Bug#573264: marked as done (Hangcheck timer elapsed... is back with i915 + 2.6.33)

2011-04-27 Thread Debian Bug Tracking System
Your message dated Wed, 27 Apr 2011 09:17:18 +0200
with message-id 20110427071718.ga14...@radis.liafa.jussieu.fr
and subject line Re: Bug#573264: Hangcheck timer elapsed... is back with i915 
+ 2.6.33
has caused the Debian Bug report #573264,
regarding Hangcheck timer elapsed... is back with i915 + 2.6.33
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 ow...@bugs.debian.org
immediately.)


-- 
573264: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573264
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: xserver-xorg-video-intel
Version: 2:2.9.1-2
Severity: Important
Justification: Frequent crashes on specific hardware

Heyho!

Opening a new bug since errors are slightly different from what I've seen 
reported with earlier kernel/X.

Symptom:
X suddenly goes black during some (unspecified) actions (opening menus, 
resizing windows, ...); this time instead of a mouse counter there is a text 
cursor (non-blinking underline) top left of the screen.

Changing to text console is not possible.  ssh is fine, restarting X is not 
possible.

Messages:
dmesg ends with:
[ 5559.16] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... 
GPU hung
[ 5559.100019] render error detected, EIR: 0x
[ 5559.100249] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns 
-5 (awaiting 425747 at 425735)

Xorg.0.log ends with:
+++
Fatal server error:
Failed to submit batchbuffer: Input/output error


Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.
Please also check the log file at /var/log/Xorg.0.log for additional 
information.

(II) AIGLX: Suspending AIGLX clients for VT switch
+++

kernel is 2.6.33-1~experimental.2
X is 2:1.7.5-1 (xserver-xorg-core); rest of the system is a fairly up to 
date squeeze.

Now trying with mem=400M (on a 512M box) - this didn't get us anywhere.

Compositing was disabled.  Enabling compositing gets us this crash 
immediately instead only sporadically.


cheers
-- vbi

-- 
BOFH excuse #333:

A plumber is needed, the network drain is clogged


signature.asc
Description: This is a digitally signed message part.
---End Message---
---BeginMessage---
http://www.debian.org/News/2011/20110423

