I know that many feel that ide-scsi is useless, and should go away. And you are probably tired of message threads talking about it. Yet I ask respectfully that you hear me out, and give me feedback.

I need ide-scsi to survive. Why? I maintain osst, a driver for OnStream tape drives, which need special handling. These drives exist in SCSI, ATAPI, USB and IEEE1394 versions.

One high-level driver, osst, handles all of them, and that's how it should be, right? For ATAPI, it relies on ide-scsi.

(By the way, ide-tape contains code for the ATAPI version, the DI-30, but that code is old and has serveral known problems - I'd like to see it removed - or at least deprecated - I will do that myself later if people want me to.)

So can we agree to keep ide-scsi? I know it is not desired any more for cd writers. To avoid the problem reports from people who don't realize that and select ide-scsi anyway, we can refuse to attach to a cd-type device (today it just warns). And/or make a new explicit module parameter to tell ide-scsi exactly which drives to attach to.

Today, ide-scsi is buggy, and that needs fixing. The underlying problem is that ide-scsi stands with one leg in the IDE world and one leg in the SCSI world, which creates the challenge to make the IDE error recovery work in sync with, and under the direction of the SCSI error handler.

Example bug reports are [1], [2], [3], [4], [5], and [6].

A recurring problem is scheduling while atomic, see [1], [5], [7]. Linus points bluntly to the problem in [7]. I plead guilty to having introduced that code segment in [8]. I later attempted to improve on the error handling in [9], but that patch was not accepted (and wouldn't have fixed that particular problem).

[6] is different, and has me baffled - what can evoke a page fault in idescsi_transfer_pc?

In the spirit of cleaning up one's own mess, I am working on a new patch, to hopefully alleviate the problems. I've made liberal use of the attachments to the osdl bug reports [1]-[4] created by Mike Christie and a patch from Philip Auld [10], to give credit where it is due. I've also looked at ide-cd to see what it does differently.

Please look at the attachment (looking past the touch-ups that I made while I was at it...). Am I moving in the right direction? Specific changes I need advise on:

1. timer expiry
   attachments to [1]-[4] and [10] suggest using it. Is it useful to buy some more time? I don't see the point to wait longer. By returning 0, I let ide_timer_expiry do its thing to handle lost (dma) interrupts. By seeting the PC_TIMEDOUT flag, I tell our end_request function to return DID_TIME_OUT to the scsi system.
2. ide (atapi) abort/error
   By providing ide-scsi's own error/abort functions, I defer all errror handling to the scsi error handlers. I have nagging doubts about totally removing ide_do_reset() calls from them though :-(
3. scsi (eh) abort/error
   These take much inspiration from Mike Christie's work on [1]-[4] The eh_abort gets called first, and takes an opportunistic approach (if the problem resolves itslf, great). The eh_error pulls the carpet from under the request, and does the ide_do_reset(). I hope I've not introduced any new locking/scheduling issues :-)

I've tested the patched ide-scsi with 2.6.0 - and it works fine. Too good actually, meaning the new error routines have not been adequately exercised. Any hints as to how to simulate errors at the ide subsystem level? Something like Stephen Tweedie's testdrive [11] perhaps (if applicable to char device), but for 2.6?

Linus states in [7] that ide-scsi needs a maintainer. I haven't seen anyone step forward, so that leads me to believe I may be the only person that depends enough on ide-scsi to be motivated?

If people will have me, I am prepared to take on that responsibility. I am just concerned that I may not have enough of a variety of devices to be able to thoroughly test it (unless the DI-30 is the only one :-)). What do people see as the requirements to be able to maintain ide-scsi?

OK, let me have it... Thanks, Willem Riede.

