Sorry for late. Dmesg get no errors /informations vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 303444 53224 360132 0 0 276 157 627 814 5 2 89 4 0 0 0 302956 53228 360332 0 0 196 0 1193 1686 2 2 95 1 0 0 0 303204 53228 360332 0 0 0 0 1175 1544 2 1 97 0 1 0 0 234656 53240 428880 0 0 ...

System hangs suggest a problem with the drive controller. However this "kernel BUG" is something newly introduced in 2.6.20 which should be fixed in 2.6.20.1. Patch is below. If you still get hangs with this patch installed, then please report detail, and probably copy to linux-ide@vger.kernel.org. NeilBrown Fix various bugs with aligned reads in RAID5. It is possible for raid5 to be sent a bio that is too big for an underlying device. So if it is a READ that we pass stright down ...

If the look like this, you might want to try a few patches that are in -mm. ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: soft resetting port We thought that Robert had fixed these with some changes that went into -rc6. But they reappeared a few days later, the -mm patches seem to have finally cured it. The original ...

This report is valid only if ndiswrapper was never loaded from booting to the error. Please post the report to linux-usb-devel@lists.sourceforge.net and recompile your kernel with CONFIG_USB_DEBUG. HTH Oliver -

cancel_rearming_delayed_workqueue(wq, dwork) doesn't need the first parameter. We don't hang on un-queued dwork any longer, and work->data doesn't change its type. This means we can always figure out "wq" from dwork when it is needed. Remove this parameter, and rename the function to cancel_rearming_delayed_work(). Re-create an inline "obsolete" cancel_rearming_delayed_workqueue(wq) which just calls cancel_rearming_delayed_work(). Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> ...

With struct epoll_event { __u32 events; __u64 data; }; this won't work on s390. offsetof(struct epoll_event, data) is 8 on both 31 bit and 64 bit. So it will do the conversion and corrupt all the data. Actually we would only need the compat conversion for the sigset_t stuff. But then again I thought most 32 bit architectures would add a 4 byte pad between events and data, no? Maybe we need some arch dependent struct compat_epoll_event and have something like #define ...

Linux Kernel Markers : i386 optimization Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- /dev/null +++ b/include/asm-i386/marker.h @@ -0,0 +1,47 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. i386 architecture optimisations. + * + * (C) Copyright 2006 Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + + +#ifdef CONFIG_MARKERS +#define ...

Linux Kernel Markers : Kconfig menus Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- /dev/null +++ b/kernel/Kconfig.marker @@ -0,0 +1,17 @@ +# Code markers configuration + +config MARKERS + bool "Activate markers" + select MODULES + default n + help + Place an empty function call at each marker site. Can be + dynamically changed for a probe function. + +config MARKERS_ENABLE_OPTIMIZATION + bool "Enable marker optimization" + depends on MARKERS + default ...

