Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 3

[Jim MacBaine]

On 8/4/05, Con Kolivas <[EMAIL PROTECTED]> wrote:

> Ok perhaps on the resume side instead. When trying to resume can you try
> booting with 'dyntick=disable'. Note this isn't meant to be a long term fix
> but once we figure out where the problem is we should be able to code around
> it.

Sorry, no luck. 

I tried dyntick=disable and dyntick=noapic on resume time.  I also
tried suspend and resume after the system has been started with
dyntick=noapic: Same result.

As soon as I tell swsusp2 to discard its image, the system will come
up flawlessly.

Regards,
Jim
-
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 No-Idle-Hz aka Dynamic-Ticks 3

[Jan De Luyck]

On Thursday 04 August 2005 07:07, Con Kolivas wrote:
> On Thu, 4 Aug 2005 03:09 pm, Jan De Luyck wrote:
> > On Wednesday 03 August 2005 07:59, Con Kolivas wrote:
> > > This is the dynamic ticks patch for i386 as written by Tony Lindgen
> > > <[EMAIL PROTECTED]> and Tuukka Tikkanen
> > > <[EMAIL PROTECTED]>. Patch for 2.6.13-rc5
> >
> > On a weird sidenote: my synaptics touchpad seems to not-like dyntick very
> > much. When starting with a dyntick enabled kernel I get when psmouse.ko
> > is loaded:
> >
> > Aug  4 06:45:47 precious kernel: Synaptics claims to have extended
> > capabilities, but I'm not able to read them.<3>Unable to initialize
> > Synaptics hardware. Aug  4 06:45:47 precious kernel: input: PS/2
> > Synaptics TouchPad on isa0060/serio1
> >
> > subsequently, X fails to start too (touchpad is set as corepointer)
> >
> > reloading the module right then and there solves the problem:
> >
> > Aug  4 06:47:47 precious kernel: Synaptics Touchpad, model: 1, fw: 5.8,
> > id: 0x9d48b1, caps: 0x904713/0x4006 Aug  4 06:47:47 precious kernel:
> > input: SynPS/2 Synaptics TouchPad on isa0060/serio1
> >
> > Also, booting the same (but non-patched) kernel gives me a clean boot:
> >
> > Aug  4 06:56:42 precious kernel: Synaptics Touchpad, model: 1, fw: 5.8,
> > id: 0x9d48b1, caps: 0x904713/0x4006 Aug  4 06:56:42 precious kernel:
> > input: SynPS/2 Synaptics TouchPad on isa0060/serio1
> >
> > This is constantly reproducable for me. I guess some timing issue
> > somewhere?
>
> Did you try without the apic option or disable it at runtime? The apic
> option is proving more problems than not so far for people that have tried
> it.

The above was with apic enabled. With apic disabled, same story tho different 
boot-time message:

$ cat /sys/../state
suitable:   1
enabled:1
apic suitable:  1
using APIC: 0

dmesg gives:
Unable to query Synaptics hardware.
input: PS/2 Synaptics TouchPad on isa0060/serio1

and X refuses to start. Same resolution, just reload psmouse.

Jan
-- 
The default Magic Word, "Abracadabra", actually is a corruption of the
Hebrew phrase "ha-Bracha dab'ra" which means "pronounce the blessing".
-
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: [ACPI] [PATCH] PNPACPI: fix types when decoding ACPI resources [resend]

[Kenji Kaneshige]

Hi Bjorn,

Thank you very much for the new patch
and I'm very sorry for troubling you.

The patch looks very good to me.

Thanks,
Kenji Kaneshige


Bjorn Helgaas wrote:

On Tuesday 02 August 2005 7:05 pm, Kenji Kaneshige wrote:


This breaks the following patch that is already included into -mm
tree.

http://sourceforge.net/mailarchive/forum.php?thread_id=7844247_id=6102

I think we need to check if acpi_register_gsi() succeeded or not.



You're absolutely right.  I was just based off a Linus tree, non -mm,
and didn't notice that your patch conflicted.  How about the following
(based on 2.6.13-rc4-mm1)?  I moved the acpi_register_gsi() into
pnpacpi_parse_allocated_irqresource(), which I think is nice because
the test for failure is right next to the call.



PNPACPI: fix types when decoding ACPI resources

Use types that match the ACPI resource structures.  Previously
the u64 value from an RSTYPE_ADDRESS64 was passed as an int,
which corrupts the value.

This is one of the things that prevents 8250_pnp from working
on HP ia64 boxes.  After 8250_pnp works, we will be able to
remove 8250_acpi.c.

Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>

Index: work-mm/drivers/pnp/pnpacpi/rsparser.c
===
--- work-mm.orig/drivers/pnp/pnpacpi/rsparser.c 2005-08-02 09:39:25.0 
-0600
+++ work-mm/drivers/pnp/pnpacpi/rsparser.c  2005-08-03 09:31:05.0 
-0600
@@ -73,25 +73,28 @@
 }
 
 static void

-pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, int irq)
+pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, u32 gsi,
+   int edge_level, int active_high_low)
 {
int i = 0;
+   int irq;
while (!(res->irq_resource[i].flags & IORESOURCE_UNSET) &&
i < PNP_MAX_IRQ)
i++;
if (i < PNP_MAX_IRQ) {
res->irq_resource[i].flags = IORESOURCE_IRQ;  //Also clears 
_UNSET flag
+   irq = acpi_register_gsi(gsi, edge_level, active_high_low);
if (irq < 0) {
res->irq_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
-   res->irq_resource[i].start =(unsigned long) irq;
-   res->irq_resource[i].end = (unsigned long) irq;
+   res->irq_resource[i].start = irq;
+   res->irq_resource[i].end = irq;
}
 }
 
 static void

-pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table * res, int dma)
+pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table * res, u32 dma)
 {
int i = 0;
while (i < PNP_MAX_DMA &&
@@ -103,14 +106,14 @@
res->dma_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
-   res->dma_resource[i].start =(unsigned long) dma;
-   res->dma_resource[i].end = (unsigned long) dma;
+   res->dma_resource[i].start = dma;
+   res->dma_resource[i].end = dma;
}
 }
 
 static void

 pnpacpi_parse_allocated_ioresource(struct pnp_resource_table * res,
-   int io, int len)
+   u32 io, u32 len)
 {
int i = 0;
while (!(res->port_resource[i].flags & IORESOURCE_UNSET) &&
@@ -122,14 +125,14 @@
res->port_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
-   res->port_resource[i].start = (unsigned long) io;
-   res->port_resource[i].end = (unsigned long)(io + len - 1);
+   res->port_resource[i].start = io;
+   res->port_resource[i].end = io + len - 1;
}
 }
 
 static void

 pnpacpi_parse_allocated_memresource(struct pnp_resource_table * res,
-   int mem, int len)
+   u64 mem, u64 len)
 {
int i = 0;
while (!(res->mem_resource[i].flags & IORESOURCE_UNSET) &&
@@ -141,8 +144,8 @@
res->mem_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
-   res->mem_resource[i].start = (unsigned long) mem;
-   res->mem_resource[i].end = (unsigned long)(mem + len - 1);
+   res->mem_resource[i].start = mem;
+   res->mem_resource[i].end = mem + len - 1;
}
 }
 
@@ -156,10 +159,10 @@

case ACPI_RSTYPE_IRQ:
if ((res->data.irq.number_of_interrupts > 0) &&
valid_IRQ(res->data.irq.interrupts[0])) {
-			pnpacpi_parse_allocated_irqresource(res_table, 
-acpi_register_gsi(res->data.irq.interrupts[0],

-   res->data.irq.edge_level,
-   res->data.irq.active_high_low));
+   pnpacpi_parse_allocated_irqresource(res_table,
+   res->data.irq.interrupts[0],
+   res->data.irq.edge_level,
+   

[UPDATE PATCH] push rounding up of relative request to schedule_timeout()

[Nishanth Aravamudan]

On 03.08.2005 [17:51:47 -0700], Nishanth Aravamudan wrote:
> On 03.08.2005 [16:20:57 +0200], Roman Zippel wrote:
> > Hi,
> > 
> > On Mon, 1 Aug 2005, Nishanth Aravamudan wrote:
> > 
> > > +unsigned int __sched schedule_timeout_msecs(unsigned int timeout_msecs)
> > > +{
> > > + unsigned long expire_jifs;
> > > +
> > > + if (timeout_msecs == MAX_SCHEDULE_TIMEOUT_MSECS) {
> > > + expire_jifs = MAX_SCHEDULE_TIMEOUT;
> > > + } else {
> > > + /*
> > > +  * msecs_to_jiffies() is a unit conversion, which truncates
> > > +  * (rounds down), so we need to add 1.
> > > +  */
> > > + expire_jifs = msecs_to_jiffies(timeout_msecs) + 1;
> > > + }
> > > +
> > > + expire_jifs = schedule_timeout(expire_jifs);
> > > +
> > > + /*
> > > +  * don't need to add 1 here, even though there is truncation,
> > > +  * because we will add 1 if/when the value is sent back in
> > > +  */
> > > + return jiffies_to_msecs(expire_jifs);
> > > +}
> > 
> > As I already mentioned for msleep_interruptible this is a really terrible 
> > interface.
> > The "jiffies_to_msecs(msecs_to_jiffies(timeout_msecs) + 1)" case (when the 
> > process is immediately woken up again) makes the caller suspectible to 
> > timeout manipulations and requires constant reauditing, that no caller 
> > gets it wrong, so it's better to avoid this error source completely.
> 
> After some thought today, I realized the +1 case is not specific to
> milliseconds. It's just that it's only being done *correctly* in the
> milliseconds case...I think ;)



> Description: Ensure that schedule_timeout() requests can not possibly
> expire early in the timeout case, by adding the requested relative jiffy
> value to the next value of jiffies. Currently, by adding to the current
> value of jiffies, we might actually expire a jiffy too early (in a
> corner case).

Sorry, I forgot that sys_nanosleep() also always adds 1 to the request
(to account for this same issue, I believe, as POSIX demands no early
return from nanosleep() calls). There are some other locations where
similar

+ (t.tv_sec || t.tv_nsec)

rounding-ups occur. I'll fix those separately if this patch goes in.  I
change the one in sys_nanosleep() below to maintain the same latency as
we currently have. I also screwed up my layout in the previous
submission, sorry about that.

Description: Ensure that schedule_timeout() requests can not possibly
expire early in the timeout case, by adding the requested relative jiffy
value to the next value of jiffies. Currently, by adding to the current
value of jiffies, we might actually expire a jiffy too early (in a
corner case). Modify the callers of schedule_timeout() in timer.c to not
add 1 themselves.

Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>

---

 timer.c |   13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)

--- 2.6.13-rc4-dev/kernel/timer.c   2005-08-01 12:31:53.0 -0700
+++ 2.6.13-rc5/kernel/timer.c   2005-08-03 22:05:16.0 -0700
@@ -1134,7 +1134,7 @@ fastcall signed long __sched schedule_ti
}
}
 
-   expire = timeout + jiffies;
+   expire = timeout + jiffies + 1;
 
init_timer();
timer.expires = expire;
@@ -1190,9 +1190,10 @@ unsigned int __sched schedule_timeout_ms
} else {
/*
 * msecs_to_jiffies() is a unit conversion, which truncates
-* (rounds down), so we need to add 1.
+* (rounds down), so we need to add 1, but this is taken
+* care of by schedule_timeout() now.
 */
-   expire_jifs = msecs_to_jiffies(timeout_msecs) + 1;
+   expire_jifs = msecs_to_jiffies(timeout_msecs);
}
 
