Adam Belay wrote:

>On Mon, Nov 03, 2003 at 08:37:30AM -0800, Linus Torvalds wrote:
>  
>
>>On Mon, 3 Nov 2003, Gary Wolfe wrote:
>>    
>>
>>>Tried test8 and, now, test9 and both exhibit same problem.
>>>
>>>The issue seems to be related to the PnPBIOS support under the Plug and
>>>Play Kconfig category.  When enabled I get a crash of the form:
>>>      
>>>
>>Yes. The crash happens inside the BIOS itself, and the kernel doesn't
>>really have any control over it. The most Adam could possibly do is to
>>avoid calling the BIOS (or at least avoid _certain_ calls), but that would
>>require knowing what it is that triggers it.
>>    
>>
>
>One of the most common triggers is requesting for the dynamic (currently
>assigned) resource information.  This tends to happen with particular device
>nodes, from what I've seen typically the mouse controller, but I don't have a
>large enough sample space to make a generalization.  I've made some
>modifications to the PnPBIOS call function in the past and they seem to solve
>this problem for many of the buggy systems.
>
>  
>
>>Has PnP support ever worked for you on this board? Sometimes the solution
>>is to just say "it's dead, Jim", and just not enable it. There are few
>>enough systems that actually want PnP.
>>
>>Adam, any ideas?
>>
>>		Linus
>>    
>>
>
>I've included a patch that encourages the PnPBIOS to make more conservative
>calls and it should help with situations such as this one.  I'd like to see a
>dmi_scan for this system, if it is possible, so I can blacklist certain PnPBIOS
>features on it.  I've also attached a patch that makes the pnpbios proc
>interface an optional feature. The proc interface allows users to make PnPBIOS
>calls without restrictions and as a result can cause problems on some buggy
>systems. (one example is the recent ESCD problems posted on lkml)  Finally, the
>Kconfig help has been updated to better reflect this viewpoint.
>
>Please let me know if any of this helps.  I'd predict it will boot properly with
>the first patch applied.
>
>Thanks,
>Adam
>
>  
>
Sorry it took me so long to get back but work is taking up most of my 
free time as of late.  In any event, I applied the patch to a clean 
test9, enabled the PNP support and the PNPBios sub option.  I did not 
check the sub option, the creation of the /proc interface.   It still 
crashes by the way.  Here's the output.

Linux Plug and Play Support v0.97 (c) Adam Belay
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00f5350
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0x5f3a, dseg 0xf0000
general protection fault: 0000 [#1]
CPU: 0
EIP: 0098:[<00002b60>]  Not tainted
EFLAGS: 00010087
EIP is at 0x2b60
eax: 000033d8 ebx: 0000007b ecx: 00020000 edx: 00000002
esi: dfed244e edi: 0000004d ebp: dfed0000 esp: dfed9ee6
ds: 00b0 es: 00b0 ss:0068
Process swapper (pid: 1, threadinfo=dfed8000 task=c151b900)
Stack: 000003d8 33d829d2 00000000 815d004d 0004cf3a 00020002 9f2c80fc 
cfeacff2
           61f90909 01090109 007b6054 0000007b 00a08000 601000b0 
00a85fd6 00000082
           000b0000 00010090 00b00000 00a00002 90590000 0060c01b 00020000
Call Trace:

Code:  Bad EIP value.
 <0>Kernel panic: Attempted to kill init!

I don't know if you need all of that again but I figured it couldn't 
hurt.  Some of the stuff looks different from before.  As far as the 
dmi_dump goes, I'm not certain what you want or how to get that.  The 
best I could find out that sounds reasonable is the dmidecode app.  I've 
attached the output of that command.  If this is not what you wanted 
please let me know how to get what you want and I'll strive to get it to 
you.

Thanks for looking into this,

Gary