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 w
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:
# C
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 up
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
* scsi_wait_scan.c
- *
- * Copyright (C) 2006 James Bottomley
- *
- * 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
On Tue, 2011-04-19 at 11:20 +0200, Bartlomiej Zolnierkiewicz wrote:
> From: Bartlomiej Zolnierkiewicz
> 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 driver's m
On Mon, 2011-04-18 at 14:12 +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 18-04-2011 3:58, James Bottomley wrote:
>
> > I've got a parisc system where the DVD drive is hardwired to a silicon
> > image controller:
>
> > 00:02.0 IDE interface: Silicon Ima
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.
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 PCI
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
> > tryi
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
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
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
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
> > > &g
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=
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
'd child never writes
> > 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).
>
>
On Tue, 2010-04-06 at 08:37 -0500, James Bottomley wrote:
> > (5) Child process B is waken up and sees old value at in
> ,
> > through different cache line. B sleeps.
>
> This isn't possible. at this point, A and B have the same virtual
> address and mapping
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 userspac
s actually caused 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 Botto
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 tha
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 c
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 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:
> > >
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? Whi
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 do
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:
> > > &
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
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
CC
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:
http://bugs.gentoo.org/show_b
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 po
On Sun, 2006-10-08 at 21:16 -0600, Grant Grundler wrote:
> I didn't know Compaq used two different 53[cC]510 parts.
> Patch below adds the same tweak to the 0x0010 device ID.
>
> James or willy, this look good to you?
It seems reasonable.
Can we get confirmation from the bug submitter that it ac
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
>
On Tue, 2006-08-29 at 02:35 +0200, Oleg Verych wrote:
> request_firmware() is dead also.
> YMMV, but three years, and there are still big chunks of binary in kernel.
> And please don't add new useless info _in_ it.
I er don't think so.
We (as in the Kernel) are forcing drivers on to this path. Y
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 eas
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. Initramf
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 a
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
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
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 ca
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
e 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.
>
> The other main p
44 matches
Mail list logo
