My Lexar usb stick used to mount perfectly with kernels <=2.6.7, now mounts after about a minute with 2.6.9 but cannot be mounted at all with 2.6.10 or 2.6.11-r2. I'm always using gentoo-dev-sources. My notebook is Acer Ferrari 3000, same motherboard as Acer Aspire 1450. I'm mounting the stick manually with 'mount'. Reproducible: Always Steps to Reproduce: 1. plug the stick in 2. mount /mnt/whatever 3. wait Actual Results: Waited more the one minute to get just an error message about kernel being unable to read boot sector. Expected Results: The stick gets mounted and I could use it as previously. System uname: 2.6.9-gentoo-r13 i686 Mobile AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 10 2005, 00:34:49)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=athlon-xp -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/cursors/xorg-x11/default /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=athlon-xp -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo http://ftp.easynet.nl/mirror/gentoo" LANG="pl_PL.UTF-8" LC_ALL="pl_PL.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow X acpi alsa apache2 avi berkdb bitmap-fonts cdr crypt cups curl dri dvd dvdr emboss encode evo fam fbcon flac font-server gcj gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 imlib java javascript jikes jpeg junit libg++ libwww mad maildir mikmod mmx mozilla mozsvg mp3 mpeg mysql ncurses nls oggvorbis opengl oss pam pcmcia pdflib perl png ppds python quicktime readline scanner sdl slang spell sse ssl svg svga tcpd threads tiff truetype truetype-fonts type1-fonts unicode usb x86 xml xml2 xmms xv zlib linguas_pl" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS
Created attachment 53061 [details] part of kernel log generated when the stick was pugged in Can provide other logs of usb camera or of a built-in flash card reader.
I installed vanilla kernel 2.6.11.2 and plugged the stick in. Got the same error, exact message on the console was 'mount: can't read superblock'.
Can you please try to have it automatically mounted with ivman when you plug it in? assuming you use udev(otherwise please switch to it): emerge -va ivman /etc/init.d/ivman start [plug in stick] ls /media -l I just want to make sure that it is a herdware problem. Can you please also post lsmod?
I tried first gentoo-dev-sources-2.6.9-r13. ivman (0.5_pre2) did not mount my usb stick but it mounted a cd I inserted. Though hal (0.4.2-r1) detected the stick and reported all details when I executed lshal. Then I rebooted to vanilla 2.6.11.2 but wasn't able to test ivman. Once hal deamon was started, it kept printing these messages constantly to /var/log/messages: Mar 11 23:42:30 ahoj usb-storage: Command TEST_UNIT_READY (6 bytes) Mar 11 23:42:30 ahoj usb-storage: 00 00 00 00 00 00 Mar 11 23:42:30 ahoj usb-storage: Bulk Command S 0x43425355 T 0x47 L 0 F 0 Trg 0 LUN 0 CL 6 Mar 11 23:42:30 ahoj usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Mar 11 23:42:30 ahoj usb-storage: Status code 0; transferred 31/31 Mar 11 23:42:30 ahoj usb-storage: -- transfer complete Mar 11 23:42:30 ahoj usb-storage: Bulk command transfer result=0 Mar 11 23:42:30 ahoj usb-storage: Attempting to get CSW... Mar 11 23:42:30 ahoj usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Mar 11 23:42:30 ahoj usb-storage: Status code 0; transferred 13/13 Mar 11 23:42:30 ahoj usb-storage: -- transfer complete Mar 11 23:42:30 ahoj usb-storage: Bulk status result = 0 Mar 11 23:42:30 ahoj usb-storage: Bulk Status S 0x53425355 T 0x47 R 0 Stat 0x1 Mar 11 23:42:30 ahoj usb-storage: -- transport indicates command failure Mar 11 23:42:30 ahoj usb-storage: Issuing auto-REQUEST_SENSE Mar 11 23:42:30 ahoj usb-storage: Bulk Command S 0x43425355 T 0x80000047 L 18 F 128 Trg 0 LUN 0 CL 6 Mar 11 23:42:30 ahoj usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Mar 11 23:42:30 ahoj usb-storage: Status code 0; transferred 31/31 Mar 11 23:42:30 ahoj usb-storage: -- transfer complete Mar 11 23:42:30 ahoj usb-storage: Bulk command transfer result=0 Mar 11 23:42:30 ahoj usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes Mar 11 23:42:30 ahoj usb-storage: Status code 0; transferred 18/18 Mar 11 23:42:30 ahoj usb-storage: -- transfer complete Mar 11 23:42:30 ahoj usb-storage: Bulk data transfer result 0x0 Mar 11 23:42:30 ahoj usb-storage: Attempting to get CSW... Mar 11 23:42:30 ahoj usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Mar 11 23:42:30 ahoj usb-storage: Status code 0; transferred 13/13 Mar 11 23:42:30 ahoj usb-storage: -- transfer complete Mar 11 23:42:30 ahoj usb-storage: Bulk status result = 0 Mar 11 23:42:30 ahoj usb-storage: Bulk Status S 0x53425355 T 0x80000047 R 0 Stat 0x0 Mar 11 23:42:30 ahoj usb-storage: -- Result from auto-sense is 0 Mar 11 23:42:30 ahoj usb-storage: -- code: 0x70, key: 0x2, ASC: 0x3a, ASCQ: 0x0 Mar 11 23:42:30 ahoj usb-storage: Not Ready: Medium not present Mar 11 23:42:30 ahoj usb-storage: scsi cmd done, result=0x2 Mar 11 23:42:30 ahoj usb-storage: *** thread sleeping. Mar 11 23:42:30 ahoj usb-storage: queuecommand called Mar 11 23:42:30 ahoj usb-storage: *** thread awakened. I have a flash card reader in my notebook. lsmod said: Module Size Used by md5 3712 1 ipv6 240832 6 ipt_REJECT 5504 1 ipt_LOG 6592 3 ipt_limit 1984 2 ipt_state 1536 5 iptable_filter 2304 1 ip_tables 19712 5 ipt_REJECT,ipt_LOG,ipt_limit,ipt_state,iptable_filter snd_pcm_oss 48096 0 snd_mixer_oss 17600 1 snd_pcm_oss snd_seq_oss 32064 0 snd_seq_midi_event 6208 1 snd_seq_oss snd_seq 49744 4 snd_seq_oss,snd_seq_midi_event snd_intel8x0m 15236 0 snd_via82xx 22688 0 snd_ac97_codec 73720 2 snd_intel8x0m,snd_via82xx snd_pcm 82568 4 snd_pcm_oss,snd_intel8x0m,snd_via82xx,snd_ac97_codec snd_timer 21316 2 snd_seq,snd_pcm snd_page_alloc 7620 3 snd_intel8x0m,snd_via82xx,snd_pcm snd_mpu401_uart 6208 1 snd_via82xx snd_rawmidi 20192 1 snd_mpu401_uart snd_seq_device 6988 3 snd_seq_oss,snd_seq,snd_rawmidi snd 47652 12 snd_pcm_oss,snd_mixer_oss,snd_seq_oss,snd_seq,snd_intel8x0m,snd_via82xx,snd_ac97_codec,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device soundcore 7456 1 snd sd_mod 14288 0 af_packet 17096 2 usb_storage 103376 0 scsi_mod 122312 2 sd_mod,usb_storage usbhid 31104 0 usbmouse 4608 0 ehci_hcd 28744 0 uhci_hcd 29520 0 usbcore 105976 6 usb_storage,usbhid,usbmouse,ehci_hcd,uhci_hcd ip_conntrack_ftp 71632 0 ip_conntrack 38680 2 ipt_state,ip_conntrack_ftp via_rhine 19652 0 mii 4032 1 via_rhine unix 23668 22
Besides the change from /dev/sda to /dev/uba (ie, all scsi disk names appear to have changed) I also noticed some serious device borkage with 2.6.10 (I'm still testing 2.6.11). Many devices that are recognized fine in 2.6.8 and previous are completely horked (and mis-identified) with 2.6.10, and going back fixes everything. The only problem with going back is that newer hal versions must build against 2.6.10 or better (it will run with 2.6.8 but ocassionally breaks during runtime). That's all I have right now...
Krzysztof: Your log is showing some packet corruption which is odd. Can you definately confirm that this still works on older kernels? Also, am I right in assuming that attachment 53061 [details] is from 2.6.11? Can I see a log from 2.6.9? (Please don't compress them in future, text/plain is fine)
Steve: You are mistaken. uba is the new experimental usb-storage driver. Please go back to usb-storage for now, and if you do have any problems with that, please open another bug. http://dev.gentoo.org/~dsd/gentoo-dev-sources/issues-current.htm#2.6.9-ub
Hands down! I cannot configure a kernel with working usb-storage anymore... I tried older kernels as Daniel suggested. First, I tried KNOPPIX with 2.6.7, everything went fine, here's the log: Mar 13 09:23:05 Knoppix syslogd 1.4.1#15: restart. Mar 13 09:23:24 Knoppix usb.agent[1674]: usbcore: already loaded Mar 13 09:23:25 Knoppix input.agent[1831]: evdev: already loaded Mar 13 09:23:25 Knoppix input.agent[1800]: evdev: already loaded Mar 13 09:23:26 Knoppix input.agent[1919]: evdev: already loaded Mar 13 09:23:26 Knoppix input.agent[1904]: tsdev: already loaded Mar 13 09:23:26 Knoppix input.agent[1904]: joydev: already loaded Mar 13 09:23:26 Knoppix input.agent[1904]: evdev: already loaded Mar 13 09:23:26 Knoppix usb.agent[1977]: usb-storage: already loaded Mar 13 09:23:27 Knoppix scsi.agent[2020]: disk at /devices/pci0000:00/0000:00:10.2/usb3/3-1/3-1:1.0/host2/2:0:0:0 Mar 13 09:23:40 Knoppix usb.agent[2055]: usb-storage: already loaded Mar 13 09:23:41 Knoppix scsi.agent[2105]: disk at /devices/pci0000:00/0000:00:10.3/usb4/4-4/4-4:1.0/host3/3:0:0:0 Mar 13 09:25:26 Knoppix usb.agent[2256]: usb-storage: already loaded Mar 13 09:25:27 Knoppix scsi.agent[2299]: disk at /devices/pci0000:00/0000:00:10.3/usb4/4-4/4-4:1.0/host4/4:0:0:0 I only needed to modprobe ehci_hcd that wasn't autoloaded. Copied a big file to make sure USB 2.0 is working. Next, I tried Gentoo LiveCD 2004.3, customized with catalyst, my own kernel config as far as I remember. The kernel was 2.6.9 and my usb stick worked perfectly: Mar 13 09:30:34 [kernel] Linux version 2.6.9-gentoo-r6-livecd (root@ahoj) (gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)) #1 SMP Thu Nov 25 20:08:22 UTC 2004 Mar 13 09:30:39 [kernel] parport: PnPBIOS parport detected. Mar 13 09:30:39 [kernel] Device not ready. Make sure there is a disc in the drive. - Last output repeated twice - Mar 13 09:30:39 [kernel] Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0 Mar 13 09:30:39 [kernel] via-rhine.c:v1.10-LK1.2.0-2.6 June-10-2004 Written by Donald Becker Mar 13 09:30:39 [kernel] eth0: VIA Rhine II at 0xd0006c00, 00:c0:9f:2e:ed:9e, IRQ 4. Mar 13 09:32:01 [kernel] usb 1-4: new high speed USB device using address 4 Mar 13 09:32:01 [kernel] scsi1 : SCSI emulation for USB Mass Storage devices Mar 13 09:32:01 [kernel] Vendor: Generic Model: STORAGE DEVICE Rev: 1.25 Mar 13 09:32:01 [kernel] SCSI device sdb: 256000 512-byte hdwr sectors (131 MB) Mar 13 09:32:01 [kernel] Attached scsi removable disk sdb at scsi1, channel 0, id 0, lun 0 Mar 13 09:32:01 [kernel] Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 0 Mar 13 09:32:01 [kernel] USB Mass Storage device found at 4 Mar 13 09:34:29 [kernel] usb 1-4: USB disconnect, address 4 Ehci_hcd was loaded by autodetection and copying a big file confirmed USB 2.0 was ok. That is the same kernel version I have in my Gentoo (HD) and I need two minutes to mount the stick! I attach kernel log to prove. That inspired me to try some distribution that would have 2.6.10 or 2.6.11 kernel. I downloaded Gentoo install cd 2005.0-rc5 with 2.6.10 kernel and tried it. The usb stick worked perfectly! So it is not a hardware problem. It looks as if it was configuration problem but I don't remember changing it since 2.6.7. I 'm going to compare the config of Gentoo 2005.0-rc5 if there is /proc/config.gz. Let me summarize the usb-stick handling: The kernels I configured in my hd Gentoo: * <=2.6.7 perfect * 2.6.9 does mount but after 2 minutes and many errors in kernel's log * 2.6.10 (gentoo-dev-sources) and 2.6.11.2 (vanilla) does not mount at all and produce many error messages The kernels in livecd distributions: * 2.6.7 in KNOPPIX, perfect * 2.6.9 and 2.6.10 in Gentoo LiveCD, perfect If you have any idea, please let me know.
Created attachment 53317 [details] usb stick handling by kernel 2.6.9-r13 I configured BTW, attachment 53061 [details] is from vanilla 2.6.11.2
Created attachment 53318 [details] current kernel config
I wasn't wrong configuring kernel, it was udev that changed in the meantime. I run genkernel to create a kernel that would be as similar to the one on Gentoo LiveCD as possible. The generated kernel gave me exactly the same error messages I got with kernels configured on my own so I realized the problem is somewhere outside. I though about udev and hotplug as the only candidates and that reminded me about some udev rule I wrote in the past, or in fact copied from Gentoo wiki and modified for my usb stick. The rule is as following: BUS="usb", KERNEL="sd*", SYSFS{product}="JUMPDRIVE2", NAME="%k", SYMLINK="wtyczka%n" That's it. Once I commented it out, all problems with mounting are gone! Of course I use /dev/sdb1 now rather than /dev/wtyczka1 but that's not a big deal. The rule at least was good in the past, I had no problem using the stick until I forgot about the rule and changed kernel or updated udev, can't remember now. Should I change the bug status to invalid or someone else makes this decision?
That makes no sense - I'm doubtful whether that is actually your problem. What happens if you put that rule back in place but try and mount /dev/sdb1 ? Do the major/minor numbers of that node match the numbers for your custom node which you are trying to mount?
Actually, maybe it does, since your log doesn't end in an error (each operation fails a few times then succeeds). Your rule is probably not producing the desired effects, it lacks specifity. Read this: http://www.reactivated.net/writing_udev_rules.html#example-camera Looking at the major/minor numbers will confirm what is happening too.
My custom nodes are simple symlinks, have no major/minor numbers: /dev/wtyczka -> /dev/sdb /dev/wtyczka1 -> /dev/sdb1 When I uncommented the rule, plugged the stick in, executed 'mount /dev/sdb1' and waited about 2 minutes got the same error message as previously: mount: /dev/sdb1: can't read superblock The rule comes from the webpage you mentioned. Go one page down to "Additional notes on writing rules for USB storage" and you will see my rule with just different names.
Ah yes, I'm good at forgetting things which I've written myself :) Greg, any ideas on this? Could the sysfs querying (SYSFS{product}) actually be causing the USB device to be queried too early on and break future data transfers?
Can you reproduce in udev 056 on Linux 2.6.11? Might also be worth trying 2.6.12-rc4
Oh yes, I can reproduce... udev 056, gentoo-sources-2.6.11-r9, my attempts to mount give the usual: mount /dev/sdb1: can't read superblock I attach a current kernel log produced with 2.6.11-r9. Unfortunately I cannot try 2.6.12, tommorow morning I'm leaving for vacation, I'll try the newer kernel in about two weeks.
Created attachment 59316 [details] related part of the kernel log (gentoo-sources-2.6.11-r9)
Hi Kay :) This is the bug I mentioned. Any thoughts?
2 things: 1) Daniel was right; the /dev/uba stuff was because of the low-bandwitdh USB storage driver, which I have since disabled (hint: don't use it yet). 2) The rule in question could be too specific (as opposed to lacking specificity). I would suggest using the other rule form, which doesn't create the whole disk node, i.e.: BUS="scsi", SYSFS{vendor}="DV 3100 ", KERNEL="sd*[0-9]", SYMLINK="cooldv/dv%n" Note the lack of a Name parameter, the KERNEL option, and the BUS it looks up on. I've found that "scsi" is more reliable than "usb" for matching udev rules on flash drives, cameras, etc. Also, the NAME parameter sometimes seems to confuse udev (if you look at the default rules, you'll see many of them use fewer parameters to match on). Finally, the whole disk node should only be created if you need it. This only really applies when 1) you need to fdisk the node, or 2) you have a flash disk that only mounts as the whole disk, i.e., /dev/sda (rare, but it happens). A flash drive, USB stick, CF card reader, or camera that uses straight usbstorage, should normally mount as /dev/sda1 (type vfat). You may also format as you would any drive, but then you takes your chances on what can mount it... If you play with different forms of your custom rule, you may see the problem go away. Hope this helps.
Yesterday, before reading a comment #20 of Steve Arnold, I tried vanilla sources 2.6.12-rc5 to see how it handles the problematic udev rule. The kernel ignored this rule at all. It behaved strange because sometimes it created /dev/sdb1 in few seconds after plugging a stick in and sometimes it needed a few _minutes_ to do the same. Anyway, the symlink defined in the udev rule was never created. Today I read the comment of Steve Arnold and tried to use the new udev rule. I had to modify it slightly because udevinfo output did not offer any product- or vendor-specific information: BUS="scsi" ID="4:0:0:0" DRIVER="sd" SYSFS{detach_state}="0" SYSFS{device_blocked}="0" SYSFS{max_sectors}="240" SYSFS{model}="STORAGE DEVICE " SYSFS{queue_depth}="1" SYSFS{queue_type}="none" SYSFS{rev}="1.25" SYSFS{scsi_level}="3" SYSFS{state}="running" SYSFS{timeout}="30" SYSFS{type}="0" SYSFS{vendor}="Generic " so the rule I tried was the following: BUS="scsi", SYSFS{model}="STORAGE*", KERNEL="sd*[0-9]", SYMLINK="cooldv/dv%n" It does work and works well (gentoo-sources 2.6.11-r9). The rule seems to be general enough to handle all usb sticks and it doesn't conflict with my digital camera! I've already rewritten camera's rule to use BUS="scsi" and tried both the camera and the stick simultaneously - no problem. I also tried the above new rule with vanilla sources 2.6.12-rc5. It works also well and when I displayed udevinfo I understood why the previous rule was ignored by 2.6.12 - there was only a section of BUS="scsi", no more BUS="usb" for the usb stick I plugged in! So, it seems, the rule of Steve Arnold will be a necessity starting with 2.6.12... Fortunately, it works very well.
Ok, closing.
The cooldv/ symlink is just the name of my cheesy little camera; you can name it anything you want. Glad it works better for you.