References:
[1] http://bugme.osdl.org/show_bug.cgi?id=393
[2] http://bugme.osdl.org/show_bug.cgi?id=829
[3] http://bugme.osdl.org/show_bug.cgi?id=1335
[4] http://bugme.osdl.org/show_bug.cgi?id=1381
[5] http://marc.theaimsgroup.com/?l=linux-kernel&m=107103475609592&w=2
[6] http://marc.theaimsgroup.com/?l=linux-scsi&m=105334942001271&w=2
[7] http://marc.theaimsgroup.com/?l=linux-kernel&m=107150176124047&w=2
[8] http://marc.theaimsgroup.com/?l=linux-scsi&m=104051080518591&w=2
[9] http://marc.theaimsgroup.com/?l=linux-scsi&m=104361480527780&w=2
[10] http://marc.theaimsgroup.com/?l=linux-scsi&m=107115248030218&w=2
[11] http://people.redhat.com/sct/patches/testdrive/

The hotplug CPU code introduces two major problems:

1. Threads which previously never stopped (migration thread, ksoftirqd, keventd) have to be stopped cleanly as CPUs go offline.
2. Threads which previously never had to be created now have to be created when a CPU goes online.

Unfortunately, stopping a thread is fairly baroque, involving memory barriers, a completion and spinning until the task is actually dead.

There are also three problems in starting a thread:

1. Doing it from a random process context risks environment contamination: better to do it from keventd to guarantee a clean environment, a-la call_usermodehelper.
2. Getting the task struct without races is a hard: see kernel/sched.c migration_call(), kernel/workqueue.c create_workqueue_thread().
3. There are races in starting a thread for a CPU which is not yet online: migration thread does a complex dance at the moment for a similar reason (there may be no migration thread to migrate us).

Place all this logic in some primitives to make life easier: kthread_create(), kthread_start() and kthread_destroy(). These primitives require no extra data-structures in the caller: they operate on normal "struct task_struct"s.

Other changes:

• Expose keventd_up(), as keventd and migration threads will use kthread to launch, and kthread normally uses workqueues and must recognize this case.

there are two mechanisms I (and some others) felt were missing from the equally nifty workqueue stuff:

1. one-shot threads
2. keventd overflow

For #1, your patch seems to cover that nicely.

For #2, that's to be used for situations where (a) you need a thread context _and_ (b) you simply cannot wait for keventd to become available (since there are no time guarantees).

available via Bitkeeper at <bk://smurf.bkbits.net/linux-2.6-mm>.

If you use this tree, please consider dropping me a note or whatever; I don't like to work in a vacuum...

The way I've built this, in case anybody's curious:

• undo all the changes in 2.6.0-mm2 but not in 2.6.1-rc1-mm1.
• merge with 2.6.1-rc1, resolved nine conflicts.
• Apply all patches in 2.6.1-rc1-mm2 but not in 2.6.0-mm2. Some didn't apply fully, for whatever reason.
• Generate a diff between 2.6.1-rc1 and top-of-tree. Use interdiff -p1 to compare that to Andrew's official patch. (There were none, which was somewhat surprising.)

Oh yes, I've stopped prefixing the patch tags with mm[12]; that would get too confusing in the long run.

Right now, compiling a 2.6.0-mm1 (what I had handy) with the 3.3 gcc on my Pentium system for arch i386 generates 1386 signed and unsigned warnings, of the two kinds:

   warning: signed and unsigned type in conditional expression
   warning: comparison between signed and unsigned

A patch that resolved these 1386 warnings would (1) generate more crap than it cleaned up, (2) immediately result in adding more bugs than removed, and (3) due to the crap level rising, generate more bugs long term than it avoided.

This is the third release of the -tiny kernel tree. The aim of this tree is to collect patches that reduce kernel disk and memory footprint as well as tools for working on small systems. Target users are things like embedded systems, small or legacy desktop folks, and handhelds.

Latest release includes:

• sync against 2.6.1-rc1
• latest netdrvr patchkit
• SLOB allocator
• Andi Kleen's bloat-o-meter
• configurable tcpdiag, inetpeer, dnotify, ptrace, sysenter/vsyscall
• configurable X86 CPU feature detection
• ability to override arch CFLAGS from Kconfig
• optional uninlining of current and thread_info
• other minor tweaks

