Re: Kernel 2.4 for etch or not
On Monday 30 January 2006 03:29, Alexander Schmehl wrote: Wouldn't it then be possible then to drop D-I support for 2.4 and ask user to install the old kernel, if needed after the installation? At least if supporting 2.4 for D-I is getting to complicate... Switching from 2.4 to 2.6 (and vice versa) has its own problems for users. See the Sarge release notes for some possible issues. But yes, in theory that would be an option (though only for i386). pgp31HuC0eoqq.pgp Description: PGP signature
Bug#100421: Greetings,
How are you, [EMAIL PROTECTED] We spoke a few days ago and I'd like to confirm everything now. Please go over the information below and let me know if you have any questions. www.queenla.com/am/ We are accepting your form. Your status has been accepted. We need to confirm your details one more time. Just check the URL above and fill out our last form. Sincerely, [EMAIL PROTECTED] Wilton G. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350482: [hppa] module xfs relocation of symbol freeze_bdev is out of range
On Sun, Jan 29, 2006 at 10:24:55PM +0100, Frans Pop wrote: I have cloned the installation report to #350482 and reassigned that to the linux-2.6 source package for this issue. The user confirmed this issue is still there for 2.6.15. I'll leave it to kernel maintainers to determine if this should be RC or not. The problem is caused because the module is too damn big and a 17-bit branch displacement relocation can't reach a symbol. I think Randolph was working on this for Fabio, not sure what the results of that were... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295657: EXT3 on RAID problems in all 2.6-smp
Hi all, I am mailing to close this bug. Some time ago I found out what the real cause of it all was: a faulty memory chip. At boot time it checked out fine, and even during operations it faulted only in 5% of the cases or so. Intense runs of memtest86+ revealed the problem. I removed the chip and no more problems since. Thanks to all that have tried to help out! Cheers, Jeroen On Tuesday 31 May 2005 13:52, Jeroen van Disseldorp wrote: Well it happened again last weekend, with 2.6.11-1-686-smp this time: May 26 22:39:11 einstein kernel: EXT3-fs error (device dm-2): ext3_readdir: bad entry in directory #82935810: rec_len %% 4 != 0 - offset=0, inode=23147 May 26 22:39:11 einstein kernel: Aborting journal on device dm-2. May 26 22:39:12 einstein kernel: EXT3-fs error (device dm-2) in ext3_reserve_inode_write: Journal has aborted May 26 22:39:12 einstein kernel: EXT3-fs error (device dm-2) in ext3_dirty_inode: Journal has aborted May 26 22:39:12 einstein kernel: ext3_abort called. May 26 22:39:12 einstein kernel: EXT3-fs error (device dm-2): ext3_journal_start_sb: Detected aborted journal May 26 22:39:12 einstein kernel: Remounting filesystem read-only If I can provide any more info, please let me know. Jeroen On Thursday 19 May 2005 17:04, maximilian attems wrote: severity 295657 important stop On Thu, 19 May 2005, Erik Forsberg wrote: On Wed, 2005-05-18 at 22:44 +0200, maximilian attems wrote: can you try to reproduce it with more recent 2.6.11 from unstable? In my case, the machine in question is unfortunately running as a medium-sized mailserver. It's a rather bad idea to use it for file system trashing tests. agreed. I will receive a P4 (HyperThreaded) machine at work in a few weeks. I might be able to do some quick tests on that hardware. Btw, http://marc.theaimsgroup.com/?l=linux-kernelm=107913912311421w= 2 seems to be a relevant thread on Linux-kernel. thanks for the pointer, unfortunately the thread ends without conclusion. so i can't help you atm. good luck. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 for etch or not
On Sun, 2006-01-29 at 23:18 +0100, maximilian attems wrote: On Sun, 29 Jan 2006, Moritz Muehlenhoff wrote: Holger Levsen wrote: Even though 2.4 is moving very slowly nowadays (mostly security updates, very seldom new drivers are including), this is more work than needed, because every fix needs to be backported to 2.4.27 (and 2.4.18 for woody). According to a linux-kernel posting by Marcelo Tosatti a few weeks ago 2.4 is now in strict maintenance mode, with only critical bug fixes being allowed. As of today several of the security fixes for 2.4 are already pushed upstream by Dann or Horms, it's unreasonable to do so until 2010, when Sarge's oldstable support will fade out. indeed both seem to do most of the 2.4 security support, more than upstream does. so there word should count the most concerning an eventual 2.4 in etch. Security support for 2.4 is already becoming difficult; I really wouldn't want to support it in the etch timeframe. Clearly we'll have to drop support for 2.4 at some point - I vote for when security support for sarge stops (after its lived out its oldstable lifespan). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295657: marked as done (EXT3 on RAID problems in all 2.6-smp)
Your message dated Mon, 30 Jan 2006 22:15:29 +0100 with message-id [EMAIL PROTECTED] and subject line Bug#295657: EXT3 on RAID problems in all 2.6-smp has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 17 Feb 2005 09:20:25 + From [EMAIL PROTECTED] Thu Feb 17 01:20:25 2005 Return-path: [EMAIL PROTECTED] Received: from smtp-vbr12.xs4all.nl [194.109.24.32] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1D1hpg-00033e-00; Thu, 17 Feb 2005 01:20:24 -0800 Received: from smtp.dizzl.com (gateway.dizzl.com [213.84.228.80]) by smtp-vbr12.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1H9KMmI033773 for [EMAIL PROTECTED]; Thu, 17 Feb 2005 10:20:22 +0100 (CET) (envelope-from [EMAIL PROTECTED]) Received: from newton.dizzl.com (newton.dizzl.com [10.1.1.64]) by smtp.dizzl.com (Postfix) with ESMTP id 663D984B8 for [EMAIL PROTECTED]; Thu, 17 Feb 2005 10:20:21 +0100 (CET) From: Jeroen van Disseldorp [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: EXT3 on RAID problems in all 2.6-smp Date: Thu, 17 Feb 2005 10:20:41 +0100 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Message-Id: [EMAIL PROTECTED] X-UID: 7 X-Length: 30732 Content-Type: Multipart/Mixed; boundary=Boundary-00=_pHGFCuBZkbC7biy X-Virus-Scanned: by XS4ALL Virus Scanner Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-5.0 required=4.0 tests=HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: --Boundary-00=_pHGFCuBZkbC7biy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Package: kernel-image-2.6.10-1-686-smp Version: 2.6.10-4 Severity: critical 2 months ago I bought 4 new hard drives, which I configured as follows: - | Linux | Swap | RAIDSET-1 disk 1 | - | RAIDSET-0 disk 1 | RAIDSET-1 disk 2 | - | RAIDSET-0 disk 2 | RAIDSET-1 disk 3 | - | RAIDSET-0 disk 3 | RAIDSET-1 disk 4 | - RAIDSET-0 is 20G, RAIDSET-1 is 709G. On top of both raid devices I use the device mapper to encrypt those disks, so data travels to the disk through the following layers: vfs - ext3 - device mapper - raid - physical disks Since the beginning I have been having problems with heavy disk usage on RAIDSET-1. It seems that under normal circumstances the system is stable, but under heavy load the following error occurs: Feb 12 06:27:25 einstein kernel: EXT3-fs error (device dm-2): ext3_readdir: bad entry in directory #84509561: rec_len %% 4 != 0 - offset=0, inode=1629516644, rec_len=29795, name_len=117 Feb 12 06:27:25 einstein kernel: Aborting journal on device dm-2. Feb 12 06:27:25 einstein kernel: ext3_abort called. Feb 12 06:27:25 einstein kernel: EXT3-fs abort (device dm-2): ext3_journal_start: Detected aborted journal Feb 12 06:27:25 einstein kernel: Remounting filesystem read-only As I do some spam-learning and backups at night, requiring some heavy disk use, this happens just about every day. Running fsck after the error is useless, as it finds no errors at all. So there is little else to do then remount and hope for the best for another day. My system is a dual Pentium II 400MHz with 384MB memory. All four disks are Hitachi/IBM Deskstar 250G. The problem occurs with every 2.6 kernel I have tried so far, starting from 2.6.7. Typical thing is that it only seems to occur on -smp kernels. I've been running some UP-kernels as well and (although slower) they do not thrash the ext3 journal. Could this be an SMP race? More system information can be found in the attached kern.log. Regards, Jeroen --Boundary-00=_pHGFCuBZkbC7biy Content-Type: text/x-log; charset=us-ascii; name=kern.log Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=kern.log Feb 12 12:09:48 einstein kernel: klogd 1.4.1#16, log source = /proc/kmsg started. Feb 12 12:09:48 einstein kernel: Inspecting /boot/System.map-2.6.7-1-686-smp Feb 12 12:09:49
Re: Kernel 2.4 for etch or not
Hi Holger, thanks for raising this important issue and sorry for being slow to reply. I think that I agree with pretty much everything you wrote, so I won't reiterate that here. However, I'd like to take the opportunity to clarify my position with regards to 2.4 in Etch. When I first became involved with debian-kernel, leading up to Sarge, my main interest was in making sure that 2.4 was in good shape. This is because at that time I felt that there was a very strong audience for it, and that it was essential for Sarge's success. As many people had already shifted their focus to 2.6 I felt there was a bit of a vacuum, and I was happy to fill it. However, leading up to Etch, as we now are, I really feel that for the various reasons you listed, the support burden of 2.4 in Etch is heavier than its benefit. So, except for architectures that absolutely must have it, we should drop 2.4. I believe 2.2 was in Sarge for some architectures, and probably will also have it for Etch. So this idea is by no means new. To be quite honest, when people like Ted T'so advise me that 2.4 isn't really viable for Etch, I tend to take notice. If, the release maintainers decide that we really must keep 2.4, then moving forward to 2.4.3X with the new unified packaging that is seen in current linux-2.6 packages is the next best option. Holger, I guess that responsibility would fall on your shoulders for now, as I unfortunately do not have the time to devote to it. Hopefully some more volunteers can be found. Failing that, keep updating 2.4.27, as we already are for Sarge security, and include that. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 for etch or not
On the topic of Security fixes and 2.4's upstream. Dann, myself, and all others involved endeavour to push any patches we find that are missing from upstream to the relevant parties. This includes 2.4 and 2.6, security and non-security patches. Marcelo has specifically asked vendors (and others) to keep doing this for 2.4. So if you have patches for critical bugs, please forward them on - he can decide to drop or keep them. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347412: Tried with just skge
Ok, I just tried with having only the 'skge' module loaded since boot. Once again, ethernet died. So, the summary is: 2.6.12, w/ sk98lin: Works 2.6.12 does not have skge. 2.6.15 w/ sk98lin skge (yes, you can load both[0]): Fails 2.6.15 w/ sk98lin: Fails 2.6.15 w/ skge: Fails where fails means either the ethernet card stops working (silently, with no errors) or SATA fails (all I/O gives I/O errors --- quite a bit not silent, and loses data). [0] And at least the combination of udev and discover was doing so until I stopped it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
