Bug#284194: kernel-headers-2.4.27-1-sparc32: file missing for sparc32: include/asm-sparc/asm_offsets.h
Package: kernel-headers-2.4.27-1-sparc32 Version: 2.4.27-1 Severity: important Hi, You probably got kernel-headers-2.4.27-1 from a sparc64 build and now sparc32 is messed up. 1. include/asm-sparc/asm_offsets.h is missing but still referenced by include/asm-sparc/ptrace.h, giving you a nice compilation error 2. something else is totally messed up, too. The alsa-driver-1.0.7 from http://www.alsa-project.org does not compile, giving LOTS of errors for e.g. sun-amd7930 module. I do this to test the new sun-dbri alsa module as discussed in the debian-sparc mailing list(2004-11-21). Note that compiling my own kernel (without versioned symbols and without initrd and without kernel audio modules) makes the alsa-driver package compile! So the compilation errors definitely come from this package! The errors shown are posted here: http://lists.debian.org/debian-sparc/2004/11/msg00162.html And thats already after I worked around point 1 above! HS -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: sparc Kernel: Linux 2.4.27 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kernel-headers-2.4.27-1-sparc32 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii kernel-headers-2.4.27-1 2.4.27-1 Header files related to Linux kern -- no debconf information
Bug#273638: Slowdown on Latidude D600
Package: kernel-image-2.6.8-1 Version: 2.6.8-10 After an upgrade from whatever previous version of kernel-image-2.6.8-1 was on my system (APT really should have some logging) to version 2.6.8-10, the touchpad mouse became unresponsive, and keyboard input became sluggish. So sluggish that it was unusable. This system is a laptop, as well. It's a Dell Latitude D600, with 1GB of RAM, and a 1.7GHz Pentium M. I'm back to my trusty old 2.6.4 kernel, and waiting for the next 2.6.8, or perhaps 2.6.9
Bug#284213: system noise when using ACPI module processor
Package: kernel-source-2.6.8 Severity: minor Version: 2.6.8-10 Hi! There is a problem with ACPI module processor in recent 2.6er kernels. After loading this module my pentium-m notebook (ACER TM291) makes a very high-pitched sound (not the fan) on idle. It sounds like an old CRT monitor shortly before its end. :-) It's caused by a change in include/asm-i386/param.h, where HZ was set from 100 to 1000. I have already send my notebook back to the vendor for repair the singing capacitor on the mainboard, but I got it back unrepaired. They could not reproduce this behavoiur under Windows. :-( This uses a 100Hz timer, so I have no chance of repair. Google tells, it is a known problem which was previously discussed at Kernel Bug Tracker. http://bugme.osdl.org/show_bug.cgi?id=2478 http://bugme.osdl.org/show_bug.cgi?id=3549 http://bugme.osdl.org/show_bug.cgi?id=3406 But the patch for #define HZ was rejected. Since I'm not sure that the found solution (disabling of C3) is the best solution and this patch will be included in 2.6.10, I'd like to ask you for a Debian patch to switch back to HZ=100. Please consider to add attached patch. I like the distribution kernel very much (together with m-a) and it would be a pity to have to build my own kernel caused by this issue. Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * --- linux-2.6.7/include/asm-i386/param.h 2004-06-17 09:34:28.0 +0800 +++ linux-2.6.7-new/include/asm-i386/param.h 2004-07-19 13:30:54.207125536 +0800 @@ -2,7 +2,7 @@ #define _ASMi386_PARAM_H #ifdef __KERNEL__ -# define HZ 1000 /* Internal kernel timer frequency */ +# define HZ 100 /* Internal kernel timer frequency */ # define USER_HZ 100 /* .. some user interfaces are in ticks */ # define CLOCKS_PER_SEC (USER_HZ) /* like times() */ #endif pgpB7dj23fYyf.pgp Description: signature
Bug#284221: utter lack of acenic drivers on i386, hppa
Package: kernel Severity: normal I have a hppa a500 with two pci nics in it: :10:00.0 0200: 12ae:0001 (rev 01) :10:00.0 Ethernet controller: Alteon Networks Inc. AceNIC Gigabit Ethernet (rev 01) :20:00.0 0200: 12ae:0001 (rev 01) :20:00.0 Ethernet controller: Alteon Networks Inc. AceNIC Gigabit Ethernet (rev 01) Discover says to use the acenic driver for these, but it does not seem to be available in the 2.4 or 2.6 kernels for hppa or i386. I do see the driver the the kernel source so please turn it on. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- see shy jo signature.asc Description: Digital signature
Bug#284221: utter lack of acenic drivers on i386, hppa
On Sat, Dec 04, 2004 at 12:18:01PM -0500, Joey Hess wrote: Discover says to use the acenic driver for these, but it does not seem to be available in the 2.4 or 2.6 kernels for hppa or i386. I do see the driver the the kernel source so please turn it on. I thought the anti-firmware fanatics had decreed we couldn't ship this driver? -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain
Processed: Re: Bug#284221: utter lack of acenic drivers on i386, hppa
Processing commands for [EMAIL PROTECTED]: tags 284221 + wontfix Bug#284221: utter lack of acenic drivers on i386, hppa There were no tags set. Tags added: wontfix thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#284221: utter lack of acenic drivers on i386, hppa
Matthew Wilcox wrote: On Sat, Dec 04, 2004 at 12:18:01PM -0500, Joey Hess wrote: Discover says to use the acenic driver for these, but it does not seem to be available in the 2.4 or 2.6 kernels for hppa or i386. I do see the driver the the kernel source so please turn it on. I thought the anti-firmware fanatics had decreed we couldn't ship this driver? That could very well be.. -- see shy jo signature.asc Description: Digital signature
Bug#284221: utter lack of acenic drivers on i386, hppa
On Sat, Dec 04, 2004 at 01:01:33PM -0500, Kyle McMartin wrote: * ACENIC firwmare, driver disabled: . drivers/net/acenic_firmware.h So there's a good reason why you're unable to use these cards. ITYM good reason to switch to Ubuntu, Gentoo or Fedora. HTH. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain
Bug#270743: This is most probably a hardware problem
Hi, I suffered from the same problem for quite some time now. It was obviously a loose-fitting display data connector on the logic board. Re-seating the connector solved it for me. See http://www.pbfixit.com/Guide/51.16.13.html (middle image) Cheers, -- Michael message composed with VIM - Vi IMproved 6.3 (2004 June 7, compiled Jun 18 2004 11:44:00)
Bug#283603: nForce2. forcedeth network driver loads with 2.6, but not with 2.4
On Mon, Nov 29, 2004 at 07:32:46PM -0800, Andriy Palamarchuk wrote: Package: installation-reports Debian-installer-version: Installer rc2, got on November 29 from http://cdimage.debian.org/pub/cdimage-testing/sarge_d-i/i386/rc2/sarge-i386-netinst.iso snip/ Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [E] Config network: [ ] Detect CD: [ ] Load installer modules: [ ] snip/ Comments/Problems: Summary: Initialization of forcedeth network driver fails with the provided 2.4 kernel, however the driver initializes succcessfully if running 2.6 kernel (when the installation is started with linux26 on the installation prompt. The machine has installed Mandrake 10 Steps to reproduce: 1) Booting from CD, accepting all the default choices. 2) Get to the page with message no ethernet card was detected and list of network drivers. Select forcedeth driver. 3) Get message forcedeth driver failed to load, I am requested driver parameters. Don't choose anything, hit Enter - again get the list from step 2. Note, the driver loads with 2.6. Steps to reproduce: 1) Booting from CD, specifing linux26 on the initial prompt, hit Enter, accept all the default choices 2) Get to the page with message no ethernet card was detected and list of network drivers. Select forcedeth driver. 3) Autoconfiguration runs successfully, network detected, I am requested to configure DHCP client. Let me know if you need more information. Could you do a complete install with a 2.6 kernel? Regards, Andriy Palamarchuk Cheers Geert Stappers signature.asc Description: Digital signature
error in apt-get upgrade process
Why is apt-get -f u upgrade asking me now to upgrade to kernel-image-2.4.27-1-k7? This box is on unstable * kernel-image-2.6.9-1-k7. Several times over the past several weeks already upgraded kernel-images have been upgraded to the SAME image. During those upgrades the initrd.img link has been invariably removed with nothing left in place. A new link had to be created manually for the lilo boot process to work. Fun for an ancient FORTUNE SYSTEMS and ALTOS ATT UNIX tech support guy, but time consuming. I have done an apt-get check, clean, autoclean followed by update then upgrade, same result. Thanks, Norm Rosen [EMAIL PROTECTED] apt-get -f -u upgrade this time produced: Reading Package Lists... Building Dependency Tree... The following packages will be upgraded: base-config base-passwd kernel-image-2.4.27-1-k7 libglib2.0-0 libglib2.0-dev libpng10-0 libpng12-0 libpng12-dev libpng2 libpng3 libwine libwine-dev libwine-print libwine-twain mysql-admin mysql-admin-common mysql-query-browser mysql-query-browser-common whois wine wine-doc wine-utils 22 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 35 not fully installed or removed. Need to get 32.2MB of archives. After unpacking 3635kB of additional disk space will be used. Do you want to continue? [Y/n]
mkinitrd module detection
Hi, This is a proposal to improve mkinitrd by reusing code from the hotplug project to determine which modules are needed on the initrd image to support block devices. It is an alternative to an earlier proposal to make devices in sysfs point to the module that implements their driver. It improves on the original proposal in the following ways: - no kernel changes required, so will work with older 2.6 kernels - can cope with differences between modules in running kernel and new kernel; as an example, it understands that a USB stick in 2.6.8 needs usb-storage, but in 2.6.9 will need the ub module. The original proposal and the problems motivating it are discussed in: - http://marc.theaimsgroup.com/?l=linux-scsim=109570145108639w=2 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=263169 The method is simple: mkinitrd runs under an old kernel on some hardware, and it needs to find the minimal set of modules needed to boot a new kernel on that hardware. Sysfs describes the hardware, complete with device identifiers, and a module map provided with the new kernel describes which modules are needed to operate a particular piece of hardware. Finally, modules.dep shows which support modules must be loaded before a module can be loaded. Hotplug uses this same information to load modules for a new device into a running kernel. In fact hotplug and mkinitrd are two sides of the same coin: hotplug finds modules for available hardware given a running kernel, and mkinitrd finds modules for some kernel given available hardware. So I copied the module table processing from hotplug and adapted it to use tables from a different kernel. After that, it's only a matter of identifying which hardware devices are used to implement block devices; essentially that's just /sys/block/*/device/. One little twist: if you're using for example a USB stick, you need not only the USB driver, but also the PCI driver for the bus that the USB host is attached to. The pathname of the device in /sys/devices identifies all such parent devices. The attached script implements this method, and seems to give more or less correct answers on a machine with SATA drive (although I wonder about the location of ide0 in sysfs): [EMAIL PROTECTED]:/dat/tmp$ uname -r 2.6.8-1-686 [EMAIL PROTECTED]:/dat/tmp$ sh joke4 === /sys/block/hda devno 3:0 at: /sys/devices/ide0/0.0 needs: === /sys/block/sda devno 8:0 at: /sys/devices/pci:00/:00:1f.2/host0/0:0:0:0 needs: ata_piix === /sys/block/sdb devno 8:16 at: /sys/devices/pci:00/:00:1d.7/usb5/5-4/5-4.3/5-4.3:1.0/host7/7:0:0:0 needs: ehci-hcd usbcore usbcore usb-storage recommended module load order: /lib/modules/2.6.8-1-686/kernel/drivers/scsi/libata.ko /lib/modules/2.6.8-1-686/kernel/drivers/scsi/scsi_mod.ko /lib/modules/2.6.8-1-686/kernel/drivers/scsi/ata_piix.ko /lib/modules/2.6.8-1-686/kernel/drivers/usb/core/usbcore.ko /lib/modules/2.6.8-1-686/kernel/drivers/usb/host/ehci-hcd.ko /lib/modules/2.6.8-1-686/kernel/drivers/ide/ide-core.ko /lib/modules/2.6.8-1-686/kernel/drivers/usb/storage/usb-storage.ko [EMAIL PROTECTED]:/dat/tmp$ sh joke4 2.6.10-rc2-e === /sys/block/hda devno 3:0 at: /sys/devices/ide0/0.0 needs: === /sys/block/sda devno 8:0 at: /sys/devices/pci:00/:00:1f.2/host0/0:0:0:0 needs: ata_piix === /sys/block/sdb devno 8:16 at: /sys/devices/pci:00/:00:1d.7/usb5/5-4/5-4.3/5-4.3:1.0/host7/7:0:0:0 needs: ehci-hcd usbcore usbcore ub recommended module load order: /lib/modules/2.6.10-rc2-e/kernel/drivers/scsi/libata.ko /lib/modules/2.6.10-rc2-e/kernel/drivers/scsi/scsi_mod.ko /lib/modules/2.6.10-rc2-e/kernel/drivers/scsi/ata_piix.ko /lib/modules/2.6.10-rc2-e/kernel/drivers/usb/core/usbcore.ko /lib/modules/2.6.10-rc2-e/kernel/drivers/usb/host/ehci-hcd.ko /lib/modules/2.6.10-rc2-e/kernel/drivers/block/ub.ko [EMAIL PROTECTED]:/dat/tmp$ I'm looking for comments: could this approach be made to work, and if so what would be the best way to go about moving from this proof of concept to something that could be used as part of a complete mkinitrd? Regards, Erik # # Given a kernel version (default the running kernel) # print an ordered minimal list of all files that must # be loaded into that kernel in order for all block # devices to be operational. # # A large part of this script is copied from the hotplug package, # http://linux-hotplug.sourceforge.net/ # # This software may be used and distributed according to the terms # of the GNU General Public License, incorporated herein by reference.