[LinuxBIOS] Kernel lock-ups??

joe at smittys.pointclark.net joe at smittys.pointclark.net
Wed Oct 17 09:18:02 CEST 2007


Quoting joe at smittys.pointclark.net:

> Quoting joe at smittys.pointclark.net:
>
>> Quoting Stefan Reinauer <stepan at coresystems.de>:
>>
>>> Uwe Hermann wrote:
>>>> On Tue, Oct 16, 2007 at 06:31:19PM +0200, Stefan Reinauer wrote:
>>>>
>>>>> ron minnich wrote:
>>>>>
>>>>>> Factory bioses frequently ship with broken IRQ tables. The 'hlt'
>>>>>> problem is a classic 'clock interrupts are not working' symptom. This
>>>>>> is good (it's basic) and bad (it can be a bear to debug).
>>>>>>
>>>>>> how do vendors get around their own broken tables in the fuctory bios?
>>>>>> It appears they ignore them and just jam the correct bits into
>>>>>> correct places. sad, but true. We see it all the time.
>>>>>>
>>>>> Vendors also ship with ACPI. As soon as Linux detects a reasonably
>>>>> complete ACPI implementation, it will not even look at IRQ   
>>>>> tables anymore.
>>>>>
>>>>
>>>> I'm curious, can we make the same assumptions for other payloads/OSes?
>>>> Windows, *BSD, Solaris, Plan 9, OS/2 (yuck), DOS, OFW(?), whatever...
>>>>
>>>
>>> The assumption we can make is: either ACPI or MP+PIRQ have to be there.
>>> The other assumption is no "legacy" BIOS supports MP+PIRQ anymore.
>>> So the "legacy" stuff is only actively maintained in LinuxBIOS ;-)
>>>
>>> Stefan
>>
>> Ok, So I will dig into the irq tables and see what I can find. But,
>> how do I now this isn't just related to a Read issue with the Upper
>> Bios Area 0x0F0000(960K) - 0x0FFFFF(1MB)?? That is why I would like to
>> diagnos that first. So I ask is there a way to dump (printk) this area
>> in human readable format right after the check_pirq_routing_table()
>> function?? Or if I can fudge my way to a linux command line with a
>> whole bunch of work arounds can I dump it then to see the issue?
>>
So just for sh*** and giggles I tried the no-hlt command and it got a  
little further. Does this look like the kernel is able to read the irq  
tables from LB but they are incorrect???

Thanks - Joe

Booting 'hdc1:/vmlinuz-2.6.9-1.667 ro root=/dev/hdc2 console=tty0  
console=ttyS0
,115200n8 acpi=off irqpoll lpj=720896 no-hlt initrd=/initrd-2.6.9-1.667.img'

PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
PCI: Using IRQ router PIIX/ICH [8086/24c0] at 0000:00:1f.
PCI: IRQ 0 for device 0000:00:02.0 doesn't match PIRQ mask - try  
pci=usepirqmask
PCI: Found IRQ 11 for device 0000:00:02.0
PCI: Sharing IRQ 11 with 0000:00:1d.0
PCI: IRQ 0 for device 0000:00:1d.1 doesn't match PIRQ mask - try  
pci=usepirqmask
PCI: Found IRQ 10 for device 0000:00:1d.1
PCI: IRQ 0 for device 0000:00:1d.2 doesn't match PIRQ mask - try  
pci=usepirqmask
PCI: Found IRQ 5 for device 0000:00:1d.2
PCI: Sharing IRQ 5 with 0000:00:1f.1
PCI: IRQ 0 for device 0000:00:1d.7 doesn't match PIRQ mask - try  
pci=usepirqmask
PCI: IRQ 0 for device 0000:00:1f.3 doesn't match PIRQ mask - try  
pci=usepirqmask
PCI: Found IRQ 3 for device 0000:00:1f.3
PCI: Sharing IRQ 3 with 0000:00:1f.5
PCI: Sharing IRQ 3 with 0000:00:1f.6





More information about the coreboot mailing list