Yaird mailinglist created! (Was: Plugins feature for yaird.)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 15 Nov 2005 08:08:51 +0100 Sven Luther [EMAIL PROTECTED] wrote: Once Jonas sets up the alioth account he has been speaking of, he can ask for a TLA archive there, Even better: Let's use the newly created mailinglist [EMAIL PROTECTED] for discussions like this! I have finally found time to create the yaird project at Alioth, and created the above mailinglist. A few people that have showed special interest in yaird development has been explicitly invited to join the new mailinglist - others are quite welcome too: http://lists.alioth.debian.org/mailman/listinfo/yaird-devel I will change Maintainer field on next yaird release. Members of the kernel team are very welcome to join the yaird development team if interested - as is everyone else! Let's no longer cross-post yaird-specific stuff to several already quite busy lists. Regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDefUtn7DbMsAkQLgRAkJUAJ461AY8r66gkgOCfqGZVHieCwzpDwCgiq31 B1fd140hohpaPU1cwVJdbDE= =bxLc -END PGP SIGNATURE-
Re: Plugins feature for yaird.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 15 Nov 2005 02:18:14 +0100 Erik van Konijnenburg [EMAIL PROTECTED] wrote: On Sat, Nov 12, 2005 at 11:55:37AM +0100, Marco Amadori wrote: Another question, could you use already setup svn for yaird? there is already a yaird subversion repo in d-i alioth svn. The quickest way to make a repository available would be for me to mirror the TLA archive; this has zero information loss due to migration, so it's easy to switch to something better once that becomes available. However, the repository is only interesting as a communication medium, publishing the TLA makes only sense if you can use the format. Please let me know if you have any use for access to a TLA or bazaar archive; otherwise we'll have to look at SVN. FYI: I have responded to this on the [EMAIL PROTECTED] mailinglist: http://lists.alioth.debian.org/pipermail/yaird-devel/2005-November/00.html - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDefxGn7DbMsAkQLgRAuCYAKCcmEv3ByRquacha7kAwkMFjFcs8gCffbru qLvBUKKDQLtkKx3aS/IUtX8= =te6R -END PGP SIGNATURE-
Re: [D-I] Supporting 2.6.14 kernels in base-installer
On Tuesday 15 November 2005 13:23, Sven Luther wrote: Jonas, does it actually know how to look into /target/etc/fstab and not /etc/fstab ? This of course is a completely irrelevant question as d-i runs the initrd generators in a chroot on /target. So, yes, effectively it _does_ look in /target/etc/fstab. pgp5glKhOdDru.pgp Description: PGP signature
Bug#339327: linux-2.6: don't display lilo-related messages unless lilo is installed
reassign 339327 kernel-package severity 339327 wishlist merge 336927 339327 thanks * Sean Finney [EMAIL PROTECTED] [2005-11-15 15:44]: The link /vmlinuz.old is a damaged link Removing symbolic link vmlinuz.old This is the same as my #336927, fixed in experimental by not mentioning the boot loader at all. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#339327: linux-2.6: don't display lilo-related messages unless lilo is installed
Processing commands for [EMAIL PROTECTED]: reassign 339327 kernel-package Bug#339327: linux-2.6: don't display lilo-related messages unless lilo is installed Bug reassigned from package `linux-2.6' to `kernel-package'. severity 339327 wishlist Bug#339327: linux-2.6: don't display lilo-related messages unless lilo is installed Severity set to `wishlist'. merge 336927 339327 Bug#336927: kernel/image.postinst should mention GRUB Bug#339327: linux-2.6: don't display lilo-related messages unless lilo is installed Merged 336927 339327. 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]
Note about unfortunate message from linux-image
Hi! I'm not reporting this as bug, because I think I've read this is fixed in the kernel-package in experimental anyway. Just in case it's not fixed... The bug is that linux-image complains about a possible previous install of the kernel, probably just because the linux-headers that were unpacked before, but in the same apt-get call, put the build symlink in /lib/modules/2.6.14-2/. Willi typescript Description: Binary data
Re: [D-I] Supporting 2.6.14 kernels in base-installer
On Tue, Nov 15, 2005 at 05:14:50PM +0100, Frans Pop wrote: On Tuesday 15 November 2005 13:23, Sven Luther wrote: Jonas, does it actually know how to look into /target/etc/fstab and not /etc/fstab ? This of course is a completely irrelevant question as d-i runs the initrd generators in a chroot on /target. So, yes, effectively it _does_ look in /target/etc/fstab. Ah, of course, well i just wanted to make sure we didn't overlook something. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336392: Acknowledgement (linux-image-2.6.14-1-686: 2.6.14 doesn't boot after dist-upgrade from 2.6.12)
Erik van Konijnenburg wrote: If you have room to experiment with explicitly putting the missing module on the image, please do; I would like to include the resulting knowledge in the readme. MODULE BusLogic did the trick. :) Newer versions of VMware use LSI Logic by default so it didn't affect all VMware installations. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339365: initramfs-tools: fails with recent udev versions
Package: initramfs-tools Severity: important With the recent udev version (0.074-3), /sbin/udevsynthesize tries to run /lib/udev/udevsynthesize if the kernel is a recent version. This fails as /lib/udev/* is not copied to the initramfs image meaning that the boot fails. Re, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339371: kernel-image-2.6.8-2-k7: kernel panic with PREEMPT
Package: kernel-image-2.6.8-2-k7 Version: 2.6.8-16 Severity: important I am not a kernel guru. I found this machine blocked and I reset it. This is its syslog. Bye, Giuseppe -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kernel-image-2.6.8-2-k7 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii initrd-tools 0.1.81.1 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo -- no debconf information Nov 15 16:55:04 casa kernel: invalid operand: [#1] Nov 15 16:55:04 casa kernel: PREEMPT Nov 15 16:55:04 casa kernel: Modules linked in: vmnet vmmon nfsd exportfs nfs lockd sunrpc ipt_MASQUERADE ipt_REDIRECT iptable_nat ip_conntrack ipt_limit iptable_filter ip_tables af_packet ipv6 joydev snd_via82xx snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore aic79xx pciehp ext2 vfat fat capability commoncap ext3 jbd mbcache ppp_deflate zlib_deflate bsd_comp lp ppp_async ppp_generic slhc crc_ccitt st parport_pc parport floppy pcspkr rtc i2c_viapro i2c_core 8139cp shpchp pci_hotplug amd64_agp agpgart usblp usbhid ehci_hcd eth1394 uhci_hcd 8139too mii sk98lin ohci1394 ieee1394 tsdev mousedev evdev psmouse ide_cd cdrom sata_via sata_promise libata usb_storage usbcore unix fbcon font vesafb cfbcopyarea cfbimgblt cfbfillrect xfs dm_mod sd_mod sg aic7xxx scsi_mod ide_generic via82cxxx ide_disk ide_core raid1 md Nov 15 16:55:04 casa kernel: CPU:0 Nov 15 16:55:04 casa kernel: EIP:0060:[eligible_child+3/240]Tainted: P Nov 15 16:55:04 casa kernel: EFLAGS: 00010292 (2.6.8-2-k7) Nov 15 16:55:04 casa kernel: EIP is at eligible_child+0x3/0xf0 Nov 15 16:55:04 casa kernel: eax: 0003 ebx: e0e752a0 ecx: cbc9a000 edx: Nov 15 16:55:04 casa kernel: esi: cba679f0 edi: e0e75340 ebp: cba67a88 esp: cbc9bf38 Nov 15 16:55:04 casa kernel: ds: 007b es: 007b ss: 0068 Nov 15 16:55:04 casa kernel: Process apache2 (pid: 14992, threadinfo=cbc9a000 task=cba679f0) Nov 15 16:55:04 casa kernel: Stack: 0001 cbc9bf70 c011efb5 0003 e0e752a0 cbc9a000 Nov 15 16:55:04 casa kernel: cba679f0 c0118aa0 cbc9bf8c Nov 15 16:55:04 casa kernel: cba679f0 c0118aa0 cba67b3c cba67b3c f76d8540 f76d8540 Nov 15 16:55:04 casa kernel: Call Trace: Nov 15 16:55:04 casa kernel: [sys_wait4+197/624] sys_wait4+0xc5/0x270 Nov 15 16:55:04 casa kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 Nov 15 16:55:04 casa kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 Nov 15 16:55:04 casa kernel: [sys_waitpid+39/43] sys_waitpid+0x27/0x2b Nov 15 16:55:04 casa kernel: [syscall_call+7/11] syscall_call+0x7/0xb Nov 15 16:55:04 casa kernel: Code: 8b 54 24 0c 89 5c 24 04 8b 4c 24 14 8b 5c 24 10 85 d2 0f 8e Nov 15 16:55:04 casa kernel: 6note: apache2[14992] exited with preempt_count 1 Nov 15 16:55:04 casa kernel: invalid operand: [#2] Nov 15 16:55:04 casa kernel: PREEMPT Nov 15 16:55:04 casa kernel: Modules linked in: vmnet vmmon nfsd exportfs nfs lockd sunrpc ipt_MASQUERADE ipt_REDIRECT iptable_nat ip_conntrack ipt_limit iptable_filter ip_tables af_packet ipv6 joydev snd_via82xx snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore aic79xx pciehp ext2 vfat fat capability commoncap ext3 jbd mbcache ppp_deflate zlib_deflate bsd_comp lp ppp_async ppp_generic slhc crc_ccitt st parport_pc parport floppy pcspkr rtc i2c_viapro i2c_core 8139cp shpchp pci_hotplug amd64_agp agpgart usblp usbhid ehci_hcd eth1394 uhci_hcd 8139too mii sk98lin ohci1394 ieee1394 tsdev mousedev evdev psmouse ide_cd cdrom sata_via sata_promise libata usb_storage usbcore unix fbcon font vesafb cfbcopyarea cfbimgblt cfbfillrect xfs dm_mod sd_mod sg aic7xxx scsi_mod ide_generic via82cxxx ide_disk ide_core raid1 md Nov 15 16:55:04 casa kernel: CPU:0 Nov 15 16:55:04 casa kernel: EIP:0060:[eligible_child+3/240]Tainted: P Nov 15 16:55:04 casa kernel: EFLAGS: 00010292 (2.6.8-2-k7) Nov 15 16:55:04 casa kernel: EIP is at eligible_child+0x3/0xf0 Nov 15 16:55:04 casa kernel: eax: 0001 ebx: e36fa0b0 ecx: e3696000 edx: Nov 15 16:55:04 casa kernel: esi: e352e600 edi: e36fa150 ebp: e352e698 esp: e3697f38 Nov 15 16:55:04 casa kernel: ds: 007b es: 007b ss: 0068 Nov 15 16:55:04 casa kernel: Process apache-ssl (pid: 6351, threadinfo=e3696000 task=e352e600) Nov 15 16:55:04 casa kernel: Stack: 0004 e3697f70 c011efb5 0001 e36fa0b0 e3696000 Nov 15 16:55:04 casa kernel: e352e600 c0118aa0 e3697f8c
2.6.14 kernel udebs and d-i
Thought I'd document the process of updating d-i's kernel udebs from 2.6.12 to 2.6.14, since there's been various speculation about how automatable this is. 1. Installed 2.6.14 kernel deb. 2. Ran find in the old and new kernel modules directories and diffed the list to find added/removed modules. 3. New crypto, acpi hotkey, drm, char, watchdog modules generally not relevant to d-i, skipped. 4. Two new firmware modules, dcdbas and dell_rbu. Looked at the source to see what the firmware was used by, looks not relevant for d-i. 5. Skipped new hwmon set of drivers after verifying they weren't useful in installation. 6. Skipped i2c changes, since noone has asked for any i2c stuff in d-i yet. 7. ide/pci/it821x is new, it's a new pci ide controller. Added to list in kernel-wedge. Verified that hw-detect will find and load it. 8. Skipped infiniband changes, since nooone has asked for that in d-i yet. 9. Skipped gameport driver removal, not relevant. 10. md.ko is renamed to md-mod.ko. Updated kernel-wedge to include whichever is available. Checked d-i tree for instances of modprobe md and fixed them to try both. Cursed the %$(#)@(# gratuitous module renaming squad some more. 11. Skipped media/dvb, media/video, not relevant for d-i. 12. Reviewed the new split mpt* modules. Got pretty confused and chatted with hch to sort it out. Added all three new modules. 13. Skipped mtd changes since d-i doesn't need it. 14. de600/de620 nic drivers are gone from binary kernel package (but not source), made them optional in linux-kernel-di-i386-2.6 modules list. 15. atp nic driver is also removed, but d-i didn't include it before for some reason, so no change needed. 16. Looked at the sun cassini nic card .. not quite sure why it's in the i386 kernel since some docs I find online seems to suggest it only works with Sun HW, but assumed the kernel team has a reason and added it to list. 17. Looked at new cxgb and added to nic-extra-modules. 18. Looked at the new drivers/net/phy/ stuff, trying to decide whether to include the non-generic phy drivers (deps will pull in the generic phy support). Unsure, but left it out for now, since AFAIK nothing in d-i would load these modules. 19. Added sis190, skge, uli526x nic modules. 20. Hostap is in this version of the kernel.. Left out for now even though I love this driver, since AFAIK other existing drivers should suffice for installation. Double-checked this in modules.pcimap, and indeed no pci ids are uniquely supported by hostap. 21. Skipped adding ipw2100 and ipw2200 since they appear to need firmware that is not included. 22. Skipped the orinoco_nortel module, seems very edge case. 23. Skipped the spectrum_cs module since it needs firmware and special utilities. 24. megaraid is removed (renamed to megaraid_mbox), so made kernel-wedge aware of that. Also, added megaraid_sas. 26. Looked at raid_class's documentation which is in its entirity, Provides RAID. Blinked in puzzlement. Asked on irc. Went on to the next module. 27. Added sata_mv, yay, more sata. 28. Skipped new serial board drivers. 29. Skipped usb atm, audio, misc, and input changes, none appicable. 30. Skipped new usb/host/isp116x-hcd module, for now, since I don't know if it's common enough to include and d-i doesn't try to load it with te other hcd module. 31. Skipped all the usb nic modules since once of d-i's blind spots is support for any usb network hardware. 32. Noticed that this kernel drops support for modular vesafb and might break d-i. Oh well.. 33. Skipped 1-wire bus stuff 34. Skipped plan 9 filesystem support, we'll get bug reports if someone needs it. 35. Skipped fuse, not applicable (for now?) 36. Skipped relayfs, no applicable. 37. Looked over new kernel lib modules and etc, including the new generic ieee80211 modules. 38. Skipped netfilter and other tcp stuff. 39. Skipped sound, security, and schedulers, d-i needs none of them. 40. Committed the changes, built and installed new kernel-wedge. 41. Did a test build of linux-kernel-di-i386-2.6. Got a successful build after four tries. Had to adjust the dependencies of pcmcia-modules to include firmwre-modules and make some other changes I'd missed. 42. Copied udebs to loacaludebs, updated config/i386.cfg to use the new kernel and ran a make all_rebuild to make sure d-i still built. -- see shy jo signature.asc Description: Digital signature
Bug#328534: Adaptec 2005S Hangs with current experiemental 2.6.13-686-smp kernel
Sven Luther wrote: On Sun, Nov 13, 2005 at 07:01:28PM -0800, wolftales wrote: Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 13 Nov 2005 12:38:35 -0800 Wolftales [EMAIL PROTECTED] wrote: I had no luck running this with yaird as I showed below. Do I understand correctly that your running kernel is 2.4.27? If so, then you can't install yaird as it requires sysfs on the running kernel. To install using yaird you must first install and boot a kernel between 2.6.8 (oldest kernel supported by yaird) and 2.6.12 (newest kernel supported by initrd-tools). - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDd+3Dn7DbMsAkQLgRAsa1AJ4vQYbOaWfe4d8EW0b+3uJILCnPEgCfTBAs n/b+RK0yVDQJFKaop9A5oAg= =OBAT -END PGP SIGNATURE- I can not install a 2.6 kernel because of these boot issues. The 2.4 kernel has been the only one I can successfully boot off from. So it appears to be a kind of a catch-22. You have two choices : 1) install 2.6.8 from sarge or 2.6.12 from etch, and then install 2.6.14 after reboot. You will be forced to do something similar because of udev anyway. 2) install initramfs-tools and then install the 2.6.14 kernel. Things are still in flux, and 2.6.14 will not enter etch until these upgrade paths are solved. Friendly, Sven Luther Hi, I am not sure how to accomplish installing yaird inorder to install 2.6.14. The only 2.6 kernel that works is the di kernel. I do not know how to use rescue mode to make this installation successful. However, Any version of the 2.6 kernel I have tried beyond that di kernel panics on boot. I _can_ get them installed. If I could get a normal version of 2.6 to work, I am thinking my issue would be solved. Said differently, I have attempted to boot 2.6.10, 2.6.12, 2.6.13 and 2.6.14 (rc5 2). All version fail on boot. Only the di kernel hasn't paniced on boot . . . or knoppix kernel, that worked as well. I do not know how to install yaird because I do not have a working 2.6.x environment to leverage. Secondly, I have installed 2.6.14 with initramfs-tools and provided the output. The issue while ordering changed with the modification of udevsynthesize from 2 to 20 was functionally the same. Device does not exist, /dev/sda1. I may not be following where this e-mail thread is going, but I have accomplished both 1 2 of this last message. I just haven't been able to install 2.6.14 using yaird to create the initrd.img. Please let me know if I am missing something about these instructions. Are we now troubleshooting yaird or trying to get 2.6.14 to install? yaird seems to be a catch-22 while 2.6.14 was installed and a boot was successfully tried a couple of times, it just ends with the kernel panic before reaching a usable level. What should I do next? Thank you, Ken -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Supporting 2.6.14 kernels in base-installer
(Forwarding replies to the yaird-devel list) On Mon, Nov 14, 2005 at 09:21:38PM +0100, Sven Luther wrote: On Mon, Nov 14, 2005 at 03:17:24PM -0500, Joey Hess wrote: Sven Luther wrote: Also, we have perl-base in base, or used to at least, would yaird not be able to depend on perl-base only ? yaird uses at lest the following perl modules which are not currently present in perl-base but are in perl: ./Image.pm:use File::Copy; ./Pack.pm:use File::Temp; On the one hand, perl-base exists to provide the perl modules needed by packages in the Debian base system, so if a package like debconf or so needs a specific module, it can be moved from perl to that package. If yaird becomes part of the base system, or close enough to be needed to fit on Debian netinst CDs (which is pretty much the same thing), then adding the modules it needs to perl-base should not be a problem. perl's maintainer is very helpful about these things in my experience. On the other hand, the use of File::Copy is trivially replaced by a system() call. I'd be careful replacing the File::Temp usages with something else though. Agreed. It also uses HTML::Template and Parse::Recdescent that are in separate packages. From what I can see of the config files, using Parse::Recdescent to parse them is overkill; it should be possible to write a parser by hand pretty easily. The use of HtmlTemplate is quite strange. Parse::RecDescent: the information in the config file is a bit too much for the perl AppConfig module, you will need a parser. I agree that a parser could be hand written, and it would be smaller than what RecDescent does, if only because you don't need to include a parser-generator, just a parser. The .deb for RecDescent is only 88k, but it sucks in perl rather than perl-base. What that buys you is years of testing plus good error reporting. It's a tradeoff. HtmlTemplate: two aspects here: (1) _html_ template? The html is accidental, this just happens to be the best templating package around, for our purposes at least. Think of it as a generic template package that happens to have pointy brackets as escape notation. (2) But why templating at all? The basic premise is that yaird provides analysis code (in perl) and we want tunable behaviour based on that analysis: putting stuff on the image, where it should be possible to experiment with the stuff on image, without understanding every last detail of the perl code. There are a lot of ways to make it tunable: -- callbacks invoked by the analysis modules, -- data structures returned by analysis modules, then interpreted to put stuff on the image -- or templates The templating approach has the advantage of a clean separation between layers: when writing eg an LVM analysis module, you don't have to think about side effects in templates used; the template system is guaranteed to be side effect free. Conversely, when writing a template, the information available to the template and the allowed syntax is pretty obvious. The templating approach seems to be approximately the simplest one that is expressive enough; personally, I find the ugliest bits of yaird are in the top level config, more than in the bottom level templates. As with the parser, you could roll your own which would be smaller than the generic one, but the first releases would not have the stability and documentation that comes with years of polishing. I think the best would be for Erik to comment on this, CCing this to him now. To summarise: we can reduce dependencies and make the footprint smaller, but at a cost in building effort and the stability that comes with mature packages. A consequence is that it would take longer to build new features such as swsusp. It's a tradeoff; I would appreciate input on which aspect is most important for etch. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#338347: psmouse driver keeps losing synchronization
David Hugh-Jones [EMAIL PROTECTED] wrote: The only way I seem to be able to fix is: stop apmd; modprobe -r psmouse; unplug mouse; plug mouse back in; modprobe psmouse. That works some of the time. (Stopping apmd may not be necessary, I am not sure.) Hi David, this problem seems completely different to the problem that I had. Could you please post report to the upstream maintainers, Vojtech Pavlik [EMAIL PROTECTED], [EMAIL PROTECTED], CCing [EMAIL PROTECTED] Thanks -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New kernel-package 10.009 heading for experimental
Sven Luther [EMAIL PROTECTED] wrote: On Thu, Nov 10, 2005 at 03:58:54PM -0600, Manoj Srivastava wrote: On Thu, 10 Nov 2005 08:43:07 +0100, Sven Luther [EMAIL PROTECTED] said: As discussed on irc, we still need to find out why the new k-p break (or whatever you want to call it) the linux-2.6 control file mechanism, and thus we end up with missing dependencies on the linux-image packages, which break the ramdisk-tool upgrade path. Please don't upload the package to unstable until we know what is going on, and fix it, but i guess that was always your intentions. Well, as it turns out, it was not kernel-package breaking the dependency mechanism, it was the linux-2.6 control file not playing nice with dpkg-gencontrol, so the only thing holding kernel-package back is a request from the kernel team to wait until the -3 release. Indeed, and all the issues i was aware of have been solved now, so as far as i am concerned the 10.00x k-p can go in unstable, not sure if we should use it for -3 directly or not. Sorry for the confusion about this, i seriously believed you where uploading to unstable. I've been away from my desk for a few days, well other than occasionaly popping in on IRC. If I'm not deeply mistaken 2.6.14-3 is now out there, and was released using k-p 9.008.4. 10.00x seems to be in pretty good shape now, unless something nasty is lurking deeper in my INBOX. Manoj, please upload at will. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
On Mon, Nov 14, 2005 at 07:45:20PM -0500, Graham Knap wrote: James Bottomley [EMAIL PROTECTED] wrote: Can you try with the attached patch, which will force DV to ignore the echo buffer write tests? I'll certainly try. The kernel I was using was a prebuilt Debian kernel. I'm not sure how to rebuild it from source. Horms, if you could point me in the right direction, I'll give it a try. That depends exactly what you want to build. To just make an image for testing, upacking the tarball supplied by linux-source-2.6.14, using the config that came with linux-image-XYZ in /boot, and optionally using make-kpkg, should work. Though I think you have most of that happening. For now, I've built a kernel using the linux-source-2.6.14 package (version 2.6.14-2). It's massively stripped down so that it compiles in a semi-reasonable amount of time on this very slow PC. There isn't a great deal I can suggest in order to speed up builds, except perhaps using ccache, or trimming the config as you have done. If you need me to build stuff for you, I'm happy to oblige, though obviously there are extra email round-trips involved. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Supporting 2.6.14 kernels in base-installer
On Wed, Nov 16, 2005 at 12:35:03AM +0100, Erik van Konijnenburg wrote: I think the best would be for Erik to comment on this, CCing this to him now. To summarise: we can reduce dependencies and make the footprint smaller, but at a cost in building effort and the stability that comes with mature packages. A consequence is that it would take longer to build new features such as swsusp. It's a tradeoff; I would appreciate input on which aspect is most important for etch. Thanks for your reply. I am not sure, but i feel that the rewriting or whatever to use only perl-base would be needed only once we are sure it is going to be part of base or not. This is a choice, and i have the feeling that the 2.4 upgrade path makes initramfs-tools more suitable as default, altough i believe choice is good. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord and newer Linux kernels
In article [EMAIL PROTECTED] you wrote: [-- text/plain, encoding quoted-printable, charset: us-ascii, 33 lines --] [ Bugger, got the cdrtools-devel address wrong on the first mail. Now fixed. ] On Fri, Nov 11, 2005 at 12:53:00AM +0100, Christoph Hellwig wrote: On Thu, Nov 10, 2005 at 11:47:29PM +, Steve McIntyre wrote: In kernel 2.6.8 and later, SCSI generic commands are verified for safety. This may be a reasonable measure in some respects, but it makes effective non-root CD/DVD burning rather difficult. For best performance cdrecord, growisofs and friends may often need to send SCSI commands to drives that the kernel may neither know about nor understand. And (to add to the pain) these commands are very often vendor- or device-specific, so simply allowing those commands in the kernel will defeat the point of the verification in the first place. The whole point of the verification is to allow safe access to a selected set of raw commands for normal users. root (or rather a process that has CAP_SYS_RAWIO) can send any command. if you need unknown commands just make sure to burn as root, as everything else would be unsafe anyway. That does make it rather difficult to have any safe CD/DVD writing software - do you think it's a good idea to have end users run apps as root to burn CDs? I've read too much of the cdrecord source to be happy running that as root! :-) My thought is that it might be better to allow specific commands on specific drives, and let the local admin configure that for themselves... The whole problem is that some IOCTLS are not safe. And there is no definitive list of IOCTLs, so safe ones are added as they are known. And the others are disabled. If you have discovered ioctls which are indeed safe, then they should be added to the whitelist. As for allowing root to have a mechanism to allow users to access arbitary (unsafe) ioctls, that sounds like a can of worms to me. I have CCed the SCSI maintainers for comment. For their reference, your original post and patch, allong with the rest of this thread is at: http://lists.debian.org/debian-kernel/2005/11/msg00748.html -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338431: linux-2.6: [infrastrucutre] gencontrol.py should know how to exclude stuff from deps, add INITRD_CMD setting.
In article [EMAIL PROTECTED] you wrote: Package: linux-2.6 Severity: normal Well, this is something that came up with the desire of not using the (currently broken) initramfs-tools on alpha. We need two implementations to fix this, or at least one of them but the other seems useful too. 1) gencontrol.py should know how to handle an 'excludes' field, which will be used to remove any reference to the entries in it when generating the depends and such fields, this would be used as : arch/alpha/defines: ... excludes: initramfs-tools and the line : Depends: yaird | initramfs-tools | linux-initramfs-tool, module-init-tools (= 0.9.13) would be rewritten to : Depends: yaird | linux-initramfs-tool, module-init-tools (= 0.9.13) 2) We need support for setting INITRD_CMD prior to the make-kpkg command which creates the postinst (i thinkg the kernel-image one not sure though). This would allow to do : arch/defines : ... ramdisks: mkinitrd.yaird mkinitramfs arch/alpha/defines : ... ramdisks: mkinitrd.yaird The first one would be nice to have, we currently keep the full depend and add a conflict on alpha, but i believe the second solution is better, altough it needs k-p 10.000x. The reason why the second fix is better, is that there is really no reason to stop alpha from installing initramfs-tools, just we have to make sure not to use it by default. Agreed. I'm somewhat dubious about the need for 1) as we do have a mechanism, albeit a little tedious, to effect these kind of dependancies. And in this case at least 2) shows us that there is actually a slightly deeper problem that needs to be addresses. I'd be surprised if we really end up needing 1). -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338606: Kernel 2.6.14 break midi play in SB Live
In article [EMAIL PROTECTED] you wrote: Package: linux-image-2.6.14-1-k7 Version: 2.6.14-1 Severity: Normal In this kernel version I am unable to play midi (no sound) files with pmidi program in a SB Live Value. With the same settings, pmidi works perfectly in kernel version 2.6.12. Taking a wild guess, I'd say that this is related to the following patch, which seems to be have been added to shortly after the release of 2.6.12. http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2b6b22f3815b2937f272d3666bd18665d3f7f5a8 I've CCed James Courtier-Dutton, the EMU10K1 maintainer, he can probably help rather than just stabbing in the dark as I have done. PCI report :00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80) :00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge :00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) :00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) :00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] :00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) :00:13.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a) :00:13.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 0a) :01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) Modules snd_rtctimer3152 0 snd_seq_midi9312 0 snd_emu10k1_synth 7424 0 snd_emux_synth 37632 1 snd_emu10k1_synth snd_seq_virmidi 7232 1 snd_emux_synth snd_seq_midi_emul 7424 1 snd_emux_synth snd_seq_oss35328 0 snd_seq_midi_event 7168 3 snd_seq_midi,snd_seq_virmidi,snd_seq_oss snd_seq52624 8 snd_seq_midi,snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_oss,snd_seq_midi_event snd_emu10k1 123492 1 snd_emu10k1_synth snd_rawmidi25440 3 snd_seq_midi,snd_seq_virmidi,snd_emu10k1 snd_seq_device 8780 7 snd_seq_midi,snd_emu10k1_synth,snd_emux_synth,snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi snd_ac97_codec 97276 1 snd_emu10k1 snd_pcm_oss54688 0 snd_mixer_oss 19776 1 snd_pcm_oss snd_pcm92168 3 snd_emu10k1,snd_ac97_codec,snd_pcm_oss snd_timer 24772 4 snd_rtctimer,snd_seq,snd_emu10k1,snd_pcm snd_ac97_bus2176 1 snd_ac97_codec snd_page_alloc 10952 2 snd_emu10k1,snd_pcm snd_util_mem4544 2 snd_emux_synth,snd_emu10k1 snd_hwdep 9184 2 snd_emux_synth,snd_emu10k1 snd55652 13 snd_emux_synth,snd_seq_virmidi,snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_hwdep soundcore 9696 1 snd rtc12472 1 snd_rtctimer Thanks Waldo Cancino -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338497: marked as done ([wishlist] Please add 3w-xxxx to the initrd's /loadmodules)
Your message dated Wed, 16 Nov 2005 12:39:03 +0900 (JST) with message-id [EMAIL PROTECTED] and subject line Bug#338497: [wishlist] Please add 3w- to the initrd's /loadmodules has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 10 Nov 2005 17:11:44 + From [EMAIL PROTECTED] Thu Nov 10 09:11:44 2005 Return-path: [EMAIL PROTECTED] Received: from office-gw.westend.com ([212.117.64.2] helo=xeniac.intern) by spohr.debian.org with esmtp (Exim 4.50) id 1EaFxg-0001yg-Nf for [EMAIL PROTECTED]; Thu, 10 Nov 2005 09:11:44 -0800 Received: by xeniac.intern (Postfix, from userid 1000) id EEF5B37815E; Thu, 10 Nov 2005 18:11:42 +0100 (CET) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Christian Hammers [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: [wishlist] Please add 3w- to the initrd's /loadmodules X-Mailer: reportbug 3.8 Date: Thu, 10 Nov 2005 18:11:42 +0100 Message-Id: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 Package: kernel-image-2.6.8-2-686 Version: 2.6.8-16 Severity: wishlist Hello Please ad the 3w- which is the driver for the commonly used 3ware (P)ATA RAID controller to the list of modules that get loaded automatically because else it won't boot so well... bye, -christian- -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages kernel-image-2.6.8-2-686 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.81.1 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo -- no debconf information --- Received: (at 338497-done) by bugs.debian.org; 16 Nov 2005 03:39:35 + From [EMAIL PROTECTED] Tue Nov 15 19:39:35 2005 Return-path: [EMAIL PROTECTED] Received: from koto.vergenet.net ([210.128.90.7]) by spohr.debian.org with esmtp (Exim 4.50) id 1EcE90-00058u-VW for [EMAIL PROTECTED]; Tue, 15 Nov 2005 19:39:35 -0800 Received: by koto.vergenet.net (Postfix, from userid 7100) id E59343402F; Wed, 16 Nov 2005 12:39:03 +0900 (JST) From: Horms [EMAIL PROTECTED] To: Christian Hammers [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Bug#338497: [wishlist] Please add 3w- to the initrd's /loadmodules In-Reply-To: [EMAIL PROTECTED] X-Newsgroups: gmane.linux.debian.devel.kernel User-Agent: tin/1.7.10-20050815 (Grimsay) (UNIX) (Linux/2.6.14-1-686-smp (i686)) Message-Id: [EMAIL PROTECTED] Date: Wed, 16 Nov 2005 12:39:03 +0900 (JST) X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 In article [EMAIL PROTECTED] you wrote: Hello On 2005-11-10 Sven Luther wrote: So, your real request is that initrd-tools is not including the module in your initrd. So, please add the module to /etc/mkinitrd/modules, and rebuild your initrd (with dpkg-reconfigure kernel-image-2.6.8-...). So the initrd image is rebuild on every kernel upgrade automatically? I was under the assumption that it was distributed as binary with the kernel-image package and I could no longer use the official kernel image which would have been a pain. The initrd image is built for your system when the kernel image is installed. It is cusomised for your system, and thus can't be shipped as a binary. You can modify how mkinitrd generates this image using the files in /etc/mkinird And you can manually re-create the initrd image by invoking mkinitrd on the command line. So in this case you can close the bug report (although more documentation would be fine :)) Closing :) -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact
Bug#338615: psmouse should be loaded after usb-stuff
Hi, According to http://bugs.debian.org/338615 and before it http://www.ussg.iu.edu/hypermail/linux/kernel/0407.1/0862.html The psmouse driver needs to be loaded after usb (if it is going to be loaded). I'm posting this to linux-input and linux-hotplug-devel as I have no idea how this should be done. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#250171: marked as done (kernel-source-2.4.26: hptraid/hpt366 spin-down HDD)
Your message dated Wed, 16 Nov 2005 13:02:50 +0900 with message-id [EMAIL PROTECTED] and subject line Bug#250171: kernel-source-2.4.26: hptraid/hpt366 spin-down HDD has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 21 May 2004 00:11:32 + From [EMAIL PROTECTED] Thu May 20 17:11:32 2004 Return-path: [EMAIL PROTECTED] Received: from ls401.htnet.hr [195.29.150.2] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1BQxdM-0005N5-00; Thu, 20 May 2004 17:11:32 -0700 Received: from ls401.htnet.hr (localhost.localdomain [127.0.0.1]) by ls401.htnet.hr (0.0.0/8.12.10) with ESMTP id i4L0BUH9014790 for [EMAIL PROTECTED]; Fri, 21 May 2004 02:11:30 +0200 Received: from d1t (ad24-m67.net.htnet.hr [195.29.59.67]) by ls401.htnet.hr (0.0.0/8.12.10) with ESMTP id i4L0BTdg014783; Fri, 21 May 2004 02:11:29 +0200 Received: from root by d1t with local (Exim 3.35 #1 (Debian)) id 1BQc9u-HA-00; Thu, 20 May 2004 03:15:42 +0200 Date: Thu, 20 May 2004 03:15:42 +0200 From: Nino Saban [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: kernel-source-2.4.26: hptraid/hpt366 spin-down HDD Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Reportbug-Version: 2.58 X-Trace: ls401.htnet.hr 1085098290 5162 195.29.59.67 (Fri, 21 May 2004 02:11:30 +0200) Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-7.3 required=4.0 tests=BAYES_00,DATE_IN_PAST_12_24, HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: Package: kernel-source-2.4.26 Version: 2.4.26-2 Severity: important 1) Install Woody base system, and proposed update package kernel-image-2.4.24-2-386 The system has a Highpoint RocketRAID 133 PCI card (firmware 2.35) controller, which is handled by hpt366.o hptraid.o Booting system uses initrd, and loads modules in this order: ide-disk hpt366 ide-detect hptraid 2) Create RAID1 array in controller's BIOS with disks: 2 x Seagate Barracuda 7200.7 ST3120026A (3.06 firmware) (ATA100 devices = working normally in udma5 mode) /dev/hde /dev/hdg which become /dev/ataraid/d0 whole disk device SYSTEM works fine with this RAID 1 array, but when we do # cd # cat /proc/ide/hpt366 and then e.g. # pwd THESE MESSAGES APPEAR: == hdg: DMA disabled hdg: drive not ready ide3: reset: success or hdg: timeout waiting for DMA == ACTUALLY, IT SEEMS second disk in the array SPINS DOWN as if going to standby mode. CONSEQUENCES ARE CATASTROPHIC, system freezes and if we somehow manage to type a command (e.g. on the SMP system) like init 0 it fails, and filesystem gets, so badly damaged it is practically impossible to repair SEEMS LIKE A KERNEL BUG? Noticed, the same crash does NOT happen when using disks in non-RAID mode # cat /proc/ide/hpt366 does not do any damage. Note: CRASH happens also with kernel 2.4.26 (kernel-image-2.4.26-1-386 package) HARDWARE: Abit IC7-G (i875P chipset) 1 GB ECC memory Pentium4 Prescott 3.0 GHz (with or without HyperThreading) -- System Information: Debian Release: 3.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i586) Kernel: Linux 2.4.24-1-386 Locale: LANG=C, LC_CTYPE=C --- Received: (at 250171-done) by bugs.debian.org; 16 Nov 2005 04:06:49 + From [EMAIL PROTECTED] Tue Nov 15 20:06:49 2005 Return-path: [EMAIL PROTECTED] Received: from koto.vergenet.net ([210.128.90.7]) by spohr.debian.org with esmtp (Exim 4.50) id 1EcEZN-00025l-5h for [EMAIL PROTECTED]; Tue, 15 Nov 2005 20:06:49 -0800 Received: by koto.vergenet.net (Postfix, from userid 7100) id D14D034030; Wed, 16 Nov 2005 13:06:17 +0900 (JST) Date: Wed, 16 Nov 2005 13:02:50 +0900 From: Horms [EMAIL PROTECTED]
Bug#255425: marked as done (kernel-source-2.4.26: Patch to enable Dell PowerEdge 750 SATA DMA support)
Your message dated Wed, 16 Nov 2005 13:06:03 +0900
with message-id [EMAIL PROTECTED]
and subject line Bug#255425: kernel-source-2.4.26: Patch to enable Dell
PowerEdge 750 SATA DMA support
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 20 Jun 2004 20:45:10 +
From [EMAIL PROTECTED] Sun Jun 20 13:45:10 2004
Return-path: [EMAIL PROTECTED]
Received: from lyra.bfree.on.ca [66.207.115.254]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1Bc9BP-0002lG-00; Sun, 20 Jun 2004 13:44:55 -0700
Received: from [199.79.214.237] (207-177-225-50.dsl.redshift.com
[:::207.177.225.50])
(AUTH: PLAIN dajhorn, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by lyra with esmtp; Sun, 20 Jun 2004 16:43:04 -0400
Message-ID: [EMAIL PROTECTED]
Date: Sun, 20 Jun 2004 13:44:10 -0700
From: Darik Horn [EMAIL PROTECTED]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040616
X-Accept-Language: en-us, en
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary==_lyra-15735-1087764184-0001-2
To: [EMAIL PROTECTED]
Subject: kernel-source-2.4.26: Patch to enable Dell PowerEdge 750 SATA DMA
support
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-3.2 required=4.0 tests=BAYES_01,DOMAIN_BODY,
HAS_PACKAGE,UPPERCASE_25_50 autolearn=no
version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
This is a MIME-formatted message. If you see this text it means that your
E-mail software does not support MIME-formatted messages.
--=_lyra-15735-1087764184-0001-2
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Package: kernel-source-2.4.26
Version: 2.4.26-2
Severity: wishlist
Tags: patch
This patch by Nick Craig-Wood enables DMA support for the Intel 6300ESB
SATA disk controller in the Dell PowerEdge 750. A compatible driver is
already in the kernel, so this patch just adds the new PCI device id.
--=_lyra-15735-1087764184-0001-2
Content-Type: text/plain; name=linux-2.4.26-pe750.patch; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename=linux-2.4.26-pe750.patch
diff -Ndru kernel-source-2.4.26/drivers/ide/pci/piix.c
kernel-source-2.4.26-pe750/drivers/ide/pci/piix.c
--- kernel-source-2.4.26/drivers/ide/pci/piix.c Wed Apr 14 13:05:30 2004
+++ kernel-source-2.4.26-pe750/drivers/ide/pci/piix.c Tue Jun 15 20:50:25 2004
@@ -155,6 +155,7 @@
case PCI_DEVICE_ID_INTEL_82801E_11:
case PCI_DEVICE_ID_INTEL_ESB_2:
case PCI_DEVICE_ID_INTEL_ICH6_2:
+ case PCI_DEVICE_ID_INTEL_ESB_3:
p += sprintf(p, PIIX4 Ultra 100 );
break;
case PCI_DEVICE_ID_INTEL_82372FB_1:
@@ -294,6 +295,7 @@
case PCI_DEVICE_ID_INTEL_82801EB_11:
case PCI_DEVICE_ID_INTEL_ESB_2:
case PCI_DEVICE_ID_INTEL_ICH6_2:
+ case PCI_DEVICE_ID_INTEL_ESB_3:
mode = 3;
break;
/* UDMA 66 capable */
@@ -686,6 +688,7 @@
case PCI_DEVICE_ID_INTEL_82801E_11:
case PCI_DEVICE_ID_INTEL_ESB_2:
case PCI_DEVICE_ID_INTEL_ICH6_2:
+ case PCI_DEVICE_ID_INTEL_ESB_3:
{
unsigned int extra = 0;
pci_read_config_dword(dev, 0x54, extra);
@@ -883,6 +886,7 @@
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801EB_1, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 18},
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_2, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 19},
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_2, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 20},
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_3, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 21},
{ 0, },
};
diff -Ndru kernel-source-2.4.26/drivers/ide/pci/piix.h
kernel-source-2.4.26-pe750/drivers/ide/pci/piix.h
--- kernel-source-2.4.26/drivers/ide/pci/piix.h Wed Apr 14 13:05:30 2004
+++ kernel-source-2.4.26-pe750/drivers/ide/pci/piix.h Wed Jun 16 07:59:41 2004
@@ -333,6 +333,20 @@
.enablebits = {{0x41,0x80,0x80}, {0x43,0x80,0x80}},
.bootable = ON_BOARD,
.extra = 0,
+ },{ /* 21 */
Bug#278043: marked as done (macintosh: cannot compile because of syntax error)
Your message dated Wed, 16 Nov 2005 12:58:46 +0900
with message-id [EMAIL PROTECTED]
and subject line #278043 macintosh: cannot compile because of syntax error
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 24 Oct 2004 13:28:15 +
From [EMAIL PROTECTED] Sun Oct 24 06:28:15 2004
Return-path: [EMAIL PROTECTED]
Received: from areims-151-1-9-86.w83-192.abo.wanadoo.fr (Arda.LT-P.net)
[83.192.135.86] (mail)
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1CLiPv-0002Pf-00; Sun, 24 Oct 2004 06:28:15 -0700
Received: from ltp by Arda.LT-P.net with local (Exim 3.36 #1 (Debian))
id 1CLiPo-0001DE-00; Sun, 24 Oct 2004 15:28:08 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=ISO-8859-15
From: LT-P [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: macintosh: cannot compile because of syntax error
X-Mailer: reportbug 2.63
Date: Sun, 24 Oct 2004 15:28:01 +0200
Message-Id: [EMAIL PROTECTED]
Sender: LT-P [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
Package: kernel-source-2.4.26
Version: 2.4.26-6
Severity: normal
While compiling the kernel with a correct config file from kernel 2.4.25:
___
make[4]: Entering directory
`/surplus/system/src/kernel-source-2.4.26/drivers/macintosh'
gcc -D__KERNEL__ -I/surplus/system/src/kernel-source-2.4.26/include -Wall
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -O2
-fomit-frame-pointer -I/surplus/system/src/kernel-source-2.4.26/arch/ppc
-fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple
-mstring -nostdinc -iwithprefix include -DKBUILD_BASENAME=nvram -c -o nvram.o
nvram.c
nvram.c: Dans la fonction « read_nvram »:
nvram.c:41: error: erreur d'analyse syntaxique before unsigned
nvram.c:46: error: `i' undeclared (first use in this function)
nvram.c:46: error: (Each undeclared identifier is reported only once
nvram.c:46: error: for each function it appears in.)
nvram.c:48: attention : left-hand operand of comma expression has no effect
make[4]: *** [nvram.o] Error 1
___
If we look at the source
(/usr/src/kernel-source-2.4.26/drivers/macintosh/nvram.c), we can see that:
___
37 static ssize_t read_nvram(struct file *file, char *buf,
38size_t count, loff_t *ppos)
39 {
40loff_t n = *ppos
41unsigned int i = n;
42char *p = buf;
43
___
So I added a semicolon at the end of line 40, and the compiler accepted it.
Happy patching :)
LT-P
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: powerpc (ppc)
Kernel: Linux 2.4.25-ltp
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Versions of packages kernel-source-2.4.26 depends on:
ii binutils 2.15-4 The GNU assembler, linker and bina
ii bzip2 1.0.2-1A high-quality block-sorting file
ii coreutils [fileutils] 5.2.1-2The GNU core utilities
ii fileutils 5.2.1-2The GNU file management utilities
-- no debconf information
---
Received: (at 278043-done) by bugs.debian.org; 16 Nov 2005 04:06:49 +
From [EMAIL PROTECTED] Tue Nov 15 20:06:49 2005
Return-path: [EMAIL PROTECTED]
Received: from koto.vergenet.net ([210.128.90.7])
by spohr.debian.org with esmtp (Exim 4.50)
id 1EcEZN-00025k-79
for [EMAIL PROTECTED]; Tue, 15 Nov 2005 20:06:49 -0800
Received: by koto.vergenet.net (Postfix, from userid 7100)
id B2FD63402B; Wed, 16 Nov 2005 13:06:17 +0900 (JST)
Date: Wed, 16 Nov 2005 12:58:46 +0900
From: Horms [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: #278043 macintosh: cannot compile because of syntax error
Message-ID: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Cluestick: seven
User-Agent: Mutt/1.5.11
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-2.0 required=4.0 tests=BAYES_01 autolearn=no
Re: Processed: kernel 2.4
Debian Bug Tracking System [EMAIL PROTECTED] wrote: Processing commands for [EMAIL PROTECTED]: reassign 278043 kernel-source-2.4.27 Bug#278043: macintosh: cannot compile because of syntax error Warning: Unknown package 'kernel-source-2.4.26' Bug reassigned from package `kernel-source-2.4.26' to `kernel-source-2.4.27'. reassign 250171 kernel-source-2.4.27 Bug#250171: kernel-source-2.4.26: hptraid/hpt366 spin-down HDD Warning: Unknown package 'kernel-source-2.4.26' Bug reassigned from package `kernel-source-2.4.26' to `kernel-source-2.4.27'. reassign 255425 kernel-source-2.4.27 Bug#255425: kernel-source-2.4.26: Patch to enable Dell PowerEdge 750 SATA DMA support Warning: Unknown package 'kernel-source-2.4.26' Bug reassigned from package `kernel-source-2.4.26' to `kernel-source-2.4.27'. reassign 255406 kernel-source-2.4.27 Bug#255406: kernel-source-2.4.26: Kernel crash when removing interface from wrong bridge group Warning: Unknown package 'kernel-source-2.4.26' Bug reassigned from package `kernel-source-2.4.26' to `kernel-source-2.4.27'. reassign 252187 kernel-source-2.4.27 Bug#252187: kernel-source-2.4.26: plip_ioctl do not check cmd param equal to SIOCDEVPLIP Warning: Unknown package 'kernel-source-2.4.26' Bug reassigned from package `kernel-source-2.4.26' to `kernel-source-2.4.27'. reassign 290428 kernel-source-2.4.27 Bug#290428: kernel-source-2.4.25: Building from source puts extra files in tarball Warning: Unknown package 'kernel-source-2.4.25' Bug reassigned from package `kernel-source-2.4.25' to `kernel-source-2.4.27'. reassign 252289 kernel-source-2.4.27 Bug#252289: general: system clock goes chaoticly causing system breakdown Warning: Unknown package 'kernel-source-2.4.26' Bug reassigned from package `kernel-source-2.4.26' to `kernel-source-2.4.27'. reassign 262324 kernel-source-2.4.27 Bug#262324: Add support for NetMOS 9805 parport Warning: Unknown package 'kernel-source-2.4.26' Bug reassigned from package `kernel-source-2.4.26' to `kernel-source-2.4.27'. I have gone through these up to and including 262324. They generally fall into one of 3 categories. 1) Already fixed, usually in upstream's 2.4.27 and thus should be closed. 2) Patch that should be applied, and if not upstream forwarded 3) Onerous backport which should be marked +upstream +wontfix I would be most grateful if some brave sole could go through the rest of the list and close/tag them. Even if you skip half of them it will still give me a headstart on the more problematic ones. I think there are some other batch reassignments futher down my debian-kernel inbox. Same goes for them, and the BTS in general for that matter. reassign 230340 kernel-source-2.4.27 Bug#230340: Kernel OOPS with Debian version of kernel sources for 2.4.24 Warning: Unknown package 'kernel-source-2.4.24' Bug reassigned from package `kernel-source-2.4.24' to `kernel-source-2.4.27'. reassign 290428 kernel-source-2.4.27 Bug#290428: kernel-source-2.4.25: Building from source puts extra files in tarball Bug reassigned from package `kernel-source-2.4.27' to `kernel-source-2.4.27'. reassign 230340 kernel-source-2.4.27 Bug#230340: Kernel OOPS with Debian version of kernel sources for 2.4.24 Bug reassigned from package `kernel-source-2.4.27' to `kernel-source-2.4.27'. reassign 259913 kernel-image-2.4.27-2-sparc64 Bug#259913: sr_mod does not work with Ultra60 cdrom Warning: Unknown package 'kernel-image-2.4.26-sparc64' Bug reassigned from package `kernel-image-2.4.26-sparc64' to `kernel-image-2.4.27-2-sparc64'. reassign 261868 kernel-image-2.4.27-2-sparc64 Bug#261868: kernel-image-2.4.26-sparc64: crash (freeze) Warning: Unknown package 'kernel-image-2.4.26-sparc64' Bug reassigned from package `kernel-image-2.4.26-sparc64' to `kernel-image-2.4.27-2-sparc64'. reassign 237075 kernel-image-2.4.27-2-sparc64 Bug#237075: bterm exits with segmentation fault on Sun Ultra 1 Creator 3d Warning: Unknown package 'kernel-image-2.4.26-sparc64' Bug#245620: bterm segmentation fault -- sparc ultra 30, creator graphics Warning: Unknown package 'kernel-image-2.4.26-sparc64' Bug reassigned from package `kernel-image-2.4.26-sparc64' to `kernel-image-2.4.27-2-sparc64'. reassign 268056 kernel-image-2.4.27-2-sparc64 Bug#268056: kernel-image-2.4.26-sparc64: oopses after mounting root readonly Warning: Unknown package 'kernel-image-2.4.26-sparc64' Bug reassigned from package `kernel-image-2.4.26-sparc64' to `kernel-image-2.4.27-2-sparc64'. reassign 245620 kernel-image-2.4.27-2-sparc64 Bug#245620: bterm segmentation fault -- sparc ultra 30, creator graphics Bug#237075: bterm exits with segmentation fault on Sun Ultra 1 Creator 3d Bug reassigned from package `kernel-image-2.4.27-2-sparc64' to `kernel-image-2.4.27-2-sparc64'. reassign 261368 kernel-image-2.4.27-2-sparc64-smp Bug#261368: swf-player: swf_play oops on sparc64-smp Warning: Unknown package
Re: [D-I] Supporting 2.6.14 kernels in base-installer
On Tue, Nov 15, 2005 at 08:31:28AM +0100, Sven Luther wrote: On Mon, Nov 14, 2005 at 08:38:03PM -0800, Steve Langasek wrote: On Mon, Nov 14, 2005 at 10:38:41PM +0100, Sven Luther wrote: I still think choice is good, and also what users expect of debian. A sane default, plus the ability to override that in expert mode. Choice is overrated, and a poor substitute for properly working tools. Which initramfs generator do I need to use so that my system will be bootable post-install? is not a choice that *any* user looks forward to making; if a user really has a strong preference for yaird vs. initramfs-tools, that option is open to them after the install. The real question here is : 1) what does it cost us. I *listed* other costs, which you apparently ignored. Joeyh is concerned about testing. I personally have doubts that this is a bad thing, as it means more testing which is good, but i defer to his greater experience on this. No, this is extra testing of *code that wouldn't need to exist if not for this option*. That's not good, that's *wasteful*. Too often, Debian developers (and Open Source folks in general) give users choices in lieu of making sound technical decisions or fixing bugs. I'll take install this; it works, and when it doesn't, the bugs will get fixed any day over well, you can have mediocre.py, or you can have mediocre.pl; if one doesn't work, use the other one. In the case of initramfs generators in the installer, giving users choice instead of just fixing bugs means pushing the load on the installer team for testing a greater number of code paths, and on the translators for debconf templates that no one should ever need. Nope, it is more than a technical difference in language used, it is a different design goal between both. Um... the design goal is create an initramfs that boots the user's system. Any other design goals are almost completely irrelevant to the user... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#338615: psmouse should be loaded after usb-stuff
On Wed, Nov 16, 2005 at 01:06:17PM +0900, Horms wrote: Hi, According to http://bugs.debian.org/338615 and before it http://www.ussg.iu.edu/hypermail/linux/kernel/0407.1/0862.html The psmouse driver needs to be loaded after usb (if it is going to be loaded). I'm posting this to linux-input and linux-hotplug-devel as I have no idea how this should be done. It's not necessary anymore. Using the 'usb-handoff' on the kernel command line option is enough in the cases where it's needed. -- Vojtech Pavlik SuSE Labs, SuSE CR -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339057: linux-image-2.6.14-1-686: Cannot turn DMA on for /dev/hda
Hello, can you please add the output of lsmod from both 2.6.12 and 2.6.14? I suspect yaird is loading the ide_generic module before the mainboard-specific one. If this is the case, please edit /etc/yaird/Default.cfg in the section CONFIG, add MODULE ide-core MODULE via82cxxx MODULE ide_generic and replace via82cxxx with whatever your ide-driver should be. HTH Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#339295: psmouse.c: Failed to reset mouse on isa0060/serio1 - works fine with 2.6.13-1-k7
Package: linux-image-2.6.14-2-k7 Version: 2.6.14-3 Severity: normal Hi all, with linux-image-2.6.14-2-k7 my Logitech USB infrared mouse does not work any longer (the infrared light turns on though). During bootup I can see these messages: kernel: psmouse.c: Failed to reset mouse on isa0060/serio1 kernel: psmouse.c: Failed to enable mouse on isa0060/serio1 Full boot message can be found here: http://www.mistersixt.de/tmp/dmesg-2.6.14.txt With kernel 2.6.13-1-k7 it works like expected. Let me know if you need further information. Kind regards, Joerg. -- System Information: Debian Release: unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages linux-image-2.6.14-2-k7 depends on: ii module-init-tools 3.2-pre9-4 tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.11-12 Yet Another mkInitRD linux-image-2.6.14-2-k7 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Supporting 2.6.14 kernels in base-installer
On Mon, Nov 14, 2005 at 04:15:36PM -0500, Joey Hess wrote: Jonas Smedegaard wrote: I don't understand what temporary hardcoding of root partition actually means. Yaird looks at /etc/fstab for the root partion. d-i currently does this before installing mkinitrd-tools: # Temporarily hardcode the root partition. rootpart_devfs=$(mount | grep on /target | cut -d' ' -f1) rootpartfs=$(mount | grep on /target | cut -d' ' -f5) rootpart=$(mapdevfs $rootpart_devfs) if [ -f $mkinitrdconf ]; then sed -e s#^ROOT=.*#ROOT='$rootpart $rootpartfs'# $mkinitrdconf $mkinitrdconf.new mv $mkinitrdconf.new $mkinitrdconf else echo ROOT='$rootpart $rootpartfs' $mkinitrdconf fi Appacently Colin has already checked that initramfs-tools doesn't need such a hack, Right; Jeff Bailey has been very clear to me that it can work it out based on what it's told by the bootloader. Some lilo modifications may be needed at some point to pass the root filesystem as a device name rather than in lilo's hex-encoded major/minor form (which I'm told will eventually break due to kernel changes, and probably doesn't work so well for wacky block devices even now), either by changing lilo directly to do that or just by making lilo-installer override it by adding root= to the kernel command line in append=. initramfs-tools does handle lilo's current syntax for the moment, though. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339304: linux-image-2.6.14-2-k7: please supply kernels capable of addressing 4Gb of memory
Package: linux-image-2.6.14-2-k7 Version: 2.6.14-3 Severity: wishlist I've got a couple of machines based on amd64 with 4Gb of memory. With the stock k7 and k7-smp debian supplied kernels, I can only see 3Gb of this memory when booted. Although I can fiddle with the BIOS settings on one of the machines to get around 3.8Gb of memory visible when booted, on the other, no amount of BIOS fiddling gets me above 3Gb. What I've had to on both machines is to take the config options for the k7 and k7-smp versions and then enabled 64Gb support so that PAE can be used to access the physical memory above 4Gb (the BIOS has made a hole in the physical memory map). dmesg shows: BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - bffb (usable) BIOS-e820: bffb - bffc (ACPI data) BIOS-e820: bffc - bfff (ACPI NVS) BIOS-e820: bfff - c000 (reserved) BIOS-e820: ff78 - 0001 (reserved) BIOS-e820: 0001 - 00014000 (usable) Warning only 4GB will be used. Use a PAE enabled kernel. I've also noticed this problem on some P4 machines too. Now that machines with 4Gb or more of memory are becoming more prevalent, please either build the stock k7, k7-smp, 686 and 686-smp kernels with memory support for 64Gb or supply extra packages that include this support. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-k7 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages linux-image-2.6.14-2-k7 depends on: ii module-init-tools 3.2-pre9-4 tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.11-12 Yet Another mkInitRD linux-image-2.6.14-2-k7 recommends no packages. -- no debconf information * This email and any attachment is confidential. It may only be read, copied and used by the intended recipient(s). If you are not the intended recipient (s), you may not copy, use, distribute, forward, store or disclose this e-mail or any attachment. If you are not the intended recipient(s) or have otherwise received this e-mail in error, you should destroy it and any attachment and notify the sender by reply e-mail or send a message to: [EMAIL PROTECTED] * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339295: psmouse.c: Failed to reset mouse on isa0060/serio1 - works fine with 2.6.13-1-k7
Maximilian Attems wrote: On Tue, Nov 15, 2005 at 10:37:06AM +0100, Joerg Morbitzer wrote: with linux-image-2.6.14-2-k7 my Logitech USB infrared mouse does not work any longer (the infrared light turns on though). During bootup I can see these messages: kernel: psmouse.c: Failed to reset mouse on isa0060/serio1 kernel: psmouse.c: Failed to enable mouse on isa0060/serio1 Full boot message can be found here: http://www.mistersixt.de/tmp/dmesg-2.6.14.txt With kernel 2.6.13-1-k7 it works like expected. Let me know if you need further information. please append dmesg of working 2.6.13, also lsmod after boot for both kernels. output of cat /proc/bus/input/devices would be cool to. (we might need more ;-) Sure, this is the kernel output of 2.6.13: http://www.mistersixt.de/tmp/dmesg-2.6.13.txt Here lsmod for both kernel versions: http://www.mistersixt.de/tmp/lsmod-2.6.13.txt http://www.mistersixt.de/tmp/lsmod-2.6.14.txt And finally the input devices: http://www.mistersixt.de/tmp/cat-usb-device.txt Kind regards, Joerg. -- EMail: [EMAIL PROTECTED] Forum: http://www.morbitzer.de/cgi-bin/cutecast/cutecast.pl Chat: http://www.morbitzer.de/irccgi.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339295: psmouse.c: Failed to reset mouse on isa0060/serio1 - works fine with 2.6.13-1-k7
On Tue, Nov 15, 2005 at 11:29:27AM +0100, Joerg Morbitzer wrote: Maximilian Attems wrote: On Tue, Nov 15, 2005 at 10:37:06AM +0100, Joerg Morbitzer wrote: with linux-image-2.6.14-2-k7 my Logitech USB infrared mouse does not work any longer (the infrared light turns on though). During bootup I can see these messages: kernel: psmouse.c: Failed to reset mouse on isa0060/serio1 kernel: psmouse.c: Failed to enable mouse on isa0060/serio1 Full boot message can be found here: http://www.mistersixt.de/tmp/dmesg-2.6.14.txt With kernel 2.6.13-1-k7 it works like expected. Let me know if you need further information. please append dmesg of working 2.6.13, also lsmod after boot for both kernels. output of cat /proc/bus/input/devices would be cool to. (we might need more ;-) Sure, this is the kernel output of 2.6.13: http://www.mistersixt.de/tmp/dmesg-2.6.13.txt please output of dmesg, it is a pain to diff syslog. after boot: dmesg dmesg-2.6.13 Here lsmod for both kernel versions: http://www.mistersixt.de/tmp/lsmod-2.6.13.txt http://www.mistersixt.de/tmp/lsmod-2.6.14.txt And finally the input devices: http://www.mistersixt.de/tmp/cat-usb-device.txt for which kernel was that? i see an usb mouse there. also please _append_ the messages to your mail, instead of putting them to a temporary webdir, where they will disappear soonest. while we are it the appended output of he following cmd might help (for both kernels working and non working): cat /proc/ioports -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339295: psmouse.c: Failed to reset mouse on isa0060/serio1 - works fine with 2.6.13-1-k7
please output of dmesg, it is a pain to diff syslog. after boot: dmesg dmesg-2.6.13 Simply do cat dmesg-2.6.14.txt | cut -d -f 6- and you have the plain dmesg output. However, check out the attachments for the plain dmesg files. Here lsmod for both kernel versions: http://www.mistersixt.de/tmp/lsmod-2.6.13.txt http://www.mistersixt.de/tmp/lsmod-2.6.14.txt And finally the input devices: http://www.mistersixt.de/tmp/cat-usb-device.txt for which kernel was that? 2.6.13 i see an usb mouse there. Yes, I am talking about an usb mouse, please see my first email. Here is the output of the devices of 2.6.14: I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name=AT Translated Set 2 keyboard P: Phys=isa0060/serio0/input0 H: Handlers=kbd event0 B: EV=120013 B: KEY=4 200 3802078 f840d001 f2df ffef fffe B: MSC=10 B: LED=7 I: Bus=0011 Vendor=0002 Product=0001 Version= N: Name=PS/2 Generic Mouse P: Phys=isa0060/serio1/input0 H: Handlers=mouse0 event1 ts0 B: EV=7 B: KEY=7 0 0 0 0 0 0 0 0 B: REL=3 I: Bus=0010 Vendor=001f Product=0001 Version=0100 N: Name=PC Speaker P: Phys=isa0061/input0 H: Handlers=kbd event2 B: EV=40001 B: SND=6 I: Bus=0003 Vendor=046d Product=c00e Version=1110 N: Name=Logitech USB-PS/2 Optical Mouse P: Phys=usb-:00:04.2-2/input0 H: Handlers=mouse1 event3 ts1 B: EV=7 B: KEY=7 0 0 0 0 0 0 0 0 B: REL=103 while we are it the appended output of he following cmd might help (for both kernels working and non working): cat /proc/ioports Please see attachments. Kind regards, Joerg. Linux version 2.6.13-1-k7 (Debian 2.6.13-1) ([EMAIL PROTECTED]) (gcc version 4.0.2 (Debian 4.0.2-2)) #1 Fri Oct 7 00:57:20 JST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1ffec000 (usable) BIOS-e820: 1ffec000 - 1ffef000 (ACPI data) BIOS-e820: 1ffef000 - 1000 (reserved) BIOS-e820: 1000 - 2000 (ACPI NVS) BIOS-e820: - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. On node 0 totalpages: 131052 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 126956 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 ASUS ) @ 0x000f6ac0 ACPI: RSDT (v001 ASUS A7M266 0x30303031 MSFT 0x31313031) @ 0x1ffec000 ACPI: FADT (v001 ASUS A7M266 0x30303031 MSFT 0x31313031) @ 0x1ffec080 ACPI: DSDT (v001 ASUS A7M266 0x1000 MSFT 0x010b) @ 0x ACPI: PM-Timer IO Port: 0xe408 Allocating PCI resources starting at 2000 (gap: 2000:dfff) Built 1 zonelists Kernel command line: BOOT_IMAGE=LinuxOLD ro root=302 acpi=on apm=off pci=noacpi Local APIC disabled by BIOS -- you can enable it with lapic mapped APIC to d000 (01402000) Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 1534.396 MHz processor. Using pmtmr for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 514340k/524208k available (1777k kernel code, 9336k reserved, 740k data, 172k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 3068.81 BogoMIPS (lpj=1534406) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383f9ff c1c3f9ff CPU: After vendor identify, caps: 0383f9ff c1c3f9ff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383f9ff c1c3f9ff 0020 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) CPU: AMD Athlon(TM) XP 1800+ stepping 02 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0e20 (from 0c20) checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd Freeing initrd memory: 1484k freed NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xf0dc0, last bus=1 PCI: Using configuration type 1 ACPI: Subsystem revision 20050408 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 12 devices PnPBIOS: Disabled by ACPI PNP PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00)
Bug#339295: psmouse.c: Failed to reset mouse on isa0060/serio1 - works fine with 2.6.13-1-k7
On Tue, Nov 15, 2005 at 12:22:59PM +0100, Joerg Morbitzer wrote: please output of dmesg, it is a pain to diff syslog. after boot: dmesg dmesg-2.6.13 Simply do cat dmesg-2.6.14.txt | cut -d -f 6- cool, thanks for teaching me cut usage, never got to that.. However, check out the attachments for the plain dmesg files. a quick diff reveals that you boot your 2.6.14 and 2.6.13 with different kernel parameters in ?lilo?. please try to boot 2.6.14 too with pci=noacpi or pci=routeirq that's more an workaround.. bug should be forwarded to acpi upstream. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Supporting 2.6.14 kernels in base-installer
On Tue, Nov 15, 2005 at 10:24:41AM +, Colin Watson wrote: On Mon, Nov 14, 2005 at 04:15:36PM -0500, Joey Hess wrote: Jonas Smedegaard wrote: I don't understand what temporary hardcoding of root partition actually means. Yaird looks at /etc/fstab for the root partion. Jonas, does it actually know how to look into /target/etc/fstab and not /etc/fstab ? d-i currently does this before installing mkinitrd-tools: # Temporarily hardcode the root partition. rootpart_devfs=$(mount | grep on /target | cut -d' ' -f1) rootpartfs=$(mount | grep on /target | cut -d' ' -f5) rootpart=$(mapdevfs $rootpart_devfs) if [ -f $mkinitrdconf ]; then sed -e s#^ROOT=.*#ROOT='$rootpart $rootpartfs'# $mkinitrdconf $mkinitrdconf.new mv $mkinitrdconf.new $mkinitrdconf else echo ROOT='$rootpart $rootpartfs' $mkinitrdconf fi Appacently Colin has already checked that initramfs-tools doesn't need such a hack, Right; Jeff Bailey has been very clear to me that it can work it out based on what it's told by the bootloader. Some lilo modifications may be needed at some point to pass the root filesystem as a device name rather than in lilo's hex-encoded major/minor form (which I'm told will eventually break due to kernel changes, and probably doesn't work so well for wacky block devices even now), either by changing lilo directly to do that or just by making lilo-installer override it by adding root= to the kernel command line in append=. initramfs-tools does handle lilo's current syntax for the moment, though. What about the wide variety of non-x86 boot loaders ? What about the prep case, where you cannot set default args appart from the kernel command line ? I still think that having the ramdisk content hardcode the root path (overridable on the command line) is a more secure way of doing this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339295: psmouse.c: Failed to reset mouse on isa0060/serio1 - works fine with 2.6.13-1-k7
Maximilian Attems wrote: a quick diff reveals that you boot your 2.6.14 and 2.6.13 with different kernel parameters in ?lilo?. please try to boot 2.6.14 too with pci=noacpi or pci=routeirq that's more an workaround.. bug should be forwarded to acpi upstream. Sorry, but your workaround didn't help, the mouse is neither working with pci=noacpi nor with pci=routeirq. Regards, Joerg. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339304: linux-image-2.6.14-2-k7: please supply kernels capable of addressing 4Gb of memory
On Tue, Nov 15, 2005 at 10:28:27AM +, Andrew Chittenden wrote: Package: linux-image-2.6.14-2-k7 Version: 2.6.14-3 Severity: wishlist I've got a couple of machines based on amd64 with 4Gb of memory. With the stock k7 and k7-smp debian supplied kernels, I can only see 3Gb of k7 and k7-smp are 32bit athlon (not 64) kernels, please don't use them. You probably want amd64-k8 or amd64-k8-smp flavours from the amd64 arch. Even more, you probably want to use a amd64 arch install and not the 32bit i386 one, but i will let others comment on this Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Supporting 2.6.14 kernels in base-installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 15 Nov 2005 13:23:25 +0100 Sven Luther [EMAIL PROTECTED] wrote: On Tue, Nov 15, 2005 at 10:24:41AM +, Colin Watson wrote: On Mon, Nov 14, 2005 at 04:15:36PM -0500, Joey Hess wrote: Jonas Smedegaard wrote: I don't understand what temporary hardcoding of root partition actually means. Yaird looks at /etc/fstab for the root partion. Jonas, does it actually know how to look into /target/etc/fstab and not /etc/fstab ? Nope. As said it looks at /etc/fstab. Have a look at the mkinitrd wrapper: It returns Unsupported to the following options: -d -k -r So if d-i does not run the ramdisk tool chroot'ed then there is indeed a problem. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDeewyn7DbMsAkQLgRArq4AJ9tN6rNRytiwxRUFgqnUR7MZ+ClAQCffN/A qeNEl/oUDhUHDDcDNc0OCLg= =I7a+ -END PGP SIGNATURE-
Bug#339327: linux-2.6: don't display lilo-related messages unless lilo is installed
Package: linux-2.6 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, i sometimes get messages like the following: The link /vmlinuz.old is a damaged link Removing symbolic link vmlinuz.old Unless you used the optional flag in lilo, you may need to re-run lilo The link /initrd.img.old is a damaged link Removing symbolic link initrd.img.old Unless you used the optional flag in lilo, you may need to re-run lilo a simple which lilo could probably determine whether mentioning lilo were appropriate. sean - -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDefRlynjLPm522B0RAt2vAJ9cdSjNHB+Tp/bKg5kisGF4neMeBACfYo3Y FnpeLzJ8gHKVQ5sk5tzy874= =2zcD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
