Processes receive SIGSEGV if TCQ is enabled

Processes receive SIGSEGV if TCQ is enabled

[Thomas Schlichter]

[-- Attachment #1.1: Type: text/plain, Size: 3216 bytes --]

Hello,

today I tried to test TCQ with the linux-2.6.0-test9-mm1 kernel. The config.gz 
is attached. But after enabling TCQ with 'hdparm -Q1 /dev/hda' newly started 
processes die due to a received SIGSEGV. No bad kernel messages appear...

Disabling TCQ again doesn't help, only e reboot does...
When I let the kernel enable TCQ at boot time, it set the TCQ buffer depth to 
8 and even the init script was killed!

Here some additional information:

schlicht@bigboss:~> uname -a
Linux bigboss 2.6.0-test9-mm1 #1 Thu Oct 30 14:45:35 CET 2003 i686 unknown 
unknown GNU/Linux
schlicht@bigboss:~> hdparm -i /dev/hda

/dev/hda:

 Model=IBM-DTLA-307030, FwRev=TX4OA50C, SerialNo=YK0YKT61943
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
 BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=60036480
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1:

 * signifies the current active mode

schlicht@bigboss:~> hdparm -i /dev/hdb
/dev/hdb: No such device or address
schlicht@bigboss:~> cat /proc/ide/via
----------VIA BusMastering IDE Configuration----------------
Driver Version:                     3.38
South Bridge:                       VIA vt8235
Revision:                           ISA 0x0 IDE 0x6
Highest DMA rate:                   UDMA133
BM-DMA base:                        0xec00
PCI clock:                          33.3MHz
Master Read  Cycle IRDY:            0ws
Master Write Cycle IRDY:            0ws
BM IDE Status Register Read Retry:  yes
Max DRDY Pulse Width:               No limit
-----------------------Primary IDE-------Secondary IDE------
Read DMA FIFO flush:          yes                 yes
End Sector FIFO flush:         no                  no
Prefetch Buffer:              yes                 yes
Post Write Buffer:            yes                 yes
Enabled:                      yes                 yes
Simplex only:                  no                  no
Cable Type:                   80w                 40w
-------------------drive0----drive1----drive2----drive3-----
Transfer Mode:       UDMA       PIO       DMA      UDMA
Address Setup:      120ns     120ns     120ns     120ns
Cmd Active:          90ns      90ns      90ns      90ns
Cmd Recovery:        30ns      30ns      30ns      30ns
Data Active:         90ns     330ns      90ns      90ns
Data Recovery:       30ns     270ns      30ns      30ns
Cycle Time:          22ns     600ns     120ns      60ns
Transfer Rate:   88.8MB/s   3.3MB/s  16.6MB/s  33.3MB/s
schlicht@bigboss:~> mount
/dev/hda5 on / type reiserfs (rw)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
sysfs on /sys type sysfs (rw)
tmpfs on /tmp type tmpfs (rw)


Regards
   Thomas

P.S.: My hdparm version v5.4 sets the queuing depth only to 1 even if I 
provide e.g. '-Q8'...

[-- Attachment #1.2: config.gz --]
[-- Type: application/x-gzip, Size: 13517 bytes --]

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Processes receive SIGSEGV if TCQ is enabled

[Bartlomiej Zolnierkiewicz]

[ Jens - IDE TCQ maintainer 8) added to cc: ]

On Thursday 30 of October 2003 16:01, Thomas Schlichter wrote:
> Hello,

Hi,

Could you also send dmesg output and retry with vanilla -test9?

--bartlomiej

> today I tried to test TCQ with the linux-2.6.0-test9-mm1 kernel. The
> config.gz is attached. But after enabling TCQ with 'hdparm -Q1 /dev/hda'
> newly started processes die due to a received SIGSEGV. No bad kernel
> messages appear...
>
> Disabling TCQ again doesn't help, only e reboot does...
> When I let the kernel enable TCQ at boot time, it set the TCQ buffer depth
> to 8 and even the init script was killed!

Re: Processes receive SIGSEGV if TCQ is enabled

[Andrew Morton]

Thomas Schlichter <schlicht@uni-mannheim.de> wrote:
>
>  today I tried to test TCQ with the linux-2.6.0-test9-mm1 kernel. The config.gz 
>  is attached. But after enabling TCQ with 'hdparm -Q1 /dev/hda' newly started 
>  processes die due to a received SIGSEGV. No bad kernel messages appear...

Probably we need to turn off TCQ in kernel config until the confidence
level is higher.

>  Disabling TCQ again doesn't help, only e reboot does...

That will be because you have incorrect program text in pagecache, left
over from when the driver was in TCQ mode.

Re: Processes receive SIGSEGV if TCQ is enabled

[Thomas Schlichter]

[-- Attachment #1.1: Type: text/plain, Size: 1541 bytes --]

Hello again...

On Thursday 30 October 2003 22:33, Andrew Morton wrote:
> Thomas Schlichter <schlicht@uni-mannheim.de> wrote:
> >  today I tried to test TCQ with the linux-2.6.0-test9-mm1 kernel. The
> > config.gz is attached. But after enabling TCQ with 'hdparm -Q1 /dev/hda'
> > newly started processes die due to a received SIGSEGV. No bad kernel
> > messages appear...
>
> Probably we need to turn off TCQ in kernel config until the confidence
> level is higher.
>
> >  Disabling TCQ again doesn't help, only e reboot does...
>
> That will be because you have incorrect program text in pagecache, left
> over from when the driver was in TCQ mode.

Yes, that would explan it...

Well, I tested it with vanilla test9 and it has exaclty the same problems with 
TCQ here as test9-mm1 has. This means:

- TCQ enabled at boot time (TCQ depth is set to 8) kills the init script
- TCQ set to 1 with hdparm kills nearly everything
- TCQ set to 8 kills just some programms
- TCQ set to 32 seems to work

Attached is the dmesg from vanilla test9 where I set the TCQ depth to 32. If I 
set it to 1 the messages are the same (as explained in my original mail, 
there is no warning or error in the logs) except 'hda: tagged command 
queueing enabled, command queue depth 32' will be 'hda: tagged command 
queueing enabled, command queue depth 1'...

Btw. hdparam correctly sets the TCQ buffer depth, but TCQ always has to be 
disabled before setting an other TCQ depth, that confused me... ;-)

Regards
   Thomas

[-- Attachment #1.2: dmesg --]
[-- Type: text/plain, Size: 15707 bytes --]

0000000) @ 0x0fff3040
ACPI: MADT (v001 KT400  AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x0fff7000
ACPI: DSDT (v001 KT400  AWRDACPI 0x00001000 MSFT 0x0100000d) @ 0x00000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:7 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] polarity[0x1] trigger[0x1] lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0])
IOAPIC[0]: Assigned apic_id 2
IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, IRQ 0-23
ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0] trigger[0x0])
ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x0] trigger[0x0])
ACPI: INT_SRC_OVR (bus[0] irq[0xe] global_irq[0xe] polarity[0x1] trigger[0x1])
ACPI: INT_SRC_OVR (bus[0] irq[0xf] global_irq[0xf] polarity[0x1] trigger[0x1])
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Building zonelist for node : 0
Kernel command line: auto BOOT_IMAGE=linux ro root=305 BOOT_FILE=/boot/vmlinuz video=vesafb:mtrr,pmipal,ywrap
Initializing CPU#0
PID hash table entries: 1024 (order 10: 8192 bytes)
Detected 1307.337 MHz processor.
Console: colour dummy device 80x25
Memory: 255656k/262080k available (1880k kernel code, 5696k reserved, 809k data, 192k init, 0k highmem)
Calibrating delay loop... 2572.28 BogoMIPS
Security Scaffold v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU:     After generic identify, caps: 0383fbff c1c3fbff 00000000 00000000
CPU:     After vendor identify, caps: 0383fbff c1c3fbff 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 64K (64 bytes/line)
CPU:     After all inits, caps: 0383fbff c1c3fbff 00000000 00000020
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Duron(tm) processor stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
ENABLING IO-APIC IRQs
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=-1
number of MP IRQ sources: 15.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 00178003
.......     : max redirection entries: 0017
.......     : PRQ implemented: 1
.......     : IO APIC version: 0003
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 001 01  0    0    0   0   0    1    1    39
 02 001 01  0    0    0   0   0    1    1    31
 03 001 01  0    0    0   0   0    1    1    41
 04 001 01  0    0    0   0   0    1    1    49
 05 001 01  0    0    0   0   0    1    1    51
 06 001 01  0    0    0   0   0    1    1    59
 07 001 01  0    0    0   0   0    1    1    61
 08 001 01  0    0    0   0   0    1    1    69
 09 001 01  0    0    0   0   0    1    1    71
 0a 001 01  0    0    0   0   0    1    1    79
 0b 001 01  0    0    0   0   0    1    1    81
 0c 001 01  0    0    0   0   0    1    1    89
 0d 001 01  0    0    0   0   0    1    1    91
 0e 001 01  0    0    0   0   0    1    1    99
 0f 001 01  0    0    0   0   0    1    1    A1
 10 000 00  1    0    0   0   0    0    0    00
 11 000 00  1    0    0   0   0    0    0    00
 12 000 00  1    0    0   0   0    0    0    00
 13 000 00  1    0    0   0   0    0    0    00
 14 000 00  1    0    0   0   0    0    0    00
 15 000 00  1    0    0   0   0    0    0    00
 16 000 00  1    0    0   0   0    0    0    00
 17 000 00  1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1306.0989 MHz.
