6:33 a.m.
Hello,
I get the following message repeatedly from syslogd, after a wakeup from
hibernate:
kernel:do_IRQ: 0.81 No irq handler for vector (irq -1)
I am running kernel 3.6.3-200 on a fully updated F20.
Any suggestions as to how to diagnose and fix the issue?
Thanks,
Ranjan
--
Important Notice: This mailbox is ignored: e-mails are set to be
deleted on receipt. Please respond to the mailing list if appropriate.
For those needing to send personal or professional e-mail, please use
appropriate addresses.
____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth
5:32 p.m.
Thanks again!
On Mon, 6 Oct 2014 23:15:56 +0200 Heinz Diehl <htd+ml(a)fritha.org> wrote:
> http://ur1.ca/iawmi ->
http://paste.fedoraproject.org/139547/00617141
Reading your dmesg dump, I'm not convinced that the irq handler is
what causes you problems. Some years ago, the code was modified that
the missing interrupt was ACKed, thus letting the machine proceed.
I see. Thanks!
However, you have a seriously segfaulting browser (firefox?) which
corrupts the memory. The general protection fault could even be caused
by a null pointer dereference. I guess that's the problem.
I am using firefox from the F20 repos. Is there a bug in firefox, or is it somewhere else?
In addition, are you at F22? Your dmesg says you're using a
3.17.0-0.rc7.git2.1.fc22.x86_64 kernel. When compiling a kernel source
rpm meant for F22 on a F20 system, the package would be tagged fc20.
I was using the kernel from rawhide which is why it is tagged F22: I did not yet compile
it myself. I guess I should try this next. The Fedora vanilla kernel repos do not have the
latest 3.17 kernel yet.
Many thanks again!
Ranjan
____________________________________________________________
Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/password-manager
4:15 p.m.
On 06.10.2014, Ranjan Maitra wrote:
What is the difference between the Fedora vanilla kernels
(as described in https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories)
and the kernel on kernel.org, would you happen to know?
As far as I can see from the description, these are the unmodified
original kernels from kernel.org.
Btw, maybe my bug reports did not address the correct component
(kernel) but they have not
been assigned yet. (Should I file under irqbalance?)
No. Most probably, it's a kernel bug. It could be a bug somewhere else
which triggers this one. Historically, such bugs didn't occur when
irqbalance was disabled, but this does not automatically mean that
it's irqbalance itself which is buggy.
Reading your dmesg dump, I'm not convinced that the irq handler is
what causes you problems. Some years ago, the code was modified that
the missing interrupt was ACKed, thus letting the machine proceed.
However, you have a seriously segfaulting browser (firefox?) which
corrupts the memory. The general protection fault could even be caused
by a null pointer dereference. I guess that's the problem.
In addition, are you at F22? Your dmesg says you're using a
3.17.0-0.rc7.git2.1.fc22.x86_64 kernel. When compiling a kernel source
rpm meant for F22 on a F20 system, the package would be tagged fc20.
8:13 a.m.
On Mon, 6 Oct 2014 14:35:36 +0200 Heinz Diehl <htd+ml(a)fritha.org> wrote:
On 04.10.2014, Ranjan Maitra wrote:
> Anecdotally also, it appears to be true. Without the resume = UUID
> stuff, it does not wake up from hibernate but goes on to reboot.
I tried both with and without the resume device in grub.conf, and my
system showd identical behaviour: it went into hibernation, and after
pressing the start button, it began to boot and finally loaded the
image from the disk. It has always been this way for me. Just curious,
since I have little experience with hibernation: is there something
which should have happened instead?
Thank you for your e-mail! For me, since Fedora 20, it has been the case (for all Fedora
aptops that I have -- four) that hibernate does not resume without the workaround
mentioned in that thread. It goes back and boots. The
"problem"/"feature" only arose since Fedora 20 -- no intervention was
needed till Fedora 19. The same is true for Debian-based systems which my wife runs.
Perhaps this is a consequence of using non-vanilla kernels (like Windoze, Debian-based and
now Fedora-based systems appear to now want to tell us what is good for us and not), so
maybe I should try with a vanilla kernel and see.
Anyway, my irqbalance issue has been back. I sent e-mail to the thread yesterday
including my dmesg, my lsmod and lspci -v but it was too long (199KB) and the message is
being held for "moderator approval". It, however, came up for five times with
those messages and the network, but the sixth time, it simply rebooted. I don't have
dmesg for this one.
What is the difference between the Fedora vanilla kernels (as described in
https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories) and the kernel on kernel.org,
would you happen to know?
Many thanks again!
Ranjan
PS: here is the sum of my previous message:
Message from syslogd at Oct 5 08:47:23 ...
kernel:[51883.675020] do_IRQ: 0.81 No irq handler for vector (irq -1)
Message from syslogd at Oct 5 08:47:23 ...
kernel:do_IRQ: 0.81 No irq handler for vector (irq -1)
I am going to look into erasing irqbalance, but I thought that I would
see if anyone had any ideas from the dmesg, lspci and lsmod.
For this one time, the machine seems to work.
Btw, maybe my bug reports did not address the correct component (kernel) but they have
not
been assigned yet. (Should I file under irqbalance?)
Many thanks,
Ranjan
I have put the three outputs up using fpaste.
dmesg:
08:03:02~$ fpaste dmesg.txt
Uploading (270.6KiB)...
http://ur1.ca/iawmi -> http://paste.fedoraproject.org/139547/00617141
$ fpaste lsmod.txt
Uploading (5.8KiB)...
http://ur1.ca/iawn1 -> http://paste.fedoraproject.org/139549/26007721
$ fpaste lspci.txt
Uploading (8.6KiB)...
http://ur1.ca/iawn3 -> http://paste.fedoraproject.org/139550/26008001
____________________________________________________________
Publish your photos in seconds for FREE
TRY IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if4
7:35 a.m.
On 04.10.2014, Ranjan Maitra wrote:
Anecdotally also, it appears to be true. Without the resume = UUID
stuff, it does not wake up from hibernate but goes on to reboot.
I tried both with and without the resume device in grub.conf, and my
system showd identical behaviour: it went into hibernation, and after
pressing the start button, it began to boot and finally loaded the
image from the disk. It has always been this way for me. Just curious,
since I have little experience with hibernation: is there something
which should have happened instead?
12:13 p.m.
On 04.10.2014, Ranjan Maitra wrote:
Does grub not have to be updated also? How does one do that?
No. Your kernel gets installed by "make install". Grub.cfg
will also be updated. After "make install", you're done and ready to
boot your new kernel. No need for further (grub) action.
I see: makes sense! Btw, 3.16.4-rc1 is not available on
www.kernel.org.
https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.16.4-r...
The patches for the stable review are not showed on the kernel.org
main page, they live in the "stable-review" subdirectory as shown
above.
What is the difference between this and 3,17-rc7?
3.17 is the mainline kernel which is under actual development, and
will be the stable kernel once released and updated. Soon after 3.17
is released, the merge window opens, which is the time the developers
are sending new patches to Linus. After 3.18-rc1 is released, the
merge window closes, and usually only bug fixes are accepted then.
Important fixes will be backported to the stable kernel trees, thus the
different minor version number releases.
In short: the actual mainline kernel is the one which is most
up-to-date (3.17 will be released soon..).
What I don't quite understand is that there seem to be no issues
when
the system is rebooted. But issues arise only upon a wakeup from
hibernate. Which I did, as advised in the mailing list here, doing the
following:
[....]
With grub2, an additional "resume" boot parameter is not needed, as
long as your swap partition is properly formatted (mkswap, swapon)
and referred to in fstab when installing your kernel.
10:41 a.m.
Thanks again!
On Sat, 4 Oct 2014 16:51:49 +0200 Heinz Diehl <htd+ml(a)fritha.org> wrote:
In that case, you should download your kernels directly from
kernel.org. It's not a big deal to compile a kernel on your own.
1. Download e.g. the latest mainline kernel from kernel.org
2. Unpack it into /usr/src
3. Copy the latest .config from your actual Fedora kernel (/boot) into
the root of the kernel sourcetree
4. "make oldconfig" (maybe you have to configure some new options here)
5. "make"
6. "make modules_install"
7. "make install"
8. Reboot your new kernel
This kernel lives peacefully alongside your Fedora kernels, and you
can delete the respective files under /boot, the sourcetree and the
modules in /lib/modules/ if you want to remove it. You do not damage
your Fedora kernel installation or the like. It's safe.
Does grub not have to be updated also? How does one do that?
Btw: there hasn't been any update to -stable in nearly 2 weeks,
because the stable maintainer was too busy to push out a new release
during this period. However, 3.16.4-rc1 was released today and
will soon be transferred into 3.16.4.
I see: makes sense! Btw, 3.16.4-rc1 is not available on www.kernel.org.
What is the difference between this and 3,17-rc7?
Btw2: didn't disabling irqbalance workaround the phenomenon?
Sorry, I first decided to do the BIOS upgrade. And since I started
having the network not coming up (consistently now, 100% of the cases)
on a wakeup from hibernate, I did not try out the disabling irqbalance.
(Only once after the BIOS upgrade so far did I get the above mesage.)
What I don't quite understand is that there seem to be no issues when
the system is rebooted. But issues arise only upon a wakeup from
hibernate. Which I did, as advised in the mailing list here, doing the
following:
1. edit /etc/sysconfig/grub
to add: resume=UUID="b7751022-8912-4bb
a-bfb4-f7647b351a21" to the GRUB_CMDLINE_LINUX.
2. run sudo bash -x grub2-mkconfig -o /boot/grub2/grub.cfg
Hopefully, this was correct and I did not miss anything.
Many thanks and best wishes,
Ranjan
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
--
Important Notice: This mailbox is ignored: e-mails are set to be
deleted on receipt. Please respond to the mailing list if appropriate.
For those needing to send personal or professional e-mail, please use
appropriate addresses.
____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop!
Check it out at http://www.inbox.com/marineaquarium
9:51 a.m.
On 04.10.2014, Ranjan Maitra wrote:
How does one do this?
Most probably, a "yum downgrade" will do it. I've never used any
Fedora (or other distro) kernels longer than during the installation,
so I've no experience.
Also, what is the difference between the Fedora and vanilla kernels?
I guess the kernel folks of every distribution add some distribution-related
patches to it which aren't in mainline.
Should I go here to get it?
[....]
In that case, you should download your kernels directly from
kernel.org. It's not a big deal to compile a kernel on your own.
1. Download e.g. the latest mainline kernel from kernel.org
2. Unpack it into /usr/src
3. Copy the latest .config from your actual Fedora kernel (/boot) into
the root of the kernel sourcetree
4. "make oldconfig" (maybe you have to configure some new options here)
5. "make"
6. "make modules_install"
7. "make install"
8. Reboot your new kernel
This kernel lives peacefully alongside your Fedora kernels, and you
can delete the respective files under /boot, the sourcetree and the
modules in /lib/modules/ if you want to remove it. You do not damage
your Fedora kernel installation or the like. It's safe.
If you want to bisect, the steps to compile the cloned kernel sources
are the same as above.
Btw: there hasn't been any update to -stable in nearly 2 weeks,
because the stable maintainer was too busy to push out a new release
during this period. However, 3.16.4-rc1 was released today and
will soon be transferred into 3.16.4.
Btw2: didn't disabling irqbalance workaround the phenomenon?
9:18 a.m.
Thank you again!
On Sat, 4 Oct 2014 09:30:39 +0200 Heinz Diehl <htd+ml(a)fritha.org> wrote:
On 03.10.2014, Ranjan Maitra wrote:
> How does one go down to a 3.15.10 kernel? I could try that and see, I
> guess. Would it also downgrade the headers, etc?
If you install a Fedora kernel: yes.
How does one do this?
$sudo downgrade kernel\* yields:
$ sudo yum downgrade kernel\*
Loaded plugins: langpacks
Package kernel-3.11.10-301.fc20.x86_64 is allowed multiple installs,
skipping Package kernel-debug-3.11.10-301.fc20.x86_64 is allowed
multiple installs, skipping Package
kernel-debug-devel-3.11.10-301.fc20.x86_64 is allowed multiple
installs, skipping Package
kernel-debug-modules-extra-3.11.10-301.fc20.x86_64 is allowed multiple
installs, skipping Package kernel-devel-3.11.10-301.fc20.x86_64 is
allowed multiple installs, skipping Package
kernel-modules-extra-3.11.10-301.fc20.x86_64 is allowed multiple
installs, skipping No Match for available package:
kernel-doc-3.11.10-301.fc20.noarch No Match for available package:
kernel-tools-3.11.10-301.fc20.x86_64 No Match for available package:
kernel-tools-libs-3.11.10-301.fc20.i686 No Match for available package:
kernel-tools-libs-3.11.10-301.fc20.x86_64 No Match for available
package: kernel-tools-libs-devel-3.11.10-301.fc20.i686 No Match for
available package: kernel-tools-libs-devel-3.11.10-301.fc20.x86_64 No
Match for available package: kernelshark-2.2.1-3.fc20.x86_64 Resolving
Dependencies
--> Running transaction check
---> Package kernel-headers.x86_64 0:3.11.10-301.fc20 will be a
downgrade
---> Package kernel-headers.x86_64 0:3.16.3-200.fc20 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version
Repository Size
================================================================================
Downgrading: kernel-headers x86_64
3.11.10-301.fc20 fedora 899 k
Transaction Summary
================================================================================
Downgrade 1 Package
Total download size: 899 k
Is this ok [y/d/N]:
Is this ok?
Also, what is the difference between the Fedora and vanilla kernels?
Should I go here to get it?
https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories
I think: if you're able to reproduce the error easily, you should
try
to bisect the patch which introduced the faulty behaviour. This would
only make sense with a vanilla kernel.
The first step would be to find a kernel which isn't problematic, and
the first one which is. Here's how to do it:
http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-fi...
Thank you. I will look into this. Thought it may well be at least a bit
above my league.
Alternatively, could you try latest mainline (3.17-rc7) and check if
the problem persists? Maybe it's solved there.
That would involve enabling rawhide, I guess? So
$ sudo yum update kernel --enablerepo rawhide
Loaded plugins: langpacks
rawhide/x86_64/metalink | 11 kB
00:00 rawhide | 4.2
kB 00:00 Resolving Dependencies
--> Running transaction check
---> Package kernel.x86_64 0:3.17.0-0.rc7.git2.1.fc22 will be installed
--> Processing Dependency: kernel-modules-uname-r =
3.17.0-0.rc7.git2.1.fc22.x86_64 for package:
kernel-3.17.0-0.rc7.git2.1.fc22.x86_64
--> Processing Dependency: kernel-core-uname-r =
3.17.0-0.rc7.git2.1.fc22.x86_64 for package:
kernel-3.17.0-0.rc7.git2.1.fc22.x86_64
--> Running transaction check
---> Package kernel-core.x86_64 0:3.17.0-0.rc7.git2.1.fc22 will be
installed
---> Package kernel-modules.x86_64 0:3.17.0-0.rc7.git2.1.fc22 will be
installed
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version
Repository Size
================================================================================
Installing: kernel x86_64
3.17.0-0.rc7.git2.1.fc22 rawhide 41 k Installing for
dependencies: kernel-core x86_64
3.17.0-0.rc7.git2.1.fc22 rawhide 18 M kernel-modules
x86_64 3.17.0-0.rc7.git2.1.fc22 rawhide 17 M
Transaction Summary
================================================================================
Install 1 Package (+2 Dependent packages)
Total download size: 35 M
Installed size: 57 M
Is this ok [y/d/N]:
Exiting on user command
Your transaction was saved, rerun it with:
yum load-transaction /tmp/yum_save_tx.2014-10-04.09-15.EbFF_o.yumtx
This does not update the kernel-headers or the kernel-modules-extra. Is
that an issue?
Many thanks,
Ranjan
PS: I am just curious: why has there been no update for 3.16 on the
mainline for over two weeks?
Many thanks again!
Ranjan
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
--
Important Notice: This mailbox is ignored: e-mails are set to be
deleted on receipt. Please respond to the mailing list if appropriate.
For those needing to send personal or professional e-mail, please use
appropriate addresses.
____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth
2:30 a.m.
On 03.10.2014, Ranjan Maitra wrote:
How does one go down to a 3.15.10 kernel? I could try that and see,
I
guess. Would it also downgrade the headers, etc?
If you install a Fedora kernel: yes.
I think: if you're able to reproduce the error easily, you should try
to bisect the patch which introduced the faulty behaviour. This would
only make sense with a vanilla kernel.
The first step would be to find a kernel which isn't problematic, and
the first one which is. Here's how to do it:
http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-fi...
Alternatively, could you try latest mainline (3.17-rc7) and check if
the problem persists? Maybe it's solved there.
2:45 p.m.
Hello,
On Wed, 1 Oct 2014 21:34:18 +0200 Heinz Diehl <htd+ml(a)fritha.org> wrote:
On 01.10.2014, Ranjan Maitra wrote:
> Unfortunately, there are hard lockups.
Then, you should definitely report this to the Fedora kernel folks.
You can also try with a vanilla kernel from kernel.org, and if the
problem persists, you could report it directly to the linux kernel
mailing list.
> How do I disable irqbalance?
You can do a "yum remove irqbalance" or a "systemctl disable
irqbalance.service". And add "acpi_irq_nobalance" to the kernel boot
parameters in grub.conf.
> And there appears to be no irq.c on my system.
It should be in the arch/x86/kernel/ directory of your kernel sourcetree.
It's been quite a while I tried to understand this area of the kernel.
[....]
> I did submit a bug report yesterday but it has not been assigned yet.
> Looks like an obscure issue.
This (and/or similar bugs) are going on for a while. I remember
those hard lockups from quite a few years back in time (at least in
the 2.6 generation). Not sure if they have the same origin/cause,
though. If I remember this correctly, both a racy irq migration
code as well as a faulty BIOS were discussed.
Maybe there is a BIOS update for your machine?
I just wanted to mention that the BIOS update did not have any effect
(the system still has the same problems waking up from hibernate).
How does one go down to a 3.15.10 kernel? I could try that and see, I
guess. Would it also downgrade the headers, etc?
Many thanks,
Ranjan
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
--
Important Notice: This mailbox is ignored: e-mails are set to be
deleted on receipt. Please respond to the mailing list if appropriate.
For those needing to send personal or professional e-mail, please use
appropriate addresses.
____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!
2:58 p.m.
On Wed, 1 Oct 2014 21:34:18 +0200 Heinz Diehl <htd+ml(a)fritha.org> wrote:
On 01.10.2014, Ranjan Maitra wrote:
> Unfortunately, there are hard lockups.
Then, you should definitely report this to the Fedora kernel folks.
Thanks! I have done this.
You can also try with a vanilla kernel from kernel.org, and if the
problem persists, you could report it directly to the linux kernel
mailing list.
I will look into this, thanks!
> How do I disable irqbalance?
You can do a "yum remove irqbalance" or a "systemctl disable
irqbalance.service". And add "acpi_irq_nobalance" to the kernel boot
parameters in grub.conf.
I see, thanks.
> And there appears to be no irq.c on my system.
It should be in the arch/x86/kernel/ directory of your kernel sourcetree.
It's been quite a while I tried to understand this area of the kernel.
Sure, thanks!
[....]
> I did submit a bug report yesterday but it has not been assigned yet.
> Looks like an obscure issue.
This (and/or similar bugs) are going on for a while. I remember
those hard lockups from quite a few years back in time (at least in
the 2.6 generation). Not sure if they have the same origin/cause,
though. If I remember this correctly, both a racy irq migration
code as well as a faulty BIOS were discussed.
Maybe there is a BIOS update for your machine?
The machine is three months old, so not completely clear but I will
take a look. One problem is that I stripped out the Windows 7 that it
came with, and may be an issue. Here is the bios released as per Dell:
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId...
Thanks again!
Best wishes,
Ranjan
____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth
3:01 p.m.
On 01.10.2014 21:58, Ranjan Maitra wrote:
On Wed, 1 Oct 2014 21:34:18 +0200 Heinz Diehl
<htd+ml(a)fritha.org> wrote:
> On 01.10.2014, Ranjan Maitra wrote:
>
>> Unfortunately, there are hard lockups.
>
> Then, you should definitely report this to the Fedora kernel folks.
Thanks! I have done this.
> You can also try with a vanilla kernel from kernel.org, and if the
> problem persists, you could report it directly to the linux kernel
> mailing list.
I will look into this, thanks!
Reporting bugs for the Linux kernel
https://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html
2:45 p.m.
On 01.10.2014 21:34, Heinz Diehl wrote:
On 01.10.2014, Ranjan Maitra wrote:
> Unfortunately, there are hard lockups.
Then, you should definitely report this to the Fedora kernel folks.
You can also try with a vanilla kernel from kernel.org, and if the
problem persists, you could report it directly to the linux kernel
mailing list.
> How do I disable irqbalance?
You can do a "yum remove irqbalance" or a "systemctl disable
irqbalance.service". And add "acpi_irq_nobalance" to the kernel boot
parameters in grub.conf.
> And there appears to be no irq.c on my system.
It should be in the arch/x86/kernel/ directory of your kernel sourcetree.
It's been quite a while I tried to understand this area of the kernel.
[....]
> I did submit a bug report yesterday but it has not been assigned yet.
> Looks like an obscure issue.
This (and/or similar bugs) are going on for a while. I remember
those hard lockups from quite a few years back in time (at least in
the 2.6 generation). Not sure if they have the same origin/cause,
though. If I remember this correctly, both a racy irq migration
code as well as a faulty BIOS were discussed.
Maybe there is a BIOS update for your machine?
How it ends when you have to deal with the kernel
http://www.theregister.co.uk/2013/01/24/alan_cox_quits_linux_development
2:34 p.m.
On 01.10.2014, Ranjan Maitra wrote:
Unfortunately, there are hard lockups.
Then, you should definitely report this to the Fedora kernel folks.
You can also try with a vanilla kernel from kernel.org, and if the
problem persists, you could report it directly to the linux kernel
mailing list.
How do I disable irqbalance?
You can do a "yum remove irqbalance" or a "systemctl disable
irqbalance.service". And add "acpi_irq_nobalance" to the kernel boot
parameters in grub.conf.
And there appears to be no irq.c on my system.
It should be in the arch/x86/kernel/ directory of your kernel sourcetree.
It's been quite a while I tried to understand this area of the kernel.
[....]
I did submit a bug report yesterday but it has not been assigned
yet.
Looks like an obscure issue.
This (and/or similar bugs) are going on for a while. I remember
those hard lockups from quite a few years back in time (at least in
the 2.6 generation). Not sure if they have the same origin/cause,
though. If I remember this correctly, both a racy irq migration
code as well as a faulty BIOS were discussed.
Maybe there is a BIOS update for your machine?
1:52 a.m.
On 30.09.2014, Ranjan Maitra wrote:
Thanks! I will do that right now. This only happens to me on a
wakeup
from hibernate and with one new laptop (Dell Precision M3800).
If this gives you problems, you could try to disable irqbalance to
work around. Otherwise, I would have ignored the message (which is
kind of a warning, if I remember the source correctly - there were
hard lockups some years ago, and AFAIR the code around the missing
interrupt for a certain cpu vector (take a look into irq.c) was
modified to ack the missing interrupt, giving the system a chance to
proceed. Feel free to correct me if I'm wrong.
2:18 p.m.
Thanks! I will do that right now. This only happens to me on a wakeup
from hibernate and with one new laptop (Dell Precision M3800).
Best wishes,
Ranjan
On Tue, 30 Sep 2014 20:47:15 +0200 Heinz Diehl <htd+ml(a)fritha.org>
wrote:
On 30.09.2014, Ranjan Maitra wrote:
> kernel:do_IRQ: 0.81 No irq handler for vector (irq -1)
Could be a bug in the irq migration code. You should report this to
the Fedora kernel maintainers.
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
--
Important Notice: This mailbox is ignored: e-mails are set to be
deleted on receipt. Please respond to the mailing list if appropriate.
For those needing to send personal or professional e-mail, please use
appropriate addresses.
____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth
8:16 a.m.
On Wed, 1 Oct 2014 08:52:19 +0200 Heinz Diehl <htd+ml(a)fritha.org> wrote:
On 30.09.2014, Ranjan Maitra wrote:
> Thanks! I will do that right now. This only happens to me on a wakeup
> from hibernate and with one new laptop (Dell Precision M3800).
If this gives you problems, you could try to disable irqbalance to
work around. Otherwise, I would have ignored the message (which is
kind of a warning, if I remember the source correctly - there were
hard lockups some years ago, and AFAIR the code around the missing
interrupt for a certain cpu vector (take a look into irq.c) was
modified to ack the missing interrupt, giving the system a chance to
proceed. Feel free to correct me if I'm wrong.
Thanks! Unfortunately, there are hard lockups. Last night upon wakeup
from hibernate, I got the following:
kernel:[43026.180173] do_IRQ: 0.81 No irq handler for vector (irq -1)
kernel:do_IRQ: 0.81 No irq handler for vector (irq -1)
And there was a thick band of flitting black red and blue speckled
images aceorss the top lof the lower third of my screen. I could not
seem to be able to get rid of this without reboot.
This morning, I did not get any messages but the system was in hard
lockup. And I had to reboot.
How do I disable irqbalance? And there appears to be no irq.c on my
system.
Btw, here is output from my lsmod and lspci:
$ lsmod
Module Size Used by
smsc75xx 37319 0
usbnet 41927 1 smsc75xx
mii 13527 2 usbnet,smsc75xx
ip6t_rpfilter 12546 1
tun 27153 0
ip6t_REJECT 12939 2
xt_conntrack 12760 9
bnep 19624 2
ebtable_nat 12807 0
ebtable_broute 12731 0
bridge 116006 1 ebtable_broute
stp 12868 1 bridge
llc 13941 2 stp,bridge
ebtable_filter 12827 0
ebtables 30758 3
ebtable_broute,ebtable_nat,ebtable_filter ip6table_nat 12974
1 nf_conntrack_ipv6 18738 6
nf_defrag_ipv6 34712 1 nf_conntrack_ipv6
nf_nat_ipv6 13213 1 ip6table_nat
ip6table_mangle 12700 1
ip6table_security 12710 1
ip6table_raw 12683 1
ip6table_filter 12815 1
ip6_tables 26809 5
ip6table_filter,ip6table_mangle,ip6table_security,ip6table_nat,ip6table_raw
iptable_nat 12970 1 nf_conntrack_ipv4 14656 5
nf_defrag_ipv4 12702 1 nf_conntrack_ipv4
nf_nat_ipv4 13199 1 iptable_nat
nf_nat 25178 4
nf_nat_ipv4,nf_nat_ipv6,ip6table_nat,iptable_nat nf_conntrack
99420 8
nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,ip6table_nat,iptable_nat,nf_conntrack_ipv4,nf_conntrack_ipv6
iptable_mangle 12695 1 iptable_security 12705 1
iptable_raw 12678 1 arc4 12608 2
iwlmvm 222115 0
mac80211 623787 1 iwlmvm
x86_pkg_temp_thermal 14205 0
coretemp 13441 0
kvm_intel 147547 0
kvm 452677 1 kvm_intel
crct10dif_pclmul 14307 0
crc32_pclmul 13133 0
crc32c_intel 22094 0
ghash_clmulni_intel 13230 0
pn544_mei 12802 0
mei_phy 13574 1 pn544_mei
pn544 18073 1 pn544_mei
rtsx_pci_sdmmc 22998 0
hci 43298 2 pn544,mei_phy
snd_hda_codec_realtek 72791 1
mmc_core 121087 1 rtsx_pci_sdmmc
rtsx_pci_ms 18168 0
snd_hda_codec_generic 67662 1 snd_hda_codec_realtek
snd_hda_codec_hdmi 47489 1
iTCO_wdt 13480 0
memstick 16199 1 rtsx_pci_ms
nfc 98285 2 hci,pn544
iTCO_vendor_support 13419 1 iTCO_wdt
dell_wmi 12681 0
sparse_keymap 13584 1 dell_wmi
uvcvideo 81022 0
videobuf2_vmalloc 13163 1 uvcvideo
videobuf2_memops 13161 1 videobuf2_vmalloc
dell_laptop 18168 0
snd_hda_intel 30379 7
videobuf2_core 57175 1 uvcvideo
snd_hda_controller 30139 1 snd_hda_intel
dcdbas 14875 1 dell_laptop
v4l2_common 14542 1 videobuf2_core
snd_hda_codec 131298 5
snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller
joydev 17344 0 iwlwifi 125702 1 iwlmvm
btusb 32448 0
snd_hwdep 17650 1 snd_hda_codec
videodev 147660 3 uvcvideo,v4l2_common,videobuf2_core
microcode 44710 0
i2c_i801 18146 0
serio_raw 13434 0
hid_multitouch 17419 0
bluetooth 433970 21 bnep,btusb
snd_seq 62266 0
rtsx_pci 44989 2 rtsx_pci_ms,rtsx_pci_sdmmc
cfg80211 500115 3 iwlwifi,mac80211,iwlmvm
lpc_ich 21093 0
snd_seq_device 14136 1 snd_seq
media 20846 2 uvcvideo,videodev
mfd_core 13182 2 lpc_ich,rtsx_pci
snd_pcm 104333 4
snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_controller
rfkill 21979 6 nfc,cfg80211,bluetooth,dell_laptop
mei_me 19568 0 snd_timer 28778 2
snd_pcm,snd_seq mei 86597 3 pn544_mei,mei_phy,mei_me
snd 75905 24
snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device
soundcore 14491 2 snd,snd_hda_codec
int3403_thermal 12967 0 dell_smo8800 13154 0
shpchp 37047 0
nfsd 283833 1
auth_rpcgss 58761 1 nfsd
nfs_acl 12741 1 nfsd
lockd 93436 1 nfsd
sunrpc 279214 5 nfsd,auth_rpcgss,lockd,nfs_acl
nouveau 1222531 1
i915 904304 5
ttm 80772 1 nouveau
i2c_algo_bit 13257 2 i915,nouveau
drm_kms_helper 58041 2 i915,nouveau
drm 291361 7 ttm,i915,drm_kms_helper,nouveau
i2c_core 55486 8
drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,v4l2_common,nouveau,videodev
mxm_wmi 12865 1 nouveau wmi 18820 3
dell_wmi,mxm_wmi,nouveau video 19777 2 i915,nouveau
$ lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor DRAM Controller (rev 06) 00:01.0 PCI bridge: Intel
Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16
Controller (rev 06) 00:02.0 VGA compatible controller: Intel
Corporation 4th Gen Core Processor Integrated Graphics Controller (rev
06) 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen
Core Processor HD Audio Controller (rev 06) 00:04.0 Signal processing
controller: Intel Corporation Device 0c03 (rev 06) 00:14.0 USB
controller: Intel Corporation 8 Series/C220 Series Chipset Family USB
xHCI (rev 05) 00:16.0 Communication controller: Intel Corporation 8
Series/C220 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0
USB controller: Intel Corporation 8 Series/C220 Series Chipset Family
USB EHCI #2 (rev 05) 00:1b.0 Audio device: Intel Corporation 8
Series/C220 Series Chipset High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #1 (rev d5) 00:1c.2 PCI bridge: Intel
Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port
#3 (rev d5) 00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI
Express Root Port #4 (rev d5) 00:1d.0 USB controller: Intel Corporation 8 Series/C220
Series Chipset Family USB EHCI #1 (rev 05) 00:1f.0 ISA bridge: Intel Corporation HM87
Express LPC Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation 8 Series/C220
Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05) 00:1f.3 SMBus: Intel
Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05) 00:1f.6 Signal
processing controller: Intel Corporation 8 Series Chipset Family Thermal Management
Controller (rev 05) 02:00.0 3D controller: NVIDIA Corporation GK107GLM [Quadro K1100M]
(rev a1)
06:00.0 Network controller: Intel Corporation Wireless 7260 (rev 6b)
07:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd.
RTS5249 PCI Express Card Reader (rev 01)
I do not have kernel modesetting disabled in my kernel. The hardware is
Dell Precision M3800 and the screen resolution is 3200x1800. 12GB
memory and 16GB swap. If more information is needed, feel free to ask.
I did submit a bug report yesterday but it has not been assigned yet.
Looks like an obscure issue.
Many thanks and best wishes,
Ranjan
____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth
2:29 p.m.
Thanks again!
3.17 is the mainline kernel which is under actual development, and
will be the stable kernel once released and updated. Soon after 3.17
is released, the merge window opens, which is the time the developers
are sending new patches to Linus. After 3.18-rc1 is released, the
merge window closes, and usually only bug fixes are accepted then.
Important fixes will be backported to the stable kernel trees, thus the
different minor version number releases.
On a whim, I decided to try 3.17-rc7 from rawhide first. This appears
to bring the network back on after a resume. It did it twice now. So
this issue has been alleviated at least somewhat. Fingers crossed, but
we shall see! No messages from irqbalance and no lockups also yet so
there is some hope for cautious optimism!:-)
In short: the actual mainline kernel is the one which is most
up-to-date (3.17 will be released soon..).
> What I don't quite understand is that there seem to be no issues when
> the system is rebooted. But issues arise only upon a wakeup from
> hibernate. Which I did, as advised in the mailing list here, doing the
> following:
[....]
With grub2, an additional "resume" boot parameter is not needed, as
long as your swap partition is properly formatted (mkswap, swapon)
and referred to in fstab when installing your kernel.
Is this true anymore? I thought this was gone with F20, and manual
intervention was needed, from what I understood from this thread:
https://lists.fedoraproject.org/pipermail/users/2013-December/443589.html
However, the solution in the above thread is inaccurate. The correct
solution is here:
https://lists.fedoraproject.org/pipermail/users/2013-December/443871.html
Anecdotally also, it appears to be true. Without the resume = UUID
stuff, it does not wake up from hibernate but goes on to reboot.
I formatted swap with the Anaconda installer. And I do have swapon.
$ swapon
NAME TYPE SIZE USED PRIO
/dev/sda2 partition 15.6G 0B -1
I would love it, if I did not have to play with grub to get hibernate
working.
Thanks again!
Best wishes,
Ranjan
____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth
3483
days inactive
3489
days old
19 comments
3 participants
participants (3)
-
Heinz Diehl -
poma -
Ranjan Maitra