I'm not sure this is a good idea. As you're creating a new interface, why not create something new/improved without the problems that confining yourself to APM emulation brings? Regards, Richard -

Hello, some months ago I sent to the MIPS and ARM mail lists a patch to unify the several APM emulation codes adding a new dedicated directory so it can be used to put there the per board specific code avoiding code duplications (see files ./arch/arm/kernel/apm.c, ./arch/mips/kernel/apm.c and ./arch/sh/kernel/apm.c that are almost the same). The patch is here "http://www.linux-mips.org/archives/linux-mips/2006-07/msg00144.html" and it has been lost in the deep space... The target is to ...

Takashi asked me to send you this single patch as it conflicted with his current tree and it is needed before 2.6.20 comes out to fix a userspace ABI breakage that I caused earlier. This patch fixes a bug with the sound core when CONFIG_SYSFS_DEPRECATED is enabled. More details can be found in the patch itself, which will follow as a reply to this message. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ thanks, greg k-h include/sound/core.h ...

--nextPart1550477.nZ2r2BMeEE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline i'd like to rename the members in the _xt_align struct in=20 netfilter/x_tables.h ... by not using 'u8', 'u16', etc..., it's possible to= =20 filter headers meant for userspace through the preprocessor and pull out=20 people who accidentally utilize these internal types ... however, by using= =20 struct members who have the same name as 'u8', ...

Not sure why this was sent. The other 4/4 email is the correct one. Josef "Jeff" Sipek. -- Bad pun of the week: The formula 1 control computer suffered from a race condition -

The following patches (also available though the git tree) address a number of code cleanliness issues with Unionfs. You can pull from 'master' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/unionfs.git to receive the following: Adrian Bunk (1): fs/unionfs/: possible cleanups Josef 'Jeff' Sipek (3): fs/unionfs/: Remove stale_inode.c fs/unionfs/: Andrew Morton's comments fs/unionfs/: Don't duplicate the struct nameidata fs/unionfs/branchman.c ...

- rename {,un}lock_dentry to unionfs_{,un}lock_dentry - few minor coding style fixes - removed prototypes from .c files - replaced dbstart macros etc with static inlines - replaced UNIONFS_D(d)->sem semaphore with a mutex - renamed sioq struct workqueue to superio_workqueue - made unionfs_get_nlinks and alloc_whname not inlined Signed-off-by: Josef 'Jeff' Sipek <jsipek@cs.sunysb.edu> --- fs/unionfs/branchman.c | 4 +- fs/unionfs/commonfops.c | 48 ++++++++++---------- ...

Is there any way to estimate the size of the user base for 2.6.16? e.g. how many downloads does it get? -

