Kernel Traffic #251 For 9�Feb�2004

There were 685 different contributors. 355 posted more than once. 279 posted last week too.

Gerd Knorr said, "This patch adds a module with some helper functions to handle infrared remotes using the linux input layer. It doesn't do any useful stuff alone, but the saa7134 and bttv drivers will use that to support the remotes shipped with some TV cards." Rusty Russell suggested updating the code to use the new module_param() code from 2.6, but Gerd said, "No. The code in question must also build on 2.4 kernels which don't have module_param(). And I don't want to clutter up the code with #ifdefs unless I absolutely have to. I'll do for the bttv ir support, that is 2.6 only anyway due to the usage of tasklets." Rusty said this would be fine, and that "I'll write and test the forward compat macros for 2.4, submit them to Marcelo, and then bother you again 8)" . He posted the compatibility patch a couple of hours later, adding, "It doesn't do arrays or strings, but they can be added if required." Gerd said array support would be in his module code, so it would be useful to have it in 2.4 as well. Rusty was reluctant, and they took the discussion off-line.

Pat Gefre posted his latest set of Altix patches for 2.6, and Andrew Morton replied, "I'll assume these are for review at this time. When that is complete, please send them over, one changelog+patch per email in the time-honoured manner, thanks." Meanwhile, Pat and Christoph Hellw went back and forth on technical problems for awhile.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/

There's a patch here which changes the ia32 CPU type selection. Make sure you go in there and select the right CPU type(s), else the kernel won't compile. We might need to set a default here.
Kernel NFS server update
MD update
V4L update
A string of fixes against the parport, paride and associated drivers
Update to the latest UML
Patches to support gcc-3.4 on ia32. There is more to do here - more warnings need to be fixed and the exception tables need to be sorted. I didn't add the `-Winline' patch because it's way too noisy at present.

Prakash K. Cheemplavam reported lockups, which he'd had with earlier kernels as well. Valdis Kletnieks suggested, "If this is the NVidia graphics driver, it's been doing it at least since 2.5.6something, at least that I've seen. It's basically calling pci_find_slot in an interrupt context, which ends up calling pci_find_subsys which complains about it. One possible solution would be for the code to be changed to call pci_find_slot during module initialization and save the return value, and use that instead. Yes, I know this prevents hotplugging. Who hotplugs graphics cards? ;)"

KGDB 2.0.3 is available at http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

It panics and enter kgdb_handle_exception recursively and silently. To see the panic on screen make kgdb_handle_exception return immediately if kgdb_connected is non-zero.

Panic trace is pasted below. It panics in skb_release_data. Looks like skb handling will have to changed to be have kgdb specific buffers.

Andi Kleen asked if Amit had used some recent netpoll patches, and Amit replied, "I am not using netpoll (yet). My patch doesn't require any driver modifications, that the mm ethernet patch required." Pavel Machek asked if this meant Amit would eventually use netpoll, and Amit replied, "I don't know yet. I don't like the idea of a debugger using a lot of kernel code. I am trying to implement kgdboe without netpoll and without making changes to ethernet drivers. Perhaps I'll have to use netpoll eventually!" Close by, Matt Mackall remarked, "I went the no-modified-drivers route originally and a long discussion with Jeff Garzik eventually convinced me of the error of my ways. There are a bunch of paths that are racy if you try to make a generic poll function."

Someone was having trouble porting their C++ module from the 2.4 kernel into 2.6, and Richard B. Johnson said, "There is no C++ runtime support in the kernel for C++. Are you sure this is a module and not an application? Many network processes (daemons) are applications and they don't require any knowledge of kernel internals except what's provided by the normal C/C++ include-files." Bart Samwel confirmed that this was indeed a module, adding, "It includes a kernel patch that makes it possible to include a lot of the kernel headers into C++, stuff like changing asm :: to asm : : (note the space, :: is an operator in C++) and renaming "struct namespace" to something containing less C++ keywords. The module also includes rudimentary C++ runtime support code, so that the C++ code will run inside the kernel. I'm afraid that the task of compiling it for 2.6 is going to be pretty tough -- the kernel needs loads of patches to make it work within a C++ extern "C" clause, and it probably completely different patches from those needed by 2.4. Getting the build system to work is the least of the concerns." Richard thought the whole exercise was a waste of time, and that C++ had no place in the kernel. "Next thing it'll be Visual BASIC, then Java," he said.

Bart replied (disclaiming involvement with the module in question), explaining that the code had originally been in C++, encompassing hundreds of files; and that the work of porting all that to C for Linux, was comparable to the work of modifying the kernel to accept a C++ module. He went on, "I expect that they decided to do C++ because the model they try to express is best modeled using C++. This design decision can be debated, because it is perfectly feasible (albeit with a lot more work) to implement an OO model in C. In fact, I have helped to implement a similar framework (the OKE CORRAL) which was written completely in C. But, the fact of the matter is, this useful (but huge) kernel module is there now (and it has been here since the early 2.2 kernels), and it was not written just to "prove" that it could be done, but because C++ seemed at the time to be the best language for the job. The start of this project may very well predate the many times that this was hashed-over on the LKML."

Later, Bart said that the module authors "have never asked the kernel developers to change. They've simply taken a language with an excellent C interoperability layer, which can compile to object code that contains only exported symbols with C-linkage, and they have restricted themselves to a subset of that language that doesn't break the C code they're interoperating with. This has become possible only because of the freeness of the kernel (which is encoded in the license and further enforced by things like EXPORT_SYMBOL_GPL), which allowed them to modify the kernel headers in order to get it to compile in an extern "C" clause in C++. They've maintained this patch since 2.2, and I don't expect this to change. I've even heard I don't think _they_ expect this to change, as they probably know all too well about the political climate within the kernel developers' scene. However, as long as the kernel keeps using C as it's language, keeps being GPL'ed, and keeps exporting a module interface that is defined by some prototypes in some C include files, I don't see how this could lead to any trouble for them. They can always maintain and distribute their patch (because of the freeness), they can always link in their C++ code as a module (because of the module layer) and they can always use the kernel's header files to import the module ABI for the current kernel (because they are C files, and because C++'s extern "C" will always be able to parse them -- except for some small fragments maybe, which might require a patch)."

in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:

the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is either

looking for problems
a C++ bigot that can't see what he is writing is really just C anyway
was given an assignment in CS class to do so.

