so prepare struct pica_dev for R94 in p_nec_r94.c to handle its quirk.
The problem was reported by David Hopper on port-arc.
XXX We should use ARC BIOS to get info of these devices.
- Clean up the way cpu-specific tlb/cache functions are configured
and used.
- Add a workaround for a problem whereby cpu* at superhyway? fails
to probe.
- Print more info about the cpu/cache.
- Move the RESVEC handlers back into generic sh5 code and ditch
the panic stack hack.
- Make the on-chip SCIF device the default console on Cayman.
- Add experimental support for booting via a standalone bootstrap
program (not yet committed) and using the boot parameters passed
in by it.
- Add a few more SH elf constants.
- Tick a couple of items off the TODO list.
Treat +ve numbers as process group ids and -ve as pids (see tcsetpgrp() in part of current session.
Treat +ve numbers as process group ids and -ve as pids - see tcsetpgrp(3).
(approved by christos)
(we really don't need to support multiple interfaces)
Also arrange things so that we are able to unload the PXE stacks only
when we are sure that we don't need them anymore. (To make this more
useful, a hook in exec() is needed.
This fixes the floppy access problem on some hardware.
Problem reported by Miroslav Kure via Jason Wright <jason [at]
thought [dot] net> of OpenBSD. Thanks.
Fix from ALSA driver; although this setting is undocumented but
according to Jaroslav Kysela <perex [at] suse [dot] cz> of ALSA,
there's no error reported so far.
-update comments
-remove remaining references to "bootparam"
-don't try to interpret extra arguments to net_open() - we
get only passed a NULL anyway (see devopen.c)
Changes since last import:
. lots of whitespace cleanups
. typo fixes (e.g. hz, compatibilty)
. fix brightness ioctl return value
. wait for int ready using DELAY() instead of tight loop
by Andrey Petrov and Jason Thorpje (AFAIK).
This is a hack that covers some symptoms while we have no idea where
the real problem is. Anyway, since this avoids random data corruption
we better be safe and have this in-tree until the problem is solved the
right way.
pass it to the BOOTP server in the "filename" field.
(as the "netboot" bootROMs already did)
So the user can easily switch between different kernels/configurations.
