Bug#949369: i915: kernel crash in i915_active_acquire()

[Nils Jarle Haugen]

Dear maintainers,

I experienced the same crash today. I have the Lenovo t470p with the 
i915 (Intel HD 630 graphics) and the NVIDIA 940MX dedicated graphics 
card. I statically switch between intel and nvidia with xrandr and sddm 
scrpts (using 
https://wiki.debian.org/NvidiaGraphicsDrivers/Optimus#Configuration).


On the occasion when the system crashed, the xrandr and sddm scripts 
were commented out and not actively in use (but the nvidia kernel module 
was still loaded).


The crash left the system in a unusable state, needed to call sysrq to 
force restart it.


I'll try to purge the proprietary drivers and then try to reproduce the 
issue.



Kind regards,
Nils J. Haugen


Distributor ID: Debian
Description:    Debian GNU/Linux bullseye/sid
Release:    testing
Codename:   bullseye
5.4.0-3-amd64

Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.793555] i915 
:00:02.0: GPU HANG: ecode 9:1:0x, hang on rcs0
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.794565] i915 
:00:02.0: Resetting rcs0 for hang on rcs0
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.795587] i915 
:00:02.0: Resetting chip for hang on rcs0
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846861] [ cut 
here ]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846871] invalid opcode: 
 [#1] SMP PTI
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846875] CPU: 1 PID: 4125 
Comm: Unity Tainted: G   OE 5.4.0-3-amd64 #1 Debian 5.4.13-1
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846878] Hardware name: 
LENOVO 20J6CTO1WW/20J6CTO1WW, BIOS R0FET50W (1.30 ) 07/03/2019
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846885] RIP: 
0010:__list_del_entry_valid.cold+0x31/0x55
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846889] Code: 61 0e a3 e8 
d4 1d ce ff 0f 0b 48 c7 c7 50 62 0e a3 e8 c6 1d ce ff 0f 0b 48 89 f2 48 
89 fe 48 c7 c7 10 62 0e a3 e8 b2 1d ce ff <0f> 0b 48 89 fe 4c 89 c2 48 
c7 c7 d8 61 0e a3 e8 9e 1d ce ff 0f 0b
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846892] RSP: 
0018:ba9dc91978a0 EFLAGS: 00010046
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846895] RAX: 
0054 RBX: a0769e0d4fc0 RCX: 
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846897] RDX: 
 RSI: a0783e257688 RDI: a0783e257688
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846899] RBP: 
a0783b9b6068 R08: a0783e257688 R09: 0063
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846901] R10: 
ba9dc9197750 R11:  R12: a0783b9b6000
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846903] R13: 
a0783b9b6000 R14: a0783267c180 R15: a078300f7ae8
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846906] FS: 
7f571b4992c0() GS:a0783e24() knlGS:
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846908] CS:  0010 DS: 
 ES:  CR0: 80050033
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846910] CR2: 
7f5717f28000 CR3: 000432e5e004 CR4: 003606e0
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846913] DR0: 
 DR1:  DR2: 
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846915] DR3: 
 DR6: fffe0ff0 DR7: 0400

Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846916] Call Trace:
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846989] 
i915_request_retire+0xc9/0x380 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847042] 
retire_requests+0x4e/0x60 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847088] 
i915_retire_requests+0xa9/0x230 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847133] 
i915_gem_evict_for_node+0x264/0x2b0 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847176] 
i915_gem_gtt_reserve+0x45/0x70 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847222] 
__i915_vma_do_pin+0x1d7/0x490 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847265] 
eb_lookup_vmas+0xa90/0xb90 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847305]  ? 
intel_gt_terminally_wedged+0x23/0xf0 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847344] 
i915_gem_do_execbuffer+0x67c/0x1520 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847352]  ? 
shmem_alloc_page+0x47/0x90
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847356]  ? 
xas_store+0x56/0x5e0
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847362]  ? 
mem_cgroup_charge_statistics+0x4c/0xd0
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847365]  ? 
mem_cgroup_commit_charge+0x5f/0x4e0
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847370]  ? 
__kmalloc_node+0x1f5/0x300
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847407] 
i915_gem_execbuffer2_ioctl+0x1df/0x3d0 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847445]  ? 
i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847466] 
drm_ioctl_kernel+0xaa/0xf0 [drm]
Feb 18 15:29:29 nilsjarle

