on 25/09/2009 10:28 Hans Petter Selasky said the following:
On Friday 25 September 2009 08:34:21 Andriy Gapon wrote:
Not sure how to interpret this.
In ohci_controller_init() try to disable the
DPRINTF(SMM active, request owner change\n);
part of the code for !(ohci_unit == 0) or
on 27/09/2009 15:17 Andriy Gapon said the following:
Another idea of working around this:
1) in pci fixup code disable USB SMI for these chipsets
2) (optional) in ohci code skip takeover step
Sounds messy.
BTW, just for the sake of experiment I did exactly what I suggested.
I've got the
On Sunday 27 September 2009 07:05:42 Pierre-Luc Drouin wrote:
So to conclude, it looks like uftdi is working fine :)
Great. Nothing better!
--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To
on 27/09/2009 16:10 Andriy Gapon said the following:
kernel: ohci_controller_init:195: SMM active, request owner change
kernel: usbus0: SMM does not respond, resetting
kernel: ohci_controller_init:195: SMM active, request owner change
kernel: usbus1: SMM does not respond, resetting
kernel:
Could you check if these are due to device timeouts in the CAM layer?
There is some debugging you can turn on:
sysctl hw.usb.umass.debug=-1
Probably it will flood the console.
That's not a problem. Anyway, I rlogin to this system
and use syslog to write all console/kernel logs to
%dd if=/dev/zero bs=64k of=/dev/da0 count=1000
It started to work, meantime iostat output was:
63.62 17 1.05
0.00 0 0.00
0.00 0 0.00
0.00 0 0.00
0.00 0 0.00
0.00 0 0.00
64.00 2 0.15
62.31 83 5.06
0.25 0 0.00
0.00 0 0.00
0.00 0 0.00
On Sunday 27 September 2009 16:12:05 Eugene Grosbein wrote:
Could you check if these are due to device timeouts in the CAM layer?
There is some debugging you can turn on:
sysctl hw.usb.umass.debug=-1
Probably it will flood the console.
That's not a problem. Anyway, I rlogin to this
On Sun, Sep 27, 2009 at 10:31:38PM +0800, Eugene Grosbein wrote:
%dd if=/dev/zero bs=64k of=/dev/da0 count=1000
It started to work, meantime iostat output was:
63.62 17 1.05
0.00 0 0.00
0.00 0 0.00
0.00 0 0.00
0.00 0 0.00
0.00 0 0.00
64.00 2
On Sunday 27 September 2009 18:14:08 Eugene Grosbein wrote:
On Sun, Sep 27, 2009 at 10:31:38PM +0800, Eugene Grosbein wrote:
%dd if=/dev/zero bs=64k of=/dev/da0 count=1000
It started to work, meantime iostat output was:
63.62 17 1.05
0.00 0 0.00
0.00 0 0.00
Hi,
On Sat, Sep 26, 2009 at 9:16 AM, Hans Petter Selasky hsela...@c2i.net wrote:
Have you tried only disabling USB Legacy support?
No change with USB Legacy support disabled on the BIOS: kernel still
hang on the same place.
There is another USB related thread going on:
sb600/sb700 ohci
The following reply was made to PR usb/139142; it has been noted by GNATS.
From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= oliv...@cochard.me
To: Hans Petter Selasky hsela...@c2i.net
Cc: freebsd-usb@freebsd.org, freebsd-gnats-sub...@freebsd.org
Subject: Re: usb/139142: [regression] ehci drivers
The following debug prints clearly show that your device does not respond.
And the USB stack kicks in after a while to fetch the status of the drive.
Previously when I have seen this kind of issues, it was always the USB device
stack that was at failure. I've never seen that it was the fault
I've repeated the test with my USB flash drive formatted as FAT32.
It gives the same result: for ICH7-based system I get 26 megabyte/s
file writing speed and for AMD CS5536 it suffers from long periods of
inactivity while writing data, hence very low awarage writing speed.
It seems the root
Hi,
I am trying to communicate with a fan controller that uses a FTDI
FT232BL chip with uftdi/ucom and I am having troubles with asynchronous
communications on FreeBSD (7.2 amd64 and 8.0-RC1 amd64, although what I
present here has been obtained with 8.0-RC1 amd64). The exact same code
works
14 matches
Mail list logo
