Bug#284961: kernel-image-2.4.27-1-smp: kernel-image-2.4.27-1-* does not detect proper SCSI Controller.
Hi Greg, On Tue, Apr 05, 2005 at 10:17:49PM -0400, Greg Folkert wrote: I can arrange an account with sudo access. As long as we do the account info off-bug. On Tue, 2005-04-05 at 18:06 -0700, Steve Langasek wrote: Hi Greg, Apologies for the dormancy on this bug; yours is one of several RC bugs on initrd-tools that have been long in the resolving, so it's not just you... FWIW. :) You mentioned being able to get access to this machine for debugging. Is that still a possibility? Thanks, Bad news... I can't reproduce this problem, even on your machine. :) Can you tell me what kernel you were running at the time you saw the problem? Your initial report was from a machine that was running 2.4.27-1-smp, so I assume you got this kernel working using MODULES=most in mkinitrd.conf and then reported the bug; does that agree with what you recall of the situation? I suspect this problem was caused by a module name change in the kernel, where earlier you might have been using sym53c8xx instead of sym53c8xx_2, so the wrong driver name was detected based on which module was currently running. Fixing this in initrd-tools therefore probably means introducing some special-casing to mangle this module name according to the selected kernel version. If you are still able to reproduce this bug on your system, please let me know how it's manifesting, in case I'm overlooking something. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bug#284961: kernel-image-2.4.27-1-smp: kernel-image-2.4.27-1-* does not detect proper SCSI Controller.
Resend Sorry. Forgot the bug. On Fri, 2005-04-08 at 23:16 -0700, Steve Langasek wrote: Hi Greg, On Tue, Apr 05, 2005 at 10:17:49PM -0400, Greg Folkert wrote: I can arrange an account with sudo access. As long as we do the account info off-bug. On Tue, 2005-04-05 at 18:06 -0700, Steve Langasek wrote: Hi Greg, Apologies for the dormancy on this bug; yours is one of several RC bugs on initrd-tools that have been long in the resolving, so it's not just you... FWIW. :) You mentioned being able to get access to this machine for debugging. Is that still a possibility? Thanks, Bad news... I can't reproduce this problem, even on your machine. :) Can you tell me what kernel you were running at the time you saw the problem? Your initial report was from a machine that was running 2.4.27-1-smp, so I assume you got this kernel working using MODULES=most in mkinitrd.conf and then reported the bug; does that agree with what you recall of the situation? Well, that kernel that is currently running also has this problem. You need to compare the modules sym53c8xx and sym53c8xx_2, you will see they are the same module, different location. I suspect this problem was caused by a module name change in the kernel, where earlier you might have been using sym53c8xx instead of sym53c8xx_2, so the wrong driver name was detected based on which module was currently running. Fixing this in initrd-tools therefore probably means introducing some special-casing to mangle this module name according to the selected kernel version. This is probably what the problem is. But, I still have noticed, that installing any kernel still gets this error. You can go ahead and remove and re-install any kernel you want. If you do this, I am sure you should be able to discover it. I can recover with tftp booting, so it shouldn;t be to bad. If you are still able to reproduce this bug on your system, please let me know how it's manifesting, in case I'm overlooking something. I am sure, that (re)installing any kernel will give you the problem. I have given you sudo access and in the sudo group. I only ask that you don't screw up /home if you need to I can re-back it up. Pretty much the whole reason I couldn't let you in, was the firewall changes would have made a service interruption for us. I had to open undead up to more than one external host for ssh. You realize, the reason it is called undead, the machine was built on July 10, 1994 shipped to the company I worked at. I have been the admin for that machine since then. They took it out of commission and gave it to me. If you still cannot reproduce it, lemme know, I should be able to. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: Re: Bug#301701: kernel-image-2.6.10-1-k7: System catatonic when tryingtowrite DVD or CD as user
I have demonstrated this bug with a vanilla kernel.org kernel. I have found a similar blocking bug submitted on 20th February and appended a copy of the Debian bug. http://bugzilla.kernel.org/show_bug.cgi?id=4234 Given the severity of the bug, I am surprised it has survived two kernel versions. For me, 2,6.10 and 2.6.11 have incrementally added three serious/ critical bugs, and only solved an ISO9660 file system issue (where files 2Gb would confuse the driver). The field is open for better systems of kernel development management than what we are seeing with the official kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#303844: resolve device xxx is grabbed by another driver
Processing commands for [EMAIL PROTECTED]: reassign 303844 kernel-source-2.6.11 Bug#303844: resolve device xxx is grabbed by another driver Bug reassigned from package `sl-modem-source' to `kernel-source-2.6.11'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of kernel-source-2.6.11_2.6.11-3_powerpc.changes
kernel-source-2.6.11_2.6.11-3_powerpc.changes uploaded successfully to localhost along with the files: kernel-source-2.6.11_2.6.11-3.dsc kernel-source-2.6.11_2.6.11-3.diff.gz kernel-patch-debian-2.6.11_2.6.11-3_all.deb kernel-source-2.6.11_2.6.11-3_all.deb kernel-tree-2.6.11_2.6.11-3_all.deb kernel-doc-2.6.11_2.6.11-3_all.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
kernel-source-2.6.11_2.6.11-3_powerpc.changes ACCEPTED
Accepted: kernel-doc-2.6.11_2.6.11-3_all.deb to pool/main/k/kernel-source-2.6.11/kernel-doc-2.6.11_2.6.11-3_all.deb kernel-patch-debian-2.6.11_2.6.11-3_all.deb to pool/main/k/kernel-source-2.6.11/kernel-patch-debian-2.6.11_2.6.11-3_all.deb kernel-source-2.6.11_2.6.11-3.diff.gz to pool/main/k/kernel-source-2.6.11/kernel-source-2.6.11_2.6.11-3.diff.gz kernel-source-2.6.11_2.6.11-3.dsc to pool/main/k/kernel-source-2.6.11/kernel-source-2.6.11_2.6.11-3.dsc kernel-source-2.6.11_2.6.11-3_all.deb to pool/main/k/kernel-source-2.6.11/kernel-source-2.6.11_2.6.11-3_all.deb kernel-tree-2.6.11_2.6.11-3_all.deb to pool/main/k/kernel-source-2.6.11/kernel-tree-2.6.11_2.6.11-3_all.deb Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#270376: PCMCIA Nic stops working after upgrading to 2.6.6/7/8
On Fri, 08 Apr 2005, Jefferson Cowart wrote: Looks like I may have spoken a bit too soon. The problem is partially fixed, but I'm still having a few problems. After the system was up I ran cardctl eject 0 to stop and let me remove my Ethernet card and I got the follow error: eth0: no IPv6 routers present irq 10: nobody cared! [c01297b5] __report_bad_irq+0x31/0x77 can you send the hexdump of the cardbus controller before and after the cardctl command on this patched 2.6.11 kernel: /proc/bus/pci/00/07.0 and /proc/bus/pci/00/07.1 thanks for your feedback. maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 08:31:22PM -0400, Raul Miller wrote: On Fri, Apr 08, 2005 at 07:34:00PM +0200, Adrian Bunk wrote: If Debian was at least consistent. Why has Debian a much more liberal interpretation of MP3 patent issues than RedHat? It's impossible to treat patents consistently. The U.S. patent office, at least, has granted patents on natural laws, on stuff that's already patented, on stuff with clear prior art, on trivial math operations and so on. Patents are being granted so quickly there's no way of even knowing what's patented. Or were you hoping that Debian would follow Red Hat's lead? Even RedHat with a stronger financial background than Debian considered the MP3 patents being serious enough to remove MP3 support. Yes, Debian can choose to put a higher risk on their distributors and mirrors - there's nothing wrong with this. Note that this is a respose to Josselin's statement: -- snip -- When there are several possible interpretations, you have to pick up the more conservative one, as it's not up to us to make the interpretation, but to a court. -- snip -- It's simply silly to be extremely picky on copyright issues while being extremely liberal on patent issues - the risk of a Debian distributor being sued for patent violations (no matter how the lawsuit might end) is definitely present. As for this particular patent, I'm not really sure what's being patented. ... Which one of the 23 patents they list do you call this particular patent? Raul cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#270898: initrd-tools: it's an old kernel bug
Package: initrd-tools Version: 0.1.77 Followup-For: Bug #270898 Today I experienced the same bug. I installed 3 years ago a woody server with the same cd with xfs support. It seems to be a kernel bug, because after downloading a new 2.4.30 kernel, compiling it and booting I've been able to install the package kernel-image-2.6-686 . I don't know exactly the bug, but the -a flag of the command cp called inside mkinitrd doesn't seems to work with old kernel with the xfs patch. You can try it copying something with the -a flag and the old kernel won't let you do it. With a newer one you'll be able. So, I think you can close the bug. :-) -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.9-1-k7-smp Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages initrd-tools depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii cpio 2.5-1.2GNU cpio -- a program to manage ar ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii dash 0.5.2-2The Debian Almquist Shell ii util-linux2.12-10Miscellaneous system utilities -- no debconf information -- Non c'è più forza nella normalità, c'è solo monotonia. signature.asc Description: Digital signature
Bug#303918: Patch to support IT8212 on-board RAID controller
Package: kernel-image-2.6.10-i386 Severity: wishlist Tags: patch Dear Debian Kernel Maintainers, Alan Cox has a patch against 2.6.10 that supports the IT 8212 RAID Controller, which is found on some motherboards. This patch (http://lkml.org/lkml/2004/12/28/79) applied with no problem against the Debian kernel sources. It just adds one extra source file that builds one extra module so there is no concern about code destabilization. I'm using this module on my system now. If you could include this in the debian sources and enable the module, I'd be very much in your debt. Thanks. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10it8212 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#303926: kernel-image-2.6.11-1-686: Loads IDE Modules permanently
Package: kernel-image-2.6.11-1-686 Version: 2.6.11-2 Severity: normal Not sure if this is a kernel bug or not... Would like to remove unused modules if possable -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (900, 'testing'), (100, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages kernel-image-2.6.11-1-686 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii initrd-tools 0.1.77 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Bug#301701: kernel-image-2.6.10-1-k7: System catatonic when tryingtowrite DVD or CD as user
please don't forget to cc your bug reports! On Sat, 09 Apr 2005, Nick Hill wrote: I have demonstrated this bug with a vanilla kernel.org kernel. I have found a similar blocking bug submitted on 20th February and appended a copy of the Debian bug. http://bugzilla.kernel.org/show_bug.cgi?id=4234 which version of cdrecord or growisofs package are you using? cant duplicate your problem with 2.6.11 and newer kernels. Given the severity of the bug, I am surprised it has survived two kernel versions. For me, 2,6.10 and 2.6.11 have incrementally added three serious/ critical bugs, and only solved an ISO9660 file system issue (where files 2Gb would confuse the driver). The field is open for better systems of kernel development management than what we are seeing with the official kernel. who are you to come up which such bad attitudes and to think you gonna go anywhere? -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#303926: kernel-image-2.6.11-1-686: Loads IDE Modules permanently
Processing commands for [EMAIL PROTECTED]: reassign 303926 initrd-tools Bug#303926: kernel-image-2.6.11-1-686: Loads IDE Modules permanently Bug reassigned from package `kernel-image-2.6.11-1-686' to `initrd-tools'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303926: kernel-image-2.6.11-1-686: Loads IDE Modules permanently
reassign 303926 initrd-tools thanks On Sat, 09 Apr 2005, Stuart Sheldon wrote: Not sure if this is a kernel bug or not... Would like to remove unused modules if possable it has to do with the reorganisation of the semi-broken modular ide patch, that debian carried around. upstream ide-dev looks like heading in a saner direction, but that's definetely a post linux-2.6.12 item. anyway initrd shouldn't load all ide drivers first. so reassigned, don't expect a too quick fix for that. regards maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303777: kernel-image: Bind9 from woody fails to start; capset failed: Operation not permitted
On Fri, 08 Apr 2005, [EMAIL PROTECTED] wrote: Package: kernel-image Version: 2.6.11-3 Severity: important Bind9 from Debian woody will not start when run with this kernel. It does work with kernel 2.6.10 and previous. as debian sarge will release with 2.6.8, it's not so much of a trouble it may be the selinux stuff, dont know that cpset module? #/etc/iniit.d/bind9 start Starting domain name service: namednamed: capset failed: Operation not permitted -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303550: (fwd) Re: Bug#303550: kernel-image-2.6.11-1-686: irq11 makes eth0 problems
- Forwarded message from Philippe Bourcier [EMAIL PROTECTED] - X-Original-To: [EMAIL PROTECTED] Date: Sat, 9 Apr 2005 20:51:37 +0200 From: Philippe Bourcier [EMAIL PROTECTED] To: maximilian attems [EMAIL PROTECTED] Subject: Re: Bug#303550: kernel-image-2.6.11-1-686: irq11 makes eth0 problems hi Maximilian, first, thanks a lot for looking to this problem On Fri, Apr 08, 2005 at 06:34:48PM +0200, maximilian attems wrote: tags 303550 moreinfo On Thu, 07 Apr 2005, Philippe BOURCIER wrote: Apr 6 19:54:47 ile kernel: Linux version 2.6.11-1-686 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-8)) #1 Sun Apr 3 06:20:48 EDT 2005 Apr 6 19:55:15 ile kernel: eth0: flipped to 10baseT Apr 6 19:55:19 ile kernel: irq 11: nobody cared! Apr 6 19:55:19 ile kernel: [c013242a] __report_bad_irq+0x2a/0xa0 Apr 6 19:55:19 ile kernel: [c0131ed0] handle_IRQ_event+0x30/0x70 Apr 6 19:55:19 ile kernel: [c0132530] note_interrupt+0x70/0xb0 Apr 6 19:55:19 ile kernel: [c0131ff0] __do_IRQ+0xe0/0xf0 Apr 6 19:55:19 ile kernel: [c0105279] do_IRQ+0x19/0x30 Apr 6 19:55:19 ile kernel: [c010391a] common_interrupt+0x1a/0x20 Apr 6 19:55:19 ile kernel: [c011cb6e] __do_softirq+0x2e/0x90 Apr 6 19:55:19 ile kernel: [c011cbf6] do_softirq+0x26/0x30 Apr 6 19:55:19 ile kernel: [c010527e] do_IRQ+0x1e/0x30 Apr 6 19:55:19 ile kernel: [c010391a] common_interrupt+0x1a/0x20 Apr 6 19:55:19 ile kernel: handlers: Apr 6 19:55:19 ile kernel: [c8cd1980] (usb_hcd_irq+0x0/0x70 [usbcore]) Apr 6 19:55:19 ile kernel: [c8cc48a0] (yenta_interrupt+0x0/0x40 [yenta_socket]) Apr 6 19:55:19 ile kernel: [c8cc48a0] (yenta_interrupt+0x0/0x40 [yenta_socket]) Apr 6 19:55:19 ile kernel: Disabling IRQ #11 Apr 6 19:55:19 ile kernel: eth0: interrupt(s) dropped! Apr 6 19:55:24 ile kernel: eth0: no IPv6 routers present sometimes, i got that one : Apr 9 19:45:29 ile kernel: Linux Kernel Card Services Apr 9 19:45:29 ile kernel: options: [pci] [cardbus] [pm] Apr 9 19:45:29 ile kernel: PCI: Found IRQ 11 for device :00:03.0 Apr 9 19:45:29 ile kernel: Yenta: CardBus bridge found at :00:03.0 [:] Apr 9 19:45:29 ile kernel: Yenta: Using CSCINT to route CSC interrupts to PCI Apr 9 19:45:29 ile kernel: Yenta: Routing CardBus interrupts to PCI Apr 9 19:45:29 ile kernel: Yenta TI: socket :00:03.0, mfunc 0xcba97543, devctl 0x62 Apr 9 19:45:29 ile kernel: irq 11: nobody cared! Apr 9 19:45:29 ile kernel: [c013242a] __report_bad_irq+0x2a/0xa0 Apr 9 19:45:29 ile kernel: [c0131ed0] handle_IRQ_event+0x30/0x70 Apr 9 19:45:29 ile kernel: [c0132530] note_interrupt+0x70/0xb0 Apr 9 19:45:29 ile kernel: [c0131ff0] __do_IRQ+0xe0/0xf0 Apr 9 19:45:29 ile kernel: [c0105279] do_IRQ+0x19/0x30 Apr 9 19:45:29 ile kernel: [c010391a] common_interrupt+0x1a/0x20 Apr 9 19:45:29 ile kernel: [c011cb6e] __do_softirq+0x2e/0x90 Apr 9 19:45:29 ile kernel: [c011cbf6] do_softirq+0x26/0x30 Apr 9 19:45:29 ile kernel: [c010527e] do_IRQ+0x1e/0x30 Apr 9 19:45:29 ile kernel: [c010391a] common_interrupt+0x1a/0x20 Apr 9 19:45:29 ile kernel: [c01bb294] pci_bus_write_config_word+0x54/0x60 Apr 9 19:45:29 ile kernel: [c8cc64db] yenta_probe_cb_irq+0x6b/0x130 [yenta_socket] Apr 9 19:45:29 ile kernel: [c0118507] printk+0x17/0x20 Apr 9 19:45:29 ile kernel: [c8cc5461] ti12xx_irqroute_func0+0x91/0x390 [yenta_socket] Apr 9 19:45:29 ile kernel: [c8cc5c3f] ti12xx_override+0xff/0x1b0 [yenta_socket] Apr 9 19:45:29 ile kernel: [c8cc5d7f] ti1250_override+0x8f/0xa0 [yenta_socket] Apr 9 19:45:29 ile kernel: [c8cc69a0] yenta_probe+0x220/0x250 [yenta_socket] Apr 9 19:45:29 ile kernel: [c01bf402] pci_device_probe_static+0x52/0x70 Apr 9 19:45:29 ile kernel: [c01bf45c] __pci_device_probe+0x3c/0x50 Apr 9 19:45:29 ile kernel: [c01bf49c] pci_device_probe+0x2c/0x50 Apr 9 19:45:29 ile kernel: [c0211a4f] driver_probe_device+0x2f/0x80 Apr 9 19:45:29 ile kernel: [c0211b9c] driver_attach+0x5c/0xa0 Apr 9 19:45:29 ile kernel: [c02120ed] bus_add_driver+0x9d/0xd0 Apr 9 19:45:29 ile kernel: [c021270f] driver_register+0x2f/0x40 Apr 9 19:45:29 ile kernel: [c01bf714] pci_register_driver+0x64/0x90 Apr 9 19:45:29 ile kernel: [c8c8300f] yenta_socket_init+0xf/0x11 [yenta_socket] Apr 9 19:45:29 ile kernel: [c012f6b2] sys_init_module+0x122/0x1b0 Apr 9 19:45:29 ile kernel: [c0102f33] syscall_call+0x7/0xb Apr 9 19:45:29 ile kernel: handlers: Apr 9 19:45:29 ile kernel: [c8cd1980] (usb_hcd_irq+0x0/0x70 [usbcore]) Apr 9 19:45:29 ile kernel: Disabling IRQ #11 Apr 9 19:45:29 ile kernel: Yenta TI: socket :00:03.0 probing PCI interrupt failed, trying to fix Apr 9 19:45:29 ile kernel: Yenta TI: socket :00:03.0 no PCI interrupts. Fish. Please report. Apr 9 19:45:29 ile kernel: Yenta: ISA IRQ mask 0x0690, PCI irq 0 Apr 9 19:45:29 ile kernel: Socket status: 3019 Apr 9 19:45:29 ile kernel: PCI: Found IRQ 11 for device :00:03.1 Apr 9 19:45:29 ile kernel: Yenta: CardBus bridge found at :00:03.1 [:] Apr
Re: Bug#297673: sis900: Unknown symbol crc32_le
Hi, make sure you havce the crc32 module compiled and then: $modprobe crc32 -James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303550: kernel-image-2.6.11-1-686: irq11 makes eth0 problems
please don't drop from cc the bug report. :) On Sat, 09 Apr 2005, Philippe Bourcier wrote: first, thanks a lot for looking to this problem ok, let's look if he can get nail that down. On Fri, Apr 08, 2005 at 06:34:48PM +0200, maximilian attems wrote: Apr 6 19:54:47 ile kernel: Linux version 2.6.11-1-686 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-8)) #1 Sun Apr 3 06:20:48 EDT 2005 Apr 6 19:55:15 ile kernel: eth0: flipped to 10baseT Apr 6 19:55:19 ile kernel: irq 11: nobody cared! well there is a longstanding bug for the texas instruments pcmcia bridge irq routing in current kernel sources since 2.6.6rc1, if you want more details about you can look at #270376 (yes scroll way down). short resume, current upstream fix is not yet perfect but seems to work for normal operations beside cardctl eject operations. could you tested the kernel-image at: http://charm.itp.tuwien.ac.at/~mattems/ (it's a 386 image, i'll post shortly a patched 686 there too). would be cool to know if that helps for you too, the other bug reporter has an PCI1220 bridge while yours is a PCI1225. please post after boot of aboves 2.6.11 kernel: * dmesg * hexdump /proc/bus/pci/00/03.0 * hexdump /proc/bus/pci/00/03.1 thanks for your feedback -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Grace period for kernel-source uploads
Hello, I think it would be really useful if whoever is planning the next kernel-source upload would give at least 24-hour advance warning by e-mailing debian-kernel that such upload is planned. That would give people a chance to review their patches, make last-minute additions and build a test kernel based on the new k-s. Just an idea, comments are welcome. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Grace period for kernel-source uploads
On Sat, 09 Apr 2005 16:12:57 -0400, Jurij Smakov wrote: Hello, I think it would be really useful if whoever is planning the next kernel-source upload would give at least 24-hour advance warning by e-mailing debian-kernel that such upload is planned. That would give people a chance to review their patches, make last-minute additions and build a test kernel based on the new k-s. Just an idea, comments are welcome. I'd rather people do kernel-source uploads when they're needed. One of the problems with architectures all using k-s is, attempting to coordinate a release that every arch is satisfied w/ is problematic. People get annoyed when their arch is ready to go, but they have to wait for some other arch. So, it's better to just release whenever. We have kernel-tree, which means kernel-image packages don't need to rebuild for every k-s release. The way this works in practice is; I get i386 in shape, release k-s 2.6.x-1. Svenl gets powerpc ready, and dannf gets ia64 ready (though they don't coordinate), and Sven releases k-s 2.6.x-2. Horms throws some security fixes in SVN; Joshk gets sparc ready, and releases k-s 2.6.x-3. Due to the security patches, other archs rebuild against 2.6.x-3. And so on. If people want to give advance notice of a k-s release, that's fine, but it shouldn't be a requirement. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Grace period for kernel-source uploads
On Sat, 9 Apr 2005, Andres Salomon wrote: The way this works in practice is; I get i386 in shape, release k-s 2.6.x-1. Svenl gets powerpc ready, and dannf gets ia64 ready (though they don't coordinate), and Sven releases k-s 2.6.x-2. Horms throws some security fixes in SVN; Joshk gets sparc ready, and releases k-s 2.6.x-3. Due to the security patches, other archs rebuild against 2.6.x-3. And so on. Don't you think that the way you described (and that's the way it works now) is the major reason behind the very long times it takes to push through the security updates on all architectures? That way it make take people a long time to make k-i even build against 2.6.x-3 due to broken arch-specific patches, missing/added kernel options, etc. I would rather proactively track the changes in k-s, making sure that new k-i may be built against it immediately. If people want to give advance notice of a k-s release, that's fine, but it shouldn't be a requirement. I am not saying that it should be a requirement, just something everyone can benefit from (especially in the case of ABI-breaking changes in k-s). Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
It's impossible to treat patents consistently. On Sat, Apr 09, 2005 at 04:38:15PM +0200, Adrian Bunk wrote: Even RedHat with a stronger financial background than Debian considered the MP3 patents being serious enough to remove MP3 support. It's silly to treat financial risk as being a one dimensional quantity. It could easily be that Red Hat decided that the mp3 patent owners would be going after people with deep pockets. If this is the risk model, Red Hat's risk would be much much higher than Debian's. Note that this is a respose to Josselin's statement: When there are several possible interpretations, you have to pick up the more conservative one, as it's not up to us to make the interpretation, but to a court. Sure, if you have several plausible interpretations, you pick the one you feel is likely to be the most important, and if all of them seem likely you pick the one that seems worst. But, ultimately, you can't treat software patents consistently. There's no reasonable way to do so. It's simply silly to be extremely picky on copyright issues while being extremely liberal on patent issues - the risk of a Debian distributor being sued for patent violations (no matter how the lawsuit might end) is definitely present. Anything to do with software patents is silly. Being liberal about software patents is silly. Being conservative about software patents is silly. Copyright, while far from perfect, can at least be reasoned about. As for this particular patent, I'm not really sure what's being patented. ... Which one of the 23 patents they list do you call this particular patent? What makes you think I'm sure about what's being patented in 22 of those patents? I should probably have said As for patent claims applying to mp3, ..., but the issue is thorny enough that even that might not have been accurate enough. But, treating this particular patent as a meta-syntactic variable should be adequate for you to understand what I was saying. Bottom line, though: softare patents generally make very little sense. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Grace period for kernel-source uploads
On Sat, 09 Apr 2005, Jurij Smakov wrote: Don't you think that the way you described (and that's the way it works now) is the major reason behind the very long times it takes to push through the security updates on all architectures? That way it make take people a long time to make k-i even build against 2.6.x-3 due to broken arch-specific patches, missing/added kernel options, etc. I would rather proactively track the changes in k-s, making sure that new k-i may be built against it immediately. disagreed, all the archs managed in the d-k svn got their updates steadily. problems are the trees outside of it as well d-i udebs relying on a stable abi, which is easily broken on many security fixes. I am not saying that it should be a requirement, just something everyone can benefit from (especially in the case of ABI-breaking changes in k-s). don't think so, agreed with dillinger that current way works. regads maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Grace period for kernel-source uploads
On Sat, 9 Apr 2005, maximilian attems wrote: disagreed, all the archs managed in the d-k svn got their updates steadily. problems are the trees outside of it as well d-i udebs relying on a stable abi, which is easily broken on many security fixes. Quite on the contrary, with the current way of doing things we are continuously in a state with a skew between k-i versions on different arches. As Anders described, every arch maintainer builds the k-i against there own arch-specific k-s upload, which causes sync problems whenever a complete rebuild on all arches is required. I believe, that ideally k-i for _all_ arches should be rebuilt after every k-s upload, and Sven is working on a single source package for all k-i images to implement exactly that. don't think so, agreed with dillinger that current way works. In the recent DPL campaign a lot of attention was focused on the lack of communication withing Debian. My proposal is one way to somewhat improve it within a kernel team, for what it's worth. If people insist on doing it the old way, fine with me. regads maks Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301701: kernel-image-2.6.10-1-k7: System catatonic when tryingtowrite DVD or CD as user
maximilian attems wrote: which version of cdrecord or growisofs package are you using? Both are listed in both the Debian and kernel.org bug along with plenty of other info. Cdrecord-Clone 2.01.01a01 * growisofs by [EMAIL PROTECTED], version 5.21 cant duplicate your problem with 2.6.11 and newer kernels. I have duplicated wthe bug with Debian 2.6.11-3 and Kernel.org 2.6.11.7. The bug occurs every time. I hit reset, boot into 2.6.9 then it works OK. Given the severity of the bug, I am surprised it has survived two kernel versions. For me, 2,6.10 and 2.6.11 have incrementally added three serious/ critical bugs, and only solved an ISO9660 file system issue (where files 2Gb would confuse the driver). The field is open for better systems of kernel development management than what we are seeing with the official kernel. who are you to come up which such bad attitudes and to think you gonna go anywhere? Max, a world where people can't declare their opinions and observations (where someone else may not agree with them) would be a bad place. This is what distinguishes the mediaeval dark ages. I don't think anyone should fall into the thinking the current process is perfect as that will block thinking of possible improvements. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303970: kernel-image-2.6.11-1-386: in /lib/modules, source - /home/dilinger/src/kernel/kernel-image/2.6.11-2/kernel-image-2.6.11-i386-2.6.11/install-386
Package: kernel-image-2.6.11-1-386 Version: 2.6.11-2 Severity: normal /lib/modules/2.6.11-1-386 as installed has the following symbolic link: source - /home/dilinger/src/kernel/kernel-image/2.6.11-2/kernel-image-2.6.11-i386-2.6.11/install-386 -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i586) Kernel: Linux 2.6.11-1-386 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages kernel-image-2.6.11-1-386 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities ii initrd-tools 0.1.77 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295422: e2fsprogs for Sarge
On Fri, Apr 08, 2005 at 02:36:58PM +0900, Horms wrote: Hi Ted, It seems that I missunderstood the preferences expressed by Steve Langasek in my discussions with him. As it turns out he feels that it would be best to get 0.37-2 ready, as 0.37-1 is currently in sarge and has been beaten upon by users quite a bit. This should mittigate most of the need for review. And hopefully make your life a bit easier too. OK, I've just uploaded e2fsprogs 1.37-2. It is more than just the IA-64 core dump fix, but they are all extremely low-risk bugfixes: * Fix filefrag so that it works non ext2/3 filesystems again. (Closes: #303509) * Make sure we include stdlib.h to fix a core dump bug in mke2fs on the IA64 architecture (or other platforms where sizeof(ptr) sizeof(int)) (Closes: #302200) * Add missing return values so that we don't return garbage in certain error cases in ext2fs_write_new_inode() and ext2fs_read_int_block(). * Fix minor spelling typo in the mke2fs man page * Avoid doing the LOW_DTIME checks if the superblock last mount time indicates that the system clock may not be set correctly. * Add further paranoia checks to the blkid, ext2fs, and ss libraries to make them safe to call from setuid or setgid applications. The diff file is quite small and easy to sanity check. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277942: ipv6 issues on sparc - can't reproduce
Hi Wouter, I have failed to reproduce the bug 277942 (oops/panic when loading or running with ipv6 module) with a recent kernel kernel-image-2.4.27-2-sparc64 version 2.4.27-9 (currently in sid). My machine is Ultra5 with Happy Meal network card as well (TP connection though). Could you please check that the problem is still present for you? Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Grace period for kernel-source uploads
On Sat, 09 Apr 2005 16:55:23 -0400, Jurij Smakov wrote: On Sat, 9 Apr 2005, Andres Salomon wrote: The way this works in practice is; I get i386 in shape, release k-s 2.6.x-1. Svenl gets powerpc ready, and dannf gets ia64 ready (though they don't coordinate), and Sven releases k-s 2.6.x-2. Horms throws some security fixes in SVN; Joshk gets sparc ready, and releases k-s 2.6.x-3. Due to the security patches, other archs rebuild against 2.6.x-3. And so on. Don't you think that the way you described (and that's the way it works now) is the major reason behind the very long times it takes to push through the security updates on all architectures? That way it make take Not at all. Security updates would still take a long time if you had to announce a k-s release, wait for 8 or so architectures to say ok, we're ready to go!, do a release, and then wait for their uploads. What causes this process to take so long is the fact that kernels aren't built for every k-s upgrade; that should be fixed once we have k-s generating images. people a long time to make k-i even build against 2.6.x-3 due to broken arch-specific patches, missing/added kernel options, etc. I would rather proactively track the changes in k-s, making sure that new k-i may be built against it immediately. That should always be the case, unless a security update affects something on your architecture, or you screw up something on your arch w/ a prior patch. :) If people want to give advance notice of a k-s release, that's fine, but it shouldn't be a requirement. I am not saying that it should be a requirement, just something everyone can benefit from (especially in the case of ABI-breaking changes in k-s). ABI-breaking changes are a special case; unfortunately, we don't have any infrastructure in place to handle that right now. ABI breaking changes should definitely be given more consideration, and announced on d-k so that arch kernel maintainers know to bump the ABINAME on their packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
