[PATCH] lib: crc-itu-t: Fix typo in comment

Signed-off-by: David Mosberger-Tang --- lib/crc-itu-t.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/crc-itu-t.c b/lib/crc-itu-t.c index 1974b355c148..1d26a1647da5 100644 --- a/lib/crc-itu-t.c +++ b/lib/crc-itu-t.c @@ -7,7 +7,7 @@ #include #include -/** CRC table

[PATCH] lib: crc-itu-t: Fix comment in typo

Signed-off-by: David Mosberger-Tang --- lib/crc-itu-t.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/crc-itu-t.c b/lib/crc-itu-t.c index 1974b355c148..56e6e0d63d1e 100644 --- a/lib/crc-itu-t.c +++ b/lib/crc-itu-t.c @@ -7,7 +7,7 @@ #include #include -/** CRC table

[PATCH] drivers: nvmem: atmel-secumod: New driver for Atmel Secumod nvram

Signed-off-by: David Mosberger <dav...@egauge.net> --- .../devicetree/bindings/nvmem/atmel-secumod.txt| 47 +++ drivers/nvmem/Kconfig | 7 + drivers/nvmem/Makefile | 2 + drivers/nvmem/atmel-secumod.c

[PATCH] drivers: nvmem: atmel-secumod: New driver for Atmel Secumod nvram

Signed-off-by: David Mosberger --- .../devicetree/bindings/nvmem/atmel-secumod.txt| 47 +++ drivers/nvmem/Kconfig | 7 + drivers/nvmem/Makefile | 2 + drivers/nvmem/atmel-secumod.c | 143

Re: [PATCH] drivers: nvmem: atmel-secumod: New driver for Atmel Secumod nvram

Thanks for the feedback. Rob! I'll make the changes and resend the patch (which has now also been updated to work with linux-next).

Re: [PATCH] drivers: nvmem: atmel-secumod: New driver for Atmel Secumod nvram

Thanks for the feedback. Rob! I'll make the changes and resend the patch (which has now also been updated to work with linux-next).

[PATCH] drivers: nvmem: atmel-secumod: New driver for Atmel Secumod nvram

Signed-off-by: David Mosberger <dav...@egauge.net> --- .../devicetree/bindings/nvmem/atmel-secumod.txt| 46 drivers/nvmem/atmel-secumod.c | 125 + 2 files changed, 171 insertions(+) create mode 100644 Documentation/devicetree/bindings

[PATCH] drivers: nvmem: atmel-secumod: New driver for Atmel Secumod nvram

Signed-off-by: David Mosberger --- .../devicetree/bindings/nvmem/atmel-secumod.txt| 46 drivers/nvmem/atmel-secumod.c | 125 + 2 files changed, 171 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvmem/atmel-secumod.txt

Re: [PATCH] usb: host: max3421-hcd: use time_after()

Acked-by: David Mosberger On Mon, Dec 15, 2014 at 8:22 AM, Asaf Vertz wrote: > To be future-proof and for better readability the time comparisons are > modified to use time_after() instead of plain, error-prone math. > > Signed-off-by: Asaf Vertz > --- > drivers/usb/host/ma

Re: [PATCH] usb: host: max3421-hcd: use time_after()

Acked-by: David Mosberger dav...@egauge.net On Mon, Dec 15, 2014 at 8:22 AM, Asaf Vertz asaf.ve...@tandemg.com wrote: To be future-proof and for better readability the time comparisons are modified to use time_after() instead of plain, error-prone math. Signed-off-by: Asaf Vertz asaf.ve

Re: [PATCH] usb: host: max3421-hcd: unconditionally use GFP_ATOMIC in max3421_urb_enqueue()

-off-by: Alexey Khoroshilov Acked-by: David Mosberger > --- > drivers/usb/host/max3421-hcd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c > index 858efcfda50b..ed22424dbec7 100644 > --- a/dr

Re: [PATCH] usb: host: max3421-hcd: unconditionally use GFP_ATOMIC in max3421_urb_enqueue()

-by: Alexey Khoroshilov khoroshi...@ispras.ru Acked-by: David Mosberger dav...@egauge.net --- drivers/usb/host/max3421-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c index 858efcfda50b..ed22424dbec7 100644

Re: UBIFS recovery taking too long

