Re: [Pkg-xen-devel] oldschool xen kernel on sid

[Thomas Goirand]

Bastian Blank wrote:
> On Tue, Oct 27, 2009 at 10:32:52PM +0100, Bastian Blank wrote:
>> On Tue, Oct 27, 2009 at 10:05:45PM +0100, Thomas Schwinge wrote:
>>> Bastian, is any of your Xen dom0 work available somewhere?
>> Yes. http://hermes.jura.uni-tuebingen.de/~blank/debian/xen-test.
> 
> The xen utils are currently not able to cope with this modular
> distribution config, so the following should give you running xend and
> the possibility to run domains.
> 
> | modprobe evtchn
> | modprobe xenfs  
> | modprobe blkbk 
> | modprobe netbk
> | mount -t xenfs none /proc/xen
> | /etc/init.d/xend start
> 
> Bastian

Hi Bastian,

Would this kernel work as a dom0 in Lenny? I would need it in my laptop
(not in production...), as otherwise I can't have wifi (I have an Intel
5300 board...). Can you also provide the source package so I can
recompile it with the Lenny gcc/libs?

Thanks for this great work.

Thomas


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#552610: modinfo: could not find module /lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/sound/core/snd.ko

[Stepan Golosunov]

Package: linux-2.6
Version: 2.6.31-1
Severity: important

When installing on lenny, linux-image-2.6.31-1-amd64 generates
lots of warnings with wrong modules paths.
Looks like firmware check is not working.

Распаковывается пакет linux-image-2.6.31-1-amd64 (из файла 
.../linux-image-2.6.31-1-amd64_2.6.31-1_amd64.deb)...
Настраивается пакет linux-image-2.6.31-1-amd64 (2.6.31-1) ...
Running depmod.
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/net/ipv4/tcp_diag.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/net/ipv4/inet_diag.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/net/tun.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/arch/x86/kvm/kvm-intel.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/arch/x86/kvm/kvm.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/char/ppdev.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/parport/parport_pc.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/char/lp.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/parport/parport.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/net/bridge/bridge.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/fs/fuse/fuse.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/block/loop.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/sound/pci/hda/snd-hda-intel.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/sound/core/snd-pcm.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/sound/core/seq/snd-seq.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/sound/core/snd-timer.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/input/serio/serio_raw.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/sound/core/seq/snd-seq-device.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/i2c/busses/i2c-i801.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/input/misc/pcspkr.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/input/mouse/psmouse.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/sound/core/snd.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/i2c/i2c-core.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/acpi/button.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/sound/soundcore.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/char/agp/intel-agp.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/sound/core/snd-page-alloc.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/input/evdev.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/fs/ext3/ext3.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/fs/jbd/jbd.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/fs/mbcache.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/md/dm-mirror.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/md/dm-log.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/md/dm-snapshot.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/md/dm-mod.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/ata/ata_generic.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/scsi/sg.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel/drivers/scsi/sr_mod.ko
modinfo: could not find module 
/lib/modules/2.6.31-1-amd64//lib/modules/2.6.31-1-amd64/kernel

Bug#542614: linux-image-2.6.26-2-xen-amd64: processes hung on high load

[Imre Oolberg]

Hi!

I run into more-or-less same sequence of events using Lenny this fall.
Last time my guest hang with messages similar to those described in this
 bug report was using kernel image

linux-image-2.6.26-2-xen-amd64_2.6.26-19_amd64.deb

Hardware platform is HP DL 585 (Quad-Core AMD Opteron(tm) Processor
8354). But before it happened before with different HP DL, cant remember
exact model, also (that time guests kept on working but dom0 was
inaccessible).

I have tried it with latest Lenny kernel, i.e. 2.6.26-19lenny1 bus from
changelog i didnt see any changes referring in this field.

First of all i wanted to say that i am thankful Debian user as it is but
if i may ask does this bug seem to bother lots of other Lenny users too
and if there are any known workarounds to this or better yet fix on the
way?

This bug touches me much and though i dont unfortunately code myself if
i can be of help testing something, i would gladly do so!


Best regards,

Imre



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#552422: linux-2.6 2.6.31-1 FTBFS on mipsel

[Aurelien Jarno]

