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
Version-Release number of selected component (if applicable):
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
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
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
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]
Created attachment 54629 [details]
This line shows that you were almost there:
SysRq : HELP : loglevel0-8 reBoot tErm kIll saK showMem Off showPc unRaw Sync
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]
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-)