Re: ext2 or usb problem

2017-07-02 Thread Juan Francisco Cantero Hurtado 
On Sun, Jul 02, 2017 at 01:51:48PM -0400, Donald Allen wrote:
> On 1 July 2017 at 18:55, Juan Francisco Cantero Hurtado
>  wrote:
> > On Sat, Jul 01, 2017 at 03:43:48PM -0400, Donald Allen wrote:
> >> On 1 July 2017 at 12:06, Juan Francisco Cantero Hurtado
> >>  wrote:
> >>
> >> > The USB disks and ext2 are both quite slow on OpenBSD. Try with FFS but
> >> > you're not going to see better numbers.
> >> >
> >> > On Linux, the kernel uses UAS for your USB disks. We only supports
> >> > bulk-only.
> >>
> >> If you are implying that if I had only waited a week or a month for
> >> this to complete on OpenBSD yesterday, I think you are incorrect. This
> >> was hung, not slow.
> >
> > No, it's just slow. I've had the same problem for years. Our ext2
> > implementation is slow even on SATA.
> 
> This is not helpful. You insist that you know what is going on when I
> was in front of the computer and you were not. File copying to an ext2
> filesystem on a usb drive is 10x slower than to an ffs filesystem on
> an internal sata drive mounted async (ext2 is async; apples to
> apples). I know because I've measured it, including the time to sync.
> The file in question was 1.5 GB. That copy should have taken 150
> seconds or so at the rates I measured. The system sat there for two
> hours, as I said in my message. And when I came back, it was making no
> progress, as I also said in my message. I'm done discussing this. I've
> reported what I found and offered to help debug it. My workaround is
> simple: I will do these backup disk updates and anything else
> involving ext2/usb disks with Linux.

You're taking my comments too personally. I was talking only from my
experience.

You can't mount ext2 with "async" on OpenBSD. FFS only syncs the
metadata by default, that's why the "sync" option exists for FFS. And
you can't compare a SATA disks with an USB bulk-only. So, you're not
comparing apples to apples.

I've copied a file to an USB disk formatted as ext2 and the speed is
about 12MB/s. It's similar to your numbers with the 1.5GB file.

My point was that if you're writing a lot of metadata updates (something
usual with rsync), due to the limitations of our ext2 implementation and
the USB stack, the process sometimes will get stuck.

Cheers.


-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: ext2 or usb problem

2017-07-02 Thread Donald Allen 
On 2 July 2017 at 14:02, Theo de Raadt  wrote:
>> On 2 July 2017 at 13:54, Theo de Raadt  wrote:
>> >> This is not helpful. You insist that you know what is going on when I
>> >> was in front of the computer and you were not. File copying to an ext2
>> >> filesystem on a usb drive is 10x slower than to an ffs filesystem on
>> >> an internal sata drive mounted async (ext2 is async; apples to
>> >> apples). I know because I've measured it, including the time to sync.
>> >> The file in question was 1.5 GB. That copy should have taken 150
>> >> seconds or so at the rates I measured. The system sat there for two
>> >> hours, as I said in my message. And when I came back, it was making no
>> >> progress, as I also said in my message. I'm done discussing this. I've
>> >> reported what I found and offered to help debug it. My workaround is
>> >> simple: I will do these backup disk updates and anything else
>> >> involving ext2/usb disks with Linux.
>> >
>> > Then why all the angst?
>> >
>> > If you really wanted it fixed you have the src code.  Yelling at people
>> > isn't helpful either, is it?
>>
>> If you consider this 'yelling', then you really need to consult a
>> dictionary. And you are a fine one to be lecturing anyone about
>> yelling.
>
> Look, you don't get to lecture developers who are trying to help.
>
> Please leave here.

Done.

Re: ext2 or usb problem

2017-07-02 Thread Theo de Raadt 
> On 2 July 2017 at 13:54, Theo de Raadt  wrote:
> >> This is not helpful. You insist that you know what is going on when I
> >> was in front of the computer and you were not. File copying to an ext2
> >> filesystem on a usb drive is 10x slower than to an ffs filesystem on
> >> an internal sata drive mounted async (ext2 is async; apples to
> >> apples). I know because I've measured it, including the time to sync.
> >> The file in question was 1.5 GB. That copy should have taken 150
> >> seconds or so at the rates I measured. The system sat there for two
> >> hours, as I said in my message. And when I came back, it was making no
> >> progress, as I also said in my message. I'm done discussing this. I've
> >> reported what I found and offered to help debug it. My workaround is
> >> simple: I will do these backup disk updates and anything else
> >> involving ext2/usb disks with Linux.
> >
> > Then why all the angst?
> >
> > If you really wanted it fixed you have the src code.  Yelling at people
> > isn't helpful either, is it?
> 
> If you consider this 'yelling', then you really need to consult a
> dictionary. And you are a fine one to be lecturing anyone about
> yelling.

