Izumi Tsutsui wrote:
> scotte@warped.com wrote:
> 
>> uhub1: device problem, disabling port 2
>>
>> on boot. "Sometimes" it actually works, and I see sd0 show up, but 
>> usually not.  There's no rhyme or reason that I can tell.
> 
> Is your host adapter is VIA UHCI?
> if so, maybe similar problem with kern/11018.
> (i.e. some other ports have had the same problem,
>  but I guess gcc4 triggers it on i386 and amd64.)

Yes, this is:

cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) 64 Processor 3400+, 2202.95 MHz
cpu0: features: e7dbfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
cpu0: features: e7dbfbff<PGE,MCA,CMOV,PAT,PSE36,MPC,NOX,MMXX,MMX>
cpu0: features: e7dbfbff<FXSR,SSE,SSE2,LONG,3DNOW2,3DNOW>
cpu0: I-cache 64 KB 64B/line 2-way, D-cache 64 KB 64B/line 2-way
cpu0: L2 cache 1 MB 64B/line 16-way
cpu0: ITLB 32 4 KB entries fully associative, 8 4 MB entries fully 
associative
cpu0: DTLB 32 4 KB entries fully associative, 8 4 MB entries fully 
associative
[snip]
uhci1 at pci0 dev 16 function 1: vendor 0x1106 product 0x3038 (rev. 0x81)
uhci1: interrupting at ioapic0 pin 21 (irq 5)
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: vendor 0x1106 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered

The behavior seems very similar to what is described by your final post 
on that PR.  I don't think it's a gcc4 problem (although I am using 
gcc4) since I believe I saw the issue before amd64 switched over, 
although I could be mistaken.

I'm honestly clueless as to how to debug this further, and have just 
been living with it, since I can usually re-plug the devices to make 
them show up. :-)

	ScottE