Bug#439188:

[L.P.H. van Belle]

Package: linux-image-2.6.18-5-k7
Version: 2.6.18.dfsg.1-13etch1



BUG: unable to handle kernel NULL pointer dereference at virtual address
0074
 printing eip:
c016be39
*pde = 
Oops:  [#2]
SMP
Modules linked in: ipt_TCPMSS ipt_recent xt_limit xt_tcpudp ip_nat_irc
ip_nat_ftp iptable_nat iptable_mangle ipt_LOG ipt_MASQUERADE ip_nat ipt_TOS
ipt_REJECT ip_conntrack_irc ip_conntrack_ftp xt_state ip_conntrack nfnetlink
iptable_filter ip_tables x_tables button ac battery dm_crypt dm_snapshot
dm_mirror dm_mod tsdev via_agp shpchp pci_hotplug agpgart rtc parport_pc
via_ircc parport psmouse irda serio_raw crc_ccitt evdev pcspkr ext3 jbd
mbcache ide_generic ide_cd cdrom ide_disk generic uhci_hcd usbcore via82cxxx
ide_core thermal processor fan raid10 raid456 xor raid1 md_mod 3c59x mii
CPU:0
EIP:0060:[]Tainted: G SVLI
EFLAGS: 00010206   (2.6.18-5-k7 #1)
EIP is at time_out_leases+0x33/0x45
eax: db4fce9c   ebx: 0048   ecx: dfa694dc   edx: 
esi: db4fcf40   edi:    ebp: dfa694dc   esp: c3717ea4
ds: 007b   es: 007b   ss: 0068
Process find (pid: 10213, ti=c3716000 task=f7a6b550 task.ti=c3716000)
Stack:  00018801 c016cc42 00018801 db4fce9c db4fce9c 
c3717f3c
   c0165b1a db4fce9c f89418fa 0004 c0165c38 db4fce9c 00018801

   c3717f3c c0166adb db4f7784 c3717f3c  00018801 c3717f3c
c0168af6
Call Trace:
 [] __break_lease+0x55/0x2bf
 [] generic_permission+0x57/0xcc
 [] ext3_permission+0x0/0xa [ext3]
 [] permission+0xa9/0xbc
 [] may_open+0x131/0x20e
 [] open_namei+0x23d/0x5b3
 [] do_filp_open+0x1c/0x31
 [] sys_lstat64+0x1e/0x23
 [] do_sys_open+0x3e/0xb3
 [] sys_open+0x16/0x18
 [] sysenter_past_esp+0x56/0x79
Code: eb 23 8b 4b 44 85 c9 74 09 a1 80 11 31 c0 39 c8 79 04 89 de eb 0f 83
e2 ef 89 f0 e8 cb fe ff ff 3b 1e 0f 44 f3 8b 1e 85 db 74 0f  43 2c 20 74
09 0f b6 53 2d f6 c2 10 75 c8 5b 5e c3 53 89 c3
EIP: [] time_out_leases+0x33/0x45 SS:ESP 0068:c3717ea4


CPU:
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 6
model name  : AMD Athlon(tm) XP 2000+
stepping: 2
cpu MHz : 1673.820
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts
bogomips: 3350.52

PCI: 
00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333]
00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333
AGP]
00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev
78)
00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
(rev 30)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8233A ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1
Controller (rev 23)
00:11.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1
Controller (rev 23)
01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX
400] (rev b2)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reducing number of i386 linux images

[dann frazier]

On Wed, Aug 22, 2007 at 08:20:22PM -0700, Steve Langasek wrote:
> On Wed, Aug 22, 2007 at 09:39:02AM -0400, Kyle McMartin wrote:
> > On Wed, Aug 22, 2007 at 09:18:44AM +0200, maximilian attems wrote:
> > > > I propose the following:
> > > > - Rename 686-bigmem to 686-pae. pae is more than support for much
> > > >   memory, it includes things like NX.
> 
> > > nack
> > > as already told on private channel to many pentium m out there are
> > > don't support pae
> 
> > OTOH, there's little reason to ship a 486 *and* a 686 kernel, probably
> > easiest to just drop the 686 and rename 486 to generic or something.
> 
> Is that based on benchmarks, or on an assessment that non-PAE 686 machines
> are uninteresting?  I would think that if the performance benefit of 686
> over 486 is measurable at all, it's precisely the older systems that benefit
> most from having a separate kernel flavor, in terms of the hardware
> remaining useful.

I hope it will be based on benchmarks - I see no reason to drop any
flavours if there maybe a significant performance benefit for a
significant part of our userbase[1]. I want as many people to run the
official kernel as possible and not to regress to the woody days
where any clueful admin built/ran their own.

In lieu of convincing benchmarks, the default answer should be to
*not* drop flavours. Without numbers, users are going to believe
(rightfully or not) that running Debian's kernel reduces the power
they get from their hardware. That factor is worth the slower build
times and extra disk space.

fwiw, a coworker is looking into the availability of a benchmark that
should be good for comparing pae/non-pae.

[1] whatever that means.

-- 
dann frazier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reducing number of i386 linux images

[Steve Langasek]

On Wed, Aug 22, 2007 at 09:39:02AM -0400, Kyle McMartin wrote:
> On Wed, Aug 22, 2007 at 09:18:44AM +0200, maximilian attems wrote:
> > > I propose the following:
> > > - Rename 686-bigmem to 686-pae. pae is more than support for much
> > >   memory, it includes things like NX.

> > nack
> > as already told on private channel to many pentium m out there are
> > don't support pae

> OTOH, there's little reason to ship a 486 *and* a 686 kernel, probably
> easiest to just drop the 686 and rename 486 to generic or something.

Is that based on benchmarks, or on an assessment that non-PAE 686 machines
are uninteresting?  I would think that if the performance benefit of 686
over 486 is measurable at all, it's precisely the older systems that benefit
most from having a separate kernel flavor, in terms of the hardware
remaining useful.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reorganizing packages

[Steve Langasek]

On Wed, Aug 22, 2007 at 10:49:30PM -0300, Otavio Salvador wrote:
> experimental might be used if we had a linux-2.7 or something while
> it's not OK for sid and Maks and Bastian agree that we're not going to
> have more the one kernel source on the distro anymore so there's no
> more need to allow this diversion.

It's short-sighted to "agree" that we're not going to have more than one
kernel source in the distro when the circumstances have not yet arisen where
we have to consider what to do about a new upstream major version.

For that matter, if someone in the project decides that they have need for a
different kernel than the one the kernel team wants to ship (for a
particular port, or to support older hardware, or to support a newer
cutting-edge kernel design, or for some other reason), the kernel team
doesn't have the authority to prohibit this.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reorganizing packages

[Otavio Salvador]

