Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 112944 - USB hard drive does not work on amd64
Summary: USB hard drive does not work on amd64
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
URL:
Whiteboard:
Keywords:
: 114114 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-11-18 11:45 UTC by Jon Mason
Modified: 2005-12-04 19:30 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jon Mason 2005-11-18 11:45:08 UTC
When attaching a USB hdisk to 2 different AMD64 systems, the disk shows up in
dmesg but is not accessable.

From dmesg on amd64:
...
usb 1-4: new high speed USB device using ehci_hcd and address 3
scsi3 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
  Vendor: Maxtor 2  Model: B020H1            Rev:  0 0
  Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sdb: 39874367 512-byte hdwr sectors (20416 MB)
sdb: assuming drive cache: write through
SCSI device sdb: 39874367 512-byte hdwr sectors (20416 MB)
sdb: assuming drive cache: write through
 sdb: sdb1
Attached scsi disk sdb at scsi3, channel 0, id 0, lun 0
usb-storage: device scan complete
usb 1-4: USB disconnect, address 3
...

Reproducible: Always
Steps to Reproduce:
1. Connect and power-on USB hdisk
2. load usb-storage kernel module (if not compiled in kernel)
3. verify kernel has detected it via dmesg
4. attempt to use it
Actual Results:  
The disk shows up in dmesg but is not accessable.  "fdisk -l" does not show the
disk as being connected, and mount does not detect a device and fails when
trying to mount.


This is only a problem if the device is hotplugged.  If the device is present
prior to boot, then it will detect and mount it a desired.  

Also, it curently works on x86.  dmesg from working system:
...
usb 1-4: new high speed USB device using ehci_hcd and address 3
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
  Vendor: Maxtor 2  Model: B020H1            Rev:  0 0
  Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sda: 39874367 512-byte hdwr sectors (20416 MB)
sda: assuming drive cache: write through
SCSI device sda: 39874367 512-byte hdwr sectors (20416 MB)
sda: assuming drive cache: write through
 sda: sda1
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
usb-storage: device scan complete
ReiserFS: sda1: found reiserfs format "3.6" with standard journal
ReiserFS: sda1: using ordered data mode
ReiserFS: sda1: journal params: device sda1, size 8192, journal first block 18,
max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda1: checking transaction log (sda1)
ReiserFS: sda1: Using r5 hash to sort names
usb 1-4: USB disconnect, address 3
...
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2005-11-18 11:48:15 UTC
emerge --info missing, we cannot really guess which kernel version are you using. 
Comment 2 Jon Mason 2005-11-18 12:18:10 UTC
For one of the broken systems:

Portage 2.0.51.22-r3 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r2,
2.6.14.2 x86_64)
=================================================================
System uname: 2.6.14.2 x86_64 AMD Opteron(tm) Processor 248
Gentoo Base System version 1.6.13
dev-lang/python:     2.3.5, 2.4.2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   1.5.20
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=k8 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 avi berkdb bitmap-fonts bzip2 crypt eds emboss encode expat
foomaticdb fortran gif gpm gstreamer gtk2 imlib ipv6 jpeg lzw lzw-tiff mp3 mpeg
ncurses opengl pam pcre pdflib perl png python qt quicktime readline sdl spell
ssl tcpd tiff truetype-fonts type1-fonts udev usb userlocales xml2 xpm xv zlib
userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY
Comment 3 Daniel Drake (RETIRED) gentoo-dev 2005-11-24 17:07:54 UTC
The dmesg result from amd64 suggests that the kernel detected the device and
then decided it had disconnected. But you might have plugged in the device,
disconnected it, and then produced the logs. Please clarify this.
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2005-12-01 01:36:18 UTC
*** Bug 114114 has been marked as a duplicate of this bug. ***
Comment 5 Jon Mason 2005-12-01 05:59:53 UTC
Yes, in both cases the USB hdisk was disconnected prior to me capturing the
dmesg.  I am happy to recapture dmesg or provide any other information you think
would be beneficial.
Comment 6 Daniel Drake (RETIRED) gentoo-dev 2005-12-04 07:16:27 UTC
Ok, please show us more of the process. For example, you might plug it in and
see the following appear in dmesg:

SCSI device sdb: 39874367 512-byte hdwr sectors (20416 MB)
sdb: assuming drive cache: write through
 sdb: sdb1
Attached scsi disk sdb at scsi3, channel 0, id 0, lun 0

You might then do:

# ls -l /dev/sdb*
# mount -t auto /dev/sdb1 /mnt/temp

and show us the output, and the end of dmesg after the mount has failed too. It
would also be a good idea to attach your kernel .config
Comment 7 Jon Mason 2005-12-04 19:30:29 UTC
I re-emerged my system (emerge -eD world), and it seems to be working now. 
thanks for your help.