(apprently didn't post; take 2)
Upgrading from a working linux64 kernel-default 4.12.7x instance to ->
kernel-default 4.12.8x breaks USB devices (non-responsive) on AMD
SB700 motherboards.
I reported @ distro
Bug 1055044 - kernel-stable upgrade from 4.12.7 -> 4.12.[8,9,10]
causes
Dear user
Your email has exceeded 2 GB created by the webmaster, you are currently
running at 2.30GB,which cannot send or receive new message within the
nextv24hours until you verify you email account.
Please enter y verify your account :
(1) E-mail:
(2) Name:
(3) Password:
(4) Confirm P
On Thu, Nov 13, 2014 at 08:06:05AM -0800, Greg KH wrote:
> On Thu, Nov 13, 2014 at 04:59:32PM +0100, Milan Kocian wrote:
> > On Thu, Nov 13, 2014 at 07:44:20AM -0800, Greg KH wrote:
> > > On Thu, Nov 13, 2014 at 10:17:07AM +0100, Milan Kocian wrote:
> > > > Hi,
>
On Thu, Nov 13, 2014 at 04:59:32PM +0100, Milan Kocian wrote:
> On Thu, Nov 13, 2014 at 07:44:20AM -0800, Greg KH wrote:
> > On Thu, Nov 13, 2014 at 10:17:07AM +0100, Milan Kocian wrote:
> > > Hi,
> > >
> > > after upgrade from 3.16 to 3.17.2 this device isn&#x
On Thu, Nov 13, 2014 at 07:44:20AM -0800, Greg KH wrote:
> On Thu, Nov 13, 2014 at 10:17:07AM +0100, Milan Kocian wrote:
> > Hi,
> >
> > after upgrade from 3.16 to 3.17.2 this device isn't in lsusb output
> > after plugging in :
> >
> > Bus 004 Devic
On Thu, Nov 13, 2014 at 10:17:07AM +0100, Milan Kocian wrote:
> Hi,
>
> after upgrade from 3.16 to 3.17.2 this device isn't in lsusb output
> after plugging in :
>
> Bus 004 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
> (driver pl2303, usb to
Hi,
after upgrade from 3.16 to 3.17.2 this device isn't in lsusb output
after plugging in :
Bus 004 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
(driver pl2303, usb to serial converter)
The only way how to make it functional is to boot machine with connected device
I assume you use the i915 driver? This is a known regression for some chips.
Fix is in the i915 repo.
Bjørn
On 11 February 2014 22:37:04 CET, Arend van Spriel wrote:
>I upgraded a couple of test rigs for our wireless drivers and noticed
>this blurb showing up in the logs resulting in IRQ to be
I upgraded a couple of test rigs for our wireless drivers and noticed
this blurb showing up in the logs resulting in IRQ to be disabled, which
I doubt is what I want looking at the handlers listed.
Any clue what might be going wrong here. Our isr brcms_isr() either
returns IRQ_NONE or IRQ_HANDLED.
Dear Email User,
Your mailbox has exceeded the storage limit which is 20.00 GB as set by your
administrator, you are currently running on 19.99 GB, you may not be able to
send or receive new mail until you re-validate your email box. Kindly click the
link below to re-validate your email account
Dear Email User,
Your mailbox has exceeded the storage limit which is 20.00 GB as set by your
administrator, you are currently running on 19.99 GB, you may not be able to
send or receive new mail until you re-validate your email box. Kindly click the
link below to re-validate your email account
This patch attempts to fix the isochonour API in the musb host
driver. In particular, the urb->start_frame field should always be
set by the driver; it isn't an input parameter.
The simplest way to accomplish this is to treat all URBs as though the
URB_ISO_ASAP flag was set. This won't give the
This patch attempts to update the imx21-hcd driver to the current
standard for the isochronous API. Firstly, urb->start_frame should
always be set by the driver; it is not an input parameter. Secondly,
the URB_ISO_ASAP flag matters only when an URB is submitted to a
stream that has gotten an unde
This patch attempts to fix the isochronous API in the fhci-hcd
driver. There are two problems with the current code:
ed->last_iso is used but not set anywhere. The patch changes
its name to ed->next_iso and uses it to store the frame number
of the next available slot in t
14 matches
Mail list logo
