USB Ports vanished from Slackware 12.1
 

Hello, folks!

I'm using slackware 12.1 for some time now and this morning (kind of the first day of my winter break) I decided to fix an old USB pen drive to save some docs... (bad idea #1).

I had some trouble deleting some files. Slack kept telling me that the files weren't there, so (probably not the smartest decision ever) I decided to "format" the tiny thing. (bad idea #2).

cfdisk wouldn't do it and I ended up on fdisk. (bad idea #3).

I thought I was formatting 4 partitions in the same pen drive which now I think might have been my four usb ports.
After that, no USB Ports are working at my computer at all.
I even boot slackware 13.1 from a dvd and still couldn't get any USB working.


rc.hotplug is nowhere to be found.

at the end of dmesg, I get:

usb 1-7: new high speed USB device using ehci_hcd and address 2
usb 1-7: device descriptor read/64, error -32
usb 1-7: device descriptor read/64, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 3
usb 1-7: device descriptor read/64, error -32
usb 1-7: device descriptor read/64, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 4
usb 1-7: device not accepting address 4, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 5
usb 1-7: device not accepting address 5, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 6
usb 1-7: device descriptor read/64, error -32
usb 1-7: device descriptor read/64, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 7
usb 1-7: device descriptor read/64, error -32
usb 1-7: device descriptor read/64, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 8
usb 1-7: device not accepting address 8, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 9
usb 1-7: device not accepting address 9, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 10
usb 1-7: device descriptor read/64, error -32
usb 1-7: device descriptor read/64, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 11
usb 1-7: device descriptor read/64, error -32
usb 1-7: device descriptor read/64, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 12
usb 1-7: device not accepting address 12, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 13
usb 1-7: device not accepting address 13, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 14
usb 1-7: device descriptor read/64, error -32
usb 1-7: device descriptor read/64, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 15
usb 1-7: device descriptor read/64, error -32
usb 1-7: device descriptor read/64, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 16
usb 1-7: device not accepting address 16, error -32
usb 1-7: new high speed USB device using ehci_hcd and address 17
usb 1-7: device not accepting address 17, error -32
usb 1-3: new high speed USB device using ehci_hcd and address 18
usb 1-3: device descriptor read/64, error -32
usb 1-3: device descriptor read/64, error -32
usb 1-3: new high speed USB device using ehci_hcd and address 19
usb 1-3: device descriptor read/64, error -32
usb 1-3: device descriptor read/64, error -32
usb 1-3: new high speed USB device using ehci_hcd and address 20
usb 1-3: device not accepting address 20, error -32
usb 1-3: new high speed USB device using ehci_hcd and address 21
usb 1-3: device not accepting address 21, error -32

I didn't mess with this kernel and everything was just great 4 hours ago...

Any ideas, thoughts, advices or solutions?
Thanks, everyone!

Did you Google the problem... ?
 

Here is a similar post with a solution... hope it helps !

http://www.linuxquestions.org/questi...r-work-231930/

Thanks, hughetorrance, for replying.

I did google it and nothing I found helped.
The post you provided didn't help either...

I'll keep searching.
If you have any other idea or thread you think might help, please post it.

This is what I get from mount:

/dev/hdc2 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/hdb2 on /home type ext3 (rw)
/dev/sdb1 on /mnt/ikaros type ext3 (rw,noexec,nosuid,nodev)
tmpfs on /dev/shm type tmpfs (rw)

BIOS
 

Have you checked your BIOS settings with regard to USB... ?

My skills are limited so hopefully someone will be along to help.

Perhaps there is a script to be re-run in pkgtool

Also from the live DVD you can swop files and folders relevant to your problem... naturally backing up before you start if you need to... LOL I dont.

Lasly, what about an upgrade to a newer version !

I have had to do this on some problems.

Sounds like the hardware got burned, but other times I have managed to fix a hardware port problem by mysterious means, not at all understood (except that one time).

Options:

1. Repeat the formatting operations (*CRINGE*) and note the exact error messages.
Try this with the pen in and without the pen, and any other combination you can think. I am serious, the best insights come from the oddest experiment. Try putting the pen in one USB port and mounting a different port. Try a known good USB device.

2. Note if the USB leds are behaving normally. I had one case where
the USB device would not light up. I tried a different kernel and
they were back working again. Switched back to the first case and that was working again to. Didn't learn a thing about why.

3. Search for the error messages in the source code and find out what it was trying to do.
Once you know what got formatted, you can tackle undoing the damage.

4. Take the pen to another computer and see if it will mount. Try a library computer if nothing else is available.

5. Build a custom kernel with the debugging messages turned on.
Use menuconfig to visit all the relevant drivers and turn on any debugging options you can find. This results in a larger kernel that babbles alot.
Enable the error messages in the lilo append line per the instructions
(which you should have wrote down).
Run lilo, reboot, and experiment with mounting the pen, other USB devices (must assume the pen is maybe totally corrupted), and the USB-pen in question.
Find the error messages in the source code and figure out:
- which driver
- what the driver was trying to do
- what the driver actually did
- what the driver did for a format command

What is the output of `lsmod`?

Another distro ...
 

Have you tried to see if things work from a live distro... like almost any other live distro will do to check its not the hardware.

