and use home-grown buffer structure.
Handle display orientation (normal or upside-down) appropriately
by making use of devinfo of base device.
If the LCD is at an expansion slot of a base unit
whose di_connector_direction == MAPLE_CONN_TOP,
the driver automatically rotates the bitmap.
You need not rotate the bitmap before passing to the driver (spec change).
under some circumstances, leave turds in the icache following vmspace
teardown.
It's not yet clear if this is a pmap bug or a toolchain problem since
the hack is unecessary when the kernel is compiled with -O0. Of course
that could just be masking the problem due to increased icache pressure...
the standard flags. See also PR#19163.
Before:
cpu0: AMD Athlon XP 1800+ (686-class), 1532.11 MHz
cpu0: features 383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR>
cpu0: features 383f9ff<PGE,MCA,CMOV,FGPAT,PSE36,MMX>
cpu0: features 383f9ff<FXSR,SSE>
After:
cpu0: AMD Athlon XP 1800+ (686-class), 1532.11 MHz
cpu0: features c3cbf9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR>
cpu0: features c3cbf9ff<PGE,MCA,CMOV,PAT,PSE36,MPC,MMXX,MMX>
cpu0: features c3cbf9ff<FXSR,SSE,3DNOW2,3DNOW>
While I'm here, amd_cpuid_cpu_cacheinfo() is an info function rather
than a probe function.
and seems like generally sensible (more sensible than not doing so), so done
in generic code rather than compat glue only
Change proposed in PR kern/18767 by Emmanuel Dreyfus.
- leave 5 processes for root-only use, the previous value of 1
was unsufficient to execute additional commands once logged, and
perhaps also not enough to actually login remotely with recent (open)sshd
- protect the log of "proc: table full" with ratecheck(), so that
the message is only logged once per 10 seconds; though syslogd normally
doesn't pass the repeated messages through, this avoids flooding
syslogd and potentially also screen/logs
- If the process hits either system limit of number of processes in system,
or user's limit of same, force the process to sleep for 0.5 seconds
before returning failure. This turns 2000 rampaging fork monsters into
2000 harmlessly snoozing fork monsters.
The sleep is intentionally uninterruptible by signals.
These are not intended as ultimate protection agains fork-bombs.
Determined attacker can eat CPU differently than via repeating
fork() calls. But this is good enough to help protect against
programming mistakes or simple-minded tests.
Based on FreeBSD kern_fork.c change in revision 1.132 by
Mike Silbersack <silby at FreeBSD org>
Change also discussed on tech-kern@NetBSD.org, thread
'Fork bomb protection patch'.
to read sector 18, and fallback to 1.44MB drive geometry if that fails.
This allows to boot from 1.44MB floppy disk in 2.88MB drive.
Tested with 2.88MB drive in IBM PS/2 model 95 donated
by 'Yokotashi' <lhc at kanal ucw cz> and Pavel Cahyna
<pavel.cahyna at st ms mff cuni cz>
Bump biosboot version.
Fixes PR kern/3418 by Keith Moore.
Change okayed by Frank van den Linden.
isochronous reception routine for IEEE 1394 OHCI (fwohci). The
transmission part is under construction.
The minimum configuration options for this feature are:
# IEEE 1394 (i.LINK)
fwohci* at pci? dev ? function ?
pseudo-device fwiso 1
- All regs must be saved before any register is altered.
- movc{3,5} alters r0-r5, so clearing bss would clear the text instead.
This needs more thinking/testing to get it work correct; there are
different ways different CPUs call "boot".
This situation is normal for asynchronous sources, and the byte stuffing
algorithm used generates unpleasant noise.
Also take care of scattered data buffer and do memcpy correctly.
This should fix PR kern/16385.
1. Clean up some debugging and trigger some on only extreme debugging needs
2. Comment alloc data mapping a bit better and fix some of the bugs here
(note..there still are some so for now the free method is never called while
I track these down)
3. Fix the copying logic in data_resp. It was calculating negative offsets
which blew up memcpy.
At this point I can probe, inquire and get through the findroot steps of a
boot:
sd0 at scsibus0 target 0 lun 0: <Maxtor, 1394 storage, 60> disk fixed
sd0: mode sense (4) returned nonsense; using fictitious geometry
sd0: 76293 MB, 76293 cyl, 64 head, 32 sec, 512 bytes/sect x 156250000 sectors
sd0: mode sense (4) returned nonsense; using fictitious geometry
sd0: no disk label
findroot: can't open dev sd0a (6)
NOTE: This will panic my machine right now with a simple disklabel -r sd0.
Also, since the free mappings routines are if (0)'d out at the moment do not
use this code for anything except experiments and then only on a machine
you don't mind panic'ing.
Fixing the mapping routines will be the next step and then finally chasing
down the proper mode sense these drives understand.
