* [DNX#2006040142001329] [U-Boot-Users] [PATCH] FAT32 access on USB memory [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001329] was created:
<snip>
> Hi,
>
> I have had following problem with ARM9 CPUs NS9360, NS9750, S3C2410 and
> S3C2440:
>
> Using fatload command with 2GB USB memory stick lead to data abort and
> reset of CPU.
>
> The reason herefor is, that the access to the variable fatbuf produces
> an alignment error, if FAT32 is used.
>
> Attached patch moves the variable fatbuf to top of the structure, where
> it is defined, so that accesses to this variable are always aligned.
>
> CHANGELOG:
> Fix access via fatload command on FAT32 formatted partitions
> Patch by Joachim Jaeger, 18 Nov 2005
>
> Signed-off-by: Joachim Jaeger <joachim_jaeger@digi.com>
>
>
> Best regards
> Joachim Jaeger
>
> --
> FS FORTH-SYSTEME GmbH
> A Digi International Company
> Kueferstr. 8, D-79206 Breisach
> Phone: +49 (7667) 908-0, FAX +49 (7667) 908-200
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001311] [U-Boot-Users] Fix 32bits compilation error in dm9 [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001311] was created:
<snip>
> Hi,
>
> the attached patch fix a compilation error in dm9000.c when configured
> in 32
> bits mode.
>
> Eric
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001301] [U-Boot-Users] [Patch 1/5] Add support for AT91SAM [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001301] was created:
<snip>
> Hi Wolfgang,
>
> Following patches are applied against git top of tree and should be
> applied
> in numerical order.
>
>
> The five following patches adds support to build the AT91SAM9261EK board
> (USB, LCD and DataFlash support)
>
>
> This first patch (1/5) adds support for ATMEL AT91SAM9261EK board.
>
> CHANGELOG
> Patch by Nicolas Lacressonniere 31 January 2006
> * Add support for ATMEL AT91SAM9261EK board (arm926ejs)
>
>
> Best regards.
> Nicolas.
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001294] [U-Boot-Users] [patch] code-cleanup-for-tqm5200-bo [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001294] was created:
<snip>
> Code cleanup for TQM5200 board.
>
> Signed-off-by: Martin Krause <martin.krause@tqs.de>
>
> This patch removes the obsolete flash driver /board/tqm5200/flash.c
>
> CHANGELOG:
>
> * Code cleanup for TQM5200 board.
> Patch by Martin Krause, 11 Jan 2006
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001285] [U-Boot-Users] [PATCH] Intel PXA270 Mainstone u-bo [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001285] was created:
<snip>
> Attached u-boot-1.1.4 new board port for Intel PXA270 Mainstone board
> (aka HCDDBBVA0)
>
> > Please send it to this list. Make sure that your code follows the
> > Coding Style requirements - see README sections "Coding Style" and
> > "Submitting Patches".
>
> I've done my best, hope will be ok ;-)
> Ciao
> --
> Marco Cavallini
> Koan s.a.s. - Bergamo - ITALIA
> Embedded and Real-Time Software Engineering
> www.koansoftware.com | www.klinux.org
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001267] [U-Boot-Users] PATCH - Coldfire gcc3.4 compiling f [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001267] was created:
<snip>
> This patch is properly formatted.
>
> Index: config.mk
> ===================================================================
> RCS file: /cvsroot/u-boot/u-boot/config.mk,v
> retrieving revision 1.14
> diff -u -r1.14 config.mk
> --- config.mk 4 Oct 2005 21:11:34 -0000 1.14
> +++ config.mk 6 Dec 2005 18:16:22 -0000
> @@ -139,7 +139,14 @@
> endif
> endif
>
> +# turn jbsr into jsr for m68k
> +ifeq ($(ARCH),m68k)
> +ifeq ($(findstring 3.4,$(shell $(CC) --version)),3.4)
> +AFLAGS_DEBUG := -Wa,-gstabs,-S
> +endif
> +else
> AFLAGS_DEBUG := -Wa,-gstabs
> +endif
> AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
>
> LDFLAGS += -Bstatic -T $(LDSCRIPT) -Ttext $(TEXT_BASE)
> $(PLATFORM_LDFLAGS)
>
> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of Jate
> Sujjavanich
> Sent: Tuesday, December 06, 2005 12:08 PM
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] PATCH - Coldfire gcc3.4 compiling fix
>
> Index: config.mk
> ===================================================================
> RCS file: /cvsroot/u-boot/u-boot/config.mk,v
> retrieving revision 1.14
> diff -u -r1.14 config.mk
> --- config.mk 4 Oct 2005 21:11:34 -0000 1.14
> +++ config.mk 6 Dec 2005 16:57:10 -0000
> @@ -139,7 +139,14 @@
> endif
> endif
>
> +# turn jbsr into jsr for m68k
> +ifeq ($(ARCH),m68k)
> +ifeq ($(findstring 3.4,$(shell $(CC) --version)),3.4) AFLAGS_DEBUG :=
> +-Wa,-gstabs,-S endif else
> AFLAGS_DEBUG := -Wa,-gstabs
> +endif
> AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
>
> LDFLAGS += -Bstatic -T $(LDSCRIPT) -Ttext $(TEXT_BASE)
> $(PLATFORM_LDFLAGS)
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001276] [U-Boot-Users] [PATCH-3/4] blackfin: flashless boa [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001276] was created:
<snip>
> ## no text/plain body => see attachment (text/plain) ##
</snip>
Your U-Boot support team
^ permalink raw reply
* Re: [spi-devel-general] Re: question on spi_bitbang
From: Kumar Gala @ 2006-03-31 23:58 UTC (permalink / raw)
To: David Brownell; +Cc: spi-devel-general, linux kernel mailing list
In-Reply-To: <200603311420.02962.david-b@pacbell.net>
On Mar 31, 2006, at 4:20 PM, David Brownell wrote:
> On Friday 31 March 2006 2:11 pm, Kumar Gala wrote:
>
>> So I give a new question. Any issue with adding a rx & tx completion
>> to spi_bitbang?
>
> What do you mean?
>
>> In my HW I get an interrupt when the transmitter is
>> done transmitting and one when the receiver is done receiving. I
>> need some way to synchronize and wait for both events to occur before
>> continuing on in txrx_word().
>
> You can't return from txrx_word() before the RX event, since the
> return value is the word that was shifted in. So if you use IRQs
> to synchronize there (rather than polling a status register), all
> that would be internal to your code.
Your right, I just put this in my struct that wraps spi_bitbang.
It's too bad we dont have a better solution for spi_bitbang having to
be first.
I've got a working driver w/o using the setup_transfer() mods, I'll
look at fixing that up next.
- kumar
^ permalink raw reply
* Re: smp_locks reference_discarded errors
From: Adrian Bunk @ 2006-03-31 23:56 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Dave Jones, Andrew Morton, linux-kernel
In-Reply-To: <20060331193338.GA10664@mars.ravnborg.org>
On Fri, Mar 31, 2006 at 09:33:38PM +0200, Sam Ravnborg wrote:
> On Fri, Mar 31, 2006 at 09:08:51PM +0200, Adrian Bunk wrote:
> > On Sun, Mar 26, 2006 at 06:10:55PM +0200, Sam Ravnborg wrote:
> > > On Sun, Mar 26, 2006 at 10:40:42AM -0500, Dave Jones wrote:
> > > >
> > > > came out of a 'make buildcheck' a day or two ago (the following day,
> > > > Sam nuked reference_discarded.pl in favour of it being done
> > > > magically somewhere else (I've not looked into how its done now).
> > > The check is part of modpost now. modpost is only used when building
> > > modules but that holds true for most builds anyway therefore I did not
> > > move it to a separate executable.
> > >...
> >
> > This doesn't sound good.
> >
> > This means that we have no longer any tool that warns us about e.g.
> > references from non-__exit code to __exit code [1]?
> > [1] __exit, not __{dev,cpu,mem}exit
>
> It does warn for this also. The test I have carried out has mostly been
> on allmodconfig builds though. I assume you are worried for the case
> when a module is built-in and the __exit section is discarded - or?
Exactly - especially since in kernel 2.6 we are getting on architectures
like i386 no longer link errors as we did in kernel 2.4.
Perhaps I'm only concerned because my usual builds didn't produce a
single warning... ;-)
> Sam
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH 1/2] Base pSeries PCIe support
From: Dave Hansen @ 2006-03-31 22:15 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060331160545.db3fa210.moilanen@austin.ibm.com>
On Fri, 2006-03-31 at 16:05 -0600, Jake Moilanen wrote:
> --- 2.6.16.orig/arch/powerpc/kernel/rtas_pci.c 2006-03-31 15:11:20.000000000 -0600
> +++ 2.6.16/arch/powerpc/kernel/rtas_pci.c 2006-03-31 15:15:35.000000000 -0600
> @@ -315,7 +315,8 @@
> for (node = of_get_next_child(root, NULL);
> node != NULL;
> node = of_get_next_child(root, node)) {
> - if (node->type == NULL || strcmp(node->type, "pci") != 0)
> +
> + if (node->type == NULL || ((strcmp(node->type, "pci") != 0) && (strcmp(node->type, "pciex") != 0)))
> continue;
That one looks to have gone a wee bit over 80 columns.
-- Dave
^ permalink raw reply
* Re: Avoid excessive time spend on concurrent slab shrinking
From: Christoph Lameter @ 2006-03-31 23:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: nickpiggin, linux-mm
In-Reply-To: <20060331153235.754deb0c.akpm@osdl.org>
On Fri, 31 Mar 2006, Andrew Morton wrote:
> > System sluggish in general. cscope takes 20 minutes to start etc. Dropping
> > the caches restored performance.
>
> OK. What sort of system was it, and what was the workload? FIlesystem types?
A build server. Lots of scripts running, compilers etc etc.
> It's been like that for an awful long time. Can you think why this has
> only just now been noticed?
Testing has reached new level of thoroughness because of the new releases
that are due soon...
> > We just noticed general sluggishness and took some stackdumps to see what
> > the system was up to.
>
> OK. But was it D-state sleep (semaphore lock contention) or what?
Yes, lots of processes waiting on semaphores in
shrink_slab->shrink_icache_memory. Need to look at this in more detail it
seems.
I looked at the old release that worked. Seems that it did the same thing
in terms of slab shrinking. Concurrent slab shrinking was no problem. So
you may be right. Its something unrelated to the code in vmscan.c. Maybe
Nick knows something about this?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] 8250: yet another attempt at a serial console fix
From: Georg Nikodym @ 2006-03-31 23:48 UTC (permalink / raw)
To: Georg Nikodym; +Cc: linux-kernel, rmk+serial
In-Reply-To: <BC34AAD1-595C-4E8E-A8D0-D0F1A9E93C69@rogers.com>
[-- Attachment #1: Type: text/plain, Size: 340 bytes --]
On Mar 31, 2006, at 14:29, Georg Nikodym wrote:
>
> Since the old code worked I had trouble swallowing the backup timer
> idea. But the detection logic worked a charm so I lifted that and
> offer up the attached patch for evisceration.
Please ignore my earlier patch submission. There are at least four
things wrong with it.
-g
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Avoid excessive time spend on concurrent slab shrinking
From: Andrew Morton @ 2006-03-31 23:46 UTC (permalink / raw)
To: Christoph Lameter; +Cc: nickpiggin, linux-mm
In-Reply-To: <Pine.LNX.4.64.0603311507130.8617@schroedinger.engr.sgi.com>
Christoph Lameter <clameter@sgi.com> wrote:
>
> On Fri, 31 Mar 2006, Andrew Morton wrote:
>
> > Christoph Lameter <clameter@sgi.com> wrote:
> > >
> > > We experienced that concurrent slab shrinking on 2.6.16 can slow down a
> > > system excessively due to lock contention.
> >
> > How much?
>
> System sluggish in general. cscope takes 20 minutes to start etc. Dropping
> the caches restored performance.
OK. What sort of system was it, and what was the workload? FIlesystem types?
What sort of overhead was it? sleeping-in-D-state?
pingponging-cachelines-around?
It's been like that for an awful long time. Can you think why this has
only just now been noticed?
> > Which lock(s)?
>
> Seems to be mainly iprune_sem. So its inode reclaim.
But why on earth would iprune_mutex make such a difference? The kernel can
throw away inodes at a great old rate, and it takes quite some time to
restore them.
I fear that something new is happening, and that prune_icache() is now
doing lots of work without achieving anything.
We have fiddled with various things in fs/inode.c which could affect this
over the past year. I wonder if one of those changes has caused the inode
scan to now scan lots of unreclaimable inodes.
> > > Slab shrinking is a global
> > > operation so it does not make sense for multiple slab shrink operations
> > > to be ongoing at the same time.
> >
> > That's how it used to be - it was a semaphore and we baled out if
> > down_trylock() failed. If we're going to revert that change then I'd
> > prefer to just go back to doing it that way (only with a mutex).
>
> No problem with that. Seems that the behavior <2.6.9 was okay. This showed
> up during beta testing of a new major distribution release.
OK.
> > The reason we made that change in 2.6.9:
> >
> > Use an rwsem to protect the shrinker list instead of a regular
> > semaphore. Modifications to the list are now done under the write lock,
> > shrink_slab takes the read lock, and access to shrinker->nr becomes racy
> > (which is no concurrent.
> >
> > Previously, having the slab scanner get preempted or scheduling while
> > holding the semaphore would cause other tasks to skip putting pressure on
> > the slab.
> >
> > Also, make shrink_icache_memory return -1 if it can't do anything in
> > order to hold pressure on this cache and prevent useless looping in
> > shrink_slab.
>
> Shrink_icache_memory() never returns -1.
if (!(gfp_mask & __GFP_FS))
return -1;
> > Note the lack of performance numbers? How are we to judge which the
> > regression which your proposal introduces is outweighed by the (unmeasured)
> > gain it provides?
>
> We just noticed general sluggishness and took some stackdumps to see what
> the system was up to.
OK. But was it D-state sleep (semaphore lock contention) or what?
> Do we have a benchmark for slab shrinking?
Nope. In general reclaim shouldn't be a performance problem because the
things which we reclaim take so much work to reestablish. It only causes
problems when we're repeatedly scanning lots of things which aren't
actually reclaimable. Hence my suspicions are aroused...
> > We need a *lot* of testing results with varied workloads and varying
> > machine types before we can say that changes like this are of aggregate
> > benefit and do not introduce bad corner-case regressions.
>
> The slowdown of the system running concurrent slab reclaim is pretty
> severe. Machine is basically unusable until you manually trigger the
> dropping of the caches.
bad.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Avoid excessive time spend on concurrent slab shrinking
From: Andrew Morton @ 2006-03-31 23:45 UTC (permalink / raw)
To: Christoph Lameter; +Cc: nickpiggin, linux-mm
In-Reply-To: <Pine.LNX.4.64.0603311441400.8465@schroedinger.engr.sgi.com>
(Resent to correct linux-mm address)
Christoph Lameter <clameter@sgi.com> wrote:
>
> We experienced that concurrent slab shrinking on 2.6.16 can slow down a
> system excessively due to lock contention.
How much?
Which lock(s)?
> Slab shrinking is a global
> operation so it does not make sense for multiple slab shrink operations
> to be ongoing at the same time.
That's how it used to be - it was a semaphore and we baled out if
down_trylock() failed. If we're going to revert that change then I'd
prefer to just go back to doing it that way (only with a mutex).
The reason we made that change in 2.6.9:
Use an rwsem to protect the shrinker list instead of a regular
semaphore. Modifications to the list are now done under the write lock,
shrink_slab takes the read lock, and access to shrinker->nr becomes racy
(which is no concurrent.
Previously, having the slab scanner get preempted or scheduling while
holding the semaphore would cause other tasks to skip putting pressure on
the slab.
Also, make shrink_icache_memory return -1 if it can't do anything in
order to hold pressure on this cache and prevent useless looping in
shrink_slab.
Note the lack of performance numbers? How are we to judge which the
regression which your proposal introduces is outweighed by the (unmeasured)
gain it provides?
> The single shrinking task can perform the
> shrinking for all nodes and processors in the system.
Probably. But we _can_ sometimes do disk I/O while holding that lock, down
in the inode-releasing code, iirc. Could get bad with a `-o sync' mounted
filesystem.
> Introduce an atomic
> counter that works in the same was as in shrink_zone to limit concurrent
> shrinking.
No, a simple mutex_trylock() should suffice.
> Also calculate the time it took to do the shrinking and wait at least twice
> that time before doing it again. If we are spending excessive time
> on slab shrinking then we need to pause for some time to insure that the
> system is capable of archiving other tasks.
No way, sorry. I've had it with "gee let's do this, it might be better"
"optimisations" in that code.
We need a *lot* of testing results with varied workloads and varying
machine types before we can say that changes like this are of aggregate
benefit and do not introduce bad corner-case regressions.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] ia64 build fixes
From: Alex Williamson @ 2006-03-31 23:44 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel, xen-ia64-devel
Include features header in xenbus_probe and build features.c
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
---
diff -r d76a7a40f3a9 linux-2.6-xen-sparse/arch/ia64/xen/drivers/coreMakefile
--- a/linux-2.6-xen-sparse/arch/ia64/xen/drivers/coreMakefile Fri Mar 31 17:44:26 2006 +0100
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/drivers/coreMakefile Fri Mar 31 16:31:41 2006 -0700
@@ -10,7 +10,7 @@ CPPFLAGS_vmlinux.lds += -U$(XENARCH)
@ln -fsn $(srctree)/arch/$(XENARCH)/kernel/vmlinux.lds.S $@
-obj-y := gnttab.o
+obj-y := gnttab.o features.o
obj-$(CONFIG_PROC_FS) += xen_proc.o
ifeq ($(ARCH),ia64)
diff -r d76a7a40f3a9 linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_probe.c
--- a/linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_probe.c Fri Mar 31 17:44:26 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_probe.c Fri Mar 31 16:31:41 2006 -0700
@@ -49,6 +49,7 @@
#include <xen/xenbus.h>
#include <xen/xen_proc.h>
#include <xen/evtchn.h>
+#include <xen/features.h>
#include "xenbus_comms.h"
^ permalink raw reply
* man-pages-2.28 is released
From: Michael Kerrisk @ 2006-03-31 23:44 UTC (permalink / raw)
To: linux-kernel; +Cc: michael.kerrisk
In-Reply-To: <5159.1143403544@www006.gmx.net>
Gidday,
I recently released man-pages-2.28, which can be found at:
ftp://ftp.win.tue.nl/pub/linux-local/manpages
or:
ftp://ftp.kernel.org/pub/linux/docs/manpages
or mirrors: ftp://ftp.XX.kernel.org/pub/linux/docs/manpages
This release includes the following new pages:
sem_post.3
sem_getvalue.3
sem_close.3
sem_open.3
sem_destroy.3
sem_wait.3
sem_unlink.3
sem_init.3
sem_overview.7
mtk
New pages describing the POSIX semaphores API.
These pages supercede and provide a superset of the information
in the glibc (3thr) "semaphores(3)" manual page.
==========
The man-pages set contains sections 2, 3, 4, 5, and 7 of
the manual pages. These sections describe the following:
2: (Linux) system calls
3: (libc) library functions
4: Devices
5: File formats and protocols
7: Overview pages, conventions, etc.
As far as this list is concerned the most relevant parts are:
all of sections 2 and 4, which describe kernel-userland interfaces;
in section 5, the proc(5) manual page, which attempts (it's always
catching up) to be a comprehensive description of /proc; and
various pages in section 7, some of which are overview pages of
kernel features (e.g., networking protocols).
If you make a change to a kernel-userland interface, or observe
a discrepancy between the manual pages and reality, would you
please send me (at mtk-manpages@gmx.net ) one of the following
(in decreasing order of preference):
1. An in-line "diff -u" patch with text changes for the
corresponding manual page. (The most up-to-date version
of the manual pages can always be found at
ftp://ftp.win.tue.nl/pub/linux-local/manpages or
ftp://ftp.kernel.org/pub/linux/docs/manpages .)
2. Some raw text describing the changes, which I can then
integrate into the appropriate manual page.
3. A message alerting me that some part of the manual pages
does not correspond to reality. Eventually, I will try to
remedy the situation.
Obviously, as we get further down this list, more of my time
is required, and things may go slower, especially when the
changes concern some part of the kernel that I am ignorant
about and I can't find someone to assist.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance?
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/,
read the HOWTOHELP file and grep the source
files for 'FIXME'.
^ permalink raw reply
* Re: Semantics of smp_mb() [was : Re: [PATCH] Fix RCU race in access of nohz_cpu_mask ]
From: Jesse Barnes @ 2006-03-31 23:38 UTC (permalink / raw)
To: Jeremy Higdon
Cc: Paul E. McKenney, bcasavan, Keith Owens, Andi Kleen, ajwade,
vatsa, Oleg Nesterov, linux-kernel, Dipankar Sarma, Andrew Morton,
Ingo Molnar
In-Reply-To: <20060331045627.GB426545@sgi.com>
[Unknown author]
> > > From comments by jejb, we're looking at modifying the mmiowb
> > > API by adding an argument which would be a register to read
> > > from if the architecture in question needs ordering in this
> > > way but does not have a lighter weight mechanism like the Altix
> > > mmiowb. Since there will now need to be a width indication,
> > > mmiowb will be replaced with mmiowb[bwlq].
> >
> > Any progress on this front? I figured that I would wait to update
> > the ordering document until after this change happened, but if it
> > is going to be awhile, I should proceed with the current API.
I avoided doing this initially on the premise that I shouldn't do things
'just because we might need it in the future' since that way seems to
lead to madness. Is there actual hardware that needs an argument to
mmiowb() (i.e. that can't just do a read from the system's single bridge
or something)?
Jesse
^ permalink raw reply
* RE: IDE CMD 64x PCI driver
From: Alan Cox @ 2006-03-31 23:46 UTC (permalink / raw)
To: Komuro; +Cc: linux-kernel
In-Reply-To: <27060187.14131143847493404.komurojun-mbn@nifty.com>
On Sad, 2006-04-01 at 08:24 +0900, Komuro wrote:
> Hello,
>
> >I am having difficultly getting the IDE CMD 64x PCI driver to work for the
> >CMD PCI-648 device. I have decided to dig through kernel and driver code
> >to find out why and hopefully correct the problem.
>
>
>
> It seems nobody maintains the CMD64x driver.
I've been working on CMD648 support for the libata PATA set. I don't
have a CMD648 so testers would be most welcome.
^ permalink raw reply
* 2.6.16.1 (1) vs ieee1394 (0) HELP! (I told the missus I could do this)
From: Gene Heskett @ 2006-03-31 23:36 UTC (permalink / raw)
To: linux kernel mailing list
Greetings all;
I sent this once, but it hasn't come back in about 20 minutes, sorry if
it hits twice.
I may have found a gotcha in the 2.6.16.1 and NDI how far back it goes
because I haven't used anything ieee1394 in months.
Anyway, I plugged in my camera, a Sony DCR-TVR460 and fired up kino,
fully expecting to see the viewfinders image on screen as soon as I
switched kino to the capture screen.
Unforch, its blank and kino is locked up, needing kde's emergency kill
the process to kill it when I click on the closing x.
>From the logs, I get this is 4 or 5 lines.
Mar 31 17:30:16 coyote ieee1394.agent[8925]: ... no drivers for IEEE1394
product 0x/0x/0x
Mar 31 17:30:16 coyote ieee1394.agent[8921]: ... no drivers for IEEE1394
product 0x/0x/0x
Mar 31 17:30:16 coyote kernel: ieee1394: raw1394: /dev/raw1394 device
initialized
And about 6 or 7 lines of gconf verbosy later, this:
Mar 31 17:31:28 coyote kernel: ohci1394: fw-host0: Waking dma ctx=0 ...
processing is probably too slow
then:
[root@coyote linux-2.6.16.1]# lsmod |grep 1394
raw1394 24172 0
dv1394 16716 0
ohci1394 27824 1 dv1394
ieee1394 82488 3 raw1394,dv1394,ohci1394
And:
[root@coyote linux-2.6.16.1]#
ls /lib/modules/2.6.16.1/kernel/drivers/ieee1394
dv1394.ko ieee1394.ko ohci1394.ko raw1394.ko sbp2.ko video1394.ko
sbp2.ko isn't needed, its for a webcam thats a POS. I should quit
building it altogether.
modprobe video1394 inserts that module, but makes zilch difference.
kino still freezes the instant the capture button is clicked.
Unplugging the firewire cable from the camera is silent in messages, but
dmesg says:
ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[08004601044684e4]
ieee1394: Node resumed: ID:BUS[0-00:1023] GUID[08004601044684e4]
ieee1394: Node changed: 0-00:1023 -> 0-01:1023
ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[08004601044684e4]
ieee1394: Node resumed: ID:BUS[0-00:1023] GUID[08004601044684e4]
ieee1394: Node changed: 0-00:1023 -> 0-01:1023
Then from:
[root@coyote boot]# lspci -vv |grep -A10 01:09
01:09.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23
IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (500ns min, 1000ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 12
Region 0: Memory at ec004000 (32-bit, non-prefetchable)
Region 1: Memory at ec000000 (32-bit, non-prefetchable)
[size=16K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
And I'm not smart enough for anything there to raise a flag.
So obviously something's gone aglay, but what?
The last time I ran this config to do some movie editing of a wedding,
along about June of last year, it all Just Worked. And I recently did
some much needed housekeeping, such that if I wanted to build a 2.6.14
kernel, I'd have to go get the tarball & start from scratch.
Ideas anybody?
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply
* [PATCH] net: Broadcast ARP packets on link local addresses
From: David Daney @ 2006-03-31 23:26 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, freek, pgf
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in RFC
3927. There are several user space daemons available that implement
most of the protocol (zcip, busybox, ...). The kernel's APR driver
should function in the normal manner except that it is required to
broadcast all ARP packets that it originates in the link local address
space (169.254.0.0/16). RFC 3927 section 2.5 explains the requirement.
The current ARP code is non-compliant because it does not broadcast
some ARP packets as required by RFC 3927.
This patch to net/ipv4/arp.c checks the source address of all ARP
packets and if the fall in 169.254.0.0/16, they are broadcast instead
of unicast. I would like to thank Freek Dijkstra wrote the first
version of the patch. He was kind enough to sign off on it in his
(off-list) e-mail to me:
>David Daney wrote:
>
>
>> For the linux kernel the requirements for contributing are quite easy.
>> All people who wrote the patch simply affirm that they are have the
>> right to contribute and that they are doing so. See section 11 of
>> Documentation/SubmittingPatches in the kernel source tree.
>
>
> Just read. (a) and (d) apply (I wrote it, and I'm fine that you use it):
> Signed-off-by: Freek Dijkstra <freek@macfreek.nl>
>
.
.
.
>
> I hereby release the above patch in the public domain.
> (You may credit me or not, I don't think it's needed).
>
> Have fun.
> Freek
This patch is against 2.6.16.1
Signed-off-by: David Daney <ddaney@avtrex.com>
---
--- net/ipv4/arp.c.orig 2006-03-31 13:44:50.000000000 -0800
+++ net/ipv4/arp.c 2006-03-31 13:48:26.000000000 -0800
@@ -682,6 +682,7 @@ void arp_send(int type, int ptype, u32 d
unsigned char *target_hw)
{
struct sk_buff *skb;
+ int lla;
/*
* No arp on this interface.
@@ -690,8 +691,13 @@ void arp_send(int type, int ptype, u32 d
if (dev->flags&IFF_NOARP)
return;
+ /* If link local address (169.254.0.0/16) we must broadcast
+ * the ARP packet. See RFC 3927 section 2.5 for details.
+ */
+ lla = (dest_ip & htonl(0xFFFF0000UL)) == htonl(0xA9FE0000UL);
+
skb = arp_create(type, ptype, dest_ip, dev, src_ip,
- dest_hw, src_hw, target_hw);
+ lla ? NULL : dest_hw, src_hw, target_hw);
if (skb == NULL) {
return;
}
^ permalink raw reply
* RE: IDE CMD 64x PCI driver
From: Komuro @ 2006-03-31 23:24 UTC (permalink / raw)
To: linux-kernel
Hello,
>I am having difficultly getting the IDE CMD 64x PCI driver to work for the
>CMD PCI-648 device. I have decided to dig through kernel and driver code
>to find out why and hopefully correct the problem.
It seems nobody maintains the CMD64x driver.
Best Regards
Komuro
^ permalink raw reply
* Re: [V9fs-developer] [PATCH] 9p: cleanup unused functions
From: Latchesar Ionkov @ 2006-03-31 23:25 UTC (permalink / raw)
To: Eric Van Hensbergen; +Cc: akpm, linux-kernel, v9fs-developer, ericvh
In-Reply-To: <200603312125.k2VLPnX0003602@hera.kernel.org>
Hmm, the fact that they are not used currently doesn't mean that they are
not going to be used soon. Please don't remove them, I'll have to add them
back again :)
Thanks,
Lucho
On Fri, Mar 31, 2006 at 09:25:49PM +0000, Eric Van Hensbergen said:
> >From nobody Mon Sep 17 00:00:00 2001
> From: Eric Van Hensbergen <ericvh@gmail.com>
> Date: Fri Mar 31 15:20:06 2006 -0600
> Subject: [PATCH] 9p: remove unused functions
>
> This patch just removes some unused functions that were previously
>
> Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
>
> ---
>
> fs/9p/conv.c | 26 --------------------------
> fs/9p/fcall.c | 25 -------------------------
> fs/9p/mux.c | 26 --------------------------
> 3 files changed, 0 insertions(+), 77 deletions(-)
>
> 6b9742bbf5beb884dd9a1f285d04da8b14c6a09d
> diff --git a/fs/9p/conv.c b/fs/9p/conv.c
> index a767e05..63311ef 100644
> --- a/fs/9p/conv.c
> +++ b/fs/9p/conv.c
> @@ -535,32 +535,6 @@ struct v9fs_fcall *v9fs_create_tversion(
> return fc;
> }
>
> -#if 0
> -struct v9fs_fcall *v9fs_create_tauth(u32 afid, char *uname, char *aname)
> -{
> - int size;
> - struct v9fs_fcall *fc;
> - struct cbuf buffer;
> - struct cbuf *bufp = &buffer;
> -
> - size = 4 + 2 + strlen(uname) + 2 + strlen(aname); /* afid[4] uname[s] aname[s] */
> - fc = v9fs_create_common(bufp, size, TAUTH);
> - if (IS_ERR(fc))
> - goto error;
> -
> - v9fs_put_int32(bufp, afid, &fc->params.tauth.afid);
> - v9fs_put_str(bufp, uname, &fc->params.tauth.uname);
> - v9fs_put_str(bufp, aname, &fc->params.tauth.aname);
> -
> - if (buf_check_overflow(bufp)) {
> - kfree(fc);
> - fc = ERR_PTR(-ENOMEM);
> - }
> - error:
> - return fc;
> -}
> -#endif /* 0 */
> -
> struct v9fs_fcall *
> v9fs_create_tattach(u32 fid, u32 afid, char *uname, char *aname)
> {
> diff --git a/fs/9p/fcall.c b/fs/9p/fcall.c
> index 71742ba..d78cb77 100644
> --- a/fs/9p/fcall.c
> +++ b/fs/9p/fcall.c
> @@ -147,31 +147,6 @@ v9fs_t_clunk(struct v9fs_session_info *v
> return ret;
> }
>
> -#if 0
> -/**
> - * v9fs_v9fs_t_flush - flush a pending transaction
> - * @v9ses: 9P2000 session information
> - * @tag: tag to release
> - *
> - */
> -int v9fs_t_flush(struct v9fs_session_info *v9ses, u16 oldtag)
> -{
> - int ret;
> - struct v9fs_fcall *tc;
> -
> - dprintk(DEBUG_9P, "oldtag %d\n", oldtag);
> -
> - tc = v9fs_create_tflush(oldtag);
> - if (!IS_ERR(tc)) {
> - ret = v9fs_mux_rpc(v9ses->mux, tc, NULL);
> - kfree(tc);
> - } else
> - ret = PTR_ERR(tc);
> -
> - return ret;
> -}
> -#endif
> -
> /**
> * v9fs_t_stat - read a file's meta-data
> * @v9ses: 9P2000 session information
> diff --git a/fs/9p/mux.c b/fs/9p/mux.c
> index 3e5b124..a06eb6f 100644
> --- a/fs/9p/mux.c
> +++ b/fs/9p/mux.c
> @@ -915,32 +915,6 @@ v9fs_mux_rpc(struct v9fs_mux_data *m, st
> return err;
> }
>
> -#if 0
> -/**
> - * v9fs_mux_rpcnb - sends 9P request without waiting for response.
> - * @m: mux data
> - * @tc: request to be sent
> - * @cb: callback function to be called when response arrives
> - * @cba: value to pass to the callback function
> - */
> -int v9fs_mux_rpcnb(struct v9fs_mux_data *m, struct v9fs_fcall *tc,
> - v9fs_mux_req_callback cb, void *a)
> -{
> - int err;
> - struct v9fs_req *req;
> -
> - req = v9fs_send_request(m, tc, cb, a);
> - if (IS_ERR(req)) {
> - err = PTR_ERR(req);
> - dprintk(DEBUG_MUX, "error %d\n", err);
> - return PTR_ERR(req);
> - }
> -
> - dprintk(DEBUG_MUX, "mux %p tc %p tag %d\n", m, tc, req->tag);
> - return 0;
> -}
> -#endif /* 0 */
> -
> /**
> * v9fs_mux_cancel - cancel all pending requests with error
> * @m: mux data
> --
> 1.2.4.gb0a3de4
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> V9fs-developer mailing list
> V9fs-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/v9fs-developer
^ permalink raw reply
* Re: Avoid excessive time spend on concurrent slab shrinking
From: Christoph Lameter @ 2006-03-31 23:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: nickpiggin, linux-mm
In-Reply-To: <20060331150120.21fad488.akpm@osdl.org>
On Fri, 31 Mar 2006, Andrew Morton wrote:
> Christoph Lameter <clameter@sgi.com> wrote:
> >
> > We experienced that concurrent slab shrinking on 2.6.16 can slow down a
> > system excessively due to lock contention.
>
> How much?
System sluggish in general. cscope takes 20 minutes to start etc. Dropping
the caches restored performance.
> Which lock(s)?
Seems to be mainly iprune_sem. So its inode reclaim.
> > Slab shrinking is a global
> > operation so it does not make sense for multiple slab shrink operations
> > to be ongoing at the same time.
>
> That's how it used to be - it was a semaphore and we baled out if
> down_trylock() failed. If we're going to revert that change then I'd
> prefer to just go back to doing it that way (only with a mutex).
No problem with that. Seems that the behavior <2.6.9 was okay. This showed
up during beta testing of a new major distribution release.
> The reason we made that change in 2.6.9:
>
> Use an rwsem to protect the shrinker list instead of a regular
> semaphore. Modifications to the list are now done under the write lock,
> shrink_slab takes the read lock, and access to shrinker->nr becomes racy
> (which is no concurrent.
>
> Previously, having the slab scanner get preempted or scheduling while
> holding the semaphore would cause other tasks to skip putting pressure on
> the slab.
>
> Also, make shrink_icache_memory return -1 if it can't do anything in
> order to hold pressure on this cache and prevent useless looping in
> shrink_slab.
Shrink_icache_memory() never returns -1.
> Note the lack of performance numbers? How are we to judge which the
> regression which your proposal introduces is outweighed by the (unmeasured)
> gain it provides?
We just noticed general sluggishness and took some stackdumps to see what
the system was up to. Do we have a benchmark for slab shrinking?
> We need a *lot* of testing results with varied workloads and varying
> machine types before we can say that changes like this are of aggregate
> benefit and do not introduce bad corner-case regressions.
The slowdown of the system running concurrent slab reclaim is pretty
severe. Machine is basically unusable until you manually trigger the
dropping of the caches.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] Add gcc 4.0 support
From: John Davidorff Pell @ 2006-03-31 23:18 UTC (permalink / raw)
To: Paul Brook; +Cc: qemu-devel
In-Reply-To: <200603292033.53117.paul@codesourcery.com>
On 29 Mar 2006, at 11:33, Paul Brook wrote:
> Also, the gcc -O2 option is more than the sum of the other options
> it enables.
That, IMHO, is a bug. Of course, its not Qemu's bug. :-)
JP
--
"The New York Times is read by the people who run the country. The
Washington Post is read by the people who think they run the country.
The National Enquirer is read by the people who think Elvis is alive
and running the country ..."
-- Robert J Woodhead
^ permalink raw reply
* Re: Oops: mounting floppy disk on PPC64 (power3)
From: Nathan Lynch @ 2006-03-31 22:50 UTC (permalink / raw)
To: Markus Rothe; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200603312138.16032.markus@unixforces.net>
Hello.
Markus Rothe wrote:
>
> this is kernel 2.6.16.1 compiled with gcc 4.1.0 (gentoo patches). I never
> tried to mount a floppy on this system before, so I don't know if it Oops'ed
> in previous kernel versions, too.
>
> power3 ~ # uname -a
> Linux power3 2.6.16.1 #1 Fri Mar 31 21:08:43 UTC 2006 ppc64 POWER3 (630+) CHRP
> IBM,7044-170 GNU/Linux
> power3 ~ # modprobe floppy
> power3 ~ # mount /mnt/floppy/
> Oops: Kernel access of bad area, sig: 11 [#1]
> NUMA PSERIES
> Modules linked in: floppy
> NIP: C0000000000201E8 LR: D0000000000C43A4 CTR: C0000000000201D8
> REGS: c0000000003df470 TRAP: 0300 Not tainted (2.6.16.1)
> MSR: A000000000001032 <ME,IR,DR> CR: 48000082 XER: 00000000
> DAR: 0000000000000178, DSISR: 0000000040000000
> TASK = c0000000003fc9b0[0] 'swapper' THREAD: c0000000003dc000
> GPR00: C00000000042FC08 C0000000003DF6F0 C0000000004D3310 0000000000000000
> GPR04: C00000000161D000 0000000000000400 0000000000000002 0000000000000750
> GPR08: 0000000000000064 D0000000000D4AE0 D0000000000D5F20 C0000000000201D8
> GPR12: D0000000000CB280 C0000000003FCF80 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 4000000001400000 C0000000003595E0
> GPR20: C0000000003D1F28 00000000017D1A80 C0000000003D1A80 0000000000000060
> GPR24: 00000000000003F0 A000000000009032 0000000000000044 00000000000000D9
> GPR28: 0000000000000400 0000000000000002 D0000000000DB880 C00000000161D000
> NIP [C0000000000201E8] .dma_map_single+0x10/0x70
> LR [D0000000000C43A4] .setup_rw_floppy+0x2c0/0xaa8 [floppy]
> Call Trace:
> [C0000000003DF6F0] [D0000000000C5790] .start_motor+0x108/0x158 [floppy]
> (unreli)
> [C0000000003DF760] [D0000000000C43A4] .setup_rw_floppy+0x2c0/0xaa8 [floppy]
> [C0000000003DF810] [C000000000044714] .run_timer_softirq+0x174/0x20c
> [C0000000003DF8B0] [C00000000003FC68] .__do_softirq+0x80/0x128
> [C0000000003DF940] [C00000000003FD5C] .do_softirq+0x4c/0x68
> [C0000000003DF9C0] [C00000000001C9E8] .timer_interrupt+0x360/0x388
> [C0000000003DFA90] [C0000000000034B8] decrementer_common+0xb8/0x100
> --- Exception: 901 at .ppc64_runlatch_off+0x0/0x50
> LR = .default_idle+0x48/0x70
> [C0000000003DFD80] [C000000000016764] .default_idle+0x68/0x70 (unreliable)
> [C0000000003DFE00] [C0000000000166E8] .cpu_idle+0x40/0x54
> [C0000000003DFE70] [C0000000000092B0] .rest_init+0x3c/0x54
> [C0000000003DFEF0] [C0000000003B16D4] .start_kernel+0x1f0/0x208
> [C0000000003DFF90] [C000000000008514] .start_here_common+0x88/0x174
> Instruction dump:
> 4e800421 e8410028 48000008 0fe00000 38210070 e8010010 7c0803a6 4e800020
> 7c0802a6 f8010010 f821ff91 e80298d0 <e9230178> 7fa90000 409e000c e92298d8
>
> Am I doing something wrong?
Nope.
I believe this was fixed in Linus' tree as of a couple days ago:
diff-tree b239cbe957ae730caa8af2f169a4d35b8c1bb299 (from
69ed3324983bb937d78a857Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue Mar 28 14:40:58 2006 +1100
[PATCH] powerpc: make ISA floppies work again
We used to assume that a DMA mapping request with a NULL dev was
for
ISA DMA. This assumption was broken at some point. Now we
explicitly
pass the detected ISA PCI device in the floppy setup.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Maybe you could verify with latest -git, or 2.6.17-rc1 when it's
released?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.