expire_jifs = schedule_timeout(expire_jifs);
@@ -1286,7 +1287,7 @@ asmlinkage long sys_nanosleep(struct tim
if ((t.tv_nsec >= 10L) || (t.tv_nsec < 0) || (t.tv_sec < 0))
return -EINVAL;
 
-   expire = timespec_to_jiffies() + (t.tv_sec || t.tv_nsec);
+   expire = timespec_to_jiffies();
current->state = TASK_INTERRUPTIBLE;
expire = schedule_timeout(expire);
 
@@ -1675,7 +1676,7 @@ unregister_time_interpolator(struct time
  */
 void msleep(unsigned int msecs)
 {
-   unsigned long timeout = msecs_to_jiffies(msecs) + 1;
+   unsigned long timeout = msecs_to_jiffies(msecs);
 
while (timeout) {
set_current_state(TASK_UNINTERRUPTIBLE);
@@ -1691,7 +1692,7 @@ EXPORT_SYMBOL(msleep);
  */
 unsigned long msleep_interruptible(unsigned int msecs)
 {
-   unsigned long timeout = msecs_to_jiffies(msecs) + 1;
+   unsigned long timeout = msecs_to_jiffies(msecs);
 
while (timeout && !signal_pending(current)) {
set_current_state(TASK_INTERRUPTIBLE);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  

Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 3

[Con Kolivas]

On Thu, 4 Aug 2005 03:09 pm, Jan De Luyck wrote:
> On Wednesday 03 August 2005 07:59, Con Kolivas wrote:
> > This is the dynamic ticks patch for i386 as written by Tony Lindgen
> > <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>.
> > Patch for 2.6.13-rc5
>
> On a weird sidenote: my synaptics touchpad seems to not-like dyntick very
> much. When starting with a dyntick enabled kernel I get when psmouse.ko is
> loaded:
>
> Aug  4 06:45:47 precious kernel: Synaptics claims to have extended
> capabilities, but I'm not able to read them.<3>Unable to initialize
> Synaptics hardware. Aug  4 06:45:47 precious kernel: input: PS/2 Synaptics
> TouchPad on isa0060/serio1
>
> subsequently, X fails to start too (touchpad is set as corepointer)
>
> reloading the module right then and there solves the problem:
>
> Aug  4 06:47:47 precious kernel: Synaptics Touchpad, model: 1, fw: 5.8, id:
> 0x9d48b1, caps: 0x904713/0x4006 Aug  4 06:47:47 precious kernel: input:
> SynPS/2 Synaptics TouchPad on isa0060/serio1
>
> Also, booting the same (but non-patched) kernel gives me a clean boot:
>
> Aug  4 06:56:42 precious kernel: Synaptics Touchpad, model: 1, fw: 5.8, id:
> 0x9d48b1, caps: 0x904713/0x4006 Aug  4 06:56:42 precious kernel: input:
> SynPS/2 Synaptics TouchPad on isa0060/serio1
>
> This is constantly reproducable for me. I guess some timing issue
> somewhere?

Did you try without the apic option or disable it at runtime? The apic option 
is proving more problems than not so far for people that have tried it.

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] i386 No-Idle-Hz aka Dynamic-Ticks 3

[Jan De Luyck]

On Wednesday 03 August 2005 07:59, Con Kolivas wrote:
> This is the dynamic ticks patch for i386 as written by Tony Lindgen
> <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>.
> Patch for 2.6.13-rc5

On a weird sidenote: my synaptics touchpad seems to not-like dyntick very much. 
When starting with a dyntick enabled kernel I get when psmouse.ko is loaded:

Aug  4 06:45:47 precious kernel: Synaptics claims to have extended 
capabilities, but I'm not able to read them.<3>Unable to initialize Synaptics 
hardware.
Aug  4 06:45:47 precious kernel: input: PS/2 Synaptics TouchPad on 
isa0060/serio1

subsequently, X fails to start too (touchpad is set as corepointer)

reloading the module right then and there solves the problem:

Aug  4 06:47:47 precious kernel: Synaptics Touchpad, model: 1, fw: 5.8, id: 
0x9d48b1, caps: 0x904713/0x4006
Aug  4 06:47:47 precious kernel: input: SynPS/2 Synaptics TouchPad on 
isa0060/serio1

Also, booting the same (but non-patched) kernel gives me a clean boot:

Aug  4 06:56:42 precious kernel: Synaptics Touchpad, model: 1, fw: 5.8, id: 
0x9d48b1, caps: 0x904713/0x4006
Aug  4 06:56:42 precious kernel: input: SynPS/2 Synaptics TouchPad on 
isa0060/serio1

This is constantly reproducable for me. I guess some timing issue somewhere?

Jan

-- 
A good name lost is seldom regained.  When character is gone,
all is gone, and one of the richest jewels of life is lost forever.
-- J. Hawes
-
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/3] cpqarray: ioctl support to configure LUNs dynamically

[Saripalli, Venkata Ramanamurthy (STSD)]

Patch 2 of 3
This patch adds support for IDAREGNEWDISK, IDADEREGDISK, IDAGETLOGINFO
ioctls required
to configure LUNs dynamically on SA4200 controller using ACU.

Please consider this for inclusion.

Signed-off-by: Ramanamurthy Saripalli <[EMAIL PROTECTED]>

 cpqarray.c  |  281
++--
 cpqarray.h  |1 
 ida_ioctl.h |   10 ++
 3 files changed, 286 insertions(+), 6 deletions(-)

--
diff -burpN old/drivers/block/cpqarray.c new2/drivers/block/cpqarray.c
--- old/drivers/block/cpqarray.c2005-06-28 23:26:06.0
-0400
+++ new2/drivers/block/cpqarray.c   2005-06-28 23:42:22.0
-0400
@@ -45,13 +45,13 @@
 
 #define SMART2_DRIVER_VERSION(maj,min,submin)
((maj<<16)|(min<<8)|(submin))
 
-#define DRIVER_NAME "Compaq SMART2 Driver (v 2.6.0)"
-#define DRIVER_VERSION SMART2_DRIVER_VERSION(2,6,0)
+#define DRIVER_NAME "Compaq SMART2 Driver (v 2.6.1)"
+#define DRIVER_VERSION SMART2_DRIVER_VERSION(2,6,1)
 
 /* Embedded module documentation macros - see modules.h */
 /* Original author Chris Frantz - Compaq Computer Corporation */
 MODULE_AUTHOR("Compaq Computer Corporation");
-MODULE_DESCRIPTION("Driver for Compaq Smart2 Array Controllers version
2.6.0");
+MODULE_DESCRIPTION("Driver for Compaq Smart2 Array Controllers version
2.6.1");
 MODULE_LICENSE("GPL");
 
 #include "cpqarray.h"
@@ -143,6 +143,8 @@ static int pollcomplete(int ctlr);
 static void getgeometry(int ctlr);
 static void start_fwbk(int ctlr);
 
+static int register_new_disk(ctlr_info_t *h, int logovl);
+static int deregister_disk(struct gendisk *disk);
 static cmdlist_t * cmd_alloc(ctlr_info_t *h, int get_from_pool);
 static void cmd_free(ctlr_info_t *h, cmdlist_t *c, int got_from_pool);
 
@@ -157,6 +159,14 @@ static int sendcmd(
unsigned int blk,
unsigned int blkcnt,
unsigned int log_unit );
+static int sendcmd_withirq(
+__u8cmd,
+int ctlr,
+void*buff,
+size_t  size,
+unsigned int blk,
+unsigned int blkcnt,
+unsigned int log_unit );
 
 static int ida_open(struct inode *inode, struct file *filep);
 static int ida_release(struct inode *inode, struct file *filep);
@@ -354,7 +364,10 @@ static void __devexit cpqarray_remove_on
kfree(hba[i]->cmd_pool_bits);
for(j = 0; j < NWD; j++) {
if (ida_gendisk[i][j]->flags & GENHD_FL_UP)
+   {
del_gendisk(ida_gendisk[i][j]);
+   }
+
devfs_remove("ida/c%dd%d",i,j);
put_disk(ida_gendisk[i][j]);
}
@@ -1141,8 +1154,11 @@ static int ida_ioctl(struct inode *inode
 {
drv_info_t *drv = get_drv(inode->i_bdev->bd_disk);
ctlr_info_t *host = get_host(inode->i_bdev->bd_disk);
+   struct gendisk *disk = inode->i_bdev->bd_disk;
int error;
int diskinfo[4];
+int ctlr = MAJOR(inode->i_rdev) - COMPAQ_SMART2_MAJOR;
+int dsk  = MINOR(inode->i_rdev) >> NWD_SHIFT;
struct hd_geometry __user *geo = (struct hd_geometry __user
*)arg;
ida_ioctl_t __user *io = (ida_ioctl_t __user *)arg;
ida_ioctl_t *my_io;
@@ -1212,15 +1228,268 @@ out_passthru:
return -EFAULT;
return(0);
}   
+   case IDADEREGDISK:  
+return( deregister_disk(disk));
+case IDAREGNEWDISK:
+{
+int logvol = arg;
+return register_new_disk(host, logvol);
+}
 
+case IDAGETLOGINFO:
+   {
+   idaLogvolInfo_struct luninfo;
+
+luninfo.LogVolID = dsk; 
+luninfo.num_opens = hba[ctlr]->drv[dsk].usage_count;
+ 
+/* count partitions 1 to 15 with sizes > 0 */
+/*start = (dsk << NWD_SHIFT);
+for(i=1; i sizes[minor] != 0)
+num_parts++;
+}
+luninfo.num_parts = num_parts;*/
+if (copy_to_user((void *) arg, ,
+sizeof( idaLogvolInfo_struct) ))
+return -EFAULT;
+return(0);
+   }
default:
+printk(KERN_WARNING "cpqarray: calling default
ioctl\n");
return -EINVAL;
}

 }
-/*
- * ida_ctlr_ioctl is for passing commands to the controller from
userspace.
- * The command block (io) has already been copied to kernel space for
us,
+
+static int sendcmd_withirq(
+__u8cmd,
+int ctlr,
+void*buff,
+size_t  size,
+unsigned int blk,
+unsigned int blkcnt,
+unsigned int log_unit )
+{
+cmdlist_t *c;
+unsigned long flags;
+ctlr_info_t *info_p = hba[ctlr];
+//DECLARE_COMPLETION(wait);
+
+
+c = cmd_alloc(info_p, 0);
+if(!c)

[PATCH 3/3] cpqarray: per disk request queue in 2.6 kernel

[Saripalli, Venkata Ramanamurthy (STSD)]

Patch 3 of 3
This patch adds support for per disk request queue in 2.6 kernel. This
solves the
kernel panic while removing the cpqarray with more than one LUN
configured.

Please consider this for inclusion.

Signed-off-by: Ramanamurthy Saripalli <[EMAIL PROTECTED]>

 cpqarray.c |   51 +++
 cpqarray.h |1 +
 2 files changed, 48 insertions(+), 4 deletions(-)

---
diff -burpN old/drivers/block/cpqarray.c new3/drivers/block/cpqarray.c
--- old/drivers/block/cpqarray.c2005-06-28 23:26:06.0
-0400
+++ new3/drivers/block/cpqarray.c   2005-06-29 00:01:22.0
-0400
@@ -45,13 +45,13 @@
 
 #define SMART2_DRIVER_VERSION(maj,min,submin)
((maj<<16)|(min<<8)|(submin))
 
-#define DRIVER_NAME "Compaq SMART2 Driver (v 2.6.0)"
-#define DRIVER_VERSION SMART2_DRIVER_VERSION(2,6,0)
+#define DRIVER_NAME "Compaq SMART2 Driver (v 2.6.1)"
+#define DRIVER_VERSION SMART2_DRIVER_VERSION(2,6,1)
 
 /* Embedded module documentation macros - see modules.h */
 /* Original author Chris Frantz - Compaq Computer Corporation */
 MODULE_AUTHOR("Compaq Computer Corporation");
-MODULE_DESCRIPTION("Driver for Compaq Smart2 Array Controllers version
2.6.0");
+MODULE_DESCRIPTION("Driver for Compaq Smart2 Array Controllers version
2.6.1");
 MODULE_LICENSE("GPL");
 
 #include "cpqarray.h"
@@ -489,6 +489,22 @@ static int cpqarray_register_ctlr( int i
blk_queue_hardsect_size(hba[i]->queue, drv->blk_size);
set_capacity(disk, drv->nr_blks);
disk->queue = hba[i]->queue;
+
+   /*
+* Create request queue per logical volume
+*/
+if ( j )
+disk->queue = blk_init_queue(do_ida_request,
[i]->lock);
+
+disk->queue->queuedata = hba[i];
+
+/* This is a hardware imposed limit. */
+blk_queue_max_hw_segments(disk->queue, SG_MAX);
+
+/* This is a driver limit and could be eliminated. */
+blk_queue_max_phys_segments(disk->queue, SG_MAX);
+
+
disk->private_data = drv;
add_disk(disk);
}
@@ -1060,6 +1076,9 @@ static irqreturn_t do_ida_intr(int irq, 
unsigned long istat;
unsigned long flags;
__u32 a,a1;
+   int j;
+int ctlr = h->ctlr; 
+int start_queue = h->next_to_run;
 
istat = h->access.intr_pending(h);
/* Is this interrupt for us? */
@@ -1113,7 +1132,31 @@ static irqreturn_t do_ida_intr(int irq, 
/*
 * See if we can queue up some more IO
 */
-   do_ida_request(h->queue);
+for(j=0; j < NWD; j++) {
+int curr_queue = (start_queue + j) % NWD;
+
+if (!(ida_gendisk[ctlr][curr_queue]->queue) ||
+!(h->drv[curr_queue].heads))
+continue;
+
+blk_start_queue(ida_gendisk[ctlr][curr_queue]->queue);
+
+if ( (find_first_zero_bit(h->cmd_pool_bits, NR_CMDS) )
== NR_CMDS)
+{
+if ( curr_queue == start_queue) {
+h->next_to_run = (start_queue + 1) %
NWD;
+goto cleanup;
+} else {
+h->next_to_run = curr_queue;
+goto cleanup;
+}
+} else {
+curr_queue = (curr_queue + 1) %NWD;
+}
+}
+
+cleanup:
+
spin_unlock_irqrestore(IDA_LOCK(h->ctlr), flags); 
return IRQ_HANDLED;
 }
diff -burpN old/drivers/block/cpqarray.h new3/drivers/block/cpqarray.h
--- old/drivers/block/cpqarray.h2005-06-28 23:26:14.0
-0400
+++ new3/drivers/block/cpqarray.h   2005-06-29 00:01:31.0
-0400
@@ -117,6 +117,7 @@ struct ctlr_info {
unsigned int nr_frees;
struct timer_list timer;
unsigned int misc_tflags;
+   int next_to_run;
 };
 
 #define IDA_LOCK(i)([i]->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 1/2] cpqfc: fix for "Using too much stach" in 2.6 kernel

[Dave Jones]

On Thu, Aug 04, 2005 at 10:09:51AM +0530, Saripalli, Venkata Ramanamurthy 
(STSD) wrote:
 > -  ULONG ulFibreFrame[2048/4];  // max DWORDS in incoming FC

This is 512 ulongs, which is 2KB.

 > +  ulFibreFrame = kmalloc((2048/4), GFP_KERNEL);

You're replacing it with a 512 byte buffer.

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 4/5] Driver core: Documentation: fix whitespace between parameters

[Andrew Morton]

[EMAIL PROTECTED] wrote:
>
> Fix whitespace after comma between parameters.
> ...
> -#define DEVICE_ATTR(_name,_mode,_show,_store)  \
> +#define DEVICE_ATTR(_name, _mode, _show, _store)  \
>

I think this one's a bit _too_ trivial, really.  Yes, it's irritating, but
the tree is absolutely full of such things.


-
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 for 2.6.13-rc5] V4L: OOPS fix for BTTV on bad behaviored PCI chipsets

[Andrew Morton]

Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
>
> --- linux-2.6.13/drivers/media/video/bttv-driver.c2005-08-03 
> 18:25:55.0 -0300
>  +++ linux/drivers/media/video/bttv-driver.c  2005-08-03 22:19:44.0 
> -0300
>  @@ -1,5 +1,5 @@
>   /*
>  -$Id: bttv-driver.c,v 1.45 2005/07/20 19:43:24 mkrufky Exp $
>  +$Id: bttv-driver.c,v 1.52 2005/08/04 00:55:16 mchehab Exp $
>   
>   bttv - Bt848 frame grabber driver
>   
>  @@ -80,6 +80,7 @@
>   static unsigned int uv_ratio= 50;
>   static unsigned int full_luma_range = 0;
>   static unsigned int coring  = 0;
>  +extern int no_overlay;

umm, OK.  Could you please send a fixup patch sometime which 

a) renames the now-global no_overlay to something more subsystem-specific and

b) move its declaration out of .c and into .h?

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/

mthca and LinuxBIOS (was: [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes)

[Roland Dreier]

yhlu> In LinuxBIOS, If I enable the prefmem64 to use real 64
yhlu> range. the IB driver in Kernel can not be loaded.

What does it mean to "enable the prefmem64 to use real 64 range"?

Does the driver work if you don't do this?

yhlu> ib_mthca :04:00.0: Failed to initialize queue pair table, 
aborting.

Can you add printk()s to mthca_qp.c::mthca_init_qp_table() to find out
how far the function gets before it fails?

It would also be useful for you to build with CONFIG_INFINIBAND_MTHCA_DEBUG=y
and send the kernel output you get with that.

 - Roland
-
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/3] cpqarray: support for SENSE_SURF_STATUS ioctl

[Saripalli, Venkata Ramanamurthy (STSD)]

Patch 1 of 3
This patch adds support for SENSE_SURF_STATUS ioctl for configuring
SA4200 controller
using Array Configuration Utility (ACU).

Please consider this for inclusion.

Signed-off-by: Ramanamurthy Saripalli <[EMAIL PROTECTED]>

 cpqarray.c |8 +---
 ida_cmd.h  |2 ++
 2 files changed, 7 insertions(+), 3 deletions(-)

--
diff -burpN old/drivers/block/cpqarray.c new1/drivers/block/cpqarray.c
--- old/drivers/block/cpqarray.c2005-06-28 23:26:06.0
-0400
+++ new1/drivers/block/cpqarray.c   2005-06-28 23:28:03.0
-0400
@@ -45,13 +45,13 @@
 
 #define SMART2_DRIVER_VERSION(maj,min,submin)
((maj<<16)|(min<<8)|(submin))
 
-#define DRIVER_NAME "Compaq SMART2 Driver (v 2.6.0)"
-#define DRIVER_VERSION SMART2_DRIVER_VERSION(2,6,0)
+#define DRIVER_NAME "Compaq SMART2 Driver (v 2.6.1)"
+#define DRIVER_VERSION SMART2_DRIVER_VERSION(2,6,1)
 
 /* Embedded module documentation macros - see modules.h */
 /* Original author Chris Frantz - Compaq Computer Corporation */
 MODULE_AUTHOR("Compaq Computer Corporation");
-MODULE_DESCRIPTION("Driver for Compaq Smart2 Array Controllers version
2.6.0");
+MODULE_DESCRIPTION("Driver for Compaq Smart2 Array Controllers version
2.6.1");
 MODULE_LICENSE("GPL");
 
 #include "cpqarray.h"
@@ -1272,6 +1272,7 @@ static int ida_ctlr_ioctl(ctlr_info_t *h
c->req.hdr.sg_cnt = 1;
break;
case IDA_READ:
+   case SENSE_SURF_STATUS:
case READ_FLASH_ROM:
case SENSE_CONTROLLER_PERFORMANCE:
p = kmalloc(io->sg[0].size, GFP_KERNEL);
@@ -1337,6 +1338,7 @@ static int ida_ctlr_ioctl(ctlr_info_t *h
 sizeof(ida_ioctl_t),
 PCI_DMA_BIDIRECTIONAL);
case IDA_READ:
+   case SENSE_SURF_STATUS:
case DIAG_PASS_THRU:
case SENSE_CONTROLLER_PERFORMANCE:
case READ_FLASH_ROM:
diff -burpN old/drivers/block/ida_cmd.h new1/drivers/block/ida_cmd.h
--- old/drivers/block/ida_cmd.h 2005-06-28 23:26:22.0 -0400
+++ new1/drivers/block/ida_cmd.h2005-06-28 23:28:03.0
-0400
@@ -318,6 +318,8 @@ typedef struct {
__u8reserved[510];
 } mp_delay_t;
 
+#define SENSE_SURF_STATUS   0x70
+
 #define PASSTHRU_A 0x91
 typedef struct {
__u8target;
-
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: Obsolete files in 2.6 tree

[Will Dyson]

On 8/3/05, Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Jiri Slaby napsal(a):
> 
> > fs/befs/attribute.c
> 
> And what about entire befs? Is it used?
> Last change was made on 2002 and many features are still missing.

Well, don't know about anyone else, but I certainly don't use it
anymore. If anyone needs  a fully-functional befs driver, the easiest
route to that would probably be getting Haiku's befs driver to compile
in userland as a FUSE fs.

At any rate, attribute.c can go. It is easy enough to add back in if
anyone ever wants to do the (relativly minor) refactoring nessisary to
get it working.

Signed-off-by: Will Dyson <[EMAIL PROTECTED]>

diff -r 1e753e53161a fs/befs/attribute.c
--- a/fs/befs/attribute.c   Tue Aug  2 13:00:13 2005
+++ /dev/null   Thu Aug  4 00:31:20 2005
@@ -1,117 +0,0 @@
-/*
- * linux/fs/befs/attribute.c
- *
- * Copyright (C) 2002 Will Dyson <[EMAIL PROTECTED]>
- *
- * Many thanks to Dominic Giampaolo, author of "Practical File System
- * Design with the Be File System", for such a helpful book.
- *
- */
-
-#include 
-#include 
-#include 
-
-#include "befs.h"
-#include "endian.h"
-
-#define SD_DATA(sd)\
-   (void*)((char*)sd + sizeof(*sd) + (sd->name_size - sizeof(sd->name)))
-
-#define SD_NEXT(sd)\
-   (befs_small_data*)((char*)sd + sizeof(*sd) + (sd->name_size - \
-   sizeof(sd->name) + sd->data_size))
-
-int
-list_small_data(struct super_block *sb, befs_inode * inode, filldir_t filldir);
-
-befs_small_data *
-find_small_data(struct super_block *sb, befs_inode * inode,
-const char *name);
-int
-read_small_data(struct super_block *sb, befs_inode * inode,
-befs_small_data * sdata, void *buf, size_t bufsize);
-
-/**
- *
- *
- *
- *
- *
- */
-befs_small_data *
-find_small_data(struct super_block *sb, befs_inode * inode, const char *name)
-{
-   befs_small_data *sdata = inode->small_data;
-
-   while (sdata->type != 0) {
-   if (strcmp(name, sdata->name) != 0) {
-   return sdata;
-   }
-   sdata = SD_NEXT(sdata);
-   }
-   return NULL;
-}
-
-/**
- *
- *
- *
- *
- *
- */
-int
-read_small_data(struct super_block *sb, befs_inode * inode,
-   const char *name, void *buf, size_t bufsize)
-{
-   befs_small_data *sdata;
-
-   sdata = find_small_data(sb, inode, name);
-   if (sdata == NULL)
-   return BEFS_ERR;
-   else if (sdata->data_size > bufsize)
-   return BEFS_ERR;
-
-   memcpy(buf, SD_DATA(sdata), sdata->data_size);
-
-   return BEFS_OK;
-}
-
-/**
- *
- *
- *
- *
- *
- */
-int
-list_small_data(struct super_block *sb, befs_inode * inode)
-{
-
-}
-
-/**
- *
- *
- *
- *
- *
- */
-int
-list_attr(struct super_block *sb, befs_inode * inode)
-{
-
-}
-
-/**
- *
- *
- *
- *
- *
- */
-int
-read_attr(struct super_block *sb, befs_inode * inode)
-{
-
-}


-- 
Will Dyson
diff -r 1e753e53161a fs/befs/attribute.c
--- a/fs/befs/attribute.c	Tue Aug  2 13:00:13 2005
+++ /dev/null	Thu Aug  4 00:31:20 2005
@@ -1,117 +0,0 @@
-/*
- * linux/fs/befs/attribute.c
- *
- * Copyright (C) 2002 Will Dyson <[EMAIL PROTECTED]>
- *
- * Many thanks to Dominic Giampaolo, author of "Practical File System
- * Design with the Be File System", for such a helpful book.
- *
- */
-
-#include 
-#include 
-#include 
-
-#include "befs.h"
-#include "endian.h"
-
-#define SD_DATA(sd)\
-	(void*)((char*)sd + sizeof(*sd) + (sd->name_size - sizeof(sd->name)))
-
-#define SD_NEXT(sd)\
-	(befs_small_data*)((char*)sd + sizeof(*sd) + (sd->name_size - \
-	sizeof(sd->name) + sd->data_size))
-
-int
-list_small_data(struct super_block *sb, befs_inode * inode, filldir_t filldir);
-
-befs_small_data *
-find_small_data(struct super_block *sb, befs_inode * inode,
- const char *name);
-int
-read_small_data(struct super_block *sb, befs_inode * inode,
-		 befs_small_data * sdata, void *buf, size_t bufsize);
-
-/**
- *
- *
- *
- *
- *
- */
-befs_small_data *
-find_small_data(struct super_block *sb, befs_inode * inode, const char *name)
-{
-	befs_small_data *sdata = inode->small_data;
-
-	while (sdata->type != 0) {
-		if (strcmp(name, sdata->name) != 0) {
-			return sdata;
-		}
-		sdata = SD_NEXT(sdata);
-	}
-	return NULL;
-}
-
-/**
- *
- *
- *
- *
- *
- */
-int
-read_small_data(struct super_block *sb, befs_inode * inode,
-		const char *name, void *buf, size_t bufsize)
-{
-	befs_small_data *sdata;
-
-	sdata = find_small_data(sb, inode, name);
-	if (sdata == NULL)
-		return BEFS_ERR;
-	else if (sdata->data_size > bufsize)
-		return BEFS_ERR;
-
-	memcpy(buf, SD_DATA(sdata), sdata->data_size);
-
-	return BEFS_OK;
-}
-
-/**
- *
- *
- *
- *
- *
- */
-int
-list_small_data(struct super_block *sb, befs_inode * inode)
-{
-
-}
-
-/**
- *
- *
- *
- *
- *
- */
-int
-list_attr(struct super_block *sb, befs_inode * inode)
-{
-
-}
-
-/**
- *
- *
- *
- *
- *
- */
-int
-read_attr(struct super_block *sb, befs_inode * inode)
-{
-
-}

[PATCH 2/2] cpqfc: fix for possible memory out of bounds bugzilla#243

[Saripalli, Venkata Ramanamurthy (STSD)]

Patch 2 of 2

This patch fixes the Bugzilla Bug#243. This fix is to solve the possible
memory
out of bounds in BigEndianSwap routine of cpqfcTSworker.c

Please consider this for inclusion

Signed-off-by: Ramanamurthy Saripalli <[EMAIL PROTECTED]>

 cpqfcTScontrol.c |2 --
 cpqfcTSworker.c  |3 +++
 2 files changed, 3 insertions(+), 2 deletions(-)

---
diff -burpN old/drivers/scsi/cpqfcTScontrol.c
new/drivers/scsi/cpqfcTScontrol.c
--- old/drivers/scsi/cpqfcTScontrol.c   2005-07-12 22:52:29.0
+0530
+++ new/drivers/scsi/cpqfcTScontrol.c   2005-07-19 00:33:29.385458328
+0530
@@ -606,7 +606,6 @@ static int PeekIMQEntry( PTACHYON fcChip
 if( (fcChip->IMQ->QEntry[CI].type & 0x1FF) == 0x104 )
 { 
   TachFCHDR_GCMND* fchs;
-#error This is too much stack
   ULONG ulFibreFrame[2048/4];  // max DWORDS in incoming FC
Frame
  USHORT SFQpi = (USHORT)(fcChip->IMQ->QEntry[CI].word[0] &
0x0fffL);
 
@@ -718,7 +717,6 @@ int CpqTsProcessIMQEntry(void *host)
   ULONG x_ID;
   ULONG ulBuff, dwStatus;
   TachFCHDR_GCMND* fchs;
-#error This is too much stack
   ULONG ulFibreFrame[2048/4];  // max number of DWORDS in incoming
Fibre Frame
   UCHAR ucInboundMessageType;  // Inbound CM, dword 3 "type" field
 
diff -burpN old/drivers/scsi/cpqfcTSworker.c
new/drivers/scsi/cpqfcTSworker.c
--- old/drivers/scsi/cpqfcTSworker.c2005-07-12 22:52:29.0
+0530
+++ new/drivers/scsi/cpqfcTSworker.c2005-07-19 00:33:32.245023608
+0530
@@ -4024,6 +4024,9 @@ void BigEndianSwap( UCHAR *source, UCHAR
   int i,j;
 
   source+=3;   // start at MSB of 1st ULONG
+
+  cnt -= (cnt % 4 );
+
   for( j=0; j < cnt; j+=4, source+=4, dest+=4)  // every ULONG
   {
 for( i=0; i<4; i++)  // every UCHAR in ULONG
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] cpqfc: fix for "Using too much stach" in 2.6 kernel

[Saripalli, Venkata Ramanamurthy (STSD)]

Patch 1 of 2

This patch fixes the "#error this is too much stack" in 2.6 kernel.
Using kmalloc to allocate memory to ulFibreFrame.

Please consider this for inclusion

Signed-off-by: Ramanamurthy Saripalli <[EMAIL PROTECTED]>

 cpqfcTScontrol.c |   14 +-
 1 files changed, 9 insertions(+), 5 deletions(-)

---
diff -burpN old/drivers/scsi/cpqfcTScontrol.c
new/drivers/scsi/cpqfcTScontrol.c
--- old/drivers/scsi/cpqfcTScontrol.c   2005-07-12 22:52:29.0
+0530
+++ new/drivers/scsi/cpqfcTScontrol.c   2005-07-18 22:19:54.229947176
+0530
@@ -606,22 +606,25 @@ static int PeekIMQEntry( PTACHYON fcChip
 if( (fcChip->IMQ->QEntry[CI].type & 0x1FF) == 0x104 )
 { 
   TachFCHDR_GCMND* fchs;
-#error This is too much stack
-  ULONG ulFibreFrame[2048/4];  // max DWORDS in incoming FC
Frame
+  ULONG *ulFibreFrame;  // max DWORDS in incoming FC Frame
  USHORT SFQpi = (USHORT)(fcChip->IMQ->QEntry[CI].word[0] &
0x0fffL);
 
+ ulFibreFrame = kmalloc((2048/4), GFP_KERNEL);
+   
  CpqTsGetSFQEntry( fcChip,
 SFQpi,// SFQ producer ndx 
ulFibreFrame, // contiguous dest. buffer
FALSE);   // DON'T update chip--this is a "lookahead"
   
- fchs = (TachFCHDR_GCMND*)
+ fchs = (TachFCHDR_GCMND*)ulFibreFrame;
   if( fchs->pl[0] == ELS_LILP_FRAME)
  {
+   kfree(ulFibreFrame);
 return 1; // found the LILP frame!
  }
  else
  {
+   kfree(ulFibreFrame);
// keep looking...
  }
}  
@@ -718,12 +721,12 @@ int CpqTsProcessIMQEntry(void *host)
   ULONG x_ID;
   ULONG ulBuff, dwStatus;
   TachFCHDR_GCMND* fchs;
-#error This is too much stack
-  ULONG ulFibreFrame[2048/4];  // max number of DWORDS in incoming
Fibre Frame
+  ULONG *ulFibreFrame;  // max number of DWORDS in incoming Fibre Frame
   UCHAR ucInboundMessageType;  // Inbound CM, dword 3 "type" field
 
   ENTER("ProcessIMQEntry");

+  ulFibreFrame = kmalloc((2048/4), GFP_KERNEL); 
 
// check TachLite's IMQ producer index -
// is a new message waiting for us?
@@ -1627,6 +1630,7 @@ int CpqTsProcessIMQEntry(void *host)
 
   LEAVE("ProcessIMQEntry");
   
+  kfree(ulFibreFrame);  
   return iStatus;
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: question on memory map of process on i386

[Keith Owens]

On Wed, 03 Aug 2005 17:28:38 -0600, 
"Christopher Friesen" <[EMAIL PROTECTED]> wrote:
>
>On i386, /proc//maps shows the following entry:
>
>e000-f000 ---p  00:00 0
>
>This page of memory is way up above TASK_SIZE (which is 0xc000), so 
>how is it visible to userspace?
>
>Just to complicate things,  I seem to find the vma for this page using 
>find_vma_prev().
>
>Can anyone explain what's going on?

The gate page is a section of code that is generated as part of the
kernel build.  At run time, the gate page is mapped into all the user
space processes.  There is also a virtual dynamic .so (vdso) file that
is created by the kernel and picked up by the linker, the vdso maps the
kernel entries in the gate page.  Run this command and look for "gate".

  ldd -v `which cat`

Once all the dots are joined by the linker, a program can use the vdso
to directly access the gate page, even though the vdso and the
underlying page belongs to the kernel.  This direct access does not
incur any of the overhead associated with a syscall, so it can be very
fast.

What is in the gate page varies from one architecture to another, glibc
hides the arch differences from the program.  Some sample uses for the
gate page -

i386: select between int 0x80 or sysenter to enter the kernel.
ia64: select between break 0x10 or epc to enter the kernel, epc is
  significantly faster.  On ia64, the gate page also contains the
  signal delivery trampoline.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: question on memory map of process on i386

[Steven Rostedt]

On Wed, 2005-08-03 at 17:28 -0600, Christopher Friesen wrote:
> On i386, /proc//maps shows the following entry:
> 
> e000-f000 ---p  00:00 0
> 
> This page of memory is way up above TASK_SIZE (which is 0xc000), so 
> how is it visible to userspace?
> 
> Just to complicate things,  I seem to find the vma for this page using 
> find_vma_prev().
> 
> Can anyone explain what's going on?
> 

Looking at the code, it seems to be the "gate area". But what this is
used for, I'm not really sure. I did a little searching but found no
good explanations of it. So I added Keith to the CC since most of the
updates to this was submitted by him :-)

-- Steve


-
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/

[Fwd: Re: BTTV - experimental no_overlay patch]

[Mauro Carvalho Chehab]

Greg,

It seems that some newer VIA chipsets have some troubles with PCI2PCI
data transfers. These problems had occurred on the past (while Gerd
Knorr were the V4L maintainer) and affected Overlay support for bttv
cards, mostly on via chipsets. 
Bodo (and others) had reported some OOPS occurring when activating
Overlay support (that makes data transfers from PCI bttv cards to AGI
video card).
We've made some tests deactivating overlay support and they reported no
OOPS.
I'm submiting a patch for V4L bttv to allow disabling pci2pci transfers
based on quirks.c information and also an optional workaround parameter
to force the board to don't allow (no_overlay insmod parameter).
I think you may also check if it is a hardware problem with these via
chips or something that can be fixed by software (increasing some
delays, for example?).

Mauro.
Current V4L Maintainer.

 Mensagem encaminhada 
De: Bodo Eggert <[EMAIL PROTECTED]>
Para: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Assunto: Re: BTTV - experimental no_overlay patch
Data: Thu, 4 Aug 2005 02:28:21 +0200 (CEST)

On Wed, 3 Aug 2005, Mauro Carvalho Chehab wrote:

> Bodo,
> 
>   Please, send me bttv init logs. I need to know if PCI quirks has
> detected your PCI chipset as a problematic one.

It seems it hasn't. Full dmesg and lspci:


Detected 901.761 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 514344k/524224k available (3082k kernel code, 9324k reserved, 961k 
data, 148k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1806.64 BogoMIPS (lpj=3613286)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0183f9ff c1c7f9ff    
 
CPU: After vendor identify, caps: 0183f9ff c1c7f9ff    
 
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0183f9ff c1c7f9ff  0020  
 
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
CPU: AMD Athlon(tm) Processor stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
NET: Registered protocol family 16
PCI: Using configuration type 1
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Boot video device is :01:00.0
PCI: Using IRQ router VIA [1106/0686] at :00:07.0
PCI: Bridge: :00:01.0
  IO window: c000-cfff
  MEM window: e800-e9ff
  PREFETCH window: d000-dfff
PCI: Setting latency timer of device :00:01.0 to 64
Machine check exception polling timer started.
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]).
NTFS driver 2.1.23 [Flags: R/O].
Initializing Cryptographic API
Applying VIA southbridge workaround.
radeonfb_pci_register BEGIN
radeonfb (:01:00.0): Found 131072k of DDR 128 bits wide videoram
radeonfb (:01:00.0): mapped 16384k videoram
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=250.00 Mhz, System=200.00 MHz
radeonfb: PLL min 2 max 4
1 chips in connector info
 - chip 1 has 2 connectors
  * connector 0 of type 2 (CRT) : 2300
  * connector 1 of type 3 (DVI-I) : 3201
Starting monitor auto detection...
radeonfb: I2C (port 1) ... not found
radeonfb: I2C (port 2) ... not found
radeonfb: I2C (port 3) ... found CRT display
radeonfb: I2C (port 4) ... not found
radeonfb: I2C (port 2) ... not found
radeonfb: I2C (port 4) ... not found
radeonfb: I2C (port 3) ... found CRT display
radeonfb: Monitor 1 type CRT found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
hStart = 694, hEnd = 757, hTotal = 795
vStart = 402, vEnd = 408, vTotal = 418
h_total_disp = 0x590062hsync_strt_wid = 0x8702c0
v_total_disp = 0x18f01a1   vsync_strt_wid = 0x860191
pixclock = 85925
freq = 1163
freq = 1666, PLL min = 2, PLL max = 4
ref_div = 12, ref_clk = 2700, output_freq = 26656
ref_div = 12, ref_clk = 2700, output_freq = 26656
post div = 0x5
fb_div = 0x76
ppll_div_3 = 0x50076
Console: switching to colour frame buffer device 90x25
radeonfb (:01:00.0): ATI Radeon AS 
radeonfb_pci_register END
PCI: Enabling device :00:09.0 ( -> 0003)
PCI: Found IRQ 5 for device :00:09.0
PCI: Sharing IRQ 5 with :00:0d.0
fb: 3Dfx Banshee memory = 16384K
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected VIA Twister-K/KT133x/KM133 chipset
agpgart: AGP aperture is 64M @ 0xe000
[drm] Initialized drm 1.0.0 

[PATCH for 2.6.13-rc5] V4L: OOPS fix for BTTV on bad behaviored PCI chipsets

[Mauro Carvalho Chehab]

no_overlay bttv parameter implemented to fix OOPS on some PCI chipsets 
(like some VIA) with these behaviors:

1) If pci_quicks does identify the chip as having troubles to 
   handle PCI2PCI transfers, no_overlay defaults to 1. The user may force 
   it to 0, to reenable (not recommended).
2) For newer chipsets not blacklisted, no_overlay=1 is provided as a 
   workaround until PCI chipset included on /drivers/pci/quirks.c

Thanks to  Bodo Eggert <[EMAIL PROTECTED]>

Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>

 linux/Documentation/video4linux/bttv/Insmod-options |3 +
 linux/drivers/media/video/bttv-cards.c  |   10 ++--
 linux/drivers/media/video/bttv-driver.c |   28 ++--
 3 files changed, 33 insertions(+), 8 deletions(-)

diff -u linux-2.6.13/drivers/media/video/bttv-driver.c linux/drivers/media/video/bttv-driver.c
--- linux-2.6.13/drivers/media/video/bttv-driver.c	2005-08-03 18:25:55.0 -0300
+++ linux/drivers/media/video/bttv-driver.c	2005-08-03 22:19:44.0 -0300
@@ -1,5 +1,5 @@
 /*
-$Id: bttv-driver.c,v 1.45 2005/07/20 19:43:24 mkrufky Exp $
+$Id: bttv-driver.c,v 1.52 2005/08/04 00:55:16 mchehab Exp $
 
 bttv - Bt848 frame grabber driver
 
@@ -80,6 +80,7 @@
 static unsigned int uv_ratio= 50;
 static unsigned int full_luma_range = 0;
 static unsigned int coring  = 0;
+extern int no_overlay;
 
 /* API features (turn on/off stuff for testing) */
 static unsigned int v4l2= 1;
@@ -2151,6 +2152,10 @@
 		return 0;
 	}
 	case V4L2_BUF_TYPE_VIDEO_OVERLAY:
+		if (no_overlay > 0) {
+			printk ("V4L2_BUF_TYPE_VIDEO_OVERLAY: no_overlay\n");
+			return -EINVAL;
+		}
 		return setup_window(fh, btv, >fmt.win, 1);
 	case V4L2_BUF_TYPE_VBI_CAPTURE:
 		retval = bttv_switch_type(fh,f->type);
@@ -2224,9 +2229,11 @@
 			/* others */
 			cap->type = VID_TYPE_CAPTURE|
 VID_TYPE_TUNER|
-VID_TYPE_OVERLAY|
 VID_TYPE_CLIPPING|
 VID_TYPE_SCALES;
+			if (no_overlay <= 0)
+cap->type |= VID_TYPE_OVERLAY;
+
 			cap->maxwidth  = bttv_tvnorms[btv->tvnorm].swidth;
 			cap->maxheight = bttv_tvnorms[btv->tvnorm].sheight;
 			cap->minwidth  = 48;
@@ -2302,6 +2309,11 @@
 		struct video_window *win = arg;
 		struct v4l2_window w2;
 
+		if (no_overlay > 0) {
+			printk ("VIDIOCSWIN: no_overlay\n");
+			return -EINVAL;
+		}
+
 		w2.field = V4L2_FIELD_ANY;
 		w2.w.left= win->x;
 		w2.w.top = win->y;
@@ -2577,10 +2589,12 @@
 		cap->version = BTTV_VERSION_CODE;
 		cap->capabilities =
 			V4L2_CAP_VIDEO_CAPTURE |
-			V4L2_CAP_VIDEO_OVERLAY |
 			V4L2_CAP_VBI_CAPTURE |
 			V4L2_CAP_READWRITE |
 			V4L2_CAP_STREAMING;
+		if (no_overlay <= 0)
+			cap->capabilities |= V4L2_CAP_VIDEO_OVERLAY;
+
 		if (bttv_tvcards[btv->c.type].tuner != UNSET &&
 		bttv_tvcards[btv->c.type].tuner != TUNER_ABSENT)
 			cap->capabilities |= V4L2_CAP_TUNER;
@@ -3076,7 +3090,7 @@
 static struct video_device bttv_video_template =
 {
 	.name = "UNSET",
-	.type = VID_TYPE_CAPTURE|VID_TYPE_TUNER|VID_TYPE_OVERLAY|
+	.type = VID_TYPE_CAPTURE|VID_TYPE_TUNER|
 	VID_TYPE_CLIPPING|VID_TYPE_SCALES,
 	.hardware = VID_HARDWARE_BT848,
 	.fops = _fops,
@@ -3756,6 +3770,12 @@
 /* register video4linux devices */
 static int __devinit bttv_register_video(struct bttv *btv)
 {
+	if (no_overlay <= 0) {
+		bttv_video_template.type |= VID_TYPE_OVERLAY;
+	} else {
+		printk("bttv: Overlay support disabled.\n");
+	}
+
 	/* video */
 	btv->video_dev = vdev_init(btv, _video_template, "video");
 if (NULL == btv->video_dev)
diff -u linux-2.6.13/drivers/media/video/bttv-cards.c linux/drivers/media/video/bttv-cards.c
--- linux-2.6.13/drivers/media/video/bttv-cards.c	2005-08-03 18:25:55.0 -0300
+++ linux/drivers/media/video/bttv-cards.c	2005-08-03 22:19:44.0 -0300
@@ -95,7 +95,7 @@
 static unsigned int triton1=0;
 static unsigned int vsfx=0;
 static unsigned int latency = UNSET;
-static unsigned int no_overlay=-1;
+int no_overlay=-1;
 
 static unsigned int card[BTTV_MAX]   = { [ 0 ... (BTTV_MAX-1) ] = UNSET };
 static unsigned int pll[BTTV_MAX]= { [ 0 ... (BTTV_MAX-1) ] = UNSET };
@@ -4296,9 +4475,11 @@
 		printk(KERN_INFO "bttv: Host bridge needs VSFX enabled.\n");
 	if (pcipci_fail) {
 		printk(KERN_WARNING "bttv: BT848 and your chipset may not work together.\n");
-		if (UNSET == no_overlay) {
-			printk(KERN_WARNING "bttv: going to disable overlay.\n");
+		if (!no_overlay) {
+			printk(KERN_WARNING "bttv: overlay will be disabled.\n");
 			no_overlay = 1;
+		} else {
+			printk(KERN_WARNING "bttv: overlay forced. Use this option at your own risk.\n");
 		}
 	}
 	if (UNSET != latency)

diff -u linux-2.6.13/Documentation/video4linux/bttv/Insmod-options linux/Documentation/video4linux/bttv/Insmod-options
--- linux-2.6.13/Documentation/video4linux/bttv/Insmod-options	2005-06-17 16:48:29.0 -0300
+++ linux/Documentation/video4linux/bttv/Insmod-options	2005-08-03 

Re: [PATCH] 1/5 more-asm-cleanup

[Zachary Amsden]

H. Peter Anvin wrote:



Reject!  This is a bogus patch; Intel's CPUID level 4 has a 
nonstandard dependency on ECX (idiots...) and therefore this needs 
special handling.


-hpa



Here's a better idea.  Let's comment that unusual dependency and make it 
explicit in the macro.


Some more assembler cleanups I noticed along the way.

Diffs against: 2.6.13-rc4-mm1

Signed-off-by: Zachary Amsden <[EMAIL PROTECTED])
Index: linux-2.6.13/arch/i386/kernel/crash.c
===
--- linux-2.6.13.orig/arch/i386/kernel/crash.c  2005-08-03 15:18:18.0 
-0700
+++ linux-2.6.13/arch/i386/kernel/crash.c   2005-08-03 15:19:39.0 
-0700
@@ -153,7 +153,7 @@
disable_local_APIC();
atomic_dec(_for_crash_ipi);
/* Assume hlt works */
-   __asm__("hlt");
+   halt();
for(;;);
 
return 1;
Index: linux-2.6.13/arch/i386/kernel/machine_kexec.c
===
--- linux-2.6.13.orig/arch/i386/kernel/machine_kexec.c  2005-08-03 
15:18:18.0 -0700
+++ linux-2.6.13/arch/i386/kernel/machine_kexec.c   2005-08-03 
15:19:39.0 -0700
@@ -93,10 +93,7 @@
curidt.size= limit;
curidt.address = (unsigned long)newidt;
 
-   __asm__ __volatile__ (
-   "lidtl %0\n"
-   : : "m" (curidt)
-   );
+   load_idt();
 };
 
 
@@ -108,10 +105,7 @@
curgdt.size= limit;
curgdt.address = (unsigned long)newgdt;
 
-   __asm__ __volatile__ (
-   "lgdtl %0\n"
-   : : "m" (curgdt)
-   );
+   load_gdt();
 };
 
 static void load_segments(void)
Index: linux-2.6.13/arch/i386/kernel/process.c
===
--- linux-2.6.13.orig/arch/i386/kernel/process.c2005-08-03 
15:18:18.0 -0700
+++ linux-2.6.13/arch/i386/kernel/process.c 2005-08-03 17:27:48.0 
-0700
@@ -165,7 +165,7 @@
 */
local_irq_disable();
while (1)
-   __asm__ __volatile__("hlt":::"memory");
+   halt();
 }
 #else
 static inline void play_dead(void)
Index: linux-2.6.13/arch/i386/kernel/msr.c
===
--- linux-2.6.13.orig/arch/i386/kernel/msr.c2005-08-03 15:18:18.0 
-0700
+++ linux-2.6.13/arch/i386/kernel/msr.c 2005-08-03 15:19:39.0 -0700
@@ -46,23 +46,13 @@
 
 static struct class *msr_class;
 
-/* Note: "err" is handled in a funny way below.  Otherwise one version
-   of gcc or another breaks. */
-
 static inline int wrmsr_eio(u32 reg, u32 eax, u32 edx)
 {
int err;
 
-   asm volatile ("1:   wrmsr\n"
- "2:\n"
- ".section .fixup,\"ax\"\n"
- "3:   movl %4,%0\n"
- " jmp 2b\n"
- ".previous\n"
- ".section __ex_table,\"a\"\n"
- " .align 4\n" "   .long 1b,3b\n" ".previous":"=" (err)
- :"a"(eax), "d"(edx), "c"(reg), "i"(-EIO), "0"(0));
-
+   err = wrmsr_safe(reg, eax, edx);
+   if (err)
+   err = -EIO;
return err;
 }
 
@@ -70,18 +60,9 @@
 {
int err;
 
-   asm volatile ("1:   rdmsr\n"
- "2:\n"
- ".section .fixup,\"ax\"\n"
- "3:   movl %4,%0\n"
- " jmp 2b\n"
- ".previous\n"
- ".section __ex_table,\"a\"\n"
- " .align 4\n"
- " .long 1b,3b\n"
- ".previous":"=" (err), "=a"(*eax), "=d"(*edx)
- :"c"(reg), "i"(-EIO), "0"(0));
-
+   err = rdmsr_safe(reg, eax, edx);
+   if (err)
+   err = -EIO;
return err;
 }
 
Index: linux-2.6.13/arch/i386/kernel/cpu/intel.c
===
--- linux-2.6.13.orig/arch/i386/kernel/cpu/intel.c  2005-08-03 
15:18:18.0 -0700
+++ linux-2.6.13/arch/i386/kernel/cpu/intel.c   2005-08-03 20:22:55.0 
-0700
@@ -82,16 +82,13 @@
  */
 static int __devinit num_cpu_cores(struct cpuinfo_x86 *c)
 {
-   unsigned int eax;
+   unsigned int eax, ebx, ecx, edx;
 
if (c->cpuid_level < 4)
return 1;
 
-   __asm__("cpuid"
-   : "=a" (eax)
-   : "0" (4), "c" (0)
-   : "bx", "dx");
-
+   /* Intel has a non-standard dependency on %ecx for this CPUID level. */
+   cpuid_count(4, 0, , , , );
if (eax & 0x1f)
return ((eax >> 26) + 1);
else
Index: linux-2.6.13/arch/i386/mach-voyager/voyager_basic.c
===
--- linux-2.6.13.orig/arch/i386/mach-voyager/voyager_basic.c2005-08-03 
15:18:18.0 -0700
+++ 

Re: 2.6.13-rc4 - kernel panic - BUG at net/ipv4/tcp_output.c:918

[Herbert Xu]

On Mon, Aug 01, 2005 at 08:33:20AM +, Guillaume Pelat wrote:
> 
> I just tried the patch attached. :)
> 
> The bug is still here (same symptoms), with a slightly different backtrace :
> [ cut here ]
> kernel BUG at net/ipv4/tcp_output.c:918!

OK, let's try again :)

I bet it's the tcp_enter_cwr() call in tcp_transmit_skb().  So
the sequence is:

tcp_write_xmit
cwnd_quota = tcp_cwnd_test
tcp_transmit_skb
tcp_enter_cwr
tp->snd_cwnd = min(tp->snd_cwnd, in_flight + 1)

At this point cwnd_quota is out-of-sync with tp->snd_cwnd.

cwnd_quota -= tcp_skb_pcount(skb)
cwnd_quota > 0
tcp_tso_should_defer
BUG since tp->snd_cwnd is smaller than what
cwnd_quota indicated.

So I suppose we should reset cwnd_quota after tcp_transmit_skb?

Perhaps we should only transmit one MSS in this case?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/23] reboot-fixes

[Nigel Cunningham]

Hi.

On Thu, 2005-07-28 at 08:54, Pavel Machek wrote:
> Hi!
> 
> > >  > Good question.  I'm not certain if Pavel intended to add
> > >  > device_suspend(PMSG_FREEZE) to the reboot path.  It was
> > >  > there in only one instance.  Pavel comments talk only about
> > >  > the suspend path.
> > > 
> > >  Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path.
> > 
> > Why?
> 
> Many bioses are broken; if you leave hardware active during reboot,
> they'll hang during reboot. It is so common problem that I think that
> only sane solution is make hardware quiet before reboot.

Sorry for my slow reply.

If I remember correctly PMSG_FREEZE was intended solely for stopping
activity when suspend to disk implementations are about to do their
atomic copies. I thought that ide reacts to this message by putting a
hold on queues, but doesn't otherwise do anything to prepare a drive for
a restart. If that's true, using FREEZE here isn't going to stop drives
from doing their emergency shutdown actions. Don't we need PMSG_SUSPEND
instead?

Regards,

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 1/5 more-asm-cleanup

[Zachary Amsden]

Please explain why this is a reject after looking at the cpuid macro.  
It changed recently.  Note 0 -> %ecx.


Would you prefer that I call cpuid_count and pass an explicit zero 
parameter for ecx?



/*
* Generic CPUID function
* clear %ecx since some cpus (Cyrix MII) do not set or clear %ecx
* resulting in stale register contents being returned.
*/
static inline void cpuid(unsigned int op, unsigned int *eax, unsigned 
int *ebx, unsigned int *ecx, unsigned int *edx)

{
   __asm__("cpuid"
   : "=a" (*eax),
 "=b" (*ebx),
 "=c" (*ecx),
 "=d" (*edx)
   : "0" (op), "c"(0));
}


H. Peter Anvin wrote:


[EMAIL PROTECTED] wrote:


Some more assembler cleanups I noticed along the way.




Index: linux-2.6.13/arch/i386/kernel/cpu/intel.c
===
--- linux-2.6.13.orig/arch/i386/kernel/cpu/intel.c2005-08-03 
15:18:18.0 -0700
+++ linux-2.6.13/arch/i386/kernel/cpu/intel.c2005-08-03 
15:19:39.0 -0700

@@ -82,16 +82,12 @@
  */
 static int __devinit num_cpu_cores(struct cpuinfo_x86 *c)
 {
-unsigned int eax;
+unsigned int eax, ebx, ecx, edx;
 
 if (c->cpuid_level < 4)

 return 1;
 
-__asm__("cpuid"

-: "=a" (eax)
-: "0" (4), "c" (0)
-: "bx", "dx");
-
+cpuid(4, , , , );
 if (eax & 0x1f)
 return ((eax >> 26) + 1);



Reject!  This is a bogus patch; Intel's CPUID level 4 has a 
nonstandard dependency on ECX (idiots...) and therefore this needs 
special handling.


-hpa



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Regarding PCIBIOS_MIN_MEM and PCIBIOS_MIN_IO

[Chandrasekhar Nagaraj]

Hi,
I am writing a driver for the PCI controller for the
2.4.17 kernel.
I found out that we need to define 2 macros
PCIBIOS_MIN_MEM and PCIBIOS_MIN_IO. What does these
macros mean?
I have a ARM board with Memory space starting at
0x6000_ and IO space starting at 0x7000_. So
does this mean that I have to set the above values to
these macros?

Thanks and Regards
Chandrasekhar






__
Free antispam, antivirus and 1GB to save all your messages
Only in Yahoo! Mail: http://in.mail.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: Calling suspend() in halt/restart/shutdown -> not a good idea

[Andrew Morton]

Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> Andrew, please back that off before 2.6.13. I'll try to send a patch if
>  you want later today if I find some time with a kernel source at hand.

Please do.
-
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 linux-2.6.13-rc3] SATA: rewritten sil24 driver

[Tejun Heo]

 Hello, Edward.

 One more question.

> > >
> > >I think this will work (adapted from sil_interrupt():
> > >
> > >static void sil_irq_clear(struct ata_port *ap)
> > >{
> > >struct sil_port_priv *pp = ap->private_data;
> > >struct Port_Registers *port_base = pp->pregs;
> > >unsigned long port_int;
> > >
> > >port_int  = readl((void *)_base->IntStatus);
> > >writel(port_int, _base->IntStatus);
> > >}
> > >
> > >I'm assuming that this entry point is expected to clear all interrupts, no?
> > 
> > Correct.
> > 
> 
>  I'll verify with the error register clearing part of the original
> driver and submit a patch.
> 

 Command completion interrupt is automatcally cleared by reading
PORT_SLOT_STAT register (SlotStatus in the original driver), and error
registers should be manually cleared by writing to PORT_IRQ_STAT
(IntStatus).

 I agree that above code should clear both.  Just wanna verify.  Have
you tested it and/or do you have any information confirming this?  If
we don't have any further info, I think we should read PORT_SLOT_STAT
before clearing PORT_IRQ_STAT to be on the safe side.

 Thanks.

-- 
tejun
-
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] PPC64: Fix UP kernel build

[Olof Johansson]

Hi,

CONFIG_KEXEC breaks UP builds because of a misspelled smp_release_cpus().
Also, the function isn't defined unless built with CONFIG_SMP but it is
needed if we are to go from a UP to SMP kernel. Enable it and document it.

Thanks to Steven Winiecki for reporting this and to Milton for remembering
how it's supposed to work and why.

-Olof

Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>

Index: 2.6/arch/ppc64/kernel/machine_kexec.c
===
--- 2.6.orig/arch/ppc64/kernel/machine_kexec.c  2005-08-03 19:53:16.0 
-0500
+++ 2.6/arch/ppc64/kernel/machine_kexec.c   2005-08-03 20:39:49.0 
-0500
@@ -243,13 +243,17 @@ static void kexec_prepare_cpus(void)
 
 static void kexec_prepare_cpus(void)
 {
+   extern void smp_release_cpus(void);
/*
 * move the secondarys to us so that we can copy
 * the new kernel 0-0x100 safely
 *
 * do this if kexec in setup.c ?
+*
+* We need to release the cpus if we are ever going from an
+* UP to an SMP kernel.
 */
-   smp_relase_cpus();
+   smp_release_cpus();
if (ppc_md.cpu_irq_down)
ppc_md.cpu_irq_down();
local_irq_disable();
Index: 2.6/arch/ppc64/kernel/head.S
===
--- 2.6.orig/arch/ppc64/kernel/head.S   2005-08-03 19:53:16.0 -0500
+++ 2.6/arch/ppc64/kernel/head.S2005-08-03 20:37:22.0 -0500
@@ -2071,7 +2071,7 @@ _GLOBAL(hmt_start_secondary)
blr
 #endif
 
-#if defined(CONFIG_SMP) && !defined(CONFIG_PPC_ISERIES)
+#if defined(CONFIG_KEXEC) || (defined(CONFIG_SMP) && 
!defined(CONFIG_PPC_ISERIES))
 _GLOBAL(smp_release_cpus)
/* All secondary cpus are spinning on a common
 * spinloop, release them all now so they can start
-
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.4.21: Sharing interrupts with serial console

[Chris Budd]

I have read 
http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/preparation-setport.html
and http://www.linux-mips.org/archives/linux-mips/2004-04/msg00134.html
and other items, but I still have not found the answers to the
following questions:

1.  The rs_init function in ./linux-2.4.21/drivers/char/serial.c
explicitly states "The interrupt of the serial console port can't be
shared."  Does this include *ALL* interrupts?  The code checks for
sharing only with other serial devices, not *ALL* types of devices
like I2C, RTC, etc.

2.  While the presence of the comment about not sharing was nice, it
does not explain "why?"  Why can't we share the serial console
interrupt?  The serial console seems to work when I alter serial.c to
skip this check for the sharing of interrupts with the serial console.

3.  Does the hardware platform matter?  We are running Linux 2.4.21 on
an embedded XScale(ARM)-based board.

Thanks,
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 patch] remove support for gcc < 3.2

[Dave Airlie]

On 8/1/05, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch removes support for gcc < 3.2 .
> 
> The advantages are:
> - reducing the number of supported gcc versions from 8 to 4 [1]
>   allows the removal of several #ifdef's and workarounds
> - my impression is that the older compilers are only rarely
>   used, so miscompilations of a driver with an old gcc might
>   not be detected for a longer amount of time
> 
>

Another disadvantage is you'll really piss of the VAX developers (all
3 of us!!!, well me not so much anymore...)

I think there is a gcc 4.x compiler nearly capable of building a
kernel for the VAX...

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: [openib-general] Re: [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes

[Grant Grundler]

On Wed, Aug 03, 2005 at 05:58:11PM -0700, yhlu wrote:
> Roland,
> 
> In LinuxBIOS, If I enable the prefmem64 to use real 64 range. the IB
> driver in Kernel can not be loaded.

Can you provide a few more details about the configuration?
o kernel version
o architecture (i386 or x86-64)
o post the full console output from power up?

Recent email on linux-pci raised awareness that 32-bit kernel
can not support 64-bit PCI MMIO addresses. struct resource (defined in
include/linux/ioport.h) defines the start/end field as "unsigned long".
That's only 32-bit on i386 kernels.

> PCI: 04:00.0 18 <- [0xfcf000 - 0xfcf07f] prefmem64
> PCI: 04:00.0 20 <- [0xfce000 - 0xfcefff] prefmem64
>   
I have to wonder if those BARs are truly prefetchable.
Does Mellanox assume CPU is the only one to write the 3rd BAR (RAM)
and the CPU implements a write-through cache (vs write back)?

I'm just guessing because I don't understand exactly how the
256MB of onboard RAM is accessed.

hth,
grant

> 
> ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005)
> ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex (Tavor 
> c)
> ib_mthca :04:00.0: Failed to initialize queue pair table, aborting.
> ib_mthca: probe of :04:00.0 failed with error -16
> ___
> openib-general mailing list
> openib-general@openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

And I have to wonder if those BARs truly are prefetchable.
It would imply only the CPU writes them and 
-
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] Speedup FAT filesystem directory reads

[Karsten Wiese]

Hi,

Please give this a try and commit to -mm or mainline, if approved.

Thanks,
Karsten

Summary:
This speeds up directory reads for large FAT partitions,
if the buffercache has to be filled from the drive.
Following values were taken from:
$ time find path_to_freshly_mounted_fat > /dev/null
on an otherwise idle system.
FAT with 16KB Clusters on IDE attached drive:   Factor  2
FAT with 32KB Clusters on USB2 attached drive:  Factor 10 (!)
Its less than 1/10 slower, if the buffercache is uptodate.

The patch touches 3 areas:
- fat_bmap() returns the sector's offset in the cluster or a 
  negativ error code instead of 0 or the negativ error code.
  It's callers are changed accordingly.
- fat__get_entry() calls sb_breadahead() to readahead a whole cluster,
  if the requested sector is the first one in a cluster.
  It is usefull to do this, because on FAT directories occupy whole
  clusters.
  Readahead is only done, if the cluster's first sector is not uptodate
  to avoid overhead, when the buffer cache is already uptodate.
  Note that on memory pressure, the maximal byte count wasted
  (read: has to be red from disk twice) is 1 cluster's size. Thats 64KB.
- Unrelated cleanup at one spot:
if (bh)
brelse(bh);
  is replaced with:
brelse(bh);
  brelse() can handle NULL pointer arguments by itself.

Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>

diff -ur linux-2.6.13_orig/fs/fat/cache.c linux-2.6.13/fs/fat/cache.c
--- linux-2.6.13_orig/fs/fat/cache.c	2005-07-31 21:15:16.0 +0200
+++ linux-2.6.13/fs/fat/cache.c	2005-08-02 13:55:50.0 +0200
@@ -320,5 +320,5 @@
 		return cluster;
 	else if (cluster)
 		*phys = fat_clus_to_blknr(sbi, cluster) + offset;
-	return 0;
+	return offset;
 }
diff -ur linux-2.6.13_orig/fs/fat/dir.c linux-2.6.13/fs/fat/dir.c
--- linux-2.6.13_orig/fs/fat/dir.c	2005-07-31 21:14:20.0 +0200
+++ linux-2.6.13/fs/fat/dir.c	2005-07-31 21:53:28.0 +0200
@@ -46,7 +46,7 @@
 	struct super_block *sb = dir->i_sb;
 	sector_t phys, iblock;
 	int offset;
-	int err;
+	int clu_sector;
 
 next:
 	if (*bh)
@@ -54,10 +54,21 @@
 
 	*bh = NULL;
 	iblock = *pos >> sb->s_blocksize_bits;
-	err = fat_bmap(dir, iblock, );
-	if (err || !phys)
+	clu_sector = fat_bmap(dir, iblock, );
+	if (clu_sector < 0 || !phys)
 		return -1;	/* beyond EOF or error */
 
+	if (0 == clu_sector) {
+		struct buffer_head *bh = __getblk(sb->s_bdev, phys, sb->s_blocksize);
+		if (!buffer_uptodate(bh)) {
+			int sec;
+			int sec_per_clus = MSDOS_SB(sb)->sec_per_clus;
+			for (sec = 0; sec < sec_per_clus; sec++)
+sb_breadahead(sb, phys + sec);
+		}
+		brelse(bh);
+	}
+
 	*bh = sb_bread(sb, phys);
 	if (*bh == NULL) {
 		printk(KERN_ERR "FAT: Directory bread(block %llu) failed\n",
@@ -635,8 +646,7 @@
 EODir:
 	filp->f_pos = cpos;
 FillFailed:
-	if (bh)
-		brelse(bh);
+	brelse(bh);
 	if (unicode)
 		free_page((unsigned long)unicode);
 out:
diff -ur linux-2.6.13_orig/fs/fat/inode.c linux-2.6.13/fs/fat/inode.c
--- linux-2.6.13_orig/fs/fat/inode.c	2005-07-31 21:15:16.0 +0200
+++ linux-2.6.13/fs/fat/inode.c	2005-08-02 13:55:50.0 +0200
@@ -56,7 +56,7 @@
 	int err;
 
 	err = fat_bmap(inode, iblock, );
-	if (err)
+	if (err < 0)
 		return err;
 	if (phys) {
 		map_bh(bh_result, sb, phys);
@@ -76,7 +76,7 @@
 	}
 	MSDOS_I(inode)->mmu_private += sb->s_blocksize;
 	err = fat_bmap(inode, iblock, );
-	if (err)
+	if (err < 0)
 		return err;
 	if (!phys)
 		BUG();

Re: [patch] ide: fix kmalloc_node breakage in ide driver

[Christoph Lameter]

On Wed, 3 Aug 2005, Ravikiran G Thirumalai wrote:

> Machines with ide-interfaces which do not have pci devices are crashing on 
> boot
> at pcibus_to_node in the ide drivers.  We noticed this on a x445 running
> 2.6.13-rc4.  Similar issue was discussed earlier, but the crash was due 
> to hwif being NULL.
> http://marc.theaimsgroup.com/?t=11207535203=1=2
> Andi and Christoph had patches, but neither went in.  Here's one of those
> patches with an added BUG_ON(hwif == NULL).  Please include.

This needs to go into 2.6.13.

-
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] flush icache early when loading module

[Rusty Russell]

On Thu, 2005-08-04 at 02:34 +0200, Thomas Koeller wrote:
> The patch below, created against linux-2.6.12.3, changes the sequence of
> operations performed during module loading to flush the instruction cache
> before module parameters are processed. If a module has parameters of an
> unusual type that cannot be handled using the standard accessor functions
> param_set_xxx and param_get_xxx, it has to to provide a set of accessor
> functions for this type. This requires module code to be executed during
> parameter processing, which is of course only possible after the icache
> has been flushed.
> 
> Signed-off-by: Thomas Koeller <[EMAIL PROTECTED]>

Yes, well caught.

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

-
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: fix kmalloc_node breakage in ide driver

[Ravikiran G Thirumalai]

Machines with ide-interfaces which do not have pci devices are crashing on boot
at pcibus_to_node in the ide drivers.  We noticed this on a x445 running
2.6.13-rc4.  Similar issue was discussed earlier, but the crash was due 
to hwif being NULL.
http://marc.theaimsgroup.com/?t=11207535203=1=2
Andi and Christoph had patches, but neither went in.  Here's one of those
patches with an added BUG_ON(hwif == NULL).  Please include.

Thanks,
Kiran


Patch fixes oops caused by ide interfaces not on pci. pcibus_to_node causes
the kernel to crash otherwise.  Patch also adds a BUG_ON to check if hwif is 
NULL. 

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]>
Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]>


Index: linux-2.6.13-rc1/drivers/ide/ide-probe.c
===
--- linux-2.6.13-rc1.orig/drivers/ide/ide-probe.c   2005-06-29 
20:06:53.0 -0400
+++ linux-2.6.13-rc1/drivers/ide/ide-probe.c2005-08-02 10:09:20.930965408 
-0400
@@ -960,6 +960,15 @@
 }
 #endif /* MAX_HWIFS > 1 */
 
+static inline int hwif_to_node(ide_hwif_t *hwif)
+{
+   if (hwif->pci_dev)
+   return pcibus_to_node(hwif->pci_dev->bus);
+   else
+   /* Add ways to determine the node of other busses here */
+   return -1;
+}
+
 /*
  * init request queue
  */
@@ -978,8 +987,7 @@
 *  do not.
 */
 
-   q = blk_init_queue_node(do_ide_request, _lock,
-   pcibus_to_node(drive->hwif->pci_dev->bus));
+   q = blk_init_queue_node(do_ide_request, _lock, hwif_to_node(hwif));
if (!q)
return 1;
 
@@ -1048,6 +1056,8 @@
 
BUG_ON(in_interrupt());
BUG_ON(irqs_disabled());
+   BUG_ON(hwif == NULL);
+   
down(_cfg_sem);
hwif->hwgroup = NULL;
 #if MAX_HWIFS > 1
@@ -1097,7 +1107,7 @@
spin_unlock_irq(_lock);
} else {
hwgroup = kmalloc_node(sizeof(ide_hwgroup_t), GFP_KERNEL,
-   pcibus_to_node(hwif->drives[0].hwif->pci_dev->bus));
+   hwif_to_node(hwif->drives[0].hwif));
if (!hwgroup)
goto out_up;
 
-
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-usb-devel] Re: Fw: ati-remote strangeness from 2.6.12 onwards

[Ryan Brown]

> mdew wrote:
> > mapped to "p". I found the TV Button, The DVD Button, the CH-/+ and
> > the OK Button all non-working, every other button produced the "p".
> 
> Could you please try 'showkey -s' from a console on all of those keys?

Without my patch, nothing shows up when pressing OK, TV and DVD, in showkey -s

# with my patch
mediabawx2:~# showkey -s
kb mode was XLATE

press any key (program terminates after 10s of last keypress)...
0x1c 0x9c- OK
0xe0 0x1f 0xe0 0x9f   - TV
0xe0 0x17 0xe0 0x97   - DVD

> Pavel: I would think that 'more useful' is not really the same as
> 'correct'. If you find it useful to map this key to 'ENTER', so you
> should remap it in userspace. It should not be KEY_ENTER in the kernel
> for at least two reasons:
> 
> - The key is labled 'ok' (and not enter). I assume the code KEY_OK is
>made for exactly that kind of key and certain applications might
>look for exactly this code.
> - You might want to differentiate between this key and the ENTER key
>of your keyboard, at least I do. If the kernel is sending the same
>code for both keys, this is not possible in userspace.
> 
> Frank
> 
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 5/5 ldt-accessors

[zach]

Introduce a write acessor for updating the current LDT.  This is required for
hypervisors like Xen that do not allow LDT pages to be directly written.

Testing - here's a fun little LDT test that can be trivially modified to test
limits as well.

/*
 * Copyright (c) 2005, Zachary Amsden ([EMAIL PROTECTED])
 * This is licensed under the GPL.
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#define __KERNEL__
#include 

void main(void)
{
struct user_desc desc;
char *code;
unsigned long long tsc;

code = (char *)mmap(0, 8192, PROT_EXEC|PROT_READ|PROT_WRITE,
 MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
desc.entry_number = 0;
desc.base_addr = code;
desc.limit = 1;
desc.seg_32bit = 1;
desc.contents = MODIFY_LDT_CONTENTS_CODE;
desc.read_exec_only = 0;
desc.limit_in_pages = 1;
desc.seg_not_present = 0;
desc.useable = 1;
if (modify_ldt(1, , sizeof(desc)) != 0) {
perror("modify_ldt");
}
printf("code base is 0x%08x\n", (unsigned)code);
code[0x0ffe] = 0x0f;  /* rdtsc */
code[0x0fff] = 0x31;
code[0x1000] = 0xcb;  /* lret */
__asm__ __volatile("lcall $7,$0xffe" : "=A" (tsc));
printf("TSC is 0x%016llx\n", tsc);
}

Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Index: linux-2.6.13/arch/i386/kernel/ldt.c
===
--- linux-2.6.13.orig/arch/i386/kernel/ldt.c2005-08-03 15:44:24.0 
-0700
+++ linux-2.6.13/arch/i386/kernel/ldt.c 2005-08-03 15:48:53.0 -0700
@@ -177,7 +177,7 @@
 static int write_ldt(void __user * ptr, unsigned long bytecount, int oldmode)
 {
struct mm_struct * mm = current->mm;
-   __u32 entry_1, entry_2, *lp;
+   __u32 entry_1, entry_2;
int error;
struct user_desc ldt_info;
 
@@ -205,8 +205,6 @@
goto out_unlock;
}
 
-   lp = (__u32 *) ((ldt_info.entry_number << 3) + (char *) 
mm->context.ldt);
-
/* Allow LDTs to be cleared by the user. */
if (ldt_info.base_addr == 0 && ldt_info.limit == 0) {
if (oldmode || LDT_empty(_info)) {
@@ -223,8 +221,7 @@
 
/* Install the new entry ...  */
 install:
-   *lp = entry_1;
-   *(lp+1) = entry_2;
+   write_ldt_entry(mm->context.ldt, ldt_info.entry_number, entry_1, 
entry_2);
error = 0;
 
 out_unlock:
Index: linux-2.6.13/include/asm-i386/desc.h
===
--- linux-2.6.13.orig/include/asm-i386/desc.h   2005-08-03 15:44:24.0 
-0700
+++ linux-2.6.13/include/asm-i386/desc.h2005-08-03 16:17:25.0 
-0700
@@ -96,6 +96,13 @@
(info)->seg_not_present == 1&& \
(info)->useable == 0)
 
+static inline void write_ldt_entry(void *ldt, int entry, __u32 entry_a, __u32 
entry_b)
+{
+   __u32 *lp = (__u32 *)((char *)ldt + entry*8);
+   *lp = entry_a;
+   *(lp+1) = entry_b;
+}
+
 #if TLS_SIZE != 24
 # error update this code.
 #endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

HZ==250 and rounding issues?

[Nishanth Aravamudan]

Hello all,

While discussing milliseconds and jiffies and their inter-relations with
Roman Zippel in a separate thread, I came across an interesting and
perhaps problematic rounding issue with directly using HZ when HZ==250.

Consider requesting a 10 millisecond sleep, in jiffies. This is
accomplished via HZ/100, as there are HZ jiffies in a second and, thus,
1/100th of HZ should be 10 milliseconds in jiffies (this is the common
interpretation, I think, and the flaw may simply lie in the
interpretation). But, if HZ==250, then HZ/100 = 2 (integer division with
truncation), which when translated to milliseconds, is 8 ms (250
interrupts per second means a jiffy is 4 milliseconds in duration).

Now, combine this with the potential corner case (explained in
http://marc.theaimsgroup.com/?l=linux-kernel=112311712414431=2)
where a schedule_timeout(HZ/100) request occurs immediately before a
timer interrupt occurs. We now might get a 4 millisecond sleep *and*
have schedule_timeout() return 0, indicating falsely that a full 10
millisecond sleep has elapsed.

Could be, though, that my analysis is flawed here too :) Please correct
me if that's the case!

I will try to audit the direct users of HZ; maybe this isn't really a
problem. Just some food for thought.

Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 1/5 more-asm-cleanup

[H. Peter Anvin]

[EMAIL PROTECTED] wrote:

Some more assembler cleanups I noticed along the way.



Index: linux-2.6.13/arch/i386/kernel/cpu/intel.c
===
--- linux-2.6.13.orig/arch/i386/kernel/cpu/intel.c  2005-08-03 
15:18:18.0 -0700
+++ linux-2.6.13/arch/i386/kernel/cpu/intel.c   2005-08-03 15:19:39.0 
-0700
@@ -82,16 +82,12 @@
  */
 static int __devinit num_cpu_cores(struct cpuinfo_x86 *c)
 {
-   unsigned int eax;
+   unsigned int eax, ebx, ecx, edx;
 
 	if (c->cpuid_level < 4)

return 1;
 
-	__asm__("cpuid"

-   : "=a" (eax)
-   : "0" (4), "c" (0)
-   : "bx", "dx");
-
+   cpuid(4, , , , );
if (eax & 0x1f)
return ((eax >> 26) + 1);


Reject!  This is a bogus patch; Intel's CPUID level 4 has a nonstandard 
dependency on ECX (idiots...) and therefore this needs special handling.


-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ACPI] Re: [PATCH] PNPACPI: fix types when decoding ACPI resources [resend]

[Shaohua Li]

On Wed, 2005-08-03 at 23:16 +0200, matthieu castet wrote:
> 
> There are drivers/acpi/motherboard.c that done some stuff already handle 
> by pnp/system.c.
Yes, it should be disabled if pnpacpi is enabled. The only concern is
motherboard.c also request some ACPI resources, which might not declaim
in ACPI motherboard device, but it's completely BIOS dependent. We might
could try remove it at -mm tree to see if it breaks any system later.

> 
> PS : I saw in acpi ols paper that you plan once all dupe acpi drivers 
> will be removed to register again the pnp device in acpi layer. Do you 
> plan to add more check and for example add only device that have a CRS 
> in pnp layer ?
For detecting PNP device? it's worthy trying.

Thanks,
Shaohua

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes

[yhlu]

Roland,

In LinuxBIOS, If I enable the prefmem64 to use real 64 range. the IB
driver in Kernel can not be loaded.

YH

PCI: 00:18.0 1c1 <- [0x001000 - 0x003fff] io 
PCI: 00:18.0 1b9 <- [0xfce000 - 0xfcf07f] prefmem 
PCI: 00:18.0 1b1 <- [0x00fc00 - 0x00fd2f] mem
PCI: 01:0f.0 24 <- [0xfce000 - 0xfcf07f] bus 4 prefmem
PCI: 01:0f.0 20 <- [0x00fd10 - 0x00fd1f] bus 4 mem
PCI: 04:00.0 10 <- [0x00fd10 - 0x00fd1f] mem64
PCI: 04:00.0 18 <- [0xfcf000 - 0xfcf07f] prefmem64
PCI: 04:00.0 20 <- [0xfce000 - 0xfcefff] prefmem64  

ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005)
ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex (Tavor c)
ib_mthca :04:00.0: Failed to initialize queue pair table, aborting.
ib_mthca: probe of :04:00.0 failed with error -16
-
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 11/15] KGDB: KGDBoE I/O driver

[Matt Mackall]

On Fri, Jul 29, 2005 at 02:20:55PM -0700, Tom Rini wrote:
> 
> This is the simple KGDB over Ethernet I/O driver that uses netpoll for all of
> the heavy lifting.  At one point this was very similar to the version Matt
> Mackall wrote and is currently in Andrew's tree.  Since then it has been
> reworked to fit into our model.

Looks good to me.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] remove support for gcc < 3.2

[Mathieu Chouquet-Stringer]

[EMAIL PROTECTED] (Gustavo Guillermo Pérez) writes:
> Please keep the 2.95 support I use to use a lot, on not new hardware.
> If you have old hardware with not much resources gcc 2.95 works just fine and 
> fast, even you build the main kernel on other machine, by compatibility 
> issues one or two drivers should be builded a lot of times into the older 
> hardware, then we are forced to build gcc 3.4 or something like.

Moreover I get some weird networking problems which prevent setting up the
routes (RNETLINK invalid argument messages) when I compile my kernel with
4.0.1 while the same kernel, same config works fine compiled with 3.2.3...

So eventhough 4.0 is supposed to be supported, it doesn't work too well in
my case.
-- 
Mathieu Chouquet-Stringer
-
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] push rounding up of relative request to schedule_timeout()