..... host bus clock speed is 201.0075 MHz.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb3b0, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20031002
IOAPIC[0]: Set PCI routing entry (2-9 -> 0x71 -> IRQ 9 Mode:0 Active:0)
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [ALKA] (IRQs 20)
ACPI: PCI Interrupt Link [ALKB] (IRQs 21)
ACPI: PCI Interrupt Link [ALKC] (IRQs 22)
ACPI: PCI Interrupt Link [ALKD] (IRQs 23)
Linux Plug and Play Support v0.97 (c) Adam Belay
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fbe80
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xbeb0, dseg 0xf0000
PnPBIOS: 15 nodes reported by PnP BIOS; 15 recorded by driver
IOAPIC[0]: Set PCI routing entry (2-16 -> 0xa9 -> IRQ 16 Mode:1 Active:1)
00:00:08[A] -> 2-16 -> IRQ 16
IOAPIC[0]: Set PCI routing entry (2-17 -> 0xb1 -> IRQ 17 Mode:1 Active:1)
00:00:08[B] -> 2-17 -> IRQ 17
IOAPIC[0]: Set PCI routing entry (2-18 -> 0xb9 -> IRQ 18 Mode:1 Active:1)
00:00:08[C] -> 2-18 -> IRQ 18
IOAPIC[0]: Set PCI routing entry (2-19 -> 0xc1 -> IRQ 19 Mode:1 Active:1)
00:00:08[D] -> 2-19 -> IRQ 19
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
_CRS returns NULL! Using IRQ 21 for device (PCI Interrupt Link [ALKB]).
ACPI: PCI Interrupt Link [ALKB] enabled at IRQ 21
IOAPIC[0]: Set PCI routing entry (2-21 -> 0xc9 -> IRQ 21 Mode:1 Active:1)
00:00:10[A] -> 2-21 -> IRQ 21
Pin 2-21 already programmed
Pin 2-21 already programmed
Pin 2-21 already programmed
_CRS returns NULL! Using IRQ 20 for device (PCI Interrupt Link [ALKA]).
ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 20
IOAPIC[0]: Set PCI routing entry (2-20 -> 0xd1 -> IRQ 20 Mode:1 Active:1)
00:00:11[A] -> 2-20 -> IRQ 20
Pin 2-21 already programmed
_CRS returns NULL! Using IRQ 22 for device (PCI Interrupt Link [ALKC]).
ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22
IOAPIC[0]: Set PCI routing entry (2-22 -> 0xd9 -> IRQ 22 Mode:1 Active:1)
00:00:11[C] -> 2-22 -> IRQ 22
_CRS returns NULL! Using IRQ 23 for device (PCI Interrupt Link [ALKD]).
ACPI: PCI Interrupt Link [ALKD] enabled at IRQ 23
IOAPIC[0]: Set PCI routing entry (2-23 -> 0xe1 -> IRQ 23 Mode:1 Active:1)
00:00:11[D] -> 2-23 -> IRQ 23
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-23 already programmed
Pin 2-23 already programmed
Pin 2-23 already programmed
Pin 2-23 already programmed
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
divert: not allocating divert_blk for non-ethernet device lo
vesafb: framebuffer at 0xd8000000, mapped to 0xd080b000, size 16384k
vesafb: mode is 1024x768x16, linelength=2048, pages=0
vesafb: protected mode interface info at c000:c2c0
vesafb: pmi: set display start = c00cc305, set palette = c00cc38a
vesafb: pmi: ports = b4c3 b503 ba03 c003 c103 c403 c503 c603 c703 c803 c903 cc03 ce03 cf03 d003 d103 d203 d303 d403 d503 da03 ff03 
vesafb: scrolling: ywrap using protected mode interface, yres_virtual=8192
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
fb0: VESA VGA frame buffer device
Machine check exception polling timer started.
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
apm: overridden by ACPI.
Total HugeTLB memory allocated, 0
ikconfig 0.7 with /proc/config*
VFS: Disk quotas dquot_6.5.1
Initializing Cryptographic API
PCI: Via IRQ fixup for 0000:00:10.1, from 11 to 5
PCI: Via IRQ fixup for 0000:00:10.2, from 10 to 5
ACPI: Power Button (FF) [PWRF]
ACPI: Fan [FAN] (on)
ACPI: Processor [CPU0] (supports C1 C2)
ACPI: Thermal Zone [THRM] (41 C)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Console: switching to colour frame buffer device 128x48
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:11.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci0000:00:11.1
    ide0: BM-DMA at 0xec00-0xec07, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xec08-0xec0f, BIOS settings: hdc:DMA, hdd:DMA
