lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 02 Dec 2007 00:14:21 +0000
From:	Nix <nix@...eri.org.uk>
To:	linux-kernel@...r.kernel.org
Subject: sym53c8xx2: incredible sloth after parity error / SCSI bus reset

About once a year I get a SCSI parity error on one of my systems (the
only one with SCSI). I presume the cabling is substandard, but given my
coordination deficits and the rarity of the errors I'd do far more
damage replacing it than leaving it be.

I had one of these today.

The system (2.6.23.9) spotted the error, and seemingly recovered:

Dec  1 12:53:40 loki warning: kernel: sym0: SCSI parity error detected: SCR1=132 DBC=50000000 SBCL=0
Dec  1 12:53:40 loki warning: kernel: sym0:0: ERROR (81:0) (8-0-0) (10/9d/0) @ (mem c2800048:ffffffff).
Dec  1 12:53:40 loki warning: kernel: sym0: regdump: da 00 00 9d 47 10 00 0e 00 08 80 00 80 00 0f 0a d0 58 3c 01 02 ff ff ff.
Dec  1 12:53:40 loki warning: kernel: sym0: SCSI BUS reset detected.
Dec  1 12:53:40 loki notice: kernel: sym0: SCSI BUS has been reset.

However, after that reset I/O to any device on that controller is
*incredibly* slow.

A monthly RAID check kicked off shortly afterwards and provided my first
clue. Load average >15, and:

md1 : active raid5 sda6[0] hdc5[3] sdb6[1]
      76807296 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
      [========>............]  check = 42.8% (16450780/38403648) finish=253.3min speed=1442K/sec

1442Kb/s is a bit less than I'd expect from a three-drive array with
disks capable of 40Mb/s easily.

/dev/sda:
 Timing buffered disk reads:    8 MB in  3.50 seconds =   2.29 MB/sec

A somewhat slower ATAPI disk on the same machine:

/dev/hdc:
 Timing buffered disk reads:  110 MB in  3.05 seconds =  36.08 MB/sec

So, um, what could cause this? Can I speed it up again other than by
rebooting (which I'm just about to do, but it is annoying).

-- 
`Some people don't think performance issues are "real bugs", and I think 
such people shouldn't be allowed to program.' --- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