[Nishanth Aravamudan]

On 03.08.2005 [16:20:57 +0200], Roman Zippel wrote:
> Hi,
> 
> On Mon, 1 Aug 2005, Nishanth Aravamudan wrote:
> 
> > +unsigned int __sched schedule_timeout_msecs(unsigned int timeout_msecs)
> > +{
> > +   unsigned long expire_jifs;
> > +
> > +   if (timeout_msecs == MAX_SCHEDULE_TIMEOUT_MSECS) {
> > +   expire_jifs = MAX_SCHEDULE_TIMEOUT;
> > +   } else {
> > +   /*
> > +* msecs_to_jiffies() is a unit conversion, which truncates
> > +* (rounds down), so we need to add 1.
> > +*/
> > +   expire_jifs = msecs_to_jiffies(timeout_msecs) + 1;
> > +   }
> > +
> > +   expire_jifs = schedule_timeout(expire_jifs);
> > +
> > +   /*
> > +* don't need to add 1 here, even though there is truncation,
> > +* because we will add 1 if/when the value is sent back in
> > +*/
> > +   return jiffies_to_msecs(expire_jifs);
> > +}
> 
> As I already mentioned for msleep_interruptible this is a really terrible 
> interface.
> The "jiffies_to_msecs(msecs_to_jiffies(timeout_msecs) + 1)" case (when the 
> process is immediately woken up again) makes the caller suspectible to 
> timeout manipulations and requires constant reauditing, that no caller 
> gets it wrong, so it's better to avoid this error source completely.