hda: IBM-DTLA-307030, ATA DISK drive
Using anticipatory io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: PLEXTOR CD-R PX-W8432T, ATAPI CD/DVD-ROM drive
hdd: Pioneer DVD-ROM ATAPIModel DVD-105S 013, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 60036480 sectors (30738 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
 hda: hda1 hda2 hda3 < hda5 hda6 >
hdc: ATAPI 32X CD-ROM CD-R/RW drive, 4096kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
hdd: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33)
ide-floppy driver 0.99.newide
Console: switching to colour frame buffer device 128x48
mice: PS/2 mouse device common for all mice
input: PC Speaker
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Translated Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
BIOS EDD facility v0.10 2003-Oct-11, 1 devices found
Please report your BIOS at http://domsch.com/linux/edd30/results.html
PM: Reading pmdisk image.
PM: Resume from disk failed.
ACPI: (supports S0 S1 S3 S4 S5)
found reiserfs format "3.5" with standard journal
Reiserfs journal params: device hda5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
reiserfs: checking transaction log (hda5) for (hda5)
reiserfs: replayed 63 transactions in 2 seconds
Using r5 hash to sort names
reiserfs: using 3.5.x disk format
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 192k freed
NET: Registered protocol family 1
Adding 524656k swap on /dev/hda2.  Priority:-1 extents:1
Real Time Clock Driver v1.12
Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
CAPI Subsystem Rev 1.21.6.8
ksysguardd: numerical sysctl 7 2 1 is obsolete.
8139too Fast Ethernet driver 0.9.26
divert: allocating divert_blk for eth0
eth0: RealTek RTL8139 at 0xd191d000, 00:e0:7d:b5:8b:2a, IRQ 17
eth0:  Identified 8139 chip type 'RTL-8139C'
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.1
uhci_hcd 0000:00:10.0: UHCI Host Controller
uhci_hcd 0000:00:10.0: irq 21, io base 0000e000
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
uhci_hcd 0000:00:10.1: UHCI Host Controller
uhci_hcd 0000:00:10.1: irq 21, io base 0000e400
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
uhci_hcd 0000:00:10.2: UHCI Host Controller
uhci_hcd 0000:00:10.2: irq 21, io base 0000e800
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ehci_hcd 0000:00:10.3: EHCI Host Controller
ehci_hcd 0000:00:10.3: irq 21, pci mem d191f000
ehci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 4
ehci_hcd 0000:00:10.3: USB 2.0 enabled, EHCI 1.00, driver 2003-Jun-13
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 6 ports detected
hub 1-0:1.0: new USB device on port 1, assigned address 2
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
lp0: using parport0 (polling).
lp0: console ready
NET: Registered protocol family 10
Disabled Privacy Extensions on device c0365ca0(lo)
IPv6 over IPv4 tunneling driver
divert: not allocating divert_blk for non-ethernet device sit0
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
mtrr: 0xd8000000,0x4000000 overlaps existing 0xd8000000,0x1000000
Linux video capture interface: v1.00
bttv: driver version 0.9.12 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv0: Bt848 (rev 18) at 0000:00:0c.0, irq: 18, latency: 32, mmio: 0xe2002000
bttv0: using: Hauppauge (bt848) [card=2,insmod option]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
bttv0: Hauppauge eeprom: model=60004, tuner=Philips FI1216 MK2 (5), radio=no
bttv0: using tuner=5
bttv0: i2c: checking for MSP34xx @ 0x80... not found
bttv0: i2c: checking for TDA9875 @ 0xb0... not found
bttv0: i2c: checking for TDA7432 @ 0x8a... not found
tvaudio: TV audio decoder + audio/video mux driver
tvaudio: known chips: tda9840,tda9873h,tda9874h/a,tda9850,tda9855,tea6300,tea6420,tda8425,pic16c54 (PV951),ta8874z
tuner: chip found @ 0xc2
tuner: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
registering 0-0061
bttv0: registered device video0
bttv0: registered device vbi0
eth0: no IPv6 routers present
usb 1-1: USB disconnect, address 2
hub 1-0:1.0: new USB device on port 1, assigned address 3
drivers/usb/core/usb.c: registered new driver hiddev
drivers/usb/input/hid-ff.c: hid_ff_init could not find initializer
input: USB HID v1.00 Mouse [Logitech USB-PS/2 Mouse M-BA47] on usb-0000:00:10.0-1
drivers/usb/core/usb.c: registered new driver hid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
hda: tagged command queueing enabled, command queue depth 32
Creative EMU10K1 PCI Audio Driver, version 0.20a, 21:49:21 Oct 30 2003
emu10k1: EMU10K1 rev 4 model 0x20 found, IO at 0xd800-0xd81f, IRQ 19
ac97_codec: AC97  codec, id: TRA3 (TriTech TR28023)
ksysguardd: numerical sysctl 7 2 1 is obsolete.

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Processes receive SIGSEGV if TCQ is enabled