Linux Kernel Markers, architecture independant code. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -121,6 +121,19 @@ __ksymtab_strings : AT(ADDR(__ksymtab_strings) - LOAD_OFFSET) { \ *(__ksymtab_strings) \ } \ + /* Kernel markers : pointers */ \ + .markers : AT(ADDR(.markers) - LOAD_OFFSET) { \ + VMLINUX_SYMBOL(__start___markers) = ...

From: Robert Hancock <hancockr@shaw.ca> Perhaps you have a point, I'll think about this some more. But on the other hand note that kernel log messages can scroll away and get lost, so you cannot really rely upon them for gathering information which is necessary for properly detecting devices in userspace or anything like that. -

local_t : ia64 extension Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- a/include/asm-ia64/local.h +++ b/include/asm-ia64/local.h @@ -1,50 +1 @@ -#ifndef _ASM_IA64_LOCAL_H -#define _ASM_IA64_LOCAL_H - -/* - * Copyright (C) 2003 Hewlett-Packard Co - * David Mosberger-Tang <davidm@hpl.hp.com> - */ - -#include <linux/percpu.h> - -typedef struct { - atomic64_t val; -} local_t; - -#define LOCAL_INIT(i) ((local_t) { { (i) } }) -#define ...

local_t : parisc cleanup parisc architecture local_t cleanup : use asm-generic/local.h. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- a/include/asm-parisc/local.h +++ b/include/asm-parisc/local.h @@ -1,40 +1 @@ -#ifndef _ARCH_PARISC_LOCAL_H -#define _ARCH_PARISC_LOCAL_H - -#include <linux/percpu.h> -#include <asm/atomic.h> - -typedef atomic_long_t local_t; - -#define LOCAL_INIT(i) ATOMIC_LONG_INIT(i) -#define local_read(v) atomic_long_read(v) -#define ...

local_t : alpha extension Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- a/include/asm-alpha/local.h +++ b/include/asm-alpha/local.h @@ -4,37 +4,115 @@ #include <linux/percpu.h> #include <asm/atomic.h> -typedef atomic64_t local_t; +typedef struct +{ + atomic_long_t a; +} local_t; -#define LOCAL_INIT(i) ATOMIC64_INIT(i) -#define local_read(v) atomic64_read(v) -#define local_set(v,i) atomic64_set(v,i) +#define LOCAL_INIT(i) { ATOMIC_LONG_INIT(i) } +#define ...

local_t : s390 cleanup s390 architecture local_t cleanup : use asm-generic/local.h. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- a/include/asm-s390/local.h +++ b/include/asm-s390/local.h @@ -1,58 +1 @@ -#ifndef _ASM_LOCAL_H -#define _ASM_LOCAL_H - -#include <linux/percpu.h> -#include <asm/atomic.h> - -#ifndef __s390x__ - -typedef atomic_t local_t; - -#define LOCAL_INIT(i) ATOMIC_INIT(i) -#define local_read(v) atomic_read(v) -#define ...

local_t : architecture independant extension Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- a/include/asm-generic/local.h +++ b/include/asm-generic/local.h @@ -33,6 +33,19 @@ typedef struct #define local_add(i,l) atomic_long_add((i),(&(l)->a)) #define local_sub(i,l) atomic_long_sub((i),(&(l)->a)) +#define local_sub_and_test(i, l) atomic_long_sub_and_test((i), (&(l)->a)) +#define local_dec_and_test(l) atomic_long_dec_and_test(&(l)->a) +#define local_inc_and_test(l) ...

local_t : sparc64 cleanup sparc64 local_t cleanup : simply use asm-generic/local.h. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- a/include/asm-sparc64/local.h +++ b/include/asm-sparc64/local.h @@ -1,40 +1 @@ -#ifndef _ARCH_SPARC64_LOCAL_H -#define _ARCH_SPARC64_LOCAL_H - -#include <linux/percpu.h> -#include <asm/atomic.h> - -typedef atomic64_t local_t; - -#define LOCAL_INIT(i) ATOMIC64_INIT(i) -#define local_read(v) atomic64_read(v) -#define ...

atomic.h : Add atomic64 cmpxchg, xchg and add_unless to alpha Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- a/include/asm-alpha/atomic.h +++ b/include/asm-alpha/atomic.h @@ -175,19 +175,62 @@ static __inline__ long atomic64_sub_return(long i, atomic64_t * v) return result; } -#define atomic_cmpxchg(v, o, n) ((int)cmpxchg(&((v)->counter), (o), (n))) +#define atomic64_cmpxchg(v, old, new) (cmpxchg(&((v)->counter), old, new)) +#define atomic64_xchg(v, new) ...

atomic.h : Add atomic64 cmpxchg, xchg and add_unless to x86_64 Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- a/include/asm-x86_64/atomic.h +++ b/include/asm-x86_64/atomic.h @@ -375,8 +375,8 @@ static __inline__ long atomic64_add_return(long i, atomic64_t *v) long __i = i; __asm__ __volatile__( LOCK_PREFIX "xaddq %0, %1;" - :"=r"(i) - :"m"(v->counter), "0"(i)); + :"+r" (i), "+m" (v->counter) + : : "memory"); return i + __i; } @@ -388,7 +388,10 @@ ...

atomic.h : Add atomic64 cmpxchg, xchg and add_unless to parisc Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- a/include/asm-parisc/atomic.h +++ b/include/asm-parisc/atomic.h @@ -6,7 +6,6 @@ #define _ASM_PARISC_ATOMIC_H_ #include <linux/types.h> -#include <asm/system.h> /* * Atomic operations that C can't guarantee us. Useful for @@ -163,7 +162,7 @@ static __inline__ int atomic_read(const atomic_t *v) } /* exported interface */ -#define ...

atomic.h : i386 type safety fix This patch removes an explicit cast to an integer type for the result returned by cmpxchg. It is not per se a problem on the i386 architecture, because sizeof(int) == sizeof(long), but whenever this code is cut'n'pasted to a different architecture (which happened at least for x86_64), it would simply accept passing an atomic64_t value as parameter to cmpxchg, xchg and add_unless, having 64 bits inputs casted to 32 bits. Signed-off-by: Mathieu Desnoyers ...

atomic.h : Add atomic64 cmpxchg, xchg and add_unless to powerpc Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- a/include/asm-powerpc/atomic.h +++ b/include/asm-powerpc/atomic.h @@ -165,7 +165,7 @@ static __inline__ int atomic_dec_return(atomic_t *v) return t; } -#define atomic_cmpxchg(v, o, n) ((int)cmpxchg(&((v)->counter), (o), (n))) +#define atomic_cmpxchg(v, o, n) (cmpxchg(&((v)->counter), (o), (n))) #define atomic_xchg(v, new) (xchg(&((v)->counter), new)) ...

