Re: [-mm PATCH] Memory controller improve user interface
On Thu, 30 Aug 2007 04:07:11 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > 1. Several people recommended it > 2. Herbert mentioned that they've moved to that interface and it >was working fine for them. > I have no strong opinion. But how about Mega bytes ? (too big ?) There will be no rounding up/down problem. -Kame. - 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: [Lguest] [V9fs-developer] [kvm-devel] [RFC] 9p: add KVM/QEMUpci transport
My current view of the IO stack is the following: -- -- -- -- - |NET_PCI_BACK| |BLK_PCI_BACK| |9P_PCI_BACK| |NET_FRONT| |BLK_FRONT| |9P_FRONT| -- -- -- -- - - --- --- |KVM_PCI_BUS| |hypercall_ops| |shared_mem_virtio| - --- --- So the 9P implementation should add the front end logic and the p9_pci_backend that glues the shared_memory, pci_bus and hypercalls together. >That's also in our plans. There was no virtio support in KVM when I >started working in the transport. > >Thanks, >Lucho > >On 8/29/07, Anthony Liguori <[EMAIL PROTECTED]> wrote: >> I think that it would be nicer to implement the p9 transport on top of >> virtio instead of directly on top of PCI. I think your PCI transport >> would make a pretty nice start of a PCI virtio transport though. >> >> Regards, >> >> Anthony Liguori >> >> On Tue, 2007-08-28 at 13:52 -0500, Eric Van Hensbergen wrote: >> > From: Latchesar Ionkov <[EMAIL PROTECTED]> >> > >> > This adds a shared memory transport for a synthetic 9p device for >> > paravirtualized file system support under KVM/QEMU. >> > >> > Signed-off-by: Latchesar Ionkov <[EMAIL PROTECTED]> >> > Signed-off-by: Eric Van Hensbergen <[EMAIL PROTECTED]> >> > --- >> > Documentation/filesystems/9p.txt |2 + >> > net/9p/Kconfig | 10 ++- >> > net/9p/Makefile |4 + >> > net/9p/trans_pci.c | 295 >++ >> > 4 files changed, 310 insertions(+), 1 deletions(-) >> > create mode 100644 net/9p/trans_pci.c >> > >> > diff --git a/Documentation/filesystems/9p.txt >b/Documentation/filesystems/9p.txt >> > index 1a5f50d..e1879bd 100644 >> > --- a/Documentation/filesystems/9p.txt >> > +++ b/Documentation/filesystems/9p.txt >> > @@ -46,6 +46,8 @@ OPTIONS >> > tcp - specifying a normal TCP/IP connection >> > fd - used passed file descriptors for >connection >> > (see rfdno and wfdno) >> > + pci - use a PCI pseudo device for 9p >communication >> > + over shared memory between a guest and >host >> > >> >uname=name user name to attempt mount as on the remote server. >The >> > server may override or ignore this value. Certain >user >> > diff --git a/net/9p/Kconfig b/net/9p/Kconfig >> > index 09566ae..8517560 100644 >> > --- a/net/9p/Kconfig >> > +++ b/net/9p/Kconfig >> > @@ -16,13 +16,21 @@ menuconfig NET_9P >> > config NET_9P_FD >> > depends on NET_9P >> > default y if NET_9P >> > - tristate "9P File Descriptor Transports (Experimental)" >> > + tristate "9p File Descriptor Transports (Experimental)" >> > help >> > This builds support for file descriptor transports for 9p >> > which includes support for TCP/IP, named pipes, or passed >> > file descriptors. TCP/IP is the default transport for 9p, >> > so if you are going to use 9p, you'll likely want this. >> > >> > +config NET_9P_PCI >> > + depends on NET_9P >> > + tristate "9p PCI Shared Memory Transport (Experimental)" >> > + help >> > + This builds support for a PCI psuedo-device currently >available >> > + under KVM/QEMU which allows for 9p transactions over shared >> > + memory between the guest and the host. >> > + >> > config NET_9P_DEBUG >> > bool "Debug information" >> > depends on NET_9P >> > diff --git a/net/9p/Makefile b/net/9p/Makefile >> > index 7b2a67a..26ce89d 100644 >> > --- a/net/9p/Makefile >> > +++ b/net/9p/Makefile >> > @@ -1,5 +1,6 @@ >> > obj-$(CONFIG_NET_9P) := 9pnet.o >> > obj-$(CONFIG_NET_9P_FD) += 9pnet_fd.o >> > +obj-$(CONFIG_NET_9P_PCI) += 9pnet_pci.o >> > >> > 9pnet-objs := \ >> > mod.o \ >> > @@ -14,3 +15,6 @@ obj-$(CONFIG_NET_9P_FD) += 9pnet_fd.o >> > >> > 9pnet_fd-objs := \ >> > trans_fd.o \ >> > + >> > +9pnet_pci-objs := \ >> > + trans_pci.o \ >> > diff --git a/net/9p/trans_pci.c b/net/9p/trans_pci.c >> > new file mode 100644 >> > index 000..36ddc5f >> > --- /dev/null >> > +++ b/net/9p/trans_pci.c >> > @@ -0,0 +1,295 @@ >> > +/* >> > + * net/9p/trans_pci.c >> > + * >> > + * 9P over PCI transport layer. For use with KVM/QEMU. >> > + * >> > + * Copyright (C) 2007 by Latchesar Ionkov <[EMAIL PROTECTED]> >> > + * >> > + * This program is free software; you can redistribute it and/or >modify >> > + * it under the terms of the GNU General Public License version 2 >> > + * as published by the Free Software Foundation. >> > + * >> > + * This program is distributed in the hope that it will be useful, >> > + * but WITHOUT ANY WARRANTY; without even the implied
Re: [RFC] TASK_KILLED
On Wed, 29 Aug 2007, Matthew Wilcox wrote: > > I've long hated the non-killability of tasks accessing a dead > NFS server. Linus had an idea for fixing this way back in 2002: > http://www.ussg.iu.edu/hypermail/linux/kernel/0208.0/0167.html which > I've prototyped in this patch. Hey, I obviously approve. And the patch looks simple. Feel free to re-submit after 2.6.23 is out the door, I don't think anybody will really complain. Any NFS user will know why something like this can be really nice. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Designers and Builders (was: Who wants to maintain KR list for stable releases?)
Adrian Bunk wrote > Tracking feature or implementation suggestions wouldn't make sense. > Consider e.g. that there are several people on linux-kernel who often > write what they think the kernel should do but who never write a single > line of code themselves. There's no value in tracking such stuff. There are designers, and there are builders. Can you tell me who is more important? Thanks! -- Al - 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] Override 80-wire cable detection for Toshiba S1800-814
Alan Cox wrote: > Daniel Exner <[EMAIL PROTECTED]> wrote: >> Attached patch will add above mentioned Laptop Model to whitelist for both >> pata_ali and alim15x3, as it is correctly detected as 40-wire connected >> but this cable is short enough to still do transfers higher than UDMA33. > > Looks good to me - does need a Signed-off-by: line however Wow! I have been running 80wire cable detection override on 40wire cables for quite some time without any problem, but I never thought it to be legal if the 40wire cable length is short enough. How short does it have to be, and can't we have a kernel bootparm to override the cable detection? Thanks! -- Al - 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 0/5] ALSA: cs5535audio fixes
On 8/29/07, Andres Salomon <[EMAIL PROTECTED]> wrote: > Hi, > > Here are a bunch of fixes for the cs5535audio driver. None of these are > OLPC specific; generic chip and power management fixes, and one cleanup > patch. All have been tested on an OLPC (5536), so even though the 5535 > data sheet claims to be the same, it would be nice to hear success/failure > reports from someone with a 5535. The patches look good. I'm traveling till Sep 2nd so can't test on 5535 yet. Thanks very much for your efforts Andres. Thanks, jaya Acked-by: Jaya Kumar <[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/
[PATCH 5/5] ALSA: cs5535audio: drop unused bus master stuff
We really only care about the first two bus masters (playback and capture).
There's no need to have unused BM code lying around, so let's get rid of it.
If for some reason we trigger an IRQ for some BM that we're not using.. well,
that warrants spitting out an error message (imo).
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
sound/pci/cs5535audio/cs5535audio.c | 24 +++-
sound/pci/cs5535audio/cs5535audio.h | 31 +--
2 files changed, 4 insertions(+), 51 deletions(-)
diff --git a/sound/pci/cs5535audio/cs5535audio.c
b/sound/pci/cs5535audio/cs5535audio.c
index b8e75ef..2b35889 100644
--- a/sound/pci/cs5535audio/cs5535audio.c
+++ b/sound/pci/cs5535audio/cs5535audio.c
@@ -206,7 +206,6 @@ static void process_bm1_irq(struct cs5535audio *cs5535au)
static irqreturn_t snd_cs5535audio_interrupt(int irq, void *dev_id)
{
u16 acc_irq_stat;
- u8 bm_stat;
unsigned char count;
struct cs5535audio *cs5535au = dev_id;
@@ -217,7 +216,7 @@ static irqreturn_t snd_cs5535audio_interrupt(int irq, void
*dev_id)
if (!acc_irq_stat)
return IRQ_NONE;
- for (count = 0; count < 10; count++) {
+ for (count = 0; count < 4; count++) {
if (acc_irq_stat & (1 << count)) {
switch (count) {
case IRQ_STS:
@@ -232,26 +231,9 @@ static irqreturn_t snd_cs5535audio_interrupt(int irq, void
*dev_id)
case BM1_IRQ_STS:
process_bm1_irq(cs5535au);
break;
- case BM2_IRQ_STS:
- bm_stat = cs_readb(cs5535au, ACC_BM2_STATUS);
- break;
- case BM3_IRQ_STS:
- bm_stat = cs_readb(cs5535au, ACC_BM3_STATUS);
- break;
- case BM4_IRQ_STS:
- bm_stat = cs_readb(cs5535au, ACC_BM4_STATUS);
- break;
- case BM5_IRQ_STS:
- bm_stat = cs_readb(cs5535au, ACC_BM5_STATUS);
- break;
- case BM6_IRQ_STS:
- bm_stat = cs_readb(cs5535au, ACC_BM6_STATUS);
- break;
- case BM7_IRQ_STS:
- bm_stat = cs_readb(cs5535au, ACC_BM7_STATUS);
- break;
default:
- snd_printk(KERN_ERR "Unexpected irq src\n");
+ snd_printk(KERN_ERR "Unexpected irq src: "
+ "0x%x\n", acc_irq_stat);
break;
}
}
diff --git a/sound/pci/cs5535audio/cs5535audio.h
b/sound/pci/cs5535audio/cs5535audio.h
index 516219a..66bae76 100644
--- a/sound/pci/cs5535audio/cs5535audio.h
+++ b/sound/pci/cs5535audio/cs5535audio.h
@@ -16,48 +16,19 @@
#define ACC_IRQ_STATUS 0x12
#define ACC_BM0_CMD0x20
#define ACC_BM1_CMD0x28
-#define ACC_BM2_CMD0x30
-#define ACC_BM3_CMD0x38
-#define ACC_BM4_CMD0x40
-#define ACC_BM5_CMD0x48
-#define ACC_BM6_CMD0x50
-#define ACC_BM7_CMD0x58
#define ACC_BM0_PRD0x24
#define ACC_BM1_PRD0x2C
-#define ACC_BM2_PRD0x34
-#define ACC_BM3_PRD0x3C
-#define ACC_BM4_PRD0x44
-#define ACC_BM5_PRD0x4C
-#define ACC_BM6_PRD0x54
-#define ACC_BM7_PRD0x5C
#define ACC_BM0_STATUS 0x21
#define ACC_BM1_STATUS 0x29
-#define ACC_BM2_STATUS 0x31
-#define ACC_BM3_STATUS 0x39
-#define ACC_BM4_STATUS 0x41
-#define ACC_BM5_STATUS 0x49
-#define ACC_BM6_STATUS 0x51
-#define ACC_BM7_STATUS 0x59
#define ACC_BM0_PNTR 0x60
#define ACC_BM1_PNTR 0x64
-#define ACC_BM2_PNTR 0x68
-#define ACC_BM3_PNTR 0x6C
-#define ACC_BM4_PNTR 0x70
-#define ACC_BM5_PNTR 0x74
-#define ACC_BM6_PNTR 0x78
-#define ACC_BM7_PNTR 0x7C
+
/* acc_codec bar0 reg bits */
/* ACC_IRQ_STATUS */
#define IRQ_STS0
#define WU_IRQ_STS 1
#define BM0_IRQ_STS2
#define BM1_IRQ_STS3
-#define BM2_IRQ_STS4
-#define BM3_IRQ_STS5
-#define BM4_IRQ_STS6
-#define BM5_IRQ_STS
[PATCH 2/5] ALSA: cs5535audio: fix PRD register save/restore power management race
In the suspend path, we currently save the PRD registers and then disable DMA.
This is racy; the sound hardware might update the PRD register as it finishes
processing some DMA pages between when we've saved the PRD registers and
when DMA actually gets disabled. Furthermore, we actively check whether or
not DMA is enabled before saving PRD registers; there's no reason to do that,
as the PRD registers should not update when we twiddle the ACC_BM[x]_CMD
register(s). Worst case, we save the PRD registers twice; even powering
down the ACC shouldn't mess with the PRD registers (according to the 5536
data sheet, section 5.3.7.4, power-down procedure). This patch reworks
all that to first disable DMA, and then save PRD registers.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
sound/pci/cs5535audio/cs5535audio.h |1 -
sound/pci/cs5535audio/cs5535audio_pcm.c |2 --
sound/pci/cs5535audio/cs5535audio_pm.c | 14 +++---
3 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/sound/pci/cs5535audio/cs5535audio.h
b/sound/pci/cs5535audio/cs5535audio.h
index 4fd1f31..c7a2044 100644
--- a/sound/pci/cs5535audio/cs5535audio.h
+++ b/sound/pci/cs5535audio/cs5535audio.h
@@ -106,7 +106,6 @@ struct cs5535audio_dma {
struct snd_pcm_substream *substream;
unsigned int buf_addr, buf_bytes;
unsigned int period_bytes, periods;
- int suspended;
u32 saved_prd;
};
diff --git a/sound/pci/cs5535audio/cs5535audio_pcm.c
b/sound/pci/cs5535audio/cs5535audio_pcm.c
index e61f972..fe21a1c 100644
--- a/sound/pci/cs5535audio/cs5535audio_pcm.c
+++ b/sound/pci/cs5535audio/cs5535audio_pcm.c
@@ -300,14 +300,12 @@ static int snd_cs5535audio_trigger(struct
snd_pcm_substream *substream, int cmd)
break;
case SNDRV_PCM_TRIGGER_RESUME:
dma->ops->enable_dma(cs5535au);
- dma->suspended = 0;
break;
case SNDRV_PCM_TRIGGER_STOP:
dma->ops->disable_dma(cs5535au);
break;
case SNDRV_PCM_TRIGGER_SUSPEND:
dma->ops->disable_dma(cs5535au);
- dma->suspended = 1;
break;
default:
snd_printk(KERN_ERR "unhandled trigger\n");
diff --git a/sound/pci/cs5535audio/cs5535audio_pm.c
b/sound/pci/cs5535audio/cs5535audio_pm.c
index 3e4d198..9a4e84a 100644
--- a/sound/pci/cs5535audio/cs5535audio_pm.c
+++ b/sound/pci/cs5535audio/cs5535audio_pm.c
@@ -64,13 +64,13 @@ int snd_cs5535audio_suspend(struct pci_dev *pci,
pm_message_t state)
int i;
snd_power_change_state(card, SNDRV_CTL_POWER_D3hot);
+ snd_pcm_suspend_all(cs5535au->pcm);
+ snd_ac97_suspend(cs5535au->ac97);
for (i = 0; i < NUM_CS5535AUDIO_DMAS; i++) {
struct cs5535audio_dma *dma = >dmas[i];
- if (dma && dma->substream && !dma->suspended)
+ if (dma && dma->substream)
dma->saved_prd = dma->ops->read_prd(cs5535au);
}
- snd_pcm_suspend_all(cs5535au->pcm);
- snd_ac97_suspend(cs5535au->ac97);
/* save important regs, then disable aclink in hw */
snd_cs5535audio_stop_hardware(cs5535au);
@@ -112,17 +112,17 @@ int snd_cs5535audio_resume(struct pci_dev *pci)
if (!timeout)
snd_printk(KERN_ERR "Failure getting AC Link ready\n");
- /* we depend on ac97 to perform the codec power up */
- snd_ac97_resume(cs5535au->ac97);
/* set up rate regs, dma. actual initiation is done in trig */
for (i = 0; i < NUM_CS5535AUDIO_DMAS; i++) {
struct cs5535audio_dma *dma = >dmas[i];
- if (dma && dma->substream && dma->suspended) {
+ if (dma && dma->substream) {
dma->substream->ops->prepare(dma->substream);
dma->ops->setup_prd(cs5535au, dma->saved_prd);
}
}
-
+
+ /* we depend on ac97 to perform the codec power up */
+ snd_ac97_resume(cs5535au->ac97);
snd_power_change_state(card, SNDRV_CTL_POWER_D0);
return 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 3/5] ALSA: cs5535audio: update PCI device handling in suspend/resume
Save the PCI state before disabling the device, and add some error checking.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
sound/pci/cs5535audio/cs5535audio_pm.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/sound/pci/cs5535audio/cs5535audio_pm.c
b/sound/pci/cs5535audio/cs5535audio_pm.c
index 9a4e84a..838708f 100644
--- a/sound/pci/cs5535audio/cs5535audio_pm.c
+++ b/sound/pci/cs5535audio/cs5535audio_pm.c
@@ -74,8 +74,11 @@ int snd_cs5535audio_suspend(struct pci_dev *pci,
pm_message_t state)
/* save important regs, then disable aclink in hw */
snd_cs5535audio_stop_hardware(cs5535au);
+ if (pci_save_state(pci)) {
+ printk(KERN_ERR "cs5535audio: pci_save_state failed!\n");
+ return -EIO;
+ }
pci_disable_device(pci);
- pci_save_state(pci);
pci_set_power_state(pci, pci_choose_state(pci, state));
return 0;
}
@@ -89,7 +92,12 @@ int snd_cs5535audio_resume(struct pci_dev *pci)
int i;
pci_set_power_state(pci, PCI_D0);
- pci_restore_state(pci);
+ if (pci_restore_state(pci) < 0) {
+ printk(KERN_ERR "cs5535audio: pci_restore_state failed, "
+ "disabling device\n");
+ snd_card_disconnect(card);
+ return -EIO;
+ }
if (pci_enable_device(pci) < 0) {
printk(KERN_ERR "cs5535audio: pci_enable_device failed, "
"disabling device\n");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] ALSA: cs5535audio: fix ACC_BM[x]_CMD register handling
ACcording to 6.3.2.7 of the cs5535/cs5536 data sheets, the ACC_BM[x]_CMD registers are only 8 bits wide. This driver treats them as 32 bits wide, and also has bits in the wrong place. Simple fix to the definitions. Signed-off-by: Andres Salomon <[EMAIL PROTECTED]> --- sound/pci/cs5535audio/cs5535audio.h | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/sound/pci/cs5535audio/cs5535audio.h b/sound/pci/cs5535audio/cs5535audio.h index c7a2044..516219a 100644 --- a/sound/pci/cs5535audio/cs5535audio.h +++ b/sound/pci/cs5535audio/cs5535audio.h @@ -62,11 +62,11 @@ #define EOP(1<<0) #define BM_EOP_ERR (1<<1) /* ACC_BMX_CTL */ -#define BM_CTL_EN 0x0001 -#define BM_CTL_PAUSE 0x0011 -#define BM_CTL_DIS 0x -#define BM_CTL_BYTE_ORD_LE 0x -#define BM_CTL_BYTE_ORD_BE 0x0100 +#define BM_CTL_EN 0x01 +#define BM_CTL_PAUSE 0x03 +#define BM_CTL_DIS 0x00 +#define BM_CTL_BYTE_ORD_LE 0x00 +#define BM_CTL_BYTE_ORD_BE 0x04 /* cs5535 specific ac97 codec register defines */ #define CMD_MASK 0xFF00 #define CMD_NEW0x0001 - 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: regression of autofs for current git?
On Wed, 2007-08-29 at 20:09 -0700, Hua Zhong wrote: > I am in the process of bisecting now. It takes a while but the bad commit is > between 2.6.22 and 13f9966b3ba5b45f47f2ea0eb0a90afceedfbb1f (June 28). I'll > continue tomorrow. > > My system is FC4. > > autofs-4.1.4-26 > nfs-utils-1.0.7-13.FC4 > > By the way, the particular autofs commit Andrian sent is innocent. It's > something else. > > It will still take me about 10 reboots to bisect. If anyone has a patch for > me to try, I'll give it a shot tomorrow. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=75180df2ed467866ada839fe73cf7cc7d75c0a22 This (and it's related patches) may be the problem. I can probably tell if you post your map or if you strace the automount process managing the a problem mount point and look for mount returning EBUSY when it should succeed. > > > -Original Message- > > From: Ian Kent [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, August 29, 2007 8:00 PM > > To: Hua Zhong > > Cc: 'Linux Kernel Mailing List'; [EMAIL PROTECTED]; Adrian Bunk > > Subject: Re: regression of autofs for current git? > > > > On Thu, 2007-08-30 at 00:47 +0200, Adrian Bunk wrote: > > > On Wed, Aug 29, 2007 at 01:58:58PM -0700, Hua Zhong wrote: > > > > > > > Hi, > > > > > > Hi Hua, > > > > > > > I am wondering if this is a known issue, but I just built the > > current git > > > > and several autofs mounts mysteriously disappeared. Restarting > > autofs could > > > > fix some, but then lose others. 2.6.22 was fine. > > > > > > > > Is there anything I could check other than bisect? (It may take > > some time > > > > for me to get to it) > > > > > > the commit below is the only autofs4 patch that went into the git > > tree > > > since 2.6.22. > > > > > > Does reverting it fix your problems? > > > > Maybe but there is an NFS change that appears to be in the current > > 2.6.23-rc kernel and doesn't seem to be in 2.6.22 that is known to > > break > > some autofs maps and also breaks amd. > > > > I can't seem to locate the commit just now. > > In the meantime what version of user space autofs and nfs-utils are you > > running? > > And can you post your autofs maps please? > > > > Ian > > > > > > - 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/5] ALSA: cs5535audio: correctly set dma->substream
We're never actually setting dma->substream to the current substream; that
means the dma->substream checks that we do in the suspend/resume path
are never satisfied, and the PRD registers are never correctly managed. This
changes it so that we set the substream when constructing the specific
bus master DMA, and unsetting it when we tear down the BM's DMA.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
sound/pci/cs5535audio/cs5535audio_pcm.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/sound/pci/cs5535audio/cs5535audio_pcm.c
b/sound/pci/cs5535audio/cs5535audio_pcm.c
index 5450a9e..e61f972 100644
--- a/sound/pci/cs5535audio/cs5535audio_pcm.c
+++ b/sound/pci/cs5535audio/cs5535audio_pcm.c
@@ -164,6 +164,7 @@ static int cs5535audio_build_dma_packets(struct cs5535audio
*cs5535au,
jmpprd_addr = cpu_to_le32(lastdesc->addr +
(sizeof(struct
cs5535audio_dma_desc)*periods));
+ dma->substream = substream;
dma->period_bytes = period_bytes;
dma->periods = periods;
spin_lock_irq(>reg_lock);
@@ -241,6 +242,7 @@ static void cs5535audio_clear_dma_packets(struct
cs5535audio *cs5535au,
{
snd_dma_free_pages(>desc_buf);
dma->desc_buf.area = NULL;
+ dma->substream = NULL;
}
static int snd_cs5535audio_hw_params(struct snd_pcm_substream *substream,
-
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/5] ALSA: cs5535audio fixes
Hi, Here are a bunch of fixes for the cs5535audio driver. None of these are OLPC specific; generic chip and power management fixes, and one cleanup patch. All have been tested on an OLPC (5536), so even though the 5535 data sheet claims to be the same, it would be nice to hear success/failure reports from someone with a 5535. -- Andres Salomon <[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: Forced unmounting for removable devices
Eduard-Gabriel Munteanu wrote: > *This message was transferred with a trial version of CommuniGate(r) Pro* > This might have been discussed a few years ago, but things have changed. > I'm talking about patches like this one (I'm not the author): > http://developer.osdl.org/dev/fumount/#kernel1 > > The current situation requires a way to forcibly unmount removable > media. Consider the following (real) scenario. Someone has a box with > hald + dbus + ivman to support "supermounting" the CDROM drive. He has > to install a 2 CD application using Wine for example, but the setup > application prevents normal unmounting of the first one. Then he goes on > and pushes the button to eject the CD, lazy-unmounting the media. The > kernel goes mad and all attempts to load the second CD fail (the kernel > hasn't got rid of the first fs). > > If there was anything like a real forced unmounting, things would have > worked well, as on MS Windows itself. > > As far as I can see, there is no other sane way to solve such problems. > So, what's keeping such patches from making their way into the > mainstream kernel? All (but maybe I haven't searched enough) arguments > against such a feature that I've seen by now just say "it's not needed", > "it's not worth it" and so on, and many of them refer to network mounts. > > P.S.: I'm not saying lazy unmounting should be replaced. They both make > sense, depending on the scenario. There are patches in -mm for revokeat()/frevoke(), which can be used to implement exactly that. If a device "vanishes" (CD is removed in the middle of loading, USB pend rive yanked out the middle of I/O, NFS server thats gone MIA), A user-space program (maybe HAL) could iterate over the open files and revoke() them, at which point the system can be cleanly unmounted. - 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: regression of autofs for current git?
I am in the process of bisecting now. It takes a while but the bad commit is between 2.6.22 and 13f9966b3ba5b45f47f2ea0eb0a90afceedfbb1f (June 28). I'll continue tomorrow. My system is FC4. autofs-4.1.4-26 nfs-utils-1.0.7-13.FC4 By the way, the particular autofs commit Andrian sent is innocent. It's something else. It will still take me about 10 reboots to bisect. If anyone has a patch for me to try, I'll give it a shot tomorrow. > -Original Message- > From: Ian Kent [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 29, 2007 8:00 PM > To: Hua Zhong > Cc: 'Linux Kernel Mailing List'; [EMAIL PROTECTED]; Adrian Bunk > Subject: Re: regression of autofs for current git? > > On Thu, 2007-08-30 at 00:47 +0200, Adrian Bunk wrote: > > On Wed, Aug 29, 2007 at 01:58:58PM -0700, Hua Zhong wrote: > > > > > Hi, > > > > Hi Hua, > > > > > I am wondering if this is a known issue, but I just built the > current git > > > and several autofs mounts mysteriously disappeared. Restarting > autofs could > > > fix some, but then lose others. 2.6.22 was fine. > > > > > > Is there anything I could check other than bisect? (It may take > some time > > > for me to get to it) > > > > the commit below is the only autofs4 patch that went into the git > tree > > since 2.6.22. > > > > Does reverting it fix your problems? > > Maybe but there is an NFS change that appears to be in the current > 2.6.23-rc kernel and doesn't seem to be in 2.6.22 that is known to > break > some autofs maps and also breaks amd. > > I can't seem to locate the commit just now. > In the meantime what version of user space autofs and nfs-utils are you > running? > And can you post your autofs maps please? > > Ian > > - 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: CONFIG_HOTPLUG_CPU: kconfig bug?
Hi,
On Wed, 29 Aug 2007, Sam Ravnborg wrote:
> > > > I've noticed an oddity with CONFIG_HOTPLUG_CPU in 2.6.23-rc:
> > > > make oldconfig seems to turn it on even when nothing wants it,
> > > > increasing kernel size by about 10k; but if you then edit the
> > > > line out of .config and make oldconfig again, it correctly
> > > > offers the choice and lets it be turned off after all.
>
> I have tried to track down what is happening here.
> The culprint is:
>
> config SUSPEND_SMP
> bool
> depends on SUSPEND_SMP_POSSIBLE && PM_SLEEP
> select HOTPLUG_CPU
> default y
>
>
> It seems that due to the fact that SUSPEND_SMP is default y
> then kconfig enforce the "select HOTPLUG_CPU".
It's somewhat a side effect of using select and defaults, the order of the
config symbols becomes significant for oldconfig, if you look at the
output you'll find:
Support for suspend on SMP and hot-pluggable CPUs (EXPERIMENTAL) (HOTPLUG_CPU)
[Y/?] y
this sets it to 'y'. In this case one isn't asked about it, because there
is only one choice. The patch below avoids the setting of the value here.
bye, Roman
Avoid setting the value if the symbol doesn't need to be changed or can't
be changed. Later choices may change the dependencies and thus the
possible input range.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
scripts/kconfig/conf.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
Index: linux-2.6/scripts/kconfig/conf.c
===
--- linux-2.6.orig/scripts/kconfig/conf.c
+++ linux-2.6/scripts/kconfig/conf.c
@@ -72,7 +72,7 @@ static void check_stdin(void)
}
}
-static void conf_askvalue(struct symbol *sym, const char *def)
+static int conf_askvalue(struct symbol *sym, const char *def)
{
enum symbol_type type = sym_get_type(sym);
tristate val;
@@ -87,7 +87,7 @@ static void conf_askvalue(struct symbol
printf("%s\n", def);
line[0] = '\n';
line[1] = 0;
- return;
+ return 0;
}
switch (input_mode) {
@@ -97,23 +97,23 @@ static void conf_askvalue(struct symbol
case set_random:
if (sym_has_value(sym)) {
printf("%s\n", def);
- return;
+ return 0;
}
break;
case ask_new:
case ask_silent:
if (sym_has_value(sym)) {
printf("%s\n", def);
- return;
+ return 0;
}
check_stdin();
case ask_all:
fflush(stdout);
fgets(line, 128, stdin);
- return;
+ return 1;
case set_default:
printf("%s\n", def);
- return;
+ return 1;
default:
break;
}
@@ -123,7 +123,7 @@ static void conf_askvalue(struct symbol
case S_HEX:
case S_STRING:
printf("%s\n", def);
- return;
+ return 1;
default:
;
}
@@ -174,6 +174,7 @@ static void conf_askvalue(struct symbol
break;
}
printf("%s", line);
+ return 1;
}
int conf_string(struct menu *menu)
@@ -187,7 +188,8 @@ int conf_string(struct menu *menu)
def = sym_get_string_value(sym);
if (sym_get_string_value(sym))
printf("[%s] ", def);
- conf_askvalue(sym, def);
+ if (!conf_askvalue(sym, def))
+ return 0;
switch (line[0]) {
case '\n':
break;
@@ -240,7 +242,8 @@ static int conf_sym(struct menu *menu)
if (menu_has_help(menu))
printf("/?");
printf("] ");
- conf_askvalue(sym, sym_get_string_value(sym));
+ if (!conf_askvalue(sym, sym_get_string_value(sym)))
+ return 0;
strip(line);
switch (line[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: regression of autofs for current git?
On Thu, 2007-08-30 at 00:47 +0200, Adrian Bunk wrote: > On Wed, Aug 29, 2007 at 01:58:58PM -0700, Hua Zhong wrote: > > > Hi, > > Hi Hua, > > > I am wondering if this is a known issue, but I just built the current git > > and several autofs mounts mysteriously disappeared. Restarting autofs could > > fix some, but then lose others. 2.6.22 was fine. > > > > Is there anything I could check other than bisect? (It may take some time > > for me to get to it) > > the commit below is the only autofs4 patch that went into the git tree > since 2.6.22. > > Does reverting it fix your problems? Maybe but there is an NFS change that appears to be in the current 2.6.23-rc kernel and doesn't seem to be in 2.6.22 that is known to break some autofs maps and also breaks amd. I can't seem to locate the commit just now. In the meantime what version of user space autofs and nfs-utils are you running? And can you post your autofs maps please? Ian - 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.23-rc3-mm1 - vdso and gettimeofday issues with glibc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Morton wrote: > So it's an interaction between the x86_64 vdso patches in Andi's tree and > newer glibc, and we don't know which one is getting it wrong yet? glibc does nothing but call the code in the vdso. We have a function pointer variable which either has the old vsyscall value or the address of the function in the vdso. Everything else is identical. Unless the interface of the vdso function is different (which it shouldn't) I don't think you can blame glibc. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG1i+K2ijCOnn/RHQRArogAKC3zBeyOzqJRF+x2zj3fBg9iGLdyQCgx9Z3 dv3Izh65+kxKedza6RH3MHk= =qEdC -END PGP SIGNATURE- - 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.23 2/2] - cxgb3 engine microcode load
From: Divy Le Ray <[EMAIL PROTECTED]>
Load the engine microcode when an interface
is brought up, instead of of doing it when the module
is loaded.
Loosen up tight binding between the driver and the
engine microcode version.
There is no need for microcode update with T3A boards.
Fix the file naming.
Do a better job at logging the loading activity.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h |3 +
drivers/net/cxgb3/cxgb3_main.c | 126 ++--
drivers/net/cxgb3/t3_hw.c | 46 +--
3 files changed, 123 insertions(+), 52 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index 1637800..2129210 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -679,7 +679,8 @@ const struct adapter_info *t3_get_adapter_info(unsigned int
board_id);
int t3_seeprom_read(struct adapter *adapter, u32 addr, u32 *data);
int t3_seeprom_write(struct adapter *adapter, u32 addr, u32 data);
int t3_seeprom_wp(struct adapter *adapter, int enable);
-int t3_check_tpsram_version(struct adapter *adapter);
+int t3_get_tp_version(struct adapter *adapter, u32 *vers);
+int t3_check_tpsram_version(struct adapter *adapter, int *must_load);
int t3_check_tpsram(struct adapter *adapter, u8 *tp_ram, unsigned int size);
int t3_set_proto_sram(struct adapter *adap, u8 *data);
int t3_read_flash(struct adapter *adapter, unsigned int addr,
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index f3bf128..5ab319c 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -729,6 +729,7 @@ static void bind_qsets(struct adapter *adap)
}
#define FW_FNAME "t3fw-%d.%d.%d.bin"
+#define TPSRAM_NAME "t3%c_protocol_sram-%d.%d.%d.bin"
static int upgrade_fw(struct adapter *adap)
{
@@ -747,6 +748,71 @@ static int upgrade_fw(struct adapter *adap)
}
ret = t3_load_fw(adap, fw->data, fw->size);
release_firmware(fw);
+
+ if (ret == 0)
+ dev_info(dev, "successful upgrade to firmware %d.%d.%d\n",
+FW_VERSION_MAJOR, FW_VERSION_MINOR, FW_VERSION_MICRO);
+ else
+ dev_err(dev, "failed to upgrade to firmware %d.%d.%d\n",
+ FW_VERSION_MAJOR, FW_VERSION_MINOR, FW_VERSION_MICRO);
+
+ return ret;
+}
+
+static inline char t3rev2char(struct adapter *adapter)
+{
+ char rev = 0;
+
+ switch(adapter->params.rev) {
+ case T3_REV_B:
+ case T3_REV_B2:
+ rev = 'b';
+ break;
+ }
+ return rev;
+}
+
+int update_tpsram(struct adapter *adap)
+{
+ const struct firmware *tpsram;
+ char buf[64];
+ struct device *dev = >pdev->dev;
+ int ret;
+ char rev;
+
+ rev = t3rev2char(adap);
+ if (!rev)
+ return 0;
+
+ snprintf(buf, sizeof(buf), TPSRAM_NAME, rev,
+TP_VERSION_MAJOR, TP_VERSION_MINOR, TP_VERSION_MICRO);
+
+ ret = request_firmware(, buf, dev);
+ if (ret < 0) {
+ dev_err(dev, "could not load TP SRAM: unable to load %s\n",
+ buf);
+ return ret;
+ }
+
+ ret = t3_check_tpsram(adap, tpsram->data, tpsram->size);
+ if (ret)
+ goto release_tpsram;
+
+ ret = t3_set_proto_sram(adap, tpsram->data);
+ if (ret == 0)
+ dev_info(dev,
+"successful update of protocol engine "
+"to %d.%d.%d\n",
+TP_VERSION_MAJOR, TP_VERSION_MINOR, TP_VERSION_MICRO);
+ else
+ dev_err(dev, "failed to update of protocol engine %d.%d.%d\n",
+ TP_VERSION_MAJOR, TP_VERSION_MINOR, TP_VERSION_MICRO);
+ if (ret)
+ dev_err(dev, "loading protocol SRAM failed\n");
+
+release_tpsram:
+ release_firmware(tpsram);
+
return ret;
}
@@ -763,6 +829,7 @@ static int upgrade_fw(struct adapter *adap)
static int cxgb_up(struct adapter *adap)
{
int err = 0;
+ int must_load;
if (!(adap->flags & FULL_INIT_DONE)) {
err = t3_check_fw_version(adap);
@@ -771,6 +838,13 @@ static int cxgb_up(struct adapter *adap)
if (err)
goto out;
+ err = t3_check_tpsram_version(adap, _load);
+ if (err == -EINVAL) {
+ err = update_tpsram(adap);
+ if (err && must_load)
+ goto out;
+ }
+
err = init_dummy_netdevs(adap);
if (err)
goto out;
@@ -1110,8 +1184,10 @@ static void get_drvinfo(struct net_device *dev, struct
ethtool_drvinfo *info)
struct port_info *pi = netdev_priv(dev);
struct adapter *adapter = pi->adapter;
u32 fw_vers = 0;
+ u32
[PATCH 2.6.23 1/2] cxgb3 - Fix dev->priv usage
From: Divy Le Ray <[EMAIL PROTECTED]>
cxgb3 used netdev_priv() and dev->priv for different purposes.
In 2.6.23, netdev_priv() == dev->priv, cxgb3 needs a fix.
This patch is a partial backport of Dave Miller's changes in the
net-2.6.24 git branch.
Without this fix, cxgb3 crashes on 2.6.23.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/cxio_hal.c |2 -
drivers/net/cxgb3/adapter.h|2 +
drivers/net/cxgb3/cxgb3_main.c | 126 ++--
drivers/net/cxgb3/cxgb3_offload.c | 16 +++-
drivers/net/cxgb3/cxgb3_offload.h |2 +
drivers/net/cxgb3/sge.c| 23 --
drivers/net/cxgb3/t3cdev.h |3 -
7 files changed, 105 insertions(+), 69 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.c
b/drivers/infiniband/hw/cxgb3/cxio_hal.c
index 1518b41..beb2a38 100644
--- a/drivers/infiniband/hw/cxgb3/cxio_hal.c
+++ b/drivers/infiniband/hw/cxgb3/cxio_hal.c
@@ -916,7 +916,7 @@ int cxio_rdev_open(struct cxio_rdev *rdev_p)
PDBG("%s opening rnic dev %s\n", __FUNCTION__, rdev_p->dev_name);
memset(_p->ctrl_qp, 0, sizeof(rdev_p->ctrl_qp));
if (!rdev_p->t3cdev_p)
- rdev_p->t3cdev_p = T3CDEV(netdev_p);
+ rdev_p->t3cdev_p = dev2t3cdev(netdev_p);
rdev_p->t3cdev_p->ulp = (void *) rdev_p;
err = rdev_p->t3cdev_p->ctl(rdev_p->t3cdev_p, RDMA_GET_PARAMS,
&(rdev_p->rnic_info));
diff --git a/drivers/net/cxgb3/adapter.h b/drivers/net/cxgb3/adapter.h
index ab72563..20e887d 100644
--- a/drivers/net/cxgb3/adapter.h
+++ b/drivers/net/cxgb3/adapter.h
@@ -50,7 +50,9 @@ typedef irqreturn_t(*intr_handler_t) (int, void *);
struct vlan_group;
+struct adapter;
struct port_info {
+ struct adapter *adapter;
struct vlan_group *vlan_grp;
const struct port_type_info *port_type;
u8 port_id;
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index dc5d269..f3bf128 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -358,11 +358,14 @@ static int init_dummy_netdevs(struct adapter *adap)
for (j = 0; j < pi->nqsets - 1; j++) {
if (!adap->dummy_netdev[dummy_idx]) {
- nd = alloc_netdev(0, "", ether_setup);
+ struct port_info *p;
+
+ nd = alloc_netdev(sizeof(*p), "", ether_setup);
if (!nd)
goto free_all;
- nd->priv = adap;
+ p = netdev_priv(nd);
+ p->adapter = adap;
nd->weight = 64;
set_bit(__LINK_STATE_START, >state);
adap->dummy_netdev[dummy_idx] = nd;
@@ -482,7 +485,8 @@ static ssize_t attr_store(struct device *d, struct
device_attribute *attr,
#define CXGB3_SHOW(name, val_expr) \
static ssize_t format_##name(struct net_device *dev, char *buf) \
{ \
- struct adapter *adap = dev->priv; \
+ struct port_info *pi = netdev_priv(dev); \
+ struct adapter *adap = pi->adapter; \
return sprintf(buf, "%u\n", val_expr); \
} \
static ssize_t show_##name(struct device *d, struct device_attribute *attr, \
@@ -493,7 +497,8 @@ static ssize_t show_##name(struct device *d, struct
device_attribute *attr, \
static ssize_t set_nfilters(struct net_device *dev, unsigned int val)
{
- struct adapter *adap = dev->priv;
+ struct port_info *pi = netdev_priv(dev);
+ struct adapter *adap = pi->adapter;
int min_tids = is_offload(adap) ? MC5_MIN_TIDS : 0;
if (adap->flags & FULL_INIT_DONE)
@@ -515,7 +520,8 @@ static ssize_t store_nfilters(struct device *d, struct
device_attribute *attr,
static ssize_t set_nservers(struct net_device *dev, unsigned int val)
{
- struct adapter *adap = dev->priv;
+ struct port_info *pi = netdev_priv(dev);
+ struct adapter *adap = pi->adapter;
if (adap->flags & FULL_INIT_DONE)
return -EBUSY;
@@ -556,9 +562,10 @@ static struct attribute_group cxgb3_attr_group = {.attrs =
cxgb3_attrs };
static ssize_t tm_attr_show(struct device *d, struct device_attribute *attr,
char *buf, int sched)
{
- ssize_t len;
+ struct port_info *pi = netdev_priv(to_net_dev(d));
+ struct adapter *adap = pi->adapter;
unsigned int v, addr, bpt, cpt;
- struct adapter *adap = to_net_dev(d)->priv;
+ ssize_t len;
addr = A_TP_TX_MOD_Q1_Q0_RATE_LIMIT - sched / 2;
rtnl_lock();
@@ -581,10 +588,11 @@ static ssize_t tm_attr_show(struct device *d, struct
device_attribute *attr,
static ssize_t tm_attr_store(struct device *d, struct device_attribute *attr,
[PATCH 2.6.23 0/2] cxgb3 driver fixes
Jeff, I'm resubmitting the cxgb3 dev->priv issue. I'm also submitting a patch fixing the engine microcode loading. The first patch changes in both cxgb3 and iw_cxgb3 related to the dev->priv issue. The second patch allows the driver to load the engine microcode at the right time - when a port is brought up as opposed to the module getting loaded. It does a better job at logging the loading activity, and loosen the strict version requirement currently in place. Cheers, Divy - 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: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc
Pete/Piet Delaney wrote: We are getting a problem with VMware where kernel text is the schedler is getting wacked with four null bytes into the code. Thought I'd use the current linux-2.6-kgdb.git tree and possible the CONFIG_DEBUG_RODATA patch to make kernel text readonly: https://www.x86-64.org/pipermail/patches/2007-March/003666.html I thought the kernel text was RO and gdb had to disable it to insert a breakpoint. If you are going to make all the kernel text RO, then you are going to have to add some code to the kgdb write memory so as to unprotect a given page or all the breakpoint writes are going to fail. Alternatively you can use HW breakpoints. But, I have no idea if your VM Ware simulated HW emulate HW breakpoint registers or not. Jason. - 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 8957] New: Exported functions and variables should not be reachable by the outside of the module until module_init finishes
On Wed, 29 Aug 2007 19:33:48 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > On Wed, 29 Aug 2007 11:33:06 -0700 (PDT) [EMAIL PROTECTED] wrote: > > > >> http://bugzilla.kernel.org/show_bug.cgi?id=8957 > >> > >>Summary: Exported functions and variables should not be > >> reachable > >> by the outside of the module until module_init finishes > >>Product: Other > >>Version: 2.5 > >> KernelVersion: 2.6.23-rc4 > >> Platform: All > >> OS/Version: Linux > >> Tree: Mainline > >> Status: NEW > >> Severity: normal > >> Priority: P1 > >> Component: Modules > >> AssignedTo: [EMAIL PROTECTED] > >> ReportedBy: [EMAIL PROTECTED] > >> > >> > >> Problem Description: a module's exported functions can be called before > >> before > >> they are properly initialized by the module_init function. > >> > >> Steps to reproduce: write a module that exports functions that require > >> initialization by the module_init function to work correctly. > >> > >> E.g. spin lock variables are no longer allowed to be initialized by C > >> initializers of the module but only by spin_lock_init that can be called > >> by the > >> module_init function. If an exported function calls spin_lock before it is > >> initialized, it deadlocks. > >> > > > > ooh, nice bug ;) > > Under what circumstances is this actually happening? What are these > functions that are being called? > > Normally things are set up such that this isn't a problem, i.e. if > module A depends on module B, module A can't load until module B is > finished loading. > Good point. This thus-far-undescribed module could make its internals externally visible via one of the kernel's many register_foo() interfaces, but it would be a buggy module if it was doing register_foo(my_foo) before my_foo() was ready to be called. - 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: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc
Pete/Piet Delaney wrote: Why am I getting this when I do: git clone http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git I have only ever used: git clone git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git Jason. - 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/
Forced unmounting for removable devices
*This message was transferred with a trial version of CommuniGate(r) Pro* This might have been discussed a few years ago, but things have changed. I'm talking about patches like this one (I'm not the author): http://developer.osdl.org/dev/fumount/#kernel1 The current situation requires a way to forcibly unmount removable media. Consider the following (real) scenario. Someone has a box with hald + dbus + ivman to support "supermounting" the CDROM drive. He has to install a 2 CD application using Wine for example, but the setup application prevents normal unmounting of the first one. Then he goes on and pushes the button to eject the CD, lazy-unmounting the media. The kernel goes mad and all attempts to load the second CD fail (the kernel hasn't got rid of the first fs). If there was anything like a real forced unmounting, things would have worked well, as on MS Windows itself. As far as I can see, there is no other sane way to solve such problems. So, what's keeping such patches from making their way into the mainstream kernel? All (but maybe I haven't searched enough) arguments against such a feature that I've seen by now just say "it's not needed", "it's not worth it" and so on, and many of them refer to network mounts. P.S.: I'm not saying lazy unmounting should be replaced. They both make sense, depending on the scenario. - 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: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc
On Wed, 29 Aug 2007 18:19:29 -0700 Pete/Piet Delaney wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Pete/Piet Delaney wrote: > > Jason Wessel wrote: > >> Andrew Morton wrote: > >>> On Wed, 22 Aug 2007 17:44:12 -0500 > >>> Jason Wessel <[EMAIL PROTECTED]> wrote: > >>> > >>> > +while (!atomic_read(_active)); > > >>> eek. We're in the process of hunting down and eliminating exactly this > >>> construct. There have been cases where the compiler cached the > >>> atomic_read() result in a register, turning the above into an infinite > >>> loop. > >>> > >>> Plus we should never add power-burners like that into the kernel > >>> anyway. That loop should have a cpu_relax() in it. Which will also > >>> fix the > >>> compiler problem described above. > >>> > >>> > >> Agreed, and fixed with a cpu_relax. > > > >>> Thirdly, please always add a newline when coding statements like that: > >>> > >>> while (expr()) > >>> ; > >>> > >> The other instances I found of the same problem in the kgdb core are > >> fixed too. > > > >> I merged all the changes into the for_mm branch in the kgdb git tree. > > > > Where is the kgdb git tree? > > Why am I getting this when I do: > > git clone > http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git > > - > > error: Couldn't get > http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git/refs/tags/v2.6.11 > for tags/v2.6.11 > The requested URL returned error: 404 > error: Could not interpret tags/v2.6.11 as something to pull > rm: cannot remove directory > `/nethome/piet/Src/linux/git/jwessel/linux-2.6-kgdb/.git/clone-tmp': > Directory not empty > /nethome/piet/Src/linux/git/jwessel$ > - > See the URLs at the top of http://git.kernel.org/?p=linux/kernel/git/jwessel/linux-2.6-kgdb.git;a=summary and try one of those (the git one preferably). > We are getting a problem with VMware where kernel text is the schedler > is getting wacked with four null bytes into the code. Thought I'd use > the current linux-2.6-kgdb.git tree and possible the CONFIG_DEBUG_RODATA > patch to make kernel text readonly: > > https://www.x86-64.org/pipermail/patches/2007-March/003666.html > > I thought the kernel text was RO and gdb had to disable it to > insert a breakpoint. > > - -piet > > > > > -piet > > > >> Thanks, > >> Jason. > >> - > >> 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/ > > > > > - - > 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/ > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFG1hshJICwm/rv3hoRAhTGAJ46pq69zYHqRmT+yTmRx+RVh8aBtgCfdyFM > gl91xCFTy0NJxHalVXpd9Os= > =c8FZ > -END PGP SIGNATURE- > - > 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/ > --- ~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/
Re: [PATCH 5/5] Net: ath5k, kconfig changes
2007/8/28, Christoph Hellwig <[EMAIL PROTECTED]>: > On Tue, Aug 28, 2007 at 12:01:30PM -0400, Jiri Slaby wrote: > > +config ATH5K_AR5210 > > + bool "Support AR5210" > > + depends on ATH5K > > + default y > > + > > +config ATH5K_AR5211 > > + bool "Support AR5211" > > + depends on ATH5K > > + default y > > + > > +config ATH5K_AR5212 > > + bool "Support AR5212" > > + depends on ATH5K > > + default y > > Please don't add more default statements. > > Also this whole patch seems rather pointless. It saves only > very little and turns the driver into a complete ifdef maze. It saves big chunks of code (not only initial register settings arrays) and we'll extend it's use more inside ath5k_hw.c Trust me this is a very useful step, eg. check out descriptor processing / setup or PHY functions (calibrate/channel set etc). For example AR5210 mac chip only comes with RF5110 phy chip so we can get rid of RF5111/RF5112 code, AR5211 comes with RF5111 so we can get rid of RF5110 and RF5112 code and AR5212 comes with RF5111 or RF5112 so we get rid of RF5110. This thing also saves lots of checks during runtime (some of them happen verry frequently, eg. durring descriptor processing). Also most people will use 5212 code only, 5211 cards are on some old laptops and 5210, well i couldn't even find a 5210 for actual testing :P -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick - 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: speeding up swapoff
Daniel Drake wrote: On Wed, 2007-08-29 at 07:30 -0700, Arjan van de Ven wrote: My experiments show that when there is not much free physical memory, swapoff moves pages out of swap at a rate of approximately 5mb/sec. sounds like about disk speed (at random-seek IO pattern) We are only using 'standard' seagate SATA disks, but I would have thought much more performance (40+ mb/sec) would be reachable. Not if it is doing random seeks.. before you go there... is this a "real life" problem? Or just a mostly-artificial corner case? (the answer to that obviously is relevant for the 'should we really care' question) It's more-or-less a real life problem. We have an interactive application which, when triggered by the user, performs rendering tasks which must operate in real-time. In attempt to secure performance, we want to ensure everything is memory resident and that nothing might be swapped out during the process. So, we run swapoff at that time. If there is a decent number of pages swapped out, the user sits for a while at a 'please wait' screen, which is not desirable. To throw some numbers out there, likely more than a minute for 400mb of swapped pages. Sure, we could run the whole interactive application with swap disabled, which is pretty much what we do. However we have other non-real-time processing tasks which are very memory hungry and do require swap. So, there are 'corner cases' where the user can reach the real-time part of the interactive application when there is a lot of memory swapped out. Normally mlockall is what is used in this sort of situation, that way it doesn't force all swapped data in for every app. It's possible that calling this with lots of swapped pages in the app at the time may have the same problem though. -- 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: [Bugme-new] [Bug 8957] New: Exported functions and variables should not be reachable by the outside of the module until module_init finishes
Andrew Morton wrote: On Wed, 29 Aug 2007 11:33:06 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8957 Summary: Exported functions and variables should not be reachable by the outside of the module until module_init finishes Product: Other Version: 2.5 KernelVersion: 2.6.23-rc4 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Problem Description: a module's exported functions can be called before before they are properly initialized by the module_init function. Steps to reproduce: write a module that exports functions that require initialization by the module_init function to work correctly. E.g. spin lock variables are no longer allowed to be initialized by C initializers of the module but only by spin_lock_init that can be called by the module_init function. If an exported function calls spin_lock before it is initialized, it deadlocks. ooh, nice bug ;) Under what circumstances is this actually happening? What are these functions that are being called? Normally things are set up such that this isn't a problem, i.e. if module A depends on module B, module A can't load until module B is finished loading. -- 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: 2.6.23-rc3-mm1: inlining failures in sound/pci/hda/hda_codec.c
Hi,
>On 8/23/07, Takashi Iwai <[EMAIL PROTECTED]> wrote:
> At Wed, 22 Aug 2007 22:23:03 +0200,
> Mariusz Kozlowski wrote:
> >
> > Hello,
> >
> > This is from x86_32 with gcc 3.4.6:
> >
> > CC [M] sound/pci/hda/hda_codec.o
> > sound/pci/hda/hda_codec.c: In function `snd_hda_codec_free':
> > sound/pci/hda/hda_codec.c:517: sorry, unimplemented: inlining failed
> > in
> call to 'free_hda_cache': function body not available
> > sound/pci/hda/hda_codec.c:534: sorry, unimplemented: called from
> > here
> > sound/pci/hda/hda_codec.c:517: sorry, unimplemented: inlining failed
> > in
> call to 'free_hda_cache': function body not available
> > sound/pci/hda/hda_codec.c:535: sorry, unimplemented: called from
> > here
> > make[3]: *** [sound/pci/hda/hda_codec.o] Error 1
> > make[2]: *** [sound/pci/hda] Error 2
> > make[1]: *** [sound/pci] Error 2
> > make: *** [sound] Error 2
>
> Since it doesn't happen with gcc-4.x, this looks like a gcc-3.x
> specific problem. Does the patch below fix?
>
>
> Taksahi
>
> diff -r db9001b20d29 pci/hda/hda_codec.c
> --- a/pci/hda/hda_codec.c Wed Aug 22 14:19:45 2007 +0200
> +++ b/pci/hda/hda_codec.c Wed Aug 22 23:06:00 2007 +0200
> @@ -514,7 +514,7 @@ static int read_widget_caps(struct hda_c
>
> static void init_hda_cache(struct hda_cache_rec *cache,
> unsigned int record_size);
> -static inline void free_hda_cache(struct hda_cache_rec *cache);
> +static void free_hda_cache(struct hda_cache_rec *cache);
>
> /*
> * codec destructor
> @@ -707,7 +707,7 @@ static void __devinit init_hda_cache(str
> cache->record_size = record_size;
> }
>
> -static inline void free_hda_cache(struct hda_cache_rec *cache)
> +static void free_hda_cache(struct hda_cache_rec *cache)
> {
> kfree(cache->buffer);
> }
How about this one:
diff -uprN linux/sound/pci/hda/hda_codec.c linux.new/sound/pci/hda/hda_codec.c
--- linux/sound/pci/hda/hda_codec.c 2007-08-30 09:27:42.0 +0800
+++ linux.new/sound/pci/hda/hda_codec.c 2007-08-30 09:27:50.0 +0800
@@ -514,7 +514,11 @@ static int read_widget_caps(struct hda_c
static void init_hda_cache(struct hda_cache_rec *cache,
unsigned int record_size);
-static inline void free_hda_cache(struct hda_cache_rec *cache);
+
+static inline void free_hda_cache(struct hda_cache_rec *cache)
+{
+ kfree(cache->buffer);
+}
/*
* codec destructor
@@ -707,10 +711,6 @@ static void __devinit init_hda_cache(str
cache->record_size = record_size;
}
-static inline void free_hda_cache(struct hda_cache_rec *cache)
-{
- kfree(cache->buffer);
-}
/* query the hash. allocate an entry if not found. */
static struct hda_cache_head *get_alloc_hash(struct hda_cache_rec *cache,
> -
> 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/
>
-
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: nmi_watchdog=2 regression in 2.6.21
On Wed, 2007-08-29 at 14:24 -0700, Stephane Eranian wrote: > Now on Core Duo, there is no PEBS anyway, so it is okay to use counter 0 > for NMI. The problem is that the detection code in perfctr-watchdog.c > treats a Core Duo and a Core 2 Duo the same way as they both have the > X86_FEATURE_ARCH_PERFMON bit set. > > I have attached a patch with handle the case of the Core Duo. Unfortunately, > I do not own one so I cannot test it. I would appreciate if you could > try re-applying my counter 0 -> 1 patch + this new one to see if you > have the problem with the NMI getting stuck. I tested your patch .. The system doesn't hang, but the NMI seems to disappear .. The check_nmi_watchdog() is not called, and the NMI never actually starts firing .. Is that what you had intended? 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] fix the max path calculation in radix-tree.c
On Wed, Aug 29, 2007 at 05:39:18PM -0400, Jeff Moyer wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
>
> > On Tue, Aug 21, 2007 at 03:48:42PM -0400, Jeff Moyer wrote:
> >> Hi,
> >>
> >> A while back, Nick Piggin introduced a patch to reduce the node memory
> >> usage for small files (commit cfd9b7df4abd3257c9e381b0e445817b26a51c0c):
> >>
> >> -#define RADIX_TREE_MAP_SHIFT 6
> >> +#define RADIX_TREE_MAP_SHIFT (CONFIG_BASE_SMALL ? 4 : 6)
> >>
> >> Unfortunately, he didn't take into account the fact that the
> >> calculation of the maximum path was based on an assumption of having
> >> to round up:
> >>
> >> #define RADIX_TREE_MAX_PATH (RADIX_TREE_INDEX_BITS/RADIX_TREE_MAP_SHIFT +
> >> 2)
> >>
> >> So, if CONFIG_BASE_SMALL is set, you will end up with a
> >> RADIX_TREE_MAX_PATH that is one greater than necessary. The practical
> >> upshot of this is just a bit of wasted memory (one long in the
> >> height_to_maxindex array, an extra pre-allocated radix tree node per
> >> cpu, and extra stack usage in a couple of functions), but it seems
> >> worth getting right.
> >>
> >> It's also worth noting that I never build with CONFIG_BASE_SMALL.
> >> What I did to test this was duplicate the code in a small user-space
> >> program and check the results of the calculations for max path and the
> >> contents of the height_to_maxindex array.
> >>
> >
> > OK, after you DIV_ROUND_UP, what is the extra 1 for? For paths, it is
> > because
> > they are NULL terminated paths I guess (without remembering too hard), and
> > for
> > height_to_maxindex array it is needed for 0-height trees I think. So it
> > would
> > be kinda cleaner to have the _real_ MAX_PATH, and two other constants for
> > this array and the paths arrays (that just happen to be identical due to
> > implementation). Don't you think?
> >
> > But that's not to nack this patch. On the contrary I think your logic is
> > correct, and it should be fixed. I didn't check the maths myself but I trust
> > you :)
>
> Hi, Nick,
>
> As I said, I wasn't sure what to name the constants for the path and
> height arrays, so I just commented the +1 there. I've been running
Hi Jeff,
That looks really nice, thanks. No complaints from me.
Acked-by: Nick Piggin <[EMAIL PROTECTED]>
> this on one of my 64bit test systems successfully for about a day,
> now. The one code path I was concerned about was
> radix_tree_node_alloc, since the prealloc array changes size with this
> patch. I stepped through the code by hand and it looks right to me.
> Additionally, I wrote a kprobe that would simulate the
> kmem_cache_alloc failure. I then inserted a node at max height into
> an empty tree with preemption disabled. I verified, using the crash
> utility, that the tree was constructed and filled in properly.
>
> You can find the kprobe at http://people.redhat.com/jmoyer/radix-tree/.
>
> Signed-off-by: Jeff Moyer <[EMAIL PROTECTED]>
>
> diff --git a/lib/radix-tree.c b/lib/radix-tree.c
> index 514efb2..d2655cb 100644
> --- a/lib/radix-tree.c
> +++ b/lib/radix-tree.c
> @@ -60,9 +60,14 @@ struct radix_tree_path {
> };
>
> #define RADIX_TREE_INDEX_BITS (8 /* CHAR_BIT */ * sizeof(unsigned long))
> -#define RADIX_TREE_MAX_PATH (RADIX_TREE_INDEX_BITS/RADIX_TREE_MAP_SHIFT + 2)
> +#define RADIX_TREE_MAX_PATH (DIV_ROUND_UP(RADIX_TREE_INDEX_BITS, \
> + RADIX_TREE_MAP_SHIFT))
>
> -static unsigned long height_to_maxindex[RADIX_TREE_MAX_PATH] __read_mostly;
> +/*
> + * The height_to_maxindex array needs to be one deeper than the maximum
> + * path as height 0 holds only 1 entry.
> + */
> +static unsigned long height_to_maxindex[RADIX_TREE_MAX_PATH + 1]
> __read_mostly;
>
> /*
> * Radix tree node cache.
> @@ -487,7 +492,11 @@ EXPORT_SYMBOL(radix_tree_tag_set);
> void *radix_tree_tag_clear(struct radix_tree_root *root,
> unsigned long index, unsigned int tag)
> {
> - struct radix_tree_path path[RADIX_TREE_MAX_PATH], *pathp = path;
> + /*
> + * The radix tree path needs to be one longer than the maximum path
> + * since the "list" is null terminated.
> + */
> + struct radix_tree_path path[RADIX_TREE_MAX_PATH + 1], *pathp = path;
> struct radix_tree_node *slot = NULL;
> unsigned int height, shift;
>
> @@ -882,7 +891,11 @@ static inline void radix_tree_shrink(struct
> radix_tree_root *root)
> */
> void *radix_tree_delete(struct radix_tree_root *root, unsigned long index)
> {
> - struct radix_tree_path path[RADIX_TREE_MAX_PATH], *pathp = path;
> + /*
> + * The radix tree path needs to be one longer than the maximum path
> + * since the "list" is null terminated.
> + */
> + struct radix_tree_path path[RADIX_TREE_MAX_PATH + 1], *pathp = path;
> struct radix_tree_node *slot = NULL;
> struct radix_tree_node *to_free;
> unsigned int height, shift;
-
To unsubscribe from this list: send the line "unsubscribe
Re: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pete/Piet Delaney wrote: > Jason Wessel wrote: >> Andrew Morton wrote: >>> On Wed, 22 Aug 2007 17:44:12 -0500 >>> Jason Wessel <[EMAIL PROTECTED]> wrote: >>> >>> +while (!atomic_read(_active)); >>> eek. We're in the process of hunting down and eliminating exactly this >>> construct. There have been cases where the compiler cached the >>> atomic_read() result in a register, turning the above into an infinite >>> loop. >>> >>> Plus we should never add power-burners like that into the kernel >>> anyway. That loop should have a cpu_relax() in it. Which will also >>> fix the >>> compiler problem described above. >>> >>> >> Agreed, and fixed with a cpu_relax. > >>> Thirdly, please always add a newline when coding statements like that: >>> >>> while (expr()) >>> ; >>> >> The other instances I found of the same problem in the kgdb core are >> fixed too. > >> I merged all the changes into the for_mm branch in the kgdb git tree. > > Where is the kgdb git tree? Why am I getting this when I do: git clone http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git - error: Couldn't get http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git/refs/tags/v2.6.11 for tags/v2.6.11 The requested URL returned error: 404 error: Could not interpret tags/v2.6.11 as something to pull rm: cannot remove directory `/nethome/piet/Src/linux/git/jwessel/linux-2.6-kgdb/.git/clone-tmp': Directory not empty /nethome/piet/Src/linux/git/jwessel$ - We are getting a problem with VMware where kernel text is the schedler is getting wacked with four null bytes into the code. Thought I'd use the current linux-2.6-kgdb.git tree and possible the CONFIG_DEBUG_RODATA patch to make kernel text readonly: https://www.x86-64.org/pipermail/patches/2007-March/003666.html I thought the kernel text was RO and gdb had to disable it to insert a breakpoint. - -piet > > -piet > >> Thanks, >> Jason. >> - >> 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/ > > - - 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/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1hshJICwm/rv3hoRAhTGAJ46pq69zYHqRmT+yTmRx+RVh8aBtgCfdyFM gl91xCFTy0NJxHalVXpd9Os= =c8FZ -END PGP SIGNATURE- - 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] local_t Documentation update 2
On Wed, Aug 29, 2007 at 08:19:53AM -0400, Mathieu Desnoyers wrote:
> local_t Documentation update 2
>
> Grant Grundler was asking for more detail about correct usage of local atomic
> operations and suggested adding the resulting summary to local_ops.txt.
>
> "Please add a bit more detail. If DaveM is correct (he normally is), then
> there must be limits on how the local_t can be used in the kernel process
> and interrupt contexts. I'd like those rules spelled out very clearly
> since it's easy to get wrong and tracking down such a bug is quite painful."
>
> It applies on top of 2.6.23-rc3-mm1.
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> CC: Grant Grundler <[EMAIL PROTECTED]>
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
thanks!
grant
> ---
> Documentation/local_ops.txt | 23 +++
> 1 file changed, 23 insertions(+)
>
> Index: linux-2.6-lttng/Documentation/local_ops.txt
> ===
> --- linux-2.6-lttng.orig/Documentation/local_ops.txt 2007-08-29
> 08:09:34.0 -0400
> +++ linux-2.6-lttng/Documentation/local_ops.txt 2007-08-29
> 08:15:37.0 -0400
> @@ -45,6 +45,29 @@ long fails. The definition looks like :
> typedef struct { atomic_long_t a; } local_t;
>
>
> +* Rules to follow when using local atomic operations
> +
> +- Variables touched by local ops must be per cpu variables.
> +- _Only_ the CPU owner of these variables must write to them.
> +- This CPU can use local ops from any context (process, irq, softirq, nmi,
> ...)
> + to update its local_t variables.
> +- Preemption (or interrupts) must be disabled when using local ops in
> + process context to make sure the process won't be migrated to a
> + different CPU between getting the per-cpu variable and doing the
> + actual local op.
> +- When using local ops in interrupt context, no special care must be
> + taken on a mainline kernel, since they will run on the local CPU with
> + preemption already disabled. I suggest, however, to explicitly
> + disable preemption anyway to make sure it will still work correctly on
> + -rt kernels.
> +- Reading the local cpu variable will provide the current copy of the
> + variable.
> +- Reads of these variables can be done from any CPU, because updates to
> + "long", aligned, variables are always atomic. Since no memory
> + synchronization is done by the writer CPU, an outdated copy of the
> + variable can be read when reading some _other_ cpu's variables.
> +
> +
> * How to use local atomic operations
>
> #include
>
> --
> Mathieu Desnoyers
> Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
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 1/4] Large Blocksize support for Ext2/3/4
On Wed, 29 Aug 2007, Mingming Cao wrote: > It's quite simple to support large block size in ext2/3/4, mostly just > enlarge the block size limit. But it is NOT possible to have 64kB > blocksize on ext2/3/4 without some changes to the directory handling > code. The reason is that an empty 64kB directory block would have a > rec_len == (__u16)2^16 == 0, and this would cause an error to be hit in > the filesystem. The proposed solution is to put 2 empty records in such > a directory, or to special-case an impossible value like rec_len = > 0x to handle this. Ahh. Good. I could add the path to the large blocksize patchset? - 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] Adds full stack to critical-section tracing
On Fri, 2007-08-10 at 08:14 -0600, Gregory Haskins wrote:
> ---
>
> include/linux/sched.h |7 +--
> kernel/latency_trace.c | 18 +++---
> 2 files changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 8ebb43c..233d26c 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1306,10 +1306,13 @@ struct task_struct {
> #endif
>
> #define MAX_PREEMPT_TRACE 25
> +#define MAX_PREEMPT_TRACE_DEPTH 5
>
> #ifdef CONFIG_PREEMPT_TRACE
> - unsigned long preempt_trace_eip[MAX_PREEMPT_TRACE];
> - unsigned long preempt_trace_parent_eip[MAX_PREEMPT_TRACE];
> + struct {
> + struct stack_trace trace;
> + unsigned long data[MAX_PREEMPT_TRACE_DEPTH];
> + } preempt_trace[MAX_PREEMPT_TRACE];
These changes need some fixing .. The "struct stack_trace"
infrastructure is based on CONFIG_STACKTRACE , so at least you would
want to ifdef your changes on that config options ..
I modified you patch to include the ifdefs,
ftp://source.mvista.com/pub/dwalker/misc/debug-preempt-5-levels-of-stack-frames.patch
The other problem I noticed is that the save_stack_trace(trace); seems
kind of heavy weight to be calling from inside add_preempt_count. If
your only going to a depth of 5 you could potentially use there macros,
#ifdef CONFIG_FRAME_POINTER
# ifndef CONFIG_ARM
# define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0))
# define CALLER_ADDR1 ((unsigned long)__builtin_return_address(1))
# define CALLER_ADDR2 ((unsigned long)__builtin_return_address(2))
# define CALLER_ADDR3 ((unsigned long)__builtin_return_address(3))
# define CALLER_ADDR4 ((unsigned long)__builtin_return_address(4))
# define CALLER_ADDR5 ((unsigned long)__builtin_return_address(5))
# else
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: [2.6 patch] remove securebits
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> To summarize more clearly, I think that so long as we support
> process trees with a sort of !SECURE_NOROOT support, that
> support should include the ability to use prctl(KEEP_CAPS) the
> way one uses it now.
> When a process tree is in strict capability mode,
> prctl(PR_{G,S}ET_KEEP_CAPS) should return -EINVAL.
I agree. I'll try to code it up in a way that its clear how to delete
this functionality when folk realize they no longer need it...
- -static inline int get_file_caps(struct linux_binprm *bprm)
+int cap_bprm_set_security(struct linux_binprm *bprm)
{
bprm_clear_caps(bprm);
+ bprm_force_uid0_caps(bprm);
+ current->keep_capabilities = 0;
> This is being moved from bprm_apply to bprm_set, which moves it
> earlier. If exec fails later on, keep_capabilities might be set
> to 0 even though exec failed.
I'll look at it again, but I had thought I had preserved the previous
behavior with this condensed version of the code. Are you suggesting an
improvement to what was there, or pointing out I'm inadvertently
breaking the old behavior?
Thanks
Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG1hSu+bHCR3gb8jsRAhHJAJ9Pn8w2InrhbNjBjpqT9NEE0HX61QCgkBR8
Bo1xJcZGqbsr+IhQ+DDyENA=
=PKx4
-END PGP SIGNATURE-
-
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 3/4] ext3: fix rec_len overflow with 64KB block size
[3/4] ext3: fix rec_len overflow
- prevent rec_len from overflow with 64KB blocksize
Signed-off-by: Takashi Sato <[EMAIL PROTECTED]>
Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
---
fs/ext3/dir.c | 13 ---
fs/ext3/namei.c | 88 +++-
include/linux/ext3_fs.h |9
3 files changed, 91 insertions(+), 19 deletions(-)
Index: linux-2.6.23-rc3/fs/ext3/dir.c
===
--- linux-2.6.23-rc3.orig/fs/ext3/dir.c 2007-08-12 21:25:24.0 -0700
+++ linux-2.6.23-rc3/fs/ext3/dir.c 2007-08-29 15:40:06.0 -0700
@@ -100,10 +100,11 @@ static int ext3_readdir(struct file * fi
unsigned long offset;
int i, stored;
struct ext3_dir_entry_2 *de;
- struct super_block *sb;
int err;
struct inode *inode = filp->f_path.dentry->d_inode;
int ret = 0;
+ struct super_block *sb = inode->i_sb;
+ unsigned tail = sb->s_blocksize;
sb = inode->i_sb;
@@ -167,8 +168,11 @@ revalidate:
* readdir(2), then we might be pointing to an invalid
* dirent right now. Scan from the start of the block
* to make sure. */
- if (filp->f_version != inode->i_version) {
- for (i = 0; i < sb->s_blocksize && i < offset; ) {
+ if (tail > EXT3_DIR_MAX_REC_LEN) {
+ tail = EXT3_DIR_MAX_REC_LEN;
+ }
+if (filp->f_version != inode->i_version) {
+ for (i = 0; i < tail && i < offset; ) {
de = (struct ext3_dir_entry_2 *)
(bh->b_data + i);
/* It's too expensive to do a full
@@ -189,7 +193,7 @@ revalidate:
}
while (!error && filp->f_pos < inode->i_size
- && offset < sb->s_blocksize) {
+ && offset < tail) {
de = (struct ext3_dir_entry_2 *) (bh->b_data + offset);
if (!ext3_check_dir_entry ("ext3_readdir", inode, de,
bh, offset)) {
@@ -225,6 +229,7 @@ revalidate:
}
filp->f_pos += le16_to_cpu(de->rec_len);
}
+ filp->f_pos = EXT3_DIR_ADJUST_TAIL_OFFS(filp->f_pos,
sb->s_blocksize);
offset = 0;
brelse (bh);
}
Index: linux-2.6.23-rc3/fs/ext3/namei.c
===
--- linux-2.6.23-rc3.orig/fs/ext3/namei.c 2007-08-12 21:25:24.0
-0700
+++ linux-2.6.23-rc3/fs/ext3/namei.c2007-08-29 15:30:10.0 -0700
@@ -262,9 +262,13 @@ static struct stats dx_show_leaf(struct
unsigned names = 0, space = 0;
char *base = (char *) de;
struct dx_hash_info h = *hinfo;
+ unsigned tail = size;
printk("names: ");
- while ((char *) de < base + size)
+ if (tail > EXT3_DIR_MAX_REC_LEN) {
+ tail = EXT3_DIR_MAX_REC_LEN;
+ }
+ while ((char *) de < base + tail)
{
if (de->inode)
{
@@ -677,8 +681,12 @@ static int dx_make_map (struct ext3_dir_
int count = 0;
char *base = (char *) de;
struct dx_hash_info h = *hinfo;
+ unsigned tail = size;
- while ((char *) de < base + size)
+ if (tail > EXT3_DIR_MAX_REC_LEN) {
+ tail = EXT3_DIR_MAX_REC_LEN;
+ }
+ while ((char *) de < base + tail)
{
if (de->name_len && de->inode) {
ext3fs_dirhash(de->name, de->name_len, );
@@ -775,9 +783,13 @@ static inline int search_dirblock(struct
int de_len;
const char *name = dentry->d_name.name;
int namelen = dentry->d_name.len;
+ unsigned tail = dir->i_sb->s_blocksize;
de = (struct ext3_dir_entry_2 *) bh->b_data;
- dlimit = bh->b_data + dir->i_sb->s_blocksize;
+ if (tail > EXT3_DIR_MAX_REC_LEN) {
+ tail = EXT3_DIR_MAX_REC_LEN;
+ }
+ dlimit = bh->b_data + tail;
while ((char *) de < dlimit) {
/* this code is executed quadratically often */
/* do minimal checking `by hand' */
@@ -1115,6 +1127,9 @@ static struct ext3_dir_entry_2* dx_pack_
unsigned rec_len = 0;
prev = to = de;
+ if (size > EXT3_DIR_MAX_REC_LEN) {
+ size = EXT3_DIR_MAX_REC_LEN;
+ }
while ((char*)de < base + size) {
next = (struct ext3_dir_entry_2 *) ((char *) de +
le16_to_cpu(de->rec_len));
@@ -1180,8 +1195,15 @@ static struct ext3_dir_entry_2 *do_split
/* Fancy dance to stay within two buffers */
de2 = dx_move_dirents(data1,
[RFC 4/4]ext4: fix rec_len overflow with 64KB block size
[4/4] ext4: fix rec_len overflow
- prevent rec_len from overflow with 64KB blocksize
Signed-off-by: Takashi Sato <[EMAIL PROTECTED]>
Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
---
fs/ext4/dir.c | 11 --
fs/ext4/namei.c | 88 +++-
include/linux/ext4_fs.h |9
3 files changed, 90 insertions(+), 18 deletions(-)
Index: linux-2.6.23-rc3/fs/ext4/dir.c
===
--- linux-2.6.23-rc3.orig/fs/ext4/dir.c 2007-08-12 21:25:24.0 -0700
+++ linux-2.6.23-rc3/fs/ext4/dir.c 2007-08-29 15:33:19.0 -0700
@@ -100,10 +100,11 @@ static int ext4_readdir(struct file * fi
unsigned long offset;
int i, stored;
struct ext4_dir_entry_2 *de;
- struct super_block *sb;
int err;
struct inode *inode = filp->f_path.dentry->d_inode;
+ struct super_block *sb = inode->i_sb;
int ret = 0;
+ unsigned tail = sb->s_blocksize;
sb = inode->i_sb;
@@ -166,8 +167,11 @@ revalidate:
* readdir(2), then we might be pointing to an invalid
* dirent right now. Scan from the start of the block
* to make sure. */
+ if (tail > EXT4_DIR_MAX_REC_LEN) {
+ tail = EXT4_DIR_MAX_REC_LEN;
+ }
if (filp->f_version != inode->i_version) {
- for (i = 0; i < sb->s_blocksize && i < offset; ) {
+ for (i = 0; i < tail && i < offset; ) {
de = (struct ext4_dir_entry_2 *)
(bh->b_data + i);
/* It's too expensive to do a full
@@ -188,7 +192,7 @@ revalidate:
}
while (!error && filp->f_pos < inode->i_size
- && offset < sb->s_blocksize) {
+ && offset < tail) {
de = (struct ext4_dir_entry_2 *) (bh->b_data + offset);
if (!ext4_check_dir_entry ("ext4_readdir", inode, de,
bh, offset)) {
@@ -225,6 +229,7 @@ revalidate:
}
filp->f_pos += le16_to_cpu(de->rec_len);
}
+ filp->f_pos = EXT4_DIR_ADJUST_TAIL_OFFS(filp->f_pos,
sb->s_blocksize);
offset = 0;
brelse (bh);
}
Index: linux-2.6.23-rc3/fs/ext4/namei.c
===
--- linux-2.6.23-rc3.orig/fs/ext4/namei.c 2007-08-28 11:08:48.0
-0700
+++ linux-2.6.23-rc3/fs/ext4/namei.c2007-08-29 15:30:22.0 -0700
@@ -262,9 +262,13 @@ static struct stats dx_show_leaf(struct
unsigned names = 0, space = 0;
char *base = (char *) de;
struct dx_hash_info h = *hinfo;
+ unsigned tail = size;
printk("names: ");
- while ((char *) de < base + size)
+ if (tail > EXT4_DIR_MAX_REC_LEN) {
+ tail = EXT4_DIR_MAX_REC_LEN;
+ }
+ while ((char *) de < base + tail)
{
if (de->inode)
{
@@ -677,8 +681,12 @@ static int dx_make_map (struct ext4_dir_
int count = 0;
char *base = (char *) de;
struct dx_hash_info h = *hinfo;
+ unsigned tail = size;
- while ((char *) de < base + size)
+ if (tail > EXT4_DIR_MAX_REC_LEN) {
+ tail = EXT4_DIR_MAX_REC_LEN;
+ }
+ while ((char *) de < base + tail)
{
if (de->name_len && de->inode) {
ext4fs_dirhash(de->name, de->name_len, );
@@ -773,9 +781,13 @@ static inline int search_dirblock(struct
int de_len;
const char *name = dentry->d_name.name;
int namelen = dentry->d_name.len;
+ unsigned tail = dir->i_sb->s_blocksize;
de = (struct ext4_dir_entry_2 *) bh->b_data;
- dlimit = bh->b_data + dir->i_sb->s_blocksize;
+ if (tail > EXT4_DIR_MAX_REC_LEN) {
+ tail = EXT4_DIR_MAX_REC_LEN;
+ }
+ dlimit = bh->b_data + tail;
while ((char *) de < dlimit) {
/* this code is executed quadratically often */
/* do minimal checking `by hand' */
@@ -1113,6 +1125,9 @@ static struct ext4_dir_entry_2* dx_pack_
unsigned rec_len = 0;
prev = to = de;
+ if (size > EXT4_DIR_MAX_REC_LEN) {
+ size = EXT4_DIR_MAX_REC_LEN;
+ }
while ((char*)de < base + size) {
next = (struct ext4_dir_entry_2 *) ((char *) de +
le16_to_cpu(de->rec_len));
@@ -1178,8 +1193,15 @@ static struct ext4_dir_entry_2 *do_split
/* Fancy dance to stay within two buffers */
de2 = dx_move_dirents(data1, data2, map + split, count - split);
de =
[RFC 2/4]ext2: fix rec_len overflow with 64KB block size
[2/4] ext2: fix rec_len overflow
- prevent rec_len from overflow with 64KB blocksize
Signed-off-by: Takashi Sato <[EMAIL PROTECTED]>
Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
---
fs/ext2/dir.c | 46 --
include/linux/ext2_fs.h | 13 +
2 files changed, 49 insertions(+), 10 deletions(-)
Index: linux-2.6.23-rc3/fs/ext2/dir.c
===
--- linux-2.6.23-rc3.orig/fs/ext2/dir.c 2007-08-12 21:25:24.0 -0700
+++ linux-2.6.23-rc3/fs/ext2/dir.c 2007-08-29 15:29:51.0 -0700
@@ -94,9 +94,9 @@ static void ext2_check_page(struct page
goto out;
}
for (offs = 0; offs <= limit - EXT2_DIR_REC_LEN(1); offs += rec_len) {
+ offs = EXT2_DIR_ADJUST_TAIL_OFFS(offs, chunk_size);
p = (ext2_dirent *)(kaddr + offs);
rec_len = le16_to_cpu(p->rec_len);
-
if (rec_len < EXT2_DIR_REC_LEN(1))
goto Eshort;
if (rec_len & 3)
@@ -108,6 +108,7 @@ static void ext2_check_page(struct page
if (le32_to_cpu(p->inode) > max_inumber)
goto Einumber;
}
+ offs = EXT2_DIR_ADJUST_TAIL_OFFS(offs, chunk_size);
if (offs != limit)
goto Eend;
out:
@@ -283,6 +284,7 @@ ext2_readdir (struct file * filp, void *
de = (ext2_dirent *)(kaddr+offset);
limit = kaddr + ext2_last_byte(inode, n) - EXT2_DIR_REC_LEN(1);
for ( ;(char*)de <= limit; de = ext2_next_entry(de)) {
+ de = EXT2_DIR_ADJUST_TAIL_ADDR(kaddr, de,
sb->s_blocksize);
if (de->rec_len == 0) {
ext2_error(sb, __FUNCTION__,
"zero-length directory entry");
@@ -305,8 +307,10 @@ ext2_readdir (struct file * filp, void *
return 0;
}
}
+ filp->f_pos = EXT2_DIR_ADJUST_TAIL_OFFS(filp->f_pos,
sb->s_blocksize);
filp->f_pos += le16_to_cpu(de->rec_len);
}
+ filp->f_pos = EXT2_DIR_ADJUST_TAIL_OFFS(filp->f_pos,
sb->s_blocksize);
ext2_put_page(page);
}
return 0;
@@ -343,13 +347,14 @@ struct ext2_dir_entry_2 * ext2_find_entr
start = 0;
n = start;
do {
- char *kaddr;
+ char *kaddr, *page_start;
page = ext2_get_page(dir, n);
if (!IS_ERR(page)) {
- kaddr = page_address(page);
+ kaddr = page_start = page_address(page);
de = (ext2_dirent *) kaddr;
kaddr += ext2_last_byte(dir, n) - reclen;
while ((char *) de <= kaddr) {
+ de = EXT2_DIR_ADJUST_TAIL_ADDR(page_start, de,
dir->i_sb->s_blocksize);
if (de->rec_len == 0) {
ext2_error(dir->i_sb, __FUNCTION__,
"zero-length directory entry");
@@ -416,6 +421,7 @@ void ext2_set_link(struct inode *dir, st
unsigned to = from + le16_to_cpu(de->rec_len);
int err;
+ to = EXT2_DIR_ADJUST_TAIL_OFFS(to, inode->i_sb->s_blocksize);
lock_page(page);
err = page->mapping->a_ops->prepare_write(NULL, page, from, to);
BUG_ON(err);
@@ -446,6 +452,7 @@ int ext2_add_link (struct dentry *dentry
char *kaddr;
unsigned from, to;
int err;
+ char *page_start = NULL;
/*
* We take care of directory expansion in the same loop.
@@ -460,16 +467,28 @@ int ext2_add_link (struct dentry *dentry
if (IS_ERR(page))
goto out;
lock_page(page);
- kaddr = page_address(page);
+ kaddr = page_start = page_address(page);
dir_end = kaddr + ext2_last_byte(dir, n);
de = (ext2_dirent *)kaddr;
- kaddr += PAGE_CACHE_SIZE - reclen;
+ if (chunk_size < EXT2_DIR_MAX_REC_LEN) {
+ kaddr += PAGE_CACHE_SIZE - reclen;
+ } else {
+ kaddr += PAGE_CACHE_SIZE -
+ (chunk_size - EXT2_DIR_MAX_REC_LEN) - reclen;
+ }
while ((char *)de <= kaddr) {
+ de = EXT2_DIR_ADJUST_TAIL_ADDR(page_start, de,
chunk_size);
if ((char *)de == dir_end) {
/* We hit i_size */
name_len = 0;
- rec_len = chunk_size;
- de->rec_len = cpu_to_le16(chunk_size);
+
[RFC 1/4] Large Blocksize support for Ext2/3/4
The next 4 patches support large block size (up to PAGESIZE, max 64KB)
for ext2/3/4, originally from Takashi Sato.
http://marc.info/?l=linux-ext4=115768873518400=2
It's quite simple to support large block size in ext2/3/4, mostly just
enlarge the block size limit. But it is NOT possible to have 64kB
blocksize on ext2/3/4 without some changes to the directory handling
code. The reason is that an empty 64kB directory block would have a
rec_len == (__u16)2^16 == 0, and this would cause an error to be hit in
the filesystem. The proposed solution is to put 2 empty records in such
a directory, or to special-case an impossible value like rec_len =
0x to handle this.
The Patch-set consists of the following 4 patches.
[1/4] ext2/3/4: enlarge blocksize
- Allow blocksize up to pagesize
[2/4] ext2: fix rec_len overflow
- prevent rec_len from overflow with 64KB blocksize
[3/4] ext3: fix rec_len overflow
- prevent rec_len from overflow with 64KB blocksize
[4/4] ext4: fix rec_len overflow
- prevent rec_len from overflow with 64KB blocksize
Just rebase to 2.6.23-rc4 and against the ext4 patch queue. Compile tested
only.
Next steps:
Need a e2fsprogs changes to able test this feature. As mkfs needs to be
educated not assuming rec_len to be blocksize all the time.
Will try it with Christoph Lameter's large block patch next.
Signed-off-by: Takashi Sato <[EMAIL PROTECTED]>
Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
---
---
fs/ext2/super.c |2 +-
fs/ext3/super.c |5 -
fs/ext4/super.c |5 +
include/linux/ext2_fs.h |4 ++--
include/linux/ext3_fs.h |4 ++--
include/linux/ext4_fs.h |4 ++--
6 files changed, 16 insertions(+), 8 deletions(-)
Index: linux-2.6.23-rc3/fs/ext2/super.c
===
--- linux-2.6.23-rc3.orig/fs/ext2/super.c 2007-08-12 21:25:24.0
-0700
+++ linux-2.6.23-rc3/fs/ext2/super.c2007-08-29 15:22:29.0 -0700
@@ -775,7 +775,7 @@ static int ext2_fill_super(struct super_
brelse(bh);
if (!sb_set_blocksize(sb, blocksize)) {
- printk(KERN_ERR "EXT2-fs: blocksize too small for
device.\n");
+ printk(KERN_ERR "EXT2-fs: bad blocksize %d.\n",
blocksize);
goto failed_sbi;
}
Index: linux-2.6.23-rc3/fs/ext3/super.c
===
--- linux-2.6.23-rc3.orig/fs/ext3/super.c 2007-08-12 21:25:24.0
-0700
+++ linux-2.6.23-rc3/fs/ext3/super.c2007-08-29 15:22:29.0 -0700
@@ -1549,7 +1549,10 @@ static int ext3_fill_super (struct super
}
brelse (bh);
- sb_set_blocksize(sb, blocksize);
+ if (!sb_set_blocksize(sb, blocksize)) {
+ printk(KERN_ERR "EXT3-fs: bad blocksize %d.\n",
blocksize);
+ goto out_fail;
+ }
logic_sb_block = (sb_block * EXT3_MIN_BLOCK_SIZE) / blocksize;
offset = (sb_block * EXT3_MIN_BLOCK_SIZE) % blocksize;
bh = sb_bread(sb, logic_sb_block);
Index: linux-2.6.23-rc3/fs/ext4/super.c
===
--- linux-2.6.23-rc3.orig/fs/ext4/super.c 2007-08-28 11:09:40.0
-0700
+++ linux-2.6.23-rc3/fs/ext4/super.c2007-08-29 15:24:08.0 -0700
@@ -1626,6 +1626,11 @@ static int ext4_fill_super (struct super
goto out_fail;
}
+ if (!sb_set_blocksize(sb, blocksize)) {
+ printk(KERN_ERR "EXT4-fs: bad blocksize %d.\n", blocksize);
+ goto out_fail;
+ }
+
/*
* The ext4 superblock will not be buffer aligned for other than 1kB
* block sizes. We need to calculate the offset from buffer start.
Index: linux-2.6.23-rc3/include/linux/ext2_fs.h
===
--- linux-2.6.23-rc3.orig/include/linux/ext2_fs.h 2007-08-12
21:25:24.0 -0700
+++ linux-2.6.23-rc3/include/linux/ext2_fs.h2007-08-29 15:22:29.0
-0700
@@ -86,8 +86,8 @@ static inline struct ext2_sb_info *EXT2_
* Macro-instructions used to manage several block sizes
*/
#define EXT2_MIN_BLOCK_SIZE1024
-#defineEXT2_MAX_BLOCK_SIZE 4096
-#define EXT2_MIN_BLOCK_LOG_SIZE 10
+#define EXT2_MAX_BLOCK_SIZE65536
+#define EXT2_MIN_BLOCK_LOG_SIZE10
#ifdef __KERNEL__
# define EXT2_BLOCK_SIZE(s)((s)->s_blocksize)
#else
Index: linux-2.6.23-rc3/include/linux/ext3_fs.h
===
--- linux-2.6.23-rc3.orig/include/linux/ext3_fs.h 2007-08-12
21:25:24.0 -0700
+++ linux-2.6.23-rc3/include/linux/ext3_fs.h2007-08-29 15:22:29.0
Re: [PATCH] avoid negative (and full-width) shifts in radix-tree.c, take 3
On 2007.08.29 10:49:12 -0700, Christoph Lameter wrote: > On Wed, 29 Aug 2007, Peter Lund wrote: > > > > > - if (tmp >= RADIX_TREE_INDEX_BITS) > > - index = ~0UL; > > - return index; > > + if (shift < 0) > > + return ~0UL; > > + if (shift >= 8 * sizeof(unsigned long)) > > 8* sizeof(unsigned long) is the constant BITS_PER_LONG. Or in this context: RADIX_TREE_INDEX_BITS, which happens to be the old check, which just needed to be extended to cover negative shifts. Björn - 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: [1/4] 2.6.23-rc4: known regressions
On Thu, 30 Aug 2007, Adrian Bunk wrote:
> Christoph, is your fix in -mm suitable for 2.6.23, or how else should
> this regression be fixed for 2.6.23?
Looks like this is just alpha and a certain particular compiler version?
You may get away with adding
void __kmalloc_size_too_large(void)
{
BUG();
}
somewhere if you use the particular compiler version causing trouble.
The compiler will then generate some useless code wasting processor
cycles due to not folding constants but it should(tm) work.
-
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: [Hdaps-devel] [PATCH 2.6.23-rc2] hwmon: HP Mobile Data Protection System 3D ACPI driver (resend)
On 8/29/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > On Wed, 29 Aug 2007, Yan Burman wrote: > HDAPS with input device support is quite new. hdapsd was patched to talk to > it, too. I suppose we should port the input device support to the driver > in-tree just so that we get it in tree as well. Sounds like an useful > reason to bother with in-tree hdaps. Not that it will save much power with > the in-tree driver, but at least it will be widely available from there. In case they'll be of help for such porting, the relevant hdaps patches from my tp_smapi patch series are attached. > > I agree that the sys interface is probably not the best choice, but the > > accelerometer data should provide not only position, but also generate > > an event when it detects > > that it's falling. From what I understood hdaps does not have that info, > > You can generate events on input devices, but I am not sure that's the best > way to go about it for this. Things that block on read until an interrupt > happens might work better. You can do the latter via another (4th) input device. > I'd suggest an accelerometer sysfs interface, that we implement in hdaps > (in and out-of-tree), ams and hpmdp. One input device for joystick > emulation (optional), one input device with accelerometer data in mg or ug, Is any of the accelerometer drivers currently capable of computing the physical acceleration? Also, is there an issue of linear vs. angular acceleration? > and an optional one with the raw accelerometer data. Before or after axis inversion/swapping? The tp_smapi hdaps driver (losslessly) inverts the raw data too, to avoid duplication of model-specific orientation logic. > unless someone wants to implement their own free-fall algorithms instead of > using whatever is in the firmware). The term "free-fall" is dangerously misleading, for the reasons explained in the IBM APS whitepaper. Shem hdaps: Add ID fields to the hdaps joystick-emulation input device Minor ABI break: the input dev name changes from "hdaps" to a more meaningful "ThinkPad HDAPS joystick emulation", following Documentation/input/input-programming.txt. The bus/vendor/product/version have been coordinated with the maintainer of thinkpad_acpi (the other user of this bus/vendor namespace). Signed-off-by: Shem Multinymous <[EMAIL PROTECTED]> --- drivers/hwmon/hdaps.c | 17 ++--- 1 files changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/hwmon/hdaps.c b/drivers/hwmon/hdaps.c index ad92c0a..423f348 100644 --- a/drivers/hwmon/hdaps.c +++ b/drivers/hwmon/hdaps.c @@ -35,6 +35,7 @@ #include #include #include +#include /* Embedded controller accelerometer read command and its result: */ static const struct thinkpad_ec_row ec_accel_args = @@ -62,9 +63,14 @@ static const struct thinkpad_ec_row ec_accel_args = #define HDAPS_INPUT_FLAT 4 #define KMACT_REMEMBER_PERIOD (HZ/10) /* keyboard/mouse persistance */ +/* Input IDs */ +#define HDAPS_INPUT_VENDOR PCI_VENDOR_ID_IBM +#define HDAPS_INPUT_PRODUCT 0x5054 /* "TP", shared with thinkpad_acpi */ +#define HDAPS_INPUT_JS_VERSION 0x6801 /* Joystick emulation input device */ + static struct timer_list hdaps_timer; static struct platform_device *pdev; -static struct input_dev *hdaps_idev; +static struct input_dev *hdaps_idev; /* joystick-like device with fuzz */ static unsigned int hdaps_invert; static int needs_calibration; @@ -744,8 +750,13 @@ static int __init hdaps_init(void) /* calibration for the input device (deferred to avoid delay) */ needs_calibration = 1; - /* initialize the input class */ - hdaps_idev->name = "hdaps"; + /* initialize the joystick-like fuzzed input device */ + hdaps_idev->name = "ThinkPad HDAPS joystick emulation"; + hdaps_idev->phys = "hdaps/input0"; + hdaps_idev->id.bustype = BUS_HOST; + hdaps_idev->id.vendor = HDAPS_INPUT_VENDOR; + hdaps_idev->id.product = HDAPS_INPUT_PRODUCT; + hdaps_idev->id.version = HDAPS_INPUT_JS_VERSION; hdaps_idev->dev.parent = >dev; hdaps_idev->evbit[0] = BIT(EV_ABS); input_set_abs_params(hdaps_idev, ABS_X, -- 1.5.2.4 hdaps: Add a 2nd input device for raw accelerometer data The current interface used for reading the HDAPS accelerometer requires userspace daemons to poll a sysfs attribute. This causes interrupts on tickless kernels, and introduces a phase difference between the userspace->kernel polling and kernel->hardware polling. To solve this, this patch introduces an input dev interface to the accelerometer data. It differs from the existing hdaps input dev in that it produces raw measurements, without fuzzing or calibration (but with axis reversal, this the model-specific knowledge is already encoded in the driver). Signed-off-by: Shem Multinymous <[EMAIL PROTECTED]> --- drivers/hwmon/Kconfig |7 --- drivers/hwmon/hdaps.c | 32 2 files changed, 36 insertions(+), 3 deletions(-) diff --git a/drivers/hwmon/Kconfig
2.6.23-rc4-dw1
I've updated to 2.6.23-rc4 .. This is an "Ingo appears to be busy.." release .. I've been waiting for a -rt update , but there hasn't been one for a while. So my tree is the best everyone will get for now. ftp://source.mvista.com/pub/dwalker/rt/patch-2.6.23-rc4-dw1 ftp://source.mvista.com/pub/dwalker/rt/patch-2.6.23-rc4-dw1.tar.bz2 The patches follow the release style of Ingo's tree, and his release notes also apply to my patch as well. I included a fresh git-acpi pull. I also included all the patches I've submitted to Ingo, and the following patches that got submitting to lkml and the linux-rt-users list, From: Steven Rostedt <[EMAIL PROTECTED]> Subject: [PATCH RT] fix non SMP compile smp stubs From: Sven-Thorsten Dietrich <[EMAIL PROTECTED]> Subject: [PATCH RT] - Mellanox IB driver patch From: Steven Rostedt <[EMAIL PROTECTED]> Subject: [PATCH RT] Add missing semicolon in percpu_list.h From: "Paul E. McKenney" <[EMAIL PROTECTED]> Subject: [PATCH RFC -rt] synchronize_sched() without migration From: "Paul E. McKenney" <[EMAIL PROTECTED]> Subject: [PATCH RFC -rt] Allow rcutorture to handle synchronize_sched() From: Steven Rostedt <[EMAIL PROTECTED]> Subject: [PATCH RT] Only run softirqs from the irq thread if the irq From: Steven Rostedt <[EMAIL PROTECTED]> Subject: [PATCH RT 2/3] initialize the clock source to jiffies clock. Enjoy, 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: [31/36] Large Blocksize: Core piece
On Wed, 29 Aug 2007, Mingming Cao wrote: > > Known internal limitations: > > > > Ext264k > > XFS 64k > > Reiserfs8k > > Ext34k (rumor has it that changing a constant can remove the > > limit) > > Ext44k > > > > There are patches original worked by Takashi Sato to support large block > size (up to 64k) in ext2/3/4, which addressed the directory issue as > well. I just forward ported. Will posted it in a separate thread. > Haven't get a chance to integrated with your patch yet (next step). Ahh. Great. Keep me posted. - 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: [1/4] 2.6.23-rc4: known regressions
On Thu, 30 Aug 2007, Adrian Bunk wrote:
> > CC init/version.o
> > LD init/built-in.o
> > LD .tmp_vmlinux1
> > arch/alpha/kernel/built-in.o(.text+0xaaa8): In function
> > `pdev_save_srm_config':
> > include/linux/slub_def.h:154: undefined reference to
> > `__kmalloc_size_too_large'
> > arch/alpha/kernel/built-in.o(.text+0xaaac):include/linux/slub_def.h:154:
> > undefined reference to `__kmalloc_size_too_large'
> > arch/alpha/kernel/built-in.o(.text+0xd0a8): In function
> > `module_frob_arch_sections':
> > include/linux/slub_def.h:154: undefined reference to
> > `__kmalloc_size_too_large'
> > arch/alpha/kernel/built-in.o(.text+0xd0ac):include/linux/slub_def.h:154:
> > undefined reference to `__kmalloc_size_too_large'
> > arch/alpha/kernel/built-in.o(.text+0x19388): In function
> > `srmcons_get_private_struct':
> > include/linux/slub_def.h:154: undefined reference to
> > `__kmalloc_size_too_large'
> > arch/alpha/kernel/built-in.o(.text+0x1938c):include/linux/slub_def.h:154:
> > more undefined references to `__kmalloc_size_too_large' follow
> > make[1]: *** [.tmp_vmlinux1] Error 1
> > make: *** [_all] Error 2
> >...
>
> Christoph, is your fix in -mm suitable for 2.6.23, or how else should
> this regression be fixed for 2.6.23?
Could you give me an asm dump via objdump of one of these functions?
I wonder what is going on there? Seeing the code generated may give us a
hint what is going on.
Likely an old compiler that has troubles performing constant folding .
One
solution would be to use a newer compiler?
And yes, the page allocator pass through patch in mm would fix this.
Or define CONFIG_BROKEN_CONSTANT_FOLDING for alpha and then use this
patch:
---
include/linux/slub_def.h |4
1 file changed, 4 insertions(+)
Index: linux-2.6/include/linux/slub_def.h
===
--- linux-2.6.orig/include/linux/slub_def.h 2007-08-29 17:03:48.0
-0700
+++ linux-2.6/include/linux/slub_def.h 2007-08-29 17:09:55.0 -0700
@@ -168,6 +168,7 @@ void *__kmalloc(size_t size, gfp_t flags
static inline void *kmalloc(size_t size, gfp_t flags)
{
+#ifndef CONFIG_BROKEN_CONSTANT_FOLDING
if (__builtin_constant_p(size) && !(flags & SLUB_DMA)) {
struct kmem_cache *s = kmalloc_slab(size);
@@ -176,6 +177,7 @@ static inline void *kmalloc(size_t size,
return kmem_cache_alloc(s, flags);
} else
+#endif
return __kmalloc(size, flags);
}
@@ -185,6 +187,7 @@ void *kmem_cache_alloc_node(struct kmem_
static inline void *kmalloc_node(size_t size, gfp_t flags, int node)
{
+#ifndef CONFIG_BROKEN_CONSTANT_FOLDING
if (__builtin_constant_p(size) && !(flags & SLUB_DMA)) {
struct kmem_cache *s = kmalloc_slab(size);
@@ -193,6 +196,7 @@ static inline void *kmalloc_node(size_t
return kmem_cache_alloc_node(s, flags, node);
} else
+#endif
return __kmalloc_node(size, flags, node);
}
#endif
-
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: [31/36] Large Blocksize: Core piece
On Tue, 2007-08-28 at 12:06 -0700, [EMAIL PROTECTED] wrote:
> plain text document attachment (0031-Large-Blocksize-Core-piece.patch)
> Provide an alternate definition for the page_cache_xxx(mapping, ...)
> functions that can determine the current page size from the mapping
> and generate the appropriate shifts, sizes and mask for the page cache
> operations. Change the basic functions that allocate pages for the
> page cache to be able to handle higher order allocations.
>
> Provide a new function
>
> mapping_setup(stdruct address_space *, gfp_t mask, int order)
>
> that allows the setup of a mapping of any compound page order.
>
> mapping_set_gfp_mask() is still provided but it sets mappings to order 0.
> Calls to mapping_set_gfp_mask() must be converted to mapping_setup() in
> order for the filesystem to be able to use larger pages. For some key block
> devices and filesystems the conversion is done here.
>
> mapping_setup() for higher order is only allowed if the mapping does not
> use DMA mappings or HIGHMEM since we do not support bouncing at the moment.
> Thus BUG() on DMA mappings and clear the highmem bit of higher order mappings.
>
> Modify the set_blocksize() function so that an arbitrary blocksize can be set.
> Blocksizes up to MAX_ORDER - 1 can be set. This is typically 8MB on many
> platforms (order 11). Typically file systems are not only limited by the core
> VM but also by the structure of their internal data structures. The core VM
> limitations fall away with this patch. The functionality provided here
> can do nothing about the internal limitations of filesystems.
>
> Known internal limitations:
>
> Ext264k
> XFS 64k
> Reiserfs8k
> Ext34k (rumor has it that changing a constant can remove the
> limit)
> Ext44k
>
There are patches original worked by Takashi Sato to support large block
size (up to 64k) in ext2/3/4, which addressed the directory issue as
well. I just forward ported. Will posted it in a separate thread.
Haven't get a chance to integrated with your patch yet (next step).
thanks,
Mingming
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
> ---
> block/Kconfig | 17 ++
> drivers/block/rd.c |6 ++-
> fs/block_dev.c | 29 +++---
> fs/buffer.c |4 +-
> fs/inode.c |7 ++-
> fs/xfs/linux-2.6/xfs_buf.c |3 +-
> include/linux/buffer_head.h | 12 -
> include/linux/fs.h |5 ++
> include/linux/pagemap.h | 121 --
> mm/filemap.c| 17 --
> 10 files changed, 192 insertions(+), 29 deletions(-)
>
> Index: linux-2.6/block/Kconfig
> ===
> --- linux-2.6.orig/block/Kconfig 2007-08-27 19:22:13.0 -0700
> +++ linux-2.6/block/Kconfig 2007-08-27 21:16:38.0 -0700
> @@ -62,6 +62,20 @@ config BLK_DEV_BSG
> protocols (e.g. Task Management Functions and SMP in Serial
> Attached SCSI).
>
> +#
> +# The functions to switch on larger pages in a filesystem will return an
> error
> +# if the gfp flags for a mapping require only DMA pages. Highmem will always
> +# be switched off for higher order mappings.
> +#
> +config LARGE_BLOCKSIZE
> + bool "Support blocksizes larger than page size"
> + default n
> + depends on EXPERIMENTAL
> + help
> + Allows the page cache to support higher orders of pages. Higher
> + order page cache pages may be useful to increase I/O performance
> + anbd support special devices like CD or DVDs and Flash.
> +
> endif # BLOCK
>
> source block/Kconfig.iosched
> Index: linux-2.6/drivers/block/rd.c
> ===
> --- linux-2.6.orig/drivers/block/rd.c 2007-08-27 20:59:27.0 -0700
> +++ linux-2.6/drivers/block/rd.c 2007-08-27 21:10:38.0 -0700
> @@ -121,7 +121,8 @@ static void make_page_uptodate(struct pa
> }
> } while ((bh = bh->b_this_page) != head);
> } else {
> - memset(page_address(page), 0,
> page_cache_size(page_mapping(page)));
> + memset(page_address(page), 0,
> + page_cache_size(page_mapping(page)));
> }
> flush_dcache_page(page);
> SetPageUptodate(page);
> @@ -380,7 +381,8 @@ static int rd_open(struct inode *inode,
> gfp_mask = mapping_gfp_mask(mapping);
> gfp_mask &= ~(__GFP_FS|__GFP_IO);
> gfp_mask |= __GFP_HIGH;
> - mapping_set_gfp_mask(mapping, gfp_mask);
> + mapping_setup(mapping, gfp_mask,
> + page_cache_blkbits_to_order(inode->i_blkbits));
> }
>
> return 0;
> Index: linux-2.6/fs/block_dev.c
> ===
> --- linux-2.6.orig/fs/block_dev.c 2007-08-27
Re: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pete/Piet Delaney wrote: > Jason Wessel wrote: >> Andrew Morton wrote: >>> On Wed, 22 Aug 2007 17:44:12 -0500 >>> Jason Wessel <[EMAIL PROTECTED]> wrote: >>> >>> +while (!atomic_read(_active)); >>> eek. We're in the process of hunting down and eliminating exactly this >>> construct. There have been cases where the compiler cached the >>> atomic_read() result in a register, turning the above into an infinite >>> loop. >>> >>> Plus we should never add power-burners like that into the kernel >>> anyway. That loop should have a cpu_relax() in it. Which will also >>> fix the >>> compiler problem described above. >>> >>> >> Agreed, and fixed with a cpu_relax. > >>> Thirdly, please always add a newline when coding statements like that: >>> >>> while (expr()) >>> ; >>> >> The other instances I found of the same problem in the kgdb core are >> fixed too. > >> I merged all the changes into the for_mm branch in the kgdb git tree. > > Where is the kgdb git tree? Trying: git clone http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git - -piet > > -piet > >> Thanks, >> Jason. >> - >> 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/ > > - - 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/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1gnFJICwm/rv3hoRApOoAJ9BHXLsIuxDiOCaAFRfAZGwrDXATQCeLL3O bxtr3qz0soPRghPmtSZgOqc= =kQd1 -END PGP SIGNATURE- - 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: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Wessel wrote: > Andrew Morton wrote: >> On Wed, 22 Aug 2007 17:44:12 -0500 >> Jason Wessel <[EMAIL PROTECTED]> wrote: >> >> >>> +while (!atomic_read(_active)); >>> >> >> eek. We're in the process of hunting down and eliminating exactly this >> construct. There have been cases where the compiler cached the >> atomic_read() result in a register, turning the above into an infinite >> loop. >> >> Plus we should never add power-burners like that into the kernel >> anyway. That loop should have a cpu_relax() in it. Which will also >> fix the >> compiler problem described above. >> >> > Agreed, and fixed with a cpu_relax. > >> Thirdly, please always add a newline when coding statements like that: >> >> while (expr()) >> ; >> > > The other instances I found of the same problem in the kgdb core are > fixed too. > > I merged all the changes into the for_mm branch in the kgdb git tree. Where is the kgdb git tree? - -piet > > Thanks, > Jason. > - > 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/ > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1gS/JICwm/rv3hoRAhfRAJ42F3QlzGwG4aQbs9hHVMI4kJ9SWQCfXrku UGo97ByKsB9yhyIu5c+2Jh0= =welB -END PGP SIGNATURE- - 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: Who wants to maintain KR list for stable releases? (was Re: nmi_watchdog=2 regression in 2.6.21)
> Bugzilla is for tracking bugs, not for discussing possible
> kernel features.
True, but some of them are categorized as bugs from the reporter's
prospective, when they say "man page says" or "according to POSIX it's
wrong". I am going to push ones that are feature suggestions,
re-design suggestions, and some way implementation related out to the
site that Rick is going to help to maintain, which is more of
suggested projects list.
>
> Tracking feature or implementation suggestions wouldn't make sense.
> Consider e.g. that there are several people on linux-kernel who often
> write what they think the kernel should do but who never write a single
> line of code themselves. There's no value in tracking such stuff.
Yes, but some suggestions seem to make sense. How about evaluating it?
and if they are real making it a possible project for someone who
would do appropriate research, etc. And we move them from bugzilla
where they don't belong to a development arena.
> > improved searches - for sure, for example in addition to
> > pre-cooked queries make possible using "raw" queries directly on sql,
> > which will address misplaced bugs and will make categories more
> > dynamic;
>
> What do you have in mind?
I am going to look into the bugzilla software to start with, and see
if there is a way to expand it this way. we used to have such internal
tracking (unix based) at work, where we could compose pretty much
freelance queries, it is really not big deal for developers who script
and write huge regular expressions for their convenience every
day...just a vogue idea for now, trying to think how to minimize bugs
that get lost because of wrong bucket. Going manually through all of
them is not very effective.
> I've always been able to do any search I wanted using the "Advanced Search"
> of Bugzilla. Well, just checking, it seems the search for the new
> "regression" flag could be made easier, but that's not a general problem.
>
Yes but you have to assume that everything is in the right place from
start, besides putting things into categories is often impossible
before some exchange with reporter and initial diagnostics. The worst
category so fas as I found is "other" (in every place where it
exists). Most of the "other" bugs haven't been touched, and some have
huge "SATA" letters in the description written in them :)
> But what could be improved in the database would be to fix the
> charset problems for getting the RSS feeds working (#8774). ;-)
I agree :)
> Documentation makes sense, but it belongs into some place like the
> kernelnewbies wiki, not the Bugzilla itself.
Right, so there should be convenient links to such. I know people like
Mauro maintains his own set of templates and he was the one to suggest
it, but later I found out myself that looking for serial console or
bisect instructions every time is cumbersome... I can't imagine
making every maintainer to have to have his own, maybe some hate bug
stuff for this ("oh, not that again...")
> Preferences settings plus saved searches already work.
>
> What is missing?
I guess existing one is certainly good in many ways - just not good
enough for people to love it ;) Frankly, I see so many other bugzillas
that have better look and feel but there is no way we can change it
overnight...improving things according to feedback from maintainers
(after all the whole purpose is to give them what they need, even in
case if they don't need bugzilla at all! then it should be best
possible interface for bug maintainers ;), maybe try 3.0+ first and
see how much better we get...
> There's a "Home" link that does exactly this among the actions offered
> at the bottom of all pages.
Yea you can find many hidden buttons that you have to scroll down to
:) A little more ergonomics wouldn't hurt though..
> Bugzilla isn't that bad and it has the advantage of being the most
> popular bug tracking system for open source projects, which means that
> most likely every kernel developer and many submitters have already used
> a Bugzilla at some other project.
>
> From past discussions my impression was that several kernel developers
> have an email based workflow and are reluctant to integrate web based
> actions into their workflow.
Yes, and we should cater to them as well. I am totally agree with you
that tracking and fixing real bugs is the real goal, and interface is
only important as long as it serves the purpose, and not being a
culprit. We'll see how it will be evolving. (and I am evolving here
too - trying to find what's missing and how to make things work :)
> I'd say the success of any bigger Bugzilla change or switch to a
> different or writing of a new bug tracking system could be measured
> by answering the following question:
> Will Linus Torvalds and David Miller use it?
Heh, yes. This should be something really awesome don't you think :)
--Natalie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Re: 4KSTACKS + DEBUG_STACKOVERFLOW harmful
On Aug 29, 2007, at 19:01:57, Eric Sandeen wrote: Jesper Juhl wrote: A first step could be to allocate those two char arrays with kmalloc() instead of on the stack, but then I guess that dump_stack () gets called from places where we may not really want to be calling kmalloc(). I guess we could allocate the buffers earlier (like at boot time) and store pointers somewhere where dump stack can get to them later when it needs them. Yep, I thought about something like that... and I assume you'd need a bit of locking around them too. How about turning off preemption and using a per-CPU buffer? Alternatively you could turn off IRQs, poke a per-CPU value to clue in any incoming NMIs, and switch to a separate stack. I suppose if you wanted it to work with all of 16 bytes of stack left on both thread and IRQ stacks, you could have separate per-CPU NMI stacks; the stack-dump would be poking a special per-CPU value and sending ourselves an NMI. There are probably a half dozen other variants on ways to run screaming to the CPU saying "It hurts mommy!" and get a new stack in which we can play for a while. Cheers, Kyle Moffett - 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: [1/4] 2.6.23-rc4: known regressions
On Wed, Aug 29, 2007 at 08:04:52PM +0200, Jan Dittmer wrote: > Michal Piotrowski wrote: > > Subject : 2.6.23-rc2 cross compile regressions (alpha,xtensa) > > References : http://lkml.org/lkml/2007/8/6/43 > > Last known good : alpha: 2.6.22-git8 xtensa: 2.6.22-git6 > > Submitter : Jan Dittmer <[EMAIL PROTECTED]> > > Caused-By : ? > > Handled-By : xtensa: Christian Zankel <[EMAIL PROTECTED]> > > Status : unknown > > Status: Unfixed > > alpha: http://l4x.org/k/?d=33700 > CC init/version.o > LD init/built-in.o > LD .tmp_vmlinux1 > arch/alpha/kernel/built-in.o(.text+0xaaa8): In function > `pdev_save_srm_config': > include/linux/slub_def.h:154: undefined reference to > `__kmalloc_size_too_large' > arch/alpha/kernel/built-in.o(.text+0xaaac):include/linux/slub_def.h:154: > undefined reference to `__kmalloc_size_too_large' > arch/alpha/kernel/built-in.o(.text+0xd0a8): In function > `module_frob_arch_sections': > include/linux/slub_def.h:154: undefined reference to > `__kmalloc_size_too_large' > arch/alpha/kernel/built-in.o(.text+0xd0ac):include/linux/slub_def.h:154: > undefined reference to `__kmalloc_size_too_large' > arch/alpha/kernel/built-in.o(.text+0x19388): In function > `srmcons_get_private_struct': > include/linux/slub_def.h:154: undefined reference to > `__kmalloc_size_too_large' > arch/alpha/kernel/built-in.o(.text+0x1938c):include/linux/slub_def.h:154: > more undefined references to `__kmalloc_size_too_large' follow > make[1]: *** [.tmp_vmlinux1] Error 1 > make: *** [_all] Error 2 >... Christoph, is your fix in -mm suitable for 2.6.23, or how else should this regression be fixed for 2.6.23? > Jan cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [stable] [patch 25/28] USB: cdc-acm: fix sysfs attribute registration bug
On 08/24/2007 02:04 PM, Greg KH wrote: >> I don't understand. The history for stable/linux-2.6.22.y.git at >> http://git.kernel.org shows that the commit for my patch, labelled >> >> 6b30a4e1c357410a78d7bcb831743b0e99bab4ad, >> >> includes both hunks. And patch-2.6.22.5.bz2 includes both as well. >> Something's fishy. > *sigh* The stable-queue tree does not match what got released for 2.6.22.5. $ pwd /home/me/git/stable-queue $ grep cdc releases/2.6.22.5/* $ $ bzcat patch-2.6.22.5.bz2 | grep cdc index acdc3be..e2b9ca4 100644 diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c - 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: [Hdaps-devel] [PATCH 2.6.23-rc2] hwmon: HP Mobile Data Protection System 3D ACPI driver (resend)
On Wed, 29 Aug 2007, Yan Burman wrote: > I don't mind doing it this way, it's just that from what I saw all > current applications use the sys interface, so I figured that people > would like to be able to use those. Well, they will have to fix their applications to use the input device, if the other drivers do all of us a big favour and NOT implement that hideous crap HDAPS unforunately started with. That said, if you decide to implement it, we can also live with that. It just takes one warning on the driver to the likes of "warning: application with pid foo is using an outdated, power-wasting interface, please port it to the accelerometer input device" to syslog anytime you notice someone is trying to read it often enough. HDAPS with input device support is quite new. hdapsd was patched to talk to it, too. I suppose we should port the input device support to the driver in-tree just so that we get it in tree as well. Sounds like an useful reason to bother with in-tree hdaps. Not that it will save much power with the in-tree driver, but at least it will be widely available from there. > Debian/Ubuntu also have some stuff for hdaps in their repositories. So > it seems to me that people are using the sys interface. They didn't have a choice until a few weeks ago... not for HDAPS, at least. > > driver gets the dibs on how to implement those interfaces in a proper > > generic way. Want to be the one? Please? We in hdaps-devel can certainly > > help with ideas and fix out-of-tree hdaps to also implement the interface. > > > I agree that the sys interface is probably not the best choice, but the > accelerometer data should provide not only position, but also generate > an event when it detects > that it's falling. From what I understood hdaps does not have that info, You can generate events on input devices, but I am not sure that's the best way to go about it for this. Things that block on read until an interrupt happens might work better. And there is also netlink sockets, and other ways to send events to user space. I don't know which way would be best, this is something to ask in LKML. I'd suggest an accelerometer sysfs interface, that we implement in hdaps (in and out-of-tree), ams and hpmdp. One input device for joystick emulation (optional), one input device with accelerometer data in mg or ug, and an optional one with the raw accelerometer data. Also, an optional way to send events notifying of free-fall to userspace *and* to other kernel drivers (so that you can actually hook it to the queue-freeze engine in-kernel, I fail to see why ams and hpmdp should need userspace at all, unless someone wants to implement their own free-fall algorithms instead of using whatever is in the firmware). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - 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.23 patch] xtensa process.c must #include
On Wed, Aug 29, 2007 at 08:04:52PM +0200, Jan Dittmer wrote: > Michal Piotrowski wrote: > > Subject : 2.6.23-rc2 cross compile regressions (alpha,xtensa) > > References : http://lkml.org/lkml/2007/8/6/43 > > Last known good : alpha: 2.6.22-git8 xtensa: 2.6.22-git6 > > Submitter : Jan Dittmer <[EMAIL PROTECTED]> > > Caused-By : ? > > Handled-By : xtensa: Christian Zankel <[EMAIL PROTECTED]> > > Status : unknown > > Status: Unfixed >... > xtensa: http://l4x.org/k/?d=33728 > CC arch/xtensa/kernel/process.o > arch/xtensa/kernel/process.c:50: error: `INR_OPEN' undeclared here (not in a > function) > arch/xtensa/kernel/process.c:50: error: initializer element is not constant > arch/xtensa/kernel/process.c:50: error: (near initialization for > `init_signals.rlim[7].rlim_cur') >... Patch below. > Jan cu Adrian <-- snip --> Another fallout from the removal of #include from mm.h Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- 6a0031b0f3f40238fc604bba264981776a155dbf diff --git a/arch/xtensa/kernel/process.c b/arch/xtensa/kernel/process.c index ce758ba..dd498f1 100644 --- a/arch/xtensa/kernel/process.c +++ b/arch/xtensa/kernel/process.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include - 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 patch] update .gitignore
Some shipped files were wrongly ignored by git. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- .gitignore |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) 45a1318453ecc5fa346d323e8d806a5630a7191c diff --git a/.gitignore b/.gitignore index 27c3e83..80d891b 100644 --- a/.gitignore +++ b/.gitignore @@ -17,15 +17,21 @@ *.lst *.symtypes +# .gitignore files +!.gitignore + # # Top-level generic files # tags TAGS vmlinux* -!vmlinux.lds.S +!vmlinux*.lds* +!vmlinux*.scr System.map Module.symvers +!.mailmap +!.mm # # Generated include files - 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 patch] rename .i assembler includes to .h
On Mon, Aug 20, 2007 at 02:16:46AM +0200, Andi Kleen wrote: > On Mon, Aug 20, 2007 at 01:01:36AM +0200, Adrian Bunk wrote: > > On Wed, Aug 01, 2007 at 09:10:37PM +0200, Adrian Bunk wrote: > > > On Wed, Aug 01, 2007 at 11:07:53PM +0400, Alexey Dobriyan wrote: > > > > On Wed, Aug 01, 2007 at 03:10:51PM +0200, Adrian Bunk wrote: > > > > > --- linux-2.6.23-rc1-mm2/.gitignore.old > > > > > +++ linux-2.6.23-rc1-mm2/.gitignore > > > > > @@ -14,18 +14,25 @@ > > > > > *.so > > > > > *.mod.c > > > > > *.i > > > > > +!include/asm-*/*.i > > > > > > > > I think these should be renamed to .S and let .i alone for preprocessed > > > > stuff. > > > >... > > > > > > Fine with me if Andi agrees. > > > > Andi? > > Hmm, perhaps rename alternative-asm.i to .h and stick a #ifdef __ASSEMBLY__ > around it. Patch below. > There is actually only one includer currently, but there might > be more in the future again. > > -Andi cu Adrian <-- snip --> .i is an ending used for preprocessed stuff. This patch therefore renames assembler include files to .h and guards the contents with an #ifdef __ASSEMBLY__. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- arch/i386/lib/semaphore.S|4 ++-- arch/x86_64/lib/rwlock.S |2 +- include/asm-i386/alternative-asm.h | 16 include/asm-i386/alternative-asm.i | 12 include/asm-i386/frame.h | 27 +++ include/asm-i386/frame.i | 23 --- include/asm-um/alternative-asm.h |6 ++ include/asm-um/alternative-asm.i |6 -- include/asm-um/frame.h |6 ++ include/asm-um/frame.i |6 -- include/asm-x86_64/alternative-asm.h | 16 include/asm-x86_64/alternative-asm.i | 12 12 files changed, 74 insertions(+), 62 deletions(-) 7b64536780b39820b13bebd144983c3c8c9ae64c diff --git a/arch/i386/lib/semaphore.S b/arch/i386/lib/semaphore.S index c01eb39..444fba4 100644 --- a/arch/i386/lib/semaphore.S +++ b/arch/i386/lib/semaphore.S @@ -15,8 +15,8 @@ #include #include -#include -#include +#include +#include #include /* diff --git a/arch/x86_64/lib/rwlock.S b/arch/x86_64/lib/rwlock.S index 0cde1f8..05ea55f 100644 --- a/arch/x86_64/lib/rwlock.S +++ b/arch/x86_64/lib/rwlock.S @@ -2,7 +2,7 @@ #include #include -#include +#include #include /* rdi:pointer to rwlock_t */ diff --git a/include/asm-i386/alternative-asm.h b/include/asm-i386/alternative-asm.h new file mode 100644 index 000..c478a03 --- /dev/null +++ b/include/asm-i386/alternative-asm.h @@ -0,0 +1,16 @@ +#ifdef __ASSEMBLY__ + +#ifdef CONFIG_SMP + .macro LOCK_PREFIX +1: lock + .section .smp_locks,"a" + .align 4 + .long 1b + .previous + .endm +#else + .macro LOCK_PREFIX + .endm +#endif + +#endif /* __ASSEMBLY__ */ diff --git a/include/asm-i386/alternative-asm.i b/include/asm-i386/alternative-asm.i deleted file mode 100644 index f051020..000 --- a/include/asm-i386/alternative-asm.i +++ /dev/null @@ -1,12 +0,0 @@ -#ifdef CONFIG_SMP - .macro LOCK_PREFIX -1: lock - .section .smp_locks,"a" - .align 4 - .long 1b - .previous - .endm -#else - .macro LOCK_PREFIX - .endm -#endif diff --git a/include/asm-i386/frame.h b/include/asm-i386/frame.h new file mode 100644 index 000..06850a7 --- /dev/null +++ b/include/asm-i386/frame.h @@ -0,0 +1,27 @@ +#ifdef __ASSEMBLY__ + +#include + +/* The annotation hides the frame from the unwinder and makes it look + like a ordinary ebp save/restore. This avoids some special cases for + frame pointer later */ +#ifdef CONFIG_FRAME_POINTER + .macro FRAME + pushl %ebp + CFI_ADJUST_CFA_OFFSET 4 + CFI_REL_OFFSET ebp,0 + movl %esp,%ebp + .endm + .macro ENDFRAME + popl %ebp + CFI_ADJUST_CFA_OFFSET -4 + CFI_RESTORE ebp + .endm +#else + .macro FRAME + .endm + .macro ENDFRAME + .endm +#endif + +#endif /* __ASSEMBLY__ */ diff --git a/include/asm-i386/frame.i b/include/asm-i386/frame.i deleted file mode 100644 index 0362025..000 --- a/include/asm-i386/frame.i +++ /dev/null @@ -1,23 +0,0 @@ -#include - -/* The annotation hides the frame from the unwinder and makes it look - like a ordinary ebp save/restore. This avoids some special cases for - frame pointer later */ -#ifdef CONFIG_FRAME_POINTER - .macro FRAME - pushl %ebp - CFI_ADJUST_CFA_OFFSET 4 - CFI_REL_OFFSET ebp,0 - movl %esp,%ebp - .endm - .macro ENDFRAME - popl %ebp - CFI_ADJUST_CFA_OFFSET -4 - CFI_RESTORE ebp - .endm -#else - .macro FRAME - .endm - .macro ENDFRAME - .endm -#endif diff --git a/include/asm-um/alternative-asm.h b/include/asm-um/alternative-asm.h new file mode 100644 index
Re: [Bugme-new] [Bug 8957] New: Exported functions and variables should not be reachable by the outside of the module until module_init finishes
On Wed, 29 Aug 2007 11:33:06 -0700 (PDT) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8957 > >Summary: Exported functions and variables should not be reachable > by the outside of the module until module_init finishes >Product: Other >Version: 2.5 > KernelVersion: 2.6.23-rc4 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Modules > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Problem Description: a module's exported functions can be called before before > they are properly initialized by the module_init function. > > Steps to reproduce: write a module that exports functions that require > initialization by the module_init function to work correctly. > > E.g. spin lock variables are no longer allowed to be initialized by C > initializers of the module but only by spin_lock_init that can be called by > the > module_init function. If an exported function calls spin_lock before it is > initialized, it deadlocks. > ooh, nice bug ;) - 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.23-rc4: BAD regression
Il Wed, Aug 29, 2007 at 01:29:56AM +0200, Daniel Ritz ha scritto: > tried that one on my old toshiba tecra 8000 laptop, almost killing it. > the fan doesn't work any more...type 'make' and see the box dying. > luckily my CPU doesn't commit suicide...bisected it to that one: > > cd8c93a4e04dce8f00d1ef3a476aac8bd65ae40b is first bad commit I've just bisected down to the same commit. In my case the fan is locked at maximum speed and the system is *extremly* slow (some kind of throttling?). Alexey, I've seen the patch, I'll test it tomorrow and report back. Luca -- Tentare e` il primo passo verso il fallimento. Homer J. Simpson - 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.23-rc3-mm1 - vdso and gettimeofday issues with glibc
On Wed, 29 Aug 2007 13:37:38 -0400 [EMAIL PROTECTED] wrote: > On Wed, 29 Aug 2007 10:04:33 EDT, [EMAIL PROTECTED] said: > > (Fixing the Subject: and updating the info) > > > On Wed, 22 Aug 2007 02:06:48 PDT, Andrew Morton said: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/ > > > The issue: vdso and gettimeofday seem to be having a quarrel. > > This is also open as a Fedora bug: > https://bugzilla.redhat.com/show_bug.cgi?id=262481 > So it's an interaction between the x86_64 vdso patches in Andi's tree and newer glibc, and we don't know which one is getting it wrong yet? If I ever get another -mm out the door (have been without electricity for several days) I'll drop the vdso changes until this is sorted out. - 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] ppc32/8xx: Fix r3 trashing due to 8MB TLB page instantiation
On Aug 28, 2007, at 6:20 AM, Jochen Friedrich wrote: Instantiation of 8MB pages on the TLB cache for the kernel static mapping trashes r3 register on !CONFIG_8xx_CPU6 configurations. This ensures r3 gets saved and restored. This has been posted to linuxppc-embedded by Marcelo Tosatti <[EMAIL PROTECTED]>, but only an incomplete version of the patch has been applied in c51e078f82096a7d35ac8ec2416272e843a0e1c4. This patch adds the rest of the fix. Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]> --- arch/ppc/kernel/head_8xx.S |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) This can be pulled from git://git.bocc.de/dbox2.git ppc-fixes diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S index 944c35c..eb8d26f 100644 --- a/arch/ppc/kernel/head_8xx.S +++ b/arch/ppc/kernel/head_8xx.S @@ -495,9 +495,7 @@ LoadLargeDTLB: lwz r11, 4(r0) lwz r12, 16(r0) -#ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) -#endif rfi /* This is the data TLB error on the MPC8xx. This could be due to do we need this in arch/powerpc as well? - k - 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: 4KSTACKS + DEBUG_STACKOVERFLOW harmful
Jesper Juhl wrote: >> Any suggestions for ways around this? The warning is somewhat helpful, >> and I guess the obvious option is to lighten up the dump_stack path, but >> it's still effectively reducing precious available stack space by some >> amount. >> > A first step could be to allocate those two char arrays with kmalloc() > instead of on the stack, but then I guess that dump_stack() gets > called from places where we may not really want to be calling > kmalloc(). I guess we could allocate the buffers earlier (like at boot > time) and store pointers somewhere where dump stack can get to them > later when it needs them. Yep, I thought about something like that... and I assume you'd need a bit of locking around them too. >> With CONFIG_DEBUG_STACK_USAGE, we could print at oops time: "oh, and by >> the way, you blew your stack" if there is no zeroed stack space left, as >> a post-mortem. Even without that option, I think we could still check >> whether the *current* %esp at oops time has gone too far? But if we >> blew the stack, returned, and *then* oops, I think it'd be hard to know >> without the DEBUG_STACK_USAGE option that we ran out of room. >> > > We could also simply have it warn at a higher limit, like 1024 bytes > instead of 512. But I guess then we would get too many false positives > and make it less useful. Yes, but if you happen to warn deeper anyway, just because you got "lucky" with IRQ timing, you'll still explode. Regardless of where the threshold is, there's still a risk of starting the warning deeper than that. Whatever stack the warning takes effectively reduces the useable stack size. -Eric - 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: [Tech-board-discuss] Re: [Ksummit-2007-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Wed, 29 Aug 2007 05:55:16 -0600 Matthew Wilcox <[EMAIL PROTECTED]> wrote: > On a serious note, James, I think you mis-spoke when you said that > Andrew Morton's term was up this year. In that case I hereby quit ;) My contribution to the TAB has been practically zero and I don't expect that to change. - 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: 4KSTACKS + DEBUG_STACKOVERFLOW harmful
On 30/08/2007, Eric Sandeen <[EMAIL PROTECTED]> wrote: > Noticed today that the combination of 4KSTACKS and DEBUG_STACKOVERFLOW > config options is a bit deadly. > > DEBUG_STACKOVERFLOW warns in do_IRQ if we're within THREAD_SIZE/8 of the > end of useable stack space, or 512 bytes on a 4k stack. > > If we are, then it goes down the dump_stack path, which uses most, if > not all, of the remaining stack, thereby turning a well-intentioned > warning into a full-blown catastrophe. > ... > > 448 bytes to tell us that we're within 512 bytes (or less) of certain > doom... and I think there's call overhead on top of that? > > The large stack usage in those 2 functions is due to big char arrays, of > size KSYM_NAME_LEN (128 bytes) and KSYM_SYMBOL_LEN (223 bytes). > > IOW, the stack warning effectively reduces useful stack left in our itty > bitty 4k stacks by over 10%. > > Any suggestions for ways around this? The warning is somewhat helpful, > and I guess the obvious option is to lighten up the dump_stack path, but > it's still effectively reducing precious available stack space by some > amount. > A first step could be to allocate those two char arrays with kmalloc() instead of on the stack, but then I guess that dump_stack() gets called from places where we may not really want to be calling kmalloc(). I guess we could allocate the buffers earlier (like at boot time) and store pointers somewhere where dump stack can get to them later when it needs them. > With CONFIG_DEBUG_STACK_USAGE, we could print at oops time: "oh, and by > the way, you blew your stack" if there is no zeroed stack space left, as > a post-mortem. Even without that option, I think we could still check > whether the *current* %esp at oops time has gone too far? But if we > blew the stack, returned, and *then* oops, I think it'd be hard to know > without the DEBUG_STACK_USAGE option that we ran out of room. > We could also simply have it warn at a higher limit, like 1024 bytes instead of 512. But I guess then we would get too many false positives and make it less useful. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fbdev: find mode with the highest/safest refresh rate in fb_find_mode()
Currently, if the refresh rate is not specified, fb_find_mode() returns
the first known video mode with the requested resolution, which provides
no guarantees wrt the refresh rate. Change this so that the mode with
the highest refresh rate is returned when the driver provides a custom
video mode database and the monitor limits, and a mode with the safe
60 Hz refresh rate otherwise.
Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 3741ad7..9598c46 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -606,26 +606,43 @@ done:
DPRINTK("Trying specified video mode%s %ix%i\n",
refresh_specified ? "" : " (ignoring refresh rate)", xres, yres);
- diff = refresh;
+ if (!refresh_specified) {
+ /*
+* If the caller has provided a custom mode database and a
+* valid monspecs structure, we look for the mode with the
+* highest refresh rate. Otherwise we play it safe it and
+* try to find a mode with a refresh rate closest to the
+* standard 60 Hz.
+*/
+ if (db != modedb &&
+ info->monspecs.vfmin && info->monspecs.vfmax &&
+ info->monspecs.hfmin && info->monspecs.hfmax &&
+ info->monspecs.dclkmax) {
+ refresh = 1000;
+ } else {
+ refresh = 60;
+ }
+ }
+
+ diff = -1;
best = -1;
for (i = 0; i < dbsize; i++) {
- if (name_matches(db[i], name, namelen) ||
- (res_specified && res_matches(db[i], xres, yres))) {
- if(!fb_try_mode(var, info, [i], bpp)) {
- if(!refresh_specified || db[i].refresh ==
refresh)
- return 1;
- else {
- if(diff > abs(db[i].refresh - refresh))
{
- diff = abs(db[i].refresh -
refresh);
- best = i;
- }
+ if ((name_matches(db[i], name, namelen) ||
+ (res_specified && res_matches(db[i], xres, yres))) &&
+ !fb_try_mode(var, info, [i], bpp)) {
+ if (refresh_specified && db[i].refresh == refresh) {
+ return 1;
+ } else {
+ if (abs(db[i].refresh - refresh) < diff) {
+ diff = abs(db[i].refresh - refresh);
+ best = i;
}
}
}
}
if (best != -1) {
fb_try_mode(var, info, [best], bpp);
- return 2;
+ return (refresh_specified) ? 2 : 1;
}
diff = xres + yres;
-
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] sysctl: Deprecate sys_sysctl in a user space visible fashion.
On Wed, 29 Aug 2007 11:46:04 +0100 Alan Cox <[EMAIL PROTECTED]> wrote: > > >> adequate job of warning our users. A printk when we run a program > > >> that uses the binary interface and an long enough interval the warning > > >> makes it to the Enterprise kernels before we remove the interface > > >> should be sufficient. > > The enterprise products will probably just remove the printk. Even if > they didn't you are looking at ten years before things finish changing > based on current experiences, probably longer as things stabilize. If that happens then the enterprise vendors will tell us (won't they). We can then discuss it and we may well elect to do something different. But Eric is predicting that this probably _won't_ happen. There's only one way to find out. > The whole "whine a bit" process simply doesn't work when you are trying > to persuade people to move in a non-hobbyist context. Eric thinks there will be little if any moving to be done. > They don't want to > move, the message is simply an annoyance, their upstream huge package > vendor won't change just to deal with it and they'll class it as a > regression from previous releases, an incompatibility and file bugs until > it goes away. > > Its user ABI and as Linus said - we don't break it. Trimming down all the > crap that never worked via sysctl is one thing, not putting sysctl in new > platforms likewise. Trying to undo it isn't going to work > We don't know that yet. You may be right, or maybe Eric is right. Let's find out. - 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: regression of autofs for current git?
On Wed, Aug 29, 2007 at 01:58:58PM -0700, Hua Zhong wrote:
> Hi,
Hi Hua,
> I am wondering if this is a known issue, but I just built the current git
> and several autofs mounts mysteriously disappeared. Restarting autofs could
> fix some, but then lose others. 2.6.22 was fine.
>
> Is there anything I could check other than bisect? (It may take some time
> for me to get to it)
the commit below is the only autofs4 patch that went into the git tree
since 2.6.22.
Does reverting it fix your problems?
> Thanks for your help.
>
> Hua
cu
Adrian
commit 1864f7bd58351732593def024e73eca1f75bc352
Author: Ian Kent <[EMAIL PROTECTED]>
Date: Wed Aug 22 14:01:54 2007 -0700
autofs4: deadlock during create
Due to inconsistent locking in the VFS between calls to lookup and
revalidate deadlock can occur in the automounter.
The inconsistency is that the directory inode mutex is held for both lookup
and revalidate calls when called via lookup_hash whereas it is held only
for lookup during a path walk. Consequently, if the mutex is held during a
call to revalidate autofs4 can't release the mutex to callback the daemon
as it can't know whether it owns the mutex.
This situation happens when a process tries to create a directory within an
automount and a second process also tries to create the same directory
between the lookup and the mkdir. Since the first process has dropped the
mutex for the daemon callback, the second process takes it during
revalidate leading to deadlock between the autofs daemon and the second
process when the daemon tries to create the mount point directory.
After spending quite a bit of time trying to resolve this on more than one
occassion, using rather complex and ulgy approaches, it turns out that just
delaying the hashing of the dentry until the create operation works fine.
Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index 2d4c8a3..45ff3d6 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -587,19 +587,20 @@ static struct dentry *autofs4_lookup(struct inode *dir,
struct dentry *dentry, s
unhashed = autofs4_lookup_unhashed(sbi, dentry->d_parent,
>d_name);
if (!unhashed) {
/*
-* Mark the dentry incomplete, but add it. This is needed so
-* that the VFS layer knows about the dentry, and we can count
-* on catching any lookups through the revalidate.
-*
-* Let all the hard work be done by the revalidate function that
-* needs to be able to do this anyway..
-*
-* We need to do this before we release the directory semaphore.
+* Mark the dentry incomplete but don't hash it. We do this
+* to serialize our inode creation operations (symlink and
+* mkdir) which prevents deadlock during the callback to
+* the daemon. Subsequent user space lookups for the same
+* dentry are placed on the wait queue while the daemon
+* itself is allowed passage unresticted so the create
+* operation itself can then hash the dentry. Finally,
+* we check for the hashed dentry and return the newly
+* hashed dentry.
*/
dentry->d_op = _root_dentry_operations;
dentry->d_fsdata = NULL;
- d_add(dentry, NULL);
+ d_instantiate(dentry, NULL);
} else {
struct autofs_info *ino = autofs4_dentry_ino(unhashed);
DPRINTK("rehash %p with %p", dentry, unhashed);
@@ -607,15 +608,17 @@ static struct dentry *autofs4_lookup(struct inode *dir,
struct dentry *dentry, s
* If we are racing with expire the request might not
* be quite complete but the directory has been removed
* so it must have been successful, so just wait for it.
+* We need to ensure the AUTOFS_INF_EXPIRING flag is clear
+* before continuing as revalidate may fail when calling
+* try_to_fill_dentry (returning EAGAIN) if we don't.
*/
- if (ino && (ino->flags & AUTOFS_INF_EXPIRING)) {
+ while (ino && (ino->flags & AUTOFS_INF_EXPIRING)) {
DPRINTK("wait for incomplete expire %p name=%.*s",
unhashed, unhashed->d_name.len,
unhashed->d_name.name);
autofs4_wait(sbi, unhashed, NFY_NONE);
DPRINTK("request completed");
}
- d_rehash(unhashed);
dentry = unhashed;
}
@@ -658,7 +661,7
Re: [-mm PATCH] Memory controller improve user interface
Dave Hansen wrote: > On Thu, 2007-08-30 at 03:57 +0530, Balbir Singh wrote: >> True, mmap() is a good example of such an interface for developers, I >> am not sure about system admins though. >> >> To quote Andrew >> >> Reporting tools could run getpagesize() and do the arithmetic, but we >> generally try to avoid exposing PAGE_SIZE, HZ, etc to userspace in this >> manner. >> > > Well, rounding to PAGE_SIZE exposes PAGE_SIZE as well, just in a > non-intuitive fashion. :) > Agreed, but the user might choose to ignore it altogether. > If we're going to modify what the user specifies, we should probably at > least mandate that writes are only a "suggestion" and users must read > back the value to ensure what actually got committed. > Agreed, excellent suggestion! > If we're going to round in any direction, shouldn't we round up? If a > user specifies 4097 bytes and uses two pages, we don't want to complain > when they hit that second page. > Absolutely, I used rounding to mean round up, truncation for rounding down. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - 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: [-mm PATCH] Memory controller improve user interface
Dave Hansen wrote: > On Wed, 2007-08-29 at 15:20 -0700, Paul Menage wrote: >> I'd argue that having the user's specified limit be truncated to the >> page size is less confusing than giving an EINVAL if it's not page >> aligned. > > Do we truncate mmap() values to the nearest page so to not confuse the > user? ;) > I think rounding to the closest page size is a better option, but again it can be a bit confusing. I am all for using memparse() to parse the user input as a specification of the memory limit. The second question of how to store it internally without truncation/ rounding is something we need to agree upon. We also need to see how to display the data back to the user. I chose kilobytes for two reasons 1. Several people recommended it 2. Herbert mentioned that they've moved to that interface and it was working fine for them. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL PS: I am going off to the web to search for some CUI/CLI guidelines. - 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: [-mm PATCH] Memory controller improve user interface
On Thu, 2007-08-30 at 03:57 +0530, Balbir Singh wrote: > True, mmap() is a good example of such an interface for developers, I > am not sure about system admins though. > > To quote Andrew > > Reporting tools could run getpagesize() and do the arithmetic, but we > generally try to avoid exposing PAGE_SIZE, HZ, etc to userspace in this > manner. > Well, rounding to PAGE_SIZE exposes PAGE_SIZE as well, just in a non-intuitive fashion. :) If we're going to modify what the user specifies, we should probably at least mandate that writes are only a "suggestion" and users must read back the value to ensure what actually got committed. If we're going to round in any direction, shouldn't we round up? If a user specifies 4097 bytes and uses two pages, we don't want to complain when they hit that second page. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/4] 2.6.23-rc4: known regressions
Takashi Iwai wrote: At Wed, 29 Aug 2007 18:42:56 +0300, Ivan N. Zlatev wrote: On 8/29/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote: ALSA Subject : Master volume control broken References : http://lkml.org/lkml/2007/8/18/46 Last known good : ? Submitter : Thomas Meyer <[EMAIL PROTECTED]> Caused-By : Ivan N. Zlatev <[EMAIL PROTECTED]> commit 5d5d3bc3eddf2ad97b2cb090b92580e7fed6cee1 Handled-By : Ivan N. Zlatev <[EMAIL PROTECTED]> Status : problem is being debugged Hello, I am not the one to handle the issue. I have just supplied the pinconfigs for the intel mac cards and assisted with logs/debug information, so I happen to be more of an end user. I am not familiar with the code base of the Intel HDA Codec. Takashi Iwai is the one with the knowledge to fix the problem. ... but without the hardware :-< IMO, this is actually no real regression. In the earlier verison, you didn't have controls for multiple outputs, thus the mixer control was named as Master. Now you do have multiple individual controls, and thus there is no master any more, instead. That's the trade-off. Would you buy or use a stand-alone mixer where the only way to control total output would be to change the setting for one output, then rebalance all the others against it, and then iterate until the result is correct? Is this an intermediate step to the full functionality of a $29 Radio Shack mixer, or a limitation of just one audio driver, or maybe the user interface for ALSA is broken right now? Is it planned to leave Linux audio in this state? -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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/
4KSTACKS + DEBUG_STACKOVERFLOW harmful
Noticed today that the combination of 4KSTACKS and DEBUG_STACKOVERFLOW config options is a bit deadly. DEBUG_STACKOVERFLOW warns in do_IRQ if we're within THREAD_SIZE/8 of the end of useable stack space, or 512 bytes on a 4k stack. If we are, then it goes down the dump_stack path, which uses most, if not all, of the remaining stack, thereby turning a well-intentioned warning into a full-blown catastrophe. The callchain from the warning looks something like this, with stack usage shown as found on my x86 box: 4 dump_stack 4 show_trace 8 show_trace_log_lvl 4 dump_trace print_context_stack 12 print_trace_address print_symbol 232 __print_symbol 164 sprint_symbol 20 printk ___ 448 448 bytes to tell us that we're within 512 bytes (or less) of certain doom... and I think there's call overhead on top of that? The large stack usage in those 2 functions is due to big char arrays, of size KSYM_NAME_LEN (128 bytes) and KSYM_SYMBOL_LEN (223 bytes). IOW, the stack warning effectively reduces useful stack left in our itty bitty 4k stacks by over 10%. Any suggestions for ways around this? The warning is somewhat helpful, and I guess the obvious option is to lighten up the dump_stack path, but it's still effectively reducing precious available stack space by some amount. With CONFIG_DEBUG_STACK_USAGE, we could print at oops time: "oh, and by the way, you blew your stack" if there is no zeroed stack space left, as a post-mortem. Even without that option, I think we could still check whether the *current* %esp at oops time has gone too far? But if we blew the stack, returned, and *then* oops, I think it'd be hard to know without the DEBUG_STACK_USAGE option that we ran out of room. -Eric - 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/28] 2.6.22-stable review cycle again
Sorry for the delay, I am out of town for a few weeks, and am away from network connectivit at the moment. I'll get this out in a few days when I return to civilization. Thanks, Greg k-h Sent via BlackBerry by AT - 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: [-mm PATCH] Memory controller improve user interface
Dave Hansen wrote: > On Thu, 2007-08-30 at 03:34 +0530, Balbir Singh wrote: >> I've thought about this before. The problem is that a user could >> set his limit to 1 bytes, but would then see the usage and >> limit round to the closest page boundary. This can be confusing >> to a user. > > True, but we're lying if we allow a user to set their limit there, > because we can't actually enforce a limit at 8,192 bytes vs 10,000. > They're the same limit as far as the kernel is concerned. > > Why not just -EINVAL if the value isn't page-aligned? There are plenty > of interfaces in the kernel that require userspace to know the page > size, so this shouldn't be too difficult. True, mmap() is a good example of such an interface for developers, I am not sure about system admins though. To quote Andrew Reporting tools could run getpagesize() and do the arithmetic, but we generally try to avoid exposing PAGE_SIZE, HZ, etc to userspace in this manner. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - 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: [-mm PATCH] Memory controller improve user interface
On Wed, 2007-08-29 at 15:20 -0700, Paul Menage wrote: > > I'd argue that having the user's specified limit be truncated to the > page size is less confusing than giving an EINVAL if it's not page > aligned. Do we truncate mmap() values to the nearest page so to not confuse the user? ;) Imagine a careful application setting and accounting for limits on a long-running system. Might its internal accounting get sufficiently misaligned from the kernel's after a while to cause a problem? Truncating values like that would appear reserve significantly less memory than desired over a long period of time. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Who wants to maintain KR list for stable releases? (was Re: nmi_watchdog=2 regression in 2.6.21)
On Wed, Aug 29, 2007 at 12:42:02AM -0700, Natalie Protasevich wrote:
>...
> Then I think bugzilla needs:
> adding more categories such as security,
"security" would be a flag like "regression", not a category.
> system calls (lots of
> implementation suggestions for posix and non-posix ones),
>...
Bugzilla is for tracking bugs, not for discussing possible
kernel features.
Tracking feature or implementation suggestions wouldn't make sense.
Consider e.g. that there are several people on linux-kernel who often
write what they think the kernel should do but who never write a single
line of code themselves. There's no value in tracking such stuff.
> improved searches - for sure, for example in addition to
> pre-cooked queries make possible using "raw" queries directly on sql,
> which will address misplaced bugs and will make categories more
> dynamic;
What do you have in mind?
I've always been able to do any search I wanted using the "Advanced Search"
of Bugzilla. Well, just checking, it seems the search for the new
"regression" flag could be made easier, but that's not a general problem.
But what could be improved in the database would be to fix the
charset problems for getting the RSS feeds working (#8774). ;-)
> recipe database, for standard debugging requests and procedures
> (serial console, getting sysreq traces, bisecting etc. - things to cut
> and paste)
Documentation makes sense, but it belongs into some place like the
kernelnewbies wiki, not the Bugzilla itself.
> user modifiable personal environment ("my bugzilla"), more of
> morph type interface around the database.
Preferences settings plus saved searches already work.
What is missing?
> ... not mentioning all flaws and problems with current one (cannot get
> back to home page,
There's a "Home" link that does exactly this among the actions offered
at the bottom of all pages.
> clear previous search,
There's a "Search" link that gives you a new search among the actions
offered at the bottom of all pages.
> do certain updates in one step
>...
The only thing that comes into my mind is that you cannot reassign a bug
and change it's status in one step. But "flaws and problems" would IMHO
be too hard an expression since it works fine with two updates.
> Regressions need to be tracked in effective manner, and I also noticed
> counter intuitive question that we have now (the infamous "last
> release when it _didn't_ happen") is clearly not the way to go, rather
> adding simple boxes "Was working in XX" and "Not working in XX" or
> similar straightforward question.
Sounds like a good solution for the one question so many submitters get
wrong. :-)
> In my opinion bugzilla is far from being a convenient tool. I suspect
> that hating bugzilla comes down to having to deal with no
> sophisticated interface that is inadequate - when so many nice and
> slick tools and sites are around that we all used to. I am also
> investigating and checking out other bugzillas looking for good ideas.
Bugzilla isn't that bad and it has the advantage of being the most
popular bug tracking system for open source projects, which means that
most likely every kernel developer and many submitters have already used
a Bugzilla at some other project.
>From past discussions my impression was that several kernel developers
have an email based workflow and are reluctant to integrate web based
actions into their workflow.
I'd say the success of any bigger Bugzilla change or switch to a
different or writing of a new bug tracking system could be measured
by answering the following question:
Will Linus Torvalds and David Miller use it?
> Thanks,
> --Natalie
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
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: [-mm PATCH] Memory controller improve user interface
On 8/29/07, Dave Hansen <[EMAIL PROTECTED]> wrote: > On Thu, 2007-08-30 at 03:34 +0530, Balbir Singh wrote: > > I've thought about this before. The problem is that a user could > > set his limit to 1 bytes, but would then see the usage and > > limit round to the closest page boundary. This can be confusing > > to a user. > > True, but we're lying if we allow a user to set their limit there, > because we can't actually enforce a limit at 8,192 bytes vs 10,000. > They're the same limit as far as the kernel is concerned. > > Why not just -EINVAL if the value isn't page-aligned? There are plenty > of interfaces in the kernel that require userspace to know the page > size, so this shouldn't be too difficult. I'd argue that having the user's specified limit be truncated to the page size is less confusing than giving an EINVAL if it's not page aligned. Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH -mm 0/3] PM: Improve ACPI handling during suspend and hibernation (rev. 3)
On Monday, 27 August 2007 23:47, Rafael J. Wysocki wrote: > Hi, > > The patches in this series are intended to improve the handling of the ACPI > platform during suspend and hibernation. > > They do the following things: > * make hibernation_platform_enter() consistent with the sleep state entering > code in kernel/power/main.c > * introduce global platform callbacks allowing us to handle ACPI in a more > fine > grained way during suspend and hibernation > * improve the handling of the system status indicator during suspend and > hibernation. Please regard this patch series as withdrawn. I have found a corner case that requires special treatment clashing with the 2/3 and 3/3 patches and the 1/3 patch will be resubmitted separately. Greetings, Rafael - 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: [-mm PATCH] Memory controller improve user interface
On Thu, 2007-08-30 at 03:34 +0530, Balbir Singh wrote: > I've thought about this before. The problem is that a user could > set his limit to 1 bytes, but would then see the usage and > limit round to the closest page boundary. This can be confusing > to a user. True, but we're lying if we allow a user to set their limit there, because we can't actually enforce a limit at 8,192 bytes vs 10,000. They're the same limit as far as the kernel is concerned. Why not just -EINVAL if the value isn't page-aligned? There are plenty of interfaces in the kernel that require userspace to know the page size, so this shouldn't be too difficult. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm PATCH] Memory controller improve user interface
Dave Hansen wrote: > On Wed, 2007-08-29 at 16:40 +0530, Balbir Singh wrote: >> >> @@ -352,7 +353,7 @@ int mem_container_charge(struct page *pa >> kfree(pc); >> pc = race_pc; >> atomic_inc(>ref_cnt); >> - res_counter_uncharge(>res, 1); >> + res_counter_uncharge(>res, MEM_CONTAINER_CHARGE_KB); >> css_put(>css); >> goto done; >> } > > Do these changes really need to happen anywhere besides the > user<->kernel boundary? Why can't internal tracking be in pages? I've thought about this before. The problem is that a user could set his limit to 1 bytes, but would then see the usage and limit round to the closest page boundary. This can be confusing to a user. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - 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: [NFS] [3/4] 2.6.23-rc4: known regressions
On Wed, Aug 29, 2007 at 05:27:39PM +0200, Michal Piotrowski wrote: > FS > > Subject : [NFSD OOPS] 2.6.23-rc1-git10 > References : http://lkml.org/lkml/2007/8/2/462 > Last known good : ? > Submitter : Andrew Clayton <[EMAIL PROTECTED]> > Caused-By : ? > Handled-By : ? > Status : unknown This is a bug, but (alas) appears to be a preexisting bug, so may not belong on this list.--b. - 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/
Possible kernel lock in semaphore's __down()
Hi!
I'm a newbie here on the list and also as a "kernel hacker". There's a
bug reported in bugzilla (Bug 7927), cite:
> In the function __down
>
> fastcall void __sched __down(struct semaphore * sem)
> {
> struct task_struct *tsk = current;
> DECLARE_WAITQUEUE(wait, tsk);
> unsigned long flags;
>
> tsk->state = TASK_UNINTERRUPTIBLE;
> spin_lock_irqsave(>wait.lock, flags);
> add_wait_queue_exclusive_locked(>wait, );
> ...
> }
>
>
> From this code fragment, it sets the tsk->state to TASK_UNINTERRUPTIBLE
> before
> gets the spinlock. Assume at that moment, a interrupt ocuur and and after the
> interrupt handle ends, an other process is scheduled to run (assume the
> kernel
> is preemptalbe). In this case, the previous process ( its state has set to
> TASK_UNINTERRUPTIBLE) has been picked off the run queue, and it has not yet
> add
> to the wait queue( sem->wait ), so it may be never waited up forever.
>
I have marked it as rejected as as I can see at the time this function is
called,
it is guaranteed that ret_from_intr() will not call schedule() on return from
an
interrupt handler to either kernel space or user space because of the call
to macro might_sleep() in semaphore's down(). Am I wrong?
Thanks and best regards,
Aleksandar Dezelin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use task_pid_nr() in ip_vs_sync.c
Pavel Emelianov [EMAIL PROTECTED] wrote: | The sync_master_pid and sync_backup_pid are set in set_sync_pid() | and are used later for set/not-set checks and in printk. So it | is safe to use the global pid value in this case. | | Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Acked-by: Sukadev Bhattiprolu <[EMAIL PROTECTED]> | | --- | | diff --git a/net/ipv4/ipvs/ip_vs_sync.c b/net/ipv4/ipvs/ip_vs_sync.c | index 959c08d..d0798a5 100644 | --- a/net/ipv4/ipvs/ip_vs_sync.c | +++ b/net/ipv4/ipvs/ip_vs_sync.c | @@ -794,7 +794,7 @@ static int sync_thread(void *startup) | | add_wait_queue(_wait, ); | | - set_sync_pid(state, current->pid); | + set_sync_pid(state, task_pid_nr(current)); | complete(tinfo->startup); | | /* - 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] Override 80-wire cable detection for Toshiba S1800-814
On Wed, 29 Aug 2007 23:41:13 +0200 Daniel Exner <[EMAIL PROTECTED]> wrote: > Hi! > > Please CC me, as I'm currently not subscribed to this list, thx. > > Attached patch will add above mentioned Laptop Model to whitelist for both > pata_ali and alim15x3, as it is correctly detected as 40-wire connected but > this cable is short enough to still do transfers higher than UDMA33. > Don't know if this is also true for other S1800 Laptops cause I own only one. Looks good to me - does need a Signed-off-by: line however - 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: Understanding I/O behaviour - next try
--- Chuck Ebbert <[EMAIL PROTECTED]> wrote: > On 08/28/2007 11:53 AM, Martin Knoblauch wrote: > > > > The basic setup is a dual x86_64 box with 8 GB of memory. The > DL380 > > has a HW RAID5, made from 4x72GB disks and about 100 MB write > cache. > > The performance of the block device with O_DIRECT is about 90 > MB/sec. > > > > The problematic behaviour comes when we are moving large files > through > > the system. The file usage in this case is mostly "use once" or > > streaming. As soon as the amount of file data is larger than 7.5 > GB, we > > see occasional unresponsiveness of the system (e.g. no more ssh > > connections into the box) of more than 1 or 2 minutes (!) duration > > (kernels up to 2.6.19). Load goes up, mainly due to pdflush threads > and > > some other poor guys being in "D" state. > > Try booting with "mem=4096M", "mem=2048M", ... > > hmm. I tried 1024M a while ago and IIRC did not see a lot [any] difference. But as it is no big deal, I will repeat it tomorrow. Just curious - what are you expecting? Why should it help? Thanks Martin -- Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de - 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] Override 80-wire cable detection for Toshiba S1800-814
Hi!
Please CC me, as I'm currently not subscribed to this list, thx.
Attached patch will add above mentioned Laptop Model to whitelist for both
pata_ali and alim15x3, as it is correctly detected as 40-wire connected but
this cable is short enough to still do transfers higher than UDMA33.
Don't know if this is also true for other S1800 Laptops cause I own only one.
I hope I did this correctly as this is my first Patch Mail to LKML :)
--
Greetings
Daniel Exner
--- linux-2.6.22.old/drivers/ata/pata_ali.c 2007-08-29 23:27:53.0 +0200
+++ linux-2.6.22/drivers/ata/pata_ali.c 2007-08-29 23:14:37.0 +0200
@@ -48,6 +48,13 @@
DMI_MATCH(DMI_BOARD_VERSION, "OmniBook N32N-736"),
},
},
+ {
+ .ident = "Toshiba Satelite S1800-814",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "S1800-814"),
+ },
+ },
{ }
};
--- linux-2.6.22.old/drivers/ide/pci/alim15x3.c 2007-08-29 22:17:14.0 +0200
+++ linux-2.6.22/drivers/ide/pci/alim15x3.c 2007-08-29 22:56:27.0 +0200
@@ -596,6 +596,13 @@
DMI_MATCH(DMI_BOARD_VERSION, "OmniBook N32N-736"),
},
},
+ {
+ .ident = "Toshiba Satellite S1800-814",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "S1800-814"),
+ },
+ },
{ }
};
Re: [patch] fix the max path calculation in radix-tree.c
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Tue, Aug 21, 2007 at 03:48:42PM -0400, Jeff Moyer wrote:
>> Hi,
>>
>> A while back, Nick Piggin introduced a patch to reduce the node memory
>> usage for small files (commit cfd9b7df4abd3257c9e381b0e445817b26a51c0c):
>>
>> -#define RADIX_TREE_MAP_SHIFT6
>> +#define RADIX_TREE_MAP_SHIFT(CONFIG_BASE_SMALL ? 4 : 6)
>>
>> Unfortunately, he didn't take into account the fact that the
>> calculation of the maximum path was based on an assumption of having
>> to round up:
>>
>> #define RADIX_TREE_MAX_PATH (RADIX_TREE_INDEX_BITS/RADIX_TREE_MAP_SHIFT + 2)
>>
>> So, if CONFIG_BASE_SMALL is set, you will end up with a
>> RADIX_TREE_MAX_PATH that is one greater than necessary. The practical
>> upshot of this is just a bit of wasted memory (one long in the
>> height_to_maxindex array, an extra pre-allocated radix tree node per
>> cpu, and extra stack usage in a couple of functions), but it seems
>> worth getting right.
>>
>> It's also worth noting that I never build with CONFIG_BASE_SMALL.
>> What I did to test this was duplicate the code in a small user-space
>> program and check the results of the calculations for max path and the
>> contents of the height_to_maxindex array.
>>
>
> OK, after you DIV_ROUND_UP, what is the extra 1 for? For paths, it is because
> they are NULL terminated paths I guess (without remembering too hard), and for
> height_to_maxindex array it is needed for 0-height trees I think. So it would
> be kinda cleaner to have the _real_ MAX_PATH, and two other constants for
> this array and the paths arrays (that just happen to be identical due to
> implementation). Don't you think?
>
> But that's not to nack this patch. On the contrary I think your logic is
> correct, and it should be fixed. I didn't check the maths myself but I trust
> you :)
Hi, Nick,
As I said, I wasn't sure what to name the constants for the path and
height arrays, so I just commented the +1 there. I've been running
this on one of my 64bit test systems successfully for about a day,
now. The one code path I was concerned about was
radix_tree_node_alloc, since the prealloc array changes size with this
patch. I stepped through the code by hand and it looks right to me.
Additionally, I wrote a kprobe that would simulate the
kmem_cache_alloc failure. I then inserted a node at max height into
an empty tree with preemption disabled. I verified, using the crash
utility, that the tree was constructed and filled in properly.
You can find the kprobe at http://people.redhat.com/jmoyer/radix-tree/.
Signed-off-by: Jeff Moyer <[EMAIL PROTECTED]>
diff --git a/lib/radix-tree.c b/lib/radix-tree.c
index 514efb2..d2655cb 100644
--- a/lib/radix-tree.c
+++ b/lib/radix-tree.c
@@ -60,9 +60,14 @@ struct radix_tree_path {
};
#define RADIX_TREE_INDEX_BITS (8 /* CHAR_BIT */ * sizeof(unsigned long))
-#define RADIX_TREE_MAX_PATH (RADIX_TREE_INDEX_BITS/RADIX_TREE_MAP_SHIFT + 2)
+#define RADIX_TREE_MAX_PATH (DIV_ROUND_UP(RADIX_TREE_INDEX_BITS, \
+ RADIX_TREE_MAP_SHIFT))
-static unsigned long height_to_maxindex[RADIX_TREE_MAX_PATH] __read_mostly;
+/*
+ * The height_to_maxindex array needs to be one deeper than the maximum
+ * path as height 0 holds only 1 entry.
+ */
+static unsigned long height_to_maxindex[RADIX_TREE_MAX_PATH + 1] __read_mostly;
/*
* Radix tree node cache.
@@ -487,7 +492,11 @@ EXPORT_SYMBOL(radix_tree_tag_set);
void *radix_tree_tag_clear(struct radix_tree_root *root,
unsigned long index, unsigned int tag)
{
- struct radix_tree_path path[RADIX_TREE_MAX_PATH], *pathp = path;
+ /*
+* The radix tree path needs to be one longer than the maximum path
+* since the "list" is null terminated.
+*/
+ struct radix_tree_path path[RADIX_TREE_MAX_PATH + 1], *pathp = path;
struct radix_tree_node *slot = NULL;
unsigned int height, shift;
@@ -882,7 +891,11 @@ static inline void radix_tree_shrink(struct
radix_tree_root *root)
*/
void *radix_tree_delete(struct radix_tree_root *root, unsigned long index)
{
- struct radix_tree_path path[RADIX_TREE_MAX_PATH], *pathp = path;
+ /*
+* The radix tree path needs to be one longer than the maximum path
+* since the "list" is null terminated.
+*/
+ struct radix_tree_path path[RADIX_TREE_MAX_PATH + 1], *pathp = path;
struct radix_tree_node *slot = NULL;
struct radix_tree_node *to_free;
unsigned int height, shift;
-
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] Remove write-only variable from pktgen_thread
Pavel Emelianov [EMAIL PROTECTED] wrote:
| The pktgen_thread.pid is set to current->pid and is never used
| after this. So remove this at all.
|
| Found during isolating the explicit pid/tgid usage.
|
| Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Good observation that its not being used :-)
Acked-by: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
|
| ---
|
| diff --git a/net/core/pktgen.c b/net/core/pktgen.c
| index 3a3154e..93695c2 100644
| --- a/net/core/pktgen.c
| +++ b/net/core/pktgen.c
| @@ -380,7 +380,6 @@ struct pktgen_thread {
| /* Field for thread to receive "posted" events terminate, stop ifs
| etc. */
|
| u32 control;
| - int pid;
| int cpu;
|
| wait_queue_head_t queue;
| @@ -3462,8 +3461,6 @@ static int pktgen_thread_worker(void *ar
|
| init_waitqueue_head(>queue);
|
| - t->pid = current->pid;
| -
| pr_debug("pktgen: starting pktgen/%d: pid=%d\n", cpu,
| task_pid_nr(current));
|
| max_before_softirq = t->max_before_softirq;
-
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: nmi_watchdog=2 regression in 2.6.21
Daniel,
On Tue, Aug 28, 2007 at 01:13:44PM -0700, Daniel Walker wrote:
> On Tue, 2007-08-28 at 12:46 -0700, Stephane Eranian wrote:
>
> > I think I found the problem. As I suspected, it seems there is an assymetry
> > between the 1st end 2nd counter (just like what they have on P6 core). Yet
> > for architectural perfmon v1, this restriction is supposed to be lifted.
> >
> > Unfortunately, a quick look at the errata document at
> > http://download.intel.com/design/mobile/SPECUPDT/30922212.pdf
> >
> > for Core Duo shows bugs A49 as 'nofix':
> > Core Duo processor has a bug which renders the enable bit (22) of
> > PERFEVTSEL1 inoperative. The processor behaves like former P6 cores,
> > the enable bit of PERFEVTSEL0 controls the activation of both counters
>
> Your patch switched the nmi from PERFEVTSEL0 to PERFEVTSEL1 (right?)..
> So 0 works, 1 does not , for me anyway ..
>
Yes that is what the patch was doing and it was for a specific reason. On
a Core 2 Duo (which uses the 2nd generation of the architectural PMU), some
useful features (such as PEBS) requiree the use of counter 0 so we cannot
give it away to NMI.
Now on Core Duo, there is no PEBS anyway, so it is okay to use counter 0
for NMI. The problem is that the detection code in perfctr-watchdog.c
treats a Core Duo and a Core 2 Duo the same way as they both have the
X86_FEATURE_ARCH_PERFMON bit set.
I have attached a patch with handle the case of the Core Duo. Unfortunately,
I do not own one so I cannot test it. I would appreciate if you could
try re-applying my counter 0 -> 1 patch + this new one to see if you
have the problem with the NMI getting stuck.
The patch below is probably still needed to handle the case where you get
stuck.
Thanks.
> > That explains why you get the 'NMI stuck' message when using PERFEVTSEL1.
> > I suspect when using PERFEVTSEL0, then NMI watchdog is not stuck. So it
> > is possible that in case NMI is stuck the code does not cleanly shutdown the
> > NMI interrupt and you get some spurious NMI interrupt later in the boot at
> > you are stuck because you are holding a lock. We need to look at the error
> > path of check_nmi_watchdog(). I glance through it and could not find the
> > place
> > where the APIC vector is cleared.
>
> As far as I can tell the check_nmi_watchdog() doesn't take locks, and it
> can't safely share a lock with the NMI ..
>
> The patch below fixes the hang (not the stuck NMI) .. Not totally sure
> why, but the cpus are stuck in a loop waiting for the endflag which
> never comes .. This also plays with the nmi hz which might do
> something.. /proc/interrupt doesn't show any nmi's either..
>
> Daniel
>
> Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
>
> Index: linux-2.6.22/arch/i386/kernel/nmi.c
> ===
> --- linux-2.6.22.orig/arch/i386/kernel/nmi.c 2007-08-15 00:51:12.0
> +
> +++ linux-2.6.22/arch/i386/kernel/nmi.c 2007-08-28 20:15:04.0
> +
> @@ -82,7 +82,7 @@ static __init void nmi_cpu_busy(void *da
> static int __init check_nmi_watchdog(void)
> {
> unsigned int *prev_nmi_count;
> - int cpu;
> + int cpu, ret = 0;
>
> if ((nmi_watchdog == NMI_NONE) || (nmi_watchdog == NMI_DEFAULT))
> return 0;
> @@ -125,18 +125,18 @@ static int __init check_nmi_watchdog(voi
> if (!atomic_read(_active)) {
> kfree(prev_nmi_count);
> atomic_set(_active, -1);
> - return -1;
> - }
> + printk("nmi malfunctioning.\n");
> + ret = -1;
> + } else
> + printk("OK.\n");
> endflag = 1;
> - printk("OK.\n");
> -
> /* now that we know it works we can reduce NMI frequency to
> something more reasonable; makes a difference in some configs */
> if (nmi_watchdog == NMI_LOCAL_APIC)
> nmi_hz = lapic_adjust_nmi_hz(1);
>
> kfree(prev_nmi_count);
> - return 0;
> + return ret;
> }
> /* This needs to happen later in boot so counters are working */
> late_initcall(check_nmi_watchdog);
>
--
-Stephane
diff --git a/arch/i386/kernel/cpu/perfctr-watchdog.c
b/arch/i386/kernel/cpu/perfctr-watchdog.c
index 9b5d6af..8af7998 100644
--- a/arch/i386/kernel/cpu/perfctr-watchdog.c
+++ b/arch/i386/kernel/cpu/perfctr-watchdog.c
@@ -613,6 +613,17 @@ static struct wd_ops intel_arch_wd_ops = {
.evntsel = MSR_ARCH_PERFMON_EVENTSEL1,
};
+/*
+ * Check for Intel Core Duo because it has a bug with PERFEVTSEL1
+ * (see Spefication Update bug AE49) and must use PERFEVTSEL0. We cannot
+ * use this counter on other processors supporting X86_FEATURE_ARCH_PERFMON
+ * because PEBS requires it.
+ */
+static inline int is_coreduo(void)
+{
+ return boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 14;
+}
+
static void probe_nmi_watchdog(void)
{
switch (boot_cpu_data.x86_vendor) {
@@ -623,7 +634,8 @@ static void probe_nmi_watchdog(void)
Re: [PATCH] Send quota messages via netlink
On Wed, 29 Aug 2007 15:06:43 MDT, Eric W. Biederman said: > So we have to figure out how to do the hard thing which is look at > who opened our netlink broadcast see if they are in the same user > namespace as current->user. Which is a pain and we don't currently > have the infrastructure for. Provision also needs to be made for things that are listening to the netlink broadcasts that don't match the user doing the operation or the owner of the file - similar to the way auditd wants events. pgpJMJHoMvAqQ.pgp Description: PGP signature
Re: [PATCH] Use same_thread_group() in signalfd.c
Pavel Emelianov [EMAIL PROTECTED] wrote: | This is a lost hunk of previous patch that isolated the | explicit usage of task->tgid in some places. The signalfd | code uses the tsk->tgid comparison. | | Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Acked-by: Sukadev Bhattiprolu <[EMAIL PROTECTED]> | | --- | | diff --git a/fs/signalfd.c b/fs/signalfd.c | index a8e293d..5bfd2c5 100644 | --- a/fs/signalfd.c | +++ b/fs/signalfd.c | @@ -64,7 +64,7 @@ static int signalfd_lock(struct signalfd | return 0; | } | | - if (lk->tsk->tgid == current->tgid) | + if (same_thread_group(lk->tsk, current->tgid)) | lk->tsk = current; | | return 1; - 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] Send quota messages via netlink
Jan Kara <[EMAIL PROTECTED]> writes: > >> However I'm still confused about the use of current->user. If that >> is what we really want and not the user who's quota will be charged >> it gets to be a really trick business, because potentially the uid >> we want to deliver varies depending on who opened the netlink socket. > I see it's a complicated matter :). What I need to somehow pass to > userspace is something (and I don't really care whether it will be number, > string or whatever) that userspace can read and e.g. find a terminal > window or desktop the affected user has open and also translate the > identity to some user-understandable name (average user Joe has to > understand that he should quickly cleanup his home directory ;). > Thinking more about it, we could probably pass a string to userspace in > the format: > : > > So for example we can have something like: > unix:1000 (traditional unix UIDs) > nfs4:[EMAIL PROTECTED] > > The problem is: Are we able to find out in which "namespace type" we are > and send enough identifying information from a context of unpriviledged > user? Ok. This provides enough context to understand what you are trying to do. You do want the unix user id, not the filesystem notion. Because you are looking for the user. So we have to figure out how to do the hard thing which is look at who opened our netlink broadcast see if they are in the same user namespace as current->user. Which is a pain and we don't currently have the infrastructure for. Eric - 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: from which address does the kernel load initrd?
Xu Yang wrote: does anyone know from which address does the kernel load the initrd? I mean the default value? I want to boot the filesystem using a ramdisk. but the I don't know where to put it in my ram? as I don't have flash , I can only load the ramdisk into the ram. and which boot option should I use? See Documentation/i386/boot.txt -hpa - 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/
regression of autofs for current git?
Hi, I am wondering if this is a known issue, but I just built the current git and several autofs mounts mysteriously disappeared. Restarting autofs could fix some, but then lose others. 2.6.22 was fine. Is there anything I could check other than bisect? (It may take some time for me to get to it) Thanks for your help. Hua - 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.23-rc4: BAD regression
On Wednesday 29 August 2007 21:45:01 Alexey Starikovskiy wrote: > If you could open a bugreport at bugzilla.kernel.org in ACPI category > and attach > dmesg and acpidump output, that would help a lot. (I hope :( ) > done. http://bugzilla.kernel.org/show_bug.cgi?id=8958 > Thanks, > Alex. > > Daniel Ritz wrote: > > On Wednesday 29 August 2007 06:41:41 Alexey Starikovskiy wrote: > > > >> Daniel, > >> Does this patch help you, or do we need to revert the whole thing? > >> > >> > > > > yes, this does the trick. the fan goes on again. thanks. > > if you still need additional debug output or if you want me to test > > a different patch just let me know. > > > > rgds > > -daniel > > > > > >> Sorry for the trouble, > >> Alex. > >> Daniel Ritz wrote: > >> > >>> tried that one on my old toshiba tecra 8000 laptop, almost killing it. > >>> the fan doesn't work any more...type 'make' and see the box dying. > >>> luckily my CPU doesn't commit suicide...bisected it to that one: > >>> > >>> cd8c93a4e04dce8f00d1ef3a476aac8bd65ae40b is first bad commit > >>> commit cd8c93a4e04dce8f00d1ef3a476aac8bd65ae40b > >>> Author: Alexey Starikovskiy <[EMAIL PROTECTED]> > >>> Date: Fri Aug 3 17:52:48 2007 -0400 > >>> > >>> ACPI: EC: If ECDT is not found, look up EC in DSDT. > >>> > >>> Some ASUS laptops access EC space from device _INI methods, but do not > >>> provide ECDT for early EC setup. In order to make them function > >>> properly, > >>> there is a need to find EC is DSDT before any _INI is called. > >>> > >>> Similar functionality was turned on by acpi_fake_ecdt=1 command line > >>> before. Now it is on all the time. > >>> > >>> http://bugzilla.kernel.org/show_bug.cgi?id=8598 > >>> > >>> Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]> > >>> Signed-off-by: Len Brown <[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/
from which address does the kernel load initrd?
does anyone know from which address does the kernel load the initrd? I mean the default value? I want to boot the filesystem using a ramdisk. but the I don't know where to put it in my ram? as I don't have flash , I can only load the ramdisk into the ram. and which boot option should I use? thanks regards, yang - 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] TASK_KILLED
I've long hated the non-killability of tasks accessing a dead
NFS server. Linus had an idea for fixing this way back in 2002:
http://www.ussg.iu.edu/hypermail/linux/kernel/0208.0/0167.html which
I've prototyped in this patch.
Splitting up TASK_* into separate bits is going to need a lot more
auditing, I think. It was easier back in 2002, but since then we've added
TASK_STOPPED and TASK_TRACED which also need to be gingerly checked for.
There's some debug code left in here to discourage Linus from just
applying it.
I've only added one real user of the killable concept to this patch --
try_lock_page(). However, this is enough for 'cat */*/*' to be killable
with a ^C when I unplug the ethernet cord between it and the nfs server.
I have another version of this patch which makes TASK_KILLABLE a separate
state on par with TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE, but I
don't like it as much as this one. I'll post it if there's demand.
diff --git a/fs/proc/array.c b/fs/proc/array.c
index ee4814d..6a3c876 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -140,13 +140,8 @@ static const char *task_state_array[] = {
static inline const char *get_task_state(struct task_struct *tsk)
{
- unsigned int state = (tsk->state & (TASK_RUNNING |
- TASK_INTERRUPTIBLE |
- TASK_UNINTERRUPTIBLE |
- TASK_STOPPED |
- TASK_TRACED)) |
- (tsk->exit_state & (EXIT_ZOMBIE |
- EXIT_DEAD));
+ unsigned int state = (tsk->state & TASK_REPORT) |
+ (tsk->exit_state & (EXIT_ZOMBIE | EXIT_DEAD));
const char **p = _state_array[0];
while (state) {
diff --git a/fs/read_write.c b/fs/read_write.c
index 507ddff..29e3f21 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -220,7 +220,7 @@ Einval:
static void wait_on_retry_sync_kiocb(struct kiocb *iocb)
{
- set_current_state(TASK_UNINTERRUPTIBLE);
+ set_current_state(TASK_KILLABLE);
if (!kiocbIsKicked(iocb))
schedule();
else
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 8a83537..56675e4 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -154,6 +154,7 @@ static inline pgoff_t linear_page_index(struct
vm_area_struct *vma,
}
extern void FASTCALL(__lock_page(struct page *page));
+extern int FASTCALL(__try_lock_page(struct page *page));
extern void FASTCALL(__lock_page_nosync(struct page *page));
extern void FASTCALL(unlock_page(struct page *page));
@@ -168,6 +169,18 @@ static inline void lock_page(struct page *page)
}
/*
+ * try_lock_page is like lock_page but sleeps killably. It returns
+ * 1 if it locked the page and 0 if it was killed while waiting.
+ */
+static inline int try_lock_page(struct page *page)
+{
+ might_sleep();
+ if (TestSetPageLocked(page))
+ return __try_lock_page(page);
+ return 1;
+}
+
+/*
* lock_page_nosync should only be used if we can't pin the page's inode.
* Doesn't play quite so well with block device plugging.
*/
diff --git a/include/linux/sched.h b/include/linux/sched.h
index bd6a032..c0c7d7c 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -165,16 +165,35 @@ print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq
*cfs_rq)
* mistake.
*/
#define TASK_RUNNING 0
-#define TASK_INTERRUPTIBLE 1
-#define TASK_UNINTERRUPTIBLE 2
-#define TASK_STOPPED 4
-#define TASK_TRACED8
+#define __TASK_INTERRUPTIBLE 1
+#define __TASK_UNINTERRUPTIBLE 2
+#define __TASK_STOPPED 4
+#define __TASK_TRACED 8
/* in tsk->exit_state */
#define EXIT_ZOMBIE16
#define EXIT_DEAD 32
/* in tsk->state again */
#define TASK_NONINTERACTIVE64
#define TASK_DEAD 128
+#define TASK_WAKEKILL 256
+#define TASK_WAKESIGNAL512
+#define TASK_LOADAVG 1024
+
+/* Convenience macros for the sake of set_task_state */
+#define TASK_INTERRUPTIBLE (TASK_WAKESIGNAL | __TASK_INTERRUPTIBLE)
+#define TASK_UNINTERRUPTIBLE (TASK_LOADAVG | __TASK_UNINTERRUPTIBLE)
+#define TASK_KILLABLE (TASK_WAKEKILL | TASK_UNINTERRUPTIBLE)
+#define TASK_STOPPED (TASK_WAKEKILL | __TASK_STOPPED)
+#define TASK_TRACED(TASK_WAKEKILL | __TASK_TRACED)
+
+/* Convenience macros for the sake of wake_up */
+#define TASK_NORMAL(__TASK_INTERRUPTIBLE | __TASK_UNINTERRUPTIBLE)
+#define TASK_ALL (TASK_WAKESIGNAL | TASK_WAKEKILL | TASK_LOADAVG)
+
+/* get_task_state() */
+#define TASK_REPORT(TASK_RUNNING | __TASK_INTERRUPTIBLE | \
+ __TASK_UNINTERRUPTIBLE | __TASK_STOPPED | \
+ __TASK_TRACED)
#define __set_task_state(tsk, state_value)
[PATCH] Fix lguest page-pinning logic ("lguest: bad stack page 0xc057a000")
If the stack pointer is 0xc057a000, then the first stack page is at 0xc0579000 (the stack pointer is decremented before use). Not calculating this correctly caused guests with CONFIG_DEBUG_PAGEALLOC=y to be killed with a "bad stack page" message: the initial kernel stack was just proceeding the .smp_locks section which CONFIG_DEBUG_PAGEALLOC marks read-only when freeing. Thanks to Frederik Deweerdt for the bug report! Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> --- drivers/lguest/interrupts_and_traps.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) === --- a/drivers/lguest/interrupts_and_traps.c +++ b/drivers/lguest/interrupts_and_traps.c @@ -270,8 +270,11 @@ void pin_stack_pages(struct lguest *lg) /* Depending on the CONFIG_4KSTACKS option, the Guest can have one or * two pages of stack space. */ for (i = 0; i < lg->stack_pages; i++) - /* The stack grows *upwards*, hence the subtraction */ - pin_page(lg, lg->esp1 - i * PAGE_SIZE); + /* The stack grows *upwards*, so the address we're given is the +* start of the page after the kernel stack. Subtract one to +* get back onto the first stack page, and keep subtracting to +* get to the rest of the stack pages. */ + pin_page(lg, lg->esp1 - 1 - i * PAGE_SIZE); } /* Direct traps also mean that we need to know whenever the Guest wants to use - 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/28] 2.6.22-stable review cycle again
On Wed, Aug 29, 2007 at 10:43:53PM +0300, Thomas Backlund wrote: > Greg KH skrev: > >This is the start of the stable review cycle for the 2.6.22.6 release. > >There are 28 patches in this series, all will be posted as a response > >to this one. If anyone has any issues with these being applied, please > >let us know. If anyone is a maintainer of the proper subsystem, and > >wants to add a Signed-off-by: line to the patch, please respond with it. > > > >These patches are sent out with a number of different people on the Cc: > >line. If you wish to be a reviewer, please email [EMAIL PROTECTED] to > >add your name to the list. If you want to be off the reviewer list, > >also email us. > > > >Responses should be made by August 25 22:00:00 UTC 2007. Anything > >received after that time might be too late. > > > > What happend to this ?? probably that Greg is currently very busy, as he has not posted for the last 5 days. I can attest it's not always easy to find the time needed to release on time. Give him a few more days. People have seen 2.4.35 drifting by nearly one month after I announced -rc1, so 5 days is really not much here ;-) Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