[Ivan Gyurdiev]

Hi, perhaps this might also be relevant:

http://www.ussg.iu.edu/hypermail/linux/kernel/0307.2/1655.html

Have those issues here been finally addressed?
I haven't been following development much lately, but I wanted to ask, 
since at the moment I have no confidence in TCQ. I know #1 has been 
fixed. Have there been any major TCQ changes that I need to retest for?

The only thing I see is this:

ChangeSet@1.1153.141.3, 2003-09-05 07:15:37-07:00, 
B.Zolnierkiewicz@elka.pw.edu.pl
   [PATCH] ide: fix ide_cs oops with TCQ

Thomas Schlichter wrote:
> Hello again...
> 
> On Thursday 30 October 2003 22:33, Andrew Morton wrote:
> 
>>Thomas Schlichter <schlicht@uni-mannheim.de> wrote:
>>
>>> today I tried to test TCQ with the linux-2.6.0-test9-mm1 kernel. The
>>>config.gz is attached. But after enabling TCQ with 'hdparm -Q1 /dev/hda'
>>>newly started processes die due to a received SIGSEGV. No bad kernel
>>>messages appear...

Re: Processes receive SIGSEGV if TCQ is enabled

[Nick Piggin]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

Hi,
If you're testing IDE TCQ, please try the following patch and use the
default io scheduler. It won't fix anything, but it poisons requests
so we can sometimes tell if they are being used in the wrong places.
I have seen warnings that lead me to believe this might be happening.
Its against 2.6.0-test9-mm1. Report any stack traces you see. Thanks.