Otavio Salvador <[EMAIL PROTECTED]> writes:

> Steve Langasek <[EMAIL PROTECTED]> writes:
>
>> On Wed, Aug 22, 2007 at 02:21:18PM +0200, Bastian Blank wrote:
>>> On Wed, Aug 22, 2007 at 02:11:48AM -0700, Steve Langasek wrote:
>>> > I object; if and when there ever is a new upstream kernel branch that we
>>> > want to track separately this would have to be reverted,
>>
>>> No. We never had complete support for more than one branch. And I really
>>> doubt that anyone wants the sarge-maintenance-problem back.
>>
>> No, I'm sure we don't want it; but if upstream ever changes its mind later
>> about 2.6 being the one true kernel, we might still have it.
>
> I agree with you Steve and personally I don't see any good reason for
> dropping it.

After talking with "maks" at IRC I've changed my mind and now I agree on
the renaming.

The only good reason that I still have to keep it is due GIT tree name
but I don't think it's a requirement to us to follow it.

experimental might be used if we had a linux-2.7 or something while
it's not OK for sid and Maks and Bastian agree that we're not going to
have more the one kernel source on the distro anymore so there's no
more need to allow this diversion.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#438458: same problem

[Oleg Lyashko]

Have the same problem with

linux-image-2.6.18-5-amd64  2.6.18.dfsg.1-13etch1

after upgrading (linux-image-2.6.18-4-amd64 work fine)

Motherboard P5B
Display adapter ATI RADEON X1600 Series
Intel(R) Core(TM)2 CPU  6600  @ 2.40GHz
MemTotal4031636 kB


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#438458: same problem

[Oleg Lyashko]

Have the same problem with

linux-image-2.6.18-5-amd64  2.6.18.dfsg.1-13etch1

after upgrading (linux-image-2.6.18-4-amd64 work fine)

Motherboard P5B
Display adapter ATI RADEON X1600 Series
Intel(R) Core(TM)2 CPU  6600  @ 2.40GHz
MemTotal4031636 kB


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Root on LVM bug

[Adam C Powell IV]

Greetings,

I recently installed etch on an amd64 box which previously had Fedora.
It had a small ext2 /boot and large LVM, so I shrunk Fedora's volume and
made a new one for Debian, where I installed everything.  I included the
LVM modules in /etc/initramfs-tools/modules .  Then I added the
following section to /boot/grub/menu.lst :

title Debian
root (hd0,0)
kernel /vmlinuz-2.6.18-4-amd64 root=/dev/VolGroup00/LogVol02
initrd /initrd.img-2.6.18-4-amd64

