Zachary Amsden wrote:
Chris Wright wrote:
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
perfor
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
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 mos
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 h
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 3
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
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
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
>
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
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 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 ~995
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 [
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, bu
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
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
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.ko
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 no
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 te
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
c
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,
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 th
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 ht
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_DM
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
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(&pgd_lock, flags);
- memcpy((pgd_t *)pgd + USER_PTRS_PER_PGD,
+ clone_pgd_range((pgd_t *)p
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
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
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 wh
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'
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 sugges
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> + memset(pgd, 0, USER_PTRS_PER_PGD*sizeof(pgd_t));
> if (PTRS_PER_PMD == 1)
> spin_lock_irqsave(&pgd_lock, flags);
>
> - memcpy((pgd_t *)pgd + USER_PTRS_PER_PGD,
> + clone_pgd_range((pgd_t *)pgd + USER_PTRS_PER_PGD,
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]
> >
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
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 ex
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 "unsubsc
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(&count,...);
>
> ptr = kmalloc(sizeof(struct foo) * count);
>
> if (!ptr)
>
[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 `
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.6915
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 th
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 hyper
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
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
* 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
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 inter
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 di
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 r
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 g
> 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
* 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 abl
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.
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
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 suspici
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 h
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 show
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
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_doma
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 dow
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 loo
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 n
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
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_LI
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(&quirk->list);
> > > + quirk->dev = dev;
> > > + list_add(&qui
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
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.ke
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 fai
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
On Fri, 2005-08-05 at 15:26 -0700, Andrew Morton wrote:
> Kristen Accardi <[EMAIL PROTECTED]> wrote:
> > + if (!quirk)
> > + return -ENOMEM;
> > +
> > + INIT_LIST_HEAD(&quirk->list);
> > + quirk->dev = dev;
> > + list_add(&quirk->list, &msi_quirk_list);
> > + return 0;
> > +
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 neve
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'l
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 s
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 al
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 bec
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.
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 (c
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
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 thin
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 gca
> 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
l
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_S
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
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
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()
> 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
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 <[EMA
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
> > 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
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. :-)
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
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 a
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
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 cause
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 *
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
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_reg
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
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. Th
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 del
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 unneed
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
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
1 - 100 of 334 matches
Mail list logo
