Kernel Traffic #252 by Zack Brown
[email protected] Thu, 12 Feb 2004 22:21:11 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #252 For 12 Feb
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 25 Jan - 30 Jan (9 Linux 2.6.2-rc2 Released
posts)
2. 26 Jan - 1 Feb (17 Ongoing FAT Filesystem Support
posts)
3. 26 Jan - 2 Feb (14 Encrypted Filesystem; User-Space Filesystem
posts)
4. 28 Jan - 30 Jan (6 UDF Write Support For DVD And CD Media Under
posts) 2.6
5. 29 Jan - 3 Feb (14 Some Discussion Of Hyperthreading
posts) Implementation
6. 29 Jan - 30 Jan (3 Linux 2.4.25-pre8 Released
posts)
7. 30 Jan (1 PC300 Update For 2.6
post)
8. 30 Jan - 1 Feb (3 Linux 2.6.2-rc3 Released
posts)
9. 31 Jan (2 Netwosix Linux Distribution Version 1.0
posts) Released For Kernel 2.6.1
10. 1 Feb - 2 Feb (32 Input Drivers FAQ For 2.6
posts)
11. 2 Feb - 3 Feb (4 Support For IBM RSA Service Processor
posts)
12. 3 Feb (1 Some UML Fixes For 2.6.2-rc3-mm1
post)
13. 3 Feb (9 udev 016 Released
posts)
Mailing List Stats For This Week
We looked at 889 posts in 4067K.
There were 330 different contributors. 134 posted more than once. 162 posted
last week too.
The top posters of the week were:
* 88 posts in 524K by Greg KH
* 19 posts in 71K by Timothy Miller
* 18 posts in 57K by Vojtech Pavlik
* 15 posts in 49K by Andrew Morton
* 14 posts in 53K by Linus Torvalds
* Full Stats
1. Linux 2.6.2-rc2 Released
25 Jan - 30 Jan (9 posts) Archive Link: "Linux v2.6.2-rc2"
Topics: USB
People: Linus Torvalds
Linus Torvalds announced Linux 2.6.2-rc2, saying:
It's being uploaded right now, and the BK trees should already be uptodate.
There's a x86-64 update and IRDA updates here, and a number of USB storage
fixes. The rest is pretty small.
2. Ongoing FAT Filesystem Support
26 Jan - 1 Feb (17 posts) Archive Link: "PATCH to access old-style FAT fs"
Topics: FS: FAT
People: Frodo Looijaard, H. Peter Anvin, Hirofumi Ogawa, Andries Brouwer
Frodo Looijaard said:
I have created and attached a new version of my old-style FAT filesystem
patch, this time for the 2.6.0 kernel. It can also be found on http://
debian.frodo.looijaard.name/.
Some old implementation of the FAT standard mark the end of the directory
file index by inserting a filename beginning with a byte 00. All entries
after it should be ignored, even though they are not marked as deleted. At
least some EPOC releases (an OS used on Psion PDAs, for example) still use
this policy.
The included patch adds the `oldfat' mount option for FAT-based
filesystems. Without it, doing an 'ls' on old-style FATs will show a lot of
garbage, both old files that have been deleted, and bogus entries that have
never been filled.
If you do not use the `oldfat' mount option, FAT filesystems should work
exactly as before. I have been very careful not to change the logic of the
FAT driver, in order not to break anything. In fact, the patch could
probably be optimized a bit, but I wanted to keep it as risk-free as
possible.
It should be safe to mount a normal FAT filesystem with the `oldfat' mount
option. I have been doing that on and off with some local Win98 filesystems
without any trouble. Actually, the only reason I have introduced the mount
option is to keep the new logic strictly seperated from the old driver.
All feedback would be very welcome. This patch is released under the GPL.
Feel free to include it in stock kernels.
Debian users can install the .deb on http://debian.frodo.looijaard.name and
have the patch applied automatically when compiling 2.6.x kernels.
H. Peter Anvin replied, "It's not just "old implementations" -- it's the spec."
He went on, "After reaching a filename beginning with 00, no further data
should be assumed to be in that filesystem. MS-DOS itself would only do that
when formatting the filesystem, so *all* the subsequent entries would be
assumed to start with 00, but that doesn't really seem to be to spec." Hirofumi
Ogawa replied:
The new cluster for directory entries must be initialized by 0x00. And,
when the directory entry is deleted, the name[0] is updated by 0xe5 not
0x00.
So, if the name[0] is 0x00, it after, all bytes in cluster is 0x00.
The fat driver can stop at name[0] == 0x00, but this is just optimization.
The behavior shouldn't change by this.
H. Peter replied:
I looked at the spec, and yes, that is how the spec reads:
If DIR_Name[0] == 0x00, then the directory entry is free (same as for
0xE5), and there are no allocated directory entries after this one (all of
the DIR_Name[0] bytes in all of the entries after this one are also set to
0). The special 0 value, rather than the 0xE5 value, indicates to FAT file
system driver code that the rest of the entries in this directory do not
need to be examined because they are all free.
I guess the original poster has found filesystems which have a 0 followed
by garbage. In cases like that, the cardinal rule for FAT is WWDD (What
Would DOS Do)... since I'm pretty sure DOS stops examining at that point,
we should do the same.
It's the same thing as with using 0xF8 for ending clusters; it's correct
according to spec, but WWDD says 0xFF is the right thing.
Hirofumi replied:
The new cluster for directory entries must be initialized by 0x00. This is
required by spec.
If cluster has garbage, the fat driver needs to do such the following part.
Stop at DIR_Name[0] == 0 is not enough, and I don't think DOS does this.
Frodo replied that if the new cluster for directory entries really did require
an 0x00 intialization, it meant that EPOC filesystems violated that
specification. He added, "As I said, I *think* it is safe to have my patch
always applied (that is, stop when DIR_Name[0] == 0, and be careful to add a
new DIR_Name[0] = 0 entry when new entries are added at the back). It would
conform to the standard. But I would not really be surprised if there was yet
another FAT implementation somewhere out there that breaks the standard in some
other subtle way, which works now but exhibits problems with my patch. That is
why I made it a mount option." Hirofumi replied:
"stop when DIR_Name[0] == 0" should be added after cleanup. The option is
not needed.
Honestly, I wouldn't like to add the "add a new DIR_Name[0] = 0" part. The
option is added easy, but it is not removed easy. And we must maintain it.
(BTW, looks like that patch is buggy)
Those stuff makes a change of the normal path difficult really. At the same
reason, I removed the fat_cvf stuff.
Frodo said he'd be willing to maintain the patch separately for those who
needed it; and asked what bugs Hirofumi had seen. Hirofumi said a separate
patch would be best; and he went into some details on problems with Frodo's
patch. This prompted Frodo to release a new patch, saying:
I have attached a newer, better behaving version of my patch:
+ Implements new mount option oldfat for FAT-derived filesystems.
+ Stops scanning dirs when DIR_Name[0] = 0 when oldfat is set
+ Writes a 0 to the next entry DIR_Name[0] when overwriting an entry
which has DIR_Name[0] = 0 when oldfat is set
It has been tested with both msdos and vfat filesystems and seems to work
well (unlike the patch of a few days ago, which had some issues).
Once you get around to cleaning up the code and making the
stop-scanning-dirs-on-zero the default way, the patch can be shrunken to
include only the third item.
H. Peter objected again, "Please don't call this "oldfat". There is nothing
about this which is "old-style"; it's a workaround for a bug in a specific OS."
Andries Brouwer also said in response to the new patch:
The DOS situation is not so much that 0 is an end-of-dir marker. It marks
that this entry, and all following entries, has never been used.
For the time being there is no justification for "oldfat". The only place
where this behaviour has been reported (not only by you, I saw several
references) is on Psion PDAs. So "psion" would be a more obvious name, if a
mount option is needed.
And maybe no mount option is needed.
Your 2nd and 3rd points can be done always, I think, unless our FAT code
should mimic the DOS FAT behaviour (on non-DOS filesystems).
Shortly thereafter Frodo posted a new patch, saying:
another update of the patch, which addresses some of the reactions and
concerns which I got in reply:
+ The mount option is now called `epoc' instead of `oldfat'
+ fat_search_long now jumps directly to EODir when it finds a zero-marked
entry (it took some hard looking, but I belief this is safe).
+ fat_readdirx logic is slightly simplified (but can't jump to EODir on a
zero-marked entry, regrettably).
Thanks for your feedback!
I'll try to keep this patch up-to-date with new 2.6 kernels. The latest
version can always be found on http://debian.frodo.looijaard.name/
3. Encrypted Filesystem; User-Space Filesystem
26 Jan - 2 Feb (14 posts) Archive Link: "Encrypted Filesystem"
Topics: BSD: FreeBSD, BSD: NetBSD, Extended Attributes, FS: Coda, FS: NFS, FS:
ext3, FS: ramfs, OOM Killer, Version Control, Virtual Memory
People: Michael A Halcrow, Mark Borgerding, Felipe Alfaro Solana, Pavel Machek
, Adam Sampson, Andy Isaacson, Jan Harkes, Miklos Szeredi, Erez Zadok
Michael A Halcrow said:
I have some time this year to work on an encrypted filesystem for Linux. I
have surveyed various LUG's, tested and reviewed code for currently
existing implementations, and have started modifying some of them. I would
like to settle on a single approach on which to focus my efforts, and I am
interested in getting feedback from the LKML community as to which approach
is the most feasible.
This is the feature wish-list that I have compiled, based on personal
experience and feedback I have received from other individuals and groups:
+ Seamless application to the root filesystem
o Layered over the entire root filesystem
o Unencrypted pass-through mode with minimal overhead
o Files are marked as ``encrypted'' or ``unencrypted'' and treated
accordingly by the encryption layer
+ Key->file association
o As opposed to key->blkdev or key->directory granularity
o No encryption metafiles in directories, instead placing that
information into Extended Attributes
o May break some backup utilities that are not EA-aware; may require
another mode where encryption metadata is stored in a header block
on the encrypted file
o Directories can be flagged as ``encrypted-only'', where any new
files created in that directory are, by default, encrypted, with
the key and permissions defined in the directory's metadata
o Processes may have encryption contexts, whereby any new files they
create are encrypted by default according to the process'
authentication
o Make as much metadata about the file as confidential as possible
(filesize, executable bit, etc.)
+ Pluggable encryption (I wouldn't mind using a block cipher in CTR mode)
+ Authentication via PAM
o pam_usb
o Bluetooth
o Kerberos
o PAM checks for group membership before allowing access to certain
encrypted files
+ Rootplug-based LSM to provide key management (necessary to use LSM?)
+ Secret splitting and/or (m,n)-threshold support on the keys
+ Signatures on files flagged for auditing in order to detect attempts to
circumvent the encryption layer (via direct modifications to the files
themselves in the underlying filesystem)
+ Ad-hoc groups for access to decrypted versions of files
o i.e., launch web browser, drop group membership by default (like
capability inheritance masks) so that the browser does not have
access to decrypted files by default; PAM module checks for group
membership before allowing access (explicit user authorization on
application access requests)
+ Userland utilities to support encrypted file management
+ Extensions to nautilus and konqueror to be able to use these utilities
from a common interface (think: right-click, encrypted)
+ Distro installation integration
+ Transparent shredding, where the underlying filesystem supports it
+ Versioning and snapshots (CVS-ish behavior)
+ Design to work w/ SE Linux
These are features that have been requested, but are not necessarily hard
requirements for the encrypted filesystem. They are just suggestions that I
have received, and I am not convinced that they are all feasible.
There are several potential approaches to an encrypted filesystem with
these features, all with varying degrees of modification to the kernel
itself, each with its own set of advantages and disadvantages.
Options that I am aware of include:
+ NFS-based (CFS, TCFS)
o CFS is mature
o Performance issues
o Violates UNIX semantics w/ hole behavior
o Single-threaded
+ Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)
o Newer solutions, not as well accepted or tested as CFS
o KDE team is using SSHFS+FUSE
+ Loopback (cryptoloop) encrypted block device
o Mature; in the kernel
o Block device granularity; breaks most incremental backup
applications
+ LSM-based
o Is this even possible? Are the hooks that we need there?
+ Modifications to VFS (stackable filesystem, like NCryptfs)
o Very low overhead claimed by Erez Zadok
o Full implementation not released
o Key->directory granularity
o Evicts cleartext pages from the cache on process death
o Uses dcache to store attaches
o Other niceties, but it's not released...
My goal is to develop an encrypted filesystem ``for the desktop'', where a
user can right-click on a file in konqueror or nautilus and check the
``encrypted'' box, and all subsequent accesses by any processes to that
file will require authentication in order for the file to be decrypted. I
have already made some modifications to CFS to support this functionality,
but I am not sure at this moment whether or not CFS is the best route to go
for this.
I have had requests to write a kernel module that, when loaded,
transparently starts acting as the encryption layer on top of whatever root
filesystem is mounted. For example, an ext3 partition may have encrypted
files strewn about, which are accessible only after loading the module (and
authenticating, etc.).
Mark Borgerding had a number of comments; among them he said, "Per-file
signatures will severely affect random access performance. Changing 1 byte in a
1 GB file would require the whole thing to be reread." Felipe Alfaro Solana
suggested, "What about calculating signatures on a per-block basis instead?"
And Pavel Machek replied, "Hmm, having md5's in indirect blocks would be very
nice for detecting cable problems ;-). That's usefull even without encryption."
Elsewhere, Adam Sampson took the opportunity to point out that a user-space
filesystem mechanism would allow a lot of cool stuff if it were included in the
kernel. Since a variety of user-space filesystem implementations existed, he
asked why none had yet been included. This would help enable encryption, and
also "network filesystems, various sorts of specialised caching (such as Zero
Install), automounter-like systems, prototyping and so on." Andy Isaacson
pointed out, "There are a lot of subtle and not-so-subtle problems in this
space. For example, I really liked the paging example given in section 3.1 of
"A toolkit for user-level file systems", David Mazieres, Proceedings of the
2001 USENIX Technical Conference available at http://www.fs.net/sfswww/
pubs.html" Jan Harkes also replied to Adam, saying:
Ehh, Coda's kernel module does just that. It is used by the userspace cache
manager of the Coda Distributed File System.
http://www.coda.cs.cmu.edu/
But several other projects seem to be using it,
http://uservfs.sourceforge.net/
http://dav.sourceforge.net/
The interface to userspace a bit clumsy to work with, but there are kernel
modules for FreeBSD/NetBSD/Solaris and an experimental one for Windows 2000
/NT/XP, which makes any significant changes a bit of a pain.
It does have it's pecularities, reads and writes are not passed up to
userspace, only the open and close VFS calls. This makes the module
reasonably quite simple as it doesn't have to deal with VM issues and it
isn't susceptible to deadlocks,
app wants to read data from a file ->
userspace application requires memory allocation to provide this data ->
VM tries to write out dirty data associated with the Coda mountpoint ==
deadlock
So whole file caching keeps the kernel module more portable and simplifies
the userspace code. But it makes things like streaming reads/writes or
quotas impossible. If you want to provide encryption there you would have
to store an unencrypted copy of every open file somewhere on disk or in
ramfs/tmpfs and incur the cost of (de)crypting (and (de)compressing)
whenever it is opened or closed.
Jean-Luc Cooke felt that encrypted loopback already solved this; but there was
no discussion.
Elsewhere, Miklos Szeredi also replied to Andy, saying:
I'm planning on submitting FUSE for inclusion into 2.7 (and maybe 2.6 if
that is acceptable). I feel that FUSE has been maturing lately with some
very interesting applications (http://www.inf.bme.hu/~mszeredi/fuse/
Filesystems) .
Here are the reasons for _not_ including it:
1. There are already two filesystems in kernel that are perfectly usable
for this purpose: NFS and CODA
2. There are currently two competing userspace filesystem layers that have
about the same "market share": LUFS and FUSE. Why should we prefer one
over the other
I'll try to refute myself on these points:
1. Both NFS and CODA were designed for something different. IOW they are
not optimized for the purpose of supporting userspace filesystems. NFS
is slow and there are problems with coherency of the underlying and the
mounted filesystem. CODA does not support random file access (or even
streaming), only reading whole files. It also has a miriad of small
problems when used for exporting a userspace fs (I've been personally
burned many times while doing AVFS over CODA).
2. This one is harder to get rid of, especially because I don't want to
delve into the technical merits of one or the other (I'd be a bit
biased). But I have compared both the kernel interface and the library
API of LUFS and FUSE and they are very similar. And that is a good
thing, because it makes possible to support LUFS filesystems with the
FUSE kernel module and vica versa.
Pavel pointed to the deadlock described above by Jan, and asked how FUSE dealt
with that problem. Miklos replied:
1. In FUSE normal writes go through the cache, so no dirty pages are
created. The only possibility to create dirty pages is with shared
writable mapping, and this is rare
2. Userspace filesystem app can be multithreaded, so probably write can be
satisfied even if read is pending.
3. The 2.6 kernel provides asynchronous page writeback, so even if a
writeback is blocking forever the VM will continue to try to free up
memory.
4. If no memory can be freed, then the allocation will fail, so the read
will fail: no deadlock.
5. Even if the memory allocation was caused by a page fault, which cannot
fail, the worst case is that the OOM killer is invoked, and memory is
freed up: no deadlock.
So with the asynchronous page writeback mechanism the 2.6 kernel is very
immune to this kind of deadlock. I have tested this with a little program
which behaves very nastily in this respect (I can send you this if you're
interested). And I was able to invoke the OOM killer if there was no swap,
but there was never a deadlock.
Pavel was impressed, and there was some speculation on ways Miklos' description
might possibly break down; but nothing conclusive came out of it.
4. UDF Write Support For DVD And CD Media Under 2.6
28 Jan - 30 Jan (6 posts) Archive Link: "Status of UDF write on DVD-R(W) and
CD-R(W) disks?"
People: Jeremy Jackson, Peter Osterlund
Stephen Anthony asked about the status of UDF write support on DVD and CD
media, specifically, incremental write support, so that these media would
behave like write-only hard drives. Jeremy Jackson suggested, "Google for
packet-patch. I've had this for about 9 months, although I don't use it much,
and it doesn't work well with Adaptec/Roxio direct-CD." Stephen replied that
that solution was only for 2.4 kernels, while he was looking for something to
use under 2.6. Peter Osterlund replied, "Patches for 2.6 are available here: (
http://w1.894.telia.com/~u89404340/patches/packet/2.6/) http://w1.894.telia.com
/~u89404340/patches/packet/2.6/" .
5. Some Discussion Of Hyperthreading Implementation
29 Jan - 3 Feb (14 posts) Archive Link: "[PATCH] 2.6.1 Hyperthread smart
"nice""
Topics: Assembly, Hyperthreading, SMP
People: Con Kolivas, Ingo Molnar
Con Kolivas said:
this is not the "right way" to do it, but it works here and now for those
who have P4HT processors.
A while back we had an lkml thread about the problem of running low
priority tasks on hyperthread enabled cpus in SMP mode. Brief summary: If
you run a P4HT in uniprocessor mode and run a cpu intensive task at nice
+20 (like setiathome), the most cpu it will get during periods of heavy
usage is about 8%. If you boot a P4HT in SMP mode and run a cpu intensive
task at nice +20 then if you run a task even at nice -20 concurrently, the
nice +20 task will get 50% of the cpu time even though you have a very high
priority task. So ironically booting in SMP mode makes your machine slower
for running background tasks.
This patch (together with the ht base patch) will not allow a priority >10
difference to run concurrently on both siblings, instead putting the low
priority one to sleep. Overall if you run concurrent nice 0 and nice 20
tasks with this patch your cpu throughput will drop during heavy periods by
up to 10% (the hyperthread benefit), but your nice 0 task will run about
90% faster. It has no effect if you don't run any tasks at different "nice"
levels. It does not modify real time tasks or kernel threads, and will
allow niced tasks to run while a high priority kernel thread is running on
the sibling cpu.
http://ck.kolivas.org/patches/2.6/2.6.1/experimental/. There are other
patches that go with it which is why these have slight offsets but should
work ok.
After some discussion, public and private, Con said:
Criticism was laid at the previous patch for the way a more "nice" task
might never run on the sibling cpu if a high priority task was running.
This patch is a much better solution.
What this one does is the following; If there is a "nice" difference
between tasks running on logical cores of the same cpu, the more "nice" one
will run a proportion of time equal to the timeslice it would have been
given relative to the less "nice" task. ie a nice 19 task running on one
core and the nice 0 task running on the other core will let the nice 0 task
run continuously (102ms is normal timeslice) and the nice 19 task will only
run for the last 10ms of time the nice 0 task is running. This makes for a
much more balanced resource distribution, gives significant preference to
the higher priority task, but allows them to benefit from running on both
logical cores.
This seems to me a satisfactory solution to the hyperthread vs nice
problem. Once again this is too arch. specific a change to sched.c for
mainline, but as proof of concept I believe it works well for those who
need something that works that they can use now.
http://ck.kolivas.org/patches/2.6/2.6.1/experimental/
The stuff on my website is incremental with my other experiments, but the
attached patch applies cleanly to 2.6.1
Ingo Molnar was very impressed with this basic rule, saying, "the higher prio
task will get at least as much raw (unshared) physical CPU slice as it would
get without HT." Con replied:
Glad you agree.
From the anandtech website a description of the P4 Prescott (next
generation IA32) with hyperthreading shows this with the new SSE3
instruction set:
"Finally we have the two thread synchronization instructions ???
monitor and mwait. These two instructions work hand in hand to improve
Hyper Threading performance. The instructions work by determining
whether a thread being sent to the core is the OS??? idle thread or
other non-productive threads generated by device drivers and then
instructing the core to worry about those threads after working on
whatever more useful thread it is working on at the time."
At least it appears Intel are well aware of the priority problem, but full
priority support across logical cores is not likely. However I guess these
new instructions are probably enough to work with if someone can do the
coding.
Ingo replied:
these instructions can be used in the idle=poll code instead of rep-nop.
This way idle-wakeup can be done via the memory bus in essence, and the
idle threads wont waste CPU time. (right now idle=poll wastes lots of
cycles on HT boxes and is thus unusable.)
for lowprio tasks they are of little use, unless you modify gcc to sprinkle
mwait yields all around the 'lowprio code' - not very practical i think.
Con was revolted by that prospect, and said:
Looks like the kernel is the only thing likely to be smart enough to do
this correctly for some time yet.
Nick, any chance of seeing something like this in your sched domains? (that
would be the right way unlike my hacking sched.c directly for a specific
architecture).
But Ingo replied:
no, there's no way for the kernel to do this 'correctly', without further
hardware help. mwait is suspending the current virtual CPU a bit better
than rep-nop did. This can be exploited for the idle loop because the idle
loop does nothing so it can execute the rep-nop. (mwait can likely also be
used for spinlocks but that is another issue.)
user-space code that is 'low-prio' cannot be slowed down via mwait, without
interleaving user-space instructions with mwait (or with rep-nop).
this is a problem area that is not solved by mwait - giving priority to
virtual CPUs should be offered by CPUs, once the number of logical cores
increases significantly - if the interaction between those cores is
significant. (there are SMT designs where this isnt an issue.)
6. Linux 2.4.25-pre8 Released
29 Jan - 30 Jan (3 posts) Archive Link: "Linux 2.4.25-pre8"
Topics: Disks: SCSI, FS: CIFS, FS: smbfs, Power Management: ACPI, USB
People: Marcelo Tosatti
Marcelo Tosatti announced 2.4.25-pre8, saying:
This release contains a big USB merge, architecture updates (Alpha, SPARC,
x86/64), SCSI driver updates (cpqarray and MPT fusion), smbfs support for
CIFS Unix extensions and large files (backported from 2.6), "ACPICA" merge
and ACPI fixes, merge jgarzik's net driver fixes, amongst others.
This is probably the last -pre.
7. PC300 Update For 2.6
30 Jan (1 post) Archive Link: "[PATCH] PC300 update"
Topics: Ioctls
People: Marcelo Tosatti, Linus Torvalds
Marcelo Tosatti said to Linus Torvalds:
This patch forward ports a few important fixes from the 2.4 driver. This
changes have been well tested.
Please apply.
Changelog:
+ Update maintainer email address
+ Mark pci_device_id list with __devinitdata.
Greg: rmk and hch checked this and found no problem. A bunch of other
drivers are doing the same.
+ Set correct protocol type on packet receive (this caused the kernel to
drop all packets received)
+ Add #ifdef DEBUG around debug printk()
Greg, Christoph: dprintk()/etc would be nice, but we're not trying a
rewrite here. Yes its ugly but its consistent with the rest. Maybe we can
do it for the whole driver, later on.
+ ioctl: Add missing size checks before copying data from userspace.
8. Linux 2.6.2-rc3 Released
30 Jan - 1 Feb (3 posts) Archive Link: "Linux 2.6.2-rc3"
Topics: FS: XFS, Hot-Plugging, Power Management: ACPI, USB
People: Linus Torvalds
Linus Torvalds announced 2.6.2-rc3, saying:
The bulk of this is an ACPI update, but there's USB, ia-64, i2c, XFS and
PCI hotplug updates here too.
Please don't send in anything but critical fixes until after the final
2.6.2 release.
9. Netwosix Linux Distribution Version 1.0 Released For Kernel 2.6.1
31 Jan (2 posts) Archive Link: "ANNOUNCEMENT: Linux Netwosix 1.0 with Kernel
2.6.1 is released"
Topics: BSD
People: Vincenzo Ciaglia
Vincenzo Ciaglia said:
It's my pleasure to announce that Linux Netwosix 1.0 is released and runs
the kernel 2.6.1 by default. It seems to be the first linux distro with
this kernel. I'm hopeful on this kernel. Linux Netwosix is a powerful and
optimized Linux distribution for servers and Network Security related jobs.
It can be also used for special operations as penetration test with its big
collection of softwares and sources security oriented. It's a ligh
distribution created for the requirements of every SysAdmin and it's very
portable and highly configurable. Our philosophy is to give a big liberty
of configuration to the SysAdmin. Only in this way he/she can configure a
powerful and stable server machine. Linux Netwosix have also a powerful
ports system +(Nepote) similar to the xBSD systems but more flexible and
usable.
Here the announcement release:
http://www.netwosix.org/announce.html
10. Input Drivers FAQ For 2.6
1 Feb - 2 Feb (32 posts) Archive Link: "2.6 input drivers FAQ"
Topics: Bug Tracking, Power Management: ACPI, USB
People: Vojtech Pavlik, Jesse Barnes
Vojtech Pavlik documented:
Common problems and solutions with 2.6 input drivers:
Problems:
How do I get a list of the input devices in my system?
How can I check that the input drivers have found my devices correctly?
Solution:
'cat /proc/bus/input/devices' and 'dmesg' are your friends here. The first
lists all devices known to the input core with their properties, and the
latter shows the messages from boot. There you can spot any errors that
happened in the probing process.
Problems:
I'm getting double clicks when I click only once.
My scroll wheel scrolls by two lines/screens instead of one.
My mouse moves too fast.
Solution:
Check your XFree86 config file.
You probably have two "mouse" entries there, one pointing to /dev/psaux and
the other to /dev/input/mice, so that you can get both your PS/2 and USB
mouse working on 2.4.
2.6 uses the input subsystem for both PS2 and USB, and thus both devices
will report events from both mice, resulting in doubled events.
Remove either the /dev/psaux or /dev/input/mice entry, depending what suits
you better for 2.4 compatibility should you ever need go back to 2.4.
Problems:
My mouse wheel is not working in X.
My Logitech (MousManPS/2) mouse stopped working in X.
My extra buttons don't work in X.
Solution:
Check your XFree86 config file.
Make sure the mouse protocol is set to "ExplorerPS/2", as that is what the
2.6 kernel exports to applications regardless of the real mouse type.
Make sure you have an "ZAxisMapping 4 5" entry.
Make sure you have an entry for remapping the extra buttons above 5.
Problem:
Kernel reports:
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/
serio0).
atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Solution:
Well, the kernel means what it says. XFree86 boldly goes and accesses the
keyboard controller registers when it starts up. This is a bad thing to do,
as it can conflict with the kernel using these registers at the same time.
The kernel spots this and complains, and in most cases is not affected by
the problem.
So, unless you are an XFree86 developer and can fix X, ignore this message.
Problem:
I get the message above, but I'm not running X.
Solution:
Other applications (for example kbdrate) may also access the keyboard
controller. This will trigger the same message.
Fix your application / utility or ignore the message.
Problem:
My multimedia keys don't work at all and instead emit a message like this:
atkbd.c: Unknown key pressed (translated set 2, code 0x83 on isa0060/
serio0).
atkbd.c: Use 'setkeycodes e003 <keycode>' to make it known.
atkbd.c: Unknown key released (translated set 2, code 0x83 on isa0060/
serio0).
atkbd.c: Use 'setkeycodes e003 <keycode>' to make it known.
Solution:
Do what the kernel says. Use the setkeycodes utility with the suggested
scncode value. For the keycode value, look into /usr/include/linux/input.h,
where is a list of all defined Linux keycodes.
Then you can verify that the keyboard works correctly by using the evtest
program:
evtest /dev/input/event#
Where # is the number of the input device that is your keyboard.
Problem:
setkeycodes refuses to work with keycodes above 127.
Solution:
Get a recent version of the kbd package, and recompile on a 2.6 kernel.
Problem:
Ok, evtest shows everything correctly, but I get incorrect keysyms assigned
to these keys in XFree86.
Solution:
While the 2.6 kernel tries to use the "standard" scancodes as much as
possible, it is not posible for all keys.
A good solution is to modify the XKB keyboard definition to match the
scancodes one can obtain from 'showkeys -s', after the above problem is
solved and the keys work in evtest.
An better solution would be to write a kernel-2.6 keyboard definition, as
the scancodes are the same for every type of keyboard, independend of the
hardware. This is called hardware abstraction.
A perfect solution would be to get X to use the event protocol. If you're
an XFree86 developer, you might consider this.
Problem:
My PC Speaker is not beeping anymore in 2.6.
Solution:
Enable it in the kernel config. Go to Drivers->Input->Misc->PC Speaker.
Problem:
My Synaptics touchpad lost the ability of tap-to-click, scroll, etc.
Solution:
The easy solution is to pass psmouse.proto=imps on the kernel command line,
or proto=imps on the psmouse module command line. This will restore 2.4
behavior.
A better solution is to download the new XFree86 Synaptics driver that
cooperates with the input drivers nicely, from:
http://w1.894.telia.com/~u89404340/touchpad/index.html
This will allow you to configure the behavior of the touchpad in detail and
give you all the features it can do, including palm detection and similar.
In case you want to get this running at the console, too, an updated GPM
package can be found here:
http://www.geocities.com/dt_or/gpm/gpm.html
Problem:
When I switch my KVM, my PS/2 mouse goes all crazy.
Solution:
Use psmouse.proto=bare on the kernel command line, or proto=bare on the
psmouse module command line.
Problem:
I'm getting these:
psmouse.c: PS/2 mouse at serio0 lost synchronization, throwing 2 bytes
away.
Solution:
Check your mouse cable. If this only happens when you move your mouse in a
certain way, fix the mouse cable or replace the mouse.
Check your kernel and harddisk settings. This message can also happen when
the mouse interrupt is delayed more than one half of a second. Make sure
DMA is enabled for your harddrive and CD-ROM. Kill your ACPI/APM battery
monitoring applet. Try disabling ACPI, frequency scaling. Make sure your
time is ticking correctly, often with frequency scaling it gets unreliable.
Even if you're using the ACPI PM Timer as a clock source - actually this
often leads to the above problem.
Problem:
My keyboard autorepeat is not as snappy as it used to be in the 2.5 series.
Solution:
Use atkbd.softrepeat=1 on the kernel command line, or "softrepeat=1" on
atkbd module command line. This will enable kernel internal repeat
generation, which is much more flexible and allows higher repeat rates and
shorter repeat delays than the keyboard itself does.
Problem:
kbdrate doesn't work when I use atkbd.softrepeat.
Solution:
Get an up-to-date version of the kbd package. Recompile on 2.6.
Problem:
I've read through the whole file, and it did not help me at all!
Solution:
Either you didn't have any problem in the first place, or it's something
that is not very often and thus not listed. Try contacting the driver
author/maintainer, the kernel mailing list, or enter the problem into the
Linux kernel bugzilla.
Jesse Barnes was overjoyed to see this document, and immediately found a
solution to one of his long-term problems.
11. Support For IBM RSA Service Processor
2 Feb - 3 Feb (4 posts) Archive Link: "[PATCH] Driver for IBM RSA service
processor (1/2)"
Topics: FS: sysfs
People: Max Asbock
Max Asbock said:
Here is a device driver for the IBM xSeries RSA service processor. The
ibmasm driver is mainly intended to be used in conjunction with a user
space API and systems management applications that need to get in-band
access to the service processor, such as sending commands or waiting for
events. For the remote video feature the driver relays remote mouse and
keyboard events to user space. By itself the driver also allows the OS to
make use the UART on the service processor board as a regular serial line.
The user interface to the driver is a custom file system. It does not use
sysfs since the operations on the files are somewhat beyond the one file /
one value rule for sysfs. Since it is not strictly a char driver I put it
into the drivers/misc directory.
12. Some UML Fixes For 2.6.2-rc3-mm1
3 Feb (1 post) Archive Link: "[patch] uml-fixes-2.6.2-rc3-mm1-A2"
Topics: User-Mode Linux
People: Ingo Molnar
Ingo Molnar said:
the attached patch fixes UML on 2.6.2-rc3-mm1:
+ generic: dmapool.o depends on CONFIG_PCI
+ x86: reshuffle the way TASK_SIZE is defined on x86. [UML relied on a
specific order of definitions within the x86 header files, the 4/4
patch broke this assumption.]
+ UML: sys_call_table.c: syscall layout changed
+ UML: um_arch.c: handle_sysrq() changed
UML compiles & works fine with this patch applied.
13. udev 016 Released
3 Feb (9 posts) Archive Link: "[ANNOUNCE] udev 016 release"
Topics: FS: devfs, FS: sysfs, Hot-Plugging
People: Greg KH
Greg KH said:
I've released the 016 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-016.tar.gz (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-016.tar.gz)
rpms built against Red Hat FC1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-016-1.i386.rpm (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-016-1.i386.rpm)
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-016-1.src.rpm (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-016-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 (http://www.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 (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs)
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.