The big bit here is SLOB, which optionally replaces the SLAB allocator and kmalloc wrappers with a traditional malloc arena and a SLAB emulation layer. SLOB is less than a tenth the size of the SLAB code and is considerably more space efficient with its allocations, but is not as fast and may prove less resistant to long-term fragmentation.

Thanks to Andi Kleen, Magnus Naeslund, and various others for their contributions and suggestions.

The patch can be found at:

http://selenic.com/tiny/2.6.1-rc1-tiny1.patch.bz2
http://selenic.com/tiny/2.6.1-rc1-tiny1-broken-out.tar.bz2

Contributions and suggestions are encouraged. In particular, it would be helpful if people with non-x86 hardware could take a stab at extending some of the stuff that's currently only been done for X86 to other architectures.

I have a 386 I really should try this out on.

Of note IPv4 is about 90K compressed. And I know you can do a minimal IPv4 stack in about 8K compressed.

My target is a minimal kernel that can be used as a bootloader. But what I am looking for at first is to be able to turn as many things off as possible so that we can test to see how much individual pieces add.

If you look at ELKS or one of the old unix like kernels you can get those down to 64K and still be usable.

I'm currently looking at removing the buffer cache, since I most of the time I don't care about disks. This is complicated by the fact that many of the default paths in the kernel when they don't have a better implementation use buffer cache methods. But I'm making headway.

Proc is one of things that frequently has loads of crap that are not needed in a minimal setup.

Until I find more candidates to turn off I can't see any low hanging fruit for shrinking in size.

I have a new set of input patches, could you take look at them?

1. i8042-suspend.patch
   Add suspend methods to i8042 to restore BIOS settings on suspend and kill polling timer which sometimes prevents APM suspend
2. i8042-options-parsing.patch
   psmouse-options-parsing.patch
   atkbd-options.parsing
   Complete conversion to the new way of parsing parameters. Drop "i8042_", "psmouse_" and "atkbd_" prefixes from option names when compiled as a module and require "i8042.", "psmouse." and "atkbd." prefixes if built into the kernel.
3. missing-module-license.patch
   Maple and newton keyboard drivers were missing MODULE_LICENSE("GPL")
4. kconfig-synaptics-help.patch
   Suggest psmouse.proto=imps to Synaptics users who do not want install native XFree Synaptics driver so taps would still work
5. sis-aux-port.patch
   Do not ignore AUX port if chipset fails to disable it when we do probes as SiS is having trouble disabling but otherwise mouse works fine.

The patches are on top of 2 other input patches (remove jitter and ps2 emulation) that I have sent to the list earlier. You can find the complete set of patches at http://www.geocities.com/dt_or/input/2_6_0-rc1/ and http://www.geocities.com/dt_or/input/2_6_0-rc1-mm1/

We are glad to announce the USAGI STABLE RELEASE 5, dated on January 4th, 2004. This is the last major STABLE release based on linux-2.4 kernel from USAGI Project. Our primary target of development is moved to linux-2.6 kernel.

Changes from the STABLE RELEASE 4.1 are:

• based on linux-2.4.21,
• IPsec transport/tunnel mode support,
• Mobile IPv6 support,
• fixed interaction between IPsec and Mobile IPv6,
• Default Router Preference Support, and
• Route Information Option Support.

However, the IPsec and Mobile IPv6 implementations included in this STABLE release may not developed further. Because the IPsec stack was written for linux-2.4 kernel by USAGI Project and currently we have rewritten NEW IPsec stack for linux-2.6 kernel and the stack is included linux-2.6 mainline kernel. The IPsec stack included linux-2.6 kernel is implemented based on "xfrm" architecture and we will continue developing based on the NEW IPsec stack.

The Mobile IPv6 stack is the same situation as the IPsec. The Mobile IPv6 stack included in this release is developed by HUT GO Project and the stack is mainly written for linux-2.4 kernel. Currently USAGI Project and GO Project have started joint project for developing new Mobile IPv6 stack based on linux-2.6 kernel.