Nick


[-- Attachment #2: as-req-debug.patch --]
[-- Type: text/plain, Size: 4329 bytes --]

 linux-2.6-npiggin/drivers/block/as-iosched.c |   69 ++++++++++++++++++++-------
 1 files changed, 53 insertions(+), 16 deletions(-)

diff -puN drivers/block/as-iosched.c~as-req-debug drivers/block/as-iosched.c
--- linux-2.6/drivers/block/as-iosched.c~as-req-debug	2003-10-31 09:42:27.000000000 +1100
+++ linux-2.6-npiggin/drivers/block/as-iosched.c	2003-10-31 10:33:00.000000000 +1100
@@ -136,6 +136,10 @@ enum arq_state {
 				   scheduler */
 	AS_RQ_DISPATCHED,	/* On the dispatch list. It belongs to the
 				   driver now */
+	AS_RQ_PRESCHED,		/* Debug poisoning for requests being used */
+	AS_RQ_REMOVED,
+	AS_RQ_MERGED,
+	AS_RQ_POSTSCHED,	/* when they shouldn't be */
 };
 
 struct as_rq {
@@ -897,8 +901,14 @@ static void as_completed_request(request
 
 	WARN_ON(!list_empty(&rq->queuelist));
 
-	if (unlikely(arq->state != AS_RQ_DISPATCHED))
-		return;
+	if (arq->state == AS_RQ_MERGED)
+		goto out;
+
+	if (arq->state != AS_RQ_REMOVED) {
+		printk("arq->state %d\n", arq->state);
+		WARN_ON(1);
+		goto out;
+	}
 
 	if (ad->changed_batch && ad->nr_dispatched == 1) {
 		WARN_ON(ad->batch_data_dir == arq->is_sync);
@@ -926,7 +936,7 @@ static void as_completed_request(request
 	}
 
 	if (!arq->io_context)
-		return;
+		goto out;
 
 	if (ad->io_context == arq->io_context) {
 		ad->antic_start = jiffies;
@@ -942,7 +952,7 @@ static void as_completed_request(request
 
 	aic = arq->io_context->aic;
 	if (!aic)
-		return;
+		goto out;
 
 	spin_lock(&aic->lock);
 	if (arq->is_sync == REQ_SYNC) {
@@ -952,6 +962,9 @@ static void as_completed_request(request
 	spin_unlock(&aic->lock);
 
 	put_io_context(arq->io_context);
+
+out:
+	arq->state = AS_RQ_POSTSCHED;
 }
 
 /*
@@ -1020,14 +1033,14 @@ static void as_remove_request(request_qu
 	struct as_rq *arq = RQ_DATA(rq);
 
 	if (unlikely(arq->state == AS_RQ_NEW))
-		return;
-
-	if (!arq) {
-		WARN_ON(1);
-		return;
-	}
+		goto out;
 
 	if (ON_RB(&arq->rb_node)) {
+		if (arq->state != AS_RQ_QUEUED) {
+			printk("arq->state %d\n", arq->state);
+			WARN_ON(1);
+			goto out;
+		}
 		/*
 		 * We'll lose the aliased request(s) here. I don't think this
 		 * will ever happen, but if it does, hopefully someone will
@@ -1035,8 +1048,16 @@ static void as_remove_request(request_qu
 		 */
 		WARN_ON(!list_empty(&rq->queuelist));
 		as_remove_queued_request(q, rq);
-	} else
+	} else {
+		if (arq->state != AS_RQ_DISPATCHED) {
+			printk("arq->state %d\n", arq->state);
+			WARN_ON(1);
+			goto out;
+		}
 		as_remove_dispatched_request(q, rq);
+	}
+out:
+	arq->state = AS_RQ_REMOVED;
 }
 
 /*
@@ -1276,8 +1297,6 @@ fifo_expired:
 			ad->new_batch = 1;
 
 		ad->changed_batch = 0;
-
-//		arq->request->flags |= REQ_SOFTBARRIER;
 	}
 
 	/*
@@ -1402,6 +1421,11 @@ static void as_requeue_request(request_q
 	struct as_rq *arq = RQ_DATA(rq);
 
 	if (arq) {
+		if (arq->state != AS_RQ_REMOVED) {
+			printk("arq->state %d\n", arq->state);
+			WARN_ON(1);
+		}
+
 		arq->state = AS_RQ_DISPATCHED;
 		if (arq->io_context && arq->io_context->aic)
 			atomic_inc(&arq->io_context->aic->nr_dispatched);
@@ -1421,12 +1445,18 @@ as_insert_request(request_queue_t *q, st
 	struct as_data *ad = q->elevator.elevator_data;
 	struct as_rq *arq = RQ_DATA(rq);
 
-#if 0
+ 	if (arq) {
+ 		if (arq->state != AS_RQ_PRESCHED) {
+ 			printk("arq->state: %d\n", arq->state);
+ 			WARN_ON(1);
+ 		}
+ 		arq->state = AS_RQ_NEW;
+ 	}
+
 	/* barriers must flush the reorder queue */
 	if (unlikely(rq->flags & (REQ_SOFTBARRIER | REQ_HARDBARRIER)
 			&& where == ELEVATOR_INSERT_SORT))
 		where = ELEVATOR_INSERT_BACK;
-#endif
 
 	switch (where) {
 		case ELEVATOR_INSERT_BACK:
@@ -1662,6 +1692,8 @@ as_merged_requests(request_queue_t *q, s
 	 */
 	as_remove_queued_request(q, next);
 	put_io_context(anext->io_context);
+
+	anext->state = AS_RQ_MERGED;
 }
 
 /*
@@ -1694,6 +1726,11 @@ static void as_put_request(request_queue
 		return;
 	}
 
+	if (arq->state != AS_RQ_POSTSCHED) {
+		printk("arq->state %d\n", arq->state);
+		WARN_ON(1);
+	}
+
 	mempool_free(arq, ad->arq_pool);
 	rq->elevator_private = NULL;
 }
@@ -1707,7 +1744,7 @@ static int as_set_request(request_queue_
 		memset(arq, 0, sizeof(*arq));
 		RB_CLEAR(&arq->rb_node);
 		arq->request = rq;
-		arq->state = AS_RQ_NEW;
+		arq->state = AS_RQ_PRESCHED;
 		arq->io_context = NULL;
 		INIT_LIST_HEAD(&arq->hash);
 		arq->on_hash = 0;

_

Re: Processes receive SIGSEGV if TCQ is enabled

[Thomas Schlichter]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

Hi,

On Friday 31 October 2003 00:40, Nick Piggin wrote:
> Hi,
> If you're testing IDE TCQ, please try the following patch and use the
> default io scheduler. It won't fix anything, but it poisons requests
> so we can sometimes tell if they are being used in the wrong places.
> I have seen warnings that lead me to believe this might be happening.
> Its against 2.6.0-test9-mm1. Report any stack traces you see. Thanks.

OK, I tested 2.6.0-test9-mm1 + your patch, but it seems not to print any 
messages or stack traces, even if many processes are killed after setting TCQ 
depth to 1.

Today, however, I got reiserfs corruption messages in the logs, but 
fsck.reiserfs could not find any corruption on the next boot, so I think this 
is not a real corruption but just reading the wrong data...

The messages are something like:

Oct 31 07:57:53 bigboss kernel: is_tree_node: node level 2120 does not match 
to the expected one 1
Oct 31 07:57:53 bigboss kernel: vs-5150: search_by_key: invalid format found 
in block 642544. Fsck?
Oct 31 07:57:53 bigboss kernel: vs-13070: reiserfs_read_locked_inode: i/o 
failure occurred trying to find stat data of [4767268 4767269 0x0 SD]
Oct 31 07:57:53 bigboss kernel: is_tree_node: node level 2120 does not match 
to the expected one 1
Oct 31 07:57:53 bigboss kernel: vs-5150: search_by_key: invalid format found 
in block 642544. Fsck?
Oct 31 07:57:53 bigboss kernel: vs-13070: reiserfs_read_locked_inode: i/o 
failure occurred trying to find stat data of [4767268 4767269 0x0 SD]

> Nick

  Thomas

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Processes receive SIGSEGV if TCQ is enabled

[Nick Piggin]

Thomas Schlichter wrote:

>Hi,
>
>On Friday 31 October 2003 00:40, Nick Piggin wrote:
>
>>Hi,
>>If you're testing IDE TCQ, please try the following patch and use the
>>default io scheduler. It won't fix anything, but it poisons requests
>>so we can sometimes tell if they are being used in the wrong places.
>>I have seen warnings that lead me to believe this might be happening.
>>Its against 2.6.0-test9-mm1. Report any stack traces you see. Thanks.
>>
>
>OK, I tested 2.6.0-test9-mm1 + your patch, but it seems not to print any 
>messages or stack traces, even if many processes are killed after setting TCQ 
>depth to 1.
>

OK well thats good, its not my problem then ;) Thanks.

Re: Processes receive SIGSEGV if TCQ is enabled

[Jens Axboe]

On Thu, Oct 30 2003, Bartlomiej Zolnierkiewicz wrote:
> 
> [ Jens - IDE TCQ maintainer 8) added to cc: ]

Not really (added, that is :)

> Could you also send dmesg output and retry with vanilla -test9?

It's probably via + tcq, that drive is known good with ide-tcq. At least
I've never seen problems with it.

-- 
Jens Axboe

Re: Processes receive SIGSEGV if TCQ is enabled

[Thomas Schlichter]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

On Friday 31 October 2003 14:00, Jens Axboe wrote:
> It's probably via + tcq, that drive is known good with ide-tcq. At least
> I've never seen problems with it.

Maybe it is a problem with via + tcq... so, how to debug?

@Ivan: Did you also use a via chipset when reporting the problems mentioned in
http://www.ussg.iu.edu/hypermail/linux/kernel/0307.2/1655.html ? Beacuse your 
point 4) indeed looks very similar to my problems...

  Thomas

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Processes receive SIGSEGV if TCQ is enabled

[Ivan Gyurdiev]

Thomas Schlichter wrote:
> On Friday 31 October 2003 14:00, Jens Axboe wrote:
> 
>>It's probably via + tcq, that drive is known good with ide-tcq. At least
>>I've never seen problems with it.
> 
> 
> Maybe it is a problem with via + tcq... so, how to debug?
> 
> @Ivan: Did you also use a via chipset when reporting the problems mentioned in
> http://www.ussg.iu.edu/hypermail/linux/kernel/0307.2/1655.html ? Beacuse your 
> point 4) indeed looks very similar to my problems...
> 
>   Thomas


Yes - VIA chipset.

00:11.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)