Kernel Traffic #288 For 2�Jan�2005

Fix the panic spewing XFree86 keyboard printks bug (quick fix for now). Fix a problem with legacy ide /proc and also fix the Seqpacket/SELinux problems.

Arjan van de Ven is now building RPMS of the kernel and those can be found in the RPM subdirectory and should be yum-able. Expect the RPMS to lag the diff a little as the RPM builds and tests do take time.

The it8212 still doesn't default to DMA on - that is on the TODO list. The HPT366 rework project is also not ready (its gone back to the drawing board for a few days if you are a volunteer and wondered what is up).

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/linux-2.6/2.6.9/

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/

• It's time to shut things down for a 2.6.10 release now. I'll do another pass through the -mm lineup for things which should go into 2.6.10.

  If anyone has patches in -mm which they think should go into 2.6.10 please let me know. (particularly ppc/ppc64). The v4l patches certainly look like they need to go in.

• I seem to have accumulated several tens of bug reports, most of which are post-2.6.9 and a few of which predate 2.6.9. I'll send out another round of emails regarding that shortly. Please let's focus on these things so we can get a good 2.6.10 out.
• There's a pretty big revamp of the filesystem quota code in here. If you use quotas, please test.
• Also a larger refactoring of the DVB code. It would be appreciated if people could avoid little cleanups in the current code while this is under test. Testing from DVB users would be appreciated.

this should about cover it. I've written two document files, and packaged them as a patch.

Two things caught my eye while I was writing this up:

The header comments for CDROMREADRAW, CDROMREADMODE1, and CDROMREADMODE2 disagree with the actual source code. The header comments imply that a cdrom_read structure is used to pass data, but the source code actually reads a cdrom_msf structure and then overwrites it with raw data. I'm not sure if there's a bug in the header comments, in the driver source, or I misread something.

The CDROM_LOCKDOOR ioctl seems to lock/unlock all doors on all drives, because it uses a global variable.

This -ac is a little different. It's an experimental -ac to test the accumulated patches it would be nice to have in -ac but which might break something and seemed too risky. As such please test it but in general wait for the next -ac before planning to update production systems.

Arjan van de Ven is now building RPMS of the kernel and those can be found in the RPM subdirectory and should be yum-able. Expect the RPMS to lag the diff a little as the RPM builds and tests do take time.

The it8212 still doesn't default to DMA on - that is on the TODO list. The HPT366 rework project is also not ready (its gone back to the drawing board for a few days if you are a volunteer and wondered what is up).

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/linux-2.6/2.6.9/

For a while VGER did answer to all MAIL FROM and RCPT TO lines of the SMTP protocol "450 I am sick.." (actual text was something else) and thus refused to take any email from outside and asked for latter retry. (All proper MTAs have a queue, and they use it.)

It is amazing how many noticed the slow-down of the message flood, and asked from VGER's postmaster (or webmaster) about the thing. Unfortunately at this time the problem prevented the question from being delivered to us... Linus himself knew other addresses, and got our immediate attention.

Technically: VGER's SMTP input server's one helper program had ran out of sockets, and it didn't do correct resource rollback in all failure situations -> it didn't heal itself.

This had started to some extent on Wednesday morning (UTC) and it went all bad on Thursday noonish (UTC) and finally we became aware of the thing on Friday around 18:00 UTC, analyzed the problem, and restarted relevant subsystem. (Restart does cure some problems, this was in that group of things.)

Accumulated queues from all over were delivered into VGER in about 10 hours, and in about the same time they were also processed (delivery bounces and list messages, both.)

This is the start of the 29th -pre cycle of the v2.4 kernel series.

Its mainly backport of driver fixes from v2.6: SATA subsystem update, network drivers (e1000, forcedeth, 3c59x), collection of I2C corrections, isofs large file fix, sym53c8xx_2 fixes, InterMezzo backports, JFS update, an IA32 microcode fix, MIPS update, couple of USB changes, amongst others.

The ACPI bug which caused I2C problems has been solved.

It also contains a VM change from Andrea which improves performance on high-end boxes making certain loads useable on those systems.

The number of changes is small and it should keep decreasing as time passes.

I recently bought an iRiver PMP-140 portable multimedia player which runs under Linux. Unfortunately, I could neither find the offer for the source code required by the GPL nor would the support people at iriver USA tell me where I can get the source code. They just said that it is not possible to get the sources. I also emailed to iRiver Germany but haven`t received an answer yet. Has anybody else tried to contact them? If you are interested, there is a new firmware available here (klick on PMP100kor-v201.zip).

Using string on the unzipped files shows that at least the Linux kernel and busybox are used in the firmware.

I tried to send this email to [email protected] but it came back with a no route to host error which I also get for the website now, although I could load it just a half an hour ago.

What should be the next step?

Below is a patch adding inotify to 2.6.10-rc2.

This is version 0.16.

inotify is intended to correct the deficiencies of dnotify:

• dnotify requires the opening of one fd per each directory that you intend to watch. This quickly results in too many open files and pins removable media, preventing unmount.
• dnotify is directory-based. You only learn about changes to directories. Sure, a change to a file in a directory affects the directory, but you are then forced to keep a cache of stat structures.
• dnotify's interface to user-space is awful. Signals?

inotify provides a more usable, simple, powerful solution to file change notification:

• inotify's interface is a device node, not SIGIO. You open a single fd to the device node, which is select()-able.
• inotify has an event that says "the filesystem that the item you were watching is on was unmounted."
• inotify can watch directories or files.

The primary change since the last post is the move to new per-user resource limits. Watches are now resource limited on a per-user level, not per-device. These limits are now configurable via sysfs.

Added the FIONREAD ioctl for querying the number of events waiting in the queue. The maximum number of events is configurable via sysfs.

Other changes include cleanups and bug fixes (including a nasty bug with queue overflows).

In an email conversation with Alan Cox and Andrew Morton I was asked if OSDL could create a repository for old non-NDA manuals.

I agreed that this sort of old copyrighted but never to be reprinted documentation needs a home and even though some said it was a monster it looked like a nice little bunny to me so .....

I've set up a little web site and have a file cabinet all ready to go.

http://developer.osdl.org/dev/opendoc/index.html

I also decided that as long as I had to keep a list of hard copy documentation in the drawer I might as well add links to companies providing documentation and links to any groups or standards. So if you have favorite links or your company provides developer information for open source folks please send the link information to [email protected].

If you have an old non-NDA manual for something that you aren't the maintainer and no longer want the responsibility of keeping coffee or pet stains off of it. Then please follow the instructions under "Submitting Hardcopy".

As for any other comments I welcome them. Not set on the anything just trying to provide a service here.

I agree this document repository has significant potential, but I also agree with Dave: from my own direct experience, documents DO disappear.

The ALSA project routinely asks vendors if the hardware manual can be mirrored on their FTP site, and I have been doing the same for network and ATA drivers:

http://gkernel.sourceforge.net/specs/

Though I cannot say that all the people who gave me permission to mirror the site are still around, to give permission to push these specs to ODSL.