On Tue, 2022-02-08 at 13:10 +, Matthew Wilcox wrote:
> On Tue, Feb 08, 2022 at 12:01:22PM +0100, Julian Andres Klode wrote:
> > It's worth pointing out that in Ubuntu, the generated MOK key
> > is for module signing only (extended key usage
> > 1.3.6.1.4.1.2312.16.1.2), kernels signed with it
Subject: linux-image-5.5.0-2-amd64 won't boot in a AMD SEV Virtual Machine
Package: src:linux
Version: 5.5.17-1
Severity: important
The boot failure is total: not even a console log can be seen, and
seems to be due to the necessary memory encryption option not being set
in the debian kernel:
#
On Wed, 2019-10-02 at 22:07 +0200, Salvatore Bonaccorso wrote:
> > Linux Kernel 5.2 is completely unusable on most of my systems. The
> > problem seems to be something to do with memory compaction causing
> > intervals where the system becomes unresponsive.
> >
> > This is definitely an upstream
Package: src:linux
Version: 5.2.9-2
Severity: important
Tags: upstream
Dear Maintainer,
Linux Kernel 5.2 is completely unusable on most of my systems. The problem
seems to be something to do with memory compaction causing intervals where
the system becomes unresponsive.
This is definitely an
On Wed, 2014-02-19 at 01:06 +, Ben Hutchings wrote:
Matt Taggart reported that mvsas didn't bind to the Marvell
SAS controller on a Supermicro AOC-SAS2LP-MV8 board.
lspci reports it as:
01:00.0 RAID bus controller [0104]: Marvell Technology Group Ltd. Device
[1b4b:9485] (rev 03)
(C) 2006 James Bottomley james.bottom...@steeleye.com
- *
- * This is a simple module to wait until all the async scans are
- * complete. The idea is to use it in initrd/initramfs scripts. You
- * modprobe it after all the modprobes of the root SCSI drivers and it
- * will wait until they have
On Tue, 2011-04-19 at 11:20 +0200, Bartlomiej Zolnierkiewicz wrote:
From: Bartlomiej Zolnierkiewicz bzoln...@gmail.com
Subject: [PATCH v2] pata_cmd64x: add enablebits checking
Fixes IDE - libata regression.
IDE's cmd64x host driver has been supporting enablebits checking
since the initial
On Sun, 2011-04-17 at 11:11 -0400, John David Anglin wrote:
On Sat, 2011-04-16 at 19:35 -0400, John David Anglin wrote:
On Sat, 16 Apr 2011, James Bottomley wrote:
Strike that one ... I enabled USB in my 2.6.39-rc3 build and it inserts
the OHCI module and discovers the ports just
On Sun, 2011-04-17 at 10:23 -0500, James Bottomley wrote:
It's most likely a driver module that's getting loaded which is turned
off in the booting configuration ... finding it isn't going to be easy,
though ...
Finally got a build (had to swap out -Os for -O2).
I traced the module loads
On Sun, 2011-04-17 at 20:37 +0100, Ben Hutchings wrote:
On Sun, 2011-04-17 at 14:28 -0500, James Bottomley wrote:
I traced the module loads and successful inits and found it; it's
pata_cmd64x ... it loads but never returns from init. I bet it's
trying to poke into ISA space which causes
I've got a parisc system where the DVD drive is hardwired to a silicon
image controller:
00:02.0 IDE interface: Silicon Image, Inc. SiI 0649 Ultra ATA/100 PCI to
ATA Host Controller (rev 02) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: Silicon Image, Inc. SiI 0649 Ultra ATA/100
On Sun, 2011-04-17 at 21:25 -0400, John David Anglin wrote:
This is excellent detective work. If I might ask, how did you trace
the module loads and successful inits?
Heh, you're expecting me to name magic tracing tools? Well (shuffles
feet) I just put printks in kernel/modules.c to do it.
On Sat, 2011-04-16 at 14:07 -0400, John David Anglin wrote:
I posted this debian bug report because the most recent debian
SMP kernel build fails to boot on my rp3440:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622997
I don't think debian kernels have worked since lenny.
Hmm, well
On Sat, 2011-04-16 at 15:29 -0400, John David Anglin wrote:
On Sat, 2011-04-16 at 14:07 -0400, John David Anglin wrote:
I posted this debian bug report because the most recent debian
SMP kernel build fails to boot on my rp3440:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622997
On Sat, 2011-04-16 at 15:48 -0500, James Bottomley wrote:
On Sat, 2011-04-16 at 15:29 -0400, John David Anglin wrote:
On Sat, 2011-04-16 at 14:07 -0400, John David Anglin wrote:
I posted this debian bug report because the most recent debian
SMP kernel build fails to boot on my rp3440
On Sat, 2011-04-16 at 19:35 -0400, John David Anglin wrote:
On Sat, 16 Apr 2011, James Bottomley wrote:
Strike that one ... I enabled USB in my 2.6.39-rc3 build and it inserts
the OHCI module and discovers the ports just fine.
Boot 2.6.39-rc3 fails for me with attached config.
I can't
On Tue, 2010-04-06 at 08:37 -0500, James Bottomley wrote:
(5) Child process B is waken up and sees old value at x in
oldpage,
through different cache line. B sleeps.
This isn't possible. at this point, A and B have the same virtual
address and mapping for oldpage this means
to the memory that causes the fault.
Thanks for writing and testing a patch.
The case of #561203 is second scenario. I think that this case is
relevant to VIVT-WB machine too (provided kernel does copy by kernel
address).
James Bottomley wrote:
So this is going to be a hard sell because
On Sun, 2010-04-04 at 22:51 -0400, John David Anglin wrote:
Thanks a lot for the discussion.
James Bottomley wrote:
So your theory is that the data the kernel sees doing the page copy can
be stale because of dirty cache lines in userspace (which is certainly
possible
by binutils outputting duplicate .text
section names. However, this trips a panic on boot because kernel/modules.c
has insufficient error checking for this case
Patches to fix this are
From 1b364bf438cf337a3818aee77d68c0713f3e1fc4 Mon Sep 17 00:00:00 2001
From: James Bottomley james.bottom
On Sat, 2009-08-15 at 19:21 +0100, Ben Hutchings wrote:
On Sat, 2009-08-15 at 10:47 -0700, james.bottom...@hansenpartnership.com
wrote:
Package: linux-image-2.6.30-1-686
Version: 2.6.30-5
Severity: serious
Justification: Policy 2.2.1
That very same section explains why we cannot do
OK, so lets go back to basics here.
The point of a bug report is to report a bug. The Bug here is that
large numbers of systems will break on upgrade to this kernel once it
hits stable. This is the problem that needs fixing.
The fact that you find the suggested fix politically incorrect, or
On Wed, 2009-05-06 at 16:19 +0200, maximilian attems wrote:
[4194023.390744] [ cut here ]
[4194023.448362] WARNING: at
/build/buildd-linux-2.6_2.6.29-3-alpha-bvFcox/linux-2.6-2.6.29/debian/build/source_alpha_none/kernel/so
Is there any way we can get what that file
On Tue, 2008-09-09 at 10:58 -0600, dann frazier wrote:
On Mon, Sep 08, 2008 at 11:58:22AM -0500, James Bottomley wrote:
On Mon, 2008-09-08 at 18:37 +0200, Bastian Blank wrote:
On Sat, Sep 06, 2008 at 10:06:26AM -0500, James Bottomley wrote:
Parisc is a CONFIG_GEN_RTC architecture (we use
On Tue, 2008-09-09 at 19:38 +0200, Bastian Blank wrote:
On Tue, Sep 09, 2008 at 10:58:35AM -0600, dann frazier wrote:
fyi, I've got an hppa build in progress - disabling RTC_CLASS causes
the symbols below to be removed (essentially, ^rtc_*)
The whole new-style rtc support.
But it doesn't
On Tue, 2008-09-09 at 20:01 +0200, Bastian Blank wrote:
On Tue, Sep 09, 2008 at 12:48:35PM -0500, James Bottomley wrote:
They certainly have to be inessential to the parisc ABI ... they don't
work if anything's actually trying to use them.
Really? Which sort of don't work is this? Why
On Tue, 2008-09-09 at 20:29 +0200, Bastian Blank wrote:
On Tue, Sep 09, 2008 at 01:12:01PM -0500, James Bottomley wrote:
On Tue, 2008-09-09 at 20:01 +0200, Bastian Blank wrote:
On Tue, Sep 09, 2008 at 12:48:35PM -0500, James Bottomley wrote:
They certainly have to be inessential
On Mon, 2008-09-08 at 18:37 +0200, Bastian Blank wrote:
On Sat, Sep 06, 2008 at 10:06:26AM -0500, James Bottomley wrote:
Parisc is a CONFIG_GEN_RTC architecture (we use the generic real time
clock driver).
Well.
Starting with 2.6.26, debian is now enabling
Package: linux-image-2.6.24-1-parisc
Version: 2.6.24-5
Severity: critical
Tags: patch
Justification: breaks the whole system
This actually isn't just a bug in debian, it affects every distro which
uses the stable tree as a base
for instance, the gentoo bug is here:
Package: linux-image-2.6.24-1-parisc64
Version: 2.6.24-5
Severity: critical
Tags: patch
Justification: breaks the whole system
The parisc 64 bit kernel panics on boot with this:
CC net/ipv4/netfilter/iptable_raw.mod.o
CC net/ipv4/tcp_diag.mod.o
CC net/ipv4/tunnel4.mod.o
On Wed, 2007-05-16 at 14:36 +0100, Leigh Blackwell wrote:
I have been looking at the issue with theses cerc devices, has this
bug 374792 been closed based on people reverting the firmware to 6.61.
Unfortunately Dell doesn't support a Firmware version that old on our
Server, is it
On Sun, 2006-10-08 at 14:40 -0700, Matt Taggart wrote:
dann frazier writes...
hey Grant/James,
It looks like we're still having cpqarray/sym2 conflicts under
2.6.18 - any idea what this problem may be?
This is for dl380. At the very bottom (after the close of the bug) of
This is a reference implementation with the debian mkinitrd-tools
package. It shows how to identify the firmware files necessary for
drivers in the initrd and also includes a primitive system for loading
them.
I've tested this with the aic94xx driver using the new MODULE_FIRMWARE()
tag.
On Tue, 2006-08-29 at 01:04 +0200, Sven Luther wrote:
Notice that mkinitrd-tools is dead, and will probably be removed from etch.
mkinitramfs-tools and yaird are the two currently used tools.
Yes ... I'm aware of that. That's why this is a reference
implementation. initramfs should be
On Fri, 2006-08-18 at 12:39 -0400, Kyle McMartin wrote:
The problem is because they both claim support for the same PCI Ids:
That's this fix, isn't it?
http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git;a=commit;h=b2b3c121076961333977f485f0d54c22121df920
James
--
To
On Sun, 2005-11-20 at 21:21 -0500, Graham Knap wrote:
Sure enough, the kernel now boots. I'll attach the dmesg output here.
Do you guys have a final patch in mind?
Let me know if there are other tests you'd like me to run. Now that I
know how to do this, I should be able to turn around
On Sun, 2005-11-13 at 12:41 -0500, Doug Ledford wrote:
If the drive is unaccessible after the DV failure, even on a warm reboot
(which includes a SCSI bus reset), then the drive is flat hung.
Something done in the current code is breaking it. Can you get a boot
with DV turned off and
On Sun, 2005-11-13 at 13:03 -0500, Graham Knap wrote:
Doug Ledford [EMAIL PROTECTED] wrote:
You already said it didn't help with the problem,
I meant that I don't think I successfully disabled DV, because the boot
messages were *identical*, except for the line where the kernel shows
the
On Sun, 2005-11-13 at 14:42 -0500, Doug Ledford wrote:
The device is on a non-LVD bus. Certain devices were created back when
the spec still stated that using PPR negotiation messages on a non-LVD
bus was a no-no. As the echo buffer was an addition to support DV, and
originally DV wasn't
On Tue, 2005-11-08 at 20:47 -0500, Graham Knap wrote:
Target 0 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Goal: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
Curr: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
That's a bit
revision as 1.34.3 during POST.
Any help would be much appreciated.
Hi Graham,
thanks for your detailed report. This does smell a lot like a driver
bug, and as such, its proably best passed onto the upstream maintainers.
As such I've CCed James Bottomley and linux-scsi for comment
41 matches
Mail list logo
