Re: [PROPOSAL] 2.4.27 as default 2.4 kernel for sarge
On Fri, Aug 27, 2004 at 10:47:29AM +0200, Matthias Klose wrote: > > It will be 2.6.8. > > If you write 2.6.8, do you mean 2.6.8.1? Or is the diff to .1 included > in the Debian packages? I cannot find a hint and the version number is > misleading. Given the diff to .1 is tiny and four-digit version numbers are breaking lots of things (there's even rumors of breaking the nptl detection in glibc, but given that debian _still_ doesn't have a tls-capable toolchain on ppc I couldn't test it) we've decided to stay with 2.6.8. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer on ppc64
On Fri, Nov 14, 2003 at 11:22:27AM +0100, Sven Luther wrote: > > 1. Installer requires devfs support. In 2.6 devfs is pretty much > >deprecated, so it would be nice if d-i could handle a non devfs kernel. > >It doesnt look like there are too many places that care. The initrd had > >an empty /dev, thats easily fixed. It looks like the stuff that parses > >/proc/partitions expects devfs style names but I havent looked into the > >code yet. > > Past discussion about these issues suggest that devfs is indeed needed, > but will not be enabled by default if you don't pass the devfs=mount or > something such command. My personal experience on this subject doesn't > seem to support this theory, at least for 2.6 kernels. ?? devfs is marked deprecated in 2.6. And the devfs names in /proc/partitions thing is a 2.4 bug when devfs is enabled. /proc/partitions shouldn't show device names at all, just unique identifiers for devices. That's what it has always done, except for Linux 2.4 with devfs enabled. > Same as above, d-i doesn't support subarches yet. That said, parted > should be available, and normally you should be able to use partitioner > and/or autopartkit transparently. What partitioning scheme are your box > using ? > > > 4. shm is not a valid filesystem in 2.6. Changing /sbin/init to use > >tmpfs fixed this. > > Mmm, no idea about this one, maybe a special 2.6 kernel support for d-i > would be nice to have, a bit like woody's boot-floppies supported 2.2 > and 2.4 kernels ? shm is just an alias to tmpfs on 2.4 kernel. You should always use the tmpfs name. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel, devfs and /proc/partitions question.
On Tue, Dec 16, 2003 at 11:46:38AM +0100, Sven Luther wrote: > Furthermore. If devfs is not mounted, devfs should have no influence > whatsoever on the running kernel, right ? Unfortunately devfs is a broken POS, so in 2.4 it has quite a lot.. > The problem is that i am running the powerpc kernel without any devfs > option, and not built with devfs-automount, but altough the df output > seems ok, /proc/partitions seems to show the devfs volumes. Yes, that's a known bug in 2.4 kernels, and is fixed in Linux 2.6. > Is this the correct and expected behavior ? What do other people > (popwerpc users or not) see here ? And can this be safely ignored, or > will it cause problems later with non devfs mounted kernels ? It's not correct, but expected. Better don't use devfs. (Yeah, I know the d-i folks don't get it, but fortunately I hope I won't ever have to reinstall Debian on this box :)) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: G5 install?
On Thu, Jul 08, 2004 at 12:19:24AM -0700, Brad Boyer wrote: > The 20040707 image does seem to fix this specific problem, and it now > gets into the installer. It still locks up later while handling the > disks, in the same approximate spot that it does when using the 2.4 > kernel. I'll see what I can do to pin down exactly where it crashes. The same happens here for me. I don't get any kernel messages, even when doing dmesg -n 8 before. I suspect it's a kernel issue somehow. Is there some way to kinda single-step through d-i? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: G5 install?
On Sat, Jul 10, 2004 at 12:56:06PM -0700, Brad Boyer wrote: > It seems bad to me for one of these scripts to be so sure that it can > load a particular module, when the rest of the install is pretty > careful to allow a user in expert mode to override module selection. > Of course, loading a module shouldn't really crash the machine, but > that's another story. The problem with floppy.o and a few other ISA-aera modules is that they randomly poke into the I/O space - something that will crash lots of machines, including macs. But AFAIK there's no power4 or ppc970-based machine with a floppy driver, so shouldn't we just drop that driver? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed to insert STA entry for the AP (error -2)
Hi all, adding the debian-kernel list due to issues with using debian-installer daily snapshot to install on my brand new laptop with an ath11k_pci supported wifi chip. It turns out that while d-i comes with the ath11k and ath11k_pci drivers, but misses the qrtr, qrtr-mki and michael_mic modules that are needed for the driver to actually work and not just load. On Wed, Dec 07, 2022 at 02:49:37PM +0200, Kalle Valo wrote: > Thanks. But this makes me wonder is it sensible to randomly install a > set of .ko files and drop the rest, like Debian's installer apparently > does? The dependency for drivers is pretty well documented in Kconfig > files, thanks to build testers testing with random configurations, but > if the installer omits all that there will be problems just like you are > experiencing. So for me MODULE_SOFTDEP() feels just like a band aid and > not a robust solution. I think a driver that a driver that has a runtime depedency on a certain module, but doesn't import symbols is always going to be somewhat problematic. But I also agree that the arbitrary splitting of kernel modules into separate packages for the installer, or in fact not packaging them at all for the installer is rather problematic. I'm not sure what the rationale is behind that, but I've added the debian-kernel and debian-boot lists. > Though I am happy to take your MODULE_SOFTDEP() patch, just wondering if > there is a better way to solve this. For example net/mac80211 (the > 802.11 stack) has a lot of crypto dependencies: > > select CRYPTO > select CRYPTO_LIB_ARC4 > select CRYPTO_AES > select CRYPTO_CCM > select CRYPTO_GCM > select CRYPTO_CMAC > select CRC32 > > And it's not using MODULE_SOFTDEP() at all. Yes. I'm not quite sure how the packages for d-i select which modules to include where, but given that other wifi hardware seems to work in the installer they must have figured this out somehow.
enabling CONFIG_IDEDMA_ONLYDISK
We have tons of reports for broken CDs in the BTS, and I noticed that unlike the commercial distibution vendors we don't have CONFIG_IDEDMA_ONLYDISK set ibn our install kernels. I'd rather play safe and slow in this case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Processed: reassign 270385 to kernel-image-2.6.8-1-386
On Tue, Sep 07, 2004 at 09:03:08AM -0700, Debian Bug Tracking System wrote: > Processing commands for [EMAIL PROTECTED]: > > > # Automatically generated email from bts, devscripts version 2.8.4 > > reassign 270385 kernel-image-2.6.8-1-386 > Bug#270385: [i386] [20040905] SCSI controller DDRS-39130W not recognized in 2.6 > Bug reassigned from package `installation-reports' to `kernel-image-2.6.8-1-386'. What driver is used for this controller in 2.4? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge on OldWorld Mac - No root device
On Mon, Sep 27, 2004 at 04:40:16PM -0400, Joey Hess wrote: > Rick Thomas wrote: > > I've submitted several bug reports on this topic. The developers > > know about it, and may fix it sometime. It's not as easy to fix as > > it sounds, because the mesh controller is not on the regular PCI > > bus, so the normal hardware discovery programs never get a chance > > to see it. > > As far as I can tell, it's fixed in an as-yet unreleased version of > hw-detect: > > - mac-io bus detection improvements: > + Detect mesh SCSI controller (closes: #269655, #271419). > + Detect mace Ethernet controller. > + Detect mac53c94 SCSI controller. > + Detect therm_adt746x and therm_windtunnel fan controllers, although > only post-reboot for now since those modules aren't in > linux-kernel-di-powerpc-*. > + Cope with /proc/device-tree/aliases/mac-io pointing to a symlink. Note that there's a patch on lkml that adds device tables ala pci,usb,etc.. for macio. But that's probably useless for you as you'd want to support 2.4 aswell? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping 386 support
On Sun, Oct 03, 2004 at 07:54:12PM -0400, Joey Hess wrote: > Steve Langasek wrote: > > The d-i images really need to be built from kernel-image packages that > > are in the archive at the time we ship. Optimizing for 486 isn't a very > > good reason on its own to force another kernel build cycle. > > I had not even considered the impact of changing the optimisation, only > of changing the package name. Steve's right, and we'd have to test the > new build too. Also, doesn't optimising for 486 slow things down more > than the current 386 builds on non-486 machines? The 386 build is > installed whenever we cannot guess the right processor to optimise for. > It's also installed all the time when the common netinst CD image is > used, since we can only fit on kernel image on that CD. There's not really 486-optimized kernel as both core are so simple that gcc isn't doing any special instruction scheduling. The new instructions in the 486 are pretty important, though - e.g. bswap can optimize endian swapping quite nicely and cmpxchg is required for dri. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping the amd64-generic flavour
On Sat, Jun 24, 2006 at 08:20:56AM +0200, Florian Weimer wrote: > * Frederik Schueler: > > > -generic is odd and too long. I am considering to change the naming > > scheme completely, and call the flavours 2.6.x-y-amd64 and > > 2.6.x-y-em64t respectively. > > Newer GCCs produce AMD64 code which is supposed to be closed to > optimal to what GCC can produce on EM64T. Does it still make sense to > distinguish between them? Or has it got something to do with the way > the kernel sets up its data structures? The officially recommended way to build a distro kernel is to build the generic one. It's as fast as the specific ones because it uses some binary patching during bootup. The only thing you save with the specific options is a tiny little bit of space. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] ---end quoted text--- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
