Bug#435877: Add pciids for ICH9 IDE mode SATA controller
Package: linux-2.6 Version: 2.6.18.dfsg.1-12etch2 Severity: important Tags: etch We should backport this patch to add support for the ICH9 controllers: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=f98b6573f190aff2748894da13a48bab0f10c733 -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435878: [hppa] fix hang in SMP mode - no interrupts delivered
Package: linux-2.6 Version: 2.6.18.dfsg.1-12etch2 Severity: important Tags: patch, etch Thibaut pointed out that etch is missing the following patch, causing lockups in SMP mode. http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=commitdiff_plain;h=462b529f91b618f4bd144bbc6184f616dfb58a1e -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435547: linux-source-2.6.18: sis190 driver should not assume ISA bridge is SiS965 only
On Wed, Aug 01, 2007 at 04:18:35PM +0200, Neil Muller wrote: Package: linux-source-2.6.18 Severity: normal Tags: patch The sis190 driver uses the ISA bridge to read various values. It currently assumes that the bridge is Sis965 only, but recent SIS motherboards use the Sis966 bridge. The following patch (against linux-source-2.6.18) should address this. The patch is based on a similiar fix in the sis900 driver. Thanks Neil. In order for Debian to include this change, we would first like to see it in the upstream kernel: http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines Since I don't see this change in Linus' latest tree, I suggest submitting it upstream first. Once this change (or something like it) is included, please update this bug report with a pointer to the changeset. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.22 - broken on ia64 and mipsel
On Fri, Jul 27, 2007 at 09:55:27PM +0200, Martin Michlmayr wrote: * Bastian Blank [EMAIL PROTECTED] [2007-07-24 17:21]: 2.6.22 is currently broken on ia64 and mipsel. - mipsel: broken config. I fixed this in trunk a while ago, but I just commited it to the sid branch as well. -3 can be released now as far as I'm concerned. I'm testing building a fix for #431773 right now that I'd like to get into -3. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fstab update for persistent device names
On Thu, Jul 26, 2007 at 07:42:20PM +0200, Bastian Blank wrote: On Thu, Jul 26, 2007 at 10:47:00AM -0600, dann frazier wrote: We need to decide which arches needs this rewrite now and which value should be filed in. And also, how should we re-write them? Should we just provide documentation, or also provide a utility to do it? You don't want to do things manual if you can automate them. ... No. Maintainer scripts must not change _any_ conffile. What is your idea for implementing this? Creating a utility that must be manually executed by the administrator? If so, how will the the admin be informed that they need to run it - by causing linux-image preinsts to error out if old-style names are detected? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fstab update for persistent device names
On Thu, Jul 26, 2007 at 11:40:19AM +0200, Bastian Blank wrote: Hi folks For the libata-pata support we need to change fstab on several arches to not break all systems which uses them. Not to mention bootloader configs and other things that may handle dump partitions. We need to decide which arches needs this rewrite now and which value should be filed in. And also, how should we re-write them? Should we just provide documentation, or also provide a utility to do it? linux-images w/ libata-pata should probably detect non-persistent names and fail to install, telling the user they need to run the upgrade utility (or manually upgrade) before continuing. There are 5 or so variants: - /dev/disk/by-id: Includes disk serial number or wwnn. - /dev/disk/by-label: Filesystem label. Do all filesystems support labels? fat doesn't, iirc. - /dev/disk/by-path: Includes pci device and lun. - /dev/disk/by-uuid: UUID of filesystem. Maybe we want the uuid of md devices also? Do all filesystems support UUID? - LABEL= - UUID= Another option is to leave the option to the user with a sane default. I'm thinking something like: 1) scan all config files we know about that contain such references 2) Probe these devices for available persistent-names 3) Present the list of available names to the user 4) re-write all config files that reference that device For 4), we could either try and incorporate all config file knowledge in the utility, or provide a hook system by which we make a name map available but each package is responsible for doing its own renaming. The latter would give us a pass on the don't edit other package's config files rule. We have to support the following device types, I think: - pata, sata, parallel scsi, sas No problem, I would prefer by-id. It should be stable for this types of devices. So a user needs to fix this entry for a disk replacement. - fiberchannel by-id. It includes the wwnn, which is defined as unique for each device. If someone have more than one path to the disk, they need multipath-tools anyway, which creates /dev/mapper/$wwnn. - iscsi This is a problem. iscsi have a stable identifier for a device, but it is not exported by udev. udev provides the following: | /dev/disk/by-id/scsi-16465616462656166333a3100 This is the usual disc identification. And: | /dev/disk/by-path/ip-192.168.9.13:3260-iscsi-iqn.2007-07.org.zseries.debian00:storage.org.zseries.debian04v4-lun-1 This includes the ip of the target, the id and the lun. The id is defined to be unique for a device. Maybe we want something like by-id/iscsi-iqn.2007-07.org.zseries.debian00:storage.org.zseries.debian04v4-lun-1. More than one path needs multipath-tools also. The following devices can be ignored: - md* - mapper/* - lvm symlinks Or should we ignore all devices which we don't know about? I would think so. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.22 - broken on ia64 and mipsel
On Tue, Jul 24, 2007 at 05:21:02PM +0200, Bastian Blank wrote: Hi folks 2.6.22 is currently broken on ia64 and mipsel. - ia64: ABI. Testing a build now. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410817: Will this problem be fixed soon?
On Mon, Jul 23, 2007 at 11:10:55AM +0200, Guillaume Estival wrote: According to Mark, it only requires a minor change on the driver code and I will wait for a 4.0r1 to do the job... The kernel for 4.0r1 is already complete, so there will be no fix there. This fix will also not appear in 4.0r2 unless we first get the fix upstream and backport it into the etch kernel. Mark asked the proper way to proceed. I suggest: 1) submitting the patch upstream and following up until it or an alternative is accepted. 2) pinging this bug again once that has occurred, at which point we can consider backporting it -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394742: please test etch snapshots
hey Mikko, I've queued your patch up for the second etch point release. Snapshots of this kernel are autobuilt and available for testing. Would you mind testing the latest build to verify? See: http://wiki.debian.org/DebianKernel The patch is in dists/etch/ -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: custom configured kernel from package sources?
On Thu, Jul 19, 2007 at 01:20:22PM +1200, Steve Wray wrote: Hi there, I've been trying to work out where, exactly, to post this question. I'm not on either list and since this is (hopefuly) a one-off I'm not going to subscribe at this time so please CC me in on-list replies. I want to build a kernel package for the Xen subarchitecture with NFS root enabled. I want to use the 2.6.18 kernel and I want to produce a package from the Debian sources. I've done an apt-get source linux-image-2.6.18-4-xen-686 of course, this gets me a more generic kernel source than just the Xen one, but I wanted to be certain that I pulled in the exact Debian source package which was used to generate the running kernel. From what I've read, I need to run split-config, which I got from SVN (it doesn't seem to exist anywhere else, its not in the source package nor in any other package so far as I can tell). You should be able to just use linux-tree-2.6.18. I haven't tested these commands, but I think this is how it works: $ tar xfj /usr/src/linux-source-2.6.18.tar.bz2 $ /usr/src/kernel-patches/all/2.6.18/apply/debian -f xen 2.6.18-12etch2 You can run the debian script w/ --help to see the full list of options. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xen on Kernel Debian testing/untsable
On Wed, Jul 18, 2007 at 06:51:20AM -0500, Nestor A. Diaz wrote: Hello, i am using xen under etch with 2.6.18 linux kernel, however i have some issues with the sata driver with ahci enabled, according to sata linux kernel maintainer, this is fixed in 2.6.20, i see that xen is not supported under debian packages for xen 2.6.22, is xen under testing / unstable supposed to be installed from a debian kernel patch package ? or something like that ? As I understand it, upstream Xen is still stuck back on 2.6.18, so there's no patches available for testing (2.6.21) or sid (2.6.22). I wonder if your ahci problem is fixable in etch - do you happen to know what changed to fix it? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for 2.6.22-2 [Was, Re: 2.6.22]
On Wed, Jul 18, 2007 at 02:45:26PM -0700, Steve Langasek wrote: This is fixed now, but in the meantime 2.6.22-1 has been uploaded. (I'm really tempted to disable the separate 'vserver' flavor for alpha to get manageable build times on my ev56 for testing...) Are there other currently pending changes that we need to have in before uploading a 2.6.22-2? I noticed a lot of missing drivers on ia64 this morning (including the sym2 driver which is in a lot of ia64 boxes, but not my fusion-based test machine). I'm testing a build right now with them re-enabled and will commit after a test boot. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410817: Will this problem be fixed soon?
On Fri, Jul 13, 2007 at 03:00:00PM +0200, Guillaume Estival wrote: I need to reinstall properly a file server into etch because it is originally a testing sarge moved onto stable sarge dist upgrade into etch. The result isn't really good (some things do not run anymore) but I can't reinstall the system since Etch 4.0r0 DVD don't even see my RAID 1 PERC controller You say its not even seeing the controller? If so, I'd suggest filing a separate bug. This report describes an issue where the controller is found but logical disks are not detected. Also see: http://wiki.debian.org/DebianKernelReportingBugs -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410817: unable to reproduce
Mark, I found a megaraid card today in the hopes that I could reproduce this problem - unfortunately, I could not. See the log below. As you can see, my card also has the 101e:1960 pci id. At POST mine reports itself as: hp raid controller BIOS version G.02.03 Is there maybe a firmware upgrade available for yours? See: http://lackof.org/taggart/hacking/netraid/ Also, do more recent kernels work for you? Linux version 2.6.18-4-686 (Debian 2.6.18.dfsg.1-12) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Mon Mar 26 17:17:36 UTC 2007 ... megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006) megaraid: 2.20.4.9 (Release Date: Sun Jul 16 12:27:22 EST 2006) ... megaraid: probe new device 0x101e:0x1960:0x103c:0x60e8: bus 7:slot 0:func 0 ACPI: PCI Interrupt :07:00.0[A] - GSI 21 (level, low) - IRQ 209 PCI: Setting latency timer of device :07:00.0 to 64 megaraid: fw version:[] bios version:[G ] scsi0 : LSI Logic MegaRAID driver scsi[0]: scanning scsi channel 0 [Phy 0] for non-raid devices ... scsi[0]: scanning scsi channel 1 [Phy 1] for non-raid devices scsi[0]: scanning scsi channel 2 [virtual] for logical drives Vendor: MegaRAID Model: LD 0 RAID1 34G Rev: H Type: Direct-Access ANSI SCSI revision: 02 SCSI device sda: 71129088 512-byte hdwr sectors (36418 MB) sda: Write Protect is off sda: Mode Sense: 00 00 00 00 sda: asking for cache data failed sda: assuming drive cache: write through SCSI device sda: 71129088 512-byte hdwr sectors (36418 MB) sda: Write Protect is off sda: Mode Sense: 00 00 00 00 sda: asking for cache data failed sda: assuming drive cache: write through sda: sda1 sda2 sda5 sd 0:2:0:0: Attached scsi disk sda ... -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.22
On Wed, Jul 11, 2007 at 06:07:24PM -0600, dann frazier wrote: On Wed, Jul 11, 2007 at 03:08:36PM +0200, Bastian Blank wrote: According to the projectb, only amd64, arm, i386, ia64 and powerpc had linux-2.6/experimental built. s390 and sparc are built in the snapshots. This left alpha, building.. Failed[1] hppa, building.. Failed[2] ia64, Already built for experimental (also in the list above), though I am testing a build w/ vserver enabled since I've had a few different requests for this now. built fine, will do some testing before commiting [1] CC arch/alpha/kernel/sys_titan.o cc1: warnings being treated as errors arch/alpha/kernel/sys_titan.c: In function 'titan_late_init': arch/alpha/kernel/sys_titan.c:281: warning: ignoring return value of 'request_irq', declared with attribute warn_unused_result arch/alpha/kernel/sys_titan.c:283: warning: ignoring return value of 'request_irq', declared with attribute warn_unused_result arch/alpha/kernel/sys_titan.c:285: warning: ignoring return value of 'request_irq', declared with attribute warn_unused_result arch/alpha/kernel/sys_titan.c:287: warning: ignoring return value of 'request_irq', declared with attribute warn_unused_result arch/alpha/kernel/sys_titan.c:289: warning: ignoring return value of 'request_irq', declared with attribute warn_unused_result arch/alpha/kernel/sys_titan.c: In function 'privateer_init_pci': arch/alpha/kernel/sys_titan.c:348: warning: ignoring return value of 'request_irq', declared with attribute warn_unused_result arch/alpha/kernel/sys_titan.c:350: warning: ignoring return value of 'request_irq', declared with attribute warn_unused_result make[5]: *** [arch/alpha/kernel/sys_titan.o] Error 1 make[4]: *** [arch/alpha/kernel] Error 2 make[4]: Leaving directory `/tmp/buildd/linux-2.6-2.6.22~rc5/debian/build/build-alpha-none-alpha-generic' make[3]: *** [debian/stamp-build-kernel] Error 2 make[3]: Leaving directory `/tmp/buildd/linux-2.6-2.6.22~rc5/debian/build/build-alpha-none-alpha-generic' make[2]: *** [debian/stamps/build-alpha-none-alpha-generic-kernel-package] Error 2 make[2]: Leaving directory `/tmp/buildd/linux-2.6-2.6.22~rc5' make[1]: *** [build-alpha-none-alpha-generic-real] Error 2 make[1]: Leaving directory `/tmp/buildd/linux-2.6-2.6.22~rc5' make: *** [debian/stamps/build-base] Error 2 [2] CC [M] drivers/video/vgastate.o In file included from drivers/video/vgastate.c:20: include/video/vga.h:23:21: error: asm/vga.h: No such file or directory make[6]: *** [drivers/video/vgastate.o] Error 1 make[5]: *** [drivers/video] Error 2 make[4]: *** [drivers] Error 2 make[4]: Leaving directory `/tmp/buildd/linux-2.6-2.6.22~rc5/debian/build/build-hppa-none-parisc' make[3]: *** [debian/stamp-build-kernel] Error 2 make[3]: Leaving directory `/tmp/buildd/linux-2.6-2.6.22~rc5/debian/build/build-hppa-none-parisc' make[2]: *** [debian/stamps/build-hppa-none-parisc-kernel-package] Error 2 make[2]: Leaving directory `/tmp/buildd/linux-2.6-2.6.22~rc5' make[1]: *** [build-hppa-none-parisc-real] Error 2 make[1]: Leaving directory `/tmp/buildd/linux-2.6-2.6.22~rc5' make: *** [debian/stamps/build-base] Error 2 -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.22
On Thu, Jul 12, 2007 at 08:06:03PM +0200, Frank Lichtenheld wrote: On Thu, Jul 12, 2007 at 10:50:24AM -0600, dann frazier wrote: [2] CC [M] drivers/video/vgastate.o In file included from drivers/video/vgastate.c:20: include/video/vga.h:23:21: error: asm/vga.h: No such file or directory make[6]: *** [drivers/video/vgastate.o] Error 1 make[5]: *** [drivers/video] Error 2 make[4]: *** [drivers] Error 2 make[4]: Leaving directory `/tmp/buildd/linux-2.6-2.6.22~rc5/debian/build/build-hppa-none-parisc' make[3]: *** [debian/stamp-build-kernel] Error 2 make[3]: Leaving directory `/tmp/buildd/linux-2.6-2.6.22~rc5/debian/build/build-hppa-none-parisc' make[2]: *** [debian/stamps/build-hppa-none-parisc-kernel-package] Error 2 make[2]: Leaving directory `/tmp/buildd/linux-2.6-2.6.22~rc5' make[1]: *** [build-hppa-none-parisc-real] Error 2 make[1]: Leaving directory `/tmp/buildd/linux-2.6-2.6.22~rc5' make: *** [debian/stamps/build-base] Error 2 Hrm, why did you build ~rc5? This is fixed in trunk. No good reason, I'll retry trunk builds of both alpha and hppa. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.22
On Thu, Jul 12, 2007 at 12:12:48PM -0600, dann frazier wrote: No good reason, I'll retry trunk builds of both alpha and hppa. fyi, alpha fails at the same point. My hppa build is still progressing. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.22
On Thu, Jul 12, 2007 at 11:13:23PM +0200, Frank Lichtenheld wrote: On Thu, Jul 12, 2007 at 10:36:19PM +0200, Frank Lichtenheld wrote: On Thu, Jul 12, 2007 at 01:57:57PM -0600, dann frazier wrote: On Thu, Jul 12, 2007 at 12:12:48PM -0600, dann frazier wrote: No good reason, I'll retry trunk builds of both alpha and hppa. fyi, alpha fails at the same point. My hppa build is still progressing. hppa was fixed in commit r9073. Maybe alpha needs a similar patch. Sorry, probably misinterpreted same here. You probably meant same as before, not same as hppa. Correct - sorry that wasn't clear. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VIA 6103 networking driver gets slow at high bandwidth usage
On Thu, Jul 12, 2007 at 01:00:38PM +0200, victor nawothnig wrote: Package: linux-image Version: 2.6.18-4-k7 If I run P2P applications such as rtorrent or uTorrent (under wine) and they max out my download bandwidth (~1.2MByte/s) my network gets incredibly slow. Ping latency to my local router is ~1s instead of 0.5ms. Closing the application decreases that ping to ~10s, restarting it decreases it to ~1s again. Since this started happening when I upgraded my kernel during a dist-upgrade from Etch to Lenny I suppose it is the driver within the kernel, that may cause that problem. Hardware itself is fine. hey Victor, Your best bet for getting this fixed is to help narrow down when the change occurred as much as possible. I just created this page that should help explain how to do that: http://wiki.debian.org/DebianKernelReportingBugs -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.22
On Wed, Jul 11, 2007 at 03:08:36PM +0200, Bastian Blank wrote: According to the projectb, only amd64, arm, i386, ia64 and powerpc had linux-2.6/experimental built. s390 and sparc are built in the snapshots. This left alpha, building.. hppa, building.. ia64, Already built for experimental (also in the list above), though I am testing a build w/ vserver enabled since I've had a few different requests for this now. mips and mipsel where builds are needed. don't have these, sorry :( -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.21-6
On Mon, Jul 09, 2007 at 01:49:15PM -0600, dann frazier wrote: On Sun, Jul 08, 2007 at 05:50:11PM +0200, Bastian Blank wrote: Hi folks I'd like to schedule 2.6.21-6 for tuesday. It only contains a security fix. Dann: Is there a CVE for the nf_conntrack_h323? I have not seen one, but I'll ask on vendor-sec. CVE-2007-3642 - looks like its already marked for release or I'd have added this to the changelog in svn. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.21-6
On Sun, Jul 08, 2007 at 05:50:11PM +0200, Bastian Blank wrote: Hi folks I'd like to schedule 2.6.21-6 for tuesday. It only contains a security fix. Dann: Is there a CVE for the nf_conntrack_h323? I have not seen one, but I'll ask on vendor-sec. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AMD/ATI SB700 support to Debian
On Wed, Jul 04, 2007 at 10:55:35AM +0800, Shane Huang wrote: Hi Dann: Do you know of any reason these changes wouldn't work on a 2.6.18 base? Would you be able to run QA on one of our daily builds if I pointed you to snapshot debs with these changes? I'm sorry that I do not catch your meaning very much because I'm a newbie in Debian, I did not use Debian before and know little about it, the distribution I have being using for some time is Redhat/Fedora. My main task here is to check whether the SB700 patches have been added into the familiar distributions to be released such as Debian 4.1, RHEL5.1 and Fedora 8. 'lenny' is the next major release of Debian (which might be called 4.1). But, that is over a year away whereas adding hardware support to the existing release (4.0, 'etch') is possible sooner. So could you give me more information about your questions? Such as: What's the function/usage of 2.6.18 base? Why are you still using it if next Debian 4.1 release will use the kernel after 2.6.23-rc1. etc Debian 'etch' is based on 2.6.18. The combined mode patch for sb700 depends on a quirk that was added for sb600 after 2.6.18. I could of course backport this quirk only for sb700, but is there a good reason for adding it for sb600 as well? I think adding both the SB600 patch and SB700 is better, since the distribution can be used on motherboards with SB600 or SB700. SB600 support is already there. What I'm saying is that there was a pci quirk added for the SB600 sometime after 2.6.18, and the SB700 uses the same one. So, since we would, in theory, backport it as part of the SB700 backport - what is the value/risk of enabling it for the SB600 as well? We don't want to risk breaking existing SB600 support in etch unless there's a good reason. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AMD/ATI SB700 support to Debian
On Tue, Jul 03, 2007 at 03:03:33PM +0800, Shane Huang wrote: If next Debian release(4.1?) will use the linux kernel after 2.6.23-rc1, then that's good and you may discard this mail. It will. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AMD/ATI SB700 support to Debian
On Tue, Jul 03, 2007 at 03:03:33PM +0800, Shane Huang wrote: Greetings: This is Shane. We have four patches for AMD/ATI SB700, and we will full support SB700 until 2.6.23-rc1. The four patches have been accepted by kernel org and the applied kernel version are listed as below: 1.SMBus device ID 2.6.23-rc1 Upstream commit: http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/i2c-piix4-add-ATI -SB700-support.patch 2.IDE device ID 2.6.22 Upstream commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi t;h=6c6a2a8d201b4f8fd54167802da5ddbe08abd744 3.SATA device ID2.6.22 Upstream commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi t;h=2bcfdde6767f2f07891d2753c25220012fe5e6d2 4.Combined mode 2.6.22 Upstream commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi t;h=823777181b4c0200923dcb026efa5b37f55c0ecf Because the patch for SMBus device ID is sent after the merge window for 2.6.22, and as a result it is queued for the next kernel version: 2.6.23. it will be merged in Linus' tree between 2.6.22 (final) and 2.6.23-rc1. I took a look at these patches, and they are certainly something we'd consider for a point release of the existing Debian release if they can be backported to the 2.6.18 base in such a way that the changes will only affect new hardware - since they are mostly just adding ids, etc, that might be the case. Do you know of any reason these changes wouldn't work on a 2.6.18 base? Would you be able to run QA on one of our daily builds if I pointed you to snapshot debs with these changes? The combined mode patch for sb700 depends on a quirk that was added for sb600 after 2.6.18. I could of course backport this quirk only for sb700, but is there a good reason for adding it for sb600 as well? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=ab17443a3df35abe4b7529e83511a591aa7384f3 -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429625: linux-source-2.6.18 build fails on hppa - missing patch?
On Tue, Jun 19, 2007 at 09:54:08AM +0200, [EMAIL PROTECTED] wrote: Package: linux-source-2.6.18 Version: 2.6.18.dfs This version does not exist. Were you using dpkg -l to identify the version? If so, I suggest either setting COLUMNS to something reasonably big or piping the output through cat (e.g., dpkg -l linux-source-2.6.18 | cat) to see the full version. Should there not be a hppa/parisc-specific patch to apply to the standard debian kernel source package? No such patch appears to be available in etch. It is, but you need to apply it: # apt-get install linux-tree-2.6.18 # tar xfj /usr/src/linux-source-2.6.18.tar.bz2 # cd linux-source-2.6.18 # /usr/src/kernel-patches/all/2.6.18/apply/debian -a hppa -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SID/apt-get old kernel sources..
On Fri, Jun 22, 2007 at 12:53:59PM -0400, Sateesh Mandava wrote: Hi, I am running 2.6.18 kernel with debian/sid and in need of kernel headers/source to compile nvidia/ivtv kernel modules. apt-get is not able to find linux-source-2.6.18* or linux-headers-2.6.18* packages. It is only pointing to 2.6.21 packages. Can some body let me know how to get old kernel source/header files using apt? Here is my /etc/apt/sources.list file. deb http://ftp.us.debian.org/debian/ sid main contrib non-free deb-src http://ftp.us.debian.org/debian/ sid main contrib non-free deb-src http://security.debian.org/ etch/updates main deb http://www.debian-multimedia.org sid main apt output.. $ sudo apt-get install linux-source-2.6.18 Reading package lists... Done Building dependency tree... Done Package linux-source-2.6.18 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package linux-source-2.6.18 has no installation candidate Add to your sources.list: deb http://ftp.us.debian.org/debian/ testing main contrib non-free Also note that there are pre-compiled modules for ivtv and nvidia in the archive. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429449: aptitude says kernel-image-2.6-powerpc version 102sarge2 depends on non-existent kernel version
On Mon, Jun 18, 2007 at 03:14:55AM -0400, Rick Thomas wrote: Any idea why? Works for me.. [EMAIL PROTECTED]:~$ sudo apt-get install kernel-image-2.6-powerpcReading package lists... Done Building dependency tree... Done The following extra packages will be installed: kernel-image-2.6.8-4-powerpc The following NEW packages will be installed kernel-image-2.6.8-4-powerpc The following packages will be upgraded: kernel-image-2.6-powerpc 1 upgraded, 1 newly installed, 0 to remove and 5 not upgraded. Need to get 13.6MB of archives. After unpacking 40.3MB of additional disk space will be used. Do you want to continue [Y/n]? /etc/apt/sources.list: deb http://security.debian.org/ sarge/updates main contrib non-free deb-src http://security.debian.org/ sarge/updates main contrib non-free -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427826: probably due to a filesystem bug
On Wed, Jun 13, 2007 at 03:58:19AM -0700, Salvador Fandio wrote: Hi, The machine is stable since I run fsck on all the file systems some days ago, it has not hanged again. Probably, the problem was related to some bug on the file system code. There is no way to reproduce it and so I suppose the ticket can be closed. ok, closing then. thanks for the update. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428503: kernel-image-2.6-k7_101sarge2 broken dependency
On Tue, Jun 12, 2007 at 11:26:26AM +0200, Guido Nickels wrote: Package: kernel-image-2.6-k7 Version: 101sarge2 The package depends on kernel-image-2.6.8-4-k7 which is not available anywhere on archive servers (latest available version is 2.6.8-3-k7). See http://packages.debian.org/oldstable/base/kernel-image-2.6-k7 or any apt mirror for verification. Please be patient - these security updates are in progress. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Make not working on linux-source-2.6.18
On Tue, Jun 12, 2007 at 07:42:17PM -0400, Tim wrote: I just installed Etch both on my laptop and on my desktop. On both machines, I downloaded linux-source-2.6.18 and tar'ed them into /usr/src. However, when I run make EXTRAVERSION=-k7 oldversion, I get several error messages about files not existing, called by gcc. I am using gcc 4.1, and I am sure this source matches my kernel image (linux-image-2.6.18-4-k7). Well, first of all I don't think there's actually a target called 'oldversion'. Maybe you mean oldconfig? Without actual error messages, I can't really tell if this is the only problem. Is there another tool I need besides gcc? There are a number of tools you need besides gcc. Again, I can't guess as to what you might be missing w/o actual error messages. I need to install the headers in order to install ndiswrapper for my wireless card. All of this worked on sarge with no issues, using kernel-source-2.6.8-2-k7. The headers are pre-packaged and can easily be installed using the following commands: # apt-get install module-assistant # m-a prepare Also note that ndiswrapper source is already packaged in Debian, so you can build/install the module easily by running the above commands followed by: # apt-get install ndiswrapper-source # m-a a-i ndiswrapper -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changing maintainer field
On Tue, Jun 05, 2007 at 12:13:19AM +0200, Frans Pop wrote: On Monday 04 June 2007 23:42, maximilian attems wrote: what where the args against it appart from pure inertia? Note that you'll probably lose me as someone who occasionally helps reply to bugs as I doubt I'll want to be subscribed to two separate kernel lists. I suspect this will be true for others as well. why? I mean, what's the overhead of subscribing to two separate lists? Just curious.. It will also mean that I will lose some sense of what is happening wrt the kernel. Are there enough people who are planning to subscribe to the bug list anyway or is it just going to further reduce the number of people that see and deal with kernel BRs? I for one would certainly subscribe to both. However, I've heard complaints from people that they are interested in higher level/lower traffic discussions (new upstream to be uploaded to experimental, kernel update in a stable release, should we drop kernel-package, etc), but they are not interested in individual bugs. The current model is suboptimal for them. Perhaps we can force these people to watch bug traffic go by so that they can't help but participate in triage at some level, but I suspect its more likely that these people will just unsubscribe altogether (or implement their own filter). imo, people should be able to select their level of involvement. However, since I personally want to see all of this mail, I'm not really going to push the issue. If there's no outcry from people who want to see only bugs or only non-bugs, then we're probably trying to solve a non-existant problem. In fact, of the people I remember complaning about this, I don't think either are active on the current list (and I don't know whether they would subscribe to either filtered one). I do however think that getting more people involved with triage is critical. I think the best way to do that would be for the kernel team to create some sort of work flow that establishes the rules for dealing with bugs, things like: * When and how to forward bugs upstream * How long to leave a bug open w/o a response from the submitter * Procedures for narrowing down a fix/breakage - e.g., determining if its debian-specific, using git-bisect, etc * Useful usertag procedures for reducing the problem into smaller sets - e.g., hardware, subsystem, etc. In short, get it down to where 80% of the work can be handled by monkeys, then start baiting traps with bananas and building automated poop-slingers where feasible. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is linux-image-2.6-k7 required?
On Tue, May 29, 2007 at 03:39:41PM -0700, Phillip Pi wrote: Hello, I did an apt-get update and dist-upgrade today, and noticed it wanted to install Kernel 2.6.21-1-K7. I am still using v2.6.18-4-K7 (uname: 2.6.18-4-k7 #1 SMP Wed May 9 23:42:01 UTC 2007 i686 GNU/Linux). I did not want to install the new Kernel, so I removed linux-image-2.6-k7 which was depended on. Is this going to be a problem if linux-image-2.6-k7 is not installed? I have not rebooted yet. The package description did not make sense to me: Description: Linux kernel 2.6 image on AMD K7. This package depends on the latest binary image for Linux kernel 2.6 on 32bit AMD Duron/Athlon/AthlonXP machines. Is that saying it is required? If so, then how do I keep the one for 2.6.18? It is not required. The linux-latest-2.6 packages are there to assist you in upgrading to the latest available kernel in your distribution. If you do not wish to upgrade, you can remain at 2.6.18. That said, 2.6.18 no longer exists in sid and is not supported beyond etch, so you will not automatically receive any fixes (security or otherwise) for it. If you would prefer to continue running 2.6.18 but also receive these fixes, I'd suggest running etch and installing etch's linux-image-2.6-k7, which will keep you running the latest 2.6.18 even if the ABI name changes. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is linux-image-2.6-k7 required?
Please reply to the list and not just to me. On Tue, May 29, 2007 at 04:45:12PM -0700, Phillip Pi wrote: Hmm, wasn't I running etch? I still would like to get 2.6.18 fixes. I'd have to say no since 2.6.21 is not in etch. $ cat /etc/apt/sources.list |grep etch deb http://security.debian.org/ etch/updates main contrib non-free $ cat /etc/apt/sources.list |grep sid deb http://download.videolan.org/pub/videolan/debian sid main deb-src http://download.videolan.org/pub/videolan/debian sid main deb http://www.debian-multimedia.org sid main I suggest you follow this process to identify where its coming from: 1) Comment out a sources.list entry 2) apt-get update 3) apt-get install linux-image-2.6-k7 4) If it still wants to install 2.6.21, goto 1 5) The last line you commented out is the problem I thought it was odd to see today's dist-upgrade wanted 2.6.21 Kernel. Am I missing something? Should I post my whole sources.list file? Feel free, but the above process should be sufficient for identifying the problem. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is linux-image-2.6-k7 required?
On Tue, May 29, 2007 at 07:00:44PM -0700, Phillip Pi wrote: deb http://ftp.us.debian.org/debian/ unstable main non-free contrib There you go, unstable == sid. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[SRM] kernel updates for oldstable
As previously noted[1], a 2.6 kernel security update is pending for sarge that changes the ABI. This update has now been NEW-processed, and a DSA should be released soon. I've spoken with Frans, and the plan is to do a spin of d-i ASAP as oldstable installs are currently rather broken. This respin would also include this ABI change. Since we're spinning d-i anyway, I thought I'd see if we could get some other non-security changes in there anyway. We've had some stuff queued for way too long (since before sarge released even). I re-examined each of the issues yesterday, and ended up with the following changes, most of which are things Horms had queued for a stable update (though I did drop 3 changes that I felt were of less than important severity), and a few that we've identified since. I have started builds across all of the architectures - I think the final one will complete tomorrow morning. If there are no objections to any of the proposed changes (or requests for an extended review cycle), I'll plan to upload tomorrow evening after some testing. kernel-source-2.6.8 (2.6.8-17) oldstable; urgency=high [ Simon Horman ] * drivers-net-via-rhine-wol-oops.dpatch (removed): This patch breaks the via-rhine driver and 2.6.8 and is completely bogus for this version of the kernel (closes: #311357) * drivers-media-vidio-bttv-vc100xp-detect.dpatch Allow Leadtek WinFast VC100 XP cards to work. * fs-jbd-checkpoint-assertion.dpatch Fix possible false assertion failure in log_do_checkpoint(). We might fail to detect that we actually made a progress when cleaning up the checkpoint lists if we don't retry after writing something to disk. * mm-rmap-out-of-bounds-pte.dpatch Stop try_to_unmap_cluster() passing out-of-bounds pte to pte_unmap() * net-ipv4-netfilter-ip_queue-deadlock.dpatch Fix deadlock with ip_queue and tcp local input path. * asm-i386-mem-clobber.dpatch: Make sure gcc doesn't reorder memory accesses in strncmp and friends on i386. * drivers-acpi-pci_irq-elcr.dpatch: Make sure we call acpi_register_gsi() even for default PCI interrupt assignment. That's the part that keeps track of the ELCR register, and we want to make sure that the PCI interrupts are properly marked level/low. [ dann frazier ] * Merge in applicable fixes from 2.6.12.4 - netfilter-deadlock-ip6_queue.dpatch - rocket_c-fix-ldisc-ref-count.dpatch - early-vlan-fix.dpatch [ Simon Horman ] * drivers-sata-promise-sataii_tx2_tx4.dpatch Add SATAII TX2 and TX2/TX4 support to sata promise driver (Closes: #317286) * module-per-cpu-alignment-fix.dpatch Module per-cpu alignment cannot always be met From 2.6.12.5 * genelink-usbnet-skb-typo.dpatch fix gl_skb/skb type error in genelink driver in usbnet Backported From 2.6.12.6 * drivers-ide-ppp-pmac-build.dpatch Make sure BLK_DEV_IDEDMA_PCI is defined for pmac ide driver builds (closes: #321442) * fs-ext3-nfs-parent-fix.dpatch ext3 file systems mounted over nfs may lookup .. in dx directories causing an oops. (closes: #323557) * sparc-request_irq-in-RTC-fix.dpatch Use SA_SHIRQ in sparc specific code. From 2.6.13.1 * forcedeth-init-link-settings-in-nv_open.patch forcedeth: Initialize link settings in every nv_open() From 2.6.13.2 * fix-MPOL_F_VERIFY.patch Fix MPOL_F_VERIFY From 2.6.13.2 * fix-more-byte-to-dword-writes-to-PCI_ROM_ADDRESS-config-word.patch Fix up more strange byte writes to the PCI_ROM_ADDRESS config word From 2.6.13.2 * yenta-oops-fix.patch yenta oops fix From 2.6.13.3 * fix-de_thread-BUG_ON.patch Fix fs/exec.c:788 (de_thread()) BUG_ON From 2.6.13.3 * ipv6-fix-per-socket-multicast-filtering.patch fix IPv6 per-socket multicast filtering in exact-match case From 2.6.13.3 * ipvs-ip_vs_ftp-breaks-connections.patch ipvs: ip_vs_ftp breaks connections using persistence From 2.6.13.3 * ieee1394-sbp2-fixes-for-hot-unplug-and-module-unloading.dpatch ieee1394/sbp2: fixes for hot-unplug and module unloading From 2.6.13.4 * fix-sparc64-fpu-register-corruption.dpatch [SPARC64]: Fix userland FPU state corruption. From 2.6.13.4 [ dann frazier ] * drivers-block-raw-ioctl2.dpatch, drivers-block-ioctl-enotty.dpatch: Fix a bug in the block layer that causes a bootloader installation error under certain conditions - breaks installation on cciss devices. (closes: #354493) * Fix data corruption with dm-crypt over RAID5 (closes: #336153) * Fix VLAN support for 3c59x/90x series hardware (closes: #349774) * Fix erroneous calculation of 'len' parameter to NLMSG_PUT resulting in bogus 'error during NLMSG_PUT' messages (closes: #372621) * hp-diva-rmp3.dpatch, hp-diva-hurricane.dpatch: Add PCI IDs for newer Diva console ports -- dann frazier [EMAIL PROTECTED] Sat, 26 May 2007 01:56:24 -0600 [1] http
Re: Scheduling linux-2.6 2.6.21-4
On Fri, May 25, 2007 at 10:20:48PM +0200, Bastian Blank wrote: Hi folks I'd like to schedule linux-2.6 2.6.21-4 for tomorrow. It only fixes the symbol versions for powerpc. Currently it is not possible to build modules against. After that, will you be amiable to a linux-latest-2.6 upload for 2.6.21, or are there other things that should be fixed first? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426035: Please add CONFIG_KEXEC
On Fri, May 25, 2007 at 08:32:46PM +0200, G??rkan Seng??n wrote: Package: linux-2.6 Version: 2.6.21-2 Severity: wishlist Can you add these to the kernel .config so kexec-tools gets usable? CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x10 CONFIG_RELOCATABLE=y CONFIG_PHYSICAL_ALIGN=0x10 That allows stuff like: # kexec -l /boot/vmlinuz-`uname -r` --append=`cat /proc/cmdline` # kexec -e Right, but isn't it true that you need a non-relocatable kernel to boot and a relocatable kernel to kexec (on x86)? In other words, doesn't this require an additional kernel flavor? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux-latest-2.6 update required for unstable/testing
2.6.18.dfsg.1-13 has been accepted into stable for the upcoming 4.0r1 release. However, I also need to upload various other packages including linux-latest-2.6. stable is not permitted to have a version greater than testing or unstable (and propagation does not automatically occur) so we will also need to update linux-latest-2.6 individually for those suites. Does anyone object to updating linux-latest 2.6 for 2.6.21-1 in sid? Other than the KERNELVERSION change, are there other things that need to happen first (e.g., removal of transition packages, etc)? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[SRM] linux-2.6 uploads to stable and testing
I have uploaded updates for linux-2.6: 2.6.18.dfsg.1-13 - s-p-u 2.6.18.dfsg.1-13lenny1 - t-p-u These uploads are identical other than the version and build environment. These are ABI changes so require NEW processing. A handful of other packages also need to be rebuilt against these updates (modules, fai-kernels, user-mode-linux, etc). What is the correct procedure for timing those uploads to insure that the buildds build against the correct source? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417121: can you reproduce with a later kernel?
hey Subhashis, Can you attempt to reproduce this bug with the 2.6.21 kernel in sid? It would be good to know if this still exists in recent kernels before forwarding this upstream. If you can reproduce, please include the entire output of 'dmesg' in your follow-up. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364607: reproducible in etch?
Can you let us know if this problem is still reproducible with etch's 2.6.18 kernel? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Where are the kernels ?
On Tue, May 22, 2007 at 04:32:05PM +0200, Hans wrote: Hi dear maintainers ! I am just wondering, why debian sid does not include the newest pre-build kernel-images (version 2.6.21). I found only the sources and the linux-kbuild, but no headers and no prebuilt linux-image. What is the reason of this ? (I use ftp.de.debian.org as source-server) The 64-bit-version are since about 2 weeks downloadable, but the 32-bit-versions stil not ! (In earlier times, 32-bit-versions were always ealier with packages than the 64-bit versions) You haven't told us what architecture you are using, so I'll assume the most popular which is i386. 2.6.21-2 was autobuilt successfully for i386 on May 19th: http://buildd.debian.org/fetch.cgi?pkg=linux-2.6ver=2.6.21-2arch=i386stamp=1179553434file=log But for some reason it has been stuck in incoming since the 19th: http://incoming.debian.org/ It looks like alpha, mips, and mipsel have been stuck since the 19th, and sparc since the 20th. I believe the correct group of people to contact for this issue are the FTP Masters, whom I've cc'd. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422284: Happened again
On Sun, May 13, 2007 at 01:56:50PM -0700, Rob Leslie wrote: The problem occurred again today during installation of a new package, this time against package version 2.6.18.dfsg.1-12etch2: Bad page state in process 'dpkg-preconfigu' page:c1209300 flags:0x8000 mapping: mapcount:0 count:8192 Trying to fix it up, but a reboot is needed hey Rob, This is most likely a sign of bad memory. You can try running one of the memtest86 tools to verify, but I'd suggest replacing this DIMM. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ipv6-disallow-RH0-by-default.patch causes a paging request error on the NSLU2
On Fri, May 11, 2007 at 12:05:27AM -0600, Gordon Farquharson wrote: Hi Dann The backported patch bugfix/ipv6-disallow-RH0-by-default.patch you checked into the etch branch of the kernel causes the kernel to issue the message, Unable to handle kernel paging request at virtual address 6261746d (see boot log below) on the Linksys NSLU2 (arm). The system boots successfully with all of the rest of the patches in series 13 applied. I can still ssh to the system, but the system is not stable. For instance, ifconfig never finishes running. Below the boot log, I have included the active process list after running ifconfig. It looks like the first version of the original patch in 2.6.20 and 2.6.21 was broken [1], The fix for the broken patch in 2.6.21 was committed after 2.6.21 was released [2] and is included in 2.6.21.1. I haven't looked at your backported version enough to see if the problem is the same as the problem described in the original patch. Thanks a lot for testing those snapshots, I'm glad you caught this. Unfortunately, this code changed a great deal between 2.6.18 and 2.6.20 - in fact, 2.6.18 didn't support the type 2 route headers. I'll revert for now and recommit when this is resolved. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ipv6-disallow-RH0-by-default.patch causes a paging request error on the NSLU2
On Fri, May 11, 2007 at 11:18:26AM -0600, dann frazier wrote: I'll revert for now and recommit when this is resolved. hey Gordon, Vlad Yasevich sent me a fix for this, and I've committed it in r8571. Would you mind testing this to confirm it fixes your problem? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux image upgrade overwrites menu.lst
On Wed, May 09, 2007 at 01:44:09PM -0500, [EMAIL PROTECTED] wrote: Sirs: Your latest update package has what I consider a BUG! Some of us have carefully-crafted /boot/grub/menu.lst files; mine had 6 entries spread across multiple drives. To just write over these files TWICE without asking or saving them to another non-existing extension is WRONG! Please fix your distribution system to at least ASK if we want our menu.lst overwritten, ESPECIALLY for something as trivial as a kernel image namechange. That's unfortunate, but menu.lst clearly says: ## lines between the AUTOMAGIC KERNELS LIST markers will be modified ## by the debian update-grub script except for the default options below update-grub isn't explicitly called by the scripts in linux-image, Rather it is setup as a hook in /etc/kernel-img.conf. If you would like to prevent update-grub from running on install, you can remove the hooks lines from that file. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412092: [Patch] bug in gdth.c crashing machine
On Mon, May 07, 2007 at 11:04:07AM +0200, Joerg Dorchain wrote: On Tue, May 01, 2007 at 07:32:57PM -0600, dann frazier wrote: You can retrieve snapshots from here: deb http://kernel-archive.buildserver.net/debian-kernel etch main This patch was committed in r8560, so you'll want to test a version = 2.6.18.dfsg.1-13~snapshot.8560 when its available. I only found linux-image-2.6.18-5-686_2.6.18.dfsg.1-13~snapshot.8564_i386.deb today and installed it. That is fine, it is = 2.6.18.dfsg.1-13~snapshot.8560. As the machine in question is in a production environment, it can take some time to find a maintaince window to test it. If so I will report. Ok - please let us know as soon as you're able. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug 404148.
On Mon, May 07, 2007 at 05:02:15PM +0200, ?ukasz Buczy?ski / Gadu-Gadu S.A. wrote: Hi. i'v been following discussion and you reply with etch repo on this address: deb http://kernel-archive.buildserver.net/debian-kernel etch main i saw that there is .deb files for other architecture not for amd64 only preconfigured but not compiled for it/on it. Can i get an information that there will be kernel compiled for amd64 arch ? I've added debian-kernel@lists.debian.org to the CC list. In the future, please contact that list instead of (or in addition to) me directly. There are a number of other people on our team that may be able to help. I do not see amd64 builds there either, and I don't know if there are plans to add them. You can always build your own snapshot by: 1) adding the following to your /etc/apt/sources.list file: deb-src http://kernel-archive.buildserver.net/debian-kernel etch main 2) apt-get update 3) apt-get install build-essential 4) apt-get build-dep linux-2.6 5) apt-get source -b linux-2.6 I've copied some pre-built debs to here, if that's easier: http://people.debian.org/~dannf/404148/ -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422640: linux-source-2.6.20: Changelog badly formatted?
reassign 422640 kernel-package thanks On Mon, May 07, 2007 at 03:17:38PM +0200, Vincent L??nngren wrote: Package: linux-source-2.6.20 Version: 2.6.20-3 Severity: normal I got this output from make-kpkg, and I don't know if there's actually something wrong with the changelog or if it's something with whatever is parsing it. hey Vincent, linux-source-2.6.20 does not provide this changelog file, so if this is a bug it is most likely a bug in kernel-package. However, I can not reproduce with my usual make-kpkg commands. Please provide the command you executed to generate this error so that we might reproduce. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404148: Upstream patch by nVidia
On Fri, May 04, 2007 at 10:34:39PM +0200, Marcin Gozdalik wrote: Hi I've been following this discussion as this problem hits many of my servers as well. Recently an upstream patch has appeared: http://groups.google.pl/group/linux.kernel/browse_thread/thread/4783711fa3d7592/dd12faec9a78f874 Is it possible to fix this problem in etch? You bet! I've committed this to our repository, I'd appreciate it if people with this hardware could test snapshot builds and reply to this bug report to confirm that it does (or doesn't) fix the issue on your system. Snapshot builds are available here: deb http://kernel-archive.buildserver.net/debian-kernel etch main Please try a version = 2.6.18.dfsg.1-13~snapshot.8564 (should be available within 24 hours). -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dropping initrd-tools from testing
hey, I don't see any reason to continue having initrd-tools in testing, so can we get a freeze exception to enable its removal? -- dann frazier | HP Open Source and Linux Organization -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412092: [Patch] bug in gdth.c crashing machine
On Fri, Feb 23, 2007 at 04:11:37PM +0100, Joerg Dorchain wrote: Package: linux-image-2.6.18-3-686 Version: 2.6.18-7 Tags: upstream,patch Severity: important Hello, there is a bug in the gdth driver causing crashes and potential data losses when using tape. The bug is also described and confirmed on the lklm on 13 Oct 2006 Message-ID: [EMAIL PROTECTED] The included patch is derived directly from that mail. Please consider including it until it has made it upstream, as it endangers machines doing tape backups. hey Joerg, Thanks for this report. This fix has gone upstream so I've queued this for the first etch update. I'd appreciate it if you could test a snapshot build that includes this fix and reply to this report. Such a snapshot build should be available within the next 24 hours. You can retrieve snapshots from here: deb http://kernel-archive.buildserver.net/debian-kernel etch main This patch was committed in r8560, so you'll want to test a version = 2.6.18.dfsg.1-13~snapshot.8560 when its available. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420875: fixed in 2.6.20-1
Version: 2.6.20-1 CVE-2007-1734 was fixed in 2.6.20.5 which was included in 2.6.20-1. CVE-2007-1497 was fixed in 2.6.20.3, also included in 2.6.20-1. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387741: resolved?
hey Thijmen, Is this issue resolved by the 2.6.18 kernel in etch? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421110: Upgrading linux-image-2.6.20-1-686-bigmem should never happen
On Thu, Apr 26, 2007 at 10:51:17AM -0400, Stefan Monnier wrote: I.e. it would require an explicit command on my part to install the newer kernel. Just put it on hold. echo linux-image-2.6.20-1-686-bigmem hold | sudo dpkg --set-selections -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [kernel] r8503 - in dists/etch/linux-2.6/debian: . patches/features patches/series
On Tue, Apr 24, 2007 at 09:44:49AM +, Maximilian Attems wrote: Author: maks Date: Tue Apr 24 09:44:48 2007 New Revision: 8503 Added: dists/etch/linux-2.6/debian/patches/features/agp-i965.patch Modified: dists/etch/linux-2.6/debian/changelog dists/etch/linux-2.6/debian/patches/series/13 Log: fix i965 board support hey Maks, Can you have someone test a snapshot w/ this patch and verify that it works? That would be good information to have in the bug report. And, since this is new support, what do you think about also including these two? [AGPGART] Add suspend callback for i965: 08da3f413f6aa3eb48cfc5331c68e57393167fe5 [AGPGART] intel_agp: PCI id update for Intel 965GM 4598af33d9143942f00cf7692b247027aba35316 -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419175: Additional info
On Sat, Apr 14, 2007 at 07:31:55PM -0400, Greg Hartman wrote: I built a kernel (the 2.6.8 version that shipped with Sarge) with CONFIG_USB_STORAGE_DEBUG=y. I then rebooted the system, waited 16 minutes, and tried to read from the disk with: dd if=/dev/sda of=/dev/null count=1 This failed with an I/O error. I have attached the dmesg output and also the output from lsusb. hey Greg, Can you reproduce with the 2.6.20 kernel in sid? It should be installable on an etch system. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416200: closing
Closing then, thanks! -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419475: linux-image-2.6.18-4-k7: erroneous behaviour of Realtek 8139, network practically unusable
On Mon, Apr 16, 2007 at 12:42:35AM +0200, David Garabana Barro wrote: This is the output of lspci for both cards (mainboard internal, and PCI): 01:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Flags: bus master, medium devsel, latency 32, IRQ 201 I/O ports at 8400 [size=256] Memory at e600 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 01:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Giga-byte Technology GA-7VM400M/7VT600 Motherboard Flags: bus master, medium devsel, latency 32, IRQ 193 I/O ports at 8800 [size=256] Memory at e6001000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 hey David, Can you provide the output of 'dmesg' for both your working 2.6.16 and your failing 2.6.18? Also, can you test the 2.6.20 kernel in sid? It should install fine on an etch system. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418879: linux-image-2.6.18-4-amd64: forcedeth lockup
On Thu, Apr 12, 2007 at 03:00:30PM +0100, root wrote: Package: linux-image-2.6.18-4-amd64 Version: 2.6.18.dfsg.1-12 Severity: important The driver locks up and it would appear to be most likely if there is a network problem such as a miss-configured switch giving a duplex miss-match. It complains about not resetting something tx side if you attempt to down/up the interface. hey Alister, Can you reproduce with the 2.6.20 kernel in sid? It should install cleanly in an etch environment. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.20 broken on several arches
On Wed, Apr 11, 2007 at 08:25:49PM +0200, Bastian Blank wrote: On Tue, Apr 10, 2007 at 01:58:59PM -0600, dann frazier wrote: Kyle created a patch for 2.6.20 that I've committed in r8460. I've got a few more config changes to commit, then hppa should be ready. The patch conflicts with other patches. Should be fixed in r8467: Author: dannf Date: Wed Apr 11 19:46:23 2007 New Revision: 8467 Added: dists/sid/linux-2.6/debian/patches/series/2-extra Modified: dists/sid/linux-2.6/debian/patches/series/2 Log: make parisc patch arch-specific. This is just a temporary workaround due to conflicts between the vserver and hppa patches. In general, it makes security maintenance easier if we avoid arch-specific patches as much as possible (*hint*) Modified: dists/sid/linux-2.6/debian/patches/series/2 == --- dists/sid/linux-2.6/debian/patches/series/2 (original) +++ dists/sid/linux-2.6/debian/patches/series/2 Wed Apr 11 19:46:23 2007 @@ -1,2 +1 @@ - features/mips/sb1-duart.patch -+ bugfix/hppa/parisc.patch Added: dists/sid/linux-2.6/debian/patches/series/2-extra == --- (empty file) +++ dists/sid/linux-2.6/debian/patches/series/2-extra Wed Apr 11 19:46:23 2007 @@ -0,0 +1 @@ ++ bugfix/hppa/parisc.patch hppa -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.20 broken on several arches
On Tue, Apr 10, 2007 at 11:46:42AM -0400, Kyle McMartin wrote: On Tue, Apr 10, 2007 at 04:48:52PM +0200, Bastian Blank wrote: Hi folks 2.6.20 is broken on the following arches: alpha, hppa, mips and mipsel. I fixed mips and mipsel by dropping the broken sb1250 uart patch. I did not dig into the alpha and hppa errors. What should we do about this topic? As we need the version in testing and linux-libc-dev for use by glibc ASAP, I think about dropping all images for this arches for now until it is fixed (which may correlate with the availability of 2.6.21 ...). The relevant fixes for hppa have been merged into 2.6.21, but I provided a patch for 2.6.20 for Ubuntu. Either option is acceptable to me. Kyle created a patch for 2.6.20 that I've committed in r8460. I've got a few more config changes to commit, then hppa should be ready. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing 2.6.18.dfsg.1-13
On Mon, Apr 09, 2007 at 04:48:29PM +0200, Bastian Blank wrote: On Sun, Apr 08, 2007 at 01:38:31PM -0600, dann frazier wrote: Sure, I can handle them. Okay. You want to use the -XetchY namespace for security builds and the -X for p-u uploads? The first is no problem, but the later is if we don't update linux-2.6 in testing ASAP. That was my default plan, but I can use -XetchY in the meantime for both since they need to be ordered anyway. Rebuild on every linux-2.6 update - fai-kernels user-mode-linux BinNMUs at least for fai-kernels will work. Ah, good point. Rebuild on ABI changes -- linux-latest-2.6 linux-modules-contrib-2.6 linux-modules-extra-2.6 linux-modules-nonfree-2.6 loop-aes nvidia-kernel-legacy-2.6.18-4-amd64 Hmm? What's your question? Does this need rebuilding? -- firmware-nonfree No. Except that the build dependencies will go away. A FTBFS is certainly a regression, so I suppose this should be on the ABI change list? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412850: Please add GRUB/sarge conflict for users of backports.org
On Mon, Apr 09, 2007 at 01:06:51PM +0200, Christian Hammers wrote: On 2007-04-07 Jonas Smedegaard wrote: Christian Hammers wrote: Users of sarge+backports.org suffer the problem that their GRUB does not know how to load the hypervisor module. Please add the following to give them a hint: Conflict: grub ( 0.97-16) (This could, of course, be done by the backporters, too, but it would be easier and AFAIK without drawbacks if be done by you.) I believe such conflict would have a high risk of causing grub to get removed, rather than the intended refusal to install the kernel. Hm, that would be bad indeed :) Given that Etch is almost due, maybe just tag it wontfix for reference.. Since the kernel bug tracking system is currently overloaded, I'm going to go ahead and close this. This bug will still be found in google, etc, since this is in public mailing list archives now. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing 2.6.18.dfsg.1-13
On Sun, Apr 08, 2007 at 08:22:58PM +0200, Bastian Blank wrote: On Thu, Apr 05, 2007 at 03:01:41PM -0600, dann frazier wrote: aba tells me that we should be able to do our first upload real soon now. Once he gives me a go, I'd like to upload a -13. Again, that doesn't mean that -13 will ship in r1 - if we resolve additional issues in time we can always do another upload. Please let me know if you have any concerns about this plan, or if you have any imminent fixes we should wait for. This is fine for me. Do you want to handle the uploads? Otherwise I can take my hands on it. linux-latest-2.6 needs to be updated as well. Sure, I can handle them. From what I can tell, the following packages need to updated along with linux-2.6 (in dists/etch/dependent-pkgs in svn). Are there any obvious ones missing? Rebuild on every linux-2.6 update - fai-kernels user-mode-linux Rebuild on ABI changes -- linux-latest-2.6 linux-modules-contrib-2.6 linux-modules-extra-2.6 linux-modules-nonfree-2.6 loop-aes nvidia-kernel-legacy-2.6.18-4-amd64 nvidia-graphics-legacy-modules-i386 nvidia-graphics-modules-amd64 nvidia-graphics-modules-i386 Does this need rebuilding? -- firmware-nonfree -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418076: linux-2.6: cannot mount network filesystems
Package: linux-2.6 Version: 2.6.18.dfsg.1-12 Severity: important Tags: patch The VXC_BINARY_MOUNT capability should be sufficient to mount network filesystems, but its not. Due to this bug, users currently must grant a vserver SYS_ADMIN capabilities in order to mount network filesystems. Though this works, SYS_ADMIN also gives the vserver a hell of a lot of other privileges as well (turn swap off on, configure md, access to nvram, etc). See http://linux-vserver.org/Capabilities_and_Flags for the full list. This patch from upstream fixes the issue. diff -NurpP --minimal linux-2.6.18.5-vs2.0.2.2-rc9/fs/super.c linux-2.6.18.5-vs2.0.3-rc1/fs/super.c --- linux-2.6.18.5-vs2.0.2.2-rc9/fs/super.c 2006-09-20 17:59:47 +0200 +++ linux-2.6.18.5-vs2.0.3-rc1/fs/super.c 2006-12-13 23:06:16 +0100 @@ -848,7 +848,7 @@ vfs_kern_mount(struct file_system_type * sb = mnt-mnt_sb; error = -EPERM; - if (!capable(CAP_SYS_ADMIN) !sb-s_bdev + if (!vx_capable(CAP_SYS_ADMIN, VXC_BINARY_MOUNT) !sb-s_bdev (sb-s_magic != PROC_SUPER_MAGIC) (sb-s_magic != DEVPTS_SUPER_MAGIC)) goto out_sb; -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: ia64 Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-itanium Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336153: Bug 336153 must be fixed ASAP - filesystem corruption IS critical!
On Thu, Apr 05, 2007 at 05:37:27PM +0200, Tillmann Steinbrecher wrote: Hi, I can't understand why Bug 336153 still has status pending. It's a well-known issue that causes massive data corruption. It is reproducible and has been confirmed by several people, including the dm-crypt developer himself. A patch has been available for several MONTHS. It's a simple 4-line patch. How come it isn't applied for the etch kernel? It is required for kernel 2.6.18 which is used for etch. It is NOT required for 2.6.19 and future kernels. See also: http://www.spinics.net/lists/dm-crypt/msg00481.html It is fixed in 2.6.18, #336153 is for sarge (2.6.8) which is where it is still pending. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Preparing 2.6.18.dfsg.1-13
The SRM team would like for us to keep s-p-u current with our latest fixes, rather than holding back uploads until just before a point release. This means we may upload multiple candidates before one actually makes it into etch. This should increase our testing base, get us autobuilt on more architectures[1], and hopefully reduce the latency of doing regular point releases. aba tells me that we should be able to do our first upload real soon now. Once he gives me a go, I'd like to upload a -13. Again, that doesn't mean that -13 will ship in r1 - if we resolve additional issues in time we can always do another upload. Please let me know if you have any concerns about this plan, or if you have any imminent fixes we should wait for. Since both the etch and etch-security branches contain ABI breakers and since neiter of the security issues is critical enough (imo) to warrant an immediate DSA, I plan to merge the security changes into the etch branch and introduce them in r1. [1] kernel-archive.buildserver.net is doing snapshot builds for the etch branch, so that should catch most build issues and help us catch issues in-between uploads to s-p-u -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404148: disabling hw iommu on nvidia
hey Andi,
Debian is looking at patching our kernel to disable the hw iommu on
nvidia chipsets for the data corruption bug that's been discussed on
lkml[1]. As far as I can tell there isn't an upstream solution yet, but
Steve Langasek has proposed the following patch which seems to work
for one of our users. Would you mind taking a look at it and see if
you can pick out any obvious problems?
The full text of this discussion can be found at:
http://bugs.debian.org/404148
[1] http://marc.info/?l=linux-kernelm=116898325616149w=2
--- a/arch/x86_64/kernel/io_apic.c 2007-03-22 00:54:33.0 -0700
+++ b/arch/x86_64/kernel/io_apic.c 2007-03-22 01:13:06.0 -0700
@@ -344,6 +344,22 @@
timer override.\n);
}
#endif
+#ifdef CONFIG_IOMMU
+ /* Forcibly disabling nvidia HW iommu,
+ per Debian bug #404148. */
+ if ((end_pfn MAX_DMA32_PFN ||
+force_iommu)
+ !iommu_aperture_allowed) {
+ printk(KERN_INFO
+Looks like an nvidia chipset. Disabling HW IOMMU. Override with
\iommu=allowed\\n);
+#ifdef CONFIG_SWIOTLB
+ swiotlb = 1;
+#else
+ no_iommu = 1;
+#endif
+ }
+#endif
+
/* RED-PEN skip them on mptables too? */
return;
--
dann frazier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404148: disabling hw iommu on nvidia
On Tue, Apr 03, 2007 at 12:37:09AM +0200, Andi Kleen wrote: On Tuesday 03 April 2007 00:29:16 dann frazier wrote: hey Andi, Debian is looking at patching our kernel to disable the hw iommu on nvidia chipsets for the data corruption bug that's been discussed on lkml[1]. It would be better if you waited until the official solution. The hardware debugging people are working on it. You'll likely get more problems out of swiotlb because the defaults are too small for high loads. As far as I can tell there isn't an upstream solution yet, but Steve Langasek has proposed the following patch which seems to work for one of our users. Would you mind taking a look at it and see if you can pick out any obvious problems? You got at least one off by one bug. And SWIOTLB cannot be undefined with CONFIG_IOMMU so the nested ifdef is useless. Because of where we are in the release cycle we will have to wait a little while anyway before we can do an update - hopefully the hw guys will have had some success by then. Thanks for the quick review! -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
On Sat, Mar 31, 2007 at 03:58:49AM -0700, Steve Langasek wrote: On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote: As I've told you in my email before I just tested your patch with the following results (used linux-source-2.6.18 (2.6.18.dfsg.1-12) from testing, of course on an amd64 system): - The patch applies without problems - The kernel compiles with it without problems (at least with my config) - It boots correctly - and it automatically disables the hardware iommu (look at my dmesg below): Thanks, that's great to hear. Agreed - good work on the patch Steve, and thanks for testing Christoph. I would say (although I'm by any means not kernel expert) that your patch looks good and I _strongly_ recommend to include it in etch r0 (!!)... You're the release manager,... so you should get managed this :-) It wouldn't be appropriate for me to push this without the consent of the rest of the kernel team just because I'm the release manager; I'm not even an amd64 porter, this should be signed off on by the folks who are actually responsible for the amd64 kernel first. I see no reason not to include it in r1, at least until upstream finds something better. Does anyone disagree? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416519: linux-source-2.6.18: Suggests non-existant package ncurses-dev
On Wed, Mar 28, 2007 at 06:40:29AM -0400, Max Hyre wrote: Package: linux-source-2.6.18 Version: 2.6.18.dfsg.1-11 Severity: minor Its a virtual package: [EMAIL PROTECTED]:~$ apt-cache show libncurses5-dev | grep ^Provides Provides: libncurses-dev, ncurses-dev -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412143: unreproducible in 2.6.18
fyi, I've been trying to reproduce this in 2.6.18, but haven't been able to. The vserver developers believe the bug wasn't actually introduced until 2.6.19. So, our patch in -12 was likely unnecessary. -- dann frazier | HP Open Source and Linux Organization -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412132: abi bump
Saw this on IRC wanted to record it... waldi dannf: can you please take a look at #412143? waldi hrm, I can't fix #412132 without abi bump waldi someone defined atomic_t as signed vorlon r1, then? waldi yes -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: troubles with DAC960
On Sat, Mar 24, 2007 at 03:38:20PM +0100, Boris Andratzek wrote: Hello members of the debian kernel list, I'm new to this and hope I don't misuse the list in any way. Doing the update from debian sarge to etch on my server I ran into the bug documented here: bugzilla.kernel.org/show_bug.cgi?id=7177 I already made some comments there. I tried to contact the maintainer of the DAC960 driver but as far as I found out, Leonard N. Zubkoff unfortunatly died in a helicopter crash. Without being impious, I want to ask if anybody can give me an idea of how this thing will go on. Is there anybody new doing the maintaining? hey Boris, That's a question for upstream - the upstream list is here: http://vger.kernel.org/vger-lists.html#linux-scsi Is there hope for a fix? Where can I find more information? Can I do anything to help (testing, logging)? I think the most useful information you could add to 7177 is to identify the specific change that broke it. The original reporter claims that this was broken after 2.6.11 - can you verify that 2.6.11 worked and 2.6.12 is broken? If you can do that, then you can try to use git bisect to identify the commit that changed this behavior. Since this is pre-2.6.12, you probably need to use the bitkeeper import git tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/old-2.6-bkcvs.git Instructions for using git bisect can be found here: http://dannf.org/bloggf/tech/git-bisect.html And please contact us when there is an upstream fix so that we can include it in Debian. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#251023: upstream status of acpi-dsdt-initrd patch
hey, I did a little research this morning to try to formulate an opinion - here's what I found: * This patch is not upstream and is unlikely to go upstream. The ACPI maintainer doesn't seem to doubt its quality, but rather believes its a development tool and not something distributors can support[1]. * Fedora has chosen to follow upstream and not include this patch[2], while SuSE, Ubuntu, and Mandriva do include it[3]. * There are cases where a different DSDT is necessary for our kernel to work on certain hardware. A friend of mine gave me his real-life example of a device where the DSDT reports the wrong interrupt link. noacpi doesn't disable acpi-based interrupt routing. irqpoll would work, but the performance hit is too high. A device quirk could be added to the kernel to workaround this device, but this device has a generic pci device/vendor and subsystem device/vendor, so it would be at least difficult. So it seems clear to me that we'd be alienating users by not including this patch, but we'd also be introducing a feature we cannot support. I don't believe that our patch acceptance guidelines[4] should make it impossible for us to consider this patch. The upstream guideline is there because we don't want to include sub-par code, and we don't want to maintain a feature that we introduced but has been abandoned upstream. I don't think either of these applies here, at least not terminally. The patch appears to be pretty robus, though the coding issues waldi uncovered should certainly be looked into, and I think we could work with other distributions to continue maintenance of the patch in the event that upstream drops it. I agree with upstream/Fedora that this isn't something we can support - if someone reports a bug, its quite possible its caused by their hacked system firmware, and there's nothing in a bug report that would tip us off to this. Of course, we deal with similar scenarios today - non-free kernel modules and userspace-loaded firmware. non-free kernel modules are dealt with using tainting, while userspace-loaded firmware problem is just simply less likely to be hacked. I think that it should be clear to our users that using this is unsupported, and any bugs they report need to be reproduced w/o loading DSDTs. Would it be possible for us to add our own tainting signature for this case? It seems to match well with the goals of tainting. Documentation/oops-tracing.txt says: The primary reason for the 'Tainted: ' string is to tell kernel debuggers if this is a clean kernel or if anything unusual has occurred. And the use of tainting doesn't appear to be limited to modules - the unsafe-SMP case identified by the 'S' in the taint signature is an example. I also wonder if ACPI upstream would re-consider including this patch if DSDT-tainting was implemented? [1] http://sourceforge.net/mailarchive/message.php?msg_id=9175150 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169014 [3] http://gaugusch.at/kernel.shtml [4] http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why does r8375 change the ABI?
On Fri, Mar 23, 2007 at 09:51:02AM +0100, Bastian Blank wrote: On Thu, Mar 22, 2007 at 06:23:47PM -0600, dann frazier wrote: The linux-2.6 build reports that this patch (fix for CVE-2006-5753) breaks the ABI - but I can't seem to figure out why. Can you please provide the output of the abi check? Are only some functions affected or all? [EMAIL PROTECTED]:~/tmp/linux-2.6-2.6.18.dfsg.1$ python2.4 \ debian/bin/abicheck.py debian/build/build-i386-none-486 i386 none 486 ABI has changed! Refusing to continue. Changed symbols: is_bad_inode version: 0xa68da888- 0xe0848c31 make_bad_inodeversion: 0xf14b2332- 0x900a13d5 Troy Heber narrowed down the breakage to the addition of the #include linux/poll.h line, but he couldn't identify the change in the object files. He need to check the debugging output of the versions tool. It does a source-level check and may be confused by some construct. Ok - what is the name of the versions tool? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415972: No xen kernel image for k7 anymore!
On Fri, Mar 23, 2007 at 03:56:39PM +0100, Ralph Passgang wrote: Package: linux-source-2.6 Version: 2.6.18.dfsg.1-11 Severity: important Tag: etch With 2.6.18-4 Debian switched from non-pae to pae-only xen kernels. This means that xen is not useable anymore for many users, which were able to use non-pae kernels without a problem for a long time till now. Actually they did have a problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399113 Dear debian-kernel-team, please rethink your position of pae-only xen kernels and reupload at least a working k7 kernel image again. Just having pae kernels in the archive is a very unwise decision. For me there is no technical reason for not shipping standard images without pae... A fix for the above bug is necessary (waldi would have to say whether it is sufficient) to add non-pae images to the build. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410010: tested, pending for -12
I tested this fix on a system here and it seems fine. I've committed it for -12. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the -12 question
On Thu, Mar 22, 2007 at 01:31:30AM +, Oleg Verych wrote: From: dann frazier Newsgroups: gmane.linux.debian.devel.kernel Subject: the -12 question Date: Wed, 21 Mar 2007 18:44:08 -0600 [] * I also propose we use the requirements in my etch-updates proposal for fixes (must have bug filed, must be important or greater) Is it possible to have a way for ti-usb serial patches (removing firmware and hotplug, tested by upsteam author) there? Shall i file a bug for that? Sure - you can certainly file a bug for it and we can consider it. Please include an explanation of what it fixes (and why we should consider it important severity or greater, if its not obvious) along with the upstream status. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
why does r8375 change the ABI?
The linux-2.6 build reports that this patch (fix for CVE-2006-5753) breaks the ABI - but I can't seem to figure out why. Troy Heber narrowed down the breakage to the addition of the #include linux/poll.h line, but he couldn't identify the change in the object files. Anyone here have any ideas? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
the -12 question
Steve asked on IRC about doing a -12 for 4.0r0. There are a few RC bugs and a few security bugs that we could fix before then. Of those present on IRC (vorlon, fjp, fs and myself), there was a consensus to proceed. Does anyone on the kernel team object to this? The details... * This would not involve a spin of d-i[1] * No ABI changes would be permitted (obviously) * We would upload to unstable * I've already merged my changes from the etch-security branches onto the etch branch. There are other pending CVEs, but nothing I think is a must before etch (but I might add others while -12 is open) * vorlon would like to see this uploaded over the weekend, I propose an upload before Monday's dinstall. waldi: is it possible to get snapshot builds of the etch branch going for this? * I also propose we use the requirements in my etch-updates proposal for fixes (must have bug filed, must be important or greater) Here's the current list of stuff I'd been tracking for an etch update - this doesn't mean they were approved by the SRM team, just that they are on my list of things to review: http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED];which=tagdata=dkt-etch-update [1] dannf does it mean a spin of d-i? vorlon no dannf (no ABI change would be allowed of course) vorlon it's likely that fjp won't approve, but I've done the due diligence for the GPL source issues, and I see no reason to re-spin d-i over a simple kernel upgrade fjp Unless there are functional fixes in there too that would improve d-i, I guess I can live with it. -- dann frazier | HP Open Source and Linux Organization -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412132:
On Mon, Mar 19, 2007 at 07:03:35PM +0100, Patrick Matth??i wrote: Hi, I'm sorry but when will the update with the fix available (ca ~). Its too early to say. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Towards consensus of our usage of the Uploaders field
On Fri, Mar 16, 2007 at 02:19:11AM +0100, Frans Pop wrote: On Thursday 15 March 2007 21:32, dann frazier wrote: Given this, I believe anyone on the kernel team should be permitted an entry in the Uploaders field. I also do not believe that the presence of a maintainer's name in the Uploaders field grants them any additional privileges. Uploads still need to be coordinated on the mailing list, etc. In the D-I team we treat the Uploaders field differently. Uploaders are people who actually coordinate the package or do frequent uploads because of their role in the project (e.g. the release manager). Thanks for this description Frans. Is this treatment simply the way it has always done it, or are their other justifications/polices around it? For example, if you are not currently in Uploaders and you wish to do an upload, do you just add yourself to Uploaders and upload? Or, must you achieve a rough consensus among the other uploaders and/or the release manager? Or, eg., does the d-i team use this because they believe it provides information to the outside world such as these are the people I need to poke about accepting my patch, etch? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Planning kernel updates in etch
On Thu, Mar 15, 2007 at 02:07:24PM +0200, Jurij Smakov wrote: On Tue, Mar 13, 2007 at 10:39:34AM -0600, dann frazier wrote: hey, I'd like to start a discussion on how we will go about doing updates to etch after its initial release. [proposal skipped] I think it's a very reasonable proposal and I'll start handling sparc patches, intended for kernel's etch point releases according to it. Thanks. I haven't received any negative comments, so I'll update the usertag wiki to reflect it. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Planning kernel updates in etch
On Tue, Mar 13, 2007 at 10:39:34AM -0600, dann frazier wrote: I propose that we continue using usertags for this purpose, but only two of them - one for security, and one for non-security. We can use the 'pending' tag to differentiate between issues that are fixed in svn and those that are not yet fixed (pending flag is added automatically by a post-commit hook anyway). My suggestion is simply 'dkt-etch-update' and 'dkt-etch-security-update'. Neither imply the status of the bug, which I think is sufficiently handled by other tags. Actually, I'd like to modify this proposal and suggest that we only use dkt-etch-update. Security bugs should have the 'security' tag, so the extra usertag is redundant as well. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Towards consensus of our usage of the Uploaders field
According to policy 5.6.3: List of the names and email addresses of co-maintainers of the package, if any. If the package has other maintainers beside the one named in the Maintainer field, their names and email addresses should be listed here. Given this, I believe anyone on the kernel team should be permitted an entry in the Uploaders field. I also do not believe that the presence of a maintainer's name in the Uploaders field grants them any additional privileges. Uploads still need to be coordinated on the mailing list, etc. Does this match other people's interpretations? Let's please use this thread to achieve consensus on Uploaders usage. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Towards consensus of our usage of the Uploaders field
On Thu, Mar 15, 2007 at 10:43:49PM +0100, Bastian Blank wrote: On Thu, Mar 15, 2007 at 02:32:29PM -0600, dann frazier wrote: Does this match other people's interpretations? Let's please use this thread to achieve consensus on Uploaders usage. No. What is your interpretation Bastian? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about config of Debian/unstable kernel
On Fri, Feb 23, 2007 at 06:34:25PM +0100, Patrick Vervoorn wrote: Hello there, I'm running the following Debian-unstable kernel: Linux morannon 2.6.18-4-686 #1 SMP Wed Feb 21 16:06:54 UTC 2007 i686 GNU/Linux Aptitude says: --\ Versions i2.6.18.dfsg.1-11 Is this kernel compiled/generated with the Large Block Devices enabled? Reason, I've mounted a 3.0TB filesystem via samba, but am seeing only 2.0TB of it via, for instance, df. If this is not enabled, is there an easy way to do enable it in this binary kernel image, or do I have to generate my own kernel? [EMAIL PROTECTED]:/tmp$ grep LBD /boot/config-2.6.18-4-686 CONFIG_LBD=y -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414874: kernel-image-2.6.8-3-386: LVM and devfs interaction cause may error messages during startup
reassign 414874 kernel-source-2.6.8 tag 414874 + moreinfo stop On Wed, Mar 14, 2007 at 12:37:19PM +0100, Ramon Garcia wrote: Package: kernel-image-2.6.8-3-386 Version: 2.6.8-16sarge6 Severity: important In a system configured with LVM, the initrd uses devfs during startup. When the LVM system is activated (vgchange -a y), the screen is filled with errors messages devfs_mk_dir: invalid argument devfs_mk_dev: could not append to parent for disc (this is repeated about ~ 100 times or more) hey Ramon, Thank you for the patch. Can you add some justification for the important severity? e.g., does it cause the boot to fail? Unfortunately at this point in the lifetime of sarge we will only fix bugs of a high severity. This shouldn't be an issue for etch, as devfs is no longer included. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Giving d-kernel write to David H?rdeman
On Wed, Mar 14, 2007 at 09:37:00PM +0100, maximilian attems wrote: unless there are objections, I intend to pass d-kernel write access to David H?rdeman (alphix-guest). He has done a great job in the early userspace support of the upcoming etch release. next initramfs-tools release adds him to the uploaders field. we have interesting plans on how to improve initramfs-tools. having write access to the same initramfs-tools repo would make the collaboration much easier. No objection here -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Planning kernel updates in etch
hey, I'd like to start a discussion on how we will go about doing updates to etch after its initial release. Security Updates Security updates will happen in dists/etch-security in svn and I'll continue to coordinate those. However, I'd love to have some help/redundancy for this. Very little of the work actually requires being on the security team or having access to vendor-sec, and the tracker for these issues scales pretty well w/ multiple people. Please contact me if you're interested (and/or see the kernel-sec repo on svn.debian.org). Stable Updates -- In etch, we should really start taking advantage of point releases updates to fix bugs. What bugs can be fixed in a stable update? -- The stable release team considers bugs of severity important or greater to be candidates for a stable update. Additional device support is considered 'important', so low-risk/well tested driver updates are possible. What bugs cannot be fixed in a stable release? -- The _most_ important thing is that we must not break existing systems. So even if something fixes an unquestionably important bug, it may still be rejected because it adds too much risk. ABI changes are considered high risk. If you want to get in a fix that is considered too risky for 2.6.18, your best bet is to get it upstream so that its available for a possible etch 1/2 kernel (see below). Every commit targeted for a stable update should include a changelog entry that references a bug report with an appropriate severity. This makes it easier for the SRM team to review the issue. We should certainly watch the various stable git trees for updates, but they should not be treated specially. Each fix we pull in should have a = important bug that clearly justifies its inclusion. Commits should occur under dists/etch in svn (looks like this was branched already). We'll of course have to merge security updates in periodically. etch 1/2 kernel - As discussed last summer, let's look into adding a new kernel into etch at some point. I'd personally like to time this to occur about a year after etch so that we won't be trying to do security updates on sarge, etch and etch 1/2 all at the same time. If you want to add support for a new device but its too risky to do so in 2.6.18, this is the way. Using usertags to track --- In the past we've used usertags to track bugs queued for a stable update, all under user [EMAIL PROTECTED] dkt-pending-sarge-update: queued for a point release dkt-pending-sarge-security-update queued for a security update These are documented on our wiki page: http://wiki.debian.org/DebianKernelBTSUserTags There's also a new one added there: dkg-waiting-etch-update Which seems to exist for fixes that are queued, but not yet committed. I propose that we continue using usertags for this purpose, but only two of them - one for security, and one for non-security. We can use the 'pending' tag to differentiate between issues that are fixed in svn and those that are not yet fixed (pending flag is added automatically by a post-commit hook anyway). My suggestion is simply 'dkt-etch-update' and 'dkt-etch-security-update'. Neither imply the status of the bug, which I think is sufficiently handled by other tags. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402751: [EMAIL PROTECTED]: Bug#402751: Works on Dell Optiplex gx620.]
Thanks for the update, closing then. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SMTP server in Debian GNU/Linus Systems
On Wed, Mar 07, 2007 at 10:28:46AM +1100, Lena Chong wrote: Dear sir/madam, I am using debian Linux. What package should I install to make it as a SMTP server ?? Where can I download such package ?? hey Lena, Please contact the debian-user list. The debian-kernel list is for kernel development discussions. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: reportbug script for linux-image
On Sun, Mar 04, 2007 at 07:43:30PM +0100, Bastian Blank wrote: Hi folks There was some calls to add reportbug scripts to all the linux packages. That'd be cool They should add the following informations to the bugreport if it is the running kernel: - lsmod - dmesg It might be better to include /var/log/kern.log, since dmesg may have overflowed since boot (but, I suppose you could argue that we should use dmesg explicitly to limit the size of the report by default). -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391867: Please reopen that bug.
reopen 391867 found 391867 2.6.18.dfsg.1-11 thanks On Mon, Mar 05, 2007 at 09:36:55PM +0100, Michael Altmann wrote: Dear Debian Developers, the bug seems still existing on my machine. I'm Using linux-image-2.6.18-4-686 (2.6.18.dfsg.1-11) while the bug report claims to be fixed in 2.6.18.dfsg.1-9. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412789: xorg: mouse cursor does not move with Debian kernel newer than 2.6.18
On Wed, Feb 28, 2007 at 08:26:11AM +0100, Stefan Hirschmann wrote: Package: linux-image-2.6.18-4-k7 Version: 2.6.18.dfsg.1-11 Severity: critical Justification: breaks unrelated software When I am booting with the Debian linux-image-2.6.18-4-k7 then in X.org the mousecursor is not moveable. This means: I can move the mouse, but the cursor stands still on the same place. With my self compiled kernel everything works fine. Also with the Debian linux-image-2.6.16* everything worked fine, so I am sure, that this bug is related to the kernel. Without a mouse, X.org is not useable for me and so I made the Severity critical, breaks unrelated software. Please provide your /etc/x11/xorg.conf file, the output of dmesg, and your /var/log/Xorg.0.log file. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412837: use udev aliases
hey Sebastian, When you accessing devices using the /dev/sd* names, you are counting on the same ordering each time. If you want to use a name that won't change, try one of the aliases under /dev/disk. For example, I use the following line in my /etc/fstab to mount my usb stick: /dev/disk/by-id/usb-PNY_USB_2.0_FD_6E59150036E6 /media/usb vfat noauto,defaults 0 0 Linux does not guarantee ordering of /dev/sd* devices, so this is not a kernel bug. [1] and really cannot, since driver loading is a userspace thing -- dann frazier | HP Open Source and Linux Organization -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413078: Gcc does not work after kernel upgrade
On Fri, Mar 02, 2007 at 02:13:22PM +0800, Andrew Buckeridge wrote: package: linux-image-2.6.18-4-amd64 version: 2.6.18.dfsg.1-11 Trivial program now segfault and/or get garbled data from functions. Please include an example program, and instructions on compiling it. Also, what kernel did you upgrade from where this program did work? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