Look, you don't get to lecture developers who are trying to help.

Please leave here.

Re: ext2 or usb problem

2017-07-02 Thread Donald Allen 
On 2 July 2017 at 13:54, Theo de Raadt  wrote:
>> This is not helpful. You insist that you know what is going on when I
>> was in front of the computer and you were not. File copying to an ext2
>> filesystem on a usb drive is 10x slower than to an ffs filesystem on
>> an internal sata drive mounted async (ext2 is async; apples to
>> apples). I know because I've measured it, including the time to sync.
>> The file in question was 1.5 GB. That copy should have taken 150
>> seconds or so at the rates I measured. The system sat there for two
>> hours, as I said in my message. And when I came back, it was making no
>> progress, as I also said in my message. I'm done discussing this. I've
>> reported what I found and offered to help debug it. My workaround is
>> simple: I will do these backup disk updates and anything else
>> involving ext2/usb disks with Linux.
>
> Then why all the angst?
>
> If you really wanted it fixed you have the src code.  Yelling at people
> isn't helpful either, is it?

If you consider this 'yelling', then you really need to consult a
dictionary. And you are a fine one to be lecturing anyone about
yelling.

Re: ext2 or usb problem

2017-07-02 Thread Theo de Raadt 
> This is not helpful. You insist that you know what is going on when I
> was in front of the computer and you were not. File copying to an ext2
> filesystem on a usb drive is 10x slower than to an ffs filesystem on
> an internal sata drive mounted async (ext2 is async; apples to
> apples). I know because I've measured it, including the time to sync.
> The file in question was 1.5 GB. That copy should have taken 150
> seconds or so at the rates I measured. The system sat there for two
> hours, as I said in my message. And when I came back, it was making no
> progress, as I also said in my message. I'm done discussing this. I've
> reported what I found and offered to help debug it. My workaround is
> simple: I will do these backup disk updates and anything else
> involving ext2/usb disks with Linux.

Then why all the angst?

If you really wanted it fixed you have the src code.  Yelling at people
isn't helpful either, is it?

Re: ext2 or usb problem

2017-07-02 Thread Donald Allen 
On 1 July 2017 at 18:55, Juan Francisco Cantero Hurtado
 wrote:
> On Sat, Jul 01, 2017 at 03:43:48PM -0400, Donald Allen wrote:
>> On 1 July 2017 at 12:06, Juan Francisco Cantero Hurtado
>>  wrote:
>>
>> > The USB disks and ext2 are both quite slow on OpenBSD. Try with FFS but
>> > you're not going to see better numbers.
>> >
>> > On Linux, the kernel uses UAS for your USB disks. We only supports
>> > bulk-only.
>>
>> If you are implying that if I had only waited a week or a month for
>> this to complete on OpenBSD yesterday, I think you are incorrect. This
>> was hung, not slow.
>
> No, it's just slow. I've had the same problem for years. Our ext2
> implementation is slow even on SATA.

This is not helpful. You insist that you know what is going on when I
was in front of the computer and you were not. File copying to an ext2
filesystem on a usb drive is 10x slower than to an ffs filesystem on
an internal sata drive mounted async (ext2 is async; apples to
apples). I know because I've measured it, including the time to sync.
The file in question was 1.5 GB. That copy should have taken 150
seconds or so at the rates I measured. The system sat there for two
hours, as I said in my message. And when I came back, it was making no
progress, as I also said in my message. I'm done discussing this. I've
reported what I found and offered to help debug it. My workaround is
simple: I will do these backup disk updates and anything else
involving ext2/usb disks with Linux.

Re: ext2 or usb problem