In the course of discussion, Xose Vazquez Perez said that the aic7xxx driver in the kernel was lagging far behind the driver released by Adaptec. He added, "It looks like the _kernel_ driver is going to be without a maintainer unless somebody works on it, porting ADAPTEC fixes/features to the kernel driver." James Bottomley said, "this is *not* the way I see it. At the moment, Ataptec is the maintainer of that driver unless they choose formally to relinquish it." Justin T. Gibbs asked, "Can you provide your definition of "maintainer"? I know that I am maintainer of the drivers distributed from my website, but I don't feel I have ever been maintainer of the drivers in the 2.4.X, 2.5.X, or 2.6.X trees." James replied, "A maintainer is a person who works with the kernel community to keep the driver (or subsystem, filesystem or whatever) up to date. Such a person may or possibly may not have an entry in the MAINTAINERS file." Justin said, "Does the maintainer have the ability to veto changes that harm the code they maintain? In otherwords, you claim that I am the maintainer of the drivers in the kernel.org tree. This has not prevented changes from being made to these drivers without adequate review. Even your last update to the driver threw away all of the changelog state and left at least the aic79xx driver in a worse state than it was in before (see changelog entries for the driver versions after the one that you imported for details - this was exactly why I didn't submit that particular revision). You didn't even bother to ask me if importing 1.3.11 was appropriate. This is why I say I don't feel like a maintainer. I'm not given adequate control over the end product yet I'm supposed to take the blame when it doesn't work." Linus Torvalds replied that actually, nobody had the right to absolutely veto a code change. He went on:

Even _I_ don't veto changes that the right people push (my motto: "everybody is wrong sometimes: when enough people complain, even I am wrong").

In particular, maintainers of "conceptually higher" generally always have priority. If Al Viro says a filesystem is doing something wrong from a VFS standpoint, then that filesystem is broken - regardless of whether the filesystem maintainer agrees or not. Because the VFS layer requirements trump any low-level filesystem issues.

But perhaps more importantly (and it's the reason even _I_ don't have the right, regardless of how high up in the maintainership chain I am), nobody has veto-power over anything. That's to keep people honest: nobody should _ever_ think that they are "in control", and that nobody else can replace them.

In other words: maintainership is not ownership. It's a stewardship.

End result: maintainership is a nasty and mostly unthankful job. It doesn't really give many privileges, and most of what it does is just have people complain to you about bugs. The satisfaction is there, of course, but

And finally: maintainership is largely about working with people. There's some code in there too, but people tend to be more important.

James also replied to Justin, reiterating the point that maintainership was not the same as ownership, and saying, "It's not about control, it's about co-operation. The control you seek simply does not exist in the kernel development process." He also pointed out specifically, that Justin had invited him to integrate his patches whenever he pleased; and that James couldn't be held responsible for accepting that invitation. Justin replied, saying that he'd given James a lot of information to help decide which changes to integrate, and that James had ignored that data, causing harm to the driver. But the debate didn't go on very long, and petered out quickly without real resolution.

I've been using this since 2.4.22 and since laptop_mode is in the kernel since 2.4.23-pre<something> and I haven't seen that anyone else has implemented this so I decided to post it on the list in case anyone is interested.

It's a patch to modify the journal flush time of reiserfs to support laptop_mode (same functionality as ext3 has already).

Nikita Danilov replied, "Support for reiserfs laptop mode is in 2.6 now. It is done by adding new mount option "commit=N" that sets commit interval in seconds." Micha defended his approach, and a couple posts down the line Bart Samwel remarked, "You might want to take a look at Hugang's patch to support laptop mode on reiserfs in 2.6. This patch was posted somewhere last month. It adds a "commit=" option to reiserfs, so that you can change this externally by remounting. I think this solution is a lot cleaner than to have reiserfs code directly depend on laptop mode." He added, "If you decide to port that patch, you might want to look at the documentation for laptop mode in 2.6. The control script that's in there works for both 2.4 and 2.6, and it automatically remounts your ext3 and reiserfs filesystems with the appropriate commit options (and remounts them without the commit options when laptop mode is stopped). (There is also some ACPI event binding code in the documentation, which automatically enables laptop_mode when using battery power and disables it when your laptop is plugged in. I don't know if that works with 2.4 though.)" Nikita replied that Hu Gang's patch had already been merged into the main tree.

Witold Krecicki posted a patch to allow IDE to be built as a module in 2.6; Bartlomiej Zolnierkiewicz said Witold's solution would not cover every case, and offered his own patch instead, saying, "I've been working on it from some time and I think all cornercases are covered." Folks seemed to prefer Bartlomiej's driver, and went on to discuss various technical issues. In one subthread, it was made clear that the IDE module would not be unloadable once loaded.

Hu Gang said he was trying to port the software suspend feature to the PowerPC, but needed some help with the assembley code used in the function that saved process state. Nigel Cunningham replied that he wouldn't be much use with assembley, but that he'd help out with the other parts of the port, as Hu progressed.

A bunch of people started debating the difficulties of the code in question, and at some point Hu gave a link to some PPC documentation. At another point in the discussion, Benjamin Herrenschmidt said:

