Re: preliminary kernel-source 2.6.7 packages available
Hi, > deb http://www.theorie.physik.uni-muenchen.de/~jens/kernel-source ./ > Please check them out and provide feedback. I tried to compile for i386 from this source, but it was aborted by error: kernel/power/swsusp-core.c:48:20: swsusp.h: No such file or directory kernel/power/swsusp-core.c: In function `mark_swapfiles': ... Does 2.6.7 change around swsuspend code? Upstream code, linux-2.6.7.tar.bz2 looks not use this file. Thanks, -- Kenshi Muto [EMAIL PROTECTED]
Re: Bug#254325: kernel-source-2.4.22: DoS in OSS Sound Blaster Driver (CAN-2004-0178)
On Sat, Jun 19, 2004 at 03:27:59PM +0100, Martin Michlmayr wrote: > * Horms <[EMAIL PROTECTED]> [2004-06-15 20:10]: > > 1. If Herbet is no longer the maintainer, who is? > > A group of people which use debian-kernel@lists.debian.org to > communicate; the effort is led by William Irwin <[EMAIL PROTECTED]> Thanks, I have subsequently joined that list. > > 3. Are there any plans to remove any of these packages in the near > >future. > > There have been efforts to reduce the number of kernel source packages > in Debian. Andreas Barth has done some work on this and can tell you > more. The plan is to ship with one source package per major revision > (2.2, 2.4, 2.6; there have been talks about removing 2.2, but it seems > some architectures still need it.) Thanks, that sounds good to me. > > 5. Is there a mailing list / web page / whatever that outlines > >what kernels are currently available in what distribution, > >which are planned for removal, etc... > > Maybe Andreas Barth has collected this information. > > > 6. Does anyone check the CVEs and other vendor's updated kernel > >package advisories as they come out to make sure that the > >debian packages are up to date? > > > 7. Is there any value in me refiling these bugs, and possibly other > >of a similar vein, against other kernel-source packages. > >And if so, which ones? > > Against the newest 2.4 and 2.6, but obviously only if they still have > those problems. Of course. I will look into which of the bugs are still present. I don't think that many of the ones that i originally listed are present in the latest kernel.org kernel. -- Horms
Re: Other kernel packages
On Sat, Jun 19, 2004 at 09:51:28PM +0200, Sven Luther wrote: > On Sat, Jun 19, 2004 at 08:30:59PM +0200, Francesco Paolo Lovergine wrote: > > On Sat, Jun 19, 2004 at 03:13:44PM +0100, Martin Michlmayr wrote: > > > * tbm <[EMAIL PROTECTED]> [2004-06-14 17:05]: > > > > There are some other kernel related packages that have to be taken > > > > care of: > > > > > > > > cramfs > > > > initrd-tools > > > > kernel-image-*-alpha > > > > kernel-image-*-i386 > > > > kernel-kbuild-* > > > > kernel-source-* > > > > modules-scyld-source-0.1 > > > > > > > > Jeff Bailey was interested in helping with initrd-tools and I put him > > > > in contact with wli today. It would be great if someone could take a > > > > look at the other packages (especially cramfs and > > > > modules-scyld-source-0.1). > > > > > > Can anyone check those packages? > > > > > > > I can have care of cramfs and eventually initrd-tools. I saw that > > initrd-tools is already re-assigned to d-kernel, but I dunno who is > > baby-sitting it, if anyone... > > It would make sense to maintain all those inside the alioth kernel SVN > repository. Agreed, it seems they are quite closely related and bugs in, for instance initrd-tools, are likely to impact the kernel packages themselves, so it makes sense to have them all in the same place, hopefully with the same eyes looking over the problem. -- Horms
Bug#255449: kernel-image-2.6-k7: cpio complains while installing
Package: kernel-image-2.6-k7 Version: 2.6.6-2 Severity: minor Hi there, Setting up kernel-image-2.6.6-2-k7 (2.6.6-2) ... cpio: /etc/modprobe.conf: No such file or directory cpio: /lib/modules/modprobe.conf: No such file or directory Apparently the latest versions of module-init-tools no longer ship/use this file. Regards, Anand -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.2 Locale: LANG=C, LC_CTYPE=C Versions of packages kernel-image-2.6-k7 depends on: ii kernel-image-2.6.6-2-k7 2.6.6-2Linux kernel image for version 2.6 -- no debconf information
Re: preliminary kernel-source 2.6.7 packages available
On Mon, Jun 21, 2004 at 12:18:09AM +0200, Jens Schmalzing wrote: > Hi, > > I've created preliminary kernel-source packages based on the 2.6.7 > split patches created by Christoph. They can be found at > > deb http://www.theorie.physik.uni-muenchen.de/~jens/kernel-source ./ > > Please check them out and provide feedback. Whee, cool. Some comments: - I have done some more work on the split patches, especially added lots of .dpatch commentary. I'll re-merged that with your changes tomorrow - the changelog should be much more detailed, e.g. mentioning which changes we've dropped that didn't go upstream. I'll write something up on that. Else just thank a lot to Sven & you!
preliminary kernel-source 2.6.7 packages available
Hi, I've created preliminary kernel-source packages based on the 2.6.7 split patches created by Christoph. They can be found at deb http://www.theorie.physik.uni-muenchen.de/~jens/kernel-source ./ Please check them out and provide feedback. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#255425: kernel-source-2.4.26: Patch to enable Dell PowerEdge 750 SATA DMA support
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.
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 */
+ .vendor = PCI_VENDOR_ID_INTEL,
+ .device = PCI_DEVICE_ID_INTEL_ESB_3,
+ .name = "ICH5",
+ .init_setup = init_setup_piix,
+ .init_chipset = init_chipset_piix,
+ .init_iops = NULL,
+ .init_hwif = init_hwif_piix,
+ .init_dma = init_dma_piix,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .enablebits = {{0x41,0x80,0x80}, {0x43,0x80,0x80}},
+ .bootable = ON_BOARD,
+ .extra = 0,
},{
.vendor = 0,
.device = 0,
Bug#255406: kernel-source-2.4.26: Kernel crash when removing interface from wrong bridge group
Package: kernel-source-2.4.26
Severity: normal
Some time ago i found a kernel crash in 2.4.x and reported it to LKML.
Unfortunately i never recieved a reply, and i didn't see it in recent
pre-releases of the 2.4.x kernel.
To verify your system is vulnerable (need bridge support):
$ brctl addbr br0
$ brctl addbr br1
$ brctl addif br0 eth0
$ brctl delif br1 eth0
(note br1 in last line, not br0! Deleting from the wrong bridge triggers
the kernel crash.)
This is a 1:1 backport (100% copy&paste) from 2.6.5 of the fix.
Verify yourself, grab the file from 2.6.5, go to the function, copy the
code, paste it and the issue is done. Returns "einval" on invalid
requests instead of causing an inconsistency and a panic.
(fixed sometime in 2.5.x it seems; it might be worth looking at when
this was fixed - it might contain other fixes, too.)
--- net/bridge/br_if.c.2.4.21 2004-05-20 14:34:50.0 +0200
+++ net/bridge/br_if.c 2004-05-20 14:37:22.0 +0200
@@ -254,6 +254,10 @@
int br_del_if(struct net_bridge *br, struct net_device *dev)
{
int retval;
+ struct net_bridge_port *p;
+
+ if ((p = dev->br_port) == NULL || p->br != br)
+ return -EINVAL;
br_write_lock_bh(BR_NETPROTO_LOCK);
write_lock(&br->lock);
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.6
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: 2.6 hppa kernel debs
On Wed, Jun 16, 2004 at 10:37:45PM +0200, Thibaut VARENE wrote: > Since we don't have any 2.6 packages for hppa yet, we're looking at _The > Good Thing_ (tm) to do to create them. > > That's why we'd like to coordinate with other arch kernel maintainers to > do things right, so we're welcoming any hints on that topic. > I'm wondering if instead of shipping kernel-patch-hppa-VERSION, we should just ship a kernel-patch-hppa with all the relevant patches in. The patches are not particularly large when gzipped, so size shouldn't be an issue if we say, included the current version plus previous plus the latest patch against the stable kernel-source. Any comments? Regards, -- Kyle McMartin
Bug#255390: mkinitrd does not find modprobe.conf
Package: initrd-tools Version: 0.1.70 On one of my systems, mkinitrd fails creating the initrd with the following output: # mkinitrd -o /boot/initrd.img-2.6.6-2-k7 2.6.6-2-k7 cpio: /etc/modprobe.conf: No such file or directory cpio: /lib/modules/modprobe.conf: No such file or directory # It is correct, that these two locations do not contain a file 'modprobe.conf' but on a second system I have them neither and mkinitrd does not fail. Both systems run 2.6 series kernels. If I edit /usr/sbin/mkinitrd and remove the lines in the else case of line 1042 (the case where not $oldstyle) replacing them with "echo /etc/modules.conf" like in the $oldstyle case I can build the initrd. The initrd created with this modified mkinitrd works well. The initrd created with the original script does not allow the kernel to start. In this case I only get the error message, that the kernel was unable to mount its root file system (ext3 on an ATA hdd). Tot kijk Matthias
Re: Proposition: latest kernel source dependency package
Hi, Goswin von Brederlow writes: > Some people want the latest 2.4 kernel, some the latest 2.6 kernel. Yes. > Both should be possible. Yes. > So kernel-tree-2.4 and kernel-tree-2.6 should be there. Not necessarily. A kernel-tree tracker package only depends on the latest version, but doesn't conflict with the old ones. So even with a tracker package installed, you can have as many real kernel-tree packages as you want. > I doubt anyone wants to magically jump from 2.6 to a 2.7 or 2.8 > kernel when it comes out, sticking with one 2.x series is probably > meta enough. First, there's no magic there. After pulling in the latest kernel tree, the user has to build, install and reboot that kernel to actually use it. Second, having pulled some of my boxen across three stable releases, a package tracking the corresponding transitions from 2.0 to 2.2 to 2.4 and soon to 2.6 would have been nifty. Not that it really matters if you use it every two or three years. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: Proposition: latest kernel source dependency package
Jens Schmalzing <[EMAIL PROTECTED]> writes: > Hi, > > Goswin von Brederlow writes: > >> Better would be Kernel-tree-2.6 analog to kernel-tree-2.6.6. > > I'm working on the kernel-source-2.6.7 package anyway, I'll add a > kernel-tree metapackage. kernel-tree because IMHO sticking with a > certain minor version is against the spirit of a tracker package. > > Regards, Jens. Some people want the latest 2.4 kernel, some the latest 2.6 kernel. Both should be possible. So kernel-tree-2.4 and kernel-tree-2.6 should be there. I doubt anyone wants to magically jump from 2.6 to a 2.7 or 2.8 kernel when it comes out, sticking with one 2.x series is probably meta enough. Just my 2c. MfG Goswin
Re: Proposition: latest kernel source dependency package
Hi, Goswin von Brederlow writes: > Better would be Kernel-tree-2.6 analog to kernel-tree-2.6.6. I'm working on the kernel-source-2.6.7 package anyway, I'll add a kernel-tree metapackage. kernel-tree because IMHO sticking with a certain minor version is against the spirit of a tracker package. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: mkvmlinuz, boot-loaders and powerpc kernels.
On Sun, Jun 20, 2004 at 10:49:05AM +0200, Jens Schmalzing wrote: > Dear Sven, > > > Jens, in your discussion with Manoj about this, where would the > > generic-powerpc or whatever script reside ? > > in my proposal, 'generic' or 'official' would be a separate PowerPC > subarch that > > a) packages the kernel as an uncompressed ELF image file in >/boot/vmlinux-- and nothing else, > > b) packages the bootloading glue for pmac, chrp and prep into the >directory /usr/lib/kernel-image--, > > c) takes provisions to apply the correct glue in the postinst. > > Right now, a) and b) are implemented in the debian/rules file of > kernel-patch-powerpc, by building an intermediate pmac kernel-image > package, unpacking it, and making the necessary changes. I don't like it. It introduces an artificial difference between the self built kernel-images and the official ones. My idea was to replace each of the loader/loaderdep/loaderdoc, with a common stuff, calling a script, maybe provided by kernel-package, and introducing a dependency with loaderdep of the form : quik | yaboot | mkvmlinuz. This dependency would be on the kernel-image package directly. The script would then detect the subarch as usual and call the right bootloader generator (well, probably nothing for yaboot or quik, not sure, and the right magic for mkvmlinuz). But then, maybe using a separate package is best, so we can do the debconf dialog, and ask the user about its preference, and then have the script called by the kernel-image postinst consult the debconf database and act accordyingly. If it was not for the binutils dependency, i would say that mkvmlinuz fited this role perfeectly, but maybe mkvmlinuz could spawn a powerpc-bootloader binary package which would handle this, and carry the dependencies on quik | yaboot | mkvmlinuz. What do you think ? This way, we would just need to replace the loader and co in kernel-image to point to powerpc-bootloader package, and have all the rest handled by this powerpc-bootloader package ? How does that feel ? Friendly, Sven Luther
Re: Proposition: latest kernel source dependency package
Wouter Koolen-Wijkstra <[EMAIL PROTECTED]> writes: > Dear Debian Kernel Maintainer(s), > > I think it would be nice to have an empty package called > 'kernel-source-latest' (or something similar), which always depends on > the latest Debian kernel source package. This way (nightly cron > automated) apt-get upgrade can automatically retrieve new kernels when > they become available. > > A very happy Debian GNU/Linux user, > > Wouter Koolen-Wijkstra Better would be Kernel-tree-2.6 analog to kernel-tree-2.6.6. MfG Goswin
Proposition: latest kernel source dependency package
Dear Debian Kernel Maintainer(s), I think it would be nice to have an empty package called 'kernel-source-latest' (or something similar), which always depends on the latest Debian kernel source package. This way (nightly cron automated) apt-get upgrade can automatically retrieve new kernels when they become available. A very happy Debian GNU/Linux user, Wouter Koolen-Wijkstra
Re: mkvmlinuz, boot-loaders and powerpc kernels.
Dear Sven, > Jens, in your discussion with Manoj about this, where would the > generic-powerpc or whatever script reside ? in my proposal, 'generic' or 'official' would be a separate PowerPC subarch that a) packages the kernel as an uncompressed ELF image file in /boot/vmlinux-- and nothing else, b) packages the bootloading glue for pmac, chrp and prep into the directory /usr/lib/kernel-image--, c) takes provisions to apply the correct glue in the postinst. Right now, a) and b) are implemented in the debian/rules file of kernel-patch-powerpc, by building an intermediate pmac kernel-image package, unpacking it, and making the necessary changes. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: mkvmlinuz, boot-loaders and powerpc kernels.
On Sat, Jun 19, 2004 at 01:26:13PM +0200, Jens Schmalzing wrote: > Hi, > > Sven Luther writes: > > > Some kind of alternative dependency on yaboot | quik | mkvmlinuz > > would take care of fullfilling the dependency, without allowing > > cruft to be installed, at least without needing yaboot and quik > > where they are not needed, or letting mkvmlinuz pull in the binutils > > dependency ? > > This does not cover the case where a system uses a method outside its > own Debian packaging system, such as BootX or a BootP/TFTP server. > Still, it's probably the best one can do with the control file. > > > Jens, would that be an acceptable solution ? > > To me this looks like the way to go. I already exchanged a few > messages with Manoj about a similar issue, namely packaging the boot > glue into /usr/lib/kernel-image-, which is now done by the > debian/rules file of kernel-patch-powerpc. We ended here: > > Jens: > > | May I suggest the following: We take care of the above two points by > | adding a sub-architecture `generic' or `official' to powerpc and put > | the necessary commands there. > > Manoj: > > | Sounds like a plan. Jens, in your discussion with Manoj about this, where would the generic-powerpc or whatever script reside ? In the kernel-package which then includes it in each kernel-image file ? Or in a separate standalone package which would be depended upon (which could also be the mkvmlinuz, albeit renamed if you like), and more easily modifiable ? The only problem with this i see is the mention of QuikDefault for loaderdoc, altough i have no idea where it is taking this stuff from. Friendly, Sven Luther
