Re: [PATCH] pcmcia: ppc64 needs 64-bit ioaddr_t
On Mon, May 14, 2007 at 05:57:31PM -0500, Olof Johansson wrote: > On Sun, May 13, 2007 at 11:46:08PM +0200, Christoph Hellwig wrote: > > On Sat, May 12, 2007 at 09:31:05AM -0500, Olof Johansson wrote: > > > ppc64 really needs ioaddr_t to be 64-bit, since I/O addresses really > > > are MMIO addresses, and remapped to a high range. > > > > > > While the type is exported to userspace, there hasn't been any platforms > > > with PCMCIA on 64-bit powerpc until now, so changing it won't regress > > > any existing users. > > > > In fact the only use of the type should be in the obsolete ioctl-based user > > interface. So instead of changing the size of the type you should > > > > a) make sure you're not using cardmgr > > b) fix up those places that still use ioaddr_t where they shouldn't > > and switch the to kio_addr_t (why not just unsigned long like all > > other busses?) > > I just noticed that feature-removal-schedule.txt says November 2005 for > the removal of the pcmcia ioctl's, but they're still there. I'm missing > the history here, any reason they weren't removed yet? See the discussions on lkml. It seems like people haven't really noticed the deprecation messages and are still using it. Still not a good reason to use them on a new port (at least new in terms of pcmcia support) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1 lost snd_4236 device
On 05/13/2007 06:23 PM, Pete Clements wrote:
Fyi:
With 2.6.22-rc1 get following when loading sound device module. Introduced
with 2.6.21-git16.
FATAL: Error inserting snd_cs4236
(/lib/modules/2.6.22-rc1/kernel/sound/isa/cs423x/snd-cs4236.ko): No such device
FATAL: Error running install command for snd_cs4236
Yup; the conversion of the mixed legacy/pnp ALSA drivers to the isa_bus
framework is not quite right. Wants the attached.
Takashi, this needs to go to Linus. Can you make sure it gets there? This is
against -linus HEAD.
Signed-off-by: Rene Herman <[EMAIL PROTECTED]>
Rene.
diff --git a/sound/isa/cmi8330.c b/sound/isa/cmi8330.c
index 214d65d..f471f8a 100644
--- a/sound/isa/cmi8330.c
+++ b/sound/isa/cmi8330.c
@@ -109,6 +109,7 @@ module_param_array(wssdma, int, NULL, 0444);
MODULE_PARM_DESC(wssdma, "DMA for CMI8330 WSS driver.");
#ifdef CONFIG_PNP
+static int isa_registered;
static int pnp_registered;
#endif
@@ -686,14 +687,18 @@ static int __init alsa_card_cmi8330_init(void)
int err;
err = isa_register_driver(_cmi8330_driver, SNDRV_CARDS);
- if (err < 0)
- return err;
#ifdef CONFIG_PNP
+ if (!err)
+ isa_registered = 1;
+
err = pnp_register_card_driver(_pnpc_driver);
if (!err)
pnp_registered = 1;
+
+ if (isa_registered)
+ err = 0;
#endif
- return 0;
+ return err;
}
static void __exit alsa_card_cmi8330_exit(void)
@@ -701,8 +706,10 @@ static void __exit alsa_card_cmi8330_exit(void)
#ifdef CONFIG_PNP
if (pnp_registered)
pnp_unregister_card_driver(_pnpc_driver);
+
+ if (isa_registered)
#endif
- isa_unregister_driver(_cmi8330_driver);
+ isa_unregister_driver(_cmi8330_driver);
}
module_init(alsa_card_cmi8330_init)
diff --git a/sound/isa/cs423x/cs4236.c b/sound/isa/cs423x/cs4236.c
index 87f1392..1a14f33 100644
--- a/sound/isa/cs423x/cs4236.c
+++ b/sound/isa/cs423x/cs4236.c
@@ -127,6 +127,7 @@ module_param_array(dma2, int, NULL, 0444);
MODULE_PARM_DESC(dma2, "DMA2 # for " IDENT " driver.");
#ifdef CONFIG_PNP
+static int isa_registered;
static int pnpc_registered;
#ifdef CS4232
static int pnp_registered;
@@ -770,9 +771,9 @@ static int __init alsa_card_cs423x_init(void)
int err;
err = isa_register_driver(_isa_driver, SNDRV_CARDS);
- if (err < 0)
- return err;
#ifdef CONFIG_PNP
+ if (!err)
+ isa_registered = 1;
#ifdef CS4232
err = pnp_register_driver(_pnp_driver);
if (!err)
@@ -781,8 +782,14 @@ static int __init alsa_card_cs423x_init(void)
err = pnp_register_card_driver(_pnpc_driver);
if (!err)
pnpc_registered = 1;
-#endif /* CONFIG_PNP */
- return 0;
+#ifdef CS4232
+ if (pnp_registered)
+ err = 0;
+#endif
+ if (isa_registered)
+ err = 0;
+#endif
+ return err;
}
static void __exit alsa_card_cs423x_exit(void)
@@ -794,8 +801,9 @@ static void __exit alsa_card_cs423x_exit(void)
if (pnp_registered)
pnp_unregister_driver(_pnp_driver);
#endif
-#endif /* CONFIG_PNP */
- isa_unregister_driver(_isa_driver);
+ if (isa_registered)
+#endif
+ isa_unregister_driver(_isa_driver);
}
module_init(alsa_card_cs423x_init)
diff --git a/sound/isa/es18xx.c b/sound/isa/es18xx.c
index d2a9c7d..f7732bf 100644
--- a/sound/isa/es18xx.c
+++ b/sound/isa/es18xx.c
@@ -2036,7 +2036,9 @@ module_param_array(dma2, int, NULL, 0444);
MODULE_PARM_DESC(dma2, "DMA 2 # for ES18xx driver.");
#ifdef CONFIG_PNP
-static int pnp_registered, pnpc_registered;
+static int isa_registered;
+static int pnp_registered;
+static int pnpc_registered;
static struct pnp_device_id snd_audiodrive_pnpbiosids[] = {
{ .id = "ESS1869" },
@@ -2466,18 +2468,22 @@ static int __init alsa_card_es18xx_init(void)
int err;
err = isa_register_driver(_es18xx_isa_driver, SNDRV_CARDS);
- if (err < 0)
- return err;
-
#ifdef CONFIG_PNP
+ if (!err)
+ isa_registered = 1;
+
err = pnp_register_driver(_pnp_driver);
if (!err)
pnp_registered = 1;
+
err = pnp_register_card_driver(_pnpc_driver);
if (!err)
pnpc_registered = 1;
+
+ if (isa_registered || pnp_registered)
+ err = 0;
#endif
- return 0;
+ return err;
}
static void __exit alsa_card_es18xx_exit(void)
@@ -2487,8 +2493,9 @@ static void __exit alsa_card_es18xx_exit(void)
pnp_unregister_card_driver(_pnpc_driver);
if (pnp_registered)
pnp_unregister_driver(_pnp_driver);
+ if (isa_registered)
#endif
- isa_unregister_driver(_es18xx_isa_driver);
+ isa_unregister_driver(_es18xx_isa_driver);
}
module_init(alsa_card_es18xx_init)
diff --git a/sound/isa/gus/interwave.c
Re: Linux 2.6.22-rc1
> >Seriously, it might be a tad more efficient if the help texts were > >written by those who invented the options in the first place. > > menuconfig NETDEV_1 > bool "Ethernet (10GbE)" > ---help-- > Say Y here to actually be able to go into this menu > and select some drivers that we think belong to the > "10 Gigabit Ethernet" family. > > If unsure, it is unwise to say N! > > See, this looks so fundamentally basic to me that I find it > almost funny. YMMV, hence I asked for suggestions from > other people. I remember very well the time when I first issued make menuconfig. Ever since then I've been grateful for all those "fundamentally basic" explanations. And I've learned quite alot about kernelconfig just by reading them. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpR0U6biGdbj.pgp Description: PGP signature
Re: [ARM] Fix hard_smp_processor_id compile error
On Mon, May 14, 2007 at 10:22:34PM -0700, Andrew Morton wrote: > On Tue, 15 May 2007 13:54:23 +0900 Simon Horman <[EMAIL PROTECTED]> wrote: > > > On Mon, May 14, 2007 at 09:48:18PM -0700, Andrew Morton wrote: > > > On Tue, 15 May 2007 11:59:41 +0900 Fernando Luis Vázquez Cao <[EMAIL > > > PROTECTED]> wrote: > > > > > > > On Tue, 2007-05-15 at 11:18 +0900, Simon Horman wrote: > > > > > "Remove hardcoding of hard_smp_processor_id on UP systems", > > > > > 2f4dfe206a2fc07099dfad77a8ea2f4b4ae2140f in Linus' tree, moved > > > > > the definition of hard_smp_processor_id linux/smp.h to asm/smp.h > > > > > for UP systems. This causes a regression on ARM as the definition > > > > > was not added to asm-arm/smp.h. > > > > Hi Simon! > > > > > > > > Thank you for catching and fixing these compile errors. I should install > > > > a cross-compiler ASAP. > > > > > > Mine are at http://userweb.kernel.org/~akpm/cross-compilers/ > > > > Do you have / know of tools to create a set of configs for testing? > > What I am thinking of is something that takes the default configs, > > then toggles SMP, PREEMT and stuff like that, testing all the > > permutations. > > `make randconfig'? I was thinking of something a little more predictable. But that end up could working just as well. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ARM] Fix hard_smp_processor_id compile error
On Tue, 15 May 2007 13:54:23 +0900 Simon Horman <[EMAIL PROTECTED]> wrote: > On Mon, May 14, 2007 at 09:48:18PM -0700, Andrew Morton wrote: > > On Tue, 15 May 2007 11:59:41 +0900 Fernando Luis Vázquez Cao <[EMAIL > > PROTECTED]> wrote: > > > > > On Tue, 2007-05-15 at 11:18 +0900, Simon Horman wrote: > > > > "Remove hardcoding of hard_smp_processor_id on UP systems", > > > > 2f4dfe206a2fc07099dfad77a8ea2f4b4ae2140f in Linus' tree, moved > > > > the definition of hard_smp_processor_id linux/smp.h to asm/smp.h > > > > for UP systems. This causes a regression on ARM as the definition > > > > was not added to asm-arm/smp.h. > > > Hi Simon! > > > > > > Thank you for catching and fixing these compile errors. I should install > > > a cross-compiler ASAP. > > > > Mine are at http://userweb.kernel.org/~akpm/cross-compilers/ > > Do you have / know of tools to create a set of configs for testing? > What I am thinking of is something that takes the default configs, > then toggles SMP, PREEMT and stuff like that, testing all the > permutations. `make randconfig'? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc1
almost, highstart_pfn is used in a few printks
arch/i386/mm/discontig.c: In function 'setup_memory':
arch/i386/mm/discontig.c:314: error: 'highstart_pfn' undeclared (first
use in this function)
arch/i386/mm/discontig.c:314: error: (Each undeclared identifier is
reported only once
arch/i386/mm/discontig.c:314: error: for each function it appears in.)
On 5/15/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Tue, 15 May 2007, andrew hendry wrote:
>
> from a randconfig, attached.
>
> arch/i386/mm/discontig.c:107: error: expected identifier or '(' before
numeric constant
Gaah. That file is horrible. It redeclares a lot of stuff that it has no
business declaring.
Does this patch help?
Linus
---
arch/i386/mm/discontig.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/i386/mm/discontig.c b/arch/i386/mm/discontig.c
index aa58720..baac2a4 100644
--- a/arch/i386/mm/discontig.c
+++ b/arch/i386/mm/discontig.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -97,15 +98,8 @@ unsigned long node_memmap_size_bytes(int nid, unsigned long
start_pfn,
#endif
extern unsigned long find_max_low_pfn(void);
-extern void find_max_pfn(void);
extern void add_one_highpage_init(struct page *, int, int);
-extern struct e820map e820;
-extern unsigned long highend_pfn, highstart_pfn;
-extern unsigned long max_low_pfn;
-extern unsigned long totalram_pages;
-extern unsigned long totalhigh_pages;
-
#define LARGE_PAGE_BYTES (PTRS_PER_PTE * PAGE_SIZE)
unsigned long node_remap_start_pfn[MAX_NUMNODES];
@@ -360,7 +354,9 @@ void __init zone_sizes_init(void)
max_zone_pfns[ZONE_DMA] =
virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT;
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
+#ifdef CONFIG_HIGHMEM
max_zone_pfns[ZONE_HIGHMEM] = highend_pfn;
+#endif
/* If SRAT has not registered memory, register it now */
if (find_max_pfn_with_active_regions() == 0) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugme-new] [Bug 8479] New: gettimeofday returning 1000000 in tv_usec on core2duo
On Mon, 14 May 2007 21:17:47 -0700 [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8479 > >Summary: gettimeofday returning 100 in tv_usec on core2duo > Kernel Version: 2.6.21 > Status: NEW > Severity: normal > Owner: [EMAIL PROTECTED] > Submitter: [EMAIL PROTECTED] > > > Most recent kernel where this bug did *NOT* occur: 2.6.20 > Distribution: Gentoo > Hardware Environment: core2duo T7200 (all reporters had this same CPU) > Software Environment: Linux 2.6.21, glibc 2.5 > Problem Description: > > gettimeofday returns 1 - 100 in tv_usec, not 0 - 99 > This does not happen on any of my AMD-based 32 or 64 bit boxes, only on my > core2duo; I have 2 other reports of this problem, all on T7200's > > Steps to reproduce: > > call gettimeofday a lot. Eventually, you'll get 100 returned in tv_usec. > My > average is ~1 in 100 calls. I've attached my test program, with output > from > various boxes. One of the other reporters tried the test program too, and got > similar output. .config will be attached too. err, whoops. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ARM] Fix hard_smp_processor_id compile error
On Mon, May 14, 2007 at 09:48:18PM -0700, Andrew Morton wrote: > On Tue, 15 May 2007 11:59:41 +0900 Fernando Luis Vázquez Cao <[EMAIL > PROTECTED]> wrote: > > > On Tue, 2007-05-15 at 11:18 +0900, Simon Horman wrote: > > > "Remove hardcoding of hard_smp_processor_id on UP systems", > > > 2f4dfe206a2fc07099dfad77a8ea2f4b4ae2140f in Linus' tree, moved > > > the definition of hard_smp_processor_id linux/smp.h to asm/smp.h > > > for UP systems. This causes a regression on ARM as the definition > > > was not added to asm-arm/smp.h. > > Hi Simon! > > > > Thank you for catching and fixing these compile errors. I should install > > a cross-compiler ASAP. > > Mine are at http://userweb.kernel.org/~akpm/cross-compilers/ Do you have / know of tools to create a set of configs for testing? What I am thinking of is something that takes the default configs, then toggles SMP, PREEMT and stuff like that, testing all the permutations. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tracking down disk spinups.
On Monday 14 May 2007 4:46 pm, Dave Jones wrote: > On Mon, May 14, 2007 at 04:28:35PM -0400, Rob Landley wrote: > > On Monday 14 May 2007 2:57 pm, Dave Jones wrote: > > > Why did the kernel ignore what I told it to do ? > > > I'm sure it thinks it knows better than me for a reason, but > > > I'd like to know what it is. > > > > Remount doesn't switch filesystem drivers, it tells the existing filesystem > > driver to accept new flags and/or a new option string. > > yes, I had misinterpreted what 'remount' did. I thought behind the scenes > it actually did a umount/mount. I implemented the BusyBox mount command last year. (Well, rewrote three times until just about none of the old code was left.) Getting remount to work right is a monster headache. (The new flags _replace_ the old flags, not delta against them, so you have to parse /etc/mtab (or /proc/mounts), read the old flags out of that, mask them yourself, and supply them back in. And of course, not all of them are flags, some remain strings, but you can't keep strings you turned into flags because the driver will barf that it's an unrecognized string option... Headache. And don't get me started on vfat spitting back string options from /proc/mounts that are THE DEFAULT VALUES... Grrr. I'll stop now.) You can always umount/mount yourself. > > To switch drivers you have to umount the old sucker and mount the new one. > > (The idea of handing off consistent cache data from one mounted filesystem > > driver to another... Ouch.) > > a umount would purge the cache, but that's irrelevant given it doesn't > work that way. > > Anyways, I rebooted after s/ext3/ext2/ on my fstab, and found things > hadn't really got any more obvious what was going on. > Instead of 'kjournald' writing stuff out, now it's 'pdflush'. > > *has sudden brainwave* > > Ahh, it's doing atime updates. Duh. I had to add MS_SILENT (1<<15) to the default mount options for busybox (because otherwise the kernel got log message diarrhea). I was seriously tempted to add MS_NOATIME to that, but didn't. I should write up a good "mount" spec, from the kernel's point of view. (There isn't one. I looked.) Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ARM] Fix hard_smp_processor_id compile error
On Tue, 15 May 2007 11:59:41 +0900 Fernando Luis Vázquez Cao <[EMAIL PROTECTED]> wrote: > On Tue, 2007-05-15 at 11:18 +0900, Simon Horman wrote: > > "Remove hardcoding of hard_smp_processor_id on UP systems", > > 2f4dfe206a2fc07099dfad77a8ea2f4b4ae2140f in Linus' tree, moved > > the definition of hard_smp_processor_id linux/smp.h to asm/smp.h > > for UP systems. This causes a regression on ARM as the definition > > was not added to asm-arm/smp.h. > Hi Simon! > > Thank you for catching and fixing these compile errors. I should install > a cross-compiler ASAP. Mine are at http://userweb.kernel.org/~akpm/cross-compilers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/15] per device dirty throttling -v6
On Thursday May 10, [EMAIL PROTECTED] wrote: > The latest version of the per device dirty throttling patches. > > I put in quite a few comments, and added an patch to do per task dirty > throttling as well, for RFCs sake :-) > > I haven't yet come around to do anything but integrety testing on this code > base, ie. it built a kernel. I hope to do more tests shorty if time permits... > > Perhaps the people on bugzilla.kernel.org #7372 might be willing to help out > there. > > Oh, patches are against 2.6.21-mm2 > > -- Patch 12 has: +#include But that file isn't added until patch 14. Splitting the "proportions" stuff out into lib/ is a good idea. You have left some remnants of it's origin though, which mentions of BDI pages total page writeback The "proportions" library always uses a percpu counter, which is perfect of the per-bdi counter, but seems wrong when you use the same code for per-task throttling. Have a percpu counter in struct task seems very wasteful. You don't need to lock the access to this counter as it is only ever access as current-> so a simple "long" (or "long long") would do. The global "vm_dirties" still needs to be percpu I'm not sure what best to do about this. The per-task throttling is interesting. You reduce the point where a task has to throttle by up to half, based on the fraction of recently dirtied pages that the task is responsible for. So if there is one writer, it now gets only half the space that it used to. That is probably OK, we can just increase the space available... If there are two equally eager writers, they can both use up to the 75% mark, so they probably each get 37%, which is reasonable. If there is one fast an one slow writer where the slow writer is generating dirty pages well below the writeout rate of the device, the fast writer will throttle at around 50% and the slow writer will never block. That is nice. If you have two writers A and B writing aggressively to two devices X and Y with different speeds, say X twice the speed of Y, then in the steady state, X gets 2/3 of the space and Y gets 1/3. A will dirty twice the pages that B dirties so A will get to use 1 - (2/3)/2 == 2/3 of that space or 4/9, and B will get to use 1 - (1/3)/2 == 5/6 of that space or 5/18. Did I get that right? So they will each reduce the space available to the other, even though they aren't really competing. That might not be a problem, but it is interesting... It seems that the 'one half' is fairly arbitrary. It could equally well be 3/4. That would simply mean there is less differentiation between the more and less aggressive writer. I would probably lean towards a higher number like 3/4. It should still give reasonable differentiation without cutting max amount of dirty memory in half for the common 1-writer case. A couple of years ago Andrea Arcangeli wrote a patch that did per-task throttling, which it is worth comparing with. http://lwn.net/Articles/152277/ It takes each task separately, measure rate-of-dirtying over a fixed time period, and throttle when that rate would put the system over the limit soon. Thus slower dirtiers throttle later. Having to configure the fixed number (the period) is always awkward, and I think your floating average is better suited for the task. I doubt if Andrea's patch still applies so a direct comparison might be awkward, but it might not hurt to read through it if you haven't already. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pasemi: Electra CF driver
Driver for the CompactFlash slot on the PA Semi Electra eval board. It's
a simple device sitting on localbus, with interrupts and detect/voltage
control over GPIO.
The driver is implemented as an of_platform driver, and adds localbus
as a bus being probed by the of_platform framework.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
Updated based on review comments from Russell, as well as retooled for
the I/O space changes (as discussed with Arnd/BenH).
This patch depends on the PCMCIA pcmcia_bus_type export to compile:
http://lists.infradead.org/pipermail/linux-pcmcia/2007-May/004628.html
and on the ioaddr_t change to work at runtime:
http://patchwork.ozlabs.org/linuxppc/patch?id=11147
Also, had to switch to bool config option since the iospace functions
aren't exported (starting with .23 we should be able to switch back to
tristate). Keep all the module init/remove calls for now.
Index: powerpc/drivers/pcmcia/Kconfig
===
--- powerpc.orig/drivers/pcmcia/Kconfig
+++ powerpc/drivers/pcmcia/Kconfig
@@ -270,6 +270,13 @@ config AT91_CF
Say Y here to support the CompactFlash controller on AT91 chips.
Or choose M to compile the driver as a module named "at91_cf".
+config ELECTRA_CF
+ bool "Electra CompactFlash Controller"
+ depends on PCMCIA=y && PPC_PASEMI
+ help
+ Say Y here to support the CompactFlash controller on the
+ PA Semi Electra eval board.
+
config PCCARD_NONSTATIC
tristate
Index: powerpc/drivers/pcmcia/Makefile
===
--- powerpc.orig/drivers/pcmcia/Makefile
+++ powerpc/drivers/pcmcia/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_PCMCIA_VRC4171) += vrc417
obj-$(CONFIG_PCMCIA_VRC4173) += vrc4173_cardu.o
obj-$(CONFIG_OMAP_CF) += omap_cf.o
obj-$(CONFIG_AT91_CF) += at91_cf.o
+obj-$(CONFIG_ELECTRA_CF) += electra_cf.o
sa11xx_core-y += soc_common.o sa11xx_base.o
pxa2xx_core-y += soc_common.o pxa2xx_base.o
Index: powerpc/drivers/pcmcia/electra_cf.c
===
--- /dev/null
+++ powerpc/drivers/pcmcia/electra_cf.c
@@ -0,0 +1,382 @@
+/*
+ * Copyright (C) 2007 PA Semi, Inc
+ *
+ * Maintained by: Olof Johansson <[EMAIL PROTECTED]>
+ *
+ * Based on drivers/pcmcia/omap_cf.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static const char driver_name[] = "electra-cf";
+
+struct electra_cf_socket {
+ struct pcmcia_socketsocket;
+
+ struct timer_list timer;
+ unsignedpresent:1;
+ unsignedactive:1;
+
+ struct of_device*ofdev;
+ unsigned long mem_phys;
+ void __iomem * mem_base;
+ unsigned long mem_size;
+ void __iomem * io_virt;
+ unsigned intio_base;
+ unsigned intio_size;
+ u_int irq;
+ struct resource iomem;
+ void __iomem * gpio_base;
+ int gpio_detect;
+ int gpio_vsense;
+ int gpio_3v;
+ int gpio_5v;
+};
+
+#definePOLL_INTERVAL (2 * HZ)
+
+
+static int electra_cf_present(struct electra_cf_socket *cf)
+{
+ unsigned int gpio;
+
+ gpio = in_le32(cf->gpio_base+0x40);
+ return !(gpio & (1 << cf->gpio_detect));
+}
+
+static int electra_cf_ss_init(struct pcmcia_socket *s)
+{
+ return 0;
+}
+
+/* the timer is primarily to kick this socket's pccardd */
+static void electra_cf_timer(unsigned long _cf)
+{
+ struct electra_cf_socket *cf = (void *) _cf;
+ int present = electra_cf_present(cf);
+
+ if (present != cf->present) {
+ cf->present = present;
+ pcmcia_parse_events(>socket, SS_DETECT);
+ }
+
+ if (cf->active)
+ mod_timer(>timer, jiffies + POLL_INTERVAL);
+}
Re: Linux 2.6.22-rc1
On Tue, 15 May 2007, andrew hendry wrote:
>
> from a randconfig, attached.
>
> arch/i386/mm/discontig.c:107: error: expected identifier or '(' before
> numeric constant
Gaah. That file is horrible. It redeclares a lot of stuff that it has no
business declaring.
Does this patch help?
Linus
---
arch/i386/mm/discontig.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/i386/mm/discontig.c b/arch/i386/mm/discontig.c
index aa58720..baac2a4 100644
--- a/arch/i386/mm/discontig.c
+++ b/arch/i386/mm/discontig.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -97,15 +98,8 @@ unsigned long node_memmap_size_bytes(int nid, unsigned long
start_pfn,
#endif
extern unsigned long find_max_low_pfn(void);
-extern void find_max_pfn(void);
extern void add_one_highpage_init(struct page *, int, int);
-extern struct e820map e820;
-extern unsigned long highend_pfn, highstart_pfn;
-extern unsigned long max_low_pfn;
-extern unsigned long totalram_pages;
-extern unsigned long totalhigh_pages;
-
#define LARGE_PAGE_BYTES (PTRS_PER_PTE * PAGE_SIZE)
unsigned long node_remap_start_pfn[MAX_NUMNODES];
@@ -360,7 +354,9 @@ void __init zone_sizes_init(void)
max_zone_pfns[ZONE_DMA] =
virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT;
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
+#ifdef CONFIG_HIGHMEM
max_zone_pfns[ZONE_HIGHMEM] = highend_pfn;
+#endif
/* If SRAT has not registered memory, register it now */
if (find_max_pfn_with_active_regions() == 0) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] pcmcia: export pcmcia_bus_type (GPL-only)
Export pcmcia_bus_type so module-based drivers can register bus notifiers.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: powerpc/drivers/pcmcia/ds.c
===
--- powerpc.orig/drivers/pcmcia/ds.c
+++ powerpc/drivers/pcmcia/ds.c
@@ -1404,6 +1404,7 @@ struct bus_type pcmcia_bus_type = {
.suspend = pcmcia_dev_suspend,
.resume = pcmcia_dev_resume,
};
+EXPORT_SYMBOL_GPL(pcmcia_bus_type);
static int __init init_pcmcia_bus(void)
Index: powerpc/include/pcmcia/ss.h
===
--- powerpc.orig/include/pcmcia/ss.h
+++ powerpc/include/pcmcia/ss.h
@@ -298,6 +298,7 @@ extern int pcmcia_register_socket(struct
extern void pcmcia_unregister_socket(struct pcmcia_socket *socket);
extern struct class pcmcia_socket_class;
+extern struct bus_type pcmcia_bus_type;
/* socket drivers are expected to use these callbacks in their .drv struct */
extern int pcmcia_socket_dev_suspend(struct device *dev, pm_message_t state);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] pcmcia: ppc64 needs 32-bit ioaddr_t
ppc64 really needs ioaddr_t to be 32-bit, since I/O beyond the first PCI bus might be mapped at a higher range. While the type is exported to userspace, there hasn't been any platforms with PCMCIA on 64-bit powerpc until now, so changing it won't regress any existing users. Besides, those interfaces are overdue for removal already. Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> Index: 2.6.21/include/pcmcia/cs_types.h === --- 2.6.21.orig/include/pcmcia/cs_types.h +++ 2.6.21/include/pcmcia/cs_types.h @@ -21,7 +21,7 @@ #include #endif -#if defined(__arm__) || defined(__mips__) +#if defined(__arm__) || defined(__mips__) || defined(__powerpc64__) /* This (ioaddr_t) is exposed to userspace & hence cannot be changed. */ typedef u_int ioaddr_t; #else - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/4] IBMASM: whitespace cleanup
IBMASM: whitespace cleanup
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/misc/ibmasm/command.c | 14 +++---
drivers/misc/ibmasm/dot_command.c | 10 +-
drivers/misc/ibmasm/dot_command.h |2 +-
drivers/misc/ibmasm/event.c |8
drivers/misc/ibmasm/heartbeat.c |2 +-
drivers/misc/ibmasm/i2o.h | 10 +-
drivers/misc/ibmasm/ibmasm.h |6 +++---
drivers/misc/ibmasm/ibmasmfs.c| 24
drivers/misc/ibmasm/lowlevel.c|2 +-
drivers/misc/ibmasm/lowlevel.h| 16
drivers/misc/ibmasm/module.c | 10 +-
drivers/misc/ibmasm/r_heartbeat.c | 10 +-
drivers/misc/ibmasm/remote.h |8
drivers/misc/ibmasm/uart.c|2 +-
14 files changed, 62 insertions(+), 62 deletions(-)
Index: work/drivers/misc/ibmasm/command.c
===
--- work.orig/drivers/misc/ibmasm/command.c
+++ work/drivers/misc/ibmasm/command.c
@@ -18,7 +18,7 @@
*
* Copyright (C) IBM Corporation, 2004
*
- * Author: Max Asböck <[EMAIL PROTECTED]>
+ * Author: Max Asböck <[EMAIL PROTECTED]>
*
*/
@@ -72,7 +72,7 @@ struct command *ibmasm_new_command(struc
static void free_command(struct kobject *kobj)
{
struct command *cmd = to_command(kobj);
-
+
list_del(>queue_node);
atomic_dec(_count);
dbg("command count: %d\n", atomic_read(_count));
@@ -113,14 +113,14 @@ static inline void do_exec_command(struc
exec_next_command(sp);
}
}
-
+
/**
* exec_command
* send a command to a service processor
* Commands are executed sequentially. One command (sp->current_command)
* is sent to the service processor. Once the interrupt handler gets a
* message of type command_response, the message is copied into
- * the current commands buffer,
+ * the current commands buffer,
*/
void ibmasm_exec_command(struct service_processor *sp, struct command *cmd)
{
@@ -160,7 +160,7 @@ static void exec_next_command(struct ser
}
}
-/**
+/**
* Sleep until a command has failed or a response has been received
* and the command status been updated by the interrupt handler.
* (see receive_response).
@@ -182,8 +182,8 @@ void ibmasm_receive_command_response(str
{
struct command *cmd = sp->current_command;
- if (!sp->current_command)
- return;
+ if (!sp->current_command)
+ return;
memcpy_fromio(cmd->buffer, response, min(size, cmd->buffer_size));
cmd->status = IBMASM_CMD_COMPLETE;
Index: work/drivers/misc/ibmasm/dot_command.c
===
--- work.orig/drivers/misc/ibmasm/dot_command.c
+++ work/drivers/misc/ibmasm/dot_command.c
@@ -17,7 +17,7 @@
*
* Copyright (C) IBM Corporation, 2004
*
- * Author: Max Asböck <[EMAIL PROTECTED]>
+ * Author: Max Asböck <[EMAIL PROTECTED]>
*
*/
@@ -44,11 +44,11 @@ void ibmasm_receive_message(struct servi
size = message_size;
switch (header->type) {
- case sp_event:
+ case sp_event:
ibmasm_receive_event(sp, message, size);
break;
case sp_command_response:
- ibmasm_receive_command_response(sp, message, size);
+ ibmasm_receive_command_response(sp, message, size);
break;
case sp_heartbeat:
ibmasm_receive_heartbeat(sp, message, size);
@@ -95,7 +95,7 @@ int ibmasm_send_driver_vpd(struct servic
strcat(vpd_data, IBMASM_DRIVER_VPD);
vpd_data[10] = 0;
vpd_data[15] = 0;
-
+
ibmasm_exec_command(sp, command);
ibmasm_wait_for_response(command, IBMASM_CMD_TIMEOUT_NORMAL);
@@ -118,7 +118,7 @@ struct os_state_command {
* During driver init this function is called with os state "up".
* This causes the service processor to start sending heartbeats the
* driver.
- * During driver exit the function is called with os state "down",
+ * During driver exit the function is called with os state "down",
* causing the service processor to stop the heartbeats.
*/
int ibmasm_send_os_state(struct service_processor *sp, int os_state)
Index: work/drivers/misc/ibmasm/dot_command.h
===
--- work.orig/drivers/misc/ibmasm/dot_command.h
+++ work/drivers/misc/ibmasm/dot_command.h
@@ -17,7 +17,7 @@
*
* Copyright (C) IBM Corporation, 2004
*
- * Author: Max Asböck <[EMAIL PROTECTED]>
+ * Author: Max Asböck <[EMAIL PROTECTED]>
*
*/
Index: work/drivers/misc/ibmasm/event.c
===
--- work.orig/drivers/misc/ibmasm/event.c
+++ work/drivers/misc/ibmasm/event.c
@@ -18,7 +18,7 @@
*
* Copyright (C) IBM Corporation, 2004
*
- * Author: Max Asböck <[EMAIL PROTECTED]>
+ * Author: Max
[patch 3/4] IBMASM: miscellaneous fixes
IBMASM: miscellaneous fixes
Fix some minor issues, such as:
- properly set up ID of keyboard device (was mixed up with mouse)
- constify translation tables
- change some variables to #defines
- set up input device's parent to form proper sysfs hierarchy
- minor formatting changes
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/misc/ibmasm/remote.c | 37 ++---
1 files changed, 18 insertions(+), 19 deletions(-)
Index: work/drivers/misc/ibmasm/remote.c
===
--- work.orig/drivers/misc/ibmasm/remote.c
+++ work/drivers/misc/ibmasm/remote.c
@@ -28,11 +28,10 @@
#include "ibmasm.h"
#include "remote.h"
-static int xmax = 1600;
-static int ymax = 1200;
+#define MOUSE_X_MAX1600
+#define MOUSE_Y_MAX1200
-
-static unsigned short xlate_high[XLATE_SIZE] = {
+static const unsigned short xlate_high[XLATE_SIZE] = {
[KEY_SYM_ENTER & 0xff] = KEY_ENTER,
[KEY_SYM_KPSLASH & 0xff] = KEY_KPSLASH,
[KEY_SYM_KPSTAR & 0xff] = KEY_KPASTERISK,
@@ -81,7 +80,8 @@ static unsigned short xlate_high[XLATE_S
[KEY_SYM_NUM_LOCK & 0xff] = KEY_NUMLOCK,
[KEY_SYM_SCR_LOCK & 0xff] = KEY_SCROLLLOCK,
};
-static unsigned short xlate[XLATE_SIZE] = {
+
+static const unsigned short xlate[XLATE_SIZE] = {
[NO_KEYCODE] = KEY_RESERVED,
[KEY_SYM_SPACE] = KEY_SPACE,
[KEY_SYM_TILDE] = KEY_GRAVE,[KEY_SYM_BKTIC] = KEY_GRAVE,
@@ -133,19 +133,16 @@ static unsigned short xlate[XLATE_SIZE]
[KEY_SYM_Z] = KEY_Z,[KEY_SYM_z] = KEY_Z,
};
-static char remote_mouse_name[] = "ibmasm RSA I remote mouse";
-static char remote_keybd_name[] = "ibmasm RSA I remote keyboard";
-
static void print_input(struct remote_input *input)
{
if (input->type == INPUT_TYPE_MOUSE) {
unsigned char buttons = input->mouse_buttons;
dbg("remote mouse movement: (x,y)=(%d,%d)%s%s%s%s\n",
input->data.mouse.x, input->data.mouse.y,
- (buttons)?" -- buttons:":"",
- (buttons & REMOTE_BUTTON_LEFT)?"left ":"",
- (buttons & REMOTE_BUTTON_MIDDLE)?"middle ":"",
- (buttons & REMOTE_BUTTON_RIGHT)?"right":""
+ (buttons) ? " -- buttons:" : "",
+ (buttons & REMOTE_BUTTON_LEFT) ? "left " : "",
+ (buttons & REMOTE_BUTTON_MIDDLE) ? "middle " : "",
+ (buttons & REMOTE_BUTTON_RIGHT) ? "right" : ""
);
} else {
dbg("remote keypress (code, flag, down):"
@@ -180,7 +177,7 @@ static void send_keyboard_event(struct i
key = xlate_high[code & 0xff];
else
key = xlate[code];
- input_report_key(dev, key, (input->data.keyboard.key_down) ? 1 : 0);
+ input_report_key(dev, key, input->data.keyboard.key_down);
input_sync(dev);
}
@@ -228,20 +225,22 @@ int ibmasm_init_remote_input_dev(struct
mouse_dev->id.vendor = pdev->vendor;
mouse_dev->id.product = pdev->device;
mouse_dev->id.version = 1;
+ mouse_dev->dev.parent = sp->dev;
mouse_dev->evbit[0] = BIT(EV_KEY) | BIT(EV_ABS);
mouse_dev->keybit[LONG(BTN_MOUSE)] = BIT(BTN_LEFT) |
BIT(BTN_RIGHT) | BIT(BTN_MIDDLE);
set_bit(BTN_TOUCH, mouse_dev->keybit);
- mouse_dev->name = remote_mouse_name;
- input_set_abs_params(mouse_dev, ABS_X, 0, xmax, 0, 0);
- input_set_abs_params(mouse_dev, ABS_Y, 0, ymax, 0, 0);
+ mouse_dev->name = "ibmasm RSA I remote mouse";
+ input_set_abs_params(mouse_dev, ABS_X, 0, MOUSE_X_MAX, 0, 0);
+ input_set_abs_params(mouse_dev, ABS_Y, 0, MOUSE_Y_MAX, 0, 0);
- mouse_dev->id.bustype = BUS_PCI;
+ keybd_dev->id.bustype = BUS_PCI;
keybd_dev->id.vendor = pdev->vendor;
keybd_dev->id.product = pdev->device;
- mouse_dev->id.version = 2;
+ keybd_dev->id.version = 2;
+ keybd_dev->dev.parent = sp->dev;
keybd_dev->evbit[0] = BIT(EV_KEY);
- keybd_dev->name = remote_keybd_name;
+ keybd_dev->name = "ibmasm RSA I remote keyboard";
for (i = 0; i < XLATE_SIZE; i++) {
if (xlate_high[i])
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 2/4] IBMASM: dont use extern in function declarations
IBMASM: don't use extern in function declarations
We normally don't use extern in function declarations located in header files.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/misc/ibmasm/ibmasm.h | 64 +--
1 files changed, 32 insertions(+), 32 deletions(-)
Index: work/drivers/misc/ibmasm/ibmasm.h
===
--- work.orig/drivers/misc/ibmasm/ibmasm.h
+++ work/drivers/misc/ibmasm/ibmasm.h
@@ -163,55 +163,55 @@ struct service_processor {
};
/* command processing */
-extern struct command *ibmasm_new_command(struct service_processor *sp, size_t
buffer_size);
-extern void ibmasm_exec_command(struct service_processor *sp, struct command
*cmd);
-extern void ibmasm_wait_for_response(struct command *cmd, int timeout);
-extern void ibmasm_receive_command_response(struct service_processor *sp, void
*response, size_t size);
+struct command *ibmasm_new_command(struct service_processor *sp, size_t
buffer_size);
+void ibmasm_exec_command(struct service_processor *sp, struct command *cmd);
+void ibmasm_wait_for_response(struct command *cmd, int timeout);
+void ibmasm_receive_command_response(struct service_processor *sp, void
*response, size_t size);
/* event processing */
-extern int ibmasm_event_buffer_init(struct service_processor *sp);
-extern void ibmasm_event_buffer_exit(struct service_processor *sp);
-extern void ibmasm_receive_event(struct service_processor *sp, void *data,
unsigned int data_size);
-extern void ibmasm_event_reader_register(struct service_processor *sp, struct
event_reader *reader);
-extern void ibmasm_event_reader_unregister(struct service_processor *sp,
struct event_reader *reader);
-extern int ibmasm_get_next_event(struct service_processor *sp, struct
event_reader *reader);
-extern void ibmasm_cancel_next_event(struct event_reader *reader);
+int ibmasm_event_buffer_init(struct service_processor *sp);
+void ibmasm_event_buffer_exit(struct service_processor *sp);
+void ibmasm_receive_event(struct service_processor *sp, void *data, unsigned
int data_size);
+void ibmasm_event_reader_register(struct service_processor *sp, struct
event_reader *reader);
+void ibmasm_event_reader_unregister(struct service_processor *sp, struct
event_reader *reader);
+int ibmasm_get_next_event(struct service_processor *sp, struct event_reader
*reader);
+void ibmasm_cancel_next_event(struct event_reader *reader);
/* heartbeat - from SP to OS */
-extern void ibmasm_register_panic_notifier(void);
-extern void ibmasm_unregister_panic_notifier(void);
-extern int ibmasm_heartbeat_init(struct service_processor *sp);
-extern void ibmasm_heartbeat_exit(struct service_processor *sp);
-extern void ibmasm_receive_heartbeat(struct service_processor *sp, void
*message, size_t size);
+void ibmasm_register_panic_notifier(void);
+void ibmasm_unregister_panic_notifier(void);
+int ibmasm_heartbeat_init(struct service_processor *sp);
+void ibmasm_heartbeat_exit(struct service_processor *sp);
+void ibmasm_receive_heartbeat(struct service_processor *sp, void *message,
size_t size);
/* reverse heartbeat - from OS to SP */
-extern void ibmasm_init_reverse_heartbeat(struct service_processor *sp, struct
reverse_heartbeat *rhb);
-extern int ibmasm_start_reverse_heartbeat(struct service_processor *sp, struct
reverse_heartbeat *rhb);
-extern void ibmasm_stop_reverse_heartbeat(struct reverse_heartbeat *rhb);
+void ibmasm_init_reverse_heartbeat(struct service_processor *sp, struct
reverse_heartbeat *rhb);
+int ibmasm_start_reverse_heartbeat(struct service_processor *sp, struct
reverse_heartbeat *rhb);
+void ibmasm_stop_reverse_heartbeat(struct reverse_heartbeat *rhb);
/* dot commands */
-extern void ibmasm_receive_message(struct service_processor *sp, void *data,
int data_size);
-extern int ibmasm_send_driver_vpd(struct service_processor *sp);
-extern int ibmasm_send_os_state(struct service_processor *sp, int os_state);
+void ibmasm_receive_message(struct service_processor *sp, void *data, int
data_size);
+int ibmasm_send_driver_vpd(struct service_processor *sp);
+int ibmasm_send_os_state(struct service_processor *sp, int os_state);
/* low level message processing */
-extern int ibmasm_send_i2o_message(struct service_processor *sp);
-extern irqreturn_t ibmasm_interrupt_handler(int irq, void * dev_id);
+int ibmasm_send_i2o_message(struct service_processor *sp);
+irqreturn_t ibmasm_interrupt_handler(int irq, void * dev_id);
/* remote console */
-extern void ibmasm_handle_mouse_interrupt(struct service_processor *sp);
-extern int ibmasm_init_remote_input_dev(struct service_processor *sp);
-extern void ibmasm_free_remote_input_dev(struct service_processor *sp);
+void ibmasm_handle_mouse_interrupt(struct service_processor *sp);
+int ibmasm_init_remote_input_dev(struct service_processor *sp);
+void ibmasm_free_remote_input_dev(struct service_processor *sp);
/* file system */
-extern int
[patch 4/4] IBMASM: must depend on CONFIG_INPUT
IBMASM: must depend on CONFIG_INPUT The driver registers couple of input devices and therefore must depend on CONFIG_INPUT. Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]> --- drivers/misc/Kconfig |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: work/drivers/misc/Kconfig === --- work.orig/drivers/misc/Kconfig +++ work/drivers/misc/Kconfig @@ -6,7 +6,7 @@ menu "Misc devices" config IBM_ASM tristate "Device driver for IBM RSA service processor" - depends on X86 && PCI && EXPERIMENTAL + depends on X86 && PCI && INPUT && EXPERIMENTAL ---help--- This option enables device driver support for in-band access to the IBM RSA (Condor) service processor in eServer xSeries systems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/4] IBMASM - miscellaneous fixes
Hi, Here is bunch of fixes for ibmasm driver. They are untested as I do not have the hardware. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc1
from a randconfig, attached.
arch/i386/mm/discontig.c:107: error: expected identifier or '(' before
numeric constant
arch/i386/mm/discontig.c: In function 'zone_sizes_init':
arch/i386/mm/discontig.c:363: error: 'ZONE_HIGHMEM' undeclared (first
use in this function)
arch/i386/mm/discontig.c:363: error: (Each undeclared identifier is
reported only once
arch/i386/mm/discontig.c:363: error: for each function it appears in.)
make[1]: *** [arch/i386/mm/discontig.o] Error 1
make: *** [arch/i386/mm] Error 2
config.gz
Description: GNU Zip compressed data
Re: [patch 4/4] powerpc 2.6.21-rt1: reduce scheduling latency by changing tlb flush size
At Mon, 14 May 2007 16:40:02 +0200, Arnd Bergmann wrote: > > On Monday 14 May 2007, Tsutomu OWA wrote: > > --- linux-2.6.21-rt1/include/asm-powerpc/tlbflush.h 2007-04-26 > > 12:08:32.0 +0900 > > +++ rt/include/asm-powerpc/tlbflush.h 2007-05-14 16:12:47.0 +0900 > > @@ -25,7 +25,12 @@ struct mm_struct; > > #include > > #include > > > > +#if defined(CONFIG_PPC_CELLEB) && defined(CONFIG_PREEMPT_RT) > > +/* Since tlb flush takes long time on Celleb, reduce it to 1 when Celleb > > && RT */ > > +#define PPC64_TLB_BATCH_NR 1 > With this code, you get silent side-effects of enabling PPC_CELLEB > along with another platform. Yeah, thank you for pointing it out. I'll send revised patch later. > Maybe instead you should change the hpte_need_flush() to always flush > when running on the celleb platform and PREEMPT_RT is enabled. Hmm... Is it in linux-2.6.21? grep'ing it did not help... Is http://patchwork.ozlabs.org/linuxppc/patch?id=10361 is the first place where the hpte_need_flush() appears? -- owa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] powerpc: Add spinlock to request_phb_iospace()
request_phb_iospace() can be called from different CPUs at init
time (at least with my next patch) and thus needs a spinlock. As
for the next patch, this is a temporary workaround for 2.6.22
issues until my rewrite of IO mappings is ready (for 2.6.23)
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
arch/powerpc/mm/pgtable_64.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/powerpc/mm/pgtable_64.c
===
--- linux-cell.orig/arch/powerpc/mm/pgtable_64.c2007-05-15
13:17:59.0 +1000
+++ linux-cell/arch/powerpc/mm/pgtable_64.c 2007-05-15 13:18:32.0
+1000
@@ -322,6 +322,8 @@ EXPORT_SYMBOL(__ioremap);
EXPORT_SYMBOL(iounmap);
EXPORT_SYMBOL(__iounmap);
+static DEFINE_SPINLOCK(phb_io_lock);
+
void __iomem * reserve_phb_iospace(unsigned long size)
{
void __iomem *virt_addr;
@@ -329,8 +331,10 @@ void __iomem * reserve_phb_iospace(unsig
if (phbs_io_bot >= IMALLOC_BASE)
panic("reserve_phb_iospace(): phb io space overflow\n");
+ spin_lock(_io_lock);
virt_addr = (void __iomem *) phbs_io_bot;
phbs_io_bot += size;
+ spin_unlock(_io_lock);
return virt_addr;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] powerpc: Fix IO space on PCI busses created from of_platform
This changes the way of_platform_pci creates PCI host bridges such
that it uses request_phb_iospace() for mapping the IO ports, instead
of using the dynamic hotplug stuff. That guarantees the IO space
stays within the 2GB limit and thus doesn't break half of the legacy
drivers around.
Fixes a couple of warnings due to missing IO space while at it.
This patch is a temporary workaround for 2.6.22 before a more complete
rewrite of IO mappings is merged in 2.6.23
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
arch/powerpc/kernel/of_platform.c | 10 ++
arch/powerpc/kernel/pci_64.c | 23 ++-
2 files changed, 28 insertions(+), 5 deletions(-)
Index: linux-cell/arch/powerpc/kernel/of_platform.c
===
--- linux-cell.orig/arch/powerpc/kernel/of_platform.c 2007-05-15
13:19:43.0 +1000
+++ linux-cell/arch/powerpc/kernel/of_platform.c2007-05-15
13:24:03.0 +1000
@@ -427,11 +427,13 @@ static int __devinit of_pci_phb_probe(st
/* Process "ranges" property */
pci_process_bridge_OF_ranges(phb, dev->node, 0);
- /* Setup IO space.
-* This will not work properly for ISA IOs, something needs to be done
-* about it if we ever generalize that way of probing PCI brigdes
+ /* Setup IO space. We use the non-dynamic version of that code here,
+* which doesn't quite support unplugging. Next kernel release will
+* have a better fix for this.
+* Note also that we don't do ISA, this will also be fixed with a
+* more massive rework.
*/
- pci_setup_phb_io_dynamic(phb, 0);
+ pci_setup_phb_io(phb, 0);
/* Init pci_dn data structures */
pci_devs_phb_init_dynamic(phb);
Index: linux-cell/arch/powerpc/kernel/pci_64.c
===
--- linux-cell.orig/arch/powerpc/kernel/pci_64.c2007-05-15
13:23:30.0 +1000
+++ linux-cell/arch/powerpc/kernel/pci_64.c 2007-05-15 13:53:02.0
+1000
@@ -41,6 +41,7 @@
unsigned long pci_probe_only = 1;
int pci_assign_all_buses = 0;
+static int pci_initial_scan;
static void fixup_resource(struct resource *res, struct pci_dev *dev);
static void do_bus_setup(struct pci_bus *bus);
@@ -604,6 +605,8 @@ static int __init pcibios_init(void)
/* map in PCI I/O space */
phbs_remap_io();
+ pci_initial_scan = 1;
+
printk(KERN_DEBUG "PCI: Probing PCI hardware done\n");
return 0;
@@ -1042,13 +1045,16 @@ void __devinit pci_process_bridge_OF_ran
}
}
-void __init pci_setup_phb_io(struct pci_controller *hose, int primary)
+void __devinit pci_setup_phb_io(struct pci_controller *hose, int primary)
{
unsigned long size = hose->pci_io_size;
unsigned long io_virt_offset;
struct resource *res;
struct device_node *isa_dn;
+ if (size == 0)
+ return;
+
hose->io_base_virt = reserve_phb_iospace(size);
DBG("phb%d io_base_phys 0x%lx io_base_virt 0x%lx\n",
hose->global_number, hose->io_base_phys,
@@ -1069,6 +1075,15 @@ void __init pci_setup_phb_io(struct pci_
res = >io_resource;
res->start += io_virt_offset;
res->end += io_virt_offset;
+
+ /* If this is called after the initial PCI scan, then we need to
+* proceed to IO mappings now
+*/
+ if (pci_initial_scan)
+ __ioremap_explicit(hose->io_base_phys,
+ (unsigned long)hose->io_base_virt,
+ hose->pci_io_size,
+ _PAGE_NO_CACHE | _PAGE_GUARDED);
}
void __devinit pci_setup_phb_io_dynamic(struct pci_controller *hose,
@@ -1078,6 +1093,9 @@ void __devinit pci_setup_phb_io_dynamic(
unsigned long io_virt_offset;
struct resource *res;
+ if (size == 0)
+ return;
+
hose->io_base_virt = __ioremap(hose->io_base_phys, size,
_PAGE_NO_CACHE | _PAGE_GUARDED);
DBG("phb%d io_base_phys 0x%lx io_base_virt 0x%lx\n",
@@ -1106,6 +1124,9 @@ static int get_bus_io_range(struct pci_b
/* Root Bus */
res = >io_resource;
+ if (res->end == 0 && res->start == 0)
+ return 1;
+
*start_virt = pci_io_base + res->start;
*start_phys = *start_virt + hose->io_base_phys
- (unsigned long) hose->io_base_virt;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix/add raw1394 CONFIG_COMPAT code
On Sunday 06 May 2007 19:14, Petr Vandrovec wrote:
> Hello Dan,
>
> This patch makes raw1394 in current Linux git tree (2.6.21-1570) usable to
> 32bit
> applications running on 64bit kernel (tested on i386 app using x86_64
> kernel). I
> had to make following changes:
>
> * read() always failed with -EFAULT. This was happening due to
> raw1394_compat_read copying data to wrong location - access_ok always
> failed as 'r' is kernel address, not user. Whole function just tried to
> copy data from 'r' to 'r', which is not good.
>
> * write(fd, buf, 52) from 32bit app was returning 56. Most of callers did not
> care, but some (arm registration) did, and anyway it looks bad if request
> for
> writing 52 bytes returns 56. And returning sizeof anything in 'int' is not
> good as well. So all functions now return '0' instead of
> sizeof(struct raw1394_request) on success, and write() itself provides
> correct
> return value (it just returns value it was asked to write on success as
> raw1394
> does not do any partial writes at all).
>
> * Related to this was problem that write() could have returned 0 when kernel
> state would become corrupted and moved to different state than
> opened/initialized/connected. Now it returns -EBADFD which seemed
> appropriate.
>
> * And add compat_ioctl. Although all structures are more or less same,
> raw1394_iso_packets got pointer inside, and raw1394_cycle_timer got unwanted
> padding in the middle. I did not add any translation for ioctls passing
> array
> of integers around as integers seem to have same size (32 bits) on all
> architectures supported by Linux.
>
> With this in place I was able to run my test app and grab some mpegs, so I
> believe
> that I got everything necessary done. If you believe I have missed some
> ioctl, yell
> at me.
> Thanks,
> Petr Vandrovec
>
> Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
Reviewed and been testing out fine here on i386.
Acked-by: Dan Dennedy <[EMAIL PROTECTED]>
> diff -uprdN linux/drivers/ieee1394/raw1394.c linux/drivers/ieee1394/raw1394.c
> --- linux/drivers/ieee1394/raw1394.c 2007-05-06 17:45:47.0 -0700
> +++ linux/drivers/ieee1394/raw1394.c 2007-05-06 18:08:05.0 -0700
> @@ -460,7 +460,7 @@ static const char __user *raw1394_compat
> static int
> raw1394_compat_read(const char __user *buf, struct raw1394_request *r)
> {
> - struct compat_raw1394_req __user *cr = (typeof(cr)) r;
> + struct compat_raw1394_req __user *cr = (typeof(cr)) buf;
> if (!access_ok(VERIFY_WRITE, cr, sizeof(struct compat_raw1394_req)) ||
> P(type) ||
> P(error) ||
> @@ -588,7 +588,7 @@ static int state_opened(struct file_info
>
> req->req.length = 0;
> queue_complete_req(req);
> - return sizeof(struct raw1394_request);
> + return 0;
> }
>
> static int state_initialized(struct file_info *fi, struct pending_request
> *req)
> @@ -602,7 +602,7 @@ static int state_initialized(struct file
> req->req.generation = atomic_read(_generation);
> req->req.length = 0;
> queue_complete_req(req);
> - return sizeof(struct raw1394_request);
> + return 0;
> }
>
> switch (req->req.type) {
> @@ -674,7 +674,7 @@ out_set_card:
> }
>
> queue_complete_req(req);
> - return sizeof(struct raw1394_request);
> + return 0;
> }
>
> static void handle_iso_listen(struct file_info *fi, struct pending_request
> *req)
> @@ -866,7 +866,7 @@ static int handle_async_request(struct f
> if (req->req.error) {
> req->req.length = 0;
> queue_complete_req(req);
> - return sizeof(struct raw1394_request);
> + return 0;
> }
>
> hpsb_set_packet_complete_task(packet,
> @@ -884,7 +884,7 @@ static int handle_async_request(struct f
> hpsb_free_tlabel(packet);
> queue_complete_req(req);
> }
> - return sizeof(struct raw1394_request);
> + return 0;
> }
>
> static int handle_iso_send(struct file_info *fi, struct pending_request *req,
> @@ -908,7 +908,7 @@ static int handle_iso_send(struct file_i
> req->req.error = RAW1394_ERROR_MEMFAULT;
> req->req.length = 0;
> queue_complete_req(req);
> - return sizeof(struct raw1394_request);
> + return 0;
> }
>
> req->req.length = 0;
> @@ -928,7 +928,7 @@ static int handle_iso_send(struct file_i
> queue_complete_req(req);
> }
>
> - return sizeof(struct raw1394_request);
> + return 0;
> }
>
> static int handle_async_send(struct file_info *fi, struct pending_request
> *req)
> @@ -943,7 +943,7 @@ static int handle_async_send(struct file
> req->req.error = RAW1394_ERROR_INVALID_ARG;
>
Re: 2.6.21-mm2 - CONFIG_STATISTIC and Intel PowerTOP...
On Wed, 09 May 2007 01:23:22 PDT, Andrew Morton said: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm2/ So I'm trying to get the Intel PowerTop stuff working, and discovered that / proc/timer_stats and/or /proc/tstats has moved to /debug in -mm2 - but only if you're building for S390. For other architechtures it just evaporates entirely. I had to bash this patch in to get it to get included in an x86_64 build: --- linux-2.6.21-mm2/arch/x86_64/Kconfig.statistics 2007-05-14 23:01:00.0 -0400 +++ linux-2.6.21-mm2/arch/x86_64/Kconfig2007-05-14 23:00:45.0 -0400 @@ -793,6 +793,8 @@ source "kernel/Kconfig.marker" +source "lib/Kconfig.statistic" + endmenu source "arch/x86_64/Kconfig.debug" Am just replicating the choice to put it in arch/s390/Kconfig - not sure why it was in there rather than lib/Kconfig.debug - is there a reason here? Having bashed *that* into place, I hit this at kernel link time: WARNING: lib/built-in.o - Section mismatch: reference to .init.text:statistic_hotcpu from .data between 'statistic_hotcpu_notifier' (at offset 0x640) and 'io_tlb_lock' pgpKFhRz7YCOz.pgp Description: PGP signature
Re: [PATCH] sdhci: Add quirk to support polling for card presence
There is apparently at least one instance of the Ricoh SDHCI
implementation out there where card insertion and removal
interrupts do not work - so the only way to detect a change
in the presence of a card is to poll.
This changes adds a polling quirk for the particular model
reported. Others may be affected, but we can add them as they
arise.
As part of this change, caching of the present state is introduced
to reduce the amount of work done when nothing has changed. This
cached state is referred to in the standard interrupt path but as
it is interrupt driven - the cached and new state should never be
the same so it will cause no change in behaviour.
Signed-off-by: Philip Langdale <[EMAIL PROTECTED]>
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ff5bf73..2d5ec61 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -34,6 +34,7 @@ static unsigned int debug_quirks = 0;
/* Controller doesn't like some resets when there is no card inserted. */
#define SDHCI_QUIRK_NO_CARD_NO_RESET (1<<2)
#define SDHCI_QUIRK_SINGLE_POWER_WRITE (1<<3)
+#define SDHCI_QUIRK_NO_CARD_DETECT_INT (1<<4)
static const struct pci_device_id pci_ids[] __devinitdata = {
{
@@ -48,6 +49,16 @@ static const struct pci_device_id pci_ids[] __devinitdata = {
{
.vendor = PCI_VENDOR_ID_RICOH,
.device = PCI_DEVICE_ID_RICOH_R5C822,
+ .subvendor = PCI_SUBVENDOR_ID_FUJITSU_SIEMENS,
+ .subdevice = PCI_SUBDEVICE_ID_FUJITSU_SIEMENS_SI1520,
+ .driver_data= SDHCI_QUIRK_FORCE_DMA |
+ SDHCI_QUIRK_NO_CARD_NO_RESET |
+ SDHCI_QUIRK_NO_CARD_DETECT_INT,
+ },
+
+ {
+ .vendor = PCI_VENDOR_ID_RICOH,
+ .device = PCI_DEVICE_ID_RICOH_R5C822,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
.driver_data= SDHCI_QUIRK_FORCE_DMA |
@@ -788,13 +799,18 @@ static void sdhci_tasklet_card(unsigned long param)
{
struct sdhci_host *host;
unsigned long flags;
+ int present;
+ int polling;
host = (struct sdhci_host*)param;
+ polling = host->chip->quirks & SDHCI_QUIRK_NO_CARD_DETECT_INT;
+
spin_lock_irqsave(>lock, flags);
- if (!(readl(host->ioaddr + SDHCI_PRESENT_STATE) & SDHCI_CARD_PRESENT)) {
- if (host->mrq) {
+ present = readl(host->ioaddr + SDHCI_PRESENT_STATE) &
SDHCI_CARD_PRESENT;
+ if (present != host->present) {
+ if (!present && host->mrq) {
printk(KERN_ERR "%s: Card removed during transfer!\n",
mmc_hostname(host->mmc));
printk(KERN_ERR "%s: Resetting controller.\n",
@@ -806,11 +822,21 @@ static void sdhci_tasklet_card(unsigned long param)
host->mrq->cmd->error = MMC_ERR_FAILED;
tasklet_schedule(>finish_tasklet);
}
- }
- spin_unlock_irqrestore(>lock, flags);
+ host->present = present;
+
+ spin_unlock_irqrestore(>lock, flags);
+
+ mmc_detect_change(host->mmc,
+ polling ? 0 : msecs_to_jiffies(500));
+ } else {
+ spin_unlock_irqrestore(>lock, flags);
+ }
- mmc_detect_change(host->mmc, msecs_to_jiffies(500));
+ if (polling) {
+ host->detect_timer.expires = jiffies + HZ;
+ add_timer(>detect_timer);
+ }
}
static void sdhci_tasklet_finish(unsigned long param)
@@ -865,6 +891,15 @@ static void sdhci_tasklet_finish(unsigned long param)
mmc_request_done(host->mmc, mrq);
}
+static void sdhci_detect_timer(unsigned long data)
+{
+ struct sdhci_host *host;
+
+ host = (struct sdhci_host*)data;
+
+ tasklet_schedule(>card_tasklet);
+}
+
static void sdhci_timeout_timer(unsigned long data)
{
struct sdhci_host *host;
@@ -1329,6 +1364,8 @@ static int __devinit sdhci_probe_slot(struct pci_dev
*pdev, int slot)
*/
mmc->max_blk_count = 65535;
+ host->present = readl(host->ioaddr + SDHCI_PRESENT_STATE) &
SDHCI_CARD_PRESENT;;
+
/*
* Init tasklets.
*/
@@ -1344,6 +1381,12 @@ static int __devinit sdhci_probe_slot(struct pci_dev
*pdev, int slot)
if (ret)
goto untasklet;
+ if (host->chip->quirks & SDHCI_QUIRK_NO_CARD_DETECT_INT) {
+ setup_timer(>detect_timer, sdhci_detect_timer, (unsigned
long)host);
+ host->detect_timer.expires = jiffies + HZ;
+ add_timer(>detect_timer);
+ }
+
sdhci_init(host);
#ifdef CONFIG_MMC_DEBUG
@@ -1396,6 +1439,10 @@ static void sdhci_remove_slot(struct pci_dev *pdev, int
slot)
Re: oprofile broken in 2.6.21 SMP (was Re: Remove constructor from buffer_head)
On Sun, 13 May 2007 16:38:16 -0400 Benjamin LaHaise <[EMAIL PROTECTED]> wrote: > On Sat, May 05, 2007 at 11:31:20AM +0200, Andi Kleen wrote: > > Hmm, after a opcontrol --reset i see the same issue now. Don't know what's > > wrong, but it must be something different from the .20 perfctr allocation > > problem. > > > > It looks like the daemon doesn't get any data from the kernel > > I finally had time to track this down. The breakage is caused by "[PATCH] > x86-64: Let oprofile reserve MSR on all CPUs". Oprofile is already calling > the reserve functions on each CPU in the system when it sets up the MSRs. > This results in oprofile getting a reservation failure on CPUs above 0. The > following makes oprofile adapt to the API change for now -- oprofile > still needs to be modified to perform the reservations earlier during its > initialization, but that's a little bit more involved than the immediate > bug fix. This only affects systems with more than 1 CPU. This patch has > been through limited testing (Athlon 64 X2 and Core 2, but not on the P4) on > x86 and x86-64 (Core 2 only). Unfortunately we've left this a bit too late - your patch is patching code which isn't there any more in mainline and we also need a 2.6.21.x fix. So perhaps we could merge your "immediate bugfix" into -stable and implement the "more involved" fix for 2.6.22. Andi, any preferences? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc1
On 5/15/07, Stefan Richter <[EMAIL PROTECTED]> wrote: Tilman Schmidt wrote: > Am 14.05.2007 22:33 schrieb Jan Engelhardt: >> * Disabling this menu disables all the fluff inside it, except when it doesn't. > Another essential piece of information. I seem to remember other > menus which, when disabled, kept the selection status of the > options inside and just hid them from view. It's a matter of /dependence/ on a menuconfig option whether options inside the menu will be disabled. Not a matter of being located in the menu. Yeah, this is a good solution -- making options inside a menuconfig also dependent on it makes sense. If menuconfig isn't used with strict discipline, we end up with inconsistent and misleading presentation of the kernel configuration. Yes, this really requires discipline on the part of those who add new config options, to also "depends on" the menuconfig they're inside, otherwise we end up with inconsistencies. We can't really make this automatic, or can we? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ARM] Fix hard_smp_processor_id compile error
On Tue, 2007-05-15 at 11:18 +0900, Simon Horman wrote: > "Remove hardcoding of hard_smp_processor_id on UP systems", > 2f4dfe206a2fc07099dfad77a8ea2f4b4ae2140f in Linus' tree, moved > the definition of hard_smp_processor_id linux/smp.h to asm/smp.h > for UP systems. This causes a regression on ARM as the definition > was not added to asm-arm/smp.h. Hi Simon! Thank you for catching and fixing these compile errors. I should install a cross-compiler ASAP. - Fernando > Cc: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]> > Signed-off-by: Simon Horman <[EMAIL PROTECTED]> > > --- > arch/arm/mach-integrator/core.c |1 + > include/asm-arm/smp.h | 10 ++ > 2 files changed, 7 insertions(+), 4 deletions(-) > > arm-unknown-linux-gnu-gcc (GCC) 4.1.1 > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > CC arch/arm/mach-integrator/core.o > arch/arm/mach-integrator/core.c: In function 'integrator_timer_interrupt': > arch/arm/mach-integrator/core.c:264: warning: implicit declaration of > function 'hard_smp_processor_id' > [snip] > LD .tmp_vmlinux1 > arch/arm/mach-integrator/built-in.o: In function `integrator_timer_interrupt': > cpu.c:(.text+0x398): undefined reference to `hard_smp_processor_id' > make: *** [.tmp_vmlinux1] error 1 > > This was produced by running the following in a crosstool cross-compiling > environment: > cp arch/arm/configs/integrator_defconfig .config > yes "" | make modconfig > make > > Index: linux-2.6/arch/arm/mach-integrator/core.c > === > --- linux-2.6.orig/arch/arm/mach-integrator/core.c2007-05-15 > 10:56:06.0 +0900 > +++ linux-2.6/arch/arm/mach-integrator/core.c 2007-05-15 10:56:16.0 > +0900 > @@ -28,6 +28,7 @@ > #include > #include > #include > +#include > > #include "common.h" > > Index: linux-2.6/include/asm-arm/smp.h > === > --- linux-2.6.orig/include/asm-arm/smp.h 2007-05-15 10:51:54.0 > +0900 > +++ linux-2.6/include/asm-arm/smp.h 2007-05-15 10:56:34.0 +0900 > @@ -10,16 +10,16 @@ > #ifndef __ASM_ARM_SMP_H > #define __ASM_ARM_SMP_H > > +#ifndef CONFIG_SMP > +#define hard_smp_processor_id() 0 > +#else > + > #include > #include > #include > > #include > > -#ifndef CONFIG_SMP > -# error " included in non-SMP build" > -#endif > - > #define raw_smp_processor_id() (current_thread_info()->cpu) > > /* > @@ -134,4 +134,6 @@ extern void show_local_irqs(struct seq_f > */ > asmlinkage void do_local_timer(struct pt_regs *); > > +#endif /* CONFIG_SMP */ > + > #endif /* ifndef __ASM_ARM_SMP_H */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: fair clock use in CFS
> Either you have a strange definition of fairness or you chose an > extremely > poor example, Ingo. In a fair scheduler I'd expect all tasks to > get the exact > same amount of time on the processor. Yes, as a long-term average. However, that is impossible to do in the short-term. Some taks has to run first and some task has to run last. Whatever task runs last has had no CPU for all the time the other tasks were running. > So if there are 10 tasks running at > nice 0 and the current task has run for 20msecs before a new task > is swapped > onto the CPU, the new task and *all* other tasks waiting to get > onto the CPU > should get the same 20msecs. What you've described above is fundamentally > unfair - one process running for 20msecs while the 10 processes that are > waiting for their chance each get a period that increases from a > short period > at a predictable rate. The thing you're missing is that you are jumping into the middle of a system that operates based on history. You are assuming concurrent creation of ten tasks with no history and that for some reason the first task gets to run for 20 milliseconds. The scheduler has to compensate for that past or it's not fair. > Some numbers based on your above description: > Process 1 runs for 20msecs > Process 2 runs for 2msecs (20/10 == 2msecs) > Process 3 runs for 2.2msecs (has waited 22msecs, 22/10 == 2.2) > Process 4 runs for 2.4msecs (has waited 24.2msecs - rounded for brevity) > Process 5 runs for 2.7msecs (has waited 26.6msecs - rounded for brevity) > process 6 runs for 3msecs (has waited 30.3msecs) > process 7 runs for 3.3msecs (has waited approx. 33msecs) > process 8 runs for 3.6msecs (has waited approx. 36msecs) > process 9 runs for 3.9msecs (has waited approx. 39msecs) > process 10 runs for 4.2msecs (has waited approx. 42msecs) This is the scheduler making up for the assumed past that you got you into this situation. It cannot simply predict a perfect distribution and apply it because when it chooses how much CPU time to give process 2, it has no idea how many processes will be ready to run when it chooses how much CPU time to give process 10. > Now if the "process time" isn't scaled to match the length of > time that the > process has spent waiting to get on the CPU you get some measure > of fairness > back, but even then the description of CFS you've given shows a > fundamental > unfairness. What is that unfairness? That if there are 10 processes that want to run, all things being equal, someone has to go first and someone has to go last? That over a very short period of time, one process gets 100% of the CPU and the others get none? Yes. This fundamental unfairness is in every scheduler. The issue is what you do to make up for this and create long-term fairness. > However, if you meant that "the new process has spent 20msecs > waiting to get > on the CPU", then the rest of your description does show what I'd > expect from > a fair scheduler. If not, then I guess that CFS is only > "Completely Fair" for > significantly large values of "fair". Same with every scheduler. It's fair over periods of time significantly longer than the context switch interval. > Hrm... Okay, so you're saying that "fair_clock" runs slower the > more process > there are running to keep the above run-up in "Time Spent on CPU" > I noticed > based solely on your initial example? If that is the case, then I > can see the > fairness - its just not visible from a really quick look at the > code and the > simplified description you gave earlier. You have to long over a longer period of time and taking into account that the scheduler also has to compensate for past inequities. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: undeprecate raw driver.
> On Mon, 14 May 2007, Bob Johnston wrote: > > Alan Cox lxorguk.ukuu.org.uk> writes: > > > > > > Why not just use the terms: > > > > * outdated - as a replacement for "deprecated". > > > > > > Because they don't actually mean the same thing ? > > > > "superseded" would probably be a better word, perhaps lacking the > > negative connotations of "deprecated" > except that you *want* the negative connotation associated with the > word "deprecated." you don't just want to say something's been > superseded. rather, you want to say that it's not only been > superseded but that you really want people to *stop using it* and move > up to the newer version; otherwise, there is no motivation to upgrade. > i'm just baffled by the resistance to the word "deprecated" since it > represents *exactly* the idea you want to get across here. its use > in software projects is well-established. why are some people so put > off by it? Let me give this a big AOL-style "me too". Terms such as "deprecated" and "obsolete" have been used by programmers for as long as I can remember, and if you don't know exactly what they mean, you probably should just learn. A feature is "deprecated" if there is some other feature or mechanism that is considered superior to it in all cases. It may just be more efficient, it may avoid potential pitfalls of the deprecated mechanism. You should avoid using a deprecated feature in new code and should try to remove use of it from old code. The classic example of a deprecated function is 'gets'. Deprecated features are generally kept for compatability purposes or because standards require them. A function deprecated on one platform may be perfectly fine on another. You might choose to use a deprecated feature for compatability purposes. It is not urgent to hack use of deprecated features out of existing code. (However, you should evaluate whether the reason for deprecation creates a problem in your code, especially if it's a security issue.) Deprecated features can reasonably be expected to continue to work as well as they ever have. They should not be newly-broken. If a deprecated feature is broken in a new version, that is a regression. A feature is "obsolete" if it no longer serves any purpose. It may be so broken that it is no longer even usable. It might still be technically working but not have any actual case of any significance in which you might want to use it. Linux's Sony CDU-535 driver is obsolete (a driver for an old CDROM drive with a specialized ISA controller that transferred data at well less than 1X and supports only a *very* slow PIO mode). Obsolete features are generally scheduled for removal. They are usually not removed just on the off chance that the removal might harm someone. It may not even be possible to test them and the last time they were tested may have been several major releases ago. One should generally not expect obsolete features to work. Something obsolete may conflict with never features. For example, a driver that breaks with hotpluggable CPUs. One contemplating using an obsolete feature in a new design should have a damn good reason and might possibly need to have their head examined. The raw driver *is* deprecated. It is *not* obsolete. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc1
On 5/15/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > [...] > They are just a menu Ok, so they don't really affect Makefiles / sources (and thus builds). In that case I'd suggest that let's please change the names of such menuconfig options from CONFIG_ to CONFIG_MENU_, otherwise Or perhaps we could change the text associated with these "menu-only" dummy constructs instead ... we really screw the text-based "make oldconfig" folks who think that they're taking a build-related (and not presentation-related) decision when confronted with a: So: Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW) becomes: [MENU] Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW) ? Thanks, Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.22-rc1] gpio interface loosens call restrictions
Loosen gpio_{request,free}() and gpio_direction_{in,out}put() call context
restrictions slightly, so a common idiom is no longer an error: board init
code setting up spinlock-safe GPIOs before tasking is enabled.
The issue was caught by some paranoid code with might_sleep() checks. The
legacy platform-specific GPIO interfaces stick to spinlock-safe GPIOs, so
this change reflects current implementations and won't break anything.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Documentation/gpio.txt |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
--- osk.orig/Documentation/gpio.txt 2007-05-12 21:18:56.0 -0700
+++ osk/Documentation/gpio.txt 2007-05-13 09:35:27.0 -0700
@@ -113,7 +113,9 @@ setting up a platform_device using the G
The return value is zero for success, else a negative errno. It should
be checked, since the get/set calls don't have error returns and since
-misconfiguration is possible. (These calls could sleep.)
+misconfiguration is possible. You should normally issue these calls from
+a task context. However, for spinlock-safe GPIOs it's OK to use them
+before tasking is enabled, as part of early board setup.
For output GPIOs, the value provided becomes the initial output value.
This helps avoid signal glitching during system startup.
@@ -199,7 +201,9 @@ However, many platforms don't currently
Passing invalid GPIO numbers to gpio_request() will fail, as will requesting
GPIOs that have already been claimed with that call. The return value of
-gpio_request() must be checked. (These calls could sleep.)
+gpio_request() must be checked. You should normally issue these calls from
+a task context. However, for spinlock-safe GPIOs it's OK to request GPIOs
+before tasking is enabled, as part of early board setup.
These calls serve two basic purposes. One is marking the signals which
are actually in use as GPIOs, for better diagnostics; systems may have
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc1
Hello, On 5/15/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: [...] They are just a menu Ok, so they don't really affect Makefiles / sources (and thus builds). In that case I'd suggest that let's please change the names of such menuconfig options from CONFIG_ to CONFIG_MENU_, otherwise we really screw the text-based "make oldconfig" folks who think that they're taking a build-related (and not presentation-related) decision when confronted with a: Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW) kind of option. OTOH: Ethernet (1000 Mbit) (MENU_NETDEV_1000) [Y/n] (NEW) taxes a make-oldconfig-using-person's intuition a little less, IMHO. So this'll hopefully take care of Tilman's and Stefan's gripes: On 5/15/07, Tilman Schmidt <[EMAIL PROTECTED]> wrote: (Except for the "this menu" part which might appear rather cryptic to users of the curses based interface who don't see any menu.) [...] Point is, without grepping through the Kconfig the user has no way of knowing that the question comes from a menuconfig in the first place ... ... s/he cannot be sure the option doesn't directly affect code generation. and On 5/15/07, Stefan Richter <[EMAIL PROTECTED]> wrote: One problem is, nobody can see easily whether saying Y is merely the ticket to get into the menu, or whether it on its own will cause something to be built. ? On 5/15/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: that can be switched on or off. It is for those people that start with an arbitrary .config and work their way through menuconfig to disable all the parts they do not want. So, point no. 1: * Disabling this menu disables all the fluff inside it, without needing to enter the menu and disable each option one by one (as was the case previously) This kind of promise was really nice, and why I liked Jan's menuconfig patches a lot. But if: On 5/15/07, Tilman Schmidt <[EMAIL PROTECTED]> wrote: Another essential piece of information. I seem to remember other menus which, when disabled, kept the selection status of the options inside and just hid them from view. is true, then are we really gaining much from these configmenu's? [unrelated] I wish these new constructs were called "configmenu" and _not_ "menuconfig". It causes confusion with the "menuconfig" master Makefile rule which has nothing to do with these new "configmenu"s. [/unrelated] Then of course, one can also turn these menuconfig on (apparently!) to be able to descend into them and select some drivers they like. Point no. 2: * Since Jens Axboe's stance ["default y idiocy"] is to have these menus disabled by default, people should most likely enable them first before they will be able to enter them. I do agree that anything non-essential (even if it's just a presentation menu that doesn't affect builds) must be default n. (I would have wanted them to be always 'y' - it does not affect the build, just opens all menus by default) IMHO, the real problem with "default y" menuconfig's, is that they cause unpleasant surprises to those folks that use the text-based "make oldconfig". They get confronted with choices that they never bothered about (or even knew existed) previously, and have no idea how to answer them -- same problem faced by Tilman, when he used oldconfig. >Seriously, it might be a tad more efficient if the help texts were >written by those who invented the options in the first place. menuconfig NETDEV_1 bool "Ethernet (10GbE)" ---help-- Say Y here to actually be able to go into this menu and select some drivers that we think belong to the "10 Gigabit Ethernet" family. If unsure, it is unwise to say N! See, this looks so fundamentally basic to me that I find it almost funny. YMMV, hence I asked for suggestions from other people. IMHO, those using "oldconfig" are often looking towards doing things quickly ... doesn't help them if they have default y menu's that they need to "?" upon then to see what they're really about. >For a start, it shouldn't require users to grep through Kconfigs >and Makefiles in order to find out what effects an option has. menuconfigs are some special kind in that they combine an option with a menu. Perhaps now that some ->menuconfig patches have gone in, more people will get to know these constructs. I think what happened here is that Jan really only considered the "make menuconfig" users with these new constructs (which makes life really simple for them), but "oldconfig" users were unfortunately in for unpleasant surprises ... On 5/15/07, Stefan Richter <[EMAIL PROTECTED]> wrote: PS: I still believe that Kconfigs shouldn't by overly burdened with presentation. Presentation should mostly be left to the UIs. And the UIs shouldn't be created by kernel hackers... ;-) Kernel dev's can still try, can't they ;-) I do agree that Kconfig is primarily a build dependency language, but also, note that linking Kconfig dependency rules with
[ARM] Fix hard_smp_processor_id compile error
"Remove hardcoding of hard_smp_processor_id on UP systems", 2f4dfe206a2fc07099dfad77a8ea2f4b4ae2140f in Linus' tree, moved the definition of hard_smp_processor_id linux/smp.h to asm/smp.h for UP systems. This causes a regression on ARM as the definition was not added to asm-arm/smp.h. Cc: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]> Signed-off-by: Simon Horman <[EMAIL PROTECTED]> --- arch/arm/mach-integrator/core.c |1 + include/asm-arm/smp.h | 10 ++ 2 files changed, 7 insertions(+), 4 deletions(-) arm-unknown-linux-gnu-gcc (GCC) 4.1.1 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. CC arch/arm/mach-integrator/core.o arch/arm/mach-integrator/core.c: In function 'integrator_timer_interrupt': arch/arm/mach-integrator/core.c:264: warning: implicit declaration of function 'hard_smp_processor_id' [snip] LD .tmp_vmlinux1 arch/arm/mach-integrator/built-in.o: In function `integrator_timer_interrupt': cpu.c:(.text+0x398): undefined reference to `hard_smp_processor_id' make: *** [.tmp_vmlinux1] error 1 This was produced by running the following in a crosstool cross-compiling environment: cp arch/arm/configs/integrator_defconfig .config yes "" | make modconfig make Index: linux-2.6/arch/arm/mach-integrator/core.c === --- linux-2.6.orig/arch/arm/mach-integrator/core.c 2007-05-15 10:56:06.0 +0900 +++ linux-2.6/arch/arm/mach-integrator/core.c 2007-05-15 10:56:16.0 +0900 @@ -28,6 +28,7 @@ #include #include #include +#include #include "common.h" Index: linux-2.6/include/asm-arm/smp.h === --- linux-2.6.orig/include/asm-arm/smp.h2007-05-15 10:51:54.0 +0900 +++ linux-2.6/include/asm-arm/smp.h 2007-05-15 10:56:34.0 +0900 @@ -10,16 +10,16 @@ #ifndef __ASM_ARM_SMP_H #define __ASM_ARM_SMP_H +#ifndef CONFIG_SMP +#define hard_smp_processor_id()0 +#else + #include #include #include #include -#ifndef CONFIG_SMP -# error " included in non-SMP build" -#endif - #define raw_smp_processor_id() (current_thread_info()->cpu) /* @@ -134,4 +134,6 @@ extern void show_local_irqs(struct seq_f */ asmlinkage void do_local_timer(struct pt_regs *); +#endif /* CONFIG_SMP */ + #endif /* ifndef __ASM_ARM_SMP_H */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] Slab allocators: Define common size limitations
Currently we have a maze of configuration variables that determine
the maximum slab size. Worst of all it seems to vary between SLAB and SLUB.
So define a common maximum size for kmalloc. For conveniences sake
we use the maximum size ever supported which is 32 MB. We limit the maximum
size to a lower limit if MAX_ORDER does not allow such large allocations.
For many architectures this patch will have the effect of adding large
possible kmalloc sizes. x86_64 adds 5 new kmalloc sizes. So a small amount
of memory will be needed for these caches (contemporary SLAB has dynamically
sizeable node and cpu structure so the waste is less than in the past).
Most architectures will then be able to allocate object sizes up to MAX_ORDER.
We have had repeated breakage on IA64 because a NUMA structure grew beyond
what the slab allocators supported (thus some of the conditions regarding
cpu sizes and node numbers). This patch will avoid future issues.
CONFIG_LARGE_ALLOCS is no longer necessary so drop it.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
arch/blackfin/Kconfig |8
arch/frv/Kconfig |8
arch/m68knommu/Kconfig|8
arch/sparc64/Kconfig |3 ---
arch/v850/Kconfig |8
include/linux/kmalloc_sizes.h | 20 +++-
include/linux/slab.h | 15 +++
include/linux/slub_def.h | 15 ++-
mm/slab.c | 19 ++-
9 files changed, 34 insertions(+), 70 deletions(-)
Index: slub/include/linux/slab.h
===
--- slub.orig/include/linux/slab.h 2007-05-14 17:26:56.0 -0700
+++ slub/include/linux/slab.h 2007-05-14 17:43:58.0 -0700
@@ -77,6 +77,21 @@ static inline void *kmem_cache_alloc_nod
#endif
/*
+ * The largest kmalloc size supported by the slab allocators is
+ * 32 megabyte (2^25) or the maximum allocatable page order if that is
+ * less than 32 MB.
+ *
+ * WARNING: Its not easy to increase this value since the allocators have
+ * to do various tricks to work around compiler limitations in order to
+ * ensure proper constant folding.
+ */
+#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT) <= 25 ? \
+ (MAX_ORDER + PAGE_SHIFT) : 25)
+
+#define KMALLOC_MAX_SIZE (1UL << KMALLOC_SHIFT_HIGH)
+#define KMALLOC_MAX_ORDER (KMALLOC_SHIFT_HIGH - PAGE_SHIFT)
+
+/*
* Common kmalloc functions provided by all allocators
*/
void *__kmalloc(size_t, gfp_t);
Index: slub/include/linux/slub_def.h
===
--- slub.orig/include/linux/slub_def.h 2007-05-14 17:26:56.0 -0700
+++ slub/include/linux/slub_def.h 2007-05-14 17:43:39.0 -0700
@@ -58,17 +58,6 @@ struct kmem_cache {
*/
#define KMALLOC_SHIFT_LOW 3
-#ifdef CONFIG_LARGE_ALLOCS
-#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT) < 25 ? \
- MAX_ORDER + PAGE_SHIFT - 1 : 25)
-#else
-#if !defined(CONFIG_MMU) || NR_CPUS > 512 || MAX_NUMNODES > 256
-#define KMALLOC_SHIFT_HIGH 20
-#else
-#define KMALLOC_SHIFT_HIGH 18
-#endif
-#endif
-
/*
* We keep the general caches in an array of slab caches that are used for
* 2^x bytes of allocations.
@@ -79,7 +68,7 @@ extern struct kmem_cache kmalloc_caches[
* Sorry that the following has to be that ugly but some versions of GCC
* have trouble with constant propagation and loops.
*/
-static inline int kmalloc_index(int size)
+static inline int kmalloc_index(size_t size)
{
/*
* We should return 0 if size == 0 but we use the smallest object
@@ -87,7 +76,7 @@ static inline int kmalloc_index(int size
*/
WARN_ON_ONCE(size == 0);
- if (size >= (1UL << KMALLOC_SHIFT_HIGH))
+ if (size > KMALLOC_MAX_SIZE)
return -1;
if (size > 64 && size <= 96)
Index: slub/include/linux/kmalloc_sizes.h
===
--- slub.orig/include/linux/kmalloc_sizes.h 2007-05-14 17:26:56.0
-0700
+++ slub/include/linux/kmalloc_sizes.h 2007-05-14 18:42:45.0 -0700
@@ -19,17 +19,27 @@
CACHE(32768)
CACHE(65536)
CACHE(131072)
-#if (NR_CPUS > 512) || (MAX_NUMNODES > 256) || !defined(CONFIG_MMU)
+#if KMALLOC_MAX_SIZE >= 262144
CACHE(262144)
#endif
-#ifndef CONFIG_MMU
+#if KMALLOC_MAX_SIZE >= 524288
CACHE(524288)
+#endif
+#if KMALLOC_MAX_SIZE >= 1048576
CACHE(1048576)
-#ifdef CONFIG_LARGE_ALLOCS
+#endif
+#if KMALLOC_MAX_SIZE >= 2097152
CACHE(2097152)
+#endif
+#if KMALLOC_MAX_SIZE >= 4194304
CACHE(4194304)
+#endif
+#if KMALLOC_MAX_SIZE >= 8388608
CACHE(8388608)
+#endif
+#if KMALLOC_MAX_SIZE >= 16777216
CACHE(16777216)
+#endif
+#if KMALLOC_MAX_SIZE >= 33554432
CACHE(33554432)
-#endif /* CONFIG_LARGE_ALLOCS */
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On Mon, May 14, 2007 at 07:38:23PM +0200, Luca Tettamanti wrote:
> I'm running git 705962cc (which is a commit after -rc1) and I still see
> the OOPS on boot. The patch above is already applied though. Note that
> I'm using the SLAB allocator:
>
> CONFIG_SLAB=y
> # CONFIG_SLUB is not set
> # CONFIG_SLOB is not set
>
>
> Ending clean XFS mount for filesystem: dm-4
> BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
Please send me your .config file.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] lguest: block driver tidyups
1) Use new dma wrapper functions, and handle bind failure (may happen
in future)
2) Use new lgdev_irq() "get me a good interrupt number" function.
3) Use new lguest_map()/lguest_unmap() instead of ioremap/iounmap.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/block/lguest_blk.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
===
--- a/drivers/block/lguest_blk.c
+++ b/drivers/block/lguest_blk.c
@@ -37,7 +37,7 @@ struct blockdev
int irq;
unsigned long phys_addr;
- /* The ioremap'ed block page. */
+ /* The mapped block page. */
struct lguest_block_page *lb_page;
/* We only have a single request outstanding at a time. */
@@ -123,7 +123,7 @@ static void do_write(struct blockdev *bd
pr_debug("lgb: WRITE sector %li\n", (long)req->sector);
setup_req(bd, 1, req, );
- hcall(LHCALL_SEND_DMA, bd->phys_addr, __pa(), 0);
+ lguest_send_dma(bd->phys_addr, );
}
static void do_read(struct blockdev *bd, struct request *req)
@@ -134,7 +134,7 @@ static void do_read(struct blockdev *bd,
setup_req(bd, 0, req, >dma);
empty_dma();
- hcall(LHCALL_SEND_DMA, bd->phys_addr, __pa(), 0);
+ lguest_send_dma(bd->phys_addr, );
}
static void do_lgb_request(request_queue_t *q)
@@ -183,13 +183,13 @@ static int lguestblk_probe(struct lguest
return -ENOMEM;
spin_lock_init(>lock);
- bd->irq = lgdev->index+1;
+ bd->irq = lgdev_irq(lgdev);
bd->req = NULL;
bd->dma.used_len = 0;
bd->dma.len[0] = 0;
bd->phys_addr = (lguest_devices[lgdev->index].pfn << PAGE_SHIFT);
- bd->lb_page = (void *)ioremap(bd->phys_addr, PAGE_SIZE);
+ bd->lb_page = lguest_map(bd->phys_addr, 1);
if (!bd->lb_page) {
err = -ENOMEM;
goto out_free_bd;
@@ -225,7 +225,9 @@ static int lguestblk_probe(struct lguest
if (err)
goto out_cleanup_queue;
- hcall(LHCALL_BIND_DMA, bd->phys_addr, __pa(>dma), (1<<8)+bd->irq);
+ err = lguest_bind_dma(bd->phys_addr, >dma, 1, bd->irq);
+ if (err)
+ goto out_free_irq;
bd->disk->major = bd->major;
bd->disk->first_minor = 0;
@@ -241,6 +243,8 @@ static int lguestblk_probe(struct lguest
lgdev->private = bd;
return 0;
+out_free_irq:
+ free_irq(bd->irq, bd);
out_cleanup_queue:
blk_cleanup_queue(bd->disk->queue);
out_put_disk:
@@ -248,7 +252,7 @@ out_unregister_blkdev:
out_unregister_blkdev:
unregister_blkdev(bd->major, "lguestblk");
out_unmap:
- iounmap(bd->lb_page);
+ lguest_unmap(bd->lb_page);
out_free_bd:
kfree(bd);
return err;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] lguest: console driver tidyups
1) Use new lguest_send_dma & lguest_bind_dma functions.
2) sparse: lguest_cons can be static.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/char/hvc_lguest.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
===
--- a/drivers/char/hvc_lguest.c
+++ b/drivers/char/hvc_lguest.c
@@ -36,7 +36,7 @@ static int put_chars(u32 vtermno, const
dma.len[1] = 0;
dma.addr[0] = __pa(buf);
- hcall(LHCALL_SEND_DMA, LGUEST_CONSOLE_DMA_KEY, __pa(), 0);
+ lguest_send_dma(LGUEST_CONSOLE_DMA_KEY, );
return count;
}
@@ -59,7 +59,7 @@ static int get_chars(u32 vtermno, char *
return count;
}
-struct hv_ops lguest_cons = {
+static struct hv_ops lguest_cons = {
.get_chars = get_chars,
.put_chars = put_chars,
};
@@ -75,14 +75,17 @@ console_initcall(cons_init);
static int lguestcons_probe(struct lguest_device *lgdev)
{
- lgdev->private = hvc_alloc(0, lgdev->index+1, _cons, 256);
+ int err;
+
+ lgdev->private = hvc_alloc(0, lgdev_irq(lgdev), _cons, 256);
if (IS_ERR(lgdev->private))
return PTR_ERR(lgdev->private);
- if (!hcall(LHCALL_BIND_DMA, LGUEST_CONSOLE_DMA_KEY, __pa(_input),
- (1<<8) + lgdev->index+1))
+ err = lguest_bind_dma(LGUEST_CONSOLE_DMA_KEY, _input, 1,
+ lgdev_irq(lgdev));
+ if (err)
printk("lguest console: failed to bind buffer.\n");
- return 0;
+ return err;
}
static struct lguest_driver lguestcons_drv = {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] lguest: netdriver tidyups and a bugfix
Feedback from Jeff Garzik:
1) Use netdev_priv instead of dev->priv.
2) Check for ioremap failure
3) iounmap on failure.
4) Wrap SEND_DMA and BIND_DMA calls
5) Don't set NETIF_F_SG unless we set NETIF_F_NO_CSUM
6) Use SET_NETDEV_DEV()
7) Don't set dev->irq, mem_start & mem_end (deprecated)
Feedback from Chrisoph Hellwig:
8) Use lguest_map()/lguest_unmap() helpers instead of ioremap/iounmap.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/net/lguest_net.c | 54 ++
1 file changed, 31 insertions(+), 23 deletions(-)
===
--- a/drivers/net/lguest_net.c
+++ b/drivers/net/lguest_net.c
@@ -22,7 +22,6 @@
#include
#include
#include
-#include
#define SHARED_SIZEPAGE_SIZE
#define MAX_LANS 4
@@ -34,6 +33,9 @@ struct lguestnet_info
struct lguest_net *peer;
unsigned long peer_phys;
unsigned long mapsize;
+
+ /* The lguest_device I come from */
+ struct lguest_device *lgdev;
/* My peerid. */
unsigned int me;
@@ -84,7 +86,7 @@ static void skb_to_dma(const struct sk_b
static void lguestnet_set_multicast(struct net_device *dev)
{
- struct lguestnet_info *info = dev->priv;
+ struct lguestnet_info *info = netdev_priv(dev);
if ((dev->flags & (IFF_PROMISC|IFF_ALLMULTI)) || dev->mc_count)
info->peer[info->me].mac[0] |= PROMISC_BIT;
@@ -110,13 +112,13 @@ static void transfer_packet(struct net_d
struct sk_buff *skb,
unsigned int peernum)
{
- struct lguestnet_info *info = dev->priv;
+ struct lguestnet_info *info = netdev_priv(dev);
struct lguest_dma dma;
skb_to_dma(skb, skb_headlen(skb), );
pr_debug("xfer length %04x (%u)\n", htons(skb->len), skb->len);
- hcall(LHCALL_SEND_DMA, peer_key(info,peernum), __pa(), 0);
+ lguest_send_dma(peer_key(info, peernum), );
if (dma.used_len != skb->len) {
dev->stats.tx_carrier_errors++;
pr_debug("Bad xfer to peer %i: %i of %i (dma %p/%i)\n",
@@ -137,7 +139,7 @@ static int lguestnet_start_xmit(struct s
{
unsigned int i;
int broadcast;
- struct lguestnet_info *info = dev->priv;
+ struct lguestnet_info *info = netdev_priv(dev);
const unsigned char *dest = ((struct ethhdr *)skb->data)->h_dest;
pr_debug("%s: xmit %02x:%02x:%02x:%02x:%02x:%02x\n",
@@ -162,7 +164,7 @@ static int lguestnet_start_xmit(struct s
/* Find a new skb to put in this slot in shared mem. */
static int fill_slot(struct net_device *dev, unsigned int slot)
{
- struct lguestnet_info *info = dev->priv;
+ struct lguestnet_info *info = netdev_priv(dev);
/* Try to create and register a new one. */
info->skb[slot] = netdev_alloc_skb(dev, ETH_HLEN + ETH_DATA_LEN);
if (!info->skb[slot]) {
@@ -180,7 +182,7 @@ static irqreturn_t lguestnet_rcv(int irq
static irqreturn_t lguestnet_rcv(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
- struct lguestnet_info *info = dev->priv;
+ struct lguestnet_info *info = netdev_priv(dev);
unsigned int i, done = 0;
for (i = 0; i < ARRAY_SIZE(info->dma); i++) {
@@ -220,7 +222,7 @@ static int lguestnet_open(struct net_dev
static int lguestnet_open(struct net_device *dev)
{
int i;
- struct lguestnet_info *info = dev->priv;
+ struct lguestnet_info *info = netdev_priv(dev);
/* Set up our MAC address */
memcpy(info->peer[info->me].mac, dev->dev_addr, ETH_ALEN);
@@ -232,8 +234,8 @@ static int lguestnet_open(struct net_dev
if (fill_slot(dev, i) != 0)
goto cleanup;
}
- if (!hcall(LHCALL_BIND_DMA, peer_key(info, info->me), __pa(info->dma),
- (NUM_SKBS << 8) | dev->irq))
+ if (lguest_bind_dma(peer_key(info,info->me), info->dma,
+ NUM_SKBS, lgdev_irq(info->lgdev)) != 0)
goto cleanup;
return 0;
@@ -246,13 +248,13 @@ static int lguestnet_close(struct net_de
static int lguestnet_close(struct net_device *dev)
{
unsigned int i;
- struct lguestnet_info *info = dev->priv;
+ struct lguestnet_info *info = netdev_priv(dev);
/* Clear all trace: others might deliver packets, we'll ignore it. */
memset(>peer[info->me], 0, sizeof(info->peer[info->me]));
/* Deregister sg lists. */
- hcall(LHCALL_BIND_DMA, peer_key(info, info->me), __pa(info->dma), 0);
+ lguest_unbind_dma(peer_key(info, info->me), info->dma);
for (i = 0; i < ARRAY_SIZE(info->dma); i++)
dev_kfree_skb(info->skb[i]);
return 0;
@@ -290,30 +292,34 @@ static int lguestnet_probe(struct lguest
/* Turning on/off promisc will call dev->set_multicast_list.
* We don't actually
[PATCH 3/6] lguest: guest tidyups
Jeff Garzik argued forcefully that __pa() should not appear in
drivers, and that struct netdevice's irq field should not be used.
Christoph Hellwig suggested that I run sparse, and provide an
lguest-specific wrapper for mapping/unmapping virtual device memory.
Results:
1) send-dma and bind-dma hypercall wrappers for drivers to use,
2) formalization of the convention that devices can use the irq
corresponding to their index on the lguest_bus.
3) Helper to map and unmap virtual device memory (not classic __iomem).
4) lguest.c should include "lguest_bus.h" for lguest_devices declaration.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/lguest/lguest.c | 33 +
drivers/lguest/lguest_bus.c |2 +-
include/linux/lguest_bus.h | 17 -
3 files changed, 50 insertions(+), 2 deletions(-)
===
--- a/drivers/lguest/lguest.c
+++ b/drivers/lguest/lguest.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -35,6 +36,7 @@
#include
#include
#include
+#include
/* Declarations for definitions in lguest_guest.S */
extern char lguest_noirq_start[], lguest_noirq_end[];
@@ -99,6 +101,37 @@ void async_hcall(unsigned long call,
next_call = 0;
}
local_irq_restore(flags);
+}
+
+void lguest_send_dma(unsigned long key, struct lguest_dma *dma)
+{
+ dma->used_len = 0;
+ hcall(LHCALL_SEND_DMA, key, __pa(dma), 0);
+}
+
+int lguest_bind_dma(unsigned long key, struct lguest_dma *dmas,
+ unsigned int num, u8 irq)
+{
+ if (!hcall(LHCALL_BIND_DMA, key, __pa(dmas), (num << 8) | irq))
+ return -ENOMEM;
+ return 0;
+}
+
+void lguest_unbind_dma(unsigned long key, struct lguest_dma *dmas)
+{
+ hcall(LHCALL_BIND_DMA, key, __pa(dmas), 0);
+}
+
+/* For guests, device memory can be used as normal memory, so we cast away the
+ * __iomem to quieten sparse. */
+void *lguest_map(unsigned long phys_addr, unsigned long pages)
+{
+ return (__force void *)ioremap(phys_addr, PAGE_SIZE*pages);
+}
+
+void lguest_unmap(void *addr)
+{
+ iounmap((__force void __iomem *)addr);
}
static unsigned long save_fl(void)
===
--- a/drivers/lguest/lguest_bus.c
+++ b/drivers/lguest/lguest_bus.c
@@ -136,7 +136,7 @@ static int __init lguest_bus_init(void)
return 0;
/* Devices are in page above top of "normal" mem. */
- lguest_devices = ioremap(max_pfn << PAGE_SHIFT, PAGE_SIZE);
+ lguest_devices = lguest_map(max_pfnindex + 1;
+}
+
+/* dma args must not be vmalloced! */
+void lguest_send_dma(unsigned long key, struct lguest_dma *dma);
+int lguest_bind_dma(unsigned long key, struct lguest_dma *dmas,
+ unsigned int num, u8 irq);
+void lguest_unbind_dma(unsigned long key, struct lguest_dma *dmas);
+
+/* Map the virtual device space */
+void *lguest_map(unsigned long phys_addr, unsigned long pages);
+void lguest_unmap(void *);
struct lguest_driver {
const char *name;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] lguest: kbuild tidyups
Sam Ravnborg says lg-objs is deprecated, use lg-y. Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> --- drivers/lguest/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) === --- a/drivers/lguest/Makefile +++ b/drivers/lguest/Makefile @@ -3,5 +3,5 @@ obj-$(CONFIG_LGUEST_GUEST) += lguest.o l # Host requires the other files, which can be a module. obj-$(CONFIG_LGUEST) += lg.o -lg-objs := core.o hypercalls.o page_tables.o interrupts_and_traps.o \ +lg-y := core.o hypercalls.o page_tables.o interrupts_and_traps.o \ segments.o io.o lguest_user.o switcher.o - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] lguest: host code tidyups
Christoph Hellwig said runs sparse:
1) page_tables.c unnecessary initialization
2) Change prototype of run_lguest and do cast in caller instead (when we add
__user to cast, it runs over another line).
Al Viro pointed out the ugly cast in push_lguest_stack():
3) Stick with unsigned long for arg, removes 4 casts in total.
Most importantly, I now realize that Christoph's incorrect ranting
about lgread_u32 et al was in fact a subtle ploy to make me diagnose
the real issue: sparse 0.3 complains about casting a __user pointer
to/from u32, but not an "unsigned long". They are (currently)
equivalent for lguest, but this is a much better solution than __force.
Kudos, Christoph, for such masterful manipulation!
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/lguest/core.c | 37 -
drivers/lguest/hypercalls.c |9 +++-
drivers/lguest/interrupts_and_traps.c | 15 +++--
drivers/lguest/io.c |2 -
drivers/lguest/lg.h | 37 -
drivers/lguest/lguest_user.c |2 -
drivers/lguest/page_tables.c |2 -
drivers/lguest/segments.c |6 ++---
include/linux/lguest_launcher.h |2 -
9 files changed, 56 insertions(+), 56 deletions(-)
===
--- a/drivers/lguest/core.c
+++ b/drivers/lguest/core.c
@@ -212,39 +212,40 @@ int lguest_address_ok(const struct lgues
}
/* Just like get_user, but don't let guest access lguest binary. */
-u32 lgread_u32(struct lguest *lg, u32 addr)
+u32 lgread_u32(struct lguest *lg, unsigned long addr)
{
u32 val = 0;
/* Don't let them access lguest binary */
if (!lguest_address_ok(lg, addr, sizeof(val))
|| get_user(val, (u32 __user *)addr) != 0)
- kill_guest(lg, "bad read address %u", addr);
+ kill_guest(lg, "bad read address %#lx", addr);
return val;
}
-void lgwrite_u32(struct lguest *lg, u32 addr, u32 val)
+void lgwrite_u32(struct lguest *lg, unsigned long addr, u32 val)
{
if (!lguest_address_ok(lg, addr, sizeof(val))
|| put_user(val, (u32 __user *)addr) != 0)
- kill_guest(lg, "bad write address %u", addr);
-}
-
-void lgread(struct lguest *lg, void *b, u32 addr, unsigned bytes)
+ kill_guest(lg, "bad write address %#lx", addr);
+}
+
+void lgread(struct lguest *lg, void *b, unsigned long addr, unsigned bytes)
{
if (!lguest_address_ok(lg, addr, bytes)
|| copy_from_user(b, (void __user *)addr, bytes) != 0) {
/* copy_from_user should do this, but as we rely on it... */
memset(b, 0, bytes);
- kill_guest(lg, "bad read address %u len %u", addr, bytes);
- }
-}
-
-void lgwrite(struct lguest *lg, u32 addr, const void *b, unsigned bytes)
+ kill_guest(lg, "bad read address %#lx len %u", addr, bytes);
+ }
+}
+
+void lgwrite(struct lguest *lg, unsigned long addr, const void *b,
+unsigned bytes)
{
if (!lguest_address_ok(lg, addr, bytes)
|| copy_to_user((void __user *)addr, b, bytes) != 0)
- kill_guest(lg, "bad write address %u len %u", addr, bytes);
+ kill_guest(lg, "bad write address %#lx len %u", addr, bytes);
}
static void set_ts(void)
@@ -294,7 +295,7 @@ static void run_guest_once(struct lguest
: "memory", "%edx", "%ecx", "%edi", "%esi");
}
-int run_guest(struct lguest *lg, char *__user user)
+int run_guest(struct lguest *lg, unsigned long __user *user)
{
while (!lg->dead) {
unsigned int cr2 = 0; /* Damn gcc */
@@ -302,8 +303,8 @@ int run_guest(struct lguest *lg, char *_
/* Hypercalls first: we might have been out to userspace */
do_hypercalls(lg);
if (lg->dma_is_pending) {
- if (put_user(lg->pending_dma, (unsigned long *)user) ||
- put_user(lg->pending_key, (unsigned long *)user+1))
+ if (put_user(lg->pending_dma, user) ||
+ put_user(lg->pending_key, user+1))
return -EFAULT;
return sizeof(unsigned long)*2;
}
@@ -367,7 +368,7 @@ int run_guest(struct lguest *lg, char *_
if (deliver_trap(lg, lg->regs->trapnum))
continue;
- kill_guest(lg, "unhandled trap %i at %#x (%#x)",
+ kill_guest(lg, "unhandled trap %li at %#lx (%#lx)",
lg->regs->trapnum, lg->regs->eip,
lg->regs->trapnum == 14 ? cr2 : lg->regs->errcode);
}
@@ -420,7 +421,7 @@ static int __init init(void)
lock_cpu_hotplug();
if (cpu_has_pge) { /* We have a broader idea of "global". */
Re: [RFC] Orphaning MMC host drivers
On Monday 14 May 2007 21:38, Pierre Ossman wrote: > @@ -2382,6 +2391,9 @@ M:[EMAIL PROTECTED] > W: http://popies.net/meye/ > S: Maintained > > +MOTOROLA I.MX MMCI DRIVER > +S: Orphan > + > MOUSE AND MISC DEVICES [GENERAL] > P: Alessandro Rubini > M:[EMAIL PROTECTED] > @@ -2902,6 +2914,9 @@ M:[EMAIL PROTECTED] Hello Pierre, as I have already stated, I would take responsibility for I.MX SDHC driver. It is not perfect, but I am trying to keep and fix it and I would be happy to receive feedback or help from others. The actual state is such, that read works for both SD/MMC, but write is failing. The write path is timing sensitive and some other kernel changes above 2.6.18 exposes these problems. I have some ideas, how to dig for this problem in mind, but I did not find time to try them yet. I have already proposed MAINTAINERS change, but you did not liked to point L: field to "sdhci-devel" list. I propose ALKML mailing list this time as you suggested. Do you include change or should I send my own patch for review? Would you suggest change in driver name to MOTOROLA I.MX MMCI DRIVER ? Best wishes Pavel My original proposal with L: changed to ALKML Index: linux-2.6.21/MAINTAINERS === --- linux-2.6.21.orig/MAINTAINERS +++ linux-2.6.21/MAINTAINERS @@ -1717,6 +1717,13 @@ M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] (subscribers-only) S: Maintained +IMX MMC/SD HOST CONTROLLER INTERFACE DRIVER +P: Pavel Pisa +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +W: http://mmc.drzeus.cx/wiki/Controllers/Freescale/SDHC +S: Maintained + INFINIBAND SUBSYSTEM P: Roland Dreier M: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fair clock use in CFS
It is possible to do something like this in check_preemption ? delta = curr->fair_key - first->fair_key; if (delta > ??? [scale it as you wish] || (curr->key > first->key) && (curr->wait_runtime > ??? [simple funtion of curr->weight]) ) preempt Forgive me, there is typo in the above check. It should be "less than" since we are controlling negative lags. (curr->key > first->key) && (curr->wait_runtime < ??? [simple funtion of curr->weight]) ) A limit control on wait_runtime may prevent a high weight task from running for too long, so that others get executed a little earlier. Just a thought :-) Ting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Freezeable workqueues [Was: 2.6.22-rc1: Broken suspend on SMP with tifm]
> > > > - Do we need freezeable workqueues ? > > > > Well, we have at least one case in which they appear to be useful. > I need freezeable wq exactly for the fact that they are synchronized with suspend/resume. My workitem may do device_register/unregister and it can (and will be) scheduled from irq handler during resume. As far as I understand, before freezeable wqs, kthreads were the only way to achieve this behavior, which is less convenient. Need Mail bonding? Go to the Yahoo! Mail Q for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list=396546091 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc1 creating an invalid randconfig
I recently was using randconfig to fish for some broken configs, when I came to a .config[1], The failure appeared to be related to CONFIGFS, so I mailed the maintainer, and was told CONFIGFS is selected but SYSFS is not, and it shouldn't be possible unless edited by hand which I didn't. Next, I forwarded the conversation to the Kconfig maintainer, to where I was told it's not directly a Kconfig problem. Anyone know which maintainer takes responsibility in this area? [1] http://avuton.googlepages.com/config Thanks -- avuton -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc1 xfs lockdep messages
I tend to get this when doing unlinks or rms in xfs:
===
[ INFO: possible circular locking dependency detected ]
2.6.22-rc1-paravirt #1382
---
rm/1451 is trying to acquire lock:
(&(>i_lock)->mr_lock/1){--..}, at: [] xfs_ilock+0x64/0x8d [xfs]
but task is already holding lock:
(&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x64/0x8d [xfs]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&(>i_lock)->mr_lock){}:
[] __lock_acquire+0xa1f/0xbab
[] lock_acquire+0x7b/0x9f
[] down_write_nested+0x3d/0x58
[] xfs_ilock+0x64/0x8d [xfs]
[] xfs_iget_core+0x2bd/0x605 [xfs]
[] xfs_iget+0xac/0x133 [xfs]
[] xfs_trans_iget+0xdc/0x142 [xfs]
[] xfs_ialloc+0xa5/0x457 [xfs]
[] xfs_dir_ialloc+0x6d/0x260 [xfs]
[] xfs_create+0x2f4/0x5a6 [xfs]
[] xfs_vn_mknod+0x130/0x1e5 [xfs]
[] xfs_vn_create+0x12/0x14 [xfs]
[] vfs_create+0x9b/0xe5
[] open_namei+0x176/0x593
[] do_filp_open+0x26/0x3b
[] do_sys_open+0x43/0xc7
[] sys_open+0x1c/0x1e
[] syscall_call+0x7/0xb
[] 0x
-> #0 (&(>i_lock)->mr_lock/1){--..}:
[] __lock_acquire+0x903/0xbab
[] lock_acquire+0x7b/0x9f
[] down_write_nested+0x3d/0x58
[] xfs_ilock+0x64/0x8d [xfs]
[] xfs_lock_inodes+0x11d/0x12f [xfs]
[] xfs_lock_dir_and_entry+0xc2/0xcc [xfs]
[] xfs_remove+0x213/0x425 [xfs]
[] xfs_vn_unlink+0x1c/0x44 [xfs]
[] vfs_unlink+0x75/0xb3
[] do_unlinkat+0x96/0x12c
[] sys_unlink+0x13/0x15
[] syscall_call+0x7/0xb
[] 0x
other info that might help us debug this:
3 locks held by rm/1451:
#0: (>i_mutex/1){--..}, at: [] do_unlinkat+0x5e/0x12c
#1: (>i_mutex){--..}, at: [] mutex_lock+0x1f/0x23
#2: (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x64/0x8d
[xfs]
stack backtrace:
[] show_trace_log_lvl+0x1a/0x30
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] print_circular_bug_tail+0x5f/0x68
[] __lock_acquire+0x903/0xbab
[] lock_acquire+0x7b/0x9f
[] down_write_nested+0x3d/0x58
[] xfs_ilock+0x64/0x8d [xfs]
[] xfs_lock_inodes+0x11d/0x12f [xfs]
[] xfs_lock_dir_and_entry+0xc2/0xcc [xfs]
[] xfs_remove+0x213/0x425 [xfs]
[] xfs_vn_unlink+0x1c/0x44 [xfs]
[] vfs_unlink+0x75/0xb3
[] do_unlinkat+0x96/0x12c
[] sys_unlink+0x13/0x15
[] syscall_call+0x7/0xb
===
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ALSA sound driver for SEGA Dreamcast AICA (pcm)
I still noticed some type cleanups, and possibly a good debug message..
On Mon, May 14, 2007 at 11:14:55PM +0100, Adrian McMenamin wrote:
> +/* spu_memload - write to SPU address space */
> +static void spu_memload(u32 toi, void __iomem * from, int length)
> +{
> + u32 __iomem *froml = from;
> + u32 __iomem *to = (u32 __iomem *) (SPU_MEMORY_BASE + toi);
> + int i, val;
You should use "void *from" because it's not IO memory. Also, use "u32 val"
since that is the native type of "u32 *from".
> + length = DIV_ROUND_UP(length, 4);
> + spu_write_wait();
> + for (i = 0; i < length; i++) {
> + val = *froml;
> + writel(val, to);
> + froml++;
> + to++;
> + if (i && !(i % 8))
> + spu_write_wait();
> + }
> +}
It seems a small simplification is possible:
/* remove first spu_write_wait(); */
for (i = 0; i < length; i++) {
if (!(i % 8))
spu_write_wait();
val = *froml;
...
}
> +/* SPU specific functions */
> +/* spu_write_wait - wait for G2-SH FIFO to clear */
> +static void spu_write_wait(void)
> +{
> + int time_count;
> + time_count = 0;
> + while (1) {
> + if (!(readl(G2_FIFO) & 0x11))
> + break;
> + /* To ensure hardware failure doesn't wedge kernel */
> + time_count++;
> + if (time_count > 0x1)
Maybe this deserves a printk() message?
> +static struct snd_pcm_hardware snd_pcm_aica_playback_hw = {
> + .info = (SNDRV_PCM_INFO_NONINTERLEAVED),
> + .formats =
> + (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE |
> + SNDRV_PCM_FMTBIT_IMA_ADPCM),
> + .rates = SNDRV_PCM_RATE_8000_48000,
> + .rate_min = 8000,
> + .rate_max = 48000,
> + .channels_min = 1,
> + .channels_max = 2,
> + .buffer_bytes_max = AICA_BUFFER_SIZE,
> + .period_bytes_min = AICA_PERIOD_SIZE,
> + .period_bytes_max = AICA_PERIOD_SIZE,
> + .periods_min = AICA_PERIOD_NUMBER,
> + .periods_max = AICA_PERIOD_NUMBER,
> +};
> +
> +static int aica_dma_transfer(int channels, int buffer_size,
> + struct snd_pcm_substream *substream)
> +{
> + int q, err, period_offset;
> + struct snd_card_aica *dreamcastcard;
> + struct snd_pcm_runtime *runtime;
> + err = 0;
> + dreamcastcard = substream->pcm->private_data;
> + period_offset = dreamcastcard->clicks;
> + period_offset %= (AICA_PERIOD_NUMBER / channels);
> + runtime = substream->runtime;
> + for (q = 0; q < channels; q++) {
> + err = dma_xfer(AICA_DMA_CHANNEL,
> +(unsigned long)(runtime->dma_area +
> +(AICA_BUFFER_SIZE * q) /
> +channels +
> +AICA_PERIOD_SIZE *
> +period_offset),
> +AICA_CHANNEL0_OFFSET + q * CHANNEL_OFFSET +
> +AICA_PERIOD_SIZE * period_offset,
> +buffer_size / channels, AICA_DMA_MODE);
> + if (unlikely(err < 0))
> + break;
> + dma_wait_for_completion(AICA_DMA_CHANNEL);
> + }
> + return err;
> +}
> +
> +static void startup_aica(struct snd_card_aica *dreamcastcard)
> +{
> + spu_memload(AICA_CHANNEL0_CONTROL_OFFSET,
> + (u8 *) dreamcastcard->channel,
Why cast to u8 *? spu_memload gets a void *, and the void * is casted
into an u32 *.
> + sizeof(struct aica_channel));
> + aica_chn_start();
> +}
> +
> +static void run_spu_dma(struct work_struct *work)
> +{
> + int buffer_size;
> + struct snd_pcm_substream *substream;
> + struct snd_pcm_runtime *runtime;
> + struct snd_card_aica *dreamcastcard;
> + struct spu_work_holder *holder = container_of(work, struct
> spu_work_holder, spu_dma_work);
> + substream = holder-> sspointer;
> + dreamcastcard = substream->pcm->private_data;
> + runtime = substream->runtime;
> + if (unlikely(dreamcastcard->dma_check == 0)) {
> + buffer_size = frames_to_bytes(runtime, runtime->buffer_size);
> + if (runtime->channels > 1)
> + dreamcastcard->channel->flags |= 0x01;
> + aica_dma_transfer(runtime->channels, buffer_size, substream);
> + startup_aica(dreamcastcard);
> + dreamcastcard->clicks =
> + buffer_size / (AICA_PERIOD_SIZE * runtime->channels);
> + return;
> + } else {
> + aica_dma_transfer(runtime->channels,
> + AICA_PERIOD_SIZE * runtime->channels,
> + substream);
> + snd_pcm_period_elapsed(dreamcastcard->substream);
> +
Re: [PATCH] Add driver for Dallas DS1682 elapsed time recorder
On Sun, 13 May 2007 01:43:42 -0600
Grant Likely <[EMAIL PROTECTED]> wrote:
>
> Here is the 3rd iteration with the following changes:
> - Modified to be an i2c "new style" driver based on David Brownell's work
> - uses the new prototype for i2c_smbus_read_i2c_block_data() for block data
> reads instead of a single byte at a time.
>
> drivers/i2c/chips/ds1682.c | 270
>
> 1 files changed, 270 insertions(+), 0 deletions(-)
This version of the patch omitted the changes to drivers/i2c/chips/Kconfig
and drivers/i2c/chips/Makefile, which I assume was accidental.
As usual, I generated the delta so we can see what was done:
From: Grant Likely <[EMAIL PROTECTED]>
- Modified to be an i2c "new style" driver based on David Brownell's work
- uses the new prototype for i2c_smbus_read_i2c_block_data() for block data
reads instead of a single byte at a time.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
Cc: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/i2c/chips/ds1682.c | 333 ---
1 files changed, 121 insertions(+), 212 deletions(-)
diff -puN
drivers/i2c/chips/ds1682.c~i2c-add-driver-for-dallas-ds1682-elapsed-time-recorder-update
drivers/i2c/chips/ds1682.c
---
a/drivers/i2c/chips/ds1682.c~i2c-add-driver-for-dallas-ds1682-elapsed-time-recorder-update
+++ a/drivers/i2c/chips/ds1682.c
@@ -16,132 +16,106 @@
/*
* The DS1682 elapsed timer recorder is a simple device that implements
- * one elapsed time counters, one event counter, an alarm signal and 10
+ * one elapsed time counter, one event counter, an alarm signal and 10
* bytes of general purpose EEPROM.
*
* This driver provides access to the DS1682 counters and user data via
* the sysfs. The following attributes are added to the device node:
- * elapsed_time (u32): Total elapsed event time in 1/4s resolution
+ * elapsed_time (u32): Total elapsed event time in ms resolution
* alarm_time (u32): When elapsed time exceeds the value in alarm_time,
* then the alarm pin is asserted.
* event_count (u16): number of times the event pin has gone low.
- * user_data (u8[10]): general purpose EEPROM
+ * eeprom (u8[10]): general purpose EEPROM
*
* Counter registers and user data are both read/write unless the device
- * has been write protected. This driver does not support turning on write
+ * has been write protected. This driver does not support turning off write
* protection. Once write protection is turned on, it is impossible to
- * turn off so I have left the feature out of this driver to avoid
+ * turn it off again, so I have left the feature out of this driver to avoid
* accidental enabling, but it is trivial to add write protect support.
*
*/
-#include
#include
#include
#include
#include
#include
-#include
#include
#include
#include
+#include
/* Device registers */
-#define DS1682_ADDR0x6B
-
#define DS1682_REG_CONFIG 0x00
#define DS1682_REG_ALARM 0x01
#define DS1682_REG_ELAPSED 0x05
#define DS1682_REG_EVT_CNTR0x09
-#define DS1682_REG_USER_DATA 0x0b
+#define DS1682_REG_EEPROM 0x0b
#define DS1682_REG_RESET 0x1d
#define DS1682_REG_WRITE_DISABLE 0x1e
#define DS1682_REG_WRITE_MEM_DISABLE 0x1f
-/*
- * Probing class
- */
-static unsigned short normal_i2c[] = { DS1682_ADDR, I2C_CLIENT_END };
-
-I2C_CLIENT_INSMOD;
-
-/*
- * Low level chip access functions
- */
-static int ds1682_read(struct i2c_client *client, int reg, void *buf, int len)
-{
- u8 *bytes = buf;
- int val;
-
- while (len--) {
- val = i2c_smbus_read_byte_data(client, reg++);
- if (val < 0)
- return -EIO;
- *bytes++ = val;
- }
- return 0;
-}
+#define DS1682_EEPROM_SIZE 10
/*
* Generic counter attributes
*/
-static int ds1682_attr_to_reg(struct device_attribute *attr, int *regsize);
-
-static ssize_t ds1682_show(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t ds1682_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
- u32 val = 0;
- int reg;
- int regsize;
-
- dev_dbg(dev, "ds1682_show() called for %s\n", attr->attr.name);
-
- /* Get the register address */
- reg = ds1682_attr_to_reg(attr, );
- if (reg < 0)
- return -EIO;
+ struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+ struct i2c_client *client = to_i2c_client(dev);
+ __le32 val = 0;
+ int rc;
+
+ dev_dbg(dev, "ds1682_show() called on %s\n", attr->attr.name);
/* Read the register */
- if (ds1682_read(to_i2c_client(dev), reg, , regsize))
+ rc =
Re: why does x86 "make defconfig" build a single, lonely module?
On 5/14/07, James Bottomley <[EMAIL PROTECTED]> wrote: On Mon, 2007-05-14 at 17:53 +0530, Satyam Sharma wrote: > > I guess this is probably the behaviour that James wanted originally? No ... you're still not reading the explanation in the thread: The wait scan module is designed to wait for scans of driver modules. Whether SCSI=y or m has no effect on this ... you can still have modular drivers with built in SCSI. Ah, I see why we _want_ this built as a _module_ only, and don't even want to expose the Kconfig option to the user, lest he screw himself later. But dangling "default m"'s or "default y"'s not exposed to the user do stand out discomfortingly in Kconfigs, wish there was a better way to handle this. > > Anyway, attached patch (subsumes previous one) cleans up all this. > > Now, scsi_wait_scan is the only guy who controls waiting upon async > > scans to complete: > > > > If SCSI=n, SCSI_WAIT_SCAN=n, obviously. > > > > If SCSI=y, SCSI_WAIT_SCAN=y, so it gets built-in and is run at > > late_initcall. > > > > If SCSI=m, SCSI_WAIT_SCAN=m too and would hopefully be run > > by the initrd/initramfs scripts to wait for async SCSI bus scans to > > finish before allowing the boot to proceed. > > > > [ Attached patch does _not_ expose SCSI_WAIT_SCAN to the > > user at kernel configuration time, so if somebody wants it to be > > built as a module even when SCSI=y (why would anybody > > want that, doesn't make much sense to me to modprobe > > scsi_wait_scan _after_ boot-up), it would not be possible to > > do so. But if someone really wants that, let me know, we can > > add a depends, tristate "..." and help in this Kconfig option to > > accomplish that too. ] > > This has sadly become a one-person thread, but Robert informs > me in private mail that we can further clean/simplify the patch: > > [subsumes both previous patches] > > Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> > > --- > > drivers/scsi/Kconfig |3 +-- > drivers/scsi/scsi_scan.c |5 + > 2 files changed, 2 insertions(+), 6 deletions(-) > > --- > > diff -ruNp a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig > --- a/drivers/scsi/Kconfig2007-05-10 23:19:32.0 +0530 > +++ b/drivers/scsi/Kconfig2007-05-14 17:59:51.0 +0530 > @@ -243,9 +243,8 @@ config SCSI_SCAN_ASYNC > > config SCSI_WAIT_SCAN > tristate > - default m > depends on SCSI > - depends on MODULES > + default SCSI > > menu "SCSI Transports" > depends on SCSI > diff -ruNp a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c > --- a/drivers/scsi/scsi_scan.c2007-05-14 16:06:43.0 +0530 > +++ b/drivers/scsi/scsi_scan.c2007-05-14 16:10:34.0 +0530 > @@ -184,14 +184,11 @@ int scsi_complete_async_scans(void) > /* Only exported for the benefit of scsi_wait_scan */ > EXPORT_SYMBOL_GPL(scsi_complete_async_scans); > > -#ifndef MODULE > /* > * For async scanning we need to wait for all the scans to complete before > * trying to mount the root fs. Otherwise non-modular drivers may not be ready > - * yet. > + * yet. This is done by scsi_wait_scan. > */ > -late_initcall(scsi_complete_async_scans); > -#endif This is actually not in mainline. It's an incorrect patch in -mm. The problem with late_initcall is that they queue in link order ... so any SCSI module (and there a few) linked after this won't benefit from it. The obvious hack is to have a separate file with this in the final link. However, Matthew Wilcox thinks he can do better. Yeah, thanks for this explanation. -mm is probably what confused me here. I did consider the fact that late_initcall's are called in link order, but saw that there was an explicit effort (hack?) in drivers/scsi/Makefile to keep scsi_wait_scan last so that SCSI devices probe earlier ... not that this helps us with modular drivers, of course. Thanks, Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] scalable rw_mutex
On Mon, May 14, 2007 at 12:59:10PM +0200, Peter Zijlstra wrote: > Changes include: > > - wmb+rmb != mb > - ->state folded into ->waiter > > --- > Subject: scalable rw_mutex > > Scalable reader/writer lock. > > Its scalable in that the read count is a percpu counter and the reader fast > path does not write to a shared cache-line. > > Its not FIFO fair, but starvation proof by alternating readers and writers. Hmmm... brlock reincarnates, but as sleeplock. ;-) I believe that there are a few severe problems in this code, search for "!!!" to quickly find the specific areas that concern me. Thanx, Paul > Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]> > --- > include/linux/rwmutex.h | 82 > kernel/Makefile |3 > kernel/rwmutex.c| 232 > > 3 files changed, 316 insertions(+), 1 deletion(-) List of races that must be resolved: 1. Read acquire vs. write acquire. rw_mutex_read_lock() invokes __rw_mutex_read_trylock(), if this fails, invokes rw_mutex_read_lock_slow(). __rw_mutex_read_trylock() increments the per-CPU counter, does smp_mb(), picks up ->waiter: if non-NULL decrements the per-CPU counter, does a barrier(), does wake_up_process() on the task fetched from ->waiter. Return failure. Otherwise, return success. rw_mutex_read_lock_slow() increments ->read_waiters, acquires ->read_mutex, increments the ->readers counter, and decrements the ->read_waiters counter. It then fetches ->waiter, and, if non-NULL, wakes up the tasks. Either way, releases ->read_mutex. rw_mutex_write_lock_nested(): acquires ->write_mutex, which prevents any writer-writer races. Acquires ->read_mutex, which does -not- prevent readers from continuing to acquire. Sets ->waiter to current, which -does- (eventually) stop readers. smp_mb(), then invokes rw_mutex_writer_wait() for the sum of the per-CPU counters to go to zero. !In principle, this could be indefinitely postponed, but in practice would require an infinite number of reading tasks, so probably OK to ignore. ;-) This can occur because the readers unconditionally increment their per-CPU counters, and decrement it only later. The smp_mb()s currently in the reader and the writer code forms a Dekker-algorithm-like barrier, preventing both the reader and writer from entering their critical section, as required. 2. Read acquire vs. write release (need to avoid reader sleeping forever, even in the case where no one ever uses the lock again). rw_mutex_read_lock() invokes __rw_mutex_read_trylock(), if this fails, invokes rw_mutex_read_lock_slow(). __rw_mutex_read_trylock() increments the per-CPU counter, does smp_mb(), picks up ->waiter: if non-NULL decrements the per-CPU counter, does a barrier(), does wake_up_process() on the task fetched from ->waiter. Return failure. Otherwise, return success. rw_mutex_read_lock_slow() increments ->read_waiters, acquires ->read_mutex, increments the ->readers counter, and decrements the ->read_waiters counter. It then fetches ->waiter, and, if non-NULL, wakes up the tasks. Either way, releases ->read_mutex. rw_mutex_write_unlock(): pick up ->read_waiters, release ->read_mutex, if copy of ->read_waiters was non-NULL do slow path (but refetches ->read_waiters??? why??? [Ah -- refetched each time through the loop in the rw_mutex_writer_wait() macro), NULL out ->waiter, then release ->write_mutex. Slow path: Pick up ->waiter, make sure it is us, set state to uninterruptible, loop while ->read_waiters less than the value fetched earlier from ->read_waiters, scheduling each time through, set state back to running. (!!!This is subject to indefinite postponement by a flurry of readers, see the commentary
[PATCH] docbook: make kernel-locking table readable
From: Randy Dunlap <[EMAIL PROTECTED]> Andi Kleen pointed out to me that the kernel locking cheat sheet table entries are unreadable. Make table entries smaller so that pdf and ps output is readable (columns were being overwritten and garbled) by using abbreviations. This allows the tables to fit on one page cleanly. Add a Legend for the abbreviations: SLIS: spin_lock_irqsave SLI: spin_lock_irq SL: spin_lock SLBH: spin_lock_bh DI: down_interruptible Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- Documentation/DocBook/kernel-locking.tmpl | 123 +++--- 1 file changed, 78 insertions(+), 45 deletions(-) --- linux-2.6.22-rc1.orig/Documentation/DocBook/kernel-locking.tmpl +++ linux-2.6.22-rc1/Documentation/DocBook/kernel-locking.tmpl @@ -551,10 +551,12 @@ spin_lock_irqsave(), which is a superset of all other spinlock primitives. + Table of Locking Requirements + IRQ Handler A @@ -576,97 +578,128 @@ IRQ Handler B -spin_lock_irqsave +SLIS None Softirq A -spin_lock_irq -spin_lock_irq -spin_lock +SLI +SLI +SL Softirq B -spin_lock_irq -spin_lock_irq -spin_lock -spin_lock +SLI +SLI +SL +SL Tasklet A -spin_lock_irq -spin_lock_irq -spin_lock -spin_lock +SLI +SLI +SL +SL None Tasklet B -spin_lock_irq -spin_lock_irq -spin_lock -spin_lock -spin_lock +SLI +SLI +SL +SL +SL None Timer A -spin_lock_irq -spin_lock_irq -spin_lock -spin_lock -spin_lock -spin_lock +SLI +SLI +SL +SL +SL +SL None Timer B -spin_lock_irq -spin_lock_irq -spin_lock -spin_lock -spin_lock -spin_lock -spin_lock +SLI +SLI +SL +SL +SL +SL +SL None User Context A -spin_lock_irq -spin_lock_irq -spin_lock_bh -spin_lock_bh -spin_lock_bh -spin_lock_bh -spin_lock_bh -spin_lock_bh +SLI +SLI +SLBH +SLBH +SLBH +SLBH +SLBH +SLBH None User Context B +SLI +SLI +SLBH +SLBH +SLBH +SLBH +SLBH +SLBH +DI +None + + + + + + + +Legend for Locking Requirements Table + + + + +SLIS +spin_lock_irqsave + + +SLI spin_lock_irq -spin_lock_irq -spin_lock_bh -spin_lock_bh -spin_lock_bh -spin_lock_bh -spin_lock_bh + + +SL +spin_lock + + +SLBH spin_lock_bh + + +DI down_interruptible -None + - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Define new percpu interface for shared data -- version 2
Changes from previous version:
1. Shorter macro and section names.
2. Detailed change log.
per cpu data section contains two types of data. One set which is exclusively
accessed by the local cpu and the other set which is per cpu, but also shared
by remote cpus. In the current kernel, these two sets are not clearely
separated out. This can potentially cause the same data cacheline shared
between the two sets of data, which will result in unnecessary bouncing of the
cacheline between cpus.
One way to fix the problem is to cacheline align the remotely accessed per cpu
data, both at the beginning and at the end. Because of the padding at both ends,
this will likely cause some memory wastage and also the interface to achieve
this is not clean.
This patch:
Moves the remotely accessed per cpu data (which is currently marked
as cacheline_aligned_in_smp) into a different section, where all the data
elements are cacheline aligned. And as such, this differentiates the local
only data and remotely accessed data cleanly.
Signed-off-by: Fenghua Yu <[EMAIL PROTECTED]>
Acked-by: Suresh Siddha <[EMAIL PROTECTED]>
---
arch/alpha/kernel/vmlinux.lds.S |5 +
arch/arm/kernel/vmlinux.lds.S |5 +
arch/cris/arch-v32/vmlinux.lds.S |5 +
arch/frv/kernel/vmlinux.lds.S |5 +
arch/i386/kernel/vmlinux.lds.S|7 +--
arch/ia64/kernel/vmlinux.lds.S|1 +
arch/m32r/kernel/vmlinux.lds.S|5 +
arch/mips/kernel/vmlinux.lds.S|5 +
arch/parisc/kernel/vmlinux.lds.S |7 +++
arch/powerpc/kernel/vmlinux.lds.S |7 +--
arch/ppc/kernel/vmlinux.lds.S |5 +
arch/s390/kernel/vmlinux.lds.S|5 +
arch/sh/kernel/vmlinux.lds.S |5 +
arch/sh64/kernel/vmlinux.lds.S|5 +
arch/sparc/kernel/vmlinux.lds.S |5 +
arch/sparc64/kernel/vmlinux.lds.S |5 +
arch/x86_64/kernel/vmlinux.lds.S |6 ++
arch/xtensa/kernel/vmlinux.lds.S |5 +
include/asm-generic/percpu.h |8
include/asm-generic/vmlinux.lds.h | 10 ++
include/asm-i386/percpu.h |5 +
include/asm-ia64/percpu.h | 10 ++
include/asm-powerpc/percpu.h |7 +++
include/asm-s390/percpu.h |7 +++
include/asm-sparc64/percpu.h |7 +++
include/asm-x86_64/percpu.h |7 +++
26 files changed, 82 insertions(+), 72 deletions(-)
diff -Nurp linux-2.6.21-rc7.0/arch/alpha/kernel/vmlinux.lds.S
linux-2.6.21-rc7.1/arch/alpha/kernel/vmlinux.lds.S
--- linux-2.6.21-rc7.0/arch/alpha/kernel/vmlinux.lds.S 2007-05-01
07:32:58.0 -0700
+++ linux-2.6.21-rc7.1/arch/alpha/kernel/vmlinux.lds.S 2007-05-14
12:44:40.0 -0700
@@ -69,10 +69,7 @@ SECTIONS
. = ALIGN(8);
SECURITY_INIT
- . = ALIGN(8192);
- __per_cpu_start = .;
- .data.percpu : { *(.data.percpu) }
- __per_cpu_end = .;
+ PERCPU(8192)
. = ALIGN(2*8192);
__init_end = .;
diff -Nurp linux-2.6.21-rc7.0/arch/arm/kernel/vmlinux.lds.S
linux-2.6.21-rc7.1/arch/arm/kernel/vmlinux.lds.S
--- linux-2.6.21-rc7.0/arch/arm/kernel/vmlinux.lds.S2007-05-01
07:32:58.0 -0700
+++ linux-2.6.21-rc7.1/arch/arm/kernel/vmlinux.lds.S2007-05-14
12:44:40.0 -0700
@@ -59,10 +59,7 @@ SECTIONS
usr/built-in.o(.init.ramfs)
__initramfs_end = .;
#endif
- . = ALIGN(4096);
- __per_cpu_start = .;
- *(.data.percpu)
- __per_cpu_end = .;
+ PERCPU(4096)
#ifndef CONFIG_XIP_KERNEL
__init_begin = _stext;
*(.init.data)
diff -Nurp linux-2.6.21-rc7.0/arch/cris/arch-v32/vmlinux.lds.S
linux-2.6.21-rc7.1/arch/cris/arch-v32/vmlinux.lds.S
--- linux-2.6.21-rc7.0/arch/cris/arch-v32/vmlinux.lds.S 2007-05-01
07:32:59.0 -0700
+++ linux-2.6.21-rc7.1/arch/cris/arch-v32/vmlinux.lds.S 2007-05-14
12:44:40.0 -0700
@@ -92,10 +92,7 @@ SECTIONS
}
SECURITY_INIT
- . = ALIGN (8192);
- __per_cpu_start = .;
- .data.percpu : { *(.data.percpu) }
- __per_cpu_end = .;
+ PERCPU(8192)
#ifdef CONFIG_BLK_DEV_INITRD
.init.ramfs : {
diff -Nurp linux-2.6.21-rc7.0/arch/frv/kernel/vmlinux.lds.S
linux-2.6.21-rc7.1/arch/frv/kernel/vmlinux.lds.S
--- linux-2.6.21-rc7.0/arch/frv/kernel/vmlinux.lds.S2007-05-01
07:32:59.0 -0700
+++ linux-2.6.21-rc7.1/arch/frv/kernel/vmlinux.lds.S2007-05-14
12:44:40.0 -0700
@@ -57,10 +57,7 @@ SECTIONS
__alt_instructions_end = .;
.altinstr_replacement : { *(.altinstr_replacement) }
- . = ALIGN(4096);
- __per_cpu_start = .;
- .data.percpu : { *(.data.percpu) }
- __per_cpu_end = .;
+ PERCPU(4096)
#ifdef CONFIG_BLK_DEV_INITRD
. = ALIGN(4096);
diff -Nurp linux-2.6.21-rc7.0/arch/i386/kernel/vmlinux.lds.S
linux-2.6.21-rc7.1/arch/i386/kernel/vmlinux.lds.S
--- linux-2.6.21-rc7.0/arch/i386/kernel/vmlinux.lds.S
Re: [PATCH 1/2] kbuild: Add "Section mismatch" warning whitelist for powerpc
Hi, On 5/14/07, Kumar Gala <[EMAIL PROTECTED]> wrote: On May 14, 2007, at 6:06 AM, Sam Ravnborg wrote: > On Mon, May 14, 2007 at 06:53:32PM +0800, Li Yang wrote: >> This patch fixes the following "Section mismatch" warnings when >> build powerpc platforms. >> >> - >> WARNING: arch/powerpc/mm/built-in.o - Section mismatch: reference to >> .init.text:early_get_page from .text between >> 'pte_alloc_one_kernel' (at >> offset 0xc68) and 'pte_alloc_one' >> WARNING: mm/built-in.o - Section mismatch: reference to >> .init.text:set_up_list3s from .text between >> 'kmem_cache_create' (at offset >> 0x20300) and 'cache_reap' >> - This warnings should be handled by __init_refok instead. Actually, once __init_refok comes in, would we need any other whitelisting mechanism at all? I think the exception patterns in secref_whitelist() and those two other whitelisting functions (init_section_ref_ok and exit_section_ref_ok) could all be subsumed and made redundant if / when __init_refok is used in the actual sources. Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab hang on boot
On Mon, 14 May 2007 16:46:17 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> wrote: > -#define KMALLOC_SHIFT_HIGH 25 > +#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT) =< 25 ? \ > + MAX_ORDER + PAGE_SHIFT - 1 : 25) Would prefer to see a lot more parentheses in there. Who knows what the arch is using for MAX_ORDER and PAGE_SHIFT. > #if !defined(CONFIG_MMU) || NR_CPUS > 512 || MAX_NUMNODES > 256 > #define KMALLOC_SHIFT_HIGH 20 > @@ -86,6 +87,9 @@ static inline int kmalloc_index(int size >*/ > WARN_ON_ONCE(size == 0); > > + if (size >= (1UL << KMALLOC_SHIFT_HIGH)) > + return -1; > + `size' is `int'. Deliberately comparing it to an unsigned long seems unpointful. Arguably, `size' should be size_t. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Use the new percpu interface for shared data -- version 2
Currently most of the per cpu data, which is accessed by different cpus, has a
cacheline_aligned_in_smp attribute. Move all this data to the new per cpu
shared data section: .data.percpu.shared_aligned.
This will seperate the percpu data which is referenced frequently by other cpus
from the local only percpu data.
Signed-off-by: Fenghua Yu <[EMAIL PROTECTED]>
Acked-by: Suresh Siddha <[EMAIL PROTECTED]>
---
arch/i386/kernel/init_task.c |2 +-
arch/i386/kernel/irq.c |2 +-
arch/ia64/kernel/smp.c |2 +-
arch/x86_64/kernel/init_task.c |2 +-
kernel/sched.c |2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff -Nurp linux-2.6.21-rc7.0/arch/i386/kernel/init_task.c
linux-2.6.21-rc7.1/arch/i386/kernel/init_task.c
--- linux-2.6.21-rc7.0/arch/i386/kernel/init_task.c 2007-04-15
16:50:57.0 -0700
+++ linux-2.6.21-rc7.1/arch/i386/kernel/init_task.c 2007-05-14
12:44:43.0 -0700
@@ -42,5 +42,5 @@ EXPORT_SYMBOL(init_task);
* per-CPU TSS segments. Threads are completely 'soft' on Linux,
* no more per-task TSS's.
*/
-DEFINE_PER_CPU(struct tss_struct, init_tss)
cacheline_internodealigned_in_smp = INIT_TSS;
+DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, init_tss) = INIT_TSS;
diff -Nurp linux-2.6.21-rc7.0/arch/i386/kernel/irq.c
linux-2.6.21-rc7.1/arch/i386/kernel/irq.c
--- linux-2.6.21-rc7.0/arch/i386/kernel/irq.c 2007-05-01 07:32:59.0
-0700
+++ linux-2.6.21-rc7.1/arch/i386/kernel/irq.c 2007-05-14 12:44:43.0
-0700
@@ -21,7 +21,7 @@
#include
#include
-DEFINE_PER_CPU(irq_cpustat_t, irq_stat) cacheline_internodealigned_in_smp;
+DEFINE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
EXPORT_PER_CPU_SYMBOL(irq_stat);
DEFINE_PER_CPU(struct pt_regs *, irq_regs);
diff -Nurp linux-2.6.21-rc7.0/arch/ia64/kernel/smp.c
linux-2.6.21-rc7.1/arch/ia64/kernel/smp.c
--- linux-2.6.21-rc7.0/arch/ia64/kernel/smp.c 2007-04-15 16:50:57.0
-0700
+++ linux-2.6.21-rc7.1/arch/ia64/kernel/smp.c 2007-05-14 12:44:43.0
-0700
@@ -70,7 +70,7 @@ static volatile struct call_data_struct
#define IPI_KDUMP_CPU_STOP 3
/* This needs to be cacheline aligned because it is written to by *other*
CPUs. */
-static DEFINE_PER_CPU(u64, ipi_operation) cacheline_aligned;
+static DEFINE_PER_CPU_SHARED_ALIGNED(u64, ipi_operation);
extern void cpu_halt (void);
diff -Nurp linux-2.6.21-rc7.0/arch/x86_64/kernel/init_task.c
linux-2.6.21-rc7.1/arch/x86_64/kernel/init_task.c
--- linux-2.6.21-rc7.0/arch/x86_64/kernel/init_task.c 2007-04-15
16:50:57.0 -0700
+++ linux-2.6.21-rc7.1/arch/x86_64/kernel/init_task.c 2007-05-14
12:44:43.0 -0700
@@ -44,7 +44,7 @@ EXPORT_SYMBOL(init_task);
* section. Since TSS's are completely CPU-local, we want them
* on exact cacheline boundaries, to eliminate cacheline ping-pong.
*/
-DEFINE_PER_CPU(struct tss_struct, init_tss)
cacheline_internodealigned_in_smp = INIT_TSS;
+DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, init_tss) = INIT_TSS;
/* Copies of the original ist values from the tss are only accessed during
* debugging, no special alignment required.
diff -Nurp linux-2.6.21-rc7.0/kernel/sched.c linux-2.6.21-rc7.1/kernel/sched.c
--- linux-2.6.21-rc7.0/kernel/sched.c 2007-05-01 07:33:07.0 -0700
+++ linux-2.6.21-rc7.1/kernel/sched.c 2007-05-14 12:44:43.0 -0700
@@ -263,7 +263,7 @@ struct rq {
struct lock_class_key rq_lock_key;
};
-static DEFINE_PER_CPU(struct rq, runqueues) cacheline_aligned_in_smp;
+static DEFINE_PER_CPU_SHARED_ALIGNED(struct rq, runqueues);
static DEFINE_MUTEX(sched_hotcpu_mutex);
static inline int cpu_of(struct rq *rq)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-git10/11: files getting truncated on xfs? or maybe an nlink problem?
On Sat, May 12, 2007 at 07:56:20AM -0700, Jeremy Fitzhardinge wrote: > David Chinner wrote: > > What I don't understand is that on unmount dirty xfs inodes get > > written out. Clearly this is not happening - either there's a hole > > in the writeback logic (unlikely - it was unchanged) or we've missed > > some case where we need to update the filesize and mark the inode > > dirty. > > > > H - if the write was just a short append to the file, then the > > block that was written to should already be mapped. Then we'll just > > look up the extent by doing a BMAPI_READ lookup, set the type to > > IOMAP_READ and add the block to ioend we are building. > > > > Well, that result I mailed you showed that the difference was just over > 16k, and that there was a 32 block difference in the final extent > length. Does that fit with this theory? Yes - because when we do specualtive allocation of 64k beyond EOF by default on appends > > The type IOMAP_READ determines the I/O completion behaviour - in this case > > it is xfs_end_bio_read(), which fails to update the file size > > > > Bingo. > > > > A patch for you to try, Jeremy. I've just started a test run on it... > > > > Thanks, I'll give it a spin. Have you reproduced the bug yourself? No, not yet. I haven't had chance because I'm travelling at the moment Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [announce] Intel announces the PowerTOP utility for Linux
Looks like the radeon driver has the same problem as the i915 driver mentioned on the known problems page - I get 60 wakeups/sec from it on my Compaq X1000 laptop (Radeon 9000 graphics) while in X, which essentially prevents entry into C3. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + timer_stats-slimmed-down-using-statistics-infrastucture.patch added to -mm tree
On Mon, 2007-05-14 at 10:26 +0200, Martin Peschke wrote: > > > >> [EMAIL PROTECTED] timer_stats]# cat data > > > > this patch changes the userspace API though, and breaks PowerTOP :( > > Though I think it was unfortunate to add the "old" proc API in 2.6.21. > timer_stats is clearly labeled as debug stuff in config help, which is why > debugfs would have been a proper place. but it's not there, it's in it's current place. And userspace apps depend on it... so what's the reason to change this after it became ABI ? If there's a good one I can fix powertop.. but oh well I hope you kept the rest of the file format the same ;) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fair clock use in CFS
* William Lee Irwin III <[EMAIL PROTECTED]> wrote: >> [...] I'm suspicious of EEVDF's timekeeping now as well. On Mon, May 14, 2007 at 02:04:05PM +0200, Ingo Molnar wrote: > well, EEVDF is a paper-only academic scheduler, one out of thousands > that never touched real hardware. For nearly every mathematically > possible scheduling algorithm i suspect there's at least one paper out > there already describing it ;-) But this time the EEVDF paper got it > right and you got it wrong. But really, if you want to make an impact on > how CFS looks like then please try it and send test feedback and/or > patches - not words. =B-) Perhaps the paper was inspired by preexisting code. Perhaps the code dated back to the 70's. The weight consistency testcase is largely done on account of Davide Libenzi's already having written such a load generator apart from incorporating the already-written code to postprocess the results. I have no particular need to rely on the cfs patches for whatever scheduler patches I'd care to write. I suppose I could write some if I feel particularly inspired. Code review is not my forte anyway. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] libata: add human-readable error value decoding (v2)
This adds human-readable decoding of the ATA status and error registers (similar
to what drivers/ide does) as well as the SATA Serror register to libata error
handling output. This prevents the need to pore through standards documents
to figure out the meaning of the bits in these registers when looking at error
reports. Some bits that drivers/ide decoded are not decoded here, since the bits
are either command-dependent or obsolete, and properly parsing them would add
too much complexity.
This version reduces the length of the SError parsed output strings relative to
the
previous version of this patch.
Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
--- linux-2.6.21.1/drivers/ata/libata-eh.c 2007-04-27 15:49:26.0
-0600
+++ linux-2.6.21.1edit/drivers/ata/libata-eh.c 2007-05-14 17:38:35.0
-0600
@@ -1523,6 +1523,27 @@ static void ata_eh_report(struct ata_por
ata_port_printk(ap, KERN_ERR, "(%s)\n", desc);
}
+ if (ehc->i.serror)
+ ata_port_printk(ap, KERN_ERR,
+ "SError: {%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s}\n",
+ ehc->i.serror & SERR_DATA_RECOVERED ? "RecovData " : "",
+ ehc->i.serror & SERR_COMM_RECOVERED ? "RecovComm " : "",
+ ehc->i.serror & SERR_DATA ? "UnrecovData " : "",
+ ehc->i.serror & SERR_PERSISTENT ? "Persist " : "",
+ ehc->i.serror & SERR_PROTOCOL ? "Proto " : "",
+ ehc->i.serror & SERR_INTERNAL ? "HostInt " : "",
+ ehc->i.serror & SERR_PHYRDY_CHG ? "PHYRdyChg " : "",
+ ehc->i.serror & SERR_PHY_INT_ERR ? "PHYInt " : "",
+ ehc->i.serror & SERR_COMM_WAKE ? "CommWake " : "",
+ ehc->i.serror & SERR_10B_8B_ERR ? "10B8B " : "",
+ ehc->i.serror & SERR_DISPARITY ? "Dispar " : "",
+ ehc->i.serror & SERR_CRC ? "BadCRC " : "",
+ ehc->i.serror & SERR_HANDSHAKE ? "Handshk " : "",
+ ehc->i.serror & SERR_LINK_SEQ_ERR ? "LinkSeq " : "",
+ ehc->i.serror & SERR_TRANS_ST_ERROR ? "TrStaTrns " : "",
+ ehc->i.serror & SERR_UNRECOG_FIS ? "UnrecFIS " : "",
+ ehc->i.serror & SERR_DEV_XCHG ? "DevExch " : "" );
+
for (tag = 0; tag < ATA_MAX_QUEUE; tag++) {
static const char *dma_str[] = {
[DMA_BIDIRECTIONAL] = "bidi",
@@ -1552,6 +1573,29 @@ static void ata_eh_report(struct ata_por
res->hob_feature, res->hob_nsect,
res->hob_lbal, res->hob_lbam, res->hob_lbah,
res->device, qc->err_mask,
ata_err_string(qc->err_mask));
+
+ if (res->command & (ATA_BUSY | ATA_DRDY | ATA_DF | ATA_DRQ |
+ ATA_ERR) ) {
+ if (res->command & ATA_BUSY)
+ ata_dev_printk(qc->dev, KERN_ERR,
+ "status: {Busy}\n" );
+ else
+ ata_dev_printk(qc->dev, KERN_ERR,
+ "status: {%s%s%s%s}\n",
+ res->command & ATA_DRDY ? "DRDY " : "",
+ res->command & ATA_DF ? "DF " : "",
+ res->command & ATA_DRQ ? "DRQ " : "",
+ res->command & ATA_ERR ? "ERR " : "" );
+ }
+
+ if (cmd->command != ATA_CMD_PACKET &&
+ (res->feature & (ATA_ICRC | ATA_UNC | ATA_IDNF |
ATA_ABORTED)))
+ ata_dev_printk(qc->dev, KERN_ERR,
+ "error: {%s%s%s%s}\n",
+ res->feature & ATA_ICRC ? "ICRC " : "",
+ res->feature & ATA_UNC ? "UNC " : "",
+ res->feature & ATA_IDNF ? "IDNF " : "",
+ res->feature & ATA_ABORTED ? "ABRT " : "" );
}
}
--- linux-2.6.21.1/include/linux/ata.h 2007-04-27 15:49:26.0 -0600
+++ linux-2.6.21.1edit/include/linux/ata.h 2007-05-09 19:25:54.0
-0600
@@ -223,6 +223,15 @@ enum {
SERR_PROTOCOL = (1 << 10), /* protocol violation */
SERR_INTERNAL = (1 << 11), /* host internal error */
SERR_PHYRDY_CHG = (1 << 16), /* PHY RDY changed */
+ SERR_PHY_INT_ERR= (1 << 17), /* PHY internal error */
+ SERR_COMM_WAKE = (1 << 18), /* Comm wake */
+ SERR_10B_8B_ERR = (1 << 19), /* 10b to 8b decode error */
+ SERR_DISPARITY = (1 << 20), /* Disparity */
+ SERR_CRC= (1 << 21), /* CRC error */
+ SERR_HANDSHAKE = (1 << 22), /* Handshake error */
+ SERR_LINK_SEQ_ERR = (1 << 23), /* Link sequence error */
+ SERR_TRANS_ST_ERROR = (1 << 24), /* Transport state transition
error
[PATCH] parport: mailing list is subscribers-only
From: Randy Dunlap <[EMAIL PROTECTED]> linux-parport is subscribers-only: Your mail to 'Linux-parport' with the subject Re: [QUESTION] parallel console configuration Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- MAINTAINERS |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-2.6.22-rc1.orig/MAINTAINERS +++ linux-2.6.22-rc1/MAINTAINERS @@ -2691,13 +2691,13 @@ L: [EMAIL PROTECTED] S: Maintained PARALLEL PORT SUPPORT -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) S: Orphan PARIDE DRIVERS FOR PARALLEL PORT IDE DEVICES P: Tim Waugh M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) W: http://www.torque.net/linux-pp.html S: Maintained - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] usb/core/hub.c loops forever on resume from ram due to bluetooth
Greg KH wrote:
Ok, I'll take a patch to keep the loop from going forever, but the main
issue here is that there is probably a hardware failure somewhere.
Okay, found it. The root cause here was a missing CONFIG_USB_SUSPEND=y,
which means the hci_usb device never got marked as USB_STATE_SUSPENDED,
which then caused the loop to go on forever.
The system works fine now with CONFIG_USB_SUSPEND=y in the .config.
Here's the patch to prevent future lockups for this or other causes.
I no longer need it, but it does still seem a good idea.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- old/drivers/usb/core/hub.c 2007-04-26 12:02:47.0 -0400
+++ linux/drivers/usb/core/hub.c2007-05-01 18:48:46.0 -0400
@@ -403,9 +403,10 @@
struct usb_hub *hub =
container_of(work, struct usb_hub, tt.kevent);
unsigned long flags;
+ int limit = 100;
spin_lock_irqsave (>tt.lock, flags);
- while (!list_empty (>tt.clear_list)) {
+ while (--limit && !list_empty (>tt.clear_list)) {
struct list_head*temp;
struct usb_tt_clear *clear;
struct usb_device *hdev = hub->hdev;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: slab hang on boot
On Mon, 14 May 2007, David Miller wrote:
> From: Meelis Roos <[EMAIL PROTECTED]>
> Date: Mon, 14 May 2007 21:36:42 +0300 (EEST)
>
> > Sorry, I could not test the parport patch yet - I did git upgrade as of
> > yesterday and the kernel hangs on boot. boot -p reveals the following
> > slab panic:
>
> Please enable SLUB to work around this for now, SLAB wants
> LARGE_ALLOCS enabled when it really shouldn't require that
> for a 512K or 1MB SLAB when PAGE_SIZE==8192 :-(
Ok.
> > kmem_cache_create: Early error in slab tsb_512KB
> > kernel BUG at mm/slab.c:2165!
>
> Christoph, this is why I had to have LARGE_ALLOCS enabled on sparc64
> all this time, for that MAX_OBJ_ORDER logic in mm/slab.c in order
> to get 512K and 1MB slab caches usable.
Hmmm... The #ifdef crap there has worried me for a long time. Lets try to
clear that mess up too.
> This inconsistency is painful for platforms. If I enable LARGE_ALLOCS
> on sparc64 then SLAB works but it's a total waste for SLUB.
>
> Right now if I enable LARGE_ALLOCS, SLUB will break again due to
> that KMALLOC_SHIFT_HIGH bug we fixed the other week, Christophe
> can you at least push that fix to Linus if you haven't already?
No I thought you had it under control so I held it in my tree.
Andrew please push this patch upstream.
SLUB: CONFIG_LARGE_ALLOCS must consider MAX_ORDER limit
Take MAX_ORDER into consideration when determing KMALLOC_SHIFT_HIGH.
Otherwise we may run into a situation where we attempt to create
general slabs larger than MAX_ORDER.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
include/linux/slub_def.h |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: slub/include/linux/slub_def.h
===
--- slub.orig/include/linux/slub_def.h 2007-05-10 15:19:39.0 -0700
+++ slub/include/linux/slub_def.h 2007-05-10 16:06:15.0 -0700
@@ -59,7 +59,8 @@ struct kmem_cache {
#define KMALLOC_SHIFT_LOW 3
#ifdef CONFIG_LARGE_ALLOCS
-#define KMALLOC_SHIFT_HIGH 25
+#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT) =< 25 ? \
+ MAX_ORDER + PAGE_SHIFT - 1 : 25)
#else
#if !defined(CONFIG_MMU) || NR_CPUS > 512 || MAX_NUMNODES > 256
#define KMALLOC_SHIFT_HIGH 20
@@ -86,6 +87,9 @@ static inline int kmalloc_index(int size
*/
WARN_ON_ONCE(size == 0);
+ if (size >= (1UL << KMALLOC_SHIFT_HIGH))
+ return -1;
+
if (size > 64 && size <= 96)
return 1;
if (size > 128 && size <= 192)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5][TAKE2] fallocate() implementation on i86, x86_64 and powerpc
On Mon, 14 May 2007 20:15:24 +0530 "Amit K. Arora" <[EMAIL PROTECTED]> wrote: > > This patch implements sys_fallocate() and adds support on i386, x86_64 > and powerpc platforms. This patch no longer applies to Linus' tree - for a start there is no file arch/x86_64/kernel/functionlist any more. Can you rebase it, please? -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp1j2vzeD4fZ.pgp Description: PGP signature
Re: [PATCH 1/2] s2io: add PCI error recovery support
I failed to cc some of the people on the cc list ... so am resending.
--linas
On Mon, May 14, 2007 at 06:37:30PM -0500, Linas Vepstas wrote:
>
> This patch adds PCI error recovery support to the
> s2io 10-Gigabit ethernet device driver. Third revision,
> blocks interrupts and the watchdog.
>
> Tested, seems to work well.
>
> Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
> Acked-by: Ramkrishna Vepa <[EMAIL PROTECTED]>
> Cc: Raghavendra Koushik <[EMAIL PROTECTED]>
> Cc: Wen Xiong <[EMAIL PROTECTED]>
>
>
>
> Jeff, please apply for 2.6.22
>
> --linas
>
>
> drivers/net/s2io.c | 116
> ++---
> drivers/net/s2io.h |5 ++
> 2 files changed, 116 insertions(+), 5 deletions(-)
>
> Index: linux-2.6.22-rc1/drivers/net/s2io.c
> ===
> --- linux-2.6.22-rc1.orig/drivers/net/s2io.c 2007-05-14 17:05:03.0
> -0500
> +++ linux-2.6.22-rc1/drivers/net/s2io.c 2007-05-14 17:23:45.0
> -0500
> @@ -480,11 +480,18 @@ static struct pci_device_id s2io_tbl[] _
>
> MODULE_DEVICE_TABLE(pci, s2io_tbl);
>
> +static struct pci_error_handlers s2io_err_handler = {
> + .error_detected = s2io_io_error_detected,
> + .slot_reset = s2io_io_slot_reset,
> + .resume = s2io_io_resume,
> +};
> +
> static struct pci_driver s2io_driver = {
>.name = "S2IO",
>.id_table = s2io_tbl,
>.probe = s2io_init_nic,
>.remove = __devexit_p(s2io_rem_nic),
> + .err_handler = _err_handler,
> };
>
> /* A simplifier macro used both by init and free shared_mem Fns(). */
> @@ -2700,6 +2707,9 @@ static void s2io_netpoll(struct net_devi
> u64 val64 = 0xULL;
> int i;
>
> + if (pci_channel_offline(nic->pdev))
> + return;
> +
> disable_irq(dev->irq);
>
> atomic_inc(>isr_cnt);
> @@ -3225,6 +3235,8 @@ static void alarm_intr_handler(struct s2
> int i;
> if (atomic_read(>card_state) == CARD_DOWN)
> return;
> + if (pci_channel_offline(nic->pdev))
> + return;
> nic->mac_control.stats_info->sw_stat.ring_full_cnt = 0;
> /* Handling the XPAK counters update */
> if(nic->mac_control.stats_info->xpak_stat.xpak_timer_count < 72000) {
> @@ -4324,6 +4336,10 @@ static irqreturn_t s2io_isr(int irq, voi
> struct mac_info *mac_control;
> struct config_param *config;
>
> + /* Pretend we handled any irq's from a disconnected card */
> + if (pci_channel_offline(sp->pdev))
> + return IRQ_NONE;
> +
> atomic_inc(>isr_cnt);
> mac_control = >mac_control;
> config = >config;
> @@ -6579,7 +6595,7 @@ static void s2io_rem_isr(struct s2io_nic
> } while(cnt < 5);
> }
>
> -static void s2io_card_down(struct s2io_nic * sp)
> +static void do_s2io_card_down(struct s2io_nic * sp, int do_io)
> {
> int cnt = 0;
> struct XENA_dev_config __iomem *bar0 = sp->bar0;
> @@ -6594,7 +6610,8 @@ static void s2io_card_down(struct s2io_n
> atomic_set(>card_state, CARD_DOWN);
>
> /* disable Tx and Rx traffic on the NIC */
> - stop_nic(sp);
> + if (do_io)
> + stop_nic(sp);
>
> s2io_rem_isr(sp);
>
> @@ -6602,7 +6619,7 @@ static void s2io_card_down(struct s2io_n
> tasklet_kill(>task);
>
> /* Check if the device is Quiescent and then Reset the NIC */
> - do {
> + while(do_io) {
> /* As per the HW requirement we need to replenish the
>* receive buffer to avoid the ring bump. Since there is
>* no intention of processing the Rx frame at this pointwe are
> @@ -6627,8 +6644,9 @@ static void s2io_card_down(struct s2io_n
> (unsigned long long) val64);
> break;
> }
> - } while (1);
> - s2io_reset(sp);
> + }
> + if (do_io)
> + s2io_reset(sp);
>
> spin_lock_irqsave(>tx_lock, flags);
> /* Free all Tx buffers */
> @@ -6643,6 +6661,11 @@ static void s2io_card_down(struct s2io_n
> clear_bit(0, &(sp->link_state));
> }
>
> +static void s2io_card_down(struct s2io_nic * sp)
> +{
> + do_s2io_card_down(sp, 1);
> +}
> +
> static int s2io_card_up(struct s2io_nic * sp)
> {
> int i, ret = 0;
> @@ -8020,3 +8043,86 @@ static void lro_append_pkt(struct s2io_n
> sp->mac_control.stats_info->sw_stat.clubbed_frms_cnt++;
> return;
> }
> +
> +/**
> + * s2io_io_error_detected - called when PCI error is detected
> + * @pdev: Pointer to PCI device
> + * @state: The current pci conneection state
> + *
> + * This function is called after a PCI bus error affecting
> + * this device has been detected.
> + */
> +static pci_ers_result_t s2io_io_error_detected(struct pci_dev *pdev,
> + pci_channel_state_t state)
> +{
> + struct net_device *netdev = pci_get_drvdata(pdev);
>
Re: [PATCH 2/2] s2io: add PCI error recovery support
s2io cleanup suggestions, per discussion on mailing lists.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/s2io.c |2 --
drivers/net/s2io.h |1 -
2 files changed, 3 deletions(-)
Index: linux-2.6.22-rc1/drivers/net/s2io.c
===
--- linux-2.6.22-rc1.orig/drivers/net/s2io.c2007-05-14 17:23:45.0
-0500
+++ linux-2.6.22-rc1/drivers/net/s2io.c 2007-05-14 17:24:03.0 -0500
@@ -3980,7 +3980,6 @@ static int s2io_close(struct net_device
/* Reset card, kill tasklet and free Tx and Rx buffers. */
s2io_card_down(sp);
- sp->device_close_flag = TRUE; /* Device is shut down. */
return 0;
}
@@ -8063,7 +8062,6 @@ static pci_ers_result_t s2io_io_error_de
if (netif_running(netdev)) {
/* Bring down the card, while avoiding PCI I/O */
do_s2io_card_down(sp, 0);
- sp->device_close_flag = TRUE; /* Device is shut down. */
}
pci_disable_device(pdev);
Index: linux-2.6.22-rc1/drivers/net/s2io.h
===
--- linux-2.6.22-rc1.orig/drivers/net/s2io.h2007-05-14 17:23:45.0
-0500
+++ linux-2.6.22-rc1/drivers/net/s2io.h 2007-05-14 17:24:03.0 -0500
@@ -794,7 +794,6 @@ struct s2io_nic {
struct net_device_stats stats;
int high_dma_flag;
- int device_close_flag;
int device_enabled_once;
char name[60];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [QUESTION] parallel console configuration
On Fri, 16 Feb 2007 20:23:00 +0100 Michal Piotrowski wrote: > Hi, > > I'm trying to setup a parallel console. > > CONFIG_PARPORT=y > CONFIG_PARPORT_PC=y > CONFIG_PRINTER=y > CONFIG_LP_CONSOLE=y > > kernel params > console=lp0 console=tty0 > > System stuck on > lp0: using parport0 (interrupt-driven). > > http://www.stardust.webpages.pl/files/tbf/euridica/2.6.20/1.jpg > > What am I doing wrong? Hi Michal, LP_CONSOLE didn't work for me for awhile, but it does work for me in 2.6.22-rc1. Have you tested it lately? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] s2io: add PCI error recovery support
This patch adds PCI error recovery support to the
s2io 10-Gigabit ethernet device driver. Third revision,
blocks interrupts and the watchdog.
Tested, seems to work well.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Acked-by: Ramkrishna Vepa <[EMAIL PROTECTED]>
Cc: Raghavendra Koushik <[EMAIL PROTECTED]>
Cc: Wen Xiong <[EMAIL PROTECTED]>
Jeff, please apply for 2.6.22
--linas
drivers/net/s2io.c | 116 ++---
drivers/net/s2io.h |5 ++
2 files changed, 116 insertions(+), 5 deletions(-)
Index: linux-2.6.22-rc1/drivers/net/s2io.c
===
--- linux-2.6.22-rc1.orig/drivers/net/s2io.c2007-05-14 17:05:03.0
-0500
+++ linux-2.6.22-rc1/drivers/net/s2io.c 2007-05-14 17:23:45.0 -0500
@@ -480,11 +480,18 @@ static struct pci_device_id s2io_tbl[] _
MODULE_DEVICE_TABLE(pci, s2io_tbl);
+static struct pci_error_handlers s2io_err_handler = {
+ .error_detected = s2io_io_error_detected,
+ .slot_reset = s2io_io_slot_reset,
+ .resume = s2io_io_resume,
+};
+
static struct pci_driver s2io_driver = {
.name = "S2IO",
.id_table = s2io_tbl,
.probe = s2io_init_nic,
.remove = __devexit_p(s2io_rem_nic),
+ .err_handler = _err_handler,
};
/* A simplifier macro used both by init and free shared_mem Fns(). */
@@ -2700,6 +2707,9 @@ static void s2io_netpoll(struct net_devi
u64 val64 = 0xULL;
int i;
+ if (pci_channel_offline(nic->pdev))
+ return;
+
disable_irq(dev->irq);
atomic_inc(>isr_cnt);
@@ -3225,6 +3235,8 @@ static void alarm_intr_handler(struct s2
int i;
if (atomic_read(>card_state) == CARD_DOWN)
return;
+ if (pci_channel_offline(nic->pdev))
+ return;
nic->mac_control.stats_info->sw_stat.ring_full_cnt = 0;
/* Handling the XPAK counters update */
if(nic->mac_control.stats_info->xpak_stat.xpak_timer_count < 72000) {
@@ -4324,6 +4336,10 @@ static irqreturn_t s2io_isr(int irq, voi
struct mac_info *mac_control;
struct config_param *config;
+ /* Pretend we handled any irq's from a disconnected card */
+ if (pci_channel_offline(sp->pdev))
+ return IRQ_NONE;
+
atomic_inc(>isr_cnt);
mac_control = >mac_control;
config = >config;
@@ -6579,7 +6595,7 @@ static void s2io_rem_isr(struct s2io_nic
} while(cnt < 5);
}
-static void s2io_card_down(struct s2io_nic * sp)
+static void do_s2io_card_down(struct s2io_nic * sp, int do_io)
{
int cnt = 0;
struct XENA_dev_config __iomem *bar0 = sp->bar0;
@@ -6594,7 +6610,8 @@ static void s2io_card_down(struct s2io_n
atomic_set(>card_state, CARD_DOWN);
/* disable Tx and Rx traffic on the NIC */
- stop_nic(sp);
+ if (do_io)
+ stop_nic(sp);
s2io_rem_isr(sp);
@@ -6602,7 +6619,7 @@ static void s2io_card_down(struct s2io_n
tasklet_kill(>task);
/* Check if the device is Quiescent and then Reset the NIC */
- do {
+ while(do_io) {
/* As per the HW requirement we need to replenish the
* receive buffer to avoid the ring bump. Since there is
* no intention of processing the Rx frame at this pointwe are
@@ -6627,8 +6644,9 @@ static void s2io_card_down(struct s2io_n
(unsigned long long) val64);
break;
}
- } while (1);
- s2io_reset(sp);
+ }
+ if (do_io)
+ s2io_reset(sp);
spin_lock_irqsave(>tx_lock, flags);
/* Free all Tx buffers */
@@ -6643,6 +6661,11 @@ static void s2io_card_down(struct s2io_n
clear_bit(0, &(sp->link_state));
}
+static void s2io_card_down(struct s2io_nic * sp)
+{
+ do_s2io_card_down(sp, 1);
+}
+
static int s2io_card_up(struct s2io_nic * sp)
{
int i, ret = 0;
@@ -8020,3 +8043,86 @@ static void lro_append_pkt(struct s2io_n
sp->mac_control.stats_info->sw_stat.clubbed_frms_cnt++;
return;
}
+
+/**
+ * s2io_io_error_detected - called when PCI error is detected
+ * @pdev: Pointer to PCI device
+ * @state: The current pci conneection state
+ *
+ * This function is called after a PCI bus error affecting
+ * this device has been detected.
+ */
+static pci_ers_result_t s2io_io_error_detected(struct pci_dev *pdev,
+ pci_channel_state_t state)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct s2io_nic *sp = netdev->priv;
+
+ netif_device_detach(netdev);
+
+ if (netif_running(netdev)) {
+ /* Bring down the card, while avoiding PCI I/O */
+ do_s2io_card_down(sp, 0);
+ sp->device_close_flag = TRUE; /* Device is shut down. */
+ }
+
Re: [ck] Re: [PATCH] mm: swap prefetch more improvements
On 5/14/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Tue, 15 May 2007 08:43:35 +1000 Con Kolivas <[EMAIL PROTECTED]> wrote: > On Tuesday 15 May 2007 08:00, Andrew Morton wrote: > > On Mon, 14 May 2007 10:50:54 +1000 > > > > Con Kolivas <[EMAIL PROTECTED]> wrote: > > > akpm, please queue on top of "mm: swap prefetch improvements" > > > > > > --- > > > Failed radix_tree_insert wasn't being handled leaving stale kmem. > > > > > > The list should be iterated over in the reverse order when prefetching. > > > > > > Make the yield within kprefetchd stronger through the use of > > > cond_resched. > > > > hm. > > > > > - might_sleep(); > > > - if (!prefetch_suitable()) > > > + /* Yield to anything else running */ > > > + if (cond_resched() || !prefetch_suitable()) > > > goto out_unlocked; > > > > So if cond_resched() happened to schedule away, we terminate this > > swap-tricking attempt. It's not possible to determine the reasons for this > > from the code or from the changelog (==bad). > > > > How come? > > Hmm I thought the line above that says "yield to anything else running" was > explicit enough. The idea is kprefetchd shouldn't run if any other real > activity is happening just about anywhere, and a positive cond_resched would > indicate likely activity so we just put kprefetchd back to sleep. I mean, if swap-prefetch is actually useful, then it'll still be useful if the machine happens to be doing some computational work. It's not obvious to me that there is linkage between "doing CPU work" and "prefetching is presently undesirable". That may be true, but I believe Con is attempting to err on the side of caution in saying that swap prefetch should have practically no negative impact if _anything_ is running. (The whole premise, for now, anyways, is that swap prefetch should provide... "something for (almost) nothing", if I'm interpreting this right.) That said, there are probably some cases (seti) where swap prefetch during the run of that batch program would help. On the flip side, there are also some cases where batch processes (various other seti-like "boinc" apps) which use a good deal of memory, meaning that performing the prefetch at that time is futile, unhelpful, or otherwise unwanted. Would it be better to be less yield-y in this circumstance? -- Michael Chang Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: swap prefetch more improvements
On Tuesday 15 May 2007 09:01, Andrew Morton wrote: > On Tue, 15 May 2007 08:43:35 +1000 > > Con Kolivas <[EMAIL PROTECTED]> wrote: > > On Tuesday 15 May 2007 08:00, Andrew Morton wrote: > > > On Mon, 14 May 2007 10:50:54 +1000 > > > > > > Con Kolivas <[EMAIL PROTECTED]> wrote: > > > > akpm, please queue on top of "mm: swap prefetch improvements" > > > > > > > > --- > > > > Failed radix_tree_insert wasn't being handled leaving stale kmem. > > > > > > > > The list should be iterated over in the reverse order when > > > > prefetching. > > > > > > > > Make the yield within kprefetchd stronger through the use of > > > > cond_resched. > > > > > > hm. > > > > > > > - might_sleep(); > > > > - if (!prefetch_suitable()) > > > > + /* Yield to anything else running */ > > > > + if (cond_resched() || !prefetch_suitable()) > > > > goto out_unlocked; > > > > > > So if cond_resched() happened to schedule away, we terminate this > > > swap-tricking attempt. It's not possible to determine the reasons for > > > this from the code or from the changelog (==bad). > > > > > > How come? > > > > Hmm I thought the line above that says "yield to anything else running" > > was explicit enough. The idea is kprefetchd shouldn't run if any other > > real activity is happening just about anywhere, and a positive > > cond_resched would indicate likely activity so we just put kprefetchd > > back to sleep. > > But kprefetchd runs as SCHED_BATCH. Doesn't that mean that some low-prio > background thing (seti?) will disable swap-prefetch? > > I mean, if swap-prefetch is actually useful, then it'll still be useful if > the machine happens to be doing some computational work. It's not obvious > to me that there is linkage between "doing CPU work" and "prefetching is > presently undesirable". set_tsk_need_resched which is the trigger for a cond_resched occurring won't be set just by a cpu bound task constantly running in the background as far as I can see. It's only if some wakeup has triggered a set_tsk_need_resched. ie prefetching still happens here with setiathome or equivalent running in my testing. It might be overkill but from what I can see here it is no impediment to prefetching occurring. I'll think about it some more and do more testing but it seems ok to me. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb-storage: Add support for unusual device by Sierra Wireless
Kevin Lloyd wrote: Not a bad idea. When using the US_FL_IGNORE_DEVICE flag, that causes the usb-storage driver to no load the device and allow another driver properly load it? The reason I ask is because I previously had a separate driver for the device, however there were priority issues regarding which loaded first usb-storage or the separate driver. Yes, that's what it's designed for. If usb-storage does come first, the US_FL_IGNORE_DEVICE flag causes it to return -ENODEV from probe, which causes the driver core to look for other candidate drivers to claim the device. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Let smp_call_function_single return -EBUSY.
On Monday 14 May 2007 21:11, Andrew Morton wrote: > On Mon, 14 May 2007 11:23:17 +0200 > > Heiko Carstens <[EMAIL PROTECTED]> wrote: > > From: Heiko Carstens <[EMAIL PROTECTED]> > > > > All architectures that have an implementation of smp_call_function_single > > let it return -EBUSY if it is asked to execute func on the current cpu. > > Therefore the UP version must always return -EBUSY. > > smp_call_function_single() is a mess. > > - it's unclear to me why smp_call_function_single(cpu, ...) doesn't just > call the darn function if cpu==smp_processor_id(). I always wondered that too. Also I think we really need a cpu notifier that does smp_call_single automatically; i find myself reimplementing that multiple times. > - it's unclear to me why smp_call_function_single(cpu, ...) doesn't just > call the darn function if CONFIG_SMP=n. Yes. > > - it's unclear to me why smp_call_function_single(cpu, ...) isn't called > smp_call_function_on(cpu, ...) > > - the x86_64 version doesn't return -EBUSY: it returns zero. Despite its > claim "Retrurns 0 on success, else a negative status code.". Will fix. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fair clock use in CFS
On Mon, May 14, 2007 at 12:31:20PM +0200, Ingo Molnar wrote: >>> please clarify - exactly what is a mistake? Thanks, * William Lee Irwin III <[EMAIL PROTECTED]> wrote: >> The variability in ->fair_clock advancement rate was the mistake, at >> least according to my way of thinking. [...] On Mon, May 14, 2007 at 01:50:49PM +0200, Ingo Molnar wrote: > you are quite wrong. Lets consider the following example: > we have 10 tasks running (all at nice 0). The current task spends 20 > msecs on the CPU and a new task is picked. How much CPU time did that > waiting task get entitled to during its 20 msecs wait? If fair_clock was > constant as you suggest then we'd give it 20 msecs - but its true 'fair > expectation' of CPU time was only 20/10 == 2 msecs! The amount of time to which the task was entitled remains the same, delta_exec*curr->load_weight/get_rq_load(rq). Where the timekeeping goes wrong is when trying to divide out changes in the virtual time. Where I'm actually wrong is that using wall clock time doesn't resolve it because there still isn't an integral to divide out. The running average is a closer approximation. Possibly better would be to update an explicit integral at the time of changes to ->raw_weighted_load and to store a starting value of the integral for use as a subtrahend to form a difference to use in lieu of computations now used for delta_fair. It's a step function so it's not computationally intensive. What's now used is somewhat more ad hoc. On Mon, May 14, 2007 at 01:50:49PM +0200, Ingo Molnar wrote: > So a 'constant' fair_clock would turn the whole equilibrium upside down > (it would inflate p->wait_runtime values and the global sum would not be > roughly constant anymore but would run up very fast), especially during > fluctuating loads. > the fair_clock is the fundamental expression of "fair CPU timeline", and > task's expected runtime is always measured by that, not by the real > clock. The only time when we measure the true time is when a _single_ > task runs on the CPU - but in that case the task truly spent a small > amount of time on the CPU, exclusively. See the exec_time calculations > in kernel/sched_fair.c. My thought here revolves around the divisor of p->wait_runtime. The interest in the global sum is interesting. It suggests an \ell^1 (sum of absolute values) aggregate lag metric but it appears you're looking at them as signed in this sum. The field is at least signed. More typical is attempting to minimize \ell^\infty (maximum absolute value) aggregate lag metrics. I'm suspicious of this global sum of signed lags. I would expect it to deviate from this constraint significantly due to arriving and departing tasks. The vector of lags is merely restricted to lie near a plane i.e. |\sum_t lag(t)| < K as opposed to within some distance from the origin in some \ell^p norm i.e. \sum_t |lag(t)|^p < K with the usual limiting convention for p = \infty. The latter is the requirement for constant lag bounds. Of course, this sum treatment will largely work out anyway given that tasks with larger positive lags are favored and larger negative lags penalized. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trivial string form cleanups
On Tuesday 15 May 2007 00:59, Jeremy Fitzhardinge wrote: > Saves sizeof(char *) per string too, but you need to be careful none of > these are being passed to sizeof or typeof. Did you check for that in > your conversions? Yes, i did, but i just went through them again to make it sure and i really couldn't see any sizeof, typeof or other suspicious usages of those strings in this set of cleanups. Thanks, Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] usb-storage: Add support for unusual device by Sierra Wireless
Not a bad idea. When using the US_FL_IGNORE_DEVICE flag, that causes the usb-storage driver to no load the device and allow another driver properly load it? The reason I ask is because I previously had a separate driver for the device, however there were priority issues regarding which loaded first usb-storage or the separate driver. Thanks, - Kevin -Original Message- From: Daniel Drake [mailto:[EMAIL PROTECTED] Sent: Monday, May 14, 2007 3:59 PM To: Kevin Lloyd Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org Subject: Re: [PATCH] usb-storage: Add support for unusual device by Sierra Wireless Kevin Lloyd wrote: > From: Kevin Lloyd <[EMAIL PROTECTED]> > > This patch is targeted for the 2.6.21.1 kernel source. It adds support > for Sierra Wireless devices with auto-install support to the > unusual_devices list of the usb-mass storage driver. This requires > changes to Kconfig, Makefile, usb.c, unusual_devs.h, and the addition > of sierra_ms.h & sierra_ms.c. We have to do a similar thing for some zd1211rw USB-wireless devices, which appear as a virtual CDROM drive on plugin. To convert them to a proper wireless device, the cdrom has to be ejected, then the device disconnects and reconnects with different ID's (and the wireless endpoints). Originally I wrote a usb-storage subdriver to handle the auto-eject, but this was rejected. It was decided to make usb-storage simply ignore the devices, and have the zd1211rw driver do the eject operation. The same may also apply in your case. See the US_FL_IGNORE_DEVICE flag, and the DEVICE_INSTALLER handling in drivers/net/wireless/zd1211rw/zd_usb.c Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: swap prefetch more improvements
On Tue, 15 May 2007 08:43:35 +1000 Con Kolivas <[EMAIL PROTECTED]> wrote: > On Tuesday 15 May 2007 08:00, Andrew Morton wrote: > > On Mon, 14 May 2007 10:50:54 +1000 > > > > Con Kolivas <[EMAIL PROTECTED]> wrote: > > > akpm, please queue on top of "mm: swap prefetch improvements" > > > > > > --- > > > Failed radix_tree_insert wasn't being handled leaving stale kmem. > > > > > > The list should be iterated over in the reverse order when prefetching. > > > > > > Make the yield within kprefetchd stronger through the use of > > > cond_resched. > > > > hm. > > > > > - might_sleep(); > > > - if (!prefetch_suitable()) > > > + /* Yield to anything else running */ > > > + if (cond_resched() || !prefetch_suitable()) > > > goto out_unlocked; > > > > So if cond_resched() happened to schedule away, we terminate this > > swap-tricking attempt. It's not possible to determine the reasons for this > > from the code or from the changelog (==bad). > > > > How come? > > Hmm I thought the line above that says "yield to anything else running" was > explicit enough. The idea is kprefetchd shouldn't run if any other real > activity is happening just about anywhere, and a positive cond_resched would > indicate likely activity so we just put kprefetchd back to sleep. But kprefetchd runs as SCHED_BATCH. Doesn't that mean that some low-prio background thing (seti?) will disable swap-prefetch? I mean, if swap-prefetch is actually useful, then it'll still be useful if the machine happens to be doing some computational work. It's not obvious to me that there is linkage between "doing CPU work" and "prefetching is presently undesirable". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb-storage: Add support for unusual device by Sierra Wireless
Kevin Lloyd wrote: From: Kevin Lloyd <[EMAIL PROTECTED]> This patch is targeted for the 2.6.21.1 kernel source. It adds support for Sierra Wireless devices with auto-install support to the unusual_devices list of the usb-mass storage driver. This requires changes to Kconfig, Makefile, usb.c, unusual_devs.h, and the addition of sierra_ms.h & sierra_ms.c. We have to do a similar thing for some zd1211rw USB-wireless devices, which appear as a virtual CDROM drive on plugin. To convert them to a proper wireless device, the cdrom has to be ejected, then the device disconnects and reconnects with different ID's (and the wireless endpoints). Originally I wrote a usb-storage subdriver to handle the auto-eject, but this was rejected. It was decided to make usb-storage simply ignore the devices, and have the zd1211rw driver do the eject operation. The same may also apply in your case. See the US_FL_IGNORE_DEVICE flag, and the DEVICE_INSTALLER handling in drivers/net/wireless/zd1211rw/zd_usb.c Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trivial string form cleanups
Frank Seidel wrote: > Change of string form like Jeff Garzik suggested > it at http://janitor.kernelnewbies.org/TODO > to get better assembly output as this format only > declares a single variable. > Saves sizeof(char *) per string too, but you need to be careful none of these are being passed to sizeof or typeof. Did you check for that in your conversions? J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [VOYAGER] fix build broken by shift to smp_ops
James Bottomley wrote: > Let me do it. > > These are the two patches, tested and working on Voyager. > > The order of application is > > i386-common-smp.patch > i386-fix-voyager-build.patch > Yep, looks fine to me. The only difference from the ones I just posted appears to be a little bit of whitespace. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to access correctly serial port inside module?
Am 14.05.2007 22:00 schrieb Jan Engelhardt: > On May 14 2007 19:40, Lars K.W. Gohlke wrote: >>> >>> after searching the mailing list and searching the web, I still don't >>> know how to access correctly the serial port (in user space known as >>> /dev/ttyS01) > > http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad That's not nice, sending a newbie on a wild goose chase like that. He doesn't want to write to a file from kernel after all. Reading FAQs is never bad, of course, but reading that particular one won't help him at all with this questions. Lars: Read that at your leisure if you have time. It is quite educating, though completely irrelevant to your questions. >>> would somebody be so kind to give me an example: >>> >>> with this behaviour: >>> >>> 1. read from port >>> 2. output via printk() >>> 3. write to port > > inb/inw/inl, printk, outb/outw/outl. This is even less nice. You're sending him down the road of directly programming UART registers, knowing full well (I hope) that this a Bad Thing. What will you tell him when he comes back covered in bruises? Lars: Ignore this advice. You don't want to use in[bwl]/out[bwl] to directly access serial port hardware for which the kernel has a working driver already. That way lies pain, as I know from experience. Read up on the line discipline interface instead, as described in my previous reply. HTH T. -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: [PATCH] pcmcia: ppc64 needs 64-bit ioaddr_t
On Tue, May 15, 2007 at 08:47:04AM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2007-05-14 at 15:08 -0700, Andrew Morton wrote: > > > > Well that's some pretty sad code you've found there. The kernel > > surely has > > some appropriate type to use here without us having to invent a new > > one. > > But I suspect if we were to rationalise things in there it will get > > messy. > > There is more sad stuff involved with drivers assuming IO ports fit in > int. A proper fix for 2.6.23 will be the rework of PIO allocation I'm > doing. A temporary fix for 2.6.22 would be for Olof to use > reserve_phb_iospace() to make sure his PIO gets in the low 31 bits. We > need to add a spinlock to it though. Yes, we should do fine with just a 32-bit type and my CF driver being fixed. I've been travelling and catching up with other things today, I should have something to post tomorrow. Andrew, you can drop this patch for now. Sorry for the churn. -Olof - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [VOYAGER] fix build broken by shift to smp_ops
James Bottomley wrote: > Seriously, though, although I tolerate voyager breakage through the > merge window, I actively try to clean it up and have a working voyager > for the next release. There's no real excuse for not fixing build > breakage. How it's done, I don't really care. The only blocker for the > two patch smp consolidation + voyager fix was Andi ... if he's relaxing > that, then we can go that route. > > Until this is fixed, there are going to be -rc testers firing off build > failure reports, which I think we'd all like to Sure. I'm just surprised this is causing so much fuss, since I thought we'd resolved it all last month. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcmcia: ppc64 needs 64-bit ioaddr_t
On Sun, May 13, 2007 at 11:46:08PM +0200, Christoph Hellwig wrote: > On Sat, May 12, 2007 at 09:31:05AM -0500, Olof Johansson wrote: > > ppc64 really needs ioaddr_t to be 64-bit, since I/O addresses really > > are MMIO addresses, and remapped to a high range. > > > > While the type is exported to userspace, there hasn't been any platforms > > with PCMCIA on 64-bit powerpc until now, so changing it won't regress > > any existing users. > > In fact the only use of the type should be in the obsolete ioctl-based user > interface. So instead of changing the size of the type you should > > a) make sure you're not using cardmgr > b) fix up those places that still use ioaddr_t where they shouldn't > and switch the to kio_addr_t (why not just unsigned long like all > other busses?) I just noticed that feature-removal-schedule.txt says November 2005 for the removal of the pcmcia ioctl's, but they're still there. I'm missing the history here, any reason they weren't removed yet? -Olof - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Trivial string form cleanups
Change of string form like Jeff Garzik suggested
it at http://janitor.kernelnewbies.org/TODO
to get better assembly output as this format only
declares a single variable.
Signed-off-by: Frank Seidel <[EMAIL PROTECTED]>
---
arch/ppc/platforms/4xx/xilinx_ml300.c |2 +-
arch/ppc/platforms/4xx/xilinx_ml403.c |2 +-
drivers/atm/fore200e_mkfirm.c |6 +++---
drivers/net/cris/eth_v10.c|2 +-
drivers/net/fs_enet/mii-fec.c |2 +-
drivers/net/isa-skeleton.c|4 ++--
drivers/net/wan/c101.c|4 ++--
drivers/net/wan/hdlc.c|2 +-
drivers/net/wan/n2.c |4 ++--
drivers/net/wan/pc300too.c|4 ++--
drivers/net/wan/pci200syn.c |4 ++--
drivers/net/wan/sdla.c|2 +-
drivers/net/wan/wanxl.c |2 +-
drivers/sbus/char/bpp.c |2 +-
14 files changed, 21 insertions(+), 21 deletions(-)
Index: b/drivers/net/wan/n2.c
===
--- a/drivers/net/wan/n2.c
+++ b/drivers/net/wan/n2.c
@@ -33,8 +33,8 @@
#include "hd64570.h"
-static const char* version = "SDL RISCom/N2 driver version: 1.15";
-static const char* devname = "RISCom/N2";
+static const char version[] = "SDL RISCom/N2 driver version: 1.15";
+static const char devname[] = "RISCom/N2";
#undef DEBUG_PKT
#define DEBUG_RINGS
Index: b/arch/ppc/platforms/4xx/xilinx_ml300.c
===
--- a/arch/ppc/platforms/4xx/xilinx_ml300.c
+++ b/arch/ppc/platforms/4xx/xilinx_ml300.c
@@ -53,7 +53,7 @@
* ppc4xx_pic_initarch/ppc/syslib/xilinx_pic.c
*/
-const char* virtex_machine_name = "ML300 Reference Design";
+const char virtex_machine_name[] = "ML300 Reference Design";
#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
static volatile unsigned *powerdown_base =
Index: b/arch/ppc/platforms/4xx/xilinx_ml403.c
===
--- a/arch/ppc/platforms/4xx/xilinx_ml403.c
+++ b/arch/ppc/platforms/4xx/xilinx_ml403.c
@@ -55,7 +55,7 @@
* ppc4xx_pic_initarch/ppc/syslib/xilinx_pic.c
*/
-const char* virtex_machine_name = "ML403 Reference Design";
+const char virtex_machine_name[] = "ML403 Reference Design";
#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
static volatile unsigned *powerdown_base =
Index: b/drivers/net/wan/sdla.c
===
--- a/drivers/net/wan/sdla.c
+++ b/drivers/net/wan/sdla.c
@@ -57,7 +57,7 @@
#include
#include
-static const char* version = "SDLA driver v0.30, 12 Sep 1996, [EMAIL
PROTECTED]";
+static const char version[] = "SDLA driver v0.30, 12 Sep 1996, [EMAIL
PROTECTED]";
static unsigned int valid_port[] = { 0x250, 0x270, 0x280, 0x300, 0x350, 0x360,
0x380, 0x390};
Index: b/drivers/net/wan/wanxl.c
===
--- a/drivers/net/wan/wanxl.c
+++ b/drivers/net/wan/wanxl.c
@@ -32,7 +32,7 @@
#include "wanxl.h"
-static const char* version = "wanXL serial card driver version: 0.48";
+static const char version[] = "wanXL serial card driver version: 0.48";
#define PLX_CTL_RESET 0x4000 /* adapter reset */
Index: b/drivers/net/wan/c101.c
===
--- a/drivers/net/wan/c101.c
+++ b/drivers/net/wan/c101.c
@@ -30,8 +30,8 @@
#include "hd64570.h"
-static const char* version = "Moxa C101 driver version: 1.15";
-static const char* devname = "C101";
+static const char version[] = "Moxa C101 driver version: 1.15";
+static const char devname[] = "C101";
#undef DEBUG_PKT
#define DEBUG_RINGS
Index: b/drivers/net/wan/hdlc.c
===
--- a/drivers/net/wan/hdlc.c
+++ b/drivers/net/wan/hdlc.c
@@ -38,7 +38,7 @@
#include
-static const char* version = "HDLC support module revision 1.21";
+static const char version[] = "HDLC support module revision 1.21";
#undef DEBUG_LINK
Index: b/drivers/net/wan/pci200syn.c
===
--- a/drivers/net/wan/pci200syn.c
+++ b/drivers/net/wan/pci200syn.c
@@ -33,8 +33,8 @@
#include "hd64572.h"
-static const char* version = "Goramo PCI200SYN driver version: 1.16";
-static const char* devname = "PCI200SYN";
+static const char version[] = "Goramo PCI200SYN driver version: 1.16";
+static const char devname[] = "PCI200SYN";
#undef DEBUG_PKT
#define DEBUG_RINGS
Index: b/drivers/net/wan/pc300too.c
===
--- a/drivers/net/wan/pc300too.c
+++ b/drivers/net/wan/pc300too.c
@@ -37,8 +37,8 @@
#include "hd64572.h"
-static const char* version = "Cyclades PC300 driver version: 1.17";
-static const char* devname = "PC300";
+static const char version[] =
Re: [PATCH] pcmcia: ppc64 needs 64-bit ioaddr_t
On Mon, 2007-05-14 at 15:08 -0700, Andrew Morton wrote: > > Well that's some pretty sad code you've found there. The kernel > surely has > some appropriate type to use here without us having to invent a new > one. > But I suspect if we were to rationalise things in there it will get > messy. There is more sad stuff involved with drivers assuming IO ports fit in int. A proper fix for 2.6.23 will be the rework of PIO allocation I'm doing. A temporary fix for 2.6.22 would be for Olof to use reserve_phb_iospace() to make sure his PIO gets in the low 31 bits. We need to add a spinlock to it though. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: swap prefetch more improvements
On Tuesday 15 May 2007 08:00, Andrew Morton wrote: > On Mon, 14 May 2007 10:50:54 +1000 > > Con Kolivas <[EMAIL PROTECTED]> wrote: > > akpm, please queue on top of "mm: swap prefetch improvements" > > > > --- > > Failed radix_tree_insert wasn't being handled leaving stale kmem. > > > > The list should be iterated over in the reverse order when prefetching. > > > > Make the yield within kprefetchd stronger through the use of > > cond_resched. > > hm. > > > - might_sleep(); > > - if (!prefetch_suitable()) > > + /* Yield to anything else running */ > > + if (cond_resched() || !prefetch_suitable()) > > goto out_unlocked; > > So if cond_resched() happened to schedule away, we terminate this > swap-tricking attempt. It's not possible to determine the reasons for this > from the code or from the changelog (==bad). > > How come? Hmm I thought the line above that says "yield to anything else running" was explicit enough. The idea is kprefetchd shouldn't run if any other real activity is happening just about anywhere, and a positive cond_resched would indicate likely activity so we just put kprefetchd back to sleep. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [VOYAGER] fix build broken by shift to smp_ops
On Mon, 2007-05-14 at 15:29 -0700, Andrew Morton wrote:
> On Mon, 14 May 2007 23:58:09 +0200
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> >
> > > OK, but only if you don't want to put "i386: move common parts of smp
> > > into their own file" in front of it, and remove the duplicated code. I
> > > could send you a third copy if you like.
> >
> > Using Jeremy's patch is better than James'
> >
>
> This is getting comical.
>
> According to my records, the patch
> voyager-fix-build-broken-by-shift-to-smp_ops.patch _is_ Jeremy's patch.
> James forwarded it.
It's Jeremy's patch modified to work in the absence of the smp ops
consolidation patch.
> I take it from your statement that we should merge some Jeremy-patch other
> than this Jeremy-patch?
>
> If "yes", than could Jeremy please resend the other patch(es) (I believe there
> are multiple patches involved) and then can James please test them?
Let me do it.
These are the two patches, tested and working on Voyager.
The order of application is
i386-common-smp.patch
i386-fix-voyager-build.patch
James
--- Begin Message ---
Several parts of kernel/smp.c and smpboot.c are generally useful for
other subarchitectures and paravirt_ops implementations, so make them
available for reuse.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
Cc: Eric W. Biederman <[EMAIL PROTECTED]>
---
arch/i386/kernel/Makefile|1
arch/i386/kernel/smp.c | 65 +++---
arch/i386/kernel/smpboot.c | 22 ---
arch/i386/kernel/smpcommon.c | 79 ++
include/asm-i386/processor.h |4 ++
5 files changed, 90 insertions(+), 81 deletions(-)
===
Index: BUILD-voyager/arch/i386/kernel/Makefile
===
--- BUILD-voyager.orig/arch/i386/kernel/Makefile2007-05-08
17:00:34.0 -0500
+++ BUILD-voyager/arch/i386/kernel/Makefile 2007-05-08 17:00:45.0
-0500
@@ -19,6 +19,7 @@ obj-$(CONFIG_X86_CPUID) += cpuid.o
obj-$(CONFIG_MICROCODE)+= microcode.o
obj-$(CONFIG_APM) += apm.o
obj-$(CONFIG_X86_SMP) += smp.o smpboot.o tsc_sync.o
+obj-$(CONFIG_SMP) += smpcommon.o
obj-$(CONFIG_X86_TRAMPOLINE) += trampoline.o
obj-$(CONFIG_X86_MPPARSE) += mpparse.o
obj-$(CONFIG_X86_LOCAL_APIC) += apic.o nmi.o
Index: BUILD-voyager/arch/i386/kernel/smp.c
===
--- BUILD-voyager.orig/arch/i386/kernel/smp.c 2007-05-08 17:00:34.0
-0500
+++ BUILD-voyager/arch/i386/kernel/smp.c2007-05-08 17:00:45.0
-0500
@@ -467,7 +467,7 @@ void flush_tlb_all(void)
* it goes straight through and wastes no time serializing
* anything. Worst case is that we lose a reschedule ...
*/
-void native_smp_send_reschedule(int cpu)
+static void native_smp_send_reschedule(int cpu)
{
WARN_ON(cpu_is_offline(cpu));
send_IPI_mask(cpumask_of_cpu(cpu), RESCHEDULE_VECTOR);
@@ -546,9 +546,10 @@ static void __smp_call_function(void (*f
* You must not call this function with disabled interrupts or from a
* hardware interrupt handler or from a bottom half handler.
*/
-int native_smp_call_function_mask(cpumask_t mask,
- void (*func)(void *), void *info,
- int wait)
+static int
+native_smp_call_function_mask(cpumask_t mask,
+ void (*func)(void *), void *info,
+ int wait)
{
struct call_data_struct data;
cpumask_t allbutself;
@@ -599,60 +600,6 @@ int native_smp_call_function_mask(cpumas
return 0;
}
-/**
- * smp_call_function(): Run a function on all other CPUs.
- * @func: The function to run. This must be fast and non-blocking.
- * @info: An arbitrary pointer to pass to the function.
- * @nonatomic: Unused.
- * @wait: If true, wait (atomically) until function has completed on other
CPUs.
- *
- * Returns 0 on success, else a negative status code.
- *
- * If @wait is true, then returns once @func has returned; otherwise
- * it returns just before the target cpu calls @func.
- *
- * You must not call this function with disabled interrupts or from a
- * hardware interrupt handler or from a bottom half handler.
- */
-int smp_call_function(void (*func) (void *info), void *info, int nonatomic,
- int wait)
-{
- return smp_call_function_mask(cpu_online_map, func, info, wait);
-}
-EXPORT_SYMBOL(smp_call_function);
-
-/**
- * smp_call_function_single - Run a function on another CPU
- * @cpu: The target CPU. Cannot be the calling CPU.
- * @func: The function to run. This must be fast and non-blocking.
- * @info: An arbitrary pointer to pass to the function.
- * @nonatomic: Unused.
- * @wait: If true, wait until
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v1
On Monday 14 May 2007 23:05:14 Thomas Gleixner wrote: > On Mon, 2007-05-14 at 22:15 +0100, Alistair John Strachan wrote: > > On Monday 14 May 2007 11:26:08 Thomas Gleixner wrote: > > > I'm pleased to announce an updated version of the x86_64 > > > highres/dyntick support patches against 2.6.22-rc1: > > > > [snip] > > > > > - Various fixups from Chris Wright > > > - TSC calibration fix (pointed out by Alistair John Strachan) > > > > > > Comments, bugreports, patches are welcome as ususal > > > > Neither of the bugs I reported appear to be fixed. > > > > I took a clean git tree from the 2.6.22-rc1 tag and patched with this > > version; my CPU MHz and dmesg counter still appear to be broken (v3 was > > used). > > Sigh. /me feels stupid. > > Can you please apply the following patch on top and check, whether it > fixes the problem ? Please provide the debug output, when it fails. Doesn't fix the problem, and here is the debug: TSC calibrated against pm_timer 8927439 9106459 179020 640810145 tsckhz: 1350695500 640810145 210779356 Marking TSC unstable due to TSCs unsynchronized time.c: Detected 210779.356 MHz processor. (Perhaps if this debug effort has to continue, we could remove some of these gentlemen from CC?) -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: O_DIRECT for FAT
Hubertus Grobbel <[EMAIL PROTECTED]> writes: > I found out, that the option O_DIRECT for opening a file on a fat- > filesystem successfully completes. But reading and writing to that > file leads to EINVAL errors (using kernel 2.6.18). EINVAL may be meaning the memory alignment which you passed to syscall is wrong. > Do you see a way to solve my problem by any workaround? Is O_DIRECT > support for fat-fs feasible in future? The fatfs is supporting O_DIRECT for read, for write it's partially supporting (can't extend file size). -- OGAWA Hirofumi <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] - LXR on kernel.org ? was: Re: What tools to use?
On Mon, 2007-05-14 at 21:44 +0200, Jan-Benedict Glaw wrote: > On Fri, 2007-05-11 10:06:17 +0200, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: > > Jesper Juhl wrote: > > > On 10/05/07, Shahbaz Khan <[EMAIL PROTECTED]> wrote: > > why not adding a link to every kernel an kernel.org kernel, > > pointing to recent lxr`ed kernel source - or - even better - > > make lxr`ed kernel source part of kernel.org (so we > > have "B V VIC Changelog LXR" ) ? > > I'd support the idea, but somebody needs to offer a machine or two and > enough bandwidth. (Though I hope that it's used rarely enough so that > only one machine is needed.) This is what I was interested in getting setup. I'm away on vacation this week (I'm currently out on the road to Yosemite and about to have no email whatsoever), but I just asked an intern of mine to start looking into it and will followup when I get back next week. Please keep me copied on any mail. Jon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [VOYAGER] fix build broken by shift to smp_ops
Andrew Morton wrote:
> This is getting comical.
>
> According to my records, the patch
> voyager-fix-build-broken-by-shift-to-smp_ops.patch _is_ Jeremy's patch.
> James forwarded it.
>
> I take it from your statement that we should merge some Jeremy-patch other
> than this Jeremy-patch?
>
> If "yes", than could Jeremy please resend the other patch(es) (I believe there
> are multiple patches involved) and then can James please test them?
>
> If "no" then I think I'll just go shopping.
>
Maybe we should just refer to all patches by their SHA1 hashes.
I'm attaching the two I have, which build for me, and I think James has
tested as working.
(21583c0234c7cc1cd6c4f312ce7a2456086e2323 and
e8862935d0e773f12d73a9502f4bc7de06a6cedd, BTW.)
J
Subject: i386: move common parts of smp into their own file
Several parts of kernel/smp.c and smpboot.c are generally useful for
other subarchitectures and paravirt_ops implementations, so make them
available for reuse.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Acked-by: Chris Wright <[EMAIL PROTECTED]>
Cc: James Bottomley <[EMAIL PROTECTED]>
Cc: Eric W. Biederman <[EMAIL PROTECTED]>
---
arch/i386/kernel/Makefile|1
arch/i386/kernel/smp.c | 65 +++---
arch/i386/kernel/smpboot.c | 22 ---
arch/i386/kernel/smpcommon.c | 79 ++
include/asm-i386/processor.h |4 ++
5 files changed, 90 insertions(+), 81 deletions(-)
===
--- a/arch/i386/kernel/Makefile
+++ b/arch/i386/kernel/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_MICROCODE) += microcode.o
obj-$(CONFIG_MICROCODE) += microcode.o
obj-$(CONFIG_APM) += apm.o
obj-$(CONFIG_X86_SMP) += smp.o smpboot.o tsc_sync.o
+obj-$(CONFIG_SMP) += smpcommon.o
obj-$(CONFIG_X86_TRAMPOLINE) += trampoline.o
obj-$(CONFIG_X86_MPPARSE) += mpparse.o
obj-$(CONFIG_X86_LOCAL_APIC) += apic.o nmi.o
===
--- a/arch/i386/kernel/smp.c
+++ b/arch/i386/kernel/smp.c
@@ -468,7 +468,7 @@ void flush_tlb_all(void)
* it goes straight through and wastes no time serializing
* anything. Worst case is that we lose a reschedule ...
*/
-void native_smp_send_reschedule(int cpu)
+static void native_smp_send_reschedule(int cpu)
{
WARN_ON(cpu_is_offline(cpu));
send_IPI_mask(cpumask_of_cpu(cpu), RESCHEDULE_VECTOR);
@@ -547,9 +547,10 @@ static void __smp_call_function(void (*f
* You must not call this function with disabled interrupts or from a
* hardware interrupt handler or from a bottom half handler.
*/
-int native_smp_call_function_mask(cpumask_t mask,
- void (*func)(void *), void *info,
- int wait)
+static int
+native_smp_call_function_mask(cpumask_t mask,
+ void (*func)(void *), void *info,
+ int wait)
{
struct call_data_struct data;
cpumask_t allbutself;
@@ -600,60 +601,6 @@ int native_smp_call_function_mask(cpumas
return 0;
}
-/**
- * smp_call_function(): Run a function on all other CPUs.
- * @func: The function to run. This must be fast and non-blocking.
- * @info: An arbitrary pointer to pass to the function.
- * @nonatomic: Unused.
- * @wait: If true, wait (atomically) until function has completed on other CPUs.
- *
- * Returns 0 on success, else a negative status code.
- *
- * If @wait is true, then returns once @func has returned; otherwise
- * it returns just before the target cpu calls @func.
- *
- * You must not call this function with disabled interrupts or from a
- * hardware interrupt handler or from a bottom half handler.
- */
-int smp_call_function(void (*func) (void *info), void *info, int nonatomic,
- int wait)
-{
- return smp_call_function_mask(cpu_online_map, func, info, wait);
-}
-EXPORT_SYMBOL(smp_call_function);
-
-/**
- * smp_call_function_single - Run a function on another CPU
- * @cpu: The target CPU. Cannot be the calling CPU.
- * @func: The function to run. This must be fast and non-blocking.
- * @info: An arbitrary pointer to pass to the function.
- * @nonatomic: Unused.
- * @wait: If true, wait until function has completed on other CPUs.
- *
- * Returns 0 on success, else a negative status code.
- *
- * If @wait is true, then returns once @func has returned; otherwise
- * it returns just before the target cpu calls @func.
- */
-int smp_call_function_single(int cpu, void (*func) (void *info), void *info,
- int nonatomic, int wait)
-{
- /* prevent preemption and reschedule on another processor */
- int ret;
- int me = get_cpu();
- if (cpu == me) {
- WARN_ON(1);
- put_cpu();
- return -EBUSY;
- }
-
- ret = smp_call_function_mask(cpumask_of_cpu(cpu), func, info, wait);
-
- put_cpu();
- return ret;
-}
-EXPORT_SYMBOL(smp_call_function_single);
-
static void stop_this_cpu (void * dummy)
{
local_irq_disable();
@@ -671,7 +618,7 @@ static void stop_this_cpu (void * dummy)
* this function calls the 'stop' function on all
Re: [RFC][PATCH 5/14] Introduce union stack
On Mon, 2007-05-14 at 15:10 +0530, Bharata B Rao wrote:
> From: Jan Blunck <[EMAIL PROTECTED]>
> Subject: Introduce union stack.
>
> Adds union stack infrastructure to the dentry structure and provides
> locking routines to walk the union stack.
...
> --- /dev/null
> +++ b/include/linux/dcache_union.h
> @@ -0,0 +1,248 @@
> +/*
> + * VFS based union mount for Linux
> + *
> + * Copyright © 2004-2007 IBM Corporation
> + * Author(s): Jan Blunck ([EMAIL PROTECTED])
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the Free
> + * Software Foundation; either version 2 of the License, or (at your option)
> + * any later version.
> + *
> + */
> +#ifndef __LINUX_DCACHE_UNION_H
> +#define __LINUX_DCACHE_UNION_H
> +#ifdef __KERNEL__
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#ifdef CONFIG_UNION_MOUNT
> +
> +/*
> + * This is the union info object, that describes general information about
> this
> + * union directory
> + *
> + * u_mutex protects the union stack against modification. You can reach it
> + * through the d_union field in struct dentry. Hold it when you are walking
> + * or modifing the union stack !
> + */
> +struct union_info {
> + atomic_t u_count;
> + struct mutex u_mutex;
> +};
> +
> +/* allocate/de-allocate */
> +extern struct union_info *union_alloc(void);
> +extern struct union_info *union_get(struct union_info *);
> +extern void union_put(struct union_info *);
> +
> +/*
> + * These are the functions for locking a dentry's union. When one
> + * want to acquire a denties union lock, use:
> + *
> + * - union_lock() when you can sleep,
> + * - union_lock_spinlock() when you are holding a spinlock (that
> + * you CAN savely give up and reacquire again)
> + * - union_lock_readlock() when you are holding a readlock (that
> + * you CAN savely give up and reacquire again)
> + *
> + * Otherwise get the union lock early before you enter your
> + * "no sleeping here" code.
> + *
> + * NOTES: union_info structure is reference counted using u_count member.
> + * union_get() and union_put() which get and put references on union_info
> + * should be done under union_info's u_mutex. Since the last union_put()
> frees
> + * the union_info structure itself it can't obviously be done under u_mutex.
> + * union_release() should be used in such cases (Eg. dput(), umount()) where
> + * union_info is disassociated from the dentries, and it becomes safe
> + * to free the union_info.
> + */
> +static inline void __union_lock(struct union_info *uinfo)
> +{
> + BUG_ON(!atomic_read(>u_count));
> + mutex_lock(>u_mutex);
> +}
> +
> +static inline void union_lock(struct dentry *dentry)
> +{
> + if (unlikely(dentry && dentry->d_union)) {
> + struct union_info *ui = dentry->d_union;
> +
> + UM_DEBUG_LOCK("\"%s\" locking %p (count=%d)\n",
> + dentry->d_name.name, ui,
> + atomic_read(>u_count));
> + __union_lock(dentry->d_union);
> + }
> +}
> +
> +static inline void __union_unlock(struct union_info *uinfo)
> +{
> + BUG_ON(!atomic_read(>u_count));
> + mutex_unlock(>u_mutex);
> +}
> +
> +static inline void union_unlock(struct dentry *dentry)
> +{
> + if (unlikely(dentry && dentry->d_union)) {
> + struct union_info *ui = dentry->d_union;
> +
> + UM_DEBUG_LOCK("\"%s\" unlocking %p (count=%d)\n",
> + dentry->d_name.name, ui,
> + atomic_read(>u_count));
> + __union_unlock(dentry->d_union);
> + }
> +}
> +
> +static inline void union_alloc_dentry(struct dentry *dentry)
> +{
> + spin_lock(>d_lock);
> + if (!dentry->d_union) {
> + dentry->d_union = union_alloc();
> + spin_unlock(>d_lock);
> + } else {
> + spin_unlock(>d_lock);
> + union_lock(dentry);
> + }
> +}
> +
> +static inline struct union_info *union_lock_and_get(struct dentry *dentry)
> +{
> + union_lock(dentry);
> + return union_get(dentry->d_union);
> +}
> +
> +/* Shouldn't be called with last reference to union_info */
> +static inline void union_put_and_unlock(struct union_info *uinfo)
> +{
> + union_put(uinfo);
> + __union_unlock(>u_mutex);
^^^
It should be
__union_unlock(uinfo);
Thanks,
Badari
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How to access correctly serial port inside module?
Am 14.05.2007 15:00 schrieb Lars K.W. Gohlke: > after searching the mailing list and searching the web, I still don't > know how to access correctly the serial port (in user space known as > /dev/ttyS01) I can only tell you how I did it in the special case of the ser_gigaset driver which drives an ISDN device attached to a serial port: I implemented it as a line discipline which is associated to the appropriate serial port by a userspace daemon. Reading material: Documentation/tty.txt documentation on the line discipline interface include/linux/tty.h include/linux/tty_ldisc.h definitions for same drivers/isdn/gigaset/ser-gigaset.c my code - a simple example of abusing the line discipline interface for your own ends :-) > would somebody be so kind to give me an example: I hope the following will help you some. If not, feel free to ask again. > with this behaviour: > > 1. read from port That's not how things work in the kernel. There is no system call for reading some data that has arrived on that port or blocking if there is none, like a userspace program would do. Instead, when you register your line discipline you provide a callback function (receive_buf) for the serial driver to call when data has been received. That function can be called at any time and has to deal with the data as it gets it. > 2. output via printk() You can of course put a printk() in your receive_buf function. But ultimately you'll want to do more than that with the data, I'm sure. > 3. write to port That's easy. :-) No, it isn't. The serial driver *does* provide a function (aptly called "write") for sending data to the serial port, but you can't just call it any time you like. You have to synchronize with the driver by waiting for it to call your "write_wakeup" callback before you can call its write function again. HTH T. -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: [VOYAGER] fix build broken by shift to smp_ops
On Mon, 14 May 2007 23:58:09 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote: > > > OK, but only if you don't want to put "i386: move common parts of smp > > into their own file" in front of it, and remove the duplicated code. I > > could send you a third copy if you like. > > Using Jeremy's patch is better than James' > This is getting comical. According to my records, the patch voyager-fix-build-broken-by-shift-to-smp_ops.patch _is_ Jeremy's patch. James forwarded it. I take it from your statement that we should merge some Jeremy-patch other than this Jeremy-patch? If "yes", than could Jeremy please resend the other patch(es) (I believe there are multiple patches involved) and then can James please test them? If "no" then I think I'll just go shopping. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [VOYAGER] fix build broken by shift to smp_ops
On Mon, 2007-05-14 at 15:00 -0700, Jeremy Fitzhardinge wrote: > Andrew Morton wrote: > > Well, let's get the build fix in place first and then we can feed > > the cleanup in later on, in a more leisurely fashion? > > > > If you like. Are all the Voyager users standing outside your office > with pitchforks, demanding satisfaction? That could be arranged ... The Xensource offices are just up the road from Google, you know if I wanted to kill two birds with one stone. Seriously, though, although I tolerate voyager breakage through the merge window, I actively try to clean it up and have a working voyager for the next release. There's no real excuse for not fixing build breakage. How it's done, I don't really care. The only blocker for the two patch smp consolidation + voyager fix was Andi ... if he's relaxing that, then we can go that route. Until this is fixed, there are going to be -rc testers firing off build failure reports, which I think we'd all like to James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb-storage: Add support for unusual device by Sierra Wireless
On Mon, 14 May 2007 14:44:49 -0700, Kevin Lloyd <[EMAIL PROTECTED]> wrote:
> + schedule_timeout_uninterruptible(delay_t*HZ);
> + retval = sierra_ms_change_mode(us, SWIMS_SET_MODE_Modem);
> + if (retval == -ETIMEDOUT || retval == -ETIME) {
> + US_DEBUGP("sierra_ms: Command timed out.\n");
> + retries--;
This is strange. The two values should not typically be mixed this way.
ETIMEOUT happens when we (host) sent the setup packet, device took it,
and then posted NAKs for all data-in that we did, so eventually (after 5s),
we unlinked the URB. This means that the device works, just doesn't
want to perform the command in time. The bus itself functions fine.
ETIME means that something has violated the bus protocol. It's like
-EBUS for MMIO on PCI. Usually it means that the firmware in the device
is completely dead. You can call this a timeout in some sense, but
in reality it's no different from EILSEQ. We just report a different
code for finer shades of debugging. It happens in less than a millisecond.
I think you just need to test for ETIMEDOUT for that message.
> + int result;
> + unsigned char *blankArray;
> + blankArray = kmalloc(0, GFP_KERNEL);
> + result = usb_stor_control_msg(us, us->send_ctrl_pipe,
> + SWIMS_USB_REQUEST_SetMode,
> + SWIMS_USB_REQUEST_TYPE_SetMode,
> + eSocMode,
> + SWIMS_USB_INDEX_SetMode,
> + blankArray,
> + 0,
> + 5*HZ);
The blankArray is completely unnecessary here. If something hits
a NULL despite the zero transfer size, it has to be fixed.
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: O_DIRECT for FAT
> I would like to access on certain files on a flash-disk without cache > usage, whereas the rest of the filesystem shall be accessed normally/cached. > I am aware of the previous discussion. My application is not targetting on a > pure file usage (I can live with the existing features for that), but also > for a side-channel IO to interact with the device. Assuming you basically want to be sure writes hit the media you can use the fsync and fdatasync system calls on modern kernels to ensure your data is on the media and is flushed when you want it not when the kernel gets around to it out of boredom. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