Ok, I hammered that for a day and got pmdisk (patrick's version) suspending and resuming on a pismo G3 (with XFree etc.. running). Lots of rough edges still (via-pmu sleep need to be improved, ADB need porting to the new driver model to be properly suspended/resumed, a sysdev for RTC is needed too for time, the asm code should be fixed for G5, etc...)

I had to fix some issues in the core pmdisk code though. One big one is that lots of drivers expect suspend to disk to be state 4 while the current code used state 3 for that (and suspend to RAM to be state 3 btw). I hacked that in include/linux/suspend.h, but we shall probably just get rid of those stupid numbers and properly define each constant indstead.

We should also use a different state for the suspend calls done before saving the image, and the ones done before resuming the image, some driver may be optimized for these cases.

The patch is against my tree currently, and the arch/ppc/kernel/pmdisk.S file is appended as-is (not in patch form). I don't plan to release that right now, I may hack a bit on it in the "background" (I want to get HIGHMEM working some day). Feel free to improve, but then keep me informed please.

Ah, also: The "Freeing memory" phase takes forever. That should really be fixed.

Hu confirmed that this worked on his laptop as well, as did Guido Guenther; and the discussion continued. Several folks replied privately to Benjamin with crash reports, "mostly lockups right after printing the number of pages to save," and he confirmed that he'd made his system lock up under similar conditions as well. He added, "Also, at least on pmac laptops, the HD is usually so fast, that I suspect spending 10 seconds freeing things is less efficient than spending this 10 seconds writing 200Mb of data to disk :) Also, one wakup, it's quite painful to see everything be swapped in again. It may make sense to be less agressive on the memory freeing, though finding a good balance isn't easy." The discussion continued, and Hu soon posted a swsusp2 update of his own, saying it seemed to work fine. Nigel was happy to see this, and said he'd add this to the main software suspend code, though marked as experimental for the moment. There were some comments about the patch's organization, and the thread petered out.

Andries Brouwer posted a patch to fix an ide-scsi crash bug he'd noticed, and Pascal Schmidt said, "I can confirm that it also makes my MO drive work with ide-scsi. I could also successfully write 4.1 GB of data to a DVD+RW disc. Writing 700 MB to a normal CD-RW disc also worked (yes, I know I could use ide-cd for this, I just did this for testing the ide-scsi fix). This patch seems to solve all my 2.6 ide-scsi problems." Linus Torvalds said, "I've applied the fix part of it and pushed it out. If Andries wants to re-send the whitespace fixes, I can apply those too, but I hate applying patches like this where the whitespace fixes hide the real fix." Andries replied:

Yes, it seems we presently have no good mechanism / policy here. Patches are noise. If some kernel version works and another doesnt, one has to look at the diffs. Whitespace-only diffs are bad, I would never submit them. They also needlessly invalidate existing patches.

On the other hand, nice, readable kernel sources are important. I used to polish the immediate neighbourhood of an actual change. If that is undesirable, what would you prefer?

Ben Pfaff remarked, "When one version of a source file works and another doesn't, `diff -b' or `diff -w' usually does a good job of ignoring whitespace changes." And Linus also said to Andries:

Whitespace-only diffs can be very useful. In particular, they are common when somebody starts working on a piece of code without a maintainer, and the old code was terminally broken wrt whitespace. Happens quite often in the driver world.

So I don't have any real issues with applying whitespace-only patches, and I much prefer them to patches that mix whitespace and bugfixes. In particular, if the whitespace fixes are preparation for some other cleanup, it's usually a good idea.

(I agree that if the whitespace fix is just random, it's usually not worth it).

In Pascal's original reply to Andries, he'd also said that the atapi-mo-support in Andrew Morton's tree were no longer needed, because "That patch only works with 2048 byte sector discs, while the ide-scsi/sd solution also works with 512 and 1024 byte sector discs." Linus in his same reply, said, "I'd really like the ATA cdrom driver to handle different sector sizes properly. There really is no excuse for a block device driver to hardcode its blocksize if it can avoid it." Andries said in his reply:

Yes, it is very easy to change that.

And another thing that is very easy is to move partitioning away from the individual block devices. It was part of the stuff I did last year. Hope to try again for 2.7.

And then there is the read-only part that must be removed.

Those are three reasons why ide-cd today doesnt work so well with optical disks. But I am not sure it is desirable to make ide-cd work with them. The source would be littered with ifs - all this toc stuff is inappropriate for disks.

Markus Hastbacka asked what the difference was between ALSA and OSS sound support; and why ALSA became the 2.6 default. He said he understood some of ALSA's good features, but noted that it wouldn't let him open two sound sources at the same time, such as xmms and Quake 3. Raphael Rigo couldn't answer the larger question, but he did give a pointer to some instructions to enable software mixing with ALSA. Elsewhere, Jaroslav Kysela also said to Markus, "It seems that you don't understand our goals. Please, look to our web pages - http://www.alsa-project.org. If you use audio devices only for consumer use, you probably don't notice anything special." Regarding opening multiple sound sources, Jaroslav added:

We don't do this in kernel. We implemented the direct stream mixing in our library (userspace). If your applications already uses ALSA APIs or if you redirect the OSS ioctls to ALSA library (our aoss library), you can enjoy multiple sounds.

Of course, using hardware which can do the hardware mixing is still better. It's the same difference like between sw 3D rendering and hw 3D rendering.

The enclosed patch implements the netdev_* error-logging macros for network drivers. These macros have been discussed at length on the linux-kernel and linux-netdev lists. All issues that reviewers have raised were addressed previously. This is just an update for v2.6.1.

In December, Jeff Garzik indicated his intention to merge this into the net-drivers-2.5-exp queue, but he apparently never got around to it. As previously discussed, these macros are in demand now (e.g., for the e1000 driver) and have essentially no impact on drivers that don't use them.

RECAP (from previous posts):

Calls to the netdev_* macros (netdev_printk and wrappers such as netdev_err) are intended to replace calls to printk in network device drivers. These macros have the following characteristics:

The first arg is a pointer to the net_device struct.
The second arg, which is a NETIF_MSG_* message level, can be used to implement verbosity control.
The remaining format + args are the same as in the corresponding printk call.
Standard message prefixes: verbose (interface name, driver name, bus ID) during probe, or just the interface name once the device is registered.
The current implementation just calls printk. However, the netdev_* interface and availability of the net_device pointer open the door for logging additional information (via printk, via evlog/netlink, etc.) as desired, with no change to driver code.

Looks OK to me.

But it does make one wonder whether we'll soon see standalone patches for scsi_printk(), pci_bridge_printk(), random_other_subsystem_printk(), ...?

Or is it intended that the backend logging code will be implemented mainly in terms of the `struct device'? So netdev_printk() will be a bit of netdev-specific boilerplate which then calls into a more generic device_printk()?

Well, there is indeed sdev_printk for the SCSI mid-layer and low-level drivers. Dan Stekloff posted an updated patch for this on linux-scsi yesterday.

When Alan Cox suggested dev_printk, it was with the idea that other subsystems might have similar macros. Although I don't know of other such macros in the works, I wouldn't rule them out.

I think dev_printk will work just fine for drivers where [driver name + bus ID] is the appropriate message tag. Where that's not the case, other macros emerge. (For example, for net devices you want the interface name, and for SCSI devices the SCSI bus ID is more interesting than the PCI bus ID.)

Another thing to consider is whether, for the subsystem in question, some other struct pointer (e.g., struct net_device* or struct scsi_device*) might prove more useful in the future than the struct device pointer. I.e., such pointers could be used to get at the struct device AND other subsystem-specific info.

Also, there are also situations where there is no underlying struct device (e.g., some upper-level network drivers) or the driver is not yet defined (e.g., during a SCSI scan).

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm5/

Mainly a resync

Various little fixes
Various fixes to make 2.6.1-mm5 successfully build and run with current gcc CVS (gcc-3.5).
Building the IDE drivers as modules should work now.

Christoph Hellwig asked, "Any reason you keep CardServices-compatibility-layer.patch around? Having a compat layer for old driver around just for some architectures, thus having drivers that only compile on some for no deeper reasons sounds like an incredibly bad idea. Especially when that API is not used by any intree driver and only in -mm ;)" Andrew replied:

Yes, we were concerned about avoiding breaking the various random out-of-tree pcmcia drivers which people use. Russell would prefer that if we _do_ have a compat layer it should be implemented in a different manner.

But we're all fairly uncertain that the compat layer is needed - converting a driver is a pretty simple exercise, and Davd Hinds doesn't intend to maintain his drivers into 2.6.

So the compatibility layer will probably go away soon, unless something happens to bring it back into consideration.

Jan De Luyck asked how usable the Hightpoint HPT370 ide "raid" controller was on Linux 2.4 and 2.6; Wilfried Weissmann replied, "2.4 is fine if you use the ataraid code. mirroring is not fault tolerant so you would not want to use that. raid-0 and jbod is ok. i am currently looking into 2.6. i will probably write an evms plugin for the new kernel. the nice thing is that it will work also for 2.4er kernels with the evms patches plus we get a proper mirroring solution for free. :)" Brian McGroarty said, "No problems with 2.4 here. 2.6 recognizes my 374, which uses the hpt366 driver like the 370. However, no devices are being made available from it (http://lkml.org/lkml/2004/1/16/18)" . Xavier Bestel confirmed seeing the same behavior on his own system; although Mans Rullgard reported his hpt374-based board working fine with 2.6.

kgdb 2.0.5 is available at http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.5.tar.bz2

ChangeLog
2004-01-20 Amit S. Kale <[email protected]>
* Created a ring buffer for kgdb ethernet packets. Several fixes and changes to kgdb on ethernet.

2004-01-20 TimeSys Corporation
* Fixed a problem with not responding to Ctrl+C during priting of console messages through gdb.

I have pasted below eth.patch for review. When using the ethernet interface, gdb times out several times. It receives packets and junk instead of acks. I see following type of messages out of 8139too.c on the console "eth0:Out-of-sync dirty pointer, 15 vs. 20."

Preliminary 648FX agp support.

The delay problem described in http://www.ussg.iu.edu/hypermail/linux/kernel/0401.1/0053.html still exists. Dave: any luck with that data sheet yet?

agp3 specifies things that had been left up to implementers in previous versions hence the new generic-agp3.c file. Apart from the problem described above the 648 chipset seems to stick to the spec.

If this is also true for other chipset it might be possible to turn this into a generic agp3 driver at some point?

Obviously, users of the fglrx driver will want to turn off the internalagp option.

20�Jan�2004�-�24�Jan�2004 (11 posts) Archive Link: "Linux 2.6.2-rc1"

Ok, this is the next "big merge" with things from Andrew's -mm tree, along with a number of new drivers and arch updates.

People have been busy little beavers. In particular, there are 432 patches that came through Andrew.

Of the other updates, the biggest single thing is the new qla2xxx SCSI driver. But there's a fair number of other drivers too. See the summary for more details.

Stephen Rothwell pointed out that Linus had spelled his name wrong (Rothwel) in the ChangeLog, and said that Rusty Russell had offered him some sage advice, to nip that in the bud or it would haunt him forever. Linus replied:

For every time IBM removed one vowel from one of their ppc mnemonics, I'll remove one "l" from a ppc developer.

We'll see who blinks first.

Linus "payback time" Torvalds

Dave Jones tried to post to the linux-dvb mailing list, which was listed in the kernel MAINTAINERS file as the official list for DVB discussion; but since he wasn't actually subscribed to the list, it rejected his post. He said on linux-kernel, that these sorts of closed lists should be marked as such in the MAINTAINERS file, so folks didn't waste their time. Linus Torvalds replied, "Sounds like they shouldn't be in MAINTAINERS at all if they can't be posted to. I mean, what's the point?" There was a lot of agreement with this, and Jes Sorensen said at one point, "can a list be considered a contact point at all if you can't post to it? If they are so afraid of outside posters, they can setup a specific list for bug reporting only thats open or something." And Rik van Riel said, "we should remove all addresses from MAINTAINERS where bug reports by email aren't welcome."

One reason for keeping a list closed is to avoid spam; and the discussion meandered into various anti-spam techniques, bayesian filtering and so forth. At one point, Michael Hunold took it back to the linux-dvb issue, saying:

We've created a new e-mail address which is currently an open mailing-list anybody can subscribe to.

It's currently watched by the main developers. If spam takes over the list, we might change it to "moderated" or even route it to one single person.

Sorry for the inconvenience, I hope this is a solution we can all live with.

He posted a patch to the MAINTAINERS file, to add "[email protected]" as the open list, and to mark [email protected] as subscription-only. Dave thanked him, and the thread ended.

Update for SiS framebuffer driver for 2.6.1 vanilla

Since it does not seem as if the fbdev stuff gets merged anytime soon, I made this patch for 2.6.1 vanilla.

I slightly lost track of current patch size policy, so please excuse me if this is beyond current limits.

Anyway, sisfb is simply broken in current 2.6.x. This patch updates sisfb to the current development version which no less than 11 months ahead of the version in the kernel.

Updated includes

many fixes (duh)
support for new chipsets (661, 741, 760)
support for new video bridges (301C, 302ELV)
removal of all offending fp code (as discussed earlier this month)
a lot of code clean-up (which is the main reason for its size)

Patch is here: http://www.winischhofer.net/sis/sisfb_patch_2.6.1.diff.gz

Andrew Morton replied, "we need to coordinate this with James and Ben who are also doing things in this area. But we wouldn't want to have to defer this SiS patch until everything is sorted out in the fbdev core - life is too short ;)" . Thomas replied:

Exactly. I don't see any activity on the fvdevel list since a while back. Don't even know what the current status is.

Anyway, it required only to compiler directives to exclude the modifications needed by the current James-stuff. Shouldn't be too hard.

Nigel Cunningham said, "Here's a patch Bernard Blackham posted to the Software Suspend mailing list, which has fixed data-not-being-properly flushed issues for some people. (Forwarded with Bernard's permission)." Andrew Morton pointed out, "This spins down the disk(s) when you're just doing do a reboot. That's fairly irritating and could affect reboot times if one has many disks." John Bradford speculated, "I think it is an attempt to force some broken drives to flush their cache, but I wonder whether it will simply move the problem from one set of broken drives to another :-)." James H. Cloos Jr. felt that this was exactly what would happen; and close by, Nigel asked if there were any better way. John said, "It was discussed at length around the 2.4.20 timeframe, when the power-off cache-flush and spin down behavior was changed, but I don't remember any real conclusion being reached." And Andrew said:

A couple of thoughts come to mind:

a) Don't do it if the user typed reboot - only do it if we're powering down.

b) Try to do a cache flush instead. If that fails (do we know?) then power down the disk instead.

Nigel started to consider this, when Jeff Garzik broke in with, "I'm either shocked or very very worried that the reboot notifier that flushes IDE in 2.4.x, ide_notifier, is nowhere to be seen in 2.6.x :( That seems like the real problem -- the code _used_ to be there." And Bartlomiej Zolnierkiewicz said, "Yep, it should be re-added. I wonder when/why it was removed?" But there was no answer.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc1/2.6.2-rc1-mm1/

Nothing very exciting, just lots of random fixes.
The x86 gcc-3.4/gcc-3.5 support seems pretty much complete now. There are enough fixes here to get a reasonably clean build with my .config but a full kernel build still will need work.
I've uploaded patch-scripts-0.14 to

http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.14/

The main change is the addition of the new `patch-bomb' script. It uses a little standalone SMPT client written by Bryan Henderson to mail patches to a victim, with an optional Cc to the people who wrote each of the patches. See docco.txt for details.

I've released the 014 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-014.tar.gz

rpms built against Red Hat FC1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-014-1.i386.rpm
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-014-1.src.rpm

udev allows users to have a dynamic /dev and provides the ability to have persistent device names. It uses sysfs and /sbin/hotplug and runs entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run. Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

Major changes from the 013 version:

speed! This version is _much_ faster than the 013 release. Thanks to Ananth Narayan for the libsysfs changes (and udev patch) that enabled this.
there's a new program called udevinfo in the extras/ directory that helps in determining the sysfs information for a specific device. This is useful in writing new udev rules.
the %D modifier is now gone. People who were using it to provide a devfs naming scheme will need to rewrite their rules (look at the examples on the linux-hotplug-devel mailing list for more details.)
lots of little changes and bug fixes.

Thanks again to everyone who has send me patches for this release, a full list of everyone, and their changes is below.

udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev

Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.

22�Jan�2004�-�24�Jan�2004 (6 posts) Archive Link: "vt6410 in kernel 2.6"

Mike Gabriel asked if anyone was working on support for the vt6410 IDE/RAID chipset in Linux 2.6; he added, "there has been an attempt by via itself, but it only suits redhat 7.2 kernels and systems, thus it is highly specific." Jeff Garzik said that support should already be in 2.6; Mike asked for the names of the config options, as he was unable to find them; and Jeff said, "CONFIG_BLK_DEV_GENERIC or CONFIG_SCSI_SATA_VIA should do it." Mike asked, "i thought these options were for SATA only. what i need is the ide-part of the controller. is this support by these options, as well?" And Jeff said, "The PATA part is handled by CONFIG_IDE, though drivers/ide/pci/via82cxxx.c may need another PCI id or two. 'lspci -n' will retrieve these ids."

Nicklas Bondesson asked, "I wonder what the status is on implementing an ataraid (replacement) in the 2.6.x kernel tree. It can be done with device mapping, but it's still far too tactless I think." And Mike Fedyk replied, "Many disagree. In fact it looks like MD will be merged with DM, so you might as well start on using DM for this too."

Time for a big PowerMac merge, a bunch of these things are driver updates and machine support fixes that went in after the 2.6.0-rc code freeze, and support for newer machines (including 32 bits support for the G5).

This is for inclusion with -mm and possible comments, currently, the 51 changesets are folded in one big patch. When it's time to merge with linus, he'll get them as separate csets.

The full support for the G5 also need a sungem driver update currently in davem's hands.

The full support for all recent pmacs also wants some fbdev updates that will come separately.

Too big to be posted here (and I didn't feel like using Greg's script to post 51 emails in burst to lkml :) so here's an URL to pick it up:

http://gate.crashing.org/~benh/big-pmac.diff
or
http://gate.crashing.org/~benh/big-pmac.diff.bz2

This patch removes memblks from the kernel ... we don't use them, and the NUMA API that was planning to use them when they were originally designed isn't going to use them anymore. They're just unnecessary added complexity now ... time for them to go.

There's a slight complication in that ia64 uses something with a similar name for part of its memory layout, but Jes Sorensen kindly untangled them from each other for us. The patch with his modifications is below. Jes tested it on ia64, and I testbuilt it with every config in my arsenal.

Matthew Dobson said, "As the unfortunate soul who pushed this whole memblk concept way back when, I'll add my support for their removal. The things I envisioned happening with memblks never materialized and so Martin is right, now they're just taking up space. Adios memblks, we barely knew ye." And Yasunori Goto added, "I feel I have to agree removing memblk, because my opinion is just concept and I don't have any patch yet. If memblks will be needed again when we will be able to support partial failure of memory, I will post the patch."

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc1/2.6.2-rc1-mm2/

There is a new debug check in here which drops a stack trace when a piece of code calls one of the sleep_on() functions without lock_kernel() held. This is almost certainly a bug. Please try to identify (from the trace) which subsystem is the culprit and copy its maintainer when reporting such traces.

After ten such warnings the diagnostic shuts itself up.
A big SiS framebuffer driver update. Please test, and include Thomas Winischhofer <[email protected]> in any reports.
Included the latest ACPI test tree. Please copy [email protected] on any ACPI-related reports.
Another MD update.

Mariusz Mazur said, "At http://ep09.pld-linux.org/~mmazur/glibc-kernel-headers/ there are userland headers for linux, derived from 2.6 kernels with lots of 2.4 compatibility fixes. CVS repo can be found at cvs.pld-linux.org/glibc-kernel-headers (anon and webcvs). These headers are currently used to compile a whole linux distro (ftp.pld-linux.org/dists/ac) for x86, sparc, amd64, alpha and ppc, but general fixes are applied to all archs since we never know if a new arch won't be added (amd64 was added just a month-two ago). #1 feature is that they are and will be maintained (currently three people are working on them) and bugs are mostly fixed instantly." Daniel Jacobowitz replied:

I've done precisely the same thing for Debian - if I find the time, I'll compare...

I would really like to come up with an approach to maintain this interface definition in the kernel source. I'm still trying to think of a way to do it without breaking compatibility or kernel builds.

Mariusz replied, "As I really would like that (less work for me :) I do not think this is possible. First thing - 2.4 compatibility in 2.6 kernel would seem weird to say at least. Second - I've ripped out kernel code where I could and used glibc includes instead - this is (a) The Right Thing (tm) and (b) practically undoable inside kernel or would require huge amounts of work, which is really better of left outside."

Sam Ravnborg also replied to Daniel's suggestion, offering to help with any kbuild needs that might come up. Elsewhere, H. Peter Anvin also said:

We've referred to this for quite a while as the "ABI header project"; it's been targetted for 2.7, since it missed the 2.6 freeze.

We have set up a mailing list at:

http://zytor.com/mailman/listinfo/linuxabi

The goal is to get a formal exportable version of the kernel ABI that user-space libraries can use.

Daniel checked out the list, but noticed that there had never been any traffic on it. He asked what was up, and H. Peter replied, "There was some traffic on the klibc list, but I don't think things got started after the new list was created."

23�Jan�2004�-�27�Jan�2004 (16 posts) Archive Link: "Linux 2.4.25-pre7"

It contains a bunch of architecture-specific updates (ia64, ppc, mips), JFS and XFS updates, bugfix for big (>128GB) FAT filesystem corruption, amongst others.

About 2.4 freeze:

The planned freeze during 2.4.26 can happen only for 2.4.27.

There are a few bad problems I'm aware of which still need to be fixed (aic7xxx needs to be updated, modular IDE has some problems, etc). Those should get fixed during 2.4.26-pre.

Udo A. Steinberg asked if Marcelo planned to merge cryptoloop into the kernel before the freeze, and Marcelo replied that no, he had not plans to do so.

Any chance of the forward-compatible module_param patch?

Name: 2.4 module_param Forward Compatibility Macros
Author: Rusty Russell
Status: Tested on 2.5.24-pre6
Version: 2.4

D: Simple uses of module_param() (implemented in 2.6) can be mapped
D: onto the old MODULE_PARM macros.
D:
D: New code should use module_param() because:
D: 1) Types are checked,
D: 2) Existence of parameters are checked,
D: 3) Customized types are possible [1]
D: 4) Customized set/get routines are possible [1]
D: 5) Parameters appear as boot params with prefix "<modname>." [1]
D: 6) Optional viewing and control through sysfs [2]
D:
D: [1] Not for 2.4 compatibility macros
D: [2] Not in 2.6.1 or 2.4, and only if third arg non-zero.

