I haven't pinpointed the actual cause, here's the full conf of the
working kernel setup:
ident "$Revision: 280409-1$"
makeoptions COPTS="-O2 -fno-omit-frame-pointer"
config netbsd root on ? type ?
ipmi0 at mainbus?
acpi0 at mainbus0
hpet* at acpi?
pckbc* at acpi?
pci* at mainbus? bus ?
pci* at pchb? bus ?
pci* at ppb? bus ?
pchb* at pci? dev ? function ?
pcib* at pci? dev ? function ?
ppb* at pci? dev ? function ?
ichlpcib* at pci? dev ? function ?
agp* at pchb?
isa0 at ichlpcib?
pckbd* at pckbc?
vga* at pci? dev ? function ?
wsdisplay* at vga? console ?
wsdisplay* at wsemuldisplaydev?
wskbd* at pckbd? console ?
com0 at isa? port 0x3f8 irq 4
com1 at isa? port 0x2f8 irq 3
scsibus* at scsi?
sd* at scsibus? target ? lun ?
st* at scsibus? target ? lun ?
cd* at scsibus? target ? lun ?
ch* at scsibus? target ? lun ?
ses* at scsibus? target ? lun ?
uk* at scsibus? target ? lun ?
piixide* at pci? dev ? function ?
atabus* at ata?
wd* at atabus? drive ? flags 0x0000
atapibus* at atapi?
cd* at atapibus? drive ? flags 0x0000
sd* at atapibus? drive ? flags 0x0000
st* at atapibus? drive ? flags 0x0000
uk* at atapibus? drive ? flags 0x0000
re* at pci? dev ? function ?
rgephy* at mii? phy ?
ehci* at pci? dev ? function ?
uhci* at pci? dev ? function ?
usb* at ehci?
usb* at uhci?
uhub* at usb?
uhub* at uhub? port ?
uhidev* at uhub? port ? configuration ? interface ?
ukbd* at uhidev? reportid ?
wskbd* at ukbd? console ? mux 1
uhid* at uhidev? reportid ?
umass* at uhub? port ? configuration ? interface ?
pseudo-device ccd 4
pseudo-device cgd 4
pseudo-device raid 8
pseudo-device fss 4
pseudo-device md 1
pseudo-device veriexec 1
P.S. On a side note, I must admit I'm really amazed by the new
improvements within NetBSD 5 - I've only recently upgraded from version
2. Rock on.
David Holland a écrit :
> The following reply was made to PR kern/40945; it has been noted by GNATS.
> From: David Holland <dholland-bugs@xxxxxxxxxx>
> To: gnats-bugs@xxxxxxxxxx
> Subject: Re: kern/40945: system process locked at 100% CPU
> Date: Wed, 6 May 2009 22:39:14 +0000
> On Mon, May 04, 2009 at 03:30:05PM +0000, okay_awright wrote:
> > The bug is still present in the final 5.0 release.
> > The only workaround I was able to find (I'm no kernel hacker or ACPI
> > expert) is to disable every Intel sensor device within the kernel, then
> > the problem disappears and the system process remains idle. Something
> > may be broken or incomplete within the new envsys 2, for information the
> > problem did not appear in the previous (4.0) distribution.
> Which drivers specifically do you need to disable? (And do you need to
> disable all of them or is there just one that's really causing the
> problem? I'd expect the latter.)
> David A. Holland