Closing :(

Cheers,
Julien

---End Message---


Bug#611954: Realtek Card RTL8111/8168B working here

2011-04-27 Thread Sebastian Niehaus
Just for the record: I have a RTL8111/8168B card working fine on Squeeze
AMD64. 




,[ lspci -v ]
|
| [...]
| 
| 
| 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B 
PCI Express Gigabit Ethernet controller (rev 03)
| Subsystem: Micro-Star International Co., Ltd. Device 7599
| Flags: bus master, fast devsel, latency 0, IRQ 28
| I/O ports at e800 [size=256]
| Memory at fdfff000 (64-bit, prefetchable) [size=4K]
| Memory at fdff8000 (64-bit, prefetchable) [size=16K]
| Expansion ROM at fe9e [disabled] [size=128K]
| Capabilities: [40] Power Management version 3
| Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
| Capabilities: [70] Express Endpoint, MSI 01
| Capabilities: [ac] MSI-X: Enable- Count=4 Masked-
| Capabilities: [cc] Vital Product Data
| Capabilities: [100] Advanced Error Reporting
| Capabilities: [140] Virtual Channel
| Capabilities: [160] Device Serial Number 03-00-00-00-68-4c-e0-00
| Kernel driver in use: r8169
`


During initialisation it tries to patch its firmware but doesn't
succeed. 


,[ /var/log/syslog ]
| Apr 26 15:33:27 ceramic kernel: [0.677891] r8169 Gigabit Ethernet driver 
2.3LK-NAPI loaded
| Apr 26 15:33:27 ceramic kernel: [0.677908] r8169 :05:00.0: PCI INT A 
- GSI 17 (level, low) - IRQ 17
| Apr 26 15:33:27 ceramic kernel: [0.677946] r8169 :05:00.0: setting 
latency timer to 64
| Apr 26 15:33:27 ceramic kernel: [0.677988]   alloc irq_desc for 29 on 
node 0
| Apr 26 15:33:27 ceramic kernel: [0.677989]   alloc kstat_irqs on node 0
| Apr 26 15:33:27 ceramic kernel: [0.678001] r8169 :05:00.0: irq 29 for 
MSI/MSI-X
| Apr 26 15:33:27 ceramic kernel: [0.678428] eth0: RTL8168d/8111d at 
0xc9c64000, 6c:62:de:ad:be:ef, XID 081000c0 IRQ 29
| Apr 26 15:33:27 ceramic kernel: [0.685110] eth0: unable to apply firmware 
patch
`

Anyway, networking works fine here. (Okay, I did no performance tests).


See also: http://thread.gmane.org/gmane.linux.network/179166/focus=1069855



pgpXYcvtW5S7Z.pgp
Description: PGP signature


Bug#624297: build-linux-kbuild.sh: add support for -rcX kernels (needs version mangling)

2011-04-27 Thread Andreas Beckmann
Package: linux-kbuild-2.6
Severity: normal
Tags: patch

Hi,

attached is a patch for the build-linux-kbuild.sh referenced from
http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage

It adds support for -rcX kernels by doing version mangling from -rcX to
~rcX as needed by Debian.

Also it would be nice if the build-linux-kbuild.sh would be kept in the
SVN repository and a comment like the following be added to the script:

  # The latest version of this script can be retrived via
  # svn export URL/build-linux-kbuild.sh

Andreas


-- System Information:
Debian Release: 6.0.1
  APT prefers stable
  APT policy: (800, 'stable'), (700, 'testing'), (600, 'unstable'), (500, 
'stable-updates'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- build-linux-kbuild.orig.sh  2010-11-12 17:55:22.0 +0100
+++ build-linux-kbuild.sh   2011-04-27 08:50:17.770352638 +0200
@@ -9,11 +9,12 @@
 # changelog)
 
 set -ex
-VERSION=2.6.36
+UPSTREAM_VERSION=2.6.39-rc4
+VERSION=$(echo ${UPSTREAM_VERSION} | sed -e 's/-rc/~rc/')
 DEBIAN_VERSION=${VERSION}-1~experimental.1
 CHANGELOG_MESSAGE=${VERSION}
 
-[ -e linux-${VERSION}.tar.bz2 ]
+[ -e linux-${UPSTREAM_VERSION}.tar.bz2 ]
 
 cleanme=orig linux-kbuild-2.6 linux-kbuild-2.6-${VERSION}
 
@@ -31,7 +32,7 @@
 
 cd linux-kbuild-2.6
 dch -v ${DEBIAN_VERSION} ${CHANGELOG_MESSAGE}
-./debian/bin/genorig.py ../linux-${VERSION}.tar.bz2
+./debian/bin/genorig.py ../linux-${UPSTREAM_VERSION}.tar.bz2
 cd ..
 tar -xzf orig/linux-kbuild-2.6_${VERSION}.orig.tar.gz
 cd linux-kbuild-2.6-${VERSION}


Schenk moeder een abonnement en ontvang zelf een leuk cadeau!

2011-04-27 Thread Abonnementen . be
Schenk moeder een abonnement op een kwaliteitsmagazine. 
Je ontvangt zelf een leuk cadeau. 

Bekijk hier onze nederlandstalige selectie:
http://www.abonnementen.be/moederdag

Bekijk hier onze franstalige selectie:
http://www.abonnements.be/fetedesmeres

Aanbod geldig tot 15/05/2011 of zolang de voorraad strekt.Klik hier indien je 
niet langer commerciële mails van Abonnementen.be wenst te 
ontvangen.http://messagent.roulartamail.be/optiext/optiextension.dll?ID=eQheK64ZnzJJezam_Br4nMFlfJM8fceKqVc4qCNdOnjuYzBeM

Bug#623584: marked as done (grub error: libm.so.6: cannot open shared object file: No such file or directory)

2011-04-27 Thread Debian Bug Tracking System
Your message dated Wed, 27 Apr 2011 11:24:32 +0200
with message-id 1303896272.6044.20.camel@scarafaggio
and subject line Re: Bug#623584: initramfs-tools create a wrong directory tree
has caused the Debian Bug report #623584,
regarding grub error: libm.so.6: cannot open shared object file: No such file 
or directory
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 ow...@bugs.debian.org
immediately.)


-- 
623584: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623584
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: initramfs-tools
Version: 0.98.8
Severity: important

Hi all,
I am trying to setup a 64 bit machine with Debian squeeze. After the
installation complete (this is a special crafted installation with mixed
32bit and 64bit executables) the machine cannot boot anymore.

The bootloader is grub-pc. It starts, then load kernel and initrd,
uncompress initrd and tries to run the shell. This is where it fails
giving the error libm.so.6: cannot open shared object file: No such
file or directory.

I booted via a cdrom (debian 6.0 live rescue amd64), mounted all volumes
in /mnt (and subdirs) and chroot'ed into it.

Then, I went to /boot and uncompress the initrd image. This is what I
can see:

root@debian:/boot/f# ls -l
total 36
drwxr-xr-x 2 root root 4096 Apr 21 15:07 bin
drwxr-xr-x 3 root root 4096 Apr 21 14:28 conf
drwxr-xr-x 5 root root 4096 Apr 21 14:28 etc
-rwxr-xr-x 1 root root 5955 Apr 21 14:28 init
drwxr-xr-x 4 root root 4096 Apr 21 14:28 lib
drwxr-xr-x 2 root root 4096 Apr 21 14:28 lib64
drwxr-xr-x 2 root root 4096 Apr 21 14:28 sbin
drwxr-xr-x 6 root root 4096 Apr 21 14:28 scripts
root@debian:/boot/f# ldd bin/sh
linux-vdso.so.1 =  (0x7936d000)
libm.so.6 = /lib64/libm.so.6 (0x7f0146f8b000)
libc.so.6 = /lib64/libc.so.6 (0x7f0146c2a000)
/lib64/ld-linux-x86-64.so.2 (0x7f0147213000)
root@debian:/boot/f# ls -l /lib64/libm.so.6 /lib64/libc.so.6 
/lib64/ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root 12 Apr 19 18:57 /lib64/ld-linux-x86-64.so.2 - 
ld-2.11.2.so
lrwxrwxrwx 1 root root 14 Apr 19 18:57 /lib64/libc.so.6 - libc-2.11.2.so
lrwxrwxrwx 1 root root 14 Apr 19 18:57 /lib64/libm.so.6 - libm-2.11.2.so
root@debian:/boot/f# ls -l lib64/libm.so.6 lib64/libc.so.6 
lib64/ld-linux-x86-64.so.2
-rwxr-xr-x 1 root root  128744 Apr 21 14:28 lib64/ld-linux-x86-64.so.2
-rwxr-xr-x 1 root root 1432968 Apr 21 14:28 lib64/libc.so.6
-rw-r--r-- 1 root root  530736 Apr 21 14:28 lib64/libm.so.6
root@debian:/boot/f# bin/sh


BusyBox v1.17.1 (Debian 1:1.17.1-8) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/boot/f # exit
root@debian:/boot/f# chroot . bin/sh
bin/sh: error while loading shared libraries: libm.so.6: cannot open shared 
object file: No such file or directory
root@debian:/boot/f# chroot . lib64/ld-linux-x86-64.so.2 bin/sh
bin/sh: error while loading shared libraries: libm.so.6: cannot open shared 
object file: No such file or directory
root@debian:/boot/f# file bin/sh lib64/libm.so.6
bin/sh:  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
dynamically linked (uses shared libs), stripped
lib64/libm.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
root@debian:/boot/f# diff /lib64/libc-2.11.2.so lib64/libc.so.6 
root@debian:/boot/f# diff /lib64/libm-2.11.2.so lib64/libm.so.6 

As you may see all program work correctly. I may even run busybox on the
main system, but if I try to run it inside the initramfs image then it
fails.

I tried to create the initrd image from scratch but it does not solve
the problem. The command I used is:

root@debian:/boot/f# update-initramfs -k all -u
update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
W: Possible missing firmware /lib/firmware/tigon/tg3_tso5.bin for module tg3
W: Possible missing firmware /lib/firmware/tigon/tg3_tso.bin for module tg3
W: Possible missing firmware /lib/firmware/tigon/tg3.bin for module tg3

Any hints on what to do next?

I thank you very much,
Giuseppe



---End Message---
---BeginMessage---
Hi Ben,
thanks for helping on this bug report.

On ven, 2011-04-22 at 15:35 +0100, Ben Hutchings wrote:
 On Fri, 2011-04-22 at 09:36 +0200, Giuseppe Sacco wrote:
  Hi,
  I made a few tests on this report and I found that the loader is not
  looking at the right directories. Please have a look at this:
 [...]
  Please note that on both system (outside of chroot) /lib64 is a link
  to /lib.
 
 I think that's normal; however /lib should be higher up the library
 search path than /lib64.
 
 What does 'ldd /bin/sh' say 

Bug#624307: xen-linux-system-2.6.32-5-xen-amd64: lvm causes kernel panic - kernel BUG at arch/x86/xen/mmu.c:1860!

2011-04-27 Thread Jörg Stephan
Package: xen-linux-system-2.6.32-5-xen-amd64
Version: 2.6.32-31
Severity: normal
Tags: upstream

kernel BUG at arch/x86/xen/mmu.c:1860!

lvm causes a kernelpanic while executing several lvm commands like
create/rename/resize/display.

The bug is already fxed in the upstream package and need to be applied
in the debian package too. The failure causes the whole system to stop.

The bug is described by the following syslog output:

Dec 26 15:58:29 xen01 kernel: kernel BUG at arch/x86/xen/mmu.c:1860!
Dec 26 15:58:29 xen01 kernel: invalid opcode:  [#1] SMP
Dec 26 15:58:29 xen01 kernel: last sysfs file: /sys/block/dm-26/dev
Dec 26 15:58:29 xen01 kernel: CPU 0
Dec 26 15:58:29 xen01 kernel: Modules linked in: ipt_MASQUERADE
iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state
nf_conntrack ipt_REJECT xt_tcpudp xt_physdev iptable_filter ip_tables
x_tables bridge stp be2iscsi iscsi_tcp bnx2i cnic uio ipv6 cxgb3i cxgb3
mdio libiscsi_tcp libiscsi scsi_transport_iscsi loop dm_multipath
scsi_dh video backlight output sbs sbshc power_meter hwmon battery
acpi_memhotplug xen_acpi_memhotplug ac parport_pc lp parport sg tpm_tis
tpm tpm_bios button i2c_i801 i2c_core iTCO_wdt e1000e shpchp pcspkr
dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_mod usb_storage
ahci libata sd_mod scsi_mod raid1 ext3 jbd uhci_hcd ohci_hcd ehci_hcd
[last unloaded: microcode]
Dec 26 15:58:29 xen01 kernel: Pid: 27998, comm: udevd Not tainted
2.6.32.27-0.xen.pvops.choon.centos5 #1 S3420GP
Dec 26 15:58:29 xen01 kernel: RIP: e030:[8100cb5b]
[8100cb5b] pin_pagetable_pfn+0x53/0x59
Dec 26 15:58:29 xen01 kernel: RSP: e02b:88003bc3bdc8  EFLAGS:
00010282
Dec 26 15:58:29 xen01 kernel: RAX: ffea RBX:
00017605 RCX: 00bb
Dec 26 15:58:29 xen01 kernel: RDX: deadbeef RSI:
deadbeef RDI: deadbeef
Dec 26 15:58:29 xen01 kernel: RBP: 88003bc3bde8 R08:
0028 R09: 8800
Dec 26 15:58:29 xen01 kernel: R10: deadbeef R11:
7fdb5665e600 R12: 0003
Dec 26 15:58:30 xen01 kernel: R13: 00017605 R14:
880012ee0780 R15: 7fdb56224268
Dec 26 15:58:30 xen01 kernel: FS:  7fdb56fed710()
GS:88002804f000() knlGS:
Dec 26 15:58:30 xen01 kernel: CS:  e033 DS:  ES:  CR0:
8005003b
Dec 26 15:58:30 xen01 kernel: CR2: 7fdb56224268 CR3:
3addb000 CR4: 2660
Dec 26 15:58:30 xen01 kernel: DR0:  DR1:
 DR2: 
Dec 26 15:58:30 xen01 kernel: DR3:  DR6:
0ff0 DR7: 0400
Dec 26 15:58:30 xen01 kernel: Process udevd (pid: 27998, threadinfo
88003bc3a000, task 880012ee0780)
Dec 26 15:58:30 xen01 kernel: Stack:
Dec 26 15:58:30 xen01 kernel:   00424121
00013f00ae20 00017605
Dec 26 15:58:30 xen01 kernel: 0 88003bc3be08 8100e07c
88003a3c2580 880034bb6588
Dec 26 15:58:30 xen01 kernel: 0 88003bc3be18 8100e0af
88003bc3be58 810a402f
Dec 26 15:58:31 xen01 kernel: Call Trace:
Dec 26 15:58:31 xen01 kernel:  [8100e07c]
xen_alloc_ptpage+0x64/0x69
Dec 26 15:58:31 xen01 kernel:  [8100e0af]
xen_alloc_pte+0xe/0x10
Dec 26 15:58:31 xen01 kernel:  [810a402f]
__pte_alloc+0x70/0xce
Dec 26 15:58:31 xen01 kernel:  [810a41cd]
handle_mm_fault+0x140/0x8b9
Dec 26 15:58:31 xen01 kernel:  [810d2ecc] ? d_kill+0x3a/0x42
Dec 26 15:58:31 xen01 kernel:  [810c4cd1] ? __fput+0x1cb/0x1da
Dec 26 15:58:31 xen01 kernel:  [8131be4d]
do_page_fault+0x252/0x2e2
Dec 26 15:58:31 xen01 kernel:  [81319dd5] page_fault+0x25/0x30
Dec 26 15:58:31 xen01 kernel: Code: 48 b8 ff ff ff ff ff ff ff 7f 48 21
c2 48 89 55 e8 48 8d 7d e0 be 01 00 00 00 31 d2 41 ba f0 7f 00 00 e8 e9
c7 ff ff 85 c0 74 04 0f 0b eb fe c9 c3 55 40 f6 c7 01 48 89 e5 53 48
89 fb 74 5b 48
Dec 26 15:58:31 xen01 kernel: RIP  [8100cb5b]
pin_pagetable_pfn+0x53/0x59
Dec 26 15:58:31 xen01 kernel:  RSP 88003bc3bdc8
Dec 26 15:58:31 xen01 kernel: ---[ end trace 540bcf6f0170242d ]---


-- System Information:
Debian Release: 6.0.1
  APT prefers stable
  APT policy: (900, 'stable'), (50, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xen-linux-system-2.6.32-5-xen-amd64 depends on:
pn  linux-image-2.6.32-5-xen-amd6 none (no description available)
ii  xen-hypervisor-4.0-amd64 [xen 4.0.1-2The Xen Hypervisor on AMD64

xen-linux-system-2.6.32-5-xen-amd64 recommends no packages.

xen-linux-system-2.6.32-5-xen-amd64 suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4db7e7de.2090...@key-systems.net



Bug#590105: Buffalo LS-CHL not supported yet

2011-04-27 Thread Martin Michlmayr
* Antonios Galanopoulos an...@goto10.org [2011-04-27 00:04]:
  Which device are you interested in?  Buffalo Linkstation Live (LS-CHL)
  or Buffalo Linkstation Mini (LS-WSGL)?
 
 Its a Linkstation Pro Duo. (LS-WTGL/R1)

Is this different to the normal Pro?  If so, it's not supported by the
upstream kernel and your best bet is to start by adding kernel
support.

-- 
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
Archive: http://lists.debian.org/20110427102027.gc14...@jirafa.cyrius.com



Bug#590105: Buffalo LS-CHL not supported yet

2011-04-27 Thread Antonios Galanopoulos

On Wed, 27 Apr 2011 11:20:27 +0100, Martin Michlmayr wrote:

* Antonios Galanopoulos an...@goto10.org [2011-04-27 00:04]:
 Which device are you interested in?  Buffalo Linkstation Live 
(LS-CHL)

 or Buffalo Linkstation Mini (LS-WSGL)?

Its a Linkstation Pro Duo. (LS-WTGL/R1)


Is this different to the normal Pro?  If so, it's not supported by 
the

upstream kernel and your best bet is to start by adding kernel
support.
I am not sure what the differences are. I have successfully booted it 
with foonas (http://foonas.org) via tftp and there it appears as a 
linkstation Pro in the dmesg logs. Same with debian but the Sata drives 
are not recognised.




--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ef0b7c35bd51edbdcc861fe750cb...@goto10.org



Bug#621803: Add support for /run directory

2011-04-27 Thread rleigh
On Tue, Apr 26, 2011 at 06:48:15PM +0200, Marco d'Itri wrote:
 On Apr 26, rleigh rle...@codelibre.net wrote:
 
  Testing with initramfs-tools (maks/run) with current unstable shows
  udev appearing to work correctly with it using /dev/.udev when /run
  is not present on the host system.  And also with /run present on
 Did you check with LVM and that all its persistent symlinks are still
 there?

I created a new kvm VM this morning which uses LVM, so I'll test
all the combinations later tonight.

  In a kvm VM, I do see some errors from udev at startup:
 These are unrelated and harmless (the errors are old, only the message
 is new).
 
   Why does /run should not be noexec?
  If /run/shm is also on /run (not a separate mount), it needs to be
  executable.
 Why do we need it executable?

From what I've read from past initscripts and other bug reports, it's
required for mmapping shared memory with PROT_EXEC, but I have not
verified this by writing a testcase.

Marco, have you tested this upgrade path?  That is /run in the
initramfs and no /run on the rootfs?  Is udev checking for that and
   No, but if the database is not copied to the initramfs then LVM will be
   annoyed.
  Which database is this?  Is this something that the LVM scripts need
  updating to handle?
 It is /dev/.udev/ or /run/udev/. I do not know exactly how LVM interacts
 with it, just that it must be preserved.

OK.  I feel that doing something like this:

if [ -d /run ]  [ ! -d /root/run ]; then
  mv /run/udev /dev/.udev
(or mv /run/udev /root/dev/.udev)
fi

at the point where we mount --move in the initramfs would be the
best action to take.  It preserves the udev state from the
initramfs when it would otherwise be lost.  In the case where
/run also exists on the rootfs, no action needs taking.

When I do the testing in my new VM, I'll test this type of change
as well.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature


Processed (with 1 errors): reassign 624307 to linux-image-2.6.32-5-xen-amd64, forcibly merging 613634 624307

2011-04-27 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 reassign 624307 linux-image-2.6.32-5-xen-amd64
Bug #624307 [xen-linux-system-2.6.32-5-xen-amd64] 
xen-linux-system-2.6.32-5-xen-amd64: lvm causes kernel panic - kernel BUG at 
arch/x86/xen/mmu.c:1860!
Bug reassigned from package 'xen-linux-system-2.6.32-5-xen-amd64' to 
'linux-image-2.6.32-5-xen-amd64'.
Bug No longer marked as found in versions linux-2.6/2.6.32-31.
 forcemerge 613634 624307
Bug#613634: linux-image-2.6.32-5-xen-amd64: Using pvcreate on a multipathed 
iscsi device produces a kernel bug
Bug#624307: xen-linux-system-2.6.32-5-xen-amd64: lvm causes kernel panic - 
kernel BUG at arch/x86/xen/mmu.c:1860!
Mismatch - only Bugs in the same package can be forcibly merged:
Bug 624307 is not in the same package as 613634
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
624307: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624307
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.130390951816555.transcr...@bugs.debian.org



Processed: severity of 624297 is wishlist

2011-04-27 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 severity 624297 wishlist
Bug #624297 [linux-kbuild-2.6] build-linux-kbuild.sh: add support for -rcX 
kernels (needs version mangling)
Severity set to 'wishlist' from 'normal'

 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
624297: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624297
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.130391128522921.transcr...@bugs.debian.org



Processed: reassign 624307 to linux-2.6, forcibly merging 613634 624307

2011-04-27 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 reassign 624307 linux-2.6
Bug #624307 [linux-image-2.6.32-5-xen-amd64] 
xen-linux-system-2.6.32-5-xen-amd64: lvm causes kernel panic - kernel BUG at 
arch/x86/xen/mmu.c:1860!
Bug reassigned from package 'linux-image-2.6.32-5-xen-amd64' to 'linux-2.6'.
 forcemerge 613634 624307
Bug#613634: linux-image-2.6.32-5-xen-amd64: Using pvcreate on a multipathed 
iscsi device produces a kernel bug
Bug#624307: xen-linux-system-2.6.32-5-xen-amd64: lvm causes kernel panic - 
kernel BUG at arch/x86/xen/mmu.c:1860!
Bug#610812: linux-image-2.6.32-5-xen-amd64: kernel BUG at 
/build/buildd-linux-2.6_2.6.32-29-amd64-xcs37n/.../x86/xen/mmu.c:1649
Bug#614400: linux-image-2.6.32-5-xen-amd64: Kernel Crash when initiating 
lvcreate or lvremove actions
Bug#615048: base: After removing lvm snapshot got kernel BUG at 
/build/.../source_amd64_xen/arch/x86/xen/mmu.c:1649!
Forcibly Merged 610812 613634 614400 615048 624307.

 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
615048: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615048
624307: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624307
613634: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613634
610812: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610812
614400: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614400
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.130391139023490.transcr...@bugs.debian.org



Re: [patch] m68k, mm: set all online nodes in N_NORMAL_MEMORY

2011-04-27 Thread Thorsten Glaser
Geert Uytterhoeven dixit:

Fixed those up, applied, and will send to Linus for 2.6.39-final.

Attached patch
• synchronises the 0009-* patch against what will be in 2.6.39
  (no changes in the patch area, only in the patch metadata)
• adds the series/5 file which seemingly was forgotten

I think you’ll still need the following patch for 2.6.39:
0008-m68k-atari-Reserve-some-ST-RAM-early-on-for-device-b.patch
We’re working on getting that functionality in 2.6.40 though.

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi HuntIndex: 
dists/sid/linux-2.6/debian/patches/bugfix/m68k/0009-m68k-mm-set-all-online-nodes-in-N_NORMAL_MEMORY.patch
===
--- 
dists/sid/linux-2.6/debian/patches/bugfix/m68k/0009-m68k-mm-set-all-online-nodes-in-N_NORMAL_MEMORY.patch
   (revision 17261)
+++ 
dists/sid/linux-2.6/debian/patches/bugfix/m68k/0009-m68k-mm-set-all-online-nodes-in-N_NORMAL_MEMORY.patch
   (working copy)
@@ -1,47 +1,25 @@
-From 678cf05cb8031c762644a393b7c943e7a9d2c288 Mon Sep 17 00:00:00 2001
+From fb5f44b4fd12bfd16019956d0d0795278a2f561b Mon Sep 17 00:00:00 2001
 From: Michael Schmitz schmitz...@googlemail.com
-Date: Sun, 24 Apr 2011 13:59:43 +1200
-Subject: [PATCH 9/9] m68k, mm: set all online nodes in N_NORMAL_MEMORY
+Date: Tue, 26 Apr 2011 14:51:53 +1200
+Subject: [PATCH] m68k/mm: Set all online nodes in N_NORMAL_MEMORY
 
-David Rientjes wrote:
- For m68k, N_NORMAL_MEMORY represents all nodes that have present memory
- since it does not support HIGHMEM.  This patch sets the bit at the time
- the node is brought online.
-
- If N_NORMAL_MEMORY is not accurate, slub may encounter errors since it
- uses this nodemask to setup per-cache kmem_cache_node data structures.
-
- Signed-off-by: David Rientjes rient...@google.com
- ---
-  arch/m68k/mm/init_mm.c |2 ++
-  1 files changed, 2 insertions(+), 0 deletions(-)
-
- diff --git a/arch/m68k/mm/init_mm.c b/arch/m68k/mm/init_mm.c
- --- a/arch/m68k/mm/init_mm.c
- +++ b/arch/m68k/mm/init_mm.c
- @@ -59,6 +59,8 @@ void __init m68k_setup_node(int node)
-  }
-  #endif
-  pg_data_map[node].bdata = bootmem_node_data + node;
- +if (node_present_pages(node))
- +node_set_state(node, N_NORMAL_MEMORY);
-  node_set_online(node);
-  }
-
-
-As Andreas pointed out, node_present_pages is set in free_area_init_node
-which only gets called at the very end of m68k mm paging_init.
+For m68k, N_NORMAL_MEMORY represents all nodes that have present memory
+since it does not support HIGHMEM.  This patch sets the bit at the time
+node_present_pages has been set by free_area_init_node.
+At the time the node is brought online, the node state would have to be
+done unconditionally since information about present memory has not yet
+been recorded.
 
-The correct patch would be something like this - the need for the
-conditional is perhaps debatable, seeing as we set the pages present
-just before node_set_state.
+If N_NORMAL_MEMORY is not accurate, slub may encounter errors since it
+uses this nodemask to setup per-cache kmem_cache_node data structures.
 
-Tested on my ARAnyM test setup so far. I'd like to wait for an
-independent kernel image built by Thorsten before I test on the actual
-hardware. Sorry but you'll have to restart your build Thorsten :-)
+This pach is an alternative to the one proposed by David Rientjes
+rient...@google.com attempting to set node state immediately when
+bringing the node online.
 
 Signed-off-by: Michael Schmitz schm...@debian.org
-Tested-by: Thorsten Glaser t...@debian.org
+Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
+CC: sta...@kernel.org
 ---
  arch/m68k/mm/motorola.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
@@ -60,5 +38,5 @@
  }
  
 -- 
-1.7.4.4
+1.7.5
 
Index: dists/sid/linux-2.6/debian/patches/series/5
===
--- dists/sid/linux-2.6/debian/patches/series/5 (revision 0)
+++ dists/sid/linux-2.6/debian/patches/series/5 (revision 0)
@@ -0,0 +1,12 @@
+# will be in 2.6.39 (pulled from linus tree)
++ bugfix/m68k/0001-m68k-Add-helper-function-handle_kernel_fault.patch
++ bugfix/m68k/0002-m68k-Use-base_trap_init-to-initialize-vectors.patch
++ bugfix/m68k/0003-m68k-Allow-all-kernel-traps-to-be-handled-via-except.patch
++ bugfix/m68k/0004-m68k-atari-Initial-ARAnyM-support.patch
++ bugfix/m68k/0005-m68k-atari-ARAnyM-Add-support-for-block-access.patch
++ bugfix/m68k/0006-m68k-atari-ARAnyM-Add-support-for-console-access.patch
++ bugfix/m68k/0007-m68k-atari-ARAnyM-Add-support-for-network-access.patch
+# accepted by m68k subsystem maintainer; probably in 2.6.40
++ bugfix/m68k/0008-m68k-atari-Reserve-some-ST-RAM-early-on-for-device-b.patch
+# will be in 2.6.39
++ 

Bug#624343: linux-image-2.6.38-2-amd64: frequent message bio too big device md0 (248 240) in kern.log

2011-04-27 Thread Jameson Graef Rollins
Package: linux-2.6
Version: 2.6.38-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

As you can see from the kern.log snippet below, I am seeing frequent
messages reporting bio too big device md0 (248  240).

I run what I imagine is a fairly unusual disk setup on my laptop,
consisting of:

  ssd - raid1 - dm-crypt - lvm - ext4

I use the raid1 as a backup.  The raid1 operates normally in degraded
mode.  For backups I then hot-add a usb hdd, let the raid1 sync, and
then fail/remove the external hdd. 

I started noticing these messages after my last sync.  I have not
rebooted since.

I found a bug report on the launchpad that describes an almost
identical situation:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/320638

The reporter seemed to be concerned that their may be data loss
happening.  I have not yet noticed any, but of course I'm terrified
that it's happening and I just haven't found it yet.  Unfortunately
the bug was closed with a Won't Fix without any resolution.

Is this a kernel bug, or is there something I can do to remedy the
situation?  I haven't tried to reboot yet to see if the messages stop.
I'm obviously most worried about data loss.  Please advise!

Thanks so much for any help.

jamie.


- -- Package-specific info:
** Version:
Linux version 2.6.38-2-amd64 (Debian 2.6.38-3) (b...@decadent.org.uk) (gcc 
version 4.4.5 (Debian 4.4.5-15) ) #1 SMP Thu Apr 7 04:28:07 UTC 2011

** Command line:
BOOT_IMAGE=/vmlinuz-2.6.38-2-amd64 root=/dev/mapper/servo-root ro vga=788

** Not tainted

** Kernel log:
[134465.496126] bio too big device md0 (248  240)
[134465.544976] bio too big device md0 (248  240)
[134465.626438] bio too big device md0 (248  240)
[134465.675884] bio too big device md0 (248  240)
[134465.752459] bio too big device md0 (248  240)
[134465.827410] bio too big device md0 (248  240)
[134466.087495] bio too big device md0 (248  240)
[134466.155538] bio too big device md0 (248  240)
[134466.225549] bio too big device md0 (248  240)
[134466.268505] bio too big device md0 (248  240)
[134466.397099] bio too big device md0 (248  240)
[134466.464110] bio too big device md0 (248  240)
[134466.501557] bio too big device md0 (248  240)
[134466.547847] bio too big device md0 (248  240)
[134466.636949] bio too big device md0 (248  240)
[134466.695790] bio too big device md0 (248  240)
[134466.748543] bio too big device md0 (248  240)
[134466.791067] bio too big device md0 (248  240)
[134466.822082] bio too big device md0 (248  240)
[134466.834387] bio too big device md0 (248  240)
[134466.884726] bio too big device md0 (248  240)
[134466.933843] bio too big device md0 (248  240)
[134466.982737] bio too big device md0 (248  240)
[134467.021168] bio too big device md0 (248  240)
[134467.093886] bio too big device md0 (248  240)
[134467.113183] bio too big device md0 (248  240)
[134467.133697] bio too big device md0 (248  240)
[134467.163391] bio too big device md0 (248  240)
[134467.238819] bio too big device md0 (248  240)
[134467.279655] bio too big device md0 (248  240)
[134467.337005] bio too big device md0 (248  240)
[134467.406347] bio too big device md0 (248  240)
[134467.462565] bio too big device md0 (248  240)
[134467.499770] bio too big device md0 (248  240)
[134467.544269] bio too big device md0 (248  240)
[134511.879575] bio too big device md0 (248  240)
[134511.903777] bio too big device md0 (248  240)
[135819.708128] bio too big device md0 (248  240)
[135833.674591] bio too big device md0 (248  240)
[135833.675175] bio too big device md0 (248  240)
[135833.679417] bio too big device md0 (248  240)
[135833.683757] bio too big device md0 (248  240)
[135833.687908] bio too big device md0 (248  240)
[135833.691984] bio too big device md0 (248  240)
[135833.696038] bio too big device md0 (248  240)
[135833.700465] bio too big device md0 (248  240)
[135833.705000] bio too big device md0 (248  240)
[135833.709328] bio too big device md0 (248  240)
[135833.713498] bio too big device md0 (248  240)
[135833.717687] bio too big device md0 (248  240)
[135833.721729] bio too big device md0 (248  240)
[135833.727046] bio too big device md0 (248  240)
[135833.732615] bio too big device md0 (248  240)
[135833.736938] bio too big device md0 (248  240)
[135835.924148] bio too big device md0 (248  240)
[135835.941912] bio too big device md0 (248  240)
[135835.942503] bio too big device md0 (248  240)
[135835.955810] bio too big device md0 (248  240)
[135836.007533] bio too big device md0 (248  240)
[135836.016057] bio too big device md0 (248  240)
[135836.020241] bio too big device md0 (248  240)
[135836.020257] bio too big device md0 (248  240)
[135836.028139] bio too big device md0 (248  240)
[135836.038644] bio too big device md0 (248  240)
[135836.039922] bio too big device md0 (248  240)
[135836.070426] bio too big device md0 (248  240)
[135836.102252] bio too big device md0 (248  240)
[135836.103499] bio too big device md0 (248  240)
[135836.104840] bio too big device 

Bug#624297: ship build-linux-kbuild.sh in the documentation of the linux-kbuild-KVERS binary package

2011-04-27 Thread Andreas Beckmann
Hi,

I also suggest to add the build-linux-kbuild.sh script to the
documentation of the linux-kbuild-KVERS binary packages, that way it
should be easy to find for the people that need a current version of the
linux-kbuild-KVERS package to build modules for the latest kernel in
experimental.


Andreas




-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4db84a78.5070...@abeckmann.de



Bug#515754: nfs-common: Mounting with sec=krb fails with access denied by server, while mounting

2011-04-27 Thread Bernd Aufrecht

Hi,

I can confirm that the issue still exists with version 1:1.2.3-2.

The workaround with allow_weak_crypto=true also fails to fix this.

If I perform a immediate downgrade to nfs-common 1:1.2.2-5 everything 
works fine again if (and only if) allow_weak_crypto=true is present in 
the config file.


--
Bernd



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4db87b6f.9000...@googlemail.com



Bug#624372: linux-source-2.6.39: Fix warnings for invalid symbol values (now boolean)

2011-04-27 Thread Sedat Dilek
Package: linux-source-2.6.39
Version: 2.6.39~rc4-1~experimental.1
Severity: normal
Tags: patch

Hi,

attached patch against debian-dir from linux-2.6/trunk (r17251) fixes
these warnings:

.config:555:warning: symbol value 'm' invalid for LEDS_CLASS
.config:917:warning: symbol value 'm' invalid for MFD_WM8994
.config:2292:warning: symbol value 'm' invalid for BT_L2CAP
.config:2293:warning: symbol value 'm' invalid for BT_SCO

- Sedat -


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

Kernel: Linux 2.6.39-rc4-686-pae
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


Fix-warnings-for-invalid-symbol-values-now-boolean.patch
Description: plain/text


Bug#624373: linux-image-2.6.38-2-amd64: Inserting fuse fails with Unknown symbol

2011-04-27 Thread Lubomír Sedlář
Package: linux-2.6
Version: 2.6.38-4
Severity: normal

When trying to mount NTFS partition, I get an error that inserting
module fuse failed due to kstrtoull being an unknown symbol and the
drive is not mounted.

$ sudo mount -t ntfs-3g /dev/sdb1 /mnt/disk
FATAL: Error inserting fuse 
(/lib/modules/2.6.38-2-amd64/kernel/fs/fuse/fuse.ko): Unknown symbol in module, 
or unknown parameter (see dmesg)
ntfs-3g-mount: fuse device is missing, try 'modprobe fuse' as root
$ 

-- Package-specific info:
** Version:
Linux version 2.6.38-2-amd64 (Debian 2.6.38-3) (b...@decadent.org.uk) (gcc 
version 4.4.5 (Debian 4.4.5-15) ) #1 SMP Thu Apr 7 04:28:07 UTC 2011

** Command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.38-2-amd64 
root=UUID=163ded38-b055-41d5-9664-d873b0a0f92e ro

** Tainted: WIO (6656)
 * Taint on warning.
 * Working around severe firmware bug.
 * Out-of-tree module has been loaded.

** Kernel log:
[258506.647370] PM: early resume of devices complete after 7.025 msecs
[258506.647507] i915 :00:02.0: setting latency timer to 64
[258506.653913] uhci_hcd :00:1a.0: setting latency timer to 64
[258506.653937] usb usb3: root hub lost power or was reset
[258506.653950] uhci_hcd :00:1a.1: setting latency timer to 64
[258506.653973] usb usb4: root hub lost power or was reset
[258506.653984] uhci_hcd :00:1a.2: setting latency timer to 64
[258506.654008] usb usb5: root hub lost power or was reset
[258506.654021] ehci_hcd :00:1a.7: setting latency timer to 64
[258506.654117] uhci_hcd :00:1d.0: setting latency timer to 64
[258506.654141] usb usb6: root hub lost power or was reset
[258506.654152] uhci_hcd :00:1d.1: setting latency timer to 64
[258506.654176] usb usb7: root hub lost power or was reset
[258506.654187] uhci_hcd :00:1d.2: setting latency timer to 64
[258506.654211] usb usb8: root hub lost power or was reset
[258506.654223] ehci_hcd :00:1d.7: setting latency timer to 64
[258506.654263] pci :00:1e.0: setting latency timer to 64
[258506.654275] ata_piix :00:1f.2: PCI INT A - GSI 21 (level, low) - IRQ 
21
[258506.654280] ata_piix :00:1f.2: setting latency timer to 64
[258506.654294] ata_piix :00:1f.5: PCI INT C - GSI 18 (level, low) - IRQ 
18
[258506.654298] ata_piix :00:1f.5: setting latency timer to 64
[258506.654324] iwlagn :02:00.0: RF_KILL bit toggled to disable radio.
[258506.656019] tg3 :85:00.0: eth0: Link is down
[258506.684793] sd 0:0:0:0: [sda] Starting disk
[258506.711001] HDA Intel :00:1b.0: power state changed by ACPI to D0
[258506.711013] HDA Intel :00:1b.0: power state changed by ACPI to D0
[258506.711025] HDA Intel :00:1b.0: power state changed by ACPI to D0
[258506.711034] HDA Intel :00:1b.0: power state changed by ACPI to D0
[258506.711047] HDA Intel :00:1b.0: PCI INT A - GSI 17 (level, low) - IRQ 
17
[258506.711060] HDA Intel :00:1b.0: setting latency timer to 64
[258506.711137] HDA Intel :00:1b.0: irq 47 for MSI/MSI-X
[258506.740256] firewire_core: skipped bus generations, destroying all nodes
[258507.044124] usb 4-1: reset full speed USB device using uhci_hcd and address 
2
[258507.160327] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[258507.168586] ata2.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered 
out
[258507.168595] ata2.00: ACPI cmd ef/03:41:00:00:00:a0 (SET FEATURES) filtered 
out
[258507.184538] ata2.00: configured for UDMA/100
[258507.240310] firewire_core: rediscovered device fw0
[258507.547491] serial 00:09: activated
[258507.550806] parport_pc 00:0a: activated
[258509.620304] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[258509.652501] ata1.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered 
out
[258509.652510] ata1.00: ACPI cmd ef/03:41:00:00:00:a0 (SET FEATURES) filtered 
out
[258509.684457] ata1.00: configured for UDMA/100
[258509.770467] PM: resume of devices complete after 3123.016 msecs
[258509.966353] PM: Finishing wakeup.
[258509.966359] Restarting tasks ... done.
[258509.988749] video LNXVIDEO:00: Restoring backlight state
[258510.260291] usb 6-2: new low speed USB device using uhci_hcd and address 5
[258510.440583] usb 6-2: New USB device found, idVendor=0461, idProduct=4d20
[258510.440588] usb 6-2: New USB device strings: Mfr=0, Product=2, 
SerialNumber=0
[258510.440592] usb 6-2: Product: USB Optical Mouse
[258510.456943] input: USB Optical Mouse as 
/devices/pci:00/:00:1d.0/usb6/6-2/6-2:1.0/input/input15
[258510.457176] generic-usb 0003:0461:4D20.0004: input,hidraw0: USB HID v1.11 
Mouse [USB Optical Mouse] on usb-:00:1d.0-2/input0
[258759.814949] iwlagn :02:00.0: RF_KILL bit toggled to enable radio.
[258759.913646] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[258760.472270] usb 3-1: new full speed USB device using uhci_hcd and address 7
[258760.640327] usb 3-1: New USB device found, idVendor=03f0, idProduct=171d
[258760.640338] usb 3-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[258760.640344] usb 3-1: Product: HP 

Bug#624373: marked as done (linux-image-2.6.38-2-amd64: Inserting fuse fails with Unknown symbol)

2011-04-27 Thread Debian Bug Tracking System
Your message dated Wed, 27 Apr 2011 23:23:33 +0200
with message-id 20110427212333.ga15...@wavehammer.waldi.eu.org
and subject line Re: Bug#624373: linux-image-2.6.38-2-amd64: Inserting fuse 
fails with Unknown symbol
has caused the Debian Bug report #624373,
regarding linux-image-2.6.38-2-amd64: Inserting fuse fails with Unknown symbol
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 ow...@bugs.debian.org
immediately.)


-- 
624373: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624373
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: linux-2.6
Version: 2.6.38-4
Severity: normal

When trying to mount NTFS partition, I get an error that inserting
module fuse failed due to kstrtoull being an unknown symbol and the
drive is not mounted.

$ sudo mount -t ntfs-3g /dev/sdb1 /mnt/disk
FATAL: Error inserting fuse 
(/lib/modules/2.6.38-2-amd64/kernel/fs/fuse/fuse.ko): Unknown symbol in module, 
or unknown parameter (see dmesg)
ntfs-3g-mount: fuse device is missing, try 'modprobe fuse' as root
$ 

-- Package-specific info:
** Version:
Linux version 2.6.38-2-amd64 (Debian 2.6.38-3) (b...@decadent.org.uk) (gcc 
version 4.4.5 (Debian 4.4.5-15) ) #1 SMP Thu Apr 7 04:28:07 UTC 2011

** Command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.38-2-amd64 
root=UUID=163ded38-b055-41d5-9664-d873b0a0f92e ro

** Tainted: WIO (6656)
 * Taint on warning.
 * Working around severe firmware bug.
 * Out-of-tree module has been loaded.

** Kernel log:
[258506.647370] PM: early resume of devices complete after 7.025 msecs
[258506.647507] i915 :00:02.0: setting latency timer to 64
[258506.653913] uhci_hcd :00:1a.0: setting latency timer to 64
[258506.653937] usb usb3: root hub lost power or was reset
[258506.653950] uhci_hcd :00:1a.1: setting latency timer to 64
[258506.653973] usb usb4: root hub lost power or was reset
[258506.653984] uhci_hcd :00:1a.2: setting latency timer to 64
[258506.654008] usb usb5: root hub lost power or was reset
[258506.654021] ehci_hcd :00:1a.7: setting latency timer to 64
[258506.654117] uhci_hcd :00:1d.0: setting latency timer to 64
[258506.654141] usb usb6: root hub lost power or was reset
[258506.654152] uhci_hcd :00:1d.1: setting latency timer to 64
[258506.654176] usb usb7: root hub lost power or was reset
[258506.654187] uhci_hcd :00:1d.2: setting latency timer to 64
[258506.654211] usb usb8: root hub lost power or was reset
[258506.654223] ehci_hcd :00:1d.7: setting latency timer to 64
[258506.654263] pci :00:1e.0: setting latency timer to 64
[258506.654275] ata_piix :00:1f.2: PCI INT A - GSI 21 (level, low) - IRQ 
21
[258506.654280] ata_piix :00:1f.2: setting latency timer to 64
[258506.654294] ata_piix :00:1f.5: PCI INT C - GSI 18 (level, low) - IRQ 
18
[258506.654298] ata_piix :00:1f.5: setting latency timer to 64
[258506.654324] iwlagn :02:00.0: RF_KILL bit toggled to disable radio.
[258506.656019] tg3 :85:00.0: eth0: Link is down
[258506.684793] sd 0:0:0:0: [sda] Starting disk
[258506.711001] HDA Intel :00:1b.0: power state changed by ACPI to D0
[258506.711013] HDA Intel :00:1b.0: power state changed by ACPI to D0
[258506.711025] HDA Intel :00:1b.0: power state changed by ACPI to D0
[258506.711034] HDA Intel :00:1b.0: power state changed by ACPI to D0
[258506.711047] HDA Intel :00:1b.0: PCI INT A - GSI 17 (level, low) - IRQ 
17
[258506.711060] HDA Intel :00:1b.0: setting latency timer to 64
[258506.711137] HDA Intel :00:1b.0: irq 47 for MSI/MSI-X
[258506.740256] firewire_core: skipped bus generations, destroying all nodes
[258507.044124] usb 4-1: reset full speed USB device using uhci_hcd and address 
2
[258507.160327] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[258507.168586] ata2.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered 
out
[258507.168595] ata2.00: ACPI cmd ef/03:41:00:00:00:a0 (SET FEATURES) filtered 
out
[258507.184538] ata2.00: configured for UDMA/100
[258507.240310] firewire_core: rediscovered device fw0
[258507.547491] serial 00:09: activated
[258507.550806] parport_pc 00:0a: activated
[258509.620304] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[258509.652501] ata1.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered 
out
[258509.652510] ata1.00: ACPI cmd ef/03:41:00:00:00:a0 (SET FEATURES) filtered 
out
[258509.684457] ata1.00: configured for UDMA/100
[258509.770467] PM: resume of devices complete after 3123.016 msecs
[258509.966353] PM: Finishing wakeup.
[258509.966359] Restarting tasks ... done.
[258509.988749] video LNXVIDEO:00: Restoring backlight state
[258510.260291] usb 

Bug#623881: linux-image-2.6.32-5-openvz-amd64: many oops after kexec reboot

2011-04-27 Thread Steven Chamberlain
On 24/04/11 01:54, Steven Chamberlain wrote:
 ... [in] 2.6.32-31 it
 still seems reproducible every time.

I've just tried going back to 2.6.32-30 (my own build, with fixes for
607041 and 613170 applied because I need them) and kexec works there.
So I think a problem was introduced during the other, many changes in
2.6.32-31.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4db892df.3090...@pyro.eu.org