When I booted, it sat at "Begin: Waiting for root file system..." but
the Fedora 2.6.11 kernel started right up with otherwise identical
options (except that it couldn't load the Fedora modules in Debian).

After a few hours of messing around, on a whim I tried changing the
root= parameter to /dev/mapper/VolGroup00-LogVol02 , which worked!

So I believe something is wrong with either mount or udev used in the
initramfs, such that it either doesn't create the /dev/
entries, or can't mount them.  I did a ton of searching and couldn't
find anything, so I don't think this is a known issue.

Given that installed Debian and other distros can use both /dev/mapper
and /dev/, shouldn't this be supported in the root= parameter
in grub?  Where is the bug, and has it been fixed already in lenny?  If
not, how can I help?

[Please cc me in replies]

Thanks,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linux-latest-2.6 update in stable incomplete

[dann frazier]

On Tue, Aug 21, 2007 at 09:10:02AM -0600, dann frazier wrote:
> On Tue, Aug 21, 2007 at 09:15:22AM +0200, Bastian Blank wrote:
> > On Mon, Aug 20, 2007 at 04:10:31PM -0600, dann frazier wrote:
> > > Are security updates visible at this point in the install. I think
> > > they are (except for network-less installs).
> > 
> > No.
> 
> Bummer, but at least it fixes upgrades.
> 
>22:55:11> dannf: from SRM's POV the security update for the
>kernel on arm is a go!
> 
> So I'm planning to proceed.

Last build (hppa) just came in, so its released.

-- 
dann frazier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processing of linux-latest-2.6_6etch2_ia64.changes

[Archive Administrator]

linux-latest-2.6_6etch2_ia64.changes uploaded successfully to localhost
along with the files:
  linux-latest-2.6_6etch2.dsc
  linux-latest-2.6_6etch2.tar.gz
  linux-image-itanium_2.6.18+6etch2_ia64.deb
  linux-image-2.6-itanium_2.6.18+6etch2_ia64.deb
  linux-headers-2.6-itanium_2.6.18+6etch2_ia64.deb
  linux-image-mckinley_2.6.18+6etch2_ia64.deb
  linux-image-2.6-mckinley_2.6.18+6etch2_ia64.deb
  linux-headers-2.6-mckinley_2.6.18+6etch2_ia64.deb
  kernel-image-2.6-itanium_2.6.18+6etch2_ia64.deb
  kernel-image-2.6-itanium-smp_2.6.18+6etch2_ia64.deb
  kernel-image-2.6-mckinley_2.6.18+6etch2_ia64.deb
  kernel-image-2.6-mckinley-smp_2.6.18+6etch2_ia64.deb
  linux-image-2.6-itanium-smp_2.6.18+6etch2_ia64.deb
  linux-image-2.6-mckinley-smp_2.6.18+6etch2_ia64.deb

Greetings,

Your Debian queue daemon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reorganizing packages

[Otavio Salvador]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Wed, Aug 22, 2007 at 02:21:18PM +0200, Bastian Blank wrote:
>> On Wed, Aug 22, 2007 at 02:11:48AM -0700, Steve Langasek wrote:
>> > I object; if and when there ever is a new upstream kernel branch that we
>> > want to track separately this would have to be reverted,
>
>> No. We never had complete support for more than one branch. And I really
>> doubt that anyone wants the sarge-maintenance-problem back.
>
> No, I'm sure we don't want it; but if upstream ever changes its mind later
> about 2.6 being the one true kernel, we might still have it.

I agree with you Steve and personally I don't see any good reason for
dropping it.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reorganizing packages

[Steve Langasek]

On Wed, Aug 22, 2007 at 02:21:18PM +0200, Bastian Blank wrote:
> On Wed, Aug 22, 2007 at 02:11:48AM -0700, Steve Langasek wrote:
> > I object; if and when there ever is a new upstream kernel branch that we
> > want to track separately this would have to be reverted,

> No. We never had complete support for more than one branch. And I really
> doubt that anyone wants the sarge-maintenance-problem back.

No, I'm sure we don't want it; but if upstream ever changes its mind later
about 2.6 being the one true kernel, we might still have it.

> >  and in the meantime
> > it would cause more confusion and work because of the need to shuffle the
> > transition packages for users to get a smooth upgrade from etch.

> The linux-image packages are already in etch.

But they weren't *used* as the metapackages that users installed.  We still
need linux-image-2.6-foo packages in lenny for upgrade, if nothing else.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#439167: linux-2.6: forcedeth MAC correction bug in Etch

[Moritz Muehlenhoff]

Package: linux-2.6
Version: 2.6.18.dfsg.1-13etch1
Severity: important

Hi Dann,
There's a nasty bug in NVidia onboard ethernet chipsets:
The MAC address provided by the BIOS is invalid (it's inverted); as a 
consequence
the kernel creates a random MAC as a workaround. In combination with udev this 
leads
to a new ethX device every time you reboot.

I've pulled the relevant fixes from git for the kernel in Univention Corporate
Server 2.0, a Debian-derived distribution based on Etch. We've updated the
Etch kernel with the attached patch and verified it to work on the system below:
http://www.asus.de/products.aspx?l1=1&l2=2&l3=407&l4=0&model=1155&modelmenu=2
(It should apply to a wide range of NVidia-based systems)

So, I propose to update forcedeth in the r2 point update. This is been fixed in
linux-2.6 in 2.6.20 or 2.6.21.

Cheers,
Moritz

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core)
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
diff -Naur linux-2.6-2.6.18.dfsg.1.orig/debian/patches/features/forcedeth-mac-correction.patch linux-2.6-2.6.18.dfsg.1/debian/patches/features/forcedeth-mac-correction.patch
--- linux-2.6-2.6.18.dfsg.1.orig/debian/patches/features/forcedeth-mac-correction.patch	1970-01-01 01:00:00.0 +0100
+++ linux-2.6-2.6.18.dfsg.1/debian/patches/features/forcedeth-mac-correction.patch	2007-08-18 13:21:11.0 +0200
@@ -0,0 +1,140 @@
+--- drivers/net/forcedeth.c.orig	2007-08-13 15:59:52.0 +0200
 a/drivers/net/forcedeth.c	2007-08-13 15:59:09.0 +0200
+@@ -168,6 +169,7 @@
+ #define DEV_HAS_PAUSEFRAME_TX   0x0200  /* device supports tx pause frames */
+ #define DEV_HAS_STATISTICS  0x0400  /* device supports hw statistics */
+ #define DEV_HAS_TEST_EXTENDED   0x0800  /* device supports extended diagnostic test */
++#define DEV_HAS_CORRECT_MACADDR 0x4000  /* device supports correct mac address order */
+ 
+ enum {
+ 	NvRegIrqStatus = 0x000,
+@@ -262,7 +264,8 @@
+ 	NvRegRingSizes = 0x108,
+ #define NVREG_RINGSZ_TXSHIFT 0
+ #define NVREG_RINGSZ_RXSHIFT 16
+-	NvRegUnknownTransmitterReg = 0x10c,
++	NvRegTransmitPoll = 0x10c,
++#define NVREG_TRANSMITPOLL_MAC_ADDR_REV	0x8000
+ 	NvRegLinkSpeed = 0x110,
+ #define NVREG_LINKSPEED_FORCE 0x1
+ #define NVREG_LINKSPEED_10	1000
+@@ -1178,7 +1181,7 @@
+ 			KERN_INFO "nv_stop_tx: TransmitterStatus remained busy");
+ 
+ 	udelay(NV_TXSTOP_DELAY2);
+-	writel(0, base + NvRegUnknownTransmitterReg);
++	writel(readl(base + NvRegTransmitPoll) & NVREG_TRANSMITPOLL_MAC_ADDR_REV, base + NvRegTransmitPoll);
+ }
+ 
+ static void nv_txrx_reset(struct net_device *dev)
+@@ -3918,7 +3921,7 @@
+ 	oom = nv_init_ring(dev);
+ 
+ 	writel(0, base + NvRegLinkSpeed);
+-	writel(0, base + NvRegUnknownTransmitterReg);
++	writel(readl(base + NvRegTransmitPoll) & NVREG_TRANSMITPOLL_MAC_ADDR_REV, base + NvRegTransmitPoll);
+ 	nv_txrx_reset(dev);
+ 	writel(0, base + NvRegUnknownSetupReg6);
+ 
+@@ -4094,7 +4097,7 @@
+ 	unsigned long addr;
+ 	u8 __iomem *base;
+ 	int err, i;
+-	u32 powerstate;
++	u32 powerstate, txreg;
+ 
+ 	dev = alloc_etherdev(sizeof(struct fe_priv));
+ 	err = -ENOMEM;
+@@ -4281,12 +4284,31 @@
+ 	np->orig_mac[0] = readl(base + NvRegMacAddrA);
+ 	np->orig_mac[1] = readl(base + NvRegMacAddrB);
+ 
+-	dev->dev_addr[0] = (np->orig_mac[1] >>  8) & 0xff;
+-	dev->dev_addr[1] = (np->orig_mac[1] >>  0) & 0xff;
+-	dev->dev_addr[2] = (np->orig_mac[0] >> 24) & 0xff;
+-	dev->dev_addr[3] = (np->orig_mac[0] >> 16) & 0xff;
+-	dev->dev_addr[4] = (np->orig_mac[0] >>  8) & 0xff;
+-	dev->dev_addr[5] = (np->orig_mac[0] >>  0) & 0xff;
++	/* check the workaround bit for correct mac address order */
++	txreg = readl(base + NvRegTransmitPoll);
++	if ((txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) ||
++	(id->driver_data & DEV_HAS_CORRECT_MACADDR)) {
++		/* mac address is already in correct order */
++		dev->dev_addr[0] = (np->orig_mac[0] >>  0) & 0xff;
++		dev->dev_addr[1] = (np->orig_mac[0] >>  8) & 0xff;
++		dev->dev_addr[2] = (np->orig_mac[0] >> 16) & 0xff;
++		dev->dev_addr[3] = (np->orig_mac[0] >> 24) & 0xff;
++		dev->dev_addr[4] = (np->orig_mac[1] >>  0) & 0xff;
++		dev->dev_addr[5] = (np->orig_mac[1] >>  8) & 0xff;
++	} else {
++		/* need to reverse mac address to correct order */
++		dev->dev_addr[0] = (np->orig_mac[1] >>  8) & 0xff;
++		dev->dev_addr[1] = (np->orig_mac[1] >>  0) & 0xff;
++		dev->dev_addr[2] = (np->orig_mac[0] >> 24) & 0xff;
++		dev->dev_addr[3] = (np->orig_mac[0] >> 16) & 0xff;
++		dev->dev_addr[4] = (np->orig_mac[0] >>  8) & 0xff;
++		dev->dev_addr[5] = (np->orig_mac[0] >>  0) & 0xff;
++		/* set permanent address to be correct aswell */
++		np->orig_mac[0] = (dev->dev_addr[0] << 0) + (dev->dev_addr[1] << 8) +
++			(dev->dev_addr[2] << 16) + (dev->dev_addr[3] << 24);
++		np->orig_mac[1] = (dev->dev_addr[4] << 0) + (dev->dev_addr[5] << 8);
++		writel(txreg|NVREG_

Re: Reducing number of i386 linux images

[Kyle McMartin]

On Wed, Aug 22, 2007 at 09:18:44AM +0200, maximilian attems wrote:
> > I propose the following:
> > - Rename 686-bigmem to 686-pae. pae is more than support for much
> >   memory, it includes things like NX.
> 
> nack
> as already told on private channel to many pentium m out there are
> don't support pae
> 

OTOH, there's little reason to ship a 486 *and* a 686 kernel, probably
easiest to just drop the 686 and rename 486 to generic or something.

> > - Drop k7.
> 
> ack
> 486 image is fine for those and the hardware is no longer
> so wide spread.

word.

Cheers,
Kyle


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#434752: Kernel hangs when I echo 0 > /proc/sys/vm/vdso_enabled

[Loïc Minier]

tags 434752 + patch
stop

On Thu, Jul 26, 2007, Loïc Minier wrote:
>  Since some months, I get unusable backtraces from gdb; I was pointed at
>  an OpenSuse bug at:
> 

 I extracted the patch Novell/OpenSuse applied to its kernel, would be
 nice to get it in Debian.

-- 
Loïc Minier
Subject: i386: allow debuggers to access the vsyscall page with  compat vDSO
From: "Jan Beulich" <[EMAIL PROTECTED]>
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

 arch/i386/kernel/sysenter.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Index: linux/arch/i386/kernel/sysenter.c
===
--- linux.orig/arch/i386/kernel/sysenter.c
+++ linux/arch/i386/kernel/sysenter.c
@@ -336,7 +336,9 @@ struct vm_area_struct *get_gate_vma(stru
 
 int in_gate_area(struct task_struct *task, unsigned long addr)
 {
-   return 0;
+   const struct vm_area_struct *vma = get_gate_vma(task);
+
+   return vma && addr >= vma->vm_start && addr < vma->vm_end;
 }
 
 int in_gate_area_no_task(unsigned long addr)

Processed: Re: Bug#434752: Kernel hangs when I echo 0 > /proc/sys/vm/vdso_enabled

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> tags 434752 + patch
Bug#434752: Kernel hangs when I echo 0 > /proc/sys/vm/vdso_enabled
There were no tags set.
Tags added: patch

> stop
Stopping processing here.

Please contact me if you need assistance.

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#439072: snd-intel8x0 line-in not working in later 2.6.x kernels

[Josip Rodin]

Hi Adrian,

On Wed, Aug 22, 2007 at 04:13:19AM +0200, Josip Rodin wrote:
> > I'm reporting this bug that I have been seeing for a while and which is
> > a regression from a few months/years ago - the line-in input simply doesn't
> > work right. arecord(1) just doesn't record anything with it, it doesn't show
> > any errors, it records silence. The recording from the same external source
> > works just fine with the microphone input.
> 
> I re-selected the old-style i810_audio driver in 2.6.21 and compiled it,
> unloaded the ALSA driver, loaded the old driver, and voila, everything went
> back to normal, I can hear the TV sound just fine. So, it might be that this
> is an OSS->ALSA regression that slipped through the cracks?

While browsing kernel options, I noticed:

Please contact Adrian Bunk <[EMAIL PROTECTED]> if you had to
say Y here because your hardware is not properly supported
by ALSA.

...in the description of CONFIG_OSS_OBSOLETE, so, here I am :)

This is Debian bug #439072 (and #384933 also looks suspiciously similar,
if I might add).

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reducing number of i386 linux images

[dann frazier]

On Wed, Aug 22, 2007 at 07:18:08PM +0200, Bastian Blank wrote:
> On Wed, Aug 22, 2007 at 09:18:44AM +0200, maximilian attems wrote:
> > > - Rename 686-bigmem to 686-pae. pae is more than support for much
> > >   memory, it includes things like NX.
> > 
> > nack
> > as already told on private channel to many pentium m out there are
> > don't support pae
> 
> What is the problem than? They should never install them.

waldi,
 It'd probably help if you listed out more specific statements about
your suggested migrations. This way we can better understand the
implications and what benchmarks maybe relevant.

For example:

Dropping 686-bigmem
---
 - 686-bigmem dies
 - 686 flavour acquires PAE support
 - Users with currently installed -686 systems somehow upgrade to the
   486 flavour

Dropping k7
---
...

-- 
dann frazier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#439149: kernel panic linux-image-2.6.18-5-xen-amd64 on xeon at starting multiple domUs

[Jan-Michael Thölken]

Package: linux-image-2.6-xen-amd64
Version: 2.6.18-5

When I start up multiple domUs (for example the third one)
I get the following kernel panic:

Aug 22 18:22:13 fourty2 kernel: --- [cut here ] -
[please bite here ] -
Aug 22 18:22:13 fourty2 kernel: Kernel BUG at drivers/xen/core/evtchn.c:481
Aug 22 18:22:13 fourty2 kernel: invalid opcode:  [1] SMP
Aug 22 18:22:13 fourty2 kernel: CPU 3
Aug 22 18:22:13 fourty2 kernel: Modules linked in: xt_tcpudp xt_physdev
iptable_filter ip_tables x_tables bridge netloop ipv6 button ac battery
loop psmouse serial_core pcspkr shpchp pci_hotplug serio_raw evdev ext3
jbd mbcache dm_mirror dm_snapshot dm_mod ide_generic ide_cd cdrom usbhid
piix sd_mod generic ide_core uhci_hcd bnx2 ehci_hcd megaraid_sas
scsi_mod fan
Aug 22 18:22:13 fourty2 kernel: Pid: 21, comm: xenwatch Not tainted
2.6.18-5-xen-amd64 #1
Aug 22 18:22:13 fourty2 kernel: RIP: e030:[]
[] retrigger+0x26/0x3e
Aug 22 18:22:13 fourty2 kernel: RSP: e02b:8800f2a9fd88  EFLAGS: 00010046
Aug 22 18:22:13 fourty2 kernel: RAX:  RBX:
8e00 RCX: ff578000
Aug 22 18:22:13 fourty2 kernel: RDX: 0030 RSI:
8800f2a9fd30 RDI: 011c
Aug 22 18:22:13 fourty2 kernel: RBP: 804ce280 R08:
8800f2933c70 R09: 8800ef6fb500
Aug 22 18:22:13 fourty2 kernel: R10: 8800ef6fb000 R11:
80360f30 R12: 011c
Aug 22 18:22:13 fourty2 kernel: R13: 804ce2bc R14:
 R15: 0008
Aug 22 18:22:13 fourty2 kernel: FS:  2b19b5c046d0()
GS:804c4180() knlGS:
Aug 22 18:22:13 fourty2 kernel: CS:  e033 DS:  ES: 
Aug 22 18:22:13 fourty2 kernel: Process xenwatch (pid: 21, threadinfo
8800f2a9e000, task 8800f2a77080)
Aug 22 18:22:13 fourty2 kernel: Stack:  802a06bc
8800ef6fb500  8800ef6fb500  
Aug 22 18:22:13 fourty2 kernel:  8800f2a9fde0  020b
8036dac1  
Aug 22 18:22:13 fourty2 kernel:  8036df39  8800f2a9fea4
Aug 22 18:22:13 fourty2 kernel: Call Trace:
Aug 22 18:22:13 fourty2 kernel:  [] enable_irq+0x9d/0xbc
Aug 22 18:22:13 fourty2 kernel:  [] __netif_up+0xc/0x15
Aug 22 18:22:13 fourty2 kernel:  [] netif_map+0x2a6/0x2d8
Aug 22 18:22:13 fourty2 kernel:  []
bus_for_each_dev+0x61/0x6e
Aug 22 18:22:13 fourty2 kernel:  []
xenwatch_thread+0x0/0x145
Aug 22 18:22:13 fourty2 kernel:  []
xenwatch_thread+0x0/0x145
Aug 22 18:22:13 fourty2 kernel:  []
frontend_changed+0x2ba/0x4f9
Aug 22 18:22:13 fourty2 kernel:  []
xenwatch_thread+0x0/0x145
Aug 22 18:22:13 fourty2 kernel:  []
keventd_create_kthread+0x0/0x61
Aug 22 18:22:13 fourty2 kernel:  []
xenwatch_handle_callback+0x15/0x48
Aug 22 18:22:13 fourty2 kernel:  []
xenwatch_thread+0x12d/0x145
Aug 22 18:22:13 fourty2 kernel:  []
autoremove_wake_function+0x0/0x2e
Aug 22 18:22:13 fourty2 kernel:  []
keventd_create_kthread+0x0/0x61
Aug 22 18:22:13 fourty2 kernel:  []
xenwatch_thread+0x0/0x145
Aug 22 18:22:13 fourty2 kernel:  [] kthread+0xd4/0x107
Aug 22 18:22:13 fourty2 kernel:  [] child_rip+0xa/0x12
Aug 22 18:22:13 fourty2 kernel:  []
keventd_create_kthread+0x0/0x61
Aug 22 18:22:13 fourty2 kernel:  [] kthread+0x0/0x107
Aug 22 18:22:13 fourty2 kernel:  [] child_rip+0x0/0x12
Aug 22 18:22:13 fourty2 kernel:
Aug 22 18:22:13 fourty2 kernel:
Aug 22 18:22:13 fourty2 kernel: Code: 0f 0b 68 94 db 41 80 c2 e1 01 f0
0f ab 91 00 08 00 00 b8 01
Aug 22 18:22:13 fourty2 kernel: RIP  []
retrigger+0x26/0x3e
Aug 22 18:22:13 fourty2 kernel:  RSP 


with version 2.6.18-4 everything works fine.
here my cat /proc/cpuinfo:

fourty2:/var/log# cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Xeon(R) CPU5120  @ 1.86GHz
stepping: 6
cpu MHz : 1862.119
cache size  : 4096 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc
pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips: 4656.34
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Xeon(R) CPU5120  @ 1.86GHz
stepping: 6
cpu MHz : 1862.119
cache size  : 4096 KB
physical id : 1
siblings: 1
core id : 0
cpu cores   : 1
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc
pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips: 46

Re: Reducing number of i386 linux images

[Bastian Blank]

On Wed, Aug 22, 2007 at 09:18:44AM +0200, maximilian attems wrote:
> > - Rename 686-bigmem to 686-pae. pae is more than support for much
> >   memory, it includes things like NX.
> 
> nack
> as already told on private channel to many pentium m out there are
> don't support pae

What is the problem than? They should never install them.

> > - Drop k7.
> ack
> 486 image is fine for those and the hardware is no longer
> so wide spread.

k7 is 686 compatible.

Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: severity of 439134 is important

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.10.7
> severity 439134 important
Bug#439134: linux-image-2.6.18-5-486: 2.6.18-5-486 fails to boot
Severity set to `important' from `critical'

>
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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#439020: Please could CONFIG_TCG_TPM be set to 'm'

[maximilian attems]

On Wed, Aug 22, 2007 at 09:37:47AM -0600, dann frazier wrote:
> > Debian kernels seem to be built without the required drivers.  It
> > appears they were disabled by in commit r3389 to the kernel-svn:
> > 
> > http://lists.alioth.debian.org/pipermail/kernel-svn-changes/2005-June/002083.html
> > 
> > As far as I can see the only reason given for this was:
> > 
> > http://lists.debian.org/debian-kernel/2005/06/msg00364.html
> > 
> > I appreciate that this is an emotive issue for some but I dispute the
> > assertion that these are useless.  It seems there are other developers
> > who may be interested in this as well:
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409591
> > 
> > As far as I see it, the TPM chip is just a tool, whether it is used by
> > the owner to defend their computer against tampering or whether it is
> > used by $LARGE_CORPORATION as part of a system to take away people's
> > freedoms is a separate human and a political issue.  Thus I think it
> > would be nice to have TPM drivers in Debian as then whoever has root on
> > that has the choice of whether or not to use the chip.
> 
> maks, looks like you disabled them. comments?

back in the 2005 days there was _zero_ userspace for them,
thus they were useless.

i'm ok to reconsider the old decision and to sync with fedora.
i'll reenable them on trunk once buildserver is back.

--
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#402770: linux-2.6: ip_conntrack module oopses

[Michael Dosser]

Hi,

this problem occurs also on my SGI Indigo2 with 256MB RAM:

BUG: warning at kernel/softirq.c:137/local_bh_enable()
Call Trace:
[] dump_stack+0x18/0x58
[] local_bh_enable+0x11c/0x128
[] $L436+0x50/0x88 [ip_conntrack]

# cat /proc/cpuinfo
system type : SGI Indigo2
processor   : 0
cpu model   : R4400SC V6.0  FPU V0.0
BogoMIPS: 124.67
wait instruction: no
microsecond timers  : yes
tlb_entries : 48
extra interrupt vector  : no
hardware watchpoint : yes
ASEs implemented:
VCED exceptions : 1225430
VCEI exceptions : 15227

# lsmod
Module  Size  Used by
ipv6  536464  12 
xt_tcpudp   5248  16 
xt_state3072  4 
ip_conntrack   87312  1 xt_state
nfnetlink  11952  1 ip_conntrack
iptable_filter  4288  1 
ip_tables  40128  1 iptable_filter
x_tables   27440  3 xt_tcpudp,xt_state,ip_tables
dm_snapshot32352  0 
dm_mirror  38224  0 
dm_mod109376  2 dm_snapshot,dm_mirror

# uname -a
Linux archon 2.6.18-5-r4k-ip22 #1 Mon Aug 13 00:26:41 BST 2007 mips64
GNU/Linux

I can provide more information if needed.

Mic

-- 
Ein Un*x mit einer falschen Zeit, ist ein Tor zur Hölle :)
Stefan Huber in at.linux