The modifications and bug fixes noted below were done by Realtime Control Works and Contemporary Control Systems, Inc, Jan 2005. They were incorporated into the 2.6 kernel by Jeff Morrow of Sierra Analytics, Feb 2007. <jmorrow@massspec.com> The changes have been tested on a Contemporary Controls PCI20U-4000. Summary of changes: Arc-rawmode.c: rx(): - Fixed error in received packet lengths; 256 byte packets were being received as 257 bytes packets. ...

Yes, this is actually one of the reasons i mentioned sometimes having only a slave drive can be a "legal" way to connect drives. I've lived in Curitiba and Rio for a while (familiar cities to you I guess) and sometimes we just had no choice to yank the master drive out of its bay and keep running with what we had, cause money wasnt exactly growing in trees where I used to work. Next to that, we had the so called "paraguay" quality assembled hardware, which basicly means someone, somewhere put ...

Yea, I guess you're right. For me it isnt a problem, This error message will disappear for me anyway, since I am going to re-add the drive now, like I said yesterday, I am re-adding stuff one by one, to isolate problems. I can just imagine that switching a jumper might not be as easy for everybody, especialy when they bought special front-loading harddisk bays for their disks and all, for the very reason of not having to It's not like it is causing any problems, nothing hangs or slows ...

Hi. It does?! I just did cat /sys/power/disk and it only says platform. How do you make swsusp reboot instead of powering down? Regards, Nigel -

Hi. I'm not sure. I don't use encryption myself, so I don't understand all the fine details. I just know that there are people out there using encryption, loop-aes, dmsetup and all that sort of stuff. I don't have to worry about it because they use an initrd/ramfs to do whatever they need to do to provide access to the device on which the image is found, then echo /dev/whatever_funny_device > /sys/power/suspend2/resume2 Neither am I! Presumably you'd have a lot more than emacs in ...

Hi. The network configuration utilities can help there. In addition, Suspend2 preserves the commandline you used to boot with (/sys/power/suspend2/resume_commandline), so you can use a combination of slightly varying grub entries (I have one for not starting ath0 and one for starting it) and scripts to do different things in different environments. The resume_commandline is writable, so can be cleared People are using Suspend2 with encryption today (I'm not sure about uswsusp). Some of ...

Hi. I'm using M$ hibernation and Suspend2 to dual boot on our desktop (dtv card that Linux doesn't support well yet), and I know other Suspend2 users doing the same. It's made earier by the fact that Suspend2 lets you reboot instead of powering down. As to comparing the speed with the time to boot, your estimates are way out. Both will of course vary with the harddrive and cpu speeds and compression qualities of the image, but with Suspend2, I'm seeing speeds more in the range of ...

You use the encryption patches for suspend. And even if you turn your laptop off and leave it somewhere for a bit I can turn it on install a trojan and turn it off again. Suspend/Resume is supposed to work, many people find it useful. One non suspend friendly driver makes every suspend aware driver on that system useless so we really should be tight about suspend/resume. Alan -

Well, I don't know why you're saying it's a special capability of suspend2. Even the "old" swsusp has been able to do this since I can remember. ;-) Greetings, Rafael -

I disagree. This message can be very helpful. The problem of network interfaces being renamed is a real and frequent one. A single message per interface is tolerable even if you don't actually need it. My kernel log currently produces well over 400 messages per boot, so if you want to reduce kernel log clutter, there are lots of other candidates. --=20 Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten ...

same as on sparc64 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- include/asm-sparc/io.h | 29 +++++++++++++++++++++++++++++ 1 files changed, 29 insertions(+), 0 deletions(-) diff --git a/include/asm-sparc/io.h b/include/asm-sparc/io.h index cab0b85..c23e74a 100644 --- a/include/asm-sparc/io.h +++ b/include/asm-sparc/io.h @@ -256,6 +256,35 @@ extern void iounmap(volatile void __iomem *addr); #define iowrite16(val,X) writew(val,X) #define iowrite32(val,X) writel(val,X) ...