2017-07-01 Thread Juan Francisco Cantero Hurtado 
On Sat, Jul 01, 2017 at 03:43:48PM -0400, Donald Allen wrote:
> On 1 July 2017 at 12:06, Juan Francisco Cantero Hurtado
>  wrote:
> 
> > The USB disks and ext2 are both quite slow on OpenBSD. Try with FFS but
> > you're not going to see better numbers.
> >
> > On Linux, the kernel uses UAS for your USB disks. We only supports
> > bulk-only.
> 
> If you are implying that if I had only waited a week or a month for
> this to complete on OpenBSD yesterday, I think you are incorrect. This
> was hung, not slow.

No, it's just slow. I've had the same problem for years. Our ext2
implementation is slow even on SATA.

Try this on your ext2 partition on the USB disks:

# mkdir test
# cd test
# i=0; while (( i < 20 )); do >$i; (( i += 1 )); done

It takes only a few seconds on my SATA disk. Your USB disk will take a
while to complete the command.

> 
> As for your suggestion to try FFS, that's a non-starter. I have Linux
> systems and will do the rsyncs from primary to secondary with them. I
> did this with OpenBSD yesterday because, in general, I much prefer the
> system to Linux. But I realize it's not perfect -- no system is -- and
> it appears that I found an imperfection. Using Linux for this is a
> reasonable workaround, though if anyone has an interest in trying to
> debug the OpenBSD problem, I will help.
> 

-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: ext2 or usb problem

2017-07-01 Thread Ted Unangst 
Donald Allen wrote:
> I am guessing, but do not know, that the trouble here is either in the
> ext2 support or perhaps in the usb driver. If ext2, I realize that it

It wouldn't surprise me that the USB stack can get wedged if it does lots of
IO. ext2fs probably has other bugs, but I wouldn't expect it to just hang.
It would more likely trash your files in a reasonable amount of time.

Bugs in USB do get fixed over time, although it's rarely obvious what the
problem is from any one report.

Re: ext2 or usb problem

2017-07-01 Thread Donald Allen 
On 1 July 2017 at 12:06, Juan Francisco Cantero Hurtado
 wrote:

> The USB disks and ext2 are both quite slow on OpenBSD. Try with FFS but
> you're not going to see better numbers.
>
> On Linux, the kernel uses UAS for your USB disks. We only supports
> bulk-only.

If you are implying that if I had only waited a week or a month for
this to complete on OpenBSD yesterday, I think you are incorrect. This
was hung, not slow.

As for your suggestion to try FFS, that's a non-starter. I have Linux
systems and will do the rsyncs from primary to secondary with them. I
did this with OpenBSD yesterday because, in general, I much prefer the
system to Linux. But I realize it's not perfect -- no system is -- and
it appears that I found an imperfection. Using Linux for this is a
reasonable workaround, though if anyone has an interest in trying to
debug the OpenBSD problem, I will help.

Re: ext2 or usb problem

2017-07-01 Thread Juan Francisco Cantero Hurtado 
On Sat, Jul 01, 2017 at 09:23:02AM -0400, Donald Allen wrote:
> I have three Toshiba 1TB USB drives that I use for backups and
> archives of my various systems. These disks pre-date my predominant
> use of OpenBSD, and have ext2 file-systems. One of the disks is the
> primary, to which new backups and archives are written. Another is the
> secondary. When the primary changes, I have a script that rsyncs the
> primary to the secondary. There's also a tertiary drive in my safe
> deposit box, so there's an off-site copy of all this stuff.
> Periodically, I rotate their roles, so the off-site drive doesn't get
> too stale.
> 
> I did some backups yesterday to the primary drive and, for the first
> time, ran the rsync script to copy primary to secondary on OpenBSD. I
> created directories /tmp/primary and /tmp/secondary on which to mount
> each of the file-systems. Then I mounted the primary drive with write
> access and archived some files. I then umounted it with the intention
> of re-mounting it read-only, except I got distracted at the wrong
> moment by a phone call and didn't do it. After the call, I mounted the
> secondary drive read-write and started the script to rsync the primary
> to the secondary. Because there was nothing mounted on /tmp/primary,
> rsync started deleting files wholesale. When I saw what was happening,
> I ctrl-c-ed out of the script, did a df and saw my error. Shouldn't be
> a big deal.
> 
> So I mounted the primary drive read-only and re-started the rsync
> script and the right thing happened -- files that had been deleted on
> the secondary drive were being copied from the primary. It got to a
> file that I knew to be fairly large, so I got up and went off to do
> other things. I was gone for a couple of hours. When I came back, it
> was still on the same file and the light on the secondary drive was
> blinking constantly. I opened another terminal and did a bunch of dfs,
> separated by a few seconds, and the blocks-in-use count did not
> change. I did some more dfs to be sure and got the same result. This
> was clearly not making progress, so I ctrl-c-ed out of the script and
> decided to finish this on a Linux system. I was not going to use the
> OpenBSD system on which I was doing this any more yesterday, so I ran
> shutdown, with the intent of pulling both drive connectors after the
> power went off. Except the system would not shut down. I got the
> 'Syncing disks' message and there it sat. The light on the secondary
> drive was still blinking. I waited for quite a few minutes, far longer
> than this usually takes, and finally, with no other options, I pulled
> the secondary drive's connector from the machine's usb socket. Some
> kernel messages appeared and the system shut down.
> 
> This morning, I  took the drives to the Linux system and,
> understanding that the secondary drive probably had not been sync-ed
> properly, ran fsck. There were many inconsistencies and problems with
> the meta-data, but I got through it and fsck completed. I am now
> running the rsync script on the Linux machine and it is proceeding
> normally, well past the place where things got stuck on OpenBSD
> yesterday.
> 
> I am guessing, but do not know, that the trouble here is either in the
> ext2 support or perhaps in the usb driver. If ext2, I realize that it
> is not widely used in the OpenBSD community. But the support is there
> and I chose the ext2 file-system for this reason, wanting a
> file-system that would work on either Linux or OpenBSD. I could have
> chosen UFS/FFS, but I didn't trust the support in Linux. Perhaps a bad
> decision.

