Bug#329880: initrd-tools: unnecessarily loads ide-scsi module
On Sat, Sep 24, 2005 at 12:12:27AM -0400, Ben Aisen wrote: Package: initrd-tools Version: 0.1.82 Severity: normal Tags: patch *** Please type your report below this line *** The ide-scsi module isn't used to access SCSI drives, but mkinitrd generates initrd images that load it at boot time if the host system has a newer kernel and an SCSI (or SATA) root partition. Notice that for newer kernels (and i suppose you mean 2.6.12 and up now in testing/unstable), initrd-tools is obsoleted and replaced by yaird (right now in the archive, and which works just fine) or initramfs-tools (to be uploaded). Give yaird a try and tell us what you think of it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329877: Error when trying to load speedstep-centrino module.
On Sat, Sep 24, 2005 at 04:22:24AM +0200, Guillaume Delacour wrote: Package: kernel-image-2.6.8-2-686 Version: 2.6.8-16 Severity: normal When trying to load the speedstep-centrino, i have the following errors : # modprobe speedstep-centrino FATAL: Error inserting speedstep_centrino (/lib/modules/2.6.8-2-686/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko): No such device # dmesg ... speedstep-centrino: found unsupported CPU with Enhanced SpeedStep: send /proc/cpuinfo to Jeremy Fitzhardinge [EMAIL PROTECTED] but this is a centrino processor, on this laptop : # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.60GHz stepping: 6 [...] I try to compile a kernel with officials sources (http://kernel.org), and speedstep-centrino seems to works fine. In fact your cpu is supported in recent kernels. Which one are you building from kernel.org? [...] Maybe i have to send my /proc/cpuinfo to the developper of the module, Jeremy Fitzhardinge, but i think the errors is in the precompiled kernel package. right, the problem is just your cpu is too recent for the 2.6.8 kernel I'm sure at least 2.6.10 supports it, I don't have earlier kernels here to look into :) -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Observation re third parties supporting Debian kernels
On Sat, Sep 24, 2005 at 07:02:57PM +1000, Andrew Pollock wrote: Hi, I attended a product briefing at Computer Associates on Thursday, and one of the products that was discussed more than demonstrated was something called eTrust Access Control[1], which, from my interpretation, sounds like it achieves something similar to what SE Linux probably does. That's not really the point of this email though. And why should the kernel team support propritary software, especially where a better free alternative exists already? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329880: initrd-tools: unnecessarily loads ide-scsi module
On Sat, 24 Sep 2005, Sven Luther wrote: On Sat, Sep 24, 2005 at 12:12:27AM -0400, Ben Aisen wrote: Package: initrd-tools Version: 0.1.82 Severity: normal Tags: patch *** Please type your report below this line *** The ide-scsi module isn't used to access SCSI drives, but mkinitrd generates initrd images that load it at boot time if the host system has a newer kernel and an SCSI (or SATA) root partition. Notice that for newer kernels (and i suppose you mean 2.6.12 and up now in testing/unstable), initrd-tools is obsoleted and replaced by yaird (right now in the archive, and which works just fine) or initramfs-tools (to be uploaded). Give yaird a try and tell us what you think of it. initramfs-tools is in NEW - http://ftp-master.debian.org/new.html should go in really soon. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I can't build Modules.debs with linuxheaders 2.6.12-1-k7
Am Freitag, 23. September 2005 20:06 schrieb Sébastien Platel: I have the same problem trying to compile some modules from linux-headers-2.6.12-1-686, here is my final output: regards SP A possible solutions is I compile my own kernel-image and kernel-headers. make-kpkg --stem linux --initrd --append-to-version -0-k7 --revision 2.6.13-3 debian make-kpkg --stem linux --initrd --append-to-version -0-k7 --revision 2.6.13-3 kernel-image kernel-headers Important is the first line. I have a debian directory without the first line when I compile a kenel and headers , but the contents is different. - - with best regards from Dortmund Matthias E. Popp ___ Was denken Sie über E-Mail? Wir hören auf Ihre Meinung: http://surveylink.yahoo.com/wix/p0379378.aspx
Bug#329877: Error when trying to load speedstep-centrino module.
[Restored the original Cc list, please keep the @bugs.debian.org] On Sat, Sep 24, 2005 at 02:43:52PM +0200, Guillaume Delacour wrote: I tryed with a 2.6.11.9 kernel, but i run debian stable, and i really want to run debian stable and kernel-image-2.6.8-2-686. Do i have to upgrade to testing and install a newer kernel ? You could still try the acpi-cpufreq driver (cross your fingers!). Another option is just to run a newer kernel that the one available in sarge by compiling your own (as it seems you already did) and stay with sarge, but you won't benefit the eventual security updates. hth -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329982: kernel-image-2.4.27-2-686: removing usb 2.0 cardbus card kills keyboard
Package: kernel-image-2.4.27-2-686 Version: 2.4.27-11 Severity: normal I put a usb 2.0 cardbus card into my laptop then removed it. After doing this the keyboard was ignored except for functions performed by the apm bios. After shutting down the system remotely, it functioned properly. This is a Dell Insiperon 8200 laptop that did not get along with a 2.6 kernel when I tried it. Messages in syslog relating to this: Sep 24 13:58:19 quaff kernel: PCI: Enabling device 07:00.0 ( - 0002) Sep 24 13:58:19 quaff kernel: PCI: Enabling device 07:00.1 ( - 0002) Sep 24 13:58:19 quaff kernel: PCI: Enabling device 07:00.2 ( - 0002) Sep 24 13:58:20 quaff insmod: insmod: a module named ehci-hcd already exists Sep 24 13:58:20 quaff insmod: insmod: insmod ehci-hcd failed Sep 24 13:58:20 quaff insmod: insmod: a module named ehci-hcd already exists Sep 24 13:58:20 quaff insmod: insmod: insmod ehci-hcd failed Sep 24 13:58:20 quaff insmod: insmod: a module named usb-ohci already exists Sep 24 13:58:20 quaff insmod: insmod: insmod usb-ohci failed Sep 24 13:58:20 quaff insmod: insmod: a module named usb-ohci already exists Sep 24 13:58:20 quaff insmod: insmod: insmod usb-ohci failed Sep 24 13:58:21 quaff insmod: insmod: a module named pci_hotplug already exists Sep 24 13:58:21 quaff insmod: insmod: insmod shpchp failed Sep 24 13:58:21 quaff insmod: insmod: a module named pci_hotplug already exists Sep 24 13:58:21 quaff insmod: insmod: insmod shpchp failed Sep 24 13:58:21 quaff kernel: shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x1001 Sep 24 13:58:21 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/hotplug/shpchp.o: init_module: Operation not permitted Sep 24 13:58:21 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/hotplug/shpchp.o: insmod shpchp failed Sep 24 13:58:22 quaff kernel: pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x1001 Sep 24 13:58:22 quaff kernel: pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x1001 Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/hotplug/pciehp.o: init_module: Operation not permitted Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/hotplug/pciehp.o: insmod pciehp failed Sep 24 13:58:22 quaff kernel: pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x1001 Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/hotplug/pciehp.o: init_module: Operation not permitted Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/hotplug/pciehp.o: insmod pciehp failed Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/hotplug/pciehp.o: init_module: Operation not permitted Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/hotplug/pciehp.o: insmod pciehp failed Sep 24 13:58:22 quaff kernel: hw_random: misc device register failed Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/char/hw_random.o: init_module: Device or resource busy Sep 24 13:58:22 quaff kernel: hw_random: misc device register failed Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/char/hw_random.o: init_module: Device or resource busy Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/char/hw_random.o: insmod hw_random failed Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/char/hw_random.o: insmod hw_random failed Sep 24 13:58:22 quaff kernel: hw_random: misc device register failed Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/char/hw_random.o: init_module: Device or resource busy Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/char/hw_random.o: insmod hw_random failed Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/usb/host/uhci.o: init_module: No such device Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/usb/host/uhci.o: insmod uhci failed Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/usb/host/uhci.o: init_module: No such device Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/usb/host/uhci.o: insmod uhci failed Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/usb/host/uhci.o: init_module: No such device Sep 24 13:58:22 quaff insmod: /lib/modules/2.4.27-2-686/kernel/drivers/usb/host/uhci.o: insmod uhci failed Sep 24 14:02:35 quaff kernel: usb-ohci.c: 07:00.0 device removed! Sep 24 14:02:35 quaff kernel: usb-ohci.c: 07:00.1 device removed! Sep 24 14:02:35 quaff kernel: usb-ohci.c: 07:00.0 device removed! Sep 24 14:02:35 quaff kernel: usb-ohci.c: 07:00.1 device removed! Sep 24 14:02:35 quaff kernel: usb-ohci.c: 07:00.0 device removed! Sep 24 14:02:35 quaff kernel: usb-ohci.c: 07:00.1 device removed! Sep 24 14:02:35 quaff kernel: usb-ohci.c: 07:00.0 device removed! Sep 24 14:02:35 quaff kernel: usb-ohci.c: 07:00.1 device removed! Sep 24 14:02:35 quaff kernel: Unable to handle kernel paging request
Bug#329989: snd_usb_audio unknown symbols
Package: linux-image-2.6.12-1-686-smp Version: 2.6.12-7 usb audio worked in -6... but as of -7 i'm getting this in dmesg when the module is inserted: snd_usb_audio: Unknown symbol __compound_literal.170 snd_usb_audio: Unknown symbol __compound_literal.89 snd_usb_audio: Unknown symbol __compound_literal.173 snd_usb_audio: Unknown symbol __compound_literal.112 snd_usb_audio: Unknown symbol __compound_literal.110 snd_usb_audio: Unknown symbol __compound_literal.150 snd_usb_audio: Unknown symbol __compound_literal.102 snd_usb_audio: Unknown symbol __compound_literal.114 snd_usb_audio: Unknown symbol __compound_literal.158 snd_usb_audio: Unknown symbol __compound_literal.120 snd_usb_audio: Unknown symbol __compound_literal.79 snd_usb_audio: Unknown symbol __compound_literal.166 ... goes on for a while... my wild guess is an inlining-related change in gcc-4.0. but that's just a wild guess. -dean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329879: Alloc Virtual Mem error
retitle 329879 [sparc] Alloc Virtual Mem error tags 329879 moreinfo thanks Hi, Please provide some more information: 1. Exactly what version of the kernel packages you are using (you have provided the name of the package, but not the version). 2. What network card is that and what driver it uses? 3. Please post the relevant fragment of dmesg output. Also, have in mind that 2.6.12 kernels are not really designed to run on etch (even though in most cases they would). It would be great if you could confirm that the bug is still present when running 2.6.12 on sid. 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]
Processed: Re: Alloc Virtual Mem error
Processing commands for [EMAIL PROTECTED]: retitle 329879 [sparc] Alloc Virtual Mem error Bug#329879: Alloc Virtual Mem error Changed Bug title. tags 329879 moreinfo Bug#329879: [sparc] Alloc Virtual Mem error There were no tags set. Tags added: moreinfo 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]
Re: Observation re third parties supporting Debian kernels
On Sat, Sep 24, 2005 at 12:58:40PM +0200, Christoph Hellwig wrote: On Sat, Sep 24, 2005 at 07:02:57PM +1000, Andrew Pollock wrote: Hi, I attended a product briefing at Computer Associates on Thursday, and one of the products that was discussed more than demonstrated was something called eTrust Access Control[1], which, from my interpretation, sounds like it achieves something similar to what SE Linux probably does. That's not really the point of this email though. And why should the kernel team support propritary software, especially where a better free alternative exists already? That's the attitude I feared I'd find, but was hoping I wouldn't... In this particular instance, without being intimately familiar with CA's product, I can't readily comment on how it stacks up with SE Linux, it just *sounds* SE Linuxish from the description, and from how it was described at the product briefing. As I said, the nature of the software wasn't the point of this email, it could be doing something for which there isn't a comparable free product out there. At the end of the day, I think we need to accept that we live in a mixed world of free and proprietary software. If the kernel team want to thumb their noses at the proprietary, then it may come at the cost of lost installations of Debian, which I think is a bad thing. Taking the example of where I previously worked. I'd deployed a fairly nice to manage Internet gateway infrastructure using Debian. Due to a bit of nepotism, and general higher-up management decisions, we had CA Unicenter foisted on us. We didn't get a say in it. Of course, it was supposed to do all this fandanged stuff that we already had Nagios doing, but management wanted to to be able to name drop some commercial software to clients, rather than a mish-mash of this open source stuff. We're not able to fight a massive management reeducation/attitude readjustment battle, so we have to accept what we're given. The problem is, when said commercial software starts mandating what Linux distribution(s) it'll support, if the management push is for that commercial software, then if it doesn't support Debian, then Debian's going to be the loser, not the hundreds of thousands of dollars spent on the commercial software. So it doesn't matter that those of us that have to manage the Linux boxes happen to firmly believe that Debian's got a lower cost of ownership in terms of management than say Red Hat, management just see it as we want this $100,000 piece of software, and your Linux distribution choice is blocking that implementation. I'm sure I'm not the only person who's been in this situation. So, if you don't want to try and ease that pain, maintain the attitude you're currently expressing, but I don't believe it is in the best interests of our users to be so exclusive. regards Andrew signature.asc Description: Digital signature
Re: Observation re third parties supporting Debian kernels
On Sat, Sep 24, 2005 at 12:58:39PM +0200, Sven Luther wrote: On Sat, Sep 24, 2005 at 07:02:57PM +1000, Andrew Pollock wrote: Hi, I attended a product briefing at Computer Associates on Thursday, and one of the products that was discussed more than demonstrated was something called eTrust Access Control[1], which, from my interpretation, sounds like it achieves something similar to what SE Linux probably does. That's not really the point of this email though. I asked one of the engineering types about their Linux support for this product during one of the breaks. It can enforce a policy on Windows, a few commercial Unix variants, and on Linux. When I pressed the engineer on what Linux distros were supported, it was just RedHat Enterprise Linux. He did mention that they'd looked into supporting Debian, but slammed the lid back down on it after they had discovered (and I'm paraphrasing) multiple kernels with the same version number. Seems like uninformed non-sense, but then maybe due to the previous messy situation. I think these guys are lying when speakign about linux support anyway, and only mean linux/x86 anyway. Possibly (uninformed). I didn't go into details with the guy. I don't even know what version of Debian they'd looked at, and yes, Linux/x86 is absolutely correct. These guys are coming from the world where there were only commercial Unices, so in that case, there'd be one commercial Unix per CPU architecture, so the model of distributing binaries would work. I'm not suggesting that it's a good model... We provide the linux-headers apckage to make it as easy to build external modules against those kernels as possible, so it should be no real problem. As I said to the guy from CA, they're probably best doing something like what nVidia do with their binary video driver - compile a shim against the installed kernel's headers, and have their binary crap talk to that, but I don't know enough about their product... I agree that the pre-2.6.12 situation was messy, but the new common infrastructure should be no major problem for those guys. Well it'd be interesting to see if either party was interested in talking about it... regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
