Bug 63368

Summary: memory stick inaccessible on Sony Vaio SRX77.
Product: [Retired] Red Hat Linux Reporter: Need Real Name <admi>
Component: kernelAssignee: Pete Zaitcev <zaitcev>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
URL: http://www.uno.ac/misc/vaio.html.ja.euc
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-12-17 03:18:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
This message was captured after exec. of "mount -t vfat /dev/sda1 /mnt/stick"
none
dmesg.txt
none
ksymoops.txt
none
Output from "cat /proc/modules"
none
This message was prior to "<Alt> <SysRq> T"
none
This message was captured after "<Alt> <SysRq> T"
none
ksymoops.txt none

Description Need Real Name 2002-04-13 00:03:57 UTC 
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.
Comment 1 Pete Zaitcev 2002-04-17 17:56:33 UTC 
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.
Comment 2 Need Real Name 2002-04-18 17:24:34 UTC 
Created attachment 54384 [details]
This message was captured after exec. of "mount -t vfat /dev/sda1 /mnt/stick"
Comment 3 Need Real Name 2002-04-18 17:31:04 UTC 
The above attachment is generated after we see the message
   mount: /dev/sda1 is not a valid block device
Comment 4 Pete Zaitcev 2002-04-18 17:52:38 UTC 
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.
Comment 5 Need Real Name 2002-04-19 17:28:10 UTC 
Created attachment 54628 [details]
dmesg.txt
Comment 6 Need Real Name 2002-04-19 17:32:28 UTC 
Created attachment 54629 [details]
ksymoops.txt
Comment 7 Pete Zaitcev 2002-04-19 17:35:06 UTC 
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).
Comment 8 Need Real Name 2002-04-19 19:45:21 UTC 
Created attachment 54664 [details]
Output from "cat /proc/modules"
Comment 9 Need Real Name 2002-04-19 19:47:51 UTC 
Created attachment 54665 [details]
This message was prior to "<Alt> <SysRq> T"
Comment 10 Need Real Name 2002-04-19 19:50:29 UTC 
Created attachment 54666 [details]
This message was captured after  "<Alt> <SysRq> T"
Comment 11 Need Real Name 2002-04-19 19:52:32 UTC 
Created attachment 54667 [details]
ksymoops.txt
Comment 12 Need Real Name 2002-04-19 19:57:16 UTC 
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.
Comment 13 Pete Zaitcev 2002-04-19 23:14:35 UTC 
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.
Comment 14 Pete Zaitcev 2002-05-28 22:49:07 UTC 
Please don't give up so easily, I am still looking forward
to those stack traces.
Comment 15 Dave Jones 2003-12-17 03:18:53 UTC 
20 months later.. I think you might have to give up on this one Pete 8-)