On Mon, Oct 26, 2009 at 09:04:32PM +0100, Aurelien Jarno wrote:
> On Mon, Oct 26, 2009 at 12:58:25PM -0600, dann frazier wrote:
> > On Mon, Oct 26, 2009 at 11:03:27AM +0100, Aurelien Jarno wrote:
> > > Martin Michlmayr a écrit :
> > > > * Andreas Barth  [2009-10-26 07:22]:
> > > >> Package: linux-2.6
> > > >> Version: 2.6.31-1
> > > >> Severity: serious
> > > > 
> > > >> this package FTBFS on mipsel:
> > > >>   MODPOST vmlinux.o
> > > >>   GEN .version
> > > >>   CHK include/linux/compile.h
> > > >>   UPD include/linux/compile.h
> > > >>   CC  init/version.o
> > > >>   LD  init/built-in.o
> > > >>   LD  .tmp_vmlinux1
> > > >> ld:arch/mips/kernel/vmlinux.lds:168: syntax error
> > > > 
> > > > Aurelien, can you take a look at this?
> > > 
> > > I'll try to have a look, but I don't know when. There are plenty of RC
> > > bugs on eglibc to fix first.
> > 
> > Could it be this? I don't have hardware to test.
> 
> It will most probably fix the problem. I have started a build.

Good catch, I confirm it fixes the problem.


