Bug#488969: please warn if a non-executable file in scripts/*/* is found

2008-07-06 Thread martin f krafft
also sprach maximilian attems [EMAIL PROTECTED] [2008.07.05.2251 +0200]:
 the maintainer should test such stuff before uploading.

if s/he does, then there won't be a warning and the user won't even
notice a difference.

also, this is about the user putting stuff into /etc, which is
precisely how I rendered my system unbootable.

-- 
 .''`.   martin f. krafft [EMAIL PROTECTED]
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
Most Intelligent Customers Realise Our Software Only Fools Them.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)


Bug#416109: marked as done (nVidia MCP51 Audio fails [intel snd driver] - works in 2.6.20)

2008-07-06 Thread Debian Bug Tracking System

Your message dated Sun, 6 Jul 2008 11:28:37 +0200
with message-id [EMAIL PROTECTED]
and subject line Re: nVidia MCP51 Audio fails [intel snd driver] - works in 
2.6.20
has caused the Debian Bug report #416109,
regarding nVidia MCP51 Audio fails [intel snd driver] - works in 2.6.20
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
416109: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416109
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
---BeginMessage---
Package: linux-image-2.6.18-4-k7
Version: 2.6.18.dfsg.1-11
Severity: normal


00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio
(rev a2)
Subsystem: ASUSTeK Computer Inc. Unknown device 81cb
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 0 (500ns min, 1250ns max)
Interrupt: pin B routed to IRQ 17
Region 0: Memory at fe024000 (32-bit, non-prefetchable)
[size=16K]
Capabilities: access denied


The audio device fails to function properly in the current Debian
kernel. Functions perfectly in current 2.6.20.

Is it possible to address this for Etch or is it too late now?

- Adam


-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (900, 'unstable'), (5, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20.4
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

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

Versions of packages linux-image-2.6.18-4-k7 recommends:
ii  libc6-i686  2.3.6.ds1-13 GNU C Library: Shared libraries [i

-- debconf information excluded

---End Message---
---BeginMessage---
Version: 2.6.20-1

newer kernels for etch are in backports.org or in etch + half
thanks for report thus closing.


-- 
maks

---End Message---


Bug#416657: marked as done (forcedeth doesnot work in combination with vlan and brigde)

2008-07-06 Thread Debian Bug Tracking System

Your message dated Fri, 4 Jul 2008 22:33:36 +0200
with message-id [EMAIL PROTECTED]
and subject line Re: xen-linux-system-2.6.18-4-xen-686: Prevents ALSA from 
finding soundcards
has caused the Debian Bug report #416657,
regarding forcedeth doesnot work in combination with vlan and brigde
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
416657: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416657
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
---BeginMessage---

Package: linux-image-2.6.18-4-xen-amd64
Version: 2.6.18.dfsg.1-11

For a xen installation on a sun fire 4200m2 I tried to bridge a vlan  
on eth0 (forcedeth-driver) with a vifx.x of one of the domUs. The  
network of the domU does not work at all.


I use the following custom script (peth0 is the renamed eth0)

# vlan 1103
if ! `lsmod | grep -q 8021q` ; then modprobe 8021q ; fi
vconfig add peth0 1103

brctl addbr xenbr103
brctl stp xenbr103 off
brctl setfd xenbr103 0
ip link set xenbr103 arp off
ip link set xenbr103 multicast off
ip link set peth0.1103 up
brctl addif xenbr103 peth0.1103
ip link set xenbr103 up

the xen script add the vif interface when I start the domU.

# brctl show
bridge name bridge id   STP enabled interfaces
xenbr0  8000.feff   no  vif0.0
peth2
xenbr1038000.feff   no   
peth0.1103

vif2.0


if I look at the macs I cannot see the router
# brctl showmacs xenbr103
port no mac addris local?   ageing timer
  2 00:16:3e:25:05:bc   no24.74
  1 fe:ff:ff:ff:ff:ff   yes0.00

On eth2 (an interface with e1000 driver) the same configuration  
works. A bridge without a vlan works and a vlan without bridge works  
too.


I am using:

Linux xen-7 2.6.18-4-xen-amd64 #1 SMP Wed Feb 21 16:02:59 UTC 2007  
x86_64 GNU/Linux

Package: libc6
Version: 2.3.6.ds1-13

bridge-utils  1.2-1
xen-hypervisor-3.0.3-1-am 3.0.3-0-2 The Xen  
Hypervisor on AMD64

xen-utils-3.0.3-1 3.0.3-0-2
xen-utils-common  3.0.3-0-2
vlan  1.9-2


andreas noback---End Message---
---BeginMessage---
Version: 2.6.25-1

upstream merged paravirt_ops Xen. it features enhanced netxen
and block modules.

as this code got rewritten old bug no longer apply.
for guest system it is recommend to upgrade to newer xen.
for more infos on upstream merge status see
http://wiki.xensource.com/xenwiki/XenParavirtOps

for latest 2.6.26-rc8 linux images see
http://wiki.debian.org/DebianKernel

thanks for your report.

-- 
maks

---End Message---


Bug#414890: marked as done (linux-image-2.6.18-4-xen-686: domU NFS server crashes dom0)

2008-07-06 Thread Debian Bug Tracking System

Your message dated Sun, 6 Jul 2008 11:26:50 +0200
with message-id [EMAIL PROTECTED]
and subject line Re: linux-image-2.6.18-4-xen-686: domU NFS server crashes dom0
has caused the Debian Bug report #414890,
regarding linux-image-2.6.18-4-xen-686: domU NFS server crashes dom0
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
414890: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414890
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
---BeginMessage---
Package: linux-image-2.6.18-4-xen-686
Version: 2.6.18.dfsg.1-11
Severity: normal


Hello. I run a Xen 2.8.18-4 kernel on my server. One of the domU's is an 
NFS file server. When I mount an NFS share on my desktop and upload a 
few gigabyte of information quickly then the entire dom0 on the server 
crashes, leaves a bunch of Message from syslogd@mydom0 on the 
console, hangs and needs to be rebooted.

After the reboot no crash information can be found on the system. 
/var/log/kern.log, /var/log/dmesg.*, /var/log/messages and 
/var/log/xen/xend.log are all clean.

The only way I can think of to capture the crash data is a serial 
console. I don't have one so I don't have a crash log. Sorry :-(

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

---End Message---
---BeginMessage---
Version: 2.6.25-1

upstream merged paravirt_ops Xen. it features enhanced netxen
and block modules.

as this code got rewritten old bug no longer apply.
for guest system it is recommend to upgrade to newer xen.
for more infos on upstream merge status see
http://wiki.xensource.com/xenwiki/XenParavirtOps

for latest 2.6.26-rc8 linux images see
http://wiki.debian.org/DebianKernel

thanks for your report.


-- 
maks

---End Message---


Bug#416659: marked as done (forcedeth doesnot work in combination with vlan and brigde)

2008-07-06 Thread Debian Bug Tracking System

Your message dated Fri, 4 Jul 2008 22:33:36 +0200
with message-id [EMAIL PROTECTED]
and subject line Re: xen-linux-system-2.6.18-4-xen-686: Prevents ALSA from 
finding soundcards
has caused the Debian Bug report #416659,
regarding forcedeth doesnot work in combination with vlan and brigde
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
416659: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416659
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
---BeginMessage---

Package: linux-image-2.6.18-4-xen-amd64
Version: 2.6.18.dfsg.1-11

For a xen installation on a sun fire 4200m2 I tried to bridge a vlan on 
eth0 (forcedeth-driver) with a vifx.x of one of the domUs. The network 
of the domU does not work at all.


I use the following custom script (peth0 is the renamed eth0)

# vlan 1103
   if ! `lsmod | grep -q 8021q` ; then modprobe 8021q ; fi
   vconfig add peth0 1103

   brctl addbr xenbr103
   brctl stp xenbr103 off
   brctl setfd xenbr103 0
   ip link set xenbr103 arp off
   ip link set xenbr103 multicast off
   ip link set peth0.1103 up
   brctl addif xenbr103 peth0.1103
   ip link set xenbr103 up

the xen script add the vif interface when I start the domU.

# brctl show
bridge name bridge id   STP enabled interfaces
xenbr0  8000.feff   no  vif0.0
   peth2
xenbr1038000.feff   no  peth0.1103
   vif2.0


if I look at the macs I cannot see the router
# brctl showmacs xenbr103
port no mac addris local?   ageing timer
 2 00:16:3e:25:05:bc   no24.74
 1 fe:ff:ff:ff:ff:ff   yes0.00

On eth2 (an interface with e1000 driver) the same configuration works. A 
bridge without a vlan works and a vlan without bridge works too.


I am using:

Linux xen-7 2.6.18-4-xen-amd64 #1 SMP Wed Feb 21 16:02:59 UTC 2007 
x86_64 GNU/Linux

Package: libc6
Version: 2.3.6.ds1-13

bridge-utils  1.2-1
xen-hypervisor-3.0.3-1-am 3.0.3-0-2 The Xen Hypervisor 
on AMD64

xen-utils-3.0.3-1 3.0.3-0-2
xen-utils-common  3.0.3-0-2  
vlan  1.9-2



andreas noback

---End Message---
---BeginMessage---
Version: 2.6.25-1

upstream merged paravirt_ops Xen. it features enhanced netxen
and block modules.

as this code got rewritten old bug no longer apply.
for guest system it is recommend to upgrade to newer xen.
for more infos on upstream merge status see
http://wiki.xensource.com/xenwiki/XenParavirtOps

for latest 2.6.26-rc8 linux images see
http://wiki.debian.org/DebianKernel

thanks for your report.

-- 
maks

---End Message---


Bug#416524: marked as done (linux-image-2.6.18-3-xen-686: kernel BUG at fs/fuse/control.c:82!)

2008-07-06 Thread Debian Bug Tracking System

Your message dated Sun, 6 Jul 2008 11:26:50 +0200
with message-id [EMAIL PROTECTED]
and subject line Re: linux-image-2.6.18-4-xen-686: domU NFS server crashes dom0
has caused the Debian Bug report #416524,
regarding linux-image-2.6.18-3-xen-686: kernel BUG at fs/fuse/control.c:82!
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
416524: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416524
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
---BeginMessage---
Package: linux-image-2.6.18-3-xen-686
Version: 2.6.18-8
Severity: normal


I have a directory on a remote machine mounted to my machine via
sshfs.  Earlier today there was a networking issue, which I
suspect is related to the bug.  For over an hour my machine was
unable to see the remote machine.  I had forgotten that I had
the directory mounted, until hours later syslog notified me that
there had been an oops.  I am not aware of anything that would
have tried to access the sshfs filesystem before the oops.

Without rebooting or remounting the sshfs filesystem, I can
access it now.

Here is the oops:

Mar 28 17:24:50 marmite kernel: kernel BUG at fs/fuse/control.c:82!
Mar 28 17:24:50 marmite kernel: invalid opcode:  [#1]
Mar 28 17:24:50 marmite kernel: SMP 
Mar 28 17:24:50 marmite kernel: Modules linked in: nls_cp437 vfat fat sd_mod 
usb_storage scsi_mod tun nls_iso8859_1 ncpfs binfmt_misc nbd ipv6 aoe fuse 
tsdev snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss 
snd_pcm snd_timer snd i2c_i801 soundcore snd_page_alloc i2c_core serial_core 
psmouse floppy rtc intel_rng pcspkr intel_agp agpgart shpchp pci_hotplug evdev 
serio_raw ext3 jbd mbcache dm_mirror dm_snapshot dm_mod ide_cd cdrom ide_disk 
piix e100 mii generic ide_core ehci_hcd uhci_hcd usbcore thermal processor fan
Mar 28 17:24:50 marmite kernel: CPU:0
Mar 28 17:24:50 marmite kernel: EIP:0061:[f49d4d65]Not tainted VLI
Mar 28 17:24:50 marmite kernel: EFLAGS: 00010202   (2.6.18-3-xen-686 #1) 
Mar 28 17:24:50 marmite kernel: EIP is at fuse_ctl_add_dentry+0x16/0xcb [fuse]
Mar 28 17:24:50 marmite kernel: eax: c0621744   ebx: c0621744   ecx: ded63d80   
edx: cd044d80
Mar 28 17:24:50 marmite kernel: esi: cd044d80   edi: cd044d80   ebp: c02cfc40   
esp: ded63d44
Mar 28 17:24:50 marmite kernel: ds: 007b   es: 007b   ss: 0069
Mar 28 17:24:50 marmite kernel: Process mount (pid: 6332, ti=ded62000 
task=f229e550 task.ti=ded62000)
Mar 28 17:24:50 marmite kernel: Stack:   c0621744 ded63d80 
cd044d80  f49d4e6f 4140 
Mar 28 17:24:50 marmite kernel:0002 c02cfc40 c0288ca0 ded63d80 
f49d54eb 0004  c0170034 
Mar 28 17:24:50 marmite kernel:ded63db0  c01b2f9c ed753201 
460a88c2 0cdac0dd ed753200 ed753200 
Mar 28 17:24:50 marmite kernel: Call Trace:
Mar 28 17:24:50 marmite kernel:  [f49d4e6f] fuse_ctl_add_conn+0x55/0xb9 [fuse]
Mar 28 17:24:50 marmite kernel:  [c0170034] seq_read+0x201/0x279
Mar 28 17:24:50 marmite kernel:  [c01b2f9c] idr_get_new+0xa/0x26
Mar 28 17:24:50 marmite kernel:  [f49d4f2e] fuse_ctl_fill_super+0x5b/0xb9 
[fuse]
Mar 28 17:24:50 marmite kernel:  [c015aee0] get_sb_single+0x51/0x97
Mar 28 17:24:50 marmite kernel:  [f49d4ed3] fuse_ctl_fill_super+0x0/0xb9 
[fuse]
Mar 28 17:24:50 marmite kernel:  [c015add7] vfs_kern_mount+0x7d/0xf2
Mar 28 17:24:50 marmite kernel:  [f49d4ed3] fuse_ctl_fill_super+0x0/0xb9 
[fuse]
Mar 28 17:24:50 marmite kernel:  [c015ae7e] do_kern_mount+0x25/0x36
Mar 28 17:24:50 marmite kernel:  [c016d3b0] do_mount+0x5d8/0x648
Mar 28 17:24:50 marmite kernel:  [c016c64e] mntput_no_expire+0x11/0x6a
Mar 28 17:24:50 marmite kernel:  [c01628a8] link_path_walk+0xb3/0xbd
Mar 28 17:24:50 marmite kernel:  [c014642a] __handle_mm_fault+0x63b/0xb12
Mar 28 17:24:50 marmite kernel:  [c013abc6] find_get_page+0x37/0x3c
Mar 28 17:24:50 marmite kernel:  [c013ea5b] get_page_from_freelist+0x96/0x35b
Mar 28 17:24:50 marmite kernel:  [c013ebac] get_page_from_freelist+0x1e7/0x35b
Mar 28 17:24:50 marmite kernel:  [c016c2b6] copy_mount_options+0x26/0x109
Mar 28 17:24:50 marmite kernel:  [c016d48d] sys_mount+0x6d/0xaa
Mar 28 17:24:50 marmite kernel:  [c010480b] syscall_call+0x7/0xb
Mar 28 17:24:50 marmite kernel: Code: fa 50 89 e8 53 e8 c2 c0 79 cb 83 c4 14 83 
c4 20 5b 5e 5f 5d c3 55 57 56 89 d6 53 83 ec 08 83 ba ac 00 00 00 02 8b 6c 24 
24 7e 08 0f 0b 52 00 d9 54 9d f4 89 ca e8 b8 41 79 cb 85 c0 89 c7 0f 84 
Mar 28 17:24:50 marmite kernel: EIP: [f49d4d65] fuse_ctl_add_dentry+0x16/0xcb 
[fuse] SS:ESP 0069:ded63d44

I apologise if this is a DUP, but I didn't see anything that
mentioned fuse.

-- System Information:

Bug#417594: marked as done (kernel module file corruption on reboot)

2008-07-06 Thread Debian Bug Tracking System

Your message dated Sun, 6 Jul 2008 11:30:22 +0200
with message-id [EMAIL PROTECTED]
and subject line Re: kernel module file corruption on reboot
has caused the Debian Bug report #417594,
regarding kernel module file corruption on reboot
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
417594: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=417594
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
---BeginMessage---
Package: linux-image-2.6.18-4-amd64
Version: 2.6.18.dfsg.1-12

Please note that this bug also affects the latest Debian amd64
experimental kernel linux-image-2.6.20-1-amd64, version:
2.6.20-1~experimental.1~snapshot.8402

About every 5 reboots, my kernel module directories will get corrupted
-- if I'm very careful and shut down first, boinc running in a 32-bit
chroot and second, GDM. If I just type in shutdown -h now in an xterm,
it almost guarantees corruption.

The most common corrupted file is tg3.ko and its parent directories. 

No other filesystems experience corruption. No other directories
experience corruption. Only the kernel module files/directories of the
running kernel are corrupted.

Annoying workaround:
1) reboot into rescue kernel
2) turn off networking / portmap
3) remount readonly
4) run fsck on root partition where the module files are stored
5) remount read/write
6) dpkg -i /home/user/saved_kernel.deb

Hardware:
Dual opteron 244s
MSI K8T Master2-FAR motherboard
via K8t8000 chipset
RAM with ECC turned off because the motherboard doesn't like x8bit ECC
and I can't afford to burn more $ on 2GB of new x4bit ECC RAM.

Here is some weirdness in dmesg with the hard drive. It has always had
this message, even when it was running on 32-bit kernels, but even then
I never experienced filesystem corruption with it.

hda: Maxtor 94098H6, ATA DISK drive
hda: max request size: 128KiB
hda: 80043264 sectors (40982 MB) w/2048KiB Cache, CHS=65535/16/63
hda: cache flushes not supported
 hda: hda1 hda2 hda3 hda4
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: cache flushes not supported
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown

Software:
Debian unstable + above mentioned kernels
All partitions are ext3 with internal journals mounted in data=ordered
mode and all defaults.


Linux version 2.6.20-1-amd64 (Debian 2.6.20-1~experimental.1~snapshot.8402) 
([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) 
#1 SMP Fri Mar 30 01:08:49 CEST 2007
Command line: root=/dev/hda3 ro 
BIOS-provided physical RAM map:
 BIOS-e820:  - 000a (usable)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 7fee (usable)
 BIOS-e820: 7fee - 7fee3000 (ACPI NVS)
 BIOS-e820: 7fee3000 - 7fef (ACPI data)
 BIOS-e820: 7fef - 7ff0 (reserved)
 BIOS-e820: fec0 - 0001 (reserved)
Entering add_active_range(0, 0, 160) 0 entries of 3200 used
Entering add_active_range(0, 256, 524000) 1 entries of 3200 used
end_pfn_map = 1048576
DMI 2.3 present.
ACPI: RSDP (v000 VIAK8 ) @ 0x000f6980
ACPI: RSDT (v001 VIAK8  AWRDACPI 0x42302e31 AWRD 0x) @ 
0x7fee3000
ACPI: FADT (v001 VIAK8  AWRDACPI 0x42302e31 AWRD 0x) @ 
0x7fee3040
ACPI: MADT (v001 VIAK8  AWRDACPI 0x42302e31 AWRD 0x) @ 
0x7fee7b40
ACPI: DSDT (v001 VIAK8  AWRDACPI 0x1000 MSFT 0x010e) @ 
0x
Scanning NUMA topology in Northbridge 24
Number of nodes 2
Node 0 MemBase  Limit 7fee
Entering add_active_range(0, 0, 160) 0 entries of 3200 used
Entering add_active_range(0, 256, 524000) 1 entries of 3200 used
Skipping disabled node 1
NUMA: Using 63 for the hash shift.
Using node hash shift of 63
Bootmem setup node 0 -7fee
Zone PFN ranges:
  DMA 0 - 4096
  DMA324096 -  1048576
  Normal1048576 -  1048576
early_node_map[2] active PFN ranges
0:0 -  160
0:  256 -   524000
On node 0 totalpages: 523904
  DMA zone: 56 pages used for memmap
  DMA zone: 970 pages reserved
  DMA zone: 2974 pages, LIFO batch:0
  DMA32 zone: 7108 pages used for memmap
  DMA32 zone: 512796 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x4008
ACPI: 

Bug#489470: linux-image-2.6.25-2-amd64: pciehp stops working in 2.5.25, worked in 2.6.24

2008-07-06 Thread maximilian attems
On Sun, Jul 06, 2008 at 04:44:17AM +0200, Marc Lehmann wrote:
 Package: linux-image-2.6.25-2-amd64
 Version: 2.6.25-6
 Severity: normal
 
 
 pciehp stopped working after upgrading to 2.6.25.
 
 (note that the nvidia kernel module was only loaded _after_ the problem
 occured so the kernel was not tainted)
 
 to my knowledge, the bc4328 device was never pci-hotplugged before, so it
 is unclear what 0c:00.0 has to do with pciehp.
 
please try out 2.6.26-rc8, see trunk apt lines
- http://wiki.debian.org/DebianKernel

thanks 

-- 
maks



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



Bug#407217: RTL-8169 multicast bug

2008-07-06 Thread Mikhail Gusarov

BTW, there are two more similara bugreports: #486442 and #488495

-- 


pgpD8mUDzphL2.pgp
Description: PGP signature


Bug#407217: RTL-8169 multicast bug

2008-07-06 Thread Martin Michlmayr
* Mikhail Gusarov [EMAIL PROTECTED] [2008-07-06 21:06]:
 BTW, there are two more similara bugreports: #486442 and #488495

Can you please mail Francois Romieu [EMAIL PROTECTED] and
[EMAIL PROTECTED] with an explanation of the problem?
-- 
Martin Michlmayr
http://www.cyrius.com/



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



Bug#481104: [Pkg-cryptsetup-devel] /usr/sbin/update-initramfs: update-initramfs edits /etc/initramfs-tools/conf.d/cryptroot

2008-07-06 Thread maximilian attems
On Sun, Jul 06, 2008 at 04:13:18PM +0300, ??  wrote:
 maximilian attems wrote:
  On Sat, 05 Jul 2008, David Härdeman wrote:
 

  On Fri, Jul 04, 2008 at 11:56:59PM +0200, maximilian attems wrote:
  
  Look at that: (updating initrd, duplicates the content of the cryptroot
  config file...)
  
  right cryptsetup should maybe not write into /etc/i-t/conf.d
  but in /usr/share/i-t/conf.d but those could also be mounted ro?!?
 
  anyway i'd like to hear from cryptsetup maintainers before reassgning.

  I'm not sure I understand the question. The cryptsetup initramfs hook  
  writes its config file by doing:
 
  echo $OPTIONS  $DESTDIR/conf/conf.d/cryptroot
 
  If that is below /etc, that would be due to initramfs-tools, wouldn't  
  it?
  
 
  okay it was quite late yesterday, aboves should be in the initramfs
  itself. not sure if that bug report is not completly bogus
 
  it is saying that /etc/initramfs-tools/conf.d/cryptroot is modified
  on an update-initramfs -u run. i don't see any hook on my box
  that would do that.
 

 
 Hi again... The bug report is not bogus, in the sense that it happens.
 Everytime I run  update-initramfs -u, my
 /etc/initramfs-tools/conf.d/cryptroot gets an extra line
 target=lukspace,source=/dev/hda3,key=none,lvm=evg-root
 added.
 
 I do not know what these 'hooks' are, but I run update-initramfs -u with
 strace and I send you the output in case this might help you. I found a
 directory /etc/initramfs-tools/hooks, but it is empty. Is there
 something I can check and report back, in order to see why is this
 happening?
 
 Thanks!

right send output of
a) sh -x mkinitramfs -o /tmp/foo
b) sh -x update-initramfs -u


thanks

-- 
maks



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



Bug#489186: mention UUID

2008-07-06 Thread jidanni
I see in a Debian news blurb that update-grub will use UUID
automatically.

So some parts of the grub world are quite advanced. But one would
never know about it just reading the document this bug is about.



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



Bug#410807: Kernel OOPS with 2.6.18-6-xen-686 kernel package

2008-07-06 Thread Chris Samuel
With the current kernel:

Linux wimmera 2.6.18-6-xen-686 #1 SMP Sat Jun 7 02:07:48 UTC 2008 i686 GNU/Linux

We got a similar crash as to the one others have been reporting:

Jul  7 10:20:38 wimmera kernel: [ cut here ]
Jul  7 10:20:38 wimmera kernel: kernel BUG at drivers/xen/core/evtchn.c:481!
Jul  7 10:20:38 wimmera kernel: invalid opcode:  [#1]
Jul  7 10:20:38 wimmera kernel: SMP
Jul  7 10:20:38 wimmera kernel: Modules linked in: xt_tcpudp xt_physdev 
iptable_filter ip_tables x_tables bridge netloop button ac battery w83627hf 
eeprom lm92 w83793 w83781d hwmon_vid i2c_isa loop parport_pc parport i2c_i801 
psmouse f
loppy serial_core i2c_core serio_raw rtc pcspkr shpchp pci_hotplug tsdev evdev 
ext3 jbd mbcache dm_mirror dm_snapshot dm_mod ide_cd cdrom sd_mod usbhid piix 
mptfc mptscsih mptbase scsi_transport_fc uhci_hcd ehci_hcd ahci libata generic
 ide_core usbcore e1000 scsi_mod thermal processor fan
Jul  7 10:20:38 wimmera kernel: CPU:7
Jul  7 10:20:38 wimmera kernel: EIP:0061:[c020c4be]Not tainted VLI
Jul  7 10:20:38 wimmera kernel: EFLAGS: 00010046   (2.6.18-6-xen-686 #1)
Jul  7 10:20:38 wimmera kernel: EIP is at retrigger+0x1f/0x35
Jul  7 10:20:38 wimmera kernel: eax:    ebx: 0208   ecx: 0068   
edx: f55f6000
Jul  7 10:20:38 wimmera kernel: esi: c03193e0   edi: 0148   ebp:    
esp: c0e27eb0
Jul  7 10:20:38 wimmera kernel: ds: 007b   es: 007b   ss: 0069
Jul  7 10:20:38 wimmera kernel: Process xenwatch (pid: 29, ti=c0e26000 
task=c0eaf000 task.ti=c0e26000)
Jul  7 10:20:38 wimmera kernel: Stack: c013b241 c03193e0 0148 c0319408 
c013af95 c18f96c0  
Jul  7 10:20:38 wimmera kernel:c18f96c0 c0217464  c0217844 
c02109d3 0010  060d
Jul  7 10:20:38 wimmera kernel:060c   e6ba1cb5 
c02e67a4 ee518000  0002
Jul  7 10:20:38 wimmera kernel: Call Trace:
Jul  7 10:20:38 wimmera kernel:  [c013b241] check_irq_resend+0x41/0x48
Jul  7 10:20:38 wimmera kernel:  [c013af95] enable_irq+0x72/0x89
Jul  7 10:20:38 wimmera kernel:  [c0217464] __netif_up+0xb/0x13
Jul  7 10:20:38 wimmera kernel:  [c0217844] netif_map+0x247/0x26f
Jul  7 10:20:38 wimmera kernel:  [c02109d3] xs_talkv+0xe3/0x128
Jul  7 10:20:38 wimmera kernel:  [c0210d1c] xenbus_read+0x34/0x3b
Jul  7 10:20:38 wimmera kernel:  [c02110de] xenbus_scanf+0x18/0x4d
Jul  7 10:20:38 wimmera kernel:  [c0216ed5] frontend_changed+0x29f/0x4a8
Jul  7 10:20:38 wimmera kernel:  [c02120bc] otherend_changed+0x74/0x79
Jul  7 10:20:38 wimmera kernel:  [c0210856] xenwatch_handle_callback+0x12/0x44
Jul  7 10:20:38 wimmera kernel:  [c021129b] xenwatch_thread+0x105/0x11b
Jul  7 10:20:38 wimmera kernel:  [c012b701] autoremove_wake_function+0x0/0x2d
Jul  7 10:20:38 wimmera kernel:  [c0211196] xenwatch_thread+0x0/0x11b
Jul  7 10:20:38 wimmera kernel:  [c012b635] kthread+0xc0/0xeb
Jul  7 10:20:38 wimmera kernel:  [c012b575] kthread+0x0/0xeb
Jul  7 10:20:38 wimmera kernel:  [c010293d] kernel_thread_helper+0x5/0xb
Jul  7 10:20:38 wimmera kernel: Code: ee 85 f6 75 96 58 5a 5b 5e 5f 5d c3 0f b7 
0c 85 40 b8 37 c0 8b 15 84 19 2d c0 85 c9 74 1d 0f a3 8a 80 08 00 00 19 c0 85 
c0 75 08 0f 0b e1 01 92 1a 2b c0 f0 0f ab 8a 00 08 00 00 b8 01 00 00 00
Jul  7 10:20:38 wimmera kernel: EIP: [c020c4be] retrigger+0x1f/0x35 SS:ESP 
0069:c0e27eb0


We've now applied the fix from Hans here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=410807#60

and have gone from this:

wimmera ~ # xm vcpu-list
Name  ID VCPUs   CPU State   Time(s) CPU Affinity
Domain-0   0 0 3   -b- 164.6 any cpu
Domain-0   0 1 5   -b-  24.7 any cpu
Domain-0   0 2 1   -b-  35.0 any cpu
Domain-0   0 3 1   -b-  23.5 any cpu
Domain-0   0 4 6   -b-  21.0 any cpu
Domain-0   0 5 4   -b-  26.1 any cpu
Domain-0   0 6 2   -b-  39.1 any cpu
Domain-0   0 7 0   r--  26.5 any cpu
[...]

to this:

wimmera ~ # xm vcpu-list
Name  ID VCPUs   CPU State   Time(s) CPU Affinity
Domain-0   0 0 7   r--  20.8 any cpu
[...]

Fingers crossed that this fixes the oops.. :-(

Hope this helps someone else!

cheers,
Chris
-- 
Christopher Samuel - (03) 9925 4751 - Systems Manager
 The Victorian Partnership for Advanced Computing
 P.O. Box 201, Carlton South, VIC 3053, Australia
VPAC is a not-for-profit Registered Research Agency



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