Re: [PATCH][RFC] kprobes: Add user entry-handler in kretprobes
Abhishek Sagar wrote: On Nov 13, 2007 12:09 AM, Abhishek Sagar <[EMAIL PROTECTED]> wrote: Whoops...sry for the repeated email..emailer trouble. Expecting this one to makes it to the list. Summary again: This patch introduces a provision to specify a user-defined callback to run at function entry to complement the return handler in kretprobes. Currently, whenever a kretprobe is registered, a user can specify a callback (return-handler) to be run each time the target function returns. This is also not guaranteed and is limited by the number of concurrently pending return instances of the target function in the current process's context. This patch will now allow registration of another user defined handler which is guaranteed to run each time the current return instance is allocated and the return handler is set-up. Conversely, if the entry-handler returns an error, it'll cause the current return instance to be dropped and the return handler will also not run. The purpose is to provide flexibility to do certain kinds of function level profiling using kretprobes. By being able to register function entry and return handlers, kretprobes will now be able to reduce an extra probe registration (and associated race) for scenarios where an entry handler is required to capture the function call/entry event along with the corresponding function exit event. If I understand your intentions(to capture information on function call/entry and corresponding function exit) cleary, I have few concerns on this. 1) How do you map the entry_handler(which gets executed when a process enters the function) with each instance of return probe handler. I accept that entry_handler() will execute each time process enters the function, but to calculate time, one needs to know corresponding instance of return probe handler(there should be a map for each return handler). Let me explain briefly. Suppose in a SMP system, 4 processes enter the same function at almost sametime(by executing entry_hanlder()) and returns from 4 different locations by executing the return handler. Now how do I match entry_handler() with corresponding instance of return handler for calculating time. Sometime back, Even I was interested in calculating the function execution time, but I used approach a) . Now What I think is, there could be 2 solutions to these problem. a) Collect the entry time and exit time and put it in that kretprobe_instance structure and fetch it before freeing that instance. b) Or pass ri(kretprobe_instance address to entry_handler) and match it with return probe handler. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] time: fix typo that makes sync_cmos_clock erratic
David, On Mon, 12 Nov 2007, David P. Reed wrote: > From: David P. Reed > > Fix a typo in ntp.c that has caused updating of the persistent (RTC) clock > when synced to NTP to behave erratically. Good catch. > Signed-off-by: David P. Reed Whitespace damaged as well. Please fix and resend > --- > When debugging a freeze that arises on my AMD64 machines when I run the > ntpd service, I added a number of printk's to monitor the sync_cmos_clock > procedure. I discovered that it was not syncing to cmos RTC every 11 minutes > as documented, but instead would keep trying every second for hours at a time. > The reason turned out to be a typo in sync_cmos_clock, where it attempts to > ensure that update_persistent_clock is called very close to 500 msec. after a > 1 second boundary (required by the PC RTC's spec). That typo referred to > "xtime" in one spot, rather than "now", which is derived from "xtime" but not > equal to it. This makes the test erratic, creating a "coin-flip" that decides > when update_persistent_clock is called - when it is called, which is rarely, > it may be at any time during the one second period, rather than close to 500 > msec, so the value written is needlessly incorrect, too. Please put the explanation into the changelog. > The patch works in 2.6.24rc2, but it should also work in 2.6.23. Yup > @@ -205,7 +206,10 @@ static void sync_cmos_clock(unsigned lon > return; > > getnstimeofday(); > -if (abs(xtime.tv_nsec - (NSEC_PER_SEC / 2)) <= tick_nsec / 2) Can we just s/xtime/now/ ? There is no value in an extra variable. Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: fix locking and sync bugs in x86_64 RTC code in time_64.c
David, On Mon, 12 Nov 2007, David P. Reed wrote: > From: David P. Reed > > Fix two bugs in arch/x86/kernel/time_64.c that affect the x86_64 kernel. 1) a > repeatable hard freeze due to interrupts when the ntpd service calls > update_persistent_clock(), 2) potentially unstable PC RTC timer values when > timer is read. 1) Please send separate patches for separate problems. 2) Your patch is white space damaged and does not apply. Please run it through scripts/checkpatch.pl before submitting, maybe send it to yourself first and verify that it applies correctly. > Signed-off-by: David P. Reed <[EMAIL PROTECTED]> > --- > More explanation: > 1) A repeatable but randomly timed freeze has been happening in Fedora 6 and 7 > for the last year, whenever I run the ntpd service on my AMD64x2 HP Pavilion > dv9000z laptop. This freeze is due to the use of spin_lock(_lock) under > the assumption (per a bad comment) that set_rtc_mmss is called only with > interrupts disabled. The call from ntp.c to update_persistent_clock is made > with interrupts enabled. Good catch. > 2) the use of an incorrect technique for reading the standard PC RTC timer, > which is documented to "disconnect" time registers from the bus while updates > are in progress. The use of UIP flag while interrupts are disabled to protect > a 244 microsecond window is one of the Motorola spec sheet's documented ways > to read the RTC time registers reliably. I realize that not all "clones" of > the of the what ? Also put the detailed description into the patch comment, please. > The patch updates the misleading comments and minimizes the amount of time > that the kernel disables interrupts. > > I have thoroughly tested this patch on a number of x86_64 machines with > various numbers of cores and chipsets, using 2.6.24rc2 kernel source. Note > that while testing the ntp code I found another bug in kernel/time/ntp.c which > is independent of this fix - neither patch requires the other. > > If possible, I'd love to see the patch merged with 2.6.24, and even with > 2.6.23. Care to resend ? Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.24-rc2 1/3] generic gpio -- gpio_chip support
On Wednesday 14 November 2007 17:52, David Brownell wrote: > On Tuesday 13 November 2007, Andrew Morton wrote: > > > I'll highlight the > > > point that such bitops shouldn't be preemption points. > > > > Disagree. *everything* should be a preemption point. > > So it's wrong that uses the > same calls to prevent *those* bitops from being prempted? Upstream, all spinlocks prevent preemption. But these ones are raw locks rather than normal locks probably because that they are trivially an innermost and correct lock. It's not going to be very helpful to bloat it and slow it down when debugging is turned on (atomic operations are _very_ frequent). For -rt, who knows. They probably don't even run on parisc or sparc so don't really care at this point. > Thus, that code should switch over to normal spinlocks... For upstream, there is little reason to switch them over, and some reasons not to. > I believe that if I submitted patches to do that, there'd > be a not-so-small riot. And the arguments would all boil > down to much the same ones applying to *these* bitops... I don't think you have valid reasons. Also, core/arch code has some different considerations to driver code. > > For internal-implementation > > details we do need to disable preemtion sometimes > > (to prevent deadlocks and to protect per-cpu resources). > > You're certainly talking about "internal-implementation > details" in this case. It's not like the lock is used > outside of those routines. Or as if other implementations > would even *need* such a lock. (Just like the IRQ table, > if the entries can't be removed and are all set up very > early, locking would be pointless.) Internal implementation details, as in: spin lock code has to disable preemption otherwise they deadlock; get_cpu_var() has to disable preemption to give coherent access to the variable etc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Wednesday 14 November 2007 00:27, Adrian Bunk wrote: > You missed the following in my email: > "we slowly scare them away due to the many bug reports without any > reaction." > > The problem is that bug reports take time. If you go away from easy > things like compile errors then even things like describing what does > no longer work, ideally producing a scenario where you can reproduce it > and verifying whether it was present in previous kernels can easily take > many hours that are spent before the initial bug report. > > If the bug report then gets ignored we discourage the person who sent > the bug report to do any work related to the kernel again. Cannot agree more. I am in a similar position right now. My patch to aic7xxx driver was ubmitted four times with not much reaction from scsi guys. Finally they replied and asked to rediff it against their git tree. I did that and sent patches back. No reply since then. And mind you, the patch is not trying to do anything complex, it mostly moves code around, removes 'inline', adds 'const'. What should I think about it? -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 XFS nfsd hang
I wonder if this is a similar hang to what Christian was seeing here: http://lkml.org/lkml/2007/11/13/319 Benny On Nov. 14, 2007, 9:04 +0200, Chris Wedgwood <[EMAIL PROTECTED]> wrote: > With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always) > see a hang when accessing some NFS exported XFS filesystems. Local > access to these filesystems ahead of time works without problems. > > This does not occur with 2.6.23.1. The filesystem does not appear to > be corrupt. > > > The call chain for the wedged process is: > > [ 1462.911256] nfsd D 80547840 4760 2966 2 > [ 1462.911283] 81010414d4d0 0046 > 81010414d610 > [ 1462.911322] 810104cbc6e0 81010414d480 80746dc0 > 80746dc0 > [ 1462.911360] 80744020 80746dc0 81010129c140 > 8101000ad100 > [ 1462.911391] Call Trace: > [ 1462.911417] [] __down+0xe9/0x101 > [ 1462.911437] [] default_wake_function+0x0/0xe > [ 1462.911458] [] __down_failed+0x35/0x3a > [ 1462.911480] [] _xfs_buf_find+0x84/0x24d > [ 1462.911501] [] _xfs_buf_find+0x193/0x24d > [ 1462.911522] [] xfs_buf_lock+0x43/0x45 > [ 1462.911543] [] _xfs_buf_find+0x1ba/0x24d > [ 1462.911564] [] xfs_buf_get_flags+0x5a/0x14b > [ 1462.911586] [] xfs_buf_read_flags+0x12/0x86 > [ 1462.911607] [] xfs_trans_read_buf+0x4c/0x2cf > [ 1462.911629] [] xfs_da_do_buf+0x41b/0x65b > [ 1462.911652] [] xfs_da_read_buf+0x24/0x29 > [ 1462.911673] [] xfs_dir2_block_lookup_int+0x4d/0x1ab > [ 1462.911694] [] xfs_dir2_block_lookup_int+0x4d/0x1ab > [ 1462.911717] [] xfs_dir2_block_lookup+0x15/0x8e > [ 1462.911738] [] xfs_dir_lookup+0xd2/0x12c > [ 1462.911761] [] submit_bio+0x10d/0x114 > [ 1462.911781] [] xfs_dir_lookup_int+0x2c/0xc5 > [ 1462.911802] [] lockdep_init_map+0x90/0x495 > [ 1462.911823] [] xfs_lookup+0x44/0x6f > [ 1462.911843] [] xfs_vn_lookup+0x29/0x60 > [ 1462.915246] [] __lookup_hash+0xe5/0x109 > [ 1462.915267] [] lookup_one_len+0x41/0x4e > [ 1462.915289] [] compose_entry_fh+0xc1/0x117 > [ 1462.915311] [] encode_entry+0x17c/0x38b > [ 1462.915333] [] find_or_create_page+0x3f/0xc9 > [ 1462.915355] [] _xfs_buf_lookup_pages+0x2c1/0x2f6 > [ 1462.915377] [] _spin_unlock+0x1f/0x49 > [ 1462.915399] [] cache_alloc_refill+0x1ba/0x4b9 > [ 1462.915424] [] nfs3svc_encode_entry_plus+0x0/0x13 > [ 1462.915448] [] nfs3svc_encode_entry_plus+0x10/0x13 > [ 1462.915469] [] xfs_dir2_block_getdents+0x15b/0x1e2 > [ 1462.915491] [] nfs3svc_encode_entry_plus+0x0/0x13 > [ 1462.915514] [] nfs3svc_encode_entry_plus+0x0/0x13 > [ 1462.915534] [] xfs_readdir+0x91/0xb6 > [ 1462.915557] [] nfs3svc_encode_entry_plus+0x0/0x13 > [ 1462.915579] [] xfs_file_readdir+0x31/0x40 > [ 1462.915599] [] vfs_readdir+0x61/0x93 > [ 1462.915619] [] nfs3svc_encode_entry_plus+0x0/0x13 > [ 1462.915642] [] nfsd_readdir+0x6d/0xc5 > [ 1462.915663] [] nfsd3_proc_readdirplus+0x114/0x204 > [ 1462.915686] [] nfsd_dispatch+0xde/0x1b6 > [ 1462.915706] [] svc_process+0x3f8/0x717 > [ 1462.915729] [] nfsd+0x1a9/0x2c1 > [ 1462.915749] [] child_rip+0xa/0x12 > [ 1462.915769] [] __svc_create_thread+0xea/0x1eb > [ 1462.915792] [] nfsd+0x0/0x2c1 > [ 1462.915812] [] child_rip+0x0/0x12 > > Over time other processes pile up beind this. > > [ 1462.910728] nfsd D 5440 2965 2 > [ 1462.910769] 8101040cdd40 0046 0001 > 810103471900 > [ 1462.910812] 8101029a72c0 8101040cdcf0 80746dc0 > 80746dc0 > [ 1462.910852] 80744020 80746dc0 81010008e0c0 > 8101012a1040 > [ 1462.910882] Call Trace: > [ 1462.910909] [] nfsd_permission+0x95/0xeb > [ 1462.910931] [] vfs_readdir+0x46/0x93 > [ 1462.910950] [] mutex_lock_nested+0x165/0x27c > [ 1462.910971] [] _spin_unlock+0x1f/0x49 > [ 1462.910994] [] nfs3svc_encode_entry_plus+0x0/0x13 > [ 1462.911015] [] vfs_readdir+0x46/0x93 > [ 1462.911037] [] nfs3svc_encode_entry_plus+0x0/0x13 > [ 1462.911057] [] nfsd_readdir+0x6d/0xc5 > [ 1462.911079] [] nfsd3_proc_readdirplus+0x114/0x204 > [ 1462.911102] [] nfsd_dispatch+0xde/0x1b6 > [ 1462.911122] [] svc_process+0x3f8/0x717 > [ 1462.911143] [] nfsd+0x1a9/0x2c1 > [ 1462.911165] [] child_rip+0xa/0x12 > [ 1462.911184] [] __svc_create_thread+0xea/0x1eb > [ 1462.911206] [] nfsd+0x0/0x2c1 > [ 1462.911225] [] child_rip+0x0/0x12 > > > Any suggestions other than to bisect this? (Bisection might be > painful as it crosses the x86-merge.) > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read
Re: [perfmon] Re: [perfmon2] perfmon2 merge news
On Wed, 14 Nov 2007 18:24:36 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote: > Andrew Morton writes: > > > I was hoping that after the round of release-and-review which Stephane, > > Andi and I did about twelve months ago that we were on track to merge the > > perfmon codebase as-offered. But now it turns out that the sentiment is > > that the code simply has too many bells-and-whistles to be acceptable. > > Whose sentiment? Andi and hch, maybe others I've forgotten about. > I've had a bit of a look at it today together with David Gibson. Our > impression is that the latest version is a lot cleaner and simpler > than it used to be. I'm also reading Stephane's technical report > which describes the interface, and whilst I'm only part-way through > it, I haven't seen anything yet which strikes me as unnecessary or > overly complicated. Yes, that's quite possible. I don't know how up-to-date people's knowledge is. I know I haven't looked seriously at the code in around twelve months. Let's get it on the wires as outlined and take a look at it all. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
Y, the IRQ <--> GPIO mapping is another thing I'm concerned about. Other than
that, all the other part of the gpiolib is a great work, actually,
I've been waiting
for this for quite a long time and just don't have time for a hands-on until
recently.
So let's get more feedback on this.
On Nov 14, 2007 3:19 PM, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > > > struct gpio_desc {
> > > > struct gpio_chip *chip;
> > > > unsigned is_out:1;
> > > > + unsigned requested:1;
> > > > +#ifdef CONFIG_DEBUG_FS
> > > > + const char *requested_str;
> > > > +#endif
> > >
> > > Note that this means (on typical 32-bit embedded hardware)
> > > twelve bytes per GPIO, which if you assume 256 GPIOs means
> > > an extra 3 KB static memory compared to the patch I sent.
>
> Actually, 2K is a more accurate number -- ignore DEBUG_FS.
>
>
> > Note this reduces the memory in gpio_chip, so it consumes almost same
> > memory as the patch you sent.
>
> No; the amount of space shaved from a typical (32-bit banks)
> gpio_chip is *exactly* the cost of one gpio_desc: two words.
> In one case, two bitmaps. In the other, a pointer, two bits,
> and internal struct padding.
>
> So unless each bank has only a single GPIO, this approach
> does cost more memory. Both for the extra memory associated
> with each gpio_chip that's used, and for unused gpio_desc.
>
> That's not necessarily a bad thing, though it's always worth
> avoiding bloat.
>
Well, absolutely agree on this.
> - Dave
>
--
Cheers
- eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 22/54] kset: convert /sys/devices/system to use kset_create
On Tue, 13 Nov 2007 16:35:15 -0800 Greg KH <[EMAIL PROTECTED]> wrote: > On Tue, Nov 13, 2007 at 04:01:44PM -0800, Andrew Morton wrote: > > On Tue, 13 Nov 2007 15:14:10 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > On Mon, 5 Nov 2007 12:03:34 -0800 Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > > > > <4> [<00142548>] sys_reboot+0x1a4/0x1f4 > > > > > > > <4> [<00111038>] sysc_noemu+0x10/0x16 > > > > > > > <4> [<021048e0>] 0x21048e0 > > > > > > > <4> > > > > > > > <4> > > > > > > > > > > > > > > Huh? We want to shutdown an unknown device on a bus that wishes > > > > > > > to stay > > > > > > > anonymous? > > > > > > > > > > > > > > Any hints would be appreciated... > > > > > > > > > > > > I'll look into this, I wonder if we are walking off the end of an > > > > > > unterminated list... > > > > > > > > > > Could well be. If I'm using lcrash's walk function correctly (which > > > > > always manages to confuse me...), the list of devices_kset seems to be > > > > > broken. > > > > > > > > Alright, I can reproduce something like this at shutdown time myself > > > > here, I'll try to figure it out... > > > > > > > > > > > > The Vaio oopses during `reboot -f' and I bisected it down to this patch. > > > > > > http://userweb.kernel.org/~akpm/dsc00034.jpg > > > http://userweb.kernel.org/~akpm/config-sony.txt > > > http://userweb.kernel.org/~akpm/dmesg-sony.txt > > > > The G5 Mac oopses in the same place during `halt -pfn'. > > Crap, I can't duplicate this here anymore. I'll fire up the older boxes > tonight and try to track this down... Here's another machine hit the same thing http://userweb.kernel.org/~akpm/config-vmm.txt http://userweb.kernel.org/~akpm/dsc00035.jpg (interesting EIP). Thats'a crufty old pre-ACPI PIII running hacked-about FC1. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sigwait eats blocked default-ignore signals
> But I suspect we have other issues here. Let's suppose we have threads T1 > (main) and T2. T2 blocks SIGCHLD and does sigwait(SIGCHLD). > > Now, we send SIGCHLD to the thread group. The signal is lost again because > sig_ignored() returns true on T1's side. > > Is this OK? [...] Yes, it's OK if T1 has SIGCHLD unblocked. When there are multiple threads that either don't block the signal or are in sigwait for it, then it can go to any of them and there are no guarantees at all about which. So we simply say that the signal went to the thread not in sigwait that has that signal unblocked (T1). When it got there, it was ignored. The user semantics are equivalent even if that thread never actually woke and dequeued the signal to ignore it. > I think __group_send_sig_info() shouldn't use sig_ignored() at > all. Instead, we should split __group_complete_signal() into 2 > functions. The first one, say, choose_target() shoud be used instead. The > second one, handle_fatal_signal() can also be used by tkill() and > friends. I will probably like any reorganization of the code that makes it cleaner. But we don't need to change the behavior in this regard. The most common path is __group_send_sig_info (from sys_kill), so it would be a shame to remove the short-circuit optimization there. In fact, it is probably wrong semantics to do so (for what applications expect, and possibly for POSIX conformance). That is, an unblocked, ignored (or default-ignore) signal should not set TIF_SIGPENDING and interrupt a system call in progress or just about to start. Obviously this is not a huge problem, since that's what happens under any debugger. But still, an undesireable change of semantics as well as de-optimization, I'd say. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 05:39:45PM -0700, Denys Vlasenko wrote: > On Tuesday 13 November 2007 10:56, Adrian Bunk wrote: > > On Tue, Nov 13, 2007 at 12:13:56PM -0500, Theodore Tso wrote: > > > On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote: > > > > Btw, I used to test every -mm kernel. But since I've switched distros > > > > (gentoo->ubuntu) > > > > and I have less time, I feel it's harder to test -rc or -mm kernels (I > > > > know this isn't a lkml problem > > > > but more a distro problem, but I would love having an ubuntu blessed > > > > repo with current dev kernel > > > > for the latest stable ubuntu release). > > > > > > There are two parts to this. One is a Ubuntu development kernel which > > > we can give to large numbers of people to expand our testing pool. > > > But if we don't do a better job of responding to bug reports that > > > would be generated by expanded testing this won't necessarily help us. > > >... > > > > The main problem aren't missing testers [1] - we already have relatively > > experienced people testing kernels and/or reporting bugs, and we slowly > > scare them away due to the many bug reports without any reaction. > > > > The main problem is finding experienced developers who spend time on > > looking into bug reports. > > > > Getting many relatively unexperienced users (who need more guidance for > > debugging issues) as additional testers is therefore IMHO not > > necessarily a good idea. > > And where experienced developrs are coming from? > They are not born with Linux kernel skills. > They grow up from within user base. > > Bigger user base -> more developers (eventually) You missed the following in my email: "we slowly scare them away due to the many bug reports without any reaction." The problem is that bug reports take time. If you go away from easy things like compile errors then even things like describing what does no longer work, ideally producing a scenario where you can reproduce it and verifying whether it was present in previous kernels can easily take many hours that are spent before the initial bug report. If the bug report then gets ignored we discourage the person who sent the bug report to do any work related to the kernel again. > vda 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [perfmon] Re: [perfmon2] perfmon2 merge news
Andrew Morton writes: > I was hoping that after the round of release-and-review which Stephane, > Andi and I did about twelve months ago that we were on track to merge the > perfmon codebase as-offered. But now it turns out that the sentiment is > that the code simply has too many bells-and-whistles to be acceptable. Whose sentiment? I've had a bit of a look at it today together with David Gibson. Our impression is that the latest version is a lot cleaner and simpler than it used to be. I'm also reading Stephane's technical report which describes the interface, and whilst I'm only part-way through it, I haven't seen anything yet which strikes me as unnecessary or overly complicated. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
> > > struct gpio_desc {
> > > struct gpio_chip *chip;
> > > unsigned is_out:1;
> > > + unsigned requested:1;
> > > +#ifdef CONFIG_DEBUG_FS
> > > + const char *requested_str;
> > > +#endif
> >
> > Note that this means (on typical 32-bit embedded hardware)
> > twelve bytes per GPIO, which if you assume 256 GPIOs means
> > an extra 3 KB static memory compared to the patch I sent.
Actually, 2K is a more accurate number -- ignore DEBUG_FS.
> Note this reduces the memory in gpio_chip, so it consumes almost same
> memory as the patch you sent.
No; the amount of space shaved from a typical (32-bit banks)
gpio_chip is *exactly* the cost of one gpio_desc: two words.
In one case, two bitmaps. In the other, a pointer, two bits,
and internal struct padding.
So unless each bank has only a single GPIO, this approach
does cost more memory. Both for the extra memory associated
with each gpio_chip that's used, and for unused gpio_desc.
That's not necessarily a bad thing, though it's always worth
avoiding bloat.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc2 XFS nfsd hang
With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always) see a hang when accessing some NFS exported XFS filesystems. Local access to these filesystems ahead of time works without problems. This does not occur with 2.6.23.1. The filesystem does not appear to be corrupt. The call chain for the wedged process is: [ 1462.911256] nfsd D 80547840 4760 2966 2 [ 1462.911283] 81010414d4d0 0046 81010414d610 [ 1462.911322] 810104cbc6e0 81010414d480 80746dc0 80746dc0 [ 1462.911360] 80744020 80746dc0 81010129c140 8101000ad100 [ 1462.911391] Call Trace: [ 1462.911417] [] __down+0xe9/0x101 [ 1462.911437] [] default_wake_function+0x0/0xe [ 1462.911458] [] __down_failed+0x35/0x3a [ 1462.911480] [] _xfs_buf_find+0x84/0x24d [ 1462.911501] [] _xfs_buf_find+0x193/0x24d [ 1462.911522] [] xfs_buf_lock+0x43/0x45 [ 1462.911543] [] _xfs_buf_find+0x1ba/0x24d [ 1462.911564] [] xfs_buf_get_flags+0x5a/0x14b [ 1462.911586] [] xfs_buf_read_flags+0x12/0x86 [ 1462.911607] [] xfs_trans_read_buf+0x4c/0x2cf [ 1462.911629] [] xfs_da_do_buf+0x41b/0x65b [ 1462.911652] [] xfs_da_read_buf+0x24/0x29 [ 1462.911673] [] xfs_dir2_block_lookup_int+0x4d/0x1ab [ 1462.911694] [] xfs_dir2_block_lookup_int+0x4d/0x1ab [ 1462.911717] [] xfs_dir2_block_lookup+0x15/0x8e [ 1462.911738] [] xfs_dir_lookup+0xd2/0x12c [ 1462.911761] [] submit_bio+0x10d/0x114 [ 1462.911781] [] xfs_dir_lookup_int+0x2c/0xc5 [ 1462.911802] [] lockdep_init_map+0x90/0x495 [ 1462.911823] [] xfs_lookup+0x44/0x6f [ 1462.911843] [] xfs_vn_lookup+0x29/0x60 [ 1462.915246] [] __lookup_hash+0xe5/0x109 [ 1462.915267] [] lookup_one_len+0x41/0x4e [ 1462.915289] [] compose_entry_fh+0xc1/0x117 [ 1462.915311] [] encode_entry+0x17c/0x38b [ 1462.915333] [] find_or_create_page+0x3f/0xc9 [ 1462.915355] [] _xfs_buf_lookup_pages+0x2c1/0x2f6 [ 1462.915377] [] _spin_unlock+0x1f/0x49 [ 1462.915399] [] cache_alloc_refill+0x1ba/0x4b9 [ 1462.915424] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915448] [] nfs3svc_encode_entry_plus+0x10/0x13 [ 1462.915469] [] xfs_dir2_block_getdents+0x15b/0x1e2 [ 1462.915491] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915514] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915534] [] xfs_readdir+0x91/0xb6 [ 1462.915557] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915579] [] xfs_file_readdir+0x31/0x40 [ 1462.915599] [] vfs_readdir+0x61/0x93 [ 1462.915619] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915642] [] nfsd_readdir+0x6d/0xc5 [ 1462.915663] [] nfsd3_proc_readdirplus+0x114/0x204 [ 1462.915686] [] nfsd_dispatch+0xde/0x1b6 [ 1462.915706] [] svc_process+0x3f8/0x717 [ 1462.915729] [] nfsd+0x1a9/0x2c1 [ 1462.915749] [] child_rip+0xa/0x12 [ 1462.915769] [] __svc_create_thread+0xea/0x1eb [ 1462.915792] [] nfsd+0x0/0x2c1 [ 1462.915812] [] child_rip+0x0/0x12 Over time other processes pile up beind this. [ 1462.910728] nfsd D 5440 2965 2 [ 1462.910769] 8101040cdd40 0046 0001 810103471900 [ 1462.910812] 8101029a72c0 8101040cdcf0 80746dc0 80746dc0 [ 1462.910852] 80744020 80746dc0 81010008e0c0 8101012a1040 [ 1462.910882] Call Trace: [ 1462.910909] [] nfsd_permission+0x95/0xeb [ 1462.910931] [] vfs_readdir+0x46/0x93 [ 1462.910950] [] mutex_lock_nested+0x165/0x27c [ 1462.910971] [] _spin_unlock+0x1f/0x49 [ 1462.910994] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.911015] [] vfs_readdir+0x46/0x93 [ 1462.911037] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.911057] [] nfsd_readdir+0x6d/0xc5 [ 1462.911079] [] nfsd3_proc_readdirplus+0x114/0x204 [ 1462.911102] [] nfsd_dispatch+0xde/0x1b6 [ 1462.911122] [] svc_process+0x3f8/0x717 [ 1462.911143] [] nfsd+0x1a9/0x2c1 [ 1462.911165] [] child_rip+0xa/0x12 [ 1462.911184] [] __svc_create_thread+0xea/0x1eb [ 1462.911206] [] nfsd+0x0/0x2c1 [ 1462.911225] [] child_rip+0x0/0x12 Any suggestions other than to bisect this? (Bisection might be painful as it crosses the x86-merge.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
On Tuesday 13 November 2007, eric miao wrote:
> > > > We "can" do most anything. What would that improve though?
> >
> > ... What would that improve, though? Your followup posts
> > still don't answer that question for me. I see the code,
> > but don't have an answer to that question.
> >
>
> to be honest, I don't feel like the holes. Put restrictions on
> the numbering of GPIOs might not be a good idea either.
So the point of these is to make it easier for platforms
(or even just boards) to make sure the GPIO number space
is densely packed, rather than loosely so? Paying about
2KBytes for that privilege. (Assuming a 32 bit system
with 256 GPIOs.)
I could see that being a reasonable tradeoff. I wouldn't
have started there myself, but you know how that goes!
Does anyone else have any comments on that issue?
One point you haven't really brought up in this thread is
your concern about the impact of this on IRQs. One issue
being that for GPIOs used as IRQs, with linear mappings
resembling
static inline int gpio_to_irq(unsigned gpio)
{
if (gpio >= LAST_IRQ_CAPABLE_GPIO)
return -EINVAL;
return irq + FIRST_GPIO_IRQ_NUMBER;
}
then tightly packed GPIOs mean less space wasted for IRQ
descriptors that would never be used.
And since an irq_desc bigger than your gpio_desc, there's
a tradeoff between wasting space on unused gpio_desc structs
versus unused irq_desc structs. 2 KBytes would cost about
only 35 irq_desc structs, vs 256 gpio_desc structs.
I'm guessing that's why you care about dense packing for
the GPIO numbers...
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.24-rc2 1/3] generic gpio -- gpio_chip support
On Tuesday 13 November 2007, Andrew Morton wrote: > > > > Why do you want to use raw_spinlock_t? > > > > Already answered elsewhere in this thread ... > > Can't say I really understood the answer. I don't think we > actually know where all of this extra time is being spent? Reading that, one could think performance was the only factor. But it isn't, and wasn't the one which really persuaded me. And yes we do where that time went. Although it seems that repeating that info once again won't help... > > I'll highlight the > > point that such bitops shouldn't be preemption points. > > Disagree. *everything* should be a preemption point. So it's wrong that uses the same calls to prevent *those* bitops from being prempted? Thus, that code should switch over to normal spinlocks... I believe that if I submitted patches to do that, there'd be a not-so-small riot. And the arguments would all boil down to much the same ones applying to *these* bitops... > For internal-implementation > details we do need to disable preemtion sometimes > (to prevent deadlocks and to protect per-cpu resources). You're certainly talking about "internal-implementation details" in this case. It's not like the lock is used outside of those routines. Or as if other implementations would even *need* such a lock. (Just like the IRQ table, if the entries can't be removed and are all set up very early, locking would be pointless.) > But those > preemption-off periods should be minimised. Like the three instructions in the "hot paths" for getting and setting GPIO values, when using raw spinlocks ... check. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
On Nov 14, 2007 12:36 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 November 2007, eric miao wrote:
> > Subject: [PATCH 5/5] move per GPIO "requested" to "struct gpio_desc"
> >
>
> > struct gpio_desc {
> > struct gpio_chip *chip;
> > unsigned is_out:1;
> > + unsigned requested:1;
> > +#ifdef CONFIG_DEBUG_FS
> > + const char *requested_str;
> > +#endif
>
> A better name for this would be "label", matching what's
> passed from gpio_request(). Ndls abrviatns r bd.
>
Fine.
>
> Note that this means (on typical 32-bit embedded hardware)
> twelve bytes per GPIO, which if you assume 256 GPIOs means
> an extra 3 KB static memory compared to the patch I sent.
>
Note this reduces the memory in gpio_chip, so it consumes almost same
memory as the patch you sent.
>
> > @@ -43,20 +43,19 @@ static inline int gpio_is_onchip(unsigned gpio,
> > struct gpio_chip *chip)
> > /* Warn when drivers omit gpio_request() calls -- legal but
> > * ill-advised when setting direction, and otherwise illegal.
> > */
> > -static void gpio_ensure_requested(struct gpio_chip *chip, unsigned offset)
> > +static void gpio_ensure_requested(unsigned gpio)
>
> Simpler to pass a gpio_desc pointer ...
>
>
> > if (!requested)
> > - printk(KERN_DEBUG "GPIO-%d autorequested\n",
> > - chip->base + offset);
> > + pr_debug("GPIO-%d autorequested\n", gpio);
>
> Leave the printk in ... this is the sort of thing we want
> to see fixed, which becomes unlikely once you hide such
> diagnostics. And for that matter, what would be enabling
> the "-DDEBUG" that would trigger a pr_debug() message?
>
line length issue, just ignore this if you prefer.
>
>
> ... overall the main downside of these patches seems to
> be that it consumes more static memory.
>
Not really, since it reduces the holes. That all depend on your
ARCH_NR_GPIOS.
--
Cheers
- eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1
On Nov 14, 2007 2:38 PM, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Wed, 14 Nov 2007 14:18:39 +0800 "Dave Young" <[EMAIL PROTECTED]> wrote: > > > Hi, > > Boot failed on my machine. hand copy some messages. > > > > First with BLK_DEV_RAM=y > > > > BUG kmalloc-64 Poison overwritting: > > Alloced in kset_create > > Freed in kobject_cleanup > > > > --cut-- > > alloc_disk_node > > rd_init > > kernel_init > > --cut-- > > > > Then config ramdisk as module, build and reboot: > > > > BUG: unable handle paging resuest at 6b6b6b6b > > EIP is kobject_add 0xc4/0x150 > > > > --cut-- > > kobject_set_name > > register_disk > > add_disk > > exact_match > > exact_lock > > loop_init > > --cut-- > > > > erp. Can you send the config over please? > > And which distro/version is that machine running? > Hi,andrew slackware 11 config as follows: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc2-mm1 # Wed Nov 14 13:50:01 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y # CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_LSF=y CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_PREEMPT_NOTIFIERS=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y
Re: [patch/rfc 1/4] GPIO implementation framework
On Nov 14, 2007 12:18 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 November 2007, eric miao wrote:
> > Here comes the point of "struct gpio_desc"
> >
> > Subject: [PATCH 3/5] use a per GPIO "struct gpio_desc" and chain
> > "gpio_chip" to a list
>
> I see what it does, but don't see the "why" ... surely
> you can come up with a one sentence description of why
> this would be better?
>
> And I'd been so glad to *get rid of* that list, too.
I'll be happy too.
>
>
> > +struct gpio_desc {
> > + struct gpio_chip *chip;
> > +};
> > +
>
> > -/* gpio_lock protects modification to the table of chips and to
> > - * gpio_chip->requested. If a gpio is requested, its gpio_chip
> > - * is not removable.
> > - */
>
> But it still protects data. Don't remove documentation for
> what locks protect ... update it! Otherwise someonels going
> to come by and make a change which breaks the locking model.
> Usually in some subtle (hard-to-debug) way.
I'd prefer to name it "gpio_desc_lock" instead, which is self-explanatory
and thus requires no comment at all
>
> >
> > - for (id = 0; id < ARRAY_SIZE(chips); id++) {
> > - chip = chips[id];
> > - if (!chip)
> > - continue;
> > -
> > + list_for_each_entry(chip, _chip_list, node) {
> > seq_printf(s, "%sGPIOs %d-%d, %s%s:\n",
> > started ? "\n" : "",
> > chip->base, chip->base + chip->ngpio - 1,
>
> Note that this now produces the debug info in a relatively
> random order ... ordered by registration rather than anything
> useful, and hence awkward to read.
>
> It'd be better if you just scanned your new gpio_desc[]
> table in numeric order, and start a new section whenever
> you find a new gpio_chip.
>
> That'd get rid of that otherwise-useless list, too.
>
absolutely, you get the same feeling of mine and since this is for illustration
purpose only, I don't want more patches to fix this...
> - Dave
>
--
Cheers
- eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5][RFC] Physical PCI slot objects
On Tue, 13 Nov 2007, Greg KH wrote: > On Tue, Nov 13, 2007 at 04:04:00PM -0700, Matthew Wilcox wrote: > > On Tue, Nov 13, 2007 at 02:56:05PM -0800, Greg KH wrote: > > > Why not just use the code in the linux firmware kit that does this > > > already today from userspace (thanks to Kristen for pointing this out to > > > me on irc.)? > > > > So then we have something that works on ACPI-based machines. Who will > > add support for all the other kinds of firmware and non-firmware based > > slots? > > Well, it seems that the powerpc people do not want this at all, as they > just have "virtual" slots that they don't want people trying to root > around and find the real thing. > > What other types of machines can export this kind of information? How > will you discover non-firmware based slots? Just to add my 2 cents, I've not seen any CompactPCI gear that had a way to easily map a PCI peripheral slot to the corresponding physical slot in the chassis. In the products I've worked on that use my CPCI hotplug drivers, we did any required mapping in userspace based on knowledge of the chassis layout for the particular product. Scott -- == Scott Murray, [EMAIL PROTECTED] "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
On Nov 14, 2007 11:30 AM, David Brownell <[EMAIL PROTECTED]> wrote: > On Tuesday 13 November 2007, eric miao wrote: > > > > Can we use "per gpio based" structure instead of "per gpio_chip" based > > > > one, > > > > just like what the generic IRQ layer is doing nowadays? > > > > > > We "can" do most anything. What would that improve though? > > ... What would that improve, though? Your followup posts > still don't answer that question for me. I see the code, > but don't have an answer to that question. > to be honest, I don't feel like the holes. Put restrictions on the numbering of GPIOs might not be a good idea either. > > > -- Cheers - eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Attempt to get eject failures back to ioctl(CDROMEJECT)
Hi Jens,
As you asked for some time ago. Of course, it turns out that the eject
command ignores the error anyway, but it's nice that it now errors.
Not entirely comfortable with this patch: there's a req->errors but
that seems to have some existing semantics I'm not sure of, so I simply
added a new way of flagging an error.
Cheers,
Rusty.
---
Currently the CDROMEJECT ioctl always succeeds; it'd be nice if we
managed to get the errno passed back through the request.
This patch tries to do that.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r a7da575b248f block/ll_rw_blk.c
--- a/block/ll_rw_blk.c Wed Nov 14 15:44:39 2007 +1100
+++ b/block/ll_rw_blk.c Wed Nov 14 17:33:55 2007 +1100
@@ -261,6 +261,7 @@ static void rq_init(struct request_queue
rq->end_io_data = NULL;
rq->completion_data = NULL;
rq->next_rq = NULL;
+ rq->errno = 0;
}
/**
@@ -2657,7 +2658,9 @@ int blk_execute_rq(struct request_queue
blk_execute_rq_nowait(q, bd_disk, rq, at_head, blk_end_sync_rq);
wait_for_completion();
- if (rq->errors)
+ if (rq->errno)
+ err = rq->errno;
+ else if (rq->errors)
err = -EIO;
return err;
@@ -3427,8 +3430,10 @@ static int __end_that_request_first(stru
* extend uptodate bool to allow < 0 value to be direct io error
*/
error = 0;
- if (end_io_error(uptodate))
+ if (end_io_error(uptodate)) {
+ req->errno = uptodate;
error = !uptodate ? -EIO : uptodate;
+ }
/*
* for a REQ_BLOCK_PC request, we want to carry any eventual
diff -r a7da575b248f drivers/block/virtio_blk.c
--- a/drivers/block/virtio_blk.cWed Nov 14 15:44:39 2007 +1100
+++ b/drivers/block/virtio_blk.cWed Nov 14 17:33:55 2007 +1100
@@ -51,7 +51,7 @@ static bool blk_done(struct virtqueue *v
uptodate = 1;
break;
case VIRTIO_BLK_S_UNSUPP:
- uptodate = -ENOTTY;
+ uptodate = -ENOSYS;
break;
default:
uptodate = 0;
diff -r a7da575b248f include/linux/blkdev.h
--- a/include/linux/blkdev.hWed Nov 14 15:44:39 2007 +1100
+++ b/include/linux/blkdev.hWed Nov 14 17:33:55 2007 +1100
@@ -281,6 +281,8 @@ struct request {
int tag;
int errors;
+ /* If this isn't set, assume -EIO. */
+ int errno;
int ref_count;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1
On Wed, 14 Nov 2007 14:18:39 +0800 "Dave Young" <[EMAIL PROTECTED]> wrote: > Hi, > Boot failed on my machine. hand copy some messages. > > First with BLK_DEV_RAM=y > > BUG kmalloc-64 Poison overwritting: > Alloced in kset_create > Freed in kobject_cleanup > > --cut-- > alloc_disk_node > rd_init > kernel_init > --cut-- > > Then config ramdisk as module, build and reboot: > > BUG: unable handle paging resuest at 6b6b6b6b > EIP is kobject_add 0xc4/0x150 > > --cut-- > kobject_set_name > register_disk > add_disk > exact_match > exact_lock > loop_init > --cut-- > erp. Can you send the config over please? And which distro/version is that machine running? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench
From: Nick Piggin <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 05:14:27 +1100 > On Wednesday 14 November 2007 17:12, David Miller wrote: > > Is your test system using HIGHMEM? > > > > That's one thing the page vector in the sk_buff can do a lot, > > kmaps. > > No, it's an x86-64, so no highmem. Ok. > What's also interesting is that SLAB apparently doesn't have this > condition. The first thing that sprung to mind is that SLAB caches > order > 0 allocations, while SLUB does not. However if anything, > that should actually favour the SLUB numbers if network is avoiding > order > 0 allocations. > > I'm doing some oprofile runs now to see if I can get any more info. Here are some other things you can play around with: 1) Monitor the values of skb->len and skb->data_len for packets going over loopback. 2) Try removing NETIF_F_SG in drivers/net/loopback.c's dev->feastures setting. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
On Nov 14, 2007 11:25 AM, David Brownell <[EMAIL PROTECTED]> wrote: > On Tuesday 13 November 2007, eric miao wrote: > > > > Here comes a bunch of patches to illustrate my idea, some are not related to > > the point I mentioned, and they are not mature for now :-) > > > > Subject: [PATCH 1/5] add gpio_is_onchip() for commonly used gpio range > > checking > > I'll send substantive comments later, but meanwhile note > that the *CURRENT* version was posted last Friday: > > http://marc.info/?l=linux-kernel=119463810905330=2 > http://marc.info/?l=linux-kernel=119463811005344=2 > http://marc.info/?l=linux-kernel=119463811105352=2 > > Plus the appended tweak. It's more useful to send patches > against current code, so applying them doesn't provide a > small avalanche of rejects. :) > Ok, I'll update the patches later. > > With respect to this patch adding gpio_is_onchip(), I > don't see a point. The "gpio >= chip->base" check > is basically "are the data structures corrupted?" and > so it should only be done if "extra_checks" is defined. > (And IMO, not then ...) And combining the other two tests > that way doesn't make anything more clear to me. That's > somewhat of a style issue, I guess, unless you're like > me and don't much trust GCC to avoid extra instructions. > just a style issue, moving something commonly done into a routine, and extra_checks could be put there instead everywhere for a clean look :-) > - Dave > > -- Cheers - eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [2.6.24-rc2-mm1] Fix dependencies for FSL_DMA
[POWERPC] Fix dependencies for FSL_DMA >From a powerpc allyesconfig build: drivers/dma/fsldma.c:504: error: implicit declaration of function 'bus_to_virt' Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> Index: mm/drivers/dma/Kconfig === --- mm.orig/drivers/dma/Kconfig +++ mm/drivers/dma/Kconfig @@ -36,7 +36,7 @@ config INTEL_IOP_ADMA config FSL_DMA bool "Freescale MPC85xx/MPC83xx DMA support" - depends on PPC + depends on PPC && VIRT_TO_BUS select DMA_ENGINE ---help--- Enable support for the Freescale DMA engine. Now, it support - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Align PCI memory regions to page size (4K) - Fix
On Wed, Nov 14, 2007 at 08:17:33AM +1100, Benjamin Herrenschmidt wrote: ... > Though he's trying to fix a real issue, his patch is not the right > approach imho. > > A better approach would be to have a mechanism to be triggered by the > hypervisor administration tools that will attempt to reassign -that- > specific device if it happens to share pages with another. > > The remapping would thus only happen for that single device, after it's > been put in control of the hypervisor (no host driver is bound, maybe > just an HV specific "bridging" driver is), and only when the action of > assigning it to the partition is performed, so that if the machine > crashes as a result, at least you know why :-) > > So something like your hypervisor binds a special driver to a device > that is to be reflected to a partition, at which point we are sure no > other driver is using it, then that driver can call something in the pci > layer that attempts to re-assign the device resources to keep it in a > separate page. We already have that "something": pci_enable_device(). The guest OS "Arch" code can then do the reassignment. See "3.1 Enable the PCI device" in Documentation/pci.txt. > A patch implementing such a helper, and maybe reserving the rest of the > MMIO page via some dummy resource to make sure nobody else gets in, that > would make more sense. The Hypervisor could be responsible for making the right devices visible to the appropriate partitions/guests by intercepting the PCI bus walk and/or hotplug support. I don't think you should need any dummy resource/drivers in the guest OS. hth, grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1
Hi, Boot failed on my machine. hand copy some messages. First with BLK_DEV_RAM=y BUG kmalloc-64 Poison overwritting: Alloced in kset_create Freed in kobject_cleanup --cut-- alloc_disk_node rd_init kernel_init --cut-- Then config ramdisk as module, build and reboot: BUG: unable handle paging resuest at 6b6b6b6b EIP is kobject_add 0xc4/0x150 --cut-- kobject_set_name register_disk add_disk exact_match exact_lock loop_init --cut-- Regards dave --cut-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench
On Wednesday 14 November 2007 17:12, David Miller wrote: > From: Nick Piggin <[EMAIL PROTECTED]> > Date: Wed, 14 Nov 2007 04:36:24 +1100 > > > On Wednesday 14 November 2007 12:58, David Miller wrote: > > > I suspect the issue is about having a huge skb->data linear area for > > > TCP sends over loopback. We're likely getting a much smaller > > > skb->data linear data area after the patch in question, the rest using > > > the sk_buff scatterlist pages which are a little bit more expensive to > > > process. > > > > It didn't seem to be noticeable at 1 client. Unless scatterlist > > processing is going to cause cacheline bouncing, I don't see why this > > hurts more as you add CPUs? > > Is your test system using HIGHMEM? > > That's one thing the page vector in the sk_buff can do a lot, > kmaps. No, it's an x86-64, so no highmem. What's also interesting is that SLAB apparently doesn't have this condition. The first thing that sprung to mind is that SLAB caches order > 0 allocations, while SLUB does not. However if anything, that should actually favour the SLUB numbers if network is avoiding order > 0 allocations. I'm doing some oprofile runs now to see if I can get any more info. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
> > I'll work e1000e too :-) > > awesome, looking forward to that. > BTW, It seems to need Patrick's unicast patch for e1000e first. I'll looking forward to that too. Thanks Joonwoo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Question about free/used memory on Linux
Hi Vaidy, What do you think is the right way to get the memory usage of a process, I mean the actual physical memory used ? Basically, I'm interested in the incremental cost of a process, which means, I don't want to include the text segments of shared libraries which would remain even after the process is killed (since it would be used by other processes). Is the RSS field of "ps aux" command the right one or use "pmap" command and look at the "writeable" segments ? Thanks, Ravi -Original Message- From: Vaidyanathan Srinivasan [mailto:[EMAIL PROTECTED] Sent: Sunday, October 21, 2007 10:50 PM To: Ravinandan Arakali (rarakali) Cc: Linux Kernel Subject: Re: Question about free/used memory on Linux Ravinandan Arakali (rarakali) wrote: > Hi Vaidy, > Thanks for clarifying several of my doubts. > > To answer your question about my intention, we currently have a system > with 2 GB RAM and I need to find out the actual used and free memory > so that we can decide if the same setup(applications, tmpfs etc.) can > run on another system with lesser memory. > > Is it correct to say that the "used" field "free -m" excluding > buffers/caches would give the correct idea of used memory (I mean does > it take care of shared memory, shared copies of libraries etc.) ? I > assume it does not include /dev/shm usage since that's also a tmpfs > partition ? Thats correct. The used excluding the buffer caches gives most of the memory used by the system. You have excludes _all_ file backed memory including shm. > > If so, then I can add the memory used by tmpfs partitions to the above > and get the total memory used ? > > For eg. if my "free -m" appears as below: > Linux(debug)# free -m > total used free sharedbuffers > cached > Mem: 2014984 1030 0 80 > 594 > -/+ buffers/cache:309 1705 > > Can I say that 309MB + 350 MB(size of tmpfs partitions including > /dev/shm) > is the used memory on my system ? Two problems with this logic: 1. all of tmpfs may not be really used. You are over committing. 2. You still miss the pages needed to map the program code. They are file backed too. Though this will be very less amount of memory compared to data and shared memory. Let me suggest a metric: 1. Take the used part excluding the buffers (309MB) in your case and add 'Mapped' and 'Dirty' from /proc/meminfo This may be better than adding tmpfs/shmdev size. 2. Once your system is running will all applications loaded, cleanup the pagecache (file data cached in memory) sync echo 1 > /proc/sys/vm/drop_caches The first sync will bring down 'Dirty' count and drop_caches will reclaim all 'not needed' file cache memory. Now if you use 'free' and take the used count _with_ the buffers and file cache, this will provide a realistic value. (Actually Free in /proc/meminfo) Do not exclude buffers they are _needed_ for optimum system operation. With the above figure you can probably add 10% or more memory as extra memory for file cache when the system is operating with full load. If you want to be sure of these experiments boot you system with less memory using mem=xxx kernel parameter and run some performance tests to ensure the degradation is under acceptable limits. --Vaidy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
From: Sam Ravnborg <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 06:56:06 +0100 > > > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > > some bug reporters to give up and go away. > > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > try to change my mind. > > The postmasters at vger is pretty good at running mailing lists. > For linux-kbuild my effort so far has been to request it. > Thats not a big deal. > > So if they accept it you could have [EMAIL PROTECTED] for zero > overhead for you. I already did, get a little deeper in your mailbox before replying :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench
From: Nick Piggin <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 04:36:24 +1100 > On Wednesday 14 November 2007 12:58, David Miller wrote: > > I suspect the issue is about having a huge skb->data linear area for > > TCP sends over loopback. We're likely getting a much smaller > > skb->data linear data area after the patch in question, the rest using > > the sk_buff scatterlist pages which are a little bit more expensive to > > process. > > It didn't seem to be noticeable at 1 client. Unless scatterlist > processing is going to cause cacheline bouncing, I don't see why this > hurts more as you add CPUs? Is your test system using HIGHMEM? That's one thing the page vector in the sk_buff can do a lot, kmaps. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] drivers/i2c: Drop redundant includes of moduleparam.h
From: Julia Lawall <[EMAIL PROTECTED]> Drop #include in files that also include #include . module.h includes moduleparam.h already. i'm not convinced that's a good idea. while module.h does currently (and unfortunately) include moduleparam.h, there may come a day when those header files are refactored to actually make sense, at which point all those missing moduleparam.h inclusions will cause all sorts of bad things to happen. They were removed from the drivers/media files in August: 9c12224a607a4b22ab86784e3394b52810b9507c Perhaps they should be put back there then? julia - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 06:56:06AM +0100, Sam Ravnborg wrote: > > > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > > some bug reporters to give up and go away. > > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > try to change my mind. > > The postmasters at vger is pretty good at running mailing lists. > For linux-kbuild my effort so far has been to request it. > Thats not a big deal. > > So if they accept it you could have [EMAIL PROTECTED] for zero > overhead for you. And in a later mail I saw davem already created it. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at mm/prio_tree.c:125
On Wednesday 14 November 2007 10:04, Marc Donner wrote: > hi > > i got this kernel bug on our production system, which is running since last > saturday. > > anybody an idea?? Hugh might be of most help here, cc'ed. But for the preliminary questions -- Is the bug reproduceable? And if it is possible for you to test, is it reproduceable on the latest kernel.org kernel? (2.6.23 or 2.6.24 prerelease) Does the machine have ECC RAM or does it survive memtest? Thanks for reporting, Nick > > Marc > > uname -a > Linux files 2.6.18-5-686-bigmem #1 SMP Thu Aug 30 03:25:44 UTC 2007 i686 > GNU/Linux > > Nov 13 16:55:24 files kernel: [ cut here ] > Nov 13 16:55:24 files kernel: kernel BUG at mm/prio_tree.c:125! > Nov 13 16:55:24 files kernel: invalid opcode: [#1] > Nov 13 16:55:24 files kernel: SMP > Nov 13 16:55:24 files kernel: Modules linked in: button ac battery ipv6 > dm_snapshot dm_mirror dm_mod loop snd_via82xx gameport snd_ac97_codec > snd_ac97_bus sn > d_pcm snd_timer snd_page_alloc snd_mpu401_uart evdev snd_rawmidi > snd_seq_device snd serio_raw via82cxxx_audio uart401 sound soundcore > i2c_viapro ac97_codec p > smouse i2c_core rtc pcspkr via_agp agpgart shpchp pci_hotplug raid10 > raid456 xor multipath linear ide_generic via_rhine mii ehci_hcd uhci_hcd > usbcore ide_dis > k thermal fan freq_table processor raid1 raid0 md_mod ahci sata_nv sata_sil > sata_via libata via82cxxx ide_core 3w_9xxx 3w_ scsi_mod xfs ext3 jbd > ext2 mbc > ache reiserfs > Nov 13 16:55:24 files kernel: CPU:0 > Nov 13 16:55:24 files kernel: EIP:0060:[]Not tainted VLI > Nov 13 16:55:24 files kernel: EFLAGS: 00210217 (2.6.18-5-686-bigmem #1) > Nov 13 16:55:24 files kernel: EIP is at vma_prio_tree_remove+0x46/0xcd > Nov 13 16:55:24 files kernel: eax: ee09238c ebx: f2806b58 ecx: ee09238c > edx: f2806b70 > Nov 13 16:55:24 files kernel: esi: c85c0f40 edi: f3970524 ebp: b69f4000 > esp: d8e95f1c > Nov 13 16:55:24 files kernel: ds: 007b es: 007b ss: 0068 > Nov 13 16:55:24 files kernel: Process apache (pid: 31369, ti=d8e94000 > task=f7cffaa0 task.ti=d8e94000) > Nov 13 16:55:24 files kernel: Stack: f2806b70 f2806b58 c85c0f40 ee09238c > b69f4000 c014cce1 c17e5ee0 ee09238c > Nov 13 16:55:24 files kernel:f37a238c c014bec2 b69f4000 d8e95f6c > c17e5ee0 f3cd4740 ee092b1c f37a243c > Nov 13 16:55:24 files kernel:c014c9f7 b6d87000 ee09238c 00d7 > c17e5ee0 f3cd4740 ee0925f4 ee09238c > Nov 13 16:55:24 files kernel: Call Trace: > Nov 13 16:55:24 files kernel: [] unlink_file_vma+0x25/0x2e > Nov 13 16:55:24 files kernel: [] free_pgtables+0x26/0x78 > Nov 13 16:55:24 files kernel: [] unmap_region+0xbb/0xf3 > Nov 13 16:55:24 files kernel: [] do_munmap+0x148/0x19b > Nov 13 16:55:24 files kernel: [] sys_munmap+0x33/0x41 > Nov 13 16:55:24 files kernel: [] sysenter_past_esp+0x56/0x79 > Nov 13 16:55:24 files kernel: Code: 16 8b 50 28 8b 43 04 89 42 04 89 10 89 > 5b 04 89 59 28 e9 92 00 00 00 8b 04 24 89 da 59 5b 5e 5f 5d e9 a4 04 07 00 > 39 47 3 > 4 74 08 <0f> 0b 7d 00 5e a2 29 c0 83 79 30 00 74 38 8b 77 28 8d 57 28 8d > Nov 13 16:55:24 files kernel: EIP: [] > vma_prio_tree_remove+0x46/0xcd SS:ESP 0068:d8e95f1c > > Nov 13 16:55:37 files postfix/master[3582]: warning: process > /usr/lib/postfix/smtpd pid 1044 killed by signal 11 > Nov 13 16:55:37 files postfix/master[3582]: warning: > /usr/lib/postfix/smtpd: bad command startup -- throttling - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
> > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > some bug reporters to give up and go away. > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > non-subscribers only mailing list. Period. Not negotiable, so don't even > try to change my mind. The postmasters at vger is pretty good at running mailing lists. For linux-kbuild my effort so far has been to request it. Thats not a big deal. So if they accept it you could have [EMAIL PROTECTED] for zero overhead for you. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
From: Christoph Lameter <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 20:26:33 -0800 (PST) > The only problem that I see so far is a communication problem. Thus > we need more documentation. Fair enough, I'll look more closely at the next rev of your patch set. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1
Andrew Morton wrote:
[cut]
hm, that was supposed to shut itself off after 100 messages:
if (unlikely(clone_flags & (CLONE_DETACHED|CLONE_STOPPED))) {
static int __read_mostly count = 100;
if (count && printk_ratelimit()) {
char comm[TASK_COMM_LEN];
count--;
printk(KERN_INFO "fork(): process `%s' used deprecated "
"clone flags 0x%lx\n",
get_task_comm(comm, current),
clone_flags & (CLONE_DETACHED|CLONE_STOPPED));
}
}
I don't see how you got 151 instances. I guess I'm having another stupid
day.
It looks like a simple race, two threads do count-- before doing
if(count), resulting in an almost infinite loop. Probably.
atomic_test_and_dec might work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.24-rc2-mm1 - Build fails - in nsfd/vfs.c
Kamalesh Babulal wrote: > Hi Andrew, > > The Kernel build fails, with error > > CC fs/nfsd/vfs.o > fs/nfsd/vfs.c: In function ‘nfsd_rename’: > fs/nfsd/vfs.c:1695: error: request for member ‘mnt’ in something not a > structure or union > make[2]: *** [fs/nfsd/vfs.o] Error 1 > make[1]: *** [fs/nfsd] Error 2 > make: *** [fs] Error 2 > > Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]> > -- > --- linux-2.6.24-rc2/fs/nfsd/vfs.c2007-11-13 22:16:18.0 -0500 > +++ linux-2.6.24-rc2/fs/nfsd/~vfs.c 2007-11-13 23:10:18.0 -0500 > @@ -1692,7 +1692,7 @@ nfsd_rename(struct svc_rqst *rqstp, stru > if (!host_err) > host_err = nfsd_sync_dir(fdentry); > } > - mnt_drop_write(ffhp->fh_export->ex_path.mnt); > + mnt_drop_write(ffhp->fh_export->ex_mnt); > > out_dput_new: > dput(ndentry); > Sorry, for the report, its compiles fine, my box had the wrong mm patches. -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench
On Wednesday 14 November 2007 12:58, David Miller wrote: > From: Nick Piggin <[EMAIL PROTECTED]> > Date: Tue, 13 Nov 2007 22:41:58 +1100 > > > On Tuesday 13 November 2007 06:44, Christoph Lameter wrote: > > > On Sat, 10 Nov 2007, Nick Piggin wrote: > > > > BTW. your size-2048 kmalloc cache is order-1 in the default setup, > > > > wheras kmalloc(1024) or kmalloc(4096) will be order-0 allocations. > > > > And SLAB also uses order-0 for size-2048. It would be nice if SLUB > > > > did the same... > > > > > > You can try to see the effect that order 0 would have by booting with > > > > > > slub_max_order=0 > > > > Yeah, that didn't help much, but in general I think it would give > > more consistent and reliable behaviour from slub. > > Just a note that I'm not ignoring this issue, I just don't have time > to get to it yet. No problem. I would like to have helped more, but it's slow going given my lack of network stack knowledge. If I get any more interesting data, I'll send it. > I suspect the issue is about having a huge skb->data linear area for > TCP sends over loopback. We're likely getting a much smaller > skb->data linear data area after the patch in question, the rest using > the sk_buff scatterlist pages which are a little bit more expensive to > process. It didn't seem to be noticeable at 1 client. Unless scatterlist processing is going to cause cacheline bouncing, I don't see why this hurts more as you add CPUs? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH 000 of 2] md: Fixes for md in 2.6.23
On Nov 13, 2007 8:43 PM, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > Careful, it looks like you cherry picked commit 4ae3f847 "md: raid5:
> > fix clearing of biofill operations" which ended up misapplied in
> > Linus' tree, You should either also pick up def6ae26 "md: fix
> > misapplied patch in raid5.c" or I can resend the original "raid5: fix
> > clearing of biofill operations."
> >
> > The other patch for -stable "raid5: fix unending write sequence" is
> > currently in -mm.
>
> Hm, I've attached the two patches that I have right now in the -stable
> tree so far (still have over 100 patches to go, so I might not have
> gotten to them yet if you have sent them). These were sent to me by
> Andrew on their way to Linus. if I should drop either one, or add
> another one, please let me know.
>
Drop md-raid5-fix-clearing-of-biofill-operations.patch and replace it
with the attached
md-raid5-not-raid6-fix-clearing-of-biofill-operations.patch (the
original sent to Neil).
The critical difference is that the replacement patch touches
handle_stripe5, not handle_stripe6. Diffing the patches shows the
changes for hunk #3:
-@@ -2903,6 +2907,13 @@ static void handle_stripe6(struct stripe
+@@ -2630,6 +2634,13 @@ static void handle_stripe5(struct stripe_head *sh)
raid5-fix-unending-write-sequence.patch is in -mm and I believe is
waiting on an Acked-by from Neil?
> thanks,
>
> greg k-h
Thanks,
Dan
raid5: fix clearing of biofill operations
From: Dan Williams <[EMAIL PROTECTED]>
ops_complete_biofill() runs outside of spin_lock(>lock) and clears the
'pending' and 'ack' bits. Since the test_and_ack_op() macro only checks
against 'complete' it can get an inconsistent snapshot of pending work.
Move the clearing of these bits to handle_stripe5(), under the lock.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
Tested-by: Joel Bertrand <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
---
drivers/md/raid5.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index f96dea9..3808f52 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -377,7 +377,12 @@ static unsigned long get_stripe_work(struct stripe_head *sh)
ack++;
sh->ops.count -= ack;
- BUG_ON(sh->ops.count < 0);
+ if (unlikely(sh->ops.count < 0)) {
+ printk(KERN_ERR "pending: %#lx ops.pending: %#lx ops.ack: %#lx "
+ "ops.complete: %#lx\n", pending, sh->ops.pending,
+ sh->ops.ack, sh->ops.complete);
+ BUG();
+ }
return pending;
}
@@ -551,8 +556,7 @@ static void ops_complete_biofill(void *stripe_head_ref)
}
}
}
- clear_bit(STRIPE_OP_BIOFILL, >ops.ack);
- clear_bit(STRIPE_OP_BIOFILL, >ops.pending);
+ set_bit(STRIPE_OP_BIOFILL, >ops.complete);
return_io(return_bi);
@@ -2630,6 +2634,13 @@ static void handle_stripe5(struct stripe_head *sh)
s.expanded = test_bit(STRIPE_EXPAND_READY, >state);
/* Now to look around and see what can be done */
+ /* clean-up completed biofill operations */
+ if (test_bit(STRIPE_OP_BIOFILL, >ops.complete)) {
+ clear_bit(STRIPE_OP_BIOFILL, >ops.pending);
+ clear_bit(STRIPE_OP_BIOFILL, >ops.ack);
+ clear_bit(STRIPE_OP_BIOFILL, >ops.complete);
+ }
+
rcu_read_lock();
for (i=disks; i--; ) {
mdk_rdev_t *rdev;
raid5: fix unending write sequence
From: Dan Williams <[EMAIL PROTECTED]>
handling stripe 7629696, state=0x14 cnt=1, pd_idx=2 ops=0:0:0
check 5: state 0x6 toread read write f800ffcffcc0 written
check 4: state 0x6 toread read write f800fdd4e360 written
check 3: state 0x1 toread read write written
check 2: state 0x1 toread read write written
check 1: state 0x6 toread read write f800ff517e40 written
check 0: state 0x6 toread read write f800fd4cae60 written
locked=4 uptodate=2 to_read=0 to_write=4 failed=0 failed_num=0
for sector 7629696, rmw=0 rcw=0
These blocks were prepared to be written out, but were never handled in
ops_run_biodrain(), so they remain locked forever. The operations flags
are all clear which means handle_stripe() thinks nothing else needs to be
done.
This state suggests that the STRIPE_OP_PREXOR bit was sampled 'set' when it
should not have been. This patch cleans up cases where the code looks at
sh->ops.pending when it should be looking at the consistent stack-based
snapshot of the operations flags.
Report from Joel:
Resync done. Patch fix this bug.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
Tested-by: Joel Bertrand <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
---
drivers/md/raid5.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
Re: 2.6.24-rc2-mm1
Matthew Dharm wrote: > On Tue, Nov 13, 2007 at 07:49:24PM -0800, Greg KH wrote: >> Matt, are these the errors you were worried about with the patch we were >> just talking about tha tis in my tree? > > I can't tell from these logs. There is the dmesg with CONFIG_USB_STORAGE_DEBUG : http://194.231.229.228/dmesg-2.6.24-rc2-mm1 > > The key question (in relation to the allow_restart patch) is this: Was > everything working fine until a START_STOP was sent to the device? > > The SCSI layers used to send devices START_STOP to almost every device as > part of initialization. I think we switched all of that to use > TEST_UNIT_READY instead. > > The patch you've got should re-enable START_STOP to be sent. The SCSI > layers (I'm told, but haven't verified myself) only send START_STOP if the > device reports that it needs a startup command. > > CONFIG_USB_STORAGE_DEBUG will generate a *lot* of debug output. But, it > should be pretty easy to see if START_STOP was sent at all, and if it > caused the problems. > > Matt > > P.S. Worst case, the issue we're talking about here would only cause the > device firmware to crash, which would eventually lead to a disconnect. > That shouldn't have caused the much more severe problems shown in the log > you sent. > Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1
Andrew Morton wrote:
> On Wed, 14 Nov 2007 04:41:38 +0100 Gabriel C <[EMAIL PROTECTED]> wrote:
>
>> Uff clone-prepare-to-recycle-clone_detached-and-clone_stopped.patch *really*
>> spams.
>> Looks like some programs are using this 'deprecated flag'.
>>
>> Could this have some CONFIG_SPAM_ME_PLEASE ?;)
>>
>> This is what I got in some minutes :
>>
>>
>> --dmesg|grep 'used deprecated clone flags'|sed 's/.*] //'|sort -u
>> fork(): process `artsd' used deprecated clone flags 0x40
>> fork(): process `firefox-bin' used deprecated clone flags 0x40
>> fork(): process `gcompris' used deprecated clone flags 0x40
>> fork(): process `qgit' used deprecated clone flags 0x40
>> fork(): process `thunderbird-bin' used deprecated clone flags 0x40
>> fork(): process `wish' used deprecated clone flags 0x40
>> fork(): process `xchat' used deprecated clone flags 0x40
>> fork(): process `kdbus' used deprecated clone flags 0x40
>>
>> --dmesg|grep 'used deprecated clone flags'|wc -l
>> 151
>
> hm, that was supposed to shut itself off after 100 messages:
>
> if (unlikely(clone_flags & (CLONE_DETACHED|CLONE_STOPPED))) {
> static int __read_mostly count = 100;
>
> if (count && printk_ratelimit()) {
> char comm[TASK_COMM_LEN];
>
> count--;
> printk(KERN_INFO "fork(): process `%s' used deprecated "
> "clone flags 0x%lx\n",
> get_task_comm(comm, current),
> clone_flags & (CLONE_DETACHED|CLONE_STOPPED));
> }
> }
>
> I don't see how you got 151 instances. I guess I'm having another stupid
> day.
>
No idea how I got this I just grepped the dmesg =)
> Oh well. That's CLONE_DETACHED and I think Ulrich's question just got
> answered.
>
> Which distro/version are you running?
I'm using Frugalware Linux 'current' right now with the following software :
-- sh scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux lara 2.6.24-rc2-mm1 #4 SMP Wed Nov 14 05:47:48 CET 2007 i686 Intel(R)
Xeon(TM) CPU 2.00GHz GenuineIntel GNU/Linux
Gnu C 4.2.2
Gnu make 3.81
binutils 2.18.50.0.2.20071001
util-linux 2.13
mount 2.13
module-init-tools 3.2.2
e2fsprogs 1.40.2
xfsprogs 2.9.4
pcmciautils014
Linux C Library2.7
Dynamic linker (ldd) 2.7
Linux C++ Library so.6.0
Procps 3.2.7
Net-tools 1.60
Kbd1.12
Sh-utils 6.9
udev 116
Modules Loaded fuse pc87360 hwmon_vid eeprom adm1021 ext4dev jbd2
crc16 loop lp 3c59x intel_agp mii agpgart sr_mod parport_pc cdrom iTCO_wdt
parport thermal dcdbas i82860_edac iTCO_vendor_support evdev i2c_i801 button
pcspkr processor edac_core watchdog_core shpchp pci_hotplug watchdog_dev
>
> Thanks for letting us know
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.24-rc2-mm1 - Build Fail - fs/bfs/inode.c
On Wed, 14 Nov 2007 10:30:54 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> The kernel build fails, with following error
>
> fs/bfs/inode.c: In function ‘bfs_iget’:
> fs/bfs/inode.c:37: error: ‘ino’ redeclared as different kind of symbol
> fs/bfs/inode.c:35: error: previous definition of ‘ino’ was here
> fs/bfs/inode.c:37: error: ‘inode’ undeclared (first use in this function)
> fs/bfs/inode.c:37: error: (Each undeclared identifier is reported onlyonce
> fs/bfs/inode.c:37: error: for each function it appears in.)
> make[2]: *** [fs/bfs/inode.o] Error 1
> make[1]: *** [fs/bfs] Error 2
> make: *** [fs] Error 2
>
> Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]>
> --
> --- linux-2.6.24-rc2/fs/bfs/inode.c 2007-11-14 09:53:41.0 +0530
> +++ linux-2.6.24-rc2/fs/bfs/~inode.c 2007-11-14 10:21:06.0 +0530
> @@ -34,7 +34,6 @@ void dump_imap(const char *prefix, struc
>
> struct inode *bfs_iget(struct super_block *sb, unsigned long ino)
> {
> - unsigned long ino = inode->i_ino;
> struct bfs_inode *di;
> struct inode *inode;
> struct buffer_head *bh;
>
bah. That's what happens when I apply patches and fix rejects after doing
all my compile-coverage testing.
Thanks. I put your two fixes into the hot-fixes/ directory.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-11-13-04-14 Build Fails - linking when !CONFIG_NFS_V4
On Wed, 14 Nov 2007 01:21:36 +0530 Kamalesh Babulal wrote: > Hi Andrew, > > The kernel build fails, with the following error > > LD init/built-in.o > LD .tmp_vmlinux1 > fs/built-in.o(.text+0x5d632): In function `nfs_free_unlinkdata': > fs/nfs/unlink.c:32: undefined reference to `nfs_sb_deactive' > fs/built-in.o(.rodata+0x5c5c): In function `do_execve': > fs/exec.c:1355: undefined reference to `nfs_put_super' > make: *** [.tmp_vmlinux1] Error 1 > > I suspect nfs-stop-sillyname-renames-and-unmounts-from-racing.patch, > is causing the problem. The definition of the function is between > CONFIG_NFS_V4 in fs/nfs/super.c. > > During the compilation # CONFIG_NFS_V4 is not set. Reported and hopefully fixed. Patch is here: http://lkml.org/lkml/2007/11/13/211 --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH revised] enable make ARCH=x86 (and stay backward compatible)
> > I've just built v2.6.24-rc2-409-g9418d5d + your patchset for both amd64 and > i386 using Debian's kernel-package and both went without problems. Thanks for testing! > One (minor) issue. If I start out with a .config for i386, the first make > oldconfig will ask to set 64-BIT: > 64-bit kernel (64BIT) [N/y/?] (NEW) > It would be nice if that could be avoided somehow. I do not see this can be avoided. The typical response is just to accept the default which is N so we are safe in most cases anyway because default is 'N'. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-11-13-04-14 Build Fails - linking when !CONFIG_NFS_V4
Hi Andrew, The kernel build fails, with the following error LD init/built-in.o LD .tmp_vmlinux1 fs/built-in.o(.text+0x5d632): In function `nfs_free_unlinkdata': fs/nfs/unlink.c:32: undefined reference to `nfs_sb_deactive' fs/built-in.o(.rodata+0x5c5c): In function `do_execve': fs/exec.c:1355: undefined reference to `nfs_put_super' make: *** [.tmp_vmlinux1] Error 1 I suspect nfs-stop-sillyname-renames-and-unmounts-from-racing.patch, is causing the problem. The definition of the function is between CONFIG_NFS_V4 in fs/nfs/super.c. During the compilation # CONFIG_NFS_V4 is not set. -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc2-mm1-autokern1 # Tue Nov 13 06:26:42 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_I8K is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y CONFIG_NUMA=y CONFIG_K8_NUMA=y CONFIG_NODES_SHIFT=6 CONFIG_THREAD_ORDER=1 CONFIG_X86_64_ACPI_NUMA=y # CONFIG_NUMA_EMU is not set CONFIG_ARCH_DISCONTIGMEM_ENABLE=y CONFIG_ARCH_DISCONTIGMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set CONFIG_DISCONTIGMEM_MANUAL=y # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_DISCONTIGMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_NEED_MULTIPLE_NODES=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y # CONFIG_MEMORY_HOTPLUG is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_MIGRATION=y CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y CONFIG_OUT_OF_LINE_PFN_TO_PAGE=y CONFIG_NR_CPUS=8 CONFIG_PHYSICAL_ALIGN=0x20 CONFIG_HOTPLUG_CPU=y
Re: [PATCH] Fix warning for token-ring from sysctl checker
From: Olof Johansson <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 01:23:13 -0600 > As seen when booting ppc64_defconfig: > > sysctl table check failed: /net/token-ring .3.14 procname does not match > binary path procname > > > Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> Patch applied, thanks Olof. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
Joonwoo Park wrote:
> 2007/11/14, Kok, Auke <[EMAIL PROTECTED]>:
>> Patrick McHardy wrote:
>>> Kok, Auke wrote:
Patrick McHardy wrote:
> I already posted a patch for this, not sure what happened to it.
> Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend it and send me one for
e1000e as well?
>>> Patch for e1000 attached.
>>>
>>> Does e1000e also work with PCI cards if I add the proper IDs?
>>> Otherwise I could only send an untested patch.
>>
>> Johnwoo,
>>
>> your patch unfortunately does not apply after patrick's unicast patch,
>>
>> also, ich8lan support is removed from e1000 in the e1000 version in
>> jgarzik/netdev-2.6 #upstream as planned (moved over to e1000e!).
>>
>> Can you resend your patch so that it applies to jgarzik/netdev-2.6 #upstream
>> with
>> Patrick's patch applied? That would help a lot. And possibly do the e1000e
>> patch
>> as well :)
>>
>
> This is a patch for the jgarzik/netdev-2.6 #upstream with Patrick's one was
> applied.
> But the ich8lan stuff was not removed at this patch.
no, my TODO list is insane at the moment :)
thanks for the patch. I'll apply and rip the ich8 workarounds out myself later
when appropriate.
> I'll work e1000e too :-)
awesome, looking forward to that.
Auke
>
> Thanks.
> Joonwoo
>
> [E1000]: Disable vlan hw accel when promiscuous mode
>
> Even though netdevice is in the promiscuous mode, we should receive all of
> ingress packets.
> This disable the vlan filtering feature when a vlan hw accel configured e1000
> device goes into promiscuous mode.
> This make packets visible to sniffers though it's not vlan id of itself.
>
> Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
>
> ---
> drivers/net/e1000/e1000_main.c | 23 ++-
> 1 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
> index 5fd5f51..edf2ced 100644
> --- a/drivers/net/e1000/e1000_main.c
> +++ b/drivers/net/e1000/e1000_main.c
> @@ -2425,7 +2425,7 @@ e1000_set_rx_mode(struct net_device *netdev)
> struct e1000_hw *hw = >hw;
> struct dev_addr_list *uc_ptr;
> struct dev_addr_list *mc_ptr;
> - uint32_t rctl;
> + uint32_t rctl, ctrl;
> uint32_t hash_value;
> int i, rar_entries = E1000_RAR_ENTRIES;
> int mta_reg_count = (hw->mac_type == e1000_ich8lan) ?
> @@ -2442,13 +2442,23 @@ e1000_set_rx_mode(struct net_device *netdev)
> /* Check for Promiscuous and All Multicast modes */
>
> rctl = E1000_READ_REG(hw, RCTL);
> + ctrl = E1000_READ_REG(hw, CTRL);
>
> if (netdev->flags & IFF_PROMISC) {
> rctl |= (E1000_RCTL_UPE | E1000_RCTL_MPE);
> - } else if (netdev->flags & IFF_ALLMULTI) {
> - rctl |= E1000_RCTL_MPE;
> + if (adapter->hw.mac_type != e1000_ich8lan) {
> + if (ctrl & E1000_CTRL_VME)
> + rctl &= ~E1000_RCTL_VFE;
> + }
> } else {
> - rctl &= ~E1000_RCTL_MPE;
> + if (adapter->hw.mac_type != e1000_ich8lan) {
> + if (ctrl & E1000_CTRL_VME)
> + rctl |= E1000_RCTL_VFE;
> + } else if (netdev->flags & IFF_ALLMULTI) {
> + rctl |= E1000_RCTL_MPE;
> + } else {
> + rctl &= ~E1000_RCTL_MPE;
> + }
> }
>
> uc_ptr = NULL;
> @@ -4967,7 +4977,10 @@ e1000_vlan_rx_register(struct net_device *netdev,
> struct vlan_group *grp)
> if (adapter->hw.mac_type != e1000_ich8lan) {
> /* enable VLAN receive filtering */
> rctl = E1000_READ_REG(>hw, RCTL);
> - rctl |= E1000_RCTL_VFE;
> + if (netdev->flags & IFF_PROMISC)
> + rctl &= ~E1000_RCTL_VFE;
> + else
> + rctl |= E1000_RCTL_VFE;
> rctl &= ~E1000_RCTL_CFIEN;
> E1000_WRITE_REG(>hw, RCTL, rctl);
> e1000_update_mng_vlan(adapter);
> ---
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Morton wrote: > Oh well. That's CLONE_DETACHED and I think Ulrich's question just got > answered. > > Which distro/version are you running? People should really compile their glibc better than this. The sources still use it but only if you compile for compatibility with kernels before 2.6.2. Nobody should need to need such backward compatibility. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHOoMs2ijCOnn/RHQRAn+rAJ91vQoJRpuyPJipNLFn+3g6bajDtwCgs9fm moefStvq8QdvOxVLLDPUC1o= =GsVU -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-11-13-04-14.tar.gz uploaded
[EMAIL PROTECTED] wrote: > On Tue, 13 Nov 2007 19:42:10 +0300, Al Boldi said: > > Oh. What about breaking out a stable-mm snapshot against the latest > > stable kernel? > > You can roll your own of those. > > Get a 2.6.23.N kernel tarball. > patch -R the 23.N patch against that, giving you a 23.0 tree. > Apply patch-2.6.24-rc2 to that. > > Now apply the snapshot. Ok, but I was thinking of allowing a more selective approach. First, break out an mm snapshot that only contain patch-sets that are deemed stable, but still not ready for rc. Then, a tool may allow to selectively apply a specific patch-set against the latest stable kernel, not the rc. This could possibly improve longer-term testing, instead of just relying on crunch-time rc testing. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc: Fix fs_enet module build
From: Jochen Friedrich <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 19:32:08 +0100 > If fs_enet is build as module, on PPC_CPM_NEW_BINDING platforms > mii-fec/mii-bitbang should be build as module, as well. On other > platforms, mii-fec/mii-bitbang must be included into the main module. > Otherwise some symbols remain undefined. Additionally, fs_enet uses > libphy, so add a select PHYLIB. > > Building modules, stage 2. > MODPOST 5 modules > ERROR: "fs_scc_ops" [drivers/net/fs_enet/fs_enet.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > > Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]> This is truly ugly and creates an unnecessarily hard to maintain and complex driver. Please find a way to fix this for real, so that the PPC_CPM_NEW_BINDING ifdef is not necessary at all and things get built modular or not naturally as we handle things for other cases like this. THanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
From: "Martin Bligh" <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 09:46:08 -0800 > This is a technical issue with vger.kernel.org mailing lists that I've tried > addressing before - maybe davem can help fix it? I think the problem is that certain mail headers show up multiple times and this makes it look like a looping email so we toss it. I suspect the one you really need to block out is X-MailingList or similar. Why don't you do a few tries and I'll try to remember to keep an eye out for the bounces? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.6.24-rc2-mm1 - Build Fail - fs/bfs/inode.c
Hi Andrew,
The kernel build fails, with following error
fs/bfs/inode.c: In function ‘bfs_iget’:
fs/bfs/inode.c:37: error: ‘ino’ redeclared as different kind of symbol
fs/bfs/inode.c:35: error: previous definition of ‘ino’ was here
fs/bfs/inode.c:37: error: ‘inode’ undeclared (first use in this function)
fs/bfs/inode.c:37: error: (Each undeclared identifier is reported onlyonce
fs/bfs/inode.c:37: error: for each function it appears in.)
make[2]: *** [fs/bfs/inode.o] Error 1
make[1]: *** [fs/bfs] Error 2
make: *** [fs] Error 2
Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]>
--
--- linux-2.6.24-rc2/fs/bfs/inode.c 2007-11-14 09:53:41.0 +0530
+++ linux-2.6.24-rc2/fs/bfs/~inode.c2007-11-14 10:21:06.0 +0530
@@ -34,7 +34,6 @@ void dump_imap(const char *prefix, struc
struct inode *bfs_iget(struct super_block *sb, unsigned long ino)
{
- unsigned long ino = inode->i_ino;
struct bfs_inode *di;
struct inode *inode;
struct buffer_head *bh;
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
rant on :) ... These aren't directed specifically at Andrew, but everyone who merges patches or is involved in the release process. On Wednesday 14 November 2007 08:04, Andrew Morton wrote: > On Tue, 13 Nov 2007 21:00:30 +0100 (CET) Christian Kujau <[EMAIL PROTECTED]> wrote: > > On Tue, 13 Nov 2007, Andrew Morton wrote: > > > I think that we're fairly good about working the regressions in > > > Adrian/Michal/Rafael's lists but once Linus releases 2.6.x we tend to > > > let the unsolved ones slide, and we don't pay as much attention to the > > > regressions which 2.6.x testers report. > > > > Can't we wait until all regressions[0] are fixed before releasing a new > > 2.6.x? I'd consider regressions a *literal* show stopper, and with this > > policy they just have be fixed, nothing would "slide"... > > Problem is that everyone would then sit around pumping shiny new features > into their trees waiting until someone else fixes the regressions. Not if you said their regression causing patches will get reverted unless it can be fixed for release. For everyone not involved, they'll be doing their own productive things and we don't want to stop that. > There are a number of process things we _could_ do. Like > > - have bugfix-only kernel releases I don't know why this would be better than the above. If you are worried about perception of released kernels, then it would actually be worse, because the non-bugfix-only releases will get out there, and the numbering scheme gets yet another level of complexity. Make 2.6.24-rc3 your bugfix only release. If you argue that would make the cycle too long, the solution is to merge less stuff in 2.6.24-rc1. > - Just refuse to merge any non-bugfix patches for a subsystem when it is > determined that the subsystem has "too many" regressions. If you don't allow regressions to build up over releases in the first place, then this naturally gets done for you. > - Create an "if you added a regression, you should fix some other bug > too" rule. That's pretty annoying. Everybody tries not to introduce regressions. It's just a natural part of development. You just have to make the system work well within that constraint. It's easy: "if you add a regression, you fix it. If it doesn't get fixed, we either don't release or we revert your patch." That takes care of regressions. Now for actually improving quality. I think to do that you have to encourage code review and bug fixing. - Take reviewers seriously, and don't allow patches to be merged if they have outstanding unaddressed comments (unaddressed doesn't have to mean changed completely to reviewers taste, but at least answered questions and provided rationale). Don't merge unreviewed patches. - Prioritise bugfixes and regression fixes. I realise they can be very complex changes, but I am disappointed sometimes at how some of my bugfix attempts are received. Things like silent and un-reproduceable pagecache corruption, memory ordering bugs which will likewise cause silent and un-reproduceable data corruption are totally unacceptable IMO; worse than most simple (eg. fail-stop, performance) regressions. To see them struggle because the patch isn't perfect right off the bat, they're deemed too hard, or they clash with some pending "feature" is a pity to me. I don't expect thanks or even help, but at least having some priority would help me stay interested and the bug to get fixed quicker. For a concrete example: when I did the remap_vmalloc_range() patch, I converted over all in-tree drivers to use the range checking and much safer remap_vmalloc_range. During this conversion I found several places where drivers were potentially inserting mappings wrongly or not checking user inputs properly (eg. corruption and/or security issues). And tried to fix them. And yet the whole patchset was dropped, despite being simpler and cleaner code, and attempting to fix bugs. Because I wasn't able to test the hardware (and/or maintainers didn't respond). It didn't even get a chance in -mm (and if it had, it probably would have been immediately dropped if I had a typo somewhere). Those patches are still rotting on my hdd somewhere... So it is actually far easier for me to shut my eyes and not bother reviewing any in-tree code when introducing a new API or something like that. And yet something like CFS basically bypasses the review and test process entirely and gets upstream at least a release too soon. That isn't anything against the technical side of CFS development, which I'm a lot happier with than the old scheduler. It is a problem with the merging and release process. - "if you added a regression, you should fix some other bug too" rule should be "if you want to add a new feature, you should review a number of other patches". Review points can be traded. If this could be done right, it would create a direct economic incentive to review. OK, the last
Re: 2.6.24-rc2-mm1
On Wed, 14 Nov 2007 04:41:38 +0100 Gabriel C <[EMAIL PROTECTED]> wrote:
> Uff clone-prepare-to-recycle-clone_detached-and-clone_stopped.patch *really*
> spams.
> Looks like some programs are using this 'deprecated flag'.
>
> Could this have some CONFIG_SPAM_ME_PLEASE ?;)
>
> This is what I got in some minutes :
>
>
> --dmesg|grep 'used deprecated clone flags'|sed 's/.*] //'|sort -u
> fork(): process `artsd' used deprecated clone flags 0x40
> fork(): process `firefox-bin' used deprecated clone flags 0x40
> fork(): process `gcompris' used deprecated clone flags 0x40
> fork(): process `qgit' used deprecated clone flags 0x40
> fork(): process `thunderbird-bin' used deprecated clone flags 0x40
> fork(): process `wish' used deprecated clone flags 0x40
> fork(): process `xchat' used deprecated clone flags 0x40
> fork(): process `kdbus' used deprecated clone flags 0x40
>
> --dmesg|grep 'used deprecated clone flags'|wc -l
> 151
hm, that was supposed to shut itself off after 100 messages:
if (unlikely(clone_flags & (CLONE_DETACHED|CLONE_STOPPED))) {
static int __read_mostly count = 100;
if (count && printk_ratelimit()) {
char comm[TASK_COMM_LEN];
count--;
printk(KERN_INFO "fork(): process `%s' used deprecated "
"clone flags 0x%lx\n",
get_task_comm(comm, current),
clone_flags & (CLONE_DETACHED|CLONE_STOPPED));
}
}
I don't see how you got 151 instances. I guess I'm having another stupid
day.
Oh well. That's CLONE_DETACHED and I think Ulrich's question just got
answered.
Which distro/version are you running?
Thanks for letting us know
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[LOCK] Is it really necessary to use a "big module lock"?
Hi all,
I came across a question when review other's module code.
something like:
int __init module_init()
{
down_interruptible(the_big_module_sem);
// code for init...
up(the_big_module_sem);
}
void __exit module_exit()
{
down_interruptible(the_big_module_sem);
// code for exit...
up(the_big_module_sem);
}
My question is:
- Is the lock truly necessary?
- If adding it into code, what happens?
Thank you
-- Jerry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.6.24-rc2-mm1 - Build fails - in nsfd/vfs.c
Hi Andrew, The Kernel build fails, with error CC fs/nfsd/vfs.o fs/nfsd/vfs.c: In function ‘nfsd_rename’: fs/nfsd/vfs.c:1695: error: request for member ‘mnt’ in something not a structure or union make[2]: *** [fs/nfsd/vfs.o] Error 1 make[1]: *** [fs/nfsd] Error 2 make: *** [fs] Error 2 Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]> -- --- linux-2.6.24-rc2/fs/nfsd/vfs.c 2007-11-13 22:16:18.0 -0500 +++ linux-2.6.24-rc2/fs/nfsd/~vfs.c 2007-11-13 23:10:18.0 -0500 @@ -1692,7 +1692,7 @@ nfsd_rename(struct svc_rqst *rqstp, stru if (!host_err) host_err = nfsd_sync_dir(fdentry); } - mnt_drop_write(ffhp->fh_export->ex_path.mnt); + mnt_drop_write(ffhp->fh_export->ex_mnt); out_dput_new: dput(ndentry); -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
2007/11/14, Kok, Auke <[EMAIL PROTECTED]>:
> Patrick McHardy wrote:
> > Kok, Auke wrote:
> >> Patrick McHardy wrote:
> >>
> >>> I already posted a patch for this, not sure what happened to it.
> >>> Auke, any news on merging the secondary unicast address support?
> >>
> >> I dropped the ball on that one. Care to resend it and send me one for
> >> e1000e as well?
> >
> > Patch for e1000 attached.
> >
> > Does e1000e also work with PCI cards if I add the proper IDs?
> > Otherwise I could only send an untested patch.
>
>
> Johnwoo,
>
> your patch unfortunately does not apply after patrick's unicast patch,
>
> also, ich8lan support is removed from e1000 in the e1000 version in
> jgarzik/netdev-2.6 #upstream as planned (moved over to e1000e!).
>
> Can you resend your patch so that it applies to jgarzik/netdev-2.6 #upstream
> with
> Patrick's patch applied? That would help a lot. And possibly do the e1000e
> patch
> as well :)
>
This is a patch for the jgarzik/netdev-2.6 #upstream with Patrick's one was
applied.
But the ich8lan stuff was not removed at this patch.
I'll work e1000e too :-)
Thanks.
Joonwoo
[E1000]: Disable vlan hw accel when promiscuous mode
Even though netdevice is in the promiscuous mode, we should receive all of
ingress packets.
This disable the vlan filtering feature when a vlan hw accel configured e1000
device goes into promiscuous mode.
This make packets visible to sniffers though it's not vlan id of itself.
Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 23 ++-
1 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 5fd5f51..edf2ced 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -2425,7 +2425,7 @@ e1000_set_rx_mode(struct net_device *netdev)
struct e1000_hw *hw = >hw;
struct dev_addr_list *uc_ptr;
struct dev_addr_list *mc_ptr;
- uint32_t rctl;
+ uint32_t rctl, ctrl;
uint32_t hash_value;
int i, rar_entries = E1000_RAR_ENTRIES;
int mta_reg_count = (hw->mac_type == e1000_ich8lan) ?
@@ -2442,13 +2442,23 @@ e1000_set_rx_mode(struct net_device *netdev)
/* Check for Promiscuous and All Multicast modes */
rctl = E1000_READ_REG(hw, RCTL);
+ ctrl = E1000_READ_REG(hw, CTRL);
if (netdev->flags & IFF_PROMISC) {
rctl |= (E1000_RCTL_UPE | E1000_RCTL_MPE);
- } else if (netdev->flags & IFF_ALLMULTI) {
- rctl |= E1000_RCTL_MPE;
+ if (adapter->hw.mac_type != e1000_ich8lan) {
+ if (ctrl & E1000_CTRL_VME)
+ rctl &= ~E1000_RCTL_VFE;
+ }
} else {
- rctl &= ~E1000_RCTL_MPE;
+ if (adapter->hw.mac_type != e1000_ich8lan) {
+ if (ctrl & E1000_CTRL_VME)
+ rctl |= E1000_RCTL_VFE;
+ } else if (netdev->flags & IFF_ALLMULTI) {
+ rctl |= E1000_RCTL_MPE;
+ } else {
+ rctl &= ~E1000_RCTL_MPE;
+ }
}
uc_ptr = NULL;
@@ -4967,7 +4977,10 @@ e1000_vlan_rx_register(struct net_device *netdev, struct
vlan_group *grp)
if (adapter->hw.mac_type != e1000_ich8lan) {
/* enable VLAN receive filtering */
rctl = E1000_READ_REG(>hw, RCTL);
- rctl |= E1000_RCTL_VFE;
+ if (netdev->flags & IFF_PROMISC)
+ rctl &= ~E1000_RCTL_VFE;
+ else
+ rctl |= E1000_RCTL_VFE;
rctl &= ~E1000_RCTL_CFIEN;
E1000_WRITE_REG(>hw, RCTL, rctl);
e1000_update_mng_vlan(adapter);
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] - [7/15] - remove defconfig ptr comparisons to 0 - fs/lockd
On Wed, 2007-11-14 at 13:40 +1100, Neil Brown wrote:
> On Tuesday November 13, [EMAIL PROTECTED] wrote:
> > Remove defconfig ptr comparison to 0
> >
> > Remove sparse warning: Using plain integer as NULL pointer
> >
> > Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
> >
> > ---
> >
> > diff --git a/fs/lockd/svcshare.c b/fs/lockd/svcshare.c
> > index 068886d..98548ad 100644
> > --- a/fs/lockd/svcshare.c
> > +++ b/fs/lockd/svcshare.c
> > @@ -71,7 +71,7 @@ nlmsvc_unshare_file(struct nlm_host *host, struct
> > nlm_file *file,
> > struct nlm_share*share, **shpp;
> > struct xdr_netobj *oh = >lock.oh;
> >
> > - for (shpp = >f_shares; (share = *shpp) != 0; shpp =
> > >s_next) {
> > + for (shpp = >f_shares; (share = *shpp); shpp = >s_next) {
> > if (share->s_host == host && nlm_cmp_owner(share, oh)) {
> > *shpp = share->s_next;
> > kfree(share);
> >
>
> I particularly disagree with this change as it now looked like it
> could be an '==' comparison that was mistyped. Making it
> ; (share = *shpp) != NULL;
There would also be the minor fact that the original test is being
inverted in this 'fix'. An accurate fix should at the very least be
!(share = *shpp).
> makes the intent clear.
It would be a lot cleaner just to pull the entire assignment out of the
for() statement. IOW:
for (shpp = >f_shares; *shpp != NULL; shpp = &(*shpp)->s_next) {
struct nlm_share *share = *shpp;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ata_sg_setup_one vs ata_sg_setup?
Hi Jeff,
Was looking through libata, and it seems to me that ata_sg_setup is a
superset of ata_sg_setup_one. Am I missing something? Seems like it could
be simplified.
My machine never seems to do an ata_sg_setup_one, so this patch isn't really
tested...
Thanks,
Rusty.
---
Subject: libata: fold ata_queued_cmd single and sg logic
libata separates the single buffer case from the scatterlist case
internally. It's not clear that this is necessary.
Remove the ATA_QCFLAG_SINGLE flag, and buf_virt pointer, and always
initialize qc->nbytes in ata_sg_init().
It's possible that the ATA_QCFLAG_SG and ATA_QCFLAG_DMAMAP flags could
be entirely removed, and we could use whether qc->__sg is NULL or not.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 8b1075c7ad47 drivers/ata/libata-core.c
--- a/drivers/ata/libata-core.c Tue Nov 13 21:00:47 2007 +1100
+++ b/drivers/ata/libata-core.c Wed Nov 14 15:31:07 2007 +1100
@@ -1648,16 +1648,8 @@ unsigned ata_exec_internal_sg(struct ata
memcpy(qc->cdb, cdb, ATAPI_CDB_LEN);
qc->flags |= ATA_QCFLAG_RESULT_TF;
qc->dma_dir = dma_dir;
- if (dma_dir != DMA_NONE) {
- unsigned int i, buflen = 0;
- struct scatterlist *sg;
-
- for_each_sg(sgl, sg, n_elem, i)
- buflen += sg->length;
-
+ if (dma_dir != DMA_NONE)
ata_sg_init(qc, sgl, n_elem);
- qc->nbytes = buflen;
- }
qc->private_data =
qc->complete_fn = ata_qc_complete_internal;
@@ -4543,9 +4535,6 @@ void ata_sg_clean(struct ata_queued_cmd
WARN_ON(!(qc->flags & ATA_QCFLAG_DMAMAP));
WARN_ON(sg == NULL);
- if (qc->flags & ATA_QCFLAG_SINGLE)
- WARN_ON(qc->n_elem > 1);
-
VPRINTK("unmapping %u sg elements\n", qc->n_elem);
/* if we padded the buffer out to 32-bit bound, and data
@@ -4566,16 +4555,6 @@ void ata_sg_clean(struct ata_queued_cmd
memcpy(addr + psg->offset, pad_buf, qc->pad_len);
kunmap_atomic(addr, KM_IRQ0);
}
- } else {
- if (qc->n_elem)
- dma_unmap_single(ap->dev,
- sg_dma_address([0]), sg_dma_len([0]),
- dir);
- /* restore sg */
- sg->length += qc->pad_len;
- if (pad_buf)
- memcpy(qc->buf_virt + sg->length - qc->pad_len,
- pad_buf, qc->pad_len);
}
qc->flags &= ~ATA_QCFLAG_DMAMAP;
@@ -4807,16 +4786,8 @@ void ata_noop_qc_prep(struct ata_queued_
void ata_sg_init_one(struct ata_queued_cmd *qc, void *buf, unsigned int buflen)
{
- qc->flags |= ATA_QCFLAG_SINGLE;
-
- qc->__sg = >sgent;
- qc->n_elem = 1;
- qc->orig_n_elem = 1;
- qc->buf_virt = buf;
- qc->nbytes = buflen;
- qc->cursg = qc->__sg;
-
sg_init_one(>sgent, buf, buflen);
+ ata_sg_init(qc, >sgent, 1);
}
/**
@@ -4841,75 +4813,13 @@ void ata_sg_init(struct ata_queued_cmd *
qc->n_elem = n_elem;
qc->orig_n_elem = n_elem;
qc->cursg = qc->__sg;
-}
-
-/**
- * ata_sg_setup_one - DMA-map the memory buffer associated with a command.
- * @qc: Command with memory buffer to be mapped.
- *
- * DMA-map the memory buffer associated with queued_cmd @qc.
- *
- * LOCKING:
- * spin_lock_irqsave(host lock)
- *
- * RETURNS:
- * Zero on success, negative on error.
- */
-
-static int ata_sg_setup_one(struct ata_queued_cmd *qc)
-{
- struct ata_port *ap = qc->ap;
- int dir = qc->dma_dir;
- struct scatterlist *sg = qc->__sg;
- dma_addr_t dma_address;
- int trim_sg = 0;
-
- /* we must lengthen transfers to end on a 32-bit boundary */
- qc->pad_len = sg->length & 3;
- if (qc->pad_len) {
- void *pad_buf = ap->pad + (qc->tag * ATA_DMA_PAD_SZ);
- struct scatterlist *psg = >pad_sgent;
-
- WARN_ON(qc->dev->class != ATA_DEV_ATAPI);
-
- memset(pad_buf, 0, ATA_DMA_PAD_SZ);
-
- if (qc->tf.flags & ATA_TFLAG_WRITE)
- memcpy(pad_buf, qc->buf_virt + sg->length - qc->pad_len,
- qc->pad_len);
-
- sg_dma_address(psg) = ap->pad_dma + (qc->tag * ATA_DMA_PAD_SZ);
- sg_dma_len(psg) = ATA_DMA_PAD_SZ;
- /* trim sg */
- sg->length -= qc->pad_len;
- if (sg->length == 0)
- trim_sg = 1;
-
- DPRINTK("padding done, sg->length=%u pad_len=%u\n",
- sg->length, qc->pad_len);
- }
-
- if (trim_sg) {
- qc->n_elem--;
- goto skip_map;
- }
-
- dma_address = dma_map_single(ap->dev, qc->buf_virt,
-sg->length, dir);
- if
Re: 2.6.24-rc2-mm1
On Tue, Nov 13, 2007 at 07:49:24PM -0800, Greg KH wrote: > > Matt, are these the errors you were worried about with the patch we were > just talking about tha tis in my tree? I can't tell from these logs. The key question (in relation to the allow_restart patch) is this: Was everything working fine until a START_STOP was sent to the device? The SCSI layers used to send devices START_STOP to almost every device as part of initialization. I think we switched all of that to use TEST_UNIT_READY instead. The patch you've got should re-enable START_STOP to be sent. The SCSI layers (I'm told, but haven't verified myself) only send START_STOP if the device reports that it needs a startup command. CONFIG_USB_STORAGE_DEBUG will generate a *lot* of debug output. But, it should be pretty easy to see if START_STOP was sent at all, and if it caused the problems. Matt P.S. Worst case, the issue we're talking about here would only cause the device firmware to crash, which would eventually lead to a disconnect. That shouldn't have caused the much more severe problems shown in the log you sent. -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver DP: And judging from the scores, Stef has the sma... T: LET'S NOT GO THERE! -- Dust Puppy and Tanya User Friendly, 12/11/1997 pgpIQ12NeBsnh.pgp Description: PGP signature
Re: [patch/rfc 1/4] GPIO implementation framework
On Tuesday 13 November 2007, eric miao wrote:
> Subject: [PATCH 5/5] move per GPIO "requested" to "struct gpio_desc"
>
> struct gpio_desc {
> struct gpio_chip *chip;
> unsigned is_out:1;
> + unsigned requested:1;
> +#ifdef CONFIG_DEBUG_FS
> + const char *requested_str;
> +#endif
A better name for this would be "label", matching what's
passed from gpio_request(). Ndls abrviatns r bd.
Note that this means (on typical 32-bit embedded hardware)
twelve bytes per GPIO, which if you assume 256 GPIOs means
an extra 3 KB static memory compared to the patch I sent.
> @@ -43,20 +43,19 @@ static inline int gpio_is_onchip(unsigned gpio,
> struct gpio_chip *chip)
> /* Warn when drivers omit gpio_request() calls -- legal but
> * ill-advised when setting direction, and otherwise illegal.
> */
> -static void gpio_ensure_requested(struct gpio_chip *chip, unsigned offset)
> +static void gpio_ensure_requested(unsigned gpio)
Simpler to pass a gpio_desc pointer ...
> if (!requested)
> - printk(KERN_DEBUG "GPIO-%d autorequested\n",
> - chip->base + offset);
> + pr_debug("GPIO-%d autorequested\n", gpio);
Leave the printk in ... this is the sort of thing we want
to see fixed, which becomes unlikely once you hide such
diagnostics. And for that matter, what would be enabling
the "-DDEBUG" that would trigger a pr_debug() message?
... overall the main downside of these patches seems to
be that it consumes more static memory.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
On Tuesday 13 November 2007, eric miao wrote:
> Here comes the point of "struct gpio_desc"
>
> Subject: [PATCH 3/5] use a per GPIO "struct gpio_desc" and chain
> "gpio_chip" to a list
I see what it does, but don't see the "why" ... surely
you can come up with a one sentence description of why
this would be better?
And I'd been so glad to *get rid of* that list, too.
> +struct gpio_desc {
> + struct gpio_chip *chip;
> +};
> +
> -/* gpio_lock protects modification to the table of chips and to
> - * gpio_chip->requested. If a gpio is requested, its gpio_chip
> - * is not removable.
> - */
But it still protects data. Don't remove documentation for
what locks protect ... update it! Otherwise someonels going
to come by and make a change which breaks the locking model.
Usually in some subtle (hard-to-debug) way.
>
> - for (id = 0; id < ARRAY_SIZE(chips); id++) {
> - chip = chips[id];
> - if (!chip)
> - continue;
> -
> + list_for_each_entry(chip, _chip_list, node) {
> seq_printf(s, "%sGPIOs %d-%d, %s%s:\n",
> started ? "\n" : "",
> chip->base, chip->base + chip->ngpio - 1,
Note that this now produces the debug info in a relatively
random order ... ordered by registration rather than anything
useful, and hence awkward to read.
It'd be better if you just scanned your new gpio_desc[]
table in numeric order, and start a new section whenever
you find a new gpio_chip.
That'd get rid of that otherwise-useless list, too.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] - [6/15] - remove defconfig ptr comparisons to 0 - fs/jfs
On Tue, 2007-11-13 at 18:05 -0800, Joe Perches wrote: > Remove defconfig ptr comparison to 0 > > Remove sparse warning: Using plain integer as NULL pointer > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> Signed-off-by: Dave Kleikamp <[EMAIL PROTECTED]> I've added this to the jfs git tree. Thanks, Shaggy -- David Kleikamp IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
On Tue, 13 Nov 2007, David Miller wrote: > From: Christoph Lameter <[EMAIL PROTECTED]> > Date: Tue, 13 Nov 2007 20:15:55 -0800 (PST) > > > Guess I need also to add an arch configuration guide to V2 as well so that > > the other arches can do similar tricks and emphasize that the static > > default that requires bss is only suitable for small systems. > > I'm going to be against your changes until you implement > a real fix for the BSS bloat problems. > > It's worse than the per-cpu allocator we have now, much > worse. You need to configure cpu_alloc for your arch and so far you seem to not have had the time to understand how it works otherwise you would not repeat these statements and ask me to implement what the patch already provides. The only problem that I see so far is a communication problem. Thus we need more documentation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
BTW [EMAIL PROTECTED] does not exist, please remove it from the CC: in the future :-) Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
From: Christoph Lameter <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 20:15:55 -0800 (PST) > Guess I need also to add an arch configuration guide to V2 as well so that > the other arches can do similar tricks and emphasize that the static > default that requires bss is only suitable for small systems. I'm going to be against your changes until you implement a real fix for the BSS bloat problems. It's worse than the per-cpu allocator we have now, much worse. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1
Gabriel C wrote:
> Andrew Morton wrote:
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/
>
> I got it to boot but ..
>
> ...
> [ 45.030261] input: Power Button (CM) as /devices/virtual/input/input4
> [ 45.031331] BUG: sleeping function called from invalid context at
> kernel/rwsem.c:47
> [ 45.031560] in_atomic():0, irqs_disabled():1
> [ 45.031569] 1 lock held by modprobe/2105:
> [ 45.031574] #0: (pm_qos_lock){}, at: []
> pm_qos_add_notifier+0x14/0x3c
> [ 45.031606] irq event stamp: 4036
> [ 45.031612] hardirqs last enabled at (4035): []
> debug_check_no_locks_freed+0xf9/0x105
> [ 45.031632] hardirqs last disabled at (4036): []
> _spin_lock_irqsave+0x10/0x55
> [ 45.031653] softirqs last enabled at (3710): []
> __do_softirq+0xe9/0xf1
> [ 45.031670] softirqs last disabled at (3703): []
> do_softirq+0x3a/0x52
> [ 45.031685] [] show_trace_log_lvl+0x12/0x25
> [ 45.031702] [] show_trace+0xd/0x10
> [ 45.031717] [] dump_stack+0x16/0x18
> [ 45.031728] [] __might_sleep+0xc2/0xc9
> [ 45.031740] [] down_write+0x17/0x6f
> [ 45.031754] [] blocking_notifier_chain_register+0x26/0x3f
> [ 45.031766] [] pm_qos_add_notifier+0x27/0x3c
> [ 45.031778] [] acpi_processor_power_init+0x4d/0x164 [processor]
> [ 45.031802] [] acpi_processor_start+0x503/0x556 [processor]
> [ 45.031820] [] acpi_start_single_object+0x20/0x3d
> [ 45.031837] [] acpi_device_probe+0x78/0x88
> [ 45.031850] [] driver_probe_device+0xb2/0x12d
> [ 45.031866] [] __driver_attach+0x76/0xaf
> [ 45.031878] [] bus_for_each_dev+0x3e/0x60
> [ 45.031889] [] driver_attach+0x14/0x16
> [ 45.031899] [] bus_add_driver+0x7a/0x180
> [ 45.031909] [] driver_register+0x57/0x5c
> [ 45.031918] [] acpi_bus_register_driver+0x3a/0x3c
> [ 45.031929] [] acpi_processor_init+0x73/0xc5 [processor]
> [ 45.031943] [] sys_init_module+0x14e3/0x15ae
> [ 45.031958] [] sysenter_past_esp+0x5f/0xa5
> [ 45.031969] ===
> [ 45.032213] ACPI: Invalid PBLK length [0]
> [ 45.032465] ACPI: Invalid PBLK length [0]
> [ 45.032656] ACPI: Invalid PBLK length [0]
>
>
> ...
>
> ...
> [ 102.331554] BUG: sleeping function called from invalid context at
> kernel/rwsem.c:20
> [ 102.331575] in_atomic():0, irqs_disabled():1
> [ 102.331583] 1 lock held by artsd/4385:
> [ 102.331589] #0: (pm_qos_lock){}, at: []
> pm_qos_add_requirement+0x5a/0x98
> [ 102.331619] irq event stamp: 19022
> [ 102.331624] hardirqs last enabled at (19021): []
> _spin_unlock_irqrestore+0x36/0x3c
> [ 102.331641] hardirqs last disabled at (19022): []
> _spin_lock_irqsave+0x10/0x55
> [ 102.331655] softirqs last enabled at (18846): []
> __do_softirq+0xe9/0xf1
> [ 102.331672] softirqs last disabled at (18839): []
> do_softirq+0x3a/0x52
> [ 102.331688] [] show_trace_log_lvl+0x12/0x25
> [ 102.331704] [] show_trace+0xd/0x10
> [ 102.331715] [] dump_stack+0x16/0x18
> [ 102.331727] [] __might_sleep+0xc2/0xc9
> [ 102.331739] [] down_read+0x16/0x6a
> [ 102.331750] [] __blocking_notifier_call_chain+0x24/0x4c
> [ 102.331761] [] blocking_notifier_call_chain+0xc/0xe
> [ 102.331773] [] update_target+0x3e/0x43
> [ 102.331784] [] pm_qos_add_requirement+0x76/0x98
> [ 102.331795] [] snd_pcm_hw_params_user+0x2b1/0x302
> [ 102.331811] [] snd_pcm_common_ioctl1+0x17a/0xda3
> [ 102.331825] [] snd_pcm_playback_ioctl1+0x3ab/0x3c2
> [ 102.331840] [] snd_pcm_playback_ioctl+0x27/0x35
> [ 102.331853] [] vfs_ioctl+0x22/0x67
> [ 102.331867] [] do_vfs_ioctl+0x25a/0x268
> [ 102.331878] [] sys_ioctl+0x2c/0x45
> [ 102.331889] [] sysenter_past_esp+0x5f/0xa5
> [ 102.331901] ===
> [ 102.331911] WARNING: at arch/x86/kernel/smp_32.c:561
> native_smp_call_function_mask()
> [ 102.331920] [] show_trace_log_lvl+0x12/0x25
> [ 102.331932] [] show_trace+0xd/0x10
> [ 102.331944] [] dump_stack+0x16/0x18
> [ 102.331955] [] native_smp_call_function_mask+0x39/0x11d
> [ 102.331970] [] smp_call_function+0x18/0x1d
> [ 102.331984] [] acpi_processor_latency_notify+0x13/0x1a
> [processor]
> [ 102.332011] [] notifier_call_chain+0x2b/0x4a
> [ 102.332023] [] __blocking_notifier_call_chain+0x37/0x4c
> [ 102.332035] [] blocking_notifier_call_chain+0xc/0xe
> [ 102.332047] [] update_target+0x3e/0x43
> [ 102.332058] [] pm_qos_add_requirement+0x76/0x98
> [ 102.332070] [] snd_pcm_hw_params_user+0x2b1/0x302
> [ 102.332085] [] snd_pcm_common_ioctl1+0x17a/0xda3
> [ 102.332097] [] snd_pcm_playback_ioctl1+0x3ab/0x3c2
> [ 102.332111] [] snd_pcm_playback_ioctl+0x27/0x35
> [ 102.332123] [] vfs_ioctl+0x22/0x67
> [ 102.332134] [] do_vfs_ioctl+0x25a/0x268
> [ 102.332146] [] sys_ioctl+0x2c/0x45
> [ 102.332156] [] sysenter_past_esp+0x5f/0xa5
> [ 102.332167] ===
> [ 102.357016] WARNING: at arch/x86/kernel/smp_32.c:561
>
[PATCH 2/2] sata_nv: fix ATAPI issues with memory over 4GB (v3)
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA mode
on systems with memory located above 4GB. We need to delay setting the 64-bit
DMA mask until the PRD table and padding buffer are allocated so that they don't
get allocated above 4GB and break legacy mode (which is needed for ATAPI
devices).
Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
--- linux-2.6.24-rc1-git10edit/drivers/ata/sata_nv.c.before 2007-11-13
19:04:18.0 -0600
+++ linux-2.6.24-rc1-git10edit/drivers/ata/sata_nv.c2007-11-13
19:02:34.0 -0600
@@ -247,6 +247,7 @@
void __iomem*ctl_block;
void __iomem*gen_block;
void __iomem*notifier_clear_block;
+ u64 adma_dma_mask;
u8 flags;
int last_issue_ncq;
};
@@ -748,7 +749,7 @@
adma_enable = 0;
nv_adma_register_mode(ap);
} else {
- bounce_limit = *ap->dev->dma_mask;
+ bounce_limit = pp->adma_dma_mask;
segment_boundary = NV_ADMA_DMA_BOUNDARY;
sg_tablesize = NV_ADMA_SGTBL_TOTAL_LEN;
adma_enable = 1;
@@ -763,6 +764,11 @@
config_mask = NV_MCP_SATA_CFG_20_PORT0_EN |
NV_MCP_SATA_CFG_20_PORT0_PWB_EN;
+ /* Set appropriate DMA mask. */
+ rc = pci_set_dma_mask(pdev, bounce_limit);
+ if (rc)
+ return rc;
+
if (adma_enable) {
new_reg = current_reg | config_mask;
pp->flags &= ~NV_ADMA_ATAPI_SETUP_COMPLETE;
@@ -1134,6 +1140,7 @@
void *mem;
dma_addr_t mem_dma;
void __iomem *mmio;
+ struct pci_dev *pdev = to_pci_dev(dev);
u16 tmp;
VPRINTK("ENTER\n");
@@ -1153,6 +1160,14 @@
pp->notifier_clear_block = pp->gen_block +
NV_ADMA_NOTIFIER_CLEAR + (4 * ap->port_no);
+ /* Now that the legacy PRD and padding buffer are allocated we can
+ safely raise the DMA mask to allocate the CPB/APRD table. */
+ pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
+ pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
+ /* Store the mask that was actually used so we can restore it later
+ if needed */
+ pp->adma_dma_mask = *dev->dma_mask;
+
mem = dmam_alloc_coherent(dev, NV_ADMA_PORT_PRIV_DMA_SZ,
_dma, GFP_KERNEL);
if (!mem)
@@ -2408,12 +2423,6 @@
hpriv->type = type;
host->private_data = hpriv;
- /* set 64bit dma masks, may fail */
- if (type == ADMA) {
- if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
- pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
- }
-
/* request and iomap NV_MMIO_BAR */
rc = pcim_iomap_regions(pdev, 1 << NV_MMIO_BAR, DRV_NAME);
if (rc)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] sata_nv: don't use legacy DMA in ADMA mode
We need to run any DMA command with result taskfile requested in ADMA mode
when the port is in ADMA mode, otherwise it may try to use the legacy DMA engine
in ADMA mode which is not allowed. Enforce this with BUG_ON() since data
corruption could potentially result if this happened.
Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
--- linux-2.6.24-rc1-git10/drivers/ata/sata_nv.c2007-11-01
20:01:32.0 -0600
+++ linux-2.6.24-rc1-git10edit/drivers/ata/sata_nv.c2007-11-13
19:01:09.0 -0600
@@ -791,11 +797,13 @@
static void nv_adma_tf_read(struct ata_port *ap, struct ata_taskfile *tf)
{
- /* Since commands where a result TF is requested are not
- executed in ADMA mode, the only time this function will be called
- in ADMA mode will be if a command fails. In this case we
- don't care about going into register mode with ADMA commands
- pending, as the commands will all shortly be aborted anyway. */
+ /* Other than when internal or pass-through commands are executed,
+ the only time this function will be called in ADMA mode will be
+ if a command fails. In the failure case we don't care about going
+ into register mode with ADMA commands pending, as the commands will
+ all shortly be aborted anyway. We assume that NCQ commands are not
+ issued via passthrough and so this will not abort any commands in
+ that case. */
nv_adma_register_mode(ap);
ata_tf_read(ap, tf);
@@ -1359,11 +1376,9 @@
struct nv_adma_port_priv *pp = qc->ap->private_data;
/* ADMA engine can only be used for non-ATAPI DMA commands,
- or interrupt-driven no-data commands, where a result taskfile
- is not required. */
+ or interrupt-driven no-data commands. */
if ((pp->flags & NV_ADMA_ATAPI_SETUP_COMPLETE) ||
- (qc->tf.flags & ATA_TFLAG_POLLING) ||
- (qc->flags & ATA_QCFLAG_RESULT_TF))
+ (qc->tf.flags & ATA_TFLAG_POLLING))
return 1;
if ((qc->flags & ATA_QCFLAG_DMAMAP) ||
@@ -1381,6 +1396,8 @@
NV_CPB_CTL_IEN;
if (nv_adma_use_reg_mode(qc)) {
+ BUG_ON(!(pp->flags & NV_ADMA_ATAPI_SETUP_COMPLETE) &&
+ (qc->flags & ATA_QCFLAG_DMAMAP));
nv_adma_register_mode(qc->ap);
ata_qc_prep(qc);
return;
@@ -1428,6 +1445,8 @@
if (nv_adma_use_reg_mode(qc)) {
/* use ATA register mode */
VPRINTK("using ATA register mode: 0x%lx\n", qc->flags);
+ BUG_ON(!(pp->flags & NV_ADMA_ATAPI_SETUP_COMPLETE) &&
+ (qc->flags & ATA_QCFLAG_DMAMAP));
nv_adma_register_mode(qc->ap);
return ata_qc_issue_prot(qc);
} else
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
Hmmm.. I have v2 in preparation here that puts the pda and the per cpu data into the cpu_alloc area. Thus gs: can be used to access all per cpu data. Any ideas how to abstract out the pda operations? Wasnt local_t supposed to be able to do atomic ops on cpu data? Is there an segment register version of local_t? I want also to have cmpxchg xchg etc that are all atomic without requiring any interrupt disable or preempt disable. cpu_alloc allows pointer arithmetic on cpu area pointers. The segment prefix can then be used to select the appropriate area. Guess I need also to add an arch configuration guide to V2 as well so that the other arches can do similar tricks and emphasize that the static default that requires bss is only suitable for small systems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB
Tejun Heo wrote: Could be done.. but, I don't want to constrain the ADMA APRD/CPB area in that way (there are some dual-socket Opteron boxes with this controller, forcing an allocation below 4GB for this could force a non-optimal node allocation I think..) To do this I'd have to raise the mask for the APRD allocation, drop it again, then raise it again in ADMA mode, which is kind of ugly. I don't think it really matters. The table isn't too big and it's not like access to the table has any processor locality. Maybe it's better to allocate to the same node as the irq but raising DMA mask doesn't help at all. It's quite possible that restricting the DMA mask will also restrict what node that can get allocated on. I'm not so much thinking of the CPU access to the table but the controller's banging on the thing several times for each command.. I think performance impact is nil either way but even in highly unlikely case it has any impact, allocating PRDs under 4G should be better as it avoids DAC cycles on the bus. But again, this is just irrelevant. I'd say just allocate everything under 4G. The DAC issue shouldn't matter as these controllers are integrated into the chipset so it will be using all HT bus transactions, not PCI. We can do it without all that mess in slave_config though, just by delaying raising the DMA mask until after the PRD/pad buffers are allocated. Also, I'd rather not allocate the legacy PRD at all if we're in ADMA mode. That way, if some bug causes us to try and do legacy DMA in ADMA mode, we'll crash from null pointer dereference instead of potentially transferring incorrect data (as we had in this case) and corrupting things. Yeap, I can agree with this. But can you add BUG_ON()/WARN_ON() at places instead? I know blanking pointers feel safer but I think it's best to keep resource allocation / release in ->port_start/stop(). Yeah, I've got rid of that stuff now and added some BUG_ONs for this. Will submit the patches shortly. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
On Tuesday 13 November 2007, David Brownell wrote: > http://marc.info/?l=linux-kernel=119463810905330=2 > http://marc.info/?l=linux-kernel=119463811005344=2 > http://marc.info/?l=linux-kernel=119463811105352=2 > > Plus the appended tweak. -ENOPATCH ... ;) == Minor fixups to the gpiolib code. Signed-off-by: David Brownell <[EMAIL PROTECTED]> --- lib/gpiolib.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- g26.orig/lib/gpiolib.c 2007-11-12 15:06:45.0 -0800 +++ g26/lib/gpiolib.c 2007-11-12 15:07:36.0 -0800 @@ -28,7 +28,7 @@ #defineextra_checks0 #endif -/* gpio_lock protects the table of chips and to gpio_chip->requested. +/* gpio_lock protects the table of chips and gpio_chip->requested. * While any gpio is requested, its gpio_chip is not removable. It's * a raw spinlock to ensure safe access from hardirq contexts, and to * shrink bitbang overhead: per-bit preemption would be very wrong. @@ -533,6 +533,6 @@ static int __init gpiolib_debugfs_init(v NULL, NULL, _operations); return 0; } -postcore_initcall(gpiolib_debugfs_init); +subsys_initcall(gpiolib_debugfs_init); #endif /* DEBUG_FS */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
On Tuesday 13 November 2007, eric miao wrote: > > > Can we use "per gpio based" structure instead of "per gpio_chip" based > > > one, > > > just like what the generic IRQ layer is doing nowadays? > > > > We "can" do most anything. What would that improve though? ... What would that improve, though? Your followup posts still don't answer that question for me. I see the code, but don't have an answer to that question. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
On Tuesday 13 November 2007, eric miao wrote: > > so that requested will always be used, only *requested_str will be used > for DEBUG_FS tracking assistance > > Subject: [PATCH 2/5] define gpio_chip.requested_str as a debugfs tracking > string Doesn't seem unreasonable, since the extra cost is only one bit per GPIO (and that would be paid only when debugfs is available). What can I say ... I'd rather not pay the extra memory space. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
On Wed, 14 Nov 2007, Andi Kleen wrote: > On Tue, Nov 13, 2007 at 05:52:08PM -0800, David Miller wrote: > > Yes, I've run into similar problems with lockdep as well. > > I had to build an ultra minimalized kernel to get it to > > boot on my Niagara boxes. > > > > I think I even looked at the same lockdep code, and I'd > > appreciate it if you'd submit your fix for this if you > > haven't already. > > ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/early-reserve > ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/early-alloc > ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/lockdep-early-alloc > > I didn't plan to submit it for .24, just .25. Or do you need it > urgently? > > Also it would require you to write a sparc specific arch_early_alloc() > of course. I've only done the x86-64 version. IA64 also has no lockdep. What arches support lockdep? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
From: Andi Kleen <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 03:28:32 +0100 > ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/early-reserve > ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/early-alloc > ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/lockdep-early-alloc > > I didn't plan to submit it for .24, just .25. Or do you need it > urgently? I don't need it urgently, 2.6.25 is perfectly fine. > Also it would require you to write a sparc specific arch_early_alloc() > of course. I've only done the x86-64 version. I'll be sure to take care of that when it hits .25 Thanks Andi. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 18:27:00 -0800 > Let me just say - I'm astonished at how little spam gets though the vger > lists. Considering how many times those email addresses must have been > added to spam databases. > > It must be a lot of work, and whoever is doing it does it well. > > I don't even know. Is it Matti? You? Matti gets all the credit for setting up the bayesian et al. filters we have and training it as needed. > Yes, sourceforge is a complete joke. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1
Uff clone-prepare-to-recycle-clone_detached-and-clone_stopped.patch *really* spams. Looks like some programs are using this 'deprecated flag'. Could this have some CONFIG_SPAM_ME_PLEASE ?;) This is what I got in some minutes : --dmesg|grep 'used deprecated clone flags'|sed 's/.*] //'|sort -u fork(): process `artsd' used deprecated clone flags 0x40 fork(): process `firefox-bin' used deprecated clone flags 0x40 fork(): process `gcompris' used deprecated clone flags 0x40 fork(): process `qgit' used deprecated clone flags 0x40 fork(): process `thunderbird-bin' used deprecated clone flags 0x40 fork(): process `wish' used deprecated clone flags 0x40 fork(): process `xchat' used deprecated clone flags 0x40 fork(): process `kdbus' used deprecated clone flags 0x40 --dmesg|grep 'used deprecated clone flags'|wc -l 151 Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH 000 of 2] md: Fixes for md in 2.6.23
On Tue, Nov 13, 2007 at 08:36:05PM -0700, Dan Williams wrote:
> On Nov 13, 2007 5:23 PM, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Tue, Nov 13, 2007 at 04:22:14PM -0800, Greg KH wrote:
> > > On Mon, Oct 22, 2007 at 05:15:27PM +1000, NeilBrown wrote:
> > > >
> > > > It appears that a couple of bugs slipped in to md for 2.6.23.
> > > > These two patches fix them and are appropriate for 2.6.23.y as well
> > > > as 2.6.24-rcX
> > > >
> > > > Thanks,
> > > > NeilBrown
> > > >
> > > > [PATCH 001 of 2] md: Fix an unsigned compare to allow creation of
> > > > bitmaps with v1.0 metadata.
> > > > [PATCH 002 of 2] md: raid5: fix clearing of biofill operations
> > >
> > > I don't see these patches in 2.6.24-rcX, are they there under some other
> > > subject?
> >
> > Oh nevermind, I found them, sorry for the noise...
> >
>
> Careful, it looks like you cherry picked commit 4ae3f847 "md: raid5:
> fix clearing of biofill operations" which ended up misapplied in
> Linus' tree, You should either also pick up def6ae26 "md: fix
> misapplied patch in raid5.c" or I can resend the original "raid5: fix
> clearing of biofill operations."
>
> The other patch for -stable "raid5: fix unending write sequence" is
> currently in -mm.
Hm, I've attached the two patches that I have right now in the -stable
tree so far (still have over 100 patches to go, so I might not have
gotten to them yet if you have sent them). These were sent to me by
Andrew on their way to Linus. if I should drop either one, or add
another one, please let me know.
thanks,
greg k-h
>From [EMAIL PROTECTED] Mon Oct 22 20:45:35 2007
From: [EMAIL PROTECTED]
Date: Mon, 22 Oct 2007 20:45:11 -0700
Subject: md: fix an unsigned compare to allow creation of bitmaps with v1.0 metadata
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
From: NeilBrown <[EMAIL PROTECTED]>
patch 85bfb4da8cad483a4e550ec89060d05a4daf895b in mainline.
As page->index is unsigned, this all becomes an unsigned comparison, which
almost always returns an error.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/md/bitmap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -274,7 +274,7 @@ static int write_sb_page(struct bitmap *
if (bitmap->offset < 0) {
/* DATA BITMAP METADATA */
if (bitmap->offset
-+ page->index * (PAGE_SIZE/512)
++ (long)(page->index * (PAGE_SIZE/512))
+ size/512 > 0)
/* bitmap runs in to metadata */
return -EINVAL;
>From [EMAIL PROTECTED] Mon Oct 22 20:45:44 2007
From: Dan Williams <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 20:45:11 -0700
Subject: md: raid5: fix clearing of biofill operations
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
From: Dan Williams <[EMAIL PROTECTED]>
patch 4ae3f847e49e3787eca91bced31f8fd328d50496 in mainline.
ops_complete_biofill() runs outside of spin_lock(>lock) and clears the
'pending' and 'ack' bits. Since the test_and_ack_op() macro only checks
against 'complete' it can get an inconsistent snapshot of pending work.
Move the clearing of these bits to handle_stripe5(), under the lock.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
Tested-by: Joel Bertrand <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/md/raid5.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -377,7 +377,12 @@ static unsigned long get_stripe_work(str
ack++;
sh->ops.count -= ack;
- BUG_ON(sh->ops.count < 0);
+ if (unlikely(sh->ops.count < 0)) {
+ printk(KERN_ERR "pending: %#lx ops.pending: %#lx ops.ack: %#lx "
+ "ops.complete: %#lx\n", pending, sh->ops.pending,
+ sh->ops.ack, sh->ops.complete);
+ BUG();
+ }
return pending;
}
@@ -551,8 +556,7 @@ static void ops_complete_biofill(void *s
}
}
}
- clear_bit(STRIPE_OP_BIOFILL, >ops.ack);
- clear_bit(STRIPE_OP_BIOFILL, >ops.pending);
+ set_bit(STRIPE_OP_BIOFILL, >ops.complete);
return_io(return_bi);
@@ -2903,6 +2907,13 @@ static void handle_stripe6(struct stripe
s.expanded = test_bit(STRIPE_EXPAND_READY, >state);
/* Now to look around and see what can be done */
+ /* clean-up completed biofill operations */
+ if (test_bit(STRIPE_OP_BIOFILL, >ops.complete)) {
+ clear_bit(STRIPE_OP_BIOFILL, >ops.pending);
+ clear_bit(STRIPE_OP_BIOFILL, >ops.ack);
+ clear_bit(STRIPE_OP_BIOFILL, >ops.complete);
+ }
+
rcu_read_lock();
for (i=disks; i--; ) {
mdk_rdev_t *rdev;
[PATCH] Fix build failure when CONFIG_INFINIBAND_IPOIB_CM is not defined.
Fixes: CC [M] drivers/infiniband/ulp/ipoib/ipoib_main.o drivers/infiniband/ulp/ipoib/ipoib_main.c: In function ‘ipoib_init_module’: drivers/infiniband/ulp/ipoib/ipoib_main.c:1269: error: invalid lvalue in assignment In the case where CONFIG_INFINIBAND_IPOIB_CM is not defined ipoib_max_conn_qp is #defined to 0. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- drivers/infiniband/ulp/ipoib/ipoib_main.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c index 623458e..aeb5a01 100644 --- a/drivers/infiniband/ulp/ipoib/ipoib_main.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c @@ -1265,8 +1265,9 @@ static int __init ipoib_init_module(void) ipoib_sendq_size = roundup_pow_of_two(ipoib_sendq_size); ipoib_sendq_size = min(ipoib_sendq_size, IPOIB_MAX_QUEUE_SIZE); ipoib_sendq_size = max(ipoib_sendq_size, IPOIB_MIN_QUEUE_SIZE); - +#ifdef CONFIG_INFINIBAND_IPOIB_CM ipoib_max_conn_qp = min(ipoib_max_conn_qp, IPOIB_CM_MAX_CONN_QP); +#endif ret = ipoib_register_debugfs(); if (ret) Yours Tony linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/ Jan 28 - Feb 02 2008 The Australian Linux Technical Conference! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH 000 of 2] md: Fixes for md in 2.6.23
On Nov 13, 2007 5:23 PM, Greg KH <[EMAIL PROTECTED]> wrote: > On Tue, Nov 13, 2007 at 04:22:14PM -0800, Greg KH wrote: > > On Mon, Oct 22, 2007 at 05:15:27PM +1000, NeilBrown wrote: > > > > > > It appears that a couple of bugs slipped in to md for 2.6.23. > > > These two patches fix them and are appropriate for 2.6.23.y as well > > > as 2.6.24-rcX > > > > > > Thanks, > > > NeilBrown > > > > > > [PATCH 001 of 2] md: Fix an unsigned compare to allow creation of > > > bitmaps with v1.0 metadata. > > > [PATCH 002 of 2] md: raid5: fix clearing of biofill operations > > > > I don't see these patches in 2.6.24-rcX, are they there under some other > > subject? > > Oh nevermind, I found them, sorry for the noise... > Careful, it looks like you cherry picked commit 4ae3f847 "md: raid5: fix clearing of biofill operations" which ended up misapplied in Linus' tree, You should either also pick up def6ae26 "md: fix misapplied patch in raid5.c" or I can resend the original "raid5: fix clearing of biofill operations." The other patch for -stable "raid5: fix unending write sequence" is currently in -mm. > greg k-h Regards, Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
about ext3_readpage
Hi, all
when I read ext3_readpage function following
ext3_readpage->mpage_readpage->do_mpage_readpage, there are:
nblocks = map_bh->b_size >> blkbits;
if (buffer_mapped(map_bh) && block_in_file > *first_logical_block &&
block_in_file < (*first_logical_block + nblocks)) {
unsigned map_offset = block_in_file - *first_logical_block;
unsigned last = nblocks - map_offset;
for (relative_block = 0; ; relative_block++) {
if (relative_block == last) {
clear_buffer_mapped(map_bh);
break;
}
if (page_block == blocks_per_page)
break;
blocks[page_block] = map_bh->b_blocknr + map_offset +
relative_block;
page_block++;
block_in_file++;
}
bdev = map_bh->b_bdev;
}
Since map_bh->b_size is the size of the block buffer, and blkbits is
associated with the block in inode, why does he do the operation >> ?
And what is the meaning and usage of first_logical_block? the initial
value of it is 0.
Hope someone will help me!
Thanks!
--
National Research Center for Intelligent Computing Systems
Institute of Computing Technology, Chinese Academy of Sciences
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci hotplug: fix rpaphp directory naming
On Tue, Nov 13, 2007 at 06:34:55PM -0600, Linas Vepstas wrote: > > > Fix presentation of the slot number in the /sys/bus/pci/slots > directory to match that used in the majority of other drivers. We need a signed-off-by: to be able to apply this... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
On Tuesday 13 November 2007, eric miao wrote: > > Here comes a bunch of patches to illustrate my idea, some are not related to > the point I mentioned, and they are not mature for now :-) > > Subject: [PATCH 1/5] add gpio_is_onchip() for commonly used gpio range > checking I'll send substantive comments later, but meanwhile note that the *CURRENT* version was posted last Friday: http://marc.info/?l=linux-kernel=119463810905330=2 http://marc.info/?l=linux-kernel=119463811005344=2 http://marc.info/?l=linux-kernel=119463811105352=2 Plus the appended tweak. It's more useful to send patches against current code, so applying them doesn't provide a small avalanche of rejects. :) With respect to this patch adding gpio_is_onchip(), I don't see a point. The "gpio >= chip->base" check is basically "are the data structures corrupted?" and so it should only be done if "extra_checks" is defined. (And IMO, not then ...) And combining the other two tests that way doesn't make anything more clear to me. That's somewhat of a style issue, I guess, unless you're like me and don't much trust GCC to avoid extra instructions. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stuck nfsd processes with 2.6.24-rc2
On Wed, Nov 14, 2007 at 02:36:18AM +0100, Christian Kujau wrote:
> On Tue, 13 Nov 2007, Christian Kujau wrote:
>> Ah, I forgot about that. Will do as soon as I get a working kernel again.
>> I'm in the middle of git-bisecting and I had to mark the last 2 versions
>> as "bad" but only because they 1) Oopsed during boot or 2) could not load
>> the kernel image:
>
> Same again: after 3 working versions I have to mark yet another one as
> "bad" - not because the NFS bug showed up, but I was unable to boot again
> ("linux 'zimage' kernel too big" message again). So now I am at:
Hm, so assuming I got the gitk invocation right. (I basically just ran
gitk ^goodsha1 ^goodsha2 ...etc... badsha1 badsha2 ... fs/nfsd
include/linux/nfsd net/sunrpc /include/linux/sunrpc),
nothing really obvious pops out from that list. I think the only
nonobvious changes that touch code you're likely to be hitting are the
exportfs rewrite.
Have you checked that the filesystem itself is OK? (If you 'ls
/path/to/exported/filesystem' on the server does that work?)
Anyway if you get the git-bisect results, that'll be very helpful. Till
then, yeah, sysrq-T is probably still the first thing to try.
--b.
>
> -
> git-bisect start
> # bad: [6e800af233e0bdf108efb7bd23c11ea6fa34cdeb] ACPI: add documentation for
> deprecated /proc/acpi/battery in ACPI_PROCFS
> git-bisect bad 6e800af233e0bdf108efb7bd23c11ea6fa34cdeb
> # good: [bbf25010f1a6b761914430f5fca081ec8c7accd1] Linux 2.6.23
> git-bisect good bbf25010f1a6b761914430f5fca081ec8c7accd1
> # good: [fba956c46a72f9e7503fd464ffee43c632307e31] Map volume and brightness
> events on thinkpads
> git-bisect good fba956c46a72f9e7503fd464ffee43c632307e31
> # bad: [7b1915a989ea4d426d0fd98974ab80f30ef1d779] mm/oom_kill.c: Use
> list_for_each_entry instead of list_for_each
> git-bisect bad 7b1915a989ea4d426d0fd98974ab80f30ef1d779
> # bad: [c223701cf6c706f42840631c1ca919a18e6e2800] ide: add "hdx=nodma" kernel
> parameter
> git-bisect bad c223701cf6c706f42840631c1ca919a18e6e2800
> # good: [1d677a6dfaac1d1cf51a7f58847077240985faf2] pm3fb: hardware cursor
> support
> git-bisect good 1d677a6dfaac1d1cf51a7f58847077240985faf2
> # good: [291702f017efdfe556cb87b8530eb7d1ff08cbae] [ALSA] Support ASUS P701
> eeepc [0x1043 0x82a1] support
> git-bisect good 291702f017efdfe556cb87b8530eb7d1ff08cbae
> # good: [92d15c2ccbb3e31a3fc71ad28fdb55e1319383c0] Merge branch 'for-linus'
> of git://git.kernel.dk/data/git/linux-2.6-block
> git-bisect good 92d15c2ccbb3e31a3fc71ad28fdb55e1319383c0
> # bad: [f77bf01425b11947eeb3b5b54685212c302741b8] kbuild: introduce
> ccflags-y, asflags-y and ldflags-y
> git-bisect bad f77bf01425b11947eeb3b5b54685212c302741b8
> -
>
> I'm not sure wether it's sane to continue at all ("only 19 revisions
> left!"); but this has to wait until tomorrow anyway...
>
> @Bruce: sysrq-t will have to wait too, sorry.
>
>
> thanks for any ideas,
> Christian.
> --
> BOFH excuse #70:
>
> nesting roaches shorted out the ether cable
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Let 'make help' output info about includecheck
On Mon, Nov 12, 2007 at 12:56:35AM +0100, Jesper Juhl wrote: >From: Jesper Juhl <[EMAIL PROTECTED]> > >'make includecheck' is useful and we want people to run it, so >let 'make help' output information about its existence. > > >Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> I think Randy Dunlap has done this[1]. ;) [1] http://lkml.org/lkml/2007/11/4/120 Regards. Cong - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 5/8] Immediate Values - x86 Optimization (update 2)
Mathieu Desnoyers wrote: Immediate Values - x86 Optimization x86 optimization of the immediate values which uses a movl with code patching to set/unset the value used to populate the register used as variable source. Changelog: - Use text_poke_early with cr0 WP save/restore to patch the bypass. We are doing non atomic writes to a code region only touched by us (nobody can execute it since we are protected by the immediate_mutex). - Put immediate_set and _immediate_set in the architecture independent header. - Use $0 instead of %2 with (0) operand. - Add x86_64 support, ready for i386+x86_64 -> x86 merge. - Use asm-x86/asm.h. Ok, so the most flexible solution that I see, that should fit for both i386 and x86_64 would be : 1 byte : "=Q" : Any register accessible as rh: a, b, c, and d. 2, 4 bytes : "=R" : Legacy register—the eight integer registers available on all i386 processors (a, b, c, d, si, di, bp, sp). 8 bytes : (only for x86_64) "=r" : A register operand is allowed provided that it is in a general register. That should make sure x86_64 won't try to use REX prefixed opcodes for 1, 2 and 4 bytes values. I just had a couple of utterly sick ideas. Consider this variant (this example is for a 32-bit immediate on x86-64, but the obvious macroizations apply): .section __discard,"a",@progbits 1: movl $0x12345678,%r9d 2: .previous .section __immediate,"a",@progbits .quad foo_immediate, (3f)-4, 4 .previous .org . + ((-.-(2b-1b)) & 3), 0x90 movl $0x12345678,%r9d 3: The idea is that the instruction is emitted into a section, which is marked DISCARD in the linker script. That lets us actually measure the length, and since we know the immediate is always at the end of the instruction... done! -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] - [12/15] - remove defconfig ptr comparisons to 0 - include/asm-x86
On Tue, 13 Nov 2007, Joe Perches wrote:
>
> Remove defconfig ptr comparison to 0
>
> The memcpy from memory location 0 sure looks odd.
Btw, this is also very compiler-bug-prone.
And sadly, the cast to "(void *)" doesn't help. This could easily be a
case where a compiler decides to play lawyer games, knowing that "NULL
pointers cannot be dereferenced", deciding that it's all totally undefined
behavior, and then just "optimizing" it all away.
> - memcpy(, 0, sizeof(struct acpi_table_header));
> + memcpy(, (void *)0, sizeof(struct acpi_table_header));
So to be safe from bogus compilers who care more about standards than the
obvious intention of the programmer, it might actually be better in the
long run to do something like
static inline void *create_pointer(unsigned long val)
{
void *result;
asm("":"=r" (result):"0" (val));
return result;
}
and then use "create_pointer(0)" here.
On that note: I'm not going to apply this series, because it's simply not
really appropriate any more. But when re-sending for 2.6.25-rc1, can you
make the subject lines have a slightly higher signal-to-noise ratio, ie
dropt he unnecessary stuff that doesn't add any value as a commit message
(eg "defconfig"? Is it really relevant?), and make it properly formatted?
My scripts by default remove the stuff in between []'s, so the end result
for the commit message header from this subject line would be
"- remove defconfig ptr comparisons to 0 - include/asm-x86"
which is strange and not very useful. It would read better as
Subject: [PATCH 1/15] include/asm-x86: remove ptr comparisons to 0
which would create a commit message header that is more readable.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] - [7/15] - remove defconfig ptr comparisons to 0 - fs/lockd
On Tuesday November 13, [EMAIL PROTECTED] wrote:
> Remove defconfig ptr comparison to 0
>
> Remove sparse warning: Using plain integer as NULL pointer
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> ---
>
> diff --git a/fs/lockd/svcshare.c b/fs/lockd/svcshare.c
> index 068886d..98548ad 100644
> --- a/fs/lockd/svcshare.c
> +++ b/fs/lockd/svcshare.c
> @@ -71,7 +71,7 @@ nlmsvc_unshare_file(struct nlm_host *host, struct nlm_file
> *file,
> struct nlm_share*share, **shpp;
> struct xdr_netobj *oh = >lock.oh;
>
> - for (shpp = >f_shares; (share = *shpp) != 0; shpp =
> >s_next) {
> + for (shpp = >f_shares; (share = *shpp); shpp = >s_next) {
> if (share->s_host == host && nlm_cmp_owner(share, oh)) {
> *shpp = share->s_next;
> kfree(share);
>
I particularly disagree with this change as it now looked like it
could be an '==' comparison that was mistyped. Making it
; (share = *shpp) != NULL;
makes the intent clear.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] - [9/15] - remove defconfig ptr comparisons to 0 - fs/nfsd
On Tuesday November 13, [EMAIL PROTECTED] wrote:
> Remove defconfig ptr comparison to 0
>
> Remove sparse warning: Using plain integer as NULL pointer
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> ---
>
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index d019918..07b38cf 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -987,7 +987,7 @@ nfsd_vfs_write(struct svc_rqst *rqstp, struct svc_fh
> *fhp, struct file *file,
>* flushing the data to disk is handled separately below.
>*/
>
> - if (file->f_op->fsync == 0) {/* COMMIT3 cannot work */
> + if (!file->f_op->fsync) {/* COMMIT3 cannot work */
> stable = 2;
> *stablep = 2; /* FILE_SYNC */
> }
>
Personally, I would much rather these were changed to "== NULL".
Different people have different preferences on whether to use
! foo
or
foo == NULL
and the person who wrote that code is presumably showing a preference
for the later. Changing it from "== 0" to "== NULL" is clearly a
valuable improvement. Changing from "== 0" to "! " is a stylistic
change that should not be made lightly.
I personally often use and prefer the explicit comparison to NULL.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
On Tue, Nov 13, 2007 at 05:52:08PM -0800, David Miller wrote: > Yes, I've run into similar problems with lockdep as well. > I had to build an ultra minimalized kernel to get it to > boot on my Niagara boxes. > > I think I even looked at the same lockdep code, and I'd > appreciate it if you'd submit your fix for this if you > haven't already. ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/early-reserve ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/early-alloc ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/lockdep-early-alloc I didn't plan to submit it for .24, just .25. Or do you need it urgently? Also it would require you to write a sparc specific arch_early_alloc() of course. I've only done the x86-64 version. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [GIT PATCH] hwmon updates against v2.6.24-rc2
Jean: > On Tue, 13 Nov 2007 08:12:10 -0500, Mark M. Hoffman wrote: > > Hi Linus: > > > > Please pull from: > > git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release > > > > You'll get one new driver, a few cleanups, and a few bugfixes. This > > takes care of all known regressions; hopefully it's the last you hear > > from me before 2.6.24-final. > > > > Note: the f75375s/n2100 patches especially are critical to avoid > > possible overheating problems on that platform (yay crappy BIOS). > > > > All of these patches have spent considerable time in -mm. * Jean Delvare <[EMAIL PROTECTED]> [2007-11-13 22:00:30 +0100]: > Let me have a doubt, considering that the last public -mm kernel was > released over a month ago (October 12th), which is before your previous > pull request (October 14th). I don't think that any of these patches > has been in even one public -mm tree, so in practice they probably > didn't receive any public testing at all. Well, zero is a "considerable" number. ;) Seriously though, my bad. In my (weak) defense, I will point out that all but a couple of these patches were *available* for -mm on my testing branch for at least two weeks; Oct 28 was the most recent addition. > Now let's hope that nothing breaks. I admit: post-rc2 was later than it should have been for some of this. But there was no rocket science in any of these. I think we'll be OK. Regards, -- Mark M. Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 17:55:51 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > I've created [EMAIL PROTECTED] Let me just say - I'm astonished at how little spam gets though the vger lists. Considering how many times those email addresses must have been added to spam databases. It must be a lot of work, and whoever is doing it does it well. I don't even know. Is it Matti? You? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] - [2/15] - remove defconfig ptr comparisons to 0 - drivers/net
On Tue, 2007-11-13 at 18:04 -0800, Joe Perches wrote: > Remove defconfig ptr comparison to 0 > > Remove sparse warning: Using plain integer as NULL pointer > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > Acked-by: Michael Chan <[EMAIL PROTECTED]> Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 17:11:36 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: > On Tue, 13 Nov 2007 19:52:17 -0500 > Chuck Ebbert <[EMAIL PROTECTED]> wrote: > > > On 11/13/2007 04:12 PM, Alan Cox wrote: > > >> Bug fixing is not about finding someone to blame, it's about getting the > > >> bug fixed. > > > > > > Partly - its also about understanding why the bug occurred and making it > > > not happen again. > > > > Very few people think about that part. > > Why does the kernel have very few useful tests? Tests would of course be nice, but they aren't very useful(!) Looking at this list which Natalie has generated I see around thirty which are dependent on the right hardware and ten which are not. This ratio is typical, I think. In fact I'd say that more than 75% of reported bugs are dependent on hardware. So the best test of all for the kernel is "run it on a different machine". This is why we are so dependent upon our volunteer testers/reporters to be able to do kernel development. > Lack of interest? resources? expertise? > Ideally each new feature would just be a small add on to an existing test. Sure. For system-call-visible features it would be good to do that. But this tends not to be where bugs get exposed. Because the original developer can 100% exercise such code. That isn't the case with driver/arch/platform changes. > Unlike developing new features which seems to grow well with more developers. > Bug fixing also seems to be a scarcity process. There often seems to be > a very few people that understand the problem well enough or have the > necessary > hardware to reproduce and fix the problem. We're 100% dead if "having the hardware" is a prerequisite to fixing a bug. The terminal state there is that the kernel runs on about 200 machines worldwide. We have to work with reporters via email to fix these sorts of things. As we of course do. > Recent changes like tickless and scheduler rework were well thought out and > caused > very little impact to 90% of the users. The problem is the 10% who do have > problems. > Worse, the developers often only hear about the a small sample of those. Yes. An unknown number of people just shrug and go back to an old kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-11-13-04-14.tar.gz uploaded
On November 13, 2007 08:15:41 am [EMAIL PROTECTED] wrote: > The mm snapshot broken-out-2007-11-13-04-14.tar.gz has been uploaded to > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-11-13- >04-14.tar.gz > > It contains the following patches against 2.6.24-rc2: > How exactly do I go about trying out this snapshot? I did the following: - exported 2.6.24-rc2 from my cloned git tree to a separate folder - installed quilt - extracted the patches to the "patches" directory at the top level of the 2.6.24-rc2 tree - copied the list of patches from your mail into a "series" file which I placed in the "patches" directory - ran "quilt push -a" The result was that all of the patches seem to have been applied, but there were many offsets and at least one fuzzed patch. Should they have applied cleanly? Is quilt the way I am supposed to be applying these patches? Is there a reason that there is no "series" file in the archive with the patches? Slightly confused, -- Kevin Winchester - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [perfmon] Re: [perfmon2] perfmon2 merge news
[dropped all these bouncing email lists. Adding closed lists to public
cc lists is just a bad idea]
> int
> main(int argc, char **argv)
> {
> int ctx_fd;
> pfarg_pmd_t pd[1];
> pfarg_pmc_t pc[1];
> pfarg_ctx_t ctx;
> pfarg_load_t load_args;
>
> memset(, 0, sizeof(ctx));
> memset(pc, 0, sizeof(pc));
> memset(pd, 0, sizeof(pd));
>
> /* create session (context) and get file descriptor back (identifier) */
> ctx_fd = pfm_create_context(, NULL, NULL, 0);
There's nothing in your example that makes the file descriptor needed.
>
> /* setup one config register (PMC0) */
> pc[0].reg_num = 0
> pc[0].reg_value = 0x1234;
That would be nicer if it was just two arguments.
>
> /* setup one data register (PMD0) */
> pd[0].reg_num = 0;
> pd[0].reg_value = 0;
Why do you need to set the data register? Wouldn't it make
more sense to let the kernel handle that and just return one.
>
> /* program the registers */
> pfm_write_pmcs(ctx_fd, pc, 1);
> pfm_write_pmds(ctx_fd, pd, 1);
>
> /* attach the context to self */
> load_args.load_pid = getpid();
> pfm_load_context(ctx_fd, _args);
My replacement would be to just add a flags argument to write_pmcs
with one flag bit meaning "GLOBAL CONTEXT" versus "MY CONTEXT"
>
> /* activate monitoring */
> pfm_start(ctx_fd, NULL);
Why can't that be done by the call setting up the register?
Or if someone needs to do it for a specific region they can read
the register before and then afterwards.
>
> /*
>* run code to measure
>*/
>
> /* stop monitoring */
> pfm_stop(ctx_fd);
>
> /* read data register */
> pfm_read_pmds(ctx_fd, pd, 1);
On x86 i think it would be much simpler to just let the set/alloc
register call return a number and then use RDPMC directly. That would
be actually faster and be much simpler too.
I suppose most architectures have similar facilities, if not a call could be
added for them but it's not really essential. The call might be also needed
for event multiplexing, but frankly I would just leave that out for now.
e.g. here is one use case I would personally see as useful. We need
a replacement for simple cycle counting since RDTSC doesn't do that anymore
on modern x86 CPUs. It could be something like:
/* 0 is the initial value */
/* could be either library or syscall */
event = get_event(COUNTER_CYCLES);
if (event < 0)
/* CPU has no cycle counter */
reg = setup_perfctr(event, 0 /* value */, LOCAL_EVENT); /* syscall */
rdpmc(reg, start);
some code to run ...
rdpmc(reg, end);
free_perfctr(reg); /* syscall */
On other architectures rdpmc would be different of course, but
the rest could be probably similar.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
