I tried this fix on my SuSE 10.3 system (2.6.22.5-29 kernel) and it didn't work. The system froze on boot. I think there might be more to it. Scott -

Hi Ingo, After applying the fix to try_to_wake_up() I was still seeing some large latencies for realtime tasks. Some debug code pointed out two additional causes of these latencies. I have put fixes into my 'old' kernel and the scheduler related latencies have gone away. I'm pretty confident that one of these bugs still exist in the latest RT patch set. Not so sure about the other. But, I wanted to describe in detail so that you could address in the latest version of the code if applicable. ...

-

-hiroyasu ohyama I wonder what corrected attached source makes good performance of getting page slot cluster from page area discripter which is written "si" in the source codes. Because I think head of swap_list_t discripter doesn't suggest index of swap area which is same priority that swap_list.next but one which is the highest priority in the priority's list. the si->swap_map which have high priority may be chosen by get_swap_page(), so that page slot of low priority's swap area may hav...

From: Randy Dunlap <randy.dunlap@oracle.com> Update dontdiff, based on .gitignore patches from Pete Zaitcev and Adrian Bunk. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- Documentation/dontdiff | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- linux-2.6.23-rc9-git3.orig/Documentation/dontdiff +++ linux-2.6.23-rc9-git3/Documentation/dontdiff @@ -42,6 +42,9 @@ *.9.gz .* .cscope +.gitignore +.mailmap +.mm 53c700_d.h 53c7xx_d.h 53c7xx_u.h ...

Try echo -n "10b5 9016" > /sys/bus/pci/drivers/serial/new_id and let Russell King (rmk+serial@arm.linux.org.uk) know if it works (or if it doesn't, for that matter). -- Nicholas Miell <nmiell@comcast.net> -

1) I just rebased libata-dev.git and all its branches. If you are unfamiliar with git rebasing, this means you must either re-clone, or force-update your branch like this: # grab latest nv-swncq branch URL=git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git cd /local/repo/libata-dev git-checkout master # or any branch other than what # is being updated git-fetch -f $URL nv-swncq:nv-swncq # force update of 'nv-swncq' 2) libata ACPI support has been turned on by default...

