Bug#671034: [ia64] linux fails to load INIT (Still affects 3.2.19-1)
On Wed, Jun 27, 2012 at 12:46 PM, Thibaut VARENE vare...@debian.org wrote: On Wed, Jun 27, 2012 at 7:11 AM, Jonathan Nieder jrnie...@gmail.com wrote: Thibaut VARENE wrote: Sadly I don't have testing points between Squeeze's kernel (which works) and the first kernel with which I reported the issue... For concreteness: do you mean that 2.6.32-45 works or some earlier kernel that was in squeeze? I have 2.6.32-31 running on a similar machine. I'll see about 2.6.32-45 and will report back. 2.6.32-45 works HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- 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/CA+DQjFgew77M55Gxp5yzXLPCufiKAbLWvOGpAPNmxGP=nyd...@mail.gmail.com
Bug#671034: [ia64] linux fails to load INIT (Still affects 3.2.19-1)
On Wed, Jun 27, 2012 at 7:11 AM, Jonathan Nieder jrnie...@gmail.com wrote: Thibaut VARENE wrote: Sadly I don't have testing points between Squeeze's kernel (which works) and the first kernel with which I reported the issue... For concreteness: do you mean that 2.6.32-45 works or some earlier kernel that was in squeeze? I have 2.6.32-31 running on a similar machine. I'll see about 2.6.32-45 and will report back. If you suddenly find yourself with a lot of time and no idea what to do with it, there are pre-compiled kernels in between (e.g., 2.6.35) available from http://snapshot.debian.org/. I don't think anyone on ia64 was tracking experimental, so there's not much reason to believe in the quality of those kernels, but it would be interesting to see roughly when the bug was introduced. Though the symptoms are different, I wonder how much of this bug related to #595502. I hope not much. :) Thanks, Jonathan -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- 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/CA+DQjFgOe2tnjR-6yzxyvh5T=wcrck2ra9ajohc8zjrft2v...@mail.gmail.com
Bug#671034: Still affects 3.2.19-1
Package: linux-image-3.2.0-2-mckinley Version: 3.2.19-1 -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- 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/ca+dqjfjyyrh1pmivzim6oml7qjqj-vwg+0edux8q4u9fqwb...@mail.gmail.com
Bug#671034: [ia64] linux fails to load INIT (Still affects 3.2.19-1)
On Wed, Jun 27, 2012 at 1:51 AM, Jonathan Nieder jrnie...@gmail.com wrote: severity 671034 important quit Hi Thibaut, Thibaut VARENE wrote: [Subject: Bug#671034: Still affects 3.2.19-1] Please keep in mind that these appear as emails in a crowded inbox, so the subject line can be a good place to put valuable context. Version: 3.2.19-1 Thanks for the update. Was this a regression? What is the last kernel that worked? Sadly I don't have testing points between Squeeze's kernel (which works) and the first kernel with which I reported the issue... Though the symptoms are different, I wonder how much of this bug related to #595502. Note that the latter didn't affect this particular hardware... HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- 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/ca+dqjfhgygisdce-mn47owq213caynnombl1ov9ckemcdsr...@mail.gmail.com
Bug#671034: linux-image-3.2.0-2-mckinley: fails to load INIT
Package: linux-2.6 Version: 3.2.16-1 Severity: normal Stops short of loading INIT: Loading.: Debian GNU/Linux Starting: Debian GNU/Linux ELILO v3.12 for EFI/IA-64 .. Uncompressing Linux... done Loading file \EFI\debian\initrd.img...done [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.2.0-2-mckinley (Debian 3.2.16-1) (debian-kernel@lists.debian.org) (gcc version 4.6.2 (Debian 4.6.2-12) ) #1 SMP Mon Apr 30 08:32:39 UTC 2012 [0.00] EFI v1.10 by HP: SALsystab=0x3fb38000 ACPI 2.0=0x3fb2e000 SMBIOS=0x3fb3a000 HCDP=0x3fb2c000 [0.00] booting generic kernel on platform hpzx1 [0.00] PCDP: v0 at 0x3fb2c000 [0.00] Early serial console at MMIO 0xf805 (options '9600n8') [0.00] bootconsole [uart8250] enabled [0.00] ACPI: RSDP 3fb2e000 00028 (v02 HP) [0.00] ACPI: XSDT 3fb2e02c 0009C (v01 HP rx2600 HP ) [0.00] ACPI: FACP 3fb369e0 000F4 (v03 HP rx2600 HP ) [0.00] ACPI Warning: 32/64X length mismatch in Gpe0Block: 32/16 (20110623/tbfadt-529) [0.00] ACPI Warning: 32/64X length mismatch in Gpe1Block: 32/16 (20110623/tbfadt-529) [0.00] ACPI: DSDT 3fb2e0e0 05781 (v01 HP rx2600 0007 INTL 02012044) [0.00] ACPI: FACS 3fb36ad8 00040 [0.00] ACPI: SPCR 3fb36b18 00050 (v01 HP rx2600 HP ) [0.00] ACPI: DBGP 3fb36b68 00034 (v01 HP rx2600 HP ) [0.00] ACPI: APIC 3fb36c28 000C0 (v01 HP rx2600 HP ) [0.00] ACPI: SPMI 3fb36ba0 00050 (v04 HP rx2600 HP ) [0.00] ACPI: CPEP 3fb36bf0 00034 (v01 HP rx2600 HP ) [0.00] ACPI: SSDT 3fb33870 001D6 (v01 HP rx2600 0006 INTL 02012044) [0.00] ACPI: SSDT 3fb33a50 00342 (v01 HP rx2600 0006 INTL 02012044) [0.00] ACPI: SSDT 3fb33da0 00A16 (v01 HP rx2600 0006 INTL 02012044) [0.00] ACPI: SSDT 3fb347c0 00A16 (v01 HP rx2600 0006 INTL 02012044) [0.00] ACPI: SSDT 3fb351e0 00A16 (v01 HP rx2600 0006 INTL 02012044) [0.00] ACPI: SSDT 3fb35c00 00A16 (v01 HP rx2600 0006 INTL 02012044) [0.00] ACPI: SSDT 3fb36620 001D8 (v01 HP rx2600 0006 INTL 02012044) [0.00] ACPI: SSDT 3fb36800 000EB (v01 HP rx2600 0006 INTL 02012044) [0.00] ACPI: SSDT 3fb368f0 000EF (v01 HP rx2600 0006 INTL 02012044) [0.00] ACPI: Local APIC address c000fee0 [0.00] 2 CPUs available, 2 CPUs total [0.00] SMP: Allowing 2 CPUs, 0 hotplug CPUs [0.00] Initial ramdisk at: 0xe040fdea5000 (17744800 bytes) [0.00] SAL 3.1: HP version 2.31 [0.00] SAL Platform features: None [0.00] SAL: AP wakeup using external interrupt vector 0xff [0.00] MCA related initialization done [0.00] Virtual mem_map starts at 0xa0007fffc720 [0.00] Zone PFN ranges: [0.00] DMA 0x0400 - 0x0004 [0.00] Normal 0x0004 - 0x0104 [0.00] Movable zone start PFN for each node [0.00] early_node_map[6] active PFN ranges [0.00] 0: 0x0400 - 0xfd79 [0.00] 0: 0xfec0 - 0xfecb [0.00] 0: 0x0004 - 0x0006 [0.00] 0: 0x0101 - 0x0103ff3a [0.00] 0: 0x0103ff49 - 0x0103ff84 [0.00] 0: 0x0103ffa0 - 0x0103fff0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 333260 [0.00] Policy zone: Normal [0.00] Kernel command line: BOOT_IMAGE=scsi0:/EFI/debian/boot/vmlinuz root=/dev/sda2 ro [0.00] PID hash table entries: 4096 (order: 1, 32768 bytes) [0.00] Memory: 6202848k/6233536k available (7787k code, 61104k reserved, 4468k data, 1184k init) [0.00] Leaving McKinley Errata 9 workaround enabled [0.00] Hierarchical RCU implementation. [0.00] CONFIG_RCU_FANOUT set to non-default value of 32 [0.00] NR_IRQS:1024 [0.00] ACPI: Local APIC address c000fee0 [0.00] GSI 36 (level, low) - CPU 0 (0x) vector 49 [0.00] Console: colour VGA+ 80x25 [0.004000] Calibrating delay loop... 1343.48 BogoMIPS (lpj=2686976) [0.016100] pid_max: default: 32768 minimum: 301 [0.016521] Security Framework initialized [0.017470] AppArmor: AppArmor disabled by boot time parameter [0.018253] Dentry cache hash table entries: 1048576 (order: 9, 8388608 bytes) [0.037785] Inode-cache hash table entries: 524288 (order: 8, 4194304 bytes) [0.043205] Mount-cache hash table entries: 1024 [
Bug#516382: [2.6.22 - 2.6.23 regression] [alpha] tg3: incoming ssh fails with Corrupted MAC on input
On Mon, Mar 19, 2012 at 8:29 AM, Jonathan Nieder jrnie...@gmail.com wrote: Thibaut VARENE wrote: I don't really have time to play with it nowadays, but if somebody wants to try it out I can probably arrange for remote access. I'd be happy to try if there's some kind of remote interface for interacting with the bootloader and rebooting. There is. I'll get in touch with you again later this week, I'm currently on vacation ;) T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- 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/ca+dqjfjowt9qasxrvojegqa5-hlh0kgbtg__t+5npj4f7p0...@mail.gmail.com
Bug#516382: [2.6.22 - 2.6.23 regression] [alpha] tg3: incoming ssh fails with Corrupted MAC on input
On Sat, Mar 17, 2012 at 12:09 AM, Jonathan Nieder jrnie...@gmail.com wrote: Hi Thibaut, Hi Jonathan, Thibaut VARÈNE wrote: After upgrading from etch to lenny, and booting the new kernel, I realized I couldn't login into the box anymore: ssh would consistently fail to connect with: Corrupted MAC on input It's reproducible across reboots. When I rebooted into 2.6.18, the problem vanished. I'm using a BCM 5701 (tg3 driver) GigE NIC. [...] This bug has sufficient evidence proving that it's real and affecting 2.6.26 in lenny. I'm just curious about the current status: do you still have access to a machine reproducing this? If so, do you know if squeeze or wheezy is affected? I still have the machine but it's stuck on lenny with a 2.6.18 kernel because since it's a remote machine, having trouble with networking is a major inconvenience... I don't really have time to play with it nowadays, but if somebody wants to try it out I can probably arrange for remote access. Cheers, T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- 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/CA+DQjFjjXQd6jiT3zZGUhPmNTpttF7P_1-QCfN_Lf+4OW-W=-g...@mail.gmail.com
Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources
On Tue, Sep 14, 2010 at 10:37 AM, Thibaut VARÈNE vare...@debian.org wrote: Package: linux-image-2.6.32-5-mckinley Version: 2.6.32-20 Severity: grave Justification: renders system unusable System boots fine with linux-image-2.6.32-3-mckinley 2.6.32-9. Panics with 2.6.32-20 with: I/O MMU @ c000fed01000 is out of mapping resources FWIW, this bug still affects 2.6.32-27, and renders the system completely unusable. I've had to stick with 2.6.32-9 so far. HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- 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/aanlktikkzc489swov7m848lqafisnpnfom-vyn6qq...@mail.gmail.com
Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources
On Mon, Nov 15, 2010 at 2:03 PM, Thibaut VARENE vare...@debian.org wrote: As expected, 2.6.36.1 from experimental fucked up my raid gracefully, just as 2.6.35-21 did. I'm so very very happy right now, I obviously meant 2.6.32-21 here. -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- 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/aanlktikxho+uk4p9k30_kb4znivppcy3_bh3gi+2+...@mail.gmail.com
Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources
On Mon, Nov 15, 2010 at 6:28 PM, dann frazier da...@dannf.org wrote: On Mon, Nov 15, 2010 at 02:35:21PM +, Ben Hutchings wrote: Given that this bug still exists in 2.6.36, you can report a bug upstream at https://bugzilla.kernel.org. We will be happy to backport any fix if possible. Let us know the upstream bug number or URL so we can track it. +1 - my system uses only scsi disks, so I can't reproduce this problem. As I pointed out before, this machine is a webserver, not a development crashbox. If nobody else wants to help with this issue, I'll just stick with -9 for the rest of the foreseable life of this box. FWIW, all zx2000/zx6000 have the same onboard IDE controller (cmd64x), so reproducing this bug should simply be a matter of throwing an IDE disk at them and running a system on it... (maybe two if that's what triggers the bug, but I don't think so: the affect drives are both: errors on sda (master) and direct offlining of sdb (slave)). -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- 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/aanlktikfrcuowfc035gwxpn5azun1zkcrpjnfrd1m...@mail.gmail.com
Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources
On Mon, Nov 15, 2010 at 7:54 PM, Ben Hutchings b...@decadent.org.uk wrote: Since there are many known security flaws in -9, you should only do this if you have a properly configured local firewall and are prepared to treat all local users as having root access. Not a concern: no local users (besides me) and the only network access exposed to the world is port 80... ;P Alternately you could use the Debian kernel source and build a kernel configured to use the old IDE driver for this hardware. If I'm gonna build a kernel from source, it'll be a stock kernel. I wouldn't be half surprised if they didn't expose that bug, too... On the third hand, I suspect that replacing this machine with a PC will quickly pay for itself in power savings. Agreed, it's something I'll keep in mind for when I'll have to pay for that machine's power ;) -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- 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/aanlktinfrrxaugl+jvn2hwqvwehgrp_tmp2arcekh...@mail.gmail.com
Bug#561203: threads and fork on machine with VIPT-WB cache
On Fri, Jun 4, 2010 at 7:21 AM, dann frazier da...@debian.org wrote: On Fri, Jun 04, 2010 at 10:03:07AM +0900, NIIBE Yutaka wrote: Modestas Vainius wrote: Note that Debian's buildds run a UP kernel, so as soon as those fixes go upstream we can pull them in. Thanks for all your work here! Well, as long as this is unfixed or at least common, I don't see how hppa can be considered to be a release arch. Is that UP patch available somewhere? My case and my analysis talked about UP kernel, and John David Anglin made a patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203#144 After that, the discussion went to SMP cases. It would be better to evaluate the patch again, and make sure it works for UP case and fix failures of buildd, then apply for Linux in Debian (only) for HPPA. I know that the patch is not that ideal because it touches architecture independent part of Linux, but it is worth for Linux in Debian (or Linux for the HPPA machine of buildd, at least). I'm happy to test the patch if necessary to help push this change upstream. However, we do need the change to go upstream before we can include it in the Debian kernel. Just for reference, I've summarized the test cases and related patches here: http://wiki.parisc-linux.org/TestCases HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- 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/aanlktikldmpvgejp54qcnvmcup2ns5lkepwhxwonl...@mail.gmail.com
Bug#517449: closed by maximilian attems m...@stro.at (Re: linux-image-2.6.26-1-amd64: SCHED_IDLE issues (tasks blocked for more than 120 seconds))
On Fri, Mar 12, 2010 at 12:33 AM, Debian Bug Tracking System ow...@bugs.debian.org wrote: Version: 2.6.26-21 this should have been fixed on stable update, thus closing. Which stable update? It happened to me no later than this morning, and I'm running: ii linux-image-2.6.26-2-amd64 2.6.26-21lenny3 Linux 2.6.26 image on AMD64 Thanks, T-Bone -- 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/7d01f9f01003111648i749b6321s9010bf4bbaee7...@mail.gmail.com
Bug#519984: Cannot boot 2.6.26 kernel on HPPA N4000
On Sun, Jul 26, 2009 at 4:45 PM, Grant Grundlergrund...@parisc-linux.org wrote: On Sat, Jul 25, 2009 at 05:08:24PM +0200, Thibaut VARENE wrote: Debian kernel seems to triggers HPMCs with PCI addon cards. It's been discussed previously here, dunno what the status of that bug is, but iirc it doesn't affect upstream. While many PCI cards won't work in PARISC systems, some do including many of those sold by HP. For generic PCI support, AFAIK, only PCI-PCI bridge support is broken and I've not tested those in a while. I have two systems setup in Cupertino Test Ring which each have one add-on card with PCI-PCI bridge (rio and ios). I guess this wasn't obvious enough from the thread I was pointing to, but this bug affects otherwise perfectly working PCI cards (such as tulip, SYM2, or tg3). As I said, only 2.6.26 from Debian seems to be affected (among the few kernels I've tested). HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519984: Cannot boot 2.6.26 kernel on HPPA N4000
On Sat, Jul 25, 2009 at 4:10 PM, Moritz Muehlenhoffj...@inutil.org wrote: [Adding debian-hppa to CC and quoting in full] Is this a known issue, has it been fixed in current kernels from unstable? I believe this relates to that previous post: http://www.mail-archive.com/debian-h...@lists.debian.org/msg06301.html Debian kernel seems to triggers HPMCs with PCI addon cards. It's been discussed previously here, dunno what the status of that bug is, but iirc it doesn't affect upstream. HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517627: linux-image-2.6.26-1-parisc64-smp: Acenic driver without firmware triggers HPMC
Package: linux-image-2.6.26-1-parisc64-smp Version: 2.6.26-13 Severity: important Acenic driver is provided without firmware. When it's being loaded at boot time, it starts complaining that it can't find a firmware to load. Boot progreses for a little while and eventually when setting up networking, the box goes kaboom. Yay. Relevant lspci output: 10:00.0 Ethernet controller: Alteon Networks Inc. AceNIC Gigabit Ethernet (rev 01) Subsystem: Hewlett-Packard Company Device 106f Flags: bus master, 66MHz, medium devsel, latency 128, IRQ 72 Memory at f900 (32-bit, non-prefetchable) [size=16K] Kernel driver in use: acenic -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 2.6.22.19 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-1-parisc64-smp depends on: ii debconf [debconf-2.0] 1.5.25 Debian configuration management sy ii initramfs-tools [linux-initra 0.93 tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo linux-image-2.6.26-1-parisc64-smp recommends no packages. Versions of packages linux-image-2.6.26-1-parisc64-smp suggests: pn linux-doc-2.6.26 none (no description available) ii palo 1.16+nmu1 Linux boot loader for parisc/hppa -- debconf information: linux-image-2.6.26-1-parisc64-smp/preinst/lilo-initrd-2.6.26-1-parisc64-smp: true shared/kernel-image/really-run-bootloader: true linux-image-2.6.26-1-parisc64-smp/postinst/old-dir-initrd-link-2.6.26-1-parisc64-smp: true linux-image-2.6.26-1-parisc64-smp/postinst/old-system-map-link-2.6.26-1-parisc64-smp: true linux-image-2.6.26-1-parisc64-smp/preinst/abort-install-2.6.26-1-parisc64-smp: linux-image-2.6.26-1-parisc64-smp/postinst/create-kimage-link-2.6.26-1-parisc64-smp: true linux-image-2.6.26-1-parisc64-smp/postinst/bootloader-test-error-2.6.26-1-parisc64-smp: linux-image-2.6.26-1-parisc64-smp/preinst/lilo-has-ramdisk: linux-image-2.6.26-1-parisc64-smp/postinst/kimage-is-a-directory: linux-image-2.6.26-1-parisc64-smp/preinst/elilo-initrd-2.6.26-1-parisc64-smp: true * linux-image-2.6.26-1-parisc64-smp/preinst/bootloader-initrd-2.6.26-1-parisc64-smp: false linux-image-2.6.26-1-parisc64-smp/preinst/failed-to-move-modules-2.6.26-1-parisc64-smp: linux-image-2.6.26-1-parisc64-smp/postinst/bootloader-error-2.6.26-1-parisc64-smp: linux-image-2.6.26-1-parisc64-smp/prerm/removing-running-kernel-2.6.26-1-parisc64-smp: true linux-image-2.6.26-1-parisc64-smp/postinst/depmod-error-2.6.26-1-parisc64-smp: false linux-image-2.6.26-1-parisc64-smp/postinst/depmod-error-initrd-2.6.26-1-parisc64-smp: false linux-image-2.6.26-1-parisc64-smp/preinst/already-running-this-2.6.26-1-parisc64-smp: linux-image-2.6.26-1-parisc64-smp/preinst/overwriting-modules-2.6.26-1-parisc64-smp: true linux-image-2.6.26-1-parisc64-smp/prerm/would-invalidate-boot-loader-2.6.26-1-parisc64-smp: true linux-image-2.6.26-1-parisc64-smp/postinst/old-initrd-link-2.6.26-1-parisc64-smp: true linux-image-2.6.26-1-parisc64-smp/preinst/abort-overwrite-2.6.26-1-parisc64-smp: linux-image-2.6.26-1-parisc64-smp/preinst/initrd-2.6.26-1-parisc64-smp: -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517449: linux-image-2.6.26-1-amd64: SCHED_IDLE issues (tasks blocked for more than 120 seconds)
Package: linux-image-2.6.26-1-amd64 Version: 2.6.26-13 Severity: important Tags: patch * ISSUE Lenny's kernel is subject to the bug described here: http://lkml.org/lkml/2009/1/11/70 * ANALYSIS FIX and fixed with this thread: http://lkml.org/lkml/2009/1/15/107 (in particular with http://lkml.org/lkml/2009/1/15/231 and http://lkml.org/lkml/2009/1/15/240, AFAIU) FWIW, this seems to have made it to 2.6.28.y at least, with: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.28.y.git;a=commit;h=046e7f77d734778a3b2e7d51ce63da3dbe7a8168 http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.28.y.git;a=commit;h=df94b12439ca449a852e579fc2952dac80f70c90 * TYPICAL SYMPTOMS Basically, running tasks at SCHED_IDLEPRIO (such as BOINC) renders the system sluggish and randomly unresponsive. Messages such as this one appear in dmesg: [1830473.188790] INFO: task pdflush:3945 blocked for more than 120 seconds. [1830473.269257] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [1830473.365255] pdflush D 81003c595800 0 3945 2 [1830473.365274] 81002f055d60 0046 81002f055d70 804289af [1830473.365278] 8100258eaee0 81003e966f60 8100258eb168 00028031dc67 [1830473.365281] 0008 a03445b4 81000a2e8340 000b [1830473.365283] Call Trace: [1830473.365380] [804289af] thread_return+0x6b/0xac [1830473.365448] [a03445b4] :xfs:xfs_log_move_tail+0x46/0x12c [1830473.365472] [a035b055] :xfs:xfs_buf_wait_unpin+0x86/0xa8 [1830473.365479] [8022c202] default_wake_function+0x0/0xe [1830473.365503] [a035b49b] :xfs:xfs_buf_iorequest+0x20/0x61 [1830473.365538] [a035ec2e] :xfs:xfs_bdstrat_cb+0x36/0x3a [1830473.365559] [a0357d59] :xfs:xfs_bwrite+0x5e/0xbb [1830473.365580] [a0352209] :xfs:xfs_syncsub+0x119/0x226 [1830473.365602] [a03600d4] :xfs:xfs_fs_write_super+0x1b/0x21 [1830473.365608] [8029cd90] sync_supers+0x60/0xa4 [1830473.365615] [802783f2] pdflush+0x0/0x211 [1830473.365619] [80277fb9] wb_kupdate+0x2d/0x10d [1830473.369036] [802783f2] pdflush+0x0/0x211 [1830473.369036] [80278556] pdflush+0x164/0x211 [1830473.369036] [80277f8c] wb_kupdate+0x0/0x10d [1830473.369036] [80246083] kthread+0x47/0x74 [1830473.369036] [80230196] schedule_tail+0x27/0x5c [1830473.369036] [8020cf28] child_rip+0xa/0x12 [1830473.369036] [80213299] restore_i387_ia32+0xb0/0xd4 [1830473.369036] [8024603c] kthread+0x0/0x74 [1830473.369036] [8020cf1e] child_rip+0x0/0x12 Sometimes keyboard input will yield repeated keystrokes. SSH session will stop echoing. And basically hell freezes over for 2 minutes. I believe this bug relates to #498328, #499046 and possibly #499198 This is an extremely nasty bug. I've seen it very frequently while running BOINC on Xen dom0 on a 16-core box (using debian xen kernel). A temporary workaround has been to cap BOINC to 90% CPU usage: freezes still happen but last less. HTH -- Package-specific info: ** Version: Linux version 2.6.26-1-amd64 (Debian 2.6.26-13) (wa...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-24)) #1 SMP Sat Jan 10 17:57:00 UTC 2009 -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-1-amd64 depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii initramfs-tools [linux-initra 0.92o tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo linux-image-2.6.26-1-amd64 recommends no packages. Versions of packages linux-image-2.6.26-1-amd64 suggests: ii grub 0.97-47lenny2 GRand Unified Bootloader (Legacy v pn linux-doc-2.6.26 none(no description available) -- debconf information: linux-image-2.6.26-1-amd64/postinst/create-kimage-link-2.6.26-1-amd64: true shared/kernel-image/really-run-bootloader: true linux-image-2.6.26-1-amd64/postinst/kimage-is-a-directory: linux-image-2.6.26-1-amd64/preinst/bootloader-initrd-2.6.26-1-amd64: true linux-image-2.6.26-1-amd64/postinst/old-initrd-link-2.6.26-1-amd64: true linux-image-2.6.26-1-amd64/preinst/initrd-2.6.26-1-amd64: linux-image-2.6.26-1-amd64/postinst/old-system-map-link-2.6.26-1-amd64: true linux-image-2.6.26-1-amd64/postinst/depmod-error-initrd-2.6.26-1-amd64: false linux-image-2.6.26-1-amd64/preinst/overwriting-modules-2.6.26-1-amd64: true linux-image-2.6.26-1-amd64/preinst/elilo-initrd-2.6.26-1-amd64: true linux-image-2.6.26-1-amd64/postinst/bootloader-error-2.6.26-1-amd64:
Bug#517243: linux-image-2.6.26-1-parisc64: tg3 probe triggers HPMC
Package: linux-image-2.6.26-1-parisc64 Version: 2.6.26-13 Severity: normal Booting lenny's kernel with a known working Tigon3 card (BCM5701) in the box triggers an HPMC during driver probe. I couldn't capture the console output yet, but ISTR the box crashing before the driver's output of DMA setup line. I'll provide additional info ASAP. AFAICT this doesn't happen with older (2.6.22) kernel. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: hppa (parisc64) Kernel: Linux 2.6.26-1-parisc64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-1-parisc64 depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii initramfs-tools [linux-initra 0.92o tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo linux-image-2.6.26-1-parisc64 recommends no packages. Versions of packages linux-image-2.6.26-1-parisc64 suggests: pn linux-doc-2.6.26 none (no description available) ii palo 1.16+nmu1 Linux boot loader for parisc/hppa -- debconf information: linux-image-2.6.26-1-parisc64/preinst/lilo-has-ramdisk: linux-image-2.6.26-1-parisc64/prerm/removing-running-kernel-2.6.26-1-parisc64: true linux-image-2.6.26-1-parisc64/preinst/lilo-initrd-2.6.26-1-parisc64: true shared/kernel-image/really-run-bootloader: true linux-image-2.6.26-1-parisc64/postinst/kimage-is-a-directory: linux-image-2.6.26-1-parisc64/preinst/abort-install-2.6.26-1-parisc64: linux-image-2.6.26-1-parisc64/preinst/already-running-this-2.6.26-1-parisc64: linux-image-2.6.26-1-parisc64/postinst/old-initrd-link-2.6.26-1-parisc64: true linux-image-2.6.26-1-parisc64/preinst/bootloader-initrd-2.6.26-1-parisc64: true linux-image-2.6.26-1-parisc64/postinst/bootloader-error-2.6.26-1-parisc64: linux-image-2.6.26-1-parisc64/postinst/old-dir-initrd-link-2.6.26-1-parisc64: true linux-image-2.6.26-1-parisc64/preinst/failed-to-move-modules-2.6.26-1-parisc64: linux-image-2.6.26-1-parisc64/preinst/elilo-initrd-2.6.26-1-parisc64: true linux-image-2.6.26-1-parisc64/postinst/depmod-error-initrd-2.6.26-1-parisc64: false linux-image-2.6.26-1-parisc64/postinst/bootloader-test-error-2.6.26-1-parisc64: linux-image-2.6.26-1-parisc64/postinst/create-kimage-link-2.6.26-1-parisc64: true linux-image-2.6.26-1-parisc64/postinst/depmod-error-2.6.26-1-parisc64: false linux-image-2.6.26-1-parisc64/preinst/initrd-2.6.26-1-parisc64: linux-image-2.6.26-1-parisc64/postinst/old-system-map-link-2.6.26-1-parisc64: true linux-image-2.6.26-1-parisc64/preinst/abort-overwrite-2.6.26-1-parisc64: linux-image-2.6.26-1-parisc64/preinst/overwriting-modules-2.6.26-1-parisc64: true linux-image-2.6.26-1-parisc64/prerm/would-invalidate-boot-loader-2.6.26-1-parisc64: true -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516382: linux-image-2.6.26-1-alpha-generic: tg3: incoming ssh fails with Corrupted MAC on input
Package: linux-image-2.6.26-1-alpha-generic Version: 2.6.26-13 Severity: important Hi, After upgrading from etch to lenny, and booting the new kernel, I realized I couldn't login into the box anymore: ssh would consistently fail to connect with: Corrupted MAC on input It's reproducible across reboots. When I rebooted into 2.6.18, the problem vanished. I'm using a BCM 5701 (tg3 driver) GigE NIC. Here's dmesg output with 2.6.18.dfsg.1-24: tg3.c:v3.65 (August 07, 2006) eth2: Tigon3 [partno(A6825-60101) rev 0105 PHY(5701)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ethernet 00:30:6e:49:c6:f0 eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[0] eth2: dma_rwctrl[76ff1b0f] dma_mask[64-bit] And now with 2.6.26-13: eth2: Tigon3 [partno(A6825-60101) rev 0105 PHY(5701)] (PCI:33MHz:64-bit) 10/100/1000Base-T Ethernet 00:30:6e:49:c6:f0 eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[0] eth2: dma_rwctrl[76ff1b0f] dma_mask[64-bit] I can't find anything special in the logs or dmesg, afaict. HTH -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: alpha Kernel: Linux 2.6.18-6-alpha-generic Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-1-alpha-generic depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii initramfs-tools [linux-initra 0.92o tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo linux-image-2.6.26-1-alpha-generic recommends no packages. Versions of packages linux-image-2.6.26-1-alpha-generic suggests: ii aboot 1.0~pre20040408-3 Linux bootloader for the SRM conso pn fdutilsnone(no description available) pn linux-doc-2.6.26 none(no description available) -- debconf information: linux-image-2.6.26-1-alpha-generic/prerm/would-invalidate-boot-loader-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/postinst/depmod-error-initrd-2.6.26-1-alpha-generic: false linux-image-2.6.26-1-alpha-generic/preinst/initrd-2.6.26-1-alpha-generic: shared/kernel-image/really-run-bootloader: true linux-image-2.6.26-1-alpha-generic/postinst/create-kimage-link-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/postinst/old-initrd-link-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/postinst/depmod-error-2.6.26-1-alpha-generic: false linux-image-2.6.26-1-alpha-generic/postinst/bootloader-test-error-2.6.26-1-alpha-generic: linux-image-2.6.26-1-alpha-generic/preinst/abort-install-2.6.26-1-alpha-generic: linux-image-2.6.26-1-alpha-generic/preinst/elilo-initrd-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/preinst/overwriting-modules-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/preinst/bootloader-initrd-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/preinst/failed-to-move-modules-2.6.26-1-alpha-generic: linux-image-2.6.26-1-alpha-generic/postinst/kimage-is-a-directory: linux-image-2.6.26-1-alpha-generic/postinst/old-system-map-link-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/postinst/bootloader-error-2.6.26-1-alpha-generic: linux-image-2.6.26-1-alpha-generic/postinst/old-dir-initrd-link-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/preinst/lilo-initrd-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/prerm/removing-running-kernel-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/preinst/lilo-has-ramdisk: linux-image-2.6.26-1-alpha-generic/preinst/abort-overwrite-2.6.26-1-alpha-generic: linux-image-2.6.26-1-alpha-generic/preinst/already-running-this-2.6.26-1-alpha-generic: -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515956: linux-image-2.6.26-1-alpha-generic: 2.6.26-1-alpha-generic fails to boot on DS10 (Tsunami)
Package: linux-image-2.6.26-1-alpha-generic Version: 2.6.26-13 Severity: normal Hi, Right after the release of Lenny, I upgraded my Compaq AlphaServer DS1Â0 which was previous running Etch. Everything went rather smoothly, until I tried to reboot the system: the new kernel fails to load. aboot stops at loading compressed vmlinuz, and then nothing happens. The previous Etch kernel (2.6.18) still boots just fine. I'm not quite sure how to debug this, is there any specific info to provide? HTH -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: alpha Kernel: Linux 2.6.18-6-alpha-generic Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-1-alpha-generic depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii initramfs-tools [linux-initra 0.92o tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo linux-image-2.6.26-1-alpha-generic recommends no packages. Versions of packages linux-image-2.6.26-1-alpha-generic suggests: ii aboot 1.0~pre20040408-3 Linux bootloader for the SRM conso pn fdutilsnone(no description available) pn linux-doc-2.6.26 none(no description available) -- debconf information: linux-image-2.6.26-1-alpha-generic/prerm/would-invalidate-boot-loader-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/postinst/depmod-error-initrd-2.6.26-1-alpha-generic: false linux-image-2.6.26-1-alpha-generic/preinst/initrd-2.6.26-1-alpha-generic: shared/kernel-image/really-run-bootloader: true linux-image-2.6.26-1-alpha-generic/postinst/create-kimage-link-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/postinst/old-initrd-link-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/postinst/depmod-error-2.6.26-1-alpha-generic: false linux-image-2.6.26-1-alpha-generic/postinst/bootloader-test-error-2.6.26-1-alpha-generic: linux-image-2.6.26-1-alpha-generic/preinst/abort-install-2.6.26-1-alpha-generic: linux-image-2.6.26-1-alpha-generic/preinst/elilo-initrd-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/preinst/overwriting-modules-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/preinst/bootloader-initrd-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/preinst/failed-to-move-modules-2.6.26-1-alpha-generic: linux-image-2.6.26-1-alpha-generic/postinst/kimage-is-a-directory: linux-image-2.6.26-1-alpha-generic/postinst/old-system-map-link-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/postinst/bootloader-error-2.6.26-1-alpha-generic: linux-image-2.6.26-1-alpha-generic/postinst/old-dir-initrd-link-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/preinst/lilo-initrd-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/prerm/removing-running-kernel-2.6.26-1-alpha-generic: true linux-image-2.6.26-1-alpha-generic/preinst/lilo-has-ramdisk: linux-image-2.6.26-1-alpha-generic/preinst/abort-overwrite-2.6.26-1-alpha-generic: linux-image-2.6.26-1-alpha-generic/preinst/already-running-this-2.6.26-1-alpha-generic: -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian parisc config for 2.6.26 broke the real time clock
On Tue, Sep 9, 2008 at 9:20 PM, John David Anglin [EMAIL PROTECTED] wrote: This I2C bus is not acessible by the operating system (as far as I know). HP-UX seems to be able to access fan and power status somehow. It Fan and power status are accessed through PDC. That's what I do with the pdc_chassis driver, and what's exposed in /proc/chassis on !PAT boxes (I don't have the PAT specs to implement the proper calls, unfortunately). AFAIK, there's no need to use i2c to retrieve that info, it's all PDC glue. HTH T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417927: parisc: SCSI devices get randomly offlined
Package: linux-image-2.6-parisc64 Version: 2.6.18+5 Severity: important A bug which affects all parisc kernels since 2.6.18-rc2 affects the debian parisc kernel as well. Under some random circumstances, SCSI devices (such as the root disk) will get offlined, rendering the box totally unuseable: sd 1:0:5:0: rejecting I/O to offline device EXT3-fs error (device sda3): ext3_find_entry: reading directory #1175041 offset 0 sd 1:0:5:0: rejecting I/O to offline device sd 1:0:5:0: rejecting I/O to offline device sd 1:0:5:0: rejecting I/O to offline device I can't paste the initial messages from the kernel bug since they were out of dmesg at this point, but this is a known bug already reported on parisc-linux mailing lists, see eg this thread: http://lists.parisc-linux.org/pipermail/parisc-linux/2007-January/031078.html So far this bug has been isolated on 64bit SMP machines. I can't tell for sure whether 32bit and/or UP are safe. HTH -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: hppa (parisc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-parisc64-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages linux-image-2.6-parisc64 depends on: ii linux-image-2.6.18-3-parisc64 2.6.18-7 Linux 2.6.18 image on 64-bit PA-RI linux-image-2.6-parisc64 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414044: linux-2.6: e1000 panics on parisc
Package: linux-2.6 Severity: normal The e1000 driver shipped with current d-i panics the kernel on parisc. Please either disable it or backport the fixes that can probably be found in 2.6.20 (which works just fine). HTH T-Bone Intel(R) PRO/1000 Network Driver - version 7.1.9-k4-NAPI Copyright (c) 1999-2006 Intel Corporation. Backtrace: [1011a60c] outl+0x7c/0x88 [040cd89c] e1000_io_write+0x14/0x20 [e1000] [040e1a0c] e1000_reset_hw+0x29c/0x830 [e1000] [040d5a24] e1000_probe+0x7fc/0xe20 [e1000] [10288fd0] pci_device_probe+0x88/0xc8 [102d82c0] driver_probe_device+0x80/0xf8 [102d84f4] __driver_attach+0xac/0x138 [102d791c] bus_for_each_dev+0x6c/0xd0 [102d8188] driver_attach+0x28/0x38 [102d731c] bus_add_driver+0xb4/0x1d8 [102d88d0] driver_register+0xb8/0xc8 [10289248] __pci_register_driver+0x50/0x98 [0003409c] e1000_init_module+0x6c/0x78 [e1000] [10159fc4] sys_init_module+0x17cc/0x1a00 [10104f94] syscall_exit+0x0/0x14 Kernel Fault: Code=26 regs=aed40a90 (Addr=) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 1100 Not tainted r00-03 0804000f 10560d20 04fd8b708 r04-07 040c4000 0003 02fc0229 0040 r08-11 4fd8b708 4fd8b000 4ffaa800 0002 r12-15 0167 040a30a2 040ec7e0 r16-19 040aa108 03fa 040aa148 r20-23 0814 8000 0900 r24-27 00 1054fd20 r28-31 fffc aed40a60 aed40a90 sr00-03 2000 00011800 sr04-07 IASQ: IAOQ: 102903e0 102903e4 IIR: 0ff81280ISR: IOR: CPU:0 CR30: aed4 CR31: 0R28: 1016dda4 IAOQ[0]: lba_pat_out32+0x30/0x50 IAOQ[1]: lba_pat_out32+0x34/0x50 RP(r2): outl+0x7c/0x88 Kernel panic - not syncing: Kernel Fault -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (700, 'testing'), (90, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20.1-ck1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346366: linux-2.6: linux-image-flavour should depend on a versionned linux-image-2.6-flavour
Package: linux-2.6 Severity: important I noticed that bug on my parisc machine: I wanted to get the latest linux-image-parisc-smp kernel from unstable, thus switched from testing to unstable in my sources.list, apt-get update and then apt-get install linux-image-parisc-smp. It installed linux-image-parisc-smp 2.6.15-1 *WITHOUT* installing the kernel version 2.6.15. This is because linux-image-parisc-smp depends on linux-image-2.6-parisc-smp without any version requirement, leading to the following situation: k2000:/# dpkg -l | grep linux-image ii linux-image-2.6-parisc-smp 2.6.12-10 Linux kernel 2.6 image on multi-processor 32 ii linux-image-2.6.12-1-parisc-smp 2.6.12-10 Linux kernel 2.6.12 image on multi-processor ii linux-image-parisc-smp 2.6.15-1 Linux kernel image on multi-processor 32-bit I had to apt-get install linux-image-2.6-parisc-smp to fix the problem. As far as I can tell, the description for linux-image-parisc-smp says that it should depend on the *latest* binary image for Linux Kernel, and I've just demonstrated this is not the case. To date, this bug also affects linux-image-parisc64-smp, and i've checked on my ppc boxes, linux-image-powerpc and friends are affected as well. I believe all flavours suffer from that bug but I haven't thoroughly checked that. HTH T-Bone -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: hppa (parisc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-parisc-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334278: linux-image-2.6.12-1-parisc64-smp: Unknown symbols in sound drivers
On 10/21/05, maximilian attems [EMAIL PROTECTED] wrote: On Fri, 21 Oct 2005, Thibaut VARENE wrote: On 10/16/05, Maximilian Attems [EMAIL PROTECTED] wrote: there will be soon a 2.6.14 in exeperimental, would be cool to check that too before bugging alsa upstream. I highly doubt this is an alsa-upstream bug. I wrote this driver, which didn't make it into upstream until 2.6.14-rc2, so it looks much more to me like a backport problem. *wonderfull* why didn't you tell that earlier. tell you what? That this wasn't an ALSA upstream bug? Maybe because it (wrongly) seemed just obvious to me: there is *no* alsa module that loads (as the dmesg and lsmod output show) with that kernel (no snd-* module would load, not even snd-dummy). Despite being known brainfart, I doubt that ALSA is that broken upstream :) I don't know how the Debian kernel is built from source, but it seems that some parisc-specific patch fux0red the alsa drivers, or something alike... anyway 2.6.14 contains all the fixes of the previous -rc and will soon land in unstable as soon as it gets released. anyway we aren't already in stabilization phase with backporting business. OK. I just wanted to let you know that 2.6.12 seems pretty unusable to me wrt ALSA stuff. this is what it looks like when it actually works: [EMAIL PROTECTED]:~$ uname -a Linux Esperanza 2.6.14-rc5-pa1 #13 SMP Fri Oct 21 14:27:21 CEST 2005 parisc64 GNU/Linux ok. the -pa patch is still an out of tree pain, but that should evolve hopefully.. It will. And for the records nothing in the -pa patch is needed to get that driver to work, i tested it on PPC. HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/
Bug#334278: linux-image-2.6.12-1-parisc64-smp: Unknown symbols in sound drivers
alsa-utils weren't installed, installed them. Ran alsaconf, which b0rked exactly as expected: # alsaconf Building card database... Running update-modules... Architecture-specific modutils configuration for parisc64 not found, using defaults Loading driver... WARNING: Error inserting snd (/lib/modules/2.6.12-1-parisc64-smp/kernel/sound/core/snd.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error inserting snd_timer (/lib/modules/2.6.12-1-parisc64-smp/kernel/sound/core/snd-timer.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error inserting snd_pcm (/lib/modules/2.6.12-1-parisc64-smp/kernel/sound/core/snd-pcm.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error inserting snd_ac97_codec (/lib/modules/2.6.12-1-parisc64-smp/kernel/sound/pci/ac97/snd-ac97-codec.ko): Unknown symbol in module, or unknown parameter (see dmesg) FATAL: Error inserting snd_ad1889 (/lib/modules/2.6.12-1-parisc64-smp/kernel/sound/pci/snd-ad1889.ko): Unknown symbol in module, or unknown parameter (see dmesg) Setting default volumes... Saving the mixer setup used for this in /var/lib/alsa/asound.state. /usr/sbin/alsactl: save_state:1163: No soundcards found... === Now ALSA is ready to use. For adjustment of volumes, use your favorite mixer. Have a lot of fun! That final message is particularly funny, tho ;) On 10/16/05, Maximilian Attems [EMAIL PROTECTED] wrote: On Sun, Oct 16, 2005 at 08:43:50PM +0200, Thibaut VARENE wrote: Package: linux-image-2.6.12-1-parisc64-smp Version: 2.6.12-10 Severity: normal It's impossible to get sound drivers working on my hppa box: snipp try to run alsaconf? -- maks -- Thibaut VARENE http://www.parisc-linux.org/~varenet/
Re: Kernel Security Updates for Sarge
Horms wrote: [snip] For reference, these are the architectues that I believe the kernel team handles, and the version of the kernel source they are using in Sarge: Base kernel source version of package in Sarge 2.4.27: alpha kernel-tree-2.4.27-9 (seems to be out of date in SVN) hppa kernel-tree-2.4.27-8 FYI, 2.4.27 isn't in sarge hppa. We only provide 2.6.8. HTH T-Bone
Re: status of d-i 2.4.27/2.6.8 kernel transition
On Sun, 12 Sep 2004 13:34:57 +0200 Sven Luther [EMAIL PROTECTED] wrote: On Sat, Sep 11, 2004 at 06:25:58PM +0200, Thibaut VARENE wrote: Now if d-i needs special work of mine to sync with kernel updates, I'd better be taught about it. Yes, you need to checkout d-i, and go into debian-installer/packages/kernel/linux-kernel-di-hppa and make an upload of this with the 2.4.27 kernels. The rest of the stuff includes some adaptation in 3 different places. build/config is in debian-installer/installer/build/config/hppa.cfg or somewhere in the hppa subdir of config. The base-installer is debian-installer/packages/base-installer/debian/postinst, and rootskel i am less familiar with but it is in debian-installer/packages/rootskel. What this means is probably that nobody has been doing hppa d-i work in ages. Ok this tends to make things a bit clearer. I wasn't aware that there were such tasks to do with d-i, since I'm absolutely clueless about d-i, and not that interested in it either. I'll look at the files you suggested and see what can be done. HTH, Thibaut VARENE The PA/Linux ESIEE Team http://www.pateam.org/
Re: Open a discussion about bug 253324
--- Hi, Sven Luther wrote: This is bullshit. I don't think it is a great idea to modularize the kernel, and thus lose all the early debugging. We are going to hurt us if we go that way, especially as the boot process is now more fragile as it used to be, thanks to the initrd thingy, The workaround for this problem is to modularize everything that could possibly break or hang the kernel. Load it after vesafb-or-whatever. Problem solved. I'd like to know how a modularized PCI subsystem can be loaded _AFTER_ a PCI dependent FB driver. What then if the PCI buswalk kills the kernel? I'm not even dealing with AGP here :P This is a gross example, still it proves that kind of idea can't be implemented. HTH, Thibaut VARENE PA/Linux ESIEE Team http://www.pateam.org/
Re: Open a discussion about bug 253324
--- Hi, I'd like to know how a modularized PCI subsystem can be loaded _AFTER_ a PCI dependent FB driver. Well, duh, obviously you can't do that. :-/ Heh, I has a feeling that wouldn't be that easy ;) What then if the PCI buswalk kills the kernel? You write these parts of the kernel defensively so that this doesn't happen, and/or you test it extensively so that you're sure it won't happen. this doesn't happen/you're sure it won't happen ? Are you kidding, or are we talking about Alice in kerneland? 0% failure does not exist, that's a RULE. You boot without framebuffer options, and look at the console text. Such a console text doesn't exist on ppc. Nor on mips, iirc. There are issues on hppa as well, etc. This is a gross example, still it proves that kind of idea can't be implemented. It is the direction the kernel people want to move further in. Though that may be a General Direction, some arch dependent facts have to be taken into account. Last time I checked, the Linux kernel wasn't an x86-only kernel ;) Greetings, Thibaut VARENE PA/Linux ESIEE Team http://www.pateam.org/
Re: kernel-patch-amd64
On Wed, 30 Jun 2004 08:30:05 +0200 Sven Luther [EMAIL PROTECTED] wrote: On Tue, Jun 29, 2004 at 11:14:02PM +0100, [EMAIL PROTECTED] wrote: On Tue, Jun 29, 2004 at 06:23:21PM +0200, Jens Schmalzing wrote: I would suggest that you subscribe to debian-kernel, prepare kernel-patch-amd64-2.6.7 packages based on the example of the other 2.6 kernel-patch packages (right now, this means the powerpc patches, so please let me know if you find a better way of doing it) , and upload them as soon as amd64 enters sid. Bad idea. Split the patch and get as much as possible merged upstream. Note that large parts are simply Lindent that file and they certainly should not be mixed with the rest. And ? Is that incompatible with making a kernel-patch-amd64 package and building a kernel from it ? What i really dislike about this politic of submitting stuff upstream, is that we are going all stupid and rigid about it, and totally loosing the interest of our users from our minds. I don't think so. Getting the patch upstream has several reasons IMHO: 1) We're applying an opensource scheme: if you're making changes, send feedback upstream so that everyone can benefit of it. We're not willing to fork the Linux kernel and make a Debian kernel, are we? 2) Getting the patch upstream allows upstream kernel hackers to review it. This is of real interest to our users, since we ensure that they will have a verified and accepted (read: supported) kernel. Forking the kernel would actually be missing the interest of our users. BTW, IMHO that last sentence also applies WRT negative diffs (read: removing files)... I know that we've been having kernel packages rather different than pristing source (at least for 2.4), and I'm not quite sure that is a Good Thing (tm), especially when it comes to arch-dependent bits. (who said hppa patch was 700k+? ;) So what if it is a monolitic patch ? The kernel-patch package gets first prepared, uploaded to svn, and built and uploaded to the archive. Our users wouldn't care less if the patch is monolitic or lot of small files, but they do benefit from having an amd64 kernel. Once that is done, it is easy enough to modify the patch by splitting it or whatever, and merging stuff into the kernel-source package for later inclusion into the main packages, but at least there will be a package available now. I do agree that we need to provide our users with good software in a timely fashion. Good here means good quality, and that's very important as well. Greetings, Thibaut VARENE The PA/Linux ESIEE Team http://www.pateam.org/
Re: 2.6.7
But I've tested it now for you. Doesn't compile at all. - -- snip -- CC drivers/video/vesafb.o drivers/video/vesafb.c: In function `vesafb_remove': drivers/video/vesafb.c:410: error: stray '\240' in program -- snip -- Doesn't know what this really means, because I'm not familiar with gcc error messages. That just means there were spurious characters in the input file, usually inserted by bad editors. They usually show up as white space and are a real PITA. HTH, Thibaut VARENE PA/Linux ESIEE Team http://www.pateam.org/
Re: initrd on installed kernels
On Mon, 28 Jun 2004 18:55:19 +0200 Sven Luther [EMAIL PROTECTED] wrote: have you tried changing MODULES=most to MODULES=dep or something such in /etc/mkinitrd/mkinitrd.conf ? Maybe this should be made the default ? I tried that and the compact lilo option, and damn, it's breathtakingly fast! Now an idea: why not making MODULES=dep the default configuration instead of MODULES=most ? Thx -- Thibaut VARENE The PA/Linux ESIEE Team http://www.pateam.org/ pgpdKMsbctyki.pgp Description: PGP signature
Re: initrd on installed kernels
--- On Wed, Jun 23, 2004 at 10:21:23PM +0200, Thibaut VARENE wrote: Well, we almost reached 4Mo of compressed kernel image on powerpc with the non-initrd thingy, and it broke on some subarches (like prep). So there is obiously a limit to the non-initrd kernels. agreed, though it used to work. Maybe you just need to build your own non-initrd kernel, don't you ? You just take the kernel-source and config of the debian kernel, unmodularize what you know you will want (mostly filesystem and ide modules probably) and build the resulting kernel. Very user friendly indeed. Of course I can (and I do) build my own custom kernel (without initrd). My point is that I was switching a friend from MSWin to Linux (which is quite nice already), and I didn't want to get him into the pain of having to install a complete toolchain and learning how to build his own kernel in order to be able to update it when needed (in particular for security reasons). That was pretty interesting to me, because that friend is a complete newbie to the *nix world, so I could gather interesting remarks about what's intuitive and what's not, btw. I was pretty happy that the stock woody kernel (2.4.18-bf24) was working find and loading fast, but I was quite bothered (and so was he) noticing that after apt-get installing 2.4.26-686, the box boot was significantly slowed... RE Jens' mail: the initrd used is the stock one, I didn't change anything (yet). If you consider the fact that he switched because he was tired of the slowlyness of MSWin (and the virus stories), boot speed is quite a point for a basic user who doesn't keep its box running when he doesn't use it (read: boots several times a week, if not a day). I do agree that having tons of unused drivers builtin isn't a Good Thing, but I was wondering whether some kind of compromise between what we had (non-initrd, quick boot) and what we have (initrd, slow boot) could be found. I thought that this real end user experience report might be of any use to us kernel hackers/packagers. HTH, Thibaut VARENE PA/Linux ESIEE Team http://www.pateam.org/
Re: initrd on installed kernels
--- Hi, Thibaut Varene writes: agreed, though it used to work. Once upon a time, the Linux kernel with all available IDE and SCSI drivers compiled in fit on a floppy disk :) heh. You can still find distros with X11 on a floppy disk ;) RE Jens' mail: the initrd used is the stock one, I didn't change anything (yet). There is no stock initrd, the initrd is built to fit the system you install on. Try whether you can speed up the process by fiddling with /etc/mkinitrd/mkinitrd.conf and, if you feel adventurous, with /usr/sbin/mkinitrd. Send the patches to the initrd-tools maintainer. Good point, will look after it. If you consider the fact that he switched because he was tired of the slowlyness of MSWin (and the virus stories), boot speed is quite a point for a basic user How long exactly does it take with 2.4.18-bf24 and 2.4.26? Is there a point where the system sits unusually long, seemingly doing nothing? The main difference (the only one _really_ noticeable) stands at very early stage, when lilo loads the kernel (and the initrd now). The Loading Linux... dot-bar progress message that used to last a couple of seconds is now taking tens of secs. I thought that this real end user experience report might be of any use to us kernel hackers/packagers. If it teaches us something beyond the simple fact that newer software tends to run slower on older hardware, maybe. I don't see this issue as newer software tends to run slower on older hardware. That's more additionnal *features* (cruft ?) makes software less responsive, imho ;) Regards, Jens. P.S.: What is this MSWin thing, anyway? I remember switching to Debian from NetBSD, and I really enjoyed the experience :) heh. I have some boxes which I really enjoyed switching to NetBSD _from_ Debian (really old tiny hardware, [EMAIL PROTECTED], 36M RAM) ;) MSWin meant MicroSoft Windows, sorry for my unclear abbreviations. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj! btw, what does _that_ mean ? ;) Thibaut VARENE PA/Linux ESIEE Team http://www.pateam.org/
initrd on installed kernels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I was wondering why are we using initd on installed debian kernels. Let me explain myself: I can perfectly understand that initrd is needed for d-i, but, when I recently updated an x86 woody box to testing, upgrading its kernel to 2.4.26 debian, I noticed that the initrd thingy was installed (got the nice warning about lilo). I didn't pay much attention to that at that time, knowing it was the new default for debian kernels. But, I started giggling when I realized the total boot time (time before first login prompt) of the box was almost tripled (that's a P2 400). So here comes my suggestion: why not having a specific kernel deb for d-i *with* (the one corresponding to the version selected for the stable installer), and the rest of the kernel debs *without* initrd, as they used to be? That implies that d-i would have to install a non-initrd kernel, obviously. I'm relating here a 2.4 experience, but as far as I can tell, the same is relevant wrt 2.6. Please don't flame, that's just a question. Well, ok, if you wanna flame anyway, go ahead ;) Thx, - -- Thibaut VARENE The PA/Linux ESIEE Team http://www.pateam.org/ PS: my question about proper 2.6 packaging still holds, see http://lists.debian.org/debian-kernel/2004/06/msg00177.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFA2eZGHjLD2rfS8GMRAgJ+AKC/hpbei+G8k5/1jklHxsV6LOyLZACfSfBN is7KxszjipmzIwb9QbXwSLw= =KMdT -END PGP SIGNATURE-
2.6 hppa kernel debs
Hi, After some talks with fellow hppa hackers, we decided it was time to prepare 2.6 kernel packages. Since we don't have any 2.6 packages for hppa yet, we're looking at _The Good Thing_ (tm) to do to create them. That's why we'd like to coordinate with other arch kernel maintainers to do things right, so we're welcoming any hints on that topic. Thx, -- Thibaut VARENE The PA/Linux ESIEE Team http://www.pateam.org/ pgpGvos9z0tkQ.pgp Description: PGP signature