If I was doing that I would try a few just to be sure.

lsmod
 

Module Size Used by
snd_seq_dummy 6660 0
snd_seq_oss 32896 0
snd_seq_midi_event 10112 1 snd_seq_oss
snd_seq 50256 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device 10380 3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss 40352 0
snd_mixer_oss 17920 1 snd_pcm_oss
ipv6 234724 18
lp 13348 0
fuse 45588 1
parport_pc 27556 1
parport 34632 2 lp,parport_pc
snd_intel8x0 31900 3
snd_ac97_codec 98724 1 snd_intel8x0
ac97_bus 5760 1 snd_ac97_codec
snd_pcm 72068 4 snd_pcm_oss,snd_intel8x0,snd_ac97_codec
rtc_cmos 11040 0
rtc_core 18696 1 rtc_cmos
thermal 16540 0
snd_timer 22532 3 snd_seq,snd_pcm
button 10000 0
snd 47716 13 snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_intel8x0, snd_ac97_codec,snd_pcm,snd_timer
processor 32680 1 thermal
rtc_lib 6528 1 rtc_core
psmouse 40336 0
soundcore 9824 1 snd
sis_agp 10500 1
evdev 12672 3
snd_page_alloc 11528 2 snd_intel8x0,snd_pcm
serio_raw 9092 0
shpchp 32788 0
agpgart 30664 1 sis_agp
via_rhine 24968 0
8139too 25600 0
mii 8448 2 via_rhine,8139too
sg 30224 0

Keep your mind open to what you did right before you formatted the pen.
Check the /var/log/messages if you do not remember it all.
In my disasters, it usually turns out to be something I did to get access, or the thing I did 3 steps before where I noticed all the errors that actually messed things up.

Unfortunately, there are a few things that are as non-volatile as bad hardware, and they will persist even when trying other kernels, and a kernel on a live CD (yes I found this out the hard way).

Any change in any /etc file.
Tools that save current settings.
CMOS changes, and BIOS setting changes, and I think there are a few tools (like the DATE and CLOCK) that can get to them without actually
bringing up the BIOS.
Drop down into the BIOS and give it a check over, two or three times.

I was in the kernel last night and looked at the USB driver code.
It recognizes the SCSI format command "SC_FORMAT_UNIT", but does not implement it, and will give a message "command unknown".
This is done in several places in the USB driver.

Might want to look at what indirection you have handling the USB system,
and whether something else got that FORMAT.
It could be that your indirection got clobbered.
On my system, I have to identify the usb ports as /dev/sdd1 and /dev/sde1.

One time I had to install a entirely new installation on another partition and compare setup files one by one until I found the one significant difference. I would think that booting from an installation CD would be similar.
This assumes that an entirely new (with all default settings and rc.d files, and a default kernel) has working USB ports.

USB can be difficult, requires some setup, and an installation CD is not a good test of working hardware. I got USB working with my old setup files from Slackware 10.2, but without udev working right.
If I boot the Slackware 13.1 HUGE kernel, I got udev working, but the
USB are missing and I have not been able to fix them using HUGE.

Booting a CD kernel from a different installation will not work either because they keep changing the udev and USB setup files.

Have a missing rc.hotplug file. Replace that from the installation CD for the kernel (no substitutes) and then go through it and try to remember what you might have changed.
Do not re-install the a-pkg as that will clobber every setting you have in /etc. You can untar packages into a separate directory and copy what you need by hand.
I keep a backup rc.d directory, in a directory rc.d-2.6-orig and my-rc.d-06-2010, as a tar file with my backups. This is small enough to put on a floppy. Make a separate backups just for system settings, it comes in handy.

My Slackware 13.1, does not have /sbin/hotplug because udev has replaced it entirely, but some of the old hooks are still there.
I doubt that many readers here can remember exactly what Slackware 12.1 had for USB setup so you may want to tell them explicitly
(/sbin/hotplug, udev involved).

Remember, it is possible to clobber the CMOS. Some of the BIOS are buggy and giving them an unexpected command could do anything.
For example all the bios and hardware fixups and work-arounds that are in the kernel.

The cure for a clobbered CMOS.
1. Write down all your BIOS settings and verify that they are what you wanted.
2. Turn off power, find your motherboard manual, open the case, pull the CMOS battery keep-alive power jumper, wait for CMOS to die (10 to 15 min or when patience runs out), put the jumper back exactly where you found it. I usually store the jumper on the same pin but turned 90, or 180, so it does not connect. I also use a surgical forceps to pull those things, fingers are useless.
3. Power-up the machine. The BIOS will recognize that it has invalid CMOS and will re-init it.
4. Go into your BIOS and put back all the settings you wrote down.
5. Reboot system and check the USB.

Thanks all who replied so promptly too such mysterious problem.
I (or the USB Faerie) fixed it and apparently the issue was that somehow I send some signal to the hardware telling the USB Ports to shutdown. From what I could figure, I guess that, besides not being a real expert to use the expert options in fdisk, I cleared /dev/sdd and not /dev/sdd1 or any other number and unmounted it before creating a new fs, causing some trouble somewhere. I'm not sure what solved it, but there are two main possibilities: plugging in a functional pen drive or a complete power down similar to what selfprogrammed suggested.

I'm really thankful, folks!