Arnd pointed me at anon_inode_getfd(), and the code annoyed me enough to send this patch. Mainly because the init routine carefully checks for errors, then panics (because we shouldn't run out of memory at boot). Unfortunately, it's actually worse than simply oopsing, where we'd know what had failed. Davide, please consider parts of this patch, at least. Cheers, Rusty. ---- 1) anon_inode_inode can be read_mostly, same as anon_inode_mnt. 2) The IS_ERR(anon_inode_inode) check is unneeded, sin...

The powerpc kernel stacks need to be naturally aligned, as they contain the thread info at the bottom, which is obtained by clearing the low bits of the stack pointer. However, when using 64K pages (the stack is smaller than a page), we use kmalloc to allocate it, which doesn't provide that guarantee. It appeared to work so far... until one enables SLUB debugging which then returns unaligned pointers. Ooops... This patch fixes it by using a slab cache with enforced alignment for those. It repl...

Hi, following 2.6.25-rc more closely now, I'm running yesterday's git version. The first boot was fine, then the box crashed due to disk errors. During the next bootup, it barfed a few times with: Device '2-2' does not have a release() function, it is broken and must be fixed. ------------[ cut here ]------------ WARNING: at drivers/base/core.c:119 kobject_release+0x42/0xa0() Modules linked in: fuse sg sr_mod twofish_i586 twofish_common eeprom w83l785ts asb100 hwmon_vid hwmon usb_storage zd1211r...

Extend the logging of "AR evt_bus_reset, link internal" to "AR evt_bus_reset, generation ${selfIDGeneration}". That way we can check whether this generation matches the one seen in self ID complete event logging. See OHCI 1.1 clause 8.4.2.3. Also extend logging of "firewire_ohci: * selfIDs, generation *" by "local node ID ffc*" in self ID logging to make the local node in AT/AR event logs more obvious. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- drivers/firewire/fw-oh...

Use asmlinkage_protect in sys_io_getevents, because GCC for i386 with CONFIG_FRAME_POINTER=n can decide to clobber an argument word on the stack, i.e. the user struct pt_regs. Here the problem is not a tail call, but just the compiler's use of the stack when it inlines and optimizes the body of the called function. This seems to avoid it. Signed-off-by: Roland McGrath <roland@redhat.com> --- fs/aio.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/fs/aio.c b/fs/...

i also have such a drive (damn, if i knew that saving some Watts would hurt...) - and i measured ~100 load_cycle_count per hour, which is _way_ to much, imho. if we trust the spec, the disk would be dead after ~1year. it seems that "intellipark" is not that intelligent as it should be and a little bit too agressive. from what i have found, the time for parking the heads is much below the linux kernel flush interval (which seems to be at 30secs), so i think the best thing to do is tuning either dirty...

Both are unused and the functions rdtscll() and __cycles_2_ns() don't have side-effects. Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de> --- arch/x86/kernel/tsc_32.c | 4 ---- arch/x86/kernel/tsc_64.c | 4 ---- 2 files changed, 0 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/tsc_32.c b/arch/x86/kernel/tsc_32.c index 82602d7..0406b80 100644 --- a/arch/x86/kernel/tsc_32.c +++ b/arch/x86/kernel/tsc_32.c @@ -84,7 +84,6 @@ DEFINE_PER_CPU(unsigned long, cyc2ns);...

Shift of a le value seems strange, probably meant to shift the cpu-order variable as in the prvious section of the switch statement. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- lib/lzo/lzo1x_decompress.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/lzo/lzo1x_decompress.c b/lib/lzo/lzo1x_decompress.c index 9dc7056..77f0f9b 100644 --- a/lib/lzo/lzo1x_decompress.c +++ b/lib/lzo/lzo1x_decompress.c @@ -158,7 +158,7 @@ match: t += 7 + ...

The heaviest users of the lzo code I know of are little-endian ARM devices through jffs2. When the code was merged there was a lot of discussion about the best way to handle the endian issues and unaligned accesses and whilst I seem to remember someone posting big-endian test results it could have been before some of the later changes were made. So yes its possible its not been run on BE until now or that isn't a common code path. I've checked this against the external LZO library its based on an...

When converting in tree users to my proposed unaligned byteswapping api. See the 8 patch series posted today to linux-arch. Harvey --

payload_offset/payload_length are used by loaders for nonstandard You can look at the payload headers for that. -hpa --

Sorry, I don't understand. -hpa --

The size of the unzip payload you get by looking at the last four bytes of the gzip payload (after verifying the existence of a gzip magic number.) For more specific details, look at the ELF segment headers. -hpa --

No, the last four bytes of a gzip image is the uncompressed length. A bootloader which wants the uncompressed ELF file length (as opposed to the individual ELF segments) can get it that way. -hpa --

Always use ->OUTBSYNC method for executing commands so the posting is done if needed (this affects only pmac and scc_pata host drivers at the moment). Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/ide-floppy.c | 3 ++- drivers/ide/ide-io.c | 3 ++- drivers/ide/ide-iops.c | 2 +- drivers/ide/ide-probe.c | 6 +++--- drivers/ide/ide-tape.c | 3 ++- drivers/scsi/ide-scsi.c | 6 ++++-- 6 files changed, 14 insertions(+), 9 deletions...

Hi, The x86 git tree, as of HEAD commit commit a9efd1225e6e0e78ceeaecc04cec1d428eb8173f Author: Mike Travis <travis@sgi.com> Date: Fri Apr 4 18:30:16 2008 -0700 x86: modify Kconfig to allow up to 4096 cpus doesn't want to work on one of my testboxes (x86-64 desktop, AMD-based). First, the X server doesn't want to start (it says it couldn't mmap the framebuffer). Second, if I try to suspend the box to RAM, it enters a state it cannot leave until power is physically cut from...

It's an Athlon 64 X2 on an ULi-based AsRock motherboard with Radeon X300SE I'll try to figure out what is the last good commit. Thanks, Rafael --

Attached. Thanks, Rafael

btw., Xorg works fine here on a comparable AMD system - but i use a rather new distro (Fedora 8) which has Xorg 7.2. Ingo --

Another infinite loop, this one involving both client and server. Basically what happens is that on the server nlm_fopen() calls nfsd_open() which returns -EACCES, to which nlm_fopen() returns NLM_LCK_DENIED. On the client this will turn into a -EAGAIN (nlm_stat_to_errno()), which in will cause fcntl_setlk() to retry forever. I _think_ the solution is to turn NLM_LCK_DENIED into ENOLCK for blocking locks, as NLM_LCK_BLOCKED is for the contended case. For testing the lock leave NLM_LCK_DENIED ...

Duh... Sorry, EAGAIN is indeed the correct return value for fcntl() when the lock attempt failed. I should have reread the manpage/posix spec before replying. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com --

Apologies, that was indeed a behavioral change introduced in a commit The assumption must have been that -EAGAIN could only mean that we needed to keep blocking, and hence was a nonsensical return from a filesystem lock method that waited itself for the lock to become available--such a method would return 0, -EINTR (or some more exotic error), or continue waiting. If we agree that EAGAIN is actually a legimate error to return from a blocking lock, then, yes, we need take ->lock() back out of...

You are a winner of the total sum of 500,000.00 GBP & A Toshiba Laptop.Note you are to Forward the Following Informations,Full name,Contact address& Phone Number.do make contact to Mrs.Jossy Bryant Email:toshibadraws1@live.com Regards Tim Heinz ---------------------------------------------------------------- This message was sent using http://webmail.coqui.net --

Michael Kerrisk found out that signalfd was not reporting back user data pushed using sigqueue: http://groups.google.com/group/linux.kernel/msg/9397cab8551e3123 The following patch makes signalfd to report back the ssi_ptr and ssi_int members of the signalfd_siginfo structure. Signed-off-by: Davide Libenzi <davidel@xmailserver.org> - Davide --- fs/signalfd.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) Index: linux-2.6.mod/fs/signalfd.c =============...

On Thu, 10 Apr 2008 11:57:44 -0700 (PDT) I queued this for both 2.6.25 and 2.6.24.x. Agree? --