After some thought today, I realized the +1 case is not specific to
milliseconds. It's just that it's only being done *correctly* in the
milliseconds case...I think ;)

So, consider the following:

We are requesting a 10 jiffy sleep via

set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(10);

Keep in mind that jiffies is only incremented when the timer interrupt
occurs (the whole point being, again, we do not have any inter-tick
jiffy-value).

In schedule_timeout() we will add the 10 to jiffies' current value. But
what happens if we were calling schedule_timeout() immediately before
the next timer interrupt occurs? Then we will only sleep slightly more
than 9 jiffies, instead of the 10 requested. The basic issue is that we
are always taking the floor of the current position in jiffies in
schedule_timeout() by adding the relative offset to jiffies. To
guarantee the timeout requested passes, we must add the relative offset
to (jiffies+1) [See the attached patch, which I think fixes the
"problem" in 2.6.13-rc5]. Most callers are already rounding up or adding
one to their request, so it may not be a problem. And, often, these are
sleeping paths, so most callers don't care about precision. So, while
you are correct that there is a chance for "infinite" sleep in
msleep_interruptible() and schedule_timeout_{intr,unintr}_msecs(), there
technically *should* be such a possibility in the jiffies case too, but
the code wasn't correct up until now.

All in all, seems buggy, but my analysis may also be wrong -- and this
case may be damn well near impossible to actually create.

> Constant conversion between different time units is a really bad idea. If 
> the user needs the remaining time, he is really better off to do it 
> himself by checking jiffies and only does an initial conversion from 
> relative to absolute (kernel) time.
> This wrapper function really should be an inline function and should look 
> more like this:
> 
> static inline int schedule_timeout_msecs(unsigned int timeout_msecs)
> {
>   return schedule_timeout(msecs_to_jiffies(timeout_msecs) + 1) != 0;
> }

I don't think I want the schedule_timeout*() functions' return values'
meanings to be different depending on whether you use milliseconds or
jiffies. Your version makes the millisecond-case boolean in return,
which is differnent than schedule_timeout()'s remaining-jiffies return
value.

I have also been thinking about the need to use
while(time_after(timeout_jiffies, timeout)) vs.  while(timeout_msecs),
but I will respond to a different e-mail about that.

Thanks,
Nish

---

 timer.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

Description: Ensure that schedule_timeout() requests can not possibly
expire early in the timeout case, by adding the requested relative jiffy
value to the next value of jiffies. Currently, by adding to the current
value of jiffies, we might actually expire a jiffy too early (in a
corner case).

Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>

--- 2.6.13-rc5/kernel/timer.c   2005-08-01 12:31:53.0 -0700
+++ 2.6.13-rc5-dev/kernel/timer.c   2005-08-03 17:30:10.0 -0700
@@ -1134,7 +1134,7 @@ fastcall signed long __sched schedule_ti
}
}
 
-   expire = timeout + jiffies;
+   expire = timeout + jiffies + 1;
 