The USB disks and ext2 are both quite slow on OpenBSD. Try with FFS but
you're not going to see better numbers.

On Linux, the kernel uses UAS for your USB disks. We only supports
bulk-only.

> 
> I realize that debugging this is likely to be difficult, but I will
> try to help in any way I can.
> 
> OpenBSD 6.1-current (GENERIC.MP) #69: Fri May 19 09:08:02 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8458735616 (8066MB)
> avail mem = 8196587520 (7816MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xbd1b7000 (89 entries)
> bios0: vendor LENOVO version "FWKT63A" date 12/08/2016
> bios0: LENOVO 10HYCTO1WW
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT TCPA MCFG HPET SSDT LPIT SSDT
> SSDT SSDT DBGP DBG2 SSDT MSDM SSDT UEFI SSDT LUFT ASF! BGRT
> acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4)
> PEG2(S4) SIO1(S3) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4)
> RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Pentium(R) CPU G4400T @ 2.90GHz, 2904.00 MHz
> cpu0: 
>

ext2 or usb problem

2017-07-01 Thread Donald Allen 
I have three Toshiba 1TB USB drives that I use for backups and
archives of my various systems. These disks pre-date my predominant
use of OpenBSD, and have ext2 file-systems. One of the disks is the
primary, to which new backups and archives are written. Another is the
secondary. When the primary changes, I have a script that rsyncs the
primary to the secondary. There's also a tertiary drive in my safe
deposit box, so there's an off-site copy of all this stuff.
Periodically, I rotate their roles, so the off-site drive doesn't get
too stale.

I did some backups yesterday to the primary drive and, for the first
time, ran the rsync script to copy primary to secondary on OpenBSD. I
created directories /tmp/primary and /tmp/secondary on which to mount
each of the file-systems. Then I mounted the primary drive with write
access and archived some files. I then umounted it with the intention
of re-mounting it read-only, except I got distracted at the wrong
moment by a phone call and didn't do it. After the call, I mounted the
secondary drive read-write and started the script to rsync the primary
to the secondary. Because there was nothing mounted on /tmp/primary,
rsync started deleting files wholesale. When I saw what was happening,
I ctrl-c-ed out of the script, did a df and saw my error. Shouldn't be
a big deal.