problem w/ snapshot builds?

[dann frazier]

Its been over 24 hrs since I committed something to the etch branch
and I haven't yet seen new builds appear in:
 http://kernel-archive.buildserver.net/pool/main/l/linux-2.6/

So, I checked the status page to see if there was a failure, but it
looks like its currently down:
  
http://stats.buildserver.net/packages/status.php?email=debian-kernel&packages=&arches=&subdist=kernel-dists

Last night it said the page was last updated Jan 1, 1970 - today it
has a current date, but I still don't see any logs.

I assumed snapshot builds happened automatically - but maybe I need
trigger one somehow? Or are snapshots just offline atm?

-- 
dann frazier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#439134: marked as done (linux-image-2.6.18-5-486: 2.6.18-5-486 fails to boot)

[Debian Bug Tracking System]

Your message dated Wed, 22 Aug 2007 18:47:25 +0300
with message-id <[EMAIL PROTECTED]>
and subject line Bug#439134: linux-image-2.6.18-5-486: 2.6.18-5-486 fails to 
boot
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

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

--- Begin Message ---
Package: linux-image-2.6.18-5-486
Version: 2.6.18.dfsg.1-13etch1
Severity: critical
Justification: breaks the whole system

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The 2.6.18-5-486 kernel that was pushed over the last few days to replace 
2.6.18-4 
makes this system completely unbootable. I see GRUB load the kernel and then 
the 
screen goes blank; not a single boot message appears and the IDE LED on the 
host 
remains stuck at full ON, instead of flickering to indicate data transfers 
taking 
place as it would normally appear during booting.