> > commit d71789b6fa37c21ce5eb588d279f57904a62e7e2
> > Author: Manuel Lauss 
> > Date:   Thu Sep 24 21:44:24 2009 +0200
> > 
> > mips: fix build of vmlinux.lds
> > 
> > Commit 51b563fc93c8cb5bff1d67a0a71c374e4a4ea049 ("arm, cris, mips,
> > sparc, powerpc, um, xtensa: fix build with bash 4.0") removed a few
> > CPPFLAGS with vital include paths necessary to build vmlinux.lds
> > on MIPS, and moved the calculation of the 'jiffies' symbol
> > directly to vmlinux.lds.S but forgot to change make ifdef/... to
> > cpp macros.
> > 
> > Signed-off-by: Manuel Lauss 
> > [sam: moved assignment of CPPFLAGS arch/mips/kernel/Makefile]
> > Signed-off-by: Sam Ravnborg 
> > Acked-by: Dmitri Vorobiev 
> > 
> > diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
> > index e961221..eecd2a9 100644
> > --- a/arch/mips/kernel/Makefile
> > +++ b/arch/mips/kernel/Makefile
> > @@ -2,6 +2,8 @@
> >  # Makefile for the Linux/MIPS kernel.
> >  #
> >  
> > +CPPFLAGS_vmlinux.lds := $(KBUILD_CFLAGS)
> > +
> >  extra-y:= head.o init_task.o vmlinux.lds
> >  
> >  obj-y  += cpu-probe.o branch.o entry.o genex.o irq.o process.o 
> > \
> > diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
> > index 9bf0e3d..162b299 100644
> > --- a/arch/mips/kernel/vmlinux.lds.S
> > +++ b/arch/mips/kernel/vmlinux.lds.S
> > @@ -11,15 +11,15 @@ PHDRS {
> > note PT_NOTE FLAGS(4);  /* R__ */
> >  }
> >  
> > -ifdef CONFIG_32BIT
> > -   ifdef CONFIG_CPU_LITTLE_ENDIAN
> > +#ifdef CONFIG_32BIT
> > +   #ifdef CONFIG_CPU_LITTLE_ENDIAN
> > jiffies  = jiffies_64;
> > -   else
> > +   #else
> > jiffies  = jiffies_64 + 4;
> > -   endif
> > -else
> > +   #endif
> > +#else
> > jiffies  = jiffies_64;
> > -endif
> > +#endif
> >  
> >  SECTIONS
> >  {
> > 
> > 
> > 
> > -- 
> > dann frazier
> > 
> > 
> 
> -- 
> Aurelien Jarno  GPG: 1024D/F1BCDB73
> aurel...@aurel32.net http://www.aurel32.net

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#552142: Acknowledgement (linux-image-2.6.26-2-686: machine hangs with nf_conntrack: table full, dropping packet - needs hard reboot)

[Toni Mueller]

On Sat, 24.10.2009 at 09:28:22 +0200, Bastian Blank  wrote:
> The buckets are created during module loading. But /etc/sysctl.conf is
> evaluated earlier. Aren't you seeing errors about unknown keys during
> boot?

I'll have to check that, probably RSN, but in the meantime, I got
confused by your explanation and my tour of the file system. While it
was counter-intuitive right from the start that modules should be
loaded after sysctl tried to use them, I see this in /etc/rcS.d:

S20module-init-tools
S30procps

S30procps is the script where /etc/sysctl.conf gets evaluated, so it
seems to me that /etc/sysctl.conf already gets evaluated *after*, not
before, modules were loaded.


-- 
Kind regards,
--Toni++




-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Pkg-xen-devel] oldschool xen kernel on sid

[Thomas Schwinge]

Hello!

Low-res pictures are on .
Sorry, I don't have anything better at the moment, but I'll explain them
below.

On Tue, Oct 27, 2009 at 11:55:33PM +0100, Bastian Blank wrote:
> On Tue, Oct 27, 2009 at 11:15:13PM +0100, Thomas Schwinge wrote:
> > At this point, nothing is mounted on /root -- it's supposed to be an ext3
> > filesystem based on a LVM LV.  And the very strange thing is that
> > /dev/mapper/ does contain only one LV device, and that is the swap LV
> > (254,0), but not the root filessystem one.
> 
> Please provide the complete log and the bootloader config.

GRUB2:

menuentry "Xen 3.4, Debian GNU/Linux, Linux 2.6.31-1-xen-amd64" {
insmod lvm
insmod ext2
set root=(vg0-boole-root)
search --no-floppy --fs-uuid --set 54ccee0d-3455-43dc-af2e-e2bb3940776a
multiboot /boot/xen-3.4-amd64.gz noreboot
module /boot/vmlinuz-2.6.31-1-xen-amd64 
root=/dev/mapper/vg0-boole--root ro
module /boot/initrd.img-2.6.31-1-xen-amd64
}

03.jpg, 07.jpg: Dropped into the BusyBox shell.

08.jpg, 09.jpg: mount output (nothing on /root); ls -l /dev/mapper/ (only
control and vg0-boole--swap (254,0)); lvm vgchange -ay; ls -l
/dev/mapper/ (control, vg0-boole--data (254,2), vg0-boole--root (254,1),
vg0-boole--swap (254,0).

> > If I manually run ``lvm
> > vgchange -ay'' the missing LVs appear, root (254,1) and data (254,2).
> > How would I manually resume the booting process from here?
> 
> mount $dev /root
> CTRL-D
> 
> should do it.

10.jpg: fstype vg0-boole-root (ext3); mount /dev/mapper/vg0-boole--root
/root (failed -- no such file or directory?!).

> > The exactly same arrangement boots without any problems with a non-Xen
> > kernel.  This is a up-to-date Debian testing, by the way.  Help?
> 
> I doubt that.

11.jpg: successful boot without Xen; here the device number are
different: vg0-boole--data (254,2), vg0-boole--root (254,0),
vg0-boole--swap (254,1) -- root has minor zero instead of one, and swap
vice versa?!


Regards,
 Thomas


signature.asc
Description: Digital signature

Bug#552270: Marvell CESA driver and Kirkwood

[Karsten König]

Thanks Martin.

Am Dienstag, 27. Oktober 2009 14:16:04 schrieb Martin Michlmayr:
> I got the following answer, so I'll go ahead and enable CESA for
> Kirkwood.
> 
> * Sebastian Andrzej Siewior  [2009-10-26 22:53]:
> > * Martin Michlmayr | 2009-10-26 18:26:08 [+0800]:
> > >Hi Sebastian and Nico,
> >
> > Hi Martin,
> >
> > >I put Sebastian's CESA driver into Debian's 2.6.31 kernel and enabled
> > >it for orion5x.  A Debian user asked me why I didn't enable it for
> > >Kirkwood.  AFAIK, there are some differences between the CESA on
> > >Orion5x and Kirkwood, so my assumption was that the current CESA
> > >driver doesn't work on Kirkwood.  But I'm actually not sure if this is
> > >true.
> > >
> > >Do you know if the current driver will work on Kirkwood?
> >
> > I don't really know. I just looked through the spec and compared them
> > and they look very alike:
> > - Orion's has larger sram space. The driver does not assume, it uses the
> >   size specified and Kirkwood's is set to 2KiB
> > - the register seem to be at the same spot. Orion has two engines,
> >   Kirkwood just one. Right now, only the first one is used.
> > - security engine's descriptor looks the same
> > - the DMA engine differs in a few spot but it is not yet implemented so
> >   it doesn't matter.
> >
> > As far as I can see in current git, Nico enabled the CESA engine on
> > Kirkwood [0]. It looks like he assumes that it should work, I don't know
> > if he ever has tested it :)
> >
> > [0]
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit
> >;h=ae5c8c83735f5fcb09b380944e4854a383006998 Sebastian
> 



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#517586: Found in 2.6.26-2-amd64

[Richard Hughes]

As a follow up to my previous e-mail, I set highres=off on the kernel
command line on a hunch, and the machine has been up for 22 days now.
It looks like that made the problem go away, but that may just be
because the offending code is called less.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Pkg-xen-devel] oldschool xen kernel on sid

