New: Adaptec AHA-7850 with MOD drive: Hard lockup with new Adaptec driver

http://bugzilla.kernel.org/show_bug.cgi?id=9462

           Summary: Adaptec AHA-7850 with MOD drive: Hard lockup with new
                    Adaptec driver
           Product: IO/Storage
           Version: 2.5
     KernelVersion: 2.6.22.14
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: high
          Priority: P1
         Component: SCSI
        AssignedTo: [email protected]
        ReportedBy: [email protected]

Most recent kernel where this bug did not occur: Works with the old Adaptec driver. Had lockups with 2.6.18.8 as well, with the new driver.

Distribution: Debian etch

Hardware Environment: Epox 8kta+, Athlon 800 MHz, 768MB RAM

Output form lspci:
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev
22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 10) 00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 10)
00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 10)
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:09.0 Ethernet controller: D-Link System Inc DL2000-based Gigabit Ethernet (rev 0c)
00:0a.0 USB Controller: NEC Corporation USB (rev 43)
00:0a.1 USB Controller: NEC Corporation USB (rev 43)
00:0a.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
00:0b.0 Mass storage controller: Promise Technology, Inc. PDC20518/PDC40518 (SATAII 150 TX4) (rev 02)
00:0c.0 SCSI storage controller: Adaptec AHA-7850 (rev 03)
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev a1)

Software Environment: Tried cp, dd_rescue and cat for copy. No difference.

Problem Description: When writing to the filesystem on the MOD, the computer locks completely as far as I can tell, no responses to ping, no log-entries (this is a headless server) MOD not writing and only a hard reset helps. The target filesystem had (after recovery with e2fsck) 22MB on it in one try and 350MB in another one. I guess there is some race condition or other randomized process at work. MOD size is 600MB.

Steps to reproduce:
Insert MOD, mount it, write to it, see lockup happen.
Observed with new dribver in 2.6.18.8 and 2.6.22.14. Also happens with TCQ disabled.

I should add that MODs are slow. The writing process blocks for 10-20 seconds frequently for disk flushes. This is normal and expected.

Maybe a warning should be added to the new drivr and the old one should be kept for the time being.

If there are some tests I can run for you, please let me know.