Martin Diehl has finished converting all the old style dongle driver to the new API. This was the last major feature parity issue with 2.4.X, with this work, 2.6.X should support all the IrDA serial dongles that 2.4.X supports. Martin also did a few other cleanups and fixed tekram-sir so that it works with real hardware.

All patches depend on the first patch, and the last patch depend on the previous patches. I tested this on 2.6.2-rc1 with an actisys dongle, neither Martin or I have hardware to test the other dongle drivers.

David S. Miller said, "All applied. I'll queue this up. I'll try to get it in now but it may be deferred to the next 2.6.x release." Jean thanked him, and the thread ended.

Chuck Campbell asked if ext3 had ever been back-ported to the 2.2 kernel, and Andrew Morton replied, "It was written for 2.2, and then forward-ported." He gave a link to a patch. Chuck was perplexed by this, as he saw no evidence of ext3 in any 2.2 kernel he looked at. Andrew explained, "ext3 was originally written for 2.2 but was never merged into the mainstream kernel. That happened in 2.4.15." And Theodore Ts'o remarked at this point, "There were also some bug fixes that I'm pretty sure were never backported into the 2.2 tree...."

attached is the current version of forcedeth, a network driver for nForce{,2,3} chipsets which are fairly common today. So far, the only support for nForce chipsets has been a binary-only driver from NVidia.