Colored kernel message output Let's work more on Linux's cuteness! [http://lkml.org/lkml/2007/10/4/431] The following patch makes it possible to give kernel messages a selectable color which helps to distinguish it from other noise, such as boot messages. NetBSD has it, OpenBSD has it, FreeBSD to some extent, so I think Linux should too. Inspired by cko (http://freshmeat.net/p/cko/), but independently written, later contributed forth and back. Already posted at: [ message continues ]

ANSI: \e[31m R-- \e[32m G-- \e[33m RG- (yellow) \e[34m --B \e[35m R-B (magenta) \e[36m -GB (cyan) \e[37m RGB (white) ASCII: 1 --B blue 2 -G- green 3 -GB cyan 4 R-- red ... e.g. just the other way around. 0x17 is gray-on-blue, what I use, Since I do not use 512-glyph fonts, I do not know. I suppose no, since that is what is written in the manpages or so. With FB where the hardware draws the font, I do not know either, I suppose yes. With FB where the software draws th...

Start up QBasic, issue COLOR 1 => blue. Apply said patch, issue vt.printk_color=0x01 => you get what? So! :) -

I like it. A somewhat related nice feature would be to print different loglevels with different colors. Cheers, Emil. -

Indeed it should be 0x07, should it go in. Otherwise the openbsd camp might start another flamewar. (On a personal note, would 0x1F work better for you?) -

Ah you seem to be a proponent of http://www.blackgoogle.com/ then :-) Unfortunately, it seems like Xft uses Grayscale AA (http://antigrain.com/research/font_rasterization/index.html) so black background make the font look thinner. -

"Ha, ok, I see where you're going with this one." This patch is perfectly suited to reduce heat at home and in the server room, especially during kernel development and debugging, but the average kernel usage already pays off. Just add vt.printk_color=0x08 and all your kernel messages and oopses will be printed using low-power electrons. Extremely useful on SGI Altix 4700, which does print a lot (number of CPU cores), or SunFire X4500 (number of disks). Even if not using one of these systems, C...

standard x86: ---LSB-- ---2SB-- ---3SB-- ---MSB-- [bytes] LITTLE_ENDIAN M765432L M765432L M765432L M765432L [bits] ?_BITFIELD (Not sure what bitfield type, but I'd guess BIG_ENDIAN_BITFIELD) standard sparc: ---MSB-- ---3SB-- ---2SB-- ---LSB-- [bytes] BIG_ENDIAN M765432L M765432L M765432L M765432L [bits] ?_BITFIELD (I hope I got these two right) Theoretical machine with BIG_ENDIAN but LITTLE_ENDIAN_BITFIELD: ---MSB-- ---3SB-- ---2SB-- ---LSB-- L234567M L234567M L234567M L234567M - ...

No it is not. That makes no sense. The whole point of little endian is that you store LSB, then 2SB, then 3SB, then MSB and then when the CPU reads this as a 32-bit word it rotates them all around so that in the CPU register you have: MSB_3SB_2SB_LSB M765432L_M765432L_M765432L_M765432L That is what little endian means and that is how shift operations can work fine on the CPU. Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Suppo...

That is a property of how the device is wired to the bus. The cpu will always put a value of 128 on the bus such that D7 = 1 and D0-D6 = 0. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -

This is always the same. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -

Well yes, that's why I'm asking. I'm not concerned about data from just the CPU's perspective. I'm writing a driver that talks to hardware that has a shift register. The register can be shifted either left or right, so all the bits obviously have to be in order, but it can be either order. What I want to do is to have the driver detect when byte-endianness doesn't match bit-endianness when it writes the the word to a memory-mapped device. I think I can do that like this: #if (defined...

Then I don't understand that point of defining __LITTLE_ENDIAN_BITFIELD. What does it mean for a C-level bitfield ordering to be little-endian if the processor is BIG_ENDIAN? -- Timur Tabi Linux Kernel Developer @ Freescale -

What does it mean for a C-level bitfield ordering to be little-endian if the It makes no sense because a bitfield is something having to do with a 'C' compiler and it must NEVER be used as a template to address hardware! 'C' gives no guarantee of the ordering within machine words. The only way you can access them is using 'C'. They don't have addresses like other objects (of course they do exist --somewhere). They are put into "storage units," according to the standard, and these storage un...

.../... (snipped horror use of bitfields) Bitfields are wrong. Period. Don't use them. __LITTLE_ENDIAN_BITFIELD vs. __BIG_ENDIAN_BITFIELD is Linux way to cope with existing code using them that needs fixing on architectures that have C bitfields in reverse order but that's not even something that can be properly relied upon generally. Just don't use bitfields and be happy. Ben. -

Please pull from 'upstream-davem' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem to receive the following updates: Auke Kok (2): e1000e: fix debugging printout code e1000e: Fix ethtool register test code Frank Blaschka (1): qeth: EDDP does not work on large MTUs Klaus D. Wacker (2): qeth: HiperSockets layer-3 interface drop non IPv4 or non IPv6 packets lcs: Channel errors drive lcs_recovery which leads to kernel p...

This series of patches adds a -t option to checkpatch, so it can print terse messages one per line, in a format compatible with g/cc (filename:linenumber:message). This format can be parsed by various tools and editors that can help show the errors in one window and the offending file+line in another window. This patch series also introduces a new small shell script wrapper, called scripts/checkfiles, that checks the compliance of source files (not in diff format); the script can operate on any ...

Such terse output complies with g/cc and looks like file_name:line_number:error_message This output can be easily parsed within text editors (e.g., emacs/vim) that can produce a split text screen showing in one screen the error message, and in another screen the corresponding source file, with the cursor placed on the offending line. Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu> --- scripts/checkpatch.pl | 20 ++++++++++++++++---- 1 files changed, 16 insertions(+), 4 deletions(-) ...