lo,

aic7xxx driver mmio / dma on x86_64 and some pre 2.6.19.5 ix86 linux kernels are broken here with the adaptec asc19160 PCI/32 scsi hba pci card.

well, i've got several live cd systems < 2.6.19.5i386 like whax 3.0 and knoppix 
that oops
and hang boot in aic7xxx init, only one booting here so far is knoppix 5.2,

the latest unofficial debian stable 2.6.8-12-amd64-generic, which says ACPI: PCI interrupt 0000:00:06.0[A] -> GSI 17 (level, low) -> IRQ 17
aic7xxx: PCI0:6:0 MEM region 0x0 unavailable. Cannot memory map device.
but works in PIO mode,

a debian etch 2.6.18-4-amd64 x86_64 which says:

SCSI subsystem initialized
GSI 16 sharing vector 0xA9 and IRQ 16
ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 17 (level, low) -> IRQ 169
BUG: soft lockup detected on CPU#0!

Call Trace:
<IRQ> [<ffffffff802a3fec>] softlockup_tick+0xdb/0xed
[<ffffffff802881df>] update_process_times+0x42/0x68
[<ffffffff8026cbd8>] smp_local_timer_interrupt+0x23/0x47
[<ffffffff8026d2cc>] smp_apic_timer_interrupt+0x41/0x47
[<ffffffff8025904a>] apic_timer_interrupt+0x66/0x6c
<EOI> [<ffffffff8038a412>] pci_conf1_write+0x0/0xc9
[<ffffffff88053718>] :aic7xxx:ahc_pci_test_register_access+0xc2/0x391
[<ffffffff880536a5>] :aic7xxx:ahc_pci_test_register_access+0x4f/0x391
[<ffffffff88059416>] :aic7xxx:ahc_pci_map_registers+0x1bb/0x239
[<ffffffff880523d2>] :aic7xxx:ahc_pci_config+0x4c/0x12d0
[<ffffffff80389fb7>] pcibios_set_master+0x1e/0x84
[<ffffffff88059186>] :aic7xxx:ahc_linux_pci_dev_probe+0x13e/0x213
[<ffffffff80317eea>] pci_device_probe+0xdf/0x147
[<ffffffff8036b9db>] driver_probe_device+0x52/0xa8
[<ffffffff8036ba96>] __driver_attach+0x0/0x9a
[<ffffffff8036bae6>] __driver_attach+0x50/0x9a
[<ffffffff8036ba96>] __driver_attach+0x0/0x9a
[<ffffffff8036b458>] bus_for_each_dev+0x43/0x6e
[<ffffffff8036b09a>] bus_add_driver+0x7e/0x130
[<ffffffff803180c4>] __pci_register_driver+0x57/0x7d
[<ffffffff8805903e>] :aic7xxx:ahc_linux_pci_init+0x17/0x21
[<ffffffff8806e325>] :aic7xxx:ahc_linux_init+0x325/0x336
[<ffffffff8027d27d>] default_wake_function+0x0/0xe
[<ffffffff8025e2e5>] __down_read+0x12/0x9a
[<ffffffff80294fa1>] __link_module+0x0/0x25
[<ffffffff802200e5>] __up_read+0x13/0x8a
[<ffffffff80297695>] sys_init_module+0x16cc/0x1882
[<ffffffff802584d6>] system_call+0x7e/0x83

BUG: soft lockup detected on CPU#0!

which is not surprising, since the aic driver has a thread 4E4 blocking test 
function:

I can fix the mmio check not to
hang, but the card won't actually work mmio until whatever's assigning
the BAR above 32 bits is fixed (that could either be a kernel PCI bug or
a BIOS bug).
[EMAIL PROTECTED]

a kernel.org 2.6.20 with K8 config set but built in a 32Bit debian sid 
environment, but works ok:

tom1:~# uname -a
Linux tom1.schorpp.dyndns.dk 2.6.20 #1 PREEMPT Mon Feb 5 11:21:13 CET 2007 i686 
GNU/Linux

tom1:~# 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 16
       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-


and finally the latest kernel.org 2.6.20.4 AMD K8 and .21-rc4 git built on debian amd64 etch userland that hangs boot on aic7xxx init without magic sysreq keys functionality and oops print triggering, (so the softlockup detection does not work without SMP config set, too):

Loading iSCSI transport class v2.0-724.
ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 17 (level, low) -> IRQ 17
... Kernel alive - Kernel direct mapping tables up to 100000000 @ 8000-d000

i've dangerously commented out the blocking while(!ahc_is_paused) and got the 
driver to work in PIO mode so far.

tom1:~# 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- Step 
ping- 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 [size=256]
      Region 1: Memory at ffffff000 (64-bit, non-prefetchable) [disabled] 
[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-

the driver asks the pci layer for the iomem resource correctly (checked 0x1000 
len) with:

request_mem_region(start, 0x1000, "aic7xxx")

which returns a invalid >32Bit address and the 64Bit pci mem resources flag is 
set.
the driver shortens the return value then: ahc->platform_data->mem_busaddr is 
u32.

on later freeing [   49.278810] Trying to free nonexistent resource 
<00000000fffff000-00000000ffffffff>
warning occours respectively.

i've tried to change containers to u64 but then the above allocation call fails 
with NULL return.

theres no reason to agree about a mb bios issue since the mb bios does not care about OS kernels and since some 32bit linux versions/kernel configs work and winxp_x64 kernel works fine with mmio.

we're not sure how to fix that:

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

on what circumstances can a >= 2.6.19.5 32bit kernel pci layer decode/report a correct iomem address and a < or 64bit x86_64 configured/built not?

working in to linux pci hal next, some change there must have caused the issue.
it seems fixed for 32bit kernels but not for 64bit.

y
tom

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to