Bug#900442: linux-image-4.16.0-2-amd64: LVM2 COW snapshots fail as of 4.16
Package: src:linux Version: 4.16.12-1 Severity: normal [Copying Debian LVM team, but tentatively assigning this bug to the kernel.] I've found that as of Linux 4.16, making traditional COW LVM2 snapshots fails. (AFAICT, I can't substitute thin snapshots because my origin volumes aren't thin and need to remain mounted read-write.) I've worked around this problem for now by sticking with 4.15, but that's obviously not a good long-term solution. Specifically, the relevant "lvm create" command initially fails with errors of the form Using default stripesize 64.00 KiB. device-mapper: reload ioctl on (253:N+1) failed: Input/output error Failed to lock logical volume MyGroup/MyVolume. Aborting. Manual intervention required. with the kernel meanwhile logging messages of the form generic_make_request: Trying to write to read-only block-device dm-N (partno 0) device-mapper: persistent snapshot: write_header failed device-mapper: table: 253:N+1: snapshot: Failed to read snapshot metadata device-mapper: ioctl: error adding target to table Subsequent attempts fail with errors of the form Using default stripesize 64.00 KiB. Setting chunksize to 4.00 KiB. Archiving volume group "MyGroup" metadata (seqno 9540). Creating logical volume MyVolume.snap Creating volume group backup "/etc/lvm/backup/MyGroup" (seqno 9541). activation/volume_list configuration setting not defined: Checking only host tags for MyGroup/MyVolume.snap. Creating MyGroup-MyVolume.snap Loading MyGroup-MyVolume.snap table (253:M) Resuming MyGroup-MyVolume.snap (253:M) Initializing 4.00 KiB of logical volume "MyGroup/MyVolume.snap" with value 0. Removing MyGroup-MyVolume.snap (253:M) Creating logical volume snapshot0 Creating MyGroup-MyVolume.snap-cow device-mapper: create ioctl on MyGroup-MyVolume.snap-cow LVM-GfNest[...]-cow failed: Device or resource busy Failed to lock logical volume MyGroup/MyVolume. Aborting. Manual intervention required. Could you please take a look? Thanks! -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Gateway product_name: DX4860 product_version: chassis_vendor: Gateway chassis_version: bios_vendor: American Megatrends Inc. bios_version: P02-A1 board_vendor: Gateway board_name: IPISB-VR board_version: 1.01 ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0100] (rev 09) Subsystem: Acer Incorporated [ALI] 2nd Generation Core Processor Family DRAM Controller [1025:0589] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snb_uncore 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] 2nd Generation Core Processor Family Integrated Graphics Controller [1025:0589] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04) Subsystem: Acer Incorporated [ALI] 6 Series/C200 Series Chipset Family MEI Controller [1025:0589] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me Kernel modules: mei_me 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 05) (prog-if 20 [EHCI]) Subsystem: Acer Incorporated [ALI] 6 Series/C200 Series Chipset Family USB Enhanced Host Controller [1025:0589] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 05) Subsystem: Acer Incorporated [ALI] 6 Series/C200 Series Chipset Family High Definition Audio Controller [1025:0589] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel
Bug#885245: linux: FTBFS on powerpcspe: sstep.c: ptesync unrecognized
Ben Hutchings <b...@decadent.org.uk> writes: > I would welcome a powerpcspe porter to join the kernel team, but until > that happens you should not expect any fixes from our side. (If you Fair enough. FTR, I'm not a porter for this (or any other) architecture myself, just a regular DD who helps ensure that build errors for packages that have recently emerged from NEW don't accidentally escape notice. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#885245: linux: FTBFS on powerpcspe: sstep.c: ptesync unrecognized
Source: linux
Version: 4.14.7-1
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-powe...@lists.debian.org
Usertags: powerpcspe
Builds of linux for powerpcspe (admittedly not a release architecture)
have been failing lately:
{standard input}: Assembler messages:
{standard input}:5854: Error: unrecognized opcode: `ptesync'
/<>/scripts/Makefile.build:319: recipe for target
'arch/powerpc/lib/sstep.o' failed
make[6]: *** [arch/powerpc/lib/sstep.o] Error 1
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#869511: linux: binNMU-unsafe dependency on linux-headers-*-common
Source: linux
Version: 4.11.11-1
Severity: grave
Justification: renders package unusable (uninstallable)
The recent binNMU of linux for Perl 5.26 broke the build-specific
headers packages, which are architecture-dependent but depend on an
identical *binary* version of the architecture-independent
linux-headers-*-common package. Specifically, I observe that
linux-headers-4.11.0-2-amd64 4.11.11-1+b1 depends on
linux-headers-4.11.0-2-common (= 4.11.11-1+b1), which does not exist.
Could you please fix these relationships to use ${source:Version}?
(As you may recall, the legacy ${Source-Version} variable is an alias
for *${binary:Version}*.)
Thanks!
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32
Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug#733770: linux-libc-dev: linux/btrfs.h: 'NULL' undeclared
Package: linux-libc-dev Version: 3.11.10-1 Severity: important Control: affects -1 src:trinity Attempting to #include linux/btrfs.h without first ensuring a definition of NULL (for instancy, by including stddef.h) fails: /usr/include/linux/btrfs.h: In function 'btrfs_err_str': /usr/include/linux/btrfs.h:511:11: error: 'NULL' undeclared (first use in this function) return NULL; ^ /usr/include/linux/btrfs.h:511:11: note: each undeclared identifier is reported only once for each function it appears in As a result, trinity FTBFS: https://buildd.debian.org/status/fetch.php?pkg=trinityarch=amd64ver=1.2-1stamp=1388344679 Could you please take a look? Thanks! -- 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/20131231184529.13071.69597.report...@ghostwheel.internal.ucko.debian.net
Bug#717195: linux-kbuild-3.10: modpost wrapper crashes due to bad getline call
Package: linux-kbuild-3.10 Version: 3.10-1 Severity: important debian/build/scripts/mod/modpost passes getline pointers to uninitialized name and name_len variables, leading to crashes under some circumstances. According to getline's manpage, initializing name to NULL should let the call reliably succeed, albeit with a memory leak (which you can probably ignore in this case). Could you please look into it? Thanks! -- 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/20130717195450.30689.50316.report...@ghostwheel.internal.ucko.debian.net
Bug#717195: linux-kbuild-3.10: modpost wrapper crashes due to bad getline call
Ben Hutchings b...@decadent.org.uk writes: Surprisingly, an amd64 build worked, so I didn't notice this. No problem; I quite understand, as my own debugging inconveniently encountered crashes *only* under module-assistant. :-/ I wound up contriving to use a wrapper script that arranged to run the modpost binary under Valgrind to help track the problem down. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu -- 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/udlsizc1w41@dr-wily.mit.edu
Bug#568165: linux-kbuild-2.6.32: please ship recordmcount.pl
Jonathan Nieder jrnie...@gmail.com writes: Thanks, and sorry for the long silence. No problem; truth be told, the bug hasn't affected me in a while (due to changes in either the kernel's configuration or OpenAFS's build system, I don't remember which). That said, I can confirm that your patch does indeed add recordmcount.pl to linux-kbuild-3.5, thanks. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu -- 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/udlvceunshe@dr-wily.mit.edu
Bug#627575: linux-image-2.6.39-1-amd64: hangs loading eeprom after reporting GMBUS timed out [i915]
Ben Hutchings b...@decadent.org.uk writes: It's pending for our version 2.6.39-3 and I've also submitted it to sta...@kernel.org. Great; thank you very much for identifying and incorporating it! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu -- 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/udloc1q1rtt@dr-wily.mit.edu
Bug#627575: linux-image-2.6.39-1-amd64: hangs loading eeprom after reporting GMBUS timed out [i915]
# Bcc:ing control@ once more tags 627575 fixed-upstream thanks https://bugs.freedesktop.org/show_bug.cgi?id=37514#c3 claims that a fix has landed upstream, though I haven't had a chance to confirm it. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu -- 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/udlr56sjx9k@dr-wily.mit.edu
Bug#627575: linux-image-2.6.39-1-amd64: hangs loading eeprom after reporting GMBUS timed out [i915]
forwarded 627575 https://bugs.freedesktop.org/show_bug.cgi?id=37514 thanks Ben Hutchings b...@decadent.org.uk writes: I don't recommend that you load this driver. Got it, thanks. ;-) That was all pretty much as I thought, and I can indeed do without the /etc/modules entry (whose absence lets my system boot normally; AFAICT so far, all is otherwise well with 2.6.39). Let us know the bug number or URL so we can track it. I reported it as https://bugs.freedesktop.org/show_bug.cgi?id=37514 and am hereby advising the BTS (via a Bcc: to control@bugs.d.o) that I have done so, though I've left the moreinfo tag set for now in case you need anything else from me. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu -- 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/udl7h9hp74j@dr-wily.mit.edu
Bug#627575: linux-image-2.6.39-1-amd64: hangs loading eeprom after reporting GMBUS timed out [i915]
Package: linux-2.6 Version: 2.6.39-1 Severity: important Since upgrading from 2.6.38-2 (Debian 2.6.38-5), I've found that, at least on systems with integrated Intel graphics, loading the eeprom module hangs indefinitely after reporting messages of the form [drm] GMBUS timed out, falling back to bit banging on pin N [i915 gmbus foo] This regression proved particularly troublesome on my desktop, whose /etc/modules has historically listed eeprom (per sensors-detect?); however, as you can see, I can reproduce it on my laptop as well. (A couple of minor details vary; my desktop's chipset is a Q35 rather than a GM45, and after giving up on pin 0 there, the kernel proceeds to try pin 1, with the hang occurring after one mention thereof.) Could you please investigate this problem? Thanks! -- Package-specific info: ** Version: Linux version 2.6.39-1-amd64 (Debian 2.6.39-1) (m...@debian.org) (gcc version 4.4.5 (Debian 4.4.5-12) ) #1 SMP Thu May 19 14:30:28 UTC 2011 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.39-1-amd64 root=UUID=b42c4bb6-4ecc-42b1-a76c-2fa20f9845e8 ro single ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [ 2904.484147] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2904.540156] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2904.596159] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2904.652153] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2904.708158] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2904.764159] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2904.820147] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2904.876159] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 2905.584162] [drm] GMBUS timed out, falling back to bit banging on pin 6 [i915 gmbus reserved] [ 2905.640162] [drm] GMBUS timed out, falling back to bit banging on pin 6 [i915 gmbus reserved] [ 2905.696046] [drm] GMBUS timed out, falling back to bit banging on pin 6 [i915 gmbus reserved] [ 2905.752155] [drm] GMBUS timed out, falling back to bit banging on pin 6 [i915 gmbus reserved] [ 2905.808119] [drm] GMBUS timed out, falling back to bit banging on pin 6 [i915 gmbus reserved] [ 2905.864110] [drm] GMBUS timed out, falling back to bit banging on pin 6 [i915 gmbus reserved] [ 2905.920157] [drm] GMBUS timed out, falling back to bit banging on pin 7 [i915 gmbus dpd] [ 3120.492233] INFO: task modprobe:8678 blocked for more than 120 seconds. [ 3120.492242] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 3120.492248] modprobeD 8800a32b27a0 0 8678 8677 0x0004 [ 3120.492259] 8800a32b27a0 0082 8800a32b27a0 8800a32a6e40 [ 3120.492271] 00013b40 880086ef7fd8 880086ef7fd8 00013b40 [ 3120.492282] 8800a32b27a0 880086ef6010 8800a32b27a0 880086ef6000 [ 3120.492293] Call Trace: [ 3120.492352] [81331cb5] ? __mutex_lock_common+0x127/0x193 [ 3120.492383] [a024fecc] ? i2c_add_numbered_adapter+0xad/0xad [i2c_core] [ 3120.492391] [81331ded] ? mutex_lock+0x1a/0x33 [ 3120.492406] [a024ff02] ? i2c_add_adapter+0x36/0x86 [i2c_core] [ 3120.492416] [811a95a9] ? snprintf+0x36/0x3b [ 3120.492430] [a02c585c] ? __i2c_bit_add_bus+0x1e9/0x22c [i2c_algo_bit] [ 3120.492459] [a03f227b] ? intel_gpio_create+0x124/0x13d [i915] [ 3120.492486] [a03f29da] ? gmbus_xfer+0x3ef/0x46d [i915] [ 3120.492503] [a024ed26] ? i2c_transfer+0xa1/0xdd [i2c_core] [ 3120.492520] [a024f055] ? i2c_smbus_xfer_emulated+0x2f3/0x3fd [i2c_core] [ 3120.492529] [811a338e] ? kobject_get+0x12/0x17 [ 3120.492539] [81241c84] ? get_device+0x14/0x1b [ 3120.492548] [8131c187] ? klist_add_tail+0x1f/0x41 [ 3120.492556] [81243129] ? device_add+0x4de/0x5d7 [ 3120.492572] [a024f7cc] ? i2c_default_probe+0x99/0xfd [i2c_core] [ 3120.492589] [a025007a] ? i2c_do_add_adapter+0xcf/0x22b [i2c_core] [ 3120.492605] [a02501d6] ? i2c_do_add_adapter+0x22b/0x22b [i2c_core] [ 3120.492615] [81244264] ? bus_for_each_dev+0x44/0x78 [ 3120.492631] [a02501d6] ? i2c_do_add_adapter+0x22b/0x22b [i2c_core] [ 3120.492647] [a024e6a3] ? i2c_for_each_dev+0x2c/0x47 [i2c_core] [ 3120.492668] [a0045000] ? 0xa0044fff [ 3120.492684] [a024e774] ? i2c_register_driver+0x9c/0xa2 [i2c_core] [ 3120.492695] [a0045000] ? 0xa0044fff [ 3120.492704] [81002078] ? do_one_initcall+0x78/0x131 [ 3120.492714] [810757b6] ? sys_init_module+0xd3/0x221 [ 3120.492722] [81338c12] ? system_call_fastpath+0x16/0x1b
Bug#568165: linux-kbuild-2.6.32: please ship recordmcount.pl
Package: linux-kbuild-2.6.32 Version: 2.6.32-1 Severity: important Enabling CONFIG_FTRACE_MCOUNT_RECORD in the kernel's configuration calls for the addition of recordmcount.pl to the set of scripts to install (as listed in scripts/Makefile, AFAICT); could you please do so? Thanks! -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-kbuild-2.6.32 depends on: ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib linux-kbuild-2.6.32 recommends no packages. linux-kbuild-2.6.32 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
Bug#509271: vesafb as static interferes with other FB modules
Package: linux-2.6 Version: 2.6.32-1 Severity: normal I've been running into what appears to be the same problem since upgrading to 2.6.32, in that vesafb is activating unsolicited (despite an explicit video parameter referring to i915) and interfering with inteldrmfb: [0.646467] vesafb: framebuffer at 0xd012c000, mapped to 0xc9001098, using 1216k, total 1216k [0.646471] vesafb: mode is 640x480x32, linelength=2560, pages=0 [0.646473] vesafb: scrolling: redraw [0.646477] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [0.659105] Console: switching to colour frame buffer device 80x30 [0.671601] fb0: VESA VGA frame buffer device ... [0.825885] [drm] Initialized drm 1.1.0 20060810 [0.844237] alloc irq_desc for 16 on node -1 [0.844240] alloc kstat_irqs on node -1 [0.844250] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [0.844255] i915 :00:02.0: setting latency timer to 64 [0.850779] alloc irq_desc for 26 on node -1 [0.850783] alloc kstat_irqs on node -1 [0.850795] i915 :00:02.0: irq 26 for MSI/MSI-X [0.850803] [drm] set up 7M of stolen space [0.979244] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver [0.979372] fb1: inteldrmfb frame buffer device [0.979375] registered panic notifier [0.979430] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 Although X still starts up properly complete with UXA, DRI2, and such, the text consoles remain at the low initial resolution until it starts, and are inaccessible from then on. (Attempting to switch VTs keeps a snapshot of my X desktop displayed; I can at least switch back to X without any lossage, though.) I had no such trouble with Debian's 2.6.31-1, where vesafb remained inactive: [0.818394] [drm] Initialized drm 1.1.0 20060810 [0.829123] alloc irq_desc for 16 on node 0 [0.829127] alloc kstat_irqs on node 0 [0.829139] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [0.829144] i915 :00:02.0: setting latency timer to 64 [0.835758] alloc irq_desc for 26 on node 0 [0.835762] alloc kstat_irqs on node 0 [0.835775] i915 :00:02.0: irq 26 for MSI/MSI-X [1.021708] [drm] DAC-6: set mode 1280x1024 17 [1.046259] Console: switching to colour frame buffer device 160x64 [1.050619] [drm] fb0: inteldrmfb frame buffer device [1.050681] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 -- Package-specific info: ** Version: Linux version 2.6.32-trunk-amd64 (Debian 2.6.32-1) (wa...@debian.org) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Sun Dec 6 17:49:24 UTC 2009 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-trunk-amd64 root=UUID=cb122545-993c-4751-aeb1-0466126af9dc ro quiet console=tty0 selinux=0 video=i915:modeset=1 ** Tainted: P (1) * Proprietary module has been loaded. ** Kernel log: [ 12.734999] REISERFS (device dm-4): checking transaction log (dm-4) [ 12.758019] REISERFS (device dm-4): Using r5 hash to sort names [ 12.796962] REISERFS (device dm-0): found reiserfs format 3.6 with standard journal [ 12.797025] REISERFS (device dm-0): using ordered data mode [ 12.804693] REISERFS (device dm-0): journal params: device dm-0, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 12.805654] REISERFS (device dm-0): checking transaction log (dm-0) [ 12.834560] REISERFS (device dm-0): Using r5 hash to sort names [ 12.928920] REISERFS (device dm-10): found reiserfs format 3.6 with standard journal [ 12.929005] REISERFS (device dm-10): using ordered data mode [ 12.934202] REISERFS (device dm-10): journal params: device dm-10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 12.935169] REISERFS (device dm-10): checking transaction log (dm-10) [ 12.984518] REISERFS (device dm-10): Using r5 hash to sort names [ 13.076194] REISERFS (device dm-8): found reiserfs format 3.6 with standard journal [ 13.076265] REISERFS (device dm-8): using ordered data mode [ 13.084467] REISERFS (device dm-8): journal params: device dm-8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 13.085436] REISERFS (device dm-8): checking transaction log (dm-8) [ 13.118992] REISERFS (device dm-8): Using r5 hash to sort names [ 13.183696] REISERFS (device dm-1): found reiserfs format 3.6 with standard journal [ 13.183768] REISERFS (device dm-1): using ordered data mode [ 13.188134] REISERFS (device dm-1): journal params: device dm-1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 13.189106] REISERFS (device dm-1): checking transaction log (dm-1) [ 13.230233] REISERFS (device dm-1): Using r5 hash to sort names [ 13.313941] REISERFS (device dm-6): found reiserfs format 3.6 with
Bug#533258: scripts/init-top/framebuffer: i915 needs intel-agp too
Package: initramfs-tools Version: 0.93.3 Severity: normal Tags: patch The i915 DRM module doubles as a framebuffer of sorts, at least in kernel mode-setting setups; like its cousins intelfb and i810fb, it effectively requires intel-agp despite not actually using any of its symbols. As such, could you please arrange for scripts/init-top/framebuffer to give it the same treatment, per the following patch?: --- initramfs-tools-0.93.3.orig/scripts/init-top/framebuffer +++ initramfs-tools-0.93.3/scripts/init-top/framebuffer @@ -78,7 +78,7 @@ # Map command line name to module name FB=matroxfb_base ;; -intelfb|i810fb) +intelfb|i810fb|i915) # Needs AGP driver loaded modprobe intel-agp ;; Thanks! -- Package-specific info: -- /proc/cmdline root=/dev/sda1 ro console=tty0 selinux=0 quiet video=i915:modeset=1 -- /proc/filesystems ext3 fuseblk reiserfs -- lsmod Module Size Used by ppdev 7800 0 lp 10612 0 uinput 8448 2 openafs 565040 2 sco10996 2 bridge 48112 0 stp 2868 1 bridge bnep 13744 2 rfcomm 35888 0 l2cap 21136 6 bnep,rfcomm bluetooth 54900 6 sco,bnep,rfcomm,l2cap binfmt_misc 9244 1 nfsd 268432 9 lockd 68052 1 nfsd nfs_acl 3264 1 nfsd auth_rpcgss40832 1 nfsd sunrpc196552 8 nfsd,lockd,nfs_acl,auth_rpcgss exportfs4624 1 nfsd autofs425704 2 acpi_cpufreq8912 0 cpufreq_powersave 1792 0 cpufreq_stats 4660 0 cpufreq_userspace 3620 0 microcode 25736 0 tun13952 2 ccm 8752 0 ecb 3072 0 sha512_generic 5536 0 xfrm_user 20848 2 ah6 6144 0 ah4 5296 0 esp66576 0 esp46832 0 xfrm4_mode_beet 2992 0 xfrm4_tunnel2720 0 tunnel4 3632 1 xfrm4_tunnel xfrm4_mode_tunnel 2752 0 xfrm4_mode_transport 2288 0 xfrm6_mode_transport 2336 0 xfrm6_mode_ro 2176 0 xfrm6_mode_beet 2800 0 xfrm6_mode_tunnel 2656 0 ipcomp 3312 0 ipcomp6 3424 0 xfrm_ipcomp 6172 2 ipcomp,ipcomp6 xfrm6_tunnel9088 1 ipcomp6 tunnel6 3536 1 xfrm6_tunnel rng_core4872 0 deflate 3104 0 zlib_deflate 19960 1 deflate ctr 4624 0 twofish 6816 0 twofish_common 14464 1 twofish camellia 18368 0 serpent17616 0 blowfish8768 0 des_generic16960 0 cbc 3776 0 cryptd 7336 0 aes_x86_64 8928 0 aes_generic27840 1 aes_x86_64 xcbc4840 0 rmd160 7904 0 sha256_generic 9440 0 sha1_generic2528 0 hmac4320 0 crypto_null 3696 0 af_key 29136 2 reiserfs 208552 9 fuse 54544 1 dm_crypt 12920 0 w83627ehf 22944 0 hwmon_vid 3088 1 w83627ehf eeprom 6336 0 cpufreq_conservative 7928 0 ide_generic 2452 0 [permanent] ide_cd_mod 29000 0 piix7256 0 snd_hda_codec_realtek 250068 1 snd_hda_intel 26680 7 snd_hda_codec 75184 2 snd_hda_codec_realtek,snd_hda_intel snd_hwdep 8120 1 snd_hda_codec snd_pcm_oss37200 0 snd_mixer_oss 15072 2 snd_pcm_oss snd_pcm78440 5 snd_hda_intel,snd_hda_codec,snd_pcm_oss snd_seq_midi6976 0 snd_rawmidi22992 1 snd_seq_midi snd_seq_midi_event 7696 1 snd_seq_midi snd_seq51248 3 snd_seq_midi,snd_seq_midi_event snd_timer 21824 4 snd_pcm,snd_seq serio_raw 5844 0 snd_seq_device 7476 3 snd_seq_midi,snd_rawmidi,snd_seq snd63848 20 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device pcspkr 2800 0 evdev 10448 13 psmouse42140 0 tpm_infineon9164 1 i2c_i801 10464 0 soundcore 7984 2 snd tpm16864 1 tpm_infineon parport_pc 27064 1 parport38224 3 ppdev,lp,parport_pc tpm_bios6608 1 tpm snd_page_alloc 9936 2 snd_hda_intel,snd_pcm asus_atk0110
Bug#521515: linux-headers-2.6.29-1-amd64: please restore symlinks into -common
Russ Allbery r...@debian.org writes: Could you open a bug on the openafs package when you get a chance (tomorrow or whenever) and we'll continue this there? It looks like Filed as #521745. Kernel maintainers, apologies for the topic drift here. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521515: Fwd: Re: Bug#521515: linux-headers-2.6.29-1-amd64: please restore symlinks into -common
Forwarding to Russ, who maintains a package that this change (which came without warning TTBOMK) seriously inconveniences; please keep him Cc:ed. ---BeginMessage--- severity 521515 wishlist tags 521515 wontfix thanks On Fri, Mar 27, 2009 at 09:02:04PM -0400, Aaron M. Ucko wrote: As of 2.6.29-1, that no longer holds, causing trouble for packages such as openafs-modules-source that don't entirely defer to the kbuild framework. There is no reliable way to detect the include paths of the kernel without using kbuild. but would appreciate it if you could please reinstate the symlinks in the flavor-specific linux-headers packages. Nope. At least not until you show that it breaks the _documented_ usage. Bastian -- Most legends have their basis in facts. -- Kirk, And The Children Shall Lead, stardate 5029.5 ---End Message---
Bug#521515: linux-headers-2.6.29-1-amd64: please restore symlinks into -common
Russ Allbery r...@debian.org writes: OpenAFS *does* use kbuild. Aaron, what exactly breaks? Example error messages? Is it just the symlinking to standardize the names of the header files across platforms that doesn't work? Yes: | CC [M] /usr/src/modass/usr_src/modules/openafs/src/libafs/MODLOAD-2.6.29-1-amd64-MP/afs_atomlist.o | In file included from /usr/src/modass/usr_src/modules/openafs/include/afs/afs_sysnames.h:25, | from /usr/src/modass/usr_src/modules/openafs/include/afs/param.h:55, | from /usr/src/modass/usr_src/modules/openafs/src/libafs/MODLOAD-2.6.29-1-amd64-MP/afs_atomlist.c:11: | /usr/src/modass/usr_src/modules/openafs/include/afs/stds.h:14:23: error: sys/types.h: No such file or directory followed by a cascade of other errors, starting with | In file included from /usr/src/modass/usr_src/modules/openafs/src/libafs/MODLOAD-2.6.29-1-amd64-MP/afs_atomlist.c:17: | /usr/src/modass/usr_src/modules/openafs/src/util/afs_atomlist.h:54: error: expected ‘)’ before ‘atom_size’ OpenAFS could probably adapt by changing h, netinet, and sys under MODLOAD-* from symlinks to .../include/linux to directories containing forwarding headers; I'm not sure which specific headers would need such treatment, but I suspect there are quite a few. Please let me know if you'd like any other information. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521515: linux-headers-2.6.29-1-amd64: please restore symlinks into -common
Russ Allbery r...@debian.org writes:
egrep -r '#include +[](sys|netinet|h)/' *.[ch] LINUX/ | awk '{ print $2 }'
| sed -e 's,\.\./,,' -e 's/[]//g' | sort -u
and as near as I can tell, on Linux, all those headers have the same name
but just have no directory prefix. So netinet/in.h becomes just in.h,
sys/types.h becomes just types.h, etc. Does that look right to you?
Not quite; I believe they'd become linux/in.h, linux/types.h, etc.
Moreover, a lot of the inclusions were indirect; for instance, the
#include directive for sys/types.h ultimately came from afs/stds.h
(copied from .../src/config/). As such, I'm not convinced scouring
LINUX and rx will be entirely sufficient.
and then see if that makes the build work? You'll have to do this after
make_kbuild_makefile.pl runs. (If that's more complexity to testing than
you can easily do, I'll be able to look at it eventually, but I don't have
the new kbuild infrastructure installed anywhere yet.)
I should be able to do that, but I'm tired and on my way to bed, so
it'll have to wait until at least tomorrow.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521515: linux-headers-2.6.29-1-amd64: please restore symlinks into -common
Package: linux-headers-2.6.29-1-amd64 Version: 2.6.29-1 Severity: normal Historically, /usr/src/linux-headers-VERSION-FLAVOR used to contain symlinks into /usr/src/linux-headers-VERSION-common for anything not at least potentially flavor-specific. As of 2.6.29-1, that no longer holds, causing trouble for packages such as openafs-modules-source that don't entirely defer to the kbuild framework. (OpenAFS is particularly special due to its age and support for a wide range of platforms, and makes symlinks to /lib/modules/VERSION-FLAVOR/build/include/linux in its build tree so that it can variously include the headers as h/*.h, netinet/*.h, and sys/*.h.) I have worked around the problem on my own system by throwing together a package containing a portion of the dropped symlinks (those from and into .../linux), but would appreciate it if you could please reinstate the symlinks in the flavor-specific linux-headers packages. Thanks! -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-headers-2.6.29-1-amd64 depends on: ii gcc-4.3 4.3.3-5The GNU C compiler ii linux-headers-2.6.29-1-common 2.6.29-1 Common header files for Linux 2.6. ii linux-kbuild-2.6.29 2.6.29-1 Kbuild infrastructure for Linux 2. linux-headers-2.6.29-1-amd64 recommends no packages. linux-headers-2.6.29-1-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
Bug#298099: kernel: please allow building AGP_INTEL on x86_64
Package: kernel
Severity: normal
Tags: patch upstream
The kernel's build system insists that users of x86_64 hardware use
AGP_INTEL_MCH rather than AGP_INTEL. However, the MCH driver supports
a far more limited range of hardware, and in particular fails to
support my system's i915G chipset. (I have one of the new P4s with
support for EM64T.)
Perhaps it would be better to add support for this chipset to the MCH
driver, but the regular driver seems to work fine -- X runs without
problems, certainly.
I have attached a (trivial) patch to drop the bogus restriction, along
with a patch for some 64-bit cleanliness issues in i810_dma.c that it
uncovers (though the latter's probably gratuitous given that the
original i810 allmost certainly doesn't support any 64-bit processors
anyway).
--- kernel-source-2.6.11/drivers/char/agp/Kconfig~ 2005-03-02
02:38:10.0 -0500
+++ kernel-source-2.6.11/drivers/char/agp/Kconfig 2005-03-03
14:03:51.0 -0500
@@ -78,7 +78,7 @@
config AGP_INTEL
tristate Intel 440LX/BX/GX, I8xx and E7x05 chipset support
- depends on AGP X86 !X86_64
+ depends on AGP X86
help
This option gives you AGP support for the GLX component of XFree86 4.x
on Intel 440LX/BX/GX, 815, 820, 830, 840, 845, 850, 860, 875,
--- kernel-source-2.6.11/drivers/char/drm/i810_dma.c~ 2005-03-02
02:37:55.0 -0500
+++ kernel-source-2.6.11/drivers/char/drm/i810_dma.c2005-03-04
11:27:58.0 -0500
@@ -847,7 +847,7 @@
*(u32 *)buf_priv-kernel_virtual = ((GFX_OP_PRIMITIVE | prim |
((used/4)-2)));
if (used 4) {
- *(u32 *)((u32)buf_priv-kernel_virtual + used) = 0;
+ *(u32 *)((unsigned long)buf_priv-kernel_virtual +
used) = 0;
used += 4;
}
@@ -1207,7 +1207,7 @@
if (buf_priv-currently_mapped == I810_BUF_MAPPED) {
if (used 4) {
- *(u32 *)((u32)buf_priv-virtual + used) = 0;
+ *(u32 *)((unsigned long)buf_priv-virtual + used) = 0;
used += 4;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
