On Thu, Nov 29, 2018 at 4:33 AM Greg Kroah-Hartman
wrote:
>
> On Thu, Oct 04, 2018 at 03:13:56PM -0500, Mitch Harder wrote:
> > On Mon, Sep 17, 2018 at 5:42 PM, Greg Kroah-Hartman
> > wrote:
> > > 4.14-stable review patch. If anyone has any objections
On Thu, Nov 29, 2018 at 4:33 AM Greg Kroah-Hartman
wrote:
>
> On Thu, Oct 04, 2018 at 03:13:56PM -0500, Mitch Harder wrote:
> > On Mon, Sep 17, 2018 at 5:42 PM, Greg Kroah-Hartman
> > wrote:
> > > 4.14-stable review patch. If anyone has any objections
On Mon, Sep 17, 2018 at 5:42 PM, Greg Kroah-Hartman
wrote:
> 4.14-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Eric Dumazet
>
> commit bffa72cf7f9df842f0016ba03586039296b4caaf upstream
>
> skb->rbnode shares space with skb->next,
On Mon, Sep 17, 2018 at 5:42 PM, Greg Kroah-Hartman
wrote:
> 4.14-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Eric Dumazet
>
> commit bffa72cf7f9df842f0016ba03586039296b4caaf upstream
>
> skb->rbnode shares space with skb->next,
ACK
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Alex Williamson
> Sent: Monday, July 27, 2015 4:19 PM
> To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
>
ACK
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Alex Williamson
> Sent: Monday, July 27, 2015 4:19 PM
> To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
>
ACK
-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
Behalf Of Alex Williamson
Sent: Monday, July 27, 2015 4:19 PM
To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject:
ACK
-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
Behalf Of Alex Williamson
Sent: Monday, July 27, 2015 4:19 PM
To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject:
On Tue, Aug 20, 2013 at 9:51 AM, Mitch Harder
wrote:
> On Sun, Aug 18, 2013 at 11:44 PM, Minchan Kim wrote:
>> Hello,
>>
>> On Mon, Aug 19, 2013 at 12:13:02PM +0800, Michael wang wrote:
>>> Hi, Mitch
>>>
>>> On 08/17/2013 10:01 PM, Mitch Harder
On Tue, Aug 20, 2013 at 9:51 AM, Mitch Harder
mitch.har...@sabayonlinux.org wrote:
On Sun, Aug 18, 2013 at 11:44 PM, Minchan Kim minc...@kernel.org wrote:
Hello,
On Mon, Aug 19, 2013 at 12:13:02PM +0800, Michael wang wrote:
Hi, Mitch
On 08/17/2013 10:01 PM, Mitch Harder wrote:
I'm
On Sun, Aug 18, 2013 at 11:44 PM, Minchan Kim wrote:
> Hello,
>
> On Mon, Aug 19, 2013 at 12:13:02PM +0800, Michael wang wrote:
>> Hi, Mitch
>>
>> On 08/17/2013 10:01 PM, Mitch Harder wrote:
>> > I'm encountering a BUG while using a ZRAM Swap device.
>&
On Sun, Aug 18, 2013 at 11:44 PM, Minchan Kim minc...@kernel.org wrote:
Hello,
On Mon, Aug 19, 2013 at 12:13:02PM +0800, Michael wang wrote:
Hi, Mitch
On 08/17/2013 10:01 PM, Mitch Harder wrote:
I'm encountering a BUG while using a ZRAM Swap device.
The call trace seems to involve
I'm encountering a BUG while using a ZRAM Swap device.
The call trace seems to involve the changes recently added to 3.10.6
by the patch:
zram: use zram->lock to protect zram_free_page() in swap free notify path
The hardware is a x86 single CPU AMD Athlon XP system with 1GB RAM.
I'm
I'm encountering a BUG while using a ZRAM Swap device.
The call trace seems to involve the changes recently added to 3.10.6
by the patch:
zram: use zram-lock to protect zram_free_page() in swap free notify path
The hardware is a x86 single CPU AMD Athlon XP system with 1GB RAM.
I'm implementing
On 1/18/2013 4:35 PM, H. Peter Anvin wrote:
> On 01/18/2013 05:05 PM, Mitch Bradley wrote:
>>
>>
>> On 1/18/2013 2:42 PM, H. Peter Anvin wrote:
>>> On 01/18/2013 04:40 PM, Andres Salomon wrote:
>>>> Bad news on this patch; I've been told that it brea
On 1/18/2013 2:42 PM, H. Peter Anvin wrote:
> On 01/18/2013 04:40 PM, Andres Salomon wrote:
>> Bad news on this patch; I've been told that it breaks booting on an
>> XO-1.5. Does anyone from OLPC know why yet?
>
> What are the settings of CR0 and CR4 on kernel entry on XO-1.5?
CR0 is
On 1/18/2013 2:42 PM, H. Peter Anvin wrote:
On 01/18/2013 04:40 PM, Andres Salomon wrote:
Bad news on this patch; I've been told that it breaks booting on an
XO-1.5. Does anyone from OLPC know why yet?
What are the settings of CR0 and CR4 on kernel entry on XO-1.5?
CR0 is 0x8011
CR4
On 1/18/2013 4:35 PM, H. Peter Anvin wrote:
On 01/18/2013 05:05 PM, Mitch Bradley wrote:
On 1/18/2013 2:42 PM, H. Peter Anvin wrote:
On 01/18/2013 04:40 PM, Andres Salomon wrote:
Bad news on this patch; I've been told that it breaks booting on an
XO-1.5. Does anyone from OLPC know why
On Wed, Dec 19, 2012 at 11:21 AM, Nitin Gupta wrote:
> On 12/19/2012 08:17 AM, Greg KH wrote:
>> On Wed, Dec 19, 2012 at 07:53:36AM -0800, Nitin Gupta wrote:
>>> On 12/19/2012 07:08 AM, Greg KH wrote:
On Tue, Dec 18, 2012 at 11:21:28PM -0800, Nitin Gupta wrote:
> On 12/18/2012 07:49 PM,
On Wed, Dec 19, 2012 at 11:21 AM, Nitin Gupta ngu...@vflare.org wrote:
On 12/19/2012 08:17 AM, Greg KH wrote:
On Wed, Dec 19, 2012 at 07:53:36AM -0800, Nitin Gupta wrote:
On 12/19/2012 07:08 AM, Greg KH wrote:
On Tue, Dec 18, 2012 at 11:21:28PM -0800, Nitin Gupta wrote:
On 12/18/2012 07:49
On 12/17/2012 12:04 PM, Stephen Warren wrote:
> On 12/17/2012 02:58 PM, Mitch Bradley wrote:
>> On 12/17/2012 11:36 AM, Stephen Warren wrote:
>>> On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
>>>> Nvidia's Tegra has multiple uart controller which supports:
>&g
On 12/17/2012 11:36 AM, Stephen Warren wrote:
> On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
>> Nvidia's Tegra has multiple uart controller which supports:
>> - APB dma based controller fifo read/write.
>> - End Of Data interrupt in incoming data to know whether end
>> of frame achieve or not.
On 12/17/2012 11:36 AM, Stephen Warren wrote:
On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
Nvidia's Tegra has multiple uart controller which supports:
- APB dma based controller fifo read/write.
- End Of Data interrupt in incoming data to know whether end
of frame achieve or not.
- Hw
On 12/17/2012 12:04 PM, Stephen Warren wrote:
On 12/17/2012 02:58 PM, Mitch Bradley wrote:
On 12/17/2012 11:36 AM, Stephen Warren wrote:
On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
Nvidia's Tegra has multiple uart controller which supports:
- APB dma based controller fifo read/write
On 11/13/2012 8:29 AM, Stephen Warren wrote:
> On 11/13/2012 11:10 AM, Mitch Bradley wrote:
>> It seems to me that this capebus discussion is missing an important
>> point. The name capebus suggests that it is a bus, so there should be a
>> parent node to represent that
s.
If something about the design of capebus makes that impossible, I
respectfully suggest that its design should be reviewed, taking into
account the many years of industry experience about modularity.
Mitch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
respectfully suggest that its design should be reviewed, taking into
account the many years of industry experience about modularity.
Mitch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 11/13/2012 8:29 AM, Stephen Warren wrote:
On 11/13/2012 11:10 AM, Mitch Bradley wrote:
It seems to me that this capebus discussion is missing an important
point. The name capebus suggests that it is a bus, so there should be a
parent node to represent that bus. It should have a driver
On 11/8/2012 3:28 AM, Koen Kooi wrote:
>
> Op 7 nov. 2012, om 23:35 heeft Ryan Mallon het volgende
> geschreven:
>
>> On 06/11/12 08:40, Tabi Timur-B04825 wrote:
>>> On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely
>>> wrote:
>>>
Jane is building custom BeagleBone expansion boards called
On 11/8/2012 3:28 AM, Koen Kooi wrote:
Op 7 nov. 2012, om 23:35 heeft Ryan Mallon rmal...@gmail.com het volgende
geschreven:
On 06/11/12 08:40, Tabi Timur-B04825 wrote:
On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely grant.lik...@secretlab.ca
wrote:
Jane is building custom BeagleBone
On 11/6/2012 12:37 PM, Stephen Warren wrote:
> On 11/05/2012 01:40 PM, Grant Likely wrote:
>> Hey folks,
>>
>> As promised, here is my early draft to try and capture what device
>> tree overlays need to do and how to get there. Comments and
>> suggestions greatly appreciated.
>
> Interesting.
On 11/6/2012 12:37 PM, Stephen Warren wrote:
On 11/05/2012 01:40 PM, Grant Likely wrote:
Hey folks,
As promised, here is my early draft to try and capture what device
tree overlays need to do and how to get there. Comments and
suggestions greatly appreciated.
Interesting. This just came
On 10/23/2012 1:15 PM, Jon Hunter wrote:
> Hi Mitch,
>
> On 10/23/2012 11:55 AM, Mitch Bradley wrote:
>> On 10/23/2012 4:49 AM, Jon Hunter wrote:
>>
>>> Therefore, I believe it will improve search time and hence, boot time if
>>> we have interrupt-parent
it".
Now I see that you meant that the driver should explicitly call
abstracted functions.
On 10/23/2012 7:20 AM, Felipe Balbi wrote:
> HI,
>
> On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote:
>> On 10/23/2012 12:03 AM, Felipe Balbi wrote:
>>> Hi,
>>&g
On 10/23/2012 12:03 AM, Felipe Balbi wrote:
> Hi,
>
> I much prefer having drivers explicitly manage all their resources,
> which would mean that pinctrl calls need to be done on probe() and, if
> necessary, during suspend()/resume().
Per-driver resource management is certainly convenient when
On 10/23/2012 4:49 AM, Jon Hunter wrote:
> Therefore, I believe it will improve search time and hence, boot time if
> we have interrupt-parent defined in each node.
I strongly suspect (based on many years of performance tuning, with
special focus on boot time) that the time difference will be
On 10/23/2012 4:49 AM, Jon Hunter wrote:
Therefore, I believe it will improve search time and hence, boot time if
we have interrupt-parent defined in each node.
I strongly suspect (based on many years of performance tuning, with
special focus on boot time) that the time difference will be
On 10/23/2012 12:03 AM, Felipe Balbi wrote:
Hi,
I much prefer having drivers explicitly manage all their resources,
which would mean that pinctrl calls need to be done on probe() and, if
necessary, during suspend()/resume().
Per-driver resource management is certainly convenient when you
meant that the driver should explicitly call
abstracted functions.
On 10/23/2012 7:20 AM, Felipe Balbi wrote:
HI,
On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote:
On 10/23/2012 12:03 AM, Felipe Balbi wrote:
Hi,
I much prefer having drivers explicitly manage all
On 10/23/2012 1:15 PM, Jon Hunter wrote:
Hi Mitch,
On 10/23/2012 11:55 AM, Mitch Bradley wrote:
On 10/23/2012 4:49 AM, Jon Hunter wrote:
Therefore, I believe it will improve search time and hence, boot time if
we have interrupt-parent defined in each node.
I strongly suspect (based
On 10/10/2012 1:16 PM, David Gibson wrote:
> On Wed, Oct 10, 2012 at 10:33:31AM -0500, Rob Herring wrote:
>> On 10/10/2012 10:16 AM, Stephen Warren wrote:
>>> On 10/10/2012 01:24 AM, David Gibson wrote:
On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
> On Oct 9, 2012, at 6:04
On 10/10/2012 8:45 AM, Stephen Warren wrote:
> On 10/10/2012 12:23 PM, Mitch Bradley wrote:
>> On 10/10/2012 7:09 AM, Rob Herring wrote:
>>> On 10/09/2012 04:16 PM, Stephen Warren wrote:
>>>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>>>>>
>&g
On 10/10/2012 8:40 AM, Stephen Warren wrote:
> On 10/10/2012 11:09 AM, Rob Herring wrote:
>> On 10/09/2012 04:16 PM, Stephen Warren wrote:
>>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>
> What more do you think needs discussion re: dtc+cpp?
How not to abuse the ever-loving
On 10/10/2012 7:09 AM, Rob Herring wrote:
> On 10/09/2012 04:16 PM, Stephen Warren wrote:
>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
What more do you think needs discussion re: dtc+cpp?
>>>
>>> How not to abuse the ever-loving shit out of it? :-)
>>
>> Perhaps we can just handle this
On 10/10/2012 7:09 AM, Rob Herring wrote:
On 10/09/2012 04:16 PM, Stephen Warren wrote:
On 10/01/2012 12:39 PM, Jon Loeliger wrote:
What more do you think needs discussion re: dtc+cpp?
How not to abuse the ever-loving shit out of it? :-)
Perhaps we can just handle this through the regular
On 10/10/2012 8:40 AM, Stephen Warren wrote:
On 10/10/2012 11:09 AM, Rob Herring wrote:
On 10/09/2012 04:16 PM, Stephen Warren wrote:
On 10/01/2012 12:39 PM, Jon Loeliger wrote:
What more do you think needs discussion re: dtc+cpp?
How not to abuse the ever-loving shit out of it? :-)
On 10/10/2012 8:45 AM, Stephen Warren wrote:
On 10/10/2012 12:23 PM, Mitch Bradley wrote:
On 10/10/2012 7:09 AM, Rob Herring wrote:
On 10/09/2012 04:16 PM, Stephen Warren wrote:
On 10/01/2012 12:39 PM, Jon Loeliger wrote:
What more do you think needs discussion re: dtc+cpp?
How
On 10/10/2012 1:16 PM, David Gibson wrote:
On Wed, Oct 10, 2012 at 10:33:31AM -0500, Rob Herring wrote:
On 10/10/2012 10:16 AM, Stephen Warren wrote:
On 10/10/2012 01:24 AM, David Gibson wrote:
On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
On Oct 9, 2012, at 6:04 PM, Scott Wood
On 10/9/2012 11:16 AM, Stephen Warren wrote:
> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>>
>>> What more do you think needs discussion re: dtc+cpp?
>>
>> How not to abuse the ever-loving shit out of it? :-)
>
> Perhaps we can just handle this through the regular patch review
> process; I
On 10/9/2012 11:16 AM, Stephen Warren wrote:
On 10/01/2012 12:39 PM, Jon Loeliger wrote:
What more do you think needs discussion re: dtc+cpp?
How not to abuse the ever-loving shit out of it? :-)
Perhaps we can just handle this through the regular patch review
process; I think it may be
On Thu, Aug 16, 2012 at 5:17 PM, Andi Kleen wrote:
> On Thu, Aug 16, 2012 at 11:55:06AM -0700, james northrup wrote:
>> looks like ARM results are inconclusive from a lot of folks without
>> bandwidth to do a write-up, what about just plain STAGING status for ARM so
>> the android tweakers can
On 8/16/2012 8:38 AM, Stephen Warren wrote:
> On 08/16/2012 12:08 AM, Alexandre Courbot wrote:
>> Some device drivers (panel backlights especially) need to follow precise
>> sequences for powering on and off, involving gpios, regulators, PWMs
>> with a precise powering order and delays to respect
On 8/16/2012 8:38 AM, Stephen Warren wrote:
On 08/16/2012 12:08 AM, Alexandre Courbot wrote:
Some device drivers (panel backlights especially) need to follow precise
sequences for powering on and off, involving gpios, regulators, PWMs
with a precise powering order and delays to respect between
On Thu, Aug 16, 2012 at 5:17 PM, Andi Kleen a...@firstfloor.org wrote:
On Thu, Aug 16, 2012 at 11:55:06AM -0700, james northrup wrote:
looks like ARM results are inconclusive from a lot of folks without
bandwidth to do a write-up, what about just plain STAGING status for ARM so
the android
On 8/6/2012 5:58 PM, Johannes Stezenbach wrote:
> On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote:
>> On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren wrote:
>>
>>> I can't comment on the sysfs-vs-dev interface location, but I don't
>>> think it addresses Johannes' issue; finding out
On 8/6/2012 5:58 PM, Johannes Stezenbach wrote:
On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote:
On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren swar...@wwwdotorg.org wrote:
I can't comment on the sysfs-vs-dev interface location, but I don't
think it addresses Johannes' issue;
On 8/1/2012 9:47 AM, Alex Courbot wrote:
> On 07/31/2012 09:55 PM, Mitch Bradley wrote:
>> On 7/31/2012 8:38 PM, Thierry Reding wrote:
>>> On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
>>>> On 7/31/2012 6:56 PM, Thierry Reding wrote:
>>>>
On 7/31/2012 8:38 PM, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
>> On 7/31/2012 6:56 PM, Thierry Reding wrote:
>>> On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
>>>> On 07/31/2012 07:45 AM, Stephen Warren
On 7/31/2012 6:56 PM, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
>> On 07/31/2012 07:45 AM, Stephen Warren wrote:
>>> I wonder if using the same structure/array as input and output would
>>> simplify the API; the platform data would fill in the fields
On 7/31/2012 6:56 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen Warren wrote:
I wonder if using the same structure/array as input and output would
simplify the API; the platform data would fill in the fields mentioned
On 7/31/2012 8:38 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
On 7/31/2012 6:56 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen Warren wrote:
I wonder if using the same
On 8/1/2012 9:47 AM, Alex Courbot wrote:
On 07/31/2012 09:55 PM, Mitch Bradley wrote:
On 7/31/2012 8:38 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
On 7/31/2012 6:56 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot
On Wed, Jul 18, 2012 at 8:28 PM, David Sterba wrote:
> On Fri, Jul 13, 2012 at 10:19:14AM -0500, Mitch Harder wrote:
>> I was testing the lz4(hc) patches, and I found the the compression
>> INCOMPAT flags are not being updated using the method in this patch.
>>
>> The
On Wed, Jul 18, 2012 at 8:28 PM, David Sterba d...@jikos.cz wrote:
On Fri, Jul 13, 2012 at 10:19:14AM -0500, Mitch Harder wrote:
I was testing the lz4(hc) patches, and I found the the compression
INCOMPAT flags are not being updated using the method in this patch.
The compression INCOMPAT
On Thu, Jun 28, 2012 at 10:40 AM, David Sterba wrote:
> On Tue, Jun 26, 2012 at 08:48:37AM +0200, Arnd Hannemann wrote:
>> How show should we proceed to get above mentioned patch
>> (or the similar patch from Andrei Popa) merged?
>
> Josef picked the patch into btrfs-next, I see not problem to
On Thu, Jun 28, 2012 at 10:40 AM, David Sterba d...@jikos.cz wrote:
On Tue, Jun 26, 2012 at 08:48:37AM +0200, Arnd Hannemann wrote:
How show should we proceed to get above mentioned patch
(or the similar patch from Andrei Popa) merged?
Josef picked the patch into btrfs-next, I see not problem
to trigger it ever so often if there is other
activity also going on.
M
Original Message
Subject: Re: ext3 SMP bug ? PANIC in __d_find_alias
Date: Wed, 12 Dec 2007 20:36:40 +0100
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
To: Mitch <[EMAIL PROTECTED]>
CC: linux-
? The fact that this is tainted (due to nvidia) is a red herring i
think because both my machines (the SMP and UP one) are using the same
nvidia module and the panic is in ext3 code.
Help
Mitch
Dec 10 03:02:43 home kernel: BUG: unable to handle kernel NULL pointer
dereference at virtual address
? The fact that this is tainted (due to nvidia) is a red herring i
think because both my machines (the SMP and UP one) are using the same
nvidia module and the panic is in ext3 code.
Help
Mitch
Dec 10 03:02:43 home kernel: BUG: unable to handle kernel NULL pointer
dereference at virtual address
it ever so often if there is other
activity also going on.
M
Original Message
Subject: Re: ext3 SMP bug ? PANIC in __d_find_alias
Date: Wed, 12 Dec 2007 20:36:40 +0100
From: Rafael J. Wysocki [EMAIL PROTECTED]
To: Mitch [EMAIL PROTECTED]
CC: linux-kernel@vger.kernel.org, [EMAIL
Subject: ext3_ordered_writepage panic on shiny new 2.6.22
Date: Sat, 14 Jul 2007 18:18:14 +0400
From: Mitch <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org
Hi
Light load on my system and encoding a home video to the disk using
mencoder and i get this...
BUG: unable to handle kernel NULL pointer
panic on shiny new 2.6.22
Date: Sat, 14 Jul 2007 18:18:14 +0400
From: Mitch [EMAIL PROTECTED]
To: linux-kernel@vger.kernel.org
Hi
Light load on my system and encoding a home video to the disk using
mencoder and i get this...
BUG: unable to handle kernel NULL pointer dereference at virtual
Hi
Light load on my system and encoding a home video to the disk using
mencoder and i get this...
BUG: unable to handle kernel NULL pointer dereference at virtual address
0004
printing eip:
c01a478e
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: nls_iso8859_1 nls_cp437
Hi
Light load on my system and encoding a home video to the disk using
mencoder and i get this...
BUG: unable to handle kernel NULL pointer dereference at virtual address
0004
printing eip:
c01a478e
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: nls_iso8859_1 nls_cp437
tp://bugzilla.kernel.org/show_bug.cgi?id=7988
And if you haven't already (and your problem occurs with a stock
kernel), you might want to log this as a bug like I did.
Hope this helps.
Mitch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
(and your problem occurs with a stock
kernel), you might want to log this as a bug like I did.
Hope this helps.
Mitch.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Acked-by: Mitch Williams <[EMAIL PROTECTED]>
>This is a simplified and actually more comprehensive form of a bug
>fix from Mitch Williams <[EMAIL PROTECTED]>.
[snip]
>Then if people do have a kernel message stating "No irq for vector" we
>will know it is
Acked-by: Mitch Williams [EMAIL PROTECTED]
This is a simplified and actually more comprehensive form of a bug
fix from Mitch Williams [EMAIL PROTECTED].
[snip]
Then if people do have a kernel message stating No irq for vector we
will know it is yet another novel cause that needs a complete new
related to "no vector for IRQ" in the
wild, then I have to change my stance and agree that this should be
pushed to -stable. Every one of those messages indicates that we
hit the race condition.
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
Greg KH wrote:
>
>> Perhaps we should put this into 2.6.22 then backport it to
>2.6.21.x once it
>> seems safe to do so. If we decide to go this way, we'll
>need to ask Mitch
>> to remind us to do the backport at the appropriate time,
>else we'll surely
>>
flushes are required in the various affinity setting
routines.
This patch has been validated with (unreleased) network hardware which
uses MSI-X.
Revised with input from Eric Biederman.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.20.4-clean/drive
On Fri, 2007-03-30 at 11:56 -0700, Mitch Williams wrote:
> This patch fixes a kernel bug which is triggered when using the
> irqbalance daemon with MSI-X hardware.
>
Grrr. Evolution cut-n-sometimes-paste feature bit me. Will resend with
a proper subject line.
-Mitch
-
To unsubsc
flushes are required in the various affinity setting
routines.
This patch has been validated with (unreleased) network hardware which
uses MSI-X.
Revised with input from Eric Biederman.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.21-rc5-clean/drive
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Because both MSI-X interrupt messages and MSI-X table writes are posted,
it's possible for them to cross while in-flight. This results in
interrupts being received long after the kernel thinks
flushes are required in the various affinity setting
routines.
This patch has been validated with (unreleased) network hardware which
uses MSI-X.
Revised with input from Eric Biederman.
Signed-off-by: Mitch Williams [EMAIL PROTECTED]
diff -urpN -X dontdiff linux-2.6.21-rc5-clean/drivers/pci
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Because both MSI-X interrupt messages and MSI-X table writes are posted,
it's possible for them to cross while in-flight. This results in
interrupts being received long after the kernel thinks
On Fri, 2007-03-30 at 11:56 -0700, Mitch Williams wrote:
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Grrr. Evolution cut-n-sometimes-paste feature bit me. Will resend with
a proper subject line.
-Mitch
-
To unsubscribe from this list
flushes are required in the various affinity setting
routines.
This patch has been validated with (unreleased) network hardware which
uses MSI-X.
Revised with input from Eric Biederman.
Signed-off-by: Mitch Williams [EMAIL PROTECTED]
diff -urpN -X dontdiff linux-2.6.20.4-clean/drivers/pci/msi.c
Greg KH wrote:
Perhaps we should put this into 2.6.22 then backport it to
2.6.21.x once it
seems safe to do so. If we decide to go this way, we'll
need to ask Mitch
to remind us to do the backport at the appropriate time,
else we'll surely
forget.
Yes, that's what I just asked him
be
pushed to -stable. Every one of those messages indicates that we
hit the race condition.
-Mitch
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
t.
So the answer to your question is, "probably not".
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Eric W. Biederman wrote:
>Do we still need the flush the set affinity routines?
>Shouldn't flush in mask and unmask should now be enough?
Yeah, I think you're right. I've removed that call, and
we're running some basic validation on the change. I'll
post a new patch tomorrow AM.
from Eric Biederman.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.21-rc5-clean/arch/i386/kernel/io_apic.c
linux-2.6.21-rc5/arch/i386/kernel/io_apic.c
--- linux-2.6.21-rc5-clean/arch/i386/kernel/io_apic.c 2007-03-28
10:05:22.0 -0700
+++ linux-
from Eric Biederman.
Signed-off-by: Mitch Williams [EMAIL PROTECTED]
diff -urpN -X dontdiff linux-2.6.21-rc5-clean/arch/i386/kernel/io_apic.c
linux-2.6.21-rc5/arch/i386/kernel/io_apic.c
--- linux-2.6.21-rc5-clean/arch/i386/kernel/io_apic.c 2007-03-28
10:05:22.0 -0700
+++ linux-2.6.21-rc5
Eric W. Biederman wrote:
Do we still need the flush the set affinity routines?
Shouldn't flush in mask and unmask should now be enough?
Yeah, I think you're right. I've removed that call, and
we're running some basic validation on the change. I'll
post a new patch tomorrow AM.
-Mitch
the answer to your question is, probably not.
-Mitch
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
gt;MSI is disabled before we unregister it, we don't know of any
>MSI implementation problems that will result in a screaming IRQ.
>I would say set enable/disable to the mask/unmask methods.
>
OK, that's easy. I'll whip up a patch today, test it overnight,
and post it tomorrow.
Thanks f
we unregister it, we don't know of any
MSI implementation problems that will result in a screaming IRQ.
I would say set enable/disable to the mask/unmask methods.
OK, that's easy. I'll whip up a patch today, test it overnight,
and post it tomorrow.
Thanks for looking at this.
-Mitch
Eric W. Biederman wrote:
>> However the mask function is called at EVERY interrupt,
>> so this change would be VERY expensive.
>
>If true I think that would be bad. However I don't see it.
>Where in handle_edge_irq do we mask the interrupt?
>The only place I see us calling ->mask is from
be VERY expensive.
If the driver really needs to disable the interrupt, then it can call
irq_disable(). Otherwise, mask (as-is) should be fine -- it masks
the interrupt at the APIC, and the device's interrupt moderation
should take care of keeping it from generating interrupts right away.
-Mitch
-
1 - 100 of 166 matches
Mail list logo
