Interrupt storm
Andre Guibert de Bruet
andy at siliconlandmark.com
Wed Mar 30 09:54:37 PST 2005
On Wed, 30 Mar 2005, Dan Cojocar wrote:
> On Wed, 30 Mar 2005 10:53:48 -0500 (EST), Andre Guibert de Bruet wrote:
>> On Wed, 30 Mar 2005, Dan Cojocar wrote:
>>>
>>> I tried running GENERIC and i get the following lor and watchdog
>>> timeout, no interrupt storms:
>> --- 8< --- <snip> --- 8< ---
>>> Here is the full dmesg: http://cs.ubbcluj.ro/~dan/dmesg.txt.generic
>>> I tried also my kernel with apic, i don't get interrupt storms but
>>> i get watchdog timeout message just like with GENERIC.
>>> Here is the full dmesg: http://cs.ubbcluj.ro/~dan/dmesg.txt.apic
>>> And finally i tried my kernel without apic and without acpi, it's
>>> running just fine, no interrupt storms, no watchdog timeout, but i
>>> don't have acpi :(, here is the final
>>> dmesg: http://cs.ubbcluj.ro/~dan/dmesg.txt.noacpi.
>>
>> It looks like your motherboard's DSDT is doing something hokey. I would
>> complain to the board manufacturer about this. For the timebeing, you can
>> dump the DSDT into ASL format, modify it, compile it back to DSDT and load
>> a proper version on system startup. If this is your first time, you
>> probably want to run "acpidump -d > my.asl" and make the resulting file
>> available somewhere.
>>
>> Would you also mind sharing the kernel config file that was used to build
>> the kernel that gaves you the mother of all interrupt parties?
>>
> Here is my asl: http://cs.ubbcluj.ro/~dan/my.asl
> And here is my kernel config: http://cs.ubbcluj.ro/~dan/FREE
I am looking at your kernel config file and it looks pretty much like a
stripped down version of GENERIC. I do have some observations:
- "device agp" is commented out. Is there any particular reason for this?
Does the machine not boot with it on? nForce chipsets provide generic agp
support.
- atapicam is currently broken on CURRENT. See sos@'s recent ata-mkIII
headsup announcement for additional details.
You might also want to take note of the following:
- You are specifying a "maxusers" parameter. This is no longer required
for normal operation. The kernel does a pretty good job of auto-tuning
itself. I presume there is a reason for having selected such a low number.
- The default scheduler in CURRENT is 4BSD not ULE (This might cause you
to encounter edge cases down the road).
- You commented out "device random". This causes your system to use
alternate (and arguably less secure) entropy sources for its PRNG.
I haven't really taken a look at the ASL yet. There are people on this
list that are better qualified than myself that could lend you a helping
hand with it in far less time than I ever could. I added one such person
on the CC list... :-)
Cheers,
Andy
| Andre Guibert de Bruet | Enterprise Software Consultant >
| Silicon Landmark, LLC. | http://siliconlandmark.com/ >
More information about the freebsd-current
mailing list