Remove a couple final references to the obsolete verify_area() call, which was long ago replaced by access_ok(). Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> --- it *appears* that these last two references can be removed, unless there's something really strange i'm not seeing here. include/asm-avr32/checksum.h | 2 +- include/asm-avr32/uaccess.h | 6 ------ 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/include/asm-avr32/checksum.h ...

Update: SATAPI works on first-generation chips, but only in PIO mode. To verify that DMA doesn't work I also tried Promise's pdc-ultra driver for their first-generation chips. It doesn't want to support ATAPI without an explicit option. Enabling that option makes it recognise ATAPI devices, but even a simple "eject" command triggers command timeouts and eventually a kernel oops due to the NMI watchdog. So I'm fairly sure that DMA simply doesn't work. This patch enables ATAPI on 20319 and ...

Hello, sorry to ask, will the preemption patches of Ingo Molnar come into the mainstream kernel? Or is this already the case? Gtx Carl. -

For reference, here's the probe routine I tried for 965, probably something dumb wrong with it that I'm not seeing atm. static __init const char *pci_mmcfg_intel_965(void) { u64 pciexbar, mask = 0, len = 0; u32 lo, hi; pci_mmcfg_config_num = 1; pci_conf1_read(0, 0, PCI_DEVFN(0,0), 0x60, 4, &lo); pci_conf1_read(0, 0, PCI_DEVFN(0,0), 0x64, 4, &hi); pciexbar = ((u64)hi << 32) | lo; /* Enable bit */ if (!(pciexbar & 1)) pci_mmcfg_config_num = 0; /* Size bits */ switch ...

Won't help. ext3 does NO readahead at all. It doesn't use the general VFS helper routines to read data (because it doesn't use the page cache), it just does the raw buffer-head IO directly. (In the non-indexed case, it does do some read-ahead, and it uses the generic routines for it, but because it does everything by physical address, even the generic routines will decide that it's just doing random reading if the directory isn't physically contiguous - and stop reading ...

I found that when doing free to the buffer after the vmsplice and befaore the splice syscall, the page is really moved without any memcpy, this means the flow of my application should be: - malloc aligned buffer - fill the buffer with the desired data - vmsplice - free the buffer - call splice. but I still don't get I improvements, and when profing the kernel I see _clear_user_page() too often, I guess this function called to clean the new buffers allocated by the user, for securty and ...

Hello, the following oops appears, after these actions took place: 1. Booting the notebook. 2. Loading ide_core with putting in a USB stick and mounting the filesystem onto it. 3. Remove securely the usb stick. 4. suspend the machine. 5. resume the machine. 6. Do a modprobe ide_core again. Afterwards you can see this oops: notebook1:~ # ksymoops <oops ksymoops 2.4.11 on i686 2.6.18.2-34-default. Options used -V (default) -k /proc/kallsyms (default) -l /proc/modules ...

You seem to be running a SuSE kernel - please report the issue to them. It's probably useful to repeat your test but run "find /sys/module > sys1" before loading ide_core the first time, then "find /sys/module > sys2" after "rmmod ide_core", and save the output of "diff sys1 sys2". Lee -

(forgot to CC LKML) The options, CONFIG_CFAG12864B=y CONFIG_CFAG12864B_RATE=20 causes a crash at boot in 2.6.20-rc3-mm1. I don't have the hardware associated with the options. It looks like it just doesn't have guards to detect if the hardware doesn't exists. Here is the crash, ks0108: ERROR: parport didn't find 888 port BUG: unable to handle kernel NULL pointer dereference at virtual address 0000004 printing eip: c02dbff9 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP last sysfs ...

This is mainly bug fixes, although there are a few harmless updates (like email addresses and driver PCI IDs). The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6 The Short Changelog is: adam radford (1): 3ware 8000 serialize reset code Adrian Bunk (1): qla2xxx: make qla2x00_reg_remote_port() static Akinobu Mita (1): iscsi: fix crypto_alloc_hash() error check Andrew Vasquez (9): qla2xxx: Update version number ...

I can not reproduce it anymore, resume now works. I really hope that it will stay so. Regards, Tino -

It didn't. It looks like it is unusable, becuase it isn't reliable in 2.6.20-rc3. Regards, Tino -

i am writing a module that have to make use in the vmx operations, to enable vmx operations i have to set bit 13 (vmxe bit) in the control registetr cr4 to 1. doing so in a uni cpu platform is not a problem, the question is what to do when working on smp system? to make all the cpus in the smp system support the vmx operations i have to set the that bit in cr4 in each one of them to 1. running the code servel times might always run on just one cpu and therefor not set any other cpu cr4 register ...

Hi. I just wanted to let you know that I tested the version found in git-mmc.patch (from latest -mm kernel) with kernel version 2.6.20-rc3-g6a4306b3 (2 or 3 days ago Linus' GIT tree). No problems so far: the driver seems pretty stable: it survived various suspend-to-ram and suspend-to-disk attempts without a single problem, even with the card inserted and filesystem mounted. Tests were performed with a 2GB SD card, a 512MB MMC card and with a 256 mini-SD. Best regards, Fabio -

It's not BE that is the problem -- drepper thought of that. What he fundamentally missed was the calling convention where 64-bit arguments have to be 64-bit aligned, even when they're passed through registers. So: int foo(int, long long); takes its arguments in arg0, arg2 and arg3, but glibc passes the syscall arguments in arg0, arg1 and arg2. I think the Right Way to fix this is for some gcc hacker to implement an __attribute__((packed_args)) that changes the calling convention ...

While tracking a bug for Thibaut Varene, I noticed that almost all architectures implemented exactly the same sys32_sysinfo... except parisc, where a bug was to be found in handling of the uptime. So let's remove a whole whack of code for fun and profit. Cribbed compat_sys_sysinfo from x86_64's implementation, since I figured it would be the best tested. This patch incorporates Arnd's suggestion of not using set_fs/get_fs, but instead extracting out the common code from sys_sysinfo. Tested ...

diff --git a/arch/ia64/ia32/ia32_entry.S b/arch/ia64/ia32/ia32_entry.S index a32cd59..0a76de0 100644 --- a/arch/ia64/ia32/ia32_entry.S +++ b/arch/ia64/ia32/ia32_entry.S @@ -326,7 +326,7 @@ ia32_syscall_table: data8 sys_ni_syscall data8 compat_sys_wait4 data8 sys_swapoff /* 115 */ - data8 sys32_sysinfo + data8 compat_sys_sysinfo data8 sys32_ipc data8 sys_fsync data8 sys32_sigreturn diff --git a/arch/ia64/ia32/sys_ia32.c b/arch/ia64/ia32/sys_ia32.c index 957681c..d430d36 ...

I have patches for 3.0, 3.1 and (not yet finished) 3.2. As far as I can tell: src/squashfs3.2/squashfs-tools/lzma/README: ======= This directory contains some source files from the 7z archive utility. (www.7-zip.org) All the files in this directory was originally released with the LGPL license. ======= Now "originally released" is somewhat interesting form of expression, but I do not think you can change license post factum. The patches are for "personal use" but I am happy to work ...

Looks like someone corrupted slab->free with 0x55555555. If possible, try running with CONFIG_SLAB_DEBUG enabled to catch the offender. -

Hi, while running "shred /dev/hda3" this night I got the following oops. The keyboard is no longer working, but the machine is up and running. If you need any other information, please let me know, as I will reboot this machine in ~24hours. BUG: unable to handle kernel paging request at virtual address 1b1ca570 printing eip: c014c3b1 *pde = 00000000 Oops: 0000 [#1] Modules linked in: CPU: 0 EIP: 0060:[<c014c3b1>] Not tainted VLI EFLAGS: 00010807 (2.6.19.1 #1) EIP is at ...

From: Heiko Carstens <heiko.carstens@de.ibm.com> [S390] don't call handle_mm_fault() if in an atomic context. There are several places in the futex code where a spin_lock is held and still uaccesses happen. Deadlocks are avoided by increasing the preempt count. The pagefault handler will then not take any locks but will immediately search the fixup tables. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- ...

From: Hongjie Yang <hongjie@us.ibm.com> [S390] memory detection misses 128k. Fix a memory leak problem in the memory detection routines. A memory leak of 128k occurs when we have a contiguous memory with mixed access-mode (read or write) ranges. Signed-off-by: Hongjie Yang <hongjie@us.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- arch/s390/kernel/head31.S | 12 +++++++++++- arch/s390/kernel/head64.S | 12 +++++++++++- 2 files changed, 22 insertions(+), 2 ...

From: Heiko Carstens <heiko.carstens@de.ibm.com> [S390] cio: use barrier() in stsch_reset. Use barrier() in stsch_reset() instead of duplicating the stsch() inline assembly and adding "memory" to the clobberlist. Pointed out by Chuck Ebbert. Real fix would be to add a fixup section to the stsch() and extend the basic program check handler so it searches the exception tables in case of a program check. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin ...

Hi. I use MediaGX with kernel 2.6.19. cirix.c try to find companion chip (CS5510 and CS5520) with pci_devPresent(). However, cyrix.c cannot find a companion chip because a list of pci_devices is not yet initialized when __cpuinit is called. Therefore, Search functions such as the 2.4 kernel which pci_devices list is needless is necessary. How will it be good? -- TAKADA <takada@mbf.nifty.com> -

Hi Takada-san, It is obviously bad. These part is added several years ago by my post. A cyrix.c try to find chip because of chip hardware bug affected to timer which has started early. Now, these chips have already been obsolete. There are 2 options. One is simply remove these functionality. The other is to move it to compile time ifdef that is off by default. For user who use in embbeded environment, I wanna change it to ifdef. Thank you for report! Hiroshi -

A variety of (mostly) innocuous fixes to the embedded kernel-doc content in source files, including: * make multi-line initial descriptions single line * denote some function names, constants and structs as such * change erroneous opening '/*' to '/**' in a few places * reword some text for clarity Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> --- this should give randy something to do. include/asm-i386/atomic.h | 4 ++-- include/asm-i386/bitops.h | 4 ...

Acked-by: Ingo Molnar <mingo@elte.hu> Ingo -

Any strong reason why not? x has some value that does not make sense and can create only problems. And as I explained, it can result in longer code too. So, why keep this value around. Why not re-initialize it to NULL. If x should not be re-initialized to NULL, then by the same logic, we should not even initialize local variables. And all of us know that local variables should be initialized. I would like to know a good reason as to why x should not be set to ...

No, you should not. I suspect that's the basic point you're missing. -

True I guess. But do you want to live in a software environment where as a matter of course every distribution out there puts its "value-add" in custom system calls and creating a $DISTRIBUTION-only userspace? After all, if nothing uses their shiny new custom syscall, they might as well not add it. This would fragment Linux quite horribly and IMO cases where this happens should be _dis_ couraged, not encouraged by making it less problematic to survive the resulting mess. Rene. -

So the vendor is doing something bad, and his customers will pay the price, and they will switch to another vendor who isn't doesn't create traps for their customers. What's the problem? :-) Serious,y you got into trouble in your second sentence --- and not just by the use of the passive voice: "the way chosen is to implement (a) new system call". Don't do that. There are plenty of other ways of requesting kernel services; you can create your own device driver and pass string commands ...

I will come to the main issue later but I just wanted to point out that we maintain information at two separate places - mapping between the name and the number in user space and kernel space. Shouldn't this duplication be removed. Now, let's say a vendor has linux_kernel_version_1 that has 300 system calls. The vendor needs to give some extra functionality to its customers and the way chosen is to implement new system call. The new system call number is 301. The customer gets this custom ...

If we're limited to Linux kernels, this seems to not be the case. Great care is taken in keeping this userspace ABI stable -- new system calls are given new numbers. Old system calls may disappear (after a long grace period) but even then I don't believe the number is ever recycled. If your discussion is not limited to Linux kernels, then sure, but being Some, but your supposition seems unclear. Rene -

What about lzma and squashfs ? Cheers, -- Arkadiusz Patyk [areq<>pld-linux:org] [http://rescuecd.pld-linux.org/] [IRC:areq skype:arekpatyk GG:1383 jid:arek<>patyk:net] -

If you pass SG_IO addresses, they become DMA scatter/gather tables. Jeff -

From: Randy Dunlap <randy.dunlap@oracle.com> setcc() in math-emu is written as a gcc extension statement expression macro that returns a value. However, it's not used that way and it's not needed like that, so just make it a do-while non-extension macro so that we don't use an extension when it's not needed. All 4 .c files that use setcc() produce the same code after this patch. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- arch/i386/math-emu/status_w.h | 5 ...

Is there any reason you this shouldn't be an inline function? -

closing brace on the "while" line, please. Segher -

There's an extra tab in that last line. Could you also please fix the indenting (use a tab, not spaces) -- I know it was there originally, but since there are only a few lines in that file like that... :-) [You must be tired of me by now, heh] Thanks, Segher -

how's this one? --- From: Randy Dunlap <randy.dunlap@oracle.com> setcc() in math-emu is written as a gcc extension statement expression macro that returns a value. However, it's not used that way and it's not needed like that, so just make it a do-while non-extension macro so that we don't use an extension when it's not needed. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- arch/i386/math-emu/status_w.h | 5 +++-- --- arch/i386/math-emu/status_w.h | 7 ...

See the thread "kernel.org lies about latest -mm kernel" on this mailing list. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -

On Sun, Jan 07, 2007 at 07:17:30PM +0000, Russell King wrote: > commit 24ebead82bbf9785909d4cf205e2df5e9ff7da32 > tree 921f686860e918a01c3d3fb6cd106ba82bf4ace6 > parent 264166e604a7e14c278e31cadd1afb06a7d51a11 > author Rafa³ Bilski <rafalbilski@interia.pl> 1167691774 +0100 > committer Dave Jones <davej@redhat.com> 1167799119 -0500 > > and looking at that "author" closer with od: > > 0000140 74 68 6f 72 20 52 61 66 61 b3 20 42 69 6c 73 6b > t h o r R a f ...

I doubt doing this would really be worth the effort. Only if MUAs have broken charset support or don't set a correct "charset" header in the mails they are sending. If some software still can't handle UTF-8 correctly more than 10 years 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 - ...

On Sun, 7 Jan 2007 11:56:01 +0100 (MET) Git tree is fine, Linus has a wonky mailer (that or a problem between keyboard and chair 8)) that sends UTF-8 data in ISO 8859-1 marked email. -

That is an å if you look at the raw message in UTF-8. However, Linus sends mail in with a charset of ISO-8859-1, and if you place UTF-8 encoded text in such a message body, you will see A¥. Welcome to the mess which the UTF-8 charset creates. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -

On Sun, 7 Jan 2007 15:05:53 -0500 Dave Jones <davej@redhat.com> wrote: -

Linus, I can't find 2.6.20-rc4 on the kernel.org home page. Latest shows as:- The latest prepatch for the stable Linux kernel tree is: 2.6.20-rc3 2007-01-01 01:15 UTC ~Akula2 -

On Jan 6 2007 22:19, Linus Torvalds wrote: >Leonard Norrg

$ git log | head -n 1000 | tail -n 200 > o $ file -i o o: text/plain; charset=us-ascii $ git log | head -n 1000 | tail -n 300 > o $ file -i o o: text/plain; charset=us-ascii $ git log | head -n 1000 | tail -n 400 > o $ file -i o o: text/plain; charset=utf-8 (and you know what charset the file is thought to have with all 1000 lines in it.) The same thing actually happens when I look at it via: $ git log | head -n 1000 | less but in this case the output is always interpreted by ...

The stupidity from the start up with those character sets is that they consider that a whole file is written with a given set. In fact, the charset should apply to characters themselves. At least, the quoted-printable, non-human friendly, encoding was the least stupid. Now that UTF8 comes everywhere, everyone receives tons of mangled mails, and even mailers which correctly support UTF8 and use it by default manage to shoot themselves in the foot when they reply to, or forward a mail. ...

I am inclined to say that "file" does not count, because it tries to guess an ambiguous mapping from bytes to character set. Even more, file should be _unable at all_ to distinguish an iso-8859-1 from an iso-8859-2 (or worse: 15) file. This program is soo... forget it, it's not an argument. It works well for headerful files, but text files don't really contain one. The next best thing would be html, with a proper <meta http-equiv=Content> tag. -`J' -- -

What the "file" command thinks is hardly relevant here. "file" just attempts to guess what the contents of a file might be, by applying a simple set of heuristics. Your results only highlight the actual problem: "git" is apparently unable to handle character sets properly For software with proper multilingual support, that should have been enough to make sure that all its output would be in iso-8859-1, too. The loss has happened long before you run that command, when the The problem is ...

Hmm got you. If that's the case can't we do away with the distro mirrors since we have many mirrors & torrents? In this fashion we can reduce huge loads I guess. Or, is it sentimental to have a distro mirror on kernel.org because ~Akula2 -

I think that would be a good idea - and add it to the coding/docs specs that documentation is UTF-8. Code should IMHO say 7bit though. Alan -

Wrong. The problem is partly caused by not everything understanding multi-byte character encodings, and text files containing absolutely _no_ information about their character encodings. When a text file is stored on disk, there's no way to tell what character set the characters in that file belong to. As a result, ISO-8859-1 folk assume that all text files are ISO-8859-1 encoded. UTF-8 folk assume all text files are UTF-8 encoded. This leads to utter confusion. To see what I mean, try ...

Russell King schrieb: Only if the mechanism used for placing it there ignores the different The problem of different character encodings coexisting on the same platform, and the resulting occasional messing-up, far predates Unicode. I distinctly remember one case of being bitten by this myself in 1977 when Unicode wasn't even on the horizon yet, and I don't think that was the first time. Tilman -

Latest Git does this. If the server is later than 1.4.3.3 then the receive-pack process can actually store the pack file rather than unpacking it into loose objects. The downside is that it will copy any missing base objects onto the end of a thin pack to make it not-thin. There's actually a limit that controls when to keep the pack and when not to (receive.unpackLimit). In 1.4.3.3 this defaulted to 5000 objects, which meant all but the largest pushes will be exploded into loose objects. ...

Hi. Cool. I'll have a play :) Thanks! Nigel -

Btw, this isn't the test-case, but it's a half-way re-creation of something like it. It's _really_ stupid, but here's what you can do: - compile and run this idiotic program. It creates a directory called "throwaway" that is ~44kB in size, and if I did things right, it should not be totally contiguous on disk with the current ext3 allocation logic. - as root, do "echo 3 > /proc/sys/vm/drop_caches" to get a cache-cold schenario. - do "time ls throwaway > ...

I wish people would just talk about de2fsrag... ;-\ Rene -

"getdents()" is totally serialized by the inode semaphore. It's one of the most expensive system calls in Linux, partly because of that, and partly because it has to call all the way down into the filesystem in a way that almost no other common system call has to (99% of all filesystem calls can be handled basically at the VFS layer with generic caches - but not getdents()). So if there are concurrent readdirs on the same directory, they get serialized. If there is any file ...

Well, I create my repos by doing a: git clone -l --bare which makes a hardlink from Linus's tree. But then it gets copied over to the public server, which probably severs that hardlink :( Any shortcut to clone or set up a repo using "alternatives" so that we don't have this issue at all? thanks, greg k-h -

With my gitweb caching changes this isn't as big of a deal as the front page is only generated once every 10 minutes or so (and with the changes I'm working on today that timeout will be variable) - John -

Would kernel hackers be amenable to having their trees auto-repacked, and linked via alternatives to Linus's linux-2.6.git? Looking through kernel.org, we have a ton of repositories, however packed, that carrying their own copies of the linux-2.6.git repo. Also, I wonder if "git push" will push only the non-linux-2.6.git objects, if both local and remote sides have the proper alternatives set up? Jeff -

Much better: rsync from /oldfs to /newfs, stop all ftp uploads, rsync again to catch any new files that have been added until the ftp upload was closed, then do _one_ (technically two) mountpoint moves (as opposed to Willy's idea of "some directories") in a mere second along the lines of mount --move /oldfs /older; mount --move /newfs /oldfs. let old transfers that still use files in /older complete (lsof or fuser -m), then disconnect the old volume. In case /newfs (now /oldfs) is a ...

Sorry, it means Linux.conf.au (Australia): http://lca2007.linux.org.au/ ISTM that Linus is trying to make 2.6.20-final before LCA. We'll see. --- ~Randy -

--- ~Randy -

Ok. Do you too think it might help (or even solve) the problem on kernel.org ? Willy -

At work, we had the same problem on a file server with ext3. We use rsync to make backups to a local IDE disk, and we noticed that getdents() took about the same time as Peter reports (0.2 to 2 seconds), especially in maildir directories. We tried many things to fix it with no result, including enabling dirindexes. Finally, we made a full backup, and switched over to XFS and the problem totally disappeared. So it seems that the filesystem matters a lot here when there are lots of entries in ...

Hi. Sorry for the slow reply, and the ignorance... what's an alternatives file? I've never heard of them before. Regards, Nigel -

below is a patch which improves vgetcpu latency on all x86_64 implementations i've tested. Nathan Laredo pointed out the sgdt/sidt/sldt instructions are userland-accessible and we could use their limit fields to tuck away a few bits of per-cpu information. vgetcpu generally uses lsl at present, but all of sgdt/sidt/sldt are faster than lsl on all x86_64 processors i've tested. on p4 processers lsl tends to be 150 cycles whereas the s*dt instructions are 15 cycles or less. lsl ...

Hi sonypi (ex-)maintainers ;-) drivers/char/Kconfig lists SONYPI as being !64BIT, however, there seem to be sony users with x86_64 [1] around. Is it just caution (it's also marked EXPERIMENTAL) or is it definitely known to break on 64bit? -`J' [1] (a german forum) http://www.linux-club.de/viewtopic.php?t=74400&highlight=sonypi -

However, moving to 2.6.20-rc3 does indeed seem to fix the issue thus far... -- Tom Lanyon -

Hi, today I got following bug on my 2.6.20-rc3 vanilla kernel: BUG: at fs/inotify.c:172 set_dentry_child_flags() [<c0179b74>] set_dentry_child_flags+0x5e/0x149 [<c0179cb2>] remove_watch_no_event+0x53/0x5f [<c0179da0>] inotify_remove_watch_locked+0x12/0x3e [<c0179ee2>] inotify_rm_wd+0x6c/0x89 [<c017a58a>] sys_inotify_rm_watch+0x38/0x4f [<c0102cc8>] syscall_call+0x7/0xb [<c02d0033>] fib_validate_source+0x1d8/0x22d ======================= BUG: at fs/inotify.c:172 ...

- pci_find_device is no go today. Use pci_get_device (+ pci_dev_get, _put). - ioremap->pci_iomap - iobase should be __iomem. - codingstyle (char* buffer, for(loop, if(data){, ...) 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 Sun, 07 Jan 2007 05:24:45 -0800 bah. --- a/include/asm-i386/spinlock.h~spin_lock_irq-enable-interrupts-while-spinning-i386-implementation-fix-fix +++ a/include/asm-i386/spinlock.h @@ -14,6 +14,7 @@ #define STI_STRING "sti" #define CLI_STI_CLOBBERS #define CLI_STI_INPUT_ARGS +#define __CLI_STI_INPUT_ARGS #endif /* CONFIG_PARAVIRT */ /* _ -

Now it fails with CONFIG_PARAVIRT off . scripts/kconfig/conf -s arch/i386/Kconfig CHK include/linux/version.h CHK include/linux/compile.h CHK include/linux/utsrelease.h UPD include/linux/compile.h CC arch/i386/kernel/asm-offsets.s In file included from include/linux/spinlock.h:88, from include/linux/module.h:10, from include/linux/crypto.h:22, from arch/i386/kernel/asm-offsets.c:8: include/asm/spinlock.h: In ...

Apologies for the broken patch and thanks for the fix, But, the above is needed to fix the build even with CONFIG_PARAVIRT!!! Apparently because arch/i386/mm/boot_ioremap.c undefs CONFIG_PARAVIRT. Question is, now we have 2 versions of spin_locks_irq implementation with CONFIG_PARAVIRT -- one with regular cli sti and other with virtualized CLI/STI -- sounds odd! Thanks, Kiran -

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 -

If we did that, we'd get thousands of "this link doesn't work". -

-

Should Kernel janitors then care of cleaning orphaned files ?. If so, I should forward it to Andrew Morton without CCing LKML again, right ? -- Ahmed S. Darwish http://darwish-07.blogspot.com -

> Should Kernel janitors then care of cleaning orphaned files ?. If you have the hardware to run tests then yes, if not then they are best handled with caution. Working is preferred to pretty. Alan -

Hi, The code isn't really supposed to deal with it, at most they could be replaced with a variant that prints an error message and exits. bye, Roman -

Acked-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> [ but the patch is line wrapped ] -

That would require changing the interface provided by the rtc class, but -- -

If you're thinking of going that way, it'd be courteous to CC Matt, who devoted some effort to removing just that loop in 2.6.17 ;) Hugh -

Hmm ... "git whatchanged drivers/rtc/hctosys.c" shows no such change. So I can't find any record of such a change or its rationale. - dave -

On Mon, 8 Jan 2007 09:23:41 +1100 That would be conventional. -

/me looks at how it's used in invalidate_inode_pages2_range() and .... in that case the following patch should fix the warning: --- fs/xfs/linux-2.6/xfs_fs_subr.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_fs_subr.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_fs_subr.c 2006-12-12 12:05:17.000000000 +1100 +++ ...

I can't test it here, since I'm travelling at the moment, but Acked-by: Arnd Bergmann <arndb@de.ibm.com> -

Yes, but this is simply from experience. Several modules wrote msrs Several modules implement alternate halt loops. I guess being in a module for specific CPUs makes sense... Cheers! Rusty. -

Several in tree, GPL'd modules did so. I'm not aware of out of tree modules that do that, and if they do, they are misbehaving. Reprogramming MTRR memory regions under the kernel's nose is not a proper way to behave, and this is the most benign use I can think of for write access to MSRs. If this really breaks any code out there, then there should be a proper, controlled API to do this so the kernel can Yes, but halting is a behavior that can easily introduce critical, grind to a ...

Guilty as charged :/ cheers --=20 Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person

Thanks for the reply, Andrew. How interesting... added that to kmod.c, rebuilt without change to config, reboot.... machine booted perfectly! I'm going to leave it for now, but I'll leave the dump_stack() call in there in case further issues arise. Regards -- Tom Lanyon -

Very impressive! The gain probably comes not only from avoiding the vmentry/vmexit, but also from avoiding the flushing of the global page This is a little too good to be true. Were both runs with the same KVM_NUM_MMU_PAGES? I'm also concerned that at this point in time the cr3 optimizations will only show an improvement in microbenchmarks. In real life workloads a context switch is usually preceded by an I/O, and with the current sorry Well, you did say it was ad-hoc. For ...

After all the Novell Marketing Hype you'll probably have to keep Xen ;-) Except for that I suspect a paravirt kvm or lhype might be the better hypervisor choice in the long term. -

Would shoW-blocked-tasks be OK? --- From: Randy Dunlap <randy.dunlap@oracle.com> Change SysRq showBlockedTasks from sysrq-X to sysrq-W and show that in the Help message. It was previously done via X, but X is already used for Xmon on ppc & powerpc platforms and this collision needs to be avoided. All callers of register_sysrq_key() are now marked in the sysrq op/key table. I didn't mark 'h' as Help because Help is just printed for any unknown key, such as '?'. Added some omitted ...

Woody will be using a Netwinder (he's part of the original development team.) So no sleep states and therefore no wakeup. There's various other ARM-based systems using the PC RTC, but none of them have sleep or wakeup abilities afaik. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -

Can we shout a bit less? Pavel -- Thanks for all the (sleeping) penguins. -

It is fragile for this code to depend on link order; Adrian's obvious and trivial cleanups broke it. Not only that, but some FC kernels had/have the link order reversed such that this quirk is broken anyway. I sent a patch for this back in May: http://lists.lm-sensors.org/pipermail/lm-sensors/2006-May/016113.html There was some discussion on the linux-pci mailing list as well; can't seem to find an archive of that though. Basically, it was not understood how the FC kernels could have a ...

Confirming that reiser4-sb_sync_inodes-fix.patch fixes my problem.

This fixed for me too with kernel 2.6.19.1. On my machine, every second trial to unplug the second CPU core were generating OOPS, and breaking hibernation. I've opened a bugzilla (#7786). There is a remain stuff to be fixed, related to cpuhotplug: kernel with debug options enabled shows that there is a circular locking dependency (http://bugzilla.kernel.org/attachment.cgi?id=10020&action=view): ======================================================= [ INFO: possible circular locking ...

Hi Eric, I tried recompiling the kernel per your instructions, but I got a failure here: CC [M] drivers/message/fusion/mptbase.o drivers/message/fusion/mptbase.c: In function ‘mpt_resume’: drivers/message/fusion/mptbase.c:1526: warning: ignoring return value of ‘pci_enable_device’, declared with attribute warn_unused_result CC [M] drivers/message/fusion/mptscsih.o drivers/message/fusion/mptscsih.c: In function ‘mptscsih_initTarget’: ...

I don't see which libs you are talking about. The compiler you build your kernel with is totally independant on the compiler you build your apps with. A few years ago, some distros even shipped a compiler just for the kernel (they called the binary "kgcc"). So you just have to build 2 different GCC, one for 2.4, one for 2.6 and you use them to build your kernels. If you want yet another compiler for your apps, simply do it, it's not a problem. For instance, look on my system when I type gcc- ...

That's correct about gcc-3.4.x & gcc-4.1.x about 2.6 tree support. This means 2.6 supports both gcc versions. Here are the binaries I do use:- http://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os/Fedora/RPMS/gcc-3.4.... http://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os/Fedora/RPMS/kernel-2... Now issue remains with 2.4 tree. Is it possible to build/install gcc-4.1.x along with gcc-3.4.x? This is what am trying to figure by few tests ...

2.4 was designed for gcc 2.95.3 and supports gcc up to 3.4 on all platforms, and up to 4.1 on x86, x86_64, ppc and sparc64. Recent gcc 3.4 produces good code on 2.4, and is able to efficiently optimize for size (-Os) without too Hmm, I think you did it the *hard* way. Gcc has been supporting multi-version for years. You just have to compile it with --suffix=-3.4 or --suffix=4.1 to have a whole collection of gcc versions on your host. If you don't want to recompile gcc, simply rename the ...

How about: CPU_DEAD does nothing. After __cpu_disable() cwq->thread runs on all CPUs and becomes idle when it flushes cwq->worklist: nobody will add work_struct on that list. CPU_UP: if (!cwq->thread) create_workqueue_thread(); else set_cpus_allowed(newcpu); flush_workqueue: for_each_possible_cpu() // NOT online! if (cwq->thread) flush_cpu_workqueue() Oleg. -

How would this provide a stable access to cpu_online_map in functions that need to block while accessing it (as flush_workqueue requires)? -- Regards, vatsa -

I guess you could have cwq->thread flush only it's cpu's workqueue by running on another cpu, which will avoid the need to synchronize between worker threads. I am not 100% sure if that breaks workqueue model in any way (since we could have two worker threads running on the same CPU, but servicing different queues). Hopefully it doesnt. -- Regards, vatsa -

On Sun, 7 Jan 2007 16:30:13 +0530 If a thread simply blocks, that will not permit a cpu plug/unplug to proceed. The thread had to explicitly call try_to_freeze(). CPU plug/unplug will not occur (and cpu_online_map will not change) until every process in the machine has called try_to_freeze()). So the problem which you're referring to will only occur if a workqueue callback function calls try_to_freeze(), which would be mad. Plus flush_workqueue() is on the way out. We're slowly ...

Also, we can add cpu_workqueue_struct->should_exit_after_flush flag, but -

Srivatsa, I'm completely new to cpu-hotplug, so please correct me if I'm wrong (in fact I _hope_ I am wrong) but as I see it, the hotplug/workqueue interaction is broken by design, it can't be fixed by changing just locking. Once again. CPU dies, CPU_DEAD calls kthread_stop() and sleeps until cwq->thread exits. To do so, this thread must at least complete the currently running work->func(). work->func() calls flush_workque(WQ), it does lock_cpu_hotplug() or _whatever_. Now the question, ...

^^^ If CPU_DEAD does nothing, then the dead cpu's workqueue list may be non-empty. How will it be flushed, given that no thread can run on the dead cpu? We could consider CPU_DEAD moving over work atleast (and not killing worker threads also). In that case, cwq->thread can flush its work, however it now requires serialization among worker threads, since more than one worker thread can now be servicing the same CPU's workqueue list (this will beat the very purpose of maintaining per-cpu ...

Hmm... there are some discussions currently on v4l ML about the need to add some standards to support some digital streams, like those used on webcams. Depending on the result of those discussions, we can need to use more bits. So, I think it is not worth right now to replace video std on every place it occurs. Ok, I've wrote such patch. I should send today or tomorrow to Linus, Cheers, Mauro. -

Yeah. For a more relevant case, look at the hoops we used to jump through to get "memcpy()" to generate ok code for trivial fixed-sized cases. (That said, I think __builtin_memcpy() does a reasonable job these days with gcc, and we might drop the crap one day when we can trust the compiler to do ok. It didn't use to, and we continued using our ridiculous macro/__builtin_constant_p misuses just because it works with _all_ relevant gcc versions). Linus -

I'd say "care about obvious, safe optimizations which we still not do". I want this: char v[4]; ... memcmp(v, "abcd", 4) == 0 compile to single cmpl on i386. This (gcc 4.1.1) is ridiculous: .LC0: .string "abcd" .text ... pushl $4 pushl $.LC0 pushl $v call memcmp addl $12, %esp testl %eax, %eax There are tons of examples where you can improve code generation. -- vda -

Oh, that still hasn't been fixed? Generic bug, not XFS - the global semaphore->mutex cleanup converted the bd_mount_sem to a mutex, and mutexes complain loudly when a the process unlocking the mutex is not the process that locked it. Basically, the generic code is broken - the bd_mount_mutex needs to be reverted back to a semaphore because it is locked and unlocked by different processes. The following patch does this.... BTW, Sami, can you cc xfs@oss.sgi.com on XFS bug reports in ...

Hello, Mark Wagner wrote: It seems like your system is falling apart. Timeouts are occurring everywhere. Either IRQ routing went wrong or your powersupply is not providing enough power. Adding two more disks to sil24 doesn't change anything about IRQ routing. If the system functioned okay w/ two disks attached to sil24, give your system a better power supply or rewire power cables such that each power lane is more equally loaded. -- tejun -

On Sunday 07 January 2007 00:36, Pavel Machek wrote: The primary reason it's not 4KSTACKS already is that I run multiple XFS partitions on top of an md RAID 1. LVM isn't involved, however, and I'm not using any other filesystem overlays like dm. I'm fairly sceptical that it's a stack overflow, but I'll be sure to enable Well, GCC 3.4 kernels seem to run fine with it, but as I said to Linus I'll be sure to turn this and the sound drivers off in the next build. -- ...

How is it for efficiency? I thought it was for correctness. romsignature is using probe_kernel_adress() while all other accesses to the ROMs there aren't. If nothing else, anyone reading that code is likely to ask himself the very same question -- why the one, and not the others. Rene. -

Why? It's a bit of a performance hit, but that doesn't matter here. probe_kernel_address() is semantically the right thing to be using; open-coding its contents to avoid a few fairly cheap operations is a My point is that "__get_user" doesn't make much semantic sense here: we're not talking about usermode pages. We used to use it quite often for cases where an access may or may not fault, but now we spell that I don't strongly object to using probe_kernel_address() for all ROM memory ...

The malformed HTML was generated after switch to XSLTPROC from SGML tools. The reference title <refentrytitle><phrase id="API-struct-x">struct x</phrase></refentrytitle> is converted into two recursive <a> tags <a href="re02.html"><span><a id="API-struct-x"></a>struct x</span></a> There is more possible solutions for this problem. One can be found at http://darkk.livejournal.com/ The proposed solution is based on suggestion provided by Jiri Kosek. Signed-off-by: Pavel Pisa ...

OK, so the bottom line we seem to have reached is that we can't manage the user coherency in the DMA API. Does this also mean you can't do it for non-DMA cases (kmap_atomic would seem to be a likely problem)? in which case the only coherency kmap would control would be kernel coherency? James -

I eventually found it ("Local APIC support on uniprocessors") in menuconfig. In the meantime, I'd moved my 32-bit activity to a different box (also athlon64, but a bit faster) and I had one oops on that. At least, I assume it was an oops - the caps and scroll LEDs flashed, but I couldn't do anything with MagicSysrq, not even force a reboot. Ran diff on the various configs, changed to IO-APIC plus an unrelated change to use libata for the cdrom. The faster box _seems_ stable (used for a ...