This driver has received testing by over 200 people on nForce1, nForce2 and nForce3 chipsets and has already been integrated into 2.6. Before that, it has been in -mm for a few weeks. We currently don't have any unresolved bug reports.

Credits for the driver go to:
Andrew de Quincey: Writing a spec for the chipset
Carl-Daniel Hailfinger: Co-author of the spec, driver fixes
Manfred Spraul: Writing the driver

Jeff Garzik had some criticism, saying the patch was not ready for inclusion quite yet; and that he should have been consulted. Carl-Daniel replied, "sorry. Since I had not seen any net driver patches getting into 2.4.25-pre, I assumed you had set your priorities to 2.6. Looking again, it seems the switch from 2.4.24-pre to 2.4.25-pre confused me and I forgot to double check with the actual prepatches." He promised to do a better job at coordination, to avoid toe-stepping.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc1/2.6.2-rc1-mm3/

2.6.2-rc1-mm3's allyesconfig now successfully builds with current gcc-3.5 CVS. However allyesconfig doesn't link because of symbol clashes in IRDA.
Various random fixes.

Tim Cambrant leapt for joy, as Andrew's release included Tim's patches for the first time ever; and Tim was super happy to get code into the kernel, a long-time dream of his.

Marcel Sebek said he'd ported the IMQ driver from 2.4 to 2.6; David S. Miller asked Patrick McHardy if it was OK if David merged this patch into his tree; but Patrick replied, "Please don't. The imq device is buggy, it crashes when used for ingress and egress at the same time, additionally it's unmaintained since one or two years. The lartc list is full of bugreports. Some users that depend on the functionality are working on a better implementation, I'd suggest to wait until then." David said he'd hold off, in that case.