On Mon, 29 Jan 2007 15:30:00 -0500 I've often wondered that myself, as I'm concerned for it to continue to be maintained. I'm very appreciative of what Adrian is doing with it. (Thanks!) I've been using Adrian's 2.6.16 kernel releases on two internet servers that I look after remotely. One of them is RHEL 4 the other is Fedora Core 2 (Ensim Webppliance). I'm especially wary of breaking RHEL 4, and the 2.6.16.xx kernels work perfectly except for the hald not starting (but that doesn't matter ...

We're still running 2.6.16 kernels on a bunch of machines, though 2.6.19 has been looking pretty nice on the couple of machines that are testing it. 2.6.17 and 2.6.18 felt less stable. We do a lot of Cyrus which does a lot of MMAP - and we also use the Areca driver - which are both strong reasons to move to 2.6.19.2, but if the MMAP fix was ported back to 2.6.16 we might consider staying there instead. Bron. -

I try to compile and got: CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h CC kernel/rcupreempt.o kernel/rcupreempt.c: In function 'rcupreempt_try_flip_state_name': kernel/rcupreempt.c:641: error: 'rcu_try_flip_state_names' undeclared (first use in this function) kernel/rcupreempt.c:641: error: (Each undeclared identifier is reported only once kernel/rcupreempt.c:641: error: for each function it appears in.) kernel/rcupreempt.c: ...

This would need to be #idef CONFIG_ZONE_DMA There have been some recent changes though so I am not sure what your codebase is. -

Correct. -

Sometimes developers need to see more object code in an oops report, e.g. when kernel may be corrupted at runtime. Add the "code_bytes" option for this. Signed-off-by: Chuck Ebbert <cebbert@redhat.com>

Hi Linus, I made a silly error in my last upstream push. This patch makes ocfs2 build again. --Mark Please pull from 'upstream-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2.git upstream-linus to receive the following updates: fs/ocfs2/ocfs2_fs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Mark Fasheh: ocfs2: fix thinko in ocfs2_backup_super_blkno() diff --git a/fs/ocfs2/ocfs2_fs.h b/fs/ocfs2/ocfs2_fs.h index c99e905..e61e218 ...

--nextPart10179547.8WxpbZO3dJ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline the current filename->define translation does not scrub dashes so when=20 creating stub defines for like asm-x86_64/ptrace-abi.h, we get: #define __ASM_STUB_PTRACE-ABI_H gcc just hates that sort of thing :) trivial attached patch adds - to the tr list to scrub it to _ =2Dmike --nextPart10179547.8WxpbZO3dJ Content-Type: ...

On December 14, 2006, I posted a patch that added support to the OProfile kernel driver for profiling Cell SPUs. There have been some changes/fixes to this patch since the original posting (including forward porting from 2.6.18-based kernel to 2.6.20-rc1), so I am reposting the patch for review now. This patch relies upon the following patches that have not been accepted yet: 1. oprofile cleanup patch (submitted on Nov 27) 2. Fix for PPU profiling (not submitted yet, since it depends ...

This patch adds into write inode path function to write UFS2 inode, and modifys allocate inode path to allocate and init additional inode chunks. Also some cleanups: - remove not used parameters in some functions - remove i_gen field from ufs_inode_info structure, there is i_generation in inode structure with same purposes. Signed-off-by: Evgeniy Dushistov <dushistov@mail.ru> --- Index: ...

When expanding the stack, we don't currently check if the VMA will cross into an area of the address space that is reserved for hugetlb pages. Subsequent faults on the expanded portion of such a VMA will confuse the low-level MMU code, resulting in an OOPS. Check for this. Signed-off-by: Adam Litke <agl@us.ibm.com> --- mm/mmap.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/mm/mmap.c b/mm/mmap.c index 9717337..2c6b163 100644 --- a/mm/mmap.c +++ ...

Hello, I am using kernel 2.6.18, and have been trying without success to set up multiple network interfaces using kernel boot arguments. It makes sense to be able to specify multiple interface configurations on the command line, but it has occurred to me that I may not be correctly understanding the purpose of the "ip=" parameter. My question is if it is intended to be able to use more than one "ip=" parameter in the kernel command line, or if I'm supposed to use a startup ...

Good day. I have a really big trouble with VIA-EPIA mainboards under Linux 2.6.19. After loading kernel Linux the RESET-circuit ceases to work correctly. At reset (by RESET-button or by Watchdog) the system begins to be restarted, but hangs before occurrence of any BIOS-messages. Only a power-off and then power-up can help. The problem has been reproduced confidently and constantly, I has checked up about 20 mainboards (EPIA- EN/C7 and EPIA-PD/C3). I am sure, this is not a Linux-related ...

This patch fixes the wrong query and logging of the per interface jumbo frames enabled/disabled status. Signed-off-by: Thomas Klein <tklein@de.ibm.com> --- drivers/net/ehea/ehea.h | 2 +- drivers/net/ehea/ehea_main.c | 30 +++++++++++++++++++++++------- 2 files changed, 24 insertions(+), 8 deletions(-) diff -Nurp -X dontdiff linux-2.6.20-rc6/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h --- linux-2.6.20-rc6/drivers/net/ehea/ehea.h 2007-01-25 ...

The softlockup watchdog needs to be touched after resume to avoid a false positive. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Jiri Kosina <jkosina@suse.cz> Index: linux-2.6.20-rc6-mm/kernel/time/tick-common.c =================================================================== --- linux-2.6.20-rc6-mm.orig/kernel/time/tick-common.c +++ linux-2.6.20-rc6-mm/kernel/time/tick-common.c @@ -320,6 +320,7 @@ static int tick_notify(struct notifier_b case ...

I have noticed that vger seems to be truncating Cc lists lately, often resulting in broken partial email addresses in the Cc list causing people that reply to have copies of the message bounced back instead of being delivered to the intended recipients. It seems that it munges long, multi line Cc headers into one line, and truncates that line to a maximum length. Who is the list admin again? And can they look into this? -

P.S. I'm not subscribed to any of the above lists, please Cc: me in replies. -- Evgeniy Polyakov -

Hello. I'm pleased to announce initial userspace M-on-N threading model implementation (for hackers) called NTL. This is first alpha release, which indeed has bugs and limitations. Userspace M-on-N threading model is based on the idea, that when signal is delivered, kernel saves all information related to previous context in stack, so it is possible to find it and replace. M-on-N threading model compared to usual NPTL 1-on-1 model has following advantages and disadvantages: Benefits. ...

well, I spent some time doing more deeply test. DB corruption happens anyway, even with the kernel that seems to work (I say seems because it needs much more effort to get corruption). I'm trying to understand it. I will work more over it next week. thank a lot for your time, gelma -

-

Vojtech Pavlik <vojtech@suse.cz> writes: On Sat, Jan 27, 2007 at 05:45:25PM +0000, Pavel Machek wrote: > Hi! > > > Well, I do not think your kernel code is mergeable. But bits to enable > > similar functionality in userspace probably would be mergeable. > > > > You said it :-) > > > > This patch exports to the user space the inactivity time (in msecs) of a given > > input device. Example follows: > > Looks okay to me. I guess you should sign it ...

Hi, at least for me it looks like I need something like in attachment to get patch-2.6.20-rc6-rt4 compile and link for ARM. Please correct if anything is wrong. Regards Dirk

In the meantime tested by Martin Murray on x86_64 native and inside vmware (thanks much!) who told me I could add his sob: Signed-off-by: Martin Murray <murrayma@citi.umich.edu> Rene. -

The x86_64 tree is really a x86 tree these days and contains most i386 changes. But in general if you change i386 then changing x86_64 makes sense too. -Andi -

`make help' in the build tree doesn't show the help texts about the `headers_install' and `headers_check' targets because it looks for include/asm-$(ARCH)/Kbuild in the wrong place. Add the missing `$(srctree)' prefixes to fix this. Also move the printing of the default install path for the headers inside the `if/fi', where it belongs. Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> --- Makefile | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) --- ...

Yes, the "ineffective reclaim" is more of an issue with this than linear, and the cost metric we are working on should help us show that; and then help us evaluate the utility of pushing the pages back without Yes, what was obvious from the linear against lumpy was that the only valid comparison was on the 'effectiveness' metric (which was basically the same) and code complexity (where lumpy clearly wins). But we have no feel for 'cost'. We are working on a cost metric for reclaim ...

fix-rmmod-read-write-races-in-proc-entries.patch doesn't want dynamically allocated ->proc_fops, because it will set it to NULL at module unload time. Regardless of module status, switch to statically allocated ->proc_fops which leads to simpler code without wrappers. AFAICS, also fix the following bug: "sn_force_interrupt" proc entry set ->write for itself, but was created with 0444 permissions. Change to 0644. Signed-off-by: Alexey Dobriyan <adobriyan@openvz.org> --- ...

For architectures with a split address space there has to be a call set_fs(USER_DS) that switches from KERNEL_DS to USER_DS for the init process. So far this has been done in search_binary_handler and traditionally the kernel starts with KERNEL_DS to make the early copy_from_user calls work. So, what is wrong with always setting USER_DS? We are starting a user space process after all. -- blue skies, Martin. Martin Schwidefsky Linux for zSeries Development & Services IBM Deutschland ...

On Mon, 29 Jan 2007 14:59:58 +0100 hm, thanks for testing - I'll drop it. I don't really understand what's wrong with it though. Maybe it's settng USER_DS on kernel threads? -

Hi, may a driver call wake_up() while doing resume() ? Regards Oliver -

Hi. Do you mean I/O to disk? If so, it won't fail. All pending I/O gets processed like normal either before or after suspending and resuming. If you mean something like a packet being transmitted over the network, you should be using the normal paths for recording success/failure. HTH. Nigel -

Hi, Hm, this way or another, the notification of tasks should be deferred until they are thawed. The freezeable workqueue idea seems sensible to me. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King -

Hi. Ok. In that case, you'd want to delay trying to wake them until resuming is completed. Unless there's something I've forgotten, we don't currently have an easy way for you to determine when processes are thawed. Perhaps this indicates a need for us to have a notifier chain for the end of a cycle? You could create a freezeable workqueue and schedule work from your device_resume call (assuming that's doesn't raised atomicity issues), but I wonder if that approach would be too heavy ...

The following set of patches attempt to fix the buffered write locking problems (and there are a couple of peripheral patches and cleanups there too). Patches against 2.6.20-rc6. I was hoping that 2.6.20-rc6-mm2 would be an easier diff with the fsaio patches gone, but the readahead rewrite clashes badly :( Please apply? Thanks, Nick -- SuSE Labs -

Quite a bit of code is used in maintaining these "cached pages" that are probably pretty unlikely to get used. It would require a narrow race where the page is inserted concurrently while this process is allocating a page in order to create the spare page. Then a multi-page write into an uncached part of the file, to make use of it. Next, the buffered write path (and others) uses its own LRU pagevec when it should be just using the per-CPU LRU pagevec (which will cut down on both data and code ...

If prepare_write fails with AOP_TRUNCATED_PAGE, or if commit_write fails, then we may have failed the write operation despite prepare_write having instantiated blocks past i_size. Fix this, and consolidate the trimming into one place. Signed-off-by: Nick Piggin <npiggin@suse.de> Index: linux-2.6/mm/filemap.c =================================================================== --- linux-2.6.orig/mm/filemap.c +++ linux-2.6/mm/filemap.c @@ -1911,22 +1911,9 @@ generic_file_buffered_write(struct ...

From: Andrew Morton <akpm@osdl.org> Revert 81b0c8713385ce1b1b9058e916edcf9561ad76d6. This was a bugfix against 6527c2bdf1f833cc18e8f42bd97973d583e4aa83, which we also revert. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Nick Piggin <npiggin@suse.de> Index: linux-2.6/mm/filemap.c =================================================================== --- linux-2.6.orig/mm/filemap.c +++ linux-2.6/mm/filemap.c @@ -1911,12 +1911,6 @@ generic_file_buffered_write(struct kiocb ...

Modify the core write() code so that it won't take a pagefault while holding a lock on the pagecache page. There are a number of different deadlocks possible if we try to do such a thing: 1. generic_buffered_write 2. lock_page 3. prepare_write 4. unlock_page+vmtruncate 5. copy_from_user 6. mmap_sem(r) 7. handle_mm_fault 8. lock_page (filemap_nopage) 9. commit_write 10. unlock_page a. sys_munmap / sys_mlock / others b. mmap_sem(w) c. ...

Other things got more important... I still am on the virge of using it but I have to finish off other work first so the "virge" may be a little Yes this is exactly what I need it in NTFS for. And also I need to be able to perform a mmap'ed write into a non-initialized region, i.e. a region which has disk allocation but has not been zeroed yet so in a total worst case scenario I could have a huge file that is all allocated on disk but completely not initialized yet and a single byte ...

You're right. Well observed. It was I who originally added that page_cache_release/page_cache_get, and the page_cache_get certainly followed getting the page_table_lock when I first added them. Looks like amidst all the intervening versions, with the patch going into and getting dropped from -mm from time to time, those positions became reversed without us noticing (almost certainly when the lock Yes. I'm reluctant to steal your credit, but also reluctant to go back and forth too much ...

Hi, At first, change this variable path_to_mbox_file = '/home/michal/.thunderbird/uyw4at28.default/Mail/Local\ Folders/mm_new2' Copy to a new mbox patches that appeared after 2.6.20-rc6-mm2, get 2.6.20-rc6-mm2 http://userweb.kernel.org/~akpm/2.6.20-rc6-mm2/2.6.20-rc6-mm2-broken-out.tar.gz and run witcher inside source tree. http://www.stardust.webpages.pl/ltg/files/tools/witcher/witcher.py example series diff http://www.stardust.webpages.pl/ltg/files/tools/witcher/witcher-series (it's not ...

Greg, do you have this already in your tree, or should I take it over? Soeren - could you please submit your patch with proper Signed-off-by line? Thanks, -- Jiri Kosina -

Well I need in-kernel usbhid and the way this was implemented in 2.6.19 (and before) one could change pb_fnmode on-the-fly. This is mentioned in all the power/i/mac/book tutorials and everyone is used to switching modes this way. I can happily patch the kernel to use the pb_fnmode but nonetheless this is a regression to pre 2.6.20* and will confuse others too... Soeren -- Sometimes, there's a moment as you're waking, when you become aware of the real world around you, but you're still ...

For me yes ... I just rebooted and checked fn_modes ... it works nicely. So I guess this should be applied ?! Soeren -- Sometimes, there's a moment as you're waking, when you become aware of the real world around you, but you're still dreaming. -

Actually the cleanest solution would be when I change the code in such a way that pb_fnmode parameter would be passed to hid instead of usbhid module, as this is where the input mapping is being done (you could potentially have a keyboard which needs the very same handling of fn mode as usb powerbook keyboards currently have, but on different transport - input mapping is logically transport independent). But I guess you will be not OK with breaking the backward compatibility in such way, ...

Ah, now I see. The problem is that in pre-2.6.20-rc1 the pb_fnmode was setting global variable, but after the HID layer rework, this is a per-hid variable, which is of course not updated when write to sysfs triggers. I will try to fix this before I send 2.6.20-rc6 updates to Linus, thanks for pointing this out. -- Jiri Kosina -

Does /proc have any entries to flip the "software read-only flag" for a partition or disk (which are physically read-write) ? Yakov -

Nice, reiser4 does work now. It was broken since 2.6.20-rc3-mm1, see thanks ~~ laurent -

I have a consistent problem running 'make modules_install' after compiling. The directory structure forms in /lib/modules, but no modules install. This problem showed up under -rc6-mm1 and -rc6-mm2, but not -rc6. I'm hoping somebody has hit this before, otherwise it's git-bisect time. Process is what I have been given to understand as proper: untar, patch, configure and make as $USER, make modules_install as root. I'm on a new Slackware-11.0 install (glibc 2.3.6, gcc 3.4.6, module-init-tools ...

I just got this on suspend/resume cycle on my IBM T42p pcspkr pcspkr: EARLY resume vesafb vesafb.0: EARLY resume serial8250 serial8250: EARLY resume i8042 i8042: EARLY resume platform floppy.0: EARLY resume BUG: soft lockup detected on CPU#0! [<c01043ae>] show_trace_log_lvl+0x1a/0x2f [<c0104941>] show_trace+0x12/0x14 [<c01049c5>] dump_stack+0x16/0x18 [<c0142053>] softlockup_tick+0x93/0xa2 [<c011eb5b>] run_local_timers+0x12/0x14 [<c011ed6f>] update_process_times+0x36/0x5a ...

Hi, The svc_pool_map_init_percpu() should get maxpool from the number of online cpus, not the number of nodes. The following BUG is triggered when we try to check if the cpu index is smaller than the number of nodes. (The system is multi cpu, single node). [ 133.196276] ------------[ cut here ]------------ [ 133.196334] kernel BUG at net/sunrpc/svc.c:128! [ 133.196391] invalid opcode: 0000 [#1] [ 133.196444] PREEMPT SMP [ 133.196571] last sysfs file: ...

Temporarily at http://userweb.kernel.org/~akpm/2.6.20-rc6-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm2/ - Dropped git-block due to CFQ breakage - Dropped the fsaio patches due to their dependence on git-block. - Added the new hrtimers/dynticks patches. This is an update of the 2.6.20-rc4-mm1 patches, now apparently fixed. Boilerplate: - See the `hot-fixes' directory for any important updates to ...

Hi, with dynticks and highres_timers enabled, cpufreq_ondemand makes mess here on an AMD64 UP. cpufreq_ondemand assumes that jiffies advance at exactly the same pace as the sum of all kstat_cpu(cpu).cpustat.* members. This isn't the case here as dmesg output from patch below shows. Is cpufreq_ondemand correct assuming "jiffies advance at exactly the same pace as the sum of all kstat_cpu(cpu).cpustat.* members"? Or is "dynticks and highres_timers"'s behaviour of incrementing the sum of ...

Morning! The 2.6.19 was self-compiled, using the gentoo-sources-rc4 AND using the vanilla 2.6.19 from kernel.org (I was recommended to use vanilla sources with my ATI drivers), both worked. 2.6.20 is self compiled to. I will give you the kernel output when I am at home, I will have to connect a serial cable to my laptop and use the scrollbuffer since on a kernel panic or system crash my keyboard leds start to blink, which the kernel sees as a device addressing hardware ...

Funny, when I look at my dmesg log when I boot the 2.6.19 kernel (which works) then I seem to miss something in the kernel output when I boot the 2.6.20 kernel. When I boot 2.6.19 I see: scsi 0:0:0:0: Direct-Access ATA WDC WD2000JB-00G 08.0 PQ: 0 ANSI: 5 SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) sda: Write ...

On Mon, 29 Jan 2007 00:14:24 -0600 I'd suggest you do it all in a single patch. -

(only 5 months later...) Sure, how about this? Thanks, NeilBrown Remove warning: VFS is out of sync with lock manager. But keep it as a dprintk The message can be generated in a quite normal situation: If a 'lock' request is interrupted, then the lock client needs to record that the server has the lock, incase it does. When we come the unlock, the server might say it doesn't, even though we think it does (or might) and this generates the message. Signed-off-by: Neil ...

On 2.6.20-rc6 (run #1097), the openposixtest[1] suite results were: build errors: 13 files, 31 lines PASS: 1687 FAILED: 68 UNTESTED: 95 UNRESOLVED: 9 UNSUPPORTED: 22 INTERRUPTED: 7 SCORE: 89 [1] http://posixtest.sourceforge.net/ (using v1.5.2) On 2.6.20-rc6-mm1 (run #1104), the results were: build errors: 13 files, 31 lines PASS: 1662 // 25 fewer tests PASS FAILED: 84 UNTESTED: 95 UNRESOLVED: 18 UNSUPPORTED: 22 INTERRUPTED: ...

Pretty sure it is, the rest of the command needs to be set to 0. Without it the other 9 bytes will contain uninitialized junk. For the other cleanup changes, though: Signed-off-by: Robert Hancock <hancockr@shaw.ca> -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ -

On Sun, 28 Jan 2007 19:47:27 -0600 What we don't want to happen is for those disks to spin down during a reboot. It seems that this is OK with this patch. Also, we probably don't want them to be spun down during a kexec_load, but I expect that's OK too. -

The very early archives are available on the web: http://www.kclug.org/old_archives/linux-activists/ And I'm under the impression that Alan Cox once collected a complete set of mbox archives, but this is a vague an unfocused recollection of something going by years ago. (I also thought the result was downloadable under kernel.org/pub somewhere. This would not appear to be the case.) Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no ...

Applies to 2.6.20-rc6. --- libata's SCSI translation for the SCSI START STOP UNIT command with the START bit clear (i.e. stopping the drive) appears to be incorrect. It sends an ATA STANDBY command with the time period set to 0, which the code comment says means "now", but the ATA standard says this means disable the standby timer, which effectively does nothing. Change this to issue a STANDBY IMMEDIATE command which will actually spin the drive down. The SAT (SCSI/ATA Translation) ...

It's hot here. I'm in similar situation (even *usb-serial* driver [TI USB] led me there;) In short, it turned, that usb drivers aren't drivers at all, they are just "USB interface drivers", i.e. managers of the particular USB interface *in* the device. Problem is: after changing ti-usb-serial's firmware, it is being reset and apears with new device ID. It's OK so far, but even this may be better (from USB hardware implementation point of view). Then this device, after being caught with ...

Ahh. Okay then the following patch would fix it? Shutdown cache_reaper when cpu goes down Shutdown the cache_reaper in slab.c if the cpu is brought down and set the cache_reap.func to NULL. Otherwise hotplug shuts down the reaper for good. Signed-off-by: Christoph Lameter <clameter@sgi.com> Index: linux-2.6.20-rc6/mm/slab.c =================================================================== --- linux-2.6.20-rc6.orig/mm/slab.c 2007-01-24 20:19:28.000000000 -0600 +++ ...

For the beginning, about another (but related) minor problem, debug_smp_processor_id: /* * Kernel threads bound to a single CPU can safely use * smp_processor_id(): */ This is only true without CONFIG_HOTPLUG_CPU. Otherwise CPU can go away when the task takes a preemption or sleeps. I think we need #ifndef here. Now, static void __devinit start_cpu_timer(int cpu) { struct delayed_work *reap_work = &per_cpu(reap_work, cpu); if (keventd_up() && ...

Then we wont need to do the mutex_lock/unlock in CPU_DOWN_XX anymore, right? Which brings us to this form of the patch: Shutdown cache_reaper when cpu goes down Shutdown the cache_reaper in slab.c if the cpu is brought down and set the cache_reap.func to NULL. Otherwise hotplug shuts down the reaper for good. Signed-off-by: Christoph Lameter <clameter@sgi.com> Index: linux-2.6.20-rc6-mm2/mm/slab.c =================================================================== --- ...

The CPU_DOWN would need to set work.func == NULL for this to work. But then the slab does not shut down the work queues for the processor. Isnt this another issue with workqueues? The slab would need a notification that the workqueue for a processor was shutdown in order to set work.func Well seems that we have a set of unresolved issues with workqueues and cpu hotplug. -

Good. Here is the patch against 2.6.20-rc6-mm2. CPU_DOWN_PREPARE and CPU_DOWN_FAILED somehow vanished in mm? Shutdown cache_reaper when cpu goes down Shutdown the cache_reaper in slab.c if the cpu is brought down and set the cache_reap.func to NULL. Otherwise hotplug shuts down the reaper for good. Signed-off-by: Christoph Lameter <clameter@sgi.com> Index: linux-2.6.20-rc6-mm1/mm/slab.c =================================================================== --- ...

Then CPU_DOWN_FAILED should do start_cpu_timer(cpu). Oleg. -

Because the last CPU_UP calls start_cpu_timer(), but since ->work.func != NULL we don't do schedule_delayed_work_on(). I think (if I am right) this is a slab's I think this is yet another problem with workqueues/cpu-hotplug interaction. Probably, the problem is more general. With CONFIG_CPU_HOTPLUG, we can't garantee that smp_processor_id() is stable even if the thread is pinned to I think cache_reap() is not alone, and this is not its fault. But please note another minor problem, void ...

Just to give you idea, how imperfect it is: <http://marc.theaimsgroup.com/?l=linux-mm-commits&m=116198944205036&w=2> Anyway, i still think programmers *must* take care of it, if they think ____ -

On Mon, Jan 29, 2007 at 02:26:04AM +0100, Richard Knutsson wrote: I would like to discuss, would you? ____ -

1. Patches are signed-off (not by you). _____ -

Oh, I hope I didn't give the impression I wanted it in the kernel (that is why i labeled it as SCRIPT and not PATCH), as you said it is a userspace problem. I just thought a simple script to remove those whitespace could help in an imperfect world. I prefer kate since then you can see where the tabs begins (and other features). Richard Knutsson -

By the time you do this, probably may as well remove the whole file; the leftover 4 definitions never seem to be used. The same may go for xfs_mac.h. -Eric -

Agreed. As Dave said if we get this functionality on Linux it will most likely be handled at a different level, so keeping the old IRIX-style hooks is rather pointless. -

I completely agree with you in the case you have described, it does mean that the hypervisor needs to trust all of the MSI capable hardware in the system but it if that is the best your hardware can support it is a reasonable trade-off. With the MSI-X registers in a random part of some memory mapped bar and not guaranteed to be page aligned, things are more difficult to The reason I consider the case crazy is that every example I have been given is where the hardware is doing the filtering ...

From: ebiederm@xmission.com (Eric W. Biederman) Ok, that's great to hear. I know your bi-directional approach isn't exactly what Ben wants but he can support his machines with it. Maybe after some time we can agree to move from that more towards the totally abstracted scheme. -

Current git + gregkh-pci (Which has a couple of Michaels patches). With current git the only problem should be context around msi_lookup_irq which changes between the two. But in this case the context around an entire function being deleted doesn't matter. Eric -

It can support my machines without HV with trivial changes I reckon: I need an ops struct to indirect eric's 2 remaining arch hooks (setup/teardown) but that can be done inline within asm-powerpc. I need to double check of course and probably actually port the MPIC backend and possibly go write the Cell Axon one while at it to verify everything is allright, but the base design seems sound enough. For the ones with HV (RTAS stuff), we still need to agree on how to approach it. We can ...

You can read config space, but it's not clear to me if the HV is allowed to filter it and hide things. It's also possible that the device supports MSI, but for some reason the HV doesn't allow it on that device etc. so you really have to ask the HV if it's enabled. So pci_find_cap() It would be good to have a common data structure if possible. My thinking was that most of the information is per pci_dev, so that's where I put it. I realise the Intel code stores some info that's per-irq, but ...

I've seen it do it for example with EADS bridges. I haven't seen doing it with devices (other than hiding entire functions) but I wouldn't Part of the reason is you make MSI look like MSI-X (a vector of 1 entry) while Eric does the opposite. Ben. -

Alternativly you could move the SELinux specific bits out of /proc/self/attr into an equivalent /selinux/self/attr and avoid that /proc dependency. Casey Schaufler casey@schaufler-ca.com -

True, but a system that disables proc is likely a system with a custom policy anyway, and dependency on proc is fairly basic to selinux these days (due to reliance on /proc/self/attr for process attribute manipulation in place of the old selinux syscalls). Possibly we should At present, we map the sysctls into functional groups (e.g. net, vm, fs, ...) that parallel the sysctl hierarchy so that we can limit access to only those programs/processes that need access for their purpose, ...

NAK. Mapping all sysctls to a single security label prevents any kind of fine-grained security on sysctls, and current policies already make use of the current distinctions to limit access to particular sets of sysctls to particular processes. As is, I'd expect breakage of current systems running SELinux from this patch, because (confined) processes that formerly only required access to specific sysctl labels will suddenly run into denials on the generic fallback label. If the ctl_table ...

Please don't shoot the messenger when a weakness is found in your code. Systems that increase security without worry that their implementation is correct do not impress me, but I do understand that security has little to do with correctness and everything to do with making it _expensive_ for the other guy to do what he isn't supposed to. This code path was always in the selinux code for when /proc was compiled out. I could see no way to preserve it so I removed it. Not knowing if it was a ...

Reasonable. There is the issue that your code already had this code What do information do you need to do need? Do you need extra fields in sysctl? I am more than willing to help but I am not familiar enough with selinux to do a reasonable job on my own. Eric -

From: Bastian Blank <bastian@waldi.eu.org> Subject: ibmvstgt/aio broken with 2.6.20-rc6 powerpc You use 2.6.20-rc6 with the aio-epoll-wait patch, right? I think that this is due to the aio-epoll-wait patch because without using ibmvstgt target driver, simple aio workload crashes 2.6.20-rc6 with the aio-epoll-wait patch on my POWER box. I cannot recall since when the patch doesn't work on POWER. If you are interested in only ibmvstgt target driver, use the following patch. It uses epoll ...

Acked-by: Alan Cox <alan@redhat.com> Please propogate the mutex_ FIXME comment to both functions as it may well need to cover tty->link -

A more elegant solution would be to do away with the CONFIG and switch to a weak function in the caller. -Andi -

Yes, that's one of the reasons why I dislike klist even more ;-) -

But HIGHPTE uses kmap_atomic (in mainline: does -rt use kmap there?) Hugh -

Simple: we should not implement cmpxchg in generic code. We should be able to use atomic_long_cmpxchg for this -- it will work perfectly regardless of what anybody else tells you. cmpxchg is only required for when that memory location may get modified by some other means than under your control (eg. userspace, in the case of drm, or hardware MMU in the case of Christoph's old page fault scalability patches). -- SUSE Labs, Novell Inc. Send instant messages to your online friends ...

i forgot to explain them: these are updated daily i think. The counters started late October 2006, when FC6 was released. Ingo -

Could we get the read side in separately from the write side? I think I get the read side but the write side still looks scary to me and What exactly is the MTD doing and how does it break? -

Instead of taking one lock we would need to take 4? Wont doing so cause significant locking overhead? We probably would want to run some benchmarks. Maybe disable the scheme for systems with a small number of processors? -

Is this really necessary? We have no atomic_uint_t type either. Could you use atomic_long_t instead? -

Ingo, Got it. http://mmlinux.sourceforge.net/public/patch-2.6.20-rc6-rt2.1.lock_stat.patch This compiles and runs with the CONFIG_LOCK_STAT option turned off now and I believe addresses all of your forementioned concern that you mentioned. I could have missed a detail here and there, but I think it's in pretty good shape now. bill -

Looking at it again sel_remove_bools actually only operates on files backed by selinuxfs, so yes we could use the same approach. -

It was modeled after proc_kill_inodes(), as noted in the comments. So if you have a suitable replacement for proc_kill_inodes(), you can apply -- Stephen Smalley National Security Agency -

This isn't a card problem this is a monitor problem, the card just passes through the edid data from the monitor... or else the programming of the card registers from edid is wrong.. Dave. -

On Sun, 28 Jan 2007 11:48:59 +0100 That's a pretty sad solution. Is it possible to detect these bad cards at runtime via ther behaviour? If not, can we generate a blacklist for the known-bad cards based on PCI IDs or something? Because most users won't even be aware of the module option: they'll just -

It should be in the fb layer not card specific.. as it may happen on any card... Dave. -

Fix DocBook build. Regression was introduced by gregkh-usb-usb-linux-usb_ch9h-becomes-linux-usb-ch9h.patch Tested by `make htmldocs`. Signed-off-by: Don Mullis <dwm@meer.net> Cc: gregkh@suse.de --- Documentation/DocBook/gadget.tmpl | 4 ++-- Documentation/DocBook/usb.tmpl | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) Index: linux-2.6.19/Documentation/DocBook/gadget.tmpl =================================================================== --- ...

On Mon, 29 Jan 2007 16:29:29 +1100 oh. We'd better find those fixes then. I wonder what other code made that (rather hacky) assumption? I guess we have enough debug stuff in there to find out.. -

Sorry for the slow reponse. This bug only came up due to my bad gfs2/dlm patch, which Adrian has now corrected, so I think you can just drop this patch. It now builds for me with only Adrian's gfs2/dlm patch applied. -- ~Randy -

Acked-by: Randy Dunlap <randy.dunlap@oracle.com> -

Hi, Now applied to the GFS2 -nmw git tree. Thanks, Steve. -

"depends on IPV6" would fix the bug - but it would also make NF_CONNTRACK_H323 unavailable for all people without IPV6 support in their kernel. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -

Aliens ate my brain, part 1: I tried building an out-of-tree ipfilters (ipt_osf) that worked fine under 2.6.20-rc4-mm1. After much scratching my head and adding debugging info, I discovered that this code was failing: p = create_proc_entry("sys/net/ipv4/osf", S_IFREG | 0644, NULL); if (!p) { ipt_unregister_match(&osf_match); return -ENXIO; } After much *more* head-scratching, and adding of printk's, I tracked it down into ...

Possibly my (bad) gfs2/dlm patch... Please try applying Adrian Bunk's patch to see if that fixes the IPV6 disappearing trick. (below) --- cu Adrian <-- snip --> This patch fixes a circular dependency by letting GFS2_FS_LOCKING_DLM and DLM depend on instead of select SYSFS. Since SYSFS depends on EMBEDDED this change shouldn't cause any problems for users. Signed-off-by: Adrian Bunk <bunk@stusta.de> --- fs/dlm/Kconfig | 3 +-- fs/gfs2/Kconfig | 3 +-- ...

Does it find sys? If so perhaps I should do something even more significant. I guess if I get many complaints about this I will figure out how to print It is supposed to fail in this instance. If you want something under /proc/sys you are supposed to use register_sysctl like everyone else. If it's not a sysctl it should not show up under /proc/sys. I think I fixed the one in tree instance of this behavior. I'm glad to see my cleanup uncovering more bugs, I'm sorry you were the one who ...

It does not, it was only a last ditch effort before losing power. I was Nope. Thanks for you time. - Armin -

nit: has_vdso, please. -

You need an old toolkit, but the historic section of ftp.funet.fi has a few binaries. I also got a tarball of an old a.out SUSE I simpler fix might be to just not require the vDSO for signal handling on a.out. Here's a untested patch. -Andi Don't require the vDSO for handling a.out signals and in other strange binfmts. vDSO is not necessarily mapped there. Signed-off-by: Andi Kleen <ak@suse.de> Index: ...

Well, there's no way a userspace program could depend on all hidden SSID APs having the <hidden> tag, since if you stick in another, non-ieee80211-stack card it won't be like that. So I don't think we should care about <hidden> in d80211, but I don't think we can remove it from ieee80211 either. The only case where we'll care about it is if we move to common scan-result processing code, and there we may have to put a compat flag in that the driver can set or something. But we ...

What use is it to modularly compile something that almost everybody needs? Regards Oliver -

For every module you waste PAGE_SIZE/2. In my system oliver@valisk:~/Desktop/linux-2.6.20-6-greg> lsmod|wc 46 158 1827 that's 92K. There is a point where the number of people who don't But shrinking the statically compiled kernel isn't one of them. You need to look at the actual memory footprint. Regards Oliver -

For me it was. FC6 has at least CONFIG_MD=y, and SUSE also has some =y that could be =m with the help of module autoload rules, and some =y that could truly be =m. Those being =y cannot be blacklisted. -`J' -- -

Eric, can you write an explanation, add your sign-off, Auke's ACK, and send out the result? The patch looked ok to me, but I do want the more deeper explanation too (and sign-off, of course). Linus -

Yes. A few hundred cycles of loading/unloading snd_hda_intel with enable_msi=1 didn't break it on i386. I sure hope this can get into 2.6.20! -

i've measured it and it takes a few milliseconds typically - certainly not noticeable even for hypothetical highly scripted CPU-hotplug environments. (i doubt they really exist in practice) in fact (new) kprobes uses the freezer, and it's far more performance sensitive than the handling of CPU hotplug events. And there was almost no effort put into making the freezer fast, i'm sure if it ever becomes a problem we could improve it quite drastically. And that effort would improve ...

OK. I've applied the patch and I'm now waiting for the kernel Oops... sometimes it takes two days until it happens. I'm using a standard 16550A serial controller found on my hardware, that is a PC/104 SBC: http://www.icop.com.tw/products_detail.asp?ProductID=70 We have a custom hardware that has another serial controller (TL16C554A) with 4 extra serial ports (also, 16550A type), and the problem happens in a test program that is retreiving data from ttyS0 (from the SBC) and ttyS3 (from our ...

Checked to be sure, on ext2, ext3, reiserfs, XFS symlink timestamps stick across mounts/umounts. Also, looking at disk inode structures of UFS, SysV, JFFS2, GFS2, EFS, I think they should handle lutimesat(2) just fine. -

What do you mean by "filesystems cannot support lutimes"? Filesystems that don't have on-disk timestamps for symlinks? -

On Mon, 29 Jan 2007 17:02:14 -0500 Using your little test app, the longest fsync() stall I can demonstrate on 2.6.20-rc4-mm1 on plain-old-sata-disk is 1.2 seconds. What's the max stall you're able to see with the test app? Perhaps the file is just super-fragmented. If your production app does something like: for (a lot) { fd = open(name); write(fd, a little bit); close(fd); } in multiple threads, or against a lot of different files then you might be fragmenting the files ...

All 64 bit machine will only have a single zone if we have such a range alloc mechanism. The 32bit ones with HIGHMEM wont be able to avoid it, true. But all arches that do not need gymnastics to access their memory The real savings is the simplicity of VM design, robustness and efficiency. We loose on all these fronts if we keep or add useless zones. The main reason for the recent problems with dirty handling seem to be due to exactly such a multizone balancing issues involving ...

Based on searching around for ZONE_DMA32, the following patch appears to be all that is required; diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.20-rc4-mm1-009_backout_zonecount/include/linux/vmstat.h linux-2.6.20-rc4-mm1-010_update_zonecounters/include/linux/vmstat.h --- linux-2.6.20-rc4-mm1-009_backout_zonecount/include/linux/vmstat.h 2007-01-17 17:08:36.000000000 +0000 +++ linux-2.6.20-rc4-mm1-010_update_zonecounters/include/linux/vmstat.h 2007-01-29 16:52:42.000000000 +0000 @@ ...

On Mon, 29 Jan 2007 13:54:38 -0800 (PST) Why do I have to keep repeating myself? 90% of known FC6-running machines are x86-32. 90% of vendor-shipped kernels need all three zones. And the remaining 10% ship with multiple nodes as well. So please stop telling me what a wonderful world it is to not have multiple zones. It just isn't going to happen for a long long time. The multiple-zone kernel is the case we need to care about most by a very large margin indeed. Single-zone is an ...

Yes. If this doesn't work, then we have real problems. If it does, then I try to find the part that is missing in the current code. Larry -

While this may well work (it's basically equivalent to unloading and reloading the module), it's not a long-term fix - userspace is going to notice the interface vanishing and reappearing. Larry, I guess you just mean this as a test patch? -- Matthew Garrett | mjg59@srcf.ucam.org -

Certainly not a problem on x86. But, never mind hugetlb, you still not quite convinced me that there's no problem at all with get_user_pages find_extend_vma growing on ia64. I repeat that ia64_do_page_fault has REGION tests to guard against expanding either kind of stack across into another region. ia64_brk, ia64_mmap_check and arch_get_unmapped_area have RGN_MAP_LIMIT checks. But where is the equivalent paranoia when ptrace calls get_user_pages calls find_extend_vma? If your usual ...

That sounds like syntactical vinegar and a nasty trap. Remember that venus probe that got lost because of a wrong comma. Can you find some nicer syntax for that please? Also it's pretty complex. Are there use cases for all of this? -Andi -

It will work with some luck with firescope (in the worst case you might need to disable suspend in ochi1394). Many laptops have firewire ports. ftp://ftp.firstfloor.org/pub/ak/firescope/ -Andi -

I'd certainly like to see/use it. --- ~Randy -

Oh never mind, sorry. It said "Already up-to-date", but since HTTP I see, thanks. -- Pete -

No, it's still there, and I just did a git clone on it. How does it fail for you? In any case, you're probably better of pulling from Stefans kernel.org tree: git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git since that's where new work is going to show up. I'm still trying to figure out a good workflow for this, but if all patches are going to through linux1394-devel, there's not much point in me publishing a branch in the freedesktop.org repo, if the ...

patching file drivers/net/sky2.c Hunk #1 FAILED at 3675. Hunk #2 succeeded at 3625 (offset -81 lines). Hunk #3 succeeded at 3738 with fuzz 1 (offset -1 lines). Hunk #4 succeeded at 3668 with fuzz 2 (offset -110 lines). 1 out of 4 hunks FAILED -- saving rejects to file drivers/net/sky2.c.rej # grep -c sky2_power_aux drivers/net/sky2.c 0 Shrug. tglx -

And the fix is unnecessary and counter productive on laptops, where ACPI does the right thing. tglx -

On Mon, 29 Jan 2007 14:37:23 -0800 (PST) MSI works fine for almost all systems (except AMD systems where Module option out already exists. -

Just got the same issue on one of my test boxen. Different network card though. The interface comes up fine, but DNS is not working. ifdown/up resolves it. /me keeps an eye on that. tglx -

On Mon, 29 Jan 2007 23:23:21 +0100 But the fix is necessary on laptops where ACPI messes with MSI/INTx on resume. -- Stephen Hemminger <shemminger@linux-foundation.org> -

On Mon, 29 Jan 2007 15:04:06 -0800 (PST) Why do you insist on maintaining the wrong initialization order on resume? When I raised the issue, Len brought up that the resume order did not match spec, but then there has been slow progress in fixing it (it's buried in -mm tree). -- Stephen Hemminger <shemminger@linux-foundation.org> -

FWIW, I just tried it with 2.6.20-rc6, and can confirm. Once nero is run, the kernel never gives up retrying whatever command failed, so I get... [ 4362.972995] hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest } [ 4362.981475] ide: failed opcode was: unknown [ 4362.986183] hdd: drive not ready for command endlessly. -Mike -

Still the same problem. The only difference of this patch to the previous version is, that the unhandled interrupt message is gone. As I said before: Reverting commit 44ade178249fe53d055fd92113eaa271e06acddd, which added this hackery in the first place, makes the device survive suspend/resume. tglx -

Ok, I'm personally heading to bed, but it rally should be as simple as - get the git tree in the first place - do git bisect good v2.6.19 git bisect bad v2.6.20-rc2 .. it will pick a point for you to try .. .. compile, boot, test .. "git bisect {good|bad}" depending on results - until (found) (Of course, you should check that -rc2 really is bad to make sure. I think that's what Uwe reported, though. And I don't think we've done anything after -rc2 that could impact ...

I suspect some BIOSes do *not* screw up the MSI thing on resume, and others do. I would suggest that the real fix is to not do that kind of hackery at suspend/resume time (because we can't know what the heck the BIOS does), and instead just do one of two cases: - since MSI is known to be broken for the sky2 driver due to firmware bugs, just disable it by default if CONFIG_PM is enabled. The advantages of MSI just aren't all that compelling. Possibly add a command line ...

On Mon, 29 Jan 2007 07:26:03 +0100 Do you have time to bisect it? -

this is commit e4233dec749a3519069d9390561b5636a75c7579 meanwhile. Ingo -

Or to make it bounce around onto multiple CPUs, I suppose. Leaving these out for the moment. ;-) Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> --- rcutorture.c | 90 +++++++++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 76 insertions(+), 14 deletions(-) diff -urpNa -X dontdiff linux-2.6.20-rc4-rt1/kernel/rcutorture.c linux-2.6.20-rc4-rt1-rcubtorture/kernel/rcutorture.c --- linux-2.6.20-rc4-rt1/kernel/rcutorture.c 2007-01-09 10:59:54.000000000 ...

I have run some tests with 8 patches from Linus's 2.6 tree on top of the 2.6.16.25 along with a bit of debug code in the n_tty.c, which ran perfectly for 3 days. I now removed the debug code to see if it will still run perfectly with those 8 patches. The patches I applied in order are: commit 70522e121a521aa09bd0f4e62e1aa68708b798e1 commit 41c28ff1635e71af072c4711ff5fadd5855d48e7 commit 1aef821a6b3aeca8c19d06aee012ed9db617d1e3 commit ee37df7877eeaa16d7761cce64854110a7c17ad9 commit ...

Hmm ok, although I still suspect in such a case you'll be better off with a full kcrash dump. -Andi -

My PCI tree is somewhat different to the default one and I did test it but possibly sucked in some dependancies on the cyrix and other early PCI Acked-by: Alan Cox <alan@redhat.com> This is a lot neater than the original patch too. Only problem I see is pci=reverse might need more care. Alan -

"He's got a bug!" What's his bug got to do with me? "He's got a bug!" I ain't trying to hear that, see? But seriously (the above might be too obscure of a reference :), my x86_64 GTOD patches were against vanilla and were not dependent on the HRT patches. There were a few merge/fixup patches in your tree, but I don't recall many of them being really interleaved w/ the HRT code. I'm I missing or forgetting some bit? Should I just revive the old 2.6.20-rc4-mm1 patches against your ...

-- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." -

sounds like it's not the right approach; better to follow the PT_GNU_STACK example and do it that way..... (assuming you even need it... I personally consider every binary that would need this flag as broken) -

I can confirm that this patch is needed for my Intel Mac Mini to resume correctly when used without BIOS emulation (EFI mode). Here're the relevant lspci lines: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics ...

On Mon, Jan 29, 2007 at 11:21:31PM +0100, Frédéric Riss wrote: > Le lundi 29 janvier 2007 à 23:10 +0100, Pavel Machek a écrit : > > > > Ok, I guess we'd like some testing here... so that in can be fixed in > > > > mainline... > > > > > > I can confirm that this patch is needed for my Intel Mac Mini to resume > > > correctly when used without BIOS emulation (EFI mode). Here're the > > > relevant lspci lines: > > > > Can you attach the patch you tested (there was link above, but it ...

Hi, [sorry, somewhat late, had complete and utter heating failure at home] I employed a variant of your patch (added a static i815_dev to support my i815 chipset). It didn't help, X hung on resume. PCI IDs of i815 are 0x1130, 0x1131, 0x1132. I'm having 0x1130 and 0x1131, IOW an i815 system in "external AGP graphics" mode: 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corporation 82815 815 Chipset AGP Bridge ...

Yes, if you change the normal io paths to properly support playing vmsplice games ( which have a number of corner cases ) to get the zero copy, and support madvise() and O_SYNC to control caching behavior, and fix all the error handling corner cases, then you may be able to do away with O_DIRECT. I believe that doing all that will be much more complex than O_DIRECT however. -

Is it really worth adding additional code to shut up this (imho) silly warning? It's just adding needless complexity to drivers. What happens if a driver is used on multiple platforms, some of which support trigger setting and others which don't? Are we going to end up with a large #ifdef in every driver? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -

Hi Pierre, Sorry about the delay. I changed a bit the code to align with your latest suggestions. > drivers/mmc/mmc_sysfs.c: In function