Boot Mount Error on two processor system

[mit-physicist]

My first post. I think this is the right place for it. I know there are previous posts about Boot Mount Errors, and I've read a number of them, but this seems different.

I have a working minimal FreeBSD 8.0 on a USB hard drive (not a stick) that I have been successfully using with a number of i-386 single core computers for several months.

I received a new, dual core system and tried to boot it from the same USB disk, but got a Boot Mount Error. This was after three messages saying that the system was waiting for the umass device on which the system resides. I have tried increasing kern.cam.boot_delay, but that doesn't help.

The odd thing is that I can enter ufs:/dev/da0s1a at the Boot Mount Error prompt and the system boots perfectly and works beautifully thereafter.

I have the contents of a dmesg -a in a file that I attempted to attached here, but with

boot_verbose="YES"

it's 37 kB long. Maybe I should split it into two files? Maybe this problem is well known and can be answered without seeing the dmesg output? I'm more than willing to do whatever is required to get this fixed.

I also built a nanobsd on a CF card from the system once I got it booted. Booting the nanobsd has the same problem, though it's connected to an adapter that makes it look like a regular disk. It attaches as ad4 and ad4s1a is where everything is. Again, I have been using these nanobsd servers on multiple single core systems for over a year without any kind of issue.

Anyone have a clue as to how I can resolve this problem? Thank you, in advance, for your time and consideration.

 

[wblock@]

There have been a lot of USB system changes since 8.0. Try at least 8.2-RELEASE, preferably 8-STABLE as of the last few days.

Isolate the problem by labeling the filesystems and trying the disk attached to a SATA or IDE port.

 

[mit-physicist]

Still no joy

Well, I installed the Developer distribution of 8.2; unfortunately, the problem persists. I also labeled the disks per the documentation; the problem persists. Do you think this might have to do with the number of USB hubs on the system?

I also tried setting

kern.cam.scsi_delay="10000"

. That didn't appear to change anything, and on one of the two systems it prevented me from even manually telling the system where the boot slice is.

Do you think it worthwhile to upload the result of a

dmesg -a

so what is happening is visible here?

 

[mit-physicist]

Perhaps this will help to determine what is happening

Attached are three files, the sequential thirds of a

dmesg -a

with

boot_verbose="YES"

. I know, it's long, but I want to be complete. Also, without the verbose, it doesn't show that shortly (two or three seconds) after the Boot Mount Error it finally finds da0. The line right after that, which reads

ufs:/dev/da0s1a

is me, typing it in. Of course, now that it has (re)found da0, it boots just fine from there. But what do I do to make it wait long enough to find it before it times out? Setting

kern.cam.scsi_delay

in /boot/loader.conf, even to 20000, doesn't do it... unless I've put it in the wrong place or something.

 

[wblock@]

Well, I installed the Developer distribution of 8.2; unfortunately, the problem persists.

That's just more source, but it's still the same relatively old version. Thinking more about this, the problem could be with a different USB chipset on the new system. The
freebsd-usb mailing list would be the place to post about that.

Some people have success with troublesome USB drives by using a powered hub.

I also labeled the disks per the documentation; the problem persists. Do you think this might have to do with the number of USB hubs on the system?

Not impossible, but not high on the list.

I also tried setting

kern.cam.scsi_delay="10000"

. That didn't appear to change anything, and on one of the two systems it prevented me from even manually telling the system where the boot slice is.

Do you think it worthwhile to upload the result of a

dmesg -a

so what is happening is visible here?

Yes. pastebin.com is easier for everybody than attachments.

The output of
% usbconfig
and
% usbconfig -d 3.2 dump_device_desc
(where 3.2 is the USB device number) are also relevant.