Elsewhere, Tomas Szepe said he hoped IMQ would get into the kernel at last; but someone said there didn't seem to be much use for that code, really. Vladimir B. Savkin offered, "Think multiple clients connected via PPP. I want to shape traffic, so ingress is out of question. I want different clients in a same htb class, so using qdisc on each ppp interface is out of question. It seems to me that IMQ is the only way to achieve my goals." There followed a technical argument over proper networking practices; and the thread petered out.

Cooperative Linux is a port of the Linux kernel which allows it to run cooperatively under other operating systems in ring0 without hardware emulation, based on very minimal changes in the architecture dependent code and almost no changes in functionality.

The bottom line is that it allows us to run Linux on an unmodified Windows 2000/XP system in a practical way (the user just launches an app), and it may eventually bring Linux to a large sector of desktop computer users who wouldn't even care about trying to install a dual boot system or boot a Linux live CD (like Knoppix).

Screen-shots and further details at:

http://www.colinux.org

Our motto is:

"If Linux runs on every architecture, why should another operating system be in its way?"

coLinux is similar to plex86 in a way that it implements a Linux-specific lightweight VM with I/O virtualization. However, it is designed to be mostly host-OS independent, so that with minimal porting efforts it would be possible to run it under Solaris, Linux itself, or any operating system that supports loading kernel drivers, under any architecture that uses an MMU. Unlike other virtualization methods, it doesn't base its implementation on exceptions that are caused by instructions.

