Bug#619034: [regression] "BUG: Unable to handle kernel paging request at ffffc90013cd8000" and no sound card recognized
On Thu, Jan 26, 2012 at 03:05:54PM +0100, Paul Menzel wrote: > I can recommend Flashrom [1] for doing BIOS upgrades. Just check if your > board or chipset and flash chip are supported and it should work out of > the box. If something went wrong you should ask on #flashrom or on the > list for help. You BIOS needs to be supported. I have several systems that can be flashed successfully but it will loose all informations, beginning from the mac adresses of the network adapters. Bastian -- Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant." -- Kirk, "The Ultimate Computer", stardate 4731.3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619034: [regression] "BUG: Unable to handle kernel paging request at ffffc90013cd8000" and no sound card recognized
Am Donnerstag, den 26.01.2012, 04:45 -0600 schrieb Jonathan Nieder: […] > Do you know anyone else with MSI boards and whether they suffer from > the same problem? > > Are there other BIOS versions available for this board, and is it > possible to test them to see if they need the quirk? (Please do read > the relevant caveats before trying any BIOS updates if involved in > testing for this.) I can recommend Flashrom [1] for doing BIOS upgrades. Just check if your board or chipset and flash chip are supported and it should work out of the box. If something went wrong you should ask on #flashrom or on the list for help. Thanks, Paul [1] http://www.flashrom.org/ signature.asc Description: This is a digitally signed message part
Bug#619034: [regression] "BUG: Unable to handle kernel paging request at ffffc90013cd8000" and no sound card recognized
found 619034 linux-2.6/3.2.1-2 quit Svante Signell wrote: > Do I need to add a comment about this at ticket 42619 too? I've sent a patch. I'm hoping Bjorn or some other knowledgeable person can come up with some comment to obsolete it, but in any case, I'd be happy with as thorough testing as you can come up with for it. Do you know anyone else with MSI boards and whether they suffer from the same problem? Are there other BIOS versions available for this board, and is it possible to test them to see if they need the quirk? (Please do read the relevant caveats before trying any BIOS updates if involved in testing for this.) Well, that's all I can think of. Good luck. Thanks. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619034: [regression] "BUG: Unable to handle kernel paging request at ffffc90013cd8000" and no sound card recognized
On Sat, 2012-01-21 at 08:58 +0100, Paul Menzel wrote: > forwarded 619034 https://bugzilla.kernel.org/show_bug.cgi?id=42619 > quit > > > Dear Svante, dear Jonathan, > > > Am Mittwoch, den 18.01.2012, 19:23 -0600 schrieb Jonathan Nieder: > > > Svante Signell wrote: > > > The box boots perfectly with the additional option pci=use_crs. > > > Hopefully the kernel developers and Debian Kernel Maintainers can find a > > > permanent solution soon. > > > > Thanks again for your help in this. I assume current kernels still don't > > work out of the box on your machine? I can confirm that also the latest kernel: 3.2.0-1-686-pae fails to boot without the option: pci=use_crs > I created a new ticket dedicated to the Svante’s board MS-7253, so that > the Debian BTS can track that bug now for #619034. Please comment there > anything else. Do I need to add a comment about this at ticket 42619 too? > > Unfortunately some machines need to use the _CRS table and some need > > it ignored, so for now upstream is building a table of known cases in > > which the kernel looks up the machine at boot time. Hopefully over > > time patterns will emerge and there can be a more principled rule. > > Let’s hope so. Old ticket: > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=30552 New ticket: > [2] https://bugzilla.kernel.org/show_bug.cgi?id=42619 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619034: [regression] "BUG: Unable to handle kernel paging request at ffffc90013cd8000" and no sound card recognized
forwarded 619034 https://bugzilla.kernel.org/show_bug.cgi?id=42619 quit Dear Svante, dear Jonathan, Am Mittwoch, den 18.01.2012, 19:23 -0600 schrieb Jonathan Nieder: > Svante Signell wrote: > > > I have uploaded a dmesg ouput to the kernel bug > > https://bugzilla.kernel.org/show_bug.cgi?id=30552 >> > > The box boots perfectly with the additional option pci=use_crs. > > Hopefully the kernel developers and Debian Kernel Maintainers can find a > > permanent solution soon. > > Thanks again for your help in this. I assume current kernels still don't > work out of the box on your machine? > > If so, please add a comment to [1] with the newest version you've > checked and your DMI information. (You can get it with "dmidecode" or > "grep . /sys/class/dmi/id/*", or something like "dmesg | grep DMI" on > more recent kernels.) I created a new ticket dedicated to the Svante’s board MS-7253, so that the Debian BTS can track that bug now for #619034. Please comment there anything else. > Unfortunately some machines need to use the _CRS table and some need > it ignored, so for now upstream is building a table of known cases in > which the kernel looks up the machine at boot time. Hopefully over > time patterns will emerge and there can be a more principled rule. Let’s hope so. Thanks, Paul > [1] https://bugzilla.kernel.org/show_bug.cgi?id=30552 [2] https://bugzilla.kernel.org/show_bug.cgi?id=42619 signature.asc Description: This is a digitally signed message part
Bug#619034: [regression] "BUG: Unable to handle kernel paging request at ffffc90013cd8000" and no sound card recognized
Hi Svante, Svante Signell wrote: > I have uploaded a dmesg ouput to the kernel bug > https://bugzilla.kernel.org/show_bug.cgi?id=30552 > > The box boots perfectly with the additional option pci=use_crs. > Hopefully the kernel developers and Debian Kernel Maintainers can find a > permanent solution soon. Thanks again for your help in this. I assume current kernels still don't work out of the box on your machine? If so, please add a comment to [1] with the newest version you've checked and your DMI information. (You can get it with "dmidecode" or "grep . /sys/class/dmi/id/*", or something like "dmesg | grep DMI" on more recent kernels.) Unfortunately some machines need to use the _CRS table and some need it ignored, so for now upstream is building a table of known cases in which the kernel looks up the machine at boot time. Hopefully over time patterns will emerge and there can be a more principled rule. Hope that helps, Jonathan [1] https://bugzilla.kernel.org/show_bug.cgi?id=30552 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619034: [regression] "BUG: Unable to handle kernel paging request at ffffc90013cd8000" and no sound card recognized
On Thu, 2011-07-14 at 13:27 -0500, Jonathan Nieder wrote: > Hi, > > Takashi Iwai wrote: > >>> On Wed, 2011-03-30 at 15:13 +0200, Clemens Ladisch wrote: > > Svante Signell wrote: > > >> During boot of kernel 2.6.38 (and 2.6.37) udev bugs out: > >> Waiting for /dev to be fully populated > >> BUG: Unable to handle kernel paging request at c90013cd8000 > >> axz_probe+ ... [snd_hda_intel] > >> ...lots of output lost... > >> udevadm timeout 180 sec ... > >> udevd[390]: worker [439] failed while handling > >> '/devices/pci:80/:80:01.0' > >> > >> After the timeout the boot continues! Have not yet tested if sound > >> is > >> functional. > [...] > This is the azx_readw(chip, GCAP) in azx_create(); chip->remap_addr is > 0xc90011c08000 which does look like a valid pointer, but isn't. > [...] > > The point where it Oops implies that the problem isn't in the sound > > driver but rather in a breakage in a deeper level, either PCI core, > > x86 mm or ACPI/BIOS. > > > > Any chance to bisect the kernel? > > Svante bisected it to v2.6.34-rc1~218^2~27 (x86/pci: Use > resource_size_t in update_res, 2010-02-10) --- thanks. Which is > pretty weird, since I think phys_addr_t on an amd64 machine (and hence > resource_size_t) would be 64 bits, making that commit a no-op. > > Svante, more questions (sorry): > > - could you try booting b74fd238a9cf and b74fd238a9cf^ again >(to make sure we haven't hit a heisenbug) and send the >corresponding full dmesg and .config files? I am very sorry but I don't have physical access to that box for a month from now. However, something that might be more interesting is the output of the second-to last message that was concerning x86/pci/amd/ I might get help to find that message in a few days. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619034: [regression] "BUG: Unable to handle kernel paging request at ffffc90013cd8000" and no sound card recognized
Hi, Takashi Iwai wrote: >>> On Wed, 2011-03-30 at 15:13 +0200, Clemens Ladisch wrote: > Svante Signell wrote: >> During boot of kernel 2.6.38 (and 2.6.37) udev bugs out: >> Waiting for /dev to be fully populated >> BUG: Unable to handle kernel paging request at c90013cd8000 >> axz_probe+ ... [snd_hda_intel] >> ...lots of output lost... >> udevadm timeout 180 sec ... >> udevd[390]: worker [439] failed while handling >> '/devices/pci:80/:80:01.0' >> >> After the timeout the boot continues! Have not yet tested if sound is >> functional. [...] This is the azx_readw(chip, GCAP) in azx_create(); chip->remap_addr is 0xc90011c08000 which does look like a valid pointer, but isn't. [...] > The point where it Oops implies that the problem isn't in the sound > driver but rather in a breakage in a deeper level, either PCI core, > x86 mm or ACPI/BIOS. > > Any chance to bisect the kernel? Svante bisected it to v2.6.34-rc1~218^2~27 (x86/pci: Use resource_size_t in update_res, 2010-02-10) --- thanks. Which is pretty weird, since I think phys_addr_t on an amd64 machine (and hence resource_size_t) would be 64 bits, making that commit a no-op. Svante, more questions (sorry): - could you try booting b74fd238a9cf and b74fd238a9cf^ again (to make sure we haven't hit a heisenbug) and send the corresponding full dmesg and .config files? Puzzled, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
