Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore
On Sun, Jun 18, 2023 at 08:15:43AM +0900, Mike Hommey wrote: > On Sun, Jun 18, 2023 at 06:09:57AM +0900, Mike Hommey wrote: > > On Sat, Jun 17, 2023 at 01:20:30AM +0200, Diederik de Haas wrote: > > > Control: tag -1 -moreinfo > > > Control: found -1 6.1.20-1 > > > > > > On Saturday, 17 June 2023 01:00:58 CEST Mike Hommey wrote: > > > > > 6.1.12-1 and 6.1.15-1 are good. 6.1.20-1 is the first broken one. > > > > > > Excellent, thanks. This is already very useful. > > > > > > > > > A `git bisect` would be best, but grabbing these intermediate > > > > > > versions > > > > > > (from snapshot.debian.org) is the quickest way to narrow the range. > > > > > > > > > > Last time I tried to build Debian linux kernels, it was spending a > > > > > large > > > > > amount of time building packages I don't need, and finding the right > > > > > incantation to reduce that load was not straightforward, and I can't > > > > > find my notes, unfortunately. If you have instructions I can use to go > > > > > through a bisect in a quick manner, I'm all ears. > > > > > > > > Although, if you have instructions to just build the one module and > > > > avoid > > > > rebooting, that would be even better. > > > > > > I _think_ building just one module or without rebooting is not possible. > > > > > > The 'official' instructions: > > > https://wiki.debian.org/DebianKernel/GitBisect > > > > > > I know some things to reduce what gets build, like f.e. what's described > > > here: > > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.7 > > > And there's also a facility to work with _build profiles_. > > > But I don't know if or how that could be applied to the 'official' > > > instructions > > > as that deals with the upstream kernel source directly. > > > > > > Hopefully one of the (more) experienced people chimes in with > > > actual useful things ... > > > > I was able to build the relevant module only. The regression comes from > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=337c3624bcb008f92bab38c8fc4cdf97ae5313a2 > > I sent a patch upstream, but it's not showing up on the archives yet. > I'll update with a link when I have one. Here we go: https://patchwork.kernel.org/project/linux-input/patch/20230617230957.6mx73th4blv7o...@glandium.org/ Mike
Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore
On Sun, Jun 18, 2023 at 06:09:57AM +0900, Mike Hommey wrote: > On Sat, Jun 17, 2023 at 01:20:30AM +0200, Diederik de Haas wrote: > > Control: tag -1 -moreinfo > > Control: found -1 6.1.20-1 > > > > On Saturday, 17 June 2023 01:00:58 CEST Mike Hommey wrote: > > > > 6.1.12-1 and 6.1.15-1 are good. 6.1.20-1 is the first broken one. > > > > Excellent, thanks. This is already very useful. > > > > > > > A `git bisect` would be best, but grabbing these intermediate versions > > > > > (from snapshot.debian.org) is the quickest way to narrow the range. > > > > > > > > Last time I tried to build Debian linux kernels, it was spending a large > > > > amount of time building packages I don't need, and finding the right > > > > incantation to reduce that load was not straightforward, and I can't > > > > find my notes, unfortunately. If you have instructions I can use to go > > > > through a bisect in a quick manner, I'm all ears. > > > > > > Although, if you have instructions to just build the one module and avoid > > > rebooting, that would be even better. > > > > I _think_ building just one module or without rebooting is not possible. > > > > The 'official' instructions: https://wiki.debian.org/DebianKernel/GitBisect > > > > I know some things to reduce what gets build, like f.e. what's described > > here: > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.7 > > And there's also a facility to work with _build profiles_. > > But I don't know if or how that could be applied to the 'official' > > instructions > > as that deals with the upstream kernel source directly. > > > > Hopefully one of the (more) experienced people chimes in with > > actual useful things ... > > I was able to build the relevant module only. The regression comes from > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=337c3624bcb008f92bab38c8fc4cdf97ae5313a2 I sent a patch upstream, but it's not showing up on the archives yet. I'll update with a link when I have one. Mike
Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore
On Sat, Jun 17, 2023 at 01:20:30AM +0200, Diederik de Haas wrote: > Control: tag -1 -moreinfo > Control: found -1 6.1.20-1 > > On Saturday, 17 June 2023 01:00:58 CEST Mike Hommey wrote: > > > 6.1.12-1 and 6.1.15-1 are good. 6.1.20-1 is the first broken one. > > Excellent, thanks. This is already very useful. > > > > > A `git bisect` would be best, but grabbing these intermediate versions > > > > (from snapshot.debian.org) is the quickest way to narrow the range. > > > > > > Last time I tried to build Debian linux kernels, it was spending a large > > > amount of time building packages I don't need, and finding the right > > > incantation to reduce that load was not straightforward, and I can't > > > find my notes, unfortunately. If you have instructions I can use to go > > > through a bisect in a quick manner, I'm all ears. > > > > Although, if you have instructions to just build the one module and avoid > > rebooting, that would be even better. > > I _think_ building just one module or without rebooting is not possible. > > The 'official' instructions: https://wiki.debian.org/DebianKernel/GitBisect > > I know some things to reduce what gets build, like f.e. what's described here: > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.7 > And there's also a facility to work with _build profiles_. > But I don't know if or how that could be applied to the 'official' > instructions > as that deals with the upstream kernel source directly. > > Hopefully one of the (more) experienced people chimes in with > actual useful things ... I was able to build the relevant module only. The regression comes from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=337c3624bcb008f92bab38c8fc4cdf97ae5313a2 Mike
Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore
On Sat, Jun 17, 2023 at 07:59:17AM +0900, Mike Hommey wrote: > On Sat, Jun 17, 2023 at 12:13:13AM +0200, Diederik de Haas wrote: > > Control: tag -1 moreinfo > > > > On Fri Jun 16, 2023 at 11:21 PM CEST, Mike Hommey wrote: > > > Package: src:linux > > > Version: 6.1.27-1 > > > > > > After upgrading to bookworm, my bluetooth trackpad stopped working. It's > > > properly connected, and `libinput list-devices` displays this message: > > > > > > event15 - Logitech Rechargeable Trackpad T651: kernel bug: device has min > > > == > > max on ABS_MT_POSITION_X > > > > > > It worked with earlier kernel versions. I went back to one I had at hand > > > from before the upgrade (6.1.0-0.deb11.5-amd64), and it worked again, > > > > Version 6.1.0-0.deb11.5 should be the same as version 6.1.12-1. > > If would be useful if you could verify that with the non-backports kernel > > it also works again. > > If that's the case, could you try newer versions (6.1.15-1, 6.1.20-1 and > > 6.1.25-1) to find the newest kernel version that still works? > > 6.1.12-1 and 6.1.15-1 are good. 6.1.20-1 is the first broken one. > > > A `git bisect` would be best, but grabbing these intermediate versions > > (from snapshot.debian.org) is the quickest way to narrow the range. > > Last time I tried to build Debian linux kernels, it was spending a large > amount of time building packages I don't need, and finding the right > incantation to reduce that load was not straightforward, and I can't > find my notes, unfortunately. If you have instructions I can use to go > through a bisect in a quick manner, I'm all ears. Although, if you have instructions to just build the one module and avoid rebooting, that would be even better. Mike
Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore
On Sat, Jun 17, 2023 at 12:13:13AM +0200, Diederik de Haas wrote: > Control: tag -1 moreinfo > > On Fri Jun 16, 2023 at 11:21 PM CEST, Mike Hommey wrote: > > Package: src:linux > > Version: 6.1.27-1 > > > > After upgrading to bookworm, my bluetooth trackpad stopped working. It's > > properly connected, and `libinput list-devices` displays this message: > > > > event15 - Logitech Rechargeable Trackpad T651: kernel bug: device has min > > == > max on ABS_MT_POSITION_X > > > > It worked with earlier kernel versions. I went back to one I had at hand > > from before the upgrade (6.1.0-0.deb11.5-amd64), and it worked again, > > Version 6.1.0-0.deb11.5 should be the same as version 6.1.12-1. > If would be useful if you could verify that with the non-backports kernel > it also works again. > If that's the case, could you try newer versions (6.1.15-1, 6.1.20-1 and > 6.1.25-1) to find the newest kernel version that still works? 6.1.12-1 and 6.1.15-1 are good. 6.1.20-1 is the first broken one. > A `git bisect` would be best, but grabbing these intermediate versions > (from snapshot.debian.org) is the quickest way to narrow the range. Last time I tried to build Debian linux kernels, it was spending a large amount of time building packages I don't need, and finding the right incantation to reduce that load was not straightforward, and I can't find my notes, unfortunately. If you have instructions I can use to go through a bisect in a quick manner, I'm all ears. Mike
Bug#1038271: linux-image-6.1.0-9-amd64: Logitech trackpad T651 doesn't work anymore
Package: src:linux Version: 6.1.27-1 Severity: important Dear Maintainer, After upgrading to bookworm, my bluetooth trackpad stopped working. It's properly connected, and `libinput list-devices` displays this message: event15 - Logitech Rechargeable Trackpad T651: kernel bug: device has min == max on ABS_MT_POSITION_X It worked with earlier kernel versions. I went back to one I had at hand from before the upgrade (6.1.0-0.deb11.5-amd64), and it worked again, with `libinput list-devices` reporting: Device: Logitech Rechargeable Trackpad T651 Kernel: /dev/input/event15 Group:7 Seat: seat0, default Size: 123x103mm Capabilities: pointer gesture Tap-to-click: disabled Tap-and-drag: enabled Tap drag lock:disabled Left-handed: disabled Nat.scrolling:disabled Middle emulation: disabled Calibration: n/a Scroll methods: *two-finger edge Click methods:*button-areas clickfinger Disable-w-typing: n/a Disable-w-trackpointing: n/a Accel profiles: flat *adaptive Rotation: n/a -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Gigabyte Technology Co., Ltd. product_name: TRX40 AORUS PRO WIFI product_version: -CF chassis_vendor: Default string chassis_version: Default string bios_vendor: American Megatrends International, LLC. bios_version: F6 board_vendor: Gigabyte Technology Co., Ltd. board_name: TRX40 AORUS PRO WIFI board_version: Default string ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480] Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483] (prog-if 00 [Normal decode]) Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1453] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 61) Subsystem: Gigabyte Technology Co., Ltd FCH SMBus Controller [1458:5001] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel driver in use: nvme Kernel modules: nvme 02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 [144d:a808] (prog-if 02 [NVM Express]) Subsystem: Samsung Electronics Co Ltd SSD 970 EVO [144d:a801] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel
Bug#992219: [Pkg-zfsonlinux-devel] Bug#992219: zfs-dkms: Error! Bad return status for module build on kernel: 5.13.0-trunk-amd64 (x86_64)
severity 992219 important retitle 992219 Cannot open /usr/src/linux-headers-5.13.0-trunk-common/scripts/modules-check.sh: No such file thanks On Sun, Aug 15, 2021 at 06:48:02PM -0600, Antonio Russo wrote: > Control: severity -1 wishlist > Control: retitle -1 Please backport support for 5.13 > > Hello, > > ZFS 2.0.3 doesn't support 5.13. Neither does 2.0.5, (which is a > matter of some friction). You'll have to switch to 2.1 if you > can't wait -- and I haven't gotten around to packaging it yet. > > - Antonio The bug was reassigned to the linux-headers package because before reaching the point where it is made apparent that zfs 2.0.3 doesn't support Linux 5.13, we hit an error coming from a missing file in the linux-headers package.
Re: Uploading linux (5.4.8-1)
Hi, Are you planning an update in buster-backports, too? Cheers, Mike On Sun, Jan 05, 2020 at 01:45:49PM +0100, Salvatore Bonaccorso wrote: > Hi > > I'm intenting to upload linux version 5.4.8-1 to unstable today > (Sunday) unless some surprises arise. As perfering to move to the new > stable version 5.4.8 while there were ABI changes, prefered to do an > ABI bump. > > The upload cosinst of imports of the new 5.4.7 and 5.4.8 stable > versions and additionally the following packaging changes were done: > >* Enable EROFS filesystem support as module. > Enable EROFS_FS as module, enable EROFS_FS_XATTR, EROFS_FS_POSIX_ACL, > EROFS_FS_SECURITY, EROFS_FS_ZIP and EROFS_FS_CLUSTER_PAGE_LIMIT. > Thanks to Gao Xiang (Closes: #946569) >* Enable additional netfilter modules. > Enable NFT_BRIDGE_META, NF_CONNTRACK_BRIDGE, IP6_NF_MATCH_SRH, NFT_XFRM > and NFT_SYNPROXY as modules. > Thanks to Arturo Borrero Gonzalez (Closes: #948031) > > and fixes for FBTFS on mips* (Thanks to YunQiang Su) > >[ YunQiang Su ] >* [mips*/octeon] Fix ftbfs on mips* due to octeon image-file: > move "image-file: linux" to octeon_build from octeon_image. > > Regards, > Salvatore
Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd
On Thu, Oct 25, 2018 at 03:20:11PM +0900, Mike Hommey wrote: > Package: linux-perf-4.18 > Version: 4.18.10-2 > Severity: wishlist > File: /usr/bin/perf_4.18 > > Dear Maintainer, > > Running e.g. perf report with dwarf call graph info can take a long time > depending on the size of the profile and the size of dwarf info in the > binaries being profiled. That's because each address in each library is > handled by forking and executing a new addr2line process. Each addr2line > process has to parse the dwarf info of the library it's given just to > find the location of one address. Multiply by the number of addresses, > and this can quickly become ridiculous. > > Perf, however, has an alternative implementation that just uses libbfd, > so it would be much faster than spawning a large amount of new > processes, each with a large overhead. I found https://salsa.debian.org/kernel-team/linux/blob/master/debian/rules.d/tools/perf/Makefile#L27-31 This sucks badly :( I have some massive perf data that take *hours* to deal with without libbfd. With a reduced perf data, this is the kind of difference this makes: $ time perf script > /dev/null # addr2line real3m8.718s user1m12.606s sys 1m56.649s $ time perf script > /dev/null # libbfd real0m4.141s user0m3.425s sys 0m0.894s Mike
Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd
Package: linux-perf-4.18 Version: 4.18.10-2 Severity: wishlist File: /usr/bin/perf_4.18 Dear Maintainer, Running e.g. perf report with dwarf call graph info can take a long time depending on the size of the profile and the size of dwarf info in the binaries being profiled. That's because each address in each library is handled by forking and executing a new addr2line process. Each addr2line process has to parse the dwarf info of the library it's given just to find the location of one address. Multiply by the number of addresses, and this can quickly become ridiculous. Perf, however, has an alternative implementation that just uses libbfd, so it would be much faster than spawning a large amount of new processes, each with a large overhead. Mike -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-perf-4.18 depends on: ii libbabeltrace1 1.5.6-1 ii libc6 2.27-6 ii libdw1 0.170-0.5 ii libelf1 0.170-0.5 ii liblzma55.2.2-1.3 ii libnuma12.0.12-1 ii libperl5.26 5.26.2-7+b1 ii libpython3.63.6.7-1 ii libslang2 2.3.2-1+b1 ii libunwind8 1.2.1-8 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages linux-perf-4.18 recommends: ii linux-base 4.5 Versions of packages linux-perf-4.18 suggests: pn linux-doc-4.18 -- no debconf information
Bug#808792: firmware-iwlwifi: iwlwifi-7260-17.ucode is missing
Package: firmware-iwlwifi Version: 20151207-1 Severity: normal # dmesg | grep iwlwifi | head -5 [7.473576] iwlwifi :06:00.0: enabling device ( -> 0002) [7.475332] iwlwifi :06:00.0: firmware: failed to load iwlwifi-7260-17.ucode (-2) [7.475337] iwlwifi :06:00.0: Direct firmware load for iwlwifi-7260-17.ucode failed with error -2 [7.479873] iwlwifi :06:00.0: firmware: direct-loading firmware iwlwifi-7260-16.ucode [7.480478] iwlwifi :06:00.0: loaded firmware version 16.242414.0 op_mode iwlmvm -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) firmware-iwlwifi depends on no packages. firmware-iwlwifi recommends no packages. Versions of packages firmware-iwlwifi suggests: ii initramfs-tools 0.120 -- no debconf information
Bug#773250: linux-image-3.18.0-trunk-amd64: USB keyboard not recognized at the time cryptsetup prompt shows up
Package: src:linux Version: 3.18-1~exp1 Severity: important Preliminary note: this works fine with linux-image-3.16.0-4-amd64 and all versions before that. My setup involves a luks encrypted root file system, so I get a prompt during boot for the passphrase. When booting with the kernel from linux-image-3.18.0-trunk-amd64, I simply can't type that passphrase with a usb keyboard. Note that before linux-image-3.18.0-trunk-amd64, it did work, but not immediately: at the time the prompt showed up, it would not actually work, and it would take a few seconds for the keyboard to be recognized, but it would eventually be useable to type the passphrase. This, in turn, may be related to the fact that the keyboard doesn't work in grub either, probably because the old bios compatibility doesn't work. If it did, I guess there would actually be no problem with the cryptsetup prompt. -- Package-specific info: ** Version: Linux version 3.18.0-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-4) ) #1 SMP Debian 3.18-1~exp1 (2014-12-11) ** Command line: BOOT_IMAGE=/vmlinuz-3.18.0-trunk-amd64 root=/dev/mapper/zenigata-root ro quiet ** Not tainted ** Kernel log: [ 19.479456] Bluetooth: SCO socket layer initialized [ 19.481502] usbcore: registered new interface driver btusb [ 19.483235] hidraw: raw HID events driver (C) Jiri Kosina [ 19.483523] media: Linux media interface: v0.10 [ 19.486736] Linux video capture interface: v2.00 [ 19.490747] uvcvideo: Found UVC 1.00 device Integrated Webcam (0bda:5716) [ 19.494883] Bluetooth: hci0: read Intel version: 370710018002030d37 [ 19.494886] Bluetooth: hci0: Intel device is already patched. patch num: 37 [ 19.497586] usbcore: registered new interface driver usbhid [ 19.497589] usbhid: USB HID core driver [ 19.498962] input: Integrated Webcam as /devices/pci:00/:00:14.0/usb2/2-5/2-5:1.0/input/input14 [ 19.499038] usbcore: registered new interface driver uvcvideo [ 19.499040] USB Video Class driver (1.1.1) [ 19.540150] usb 2-1.2.2: new low-speed USB device number 9 using xhci_hcd [ 19.634530] usb 2-1.2.2: New USB device found, idVendor=05ac, idProduct=0304 [ 19.634534] usb 2-1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 19.634537] usb 2-1.2.2: Product: Apple Optical USB Mouse [ 19.634538] usb 2-1.2.2: Manufacturer: Mitsumi Electric [ 19.634747] usb 2-1.2.2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes [ 19.708413] usb 2-1.2.3: new high-speed USB device number 10 using xhci_hcd [ 19.805829] usb 2-1.2.3: New USB device found, idVendor=13fe, idProduct=1f00 [ 19.805833] usb 2-1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 19.805836] usb 2-1.2.3: Product: Patriot Memory [ 19.805837] usb 2-1.2.3: Manufacturer: [ 19.805839] usb 2-1.2.3: SerialNumber: 078A1DB11609 [ 19.817557] input: HID 0566:3107 as /devices/pci:00/:00:14.0/usb2/2-1/2-1.2/2-1.2.1/2-1.2.1:1.0/0003:0566:3107.0001/input/input15 [ 19.817695] hid-generic 0003:0566:3107.0001: input,hidraw0: USB HID v1.10 Keyboard [HID 0566:3107] on usb-:00:14.0-1.2.1/input0 [ 19.818858] input: HID 0566:3107 as /devices/pci:00/:00:14.0/usb2/2-1/2-1.2/2-1.2.1/2-1.2.1:1.1/0003:0566:3107.0002/input/input16 [ 19.819240] input: Mitsumi Electric Apple Optical USB Mouse as /devices/pci:00/:00:14.0/usb2/2-1/2-1.2/2-1.2.2/2-1.2.2:1.0/0003:05AC:0304.0004/input/input17 [ 19.820157] hid-generic 0003:0566:3107.0002: input,hidraw1: USB HID v1.10 Device [HID 0566:3107] on usb-:00:14.0-1.2.1/input1 [ 19.820658] apple 0003:05AC:0304.0004: input,hidraw2: USB HID v1.10 Mouse [Mitsumi Electric Apple Optical USB Mouse] on usb-:00:14.0-1.2.2/input0 [ 19.820685] usb-storage 2-1.2.3:1.0: USB Mass Storage device detected [ 19.821692] scsi host3: usb-storage 2-1.2.3:1.0 [ 19.821799] usbcore: registered new interface driver usb-storage [ 19.878557] systemd-journald[284]: Received request to flush runtime journal from PID 1 [ 19.989804] RPC: Registered named UNIX socket transport module. [ 19.989807] RPC: Registered udp transport module. [ 19.989808] RPC: Registered tcp transport module. [ 19.989808] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 19.992791] FS-Cache: Loaded [ 19.999896] FS-Cache: Netfs 'nfs' registered for caching [ 20.006610] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 20.122205] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 20.122208] Bluetooth: BNEP filters: protocol multicast [ 20.122215] Bluetooth: BNEP socket layer initialized [ 20.481233] iwlwifi :06:00.0: L1 Enabled - LTR Enabled [ 20.481841] iwlwifi :06:00.0: L1 Enabled - LTR Enabled [ 20.821977] scsi 3:0:0:0: Direct-Access Patriot Memory PMAP PQ: 0 ANSI: 0 CCS [ 20.822548] sd 3:0:0:0: [sdb] 15654912 512-byte logical blocks: (8.01 GB/7.46 GiB) [ 20.822636] sd 3:0:0:0: Attached scsi
Bug#773250: linux-image-3.18.0-trunk-amd64: USB keyboard not recognized at the time cryptsetup prompt shows up
On Tue, Dec 16, 2014 at 09:22:42AM +0900, Mike Hommey wrote: Package: src:linux Version: 3.18-1~exp1 Severity: important Preliminary note: this works fine with linux-image-3.16.0-4-amd64 and all versions before that. My setup involves a luks encrypted root file system, so I get a prompt during boot for the passphrase. When booting with the kernel from linux-image-3.18.0-trunk-amd64, I simply can't type that passphrase with a usb keyboard. Note that before linux-image-3.18.0-trunk-amd64, it did work, but not immediately: at the time the prompt showed up, it would not actually work, and it would take a few seconds for the keyboard to be recognized, but it would eventually be useable to type the passphrase. This, in turn, may be related to the fact that the keyboard doesn't work in grub either, probably because the old bios compatibility doesn't work. If it did, I guess there would actually be no problem with the cryptsetup prompt. So it turns out that legacy support was disabled in the bios, and that made grub not recognize the keyboard... but that didn't solve the issue with the cryptsetup prompt. Mike -- 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/20141216062027.ga32...@glandium.org
Bug#694759: linux-tools-3.6: Wrong KERNEL_ARCH_PERF set for amd64
On Sat, Dec 01, 2012 at 10:17:54PM +, Ben Hutchings wrote: On Thu, 2012-11-29 at 23:40 +0100, Mike Hommey wrote: Package: linux-tools-3.6 Version: 3.6-1~experimental.1 Severity: important debian/build/tools/perf/Makefile reads: else ifeq ($(DEB_HOST_ARCH_CPU),amd64) KERNEL_ARCH_PERF = x86 This should really be: else ifeq ($(DEB_HOST_ARCH_CPU),amd64) KERNEL_ARCH_PERF = x86_64 Because tools/perf/Makefile has special cases for ARCH=x86_64. This is especially important on 3.7 when building with libunwind. This doesn't work (by itself) because tools/perf/Makefile needs to change ARCH from x86_64 to x86, and that won't happen if we specify ARCH on the command line. Possibly we need to pass it as an environment variable instead... It uses override to do that, which, heh, overrides what's given on the command line. I successfully built linux-tools-3.7 with libunwind support and ARCH=x86_64 that way (libunwind support doesn't build without ARCH=x86_64 because it lacks the necessary -l flag which is only set with ARCH=x86_64) Mike -- 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/20121201224204.ga3...@glandium.org
Bug#694759: linux-tools-3.6: Wrong KERNEL_ARCH_PERF set for amd64
On Sat, Dec 01, 2012 at 10:50:22PM +, Ben Hutchings wrote: On Sat, 2012-12-01 at 23:42 +0100, Mike Hommey wrote: On Sat, Dec 01, 2012 at 10:17:54PM +, Ben Hutchings wrote: On Thu, 2012-11-29 at 23:40 +0100, Mike Hommey wrote: Package: linux-tools-3.6 Version: 3.6-1~experimental.1 Severity: important debian/build/tools/perf/Makefile reads: else ifeq ($(DEB_HOST_ARCH_CPU),amd64) KERNEL_ARCH_PERF = x86 This should really be: else ifeq ($(DEB_HOST_ARCH_CPU),amd64) KERNEL_ARCH_PERF = x86_64 Because tools/perf/Makefile has special cases for ARCH=x86_64. This is especially important on 3.7 when building with libunwind. This doesn't work (by itself) because tools/perf/Makefile needs to change ARCH from x86_64 to x86, and that won't happen if we specify ARCH on the command line. Possibly we need to pass it as an environment variable instead... It uses override to do that, which, heh, overrides what's given on the command line. Not in the version you reported this against. Then you can run ARCH=x86_64 make instead of make ARCH=x86_64 Mike -- 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/20121201230901.ga3...@glandium.org
Bug#694759: linux-tools-3.6: Wrong KERNEL_ARCH_PERF set for amd64
Package: linux-tools-3.6 Version: 3.6-1~experimental.1 Severity: important debian/build/tools/perf/Makefile reads: else ifeq ($(DEB_HOST_ARCH_CPU),amd64) KERNEL_ARCH_PERF = x86 This should really be: else ifeq ($(DEB_HOST_ARCH_CPU),amd64) KERNEL_ARCH_PERF = x86_64 Because tools/perf/Makefile has special cases for ARCH=x86_64. This is especially important on 3.7 when building with libunwind. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.6-trunk-amd64 (SMP w/4 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 linux-tools-3.6 depends on: ii libc6 2.13-37 ii libdw10.153-2 ii libelf1 0.153-2 ii libnewt0.52 0.52.14-10 ii libperl5.14 5.14.2-15 ii libpython2.7 2.7.3-5 ii libslang2 2.2.4-15 ii perl 5.14.2-15 ii python2.7.3-3 Versions of packages linux-tools-3.6 recommends: ii linux-base 3.5 Versions of packages linux-tools-3.6 suggests: pn linux-doc-3.6 none -- 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/20121129224029.23586.84804.report...@jigen.glandium.org
Bug#694759: linux-tools-3.6: Wrong KERNEL_ARCH_PERF set for amd64
On Thu, Nov 29, 2012 at 11:40:29PM +0100, Mike Hommey wrote: Package: linux-tools-3.6 Version: 3.6-1~experimental.1 Severity: important debian/build/tools/perf/Makefile reads: else ifeq ($(DEB_HOST_ARCH_CPU),amd64) KERNEL_ARCH_PERF = x86 This should really be: else ifeq ($(DEB_HOST_ARCH_CPU),amd64) KERNEL_ARCH_PERF = x86_64 Because tools/perf/Makefile has special cases for ARCH=x86_64. This is especially important on 3.7 when building with libunwind. Note 'arch/x86/lib/memset_64.S' also needs to be added near 'arch/x86/lib/memcpy_64.S' in debian/bin/genorig.py. Mike -- 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/20121129225139.ga25...@glandium.org
Re: amd64 as default architecture
On Sun, May 20, 2012 at 02:00:21PM +0100, Ben Hutchings wrote:
On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
Ben Hutchings b...@decadent.org.uk writes:
Most new PCs have an Intel or AMD 64-bit processor, and
popcon.debian.org shows amd64 numbers almost matching i386.
For some time we have also provided the amd64 kernel for i386, identical
in all but the package metadata. This has not always been perfectly
compatible with i386 userland, but split 32/64-bit installations are
increasingly used and I think most bugs have been flushed out by now.
Thanks to multi-arch you can now add amd64 as a secondary architecture
and install the kernel package from amd64, and if your system is running
such a kernel then it can also support userland packages from amd64.
So in wheezy I would like to see:
1. Default architecture (top of the list for installation media/manual)
being amd64 ('64-bit PC').
Default image could be multiple archs. We had i386/amd64/ppc DVD images
in the past and that seems like the best default. It simply works (near
enough) everywhere. Doesn't work for all image types but where it does ...
The default image *is* i386/amd64 netinst.
2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
a secondary architecture (debconf note?).
2b. Have D-I ask wether to enable multiarch on amd64 on i386 if it
installed the amd64 kernel image but also i386 on amd64.
Would be good, but might not be possible in time for wheezy.
Slightly OT but I wanted to mention it for its similarity:
One thing that should be tested and then documented prominently as yay
or nay in the wheezy upgrade notes is wether one can cross-grade from
i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
then migrate to a 64bit userspace.
I don't believe this is easily doable yet. (It was possible, with
difficulty, even before multi-arch.)
Then in wheezy+1:
3. amd64 kernel flavour for i386 dropped.
4. Kernel and common libraries for amd64 included in i386 installation
media; kernel included on low-number disc.
5. Installer for i386 prefers amd64 kernel on any capable machine
(that's a one-line change!) and adds amd64 as secondary architecture if
this is selected.
D-I (libdebian-installer) must be multiarch aware for that then.
Otherwise it won't see the amd64 kernel in the first place.
Yes.
Eventually (wheezy+2? +3?) we would stop building a kernel package for
i386.
As in drop the i386 arch?
No, keep i386 userland only. Though we might consider reducing even
that to a 'partial architecture' that has only libraries (similar to
ia32-libs today, only cleaner).
How would plain x86 systems be supposed to boot, then?
Mike
--
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/20120520162423.ga5...@glandium.org
Bug#601187: linux-image-2.6.32-5-amd64: Please apply patch for shared I/O region support
On Mon, Dec 06, 2010 at 08:44:14AM +0100, Mike Hommey wrote: On Mon, Dec 06, 2010 at 04:25:13AM +, Ben Hutchings wrote: On Thu, 2010-12-02 at 13:39 +0100, Mike Hommey wrote: Is the following going to be considered for squeeze? I've cherry-picked all the necessary changes (I think): 8b6d043b7ee2d1b819dc833d677ea2aead71a0c0 resource: shared I/O region support 729d273aa7c86eb1406ade4eadf249cff188bf9a hwmon: (f71882fg) Acquire I/O regions while we're working with them cadb86570c41fe52a0ea741f1f9775e3412f0167 hwmon: f71882fg: use a muxed resource lock for the Super I/O port 96cb4eb019ce3185ec0d946a74b5a2202f5067c9 watchdog: f71808e_wdt: new watchdog driver for Fintek F71808E and F71882FG That's the set of patches I've been using. Awesome. Thanks. It appears I was wrong. There's one small patch missing to get support for the F71889FG watchdog: dee00abbbcab97b8ee3bbafb5e786dde83e26741 watchdog: f71808e_wdt: add support for the F71889FG Interestingly, trying to load the bundled f71808e_wdt doesn't print a error, which would be something about no device being found or something like that: # modprobe f71808e_wdt FATAL: Error inserting f71808e_wdt (/lib/modules/2.6.32-5-amd64/kernel/drivers/watchdog/f71808e_wdt.ko): Kernel does not have module support Please take whichever decision you want wrt this driver, considering the release schedule, I'd understand if that's wontfix for now. However, since I now don't need to rebuild the kernel for the shared I/O region support, fixing the lack of support for my chip is trivial on my end. Leaving the bug closed, as it was more about the shared I/O region support. Cheers, Mike -- 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/20101214162356.ga8...@glandium.org
Bug#601187: linux-image-2.6.32-5-amd64: Please apply patch for shared I/O region support
On Mon, Dec 06, 2010 at 04:25:13AM +, Ben Hutchings wrote: On Thu, 2010-12-02 at 13:39 +0100, Mike Hommey wrote: Is the following going to be considered for squeeze? I've cherry-picked all the necessary changes (I think): 8b6d043b7ee2d1b819dc833d677ea2aead71a0c0 resource: shared I/O region support 729d273aa7c86eb1406ade4eadf249cff188bf9a hwmon: (f71882fg) Acquire I/O regions while we're working with them cadb86570c41fe52a0ea741f1f9775e3412f0167 hwmon: f71882fg: use a muxed resource lock for the Super I/O port 96cb4eb019ce3185ec0d946a74b5a2202f5067c9 watchdog: f71808e_wdt: new watchdog driver for Fintek F71808E and F71882FG That's the set of patches I've been using. Awesome. Thanks. Please also note the patch makes the ABI check script barf, but there is technically no function signature change. The build-time ABI check is based on 'symbol versions', which are already used for a run-time ABI check. The 'genksyms' program generates symbol versions as a hash of the function signature (or object type) and all the structure definitions that the function/object may depend on. Thus, including a new header changes the symbol version. I've wrapped the inclusion with #ifndef __GENKSYMS__ so that this doesn't happen. Thanks for the explanation Cheers, Mike -- 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/20101206074414.ga3...@glandium.org
Re: Bug#605009: serious performance regression with ext4
On Mon, Nov 29, 2010 at 07:18:17AM +0100, Guillem Jover wrote: What's going on here? sync_file_range() is a Linux specific system call that has been around for a while. It allows program to control when writeback happens in a very low-level fashion. The first set of sync_file_range() system calls causes the system to start writing back each file once it has finished being extracted. It doesn't actually wait for the write to finish; it just starts the writeback. Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) instead, skimming over the kernel source seems to indicate it might end up doing more or less the same thing but in a portable way? On the other hand, there is no guarantee that other kernels do the same, nor that Linux will keep doing it in the future. Using sync_file_range and possibly the corresponding BSD syscall seems a better solution. (and apparently the assumption with fadvise doesn't work with xfs) Mike -- 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/20101130090755.ga8...@glandium.org
Re: Bug#605009: serious performance regression with ext4
On Tue, Nov 30, 2010 at 10:35:11AM +0100, Samuel Thibault wrote: Mike Hommey, le Tue 30 Nov 2010 10:07:55 +0100, a écrit : On Mon, Nov 29, 2010 at 07:18:17AM +0100, Guillem Jover wrote: What's going on here? sync_file_range() is a Linux specific system call that has been around for a while. It allows program to control when writeback happens in a very low-level fashion. The first set of sync_file_range() system calls causes the system to start writing back each file once it has finished being extracted. It doesn't actually wait for the write to finish; it just starts the writeback. Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) instead, skimming over the kernel source seems to indicate it might end up doing more or less the same thing but in a portable way? On the other hand, there is no guarantee that other kernels do the same, Err, that's posix. Being posix doesn't guarantee that posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) is going to start write back, which is the desired effect, but not what you may actually get, depending on the kernel. Mike -- 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/20101130103043.ga9...@glandium.org
Re: Pre-approval request for dpkg sync() changes for squeeze
On Sun, Nov 21, 2010 at 09:18:04AM +0100, Raphael Hertzog wrote: On Sun, 21 Nov 2010, Ben Hutchings wrote: I'm coming to this late. It sounds like dpkg has changed its behaviour several times recently. Please can you summarise dpkg's current and proposed use of fsync() vs sync(), and the reasons for this. Jonathan made a good summary of the history. I should add that dpkg uses sync() instead of fsync() only on systems where we know that sync() is synchronous (i.e. Linux only). Now we want to stop using sync() because of the bad side-effects: - using on a tmpfs is slower because it syncs changes on unrelated filesystems - there are those reports of dpkg blocked due to the sync see http://bugs.debian.org/595927 http://bugs.debian.org/600075 Also do I understand correctly that fsync() is more expensive when ext4 delayed allocation is in use? Apparently, at least for dpkg's usage pattern. But the performance are so much slower that you have been asked whether it would make sense to change the defaults on ext4 to include nodelalloc. Something that might be worth trying is using fallocate, which /might/ mitigate the delayed allocation effects. Mike -- 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/20101121100802.ga3...@glandium.org
Bug#600190: linux-image-2.6.32-5-amd64: btrfs filesystem df doesn't work because of missing ioctl
On Thu, Oct 14, 2010 at 03:26:08PM +0200, Mike Hommey wrote:
Package: linux-2.6
Version: 2.6.32-24
Severity: normal
The btrfs tool, which is the canonical tool for btrfs handling, doesn't
have a useful output for btrfs filesystem df because the necessay ioctl
isn't available in 2.6.32. Would you consider adding it?
1406e4327be3a533a2b18582f715ce2cfbcf6804 is the relevant commit id.
(7fde62bffb576d384ea49a3aed3403d5609ee5bc further modifies the ioctl
function to buffer the output)
I can confirm backporting 1406e4327be3a533a2b18582f715ce2cfbcf6804
(attached) makes btrfs filesystem df work.
Mike
commit 278068037d34d4c030bd812849f1a0ffae53e3dc
Author: Josef Bacik jo...@redhat.com
Date: Wed Jan 13 18:19:06 2010 +
Btrfs: add a df ioctl for btrfs
df is a very loaded question in btrfs. This gives us a way to get the
per-space
usage information so we can tell exactly what is in use where. This will
help
us figure out ENOSPC problems, and help users better understand where their
disk
space is going.
Signed-off-by: Josef Bacik jo...@redhat.com
Signed-off-by: Chris Mason chris.ma...@oracle.com
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index cdbb054..1e7a71d 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1270,6 +1270,49 @@ out:
return ret;
}
+long btrfs_ioctl_space_info(struct btrfs_root *root, void __user *arg)
+{
+ struct btrfs_ioctl_space_args space_args;
+ struct btrfs_ioctl_space_info space;
+ struct btrfs_ioctl_space_info *dest;
+ struct btrfs_space_info *info;
+ int ret = 0;
+
+ if (copy_from_user(space_args,
+ (struct btrfs_ioctl_space_args __user *)arg,
+ sizeof(space_args)))
+ return -EFAULT;
+
+ space_args.total_spaces = 0;
+ dest = (struct btrfs_ioctl_space_info *)
+ (arg + sizeof(struct btrfs_ioctl_space_args));
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(info, root-fs_info-space_info, list) {
+ if (!space_args.space_slots) {
+ space_args.total_spaces++;
+ continue;
+ }
+ if (space_args.total_spaces = space_args.space_slots)
+ break;
+ space.flags = info-flags;
+ space.total_bytes = info-total_bytes;
+ space.used_bytes = info-bytes_used;
+ if (copy_to_user(dest, space, sizeof(space))) {
+ ret = -EFAULT;
+ break;
+ }
+ dest++;
+ space_args.total_spaces++;
+ }
+ rcu_read_unlock();
+
+ if (copy_to_user(arg, space_args, sizeof(space_args)))
+ ret = -EFAULT;
+
+ return ret;
+}
+
/*
* there are many ways the trans_start and trans_end ioctls can lead
* to deadlocks. They should only be used by applications that
@@ -1334,6 +1377,8 @@ long btrfs_ioctl(struct file *file, unsigned int
return btrfs_ioctl_trans_start(file);
case BTRFS_IOC_TRANS_END:
return btrfs_ioctl_trans_end(file);
+ case BTRFS_IOC_SPACE_INFO:
+ return btrfs_ioctl_space_info(root, argp);
case BTRFS_IOC_SYNC:
btrfs_sync_fs(file-f_dentry-d_sb, 1);
return 0;
diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h
index bc49914..9893d02 100644
--- a/fs/btrfs/ioctl.h
+++ b/fs/btrfs/ioctl.h
@@ -36,6 +36,18 @@ struct btrfs_ioctl_clone_range_args {
__u64 dest_offset;
};
+struct btrfs_ioctl_space_info {
+ u64 flags;
+ u64 total_bytes;
+ u64 used_bytes;
+};
+
+struct btrfs_ioctl_space_args {
+ u64 space_slots;
+ u64 total_spaces;
+ struct btrfs_ioctl_space_info spaces[0];
+};
+
#define BTRFS_IOC_SNAP_CREATE _IOW(BTRFS_IOCTL_MAGIC, 1, \
struct btrfs_ioctl_vol_args)
#define BTRFS_IOC_DEFRAG _IOW(BTRFS_IOCTL_MAGIC, 2, \
@@ -67,4 +79,6 @@ struct btrfs_ioctl_clone_range_args {
struct btrfs_ioctl_vol_args)
#define BTRFS_IOC_SNAP_DESTROY _IOW(BTRFS_IOCTL_MAGIC, 15, \
struct btrfs_ioctl_vol_args)
+#define BTRFS_IOC_SPACE_INFO _IOWR(BTRFS_IOCTL_MAGIC, 20, \
+ struct btrfs_ioctl_space_args)
#endif
Bug#601187: linux-image-2.6.32-5-amd64: Please apply patch for shared I/O region support
Package: linux-2.6
Version: 2.6.32-26
Severity: wishlist
This is a followup from bug 597820. I would like to get the watchdog
support for f71889fg with a squeeze kernel. The support for that chip
isn't yet upstream, and I understand that you wouldn't want to include
it (yet). However, it would be much easier for me if I only had to rebuild
the module after each security release instead of the kernel, and this
means it would be nice if the squeeze kernel supported shared I/O region
for that module to be buildable and useable.
Please note that there are patches against hwmon/f71882fg.c in bug 597820
that would be better applied, too, but it's not that much a problem for me
to patch that module as well, though if someone builds the watchdog driver
without modifying the hwmon one, they will have troubles.
Please also note the patch makes the ABI check script barf, but there is
technically no function signature change.
Attached here is the backported patch (trivial context difference in the
header file).
Thanks
Mike
commit 85a6dce87df872e22fbcd4c0f7c66fafc16a531c
Author: Alan Cox a...@linux.intel.com
Date: Mon Mar 29 19:38:00 2010 +0200
resource: shared I/O region support
SuperIO devices share regions and use lock/unlock operations to chip
select. We therefore need to be able to request a resource and wait for
it to be freed by whichever other SuperIO device currently hogs it.
Right now you have to poll which is horrible.
Add a MUXED field to IO port resources. If the MUXED field is set on the
resource and on the request (via request_muxed_region) then we block
until the previous owner of the muxed resource releases their region.
This allows us to implement proper resource sharing and locking for
superio chips using code of the form
enable_my_superio_dev() {
request_muxed_region(0x44, 0x02, superio:watchdog);
outb() ..sequence to enable chip
}
disable_my_superio_dev() {
outb() .. sequence of disable chip
release_region(0x44, 0x02);
}
Signed-off-by: Giel van Schijndel m...@mortis.eu
Signed-off-by: Alan Cox a...@linux.intel.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 83aa812..140b00d 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -50,6 +50,7 @@ struct resource_list {
#define IORESOURCE_STARTALIGN 0x0004 /* start field is alignment */
#define IORESOURCE_MEM_64 0x0010
+#define IORESOURCE_MUXED 0x0040 /* Resource is software muxed */
#define IORESOURCE_EXCLUSIVE 0x0800 /* Userland may not map this
resource */
#define IORESOURCE_DISABLED0x1000
@@ -136,7 +137,8 @@ static inline unsigned long resource_type(struct resource
*res)
}
/* Convenience shorthand with allocation */
-#define request_region(start,n,name) __request_region(ioport_resource,
(start), (n), (name), 0)
+#define request_region(start,n,name)
__request_region(ioport_resource, (start), (n), (name), 0)
+#define request_muxed_region(start,n,name)
__request_region(ioport_resource, (start), (n), (name), IORESOURCE_MUXED)
#define __request_mem_region(start,n,name, excl)
__request_region(iomem_resource, (start), (n), (name), excl)
#define request_mem_region(start,n,name) __request_region(iomem_resource,
(start), (n), (name), 0)
#define request_mem_region_exclusive(start,n,name) \
diff --git a/kernel/resource.c b/kernel/resource.c
index fb11a58..a0db758 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -15,6 +15,7 @@
#include linux/spinlock.h
#include linux/fs.h
#include linux/proc_fs.h
+#include linux/sched.h
#include linux/seq_file.h
#include linux/device.h
#include linux/pfn.h
@@ -601,6 +602,8 @@ resource_size_t resource_alignment(struct resource *res)
* release_region releases a matching busy region.
*/
+static DECLARE_WAIT_QUEUE_HEAD(muxed_resource_wait);
+
/**
* __request_region - create a new busy resource region
* @parent: parent resource descriptor
@@ -613,6 +616,7 @@ struct resource * __request_region(struct resource *parent,
resource_size_t start, resource_size_t n,
const char *name, int flags)
{
+ DECLARE_WAITQUEUE(wait, current);
struct resource *res = kzalloc(sizeof(*res), GFP_KERNEL);
if (!res)
@@ -637,7 +641,15 @@ struct resource * __request_region(struct resource *parent,
if (!(conflict-flags IORESOURCE_BUSY))
continue;
}
-
+ if (conflict-flags flags IORESOURCE_MUXED) {
+ add_wait_queue(muxed_resource_wait, wait);
+ write_unlock(resource_lock);
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule();
+
Bug#597820: linux-image-2.6.32-5-amd64: 2.6.32 doesn't support the f71889fg sensor chip
On Mon, Oct 04, 2010 at 09:44:28AM +0200, Mike Hommey wrote: On Mon, Oct 04, 2010 at 09:29:20AM +0200, Mike Hommey wrote: Right, it seems that I forgot a single break-statement (causing the driver to fall through to the undetected part). Attached patch has this fixed and should work properly. I may have fucked up, but it looks like it doesn't work either. Same behaviour as before. :( I'm trying another build. I did fuck up, and it just works fine. I used watchdog-test and kill -STOP it, and the machine rebooted within a few seconds, as expected. Should I file a new bug for the watchdog support or will you just not apply these patches for squeeze? Thanks, Mike -- 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/20101014131542.ga10...@glandium.org
Bug#600190: linux-image-2.6.32-5-amd64: btrfs filesystem df doesn't work because of missing ioctl
Package: linux-2.6 Version: 2.6.32-24 Severity: normal The btrfs tool, which is the canonical tool for btrfs handling, doesn't have a useful output for btrfs filesystem df because the necessay ioctl isn't available in 2.6.32. Would you consider adding it? 1406e4327be3a533a2b18582f715ce2cfbcf6804 is the relevant commit id. (7fde62bffb576d384ea49a3aed3403d5609ee5bc further modifies the ioctl function to buffer the output) Thanks Mike -- 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/20101014132608.19461.38213.report...@jigen.glandium.org
Bug#597820: linux-image-2.6.32-5-amd64: 2.6.32 doesn't support the f71889fg sensor chip
On Sun, Oct 03, 2010 at 02:02:32PM +0200, Giel van Schijndel wrote: On Sun, Oct 03, 2010 at 09:14:44AM +0200, Mike Hommey wrote: On Sun, Oct 03, 2010 at 01:14:24AM +0200, Giel van Schijndel wrote: On Sat, Oct 02, 2010 at 08:42:19PM +0100, Ben Hutchings wrote: On Tue, 2010-09-28 at 10:36 +0200, Mike Hommey wrote: I would also be interested in the watchdog support for the same chip, That patch does *not* add watchdog support for the Fintek F71889FG chip, it *only* adds support for the F71808E and the F71882FG. Oops. Additionally a patch for the F71862FG is currently pending review and inclusion. That being said, this driver should be fairly easy to expand to include support for the F71889FG chip (AFAIK only pin-configuration should be added, which probably is just a datasheet-reading exercise). Adding support however would be something I'd suggest doing across the LKML *first*, then (optionally) backport it later. However, the last patch (729d273aa7c86eb1406ade4eadf249cff188bf9a) doesn't look right; surely it should be using the new request_muxed_region() macro too? IIRC that patch was submitted and applied *before* 8b6d043, hence request_muxed_region() wasn't available and thus not used. The patch to make use of request_muxed_region() [1] has been acked [2] but not yet applied yet, I've just sent out a poke-mail (CC-ed to this bug) with the request for it to be committed. [1] 1280669455-31283-1-git-send-email...@mortis.eu AFAICS, this id refers to the patch that ended in 96cb4eb019ce3185ec0d946a74b5a2202f5067c9. I can't find that commit in Torvald's tree. Who's the author and what's the first line of the commit message? commit 96cb4eb019ce3185ec0d946a74b5a2202f5067c9 Author: Giel van Schijndel m...@mortis.eu Date: Sun Aug 1 15:30:55 2010 +0200 watchdog: f71808e_wdt: new watchdog driver for Fintek F71808E and F71882FG In Linus' tree. $ git describe --contains 96cb4eb019ce3185ec0d946a74b5a2202f5067c9 v2.6.36-rc1~290^2~2 The one you are referring to must be http://marc.info/?l=lm-sensorsm=127219192018988w=2 Actually I'm referring to this patch (updated/rebased version of the one you're referring to): http://marc.info/?l=linux-kernelm=128066949410960w=2 PS marc.info allows direct searching on Message-ID like so: http://marc.info/?i=$message_id e.g.: http://marc.info/?i=1280669455-31283-1-git-send-email...@mortis.eu Interestingly, I found this with your message-id: https://patchwork.kernel.org/patch/116315/ Mike -- 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/20101004064033.ga4...@glandium.org
Bug#597820: linux-image-2.6.32-5-amd64: 2.6.32 doesn't support the f71889fg sensor chip
On Sun, Oct 03, 2010 at 02:47:11PM +0200, Giel van Schijndel wrote: On Sun, Oct 03, 2010 at 11:21:42AM +0200, Mike Hommey wrote: On Sun, Oct 03, 2010 at 01:33:23AM +0200, Giel van Schijndel wrote: On Sun, Oct 03, 2010 at 01:14:24AM +0200, Giel van Schijndel wrote: On Sat, Oct 02, 2010 at 08:42:19PM +0100, Ben Hutchings wrote: On Tue, 2010-09-28 at 10:36 +0200, Mike Hommey wrote: I would also be interested in the watchdog support for the same chip, That patch does *not* add watchdog support for the Fintek F71889FG chip, it *only* adds support for the F71808E and the F71882FG. Additionally a patch for the F71862FG is currently pending review and inclusion. That being said, this driver should be fairly easy to expand to include support for the F71889FG chip (AFAIK only pin-configuration should be added, which probably is just a datasheet-reading exercise). Adding support however would be something I'd suggest doing across the LKML *first*, then (optionally) backport it later. Heck I gave it a try and attached you'll find a patch to add F71889FG support to the current f71808e_wdt watchdog driver. The reason I haven't send this to the LKML before however, is that I don't have any system with that chip to test it, so please do test it and tell me the results. I gave a try to your patch, on top of the other ones. For the kernel team, please note that some of the patches don't apply cleanly on 2.6.32, because of some changes in context (mostly coding-style changes) that apparently happened between 2.6.32 and the various patches landing. I manually edited the patches to make them apply properly, please ping me if you want the modified versions. The configs also need to be modified to include CONFIG_F71808E_WDT=m. For the patches cherry-picking 729d273a, 8b6d043 and 96cb4eb (in that order) will do. 8b6d043 will probably cause a merge-conflict, just ditch IORESOURCE_WINDOW and you should be able to finish that cherry-pick. Exactly. I also had to edit the hwmon: f71882fg: use a muxed resource lock for the Super I/O port because of style changes. Still for the kernel team, applying the release_mutex_region patch makes the ABI check script barf with the following changes: __devm_release_regionmodule: vmlinux, version: 0x969a2a91 - 0x70191467, export: EXPORT_SYMBOL __devm_request_regionmodule: vmlinux, version: 0x51144912 - 0x9e7acb57, export: EXPORT_SYMBOL For Giel, it appears the watchdog driver doesn't entirely work: It loads fine: f71808e_wdt: Found f71889fg watchdog chip, revision 21 But watchdog-test (as from Documentation/watchdog/src/watchdog-test.c) doesn't work and outputs: Watchdog device not enabled. stracing it shows this: open(/dev/watchdog, O_WRONLY) = -1 ENODEV (No such device) Right, it seems that I forgot a single break-statement (causing the driver to fall through to the undetected part). Attached patch has this fixed and should work properly. I may have fucked up, but it looks like it doesn't work either. Same behaviour as before. :( I'm trying another build. Mike -- 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/20101004072920.ga5...@glandium.org
Bug#597820: linux-image-2.6.32-5-amd64: 2.6.32 doesn't support the f71889fg sensor chip
On Mon, Oct 04, 2010 at 09:29:20AM +0200, Mike Hommey wrote: Right, it seems that I forgot a single break-statement (causing the driver to fall through to the undetected part). Attached patch has this fixed and should work properly. I may have fucked up, but it looks like it doesn't work either. Same behaviour as before. :( I'm trying another build. I did fuck up, and it just works fine. I used watchdog-test and kill -STOP it, and the machine rebooted within a few seconds, as expected. Thanks Mike -- 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/20101004074428.ga5...@glandium.org
Bug#597820: linux-image-2.6.32-5-amd64: 2.6.32 doesn't support the f71889fg sensor chip
On Sun, Oct 03, 2010 at 01:14:24AM +0200, Giel van Schijndel wrote: On Sat, Oct 02, 2010 at 08:42:19PM +0100, Ben Hutchings wrote: On Tue, 2010-09-28 at 10:36 +0200, Mike Hommey wrote: On Thu, Sep 23, 2010 at 12:36:04PM +0200, Mike Hommey wrote: Package: linux-2.6 Version: 2.6.32-23 Severity: wishlist Tags: squeeze I installed a fresh squeeze on a new PC with a MSI P55M-GD45 motherboard that uses a f71889fg sensor chip. Unfortunately, while lm-sensors' sensor-detect is able to find the chip and suggest a kernel module, the module doesn't load because it lacks support for the chip. The support was added somewhen between 2.6.32 and 2.6.33, and was added by commit 7669896f. I hear that you add support for hardware when the backport is simple, this one is pretty trivial. For other reasons, I already switched to 2.6.35 on that machine, so it's not a problem for me anymore, but the motherboard is already quite old, so other people may have similar problems with a fresh squeeze. I would also be interested in the watchdog support for the same chip, That patch does *not* add watchdog support for the Fintek F71889FG chip, it *only* adds support for the F71808E and the F71882FG. Oops. Additionally a patch for the F71862FG is currently pending review and inclusion. That being said, this driver should be fairly easy to expand to include support for the F71889FG chip (AFAIK only pin-configuration should be added, which probably is just a datasheet-reading exercise). Adding support however would be something I'd suggest doing across the LKML *first*, then (optionally) backport it later. coming in 96cb4eb019ce3185ec0d946a74b5a2202f5067c9. AFAICT, it requires 8b6d043b7ee2d1b819dc833d677ea2aead71a0c0 and possibly 729d273aa7c86eb1406ade4eadf249cff188bf9a. I'm not sure how intrusive these could be considered. They seem a bit intrusive but probably safe. I would consider 729d273 to be safe. 8b6d043 is a bit more complex, though it should only affect I/O resources acquired with the newly introduced flag IORESOURCE_MUXED, it thus shouldn't affect pre-existing code. However, the last patch (729d273aa7c86eb1406ade4eadf249cff188bf9a) doesn't look right; surely it should be using the new request_muxed_region() macro too? IIRC that patch was submitted and applied *before* 8b6d043, hence request_muxed_region() wasn't available and thus not used. The patch to make use of request_muxed_region() [1] has been acked [2] but not yet applied yet, I've just sent out a poke-mail (CC-ed to this bug) with the request for it to be committed. [1] 1280669455-31283-1-git-send-email...@mortis.eu AFAICS, this id refers to the patch that ended in 96cb4eb019ce3185ec0d946a74b5a2202f5067c9. The one you are referring to must be http://marc.info/?l=lm-sensorsm=127219192018988w=2 I will give a try to your patch for the F71889FG watchdog, thanks. Mike -- 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/20101003071444.ga4...@glandium.org
Bug#597820: linux-image-2.6.32-5-amd64: 2.6.32 doesn't support the f71889fg sensor chip
On Sun, Oct 03, 2010 at 01:33:23AM +0200, Giel van Schijndel wrote: On Sun, Oct 03, 2010 at 01:14:24AM +0200, Giel van Schijndel wrote: On Sat, Oct 02, 2010 at 08:42:19PM +0100, Ben Hutchings wrote: On Tue, 2010-09-28 at 10:36 +0200, Mike Hommey wrote: I would also be interested in the watchdog support for the same chip, That patch does *not* add watchdog support for the Fintek F71889FG chip, it *only* adds support for the F71808E and the F71882FG. Additionally a patch for the F71862FG is currently pending review and inclusion. That being said, this driver should be fairly easy to expand to include support for the F71889FG chip (AFAIK only pin-configuration should be added, which probably is just a datasheet-reading exercise). Adding support however would be something I'd suggest doing across the LKML *first*, then (optionally) backport it later. Heck I gave it a try and attached you'll find a patch to add F71889FG support to the current f71808e_wdt watchdog driver. The reason I haven't send this to the LKML before however, is that I don't have any system with that chip to test it, so please do test it and tell me the results. I gave a try to your patch, on top of the other ones. For the kernel team, please note that some of the patches don't apply cleanly on 2.6.32, because of some changes in context (mostly coding-style changes) that apparently happened between 2.6.32 and the various patches landing. I manually edited the patches to make them apply properly, please ping me if you want the modified versions. The configs also need to be modified to include CONFIG_F71808E_WDT=m. Still for the kernel team, applying the release_mutex_region patch makes the ABI check script barf with the following changes: __devm_release_regionmodule: vmlinux, version: 0x969a2a91 - 0x70191467, export: EXPORT_SYMBOL __devm_request_regionmodule: vmlinux, version: 0x51144912 - 0x9e7acb57, export: EXPORT_SYMBOL For Giel, it appears the watchdog driver doesn't entirely work: It loads fine: f71808e_wdt: Found f71889fg watchdog chip, revision 21 But watchdog-test (as from Documentation/watchdog/src/watchdog-test.c) doesn't work and outputs: Watchdog device not enabled. stracing it shows this: open(/dev/watchdog, O_WRONLY) = -1 ENODEV (No such device) Please tell me if you need more feedback. Thanks, Mike -- 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/20101003092142.ga6...@glandium.org
Bug#597820: linux-image-2.6.32-5-amd64: 2.6.32 doesn't support the f71889fg sensor chip
On Thu, Sep 23, 2010 at 12:36:04PM +0200, Mike Hommey wrote: Package: linux-2.6 Version: 2.6.32-23 Severity: wishlist Tags: squeeze I installed a fresh squeeze on a new PC with a MSI P55M-GD45 motherboard that uses a f71889fg sensor chip. Unfortunately, while lm-sensors' sensor-detect is able to find the chip and suggest a kernel module, the module doesn't load because it lacks support for the chip. The support was added somewhen between 2.6.32 and 2.6.33, and was added by commit 7669896f. I hear that you add support for hardware when the backport is simple, this one is pretty trivial. For other reasons, I already switched to 2.6.35 on that machine, so it's not a problem for me anymore, but the motherboard is already quite old, so other people may have similar problems with a fresh squeeze. I would also be interested in the watchdog support for the same chip, coming in 96cb4eb019ce3185ec0d946a74b5a2202f5067c9. AFAICT, it requires 8b6d043b7ee2d1b819dc833d677ea2aead71a0c0 and possibly 729d273aa7c86eb1406ade4eadf249cff188bf9a. I'm not sure how intrusive these could be considered. Mike -- 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/20100928083618.ga23...@glandium.org
Bug#597820: linux-image-2.6.32-5-amd64: 2.6.32 doesn't support the f71889fg sensor chip
Package: linux-2.6 Version: 2.6.32-23 Severity: wishlist Tags: squeeze I installed a fresh squeeze on a new PC with a MSI P55M-GD45 motherboard that uses a f71889fg sensor chip. Unfortunately, while lm-sensors' sensor-detect is able to find the chip and suggest a kernel module, the module doesn't load because it lacks support for the chip. The support was added somewhen between 2.6.32 and 2.6.33, and was added by commit 7669896f. I hear that you add support for hardware when the backport is simple, this one is pretty trivial. For other reasons, I already switched to 2.6.35 on that machine, so it's not a problem for me anymore, but the motherboard is already quite old, so other people may have similar problems with a fresh squeeze. Cheers, Mike -- 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/20100923103604.24446.69703.report...@jigen.glandium.org
Bug#558237: linux-source-2.6.32: X with xserver-xorg-video-intel does not work any longer
On Tue, Dec 08, 2009 at 08:55:34AM +0100, Reinhard Karcher wrote: Status update for kernel-image-2.6.32-trunk-amd64: things improved a little bit. Console switching is now possible, but in X only a black screen is visible, with the exception of the mouse cursor, which is visible and moves as it should. The following message vanished from Xorg.0.log with the new kernel: Fatal server error: Failed to map 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. The messages in the calling VT are the same: ../../../libdrm/intel/intel_bufmgr_gem.c:825: Error setting to CPU domain 96: Input/output error ../../../libdrm/intel/intel_bufmgr_gem.c:899: Error setting domain 773: Input/output error I have a similar problem, except i don't have any error message on VT or logs. The mouse cursor is static when it should be animated, and most of the screen is not updated. Some parts may end up being filled up some times. I wonder if it's related to http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8082400327d8d2ca54254b593644942bed0edd25 I kind of remember a similar problem some time ago that may have been related to something similar (if my memory is correct, obviously) Mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#416063: tagging 416063
On Mon, Mar 30, 2009 at 01:11:52AM +0200, maximilian attems wrote:
On Sat, 28 Mar 2009, Mike Hommey wrote:
On Wed, Mar 28, 2007 at 12:19:49AM +0200, maximilian attems wrote:
# Automatically generated email from bts, devscripts version 2.9.26
tags 416063 - patch
Would you mind explaining?
The patch solves two issues:
- inconsistency between documentation and behaviour:
You can read the following in /etc/initramfs-tools/initramfs.conf:
# most - Add all framebuffer, acpi, filesystem, and harddrive drivers.
As it happens, most does *not* add all framebuffer drivers
yeah none at all, fixed in latest git.
the patch was not ok as we don't want to have another hardcoded list
to maintain, just added all the fb modules on one go, see
f40e826287d2776094f48302c196652f2ba8326b
hook-functions: MODULES=most add all fb modules per default
http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary
- workaround the lack of dependency on intel_agp for intelfb.
Without the workaround, you can't have intel_agp loaded before
intelfb without *not* using video=intelfb syntax, thus losing
/dev/fb device creation.
that looks more like a kernel bug,
also intelfb should just work fine if not on agp.
or are you saying there are missing symbols there?
This is what happens in intelfb_pci_register, unconditionally:
/* Use agpgart to manage the GATT */
if (!(bridge = agp_backend_acquire(pdev))) {
ERR_MSG(cannot acquire agp\n);
cleanup(dinfo);
return -ENODEV;
}
Mike
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#416063: tagging 416063
On Wed, Mar 28, 2007 at 12:19:49AM +0200, maximilian attems wrote: # Automatically generated email from bts, devscripts version 2.9.26 tags 416063 - patch Would you mind explaining? The patch solves two issues: - inconsistency between documentation and behaviour: You can read the following in /etc/initramfs-tools/initramfs.conf: # most - Add all framebuffer, acpi, filesystem, and harddrive drivers. As it happens, most does *not* add all framebuffer drivers - workaround the lack of dependency on intel_agp for intelfb. Without the workaround, you can't have intel_agp loaded before intelfb without *not* using video=intelfb syntax, thus losing /dev/fb device creation. Please consider applying the patch. Cheers, Mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: firmware-nonfree : ipw2200 ?
On Fri, Oct 24, 2008 at 01:15:10AM +0200, Frank Lin PIAT wrote: Hello, [CC'ing since someone may have the answer] I have just tested Lenny on a laptop[1] with an Intel Pro Wireless 2200 chipset. As you probably known the kernel module ipw2200 requires a non-free firmware. I'm wondering why it hasn't been packaged yet (since that card was fairly common). The license question was brought to debian-legal[1] and it seems there was no barrier. Of course, the boring part is that 1. It's non-free and 2. We must prompt the user to approve the license. - Do you know why the firmware was never shipped in Debian? Because its license, contrary to other intel wireless firmware license forbids redistributing. Which means we can't even distribute it in non-free. - If I provide a patch, do you think if have a chance to be in Lenny? Except if the license changed, no chance. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464387: BUG: soft lockup - CPU#0 stuck for 11s! [swapper:0]
On Wed, Feb 06, 2008 at 03:37:05PM +, Sam Morris wrote: Package: linux-image-2.6.24-1-686 Version: 2.6.24-2 Severity: important Since upgrading to 2.6.24, my laptop keeps locking up for short periods of time. I have noticed that the following kernel messages are logged about 30 times when this happens. Feb 6 15:31:45 tycho kernel: BUG: soft lockup - CPU#0 stuck for 11s! [swapper:0] FWIW, I had this bug on amd64, and have not experienced it since I've upgraded to 2.6.25-rc8 (from debian kernel repository), though I've hit patterns that were triggering this before a few times since I upgraded. Seems like upstream claim that this is fixed in 2.6.25 is true. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please add following hint to block linux-2.6 until Beta1 is out
On Thu, Feb 14, 2008 at 05:17:08PM -0200, Otavio Salvador wrote: Mike Hommey [EMAIL PROTECTED] writes: On Thu, Feb 14, 2008 at 07:56:55PM +0100, maximilian attems wrote: On Thu, 14 Feb 2008, Otavio Salvador wrote: Hello RM and SRM teams, I hereby ask for a block on linux-2.6 source package until d-i Beta1 gets out. If it migrates before we do the final images we can need to delay d-i release. nacked as maintainer, you are blocking for more then 2 weeks linux-2.6 migration to testing. we need massife testing of 2.6.24 for etch+half, sid is not enough. also 2.6.22 was meant to be ready 4 month ago, sorry but that schedule is over. As discussed[1] previously at debian-boot we've decided to stay at 2.6.22 for this release and do a release as fast as possible with 2.6.24. 1. http://lists.debian.org/debian-boot/2008/02/msg00012.html very bad decision 2.6.24 is needed for a lot of recent hardware, d-i doesn't install on those. ... and etch+1 2.6.24 should just be built with the proper options to still include deprecated /proc/acpi stuff (and probably disable the new interfaces for them, too, as it can have bad side effects on, e.g. hal (though I don't know if etch's hal supports /sys/class/power_supply)). This needs to be done, specially for Etch+Half kernels. It has been done for sid kernels in 2.6.24-3 upload. Though 2.6.24-3 onwards also includes the /sys/class/power_supply stuff, and unless hal gets fixed (and it is fixed in upstream git), a few software will report twice as much batteries as really present. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366175: /usr/sbin/mkinitramfs: Same situation here
Package: initramfs-tools Followup-For: Bug #366175 I got the same issue here. Why not solve the problem by adding calls to lvm initialization in the Waiting for root filesystem loop ? A workaround is to add break=mount to the kernel command line, wait for the usb disk to come up and just exit, which will continue the boot sequence properly. Mike -- Package-specific info: -- /proc/cmdline root=/dev/mapper/namakemono-root ro nolapic break=mount resume=/dev/mapper/namakemono-swap -- /proc/filesystems ext3 fuseblk ext2 -- lsmod Module Size Used by arc42048 2 ecb 3584 2 blkcipher 6340 1 ecb ieee80211_crypt_wep 5120 1 radeon112512 2 drm75668 3 radeon rfcomm 36344 0 l2cap 22496 5 rfcomm ext2 60104 2 fuse 41876 1 dm_crypt 12840 0 cpufreq_ondemand8332 1 speedstep_centrino 7136 0 freq_table 4544 2 cpufreq_ondemand,speedstep_centrino sonypi 21144 0 snd_intel8x0 32092 1 pcmcia 37388 0 snd_intel8x0m 16908 0 snd_ac97_codec 92388 2 snd_intel8x0,snd_intel8x0m ac97_bus2336 1 snd_ac97_codec snd_pcm_oss39104 0 tifm_sd10856 0 snd_mixer_oss 15296 1 snd_pcm_oss joydev 9792 0 ipw2200 138344 0 mmc_core 27620 1 tifm_sd ieee80211 31656 1 ipw2200 ieee80211_crypt 5920 2 ieee80211_crypt_wep,ieee80211 firmware_class 9472 2 pcmcia,ipw2200 yenta_socket 24908 1 rsrc_nonstatic 11904 1 yenta_socket battery12296 0 tsdev 8160 0 snd_pcm72132 4 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss tifm_7xx1 7424 0 tifm_core 10212 2 tifm_sd,tifm_7xx1 pcmcia_core37140 3 pcmcia,yenta_socket,rsrc_nonstatic ac 5636 0 snd_timer 21188 1 snd_pcm sony_laptop27840 0 button 8336 0 snd48388 9 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer iTCO_wdt 11172 0 intel_agp 23348 1 agpgart31624 2 drm,intel_agp soundcore 7584 1 snd snd_page_alloc 10088 3 snd_intel8x0,snd_intel8x0m,snd_pcm hci_usb14876 0 bluetooth 50436 5 rfcomm,l2cap,hci_usb i2c_i8019264 0 psmouse36368 0 i2c_core 23264 1 i2c_i801 serio_raw 6724 0 evdev 9472 5 rtc12984 0 ext3 121544 5 jbd55368 1 ext3 mbcache 8320 2 ext2,ext3 dm_mirror 21632 0 dm_snapshot16932 0 dm_mod 52640 18 dm_crypt,dm_mirror,dm_snapshot sd_mod 27424 3 ide_disk 16544 0 generic 4804 0 [permanent] usb_storage77120 2 piix8932 0 [permanent] ide_core 112484 4 ide_disk,generic,usb_storage,piix ata_generic 7588 0 firewire_ohci 16640 0 e100 33612 0 mii 5344 1 e100 ehci_hcd 31372 0 firewire_core 39072 1 firewire_ohci crc_itu_t 2208 1 firewire_core libata113968 1 ata_generic scsi_mod 136300 3 sd_mod,usb_storage,libata uhci_hcd 23056 0 usbcore 130568 5 hci_usb,usb_storage,ehci_hcd,uhci_hcd thermal15580 0 processor 34696 1 thermal fan 5092 0 -- /etc/kernel-img.conf do_symlinks = no relative_links = yes do_bootfloppy = no do_initrd = yes link_in_boot = no postinst_hook = /usr/sbin/update-grub postrm_hook = /usr/sbin/update-grub do_bootloader = no -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=y KEYMAP=n BOOT=local DEVICE=eth0 NFSROOT=auto -- /etc/crypttab # target name source device key file options #cswap /dev/hda4 none swap,precheck=swap #safe /home/mh/safe none luks -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages initramfs-tools depends on: ii cpio 2.9-6 GNU cpio -- a program to manage ar ii klibc-utils 1.5.7-4 small statically-linked utilities ii module-init-tools3.3-pre11-4 tools for managing Linux kernel mo ii udev
Bug#366175: /usr/sbin/mkinitramfs: Same situation here
On Sun, Dec 16, 2007 at 04:00:50PM +0100, maximilian attems wrote: On Sun, 16 Dec 2007, Mike Hommey wrote: I got the same issue here. Why not solve the problem by adding calls to lvm initialization in the Waiting for root filesystem loop ? A workaround is to add break=mount to the kernel command line, wait for the usb disk to come up and just exit, which will continue the boot the recommended workaround is to use the bootparam rootdelay=XX The problem with rootdelay is that even when you find a delay that works well enough, it can happen that the usb devices take longer than this delay *sometimes* Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418442: linux-2.6: please enable CONFIG_BLK_DEV_IO_TRACE
On Mon, Apr 09, 2007 at 08:43:00PM +0200, Bas Zoetekouw [EMAIL PROTECTED] wrote: Package: linux-2.6 Severity: wishlist Could you please enable CONFIG_BLK_DEV_IO_TRACE in the default debian kernel? It's needed for blktrace, which I'm planning to upload to unstable soonish, now that the freeze is over. It would be great if we could get it to work out of the box, without the user needing to build his own kernel. I concur, please enable CONFIG_BLK_DEV_IO_TRACE. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423694: linux-image-2.6.21-1-686: Enable CONFIG_TIMER_STATS
Package: linux-image-2.6.21-1-686 Version: 2.6.21-1~experimental.1~snapshot.8516 Severity: wishlist Please enable CONFIG_TIMER_STATS in 2.6.21 kernel packages, so that powertop can display useful information to help users and developers to tackle applications preventing more idle time. See http://www.linuxpowertop.org/ for information about powertop and why CONFIG_TIMER_STATS can be useful. Mike -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.21-1-686 depends on: ii initramfs-tools [linux-initra 0.87b tools for generating an initramfs ii module-init-tools 3.3-pre4-2 tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.12-20 Yet Another mkInitRD Versions of packages linux-image-2.6.21-1-686 recommends: pn libc6-i686none (no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395086: closed by maximilian attems [EMAIL PROTECTED] (Re: Bug#395086: linux-image-2.6.18-1-686: disable suspend to disk on install)
reopen 395086 merge 395086 395089 thanks From: maximilian attems [EMAIL PROTECTED] Subject: Re: Bug#395086: linux-image-2.6.18-1-686: disable suspend to disk on install To: [EMAIL PROTECTED] Date: Tue, 24 Oct 2006 23:33:51 +0200 User-Agent: Mutt/1.5.9i Message-ID: [EMAIL PROTECTED] On Tue, Oct 24, 2006 at 08:41:38PM +0200, Mike Hommey wrote: When installing a new kernel over the currently running one, and suspend to disk is enabled, the system will fail to resume with the newer kernel at resuming time. It would be safer if it was impossible to suspend to disk then. I guess setting some value to /sys/power/resume would do the trick. this an userspace problem. And ? The kernel package has a check to warn the user he is installing the same kernel as the currently running one. It could disable suspend to disk at the same time. This *is* a kernel package problem. More generally, I think there is something wrong with Linux doing suspend to disk in S5 instead of S4. It has great advantages, such as being able to suspend to disk an OS and booting another one, but it very risky when you use filesystems opened by the suspended OS with another one. Another issue is that you have to resume with the exact same kernel that suspended, which is the reason of this bug, but is also a problem for people having more than one kernel installed... Interaction with the bootloader may be something to be worked on... feel free to submit a bug upstream or discuss that on lkml. that is definetly not a debian specific bug. so closing for now. Are you closing every non-debian-specific bugs ? do you know there is an upstream tag for non-debian-specific bugs ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395086: closed by maximilian attems [EMAIL PROTECTED] (Re: Bug#395086: linux-image-2.6.18-1-686: disable suspend to disk on install)
On Wed, Oct 25, 2006 at 09:39:13AM +0200, maximilian attems [EMAIL PROTECTED] wrote: reassign 395086 kernel-package retitle 395086 disable swsusp on new linux-image install stop On Wed, Oct 25, 2006 at 08:36:38AM +0200, Mike Hommey wrote: On Tue, Oct 24, 2006 at 08:41:38PM +0200, Mike Hommey wrote: When installing a new kernel over the currently running one, and suspend to disk is enabled, the system will fail to resume with the newer kernel at resuming time. It would be safer if it was impossible to suspend to disk then. I guess setting some value to /sys/power/resume would do the trick. this an userspace problem. And ? The kernel package has a check to warn the user he is installing the same kernel as the currently running one. It could disable suspend to disk at the same time. This *is* a kernel package problem. kernel-package != linux-image I'm happy to learn the linux-image packages are now built with kernel-package, which everyone should know, apparently, considering the way you answered originally. Could you try to be helpful instead of trying to get rid of bugs ? Are you closing every non-debian-specific bugs ? do you know there is an upstream tag for non-debian-specific bugs ? no need to cluter the debian bts with useless bugs hanging around, reassigned your bug report. I'm happy to learn that bugs that may help users are useless. By the way, the issue I was talking about is more about some black magic between lilo/grub, the kernel, and distro-specific scripts, than something that need to be discussed on lkml. But you're maybe just trying to get rid of bugs by any means Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395086: linux-image-2.6.18-1-686: disable suspend to disk on install
Package: linux-image-2.6.18-1-686 Version: 2.6.18-3 Severity: wishlist When installing a new kernel over the currently running one, and suspend to disk is enabled, the system will fail to resume with the newer kernel at resuming time. It would be safer if it was impossible to suspend to disk then. I guess setting some value to /sys/power/resume would do the trick. More generally, I think there is something wrong with Linux doing suspend to disk in S5 instead of S4. It has great advantages, such as being able to suspend to disk an OS and booting another one, but it very risky when you use filesystems opened by the suspended OS with another one. Another issue is that you have to resume with the exact same kernel that suspended, which is the reason of this bug, but is also a problem for people having more than one kernel installed... Interaction with the bootloader may be something to be worked on... -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.18-1-686 depends on: ii initramfs-tools [linux-initra 0.84 tools for generating an initramfs ii module-init-tools 3.2.2-3tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.12-18 Yet Another mkInitRD Versions of packages linux-image-2.6.18-1-686 recommends: ii libc6-i686 2.3.6.ds1-7 GNU C Library: Shared libraries [i -- debconf information: linux-image-2.6.18-1-686/postinst/bootloader-error-2.6.18-1-686: shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-1-686/postinst/depmod-error-initrd-2.6.18-1-686: false linux-image-2.6.18-1-686/postinst/create-kimage-link-2.6.18-1-686: true linux-image-2.6.18-1-686/preinst/initrd-2.6.18-1-686: linux-image-2.6.18-1-686/preinst/abort-overwrite-2.6.18-1-686: linux-image-2.6.18-1-686/preinst/elilo-initrd-2.6.18-1-686: true linux-image-2.6.18-1-686/postinst/old-initrd-link-2.6.18-1-686: true * linux-image-2.6.18-1-686/preinst/already-running-this-2.6.18-1-686: linux-image-2.6.18-1-686/preinst/lilo-has-ramdisk: linux-image-2.6.18-1-686/postinst/bootloader-test-error-2.6.18-1-686: linux-image-2.6.18-1-686/postinst/depmod-error-2.6.18-1-686: false linux-image-2.6.18-1-686/postinst/old-dir-initrd-link-2.6.18-1-686: true linux-image-2.6.18-1-686/preinst/overwriting-modules-2.6.18-1-686: true linux-image-2.6.18-1-686/preinst/failed-to-move-modules-2.6.18-1-686: linux-image-2.6.18-1-686/preinst/lilo-initrd-2.6.18-1-686: true linux-image-2.6.18-1-686/prerm/removing-running-kernel-2.6.18-1-686: true linux-image-2.6.18-1-686/postinst/old-system-map-link-2.6.18-1-686: true linux-image-2.6.18-1-686/prerm/would-invalidate-boot-loader-2.6.18-1-686: true linux-image-2.6.18-1-686/preinst/bootloader-initrd-2.6.18-1-686: true linux-image-2.6.18-1-686/preinst/abort-install-2.6.18-1-686: linux-image-2.6.18-1-686/postinst/kimage-is-a-directory: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366226: closed by Roland Stigge [EMAIL PROTECTED] (linux-image-2.6.16-1-xen-686: /boot/config-2.6.16-1-xen-686 not shipped)
Version: 2.6.18-2 This is fixed in 2.6.18-2. Therefore closing now. Is 2.6.18-2+ kernels intended to be released with etch ? If not, this bug should be reopened to be fixed in the kernel package that will be shipped. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Tue, Aug 08, 2006 at 06:49:32AM +0200, Sven Luther [EMAIL PROTECTED] wrote: On Mon, Aug 07, 2006 at 04:46:09PM -0700, Thomas Bushnell BSG wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. Now think about why we do not do it. It does not matter. Different members of Debian have different reasons. We have all agreed to work together on the basis of the Social Contract, which says that We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. # Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system. Where do you read we allow ourselves to distribute non-free software for user convenience ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366226: linux-image-2.6.16-1-xen-686: /boot/config-2.6.16-1-xen-686 not shipped
Package: linux-image-2.6.16-1-xen-686 Severity: normal As said in the subject, the /boot/config-2.6.16-1-xen-686 file is not shipped in the package. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge upgrade - linux, grub conflict
On Mon, Apr 17, 2006 at 12:29:04AM +0200, Bastian Blank [EMAIL PROTECTED] wrote: Hi folks For sarge updates of the linux kernels, grub needs to be updated before linux-image*. Can this be forced by an conflict with older versions? A dependency is not appropriate. Why does grub have to be updated before linux-image* ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Firefox logo (Was: Re: making udev require 2.6.15 kernels)
On Sat, Feb 11, 2006 at 10:33:32AM +0100, Marco d'Itri [EMAIL PROTECTED] wrote: I also plan a GR to accept in main less free artwork which if removed does not change the functionality of the software using it (e.g. the firefox logo). The main problem with the firefox logo is not its non-freeness, but the trademarks infringment associated with its use. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291354: kernel-image-2.6.10-1-686: Clock is running too fast under Suspend to RAM.
Package: kernel-image-2.6.10-1-686 Version: 2.6.10-4 Severity: normal Preliminary note: this didn't happen with 2.6.9. When suspending to RAM for a quite long time (like, the whole night), at wake up time, the clock is far ahead. It seems to be running twice as fast, actually, because it was 10 hours ahead this morning, after roughly 10 hours of suspend to RAM... -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages kernel-image-2.6.10-1-686 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii initrd-tools 0.1.76 tools to create initrd image for p ii module-init-tools 3.1-rel-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]
Re: Simultaneous loading of e100 and eepro100 by hotplug
On Thu, Dec 02, 2004 at 08:33:32AM +1100, Brian May [EMAIL PROTECTED] wrote: Mike == Mike Hommey [EMAIL PROTECTED] writes: Mike On Wed, Dec 01, 2004 at 01:33:32PM +0100, Marco d'Itri Mike [EMAIL PROTECTED] wrote: This is not a problem (/etc/hotplug/blacklist.d/kernel-image-n.n.n-m). Mike Actually, it can be. Let's imagine the absurd case where Mike kernel-image-x blacklists eepro100 and kernel-image-y Mike blacklists e100, we have a system with no intel ethernet pro Mike 100 support. That won't happen for this particular module Mike set, but i'm pretty sure such case could happen some day. Shouldn't it depend on what kernel is booted rather then what kernels are installed? That's what i was implying. It *should*. The thing is that it's not the way hotplug works. Mike
Re: Simultaneous loading of e100 and eepro100 by hotplug
On Wed, Dec 01, 2004 at 06:48:35PM +0900, Horms [EMAIL PROTECTED] wrote: If the blacklist exists for other devices, then yes this sounds like a good idea. The e100 should be used over the eepro100 as the later is in the process of being debricated upstream. The problem is the following: is the e100 driver available in all kernel flavours/versions ? If yes, then it is safe to blacklist it in hotplug directly. If not, then it is not safe to do it in hotplug because it would blacklist eepro100 which would be the only working module on some flavours/versions. But then, we have 2 other problems. First, how to cleanly handle the fact that several kernel packages want to set the blacklist ? But that issue can be solved, it's not really a problem. Second, let's say we have kernel x and kernel y installed on the host, and x doesn't have e100, while y has it. The kernel package y blacklists eepro100, well then, we have the problem that we can't boot on kernel x and have eepro100 loaded... Mike