Cooperative Linux is like the kernel mode equivalent of User Mode Linux. It relies on the host OS kernel-space interfaces rather than relying on host OS user-space interfaces.

Currently, it is stable enough (on some common hardware configurations) for running a fully functional KNOPPIX/Debian system on Windows (see website screen-shots).

Another project close to achieving that goal is the Windows port of User Mode Linux (http://umlwin32.sf.net).

Project page:

http://sourceforge.net/projects/colinux

Thank you for your time,

- The coLinux development team.

This Open Source project is sponsored and produced by AIST, 2004 http://www.aist.go.jp/

Karim Yaghmour was very excited to see this work, and suggested checking out the Adeos Nanokernel, which tried to solve similar problems.

Nuno Silva was also enthusiastic, asking if it would be possible to run multiple instances of Linux at the same time using this system; and also asking if Linux could host the process itself yet. Dan replied that yes, multiple instances were indeed possible; and as for running under Linux itself, Dan said, "I can't say exactly when, but several people volunteered to work on this." Karim replied:

BTW, I've been looking at the code. Many of the tricks done for forcing NT to share resources with Linux should be unnecessary for a Linux setup. Also, the code apparently assumes only two OSes. You probably want to check the detailed discussion I had written some time ago about how to easily obtain an SMP cluster with Linux (N instances on separate CPUs with very few code modifications required):

http://www.opersys.com/adeos/dox/practical-smp-clusters/practical-smp-clusters.html

Some of the code you've already written can be used as-is to this end. The nanokernel side still needs some extending, but you've brought things one step closer to completion.

On a UP system, instead of running just 2 instances, you can load a nanokernel in a fixed RAM region and remap it in every instance's virtual memory. You can then use a slightly modified kexec to start independent images in different RAM regions. I had discussed this with Eric at the last OLS and he was interested. The added advantage with Adeos is that you could then share a single interrupt pipeline among all OSes, and have different OSes manage different hardware components. Of course, if you add the PCI allocation code I cover in the above paper, you can then have things like two kernels independently managing, for example, two seperate sets of ethernet card and SCSI disk. There's some pretty cool stuff to be done here, away from the simple virtual devices. You could also have a virtual ethernet layer which is shared by all OS images, and then have a private network between all OS instances. With Adeos, you can also have one kernel take care of all hard-rt operations and another kernel take care of the soft-rt operations. All of it is fairly hardware independent.

Dan said, "allowing Cooperative Linux to directly access the hardware is problematic on systems like Windows. coLinux's goal is more focused on bringing Linux to other operating systems than resources sharing among several operating systems. However, I have no doubt it can be used to run several virtual Linux's on a single SMP Linux machine, with emphasis on the 'virtual'."

Elsewhere, someone else asked about possibly writing a bare-bones OS whose only purpose was to run instances of other OSes like Cooperative Linux on top of it. Rik van Riel suggested that it would be better just to run Linux below everything, in order to have access to all the existing device drivers. Karim also said that the whole bare-bones OS concept was already an integral part of the Adeos project. Nuno Silva also gave a pointer to the xen project; to which Karim replied, "For a UP system, Xen may be fine, depending on what you're trying to do. If you're looking for a better VMware, then Xen is likely to fit your bill. However, there are a few things to keep in mind when looking at this sort of stuff. So, for example, Xen assumes that all OSes are going to use the same devices for I/O: same disk, same NIC, etc. It therefore implements lots of virtual devices for these. But what if you wanted each OS to manage separate hardware? Also, I'm not sure I want my OS instances to have to request memory on a page basis with the nanokernel/monitor. Wouldn't it be just better to reuse the existing work on the hotplug hardware (hotplug CPU, hotplug memory, etc.) to have the kernels get/return hardware resources to the nanokernel? Also, how generic is the virtualization solution being examined? I've put some thought into getting a virtualization architecture which spans UP, SMP, SMP-clusters, and hard-rt, and wrote that down as a series of papers about Adeos. I probably don't have the final answer, and there are probably many things I haven't figured out in the papers I've written on the topic, but you may want to take a look."

Due to frequent travels and lost hardware I can't even pretend to maintain the drivers for the parallel port network adapters D-Link de600 and de620 any more ( drivers/net/de6* ).

I am deeply thankful to the people who have added patches that allowed these OLD drivers to live on. We're talking about more than TEN YEARS since they were initially created... Scary...

If anyone still has access to these adapters and is willing to take the responsibility for keeping the drivers alive, just announce the take-over, tell me, and receive my blessings.

Lastly, I include a patch that updates my contact info. I don't even know who to send the patch to -- that's how out of touch I am ;-)

David S. Miller accepted the patch, and asked Bjorn to send another patch if someone else decided to take over the code.

Version 2.6.5 of perfctr, the Linux performance monitoring counters driver, is now available at the usual place: http://www.csd.uu.se/~mikpe/linux/perfctr/

Version 2.6.5, 2004-01-26

Relaxed and corrected control checks on Pentium 4:
- Allow ESCR.CPL_T1 to be non-zero when using global-mode counters on HT processors.
- Don't require ESCR.CPL_T0 to be non-zero. CPL_T0==0b00 is safe and potentially useful (global counters on HT).
- Require CCCR.ACTIVE_THREAD==0b11 on non-HT processors, as documented in the IA32 Volume 3 manual. Old non-HT P4s seem to work Ok for all four values, but this is neither guaranteed nor useful.
Per-process counters driver updated for filp->f_mapping change in 2.6.2-rc kernels.
Support 2.4.21-9.EL (RHEL3) and 2.4.22-1.2149.nptl (FC1) kernels.
Library updates for PowerPC:
- Added cpu_type constants for struct perfctr_info.
- Decode PVR and define perfctr_info.cpu_type accordingly.
- Added event set descriptions for 604/604e/750.

