Re: Unreliable TCP?

On Sat, Mar 19, 2005 at 09:59:16PM -0500, Ioan Ionita wrote: > Hello. I apologize if this may sound stupid/unknowledgeable. I'm > currently fooling around with real time voice conferencing > applications which use the UDP protocol. However, certain firewalls > don't allow UDP traffic, therefore

RDMA (Remote Direct Memory Access)

Hi Is there any plan to support RDMA in Linux ? what is the status ? my question is because I know that windows HPC project will support RDMA in release 2 and they also will support infiniband They also will support Intel Xeon 64 or the AMD Opteron only -- Best Regards,

Re: [patch 1/4] crypto/sha256.c: fix sparse warnings

[EMAIL PROTECTED] wrote: > > diff -puN crypto/sha256.c~sparse-crypto_sha256 crypto/sha256.c > --- kj/crypto/sha256.c~sparse-crypto_sha256 2005-03-18 20:05:34.0 > +0100 > +++ kj-domen/crypto/sha256.c2005-03-18 20:05:34.0 +0100 > @@ -58,7 +58,7 @@ static inline u32 Maj(u32

Re: [Patch] cpusets policy kill no swap

Interesting comments, Andrew. Thanks It will likely be a couple of days before I respond to them. I suspect a couple of us SGI folks should powwow first. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson

Re: [Patch] cpusets policy kill no swap

Paul Jackson <[EMAIL PROTECTED]> wrote: > > This mechanisms differs from a general purpose out-of-memory > killer in various ways, including: > > * An oom-killer tries to score the bad buy, to avoid shooting > the innocent little task that just happened to ask for one > page too many.

[PATCH] Error in ERR_PTR usage

Was trying to understand ERR_PTR and friends and surprisingly the first 2 references via LXR seem to be erroneous. Did grep and found 1 additional incorrect reference "return ERR_PTR(0)" and another "ERR_PTR(PTR_ERR(p))" usage. Please let me know if this patch is good. If need be, I can chop it up

Re: Nasty ReiserFS bug in 2.6.12-rc1, 2.6.12-rc1-bk1

Bob Gill <[EMAIL PROTECTED]> wrote: > > Hi. I have built 2.6.12-rc1 and 2.6.12-rc1-bk1. There seems to be a > nasty bug in ReiserFS (things are fine in 2.6.11.4). Looks like the problem lies elsewhere. > The system wants > to un-configure my SCSI Adaptec devices, and stall at "starting Hal >

Re: dmesg verbosity [was Re: AGP bogosities]

On Mon, 14 Mar 2005, Lee Revell wrote: On Mon, 2005-03-14 at 19:12 +0100, Diego Calleja wrote: Why should people look at all that "horrid" debug info everytime they boot, except when they have a problem? I'm really not trolling, but I suspect if we made the boot process less verbose, people would

Re: race between __sync_single_inode() and iput()/bdev_clear_inode()

OGAWA Hirofumi <[EMAIL PROTECTED]> wrote: > > ... > I got the above Oops while doing fs stress test. > > The cause of this was race condition between __sync_single_inode() and > iput()/bdev_clear_inode(). > > This race seems following condition. > > cpu0 (fs's inode)

Re: Real-Time Preemption and RCU

Ingo Molnar wrote: which precise locking situation do you mean? cpu 1: acquire random networking spin_lock_bh() cpu 2: read_lock(_lock) from process context interrupt. softirq. within softirq: try to acquire the networking lock. * spins. cpu 1: hardware interrupt within hw interrupt: signal

Re: Build issue current MIPS - RaQ2

Jim Gifford <[EMAIL PROTECTED]> wrote: > > I have not been able to build kernels since 2.6.9 on my RaQ2 for some > time. I have tried the linux-mips.org port and the current 2.6.11.5 > release. I keep getting the same error. > >Building modules, stage 2. >MODPOST > *** Warning:

Patch for iomap on MIPS was Re: Build issue current MIPS - RaQ2

Jim Gifford wrote: I have not been able to build kernels since 2.6.9 on my RaQ2 for some time. I have tried the linux-mips.org port and the current 2.6.11.5 release. I keep getting the same error. Building modules, stage 2. MODPOST *** Warning: "pci_iounmap" [drivers/net/tulip/tulip.ko]

Re: [PATCH][0/6] Change proc file permissions with sysctls

On Sun, 2005-03-20 at 01:22 +0100, Rene Scharfe wrote: > The permissions of files in /proc/1 (usually belonging to init) are > kept as they are. The idea is to let system processes be freely > visible by anyone, just as before. Especially interesting in this > regard would be instances of

Re: ppc64 build broke between 2.6.11-bk6 and 2.6.11-bk7

--Andrew Morton <[EMAIL PROTECTED]> wrote (on Thursday, March 17, 2005 22:44:09 -0800): > "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: >> >> drivers/built-in.o(.text+0x182bc): In function `.matroxfb_probe': >> : undefined reference to `.mac_vmode_to_var' >> make: *** [.tmp_vmlinux1] Error 1

Re: Unreliable TCP?

On Sat, 19 Mar 2005 21:59:16 EST, Ioan Ionita said: > applications which use the UDP protocol. However, certain firewalls > don't allow UDP traffic, therefore I tried UDP over TCP as a > workaround. That's the firewall's problem, not yours. There's very few firewalls that prohibit *all* UDP

Re: [PATCH 2.6.11.2][RFC] printk with anti-cluttering-feature

su den 20.03.2005 Klokka 05:37 (+0100) skreiv Bodo Eggert: > (I hope I avoided all spam-keywords this time, my previous mails didn't > seem to make it) > (please CC me on reply) > > Issue: > > On some conditions, the dmesg is spammed with repeated warnings about the > same issue which is

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00

On Sat, 2005-03-19 at 19:50 -0600, K.R. Foley wrote: > Lee Revell wrote: > > On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote: > > > >>the biggest change in this patch is the merge of Paul E. McKenney's > >>preemptable RCU code. The new RCU code is active on PREEMPT_RT. While it > >>is still

[PATCH 2.6.11.2][RFC] printk with anti-cluttering-feature

(I hope I avoided all spam-keywords this time, my previous mails didn't seem to make it) (please CC me on reply) Issue: On some conditions, the dmesg is spammed with repeated warnings about the same issue which is neither critical nor going to be fixed. This may result in losing the boot

Re: [PATCH][0/6] Change proc file permissions with sysctls

On Sun, 20 Mar 2005, Rene Scharfe wrote: > The permissions of files in /proc/1 (usually belonging to init) are > kept as they are. The idea is to let system processes be freely > visible by anyone, just as before. Especially interesting in this > regard would be instances of login. I think you

proposal

Dear friend, I am lady of the Anglican communion Knight Hood.Am lady julliet fish.I am the PRO and in charge of a trust fund put together by a group of very wealthy christian business men who over the years have donnated bountifully to orphanages, less privilledged and victims of war.This group

proposal

Dear friend, I am lady of the Anglican communion Knight Hood.Am lady julliet fish.I am the PRO and in charge of a trust fund put together by a group of very wealthy christian business men who over the years have donnated bountifully to orphanages, less privilledged and victims of war.This group

Re: Relayfs question

Jan Engelhardt wrote: > Well, what about things like urandom? It also moves "a lot" of data and does > nothing else. Forgive my slowness today, but I don't get the angle here: - Relayfs is not a replacement for char devices, we've never claimed it to be. - Urandom generates a lot of data, and

[PATCH] rename FPU_*verify_area to FPU_*access_ok

Since verify_area is going the way of the Dodo soon it seems resonable to no longer refer to it in wrapper functions/macros. FPU_verify_area and FPU_code_verify_area have already been converted to call access_ok so now seems a good time to rename them. This patch makes no functional changes at

Re: 2.6.12-rc1 breaks dosemu

On Saturday 19 March 2005 21:11, Adrian Bunk wrote: >xdosemu 1.2.2 runs fine under 2.6.11.5, but fails under 2.6.12-rc1 > with the following error: > I just tried it here, and its ok while running 2.6.12-rc1 ><-- snip --> > >$ xdosemu >ERROR: cpu exception in dosemu code outside of VM86()!

Unreliable TCP?

Hello. I apologize if this may sound stupid/unknowledgeable. I'm currently fooling around with real time voice conferencing applications which use the UDP protocol. However, certain firewalls don't allow UDP traffic, therefore I tried UDP over TCP as a workaround. This failed miserably, as the

Re: [PATCH] _raw_read_trylock for alpha

On Sat, Mar 19, 2005 at 03:39:33PM -0500, Jeff Garzik wrote: > Don't send this patch upstream until its been verified to actually work. It certainly won't. I'll gen up something soon. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

SMP boot failure, Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00

Not subscribed, so please forgive the unthreaded post. As per K.R. Foley's report, booting on SMP fails. I tried & failed to capture the boot messages via serial, so the best I can offer is a pic of what remained visible on screen at the death.

[PATCH] remove redundant NULL checks before kfree() in sound/ and avoid casting pointers about to be kfree()'ed

Checking a pointer for NULL before calling kfree() on it is redundant, kfree() deals with NULL pointers just fine. This patch removes such checks from sound/ This patch also makes another, but closely related, change. It avoids casting pointers about to be kfree()'ed like this for example :

2.6.12-rc1 breaks dosemu

xdosemu 1.2.2 runs fine under 2.6.11.5, but fails under 2.6.12-rc1 with the following error: <-- snip --> $ xdosemu ERROR: cpu exception in dosemu code outside of VM86()! trapno: 0x0e errorcode: 0x0005 cr2: 0xff8e eip: 0x69ee esp: 0xbfdbffcc eflags: 0x00010246 cs: 0x0073 ds:

Re: [CHECKER] crash after fsync causing serious FS corruptions (ext2, 2.6.11)

Hello Ted, In article <[EMAIL PROTECTED]> you wrote: > Should we fix it today? Given that we have ext3, I'd probably answer > no. It's a known property of ext2; we've lived with it for over ten > years, and to add this would just slow down ext2 (which gets used > often as benchmark standard to

[Patch] cpusets policy kill no swap

Question: Should I call oom_kill_process(), oom_kill_task(), or __oom_kill_task(), when the current task decides that it is better to die than to swap, so calls the routine mm/oom_kill.c:oom_attempt_suicide() that this patch adds, below? My best

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00

Lee Revell wrote: On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote: the biggest change in this patch is the merge of Paul E. McKenney's preemptable RCU code. The new RCU code is active on PREEMPT_RT. While it is still quite experimental at this stage, it allowed the removal of locking cruft

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00

On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote: > the biggest change in this patch is the merge of Paul E. McKenney's > preemptable RCU code. The new RCU code is active on PREEMPT_RT. While it > is still quite experimental at this stage, it allowed the removal of > locking cruft (mainly in

Re: [patch 1/4] security/selinux/ss/policydb.c: fix sparse warnings

On Sat, 19 Mar 2005 [EMAIL PROTECTED] wrote: > kj-domen/security/selinux/ss/policydb.c | 35 > ++-- > 1 files changed, 20 insertions(+), 15 deletions(-) Have you tested these changes? - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this

SATA VIA8237 Problems (Install)

I have a KT600 based motherboard & I am planning to set up my new system using that. It has onboard via 8237 sata {raid, cough cough} controller. I am planning to use a single sata disk (I am not interested in raid). The various distro installers are having tough time noticing a brand new

Mail from batman

Attn sir, I am Mr. Batman cole the manager of ITT bank, Mr Haryanto Tomo from indonesia deposited the sum of U$10million in our bank, right now he is one of the viticms of the tsunami in asia that kill thousands. Sir, if you are willing to receive this money in your account as his next of kin

Re: [patch] arch hook for notifying changes in PTE protections bits

On Sat, 19 Mar 2005 12:30:05 -0800 David Mosberger <[EMAIL PROTECTED]> wrote: > I agree about your concern about cost. Accessing the page_map is > expensive (integer division + memory access) and we have to do that in > order to find out if the page is i-cache clean. First, it's a multiply by

Re: swsusp: Remove arch-specific references from generic code

Hi, On Saturday, 19 of March 2005 23:07, Pavel Machek wrote: > Hi! > > Do you think you could just send me diff between 2.6.12-rc1 and your > tree? I'll merge it here. Sure, no problem, the diff follows. :-) It contains the following changes: - remove swsusp_restore() (with the fix to return

Re: [KBUILD] Bug in make deb-pkg when using seperate source and object directories

On Mon, Mar 14, 2005 at 11:59:26AM -0800, Ajay Patel wrote: > I had a similar problem building binrpm-pkg. > Try following patch. It worked for me. My problem wasn't actually resolved by this - the make in builddeb still caused issues. So, a normal, unified diff form of the patch, fixed up, is

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00

On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote: > i have released the -V0.7.41-00 Real-Time Preemption patch (merged to > 2.6.12-rc1), which can be downloaded from the usual place: > > http://redhat.com/~mingo/realtime-preempt/ > 3ms latency in the NFS client code. Workload was a

[PATCH][0/6] Change proc file permissions with sysctls

The following patches implement another interface that allows an admin to restrict permissions inside /proc/ to enhance the privacy of users. Following a suggestion by Albert Calahan this set of patches introduces five sysctls, each one changes the permissions of a certain file in /proc/. It

[PATCH] get rid of redundant NULL checks before kfree() in arch/i386/

Checking a pointer for NULL before calling kfree() on it is redundant, kfree() deals with NULL pointers just fine. This patch removes such checks from files in arch/i386/ Since this is a fairly trivial change (and the same change made everywhere) I've just made a single patch for all four files

[PATCH] disable builtin modules

This patch makes it possible to disable built in code from the kernel command line. The patch is rather simple - it extends the compiled-in case of module_init() to include __setup() with a name based on KBUILD_MODNAME. Problem: Say that your Firewire PHY breaks and you find yourself unable to

[PATCH] gcc-4.0 compatibility fixes for i386, m68k, ppc64, x86_64

gcc-4.0 fails with "error: array type has incomplete element type" (see http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html) on several files in linux-2.6.11.3. Who knows, maybe all this is fixed in the -mm tree already, but what the heck, here are a few fixes I haven't seen anyone else post yet.

Re: [PATCH] alpha build fixes

On Sat, Mar 19, 2005 at 03:11:16PM -0800, Richard Henderson wrote: > On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote: > > +/* TODO: integrate with include/asm-generic/pci.h ? */ > > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel) > > +{ > > + return

Re: [PATCH] alpha build fixes

On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote: > +/* TODO: integrate with include/asm-generic/pci.h ? */ > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel) > +{ > + return channel ? 15 : 14; > +} Am I missing something, or is this *only* used by

Re: [2.6 patch] fix bridge <-> ATM compile error

On Thu, Mar 17, 2005 at 03:36:40PM -0500, chas williams - CONTRACTOR wrote: > In message <[EMAIL PROTECTED]>,Adrian Bunk writes: > >Letting CONFIG_BRIDGE depend on CONFIG_ATM doesn't sound like a good > >idea, since I doubt all people using the Bridge code require ATM > >support. > > how about

[PATCH] remove redundant NULL checks before kfree() in drivers/video/

Checking a pointer for NULL before calling kfree() on it is redundant, kfree() deals with NULL pointers just fine. This patch removes such checks from files in drivers/video/ Since this is a fairly trivial change (and the same change made everywhere) I've just made a single patch for all the

Re: [MC] [CHECKER] Do ext2, jfs and reiserfs respect mount -o sync/dirsync option?

* Bernd Eckenfels: > In article <[EMAIL PROTECTED]> you wrote: >> 3. I open a file w/o O_SYNC, issue a bunch of writes, then call >> ioctl(FIOASYNC) to set the fd sync, then issure a second set of writes. >> Only the second set of writes are synchronous? > > I also am curious if one can open a

Re: Linux 2.6.11.5

Hi Greg, The changelog states that the patches for the AMD8111e and VIA-Rhine originated from dilingerdebian.org although I was the one who they originated from. http://article.gmane.org/gmane.linux.kernel/282245 http://article.gmane.org/gmane.linux.kernel/282263 : o Possible AMD8111e free

Re: [PATCH] partitions/msdos.c

On Sat, 19 Mar 2005, Werner Almesberger wrote: Andries Brouwer wrote: The two variants are: (i) partition tells the kernel to do the partition table reading, and (ii) partition uses partx to read the partition table and tells the kernel one-by-one about the partitions found this way. I guess, once

Re: [PATCH] clean up FIXME in do_timer_interrupt-lock fix

Andrew Morton wrote: George Anzinger wrote: Did you pick this up? First sent on 3-11. I did, although now looking at it I have issues. I was not happy with the locking on this. Two changes: 1) Turn off irq while setting the clock. 2) Call the timer code only through the timer interface

Re: [PATCH 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation

On Sat, Mar 19, 2005 at 08:26:45PM +0100, Andi Kleen wrote: > On Fri, Mar 18, 2005 at 03:23:44PM -0600, Matt Domsch wrote: > > For review and comment. > > > > On x86_64 systems with no IOMMU and with >4GB RAM (in fact, whenever > > there are any pages mapped above 4GB), pci_alloc_consistent()

Re: Bitrotting serial drivers

Russell King <[EMAIL PROTECTED]> wrote: > > Hi, > > m32r_sio > > > Maintainer: Hirokazu Takata > > Please clean up the m32r_sio driver, removing whatever bits of code > aren't absolutely necessary. > > Specifically, I'd like to see the following addressed: > > - the usage of

[patch] Trivial patch to update a comment in drivers/video/s1d13xxxfb.c

Trivial patch to update a comment in drivers/video/s1d13xxxfb.c Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- linux-2.6.11-mm4-orig/drivers/video/s1d13xxxfb.c2005-03-16 15:45:26.0 +0100 +++ linux-2.6.11-mm4/drivers/video/s1d13xxxfb.c 2005-03-19 22:45:10.0 +0100 @@

Re: Scheduling changes in -mm tree

"Martin J. Bligh" <[EMAIL PROTECTED]> wrote: > > I don't think these are doing much for performance. Or at least > *something* in your tree isn't ... > > Kernbench: > ElapsedSystem User CPU > elm3b67 2.6.11 50.24

Re: swsusp: Remove arch-specific references from generic code

Hi! Do you think you could just send me diff between 2.6.12-rc1 and your tree? I'll merge it here. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg

Re: [PATCH] partitions/msdos.c

Andries Brouwer wrote: > In other words, we need the user space command `partition', > where "partition -t dos /dev/sda" reads a DOS-type partition > table. So if you e.g. hotplug a new device, its partitions won't be accessible before you (or some hotplug manager, etc.) run "partition" ? > The

Re: Latency tests with 2.6.12-rc1

On Sat, 2005-03-19 at 02:51 -0500, Lee Revell wrote: > On Sat, 2005-03-19 at 08:08 +0100, Ingo Molnar wrote: > > great! The change in question is most likely the copy_page_range() fix > > that Hugh resurrected: > > > > ChangeSet 1.2037, 2005/03/08 09:26:46-08:00, [EMAIL PROTECTED] > > > >

Re: Suspend-to-disk woes

On Saturday 19 March 2005 13:29, Pavel Machek wrote: > On So 19-03-05 12:20:35, Russell Miller wrote: > > On Saturday 19 March 2005 05:26, Pavel Machek wrote: > > > Checking that would be hard, but you might want to provide patch to > > > check last-mounted dates of filesystems and panic if they

Re: swsusp: Remove arch-specific references from generic code

Hi! > swsusp-suspend_pd_pages-fix.patch Could you drop this one? It is "fixing" unused macro, we don't want it going anywhere. > suspend-to-ram-update-videotxt-with-more-systems.patch > > I've been ducking all the "swsusp_restore crap" patches. Pavel, could you > please aggregate, test and

Re: Suspend-to-disk woes

On So 19-03-05 12:20:35, Russell Miller wrote: > On Saturday 19 March 2005 05:26, Pavel Machek wrote: > > > Checking that would be hard, but you might want to provide patch to check > > last-mounted dates of filesystems and panic if they changed. > > Pavel > > Then

Re: swsusp: Remove arch-specific references from generic code

"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > On Wednesday, 16 of March 2005 01:12, Pavel Machek wrote: > > Hi! > > > > This is fix for "swsusp_restore crap"-: we had some i386-specific code > > referenced from generic code. This fixes it by inlining tlb_flush_all > > into assembly. >

Re: [PATCH] clean up FIXME in do_timer_interrupt-lock fix

George Anzinger wrote: > > Did you pick this up? First sent on 3-11. I did, although now looking at it I have issues. > I was not happy with the locking on this. Two changes: > 1) Turn off irq while setting the clock. > 2) Call the timer code only through the timer interface > (set a

Re: yenta_socket "nobody cared - Disabling IRQ #4" - WORKING!!

On Saturday 19 March 2005 09:05, Jonas Oreland wrote: > Hi again and thx again, > > SUMMARY: It's working with new hook (wo/ trying second part) > I'll post again if error comes up again. that's good news! > > Daniel Ritz wrote: > > On Saturday 19 March 2005 00:00, Jonas Oreland

Nasty ReiserFS bug in 2.6.12-rc1, 2.6.12-rc1-bk1

Hi. I have built 2.6.12-rc1 and 2.6.12-rc1-bk1. There seems to be a nasty bug in ReiserFS (things are fine in 2.6.11.4). The system wants to un-configure my SCSI Adaptec devices, and stall at "starting Hal daemon". I also get the following error message (applied variously at different times to

Re: Relayfs question

>> Ok, urandom was a bad example. I have my tty logger (ttyrpld.sf.net) which >> moves a lot of data (depends) to userspace. It uses a ring buffer [...] >[...] >Basically, all the transport code you are doing in the kernel side of >your logger would be taken care of by relayfs. And given that

Re: pwc driver in -mm kernels

On Sat, Mar 19, 2005 at 02:04:24PM +0100, Norbert Preining wrote: > Hi Andrew, hi Luc! > > I just realized that there is now the pwc driver back in -mm kernels, > but interestingly not the one from Luc, or at least not the last > published one (10.0.6). and wanted to ask if there is a specific

Re: Relayfs question

Karim Yaghmour wrote: > What relayfs does, and does very well, is move very large amounts of > data out of the kernel and make them available to user-space with very > little overhead. In the actual case of your tty logger, I've browsed > through the code briefly, and I think that with relayfs

NULL pointer bug in netpoll.c

Hi, it seems that there is a gremlin sleeping in net/core/netpoll.c:find_skb(). Even if no more buffers are available through "skbs", "skb" is dereferenced anyway. The tiny patch should fix it. Jan --- linux-2.6.11.4/net/core/netpoll.c.orig 2005-03-16 01:09:19.0 +0100 +++

Re: Relayfs question

Jan Engelhardt wrote: > Ok, urandom was a bad example. I have my tty logger (ttyrpld.sf.net) which > moves a lot of data (depends) to userspace. It uses a ring buffer of "fixed" > size (set at module load time). Apart from that relayfs could use a dynamic > sized ring buffer, I would not see

[PATCH] _raw_read_trylock for alpha

alpha SMP doesn't build, due to lack of _raw_read_trylock(). Patch below completely untested... needs review and testing. One could also use the arch-neutral generic_raw_read_trylock(), but that implementation is rather lame (it spins). I'm amazed at the number of arches that use the generic

RE: [patch] arch hook for notifying changes in PTE protections bits

> On Sat, 19 Mar 2005 12:22:20 -0800, "Seth, Rohit" <[EMAIL PROTECTED]> > said: Rohit> David S. Miller wrote on Friday, Rohit> March 18, 2005 8:06 PM: >> Take a look at set_pte_at(). You get the "mm", the virtual >> address, the pte pointer, and the

RE: [patch] arch hook for notifying changes in PTE protections bits

David S. Miller wrote on Friday, March 18, 2005 8:06 PM: > > Take a look at set_pte_at(). You get the "mm", the > virtual address, the pte pointer, and the new pte value. > Thanks for pointing out the updated interface in 2.6.12-* kernel. I think I can overload the

Re: Suspend-to-disk woes

On Saturday 19 March 2005 05:26, Pavel Machek wrote: > Checking that would be hard, but you might want to provide patch to check > last-mounted dates of filesystems and panic if they changed. > Pavel Then how would you fix it? There'd also have to be a way to reset

Re: [2.6 patch] net/bluetooth/rfcomm/core.: make a variable static

Hi Adrian, > This patch makes a needlessly global variable static. the patch is in my tree now. Thanks. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at

2.6.12-rc1 report

Greetings; Usually I come looking for a bone when I post here, but today its with verbal flowers in hand. I just built 2.6.12-rc1 and I'm pleased to report that the ieee1394 problems that required the bk-ieee1394.patch previously are apparently alleviated. Kino worked as expected, including

race between __sync_single_inode() and iput()/bdev_clear_inode()

Hi, EIP is at filemap_fdatawait+0xe/0x80 eax: e7461ad8 ebx: ecx: 0001 edx: esi: e5334c40 edi: 6b6b6b6b ebp: de239e88 esp: de239e70 ds: 007b es: 007b ss: 0068 Process fsstress (pid: 31048, threadinfo=de239000 task=e60cd020) Stack: e7d34358 de239e88 c01834f7

Re: [patch 01/10] char/ds1620: use msleep() instead of schedule_timeout()

On Sat, Mar 19, 2005 at 02:17:15PM +0100, [EMAIL PROTECTED] wrote: > Not sure why any driver needs to sleep for *two* ticks, so let's fix it. > > Use msleep() instead of schedule_timeout() to guarantee the > task delays as expected. Signals are never checked for by the callers or > in the

Re: [PATCH 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation

On Fri, Mar 18, 2005 at 03:23:44PM -0600, Matt Domsch wrote: > For review and comment. > > On x86_64 systems with no IOMMU and with >4GB RAM (in fact, whenever > there are any pages mapped above 4GB), pci_alloc_consistent() falls > back to using ZONE_DMA for all allocations, even if the device's

Re: Suspend-to-disk woes

Hi! > Hello, I experienced a pretty nasty problem a couple of days back: > > I ran 2.6.11-ck1 and built 2.6.11-ck2. The last thing I did before > booting the new kernel was to suspend-to-disk the old kernel > (something I usually do as I'm working on this laptop). > I ran the new kernel a

Build issue current MIPS - RaQ2

I have not been able to build kernels since 2.6.9 on my RaQ2 for some time. I have tried the linux-mips.org port and the current 2.6.11.5 release. I keep getting the same error. Building modules, stage 2. MODPOST *** Warning: "pci_iounmap" [drivers/net/tulip/tulip.ko] undefined! *** Warning:

Re: Relayfs question

Hi, >[...] > The current method is to just manage buffers and enable applications to mmap > the buffers to read them with some signalling on when a buffer is to be read > and when the kernel can overwrite it. > > A character device is unlikely to need such interface since you do want 16 > bytes

[patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00

i have released the -V0.7.41-00 Real-Time Preemption patch (merged to 2.6.12-rc1), which can be downloaded from the usual place: http://redhat.com/~mingo/realtime-preempt/ the biggest change in this patch is the merge of Paul E. McKenney's preemptable RCU code. The new RCU code is active on

Re: 2.6.11-rc3: APM resume problems with USB

On Sat, Mar 19, 2005 at 01:44:24AM -0800, Jeremy Fitzhardinge wrote: > On my IBM ThinkPad X31, I can only do one successful APM resume. After > the resume, there's a stream of messages on the console: > > uhci_hcd :00:1d.0: host controller process error, something bad > happened! >

Re: Relayfs question

Jan Engelhardt wrote: according to the relayfs description on opersys.com, |As the Linux kernel matures, there is an ever increasing number of facilities |and tools that need to relay large amounts of data from kernel space to user |space. Up to this point, each of these has had its own mechanism

Re: Oops in 2.6.10 (EIP is at hid_init_reports+0x151/0x1d0 [usbhid])

* Andrew Morton <[EMAIL PROTECTED]>: > > Could you please test 2.6.11 or, even better, 2.6.12-rc1? I will do that, once Debian has such a kernel :| -- Ralf Hildebrandt (i.A. des IT-Zentrum) [EMAIL PROTECTED] Charite - Universitätsmedizin BerlinTel. +49 (0)30-450 570-155

[PATCH] remove redundant NULL check before before kfree() in kernel/sysctl.c

Tiny patch to remove a redundant check for NULL pointer before calling kfree(). Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> diff -up linux-2.6.11-mm4-orig/kernel/sysctl.c linux-2.6.11-mm4/kernel/sysctl.c --- linux-2.6.11-mm4-orig/kernel/sysctl.c 2005-03-16 15:45:40.0 +0100 +++

Building Areca arcmsr driver outside kernel source tree

To get the arcmsr driver working with CentOS/RHEL 4 and using the facility to build kernel modules outside of the kernel source tree, I found the attached patch was necessary to remove the dependencies on the internal drivers/scsi/scsi*.h header files and to instead use the public ones found under

Re: bcm203x broadcom dongle firmware upload fails...

Hi Soeren, > I don't see why, it used to work reliably at some point but now it does > not. It even won't work without hotplug and then manually typing: > > echo 1 > /sys/class/firmware/2-1/loading > cat /lib/firmware/BCM2033-FW.bin >/sys/class/firmware/2-1/data > echo 0 >

Re: [PATCH] sealevel 8 port RS-232/RS-422/RS-485 board

On Thu, Mar 10, 2005 at 11:38:58PM -0600, DHollenbeck wrote: > Vendor Sealevel suggested these changes for its new board. Tried them, > they work with the card. Please apply the patch below, which was made > from 2.6.10 but can be applied to 2.6.11.2 without errors. Whitespace fixed and

RE: Need break driver<-->pci-device automatic association

Stuart, Many thanks for this interesting approach. A huge advantage is that it can be implemented as a script. But: -it still requires the Linux newcomer who wants his modem to work, to recompile her/his kernel - something which frightens beginners. -it implies that when adding

Relayfs question

Hello, according to the relayfs description on opersys.com, |As the Linux kernel matures, there is an ever increasing number of facilities |and tools that need to relay large amounts of data from kernel space to user |space. Up to this point, each of these has had its own mechanism for relaying

[PATCH 4/5] timers: remove memory barriers

del_timer() and __run_timers() use smp_wmb() before clearing timer's pending flag. It was needed because __mod_timer() did not locked old_base if the timer is not pending, so __mod_timer()->internal_add_timer() can race with del_timer()->list_del(). With the previous patch these functions are

[PATCH 3/5] timers: serialize timers

I think it is supposed that timers are serialized wrt to itself, but I can't find any documentation about it. If CPU_0 does mod_timer(jiffies+1) while the timer is currently running on CPU 1, it is quite possible that local interrupt on CPU_0 will start that timer before it finished on CPU_1.

[PATCH 2/5] timers: rework del_timer_sync()

New rules: ->_base & 1: is timer pending ->_base & ~1: where the timer was last scheduled ->_base == NULL means that this timer is not running on any cpu. del_timer_sync() clears ->_base, it is merely an optimization, so that subsequent del_timer calls do not need

[PATCH 5/5] timers: cleanup, kill __get_base()

__get_base() was added to reduce the changes in previous patches. This patch removes it. Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]> --- 2.6.12-rc1/kernel/timer.c~5_CLEAN 2005-03-19 22:28:34.0 +0300 +++ 2.6.12-rc1/kernel/timer.c 2005-03-19 23:34:23.0 +0300 @@ -86,16

[PATCH 1/5] timers: prepare for del_timer_sync() changes

There are problems with del_timer_sync(). 1. Scalability. All cpus are scanned to determine if the timer is running on that cpu. 2. It is racy. The timer can be fired again after del_timer_sync have checked all cpus and before it will recheck timer_pending(). This patch adds 'pending flag' to

[PATCH 0/5] timers: description

Hello. These patches are updated version of 'del_timer_sync: proof of concept' 2 patches. 1/5: unchanded. 2/5: del_timer_sync() simplified. It is not neccessary to unlock and retry if __TIMER_PENDING has changed, it is only neccessary if timer's base ==

Bitrotting serial drivers

Hi, m32r_sio Maintainer: Hirokazu Takata Please clean up the m32r_sio driver, removing whatever bits of code aren't absolutely necessary. Specifically, I'd like to see the following addressed: - the usage of SERIAL_IO_HUB6 (this driver doesn't support hub6 cards) - SERIAL_IO_*

  1   2   3   4   >