[Bastian Blank]

On Tue, Oct 27, 2009 at 11:15:13PM +0100, Thomas Schwinge wrote:
> At this point, nothing is mounted on /root -- it's supposed to be an ext3
> filesystem based on a LVM LV.  And the very strange thing is that
> /dev/mapper/ does contain only one LV device, and that is the swap LV
> (254,0), but not the root filessystem one.

Please provide the complete log and the bootloader config.

> If I manually run ``lvm
> vgchange -ay'' the missing LVs appear, root (254,1) and data (254,2).
> How would I manually resume the booting process from here?

mount $dev /root
CTRL-D

should do it.

> The exactly same arrangement boots without any problems with a non-Xen
> kernel.  This is a up-to-date Debian testing, by the way.  Help?

I doubt that.

Bastian

-- 
I'm frequently appalled by the low regard you Earthmen have for life.
-- Spock, "The Galileo Seven", stardate 2822.3


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#552422: linux-2.6 2.6.31-1 FTBFS on mipsel

[Martin Michlmayr]

* Aurelien Jarno  [2009-10-27 10:10]:
> > It will most probably fix the problem. I have started a build.
> 
> Good catch, I confirm it fixes the problem.

Excellent.  Thanks to the both of you.
-- 
Martin Michlmayr
http://www.cyrius.com/



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: tagging 552270

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # Automatically generated email from bts, devscripts version 2.10.35lenny7
> tags 552270 + pending
Bug #552270 [linux-2.6] orion5x crypto module not enabled
Added tag(s) pending.
>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: oldschool xen kernel on sid

[Thomas Schwinge]

Hello!

On Tue, Oct 27, 2009 at 10:32:52PM +0100, Bastian Blank wrote:
> On Tue, Oct 27, 2009 at 10:05:45PM +0100, Thomas Schwinge wrote:
> > Bastian, is any of your Xen dom0 work available somewhere?
> 
> Yes. http://hermes.jura.uni-tuebingen.de/~blank/debian/xen-test.

