On Fri, Jan 29, 2021 at 03:20:32PM -0600, Bjorn Helgaas wrote:
> > For comparison the intel iwlwifi driver is very clear about firmware
> > it's trying to load, if it can't and what exact firmware you need to
> > find on the internet (filename)
>
> I guess you're referring to this in
On Wed, Jan 27, 2021 at 03:33:00PM -0600, Bjorn Helgaas wrote:
> Hi Marc, I appreciate your persistence on this. I am frankly
> surprised that you've put up with this so long.
Well, been using linux for 27 years, but also it's not like I have much
of a choice outside of switching to windows, as
On Sat, Dec 26, 2020 at 03:12:09AM -0800, Ilia Mirkin wrote:
> > after boot, when it gets the right trigger (not sure which ones), it
> > loops on this evern 2 seconds, mostly forever.
>
> The gpu suspends with runtime pm. And then gets woken up for some
> reason (could be something quite silly,
This started with 5.5 and hasn't gotten better since then, despite some reports
I tried to send.
As per my previous message:
I have a Thinkpad P70 with hybrid graphics.
01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M600M]
(rev a2)
that one works fine, I can use i915 for
On Mon, Sep 07, 2020 at 05:29:35PM -0700, Marc MERLIN wrote:
> On Tue, Sep 08, 2020 at 01:51:19AM +0200, Karol Herbst wrote:
> > oh, I somehow missed that "disp ctor failed" message. I think that
> > might explain why things are a bit hanging. From the top of my head I
On Tue, Sep 08, 2020 at 01:51:19AM +0200, Karol Herbst wrote:
> oh, I somehow missed that "disp ctor failed" message. I think that
> might explain why things are a bit hanging. From the top of my head I
> am not sure if that's something known or something new. But just in
> case I CCed Lyude and
On Mon, Sep 07, 2020 at 09:14:03PM +0200, Karol Herbst wrote:
> > - changes in the nouveau driver. Mika told me the PCIe regression
> > "pcieport :00:01.0: PME: Spurious native interrupt!" is supposed
> > to be fixed in 5.8, but I still get a 4mn hang or so during boot and
> > with 5.8,
rInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
[6.726086] pci_bus :04: dev 00, created physical slot 0
Any idea what's going on?
Thanks,
Marc
On Sat, Aug 08, 2020 at 01:22:02PM -0700, Marc MERLIN wrote:
> On Fri, Oct 04, 2019 at 03:39:46PM +0300, Mika
On Sat, Aug 08, 2020 at 01:22:02PM -0700, Marc MERLIN wrote:
> Basically, I'm getting the same thing than this person with a P53 (which
> is a mostly identical lenovo thinkpad, to mine)
> kernel: pcieport :00:01.0: PME: Spurious native interrupt!
> kernel: pcieport :00:01.0: P
I forgot to add that my mostly hanging boots look like this:
https://photos.app.goo.gl/HJvTraYYZbiNTNE39
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Home page: http://marc.merlins.org/
On Fri, Oct 04, 2019 at 03:39:46PM +0300, Mika Westerberg wrote:
> This is otherwise similar to pcie_wait_for_link() but allows passing
> custom activation delay in milliseconds.
>
> Signed-off-by: Mika Westerberg
> ---
> drivers/pci/pci.c | 21 ++---
> 1 file changed, 18
fer to ignore, even if the duplicate
situation isn't safe per se.
What do you think?
Thanks,
Marc
> Mike
>
> On Tue, Mar 13, 2018 at 9:19 AM, Marc MERLIN <m...@merlins.org> wrote:
> > On Tue, Mar 13, 2018 at 04:24:58PM +0100, Greg Kroah-Hartman wrote:
> >> 4.14-s
fer to ignore, even if the duplicate
situation isn't safe per se.
What do you think?
Thanks,
Marc
> Mike
>
> On Tue, Mar 13, 2018 at 9:19 AM, Marc MERLIN wrote:
> > On Tue, Mar 13, 2018 at 04:24:58PM +0100, Greg Kroah-Hartman wrote:
> >> 4.14-stable review patch.
che(), after failure
> on calling register_cache_set(), bch_cache_release() will be called, then
> bdev will be freed, so bdevname(bdev, name) caused kernel crash.
>
> Since bch_cache_release() will free bdev, so in this patch we make sure
> bdev being freed if register_cache()
calling register_cache_set(), bch_cache_release() will be called, then
> bdev will be freed, so bdevname(bdev, name) caused kernel crash.
>
> Since bch_cache_release() will free bdev, so in this patch we make sure
> bdev being freed if register_cache() fail, and do not free bdev
at 11:17:39AM -0800, Marc MERLIN wrote:
> [+linux-efi and fixed Matthew's Email]
>
> As an update, I got my NVME drive to boot once at least, it seem that I need
> to wait about 2mn for the bios to do whatever, hang, recover and then
> finally continue booting.
> If I take ove
at 11:17:39AM -0800, Marc MERLIN wrote:
> [+linux-efi and fixed Matthew's Email]
>
> As an update, I got my NVME drive to boot once at least, it seem that I need
> to wait about 2mn for the bios to do whatever, hang, recover and then
> finally continue booting.
> If I take ove
is writing to pstore and
kill that job given that deleting from pstore seems not possible on my
machine, and filling it up causes the bios to get upset.
Marc
On Thu, Mar 01, 2018 at 10:22:39PM -0800, Marc MERLIN wrote:
> Howdy,
>
> I have a thinkpad P70 which started to fail resuming from
is writing to pstore and
kill that job given that deleting from pstore seems not possible on my
machine, and filling it up causes the bios to get upset.
Marc
On Thu, Mar 01, 2018 at 10:22:39PM -0800, Marc MERLIN wrote:
> Howdy,
>
> I have a thinkpad P70 which started to fail resuming from
Howdy,
I have a thinkpad P70 which started to fail resuming from S3 sleep after any
kernel past 4.12 (sometimes it would work, sometimes the HD led would come
on when trying to resume, but nothing else).
After much debugging trying to figure what was causing it and coming short,
I decided to
Howdy,
I have a thinkpad P70 which started to fail resuming from S3 sleep after any
kernel past 4.12 (sometimes it would work, sometimes the HD led would come
on when trying to resume, but nothing else).
After much debugging trying to figure what was causing it and coming short,
I decided to
On Tue, May 02, 2017 at 09:44:33AM +0200, Michal Hocko wrote:
> On Mon 01-05-17 21:12:35, Marc MERLIN wrote:
> > Howdy,
> >
> > Well, sadly, the problem is more or less back is 4.11.0. The system doesn't
> > really
> > crash but it goes into an infinite
On Tue, May 02, 2017 at 09:44:33AM +0200, Michal Hocko wrote:
> On Mon 01-05-17 21:12:35, Marc MERLIN wrote:
> > Howdy,
> >
> > Well, sadly, the problem is more or less back is 4.11.0. The system doesn't
> > really
> > crash but it goes into an infinite
that btrfs on top of dmcrypt on top of bcache may
have been enough layers to hang on btrfs check on 4.8 too, but I can't
really go back to check right now due to the driver corruption issues.
Any idea what I should do next?
Thanks,
Marc
On Tue, Nov 29, 2016 at 03:01:35PM -0800, Marc MERLIN wrote
that btrfs on top of dmcrypt on top of bcache may
have been enough layers to hang on btrfs check on 4.8 too, but I can't
really go back to check right now due to the driver corruption issues.
Any idea what I should do next?
Thanks,
Marc
On Tue, Nov 29, 2016 at 03:01:35PM -0800, Marc MERLIN wrote
ing of objtool occur in all cases,
> by moving the CONFIG_STACK_VALIDATION checks outside the 'ifeq
> ($(KBUILD_EXTMOD),)' block in the Makefile.
>
> Reported-by: Marc MERLIN <m...@merlins.org>
> Suggested-by: Jessica Yu <j...@redhat.com>
> Fixes: 3b27a0c85d70
ing of objtool occur in all cases,
> by moving the CONFIG_STACK_VALIDATION checks outside the 'ifeq
> ($(KBUILD_EXTMOD),)' block in the Makefile.
>
> Reported-by: Marc MERLIN
> Suggested-by: Jessica Yu
> Fixes: 3b27a0c85d70 ("objtool: Detect and warn if libelf is missing an
On Mon, Feb 13, 2017 at 04:00:02PM -0600, Josh Poimboeuf wrote:
> On Mon, Feb 13, 2017 at 01:31:32PM -0800, Marc MERLIN wrote:
> > Anyway, after not finding it in xconfig, I editted .config, and did:
> > # CONFIG_STACK_VALIDATION is not set
> > save .config
> > an
On Mon, Feb 13, 2017 at 04:00:02PM -0600, Josh Poimboeuf wrote:
> On Mon, Feb 13, 2017 at 01:31:32PM -0800, Marc MERLIN wrote:
> > Anyway, after not finding it in xconfig, I editted .config, and did:
> > # CONFIG_STACK_VALIDATION is not set
> > save .config
> > an
On Mon, Feb 13, 2017 at 12:41:06PM -0600, Josh Poimboeuf wrote:
> Hm, that doesn't sound right. Nothing automatically enables
> CONFIG_STACK_VALIDATION. It should be disabled unless manually enabled.
> Maybe you got it confused with CONFIG_HAVE_STACK_VALIDATION, which is
> always enabled?
I
On Mon, Feb 13, 2017 at 12:41:06PM -0600, Josh Poimboeuf wrote:
> Hm, that doesn't sound right. Nothing automatically enables
> CONFIG_STACK_VALIDATION. It should be disabled unless manually enabled.
> Maybe you got it confused with CONFIG_HAVE_STACK_VALIDATION, which is
> always enabled?
I
Hi Josh,
I'll start with the story as to why.
i've lost more hours than I care to list, because I was unable to build
the virtualbox kernel driver with newer kernels.
Sadly, it gives no useful debug info outside of
make[1]: *** No rule to make target '/tmp/vbox.0/linux/SUPDrv-linux.o', needed
by
Hi Josh,
I'll start with the story as to why.
i've lost more hours than I care to list, because I was unable to build
the virtualbox kernel driver with newer kernels.
Sadly, it gives no useful debug info outside of
make[1]: *** No rule to make target '/tmp/vbox.0/linux/SUPDrv-linux.o', needed
by
On Wed, Nov 30, 2016 at 10:14:50AM -0800, Linus Torvalds wrote:
> Anyway, none of this seems new per se. I'm adding Kent and Jens to the
> cc (Tejun already was), in the hope that maybe they have some idea how
> to control the nasty worst-case behavior wrt workqueue lockup (it's
> not really a
On Wed, Nov 30, 2016 at 10:14:50AM -0800, Linus Torvalds wrote:
> Anyway, none of this seems new per se. I'm adding Kent and Jens to the
> cc (Tejun already was), in the hope that maybe they have some idea how
> to control the nasty worst-case behavior wrt workqueue lockup (it's
> not really a
On Tue, Nov 29, 2016 at 10:01:10AM -0800, Linus Torvalds wrote:
> On Tue, Nov 29, 2016 at 9:40 AM, Marc MERLIN <m...@merlins.org> wrote:
> >
> > In my case, it is a 5x 4TB HDD with
> > software raid 5 < bcache < dmcrypt < btrfs
>
> It doesn't s
On Tue, Nov 29, 2016 at 10:01:10AM -0800, Linus Torvalds wrote:
> On Tue, Nov 29, 2016 at 9:40 AM, Marc MERLIN wrote:
> >
> > In my case, it is a 5x 4TB HDD with
> > software raid 5 < bcache < dmcrypt < btrfs
>
> It doesn't sound like the nasty situations I
On Tue, Nov 29, 2016 at 09:40:19AM -0800, Marc MERLIN wrote:
> Thanks for the reply and suggestions.
>
> On Tue, Nov 29, 2016 at 09:07:03AM -0800, Linus Torvalds wrote:
> > On Tue, Nov 29, 2016 at 8:34 AM, Marc MERLIN <m...@merlins.org> wrote:
> > > Now, to be f
On Tue, Nov 29, 2016 at 09:40:19AM -0800, Marc MERLIN wrote:
> Thanks for the reply and suggestions.
>
> On Tue, Nov 29, 2016 at 09:07:03AM -0800, Linus Torvalds wrote:
> > On Tue, Nov 29, 2016 at 8:34 AM, Marc MERLIN wrote:
> > > Now, to be fair, this is not a new pr
Thanks for the reply and suggestions.
On Tue, Nov 29, 2016 at 09:07:03AM -0800, Linus Torvalds wrote:
> On Tue, Nov 29, 2016 at 8:34 AM, Marc MERLIN <m...@merlins.org> wrote:
> > Now, to be fair, this is not a new problem, it's just varying degrees of
> > bad and usually o
Thanks for the reply and suggestions.
On Tue, Nov 29, 2016 at 09:07:03AM -0800, Linus Torvalds wrote:
> On Tue, Nov 29, 2016 at 8:34 AM, Marc MERLIN wrote:
> > Now, to be fair, this is not a new problem, it's just varying degrees of
> > bad and usually only happens when I
On Tue, Nov 29, 2016 at 05:07:51PM +0100, Michal Hocko wrote:
> On Tue 29-11-16 07:55:37, Marc MERLIN wrote:
> > On Mon, Nov 28, 2016 at 08:23:15AM +0100, Michal Hocko wrote:
> > > Marc, could you try this patch please? I think it should be pretty clear
> > > it
On Tue, Nov 29, 2016 at 05:07:51PM +0100, Michal Hocko wrote:
> On Tue 29-11-16 07:55:37, Marc MERLIN wrote:
> > On Mon, Nov 28, 2016 at 08:23:15AM +0100, Michal Hocko wrote:
> > > Marc, could you try this patch please? I think it should be pretty clear
> > > it
ut that would be too intrusive to backport
> > to 4.8 stable kernels. Instead this patch simply never declares OOM for
> > !costly high order requests. We rely on order-0 requests to do that in
> > case we are really out of memory. Order-0 requests are much more common
>
to backport
> > to 4.8 stable kernels. Instead this patch simply never declares OOM for
> > !costly high order requests. We rely on order-0 requests to do that in
> > case we are really out of memory. Order-0 requests are much more common
> > and so a risk
On Mon, Nov 28, 2016 at 08:23:15AM +0100, Michal Hocko wrote:
> Marc, could you try this patch please? I think it should be pretty clear
> it should help you but running it through your use case would be more
> than welcome before I ask Greg to take this to the 4.8 stable tree.
I ran it overnight
On Mon, Nov 28, 2016 at 08:23:15AM +0100, Michal Hocko wrote:
> Marc, could you try this patch please? I think it should be pretty clear
> it should help you but running it through your use case would be more
> than welcome before I ask Greg to take this to the 4.8 stable tree.
I ran it overnight
On Mon, Nov 28, 2016 at 08:23:15AM +0100, Michal Hocko wrote:
> Marc, could you try this patch please? I think it should be pretty clear
> it should help you but running it through your use case would be more
> than welcome before I ask Greg to take this to the 4.8 stable tree.
This will take a
On Mon, Nov 28, 2016 at 08:23:15AM +0100, Michal Hocko wrote:
> Marc, could you try this patch please? I think it should be pretty clear
> it should help you but running it through your use case would be more
> than welcome before I ask Greg to take this to the 4.8 stable tree.
This will take a
On Tue, Nov 22, 2016 at 05:25:44PM +0100, Michal Hocko wrote:
> currently AFAIR. I hate that Marc is not falling into that category but
> is it really problem for you to run with 4.9? If we have more users
Don't do anything just on my account. I had a problem, it's been fixed
in 2 different ways:
On Tue, Nov 22, 2016 at 05:25:44PM +0100, Michal Hocko wrote:
> currently AFAIR. I hate that Marc is not falling into that category but
> is it really problem for you to run with 4.9? If we have more users
Don't do anything just on my account. I had a problem, it's been fixed
in 2 different ways:
On Mon, Nov 21, 2016 at 01:56:39PM -0800, Marc MERLIN wrote:
> On Mon, Nov 21, 2016 at 10:50:20PM +0100, Vlastimil Babka wrote:
> > > 4.9rc5 however seems to be doing better, and is still running after 18
> > > hours. However, I got a few page allocation failures as per below,
On Mon, Nov 21, 2016 at 01:56:39PM -0800, Marc MERLIN wrote:
> On Mon, Nov 21, 2016 at 10:50:20PM +0100, Vlastimil Babka wrote:
> > > 4.9rc5 however seems to be doing better, and is still running after 18
> > > hours. However, I got a few page allocation failures as per below,
On Mon, Nov 21, 2016 at 10:50:20PM +0100, Vlastimil Babka wrote:
> > 4.9rc5 however seems to be doing better, and is still running after 18
> > hours. However, I got a few page allocation failures as per below, but the
> > system seems to recover.
> > Vlastimil, do you want me to continue the copy
On Mon, Nov 21, 2016 at 10:50:20PM +0100, Vlastimil Babka wrote:
> > 4.9rc5 however seems to be doing better, and is still running after 18
> > hours. However, I got a few page allocation failures as per below, but the
> > system seems to recover.
> > Vlastimil, do you want me to continue the copy
I've been stuck on 4.4.x for a while (currently 4.4.5) because any
subsequent kernel would fail to suspend or resume (S3 sleep) on my
Thinkpad P70.
Due to lack of time, I only got around to doing a git bisect now
(sorry), and did it between 4.4.0 and 4.5.0
It's my first bisect, but I hope I did
I've been stuck on 4.4.x for a while (currently 4.4.5) because any
subsequent kernel would fail to suspend or resume (S3 sleep) on my
Thinkpad P70.
Due to lack of time, I only got around to doing a git bisect now
(sorry), and did it between 4.4.0 and 4.5.0
It's my first bisect, but I hope I did
On Thu, Mar 10, 2016 at 09:13:13PM -0800, Marc MERLIN wrote:
> On Fri, Mar 11, 2016 at 04:35:21AM +, Eric Wheeler wrote:
> > Hello all,
> >
> > We were having a discussion on the bcache list about the safest reboot
> > options via sysrq here:
&g
On Thu, Mar 10, 2016 at 09:13:13PM -0800, Marc MERLIN wrote:
> On Fri, Mar 11, 2016 at 04:35:21AM +, Eric Wheeler wrote:
> > Hello all,
> >
> > We were having a discussion on the bcache list about the safest reboot
> > options via sysrq here:
&g
On Fri, Mar 11, 2016 at 04:35:21AM +, Eric Wheeler wrote:
> Hello all,
>
> We were having a discussion on the bcache list about the safest reboot
> options via sysrq here:
> http://thread.gmane.org/gmane.linux.kernel.bcache.devel/3559/focus=3586
>
> The result of the discussion ended up
On Fri, Mar 11, 2016 at 04:35:21AM +, Eric Wheeler wrote:
> Hello all,
>
> We were having a discussion on the bcache list about the safest reboot
> options via sysrq here:
> http://thread.gmane.org/gmane.linux.kernel.bcache.devel/3559/focus=3586
>
> The result of the discussion ended up
Would you be able to modify the driver to avoid these low memory problems?
Thanks,
Marc
- Forwarded message from Marc MERLIN -
From: Marc MERLIN
To: linux-bt...@vger.kernel.org
My server died last night during a btrfs send/receive to a btrfs radi5 array
Here
Would you be able to modify the driver to avoid these low memory problems?
Thanks,
Marc
- Forwarded message from Marc MERLIN m...@merlins.org -
From: Marc MERLIN m...@merlins.org
To: linux-bt...@vger.kernel.org
My server died last night during a btrfs send
On Sat, Mar 30, 2013 at 06:56:28PM +0100, Pavel Machek wrote:
> Sometimes it works, sometimes it does not. Don't blame lenovo for
> that.
>
> Maybe it should be modified to take sysrq and _then_ key?
>
> Or maybe we should use something like lshift+rshift+lalt+ralt+key?
It can't hurt to add
On Sat, Mar 30, 2013 at 06:56:28PM +0100, Pavel Machek wrote:
Sometimes it works, sometimes it does not. Don't blame lenovo for
that.
Maybe it should be modified to take sysrq and _then_ key?
Or maybe we should use something like lshift+rshift+lalt+ralt+key?
It can't hurt to add
On Wed, Jan 09, 2013 at 03:36:44AM +0100, Roland Eggner wrote:
> On 2013-01-08 Tuesday at 15:09 -0800 Marc MERLIN wrote:
> > In its infinite wisdom, lenovo has removed the sysrq key on the latest
> > thinkpads, and replaced it with a stupid ALT+FN+S key combination, which
> >
On Wed, Jan 09, 2013 at 03:36:44AM +0100, Roland Eggner wrote:
On 2013-01-08 Tuesday at 15:09 -0800 Marc MERLIN wrote:
In its infinite wisdom, lenovo has removed the sysrq key on the latest
thinkpads, and replaced it with a stupid ALT+FN+S key combination, which
doesn't really work
On Tue, Feb 26, 2013 at 08:50:04AM -0800, Marc MERLIN wrote:
> On Tue, Feb 26, 2013 at 10:29:59AM -0500, Jeff Garzik wrote:
> > On 02/25/2013 07:27 PM, Marc MERLIN wrote:
> > >Howdy,
> > >
> > >I seem to have the same problem (or similar) as Mathieu Desnoyers
On Tue, Feb 26, 2013 at 08:50:04AM -0800, Marc MERLIN wrote:
On Tue, Feb 26, 2013 at 10:29:59AM -0500, Jeff Garzik wrote:
On 02/25/2013 07:27 PM, Marc MERLIN wrote:
Howdy,
I seem to have the same problem (or similar) as Mathieu Desnoyers in
https://lkml.org/lkml/2013/2/22/437
I
On Tue, Feb 26, 2013 at 10:29:59AM -0500, Jeff Garzik wrote:
> On 02/25/2013 07:27 PM, Marc MERLIN wrote:
> >Howdy,
> >
> >I seem to have the same problem (or similar) as Mathieu Desnoyers in
> >https://lkml.org/lkml/2013/2/22/437
> >
> >I can reliably get
On Tue, Feb 26, 2013 at 10:29:59AM -0500, Jeff Garzik wrote:
On 02/25/2013 07:27 PM, Marc MERLIN wrote:
Howdy,
I seem to have the same problem (or similar) as Mathieu Desnoyers in
https://lkml.org/lkml/2013/2/22/437
I can reliably get my SSD to drop from the SATA bus given the right
message from Marc MERLIN -
From: Marc MERLIN
To: linux-...@vger.kernel.org
Hopefully this is the right list. I know that IDE!=SATA, but I can't find
a SATA list.
Please redirect me if needed.
Hardware:
Lenovo T530, 64bit kernel and userland.
Hadware is shown below, but 2 drives, one SSD (OCZ
message from Marc MERLIN m...@merlins.org -
From: Marc MERLIN m...@merlins.org
To: linux-...@vger.kernel.org
Hopefully this is the right list. I know that IDE!=SATA, but I can't find
a SATA list.
Please redirect me if needed.
Hardware:
Lenovo T530, 64bit kernel and userland.
Hadware is shown below
On Wed, Jan 09, 2013 at 03:36:44AM +0100, Roland Eggner wrote:
> On 2013-01-08 Tuesday at 15:09 -0800 Marc MERLIN wrote:
> > In its infinite wisdom, lenovo has removed the sysrq key on the latest
> > thinkpads, and replaced it with a stupid ALT+FN+S key combination, which
> >
In its infinite wisdom, lenovo has removed the sysrq key on the latest
thinkpads, and replaced it with a stupid ALT+FN+S key combination, which
doesn't really work for doing sysrq from the console (nor do I know how the
genius who did that intended for SYSRQ-S to work).
In its infinite wisdom, lenovo has removed the sysrq key on the latest
thinkpads, and replaced it with a stupid ALT+FN+S key combination, which
doesn't really work for doing sysrq from the console (nor do I know how the
genius who did that intended for SYSRQ-S to work).
On Wed, Jan 09, 2013 at 03:36:44AM +0100, Roland Eggner wrote:
On 2013-01-08 Tuesday at 15:09 -0800 Marc MERLIN wrote:
In its infinite wisdom, lenovo has removed the sysrq key on the latest
thinkpads, and replaced it with a stupid ALT+FN+S key combination, which
doesn't really work
On Thu, Jan 03, 2013 at 08:12:18AM +0100, Romain Francoise wrote:
> Marc MERLIN writes:
>
> > I had pretty repeated crashes when plugging power back into my running
> > laptop, but the display just freezes and I can't get a dump.
>
> > For the crash here, I did: susp
On Thu, Jan 03, 2013 at 08:12:18AM +0100, Romain Francoise wrote:
Marc MERLIN m...@merlins.org writes:
I had pretty repeated crashes when plugging power back into my running
laptop, but the display just freezes and I can't get a dump.
For the crash here, I did: suspend to RAM, plug
On Wed, Jan 02, 2013 at 02:27:57PM -0800, Marc MERLIN wrote:
> Google only shows hits pointing to an ext4 patch that didn't go in 3.7
> proper.
>
> http://marc.merlins.org/tmp/crash.jpg
Grumble, I kind of forgot to add the link to my .config, sorry about
that:
http://marc.merlins.org
Google only shows hits pointing to an ext4 patch that didn't go in 3.7
proper.
http://marc.merlins.org/tmp/crash.jpg
My call trace doesn't look copmlete, but shows "fatal exception in interrupt"
and:
timerqueue_del
__remove_hrtimer
__run_htrimer
hrtimer_interruypt
smp_apic_timer_interrupt
Google only shows hits pointing to an ext4 patch that didn't go in 3.7
proper.
http://marc.merlins.org/tmp/crash.jpg
My call trace doesn't look copmlete, but shows fatal exception in interrupt
and:
timerqueue_del
__remove_hrtimer
__run_htrimer
hrtimer_interruypt
smp_apic_timer_interrupt
???
On Wed, Jan 02, 2013 at 02:27:57PM -0800, Marc MERLIN wrote:
Google only shows hits pointing to an ext4 patch that didn't go in 3.7
proper.
http://marc.merlins.org/tmp/crash.jpg
Grumble, I kind of forgot to add the link to my .config, sorry about
that:
http://marc.merlins.org/tmp/.config
ing if this is due to a recent change, but I'm having trouble
> > working out where the allocation call site is.
> > --
>
> (Adding Marc Merlin to CC, since he reported same problem)
>
> Thats the firmware loading in iwlwifi driver. Not sure if it can use SG.
>
>
having trouble
working out where the allocation call site is.
--
(Adding Marc Merlin to CC, since he reported same problem)
Thats the firmware loading in iwlwifi driver. Not sure if it can use SG.
drivers/net/wireless/iwlwifi/iwl-drv.c
iwl_alloc_ucode() - iwl_alloc_fw_desc
On Sat, Sep 23, 2000 at 02:02:24PM +, Julian Anastasov wrote:
> > I didn't receive any negative comments, except for Alexey who believed the
> > check should be done in user space.
>
> Now you receive another negative comment, for the 2.2 version :)
Thanks for the feedback, it is
On Fri, Sep 22, 2000 at 01:25:54AM -0700, David S. Miller wrote:
> You've made the foo-address to ascii string routines non-reentrant.
> The hbuffer[] was on the local stack for a very good reason.
You are right, fixed.
http://marc.merlins.org/linux/arppatch/arp-patch-2.4_v1.3
(that part of the
On Fri, Sep 22, 2000 at 01:25:54AM -0700, David S. Miller wrote:
You've made the foo-address to ascii string routines non-reentrant.
The hbuffer[] was on the local stack for a very good reason.
You are right, fixed.
http://marc.merlins.org/linux/arppatch/arp-patch-2.4_v1.3
(that part of the
On Fri, Sep 22, 2000 at 01:31:06AM +0200, Andi Kleen wrote:
> You added a linear IP search to fast path ARP processing. The people running
> thousands of IP aliases will surely love you. You could at least use the
> ip_route_input output instead that arp_rcv computes anyways and check
> for
17 19:19:49 =
2000
@@ -65,6 +65,8 @@
* clean up the APFDDI & gen. FDDI bits.
* Alexey Kuznetsov: new arp state machine;
* now it is in net/core/neighbour.c.
+ * Marc Merlin : A
17 19:19:49 =
2000
@@ -65,6 +65,8 @@
* clean up the APFDDI gen. FDDI bits.
* Alexey Kuznetsov: new arp state machine;
* now it is in net/core/neighbour.c.
+ * Marc Merlin : Added
On Fri, Sep 22, 2000 at 01:31:06AM +0200, Andi Kleen wrote:
You added a linear IP search to fast path ARP processing. The people running
thousands of IP aliases will surely love you. You could at least use the
ip_route_input output instead that arp_rcv computes anyways and check
for
92 matches
Mail list logo
