Re: 2.6.13-rt1
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > Ingo, > > I just found another deadlock in the pi_lock logic. The PI logic is > very dependent on the P1->L1->P2->L2->P3 order. But our good old > friend is back, the BKL. > > Since the BKL is let go and regrabbed even if a task is grabbing > another lock, it messes up the order. For example, it can do the > following: L1->P1->L2->P2->L1 if L1 is the BKL. Luckly, (and I guess > there's really no other way) the BKL is only held by those that are > currently running, or at least not blocked on anyone. So I added code > in the pi_setprio code to test if the next lock in the loop is the BKL > and if so, if its owner is the current task. If so, the loop is > broken. > > Without this patch, I would constantly get lock ups on shutdown where > it sends SIGTERM to all the processes. It usually would lock up on > the killing of udev. But with the patch, I've shutdown a few times > already and no lockups so far. thanks, applied. Ingo - 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.13-rc7-rt4, fails to build
* Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > On Mon, 2005-08-29 at 01:35, Ingo Molnar wrote: > > * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > > > > > I'm getting a build error for 2.6.13-rc7-rt4 with PREEMPT_DESKTOP for > > > i386: > > > > hm, cannot reproduce this build problem on my current tree - could you > > try 2.6.13-rt1? (and please send the 2.6.13-rt1 .config if it still > > occurs) > > I had to redo two chunks (this also happened to me in rc7-rt3): hm, what is the problem with these two chunks? (they apply fine here, and the patched file builds fine too.) Ingo - 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: Ignore disabled ROM resources at setup
From: Jon Smirl <[EMAIL PROTECTED]> Date: Tue, 30 Aug 2005 00:35:11 -0400 > As far as I can tell no one has built recent hardware this way. But I > believe there are some old SCSI controllers that do this. I provided a > ROM API for disabling sysfs access, if we identify one of these cards > we should just add a call to it's driver to disable ROM access instead > of bothering with the copy. Currently the copy is not being used > anywhere in the kernel. Qlogic ISP is one such card, but there are several others. I think enabling the ROM is a very bad idea, since we in fact know it disables the I/O and MEM space decoders on a non-empty set of PCI cards. - 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: Ignore disabled ROM resources at setup
On Tue, 30 Aug 2005, Benjamin Herrenschmidt wrote:
>
> I was just testing a slightly different one that appear to fix the
> problem :
...
> + rom_addr = region.start | (res->flags & PCI_REGION_FLAG_MASK);
I worry about this one. It's not really correct. The low en bits are
"reserved", and while I don't know whether writing zero is always correct,
I do know that just writing the low 4 bits with the old value is a bit
strange. And the flags don't save the other bits.
So I'd prefer either my previous diff, or one that just re-reads the bits
entirely, something like the appended..
What does the PCI spec say about the reserved bits? Do we have to save
them?
Linus
---
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -24,9 +24,16 @@
static void pci_enable_rom(struct pci_dev *pdev)
{
u32 rom_addr;
+ struct resource *res = pdev->resource + PCI_ROM_RESOURCE;
+ struct pci_bus_region region;
+ if (!res->flags)
+ return;
+
+ pcibios_resource_to_bus(pdev, , res);
pci_read_config_dword(pdev, pdev->rom_base_reg, _addr);
- rom_addr |= PCI_ROM_ADDRESS_ENABLE;
+ rom_addr &= ~PCI_ROM_ADDRESS_MASK;
+ rom_addr |= region.start | PCI_ROM_ADDRESS_ENABLE;
pci_write_config_dword(pdev, pdev->rom_base_reg, rom_addr);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Ignore disabled ROM resources at setup
On Tue, 30 Aug 2005, Jon Smirl wrote: > > I was reading the status out of the PCI config space to account for > our friend X which enables ROMs without informing the OS. With X > around PCI config space can get out of sync with the kernel > structures. Well, yes, except that we use the in-kernel resource address for the actual ioremap() _anyway_ in the routine that calls this, so if X has remapped the ROM somewhere else, that wouldn't work in the first place. I'm sure X plays games with this register (I suspect that's why the Matrox thing broke in the first place), but I don't think it should do so while the kernel uses it. I don't think we have much choice anyway. See above. 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/
Re: Ignore disabled ROM resources at setup
On Tue, 30 Aug 2005, Benjamin Herrenschmidt wrote: > > So what about fixing pci_map_rom() to call pcibios_resource_to_bus() and > then write the resource back to the BAR ? I'm still a bit annoyed that > we re-allocate the address while the original one was perfectly good > (though not enabled) but the above would work. I just sent you a patch to try. Btw, as to the re-allocation of an existing address: most of the PCI layer really does try to avoid re-allocating known good addresses. In fact, I thought we did so for ROM resources too: at least pci_read_bases() does read the ROM base, and saves it off into the resource structure. We'll end up re-assigning that saved-off-address if there were resource clashes, though. And bugs always happen, especially since that code doesn't get much testing on x86 (there are almost never any interesting rom resources for _any_ device, and apparently the video device which is one of the few interesting ones always ends up using the shadow rom thing on x86 for the primary card). If you find the thing that causes us to re-assign the address, holler. (See drivers/pci/probe.c: pci_read_bases() for the code that probes the old address and saves it into the resource struct. It's called by pci_setup_device() from the device scanning routines). 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/
Re: Ignore disabled ROM resources at setup
> > I was reading the status out of the PCI config space to account for > our friend X which enables ROMs without informing the OS. With X > around PCI config space can get out of sync with the kernel > structures. Well, X isn't supposed to keep the ROM enabled is it ? besides, most of the time, the kernel code will be run at boot. I think we shouldn't care here. If X does the wrong thing, it will eventually break but it shouldn't break in the "normal" case and it will ultimately be fixed (finger crossed) by R7.1 Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.4.30-hf2
On Mon, Aug 29, 2005 at 10:29:00AM +0200, Ake wrote: > I got the following Oops. > Known problem? Fix? Nothing known here. You can retry with -hf7 if you want, which fixes other bugs, but I guess it will not change anything. > The kernel is a plain 2.4.30-hf2 I have some question : what is /usr/opt/scali/kernel/scip/scip.o ? Isn't it a binary module ? It does not seem to belong to the plain 2.4.30-hf2. > EIP:0010:[]Tainted: PF > Warning (expand_objects): object /usr/opt/scali/kernel/scip/scip.o for module > scip has changed since load Is this oops reproducible ? is it reproducible without any binary module ? 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/
Re: Ignore disabled ROM resources at setup
On 8/30/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 29 Aug 2005, David S. Miller wrote:
> >
> > So I think the kernel, by not enabling the ROM, is doing the
> > right thing here.
>
> Notice that on ppc even older versions didn't actually _enable_ the rom,
> but they would write the non-enabled address to the PCI_ROM_ADDRESS
> register, so that anybody who read that register would see _where_ the ROM
> would be enabled if it was enabled.
>
> That's the thing that changed in the commit Ben dislikes. Now, if the ROM
> is disabled, we won't even write the disabled address to the PCI register,
> because it led to trouble on some strange Matrox card. Probably a card
> that nobody has ever used on PPC, and certainly not on a Powerbook, so in
> that sense the apparent breakage on ppc is arguably "unnecessary" as far
> as Ben is concerned.
>
> But I notice the problem: pci_enable_rom() is indeed broken with the
> change.
>
> Ben, does this (totally untested) patch fix it for you?
>
> Linus
>
>
> diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
> --- a/drivers/pci/rom.c
> +++ b/drivers/pci/rom.c
> @@ -23,11 +23,14 @@
> */
> static void pci_enable_rom(struct pci_dev *pdev)
> {
> - u32 rom_addr;
> + struct resource *res = pdev->resource + PCI_ROM_RESOURCE;
> + struct pci_bus_region region;
>
> - pci_read_config_dword(pdev, pdev->rom_base_reg, _addr);
> - rom_addr |= PCI_ROM_ADDRESS_ENABLE;
> - pci_write_config_dword(pdev, pdev->rom_base_reg, rom_addr);
> + if (!res->flags)
> + return;
> +
> + pcibios_resource_to_bus(pdev, , res);
> + pci_write_config_dword(pdev, pdev->rom_base_reg, region.start |
> PCI_ROM_ADDRESS_ENABLE);
> }
I was reading the status out of the PCI config space to account for
our friend X which enables ROMs without informing the OS. With X
around PCI config space can get out of sync with the kernel
structures.
>
> /**
> -
> 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/
>
--
Jon Smirl
[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: Ignore disabled ROM resources at setup
On Mon, 2005-08-29 at 21:40 -0700, Linus Torvalds wrote:
>
> On Mon, 29 Aug 2005, David S. Miller wrote:
> >
> > So I think the kernel, by not enabling the ROM, is doing the
> > right thing here.
>
> Notice that on ppc even older versions didn't actually _enable_ the rom,
> but they would write the non-enabled address to the PCI_ROM_ADDRESS
> register, so that anybody who read that register would see _where_ the ROM
> would be enabled if it was enabled.
>
> That's the thing that changed in the commit Ben dislikes. Now, if the ROM
> is disabled, we won't even write the disabled address to the PCI register,
> because it led to trouble on some strange Matrox card. Probably a card
> that nobody has ever used on PPC, and certainly not on a Powerbook, so in
> that sense the apparent breakage on ppc is arguably "unnecessary" as far
> as Ben is concerned.
>
> But I notice the problem: pci_enable_rom() is indeed broken with the
> change.
>
> Ben, does this (totally untested) patch fix it for you?
I was just testing a slightly different one that appear to fix the
problem :
Index: linux-work/drivers/pci/rom.c
===
--- linux-work.orig/drivers/pci/rom.c 2005-08-01 22:03:44.0 +1000
+++ linux-work/drivers/pci/rom.c2005-08-30 14:46:26.0 +1000
@@ -23,9 +23,12 @@
*/
static void pci_enable_rom(struct pci_dev *pdev)
{
+ struct pci_bus_region region;
+ struct resource *res = >resource[PCI_ROM_RESOURCE];
u32 rom_addr;
- pci_read_config_dword(pdev, pdev->rom_base_reg, _addr);
+ pcibios_resource_to_bus(pdev, , res);
+ rom_addr = region.start | (res->flags & PCI_REGION_FLAG_MASK);
rom_addr |= PCI_ROM_ADDRESS_ENABLE;
pci_write_config_dword(pdev, pdev->rom_base_reg, rom_addr);
}
@@ -71,12 +74,17 @@
} else {
if (res->flags & IORESOURCE_ROM_COPY) {
*size = pci_resource_len(pdev, PCI_ROM_RESOURCE);
- return (void __iomem *)pci_resource_start(pdev,
PCI_ROM_RESOURCE);
+ return (void __iomem *)pci_resource_start(pdev,
+PCI_ROM_RESOURCE);
} else {
/* assign the ROM an address if it doesn't have one */
- if (res->parent == NULL)
- pci_assign_resource(pdev, PCI_ROM_RESOURCE);
-
+ if (res->parent == NULL) {
+ int err;
+ err = pci_assign_resource(pdev,
+ PCI_ROM_RESOURCE);
+ if (err)
+ return NULL;
+ }
start = pci_resource_start(pdev, PCI_ROM_RESOURCE);
*size = pci_resource_len(pdev, PCI_ROM_RESOURCE);
if (*size == 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: Ignore disabled ROM resources at setup
On 8/29/05, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Tue, 30 Aug 2005, Benjamin Herrenschmidt wrote: > > > > pci_map_rom "sees" that the resource is unassigned by testing the parent > > pointer, and calls pci_assign_resource() which, with this new patch, > > will do nothing. > > Ehh.. It didn't do anything with the old code either for that case, so > there's apparently something else also going on. > > It would write the base address, but since it wouldn't _enable_ the ROM > mapping (only the "non-enabled" case changed by this commit), the end > result from a hw standpoint should be exactly the same: the ROM isn't > actually mapped. > > So after pci_assign_resource(), the resource has literally been assigned, > but that patch should not have mattered in any way whether it was actually > _enabled_ or not. > > Now, there's clearly a difference. What has always worked is then to do > > pci_write_config_dword(dev, > PCI_ROM_ADDRESS, > PCI_ROM_ADDRESS_ENABLE | res->start) > > (well, these days you're supposed to use "pcibios_resource_to_bus()" to > get the start value to write out). > > Much preferable is probably to just enable the resource manually _before_ > calling pci_assign_resource, ie do something like. > > dev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_ENABLE; > pci_assign_resource(dev, PCI_ROM_RESOURCE); > > But yes, if something used to just blindly set PCI_ROM_ADDRESS_ENABLE, > then that got broken. I grepped for that and didn't see anything like it, > but I guess people are doing it with the magic constant "1".. Nothing in the driver tree should be using PCI_ROM_ADDRESS_ENABLE except drivers/pci/*. Drivers that are still manipulating ROMs directly should be converted to use the PCI ROM API. I started to fix these but some of the use is non-obvious. It is best if the maintainers do it. These files are still directly manipulating ROMs: ide/pci/aec62xx.c ide/pci/cmd64x.c ide/pci/hpt34x.c ide/pci/hpt366.c ide/pci/pdc202xx_new. ide/pci/pdc202xx_old.c mtd/maps/pci.c net/sungem.c net/sunhme.c scsi/qla2xxx/qla_init.c video/console/sticore.c video/matrox/matroxfb_misc.c video/sis/sis_main.c -- Jon Smirl [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][FAT] FAT dirent scan with hin take #2
Here is a revised version of dirent scan patch, mentioned at
following E-mail.
This patch addresses performance damages on "ls | xargs xxx" and
reverse order scan which are reported to the previous patch.
With this patch, fat_search_long() and fat_scan() use hint value
as start of scan. For each directory holds multiple hint value entries.
The entry would be selected by hash value based on scan target name and
PID. Hint value would be calculated based on the entry previously found
entry, so that the hint can cover backward neighborhood.
This patch is for 2.6.12, because I tested it at the last weekend...
Machida, Hiroyuki wrote:
>
> As I said in "[RFC] FAT dirent scan with hint"
> <[EMAIL PROTECTED]>, we realized that FAT/VFAT has
> poor performance with scanning directory entries.
>
> Per discussions with Ogawa-san, VFAT maintainer, I took profiling data
> to seek better solution. Here are results attached.
>
> In short, I would say we need to reduce following factors.
> a) number of iterations inside fat_search_long()
> b) number of callings to uni16_to_x8()
> c) number of callings to fat__get_entry(), for short name scan.
>
> In another E-mail, I'll send revised version patch which use hint
> values to scan dirent. That patch would reduce number of iterations
> inside fat_search_long() and fat_scan(). Those contributes reductions
> above a)-c) factors.
>
:
snip
:
--
Hiroyuki Machida[EMAIL PROTECTED]
SSW Dept. HENC, Sony Corp.
This patch enables using hint nformation on scanning dir.
It reaches excelent performance with "ls -l" for over 1000 entries.
* fat-dirscan-with-hint.patch
fs/fat/dir.c | 133 ---
fs/fat/inode.c | 13
include/linux/msdos_fs.h |2
3 files changed, 140 insertions(+), 8 deletions(-)
Signed-off-by: Hiroyuki Machida <[EMAIL PROTECTED]> for CELF
* modified files
--- old/include/linux/msdos_fs.h2005-08-29 09:38:53.308587787 +0900
+++ new/include/linux/msdos_fs.h2005-08-29 09:39:33.889555606 +0900
@@ -255,6 +255,8 @@ struct msdos_inode_info {
/* for avoiding the race between fat_free() and fat_get_cluster() */
unsigned int cache_valid_id;
+ struct semaphore *scan_lock;/* lock for dirscan hints */
+ loff_t *scan_hints; /* dirscan hints */
loff_t mmu_private;
int i_start;/* first cluster or 0 */
int i_logstart; /* logical first cluster */
--- old/fs/fat/dir.c2005-08-29 09:38:53.158584210 +0900
+++ new/fs/fat/dir.c2005-08-29 09:39:33.889555606 +0900
@@ -201,6 +201,91 @@ fat_shortname2uni(struct nls_table *nls,
* Return values: negative -> error, 0 -> not found, positive -> found,
* value is the total amount of slots, including the shortname entry.
*/
+
+#define FAT_SCAN_SHIFT 4 /* 2x8 way scan hints */
+#define FAT_SCAN_NWAY (1scan_lock);
+ if (MSDOS_I(dir)->scan_hints) err = -EINVAL;
+ if (!err) MSDOS_I(dir)->scan_hints = hints;
+ up(_I(dir)->scan_lock);
+ if (err == -EINVAL) {
+ if (hints) kfree(hints);
+ err = 0;
+ }
+ }
+ return err;
+}
+
+
+inline
+static void hint_record(struct inode *dir, struct fat_slot_info *sinfo,
+ int hindex)
+{
+ loff_t under_scan_off, nent;
+
+ nent = (dir->i_size > PAGE_SIZE ? dir->i_size : PAGE_SIZE)
+ / sizeof(struct msdos_dir_entry);
+
+ /* educational guess; try to cover 1/4 previous range */
+ nent >>= (FAT_SCAN_SHIFT + 2);
+ under_scan_off = nent * sizeof(struct msdos_dir_entry);
+
+ if (sinfo->slot_off > under_scan_off)
+ MSDOS_I(dir)->scan_hints[hindex] =
+ sinfo->slot_off - under_scan_off;
+ else
+ MSDOS_I(dir)->scan_hints[hindex] = 0;
+}
+
+
+inline
+static int hint_index_body(const unsigned char *name, int name_len, int
check_null)
+{
+ int i;
+ int val = 0;
+ unsigned char *p = (unsigned char *) name;
+ int id = current->pid;
+
+ for (i=0; i> 8) & 0xf) ^ (id & 0xf);
+ val = (val << 1) | (id & 1);
+ return val & (FAT_SCAN_NWAY-1);
+}
+
+inline
+static int lfn_hint_index(const unsigned char *name, int name_len)
+{
+ return hint_index_body(name, name_len, 0);
+}
+
+inline
+static int hint_index(const unsigned char *name)
+{
+ return hint_index_body(name, MSDOS_NAME, 1);
+}
+
int fat_search_long(struct inode *inode, const unsigned char *name,
[PATCH] cpm_uart: use schedule_timeout instead of direct call to schedule
use schedule_timeout instead of direct call to schedule
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
commit 85e29936d8eab1c16120ab319cc50828f3863aba
tree a6fbb48fc860c6f5dbef0d518a500b37576caf40
parent b9ecc8e4b5db64f0b4ee36dbdd6758e4ce3c2025
author Kumar K. Gala <[EMAIL PROTECTED]> Mon, 29 Aug 2005 23:46:59 -0500
committer Kumar K. Gala <[EMAIL PROTECTED]> Mon, 29 Aug 2005 23:46:59 -0500
drivers/serial/cpm_uart/cpm_uart_core.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -403,10 +403,8 @@ static int cpm_uart_startup(struct uart_
inline void cpm_uart_wait_until_send(struct uart_cpm_port *pinfo)
{
- unsigned long target_jiffies = jiffies + pinfo->wait_closing;
-
- while (!time_after(jiffies, target_jiffies))
- schedule();
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(pinfo->wait_closing);
}
/*
@@ -425,9 +423,12 @@ static void cpm_uart_shutdown(struct uar
/* If the port is not the console, disable Rx and Tx. */
if (!(pinfo->flags & FLAG_CONSOLE)) {
/* Wait for all the BDs marked sent */
- while(!cpm_uart_tx_empty(port))
+ while(!cpm_uart_tx_empty(port)) {
+ set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(2);
- if(pinfo->wait_closing)
+ }
+
+ if (pinfo->wait_closing)
cpm_uart_wait_until_send(pinfo);
/* Stop uarts */
-
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] cpm_uart: Fix baseaddress for SMC 1 and 2
Base addess register for SMC 1 and 2 are never initialized. This means that they will not work unless a bootloader already configured them. The DPRAM already have space reserved, this patch just makes sure the base addess register is updated correctly on initialization. Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- commit b9ecc8e4b5db64f0b4ee36dbdd6758e4ce3c2025 tree c6d9da4a2bec187d4fc794b91441323c04642dda parent 66256c2b92e3edafca1e86e64fcffe5c72cc39e7 author Kumar K. Gala <[EMAIL PROTECTED]> Mon, 29 Aug 2005 23:30:56 -0500 committer Kumar K. Gala <[EMAIL PROTECTED]> Mon, 29 Aug 2005 23:30:56 -0500 drivers/serial/cpm_uart/cpm_uart_cpm2.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c --- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c +++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c @@ -266,6 +266,7 @@ int cpm_uart_init_portdesc(void) cpm_uart_ports[UART_SMC1].smcp = (smc_t *) & cpm2_immr->im_smc[0]; cpm_uart_ports[UART_SMC1].smcup = (smc_uart_t *) & cpm2_immr->im_dprambase[PROFF_SMC1]; + *(u16 *)(_immr->im_dprambase[PROFF_SMC1_BASE]) = PROFF_SMC1; cpm_uart_ports[UART_SMC1].port.mapbase = (unsigned long)_immr->im_smc[0]; cpm_uart_ports[UART_SMC1].smcp->smc_smcm |= (SMCM_RX | SMCM_TX); @@ -278,6 +279,7 @@ int cpm_uart_init_portdesc(void) cpm_uart_ports[UART_SMC2].smcp = (smc_t *) & cpm2_immr->im_smc[1]; cpm_uart_ports[UART_SMC2].smcup = (smc_uart_t *) & cpm2_immr->im_dprambase[PROFF_SMC2]; + *(u16 *)(_immr->im_dprambase[PROFF_SMC2_BASE]) = PROFF_SMC2; cpm_uart_ports[UART_SMC2].port.mapbase = (unsigned long)_immr->im_smc[1]; cpm_uart_ports[UART_SMC2].smcp->smc_smcm |= (SMCM_RX | SMCM_TX); - 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 8/8] PCI Error Recovery: PPC64 core recovery routines
Linas Vepstas writes: > > One way to clean this up would be to make rpaphp the driver for the > > EADS bridges (from the pci code's point of view). > > I guess I don't understand what that means. Are you suggesting moving > pSeries_pci.c into the rpaphp code directory? No, not at all. :) I'm suggesting that the rpaphp code has a struct pci_driver whose id_table and probe function are such that it will claim the EADS bridges. (It would probably be best to match on vendor=IBM and class=PCI-PCI bridge and let the probe function figure out which of the bridges it gets asked about are actually EADS bridges.) > I would prefer to deprecate the hot-plug based recovery scheme. This > is for many reasons, including the fact that some devices that can get > pci errors are soldered onto the planar, and are not hot-pluggable. Those devices can still be isolated and reset, can they not? And they still have an EADS bridge above them, don't they? Are there any that can't be dynamically reassigned from one partition to another? I.e., they may not be physically hotpluggable but they are still virtually hotpluggable as far as the partition is concerned, IIUC. 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/
2.6.13 kernel OOPS
Hi, Is this a known problem? Thanks, Martin cat /proc/sys/net/ipv4/conf/lo/rp_filter <1>Unable to handle kernel paging request at virtual address 419a91d8 printing eip: c0116644 *pde = Oops: [#6] Modules linked in: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010246 (2.6.13) EIP is at do_proc_dointvec_conv+0x14/0x40 eax: c1b40f28 ebx: ecx: 419a91d8 edx: c1b40f24 esi: 1000 edi: 0001 ebp: 0804d008 esp: c1b40eec ds: 007b es: 007b ss: 0068 Process cat (pid: 503, threadinfo=c1b4 task=c22245d0) Stack: c0116731 419a91d8 0001 c1b40fbc c22245d0 c1b656a4 00030002 c1b40f0b c2242b84 c1b656a4 c1e12420 0804d008 c12910e0 c01169a5 0804d008 c1b40f64 c1b40fa4 Call Trace: [] do_proc_dointvec+0xc1/0x320 [] proc_dointvec+0x15/0x20 [] do_proc_dointvec_conv+0x0/0x40 [] do_rw_proc+0x6e/0x80 [] proc_readsys+0x0/0x20 [] proc_readsys+0x10/0x20 [] vfs_read+0x7e/0x140 [] sys_read+0x3c/0x70 [] syscall_call+0x7/0xb Code: 00 00 83 c4 0c 89 c8 5b 5e 5f 5d c3 8d 74 26 00 8d bc 27 00 00 00 00 83 7c 24 04 00 74 0d 8b 00 85 c0 75 18 8b 02 89 01 31 c0 c3 <8b> 09 85 c9 78 16 c7 00 00 00 00 00 31 c0 89 0a c3 8b 02 f7 d8 bash-2.05$ /bld/linux-2.6.13/scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux shadow 2.6.12 #1 SMP Sat Jun 18 09:36:33 CDT 2005 i686 unknown unknown GNU/Linux Gnu C 4.0.0 Gnu make 3.80 binutils 2.15 util-linux 2.12q mount 2.12q module-init-tools 3.0-pre2 e2fsprogs 1.35 reiserfsprogs reiserfsck: reiser4progs fsck.reiser4: pcmcia-cs 3.2.8 nfs-utils 0.1.5 Linux C Library2.3.4 Dynamic linker (ldd) 2.3.4 Linux C++ Library 6.0.4 Procps 3.2.5 Net-tools 1.60 Kbd1.12 Sh-utils 5.2.1 udev 048 Modules Loaded bash-2.05$ - 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: Ignore disabled ROM resources at setup
On Mon, 2005-08-29 at 21:20 -0700, David S. Miller wrote: > From: Linus Torvalds <[EMAIL PROTECTED]> > Date: Mon, 29 Aug 2005 21:09:24 -0700 (PDT) > > > So 2.6.13 is being "safe". It allocates the space for the ROM in the > > resource tables, but it neither enables it nor does it write the > > (disabled) address out to the device, since both of those actions have > > been shown to break on PC's. And sadly (or happily, depends on your > > viewpoint), PC's have a _much_ wider range of hardware, so they are the > > ones we have to work around. > > Actually, I can tell you that it is a known fact that Qlogic ISP > PCI cards will not respond to I/O and MEM space when you enable > the ROM. And this behavior exists in quite a few other PCI parts > as well. Yes, including Matrox cards. > So I think the kernel, by not enabling the ROM, is doing the > right thing here. It is, the problem is that not only it doesn't enable it, but it also doesn't write the resource to the BAR, which triggers a bug in pci_map_rom which then enables the decoding but doesn't update the BAR with the new address neither. Note also the, imho totally broken, code in pci_map_rom_copy() which is supposed to keep a cached copy of the ROM in memory specifically for these cards to have an easier access afterward (or for sysfs rom file access to work). I think that code should have a pointer in pci_dev for the cache instead of stuffing a kernel virtual address in the middle of the resouce tree. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ignore disabled ROM resources at setup
On Mon, 29 Aug 2005, David S. Miller wrote:
>
> So I think the kernel, by not enabling the ROM, is doing the
> right thing here.
Notice that on ppc even older versions didn't actually _enable_ the rom,
but they would write the non-enabled address to the PCI_ROM_ADDRESS
register, so that anybody who read that register would see _where_ the ROM
would be enabled if it was enabled.
That's the thing that changed in the commit Ben dislikes. Now, if the ROM
is disabled, we won't even write the disabled address to the PCI register,
because it led to trouble on some strange Matrox card. Probably a card
that nobody has ever used on PPC, and certainly not on a Powerbook, so in
that sense the apparent breakage on ppc is arguably "unnecessary" as far
as Ben is concerned.
But I notice the problem: pci_enable_rom() is indeed broken with the
change.
Ben, does this (totally untested) patch fix it for you?
Linus
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -23,11 +23,14 @@
*/
static void pci_enable_rom(struct pci_dev *pdev)
{
- u32 rom_addr;
+ struct resource *res = pdev->resource + PCI_ROM_RESOURCE;
+ struct pci_bus_region region;
- pci_read_config_dword(pdev, pdev->rom_base_reg, _addr);
- rom_addr |= PCI_ROM_ADDRESS_ENABLE;
- pci_write_config_dword(pdev, pdev->rom_base_reg, rom_addr);
+ if (!res->flags)
+ return;
+
+ pcibios_resource_to_bus(pdev, , res);
+ pci_write_config_dword(pdev, pdev->rom_base_reg, region.start |
PCI_ROM_ADDRESS_ENABLE);
}
/**
-
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: Ignore disabled ROM resources at setup
> What you want is a "zombie state", where we write the partial information > to hardware. It's what we used to do, but it's certainly no more logical > than what it does now, and it led to problem reports. > > Btw, why does this happen on powerpc, but not x86? I'm running a radeon > laptop right now myself. Hmm.. It's using the RAM shadow at c on these ... I'm still not convinced that having the struct resource allocated and mismatched with the BAR value is a good thing... But anyway, so the bug would then be pci_map_rom who is writing the enable bit without fixing the rest of the BAR... So what about fixing pci_map_rom() to call pcibios_resource_to_bus() and then write the resource back to the BAR ? I'm still a bit annoyed that we re-allocate the address while the original one was perfectly good (though not enabled) but the above would work. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ignore disabled ROM resources at setup
On 8/29/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > While looking there, I also noticed pci_map_rom_copy() stuff and I'm > surprised it was ever accepted in the tree. While I can understand that > we might need to keep a cached copy of the ROM content (due to cards > like matrox who can't enable both the ROM and the BARs among other > issues), the whole idea of whacking a kernel virtual pointer in the > struct resource->start of the ROM bar is just too disgusting for words > and will probably cause "intersting" side effects in /proc, sysfs and > others... Shouldn't we just have a pointer in pci_dev for the optional > "ROM cache" instead ? We should just delete the ROM copy stuff. It is there because the PCI spec allows for the ROM address decoder to be reused and the PCI people wanted it for completeness. It is legal to build a card that uses the address decoder to get at the ROM, then when the ROM was run it would set the same address decoder to decode other hardware on the card. You need to copy the ROM since once the decoder is changed you can't get to the ROM any more. As far as I can tell no one has built recent hardware this way. But I believe there are some old SCSI controllers that do this. I provided a ROM API for disabling sysfs access, if we identify one of these cards we should just add a call to it's driver to disable ROM access instead of bothering with the copy. Currently the copy is not being used anywhere in the kernel. -- Jon Smirl [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: [PATCH] MPC8xx PCMCIA driver
Marcelo Tosatti wrote:
On Mon, Aug 29, 2005 at 11:39:02PM -0400, Jeff Garzik wrote:
Marcelo Tosatti wrote:
+static int voltage_set(int slot, int vcc, int vpp)
+{
+ u_int reg = 0;
+
+ switch(vcc) {
+ case 0: break;
+ case 33:
+ reg |= BCSR1_PCVCTL4;
+ break;
+ case 50:
+ reg |= BCSR1_PCVCTL5;
+ break;
+ default:
+ return 1;
+ }
+
+ switch(vpp) {
+ case 0: break;
+ case 33:
+ case 50:
+ if(vcc == vpp)
+ reg |= BCSR1_PCVCTL6;
+ else
+ return 1;
+ break;
+ case 120:
+ reg |= BCSR1_PCVCTL7;
+ default:
+ return 1;
+ }
+
+ if(!((vcc == 50) || (vcc == 0)))
+ return 1;
+
+ /* first, turn off all power */
+
+ *((uint *)RPX_CSR_ADDR) &= ~(BCSR1_PCVCTL4 | BCSR1_PCVCTL5
+| BCSR1_PCVCTL6 | BCSR1_PCVCTL7);
+
+ /* enable new powersettings */
+
+ *((uint *)RPX_CSR_ADDR) |= reg;
Should use bus read/write functions, such as foo_readl() or iowrite32().
The memory map structure which contains device configuration/registers
is _always_ directly mapped with pte's (the 8xx is a chip with builtin
UART/network/etc functionality).
I don't think there is a need to use read/write acessors.
There are multiple reasons:
* Easier reviewing. One cannot easily distinguish between writing to
normal kernel virtual memory and "magic" memory that produces magicaly
side effects such as initiating DMA of a net packet.
* Compiler safety. As the code is written now, you have no guarantees
that the compiler won't combine two stores to the same location, etc.
Accessor macros are a convenient place to add compiler barriers or
'volatile' notations that the MPC8xx code lacks.
* Maintainable. foo_read[bwl] or foo_read{8,16,32} are preferred
because that's the way other bus accessors look like -- yes even
embedded SoC buses benefit from these code patterns. You want your
driver to look like other drivers as much as possible.
* Convenience. The accessors can be a zero overhead memory read/write
at a minimum. But they can also be convenient places to use special
memory read/write instructions that specify uncached memop, compiler
barriers, memory barriers, etc.
Regards,
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MPC8xx PCMCIA driver
Marcelo Tosatti writes: > The memory map structure which contains device configuration/registers > is _always_ directly mapped with pte's (the 8xx is a chip with builtin > UART/network/etc functionality). > > I don't think there is a need to use read/write acessors. Generally on PowerPC you need to use at least the eieio instruction to prevent reordering of the loads and stores to the device. It's possible that 8xx is sufficiently in-order that you get away without putting in barrier instructions (eieio or sync), but it's not good practice to omit them. You can use accessors such as in_be32 and in_le32 in this situation, when you have a kernel virtual address that is already mapped to the device. Regards, 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: [PATCH] ppc32 :Added PCI support for MPC83xx
Hmm, well the PCI spec seems to be clear on the fact that PCI
interrupts should be level sensitive.
- kumar
On Aug 29, 2005, at 10:02 PM, Li Tony-r64360 wrote:
I think it is OK. The external interrupt can be edged. And it works
well
in my board.
Tony Li
-Original Message-
From: Gala Kumar K.-galak
Sent: Tuesday, August 30, 2005 1:43 AM
To: Li Tony-r64360
Cc: linuxppc-embedded; linux-kernel@vger.kernel.org; Gala Kumar
K.-galak; Chu hanjin-r52514
Subject: Re: [PATCH] ppc32 :Added PCI support for MPC83xx
I noticed that you aren't updating the senses array in
mpc834x_sys_init_IRQ for the PCI interrupt lines, is this correct?
Should they not be IRQ_SENSE_LEVEL?
Also, I've done a bit of cosmetic cleanup to the patch, take a look
and
let me know if it works. Once we close on the IRQ sense issue I will
send this upstream.
- kumar
---
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -713,6 +713,12 @@ config MPC834x_SYS
help
This option enables support for the MPC 834x SYS evaluation
board.
+ Be aware that PCI buses can only function when SYS board is
plugged on
+ PIB (Platform IO Board) board from Freescale which provide 3
PCI slots.
+ Just like PC,the board level initalization is bootloader`s
responsiblilty.
+ The PCI deponds on bootloader configurate board corretly.
Refer to Freescale
+ to get more information about this.
+
endchoice
config PQ2ADS
@@ -1193,6 +1199,11 @@ config PCI
config PCI_DOMAINS
bool
default PCI
+
+config MPC83xx_PCI2
+bool " Supprt for 2nd PCI host controller"
+depends on PCI && MPC834x
+default y if MPC834x_SYS
config PCI_QSPAN
bool "QSpan PCI"
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c
b/arch/ppc/platforms/83xx/mpc834x_sys.c
--- a/arch/ppc/platforms/83xx/mpc834x_sys.c
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
@@ -62,9 +62,29 @@ extern unsigned long total_memory;/* in
unsigned char __res[sizeof (bd_t)];
#ifdef CONFIG_PCI
-#error "PCI is not supported"
-/* NEED mpc83xx_map_irq & mpc83xx_exclude_device
- see platforms/85xx/mpc85xx_ads_common.c */
+int
+mpc83xx_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned
char
+pin) {
+static char pci_irq_table[][4] =
+/*
+ * PCI IDSEL/INTPIN->INTLINE
+ * A B C D
+ */
+{
+{PIRQA, PIRQB, PIRQC, PIRQD}, /* idsel 0x11 */
+{PIRQC, PIRQD, PIRQA, PIRQB}, /* idsel 0x12 */
+{PIRQD, PIRQA, PIRQB, PIRQC} /* idsel 0x13 */
+};
+
+const long min_idsel = 0x11, max_idsel = 0x13, irqs_per_slot =
4;
+return PCI_IRQ_TABLE_LOOKUP;
+}
+
+int
+mpc83xx_exclude_device(u_char bus, u_char devfn) {
+return PCIBIOS_SUCCESSFUL;
+}
#endif /* CONFIG_PCI */
/*
**
**
@@ -88,7 +108,7 @@ mpc834x_sys_setup_arch(void)
#ifdef CONFIG_PCI
/* setup PCI host bridges */
-mpc83xx_sys_setup_hose();
+mpc83xx_setup_hose();
#endif
mpc83xx_early_serial_map();
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.h
b/arch/ppc/platforms/83xx/mpc834x_sys.h
--- a/arch/ppc/platforms/83xx/mpc834x_sys.h
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.h
@@ -26,7 +26,7 @@
#define VIRT_IMMRBAR((uint)0xfe00)
#define BCSR_PHYS_ADDR((uint)0xf800)
-#define BCSR_SIZE((uint)(32 * 1024))
+#define BCSR_SIZE((uint)(128 * 1024))
#define BCSR_MISC_REG2_OFF0x07
#define BCSR_MISC_REG2_PORESET0x01
@@ -34,23 +34,25 @@
#define BCSR_MISC_REG3_OFF0x08
#define BCSR_MISC_REG3_CNFLOCK0x80
-#ifdef CONFIG_PCI
-/* PCI interrupt controller */
-#define PIRQAMPC83xx_IRQ_IRQ4
-#define PIRQBMPC83xx_IRQ_IRQ5
-#define PIRQCMPC83xx_IRQ_IRQ6
-#define PIRQDMPC83xx_IRQ_IRQ7
-
-#define MPC834x_SYS_PCI1_LOWER_IO0x
-#define MPC834x_SYS_PCI1_UPPER_IO0x00ff
-
-#define MPC834x_SYS_PCI1_LOWER_MEM 0x8000
-#define MPC834x_SYS_PCI1_UPPER_MEM 0x9fff
-
-#define MPC834x_SYS_PCI1_IO_BASE 0xe200
-#define MPC834x_SYS_PCI1_MEM_OFFSET 0x
-
-#define MPC834x_SYS_PCI1_IO_SIZE 0x0100
-#endif /* CONFIG_PCI */
+#define PIRQAMPC83xx_IRQ_EXT4
+#define PIRQBMPC83xx_IRQ_EXT5
+#define PIRQCMPC83xx_IRQ_EXT6
+#define PIRQDMPC83xx_IRQ_EXT7
+
+#define MPC83xx_PCI1_LOWER_IO0x
+#define MPC83xx_PCI1_UPPER_IO0x00ff
+#define MPC83xx_PCI1_LOWER_MEM0x8000
+#define MPC83xx_PCI1_UPPER_MEM0x9fff
+#define MPC83xx_PCI1_IO_BASE0xe200
+#define MPC83xx_PCI1_MEM_OFFSET0x
+#define MPC83xx_PCI1_IO_SIZE0x0100
+
+#define MPC83xx_PCI2_LOWER_IO0x
+#define MPC83xx_PCI2_UPPER_IO0x00ff
+#define MPC83xx_PCI2_LOWER_MEM0xa000
+#define MPC83xx_PCI2_UPPER_MEM0xbfff
+#define MPC83xx_PCI2_IO_BASE0xe300
+#define MPC83xx_PCI2_MEM_OFFSET
Re: Ignore disabled ROM resources at setup
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Mon, 29 Aug 2005 21:09:24 -0700 (PDT) > So 2.6.13 is being "safe". It allocates the space for the ROM in the > resource tables, but it neither enables it nor does it write the > (disabled) address out to the device, since both of those actions have > been shown to break on PC's. And sadly (or happily, depends on your > viewpoint), PC's have a _much_ wider range of hardware, so they are the > ones we have to work around. Actually, I can tell you that it is a known fact that Qlogic ISP PCI cards will not respond to I/O and MEM space when you enable the ROM. And this behavior exists in quite a few other PCI parts as well. So I think the kernel, by not enabling the ROM, is doing the right thing here. - 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: ppp_mppe+pptp for 2.6.14?
My problems with ENOPROTOOPT were due to lack of coffee. They were caused by ICMP protocol unreachable responses from the test server because I'd taken away it's pppd. My mistake. On Mon, Aug 29, 2005 at 05:10:34PM -0500, Matt Domsch wrote: > I've asked James Cameron, pptp project lead, to try a test to force > the server side to issue a CCP DOWN, to make sure the client-side > kernel ppp_generic module does the right thing and drops packets. I've tested this now with a host running kernel 2.6.13 with Matt's SC_MUST_COMP patch to the kernel and to ppp 2.4.4b1, sending SIGUSR2 to the pppd while flooding the connection with pings from the server. The result is an LCP TermReq from the server to the client, after which no further data packets appear. All the data packets up to the LCP TermReq are encrypted. The client sends an LCP TermAck, then takes down the interface. There's sign of CCP down, in that a CCP ConfReq appears from the server just after the LCP TermReq. I'm not sure this is an adequate test, and will take advice on that. Test configuration; - server, 2.6.13 + SC_MUST_COMP, ppp 2.4.4b1 + SC_MUST_COMP, pptpd 1.3.1 - client, 2.6.12.5 + SC_MUST_COMP, ppp 2.4.4b1 + SC_MUST_COMP, pptp 1.5.0 Client side pppd log fragment; local IP address 10.8.0.2 remote IP address 10.8.0.1 Script /etc/ppp/ip-up started (pid 5036) Script /etc/ppp/ip-up finished (pid 5036), status = 0x0 rcvd [LCP TermReq id=0x2 "MPPE disabled"] LCP terminated by peer (MPPE disabled) Connect time 0.4 minutes. Sent 262920 bytes, received 262920 bytes. Script /etc/ppp/ip-down started (pid 5048) sent [LCP TermAck id=0x2] rcvd [CCP ConfReq id=0x2 ] Discarded non-LCP packet when LCP not open Script /etc/ppp/ip-down finished (pid 5048), status = 0x0 Connection terminated. Modem hangup -- James Cameron signature.asc Description: Digital signature
Re: Ignore disabled ROM resources at setup
On Mon, 29 Aug 2005, Linus Torvalds wrote: > > What you want is a "zombie state", where we write the partial information > to hardware. It's what we used to do, but it's certainly no more logical > than what it does now, and it led to problem reports. Btw, the fundamental reason for the change is that x86 used to not ever touch any ROM resources _at_all_ by default, unless you used the "pci=rom" kernel command line switch. But that got changed, and in an effort to make x86 more like all the other architectures, it now uses the generic setup-bus stuff (which used to be "generic, but not x86", since the BIOS tends to set up all PCI buses on PC's) that probes all resources (including rom resources) to see how big they are etc. That meant that suddenly the ROM resources _did_ get sized up and written, even if they didn't actually get enabled. So on an x86, 2.6.12 would never touch the ROM resource at all, while for a while in 2.6.13-rc it would write it with a disabled value by default. And that's the thing that broke. So 2.6.13 is being "safe". It allocates the space for the ROM in the resource tables, but it neither enables it nor does it write the (disabled) address out to the device, since both of those actions have been shown to break on PC's. And sadly (or happily, depends on your viewpoint), PC's have a _much_ wider range of hardware, so they are the ones we have to work around. So yes, behaviour changed, but it changed exactly because not changing it leads to problems. So what you will find is that /sbin/lspci actually understands this situation: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA]) ... [virtual] Expansion ROM at 9022 [disabled] [size=128K] ... 30: 00 00 00 00 58 00 00 00 00 00 00 00 0a 01 08 00 Notice how the hardware ROM base at 0x30 is set to "00 00 00 00", but because the resource allocation has been made and the resource shows up in /sys, lspci shows the disabled allocation correctly. That's really how any kernel user will need to understand it too: the allocation exists, but since it's not enabled, the hardware hasn't been told. 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/
Second "CPU" of 1-core HyperThreading CPU not found in 2.6.13
Greetings kind hackers... I recently switched to 2.6.13 on my desktop. I noticed that the second "CPU" (is there a better term to use in this HyperThreading scenario?) that used to be listed in /proc/cpuinfo is no longer present. Browsing over the archives, it appears as if someone else had this problem... their solution was to enable CONFIG_PM, but I already have CONFIG_PM enabled. I have to boot with 'noapic' because I have my CD-Writer hanging off an aic7xxx, and that driver goes into a nice error loop if I boot without it. I'll include some lspci output below in case it is useful. There's one more thing I noticed in the transition to 2.6.13, but I'm really not sure where I could start diagnosing it, and so any suggestions would be marvelous. As I mentioned, this machine is my desktop. In the past, I've been able to run compilers / other intensive tasks while listening to music in XMMS - the playback is never disrupted (indeed, on this P4 3.2ghz XMMS takes virtually none of the processor). Yet I've noticed enough momentary stops in sound output now to begin to suspect I've got some kind of problem. Last kernels that were functional in both regards were 2.6.12.4 and 2.6.11.7. Please note that I have not compiled with the new default tick rate of 250Hz - I'm running 1000Hz, and I have also enabled the Preemptible kernel and BKL Preemption as I have in earlier kernels. turbotaz linux-2.6.13 # lspci -v :00:00.0 Host bridge: Intel Corporation 915G/P/GV/GL/PL/910GL Processor to I/O Controller (rev 04) Subsystem: Intel Corporation 915G/P/GV/GL/PL/910GL Processor to I/O Controller Flags: bus master, fast devsel, latency 0 Capabilities: [e0] #09 [2109] :00:01.0 PCI bridge: Intel Corporation 915G/P/GV/GL/PL/910GL PCI Express Root Port (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: cdf0-cfff Prefetchable memory behind bridge: d000-dfff Expansion ROM at e000 [disabled] [size=4K] Capabilities: [88] #0d [] Capabilities: [80] Power Management version 2 Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [a0] #10 [0141] :00:1b.0 Class 0403: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 03) Subsystem: ASUSTeK Computer Inc.: Unknown device 813d Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at cdbf4000 (64-bit, non-prefetchable) Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [70] #10 [0091] :00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: d000-dfff Expansion ROM at d000 [disabled] [size=4K] Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 :00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: cde0-cdef Prefetchable memory behind bridge: 4000-4000 Expansion ROM at c000 [disabled] [size=4K] Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 :00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc.: Unknown device 80a6 Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 9880 [size=32] :00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc.: Unknown device 80a6 Flags: bus master, medium devsel, latency 0, IRQ 3 I/O ports at 9c00 [size=32] :00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc.: Unknown device 80a6 Flags: bus master, medium devsel, latency 0, IRQ 5 I/O
Re: [PATCH] MPC8xx PCMCIA driver
On Mon, Aug 29, 2005 at 11:39:02PM -0400, Jeff Garzik wrote:
> Marcelo Tosatti wrote:
> >+static int voltage_set(int slot, int vcc, int vpp)
> >+{
> >+u_int reg = 0;
> >+
> >+switch(vcc) {
> >+case 0: break;
> >+case 33:
> >+reg |= BCSR1_PCVCTL4;
> >+break;
> >+case 50:
> >+reg |= BCSR1_PCVCTL5;
> >+break;
> >+default:
> >+return 1;
> >+}
> >+
> >+switch(vpp) {
> >+case 0: break;
> >+case 33:
> >+case 50:
> >+if(vcc == vpp)
> >+reg |= BCSR1_PCVCTL6;
> >+else
> >+return 1;
> >+break;
> >+case 120:
> >+reg |= BCSR1_PCVCTL7;
> >+default:
> >+return 1;
> >+}
> >+
> >+if(!((vcc == 50) || (vcc == 0)))
> >+return 1;
> >+
> >+/* first, turn off all power */
> >+
> >+*((uint *)RPX_CSR_ADDR) &= ~(BCSR1_PCVCTL4 | BCSR1_PCVCTL5
> >+ | BCSR1_PCVCTL6 | BCSR1_PCVCTL7);
> >+
> >+/* enable new powersettings */
> >+
> >+*((uint *)RPX_CSR_ADDR) |= reg;
>
> Should use bus read/write functions, such as foo_readl() or iowrite32().
The memory map structure which contains device configuration/registers
is _always_ directly mapped with pte's (the 8xx is a chip with builtin
UART/network/etc functionality).
I don't think there is a need to use read/write acessors.
> Don't use weird types in kernel code such as 'uint'. Use the more
> explicitly-sized u32.
OK, will fix the types and address the rest of your comments.
Thanks!
-
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: Ignore disabled ROM resources at setup
On Tue, 30 Aug 2005, Benjamin Herrenschmidt wrote: > > Ok, it won't do nothing in fact. It's worse. It will return 0 (success), > will actually assign a completely new address to the resource, will > update the resource structure ... and will _not_ update the PCI resource > BAR for the ROM. > > That is very bad and definitely not what you want, wether it's ppc, x86 > or anything else. Either fail (don't assign the resource at all) or if > you assign it, keep the BAR in sync with the struct resource. I argue that the BAR _is_ in sync with the resource. The resource is allocated, but not enabled. You want to enable it, you need to write the BAR. The fact is, that writing the address (but not the enable bit) to the BAR when it's not enabled leads to problems. It wasn't entirely clear whether the problems were in the X server (possible) or whether it was actual hardware (hey, nothing surprises me any more). So what allocate does is to _allocate_ it. It so happens that with normal PIO and IOMEM resources, there is no per-resource "enable" bit, so they are always enabled. However, PCI ROM's have a per-resource enable bit both in hardware and in the "struct resource", and if it isn't set, then the resource allocation is done, but the resource is not enabled and not written to hardware. All very consistent. The allocation was successful, but you didn't ask to enable it, so pci_alloc_resource() will return success without actually enablign the hardware. What you want is a "zombie state", where we write the partial information to hardware. It's what we used to do, but it's certainly no more logical than what it does now, and it led to problem reports. Btw, why does this happen on powerpc, but not x86? I'm running a radeon laptop right now myself. Hmm.. 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/
Re: Oops in 2.6.13 (was Linux 2.6.13 )
Yes. I did also report it (see http://lkml.org/lkml/2005/8/26/252) cheers, Masoud Sharbiani Lee Revell wrote: On Mon, 2005-08-29 at 14:23 -0400, Masoud Sharbiani wrote: Sadly, with 2.6.13 (as in with 2.6.13-rc7), it crashes on boot, on a dual P3 machine It works just fine when compiled UP. This bug did NOT exist on 2.6.13-rc6 version. Did you discover this bug with 2.6.13-rc7 before 2.6.13 was released? Lee - 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: Dynamic tick for 2.6.14 - what's the plan?
On Tue, 30 Aug 2005 12:54 pm, Theodore Ts'o wrote: > On Tue, Aug 30, 2005 at 10:05:06AM +1000, Con Kolivas wrote: > > On Tue, 30 Aug 2005 08:42, Christopher Friesen wrote: > > > Lee Revell wrote: > > > > The controversy over the introduction of CONFIG_HZ demonstrated the > > > > urgency of getting a dynamic tick solution merged before 2.6.14. > > > > > > > > Anyone care to give a status report? Con, do you feel that the last > > > > version you posted is ready to go in? > > > > > > Last time I got interested in this, the management of the event queues > > > was still a fairly major performance hit. > > > > > > Has this overhead been brought down to reasonable levels? > > > > Srivatsa is still working on the smp-aware scalable version, so it's back > > in the development phase. > > Has there been an updated version of Thomas's C-state bus-mastering > measurement patch? Same issue, it's waiting on dynticks before being reworked. Cheers, Con - 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] MPC8xx PCMCIA driver
Marcelo Tosatti wrote:
+static int voltage_set(int slot, int vcc, int vpp)
+{
+ u_int reg = 0;
+
+ switch(vcc) {
+ case 0: break;
+ case 33:
+ reg |= BCSR1_PCVCTL4;
+ break;
+ case 50:
+ reg |= BCSR1_PCVCTL5;
+ break;
+ default:
+ return 1;
+ }
+
+ switch(vpp) {
+ case 0: break;
+ case 33:
+ case 50:
+ if(vcc == vpp)
+ reg |= BCSR1_PCVCTL6;
+ else
+ return 1;
+ break;
+ case 120:
+ reg |= BCSR1_PCVCTL7;
+ default:
+ return 1;
+ }
+
+ if(!((vcc == 50) || (vcc == 0)))
+ return 1;
+
+ /* first, turn off all power */
+
+ *((uint *)RPX_CSR_ADDR) &= ~(BCSR1_PCVCTL4 | BCSR1_PCVCTL5
+| BCSR1_PCVCTL6 | BCSR1_PCVCTL7);
+
+ /* enable new powersettings */
+
+ *((uint *)RPX_CSR_ADDR) |= reg;
Should use bus read/write functions, such as foo_readl() or iowrite32().
Don't use weird types in kernel code such as 'uint'. Use the more
explicitly-sized u32.
+ return 0;
+}
+
+#define socket_get(_slot_) PCMCIA_SOCKET_KEY_5V
+#define hardware_enable(_slot_) /* No hardware to enable */
+#define hardware_disable(_slot_) /* No hardware to disable */
+
+#endif /* CONFIG_RPXCLASSIC */
+
+/* FADS Boards from Motorola */
+
+#if defined(CONFIG_FADS)
+
+#define PCMCIA_BOARD_MSG "FADS"
+
+static int voltage_set(int slot, int vcc, int vpp)
+{
+ uint reg = 0;
+
+ switch(vcc) {
+ case 0:
+ break;
+ case 33:
+ reg |= BCSR1_PCCVCC0;
+ break;
+ case 50:
+ reg |= BCSR1_PCCVCC1;
+ break;
+ default:
+ return 1;
+ }
+
+ switch(vpp) {
+ case 0:
+ break;
+ case 33:
+ case 50:
+ if(vcc == vpp)
+ reg |= BCSR1_PCCVPP1;
+ else
+ return 1;
+ break;
+ case 120:
+ if ((vcc == 33) || (vcc == 50))
+ reg |= BCSR1_PCCVPP0;
+ else
+ return 1;
+ default:
+ return 1;
+ }
+
+ /* first, turn off all power */
+ *((uint *)BCSR1) &= ~(BCSR1_PCCVCC_MASK | BCSR1_PCCVPP_MASK);
+
+ /* enable new powersettings */
+ *((uint *)BCSR1) |= reg;
ditto
+ return 0;
+}
+
+#define socket_get(_slot_) PCMCIA_SOCKET_KEY_5V
+
+static void hardware_enable(int slot)
+{
+ *((uint *)BCSR1) &= ~BCSR1_PCCEN;
+}
ditto
+static void hardware_disable(int slot)
+{
+ *((uint *)BCSR1) |= BCSR1_PCCEN;
+}
etc.
+/* - */
+/* Motorola MBX860 */
+
+#if defined(CONFIG_MBX)
+
+#define PCMCIA_BOARD_MSG "MBX"
+
+static int voltage_set(int slot, int vcc, int vpp)
+{
+ unsigned char reg = 0;
+
+ switch(vcc) {
+ case 0:
+ break;
+ case 33:
+ reg |= CSR2_VCC_33;
+ break;
+ case 50:
+ reg |= CSR2_VCC_50;
+ break;
+ default:
+ return 1;
+ }
+
+ switch(vpp) {
+ case 0:
+ break;
+ case 33:
+ case 50:
+ if(vcc == vpp)
+ reg |= CSR2_VPP_VCC;
+ else
+ return 1;
+ break;
+ case 120:
+ if ((vcc == 33) || (vcc == 50))
+ reg |= CSR2_VPP_12;
+ else
+ return 1;
+ default:
+ return 1;
+ }
+
+ /* first, turn off all power */
+ *((unsigned char *)MBX_CSR2_ADDR) &= ~(CSR2_VCC_MASK | CSR2_VPP_MASK);
+
+ /* enable new powersettings */
+ *((unsigned char *)MBX_CSR2_ADDR) |= reg;
ditto.
also, use u8 not unsigned char.
+ return 0;
+}
+
+#define socket_get(_slot_) PCMCIA_SOCKET_KEY_5V
+#define hardware_enable(_slot_) /* No hardware to enable */
+#define hardware_disable(_slot_) /* No hardware to disable */
+
+#endif /* CONFIG_MBX */
+
+#if defined(CONFIG_PRxK)
+#include
+extern volatile fpga_pc_regs *fpga_pc;
+
+#define PCMCIA_BOARD_MSG "MPC855T"
+
+static int voltage_set(int slot, int vcc, int vpp)
+{
+ unsigned char reg = 0;
+ unsigned char regread;
+
Re: 2.6.13-rt1
Ingo,
I just found another deadlock in the pi_lock logic. The PI logic is
very dependent on the P1->L1->P2->L2->P3 order. But our good old friend
is back, the BKL.
Since the BKL is let go and regrabbed even if a task is grabbing another
lock, it messes up the order. For example, it can do the following:
L1->P1->L2->P2->L1 if L1 is the BKL. Luckly, (and I guess there's
really no other way) the BKL is only held by those that are currently
running, or at least not blocked on anyone. So I added code in the
pi_setprio code to test if the next lock in the loop is the BKL and if
so, if its owner is the current task. If so, the loop is broken.
Without this patch, I would constantly get lock ups on shutdown where it
sends SIGTERM to all the processes. It usually would lock up on the
killing of udev. But with the patch, I've shutdown a few times already
and no lockups so far.
-- Steve
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Index: linux_realtime_goliath/kernel/rt.c
===
--- linux_realtime_goliath/kernel/rt.c (revision 308)
+++ linux_realtime_goliath/kernel/rt.c (working copy)
@@ -816,6 +816,21 @@
l = w->lock;
TRACE_BUG_ON_LOCKED(!lock);
+ /*
+* The BKL can really be a pain. It can happen that the lock
+* we are blocked on is owned by a task that is waiting for
+* the BKL, and we own it. So, if this is the BKL and we own
+* it, then end the loop here.
+*/
+ if (unlikely(l == _sem.lock) && lock_owner(l) ==
current_thread_info()) {
+ /*
+* No locks are held for locks, so fool the unlocking
code
+* by thinking the last lock was the original.
+*/
+ l = lock;
+ break;
+ }
+
if (l != lock)
__raw_spin_lock(>wait_lock);
-
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] Only process_die notifier in ia64_do_page_fault if KPROBES is configured.
On Mon, 29 Aug 2005, Rusty Lynch wrote: > So, assuming inlining the notifier_call_chain would address Christoph's > conserns, is the following patch something like what you are sugesting? > This would make all the kdebug.h::notify_die() calls use the inline version. Please do not generate any code if the feature cannot ever be used (CONFIG_KPROBES off). With this patch we still have lots of unnecessary code being executed on each page fault. - 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: Ignore disabled ROM resources at setup
> pci_map_rom "sees" that the resource is unassigned by testing the parent > pointer, and calls pci_assign_resource() which, with this new patch, > will do nothing. Ok, it won't do nothing in fact. It's worse. It will return 0 (success), will actually assign a completely new address to the resource, will update the resource structure ... and will _not_ update the PCI resource BAR for the ROM. That is very bad and definitely not what you want, wether it's ppc, x86 or anything else. Either fail (don't assign the resource at all) or if you assign it, keep the BAR in sync with the struct resource. Also, why do we re-allocate a new address for it ? It's been properly allocated a non-conflicting address by the firmware ... That's a big problem I have with our common code as well. pci_assign_unassigned_resource() doesn't do what it claims: it will re-assign all resources, not only the unassigned ones, at least as soon as it spots a brige, and pci_assign_resource() here called by pci_map_rom() will re-assign even if the address there was already correct. At this point, i'm not sure what the proper fix it. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc6-mm2] ppp_mppe: author email change
Frank Cusack, primary author of the ppp_mppe kernel module, is no
longer at Google. This updates his email address in the module, as
agreed to by Frank privately.
ppp_mppe.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
diff -urNp --exclude-from=/home/mdomsch/excludes --minimal
linux-2.6.13-rc6-mm2.orig/drivers/net/ppp_mppe.c
linux-2.6.13-rc6-mm2/drivers/net/ppp_mppe.c
--- linux-2.6.13-rc6-mm2.orig/drivers/net/ppp_mppe.cMon Aug 29 22:08:58 2005
+++ linux-2.6.13-rc6-mm2/drivers/net/ppp_mppe.c Mon Aug 29 22:10:23 2005
@@ -2,7 +2,7 @@
* ppp_mppe.c - interface MPPE to the PPP code.
* This version is for use with Linux kernel 2.6.14+
*
- * By Frank Cusack <[EMAIL PROTECTED]>.
+ * By Frank Cusack <[EMAIL PROTECTED]>.
* Copyright (c) 2002,2003,2004 Google, Inc.
* All rights reserved.
*
@@ -59,7 +59,7 @@
#include "ppp_mppe.h"
-MODULE_AUTHOR("Frank Cusack <[EMAIL PROTECTED]>");
+MODULE_AUTHOR("Frank Cusack <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("Point-to-Point Protocol Microsoft Point-to-Point
Encryption support");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_ALIAS("ppp-compress-" __stringify(CI_MPPE));
-
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] make radix tree gang lookup faster by using a bitmap search
James Bottomley wrote: On Tue, 2005-08-30 at 10:56 +1000, Nick Piggin wrote: Gang lookup is mainly used on IO paths but also on truncate, which is a reasonably fast path on some workloads (James, this is my suggestion for what you should test - truncate). Actually, I don't think I can test this. In order to show a difference between index 5 and index 6 on 32 bit, I'd have to deal with files > 4GB in size. My 32 bit machines are the voyagers and only have 4GB discs. The machine with all the huge discs, is, naturally, ia64. Sorry, I meant for testing your gang lookup speedups. For testing regular lookups, yeah that's more difficult. For a microbenchmark you can use sparse files, which can be a good trick for testing pagecache performance without the IO. Nick Send instant messages to your online friends http://au.messenger.yahoo.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: Ignore disabled ROM resources at setup
On Tue, 30 Aug 2005, Benjamin Herrenschmidt wrote: > > pci_map_rom "sees" that the resource is unassigned by testing the parent > pointer, and calls pci_assign_resource() which, with this new patch, > will do nothing. Ehh.. It didn't do anything with the old code either for that case, so there's apparently something else also going on. It would write the base address, but since it wouldn't _enable_ the ROM mapping (only the "non-enabled" case changed by this commit), the end result from a hw standpoint should be exactly the same: the ROM isn't actually mapped. So after pci_assign_resource(), the resource has literally been assigned, but that patch should not have mattered in any way whether it was actually _enabled_ or not. Now, there's clearly a difference. What has always worked is then to do pci_write_config_dword(dev, PCI_ROM_ADDRESS, PCI_ROM_ADDRESS_ENABLE | res->start) (well, these days you're supposed to use "pcibios_resource_to_bus()" to get the start value to write out). Much preferable is probably to just enable the resource manually _before_ calling pci_assign_resource, ie do something like. dev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_ENABLE; pci_assign_resource(dev, PCI_ROM_RESOURCE); But yes, if something used to just blindly set PCI_ROM_ADDRESS_ENABLE, then that got broken. I grepped for that and didn't see anything like it, but I guess people are doing it with the magic constant "1".. I don't even find any access to "PCI_ROM_ADDRESS" in radeonfb, so I wonder if it has ever worked? I get the feeling that if the ROM wasn't enabled, it didn't work before either, but perhaps the change makes the failure mode more spectacular? 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/
KLive: Linux Kernel Live Usage Monitor
Hello, During the Kernel Summit somebody raised the point that it's not clear how much testing each rc/pre/git kernel gets before the final release. So I setup a server to track automatically the amount of testing that each kernel gets. Clearly this will be a very rough approximation and it can't be reliable, but perhaps it'll be useful. If this won't be useful, the time I spent on it is very minor so no problem ;). All the details can be found in the project website: http://klive.cpushare.com/ Full source (server included) is here: http://klive.cpushare.com/downloads/klive-0.0.tar.bz2 To run the client: wget http://klive.cpushare.com/klive.tac Then at every boot (like in /etc/init.d/boot.local): twistd -oy klive.tac In theory we could get rid of the client entirely and make it a kernel config option, but I've no idea if this project is useful, so I don't want to spend too much time on it at this point. Thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trailing comments in broken-out series file break quilt
Paul Jackson <[EMAIL PROTECTED]> wrote: > > md-fix-rh_dec-rh_inc-race-in-dm-raid1c.patch # wait > > ... > Question - should I be asking Andrew not to comment this way, or > should I be asking quilt to recognize a comment convention here? I'll just stop using them. - 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][FAT] diren scan profiling report
As I said in "[RFC] FAT dirent scan with hint" <[EMAIL PROTECTED]>, we realized that FAT/VFAT has poor performance with scanning directory entries. Per discussions with Ogawa-san, VFAT maintainer, I took profiling data to seek better solution. Here are results attached. In short, I would say we need to reduce following factors. a) number of iterations inside fat_search_long() b) number of callings to uni16_to_x8() c) number of callings to fat__get_entry(), for short name scan. In another E-mail, I'll send revised version patch which use hint values to scan dirent. That patch would reduce number of iterations inside fat_search_long() and fat_scan(). Those contributes reductions above a)-c) factors. RESULTS: 1-1) Top 10 function consuming time on long file name dir scan (vfat_lookup) for 4095th LFN entry. % kd -n 10 /tmp/lfn_kft-a.log FunctionCount Time Average Local --- - vfat_lookup 1 1242285 1242285 705 vfat_find 1 1241522 1241522 629 fat_search_long 1 1240893 1240893 887490 uni16_to_x8 4209 250222 59 249143 fat_get_entry 76569908 91 3306 fat__get_entry76266602 8750796 fat_shortname2uni 59333158 5511393 fat_short2lower_uni 41421765 5220860 fat_bmap 20213425 66 857 fat_bmap_cluster 20112568 62 1015 *)To exclude profiling overhead, doesn't count functions < 50usec **) Remove "inline" from fat/dir.c to count up inline funcs. 1-2) Top 10 function consuming time on short file name dir scan (fat_scan) for 4095th short file name entry. % kd -n 10 /tmp/kft-a.log FunctionCount Time Average Local --- - fat_scan1 149743 14974368069 fat_get_short_entry 81281512 10011706 fat_get_entry 76569806 91 3252 fat__get_entry76266554 8750425 fat_bmap 19913181 66 838 fat_bmap_cluster 19812343 62 1055 fat_get_cluster 19411288 58 8481 fat_ent_read 52 2807 53 2583 __getblk 32 2339 73 326 __bread29 2145 73 598 *)To exclude profiling overhead, doesn't count functions < 50usec **) Remove "inline" from fat/dir.c to count up inline funcs. 2-1) how to get result 1-1) % ( cat <<__CONF new begin trigger start entry 0xc00cd904 # vfat_lookup trigger stop exit 0xc00cd904# vfat_lookup filter mintime 50 filter maxtime 0 filter noints logentries 500 end __CONF ) > /proc/kft % echo prime > /proc/kft # mount vtat % time stat 4095th-shortfilename-entry real0m1.351s user0m0.007s sys 0m1.295s # umount # get data from /proc/kft_data 2-2) how to get result 1-2) % ( cat <<__CONF new begin trigger start entry 0xc00c36dc # fat_scan trigger stop exit 0xc00c36dc # fat_scan filter mintime 50 filter maxtime 0 filter noints logentries 500 end __CONF ) > /proc/kft % echo prime > /proc/kft # mount msdos % time stat 4095th-shortname-entry real0m0.216s user0m0.002s sys 0m0.200s # umount # get data from /proc/kft_data -- Hiroyuki Machida[EMAIL PROTECTED] SSW Dept. HENC, Sony Corp. - 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 :Added PCI support for MPC83xx
I think it is OK. The external interrupt can be edged. And it works well in my
board.
Tony Li
-Original Message-
From: Gala Kumar K.-galak
Sent: Tuesday, August 30, 2005 1:43 AM
To: Li Tony-r64360
Cc: linuxppc-embedded; linux-kernel@vger.kernel.org; Gala Kumar K.-galak; Chu
hanjin-r52514
Subject: Re: [PATCH] ppc32 :Added PCI support for MPC83xx
I noticed that you aren't updating the senses array in mpc834x_sys_init_IRQ for
the PCI interrupt lines, is this correct?
Should they not be IRQ_SENSE_LEVEL?
Also, I've done a bit of cosmetic cleanup to the patch, take a look and let me
know if it works. Once we close on the IRQ sense issue I will send this
upstream.
- kumar
---
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -713,6 +713,12 @@ config MPC834x_SYS
help
This option enables support for the MPC 834x SYS evaluation board.
+ Be aware that PCI buses can only function when SYS board is plugged on
+ PIB (Platform IO Board) board from Freescale which provide 3 PCI
slots.
+ Just like PC,the board level initalization is bootloader`s
responsiblilty.
+ The PCI deponds on bootloader configurate board corretly. Refer to
Freescale
+ to get more information about this.
+
endchoice
config PQ2ADS
@@ -1193,6 +1199,11 @@ config PCI
config PCI_DOMAINS
bool
default PCI
+
+config MPC83xx_PCI2
+ bool " Supprt for 2nd PCI host controller"
+ depends on PCI && MPC834x
+ default y if MPC834x_SYS
config PCI_QSPAN
bool "QSpan PCI"
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c
b/arch/ppc/platforms/83xx/mpc834x_sys.c
--- a/arch/ppc/platforms/83xx/mpc834x_sys.c
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
@@ -62,9 +62,29 @@ extern unsigned long total_memory; /* in
unsigned char __res[sizeof (bd_t)];
#ifdef CONFIG_PCI
-#error "PCI is not supported"
-/* NEED mpc83xx_map_irq & mpc83xx_exclude_device
- see platforms/85xx/mpc85xx_ads_common.c */
+int
+mpc83xx_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char
+pin) {
+ static char pci_irq_table[][4] =
+ /*
+* PCI IDSEL/INTPIN->INTLINE
+* A B C D
+*/
+ {
+ {PIRQA, PIRQB, PIRQC, PIRQD}, /* idsel 0x11 */
+ {PIRQC, PIRQD, PIRQA, PIRQB}, /* idsel 0x12 */
+ {PIRQD, PIRQA, PIRQB, PIRQC} /* idsel 0x13 */
+ };
+
+ const long min_idsel = 0x11, max_idsel = 0x13, irqs_per_slot = 4;
+ return PCI_IRQ_TABLE_LOOKUP;
+}
+
+int
+mpc83xx_exclude_device(u_char bus, u_char devfn) {
+ return PCIBIOS_SUCCESSFUL;
+}
#endif /* CONFIG_PCI */
/*
@@ -88,7 +108,7 @@ mpc834x_sys_setup_arch(void)
#ifdef CONFIG_PCI
/* setup PCI host bridges */
- mpc83xx_sys_setup_hose();
+ mpc83xx_setup_hose();
#endif
mpc83xx_early_serial_map();
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.h
b/arch/ppc/platforms/83xx/mpc834x_sys.h
--- a/arch/ppc/platforms/83xx/mpc834x_sys.h
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.h
@@ -26,7 +26,7 @@
#define VIRT_IMMRBAR ((uint)0xfe00)
#define BCSR_PHYS_ADDR ((uint)0xf800)
-#define BCSR_SIZE ((uint)(32 * 1024))
+#define BCSR_SIZE ((uint)(128 * 1024))
#define BCSR_MISC_REG2_OFF 0x07
#define BCSR_MISC_REG2_PORESET 0x01
@@ -34,23 +34,25 @@
#define BCSR_MISC_REG3_OFF 0x08
#define BCSR_MISC_REG3_CNFLOCK 0x80
-#ifdef CONFIG_PCI
-/* PCI interrupt controller */
-#define PIRQAMPC83xx_IRQ_IRQ4
-#define PIRQBMPC83xx_IRQ_IRQ5
-#define PIRQCMPC83xx_IRQ_IRQ6
-#define PIRQDMPC83xx_IRQ_IRQ7
-
-#define MPC834x_SYS_PCI1_LOWER_IO0x
-#define MPC834x_SYS_PCI1_UPPER_IO0x00ff
-
-#define MPC834x_SYS_PCI1_LOWER_MEM 0x8000
-#define MPC834x_SYS_PCI1_UPPER_MEM 0x9fff
-
-#define MPC834x_SYS_PCI1_IO_BASE 0xe200
-#define MPC834x_SYS_PCI1_MEM_OFFSET 0x
-
-#define MPC834x_SYS_PCI1_IO_SIZE 0x0100
-#endif /* CONFIG_PCI */
+#define PIRQA MPC83xx_IRQ_EXT4
+#define PIRQB MPC83xx_IRQ_EXT5
+#define PIRQC MPC83xx_IRQ_EXT6
+#define PIRQD MPC83xx_IRQ_EXT7
+
+#define MPC83xx_PCI1_LOWER_IO 0x
+#define MPC83xx_PCI1_UPPER_IO 0x00ff
+#define MPC83xx_PCI1_LOWER_MEM 0x8000
+#define MPC83xx_PCI1_UPPER_MEM 0x9fff
+#define MPC83xx_PCI1_IO_BASE 0xe200
+#define MPC83xx_PCI1_MEM_OFFSET0x
+#define MPC83xx_PCI1_IO_SIZE 0x0100
+
+#define MPC83xx_PCI2_LOWER_IO 0x
+#define MPC83xx_PCI2_UPPER_IO 0x00ff
+#define MPC83xx_PCI2_LOWER_MEM 0xa000
+#define MPC83xx_PCI2_UPPER_MEM 0xbfff
+#define MPC83xx_PCI2_IO_BASE 0xe300
+#define MPC83xx_PCI2_MEM_OFFSET0x
+#define MPC83xx_PCI2_IO_SIZE 0x0100
#endif
[PATCH] MPC8xx PCMCIA driver
Hi,
Here goes the 8xx PCMCIA driver, originally written by Magnus Damm, with
several improvements and fixes.
The driver was merged in v2.4 but never forward ported to v2.6.
Please review, comments are welcome (including aesthetic enhancements).
Russell: The driver is using pccard_nonstatic_ops for card window
management, even though the driver its marked SS_STATIC_MAP (using
mem->static_map).
Otherwise card IO windows aren't allocated properly.
diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -154,6 +154,16 @@ config TCIC
"Bridge" is the name used for the hardware inside your computer that
PCMCIA cards are plugged into. If unsure, say N.
+config PCMCIA_M8XX
+tristate "MPC8xx PCMCIA support"
+depends on PCMCIA && PPC
+select PCCARD_NONSTATIC
+help
+Say Y here to include support for PowerPC 8xx series PCMCIA
+controller.
+
+This driver is also available as a module called m8xx_pcmcia.
+
config HD64465_PCMCIA
tristate "HD64465 host bridge support"
depends on HD64465 && PCMCIA
diff --git a/drivers/pcmcia/Makefile b/drivers/pcmcia/Makefile
--- a/drivers/pcmcia/Makefile
+++ b/drivers/pcmcia/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_PD6729) += pd6729.o
obj-$(CONFIG_I82365) += i82365.o
obj-$(CONFIG_I82092) += i82092.o
obj-$(CONFIG_TCIC) += tcic.o
+obj-$(CONFIG_PCMCIA_M8XX) += m8xx_pcmcia.o
obj-$(CONFIG_HD64465_PCMCIA) += hd64465_ss.o
obj-$(CONFIG_PCMCIA_SA1100)+= sa11xx_core.o sa1100_cs.o
obj-$(CONFIG_PCMCIA_SA)+= sa11xx_core.o sa_cs.o
diff --git a/drivers/pcmcia/m8xx_pcmcia.c b/drivers/pcmcia/m8xx_pcmcia.c
new file mode 100644
--- /dev/null
+++ b/drivers/pcmcia/m8xx_pcmcia.c
@@ -0,0 +1,1295 @@
+/*
+ * m8xx_pcmcia.c - Linux PCMCIA socket driver for the mpc8xx series.
+ *
+ * (C) 1999-2000 Magnus Damm <[EMAIL PROTECTED]>
+ * (C) 2001-2002 Montavista Software, Inc.
+ * <[EMAIL PROTECTED]>
+ *
+ * Support for two slots by Cyclades Corporation
+ * <[EMAIL PROTECTED]>
+ * Further fixes, v2.6 kernel port
+ * <[EMAIL PROTECTED]>
+ *
+ * "The ExCA standard specifies that socket controllers should provide
+ * two IO and five memory windows per socket, which can be independently
+ * configured and positioned in the host address space and mapped to
+ * arbitrary segments of card address space. " - David A Hinds. 1999
+ *
+ * This controller does _not_ meet the ExCA standard.
+ *
+ * m8xx pcmcia controller brief info:
+ * + 8 windows (attrib, mem, i/o)
+ * + up to two slots (SLOT_A and SLOT_B)
+ * + inputpins, outputpins, event and mask registers.
+ * - no offset register. sigh.
+ *
+ * Because of the lacking offset register we must map the whole card.
+ * We assign each memory window PCMCIA_MEM_WIN_SIZE address space.
+ * Make sure there is (PCMCIA_MEM_WIN_SIZE * PCMCIA_MEM_WIN_NO
+ * * PCMCIA_SOCKETS_NO) bytes at PCMCIA_MEM_WIN_BASE.
+ * The i/o windows are dynamically allocated at PCMCIA_IO_WIN_BASE.
+ * They are maximum 64KByte each...
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#ifdef PCMCIA_DEBUG
+static int pc_debug = PCMCIA_DEBUG;
+module_param(pc_debug, int, 0);
+#define dprintk(args...) printk(KERN_DEBUG "m8xx_pcmcia: " args);
+#else
+#define dprintk(args...)
+#endif
+
+#define pcmcia_info(args...) printk(KERN_INFO "m8xx_pcmcia: "args)
+#define pcmcia_error(args...) printk(KERN_ERR "m8xx_pcmcia: "args)
+
+static const char *version = "Version 0.06, Aug 2005";
+MODULE_LICENSE("Dual MPL/GPL");
+
+#if !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B)
+
+/* The RPX series use SLOT_B */
+#if defined(CONFIG_RPXCLASSIC) || defined(CONFIG_RPXLITE)
+#define CONFIG_PCMCIA_SLOT_B
+#define CONFIG_BD_IS_MHZ
+#endif
+
+/* The ADS board use SLOT_A */
+#ifdef CONFIG_ADS
+#define CONFIG_PCMCIA_SLOT_A
+#define CONFIG_BD_IS_MHZ
+#endif
+
+/* The FADS series are a mess */
+#ifdef CONFIG_FADS
+#if defined(CONFIG_MPC860T) || defined(CONFIG_MPC860) || defined(CONFIG_MPC821)
+#define CONFIG_PCMCIA_SLOT_A
+#else
+#define CONFIG_PCMCIA_SLOT_B
+#endif
+#endif
+
+/* Cyclades ACS uses both slots */
+#ifdef CONFIG_PRxK
+#define CONFIG_PCMCIA_SLOT_A
+#define CONFIG_PCMCIA_SLOT_B
+#endif
+
+#endif /* !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B) */
+
+#if defined(CONFIG_PCMCIA_SLOT_A) && defined(CONFIG_PCMCIA_SLOT_B)
+
+#define PCMCIA_SOCKETS_NO 2
+/* We have only 8 windows, dualsocket support will be limited. */
+#define PCMCIA_MEM_WIN_NO 2
+#define PCMCIA_IO_WIN_NO 2
+#define PCMCIA_SLOT_MSG
Re: Dynamic tick for 2.6.14 - what's the plan?
On Tue, Aug 30, 2005 at 10:05:06AM +1000, Con Kolivas wrote: > On Tue, 30 Aug 2005 08:42, Christopher Friesen wrote: > > Lee Revell wrote: > > > The controversy over the introduction of CONFIG_HZ demonstrated the > > > urgency of getting a dynamic tick solution merged before 2.6.14. > > > > > > Anyone care to give a status report? Con, do you feel that the last > > > version you posted is ready to go in? > > > > Last time I got interested in this, the management of the event queues > > was still a fairly major performance hit. > > > > Has this overhead been brought down to reasonable levels? > > Srivatsa is still working on the smp-aware scalable version, so it's back in > the development phase. Has there been an updated version of Thomas's C-state bus-mastering measurement patch? - Ted - 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] improve i2c probing
> Date: Sun, 21 Aug 2005 00:33:48 +0100 (BST) > From: Mark Underwood <[EMAIL PROTECTED]> > > ... > Interestingly (we for me at least ;-) I have been > working on an SPI subsystem that was/is a copy of the > I2C subsystem with changes as SPI doesn't have a > protocol like I2C. ... > > To me, what I have, like I2C, doesn't tie in very well > with the new driver model (although I'm not overly > familiar with it, I think I finally understand > platform devices :-). Yes, it takes maybe a little while to sort out what the driver model does for you, especially if you're coming from whatever strange dimension the I2C model did. :) > I wonder how much work the new kernel subsystems can > do for us to cut down the size of i2c-core (and thus > also spi-core). > I guess there is no escaping the fact that I'm going > to gave to do some more homework and study the code. > Any thoughts or insights would be very welcome. Well, I've just posted a sketch of how to use the driver model in a more traditional way for SPI. That same approach could be taken with I2C if/when anyone gets motivated to make it happen ... except that, unlike SPI, I2C can actually use hardware probing in common usage. (It could kick in right after the pre-declared devices Get initialized.) - 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: [PATCH] make radix tree gang lookup faster by using a bitmap search
On Tue, 2005-08-30 at 10:56 +1000, Nick Piggin wrote: > Sonny Rao wrote: > > >On Mon, Aug 29, 2005 at 01:37:48PM +1000, Nick Piggin wrote: > > > >>s/common/only ? > >> > >>But the page tree is indexed by file offset rather than virtual > >>address, and we try to span the file's pagecache with the smallest > >>possible tree. So it will tend to make the trees taller. > >> > >> > > > >I did some experiments with different map-shift values, > >interestingly overall read throughput didn't change much but the > >cpu-utilization of radix_tree_lookup (from oprofile) changed quite a > >bit, especially in the case of MAP_SHIFT == 4 : > > > >http://www.linuxsymposium.org/2005/linuxsymposium_procv2.pdf > > > >Look on page 80, where I have the table. > > > Nice. So we can see that 6 is a pretty good choice of shift, > 4 is too low. That doesn't tell us much about 5, but if you > fit the curve, 5 should be between 14 and 15 ... so getting > expensive. Actually, several crucial pieces of data are missing. It's not hard to imagine that the results for 8, 10 and 12 are all equal to within the error bars. The missing piece of data, of course, is how big the file was, which would tell us how deep the tree was. > Of course, different systems and different workloads will > be different. But I'd be wary of going below 6 unless there > is a good reason. > > >>I'm curious: what do the benchmarks say about your gang lookup? > >> > > > >Gang-lookup isn't used in the page-cache lookups presently, so I'm > >not sure why optimizing it is very important -- unless someone is > >planning on implementing gang-lookups for page-cache reads. This would > >also cut down on number times a lock is taken and released (expensive, > >in the case of rwlock). Perhaps there is another reason? > > > > > > Gang lookup is mainly used on IO paths but also on truncate, > which is a reasonably fast path on some workloads (James, > this is my suggestion for what you should test - truncate). Actually, I don't think I can test this. In order to show a difference between index 5 and index 6 on 32 bit, I'd have to deal with files > 4GB in size. My 32 bit machines are the voyagers and only have 4GB discs. The machine with all the huge discs, is, naturally, ia64. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ignore disabled ROM resources at setup
On Fri, 2005-08-26 at 11:59 -0700, Linux Kernel Mailing List wrote: > tree d8b7aaaec93de93841b46e8e05a3b454d05bd357 > parent 26aad69e3dd854abe9028ca873fb40b410a39dd7 > author Linus Torvalds <[EMAIL PROTECTED]> Sat, 27 Aug 2005 00:49:22 -0700 > committer Linus Torvalds <[EMAIL PROTECTED]> Sat, 27 Aug 2005 00:49:22 -0700 > > Ignore disabled ROM resources at setup > > Writing even a disabled value seems to mess up some matrox graphics > cards. It may be a card-related issue, but we may also be writing > reserved low bits in the result. > > This was a fall-out of switching x86 over to the generic PCI resource > allocation code, and needs more debugging. In particular, the old x86 > code defaulted to not doing any resource allocations at all for ROM > resources. > > In the meantime, this has been reported to make X happier by Helge > Hafting <[EMAIL PROTECTED]>. This "fix" also seems to break all powermac laptops around :( In fact, it might break any user of pci_map_rom() as it exposes a bug in that function. The problem is that their firmware doesn't assign a ROM resource as they have no ROM on the video chip (like most laptops). radeonfb and aty128fb among others will call pci_map_rom() to try to find an x86 BIOS ROM with some config tables in it. pci_map_rom "sees" that the resource is unassigned by testing the parent pointer, and calls pci_assign_resource() which, with this new patch, will do nothing. Unfortunately, pci_map_rom will not notice this failure, and will happily ioremap & access the bogus resource, thus causing the crash. I'll come up with a fix for pci_map_rom later today. While looking there, I also noticed pci_map_rom_copy() stuff and I'm surprised it was ever accepted in the tree. While I can understand that we might need to keep a cached copy of the ROM content (due to cards like matrox who can't enable both the ROM and the BARs among other issues), the whole idea of whacking a kernel virtual pointer in the struct resource->start of the ROM bar is just too disgusting for words and will probably cause "intersting" side effects in /proc, sysfs and others... Shouldn't we just have a pointer in pci_dev for the optional "ROM cache" instead ? Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SPI redux ... driver model support
The last couple times SPI frameworks came up here, some of the feedback included "make it use the driver model properly; don't be like I2C". In hopes that it'll be useful, here's a small SPI core with driver model support driven from board-specific tables listing devices. I expect the I/O call(s) could stand to change; but at least this one starts out right, based on async I/O. (There's a synchronous call; it's a trivial wrapper.) arch/arm/Kconfig |2 drivers/Kconfig|2 drivers/Makefile |1 drivers/spi/Kconfig| 302 + drivers/spi/Makefile | 32 drivers/spi/spi_init.c | 233 ++ include/linux/spi.h| 179 ++ 7 files changed, 751 insertions(+) Here's one instance of the sysfs "spi_host" class: [EMAIL PROTECTED] sys]# cd /sys/class [EMAIL PROTECTED] class]# ls i2c-adapter/ misc/ pcmcia_socket/ spi_host/ usb_host/ input/ mtd/ scsi_device/ tty/ vc/ mem/ net/ scsi_host/ usb/ [EMAIL PROTECTED] class]# ls spi_host spi2/ [EMAIL PROTECTED] class]# ls -l spi_host/spi2 drwxr-xr-x2 root root0 Aug 29 18:46 ./ drwxr-xr-x3 root root0 Dec 31 1969 ../ lrwxrwxrwx1 root root0 Aug 29 18:46 device -> ../../../devices/platform/omap-uwire/ [EMAIL PROTECTED] class]# Here are the real sysfs objects for that host and its single child (on chipselect 0). Notice that the device exists, but is waiting for driver-modelized ads7846 support (touchscreen and other sensors): [EMAIL PROTECTED] class]# cd /sys/devices/platform/omap-uwire [EMAIL PROTECTED] omap-uwire]# ls bus@driver@ power/ spi2.0-ads7846/ [EMAIL PROTECTED] omap-uwire]# ls -l spi* lrwxrwxrwx1 root root0 Aug 29 18:46 bus -> ../../../../bus/spi/ -r--r--r--1 root root 4096 Aug 29 18:46 modalias drwxr-xr-x2 root root0 Aug 29 18:46 power/ [EMAIL PROTECTED] omap-uwire]# cat spi*/modalias ads7846 [EMAIL PROTECTED] omap-uwire]# For your viewing pleasure, and without the broadast flag that would prevent further redistribution, a patch is appended. - Dave - SNIP!! This is the start of a small SPI framework that started fresh, so it doesn't continue the "i2c driver model mess". - It needs less than 1KB of codespace. If we're stuck with a mid-layer for something so simple, that's the right size budget. :) - The guts use board-specific SPI master configuration tables to build the driver model tree. (Hardware probing is normally NOT an option.) - The Kconfig should be informative about the scope and content of SPI. Don't take that set of drivers seriously yet though! - Building real drivers into this framework likely means updating the I/O "async message" model to include protocol tweaking (like I2C), and maybe some RPC-ish calls (integer in/out, not bulk data; like SMBus). - No userspace API. There are several implementations to compare. Implement them like any driver, then bind that driver to the device. An SPI master controller will declare itself to the SPI framework, which causes any child devices (from those tables) to be created immediately. New "modalias" style hotplug is supported, for ultra-slim userspace tools. --- /dev/null 1970-01-01 00:00:00.0 + +++ g26/include/linux/spi.h 2005-08-29 16:00:38.0 -0700 @@ -0,0 +1,179 @@ +/* + * Copyright (C) 2005 David Brownell + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#ifndef __LINUX_SPI_H +#define __LINUX_SPI_H + +/* + * PROTOTYPE ONLY !!! + * + * The focus is on driver model support ... enough for SPI mastering + * board setups to work. The I/O model still needs attention. + */ + +/*---*/ + +/* + * INTERFACE between board init code and SPI infrastructure. + * + * No SPI driver ever sees these device tables, but it's what + * builds the
Trailing comments in broken-out series file break quilt
Apparently Andrews patch tools allow trailing comments on active lines
in the series file, as in these lines culled from the series file for
2.6.13-rc6-mm2:
e1000-numa-aware-allocation-of-descriptors-v2.patch # hold
nfs-nfs3-page-null-fill-in-a-short-read-situation.patch # wait
sched-implement-nice-support-across-physical-cpus-on-smp.patch # con
sched-change_prio_bias_only_if_queued.patch # con
sched-account_rt_tasks_in_prio_bias.patch # con
sched-smp-nice-bias-busy-queues-on-idle-rebalance.patch # con
sched-correct_smp_nice_bias.patch # con
md-fix-rh_dec-rh_inc-race-in-dm-raid1c.patch # wait
However the quilt command passes these additional terms to the patch
command as additional arguments, confusing the heck out of patch,
and generating an error message that confused the heck out of me.
Question - should I be asking Andrew not to comment this way, or
should I be asking quilt to recognize a comment convention here?
If we choose the second alternative, then the following change to
the file /usr/local/share/quilt/scripts/patchfns might to the trick:
--- /tmp/q/patchfns.1 2005-08-29 19:11:24.0 -0700
+++ /tmp/q/patchfns.2 2005-08-29 19:11:31.0 -0700
@@ -108,8 +108,8 @@ patch_args()
then
/bin/gawk '
$1 == "'"$patch"'" \
- { if (NF >= 2)
- for (i=2; i <= NF; i++)
+ { if (NF >= 2 && $2 != "#")
+ for (i=2; i <= NF && $i != "#"; i++)
print $i
else
print "-p1" ;
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
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.13-rc7-rt4, fails to build
On Mon, 2005-08-29 at 18:45, Lee Revell wrote: > On Mon, 2005-08-29 at 18:15 -0700, Fernando Lopez-Lezcano wrote: > > On Mon, 2005-08-29 at 01:35, Ingo Molnar wrote: > > > * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > > > > > > > I'm getting a build error for 2.6.13-rc7-rt4 with PREEMPT_DESKTOP for > > > > i386: > > > > > > hm, cannot reproduce this build problem on my current tree - could you > > > try 2.6.13-rt1? (and please send the 2.6.13-rt1 .config if it still > > > occurs) > > > > I still get the error, it is happening in the _smp_ build, I don't know > > what's wrong... > > > > arch/i386/mach-generic/built-in.o(.text+0x1183): In function > > `es7000_rename_gsi': > > Well you could certainly work around it by using CONFIG_X86_PC rather > than CONFIG_X86_GENERICARCH unless you really needs to support the IBM > x440, Unisys ES7000, or something with more than 8 CPUs... I don't :-) Thanks a lot for the tip!, I'll try the workaround.. -- Fernando - 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] make radix tree gang lookup faster by using a bitmap search
Nick Piggin <[EMAIL PROTECTED]> wrote: > > But of course gang lookup is only useful if a single read() call > asks for more than 1 page - is that a performance critical path? readahead should do gang lookups (or, preferably, find-next, when it's implemented). But nobody got around to it. - 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] i386, x86_64 Initial PAT implementation
Andi Kleen <[EMAIL PROTECTED]> writes: > On Tuesday 30 August 2005 02:20, Eric W. Biederman wrote: >> PAT (or setting caching policy in the page table entries) has been a >> long desired feature in the kernel and as large memory sizes become >> more prevalent it becomes increasingly hard to specify all of the >> regions that need write-back caching with just 8 MTRRs much less add >> in the write-combining regions. > > [...] > > I don't think it's a good idea to provide the APIs for write combing > to drivers without offering the facilities to avoid aliasing. Because > otherwise we will need to change the API later anyways and there > might be code creep with driver source using old unsafe accesses. > So I would not merge it right now until it is more fully developed. Everything I have provided is already there on some other architecture. Even the possibility for aliasing is already there on x86. How does my patch make anything worse? Andy what do you expect to see as a solution to the aliasing problem? Andy do you have any problem with my patch besides it does not solve a theoretical problem it does not even introduce? We need to get this at least into something like -mm where the community can review the code and do development. Denying the code access to more eyes sounds does not look like a way to solve the problem. As best I can tell guaranteeing that we do not do aliasing is a totally separate problem from PAT and it should be solved that way. This is a practical problem for me. I have hardware where mtrrs cannot be used to both map memory and setup all of the WC memory regions I need. So this patch solves a real problem at a very minimal impact to the kernel. The only way I can imagine the infrastructure working with the drivers in control (without rewriting all of the existing drivers) is to have ioremap and io_remap_pfn_range fail when presented with an attempt to map the same physical memory with different attributes. So from that perspective we already have enough infrastructure to do something. The only real problems exist when you mix WB and (UC or WC) and I have only made access to WC easier. Who is going to call ioremap or io_remap_pfn_range on ram? 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/14] ppc32: Remove board ports that are no longer maintained
On Jul 27, 2005, at 2:57 PM, Andrew Morton wrote: Kumar Gala <[EMAIL PROTECTED]> wrote: The following board ports are no longer maintained or have become obsolete: adir ash beech cedar ep405 k2 mcpn765 menf1 oak pcore rainier redwood sm850 spd823ts We are there for removing support for them. I'll merge all these into -mm for now, but will hold off sending any of them upstream pending confirmation of which patches we really want to proceed with. No one has screamed about anything but ep405 so all the others should go to Linus now. - kumar - 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.13-rc7-rt4, fails to build
On Mon, 2005-08-29 at 18:15 -0700, Fernando Lopez-Lezcano wrote: > On Mon, 2005-08-29 at 01:35, Ingo Molnar wrote: > > * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > > > > > I'm getting a build error for 2.6.13-rc7-rt4 with PREEMPT_DESKTOP for > > > i386: > > > > hm, cannot reproduce this build problem on my current tree - could you > > try 2.6.13-rt1? (and please send the 2.6.13-rt1 .config if it still > > occurs) > > I still get the error, it is happening in the _smp_ build, I don't know > what's wrong... > > arch/i386/mach-generic/built-in.o(.text+0x1183): In function > `es7000_rename_gsi': Well you could certainly work around it by using CONFIG_X86_PC rather than CONFIG_X86_GENERICARCH unless you really needs to support the IBM x440, Unisys ES7000, or something with more than 8 CPUs... Lee - 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] make radix tree gang lookup faster by using a bitmap search
Sonny Rao wrote: On Mon, Aug 29, 2005 at 01:37:48PM +1000, Nick Piggin wrote: s/common/only ? But the page tree is indexed by file offset rather than virtual address, and we try to span the file's pagecache with the smallest possible tree. So it will tend to make the trees taller. I did some experiments with different map-shift values, interestingly overall read throughput didn't change much but the cpu-utilization of radix_tree_lookup (from oprofile) changed quite a bit, especially in the case of MAP_SHIFT == 4 : http://www.linuxsymposium.org/2005/linuxsymposium_procv2.pdf Look on page 80, where I have the table. Nice. So we can see that 6 is a pretty good choice of shift, 4 is too low. That doesn't tell us much about 5, but if you fit the curve, 5 should be between 14 and 15 ... so getting expensive. Of course, different systems and different workloads will be different. But I'd be wary of going below 6 unless there is a good reason. I'm curious: what do the benchmarks say about your gang lookup? Gang-lookup isn't used in the page-cache lookups presently, so I'm not sure why optimizing it is very important -- unless someone is planning on implementing gang-lookups for page-cache reads. This would also cut down on number times a lock is taken and released (expensive, in the case of rwlock). Perhaps there is another reason? Gang lookup is mainly used on IO paths but also on truncate, which is a reasonably fast path on some workloads (James, this is my suggestion for what you should test - truncate). I actually talk about this a little bit at the end of the paper as well. I think gang-lookup when readahead has been turned off is potentially a good way to go, since we are fairly confident that all the pages are in the cache, unfortunately I haven't had (and probably won't) have any time to implement it. It is fairly difficult to do gang lookups in the cached cases, but probably not impossible. But the code around there is already probably as complicated as we would want it to be, so it would be nice if it could be cleaned up first (or maybe it is already as simple as possible :( ). Of course, if we go the lockless path it's much less important. Yep, that's what I'm thinking. The lockless patches I have can do lockless gang lookup and use it for truncate. It should be usable in the same way as the current locked gang lookup is. But of course gang lookup is only useful if a single read() call asks for more than 1 page - is that a performance critical path? Nick Send instant messages to your online friends http://au.messenger.yahoo.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: [discuss] Re: [patch 2.6.13] x86_64: implement dma_sync_single_range_for_{cpu,device}
On Monday 29 August 2005 23:48, John W. Linville wrote: > Perhaps...but I think that sounds more like a discussion of _how_ to > implement the API, rather than _whether_ it should be implemented. > Using some new variant of the swiotlb_* API might be appropriate > for the x86_64 implementation. But, since this is a portable API, > I don't think calling the (apparently Intel-specific) swiotlb_* > functions would be an appropriate replacement. What I meant is that instead of the dumb implementation you did it would be better to implement it in swiotlb_* too and copy only the requested byte range there and then call these new functions from the x86-64 wrapper. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only process_die notifier in ia64_do_page_fault if KPROBES is configured.
On Tuesday 30 August 2005 02:19, Rusty Lynch wrote: > > So, assuming inlining the notifier_call_chain would address Christoph's > conserns, is the following patch something like what you are sugesting? Yes. Well in theory you could make fast and slow notify_die too, but that's probably not worth it. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 16/16] Add hardware breakpoint support for i386
On Mon, 29 Aug 2005 09:12:08 -0700, Tom Rini <[EMAIL PROTECTED]> wrote: > >This adds hardware breakpoint support for i386. This is not as well tested as >software breakpoints, but in some minimal testing appears to be functional. Hardware breakpoints must be per cpu, not global. Also you will fall over applications that are using gdb, because gdb uses the same registers. KDB has never really supported kernel hardware breakpoints, they are hard to do without stamping on user space. - 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: process creation time increases linearly with shmem
On Tue, 30 Aug 2005, Nick Piggin wrote: > > Andrew, did you pick up the patch or should I resend to someone? I picked it up. If it causes performance regressions, we can fix them, and if it causes other problems then that will be interesting in itself. 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/
Re: process creation time increases linearly with shmem
Ray Fucillo wrote: Nick Piggin wrote: How does the following look? (I changed the comment a bit). Andrew, please apply if nobody objects. Nick, I applied this latest patch to a 2.6.12 kernel and found that it does resolve the problem. Prior to the patch on this machine, I was seeing about 23ms spent in fork for ever 100MB of shared memory segment. After applying the patch, fork is taking about 1ms regardless of the shared memory size. Hi Ray, That's good news. I think we should probably consider putting the patch in 2.6.14 or if not, then definitely 2.6.15. Andrew, did you pick up the patch or should I resend to someone? I think the fork latency alone is enough to justify inclusion... however, did you actually see increased aggregate throughput of your database (or at least not a _decreased_ throughput)? Many thanks to everyone for your help on this. Well thank you very much for breaking the kernel and telling us about it! :) Nick Send instant messages to your online friends http://au.messenger.yahoo.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: process creation time increases linearly with shmem
On Mon, 29 Aug 2005, Ray Fucillo wrote: > > FWIW, an interesting side effect of this occurs when I run the database > with this patch internally on a Linux server that uses NIS. Its an > unrelated problem and not a kernel problem. Its due to the children > calling initgroups()... apparently when you have many processes making > simultaneous initgroups() calls something starts imposing very long > waits in increments of 3 seconds Sounds like something is backing off by waiting for three seconds whenever some lock failure occurs. I don't see what locking the code might want to do (it should just do the NIS equivalent of reading /etc/groups and do a "setgroups()" system call), but I assume that the NIS server ends up having some strange locking. You might do an "ltrace testcase" (and, probably, the nis server) to see if you can see where it happens, and bug the appropriate maintainers. Especially if you have a repeatable test-case (where "repeatable" isn't just for your particular machine: it's probably timing-related), somebody might even fix it ;) 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/
[PATCH] i386, x86_64 Initial PAT implementation
PAT (or setting caching policy in the page table entries) has been a
long desired feature in the kernel and as large memory sizes become
more prevalent it becomes increasingly hard to specify all of the
regions that need write-back caching with just 8 MTRRs much less add
in the write-combining regions.
This implementation does not attempt to change the world but it is instead
an incremental improvement on what we already have. We already have
page attributes of write-back (neither PCD nor PWT), uncached (PCD and PWT),
and uncached but allow write-combining (PCD but not PWT) in the x86 page
tables. This implementation simply promotes (PCD but not PWT) to
request write-combining instead of simply allowing it. If PAT is
not implemented on the cpu on the cpu someone requesting
write-combining will get an uncached area that will allow the
mtrrs to specify write-combining.
The way we used the existing page attributes was not completely
consistent, and it is cumbersome to use if you don't understand
the architecture minutia. So I have added an implementation
pgprot_writecombine and the flags _PAGE_MA_WB, _PAGE_MA_WC,
_PAGE_MA_UC so it is clearer what the users are doing.
There should probably be an ioremap_writecombine added as well
but for now you can use __ioremap(..., _PAGE_MA_WC);
In previous conversations concerns have been raised about aliasing
issues caused by the same physical addresses being cached in different
ways. Currently this code only allows for an additional flavor
of uncached access to physical memory addresses which should be hard
to abuse, and should raise no additional aliasing problems. No
attempt has been made to fix theoretical aliasing problems.
I have tested this code and it works for me but it probably needs
to sit in the -mm tree for a little while, to get broader exposure.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/common.c | 31 ++
arch/i386/kernel/reboot.c |1 +
arch/i386/kernel/smp.c |1 +
arch/i386/mach-visws/reboot.c |1 +
arch/i386/mm/ioremap.c |2 +-
arch/i386/pci/i386.c| 15 +++
arch/x86_64/kernel/reboot.c |1 +
arch/x86_64/kernel/setup.c | 34 -
arch/x86_64/mm/ioremap.c|2 +-
drivers/char/drm/drm_vm.c |5 +
drivers/video/fbmem.c |3 +--
drivers/video/gbefb.c | 11 ++-
drivers/video/sgivwfb.c |3 +--
include/asm-i386/cpufeature.h |1 +
include/asm-i386/msr.h |2 ++
include/asm-i386/pgtable.h | 40 +--
include/asm-i386/processor.h|1 +
include/asm-x86_64/cpufeature.h |1 +
include/asm-x86_64/msr.h|2 ++
include/asm-x86_64/pgtable.h| 33
include/asm-x86_64/processor.h |1 +
21 files changed, 157 insertions(+), 34 deletions(-)
054beb808d7d8bbb39fb675faa2d0f4f54c0196d
diff --git a/arch/i386/kernel/cpu/common.c b/arch/i386/kernel/cpu/common.c
--- a/arch/i386/kernel/cpu/common.c
+++ b/arch/i386/kernel/cpu/common.c
@@ -320,6 +320,27 @@ static int __init x86_serial_nr_setup(ch
__setup("serialnumber", x86_serial_nr_setup);
+static void __devinit pat_init(void)
+{
+ /* Set PCD to Write-Combining instead of Write-Combining allow */
+ if (cpu_has_pat) {
+ unsigned long lo,hi;
+ lo = 0x00010406;
+ hi = 0x00070406;
+ wrmsr(MSR_PAT,lo,hi);
+ }
+}
+
+static void pat_shutdown(void)
+{
+ /* Restore CPU default pat state */
+ if (cpu_has_pat) {
+ unsigned long lo,hi;
+ lo = 0x00070406;
+ hi = 0x00070406;
+ wrmsr(MSR_PAT,lo,hi);
+ }
+}
/*
* This does the hard work of actually picking apart the CPU stuff...
@@ -440,6 +461,8 @@ void __devinit identify_cpu(struct cpuin
mtrr_bp_init();
else
mtrr_ap_init();
+
+ pat_init();
}
#ifdef CONFIG_X86_HT
@@ -668,3 +691,11 @@ void __devinit cpu_uninit(void)
per_cpu(cpu_tlbstate, cpu).active_mm = _mm;
}
#endif
+
+void cpu_shutdown(void)
+{
+ /* PARANOIA: Turn off optional cpu features so
+* we do not confuse the reboot process.
+*/
+ pat_shutdown();
+}
diff --git a/arch/i386/kernel/reboot.c b/arch/i386/kernel/reboot.c
--- a/arch/i386/kernel/reboot.c
+++ b/arch/i386/kernel/reboot.c
@@ -309,6 +309,7 @@ void machine_shutdown(void)
#ifdef CONFIG_X86_IO_APIC
disable_IO_APIC();
#endif
+ cpu_shutdown();
}
void machine_emergency_restart(void)
diff --git a/arch/i386/kernel/smp.c b/arch/i386/kernel/smp.c
--- a/arch/i386/kernel/smp.c
+++ b/arch/i386/kernel/smp.c
@@ -575,6 +575,7 @@ static void stop_this_cpu (void * dummy)
cpu_clear(smp_processor_id(), cpu_online_map);
local_irq_disable();
Re: [PATCH] Only process_die notifier in ia64_do_page_fault if KPROBES is configured.
On Sat, Aug 27, 2005 at 02:24:25AM +0200, Andi Kleen wrote:
> On Saturday 27 August 2005 01:05, Christoph Lameter wrote:
> > On Fri, 26 Aug 2005, Rusty Lynch wrote:
> > > Just to be sure everyone understands the overhead involved, kprobes only
> > > registers a single notifier. If kprobes is disabled (CONFIG_KPROBES is
> > > off) then the overhead on a page fault is the overhead to execute an
> > > empty notifier chain.
> >
> > Its the overhead of using registers to pass parameters, performing a
> > function call that does nothing etc. A waste of computing resources. All
> > of that unconditionally in a performance critical execution path that
> > is executed a gazillion times for an optional feature that I frankly
> > find not useful at all and that is disabled by default.
>
> In the old days notifier_call_chain used to be inline. Then someone looking
> at code size out of lined it. Perhaps it should be inlined again or notifier.h
> could supply a special faster inline version for time critical code.
>
> Then it would be simple if (global_var != NULL) { ... } in the fast path.
> In addition the call chain could be declared __read_mostly.
>
> I suspect with these changes Christoph's concerns would go away, right?
>
> -Andi
So, assuming inlining the notifier_call_chain would address Christoph's
conserns, is the following patch something like what you are sugesting?
This would make all the kdebug.h::notify_die() calls use the inline version.
(WARNING: The following has only been tested on ia64.)
include/asm-i386/kdebug.h|2 +-
include/asm-ia64/kdebug.h|2 +-
include/asm-ppc64/kdebug.h |2 +-
include/asm-sparc64/kdebug.h |2 +-
include/asm-x86_64/kdebug.h |2 +-
include/linux/notifier.h | 18 ++
kernel/sys.c | 14 +-
7 files changed, 24 insertions(+), 18 deletions(-)
Index: linux-2.6.13/include/linux/notifier.h
===
--- linux-2.6.13.orig/include/linux/notifier.h
+++ linux-2.6.13/include/linux/notifier.h
@@ -72,5 +72,23 @@ extern int notifier_call_chain(struct no
#define CPU_DOWN_FAILED0x0006 /* CPU (unsigned)v NOT going
down */
#define CPU_DEAD 0x0007 /* CPU (unsigned)v dead */
+static inline int fast_notifier_call_chain(struct notifier_block **n,
+ unsigned long val, void *v)
+{
+ int ret=NOTIFY_DONE;
+ struct notifier_block *nb = *n;
+
+ while(nb)
+ {
+ ret=nb->notifier_call(nb,val,v);
+ if(ret_STOP_MASK)
+ {
+ return ret;
+ }
+ nb=nb->next;
+ }
+ return ret;
+}
+
#endif /* __KERNEL__ */
#endif /* _LINUX_NOTIFIER_H */
Index: linux-2.6.13/kernel/sys.c
===
--- linux-2.6.13.orig/kernel/sys.c
+++ linux-2.6.13/kernel/sys.c
@@ -169,19 +169,7 @@ EXPORT_SYMBOL(notifier_chain_unregister)
int notifier_call_chain(struct notifier_block **n, unsigned long val, void *v)
{
- int ret=NOTIFY_DONE;
- struct notifier_block *nb = *n;
-
- while(nb)
- {
- ret=nb->notifier_call(nb,val,v);
- if(ret_STOP_MASK)
- {
- return ret;
- }
- nb=nb->next;
- }
- return ret;
+ return fast_notifier_call_chain(n, val, v);
}
EXPORT_SYMBOL(notifier_call_chain);
Index: linux-2.6.13/include/asm-ia64/kdebug.h
===
--- linux-2.6.13.orig/include/asm-ia64/kdebug.h
+++ linux-2.6.13/include/asm-ia64/kdebug.h
@@ -55,7 +55,7 @@ static inline int notify_die(enum die_va
.signr = sig
};
- return notifier_call_chain(_chain, val, );
+ return fast_notifier_call_chain(_chain, val, );
}
#endif
Index: linux-2.6.13/include/asm-i386/kdebug.h
===
--- linux-2.6.13.orig/include/asm-i386/kdebug.h
+++ linux-2.6.13/include/asm-i386/kdebug.h
@@ -44,7 +44,7 @@ enum die_val {
static inline int notify_die(enum die_val val,char *str,struct pt_regs
*regs,long err,int trap, int sig)
{
struct die_args args = { .regs=regs, .str=str, .err=err,
.trapnr=trap,.signr=sig };
- return notifier_call_chain(_chain, val, );
+ return fast_notifier_call_chain(_chain, val, );
}
#endif
Index: linux-2.6.13/include/asm-ppc64/kdebug.h
===
--- linux-2.6.13.orig/include/asm-ppc64/kdebug.h
+++ linux-2.6.13/include/asm-ppc64/kdebug.h
@@ -37,7 +37,7 @@ enum die_val {
static inline int notify_die(enum die_val val,char *str,struct pt_regs
*regs,long err,int trap, int sig)
{
struct die_args args = { .regs=regs, .str=str, .err=err,
.trapnr=trap,.signr=sig };
- return
Re: [PATCH 2.6] I2C: Drop I2C_DEVNAME and i2c_clientname
Hi, Jean, Em Qui, 2005-08-25 Ã s 00:19 +0200, Jean Delvare escreveu: > Hi Mauro, > > > That's not true. We keep V4L tree compatible with older kernel > > releases. Each change like this does generate a lot of work at V4L > > side to provide #ifdefs to check for linux version and provide a > > compatible way to compile with older versions. > > I'm sorry but we will not stop updating the various Linux 2.6 subsystems > to keep them compatible with 2.4 - else one would wonder why there is a > 2.6 kernel tree at all. I don't expect so, but it would be nice not to have a different I2C API for every single 2.6 version :-) It would be nice to change I2C API once and keep it stable for a while. > As time goes, the differences bwteen 2.4 and 2.6 > will only increase. You seem to be trying to keep common driver code > across incompatible trees. I'm not surprised that it is a lot of work. > That's your choice, live with it. It is not just a matter of choice. V4L stuff is mostly used by end users. There are a few professional users, like those working on CATV and video broadcasting. They don't have much knowledge and generally uses distro-provided kernels. It is not like I2C or PCI that most boards has something inside. Also: boards are country-specific. There are dozens of different analog standards. So, the same brand name (even the same model on some cases) have different tuners for different video standards. For us to have people to test all variations, we need to provide backward support. Otherwise, we'll suffer a lot to test our patches, since nobody on V4L devel is currently payed for doing his job and don't have a lab with a bunch of cards and models. > > > I don't see any sense on applying this patch, since it will not reduce > > code size or increase execution time. > > Code size and execution time are not the only factors to take into > account. Code readability and compilation time are two other ones that I > mentioned already. Agreed. > > Anyway, it doesn't look like you actually read what I wrote in the first > place. My comment about common driver code was really only by the way. > The reason why I have been proposing this patch is that I2C_DEVNAME and > i2c_clientname were only needed between Linux 2.5.68 and 2.6.0-test3, > which are unsupported by now, as they were development releases. As far > as i2c_client.name is concerned, 2.4 and 2.6.0+ trees are compatible. > Ok. I didn't understood this from your previous email. So, for me, it is perfect to apply it. We do want to keep V4L tree compatibility with 2.6.x and with the latest 2.4 version. Currently, we lost compat with 2.4, but I plan to provide a backport soon to the latest 2.4 release. I have a question for you about I2C: why i2c_driver doesn't have a generic pointer to keep priv data (like i2c_adapter) ? It would be nice to have such pointer (like have on other I2C structures), in order to support multiple tuners for each function. This is required for modern boards that have a TV analog tuner, a digital one and a radio chip, it would be nice to have such structure to keep a tuner table on it, and make easier to detect this. > Thanks, Thanks, Mauro. - 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: Dynamic tick for 2.6.14 - what's the plan?
On Tue, 30 Aug 2005 08:42, Christopher Friesen wrote: > Lee Revell wrote: > > The controversy over the introduction of CONFIG_HZ demonstrated the > > urgency of getting a dynamic tick solution merged before 2.6.14. > > > > Anyone care to give a status report? Con, do you feel that the last > > version you posted is ready to go in? > > Last time I got interested in this, the management of the event queues > was still a fairly major performance hit. > > Has this overhead been brought down to reasonable levels? Srivatsa is still working on the smp-aware scalable version, so it's back in the development phase. Cheers, Con - 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.13 : __check_region is deprecated
On 8/30/05, Diego Calleja <[EMAIL PROTECTED]> wrote: > El Tue, 30 Aug 2005 01:34:25 +0200, > Jesper Juhl <[EMAIL PROTECTED]> escribió: > > > I don't see why we should break a bunch of drivers by doing that. > > Much better, in my oppinion, to fix the few remaining drivers still > > using check_region and *then* kill it. Even unmaintained drivers may > > I'd usually agree with you, but check_region has been deprecated for so many > time; I was just wondering myself if people will bother to fix the remaining > drivers without some "incentive" > I fixed a few a while back, without any incentive other than "this just needs to be done". I'm sure noone would object if you submitted a few patches yourself to fix some of the remaining ones. -- 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/
Re: Linux 2.6.13
> There it is. 2.6.13 does not boot in my PPC (iBook, 500 MHz), it hangs just at the very begining and the machines is automatically rebooted after a couple of minutes. The on-screen messages finishes with a few "openpic" messages: http://mnm.uib.es/gallir/tmp/linux-13-ppc.jpg I used the same 2.5.12's .config that works fine (http://mnm.uib.es/gallir/tmp/config-2.6.13-ppc.txt). During "make oldconfig" I selected the default options, with the exception of the "hardware monitor" which I first enabled and then disabled because was the first suspicious. Can I do any further test? Or is it a stupid mistake? Cheers. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/gallir/ - 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/
PROBLEM: 2.6.13, Inconsistent kallsyms data
When I try to compile 2.6.13, using a complete tarball from kernel.org, the compilation fails with: --- SYSMAP System.map SYSMAP .tmp_System.map Inconsistent kallsyms data Try setting CONFIG_KALLSYMS_EXTRA_PASS make: *** [vmlinux] Error 1 --- When CONFIG_KALLSYMS_EXTRA_PASS is set, the compilation completes successfully. I'm reporting the problem as requested in the configuration help files. I see that this problem has a history, but I'm not sure what information I can supply that would be useful. If I can help in any way, please let me know how. My technical skills are limited. Jim McCloskey - 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.13 : __check_region is deprecated
El Tue, 30 Aug 2005 01:34:25 +0200, Jesper Juhl <[EMAIL PROTECTED]> escribió: > I don't see why we should break a bunch of drivers by doing that. > Much better, in my oppinion, to fix the few remaining drivers still > using check_region and *then* kill it. Even unmaintained drivers may I'd usually agree with you, but check_region has been deprecated for so many time; I was just wondering myself if people will bother to fix the remaining drivers without some "incentive" - 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: kernel panic
manomugdha biswas wrote: Hi, I am using the following makefile and the .c file to generate a kernel module. I can load this module without error and warning. But when I call ioctl() from user application to run this module it gets kernel panic! I think there's something wrong with the way you're using the wait queue (they're not normally instantiated as local variables on the stack, for one thing). It looks like you're just using it to create a delay, in that case use schedule_timeout, msleep, etc. -- 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: ppp_mppe+pptp for 2.6.14?
On Mon, Aug 29, 2005 at 05:10:34PM -0500, Matt Domsch wrote: > I've asked James Cameron, pptp project lead, to try a test to force > the server side to issue a CCP DOWN, to make sure the client-side > kernel ppp_generic module does the right thing and drops packets. I'm still working on this; tried Matt's patch against 2.6.13 last night, but it seems 2.6.13 has broken raw sockets for pptp and pptpd ... ENOPROTOOPT returned from the read() on the raw socket carrying the GRE stream from pptp to the net. Wasn't happening with 2.6.12.5. My plan is to try Matt's patch against 2.6.12.5, and try 2.6.13 bare, to isolate the cause of the ENOPROTOOPT changed behaviour. The previous version of Matt's patch (before the SC_MUST_COMP feature) is working fine for me with 2.6.12.5. (If anyone has any ideas on raw socket breakage, let me know. 2.6.13 changed net/ipv4/raw.c but the changes look to me to be minor.) -- James Cameron signature.asc Description: Digital signature
Re: Linux-2.6.13 : __check_region is deprecated
On 8/30/05, Diego Calleja <[EMAIL PROTECTED]> wrote: [snip] > > /me wonders why check_region has not been killed, it has been > deprecated for years; killing it would force developers to fix it > and would help to identify unmaintained drivers... I don't see why we should break a bunch of drivers by doing that. Much better, in my oppinion, to fix the few remaining drivers still using check_region and *then* kill it. Even unmaintained drivers may still be useful to a lot of people, no point in just breaking them for the hell of it. -- 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/
Re: process creation time increases linearly with shmem
Nick Piggin wrote: How does the following look? (I changed the comment a bit). Andrew, please apply if nobody objects. Nick, I applied this latest patch to a 2.6.12 kernel and found that it does resolve the problem. Prior to the patch on this machine, I was seeing about 23ms spent in fork for ever 100MB of shared memory segment. After applying the patch, fork is taking about 1ms regardless of the shared memory size. Many thanks to everyone for your help on this. FWIW, an interesting side effect of this occurs when I run the database with this patch internally on a Linux server that uses NIS. Its an unrelated problem and not a kernel problem. Its due to the children calling initgroups()... apparently when you have many processes making simultaneous initgroups() calls something starts imposing very long waits in increments of 3 seconds, so some processes return from initgroups() in a few ms and other processes complete in 3, 6, 9, up to 21 seconds (plus a few ms). I'm not sure what the story is with that, though its clearly not a kernel issue. If someone happens to have the answer or a suggestion, great, otherwise I'll persue that elsewhere as necessary. (I can reproduce this by simply adding a call to initgroups() call in the child of the forktest program that I sent earlier) - 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: list.h copyright owner
On Maw, 2005-08-30 at 00:40 +0200, Daniele Orlandi wrote: > So, who is the copyright holder of that file, so that I can ask him > permission > to use the file in a Lesser GPL project? Linus I believe for the most part. I wrote the prefetching changes to for_each_ functions and I'd consider those at least so obvious you don't need permission (but you can have it). Alan - 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.13 : __check_region is deprecated
El Tue, 30 Aug 2005 01:14:17 +0200, Stephane Wirtel <[EMAIL PROTECTED]> escribió: > Is there a function to replace this deprecated function ? request_region > Why is it deprecated ? >From http://lists.osdl.org/pipermail/kernel-janitors/2004-January/000346.html: "The reason that check_region() is deprecated is that it is racy. It could report that a region is available and then another driver could immediately reserve that region, since check_region() doesn't have any reservation capability." /me wonders why check_region has not been killed, it has been deprecated for years; killing it would force developers to fix it and would help to identify unmaintained drivers... - 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.13 : __check_region is deprecated
On 8/30/05, Stephane Wirtel <[EMAIL PROTECTED]> wrote: > Hi, > > By compiling my kernel, I can see that the __check_region function (in > kernel/resource.c) is deprecated. > [snip] > > Is there a function to replace this deprecated function ? > Yes, you just call request_region() and check its return value. > Why is it deprecated ? > In the past you first called check_region() followed by request_region() if the region was available. That is not safe as you could get interrupted between the two calls and something else might have already grabbed the region you thought was free by the time you get to calling request_region(). So, request_region() was rewritten to do the checking internally and let the caller know via its return value if acquiring the region failed or succeded. So these days check_region should no longer be used. It's a historic relic. request_region() should be used directly instead. That's why it is deprecated. -- 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/
Re: Linux-2.6.13 : __check_region is deprecated
On Tue, 30 Aug 2005, Stephane Wirtel wrote: > Hi, > > By compiling my kernel, I can see that the __check_region function (in > kernel/resource.c) is deprecated. > > With a grep on the source code of the last release, I get this result. > > drivers/pnp/resource.c:255: if (__check_region(_resource, > *port, length(port,end))) > include/linux/ioport.h:117:#define check_mem_region(start,n) > __check_region(_resource, (start), (n)) > include/linux/ioport.h:120:extern int __check_region(struct resource *, > unsigned long, unsigned long); > include/linux/ioport.h:125: return __check_region(_resource, s, n); > kernel/resource.c:468:int __deprecated __check_region(struct resource > *parent, unsigned long start, unsigned long n) > kernel/resource.c:481:EXPORT_SYMBOL(__check_region); > > Is there a function to replace this deprecated function ? Just restructure the code to use request_region(). > Why is it deprecated ? because it's racy. I.e., it's normally used as: check_region(); if (ok) request_region(); but between the check_region() and request_region(), the region could have been allocated by something else. -- ~Randy - 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: how do I this in sysfs?
On Mon, 29 Aug 2005 12:24:18 -0500, "Miller, Mike (OS Dev)" <[EMAIL PROTECTED]> wrote: > >> This is after my minimal sas transport class, please also >> read the thread about it on linux-scsi >> >In the referenced code for using sysfs, there only appear to be methods >for reading attributes. How about if we want to cause a command to >get written out to the hardware? Do we do something like this? > >/* get a semaphore keep everyone else out while we're working, > and hope like hell that all the other processes are playing > nice and using the semaphore too, or else we're hosed. */ > [...] >release_some_kind_of_semaphore(); > >I'm not suggesting that the above is a good idea. I don't have a good >idea about how to do this. Take a look at hwmon drivers, it is nowhere near so bad as you think. Grant. - 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] fix compiler warning in aic7770
Fix compiler warning in drivers/scsi/aic7xxx/aic7770.c :
drivers/scsi/aic7xxx/aic7770.c:129: warning: unused variable `l'
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/scsi/aic7xxx/aic7770.c |1 -
1 files changed, 1 deletion(-)
--- linux-2.6.13-orig/drivers/scsi/aic7xxx/aic7770.c2005-08-29
01:41:01.0 +0200
+++ linux-2.6.13/drivers/scsi/aic7xxx/aic7770.c 2005-08-30 01:08:22.0
+0200
@@ -126,7 +126,6 @@ aic7770_find_device(uint32_t id)
int
aic7770_config(struct ahc_softc *ahc, struct aic7770_identity *entry, u_int io)
{
- u_long l;
int error;
int have_seeprom;
u_int hostconf;
-
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: Where is the performance bottleneck?
> "Holger" == Holger Kiehl <[EMAIL PROTECTED]> writes: Holger> Hello I have a system with the following setup: (4-way CPUs, 8 spindles on two controllers) Try using XFS. See http://scalability.gelato.org/DiskScalability_2fResults --- ext3 is single threaded and tends not to get the full benefit of either the multiple spindles nor the multiple processors. -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au The technical we do immediately, the political takes *forever* - 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] drivers/net/s2io.h - lvalue fix
Hi Jesper, > Hmm, neither do I. Looking in MAINTAINERS I don't see anybody, and > looking in the sources I find just a company name `Neterion'. > So, lacking an email address for a maintainer, sending your patch to > linux-kernel is the right thing to do (even if you had found a > maintainer, adding linux-kernel to Cc: would usually also be proper). > If you get no response at all from the list or maintainer, then Andrew > Morton is the head 2.6 maintainer. Ok, thanks for your response. > > > > This patch is based on Kernel 2.6.13 release from the Linus tree. > > > > Is there a process to send patch to the mailing list ? > > > > Check out >- Documentation/SubmittingPatches >- http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt >- http://linux.yyz.us/patch-format.html >- http://www.tux.org/lkml/#s1-10 >- http://www.tux.org/lkml/#s1-15 Thanks Best Regards, Stephane -- Stephane Wirtel <[EMAIL PROTECTED]> <[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] isdn_v110 warning fix
Warning fix :
drivers/isdn/i4l/isdn_v110.c:523: warning: `ret' might be used uninitialized
in this function
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/isdn/i4l/isdn_v110.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.13-orig/drivers/isdn/i4l/isdn_v110.c 2005-08-29
01:41:01.0 +0200
+++ linux-2.6.13/drivers/isdn/i4l/isdn_v110.c 2005-08-30 00:59:34.0
+0200
@@ -516,11 +516,11 @@
}
int
-isdn_v110_stat_callback(int idx, isdn_ctrl * c)
+isdn_v110_stat_callback(int idx, isdn_ctrl *c)
{
isdn_v110_stream *v = NULL;
int i;
- int ret;
+ int ret = 0;
if (idx < 0)
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] IDE: move CONFIG_IDE_MAX_HWIFS into linux/ide.h (resend)
Ping... any objection to this? CONFIG_IDE_MAX_HWIFS is a generic thing, no need to have it duplicated by every arch that uses it. Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]> Index: work-ide/include/asm-alpha/ide.h === --- work-ide.orig/include/asm-alpha/ide.h 2005-08-24 09:36:41.0 -0600 +++ work-ide/include/asm-alpha/ide.h2005-08-24 09:37:12.0 -0600 @@ -15,10 +15,6 @@ #include -#ifndef MAX_HWIFS -#define MAX_HWIFS CONFIG_IDE_MAX_HWIFS -#endif - #define IDE_ARCH_OBSOLETE_DEFAULTS static inline int ide_default_irq(unsigned long base) Index: work-ide/include/asm-sh/ide.h === --- work-ide.orig/include/asm-sh/ide.h 2005-08-24 09:36:41.0 -0600 +++ work-ide/include/asm-sh/ide.h 2005-08-24 09:37:12.0 -0600 @@ -16,10 +16,6 @@ #include -#ifndef MAX_HWIFS -#define MAX_HWIFS CONFIG_IDE_MAX_HWIFS -#endif - #define ide_default_io_ctl(base) (0) #include Index: work-ide/include/asm-sh64/ide.h === --- work-ide.orig/include/asm-sh64/ide.h2005-08-24 09:36:41.0 -0600 +++ work-ide/include/asm-sh64/ide.h 2005-08-24 09:37:12.0 -0600 @@ -17,10 +17,6 @@ #include -#ifndef MAX_HWIFS -#define MAX_HWIFS CONFIG_IDE_MAX_HWIFS -#endif - /* Without this, the initialisation of PCI IDE cards end up calling * ide_init_hwif_ports, which won't work. */ #ifdef CONFIG_BLK_DEV_IDEPCI Index: work-ide/include/linux/ide.h === --- work-ide.orig/include/linux/ide.h 2005-08-24 09:37:03.0 -0600 +++ work-ide/include/linux/ide.h2005-08-24 09:37:24.0 -0600 @@ -266,6 +266,10 @@ #include +#ifndef MAX_HWIFS +#define MAX_HWIFS CONFIG_IDE_MAX_HWIFS +#endif + /* needed on alpha, x86/x86_64, ia64, mips, ppc32 and sh */ #ifndef IDE_ARCH_OBSOLETE_DEFAULTS # define ide_default_io_base(index)(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: [PATCH] drivers/net/s2io.h - lvalue fix
On 8/30/05, Stephane Wirtel <[EMAIL PROTECTED]> wrote: > Hi all , > > Sorry if I don't send this patch to the maintainer of s2io, but I don't > know who is he. > Hmm, neither do I. Looking in MAINTAINERS I don't see anybody, and looking in the sources I find just a company name `Neterion'. So, lacking an email address for a maintainer, sending your patch to linux-kernel is the right thing to do (even if you had found a maintainer, adding linux-kernel to Cc: would usually also be proper). If you get no response at all from the list or maintainer, then Andrew Morton is the head 2.6 maintainer. > This patch is based on Kernel 2.6.13 release from the Linus tree. > > Is there a process to send patch to the mailing list ? > Check out - Documentation/SubmittingPatches - http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt - http://linux.yyz.us/patch-format.html - http://www.tux.org/lkml/#s1-10 - http://www.tux.org/lkml/#s1-15 -- 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/
Re: Dynamic tick for 2.6.14 - what's the plan?
Lee Revell wrote: The controversy over the introduction of CONFIG_HZ demonstrated the urgency of getting a dynamic tick solution merged before 2.6.14. Anyone care to give a status report? Con, do you feel that the last version you posted is ready to go in? Last time I got interested in this, the management of the event queues was still a fairly major performance hit. Has this overhead been brought down to reasonable levels? Chris - 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.13-rc6-rt1
On Fri, 26 Aug 2005, Matt Mackall wrote:
> On Tue, Aug 16, 2005 at 02:32:01PM +0200, Michal Schmidt wrote:
> > Ingo Molnar wrote:
> > >i've released the 2.6.13-rc6-rt1 tree, which can be downloaded from the
> > >usual place:
> > >
> > > http://redhat.com/~mingo/realtime-preempt/
> > >
> > >as the name already suggests, i've switched to a new, simplified naming
> > >scheme, which follows the usual naming convention of trees tracking the
> > >mainline kernel. The numbering will be restarted for every new upstream
> > >kernel the -RT tree is merged to.
> >
> > Great! With this naming scheme it is easy to teach Matt Mackall's
> > ketchup script about the -RT tree.
> > The modified ketchup script can be downloaded from:
> > http://www.uamt.feec.vutbr.cz/rizeni/pom/ketchup-0.9+rt
> >
> > Matt, would you release a new ketchup version with this support for
> > Ingo's tree?
>
> Thanks. I've put this in my version, which is now exported as a
> Mercurial repo at:
>
> http://selenic.com/repo/ketchup
>
> This version also has -git support, finally.
>
I added the line in the patch below to be able to get Ingo's older
patches.
Esben
diff -r 1342be306020 ketchup
--- a/ketchup Sat Aug 27 01:12:42 2005
+++ b/ketchup Tue Aug 30 00:30:23 2005
@@ -367,6 +367,7 @@
# the jgarzik memorial hack
url2 = re.sub("/snapshots/", "/snapshots/old/", url)
+url2 = re.sub("/realtime-preempt/", "/realtime-preempt/older/", url2)
if url2 != url:
if download(url2, file): return file
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] arch: pci_find_device remove (ppc/platforms/85xx/mpc85xx_cds_common.c)
Generated in 2.6.13-rc6-mm2 kernel version.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
mpc85xx_cds_common.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
@@ -354,10 +354,10 @@ mpc85xx_cds_fixup_via(struct pci_control
void __init
mpc85xx_cds_pcibios_fixup(void)
{
-struct pci_dev *dev = NULL;
+struct pci_dev *dev;
u_char c;
-if ((dev = pci_find_device(PCI_VENDOR_ID_VIA,
+ if ((dev = pci_get_device(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C586_1, NULL))) {
/*
* U-Boot does not set the enable bits
@@ -374,21 +374,24 @@ mpc85xx_cds_pcibios_fixup(void)
*/
dev->irq = 14;
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
+ pci_dev_put(dev);
}
/*
* Force legacy USB interrupt routing
*/
-if ((dev = pci_find_device(PCI_VENDOR_ID_VIA,
+ if ((dev = pci_get_device(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C586_2, NULL))) {
dev->irq = 10;
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, 10);
+ pci_dev_put(dev);
}
-if ((dev = pci_find_device(PCI_VENDOR_ID_VIA,
+ if ((dev = pci_get_device(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C586_2, dev))) {
dev->irq = 11;
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, 11);
+ pci_dev_put(dev);
}
}
#endif /* CONFIG_PCI */
-
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: how do I this in sysfs?
On Mon, Aug 29, 2005 at 12:24:18PM -0500, Miller, Mike (OS Dev) wrote: > > > This is after my minimal sas transport class, please also > > read the thread about it on linux-scsi > > > In the referenced code for using sysfs, there only appear to be methods > for reading attributes. How about if we want to cause a command to > get written out to the hardware? Do we do something like this? > > /* get a semaphore keep everyone else out while we're working, >and hope like hell that all the other processes are playing >nice and using the semaphore too, or else we're hosed. */ > > get_some_kind_of_semaphore(); try flock() on the /sys/blah/blah/ directory. That should keep userspace happy. I think it only takes a small sysfs patch to make this work (or it might work today, don't remember, sorry...) Or look into using configfs instead. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] arch: pci_find_device remove (ppc/kernel/pci.c)
Generated in 2.6.13-rc6-mm2 kernel version.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
pci.c | 21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/ppc/kernel/pci.c b/arch/ppc/kernel/pci.c
--- a/arch/ppc/kernel/pci.c
+++ b/arch/ppc/kernel/pci.c
@@ -517,7 +517,7 @@ pcibios_allocate_resources(int pass)
u16 command;
struct resource *r;
- while ((dev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
+ for_each_pci_dev(dev) {
pci_read_config_word(dev, PCI_COMMAND, );
for (idx = 0; idx < 6; idx++) {
r = >resource[idx];
@@ -554,7 +554,7 @@ pcibios_assign_resources(void)
int idx;
struct resource *r;
- while ((dev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
+ for_each_pci_dev(dev) {
int class = dev->class >> 8;
/* Don't touch classless devices and host bridges */
@@ -880,14 +880,15 @@ pci_device_from_OF_node(struct device_no
*/
if (!pci_to_OF_bus_map)
return 0;
- while ((dev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
- if (pci_to_OF_bus_map[dev->bus->number] != *bus)
- continue;
- if (dev->devfn != *devfn)
- continue;
- *bus = dev->bus->number;
- return 0;
- }
+
+ for_each_pci_dev(dev)
+ if (pci_to_OF_bus_map[dev->bus->number] == *bus &&
+ dev->devfn == *devfn) {
+ *bus = dev->bus->number;
+ pci_dev_put(dev);
+ return 0;
+ }
+
return -ENODEV;
}
-
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 7/7] arch: pci_find_device remove (sparc64/kernel/ebus.c)
Generated in 2.6.13-rc6-mm2 kernel version.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
ebus.c | 17 ++---
1 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/sparc64/kernel/ebus.c b/arch/sparc64/kernel/ebus.c
--- a/arch/sparc64/kernel/ebus.c
+++ b/arch/sparc64/kernel/ebus.c
@@ -527,19 +527,13 @@ static struct pci_dev *find_next_ebus(st
{
struct pci_dev *pdev = start;
- do {
- pdev = pci_find_device(PCI_VENDOR_ID_SUN, PCI_ANY_ID, pdev);
- if (pdev &&
- (pdev->device == PCI_DEVICE_ID_SUN_EBUS ||
-pdev->device == PCI_DEVICE_ID_SUN_RIO_EBUS))
+ while (pdev = pci_get_device(PCI_VENDOR_ID_SUN, PCI_ANY_ID, pdev))
+ if (pdev->device == PCI_DEVICE_ID_SUN_EBUS ||
+ pdev->device == PCI_DEVICE_ID_SUN_RIO_EBUS)
break;
- } while (pdev != NULL);
-
- if (pdev && (pdev->device == PCI_DEVICE_ID_SUN_RIO_EBUS))
- *is_rio_p = 1;
- else
- *is_rio_p = 0;
+ *is_rio_p = !!(pdev && (pdev->device == PCI_DEVICE_ID_SUN_RIO_EBUS));
+
return pdev;
}
@@ -637,6 +631,7 @@ void __init ebus_init(void)
ebus->is_rio = is_rio;
++num_ebus;
}
+ pci_dev_put(pdev); /* XXX for the case, when ebusnd is 0, is it OK? */
#ifdef CONFIG_SUN_AUXIO
auxio_probe();
-
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/7] arch: pci_find_device remove (alpha/kernel/sys_sio.c)
Generated in 2.6.13-rc6-mm2 kernel version.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
sys_sio.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/alpha/kernel/sys_sio.c b/arch/alpha/kernel/sys_sio.c
--- a/arch/alpha/kernel/sys_sio.c
+++ b/arch/alpha/kernel/sys_sio.c
@@ -105,7 +105,7 @@ sio_collect_irq_levels(void)
struct pci_dev *dev = NULL;
/* Iterate through the devices, collecting IRQ levels. */
- while ((dev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
+ for_each_pci_dev(dev) {
if ((dev->class >> 16 == PCI_BASE_CLASS_BRIDGE) &&
(dev->class >> 8 != PCI_CLASS_BRIDGE_PCMCIA))
continue;
@@ -229,8 +229,8 @@ alphabook1_init_pci(void)
*/
dev = NULL;
- while ((dev = pci_find_device(PCI_VENDOR_ID_NCR, PCI_ANY_ID, dev))) {
-if (dev->device == PCI_DEVICE_ID_NCR_53C810
+ while ((dev = pci_get_device(PCI_VENDOR_ID_NCR, PCI_ANY_ID, dev))) {
+ if (dev->device == PCI_DEVICE_ID_NCR_53C810
|| dev->device == PCI_DEVICE_ID_NCR_53C815
|| dev->device == PCI_DEVICE_ID_NCR_53C820
|| dev->device == PCI_DEVICE_ID_NCR_53C825) {
-
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/7] arch: pci_find_device remove (frv/mb93090-mb00/pci-frv.c)
Generated in 2.6.13-rc6-mm2 kernel version.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
pci-frv.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/frv/mb93090-mb00/pci-frv.c b/arch/frv/mb93090-mb00/pci-frv.c
--- a/arch/frv/mb93090-mb00/pci-frv.c
+++ b/arch/frv/mb93090-mb00/pci-frv.c
@@ -142,9 +142,7 @@ static void __init pcibios_allocate_reso
u16 command;
struct resource *r, *pr;
- while (dev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, dev),
- dev != NULL
- ) {
+ for_each_pci_dev(dev) {
pci_read_config_word(dev, PCI_COMMAND, );
for(idx = 0; idx < 6; idx++) {
r = >resource[idx];
@@ -188,9 +186,7 @@ static void __init pcibios_assign_resour
int idx;
struct resource *r;
- while (dev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, dev),
- dev != NULL
- ) {
+ for_each_pci_dev(dev) {
int class = dev->class >> 8;
/* Don't touch classless devices and host bridges */
-
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/7] arch: pci_find_device remove (frv/mb93090-mb00/pci-irq.c)
Generated in 2.6.13-rc6-mm2 kernel version.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
pci-irq.c |4 +---
1 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/frv/mb93090-mb00/pci-irq.c b/arch/frv/mb93090-mb00/pci-irq.c
--- a/arch/frv/mb93090-mb00/pci-irq.c
+++ b/arch/frv/mb93090-mb00/pci-irq.c
@@ -48,9 +48,7 @@ void __init pcibios_fixup_irqs(void)
struct pci_dev *dev = NULL;
uint8_t line, pin;
- while (dev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, dev),
- dev != NULL
- ) {
+ for_each_pci_dev(dev) {
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, );
if (pin) {
dev->irq =
pci_bus0_irq_routing[PCI_SLOT(dev->devfn)][pin - 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/
Dynamic tick for 2.6.14 - what's the plan?
The controversy over the introduction of CONFIG_HZ demonstrated the urgency of getting a dynamic tick solution merged before 2.6.14. Anyone care to give a status report? Con, do you feel that the last version you posted is ready to go in? Lee - 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/7] arch: pci_find_device remove (alpha/kernel/sys_alcor.c)
Generated in 2.6.13-rc6-mm2 kernel version.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
sys_alcor.c |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/alpha/kernel/sys_alcor.c b/arch/alpha/kernel/sys_alcor.c
--- a/arch/alpha/kernel/sys_alcor.c
+++ b/arch/alpha/kernel/sys_alcor.c
@@ -254,7 +254,7 @@ alcor_init_pci(void)
* motherboard, by looking for a 21040 TULIP in slot 6, which is
* built into XLT and BRET/MAVERICK, but not available on ALCOR.
*/
- dev = pci_find_device(PCI_VENDOR_ID_DEC,
+ dev = pci_get_device(PCI_VENDOR_ID_DEC,
PCI_DEVICE_ID_DEC_TULIP,
NULL);
if (dev && dev->devfn == PCI_DEVFN(6,0)) {
@@ -262,6 +262,7 @@ alcor_init_pci(void)
printk(KERN_INFO "%s: Detected AS500 or XLT motherboard.\n",
__FUNCTION__);
}
+ pci_dev_put(dev);
}
-
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] drivers/net/s2io.h - lvalue fix
Hi all ,
Sorry if I don't send this patch to the maintainer of s2io, but I don't
know who is he.
This patch is based on Kernel 2.6.13 release from the Linus tree.
Is there a process to send patch to the mailing list ?
Best regards,
Stephane
--
Stephane Wirtel <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
diff --git a/drivers/net/s2io.h b/drivers/net/s2io.h
--- a/drivers/net/s2io.h
+++ b/drivers/net/s2io.h
@@ -762,8 +762,8 @@ static inline u64 readq(void __iomem *ad
{
u64 ret = 0;
ret = readl(addr + 4);
- (u64) ret <<= 32;
- (u64) ret |= readl(addr);
+ ret <<= 32;
+ ret |= readl(addr);
return ret;
}
[PATCH 0/7] arch: pci_find_device remove
Set of patches, which removes pci_find_device from arch subtree. alpha/kernel/sys_alcor.c|3 ++- alpha/kernel/sys_sio.c |6 +++--- frv/mb93090-mb00/pci-frv.c |8 ++-- frv/mb93090-mb00/pci-irq.c |4 +--- ppc/kernel/pci.c| 21 +++-- ppc/platforms/85xx/mpc85xx_cds_common.c | 11 +++ sparc64/kernel/ebus.c | 17 ++--- 7 files changed, 32 insertions(+), 38 deletions(-) - 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: ppp_mppe+pptp for 2.6.14?
On Mon, Aug 29, 2005 at 06:12:20PM +0100, Daniel Drake wrote: > Hi, > > If there are no known issues it would be nice to push this for inclusion in > 2.6.14. The relevant patches from -mm are named > ppp_mppe-add-ppp-mppe-encryption-module.patch and > ppp_mppe-add-ppp-mppe-encryption-module-update.patch > > Judging by the feedback I get from Gentoo users, there is high demand for > this :) This patch has been working fine for me for several weeks now. I've asked James Cameron, pptp project lead, to try a test to force the server side to issue a CCP DOWN, to make sure the client-side kernel ppp_generic module does the right thing and drops packets. I don't have a testbed that allows such, but he does. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.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: [PATCH] ppc32 :Added PCI support for MPC83xx
On Aug 29, 2005, at 1:07 PM, Dan Malek wrote:
On Aug 29, 2005, at 1:42 PM, Kumar Gala wrote:
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c
b/arch/ppc/platforms/83xx/mpc834x_sys.c
--- a/arch/ppc/platforms/83xx/mpc834x_sys.c
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
@@ -62,9 +62,29 @@ extern unsigned long total_memory;/* in
unsigned char __res[sizeof (bd_t)];
#ifdef CONFIG_PCI
-#error "PCI is not supported"
-/* NEED mpc83xx_map_irq & mpc83xx_exclude_device
- see platforms/85xx/mpc85xx_ads_common.c */
+int
+mpc83xx_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned
char pin)
+{
+static char pci_irq_table[][4] =
+/*
+ * PCI IDSEL/INTPIN->INTLINE
+ * A B C D
+ */
+{
+{PIRQA, PIRQB, PIRQC, PIRQD}, /* idsel 0x11 */
+{PIRQC, PIRQD, PIRQA, PIRQB}, /* idsel 0x12 */
+{PIRQD, PIRQA, PIRQB, PIRQC} /* idsel 0x13 */
+};
+
+const long min_idsel = 0x11, max_idsel = 0x13, irqs_per_slot =
4;
+return PCI_IRQ_TABLE_LOOKUP;
+}
+
+int
+mpc83xx_exclude_device(u_char bus, u_char devfn)
+{
+return PCIBIOS_SUCCESSFUL;
+}
#endif /* CONFIG_PCI */
Shouldn't this be in the PQ2FADS board specific file? Not everyone
is going to map IDSELs and IRQs this way.
mpc834x_sys is a board specific file.. This is stupid freescale
naming. The board was called MPC8349 SYS... Not sure what its called
now.
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.h
b/arch/ppc/platforms/83xx/mpc834x_sys.h
--- a/arch/ppc/platforms/83xx/mpc834x_sys.h
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.h
@@ -26,7 +26,7 @@
#define VIRT_IMMRBAR((uint)0xfe00)
#define BCSR_PHYS_ADDR((uint)0xf800)
-#define BCSR_SIZE((uint)(32 * 1024))
+#define BCSR_SIZE((uint)(128 * 1024))
#define BCSR_MISC_REG2_OFF0x07
#define BCSR_MISC_REG2_PORESET0x01
@@ -34,23 +34,25 @@
#define BCSR_MISC_REG3_OFF0x08
#define BCSR_MISC_REG3_CNFLOCK0x80
-#ifdef CONFIG_PCI
-/* PCI interrupt controller */
-#define PIRQAMPC83xx_IRQ_IRQ4
-#define PIRQBMPC83xx_IRQ_IRQ5
-#define PIRQCMPC83xx_IRQ_IRQ6
-#define PIRQDMPC83xx_IRQ_IRQ7
-
-#define MPC834x_SYS_PCI1_LOWER_IO0x
-#define MPC834x_SYS_PCI1_UPPER_IO0x00ff
-
-#define MPC834x_SYS_PCI1_LOWER_MEM 0x8000
-#define MPC834x_SYS_PCI1_UPPER_MEM 0x9fff
-
-#define MPC834x_SYS_PCI1_IO_BASE 0xe200
-#define MPC834x_SYS_PCI1_MEM_OFFSET 0x
-
-#define MPC834x_SYS_PCI1_IO_SIZE 0x0100
-#endif /* CONFIG_PCI */
+#define PIRQAMPC83xx_IRQ_EXT4
+#define PIRQBMPC83xx_IRQ_EXT5
+#define PIRQCMPC83xx_IRQ_EXT6
+#define PIRQDMPC83xx_IRQ_EXT7
The same thing with these BCSRs and IRQ mappings FADS specific.
Same comment as above.
+
+#define MPC83xx_PCI1_LOWER_IO0x
+#define MPC83xx_PCI1_UPPER_IO0x00ff
+#define MPC83xx_PCI1_LOWER_MEM0x8000
+#define MPC83xx_PCI1_UPPER_MEM0x9fff
+#define MPC83xx_PCI1_IO_BASE0xe200
+#define MPC83xx_PCI1_MEM_OFFSET0x
+#define MPC83xx_PCI1_IO_SIZE0x0100
+
+#define MPC83xx_PCI2_LOWER_IO0x
+#define MPC83xx_PCI2_UPPER_IO0x00ff
+#define MPC83xx_PCI2_LOWER_MEM0xa000
+#define MPC83xx_PCI2_UPPER_MEM0xbfff
+#define MPC83xx_PCI2_IO_BASE0xe300
+#define MPC83xx_PCI2_MEM_OFFSET0x
+#define MPC83xx_PCI2_IO_SIZE0x0100
These should be generic to everyone, and could be
in the ppc83xx_pci.h file. Maybe surround them with
#ifndef so a board specific file could move the addresses
if they wanted? I don't think an #ifndef is needed for each
define, maybe just #fndef MPC83xx_PCI1_LOWER_MEM
and let the board define everything if they want anything different.
This is just like how we did 85xx. The board specific file has to
fill out these defines for its memory map. I'm guess this is all
confusion based on the name, if its not just that let me know.
- kumar
-
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] acpi: Handle cpu_index greater than 256 properly in processor_core.c
>-Original Message- >From: Ingo Oeser [mailto:[EMAIL PROTECTED] >Sent: Saturday, August 27, 2005 5:23 AM >To: Pallipadi, Venkatesh >Cc: linux-kernel; Andrew Morton; Brown, Len >Subject: Re: [PATCH] acpi: Handle cpu_index greater than 256 >properly in processor_core.c > >Hi Venkatesh, > >On Saturday 27 August 2005 02:07, Venkatesh Pallipadi wrote: >> Fix convert_acpiid_to_cpu function to handle cpu_index >greater than 256. This >> patch also prevents a warning in IA64 cross-compile of this file >> (drivers/acpi/processor_core.c:517: warning: comparison is >always false due >> to limited range of data type). > >Why don't you just change the datatype to "unsigned int" and >the return failure value to NR_CPUS? > >That reduces the code changes and leaves the code quite clear. >It should also reduce compiled code size by some bytes, but I'm not >sure about that one. > Yes. It can be done. But to me, the current patch is more cleaner. I don't think we should mix up the cpu_index and error return value. Thanks, Venki - 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/
