Re: [ck] 2.6.12-ck5
Thanks Con, my K3B is working again. Charles -- We are Pentium of Borg. Division is futile. You will be approximated. (seen in someone's .signature) pgpVLXNQyE4a0.pgp Description: PGP signature
[ANNOUNCE] Interbench 0.28
Interbench is a benchmark application is designed to benchmark interactivity in Linux. Direct download link: http://ck.kolivas.org/apps/interbench/interbench-0.28.tar.bz2 Web page: http://interbench.kolivas.org Release early, release often they say... Changes: Yet more floating point fixes mostly coutesy of Peter Williams - Thanks! Cheers, Con pgpfx5Az4ExI0.pgp Description: PGP signature
Re: [openib-general] Re: mthca and LinuxBIOS
On Fri, Aug 05, 2005 at 04:03:00PM -0700, Greg KH wrote: ... > > yesterday, someone add pci_restore_bars, that will call > > pci_update_resource, and it will overwirte upper 32 bit of BAR2 and > > BAR4 of IB card. > > Hm, perhaps that change should not do this? > > Dominik, care to weigh in here? That was your patch... Was the origin of this patch the following thread started by John Linville: http://lkml.org/lkml/2005/6/23/257 I pointed out it would have issues with 64-bit BARs. And I suggested some solutions to JohnL's patch here: http://lkml.org/lkml/2005/7/2/14 In any case same issues apply to pci_update_resource(). 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: About Linux Device Drivers
Alejandro Cabrera wrote: Hi I'm new in the list and I'm interested in lkm, I have the Linux Device Drivers 2ed. And I use the 2.6.8-2 kernel, and the modules that I create I don't test in my workstation. Exist any way to run the examples exposed in this book over my kernel or I need the LDD 3ed thx for your patient Alejandro - 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/ The second edition of Linux Device Drivers is specific to 2.4.x (and possibly 2.2.x) kernels. The third edition will work with the 2.6 kernel. Luckily it is also released under Creative Commons. Take a look at the PDFs here: http://lwn.net/Kernel/LDD3/ Enjoy! Nick Sillik [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: [linux-pm] [PATCH] Workqueue freezer support.
On Fri, 5 Aug 2005, Nigel Cunningham wrote:
> Hi.
>
> I finally found some time to finish this off. I don't really like the
> end result - the macros looked clearer to me - but here goes. If it
> looks okay, I'll seek sign offs from each of the affected driver
> maintainers and from Ingo. Anyone else?
What are your feelings about this: http://lwn.net/Articles/145417/ ?
It seems like a cleaner way to do things. How would these patches change
if that were merged?
Concerning the patch specifically:
> diff -ruNp 400-workthreads.patch-old/include/linux/kthread.h
> 400-workthreads.patch-new/include/linux/kthread.h
> --- 400-workthreads.patch-old/include/linux/kthread.h 2004-11-03
> 21:51:12.0 +1100
> +++ 400-workthreads.patch-new/include/linux/kthread.h 2005-08-03
> 11:52:01.0 +1000
> @@ -23,10 +23,20 @@
> *
> * Returns a task_struct or ERR_PTR(-ENOMEM).
> */
> +struct task_struct *__kthread_create(int (*threadfn)(void *data),
> +void *data,
> +unsigned long freezer_flags,
> +const char namefmt[],
> +va_list * args);
> +
When comparing this to this:
> diff -ruNp 400-workthreads.patch-old/include/linux/workqueue.h
> 400-workthreads.patch-new/include/linux/workqueue.h
> --- 400-workthreads.patch-old/include/linux/workqueue.h 2005-06-20
> 11:47:30.0 +1000
> +++ 400-workthreads.patch-new/include/linux/workqueue.h 2005-08-03
> 11:49:34.0 +1000
> @@ -51,9 +51,12 @@ struct work_struct {
> } while (0)
>
> extern struct workqueue_struct *__create_workqueue(const char *name,
> - int singlethread);
> -#define create_workqueue(name) __create_workqueue((name), 0)
> -#define create_singlethread_workqueue(name) __create_workqueue((name), 1)
> + int singlethread,
> + unsigned long freezer_flag);
> +#define create_workqueue(name) __create_workqueue((name), 0, 0)
> +#define create_nofreeze_workqueue(name) __create_workqueue((name), 0,
> PF_NOFREEZE)
> +#define create_singlethread_workqueue(name) __create_workqueue((name), 1, 0)
> +#define create_nofreeze_singlethread_workqueue(name)
> __create_workqueue((name), 1, PF_NOFREEZE)
And to this:
> static struct task_struct *create_workqueue_thread(struct workqueue_struct
> *wq,
> -int cpu)
> +int cpu,
> +unsigned long freezer_flags)
> {
There is a slight discrepancy in the API changes. Obviously, we don't want
to change every caller of create_workqueue() to support this. But, perhaps
you could standardize the handling of the freezer flags (by e.g. creating
a separate _nofreeze version for each).
Also, functions that take a va_list parameter pass the structure (array)
rather than the pointer. See the definition of vprintk() in
include/linux/kernel.h for an example.
Thanks,
Pat
-
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: [ck] [ANNOUNCE] Interbench 0.27
On Sat, 6 Aug 2005 13:37, Gabriel Devenyi wrote: > After conducting some further research I've determined that cool n quiet > has no effect on this "bug" if you can call it that. With the system > running in init 1, and cool n quiet disabled in the bios, a sleep(N>0) > results in the run_time value afterwards always being nearly the same value > of ~995000 on my athlon64, similarly, my server an athlon-tbird, which > definitely has no power saving features, hovers at ~1496000 We know that sleep(1) doesn't give us accurate sleep of 1 second, only close to it limited by Hz, schedule_timeout and how busy the kernel otherwise is. > Obviously since these values are nowhere near 1, the loops_per_ms > benchmark runs forever, has anyone seen/read about sleep on amd machines > doing something odd? Can anyone else with an amd machine confirm this > behavior? Con: should we attempt to get the attention of LKML to see why > amd chips act differently? None of that matters because the timing is done during a non sleep period using the real time clock: start_time = get_nsecs(); burn_loops(loops); run_time = get_nsecs() - start_time; So the time spent in sleep(1) should be irrelevant to the timing of loops_per_ms. Something else is happening to the cpu _during_ the sleep that makes the next lot of loops take a different length of time. That's the bit I haven't been able to figure out. Cheers, Con - 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 Build Issue for 2.4.31 on Alpha AXP Cabriolet Variant
On Fri, Aug 05, 2005 at 03:38:19PM -0500, [EMAIL PROTECTED] wrote: (...) > Anyhow, a simple one line fix to the arch/alpha/kernel/Makefile solves > this problem (patch file is attached). I've also attached the config file > I used for the build, as well as the boot messages from the kernel built > after the patch was applied. Thanks Bill for the patch, I'll merge it into hotfix 4 which I'll probably release on next week (no urgent fix needed yet). My DS10 (21264) already builds and runs plain 2.4.31 fine, because it does not use ns87312. > And yes, I'm happily writing this email on my ancient Alpha box from > within Mozilla, on a KDE 3.3 desktop, running atop that patched 2.4.31 > kernel. And while this old Alpha may not be the fastest 64-bit computer on > the block, it's still usable! Those boxes are wonderful. Mine serves as a gigabit fileserver at only 466 MHz :-) Thanks, Willy - 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: [openib-general] Re: mthca and LinuxBIOS
On Fri, Aug 05, 2005 at 04:59:37PM -0700, Grant Grundler wrote: > ISTR making comments before about the offending patch on linux-pci mailing > list. Is this the same patch that assumes pci_dev->resource[i] == BAR[i] ? I meant the patch assume 1:1 for pci_dev->resource[i] and BAR[i]. not that the two are equivalent. 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: [PATCH] driver core: Add the ability to unbind drivers to devices from userspace
On 8/5/05, Greg KH <[EMAIL PROTECTED]> wrote: > On Fri, Jul 29, 2005 at 02:50:44PM -0400, Jon Smirl wrote: > > Greg, is this ok for your tree now or does it need more work? > > It's in my queue, will add it to the tree next week. Sorry for the > delay, was at OSCON this week... Glad to see this. After it lands in the tree I'll fix up about ten places where I have attribute processing wrong because of this. Is there some place in the sysfs doc that this can be mentioned? Another thing that should be cleared up is if the attributes are described by length or zero termination. Right now they get both. I suspect the right answer here is supposed to be by length. -- Jon Smirl [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: [ck] [ANNOUNCE] Interbench 0.27
After conducting some further research I've determined that cool n quiet has no effect on this "bug" if you can call it that. With the system running in init 1, and cool n quiet disabled in the bios, a sleep(N>0) results in the run_time value afterwards always being nearly the same value of ~995000 on my athlon64, similarly, my server an athlon-tbird, which definitely has no power saving features, hovers at ~1496000 Obviously since these values are nowhere near 1, the loops_per_ms benchmark runs forever, has anyone seen/read about sleep on amd machines doing something odd? Can anyone else with an amd machine confirm this behavior? Con: should we attempt to get the attention of LKML to see why amd chips act differently? -- Gabriel Devenyi [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: [PATCH] 6700/6702PXH quirk
On Fri, Aug 05, 2005 at 03:57:12PM -0700, Greg KH wrote: > Anyway, Jeff is right, add another bit field. The updated patch, which adds a new bitfield, looks OK to me. However... FWIW, compilers generate AWFUL code for bitfields. Bitfields are really tough to do optimally, whereas bit flags ["unsigned int flags & bitmask"] are the familiar ints and longs that the compiler is well tuned to optimize. Additionally, though it is not the case with struct pci_dev, bitfields cause endian headaches (see the LITTLE_ENDIAN_BITFIELD ifdefs). Bit flags are -far- superior in every case. Avoid bitfields like the plague. I wouldn't mind seeing a janitor remove all bitfields from struct pci_dev, and any other kernel structure that uses the evil constructs. Jeff - 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.12-ck5
On Sat, 2005-08-06 at 12:47 +1000, Con Kolivas wrote: > SCHED_ISO was dropped entirely. It broke in ck4, and there is now a > decent defacto standard for unprivileged realtime in mainline kernel > with realtime RLIMITS so I'm supporting the use of that instead. Too bad, this was a nice feature, but it seems like a hard problem (even OSX does not really do isochronous scheduling despite when the developer guides say). It would be good to revisit this for 2.7. Lee - 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: About Linux Device Drivers
On 8/6/05, D. ShadowWolf <[EMAIL PROTECTED]> wrote: > > On Fri, 2005-08-05 at 22:18 +0200, Alejandro Cabrera wrote: > > > Hi > > > I'm new in the list and I'm interested in lkm, I have the Linux Device > > > Drivers 2ed. And I use the 2.6.8-2 kernel, and the modules that I create > > > I don't test in my workstation. Exist any way to run the examples > > > exposed in this book over my kernel or I need the LDD 3ed > > > thx for your patient > > > Alejandro > > > > It appears he's interested in writing modules for the Linux Kernel and has > been using the book 'Linux Device Drivers, Second Edition' as a reference, > but none of the examples in the book are compiling for him. As he's stated, > he's running kernel 2.6.8-2. > > He wants to know if there is any way to make the examples in that book work or > if he has to go pick up the new version of that book. I've not seen the > books examples myself, and I'm just trying to get up to speed on the kernel > internals myself so I can't answer his question. > > Hope the interpretation of his somewhat broken english helps :) > If ShadowWolf interpretation of Alejandro's question is right and Alejandro trying to run the LDD2 books examples on 2.6.8-2 then they won't work on 2.6.x kernel or not even compile successfully That LDD2 book is for 2.2 and 2.4 kernel series and LDD3 is for 2.6 series, so go for LDD3 for your 2.6.x kernel .. -- Fawad Lateef - 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/
Inclusion order patch
Excuse me for reposting this. I forgot the subject line. hehe.
This patch lets this header stand alone, since I can never remember
which other headers to include, or in which order.
The three #include lines define the types: kobject, list_head and dev_t,
which are used in the cdev structure.
The forward declaration of struct inode is to quiet the following
compiler warning when including only cdev.h in my file:
include/linux/cdev.h:30: warning: `struct inode' declared inside parameter list
include/linux/cdev.h:30: warning: its scope is only this definition or
declaration, which is probably not what you want
I'm not sure, but I think it's saying that I'm declaring a new struct,
which will not be the same as the real struct inode if it is #included
later, because of the scope rules.
(oh yeah, this is my first patch to the list; did I get the format
right?)
BEGIN PATCH:
diff -Nru linux-2.6.12.4/include/linux/cdev.h linux/include/linux/cdev.h
--- linux-2.6.12.4/include/linux/cdev.h 2005-08-05 03:04:37.0
-0400
+++ linux/include/linux/cdev.h 2005-08-05 21:41:39.0 -0400
@@ -2,6 +2,12 @@
#define _LINUX_CDEV_H
#ifdef __KERNEL__
+#include
+#include
+#include
+
+struct inode;
+
struct cdev {
struct kobject kobj;
struct module *owner;
--
James C. Georgas <[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/
2.6.12-ck5
These are patches designed to improve system responsiveness and interactivity. It is configurable to any workload but the default ck* patch is aimed at the desktop and ck*-server is available with more emphasis on serverspace. Apply to 2.6.12 (This includes all patches in 2.6.12.4): http://ck.kolivas.org/patches/2.6/2.6.12/2.6.12-ck5/patch-2.6.12-ck5.bz2 or for server version: http://ck.kolivas.org/patches/2.6/2.6.12/2.6.12-ck5/patch-2.6.12-ck5-server.bz2 web: http://kernel.kolivas.org all patches: http://ck.kolivas.org/patches/ Split patches available. Changes since 2.6.12-ck4: -schedbatch2.8.diff +schedbatch2.9.diff A rare stall on hyperthreading was addressed and now batch tasks suspend properly. -schediso2.12.diff SCHED_ISO was dropped entirely. It broke in ck4, and there is now a decent defacto standard for unprivileged realtime in mainline kernel with realtime RLIMITS so I'm supporting the use of that instead. -isobatch_ionice2.diff +batch_ionice.diff Remove check for SCHED_ISO -HZ-864.diff It seems there were far more areas of the kernel not ready for this Hz value than I could have anticipated much to my dismay even though all code should be written in a HZ neutral fashion. Return normal -ck to HZ=1000 and change ck-server to HZ=100. -patch-2.6.12.3 +patch-2.6.12.4.bz2 Latest stable series -2612ck4-version.diff +2612ck5-version.diff Version update. Cheers, Con pgppXckBphKOD.pgp Description: PGP signature
Re: mthca and LinuxBIOS
I remember last year when I used IBGOLD 0.5 with PCI-X IB card, it seems that it could support 64 bit pref mem. I will try IBGOLD 1.7 . YH On 8/5/05, Roland Dreier <[EMAIL PROTECTED]> wrote: >yhlu> Roland, what is the -16 mean? > >yhlu> is it /* Attempt to modify a QP/EE which is not in the >yhlu> presumed state: */ MTHCA_CMD_STAT_BAD_QPEE_STATE = 0x10, > > No, -16 is just -EBUSY. You could put a printk in event_timeout() in > mthca_cmd.c to make sure, but I'm pretty sure that's where it's coming > from. In other words we issue the CONF_SPECIAL_QP firmware command > and don't ever get a response back from the HCA. > > - R. > - 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: About Linux Device Drivers
On Friday 05 August 2005 22:26, Alejandro Bonilla Beeche wrote: > On Fri, 2005-08-05 at 22:18 +0200, Alejandro Cabrera wrote: > > Hi > > I'm new in the list and I'm interested in lkm, I have the Linux Device > > Drivers 2ed. And I use the 2.6.8-2 kernel, and the modules that I create > > I don't test in my workstation. Exist any way to run the examples > > exposed in this book over my kernel or I need the LDD 3ed > > thx for your patient > > Alejandro > > Alejandro, > > I don't understand anything. What is the problem that you are > experiencing, or is this some type of question? > > If this is a question with your distribution, please contact the best > mailing list that applies for your problem with the Distribution. It appears he's interested in writing modules for the Linux Kernel and has been using the book 'Linux Device Drivers, Second Edition' as a reference, but none of the examples in the book are compiling for him. As he's stated, he's running kernel 2.6.8-2. He wants to know if there is any way to make the examples in that book work or if he has to go pick up the new version of that book. I've not seen the books examples myself, and I'm just trying to get up to speed on the kernel internals myself so I can't answer his question. Hope the interpretation of his somewhat broken english helps :) DRH 0xA6992F96300F159086FF28208F8280BB8B00C32A.asc Description: application/pgp-keys pgpykx6YvFMpB.pgp Description: PGP signature
[no subject]
This patch lets this header stand alone, since I can never remember
which other headers to include, or in which order.
The three #include lines define the types: kobject, list_head and dev_t,
which are used in the cdev structure.
The forward declaration of struct inode is to quiet the following
compiler warning when including only cdev.h in my file:
include/linux/cdev.h:30: warning: its scope is only this definition or
declaration, which is probably not what you want
I'm not sure, but I think it's saying that I'm declaring a new struct,
which will not be the same as the real struct inode if it is #included
later, because of the scope rules.
(oh yeah, this is my first patch to the list; did I get the format
right?)
BEGIN PATCH:
diff -Nru linux-2.6.12.4/include/linux/cdev.h linux/include/linux/cdev.h
--- linux-2.6.12.4/include/linux/cdev.h 2005-08-05 03:04:37.0
-0400
+++ linux/include/linux/cdev.h 2005-08-05 21:41:39.0 -0400
@@ -2,6 +2,12 @@
#define _LINUX_CDEV_H
#ifdef __KERNEL__
+#include
+#include
+#include
+
+struct inode;
+
struct cdev {
struct kobject kobj;
struct module *owner;
--
James C. Georgas <[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: [PATCH] netpoll can lock up on low memory.
On Fri, 2005-08-05 at 18:53 -0700, Matt Mackall wrote: > On Fri, Aug 05, 2005 at 08:23:55PM -0400, Steven Rostedt wrote: [...] > > If you need to really get the data out, then the design should be > > changed. Have some return value showing the failure, check for > > oops_in_progress or whatever, and try again after turning interrupts > > back on, and getting to a point where the system can free up memory > > (write to swap, etc). Just a busy loop without ever getting a skb is > > just bad. > > Why, pray tell, do you think there will be a second chance after > re-enabling interrupts? How does this work when we're panicking or > oopsing where we most care? How does this work when the netpoll client > is the kernel debugger and the machine is completely stopped because > we're tracing it? What I meant was to check for an oops and maybe then don't break out. Otherwise let the system try to reclaim memory. Since this is locked when the alloc_skb called with GFP_ATOMIC and fails. > > As for busy loops, let me direct you to the "poll" part of the name. > It is in fact the whole point. In the kernel I would think that a poll would probe for an event and let the system continue if the event hasn't arrived. Not block all activities until an event has arrived. > > > > > So even a long timeout would not do? So you don't even get a message to > > > > the console? > > > > > > In general, there's no way to measure time here. And if we're > > > using netconsole, what makes you think there's any other console? > > > > Why assume that there isn't another console? The screen may be used > > with netconsole, you just lose whatever has been scrolled too far. > > Yes, there may be another console, but we should by no means depend on > that being the case. We should in fact assume it's not. > > > > > > > Also, as Andi told me, the printk here would probably not show up > > > > > > anyway if this happens with netconsole. > > > > > > > > > > That's fine. But in fact, it does show up occassionally - I've seen > > > > > it. > > > > > > > > Then maybe what Andi told me is not true ;-) > > > > > > > > Oh, and did your machine crash when you saw it? Have you seen it with > > > > the e1000 driver? > > > > > > No and no. Most of my own testing is done with tg3. > > > > > > > If you saw the message and the system didn't crash, then that's proof > > that if the driver is not working properly, you would have lock up the > > system, and the system was _not_ in a state that it _had_ to get the > > message out. > > Let me be more precise. I've seen it in the middle of an oops dump, > where it complained, then made further progress, and then died. In > other words, the code works. And I've since upped the pool size. OK, this is more clear than what you said previously. When I asked if the system crashed, I should have asked if the system was crashing. I thought that you meant that you saw this in normal activity with no oops. So, if anything, this discussion has pointed out that the e1000 has a problem with its netpoll. I wrote an earlier patch, but since I don't own a e1000, someone will need to test it, or at least check to see if it looks OK. -- Steve - 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: About Linux Device Drivers
On Fri, 2005-08-05 at 22:18 +0200, Alejandro Cabrera wrote: > Hi > I'm new in the list and I'm interested in lkm, I have the Linux Device > Drivers 2ed. And I use the 2.6.8-2 kernel, and the modules that I create > I don't test in my workstation. Exist any way to run the examples > exposed in this book over my kernel or I need the LDD 3ed > thx for your patient > Alejandro Alejandro, I don't understand anything. What is the problem that you are experiencing, or is this some type of question? If this is a question with your distribution, please contact the best mailing list that applies for your problem with the Distribution. .Alejandro - 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: assertion (cnt <= tp->packets_out) failed
On Fri, Aug 05, 2005 at 09:32:08AM -0700, David S. Miller wrote:
>
> It therefore may be desirable to keep Herbert's fix in there, but
> back out my changes until they can be reimplemented correctly.
>
> Herbert?
Sure. Let's back it out until a better solution is found.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] s390: fix invalid kmalloc flags
Benjamin LaHaise <[EMAIL PROTECTED]> wrote: > > On Fri, Aug 05, 2005 at 05:36:29PM -0700, Andrew Morton wrote: > > No, GFP_DMA should work OK. Except GFP_DMA doesn't have __GFP_VALID set. > > It's strange that this didn't get noticed earlier. > > > > Ben, was there a reason for not giving GFP_DMA the treatment? > > Not really. Traditionally GFP_DMA was always mixed in with GFP_KERNEL or > GFP_ATOMIC. It seems that GFP_DMA wasn't in the hunk of defines that all > the other kernel flags were in, so if GFP_DMA is really valid all by itself, > adding in the __GFP_VALID should be okay. > OK, it seems that pretty much all callers do remember to add GFP_KERNEL so I guess we can treat this as a bug-which-ben's-patch-found and merge Benoit's fix. - 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] s390: fix invalid kmalloc flags
On Fri, Aug 05, 2005 at 05:36:29PM -0700, Andrew Morton wrote: > No, GFP_DMA should work OK. Except GFP_DMA doesn't have __GFP_VALID set. > It's strange that this didn't get noticed earlier. > > Ben, was there a reason for not giving GFP_DMA the treatment? Not really. Traditionally GFP_DMA was always mixed in with GFP_KERNEL or GFP_ATOMIC. It seems that GFP_DMA wasn't in the hunk of defines that all the other kernel flags were in, so if GFP_DMA is really valid all by itself, adding in the __GFP_VALID should be okay. -ben -- "Time is what keeps everything from happening all at once." -- John Wheeler - 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/1] i386 Encapsulate copying of pgd entries
Chris Wright wrote: * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: + memset(pgd, 0, USER_PTRS_PER_PGD*sizeof(pgd_t)); if (PTRS_PER_PMD == 1) spin_lock_irqsave(_lock, flags); - memcpy((pgd_t *)pgd + USER_PTRS_PER_PGD, + clone_pgd_range((pgd_t *)pgd + USER_PTRS_PER_PGD, swapper_pg_dir + USER_PTRS_PER_PGD, - (PTRS_PER_PGD - USER_PTRS_PER_PGD) * sizeof(pgd_t)); - + KERNEL_PGD_PTRS); if (PTRS_PER_PMD > 1) return; pgd_list_add(pgd); spin_unlock_irqrestore(_lock, flags); - memset(pgd, 0, USER_PTRS_PER_PGD*sizeof(pgd_t)); Why memset was never done on PAE? That's a good point. The memset() is redundant on PAE, since it allocates all 4 PMDs immediately after that (in pgd_alloc). There are two reasons for moving the memset() - one is that it can potentially perform useful work ahead of the lock and effectively act as a prefetch. The second is that at least on a hypervisor, clone_pgd_range() is likely to be taken as a page allocation hint, and thus moving the memset() before this operation allows only the actually present page directory entry updates to be passed to the hypervisor. Actually, the memset() could be redundant on non-PAE as well, since we should have gone through free_pgtables, which would have done a pmd_clear() on each user level pmd, and the kernel level pmds are copied in again inside the lock. I'll try it out to see if this is possible. Zach - 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] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 08:23:55PM -0400, Steven Rostedt wrote: > On Fri, 2005-08-05 at 14:28 -0700, Matt Mackall wrote: > > > > Netpoll generally must assume it won't get a second chance, as it's > > being called by things like oops() and panic() and used by things like > > kgdb. If netpoll fails, the box is dead anyway. > > But it is also being called by every printk in the kernel. What happens > when the printk that causes this lock up is not a panic but just some > info print. One would use netconsole when they turn on more verbose > printing, to keep the output fast, right? So if the system gets a > little memory tight, but not to the point of failing, this will cause a > lock up and no one would know why. This doesn't happen, or if it does, it happens far less often than genuine crashes. This can only happen when netpoll's burned through its entire pool of SKBs in a single interrupt and the card never releases them, despite repeated prodding. In other words, you'll get most of a dump out of the box, but you're probably screwed no matter what you do. Also note that _any_ printk can be the kernel's dying breath. This is why for both serial and video we do polled I/O to be sure we actually get our message out. Netconsole is no different. > If you need to really get the data out, then the design should be > changed. Have some return value showing the failure, check for > oops_in_progress or whatever, and try again after turning interrupts > back on, and getting to a point where the system can free up memory > (write to swap, etc). Just a busy loop without ever getting a skb is > just bad. Why, pray tell, do you think there will be a second chance after re-enabling interrupts? How does this work when we're panicking or oopsing where we most care? How does this work when the netpoll client is the kernel debugger and the machine is completely stopped because we're tracing it? As for busy loops, let me direct you to the "poll" part of the name. It is in fact the whole point. > > > So even a long timeout would not do? So you don't even get a message to > > > the console? > > > > In general, there's no way to measure time here. And if we're > > using netconsole, what makes you think there's any other console? > > Why assume that there isn't another console? The screen may be used > with netconsole, you just lose whatever has been scrolled too far. Yes, there may be another console, but we should by no means depend on that being the case. We should in fact assume it's not. > > > > > Also, as Andi told me, the printk here would probably not show up > > > > > anyway if this happens with netconsole. > > > > > > > > That's fine. But in fact, it does show up occassionally - I've seen > > > > it. > > > > > > Then maybe what Andi told me is not true ;-) > > > > > > Oh, and did your machine crash when you saw it? Have you seen it with > > > the e1000 driver? > > > > No and no. Most of my own testing is done with tg3. > > > > If you saw the message and the system didn't crash, then that's proof > that if the driver is not working properly, you would have lock up the > system, and the system was _not_ in a state that it _had_ to get the > message out. Let me be more precise. I've seen it in the middle of an oops dump, where it complained, then made further progress, and then died. In other words, the code works. And I've since upped the pool size. -- Mathematics is the supreme nostalgia of our time. - 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: lockups with netconsole on e1000 on media insertion
On Saturday 06 August 2005 11:22, Matt Mackall wrote: > On Sat, Aug 06, 2005 at 01:51:22AM +0200, Andi Kleen wrote: > > > But why are we in a hurry to dump the backlog on the floor? Why are we > > > worrying about the performance of netpoll without the cable plugged in > > > at all? We shouldn't be optimizing the data loss case. > > > > Because a system shouldn't stall for minutes (or forever like right now) > > at boot just because the network cable isn't plugged in. > > Using netconsole without a network cable could well be classified as a > serious configuration error. But please don't. An OS that slows to a crawl or crashes because a cable isn't plugged in an OS that deserves to be ridiculed. Silly timeouts on boot are scary and a waste of user's time. Regards, Daniel - 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: mthca and LinuxBIOS
yhlu> Roland, what is the -16 mean? yhlu> is it /* Attempt to modify a QP/EE which is not in the yhlu> presumed state: */ MTHCA_CMD_STAT_BAD_QPEE_STATE = 0x10, No, -16 is just -EBUSY. You could put a printk in event_timeout() in mthca_cmd.c to make sure, but I'm pretty sure that's where it's coming from. In other words we issue the CONF_SPECIAL_QP firmware command and don't ever get a response back from the HCA. - R. - 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: lockups with netconsole on e1000 on media insertion
On Sat, Aug 06, 2005 at 01:51:22AM +0200, Andi Kleen wrote: > > But why are we in a hurry to dump the backlog on the floor? Why are we > > worrying about the performance of netpoll without the cable plugged in > > at all? We shouldn't be optimizing the data loss case. > > Because a system shouldn't stall for minutes (or forever like right now) > at boot just because the network cable isn't plugged in. Using netconsole without a network cable could well be classified as a serious configuration error. NFS also is a bit sluggish without a network cable. I've already agreed that forever is a problem. Can we work towards agreeing on a non-trivial timeout, please? -- Mathematics is the supreme nostalgia of our time. - 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] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 11:51:18PM +0200, Andi Kleen wrote: > > > If that was the policy it would be a quite dumb one and make netpoll > > > totally unsuitable for production use. I hope it is not. > > > > Suggest you rip __GFP_NOFAIL out of JBD before complaining about this. > > So you're suggesting we should become as bad at handling networking > errors as we are at handling IO errors? No, I'm suggesting that the machine will hang forever sometimes and no amount of patching up netpoll or JBD, etc. will fix that. A hardware watchdog is a requirement for robust failover anyway and if you think otherwise, you're dreaming. And for reference, both are examples of theoretical should-never-happen memory allocation failures. > > > Dave, can you please apply the timeout patch anyways? > > > > Yes, let's go right over the maintainer's objections almost > > immediately after he chimes into the thread. I'll spare the list the > > colorful language this inspires. > > Sure when the maintainer has a unreasonable position on something > I think that's justified. Yours in this case is clearly unreasonable. What's clear is that you didn't like my position from my very first post in this thread and immediately went for the nuclear option without even trying to discuss it. Are you even aware that the patch we're discussing here is for a problem that has yet to be observed and that Steven's initial analysis had missed a couple things? -- Mathematics is the supreme nostalgia of our time. - 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/1] i386 Encapsulate copying of pgd entries
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: > + memset(pgd, 0, USER_PTRS_PER_PGD*sizeof(pgd_t)); > if (PTRS_PER_PMD == 1) > spin_lock_irqsave(_lock, flags); > > - memcpy((pgd_t *)pgd + USER_PTRS_PER_PGD, > + clone_pgd_range((pgd_t *)pgd + USER_PTRS_PER_PGD, > swapper_pg_dir + USER_PTRS_PER_PGD, > - (PTRS_PER_PGD - USER_PTRS_PER_PGD) * sizeof(pgd_t)); > - > + KERNEL_PGD_PTRS); > if (PTRS_PER_PMD > 1) > return; > > pgd_list_add(pgd); > spin_unlock_irqrestore(_lock, flags); > - memset(pgd, 0, USER_PTRS_PER_PGD*sizeof(pgd_t)); Why memset was never done on PAE? thanks, -chris - 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/2] cpqfc: fix for "Using too much stach" in 2.6 kernel
On 8/4/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 8/4/05, Saripalli, Venkata Ramanamurthy (STSD) <[EMAIL PROTECTED]> wrote:
> > Patch 1 of 2
> >
> > This patch fixes the "#error this is too much stack" in 2.6 kernel.
> > Using kmalloc to allocate memory to ulFibreFrame.
> >
> [snip]
> >if( fchs->pl[0] == ELS_LILP_FRAME)
> > {
> > + kfree(ulFibreFrame);
> > return 1; // found the LILP frame!
> > }
> > else
> > {
> > + kfree(ulFibreFrame);
> > // keep looking...
> > }
>
> The first thing you do in either branch is to call
> kfree(ulFibreFrame); , so instead of having the call in both branches
> you might as well just have one call before the if(). Ohh and this
> looks like it could do with a CodingStyle cleanup as well.
>
> kfree(ulFibreFrame);
> if (fchs->pl[0] == ELS_LILP_FRAME)
> return 1; /* found the LILP frame! */
> /* keep looking */
Whoops, as Rolf Eike Beer pointed out to me, I snipped one line too many.
fchs = (TachFCHDR_GCMND*)ulFibreFrame;
So, the kfree inside each branch is correct. Freeing it just before
the if would be wrong.
Sorry about that.
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.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: mthca and LinuxBIOS
Roland, what is the -16 mean? is it /* Attempt to modify a QP/EE which is not in the presumed state: */ MTHCA_CMD_STAT_BAD_QPEE_STATE = 0x10, YH On 8/5/05, yhlu <[EMAIL PROTECTED]> wrote: > You are right. CONG_SPECIAL_QP > > ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005) > ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex > (Tavor compatibility mode) (:04:00.0) > ib_mthca :04:00.0: FW version 000400060002, max commands 64 > ib_mthca :04:00.0: FW size 6143 KB (start fcefa0, end fcefff) > ib_mthca :04:00.0: HCA memory size 262143 KB (start fce000, > end fcefff) > ib_mthca :04:00.0: Max QPs: 16777216, reserved QPs: 1024, entry size: 256 > ib_mthca :04:00.0: Max CQs: 16777216, reserved CQs: 128, entry size: 64 > ib_mthca :04:00.0: Max EQs: 64, reserved EQs: 1, entry size: 64 > ib_mthca :04:00.0: reserved MPTs: 16, reserved MTTs: 16 > ib_mthca :04:00.0: Max PDs: 16777216, reserved PDs: 0, reserved UARs: 1 > ib_mthca :04:00.0: Max QP/MCG: 16777216, reserved MGMs: 0 > ib_mthca :04:00.0: Flags: 00370347 > ib_mthca :04:00.0: profile[ 0]--10/20 @ 0x fce000 (size 0x > 400) > ib_mthca :04:00.0: profile[ 1]-- 0/16 @ 0x fce400 (size 0x > 100) > ib_mthca :04:00.0: profile[ 2]-- 7/18 @ 0x fce500 (size 0x > 80) > ib_mthca :04:00.0: profile[ 3]-- 9/17 @ 0x fce580 (size 0x > 80) > ib_mthca :04:00.0: profile[ 4]-- 3/16 @ 0x fce600 (size 0x > 40) > ib_mthca :04:00.0: profile[ 5]-- 4/16 @ 0x fce640 (size 0x > 20) > ib_mthca :04:00.0: profile[ 6]--12/15 @ 0x fce660 (size 0x > 10) > ib_mthca :04:00.0: profile[ 7]-- 8/13 @ 0x fce670 (size 0x > 8) > ib_mthca :04:00.0: profile[ 8]--11/11 @ 0x fce678 (size 0x > 1) > ib_mthca :04:00.0: profile[ 9]-- 6/ 5 @ 0x fce679 (size 0x > 800) > ib_mthca :04:00.0: HCA memory: allocated 106050 KB/256000 KB > (149950 KB free) > ib_mthca :04:00.0: Allocated EQ 1 with 65536 entries > ib_mthca :04:00.0: Allocated EQ 2 with 128 entries > ib_mthca :04:00.0: Allocated EQ 3 with 128 entries > ib_mthca :04:00.0: Setting mask 000f43fe for eqn 2 > ib_mthca :04:00.0: Setting mask 0400 for eqn 3 > ib_mthca :04:00.0: NOP command IRQ test passed > ib_mthca :04:00.0: mthca_init_qp_table: mthca_CONF_SPECIAL_QP > failed for 0/1024 (-16) > ib_mthca :04:00.0: Failed to initialize queue pair table, aborting. > ib_mthca :04:00.0: Clearing mask 000f43fe for eqn 2 > ib_mthca :04:00.0: Clearing mask 0400 for eqn 3 > ib_mthca: probe of :04:00.0 failed with error -16 > - 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] Re: 2.6.12: itimer_real timers don't survive execve() any more
Roland McGrath wrote: There are other concerns. Let me see if I understand this. A thread (other than the leader) can exec and we then need to change the real_timer to wake the new task which will NOT be using the same task struct. That's correct. de_thread will turn the thread calling exec into the new leader and kill off all the other threads, including the old leader. The exec'ing thread's existing task_struct is reassigned to the PID of the original leader. My looking at the code shows that the thread leader can exit and then stays around as a zombi until the last thread in the group exits. That is correct. If an alarm comes during this wait I suspect it will wake this zombi and cause problems. You are mistaken. The signal code handles process signals sent when the leader is a zombie. The group leader sticks around with the PID that matches the TGID, until there are no live threads with its TGID. That is how process-wide kill can still work. Yes, I see, traced through the signal delivery. So Linus' patch as well as the regression of Ingo's will fix all of this. Right? -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - 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] driver core: Add the ability to unbind drivers to devices from userspace
On Fri, Jul 29, 2005 at 02:50:44PM -0400, Jon Smirl wrote: > Greg, is this ok for your tree now or does it need more work? It's in my queue, will add it to the tree next week. Sorry for the delay, was at OSCON this week... 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] kernel: use kcalloc instead kmalloc/memset
Hi,
On Fri, 5 Aug 2005, Arjan van de Ven wrote:
> Maybe it helps if I give the basic bug scenario first (pseudo C)
>
> void some_ioctl_func(...)
> {
> int count, i;
> struct foo *ptr;
>
> copy_from_user(,...);
>
> ptr = kmalloc(sizeof(struct foo) * count);
>
> if (!ptr)
> return -ENOMEM;
>
> for (i=0; i initialize(ptr+i);
> }
> }
>
>
> if the user picks count such that the multiplication overflows, the
> kmalloc will actually *succeed* in getting a chunk between 0 and 128Kb.
> The subsequent "fill the array up" will overwrite a LOT of kernel memory
> though.
>
> Fixing the hole of course involves checking "count" for too high a
> value. Using kcalloc() will check for this same overflow inside kcalloc
> and prevent it (eg return NULL) if one of these slips through.
What prevents a rogue user to call this function a number of times to
waste resources?
kcalloc() covers only small part of what is needed to make an interface
secure, once one checked everything else, the safety provided by kcalloc()
is pretty much redundant.
Relying on the current allocation limits would be rather foolish as these
can change anytime and hardcoding such assumptions is a really bad idea.
Kernel coding requires a careful use of the memory resource, so it's the
job of the driver to define reasonable limits, e.g. such arrays don't make
much sense if they require too much space and the driver should define a
limit like (PAGESIZE/sizeof(struct foo)). If the driver writer doesn't
think about memory usage, then kcalloc() will do pretty much nothing too
improve the driver, it may avoid a few problem cases, but there will be
certainly more than enough problems left.
I actually looked at the current kcalloc users and besides a few unchecked
module parameters, the arguments were either constant or had to be checked
anyway. I didn't find a single example which required the "safety" of
kcalloc().
bye, Roman
-
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] s390: fix invalid kmalloc flags
[EMAIL PROTECTED] wrote:
>
> The following patch fixes the compilation (defconfig) of s390:
>
> arch/s390/mm/built-in.o(.text+0x152c): In function `query_segment_type':
> extmem.c: undefined reference to `__your_kmalloc_flags_are_not_valid'
> arch/s390/mm/built-in.o(.text+0x19ec): In function `segment_load':
> : undefined reference to `__your_kmalloc_flags_are_not_valid'
>
>
> Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]>
>
> --- a/arch/s390/mm/extmem.c 2005-08-06 01:32:56.0 +0200
> +++ b/arch/s390/mm/extmem.c 2005-07-31 17:46:36.0 +0200
> @@ -172,8 +172,8 @@ dcss_diag_translate_rc (int vm_rc) {
> static int
> query_segment_type (struct dcss_segment *seg)
> {
> -struct qin64 *qin = kmalloc (sizeof(struct qin64), GFP_DMA);
> -struct qout64 *qout = kmalloc (sizeof(struct qout64), GFP_DMA);
> +struct qin64 *qin = kmalloc (sizeof(struct qin64), GFP_DMA|GFP_KERNEL);
> +struct qout64 *qout = kmalloc (sizeof(struct qout64),
> GFP_DMA|GFP_KERNEL);
No, GFP_DMA should work OK. Except GFP_DMA doesn't have __GFP_VALID set.
It's strange that this didn't get noticed earlier.
Ben, was there a reason for not giving GFP_DMA the treatment?
-
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.12 stalls Andrew M. req this extended dmesg dump
On Mon, Aug 01, 2005 at 09:35:25AM -0400, jt wrote: > Greg KH wrote: > > >On Sat, Jul 30, 2005 at 12:52:38PM -0700, Andrew Morton wrote: > > > > > >>udev is doing stuff. > >> > >> > >> > >>>[ 40.691350] c16b1f40 0082 c0115ff9 c1601530 bfd67d94 > >>>c1601530 [ 40.691544]c1384e80 c1384520 > >>>122d 8cc9bc6a 0008 c1601530 c1601020 [ 40.695744] > >>>c1601144 0246 c16010c8 0004 fe00 c1601020 c0121343 > >>>[ 40.699932] Call Trace: > >>>[ 40.708026] [] do_page_fault+0x1a9/0x57a > >>>[ 40.712230] [] do_wait+0x313/0x3a0 > >>>[ 40.716403] [] default_wake_function+0x0/0x10 > >>>[ 40.720663] [] default_wake_function+0x0/0x10 > >>>[ 40.724858] [] sys_wait4+0x29/0x30 > >>>[ 40.729039] [] syscall_call+0x7/0xb > >>>[ 40.733255] udev S 0 1443795 > >>>(NOTLB) > >>> > >>> > >>And it's sleeping for some reason. > >> > >> > > > >Yes, older versions of udev (< 058) can work _really slow_ with 2.6.12. > >Please upgrade your version of udev and see if that solves the issue or > >not. > > > >thanks, > > > >greg k-h > > > > > > > > > Interseting results. > I loaded udev 64 > and hotplug ng 002 Heh, I wouldn't recommend hotplug-ng on anyone, it's out of date, and really not needed at all. How about if you boot with a static /dev? Do you still have boot issues with that? 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] netpoll can lock up on low memory.
On Fri, 2005-08-05 at 23:26 +0200, Andi Kleen wrote: > I suspect Steven's patch for the e1000 is needed in addition to > handle different cases too. > I haven't tested it. Someone with a e1000 must see if it works. I submitted the e100 fix that had the same problem, but I would feel better if the patch I sent for the e1000 actually got tested. To test, one would setup a box with the e1000 and netconsole. Run with something doing several printks (possible using sysrq-t or such), and then unplug the cable (without Andi's patch) and replug it back in. If the patch worked, the system would hang while the cable was detached, but come back shortly after the cable was plugged back in. -- Steve - 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/1] i386 Encapsulate copying of pgd entries
Add a clone operation for pgd updates.
This helps complete the encapsulation of updates to page tables (or pages
about to become page tables) into accessor functions rather than using
memcpy() to duplicate them. This is both generally good for consistency
and also necessary for running in a hypervisor which requires explicit
updates to page table entries.
The new function is:
clone_pgd_range(pgd_t *dst, pgd_t *src, int count);
dst - pointer to pgd range anwhere on a pgd page
src - ""
count - the number of pgds to copy.
dst and src can be on the same page, but the range must not overlap
and must not cross a page boundary.
Note that I ommitted using this call to copy pgd entries into the
software suspend page root, since this is not technically a live paging
structure, rather it is used on resume from suspend. CC'ing Pavel in case
he has any feedback on this.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Index: linux-2.6.13/arch/i386/mm/pgtable.c
===
--- linux-2.6.13.orig/arch/i386/mm/pgtable.c2005-08-04 12:02:10.0
-0700
+++ linux-2.6.13/arch/i386/mm/pgtable.c 2005-08-05 17:13:29.0 -0700
@@ -207,19 +207,18 @@
{
unsigned long flags;
+ memset(pgd, 0, USER_PTRS_PER_PGD*sizeof(pgd_t));
if (PTRS_PER_PMD == 1)
spin_lock_irqsave(_lock, flags);
- memcpy((pgd_t *)pgd + USER_PTRS_PER_PGD,
+ clone_pgd_range((pgd_t *)pgd + USER_PTRS_PER_PGD,
swapper_pg_dir + USER_PTRS_PER_PGD,
- (PTRS_PER_PGD - USER_PTRS_PER_PGD) * sizeof(pgd_t));
-
+ KERNEL_PGD_PTRS);
if (PTRS_PER_PMD > 1)
return;
pgd_list_add(pgd);
spin_unlock_irqrestore(_lock, flags);
- memset(pgd, 0, USER_PTRS_PER_PGD*sizeof(pgd_t));
}
/* never called when PTRS_PER_PMD > 1 */
Index: linux-2.6.13/arch/i386/kernel/smpboot.c
===
--- linux-2.6.13.orig/arch/i386/kernel/smpboot.c2005-08-04
12:02:10.0 -0700
+++ linux-2.6.13/arch/i386/kernel/smpboot.c 2005-08-04 13:15:45.0
-0700
@@ -1017,8 +1017,8 @@
tsc_sync_disabled = 1;
/* init low mem mapping */
- memcpy(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS,
- sizeof(swapper_pg_dir[0]) * KERNEL_PGD_PTRS);
+ clone_pgd_range(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS,
+ KERNEL_PGD_PTRS);
flush_tlb_all();
schedule_work();
wait_for_completion();
Index: linux-2.6.13/include/asm-i386/pgtable.h
===
--- linux-2.6.13.orig/include/asm-i386/pgtable.h2005-08-04
12:02:10.0 -0700
+++ linux-2.6.13/include/asm-i386/pgtable.h 2005-08-05 17:12:33.0
-0700
@@ -276,6 +276,21 @@
}
/*
+ * clone_pgd_range(pgd_t *dst, pgd_t *src, int count);
+ *
+ * dst - pointer to pgd range anwhere on a pgd page
+ * src - ""
+ * count - the number of pgds to copy.
+ *
+ * dst and src can be on the same page, but the range must not overlap,
+ * and must not cross a page boundary.
+ */
+static inline void clone_pgd_range(pgd_t *dst, pgd_t *src, int count)
+{
+ memcpy(dst, src, count * sizeof(pgd_t));
+}
+
+/*
* Macro to mark a page protection value as "uncacheable". On processors
which do not support
* it, this is a no-op.
*/
-
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] s390: fix invalid kmalloc flags
The following patch fixes the compilation (defconfig) of s390:
arch/s390/mm/built-in.o(.text+0x152c): In function `query_segment_type':
extmem.c: undefined reference to `__your_kmalloc_flags_are_not_valid'
arch/s390/mm/built-in.o(.text+0x19ec): In function `segment_load':
: undefined reference to `__your_kmalloc_flags_are_not_valid'
Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]>
--- a/arch/s390/mm/extmem.c 2005-08-06 01:32:56.0 +0200
+++ b/arch/s390/mm/extmem.c 2005-07-31 17:46:36.0 +0200
@@ -172,8 +172,8 @@ dcss_diag_translate_rc (int vm_rc) {
static int
query_segment_type (struct dcss_segment *seg)
{
- struct qin64 *qin = kmalloc (sizeof(struct qin64), GFP_DMA);
- struct qout64 *qout = kmalloc (sizeof(struct qout64), GFP_DMA);
+ struct qin64 *qin = kmalloc (sizeof(struct qin64), GFP_DMA|GFP_KERNEL);
+ struct qout64 *qout = kmalloc (sizeof(struct qout64),
GFP_DMA|GFP_KERNEL);
int diag_cc, rc, i;
unsigned long dummy, vmrc;
@@ -332,7 +332,7 @@ static int
__segment_load (char *name, int do_nonshared, unsigned long *addr, unsigned
long *end)
{
struct dcss_segment *seg = kmalloc(sizeof(struct dcss_segment),
- GFP_DMA);
+ GFP_DMA|GFP_KERNEL);
int dcss_command, rc, diag_cc;
if (seg == NULL) {
-
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] netpoll can lock up on low memory.
On Fri, 2005-08-05 at 14:28 -0700, Matt Mackall wrote: > > Netpoll generally must assume it won't get a second chance, as it's > being called by things like oops() and panic() and used by things like > kgdb. If netpoll fails, the box is dead anyway. > But it is also being called by every printk in the kernel. What happens when the printk that causes this lock up is not a panic but just some info print. One would use netconsole when they turn on more verbose printing, to keep the output fast, right? So if the system gets a little memory tight, but not to the point of failing, this will cause a lock up and no one would know why. If you need to really get the data out, then the design should be changed. Have some return value showing the failure, check for oops_in_progress or whatever, and try again after turning interrupts back on, and getting to a point where the system can free up memory (write to swap, etc). Just a busy loop without ever getting a skb is just bad. > > > The netpoll philosophy is to assume that its traffic is an absolute > > > priority - it is better to potentially hang trying to deliver a panic > > > message than to give up and crash silently. > > > > So even a long timeout would not do? So you don't even get a message to > > the console? > > In general, there's no way to measure time here. And if we're > using netconsole, what makes you think there's any other console? Why assume that there isn't another console? The screen may be used with netconsole, you just lose whatever has been scrolled too far. > > > > > Also, as Andi told me, the printk here would probably not show up > > > > anyway if this happens with netconsole. > > > > > > That's fine. But in fact, it does show up occassionally - I've seen > > > it. > > > > Then maybe what Andi told me is not true ;-) > > > > Oh, and did your machine crash when you saw it? Have you seen it with > > the e1000 driver? > > No and no. Most of my own testing is done with tg3. > If you saw the message and the system didn't crash, then that's proof that if the driver is not working properly, you would have lock up the system, and the system was _not_ in a state that it _had_ to get the message out. -- Steve - 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, experimental] i386 Allow the fixmap to be relocated at boot time
* Zachary Amsden ([EMAIL PROTECTED]) wrote: > Your patch looks good, although the minimal change to subarch is to > merely have __FIXADDR_TOP defined by the sub-architecture. Is there any > additional benefit to moving the fixmaps into the subarch - i.e. moving > subarch-specific pieces out of mach-default? As you've identified, so subarch can put whatever wonky junk it needs in there. > I guess there is. For example include/asm-i386/mach-visws/mach_fixmap.h > could do this: > > #define SUBARCH_FIXMAPS \ >FIX_CO_CPU, /* Cobalt timer */ \ >FIX_CO_APIC,/* Cobalt APIC Redirection Table */ \ >FIX_LI_PCIA,/* Lithium PCI Bridge A */ \ >FIX_LI_PCIB,/* Lithium PCI Bridge B */ > > Then include/asm-i386/fixmap.h includes , for which the > default is an empty define for SUBARCH_FIXMAPS. nice. > Also, it seems reasonable that people may want to poke holes in high > linear space for other hypervisor projects, research, or performance > reasons without having to build a custom sub-architecture just for > that. So I think there is some benefit to making the hole size a > general configurable option (with defaults depending on the sub-arch you > select). It needs to have tangible value for in-tree code. Seems worthwhile to play with it a bit though. thanks, -chris - 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, experimental] i386 Allow the fixmap to be relocated at boot time
Chris Wright wrote: * Zachary Amsden ([EMAIL PROTECTED]) wrote: This most curious patch allows the fixmap on i386 to be unfixed. The result is that we can create a dynamically sizable hole at the top of kernel linear address space. I know at least some virtualization developers are interested in being able to achieve this to achieve run-time sizing of a hole in which a hypervisor can live, or at least to test out the performance characteristics of different sized holes. I've done it simpler with keeping it fixed but defined by the subarch. Patch is stupid simple (and untested). Do you think there's a huge gain for dynamically sizing? Your patch looks good, although the minimal change to subarch is to merely have __FIXADDR_TOP defined by the sub-architecture. Is there any additional benefit to moving the fixmaps into the subarch - i.e. moving subarch-specific pieces out of mach-default? I guess there is. For example include/asm-i386/mach-visws/mach_fixmap.h could do this: #define SUBARCH_FIXMAPS \ FIX_CO_CPU, /* Cobalt timer */ \ FIX_CO_APIC,/* Cobalt APIC Redirection Table */ \ FIX_LI_PCIA,/* Lithium PCI Bridge A */ \ FIX_LI_PCIB,/* Lithium PCI Bridge B */ Then include/asm-i386/fixmap.h includes , for which the default is an empty define for SUBARCH_FIXMAPS. And then you don't have to maintain the list of common fixmaps across the sub-architecture layer or uglify the top level fixmaps with SGI Visual Workstation support. Also, it seems reasonable that people may want to poke holes in high linear space for other hypervisor projects, research, or performance reasons without having to build a custom sub-architecture just for that. So I think there is some benefit to making the hole size a general configurable option (with defaults depending on the sub-arch you select). I have no idea if the dynamic sizing has any performance impact yet, but it may be a big win in terms of flexibility. I would be curious to hear more from the Xen core team (I know Ian mentioned he would like to try this out at one point in time). Zach - 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] fix madvise vma merging
Hugh Dickins wrote: > Better late than never, I've at last reviewed the madvise vma merging > going into 2.6.13. Remove a pointless check and fix two little bugs - > a simple test (with /proc//maps hacked to show ReadHints) showed > both mismerges in practice: though being madvise, neither was disastrous. > > 1. Correct placement of the success label in madvise_behavior: as in >mprotect_fixup and mlock_fixup, it is necessary to update vm_flags >when vma_merge succeeds (to handle the exceptional Case 8 noted in >the comments above vma_merge itself). > > 2. Correct initial value of prev when starting part way into a vma: as >in sys_mprotect and do_mlock, it needs to be set to vma in this case >(vma_merge handles only that minimum of cases shown in its comments). > > 3. If find_vma_prev sets prev, then the vma it returns is prev->vm_next, >so it's pointless to make that same assignment again in sys_madvise. Acknowledge corrections 1 and 3 readily. Treated vma_merge as block box that can handle all cases. Motivation for pointless case 3 is to skip holes and did not notice that has been covered. Thanks for corrections. > (vma_merge handles only that minimum of cases shown in its comments). > Correction 2 is tricky. Sometimes it merges similar to case 3, misses a needed split, where after the fix we can get case 4 merge. If that is what you are saying, we are in agreement. Otherwise, can you explain the real problem? Thanks, Prasanna. - 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: [openib-general] Re: mthca and LinuxBIOS
On Fri, Aug 05, 2005 at 04:06:06PM -0700, Linus Torvalds wrote: > > > On Fri, 5 Aug 2005, Greg KH wrote: > > On Fri, Aug 05, 2005 at 01:38:37PM -0700, Linus Torvalds wrote: > > > > But what's the real problem we are trying to fix here? > > We're screwing up the top 32 bits of the BAR when you resume it. Look at > the patch, you'll see the fix (the other part of the patch looks fine, but > then in order to not overwrite the upper bits with zero again when doing > the _next_ - nonexistent - BAR update, we need to have something that > avoids writing the next BAR). ISTR making comments before about the offending patch on linux-pci mailing list. Is this the same patch that assumes pci_dev->resource[i] == BAR[i] ? That's not true for 64-bit bars. > Remember: a 64-bit BAR puts the upper 32 bits in what would otherwise be > the low 32 bits of the next BAR. Which is why we need to mark the next BAR > resource as _not_ being valid some way - so that we don't try to > (incorrectly) "restore" it and overwrite the high bits of the previous > BAR. > Of course, this only hits the (very few) people who not only have 64-bit > PCI devices, but literally have them mapped in the 4GB+ region. *lots* of PCI device now have 64-bit BAR. The first I'm aware of was LSI 53c896 card (Ultra 2 SCSI). > Quite uncommon. Assigning 4GB+ regions is uncommon because too often either the HW, the OS, or the driver would break. firmware keeps having to worry about legacy OSs. 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: [PATCH] 6700/6702PXH quirk
On Fri, 2005-08-05 at 18:50 -0400, Jeff Garzik wrote:
>
> AFAICS we don't need a new list, simply consisting of PCI devs.
>
> Just invent, and set, a bit somewhere in struct pci_dev.
>
> Jeff
>
>
>
Great! I like that much better. How about this:
On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
driver and SHPC driver in MSI mode are used together. This patch will
prevent MSI from being enabled for the SHPC as part of an early pci
quirk, as well as on any pci device which sets the no_msi bit.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
diff -uprN -X linux-2.6.13-rc4/Documentation/dontdiff
linux-2.6.13-rc4/drivers/pci/msi.c linux-2.6.13-rc4-pxhquirk/drivers/pci/msi.c
--- linux-2.6.13-rc4/drivers/pci/msi.c 2005-07-28 15:44:44.0 -0700
+++ linux-2.6.13-rc4-pxhquirk/drivers/pci/msi.c 2005-08-05 16:35:16.0
-0700
@@ -453,7 +453,7 @@ static void enable_msi_mode(struct pci_d
}
}
-static void disable_msi_mode(struct pci_dev *dev, int pos, int type)
+void disable_msi_mode(struct pci_dev *dev, int pos, int type)
{
u16 control;
@@ -699,6 +699,9 @@ int pci_enable_msi(struct pci_dev* dev)
if (!pci_msi_enable || !dev)
return status;
+ if (dev->no_msi)
+ return status;
+
temp = dev->irq;
if ((status = msi_init()) < 0)
diff -uprN -X linux-2.6.13-rc4/Documentation/dontdiff
linux-2.6.13-rc4/drivers/pci/pci.h linux-2.6.13-rc4-pxhquirk/drivers/pci/pci.h
--- linux-2.6.13-rc4/drivers/pci/pci.h 2005-07-28 15:44:44.0 -0700
+++ linux-2.6.13-rc4-pxhquirk/drivers/pci/pci.h 2005-08-05 16:37:18.0
-0700
@@ -46,7 +46,7 @@ extern int pci_msi_quirk;
#else
#define pci_msi_quirk 0
#endif
-
+void disable_msi_mode(struct pci_dev *dev, int pos, int type);
extern int pcie_mch_quirk;
extern struct device_attribute pci_dev_attrs[];
extern struct class_device_attribute class_device_attr_cpuaffinity;
diff -uprN -X linux-2.6.13-rc4/Documentation/dontdiff
linux-2.6.13-rc4/drivers/pci/quirks.c
linux-2.6.13-rc4-pxhquirk/drivers/pci/quirks.c
--- linux-2.6.13-rc4/drivers/pci/quirks.c 2005-07-28 15:44:44.0
-0700
+++ linux-2.6.13-rc4-pxhquirk/drivers/pci/quirks.c 2005-08-05
16:38:28.0 -0700
@@ -1267,6 +1267,27 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7320_MCH,
quirk_pcie_mch );
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7525_MCH,
quirk_pcie_mch );
+
+/*
+ * It's possible for the MSI to get corrupted if shpc and acpi
+ * are used together on certain PXH-based systems.
+ */
+static void __devinit quirk_pcie_pxh(struct pci_dev *dev)
+{
+ disable_msi_mode(dev, pci_find_capability(dev, PCI_CAP_ID_MSI),
+ PCI_CAP_ID_MSI);
+ dev->no_msi = 1;
+
+ printk(KERN_WARNING "PCI: PXH quirk detected, "
+ "disabling MSI for SHPC device\n");
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXHD_0,
quirk_pcie_pxh);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXHD_1,
quirk_pcie_pxh);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXH_0,
quirk_pcie_pxh);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXH_1,
quirk_pcie_pxh);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXHV,
quirk_pcie_pxh);
+
+
static void __devinit quirk_netmos(struct pci_dev *dev)
{
unsigned int num_parallel = (dev->subsystem_device & 0xf0) >> 4;
diff -uprN -X linux-2.6.13-rc4/Documentation/dontdiff
linux-2.6.13-rc4/include/linux/pci.h
linux-2.6.13-rc4-pxhquirk/include/linux/pci.h
--- linux-2.6.13-rc4/include/linux/pci.h2005-07-28 15:44:44.0
-0700
+++ linux-2.6.13-rc4-pxhquirk/include/linux/pci.h 2005-08-05
16:37:08.0 -0700
@@ -556,6 +556,7 @@ struct pci_dev {
/* keep track of device state */
unsigned intis_enabled:1; /* pci_enable_device has been called */
unsigned intis_busmaster:1; /* device is busmaster */
+ unsigned intno_msi:1; /* device may not use msi */
u32 saved_config_space[16]; /* config space saved at
suspend time */
struct bin_attribute *rom_attr; /* attribute descriptor for sysfs ROM
entry */
diff -uprN -X linux-2.6.13-rc4/Documentation/dontdiff
linux-2.6.13-rc4/include/linux/pci_ids.h
linux-2.6.13-rc4-pxhquirk/include/linux/pci_ids.h
--- linux-2.6.13-rc4/include/linux/pci_ids.h2005-07-28 15:44:44.0
-0700
+++ linux-2.6.13-rc4-pxhquirk/include/linux/pci_ids.h 2005-08-02
13:58:53.0 -0700
@@ -2281,6 +2281,11 @@
#define PCI_VENDOR_ID_INTEL0x8086
#define PCI_DEVICE_ID_INTEL_EESSC 0x0008
#define PCI_DEVICE_ID_INTEL_21145 0x0039
+#define PCI_DEVICE_ID_INTEL_PXHD_0 0x0320
+#define
Re: lockups with netconsole on e1000 on media insertion
> But why are we in a hurry to dump the backlog on the floor? Why are we > worrying about the performance of netpoll without the cable plugged in > at all? We shouldn't be optimizing the data loss case. Because a system shouldn't stall for minutes (or forever like right now) at boot just because the network cable isn't plugged in. > > My primary concern here is that the loop have a non-negligible extent > in time. 5 loops is effectively equal to none. I'd be very surprised > if it was even enough for deglitching. In the normal case the packets should just be send out. -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: [PATCH, experimental] i386 Allow the fixmap to be relocated at boot time
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> This most curious patch allows the fixmap on i386 to be unfixed. The
> result is that we can create a dynamically sizable hole at the top of
> kernel linear address space. I know at least some virtualization
> developers are interested in being able to achieve this to achieve
> run-time sizing of a hole in which a hypervisor can live, or at least to
> test out the performance characteristics of different sized holes.
I've done it simpler with keeping it fixed but defined by the subarch.
Patch is stupid simple (and untested). Do you think there's a huge gain
for dynamically sizing?
--- linux-2.6.12/include/asm-i386/fixmap.h 2005-06-17 12:48:29.0
-0700
+++ linux-2.6.12-subarch/include/asm-i386/fixmap.h 2005-08-01
15:27:05.0 -0700
@@ -15,82 +15,9 @@
#include
-/* used by vmalloc.c, vsyscall.lds.S.
- *
- * Leave one empty page between vmalloc'ed areas and
- * the start of the fixmap.
- */
-#define __FIXADDR_TOP 0xf000
+#include
#ifndef __ASSEMBLY__
-#include
-#include
-#include
-#include
-#ifdef CONFIG_HIGHMEM
-#include
-#include
-#endif
-
-/*
- * Here we define all the compile-time 'special' virtual
- * addresses. The point is to have a constant address at
- * compile time, but to set the physical address only
- * in the boot process. We allocate these special addresses
- * from the end of virtual memory (0xf000) backwards.
- * Also this lets us do fail-safe vmalloc(), we
- * can guarantee that these special addresses and
- * vmalloc()-ed addresses never overlap.
- *
- * these 'compile-time allocated' memory buffers are
- * fixed-size 4k pages. (or larger if used with an increment
- * highger than 1) use fixmap_set(idx,phys) to associate
- * physical memory with fixmap indices.
- *
- * TLB entries of such buffers will not be flushed across
- * task switches.
- */
-enum fixed_addresses {
- FIX_HOLE,
- FIX_VSYSCALL,
-#ifdef CONFIG_X86_LOCAL_APIC
- FIX_APIC_BASE, /* local (CPU) APIC) -- required for SMP or not */
-#endif
-#ifdef CONFIG_X86_IO_APIC
- FIX_IO_APIC_BASE_0,
- FIX_IO_APIC_BASE_END = FIX_IO_APIC_BASE_0 + MAX_IO_APICS-1,
-#endif
-#ifdef CONFIG_X86_VISWS_APIC
- FIX_CO_CPU, /* Cobalt timer */
- FIX_CO_APIC,/* Cobalt APIC Redirection Table */
- FIX_LI_PCIA,/* Lithium PCI Bridge A */
- FIX_LI_PCIB,/* Lithium PCI Bridge B */
-#endif
-#ifdef CONFIG_X86_F00F_BUG
- FIX_F00F_IDT, /* Virtual mapping for IDT */
-#endif
-#ifdef CONFIG_X86_CYCLONE_TIMER
- FIX_CYCLONE_TIMER, /*cyclone timer register*/
-#endif
-#ifdef CONFIG_HIGHMEM
- FIX_KMAP_BEGIN, /* reserved pte's for temporary kernel mappings */
- FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
-#endif
-#ifdef CONFIG_ACPI_BOOT
- FIX_ACPI_BEGIN,
- FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1,
-#endif
-#ifdef CONFIG_PCI_MMCONFIG
- FIX_PCIE_MCFG,
-#endif
- __end_of_permanent_fixed_addresses,
- /* temporary boot-time mappings, used before ioremap() is functional */
-#define NR_FIX_BTMAPS 16
- FIX_BTMAP_END = __end_of_permanent_fixed_addresses,
- FIX_BTMAP_BEGIN = FIX_BTMAP_END + NR_FIX_BTMAPS - 1,
- FIX_WP_TEST,
- __end_of_fixed_addresses
-};
extern void __set_fixmap (enum fixed_addresses idx,
unsigned long phys, pgprot_t flags);
--- linux-2.6.12/include/asm-i386/mach-default/mach_fixmap.h1969-12-31
16:00:00.0 -0800
+++ linux-2.6.12-subarch/include/asm-i386/mach-default/mach_fixmap.h
2005-08-01 15:27:44.0 -0700
@@ -0,0 +1,93 @@
+/*
+ * mach_fixmap.h: mach dependent fixmap split out from fixmap.h
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 1998 Ingo Molnar
+ *
+ * Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999
+ */
+
+#ifndef _ASM_MACH_FIXMAP_H
+#define _ASM_MACH_FIXMAP_H
+
+/* used by vmalloc.c, vsyscall.lds.S.
+ *
+ * Leave one empty page between vmalloc'ed areas and
+ * the start of the fixmap.
+ */
+#define __FIXADDR_TOP 0xf000
+
+#ifndef __ASSEMBLY__
+#include
+#include
+#include
+#include
+#ifdef CONFIG_HIGHMEM
+#include
+#include
+#endif
+/*
+ * Here we define all the compile-time 'special' virtual
+ * addresses. The point is to have a constant address at
+ * compile time, but to set the physical address only
+ * in the boot process. We allocate these special addresses
+ * from the end of virtual memory (0xf000) backwards.
+ * Also this lets us do fail-safe vmalloc(), we
+ * can guarantee that these special addresses and
+ * vmalloc()-ed addresses never overlap.
+ *
+ * these 'compile-time allocated' memory buffers are
+ * fixed-size 4k pages. (or larger if used with an increment
+ * highger than 1) use fixmap_set(idx,phys) to associate
Re: [PATCH rc4-mm1] drivers/char/isicom.c old api rewritten
Jiri Slaby napsal(a): Could somebody test it (but NOT now)? Ok, could anybody test it now, if no problems were discovered, please? - 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: local DDOS? Kernel panic when accessing /proc/ioports
On Sat, Aug 06, 2005 at 01:29:09AM +0200, Marc Ballarin wrote: > On Fri, 5 Aug 2005 23:52:47 +0200 > Martin Loschwitz <[EMAIL PROTECTED]> wrote: > > > > > The situation in this case is somewhat obscene ... Originally, I had exactly > > this problem while using the Knoppix standard kernel (2.6.11 vanilla SMP). I > > then went to compile 2.6.12.3, also with SMP, and it showed exactly the same > > problem. I disable SMP, tried again -- voila, it worked. > > > > The kernel that I am encountering this error again now is 2.6.12.3 -- > > without > > SMP or whatsoever. I'm just out of ideas on how to fix it this time. > > Did you always use the same machine? If so, can you rule out hardware > issues? Can you reproduce this Oops at will? > I tried it on different machines -- same effect. Yes, I can reproduce it at will. > I can't reproduce this on various machines (all X86, kernels 2.6.11.9, > 2.6.12.2, 2.6.13-rc4-mm1, no SMP) > > Regards -- .''`. Martin Loschwitz Debian GNU/Linux developer : :' : [EMAIL PROTECTED][EMAIL PROTECTED] `. `'` http://www.madkiss.org/people.debian.org/~madkiss/ `- Use Debian GNU/Linux 3.0! See http://www.debian.org/ signature.asc Description: Digital signature
Re: [PATCH] Export handle_mm_fault to modules.
On Fri, 5 Aug 2005, Olof Johansson wrote: > > On Fri, Aug 05, 2005 at 04:02:13PM -0700, Linus Torvalds wrote: > > > The only thing that has ever exported it afaik is > > > > arch/ppc/kernel/ppc_ksyms.c:EXPORT_SYMBOL(handle_mm_fault); /* For MOL > > */ > > > > and that looks pretty suspicious too (what is MOL, and regardless, > > shouldn't it be an EXPORT_SYMBOL_GPL?). > > Mac-on-Linux, see http://www.maconlinux.org/. Run MacOS in a virtualized > machine under Linux (or the other way around). It's GPL. Ok. Then I suspect the right patch is this one. Stelian, can you verify? Linus --- diff --git a/arch/ppc/kernel/ppc_ksyms.c b/arch/ppc/kernel/ppc_ksyms.c --- a/arch/ppc/kernel/ppc_ksyms.c +++ b/arch/ppc/kernel/ppc_ksyms.c @@ -324,7 +324,7 @@ EXPORT_SYMBOL(__res); EXPORT_SYMBOL(next_mmu_context); EXPORT_SYMBOL(set_context); -EXPORT_SYMBOL(handle_mm_fault); /* For MOL */ +EXPORT_SYMBOL_GPL(__handle_mm_fault); /* For MOL */ EXPORT_SYMBOL(disarm_decr); #ifdef CONFIG_PPC_STD_MMU extern long mol_trampoline; - 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,experimental] i386 Allow the fixmap to be relocated at boot time
This most curious patch allows the fixmap on i386 to be unfixed. The
result is that we can create a dynamically sizable hole at the top of
kernel linear address space. I know at least some virtualization
developers are interested in being able to achieve this to achieve
run-time sizing of a hole in which a hypervisor can live, or at least to
test out the performance characteristics of different sized holes.
I have not run any performance numbers yet to see how much the cost of
making this dynamic affects native performance, but again I would stress
this is a highly experimental patch and I am looking for feedback and
any performance data from other systems that people are kind enough to
share. I'm not advocating that this get pushed into the mainline Linux
tree at this point by any means!
I believe at least the Xen folks would be interested in playing around
with this for experimenting with different MPT and frame table sizes for
PAE support in a way that doesn't require recompiling the Linux guest
each time - if the performance impact proves to be negligble, this gives
a lot of flexibility to any virtual machine which runs a hypervisor
aware kernel.
Although I did as much as possible to make the vsyscall relocation
appear clean to userspace, I can't guarantee this patch won't set fire
to your chair and electrocute your cat. Please move all pets to a safe
location before attempting to use this.
Zachary Amsden <[EMAIL PROTECTED]>
Allow creation of an compile time hole at the top of linear address space.
Extended to allow a dynamic hole in linear address space, 7/2005. This
required some serious hacking to get everything perfect, but the end result
appears to function quite nicely. Everyone can now share the appreciation
of pseudo-undocumented ELF OS fields, which means core dumps, debuggers
and even broken or obsolete linkers may continue to work.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Index: linux-2.6.13/arch/i386/Kconfig
===
--- linux-2.6.13.orig/arch/i386/Kconfig 2005-08-04 14:14:24.0 -0700
+++ linux-2.6.13/arch/i386/Kconfig 2005-08-05 15:28:42.0 -0700
@@ -127,6 +127,20 @@
endchoice
+config RELOCATABLE_FIXMAP
+ bool "Allow the fixmap to be placed dynamically at runtime"
+ depends on EXPERIMENTAL
+ help
+ Crazy hackers only.
+
+config MEMORY_HOLE
+ int "Create hole at top of memory (0-512 MB)"
+ range 0 512
+ default "0"
+ help
+ Useful for creating a hole in the top of memory when running
+ inside of a virtual machine monitor.
+
config ACPI_SRAT
bool
default y
Index: linux-2.6.13/arch/i386/kernel/sysenter.c
===
--- linux-2.6.13.orig/arch/i386/kernel/sysenter.c 2005-08-02
17:04:12.0 -0700
+++ linux-2.6.13/arch/i386/kernel/sysenter.c2005-08-05 15:47:53.0
-0700
@@ -46,22 +46,90 @@
extern const char vsyscall_int80_start, vsyscall_int80_end;
extern const char vsyscall_sysenter_start, vsyscall_sysenter_end;
+#ifdef CONFIG_RELOCATABLE_FIXMAP
+extern const char SYSENTER_RETURN;
+const char *SYSENTER_RETURN_ADDR;
+
+static void fixup_vsyscall_elf(char *page)
+{
+ Elf32_Ehdr *hdr;
+ Elf32_Shdr *sechdrs;
+ Elf32_Phdr *phdr;
+ char *secstrings;
+ int i, j, n;
+
+ hdr = (Elf32_Ehdr *)page;
+
+ /* Sanity checks against insmoding binaries or wrong arch,
+ weird elf version */
+ if (memcmp(hdr->e_ident, ELFMAG, 4) != 0 ||
+ !elf_check_arch(hdr) ||
+ hdr->e_type != ET_DYN)
+ panic("Bogus ELF in vsyscall DSO\n");
+
+ hdr->e_entry += VSYSCALL_RELOCATION;
+
+ sechdrs = (void *)hdr + hdr->e_shoff;
+ secstrings = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
+
+ for (i = 1; i < hdr->e_shnum; i++) {
+ if (!(sechdrs[i].sh_flags & SHF_ALLOC))
+ continue;
+
+ sechdrs[i].sh_addr += VSYSCALL_RELOCATION;
+ if (strcmp(secstrings+sechdrs[i].sh_name, ".dynsym") == 0) {
+ Elf32_Sym *sym = (void *)hdr + sechdrs[i].sh_offset;
+ n = sechdrs[i].sh_size / sizeof(*sym);
+ for (j = 1; j < n; j++) {
+ int ndx = sym[j].st_shndx;
+ if (ndx == SHN_UNDEF || ndx == SHN_ABS)
+ continue;
+ sym[j].st_value += VSYSCALL_RELOCATION;
+ }
+ } else if (strcmp(secstrings+sechdrs[i].sh_name, ".dynamic") ==
0) {
+ Elf32_Dyn *dyn = (void *)hdr + sechdrs[i].sh_offset;
+ int tag;
+ while ((tag = (++dyn)->d_tag) != DT_NULL) {
+ if (tag ==
Re: local DDOS? Kernel panic when accessing /proc/ioports
On Fri, 5 Aug 2005 23:52:47 +0200 Martin Loschwitz <[EMAIL PROTECTED]> wrote: > > The situation in this case is somewhat obscene ... Originally, I had exactly > this problem while using the Knoppix standard kernel (2.6.11 vanilla SMP). I > then went to compile 2.6.12.3, also with SMP, and it showed exactly the same > problem. I disable SMP, tried again -- voila, it worked. > > The kernel that I am encountering this error again now is 2.6.12.3 -- without > SMP or whatsoever. I'm just out of ideas on how to fix it this time. Did you always use the same machine? If so, can you rule out hardware issues? Can you reproduce this Oops at will? I can't reproduce this on various machines (all X86, kernels 2.6.11.9, 2.6.12.2, 2.6.13-rc4-mm1, no SMP) Regards - 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] Export handle_mm_fault to modules.
On Fri, Aug 05, 2005 at 04:02:13PM -0700, Linus Torvalds wrote: > The only thing that has ever exported it afaik is > > arch/ppc/kernel/ppc_ksyms.c:EXPORT_SYMBOL(handle_mm_fault); /* For MOL > */ > > and that looks pretty suspicious too (what is MOL, and regardless, > shouldn't it be an EXPORT_SYMBOL_GPL?). Mac-on-Linux, see http://www.maconlinux.org/. Run MacOS in a virtualized machine under Linux (or the other way around). It's GPL. -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/
sched_domains SD_BALANCE_FORK and sched_balance_self
First off, apologies for not reviewing this code at 2.6.12-mm2, I was
tied up with other things. I have some concerns as to the intent vs.
actual implementation of SD_BALANCE_FORK and the sched_balance_fork()
routine.
ARCHS=i386,x86_64,ia64
First, iirc SD_NODE_INIT initializes the sched_domain that contains all
the cpus in the system in node groups (with the exception of ia64 and
the allnodes domain). Correct?
SD_NODE_INIT for $ARCHS contains SD_BALANCE_FORK, and no other SD_*_INIT
routines do. This seems strange to me as it would seem more appropriate
to balance within a node on fork as to not have to access the duplicated
mm across nodes. If we are going to use SD_BALANCE_FORK, wouldn't it
make sense to push it down the sched_domain hierarchy to the SD_CPU_INIT
level?
And now to sched_balance_self(). As I understand it the purpose of this
method is to choose the "best" cpu to start a task on. It seems to me
that the best CPU for a forked process would be an idle CPU on the same
node as the parent in order to stay close to it's memory. Failing this,
we may need to move to other nodes if they are idle enough to warrant
the move across node boundaries. Thoughts?
For the comments below, flag = SD_BALANCE_FORK.
static int sched_balance_self(int cpu, int flag)
{
struct task_struct *t = current;
struct sched_domain *tmp, *sd = NULL;
for_each_domain(cpu, tmp)
if (tmp->flags & flag)
sd = tmp;
This jumps to the highest level domain that supports SD_BALANCE_FORK
which are the domains created with SD_NODE_INIT, so we look at all the
CPUs on the system first rather than those local to the parent's node.
while (sd) {
cpumask_t span;
struct sched_group *group;
int new_cpu;
int weight;
span = sd->span;
group = find_idlest_group(sd, t, cpu);
if (!group)
goto nextlevel;
new_cpu = find_idlest_cpu(group, cpu);
if (new_cpu == -1 || new_cpu == cpu)
goto nextlevel;
/* Now try balancing at a lower domain level */
cpu = new_cpu;
nextlevel:
sd = NULL;
weight = cpus_weight(span);
for_each_domain(cpu, tmp) {
if (weight <= cpus_weight(tmp->span))
break;
if (tmp->flags & flag)
sd = tmp;
}
If I am reading it right, this for_each_domain will exit immediately if
jumped to via nextlevel and will only do any work if a new cpu is found
to run on (which is fair sense there is no need to keep looking if the
whole system doesn't have a better place for us to go). If a new cpu
_is_ assigned though, for_each_domain will start with the lowest level
domain - which always has the smallest cpus_weight doesn't it? If so,
won't the (weight <= cpu...) condition always equate to true, ending the
loop at the first domain? If so, then that last loop doesn't do
anything at all, ever. If I am misreading this fragment, could someone
please correct my thinking?
/* while loop will break here if sd == NULL */
}
return cpu;
}
So it seems to me that we should first look at the cpus on the local
domain for SD_BALANCE_FORK. SD_BALANCE_EXEC tasks however have a
minimal mm and could probably be put on whichever cpu/group is the most
idle, regardless of node. Thoughts?
Thanks,
--
Darren Hart
IBM Linux Technology Center
Linux Kernel Team
Phone: 503 578 3185
T/L: 775 3185
-
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: lockups with netconsole on e1000 on media insertion
On Fri, Aug 05, 2005 at 11:56:50PM +0200, Andi Kleen wrote: > > I still don't like this fix. Yes, you're right, it should eventually > > give up. But here it gives up way too easily - 5 could easily > > translate to 5 microseconds. This is analogous to giving up on serial > > transmit if CTS is down for 5 loops. > > > > I'd be much happier if there were some udelay or the like in here so > > that we're not giving up on such a short timeframe. > > Problem is that it could translate to a long aggregate delay > e.g. when the kernel tries to dump the backlog after console_init. > That is why I made the delay so short. But why are we in a hurry to dump the backlog on the floor? Why are we worrying about the performance of netpoll without the cable plugged in at all? We shouldn't be optimizing the data loss case. My primary concern here is that the loop have a non-negligible extent in time. 5 loops is effectively equal to none. I'd be very surprised if it was even enough for deglitching. With serial console, we do polled I/O that runs at the serial rate - milliseconds per line of output. > Longer delay would be possible, but then it would need some logic > to detect down links and don't delay on them and then retry later etc. > Would be all far more complicated. I think we could probably have subsequent failures be much shorter without too much added complexity. But I'm not sure it matters. -- Mathematics is the supreme nostalgia of our time. - 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: mthca and LinuxBIOS
On Fri, 5 Aug 2005, Greg KH wrote: > On Fri, Aug 05, 2005 at 01:38:37PM -0700, Linus Torvalds wrote: > > But what's the real problem we are trying to fix here? We're screwing up the top 32 bits of the BAR when you resume it. Look at the patch, you'll see the fix (the other part of the patch looks fine, but then in order to not overwrite the upper bits with zero again when doing the _next_ - nonexistent - BAR update, we need to have something that avoids writing the next BAR). Remember: a 64-bit BAR puts the upper 32 bits in what would otherwise be the low 32 bits of the next BAR. Which is why we need to mark the next BAR resource as _not_ being valid some way - so that we don't try to (incorrectly) "restore" it and overwrite the high bits of the previous BAR. Of course, this only hits the (very few) people who not only have 64-bit PCI devices, but literally have them mapped in the 4GB+ region. Quite uncommon. 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: mthca and LinuxBIOS
On Fri, Aug 05, 2005 at 03:25:02PM -0700, yhlu wrote: > In LinuxBIOS, We can allocate 64 bit region ( 0xfc000) to the > mellanox Infiniband card. Some range above 4G. So the mmio below 4G > is some smaller only 128M, Otherwise need 512M. If 4 IB cards are > used, the mmio will be 2G. For new opteron E stepping, We could use > hareware memhole support. But if the CPU is before opteron E, We only > can use SW mem mapping ( will lose some performance) or lose (2G RAM). > at such case We need 64bit pref mem. We only lose 128M even four IB > card are installed. > > yesterday, someone add pci_restore_bars, that will call > pci_update_resource, and it will overwirte upper 32 bit of BAR2 and > BAR4 of IB card. Hm, perhaps that change should not do this? Dominik, care to weigh in here? That was your patch... > So the patch make pci_restore_resource > 1. don't touch BAR3, and BAR5, if BAR2, and BAR4 are 64 bit MEM IO > 2. not assume BAR2 and BAR4 upper 32bit is 0 if if BAR2, and BAR4 are > 64 bit MEM IO 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] Export handle_mm_fault to modules.
On Fri, 5 Aug 2005, Stelian Pop wrote: > > handle_mm_fault changed from an inline function to a non-inline one > (__handle_mm_fault), which is not available to external kernel modules. > The patch below fixes this. We didn't use to export handle_mm_fault before, and it wasn't an inline function in 2.6.12 either. And no modules I know of call handle_mm_fault(). What module causes problems? That's very much a kernel internal function. IOW, there's something wrong in your setup. It can't have worked on 2.6.12 either, The only thing that has ever exported it afaik is arch/ppc/kernel/ppc_ksyms.c:EXPORT_SYMBOL(handle_mm_fault); /* For MOL */ and that looks pretty suspicious too (what is MOL, and regardless, shouldn't it be an EXPORT_SYMBOL_GPL?). 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] 6700/6702PXH quirk
On Fri, Aug 05, 2005 at 03:05:13PM -0700, Kristen Accardi wrote:
> +int msi_add_quirk(struct pci_dev *dev)
> +{
> + struct msi_quirk *quirk;
> +
> + quirk = (struct msi_quirk *) kmalloc(sizeof(*quirk), GFP_KERNEL);
> + if (!quirk)
> + return -ENOMEM;
> +
> + INIT_LIST_HEAD(>list);
> + quirk->dev = dev;
You just messed up the reference counting of this device :(
Anyway, Jeff is right, add another bit field.
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] 6700/6702PXH quirk
Kristen Accardi <[EMAIL PROTECTED]> wrote: > > On Fri, 2005-08-05 at 15:26 -0700, Andrew Morton wrote: > > Kristen Accardi <[EMAIL PROTECTED]> wrote: > > > > + if (!quirk) > > > + return -ENOMEM; > > > + > > > + INIT_LIST_HEAD(>list); > > > + quirk->dev = dev; > > > + list_add(>list, _quirk_list); > > > + return 0; > > > +} > > > > Does the list not need any locking? > > Actually, I'm glad you asked that question because I was wondering that > myself. The devices are added to the list at boot time, and after that > time, the list will never change. Does PCI enumeration happen on all > processors? I thought maybe it only happened on one. In that case we > don't need a lock I don't think. > do_basic_setup() is called after SMP is up and running. do_basic_setup() calls driver_init() and most of the initcalls. Plus there's kernel preemption. So yup, I think you need locking.. - 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: Documentation - how to apply patches for various trees
On Wednesday 03 August 2005 23:08, Linus Torvalds wrote: > > On Wed, 3 Aug 2005, Jesper Juhl wrote: > > > > Here's an updated version of my document that attempts to give a short > > explanation of the various kernel trees and how to apply their patches. > > It incorporates all the feedback I've gotten (thanks guys). > > Can we have more whitespace? > [snip] The new version of the document below has more whitespace and also incorporates a lot of feedback I've gotten since the last version I posted. I think this is getting close to the point where it could be included. What do you say? Add a new document describing the major kernel trees and how to apply their patches. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- Documentation/applying-patches.txt | 439 + 1 files changed, 439 insertions(+) diff -uP linux-2.6.13-rc5-orig/Documentation/applying-patches.txt linux-2.6.13-rc5/Documentation/applying-patches.txt --- linux-2.6.13-rc5-orig/Documentation/applying-patches.txt1970-01-01 01:00:00.0 +0100 +++ linux-2.6.13-rc5/Documentation/applying-patches.txt 2005-08-06 00:46:17.0 +0200 @@ -0,0 +1,439 @@ + + Applying Patches To The Linux Kernel + + + (Written by Jesper Juhl, August 2005) + + + +A frequently asked question on the Linux Kernel Mailing List is how to apply +a patch to the kernel or, more specifically, what base kernel a patch for +one of the many trees/branches should be applied to. Hopefully this document +will explain this to you. + +In addition to explaining how to apply and revert patches, a brief +description of the different kernel trees (and examples of how to apply +their specific patches) is also provided. + + +What is a patch? +--- + A patch is a small text document containing a delta of changes between two +different versions of a source tree. Patches are created with the `diff' +program. +To correctly apply a patch you need to know what base it was generated from +and what new version the patch will change the source tree into. These +should both be present in the patch file metadata or be possible to deduce +from the filename. + + +How do I apply or revert a patch? +--- + You apply a patch with the `patch' program. The patch program reads a diff +(or patch) file and makes the changes to the source tree described in it. + +Patches for the Linux kernel are generated relative to the parent directory +holding the kernel source dir. + +This means that paths to files inside the patch file contain the name of the +kernel source directories it was generated against (or some other directory +names like "a/" and "b/"). +Since this is unlikely to match the name of the kernel source dir on your +local machine (but is often useful info to see what version an otherwise +unlabeled patch was generated against) you should change into your kernel +source directory and then strip the first element of the path from filenames +in the patch file when applying it (the -p1 argument to `patch' does this). + +To revert a previously applied patch, use the -R argument to patch. +So, if you applied a patch like this: + patch -p1 < ../patch-x.y.z + +You can revert (undo) it like this: + patch -R -p1 < ../patch-x.y.z + + +How do I feed a patch/diff file to `patch'? +--- + This (as usual with Linux and other UNIX like operating systems) can be +done in several different ways. +In all the examples below I feed the file (in uncompressed form) to patch +via stdin using the following syntax: + patch -p1 < path/to/patch-x.y.z + +If you just want to be able to follow the examples below and don't want to +know of more than one way to use patch, then you can stop reading this +section here. + +Patch can also get the name of the file to use via the -i argument, like +this: + patch -p1 -i path/to/patch-x.y.z + +If your patch file is compressed with gzip or bzip2 and you don't want to +uncompress it before applying it, then you can feed it to patch like this +instead: + zcat path/to/patch-x.y.z.gz | patch -p1 + bzcat path/to/patch-x.y.z.bz2 | patch -p1 + +If you wish to uncompress the patch file by hand first before applying it +(what I assume you've done in the examples below), then you simply run +gunzip or bunzip2 on the file - like this: + gunzip patch-x.y.z.gz + bunzip2 patch-x.y.z.bz2 + +Which will leave you with a plain text patch-x.y.z file that you can feed to +patch via stdin or the -i argument, as you prefer. + +A few other nice arguments for patch are -s which causes patch to be silent +except for errors which is nice to prevent errors from scrolling out of the +screen too fast, and --dry-run which causes patch to just print a listing of +what would happen, but doesn't actually make any changes. Finally --verbose +tells patch to print more information about the work being done. + + +Common errors when patching +--- + When patch applies a
Re: [PATCH] 6700/6702PXH quirk
AFAICS we don't need a new list, simply consisting of PCI devs. Just invent, and set, a bit somewhere in struct pci_dev. Jeff - 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/
x86_64 frame pointer via thread context
Hi, I've been playing around with extracting the frame pointer from rBP
register and using that to perform backtracing on the x86_64 platform.
With a non-threaded user application, I was able to do that
successfully. However, when attempting to do that with multi-threaded
app, this seems to fail on spawned threads (not the main thread). I am
running 2.6.13-rc5, and I have attached my test application source and
the .config I used for the kernel. The test application is compiled as:
gcc -Wall -fno-omit-frame-pointer -lpthread -o ttest1 ttest1.c
Basically the test application registers a signal. After the threads are
spawned, the main thread uses pthread_kill to signal the target threads.
The signal handler then extracts the user context and then dumps out the
rBP register as the frame pointer. When the main thread signals itself,
the rBP looks to be a valid pointer. However, when the signal handler is
executing under the spawned target threads' contexts, the value of rBP
shows up as 0x consistently. I dumped out the rBP value
in pt_regs that is passed to arch/x86_64/kernel/signal:~462:
do_notify_resume() from entry.S, and the rbp value in pt_regs is also
0x. So basically the value that was copied from kernel to user
context is "bad".
Am I doing something wrong, or is this intended to be this way on
x86_64, or is something incorrect in the kernel? This method works fine
on i386. Thanks for any help!
--
Dave
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define SCP_FROM_UCONTEXT(uc) \
((struct sigcontext *) &((struct ucontext *)(uc))->uc_mcontext)
static int _traceback_signal = -1;
static pthread_t pid1 = 0;
static pthread_t pid2 = 0;
static pthread_t pidmain = 0;
extern int __libc_allocate_rtsig(int high);
static void tb_sig_handler(int sig, siginfo_t *info, void *ucontext)
{
struct sigcontext *scp;
int ret, i;
printf("\n%s entered\n", __func__);
printf("thread 0x%lx context\n", pthread_self());
scp = SCP_FROM_UCONTEXT(ucontext);
printf("rIP: %16.16lx\n", scp->rip);
printf("rSP: %16.16lx\n", scp->rsp);
printf("rBP: %16.16lx\n", scp->rbp);
printf("\n");
}
void * test_thread1(void *arg)
{
while(1) {
sleep(2);
};
return NULL;
}
void * test_thread2(void *arg)
{
while(1) {
sleep(2);
};
return NULL;
}
int main()
{
struct sigaction act;
int ret = 0;
_traceback_signal = __libc_allocate_rtsig(1);
act.sa_sigaction = tb_sig_handler;
sigemptyset(_mask);
act.sa_flags = SA_RESTART | SA_SIGINFO;
sigaction(_traceback_signal, , NULL);
ret = pthread_create(, NULL, test_thread1, NULL);
if(ret < 0) {
fprintf(stderr, "thread 1 creation failed\n");
return -1;
}
printf("Thread 1 (0x%lx) created\n", pid1);
ret = pthread_create(, NULL, test_thread2, NULL);
if(ret < 0) {
fprintf(stderr, "thread 2 creation failed\n");
return -1;
}
printf("Thread 2 (0x%lx) created\n", pid2);
pidmain = pthread_self();
printf("Main pid: 0x%lx\n", pidmain);
ret = pthread_kill(pid1, _traceback_signal);
if(ret >= 0) {
printf("pid1[0x%lx] signaled\n", pid1);
}
sleep(1);
ret = pthread_kill(pid2, _traceback_signal);
if(ret >= 0) {
printf("pid2[0x%lx] signaled\n", pid2);
}
sleep(1);
#if 0
ret = pthread_kill(pidmain, _traceback_signal);
if(ret >= 0) {
printf("pidmain[0x%lx] signaled\n", pidmain);
}
#endif
return 0;
}
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.13-rc5
# Thu Aug 4 12:43:38 2005
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODULE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Processor type and features
#
# CONFIG_MK8 is not set
CONFIG_MPSC=y
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_L1_CACHE_BYTES=128
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_X86_HT=y
CONFIG_X86_IO_APIC=y
Re: local DDOS? Kernel panic when accessing /proc/ioports
On Fri, Aug 05, 2005 at 03:33:44PM -0700, Andrew Morton wrote: > Martin Loschwitz <[EMAIL PROTECTED]> wrote: > > > > On Fri, Aug 05, 2005 at 03:40:26PM -0400, linux-os (Dick Johnson) wrote: > > > > > > On Fri, 5 Aug 2005, Martin Loschwitz wrote: > > > > > > > Hi folks, > > > > > > > > I just ran into the following problem: Having updated my box to > > > > 2.6.12.3, > > > > I tried to start YaST2 and noticed a kernel panic (see below). Some > > > > quick > > > > debugging brought the result that the kernel crashes while some user > > > > (not > > > > even root ...) tries to access /proc/ioports. Is this a known problem > > > > and > > > > if so, is a fix available? > > > > > > > > Ooops and ksymoops-output is attached. > > > > > > > > > > This can happen if a module is unloaded that doesn't free its > > > resources! Been there, done that. > > > > > > > "This can happen" is not an acceptable explanation, I think. > > It's a very accurate one though. > > The most common cause of this bug is that some buggy kernel module has been > unloaded. It forgot to release its I/O region. When you later come along > to look in /proc/ioports the kernel goes to fetch information from the > memory which is "owned" by the module which isn't there any more. Crash. > > So if you can identify which kernel module was loaded and then unloaded, > we'll fix it up. uhm -- well, okay, once again: If you boot knoppix with the "debug" argument, it will start init but throw you on a very limited shell called "ash" right after that. At least the "cat" command is included in that shell, and lsmod is available as well. I am pretty sure that until that very early moment, not a single module has been unloaded -- infact, "rmmod" is not even called in the init script until that moment. The only modules loaded were: sbp2 ohci1394 usb_storage ub ehci_hcd usbcore And that's it. So if you suspect some module to be the culprit, it must be one of these. -- .''`. Martin Loschwitz Debian GNU/Linux developer : :' : [EMAIL PROTECTED][EMAIL PROTECTED] `. `'` http://www.madkiss.org/people.debian.org/~madkiss/ `- Use Debian GNU/Linux 3.0! See http://www.debian.org/ signature.asc Description: Digital signature
Re: [PATCH] 6700/6702PXH quirk
On Fri, 2005-08-05 at 15:26 -0700, Andrew Morton wrote: > Kristen Accardi <[EMAIL PROTECTED]> wrote: > > + if (!quirk) > > + return -ENOMEM; > > + > > + INIT_LIST_HEAD(>list); > > + quirk->dev = dev; > > + list_add(>list, _quirk_list); > > + return 0; > > +} > > Does the list not need any locking? Actually, I'm glad you asked that question because I was wondering that myself. The devices are added to the list at boot time, and after that time, the list will never change. Does PCI enumeration happen on all processors? I thought maybe it only happened on one. In that case we don't need a lock I don't think. - 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: amd64-agp vs. swsusp
On Fri, 5 Aug 2005, Andreas Steinmetz wrote: > AFAIK it works when agp is built into the kernel. You will get problems > when it is built as a module. In the module case you may want to try if > loading the module before resuming helps. Strange. I've had it built as a module from day one and never had a problem resuming. -cp -- "There are three kinds of lies: lies, damned lies, and statistics." -- Benjamin Disraeli - 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: External USB2 HDD affects speed hda
Rene Herman wrote: David Brownell wrote: Until I have some time available to actually look at this, all I can do is answer questions and say "hmm, that's strange" given wierd facts. The wierdness here is why that "Async" status bit is ever getting set when there's no work for it to do. I'll be available for testing... One more data point: I just checked 2.4.31 and it behaves the same. Hi David. Has there been any progress on this issue? (thread at http://marc.theaimsgroup.com/?t=11174961402=1=2) Rene. - 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: local DDOS? Kernel panic when accessing /proc/ioports
Martin Loschwitz <[EMAIL PROTECTED]> wrote: > > On Fri, Aug 05, 2005 at 03:40:26PM -0400, linux-os (Dick Johnson) wrote: > > > > On Fri, 5 Aug 2005, Martin Loschwitz wrote: > > > > > Hi folks, > > > > > > I just ran into the following problem: Having updated my box to 2.6.12.3, > > > I tried to start YaST2 and noticed a kernel panic (see below). Some quick > > > debugging brought the result that the kernel crashes while some user (not > > > even root ...) tries to access /proc/ioports. Is this a known problem and > > > if so, is a fix available? > > > > > > Ooops and ksymoops-output is attached. > > > > > > > This can happen if a module is unloaded that doesn't free its > > resources! Been there, done that. > > > > "This can happen" is not an acceptable explanation, I think. It's a very accurate one though. The most common cause of this bug is that some buggy kernel module has been unloaded. It forgot to release its I/O region. When you later come along to look in /proc/ioports the kernel goes to fetch information from the memory which is "owned" by the module which isn't there any more. Crash. So if you can identify which kernel module was loaded and then unloaded, we'll fix it up. - 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] driver core: Add the ability to unbind drivers to devices from userspace
On Tue, Jan 01, 2002 at 08:53:39AM +0100, Pavel Machek wrote: > Hi! > > > > > New, simplified version of the sysfs whitespace strip patch... > > > > > > Could you tell me why you don't just fail the operation if malformed > > > input is supplied? > > > > Leading/trailing white space should be allowed. For example echo > > appends '\n' unless you know to use -n. It is easier to fix the kernel > > than to teach everyone to use -n. > > Please, NO! echo -n is the right thing to do, and users will eventually learn. > We are not going to add such workarounds all over the kernel... Ahhh, this would be so much easier if people just got used to using printf instead of echo when doing text output. =) Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ - 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] 6700/6702PXH quirk
Kristen Accardi <[EMAIL PROTECTED]> wrote:
>
> ...
> On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
> driver and SHPC driver in MSI mode are used together. This patch will
> prevent MSI from being enabled for the SHPC.
>
> I made this patch more generic than just shpc because I thought it was
> possible that other devices in the system might need to add themselves
> to the msi black list.
>
> diff -uprN -X linux-2.6.13-rc4/Documentation/dontdiff
> linux-2.6.13-rc4/drivers/pci/msi.c linux-2.6.13-rc4-pxhquirk/drivers/pci/msi.c
> --- linux-2.6.13-rc4/drivers/pci/msi.c2005-07-28 15:44:44.0
> -0700
> +++ linux-2.6.13-rc4-pxhquirk/drivers/pci/msi.c 2005-08-05
> 11:38:00.0 -0700
> @@ -38,6 +38,32 @@ int vector_irq[NR_VECTORS] = { [0 ... NR
> u8 irq_vector[NR_IRQ_VECTORS] = { FIRST_DEVICE_VECTOR , 0 };
> #endif
>
> +
> +LIST_HEAD(msi_quirk_list);
> +
Can't this have static scope?
> +struct msi_quirk
> +{
> + struct list_head list;
> + struct pci_dev *dev;
> +};
We normally do
struct msi_quirk {
> +
> +int msi_add_quirk(struct pci_dev *dev)
> +{
> + struct msi_quirk *quirk;
> +
> + quirk = (struct msi_quirk *) kmalloc(sizeof(*quirk), GFP_KERNEL);
kmalloc() returns void*, hence no typecast is needed. In fact it's
undesirable because the cast defeats all typechecking.
> + if (!quirk)
> + return -ENOMEM;
> +
> + INIT_LIST_HEAD(>list);
> + quirk->dev = dev;
> + list_add(>list, _quirk_list);
> + return 0;
> +}
Does the list not need any locking?
> --- linux-2.6.13-rc4/drivers/pci/quirks.c 2005-07-28 15:44:44.0
> -0700
> +++ linux-2.6.13-rc4-pxhquirk/drivers/pci/quirks.c2005-08-05
> 11:54:15.0 -0700
> @@ -21,6 +21,10 @@
> #include
> #include "pci.h"
>
> +
> +void disable_msi_mode(struct pci_dev *dev, int pos, int type);
> +int msi_add_quirk(struct pci_dev *dev);
> +
Please put these declarations in a .h file which is visible to the
implementations and to all users.
> +static void __devinit quirk_pcie_pxh(struct pci_dev *dev)
> +{
> + disable_msi_mode(dev, pci_find_capability(dev, PCI_CAP_ID_MSI),
> + PCI_CAP_ID_MSI);
> + if (!msi_add_quirk(dev))
> + printk(KERN_WARNING "PCI: PXH quirk detected, disabling MSI for
> SHPC device\n");
> + else {
> + pci_msi_quirk = 1;
> + printk(KERN_WARNING "PCI: PXH quirk detected, unable to disable
> MSI for SHPC device, disabling MSI for all devices\n");
> + }
Some people use 80-column xterms. Break the strings up thusly:
printk(KERN_WARNING "PCI: PXH quirk detected, disabling "
"MSI for SHPC device\n");
-
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: mthca and LinuxBIOS
In LinuxBIOS, We can allocate 64 bit region ( 0xfc000) to the
mellanox Infiniband card. Some range above 4G. So the mmio below 4G
is some smaller only 128M, Otherwise need 512M. If 4 IB cards are
used, the mmio will be 2G. For new opteron E stepping, We could use
hareware memhole support. But if the CPU is before opteron E, We only
can use SW mem mapping ( will lose some performance) or lose (2G RAM).
at such case We need 64bit pref mem. We only lose 128M even four IB
card are installed.
yesterday, someone add pci_restore_bars, that will call
pci_update_resource, and it will overwirte upper 32 bit of BAR2 and
BAR4 of IB card.
So the patch make pci_restore_resource
1. don't touch BAR3, and BAR5, if BAR2, and BAR4 are 64 bit MEM IO
2. not assume BAR2 and BAR4 upper 32bit is 0 if if BAR2, and BAR4 are
64 bit MEM IO
YH
On 8/5/05, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 05, 2005 at 01:38:37PM -0700, Linus Torvalds wrote:
> >
> > Hmm.. This looks half-way sane, but too ugly for words.
> >
> > I'd much rather see that when we detect a 64-bit resource, we always mark
> > the next resource as being reserved some way, and then we just make
> > pci_update_resource() ignore such reserved resources.
> >
> > The
> >
> > if((resno & 1)==1) {
> > /* check if previous reg is 64 mem */
> > ..
> >
> > stuff is really too ugly.
>
> Yeah, that's not nice.
>
> But what's the real problem we are trying to fix here? I seem to have
> missed that in the email thread somehow.
>
> > Greg? Ivan?
>
> Ivan's the pci resource guru, any thoughts as to how to do this in a
> nicer way?
>
> 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] Export handle_mm_fault to modules.
On Fri, Aug 05, 2005 at 11:55:12PM +0200, Stelian Pop wrote: > handle_mm_fault changed from an inline function to a non-inline one > (__handle_mm_fault), which is not available to external kernel modules. > The patch below fixes this. > > Stelian. > > Export __handle_mm_fault to modules (called by the inlined handle_mm_fault > function). Which modules need this ? 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: rc5 seemed to kill a disk that rc4-mm1 likes. Also some X trouble.
Helge Hafting <[EMAIL PROTECTED]> wrote: > > 2.6.13-rc5 seemed to kill a scsi disk (sdb) for me, where 2.6.13-rc4-mm1 > have no problems with the same disk. > > Machine: opteron running a x86-64 kernel, with built-in SATA as well as > a symbios scsi controller. Two videocards running independent xservers. > The sdb disk is on the symbios controller. > > > Using 2.6.13-rc5 I suddenly got this in my logs: > > Aug 3 22:06:00 tenkende-august -- MARK -- > Aug 3 22:17:15 tenkende-august kernel: sd 0:0:0:0: ABORT operation started. > Aug 3 22:17:15 tenkende-august kernel: sd 0:0:0:0: ABORT operation timed-out. > > ... > This "no additiomnal sense" then repeats for many screenfulls. > Two sdb partitions got dropped from RAID-1 as they failed, the > md devices got remoutned read-only. > > I thought the disk had died - it was my oldest so it'd be reasonable. > Rebooting 2.6.13-rc5 did not bring the disk back - it came up useless again. > > I switched back to 2.6.13-rc4-mm1 at this point for another reason, > my X display aquired a nasty tendency to go blank for no reason during work, > something I could fix by changing resolution baqck and forth. X also tended > to get > stuck for a minute now and then - a problem I haven't seen since early 2.6. > > These troubles disappeared by going back to 2.6.13-rc4-mm1. Even more > interesting, > the sdb disk seems fine again. There were no errors as I copied > all data to another disk, and no errors when I ran a badblocks write-test > (the nondestructive write test) on it. > > The two kernels have some config differences. The 2.6.13-rc5 kernel > has ACPI+CPUFREQ configured, that the 2.6.13-rc4-mm1 doesn't have. That's a pretty big difference ;) > ... > I can run more tests, but don't know what would be the most interesting. > rc5 without powermanagement? rc4-mm1 with it? Or the newest git kernel? > Or is this the effect of some known problem? The latest -git kernel (or 2.6.13-rc6 if it's there) with APCI enabled is the one to test, please. - 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: [Pcihpd-discuss] Re: [PATCH] use bus_slot number for name
On Fri, Aug 05, 2005 at 02:31:07PM -0700, Kristen Accardi wrote:
> +#define HPSLOT_NAME_SIZE BUS_ID_SIZE
> +static inline void pci_hp_make_slot_name(struct hotplug_slot *hpslot, struct
> pci_dev *pdev)
> +{
> + snprintf(hpslot->name, HPSLOT_NAME_SIZE, "%s", pci_name(pdev));
> +}
I don't think that others can use this, as you can have multiple struct
pci_dev for the same "slot".
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: gcapatcch equivalent?
Dave Airlie <[EMAIL PROTECTED]> wrote: > > > At KS I asked after a gcapatch command for git.. > > I've got two trees drm-2.6 and linux-2.6, linux-2.6 is latest Linus, so of > course a tree diff gives me all the new patches in linux-2.6 that aren't > in drm-2.6 which isn't what I want.. I want gcapatch > > I'm sure someone has one and I don't really want to care about git > internals :-) I do this, which mostly works: MERGE_BASE=$(git-merge-base $(cat .git/refs/heads/origin ) \ $(cat .git/refs/heads/$patch_name)) cg-diff -r $MERGE_BASE:$(cat .git/refs/heads/$patch_name) >> \ $PULL/$patch_name.patch (I'm supposed to be doing real git merges of 40 trees and let git do more work for me. I'll do that when I'm feeling really, really trusting). - 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] Re: 2.6.12: itimer_real timers don't survive execve() any more
> There are other concerns. Let me see if I understand this. A thread > (other than the leader) can exec and we then need to change the > real_timer to wake the new task which will NOT be using the same task > struct. That's correct. de_thread will turn the thread calling exec into the new leader and kill off all the other threads, including the old leader. The exec'ing thread's existing task_struct is reassigned to the PID of the original leader. > My looking at the code shows that the thread leader can exit and then > stays around as a zombi until the last thread in the group exits. That is correct. > If an alarm comes during this wait I suspect it will wake this zombi and > cause problems. You are mistaken. The signal code handles process signals sent when the leader is a zombie. The group leader sticks around with the PID that matches the TGID, until there are no live threads with its TGID. That is how process-wide kill can still work. 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: [PATCH] 6700/6702PXH quirk
On Fri, 2005-08-05 at 11:35 -0700, Greg KH wrote:
> On Fri, Aug 05, 2005 at 09:27:42AM -0700, Kristen Accardi wrote:
> > @@ -1127,3 +1159,5 @@ EXPORT_SYMBOL(pci_enable_msi);
> > EXPORT_SYMBOL(pci_disable_msi);
> > EXPORT_SYMBOL(pci_enable_msix);
> > EXPORT_SYMBOL(pci_disable_msix);
> > +EXPORT_SYMBOL(disable_msi_mode);
> > +EXPORT_SYMBOL(msi_add_quirk);
>
> Why do these need to be exported? It doesn't look like you are trying
> to access these from a module, or do you have a patch that uses them
> somewhere else?
>
> thanks,
>
> greg k-h
resend with changelog info:
On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
driver and SHPC driver in MSI mode are used together. This patch will
prevent MSI from being enabled for the SHPC.
I made this patch more generic than just shpc because I thought it was
possible that other devices in the system might need to add themselves
to the msi black list.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
diff -uprN -X linux-2.6.13-rc4/Documentation/dontdiff
linux-2.6.13-rc4/drivers/pci/msi.c linux-2.6.13-rc4-pxhquirk/drivers/pci/msi.c
--- linux-2.6.13-rc4/drivers/pci/msi.c 2005-07-28 15:44:44.0 -0700
+++ linux-2.6.13-rc4-pxhquirk/drivers/pci/msi.c 2005-08-05 11:38:00.0
-0700
@@ -38,6 +38,32 @@ int vector_irq[NR_VECTORS] = { [0 ... NR
u8 irq_vector[NR_IRQ_VECTORS] = { FIRST_DEVICE_VECTOR , 0 };
#endif
+
+LIST_HEAD(msi_quirk_list);
+
+struct msi_quirk
+{
+ struct list_head list;
+ struct pci_dev *dev;
+};
+
+
+int msi_add_quirk(struct pci_dev *dev)
+{
+ struct msi_quirk *quirk;
+
+ quirk = (struct msi_quirk *) kmalloc(sizeof(*quirk), GFP_KERNEL);
+ if (!quirk)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(>list);
+ quirk->dev = dev;
+ list_add(>list, _quirk_list);
+ return 0;
+}
+
+
+
static void msi_cache_ctor(void *p, kmem_cache_t *cache, unsigned long flags)
{
memset(p, 0, NR_IRQS * sizeof(struct msi_desc));
@@ -453,7 +479,7 @@ static void enable_msi_mode(struct pci_d
}
}
-static void disable_msi_mode(struct pci_dev *dev, int pos, int type)
+void disable_msi_mode(struct pci_dev *dev, int pos, int type)
{
u16 control;
@@ -695,10 +721,16 @@ int pci_enable_msi(struct pci_dev* dev)
{
int pos, temp, status = -EINVAL;
u16 control;
+ struct msi_quirk *quirk;
if (!pci_msi_enable || !dev)
return status;
+ list_for_each_entry(quirk, _quirk_list, list) {
+ if (quirk->dev == dev)
+ return -EINVAL;
+ }
+
temp = dev->irq;
if ((status = msi_init()) < 0)
diff -uprN -X linux-2.6.13-rc4/Documentation/dontdiff
linux-2.6.13-rc4/drivers/pci/quirks.c
linux-2.6.13-rc4-pxhquirk/drivers/pci/quirks.c
--- linux-2.6.13-rc4/drivers/pci/quirks.c 2005-07-28 15:44:44.0
-0700
+++ linux-2.6.13-rc4-pxhquirk/drivers/pci/quirks.c 2005-08-05
11:54:15.0 -0700
@@ -21,6 +21,10 @@
#include
#include "pci.h"
+
+void disable_msi_mode(struct pci_dev *dev, int pos, int type);
+int msi_add_quirk(struct pci_dev *dev);
+
/* Deal with broken BIOS'es that neglect to enable passive release,
which can cause problems in combination with the 82441FX/PPro MTRRs */
static void __devinit quirk_passive_release(struct pci_dev *dev)
@@ -1267,6 +1271,30 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7320_MCH,
quirk_pcie_mch );
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7525_MCH,
quirk_pcie_mch );
+
+/*
+ * It's possible for the MSI to get corrupted if shpc and acpi
+ * are used together on certain PXH-based systems.
+ */
+static void __devinit quirk_pcie_pxh(struct pci_dev *dev)
+{
+ disable_msi_mode(dev, pci_find_capability(dev, PCI_CAP_ID_MSI),
+ PCI_CAP_ID_MSI);
+ if (!msi_add_quirk(dev))
+ printk(KERN_WARNING "PCI: PXH quirk detected, disabling MSI for
SHPC device\n");
+ else {
+ pci_msi_quirk = 1;
+ printk(KERN_WARNING "PCI: PXH quirk detected, unable to disable
MSI for SHPC device, disabling MSI for all devices\n");
+ }
+
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXHD_0,
quirk_pcie_pxh);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXHD_1,
quirk_pcie_pxh);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXH_0,
quirk_pcie_pxh);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXH_1,
quirk_pcie_pxh);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXHV,
quirk_pcie_pxh);
+
+
static void __devinit quirk_netmos(struct pci_dev *dev)
{
unsigned int num_parallel = (dev->subsystem_device & 0xf0) >> 4;
diff -uprN -X
RE: [RFC] Demand faulting for large pages
Adam Litke wrote on Friday, August 05, 2005 8:22 AM > Below is a patch to implement demand faulting for huge pages. The main > motivation for changing from prefaulting to demand faulting is so that > huge page allocations can follow the NUMA API. Currently, huge pages > are allocated round-robin from all NUMA nodes. Chen, Kenneth W wrote on Friday, August 05, 2005 2:34 PM > Spurious WARN_ON. Calls to hugetlb_pte_fault() is conditioned upon > if (is_vm_hugetlb_page(vma)) > > > > Broken here. Return VM_FAULT_SIGBUS when *pte is present?? Why > can't you move all the logic into hugetlb_pte_fault and simply call > it directly from handle_mm_fault? I'm wondering has this patch ever been tested? More broken bits: in arch/i386/mm/hugetlbpage.c:huge_pte_offset - with demand paging, you can't unconditionally walk the page table without checking existence of pud and pmd. I haven't looked closely at recent change in free_pgtables(), but we used to have a need to scrub old pmd mapping before allocate one for hugetlb pte on x86. You have to do that in huge_pte_alloc(), I'm specifically concerned with arch/i386/mm/hugetlbpage.c:huge_pte_alloc() - Ken - 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: local DDOS? Kernel panic when accessing /proc/ioports
On Fri, Aug 05, 2005 at 04:03:07PM -0400, Lee Revell wrote: > On Fri, 2005-08-05 at 21:26 +0200, Martin Loschwitz wrote: > > Ooops and ksymoops-output is attached. > > Also, don't use ksymoops for 2.6, it's redundant at best and at worst > actually removes information. Check oops-tracing.txt, the docs have > been updated. > Well, in this case, ksymoops output told me what I wanted to know -- the thing explodes when reading /proc/ioports. I need to know why it does, if the problem might be reproducible for others (that is the possible ddos thing ...) and how to fix it ... > Lee > > - > 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/ -- .''`. Martin Loschwitz Debian GNU/Linux developer : :' : [EMAIL PROTECTED][EMAIL PROTECTED] `. `'` http://www.madkiss.org/people.debian.org/~madkiss/ `- Use Debian GNU/Linux 3.0! See http://www.debian.org/ signature.asc Description: Digital signature
Re: mthca and LinuxBIOS
On Fri, Aug 05, 2005 at 01:38:37PM -0700, Linus Torvalds wrote:
>
> Hmm.. This looks half-way sane, but too ugly for words.
>
> I'd much rather see that when we detect a 64-bit resource, we always mark
> the next resource as being reserved some way, and then we just make
> pci_update_resource() ignore such reserved resources.
>
> The
>
> if((resno & 1)==1) {
> /* check if previous reg is 64 mem */
> ..
>
> stuff is really too ugly.
Yeah, that's not nice.
But what's the real problem we are trying to fix here? I seem to have
missed that in the email thread somehow.
> Greg? Ivan?
Ivan's the pci resource guru, any thoughts as to how to do this in a
nicer way?
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: lockups with netconsole on e1000 on media insertion
> I still don't like this fix. Yes, you're right, it should eventually > give up. But here it gives up way too easily - 5 could easily > translate to 5 microseconds. This is analogous to giving up on serial > transmit if CTS is down for 5 loops. > > I'd be much happier if there were some udelay or the like in here so > that we're not giving up on such a short timeframe. Problem is that it could translate to a long aggregate delay e.g. when the kernel tries to dump the backlog after console_init. That is why I made the delay so short. Longer delay would be possible, but then it would need some logic to detect down links and don't delay on them and then retry later etc. Would be all far more complicated. -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/
[PATCH] Export handle_mm_fault to modules.
handle_mm_fault changed from an inline function to a non-inline one (__handle_mm_fault), which is not available to external kernel modules. The patch below fixes this. Stelian. Export __handle_mm_fault to modules (called by the inlined handle_mm_fault function). Signed-off-by: Stelian Pop <[EMAIL PROTECTED]> Index: linux-2.6.git/mm/memory.c === --- linux-2.6.git.orig/mm/memory.c 2005-08-05 22:26:20.0 +0200 +++ linux-2.6.git/mm/memory.c 2005-08-05 23:46:49.0 +0200 @@ -2061,6 +2061,7 @@ spin_unlock(>page_table_lock); return VM_FAULT_OOM; } +EXPORT_SYMBOL(__handle_mm_fault); #ifndef __PAGETABLE_PUD_FOLDED /* -- Stelian Pop <[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: local DDOS? Kernel panic when accessing /proc/ioports
On Fri, Aug 05, 2005 at 12:50:56PM -0700, Chris Wright wrote: > * Martin Loschwitz ([EMAIL PROTECTED]) wrote: > > I just ran into the following problem: Having updated my box to 2.6.12.3, > > I tried to start YaST2 and noticed a kernel panic (see below). Some quick > > debugging brought the result that the kernel crashes while some user (not > > even root ...) tries to access /proc/ioports. Is this a known problem and > > if so, is a fix available? > > First I've heard of it. I can't trigger here with simple cat > /proc/ioports. Must be specific to your setup. What was the last > working kernel, and what's that ioport output look like? > The situation in this case is somewhat obscene ... Originally, I had exactly this problem while using the Knoppix standard kernel (2.6.11 vanilla SMP). I then went to compile 2.6.12.3, also with SMP, and it showed exactly the same problem. I disable SMP, tried again -- voila, it worked. The kernel that I am encountering this error again now is 2.6.12.3 -- without SMP or whatsoever. I'm just out of ideas on how to fix it this time. > thanks, > -chris -- .''`. Martin Loschwitz Debian GNU/Linux developer : :' : [EMAIL PROTECTED][EMAIL PROTECTED] `. `'` http://www.madkiss.org/people.debian.org/~madkiss/ `- Use Debian GNU/Linux 3.0! See http://www.debian.org/ signature.asc Description: Digital signature
Re: [PATCH] netpoll can lock up on low memory.
> > If that was the policy it would be a quite dumb one and make netpoll > > totally unsuitable for production use. I hope it is not. > > Suggest you rip __GFP_NOFAIL out of JBD before complaining about this. So you're suggesting we should become as bad at handling networking errors as we are at handling IO errors? > > Dave, can you please apply the timeout patch anyways? > > Yes, let's go right over the maintainer's objections almost > immediately after he chimes into the thread. I'll spare the list the > colorful language this inspires. Sure when the maintainer has a unreasonable position on something I think that's justified. Yours in this case is clearly unreasonable. -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: [PATCH] VM: add vm.free_node_memory sysctl
On Fri, Aug 05, 2005 at 12:45:58PM -0500, Ray Bryant wrote: > > try_to_free_pages should DTRT. That is because we generated a custom zone > > list only containing nodes in that zone and the zone reclaim only looks > > into those. > > > > It may depend on what your definition of DTRT is here. :-) > > As I understand things, if we have a node that has some mapped memory > allocated, and if one starts up a numactl -bind node memhog nodesize-slop so > as to clear some clean page cache pages from that node, then unless the > "slop" is sized in proportion to the amount of mapped memory used on the > node, then the existing mapped memory will get swapped out in order to > satisfy the new request. In addition, clean page-cache pages will get The VM should first eat clean pages, but yes at some point it will swap if you want enough. It has to because it doesn't know how to migrate to other nodes. > discarded. I think what Martin and I would prefer to see is an interface > that allows one to just get rid of the clean page cache (or at least enough > of it) so that additional mapped page allocations will occur locally to the > node without causing swapping. That seems like a very special narrow case. But have you tried if memhog really doesn't work this way? > > AFAIK, the number of mapped pages on the node is not exported to user space > (by, for example, /sys). So there is no good way to size the "slop" to > allow for an existing allocation. If there was, then using a bound memory > hog would likely be a reasonable replacement for Martin's syscall to release > all free page cache, at least for small to medium sized sized systems. I guess it could be exported without too much trouble. > The reason we ended up with a sysctl/syscall (to control the aggressiveness > with which __alloc_pages will try to free page cache before spilling) is that > deciding whether or not to spend the effort to free up page cache pages on > the local node before spilling is a workload dependent optimization. For > an HPC application it is typically worth the effort to try to free local > node page cache before spilling off node because the program will run > sufficiently long to make the improvement due to getting local storage > dominates the extra cost of doing the page allocation. For file server > workloads, for example, it is typically important to minimize the time to do > the page allocation; if it turns out to be on a remote node it really doesn't > matter that much. So it seems to me that we need some way for the > application to tell the system which approach it prefers based on the type of > workload it is -- hence the sysctl or syscall approach. Ideally it should just work transparently. Maybe NUMA allocation should be a bit more aggressive at cleaning local pages before fallback. Problem is that it potentially makes the fast path slow. -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: local DDOS? Kernel panic when accessing /proc/ioports
On Fri, Aug 05, 2005 at 03:40:26PM -0400, linux-os (Dick Johnson) wrote: > > On Fri, 5 Aug 2005, Martin Loschwitz wrote: > > > Hi folks, > > > > I just ran into the following problem: Having updated my box to 2.6.12.3, > > I tried to start YaST2 and noticed a kernel panic (see below). Some quick > > debugging brought the result that the kernel crashes while some user (not > > even root ...) tries to access /proc/ioports. Is this a known problem and > > if so, is a fix available? > > > > Ooops and ksymoops-output is attached. > > > > This can happen if a module is unloaded that doesn't free its > resources! Been there, done that. > "This can happen" is not an acceptable explanation, I think. Modules should not be able to kill the kernel -- apart from that, I can trigger the bug in the very early "ash-system" that KNOPPIX provides. At that time, the modules listed below were the only ones loaded -- no others, and I am also sure that until that point, no modules were unloaded. sbp2 ohci1394 usb_storage ub ehci_hcd usbcore -- .''`. Martin Loschwitz Debian GNU/Linux developer : :' : [EMAIL PROTECTED][EMAIL PROTECTED] `. `'` http://www.madkiss.org/people.debian.org/~madkiss/ `- Use Debian GNU/Linux 3.0! See http://www.debian.org/ signature.asc Description: Digital signature
Re: [PATCH] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 11:26:10PM +0200, Andi Kleen wrote: > On Fri, Aug 05, 2005 at 01:01:57PM -0700, Matt Mackall wrote: > > The netpoll philosophy is to assume that its traffic is an absolute > > priority - it is better to potentially hang trying to deliver a panic > > message than to give up and crash silently. > > That would be ok if netpoll was only used to deliver panics. But > it is not. It delivers all messages, and you cannot hang the > kernel during that. Actually even for panics it is wrong, because often > it is more important to reboot in a panic than (with a panic timeout) > to actually deliver the panic. That's needed e.g. in a failover cluster. > > If that was the policy it would be a quite dumb one and make netpoll > totally unsuitable for production use. I hope it is not. Suggest you rip __GFP_NOFAIL out of JBD before complaining about this. > Dave, can you please apply the timeout patch anyways? Yes, let's go right over the maintainer's objections almost immediately after he chimes into the thread. I'll spare the list the colorful language this inspires. -- Mathematics is the supreme nostalgia of our time. - 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: [RFC] Demand faulting for large pages
On Fri, Aug 05, 2005 at 02:05:42PM -0700, Chen, Kenneth W wrote: > Adam Litke wrote on Friday, August 05, 2005 8:22 AM > > Below is a patch to implement demand faulting for huge pages. The main > > motivation for changing from prefaulting to demand faulting is so that > > huge page allocations can follow the NUMA API. Currently, huge pages > > are allocated round-robin from all NUMA nodes. > > Do users of hugetlb going to accept the fact that now app will SIGBUS > when there aren't enough free hugetlb pages present at the time of fault? > It's not very nice though, but is that the general consensus? Probably not. But the simple minded overcommit check at mapping that was in the earlier SLES codebase seemed to work for people (or at least I've never heard a complaint about that). Adding that should be pretty easy. -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: [2.6 patch] remove support for gcc < 3.2
On Fri, 2005-08-05 23:30:04 +0200, Martin Drab <[EMAIL PROTECTED]> wrote: > > init/main.c:212: error: __setup_str_quiet_kernel causes a section type > > conflict > > init/main.c:220: error: __setup_str_loglevel causes a section type conflict > > init/main.c:298: error: __setup_str_init_setup causes a section type > > conflict > > init/main.c:543: error: __setup_str_initcall_debug_setup causes a section > > type conflict > > make[1]: *** [init/main.o] Error 1 > > make: *** [init] Error 2 > > I guess kernel may not yet be ready to be compiled by the latest CVS GCC > 4.1.x (currently HEAD). But it should (at least works for me) do the > latest CVS GCC 4.0.x. As I worte previously, I now again do regular compile runs with gcc-HEAD for the VAX port and it works. ...but only, if -fno-unit-at-a-time is supplied. So I actually suspect two bugs: one in the kernel's sources (missing "const" or rw/ro attributes) and -fno-unit-at-a-time disables some gcc-internal tests that should have fired. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
RE: [RFC] Demand faulting for large pages
Adam Litke wrote on Friday, August 05, 2005 8:22 AM
> +int hugetlb_pte_fault(struct mm_struct *mm, struct vm_area_struct *vma,
> + unsigned long address, int write_access)
> +{
> + int ret = VM_FAULT_MINOR;
> + unsigned long idx;
> + pte_t *pte;
> + struct page *page;
> + struct address_space *mapping;
> +
> + WARN_ON(!is_vm_hugetlb_page(vma));
Spurious WARN_ON. Calls to hugetlb_pte_fault() is conditioned upon
if (is_vm_hugetlb_page(vma))
> +int hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
> + unsigned long address, int write_access)
> +{
> +
> + if (pte_none(*ptep))
> + rc = hugetlb_pte_fault(mm, vma, address, write_access);
> +}
Broken here. Return VM_FAULT_SIGBUS when *pte is present?? Why
can't you move all the logic into hugetlb_pte_fault and simply call
it directly from handle_mm_fault?
-
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] use bus_slot number for name
On Fri, Aug 05, 2005 at 03:51:23PM -0400, Dave Jones wrote:
> On Fri, Aug 05, 2005 at 12:16:06PM -0700, Kristen Accardi wrote:
> > For systems with multiple hotplug controllers, you need to use more than
> > just the slot number to uniquely name the slot. Without a unique slot
> > name, the pci_hp_register() will fail. This patch adds the bus number
> > to the name.
> >
> > Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
> >
> > diff -uprN -X linux-2.6.13-rc4/Documentation/dontdiff
> linux-2.6.13-rc4/drivers/pci/hotplug/pciehp.h
> linux-2.6.13-rc4-shpchp-slot-name-fix/drivers/pci/hotplug/pciehp.h
> > --- linux-2.6.13-rc4/drivers/pci/hotplug/pciehp.h 2005-07-28
> 15:44:44.0 -0700
> > +++ linux-2.6.13-rc4-shpchp-slot-name-fix/drivers/pci/hotplug/pciehp.h
> 2005-08-04 17:57:18.0 -0700
> > @@ -302,7 +302,7 @@ static inline void return_resource(struc
> >
> > static inline void make_slot_name(char *buffer, int buffer_size, struct
> slot *slot)
> > {
> > - snprintf(buffer, buffer_size, "%d", slot->number);
> > + snprintf(buffer, buffer_size, "%04d_%04d", slot->bus, slot->number);
> > }
>
> Won't using..
>
> snprintf(buffer, buffer_size, "%s", pci_name(slot));
As Kristen already said, a slot could refer to multiple pci_dev devices,
so I don't know how well this would really work out.
Although you might want to put the domain in that name, if known, as
large boxes might need that, right?
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] use bus_slot number for name
On Fri, 2005-08-05 at 15:51 -0400, Dave Jones wrote:
> On Fri, Aug 05, 2005 at 12:16:06PM -0700, Kristen Accardi wrote:
> > For systems with multiple hotplug controllers, you need to use more than
> > just the slot number to uniquely name the slot. Without a unique slot
> > name, the pci_hp_register() will fail. This patch adds the bus number
> > to the name.
> >
> > Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
> >
> > diff -uprN -X linux-2.6.13-rc4/Documentation/dontdiff
> linux-2.6.13-rc4/drivers/pci/hotplug/pciehp.h
> linux-2.6.13-rc4-shpchp-slot-name-fix/drivers/pci/hotplug/pciehp.h
> > --- linux-2.6.13-rc4/drivers/pci/hotplug/pciehp.h 2005-07-28
> 15:44:44.0 -0700
> > +++ linux-2.6.13-rc4-shpchp-slot-name-fix/drivers/pci/hotplug/pciehp.h
> 2005-08-04 17:57:18.0 -0700
> > @@ -302,7 +302,7 @@ static inline void return_resource(struc
> >
> > static inline void make_slot_name(char *buffer, int buffer_size, struct
> slot *slot)
> > {
> > - snprintf(buffer, buffer_size, "%d", slot->number);
> > + snprintf(buffer, buffer_size, "%04d_%04d", slot->bus, slot->number);
> > }
>
> Won't using..
>
> snprintf(buffer, buffer_size, "%s", pci_name(slot));
>
> work equally as well, and also future-proof this ?
>
> Dave
What do you think of this patch - it is basically what you asked for
except that I moved the functionality up to pci_hotplug.h so that all
drivers can use the same nameing convention if they feel like it.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
diff -uprN -X linux-2.6.13-rc4/Documentation/dontdiff
linux-2.6.13-rc4/drivers/pci/hotplug/pciehp_core.c
linux-2.6.13-rc4-shpchp-slot-name-fix/drivers/pci/hotplug/pciehp_core.c
--- linux-2.6.13-rc4/drivers/pci/hotplug/pciehp_core.c 2005-07-28
15:44:44.0 -0700
+++ linux-2.6.13-rc4-shpchp-slot-name-fix/drivers/pci/hotplug/pciehp_core.c
2005-08-05 14:15:09.0 -0700
@@ -140,7 +140,7 @@ static int init_slots(struct controller
goto error_hpslot;
memset(new_slot->hotplug_slot->info, 0,
sizeof(struct hotplug_slot_info));
- new_slot->hotplug_slot->name = kmalloc(SLOT_NAME_SIZE,
+ new_slot->hotplug_slot->name = kmalloc(HPSLOT_NAME_SIZE,
GFP_KERNEL);
if (!new_slot->hotplug_slot->name)
goto error_info;
@@ -156,7 +156,7 @@ static int init_slots(struct controller
/* register this slot with the hotplug pci core */
new_slot->hotplug_slot->private = new_slot;
new_slot->hotplug_slot->release = _slot;
- make_slot_name(new_slot->hotplug_slot->name, SLOT_NAME_SIZE,
new_slot);
+ pci_hp_make_slot_name(new_slot->hotplug_slot, ctrl->pci_dev);
new_slot->hotplug_slot->ops = _hotplug_slot_ops;
new_slot->hpc_ops->get_power_status(new_slot,
&(new_slot->hotplug_slot->info->power_status));
diff -uprN -X linux-2.6.13-rc4/Documentation/dontdiff
linux-2.6.13-rc4/drivers/pci/hotplug/pciehp.h
linux-2.6.13-rc4-shpchp-slot-name-fix/drivers/pci/hotplug/pciehp.h
--- linux-2.6.13-rc4/drivers/pci/hotplug/pciehp.h 2005-07-28
15:44:44.0 -0700
+++ linux-2.6.13-rc4-shpchp-slot-name-fix/drivers/pci/hotplug/pciehp.h
2005-08-05 14:14:54.0 -0700
@@ -298,12 +298,6 @@ static inline void return_resource(struc
*head = node;
}
-#define SLOT_NAME_SIZE 10
-
-static inline void make_slot_name(char *buffer, int buffer_size, struct slot
*slot)
-{
- snprintf(buffer, buffer_size, "%d", slot->number);
-}
enum php_ctlr_type {
PCI,
diff -uprN -X linux-2.6.13-rc4/Documentation/dontdiff
linux-2.6.13-rc4/drivers/pci/hotplug/pci_hotplug.h
linux-2.6.13-rc4-shpchp-slot-name-fix/drivers/pci/hotplug/pci_hotplug.h
--- linux-2.6.13-rc4/drivers/pci/hotplug/pci_hotplug.h 2005-07-28
15:44:44.0 -0700
+++ linux-2.6.13-rc4-shpchp-slot-name-fix/drivers/pci/hotplug/pci_hotplug.h
2005-08-05 14:21:45.0 -0700
@@ -170,6 +170,12 @@ struct hotplug_slot {
};
#define to_hotplug_slot(n) container_of(n, struct hotplug_slot, kobj)
+#define HPSLOT_NAME_SIZE BUS_ID_SIZE
+static inline void pci_hp_make_slot_name(struct hotplug_slot *hpslot, struct
pci_dev *pdev)
+{
+ snprintf(hpslot->name, HPSLOT_NAME_SIZE, "%s", pci_name(pdev));
+}
+
extern int pci_hp_register (struct hotplug_slot *slot);
extern int pci_hp_deregister (struct hotplug_slot *slot);
extern int pci_hp_change_slot_info (struct hotplug_slot *slot,
diff -uprN -X linux-2.6.13-rc4/Documentation/dontdiff
linux-2.6.13-rc4/drivers/pci/hotplug/shpchp_core.c
linux-2.6.13-rc4-shpchp-slot-name-fix/drivers/pci/hotplug/shpchp_core.c
--- linux-2.6.13-rc4/drivers/pci/hotplug/shpchp_core.c 2005-07-28
15:44:44.0 -0700
+++
Re: [2.6 patch] remove support for gcc < 3.2
On Fri, 5 Aug 2005, Jan-Benedict Glaw wrote: > On Thu, 2005-08-04 22:38:31 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > On Thu, Aug 04, 2005 at 08:54:47AM +0200, Jan-Benedict Glaw wrote: > > >... > > > Current GCC from CVS (plus minor configury patches) seems to work. We > > > had -fno-unit-at-a-time missing in our arch Makefile which hides a bug > > > in kernel's sources. > > > > > > I guess that if you remove -fno-unit-at-a-time from i386 and use a > > > current GCC, you'll run into that fun, too. > > > > What bug exactly? > > -fno-unit-at-a-time grounded: > > [EMAIL PROTECTED]:~/test_gcc/linux-2.6.13-rc5-git3$ grep fno-unit-at > arch/i386/Makefile > # CFLAGS += $(call cc-option,-fno-unit-at-a-time) > > For presenting it, I built a gcc right from CVS: > > [EMAIL PROTECTED]:~/test_gcc/linux-2.6.13-rc5-git3$ i486-linux-gcc -v > Using built-in specs. > Target: i486-linux > Configured with: > /home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/src/gcc/configure > --disable-multilib --with-newlib --disable-nls --enable-threads=no > --disable-threads --enable-symvers=gnu --enable-__cxa_atexit --disable-shared > --target=i486-linux > --prefix=/home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/install/usr > --enable-languages=c > Thread model: single > gcc version 4.1.0 20050802 (experimental) > > ...and here you can see it explode even on i386: > > [EMAIL PROTECTED]:~/test_gcc/linux-2.6.13-rc5-git3$ make CC=i486-linux-gcc > V=1 bzImage > [...] > CHK include/asm-i386/asm_offsets.h > make -f scripts/Makefile.build obj=init > i486-linux-gcc -Wp,-MD,init/.main.o.d -nostdinc -isystem > /home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/install/usr/lib/gcc/i486-linux/4.1.0/include > -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs > -fno-strict-aliasing -fno-common -ffreestanding -O2 -fomit-frame-pointer > -pipe -msoft-float -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium4 > -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement > -Wno-pointer-sign-DKBUILD_BASENAME=main -DKBUILD_MODNAME=main -c -o > init/main.o init/main.c > init/main.c:415: error: tmp_cmdline causes a section type conflict > init/main.c:414: error: done causes a section type conflict > init/main.c:536: error: initcall_debug causes a section type conflict > include/asm/bugs.h:35: error: __setup_str_no_halt causes a section type > conflict > include/asm/bugs.h:43: error: __setup_str_mca_pentium causes a section type > conflict > include/asm/bugs.h:52: error: __setup_str_no_387 causes a section type > conflict > init/main.c:146: error: __setup_str_nosmp causes a section type conflict > init/main.c:154: error: __setup_str_maxcpus causes a section type conflict > init/main.c:211: error: __setup_str_debug_kernel causes a section type > conflict > init/main.c:212: error: __setup_str_quiet_kernel causes a section type > conflict > init/main.c:220: error: __setup_str_loglevel causes a section type conflict > init/main.c:298: error: __setup_str_init_setup causes a section type conflict > init/main.c:543: error: __setup_str_initcall_debug_setup causes a section > type conflict > make[1]: *** [init/main.o] Error 1 > make: *** [init] Error 2 I guess kernel may not yet be ready to be compiled by the latest CVS GCC 4.1.x (currently HEAD). But it should (at least works for me) do the latest CVS GCC 4.0.x. Martin - 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] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 04:57:00PM -0400, Steven Rostedt wrote: > On Fri, 2005-08-05 at 13:01 -0700, Matt Mackall wrote: > > On Fri, Aug 05, 2005 at 10:36:31AM -0400, Steven Rostedt wrote: > > > Looking at the netpoll routines, I noticed that the find_skb could > > > lockup if the memory is low. This is because the allocations are > > > called with GFP_ATOMIC (since this is in interrupt context) and if > > > it fails, it will continue to fail. This is just by observing the > > > code, I didn't have this actually happen. So if this is not the > > > case, please let me know how it can get out. Otherwise, please > > > accept this patch. > > > > By netpoll_poll() tickling the driver enough to free the currently > > queued outgoing SKBs. > > I believe that the e1000 wont free up any outgoing packets since the > netpoll call doesn't seem to get to the e1000_clean_tx part of the > e1000_intr, otherwise the system wouldn't lock under the > netpoll_send_skb when one disconnects the wire and puts it back in. The > disconnect would lock it up anyway (with Andi's patch it now doesn't) > but since it won't come back up after the link is back up, there seems > to be something wrong with the e1000 netpoll driver. This is because > the e1000_netpoll doesn't seem to be cleaning up the tx buffer and start > the queue back up. That does seem like a driver problem. > > Also note that by the time we're in this loop, we're ready to take > > desperate measures. We've already exhausted our private queue of SKBs > > so we have no alternative but to keep kicking the driver until > > something happens. > > OK, the system is under heavy memory load and starts eating up the > netpoll packets. When the last packet is gone, and you have something > like the e1000 that doesn't clean up its packets with netpoll, then you > just locked up the system. > > The scary part of this loop is that if the netpoll doesn't come up with > the goods, its game over. Say we are at desperate measures but it could > be a case where we need to output more information and lockup here > before we can go out and free some memory. Realistically, we were probably going to crash anyway at this point as we're apparently failing to recycle SKBs. Netpoll generally must assume it won't get a second chance, as it's being called by things like oops() and panic() and used by things like kgdb. If netpoll fails, the box is dead anyway. > > The netpoll philosophy is to assume that its traffic is an absolute > > priority - it is better to potentially hang trying to deliver a panic > > message than to give up and crash silently. > > So even a long timeout would not do? So you don't even get a message to > the console? In general, there's no way to measure time here. And if we're using netconsole, what makes you think there's any other console? > > > Also, as Andi told me, the printk here would probably not show up > > > anyway if this happens with netconsole. > > > > That's fine. But in fact, it does show up occassionally - I've seen > > it. > > Then maybe what Andi told me is not true ;-) > > Oh, and did your machine crash when you saw it? Have you seen it with > the e1000 driver? No and no. Most of my own testing is done with tg3. -- Mathematics is the supreme nostalgia of our time. - 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] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 01:01:57PM -0700, Matt Mackall wrote: > The netpoll philosophy is to assume that its traffic is an absolute > priority - it is better to potentially hang trying to deliver a panic > message than to give up and crash silently. That would be ok if netpoll was only used to deliver panics. But it is not. It delivers all messages, and you cannot hang the kernel during that. Actually even for panics it is wrong, because often it is more important to reboot in a panic than (with a panic timeout) to actually deliver the panic. That's needed e.g. in a failover cluster. If that was the policy it would be a quite dumb one and make netpoll totally unsuitable for production use. I hope it is not. > > > Also, as Andi told me, the printk here would probably not show up > > anyway if this happens with netconsole. > > That's fine. But in fact, it does show up occassionally - I've seen > it. > > NAK'ed. Too bad. This would mean that all serious non toy users of netpoll would have to carry this patch on their own. But that wouldn't be good. Dave, can you please apply the timeout patch anyways? I suspect Steven's patch for the e1000 is needed in addition to handle different cases too. -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: Linux 2.6.12.4
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 12
-EXTRAVERSION = .3
+EXTRAVERSION = .4
NAME=Woozy Numbat
# *DOCUMENTATION*
@@ -1149,7 +1149,7 @@ endif # KBUILD_EXTMOD
#(which is the most common case IMHO) to avoid unneeded clutter in the big
tags file.
#Adding $(srctree) adds about 20M on i386 to the size of the output file!
-ifeq ($(KBUILD_OUTPUT),)
+ifeq ($(src),$(obj))
__srctree =
else
__srctree = $(srctree)/
diff --git a/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
b/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
--- a/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
+++ b/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
@@ -44,7 +44,7 @@
#define PFX "powernow-k8: "
#define BFX PFX "BIOS error: "
-#define VERSION "version 1.40.2"
+#define VERSION "version 1.40.4"
#include "powernow-k8.h"
/* serialize freq changes */
@@ -978,7 +978,7 @@ static int __init powernowk8_cpu_init(st
{
struct powernow_k8_data *data;
cpumask_t oldmask = CPU_MASK_ALL;
- int rc;
+ int rc, i;
if (!check_supported_cpu(pol->cpu))
return -ENODEV;
@@ -1064,7 +1064,9 @@ static int __init powernowk8_cpu_init(st
printk("cpu_init done, current fid 0x%x, vid 0x%x\n",
data->currfid, data->currvid);
- powernow_data[pol->cpu] = data;
+ for_each_cpu_mask(i, cpu_core_map[pol->cpu]) {
+ powernow_data[i] = data;
+ }
return 0;
diff --git a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
--- a/arch/i386/kernel/process.c
+++ b/arch/i386/kernel/process.c
@@ -827,6 +827,8 @@ asmlinkage int sys_get_thread_area(struc
if (idx < GDT_ENTRY_TLS_MIN || idx > GDT_ENTRY_TLS_MAX)
return -EINVAL;
+ memset(, 0, sizeof(info));
+
desc = current->thread.tls_array + idx - GDT_ENTRY_TLS_MIN;
info.entry_number = idx;
diff --git a/arch/x86_64/ia32/syscall32.c b/arch/x86_64/ia32/syscall32.c
--- a/arch/x86_64/ia32/syscall32.c
+++ b/arch/x86_64/ia32/syscall32.c
@@ -57,6 +57,7 @@ int syscall32_setup_pages(struct linux_b
int npages = (VSYSCALL32_END - VSYSCALL32_BASE) >> PAGE_SHIFT;
struct vm_area_struct *vma;
struct mm_struct *mm = current->mm;
+ int ret;
vma = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
if (!vma)
@@ -78,7 +79,11 @@ int syscall32_setup_pages(struct linux_b
vma->vm_mm = mm;
down_write(>mmap_sem);
- insert_vm_struct(mm, vma);
+ if ((ret = insert_vm_struct(mm, vma))) {
+ up_write(>mmap_sem);
+ kmem_cache_free(vm_area_cachep, vma);
+ return ret;
+ }
mm->total_vm += npages;
up_write(>mmap_sem);
return 0;
diff --git a/drivers/char/rocket.c b/drivers/char/rocket.c
--- a/drivers/char/rocket.c
+++ b/drivers/char/rocket.c
@@ -277,7 +277,7 @@ static void rp_do_receive(struct r_port
ToRecv = space;
if (ToRecv <= 0)
- return;
+ goto done;
/*
* if status indicates there are errored characters in the
@@ -359,6 +359,7 @@ static void rp_do_receive(struct r_port
}
/* Push the data up to the tty layer */
ld->receive_buf(tty, tty->flip.char_buf, tty->flip.flag_buf, count);
+done:
tty_ldisc_deref(ld);
}
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -1914,9 +1914,11 @@ qla2x00_reg_remote_port(scsi_qla_host_t
rport_ids.roles |= FC_RPORT_ROLE_FCP_TARGET;
fcport->rport = rport = fc_remote_port_add(ha->host, 0, _ids);
- if (!rport)
+ if (!rport) {
qla_printk(KERN_WARNING, ha,
"Unable to allocate fc remote port!\n");
+ return;
+ }
if (rport->scsi_target_id != -1 && rport->scsi_target_id < MAX_TARGETS)
fcport->os_target_id = rport->scsi_target_id;
diff --git a/fs/bio.c b/fs/bio.c
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -261,6 +261,7 @@ inline void __bio_clone(struct bio *bio,
*/
bio->bi_vcnt = bio_src->bi_vcnt;
bio->bi_size = bio_src->bi_size;
+ bio->bi_idx = bio_src->bi_idx;
bio_phys_segments(q, bio);
bio_hw_segments(q, bio);
}
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1192,7 +1192,7 @@ static inline void *skb_header_pointer(c
{
int hlen = skb_headlen(skb);
- if (offset + len <= hlen)
+ if (hlen - offset >= len)
return skb->data + offset;
if (skb_copy_bits(skb, offset, buffer, len) < 0)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -578,6 +578,14 @@ static int vlan_device_event(struct noti
if
Linux 2.6.12.4
We (the -stable team) are announcing the release of the 2.6.12.4 kernel. The diffstat and short summary of the fixes are below. I'll also be replying to this message with a copy of the patch between 2.6.12.3 and 2.6.12.4, as it is small enough to do so. The updated 2.6.12.y git tree can be found at: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git and can be browsed at the normal kernel.org git web browser: www.kernel.org/git/ thanks, -chris -- Makefile |4 ++-- arch/i386/kernel/cpu/cpufreq/powernow-k8.c |8 +--- arch/i386/kernel/process.c |2 ++ arch/x86_64/ia32/syscall32.c |7 ++- drivers/char/rocket.c |3 ++- drivers/scsi/qla2xxx/qla_init.c|4 +++- fs/bio.c |1 + include/linux/skbuff.h |2 +- net/8021q/vlan.c |8 net/ipv4/netfilter/ip_conntrack_core.c |3 +++ net/ipv4/netfilter/ip_nat_proto_tcp.c |3 ++- net/ipv4/netfilter/ip_nat_proto_udp.c |3 ++- net/ipv6/netfilter/ip6_queue.c |2 ++ net/xfrm/xfrm_user.c |3 +++ 14 files changed, 42 insertions(+), 11 deletions(-) Summary of changes from v2.6.12.3 to v2.6.12.4 == Andrew Morton: Fw: bio_clone fix Andrew Vasquez: qla2xxx: Correct handling of fc_remote_port_add() failure case. Chris Wright: Linux 2.6.12.4 Dave Jones: Fix powernow oops on dual-core athlon Herbert Xu: Fix possible overflow of sock->sk_policy Michal Ostrowski: rocket.c: Fix ldisc ref count handling Paolo 'Blaisorblade' Giarrusso: sys_get_thread_area does not clear the returned argument Patrick McHardy: Wait until all references to ip_conntrack_untracked are dropped on unload Fix potential memory corruption in NAT code (aka memory NAT) Fix deadlock in ip6_queue Fix signedness issues in net/core/filter.c Siddha, Suresh B: x86_64 memleak from malicious 32bit elf program Tom Rini: kbuild: build TAGS problem with O= Tommy Christensen: Fix early vlan adding leads to not functional device - To unsubscribe from this list: send the line "unsubscribe linux-kernel-announce" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] remove support for gcc < 3.2
On Thu, 2005-08-04 22:38:31 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Thu, Aug 04, 2005 at 08:54:47AM +0200, Jan-Benedict Glaw wrote: > >... > > Current GCC from CVS (plus minor configury patches) seems to work. We > > had -fno-unit-at-a-time missing in our arch Makefile which hides a bug > > in kernel's sources. > > > > I guess that if you remove -fno-unit-at-a-time from i386 and use a > > current GCC, you'll run into that fun, too. > > What bug exactly? -fno-unit-at-a-time grounded: [EMAIL PROTECTED]:~/test_gcc/linux-2.6.13-rc5-git3$ grep fno-unit-at arch/i386/Makefile # CFLAGS += $(call cc-option,-fno-unit-at-a-time) For presenting it, I built a gcc right from CVS: [EMAIL PROTECTED]:~/test_gcc/linux-2.6.13-rc5-git3$ i486-linux-gcc -v Using built-in specs. Target: i486-linux Configured with: /home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/src/gcc/configure --disable-multilib --with-newlib --disable-nls --enable-threads=no --disable-threads --enable-symvers=gnu --enable-__cxa_atexit --disable-shared --target=i486-linux --prefix=/home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/install/usr --enable-languages=c Thread model: single gcc version 4.1.0 20050802 (experimental) ...and here you can see it explode even on i386: [EMAIL PROTECTED]:~/test_gcc/linux-2.6.13-rc5-git3$ make CC=i486-linux-gcc V=1 bzImage [...] CHK include/asm-i386/asm_offsets.h make -f scripts/Makefile.build obj=init i486-linux-gcc -Wp,-MD,init/.main.o.d -nostdinc -isystem /home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/install/usr/lib/gcc/i486-linux/4.1.0/include -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O2 -fomit-frame-pointer -pipe -msoft-float -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium4 -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement -Wno-pointer-sign -DKBUILD_BASENAME=main -DKBUILD_MODNAME=main -c -o init/main.o init/main.c init/main.c:415: error: tmp_cmdline causes a section type conflict init/main.c:414: error: done causes a section type conflict init/main.c:536: error: initcall_debug causes a section type conflict include/asm/bugs.h:35: error: __setup_str_no_halt causes a section type conflict include/asm/bugs.h:43: error: __setup_str_mca_pentium causes a section type conflict include/asm/bugs.h:52: error: __setup_str_no_387 causes a section type conflict init/main.c:146: error: __setup_str_nosmp causes a section type conflict init/main.c:154: error: __setup_str_maxcpus causes a section type conflict init/main.c:211: error: __setup_str_debug_kernel causes a section type conflict init/main.c:212: error: __setup_str_quiet_kernel causes a section type conflict init/main.c:220: error: __setup_str_loglevel causes a section type conflict init/main.c:298: error: __setup_str_init_setup causes a section type conflict init/main.c:543: error: __setup_str_initcall_debug_setup causes a section type conflict make[1]: *** [init/main.o] Error 1 make: *** [init] Error 2 MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
RE: [RFC] Demand faulting for large pages
Adam Litke wrote on Friday, August 05, 2005 8:22 AM > Below is a patch to implement demand faulting for huge pages. The main > motivation for changing from prefaulting to demand faulting is so that > huge page allocations can follow the NUMA API. Currently, huge pages > are allocated round-robin from all NUMA nodes. Do users of hugetlb going to accept the fact that now app will SIGBUS when there aren't enough free hugetlb pages present at the time of fault? It's not very nice though, but is that the general consensus? - 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/