Thanks!  That one boots (don't specify console=...) -- but then also gets
dropped into the BusyBox shell due to ``No init found.'' -- the same
which I also saw with another kernel, and which independently was
reported at
.

At this point, nothing is mounted on /root -- it's supposed to be an ext3
filesystem based on a LVM LV.  And the very strange thing is that
/dev/mapper/ does contain only one LV device, and that is the swap LV
(254,0), but not the root filessystem one.  If I manually run ``lvm
vgchange -ay'' the missing LVs appear, root (254,1) and data (254,2).
How would I manually resume the booting process from here?

The exactly same arrangement boots without any problems with a non-Xen
kernel.  This is a up-to-date Debian testing, by the way.  Help?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [Pkg-xen-devel] oldschool xen kernel on sid

[Bastian Blank]

On Tue, Oct 27, 2009 at 10:32:52PM +0100, Bastian Blank wrote:
> On Tue, Oct 27, 2009 at 10:05:45PM +0100, Thomas Schwinge wrote:
> > Bastian, is any of your Xen dom0 work available somewhere?
> Yes. http://hermes.jura.uni-tuebingen.de/~blank/debian/xen-test.

The xen utils are currently not able to cope with this modular
distribution config, so the following should give you running xend and
the possibility to run domains.

| modprobe evtchn
| modprobe xenfs  
| modprobe blkbk 
| modprobe netbk
| mount -t xenfs none /proc/xen
| /etc/init.d/xend start

Bastian

-- 
Another dream that failed.  There's nothing sadder.
-- Kirk, "This side of Paradise", stardate 3417.3


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: Bug handling policy

[Ben Hutchings]

On Tue, 2009-10-27 at 11:10 -0600, dann frazier wrote:
[...]
> > 2. Severities
> > 
> > Many submitters believe that their bug meets one of the following
> > criteria for high severity.  We interpret them as follows and will
> > downgrade as appropriate:
> 
> Though infrequent, we do sometimes need to "upgrade" severities as
> well. Maybe we can say "adjust as appropriate" vs. downgrade? I know
> this section is about bloated severities, but it might work better as
> a "here's how we interpret severities" section.

Agreed.

[...]
> > 3. Tagging
> > 
> > We do not use user-tags, but in order to aid bug triage we should:
> > 
> > * Add 'moreinfo' whenever we are waiting for a response from the
> >   submitter and remove it when we are not.
> > * Add 'upstream', 'fixed-upstream', 'patch', 'help' where appropriate
> 
> You could also add 'forwarded' to this list - though, you might also
> be able to do away with this bullet and complete this section with
> "other tags should be used as defined by the bug tracking system"
> instead of calling out well-defined tags.

I'll do that.

> > * Not add 'unreproducible', since bugs are commonly hardware-dependent
>   
> Though, sometimes bugs aren't hardware dependent - and unreproducible
> makes sense. Maybe "Not add 'unreproducible' in cases where the bug
> maybe hardware dependent"?

Right.

> > 5. Testing by submitter
> > 
> > Depending on the technical sophistication of the submitter and the
> > service requirements of the system in question (e.g. whether it's a
> > production server) we can request one or more of the following:
> > 
> > * Gathering more information passively (e.g. further logging, reporting
> >   contents of files in procfs or sysfs)
> > * Upgrading to the current stable/stable-proposed-updates/
> >   stable-security version, if it includes a fix for a similar bug
> > * Adding debug or fallback options to the kernel command line or
> >   module parameters
> > * Installing the unstable [or backports?] version temporarily
> > * Rebuilding and installing the kernel with a specific patch added
> >   [I think we should add a script to the source to make this easier]
> > 
> > When a bug occurs in what upstream considers the current or previous
> > stable release, and we cannot fix it, we ask the submitter to report it
> > upstream at bugzilla.kernel.org under a specific Product and Component,
> > and to tell us the upstream bug number.  We do not report bugs directly
> > because follow-up questions from upstream need to go to the submitter,
> > not to us.  Given the upstream bug number, we mark the bug as forwarded.
> > bts-link then updates its status.
> 
> We tried to capture a lot of the common user-triage processes here:
>  http://wiki.debian.org/DebianKernelReportingBugs
> 
> Maybe we could update that/reference it in this doc?

I'll try to merge the two.

> > 6. Keeping bugs separate
> > 
> > Many submitters search for a characteristic error message and treat this
> > as indicating a specific bug.  This can lead to many 'me too' follow-ups
> > where, for example, the message indicates a driver bug and the second
> > submitter is using a different driver from the original submitter.  We
> > should try to respond to such a follow-up quickly, requesting a separate
> > bug report.  Otherwise the original report is likely to turn into a mess
> > of conflicting information about two or more different bugs.
> >
> > Where the original report describes more than one bug ('...and other
> > thing...'), we should clone it and deal with each separately.
> 
> It might be valuable to just close any bugs that have gotten
> confusing overtime and clone a new bug for each *real* issue described
> within, with a good explanation that helps prevent confusion.
> "JUST BECAUSE YOU ARE SEEING A SOFT LOCKUP DOES NOT MEAN THIS IS YOUR
> BUG".
[...]

Another option may be to use the new 'summary' command
.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett


signature.asc
Description: This is a digitally signed message part

Re: Building vanilla kernel .debs

[Ben Hutchings]

On Tue, 2009-10-27 at 09:51 +0100, Marc Haber wrote:
> Hi,
> 
> On Mon, Oct 26, 2009 at 10:19:31PM +, Ben Hutchings wrote:
> > On Mon, 2009-10-26 at 21:27 +0100, Marc Haber wrote:
> > > Is it a feature that the linux-firmware package doesn't have the
> > > upstream kernel version in its name?
> > 
> > Possibly not.
> 
> Shall I file a wishlist bug or has this already been noted?

Please do, and clarify which package you are talking about
(firmware-linux-free or linux-firmware-image).

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett


signature.asc
Description: This is a digitally signed message part

Re: oldschool xen kernel on sid

[Bastian Blank]

On Tue, Oct 27, 2009 at 10:05:45PM +0100, Thomas Schwinge wrote:
> Bastian, is any of your Xen dom0 work available somewhere?

Yes. http://hermes.jura.uni-tuebingen.de/~blank/debian/xen-test.

3650d42842e0f19362134299a66c3e95159989676d1a721dbdfbddf3746dcd31  
linux-image-2.6.31-1-xen-686_2.6.31-1_i386.deb
3b51d61f3e21783f02f71d45fc57bd1a33660f05ccc7987bbd1ebd9dd2aeea12  
linux-image-2.6.31-1-xen-amd64_2.6.31-1_amd64.deb
bbf4de60b7e1eb9fa684da282e929b46b5420fc5fc42e70e7f335d63409b52e5  
xen-pvops.patch

Bastian

-- 
Change is the essential process of all existence.
-- Spock, "Let That Be Your Last Battlefield", stardate 5730.2


signature.asc
Description: Digital signature

Re: oldschool xen kernel on sid

[Thomas Schwinge]

Hello!

In an attempt to finally get a recent Xen dom0 kernel booted on this
pesky amd64 system (see

for the (short) story), I wanted to give this one one a try:

Marco Nenciarini  wrote:
> I've applied latest forward ported patches from
> 
> http://code.google.com/p/gentoo-xen-kernel/downloads/list
> 
> to the 2.6.31 experimental package.
> The resulting kernel works well for me (at least on amd64 arch).
> 
> Fell free to reuse my little work
> http://www.prato.linux.it/~mnencia/xen/oldschool-xen-2.6.31-5.patch.bz2

I applied the patch, built the kernel, but it'll crash / reset the system
in the middle of the booting process.  The last thing I can see are some
``NET:'' messages.  How to help debugging this?  Marco, should I perhaps
give your binary packages a try?


Bastian, is any of your Xen dom0 work available somewhere?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Building vanilla kernel .debs

[maximilian attems]

hello David,

I have a question on howto ship firmware build out of
make deb-pkg in linux-2.6.

On Mon, 26 Oct 2009, Ben Hutchings wrote:

> On Mon, 2009-10-26 at 21:27 +0100, Marc Haber wrote:
> > Hi,
> > 
> > 
> > Is it a feature that the linux-firmware package doesn't have the
> > upstream kernel version in its name?
> 
> Possibly not.
> 
> > $ make deb-pkg
> > (...)
> > dpkg-deb: building package linux-firmware-image' in 
> > ../linux-firmware-image_2.6.31.4.20091026.4_all.deb'.
> > dpkg-deb: building package linux-image-2.6.31.4-zgws1' in 
> > ../linux-image-2.6.31.4-zgws1_2.6.31.4.20091026.4_i386.deb'.
> > 
> > I could imagine that, a driver in kernel 2.6.x would need different
> > firmware than the same driver in kernel 2.6.y, where it would be very
> > helpful to have multiple firmware packages installed.
> 
> The linux-firmware repository
> 
> contains multiple versions of some firmware for just this reason.
> However, Linux source trees do not.
> 
> > Does the firmware infrastructure cater for this need?

tried to pass INSTALL_FW_PATH to modules_install call in
scripts/packages/builddep, but this is happily ignored there.

is it an anachronism that the INSTALL_FW_PATH defaults to
$(INSTALL_MOD_PATH)/lib/firmware and not
$(INSTALL_MOD_PATH)/lib/firmware/$(KERNELRELEASE)/


kind regards
max


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#552270: Marvell CESA driver and Kirkwood

[Martin Michlmayr]

I got the following answer, so I'll go ahead and enable CESA for
Kirkwood.

* Sebastian Andrzej Siewior  [2009-10-26 22:53]:
> * Martin Michlmayr | 2009-10-26 18:26:08 [+0800]:
> 
> >Hi Sebastian and Nico,
> Hi Martin,
> 
> >I put Sebastian's CESA driver into Debian's 2.6.31 kernel and enabled
> >it for orion5x.  A Debian user asked me why I didn't enable it for
> >Kirkwood.  AFAIK, there are some differences between the CESA on
> >Orion5x and Kirkwood, so my assumption was that the current CESA
> >driver doesn't work on Kirkwood.  But I'm actually not sure if this is
> >true.
> >
> >Do you know if the current driver will work on Kirkwood?
> I don't really know. I just looked through the spec and compared them
> and they look very alike:
> - Orion's has larger sram space. The driver does not assume, it uses the
>   size specified and Kirkwood's is set to 2KiB
> - the register seem to be at the same spot. Orion has two engines,
>   Kirkwood just one. Right now, only the first one is used.
> - security engine's descriptor looks the same
> - the DMA engine differs in a few spot but it is not yet implemented so
>   it doesn't matter.
> 
> As far as I can see in current git, Nico enabled the CESA engine on
> Kirkwood [0]. It looks like he assumes that it should work, I don't know
> if he ever has tested it :)
> 
> [0] 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ae5c8c83735f5fcb09b380944e4854a383006998
> Sebastian

-- 
Martin Michlmayr
http://www.cyrius.com/



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian Kernel Group Meeting

[Bastian Blank]

On Tue, Oct 27, 2009 at 08:13:27PM +0200, Pasi Kärkkäinen wrote:
> pv_ops dom0 patches will require more maintenance than the forward-ports
> though.. since it's not yet feature-complete, and will have many
> patches and fixes still..

You just won a free maintainership of the forward port in Lenny. The
pv-ops tree only failed to build for me, not crashed during runtime for
me.

Bastian

-- 
We have phasers, I vote we blast 'em!
-- Bailey, "The Corbomite Maneuver", stardate 1514.2


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian Kernel Group Meeting

[Pasi Kärkkäinen]

On Fri, Oct 23, 2009 at 10:27:28AM +0100, Ian Campbell wrote:
> On Fri, 2009-10-23 at 11:06 +0200, Bastian Blank wrote:
> > On Fri, Oct 23, 2009 at 08:53:39AM +0100, Ian Campbell wrote:
> > > On Wed, 2009-10-21 at 11:45 +0200, Bastian Blank wrote: 
> > > > On Thu, Oct 15, 2009 at 01:31:06PM +0100, Vincent Sanders wrote:
> > > > > xen dom 0
> > > > > +
> > > Are you basing your patch on the PV-ops tree or on one of the SuSE
> > > forward ports? Based on your recent posts to xen-devel I had assumed the
> > > former but Ben's initial post suggested perhaps the later.
> > 
> > It is based on the pv-ops tree.
> 
> Excellent, I think that's the right choice. If there is anything I can
> do to help please let me know.
> 

Ok, so squeeze will have pv_ops dom0 kernel. I thought it'd be
forward-port.. sorry for the confusion.

pv_ops dom0 patches will require more maintenance than the forward-ports
though.. since it's not yet feature-complete, and will have many
patches and fixes still..

-- Pasi


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: Bug handling policy

[dann frazier]

On Sat, Oct 17, 2009 at 05:14:54PM +0100, Ben Hutchings wrote:
> I've drafted a policy based on what I believe to be best practice.
> Please comment - is anything wrong, or anything missing?  I also left
> some questions in square brackets.
> 
> Ben.

Thanks Ben, comments below.

> ---
> 
> 1. Required information
> 
> Submitters are expected to run reportbug or other tool that runs our
> 'bug' script under the kernel version in question.  The response to
> reports without this information should be a request to follow-up using
> reportbug.  If we do not receive this the bug may be closed [after how
> long?].

1 month seems reasonable to me. reopening isn't hard.

> Exceptions:
> * If the kernel does not boot or is very unstable, instead of the usual
>   system information we need the console messages in a clear photograph
>   or via serial console or netconsole (or even retyping as a last
>   resort).  Ask the submitter to remove 'quiet' and add 'vga=6' (where
>   applicable) to the kernel command line.
> * If the report is relaying information about a bug acknowledged
>   upstream, we do not need system information but we do need specific
>   references (bugzilla.kernel.org or git commit id).
> * If the bug is clearly not hardware-specific (e.g. packaging error), we
>   do not need system information.
> 
> 2. Severities
> 
> Many submitters believe that their bug meets one of the following
> criteria for high severity.  We interpret them as follows and will
> downgrade as appropriate:

Though infrequent, we do sometimes need to "upgrade" severities as
well. Maybe we can say "adjust as appropriate" vs. downgrade? I know
this section is about bloated severities, but it might work better as
a "here's how we interpret severities" section.

> 
> 'critical: makes unrelated software on the system (or the whole system)
> break...'
>The bug must make the kernel unbootable or unstable on common
>hardware or all systems that a specific flavour is supposed to
>support.  There is no 'unrelated software' since everything
>depends on the kernel.
> 
> 'grave: makes the package in question unusable or mostly so...'
>If the kernel is unusable, this already qualifies as critical.
> 
> [Alternately: given that the user can normally reboot into an earlier
> kernel version, does that mean the bug is 'grave', not 'critical'?]
> 
> 'grave: ...or causes data loss...'
>We exclude loss of data in memory due to a crash.  Only corruption
>of data in storage or communication, or silent failure to write data,
>qualifies.

important: adds previously unsupported hardware support

> 3. Tagging
> 
> We do not use user-tags, but in order to aid bug triage we should:
> 
> * Add 'moreinfo' whenever we are waiting for a response from the
>   submitter and remove it when we are not.
> * Add 'upstream', 'fixed-upstream', 'patch', 'help' where appropriate

You could also add 'forwarded' to this list - though, you might also
be able to do away with this bullet and complete this section with
"other tags should be used as defined by the bug tracking system"
instead of calling out well-defined tags.

> * Not add 'unreproducible', since bugs are commonly hardware-dependent
  
Though, sometimes bugs aren't hardware dependent - and unreproducible
makes sense. Maybe "Not add 'unreproducible' in cases where the bug
maybe hardware dependent"?

> 4. Analysis by maintainers
> 
> Generally we should not expect to be able to reproduce bugs without
> having similar hardware.  We should consider:
> 
> * Searching bugzilla.kernel.org (including closed bugs) or other
>   relevant bug tracker
> * Searching kernel mailing lists (of the many archives,
>   http://news.gmane.org seems to suck least)
> * Viewing git commit logs for relevant source files
>   - In case of a regression, from the known good to the bad version
>   - In other cases, from the bad version forwards, in case the bug
> has been fixed since
> * Searching kerneloops.org for similar oopses
> * Matching the machine code and registers in an 'oops' against the
>   source and deducing how the impossible happened (this doesn't work
>   that often but when it does you look like a genius ;-)
> 
> 5. Testing by submitter
> 
> Depending on the technical sophistication of the submitter and the
> service requirements of the system in question (e.g. whether it's a
> production server) we can request one or more of the following:
> 
> * Gathering more information passively (e.g. further logging, reporting
>   contents of files in procfs or sysfs)
> * Upgrading to the current stable/stable-proposed-updates/
>   stable-security version, if it includes a fix for a similar bug
> * Adding debug or fallback options to the kernel command line or
>   module parameters
> * Installing the unstable [or backports?] version temporarily
> * Rebuilding and installing the kernel with a specific patch added
>   [I think we should add a script to the source to make this easier]
> 
> When a bug 

Re: Handling of EMBEDDED

[Bastian Blank]

On Wed, May 20, 2009 at 06:01:28PM +0200, Bastian Blank wrote:
> There are several options to fix this problem:
> - Remove the "select" definition and never set EMBEDDED.

Okay, there was no response, so I decided to do it this way. This will
make the config files not reproducible with upstream sources, but makes
our work much easier.

Bastian

-- 
The face of war has never changed.  Surely it is more logical to heal
than to kill.
-- Surak of Vulcan, "The Savage Curtain", stardate 5906.5


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Building vanilla kernel .debs

[Marc Haber]

Hi,

On Mon, Oct 26, 2009 at 10:19:31PM +, Ben Hutchings wrote:
> On Mon, 2009-10-26 at 21:27 +0100, Marc Haber wrote:
> > Is it a feature that the linux-firmware package doesn't have the
> > upstream kernel version in its name?
> 
> Possibly not.

Shall I file a wishlist bug or has this already been noted?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: closing 552296

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # submitter acknowledged error on his part
> close 552296
Bug#552296: Upgrading from linux-image-2.6.26-2-ixp4xx version 2.6.26-17lenny2 
to version 2.6.26-19 hangs nslu2. After upgrading and rebooting the slug has 
only ethernet light in red (fixed, not alternating)
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to Xan 

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#552296: false alarm

[Ben Hutchings]

On Mon, 2009-10-26 at 14:40 +0100, Pierre Maziere wrote:
> It seems that the update switched the /dev/sda and /dev/sdb which
> explains the freeze during the boot sequence.
> I switched the usb plugs and everything is now back to normal.
> sorry for the noise

You should not expect that USB disks will be found and assigned names in
any particular order.  You should specify partitions by label or UUID
instead of device name.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett


signature.asc
Description: This is a digitally signed message part