Turns out "pcie_aspm=off" effectively disables AER because Linux doesn't
request AER control when it doesn't advertise ASPM support (see
ACPI_PCIE_REQ_SUPPORT). That explains why "pcie_aspm=off" would avoid
the error reporting.
This report was from a v3.11-based kernel. v3.11 is from Mon Sep 2
Also, if you do see this issue, some have reported that "pcie_aspm=off"
avoids the errors. If that's the case for you, see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2043665/comments/6
and help me investigate it!
--
You received this bug notification because you are a member of Ubuntu
Generally we should not see reproducible PCIe Correctable Errors in
significant numbers. Some have reported that "pcie_aspm=off" avoids the
errors. If that's the case for you, see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2043665/comments/6
and help me investigate it!
--
You
We should not need to use "pci=noaer". Generally we should not see
reproducible PCIe Correctable Errors in significant numbers. Some have
reported that "pcie_aspm=off" avoids the errors. If that's the case for
you, see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2043665/comments/6
and
Is this reproducible? Is it related to suspend/resume? Even if the
kernel hang is not reproducible, I'm interested in the PCIe Corrected
Errors. Some have reported that "pcie_aspm=off" avoids the errors. If
that's the case for you, see
We should not need to use "pci=noaer". Generally we should not see
reproducible PCIe Correctable Errors in significant numbers. Some have
reported that "pcie_aspm=off" avoids the errors. If that's the case for
you, see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2043665/comments/6
and
We should not need to use "pci=noaer". Generally we should not see
reproducible PCIe Correctable Errors in significant numbers. Some have
reported that "pcie_aspm=off" avoids the errors. If that's the case for
you, see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2043665/comments/6
and
There are a couple mentions of "pcie_aspm=off" making a difference here.
If that's the case, see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2043665/comments/6
and help me look at this.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
If this is still reproducible, see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2043665/comments/6
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1798880
Title:
PCIe Bus Error:
Thank you! "pci=noaer" definitely sweeps this dust under the carpet,
and it would be much better to avoid that.
Narcis (comment #157) reported that "pcie_aspm=off" is a workaround and
is much more specific than "pci=noaer".
If we can collect complete dmesg and "sudo lspci -vv" output when
Sometimes the "pcie_aspm=off" kernel parameter hides this problem. I
would really like to fix the underlying problem so the parameter isn't
needed.
If anybody sees this problem and is willing to help fix it, please open
a bug report at https://bugzilla.kernel.org/, product Drivers/PCI,
mention
The "pcie_aspm=off" kernel parameter hides a problem. I would really
like to fix the underlying problem so the parameter isn't needed.
If anybody sees this problem and is willing to help fix it, please open
a bug report at https://bugzilla.kernel.org/, product Drivers/PCI,
mention the hardware
The "pcie_aspm=off" kernel parameter hides a problem. I would really
like to fix the underlying problem so the parameter isn't needed.
If anybody is willing to help fix it, please open a bug report at
https://bugzilla.kernel.org/, product Drivers/PCI, mention the hardware
platform, and attach:
Should be fixed by https://git.kernel.org/linus/d341838d776a, which will
appear in v5.19-rc1.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1884232
Title:
touchpad and touchscreen doesn't work at
The "ACPI region does not cover" errors are not related to the AER PCIe
bus error.
Neither is the nouveau MMIO read fault (that looks like a null pointer
problem).
Naveen Naidu is looking at the AER problem, so I hope we'll have a patch
that makes "pci=noaer" unnecessary.
--
You received this
Chime in on this email thread if interested:
https://lore.kernel.org/r/20200723201403.GA1450503@bjorn-Precision-5520
There are instructions at the bottom of that page about how to reply to the
thread.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Yes, I think that kernel is fine.
You can leave the i8042.nopnp=1 in your kernel command line parameters.
Otherwise it looks right.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1884232
Title:
1) Sorry, I don't have a PPA or similar kernel image for you to try.
2) I expected that Windows would move 00:1f.5 BAR 0 to be inside the
windows reported by the PCI0 _CRS, but the AIDA64 report shows
otherwise:
B00 D1F F05: Intel Ice Point-LP PCH - SPI (Flash) Controller
It looks like a BIOS bug to me.
But Windows does work, and Linux should, too. It looks like there's
plenty of available space for 00:1f.5 BAR 0. Can you try a current
version of Linux, e.g., v5.8-rc1 with the command line argument
'dyndbg="file drivers/pci/* +p"'? There were some significant
This looks like a BIOS defect. BIOS programmed BAR 0 to [mem
0xfe01-0xfe010fff], but according to the PCI0 _CRS method, that area
is not routed to the PCI bus:
ACPI: PCI Root Bridge [PCI0] (domain [bus 00-fe])
pci_bus :00: root bus resource [mem 0x000a-0x000b window]
I'm not using Mint. I started with Ubuntu 18.04 in June 2018, installed
the "cinnamon" package, and recently updated to 20.04. I don't know if
this is a regression because I didn't start using this configuration
until after moving to 20.04. Pretty sure cinnamon came from the ubuntu
repo; my
I'm sure it's not a Linux kernel bug. I don't have any idea *where* the
bug is, and https://wiki.ubuntu.com/Bugs/FindRightPackage suggested
"linux" as a safe bet.
Sorry, I didn't realize Cinnamon wasn't supported by Ubuntu. I will
either live with the behavior or switch to the supported Ubuntu
apport information
** Attachment added: "Lspci.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379885/+files/Lspci.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881644
Title:
apport information
** Attachment added: "IwConfig.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379884/+files/IwConfig.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881644
apport information
** Attachment added: "Lspci-vt.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379886/+files/Lspci-vt.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881644
apport information
** Attachment added: "ProcCpuinfo.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379890/+files/ProcCpuinfo.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881644
apport information
** Attachment added: "ProcCpuinfoMinimal.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379891/+files/ProcCpuinfoMinimal.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
apport information
** Attachment added: "UdevDb.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379896/+files/UdevDb.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881644
Title:
apport information
** Attachment added: "Lsusb-v.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379889/+files/Lsusb-v.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881644
Title:
apport information
** Attachment added: "PulseList.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379894/+files/PulseList.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881644
apport information
** Attachment added: "Lsusb-t.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379888/+files/Lsusb-t.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881644
Title:
apport information
** Attachment added: "RfKill.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379895/+files/RfKill.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881644
Title:
apport information
** Attachment added: "Lsusb.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379887/+files/Lsusb.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881644
Title:
apport information
** Attachment added: "WifiSyslog.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379897/+files/WifiSyslog.txt
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs,
apport information
** Attachment added: "CRDA.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379882/+files/CRDA.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881644
Title:
20.04
apport information
** Attachment added: "CurrentDmesg.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379883/+files/CurrentDmesg.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
apport information
** Attachment added: "ProcModules.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379893/+files/ProcModules.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881644
apport information
** Attachment added: "ProcInterrupts.txt"
https://bugs.launchpad.net/bugs/1881644/+attachment/5379892/+files/ProcInterrupts.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
apport information
** Tags added: apport-collected focal
** Description changed:
Dell 5520 laptop -> Dell Thunderbolt dock -> HDMI -> external monitor.
Running 20.04, i915 driver.
Laptop lid closed, using external monitor only. When external monitor
turns off (after
** Summary changed:
- 20.04 i915 laptop external monitor turns off when inactive, must open lid to
turn it on
+ 20.04 i915 laptop external monitor doesn't resume from power-save, must open
lid to turn it on
** Package changed: ubuntu => linux (Ubuntu)
--
You received this bug notification
Public bug reported:
Dell 5520 laptop -> Dell Thunderbolt dock -> HDMI -> external monitor.
Running 20.04, i915 driver.
Laptop lid closed, using external monitor only. When external monitor
turns off (after sleep-display-ac), keyboard/mouse activity should turn
it back on, but do not. Opening
This issue should be resolved by
https://git.kernel.org/linus/1dace0116d0b, which appeared in v4.2. If
the kernel contains that commit, the "pci=use_crs" boot parameter should
not be needed.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
John, can you also include a little more detail about what the failure
looks like to a user? Does this result in AER errors being logged?
When we come up with a patch that works, I'd like to include a hint
about what user-visible problems it fixes in the changelog. I see from
the initial report
Please try the attached patch. It makes it so that if the device does
not support ECRC generation or checking, we don't enable those features.
Currently (without this patch), we *do* enable ECRC generation and
checking if _HPX allows, i.e., if the platform can support ECRC.
The ACPI dump
https://bugzilla.kernel.org/show_bug.cgi?id=92351#c1 reports the problem occurs
with LSI FW 18.
https://bugzilla.kernel.org/show_bug.cgi?id=92351#c8 reports the problem does
NOT occur with LSI FW 19. So upgrading the adapter firmware to version 19 may
be a fix.
There is a patch at
>From the Linux kernel point of view, changing the BIOS option is not a
good fix, and "pci=realloc=off" is just a workaround and not a real fix
either. Linux should be able to work even without that, or at least
give meaningful error messages.
The original problem appears to be that:
- BIOS
** Bug watch added: Linux Kernel Bug Tracker #92351
http://bugzilla.kernel.org/show_bug.cgi?id=92351
** Also affects: linux via
http://bugzilla.kernel.org/show_bug.cgi?id=92351
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of
There's a test patch at
https://bugzilla.kernel.org/show_bug.cgi?id=175391 Any test reports
would be welcome.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1627496
Title:
radeon broken with kernel
Related problem report:
https://bugzilla.kernel.org/show_bug.cgi?id=109691
Brief analysis of AER issue:
http://lkml.kernel.org/r/20151229155822.GA17321@localhost
I did say in that analysis that I was going to work on fixing this, but
I haven't had time. It would be great if somebody would jump
The register in question is the Advanced Error Capabilities and Control
register, at offset 0x18 in the Advanced Error Reporting capability,
which starts at 0x148 in the config space of device 80:02.0.
In the pre-boot value of 0x00a0, the following bits are set (per PCIe
spec r3.0, sec 7.10.7,
This looks related to https://bugzilla.kernel.org/show_bug.cgi?id=111601
Is "pci=noaer" (without using "pci=nomsi") sufficient to allow the
system to boot?
If you boot with "pci=noaer", does it still take a long time to boot?
If so, can you collect a dmesg log with timestamps so we can see where
The git link in comment #17 is stale because it references a branch
name, which is often re-used.
I think
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?h=9a6d7298b0833614c411f774c46514efb1bd5651
is a permanent link to the same thing.
--
You received this bug notification
In comment #40, I mistakenly said we reassign 80:01.0 to an address
that is under PCI0, not PCI1. I had misread the address 0xfd
as 0xfd00, but it is actually 0xfd__, which is just after
the [mem 0x8000-0xfc] range from amd_bus.c, and is not in
any of the apertures
Anybody seeing this problem on a Foxconn K8M890-8237A system, please
test this patch. With it, sound should work without having to boot with
pci=use_crs. If you test it, please attach the complete dmesg log
here. Thanks!
** This bug is no longer a duplicate of bug 662299
Soundcard not
*** This bug is a duplicate of bug 662299 ***
https://bugs.launchpad.net/bugs/662299
Bug #662299 includes several problems with similar symptoms and the same
workaround (booting with pci=use_crs).
Booting with pci=use_crs may be a workaround for this bug as well. If
it is, please attach a
Manuel, does this problem still occur? I can't see what the problem is
in your dmesg logs. Your logs contain 'PCI: Using host bridge windows
from ACPI; if necessary, use pci=nocrs and report a bug', booting with
pci=use_crs shouldn't make a difference on your machine.
If this is still a
pci=use_crs is a workaround but not a fix. If anybody who has this
problem can attach a complete dmesg log, we should be able to fix the
kernel so it works without having to boot with pci=use_crs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
*** This bug is a duplicate of bug 662299 ***
https://bugs.launchpad.net/bugs/662299
Bug #662299 includes several problems with similar symptoms and the same
workaround (booting with pci=use_crs).
Booting with pci=use_crs may be a workaround for this bug as well. If
it is, please attach a
*** This bug is a duplicate of bug 662299 ***
https://bugs.launchpad.net/bugs/662299
valkyr's report was on an ASUSTeK M2V-MX SE. That problem should be
fixed by this commit, which appeared upstream in v3.1:
*** This bug is a duplicate of bug 662299 ***
https://bugs.launchpad.net/bugs/662299
Stormhierta 's Micro-Star MS-7253 system, this should be fixed by these
commits, which appeared upstream in v3.3:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=841137170961
Hi JoseLuisTriana,
1) pci=use_crs shouldn't make a difference on your system because we
enable pci=use_crs automatically on systems with BIOS date of 2008 or
newer, and yours is 02/21/2008
2) Re comment #4, the kernel should be able to configure devices even if
the BIOS didn't set it up
*** This bug is a duplicate of bug 1033299 ***
https://bugs.launchpad.net/bugs/1033299
** This bug has been marked a duplicate of bug 1033299
Ubuntu 12.04 - no sound with VT8237A/VT8251
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
For Micro-Star MS-7253 systems, this should be fixed by:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=841137170961
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a97f4f5e524b
which appeared upstream in v3.3. This should fix the
*** This bug is a duplicate of bug 662299 ***
https://bugs.launchpad.net/bugs/662299
** This bug has been marked a duplicate of bug 662299
Soundcard not detected (workaround: add pci=use_crs to GRUB)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Eran, can you confirm whether (1) this is still a problem, and (2)
whether pci=use_crs makes a difference? Based on your dmesg log, I
don't see what it would change, but I might have missed something.
If pci=use_crs does make a difference, can you attach complete dmesg
logs with and without it?
I think this should be fixed by these commits:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=841137170961
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a97f4f5e524b
Both appeared upstream in v3.3.
--
You received this bug
Hi timmy,
pci=use_crs shouldn't make any difference on your system, because it
was already automatically enabled even without pci=use_crs.
If you still have an issue with sound or xgifb, please attach a complete
dmesg log.
--
You received this bug notification because you are a member of
FichdlMaa, you said in comment #12 that pcie=use_crs didn't make a
difference. Can you attach a complete dmesg log with pci=use_crs? I
think it should make some difference (it should change the address
assigned to the 80:01.0 sound device), but that may not be enough to fix
the whole problem.
This might be related to
https://bugzilla.kernel.org/show_bug.cgi?id=63661
That issue was bisected to 3c076351c402 (PCI: Rework ASPM disable
code), which appeared upstream in v3.3-rc1. That commit was backported
to Ubuntu-3.2.0-22.35: http://kernel.ubuntu.com/git/ubuntu/ubuntu-
Thanks for the bug report, Cristian. There's definitely something wrong
here. There are several similar reports of invalid UUID, and I just
don't believe they're all caused by BIOS bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=17792 (your report)
I see two problems in the initial report from FichdlMaa:
1) Linux ignores ACPI _CRS information and consequently assigns addresses to
the 80:01.0 device that may not work.
2) The page fault: BUG: unable to handle kernel paging request at
c9378000
Booting with pci=use_crs should work
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1033299 is a
different problem from what robusta is reporting here. In 1033299,
pci=use_crs should work around at least part of the problem, but I
don't think it will make a difference here.
Here, we have this:
pci :00:13.0:
Reported upstream as https://bugzilla.kernel.org/show_bug.cgi?id=86951
** Bug watch added: Linux Kernel Bug Tracker #86951
http://bugzilla.kernel.org/show_bug.cgi?id=86951
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This is not a duplicate of bug 438335.
This bug is caused by something wrong with the BARs of 00:0b.0:
pci :00:0b.0: BAR 1: error updating (0x001001 != 0x01)
pci :00:0b.0: BAR 4: error updating (0x4004 != 0x36850264)
pci :00:0b.0: BAR 4: error updating (high 0x00 !=
https://bugzilla.kernel.org/show_bug.cgi?id=63661 claims to be the same
as this bug and that the problem is caused by pci: Rework ASPM disable
code from commit 3c076351c4027a56d5005a39a0b518a4ba393ce2.
I'm not 100% sure that's the case, because comment #8 reports that
pci=conf1 is a workaround,
Oops, I screwed up. Please try this patch.
** Attachment added: Revert EISA changes
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1251816/+attachment/3951225/+files/eisa-revert
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
StefanF, I took care of attaching these to the upstream report
(https://bugzilla.kernel.org/show_bug.cgi?id=59311). Thanks a lot for
collecting them. I apologize that I haven't had time to make progress
on this issue.
--
You received this bug notification because you are a member of Ubuntu
Fernando, can you attach the dmesg log and lspci -vv output from the
newest working kernel, so we can compare them with those from the non-
working 3.11 kernel?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Probably the same as this upstream bug:
https://bugzilla.kernel.org/show_bug.cgi?id=63861
** Bug watch added: Linux Kernel Bug Tracker #63861
http://bugzilla.kernel.org/show_bug.cgi?id=63861
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This is an upstream kernel issue. The upstream bug report is
https://bugzilla.kernel.org/show_bug.cgi?id=59311
If anyone is in a position to reproduce the problem with the v3.11 upstream
kernel, please attach the following to the upstream bug report:
- Complete dmesg log
- lspci -vv output
If anybody has a CLEVO M5X0JE and could confirm that recent (3.x)
kernels work on it, I would really appreciate it.
https://bugzilla.kernel.org/show_bug.cgi?id=41722 is a CLEVO M5X0JE that
hangs during boot unless we use acpi=off.
** Bug watch added: Linux Kernel Bug Tracker #41722
It looks like this report is for a valid problem, but died on the vine.
Robert, did you ever resolve this? There's a similar report from Nick
Bray here: https://lkml.org/lkml/2011/10/26/191 with screenshots that
show a very similar backtrace. In Nick's case, booting with maxcpus=1
is a
This patch should fix the shpchp error message: http://marc.info/?l
=linux-pcim=131411621004431w=2
The system hangs reported by lmbezeau and daniel-hartman are a separate
issue and should be reported as a different bug.
--
You received this bug notification because you are a member of Ubuntu
This patch will fix the SHPC error messages: http://marc.info/?l=linux-
pcim=131411621004431w=2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/444241
Title:
shpchp :00:01.0: HPC vendor_id 1022 -
Blacklisting the nv_tco module is not a good long-term solution.
A recent upstream commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6b01d30eef64456ad9e261d2173266a3244da8e1
looks like it could be a fix for this issue.
Could somebody affected by this problem
Thanks, Lisa, for testing this. I think the reason it didn't work was
because we made an error backporting it. I also noticed another problem
with the patch, so I attached a newer version here:
https://bugzilla.kernel.org/show_bug.cgi?id=31602#c22
--
You received this bug notification because
atimonin, I doubt that you're seeing the same problem. If you had the
same problem, no USB devices attached to the affected controller would
work at all. A complete dmesg log would have the details we need to be
sure.
--
You received this bug notification because you are a member of Ubuntu
Anyone else affected by this Dell 1536/1546 issue, please test the
kernel patch at https://bugzilla.kernel.org/show_bug.cgi?id=31602#c21
and attach the results and dmesg log there.
I believe you will only see the issue if you have at least 3GB of memory
in your machine.
--
You received this bug
*** This bug is a duplicate of bug 647043 ***
https://bugs.launchpad.net/bugs/647043
This is a different problem from bug #64703.
In this problem, the Dell T3500 panics when we move a USB device into an
e820-reserved area. There's a patch upstream that fixes this (commit
*** This bug is a duplicate of bug 647043 ***
https://bugs.launchpad.net/bugs/647043
This is a duplicate of bug #653238, not of bug #647043.
Bug #653238 was marked a duplicate of bug #647043, but that is
incorrect.
--
You received this bug notification because you are a member of Ubuntu
*** This bug is a duplicate of bug 647043 ***
https://bugs.launchpad.net/bugs/647043
This is a duplicate of bug #653238, not of bug #647043.
Bug #653238 was marked a duplicate of bug #647043, but that is
incorrect.
--
You received this bug notification because you are a member of Ubuntu
*** This bug is a duplicate of bug 647043 ***
https://bugs.launchpad.net/bugs/647043
This is a duplicate of bug #653238, not of bug #647043.
Bug #653238 was marked a duplicate of bug #647043, but that is
incorrect.
--
You received this bug notification because you are a member of Ubuntu
Using pci=nocrs is a manual workaround, but not sufficient to resolve
this issue.
There is an upstream bug report for this issue on a Dell 1546:
https://bugzilla.kernel.org/show_bug.cgi?id=31602
Leann reported in comment #8 that the Dell 1536 in the cert lab works.
That machine appears to have
I attached a patch for testing here:
https://bugzilla.kernel.org/show_bug.cgi?id=31602#c19
Please attach any test results and dmesg logs in the kernel bugzilla.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Also affects Kubuntu 10.04 LTS.
--
Kubuntu Adding printer via Printer Configuration tool results in invalid
printers.conf, JobSheets entry incorrect
https://bugs.launchpad.net/bugs/403169
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to
If this is still a problem, please try booting a current upstream kernel
with this patch applied:
http://bugzilla.kernel.org/show_bug.cgi?id=12006#c36
and attach the dmesg output here.
** Bug watch added: Linux Kernel Bug Tracker #12006
http://bugzilla.kernel.org/show_bug.cgi?id=12006
--
Thanks, Peter!
Here's what happens without pci=use_crs:
ACPI: PCI Root Bridge [PCI0] (:00)
pci_root PNP0A08:00: host bridge window [mem 0xc000-0xfebf] (ignored)
pci :00:01.0: PCI bridge to [bus 01-01]
pci :00:01.0: bridge window [mem 0xbfe0-0xbfef]=
The normal method is to assume that all addresses to go the PCI bus
unless they're claimed by RAM or other builtin devices first. That's
certainly not true when we have more than one PCI host bridge, and
apparently it's not true even on some single-bridge machines like this
A355.
_CRS is the way
@Andy, if the more specific fix you refer to is a hotkey-setup change,
that is only a workaround and not a sufficient fix. The kernel should
never panic or hang, no matter what user-mode applications do. If you
pick up the kernel change from comment #32, the hotkey-setup change
should not be
As petski points out, this is very likely the same issue as
https://bugs.launchpad.net/bugs/157691 because:
- it affects the HP 6710b (comment #3)
- nosmp avoids the bug (comment #20)
- crash is related to lid event
User-mode code changes are not a fix for a kernel panic, so any hotkey-
1 - 100 of 113 matches
Mail list logo