Adrian, On Tue, Dec 10, 2013 at 12:25 AM, Adrian Hunter wrote: > Slowness is probably caused by trying to make free space. Was the file > system very full? A smaller journal might help. That's possible. We have not been able to reproduce the issue in house but a customer had it happen on

Re: UBIFS recovery taking too long

Adrian, On Tue, Dec 10, 2013 at 12:25 AM, Adrian Hunter adrian.hun...@intel.com wrote: Slowness is probably caused by trying to make free space. Was the file system very full? A smaller journal might help. That's possible. We have not been able to reproduce the issue in house but a

Fwd: UBIFS recovery taking too long

I've had no luck getting any response from the linux-mtd mailing list regarding the issue reported below. I think it is a very serious issue since it can easily render an embedded system unusable. --david -- Forwarded message -- From: David Mosberger-Tang Date: Thu, Nov 7

Fwd: UBIFS recovery taking too long

I've had no luck getting any response from the linux-mtd mailing list regarding the issue reported below. I think it is a very serious issue since it can easily render an embedded system unusable. --david -- Forwarded message -- From: David Mosberger-Tang dmosber...@gmail.com

Re: [patch 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

On 11/27/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Tue, 27 Nov 2007, David Mosberger-Tang wrote: > > > Uniformity for the sake of uniformity? The small data addressing is > > really elegant and I don't think it should be dropped just for the > > sake

Re: [patch 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

On 11/27/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Mon, 26 Nov 2007, David Mosberger-Tang wrote: > > > On 11/26/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: > > > The model(small) attribute is not supported by gcc 4.X. The tests > > > w

Re: [patch 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

On 11/27/07, Christoph Lameter [EMAIL PROTECTED] wrote: On Mon, 26 Nov 2007, David Mosberger-Tang wrote: On 11/26/07, Christoph Lameter [EMAIL PROTECTED] wrote: The model(small) attribute is not supported by gcc 4.X. The tests will always be negative today. What was the rationale

Re: [patch 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

On 11/27/07, Christoph Lameter [EMAIL PROTECTED] wrote: On Tue, 27 Nov 2007, David Mosberger-Tang wrote: Uniformity for the sake of uniformity? The small data addressing is really elegant and I don't think it should be dropped just for the sake of uniformity. Uniformity for the sake

Re: [patch 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

On 11/26/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: > The model(small) attribute is not supported by gcc 4.X. The tests > will always be negative today. What was the rationale for removing this attribute? --david - To unsubscribe from this list: send the line "unsubscribe linux-kernel"

Re: [patch 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

On 11/26/07, Christoph Lameter [EMAIL PROTECTED] wrote: The model(small) attribute is not supported by gcc 4.X. The tests will always be negative today. What was the rationale for removing this attribute? --david - To unsubscribe from this list: send the line unsubscribe linux-kernel in the

Re: [PATCH] flush icache before set_pte() on ia64 take9 [2/2] flush icache at set_pte

aining task is to convince myself that this > new version covers all the cases. What about code-size? Also, is it OK to call a function from all places where a set_pte() is being done? I'd hope so, but it's a really low-level operation... --david -- Mosberger Consulting LLC, http://www.mos

Re: [PATCH] flush icache before set_pte() on ia64 take9 [2/2] flush icache at set_pte

the cases. What about code-size? Also, is it OK to call a function from all places where a set_pte() is being done? I'd hope so, but it's a really low-level operation... --david -- Mosberger Consulting LLC, http://www.mosberger-consulting.com/ - To unsubscribe from this list: send the line

Re: [PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

On 8/1/07, Zoltan Menyhart <[EMAIL PROTECTED]> wrote: > You do have model specific I cache semantics. > Not taking it into account will oblige you to flush in vain for the models > which do not require it. Why do you want to take this option? Given unlimited resources, your proposal makes

Re: [PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

On 8/1/07, Zoltan Menyhart [EMAIL PROTECTED] wrote: You do have model specific I cache semantics. Not taking it into account will oblige you to flush in vain for the models which do not require it. Why do you want to take this option? Given unlimited resources, your proposal makes perfect

Re: [PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

This seems crazy to me. Flushing should occur according to the *architecture*, not model-by-model. Even if we happen to get "lucky" on pre-Montecito CPUs, that doesn't justify such ugly hacks. Or you really want to debug this *again* come next CPU? --david On 7/30/07, KAMEZAWA Hiroyuki

Re: [PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

This seems crazy to me. Flushing should occur according to the *architecture*, not model-by-model. Even if we happen to get lucky on pre-Montecito CPUs, that doesn't justify such ugly hacks. Or you really want to debug this *again* come next CPU? --david On 7/30/07, KAMEZAWA Hiroyuki [EMAIL

Re: Fw: [PATCH] ia64: race flushing icache in do_no_page path

My book has a fairly detailed discussion of how these operations were supposed to work and what the reasoning behind them was. Unfortunately, I don't have time to really participate this discussion at the moment, but I hope somebody else has access to the book and would (re-)read it for some

Re: Fw: [PATCH] ia64: race flushing icache in do_no_page path

My book has a fairly detailed discussion of how these operations were supposed to work and what the reasoning behind them was. Unfortunately, I don't have time to really participate this discussion at the moment, but I hope somebody else has access to the book and would (re-)read it for some

Re: [BUGFIX][PATCH] fixing placement of register stack under ulimit -s

But aren't you going to be limited to less than a page worth of register-backing store even with your patch applied because the backing store will end up overflowing the memory stack? --david On 3/15/07, KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: This patch fixes ia64's bug in ulimit -s

Re: [BUGFIX][PATCH] fixing placement of register stack under ulimit -s

But aren't you going to be limited to less than a page worth of register-backing store even with your patch applied because the backing store will end up overflowing the memory stack? --david On 3/15/07, KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote: This patch fixes ia64's bug in ulimit -s

Re: [PATCH 2.6.13] IOCHK interface for I/O error handling/detecting (for ia64)

is available here: > svn co http://svn.gnumonks.org/trunk/mmio_test/ Reads are slow, sure, but writes are not (or should not). --david -- Mosberger Consulting LLC, voice/fax: 510-744-9372, http://www.mosberger-consulting.com/ 35706 Runckel Lane, Fremont, CA 94536 - To unsubscribe from this

Re: [PATCH 2.6.13] IOCHK interface for I/O error handling/detecting (for ia64)

system, heck even for moderate I/O levels. Sorry - I think this is BS. Please run mmio_test on your box and share the results. mmio_test is available here: svn co http://svn.gnumonks.org/trunk/mmio_test/ Reads are slow, sure, but writes are not (or should not). --david

Re: Add prefetch switch stack hook in scheduler function

Also, should this be called prefetch_stack() or perhaps even just prefetch_task()? Not every architecture defines a switch_stack structure. --david -- Mosberger Consulting LLC, voice/fax: 510-744-9372, http://www.mosberger-consulting.com/ 35706 Runckel Lane, Fremont, CA 94536 On 7/27/05

Re: Add prefetch switch stack hook in scheduler function

Also, should this be called prefetch_stack() or perhaps even just prefetch_task()? Not every architecture defines a switch_stack structure. --david -- Mosberger Consulting LLC, voice/fax: 510-744-9372, http://www.mosberger-consulting.com/ 35706 Runckel Lane, Fremont, CA 94536 On 7/27/05

Re: [PATCH 2.6.13-rc1 07/10] IOCHK interface for I/O error handling/detecting

On 7/5/05, Hidetoshi Seto <[EMAIL PROTECTED]> wrote: >- could anyone write same barrier for intel compiler? > Tony or David, could you help me? I think it might be best to make ia64_mca_barrier() a proper subroutine written in assembly code. Yes, that costs some time, but we're talking

Re: [PATCH 2.6.13-rc1 07/10] IOCHK interface for I/O error handling/detecting

On 7/5/05, Hidetoshi Seto [EMAIL PROTECTED] wrote: - could anyone write same barrier for intel compiler? Tony or David, could you help me? I think it might be best to make ia64_mca_barrier() a proper subroutine written in assembly code. Yes, that costs some time, but we're talking

RE: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later

> On Thu, 21 Apr 2005 10:41:52 -0700, "Luck, Tony" <[EMAIL PROTECTED]> said: Tony> Disk space issues? A complete git repository of the Linux Tony> kernel with all changesets back to 2.4.0 takes just over 3G Tony> ... which is big compared to BK, but 3G of disk only costs Tony> about

RE: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later

> On Thu, 21 Apr 2005 10:19:28 -0700, "Luck, Tony" <[EMAIL PROTECTED]> said: >> I just checked 2.6.12-rc3 and the fls() fix is indeed missing. >> Do you know what happened? Tony> If BitKeeper were still in use, I'd have dropped that patch Tony> into my "release" tree and asked Linus

Re: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later

Tony and Andrew, I just checked 2.6.12-rc3 and the fls() fix is indeed missing. Do you know what happened? --david > On Thu, 21 Apr 2005 13:30:50 +0200, Andreas Hirstius <[EMAIL PROTECTED]> > said: Andreas> Hi, The fls() patch from David solves the problem :-)) Andreas>

Re: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later

Tony and Andrew, I just checked 2.6.12-rc3 and the fls() fix is indeed missing. Do you know what happened? --david On Thu, 21 Apr 2005 13:30:50 +0200, Andreas Hirstius [EMAIL PROTECTED] said: Andreas Hi, The fls() patch from David solves the problem :-)) Andreas Do you have an

RE: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later

On Thu, 21 Apr 2005 10:19:28 -0700, Luck, Tony [EMAIL PROTECTED] said: I just checked 2.6.12-rc3 and the fls() fix is indeed missing. Do you know what happened? Tony If BitKeeper were still in use, I'd have dropped that patch Tony into my release tree and asked Linus to pull ... but

RE: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later

On Thu, 21 Apr 2005 10:41:52 -0700, Luck, Tony [EMAIL PROTECTED] said: Tony Disk space issues? A complete git repository of the Linux Tony kernel with all changesets back to 2.4.0 takes just over 3G Tony ... which is big compared to BK, but 3G of disk only costs Tony about $1 (for IDE

Re: [patch] sched: unlocked context-switches

>>>>> On Tue, 12 Apr 2005 08:42:53 +0200, Ingo Molnar <[EMAIL PROTECTED]> said: Ingo> * David Mosberger <[EMAIL PROTECTED]> wrote: >> Now, Ingo says that the order is reversed with his patch, i.e., >> switch_mm() happens after switch_to().

Re: [patch] sched: unlocked context-switches

> On Tue, 12 Apr 2005 12:12:45 +1000, Nick Piggin <[EMAIL PROTECTED]> said: >> Now, Ingo says that the order is reversed with his patch, i.e., >> switch_mm() happens after switch_to(). That means flush_tlb_mm() >> may now see a current->active_mm which hasn't really been >> activated

Re: [patch] sched: unlocked context-switches

On Tue, 12 Apr 2005 12:12:45 +1000, Nick Piggin [EMAIL PROTECTED] said: Now, Ingo says that the order is reversed with his patch, i.e., switch_mm() happens after switch_to(). That means flush_tlb_mm() may now see a current-active_mm which hasn't really been activated yet. Nick If

Re: [patch] sched: unlocked context-switches

On Tue, 12 Apr 2005 08:42:53 +0200, Ingo Molnar [EMAIL PROTECTED] said: Ingo * David Mosberger [EMAIL PROTECTED] wrote: Now, Ingo says that the order is reversed with his patch, i.e., switch_mm() happens after switch_to(). That means flush_tlb_mm() may now see a current-active_mm

Re: [patch] sched: unlocked context-switches

> On Sun, 10 Apr 2005 08:43:24 +0200, Ingo Molnar <[EMAIL PROTECTED]> said: Ingo> * David S. Miller <[EMAIL PROTECTED]> wrote: >> > Yes, of course. The deadlock was due to context-switching, not >> > switch_mm() per se. Hopefully someone else beats me to >> remembering > the

Re: [patch] sched: unlocked context-switches

On Sun, 10 Apr 2005 08:43:24 +0200, Ingo Molnar [EMAIL PROTECTED] said: Ingo * David S. Miller [EMAIL PROTECTED] wrote: Yes, of course. The deadlock was due to context-switching, not switch_mm() per se. Hopefully someone else beats me to remembering the details before Monday.

Re: [patch] sched: unlocked context-switches

>>>>> On Sat, 9 Apr 2005 09:07:38 +0200, Ingo Molnar <[EMAIL PROTECTED]> said: Ingo> * David Mosberger-Tang <[EMAIL PROTECTED]> wrote: >> > The ia64_switch_to() code includes a section that can change a >> > pinned MMU mapping (when the st

Re: [patch] sched: unlocked context-switches

> Tony: >> Ingo: >> tested on x86, and all other arches should work as well, but if an >> architecture has irqs-off assumptions in its switch_to() logic it >> might break. (I havent found any but there may such assumptions.) > The ia64_switch_to() code includes a section that can change

Re: [patch] sched: unlocked context-switches

Tony: Ingo: tested on x86, and all other arches should work as well, but if an architecture has irqs-off assumptions in its switch_to() logic it might break. (I havent found any but there may such assumptions.) The ia64_switch_to() code includes a section that can change a pinned

Re: [patch] sched: unlocked context-switches

On Sat, 9 Apr 2005 09:07:38 +0200, Ingo Molnar [EMAIL PROTECTED] said: Ingo * David Mosberger-Tang [EMAIL PROTECTED] wrote: The ia64_switch_to() code includes a section that can change a pinned MMU mapping (when the stack for the new process is in a different granule from

Re: [PATCH] add a clear_pages function to clear pages of higher order

> On Tue, 5 Apr 2005 17:33:59 -0700 (PDT), Christoph Lameter <[EMAIL > PROTECTED]> said: Christoph> Which benchmark would you recommend for this? I don't know about "recommend", but I think SPECweb, SPECjbb, the-UNIX-multi-user-benchmark-whose-name-I-keep-forgetting, and in general

Re: [PATCH] add a clear_pages function to clear pages of higher order

>>>>> On Tue, 5 Apr 2005 17:15:53 -0700 (PDT), Christoph Lameter <[EMAIL >>>>> PROTECTED]> said: Christoph> On Thu, 24 Mar 2005, David Mosberger wrote: >> That's definitely the case. See my earlier post on this topic: >> http:

Re: [03/08] fix ia64 syscall auditing

> On Tue, 5 Apr 2005 09:46:48 -0700, Greg KH <[EMAIL PROTECTED]> said: Greg> -stable review patch. If anyone has any objections, please Greg> let us know. Nitpick: the patch introduces trailing whitespace. Why doesn't everybody use emacs and enable show-trailing-whitespace? ;-)

Re: [03/08] fix ia64 syscall auditing

On Tue, 5 Apr 2005 09:46:48 -0700, Greg KH [EMAIL PROTECTED] said: Greg -stable review patch. If anyone has any objections, please Greg let us know. Nitpick: the patch introduces trailing whitespace. Why doesn't everybody use emacs and enable show-trailing-whitespace? ;-) --david

Re: [PATCH] add a clear_pages function to clear pages of higher order

On Tue, 5 Apr 2005 17:15:53 -0700 (PDT), Christoph Lameter [EMAIL PROTECTED] said: Christoph On Thu, 24 Mar 2005, David Mosberger wrote: That's definitely the case. See my earlier post on this topic: http://www.gelato.unsw.edu.au/linux-ia64/0409/11012.html Unfortunately, nobody

Re: [PATCH] add a clear_pages function to clear pages of higher order

On Tue, 5 Apr 2005 17:33:59 -0700 (PDT), Christoph Lameter [EMAIL PROTECTED] said: Christoph Which benchmark would you recommend for this? I don't know about recommend, but I think SPECweb, SPECjbb, the-UNIX-multi-user-benchmark-whose-name-I-keep-forgetting, and in general anything that

fix AGP code to work again with non-PCI AGP bridges

Thanks, --david [AGPGART] Replace check_bridge_mode() with (bridge->mode & AGSTAT_MODE_3_0). This makes AGP work again on machines with an AGP bridge that isn't a PCI device. Signed-off-by: David Mosberger-Tang <[EMAIL PROTECTED]> = drivers/char/agp/generic.c 1.87 vs ed

fix AGP code to work again with non-PCI AGP bridges

, --david [AGPGART] Replace check_bridge_mode() with (bridge-mode AGSTAT_MODE_3_0). This makes AGP work again on machines with an AGP bridge that isn't a PCI device. Signed-off-by: David Mosberger-Tang [EMAIL PROTECTED] = drivers/char/agp/generic.c 1.87 vs edited = --- 1.87

Re: [PATCH] add a clear_pages function to clear pages of higher order

> On Fri, 18 Mar 2005 20:28:08 +0100, Andi Kleen <[EMAIL PROTECTED]> said: >> stores in general for clearing pages? I checked and Itanium has >> always used non-temporal stores. So there will be no benefit for >> us from this Andi> That is weird. I would actually try to switch to

Re: [PATCH] add a clear_pages function to clear pages of higher order

On Fri, 18 Mar 2005 20:28:08 +0100, Andi Kleen [EMAIL PROTECTED] said: stores in general for clearing pages? I checked and Itanium has always used non-temporal stores. So there will be no benefit for us from this Andi That is weird. I would actually try to switch to temporal Andi

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

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

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

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

Re: Mprotect needs arch hook for updated PTE settings

> On Wed, 16 Mar 2005 13:58:04 +0100, Zoltan Menyhart <[EMAIL PROTECTED]> > said: Zoltan> An application should not change the protection of its _own_ Zoltan> text region without knowing well the requirements of the Zoltan> given architecture. And the rationale being? Zoltan> I

Re: Mprotect needs arch hook for updated PTE settings

On Wed, 16 Mar 2005 13:58:04 +0100, Zoltan Menyhart [EMAIL PROTECTED] said: Zoltan An application should not change the protection of its _own_ Zoltan text region without knowing well the requirements of the Zoltan given architecture. And the rationale being? Zoltan I did see

Re: [patch - 2.6.11-rc5-mm1] genalloc - general purpose allocator

> On 03 Mar 2005 03:21:56 -0500, Jes Sorensen <[EMAIL PROTECTED]> said: Jes> mempool on the other hand will first try and call the user Jes> provided allocation function and only if that fails try and Jes> take memory from the pool, this will force us to convert pages Jes> from cached

Re: [patch - 2.6.11-rc5-mm1] genalloc - general purpose allocator

On 03 Mar 2005 03:21:56 -0500, Jes Sorensen [EMAIL PROTECTED] said: Jes mempool on the other hand will first try and call the user Jes provided allocation function and only if that fails try and Jes take memory from the pool, this will force us to convert pages Jes from cached to

Re: [patch - 2.6.11-rc5-mm1] genalloc - general purpose allocator

At the risk of asking the obvious: what's preventing genalloc to be implemented in terms of mempool? --david - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [patch - 2.6.11-rc5-mm1] genalloc - general purpose allocator

At the risk of asking the obvious: what's preventing genalloc to be implemented in terms of mempool? --david - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: Kernel 2.4.21 hangs up

> On Tue, 01 Feb 2005 18:54:59 +0100, Markus Trippelsdorf <[EMAIL > PROTECTED]> said: Markus> They posted it to the LKML so time ago Markus> (2004-03-12). (message): Markus> http://marc.theaimsgroup.com/?l=linux-kernel=107913092300497 Markus> (script): Markus>

Re: Kernel 2.4.21 hangs up

[I trimmed the cc-list...] > On Tue, 1 Feb 2005 00:20:01 -0800 (PST), baswaraj kasture <[EMAIL > PROTECTED]> said: Baswaraj> Hi, I compiled kernel 2.4.21 with intel compiler . That's curious. Last time I checked, the changes needed to use the Intel-compiler have not been backported

Re: Kernel 2.4.21 hangs up

[I trimmed the cc-list...] On Tue, 1 Feb 2005 00:20:01 -0800 (PST), baswaraj kasture [EMAIL PROTECTED] said: Baswaraj Hi, I compiled kernel 2.4.21 with intel compiler . That's curious. Last time I checked, the changes needed to use the Intel-compiler have not been backported to 2.4. What

Re: Kernel 2.4.21 hangs up

On Tue, 01 Feb 2005 18:54:59 +0100, Markus Trippelsdorf [EMAIL PROTECTED] said: Markus They posted it to the LKML so time ago Markus (2004-03-12). (message): Markus http://marc.theaimsgroup.com/?l=linux-kernelm=107913092300497 Markus (script): Markus

Re: [RFC][PATCH] new timeofday arch specific hooks (v. A2)

> On Wed, 26 Jan 2005 08:52:12 -0800 (PST), Christoph Lameter <[EMAIL > PROTECTED]> said: Christoph> On Wed, 26 Jan 2005, Martin Schwidefsky wrote: >> Why not add an if at the start of gettimeofday to check when the >> last ntp updates has been done and if it has been too long

Re: [RFC][PATCH] new timeofday arch specific hooks (v. A2)

On Wed, 26 Jan 2005 08:52:12 -0800 (PST), Christoph Lameter [EMAIL PROTECTED] said: Christoph On Wed, 26 Jan 2005, Martin Schwidefsky wrote: Why not add an if at the start of gettimeofday to check when the last ntp updates has been done and if it has been too long since the last

patch to enable Nvidia v5336 on v2.6.11 kernel (was Re: inter_module_get and __symbol_get)

> On Tue, 25 Jan 2005 10:03:01 +1100, Keith Owens said: Keith> I have always hated the dynamic resolution model used by Keith> DRM/AGP and (originally) MTD. Well, the attached patch does the trick for me for Nvidia driver v5336 on ia64. It compiles with a minimum amount of fuss with

Re: inter_module_get and __symbol_get

> On Tue, 25 Jan 2005 09:54:36 +1100, Keith Owens said: Keith> Does DRM support this model? Keith> * Start DRM without AGP. Keith> * AGP is loaded. Keith> * DRM continues but now using AGP. Keith> If yes then it needs dynamic symbol resolution. I think it does, but I don't see

Re: inter_module_get and __symbol_get

>>>>> On Mon, 24 Jan 2005 18:19:05 -0500, Jon Smirl <[EMAIL PROTECTED]> said: Jon> On Mon, 24 Jan 2005 14:52:06 -0800, David Mosberger Jon> <[EMAIL PROTECTED]> wrote: >> Well, the only place that I know of where I (have to) care about >&

Re: inter_module_get and __symbol_get

> On Tue, 25 Jan 2005 09:44:18 +1100, Keith Owens said: Keith> Does the kernel code really need optional dynamic references Keith> between modules or kernel -> modules? That depends on how Keith> people code their modules. If the rest of the kernel no Keith> longer needs dynamic

Re: inter_module_get and __symbol_get

Keith, I didn't see any followup to your message. My apologies if I missed something. You wrote: Keith> inter_module_* and __symbol_* solve these class of problems: Keith> Module A can use module B if B is loaded, but A does not Keith> require module B to do its work. B is optional.

Re: inter_module_get and __symbol_get

Keith, I didn't see any followup to your message. My apologies if I missed something. You wrote: Keith inter_module_* and __symbol_* solve these class of problems: Keith Module A can use module B if B is loaded, but A does not Keith require module B to do its work. B is optional. Keith

Re: inter_module_get and __symbol_get

On Tue, 25 Jan 2005 09:44:18 +1100, Keith Owens kaos@ocs.com.au said: Keith Does the kernel code really need optional dynamic references Keith between modules or kernel - modules? That depends on how Keith people code their modules. If the rest of the kernel no Keith longer needs

Re: inter_module_get and __symbol_get

On Mon, 24 Jan 2005 18:19:05 -0500, Jon Smirl [EMAIL PROTECTED] said: Jon On Mon, 24 Jan 2005 14:52:06 -0800, David Mosberger Jon [EMAIL PROTECTED] wrote: Well, the only place that I know of where I (have to) care about inter_module*() is because of the DRM/AGP dependency. I can't

Re: inter_module_get and __symbol_get

On Tue, 25 Jan 2005 09:54:36 +1100, Keith Owens kaos@ocs.com.au said: Keith Does DRM support this model? Keith * Start DRM without AGP. Keith * AGP is loaded. Keith * DRM continues but now using AGP. Keith If yes then it needs dynamic symbol resolution. I think it does, but I don't

patch to enable Nvidia v5336 on v2.6.11 kernel (was Re: inter_module_get and __symbol_get)

On Tue, 25 Jan 2005 10:03:01 +1100, Keith Owens kaos@ocs.com.au said: Keith I have always hated the dynamic resolution model used by Keith DRM/AGP and (originally) MTD. Well, the attached patch does the trick for me for Nvidia driver v5336 on ia64. It compiles with a minimum amount of fuss

Re: sparse warning, or why does jifies_to_msecs() return an int?

> On Sat, 15 Jan 2005 10:05:37 -0800 (PST), Linus Torvalds <[EMAIL > PROTECTED]> said: Linus> Hmm.. I don't think your patch is wrong per se, but I do Linus> think it's a bit too subtle. I'd almost rather make Linus> "jiffies_to_msecs()" just test for overflow instead, and that

Re: sparse warning, or why does jifies_to_msecs() return an int?

On Sat, 15 Jan 2005 10:05:37 -0800 (PST), Linus Torvalds [EMAIL PROTECTED] said: Linus Hmm.. I don't think your patch is wrong per se, but I do Linus think it's a bit too subtle. I'd almost rather make Linus jiffies_to_msecs() just test for overflow instead, and that Linus should also

Re: pipe performance regression on ia64

> On Wed, 19 Jan 2005 23:43:45 +1100, Nick Piggin <[EMAIL PROTECTED]> said: Nick> Oh that's quite true. A bad score on SMP on the pipe benchmark Nick> does not mean anything is broken. Nick> And IMO, probably many (most?) lmbench tests should be run Nick> with all processes bound to

Re: pipe performance regression on ia64

On Wed, 19 Jan 2005 23:43:45 +1100, Nick Piggin [EMAIL PROTECTED] said: Nick Oh that's quite true. A bad score on SMP on the pipe benchmark Nick does not mean anything is broken. Nick And IMO, probably many (most?) lmbench tests should be run Nick with all processes bound to the same

Re: pipe performance regression on ia64

> On Wed, 19 Jan 2005 10:34:30 +1100, Nick Piggin <[EMAIL PROTECTED]> said: Nick> David I remember you reporting a pipe bandwidth regression, Nick> and I had a patch for it, but that hurt other workloads, so I Nick> don't think we ever really got anywhere. I've recently begun Nick>

Re: pipe performance regression on ia64

> On Tue, 18 Jan 2005 10:11:26 -0800 (PST), Linus Torvalds <[EMAIL > PROTECTED]> said: Linus> I don't know how to make the benchmark look repeatable and Linus> good, though. The CPU affinity thing may be the right thing. Perhaps it should be split up into three cases: -

Re: pipe performance regression on ia64

On Tue, 18 Jan 2005 10:11:26 -0800 (PST), Linus Torvalds [EMAIL PROTECTED] said: Linus I don't know how to make the benchmark look repeatable and Linus good, though. The CPU affinity thing may be the right thing. Perhaps it should be split up into three cases: -

Re: pipe performance regression on ia64

On Wed, 19 Jan 2005 10:34:30 +1100, Nick Piggin [EMAIL PROTECTED] said: Nick David I remember you reporting a pipe bandwidth regression, Nick and I had a patch for it, but that hurt other workloads, so I Nick don't think we ever really got anywhere. I've recently begun Nick having

[patch] clean up pt_regs accesses

a definition drivers/pci/pci-sysfs.c:204:16: warning: undefined identifier 'ia64_pci_legacy_read' drivers/pci/pci-sysfs.c:227:16: warning: undefined identifier 'ia64_pci_legacy_write' Somebody else will have to look into these. --david Signed-off-by: David Mosberger-Tang <[EMAIL PROTEC

[patch] clean up pt_regs accesses

a definition drivers/pci/pci-sysfs.c:204:16: warning: undefined identifier 'ia64_pci_legacy_read' drivers/pci/pci-sysfs.c:227:16: warning: undefined identifier 'ia64_pci_legacy_write' Somebody else will have to look into these. --david Signed-off-by: David Mosberger-Tang [EMAIL PROTECTED

[patch] avoid sparse warning due to time-interpolator

The "addr" member in the time-interpolator is sometimes used as a function-pointer and sometimes as an I/O-memory pointer. The attached patch tells sparse that this is OK. Signed-off-by: David Mosberger-Tang <[EMAIL PROTECTED]> = kernel/timer.c 1.109 vs edited = --- 1.10

[patch] avoid sparse warning due to time-interpolator

The addr member in the time-interpolator is sometimes used as a function-pointer and sometimes as an I/O-memory pointer. The attached patch tells sparse that this is OK. Signed-off-by: David Mosberger-Tang [EMAIL PROTECTED] = kernel/timer.c 1.109 vs edited = --- 1.109/kernel/timer.c

  1   2   >