Re: (fwd) Bug#11922: I/O error on blank tapes
On Tue, 5 Feb 2008, Kai Makisara wrote: On Mon, 4 Feb 2008, James Bottomley wrote: On Mon, 2008-02-04 at 22:28 +0100, Borislav Petkov wrote: On Mon, Feb 04, 2008 at 03:22:06PM +0100, maximilian attems wrote: (Added Bart to CC) hello borislav, ... This does still occur with 2.6.22; with a blank tape in my HP DDS-4 drive: $ tar tzvf /dev/nst0 tar: /dev/nst0: Cannot read: Input/output error That's a SCSI tape, not an IDE one. I cc'd the SCSI list This is not a bug, it is a feature. There is _nothing_ on the tape and if you try to read something, you get an error. The same thing applies to reading after the last filemark. Note that after writing a filemark at the beginning of the tape, the situation is different. Now there is a file and the normal EOF semantics apply although there still is no data. I admit that the error return could be more descriptive but the st driver tries to be compatible with other Unices. The behavior can be changed if Linux does not match other Unices. I don't remember if I have tested just this with other Unices. I will try to test this with Tru64 tomorrow. If anyone has data on other Unices, it would be helpful. None of our Tru64 boxes have a user-accessible tape drive any more. However, I have been able to test with a Solaris box. The behavior there matches the Linux behavior: blank tape - i/o error when trying to read. -- Kai - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (fwd) Bug#11922: I/O error on blank tapes
On Mon, 4 Feb 2008, James Bottomley wrote: On Mon, 2008-02-04 at 22:28 +0100, Borislav Petkov wrote: On Mon, Feb 04, 2008 at 03:22:06PM +0100, maximilian attems wrote: (Added Bart to CC) hello borislav, may i forward you that *old* Debian kernel bug, have seen you working on ide-tape: http://bugs.debian.org/11922 no we don't carry any ide patches anymore. maybe you've already fixed it in latest? thanks -- maks - Forwarded message from Stephen Kitt [EMAIL PROTECTED] - Subject: Bug#11922: I/O error on blank tapes Date: Sat, 1 Dec 2007 19:06:18 +0100 From: Stephen Kitt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi, This does still occur with 2.6.22; with a blank tape in my HP DDS-4 drive: $ tar tzvf /dev/nst0 tar: /dev/nst0: Cannot read: Input/output error That's a SCSI tape, not an IDE one. I cc'd the SCSI list This is not a bug, it is a feature. There is _nothing_ on the tape and if you try to read something, you get an error. The same thing applies to reading after the last filemark. Note that after writing a filemark at the beginning of the tape, the situation is different. Now there is a file and the normal EOF semantics apply although there still is no data. I admit that the error return could be more descriptive but the st driver tries to be compatible with other Unices. The behavior can be changed if Linux does not match other Unices. I don't remember if I have tested just this with other Unices. I will try to test this with Tru64 tomorrow. If anyone has data on other Unices, it would be helpful. -- Kai - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.22-rc regression: smartctl does not work with SATA disk
The command 'smartctl -a /dev/sdb' fails with 2.6.22-rc4 kernel. The disk /dev/sdb is a SATA disk. The command does work still with a real SCSI disk. The computer has Athlon64 X2 and it is running x86_64 SMP kernel. The chipset is Nvidia CK804 and the sata_nv driver is used. The following output from 'smartctl -a -r ioctl,1 /dev/sdb' tells the disk details and shows where the regression is: - smartctl version 5.38 [x86_64-suse-linux-gnu] Copyright (C) 2002-7 Bruce Allen Home page is http://smartmontools.sourceforge.net/ [inquiry: 12 00 00 00 24 00 ] scsi_status=0x0, host_status=0x0, driver_status=0x0 info=0x0 duration=0 milliseconds resid=0 status=0x0 [ata pass-through(16): 85 08 0e 00 00 00 01 00 00 00 00 00 00 00 ec 00 ] scsi_status=0x0, host_status=0x0, driver_status=0x0 info=0x0 duration=4 milliseconds resid=0 status=0x0 Detected SAT interface, switch to device type 'sat' REPORT-IOCTL: DeviceFD=3 Command=IDENTIFY DEVICE [ata pass-through(16): 85 08 0e 00 00 00 01 00 00 00 00 00 00 00 ec 00 ] scsi_status=0x0, host_status=0x0, driver_status=0x0 info=0x0 duration=0 milliseconds resid=0 status=0x0 REPORT-IOCTL: DeviceFD=3 Command=IDENTIFY DEVICE returned 0 === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.10 family Device Model: ST3320620AS Serial Number:9QF22KAP Firmware Version: 3.AAJ User Capacity:320,072,933,376 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Sun Jun 10 10:47:30 2007 EEST SMART support is: Available - device has SMART capability. SMART support is: Enabled REPORT-IOCTL: DeviceFD=3 Command=SMART STATUS [ata pass-through(16): 85 06 2c 00 da 00 00 00 00 00 4f 00 c2 00 b0 00 ] scsi_status=0x2, host_status=0x0, driver_status=0x8 info=0x1 duration=44 milliseconds resid=0 status=2: [desc] sense_key=0 asc=0 ascq=0 REPORT-IOCTL: DeviceFD=3 Command=SMART STATUS returned 0 REPORT-IOCTL: DeviceFD=3 Command=SMART STATUS CHECK [ata pass-through(16): 85 06 2c 00 da 00 00 00 00 00 4f 00 c2 00 b0 00 ] scsi_status=0x2, host_status=0x0, driver_status=0x8 info=0x1 duration=44 milliseconds resid=0 status=2: [desc] sense_key=0 asc=0 ascq=0 Error SMART Status command failed Please get assistance from http://smartmontools.sourceforge.net/ Values from ATA status return descriptor are: 00 09 0c 00 00 00 00 00 00 00 00 00 00 00 50 REPORT-IOCTL: DeviceFD=3 Command=SMART STATUS CHECK returned -1 A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. This is smartctl from cvs a few days ago but the smartctl shipping with SuSE 10.2 fails in the same way. I ran 'git bisect' and it suggests that the problem was introduced by 1e999736cafdffc374f22eed37b291129ef82e4e is first bad commit commit 1e999736cafdffc374f22eed37b291129ef82e4e Author: Alan Cox [EMAIL PROTECTED] Date: Wed Apr 11 00:23:13 2007 +0100 libata: HPA support i.e., before 2.6.22-rc1. At this point I find best to leave the problem to experts. -- Kai - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