init_timer();
timer.expires = expire;
@@ -1190,9 +1190,10 @@ unsigned int __sched schedule_timeout_ms
} else {
/*
 * msecs_to_jiffies() is a unit conversion, which truncates
-* (rounds down), so we need to add 1.
+* (rounds down), so we need to add 1, but this is taken
+   

Re: [ACPI] Re: [PATCH] PNPACPI: fix types when decoding ACPI resources [resend]

[Shaohua Li]

On Wed, 2005-08-03 at 09:20 -0600, Bjorn Helgaas wrote:
> On Tuesday 02 August 2005 7:01 pm, Shaohua Li wrote:
> > On Tue, 2005-08-02 at 09:55 -0600, Bjorn Helgaas wrote:
> > > Any objections to the patch below?  I posted it last Wednesday,
> > > but haven't heard anything.  Once we have this fix, 8250_pnp
> > > should have sufficient functionality that we can get rid of
> > > 8250_acpi.
> > > 
> > > Use types that match the ACPI resource structures.  Previously
> > > the u64 value from an RSTYPE_ADDRESS64 was passed as an int,
> > > which corrupts the value.
> > > 
> > > This is one of the things that prevents 8250_pnp from working
> > > on HP ia64 boxes.  After 8250_pnp works, we will be able to
> > > remove 8250_acpi.c.
> > We might always use 'unsigned long'.
> 
> Do you have a reason for preferring 'unsigned long' over the
> exact types used in the ACPI resource structures?  I thought
> it was useful to use the exact types, because then whatever
> conversion needs to happen is all in one place.
> 
> In the existing code, there's implicit conversion when you
> call "pnpacpi_parse_allocated_memresource(..., int mem, int len)"
> and pass u64 values as "mem" and "len".  You have to look both
> at the call site and the called code.  And gcc doesn't even
> complain about this truncation.
> 
> But I guess it doesn't matter much either way.
Either is ok to me.

> 
> > Did you have plan to remove other 
> > legacy acpi drivers?
> 
> No, I didn't -- which ones are you thinking about?  Looking at
> the callers of acpi_bus_register_driver(), I see:
> 
>   arch/ia64/hp/common/sba_iommu.c
>   Probably can't be converted because it needs the
>   ACPI handle to extract a vendor-specific data
>   item from _CRS.
> 
>   drivers/char/hpet.c
>   This probably should be converted to PNP.  I'll
>   look into doing this.
Great! After then we could push the ACPIPNP hotplug staff.

Thanks,
Shaohua

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 4/5 gdt-tss-redundant

[zach]

When reviewing GDT updates, I found the code:

set_tss_desc(cpu,t);/* This just modifies memory; ... */
per_cpu(cpu_gdt_table, cpu)[GDT_ENTRY_TSS].b &= 0xfdff;

This second line is unnecessary, since set_tss_desc() has already cleared
the busy bit.

Commented disassembly, line 1:

c028b8bd:   8b 0c 86mov(%esi,%eax,4),%ecx
c028b8c0:   01 cb   add%ecx,%ebx
c028b8c2:   8d 0c 39lea(%ecx,%edi,1),%ecx

  => %ecx = per_cpu(cpu_gdt_table, cpu)

c028b8c5:   8d 91 80 00 00 00   lea0x80(%ecx),%edx

  => %edx = _cpu(cpu_gdt_table, cpu)[GDT_ENTRY_TSS]

c028b8cb:   66 c7 42 00 73 20   movw   $0x2073,0x0(%edx)
c028b8d1:   66 89 5a 02 mov%bx,0x2(%edx)
c028b8d5:   c1 cb 10ror$0x10,%ebx
c028b8d8:   88 5a 04mov%bl,0x4(%edx)
c028b8db:   c6 42 05 89 movb   $0x89,0x5(%edx)

  => ((char *)%edx)[5] = 0x89
  (equivalent) ((char *)per_cpu(cpu_gdt_table, cpu)[GDT_ENTRY_TSS])[5] = 0x89

c028b8df:   c6 42 06 00 movb   $0x0,0x6(%edx)
c028b8e3:   88 7a 07mov%bh,0x7(%edx)
c028b8e6:   c1 cb 10ror$0x10,%ebx

  => other bits

Commented disassembly, line 2:

c028b8e9:   8b 14 86mov(%esi,%eax,4),%edx
c028b8ec:   8d 04 3alea(%edx,%edi,1),%eax

  => %eax = per_cpu(cpu_gdt_table, cpu)

c028b8ef:   81 a0 84 00 00 00 ffandl   $0xfdff,0x84(%eax)

  => per_cpu(cpu_gdt_table, cpu)[GDT_ENTRY_TSS].b &= 0xfdff;
  (equivalent) ((char *)per_cpu(cpu_gdt_table, cpu)[GDT_ENTRY_TSS])[5] &= 0xfd

Note that (0x89 & ~0xfd) == 0; i.e, set_tss_desc(cpu,t) has already stored the
type field in the GDT with the busy bit clear.

Eliminating redundant and obscure code is always a good thing; in fact, I
pointed out this same optimization many moons ago in arch/i386/setup.c, back
when it used to be called that.

Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>

Index: linux-2.6.13/arch/i386/power/cpu.c
===
--- linux-2.6.13.orig/arch/i386/power/cpu.c 2005-08-02 17:06:21.0 
-0700
+++ linux-2.6.13/arch/i386/power/cpu.c  2005-08-03 15:27:57.0 -0700
@@ -84,7 +84,6 @@
struct tss_struct * t = _cpu(init_tss, cpu);
 
set_tss_desc(cpu,t);/* This just modifies memory; should not be 
necessary. But... This is necessary, because 386 hardware has concept of busy 
TSS or some similar stupidity. */
-per_cpu(cpu_gdt_table, cpu)[GDT_ENTRY_TSS].b &= 0xfdff;
 
load_TR_desc(); /* This does ltr */
load_LDT(>active_mm->context); /* This does lldt */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 3/5 explicit-iopl

[zach]

The pushf/popf in switch_to are ONLY used to switch IOPL.  Making this
explicit in C code is more clear.  This pushf/popf pair was added as a
bugfix for leaking IOPL to unprivileged processes when using sysenter/sysexit
based system calls (sysexit does not restore flags).

When requesting an IOPL change in sys_iopl(), it is just as easy to
change the current flags and the flags in the stack image (in case an IRET
is required), but there is no reason to force an IRET if we came in from the
SYSENTER path.

This change is the minimal solution for supporting a paravirtualized Linux
kernel that allows user processes to run with I/O privilege.  Other solutions
require radical rewrites of part of the low level fault / system call handling
code, or do not fully support sysenter based system calls.

Unfortunately, this added one field to the thread_struct.  But as a bonus, on
P4, the fastest time measured for switch_to() went from 312 to 260 cycles, a
win of about 17% in the fast case through this performance critical path.

Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Index: linux-2.6.13/arch/i386/kernel/ioport.c
===
--- linux-2.6.13.orig/arch/i386/kernel/ioport.c 2005-06-17 12:48:29.0 
-0700
+++ linux-2.6.13/arch/i386/kernel/ioport.c  2005-08-02 17:11:01.0 
-0700
@@ -132,6 +132,7 @@
volatile struct pt_regs * regs = (struct pt_regs *) 
unsigned int level = regs->ebx;
unsigned int old = (regs->eflags >> 12) & 3;
+   struct thread_struct * t = >thread;
 
if (level > 3)
return -EINVAL;
@@ -140,8 +141,8 @@
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
}
-   regs->eflags = (regs->eflags &~ 0x3000UL) | (level << 12);
-   /* Make sure we return the long way (not sysenter) */
-   set_thread_flag(TIF_IRET);
+   t->iopl = level << 12;
+   regs->eflags = (regs->eflags & ~X86_EFLAGS_IOPL) | t->iopl;
+   set_iopl_mask(t->iopl);
return 0;
 }
Index: linux-2.6.13/arch/i386/kernel/process.c
===
--- linux-2.6.13.orig/arch/i386/kernel/process.c2005-08-02 
17:08:58.0 -0700
+++ linux-2.6.13/arch/i386/kernel/process.c 2005-08-02 17:11:01.0 
-0700
@@ -716,6 +716,13 @@
loadsegment(gs, next->gs);
 
/*
+* Restore IOPL if needed.
+*/
+   if (unlikely(prev->iopl != next->iopl)) {
+   set_iopl_mask(next->iopl);
+   }
+
+   /*
 * Now maybe reload the debug registers
 */
if (unlikely(next->debugreg[7])) {
Index: linux-2.6.13/include/asm-i386/processor.h
===
--- linux-2.6.13.orig/include/asm-i386/processor.h  2005-08-02 
17:06:23.0 -0700
+++ linux-2.6.13/include/asm-i386/processor.h   2005-08-02 17:11:27.0 
-0700
@@ -457,6 +457,7 @@
unsigned long   *io_bitmap_ptr;
 /* max allowed port in the bitmap, in bytes: */
unsigned long   io_bitmap_max;
+   unsigned long   iopl;
 /* performance counters */
struct vperfctr *perfctr;
 };
@@ -514,6 +515,21 @@
: /* no output */   \
:"r" (value))
 
+/*
+ * Set IOPL bits in EFLAGS from given mask
+ */
+static inline void set_iopl_mask(unsigned mask)
+{
+   unsigned int reg;
+   __asm__ __volatile__ ("pushfl;"
+ "popl %0;"
+ "andl %1, %0;"
+ "orl %2, %0;"
+ "pushl %0;"
+ "popfl"
+   : "=" (reg)
+   : "i" (~X86_EFLAGS_IOPL), "r" (mask));
+}
 
 /* Forward declaration, a strange C thing */
 struct task_struct;
Index: linux-2.6.13/include/asm-i386/system.h
===
--- linux-2.6.13.orig/include/asm-i386/system.h 2005-08-02 17:06:23.0 
-0700
+++ linux-2.6.13/include/asm-i386/system.h  2005-08-02 17:11:49.0 
-0700
@@ -15,8 +15,7 @@
 #define switch_to(prev,next,last) do { \
unsigned long esi,edi;  \
perfctr_suspend_thread(&(prev)->thread);\
-   asm volatile("pushfl\n\t"   \
-"pushl %%ebp\n\t"  \
+   asm volatile("pushl %%ebp\n\t"  \
 "movl %%esp,%0\n\t"/* save ESP */  \
 "movl %5,%%esp\n\t"/* restore ESP */   \
 "movl $1f,%1\n\t"  /* save EIP */  \
@@ -24,7 +23,6 @@
 "jmp __switch_to\n"

[PATCH] 2/5 privilege-cleanup

[zach]

Privilege checking cleanup.  Originally, these diffs were much greater,
but recent cleanups in Linux have already done much of the cleanup.  I
added some explanatory comments in places where the reasoning behind
certain tests is rather subtle.

Also, in traps.c, we can skip the user_mode check in handle_BUG().  The
reason is, there are only two call chains - one via die_if_kernel() and
one via do_page_fault(), both entering from die().  Both of these paths
already ensure that a kernel mode failure has happened.  Also,
the original check here, if (user_mode(regs)) was insufficient anyways,
since it would not rule out BUG faults from V8086 mode execution.

Saving the %ss segment in show_regs() rather than assuming a fixed value
also gives better information about the current kernel state in the
register dump.

Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Index: linux-2.6.13/arch/i386/kernel/signal.c
===
--- linux-2.6.13.orig/arch/i386/kernel/signal.c 2005-08-02 17:06:21.0 
-0700
+++ linux-2.6.13/arch/i386/kernel/signal.c  2005-08-02 17:09:54.0 
-0700
@@ -603,7 +603,9 @@
 * We want the common case to go fast, which
 * is why we may in certain cases get here from
 * kernel mode. Just return without doing anything
-* if so.
+* if so.  vm86 regs switched out by assembly code
+* before reaching here, so testing against kernel
+* CS suffices.
 */
if (!user_mode(regs))
return 1;
Index: linux-2.6.13/arch/i386/kernel/traps.c
===
--- linux-2.6.13.orig/arch/i386/kernel/traps.c  2005-08-02 17:06:21.0 
-0700
+++ linux-2.6.13/arch/i386/kernel/traps.c   2005-08-02 17:09:54.0 
-0700
@@ -245,7 +245,7 @@
unsigned short ss;
 
esp = (unsigned long) (>esp);
-   ss = __KERNEL_DS;
+   savesegment(ss, ss);
if (user_mode(regs)) {
in_kernel = 0;
esp = regs->esp;
@@ -302,9 +302,6 @@
char c;
unsigned long eip;
 
-   if (user_mode(regs))
-   goto no_bug;/* Not in kernel */
-
eip = regs->eip;
 
if (eip < PAGE_OFFSET)
Index: linux-2.6.13/include/asm-i386/ptrace.h
===
--- linux-2.6.13.orig/include/asm-i386/ptrace.h 2005-08-02 17:04:23.0 
-0700
+++ linux-2.6.13/include/asm-i386/ptrace.h  2005-08-02 17:09:54.0 
-0700
@@ -61,6 +61,13 @@
 struct task_struct;
 extern void send_sigtrap(struct task_struct *tsk, struct pt_regs *regs, int 
error_code);
 
+/*
+ * user_mode_vm(regs) determines whether a register set came from user mode.
+ * This is true if V8086 mode was enabled OR if the register set was from
+ * protected mode with RPL-3 CS value.  This tricky test checks that with
+ * one comparison.  Many places in the kernel can bypass this full check
+ * if they have already ruled out V8086 mode, so user_mode(regs) can be used.
+ */
 static inline int user_mode(struct pt_regs *regs)
 {
return (regs->xcs & 3) != 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] 1/5 more-asm-cleanup

[zach]

Some more assembler cleanups I noticed along the way.

Diffs against: 2.6.13-rc4-mm1

Signed-off-by: Zachary Amsden <[EMAIL PROTECTED])
Index: linux-2.6.13/arch/i386/kernel/crash.c
===
--- linux-2.6.13.orig/arch/i386/kernel/crash.c  2005-08-03 15:18:18.0 
-0700
+++ linux-2.6.13/arch/i386/kernel/crash.c   2005-08-03 15:19:39.0 
-0700
@@ -153,7 +153,7 @@
disable_local_APIC();
atomic_dec(_for_crash_ipi);
/* Assume hlt works */
-   __asm__("hlt");
+   halt();
for(;;);
 
return 1;
Index: linux-2.6.13/arch/i386/kernel/machine_kexec.c
===
--- linux-2.6.13.orig/arch/i386/kernel/machine_kexec.c  2005-08-03 
15:18:18.0 -0700
+++ linux-2.6.13/arch/i386/kernel/machine_kexec.c   2005-08-03 
15:19:39.0 -0700
@@ -93,10 +93,7 @@
curidt.size= limit;
curidt.address = (unsigned long)newidt;
 
-   __asm__ __volatile__ (
-   "lidtl %0\n"
-   : : "m" (curidt)
-   );
+   load_idt();
 };
 
 
@@ -108,10 +105,7 @@
curgdt.size= limit;
curgdt.address = (unsigned long)newgdt;
 
-   __asm__ __volatile__ (
-   "lgdtl %0\n"
-   : : "m" (curgdt)
-   );
+   load_gdt();
 };
 
 static void load_segments(void)
Index: linux-2.6.13/arch/i386/kernel/process.c
===
--- linux-2.6.13.orig/arch/i386/kernel/process.c2005-08-03 
15:18:18.0 -0700
+++ linux-2.6.13/arch/i386/kernel/process.c 2005-08-03 17:27:48.0 
-0700
@@ -165,7 +165,7 @@
 */
local_irq_disable();
while (1)
-   __asm__ __volatile__("hlt":::"memory");
+   halt();
 }
 #else
 static inline void play_dead(void)
Index: linux-2.6.13/arch/i386/kernel/msr.c
===
--- linux-2.6.13.orig/arch/i386/kernel/msr.c2005-08-03 15:18:18.0 
-0700
+++ linux-2.6.13/arch/i386/kernel/msr.c 2005-08-03 15:19:39.0 -0700
@@ -46,23 +46,13 @@
 
 static struct class *msr_class;
 
-/* Note: "err" is handled in a funny way below.  Otherwise one version
-   of gcc or another breaks. */
-
 static inline int wrmsr_eio(u32 reg, u32 eax, u32 edx)
 {
int err;
 
-   asm volatile ("1:   wrmsr\n"
- "2:\n"
- ".section .fixup,\"ax\"\n"
- "3:   movl %4,%0\n"
- " jmp 2b\n"
- ".previous\n"
- ".section __ex_table,\"a\"\n"
- " .align 4\n" "   .long 1b,3b\n" ".previous":"=" (err)
- :"a"(eax), "d"(edx), "c"(reg), "i"(-EIO), "0"(0));
-
+   err = wrmsr_safe(reg, eax, edx);
+   if (err)
+   err = -EIO;
return err;
 }
 
@@ -70,18 +60,9 @@
 {
int err;
 
-   asm volatile ("1:   rdmsr\n"
- "2:\n"
- ".section .fixup,\"ax\"\n"
- "3:   movl %4,%0\n"
- " jmp 2b\n"
- ".previous\n"
- ".section __ex_table,\"a\"\n"
- " .align 4\n"
- " .long 1b,3b\n"
- ".previous":"=" (err), "=a"(*eax), "=d"(*edx)
- :"c"(reg), "i"(-EIO), "0"(0));
-
+   err = rdmsr_safe(reg, eax, edx);
+   if (err)
+   err = -EIO;
return err;
 }
 
Index: linux-2.6.13/arch/i386/kernel/cpu/intel.c
===
--- linux-2.6.13.orig/arch/i386/kernel/cpu/intel.c  2005-08-03 
15:18:18.0 -0700
+++ linux-2.6.13/arch/i386/kernel/cpu/intel.c   2005-08-03 15:19:39.0 
-0700
@@ -82,16 +82,12 @@
  */
 static int __devinit num_cpu_cores(struct cpuinfo_x86 *c)
 {
-   unsigned int eax;
+   unsigned int eax, ebx, ecx, edx;
 
if (c->cpuid_level < 4)
return 1;
 
-   __asm__("cpuid"
-   : "=a" (eax)
-   : "0" (4), "c" (0)
-   : "bx", "dx");
-
+   cpuid(4, , , , );
if (eax & 0x1f)
return ((eax >> 26) + 1);
else
Index: linux-2.6.13/arch/i386/mach-voyager/voyager_basic.c
===
--- linux-2.6.13.orig/arch/i386/mach-voyager/voyager_basic.c2005-08-03 
15:18:18.0 -0700
+++ linux-2.6.13/arch/i386/mach-voyager/voyager_basic.c 2005-08-03 
15:19:39.0 -0700
@@ -234,10 +234,9 @@
 #endif
}
/* and wait for it to happen */
-   for(;;) {
-   __asm("cli");
-   __asm("hlt");
-   }
+   local_irq_disable();
+   for(;;) 
+   halt();
 }
 
 /* copied from process.c */
@@ -272,10 +271,9 @@
   

[PATCH] flush icache early when loading module

[Thomas Koeller]

The patch below, created against linux-2.6.12.3, changes the sequence of
operations performed during module loading to flush the instruction cache
before module parameters are processed. If a module has parameters of an
unusual type that cannot be handled using the standard accessor functions
param_set_xxx and param_get_xxx, it has to to provide a set of accessor
functions for this type. This requires module code to be executed during
parameter processing, which is of course only possible after the icache
has been flushed.

Signed-off-by: Thomas Koeller <[EMAIL PROTECTED]>