Saliec rokas ap vidukli puspilkai sievietei

2011-04-27 Thread Borodulins Anatolijs
Apliec rokas uz apaļumiem trūcīgi apģērbtai sekserītei, 

iegādājies ugunīgu dzērienu pie bāra un noskaties krāšņu šovu.. 

Jauns un spožs klubs gaida tevi un tavus draugus - mēs nesortējam savus viesus, 
mums katrs ir svarīgs: vai no Latvijas, vai Mozambikas.

Pieņemams cenas, vāciešu menedžments - sīkāk noskaidro rekur: 
http://www.superklubstev.info


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110427204552.124351a53...@antipunk.com



Bug#624268: [squeeze] include important changes from 2.6.32.39

2011-04-27 Thread dann frazier
On Wed, Apr 27, 2011 at 01:35:06AM +0100, Ben Hutchings wrote:
 On Tue, Apr 26, 2011 at 06:17:08PM -0600, dann frazier wrote:
 [...]
   6f396d4a x86, cpu: Fix regression in AMD errata checking code
  
  fixes hangs on some K8 systems
 
 I believe this is a fixup for these:
 
 [...]
   d4274252 x86, AMD: Set ARAT feature on AMD processors
   7a3b25c0 x86, cpu: Clean up AMD erratum 400 workaround
   bba4804e x86, cpu: AMD errata checking framework
  
  These avoid switching to HPET timers in deep C states on AMD
  CPUs. Though obviously an improvement, I'm not really sure what makes
  these candidates for stable - unless people have been seeing hangs w/
  the broadcast timer code on AMD systems?
 
 I'm dubious about the value of these quite large changes, as you may
 have seen in discussion on stable-review.  Given that no-one was able
 to explain what bug is fixed, and there is a functional change hidden
 in the 'cleanup' patch which again no-one was able to explain, I would
 favour reverting these.