Having a single drive on the channel configured as slave is not really a legal configuration. (I believe the ATA standards say that it's something that a host controller/driver/OS is allowed to support, but it is not required to.) A single drive should always be set to master (and connected to the end of the cable and not the middle, by the way). -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: ...

Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus to receive the following updates: drivers/mmc/sdhci.c | 40 ++++++++++++---------------------------- drivers/mmc/tifm_sd.c | 11 ++++------- drivers/mmc/wbsd.c | 6 +----- 3 files changed, 17 insertions(+), 40 deletions(-) Alex Dubov (1): tifm_sd: treat "status error" as normal command completion Pierre Ossman (4): mmc: wbsd: Remove driver version ...

Found this : # This file assigns persistent names to network interfaces. # See iftab(5) for syntax. eth0 mac 00:11:d8:a9:c0:c2 arp 1 ra0 mac 00:11:d8:b9:27:7e arp 1 As these are no MAC on my machine, I suspect this is the reason for the renaming. I'm trying Olaf's patch to check the message is printed, and next boot is without this crap in this /etc/iftab file. Regards, Paul -

Unfortunately, this patch was not applied to mainline last year. Maybe this year. Keep track about which network interface names were renamed after the network device driver printed its banner. Signed-off-by: Olaf Hering <olaf@aepfle.de> --- linux-2.6.19.orig/net/core/dev.c +++ linux-2.6.19/net/core/dev.c @@ -749,7 +749,11 @@ int dev_change_name(struct net_device *d else if (__dev_get_by_name(newname)) return -EEXIST; else + { + if (strncmp(newname, dev->name, ...

usually distro enable persistent interface naming with udev, check /etc/iftab and see if you have something like /etc/udev/something-iftab.rules regards, Benoit -

Hi, Something unrelated to the tests I am doing. I found out that the libsata driver doesn't really cope or likes the idea that you might have a controller without a master drive configured. In this case on ATA2 I have a CDROM drive, connected as slave. ATA: abnormal status 0x7F on port 0x177 ATA: abnormal status 0x7F on port 0x177 ata2.01: ATAPI, max UDMA/66 ata2.01: configured for UDMA/66 And in another case, I have ATA5 with no drives connected at all: pata_pdc2027x 0000:00:0f.0: ...

-----Original Message----- From: Andrew Morton [mailto:akpm@osdl.org] Sent: Friday, January 26, 2007 2:24 PM To: Satapathy, Soumendu Sekhar Subject: Re: Data Caching Service On Fri, 26 Jan 2007 14:05:04 +0530 hm. But applications can utilise a common cache via shared libraries, and shared memory without involving the kernel. -

As found on some arm defconfigs. I only looked at how original patch changes things and other patches fix compilation. ;-) Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> --- drivers/pcmcia/at91_cf.c | 2 +- drivers/pcmcia/soc_common.c | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) --- a/drivers/pcmcia/soc_common.c +++ b/drivers/pcmcia/soc_common.c @@ -478,7 +478,7 @@ dump_bits(char **p, const char *prefix, * * Returns: the number of characters ...

We implement our own nfsd in user space - so the kernel nfsd (as well as the lockd) are disabled. We need the handle in order to associate a kernel file handle with our own file id. M. -----Original Message----- From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of J. Bruce Fields Sent: Thursday, February 08, 2007 10:12 PM To: Menny Hamburger Cc: linux-kernel@vger.kernel.org Subject: Re: Getting the nfs_fh of a specific file/dir from the ...

Take the "quiet" option off the kernel command line (in /etc/grub.conf) so you can actually see all the messages that are being output. Presumably you haven't selected something that you need in order to mount the root filesystem.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ -

From: Randy Dunlap <randy.dunlap@oracle.com> Teach kernel-doc to handle functions that look like the new pcim_iomap_table(). Fixes this fatal error in scripts/kernel-doc: DOCPROC Documentation/DocBook/kernel-api.xml Error(/tester/linsrc/linux-2.6.20-git6//drivers/pci/pci.c:1351): cannot understand prototype: 'void __iomem * const * pcim_iomap_table(struct pci_dev *pdev) ' make[1]: *** [Documentation/DocBook/kernel-api.xml] Error 1 make: *** [htmldocs] Error 2 Signed-off-by: Randy Dunlap ...

Please explain why not. And please delete large parts of email that are not needed in replies (like the .config). Thanks. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -

We also value feedback and problem reports from testers. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -

I don't see CONFIG_BLK_DEV_INITRD=y Regards, Vito Caputo BTW, this isnt the appropriate place for asking this type of question... > CONFIG_SENSORS_IT8

Doing as I am told, here we go: This is 100% reproducible, ie: just doing a big rsync between 2 disks and burning a DVD at the same time. Note: the system isn't very responsive when this happens, most notably: audio seems to jump every ~1second. Hardware is an ASUS K8N-DL with a pair of Opteron 270s, 4GB PC3200, SATA disks, software raid. time.c: Lost 6 timer tick(s)! rip __do_softirq+0x44/0xc0) time.c: Lost 6 timer tick(s)! rip __do_softirq+0x44/0xc0) time.c: Lost 6 timer tick(s)! ...

I've seen this as well, on an ancient 4MB card. I'm pretty sure the -CSEL signal on my test board is incorrectly routed, so I thought it was because of that. I'll try to strap it tomorrow and see if it In my current pile of four CF cards, it looks like three of them are buggy, although in slightly different ways. I'd be happy to test a few patches. Haavard -

I've added this patch to the backlight git tree since it allows the removal of a powermac specific hack to chipsfb_blank and fixes the backlight class to work with drivers with no hardware blanking. Can anyone see any problems with this? The backlight class wants notification whenever the console is blanked but doesn't get this when hardware blanking fails and software blanking is used. Changing FB_EVENT_BLANK to report both would be a behaviour change which could confuse the console layer ...

The changes under drivers/acpi/ and drivers/misc/ look fine to me. Acked-by: Len Brown <len.brown@intel.com> if you need that to send those bits upstream. Note that there is a new sony-laptop driver under drivers/misc/ in my tree that I expect to send upstream next week -- and it will need the analogous updates. thanks, -

I fixed it up to at least support x86-64 too -Andi -

I think there are situations in which it can be justified, like: - The driver is not entirely finished, but we want to merge it early, because of many potential users, - The driver has only a few users who aren't interested in the suspend/resume functionality, - The device is undocumented and we don't know how to make it handle the suspend/resume (we may learn that in the future or not). For this reason I 100% agree that we should _encourage_ implementing .suspend and .resume, but we should ...

That depends on what the driver author tells us. If he says there's only one such device in the world and it needs a Linux drivers, but the system in question will never be suspended, that will be fine, I think. There are such No, in general this is not _that_ simple. Please browse the archives of bcm43xx-dev, for example. While I agree that the support for suspend and resume _is_ generally important, I also admit that there are situations in which it doesn't matter and there are many ...

Hi Julien, this is obviously a bug, thanks for a fix, I queued it for upstream. Two nitpicks: - could you please submitpatches in standard conventions, so that they could be applied directly using patch -p1 against toplevel of the kernel tree (your patch was just against hid-core.c, but without any path) - please inline patches in message and do not attach them, if possible I will submit the patch to stable team. Thanks, -- Jiri Kosina SUSE Labs -

Andrew's patch seems to work for me, no more BUGs showed up. Thanks, Miguel -- Miguel Ojeda http://maxextreme.googlepages.com/index.htm -

BTW. will kvm-13's external module work? thanks, -- http://www.fi.muni.cz/~xslaby/ Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E -

It's intel core 2 duo emulating 32-bit wxp. It happened after suspend/resume (he doesn't know if qemu was actually running) of the machine. Dmesg (not with the oops): http://www.fi.muni.cz/~xpapiez/kvm-intel-panic/dmesg.txt .config: http://www.fi.muni.cz/~xpapiez/kvm-intel-panic/config-2.6.20-rc6.txt I don't know if this is related, but qemu-system-x86 ends up in D state: root 28740 0.0 0.0 0 0 ? D 14:31 0:00 [qemu-system-x86] root 28858 0.0 0.0 0 ...

What guest? what host? How to reproduce? -- error compiling committee.c: too many arguments to function -

Nice to report, that it works, good work! regards, -- http://www.fi.muni.cz/~xslaby/ Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E -

On Sat, Feb 10, 2007 at 09:56:07AM -0800, Michael Kerrisk wrote: > Val, > > I'm just updating the mount(2) man page for MS_RELATIME, and this is the > text I've come up with: > > MS_RELATIME(Since Linux 2.6.20) > When a file on this file system is accessed, only > update the file's last accessed time (atime) if > the current value of atime is less than or equal > to the file's last modified (mtime) or last sta- > ...

In the meantime, I've been trying 2.6.20-rc7. Things are not better, except that the ata2 probing failing results in no /dev/sdd being allocated, thus it changes all the naming afterwards. So, 2.6.20-rc7 results are : - ata2 probing still very long and delaying boot a lot, - Jmicron PATA still not working, and doesn't even detect the DVD-ROM on the port. Guys, should you have any patch that you'd like me to test, feel free to send, I'll do that more than ...

pci_iomap() depends on two things - PCI and iomap. AFAIK, there is no config to test whether the current arch supports iomap or not. Previously it worked because those archs which don't support either one doesn't have set CONFIG_GENERIC_IOMAP while not implementing arch-specific ones && not compiling any driver which uses the iomap interface. This is why pci_iomap() ended up in lib/iomap.c in the first place; otherwise, it cannot be conditionalized correctly as devers currently shows ...

Take a look at lib/Kconfig. And see HAS_IOPORT there. The reason for doing it that way: majority of targets has that stuff already. Even more should have it eventually. IOW, the default should be positive. Modified in arch/*/Kconfig of targets where it doesn't work. Which is exactly what's done here. -

It looks like devres stuff is still broken on ia64, at least on the config below. The build dies with: CC drivers/base/dma-mapping.o /scratch/Ksrc/linux-git/drivers/base/dma-mapping.c: In function 'dmam_noncoherent_release': /scratch/Ksrc/linux-git/drivers/base/dma-mapping.c:32: error: 'struct ia64_machine_vector' has no member named 'platform_dma_free_coherent' /scratch/Ksrc/linux-git/drivers/base/dma-mapping.c: In function ...

I haven't looked at what causes it, but any leakage of pci details into io.h is bogus. I'd suggest that the original submitter fixes up that problem instead. -

Seems sane to me. Jeff -

ACK -

ACK -

Another source of breakage: you get devm_request_irq() only if you have GENERIC_HARDIRQS. Otherwise kernel/irq/ is simply not built. Again, you are mixing default implementation of primitives with the implementation-agnostic stuff around those primitives. I'd split kernel/irq/manage.c in two files and have the places providing alternative implementations (e.g. arch/sparc/kernel) refer to new file in their makefiles... I'm mostly done with that stuff, modulo noncoherent_dma breakage. ...

I sent a patch earlier which "fixes" at least the dma stuff by adding some more defines to asm-generic/dma-mapping-broken.h The patch below (on top of your latest one) makes sure s390 builds at least again until all this got sorted out. --- Hack to make s390 build again. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> --- include/asm-s390/io.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) Index: ...

I'd like to have that on ppc as well, so I'd rather keep it in drivers/ I agree that it doesn't need to be a module. If you can load modules, then you can load the full ohci driver. Thus, if it's an early thingy initialized by arch, it can export a special "takeover" hook that the proper ohci module can then call to override it (important if we start having an irq handler). Andi, also, how do you deal with iommu ? Not at all ? :-) Ben. -

I understand your concerns, but the problem is not *current* drivers, but what will happen to *new* drivers. If we make it implicit that a driver is compatible, then new drivers will be promoted as good even if nothing has been done for this. Regards, Willy -

That's true, but I assume that the people who opt for doing that are also Well, if we change the design to fail by default, the authors of new drivers will only have to flag them if they believe that the drivers are Well, I don't think so. Let's estimate the number of drivers that define .resume() right now: $ grep -I -l -r '.resume =' linux-2.6.20/drivers/ | wc 102 102 4169 And I think there are much more drivers that really work fine with respect to the ...

Yes, that's possible. Greetings, Rafael -

Actually, ne2k driver is okay. ne2k cards are notoriously buggy, so it responds with "****, that damn card has just locked up again, lets reset it". Ok, it takes timeout to realize card is "locked up", so it could be improved... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -

Ah, good catch. I have searched for ".resume" only and got 612, but this is the number of files, not the number of drivers. And it is not exactly Yes, I'll try to invent a test. Greetings, Rafael -

This ignores the reality of the situation, which is that many drivers support suspend and resume despite the lack of any explicit implementation. Changing things so they're flagged as broken when they're not would be a regression. -- Matthew Garrett | mjg59@srcf.ucam.org -

instead of modifying all drivers to explicitly state that they don't support it, we should start with a test of the NULL pointer for .suspend which should mean exactly the same without modifying the drivers. I find it obvious that a driver which does provide a suspend function will not support it. And if some drivers (eg /dev/null) can support it anyway, it's better to change *those* drivers to explicitly mark them as compatible. regards, Willy -

Hi. I think the '.resume =' doesn't help - some have tabs. I ran '\.resume' and got 351. It would be interesting to see how many struct pci_driver etc instances lack resume methods. Regards, Nige -

No you don't. You can make it a config option that defaults to n during a transition period. -

Thanks for the spot. arch/arm/mach-s3c2410 is being reorganised, so can we split this patch and have the other two submitted, or wait for the re-work has made it through to the kernel please? -- Ben Q: What's a light-year? A: One-third less calories than a regular year. -

In short, not very useful yet. The current run of of sparse-0.2-cl2 on git default i386 config will find about 6 place kernel using allocated memory without NULL check. But Linus said most of them is not worthy checking because it is in the early stage of the kernel initializations. It just can't fail on those small memory allocation. May be one of them worth adding the NULL check. For interrupt and spinlock checking, it less noisier than the current sparse context level checking. The new ...

OK, we should talk. Here is what I have: Linearize bytecode writer, which produce the binary linearized code. The uncompress size is about 10 times the i386 .o file. I don't have the loader ready to verify it yet. It is aim at fast loading bytecode and simple, I havn't done much toward optimized the code size. If we keep it 10 times over head, my home computer can load the full linux kernel and have some spare for checking. I am still working on the bytecode loader and linker for ...

Yes, it's basically a "normal" OOM situation. What makes it worse than usual, is that it's _kernel_ memory being used up which is not attributed to any process. So from the OOM killer's point of view it looks like none of the userspace programs are responsible for the OOM, and it will just select targets randomly. By the time it has come to the actual culprits (the filesystem daemon and 'du') it will have killed almost everything useful. So it's definitely better than without the patch, ...

No, it is not by dummy functions. Checkout how swsusp works; it needs no hw support, still it needs driver support. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -

Why not right now? Regards, Nigel -

And testing/submitting drivers, perhaps with additional text in that to make it clear we want suspend/resume support or good excuses "Please verify your driver correctly handles suspend and resume. If it does not your patch submission is likely to be suspended and only resume when the driver correctly handles this feature" -

Am 11.02.2007 20:42 schrieb Pavel Machek: Documentation/power/devices.txt? --=20 Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany - In theory, there is no difference between theory and practice. In practice, there is.

On Sunday, 11 February 2007 07:46, Willy Tarreau wrote: I agree, but the suspend/resume safeness has to be somehow indicated by the driver. We could add a flag for that, but it would require us to modify lots of existing drivers (unless there's something obvious I don't see). However, the driver can effectively say "I'm not suspend/resume-safe" by returning an error from .suspend(), in which case the system will automatically refuse to suspend. Greetings, Rafael -

Hi. Ok, that was a bit rough. Sorry. At the same time though, we were talking about new drivers. If you know enough to implement the rest of the driver, surely you know enough to implement the power management part too. (See my previous comment about Not necessarily. I dual boot our desktop machine, and hibernate both, Neither am I. I'm just asking that new drivers have power management as Yes, but why should the user have to complain to start with? Regards, Nigel -

> applicable? Well, for many people s2ram does not work even today... so requiring Ok.. but I'm not sure how many people will actually test it _that_ thoroughly. "Try to test it" is good enough for a first version. When suspend is in better shape, we can ask for more. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -

Hi. No. The differences are: Built in: The initcalls will have run, but the driver may or may not actually have been used, depending on whether it's used before we start the resume. It should probably be tested with both having been used and not having been used. Modular, loaded prior to suspending but not prior to resuming: At resume time, will still be in whatever config the bios puts it in. No Linux driver code will have touched it. Modular, loaded prior to suspending and resuming: ...

Hi. It's not that complex. All we're really talking about is a bit of extra code to cleanup and configure hardware state; things that the driver author already knows how to do. S3 might require a bit more initialisation if firmware needs to be reloaded or more extensive configuration needs to be done, but if there's firmware to be loaded, there is a reasonably good probability that we loaded it from Linux to Then you as a generic routine that does nothing but return success The questions ...

Hi. If all you need to do is say 'I don't need to do anything' and we have a shared function that does that, all we're talking about doing is adding to your struct pci_device (or whatever) .resume = generic_empty_resume; To me at least, that doesn't look awkward, and says cleanly and clearly that you've checked things over and decided you know what's required. Regards, Nigel -

By adding dummy functions, wouldn't that just look awkward ? regards, manu -

Len, resume from RAM is still broken by "Disable all wakeup GPEs". My previous patch for T43 does not help, only attached one helps (revert original patch).

resume from RAM, or resume from disk? -

Just saw it, will do. -- Jens Axboe -

You really should have needed padding in there, since even if you swapped the members, sizeof(struct epoll_event) would still need to be 16, if alignof(u64) == 8. Either adding an extra auxilliary u32, or make the two members be u64, would have been ok. I'll be posting a patch that adds the compat_ layer for epoll in kernel/compat.c. Architectures that needs it (currently only ARM-EABI and IA64 use a compat code for epoll), should wire them up. - Davide -

Indeed. That was the example I was thinking of when I suggested the "no new syscalls without _simultaneous_ compat version" rule. -- dwmw2 -

Hmm.. so you don't need to do some fancy compat conversion for the sigset_t that gets passed? Why is that? I don't get it... -

Ah, I finally get your point. Yes, that needs conversion. Ralf -

I notice that 2.6.20-git6 still doesn't include either of these fixes. Is there anything I need to do in order to push it? Thanks, Tilman --=20 Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany - In theory, there is no difference between theory and practice. In practice, there is.

Thanks, I really appreciate your answer, everything is working ok. -

On Thu, Feb 08, 2007 at 11:14:13AM -0500, William Cohen wrote: > This past week I was playing around with that pahole tool > (http://oops.ghostprotocols.net:81/acme/dwarves/) and looking at the > size of various struct in the kernel. I was surprised by the size of > the task_struct on x86_64, approaching 4K. I looked through the > fields in task_struct and found that a number of them were declared as > "unsigned long" rather than "unsigned int" despite them appearing okay > as 32-bit ...

So we are talking of two different things. You want to _compile_ the totality of the kernel as code and data relocatable - right now only modules are compiled that way. On IA32 architecture, there is no problem having the code relocatable, because most/all calls and jumps are PC relative, so very few instructions need to be different. The problem is having the data relocatable, then every access to memory has to be relative to a register, and so the register EBX is reserved for that by the ...

Yes, that's rare. OK, I read LDD3 text on completions, hope I got it right. Does it pass everyone's bullshit detectors? [PATCH v4] Fix rmmod/read/write races in /proc entries Differences from version 3: Use completion instead of unlock/schedule/lock Move refcount waiting business after removing PDE from lists, so that *cough* possible concurrent remove_proc_entry() will work. Current /proc creation interfaces suffer from at least two types of ...

Ok, following from that on my machine currently... brad@bklaptop2:/$ ls /dev/mmc* /dev/mmcblk0 /dev/mmcblk0p1 brad@bklaptop2:/$ find sys/devices | grep mmc sys/devices/pci0000:00/0000:00:1e.0/0000:06:05.3/tifm_sd0:3/mmc_host:mmc0 brad@bklaptop2:/$ find /sys/block/ | grep ...

Works fine here. The device tree is: /sys/devices/pnp0/00:02/mmc0/mmc0:0001/block:mmcblk0/mmcblk0p1/ I'm using 0.5.9 here, but CONFIG_SYSFS_DEPRECATED should make it work with any ancient version of hal. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -

Hi. I can see this problem too. I have CONFIG_SYSFS_DEPRECATED set. It happens only with SD cards, with MMC everything is OK. Fabio -

brad@bklaptop2:/sys/block/mmcblk0$ ls -laR .: total 0 drwxr-xr-x 6 root root 0 2007-02-11 23:29 . drwxr-xr-x 13 root root 0 2007-02-11 23:27 .. -r--r--r-- 1 root root 4096 2007-02-11 23:28 dev lrwxrwxrwx 1 root root 0 2007-02-11 23:27 device -> ../../class/mmc_host/mmc0/mmc0:b368 drwxr-xr-x 2 root root 0 2007-02-11 23:27 holders drwxr-xr-x 3 root root 0 2007-02-11 23:29 mmcblk0p1 drwxr-xr-x 3 root root 0 2007-02-11 23:27 queue -r--r--r-- 1 root root 4096 2007-02-11 ...

Great, thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -

Hello, I agree , I will redo all patches with above commit reverted Regards , Maxim Levitsky PS: my mailbox is now maximlevitsky@gmail.com , I took it to use SMTP , because it less likely to corrupt patches -

[Empty message]

Thanks! After this fix it is working ok. Any chance to see the proper fix in -stable kernels for at least 2.6.18.x and 2.6.19.x? Thanks, Grzegorz Kulewski -

The 7500 issue isn't actually a race but a disease, if you mask a pending irq in its RTE, the PCI hub generates an INTx message corresponding to that irq. This apparently was done to support booting OSes without APIC support. So the following would occur; - irqN pending on IOAPIC - mask => INTx message for irqN Unfortunately it appears the below code would also be affected by this as well, the appropriate reference is; 2.15.2 PCI Express* Legacy INTx Support and Boot Interrupt -

The code currently in the kernel does: pending mask read io_apic ack reprogram vector and destination unmask So I guess it does retain the bug fix. What I am looking at doing is: mask read io_apic -- Past this point no more irqs are expected from the io_apic -- Now I work to drain any inflight/pending instances of the irq send ipi to all irq destinations cpus and wait for it to return read lapic disable local irqs take irq lock -- Now no more irqs are expected to ...

And I actually talked about that in one of the emails already. There is no way you can beat an event-based thing for things that _are_ event-based. That means mainly networking. For things that aren't event-based, but based on real IO (ie filesystems etc), event models *suck*. They suck because the code isn't amenable to it in the first place (ie anybody who thinks that a filesystem is like a network stack and can be done as a state machine with packets is just crazy!). So you ...

It needs to be at most 2 seconds while down or it's going to miss some of= the state changes, why bother to output all the types of state if you're= going to ignore some of them? As for while it's up, polling more often has a negligible effect on perfo= rmance (still polling every 200ms here). If you change the timing for dif= ferent states, you should know that it won't go into the down state on a = retrain so ~up should enable faster polling. --=20 Simon Arlott

Hi Jan, below is what I got using 2.6.20. Is there any correlation to my previous reports? Should I focus testing memory/disks/etc. further(and how?)? Or should I focus modifying kernel parameters(and which)? Feb 11 14:30:47 fantasio kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 0000002d Feb 11 14:30:47 fantasio kernel: printing eip: Feb 11 14:30:47 fantasio kernel: e0c55b16 Feb 11 14:30:47 fantasio kernel: *pde = 00000000 Feb 11 14:30:47 fantasio ...

Hi! CONFIG_USB_SUSPEND=n does the job. But the patch from http://bugzilla.kernel.org/show_bug.cgi?id=7828#c29 works for my system too (with CONFIG_USB_SUSPEND=y). The bugreport was made for an ACER Travelmate 4001 WMLi, which is almost identical to my Acer Extensa 3002 WLMi. Regards, Berthold -