Package: linux-2.6
Version: 3.2.12-1
Severity: normal
During Bootup, the leds-gpio initalization fails with the following error
message:
leds-gpio: probe of leds-gpio failed with error -22
Only the power led stays lit. The /sys/class/leds directory is also empty.
-- Package-specific info:
Package: linux-image-2.6.32-5-xen-amd64
Version: 2.6.32-39
Severity: important
We have observed an issue when a Xen dom0 is removing a snapshot for a logical
volume and another process comes along to create a snapshot for that same
device (different names) causing the server to Kernel Ooops. Ac
I have also noticed, that if I am reading the trace correctly that in
both of my cases, and the original bug submitter's, and a bug posted on
old.nabble.com's case the crash always seems to happen when one CPU is
doing cheetah_xcall_deliver, and the other CPU is in the same
instruction in tl0_i
debian testing
kernel sid
Apr 3 21:37:54 pavka kernel: [36561.844540] [ cut here
]
Apr 3 21:37:54 pavka kernel: [36561.844552] WARNING: at
/build/buildd-linux-2.6_3.2.13-1-i386-2plIcw/linux-2.6-3.2.13/debian/build/source_i386_none/net/sched/sch_generic.c:255
dev_watch
Kieron Gillespie wrote:
> Here are the dmesg output from the current system running Linux
> 3.2.13 with SMP enabled with tickless disabled.
Great.
Is this reproducible without nouveau? It might be possible to test
by putting
blacklist nouveau
in /etc/modprobe.d/kg-disable-nouveau.con
Hi,
there is some more information regarding the issue on the linux-nfs
mailing list starting with:
http://www.spinics.net/lists/linux-nfs/msg24811.html
and ending here:
http://www.spinics.net/lists/linux-nfs/msg24914.html
A fix for squeeze would be great.
Best regards,
Andi
Here are the dmesg output from the current system running Linux 3.2.13
with SMP enabled with tickless disabled.
[0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 4.9.7 2004/05/27 07:31'
[0.00] PROMLIB: Root node compatible:
[0.00] Initializing cgroup subsys cpuset
[0.00] In
Processing commands for cont...@bugs.debian.org:
> severity 648766 important
Bug #648766 [src:linux-2.6] [sparc-unstable] kernel crash
Severity set to 'important' from 'normal'
> quit
Stopping processing here.
Please contact me if you need assistance.
--
648766: http://bugs.debian.org/cgi-bin/bu
severity 648766 important
quit
Kieron Gillespie wrote:
> I've attached some images to this bug message, not sure if they will
> appear
Received; thanks much.
What version of the kernel are you using? Full "dmesg" output from a
normal boot would be useful as well, so we can get to know your
con
Processing commands for cont...@bugs.debian.org:
> affects 658662 + xserver-xorg-video-intel
Bug #658662 [linux-2.6] drm/i915: no signal via DisplayPort on Sandy Bridge
since Linux 3.2
Added indication that 658662 affects xserver-xorg-video-intel
>
End of message, stopping processing here.
Pleas
Processing commands for cont...@bugs.debian.org:
> reopen 638157
Bug #638157 {Done: Luk Claes } [nfs-kernel-server]
nfs-kernel-server: attempt to mount -t nfs4 -o sec=krb5 hangs on squeeze, works
with nfs-utils from testing
'reopen' may be inappropriate when a bug has been closed with a version;
reopen 638157
thanks
Hi,
for me this is still an issue. Fresh installation, real hardware,
standard squeeze on client and server with nfs-common_1.2.2-4squeeze2
and nfs-kernel-server_1.2.2-4squeeze2 .
As I described above, the mount hangs:
root@workstation00:~# mount -t nfs4 -o sec=krb5i mains
Hi,
Horst Rauber wrote:
> I'm having the same problem (autofs hangs when accessing an auto mount point)
> with recent kernels, so I wonder if this is really fixed upstream or if there
> is another cause.
>
> Affected kernel: vanilla 3.2.13 and 3.3.1 (both amd64)
> Working kernel: 3.1.10 (amd64)
>
Hi!
This patch is "UBUNTU Way" Solution described in
If I understand correctly, you are saying there are two patches that
deal with deciding whether ata_piix or hv_storvsc handles a device and
making sure CD-ROMs are still usable:
http://thread.gmane.org/gmane.linux.ide/51712
http://thread.
Hi,
I'm having the same problem (autofs hangs when accessing an auto mount point)
with recent kernels, so I wonder if this is really fixed upstream or if there
is another cause.
Affected kernel: vanilla 3.2.13 and 3.3.1 (both amd64)
Working kernel: 3.1.10 (amd64)
Userspace: autofs5 5.0.4-3.2+b1
I tested a patch upstream and it solved the problem to me. I mailed it to the
bug
(but chose to use -quiet which I perhaps shouldn't have.)
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
16 matches
Mail list logo