So I mounted the primary drive read-only and re-started the rsync
script and the right thing happened -- files that had been deleted on
the secondary drive were being copied from the primary. It got to a
file that I knew to be fairly large, so I got up and went off to do
other things. I was gone for a couple of hours. When I came back, it
was still on the same file and the light on the secondary drive was
blinking constantly. I opened another terminal and did a bunch of dfs,
separated by a few seconds, and the blocks-in-use count did not
change. I did some more dfs to be sure and got the same result. This
was clearly not making progress, so I ctrl-c-ed out of the script and
decided to finish this on a Linux system. I was not going to use the
OpenBSD system on which I was doing this any more yesterday, so I ran
shutdown, with the intent of pulling both drive connectors after the
power went off. Except the system would not shut down. I got the
'Syncing disks' message and there it sat. The light on the secondary
drive was still blinking. I waited for quite a few minutes, far longer
than this usually takes, and finally, with no other options, I pulled
the secondary drive's connector from the machine's usb socket. Some
kernel messages appeared and the system shut down.

This morning, I  took the drives to the Linux system and,
understanding that the secondary drive probably had not been sync-ed
properly, ran fsck. There were many inconsistencies and problems with
the meta-data, but I got through it and fsck completed. I am now
running the rsync script on the Linux machine and it is proceeding
normally, well past the place where things got stuck on OpenBSD
yesterday.

I am guessing, but do not know, that the trouble here is either in the
ext2 support or perhaps in the usb driver. If ext2, I realize that it
is not widely used in the OpenBSD community. But the support is there
and I chose the ext2 file-system for this reason, wanting a
file-system that would work on either Linux or OpenBSD. I could have
chosen UFS/FFS, but I didn't trust the support in Linux. Perhaps a bad
decision.

I realize that debugging this is likely to be difficult, but I will
try to help in any way I can.

OpenBSD 6.1-current (GENERIC.MP) #69: Fri May 19 09:08:02 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8458735616 (8066MB)
avail mem = 8196587520 (7816MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xbd1b7000 (89 entries)
bios0: vendor LENOVO version "FWKT63A" date 12/08/2016
bios0: LENOVO 10HYCTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT TCPA MCFG HPET SSDT LPIT SSDT
SSDT SSDT DBGP DBG2 SSDT MSDM SSDT UEFI SSDT LUFT ASF! BGRT
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4)
PEG2(S4) SIO1(S3) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4)
RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Pentium(R) CPU G4400T @ 2.90GHz, 2904.00 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,ERMS,INVPCID,RDSEED,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 290400 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR

Today's snapshot fixed a USB problem I wasn't aware I had

2016-09-20 Thread Peter N. M. Hansteen 
yes, really.

Today for the first time in weeks I inserted a USB storage drive on my
laptop, only to have the thing not react at all, as in no sign of
anything USB related appearing in any logs or dmesg when I inserted the
device.

Now for those files it was possible to transfer using a different
method, so I held off trying to write up a bug report until I had a
fresh snapshot installed. In the meantime I noticed in dmesg output
messages like

usb0 at xhci0: USB revision 3.0
usb0: root hub problem

which would of course explain why USB devices were not behaving.

But after I'd gotten around to installing today's snapshot, I got

usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev
3.00/1.00 addr 1
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev
2.00/1.00 addr 1

and the USB drive was recognized and mountable.

I had vaguely noticed some USB related commits recently, but hey, you
fixed things!

dmesg from today is up at
https://home.nuug.no/~peter/dmesg_elke_20160920.txt.

Thanks!

- Peter
-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
'

USB problem

2016-04-07 Thread Liviu Daia 
I have an APU1.C router monitoring an UPS through an USB cable.
Today I upgraded the UPS to a different model, and the router can't see
it:

uhub3: port 5, set config 0 at addr 2 failed
uhub3: device problem, disabling port 5

(full dmesg below).

The USB port on the router and the cable are fine, since they worked
with the old UPS.  The USB port on the new UPS seems fine too, since I
can see it on a Linux machine:

$ lsusb -s 1:9 -v
Bus 001 Device 009: ID 10af:0001 Liebert Corp. PowerSure PSA UPS
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize0 8
  idVendor   0x10af Liebert Corp.
  idProduct  0x0001 PowerSure PSA UPS
  bcdDevice0.14
  iManufacturer  19 
  iProduct1 
  iSerial 2 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   34
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID  10.01
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 511
 Report Descriptors: 
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval 232

Any idea?

Regards,

Liviu Daia


