On Wed, 28 May 2014, Matteo Fortini wrote:
> Hi Alan,
> I was wondering if the patch for the OHCI controller bug could be
> tested on our system.
It isn't finished yet. I have been distracted by lots of other things.
I'll let you know when it is ready.
Alan Stern
--
To unsubscribe from this
Hi Alan,
I was wondering if the patch for the OHCI controller bug could be
tested on our system.
Thank you,
Matteo
2014-04-30 22:29 GMT+02:00 Alan Stern :
> On Wed, 30 Apr 2014, Matteo Fortini wrote:
>
>> Thank you Alan,
>> here you go: http://pastebin.com/txu8M68L we included the register file
>
Great, thank you!
Just tell me if you need any help.
Matteo
Il 30/04/2014 22:29, Alan Stern ha scritto:
On Wed, 30 Apr 2014, Matteo Fortini wrote:
Thank you Alan,
here you go: http://pastebin.com/txu8M68L we included the register file
both before and after the hangup, with a 1s interval.
Th
On Wed, 30 Apr 2014, Matteo Fortini wrote:
> Thank you Alan,
> here you go: http://pastebin.com/txu8M68L we included the register file
> both before and after the hangup, with a 1s interval.
Thanks. This confirms the reason for the problem. It's a hardware bug
in the OHCI controller; after com
Thank you Alan,
here you go: http://pastebin.com/txu8M68L we included the register file
both before and after the hangup, with a 1s interval.
Matteo
Il 25/04/2014 18:29, Alan Stern ha scritto:
On Thu, 24 Apr 2014, Matteo Fortini wrote:
After some time, we finally had another hangup on kern
On Thu, 24 Apr 2014, Matteo Fortini wrote:
> After some time, we finally had another hangup on kernel 3.14.
>
> @Alan: Here's the info we got in the files you mentioned. At any rate,
> we're keeping the board in the same state so that we can run/produce any
> other needed info.
>
> http://past
After some time, we finally had another hangup on kernel 3.14.
@Alan: Here's the info we got in the files you mentioned. At any rate,
we're keeping the board in the same state so that we can run/produce any
other needed info.
http://pastebin.com/DZPAqjcd
Thank you,
Matteo
Il 16/04/2014 1
On Wed, 16 Apr 2014, Matteo Fortini wrote:
> It's and AMD Geode single board computer, using CS5535 companion chip.
>
> Here's the pertaining lspci -vvv section:
>
> 00:0f.4 Class 0c03: Device 1022:2094 (rev 02) (prog-if 10)
> Subsystem: Device 1022:2094
> Control: I/O- Mem+ BusMaster+
It's and AMD Geode single board computer, using CS5535 companion chip.
Here's the pertaining lspci -vvv section:
00:0f.4 Class 0c03: Device 1022:2094 (rev 02) (prog-if 10)
Subsystem: Device 1022:2094
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- Fas
On Tue, 15 Apr 2014, Matteo Fortini wrote:
> Yes, we tried with 3.14 and after less than 24hrs.
>
> What could we do to fix the issue?
>
> Thank you,
> Matteo
>
> Here's dmesg output:
>
> [103200.145660] INFO: task :2341 blocked for more than 120 seconds.
> [103200.145774] Not ta
Yes, we tried with 3.14 and after less than 24hrs.
What could we do to fix the issue?
Thank you,
Matteo
Here's dmesg output:
[103200.145660] INFO: task :2341 blocked for more than 120 seconds.
[103200.145774] Not tainted 3.14.0-+ #3
[103200.145844] "echo 0 > /proc/sys/kern
On Fri, Apr 11, 2014 at 12:19:55PM +0200, Matteo Fortini wrote:
> We are experiencing stuck processes (D state) which are talking to an
> FTD_SIO usb_serial adapter. The process sometimes has to close the
> serial device when it detects an error or a timeout.
Does this also happen with 3.14?
th
We are experiencing stuck processes (D state) which are talking to an
FTD_SIO usb_serial adapter. The process sometimes has to close the
serial device when it detects an error or a timeout.
We rebuilt the kernel with the CONFIG_DEBUG_USB option and the stuck
processes reporting enabled.
The
13 matches
Mail list logo
