On 22.12.2011 18:39, Greg KH wrote:
On Thu, Dec 22, 2011 at 12:48:45PM +0100, Matthias Fuchs wrote:
Hi,
I ran into trouble when using the MPC5121 with full speed
USB devices. I've seen the issue with USB serial converters
based on FTDI and Prolific chips.
After connecting the device they
On Tue, 2012-01-03 at 16:19 +0200, Gilad Ben-Yossef wrote:
on_each_cpu() returns as its own return value the return value of
smp_call_function(). smp_call_function() in turn returns a hard
coded value of zero.
Some callers to on_each_cpu() waste cycles and bloat code space
by checking the
On 01/05/12 19:22, Scott Wood wrote:
On 01/05/2012 09:58 AM, Norbert van Bolhuis wrote:
thanks for your response.
not setting MSR_POW gives same result.
OK, so you're not getting an interrupt regardless of low-power state.
Check whether the interrupt is getting masked during standby
On Fri, 6 Jan 2012, Matthias Fuchs wrote:
For my eyes it does not really look like a general USB issue.
It looks like a problem with the Freescale EHCI implementation that is
influenced by high interrupt or internal bus load caused by the flood ping.
Indeed, it might be a problem with the
Add support for byte queue limits (BQL), based on the similar
modifications made to intel/igb/igb_main.c from Eric Dumazet
in commit bdbc063129e811264cd6c311d8c2d9b95de01231.
A local variable for tx_queue-qindex was introduced in
gfar_clean_tx_ring, since it is now used often enough to warrant
On 01/06/2012 07:53 AM, Norbert van Bolhuis wrote:
On 01/05/12 19:22, Scott Wood wrote:
On 01/05/2012 09:58 AM, Norbert van Bolhuis wrote:
thanks for your response.
not setting MSR_POW gives same result.
OK, so you're not getting an interrupt regardless of low-power state.
Check whether
A kernel oops/panic prints an instruction dump showing several
instructions before and after the instruction which caused the
oops/panic.
The code intended that the faulting instruction be enclosed in angle
brackets, however a bug caused the faulting instruction to be
interpreted by printk() as
On Fri, 2012-01-06 at 14:34 -0800, Ira W. Snyder wrote:
A kernel oops/panic prints an instruction dump showing several
instructions before and after the instruction which caused the
oops/panic.
The code intended that the faulting instruction be enclosed in angle
brackets, however a bug
On Sat, Jan 07, 2012 at 09:50:10AM +1100, Benjamin Herrenschmidt wrote:
On Fri, 2012-01-06 at 14:34 -0800, Ira W. Snyder wrote:
A kernel oops/panic prints an instruction dump showing several
instructions before and after the instruction which caused the
oops/panic.
The code intended
I know this is a long-dead thread, but I was a little curious about
the motivation here.
I'm looking at trying to support CONFIG_CMDLINE_EXTEND (an ARM
Kconfig) in this function and don't know in which cases I should look
at the CONFIG_CMDLINE and in which cases I should use whatever
happened to
10 matches
Mail list logo