From jd1008 at gmail.com Sat Sep 20 01:56:37 2014 From: jd1008 at gmail.com (jd1008) Date: Fri, 19 Sep 2014 19:56:37 -0600 Subject: Possible bug in mkfs.ext3 Message-ID: <541CDED5.7030100@gmail.com> I am reporting this on the advice of the Fedora Users Mailing List Member. This the mailing list exchange outlining the problem with specifying -S to mkfs, and it's subsequent consequences when fsck is run. I am reporting this per suggestions made to me on the Fedora Users Mailing List. The following is the mailing list exchange: On 09/18/2014 07:01 PM, Robert Nichols wrote: > On 09/18/2014 12:37 PM, jd1008 wrote: >> Is there any other tool that can extract files from a partition that >> seems to have corrupted superblocks? >> I tried dumpe2fs, and fsck -b >> to no avail. Tried all available block numbers that are listed >> when original mkfs was done, and it's output was saved. >> >> None of the blocks seem to work - all of them have invalid magic. > > Verify that the partition table still appears to be correct. If it > is pointing to the wrong starting location, none of the super blocks > will appear in the expected places. You might see if /testdisk/can > find any intact super blocks. > > Consider using a hex editor to look at some of the super blocks. > They should contain the same data. The data that actually appears > there might give some clue as to what happened. > > As a last ditch recovery effort, run mke2fs/mke3fs with the "-S" > option to initialize the super blocks and group descriptors only. > Do this only with (or on) a backup copy of the partition, since > it is potentially destructive. Then see if /debugfs/can make > sense of the filesystem, and if so, run /fsck/with the "-f" > option to repair the metadata. On 09/19/2014 07:16 PM, Chris Murphy wrote: > On Sep 19, 2014, at 11:49 AM, jd1008 wrote: > >> On 09/19/2014 08:39 AM, Robert Nichols wrote: >>> On 09/18/2014 10:57 PM, jd1008 wrote: >>>> I ran mkfs.ext3 -S /dev/sdc7 >>>> then ran fsck.ext3 -y /dev/sdc7 >>>> it blew away EVERYTHING :) >>>> >>>> Back to square one and re-dd original to test drive >>>> and start over. >>> Ouch! That _used_ to work. Trying it just now, "mke3fs -S" seems >>> to clear a substantial portion of the inodes, which the manpage >>> specifically says it should _not_ do, and then /fsck/ completes the >>> destruction by moving all of the remaining inodes to lost+found. >>> >>> Sorry about that. >>> >> Can raise a bug against it? > Chances are this is an upstream bug, or a misunderstanding. You should post your reproduce steps to the ext4 list, what you expect to happen based on man page, and what actually happens. > http://vger.kernel.org/vger-lists.html#linux-ext4 > > > Chris Murphy From adilger at dilger.ca Sat Sep 20 06:07:30 2014 From: adilger at dilger.ca (Andreas Dilger) Date: Sat, 20 Sep 2014 00:07:30 -0600 Subject: Possible bug in mkfs.ext3 In-Reply-To: <541CDED5.7030100@gmail.com> References: <541CDED5.7030100@gmail.com> Message-ID: On Sep 19, 2014, at 7:56 PM, jd1008 wrote: > I am reporting this on the advice of the Fedora Users Mailing List Member. > > This the mailing list exchange outlining the problem with specifying -S to mkfs, and it's subsequent consequences when fsck is run. > > I am reporting this per suggestions made to me on the Fedora Users Mailing List. I would say that "mke2fs -S" is going to lead to worse corruption rather than improving the situation in 999 times of 1000. It should only be used by someone who knows very specific details of the filesystem and how it was corrupted. I'm tempted to make it an "undocumented" feature, since I suspect it will do more harm than good in most cases. "-S" should at least call check_plausibility() and proceed_question() before clobbering the filesystem. Better would be something like the "findsuper" utility in the e2fsprogs sources (attached here for your conveniece). Usually in cases like this the problem is actually something with the partition table, and not that all of your backup superblocks have mysteriously been corrupted at the same time. Cheers, Andreas > The following is the mailing list exchange: > > > On 09/18/2014 07:01 PM, Robert Nichols wrote: >> On 09/18/2014 12:37 PM, jd1008 wrote: >>> Is there any other tool that can extract files from a partition that >>> seems to have corrupted superblocks? >>> I tried dumpe2fs, and fsck -b >>> to no avail. Tried all available block numbers that are listed >>> when original mkfs was done, and it's output was saved. >>> >>> None of the blocks seem to work - all of them have invalid magic. >> >> Verify that the partition table still appears to be correct. If it >> is pointing to the wrong starting location, none of the super blocks >> will appear in the expected places. You might see if /testdisk/can >> find any intact super blocks. >> >> Consider using a hex editor to look at some of the super blocks. >> They should contain the same data. The data that actually appears >> there might give some clue as to what happened. >> >> As a last ditch recovery effort, run mke2fs/mke3fs with the "-S" >> option to initialize the super blocks and group descriptors only. >> Do this only with (or on) a backup copy of the partition, since >> it is potentially destructive. Then see if /debugfs/can make >> sense of the filesystem, and if so, run /fsck/with the "-f" >> option to repair the metadata. > > > On 09/19/2014 07:16 PM, Chris Murphy wrote: >> On Sep 19, 2014, at 11:49 AM, jd1008 wrote: >> >>> On 09/19/2014 08:39 AM, Robert Nichols wrote: >>>> On 09/18/2014 10:57 PM, jd1008 wrote: >>>>> I ran mkfs.ext3 -S /dev/sdc7 >>>>> then ran fsck.ext3 -y /dev/sdc7 >>>>> it blew away EVERYTHING :) >>>>> >>>>> Back to square one and re-dd original to test drive >>>>> and start over. >>>> Ouch! That _used_ to work. Trying it just now, "mke3fs -S" seems >>>> to clear a substantial portion of the inodes, which the manpage >>>> specifically says it should _not_ do, and then /fsck/ completes the >>>> destruction by moving all of the remaining inodes to lost+found. >>>> >>>> Sorry about that. >>>> >>> Can raise a bug against it? >> Chances are this is an upstream bug, or a misunderstanding. You should post your reproduce steps to the ext4 list, what you expect to happen based on man page, and what actually happens. >> http://vger.kernel.org/vger-lists.html#linux-ext4 >> >> >> Chris Murphy > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users Cheers, Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: findsuper.c Type: application/octet-stream Size: 8259 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tytso at mit.edu Sat Sep 20 18:14:32 2014 From: tytso at mit.edu (Theodore Ts'o) Date: Sat, 20 Sep 2014 14:14:32 -0400 Subject: Possible bug in mkfs.ext3 In-Reply-To: <541CDED5.7030100@gmail.com> References: <541CDED5.7030100@gmail.com> Message-ID: <20140920181432.GB14788@thunk.org> On Fri, Sep 19, 2014 at 07:56:37PM -0600, jd1008 wrote: > I am reporting this on the advice of the Fedora Users Mailing List Member. > > This the mailing list exchange outlining the problem with specifying -S to > mkfs, > and it's subsequent consequences when fsck is run. If none of the possible superblocks are valid when using mke2fs -b , there's a good chance that your partition table (or LVM metadata) has gotten corrupted. You should definitely check to make sure the partition setup is sane before trying to use mke2fs -S. It's also true, as Andreas has stated, that with the large number of new file system options and layouts with ext4, mke2fs -S is much more hazardous unless you __really__ know what you are doing. It would probably be a good idea to have some warning messages to that effect in the man page. - Ted From jd1008 at gmail.com Sat Sep 20 18:38:18 2014 From: jd1008 at gmail.com (jd1008) Date: Sat, 20 Sep 2014 12:38:18 -0600 Subject: Possible bug in mkfs.ext3 In-Reply-To: <20140920181432.GB14788@thunk.org> References: <541CDED5.7030100@gmail.com> <20140920181432.GB14788@thunk.org> Message-ID: <541DC99A.40807@gmail.com> The -S was advised by a member of the Fedora Users Mailing List, and I thought I would try it. I still have the original disk, so no permanent harm. I keep trying what is suggested on a copy of the partition. Only drag is the copying :) It is a 400GiB partition (400 * 1024^3). I am currently scanning the parition for a superblock, starting at -b 0, and keep incrementing by 512, until I find what"might be" a superblock; i.e. fsck does not say "Bad magic number". Of course, that's no guarantee it is a superblock, but it gives me an opportunity to examine the superblock at that offset. Regards, JD On 09/20/2014 12:14 PM, Theodore Ts'o wrote: > On Fri, Sep 19, 2014 at 07:56:37PM -0600, jd1008 wrote: >> I am reporting this on the advice of the Fedora Users Mailing List Member. >> >> This the mailing list exchange outlining the problem with specifying -S to >> mkfs, >> and it's subsequent consequences when fsck is run. > If none of the possible superblocks are valid when using mke2fs -b > , there's a good chance that your partition table (or LVM > metadata) has gotten corrupted. You should definitely check to make > sure the partition setup is sane before trying to use mke2fs -S. > > It's also true, as Andreas has stated, that with the large number of > new file system options and layouts with ext4, mke2fs -S is much more > hazardous unless you __really__ know what you are doing. It would > probably be a good idea to have some warning messages to that effect > in the man page. > > - Ted > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jd1008 at gmail.com Sun Sep 21 00:01:35 2014 From: jd1008 at gmail.com (jd1008) Date: Sat, 20 Sep 2014 18:01:35 -0600 Subject: Possible bug in mkfs.ext3 In-Reply-To: References: <541CDED5.7030100@gmail.com> Message-ID: <541E155F.5050108@gmail.com> On 09/20/2014 12:07 AM, Andreas Dilger wrote: > On Sep 19, 2014, at 7:56 PM, jd1008 wrote: >> I am reporting this on the advice of the Fedora Users Mailing List Member. >> >> This the mailing list exchange outlining the problem with specifying -S to mkfs, and it's subsequent consequences when fsck is run. >> >> I am reporting this per suggestions made to me on the Fedora Users Mailing List. > I would say that "mke2fs -S" is going to lead to worse corruption rather > than improving the situation in 999 times of 1000. It should only be > used by someone who knows very specific details of the filesystem and > how it was corrupted. I'm tempted to make it an "undocumented" feature, > since I suspect it will do more harm than good in most cases. "-S" > should at least call check_plausibility() and proceed_question() before > clobbering the filesystem. > > Better would be something like the "findsuper" utility in the e2fsprogs > sources (attached here for your conveniece). Usually in cases like this > the problem is actually something with the partition table, and not that > all of your backup superblocks have mysteriously been corrupted at the > same time. > > Cheers, Andreas > >> The following is the mailing list exchange: >> >> >> On 09/18/2014 07:01 PM, Robert Nichols wrote: >>> On 09/18/2014 12:37 PM, jd1008 wrote: >>>> Is there any other tool that can extract files from a partition that >>>> seems to have corrupted superblocks? >>>> I tried dumpe2fs, and fsck -b >>>> to no avail. Tried all available block numbers that are listed >>>> when original mkfs was done, and it's output was saved. >>>> >>>> None of the blocks seem to work - all of them have invalid magic. >>> Verify that the partition table still appears to be correct. If it >>> is pointing to the wrong starting location, none of the super blocks >>> will appear in the expected places. You might see if /testdisk/can >>> find any intact super blocks. >>> >>> Consider using a hex editor to look at some of the super blocks. >>> They should contain the same data. The data that actually appears >>> there might give some clue as to what happened. >>> >>> As a last ditch recovery effort, run mke2fs/mke3fs with the "-S" >>> option to initialize the super blocks and group descriptors only. >>> Do this only with (or on) a backup copy of the partition, since >>> it is potentially destructive. Then see if /debugfs/can make >>> sense of the filesystem, and if so, run /fsck/with the "-f" >>> option to repair the metadata. >> >> On 09/19/2014 07:16 PM, Chris Murphy wrote: >>> On Sep 19, 2014, at 11:49 AM, jd1008 wrote: >>> >>>> On 09/19/2014 08:39 AM, Robert Nichols wrote: >>>>> On 09/18/2014 10:57 PM, jd1008 wrote: >>>>>> I ran mkfs.ext3 -S /dev/sdc7 >>>>>> then ran fsck.ext3 -y /dev/sdc7 >>>>>> it blew away EVERYTHING :) >>>>>> >>>>>> Back to square one and re-dd original to test drive >>>>>> and start over. >>>>> Ouch! That _used_ to work. Trying it just now, "mke3fs -S" seems >>>>> to clear a substantial portion of the inodes, which the manpage >>>>> specifically says it should _not_ do, and then /fsck/ completes the >>>>> destruction by moving all of the remaining inodes to lost+found. >>>>> >>>>> Sorry about that. >>>>> >>>> Can raise a bug against it? >>> Chances are this is an upstream bug, or a misunderstanding. You should post your reproduce steps to the ext4 list, what you expect to happen based on man page, and what actually happens. >>> http://vger.kernel.org/vger-lists.html#linux-ext4 >>> >>> >>> Chris Murphy >>> Update: Since I had believed, and it has been mentioned, that there is a possibility that the partition table itself may have been clobbered in a way to change the real starting address of the partition, I decided to search for possible candidates for a superblock using fsck in a shell script as follows: sb=0; while [ $sb -lt 429496729600 ]; do possibleSB=`e2fsck -n -b $sb /dev/sdc7 2>&1 | grep 'The superblock could not be read|Bad magic number'` [ "x$possibleSB" = "x" ] && echo $sb - "$possibleSB" sb=`expr $sb + 512` done > possibleSB I found these blocks, the value of which might hint that the current start block of the partition may have been altered: 1325056 2373632 3815424 6553600 13376000 13391872 13407744 13423616 13439488 Running fsck /dev/sdc7: for sb in 1325056 2373632 3815424 6553600 13376000 13391872 13407744 13423616 13439488 ; do echo fsck -b $sb /dev/sdc7 fsck -b $sb /dev/sdc7 echo ================= done ================================================================================= fsck -b 1325056 /dev/sdc7 fsck from util-linux 2.24.2 e2fsck 1.42.8 (20-Jun-2013) Superblock has an invalid journal (inode 8). Clear? no fsck.ext2: Illegal inode number while checking ext3 journal for /dev/sdc7 /dev/sdc7: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sdc7: ********** WARNING: Filesystem still has errors ********** ================= fsck -b 2373632 /dev/sdc7 fsck from util-linux 2.24.2 e2fsck 1.42.8 (20-Jun-2013) Superblock has an invalid journal (inode 8). Clear? no fsck.ext2: Illegal inode number while checking ext3 journal for /dev/sdc7 /dev/sdc7: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sdc7: ********** WARNING: Filesystem still has errors ********** ================= fsck -b 3815424 /dev/sdc7 fsck from util-linux 2.24.2 e2fsck 1.42.8 (20-Jun-2013) Superblock has an invalid journal (inode 8). Clear? no fsck.ext2: Illegal inode number while checking ext3 journal for /dev/sdc7 /dev/sdc7: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sdc7: ********** WARNING: Filesystem still has errors ********** ================= fsck -b 6553600 /dev/sdc7 fsck from util-linux 2.24.2 e2fsck 1.42.8 (20-Jun-2013) fsck.ext2: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc7 Could this be a zero-length partition? ================= fsck -b 13376000 /dev/sdc7 fsck from util-linux 2.24.2 e2fsck 1.42.8 (20-Jun-2013) Superblock has an invalid journal (inode 8). Clear? no fsck.ext2: Illegal inode number while checking ext3 journal for /dev/sdc7 /dev/sdc7: ********** WARNING: Filesystem still has errors ********** ================= fsck -b 13391872 /dev/sdc7 fsck from util-linux 2.24.2 e2fsck 1.42.8 (20-Jun-2013) Superblock has an invalid journal (inode 8). Clear? no fsck.ext2: Illegal inode number while checking ext3 journal for /dev/sdc7 /dev/sdc7: ********** WARNING: Filesystem still has errors ********** ================= fsck -b 13407744 /dev/sdc7 fsck from util-linux 2.24.2 e2fsck 1.42.8 (20-Jun-2013) Superblock has an invalid journal (inode 8). Clear? no fsck.ext2: Illegal inode number while checking ext3 journal for /dev/sdc7 /dev/sdc7: ********** WARNING: Filesystem still has errors ********** ================= fsck -b 13423616 /dev/sdc7 fsck from util-linux 2.24.2 e2fsck 1.42.8 (20-Jun-2013) Superblock has an invalid journal (inode 8). Clear? no fsck.ext2: Illegal inode number while checking ext3 journal for /dev/sdc7 /dev/sdc7: ********** WARNING: Filesystem still has errors ********** ================= fsck -b 13439488 /dev/sdc7 fsck from util-linux 2.24.2 e2fsck 1.42.8 (20-Jun-2013) Superblock has an invalid journal (inode 8). Clear? no fsck.ext2: Illegal inode number while checking ext3 journal for /dev/sdc7 /dev/sdc7: ********** WARNING: Filesystem still has errors ********** ================= So, of the possible sb's above, which one looks promising? From tytso at mit.edu Sun Sep 21 01:09:42 2014 From: tytso at mit.edu (Theodore Ts'o) Date: Sat, 20 Sep 2014 21:09:42 -0400 Subject: Possible bug in mkfs.ext3 In-Reply-To: <541E155F.5050108@gmail.com> References: <541CDED5.7030100@gmail.com> <541E155F.5050108@gmail.com> Message-ID: <20140921010942.GA16578@thunk.org> On Sat, Sep 20, 2014 at 06:01:35PM -0600, jd1008 wrote: > Update: > Since I had believed, and it has been mentioned, that there is a possibility > that the partition > table itself may have been clobbered in a way to change the real starting > address of the partition, > I decided to search for possible candidates for a superblock using fsck in a > shell script as follows.... Um.... if the starting location of the partition is wrong, you do ***not**** want to run fsck until fix the partition boundaries. Using fsck -b Dear all, (please Cc) I am running latest kernel (3.17-rc6) and I see corruption of an usb3.0 device usb stick. Strange errors, impossibility to mount. Repeated unplugging and replugging helps sometimes, in all cases recovery is necessary. Is this a know problem, a problem of my system Debian/sid, uptodate, self-compiled kernel of the suspend program (that initiates the suspend), the usb stick and file system, or the USB subsystem? I happily provide loads of further details about hardware, logs, whatever, but first I ask before sending tons of useless stuff!? Any idea? Thanks a lot Norbert ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 ------------------------------------------------------------------------ From stern at rowland.harvard.edu Sat Sep 27 15:57:36 2014 From: stern at rowland.harvard.edu (Alan Stern) Date: Sat, 27 Sep 2014 11:57:36 -0400 (EDT) Subject: problems with usb stick after suspend and wake up In-Reply-To: <20140927120749.GM7588@auth.logic.tuwien.ac.at> Message-ID: On Sat, 27 Sep 2014, Norbert Preining wrote: > Dear all, > > (please Cc) > > I am running latest kernel (3.17-rc6) and I see corruption of an usb3.0 > device usb stick. Strange errors, impossibility to mount. > > Repeated unplugging and replugging helps sometimes, in all cases > recovery is necessary. > > Is this a know problem, a problem of my system > Debian/sid, uptodate, self-compiled kernel > of the suspend program (that initiates the suspend), > the usb stick and file system, or the USB subsystem? > > I happily provide loads of further details about hardware, logs, whatever, > but first I ask before sending tons of useless stuff!? > > Any idea? I do not recognize this problem based on your description. Please post the dmesg log. Alan Stern From preining at logic.at Sun Sep 28 12:05:34 2014 From: preining at logic.at (Norbert Preining) Date: Sun, 28 Sep 2014 21:05:34 +0900 Subject: problems with usb stick after suspend and wake up In-Reply-To: References: <20140927120749.GM7588@auth.logic.tuwien.ac.at> Message-ID: <20140928120534.GT7588@auth.logic.tuwien.ac.at> Hi Alan, thanks for your answer. > I do not recognize this problem based on your description. Please post > the dmesg log. Here cleaned output of journalctl, removed mainly networkmanager stuff. This is about a wake up after sleep, where before the stick was ok. More details necessary, let me know. Thanks Norbert ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 ------------------------------------------------------------------------ -------------- next part -------------- Sep 28 20:57:50 wienerschnitzel kernel: Restarting tasks ... Sep 28 20:57:50 wienerschnitzel kernel: pci_bus 0000:01: Allocating resources Sep 28 20:57:50 wienerschnitzel kernel: pci_bus 0000:02: Allocating resources Sep 28 20:57:50 wienerschnitzel kernel: pci_bus 0000:03: Allocating resources Sep 28 20:57:50 wienerschnitzel kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Sep 28 20:57:50 wienerschnitzel kernel: pci_bus 0000:01: Allocating resources Sep 28 20:57:50 wienerschnitzel kernel: pci_bus 0000:02: Allocating resources Sep 28 20:57:50 wienerschnitzel kernel: pci_bus 0000:03: Allocating resources Sep 28 20:57:50 wienerschnitzel kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Sep 28 20:57:50 wienerschnitzel kernel: done. Sep 28 20:57:50 wienerschnitzel kernel: Bluetooth: hci0: read Intel version: 370710018002030d00 Sep 28 20:57:50 wienerschnitzel kernel: Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq Sep 28 20:57:50 wienerschnitzel kernel: Bluetooth: hci0: Intel Bluetooth firmware patch completed and activated Sep 28 20:57:50 wienerschnitzel kernel: iwlwifi 0000:01:00.0: L1 Disabled; Enabling L0S Sep 28 20:57:50 wienerschnitzel kernel: iwlwifi 0000:01:00.0: L1 Disabled; Enabling L0S Sep 28 20:57:50 wienerschnitzel kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Sep 28 20:57:50 wienerschnitzel kernel: sdb: sdb1 Sep 28 20:57:53 wienerschnitzel systemd[1]: Found device AP-U6 1. Sep 28 20:57:53 wienerschnitzel systemd[1]: Found device AP-U6 1. Sep 28 20:57:53 wienerschnitzel systemd[1]: Mounting /media/knubbel... Sep 28 20:57:53 wienerschnitzel systemd[1]: Mounted /media/knubbel. Sep 28 20:57:53 wienerschnitzel kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) Sep 28 20:57:53 wienerschnitzel org.gtk.Private.UDisks2VolumeMonitor[1870]: index_parse.c:191: indx_parse(): error opening /media/knubbel/BDMV/index.bdmv Sep 28 20:57:53 wienerschnitzel org.gtk.Private.UDisks2VolumeMonitor[1870]: index_parse.c:191: indx_parse(): error opening /media/knubbel/BDMV/BACKUP/index.bdmv Sep 28 20:57:58 wienerschnitzel kernel: usb 3-1: reset SuperSpeed USB device number 4 using xhci_hcd Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca00 Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca48 Sep 28 20:57:59 wienerschnitzel kernel: usb 3-1: reset SuperSpeed USB device number 4 using xhci_hcd Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca00 Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca48 Sep 28 20:57:59 wienerschnitzel kernel: usb 3-1: reset SuperSpeed USB device number 4 using xhci_hcd Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca00 Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca48 Sep 28 20:57:59 wienerschnitzel kernel: usb 3-1: reset SuperSpeed USB device number 4 using xhci_hcd Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca00 Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca48 Sep 28 20:57:59 wienerschnitzel kernel: usb 3-1: reset SuperSpeed USB device number 4 using xhci_hcd Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca00 Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca48 Sep 28 20:57:59 wienerschnitzel kernel: usb 3-1: reset SuperSpeed USB device number 4 using xhci_hcd Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca00 Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca48 Sep 28 20:57:59 wienerschnitzel kernel: sd 4:0:0:0: [sdb] Sep 28 20:57:59 wienerschnitzel kernel: Result: hostbyte=0x07 driverbyte=0x00 Sep 28 20:57:59 wienerschnitzel kernel: sd 4:0:0:0: [sdb] CDB: Sep 28 20:57:59 wienerschnitzel kernel: cdb[0]=0x2a: 2a 00 03 84 1f 80 00 00 08 00 Sep 28 20:57:59 wienerschnitzel kernel: end_request: I/O error, dev sdb, sector 58990464 Sep 28 20:57:59 wienerschnitzel kernel: Buffer I/O error on device sdb1, logical block 7372800 Sep 28 20:57:59 wienerschnitzel kernel: lost page write due to I/O error on sdb1 Sep 28 20:57:59 wienerschnitzel kernel: JBD2: Error -5 detected when updating journal superblock for sdb1-8. Sep 28 20:57:59 wienerschnitzel kernel: sd 4:0:0:0: [sdb] Sep 28 20:57:59 wienerschnitzel kernel: Result: hostbyte=0x00 driverbyte=0x08 Sep 28 20:57:59 wienerschnitzel kernel: sd 4:0:0:0: [sdb] Sep 28 20:57:59 wienerschnitzel kernel: Sense Key : 0x7 [current] Sep 28 20:57:59 wienerschnitzel kernel: sd 4:0:0:0: [sdb] Sep 28 20:57:59 wienerschnitzel kernel: ASC=0x27 ASCQ=0x0 Sep 28 20:57:59 wienerschnitzel kernel: sd 4:0:0:0: [sdb] CDB: Sep 28 20:57:59 wienerschnitzel kernel: cdb[0]=0x2a: 2a 00 03 84 1f 88 00 00 10 00 Sep 28 20:57:59 wienerschnitzel kernel: end_request: critical target error, dev sdb, sector 58990472 Sep 28 20:57:59 wienerschnitzel kernel: Aborting journal on device sdb1-8. Sep 28 20:57:59 wienerschnitzel kernel: usb 3-1: reset SuperSpeed USB device number 4 using xhci_hcd Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca00 Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca48 Sep 28 20:57:59 wienerschnitzel kernel: usb 3-1: reset SuperSpeed USB device number 4 using xhci_hcd Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca00 Sep 28 20:57:59 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca48 Sep 28 20:58:00 wienerschnitzel kernel: usb 3-1: reset SuperSpeed USB device number 4 using xhci_hcd Sep 28 20:58:00 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca00 Sep 28 20:58:00 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca48 Sep 28 20:58:00 wienerschnitzel kernel: usb 3-1: reset SuperSpeed USB device number 4 using xhci_hcd Sep 28 20:58:00 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca00 Sep 28 20:58:00 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca48 Sep 28 20:58:00 wienerschnitzel kernel: usb 3-1: reset SuperSpeed USB device number 4 using xhci_hcd Sep 28 20:58:00 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca00 Sep 28 20:58:00 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca48 Sep 28 20:58:00 wienerschnitzel kernel: usb 3-1: reset SuperSpeed USB device number 4 using xhci_hcd Sep 28 20:58:00 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca00 Sep 28 20:58:00 wienerschnitzel kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801f256ca48 Sep 28 20:58:00 wienerschnitzel kernel: sd 4:0:0:0: [sdb] Sep 28 20:58:00 wienerschnitzel kernel: Result: hostbyte=0x07 driverbyte=0x00 Sep 28 20:58:00 wienerschnitzel kernel: sd 4:0:0:0: [sdb] CDB: Sep 28 20:58:00 wienerschnitzel kernel: cdb[0]=0x2a: 2a 00 03 84 1f 80 00 00 08 00 Sep 28 20:58:00 wienerschnitzel kernel: end_request: I/O error, dev sdb, sector 58990464 Sep 28 20:58:00 wienerschnitzel kernel: Buffer I/O error on device sdb1, logical block 7372800 Sep 28 20:58:00 wienerschnitzel kernel: lost page write due to I/O error on sdb1 Sep 28 20:58:00 wienerschnitzel kernel: JBD2: Error -5 detected when updating journal superblock for sdb1-8. From stern at rowland.harvard.edu Sun Sep 28 14:24:21 2014 From: stern at rowland.harvard.edu (Alan Stern) Date: Sun, 28 Sep 2014 10:24:21 -0400 (EDT) Subject: problems with usb stick after suspend and wake up In-Reply-To: <20140928120534.GT7588@auth.logic.tuwien.ac.at> Message-ID: On Sun, 28 Sep 2014, Norbert Preining wrote: > Hi Alan, > > thanks for your answer. > > > I do not recognize this problem based on your description. Please post > > the dmesg log. > > Here cleaned output of journalctl, removed mainly networkmanager stuff. I would have preferred to see the output from dmesg, as I requested. But never mind, there probably isn't enough information in either log. > This is about a wake up after sleep, where before the stick was ok. > > More details necessary, let me know. Please collect a usbmon trace for that bus (bus 3), starting before the suspend and ending after the resume. Alan Stern From preining at logic.at Mon Sep 29 00:46:00 2014 From: preining at logic.at (Norbert Preining) Date: Mon, 29 Sep 2014 09:46:00 +0900 Subject: problems with usb stick after suspend and wake up In-Reply-To: References: <20140928120534.GT7588@auth.logic.tuwien.ac.at> Message-ID: <20140929004600.GV7588@auth.logic.tuwien.ac.at> Hi Alan, sorry for the journalctl output. I have now done the following:L * boot into 3.17-rc7 * mount the usb stick (recovery completed) * unmount, mount, unmount - just to be sure all is fine * started usbmon capturing on bus 3 * mount the usb stick * suspend to ram * wake up now the stick is "officially" mounted (/proc/mounts) * umount error messages pop up * try to mount more error messages * capture dmesg output * stip usbmon The two files are available here: http://www.preining.info/kernel/3.mon.out.gz (size 21596) http://www.preining.info/kernel/3.mon.out (size 216343) and http://www.preining.info/kernel/dmesg.log.gz (size 17883) http://www.preining.info/kernel/dmesg.log (size 67734) Just a few more things: * usb persistency is turned on * I checked the stick with badblocks during creation of the fs All the best Norbert ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 ------------------------------------------------------------------------ From stern at rowland.harvard.edu Mon Sep 29 14:15:15 2014 From: stern at rowland.harvard.edu (Alan Stern) Date: Mon, 29 Sep 2014 10:15:15 -0400 (EDT) Subject: problems with usb stick after suspend and wake up In-Reply-To: <20140929004600.GV7588@auth.logic.tuwien.ac.at> Message-ID: On Mon, 29 Sep 2014, Norbert Preining wrote: > Hi Alan, > > sorry for the journalctl output. I have now done the following:L > > * boot into 3.17-rc7 > * mount the usb stick (recovery completed) > * unmount, mount, unmount - just to be sure all is fine > * started usbmon capturing on bus 3 > * mount the usb stick > * suspend to ram > * wake up > now the stick is "officially" mounted (/proc/mounts) > * umount > error messages pop up > * try to mount > more error messages > * capture dmesg output > * stip usbmon > > The two files are available here: > http://www.preining.info/kernel/3.mon.out.gz (size 21596) > http://www.preining.info/kernel/3.mon.out (size 216343) > and > http://www.preining.info/kernel/dmesg.log.gz (size 17883) > http://www.preining.info/kernel/dmesg.log (size 67734) > > Just a few more things: > * usb persistency is turned on > * I checked the stick with badblocks during creation of the fs The first error occurred the first time the computer tried to write data to the stick following the resume. Oddly enough, an earlier write before the suspend worked correctly. But the real problem occurred when the computer asked the stick to provide the reason for the error. At that point the stick refused to answer. There were several resets, and the write was retried after each reset. And each time the write failed, and the stick refused to answer when asked the reason for the failure. There's no obvious cause for this problem. It really looks like something is wrong with the USB stick. Alan Stern From ibaldo at adinet.com.uy Mon Sep 29 14:31:45 2014 From: ibaldo at adinet.com.uy (Ivan Baldo) Date: Mon, 29 Sep 2014 11:31:45 -0300 Subject: problems with usb stick after suspend and wake up In-Reply-To: References: Message-ID: <54296D51.8030104@adinet.com.uy> El 29/09/14 11:15, Alan Stern escribi?: > The first error occurred the first time the computer tried to write > data to the stick following the resume. Oddly enough, an earlier write > before the suspend worked correctly. But the real problem occurred > when the computer asked the stick to provide the reason for the error. > At that point the stick refused to answer. > > There were several resets, and the write was retried after each reset. > And each time the write failed, and the stick refused to answer when > asked the reason for the failure. > > There's no obvious cause for this problem. It really looks like > something is wrong with the USB stick. Ok the culprit is the USB stick, but when retrying and seeing that the resets are unsuccessful, could the USB power be removed for the stick for half a second and restored and the write retried then? Have a nice day! P.s.: sorry if I am saying nonsense... -- Ivan Baldo - ibaldo at adinet.com.uy - http://ibaldo.codigolibre.net/ From Montevideo, Uruguay, at the south of South America. Freelance programmer and GNU/Linux system administrator, hire me! Alternatives: ibaldo at codigolibre.net - http://go.to/ibaldo From stern at rowland.harvard.edu Mon Sep 29 14:46:43 2014 From: stern at rowland.harvard.edu (Alan Stern) Date: Mon, 29 Sep 2014 10:46:43 -0400 (EDT) Subject: problems with usb stick after suspend and wake up In-Reply-To: <54296D51.8030104@adinet.com.uy> Message-ID: On Mon, 29 Sep 2014, Ivan Baldo wrote: > El 29/09/14 11:15, Alan Stern escribi?: > > The first error occurred the first time the computer tried to write > > data to the stick following the resume. Oddly enough, an earlier write > > before the suspend worked correctly. But the real problem occurred > > when the computer asked the stick to provide the reason for the error. > > At that point the stick refused to answer. > > > > There were several resets, and the write was retried after each reset. > > And each time the write failed, and the stick refused to answer when > > asked the reason for the failure. > > > > There's no obvious cause for this problem. It really looks like > > something is wrong with the USB stick. > Ok the culprit is the USB stick, but when retrying and seeing that > the resets are unsuccessful, could the USB power be removed for the > stick for half a second and restored and the write retried then? The simple answer is No. Host USB controllers often are not capable of turning off USB power. Besides, what would happen if the device were not a stick but a disk drive with an external power supply? Alan Stern From preining at logic.at Mon Sep 29 23:12:15 2014 From: preining at logic.at (Norbert Preining) Date: Tue, 30 Sep 2014 08:12:15 +0900 Subject: problems with usb stick after suspend and wake up In-Reply-To: References: <20140929004600.GV7588@auth.logic.tuwien.ac.at> Message-ID: <20140929231215.GR7588@auth.logic.tuwien.ac.at> Hi Alan, On Mon, 29 Sep 2014, Alan Stern wrote: > There were several resets, and the write was retried after each reset. > And each time the write failed, and the stick refused to answer when > asked the reason for the failure. > > There's no obvious cause for this problem. It really looks like > something is wrong with the USB stick. Hmm, ok, thanks. I think I will return it then. I hope they accept my explanation about it. Thanks for looking into it!!! Norbert ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 ------------------------------------------------------------------------