Red Hat Bugzilla – Bug 63368
memory stick inaccessible on Sony Vaio SRX77.
Last modified: 2007-04-18 12:41:57 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98) Description of problem: When mounting a memory stick on a Sony Vaio SRX77, mount -t vfat /dev/sda1 /mnt/stick does not find a valid block device. This worked correctly on the Sony Vaio SR33. When modprobing the usb-storage and typing lsmod periodically I noticed that the status of the usb-storage module never changes from the initializing state. If you look on www.linux-laptop.net under Vaio SRX77, you will see that all have this problem. This problem is also reported on other recent Sony Vaio's (see http://www.emperorlinux.com/hardware.html#memstick) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Insert memory stick 2. modprobe vfat 3. modprobe usb-storage 4. modprobe usb-uhci 5. modprobe usbcore 6. modprobe sd_mod 7. modprobe scsi_mod 8. mount -t vfat /dev/sda1 /mnt/stick Actual Results: mount: /dev/sda1 is not a valid block device Expected Results: successfull mount, followed by seeing the file system on the memory stick. Additional info: After trying this using the original RH7.2, we tried 7.2.93 (Skipjack 2) to see if the issues were resolved in your new release. They were not. Given that Sony seems to be swithcing the memory stick support from the PCI bus to the USB bus for its new platforms, unless this issue is addressed, RedHat 7.3 will not work with an increasing number of Vaio laptops, and possibly other computers. Getting this resolved before the final 7.3 would be useful for a *lot* of Sony laptops. If there is a "correct" sequence that works, we would like to know, but it is not obvious. More information is available on www.linux-laptop.net for SRX77, as well as the emperorlinux site mentioned above.
I would like to see the dmesg. If a module gets stuck in initializing state, it usually indicates an oops. Please collect the output of dmesg command and attach it to the bug. Do no compress/tar/zip. Do not drop into the comments box.
Created attachment 54384 [details] This message was captured after exec. of "mount -t vfat /dev/sda1 /mnt/stick"
The above attachment is generated after we see the message mount: /dev/sda1 is not a valid block device
Great, thanks! No oops in dmesg though, so my first hypothesis was wrong. Please attach the output of "cat /proc/modules" - I would like to see that "Initializing" module documented in the bug. Also... Let us think two steps ahead. Suppose it's stuck in "initializing". But dmesg that you attached has no oops. Thus: some process must be stuck in D state. It's easy to check with "ps auxw". But if so, then it would be very useful to get stack trace. To get the trace, you will need to do this: 0. Exit X11 (to reduce a chance of dmesg buffer overflow) 1. Do "echo 1 > /proc/sys/kernel/sysrq", we ship with SysRq disabled by default. You have to be root to do it. 2. If you use a graphics login, switch to text mode console with <Alt><Shift><F1>. 3. Hold <Alt>, hold <SysRq>, and tap "T". The screen will be full of stacks. 4. Do "dmesg > /tmp/dmesg.txt", just like you did before 5. Run "ksymoops < /tmp/dmesg.txt > /tmp/ksymoops.txt". This is needed because I do not have access to your /lib/modules, so I cannot get the right ksymoops output from your dmesg. Then, attach dmesg.txt and ksymoops.txt to the bug as you did with msgLog13.doc. I hope that will show where a process gets stuck.
Created attachment 54628 [details] dmesg.txt
Created attachment 54629 [details] ksymoops.txt
This line shows that you were almost there: SysRq : HELP : loglevel0-8 reBoot tErm kIll saK showMem Off showPc unRaw Sync showTasks Unmount It comes out if you hold <alt><SysRq> and then hit something that kernel cannot recognise, for instance, the space bar. We need "T" to diagnose the problem (without quotes, just the T key).
Created attachment 54664 [details] Output from "cat /proc/modules"
Created attachment 54665 [details] This message was prior to "<Alt> <SysRq> T"
Created attachment 54666 [details] This message was captured after "<Alt> <SysRq> T"
Created attachment 54667 [details] ksymoops.txt
The key combination <Alt> <SysRq> "T" gave a splash of colored lines on screen, and there was not any stack trace on the screen. And, right after that the computer was automatically reboot.
I just got a word that <alt><sysrq>T is defective in 2.4.18. Is there a chance to try it with 2.4.9-31? You can install it side by side with a current kernel and without reinstalling the whole system.
Please don't give up so easily, I am still looking forward to those stack traces.
20 months later.. I think you might have to give up on this one Pete 8-)