I have a usb hd that I use for backup. Occasionally it dies.
scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): read_inode_bitmap: Cannot read inode bitmap - block_group = 129, inode_bitmap = 4227073 scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): ext2_readdir: bad page in #2 scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): ext2_get_inode: unable to read inode block - inode=2, block=1027 scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): ext2_readdir: bad page in #2
If i unmount it and try to remount it it says sdc1 does not exist.
I am not at the location so physically unplugging then replugging in the drive isn't a convenient option.
How can I get the os to rescan the usb device so I can remount?
thx bazooka
On 22/09/2009, at 9:35 AM, Bazooka Joe wrote:
I have a usb hd that I use for backup. Occasionally it dies.
scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): read_inode_bitmap: Cannot read inode bitmap - block_group = 129, inode_bitmap = 4227073 scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): ext2_readdir: bad page in #2 scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): ext2_get_inode: unable to read inode block - inode=2, block=1027 scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): ext2_readdir: bad page in #2
If i unmount it and try to remount it it says sdc1 does not exist.
I am not at the location so physically unplugging then replugging in the drive isn't a convenient option.
How can I get the os to rescan the usb device so I can remount?
The sg_reset command might work: http://linux.die.net/man/8/sg_reset
Oliver
thx bazooka _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, 2009-09-21 at 17:05 -0700, Bazooka Joe wrote:
I have a usb hd that I use for backup. Occasionally it dies.
scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): read_inode_bitmap: Cannot read inode bitmap - block_group = 129, inode_bitmap = 4227073 scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): ext2_readdir: bad page in #2 scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): ext2_get_inode: unable to read inode block - inode=2, block=1027 scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): ext2_readdir: bad page in #2
If i unmount it and try to remount it it says sdc1 does not exist.
It may not be the USB drive. I have one that daoe the same, usually only after long periods oh high (in)activity.
On another node, no problems ever using that same drive.
On the system with the problem, CentOS 4.7, Via Kt-400A chipset.
One the other system, Centos 5.3, Via KT-880 chipset.
I've not bothered to google yet, since it seems to occur after leaving it attached for long periods and what I do doesn't take long
Maybe there's a clue?
I am not at the location so physically unplugging then replugging in the drive isn't a convenient option.
How can I get the os to rescan the usb device so I can remount?
thx bazooka
<snip>
HTH
On Mon, 2009-09-21 at 17:05 -0700, Bazooka Joe wrote:
I have a usb hd that I use for backup. Occasionally it dies. If i unmount it and try to remount it it says sdc1 does not exist.
Not sure if related to your problem but I have many 'zombie' usb devices after mounting/unmounting a few times...
# ll /dev/sd* brw-r----- 1 root disk 8, 0 Sep 17 11:45 /dev/sda* brw-r----- 1 root disk 8, 16 Sep 17 11:45 /dev/sdb* brw-r----- 1 root disk 8, 32 Sep 17 11:45 /dev/sdc brw-r----- 1 root disk 8, 48 Sep 17 11:45 /dev/sdd brw-r----- 1 root disk 8, 64 Sep 17 11:45 /dev/sde brw-r----- 1 root disk 8, 80 Sep 17 11:45 /dev/sdf brw-r----- 1 root disk 8, 96 Sep 17 11:45 /dev/sdg
# rmmod usb_storage
# ll /dev/sd* brw-r----- 1 root disk 8, 0 Sep 17 11:45 /dev/sda* brw-r----- 1 root disk 8, 16 Sep 17 11:45 /dev/sdb*
JD
William L. Maltby wrote:
On Mon, 2009-09-21 at 17:05 -0700, Bazooka Joe wrote:
I have a usb hd that I use for backup. Occasionally it dies.
scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): read_inode_bitmap: Cannot read inode bitmap - block_group = 129, inode_bitmap = 4227073 scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): ext2_readdir: bad page in #2 scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): ext2_get_inode: unable to read inode block - inode=2, block=1027 scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): ext2_readdir: bad page in #2
If i unmount it and try to remount it it says sdc1 does not exist.
It may not be the USB drive. I have one that daoe the same, usually only after long periods oh high (in)activity.
On another node, no problems ever using that same drive.
On the system with the problem, CentOS 4.7, Via Kt-400A chipset.
One the other system, Centos 5.3, Via KT-880 chipset.
I've not bothered to google yet, since it seems to occur after leaving it attached for long periods and what I do doesn't take long
Maybe there's a clue?
This can happen if the drive has power-saving features and it's gone to sleep after no activity.
What does 'sdparm -a /dev/sdc' yield? And what make/model is the disk?
On Tue, 2009-09-22 at 22:16 +0100, Stewart Williams wrote:
William L. Maltby wrote:
<snip> > It may not be the USB drive. I have one that daoe the same, usually only > after long periods oh high (in)activity. > > On another node, no problems ever using that same drive. > > On the system with the problem, CentOS 4.7, Via Kt-400A chipset. > > One the other system, Centos 5.3, Via KT-880 chipset. > > I've not bothered to google yet, since it seems to occur after leaving > it attached for long periods and what I do doesn't take long > > Maybe there's a clue?
This can happen if the drive has power-saving features and it's gone to sleep after no activity.
But it's happened while active too, I *think*, while I was doing rtorrent - but maybe it had a big period of inactivity. But then I would have expectd symptoms to be on both systems.
What does 'sdparm -a /dev/sdc' yield? And what make/model is the disk?
On 5.3 # sdparm -a /dev/sdc -bash: sdparm: command not found
On 4.7 # sdparm -a /dev/sda -bash: sdparm: command not found
For mine (I'm not the OP) Toshiba HDDR100E01X
<snip sig stuff>
On Tuesday 22 September 2009 18:59, William L. Maltby wrote:
On Tue, 2009-09-22 at 22:16 +0100, Stewart Williams wrote:
What does 'sdparm -a /dev/sdc' yield? And what make/model is the disk?
On 5.3 # sdparm -a /dev/sdc -bash: sdparm: command not found
He meant "hdparm", I think.
Quoting Yves Bellefeuille yan@storm.ca:
On Tuesday 22 September 2009 18:59, William L. Maltby wrote:
On Tue, 2009-09-22 at 22:16 +0100, Stewart Williams wrote:
What does 'sdparm -a /dev/sdc' yield? And what make/model is the disk?
On 5.3 # sdparm -a /dev/sdc -bash: sdparm: command not found
He meant "hdparm", I think.
-- Yves Bellefeuille yan@storm.ca "Yves Bellefeuille: Eterna malvenkanto en UEA" -- Heroldo Komunikas, n-ro 389
No I definitely mean't "sdparm", it's available from RPMForge and it's different from "hdparm".
[stewart@##### ~]$ whatis sdparm sdparm (8) - access SCSI modes pages; read VPD pages; send simple SCSI commands sdparm (rpm) - List or change SCSI disk parameters [stewart@##### ~]$ whatis hdparm hdparm (8) - get/set hard disk parameters hdparm (rpm) - A utility for displaying and/or setting hard disk parameters.
[stewart@##### ~]$ sudo yum whatprovides "*/sdparm"
...
sdparm-1.03-1.el5.rf.x86_64 : List or change SCSI disk parameters Matched from: Filename : /usr/bin/sdparm
...
[stewart@##### ~]$ sudo /usr/bin/sdparm -a /dev/sde Password: /dev/sde: Maxtor OneTouch 0125 Power condition mode page: IDLE 0 [cha: n, def: 0, sav: 0] STANDBY 0 [cha: y, def: 1, sav: 0] ICT 0 [cha: n, def: 0, sav: 0] SCT 4294967286 [cha: y, def:9000, sav:4294967286]
The 'STANDBY' condition is what were interested in.
On Wed, 2009-09-23 at 10:00 +0100, Stewart Williams wrote:
<snip>
No I definitely mean't "sdparm", it's available from RPMForge and it's different from "hdparm".
[stewart@##### ~]$ whatis sdparm sdparm (8) - access SCSI modes pages; read VPD pages; send simple SCSI commands sdparm (rpm) - List or change SCSI disk parameters [stewart@##### ~]$ whatis hdparm hdparm (8) - get/set hard disk parameters hdparm (rpm) - A utility for displaying and/or setting hard disk parameters.
[stewart@##### ~]$ sudo yum whatprovides "*/sdparm"
...
sdparm-1.03-1.el5.rf.x86_64 : List or change SCSI disk parameters Matched from: Filename : /usr/bin/sdparm
...
[stewart@##### ~]$ sudo /usr/bin/sdparm -a /dev/sde Password: /dev/sde: Maxtor OneTouch 0125 Power condition mode page: IDLE 0 [cha: n, def: 0, sav: 0] STANDBY 0 [cha: y, def: 1, sav: 0] ICT 0 [cha: n, def: 0, sav: 0] SCT 4294967286 [cha: y, def:9000, sav:4294967286]
The 'STANDBY' condition is what were interested in.
I installed sdparm on 5.3 and got this.
# sdparm -a /dev/sdc /dev/sdc: Toshiba USB2.0 Drive R00 1.43 Read write error recovery mode page:
warning: mode page seems malformed
The page number field should be 0x01, but is 0x05; try '--flexible'
- lots of occurrences like that last line and a whole bunch of other stuff.
So I
# sdparm -a --flexible /dev/sdc /dev/sdc: Toshiba USB2.0 Drive R00 1.43 Read write error recovery mode page:
warning: mode page seems malformed
and it looks better. The lines of interest seem to be
Power condition - old version mode page:
warning: mode page seems malformed
The page number field should be 0x0d, but is 0x05 IDLE-OLD 0 [cha: n, def: 0, sav: 0] STBY-OLD 0 [cha: n, def: 0, sav: 0] ICT-OLD 272564736 [cha: y, def:272564736, sav:272564736] SCT-OLD 1073676288 [cha: y, def:1073676288, sav:1073676288] Power condition mode page:
warning: mode page seems malformed
The page number field should be 0x1a, but is 0x05 IDLE 0 [cha: n, def: 0, sav: 0] STANDBY 0 [cha: n, def: 0, sav: 0] ICT 272564736 [cha: y, def:272564736, sav:272564736] SCT 1073676288 [cha: y, def:1073676288, sav:1073676288]
The 4.7 results are quite similar.
<snip sig stuff>
William L. Maltby wrote:
Power condition - old version mode page:
warning: mode page seems malformed
The page number field should be 0x0d, but is 0x05 IDLE-OLD 0 [cha: n, def: 0, sav: 0] STBY-OLD 0 [cha: n, def: 0, sav: 0] ICT-OLD 272564736 [cha: y, def:272564736, sav:272564736] SCT-OLD 1073676288 [cha: y, def:1073676288, sav:1073676288] Power condition mode page:
warning: mode page seems malformed
The page number field should be 0x1a, but is 0x05 IDLE 0 [cha: n, def: 0, sav: 0] STANDBY 0 [cha: n, def: 0, sav: 0] ICT 272564736 [cha: y, def:272564736, sav:272564736] SCT 1073676288 [cha: y, def:1073676288, sav:1073676288]
From those results, it doesn't look like your problem is a power issue.
_Unless_ the drive itself has a fault. But that doesn't sound like the case, as it's fine on your other box.
Maybe a problem with your USB port that you are plugging it into? Try another drive or USB device (e.g. USB flash drive) in the same port to see if you get any errors.
On Wed, 2009-09-23 at 18:25 +0100, Stewart Williams wrote:
<snip>
From those results, it doesn't look like your problem is a power issue. _Unless_ the drive itself has a fault. But that doesn't sound like the case, as it's fine on your other box.
Maybe a problem with your USB port that you are plugging it into? Try another drive or USB device (e.g. USB flash drive) in the same port to see if you get any errors.
I tried the same drive on another port (different header on MB). Same results. I *think* I tried the other drive two (I've got two identical), but I'm unsure now. I'll fire it up and and try with the other drive this week.
My first suspicion was old drive firmware (confirmed by the sdparm results?) or old 4.7 driver code since 5.3 didn't do it. My second suspicion is a flaw in the KT-440 chipset, since it didn't do it on the KT-800 chipset.
Never got aggravating enough to google and if the OP hadn't raised the issue I wouldn't have posted. I was just hoping a clue might be if we had similar chipsets or driver versions involved.
<snip sig stuff>
BTW, thanks for jumping in - I learned a bit from this.
-
Bazooka Joe -
John Doe -
Oliver Ransom -
Stewart Williams -
William L. Maltby -
Yves Bellefeuille