Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#2424 closed bug (fixed)

usb disk not published if plugged during boot (vmware)

Reported by: emitrax Owned by: mmlr
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Platform: All


If I plug my usb disk during boot (vmware) the device doesn't get published, I have to unplug it and plug it again in order to be able to mount it. I don't really know if it's the device manager, or the the usb explore thread.

Attachments (1)

automounter.jpg (159.1 KB ) - added by emitrax 12 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 by mmlr, 12 years ago

I am unable to reproduce that on real hardware or on QEMU. Could you please provide a serial or syslog.

comment:2 by emitrax, 12 years ago

Log is over 3MB and I can't attach it here, is that ok if I send to your email address?

comment:3 by mmlr, 12 years ago

Status: newassigned

Yes please do so.

comment:4 by mmlr, 12 years ago

I've got the log and it looks perfectly fine to me. There is no actual problem. Not a single failed transfer or timeout. The device is detected and the partition is published. What I gather from the output is that the only partition on that disk is a FAT one? If so this boils down to that the FAT filesystem add-on is not loaded in the early boot process (as it doesn't have a boot module symlink). It is only loaded after the partition was published and scanned, but does not check the existing partitions for a FAT filesystem. I assume this would be an unimplemented feature in the disk device manager. If my suspicion is true, adding a symlink from "/boot/beos/system/add-ons/kernel/file_systems/fat" to "/boot/beos/system/add-ons/kernel/boot" should resolve this. Otherwise please correct me by providing info on the partitions/filesystems present on that device.

comment:5 by emitrax, 12 years ago

Spot on!

Making the link slow things a bit, but it mounts it automatically. So you think this is more a disk device manager issue?

comment:6 by mmlr, 12 years ago

Component: Drivers/USBSystem/Kernel

Nice. It is most probably an unimplemented feature that the disk device manager doesn't rescan yet unknown partitions when it loads a new filesystem add-on. In any case changing component to kernel as it's disk device manager issue. Will look into it, but maybe Ingo has an idea right away or can confirm this?

comment:7 by mmlr, 12 years ago

Resolution: fixed
Status: assignedclosed

Should be fixed in hrev26128. The intel partitioning system would be associated with the disk as it just indicated supporting it with a priority of 0.1 and the actual FAT filesystem module that would have supported it with a higher priority wasn't loaded that early. Now the intel partitioning system will just leave it unsupported when it finds itself in a unlikely useful situation, therefore giving the second scan round with the FAT module available a chance of correctly identifying the partition/filesystem.

comment:8 by axeld, 12 years ago

Can you please recheck with a hrev26178 or later? I've reverted hrev26128 since it shouldn't be necessary after hrev26177 anymore.

by emitrax, 12 years ago

Attachment: automounter.jpg added

comment:9 by emitrax, 12 years ago

Quick test on the fly. ;-)

Let me know if you need anything else.

comment:10 by axeld, 12 years ago

Well, that at least doesn't seem to have anything to do with this particular problem :-) It's probably another USB issue (I'm *so* glad that Michael tackled this!!! :-)).

comment:11 by mmlr, 12 years ago

In fact the timeout handling I introduced was broken at first. Could you please retry with a current revision and check if this still happens? Please open a new bug if it does.

comment:12 by emitrax, 12 years ago

It happens indeed with hrev26239 . Opening a new bug.

Note: See TracTickets for help on using tickets.