--- linux-2.6.12.3-orig/kernel/module.c 2005-08-04 01:11:32.0 +0200
+++ linux-2.6.12.3/kernel/module.c  2005-08-04 02:00:16.0 +0200
@@ -1413,6 +1413,7 @@ static struct module *load_module(void _
long err = 0;
void *percpu = NULL, *ptr = NULL; /* Stops spurious gcc warning */
struct exception_table_entry *extable;
+   mm_segment_t old_fs;
 
DEBUGP("load_module: umod=%p, len=%lu, uargs=%p\n",
   umod, len, uargs);
@@ -1677,6 +1678,24 @@ static struct module *load_module(void _
if (err < 0)
goto cleanup;
 
+   /* flush the icache in correct context */
+   old_fs = get_fs();
+   set_fs(KERNEL_DS);
+
+   /*
+* Flush the instruction cache, since we've played with text.
+* Do it before processing of module parameters, so the module
+* can provide parameter accessor functions of its own.
+*/
+   if (mod->module_init)
+   flush_icache_range((unsigned long)mod->module_init,
+  (unsigned long)mod->module_init
+  + mod->init_size);
+   flush_icache_range((unsigned long)mod->module_core,
+  (unsigned long)mod->module_core + mod->core_size);
+
+   set_fs(old_fs);
+
mod->args = args;
if (obsparmindex) {
err = obsolete_params(mod->name, mod->args,
@@ -1758,7 +1777,6 @@ sys_init_module(void __user *umod,
const char __user *uargs)
 {
struct module *mod;
-   mm_segment_t old_fs = get_fs();
int ret = 0;
 
/* Must have permission */
@@ -1776,19 +1794,6 @@ sys_init_module(void __user *umod,
return PTR_ERR(mod);
}
 
-   /* flush the icache in correct context */
-   set_fs(KERNEL_DS);
-
-   /* Flush the instruction cache, since we've played with text */
-   if (mod->module_init)
-   flush_icache_range((unsigned long)mod->module_init,
-  (unsigned long)mod->module_init
-  + mod->init_size);
-   flush_icache_range((unsigned long)mod->module_core,
-  (unsigned long)mod->module_core + mod->core_size);
-
-   set_fs(old_fs);
-
/* Now sew it into the lists.  They won't access us, since
strong_try_module_get() will fail. */
stop_machine_run(__link_module, mod, NR_CPUS);

-- 
Thomas Koeller
[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: Documentation - how to apply patches for various trees

[Grant Coady]

Hi Jesper,
On Wed, 3 Aug 2005 23:28:06 +0200, Jesper Juhl <[EMAIL PROTECTED]> wrote:

I like it, just a little concerned about confusing new user with too 
many alternative patching methods up front...

>+ This (as usual with Linux and other UNIX like operating systems) can be
>+done in several different ways.
>+In all the examples below I feed the file (in uncompressed form) to patch
>+via stdin using the following syntax:
>+  patch -p1 < path/to/patch-x.y.z
>+
>+but patch can also get the name of the file to use via the -i argument, like
>+this:
>+  patch -p1 -i path/to/patch-x.y.z
>+
>+If your patch file is compressed with gzip or bzip2 and you don't want to
>+uncompress it before applying it, then you can feed it to patch like this
>+instead:

cat path/to/patch-x.y.z.gz | patch -p1
>+  zcat path/to/patch-x.y.z.gz | patch -p1
>+  bzcat path/to/patch-x.y.z.bz2 | patch -p1

In a howto, I'd prefer  _one_ consistent method to reduce the 
reader's confusion.  

The above trio of commands serves me well over many years' kernel 
patching, and it is trivial to up-arrow, home, change compression 
method, retry ... when my fingers get ahead of my mind :)


Experience users recognise the intent of the commands and use their 
favourite method instead, almost without thinking.


Spelling:

s/uncompression/decompression/
s/adviced/advised/
s/bandwith/bandwidth/

Cheers,
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/

Re: 2.6.13-rc3-mm3

[Christoph Lameter]

Could you try the following patch? I think the problem was that higher 
addressses were not mappable via the page fault handler. This patch 
inserts the pmd entry into the pgd as necessary if the pud level is 
folded.

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>

Index: linux-2.6.13-rc4/mm/memory.c
===
--- linux-2.6.13-rc4.orig/mm/memory.c   2005-08-03 17:08:29.0 -0700
+++ linux-2.6.13-rc4/mm/memory.c2005-08-03 17:15:22.0 -0700
@@ -2144,9 +2144,16 @@
 */
page_table_atomic_start(mm);
pgd = pgd_offset(mm, address);
-#ifndef __PAGETABLE_PUD_FOLDED
if (unlikely(pgd_none(*pgd))) {
+#ifdef __PAGETABLE_PUD_FOLDED
+   /* If the pud is folded then we need to insert a pmd entry into
+* a pgd. pud_none(pgd) == 0 so the next if statement will never
+* be taken
+*/
+   pmd_t *new;
+#else
pud_t *new;
+#endif
 
page_table_atomic_stop(mm);
new = pud_alloc_one(mm, address);
@@ -2158,7 +2165,6 @@
if (!pgd_test_and_populate(mm, pgd, new))
pud_free(new);
}
-#endif
 
pud = pud_offset(pgd, address);
if (unlikely(pud_none(*pud))) {
Index: linux-2.6.13-rc4/include/asm-generic/4level-fixup.h
===
--- linux-2.6.13-rc4.orig/include/asm-generic/4level-fixup.h2005-08-03 
17:06:01.0 -0700
+++ linux-2.6.13-rc4/include/asm-generic/4level-fixup.h 2005-08-03 
17:09:38.0 -0700
@@ -27,6 +27,7 @@
 #define pud_ERROR(pud) do { } while (0)
 #define pud_clear(pud) pgd_clear(pud)
 #define pud_populate   pgd_populate
+#define pud_alloc_one  pmd_alloc_one
 
 #undef pud_free_tlb
 #define pud_free_tlb(tlb, x)do { } while (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: BTTV - experimental no_overlay patch

[Mauro Carvalho Chehab]

Bodo,

Please, send me bttv init logs. I need to know if PCI quirks has
detected your PCI chipset as a problematic one.

Em Qui, 2005-08-04 às 01:02 +0200, Bodo Eggert escreveu:
> Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> 
> > This small patch will allow no_overlay flag to disable BTTV driver to
> > report OVERLAY capabilities. It should fix your troubles by enabling
> > no_overlay=1 when inserting bttv module.
> > 
> > This patch is against our CVS tree, but should apply with some hunk on
> > 2.6.13-rc4 or 2.6.13-rc5.
> > 
> > I'll generate a new one at morning, against 2.6.13-rc5 hopefully to
> > have it applied at 2.6.13, since it fixes an OOPS.
> 
> The CVS line will off cause not apply, and I needed to change
> s/static// int no_overlay in bttv-cards.c.
Strange. At CVS it worked even with static. But it should be ok. 
> 
> The picture is less distorted by pci activity with no_overlay=1, and it
> feels like the stable interface I used with my nvidia+2.4+XF86 before
> upgrading to 2.6+radeon+X.org. No OOPS within the first few minutes:).
That's good!

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/

[ANNOUNCE] Interbench 0.27

[Con Kolivas]

Interbench is a benchmark application is designed to benchmark interactivity 
in Linux.

Direct download link:
http://ck.kolivas.org/apps/interbench/interbench-0.27.tar.bz2

Web page:
http://interbench.kolivas.org

Changes:
Standard deviation and average latency calculation was corrected. Gaming 
standard deviation was implemented.

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: Testing RC kernels [KORG]

[John Stoffel]

> "Andrew" == Andrew James Wade <[EMAIL PROTECTED]> writes:

Andrew> I updated my kernel more frequently after learning of ketchup.
Andrew> (). The bother of getting the
Andrew> patch sequence right and applying it was enough to discourage me.
Andrew> No, it's not particularly difficult, but it may well be enough
Andrew> to discourage casual testers. 

Hear hear!  Ketchup is an amazing tool and automates a boring task, so
it's got my vote for most useful kernel build tool right now.

John
-
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: Documentation - how to apply patches for various trees

[Johannes Stezenbach]

On Wed, Aug 03, 2005 Jesper Juhl wrote:
> +How do I feed a patch/diff file to `patch'?
> +---
> + This (as usual with Linux and other UNIX like operating systems) can be
> +done in several different ways.
> +In all the examples below I feed the file (in uncompressed form) to patch
> +via stdin using the following syntax:
> + patch -p1 < path/to/patch-x.y.z

I think you should mention the -s flag. Given the size of an
average kernel patch it is otherwise very likely that errors scroll
away unnoticed.

OTOH you might also want to add a mention of lsdiff and diffstat.

Johannes
-
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: [ck] [ANNOUNCE] Interbench v0.26

[Con Kolivas]

On Thu, 4 Aug 2005 09:25 am, Con Kolivas wrote:
> On Thu, 4 Aug 2005 09:25 am, Peter Williams wrote:
> > Con Kolivas wrote:
> > > On Wed, 3 Aug 2005 22:01, Gabriel Devenyi wrote:
> > >>You haven't quite completely fixed the SD calculations it seems:
> > >>
> > >>
> > >>--- Benchmarking simulated cpu of Gaming in the presence of
> > >> simulated--- LoadLatency +/- SD (ms)  Max Latency   % Desired CPU
> > >>None   2.44 +/- nan 48.698.7
> > >>Video  12.8 +/- nan 55.2  89
> > >>X  89.7 +/- nan  49452.8
> > >>Burn400 +/- nan 100420.1
> > >>Write  49.2 +/- nan  34367.2
> > >>Read   4.14 +/- nan 56.796.7
> > >>Compile 551 +/- nan 136915.4
> > >>
> > >>:(
> > >
> > > I keep trying
> >
> > The problem is a variation of the original one that I pointed out.  The
> > value that's being added to the sum of the squares of the latency is not
> > always the square of the value being added to the latency.
> >
> > Would you like me to fix it and send you a patch?
>
> I fixed that too in what is in front of me (sorry not the one I've released
> it was only clear to me when this report came back) and am still hitting
> some bug somewhere. I've yet to track it down.

Silly me. The gaming emulation doesn't use periodic_schedule so I wasn't 
storing the data anywhere for standard deviation. Will release a fixed 
version soon.

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: [ck] [ANNOUNCE] Interbench v0.26

[Con Kolivas]

On Thu, 4 Aug 2005 09:25 am, Peter Williams wrote:
> Con Kolivas wrote:
> > On Wed, 3 Aug 2005 22:01, Gabriel Devenyi wrote:
> >>You haven't quite completely fixed the SD calculations it seems:
> >>
> >>
> >>--- Benchmarking simulated cpu of Gaming in the presence of simulated---
> >>LoadLatency +/- SD (ms)  Max Latency   % Desired CPU
> >>None   2.44 +/- nan 48.698.7
> >>Video  12.8 +/- nan 55.2  89
> >>X  89.7 +/- nan  49452.8
> >>Burn400 +/- nan 100420.1
> >>Write  49.2 +/- nan  34367.2
> >>Read   4.14 +/- nan 56.796.7
> >>Compile 551 +/- nan 136915.4
> >>
> >>:(
> >
> > I keep trying
>
> The problem is a variation of the original one that I pointed out.  The
> value that's being added to the sum of the squares of the latency is not
> always the square of the value being added to the latency.
>
> Would you like me to fix it and send you a patch?

I fixed that too in what is in front of me (sorry not the one I've released it 
was only clear to me when this report came back) and am still hitting some 
bug somewhere. I've yet to track it down.

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: [ck] [ANNOUNCE] Interbench v0.26

[Peter Williams]

Con Kolivas wrote:

On Wed, 3 Aug 2005 22:01, Gabriel Devenyi wrote:


You haven't quite completely fixed the SD calculations it seems:


--- Benchmarking simulated cpu of Gaming in the presence of simulated---
LoadLatency +/- SD (ms)  Max Latency   % Desired CPU
None   2.44 +/- nan 48.698.7
Video  12.8 +/- nan 55.2  89
X  89.7 +/- nan  49452.8
Burn400 +/- nan 100420.1
Write  49.2 +/- nan  34367.2
Read   4.14 +/- nan 56.796.7
Compile 551 +/- nan 136915.4




:(



I keep trying


The problem is a variation of the original one that I pointed out.  The 
value that's being added to the sum of the squares of the latency is not 
always the square of the value being added to the latency.


Would you like me to fix it and send you a patch?

Peter
--
Peter Williams   [EMAIL PROTECTED]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
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 No-Idle-Hz aka Dynamic-Ticks 3

[Christian Leber]

On Wed, Aug 03, 2005 at 03:59:24PM +1000, Con Kolivas wrote:
> Patch for 2.6.13-rc5

Just a few numbers:

I tried it on a Laptop (Dell C810, P3m 1133 mhz) and measured the power
usage with an external device and it stayed with or without patch at
27W. (HZ was at about 28)

On a desktop with AthlonXP with STOP activated i got a power usage of
57W with and without patch (without STOP activated 94W).
(HZ was about at 50)


Christian Leber

-- 
  "Omnis enim res, quae dando non deficit, dum habetur et non datur,
   nondum habetur, quomodo habenda est."   (Aurelius Augustinus)
  Translation: 
-
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: Documentation - how to apply patches for various trees

[Jesper Juhl]

On Wednesday 03 August 2005 23:46, Bodo Eggert wrote:
> On Wed, 3 Aug 2005, Jesper Juhl wrote:
> 
> > +What is a patch?
> 
> > +To correctly apply a patch you need to know what base it was generated from
> > +and what new version the patch will change the source tree into. These
> > +should both be present in the patch file metadata.
> 
> This is usurally not true for kernel patches, the directories are mostly
> named a and b. You can however deduce the to-bepatched version and the
> patched version from the filename.
> 
hmm, I'd say the patch filename could be considered "metadata" as well.


> [...]
> 
> Or: bzcat patch1 patch2 patch3 | (cd linux-oldversion && patch -p1)
> 
yes, there are many ways, impossible to list them all, but this might be a
good example to add, just to show application of several patches in one go.

> 


I need to get some sleep now, but I'll add most of your text to the document
tomorrow and post a new patch.

Thanks!


-- 
Jesper

-
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 2.6.13-rc4] fix get_user_pages bug

[Nick Piggin]

Linus Torvalds wrote:


On Wed, 3 Aug 2005, Nick Piggin wrote:


Oh, it gets rid of the -1 for VM_FAULT_OOM. Doesn't seem like there
is a good reason for it, but might that break out of tree drivers?



Ok, I applied this because it was reasonably pretty and I liked the 
approach. It seems buggy, though, since it was using "switch ()" to test 
the bits (wrongly, afaik),


Oops, thanks.

and I'm going to apply the appended on top of 
it. Holler quickly if you disagreee..




No that looks fine. Should really be credited to Hugh... well
I guess everyone had some input into it though (Andrew, Hugh,
you, me). It probably doesn't matter too much.

Thanks everyone.

--
SUSE Labs, Novell Inc.

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/

[PATCH] IPMI driver update part 5, OEM flag handling and hacks for some Dell machines

[Corey Minyard]

ipmi-add-per-OEM-data-available-handlers.patch
Description: unknown/unknown

[GIT PATCH] ACPI patches for 2.6.13-rc5

[Len Brown]

Hi Linus,

Please pull from:

rsync://rsync.kernel.org/pub/scm/linux/kernel/git/lenb/to-linus.git

I reverted several things to 2.6.12 behaviour
which should result in a higher quality 2.6.13 release:

1. Fixed the PCI Interrupt Link revert you pulled from the list.
2. Put Embedded Controller back into polling mode by default.
3. Set CONFIG_ACPI_HOTKEY to 'n' by default (updated driver too).
4. Lovingly restored the rudely deleted /proc/acpi/button/:-)

thanks,
-Len

p.s.
Latest ACPI plain patch, including stuff waiting for 2.6.14 is available
here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.12/
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.12/broken-out/


 drivers/acpi/Kconfig  |5 
 drivers/acpi/button.c |  206 
 drivers/acpi/ec.c |   24 -
 drivers/acpi/hotkey.c |  690 +-
 drivers/acpi/pci_link.c   |   11 
 drivers/acpi/processor_idle.c |7 
 6 files changed, 634 insertions(+), 309 deletions(-)


commit 79cda7d0e1c8629996242c036d6fe0466038d8ba
Author: Luming Yu <[EMAIL PROTECTED]>
Date:   Wed Aug 3 18:07:59 2005 -0400

[ACPI] CONFIG_ACPI_HOTKEY is now "n" by default
For 2.6.12 behaviour, this (EXPERIMENTAL) driver
should not be built.

Update the driver source with latest from Luming.

Signed-off-by: Luming Yu <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>

commit b34a8030eeab4d59dcdd86de38f6927b9edd441f
Author: Alexey Starikovskiy <[EMAIL PROTECTED]>
Date:   Wed Aug 3 17:55:21 2005 -0400

[ACPI] restore /proc/acpi/button/ (ala 2.6.12)

Signed-off-by Alexey Starikovskiy <[EMAIL PROTECTED]>
Signed-off-by Len Brown <[EMAIL PROTECTED]>

commit 7b15f5e7bb180ac7bfb8926dbbd8835fecc07fad
Author: Luming Yu <[EMAIL PROTECTED]>
Date:   Wed Aug 3 17:38:04 2005 -0400

[ACPI] revert Embedded Controller to polling-mode by default (ala
2.6.12)
Burst mode isn't ready for prime time,
but can be enabled for test via "ec_burst=1"

Signed-off-by: Luming Yu <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>

commit ecc21ebe603af31f172c43b8b261df79040790ef
Author: David Shaohua Li <[EMAIL PROTECTED]>
Date:   Wed Aug 3 11:00:11 2005 -0400

[ACPI] PCI interrupt link suspend/resume - revert to 2.6.12
behaviour

This patch disables the PCI Interrupt Link refernece counts,
which should not co-exist with the 2.6.12 irq_router.resume
method or else a double acpi_pci_link_set() could result
on resume.

Signed-off-by: David Shaohua Li <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>

commit 3d35600a9de8e2816d0e3726f64b7271af6fdda4
Author: Len Brown <[EMAIL PROTECTED]>
Date:   Wed Aug 3 00:22:52 2005 -0400

[ACPI] fix 64-bit build warning in processor_idle.c

Signed-off-by: Len Brown <[EMAIL PROTECTED]>



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] IPMI driver update part 6, clean up versioning of the IPMI driver

[Corey Minyard]

ipmi-add-module-info-tags.patch
Description: unknown/unknown

[PATCH] IPMI driver update part 2, high-res timer support fixes

[Corey Minyard]

ipmi_hrt_fixes.diff
Description: unknown/unknown

Re: [PATCH] updated - Automatically enable bigsmp when we have more than 8 CPUs

[Venkatesh Pallipadi]

Below is the updated patch.

Changes from previous version:
* Make sure there are no side-effects on other i386 subarchs.
* Make sure nothing in this patch affects x86_64
* Add additional check for Intel CPUs before switching to bigsmp mode
* Add a warning message if more than 8 CPUs are found with X86_PC subarch

Thanks,
Venki

i386 generic subarchitecture requires explicit dmi strings or command line
to enable bigsmp mode. The patch below removes that restriction, and
uses bigsmp as soon as it finds more than 8 logical CPUs, Intel processors 
and xAPIC support.

Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>

diff -purN linux-2.6.13-rc3/arch/i386/kernel/acpi/boot.c 
linux-2.6.13-rc3-auto/arch/i386/kernel/acpi/boot.c
--- linux-2.6.13-rc3/arch/i386/kernel/acpi/boot.c   2005-07-29 
00:58:06.0 -0700
+++ linux-2.6.13-rc3-auto/arch/i386/kernel/acpi/boot.c  2005-08-03 
10:13:02.0 -0700
@@ -833,6 +833,9 @@ acpi_process_madt(void)
if (!error) {
acpi_lapic = 1;
 
+#ifdef CONFIG_X86_GENERICARCH
+   generic_bigsmp_probe();
+#endif   
/*
 * Parse MADT IO-APIC entries
 */
diff -purN linux-2.6.13-rc3/arch/i386/kernel/mpparse.c 
linux-2.6.13-rc3-auto/arch/i386/kernel/mpparse.c
--- linux-2.6.13-rc3/arch/i386/kernel/mpparse.c 2005-07-29 00:58:06.0 
-0700
+++ linux-2.6.13-rc3-auto/arch/i386/kernel/mpparse.c2005-08-03 
14:12:34.156775936 -0700
@@ -65,6 +65,8 @@ int nr_ioapics;
 int pic_mode;
 unsigned long mp_lapic_addr;
 
+unsigned int def_to_bigsmp = 0;
+
 /* Processor that is doing the boot up */
 unsigned int boot_cpu_physical_apicid = -1U;
 /* Internal processor count */
@@ -213,6 +215,13 @@ static void __init MP_processor_info (st
ver = 0x10;
}
apic_version[m->mpc_apicid] = ver;
+   if ((num_processors > 8) && 
+   APIC_XAPIC(ver) && 
+   (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL))
+   def_to_bigsmp = 1;
+   else
+   def_to_bigsmp = 0;
+
bios_cpu_apicid[num_processors - 1] = m->mpc_apicid;
 }
 
diff -purN linux-2.6.13-rc3/arch/i386/kernel/setup.c 
linux-2.6.13-rc3-auto/arch/i386/kernel/setup.c
--- linux-2.6.13-rc3/arch/i386/kernel/setup.c   2005-07-29 00:58:06.0 
-0700
+++ linux-2.6.13-rc3-auto/arch/i386/kernel/setup.c  2005-08-03 
14:33:34.450182216 -0700
@@ -1593,8 +1594,13 @@ void __init setup_arch(char **cmdline_p)
 */
acpi_boot_table_init();
acpi_boot_init();
-#endif
 
+#ifdef CONFIG_X86_PC
+   if (def_to_bigsmp) {
+   printk(KERN_WARNING "More than 8 CPUs detected and 
CONFIG_X86_PC cannot handle it. Use CONFIG_X86_GENERICARCH or 
CONFIG_X86_BIGSMP.\n");
+   }
+#endif
+#endif
 #ifdef CONFIG_X86_LOCAL_APIC
if (smp_found_config)
get_smp_config();
diff -purN linux-2.6.13-rc3/arch/i386/mach-generic/bigsmp.c 
linux-2.6.13-rc3-auto/arch/i386/mach-generic/bigsmp.c
--- linux-2.6.13-rc3/arch/i386/mach-generic/bigsmp.c2005-07-29 
00:58:06.0 -0700
+++ linux-2.6.13-rc3-auto/arch/i386/mach-generic/bigsmp.c   2005-08-03 
09:54:58.0 -0700
@@ -47,7 +47,10 @@ static struct dmi_system_id __initdata b
 
 static __init int probe_bigsmp(void)
 { 
-   dmi_check_system(bigsmp_dmi_table);
+   if (def_to_bigsmp)
+   dmi_bigsmp = 1;
+   else
+   dmi_check_system(bigsmp_dmi_table);
return dmi_bigsmp; 
 } 
 
diff -purN linux-2.6.13-rc3/arch/i386/mach-generic/probe.c 
linux-2.6.13-rc3-auto/arch/i386/mach-generic/probe.c
--- linux-2.6.13-rc3/arch/i386/mach-generic/probe.c 2005-07-29 
00:58:06.0 -0700
+++ linux-2.6.13-rc3-auto/arch/i386/mach-generic/probe.c2005-08-03 
14:00:38.533567200 -0700
@@ -30,6 +30,25 @@ struct genapic *apic_probe[] __initdata 
NULL,
 };
 
+static int cmdline_apic;
+
+void __init generic_bigsmp_probe(void) 
+{
+   /*
+* This routine is used to switch to bigsmp mode when
+* - There is no apic= option specified by the user
+* - generic_apic_probe() has choosen apic_default as the sub_arch
+* - we find more than 8 CPUs in acpi LAPIC listing with xAPIC support
+*/
+  
+   if (!cmdline_apic && genapic == _default)
+   if (apic_bigsmp.probe()) {
+   genapic = _bigsmp;
+   printk(KERN_INFO "Overriding APIC driver with %s\n", 
+  genapic->name);
+   }
+}
+
 void __init generic_apic_probe(char *command_line) 
 { 
char *s;
@@ -52,6 +71,7 @@ void __init generic_apic_probe(char *com
if (!changed)
printk(KERN_ERR "Unknown genapic `%s' specified.\n", s);
*p = old;
+   cmdline_apic = changed;
} 
for (i = 0; !changed && apic_probe[i]; i++) { 
if 

Re: BTTV - experimental no_overlay patch

[Bodo Eggert]

Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:

> This small patch will allow no_overlay flag to disable BTTV driver to
> report OVERLAY capabilities. It should fix your troubles by enabling
> no_overlay=1 when inserting bttv module.
> 
> This patch is against our CVS tree, but should apply with some hunk on
> 2.6.13-rc4 or 2.6.13-rc5.
> 
> I'll generate a new one at morning, against 2.6.13-rc5 hopefully to
> have it applied at 2.6.13, since it fixes an OOPS.

The CVS line will off cause not apply, and I needed to change
s/static// int no_overlay in bttv-cards.c.

The picture is less distorted by pci activity with no_overlay=1, and it
feels like the stable interface I used with my nvidia+2.4+XF86 before
upgrading to 2.6+radeon+X.org. No OOPS within the first few minutes:).
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.
-
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 No-Idle-Hz aka Dynamic-Ticks 3

[Con Kolivas]

On Thu, 4 Aug 2005 08:22 am, Jim MacBaine wrote:
> On 8/3/05, Con Kolivas <[EMAIL PROTECTED]> wrote:
> > What happens when you disable it at runtime before suspending?
> >
> > echo 0 > /sys/devices/system/dyn_tick/dyn_tick0/enable
>
> This has no effect. The system stalls at exactly the same point. The
> last lines on my screen are:

Ok perhaps on the resume side instead. When trying to resume can you try 
booting with 'dyntick=disable'. Note this isn't meant to be a long term fix 
but once we figure out where the problem is we should be able to code around 
it.

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/

[PATCH] IPMI driver update part 4, allow userland to include ipmi.h

[Corey Minyard]

ipmi_compiler_h_include.patch
Description: unknown/unknown

[PATCH] IPMI driver update part 3, watchdog/NMI interaction fixes

[Corey Minyard]

ipmi_wdog_nmi_fixes.patch
Description: unknown/unknown

[PATCH] IPMI driver update part 1, add per-channel IPMB addresses

[Corey Minyard]

ipmi-per-channel-slave-address.patch
Description: unknown/unknown

[PATCH 2.6.13-rc4-mm1] Re: Obsolete files in 2.6 tree

[Jiri Slaby]

Alan Cox napsal(a):


drivers/char/drm/gamma_dma.c
drivers/char/drm/gamma_drv.c
 



Gamma is defunct certainly
 


Removes gamma sources, headers and pointers from Kconfig and Makefile.

Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>

patch is here (about 70 KiB):
http://www.fi.muni.cz/~xslaby/lnx/gamma.txt

--
Jiri Slaby www.fi.muni.cz/~xslaby
~\-/~  [EMAIL PROTECTED]  ~\-/~
241B347EC88228DE51EE A49C4A73A25004CB2A10

-
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: Obsolete files in 2.6 tree

[Jiri Slaby]

Jiri Slaby napsal(a):


fs/befs/attribute.c


And what about entire befs? Is it used?
Last change was made on 2002 and many features are still missing.

--
Jiri Slaby www.fi.muni.cz/~xslaby
~\-/~  [EMAIL PROTECTED]  ~\-/~
241B347EC88228DE51EE A49C4A73A25004CB2A10

-
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 No-Idle-Hz aka Dynamic-Ticks 3

[Jim MacBaine]

On 8/3/05, Con Kolivas <[EMAIL PROTECTED]> wrote:

> What happens when you disable it at runtime before suspending?
> 
> echo 0 > /sys/devices/system/dyn_tick/dyn_tick0/enable

This has no effect. The system stalls at exactly the same point. The
last lines on my screen are:

...
Software Suspend Core.
Software Suspend Compression Driver loading.
Software Suspend Encryption Driver loading.
Software Suspend Swap Writer loading.
Software Suspend FileWriter loading.
dyn-tick: Maximum ticks to skip limited to 13
dyn-tick: Timer using dynamic tick
ACPI wakeup devices:
SBTN USB0 USB1 EHCI AC97 MC97 LAN0 FSD0
ACPI: (supports S0 S3 S4 S5)
Software Suspend 2.1.9.11: Swapwriter: Signature found.
Software Suspend 2.1.9.11: Suspending enabled.

Regards,
Jim
-
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] Add Documentation/kprobes.txt

[Jim Keniston]

On Wed, 2005-08-03 at 03:41, Suparna Bhattacharya wrote:
> On Tue, Aug 02, 2005 at 03:20:06PM -0700, Jim Keniston wrote:
> > The enclosed patch creates Documentation/kprobes.txt, a guide to using
> > the existing Kprobes facility for dynamic kernel instrumentation.
> > Please apply.
...
> > +Here's how it works.  When the probe is hit, Kprobes makes a copy of
> > +the saved registers and a generous portion of the stack (see below).
> > +Kprobes then points the saved stack pointer at the stack-copy, points
> > +the saved instruction pointer at the jprobe's handler routine, and
> > +returns from the trap.  As a result, control passes to the handler,
> > +which is presented with the same register and stack contents as the
> > +probed function.  When it is done, the handler calls jprobe_return(),
> > +which traps again to restore processor state and switch back to the
> > +probed function.
> > +
> > +gcc assumes that the callee owns its arguments.  To prevent unexpected
> > +modifications to the probed function's stack, Kprobes presents the
> > +jprobe handler with a copy of the stack.  Up to MAX_STACK_SIZE bytes
> > +are copied -- e.g., 64 bytes on i386.
> 
> IIRC, we save and restore the stack, rather than pass a copy of the stack
> to the handler. Thus, while jprobes does make a copy of MAX_STACK_SIZE
> bytes, the handler still operates on the original stack (e.g. stack
> addresses are unchanged) and the stack contents are restored
> before returning control to the probed routine.
...

You're right.  Thanks.  I've modified those two paragraphs to read as
follows:
-
Here's how it works.  When the probe is hit, Kprobes makes a copy of
the saved registers and a generous portion of the stack (see below).
Kprobes then points the saved instruction pointer at the jprobe's
handler routine, and returns from the trap.  As a result, control
passes to the handler, which is presented with the same register and
stack contents as the probed function.  When it is done, the handler
calls jprobe_return(), which traps again to restore the original stack
contents and processor state and switch to the probed function.

By convention, the callee owns its arguments, so gcc may produce code
that unexpectedly modifies that portion of the stack.  This is why
Kprobes saves a copy of the stack and restores it after the jprobe
handler has run.  Up to MAX_STACK_SIZE bytes are copied -- e.g.,
64 bytes on i386.
-
Enclosed is the updated patch.  Please apply.

Jim Keniston

Acked-by: Prasanna S Panchamukhi <[EMAIL PROTECTED]>
Signed-off-by: Jim Keniston <[EMAIL PROTECTED]>
--- linux.old/Documentation/kprobes.txt 1969-12-31 16:00:00.0 -0800
+++ linux.new/Documentation/kprobes.txt 2005-08-03 14:47:02.0 -0700
@@ -0,0 +1,588 @@
+Title  : Kernel Probes (Kprobes)
+Authors: Jim Keniston <[EMAIL PROTECTED]>
+   : Prasanna S Panchamukhi <[EMAIL PROTECTED]>
+
+CONTENTS
+
+1. Concepts: Kprobes, Jprobes, Return Probes
+2. Architectures Supported
+3. Configuring Kprobes
+4. API Reference
+5. Kprobes Features and Limitations
+6. Probe Overhead
+7. TODO
+8. Kprobes Example
+9. Jprobes Example
+10. Kretprobes Example
+
+1. Concepts: Kprobes, Jprobes, Return Probes
+
+Kprobes enables you to dynamically break into any kernel routine and
+collect debugging and performance information non-disruptively. You
+can trap at almost any kernel code address, specifying a handler
+routine to be invoked when the breakpoint is hit.
+
+There are currently three types of probes: kprobes, jprobes, and
+kretprobes (also called return probes).  A kprobe can be inserted
+on virtually any instruction in the kernel.  A jprobe is inserted at
+the entry to a kernel function, and provides convenient access to the
+function's arguments.  A return probe fires when a specified function
+returns.
+
+In the typical case, Kprobes-based instrumentation is packaged as
+a kernel module.  The module's init function installs ("registers")
+one or more probes, and the exit function unregisters them.  A
+registration function such as register_kprobe() specifies where
+the probe is to be inserted and what handler is to be called when
+the probe is hit.
+
+The next three subsections explain how the different types of
+probes work.  They explain certain things that you'll need to
+know in order to make the best use of Kprobes -- e.g., the
+difference between a pre_handler and a post_handler, and how
+to use the maxactive and nmissed fields of a kretprobe.  But
+if you're in a hurry to start using Kprobes, you can skip ahead
+to section 2.
+
+1.1 How Does a Kprobe Work?
+
+When a kprobe is registered, Kprobes makes a copy of the probed
+instruction and replaces the first byte(s) of the probed instruction
+with a breakpoint instruction (e.g., int3 on i386 and x86_64).
+
+When a CPU hits the breakpoint instruction, a trap occurs, the CPU's
+registers are saved, and control passes to Kprobes via the
+notifier_call_chain mechanism.  Kprobes executes the 

[PATCH 2/2] Convert /proc/sysvipc/* to generic seq_file interface

[Mike Waychison]

This patch changes the /proc/sysvipc/shm|sem|msg files to use the generic 
seq_file implementation for struct ipc_ids.

Signed-off-by: Mike Waychison <[EMAIL PROTECTED]>

 include/linux/msg.h |1 
 include/linux/sem.h |1 
 ipc/msg.c   |   80 +++-
 ipc/sem.c   |   71 +-
 ipc/shm.c   |   86 
 5 files changed, 78 insertions(+), 161 deletions(-)

Index: linux-2.6.12.3/ipc/shm.c
===
--- linux-2.6.12.3.orig/ipc/shm.c   2005-08-03 14:31:28.0 -0700
+++ linux-2.6.12.3/ipc/shm.c2005-08-03 14:35:29.0 -0700
@@ -23,12 +23,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -51,7 +51,7 @@ static int newseg (key_t key, int shmflg
 static void shm_open (struct vm_area_struct *shmd);
 static void shm_close (struct vm_area_struct *shmd);
 #ifdef CONFIG_PROC_FS
-static int sysvipc_shm_read_proc(char *buffer, char **start, off_t offset, int 
length, int *eof, void *data);
+static int sysvipc_shm_proc_show(struct seq_file *s, void *it);
 #endif
 
 size_t shm_ctlmax = SHMMAX;
@@ -63,9 +63,10 @@ static int shm_tot; /* total number of s
 void __init shm_init (void)
 {
ipc_init_ids(_ids, 1);
-#ifdef CONFIG_PROC_FS
-   create_proc_read_entry("sysvipc/shm", 0, NULL, sysvipc_shm_read_proc, 
NULL);
-#endif
+   ipc_init_proc_interface("sysvipc/shm",
+   "   key  shmid perms   size  cpid  
lpid nattch   uid   gid  cuid  cgid  atime  dtime  ctime\n",
+   _ids,
+   sysvipc_shm_proc_show);
 }
 
 static inline int shm_checkid(struct shmid_kernel *s, int id)
@@ -869,63 +870,32 @@ asmlinkage long sys_shmdt(char __user *s
 }
 
 #ifdef CONFIG_PROC_FS
-static int sysvipc_shm_read_proc(char *buffer, char **start, off_t offset, int 
length, int *eof, void *data)
+static int sysvipc_shm_proc_show(struct seq_file *s, void *it)
 {
-   off_t pos = 0;
-   off_t begin = 0;
-   int i, len = 0;
-
-   down(_ids.sem);
-   len += sprintf(buffer, "   key  shmid perms   size  cpid  
lpid nattch   uid   gid  cuid  cgid  atime  dtime  ctime\n");
+   struct shmid_kernel *shp = it;
+   char *format;
 
-   for(i = 0; i <= shm_ids.max_id; i++) {
-   struct shmid_kernel* shp;
-
-   shp = shm_lock(i);
-   if(shp!=NULL) {
 #define SMALL_STRING "%10d %10d  %4o %10u %5u %5u  %5d %5u %5u %5u %5u %10lu 
%10lu %10lu\n"
 #define BIG_STRING   "%10d %10d  %4o %21u %5u %5u  %5d %5u %5u %5u %5u %10lu 
%10lu %10lu\n"
-   char *format;
 
-   if (sizeof(size_t) <= sizeof(int))
-   format = SMALL_STRING;
-   else
-   format = BIG_STRING;
-   len += sprintf(buffer + len, format,
-   shp->shm_perm.key,
-   shm_buildid(i, shp->shm_perm.seq),
-   shp->shm_flags,
-   shp->shm_segsz,
-   shp->shm_cprid,
-   shp->shm_lprid,
-   is_file_hugepages(shp->shm_file) ? 
(file_count(shp->shm_file) - 1) : shp->shm_nattch,
-   shp->shm_perm.uid,
-   shp->shm_perm.gid,
-   shp->shm_perm.cuid,
-   shp->shm_perm.cgid,
-   shp->shm_atim,
-   shp->shm_dtim,
-   shp->shm_ctim);
-   shm_unlock(shp);
-
-   pos += len;
-   if(pos < offset) {
-   len = 0;
-   begin = pos;
-   }
-   if(pos > offset + length)
-   goto done;
-   }
-   }
-   *eof = 1;
-done:
-   up(_ids.sem);
-   *start = buffer + (offset - begin);
-   len -= (offset - begin);
-   if(len > length)
-   len = length;
-   if(len < 0)
-   len = 0;
-   return len;
+   if (sizeof(size_t) <= sizeof(int))
+   format = SMALL_STRING;
+   else
+   format = BIG_STRING;
+   return seq_printf(s, format,
+ shp->shm_perm.key,
+ shp->id,
+ shp->shm_flags,
+ shp->shm_segsz,
+ shp->shm_cprid,
+ shp->shm_lprid,
+ is_file_hugepages(shp->shm_file) ? 

[PATCH 1/2] Add generic struct ipc_ids seq_file iteration

[Mike Waychison]

Add a generic method for ipc types to be displayed using seq_file.  This patch
abstracts out seq_file iterating over struct ipc_ids into ipc/util.c

Signed-off-by: Mike Waychison <[EMAIL PROTECTED]>

 util.c |  156 +
 util.h |8 +++
 2 files changed, 164 insertions(+)

Index: linux-2.6.12.3/ipc/util.h
===
--- linux-2.6.12.3.orig/ipc/util.h  2005-08-03 14:31:28.0 -0700
+++ linux-2.6.12.3/ipc/util.h   2005-08-03 14:35:19.0 -0700
@@ -30,7 +30,15 @@ struct ipc_ids {
struct ipc_id_ary* entries;
 };
 
+struct seq_file;
 void __init ipc_init_ids(struct ipc_ids* ids, int size);
+#ifdef CONFIG_PROC_FS
+void __init ipc_init_proc_interface(const char *path, const char *header,
+   struct ipc_ids *ids,
+   int (*show)(struct seq_file *, void *));
+#else
+#define ipc_init_proc_interface(path, header, ids, show) do {} while (0)
+#endif
 
 /* must be called with ids->sem acquired.*/
 int ipc_findkey(struct ipc_ids* ids, key_t key);
Index: linux-2.6.12.3/ipc/util.c
===
--- linux-2.6.12.3.orig/ipc/util.c  2005-08-03 14:31:28.0 -0700
+++ linux-2.6.12.3/ipc/util.c   2005-08-03 14:35:19.0 -0700
@@ -24,11 +24,20 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
 #include "util.h"
 
+struct ipc_proc_iface {
+   const char *path;
+   const char *header;
+   struct ipc_ids *ids;
+   int (*show)(struct seq_file *, void *);
+};
+
 /**
  * ipc_init-   initialise IPC subsystem
  *
@@ -86,6 +95,43 @@ void __init ipc_init_ids(struct ipc_ids*
ids->entries->p[i] = NULL;
 }
 
+#ifdef CONFIG_PROC_FS
+static struct file_operations sysvipc_proc_fops;
+/**
+ * ipc_init_proc_interface -  Create a proc interface for sysipc types
+ *using a seq_file interface.
+ * @path: Path in procfs
+ * @header: Banner to be printed at the beginning of the file.
+ * @ids: ipc id table to iterate.
+ * @show: show routine.
+ */
+void __init ipc_init_proc_interface(const char *path, const char *header,
+   struct ipc_ids *ids,
+   int (*show)(struct seq_file *, void *))
+{
+   struct proc_dir_entry *pde;
+   struct ipc_proc_iface *iface;
+
+   iface = kmalloc(sizeof(*iface), GFP_KERNEL);
+   if (!iface)
+   return;
+   iface->path = path;
+   iface->header   = header;
+   iface->ids  = ids;
+   iface->show = show;
+
+   pde = create_proc_entry(path,
+   S_IRUGO,/* world readable */
+   NULL/* parent dir */);
+   if (pde) {
+   pde->data = iface;
+   pde->proc_fops = _proc_fops;
+   } else {
+   kfree(iface);
+   }
+}
+#endif
+
 /**
  * ipc_findkey -   find a key in an ipc identifier set 
  * @ids: Identifier set
@@ -578,3 +624,113 @@ int ipc_parse_version (int *cmd)
 }
 
 #endif /* __ARCH_WANT_IPC_PARSE_VERSION */
+
+#ifdef CONFIG_PROC_FS
+static void *sysvipc_proc_next(struct seq_file *s, void *it, loff_t *pos)
+{
+   struct ipc_proc_iface *iface = s->private;
+   struct kern_ipc_perm *ipc = it;
+   loff_t p;
+
+   /* If we had an ipc id locked before, unlock it */
+   if (ipc && ipc != SEQ_START_TOKEN)
+   ipc_unlock(ipc);
+
+   /*
+* p = *pos - 1 (because id 0 starts at position 1)
+*  + 1 (because we increment the position by one)
+*/
+   for (p = *pos; p <= iface->ids->max_id; p++) {
+   if ((ipc = ipc_lock(iface->ids, p)) != NULL) {
+   *pos = p + 1;
+   return ipc;
+   }
+   }
+
+   /* Out of range - return NULL to terminate iteration */
+   return NULL;
+}
+
+/*
+ * File positions: pos 0 -> header, pos n -> ipc id + 1.
+ * SeqFile iterator: iterator value locked shp or SEQ_TOKEN_START.
+ */
+static void *sysvipc_proc_start(struct seq_file *s, loff_t *pos)
+{
+   struct ipc_proc_iface *iface = s->private;
+   struct kern_ipc_perm *ipc;
+   loff_t p;
+
+   /*
+* Take the lock - this will be released by the corresponding
+* call to stop().
+*/
+   down(>ids->sem);
+
+   /* pos < 0 is invalid */
+   if (*pos < 0)
+   return NULL;
+
+   /* pos == 0 means header */
+   if (*pos == 0)
+   return SEQ_START_TOKEN;
+
+   /* Find the (pos-1)th ipc */
+   for (p = *pos - 1; p <= iface->ids->max_id; p++) {
+   if ((ipc = ipc_lock(iface->ids, p)) != NULL) {
+   *pos = p + 1;
+   return ipc;
+ 

[PATCH 0/2] Conversion of /proc/sysvipc/* to seq_file

[Mike Waychison]

The following two patches convert /proc/sysvipc/* to use seq_file.

This gives us the following:

 - Self-consistent IPC records in proc.
 - O(n) reading of the files themselves.

Please consider applying.  Thanks,

Mike Waychison
-
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: Testing RC kernels [KORG]

[Andrew James Wade]

On August 2, 2005 11:30 pm, Gene Heskett wrote:
> And my point is that anyone with the skills to build a kernel 
> shouldn't have any problems at all find it with gftp.

I updated my kernel more frequently after learning of ketchup.
(). The bother of getting the
patch sequence right and applying it was enough to discourage me.
No, it's not particularly difficult, but it may well be enough
to discourage casual testers. 

Posting a link to ketchup on kernel.org may also decrease the
bandwidth demand, as it seems to be pretty intelligent about
using patches.
-
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: **SPAM** [PATCH 3/3] usb gadget driver for MQ11xx graphics chip

[Nick Sillik]

Michael Krufky wrote:


[EMAIL PROTECTED] wrote:

The email subject. "Re: **SPAM** [PATCH 3/3] usb gadget driver for 
MQ11xx graphics chip" ... Was that an accident, or did my email server 
take over my headers?  (i'm not running any spam filering software or 
anything)


If this happened on your end, you might want to re-send that one... 
Some email clients automatically filter messages containing "**SPAM**" 
in subject line.


Nope, isn't on your end. I'm seeing them too. I thought my mailserver 
had gone off its rocker. I'm glad to know that others are seeing this.


Nick Sillik
[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: Documentation - how to apply patches for various trees

[Bodo Eggert]

On Wed, 3 Aug 2005, Jesper Juhl wrote:

> +What is a patch?

> +To correctly apply a patch you need to know what base it was generated from
> +and what new version the patch will change the source tree into. These
> +should both be present in the patch file metadata.

This is usurally not true for kernel patches, the directories are mostly
named a and b. You can however deduce the to-bepatched version and the
patched version from the filename.

> +How do I apply a patch?
> +---
> + You apply a patch with the `patch' program. The patch program reads a diff
> +(or patch) file and makes the changes to the source tree described in it.
> +Patches for the Linux kernel are generated relative to the parent directory
> +holding the kernel source dir. This means that paths to files inside the
> +patch file contain the name of the kernel source directories it was
> +generated against - since this is unlikely to match the name of the kernel
> +source dir on your local machine (but is often useful info to see what
> +version an otherwise unlabeled patch was generated against)

Same issue.

> you should
> +change into your kernel source directory and then strip the first element of
> +the path from filenames in the patch file when applying it (the -p1 argument
> +to `patch' does this). To revert a previously applied patch, use the -R
> +argument to patch.

> +How do I feed a patch/diff file to `patch'?
[...]

Or: bzcat patch1 patch2 patch3 | (cd linux-oldversion && patch -p1)


Finding out if a patch applied correctly
---
A quick check is to search for .rej files. Unfortunately some errors 


How do I undo a patch?
---
You can undo a patch by supplying the -R switch to patch. If you patched 
using zcat ../patch.gz | patch -p1, zcat ../patch.gz | patch -Rp1 will 
undo the changes as long as the patch applied correctly.


Common errors while patching
---
"File to patch:"

  Patch could not find a file to be patched. Most probably you forgot to
  use -p1 or you're in the wrong directory. Less often, you'll find
  patches that need to be applied with -p0 instead (you can't just omit
  -p0!).^^^
  ^ [IIRC]

  Sometimes this is the result of an incomplete tarball, a out-of-space 
  error while unpacking or a fsck.

"Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines)."

  The patch was applied, but it might be applied to the wrong place
  because you patched the "wrong" source. The result might not work
  correctly.

"Hunk #3 FAILED at 2387."

  The patch could not be applied correctly. This is usurally fatal, except 
  if you apply external patches to the stable series (e.g. to 2.6.23.42
  instead of 2.6.23) and the reject is in the toplevel Makefile.
  (You'll have to manually edit the Makefile and change the version string 
   as recorded in Makefile.rej)

  If you apply more than one external patch, the same thing will happen, 
  but there is no guarantee for a working kernel (the changes may bite 
  each other).

  You can most likely recover the source tree by undoing the patch and 
  removing the .rej and .orig files. YMMV.

"Reversed (or previously applied) patch detected!  Assume -R? [n]"

  Either you really applied the patch before, or the patch is for some
  other source. If this is not the very first message, the source is
  most likely unusable by now.

"patch:  unexpected end of file in patch"
  Your download is broken. Re-get the file.

-- 
To steal information from a person is called plagiarism. To steal
information from the enemy is called gathering intelligence.
-
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: [ACPI] Re: [PATCH] PNPACPI: fix types when decoding ACPI resources [resend]

[Bjorn Helgaas]

On Wednesday 03 August 2005 3:16 pm, matthieu castet wrote:
> Bjorn Helgaas wrote:
>  > On Tuesday 02 August 2005 7:01 pm, Shaohua Li wrote:
>  >>Did you have plan to remove other
>  >>legacy acpi drivers?
>  > No, I didn't -- which ones are you thinking about?  Looking at
>  > the callers of acpi_bus_register_driver(), I see:
> looking for METHOD_NAME__CRS is more acurate.

I didn't see any new ones when I looked for METHOD_NAME__CRS.

>  >drivers/char/hpet.c
>  >This probably should be converted to PNP.  I'll
>  >look into doing this.
> IIRC, I am not sure that the pnp layer was able to pass the 64 bits 
> memory adress for hpet correctly. But it would be nice if it works.

You're right, this was broken.  But I've been pushing a PNPACPI
patch to fix this.

> There was an extention of a floppy driver in order to use acpi in -mm, 
> but it seems to have been dropped.

Yeah, I did that, and it was a huge mistake.  The point was to avoid
blind probing for the device, but my concern was for ia64, and no ia64
boxes have floppy, so it's much easier to just not build the driver.

> PS : I saw in acpi ols paper that you plan once all dupe acpi drivers 
> will be removed to register again the pnp device in acpi layer. Do you 
> plan to add more check and for example add only device that have a CRS 
> in pnp layer ?

If you mean the last paragraph of section 6, I don't really understand
it.  But it mentions 8250_acpi.c as an obstacle, and I do know that we
are very close to being able to remove that.  I've already posted two
patches (one to PNPACPI to fix the 64-bit address problem, and one to
8250_pnp to add support for MMIO UARTs).  Once those are accepted, we
should be able to remove 8250_acpi.c.  I think only ia64 really relies
on it anyway.

> PPS : is there any plan to integrate 
> http://marc.theaimsgroup.com/?l=linux-kernel=111827568001255=2

I'm afraid I don't know anything about this one.
-
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: Documentation - how to apply patches for various trees

[Jesper Juhl]

On Wednesday 03 August 2005 23:08, Linus Torvalds wrote:
> 
> On Wed, 3 Aug 2005, Jesper Juhl wrote:
> >
> > Here's an updated version of my document that attempts to give a short 
> > explanation of the various kernel trees and how to apply their patches.
> > It incorporates all the feedback I've gotten (thanks guys). 
> 
> Can we have more whitespace?
> 
Certainly.



> And since we have a single empty line implying paragraph breaks, feel free 
> to use multiple empty lines to imply "bigger" breaks (you seem to do this 
> already).
> 

Here's an updated version with more whitespace.


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 Documentation/applying-patches.txt |  323 +
 1 files changed, 323 insertions(+)

diff -uP linux-2.6.13-rc5-orig/Documentation/applying-patches.txt 
linux-2.6.13-rc5/Documentation/applying-patches.txt
--- linux-2.6.13-rc5-orig/Documentation/applying-patches.txt1970-01-01 
01:00:00.0 +0100
+++ linux-2.6.13-rc5/Documentation/applying-patches.txt 2005-08-03 
23:23:24.0 +0200
@@ -0,0 +1,323 @@
+
+   Applying Patches To The Linux Kernel
+   
+
+   (Written by Jesper Juhl, August 2005)
+
+
+
+A frequently asked question on the Linux Kernel Mailing List is how to apply
+a patch to the kernel or, more specifically, what base kernel a patch for
+one of the many trees/branches should be applied to. Hopefully this document
+will explain this to you.
+
+
+What is a patch?
+---
+ A patch is a small text document containing a delta of changes between two
+different versions of a source tree. Patches are created with the `diff'
+program.
+To correctly apply a patch you need to know what base it was generated from
+and what new version the patch will change the source tree into. These
+should both be present in the patch file metadata.
+
+
+How do I apply a patch?
+---
+ You apply a patch with the `patch' program. The patch program reads a diff
+(or patch) file and makes the changes to the source tree described in it.
+
+Patches for the Linux kernel are generated relative to the parent directory
+holding the kernel source dir.
+
+This means that paths to files inside the patch file contain the name of the
+kernel source directories it was generated against.
+Since this is unlikely to match the name of the kernel source dir on your
+local machine (but is often useful info to see what version an otherwise
+unlabeled patch was generated against) you should change into your kernel
+source directory and then strip the first element of the path from filenames
+in the patch file when applying it (the -p1 argument to `patch' does this).
+To revert a previously applied patch, use the -R argument to patch.
+
+
+How do I feed a patch/diff file to `patch'?
+---
+ This (as usual with Linux and other UNIX like operating systems) can be
+done in several different ways.
+In all the examples below I feed the file (in uncompressed form) to patch
+via stdin using the following syntax:
+   patch -p1 < path/to/patch-x.y.z
+
+but patch can also get the name of the file to use via the -i argument, like
+this:
+   patch -p1 -i path/to/patch-x.y.z
+
+If your patch file is compressed with gzip or bzip2 and you don't want to
+uncompress it before applying it, then you can feed it to patch like this
+instead:
+   zcat path/to/patch-x.y.z.gz | patch -p1
+   bzcat path/to/patch-x.y.z.bz2 | patch -p1
+
+If you wish to uncompress the patch file by hand first before applying it
+(what I assume you've done in the examples below), then you simply run
+gunzip or bunzip2 on the file - like this:
+   gunzip patch-x.y.z.gz
+   bunzip2 patch-x.y.z.bz2
+
+Which will leave you with a plain text patch-x.y.z file that you can feed to
+patch via stdin or the -i argument, as you prefer.
+
+
+Are there any alternatives to `patch'?
+---
+ Yes there are alternatives. You can use the `interdiff' program
+(http://cyberelk.net/tim/patchutils/) to generate a patch representing the
+differences between two patches and then apply the result.
+This will let you move from something like 2.6.12.2 to 2.6.12.3 in a single
+step. The -z flag to interdiff will even let you feed it patches in gzip or
+bzip2 compressed form directly without the use of zcat or bzcat or manual
+uncompression.
+
+Here's how you'd go from 2.6.12.2 to 2.6.12.3 in a single step:
+   interdiff -z ../patch-2.6.12.2.bz2 ../patch-2.6.12.3.gz | patch -p1
+
+Although interdiff may save you a step or two you are generally adviced to
+do the additional steps since interdiff can get things wrong in some cases.
+
+ Another alternative is `ketchup', which is a python script for automatic
+downloading and applying of patches (http://www.selenic.com/ketchup/).
+
+
+Where can I download the patches?
+---
+The patches are available at http://kernel.org/
+Most recent patches are linked from the front page, but they also have
+specific homes.
+
+The 2.6.x.y 

Re: [ACPI] Re: [PATCH] PNPACPI: fix types when decoding ACPI resources [resend]

[matthieu castet]

Hi,

Bjorn Helgaas wrote:
> On Tuesday 02 August 2005 7:01 pm, Shaohua Li wrote:
>

>
>>Did you have plan to remove other
>>legacy acpi drivers?
>
>
> No, I didn't -- which ones are you thinking about?  Looking at
> the callers of acpi_bus_register_driver(), I see:
looking for METHOD_NAME__CRS is more acurate.
>
>arch/ia64/hp/common/sba_iommu.c
>Probably can't be converted because it needs the
>ACPI handle to extract a vendor-specific data
>item from _CRS.
>
>drivers/char/hpet.c
>This probably should be converted to PNP.  I'll
>look into doing this.
IIRC, I am not sure that the pnp layer was able to pass the 64 bits 
memory adress for hpet correctly. But it would be nice if it works.


There are drivers/acpi/motherboard.c that done some stuff already handle 
by pnp/system.c.


There was an extention of a floppy driver in order to use acpi in -mm, 
but it seems to have been dropped.


>
> Then of course, there are a bunch of things in drivers/acpi/
> (battery, button, fan, ec, etc).  I expect the reason they are
> in drivers/acpi/ is because they need ACPI-specific functionality,
> so they probably couldn't be converted to PNP.
yes.


Matthieu

PS : I saw in acpi ols paper that you plan once all dupe acpi drivers 
will be removed to register again the pnp device in acpi layer. Do you 
plan to add more check and for example add only device that have a CRS 
in pnp layer ?


PPS : is there any plan to integrate 
http://marc.theaimsgroup.com/?l=linux-kernel=111827568001255=2 that 
seem to fix some init problem ?

-
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 No-Idle-Hz aka Dynamic-Ticks 3

[Con Kolivas]

On Thu, 4 Aug 2005 05:20, Jim MacBaine wrote:
> On 8/3/05, Con Kolivas <[EMAIL PROTECTED]> wrote:
> > This is the dynamic ticks patch for i386 as written by Tony Lindgen
> > <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>.
> > Patch for 2.6.13-rc5
> >
> > There were a couple of things that I wanted to change so here is an
> > updated version. This code should have stabilised enough for general
> > testing now.
>
> Runs very well here on a (noname) laptop, even with apic timer, the
> desktop does not "feel" different from static 1000HZ. 

I did find performance dropped off substantially in interbench but usually 
below the human perceptible range. Real time performance dropped off 
substantially, but is back to mainline performance when disabled (ie config 
on but disabled at runtime/boottime).

> But dtck 
> reproducibly breaks software-suspend2; the kernel will simply stall on
> resume.  Also stalls with dyntick=noapic.  As soon as I set
> CONFIG_NO_IDLE_HZ = n, resume works again.

What happens when you disable it at runtime before suspending?

echo 0 > /sys/devices/system/dyn_tick/dyn_tick0/enable

Cheers,
Con


pgpDdy5QFDioV.pgp
Description: PGP signature

Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 3

[Con Kolivas]

On Thu, 4 Aug 2005 05:54, Jeffrey Hundstad wrote:
> Con Kolivas wrote:
> >This is the dynamic ticks patch for i386 as written by Tony Lindgen
> ><[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>.
> >Patch for 2.6.13-rc5
> >
> >There were a couple of things that I wanted to change so here is an
> > updated version. This code should have stabilised enough for general
> > testing now.
> >
> >The sysfs interface was moved to its own directory
> >in /sys/devices/system/dyn_tick and split into separate files to
> >enable/disable dynamic ticks and usage of apic on the fly. It makes sense
> > to enable dynamic ticks and usage of apic by default if they're actually
> > built into the kernel so that is now done.
>
> I am successfully running the dynamic tick patch on an old IBM ThinkPad
> A22m.  When I enable the APIC support console beeps, you know bash -c
> 'echo -e "\a"', takes a REALLY long time to finish.  I'm assuming this
> is a badly written program and not a kernel problem.  Correct?

I think the config option which recommends leaving apic support off and 
describes this behaviour should make it clearer. Indeed I found running with 
apic on produced weird results unlike running with PIT.

> BTW: how do you know what HZ your machine is running at?

vmstat 5 will show you the average interrupts per second over 5 seconds in the 
"in" column. The interrupts are obviously more than your Hz but often only a 
little more. 

The pmstats script by Tony will tell you more accurately:
http://www.muru.com/linux/dyntick/tools/pmstats-0.2.gz

Cheers,
Con


pgpXOCAbCEd1T.pgp
Description: PGP signature

buglet reading /proc/ide/(cdrom)/capacity

[Adrian Bridgett]

Just a minor buglet I've noticed /proc/ide/hdc/cdrom (where hdc is my
CDROM drive - Liteon 52x32x52).

If I cat this file while inserting the CDROM the command hangs, then
returns 304912 (fine).

If I insert a CDROM, then wait a while (say 30 seconds), then
it returns 304912 (also fine).

However if I insert a CDROM, then wait until the light stops flashing
(5 seconds) then I get: "0\n4912"  like this:

cat //proc/ide/hdc/capacity | od -c
000   0  \n   4   9   1   2  \n

I've checked with another CD and it is the first two characters being
overwritten.

PS: I'm not currently subscribed to the list, so please Cc me.  

Thanks,

Adrian
-- 
Email: [EMAIL PROTECTED]  -*-  GPG key available on public key servers
Debian GNU/Linux - the maintainable distribution   -*-  www.debian.org
Avoid working with children, animals and Microsoft "operating" systems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Documentation - how to apply patches for various trees

[Linus Torvalds]

On Wed, 3 Aug 2005, Jesper Juhl wrote:
>
> Here's an updated version of my document that attempts to give a short 
> explanation of the various kernel trees and how to apply their patches.
> It incorporates all the feedback I've gotten (thanks guys). 

Can we have more whitespace?

You either have very long paragraphs, or no whitespace between them: I 
can't quite decide which one.

So leave an empty line between paragraphs (and if you already do, you need 
to split them ;) because it's very tiring to not have a nice break every 
once in the flow of text. 

Long paragraphs may be acceptable in fictional literary work that you read
without thinking about what you're reading. There you get into the "flow"  
of the text, and you hopefully don't need to have very many visual breaks
to keep as acnhor-points. However, the same is certainly not true in
technical text, especially something like this where you're trying to
explain somethign that the recipient doesn't ncessarily know.

My rule of thumb is that if you don't have a new paragraph roughly every
five or six lines, it's likely problematic. Maybe I have a shorter
attention span than most, but I don't think so - I just find it much
easier to read text that is nicely broken up, and when it's a "pure ASCII"
medium the only break that works well is an empty line (possibly with
indentation for further visual help - although in this context indentation
tends to be used for a separate issue: examples etc, and is not good for
paragraphs).

And since we have a single empty line implying paragraph breaks, feel free 
to use multiple empty lines to imply "bigger" breaks (you seem to do this 
already).

This email was written with an average paragraph length of 4 lines.

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: [PATCH] optimize writer path in time_interpolator_get_counter()

[Christoph Lameter]

On Wed, 3 Aug 2005, Alex Williamson wrote:

>Ok, I can see the scenario where that could produce jitter.  However,
> that implies than any exit through that path could produce jitter as it
> is.  For instance:

Well what is the difference of this approach from booting with "nojitter"? 
The ITC offsets are fixed right?

Just check that the ITC difference is less than what you want to risk and 
switch on "nojitter" during bootup if less than the limit. Same effect 
without changes to the critical timer code patchs.

The main problem occurs as far as I know when execution continues on 
another processor during time measurement. In that case you may get an 
earlier time later because the ITC of the processor you migrated to is not 
there yet Similar issues may occur if time information is communicated 
between threads running on different processor.

You have an awful nest of rats here so if you do this then please at 
least do a printk that warns people of what is going on.

-
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: realtec 8169 driver for linux kernel 2.4.22 : latest version

[Francois Romieu]

schb Schönbauer Peter <[EMAIL PROTECTED]> :
[r8169 driver for 2.4.x]

Against 2.4.31:

http://www.zoreil.com/~romieu/r8169/20050803-2.4.31-r8169-test.patch

--
Ueimor
-
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.12.3] PCI/libata INTx cleanup

[Brett Russ]

Simple cleanup to eliminate X copies of the same function in libata.  
Moved pci_enable_intx() to pci.c, added pci_disable_intx() as well, 
and use them throughout libata and msi.c.

Signed-off-by: Brett Russ <[EMAIL PROTECTED]>

Index: linux-2.6.12.3-mv/drivers/pci/msi.c
===
--- linux-2.6.12.3-mv.orig/drivers/pci/msi.c
+++ linux-2.6.12.3-mv/drivers/pci/msi.c
@@ -456,10 +456,7 @@ static void enable_msi_mode(struct pci_d
}
if (pci_find_capability(dev, PCI_CAP_ID_EXP)) {
/* PCI Express Endpoint device detected */
-   u16 cmd;
-   pci_read_config_word(dev, PCI_COMMAND, );
-   cmd |= PCI_COMMAND_INTX_DISABLE;
-   pci_write_config_word(dev, PCI_COMMAND, cmd);
+   pci_disable_intx(dev);
}
 }
 
@@ -478,10 +475,7 @@ static void disable_msi_mode(struct pci_
}
if (pci_find_capability(dev, PCI_CAP_ID_EXP)) {
/* PCI Express Endpoint device detected */
-   u16 cmd;
-   pci_read_config_word(dev, PCI_COMMAND, );
-   cmd &= ~PCI_COMMAND_INTX_DISABLE;
-   pci_write_config_word(dev, PCI_COMMAND, cmd);
+   pci_enable_intx(dev);
}
 }
 
Index: linux-2.6.12.3-mv/drivers/pci/pci.c
===
--- linux-2.6.12.3-mv.orig/drivers/pci/pci.c
+++ linux-2.6.12.3-mv/drivers/pci/pci.c
@@ -733,6 +733,43 @@ pci_clear_mwi(struct pci_dev *dev)
}
 }
 
+
+/**
+ * pci_enable_intx - enables INTx generation in PCI cfg space cmd register
+ * @dev: the PCI device to enable
+ *
+ * Enables PCI INTx generation for device
+ */
+void 
+pci_enable_intx(struct pci_dev *pdev)
+{
+u16 pci_command;
+
+pci_read_config_word(pdev, PCI_COMMAND, _command);
+if (pci_command & PCI_COMMAND_INTX_DISABLE) {
+pci_command &= ~PCI_COMMAND_INTX_DISABLE;
+pci_write_config_word(pdev, PCI_COMMAND, pci_command);
+}
+}
+
+/**
+ * pci_disable_intx - disables INTx generation in PCI cfg space cmd register
+ * @dev: the PCI device to disable
+ *
+ * Disables PCI INTx generation for device
+ */
+void 
+pci_disable_intx(struct pci_dev *pdev)
+{
+u16 pci_command;
+
+pci_read_config_word(pdev, PCI_COMMAND, _command);
+if (!(pci_command & PCI_COMMAND_INTX_DISABLE)) {
+pci_command |= PCI_COMMAND_INTX_DISABLE;
+pci_write_config_word(pdev, PCI_COMMAND, pci_command);
+}
+}
+
 #ifndef HAVE_ARCH_PCI_SET_DMA_MASK
 /*
  * These can be overridden by arch-specific implementations
@@ -809,6 +846,8 @@ EXPORT_SYMBOL(pci_request_region);
 EXPORT_SYMBOL(pci_set_master);
 EXPORT_SYMBOL(pci_set_mwi);
 EXPORT_SYMBOL(pci_clear_mwi);
+EXPORT_SYMBOL(pci_enable_intx);
+EXPORT_SYMBOL(pci_disable_intx);
 EXPORT_SYMBOL(pci_set_dma_mask);
 EXPORT_SYMBOL(pci_set_consistent_dma_mask);
 EXPORT_SYMBOL(pci_assign_resource);
Index: linux-2.6.12.3-mv/drivers/scsi/sata_sis.c
===
--- linux-2.6.12.3-mv.orig/drivers/scsi/sata_sis.c
+++ linux-2.6.12.3-mv/drivers/scsi/sata_sis.c
@@ -186,18 +186,6 @@ static void sis_scr_write (struct ata_po
outl(val, ap->ioaddr.scr_addr + (sc_reg * 4));
 }
 
-/* move to PCI layer, integrate w/ MSI stuff */
-static void pci_enable_intx(struct pci_dev *pdev)
-{
-   u16 pci_command;
-
-   pci_read_config_word(pdev, PCI_COMMAND, _command);
-   if (pci_command & PCI_COMMAND_INTX_DISABLE) {
-   pci_command &= ~PCI_COMMAND_INTX_DISABLE;
-   pci_write_config_word(pdev, PCI_COMMAND, pci_command);
-   }
-}
-
 static int sis_init_one (struct pci_dev *pdev, const struct pci_device_id *ent)
 {
struct ata_probe_ent *probe_ent = NULL;
Index: linux-2.6.12.3-mv/drivers/scsi/ahci.c
===
--- linux-2.6.12.3-mv.orig/drivers/scsi/ahci.c
+++ linux-2.6.12.3-mv/drivers/scsi/ahci.c
@@ -878,18 +878,6 @@ static int ahci_host_init(struct ata_pro
return 0;
 }
 
-/* move to PCI layer, integrate w/ MSI stuff */
-static void pci_enable_intx(struct pci_dev *pdev)
-{
-   u16 pci_command;
-
-   pci_read_config_word(pdev, PCI_COMMAND, _command);
-   if (pci_command & PCI_COMMAND_INTX_DISABLE) {
-   pci_command &= ~PCI_COMMAND_INTX_DISABLE;
-   pci_write_config_word(pdev, PCI_COMMAND, pci_command);
-   }
-}
-
 static void ahci_print_info(struct ata_probe_ent *probe_ent)
 {
struct ahci_host_priv *hpriv = probe_ent->private_data;
Index: linux-2.6.12.3-mv/drivers/scsi/ata_piix.c
===
--- linux-2.6.12.3-mv.orig/drivers/scsi/ata_piix.c
+++ linux-2.6.12.3-mv/drivers/scsi/ata_piix.c
@@ -545,18 +545,6 @@ static void piix_set_dmamode (struct ata
}
 }
 
-/* move to PCI layer, 

Re: [PATCH] Stacker - single-use static slots

[serge]

Quoting Chris Wright ([EMAIL PROTECTED]):
> * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> > > James had suggested to effectively stash the list in the last slot, so
> > > there's only the array with one reserved slot.
> > 
> > Oh, I didn't catch that.  I like it.  Will do.
> > 
> > So you mean 3 slots total including the shared one?
> 
> Yeah, i.e. common case is $LSM and capabilities.  Stack slot is last
> one, and gets put to use only if needed.
> 
> > Any comments on the added argument to register_security and
> > mod_reg_security to request a static slot?
> 
> Why would you not request a static slot?

Capability wouldn't use it, though, so that slot would be wasted.  In my
patch, capability, cap_stack, and root_plug don't ask for a slot.

> > +   spin_lock(_field_spinlock);
> > +   if (idx && *idx) {
> > +   int i;
> > +
> > +   *idx = -1;
> 
> So, I guess this means you request one, but who knows which one you'll
> get?

If you get -1 back, you didn't get a static slot.  But you don't have to
care as a module writer, the security_*_value functions will default to
using the shared slot if idx==-1.

> > +   for (i=0; i > +   if (security_field_owners[i] == NULL) {
> > +   security_field_owners[i] = ops;
> > +   *idx = i;

This (idx != -1) means you got a static slot.

Of course this can now switch to idx==num_slots meaning you use the
shared slot.

> > Given the likelyhood of
> > capability/cap_stack being registered, it seemed worthwhile not to have
> > it waste a spot, but it is an API change...
> 
> API change is no big deal.  Seems useful to get index value so you can
> do optimized retrieve later.  But, I don't see it useful to request that
> way.  Just register, get index, if index == last slot, lookup hits list.

If we do switch to all LSMs getting a slot, should we just have the
return value for register_security and mod_reg_security be the slot#, or
-error?

thanks,
-serge
-
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] VM: add vm.free_node_memory sysctl

[Andi Kleen]

On Wed, Aug 03, 2005 at 02:59:22PM -0500, Ray Bryant wrote:
> On Wednesday 03 August 2005 09:38, Andi Kleen wrote:
> > On Wed, Aug 03, 2005 at 10:24:40AM -0400, Martin Hicks wrote:
> > > On Wed, Aug 03, 2005 at 04:15:29PM +0200, Andi Kleen wrote:
> > > > On Wed, Aug 03, 2005 at 09:56:46AM -0400, Martin Hicks wrote:
> > > > > Here's the promised sysctl to dump a node's pagecache.  Please
> > > > > review!
> > > > >
> > > > > This patch depends on the zone reclaim atomic ops cleanup:
> > > > > http://marc.theaimsgroup.com/?l=linux-mm=112307646306476=2
> > > >
> > > > Doesn't numactl --bind=node memhog nodesize-someslack do the same?
> > > >
> > > > It just might kick in the oom killer if someslack is too small
> > > > or someone has unfreeable data there. But then there should be
> > > > already an sysctl to turn that one off.
> > >
> Hmmm What happens if there are already mapped pages (e. g. mapped in the 
> sense that pages are mapped into an address space) on the node and you want 
> to allocate some more, but can't because the node is full of clean page cache 
> pages?   Then one would have to set the memhog argument to the right thing to 

If you have a bind policy in the memory grabbing program then the standard 
try_to_free_pages
should DTRT. That is because we generated a custom zone list only containing 
nodes
in that zone and the zone reclaim only looks into those.

With prefered or other policies it's different though, in that cases t_t_f_p
will also look into other nodes because the policy is not binding.

That said it might be probably possible to even make non bind policies more
aggressive at freeing in the current node before looking into other nodes. 
I think the zone balancing has been mostly tuned on non NUMA systems, so
some improvements might be possible here.

Most people don't use BIND and changing the default policies like this 
might give NUMA systems a better "out of the box" experience.  However this 
memory balance is very subtle code and easy to break, so this would need some
care.

I don't think sysctls or new syscalls are the way to go here though.

-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] i386 No-Idle-Hz aka Dynamic-Ticks 3

[Valdis . Kletnieks]

On Wed, 03 Aug 2005 14:54:40 CDT, Jeffrey Hundstad said:

> BTW: how do you know what HZ your machine is running at?

% zcat /proc/config.gz | grep -i hz

might do what you thought you wanted.

What rate you're *actually* running at is probably best done by taking the
number of timer interrupts from /proc/interrupts and dividing by the
uptime in /proc/uptime


pgpR4hyTVjIDN.pgp
Description: PGP signature

Re: Calling suspend() in halt/restart/shutdown -> not a good idea

[Benjamin Herrenschmidt]

On Wed, 2005-08-03 at 12:53 -0400, Kyle Moffett wrote:
> On Aug 3, 2005, at 07:40:54, Benjamin Herrenschmidt wrote:
> >> I'd like to get rid of shutdown callback. Having two copies of code
> >> (one in callback, one in suspend) is ugly.
> >
> > Well, it's obviously not a good time for this. First, suspend and
> > shutdown don't necessarily do the same thing, then it just doesn't  
> > work
> > in practice. So either do it right completely or not at all, but  
> > 2.6.13
> > isn't the place for an half-assed hack that looks like a solution to
> > you.
> 
> One possible way to proceed might be to add a new callback that takes a
> pm_message_t: powerdown()  If it exists, it would be called in both the
> suspend and shutdown paths, before the suspend() and shutdown() calls to
> that driver are made.  As drivers are fixed to clean up and combine that
> code, they could put the merged result into the powerdown() function,
> and remove their suspend() and shutdown() functions.

We already have shutdown() for that.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] VM: add vm.free_node_memory sysctl

[Ray Bryant]

On Wednesday 03 August 2005 09:38, Andi Kleen wrote:
> On Wed, Aug 03, 2005 at 10:24:40AM -0400, Martin Hicks wrote:
> > On Wed, Aug 03, 2005 at 04:15:29PM +0200, Andi Kleen wrote:
> > > On Wed, Aug 03, 2005 at 09:56:46AM -0400, Martin Hicks wrote:
> > > > Here's the promised sysctl to dump a node's pagecache.  Please
> > > > review!
> > > >
> > > > This patch depends on the zone reclaim atomic ops cleanup:
> > > > http://marc.theaimsgroup.com/?l=linux-mm=112307646306476=2
> > >
> > > Doesn't numactl --bind=node memhog nodesize-someslack do the same?
> > >
> > > It just might kick in the oom killer if someslack is too small
> > > or someone has unfreeable data there. But then there should be
> > > already an sysctl to turn that one off.
> >
Hmmm What happens if there are already mapped pages (e. g. mapped in the 
sense that pages are mapped into an address space) on the node and you want 
to allocate some more, but can't because the node is full of clean page cache 
pages?   Then one would have to set the memhog argument to the right thing to 
keep the existing mapped memory from being swapped out, right?  Is the data 
to set that argument readily available to user space?  Martin's patch has the 
advantage of targeting just the clean page cache pages.

The way I see this, the problem is that clean page cache pages >>should<< be 
easily available to be used to satisfy a request for mapped pages.   This 
works correctly in non-NUMA Linux systems.  But in NUMA Linux systems, we 
keep tripping over this problem all the time, particularly in the  HPC space, 
and patches like Martin's come about as an attempt to solve this in the VMM.
(We trip over this in the sense that we end up allocating off node storage 
because the current node is full of page cache pages.)

The best answer we have at the present time is to run a memory hog program 
that forces the clean page cache pages to be reclaimed by putting the node in 
question under memory pressure, but this seems like an indirect way to solve 
the problem at hand which is, really, to quickly release those page cache 
pages and make them available for user programs to allocate.  So the most 
direct way to fix this is to fix it in the VMM rather than depending on a 
memory hog based work-around of some kind.   Perhaps we haven't gotten the 
right set of patches together to do this, but my take is that is where the 
fix belongs. 

And, just for the record (  :-)  ), this is not just an Altix problem.  
Opterons are NUMA systems too, and we encounter exactly this same problem in 
the HPC space on 4-node systems.  
-- 
Ray Bryant
AMD Performance Labs   Austin, Tx
512-602-0038 (o) 512-507-7807 (c)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 3

[Jeffrey Hundstad]

Con Kolivas wrote:

This is the dynamic ticks patch for i386 as written by Tony Lindgen 
<[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>. 
Patch for 2.6.13-rc5


There were a couple of things that I wanted to change so here is an updated 
version. This code should have stabilised enough for general testing now.


The sysfs interface was moved to its own directory 
in /sys/devices/system/dyn_tick and split into separate files to 
enable/disable dynamic ticks and usage of apic on the fly. It makes sense to 
enable dynamic ticks and usage of apic by default if they're actually built 
into the kernel so that is now done.
 



I am successfully running the dynamic tick patch on an old IBM ThinkPad 
A22m.  When I enable the APIC support console beeps, you know bash -c 
'echo -e "\a"', takes a REALLY long time to finish.  I'm assuming this 
is a badly written program and not a kernel problem.  Correct?


BTW: how do you know what HZ your machine is running at?

--
Jeffrey Hundstad

-
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] Disable the debug.exception-trace sysctl by default

[Andi Kleen]

On Wed, Aug 03, 2005 at 12:39:33PM -0700, Nicholas Miell wrote:
> On Wed, 2005-08-03 at 11:03 +0200, Andi Kleen wrote:
> > On Wed, Jul 27, 2005 at 11:53:30PM -0700, Nicholas Miell wrote:
> > > debug.exception-trace causes a large amount of log spew when on, and
> > > it's on by default, which is an irritation.
> > 
> > > Here's a patch to turn it off.
> > Rejected. 
> 
> Why?

It is supposed to print normally silent segfaults. That improves
quality of software greatly because people actually notice them and
bugs get only fixed when they are noticed.

We started it early with the port, but it is still very useful.

Some misguided distributions unfortunately turn it off by default, but
I think they pay the price in general software quality.


> 
> Getting 5000 lines of
> "inkscape[13137] trap int3 rip:425051 rsp:7fa26158 error:0"
> in my logs every time I ltrace something is vastly irritating and serves
> no useful purpose.

Normally it's not supposed to print anything when the process is under control 
of 
a debugger.  But we made an exception for strace.

Unfortunately that triggers with ltrace because it uses PTRACE_SYSCALL instead
of PTRACE_CONT. 

Anyways, this patch would fix that:


Index: linux/arch/x86_64/mm/fault.c
===
--- linux.orig/arch/x86_64/mm/fault.c
+++ linux/arch/x86_64/mm/fault.c
@@ -211,9 +211,7 @@ int unhandled_signal(struct task_struct 
 {
if (tsk->pid == 1)
return 1;
-   /* Warn for strace, but not for gdb */
-   if (!test_ti_thread_flag(tsk->thread_info, TIF_SYSCALL_TRACE) &&
-   (tsk->ptrace & PT_PTRACED))
+   if (tsk->ptrace & PT_PTRACED)
return 0;
return (tsk->sighand->action[sig-1].sa.sa_handler == SIG_IGN) ||
(tsk->sighand->action[sig-1].sa.sa_handler == SIG_DFL);


> Admittedly, I can (and have) turned this off, but disabling it by
> default will probably save somebody else the trouble of figuring out
> where this crap is coming from and how to kill it.

Giving some other users with the pleasure to figure why things mysteriously
break with silent segfaults. Not a good tradeoff.

-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: Testing RC kernels [KORG]

[Bodo Eggert]

On Tue, 2 Aug 2005, H. Peter Anvin wrote:
> Michael Krufky wrote:

> > Why not just have the scripts plug values into a database, and have the 
> > html/php be formatted like Bodo suggests, and reads content from database?
> > Very simple, less maintenance... Only requires 1 initial redesign, and 
> > easier maintainence of the scripts that you speak of.
> > 
> 
> The issue is to generate the values, not present them.

Which values are available, and how are they generated?
-
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/