* aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
@ 2007-03-22 15:14 thomas schorpp
2007-03-22 16:57 ` thomas schorpp
0 siblings, 1 reply; 17+ messages in thread
From: thomas schorpp @ 2007-03-22 15:14 UTC (permalink / raw)
To: SCSI development list
lo,
well, ive several live cd systems < 2.6.19.5i386 that oops and hang boot in aic7xxx init,
only one booting here 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 ok,
a debian etch 2.6.18-4-amd64 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!
a kernel.org 2.6.20 with K8 config set but built in a 32Bit debian sid environment,
but works ok,
and finally the latest kernel.org 2.6.20.3 AMD K8 built on debian amd64 etch userland that
hangs boot on aic7xxx init without magic sysreq keys functionality:
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
now trying latest scsi git and be on ##kernel at freenode if Q.
y
tom
SysRq : Resetting
Linux version 2.6.20.3amd64 (root@tom1) (gcc version 4.1.2 20061115 (prerelease7
Command line: root=/dev/sda1 ro single console=ttyS0,115200n8 aic7xxx=debug=255
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001ffd0000 (usable)
BIOS-e820: 000000001ffd0000 - 000000001ffde000 (ACPI data)
BIOS-e820: 000000001ffde000 - 0000000020000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)
end_pfn_map = 1048576
DMI 2.3 present.
Zone PFN ranges:
DMA 0 -> 4096
DMA32 4096 -> 1048576
Normal 1048576 -> 1048576
early_node_map[2] active PFN ranges
0: 0 -> 159
0: 256 -> 131024
ACPI: PM-Timer IO Port: 0x808
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x81] disabled)
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Nosave address range: 000000000009f000 - 00000000000a0000
Nosave address range: 00000000000a0000 - 00000000000e4000
Nosave address range: 00000000000e4000 - 0000000000100000
Allocating PCI resources starting at 30000000 (gap: 20000000:dec00000)
Built 1 zonelists. Total pages: 127672
Kernel command line: root=/dev/sda1 ro single console=ttyS0,115200n8 aic7xxx=de5
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 16384 bytes)
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 2000.164 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Checking aperture...
CPU 0: aperture @ d0000000 size 128 MB
Memory: 509592k/524096k available (3711k kernel code, 13908k reserved, 1316k da)
Calibrating delay using timer specific routine.. 4005.05 BogoMIPS (lpj=8010104)
Security Framework v1.0.0 initialized
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: AMD Athlon(tm) 64 Processor 3200+ stepping 02
ACPI: Core revision 20060707
tbxface-0107 [01] load_tables : ACPI Tables successfully acquired
Parsing all Control Methods:
Table [DSDT](id 0005) - 602 Objects with 65 Devices 164 Methods 27 Regions
ACPI Namespace successfully loaded at root ffffffff8079b8e0
evxfevnt-0089 [02] enable : Transition to ACPI mode successful
Using local APIC timer interrupts.
result 12501044
Detected 12.501 MHz APIC timer.
testing NMI watchdog ... OK.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
evgpeblk-0951 [04] ev_create_gpe_block : GPE 00 to 0F [_GPE] 2 regs on int 0x9
evgpeblk-1048 [03] ev_initialize_gpe_bloc: Found 5 Wake, Enabled 0 Runtime GPEsk
Completing Region/Field/Buffer/Package initialization:..........................
Initialized 26/27 Regions 33/33 Fields 39/39 Buffers 15/16 Packages (611 nodes)
Initializing Device/Processor/Thermal objects by executing _INI methods:
Executed 0 _INI methods requiring 0 _STA executions (examined 69 objects)
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: MSI-K8T-Neo2Fir, attempting to turn soundcard ON
PCI: MSI-K8T-Neo2Fir, soundcard on
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 12 devices
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
NET: Registered protocol family 8
NET: Registered protocol family 20
agpgart: Detected AGP bridge 0
agpgart: AGP aperture is 128M @ 0xd0000000
pnp: 00:08: ioport range 0x680-0x6ff has been reserved
pnp: 00:08: ioport range 0x295-0x296 has been reserved
PCI: Bridge: 0000:00:01.0
IO window: e000-efff
MEM window: fbf00000-fbffffff
PREFETCH window: e8000000-faffffff
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 3, 32768 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
JFS: nTxBlock = 3982, nTxLock = 31862
SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, nod
SGI XFS Quota Management subsystem
GFS2 (built Mar 22 2007 04:56:22) installed
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Linux agpgart interface v0.101 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Loading iSCSI transport class v2.0-724.
ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 17 (level, low) -> IRQ 17
tom1:~# lspci -s 00:06.0 -vvv
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 [size=256]
Region 1: Memory at <ignored> (64-bit, non-prefetchable) [disabled]
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:~# lspci
00:00.0 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South]
00:06.0 SCSI storage controller: Adaptec AIC-7892B U160/m (rev 02)
00:07.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
00:08.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
00:0a.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
00:0e.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46)
00:0f.0 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: ATI Technologies Inc R420 JI [Radeon X800PRO]
01:00.1 Display controller: ATI Technologies Inc R420 [Radeon X800 PRO/GTO] (Secondary)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-22 15:14 aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0! thomas schorpp
@ 2007-03-22 16:57 ` thomas schorpp
2007-03-22 21:02 ` thomas schorpp
0 siblings, 1 reply; 17+ messages in thread
From: thomas schorpp @ 2007-03-22 16:57 UTC (permalink / raw)
To: SCSI development list
no fix in scsi rc fixes git, now examining code from the softlockup trace before...
[ 0.000000] Linux version 2.6.21-rc3amd64-gbb9ba31c (root@tom1) (gcc version
4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 PREEMPT Thu Mar 22 17:39:17 CE
T 2007
[ 0.000000] Command line: root=/dev/sda1 ro single console=ttyS0,115200n8
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000001ffd0000 (usable)
[ 0.000000] BIOS-e820: 000000001ffd0000 - 000000001ffde000 (ACPI data)
[ 0.000000] BIOS-e820: 000000001ffde000 - 0000000020000000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[ 0.000000] BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)
[ 0.000000] end_pfn_map = 1048576
[ 0.000000] DMI 2.3 present.
[ 0.000000] ACPI: RSDP 000F92B0, 0014 (r0 ACPIAM)
[ 0.000000] ACPI: RSDT 1FFD0000, 0030 (r1 A M I OEMRSDT 10000612 MSFT
97)
[ 0.000000] ACPI: FACP 1FFD0200, 0084 (r2 A M I OEMFACP 10000612 MSFT
97)
[ 0.000000] ACPI: DSDT 1FFD03F0, 3D20 (r1 1XXXX 1XXXX005 5 INTL 2002
026)
[ 0.000000] ACPI: FACS 1FFDE000, 0040
[ 0.000000] ACPI: APIC 1FFD0390, 005C (r1 A M I OEMAPIC 10000612 MSFT
97)
[ 0.000000] ACPI: OEMB 1FFDE040, 0046 (r1 A M I AMI_OEM 10000612 MSFT
97)
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 4096
[ 0.000000] DMA32 4096 -> 1048576
[ 0.000000] Normal 1048576 -> 1048576
[ 0.000000] early_node_map[2] active PFN ranges
[ 0.000000] 0: 0 -> 159
[ 0.000000] 0: 256 -> 131024
[ 0.000000] Looks like a VIA chipset. Disabling IOMMU. Override with iommu=al
lowed
[ 0.000000] ACPI: PM-Timer IO Port: 0x808
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[ 0.000000] Processor #0 (Bootup-CPU)
[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x81] disabled)
[ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 1, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
[ 0.000000] Setting APIC routing to flat
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] Nosave address range: 000000000009f000 - 00000000000a0000
[ 0.000000] Nosave address range: 00000000000a0000 - 00000000000e4000
[ 0.000000] Nosave address range: 00000000000e4000 - 0000000000100000
[ 0.000000] Allocating PCI resources starting at 30000000 (gap: 20000000:dec0
0000)
[ 0.000000] Built 1 zonelists. Total pages: 126532
[ 0.000000] Kernel command line: root=/dev/sda1 ro single console=ttyS0,11520
0n8
[ 0.000000] Initializing CPU#0
[ 0.000000] PID hash table entries: 2048 (order: 11, 16384 bytes)
[ 40.851937] time.c: Detected 2000.089 MHz processor.
[ 40.853406] Console: colour VGA+ 80x25
[ 41.128559] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo
Molnar
[ 41.136287] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 41.140560] ... MAX_LOCK_DEPTH: 30
[ 41.144747] ... MAX_LOCKDEP_KEYS: 2048
[ 41.149105] ... CLASSHASH_SIZE: 1024
[ 41.153550] ... MAX_LOCKDEP_ENTRIES: 8192
[ 41.157901] ... MAX_LOCKDEP_CHAINS: 16384
[ 41.162346] ... CHAINHASH_SIZE: 8192
[ 41.166704] memory used by lock dependency info: 1648 kB
[ 41.172093] per task-struct memory footprint: 1680 bytes
[ 41.177480] ------------------------
[ 41.181041] | Locking API testsuite:
[ 41.184615] -----------------------------------------------------------------
-----------
[ 41.192694] | spin |wlock |rlock |mutex | ws
em | rsem |
[ 41.200771] ---------------------------------------------------------------
-----------
[ 41.208855] A-A deadlock: ok | ok | ok | ok | o
k | ok |
[ 41.217928] A-B-B-A deadlock: ok | ok | ok | ok | o
k | ok |
[ 41.226939] A-B-B-C-C-A deadlock: ok | ok | ok | ok | o
k | ok |
[ 41.236020] A-B-C-A-B-C deadlock: ok | ok | ok | ok | o
k | ok |
[ 41.245093] A-B-B-C-C-D-D-A deadlock: ok | ok | ok | ok | o
k | ok |
[ 41.254251] A-B-C-D-B-D-D-A deadlock: ok | ok | ok | ok | o
k | ok |
[ 41.263393] A-B-C-D-B-C-D-A deadlock: ok | ok | ok | ok | o
k | ok |
[ 41.272560] double unlock: ok | ok | ok | ok | o
k | ok |
[ 41.281529] initialize held: ok | ok | ok | ok | o
k | ok |
[ 41.290645] bad unlock order: ok | ok | ok | ok | o
k | ok |
[ 41.299657] ---------------------------------------------------------------
-----------
[ 41.307730] recursive read-lock: | ok |
| ok |
[ 41.316159] recursive read-lock #2: | ok |
| ok |
[ 41.324582] mixed read-write-lock: | ok |
| ok |
[ 41.333006] mixed write-read-lock: | ok |
| ok |
[ 41.341438] ---------------------------------------------------------------
-----------
[ 41.349511] hard-irqs-on + irq-safe-A/12: ok | ok | ok |
[ 41.356219] soft-irqs-on + irq-safe-A/12: ok | ok | ok |
[ 41.362929] hard-irqs-on + irq-safe-A/21: ok | ok | ok |
[ 41.369633] soft-irqs-on + irq-safe-A/21: ok | ok | ok |
[ 41.376327] sirq-safe-A => hirqs-on/12: ok | ok | ok |
[ 41.383029] sirq-safe-A => hirqs-on/21: ok | ok | ok |
[ 41.389732] hard-safe-A + irqs-on/12: ok | ok | ok |
[ 41.396426] soft-safe-A + irqs-on/12: ok | ok | ok |
[ 41.403146] hard-safe-A + irqs-on/21: ok | ok | ok |
[ 41.409857] soft-safe-A + irqs-on/21: ok | ok | ok |
[ 41.416568] hard-safe-A + unsafe-B #1/123: ok | ok | ok |
[ 41.423314] soft-safe-A + unsafe-B #1/123: ok | ok | ok |
[ 41.430060] hard-safe-A + unsafe-B #1/132: ok | ok | ok |
[ 41.436789] soft-safe-A + unsafe-B #1/132: ok | ok | ok |
[ 41.443527] hard-safe-A + unsafe-B #1/213: ok | ok | ok |
[ 41.450280] soft-safe-A + unsafe-B #1/213: ok | ok | ok |
[ 41.457019] hard-safe-A + unsafe-B #1/231: ok | ok | ok |
[ 41.463738] soft-safe-A + unsafe-B #1/231: ok | ok | ok |
[ 41.470476] hard-safe-A + unsafe-B #1/312: ok | ok | ok |
[ 41.477186] soft-safe-A + unsafe-B #1/312: ok | ok | ok |
[ 41.483881] hard-safe-A + unsafe-B #1/321: ok | ok | ok |
[ 41.490618] soft-safe-A + unsafe-B #1/321: ok | ok | ok |
[ 41.497347] hard-safe-A + unsafe-B #2/123: ok | ok | ok |
[ 41.504058] soft-safe-A + unsafe-B #2/123: ok | ok | ok |
[ 41.510795] hard-safe-A + unsafe-B #2/132: ok | ok | ok |
[ 41.517524] soft-safe-A + unsafe-B #2/132: ok | ok | ok |
[ 41.524244] hard-safe-A + unsafe-B #2/213: ok | ok | ok |
[ 41.530972] soft-safe-A + unsafe-B #2/213: ok | ok | ok |
[ 41.537709] hard-safe-A + unsafe-B #2/231: ok | ok | ok |
[ 41.544610] soft-safe-A + unsafe-B #2/231: ok | ok | ok |
[ 41.551331] hard-safe-A + unsafe-B #2/312: ok | ok | ok |
[ 41.558060] soft-safe-A + unsafe-B #2/312: ok | ok | ok |
[ 41.564793] hard-safe-A + unsafe-B #2/321: ok | ok | ok |
[ 41.571517] soft-safe-A + unsafe-B #2/321: ok | ok | ok |
[ 41.578245] hard-irq lock-inversion/123: ok | ok | ok |
[ 41.584974] soft-irq lock-inversion/123: ok | ok | ok |
[ 41.591694] hard-irq lock-inversion/132: ok | ok | ok |
[ 41.598423] soft-irq lock-inversion/132: ok | ok | ok |
[ 41.605160] hard-irq lock-inversion/213: ok | ok | ok |
[ 41.611880] soft-irq lock-inversion/213: ok | ok | ok |
[ 41.618625] hard-irq lock-inversion/231: ok | ok | ok |
[ 41.625354] soft-irq lock-inversion/231: ok | ok | ok |
[ 41.632066] hard-irq lock-inversion/312: ok | ok | ok |
[ 41.638794] soft-irq lock-inversion/312: ok | ok | ok |
[ 41.645523] hard-irq lock-inversion/321: ok | ok | ok |
[ 41.652243] soft-irq lock-inversion/321: ok | ok | ok |
[ 41.658963] hard-irq read-recursion/123: ok |
[ 41.664178] soft-irq read-recursion/123: ok |
[ 41.669393] hard-irq read-recursion/132: ok |
[ 41.674608] soft-irq read-recursion/132: ok |
[ 41.679824] hard-irq read-recursion/213: ok |
[ 41.685047] soft-irq read-recursion/213: ok |
[ 41.690262] hard-irq read-recursion/231: ok |
[ 41.695477] soft-irq read-recursion/231: ok |
[ 41.700700] hard-irq read-recursion/312: ok |
[ 41.705917] soft-irq read-recursion/312: ok |
[ 41.711131] hard-irq read-recursion/321: ok |
[ 41.716359] soft-irq read-recursion/321: ok |
[ 41.721579] -------------------------------------------------------
[ 41.727836] Good, all 218 testcases passed! |
[ 41.732193] ---------------------------------
[ 41.736981] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
[ 41.744291] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
[ 41.758593] Memory: 505032k/524096k available (3805k kernel code, 18504k rese
rved, 1774k data, 224k init)
[ 41.848082] Calibrating delay using timer specific routine.. 4006.34 BogoMIPS
(lpj=8012697)
[ 41.856557] Security Framework v1.0.0 initialized
[ 41.861316] Mount-cache hash table entries: 256
[ 41.866572] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[ 41.873697] CPU: L2 Cache: 512K (64 bytes/line)
[ 41.878239] CPU: AMD Athlon(tm) 64 Processor 3200+ stepping 02
[ 41.884124] ACPI: Core revision 20070126
[ 41.895705] Parsing all Control Methods:
[ 41.899595] Table [DSDT](id 0001) - 602 Objects with 65 Devices 164 Methods 2
7 Regions
[ 41.907693] tbxface-0587 [02] tb_load_namespace : ACPI Tables successful
ly acquired
[ 41.920009] evxfevnt-0091 [02] enable : Transition to ACPI mod
e successful
[ 41.969333] Using local APIC timer interrupts.
[ 42.023671] result 12500575
[ 42.026462] Detected 12.500 MHz APIC timer.
[ 42.031753] testing NMI watchdog ... OK.
[ 42.076493] NET: Registered protocol family 16
[ 42.081563] ACPI: bus type pci registered
[ 42.085588] PCI: Using configuration type 1
[ 42.094308] evgpeblk-0952 [04] ev_create_gpe_block : GPE 00 to 0F [_GPE] 2
regs on int 0x9
[ 42.107904] evgpeblk-1049 [03] ev_initialize_gpe_bloc: Found 5 Wake, Enabled
0 Runtime GPEs in this block
[ 42.118132] Completing Region/Field/Buffer/Package initialization:...........
................................................................................
......................
[ 42.145469] Initialized 26/27 Regions 33/33 Fields 39/39 Buffers 15/16 Packag
es (611 nodes)
[ 42.153990] Initializing Device/Processor/Thermal objects by executing _INI m
ethods:
[ 42.161611] Executed 0 _INI methods requiring 0 _STA executions (examined 69
objects)
[ 42.169674] ACPI: Interpreter enabled
[ 42.173336] ACPI: (supports S0 S1 S3 S4 S5)
[ 42.177705] ACPI: Using IOAPIC for interrupt routing
[ 42.212210] ACPI: PCI Root Bridge [PCI0] (0000:00)
[ 42.218513] 0000:00:0f.0: cannot adjust BAR0 (not I/O)
[ 42.223757] 0000:00:0f.0: cannot adjust BAR1 (not I/O)
[ 42.228886] 0000:00:0f.0: cannot adjust BAR2 (not I/O)
[ 42.234013] 0000:00:0f.0: cannot adjust BAR3 (not I/O)
[ 42.239699] PCI: MSI-K8T-Neo2Fir, attempting to turn soundcard ON
[ 42.245778] PCI: MSI-K8T-Neo2Fir, soundcard on
[ 42.295385] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15)
[ 42.302960] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 *11 12 14 15)
[ 42.310690] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15)
[ 42.318253] ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15)
[ 42.325826] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *
0, disabled.
[ 42.334518] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *
0, disabled.
[ 42.343206] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *
0, disabled.
[ 42.351892] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 11 12 14 15) *
0, disabled.
[ 42.360543] Linux Plug and Play Support v0.97 (c) Adam Belay
[ 42.366236] pnp: PnP ACPI init
[ 42.379607] pnp: PnP ACPI: found 12 devices
[ 42.385132] SCSI subsystem initialized
[ 42.389179] PCI: Using ACPI for IRQ routing
[ 42.393359] PCI: If a device doesn't work, try "pci=routeirq". If it helps,
post a report
[ 42.401868] NET: Registered protocol family 8
[ 42.406217] NET: Registered protocol family 20
[ 42.410911] agpgart: Detected AGP bridge 0
[ 42.419685] agpgart: AGP aperture is 128M @ 0xd0000000
[ 42.425098] pnp: 00:08: ioport range 0x680-0x6ff has been reserved
[ 42.431261] Time: tsc clocksource has been installed.
[ 42.436317] pnp: 00:08: ioport range 0x295-0x296 has been reserved
[ 42.442499] pnp: 00:0a: iomem range 0xfec00000-0xfec00fff has been reserved
[ 42.449444] pnp: 00:0a: iomem range 0xfee00000-0xfee00fff has been reserved
[ 42.456396] pnp: 00:0b: iomem range 0x0-0x9ffff could not be reserved
[ 42.462822] pnp: 00:0b: iomem range 0xc0000-0xcffff has been reserved
[ 42.469248] pnp: 00:0b: iomem range 0xe0000-0xfffff could not be reserved
[ 42.476020] pnp: 00:0b: iomem range 0x100000-0x1fffffff could not be reserved
[ 42.484406] PCI: Bridge: 0000:00:01.0
[ 42.488071] IO window: e000-efff
[ 42.491486] MEM window: fbf00000-fbffffff
[ 42.495663] PREFETCH window: e8000000-faffffff
[ 42.500353] NET: Registered protocol family 2
[ 42.542896] IP route cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 42.550166] TCP established hash table entries: 16384 (order: 8, 1310720 byte
s)
[ 42.558898] TCP bind hash table entries: 16384 (order: 8, 1310720 bytes)
[ 42.567343] TCP: Hash tables configured (established 16384 bind 16384)
[ 42.573896] TCP reno registered
[ 42.590823] Initializing RT-Tester: OK
[ 42.594724] Total HugeTLB memory allocated, 0
[ 42.599639] VFS: Disk quotas dquot_6.5.1
[ 42.603580] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 42.610491] JFS: nTxBlock = 3946, nTxLock = 31575
[ 42.618904] SGI XFS with ACLs, security attributes, realtime, large block/ino
de numbers, no debug enabled
[ 42.628786] SGI XFS Quota Management subsystem
[ 42.633553] GFS2 (built Mar 22 2007 17:21:49) installed
[ 42.639065] io scheduler noop registered
[ 42.643003] io scheduler anticipatory registered (default)
[ 42.648520] io scheduler deadline registered
[ 42.652822] io scheduler cfq registered
[ 42.754015] Linux agpgart interface v0.102 (c) Dave Jones
[ 42.759419] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
enabled
[ 42.767495] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 42.775544] 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 42.784273] RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 block
size
[ 42.792265] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[ 42.798668] ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
[ 42.807376] Loading iSCSI transport class v2.0-724.
[ 42.812647] ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 17 (level, low) -> IRQ
17
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-22 16:57 ` thomas schorpp
@ 2007-03-22 21:02 ` thomas schorpp
2007-03-22 23:00 ` thomas schorpp
0 siblings, 1 reply; 17+ messages in thread
From: thomas schorpp @ 2007-03-22 21:02 UTC (permalink / raw)
To: SCSI development list
[ 0.000000] Linux version 2.6.21-rc3amd64-gbb9ba31c-dirty (root@tom1) (gcc ve
rsion 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #3 PREEMPT Thu Mar 22 21:48
:44 CET 2007
added some traces,
ok it does not return from the first pci_map_registers():
[ 42.754305] Loading iSCSI transport class v2.0-724.
[ 42.759656] iscsi: registered transport (tcp)
[ 42.764016] ahc_linux_pci_init
[ 42.767207] ahc_linux_pci_dev_probe
[ 42.770744] ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 17 (level, low) -> IRQ
17
[ 42.778160] ahc_pci_config
[ 42.780861] set_power_state
[ 42.783656] map_registers
tracing further and provide args dump if applicable
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-22 21:02 ` thomas schorpp
@ 2007-03-22 23:00 ` thomas schorpp
2007-03-23 1:26 ` thomas schorpp
0 siblings, 1 reply; 17+ messages in thread
From: thomas schorpp @ 2007-03-22 23:00 UTC (permalink / raw)
To: SCSI development list
[ 48.848796] Loading iSCSI transport class v2.0-724.
[ 48.854066] iscsi: registered transport (tcp)
[ 48.858479] ahc_linux_pci_init
[ 48.861676] ahc_linux_pci_dev_probe
[ 48.865208] ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 17 (level, low) -> IRQ
17
[ 48.872628] ahc_pci_config
[ 48.875335] set_power_state
[ 48.878126] map_registers
[ 48.880744] ahc_pci_map_registers enter
[ 48.884571] .read_config
[ 48.887106] .reserve_mem
[ 48.889647] .write_config_iferr0
[ 48.892871] .test_registers_iferr0
[ 48.896265] ahc_pci_test_register_access enter
[ 48.900699] .read_config
[ 48.903235] .write_config_noserr
[ 48.906462] .hcnctrl
[ 48.908648] .hcntrl pause cmd
[ 48.911616] .I will pause 4E4 if missing errh before :/
ok, as expected, the wait for pause ended loop, (someone with the specs pls say max HZ
for a) wait_interruptible(_timeout)() here.
yes, I know that case must not happen and it should bug cause
the pci config is messed up already, but generally such loops are
surely inacceptable in such a kernel thread.
will dump the config data to here, maybe its readable to the aic devs.
then disable test and will let it bug somewhere further where the
cause can possibly be easier seen.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-22 23:00 ` thomas schorpp
@ 2007-03-23 1:26 ` thomas schorpp
2007-03-23 4:45 ` James Bottomley
0 siblings, 1 reply; 17+ messages in thread
From: thomas schorpp @ 2007-03-23 1:26 UTC (permalink / raw)
To: SCSI development list
ok, overriding the first while(ahc_is_paused) that blocked before
(i see no sense for doing this in a pci mmap test function, cause
proper resource setup is required *before* using such I/O functions,
otherwise the adapter had entered SEQ paused status)
i got the kernel to boot at least at pio mode.
this is surely not the correct resource and looks like a datatype
boundary overflow, the upper 0x0f is missing:
[ 49.278810] Trying to free nonexistent resource <00000000fffff000-00000000fff
fffff>
ffff-f000
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] [siz
e=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-
000f-ffff-f000
but theres a platform issue somewhere in the code, affecting
x86_64. maintainers, pls have a look, too, thx.
[ 49.181771] Loading iSCSI transport class v2.0-724.
[ 49.187129] iscsi: registered transport (tcp)
[ 49.191491] ahc_linux_pci_init
[ 49.194682] ahc_linux_pci_dev_probe
[ 49.198221] ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 17 (level, low) -> IRQ
17
[ 49.205636] ahc_pci_config
[ 49.208337] set_power_state
[ 49.211131] map_registers
[ 49.213748] ahc_pci_map_registers enter
[ 49.217574] .read_config
[ 49.220110] .reserve_mem
[ 49.222649] .write_config_iferr0
[ 49.225869] .test_registers_iferr0
[ 49.229267] ahc_pci_test_register_access enter
[ 49.233704] .read_config 116
[ 49.236584] .write_config_noserr
[ 49.239810] .hcnctrl
[ 49.241998] .paused 0
[ 49.244362] .write_config
[ 49.246982] .write_config
[ 49.249614] .fail scb_base
[ 49.252321] .ending fail err 5
[ 49.255368] .read_config
[ 49.257901] .write_config
[ 49.260523] .clrint
[ 49.262622] .seqctl
[ 49.264720] .write_config
[ 49.267340] ahc_pci_test_register_access leave
[ 49.271775] aic7xxx: PCI Device 0:6:0 failed memory mapped test. Using PIO.
[ 49.278810] Trying to free nonexistent resource <00000000fffff000-00000000fff
fffff>
[ 49.286443] .reserve_io
[ 49.288894] reserve_io_ok
[ 49.291510] .write_config
[ 49.294129] map_registers leave
[ 49.297265] read_config
[ 49.299710] write_config1
[ 49.302330] write_config2
[ 49.304951] softc_init
[ 49.307329] ahc_reset
[ 49.322446] ahc_init_core
[ 49.325301] ahc_pci:0:6:0: hardware scb 64 bytes; kernel scb 104 bytes; ahc_d
ma 8 bytes
[ 49.519047] ENINT
[ 54.513224] scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
[ 54.513226] <Adaptec 19160B Ultra160 SCSI adapter>
[ 54.513227] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
[ 54.513228]
[ 54.534992] Adaptec aacraid driver (1.1-5[2423]-mh3)
[ 54.540128] st: Version 20070203, fixed bufsize 32768, s/g segs 256
[ 54.546541] osst :I: Tape driver with OnStream support version 0.99.4
[ 54.546542] osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $
[ 54.560110] SCSI Media Changer driver v0.25
[ 54.564798] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq
1,12
[ 54.572940] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 54.578075] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 54.583665] mice: PS/2 mouse device common for all mice
[ 54.589185] md: linear personality registered for level -1
[ 54.594682] md: raid0 personality registered for level 0
[ 54.600011] md: raid1 personality registered for level 1
[ 54.672826] raid6: int64x1 1865 MB/s
[ 54.740694] raid6: int64x2 2508 MB/s
[ 54.790668] (scsi0:A:0:0): Saw Selection Timeout for SCB 0x3
[ 54.808931] raid6: int64x4 2190 MB/s
[ 54.880403] raid6: int64x8 1641 MB/s
[ 54.948293] raid6: sse2x1 2445 MB/s
[ 55.016149] raid6: sse2x2 3332 MB/s
[ 55.084035] raid6: sse2x4 3666 MB/s
[ 55.087774] raid6: using algorithm sse2x4 (3666 MB/s)
[ 55.092819] md: raid6 personality registered for level 6
[ 55.098120] md: raid5 personality registered for level 5
[ 55.103423] md: raid4 personality registered for level 4
[ 55.108724] raid5: automatically using best checksumming function: generic_ss
e
[ 55.131933] generic_sse: 6247.000 MB/sec
[ 55.136192] raid5: using function: generic_sse (6247.000 MB/sec)
[ 55.142185] md: multipath personality registered for level -4
[ 55.148202] input: AT Translated Set 2 keyboard as /class/input/input0
[ 55.155159] device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-d
evel@redhat.com
[ 55.163779] TCP cubic registered
[ 55.167586] scsi: waiting for bus probes to complete ...
[ 55.174490] scsi 0:0:1:0: Direct-Access SEAGATE ST336752LW 0003 PQ
: 0 ANSI: 3
[ 55.182578] scsi0:A:1:0: Tagged Queuing enabled. Depth 32
[ 55.188138] target0:0:1: Beginning Domain Validation
[ 55.199456] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0xc0
[ 55.204459] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x20
[ 55.209456] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x2
[ 55.214407] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x1
[ 55.219365] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x2
[ 55.224326] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x3
[ 55.229283] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x1
[ 55.234275] scsi0:A:1:0: INITIATOR_MSG_OUT PHASEMIS in Message-in phase
[ 55.240905] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x1
[ 55.245746] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x2
[ 55.250579] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x3
[ 55.255426] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x1
[ 55.260296] scsi0:A:1:0: Asserting ATN for response
[ 55.265216] scsi0:A:1:0: INITIATOR_MSG_IN PHASEMIS in Message-out phase
[ 55.271840] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x1
[ 55.276796] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x3
[ 55.281753] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x1
[ 55.286697] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x45
[ 55.291735] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x0
[ 55.296773] scsi0:A:1:0: INITIATOR_MSG_OUT PHASEMIS in Message-in phase
[ 55.303399] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x1
[ 55.308243] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x3
[ 55.313076] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x1
[ 55.317908] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x32
[ 55.322840] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x0
[ 55.327654] target0:0:1: wide asynchronous
[ 55.331969] scsi0:A:1:0: INITIATOR_MSG_IN PHASEMIS in Command phase
[ 55.342834] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0xc0
[ 55.347834] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x20
[ 55.352833] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x3
[ 55.357779] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x1
[ 55.362737] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x6
[ 55.367695] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x4
[ 55.372658] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x9
[ 55.377600] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x0
[ 55.382556] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x7f
[ 55.387593] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x1
[ 55.392532] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x2
[ 55.397540] scsi0:A:1:0: INITIATOR_MSG_OUT PHASEMIS in Message-in phase
[ 55.404164] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x1
[ 55.408994] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x6
[ 55.413841] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x4
[ 55.418675] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x9
[ 55.423505] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x0
[ 55.428355] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x3f
[ 55.433273] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x1
[ 55.438120] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x2
[ 55.442934] target0:0:1: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63
)
[ 55.450279] scsi0:A:1:0: INITIATOR_MSG_IN PHASEMIS in Command phase
[ 55.461120] (scsi0:A:1:0): SCB 2: requests Check Status
[ 55.466347] (scsi0:A:1:0): Sending Sense
[ 55.470312] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x80
[ 55.475315] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x1
[ 55.480283] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x6
[ 55.485245] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x4
[ 55.490202] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x9
[ 55.495163] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x0
[ 55.500104] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x3f
[ 55.505137] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x1
[ 55.510073] scsi0:A:1:0: INITIATOR_MSG_OUT byte 0x2
[ 55.515083] scsi0:A:1:0: INITIATOR_MSG_OUT PHASEMIS in Message-in phase
[ 55.521707] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x1
[ 55.526537] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x6
[ 55.531385] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x4
[ 55.536219] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x9
[ 55.541051] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x0
[ 55.545898] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x3f
[ 55.550813] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x1
[ 55.555662] scsi0:A:1:0: INITIATOR_MSG_IN byte 0x2
[ 55.560608] scsi0:A:1:0: INITIATOR_MSG_IN PHASEMIS in Command phase
[ 55.567063] (scsi0:A:1:0): Handled Sense Residual of 14 bytes
[ 55.572813] Copied 18 bytes of sense data:
[ 55.576919] 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0
[ 55.584392] 0x0 0x0
[ 55.590422] target0:0:1: Ending Domain Validation
[ 55.595458] (scsi0:A:1:0): Handled Residual of 4080 bytes
[ 55.856881] (scsi0:A:2:0): Saw Selection Timeout for SCB 0x2
[ 56.118816] (scsi0:A:3:0): Saw Selection Timeout for SCB 0x3
[ 56.380734] (scsi0:A:4:0): Saw Selection Timeout for SCB 0x2
[ 56.642649] (scsi0:A:5:0): Saw Selection Timeout for SCB 0x3
[ 56.904565] (scsi0:A:6:0): Saw Selection Timeout for SCB 0x2
[ 57.166480] (scsi0:A:8:0): Saw Selection Timeout for SCB 0x3
[ 57.428389] (scsi0:A:9:0): Saw Selection Timeout for SCB 0x2
[ 57.690302] (scsi0:A:10:0): Saw Selection Timeout for SCB 0x3
[ 57.952303] (scsi0:A:11:0): Saw Selection Timeout for SCB 0x2
[ 58.214304] (scsi0:A:12:0): Saw Selection Timeout for SCB 0x3
[ 58.476306] (scsi0:A:13:0): Saw Selection Timeout for SCB 0x2
[ 58.738307] (scsi0:A:14:0): Saw Selection Timeout for SCB 0x3
[ 59.000317] (scsi0:A:15:0): Saw Selection Timeout for SCB 0x2
[ 59.007520] SCSI device sda: 71687369 512-byte hdwr sectors (36704 MB)
[ 59.015053] sda: Write Protect is off
[ 59.020225] SCSI device sda: write cache: enabled, read cache: enabled, suppo
rts DPO and FUA
[ 59.029570] SCSI device sda: 71687369 512-byte hdwr sectors (36704 MB)
[ 59.037102] sda: Write Protect is off
[ 59.042273] SCSI device sda: write cache: enabled, read cache: enabled, suppo
rts DPO and FUA
[ 59.050720] sda: sda1 sda2 sda3
[ 59.068842] sd 0:0:1:0: Attached scsi disk sda
[ 59.073583] sd 0:0:1:0: Attached scsi generic sg0 type 0
[ 59.078945] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 59.085714] md: Autodetecting RAID arrays.
[ 59.089820] md: autorun ...
[ 59.092614] md: ... autorun DONE.
[ 59.106354] kjournald starting. Commit interval 5 seconds
[ 59.111969] EXT3-fs: mounted filesystem with ordered data mode.
[ 59.118031] VFS: Mounted root (ext3 filesystem) readonly.
[ 59.123508] Freeing unused kernel memory: 224k freed
[ 59.128929] Write protecting the kernel read-only data: 1416k
INIT: version 2.86 booting
[ 59.535079] NET: Registered protocol family 1
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...[ 60.246648] (scsi0:A:1:0): Handled R
esidual of 241 bytes
[ 60.270540] (scsi0:A:1:0): Handled Residual of 230 bytes
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-23 1:26 ` thomas schorpp
@ 2007-03-23 4:45 ` James Bottomley
2007-03-23 7:32 ` thomas schorpp
0 siblings, 1 reply; 17+ messages in thread
From: James Bottomley @ 2007-03-23 4:45 UTC (permalink / raw)
To: t.schorpp; +Cc: SCSI development list
On Fri, 2007-03-23 at 02:26 +0100, thomas schorpp wrote:
> ok, overriding the first while(ahc_is_paused) that blocked before
> (i see no sense for doing this in a pci mmap test function, cause
> proper resource setup is required *before* using such I/O functions,
> otherwise the adapter had entered SEQ paused status)
> i got the kernel to boot at least at pio mode.
>
> this is surely not the correct resource and looks like a datatype
> boundary overflow, the upper 0x0f is missing:
> [ 49.278810] Trying to free nonexistent resource
> <00000000fffff000-00000000fff
> fffff>
That's because ahc->platform_data->mem_busaddr is u32
> [ 54.513224] scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
> [ 54.513226] <Adaptec 19160B Ultra160 SCSI adapter>
> [ 54.513227] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
The driver code suggests that the 7892 can't do the AHC_LARGE_SCBS
features ... which means the card itself cannot address more than 32
bits of memory, so it would be unable to decode a BAR that's beyond the
32 bit range. So this looks like some type of error in the PCI config
system (or possibly in the BIOS). I think this card needs its BARs to
be in the lower 32 bits to function.
James
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-23 4:45 ` James Bottomley
@ 2007-03-23 7:32 ` thomas schorpp
2007-03-23 16:28 ` thomas schorpp
0 siblings, 1 reply; 17+ messages in thread
From: thomas schorpp @ 2007-03-23 7:32 UTC (permalink / raw)
To: SCSI development list
James Bottomley wrote:
> On Fri, 2007-03-23 at 02:26 +0100, thomas schorpp wrote:
>> ok, overriding the first while(ahc_is_paused) that blocked before
>> (i see no sense for doing this in a pci mmap test function, cause
>> proper resource setup is required *before* using such I/O functions,
>> otherwise the adapter had entered SEQ paused status)
>> i got the kernel to boot at least at pio mode.
>>
>> this is surely not the correct resource and looks like a datatype
>> boundary overflow, the upper 0x0f is missing:
>> [ 49.278810] Trying to free nonexistent resource
>> <00000000fffff000-00000000fff
>> fffff>
>
> That's because ahc->platform_data->mem_busaddr is u32
>
>
>> [ 54.513224] scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
>> [ 54.513226] <Adaptec 19160B Ultra160 SCSI adapter>
>> [ 54.513227] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
>
> The driver code suggests that the 7892 can't do the AHC_LARGE_SCBS
> features ... which means the card itself cannot address more than 32
> bits of memory, so it would be unable to decode a BAR that's beyond the
> 32 bit range. So this looks like some type of error in the PCI config
> system (or possibly in the BIOS). I think this card needs its BARs to
> be in the lower 32 bits to function.
>
> James
>
>
i agree for this to be a 32bit dma busmaster chip,
since pci_resource_flags and lspci say 64bit mem resource type
aic7xxx: pci_resource_start fffff000 *maddr 20000 mem64 4
we've a bug in the x86_64 linux pci config, BIOS is ok,
the hardware worked fine in a winxp_x64 test setup a few months ago.
will ask LKML.
y
tom
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-23 7:32 ` thomas schorpp
@ 2007-03-23 16:28 ` thomas schorpp
2007-03-23 17:23 ` James Bottomley
0 siblings, 1 reply; 17+ messages in thread
From: thomas schorpp @ 2007-03-23 16:28 UTC (permalink / raw)
To: SCSI development list
thomas schorpp wrote:
> James Bottomley wrote:
>> On Fri, 2007-03-23 at 02:26 +0100, thomas schorpp wrote:
>>> ok, overriding the first while(ahc_is_paused) that blocked before (i
>>> see no sense for doing this in a pci mmap test function, cause proper
>>> resource setup is required *before* using such I/O functions,
>>> otherwise the adapter had entered SEQ paused status)
>>> i got the kernel to boot at least at pio mode.
>>>
>>> this is surely not the correct resource and looks like a datatype
>>> boundary overflow, the upper 0x0f is missing:
>>> [ 49.278810] Trying to free nonexistent resource
>>> <00000000fffff000-00000000fff
>>> fffff>
>>
>> That's because ahc->platform_data->mem_busaddr is u32
>>
>>
>>> [ 54.513224] scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER,
>>> Rev 7.0
>>> [ 54.513226] <Adaptec 19160B Ultra160 SCSI adapter>
>>> [ 54.513227] aic7892: Ultra160 Wide Channel A, SCSI Id=7,
>>> 32/253 SCBs
>>
>> The driver code suggests that the 7892 can't do the AHC_LARGE_SCBS
>> features ... which means the card itself cannot address more than 32
>> bits of memory, so it would be unable to decode a BAR that's beyond the
>> 32 bit range. So this looks like some type of error in the PCI config
>> system (or possibly in the BIOS). I think this card needs its BARs to
>> be in the lower 32 bits to function.
>>
>> James
>>
>>
>
> i agree for this to be a 32bit dma busmaster chip,
> since pci_resource_flags and lspci say 64bit mem resource type
>
> aic7xxx: pci_resource_start fffff000 *maddr 20000 mem64 4
>
> we've a bug in the x86_64 linux pci config, BIOS is ok, the hardware
> worked fine in a winxp_x64 test setup a few months ago.
>
> will ask LKML.
>
> y
> tom
sorry, wrong according to http://download.adaptec.com/pdfs/aic7892.pdf.
"66 MHz, 64-bit, PCI interface that
supports zero wait-state memory;
also operates on 33 MHz, 32-bit
PCI busses"
this chip is capable of 64bit addressing, as pci_resource_nnnn (checking this) on x86_64 platform
and lspci on x86_64 *and* AMDK7 configured kernels reports, even on PCI/32, right?
or is it impossible to do multiplexed 64bit mem addressing on PCI/32?
Why are the driver structure address members 32bits wide types if therere PCI/64 card
models with this chips as listet in aic7xxx.txt kernel doc and stated in aic7892.pdf?
I'll adapt the respective driver structures and function args now to 64bit and see what happens...
can adaptec.inc pls comment? since the aha19160 card is still in production state,
i assume they want to have a linux x86_64 dma capable driver. so far it is not,
or can other users having this card pls confirm my pci system broken?
y
tom
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-23 16:28 ` thomas schorpp
@ 2007-03-23 17:23 ` James Bottomley
2007-03-23 18:23 ` thomas schorpp
0 siblings, 1 reply; 17+ messages in thread
From: James Bottomley @ 2007-03-23 17:23 UTC (permalink / raw)
To: t.schorpp; +Cc: SCSI development list
On Fri, 2007-03-23 at 17:28 +0100, thomas schorpp wrote:
> > i agree for this to be a 32bit dma busmaster chip,
> > since pci_resource_flags and lspci say 64bit mem resource type
> >
> > aic7xxx: pci_resource_start fffff000 *maddr 20000 mem64 4
> >
> > we've a bug in the x86_64 linux pci config, BIOS is ok, the hardware
> > worked fine in a winxp_x64 test setup a few months ago.
> >
> > will ask LKML.
> >
> > y
> > tom
>
> sorry, wrong according to http://download.adaptec.com/pdfs/aic7892.pdf.
>
> "66 MHz, 64-bit, PCI interface that
> supports zero wait-state memory;
> also operates on 33 MHz, 32-bit
> PCI busses"
>
> this chip is capable of 64bit addressing, as pci_resource_nnnn (checking this) on x86_64 platform
> and lspci on x86_64 *and* AMDK7 configured kernels reports, even on PCI/32, right?
> or is it impossible to do multiplexed 64bit mem addressing on PCI/32?
It can only do 37 bit addressing ... only the aic79xx can do the full 64
bits, so I suspect it should never get a 64 bit BAR, since it wouldn't
be able to decode the full 32 bits. 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).
> Why are the driver structure address members 32bits wide types if therere PCI/64 card
> models with this chips as listet in aic7xxx.txt kernel doc and stated in aic7892.pdf?
> I'll adapt the respective driver structures and function args now to 64bit and see what happens...
>
> can adaptec.inc pls comment? since the aha19160 card is still in production state,
> i assume they want to have a linux x86_64 dma capable driver. so far it is not,
> or can other users having this card pls confirm my pci system broken?
James
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-23 17:23 ` James Bottomley
@ 2007-03-23 18:23 ` thomas schorpp
2007-03-23 18:59 ` thomas schorpp
0 siblings, 1 reply; 17+ messages in thread
From: thomas schorpp @ 2007-03-23 18:23 UTC (permalink / raw)
To: SCSI development list
James Bottomley wrote:
> On Fri, 2007-03-23 at 17:28 +0100, thomas schorpp wrote:
>>> i agree for this to be a 32bit dma busmaster chip,
>>> since pci_resource_flags and lspci say 64bit mem resource type
>>>
>>> aic7xxx: pci_resource_start fffff000 *maddr 20000 mem64 4
>>>
static int
ahc_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
u_long *bus_addr,
uint8_t __iomem **maddr)
{
// u_long start;
u_long len;
int error;
uint64_t start;
...
printk(KERN_WARNING "aic7xxx: pci_resource_start 0x%llx mem64 0x%lx\n", start, pci_resource_flags(ahc->dev_softc, 1) & PCI_BASE_ADDRESS_MEM_TYPE_64 ); //schorpp
return (error);
aic7xxx: pci_resource_start 0xffffff000 mem64 0x4
-----------------------------------------------^
just to doublecheck the situation, posted lspci already.
will check next, if
len = pci_resource_len(ahc->dev_softc, 1);
if (start != 0) {
*bus_addr = start;
// if (request_mem_region(start, 0x1000, "aic7xxx") == 0)
if (request_mem_region(start, len, "aic7xxx") == 0)
succeeds.
>>> we've a bug in the x86_64 linux pci config, BIOS is ok, the hardware
>>> worked fine in a winxp_x64 test setup a few months ago.
>>>
>>> will ask LKML.
>>>
>>> y
>>> tom
>> sorry, wrong according to http://download.adaptec.com/pdfs/aic7892.pdf.
>>
>> "66 MHz, 64-bit, PCI interface that
>> supports zero wait-state memory;
>> also operates on 33 MHz, 32-bit
>> PCI busses"
>>
>> this chip is capable of 64bit addressing, as pci_resource_nnnn (checking this) on x86_64 platform
>> and lspci on x86_64 *and* AMDK7 configured kernels reports, even on PCI/32, right?
>> or is it impossible to do multiplexed 64bit mem addressing on PCI/32?
>
> It can only do 37 bit addressing ... only the aic79xx can do the full 64
> bits, so I suspect it should never get a 64 bit BAR, since it wouldn't
> be able to decode the full 32 bits. 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).
>
ok, i trust in that. adaptor bios and mainboard bios *are* out, winxp_x64 driver handled all.
so agree on kernel pci hal issue.
but what for const uint64_t mask_39bit = 0x7FFFFFFFFFULL;
then?
>>
>> can adaptec.inc pls comment? since the aha19160 card is still in production state,
>> i assume they want to have a linux x86_64 dma capable driver. so far it is not,
>> or can other users having this card pls confirm my pci system broken?
>
> James
>
>
y
tom
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-23 18:23 ` thomas schorpp
@ 2007-03-23 18:59 ` thomas schorpp
2007-03-24 0:51 ` thomas schorpp
0 siblings, 1 reply; 17+ messages in thread
From: thomas schorpp @ 2007-03-23 18:59 UTC (permalink / raw)
To: SCSI development list
thomas schorpp wrote:
> James Bottomley wrote:
>> On Fri, 2007-03-23 at 17:28 +0100, thomas schorpp wrote:
>>>> i agree for this to be a 32bit dma busmaster chip,
>>>> since pci_resource_flags and lspci say 64bit mem resource type
>>>>
>>>> aic7xxx: pci_resource_start fffff000 *maddr 20000 mem64 4
>>>>
>
> static int
> ahc_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
> u_long *bus_addr,
> uint8_t __iomem **maddr)
> {
> // u_long start;
> u_long len;
> int error;
> uint64_t start;
> ...
> printk(KERN_WARNING "aic7xxx: pci_resource_start 0x%llx mem64
> 0x%lx\n", start, pci_resource_flags(ahc->dev_softc, 1) &
> PCI_BASE_ADDRESS_MEM_TYPE_64 ); //schorpp
> return (error);
>
> aic7xxx: pci_resource_start 0xffffff000 mem64 0x4
> -----------------------------------------------^
>
> just to doublecheck the situation, posted lspci already.
>
> will check next, if
> len = pci_resource_len(ahc->dev_softc, 1);
> if (start != 0) {
> *bus_addr = start;
> // if (request_mem_region(start, 0x1000, "aic7xxx") == 0)
> if (request_mem_region(start, len, "aic7xxx") == 0)
>
> succeeds.
no. so the pci layer reports wrong start:
start = pci_resource_start(ahc->dev_softc, 1);
len = pci_resource_len(ahc->dev_softc, 1);
if (start != 0) {
*bus_addr = start;
// if (request_mem_region(start, 0x1000, "aic7xxx") == 0)
if (request_mem_region(start, len, "aic7xxx") == 0)
error = ENOMEM;
printk(KERN_WARNING "aic7xxx: req_mem_region 0x%x memlen 0x%lx \n", error, len ); //schorpp
tom1:~# dmesg |grep aic
aic7xxx: DMA_32BIT_MASK
aic7xxx: req_mem_region 0x0 memlen 0x1000
aic7xxx: pci_resource_start 0xffffff000 *maddr 0x20000 mem64 0x4
aic7xxx: PCI Device 0:6:0 failed memory mapped test. Using PIO.
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
>
>>>> we've a bug in the x86_64 linux pci config, BIOS is ok, the hardware
>>>> worked fine in a winxp_x64 test setup a few months ago.
>>>>
>>>> will ask LKML.
>>>>
>>>> y
>>>> tom
>>> sorry, wrong according to http://download.adaptec.com/pdfs/aic7892.pdf.
>>>
>>> "66 MHz, 64-bit, PCI interface that
>>> supports zero wait-state memory;
>>> also operates on 33 MHz, 32-bit
>>> PCI busses"
>>>
>>> this chip is capable of 64bit addressing, as pci_resource_nnnn
>>> (checking this) on x86_64 platform and lspci on x86_64 *and* AMDK7
>>> configured kernels reports, even on PCI/32, right?
>>> or is it impossible to do multiplexed 64bit mem addressing on PCI/32?
>>
>> It can only do 37 bit addressing ... only the aic79xx can do the full 64
>> bits, so I suspect it should never get a 64 bit BAR, since it wouldn't
>> be able to decode the full 32 bits. 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).
>>
>
> ok, i trust in that. adaptor bios and mainboard bios *are* out,
> winxp_x64 driver handled all.
> so agree on kernel pci hal issue.
> but what for const uint64_t mask_39bit = 0x7FFFFFFFFFULL;
> then?
>
>>>
>>> can adaptec.inc pls comment? since the aha19160 card is still in
>>> production state, i assume they want to have a linux x86_64 dma
>>> capable driver. so far it is not, or can other users having this card
>>> pls confirm my pci system broken?
>>
>> James
>>
>>
>
> y
> tom
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-23 18:59 ` thomas schorpp
@ 2007-03-24 0:51 ` thomas schorpp
2007-03-24 1:17 ` James Bottomley
0 siblings, 1 reply; 17+ messages in thread
From: thomas schorpp @ 2007-03-24 0:51 UTC (permalink / raw)
To: SCSI development list
thomas schorpp wrote:
> thomas schorpp wrote:
>> James Bottomley wrote:
>>> On Fri, 2007-03-23 at 17:28 +0100, thomas schorpp wrote:
>>>>> i agree for this to be a 32bit dma busmaster chip,
>>>>> since pci_resource_flags and lspci say 64bit mem resource type
>>>>>
>>>>> aic7xxx: pci_resource_start fffff000 *maddr 20000 mem64 4
>>>>>
>>
>> static int
>> ahc_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
>> u_long *bus_addr,
>> uint8_t __iomem **maddr)
>> {
>> // u_long start;
>> u_long len;
>> int error;
>> uint64_t start;
>> ...
>> printk(KERN_WARNING "aic7xxx: pci_resource_start 0x%llx mem64
>> 0x%lx\n", start, pci_resource_flags(ahc->dev_softc, 1) &
>> PCI_BASE_ADDRESS_MEM_TYPE_64 ); //schorpp
>> return (error);
>>
>> aic7xxx: pci_resource_start 0xffffff000 mem64 0x4
>> -----------------------------------------------^
>>
>> just to doublecheck the situation, posted lspci already.
>>
>> will check next, if
>> len = pci_resource_len(ahc->dev_softc, 1);
>> if (start != 0) {
>> *bus_addr = start;
>> // if (request_mem_region(start, 0x1000, "aic7xxx") == 0)
>> if (request_mem_region(start, len, "aic7xxx") == 0)
>>
>> succeeds.
>
> 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)
error = ENOMEM;
printk(KERN_WARNING "aic7xxx: req_mem_region start 0x%lx\n", \
ret1->start); //schorpp
if (error == 0) {
*maddr = ioremap_nocache(start, 256);
if (*maddr == NULL) {
error = ENOMEM;
release_mem_region(start, 0x1000);
}
}
} else
error = ENOMEM;
tom1:~# dmesg |grep aic
aic7xxx: DMA_32BIT_MASK
aic7xxx: req_mem_region start 0x30000000
aic7xxx: pci_resource_start 0x30000000 **maddr 0xff mem64 0x4
aic7xxx: PCI Device 0:6:0 failed memory mapped test. Using PIO.
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
tried the mem start value from lspci on a running knoppix and winxp,
but the if (ahc_pci_test_register_access(ahc) != 0) {
does not go.
thought the pci resources were constant and i could hardcode for my system ;)
remarkable is, with this mem start setting the kernel autofree(?) does not take action.
>
>>
>>>>> we've a bug in the x86_64 linux pci config, BIOS is ok, the
>>>>> hardware worked fine in a winxp_x64 test setup a few months ago.
>>>>>
>>>>> will ask LKML.
>>>>>
>>>>> y
>>>>> tom
>>>> sorry, wrong according to http://download.adaptec.com/pdfs/aic7892.pdf.
>>>>
>>>> "66 MHz, 64-bit, PCI interface that
>>>> supports zero wait-state memory;
>>>> also operates on 33 MHz, 32-bit
>>>> PCI busses"
>>>>
>>>> this chip is capable of 64bit addressing, as pci_resource_nnnn
>>>> (checking this) on x86_64 platform and lspci on x86_64 *and* AMDK7
>>>> configured kernels reports, even on PCI/32, right?
>>>> or is it impossible to do multiplexed 64bit mem addressing on PCI/32?
>>>
>>> It can only do 37 bit addressing ... only the aic79xx can do the full 64
>>> bits, so I suspect it should never get a 64 bit BAR, since it wouldn't
>>> be able to decode the full 32 bits. 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).
>>>
>>
>> ok, i trust in that. adaptor bios and mainboard bios *are* out,
>> winxp_x64 driver handled all.
>> so agree on kernel pci hal issue.
>> but what for const uint64_t mask_39bit = 0x7FFFFFFFFFULL;
>> then?
>>
>>>>
>>>> can adaptec.inc pls comment? since the aha19160 card is still in
>>>> production state, i assume they want to have a linux x86_64 dma
>>>> capable driver. so far it is not, or can other users having this
>>>> card pls confirm my pci system broken?
>>>
>>> James
>>>
>>>
>>
>> y
>> tom
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-24 0:51 ` thomas schorpp
@ 2007-03-24 1:17 ` James Bottomley
2007-03-24 3:44 ` thomas schorpp
0 siblings, 1 reply; 17+ messages in thread
From: James Bottomley @ 2007-03-24 1:17 UTC (permalink / raw)
To: t.schorpp; +Cc: SCSI development list
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-24 1:17 ` James Bottomley
@ 2007-03-24 3:44 ` thomas schorpp
2007-03-24 4:05 ` thomas schorpp
0 siblings, 1 reply; 17+ messages in thread
From: thomas schorpp @ 2007-03-24 3:44 UTC (permalink / raw)
To: SCSI development list
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...
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-24 3:44 ` thomas schorpp
@ 2007-03-24 4:05 ` thomas schorpp
2007-03-27 6:52 ` thomas schorpp
0 siblings, 1 reply; 17+ messages in thread
From: thomas schorpp @ 2007-03-24 4:05 UTC (permalink / raw)
To: SCSI development list
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-24 4:05 ` thomas schorpp
@ 2007-03-27 6:52 ` thomas schorpp
2007-03-29 20:13 ` thomas schorpp
0 siblings, 1 reply; 17+ messages in thread
From: thomas schorpp @ 2007-03-27 6:52 UTC (permalink / raw)
To: SCSI development list
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.
y
tom
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0!
2007-03-27 6:52 ` thomas schorpp
@ 2007-03-29 20:13 ` thomas schorpp
0 siblings, 0 replies; 17+ messages in thread
From: thomas schorpp @ 2007-03-29 20:13 UTC (permalink / raw)
To: SCSI development list; +Cc: 415864
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
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2007-03-29 20:13 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-22 15:14 aic7xxx: aic7892(B): BUG: soft lockup detected on CPU#0! thomas schorpp
2007-03-22 16:57 ` thomas schorpp
2007-03-22 21:02 ` thomas schorpp
2007-03-22 23:00 ` thomas schorpp
2007-03-23 1:26 ` thomas schorpp
2007-03-23 4:45 ` James Bottomley
2007-03-23 7:32 ` thomas schorpp
2007-03-23 16:28 ` thomas schorpp
2007-03-23 17:23 ` James Bottomley
2007-03-23 18:23 ` thomas schorpp
2007-03-23 18:59 ` thomas schorpp
2007-03-24 0:51 ` thomas schorpp
2007-03-24 1:17 ` James Bottomley
2007-03-24 3:44 ` thomas schorpp
2007-03-24 4:05 ` thomas schorpp
2007-03-27 6:52 ` thomas schorpp
2007-03-29 20:13 ` thomas schorpp
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.