symbios i kernel 2.2.20
Blues
blues w ds6.pg.gda.pl
Śro, 27 Lut 2002, 18:04:20 CET
Wziąłem się dzisiaj za update jednej zapomnianej maszyny z naszego
kernelka 2.2.19-26 przy okazji zaniku dłuuuuugiego prądu. Jest on
wyposażony w kontroler Tekram'a. Na tym jajku zgłasza się on następująco:
sym53c8xx: at PCI bus 0, device 9, function 1
sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
sym53c8xx: 53c1010-33 detected with Symbios NVRAM
sym53c8xx: at PCI bus 0, device 9, function 0
sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
sym53c8xx: 53c1010-33 detected with Symbios NVRAM
sym53c1010-33-0: rev 0x1 on pci bus 0 device 9 function 1 irq 10
sym53c1010-33-0: Symbios format NVRAM, ID 7, Fast-80, Parity Checking
sym53c1010-33-0: on-chip RAM at 0xebfec000
sym53c1010-33-0: restart (scsi reset).
sym53c1010-33-0: handling phase mismatch from SCRIPTS.
sym53c1010-33-0: Downloading SCSI SCRIPTS.
sym53c1010-33-1: rev 0x1 on pci bus 0 device 9 function 0 irq 10
sym53c1010-33-1: Symbios format NVRAM, ID 7, Fast-80, Parity Checking
sym53c1010-33-1: on-chip RAM at 0xebfea000
sym53c1010-33-1: restart (scsi reset).
sym53c1010-33-1: handling phase mismatch from SCRIPTS.
sym53c1010-33-1: Downloading SCSI SCRIPTS.
scsi0 : sym53c8xx-1.7.3c-20010512
scsi1 : sym53c8xx-1.7.3c-20010512
scsi : 2 hosts.
Vendor: QUANTUM Model: FIREBALL_TM3200S Rev: 300X
Type: Direct-Access ANSI SCSI revision: 02
Vendor: QUANTUM Model: FIREBALL ST3.2S Rev: 0F0C
Type: Direct-Access ANSI SCSI revision: 02
Vendor: IBM Model: DDYS-T18350N Rev: S93E
Type: Direct-Access ANSI SCSI revision: 03
Detected scsi disk sda at scsi0, channel 0, id 5, lun 0
Detected scsi disk sdb at scsi0, channel 0, id 6, lun 0
Detected scsi disk sdc at scsi1, channel 0, id 5, lun 0
sym53c1010-33-0-<5,*>: FAST-20 SCSI 20.0 MB/s (50.0 ns, offset 15)
SCSI device sda: hdwr sector= 512 bytes. Sectors= 6281856 [3067 MB] [3.1 GB] sda: sda1
sym53c1010-33-0-<6,*>: FAST-20 SCSI 20.0 MB/s (50.0 ns, offset 15)
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 6328861 [3090 MB] [3.1 GB] sdb: sdb1 sdb2
sym53c1010-33-1-<5,*>: FAST-80 WIDE SCSI 160.0 MB/s (12.5 ns, offset 62)
SCSI device sdc: hdwr sector= 512 bytes. Sectors= 35843670 [17501 MB] [17.5 GB] sdc: sdc1 sdc2 sdc3
Wszystko działa jak należy, bez żadnych zgrzytów
Natomiast na naszym jajku 2.2.20-12 wygląda to tak:
sym53c8xx: at PCI bus 0, device 9, function 1
sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
sym53c8xx: 53c1010-33 detected with Symbios NVRAM
sym53c8xx: at PCI bus 0, device 9, function 0
sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
sym53c8xx: 53c1010-33 detected with Symbios NVRAM
sym53c1010-33-0: rev 0x1 on pci bus 0 device 9 function 1 irq 10
sym53c1010-33-0: Symbios format NVRAM, ID 7, Fast-80, Parity Checking
sym53c1010-33-0: on-chip RAM at 0xebfec000
sym53c1010-33-0: restart (scsi reset).
sym53c1010-33-0: handling phase mismatch from SCRIPTS.
sym53c1010-33-0: Downloading SCSI SCRIPTS.
sym53c1010-33-1: rev 0x1 on pci bus 0 device 9 function 0 irq 10
sym53c1010-33-1: Symbios format NVRAM, ID 7, Fast-80, Parity Checking
sym53c1010-33-1: on-chip RAM at 0xebfea000
sym53c1010-33-1: restart (scsi reset).
sym53c1010-33-1: handling phase mismatch from SCRIPTS.
sym53c1010-33-1: Downloading SCSI SCRIPTS.
scsi0 : sym53c8xx-1.7.3c-20010512
scsi1 : sym53c8xx-1.7.3c-20010512
scsi : 2 hosts.
Vendor: QUANTUM Model: FIREBALL_TM3200S Rev: 300X
Type: Direct-Access ANSI SCSI revision: 02
Vendor: QUANTUM Model: FIREBALL ST3.2S Rev: 0F0C
Type: Direct-Access ANSI SCSI revision: 02
sym53c1010-33-0-<5,0>: tagged command queue depth set to 16
sym53c1010-33-0-<6,0>: tagged command queue depth set to 16
Vendor: IBM Model: DDYS-T18350N Rev: S93E
Type: Direct-Access ANSI SCSI revision: 03
sym53c1010-33-1-<5,0>: tagged command queue depth set to 16
Detected scsi disk sda at scsi0, channel 0, id 5, lun 0
Detected scsi disk sdb at scsi0, channel 0, id 6, lun 0
Detected scsi disk sdc at scsi1, channel 0, id 5, lun 0
sym53c1010-33-0-<5,*>: FAST-20 SCSI 20.0 MB/s (50.0 ns, offset 15)
SCSI device sda: hdwr sector= 512 bytes. Sectors= 6281856 [3067 MB] [3.1 GB]
sda: sda1
sym53c1010-33-0-<6,*>: FAST-20 SCSI 20.0 MB/s (50.0 ns, offset 15)
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 6328861 [3090 MB] [3.1 GB]
sdb: sdb1 sdb2
sym53c1010-33-1-<5,*>: FAST-80 WIDE SCSI 160.0 MB/s (12.5 ns, offset 62)
SCSI device sdc: hdwr sector= 512 bytes. Sectors= 35843670 [17501 MB] [17.5 GB]
sdc: sdc1 sdc2 sdc3
Niby wygląda ok, prawda? Ale tak nie jest.
Przy pierszych operacjach na dysku dostaję:
sym53c1010-33-0-<5,0>: tagged command queue depth set to 16
sym53c1010-33-0-<5,0>: QUEUE FULL! 16 busy, 15 disconnected CCBs
sym53c1010-33-0-<5,0>: tagged command queue depth set to 15
sym53c1010-33-0-<5,0>: tagged command queue depth set to 16
I tak cyklicznie.
Jeżeli duuużo jest do zapisania na dysk logi są takie:
scsi : aborting command due to timeout : pid 13354, scsi0, channel 0, id 5, lun 0 Write (10) 00 00 00 38 56 00 00 80 00
sym53c8xx_abort: pid=13354 serial_number=13366 serial_number_at_timeout=13366
scsi : aborting command due to timeout : pid 13355, scsi0, channel 0, id 5, lun 0 Write (10) 00 00 00 38 d6 00 00 80 00
sym53c8xx_abort: pid=13355 serial_number=13367 serial_number_at_timeout=13367
scsi : aborting command due to timeout : pid 13356, scsi0, channel 0, id 5, lun 0 Write (10) 00 00 00 39 56 00 00 80 00
sym53c8xx_abort: pid=13356 serial_number=13368 serial_number_at_timeout=13368
sym53c1010-33-0-<5,*>: control msgout: 80 20 1d d.
scsi : aborting command due to timeout : pid 13357, scsi0, channel 0, id 5, lun 0 Write (10) 00 00 00 39 d6 00 00 80 00
..........
Wszystko dzieje się wtedy baardzo wolno.
Nie wiem czy to będzie miało znaczenie, ale dyski mam takie:
/dev/sda1 on / type reiserfs (rw)
/dev/sdc3 on /home type ext2 (rw,grpquota,usrquota)
/dev/sdc2 on /var/spool/squid type reiserfs (rw,noatime,notail) (nie używana teraz)
/dev/sdb1 on /tmp type ext2 (rw)
/dev/sdb2 on /var/mail type reiserfs (rw,notail)
niniejszym nasze jajko na tej maszynie jest dla mnie bezużyteczne :(
--
---------------------------------
pozdr. Paweł Gołaszewski
---------------------------------
CPU not found - software emulation...
Więcej informacji o liście dyskusyjnej pld-kernel