Kernel Traffic #242 by Zack Brown
[email protected] Mon, 24 Nov 2003 09:39:31 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <E1AOKgN-0001mm-00@renegade> |
Kernel Traffic #242 For 24 Nov
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 3 Nov - 17 Nov (132 Status Of IDE-SCSI Maintainance
posts)
2. 6 Nov - 19 Nov (122 kernel.bkbits.net Down For Security Reasons;
posts) arch Proposed As BitKeeper Alternative
3. 10 Nov - 14 Nov (26 Maximum Partition Sizes Under 2.4 And 2.5
posts)
4. 14 Nov (1 LKST v2.0.0 Released For 2.6.0-test9
post)
5. 16 Nov - 17 Nov (3 Status Of SCSI Drivers
posts)
6. 16 Nov - 18 Nov (4 Version 0.17 Of Forcedeth Released
posts)
7. 18 Nov (2 Trouble Bringing The BK-CVS Gateway Back
posts) Online
8. 18 Nov - 19 Nov (2 Status Of e-Galax USB Touchscreen Support In
posts) 2.4
9. 19 Nov (4 Status Of Experimental Net Driver Updates
posts)
10. 19 Nov (1 BK->CVS Gateway Back Online
post)
11. 19 Nov (1 Some ACPI Bug Fixes For 2.6
post)
12. 19 Nov (1 Version 0.18 Of Forcedeth Released
post)
Mailing List Stats For This Week
We looked at 1076 posts in 4864K.
There were 357 different contributors. 168 posted more than once. 131 posted
last week too.
The top posters of the week were:
* 31 posts in 192K by "Prakash K. Cheemplavam"
* 31 posts in 87K by Linus Torvalds
* 29 posts in 106K by Jens Axboe
* 24 posts in 66K by Davide Libenzi
* 23 posts in 231K by Jeff Garzik
* Full Stats
1. Status Of IDE-SCSI Maintainance
3 Nov - 17 Nov (132 posts) Subject: "2.9test9-mm1 and DAO ATAPI cd-burning
corrupt"
Topics: Disks: IDE, Disks: SCSI, Ioctls, Serial ATA
People: Prakash K. Cheemplavam, Bill Davidsen, Linus Torvalds, John Bradford
Prakash K. Cheemplavam reported, "I am using k3b0.10.1 and either choosing
cdrdao or cdrecord in DAO mode to burn the cd ends up in non-bit identical
copies, wheres ion TAO (atleast with my 10x CD-RW I tested) the copy succeded."
Later he added that the data was not actually corrupted, "but in a way
truncated in DAO mode: When I read out the image from the CD-RW drive, about
5kbyte are missing at the end (and doing several burn, it is always the same
amount). Strange enough if I read the DAO burnt disk out by my DVD-ROM, the
image can be read out completely!" A couple posts later, he clarified, "The
data is on the disc, as my DVD-ROM restores the full image (md5sum matches),
but the CD-RW does not." Bill Davidsen replied, "There is a problem with
ide-scsi in 2.6, and rather than fix it someone came up with a patch to
cdrecord to allow that application to work properly, and perhaps "better" in
some way. Since the problem with ide-scsi seems to still exist for other
applications, you will probably find you have to work around the problem, by
using the -pad option of cdrecord (thought that was standard now for TAO at
least) or reading using the ide-cd driver." And Linus Torvalds replied:
Wrong.
The "somebody" strongly felt that ide-scsi was not just ugly but _evil_,
and that the syntax and usage of "cdrecord" was absolutely stupid.
That somebody was me.
ide-scsi has always been broken. You should not use it, and indeed there
was never any good reason for it existing AT ALL. But because of a broken
interface to cdrecord, cdrecord historically only wanted to touch SCSI
devices. Ergo, a silly emulation layer that wasn't really worth it.
The fact that nobody has bothered to fix ide-scsi seems to be a result of
nobody _wanting_ to really fix it.
So don't use it. Or if you do use it, send the fixes over.
John Bradford said:
Hmmm, but ide-scsi is used for a lot more than cd recorders these days.
Alan mentioned 'crazy' SATA devices back in April.
http://marc.theaimsgroup.com/?l=linux-kernel&m=105000779411632&w=2
(Not that I'm suggesting that it is particularly sane to deal with an SATA
connected printer by presenting it as a SCSI device, but I just can't see
how ide-scsi could successfully be removed now :-( )
And Bill replied, "And I don't see the joy of doing so. Unless someone wants to
write new versions of all the SCSI software out in use, a lot of functionality
is lost. In the long run it might have been better to simply fix or rewrite
ide-scsi and stop using the ide interface, becuase disk manufacturers certainly
aren't going to stop making scsi and it needs to be supported anyway. I guess
Doug Gilbert is doing other things now, I would have expected at least an
opinion out of him ;-)" He also said, "I mentioned ide tapes and ZIP drives,
Linus didn't mention how one gets around those." To which Linus replied:
The thing is, the non-ide-scsi interfaces really _should_ work. The fact
is, SG_IO ("send a SCSI command") just _works_.
However, right now only the CD-ROM driver exposes those commands. Why?
Because nobody has apparently cared enough about those theoretical IDE
tapes and ZIP drives.
In other words, they seem to "exist" in the same sense that soubdblaster
CD-ROM users "exist". True in theory, but apparently only really useful for
theoretical arguments.
Getting SCSI command support is not complicated: you add
ret = scsi_cmd_ioctl(dev, cmd, arg);
to your ioctl routine. Of course, since so far nobody seems to have cared
about anything but CD writing, it's not really tested for anything else.
Bill replied ryely:
I take it that if the IDE maintainer and you don't use a device it will not
be supported in the future? There's nothing theoretical about ZIP drives
and ATAPI tape drives, you can order them mail order or buy them at any
computer show. And 2.4 ide-scsi seems to support them perfectly, or at
least usefully, which is probably why there haven't been any complaints.
I admit I can't understand why 2.6 supports old NICs and motherboard
chipsets which haven't been made in five years, and then deliberately
desupports devices which did work and which are available at computer
stores and mail order today.
Linus said:
Those other devices have people MAINTAINING THEM AND CARING!
What's so horribly hard to understand about this? You're barking up the
wrong tree.
Again, I tell you once more:
+ for burning IDE CD-ROM's you should use the IDE driver. Not ide-scsi.
End of discussion. It's a supported and _improved_ situation from where
it was in 2.4.x.
+ For all those devices you claim exists, show me the patches. Nobody
broke ide-scsi on purpose - but the fact is that nobody also ever came
forward and _fixed_ it.
Get it now?
So come back to me when you find somebody who cares enough about the
devices you claim exists enough that he actually _does_ something about it.
Bill again insisted that there were lots of users using the hardware; and he
and Linus went back and forth, with Bill saying a strong user-base existed for
the hardware, and Linus saying that someone had to submit patches in order for
hardware to be supported. At one point Linus shouted:
NOBODY IS SENDING ME PATCHES.
What part of "open source" do you not understand?
SATA devices work fine. They have all the SCSI infrastructure working for
them. They'll "just work", even though I fervently hope that we can move
them over to the block device layer later to make them work more
efficiently.
As per the MO device that wants ide-scsi, send out patches to the kernel
mailing list, and maybe the person can test it. I certainly can't test it.
My point is that YOU ARE BARKING UP THE WRONG TREE. It does not help to
complain to me - since I don't even have the hardware to test anything
with. I fixed the IDE CD burning issue. That I had hardware for, and knew
how to fix properly.
Now it's your turn. Instead of wasting my time complaining, how about you
put up or shut up? Show me the code. THEN post it. Until you do, there's no
point to your mails.
They did not reach agreement during the thread.
2. kernel.bkbits.net Down For Security Reasons; arch Proposed As BitKeeper
Alternative
6 Nov - 19 Nov (122 posts) Subject: "kernel.bkbits.net off the air"
Topics: BSD, Version Control
People: Larry McVoy, H. Peter Anvin, Andrew Walrond, Andrea Arcangeli, Samium
Gromoff, Davide Libenzi, Larry McVoy , Jan Harkes, Zack Brown, Tom Lord
Larry McVoy reported:
As many of you have figured out, I took kernel.bkbits.net (aka
bk.kernel.org, cvs.kernel.org, and svn.kernel.org) of the air yesterday due
to the breakin that attempted to add a trojan horse to the kernel source.
I took it down after talking with Linus and Dave about it, the point was to
shut down the disk drive so that we can go do forensics on it after the
fact and see what we can figure out. Maybe someone can track down who
caused the problem.
This means someone has to go down to the colo with a new disk and do an
install and we've been too busy to do this. Would anyone object if this
wasn't done until this weekend? We're pretty booked up here with other
work. Last I checked only about 6 IP addresses where using the CVS server,
I've never checked on the SVN server (Ben? You have any idea?).
H. Peter Anvin put in, "That doesn't include anyone who uses the mirrored
repository on the main kernel.org machines. Doubt it's a big deal with the
timing, though." And Larry replied, "Last I checked, kernel.org isn't offering
pserver access, just ftp. If you want to take over the CVS access just say the
word." H. Peter said, "No, we don't do the pserver access, but some people get
the whole repository through the mirror. The current division seems to work
well, so I don't see any reason to change it." Close by, Davide Libenzi
mentioned that rsync was actually better than straight CVS for synchronization,
and Larry said, "If that's the preferred interface then maybe we should shut
down the pserver completely and let people rsync it from kernel.org." But
Davide said he couldn't speak for everyone, and that some folks might prefer
accessing the tree directly through CVS.
Elsewhere, in the course of discussion, Andrew Walrond suggested, "Persuade
Larry to release a 'clone/pull-only' version of bk which *anyone* can use to
access open source software" and Larry said, "I'd be far more likely to build a
sort of CVS like client that could do checkouts and updates of read only files.
That's a pretty straightforward thing to do, in fact, nobody needs BK source to
do that, it could all be done as wrappers pretty trivially. If someone wanted
to code that up and make the code available under a BSD license we'd take a
good look at adding that into the BK server side. It doesn't need to be bundled
in BK however. Anyone could write a daemon that locally called BK to get the
data and a client that talked to the daemon. The hard part is renames but even
that can be handled reasonably easily."
At this point Andrea Arcangeli suggested that the arch (http://gnuarch.org/bin/
view) revision control system was up to the task of hosting Linux kernel
development, "but we need to checkout a coherent cvs to import the data into
arch." Samium Gromoff replied:
i propose to go further than that.
I hope that Larry recognises that at some point the linux kernel community
_will_ switch to a free software alternative.
I think we should have a better choice than the lossy bk->cvs.
I propose we as a whole ask Larry to create a bk->arch gateway _not_ via
cvs but directly, and therefore using all the extended metadata possible.
+ this way we`ll get whole-tree changesets, file renames etc.
+ this way Larry will have a terrific argument to shut whiners.
The choice of Arch is not random, but motivated by my belief in that it is
the leading Free Software revision control effort.
If Larry wishes to give a birth to this idea, the list to contact is:
[email protected]
Jan Harkes, an arch user, pointed out that there would be significant pain
involved in any transition from BitKeeper to another tool; also, he felt that
arch was not yet ready to scale to the size of the kernel project. Finally, he
thought it was absurd to ask for Larry's help in migrating away from Larry's
own product. Samius said that his suggestion was only that Larry provide a
better gateway than CVS, not that Larry help the kernel developers switch away
from BitKeeper.
(ed. [Zack Brown] Having used arch and read its mailing list for many months, I
can say that arch has come a long, long way. It is fast, robust, and capable of
hosting very large projects; and in my opinion represents a great leap forward
in revision control systems. If it is not yet up to the scale of the Linux
kernel, it is still easily up to many of the large projects out there. Its only
major drawback is that Tom Lord, the maintainer, is extremely unreceptive to
newcomers, and tends to flame beginners after an initial pretense of
politeness. You heard it here first. I recommend that folks definitely try arch
for their projects, but read and learn all the available documentation before
asking anything on the mailing list.)
3. Maximum Partition Sizes Under 2.4 And 2.5
10 Nov - 14 Nov (26 posts) Subject: "2 TB partition support"
Topics: Disk Arrays: LVM, FS: JFS, FS: ReiserFS, FS: XFS, FS: ext2
People: Peter Chubb, Randy Dunlap, Mike Fedyk
Joseph Shamash asked if it were possible (and if so, how) to create a 2
terabyte partition under Linux. Peter Chubb replied:
Yes you can do it.
You need a 2.6 kernel. And it's best to use something other than the MSDOS
partition format --- I suggest you use parted to create a GPT partition
table (which means compiling your kernel to understand that format).
You didn't say what architecture you're running on. If it's a 64-bit system
you don't have to do anything else. If it's a 32-bit system, then turn on
CONFIG_LBD when you compile.
Joseph also asked the maximum parition size under the 2.4 kernel; Mike Fedyk
replied that he believed the maximu was 16 terabytes per block device, under
either 2.6 or a patched 2.4 kernel. But Peter said:
That's right for 32-bit systems with 4k pages. For 64 bit systems the limit
is over 8 Exabytes.
You should note that software raid has smaller limits, as does the LVM.
Also the 2.4 patches have seen *much* less testing than the 2.6 mainline
(except possibly on the SGI Altix).
Randy Dunlap also said:
I made the table below for LinuxWorld Expo/Conference in Aug. 2002, for
Linux 2.4.x on 32-bit architectures, so it is a bit out of date, but it
might be helpful or useful.
Linux 2.4 filesystem limits on 32-bit architectures, with 4 KB block sizes:
ext2/3fs reiserfs JFS XFS#
max filesize: 4 TB& 16 TB$ 16 TB$% 16 TB$
max filesystem size: 16 TB& 16 TB& 16 TB$ 16 TB$
4 PB& 8 EB&
kernel bldev limit: 2 TB 2 TB 2 TB 2 TB
Notes:
#: all kernel limits
$: kernel limit
%: 4 KB pages
@: block device limit: 2 TB (or 1 TB if signed)
&: fs limit
4. LKST v2.0.0 Released For 2.6.0-test9
14 Nov (1 post) Subject: "LKST v2.0.0 is released (Kernel v2.6.0-test9)"
People: Yumiko Sugita
Yumiko Sugita announced:
I'd like to announce publication of Linux Kernel State Tracer (LKST)
version 2.0.0, which is a tracer for Linux kernel. LKST is a useful tool
for analyzing Kernel fault and evaluating of Kernel.
LKST v2.0.0 is for Kernel version 2.6.0-test9(*). And platforms of LKST
2.0.0 are both IA32 and IA64. The details are described in
changes-2.0.0.txt.
LKST v2.0.0 is also for Kernel version 2.6.0-test8. After you executed LKST
patches, please change EXTRAVERSION value in Makefile of Kernel to
test8-lkst.
Remarks:
for supporting IA64, we changed some codes in the following programs.
o KernelHooks
LKST binaries, source code and documents are available in the following
site,
http://sourceforge.net/projects/lkst/
http://sourceforge.jp/projects/lkst/
We prepared a mailing list written below in order to let users know update
of LKST.
[email protected]
[email protected]
To subscribe, please refer following URL,
http://lists.sourceforge.net/lists/listinfo/lkst-users
http://lists.sourceforge.jp/mailman/listinfo/lkst-users
And if you have any comments, please send to the above list, or to another
mailing-list written below.
[email protected]
[email protected]
5. Status Of SCSI Drivers
16 Nov - 17 Nov (3 posts) Subject: "[summary] state of scsi drivers"
Topics: BSD: FreeBSD, Big Memory Support, Disk Arrays: RAID, Disks: SCSI,
Hot-Plugging
People: Xose Vazquez Perez, Meelis Roos
Xose Vazquez Perez posted:
* unofficial LiNUX kernel SCSI/RAID drivers list *
<[email protected]>
linux-2.4.23-rc1
Sun Nov 16 17:38:00 CET 2003
x features:
hot-plug vary_io highmem_io block_device_driver 64_bit_SG
o aacraid
manufacturer: ADAPTEC
kernel: 1.1.2 (15 May 2003)
latest: 1.1.4 (31 Oct 2003)
arch: i386 ia64 x86_64(amd64) alpha (sparc not confirmed, but expected)
features: highmem_io 64_bit_SG
maintainer: <Mark_Salyzyn*AT*adaptec.com> <markh*AT*osdl.org>
<aacraid*AT*adaptec.com> <linux-aacraid-devel*AT*dell.com>
url: http://linux.adaptec.com
http://www.domsch.com/linux/#aacraid
o aic7xxx/aic79xx
manufacturer: ADAPTEC
kernel: 6.2.36/1.3.10 (03 Jun 2003)
latest: 6.3.3 /2.0.4 (06 Nov 2003)
arch: i386 ia64 powerpc
features:
maintainer: <gibbs*AT*scsiguy.com>
url: http://people.freebsd.org/~gibbs/linux/SRC/
o cciss
manufacturer: HP
kernel: 2.4.50
latest: 2.4.50
arch: i386
features: block_device_driver
maintainer: <mike.miller*AT*hp.com> <arrays*AT*hp.com>
<Cciss-discuss*AT*lists.sourceforge.net>
url: http://sf.net/projects/cciss/
o DAC960
manufacturer: LSI Logic
kernel: 2.4.11 (11 Oct 2001)
latest: 2.4.20 (01 May 2003)
arch: i386 ia64 alpha
features: block_device_driver
maintainer: <dmo*AT*osdl.org>
url: http://www.osdl.org/archive/dmo/DAC960/
http://www.dandelion.com/Linux/DAC960.html
o dpt_i2o
manufacturer: ADAPTEC
kernel: 2.4.5 (25 Jul 2001)
latest: 2.5.0 (11 Sep 2003)
arch: i386 ia64 alpha sparc x86_64(amd64)
features: highmem_io 64_bit_SG
maintainer: <Mark_Salyzyn*AT*adaptec.com>
url: http://linux.adaptec.com
o emulex
manufacturer: EMULEX
kernel: -
latest: 1.23a
arch: i386 ia64 ppc
features:
maintainer: <tech.support*AT*emulex.com>
url: http://www.emulex.com/ts/docfc/linuxos.shtml
o feral_isp
manufacturer: QLOGIC
kernel: -
latest: Linux Platform 2.1 Common Core Code 2.7 (13 Nov 2003)
arch: i386 alpha sparc powerpc
features: alternative driver for all qlogic products
maintainer: <mjacob*AT*feral.com>
url: http://www.feral.com/isp.html
o fusion
manufacturer: LSI Logic
kernel: 2.05.05+ (14 Apr 2003)
latest: 2.05.10 (10 Oct 2003)
arch: i386 alpha sparc ia64 x86_64
features:
maintainer: <emoore*AT*lsil.com> <mpt_linux_developer*AT*lsil.com>
url: ftp://ftp.lsil.com/HostAdapterDrivers/linux/
o gdth
manufacturer: ADAPTEC
kernel: 2.05 (03 Oct 2002)
latest: 2.06a (04 Aug 2003)
arch: i386 alpha ia64
features:
maintainer: <achim.leubner*AT*intel.com>
<johannes_dinner*AT*adaptec.com>
url: http://www.icp-vortex.com/english/download/rz_neu/8x24/linux/
linux_e.htm
o ips
manufacturer: ADAPTEC
kernel: 6.00.26
latest: 6.00.26
arch: i386 ia64
features:
maintainer: <david_jeffery*AT*adaptec.com> <ipslinux*AT*adaptec.com>
url: -
o megaraid
manufacturer: LSI Logic
kernel: v1.18k/v2.00.9
latest: v1.18k/v2.00.9
arch: i386
features:
maintainer: <atulm*AT*lsil.com> <linux-megaraid-devel*AT*dell.com>
url: ftp://ftp.lsil.com/pub/linux-megaraid/
http://domsch.com/linux/#megaraid
o qla1280
manufacturer: QLOGIC
kernel: 3.23.37
latest: 3.23.37
arch: i386 alpha powerpc sparc
features:
maintainer: <jes*AT*wildopensource.com>
url: -
o qla2x00
manufacturer: QLOGIC
kernel: -
latest: 6.06.10
beta: 8.00.00b6
arch: i386
features:
maintainer: <andrew.vasquez*AT*qlogic.com>
url: http://www.qlogic.com/support/product_resources.asp?id=339
http://sf.net/projects/linux-qla2xxx/
o sym53c8xx_2
manufacturer: LSI Logic
kernel: 2.1.17a (Dec 01 2001)
latest: 2.1.19-pre3 (Nov 23 2002)
arch: i386 alpha sparc powerpc ia64
features:
maintainer: <groudier*AT*free.fr>
url: http://www.tux.org/pub/tux/roudier/drivers/linux/stable/
Regarding the qla1280, Meelis Roos remarked, "qla1280 doesn't work on sparc
(neither 2.4 nor 2.6) since it uses flush_cache_all symbol from MM internals
and there's no such internal function on sparc."
6. Version 0.17 Of Forcedeth Released
16 Nov - 18 Nov (4 posts) Subject: "forcedeth: version 0.17 available"
Topics: FS: sysfs
People: Carl-Daniel Hailfinger
Carl-Daniel Hailfinger announced:
version 0.17 of forcedeth for Linux 2.4 and 2.6 is available at http://
www.hailfinger.org/carldani/linux/patches/forcedeth/
Fixes in this release over 0.14:
+ 0.15: 08 Nov 2003: fix smp deadlock with set_multicast_list during
open.
+ 0.16: 15 Nov 2003: include file cleanup for ppc64, rx buffer size
increased to 1628 bytes.
+ 0.17: 16 Nov 2003: undo rx buffer size increase. Substract 1 from the
tx length.
Known issues:
+ Oops during module removal, probably sysfs related. Could a sysfs
expert please take a look at the code? Call trace is at http://
www.ussg.iu.edu/hypermail/linux/kernel/0311.1/0213.html More traces
(roughly the same) available on request.
+ Some boards give bogus MAC addresses and work only partially. Same
problem happens with nvnet on these boards.
+ Transmit for packets close to MTU size was broken, should be fixed now.
Please test.
7. Trouble Bringing The BK-CVS Gateway Back Online
18 Nov (2 posts) Subject: "bkcvs at rsync.kernel.org not up-to-date?"
Topics: Version Control
People: Pavel Machek, Larry McVoy, Larry McVoy
Pavel Machek asked, "Web interface indicates last change 22 hours ago, yet
rsync indicates nothing new. I know that bkcvs was supposed to be down over
weekend, but I thought it should be up by now?" Larry McVoy replied:
It's still down. The machine got moved from one colo to another and when we
went down there to find it it was nowhere to be found. So they are tracking
it down and we'll try and get it up tomorrow.
I've offered to update the rsync tree on kernel.org directly if HPA figures
out how to turn on my account (something I've been waiting on for at least
a year, hint, hint).
8. Status Of e-Galax USB Touchscreen Support In 2.4
18 Nov - 19 Nov (2 posts) Subject: "e-Galax USB touchscreens and 2.4"
Topics: USB
People: Jakub Bogusz, James Lamanna
James Lamanna asked if e-Galax USB touchscreens worked under Linux 2.4; the
module on the company web site seemed broken. Jakub Bogusz replied, "I had a
terminal with eGalax touchscreen for tests some time ago and it worked. But for
new USB core (Linux 2.4.20+) it required a patch (unpatched driver worked on
2.4.18 but caused Oops on 2.4.20): http://cvs.pld-linux.org/SOURCES/
touchkit-2.4.20.patch. (yes, it uses old GNU-style initializers, now I would
use C99-style)"
9. Status Of Experimental Net Driver Updates
19 Nov (4 posts) Subject: "[CFT] 2.6.x experimental net driver updates"
People: Jeff Garzik, Alexander Viro
Jeff Garzik announced:
Ok, Al Viro's net driver refcounting work is pretty much complete, and
shemminger/ogawa NAPI conversation of 8139too is also merged.
Please beat this up as much as possible. Don't let the "experimental" tag
fool you... these changes should be solid, and will be going to Andrew/
Linus when the 2.6.0 tree re-opens.
Don't forget to CC [email protected] on all feedback.
Alexander Viro replied, "The hell it is" [complete]. He went on:
We are through with legacy probes, we are through with init_etherdev(), we
are practically through with static struct net_device.
However, we still have weird allocators (I've got almost all of them done
by now, will submit in the next batch) and we still have struct net_device
embedded as a field of other structures in several drivers.
It's nowhere near as massive as legacy probes series, but it's going to be
10--20 patches. At least.
10. BK->CVS Gateway Back Online
19 Nov (1 post) Subject: "BK2CVS tree is back"
Topics: Version Control
People: Larry McVoy, Larry McVoy
Larry McVoy announced, "I just updated the copy on master.kernel.org and I'll
be updating that directly from now, nightly, at about 3am PST. It will probably
take a couple of days before I have the bugs worked out but there is a fresh up
to date copy there now. Thanks to HPA for fixing my account and other admin
help."
11. Some ACPI Bug Fixes For 2.6
19 Nov (1 post) Subject: "[BKPATCH] ACPI 2.6"
Topics: Power Management: ACPI
People: Len Brown
Len Brown said:
Linus, please do a
bk pull http://linux-acpi.bkbits.net/linux-acpi-release-2.6.0
The world will not stop revolving if these wait till 2.6.1, but it will
make 2.6.0 easier to support if they're included.
3 bug fixes -- all are in 2.4:
+ 1390: adds cmdline to allow manual over-ride if out policy of forcing
the ACPI SCI to level triggered is wrong.
If we don't apply, some folks with no ACPI events will need to patch.
+ 1177: makes print_IO_APIC() output useful instead of garbage.
If we don't apply, then we need to send this patch to anybody who has
an IO-APIC mode interrupt issue in ACPI mode.
+ 1434: 1-line panic fix
BIOS with correct ACPI table check-sums but garbled data can cause
panic immediately after loading with no kernel output unless this is
fixed.
a plain patch is also available here: ftp://ftp.kernel.org/pub/linux/kernel
/people/lenb/acpi/patches/release/2.6.0-test9/
acpi-20031002-2.6.0-test9.diff.gz
12. Version 0.18 Of Forcedeth Released
19 Nov (1 post) Subject: "forcedeth: version 0.18 available"
People: Carl-Daniel Hailfinger
Carl-Daniel Hailfinger announced:
version 0.18 of forcedeth for Linux 2.4 and 2.6 is available at http://
www.hailfinger.org/carldani/linux/patches/forcedeth/ It is also integrated
in 2.6.0-test9-mm4.
Fixes in this release over 0.17:
+ Avoid Oops on rmmod.
Known issues:
+ Some boards give bogus MAC addresses and work only partially. Same
problem happens with nvnet on these boards.
+ Possible system slowdown during periods of extreme network load, fix is
currently being tested.
Please test.
We Hope You Enjoy Kernel Traffic
Kernel Traffic is hosted by the generous folks at Tux.Org. All pages on this
site are copyright their original authors, and distributed under the terms of
the GNU General Public License, version 2.0.