Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!

[thomas schorpp <t.schorpp@gmx.de>]

thomas schorpp wrote:
> thomas schorpp wrote:
>> thomas schorpp wrote:
>>> James Bottomley wrote:
>>>> On Sat, 2007-03-24 at 01:51 +0100, thomas schorpp wrote:
>>>>>> no. so the pci layer reports wrong start:
>>>>> nonsense. it succeeds, confused function return with the error flag:
>>>>>
>>>>> //      u_long  start;
>>>>> //      u_long  start = 0xFFEFF000;
>>>>>         u_long  start = 0x30000000;
>>>>>         int     error;
>>>>>
>>>>>         struct resource* ret1;
>>>>>         error = 0;
>>>>> //      start = pci_resource_start(ahc->dev_softc, 1);
>>>>>         if (start != 0) {
>>>>>                 *bus_addr = start;
>>>>>                 if ((ret1 = request_mem_region(start, 0x1000, 
>>>>> "aic7xxx")) == 0)
>>>>
>>>> You can't do this.  The pci_resource_start is getting the address of
>>>> something called a Bus Address Register (BAR) it says in physical
>>>> address space where the card is responding ... you can't simply set 
>>>> that
>>>> to a random value.
>>>>
>>>> The problem you seem to have is that your system is reporting a BAR
>>>> beyond 32 bits (4GB) which the card physically can't use.  This 
>>>> could be
>>>> because of a BIOS misconfiguration or because there's a bug in the PCI
>>>> subsystem somewhere.
>>>>
>>>> James
>>>
>>> understood. waiting for LKML answers... meanwhile i found harder 
>>> reason for a possible bounds problem with the driver code on x86_64:
>>>
>>> if i do:
>>>
>>> static int
>>> ahc_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
>>>                                 u_long *bus_addr,
>>>                                 uint8_t __iomem **maddr)
>>> {
>>> //      u_long  start;
>>>        uint32_t start;
>>>
>>> i get no free warning of "*nonexistant* resource" (it cant be 
>>> nonexistant, cause it was definitely something mapped):
>>>
>>> tom1:/usr/src/linux# dmesg |grep -i free
>>> Freeing unused kernel memory: 208k freed
>>>
>>> with u_long type start i get it:
>>> Mar 24 03:41:47 localhost kernel: Trying to free nonexistent resource 
>>> <00000000fffff000-00000000ffffffff>
>>>
>>> investigating further...
>>> -
>>
>> hmm well i dont get the free warning cause
>>                        
>> release_mem_region(ahc->platform_data->mem_busaddr,
>>                                           0x1000);
>> isnt called, the hack fails
>>        error = ahc_linux_pci_reserve_mem_region(ahc, &base, &maddr);
>>        if (error == 0) {
>>
>> ok, so no bounds issue in the driver.
>>
> 
> LKML people are ignoring my report, i take this as agreement to a mb 
> bios issue.
> will test the card with a latest debian kernel x86_64 netinstall cd on 
> some other amd64 machine, but i need to find some in my reach here.
> i need more confirmation before working in the linux pci hal.
> 

no other amd64 machines in reach.

here's my "fix". seems to be a h/w bug of the adaptec 19160 hba card, 
it is just faking 64bit BAR from the register read, doesn't care on i386 arch 
due to incomplete error handling ;) , but on x86_64 arch. since here and on 
LKML is no public interest in a real fix, I do no further investigation. 

Users, *DON'T try this at home, it may break real 64bit BAR cards* (if there're any for PCI32)! 

drivers/pci/probe.c
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int rom)
{
[...]

                if ((l & (PCI_BASE_ADDRESS_SPACE | PCI_BASE_ADDRESS_MEM_TYPE_MASK))
                    == (PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_64)) {
                        u32 szhi, lhi;
                        pci_read_config_dword(dev, reg+4, &lhi);
lhi = 0; //schorpp
                        pci_write_config_dword(dev, reg+4, ~0);
                        pci_read_config_dword(dev, reg+4, &szhi);
                        pci_write_config_dword(dev, reg+4, lhi); 		//kill the wrong read 0x0F
                        szhi = pci_size(lhi, szhi, 0xffffffff);
                        next++;
printk(KERN_ERR "PCI: 64-bit check REG for device %s l %lx%lx sz %lx%lx start %llx end %llx flags $
        pci_name(dev), lhi, l, szhi, sz, res->start, res->end, res->flags);

#if BITS_PER_LONG == 64 	//the cause, more checks for buggy h/w needed or platform dep. bug somewhere deeper
                        res->start |= ((unsigned long) lhi) << 32;
                        res->end = res->start + sz;
printk(KERN_ERR "PCI: 64-bit BAR check 1 for device %s l %lx%lx sz %lx%lx start %llx end %llx flag$
        pci_name(dev), lhi, l, szhi, sz, res->start, res->end, res->flags);
[...]

hba fine again:

tom1:/usr/src/linux# lspci -vvv -s 00:06.0
00:06.0 SCSI storage controller: Adaptec AIC-7892B U160/m (rev 02)
        Subsystem: Adaptec 19160 Ultra160 SCSI Controller
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (10000ns min, 6250ns max), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 17
        BIST result: 00
        Region 0: I/O ports at d800 [disabled] [size=256]
        Region 1: Memory at 30000000 (64-bit, non-prefetchable) [size=4K]
        Expansion ROM at fbee0000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

tom1:/usr/src/linux# uname -a
Linux tom1 2.6.20.4 #30 PREEMPT Thu Mar 29 21:07:10 CEST 2007 x86_64 GNU/Linux

@debian-maintainers: Your decision if close 415864 or not. but if no one else complains why not.

y
tom