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 st...@rowland.harvard.edu:
On Wed, 30 Apr 2014, Matteo Fortini wrote:
Thank you Alan,
here you go: http://pastebin.com/txu8M68L we included
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
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
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.
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.
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
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 tainted
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-
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+
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
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
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?
12 matches
Mail list logo