+1 - I've got them reverted in my local tree, will commit after some testing.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110428001622.gc3...@dannf.org



Bug#624343: linux-image-2.6.38-2-amd64: frequent message bio too big device md0 (248 240) in kern.log

2011-04-27 Thread Jameson Graef Rollins
I am starting to suspect that these messages are in face associated with
data loss on my system.  I have witnessed these messages occur during
write operations to the disk, and I have also started to see some
strange behavior on my system.  dhclient started acting weird after
these messages appeared (not holding on to leases) and I started to
notice database exceptions in my mail client.

Interestingly, the messages seem to have gone away after reboot.  I will
watch closely to see if they return after my next raid1 sync.

jamie.


pgprQbgSVTavb.pgp
Description: PGP signature


Re: [patch] m68k, mm: set all online nodes in N_NORMAL_MEMORY

2011-04-27 Thread Ben Hutchings
On Wed, 2011-04-27 at 15:11 +, Thorsten Glaser wrote:
 Geert Uytterhoeven dixit:
 
 Fixed those up, applied, and will send to Linus for 2.6.39-final.
 
 Attached patch
 • synchronises the 0009-* patch against what will be in 2.6.39
   (no changes in the patch area, only in the patch metadata)

OK.

 • adds the series/5 file which seemingly was forgotten
[...]

Duh, I have it here but didn't check it in.  I'm normally so diligent
about running 'svn st' to check for untracked files...

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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


Bug#515754: nfs-common: Mounting with sec=krb fails with access denied by server, while mounting

2011-04-27 Thread Friedemann Stoyan
Hello,

nfs-common 1:1.2.3-2 from wheezy works flawlessly for me with sec=krb5p and
allow_weak_crypto = true in /etc/krb5.conf.

Regards
Friedemann



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110428050413.ga19...@phoenix.lab.swapon.de