Bug#948257: Testet Patch mentioned by Salvatore Bonaccorso

[nils]

The small patch at 
https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/23 
(https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/23) works 
fine.

Before:
100s of depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not 
open builtin file 
'/var/tmp/mkinitramfs_DkdaZa/lib/modules/5.4.0-2-amd64/modules.builtin.bin

With patch:
No Errors.

Bug#927386: /lib/modules/4.9.0-7-686/kernel/drivers/gpu/drm/radeon/radeon.ko: “modprobe radeon 'modeset=1'” on Thinkpad R60: black screen, kernel NULL pointer dereference

[Nils Dagsson Moskopp]

Package: src:linux
Version: 4.9.110-3+deb9u2
Severity: important
File: /lib/modules/4.9.0-7-686/kernel/drivers/gpu/drm/radeon/radeon.ko

Dear Maintainer,

I boot Linux with Kernel Modesetting disabled. This is the only way to
prevent a completely black screen. Unfortunately, it limits me to VESA
graphics, i.e. no 3D at all – since User Modesetting is not available.

A “modprobe radeon 'modeset=0'” only generates this kernel message:
[drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module!

Whenever I attempt to load the radeon module with modeseting enabled,
the screen immediately goes black. I expected it to actually load the
driver, change the resolution using Kernel Modesetting and give me 3D
rendering acceleration, via the radeon module. The kernel outputs the
lines after this paragraph, which mention the dereferencing of a NULL
pointer; I believe this is a program error in the radeon driver code.

[ 4374.923486] [drm] radeon kernel modesetting enabled.
[ 4374.923646] checking generic (d800 5b) vs hw (d800 800)
[ 4374.923649] fb: switching to radeondrmfb from VESA VGA
[ 4374.923775] Console: switching to colour dummy device 80x25
[ 4374.924928] [drm] initializing kernel modesetting (RV515 0x1002:0x7145 
0x17AA:0x2006 0x00).
[ 4374.924964] [drm] register mmio base: 0xEE00
[ 4374.924967] [drm] register mmio size: 65536
[ 4374.925149] ATOM BIOS: M54CSP/M52CSP
[ 4374.925173] [drm] Generation 2 PCI interface, using max accessible memory
[ 4374.925183] radeon :01:00.0: VRAM: 128M 0x - 
0x07FF (128M used)
[ 4374.925190] radeon :01:00.0: GTT: 512M 0x0800 - 
0x27FF
[ 4374.927419] [drm] Detected VRAM RAM=128M, BAR=128M
[ 4374.927423] [drm] RAM width 128bits DDR
[ 4374.936146] [TTM] Zone  kernel: Available graphics memory: 440242 kiB
[ 4374.936150] [TTM] Zone highmem: Available graphics memory: 1033590 kiB
[ 4374.936152] [TTM] Initializing pool allocator
[ 4374.936214] [drm] radeon: 128M of VRAM memory ready
[ 4374.936217] [drm] radeon: 512M of GTT memory ready.
[ 4374.936251] [drm] GART: num cpu pages 131072, num gpu pages 131072
[ 4374.937907] [drm] radeon: power management initialized
[ 4374.940380] [drm] radeon: 1 quad pipes, 1 z pipes initialized.
[ 4374.947928] [drm] PCIE GART of 512M enabled (table at 0x0004).
[ 4374.947982] radeon :01:00.0: WB enabled
[ 4374.947991] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x0800 and cpu addr 0xf2ea1000
[ 4374.947995] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 4374.947997] [drm] Driver supports precise vblank timestamp query.
[ 4374.948001] radeon :01:00.0: radeon: MSI limited to 32-bit
[ 4374.948064] [drm] radeon: irq initialized.
[ 4374.948100] [drm] Loading R500 Microcode
[ 4374.951990] radeon :01:00.0: firmware: direct-loading firmware 
radeon/R520_cp.bin
[ 4374.953018] [drm] radeon: ring at 0x08001000
[ 4374.953060] [drm] ring test succeeded in 9 usecs
[ 4374.953433] [drm] ib test succeeded in 0 usecs
[ 4374.954709] [drm] Radeon Display Connectors
[ 4374.954712] [drm] Connector 0:
[ 4374.954713] [drm]   VGA-1
[ 4374.954718] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 
0x7e4c
[ 4374.954720] [drm]   Encoders:
[ 4374.954722] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 4374.954724] [drm] Connector 1:
[ 4374.954726] [drm]   LVDS-1
[ 4374.954731] [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 
0x7e6c
[ 4374.954732] [drm]   Encoders:
[ 4374.954734] [drm] LCD1: INTERNAL_LVTM1
[ 4374.954736] [drm] Connector 2:
[ 4374.954738] [drm]   SVIDEO-1
[ 4374.954739] [drm]   Encoders:
[ 4374.954741] [drm] TV1: INTERNAL_KLDSCP_DAC2
[ 4374.954743] [drm] Connector 3:
[ 4374.954745] [drm]   DVI-I-1
[ 4374.954747] [drm]   HPD1
[ 4374.954751] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 
0x7e5c
[ 4374.954753] [drm]   Encoders:
[ 4374.954755] [drm] DFP1: INTERNAL_KLDSCP_TMDS1
[ 4375.348177] [drm] fb mappable at 0xD80C
[ 4375.348181] [drm] vram apper at 0xD800
[ 4375.348183] [drm] size 5914624
[ 4375.348185] [drm] fb depth is 24
[ 4375.348187] [drm]pitch is 5632
[ 4375.348428] fbcon: radeondrmfb (fb0) is primary device
[ 4375.348793] Console: switching to colour frame buffer device 175x65
[ 4375.348807] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[ 4375.364112] [drm] Initialized radeon 2.49.0 20080528 for :01:00.0 on 
minor 0
[ 4375.364854] PCI registers are not implemented.
[ 4375.364890] BUG: unable to handle kernel NULL pointer dereference at 0124
[ 4375.365041] IP: [] atom_get_src_int+0x626/0x6f0 [radeon]
[ 4375.365209] *pde =  

[ 4375.365270] Oops:  [#1] SMP
[ 4375.365324] Modules linked in: radeon btrfs xor raid6_pq ufs qnx4 hfsplus 
hfs minix ntfs vfat msdos fat jfs xfs libcrc32c ctr ccm snd_hrtimer snd_seq 
snd_seq_device fuse binfmt_misc iTCO_wdt iTCO_vendor_support arc4 pcmcia 
coretemp ttm iwl3945 drm_kms_helper 

Bug#856843: Arch bug, upstream bug, patch

[Nils]

https://bugs.archlinux.org/task/53639
https://bugzilla.kernel.org/show_bug.cgi?id=194531
Patch links in the kernel and arch bug reports.

Bug#856843: FYI, Ubuntu Bugtracker link

[Nils]

Already exists on the Ubuntu tracker, with additional info.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1686099

Bug#856843: Problem also exists on Ubuntu 16.04 with 4.4.0 kernel

[Nils]

I also see it on Ubuntu 16.04 on another system:
Linux blackbox 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC
2017 x86_64 x86_64 x86_64 GNU/Linux
ii  linux-image-4.4.0-75-generic   
4.4.0-75.96amd64Linux kernel
image for version 4.4.0 on 64 bit x86 SMP

I'll try with 4.8.0 on Ubuntu as well, but am expecting the same
behavior. For me this is with a FreeNAS server.

Should I file this bug with Ubuntu as well? Does it make sense to file
it upstream with the kernel directly?

Bug#856843: smbclient: connection flood to port 445 on mounting cifs volume under kernel 4.9.0

[Nils]

Problem persists with linux-image-4.9.0-0.bpo.2-amd64 (4.9.13-1~bpo8+1)

Bug#856843: [Pkg-samba-maint] Bug#856843: smbclient: connection flood to port 445 on mounting cifs volume under kernel 4.9.0

[Nils]

On 2017-03-09 13:46, Mathieu Parent wrote:
> Control: affects -1 + cifs-utils
>
> 2017-03-05 12:30 GMT+01:00 nils <internation...@gmx.net>:
>
>> Hello,
>> after upgrading my kernel from 4.0.8 to 4.0.9 I am getting connection floods 
>> to
>> my FreeNAS samba server from my debian machine. I never had this issue with
>> 4.0.8
> 4.0.8? Don't you mean 4.8?
>
> Can you point to the exact good/bad versions, from
> http://snapshot.debian.org/package/linux/?
>
> Also, what are your mount options (from fstab?)
>
> Regards
>
Yes, sorry, typos... 4.8 vs. 4.9.
Versions are:
ii  linux-image-4.8.0-0.bpo.2-amd64  4.8.15-2~bpo8+2
ii  linux-image-4.9.0-0.bpo.1-amd64  4.9.2-2~bpo8+1

Mount options:
//192.168.2.88/xfer /mnt/nas/xfercifs 
noauto,uid=1000,gid=1000,iocharset=utf8,sec=ntlm,credentials=/root/.cifs-nils 
0  0

Freenas Box (for Info) has:
FreeBSD freenas.dynils.de 10.3-STABLE FreeBSD 10.3-STABLE #0
r295946+1805185(9.10.2-STABLE): Wed Jan 11 17:12:42 UTC 2017
root@gauntlet:/freenas-9.10-releng/_BE/objs/freenas-9.10-releng/_BE/os/sys/FreeNAS.amd64
 
amd64
samba-nsupdate-9.8.6_1 nsupdate utility with GSS-TSIG support
samba44-4.4.5_102277   Free SMB/CIFS and AD/DC server and client
for Uni

Thanks, Nils.

Bug#856843: [Pkg-samba-maint] Bug#856843: smbclient: connection flood to port 445 on mounting cifs volume under kernel 4.9.0

[Nils]

Then this is a kernel issue, I assumed that cifsd was part of smbclient
and I see that taking up resources, but maybe that is unrelated (it was
in a normal resource usage range).

Please reassign as you think appropriate.


On 2017-03-05 14:36, Jelmer Vernooij wrote:
> On Sun, Mar 05, 2017 at 12:30:33PM +0100, nils wrote:
>> Package: smbclient
>> Version: 2:4.2.14+dfsg-0+deb8u2
>> Severity: important
>>
>> Hello,
>> after upgrading my kernel from 4.0.8 to 4.0.9 I am getting connection floods 
>> to
>> my FreeNAS samba server from my debian machine. I never had this issue with
>> 4.0.8
>>
>> Linux dnet64 4.9.0-0.bpo.1-amd64 #1 SMP Debian 4.9.2-2~bpo8+1 (2017-01-26)
>> x86_64 GNU/Linux
>> ii  smbclient  2:4.2.14+dfsg-0+deb8u2   amd64command-line
>> SMB/CIFS clients for Unix
>>
>> After mouting the cifs share(s) everything is OK for about 10 minutes, then a
>> flood of connections happens. Here is an extract of 'netstat -an' run every
>> second. Only one or two connections are shown for every 'netstat -an' run. 
>> The
>> connections are opening and closing at an incredible speed (nethogs goes to
>> 100% and doesn't show anything because it's overwhelmed). gkrellm reports 
>> about
>> 70k/Sec traffic due to this. See how the source port numbers increase
>> increadibly quickly to get an idea of how many connections are really
>> happening...
>> 
>> tcp0  1 10.0.2.15:55044 192.168.2.88:445SYN_SENT
>> tcp0  1 10.0.2.15:55252 192.168.2.88:445SYN_SENT
>> tcp0  0 10.0.2.15:55288 192.168.2.88:445
>> ESTABLISHED
>> tcp0  1 10.0.2.15:55314 192.168.2.88:445SYN_SENT
>> tcp0  1 10.0.2.15:55348 192.168.2.88:445SYN_SENT
>> tcp0  0 10.0.2.15:55396 192.168.2.88:445
>> ESTABLISHED
>> tcp0  1 10.0.2.15:55454 192.168.2.88:445SYN_SENT
>> tcp0  0 10.0.2.15:55500 192.168.2.88:445
>> ESTABLISHED
>> tcp0  0 10.0.2.15:55544 192.168.2.88:445
>> ESTABLISHED
>> tcp0 42 10.0.2.15:55586 192.168.2.88:445
>> ESTABLISHED
>> tcp0  0 10.0.2.15:55630 192.168.2.88:445
>> ESTABLISHED
>> tcp0  0 10.0.2.15:55676 192.168.2.88:445
>> ESTABLISHED
>> tcp0  0 10.0.2.15:55720 192.168.2.88:445
>> ESTABLISHED
>> tcp0  1 10.0.2.15:55770 192.168.2.88:445SYN_SENT
>> tcp1  0 10.0.2.15:55820 192.168.2.88:445
>> CLOSE_WAIT
>> tcp0  1 10.0.2.15:55868 192.168.2.88:445SYN_SENT
>> tcp0  0 10.0.2.15:55912 192.168.2.88:445
>> ESTABLISHED
>> tcp0  0 10.0.2.15:55962 192.168.2.88:445
>> ESTABLISHED
>> tcp1  0 10.0.2.15:56010 192.168.2.88:445
>> CLOSE_WAIT
>> tcp0  1 10.0.2.15:56058 192.168.2.88:445SYN_SENT
>> tcp0  0 10.0.2.15:56056 192.168.2.88:445LAST_ACK
>> tcp0  0 10.0.2.15:56104 192.168.2.88:445
>> ESTABLISHED
>> tcp0  0 10.0.2.15:56162 192.168.2.88:445
>> ESTABLISHED
>> tcp0  0 10.0.2.15:56202 192.168.2.88:445
>> ESTABLISHED
>> tcp0  1 10.0.2.15:56246 192.168.2.88:445SYN_SENT
>> tcp0  0 10.0.2.15:56290 192.168.2.88:445
>> ESTABLISHED
>> etc.
>>
>> Rebooting in 4.0.8 makes the issue go away, and I can have the shares mounted
>> as long as I want without a connection flood. Hence I assume that it's a
>> smbclient + Kernel 4.0.9 issue
> smbclient is a command-line tool, if you're just mounting CIFS shares then 
> this
> is an issue in the kernel rather than in smbclient.
>
> Jelmer

Bug#805971: linux-image-3.16.0-4-amd64: [PATCH] Xen domU "unable to handle kernel NULL pointer dereference"

[Nils Meyer]

Hi,

On Tue, 24 Nov 2015 13:34:25 + Ian Campbell  wrote:
> This needs to be fixed in mainline (or at least in net(-next).git and well
> on its way to mainline) before we can consider it for inclusion in the
> Debian kernel.
> 
> I don't see any patches from Viktor in any of those trees, nor anything
> which looks like a similar fix from someone else.

A potential workaround could be this patch which is already in mainline
4.3:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32a844056fd43dda647e1c3c6b9983bdfa04d17d

This allows the user to limit the number of queues with a module/kernel
parameter.

Bug#748805: System fails to boot after upgrading to linux-image-3.14-0.bpo.1-amd64 from wheezy-backports

[Nils Steinger]

On Sun, May 25, 2014 at 01:33:38AM +0100, Ben Hutchings wrote:
 There should be a message in the kernel log telling you exactly what was
 not found in btrfs.  You could run: 'dmesg | grep btrfs'.

dmesg's output doesn't contain 'btrfs', 'format', 'mount', or even 'module'.

Nils


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140525114020.ga6...@voidptr.de

Bug#748805: Possible cause found

[Nils Steinger]

On Sun, May 25, 2014 at 04:39:49AM +0200, Tristan Seligmann wrote:
 I added libcrc32c to /etc/initramfs-tools/modules and reran
 update-initramfs; this seems to have solved the problem.

Worked for me, too.

This also explains why the other system (the one previously running on
an XFS rootfs) worked without the workaround: xfs.ko requires libcrc32c,
so the module was included in the initramfs by default, even after the
xfs module was no longer needed.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140525120602.ga8...@voidptr.de

Bug#748805: Possible cause found

[Nils Steinger]

On Sun, May 25, 2014 at 08:45:31AM -0700, Lou Poppler wrote:
 On 5/24/14, Tristan Seligmann mithra...@mithrandi.net wrote:
 I tried this, and it does not solve the problem for me.
 My /root filesystem is an ext4 partition on a physical hard disk, /dev/sda3
 not a btrfs

You seem to be experiencing a different bug (your system hangs before it
even gets far enough to load any modules), so you might want to file a
separate bug report.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140525160134.ga22...@voidptr.de

Bug#748805: System fails to boot after upgrading to linux-image-3.14-0.bpo.1-amd64 from wheezy-backports

[Nils Steinger]

On Sat, May 24, 2014 at 05:59:18PM +0200, Bastian Blank wrote:
 On Tue, May 20, 2014 at 11:31:06PM +0200, debian-b...@voidptr.de wrote:
 Please get a name.
Sorry, I forgot to configure that properly.

  On-screen output during a failed boot attempt:
  --8--
  Decompressing Linux... Parsing ELF... done.
  Booting the kernel.
  Loading, please wait...00:03.0 C900 PCI2.10 PnP PHH+3FFC9E10+3FFB9E10 C900
  modprobe: can’t load module btrfs (kernel/fs/btrfs/btrfs.ko): unknown 
  symbol in
  module, or unknown parameter
 
 So you broke the module somehow.
I doubt _I_ broke anything, since I installed the pre-compiled package
from the official repository and rebooted without modifying anything
else.

 Please use dmesg
dmesg's output is several hundred lines long, which isn't exactly easy
to read when busybox's 'more' seems to be an alias for 'cat'…
I couldn't find any errors in the last screenful of output, the kernel
has since panicked and the KVM's web-based control interface has locked
up, so I can't examine the error any further at the moment. I will get
back to you once that's fixed.

I also migrated another KVM system from an XFS root filesystem to btrfs
and installed linux-image-3.14-0.bpo.1-amd64 — and it still boots.
The only difference to the two non-booting systems seems to be that the
working system has a separate (ext3-formatted) /boot partition.

Nils


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140525000120.ga4...@voidptr.de

Bug#677164: [3.2.17-1 - 3.2.18-1 regression] Wacom tablet in Thinkpad x220t not working

[Nils Kanning]

On Thu, 2012-06-14 at 17:10 -0500, Jonathan Nieder wrote:
  patches 0020-0024: tablet works
  patches 0020-0024,0026: does not work
 
  Thanks!  How about 0026 alone?
 
 I'm still curious about this.

Ok, I will try to do this tomorrow. However, note that at least in
combination with 0020-0024 (which seem to be ok in this respect) patch
0026 causes problems.

 So for now, it seems that dropping 0025 and 0026 in wheezy is our
 safest bet.  Then 0026 can go through stable if appropriate.

Actually I also experienced some kind of strange behavior with
0020-0024, which I did not mention so far. Sometimes the system did
not boot. (With version 3.2.18 of linux-image-3.2.0-2-amd64 this also
happened especially after resuming from hibernate.) Maybe I can
reproduce this and get some log files.

The combination 0020-0023 seems to work fine for me, though.

Nils


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

Bug#671801: Wacom tablet in Thinkpad X220 Tablet not working with linux-image-3.2.0-2-amd64_3.2.18-1_amd64

[Nils Kanning]

Hello,
the wacom tablet in my Thinkpad x220t stopped working after the update
to linux-image-3.2.0-2-amd64_3.2.18-1_amd64. (The same also occurs with
the 3.4 kernel in sid.)

I am posting this as a comment to this bug because the changelog
indicates that this was the only wacom-related change from version 17 to
18.

lsusb knowns my tablet as
Bus 002 Device 004: ID 056a:00e6 Wacom Co., Ltd

With version 18 and above lsusb -t gives
Port 5: Dev 4, If 0, Class=HID, Driver=, 12M
instead of the expected
Port 5: Dev 4, If 0, Class=HID, Driver=wacom, 12M
and consequently the device does not work.

During booting I see the following in /dev/log/syslog:
input: Wacom ISDv4 E6 Pen
as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/input/input7
However, afterwords the corresponding input directory and especially the
file input/input7 is not there.

Reloading the wacom module does not change the situation and only
produces the following in /dev/log/syslog:
usbcore: deregistering interface driver wacom
usbcore: registered new interface driver wacom
wacom: v1.53:USB Wacom tablet driver

After going back to version 17 of linux-image everything works again.

Best regards
Nils


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

Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4

[Nils S. Normann]

Chances are you all have your nfsidmap Domain mismatched between
client and server


That was it! I would never have discovered that without help.
I guess this is part of the charm of running Sid :)
Thank you!

Nils



--
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/op.v3td25fpq8pxtt@tramp.hjemmenettverk

Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4

[Nils S. Normann]

Package: nfs-common
Version: 1:1.2.5-2
Severity: important

After upgrade to nfs-common 1:1.2.5-2 I noticed that uid/gid's are displayed as
'nobody' and 'nogroup' respectively. This is the case checking with both
Nautilus and terminal.

Downgrading to 1:1.2.4-1 from Testing fixes the problem.

I am using Squeeze with nfs-kernel-server version 1:1.2.2-4 on the server side.



-- Package-specific info:
-- rpcinfo --
   program vers proto   port
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
1000241   udp  45260  status
1000241   tcp  50813  status
-- /etc/default/nfs-common --
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=yes
NEED_GSSD=
-- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
-- /etc/fstab --

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nfs-common depends on:
ii  adduser 3.113
ii  initscripts 2.88dsf-13.11
ii  libc6   2.13-21  
ii  libcap2 1:2.22-1 
ii  libcomerr2  1.42~WIP-2011-10-05-2
ii  libdevmapper1.02.1  2:1.02.65-1  
ii  libevent-1.4-2  1.4.14b-stable-1 
ii  libgssapi-krb5-21.9.1+dfsg-3 
ii  libgssglue1 0.3-3.1  
ii  libk5crypto31.9.1+dfsg-3 
ii  libkeyutils11.5.2-2  
ii  libkrb5-3   1.9.1+dfsg-3 
ii  libnfsidmap20.24-1   
ii  libtirpc1   0.2.2-5  
ii  libwrap07.6.q-21 
ii  lsb-base3.2-28   
ii  rpcbind 0.2.0-6  
ii  ucf 3.0025+nmu2  

Versions of packages nfs-common recommends:
ii  python  2.7.2-9

nfs-common 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/20111011010903.2848.8166.reportbug@Tramp.hjemmenettverk

Bug#480900: linux-image-2.6.18-6-xen-amd64: It's not possible to load the processor module because pm_idle isn't exported.

[Nils Gundelach]

Package: linux-image-2.6.18-6-xen-amd64
Version: 2.6.18.dfsg.1-18etch3
Severity: normal


May 11 18:11:47 xenserver kernel: processor: Unknown symbol pm_idle
May 11 18:11:47 xenserver kernel: thermal: Unknown symbol 
acpi_processor_set_thermal_limit


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-xen-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages linux-image-2.6.18-6-xen-amd64 depends on:
ii  e2f 1.39+1.40-WIP-2006.11.14+dfsg-2etch1 ext2 file system utilities and lib
ii  ini 0.85htools for generating an initramfs
ii  lin 2.6.18.dfsg.1-18etch3Linux 2.6.18 modules on AMD64

linux-image-2.6.18-6-xen-amd64 recommends no packages.

-- no debconf information



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

Bug#284221: Go where no man has ventured

[Nils Stepensky]

Load her up and fill her up with all 9 massive inches of you.

http://www.Belevibane.com/
Get paid starring in our porno film



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

Bug#391867: still broken and workarounds

[Nils Ivanson]

Hello, I noticed this bug when I bought my new laptop and used 2.6.18.
Today I am running Debian Sid and running GNOME

[EMAIL PROTECTED]:~$ uname -a
Linux pet 2.6.21-1-686 #1 SMP Sat May 26 16:14:59 UTC 2007 i686
GNU/Linux

and this bug is still here. On random intervals the hd-access freezes
for about 30 seconds. Sometimes it freezes 10 seconds after the
un-freeze. This makes my system very hard to use.

However... I know two workarounds for this bug, the first is to keep a
disk in the cd/dvd-drive. While a disk is present there, I get no
freezes. The second one is to specify acpi=off at boot. That also
removes all freezes.

This bug also seems to appear in Ubuntu Feisty according to launchpad.
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/104581


-- 
Nils Ivanson ([EMAIL PROTECTED])


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

Bug#300083: kernel-image-2.6.8-powerpc: problemes with the clock on a mac mini

[Nils Bruenggel]

Package: kernel-image-2.6.8-powerpc
Version: 2.6.8-11
Severity: important


I have noticed that the clock in the evening differs about 15 min
from the actual time. My mac mini runs 24/7 with ntpdate running daily
to sync the clock.

I also noticed that hwclock does not work at all for example:

[ linapple ~ # ntpdate time.ethz.ch
17 Mar 16:11:00 ntpdate[21647]: step time server 129.132.97.15 offset
-25169.568464 sec
[ linapple ~ # date
Thu Mar 17 16:11:02 CET 2005
[ linapple ~ # hwclock --show
time in rtc is Thu Mar 17 23:10:37 2005
[ linapple ~ # date
Thu Mar 17 23:10:41 CET 2005


[ linapple ~ # hwclock --show sets the clock to the hwclcok, just
hwclcok does the same. I also cannot set the hwclock (--systohc).

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.8-powerpc
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages kernel-image-2.6.8-powerpc depends on:
ii  initrd-tools  0.1.77 tools to create initrd image for p
ii  mkvmlinuz 13 create a kernel to boot a PowerPC 
ii  module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo

-- no debconf information


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