OpenBSD 5.9-current (GENERIC.MP) #1981: Thu Mar 31 14:51:55 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2098520064 (2001MB)
avail mem = 2030616576 (1936MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (7 entries)
bios0: vendor coreboot version "4.0" date 09/08/2014
bios0: PC Engines APU
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) 
PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) 
UOH4(S3) UOH5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD G-T40E Processor, 1000.12 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD G-T40E Processor, 1000.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu1: 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
acpiprt0 at acpi0: bus -1 (AGPB)
acpiprt1 at acpi0: bus -1 (HDMI)
acpiprt2 at acpi0: bus 1 (PBR4)
acpiprt3 at acpi0: bus 2 (PBR5)
acpiprt4 at acpi0: bus 3 (PBR6)
acpiprt5 at acpi0: bus -1 (PBR7)
acpiprt6 at acpi0: bus 5 (PE20)
acpiprt7 at acpi0: bus -1 (PE21)
acpiprt8 at acpi0: bus -1 (PE22)
acpiprt9 at acpi0: bus -1 (PE23)
acpiprt10 at acpi0: bus 0 (PCI0)
acpiprt11 at acpi0: bus 4 (PIBR)
acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS
acpicpu1 at acpi0:

USB problem after time_t change

2013-08-21 Thread Tristan Le Guern 
Hi,

I upgraded to a 64 bits time_t snapshots and can't connect my phone anymore.

When I plug it in any usb port I have these errors:
uhub3: port 1, set config at addr 4 failed
uhub3: device problem, disabling port 1

I tried with an usb mouse and an usb stick, and everything is fine:
uhidev0 at uhub3 port 4 configuration 1 interface 0 Logitech USB-PS/2
Optical Mouse rev 2.00/20.00 addr 3
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse1 at ums0 mux 0
umass0 at uhub3 port 3 configuration 1 interface 0 Verbatim Store 'n'
Go rev 2.00/1.00 addr 4
umass0: using SCSI over Bulk-Only
scsibus3 at umass0: 2 targets, initiator 0
sd1 at scsibus3 targ 1 lun 0: VBTM, Store 'n' Go, 1.04 SCSI0
0/direct removable serial.08ec0008DB5160201949
sd1: 979MB, 512 bytes/sector, 2004992 sectors

The device in question is a Android phone, a Xiaomi Mi 1s. Does
anyhave this kind of trouble?

dmesg:
OpenBSD 5.4-current (GENERIC.MP) #1: Mon Aug 12 20:16:33 PDT 2013
r...@morgaine.smi.sendmail.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 30config_unit,memory_size
real mem = 4066766848 (3878MB)
avail mem = 3950325760 (3767MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf25e0 (66 entries)
bios0: vendor Dell Inc. version A07 date 11/18/2010
bios0: Dell Inc. Latitude E5410
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG TCPA HPET BOOT SLIC SSDT
acpi0: wakeup devices AGP_(S4) P0P1(S4) UAR1(S3) HDEF(S4) PXSX(S4)
RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4)
PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz, 2394.41 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
cpu0: apic clock running at 133MHz
cpu1 at mainbus0: apid 4 (application processor)
cpu1: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz, 2394.01 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 2, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz, 2394.01 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 5 (application processor)
cpu3: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz, 2394.01 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 2, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 12 (P0P1)
acpiprt3 at acpi0: bus 1 (RP01)
acpiprt4 at acpi0: bus 2 (RP02)
acpiprt5 at acpi0: bus 3 (RP03)
acpiprt6 at acpi0: bus 5 (RP04)
acpiprt7 at acpi0: bus -1 (RP05)
acpiprt8 at acpi0: bus 11 (RP06)
acpiprt9 at acpi0: bus -1 (RP07)
acpiprt10 at acpi0: bus -1 (RP08)
acpiprt11 at acpi0: bus -1 (PEG3)
acpiprt12 at acpi0: bus -1 (PEG5)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C1, PSS
acpicpu1 at acpi0: C3, C1, PSS
acpicpu2 at acpi0: C3, C1, PSS
acpicpu3 at acpi0: C3, C1, PSS
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PBTN
acpibtn2 at acpi0: SBTN
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model DELL PW64011 serial 3460 type LION oem Sanyo
acpibat1 at acpi0: BAT1 not present
acpivideo0 at acpi0: VID_
acpivideo1 at acpi0: VID_
acpivout0 at acpivideo1: LCD_
cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2399, 2266, 2133, 1999,
1866, 1733, 1599, 1466, 1333, 1199, 1066, 933 MHz
pci0 at mainbus0 bus 0
vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1440x900
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 Intel 3400 USB rev 0x05: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root