Being physically present at powerup to select the previous 2.6.18-4-486 kernel 
successfully boots the system, so this has to be a problem with 2.6.18-5-486.

PS: I notice that a new initramfs tool was also pushed. If the break comes from 
there, please feel free to reassign.

- -- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-486
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)

Versions of packages linux-image-2.6.18-5-486 depends on:
ii  coreutils 5.97-5.3   The GNU core utilities
ii  debconf [debconf-2.0] 1.5.11 Debian configuration management sy
ii  initramfs-tools [linux-initra 0.85h  tools for generating an initramfs
ii  module-init-tools 3.3-pre4-2 tools for managing Linux kernel mo

linux-image-2.6.18-5-486 recommends no packages.

- -- debconf information:
  linux-image-2.6.18-5-486/postinst/kimage-is-a-directory:
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.18-5-486/postinst/old-initrd-link-2.6.18-5-486: true
  linux-image-2.6.18-5-486/preinst/already-running-this-2.6.18-5-486:
  linux-image-2.6.18-5-486/preinst/abort-install-2.6.18-5-486:
  linux-image-2.6.18-5-486/postinst/old-dir-initrd-link-2.6.18-5-486: true
  linux-image-2.6.18-5-486/postinst/old-system-map-link-2.6.18-5-486: true
  linux-image-2.6.18-5-486/preinst/failed-to-move-modules-2.6.18-5-486:
  linux-image-2.6.18-5-486/prerm/removing-running-kernel-2.6.18-5-486: true
  linux-image-2.6.18-5-486/prerm/would-invalidate-boot-loader-2.6.18-5-486: true
  linux-image-2.6.18-5-486/preinst/elilo-initrd-2.6.18-5-486: true
  linux-image-2.6.18-5-486/postinst/depmod-error-2.6.18-5-486: false
  linux-image-2.6.18-5-486/postinst/bootloader-error-2.6.18-5-486:
  linux-image-2.6.18-5-486/preinst/bootloader-initrd-2.6.18-5-486: true
  linux-image-2.6.18-5-486/preinst/abort-overwrite-2.6.18-5-486:
  linux-image-2.6.18-5-486/preinst/lilo-has-ramdisk:
  linux-image-2.6.18-5-486/postinst/depmod-error-initrd-2.6.18-5-486: false
  linux-image-2.6.18-5-486/postinst/create-kimage-link-2.6.18-5-486: true
  linux-image-2.6.18-5-486/postinst/bootloader-test-error-2.6.18-5-486:
  linux-image-2.6.18-5-486/preinst/overwriting-modules-2.6.18-5-486: true
  linux-image-2.6.18-5-486/preinst/initrd-2.6.18-5-486:
  linux-image-2.6.18-5-486/preinst/lilo-initrd-2.6.18-5-486: true

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGzFD0eXr56x4Muc0RAjGQAJ0WbHOVmWk8ba+73Oby+MCQyR2xLwCgsXAX
8eAggwb/dotDi1TblrQn4bY=
=SCcg
-END PGP SIGNATURE-

--- End Message ---
--- Begin Message ---
On 8/22/07, dann frazier <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 22, 2007 at 06:06:28PM +0300, Martin-Eric Racine wrote:
> > Package: linux-image-2.6.18-5-486
> > Version: 2.6.18.dfsg.1-13etch1
> > Severity: critical
> > Justification: breaks the whole system
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > The 2.6.18-5-486 kernel that was pushed over the last few days to replace 
> > 2.6.18-4
> > makes this system completely unbootable. I see GRUB load the kernel and 
> > then the
> > screen goes blank; not a single boot message appears and the IDE LED on the 
> > host
> > remains stuck at full ON, instead of flickering to indicate data transfers 
> > taking
> > place as it would normally appear during booting.
> >
> > Being physically present at powerup to select the previous 2.6.18-4-486 
> > kernel
> > successfully boots the system, so this has to be a problem with 
> > 2.6.18-5-486.
> >
> > PS: I notice that a new initramfs tool was also pushed. If the break comes 
> > from
> > there, please feel f

Processed: reassign 439020 to linux-2.6

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.10.7
> reassign 439020 linux-2.6
Bug#439020: Please could CONFIG_TCG_TPM be set to 'm'
Bug reassigned from package `linux-image-2.6-686' to `linux-2.6'.

>
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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#439020: Please could CONFIG_TCG_TPM be set to 'm'

[dann frazier]

reassign linux-2.6
thanks

On Tue, Aug 21, 2007 at 07:20:59PM +0100, Martin wrote:
> I was looking at trying out Trusted Grub
> ( http://www.prosec.rub.de/trusted_grub.html ) but found that the stock
> Debian kernels seem to be built without the required drivers.  It
> appears they were disabled by in commit r3389 to the kernel-svn:
> 
> http://lists.alioth.debian.org/pipermail/kernel-svn-changes/2005-June/002083.html
> 
> As far as I can see the only reason given for this was:
> 
> http://lists.debian.org/debian-kernel/2005/06/msg00364.html
> 
> I appreciate that this is an emotive issue for some but I dispute the
> assertion that these are useless.  It seems there are other developers
> who may be interested in this as well:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409591
> 
> As far as I see it, the TPM chip is just a tool, whether it is used by
> the owner to defend their computer against tampering or whether it is
> used by $LARGE_CORPORATION as part of a system to take away people's
> freedoms is a separate human and a political issue.  Thus I think it
> would be nice to have TPM drivers in Debian as then whoever has root on
> that has the choice of whether or not to use the chip.

maks, looks like you disabled them. comments?

-- 
dann frazier



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#439134: linux-image-2.6.18-5-486: 2.6.18-5-486 fails to boot

[dann frazier]

On Wed, Aug 22, 2007 at 06:06:28PM +0300, Martin-Eric Racine wrote:
> Package: linux-image-2.6.18-5-486
> Version: 2.6.18.dfsg.1-13etch1
> Severity: critical
> Justification: breaks the whole system
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> The 2.6.18-5-486 kernel that was pushed over the last few days to replace 
> 2.6.18-4 
> makes this system completely unbootable. I see GRUB load the kernel and then 
> the 
> screen goes blank; not a single boot message appears and the IDE LED on the 
> host 
> remains stuck at full ON, instead of flickering to indicate data transfers 
> taking 
> place as it would normally appear during booting.
> 
> Being physically present at powerup to select the previous 2.6.18-4-486 
> kernel 
> successfully boots the system, so this has to be a problem with 2.6.18-5-486.
> 
> PS: I notice that a new initramfs tool was also pushed. If the break comes 
> from 
> there, please feel free to reassign.

You are the first person to report such a problem and, given there
were no changes that should be in effect that early in the boot
process, I suspect some other local failure.

Please try re-installing this image, after possibly fscking your disk.
If that doesn't work, please try 2.6.18.dfsg.1-13 and see if it works.

If the latest kernel is still not working, please provide the dmesg
output of the last working kernel.

-- 
dann frazier



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#439134: linux-image-2.6.18-5-486: 2.6.18-5-486 fails to boot

[Martin-Eric Racine]

Package: linux-image-2.6.18-5-486
Version: 2.6.18.dfsg.1-13etch1
Severity: critical
Justification: breaks the whole system

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The 2.6.18-5-486 kernel that was pushed over the last few days to replace 
2.6.18-4 
makes this system completely unbootable. I see GRUB load the kernel and then 
the 
screen goes blank; not a single boot message appears and the IDE LED on the 
host 
remains stuck at full ON, instead of flickering to indicate data transfers 
taking 
place as it would normally appear during booting.

Being physically present at powerup to select the previous 2.6.18-4-486 kernel 
successfully boots the system, so this has to be a problem with 2.6.18-5-486.

PS: I notice that a new initramfs tool was also pushed. If the break comes from 
there, please feel free to reassign.

- -- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-486
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)

Versions of packages linux-image-2.6.18-5-486 depends on:
ii  coreutils 5.97-5.3   The GNU core utilities
ii  debconf [debconf-2.0] 1.5.11 Debian configuration management sy
ii  initramfs-tools [linux-initra 0.85h  tools for generating an initramfs
ii  module-init-tools 3.3-pre4-2 tools for managing Linux kernel mo

linux-image-2.6.18-5-486 recommends no packages.

- -- debconf information:
  linux-image-2.6.18-5-486/postinst/kimage-is-a-directory:
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.18-5-486/postinst/old-initrd-link-2.6.18-5-486: true
  linux-image-2.6.18-5-486/preinst/already-running-this-2.6.18-5-486:
  linux-image-2.6.18-5-486/preinst/abort-install-2.6.18-5-486:
  linux-image-2.6.18-5-486/postinst/old-dir-initrd-link-2.6.18-5-486: true
  linux-image-2.6.18-5-486/postinst/old-system-map-link-2.6.18-5-486: true
  linux-image-2.6.18-5-486/preinst/failed-to-move-modules-2.6.18-5-486:
  linux-image-2.6.18-5-486/prerm/removing-running-kernel-2.6.18-5-486: true
  linux-image-2.6.18-5-486/prerm/would-invalidate-boot-loader-2.6.18-5-486: true
  linux-image-2.6.18-5-486/preinst/elilo-initrd-2.6.18-5-486: true
  linux-image-2.6.18-5-486/postinst/depmod-error-2.6.18-5-486: false
  linux-image-2.6.18-5-486/postinst/bootloader-error-2.6.18-5-486:
  linux-image-2.6.18-5-486/preinst/bootloader-initrd-2.6.18-5-486: true
  linux-image-2.6.18-5-486/preinst/abort-overwrite-2.6.18-5-486:
  linux-image-2.6.18-5-486/preinst/lilo-has-ramdisk:
  linux-image-2.6.18-5-486/postinst/depmod-error-initrd-2.6.18-5-486: false
  linux-image-2.6.18-5-486/postinst/create-kimage-link-2.6.18-5-486: true
  linux-image-2.6.18-5-486/postinst/bootloader-test-error-2.6.18-5-486:
  linux-image-2.6.18-5-486/preinst/overwriting-modules-2.6.18-5-486: true
  linux-image-2.6.18-5-486/preinst/initrd-2.6.18-5-486:
  linux-image-2.6.18-5-486/preinst/lilo-initrd-2.6.18-5-486: true

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGzFD0eXr56x4Muc0RAjGQAJ0WbHOVmWk8ba+73Oby+MCQyR2xLwCgsXAX
8eAggwb/dotDi1TblrQn4bY=
=SCcg
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reorganizing packages

[maximilian attems]

On Wed, Aug 22, 2007 at 02:07:23PM +0200, Frederik Schueler wrote:
> 
> On Wed, Aug 22, 2007 at 02:11:48AM -0700, Steve Langasek wrote:
> > I object; if and when there ever is a new upstream kernel branch that we
> > want to track separately this would have to be reverted, and in the meantime
> > it would cause more confusion and work because of the need to shuffle the
> > transition packages for users to get a smooth upgrade from etch.
> 
> Hmm, anyone heard of a planned 2.7 or 2.8 tree? My last infos where 2.6
> is being kept for the time being.

yes current upstream stated plan is that there is no need for such trees.

as bonus it would separate dkt bug reports.
 
-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reorganizing packages

[Bastian Blank]

On Wed, Aug 22, 2007 at 02:11:48AM -0700, Steve Langasek wrote:
> I object; if and when there ever is a new upstream kernel branch that we
> want to track separately this would have to be reverted,

No. We never had complete support for more than one branch. And I really
doubt that anyone wants the sarge-maintenance-problem back.

>  and in the meantime
> it would cause more confusion and work because of the need to shuffle the
> transition packages for users to get a smooth upgrade from etch.

The linux-image packages are already in etch.

Bastian

-- 
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reducing number of i386 linux images

[Bastian Blank]

On Wed, Aug 22, 2007 at 02:05:29PM +0200, Frederik Schueler wrote:
> There are a whole lot of k7 boxes out there.

k6-3 and k7 are 686.

Bastian

-- 
"What terrible way to die."
"There are no good ways."
-- Sulu and Kirk, "That Which Survives", stardate unknown


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reorganizing packages

[Frederik Schueler]

Hello,

On Wed, Aug 22, 2007 at 02:11:48AM -0700, Steve Langasek wrote:
> I object; if and when there ever is a new upstream kernel branch that we
> want to track separately this would have to be reverted, and in the meantime
> it would cause more confusion and work because of the need to shuffle the
> transition packages for users to get a smooth upgrade from etch.

Hmm, anyone heard of a planned 2.7 or 2.8 tree? My last infos where 2.6
is being kept for the time being.


Best regards
Frederik Schüler

-- 
ENOSIG


signature.asc
Description: Digital signature

Re: Reducing number of i386 linux images

[Frederik Schueler]

On Wed, Aug 22, 2007 at 09:18:44AM +0200, maximilian attems wrote:
> 
> > - Drop k7.
> 
> ack
> 486 image is fine for those and the hardware is no longer
> so wide spread.

There are a whole lot of k7 boxes out there.

I would not like to use the 486 flavour on my K7-smp servers, but I can
run some benchmarks to verify performance penalities, if you point me to
one suited for the task.

I think if we are really going to drop k7, then we might tune some
settings in the 686 flavour to support both CPU worlds equally good 
(or bad). 

But I guess In the end, it's all about cache line alignment, and the 686
flavour will perform more or less good enough on k7, allowing us to drop
the other.


Best regards
Frederik Schüler

-- 
ENOSIG


signature.asc
Description: Digital signature

initramfs-tools / cryptoroot

[Daniel Reichelt]

Hello List,

I'm administering several linux hosts, which are all set up to boot from a
luks-encrypted partition (which partly live in LVM). I was hacked off to have
to go down to the basement and enter the passwords manually on each and every
reboot. So why not let this be managed by a central "boot server"? So I've set
up the following process:

- included sshd/dhclient3 in initrd by a hook
- on boot time, either a static ip is assigned by a boot parameter or a dynamic
one obtained by dhclient3
- sshd is started just before scripts/local-top/cryptoroot is run
- while cryptsetup waits for a password to be entered, a ssh-connection can be
made (thus being able to execute cryptsetup, vgchange etc remotely and
automated...)
- when the partition is unlocked, the cryptsetup process from cryptoroot is
just killed, booting continues (especially this part is nasty (yet) as it may
interfere with other hooks unexpectedly...)
- dhclient3/sshd are killed
- rest as usual.

The remote_unlock_via_ssh.sh script is what i use for remote unlocking. The
config files are stored gpg-encrypted, so i can safely boot root-encrypted
machines from any trusted terminal remotely.

Please let me know what you think. If you like it, I'd gladly document it 
further.

Cheers,

Daniel


PS: I hope binary attachments to this list are ok, please let me know your
conventions if not.



initramfs-remoteunlock.tar.bz2
Description: Binary data

Re: Reorganizing packages

[Steve Langasek]

On Tue, Aug 21, 2007 at 07:08:47PM +0200, Bastian Blank wrote:
> Hi folks

> * Rename linux(-[-a-z]+|)-2.6 into linux\1.
> * Drop the 2.6 version identifier from meta packages:

>   Package: linux-image-686
>   Provides: linux-image, linux-latest-modules-2.6.22-1-686
>   Depends: linux-image-2.6.22-1-686

>   Package: linux-headers-686
>   Provides: linux-headers
>   Depends: linux-headers-2.6.22-1-686

>   Package: unionfs-modules-686
>   Provides: unionfs-modules
>   Depends: unionfs-modules-2.6.22-1-686, linux-latest-modules-2.6.22-1-686

I object; if and when there ever is a new upstream kernel branch that we
want to track separately this would have to be reverted, and in the meantime
it would cause more confusion and work because of the need to shuffle the
transition packages for users to get a smooth upgrade from etch.

The -2.6 doesn't hurt anything, I recommend leaving it as-is.

> * Drop duplicated xen identifier from xen-linux-system:

>   Package: xen-linux-system-2.6.18-4-686
>   Depends: linux-image-2.6.18-4-xen-686 (= ${binary:Version}), 
> xen-hypervisor-3.0.3-1-i386-pae

That seems like a good improvement.  It doesn't require changes to the
source package name, so is less disruptive on that front; and changes to xen
binary package names have less effect on the rest of the system (e.g., the
installer).

> * Add meta packages for xen-linux-system:

>   Package: xen-linux-system-686
>   Provides: xen-linux-system
>   Depends: xen-linux-system-2.6.18-4-686, linux-image-686 (= 
> ${binary:Version})

Also seems fair to me.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reorganizing packages

[maximilian attems]

On Tue, 21 Aug 2007, Bastian Blank wrote:

> * Rename linux(-[-a-z]+|)-2.6 into linux\1.
> * Drop the 2.6 version identifier from meta packages:

cool
thanks for picking that up :)
 

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reducing number of i386 linux images

[maximilian attems]

morning.

On Tue, 21 Aug 2007, Bastian Blank wrote:

> I think its another time to reconsider the available i386 images.
> 
> Currently we build:
> - 486
> - 686
> - 686-bigmem
> - k7
> - amd64
> 
> I propose the following:
> - Rename 686-bigmem to 686-pae. pae is more than support for much
>   memory, it includes things like NX.

nack
as already told on private channel to many pentium m out there are
don't support pae

> - Drop k7.

ack
486 image is fine for those and the hardware is no longer
so wide spread.

this should allow to add vserver-bigmem
irc there is quite some demand.
 
-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]