This is the next (and hopefully the last) prerelease version to 1.1.

The biggest change is that NFS export of a FUSE filesystem is now supported under linux 2.6.X. Since 2.4 has an inferior NFS export interface it would be much more difficult to support it. But who wants to use 2.4 anyway :)

The other change is that small (4k) reads are now the default again. This is because there is some overhead with 64k reads (a memory allocation and an extra memory copy). Of course if your filesystem handles big reads more efficiently, then 64k reads may come out better. This can be controlled with the '-l' option of fusermount, passed to the fuse_mount() function or if using fuse_main() this also works:

fuseprog /mnt/xyz -- -l

You can download it from here:

http://sourceforge.net/project/showfiles.php?group_id=21636&package_id=31956&release_id=212701

Please test this release, as this will be 1.1 if no problems are found!

Jaroslav Kysela gave a link to an ALSA patch that would "update the ALSA in kernel to version 1.0.2. I am not sure, if this request is too late for 2.6.2. If so, please, consider merging to 2.6.3." Someone else replied, saying that users experiencing problems with the Intel8x0 driver, Jaroslav's patch seemed to have fixed them.

For those who've sold their GPL soul to use the binary drivers from NVIDIA...

NVIDIA have announced a new release of their graphic card drivers: version '1.0-5336'

http://www.nvidia.com/object/linux.html

This release has support for Linux 2.6 kernels, fixes AGP failures on some VIA motherboards, and fixes a problem that prevented X from running on Samsung X10 laptops.

�
Kernel Traffic Latest�\|�Archives�\|�People�\|�Topics	Wine Latest�\|�Archives�\|�People�\|�Topics	GNUe Latest�\|�Archives�\|�People�\|�Topics
Czech

1.	15�Jan�2004�-�21�Jan�2004	(11 posts)	Support For Infrared Remotes In 2.4 And 2.6
2.	15�Jan�2004�-�20�Jan�2004	(11 posts)	Altix Updates
3.	15�Jan�2004�-�21�Jan�2004	(31 posts)	Linux 2.6.1-mm4 Released
4.	16�Jan�2004�-�23�Jan�2004	(33 posts)	KGDB 2.0.3 Released
5.	16�Jan�2004�-�21�Jan�2004	(25 posts)	C++ Modules And Kernel Code
6.	16�Jan�2004�-�21�Jan�2004	(18 posts)	Some Discussion Of Maintainership And Patch Acceptance Policy
7.	16�Jan�2004�-�22�Jan�2004	(5 posts)	ReiserFS Support For laptop_mode
8.	17�Jan�2004�-�20�Jan�2004	(9 posts)	Modular IDE For 2.6
9.	18�Jan�2004�-�29�Jan�2004	(62 posts)	Software Suspend On PowerPC
10.	18�Jan�2004�-�20�Jan�2004	(16 posts)	Fix For ide-scsi Crash; Some Discussion Of Whitespace Patches
11.	19�Jan�2004�-�24�Jan�2004	(32 posts)	ALSA Vs. OSS Sound Support
12.	19�Jan�2004�-�20�Jan�2004	(5 posts)	Net Device Error Logging Macros For Drivers
13.	20�Jan�2004�-�22�Jan�2004	(40 posts)	Linux 2.6.1-mm5 Released
14.	20�Jan�2004�-�21�Jan�2004	(9 posts)	Status Of HPT370 Under 2.4 And 2.6
15.	20�Jan�2004�-�21�Jan�2004	(4 posts)	KGDB 2.0.5
16.	20�Jan�2004	(1 post)	AGPGART Preliminary SiS648 Support
17.	20�Jan�2004�-�24�Jan�2004	(11 posts)	Linux 2.6.2-rc1
18.	21�Jan�2004�-�26�Jan�2004	(64 posts)	Kernel Sub-Project Mailing List Posting Policies
19.	21�Jan�2004�-�22�Jan�2004	(6 posts)	SiSFB Update For 2.6.1
20.	21�Jan�2004�-�22�Jan�2004	(13 posts)	Data-Flushing Prior To Software Suspend
21.	22�Jan�2004	(18 posts)	Linux 2.6.2-rc1-mm1 Released
22.	22�Jan�2004	(1 post)	udev 014 Relesed
23.	22�Jan�2004�-�24�Jan�2004	(6 posts)	Support For VT6410 IDE/RAID Chipset In 2.6
24.	22�Jan�2004	(2 posts)	Status Of ATARAID In 2.6
25.	22�Jan�2004�-�26�Jan�2004	(7 posts)	PowerMac Update
26.	22�Jan�2004�-�28�Jan�2004	(4 posts)	memblks Leaving The 2.6 Tree
27.	23�Jan�2004�-�25�Jan�2004	(24 posts)	Linux 2.6.2-rc1.mm2 Released
28.	23�Jan�2004�-�25�Jan�2004	(10 posts)	Exporting Kernel Headers To User-Space; Stablizing The Kernel ABI
29.	23�Jan�2004�-�27�Jan�2004	(16 posts)	Linux 2.4.25-pre7 Released; Status Of 2.4 Deep Freeze
30.	23�Jan�2004�-�26�Jan�2004	(3 posts)	IrDA Serial Dongle Support In 2.6 Reaching Parity With 2.4 Support
31.	23�Jan�2004�-�28�Jan�2004	(8 posts)	Status Of ext3 In 2.2 Kernels
32.	24�Jan�2004	(14 posts)	Forcedeth Update For 2.4; Some Developer Confusion
33.	24�Jan�2004�-�26�Jan�2004	(3 posts)	Linux 2.6.2-rc1-mm3 Released
34.	25�Jan�2004�-�26�Jan�2004	(15 posts)	IMQ Forward-Ported To 2.6; Inclusion Still In Question
35.	25�Jan�2004�-�29�Jan�2004	(21 posts)	Cooperative Linux: Running Linux Under Windows And Other Systems
36.	25�Jan�2004	(2 posts)	drivers/net/de6* Needs A Maintainer
37.	26�Jan�2004	(1 post)	perfctr 2.6.5 Released
38.	27�Jan�2004	(1 post)	FUSE 1.1-pre2 Released
39.	27�Jan�2004	(2 posts)	ALSA 1.0.2 Released
40.	27�Jan�2004�-�28�Jan�2004	(7 posts)	Binary-Only Nvidia Drivers For 2.6

Kernel Traffic #251 For 9�Feb�2004

By Zack Brown