Bug#316848: kernel-source-2.6.8: BIOS handoff failed error loading ehci_hcd module on Asus P4P800 mainboard
Hi, I noticed this problem earlier in the 2.6 series with an Asus P4P800 Deluxe, and upgrading the BIOS to version 1018 or 1019 (I can't remember which exactly) fixed things... Given the linked discussion on lkml, there might be something else to it though! Regards, Stephen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318691: (fwd) Re: Bug#318691: kernel: pbs with Intel 82801EB/ER USB2 Controller
- Forwarded message from Philippe Monroux [EMAIL PROTECTED] - Bonjour, maximilian attems [EMAIL PROTECTED] a écrit : yes the usb stack of 2.6.8 is known bad. could you send lspci -v and lsmod? perhaps some one will be able to reproduce. lspci -v == :00:00.0 Host bridge: Intel Corp. 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) Subsystem: Asustek Computer, Inc. P4P800 Mainboard Flags: bus master, fast devsel, latency 0 Memory at e000 (32-bit, prefetchable) [size=256M] Capabilities: [e4] #09 [2106] Capabilities: [a0] AGP version 3.0 :00:01.0 PCI bridge: Intel Corp. 82865G/PE/P PCI to AGP Controller (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Memory behind bridge: fa90-fe9f Prefetchable memory behind bridge: bff0-dfef :00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: Asustek Computer, Inc. P4P800 Mainboard Flags: bus master, medium devsel, latency 0, IRQ 169 I/O ports at ef00 [size=32] :00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: Asustek Computer, Inc. P4P800 Mainboard Flags: bus master, medium devsel, latency 0, IRQ 177 I/O ports at ef20 [size=32] :00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02) (prog-if 00 [UHCI]) Subsystem: Asustek Computer, Inc. P4P800 Mainboard Flags: bus master, medium devsel, latency 0, IRQ 185 I/O ports at ef40 [size=32] :00:1d.3 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4 (rev 02) (prog-if 00 [UHCI]) Subsystem: Asustek Computer, Inc. P4P800 Mainboard Flags: bus master, medium devsel, latency 0, IRQ 169 I/O ports at ef80 [size=32] :00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: Asustek Computer, Inc. P4P800 Mainboard Flags: bus master, medium devsel, latency 0, IRQ 193 Memory at febffc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] #0a [20a0] :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 I/O behind bridge: d000-dfff Memory behind bridge: fea0-feaf :00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02) Flags: bus master, medium devsel, latency 0 :00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100 Storage Controller (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: Asustek Computer, Inc. P4P800 Mainboard Flags: bus master, medium devsel, latency 0, IRQ 185 I/O ports at unassigned I/O ports at unassigned I/O ports at unassigned I/O ports at unassigned I/O ports at fc00 [size=16] Memory at 4000 (32-bit, non-prefetchable) [size=1K] :00:1f.3 SMBus: Intel Corp. 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) Subsystem: Asustek Computer, Inc. P4P800 Mainboard Flags: medium devsel, IRQ 201 I/O ports at 0400 [size=32] :00:1f.5 Multimedia audio controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 812a Flags: bus master, medium devsel, latency 0, IRQ 201 I/O ports at e800 [size=256] I/O ports at ee80 [size=64] Memory at febff800 (32-bit, non-prefetchable) [size=512] Memory at febff400 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 :01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 00f2 (rev a2) (prog-if 00 [VGA]) Subsystem: Asustek Computer, Inc.: Unknown device 81b1 Flags: bus master, 66MHz, medium devsel, latency 248, IRQ 169 Memory at fd00 (32-bit, non-prefetchable) [size=16M] Memory at c000 (32-bit, prefetchable) [size=256M] Memory at fc00 (32-bit, non-prefetchable) [size=16M] Expansion ROM at fe9e [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 3.0 :02:05.0 Ethernet controller: Marvell Technology Group Ltd. Yukon Gigabit Ethernet 10/100/1000Base-T Adapter (rev 13) Subsystem: Asustek Computer, Inc.: Unknown device 811a Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 209 Memory at feafc000
Bug#318691: kernel: pbs with Intel 82801EB/ER USB2 Controller
On Sun, 17 Jul 2005, MONROUX philippe wrote: Hello, working on debian sarge MB asus p4p800e deluxe Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller seems to not work correctly. For example when I use a usb external DD with mirrordir I get the following error messages : , | mirrordir: error trying to write to file: /mnt/sda3/root/data.bin: | Input/output error | mirrordir: unable to open file for writing: | /mnt/sda3/root/.wmncach.el: Input/output error ` And I get D'= uninterruptible sleep processus... Is there an issue ? yes the usb stack of 2.6.8 is known bad. could you send lspci -v and lsmod? perhaps some one will be able to reproduce. but i guess 2.6.11 from unstable should work? -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309909: kernel-image-2.6-686-smp: include HPET_EMULATE_RTC option
Package: kernel-image-2.6-686-smp Followup-For: Bug #309909 to have the rtc device with hyperthreading you need the option HPET_EMULATE_RTC this option should be part of the stock kernel if HPET is enabled -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.30-vs1.2.10 Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
Andres Salomon wrote: Alright folks, I think the packaging is ready to be beaten on by people. So, unless anyone has any concerns/problems/etc, I'm going to assume everything's a go for uploading 2.6.12. The current changes and state of the packaging: - source package is called linux-2.6 - binary image packages have been renamed from kernel-image-* to linux-image-*. binary header packages have been renamed from kernel-headers-* to linux-headers-*. kfreebsd/hurd folks, if you have any comments/concerns/requirements, please be sure to let us know. - debian/control is generated from debian/templates/control.*.in, and naming/descriptions should be consistent across the various archs. - config files are generated from the pieces in debian/arch, with management of configs made a lot easier via tools in trunk/scripts (initconfig and split-config). I will probably tweak settings for the global config a bit more; expect some FTBFS for architectures until we figure out which options are safe for everyone, and which options are suitable only for certain archs. - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0 miscompiling things. however, if any architectures require gcc-4.0, either let me know, or update svn directly. - debian/README* and trunks/docs/ has information that kernel team members will find useful to understand the new packaging. - there are 3 patches that were in 2.6.11 that have been dropped due to lack of interest; sparc, alpha, and powerpc folks should determine their value, at some point. FWIW, I gave up on the common kernel package for mips/mipsel for now, and will build mips kernels via a linux-patch package which build-depends on the source .deb. The reasons which prompted me to do so are listed below, vaguely in order of importance. Thiemo Issues of the common kernel package: General problems: - The 2.6 (instead of 2.6.12 etc.) versioning means previous versions are thrown out of the archive, anything which isn't ready until then will lose support. It is IMHO not realistic to expect the rest of the world to wait for some obscure subarchitecture. - Coupling the smallest fix for a subarchitecture to a full upload of the whole arch any package puts pressure on the autobuilder network without much gain, and causes many users to download new kernels identical to the old ones because of the version bump. - E.g. disable CONFIG_PREEMPT for ia64 and let everyone upgrade their kernel. Implementation problems: - A generic header package is used, plus architecture-specific header packages which add some bits like configuration defines and process structure offsets. Architecture-specific header patches aren't taken into account, but are needed for patches outside include/asm-$arch. - Flavour names are assumed to be unique, this doesn't work well for bi-endian machines (e.g. sb1-swarm-bn for mips/mipsel) and 32/64 bit kernels. - Architecture-specific patches are restricted to a single patch per arch/subarch, with an $arch.* naming. This means to copy an identical patch with different name to support mips/mipsel, it also means all patches which may break some other architecture have to go into a single file, which is ridiculous form a maintenance POV. - Architecture-specific patches have no series mechanism, IOW they aren't really updateable. Even if they had, it is not feasible to keep multiple 2MB mips patches around for the whole duration of the 2.6 kernel series. - The current patch system breaks easily down. If one of the patches has a conflict, it is neither possible to unpatch the already applied patches nor does a patch replay help (because the first already applied patch conflicts now). So it's either rm -rf or to work around the patch system. - Only -p1 patches are accepted - no CVS diff patches, originally psted patches can't be used easily. - If $EDITOR leaves a ~ backup file in the series directory, the patch system doesn't check if the series name is valid and tries to apply the copy as well. - Same goes for the control file generation, some moved away directory gets searched for control.in files as well, no check for valid arch names or the resulting duplicate package definitions. - The resulting control file suggests every available bootloader for each image, with an [ $arch ] specifier. This is generally ugly and doesn't help for e.g. mipsel subarches with per-subarch bootloaders (colo, delo, sibyl). - The shell-snippets-disguised-as-makerules generally fails to catch errors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
On Sat, 16 Jul 2005 16:55:42 +0300, Horms wrote: On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote: [...] - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0 miscompiling things. however, if any architectures require gcc-4.0, either let me know, or update svn directly. How are you planing to do that. I need to do something about the fact that users go and grab kernel-source-2.4.27 and it doesn't compile with the default gcc any more. Here are three solutions I have thought. 1. Document this somewhere 2. Change the makefile to default to gcc-3.3 3. Change the makefile to print out a nice error if gcc version =4.0 In all cases it seems it would be good to recommend gcc-3.3. Actually, enough people on IRC have said that gcc-4.0 works for that, that I'm not convinced gcc-3.3 is necessary. I'm on the fence, I could go either way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
On Sun, 17 Jul 2005 00:36:38 -0400, Jurij Smakov wrote:
On Sun, 17 Jul 2005, Bastian Blank wrote:
On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote:
Hm, anything I'm forgetting?
- The scripts dir in the linux-headers package must match the flavour.
The problem here is that some architectures (s390, powerpc and mips) are
using two different ELF formats, depending on the options in kernel config
file. So, building different flavours for s390, for example, will produce
*Ew*
two different (incompatible) sets of executables in scripts/ subdir. As we
are currently including scripts/ directory only in the arch-common headers
package, that will be broken on the architectures. A simple solution:
include scripts/ subdirectory into the flavour-specific headers package.
Probably, it makes sense to do it only for architectures which actually
need that. I'll check what I can cook up.
- The descriptions are wrong for non-i386.
I am not too happy with how the decscription stuff turned out. I think
that the boilerplate descriptions should be generated only if the custom
descriptions are not provided, and there should be a Makefile.inc variable
controlling it. I suggest that support for custom descriptions be
restored.
This is not something I consider to be a major problem. We can either
figure out a way to make descriptions overridable on a per-{sub,}arch
basis, or revert to the per-arch control.in templates; I think the value
of having them all generated from the same template file is valuable,
however. Just looking at the number of archs that lacked ABINAMEs, or had
things hardcoded, or just skewed from convention made me think that it
would be better in the long run to force archs to all be the same wrt
package names and descriptions. For each arch/flavour, we really only
want to override small bits of each; if s390 is really that radically
different wrt description, we can even hardcode something in debian/rules
for now that does something special for s390's variable replacement.
- Dependencies with arch spec for one-arch packages.
Right, the control file is full of the packages with control fields like
this:
Architecture: powerpc
Depends: initrd-tools (= 0.1.78), coreutils | fileutils (= 4.0),
module-init-tools (= 0.9.13), e2fsprogs (= 1.35-7) [amd64], palo [hppa],
mkvmlinuz [powerpc]
The non-powerpc dependencies will probably not break anything, but
introduce a lot of additional clutter. I understand that it's easier that
way, but having only relevant dependencies listed would be cleaner. And,
to improve readability, it would be nice to have all the control file
generation logic moved to a separate script, which may be called from the
the rules file.
I disagree. I did it this way because I prefer to see exactly what
architectures are using for their boot loaders, etc. That's just my
preference.
- linux-headers-.*-all is no dummy package.
As Bastian pointed out, currently this package does not build. I can
implement it and adjust the description.
I'm not sure what is meant by this, but I'll look closer..
Best regards,
Jurij Smakov[EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
On Sun, 17 Jul 2005 04:15:39 +0200, Bastian Blank wrote: On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote: Hm, anything I'm forgetting? [...] - The shell-code is unreadable. So fix it? :) I'm still planning on using cdbs2 for packaging in the long term, anyways. The single-source packaging framework is mostly a reimplementation of things jbailey and I have already done for cdbs2. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[shorty: Re: 2.6.12 debian powerpc kernels and ppc64 ...]
The first try to send the message below didn't work. Hoping it does now ... :) Regards Wolfgang - Forwarded message from Wolfgang Pfeiifer - To: Sven Luther [EMAIL PROTECTED] Cc: debian-powerpc@lists.debian.org, debian-kernel@lists.debian.org, linux-kernel@vger.kernel.org Subject: Re: 2.6.12 debian powerpc kernels and ppc64 ... Date: Mon, 18 Jul 2005 22:17:37 +0200 User-Agent: Mutt/1.5.9i X-URL: http://www.wolfgangpfeiffer.com On Mon, Jul 18, 2005 at 07:23:05AM +0200, Sven Luther wrote: On Sun, Jul 17, 2005 at 07:52:30PM +0200, Wolfgang Pfeiffer wrote: Hi Sven On Fri, Jul 15, 2005 at 11:04:17PM +0200, Sven Luther wrote: Hello, I would like testers who want to test new powerpc kernels on ppc64 machines : These i have uploaded here : http://people.debian.org/~luther/ppc64/kernel-image-2.6.12-sven_1_powerpc.deb At least the latter one works here. Or at least it boots here without any probs, as it seems .. : $ uname -a Linux debby 2.6.12-sven #1 Fri Jul 15 13:44:26 UTC 2005 ppc GNU/Linux $ cat /proc/cpuinfo processor : 0 cpu : 7455, altivec supported clock : 867MHz revision: 0.2 (pvr 8001 0302) bogomips: 865.18 machine : PowerBook3,5 motherboard : PowerBook3,5 MacRISC2 MacRISC Power Macintosh detected as : 80 (PowerBook Titanium IV) pmac flags : 001b L2 cache: 256K unified memory : 768MB pmac-generation : NewWorld As was expectet, the 64bit is the one i am not sure about. But how come this kernel still does not have the necessary patches applied to run kismet: Please provide a bug report with this info, No. Please see: http://lkml.org/lkml/2004/8/27/303 As you can see I sent them a bug report once. It won't happen again in the foreseeable future. And as you also can see from the thread info on the left-hand bar of that page nobody seemed to be interested in the problem. IIRC I could not compile for weeks or perhaps even months a new 2.4 kernel version because of the mentioned errors. i will apply as soon as i am back in 2 weeks, if someone from the kernel team doesn't beat me to it. The site for the patch I used, IIRC: http://www.kismetwireless.net/download.shtml#orinoco2611 wget http://www.kismetwireless.net/code/orinoco-2.6.12-rfmon-dragorn-1.diff The md5sum for the latter that I have here is 41fb7cec09f4de93cd2432eb1aceba92 So if yours will be different you can let me know. And I applied the patch to 2.6.12. Or better: I probably patched a 2.6.11 (tarball) source with patch-2.6.12.bz2, and then applied the above orinoco patch. (Uncertainty because it's already a few weeks ago I compiled this kernel ... ) And just in case it might help someone else: The following snippet might serve as an example of how to compile this more or less wifi ready patched source [Please check for yourself in case I made any mistakes ... :) ... ]: tar xzvf linux-2.6.11.tar.gz cd linux-2.6.11/ bzip2 -cd /path/to/patch-2.6.12.bz2 | patch -p1 [then applying the orinoco patch from above] cp /boot/someconfig . make oldconfig fakeroot make-kpkg clean time MAKEFLAGS=CC=gcc-4.0 fakeroot make-kpkg --append-to-version=-somename --revision +anothername kernel_image or time MAKEFLAGS=CC=gcc-4.0 fakeroot make-kpkg --append-to-version=+orinoco-patched --revision +050703 kernel_image HTH Thanks for responding, Sven ... and yes: for your work, too :) And sorry for refusing to play nice if things run ugly .. Best Regards Wolfgang -- Wolfgang Pfeiffer http://profiles.yahoo.com/wolfgangpfeiffer - End forwarded message - -- Wolfgang Pfeiffer http://profiles.yahoo.com/wolfgangpfeiffer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
On Mon, 18 Jul 2005 15:19:05 +0200, Thiemo Seufer wrote: Andres Salomon wrote: Alright folks, I think the packaging is ready to be beaten on by people. So, unless anyone has any concerns/problems/etc, I'm going to assume everything's a go for uploading 2.6.12. The current changes and state of the packaging: - source package is called linux-2.6 - binary image packages have been renamed from kernel-image-* to linux-image-*. binary header packages have been renamed from kernel-headers-* to linux-headers-*. kfreebsd/hurd folks, if you have any comments/concerns/requirements, please be sure to let us know. - debian/control is generated from debian/templates/control.*.in, and naming/descriptions should be consistent across the various archs. - config files are generated from the pieces in debian/arch, with management of configs made a lot easier via tools in trunk/scripts (initconfig and split-config). I will probably tweak settings for the global config a bit more; expect some FTBFS for architectures until we figure out which options are safe for everyone, and which options are suitable only for certain archs. - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0 miscompiling things. however, if any architectures require gcc-4.0, either let me know, or update svn directly. - debian/README* and trunks/docs/ has information that kernel team members will find useful to understand the new packaging. - there are 3 patches that were in 2.6.11 that have been dropped due to lack of interest; sparc, alpha, and powerpc folks should determine their value, at some point. FWIW, I gave up on the common kernel package for mips/mipsel for now, and will build mips kernels via a linux-patch package which build-depends on the source .deb. The reasons which prompted me to do so are listed below, vaguely in order of importance. Thiemo Issues of the common kernel package: General problems: - The 2.6 (instead of 2.6.12 etc.) versioning means previous versions are thrown out of the archive, anything which isn't ready until then will lose support. That's correct. This is why we'll end up w/ two different kernel versions in unstable and testing. This is a feature, not a bug; we don't want to carry around 20 different kernel versions because an architecture can't get its act together. It is IMHO not realistic to expect the rest of the world to wait for some obscure subarchitecture. Who said we're going to wait for some obscure subarchitecture? We're going to keep working on kernels until we freeze for etch, at which point the subarchitectures have a limit amount of time to catch up. I'd hope they'd be able to keep up all along, but I'm not sure whether that'll be the case. Regardless, if architectures can all catch up at some point, we can get a kernel in testing that supports most everything; come freeze time, it becomes real easy to stabilize. We'll still need to organize and figure out what we'll be able to offer, and what sub/niche-archs we'll have to drop. I suspect working from the same source package will force us to communicate a bit more often, as well. :) - Coupling the smallest fix for a subarchitecture to a full upload of the whole arch any package puts pressure on the autobuilder network without much gain, and causes many users to download new kernels identical to the old ones because of the version bump. - E.g. disable CONFIG_PREEMPT for ia64 and let everyone upgrade their kernel. I don't think this will be an issue; we have enough development happening at a given time that we can probably just do regularly scheduled releases, w/ various architectures doing updates at the same time. We also have enough security updates happening that we'll need to release pretty regularly.. (blah). Bah, the long list below makes my head hurt. I'll ignore a bunch of stuff that I consider problems we can defer until some other time.. ;p Implementation problems: - A generic header package is used, plus architecture-specific header packages which add some bits like configuration defines and process structure offsets. Architecture-specific header patches aren't taken into account, but are needed for patches outside include/asm-$arch. Architecture-specific patches will be handled by subarch stuff. However, given that nothing else is using the subarch stuff yet, and it's pretty untested, I'll repeat what I said on IRC for the people playing along at home; we'll skip mips/mipsel for now, and try to get it into the linux-2.6 package in the near future. - Flavour names are assumed to be unique, this doesn't work well for bi-endian machines (e.g. sb1-swarm-bn for mips/mipsel) and 32/64 bit kernels. If subarches are to be used, then I assume each will have a different subarch name. So, for example, linux-headers-mips-2.6.12-1 will be depended
Re: 2.6.12 upload
On Mon, 18 Jul 2005 21:03:39 +0200, Thiemo Seufer wrote: Andres Salomon wrote: [snip] - Dependencies with arch spec for one-arch packages. Right, the control file is full of the packages with control fields like this: Architecture: powerpc Depends: initrd-tools (= 0.1.78), coreutils | fileutils (= 4.0), module-init-tools (= 0.9.13), e2fsprogs (= 1.35-7) [amd64], palo [hppa], mkvmlinuz [powerpc] The non-powerpc dependencies will probably not break anything, but introduce a lot of additional clutter. I understand that it's easier that way, but having only relevant dependencies listed would be cleaner. And, to improve readability, it would be nice to have all the control file generation logic moved to a separate script, which may be called from the the rules file. I disagree. I did it this way because I prefer to see exactly what architectures are using for their boot loaders, etc. That's just my preference. The bootloader dependencies need to be per flavour. It makes no sense to depend on N bootloaders for an architecture where N-1 are unusable for the specific flavour's kernel image. I'm assuming this is a mips-specific thing, because I haven't heard of the case w/ any other archs where each flavour requires a different bootloader. Anyways, if that is the case, then yes; we'll need to make this per-flavour (gah). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318955: /etc/init.d/initrd-tools.sh should run umount with -n option
Package: initrd-tools Version: 0.1.81.1 Severity: minor /etc/init.d/initrd-tools.sh runs at S:S05initrd-tools.sh before the root filesystem has been remounted read-write at S10checkroot.sh. All the umount commands in the script should include the -n option so that there is no attempt to write the mtab file at this stage. umount proceeds despite failure to open mtab for writing, but this behavior of the current umount program should not be relied upon. [EMAIL PROTECTED]:/mnt/hda6/etc/rcS.d$ grep umount S05initrd-tools.sh trap 'umount -n /proc' EXIT umount /initrd/dev || exit umount /initrd || exit -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
Andres Salomon wrote: [snip] It is IMHO not realistic to expect the rest of the world to wait for some obscure subarchitecture. Who said we're going to wait for some obscure subarchitecture? We're going to keep working on kernels until we freeze for etch, at which point the subarchitectures have a limit amount of time to catch up. The problem is the ongoing development in unstable. It is e.g. not possible to build debian-installer for that subarch and upload it if its kernel isn't already/still in unstable. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
Andres Salomon wrote: [snip] - Dependencies with arch spec for one-arch packages. Right, the control file is full of the packages with control fields like this: Architecture: powerpc Depends: initrd-tools (= 0.1.78), coreutils | fileutils (= 4.0), module-init-tools (= 0.9.13), e2fsprogs (= 1.35-7) [amd64], palo [hppa], mkvmlinuz [powerpc] The non-powerpc dependencies will probably not break anything, but introduce a lot of additional clutter. I understand that it's easier that way, but having only relevant dependencies listed would be cleaner. And, to improve readability, it would be nice to have all the control file generation logic moved to a separate script, which may be called from the the rules file. I disagree. I did it this way because I prefer to see exactly what architectures are using for their boot loaders, etc. That's just my preference. The bootloader dependencies need to be per flavour. It makes no sense to depend on N bootloaders for an architecture where N-1 are unusable for the specific flavour's kernel image. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#317982: udev: Does not properly add/remove usb disk drives
On Sun, Jul 17, 2005 at 01:30:41PM +0200, Kurt Roeckx wrote: On Sun, 2005-07-17 at 09:44 +0200, Kurt Roeckx wrote: Horms [EMAIL PROTECTED] wrote: Hi Kurt, Could you please send the output of lsmod and lspci -v, hopefully your hardware is reasonably common and i can reproduce this problem. However, a quick fix might be to try the 2.6.11 kernels in unstable. I'll try the 2.6.11 kernel later. The 2.6.11-7 kernel seems to work without problems. Thanks, that is valuable information. I'll try and isolate the fix (please feel free to help there), but if its a massive backport its never going to be done. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
On Mon, Jul 18, 2005 at 12:20:31PM -0400, Andres Salomon wrote: On Sat, 16 Jul 2005 16:55:42 +0300, Horms wrote: On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote: [...] - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0 miscompiling things. however, if any architectures require gcc-4.0, either let me know, or update svn directly. How are you planing to do that. I need to do something about the fact that users go and grab kernel-source-2.4.27 and it doesn't compile with the default gcc any more. Here are three solutions I have thought. 1. Document this somewhere 2. Change the makefile to default to gcc-3.3 3. Change the makefile to print out a nice error if gcc version =4.0 In all cases it seems it would be good to recommend gcc-3.3. Actually, enough people on IRC have said that gcc-4.0 works for that, that I'm not convinced gcc-3.3 is necessary. I'm on the fence, I could go either way. I for one haven't been able to compile 2.4.27 (from sarge) with gcc-4.0, it dies horribly, and as I understand there is no interest uptream in making 2.4 friendly to gcc-4.0. Sure it might work for some configurations, but I'm pretty sure its broken for enough that its a problem, the 686 config in sarge for starters. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
On Sun, Jul 17, 2005 at 12:29:47AM +0200, Sven Luther wrote: On Sat, Jul 16, 2005 at 04:55:42PM +0300, Horms wrote: On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote: Alright folks, I think the packaging is ready to be beaten on by people. So, unless anyone has any concerns/problems/etc, I'm going to assume everything's a go for uploading 2.6.12. Excellent The current changes and state of the packaging: - source package is called linux-2.6 - binary image packages have been renamed from kernel-image-* to linux-image-*. binary header packages have been renamed from kernel-headers-* to linux-headers-*. kfreebsd/hurd folks, if you have any comments/concerns/requirements, please be sure to let us know. - debian/control is generated from debian/templates/control.*.in, and naming/descriptions should be consistent across the various archs. - config files are generated from the pieces in debian/arch, with management of configs made a lot easier via tools in trunk/scripts (initconfig and split-config). I will probably tweak settings for the global config a bit more; expect some FTBFS for architectures until we figure out which options are safe for everyone, and which options are suitable only for certain archs. - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0 miscompiling things. however, if any architectures require gcc-4.0, either let me know, or update svn directly. How are you planing to do that. I need to do something about the fact that users go and grab kernel-source-2.4.27 and it doesn't compile with the default gcc any more. Here are three solutions I have thought. 1. Document this somewhere 2. Change the makefile to default to gcc-3.3 3. Change the makefile to print out a nice error if gcc version =4.0 4. ask for removal of 2.4.27 from etch/sid :) Yes, sorry I forgot that one, its currently my prefered option. But perhaps one of the other three is more appropruiate for the short-term. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
