Hi!
This is the second report of this error.
It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and
2.6.15-rc2.
It does not occur in 2.6.14.
Most easily triggered by "make clean" in the Linux source, for those of
you without access to dpkg. But both clean and dpkg will trigger it.
There are no oops.
I'm not sure what to report next, though If I were to guess it is a
interaction between XFS file system and SCSI. I've got another SCSI box
that is very similar that runs rc1, rc1-mm1 and rc1-mm2 just fine, the
only real difference being it has a ext3 file system instead.
The driver for the SCSI card (aic7xxx) did not appear change.
lspi says it's a Adaptec AIC-7892A U160/m (rev 2) card.
XFS looks like it's had extensive changes from 14 to 15-rc2.
There are many debugging options I could enable, but to be honest I'm not
sure what would be applicable in this circumstance.
Nothing in dmesg looks out of the ordinary.
Included version info, cpuinfo, module info, driver info (/proc/ioports /proc/iomem) pci info.
Questions, patches, flames are welcome.
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux guillemot 2.6.15-rc2 #2 Sat Nov 19 22:33:39 PST 2005 i686 GNU/Linux
Gnu C 4.0.3
Gnu make 3.80
binutils 2.16.91
util-linux 2.12p
mount 2.12p
module-init-tools 3.2-pre9
e2fsprogs 1.38
reiserfsprogs line
reiser4progs line
xfsprogs 2.7.7
quota-tools 3.13.
nfs-utils 1.0.7
Linux C Library 2.3.5
Dynamic linker (ldd) 2.3.5
Procps 3.2.6
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.93
udev 074
Modules Loaded radeon drm binfmt_misc lp thermal fan button processor ac battery ipv6 deflate zlib_deflate zlib_inflate twofish serpent aes_i586 blowfish des sha256 sha1 md5 crypto_null mii radeonfb usbhid eth1394 snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul ohci1394 ieee1394 sg st sr_mod cdrom snd_emu10k1 parport_pc snd_rawmidi snd_ac97_codec snd_ac97_bus parport snd_util_mem via_agp skge sata_via libata agpgart snd_hwdep ehci_hcd uhci_hcd
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(TM) XP 2800+
stepping : 0
cpu MHz : 2071.500
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips : 4146.41
radeon 106080 0 - Live 0xe1bff000
drm 63188 1 radeon, Live 0xe1b96000
binfmt_misc 8712 1 - Live 0xe0b6d000
lp 9220 0 - Live 0xe0b69000
thermal 10568 0 - Live 0xe0b65000
fan 3204 0 - Live 0xe0a76000
button 4752 0 - Live 0xe0b46000
processor 14252 1 thermal, Live 0xe0b52000
ac 3268 0 - Live 0xe0a70000
battery 7428 0 - Live 0xe0a66000
ipv6 233408 14 - Live 0xe1bc5000
deflate 2816 0 - Live 0xe0a6e000
zlib_deflate 22744 1 deflate, Live 0xe0b59000
zlib_inflate 17536 1 deflate, Live 0xe0b4c000
twofish 44352 0 - Live 0xe0b10000
serpent 24576 0 - Live 0xe0b3f000
aes_i586 37760 0 - Live 0xe0b34000
blowfish 8832 0 - Live 0xe0b04000
des 16064 0 - Live 0xe0b0b000
sha256 10432 0 - Live 0xe0a72000
sha1 2368 0 - Live 0xe0a6c000
md5 3712 1 - Live 0xe09fe000
crypto_null 2112 0 - Live 0xe0a05000
mii 4608 0 - Live 0xe0a69000
radeonfb 83392 1 - Live 0xe0b1e000
usbhid 51488 0 - Live 0xe0a78000
eth1394 17096 0 - Live 0xe0a4f000
snd_emu10k1_synth 6016 0 - Live 0xe0810000
snd_emux_synth 32960 1 snd_emu10k1_synth, Live 0xe09d2000
snd_seq_virmidi 5312 1 snd_emux_synth, Live 0xe0813000
snd_seq_midi_emul 6272 1 snd_emux_synth, Live 0xe084a000
ohci1394 30452 0 - Live 0xe09b8000
ieee1394 286776 2 eth1394,ohci1394, Live 0xe0a07000
sg 27100 2 - Live 0xe086b000
st 37152 0 - Live 0xe09a3000
sr_mod 15076 0 - Live 0xe08a7000
cdrom 35936 1 sr_mod, Live 0xe08e6000
snd_emu10k1 106980 1 snd_emu10k1_synth, Live 0xe08f5000
parport_pc 36548 1 - Live 0xe08b4000
snd_rawmidi 19488 2 snd_seq_virmidi,snd_emu10k1, Live 0xe08a1000
snd_ac97_codec 87392 1 snd_emu10k1, Live 0xe08be000
snd_ac97_bus 1792 1 snd_ac97_codec, Live 0xe0869000
parport 32456 2 lp,parport_pc, Live 0xe0874000
snd_util_mem 3392 2 snd_emux_synth,snd_emu10k1, Live 0xe0855000
via_agp 7552 1 - Live 0xe0861000
skge 32848 0 - Live 0xe0857000
sata_via 5828 0 - Live 0xe0847000
libata 50828 1 sata_via, Live 0xe0825000
agpgart 27528 2 drm,via_agp, Live 0xe083f000
snd_hwdep 7008 2 snd_emux_synth,snd_emu10k1, Live 0xe0816000
ehci_hcd 43080 0 - Live 0xe0833000
uhci_hcd 29900 0 - Live 0xe081a000
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0290-0297 : pnp 00:0c
02f8-02ff : serial
0370-0375 : pnp 00:0c
0378-037a : parport0
03c0-03df : vga+
03f8-03ff : serial
0778-077a : parport0
0cf8-0cff : PCI conf1
6800-68ff : 0000:00:13.0
7000-701f : 0000:00:10.3
7000-701f : uhci_hcd
7400-741f : 0000:00:10.2
7400-741f : uhci_hcd
7800-781f : 0000:00:10.1
7800-781f : uhci_hcd
8000-801f : 0000:00:10.0
8000-801f : uhci_hcd
8400-840f : 0000:00:0f.1
8800-88ff : 0000:00:0f.0
8800-88ff : sata_via
9000-900f : 0000:00:0f.0
9000-900f : sata_via
9400-9403 : 0000:00:0f.0
9400-9403 : sata_via
9800-9807 : 0000:00:0f.0
9800-9807 : sata_via
a000-a003 : 0000:00:0f.0
a000-a003 : sata_via
a400-a407 : 0000:00:0f.0
a400-a407 : sata_via
a800-a8ff : 0000:00:0d.0
a800-a8ff : sym53c8xx
b000-b007 : 0000:00:0b.1
b400-b43f : 0000:00:0b.0
b400-b43f : EMU10K1
b800-b8ff : 0000:00:09.0
b800-b8ff : skge
d000-dfff : PCI Bus #01
d800-d8ff : 0000:01:00.0
e400-e47f : motherboard
e400-e403 : PM1a_EVT_BLK
e404-e405 : PM1a_CNT_BLK
e408-e40b : PM_TMR
e420-e423 : GPE0_BLK
e800-e81f : motherboard
e800-e81f : pnp 00:01
00000000-0009f7ff : System RAM
0009f800-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000ccfff : Video ROM
000d8000-000d81ff : Adapter ROM
000dc000-000e13ff : Adapter ROM
000f0000-000fffff : System ROM
00100000-1fffafff : System RAM
00100000-0039fec6 : Kernel code
0039fec7-0047db1f : Kernel data
1fffb000-1fffefff : ACPI Tables
1ffff000-1fffffff : ACPI Non-volatile Storage
30000000-3001ffff : 0000:00:13.0
30020000-3002ffff : 0000:00:0d.0
bb000000-bb000fff : 0000:00:13.0
bb000000-bb000fff : aic7xxx
bb800000-bb8000ff : 0000:00:10.4
bb800000-bb8000ff : ehci_hcd
bc000000-bc000fff : 0000:00:0d.0
bc000000-bc000fff : sym53c8xx
bc800000-bc8000ff : 0000:00:0d.0
bc800000-bc8000ff : sym53c8xx
bd000000-bd003fff : 0000:00:0b.2
bd800000-bd8007ff : 0000:00:0b.2
bd800000-bd8007ff : ohci1394
be000000-be003fff : 0000:00:09.0
be000000-be003fff : skge
be800000-bfefffff : PCI Bus #01
be800000-be80ffff : 0000:01:00.1
bf000000-bf00ffff : 0000:01:00.0
bf000000-bf00ffff : radeonfb mmio
c0000000-efffffff : PCI Bus #01
c0000000-cfffffff : 0000:01:00.1
dffe0000-dfffffff : 0000:01:00.0
e0000000-efffffff : 0000:01:00.0
e0000000-efffffff : radeonfb framebuffer
f0000000-f7ffffff : 0000:00:00.0
fec00000-fec00fff : reserved
fee00000-fee00fff : reserved
ffff0000-ffffffff : reserved
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80)
Subsystem: ASUSTeK Computer Inc. A7V8X motherboard
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: 0
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
Capabilities: <available only to root>
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 [Normal decode])
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: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: be800000-bfefffff
Prefetchable memory behind bridge: c0000000-efffffff
BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
Capabilities: <available only to root>
0000:00:09.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12)
Subsystem: ASUSTeK Computer Inc. P4P800/K8V Deluxe motherboard
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 (5750ns min, 7750ns max), Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 16
Region 0: Memory at be000000 (32-bit, non-prefetchable) [size=16K]
Region 1: I/O ports at b800 [size=256]
Capabilities: <available only to root>
0000:00:0b.0 Multimedia audio controller: Creative Labs SB Audigy (rev 04)
Subsystem: Creative Labs SB Audigy 2 ZS (SB0350)
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 (500ns min, 5000ns max)
Interrupt: pin A routed to IRQ 20
Region 0: I/O ports at b400 [size=64]
Capabilities: <available only to root>
0000:00:0b.1 Input device controller: Creative Labs SB Audigy MIDI/Game port (rev 04)
Subsystem: Creative Labs SB Audigy MIDI/Game Port
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
Region 0: I/O ports at b000 [size=8]
Capabilities: <available only to root>
0000:00:0b.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port (rev 04) (prog-if 10 [OHCI])
Subsystem: Creative Labs SB Audigy FireWire Port
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 (500ns min, 1000ns max), Cache Line Size: 0x08 (32 bytes)
Interrupt: pin B routed to IRQ 17
Region 0: Memory at bd800000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at bd000000 (32-bit, non-prefetchable) [size=16K]
Capabilities: <available only to root>
0000:00:0d.0 SCSI storage controller: LSI Logic / Symbios Logic 53c895 (rev 01)
Subsystem: Tekram Technology Co.,Ltd. DC-390U2W
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 (7500ns min, 16000ns max), Cache Line Size: 0x10 (64 bytes)
Interrupt: pin A routed to IRQ 17
Region 0: I/O ports at a800 [size=256]
Region 1: Memory at bc800000 (32-bit, non-prefetchable) [size=256]
Region 2: Memory at bc000000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at 30020000 [disabled] [size=64K]
0000:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
Subsystem: ASUSTeK Computer Inc. A7V600/K8V Deluxe/K8V-X motherboard
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
Interrupt: pin B routed to IRQ 19
Region 0: I/O ports at a400 [size=8]
Region 1: I/O ports at a000 [size=4]
Region 2: I/O ports at 9800 [size=8]
Region 3: I/O ports at 9400 [size=4]
Region 4: I/O ports at 9000 [size=16]
Region 5: I/O ports at 8800 [size=256]
Capabilities: <available only to root>
0000:00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Subsystem: ASUSTeK Computer Inc. A7V600/K8V-X motherboard
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-
Interrupt: pin A routed to IRQ 14
Region 4: I/O ports at 8400 [disabled] [size=16]
Capabilities: <available only to root>
0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. A7V600/K8V-X motherboard
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, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 18
Region 4: I/O ports at 8000 [size=32]
Capabilities: <available only to root>
0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. A7V600/K8V-X motherboard
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, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 18
Region 4: I/O ports at 7800 [size=32]
Capabilities: <available only to root>
0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. A7V600/K8V-X motherboard
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, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin B routed to IRQ 18
Region 4: I/O ports at 7400 [size=32]
Capabilities: <available only to root>
0000:00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. A7V600/K8V-X motherboard
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, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin B routed to IRQ 18
Region 4: I/O ports at 7000 [size=32]
Capabilities: <available only to root>
0000:00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. A7V600/K8V-X motherboard
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, Cache Line Size: 0x10 (64 bytes)
Interrupt: pin C routed to IRQ 18
Region 0: Memory at bb800000 (32-bit, non-prefetchable) [size=256]
Capabilities: <available only to root>
0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
Subsystem: ASUSTeK Computer Inc. A7V600/K8V-X motherboard
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: 0
Capabilities: <available only to root>
0000:00:13.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02)
Subsystem: Adaptec 29160 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: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 16
BIST result: 00
Region 0: I/O ports at 6800 [disabled] [size=256]
Region 1: Memory at bb000000 (64-bit, non-prefetchable) [size=4K]
Expansion ROM at 30000000 [disabled] [size=128K]
Capabilities: <available only to root>
0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AP [Radeon 9600] (prog-if 00 [VGA])
Subsystem: Giga-byte Technology: Unknown device 4022
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: 64 (2000ns min), Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 17
Region 0: Memory at e0000000 (32-bit, prefetchable) [size=256M]
Region 1: I/O ports at d800 [size=256]
Region 2: Memory at bf000000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at dffe0000 [disabled] [size=128K]
Capabilities: <available only to root>
0000:01:00.1 Display controller: ATI Technologies Inc RV350 AP [Radeon 9600] (Secondary)
Subsystem: Giga-byte Technology: Unknown device 4023
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: 64 (2000ns min), Cache Line Size: 0x08 (32 bytes)
Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M]
Region 1: Memory at be800000 (32-bit, non-prefetchable) [size=64K]
Capabilities: <available only to root>
--
*--* Mail: [email protected]
*--* Voice: 425.739.4247
*--* Fax: 425.827.9577
*--* HTTP://the-penguin.otak.com/~lawrence
--------------------------------------
- - - - - - O t a k i n c . - - - - -
Hi there,
On Sat, Nov 19, 2005 at 11:52:33PM -0800, Lawrence Walton wrote:
> Hi!
>
> This is the second report of this error.
Please CC linux-xfs if you want to be sure XFS people see your
report.
> It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and
> 2.6.15-rc2.
>
> It does not occur in 2.6.14.
>
> Most easily triggered by "make clean" in the Linux source, for those of
> you without access to dpkg. But both clean and dpkg will trigger it.
So far I've not been able to reproduce this; I'm using "make clean"
and it works just fine for me (I'm using the current git tree).
> There are no oops.
No, it looks like XFS is stuck waiting for an IO to complete.
> I'm not sure what to report next, though If I were to guess it is a
> interaction between XFS file system and SCSI. I've got another SCSI box
> that is very similar that runs rc1, rc1-mm1 and rc1-mm2 just fine, the
> only real difference being it has a ext3 file system instead.
>
> The driver for the SCSI card (aic7xxx) did not appear change.
> lspi says it's a Adaptec AIC-7892A U160/m (rev 2) card.
>From your earlier report with the stack traces included, it looks
like XFS is waiting for a log write to complete, but it never
does (which is not valid driver behaviour). I'm using the sym53c8xx
driver in my testing BTW, which is different to you, so maybe see if
this still happens for you with different hardware? (if you can).
> Questions, patches, flames are welcome.
You could also try to drop the XFS (fs/xfs) code from 2.6.14 into
2.6.15-rc2 and see if your problem persists. There isn't anything
I can see from scanning though everything we committed into .15 so
far that would explain this. Oh, an easier test you could do would
be to try XFS CVS from oss.sgi.com - that has 2.6.14 + all the XFS
changes since then, so that should confirm/deny an XFS regression
too. Thanks!
cheers.
--
Nathan
Just another data point, running 2615rc1/2 I do not have an issue with XFS runing on MPT scsi device.
-----Original Message-----
From: [email protected] on behalf of Nathan Scott
Sent: Sun 20-Nov-05 15:08
To: Lawrence Walton
Cc: linux-kernel; [email protected]
Subject: Re: unable to use dpkg 2.6.15-rc2
Hi there,
On Sat, Nov 19, 2005 at 11:52:33PM -0800, Lawrence Walton wrote:
> Hi!
>
> This is the second report of this error.
Please CC linux-xfs if you want to be sure XFS people see your
report.
> It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and
> 2.6.15-rc2.
>
> It does not occur in 2.6.14.
>
> Most easily triggered by "make clean" in the Linux source, for those of
> you without access to dpkg. But both clean and dpkg will trigger it.
So far I've not been able to reproduce this; I'm using "make clean"
and it works just fine for me (I'm using the current git tree).
> There are no oops.
No, it looks like XFS is stuck waiting for an IO to complete.
> I'm not sure what to report next, though If I were to guess it is a
> interaction between XFS file system and SCSI. I've got another SCSI box
> that is very similar that runs rc1, rc1-mm1 and rc1-mm2 just fine, the
> only real difference being it has a ext3 file system instead.
>
> The driver for the SCSI card (aic7xxx) did not appear change.
> lspi says it's a Adaptec AIC-7892A U160/m (rev 2) card.
>From your earlier report with the stack traces included, it looks
like XFS is waiting for a log write to complete, but it never
does (which is not valid driver behaviour). I'm using the sym53c8xx
driver in my testing BTW, which is different to you, so maybe see if
this still happens for you with different hardware? (if you can).
> Questions, patches, flames are welcome.
You could also try to drop the XFS (fs/xfs) code from 2.6.14 into
2.6.15-rc2 and see if your problem persists. There isn't anything
I can see from scanning though everything we committed into .15 so
far that would explain this. Oh, an easier test you could do would
be to try XFS CVS from oss.sgi.com - that has 2.6.14 + all the XFS
changes since then, so that should confirm/deny an XFS regression
too. Thanks!
cheers.
--
Nathan
From: "Nathan Scott" <[email protected]>
> > It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and
> > 2.6.15-rc2.
> >
> > It does not occur in 2.6.14.
> >
> > Most easily triggered by "make clean" in the Linux source, for those of
> > you without access to dpkg. But both clean and dpkg will trigger it.
>
> So far I've not been able to reproduce this; I'm using "make clean"
> and it works just fine for me (I'm using the current git tree).
I can reproduce this using with 2.6.15-rc1 using AIM7 or AIM9. I forced a
corefile for one of the AIM7 threads that hung during close doing the disk_cp
subtest. The AIM9 run hung doing disk_src (running each subtest for 100
seconds). I didn't coredump that one, but rather I got into kdb and did a
backtrace on the AIM9 "singleuser" thread.
[1]kdb> btp 16155
Stack traceback for pid 16155
0xe000003864630000 16155 16116 0 1 D 0xe000003864630330
singleuser
0xa000000100778800 schedule+0x1300
args (0xe000003864637b10, 0x7fffffffffffffff, 0xa00000010039c710,
0xa00000010077d740, 0x205)
0xa00000010077b430 schedule_timeout+0x170
args (0x7fffffffffffffff, 0xa00000010039c6f0, 0xa00000010095c680,
0xa00000010039c710, 0x60f)
0xa00000010039c710 xlog_grant_log_space+0x670
args (0xe00000347a9a6100, 0xe00000347a9db2c0, 0xa0000001008c57e0,
0xe000003864637b70, 0xe00000347a9db2f7)
0xa000000100397760 xfs_log_reserve+0x1c0
args (0xe00000347a9db2c0, 0x0, 0x2, 0xe0000038624d23d8, 0x69)
0xa0000001003b11c0 xfs_trans_reserve+0xe0
args (0xe0000038624d2388, 0x29, 0x268b8, 0x0, 0x4)
0xa0000001003c2e50 xfs_create+0x550
args (0xe000003c6cbaa0c8, 0xe0000038625b17ec, 0xe000003864637c30,
0xe000003864637db0, 0x0)
0xa0000001003dcbd0 linvfs_mknod+0x630
args (0xe000003c6de8a6e8, 0xe0000038625b1730, 0x81ed, 0x0, 0x0)
0xa0000001003dcd30 linvfs_create+0x30
args (0xe000003c6de8a6e8, 0xe0000038625b1730, 0x81ff,
0xa000000100191dc0, 0x40c)
0xa000000100191dc0 vfs_create+0x1c0
args (0xe000003c6de8a6e8, 0xe0000038625b1730, 0x81ff,
0xe0000038625b1768, 0xa000000100d35550)
0xa0000001001933c0 open_namei+0xea0
args (0xe0000038625b1730, 0x8242, 0x1ff, 0xe000003864637dd0,
0xe0000038625b35e0)
0xa000000100168a80 filp_open+0x40
args (0xe0000038604df000, 0x8241, 0x1ff, 0xa0000001001692b0, 0x38b)
0xa0000001001692b0 do_sys_open+0xb0
args (0xe0000038604df000, 0x8241, 0x20, 0xfffffffffffffc18, 0x5)
0xa000000100169430 sys_open+0x50
args (0x600000000005b180, 0x241, 0x1ff, 0x0, 0x8)
0xa000000100169490 sys_creat+0x30
args (0x600000000005b180, 0x1ff, 0x607fffffffd394a0,
0xc00000000000048d, 0x600000000005a9c0)
0xa00000010000b800 ia64_ret_from_syscall
args (0x600000000005b180, 0x1ff, 0x607fffffffd394a0,
0xc00000000000048d)
0xa000000000004000 __kernel_syscall_via_break
args (0x600000000005b180, 0x1ff, 0x607fffffffd394a0,
0xc00000000000048d)
(please CC me, I'm not subscribed)
Nathan Scott <[email protected]> ha scritto:
>> It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and
>> 2.6.15-rc2.
>>
>> It does not occur in 2.6.14.
>>
>> Most easily triggered by "make clean" in the Linux source, for those of
>> you without access to dpkg. But both clean and dpkg will trigger it.
>
> So far I've not been able to reproduce this; I'm using "make clean"
> and it works just fine for me (I'm using the current git tree).
Confirmed here with 2.6.15-rc1 an IDE disk. Kernel is UP with
CONFIG_PREEMPT and 8KB stack. The following debug options are enabled:
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_FRAME_POINTER=y
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
should I try and enable something else to gather more informations?
The first time the system hung during shutdown, with kernel stuck in
pdflush (probably waked up by sync):
pdflush D E3A593A8 0 27641 6 27650 1233 (L-TLB)
d6a099fc 00000001 00000003 e3a593a8 00000296 00000001 d6a099d8 c01174af
00000000 00000000 d0cb7570 0001226c 268d47fe 00001648 cc890590 cc8906b8
7fffffff eef27240 d6a09a68 d6a09a38 c030a734 efa70c00 d6a09a18 d6a09a1c
Call Trace:
[<c030a734>] schedule_timeout+0x94/0xa0
[<f1a693ed>] xlog_grant_log_space+0x1dd/0x370 [xfs]
[<f1a66e57>] xfs_log_reserve+0x77/0xb0 [xfs]
[<f1a74b8c>] xfs_trans_reserve+0x7c/0x1a0 [xfs]
[<f1a6457c>] xfs_iomap_write_allocate+0x10c/0x4d0 [xfs]
[<f1a635de>] xfs_iomap+0x3be/0x470 [xfs]
[<f1a8abdc>] xfs_bmap+0x2c/0x40 [xfs]
[<f1a824ac>] xfs_map_blocks+0x3c/0x90 [xfs]
[<f1a83460>] xfs_page_state_convert+0x4e0/0x610 [xfs]
[<f1a83c1e>] linvfs_writepage+0x5e/0xf0 [xfs]
[<c0180782>] mpage_writepages+0x242/0x3d0
[<c01417da>] do_writepages+0x2a/0x30
[<c017ec50>] __sync_single_inode+0x70/0x200
[<c017eea4>] __writeback_single_inode+0xc4/0x1a0
[<c017f0e7>] sync_sb_inodes+0x167/0x2c0
[<c017f335>] writeback_inodes+0xf5/0x140
[<c01415d2>] wb_kupdate+0xb2/0x130
[<c0141f65>] __pdflush+0xd5/0x200
[<c01420b9>] pdflush+0x29/0x30
[<c012f735>] kthread+0x95/0xd0
[<c01013cd>] kernel_thread_helper+0x5/0x18
The second time happened while I was doing a "rm -rf" of a kernel tree:
rm D E4913E38 0 2831 2825 (NOTLB)
e4cefdb0 00000001 00000003 e4913e38 00000296 00000003 e4cefd8c c01174af
00000000 00000000 e4b3e030 0005f191 cdb3c946 00000028 e4c98090 e4c981b8
7fffffff ef1069d8 e4cefe1c e4cefdec c030a734 eee2f800 e4cefdcc e4cefdd0
Call Trace:
[<c030a734>] schedule_timeout+0x94/0xa0
[<f1a693ed>] xlog_grant_log_space+0x1dd/0x370 [xfs]
[<f1a66e57>] xfs_log_reserve+0x77/0xb0 [xfs]
[<f1a74b8c>] xfs_trans_reserve+0x7c/0x1a0 [xfs]
[<f1a7d2ad>] xfs_inactive+0x34d/0x4d0 [xfs]
[<f1a8b618>] linvfs_clear_inode+0x68/0x90 [xfs]
[<c01748a4>] clear_inode+0xf4/0x100
[<c01759fd>] generic_delete_inode+0xed/0x110
[<c0175bcf>] generic_drop_inode+0xf/0x20
[<c0175c36>] iput+0x56/0x80
[<c016b13c>] sys_unlink+0xcc/0x120
[<c01031c5>] syscall_call+0x7/0xb
At the time of the rm -rf the partition was somewhat full:
root@dreamland:~# df /usr
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda8 33996740 33549488 447252 99% /usr
root@dreamland:~# df -i /usr
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/hda8 1997584 148695 1848889 8% /usr
The first time there was a lot more of free space though (a couple of
GB).
> From your earlier report with the stack traces included, it looks
> like XFS is waiting for a log write to complete, but it never
> does (which is not valid driver behaviour). I'm using the sym53c8xx
> driver in my testing BTW, which is different to you, so maybe see if
> this still happens for you with different hardware? (if you can).
Here it happens with an IDE disk, connected to VT8233A southbridge.
Luca
--
Home: http://kronoz.cjb.net
Carpe diem, quam minimum credula postero. (Q. Horatius Flaccus)
On Tue, Nov 22, 2005 at 06:20:27PM +0100, Luca wrote:
> (please CC me, I'm not subscribed)
>
> Nathan Scott <[email protected]> ha scritto:
> >> It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and
> >> 2.6.15-rc2.
> >>
> >> It does not occur in 2.6.14.
> >>
> >> Most easily triggered by "make clean" in the Linux source, for those of
> >> you without access to dpkg. But both clean and dpkg will trigger it.
> >
> > So far I've not been able to reproduce this; I'm using "make clean"
> > and it works just fine for me (I'm using the current git tree).
>
> Confirmed here with 2.6.15-rc1 an IDE disk. Kernel is UP with
> CONFIG_PREEMPT and 8KB stack. The following debug options are enabled:
>
Keith Owens has managed to reproduce this locally, and has been
working on tracking it back to a single change - so, we'll start
trying to figure out whats gone wrong here shortly, and will get
a fix merged as soon as we can.
Thanks for reporting the problem.
cheers.
--
Nathan
On Wed, Nov 23, 2005 at 08:44:43AM +1100, Nathan Scott wrote:
> On Tue, Nov 22, 2005 at 06:20:27PM +0100, Luca wrote:
> > (please CC me, I'm not subscribed)
> >
> > Nathan Scott <[email protected]> ha scritto:
> > >> It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and
> > >> 2.6.15-rc2.
> > >>
> > >> It does not occur in 2.6.14.
> > >>
> > >> Most easily triggered by "make clean" in the Linux source, for those of
> > >> you without access to dpkg. But both clean and dpkg will trigger it.
> > >
> > > So far I've not been able to reproduce this; I'm using "make clean"
> > > and it works just fine for me (I'm using the current git tree).
> >
> > Confirmed here with 2.6.15-rc1 an IDE disk. Kernel is UP with
> > CONFIG_PREEMPT and 8KB stack. The following debug options are enabled:
> >
>
> Keith Owens has managed to reproduce this locally, and has been
> working on tracking it back to a single change - so, we'll start
> trying to figure out whats gone wrong here shortly, and will get
> a fix merged as soon as we can.
FYI - this problem is now fixed in Linus' current git tree.
cheers.
--
Nathan
Il Mon, Nov 28, 2005 at 11:23:50AM +1100, Nathan Scott ha scritto:
> On Wed, Nov 23, 2005 at 08:44:43AM +1100, Nathan Scott wrote:
> > On Tue, Nov 22, 2005 at 06:20:27PM +0100, Luca wrote:
> > > (please CC me, I'm not subscribed)
> > >
> > > Nathan Scott <[email protected]> ha scritto:
> > > >> It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and
> > > >> 2.6.15-rc2.
> > > >>
> > > >> It does not occur in 2.6.14.
> > > >>
> > > >> Most easily triggered by "make clean" in the Linux source, for those of
> > > >> you without access to dpkg. But both clean and dpkg will trigger it.
> > > >
> > > > So far I've not been able to reproduce this; I'm using "make clean"
> > > > and it works just fine for me (I'm using the current git tree).
> > >
> > > Confirmed here with 2.6.15-rc1 an IDE disk. Kernel is UP with
> > > CONFIG_PREEMPT and 8KB stack. The following debug options are enabled:
> > >
> >
> > Keith Owens has managed to reproduce this locally, and has been
> > working on tracking it back to a single change - so, we'll start
> > trying to figure out whats gone wrong here shortly, and will get
> > a fix merged as soon as we can.
>
> FYI - this problem is now fixed in Linus' current git tree.
Great, I'll give it a try ASAP. BTW why using a macro instead of an
inline function makes any difference? I don't understand...
Luca
--
Home: http://kronoz.cjb.net
"Su cio` di cui non si puo` parlare e` bene tacere".
Ludwig Wittgenstein
On Tue, Nov 29, 2005 at 05:21:06PM +0100, Luca wrote:
>
> Great, I'll give it a try ASAP. BTW why using a macro instead of an
> inline function makes any difference? I don't understand...
>
The initial conversion from macro ->inline was subtely broken
(macro changed the value of a parameter, not picked up in the
conversion), so we reverted that change for now.
cheers.
--
Nathan