You can get our complete kit which includes kernel tree, library and applications from <ftp://ftp.linux-ipv6.org/pub/usagi/stable/kit/>.

We also provide separate patches against the main-line kernel and the tools <ftp://ftp.linux-ipv6.org/pub/usagi/stable/split/>.

Many of our efforts are already in mainline kernel tree. We will continue making reasonable size patches and trying to merge it into mainline kernel tree.

We announce the latest information on our web pages. Please check our web site <http://www.linux-ipv6.org>.

We also manage the mailing lists for USAGI users. If you have questions, please join the mailing list. Comments and advises are also welcome on that mailing list. Please visit <http://www.linux-ipv6.org/ml/> for further information.

I have a version stable for the KT400 chipset, it is the KT600 which is unstable now. As soon as I finish resolving the issues one of my customers is having with the KT600, it will be released shortly there after.

Some of the problems appear with the APIC routing and interrupts being lost and not begin processed.

This release fixes a few critical problems in 2.4.23, including fixes for two security bugs.

Upgrade is recommended.

I've just packaged up the latest Linux hotplug scripts into a release, which can be found at:
http://sourceforge.net/project/showfiles.php?group_id=17679

Or from your favorite kernel.org mirror at:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_01_05.tar.gz
or for those who like bz2 packages:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_01_05.tar.bz2

I've also packaged up some pre-built (and signed) Red Hat FC 1 based rpms:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_01_05-1.noarch.rpm
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-base-2004_01_05-1.noarch.rpm

The source rpm is available if you want to rebuild it for other distros or versions of Red Hat at:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_01_05-1.src.rpm
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_01_05-1.src.rpm

The main web site for the linux-hotplug project can be found at:
http://linux-hotplug.sf.net/
which contains lots of documentation on the whole linux-hotplug process.

This release is recommended for _anyone_ using the 2.6.0 and beyond kernels who is still using hotplug scripts older than 2003_08_05, as a number of changes have been made in order to support the 2.6 kernel properly.

The release is still backwards compatible with 2.4, so there is no need to worry about upgrading.

Moving on with the 2.4.24-pre tree, here is 2.4.25-pre4.

It contains an ext2/3 update (mostly forward compatibility related), the usual architecture updates (this time S390, PPC64/32, SH), osst update, TG3 bugfixes, amongst others.

Some of the fixes listed in this changelog (the rtc fixes, the IrDA "log buster" fix and the netfilter MASQUERADE oops) were already in other -pre's, they got removed and re added for technical BK reasons.

we should _never_ make anything volatile. There just isn't any reason to. The compiler will never do any "better" with a volatile, it will only ever do worse.

If there are memory ordering constraints etc, the compiler won't be able to handle them anyway, and volatile will be a no-op. That's why we have "barrier()" and "mb()" and friends.

The _only_ acceptable use of "volatile" is basically:

• in _code_ (not data structures), where we might mark a place as making a special type of access. For example, in the PCI MMIO read functions, rather than use inline assembly to force the particular access (which would work equally well), we can force the pointer to a volatile type.

  Similarly, we force this for "test_bit()" macros etc, because they are documented to work on SMP-safe. But it's the _code_ that works that way, not the data structures.

  And this is an important distinctions: there are specific pieces of _code_ that may be SMP-safe (for whatever reasons the writer thinks). Data structures themselves are never SMP safe.

  Ergo: never mark data structures "volatile". It's a sure sign of a bug if the thing isn't a memory-mapped IO register (and even then it's likely a bug, since you really should be using the proper functions).

  (Some driver writers use "volatile" for mailboxes that are updated by DMA from the hardware. It _can_ be correct there, but the fact is, you might as well put the "volatile" in the code just out of principle).

That said, the "sure sign of a bug" case has one specific sub-case:

• to paste over bugs that you really don't tink are worth fixing any other way. This is why "jiffies" itself is declared volatile: just to let people write code that does "while (time_before(xxx, jiffies))".

But the "jiffies" case is safe only _exactly_ because it's an atomic read. You always get a valid value - so it's actually "safe" to mark jiffies as baing volatile. It allows people to be sloppy (bad), but at least it allows people to be sloppy in a safe way.

In contrast, "jiffies_64" is _not_ an area where you can safely let the compiler read a unstable value, so "volatile" is fundamentally wrong for it. You need to have some locking, or to explicitly say "we don't care in this case", and in both cases it would be wrong to call the thing "volatile". With locking, it _isn't_ volatile, and with "we don't care", it had better not make any difference. In either case the "volatile" is wrong.

We had absolutely _tons_ of bugs in the original networking code, where clueless people thougth that "volatile" somehow means that you don't need locking. EVERY SINGLE CASE, and I mean EVERY ONE, was a bug.

There are some other cases where the "volatile" keyword is fine, notably inline asm has a specific meaning that is pretty well-defined and very useful. But in all other cases I'd suggest having the volatile be part of the code, possibly with an explanation _why_ it is ok to use volatile there unless it is obvious.

I did a release at long last, it's got proper 2.6 kernel support and all the rest of the stuff that people contributed since 1.0.

It can be downloaded from the usual place:

http://sourceforge.net/projects/avf

I have released kgdb 2.0 for kernel 2.6.0 for i386 and x86_64 architectures at http://kgdb.sourceforge.net.

This version of kgdb has been supported by TimeSys Corporation and Storad Inc. It contains code from kgdb patches maintained by Andrew Morton (George Anzinger), Andi Kleen and Jim Housten.

Significant changes since previous version:

1. This version contains three patches: architecture specific patches for i386 and x86_64 and a common patch.
2. Automatic loading of modules in gdb is available on x86_64 platform now. Debugging of modules, including those in initrd, should be trivial with this feature.
3. Hasslefree detach and reconnect from gdb possible on x86_64 platform also.
4. New format of kgdb kernel command line options: kgdbwait, kgdb8250.
5. Shadow thread to get backtraces lost when gdb can't go beyond do_IRQ.
6. Uses new thread list packet qf instead of qL. This fixes the thread information loss previous versions of kgdb had.

iostat v2.0 is out!

It works flawlessly on both 2.4 & 2.6, compiles on Debian, Redhat, you name it... IOW, it's perfect. :)

Looks something like this:

                             extended device statistics
device mgr/s mgw/s    r/s    w/s    kr/s    kw/s   size queue   wait svc_t  %b
hde        0  3530    5.0   92.0    20.2 14597.8  150.6  68.1  563.2   6.0  58
hdg        0     0    0.0    0.0     0.0     0.0    0.0   0.0    0.0   0.0   0
hda        0   105  159.6   69.4   637.7   812.9    6.3  56.0  176.4   4.1  95

Find it on: http://linux.inet.hr/

We really should, but there really are some rare cases where it is actually ok.

In particular, you _can_ do math, if you just do the proper "kernel_fpu_begin()"/"kernel_fpu_end()" around it, and you have reason to believe that you can assume a math processor exists.

Is it needed? I dunno. I'd frown on it in general, but I don't see it being fundamentally wrong under the rigth circumstances.

• Some rework to the mt-ranier CDROM support and ATAPI access to MO drives. Could anyone who uses these please retest.
• A fix for loop-on-ext2-on-cdrom. Also needs testing please.

• A significant amount of work on remap_file_pages() from Ingo. Most notably, we now support per-page protections within a single VMA. This is aimed at UML and similar specialised applications which are presently forced to allocate one VMA per page.

  Anyone who is interested in remap_file_pages(), please test.

  This adds a new syscall and breaks all non-ia32 architectures. Instructions as to how to unbreak them is in the remap_file_pages-prot-2.6.1-H2 patch.

• The remap_file_pages non-blocking infrastructure has been used to implement prefaulting of minor faults for mappings. This will reduce the kernel's minor fault rate by up to a factor of eight and has been shown to offer a few percent speedup on some things.

  This needs serious benchmarking please. Tests which involve short-lived processes.

  The remap_file_pages work will probably live in -mm for a while. It needs careful review - alterations to largely unused code paths are a concern because of the potential for long-lived security and DoS holes.

• Added an implementation of RAID6 from Peter Anvin. Usage information is available in the Kconfig help for the feature. I'm sure he'd like to hear of testing results.
• There's a fix for the Radeon framebuffer card here which we're a bit wobbly about. if you have such a thing, please send a report.
• Significant amount of rework of the ACPI PM timer source patch. I'm not sure that I got all the right patches in the right place. John and Dominik, please double-check.
• Added the latest code drop from DRM CVS. People who use DRM, please test it.

This is an update of the memory hot removal patch. As I'll merge this patch over Goto-san's hotplug patch (http://marc.theaimsgroup.com/?l=linux-kernel&m=107214532922184&w=2), this will be the final version in this standalone form. When that is done, there will be no more zone_active checks in page allocation code.

Changes from the previous version (dated 20031126) are:

• Implemented remapping of mlock()'d pages. This is done by adding an argument to try_to_unmap() function to be able to ignore VM_LOCKED bit.
• Hacks to make kswapd more aggressive on disabled zones were removed. Remapping and swapping out should be used together to make system performance impact caused by memory hot removal low. I think switching remapping and swapping out based on whether pages are on active lists or inactive lists is an easy and acceptable solution. There may be better threshold, and the above idea may be inappropriate for systems where the cost of memcpy is very high.
• Bugfixes. truncate detection, page dirty bit handling, more PageAgain handling.

Known problems:

• If a page is in mapping->io_pages when remap happens, it will be moved to dirty_pages. Tracking page->list to find out the list which page is connected to would be too expensive, and I have no other idea.
• It seems there's a very small possibility of race between remap and move_from_swap_cache. I've added some code for this, but it is essentially untested.

I guess many of you think this patch has no use for yourselves, but it was at least useful for finding some kind of kernel memory leaks. :)

http://people.valinux.co.jp/~iwamoto/mh.html contains some patch explaination and usage info. This page hasn't changed much since the last post.

I just implemented a patch which allow us to allocate huge continuous pages easily. As We know it's very hard to allocate them on demand, since free memory on system may be fragmented. My approach is that I let annoying pages move to another place so that we can make free coninuous space on memory. Iwamoto's memory-hot-removal patch will help to do it.

I believe moving pages approach will be much better than random swaping page out approach for this purpose.

iwamoto> This is an update of the memory hot removal patch.
iwamoto> http://people.valinux.co.jp/~iwamoto/mh.html

My patch needs the iwamoto's memory-hot-removeval patch. You should apply both of them against linux-2.6.0.

Known problems:

• This patch doesn't work if CONFIG_HUGETLB_PAGE isn't set. Does anybody have good idea to solve it, since it's difficult to know whether a specified page is free or a part of a large continuous page without PG_compound flag.

ToDos:

• It's hard to allocate HugePages for hugetlbfs on a box which dosen't have HighMem zones yet.
• We will make some continuous pages allocation work at the same time.

The Linux Test Project test suite <http://www.linuxtestproject.org> has been released. The latest version of the testsuite contains 2100+ tests for the Linux OS. Our web site also contains other information such as: test results, a Linux test tools matrix, technical papers and HowTos on Linux testing, and a code coverage analysis tool.

Developers from the Linux Test Project co-authored the whitepaper, "Putting Linux Reliability to the Test". This article documents the test results and analysis of the Linux kernel and other core OS components, including everything from libraries and device drivers to file systems and networking, all under some fairly adverse conditions, over a period of 60 days. You can find the paper at: http://www.ibm.com/developerworks/linux/library/l-rel

Release Highlights:

• Code cleanups by Erik Andersen, Glen Foster, Jay Turner, and Ming Gao.
• Removal of a memory leak in one of the test harness libraries by Randy Hron.
• Improvements to allow tests to build and execute under more environments and distributions.

We encourage the community to post results to ltp-results@lists.sf.net, and patches, new tests, or comments/questions to ltp-list@lists.sf.net.

Just received my tenth complaint this year about the fact that kbd and recent kernels disagree as to what the right keycodes are. Since I maintain kbd it follows that recent kernels are broken.

What is right?

The old Linux convention is that for 1-88 keycode equals scancode. Above that things are a bit messy, mainly because the 128 scancodes xx and the 128 escaped scancodes e0 xx and the single combination e1 1d 45 are put into 127 keycodes, and that doesnt fit.

OK. So we want at least to preserve this 1-88 range, and may worry about the rest later. All common keys should keep their keycode. See also setkeycodes(8).

2.6 does first an untranslate and then a map to keycode, so the fact that keycode equals (translated) scancode now becomes atkbd_set2_keycode[atkbd_unxlate_table[i]] == i for i=1,...,88.

Looking at 2.6.0 we see a single mistake: scancode 84 is translated incorrectly. And many Japanese complained. Looking at 2.6.1-rc1 we see two mistakes: also scancode 85 is now mistranslated.

So, I think the change of 2.6.1-rc1 was not necessarily an improvement, but 2.6.0 needs a fix.

I can look at the details, but perhaps Vojtech wants to comment.

I won't argue that the 2.6.1-rc situation is correct, but I'll describe it and the difference from 2.4:

1. Keycode 84.

   On 2.4, keycode 84 is the SysRq keycode, since historically AT keyboards do emit a different keycode for SysRq than form PrintScreen, although they're on the same key.

   On 2.6, there is only one keycode for PrintScreen, in an attempt to be a bit saner, and that is 99. And here comes my mistake - since 84 was not used anymore, I used it for the "103rd" European key.

   The 103rd key usually produces either backslash-bar or hash-tilde, or other national combo. I believe that 2.4 did emit keycode 43 for it, since this keyboard is treated the same as backslash by AT Set 2 keyboards, in hardware.

   USB keyboards, and Set 3 keyboards, however differentiate between this key and the real backslash, and since there also can be the real backslash in addition to this key on the keyboard, it makes sense to allocate a scancode to it.

   Now my snafu was that I allocated a 2.4-used scancode to it, and one that is mapped to SAK in 2.4 keymaps usually.

   This bites French, British and probably Brazilian people, too.

   I'm open to suggestions about how to fix it.

2. Keycode 85.

   Scancode 85 (translated, set2) at the moment is not mapped to any keycode. There are other scancodes that are not mapped at all, only known scancodes are mapped, the rest should be changed by the user.

   Keycode 85 is defined as F13 (in keymaps), and is mapped to scancode 93 (both in atkbd.c and keyboard.c), which is F13, according to Microsoft documentation, which was used as reference, since that's what keyboard manufacturers tend to follow nowadays.

3. Japanese and Korean keys.

   2.6 has unified support for Japanese and Korean keys on both USB and PS/2 keyboards.

   The keycodes are defined as:

   KEY_INTL1  181  /* Romanji */
   KEY_INTL2  182  /* Hiragana / Katakana */
   KEY_INTL3  183  /* Yen */
   KEY_INTL4  184  /* Henkan */
   KEY_INTL5  185  /* Muhenkan */
   KEY_INTL6  186  /* PC9800 KP , */
   KEY_LANG1  190  /* Hanguel */
   KEY_LANG2  191  /* Hanja */
   KEY_LANG3  192  /* Katakana */
   KEY_LANG4  193  /* Hiragana */
   KEY_LANG5  194  /* Zenkaku / Hankaku */

   These keycodes are translated back to the PS/2 scancodes in raw mode.

   The problem here lies in that that all the keycodes are above 128, and are different from what 2.4 used for these keys on an AT keyboard.

   We could go back to the 2.4 layout, where the keycodes are scattered where there was space in the translated set2 scancode list, and not even all fit there, but I think that way lies madness. The 2.6 layout is based on the USB HUT definition.