Re: why are some atomic_t's not volatile, while most are?

[Chris Snook]

Jerry Jiang wrote:

On Tue, 07 Aug 2007 16:32:23 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:

It seems like this would fall more into the case of the arch providing 
guarantees when using locked/atomic access rather than anything 
SMP-related, no?.
But if you're not using SMP, the only way you get a race condition is if your 
compiler is reordering instructions that have side effects which are invisible 
to the compiler.  This can happen with MMIO registers, but it's not an issue 
with an atomic_t we're declaring in real memory.




Under non-SMP, some compilers would reordering instructions as they think
and C standard informally guarantees all operations on volatile data
are executed in the sequence in which they appear in the source code,
right?

So no reordering happens with volatile, right?


Plenty of reordering happens with volatile, but on VLIW, EPIC, and 
similar architectures, it ensures that accesses to the variable in 
question will not be compiled into instruction slots that can execute 
simultaneously.


-- 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: i386: kernel boot fail at check_irq_resend:69

[Dave Young]

>On 8/8/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> Dave Young wrote:
> >> On 8/7/07, Li Yang-r58472 <[EMAIL PROTECTED]> wrote:
> >>   -Original Message-
> >>> From: [EMAIL PROTECTED]
> >>> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Young
> >>> Sent: Tuesday, August 07, 2007 2:32 PM
> >>> To: [EMAIL PROTECTED]
> >>> Cc: LKML
> >>> Subject: i386: kernel boot fail at check_irq_resend:69
> >>>
> >>> Hi,
> >>> The kernerl 2.6.23-rc1-mm2 boot fail at check_irq_resend:69
> >>>> if (WARN_ON_ONCE(desc->handle_irq != handle_edge_irq))
> >>>>return;
> >> Failed?  It's just a kernel Badness for me, and the boot can be finished.
> >
> > No, my kernel panic after this. noapic does not help too.
> > Regards
> > dave
>
> That warning should not cause a panic. Is there another message after it?
>
Yes, The timer set failed, but I think the problem maybe caused by my
wrong lpj command line parameter. If this is true, please just excuse
me for noise.

before the warning:
MP-BIOS bug : 8254 timer not connected to IO-APIC
trying to setup timer(IRQ0) through the 8259A ... failed
trying to setup timer as Virtual Wire IRQ ... failed
trying to setup timer as ExtINT IRQ

after the warning:
failed :

kernel panic - not syncing:
IO-APIC + timer doesn't work!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4 RFC] RCU: preemptible RCU

[Paul E. McKenney]

On Tue, Aug 07, 2007 at 09:18:29PM +0200, Peter Zijlstra wrote:
> On Tue, 2007-08-07 at 11:48 -0700, Paul E. McKenney wrote:
> > This patch implements a new version of RCU which allows its read-side
> > critical sections to be preempted. It uses a set of counter pairs
> > to keep track of the read-side critical sections and flips them
> > when all tasks exit read-side critical section. The details
> > of this implementation can be found in this paper -
> > 
> > http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf
> > 
> > This patch was developed as a part of the -rt kernel development and
> > meant to provide better latencies when read-side critical sections of
> > RCU don't disable preemption.  As a consequence of keeping track of RCU
> > readers, the readers have a slight overhead (optimizations in the paper).
> > This implementation co-exists with the "classic" RCU implementations
> > and can be switched to at compiler.
> > 
> > Also includes RCU tracing summarized in debugfs and RCU_SOFTIRQ for
> > the preemptible variant of RCU.
> 
> Whickedly complex but very cool stuff!
> 
> Unfortunately I have nothing to contribute other than praise at the
> complex yet elegant way you dodged the need for synchronisation.

I am glad you like it!  Heck, I may have to print this email out,
frame it, and hang it on my cube wall.  ;-)

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

[patch 6/6] Misc cleanup

[tonyj]

Misc cleanup post removal of class_device.   adm1025_group_opt is unused.

Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>

---
 drivers/hwmon/adm1025.c |   13 -
 1 file changed, 13 deletions(-)

--- a/drivers/hwmon/adm1025.c
+++ b/drivers/hwmon/adm1025.c
@@ -347,17 +347,6 @@ static const struct attribute_group adm1
.attrs = adm1025_attributes,
 };
 
-static struct attribute *adm1025_attributes_opt[] = {
-   _attr_in4_input.attr,
-   _attr_in4_min.attr,
-   _attr_in4_max.attr,
-   NULL
-};
-
-static const struct attribute_group adm1025_group_opt = {
-   .attrs = adm1025_attributes_opt,
-};
-
 /*
  * The following function does more than just detection. If detection
  * succeeds, it also registers the new chip.
@@ -482,7 +471,6 @@ static int adm1025_detect(struct i2c_ada
 
 exit_remove:
sysfs_remove_group(_client->dev.kobj, _group);
-   sysfs_remove_group(_client->dev.kobj, _group_opt);
 exit_detach:
i2c_detach_client(new_client);
 exit_free:
@@ -540,7 +528,6 @@ static int adm1025_detach_client(struct 
 
hwmon_device_unregister(data->hwmon_dev);
sysfs_remove_group(>dev.kobj, _group);
-   sysfs_remove_group(>dev.kobj, _group_opt);
 
if ((err = i2c_detach_client(client)))
return err;

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

[patch 5/6] Convert from class_device to device for drivers/video

[tonyj]

Convert from class_device to device for drivers/video.

Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>

---
 drivers/acpi/video.c |4 ++--
 drivers/video/output.c   |   29 -
 include/linux/video_output.h |4 ++--
 3 files changed, 20 insertions(+), 17 deletions(-)

--- a/drivers/video/output.c
+++ b/drivers/video/output.c
@@ -31,7 +31,8 @@ MODULE_DESCRIPTION("Display Output Switc
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Luming Yu <[EMAIL PROTECTED]>");
 
-static ssize_t video_output_show_state(struct class_device *dev,char *buf)
+static ssize_t video_output_show_state(struct device *dev,
+  struct device_attribute *attr, char *buf)
 {
ssize_t ret_size = 0;
struct output_device *od = to_output_device(dev);
@@ -40,8 +41,9 @@ static ssize_t video_output_show_state(s
return ret_size;
 }
 
-static ssize_t video_output_store_state(struct class_device *dev,
-   const char *buf,size_t count)
+static ssize_t video_output_store_state(struct device *dev,
+   struct device_attribute *attr,
+   const char *buf,size_t count)
 {
char *endp;
struct output_device *od = to_output_device(dev);
@@ -60,21 +62,22 @@ static ssize_t video_output_store_state(
return count;
 }
 
-static void video_output_class_release(struct class_device *dev)
+static void video_output_release(struct device *dev)
 {
struct output_device *od = to_output_device(dev);
kfree(od);
 }
 
-static struct class_device_attribute video_output_attributes[] = {
+static struct device_attribute video_output_attributes[] = {
__ATTR(state, 0644, video_output_show_state, video_output_store_state),
__ATTR_NULL,
 };
 
+
 static struct class video_output_class = {
.name = "video_output",
-   .release = video_output_class_release,
-   .class_dev_attrs = video_output_attributes,
+   .dev_release = video_output_release,
+   .dev_attrs = video_output_attributes,
 };
 
 struct output_device *video_output_register(const char *name,
@@ -91,11 +94,11 @@ struct output_device *video_output_regis
goto error_return;
}
new_dev->props = op;
-   new_dev->class_dev.class = _output_class;
-   new_dev->class_dev.dev = dev;
-   strlcpy(new_dev->class_dev.class_id,name,KOBJ_NAME_LEN);
-   class_set_devdata(_dev->class_dev,devdata);
-   ret_code = class_device_register(_dev->class_dev);
+   new_dev->dev.class = _output_class;
+   new_dev->dev.parent = dev;
+   strlcpy(new_dev->dev.bus_id,name, BUS_ID_SIZE);
+   dev_set_drvdata(_dev->dev, devdata);
+   ret_code = device_register(_dev->dev);
if (ret_code) {
kfree(new_dev);
goto error_return;
@@ -111,7 +114,7 @@ void video_output_unregister(struct outp
 {
if (!dev)
return;
-   class_device_unregister(>class_dev);
+   device_unregister(>dev);
 }
 EXPORT_SYMBOL(video_output_unregister);
 
--- a/include/linux/video_output.h
+++ b/include/linux/video_output.h
@@ -31,9 +31,9 @@ struct output_properties {
 struct output_device {
int request_state;
struct output_properties *props;
-   struct class_device class_dev;
+   struct device dev;
 };
-#define to_output_device(obj) container_of(obj, struct output_device, 
class_dev)
+#define to_output_device(obj) container_of(obj, struct output_device, dev)
 struct output_device *video_output_register(const char *name,
struct device *dev,
void *devdata,
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -314,7 +314,7 @@ static int acpi_video_output_get(struct 
 {
unsigned long state;
struct acpi_video_device *vd =
-   (struct acpi_video_device *)class_get_devdata(>class_dev);
+   (struct acpi_video_device *)dev_get_drvdata(>dev);
acpi_video_device_get_state(vd, );
return (int)state;
 }
@@ -323,7 +323,7 @@ static int acpi_video_output_set(struct 
 {
unsigned long state = od->request_state;
struct acpi_video_device *vd=
-   (struct acpi_video_device *)class_get_devdata(>class_dev);
+   (struct acpi_video_device *)dev_get_drvdata(>dev);
return acpi_video_device_set_state(vd, state);
 }
 

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

[patch 3/6] Convert from class_device to device for hwmon

[tonyj]

Convert from class_device to device for hwmon_device_register/unregister

Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>

---
 drivers/hwmon/hwmon.c |   27 +--
 include/linux/hwmon.h |4 ++--
 2 files changed, 15 insertions(+), 16 deletions(-)

--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -28,17 +28,17 @@ static DEFINE_IDR(hwmon_idr);
 static DEFINE_SPINLOCK(idr_lock);
 
 /**
- * hwmon_device_register - register w/ hwmon sysfs class
+ * hwmon_device_register - register w/ hwmon
  * @dev: the device to register
  *
- * hwmon_device_unregister() must be called when the class device is no
+ * hwmon_device_unregister() must be called when the device is no
  * longer needed.
  *
- * Returns the pointer to the new struct class device.
+ * Returns the pointer to the new device.
  */
-struct class_device *hwmon_device_register(struct device *dev)
+struct device *hwmon_device_register(struct device *dev)
 {
-   struct class_device *cdev;
+   struct device *hwdev;
int id, err;
 
 again:
@@ -55,34 +55,33 @@ again:
return ERR_PTR(err);
 
id = id & MAX_ID_MASK;
-   cdev = class_device_create(hwmon_class, NULL, MKDEV(0,0), dev,
-   HWMON_ID_FORMAT, id);
+   hwdev = device_create(hwmon_class, dev, MKDEV(0,0), HWMON_ID_FORMAT, 
id);
 
-   if (IS_ERR(cdev)) {
+   if (IS_ERR(hwdev)) {
spin_lock(_lock);
idr_remove(_idr, id);
spin_unlock(_lock);
}
 
-   return cdev;
+   return hwdev;
 }
 
 /**
  * hwmon_device_unregister - removes the previously registered class device
  *
- * @cdev: the class device to destroy
+ * @dev: the class device to destroy
  */
-void hwmon_device_unregister(struct class_device *cdev)
+void hwmon_device_unregister(struct device *dev)
 {
int id;
 
-   if (likely(sscanf(cdev->class_id, HWMON_ID_FORMAT, ) == 1)) {
-   class_device_unregister(cdev);
+   if (likely(sscanf(dev->bus_id, HWMON_ID_FORMAT, ) == 1)) {
+   device_unregister(dev);
spin_lock(_lock);
idr_remove(_idr, id);
spin_unlock(_lock);
} else
-   dev_dbg(cdev->dev,
+   dev_dbg(dev->parent,
"hwmon_device_unregister() failed: bad class ID!\n");
 }
 
--- a/include/linux/hwmon.h
+++ b/include/linux/hwmon.h
@@ -16,9 +16,9 @@
 
 #include 
 
-struct class_device *hwmon_device_register(struct device *dev);
+struct device *hwmon_device_register(struct device *dev);
 
-void hwmon_device_unregister(struct class_device *cdev);
+void hwmon_device_unregister(struct device *dev);
 
 /* Scale user input to sensible values */
 static inline int SENSORS_LIMIT(long value, long low, long high)

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Convert from class_device to device in drivers/char

[tonyj]

Convert from class_device to device in drivers/char.

Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>

---
 drivers/char/dsp56k.c|4 ++--
 drivers/char/ip2/ip2main.c   |   12 ++--
 drivers/char/ipmi/ipmi_devintf.c |6 +++---
 drivers/char/istallion.c |8 +++-
 drivers/char/lp.c|5 ++---
 drivers/char/pcmcia/cm4000_cs.c  |5 ++---
 drivers/char/pcmcia/cm4040_cs.c  |5 ++---
 drivers/char/snsc.c  |3 +--
 drivers/char/stallion.c  |7 +++
 drivers/char/tipar.c |6 +++---
 drivers/char/viotape.c   |   10 +-
 11 files changed, 32 insertions(+), 39 deletions(-)

--- a/drivers/char/viotape.c
+++ b/drivers/char/viotape.c
@@ -951,10 +951,10 @@ static int viotape_probe(struct vio_dev 
state[i].cur_part = 0;
for (j = 0; j < MAX_PARTITIONS; ++j)
state[i].part_stat_rwi[j] = VIOT_IDLE;
-   class_device_create(tape_class, NULL, MKDEV(VIOTAPE_MAJOR, i), NULL,
+   device_create(tape_class, NULL, MKDEV(VIOTAPE_MAJOR, i),
"iseries!vt%d", i);
-   class_device_create(tape_class, NULL, MKDEV(VIOTAPE_MAJOR, i | 0x80),
-   NULL, "iseries!nvt%d", i);
+   device_create(tape_class, NULL, MKDEV(VIOTAPE_MAJOR, i | 0x80),
+   "iseries!nvt%d", i);
printk(VIOTAPE_KERN_INFO "tape iseries/vt%d is iSeries "
"resource %10.10s type %4.4s, model %3.3s\n",
i, viotape_unitinfo[i].rsrcname,
@@ -966,8 +966,8 @@ static int viotape_remove(struct vio_dev
 {
int i = vdev->unit_address;
 
-   class_device_destroy(tape_class, MKDEV(VIOTAPE_MAJOR, i | 0x80));
-   class_device_destroy(tape_class, MKDEV(VIOTAPE_MAJOR, i));
+   device_destroy(tape_class, MKDEV(VIOTAPE_MAJOR, i | 0x80));
+   device_destroy(tape_class, MKDEV(VIOTAPE_MAJOR, i));
return 0;
 }
 
--- a/drivers/char/ipmi/ipmi_devintf.c
+++ b/drivers/char/ipmi/ipmi_devintf.c
@@ -865,7 +865,7 @@ static void ipmi_new_smi(int if_num, str
entry->dev = dev;
 
mutex_lock(_list_mutex);
-   class_device_create(ipmi_class, NULL, dev, device, "ipmi%d", if_num);
+   device_create(ipmi_class, device, dev, "ipmi%d", if_num);
list_add(>link, _list);
mutex_unlock(_list_mutex);
 }
@@ -883,7 +883,7 @@ static void ipmi_smi_gone(int if_num)
break;
}
}
-   class_device_destroy(ipmi_class, dev);
+   device_destroy(ipmi_class, dev);
mutex_unlock(_list_mutex);
 }
 
@@ -938,7 +938,7 @@ static __exit void cleanup_ipmi(void)
mutex_lock(_list_mutex);
list_for_each_entry_safe(entry, entry2, _list, link) {
list_del(>link);
-   class_device_destroy(ipmi_class, entry->dev);
+   device_destroy(ipmi_class, entry->dev);
kfree(entry);
}
mutex_unlock(_list_mutex);
--- a/drivers/char/pcmcia/cm4000_cs.c
+++ b/drivers/char/pcmcia/cm4000_cs.c
@@ -1864,8 +1864,7 @@ static int cm4000_probe(struct pcmcia_de
return ret;
}
 
-   class_device_create(cmm_class, NULL, MKDEV(major, i), NULL,
-   "cmm%d", i);
+   device_create(cmm_class, NULL, MKDEV(major, i), "cmm%d", i);
 
return 0;
 }
@@ -1889,7 +1888,7 @@ static void cm4000_detach(struct pcmcia_
dev_table[devno] = NULL;
kfree(dev);
 
-   class_device_destroy(cmm_class, MKDEV(major, devno));
+   device_destroy(cmm_class, MKDEV(major, devno));
 
return;
 }
--- a/drivers/char/pcmcia/cm4040_cs.c
+++ b/drivers/char/pcmcia/cm4040_cs.c
@@ -642,8 +642,7 @@ static int reader_probe(struct pcmcia_de
return ret;
}
 
-   class_device_create(cmx_class, NULL, MKDEV(major, i), NULL,
-   "cmx%d", i);
+   device_create(cmx_class, NULL, MKDEV(major, i), "cmx%d", i);
 
return 0;
 }
@@ -666,7 +665,7 @@ static void reader_detach(struct pcmcia_
dev_table[devno] = NULL;
kfree(dev);
 
-   class_device_destroy(cmx_class, MKDEV(major, devno));
+   device_destroy(cmx_class, MKDEV(major, devno));
 
return;
 }
--- a/drivers/char/stallion.c
+++ b/drivers/char/stallion.c
@@ -4778,9 +4778,8 @@ static int __init stallion_module_init(v
if (IS_ERR(stallion_class))
printk("STALLION: failed to create class\n");
for (i = 0; i < 4; i++)
-   class_device_create(stallion_class, NULL,
-   MKDEV(STL_SIOMEMMAJOR, i), NULL,
-   "staliomem%d", i);
+   device_create(stallion_class, NULL, MKDEV(STL_SIOMEMMAJOR, i),
+ "staliomem%d", i);
 
return 0;
 err_unrtty:
@@ -4816,7 +4815,7 @@ static void __exit stallion_module_exit(
}
 

[patch 0/6] Convert from class_device to device [char, hwmon, video]

[tonyj]

Convert drivers/char, drivers/hwmon and drivers/video from struct class_device
to struct device.  Toward end-goal of removing class_device.
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 1/6] Convert from class_device to device in drivers/char/drm

[tonyj]

Convert from class_device to device in drivers/char/drm.

Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>

---
 drivers/char/drm/drmP.h  |8 ++---
 drivers/char/drm/drm_stub.c  |9 +++---
 drivers/char/drm/drm_sysfs.c |   58 ++-
 3 files changed, 39 insertions(+), 36 deletions(-)

Index: b/drivers/char/drm/drm_sysfs.c
===
--- a/drivers/char/drm/drm_sysfs.c
+++ b/drivers/char/drm/drm_sysfs.c
@@ -78,79 +78,81 @@ void drm_sysfs_destroy(struct class *cla
class_destroy(class);
 }
 
-static ssize_t show_dri(struct class_device *class_device, char *buf)
+static ssize_t show_dri(struct device *drm_sysfs_dev,
+   struct device_attribute *attr, char *buf)
 {
-   struct drm_device * dev = ((struct drm_head 
*)class_get_devdata(class_device))->dev;
+   struct drm_device *dev =
+   ((struct drm_head *)dev_get_drvdata(drm_sysfs_dev))->dev;
+
if (dev->driver->dri_library_name)
return dev->driver->dri_library_name(dev, buf);
return snprintf(buf, PAGE_SIZE, "%s\n", dev->driver->pci_driver.name);
 }
 
-static struct class_device_attribute class_device_attrs[] = {
+static struct device_attribute drm_sysfs_device_attrs[] = {
__ATTR(dri_library_name, S_IRUGO, show_dri, NULL),
 };
 
 /**
- * drm_sysfs_device_add - adds a class device to sysfs for a character driver
+ * drm_sysfs_device_add - adds a device to sysfs for a character driver
  * @cs: pointer to the struct class that this device should be registered to.
  * @dev: the dev_t for the device to be added.
  * @device: a pointer to a struct device that is assiociated with this class 
device.
  * @fmt: string for the class device's name
  *
- * A struct class_device will be created in sysfs, registered to the specified
+ * A struct device will be created in sysfs, registered to the specified
  * class.  A "dev" file will be created, showing the dev_t for the device.  The
- * pointer to the struct class_device will be returned from the call.  Any 
further
+ * pointer to the struct device will be returned from the call.  Any further
  * sysfs files that might be required can be created using this pointer.
  * Note: the struct class passed to this function must have previously been
  * created with a call to drm_sysfs_create().
  */
-struct class_device *drm_sysfs_device_add(struct class *cs, struct drm_head 
*head)
+struct device *drm_sysfs_device_add(struct class *cs, struct drm_head *head)
 {
-   struct class_device *class_dev;
+   struct device *drm_sysfs_dev;
int i, j, err;
 
-   class_dev = class_device_create(cs, NULL,
-   MKDEV(DRM_MAJOR, head->minor),
-   &(head->dev->pdev)->dev,
-   "card%d", head->minor);
-   if (IS_ERR(class_dev)) {
-   err = PTR_ERR(class_dev);
+   drm_sysfs_dev = device_create(cs, &(head->dev->pdev)->dev,
+   MKDEV(DRM_MAJOR, head->minor),
+   "card%d", head->minor);
+   if (IS_ERR(drm_sysfs_dev)) {
+   err = PTR_ERR(drm_sysfs_dev);
goto err_out;
}
 
-   class_set_devdata(class_dev, head);
+   dev_set_drvdata(drm_sysfs_dev, head);
 
-   for (i = 0; i < ARRAY_SIZE(class_device_attrs); i++) {
-   err = class_device_create_file(class_dev,
-  _device_attrs[i]);
+   for (i = 0; i < ARRAY_SIZE(drm_sysfs_device_attrs); i++) {
+   err = device_create_file(drm_sysfs_dev,
+_sysfs_device_attrs[i]);
if (err)
goto err_out_files;
}
 
-   return class_dev;
+   return drm_sysfs_dev;
 
 err_out_files:
if (i > 0)
for (j = 0; j < i; j++)
-   class_device_remove_file(class_dev,
-_device_attrs[i]);
-   class_device_unregister(class_dev);
+   device_remove_file(drm_sysfs_dev,
+  _sysfs_device_attrs[i]);
+   device_unregister(drm_sysfs_dev);
 err_out:
return ERR_PTR(err);
 }
 
 /**
- * drm_sysfs_device_remove - removes a class device that was created with 
drm_sysfs_device_add()
- * @dev: the dev_t of the device that was previously registered.
+ * drm_sysfs_device_remove - removes a device that was created with 
drm_sysfs_device_add()
+ * @drm_sysfs_dev: the device that was previously registered
  *
  * This call unregisters and cleans up a class device that was created with a
  * call to drm_sysfs_device_add()
  */
-void drm_sysfs_device_remove(struct class_device *class_dev)
+void drm_sysfs_device_remove(struct device *drm_sysfs_dev)
 {
   

Re: [fuse-devel] [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)

[Miklos Szeredi]

> >From a purely practical standpoint: it's a concern that all filesytems need
> patching to continue to correctly function after this change.  There might
> be filesystems which you missed, and there are out-of-tree filesystems
> which won't be updated.
> 
> And I think the impact upon the out-of-tree filesystems would be fairly
> severe: they quietly and subtly get their secutiry guarantees broken (I
> think?)
> 
> Is there any way in which we can prevent these problems?  Say
> 
> - rename something so that unconverted filesystems will reliably fail to
>   compile?

Maybe renaming ATTR_MODE to ATTR_MODE_SET (changing it's value as
well, so that binary stuff breaks visibly as well)?

This would make sense, because we are changing what this attribute
acually means.  In the new code attr->ia_mode only contains the
originally set mode, not the ones we've added to change the suid bits.

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: allow non root users to set io priority "idle" ?

[Jens Axboe]

On Wed, Aug 08 2007, dragoran wrote:
> so there is no real reason not to allow it for non root users?
> removing the check is easy (3 lines) 
> or are there any other issues/problems?

Andi already explained to you why it can't be enabled for non-root
users. I merely talked about why idle priority works.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Error message from device_rename in drivers/base/core.c

[Larry Finger]

David Miller wrote:

From: Larry Finger <[EMAIL PROTECTED]>
Date: Tue, 07 Aug 2007 23:52:34 -0500


Yes, it is most likely coming from udev. Do you know who maintains
udev? Google didn't give an answer in the first two pages.


I may be mis-remembering but I thought Greg KH was at the
helm at least at one point.



Between the previous message and this one, I found a link that lists him as one of the authors. I'll 
ping him about the "problem". Thanks for your help.


Larry

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

[PATCH] drivers/scsi/ips.c: fix scsi_add_host warning

[Eugene Teo]

This patch fixes the following warning:

drivers/scsi/ips.c: In function 'ips_register_scsi':
drivers/scsi/ips.c:6867: warning: ignoring return value of
'scsi_add_host', declared with attribute warn_unused_result

Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
---
 drivers/scsi/ips.c |   16 
 1 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
index 492a51b..b04c42f 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -6824,13 +6824,14 @@ ips_order_controllers(void)
 static int
 ips_register_scsi(int index)
 {
+   int rc = -1;
struct Scsi_Host *sh;
ips_ha_t *ha, *oldha = ips_ha[index];
sh = scsi_host_alloc(_driver_template, sizeof (ips_ha_t));
if (!sh) {
IPS_PRINTK(KERN_WARNING, oldha->pcidev,
   "Unable to register controller with SCSI 
subsystem\n");
-   return -1;
+   return rc;
}
ha = IPS_HA(sh);
memcpy(ha, oldha, sizeof (ips_ha_t));
@@ -6839,8 +6840,7 @@ ips_register_scsi(int index)
if (request_irq(ha->irq, do_ipsintr, IRQF_SHARED, ips_name, ha)) {
IPS_PRINTK(KERN_WARNING, ha->pcidev,
   "Unable to install interrupt handler\n");
-   scsi_host_put(sh);
-   return -1;
+   goto err_put_sh;
}
 
kfree(oldha);
@@ -6864,10 +6864,18 @@ ips_register_scsi(int index)
sh->max_channel = ha->nbus - 1;
sh->can_queue = ha->max_cmds - 1;
 
-   scsi_add_host(sh, NULL);
+   rc = scsi_add_host(sh, NULL);
+   if (rc)
+   goto err_free_irq;
scsi_scan_host(sh);
 
return 0;
+
+err_free_irq:
+   free_irq(ha->irq);
+err_put_sh:
+   scsi_host_put(sh);
+   return rc;
 }
 
 /*---*/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Error message from device_rename in drivers/base/core.c

[David Miller]

From: Larry Finger <[EMAIL PROTECTED]>
Date: Tue, 07 Aug 2007 23:52:34 -0500

> Yes, it is most likely coming from udev. Do you know who maintains
> udev? Google didn't give an answer in the first two pages.

I may be mis-remembering but I thought Greg KH was at the
helm at least at one point.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Error message from device_rename in drivers/base/core.c

[Larry Finger]

David Miller wrote:

From: Larry Finger <[EMAIL PROTECTED]>
Date: Tue, 07 Aug 2007 23:17:23 -0500


I am getting the following error message from drivers/base/core.c:

net eth1: device_rename: sysfs_create_symlink failed (-17)

Upon investigation, the call generating the error is renaming 'eth1' to 'eth1'. The following patch 
suppresses the error.


I think this check belongs in udev not in the kernel.  Thankfully
this message at least tells us it is happening, please don't
remove it.

I'm pretty sure it's UDEV doing this, and it should not try to rename
a netdevice to what it already is named.



Yes, it is most likely coming from udev. Do you know who maintains udev? Google didn't give an 
answer in the first two pages.


Thanks,

Larry

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: why are some atomic_t's not volatile, while most are?

[Chris Friesen]

Chris Snook wrote:

This is not a problem, since indirect references will cause the CPU to 
fetch the data from memory/cache anyway.


Isn't Zan's sample code (that shows the problem) already using indirect 
references?


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: Error message from device_rename in drivers/base/core.c

[David Miller]

From: Larry Finger <[EMAIL PROTECTED]>
Date: Tue, 07 Aug 2007 23:17:23 -0500

> I am getting the following error message from drivers/base/core.c:
> 
> net eth1: device_rename: sysfs_create_symlink failed (-17)
> 
> Upon investigation, the call generating the error is renaming 'eth1' to 
> 'eth1'. The following patch 
> suppresses the error.

I think this check belongs in udev not in the kernel.  Thankfully
this message at least tells us it is happening, please don't
remove it.

I'm pretty sure it's UDEV doing this, and it should not try to rename
a netdevice to what it already is named.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Disk spin down issue on shut down/suspend to disk

[Robert Hancock]

Henrique de Moraes Holschuh wrote:

On Tue, 07 Aug 2007, Robert Hancock wrote:

You *do* have to worry about it in any box you turn off daily.  Desktop
HDs will croak fast in that scenario, laptop HDs less so, but still too
fast.  A very good laptop HD can last about 20k emergency unloads (this
is a unit that can do about 600k normal unloads in its lifetime).
Desktop and server HDs don't even come close to those numbers, last time
I checked.

It only matters on hard drives which actually use load-unload heads. Lots
of desktop/server drives (perhaps some laptop ones as well) still use
contact start/stop, which doesn't remove the heads from the platters on


I am not so sure about that.

Please correct me if I am wrong, but contact stop in an emergency retract
shakes the head assembly badly as well. It subjects the head assembly to
higher acceleration than a normal seek, and a nasty impulse at impact with
the stopper.  And I very much doubt it is nice to the heads to slide into
the parking zone at high speed and hit the bumper while over it.

Unless I missed something, I don't why an emergency retract would not be as
big a problem as an emergency unload.

Maybe we should hunt down some proper datasheets for drives lacking head
load/unload technology, and check what they say about emergency unloads...


I did a bit of a look and didn't find any mention of the subject for 
drives using contact start/stop. I did find mention that the unload 
torque needed is quite a bit higher on load/unload systems, so I would 
imagine that having to extract or store that energy for emergency 
unloads would be more of a demanding task and might be a rougher process.


Just judging from the sound, though, hard power-offs on a desktop 
Seagate Barracuda 7200.10, for example, which is contact start/stop, 
don't really sound any different from a commanded standby. On the laptop 
drives I've seen you can really tell the difference.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

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

[patch 2/2] x86_64: ticket lock spinlock

[Nick Piggin]

Introduce ticket lock spinlocks for x86-64 which are FIFO. The implementation
is described in the comments. The straight-line lock/unlock instruction
sequence is slightly slower than the dec based locks on modern x86 CPUs,
however the difference is quite small on Core2 and Opteron when working out of
cache, and becomes almost insignificant even on P4 when the lock misses cache.
trylock is more significantly slower, but they are relatively rare.

The memory ordering of the lock does conform to Intel's standards, and the
implementation has been reviewed by Intel and AMD engineers.

The algorithm also tells us how many CPUs are contending the lock, so
lockbreak becomes trivial and we no longer have to waste 4 bytes per
spinlock for it.

After this, we can no longer spin on any locks with preempt enabled,
and cannot reenable interrupts when spinning on an irq safe lock, because
at that point we have already taken a ticket and the would deadlock if
the same CPU tries to take the lock again.  These are hackish anyway: if
the lock happens to be called under a preempt or interrupt disabled section,
then it will just have the same latency problems. The real fix is to keep
critical sections short, and ensure locks are reasonably fair (which this
patch does).

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

---
Index: linux-2.6/include/asm-x86_64/spinlock.h
===
--- linux-2.6.orig/include/asm-x86_64/spinlock.h
+++ linux-2.6/include/asm-x86_64/spinlock.h
@@ -12,74 +12,93 @@
  * Simple spin lock operations.  There are two variants, one clears IRQ's
  * on the local processor, one does not.
  *
- * We make no fairness assumptions. They have a cost.
+ * These are fair FIFO ticket locks, which are currently limited to 256
+ * CPUs.
  *
  * (the type definitions are in asm/spinlock_types.h)
  */
 
+#if (NR_CPUS > 256)
+#error spinlock supports a maximum of 256 CPUs
+#endif
+
 static inline int __raw_spin_is_locked(raw_spinlock_t *lock)
 {
-   return *(volatile signed int *)(&(lock)->slock) <= 0;
+   int tmp = *(volatile signed int *)(&(lock)->slock);
+
+   return (((tmp >> 8) & 0xff) != (tmp & 0xff));
 }
 
-static inline void __raw_spin_lock(raw_spinlock_t *lock)
+static inline int __raw_spin_is_contended(raw_spinlock_t *lock)
 {
-   asm volatile(
-   "\n1:\t"
-   LOCK_PREFIX " ; decl %0\n\t"
-   "jns 2f\n"
-   "3:\n"
-   "rep;nop\n\t"
-   "cmpl $0,%0\n\t"
-   "jle 3b\n\t"
-   "jmp 1b\n"
-   "2:\t" : "=m" (lock->slock) : : "memory");
+   int tmp = *(volatile signed int *)(&(lock)->slock);
+
+   return (((tmp >> 8) & 0xff) - (tmp & 0xff)) > 1;
 }
 
-/*
- * Same as __raw_spin_lock, but reenable interrupts during spinning.
- */
-#ifndef CONFIG_PROVE_LOCKING
-static inline void __raw_spin_lock_flags(raw_spinlock_t *lock, unsigned long 
flags)
+static inline void __raw_spin_lock(raw_spinlock_t *lock)
 {
-   asm volatile(
-   "\n1:\t"
-   LOCK_PREFIX " ; decl %0\n\t"
-   "jns 5f\n"
-   "testl $0x200, %1\n\t"  /* interrupts were disabled? */
-   "jz 4f\n\t"
-   "sti\n"
-   "3:\t"
-   "rep;nop\n\t"
-   "cmpl $0, %0\n\t"
-   "jle 3b\n\t"
-   "cli\n\t"
+   short inc = 0x0100;
+
+   /*
+* Ticket locks are conceptually two bytes, one indicating the current
+* head of the queue, and the other indicating the current tail. The
+* lock is acquired by atomically noting the tail and incrementing it
+* by one (thus adding ourself to the queue and noting our position),
+* then waiting until the head becomes equal to the the initial value
+* of the tail.
+*
+* This uses a 16-bit xadd to increment the tail and also load the
+* position of the head, which takes care of memory ordering issues
+* and should be optimal for the uncontended case. Note the tail must
+* be in the high byte, otherwise the 16-bit wide increment of the low
+* byte would carry up and contaminate the high byte.
+*/
+
+   __asm__ __volatile__ (
+   LOCK_PREFIX "xaddw %w0, %1\n"
+   "1:\t"
+   "cmpb %h0, %b0\n\t"
+   "je 2f\n\t"
+   "rep ; nop\n\t"
+   "movb %1, %b0\n\t"
+   "lfence\n\t"
"jmp 1b\n"
-   "4:\t"
-   "rep;nop\n\t"
-   "cmpl $0, %0\n\t"
-   "jg 1b\n\t"
-   "jmp 4b\n"
-   "5:\n\t"
-   : "+m" (lock->slock) : "r" ((unsigned)flags) : "memory");
+   "2:"
+   :"+Q" (inc), "+m" (lock->slock)
+   :
+   :"memory", "cc");
 }
-#endif
+
+#define __raw_spin_lock_flags(lock, flags) __raw_spin_lock(lock)
 
 

[patch 1/2] spinlock: lockbreak cleanup

[Nick Piggin]

The break_lock data structure and code for spinlocks is quite nasty.
Not only does it double the size of a spinlock but it changes locking to
a potentially less optimal trylock.

Put all of that under CONFIG_GENERIC_LOCKBREAK, and introduce a
__raw_spin_is_contended that uses the lock data itself to determine whether
there are waiters on the lock, to be used if CONFIG_GENERIC_LOCKBREAK is
not set.

Rename need_lockbreak to spin_needbreak, make it use spin_is_contended to
decouple it from the spinlock implementation, and make it typesafe (rwlocks
do not have any need_lockbreak sites -- why do they even get bloated up
with that break_lock then?).

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

---
Index: linux-2.6/include/linux/sched.h
===
--- linux-2.6.orig/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
@@ -1741,26 +1741,16 @@ extern int cond_resched_softirq(void);
 
 /*
  * Does a critical section need to be broken due to another
- * task waiting?:
+ * task waiting?: (technically does not depend on CONFIG_PREEMPT,
+ * but a general need for low latency)
  */
-#if defined(CONFIG_PREEMPT) && defined(CONFIG_SMP)
-# define need_lockbreak(lock) ((lock)->break_lock)
+#ifdef CONFIG_PREEMPT
+# define spin_needbreak(lock)  spin_is_contended(lock)
 #else
-# define need_lockbreak(lock) 0
+# define spin_needbreak(lock)  0
 #endif
 
 /*
- * Does a critical section need to be broken due to another
- * task waiting or preemption being signalled:
- */
-static inline int lock_need_resched(spinlock_t *lock)
-{
-   if (need_lockbreak(lock) || need_resched())
-   return 1;
-   return 0;
-}
-
-/*
  * Reevaluate whether the task has signals pending delivery.
  * Wake the task if so.
  * This is required every time the blocked sigset_t changes.
Index: linux-2.6/include/linux/spinlock.h
===
--- linux-2.6.orig/include/linux/spinlock.h
+++ linux-2.6/include/linux/spinlock.h
@@ -120,6 +120,12 @@ do {   
\
 
 #define spin_is_locked(lock)   __raw_spin_is_locked(&(lock)->raw_lock)
 
+#ifdef CONFIG_GENERIC_LOCKBREAK
+#define spin_is_contended(lock) ((lock)->break_lock)
+#else
+#define spin_is_contended(lock)
__raw_spin_is_contended(&(lock)->raw_lock)
+#endif
+
 /**
  * spin_unlock_wait - wait until the spinlock gets unlocked
  * @lock: the spinlock in question.
Index: linux-2.6/fs/jbd/checkpoint.c
===
--- linux-2.6.orig/fs/jbd/checkpoint.c
+++ linux-2.6/fs/jbd/checkpoint.c
@@ -347,7 +347,8 @@ restart:
break;
}
retry = __process_buffer(journal, jh, bhs,_count);
-   if (!retry && lock_need_resched(>j_list_lock)){
+   if (!retry && (need_resched() ||
+   spin_needbreak(>j_list_lock))) {
spin_unlock(>j_list_lock);
retry = 1;
break;
Index: linux-2.6/fs/jbd/commit.c
===
--- linux-2.6.orig/fs/jbd/commit.c
+++ linux-2.6/fs/jbd/commit.c
@@ -265,7 +265,7 @@ write_out_data:
put_bh(bh);
}
 
-   if (lock_need_resched(>j_list_lock)) {
+   if (need_resched() || spin_needbreak(>j_list_lock)) {
spin_unlock(>j_list_lock);
goto write_out_data;
}
Index: linux-2.6/fs/jbd2/checkpoint.c
===
--- linux-2.6.orig/fs/jbd2/checkpoint.c
+++ linux-2.6/fs/jbd2/checkpoint.c
@@ -347,7 +347,8 @@ restart:
break;
}
retry = __process_buffer(journal, jh, bhs,_count);
-   if (!retry && lock_need_resched(>j_list_lock)){
+   if (!retry && (need_resched() ||
+   spin_needbreak(>j_list_lock))) {
spin_unlock(>j_list_lock);
retry = 1;
break;
Index: linux-2.6/fs/jbd2/commit.c
===
--- linux-2.6.orig/fs/jbd2/commit.c
+++ linux-2.6/fs/jbd2/commit.c
@@ -265,7 +265,7 @@ write_out_data:
put_bh(bh);
}
 
-   if (lock_need_resched(>j_list_lock)) {
+   if (need_resched() || spin_needbreak(>j_list_lock)) {
spin_unlock(>j_list_lock);
goto write_out_data;
}
Index: linux-2.6/include/linux/spinlock_up.h
===
--- 

Re: [PATCH] msleep() with hrtimers

[Arjan van de Ven]

On Tue, 2007-08-07 at 14:45 +0200, Roman Zippel wrote:
> Hi,
> 
> On Mon, 6 Aug 2007, Arjan van de Ven wrote:
> 
> > So, let me ask a direct question: What do you think is specifically
> > wrong about changing the msleep() implementation as is done here? The
> > behavior is clearly an improvement, so what is your objection on the
> > flipside?
> 
> Again, we have two different timer APIs for a reason

yes because we have different usage patterns for timers. (exact/course
or expiring/not-typically-expiring; I know you have some other opinion
here than other people).

For this case it's relatively simple imo: The existing implementation
has a *typical* behavior which is 100% to 2000% worse than what the user
of the API asks for. And that is totally unneeded to be so crappy; it
can be much more exact easily as shown by this patch.

You keep claiming that hrtimers are so incredibly expensive; but for
msleep()... which is mostly called during driver init ... I really don't
buy that it's really expensive. We're not doing this a gazilion times
per second obviously...

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.org

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

Error message from device_rename in drivers/base/core.c

[Larry Finger]

I am getting the following error message from drivers/base/core.c:

net eth1: device_rename: sysfs_create_symlink failed (-17)

Upon investigation, the call generating the error is renaming 'eth1' to 'eth1'. The following patch 
suppresses the error.



Index: wireless-dev/drivers/base/core.c
===
--- wireless-dev.orig/drivers/base/core.c
+++ wireless-dev/drivers/base/core.c
@@ -1256,7 +1256,7 @@ int device_rename(struct device *dev, ch
sysfs_remove_link(>class->subsys.kobj, old_device_name);
error = sysfs_create_link(>class->subsys.kobj, >kobj,
  dev->bus_id);
-   if (error) {
+   if (error && memcmp(dev->bus_id, new_name, sizeof(new_name))) {
/* Uh... how to unravel this if restoring can fail? */
dev_err(dev, "%s: sysfs_create_symlink failed (%d)\n",
__FUNCTION__, error);


Larry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] msleep() with hrtimers

[Andrew Morton]

On Wed, 8 Aug 2007 05:47:02 +0200 (CEST) Roman Zippel <[EMAIL PROTECTED]> wrote:

> 
> 
> On Tue, 7 Aug 2007, Andrew Morton wrote:
> 
> > On Wed, 8 Aug 2007 01:16:49 +0200 (CEST)
> > Roman Zippel <[EMAIL PROTECTED]> wrote:
> > 
> > > Hi,
> > > 
> > > On Tue, 7 Aug 2007, Andrew Morton wrote:
> > > 
> > > > I'd be surprised if there was significant overhead - the maximum 
> > > > frequency
> > > > at which msleep() can be called is 1000Hz.  We'd need an awful lot of
> > > > overhead for that to cause problems, surely?
> > > > 
> > > > 
> > > 
> > > _Anybody_ has yet to answer what's wrong with adding a nanosleep() and 
> > > using that instead.
> > > 
> > 
> > You mean that the implementation could be simplified if msleep() were to
> > simply call do_nanosleep()?
> 
> The current msleep is fine and doesn't need any "fixing".
> Not all the world is i386, _please_ keep hrtimer usage where it's 
> required. Simple timer should be given preference unless the higher 
> resolution is really needed, which is not the case here.

Hang on.  Having msleep(1) sleep for 20 milliseconds is really awful
behaviour.  Possibly worse is the fact that with other configs, it will
delay for eight milliseconds.  Or two.  That's an order of magnitude of
unpredictability which can actually cause driver breakage.

Fixing that *bug* is a good thing.  I see no reason why we should "keep
hrtimer usage where it is required"?  The implementation details are hidden
from the caller.

It seems to be a sensible change to me and I fail to understand the
objection.

> so below is a nanosleep implementation based 
> on Jonathan's patch. This will user give a choice, so there is no need to 
> force all users to use hrtimer for a simple sleep.

But apart from needlessly fattening the kernel API, that leaves us in the
current situation where an unknown number of the msleep() callers actually
care that they are calling a function which by a huge margin fails to do
what they are asking it to do.  It will take a long time to hunt down all
the problematic callsites and migrate them to nanosleep().

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Disk spin down issue on shut down/suspend to disk

[Henrique de Moraes Holschuh]

On Tue, 07 Aug 2007, Robert Hancock wrote:
>> You *do* have to worry about it in any box you turn off daily.  Desktop
>> HDs will croak fast in that scenario, laptop HDs less so, but still too
>> fast.  A very good laptop HD can last about 20k emergency unloads (this
>> is a unit that can do about 600k normal unloads in its lifetime).
>> Desktop and server HDs don't even come close to those numbers, last time
>> I checked.
>
> It only matters on hard drives which actually use load-unload heads. Lots
> of desktop/server drives (perhaps some laptop ones as well) still use
> contact start/stop, which doesn't remove the heads from the platters on

I am not so sure about that.

Please correct me if I am wrong, but contact stop in an emergency retract
shakes the head assembly badly as well. It subjects the head assembly to
higher acceleration than a normal seek, and a nasty impulse at impact with
the stopper.  And I very much doubt it is nice to the heads to slide into
the parking zone at high speed and hit the bumper while over it.

Unless I missed something, I don't why an emergency retract would not be as
big a problem as an emergency unload.

Maybe we should hunt down some proper datasheets for drives lacking head
load/unload technology, and check what they say about emergency unloads...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 1/5] pagemap: remove file header

[Matt Mackall]

On Wed, Aug 08, 2007 at 02:31:00AM +0100, Alan Cox wrote:
> O> > The endianness is only useful when examining a raw dump of
> > > pagemap from a different machine when you don't know the
> > > source of the file.  This is pretty rare, and the programs
> > > or scripts doing the copying off-machine can certainly be
> > > made to hold this information.
> 
> Nobody fancies doing bi-endian MIPS ?

Indeed not.
 
> > > The page size is available in userspace at least with libc's
> > > getpagesize().  This will also never vary across processes,
> 
> For now. Its a logical direction however thant we end up with bigger page
> sizes either by hardware or by software merging and end up having
> different page sizes for legacy 32bit binaries.

Blerch.

> > I'd really strongly prefer to have no header. It was added to
> > futureproof the thing.
> 
> The information needed to parse /proc/pid/pagemap can be stuck
> in /proc/pid/somewherelese. If we ever get page size variations and the
> like then /proc/pid/ is going to end up with that information anyway for
> ps and friends to use.

Well if somewhereelse doesn't exist today, programs written today will
break on tomorrow's kernels.

-- 
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: [-mm PATCH 0/9] Memory controller introduction (v4)

[KAMEZAWA Hiroyuki]

On Sat, 28 Jul 2007 01:39:37 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> At OLS, the resource management BOF, it was discussed that we need to manage
> RSS and unmapped page cache together. This patchset is a step towards that
> 
Can I make a question ? Why limiting RSS instead of # of used pages per
container ? Maybe bacause of shared pages between container 
I'm sorry that I don't have much knowledge about history of this work.
If already discussed, the pointer to log is helpful.

Thanks,
-Kame

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

Re: [PATCH] msleep() with hrtimers

[Roman Zippel]

On Tue, 7 Aug 2007, Andrew Morton wrote:

> On Wed, 8 Aug 2007 01:16:49 +0200 (CEST)
> Roman Zippel <[EMAIL PROTECTED]> wrote:
> 
> > Hi,
> > 
> > On Tue, 7 Aug 2007, Andrew Morton wrote:
> > 
> > > I'd be surprised if there was significant overhead - the maximum frequency
> > > at which msleep() can be called is 1000Hz.  We'd need an awful lot of
> > > overhead for that to cause problems, surely?
> > > 
> > > 
> > 
> > _Anybody_ has yet to answer what's wrong with adding a nanosleep() and 
> > using that instead.
> > 
> 
> You mean that the implementation could be simplified if msleep() were to
> simply call do_nanosleep()?

The current msleep is fine and doesn't need any "fixing".
Not all the world is i386, _please_ keep hrtimer usage where it's 
required. Simple timer should be given preference unless the higher 
resolution is really needed, which is not the case here.

> That would work, although a bit of refactoring would be needed so that we
> could implement the TASK_UNINTERRUPTIBLE msleep() that way.

The function is not that big, so below is a nanosleep implementation based 
on Jonathan's patch. This will user give a choice, so there is no need to 
force all users to use hrtimer for a simple sleep.
Please apply this patch instead.

bye, Roman

Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>

---
 include/linux/delay.h |5 +
 kernel/timer.c|   49 +
 2 files changed, 54 insertions(+)

Index: linux-2.6/include/linux/delay.h
===
--- linux-2.6.orig/include/linux/delay.h
+++ linux-2.6/include/linux/delay.h
@@ -9,6 +9,7 @@
 
 extern unsigned long loops_per_jiffy;
 
+#include 
 #include 
 
 /*
@@ -36,6 +37,10 @@ extern unsigned long loops_per_jiffy;
 #endif
 
 void calibrate_delay(void);
+
+void nanosleep(ktime_t time);
+int nanosleep_interruptible(ktime_t *time);
+
 void msleep(unsigned int msecs);
 unsigned long msleep_interruptible(unsigned int msecs);
 
Index: linux-2.6/kernel/timer.c
===
--- linux-2.6.orig/kernel/timer.c
+++ linux-2.6/kernel/timer.c
@@ -1377,3 +1377,52 @@ unsigned long msleep_interruptible(unsig
 }
 
 EXPORT_SYMBOL(msleep_interruptible);
+
+static int do_nanosleep(ktime_t *time, int sigs)
+{
+   enum hrtimer_mode mode = HRTIMER_MODE_REL;
+   int state = sigs ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
+   struct hrtimer_sleeper sleeper;
+
+   hrtimer_init_sleeper(, current);
+   hrtimer_init(, CLOCK_MONOTONIC, mode);
+   sleeper.timer.expires = *time;
+
+   do {
+   set_current_state(state);
+   hrtimer_start(, sleeper.timer.expires, mode);
+   if (sleeper.task)
+   schedule();
+   hrtimer_cancel();
+   mode = HRTIMER_MODE_ABS;
+   if (!sleeper.task)
+   return 1;
+   } while (!sigs || !signal_pending(current));
+
+   *time = sleeper.timer.expires;
+   return 0;
+}
+
+/**
+ * nanosleep - sleep safely even with waitqueue interruptions
+ * @time: Time to sleep for
+ */
+void nanosleep(ktime_t time)
+{
+   do_nanosleep(, 0);
+}
+EXPORT_SYMBOL(nanosleep);
+
+/**
+ * nanosleep_interruptible - sleep waiting for signals
+ * @time: Time to sleep for
+ */
+int nanosleep_interruptible(ktime_t *time)
+{
+   if (do_nanosleep(time, 1))
+   return 1;
+
+   *time = ktime_sub(*time, ktime_get());
+   return 0;
+}
+EXPORT_SYMBOL(nanosleep_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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 04/12] Blackfin arch: Finalize the generic gpio support - add gpio_to_irq and irq_to_gpio

[Bryan Wu]

From: Michael Hennerich <[EMAIL PROTECTED]>

Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 include/asm-blackfin/gpio.h   |   13 +
 include/asm-blackfin/mach-bf533/irq.h |2 ++
 include/asm-blackfin/mach-bf537/irq.h |2 ++
 include/asm-blackfin/mach-bf548/irq.h |2 ++
 include/asm-blackfin/mach-bf561/irq.h |2 ++
 5 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/include/asm-blackfin/gpio.h b/include/asm-blackfin/gpio.h
index 7480cfa..e714363 100644
--- a/include/asm-blackfin/gpio.h
+++ b/include/asm-blackfin/gpio.h
@@ -421,6 +421,19 @@ unsigned short gpio_get_value(unsigned short gpio);
 void gpio_direction_input(unsigned short gpio);
 void gpio_direction_output(unsigned short gpio);
 
+#include   /* cansleep wrappers */
+#include 
+
+static inline int gpio_to_irq(unsigned gpio)
+{
+   return (gpio + GPIO_IRQ_BASE);
+}
+
+static inline int irq_to_gpio(unsigned irq)
+{
+   return (irq - GPIO_IRQ_BASE);
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ARCH_BLACKFIN_GPIO_H__ */
diff --git a/include/asm-blackfin/mach-bf533/irq.h 
b/include/asm-blackfin/mach-bf533/irq.h
index 9879e68..452fb82 100644
--- a/include/asm-blackfin/mach-bf533/irq.h
+++ b/include/asm-blackfin/mach-bf533/irq.h
@@ -128,6 +128,8 @@ CoreEmulation   **
 #define IRQ_PF14   47
 #define IRQ_PF15   48
 
+#define GPIO_IRQ_BASE  IRQ_PF0
+
 #ifdef CONFIG_IRQCHIP_DEMUX_GPIO
 #defineNR_IRQS (IRQ_PF15+1)
 #else
diff --git a/include/asm-blackfin/mach-bf537/irq.h 
b/include/asm-blackfin/mach-bf537/irq.h
index 8af2a83..36c44bc 100644
--- a/include/asm-blackfin/mach-bf537/irq.h
+++ b/include/asm-blackfin/mach-bf537/irq.h
@@ -160,6 +160,8 @@ CoreEmulation   **
 #define IRQ_PH1496
 #define IRQ_PH1597
 
+#define GPIO_IRQ_BASE  IRQ_PF0
+
 #ifdef CONFIG_IRQCHIP_DEMUX_GPIO
 #define NR_IRQS (IRQ_PH15+1)
 #else
diff --git a/include/asm-blackfin/mach-bf548/irq.h 
b/include/asm-blackfin/mach-bf548/irq.h
index e548d3c..21f06f7 100644
--- a/include/asm-blackfin/mach-bf548/irq.h
+++ b/include/asm-blackfin/mach-bf548/irq.h
@@ -337,6 +337,8 @@ Events (highest priority)  EMU 0
 #define IRQ_PJ14   BFIN_PJ_IRQ(14) /* N/A */
 #define IRQ_PJ15   BFIN_PJ_IRQ(15) /* N/A */
 
+#define GPIO_IRQ_BASE  IRQ_PA0
+
 #ifdef CONFIG_IRQCHIP_DEMUX_GPIO
 #define NR_IRQS (IRQ_PJ15+1)
 #else
diff --git a/include/asm-blackfin/mach-bf561/irq.h 
b/include/asm-blackfin/mach-bf561/irq.h
index a753ce7..1278992 100644
--- a/include/asm-blackfin/mach-bf561/irq.h
+++ b/include/asm-blackfin/mach-bf561/irq.h
@@ -289,6 +289,8 @@
 #define IRQ_PF46   119
 #define IRQ_PF47   120
 
+#define GPIO_IRQ_BASE  IRQ_PF0
+
 #ifdef CONFIG_IRQCHIP_DEMUX_GPIO
 #define NR_IRQS(IRQ_PF47 + 1)
 #else
-- 
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 10/12] Blackfin arch: update platform driver resource information to the ezkitBF548 board file

[Bryan Wu]

Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 arch/blackfin/mach-bf548/boards/ezkit.c |  367 ++-
 1 files changed, 366 insertions(+), 1 deletions(-)

diff --git a/arch/blackfin/mach-bf548/boards/ezkit.c 
b/arch/blackfin/mach-bf548/boards/ezkit.c
index 96ad95f..59e64c5 100644
--- a/arch/blackfin/mach-bf548/boards/ezkit.c
+++ b/arch/blackfin/mach-bf548/boards/ezkit.c
@@ -35,9 +35,13 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 /*
  * Name the Board for the /proc/cpuinfo
@@ -48,6 +52,87 @@ char *bfin_board_name = "ADSP-BF548-EZKIT";
  *  Driver needs to know address, irq and flag pin.
  */
 
+#if defined(CONFIG_FB_BF54X_LQ043) || defined(CONFIG_FB_BF54X_LQ043_MODULE)
+
+#include 
+
+static struct bfin_bf54xfb_mach_info bf54x_lq043_data = {
+   .width =480,
+   .height =   272,
+   .xres = {480, 480, 480},
+   .yres = {272, 272, 272},
+   .bpp =  {24, 24, 24},
+   .disp = GPIO_PE3,
+};
+
+static struct resource bf54x_lq043_resources[] = {
+   {
+   .start = IRQ_EPPI0_ERR,
+   .end = IRQ_EPPI0_ERR,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+
+static struct platform_device bf54x_lq043_device = {
+   .name   = "bf54x-lq043",
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(bf54x_lq043_resources),
+   .resource   = bf54x_lq043_resources,
+   .dev= {
+   .platform_data = _lq043_data,
+   },
+};
+#endif
+
+#if defined(CONFIG_KEYBOARD_BFIN) || defined(CONFIG_KEYBOARD_BFIN_MODULE)
+static int bf548_keymap[] = {
+   KEYVAL(0, 0, KEY_ENTER),
+   KEYVAL(0, 1, KEY_HELP),
+   KEYVAL(0, 2, KEY_0),
+   KEYVAL(0, 3, KEY_BACKSPACE),
+   KEYVAL(1, 0, KEY_TAB),
+   KEYVAL(1, 1, KEY_9),
+   KEYVAL(1, 2, KEY_8),
+   KEYVAL(1, 3, KEY_7),
+   KEYVAL(2, 0, KEY_DOWN),
+   KEYVAL(2, 1, KEY_6),
+   KEYVAL(2, 2, KEY_5),
+   KEYVAL(2, 3, KEY_4),
+   KEYVAL(3, 0, KEY_UP),
+   KEYVAL(3, 1, KEY_3),
+   KEYVAL(3, 2, KEY_2),
+   KEYVAL(3, 3, KEY_1),
+};
+
+static struct bfin_kpad_platform_data bf54x_kpad_data = {
+   .rows   = 4,
+   .cols   = 4,
+   .keymap = bf548_keymap,
+   .keymapsize = ARRAY_SIZE(bf548_keymap),
+   .debounce_time  = 5000, /* ns (5ms) */
+   .coldrive_time  = 1000, /* ns (1ms) */
+   .keyup_test_interval= 50, /* ms (50ms) */
+};
+
+static struct resource bf54x_kpad_resources[] = {
+   {
+   .start = IRQ_KEY,
+   .end = IRQ_KEY,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+
+static struct platform_device bf54x_kpad_device = {
+   .name   = "bf54x-keys",
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(bf54x_kpad_resources),
+   .resource   = bf54x_kpad_resources,
+   .dev= {
+   .platform_data = _kpad_data,
+   },
+};
+#endif
+
 #if defined(CONFIG_RTC_DRV_BFIN) || defined(CONFIG_RTC_DRV_BFIN_MODULE)
 static struct platform_device rtc_device = {
.name = "rtc-bfin",
@@ -94,6 +179,248 @@ static struct platform_device bfin_uart_device = {
 };
 #endif
 
+#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
+static struct resource smsc911x_resources[] = {
+   {
+   .name = "smsc911x-memory",
+   .start = 0x2400,
+   .end = 0x2400 + 0xFF,
+   .flags = IORESOURCE_MEM,
+   },
+   {
+   .start = IRQ_PE8,
+   .end = IRQ_PE8,
+   .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
+   },
+};
+static struct platform_device smsc911x_device = {
+   .name = "smsc911x",
+   .id = 0,
+   .num_resources = ARRAY_SIZE(smsc911x_resources),
+   .resource = smsc911x_resources,
+};
+#endif
+
+#if defined(CONFIG_USB_BF54x_HCD) || defined(CONFIG_USB_BF54x_HCD_MODULE)
+static struct resource bf54x_hcd_resources[] = {
+   {
+   .start = 0xFFC03C00,
+   .end = 0xFFC040FF,
+   .flags = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device bf54x_hcd = {
+   .name = "bf54x-hcd",
+   .id = 0,
+   .num_resources = ARRAY_SIZE(bf54x_hcd_resources),
+   .resource = bf54x_hcd_resources,
+};
+#endif
+
+#if defined(CONFIG_PATA_BF54X) || defined(CONFIG_PATA_BF54X_MODULE)
+static struct resource bfin_atapi_resources[] = {
+   {
+   .start = 0xFFC03800,
+   .end = 0xFFC0386F,
+   .flags = IORESOURCE_MEM,
+   },
+   {
+   .start = IRQ_ATAPI_ERR,
+   .end = IRQ_ATAPI_ERR,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+
+static struct platform_device bfin_atapi_device = {
+   .name = "bf54x-atapi",
+   .id = -1,

[PATCH 11/12] Blackfin arch: after removing fs.h from mm.h, fix the broken on Blackfin arch.

[Bryan Wu]

Cc: Alexey Dobriyan <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 arch/blackfin/kernel/init_task.c |1 +
 arch/blackfin/kernel/process.c   |2 ++
 arch/blackfin/kernel/sys_bfin.c  |1 +
 arch/blackfin/kernel/traps.c |1 +
 4 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/blackfin/kernel/init_task.c b/arch/blackfin/kernel/init_task.c
index b45188f..673c860 100644
--- a/arch/blackfin/kernel/init_task.c
+++ b/arch/blackfin/kernel/init_task.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static struct fs_struct init_fs = INIT_FS;
 static struct files_struct init_files = INIT_FILES;
diff --git a/arch/blackfin/kernel/process.c b/arch/blackfin/kernel/process.c
index 5a51dd6..6a7aefe 100644
--- a/arch/blackfin/kernel/process.c
+++ b/arch/blackfin/kernel/process.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
diff --git a/arch/blackfin/kernel/sys_bfin.c b/arch/blackfin/kernel/sys_bfin.c
index f5e1ae3..abcd148 100644
--- a/arch/blackfin/kernel/sys_bfin.c
+++ b/arch/blackfin/kernel/sys_bfin.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/blackfin/kernel/traps.c b/arch/blackfin/kernel/traps.c
index 8766bd6..792a841 100644
--- a/arch/blackfin/kernel/traps.c
+++ b/arch/blackfin/kernel/traps.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 09/12] Blackfin arch: scrub remaining ASSEMBLY usage since the switch to __ASSEMBLY__

[Bryan Wu]

From: Mike Frysinger <[EMAIL PROTECTED]>

Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 include/asm-blackfin/mach-bf533/blackfin.h |2 +-
 include/asm-blackfin/mach-bf537/blackfin.h |2 +-
 include/asm-blackfin/mach-bf548/blackfin.h |2 +-
 include/asm-blackfin/mach-bf561/blackfin.h |2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/asm-blackfin/mach-bf533/blackfin.h 
b/include/asm-blackfin/mach-bf533/blackfin.h
index e438449..f3b240a 100644
--- a/include/asm-blackfin/mach-bf533/blackfin.h
+++ b/include/asm-blackfin/mach-bf533/blackfin.h
@@ -38,7 +38,7 @@
 #include "defBF532.h"
 #include "anomaly.h"
 
-#if !(defined(__ASSEMBLY__) || defined(ASSEMBLY))
+#if !defined(__ASSEMBLY__)
 #include "cdefBF532.h"
 #endif
 
diff --git a/include/asm-blackfin/mach-bf537/blackfin.h 
b/include/asm-blackfin/mach-bf537/blackfin.h
index bbd9705..f196588 100644
--- a/include/asm-blackfin/mach-bf537/blackfin.h
+++ b/include/asm-blackfin/mach-bf537/blackfin.h
@@ -43,7 +43,7 @@
 #include "defBF537.h"
 #endif
 
-#if !(defined(__ASSEMBLY__) || defined(ASSEMBLY))
+#if !defined(__ASSEMBLY__)
 #include "cdefBF534.h"
 
 /* UART 0*/
diff --git a/include/asm-blackfin/mach-bf548/blackfin.h 
b/include/asm-blackfin/mach-bf548/blackfin.h
index 791218f..19e84dd 100644
--- a/include/asm-blackfin/mach-bf548/blackfin.h
+++ b/include/asm-blackfin/mach-bf548/blackfin.h
@@ -54,7 +54,7 @@
 #include "defBF549.h"
 #endif
 
-#if !(defined(__ASSEMBLY__) || defined(ASSEMBLY))
+#if !defined(__ASSEMBLY__)
 #ifdef CONFIG_BF542
 #include "cdefBF542.h"
 #endif
diff --git a/include/asm-blackfin/mach-bf561/blackfin.h 
b/include/asm-blackfin/mach-bf561/blackfin.h
index 2537c84..562aee3 100644
--- a/include/asm-blackfin/mach-bf561/blackfin.h
+++ b/include/asm-blackfin/mach-bf561/blackfin.h
@@ -38,7 +38,7 @@
 #include "defBF561.h"
 #include "anomaly.h"
 
-#if !(defined(__ASSEMBLY__) || defined(ASSEMBLY))
+#if !defined(__ASSEMBLY__)
 #include "cdefBF561.h"
 #endif
 
-- 
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 05/12] Blackfin arch: Advertise GENERIC_GPIO and remove duplicated GENERIC_CALIBRATE_DELAY

[Bryan Wu]

From: Michael Hennerich <[EMAIL PROTECTED]>

Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 arch/blackfin/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index 017defa..5c1e215 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -57,7 +57,7 @@ config GENERIC_TIME
bool
default n
 
-config GENERIC_CALIBRATE_DELAY
+config GENERIC_GPIO
bool
default y
 
-- 
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 06/12] Blackfin arch: Add PORT_J.High (needed for BF548-EZkit Touchscreen interrupts) - remove PORT_C.H

[Bryan Wu]

From: Michael Hennerich <[EMAIL PROTECTED]>

Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 arch/blackfin/mach-bf548/Kconfig |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/blackfin/mach-bf548/Kconfig b/arch/blackfin/mach-bf548/Kconfig
index e78b03d..3976b7f 100644
--- a/arch/blackfin/mach-bf548/Kconfig
+++ b/arch/blackfin/mach-bf548/Kconfig
@@ -282,7 +282,7 @@ menu "Assignment"
 
 config PINTx_REASSIGN
bool "Reprogram PINT Assignment"
-   default n
+   default y
help
  The interrupt assignment registers controls the pin-to-interrupt
  assignment in a byte-wide manner. Each option allows you to select
@@ -303,7 +303,7 @@ config PINT1_ASSIGN
 config PINT2_ASSIGN
hex "PINT2_ASSIGN"
depends on PINTx_REASSIGN
-   default 0x0101
+   default 0x07000101
 config PINT3_ASSIGN
hex "PINT3_ASSIGN"
depends on PINTx_REASSIGN
-- 
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 01/12] Blackfin arch: add peripheral resource allocation support

[Bryan Wu]

From: Michael Hennerich <[EMAIL PROTECTED]>

Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 arch/blackfin/kernel/bfin_gpio.c  |  272 ++---
 include/asm-blackfin/mach-bf533/bfin_serial_5xx.h |   11 +-
 include/asm-blackfin/mach-bf537/bfin_serial_5xx.h |   23 +-
 include/asm-blackfin/mach-bf537/portmux.h |2 +-
 include/asm-blackfin/mach-bf561/bfin_serial_5xx.h |   11 +-
 5 files changed, 274 insertions(+), 45 deletions(-)

diff --git a/arch/blackfin/kernel/bfin_gpio.c b/arch/blackfin/kernel/bfin_gpio.c
index bafcfa5..9f30948 100644
--- a/arch/blackfin/kernel/bfin_gpio.c
+++ b/arch/blackfin/kernel/bfin_gpio.c
@@ -84,6 +84,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef BF533_FAMILY
@@ -115,7 +116,11 @@ static struct gpio_port_t 
*gpio_bankb[gpio_bank(MAX_BLACKFIN_GPIOS)] = {
 };
 #endif
 
-static unsigned short reserved_map[gpio_bank(MAX_BLACKFIN_GPIOS)];
+static unsigned short reserved_gpio_map[gpio_bank(MAX_BLACKFIN_GPIOS)];
+static unsigned short reserved_peri_map[gpio_bank(MAX_BLACKFIN_GPIOS + 16)];
+char *str_ident = NULL;
+
+#define RESOURCE_LABEL_SIZE 16
 
 #ifdef CONFIG_PM
 static unsigned short wakeup_map[gpio_bank(MAX_BLACKFIN_GPIOS)];
@@ -143,13 +148,39 @@ inline int check_gpio(unsigned short gpio)
return 0;
 }
 
+static void set_label(unsigned short ident, const char *label)
+{
+
+   if (label && str_ident) {
+   strncpy(str_ident + ident * RESOURCE_LABEL_SIZE, label,
+RESOURCE_LABEL_SIZE);
+   str_ident[ident * RESOURCE_LABEL_SIZE +
+RESOURCE_LABEL_SIZE - 1] = 0;
+   }
+}
+
+static char *get_label(unsigned short ident)
+{
+   if (!str_ident)
+   return "UNKNOWN";
+
+   return (str_ident[ident * RESOURCE_LABEL_SIZE] ?
+   (str_ident + ident * RESOURCE_LABEL_SIZE) : "UNKNOWN");
+}
+
+static int cmp_label(unsigned short ident, const char *label)
+{
+   if (label && str_ident)
+   return strncmp(str_ident + ident * RESOURCE_LABEL_SIZE,
+label, strlen(label));
+   else
+   return -EINVAL;
+}
+
 #ifdef BF537_FAMILY
 static void port_setup(unsigned short gpio, unsigned short usage)
 {
if (usage == GPIO_USAGE) {
-   if (*port_fer[gpio_bank(gpio)] & gpio_bit(gpio))
-   printk(KERN_WARNING "bfin-gpio: Possible Conflict with 
Peripheral "
-  "usage and GPIO %d detected!\n", gpio);
*port_fer[gpio_bank(gpio)] &= ~gpio_bit(gpio);
} else
*port_fer[gpio_bank(gpio)] |= gpio_bit(gpio);
@@ -159,6 +190,56 @@ static void port_setup(unsigned short gpio, unsigned short 
usage)
 # define port_setup(...)  do { } while (0)
 #endif
 
+#ifdef BF537_FAMILY
+
+#define PMUX_LUT_RES   0
+#define PMUX_LUT_OFFSET1
+#define PMUX_LUT_ENTRIES   41
+#define PMUX_LUT_SIZE  2
+
+static unsigned short port_mux_lut[PMUX_LUT_ENTRIES][PMUX_LUT_SIZE] = {
+   {P_PPI0_D13, 11}, {P_PPI0_D14, 11}, {P_PPI0_D15, 11},
+   {P_SPORT1_TFS, 11}, {P_SPORT1_TSCLK, 11}, {P_SPORT1_DTPRI, 11},
+   {P_PPI0_D10, 10}, {P_PPI0_D11, 10}, {P_PPI0_D12, 10},
+   {P_SPORT1_RSCLK, 10}, {P_SPORT1_RFS, 10}, {P_SPORT1_DRPRI, 10},
+   {P_PPI0_D8, 9}, {P_PPI0_D9, 9}, {P_SPORT1_DRSEC, 9},
+   {P_SPORT1_DTSEC, 9}, {P_TMR2, 8}, {P_PPI0_FS3, 8}, {P_TMR3, 7},
+   {P_SPI0_SSEL4, 7}, {P_TMR4, 6}, {P_SPI0_SSEL5, 6}, {P_TMR5, 5},
+   {P_SPI0_SSEL6, 5}, {P_UART1_RX, 4}, {P_UART1_TX, 4}, {P_TMR6, 4},
+   {P_TMR7, 4}, {P_UART0_RX, 3}, {P_UART0_TX, 3}, {P_DMAR0, 3},
+   {P_DMAR1, 3}, {P_SPORT0_DTSEC, 1}, {P_SPORT0_DRSEC, 1},
+   {P_CAN0_RX, 1}, {P_CAN0_TX, 1}, {P_SPI0_SSEL7, 1},
+   {P_SPORT0_TFS, 0}, {P_SPORT0_DTPRI, 0}, {P_SPI0_SSEL2, 0},
+   {P_SPI0_SSEL3, 0}
+};
+
+static void portmux_setup(unsigned short per, unsigned short function)
+{
+   u16 y, muxreg, offset;
+
+   for (y = 0; y < PMUX_LUT_ENTRIES; y++) {
+   if (port_mux_lut[y][PMUX_LUT_RES] == per) {
+
+   /* SET PORTMUX REG */
+
+   offset = port_mux_lut[y][PMUX_LUT_OFFSET];
+   muxreg = bfin_read_PORT_MUX();
+
+   if (offset != 1) {
+   muxreg &= ~(1 << offset);
+   } else {
+   muxreg &= ~(3 << 1);
+   }
+
+   muxreg |= (function << offset);
+   bfin_write_PORT_MUX(muxreg);
+   }
+   }
+}
+
+#else
+# define portmux_setup(...)  do { } while (0)
+#endif
 
 static void default_gpio(unsigned short gpio)
 {
@@ -179,22 +260,15 @@ static void default_gpio(unsigned short gpio)
 
 static int __init bfin_gpio_init(void)
 {
-   int i;
-
-   printk(KERN_INFO "Blackfin GPIO 

[PATCH 02/12] Blackfin arch: Add label to call new GPIO API

[Bryan Wu]

From: Michael Hennerich <[EMAIL PROTECTED]>

Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 arch/blackfin/mach-common/ints-priority-dc.c |4 ++--
 arch/blackfin/mach-common/ints-priority-sc.c |8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/blackfin/mach-common/ints-priority-dc.c 
b/arch/blackfin/mach-common/ints-priority-dc.c
index 660f881..d5d9e57 100644
--- a/arch/blackfin/mach-common/ints-priority-dc.c
+++ b/arch/blackfin/mach-common/ints-priority-dc.c
@@ -221,7 +221,7 @@ static unsigned int bf561_gpio_irq_startup(unsigned int irq)
 
if (!(gpio_enabled[gpio_bank(gpionr)] & gpio_bit(gpionr))) {
 
-   ret = gpio_request(gpionr, NULL);
+   ret = gpio_request(gpionr, "IRQ");
if (ret)
return ret;
 
@@ -261,7 +261,7 @@ static int bf561_gpio_irq_type(unsigned int irq, unsigned 
int type)
 
if (!(gpio_enabled[gpio_bank(gpionr)] & gpio_bit(gpionr))) {
 
-   ret = gpio_request(gpionr, NULL);
+   ret = gpio_request(gpionr, "IRQ");
if (ret)
return ret;
 
diff --git a/arch/blackfin/mach-common/ints-priority-sc.c 
b/arch/blackfin/mach-common/ints-priority-sc.c
index 4708023..505b948 100644
--- a/arch/blackfin/mach-common/ints-priority-sc.c
+++ b/arch/blackfin/mach-common/ints-priority-sc.c
@@ -343,7 +343,7 @@ static unsigned int bfin_gpio_irq_startup(unsigned int irq)
u16 gpionr = irq - IRQ_PF0;
 
if (!(gpio_enabled[gpio_bank(gpionr)] & gpio_bit(gpionr))) {
-   ret = gpio_request(gpionr, NULL);
+   ret = gpio_request(gpionr, "IRQ");
if (ret)
return ret;
}
@@ -377,7 +377,7 @@ static int bfin_gpio_irq_type(unsigned int irq, unsigned 
int type)
if (type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING |
IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW)) {
if (!(gpio_enabled[gpio_bank(gpionr)] & gpio_bit(gpionr))) {
-   ret = gpio_request(gpionr, NULL);
+   ret = gpio_request(gpionr, "IRQ");
if (ret)
return ret;
}
@@ -587,7 +587,7 @@ static unsigned int bfin_gpio_irq_startup(unsigned int irq)
}
 
if (!(gpio_enabled[gpio_bank(gpionr)] & gpio_bit(gpionr))) {
-   ret = gpio_request(gpionr, NULL);
+   ret = gpio_request(gpionr, "IRQ");
if (ret)
return ret;
}
@@ -627,7 +627,7 @@ static int bfin_gpio_irq_type(unsigned int irq, unsigned 
int type)
if (type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING |
IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW)) {
if (!(gpio_enabled[gpio_bank(gpionr)] & gpio_bit(gpionr))) {
-   ret = gpio_request(gpionr, NULL);
+   ret = gpio_request(gpionr, "IRQ");
if (ret)
return ret;
}
-- 
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 00/12] Blackfin arch GPIO updating

[Bryan Wu]

As David mentioned, I send out these series patch to LKML for review.
These patches are related Blackfin arch GPIO updating, not big change at all.
I think it is OK for git-pull in -RC2 or later.

Thanks
- Bryan Wu

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 12/12] Blackfin serial driver: use new GPIO API

[Bryan Wu]

From: Michael Hennerich <[EMAIL PROTECTED]>

Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 include/asm-blackfin/mach-bf548/bfin_serial_5xx.h |   39 ++---
 1 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/include/asm-blackfin/mach-bf548/bfin_serial_5xx.h 
b/include/asm-blackfin/mach-bf548/bfin_serial_5xx.h
index 2f4afc9..f21a162 100644
--- a/include/asm-blackfin/mach-bf548/bfin_serial_5xx.h
+++ b/include/asm-blackfin/mach-bf548/bfin_serial_5xx.h
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 
 #define NR_PORTS   4
 
@@ -143,50 +144,48 @@ struct bfin_serial_res bfin_serial_resource[] = {
 
 int nr_ports = ARRAY_SIZE(bfin_serial_resource);
 
+#define DRIVER_NAME "bfin-uart"
+
 static void bfin_serial_hw_init(struct bfin_serial_port *uart)
 {
 #ifdef CONFIG_SERIAL_BFIN_UART0
-   /* Enable UART0 RX and TX on pin 7 & 8 of PORT E */
-   bfin_write_PORTE_FER(0x180 | bfin_read_PORTE_FER());
-   bfin_write_PORTE_MUX(0x3C000 | bfin_read_PORTE_MUX());
+   peripheral_request(P_UART0_TX, DRIVER_NAME);
+   peripheral_request(P_UART0_RX, DRIVER_NAME);
 #endif
 
 #ifdef CONFIG_SERIAL_BFIN_UART1
-   /* Enable UART1 RX and TX on pin 0 & 1 of PORT H */
-   bfin_write_PORTH_FER(0x3 | bfin_read_PORTH_FER());
-   bfin_write_PORTH_MUX(~0xF & bfin_read_PORTH_MUX());
+   peripheral_request(P_UART1_TX, DRIVER_NAME);
+   peripheral_request(P_UART1_RX, DRIVER_NAME);
+
 #ifdef CONFIG_BFIN_UART1_CTSRTS
-   /* Enable UART1 RTS and CTS on pin 9 & 10 of PORT E */
-   bfin_write_PORTE_FER(0x600 | bfin_read_PORTE_FER());
-   bfin_write_PORTE_MUX(~0x3C & bfin_read_PORTE_MUX());
+   peripheral_request(P_UART1_RTS, DRIVER_NAME);
+   peripheral_request(P_UART1_CTS DRIVER_NAME);
 #endif
 #endif
 
 #ifdef CONFIG_SERIAL_BFIN_UART2
-   /* Enable UART2 RX and TX on pin 4 & 5 of PORT B */
-   bfin_write_PORTB_FER(0x30 | bfin_read_PORTB_FER());
-   bfin_write_PORTB_MUX(~0xF00 & bfin_read_PORTB_MUX());
+   peripheral_request(P_UART2_TX, DRIVER_NAME);
+   peripheral_request(P_UART2_RX, DRIVER_NAME);
 #endif
 
 #ifdef CONFIG_SERIAL_BFIN_UART3
-   /* Enable UART3 RX and TX on pin 6 & 7 of PORT B */
-   bfin_write_PORTB_FER(0xC0 | bfin_read_PORTB_FER());
-   bfin_write_PORTB_MUX(~0xF000 | bfin_read_PORTB_MUX());
+   peripheral_request(P_UART3_TX, DRIVER_NAME);
+   peripheral_request(P_UART3_RX, DRIVER_NAME);
+
 #ifdef CONFIG_BFIN_UART3_CTSRTS
-   /* Enable UART3 RTS and CTS on pin 2 & 3 of PORT B */
-   bfin_write_PORTB_FER(0xC | bfin_read_PORTB_FER());
-   bfin_write_PORTB_MUX(~0xF0 | bfin_read_PORTB_MUX());
+   peripheral_request(P_UART3_RTS, DRIVER_NAME);
+   peripheral_request(P_UART3_CTS DRIVER_NAME);
 #endif
 #endif
SSYNC();
 #ifdef CONFIG_SERIAL_BFIN_CTSRTS
if (uart->cts_pin >= 0) {
-   gpio_request(uart->cts_pin, NULL);
+   gpio_request(uart->cts_pin, DRIVER_NAME);
gpio_direction_input(uart->cts_pin);
}
 
if (uart->rts_pin >= 0) {
-   gpio_request(uart->rts_pin, NULL);
+   gpio_request(uart->rts_pin, DRIVER_NAME);
gpio_direction_output(uart->rts_pin);
}
 #endif
-- 
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 03/12] Blackfin arch: fix PORT_J BUG for BF537/6 EMAC driver

[Bryan Wu]

From: Michael Hennerich <[EMAIL PROTECTED]>

Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 arch/blackfin/kernel/bfin_gpio.c  |   19 +--
 include/asm-blackfin/mach-bf537/portmux.h |   35 -
 2 files changed, 45 insertions(+), 9 deletions(-)

diff --git a/arch/blackfin/kernel/bfin_gpio.c b/arch/blackfin/kernel/bfin_gpio.c
index 9f30948..5d488ef 100644
--- a/arch/blackfin/kernel/bfin_gpio.c
+++ b/arch/blackfin/kernel/bfin_gpio.c
@@ -180,11 +180,13 @@ static int cmp_label(unsigned short ident, const char 
*label)
 #ifdef BF537_FAMILY
 static void port_setup(unsigned short gpio, unsigned short usage)
 {
-   if (usage == GPIO_USAGE) {
-   *port_fer[gpio_bank(gpio)] &= ~gpio_bit(gpio);
-   } else
-   *port_fer[gpio_bank(gpio)] |= gpio_bit(gpio);
-   SSYNC();
+   if (!check_gpio(gpio)) {
+   if (usage == GPIO_USAGE) {
+   *port_fer[gpio_bank(gpio)] &= ~gpio_bit(gpio);
+   } else
+   *port_fer[gpio_bank(gpio)] |= gpio_bit(gpio);
+   SSYNC();
+   }
 }
 #else
 # define port_setup(...)  do { } while (0)
@@ -644,11 +646,10 @@ int peripheral_request(unsigned short per, const char 
*label)
if (!(per & P_DEFINED))
return -ENODEV;
 
-   if (check_gpio(ident) < 0)
-   return -EINVAL;
-
local_irq_save(flags);
 
+   if (!check_gpio(ident)) {
+
if (unlikely(reserved_gpio_map[gpio_bank(ident)] & gpio_bit(ident))) {
printk(KERN_ERR
   "%s: Peripheral %d is already reserved as GPIO by %s 
!\n",
@@ -658,6 +659,8 @@ int peripheral_request(unsigned short per, const char 
*label)
return -EBUSY;
}
 
+   }
+
if (unlikely(reserved_peri_map[gpio_bank(ident)] & gpio_bit(ident))) {
 
/*
diff --git a/include/asm-blackfin/mach-bf537/portmux.h 
b/include/asm-blackfin/mach-bf537/portmux.h
index 7daa247..ae6c53b 100644
--- a/include/asm-blackfin/mach-bf537/portmux.h
+++ b/include/asm-blackfin/mach-bf537/portmux.h
@@ -106,4 +106,37 @@
 #define P_SPI0_SSEL2   (P_DEFINED | P_IDENT(PORT_PJ11) | P_FUNCT(1))
 #define P_SPI0_SSEL7   (P_DEFINED | P_IDENT(PORT_PJ5) | P_FUNCT(2))
 
-#endif /* _MACH_PORTMUX_H_ */
+#define P_MII0 {\
+   P_MII0_ETxD0, \
+   P_MII0_ETxD1, \
+   P_MII0_ETxD2, \
+   P_MII0_ETxD3, \
+   P_MII0_ETxEN, \
+   P_MII0_TxCLK, \
+   P_MII0_PHYINT, \
+   P_MII0_COL, \
+   P_MII0_ERxD0, \
+   P_MII0_ERxD1, \
+   P_MII0_ERxD2, \
+   P_MII0_ERxD3, \
+   P_MII0_ERxDV, \
+   P_MII0_ERxCLK, \
+   P_MII0_ERxER, \
+   P_MII0_CRS, \
+   P_MDC, \
+   P_MDIO, 0}
+
+
+#define P_RMII0 {\
+   P_MII0_ETxD0, \
+   P_MII0_ETxD1, \
+   P_MII0_ETxEN, \
+   P_MII0_ERxD0, \
+   P_MII0_ERxD1, \
+   P_MII0_ERxER, \
+   P_RMII0_REF_CLK, \
+   P_RMII0_MDINT, \
+   P_RMII0_CRS_DV, \
+   P_MDC, \
+   P_MDIO, 0}
+#endif /* _MACH_PORTMUX_H_ */
-- 
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 07/12] Blackfin arch: bug fixing, add missing BF533_FAMILY GPIO_PFx definition

[Bryan Wu]

Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 include/asm-blackfin/gpio.h |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/include/asm-blackfin/gpio.h b/include/asm-blackfin/gpio.h
index e714363..dd203cd 100644
--- a/include/asm-blackfin/gpio.h
+++ b/include/asm-blackfin/gpio.h
@@ -144,6 +144,24 @@
 
 #ifdef BF533_FAMILY
 #define MAX_BLACKFIN_GPIOS 16
+
+#defineGPIO_PF00
+#defineGPIO_PF11
+#defineGPIO_PF22
+#defineGPIO_PF33
+#defineGPIO_PF44
+#defineGPIO_PF55
+#defineGPIO_PF66
+#defineGPIO_PF77
+#defineGPIO_PF88
+#defineGPIO_PF99
+#defineGPIO_PF10   10
+#defineGPIO_PF11   11
+#defineGPIO_PF12   12
+#defineGPIO_PF13   13
+#defineGPIO_PF14   14
+#defineGPIO_PF15   15
+
 #endif
 
 #ifdef BF537_FAMILY
-- 
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 08/12] Blackfin arch: add missing gpio error handling to make sure we roll back requests in case one fails

[Bryan Wu]

From: Michael Hennerich <[EMAIL PROTECTED]>

Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 arch/blackfin/kernel/bfin_gpio.c |   10 --
 arch/blackfin/mach-bf548/gpio.c  |   11 +--
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/arch/blackfin/kernel/bfin_gpio.c b/arch/blackfin/kernel/bfin_gpio.c
index 5d488ef..f712772 100644
--- a/arch/blackfin/kernel/bfin_gpio.c
+++ b/arch/blackfin/kernel/bfin_gpio.c
@@ -711,9 +711,15 @@ int peripheral_request_list(unsigned short per[], const 
char *label)
int ret;
 
for (cnt = 0; per[cnt] != 0; cnt++) {
+
ret = peripheral_request(per[cnt], label);
-   if (ret < 0)
-   return ret;
+
+   if (ret < 0) {
+   for ( ; cnt > 0; cnt--) {
+   peripheral_free(per[cnt - 1]);
+   }
+   return ret;
+   }
}
 
return 0;
diff --git a/arch/blackfin/mach-bf548/gpio.c b/arch/blackfin/mach-bf548/gpio.c
index c073ab3..f3b9dea 100644
--- a/arch/blackfin/mach-bf548/gpio.c
+++ b/arch/blackfin/mach-bf548/gpio.c
@@ -212,11 +212,18 @@ int peripheral_request_list(unsigned short per[], const 
char *label)
int ret;
 
for (cnt = 0; per[cnt] != 0; cnt++) {
+
ret = peripheral_request(per[cnt], label);
-   if (ret < 0)
-   return ret;
+
+   if (ret < 0) {
+   for ( ; cnt > 0; cnt--) {
+   peripheral_free(per[cnt - 1]);
+   }
+   return ret;
+   }
}
 
+
return 0;
 }
 EXPORT_SYMBOL(peripheral_request_list);
-- 
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/RFT] finish i386 and x86-64 sysdata conversion

[Yinghai Lu]

On 8/7/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> My PCI domains patch add support for multiple peer root buses.  That's
> the definition of PCI domain support.

one one segment, we can not have multi peer root buses?

>
> Branch 'pciseg' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git

is your test system based AMD opteron..., and have io device on other
node/link, and use mmconfig to access that root bus on different
segment?

I used to think that we need bigSMP to support pci segments on AMD platfrom.

YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 missing newlines to some uses of dev_ messages

[Nish Aravamudan]

On 8/7/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> Found these while looking at printk uses.
>
> Add missing newlines to dev_ uses
> Add missing KERN_ prefixes to multiline dev_s
> Fixed a wierd->weird spelling typo
> Added a newline to a printk

I think these should have been split logically into 4 groups of
patches (except perhaps where they touched the same file for the first
two and the last).

The third type should go through trivial.

And they should have been split logically by subsystem, most likely?



> diff --git a/arch/ia64/sn/kernel/xpnet.c b/arch/ia64/sn/kernel/xpnet.c
> index e58fcad..a5df672 100644
> --- a/arch/ia64/sn/kernel/xpnet.c
> +++ b/arch/ia64/sn/kernel/xpnet.c
> @@ -269,8 +269,9 @@ xpnet_receive(partid_t partid, int channel, struct 
> xpnet_message *msg)
> skb->protocol = eth_type_trans(skb, xpnet_device);
> skb->ip_summed = CHECKSUM_UNNECESSARY;
>
> -   dev_dbg(xpnet, "passing skb to network layer; \n\tskb->head=0x%p "
> -   "skb->data=0x%p skb->tail=0x%p skb->end=0x%p skb->len=%d\n",
> +   dev_dbg(xpnet, "passing skb to network layer\n"
> +   KERN_DEBUG "\tskb->head=0x%p skb->data=0x%p skb->tail=0x%p "
> +   "skb->end=0x%p skb->len=%d\n",
> (void *)skb->head, (void *)skb->data, skb_tail_pointer(skb),
> skb_end_pointer(skb), skb->len);



I'm not a maintainer of any code by any means, but it seems odd,
redundant and visually confusing to me to use the dev_dbg() function
and have KERN_DEBUG's inside the string -- makes me question every
time why there isn't one for the first line too.

Perhaps these multi-line debug statements should simply be split into
multiple dev_dbg() calls? Similar for the other dev_ functions. I
think it might look cleaner, at least. Just my two cents, not a NAK or
anything.

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: Disk spin down issue on shut down/suspend to disk

[Tejun Heo]

Rafael J. Wysocki wrote:
> Well, on my box (nx6325) with the appended (experimental) patch applied
> on top of 2.6.23-rc1 with the patchset from
> http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , the
> double spin down doesn't occur during hibernation and the system is shut down
> notceably faster.

Can you please explain what the patch does?  So, I take it that entering
S4 also spins down the disk.  Does the patch remove the ACPI spin down
or libata one?

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

Re: Disk spin down issue on shut down/suspend to disk

[Tejun Heo]

Michael Sedkowski wrote:
> I did some additional checking today...
> On kernels prior to 2.6.22 line, the bug exists and manifests itself
> exactly the same way. However, when I removed the "-h" flag
> from /etc/init.d/halt, the drive spins down only once on "Power down"
> message and there is no sign of the bug and the emergency unload count
> remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4;
> 2.6.18-4-686-Etch.
> The obvious conclusion is that something must have changed it the 2.6.22
> kernels, so that removing the "-h" has no effect.
> I dunno if my observations are of any value, but I thought You should
> know...

Yeah, till 2.6.22, libata didn't spindown disks on suspend or power off
which incremented emergency unload count on all normal systems, so only
the ACPI S5 routine is spinning down the disk on you system.  The
problem here is that now that libata is fixed there are two entities
trying to spin down the disk and the disk is dumb enough to spin back up
when FLUSH CACHE or STANDBYNOW is received while spun down.  :-(

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/

Re: Linux 2.6.23-rc2

[Jeff Chua]

On 8/8/07, David Weinehall <[EMAIL PROTECTED]> wrote:

> Try adding acpi_sleep=s3_bios to your kernel boot options and see if it
> helps.

I tried, but that didn't help.

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

Make checkpatch warn about pointless casting of kalloc returns.

[Dave Jones]

Make checkpatch warn about pointless casting of kalloc returns.

Signed-off-by: Dave Jones <[EMAIL PROTECTED]>

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 73751ab..c6cae6a 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1051,6 +1051,11 @@ sub process {
CHK("__setup appears un-documented -- check 
Documentation/kernel-parameters.txt\n" . $herecurr);
}
}
+
+# check for pointless casting of kmalloc return
+   if ($rawline =~ /\*\)[ ]k[czm]alloc/) {
+   WARN("No need to cast return value.\n");
+   }
}
 
if ($chk_patch && !$is_patch) {
-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial inter-character timeout usage with async io

[Harvey Chapman]

Harvey Chapman wrote:
> just don't identify it specifically. In the ISRs, they simply check to
> see if any of bits 1, 2, or 3 are set. In the example above, on the last

Well, not entirely true, it actually checks bit 0 which indicates that
there was an interrupt, period. Bits 1, 2, and 3 indicate why the
interrupt occurred, but 8250.c and pxa.c ignore those bits.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: why are some atomic_t's not volatile, while most are?

[Jerry Jiang]

On Tue, 07 Aug 2007 16:32:23 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:

> > It seems like this would fall more into the case of the arch providing 
> > guarantees when using locked/atomic access rather than anything 
> > SMP-related, no?.
> 
> But if you're not using SMP, the only way you get a race condition is if your 
> compiler is reordering instructions that have side effects which are 
> invisible 
> to the compiler.  This can happen with MMIO registers, but it's not an issue 
> with an atomic_t we're declaring in real memory.
> 

Under non-SMP, some compilers would reordering instructions as they think
and C standard informally guarantees all operations on volatile data
are executed in the sequence in which they appear in the source code,
right?

So no reordering happens with volatile, right?

-- Jerry

>   -- 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: allow non root users to set io priority "idle" ?

[Lee Revell]

On 06 Aug 2007 13:11:01 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> For IO I suppose the same could happen too. e.g. low priority
> task wants to write out a page and keeps it locked until the IO
> is finished. High priority task wants to access the page and has
> to wait until it is unlocked. Middle task generates an endless
> stream of IO that makes the idle priority writeout never finish.

I don't think it's a problem for high priority (RT) tasks - it's well
known in the real time Linux community that you never, ever do IO from
a thread that has to satisfy RT constraints.  A correct RT linux app
does its IO from a SCHED_NORMAL thread, with *plenty* of buffering,
and feeds the RT constrained SCHED_FIFO threads using a lock free
ringbuffer.

SCHED_IDLE starving SCHED_NORMAL is an issue of course.  But
SCHED_IDLE seems a lot more useful for read than write which I would
expect to take fewer locks.  For example I'd expect Beagle to want to
read at SCHED_IDLE but write out its indices at SCHED_NORMAL.

Would it make any sense to allow anyone to set SCHED_IDLE for reads
but require root to change IO priority for writes?

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

Re: [PATCH] serial inter-character timeout usage with async io

[Harvey Chapman]

Alan Cox wrote:
> What are you actually trying to achieve ?

I'm trying to reduce the load on embedded systems running Linux and
using serial ports.

I'm trying to alleviate the following typical software scenario:

A Linux program is connected via serial port to some other serial device
using asynchronous I/O and the other serial device sends a 150 byte
sequence to the Linux program. The Linux program will receive 18
intermediate SIGIOs (one for each 8-byte threshold interrupt generated
by the UART) followed by 1 final inter-character timeout (when the UART
FIFO contains the last 6 bytes). The program upon each SIGIO would
read() 8 bytes and do some parsing of the data buffer and realize that
the whole sequence had not yet been received. Repeat 17 more times in
this example.

This doesn't change the Linux program code at all. It reduces the load.

> Firstly we don't want stuff with deep internal knowledge of devices as
> you'll have to modify and test something like 30 device drivers and it
> will rapidly be unmaintainable.

For reference:

IIR : Interrupt identification register (RO)

Bit 3   Bit 2   Bit 1   
0   0   0   Modem status change MSR read
0   0   1   Transmitter holding register empty  IIR read or THR 
write
0   1   0   Received data available RBR read
0   1   1   Line status change  LSR read
1   1   0   Character timeout (16550)   RBR read

I agree. However, the inter-character timeout is present (to the best of
my knowledge and google's) in all serial UARTs from the 16550A onward
(starting around 1994 and Windows 3.1). Before that, the IIR timeout
bit(3) was reserved and read 0. In addition, the two drivers modified,
8250.c and pxa.c are already using the inter-character timeout, they
just don't identify it specifically. In the ISRs, they simply check to
see if any of bits 1, 2, or 3 are set. In the example above, on the last
interrupt, the timeout bit(3) and the receive bit(2) would be set
causing a call to serial8250_handle_port(), but the ISR doesn't
(currently) care that it was the timeout that generated the last interrupt.


Some thoughts after writing that:
1. The ioctl should not allow the timeout mode to be set unless the UART
is a 16550A or newer.
2. The ioctl should have a way of determining if the driver supports the
timeout mode in its ISR. If it doesn't the user will sit and wait until
3,584 (4,096-512) bytes have been received. Definitely not the desired
effect, although that would only happen if the user enabled the timeout
mode on a non-supporting driver. This could be implemented with one
additional bit field (Note: I've been trying to minimize the code impact
for this timeout functionality in the hopes of making the changes more
palatable to maintainers).

I hope that has cleared up my motivation, and I'm going to make the
changes noted above to the patch.

Thanks,

Harvey

Further reading (if you're interested):
http://www.lammertbies.nl/comm/info/serial-uart.html#IIR
http://en.wikipedia.org/wiki/16550_UART
http://www.national.com/ds/PC/PC16550D.pdf
http://en.wikibooks.org/wiki/Serial_Programming:8250_UART_Programming

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 missing newlines to some uses of dev_ messages

[Jeff Garzik]

James Smart wrote:

ACK

-- james s

Joe Perches wrote:

[...]

Standard email etiquette:  please don't quote the entirety of a 1200+ 
line patch, just for a one-line response.


(also, top posting should be avoided as well)


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

Re: [RFC][PATCH 4/5] introduce TASK_SIZE_OF() for all arches

[Matt Mackall]

On Tue, Aug 07, 2007 at 03:33:03PM -0700, Dave Hansen wrote:
> 
> For the /proc//pagemap code[1], we need to able to query how
> much virtual address space a particular task has.  The trick is
> that we do it through /proc and can't use TASK_SIZE since it
> references "current" on some arches.  The process opening the
> /proc file might be a 32-bit process opening a 64-bit process's
> pagemap file.

That seems perfectly sensible to me, but I think you'll need to bounce
it off Andrew at least. (cc:ed)

> x86_64 already has a TASK_SIZE_OF() macro:
> 
> #define TASK_SIZE_OF(child) ((test_tsk_thread_flag(child, TIF_IA32)) ? 
> IA32_PAGE_OFFSET : TASK_SIZE64)
> 
> I'd like to have that for other architectures.  So, add it
> for all the architectures that actually use "current" in 
> their TASK_SIZE.  For the others, just add a quick #define
> in sched.h to use plain old TASK_SIZE.
> 
> 1. http://www.linuxworld.com/news/2007/042407-kernel.html
> 
> Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
> ---
> 
>  lxc-dave/include/asm-ia64/processor.h|3 ++-
>  lxc-dave/include/asm-parisc/processor.h  |3 ++-
>  lxc-dave/include/asm-powerpc/processor.h |4 +++-
>  lxc-dave/include/asm-s390/processor.h|2 ++
>  lxc-dave/include/linux/sched.h   |4 
>  5 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff -puN include/asm-ia64/processor.h~task_size_of 
> include/asm-ia64/processor.h
> --- lxc/include/asm-ia64/processor.h~task_size_of 2007-08-07 
> 15:30:54.0 -0700
> +++ lxc-dave/include/asm-ia64/processor.h 2007-08-07 15:30:54.0 
> -0700
> @@ -31,7 +31,8 @@
>   * each (assuming 8KB page size), for a total of 8TB of user virtual
>   * address space.
>   */
> -#define TASK_SIZE(current->thread.task_size)
> +#define TASK_SIZE_OF(tsk)((tsk)->thread.task_size)
> +#define TASK_SIZETASK_SIZE_OF(current)
>  
>  /*
>   * This decides where the kernel will search for a free chunk of vm
> diff -puN include/asm-parisc/processor.h~task_size_of 
> include/asm-parisc/processor.h
> --- lxc/include/asm-parisc/processor.h~task_size_of   2007-08-07 
> 15:30:54.0 -0700
> +++ lxc-dave/include/asm-parisc/processor.h   2007-08-07 15:30:54.0 
> -0700
> @@ -32,7 +32,8 @@
>  #endif
>  #define current_text_addr() ({ void *pc; current_ia(pc); pc; })
>  
> -#define TASK_SIZE   (current->thread.task_size)
> +#define TASK_SIZE_OF(tsk)   ((tsk)->thread.task_size)
> +#define TASK_SIZE (current->thread.task_size)
>  #define TASK_UNMAPPED_BASE  (current->thread.map_base)
>  
>  #define DEFAULT_TASK_SIZE32  (0xFFF0UL)
> diff -puN include/asm-powerpc/processor.h~task_size_of 
> include/asm-powerpc/processor.h
> --- lxc/include/asm-powerpc/processor.h~task_size_of  2007-08-07 
> 15:30:54.0 -0700
> +++ lxc-dave/include/asm-powerpc/processor.h  2007-08-07 15:30:54.0 
> -0700
> @@ -107,7 +107,9 @@ extern struct task_struct *last_task_use
>   */
>  #define TASK_SIZE_USER32 (0x0001UL - (1*PAGE_SIZE))
>  
> -#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
> +#define TASK_SIZE  (test_thread_flag(TIF_32BIT) ? \
> + TASK_SIZE_USER32 : TASK_SIZE_USER64)
> +#define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_32BIT) ? \
>   TASK_SIZE_USER32 : TASK_SIZE_USER64)
>  
>  /* This decides where the kernel will search for a free chunk of vm
> diff -puN include/asm-s390/processor.h~task_size_of 
> include/asm-s390/processor.h
> --- lxc/include/asm-s390/processor.h~task_size_of 2007-08-07 
> 15:30:54.0 -0700
> +++ lxc-dave/include/asm-s390/processor.h 2007-08-07 15:30:54.0 
> -0700
> @@ -75,6 +75,8 @@ extern struct task_struct *last_task_use
>  
>  # define TASK_SIZE   (test_thread_flag(TIF_31BIT) ? \
>   (0x8000UL) : (0x400UL))
> +# define TASK_SIZE_OF(tsk)   (test_tsk_thread_flag(tsk, TIF_31BIT) ? \
> + (0x8000UL) : (0x400UL))
>  # define TASK_UNMAPPED_BASE  (TASK_SIZE / 2)
>  # define DEFAULT_TASK_SIZE   (0x400UL)
>  
> diff -puN include/linux/sched.h~task_size_of include/linux/sched.h
> --- lxc/include/linux/sched.h~task_size_of2007-08-07 15:30:54.0 
> -0700
> +++ lxc-dave/include/linux/sched.h2007-08-07 15:30:54.0 -0700
> @@ -1712,6 +1712,10 @@ static inline void inc_syscw(struct task
>  }
>  #endif
>  
> +#ifndef TASK_SIZE_OF
> +#define TASK_SIZE_OF(tsk)TASK_SIZE
> +#endif
> +
>  #endif /* __KERNEL__ */
>  
>  #endif
> _

-- 
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: [RFC][PATCH 3/5] pagemap: remove open-coded sizeof(unsigned long)

[Matt Mackall]

On Tue, Aug 07, 2007 at 04:55:02PM -0700, Dave Hansen wrote:
> On Tue, 2007-08-07 at 18:40 -0500, Matt Mackall wrote:
> > On Tue, Aug 07, 2007 at 03:33:02PM -0700, Dave Hansen wrote:
> > > +#define PAGEMAP_ENTRY_SIZE_BYTES sizeof(unsigned long)
> > > +
> > >  static int add_to_pagemap(unsigned long addr, unsigned long pfn,
> > > struct pagemapread *pm)
> > >  {
> > >   __put_user(pfn, pm->out);
> > >   pm->out++;
> > > - pm->pos += sizeof(unsigned long);
> > > - pm->count -= sizeof(unsigned long);
> > > - pm->next = addr + PAGE_SIZE;
> > > + pm->pos += PAGEMAP_ENTRY_SIZE_BYTES;
> > > + pm->count -= PAGEMAP_ENTRY_SIZE_BYTES;
> > 
> > I think deleting ->next is a little premature here?
> 
> It is.  I'll fix that up.

While we're at it, it seems a shame to replace the unwieldy typedef
with an even longer define. My poor shift key finger aches just
thinking about typing that. PM_ENTRY_SIZE, perhaps?

-- 
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: [RFC][PATCH 2/5] pagemap: use PAGE_MASK/PAGE_ALIGN()

[Matt Mackall]

On Tue, Aug 07, 2007 at 03:33:01PM -0700, Dave Hansen wrote:
> 
> Use existing macros (PAGE_MASK/PAGE_ALIGN()) instead of
> open-coding them.

Absolutely.

Acked-by: Matt Mackall <[EMAIL PROTECTED]>

-- 
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: [PATCH] Add missing newlines to some uses of dev_ messages

[James Smart]

ACK

-- james s

Joe Perches wrote:

Found these while looking at printk uses.

Add missing newlines to dev_ uses
Add missing KERN_ prefixes to multiline dev_s
Fixed a wierd->weird spelling typo
Added a newline to a printk

Signed-off-by:  Joe Perches <[EMAIL PROTECTED]>

 arch/ia64/sn/kernel/xpnet.c|   13 ++-
 drivers/block/xsysace.c|4 +-
 drivers/char/isicom.c  |   10 ++--
 drivers/hwmon/adm1026.c|2 +-
 drivers/hwmon/lm63.c   |2 +-
 drivers/hwmon/vt1211.c |2 +-
 drivers/hwmon/w83791d.c|2 +-
 drivers/hwmon/w83792d.c|4 +-
 drivers/i2c/busses/i2c-pmcmsp.c|8 +++---
 drivers/i2c/busses/i2c-pnx.c   |2 +-
 drivers/i2c/chips/menelaus.c   |2 +-
 drivers/infiniband/hw/ehca/ehca_main.c |4 +-
 drivers/isdn/gigaset/common.c  |3 +-
 drivers/mtd/nand/s3c2410.c |2 +-
 drivers/net/ax88796.c  |2 +-
 drivers/net/bnx2.c |2 +-
 drivers/net/ehea/ehea_main.c   |9 ---
 drivers/net/myri10ge/myri10ge.c|3 +-
 drivers/net/sky2.c |2 +-
 drivers/net/usb/mcs7830.c  |   16 +++---
 drivers/net/xen-netfront.c |2 +-
 drivers/power/ds2760_battery.c |2 +-
 drivers/ps3/ps3stor_lib.c  |2 +-
 drivers/rtc/rtc-sysfs.c|5 +--
 drivers/scsi/lpfc/lpfc_sli.c   |8 --
 drivers/scsi/qla4xxx/ql4_os.c  |2 +-
 drivers/spi/atmel_spi.c|2 +-
 drivers/spi/spi_bfin5xx.c  |2 +-
 drivers/spi/spi_imx.c  |4 +-
 drivers/usb/class/cdc-acm.c|   34 
 drivers/usb/core/endpoint.c|2 +-
 drivers/usb/core/message.c |4 +-
 drivers/usb/host/ohci-s3c2410.c|2 +-
 drivers/usb/misc/adutux.c  |4 +-
 drivers/usb/misc/iowarrior.c   |8 +++---
 drivers/usb/misc/phidgetmotorcontrol.c |2 +-
 drivers/usb/serial/ftdi_sio.c  |4 +-
 drivers/usb/serial/io_edgeport.c   |2 +-
 drivers/usb/serial/ipw.c   |   18 
 drivers/usb/serial/mos7720.c   |4 +-
 drivers/usb/serial/oti6858.c   |2 +-
 drivers/usb/serial/sierra.c|   10 
 drivers/video/gxt4500.c|2 +-
 drivers/video/omap/blizzard.c  |2 +-
 drivers/video/omap/dispc.c |6 ++--
 drivers/video/omap/hwa742.c|2 +-
 drivers/video/omap/rfbi.c  |4 +-
 drivers/video/s3c2410fb.c  |2 +-
 drivers/w1/masters/ds1wm.c |2 +-
 drivers/xen/xenbus/xenbus_probe.c  |5 ++-
 sound/arm/aaci.c   |4 +-
 51 files changed, 129 insertions(+), 119 deletions(-)

diff --git a/arch/ia64/sn/kernel/xpnet.c b/arch/ia64/sn/kernel/xpnet.c
index e58fcad..a5df672 100644
--- a/arch/ia64/sn/kernel/xpnet.c
+++ b/arch/ia64/sn/kernel/xpnet.c
@@ -269,8 +269,9 @@ xpnet_receive(partid_t partid, int channel, struct 
xpnet_message *msg)
skb->protocol = eth_type_trans(skb, xpnet_device);
skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-	dev_dbg(xpnet, "passing skb to network layer; \n\tskb->head=0x%p "

-   "skb->data=0x%p skb->tail=0x%p skb->end=0x%p skb->len=%d\n",
+   dev_dbg(xpnet, "passing skb to network layer\n"
+   KERN_DEBUG "\tskb->head=0x%p skb->data=0x%p skb->tail=0x%p "
+   "skb->end=0x%p skb->len=%d\n",
(void *)skb->head, (void *)skb->data, skb_tail_pointer(skb),
skb_end_pointer(skb), skb->len);
 
@@ -576,10 +577,10 @@ xpnet_dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)

msg->tailout_ignore = end_addr - (u64)skb_tail_pointer(skb);
msg->buf_pa = __pa(start_addr);
 
-		dev_dbg(xpnet, "sending XPC message to %d:%d\nmsg->buf_pa="

-   "0x%lx, msg->size=%u, msg->leadin_ignore=%u, "
-   "msg->tailout_ignore=%u\n", dest_partid,
-   XPC_NET_CHANNEL, msg->buf_pa, msg->size,
+   dev_dbg(xpnet, "sending XPC message to %d:%d\n"
+   KERN_DEBUG "msg->buf_pa=0x%lx, msg->size=%u, "
+   "msg->leadin_ignore=%u, msg->tailout_ignore=%u\n",
+   dest_partid, XPC_NET_CHANNEL, msg->buf_pa, msg->size,
msg->leadin_ignore, msg->tailout_ignore);
 
 
diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c

index cb27e88..e988710 100644
--- a/drivers/block/xsysace.c
+++ b/drivers/block/xsysace.c
@@ -383,8 +383,8 @@ static inline void ace_dump_mem(void *base, int len)
 static void ace_dump_regs(struct ace_device *ace)
 {
dev_info(ace->dev, "ctrl:  %.8x  seccnt/cmd: %.4x  

Re: [PATCH 04/10] mm: slub: add knowledge of reserve pages

[Matt Mackall]

On Tue, Aug 07, 2007 at 05:13:52PM -0700, Christoph Lameter wrote:
> On Mon, 6 Aug 2007, Peter Zijlstra wrote:
> 
> > Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to allocation
> > contexts that are entitled to it.
> 
> Is this patch actually necessary?
>
 > If you are in an atomic context and bound to a cpu then a per cpu slab is 
> assigned to you and no one else can take object aways from that process 
> since nothing else can run on the cpu.

Servicing I/O over the network requires an allocation to send a buffer
and an allocation to later receive the acknowledgement. We can't free
our send buffer (or the memory it's supposed to clean) until the
relevant ack is received. We have to hold our reserves privately
throughout, even if an interrupt that wants to do GFP_ATOMIC
allocation shows up in-between.

> If you are not in an atomic context and are preemptable or can switch 
> allocation context then you can create another context in which reclaim 
> could be run to remove some clean pages and get you more memory. Again no 
> need for the patch.

By the point that this patch is relevant, there are already no clean
pages. The only way to free up more memory is via I/O.

-- 
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: why are some atomic_t's not volatile, while most are?

[Chris Snook]

Zan Lynx wrote:

On Tue, 2007-08-07 at 15:38 -0600, Chris Friesen wrote:

Chris Snook wrote:


That's why we define atomic_read like so:

#define atomic_read(v)  ((v)->counter)

This avoids the aliasing problem, because the compiler must de-reference 
the pointer every time, which requires a memory fetch.
Can you guarantee that the pointer dereference cannot be optimised away 
on any architecture?  Without other restrictions, a suficiently 
intelligent optimiser could notice that the address of v doesn't change 
in the loop and the destination is never written within the loop, so the 
read could be hoisted out of the loop.


Even now, powerpc (as an example) defines atomic_t as:

typedef struct { volatile int counter; } atomic_t


That volatile is there precisely to force the compiler to dereference it 
every single time.


I just tried this with GCC 4.2 on x86_64 because I was curious.

struct counter_t { volatile int counter; } test;
struct counter_t *tptr = 

int main() {
int i;

tptr->counter = 0;
i = 0;
while(tptr->counter < 100) {
i++;
}
return 0;
}

$ gcc -O3 -S t.c

a snippet of t.s:
main:
.LFB2:
movqtptr(%rip), %rdx
movl$0, (%rdx)
.p2align 4,,7
.L2:
movl(%rdx), %eax
cmpl$99, %eax
jle .L2


Now with the volatile removed:
main:
.LFB2:
movqtptr(%rip), %rax
movl$0, (%rax)
.L2:
jmp .L2

If the compiler can see it clearly, it will optimize out the load
without the volatile.


This is not a problem, since indirect references will cause the CPU to fetch the 
data from memory/cache anyway.


-- 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: [PATCH/RFT] finish i386 and x86-64 sysdata conversion

[Yinghai Lu]

On 8/7/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Yinghai Lu wrote:
> > the sysdata stuff try to fix:
> > when calgary iommu code was introduced, it is trying to share sysdata
> > that orginally is initialized k8_bus.c and used by pcibus_to_node. but
> > that only happen with AMD K8 platform. and have nothing to do with
> > calgary.
>
> incorrect:  sysdata is initialized when the structure is created, which
> clearly not only in k8_bus.c

before his first patch, numa juse use sysdata pointer for node.

>
>
> > Then my patch get_mp_bus_to_node_as_early will use that sysdata as
> > node as early as possible before the pci_scan bus is called.
>
> that's incorrect, since it assumes NUMA owns ->sysdata

At that time, only it use that.

>
>
> > then Mul came out his patch ...to split the sharing that will never happen.
>
> that's incorrect, ->sysdata will be shared among Calgary, NUMA, and
> PCI-domain support.

but not the same time on run time system with Calgary, NUMA.

>
>
> > Also i don't think anyone test muli sysdata patch with amd64 platform
> > with acpi=off. even muli himself.
>
> I did.  I did all PCI domain support development on AMD64 platform.

really, but his first patch is broken with acpi=off.
I guess you tested his patch plus your patch. instead of test his
patch barely.  I tested his patch + my patch, and it works well, and
even test his patch only.

>
>
> > calgary support bus numa at this time? i mean mult peer root bus on
> > different node..
>
> My PCI domains patch add support for multiple peer root buses.  That's
> the definition of PCI domain support.
>
> Branch 'pciseg' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git

good, i will look at it.

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

Re: [PATCH] fix oops in __audit_signal_info()

[James Morris]

On Wed, 8 Aug 2007, Al Viro wrote:

>   Check for audit_signals is misplaced and check for
> audit_dummy_context() is missing; as the result, if we send
> signal to auditd from task with NULL ->audit_context while
> we have audit_signals != 0 we end up with an oops.
> 
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>

Acked-by: James Morris <[EMAIL PROTECTED]>



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

Re: [RFC][PATCH 1/5] pagemap: remove file header

[Alan Cox]

O> > The endianness is only useful when examining a raw dump of
> > pagemap from a different machine when you don't know the
> > source of the file.  This is pretty rare, and the programs
> > or scripts doing the copying off-machine can certainly be
> > made to hold this information.

Nobody fancies doing bi-endian MIPS ?

> > The page size is available in userspace at least with libc's
> > getpagesize().  This will also never vary across processes,

For now. Its a logical direction however thant we end up with bigger page
sizes either by hardware or by software merging and end up having
different page sizes for legacy 32bit binaries.

> I'd really strongly prefer to have no header. It was added to
> futureproof the thing.

The information needed to parse /proc/pid/pagemap can be stuck
in /proc/pid/somewherelese. If we ever get page size variations and the
like then /proc/pid/ is going to end up with that information anyway for
ps and friends to use.

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

Re: file capabilities: clear fcaps on inode change (v3)

[James Morris]

On Tue, 7 Aug 2007, Serge E. Hallyn wrote:

> Yeah, I did that in v1, but didn't want to add two new security_ hooks.
> But I'll send a v4 doing that.

Yep, add what's actually needed.

Continually having to jump through all of these hoops for LSM has gone 
beyond ridiculous.



- James 
-- 
James Morris
<[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 3/5] try parent numa_node at first before using default v2

[Yinghai Lu]

[PATCH 3/5] try parent numa_node at first before using default v2

in the device_add, we try to use use parent numa_node.
need to make sure pci root bus's bridge device numa_node is set.
then we could use device->numa_node direclty for all device.
and don't need to call pcibus_to_node().

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index e48fcf0..c029ffc 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -935,7 +938,6 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus 
*bus)
dev->dev.release = pci_release_dev;
pci_dev_get(dev);
 
-   set_dev_node(>dev, pcibus_to_node(bus));
dev->dev.dma_mask = >dma_mask;
dev->dev.coherent_dma_mask = 0xull;
 
@@ -1096,6 +1098,9 @@ struct pci_bus * pci_create_bus(struct device *parent,
goto dev_reg_err;
b->bridge = get_device(dev);
 
+   if (!parent)
+   set_dev_node(b->bridge, pcibus_to_node(b));
+
b->class_dev.class = _class;
sprintf(b->class_dev.class_id, "%04x:%02x", pci_domain_nr(b), bus);
error = class_device_register(>class_dev);
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 0455aa7..d8b063b 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -672,6 +672,11 @@ int device_add(struct device *dev)
if (error)
goto Error;
 
+   /* use parent numa_node */
+   if (parent) {
+   set_dev_node(dev, dev_to_node(parent));
+   }
+
/* first, register with generic layer. */
kobject_set_name(>kobj, "%s", dev->bus_id);
error = kobject_add(>kobj);
@@ -1269,8 +1274,11 @@ int device_move(struct device *dev, struct device 
*new_parent)
dev->parent = new_parent;
if (old_parent)
klist_remove(>knode_parent);
-   if (new_parent)
+   if (new_parent) {
klist_add_tail(>knode_parent, _parent->klist_children);
+   set_dev_node(dev, dev_to_node(new_parent));
+   }
+
if (!dev->class)
goto out_put;
error = device_move_class_links(dev, old_parent, new_parent);
@@ -1280,9 +1288,12 @@ int device_move(struct device *dev, struct device 
*new_parent)
if (!kobject_move(>kobj, _parent->kobj)) {
if (new_parent)
klist_remove(>knode_parent);
-   if (old_parent)
+   dev->parent = old_parent;
+   if (old_parent) {
klist_add_tail(>knode_parent,
   _parent->klist_children);
+   set_dev_node(dev, dev_to_node(old_parent));
+   }
}
put_device(new_parent);
goto out;
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH/RFT] finish i386 and x86-64 sysdata conversion

[Jeff Garzik]

Yinghai Lu wrote:

the sysdata stuff try to fix:
when calgary iommu code was introduced, it is trying to share sysdata
that orginally is initialized k8_bus.c and used by pcibus_to_node. but
that only happen with AMD K8 platform. and have nothing to do with
calgary.


incorrect:  sysdata is initialized when the structure is created, which 
clearly not only in k8_bus.c




Then my patch get_mp_bus_to_node_as_early will use that sysdata as
node as early as possible before the pci_scan bus is called.


that's incorrect, since it assumes NUMA owns ->sysdata



then Mul came out his patch ...to split the sharing that will never happen.


that's incorrect, ->sysdata will be shared among Calgary, NUMA, and 
PCI-domain support.




Also i don't think anyone test muli sysdata patch with amd64 platform
with acpi=off. even muli himself.


I did.  I did all PCI domain support development on AMD64 platform.



calgary support bus numa at this time? i mean mult peer root bus on
different node..


My PCI domains patch add support for multiple peer root buses.  That's 
the definition of PCI domain support.


Branch 'pciseg' of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git

Jeff


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

[PATCH 4/5] net: use numa_node in net_devcice->dev instead of parent

[Yinghai Lu]

[PATCH 4/5] net: use numa_node in net_devcice->dev instead of parent

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 27cfe5f..005cc1c 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -217,7 +217,7 @@ nodata:
 struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
unsigned int length, gfp_t gfp_mask)
 {
-   int node = dev->dev.parent ? dev_to_node(dev->dev.parent) : -1;
+   int node = dev_to_node(>dev);
struct sk_buff *skb;
 
skb = __alloc_skb(length + NET_SKB_PAD, gfp_mask, 0, node);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/5] x86_64: use bus conf in NB conf fun1 to get bus range on node

[Yinghai Lu]

[PATCH 2/5] x86_64: use bus conf in NB conf fun1 to get bus range on node

So we use the same code with Quad core cpu as old opteron.
this patch is usful when acpi=off or _PXM is not there in DSDT

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

--- a/arch/x86_64/pci/k8-bus.c  2007-07-23 10:35:58.0 -0700
+++ b/arch/x86_64/pci/k8-bus.c  2007-07-23 10:38:41.0 -0700
@@ -12,15 +12,18 @@
  * RED-PEN empty cpus get reported wrong
  */
 
-#define NODE_ID_REGISTER 0x60
-#define NODE_ID(dword) (dword & 0x07)
-#define LDT_BUS_NUMBER_REGISTER_0 0x94
-#define LDT_BUS_NUMBER_REGISTER_1 0xB4
-#define LDT_BUS_NUMBER_REGISTER_2 0xD4
-#define NR_LDT_BUS_NUMBER_REGISTERS 3
-#define SECONDARY_LDT_BUS_NUMBER(dword) ((dword >> 8) & 0xFF)
-#define SUBORDINATE_LDT_BUS_NUMBER(dword) ((dword >> 16) & 0xFF)
+#define NODE_ID(dword) ((dword>>4) & 0x07)
+#define LDT_BUS_NUMBER_REGISTER_0 0xE0
+#define LDT_BUS_NUMBER_REGISTER_1 0xE4
+#define LDT_BUS_NUMBER_REGISTER_2 0xE8
+#define LDT_BUS_NUMBER_REGISTER_3 0xEC
+#define NR_LDT_BUS_NUMBER_REGISTERS 4
+#define SECONDARY_LDT_BUS_NUMBER(dword) ((dword >> 16) & 0xFF)
+#define SUBORDINATE_LDT_BUS_NUMBER(dword) ((dword >> 24) & 0xFF)
+
 #define PCI_DEVICE_ID_K8HTCONFIG 0x1100
+#define PCI_DEVICE_ID_K8_10H_HTCONFIG 0x1200
+#define PCI_DEVICE_ID_K8_11H_HTCONFIG 0x1300
 
 #define BUS_NR 256
 
@@ -60,12 +63,19 @@
 {
int i, j;
unsigned slot;
-   u32 ldtbus, nid;
+   u32 ldtbus;
u32 id;
-   static int lbnr[3] = {
+   int node;
+   u16 deviceid;
+   u16 vendorid;
+   int min_bus;
+   int max_bus;
+
+   static int lbnr[NR_LDT_BUS_NUMBER_REGISTERS] = {
LDT_BUS_NUMBER_REGISTER_0,
LDT_BUS_NUMBER_REGISTER_1,
-   LDT_BUS_NUMBER_REGISTER_2
+   LDT_BUS_NUMBER_REGISTER_2,
+   LDT_BUS_NUMBER_REGISTER_3
};
 
memset(mp_bus_to_node, 0, BUS_NR);
@@ -73,38 +83,36 @@
if (!early_pci_allowed())
return -1;
 
-   for (slot = 0x18; slot < 0x20; slot++) {
-   id = read_pci_config(0, slot, 0, PCI_VENDOR_ID);
-   if (id != (PCI_VENDOR_ID_AMD | (PCI_DEVICE_ID_K8HTCONFIG<<16)))
-   break;
-   nid = read_pci_config(0, slot, 0, NODE_ID_REGISTER);
-
-   for (i = 0; i < NR_LDT_BUS_NUMBER_REGISTERS; i++) {
-   ldtbus = read_pci_config(0, slot, 0, lbnr[i]);
-   /*
-* if there are no busses hanging off of the current
-* ldt link then both the secondary and subordinate
-* bus number fields are set to 0.
-*
-* RED-PEN
-* This is slightly broken because it assumes
-* HT node IDs == Linux node ids, which is not always
-* true. However it is probably mostly true.
-*/
-   if (!(SECONDARY_LDT_BUS_NUMBER(ldtbus) == 0
-   && SUBORDINATE_LDT_BUS_NUMBER(ldtbus) == 0)) {
-   for (j = SECONDARY_LDT_BUS_NUMBER(ldtbus);
-j <= SUBORDINATE_LDT_BUS_NUMBER(ldtbus);
-j++) {
-   int node = NODE_ID(nid);
-   mp_bus_to_node[j] = (unsigned char)node;
-   }
-   }
-   }
+   slot = 0x18;
+   id = read_pci_config(0, slot, 0, PCI_VENDOR_ID);
+
+   vendorid = id & 0x;
+   if (vendorid != PCI_VENDOR_ID_AMD)
+   goto out;
+
+   deviceid = (id>>16) & 0x;
+   if ((deviceid != PCI_DEVICE_ID_K8HTCONFIG) &&
+   (deviceid != PCI_DEVICE_ID_K8_10H_HTCONFIG) &&
+   (deviceid != PCI_DEVICE_ID_K8_11H_HTCONFIG))
+   goto out;
+
+   for (i = 0; i < NR_LDT_BUS_NUMBER_REGISTERS; i++) {
+   ldtbus = read_pci_config(0, slot, 1, lbnr[i]);
+
+   /* Check if that register is enabled for bus range */
+   if ((ldtbus & 7) != 3)
+   continue;
+
+   min_bus = SECONDARY_LDT_BUS_NUMBER(ldtbus);
+   max_bus = SUBORDINATE_LDT_BUS_NUMBER(ldtbus);
+   node = NODE_ID(ldtbus);
+   for (j = min_bus; j <= max_bus; j++)
+   mp_bus_to_node[j] = (unsigned char) node;
}
 
+out:
for (i = 0; i < BUS_NR; i++) {
-   int node = mp_bus_to_node[i];
+   node = mp_bus_to_node[i];
if (node)
printk(KERN_DEBUG "bus: %02x to node: %02x\n", i, node);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ 

[PATCH 1/5] x86_64: get mp_bus_to_node as early v3

[Yinghai Lu]

please check this one against pci_scan_bus_with_sysdata

[PATCH 1/5] x86_64: get mp_bus_to_node as early v3

current on amd k8 system with multi ht chain, the numa_node of pci devices under
/sys/devices/pci:80/* always 0, even that chain is on node 1 or 2 or 3.

workaround: pcibus_to_node(bus) is used when we want to get node that 
pci_device is on.

In struct device, we already have numa_node member. and we could use 
dev_to_node()
/set_dev_node() to get and set numa_node in the device.
set_dev_node is called in pci_device_add() with pcibus_to_node(bus). and
pcibus_to_node use bus->sysdata for nodeid.

the problem is when pci_add_device is called, bus->sysdata is not assigned
correct nodeid yet. the result will be numa_node always is 0.

pcibios_scan_root and pci_scan_root could take sysdata. So we need to get
mp_bus_to_node mapping before these two are called. and get_mp_bus_to_node
could get correct node for sysdata in root bus.

in scanning of root bus, all child bus will take parent bus sysdata. So all
pci_device->dev.numa_node will be assigned correctly automatically.

later we could use dev_to_node(_dev->dev) to get numa_node, and we could 
also
could make other bus specific device get the correct numa_node too.

this is one update version to pci_sysdata ...
also reverse pci_acpi_scan_root to use pcibios_scan_root again.

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

 arch/i386/pci/Makefile |1
 arch/i386/pci/Makefile |1
 arch/i386/pci/acpi.c   |   40 +--
 arch/i386/pci/common.c |   17 ++--
 arch/i386/pci/irq.c|4 +
 arch/i386/pci/legacy.c |6 ++
 arch/i386/pci/mp_bus_to_node.c |   24 +++
 arch/x86_64/pci/k8-bus.c   |   83 -
 include/asm-i386/pci.h |1
 include/asm-i386/topology.h|   10 
 include/asm-x86_64/pci.h   |1
 include/asm-x86_64/topology.h  |   13 ++
 11 files changed, 138 insertions(+), 62 deletions(-)

diff --git a/arch/i386/pci/Makefile b/arch/i386/pci/Makefile
index 44650e0..600d0e7 100644
--- a/arch/i386/pci/Makefile
+++ b/arch/i386/pci/Makefile
@@ -10,5 +10,6 @@ pci-y += legacy.o irq.o
 
 pci-$(CONFIG_X86_VISWS):= visws.o fixup.o
 pci-$(CONFIG_X86_NUMAQ):= numa.o irq.o
+pci-$(CONFIG_NUMA) += mp_bus_to_node.o
 
 obj-y  += $(pci-y) common.o early.o
diff --git a/arch/i386/pci/acpi.c b/arch/i386/pci/acpi.c
index bc8a44b..dfa24a1 100644
--- a/arch/i386/pci/acpi.c
+++ b/arch/i386/pci/acpi.c
@@ -8,46 +8,28 @@
 struct pci_bus * __devinit pci_acpi_scan_root(struct acpi_device *device, int 
domain, int busnum)
 {
struct pci_bus *bus;
-   struct pci_sysdata *sd;
+#ifdef CONFIG_ACPI_NUMA
int pxm;
-
-   /* Allocate per-root-bus (not per bus) arch-specific data.
-* TODO: leak; this memory is never freed.
-* It's arguable whether it's worth the trouble to care.
-*/
-   sd = kzalloc(sizeof(*sd), GFP_KERNEL);
-   if (!sd) {
-   printk(KERN_ERR "PCI: OOM, not probing PCI bus %02x\n", busnum);
-   return NULL;
-   }
+   int node;
+#endif
 
if (domain != 0) {
printk(KERN_WARNING "PCI: Multiple domains not supported\n");
-   kfree(sd);
return NULL;
}
 
-   sd->node = -1;
-
-   pxm = acpi_get_pxm(device->handle);
 #ifdef CONFIG_ACPI_NUMA
-   if (pxm >= 0)
-   sd->node = pxm_to_node(pxm);
+   pxm = acpi_get_pxm(device->handle);
+   if (pxm >= 0) {
+   node = pxm_to_node(pxm);
+   printk(KERN_INFO "bus %02x -> pxm %d -> node %02x\n",
+   busnum, pxm, node);
+   set_mp_bus_to_node(busnum, node);
+   }
 #endif
 
-   bus = pci_scan_bus_parented(NULL, busnum, _root_ops, sd);
-   if (!bus)
-   kfree(sd);
+   bus = pcibios_scan_root(busnum);
 
-#ifdef CONFIG_ACPI_NUMA
-   if (bus != NULL) {
-   if (pxm >= 0) {
-   printk("bus %d -> pxm %d -> node %d\n",
-   busnum, pxm, sd->node);
-   }
-   }
-#endif
-   
return bus;
 }
 
diff --git a/arch/i386/pci/common.c b/arch/i386/pci/common.c
index 4bc62b3..0e1163c 100644
--- a/arch/i386/pci/common.c
+++ b/arch/i386/pci/common.c
@@ -314,9 +314,14 @@ struct pci_bus * __devinit pcibios_scan_root(int busnum)
return NULL;
}
 
+   sd->node = get_mp_bus_to_node(busnum);
+
printk(KERN_DEBUG "PCI: Probing PCI hardware (bus %02x)\n", busnum);
+   bus = pci_scan_bus_parented(NULL, busnum, _root_ops, sd);
+   if (!bus)
+   kfree(sd);
 
-   return pci_scan_bus_parented(NULL, busnum, _root_ops, sd);
+   return bus;
 }
 
 extern u8 pci_cache_line_size;
@@ -456,7 +461,7 @@ void pcibios_disable_device (struct pci_dev 

[PATCH 5/5] dma: use dev_to_node to get node for device in dma_alloc_pages

[Yinghai Lu]

[PATCH 5/5] dma: use dev_to_node to get node for device in dma_alloc_pages

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

diff --git a/arch/x86_64/kernel/pci-dma.c b/arch/x86_64/kernel/pci-dma.c
index 9f80aad..6dbf1c9 100644
--- a/arch/x86_64/kernel/pci-dma.c
+++ b/arch/x86_64/kernel/pci-dma.c
@@ -52,11 +52,9 @@ dma_alloc_pages(struct device *dev, gfp_t gfp, unsigned 
order)
 {
struct page *page;
int node;
-#ifdef CONFIG_PCI
-   if (dev->bus == _bus_type)
-   node = pcibus_to_node(to_pci_dev(dev)->bus);
-   else
-#endif
+
+   node = dev_to_node(dev);
+   if (node == -1)
node = numa_node_id();
 
if (node < first_node(node_online_map))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 1/5] pagemap: remove file header

[Matt Mackall]

On Tue, Aug 07, 2007 at 03:33:00PM -0700, Dave Hansen wrote:
> 
> The /proc//pagemap file has a header containing:
>  * first byte:   0 for big endian, 1 for little
>  * second byte:  page shift (eg 12 for 4096 byte pages)
>  * third byte:   entry size in bytes (currently either 4 or 8)
>  * fourth byte:  header size
> 
> The endianness is only useful when examining a raw dump of
> pagemap from a different machine when you don't know the
> source of the file.  This is pretty rare, and the programs
> or scripts doing the copying off-machine can certainly be
> made to hold this information.
> 
> The page size is available in userspace at least with libc's
> getpagesize().  This will also never vary across processes,
> so putting it in a per-process file doesn't make any difference.
> If we need a "kernel's page size" exported to userspace,
> perhaps we can put it in /proc/meminfo.
> 
> The entry size is the really tricky one.  This can't just
> be sizeof(unsigned long) from userspace because we can have
> 32-bit processes on 64-bit kernels.  But, userspace can
> certainly derive this value if it lseek()s to the end of
> the file, and divides the file position by the size of its
> virtual address space.

I'd really strongly prefer to have no header. It was added to
futureproof the thing.

One downside to this is that dumps are no longer portable. But
that's not a showstopper, I suppose.

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

[PATCH] Add missing newlines to some uses of dev_ messages

[Joe Perches]

Found these while looking at printk uses.

Add missing newlines to dev_ uses
Add missing KERN_ prefixes to multiline dev_s
Fixed a wierd->weird spelling typo
Added a newline to a printk

Signed-off-by:  Joe Perches <[EMAIL PROTECTED]>

 arch/ia64/sn/kernel/xpnet.c|   13 ++-
 drivers/block/xsysace.c|4 +-
 drivers/char/isicom.c  |   10 ++--
 drivers/hwmon/adm1026.c|2 +-
 drivers/hwmon/lm63.c   |2 +-
 drivers/hwmon/vt1211.c |2 +-
 drivers/hwmon/w83791d.c|2 +-
 drivers/hwmon/w83792d.c|4 +-
 drivers/i2c/busses/i2c-pmcmsp.c|8 +++---
 drivers/i2c/busses/i2c-pnx.c   |2 +-
 drivers/i2c/chips/menelaus.c   |2 +-
 drivers/infiniband/hw/ehca/ehca_main.c |4 +-
 drivers/isdn/gigaset/common.c  |3 +-
 drivers/mtd/nand/s3c2410.c |2 +-
 drivers/net/ax88796.c  |2 +-
 drivers/net/bnx2.c |2 +-
 drivers/net/ehea/ehea_main.c   |9 ---
 drivers/net/myri10ge/myri10ge.c|3 +-
 drivers/net/sky2.c |2 +-
 drivers/net/usb/mcs7830.c  |   16 +++---
 drivers/net/xen-netfront.c |2 +-
 drivers/power/ds2760_battery.c |2 +-
 drivers/ps3/ps3stor_lib.c  |2 +-
 drivers/rtc/rtc-sysfs.c|5 +--
 drivers/scsi/lpfc/lpfc_sli.c   |8 --
 drivers/scsi/qla4xxx/ql4_os.c  |2 +-
 drivers/spi/atmel_spi.c|2 +-
 drivers/spi/spi_bfin5xx.c  |2 +-
 drivers/spi/spi_imx.c  |4 +-
 drivers/usb/class/cdc-acm.c|   34 
 drivers/usb/core/endpoint.c|2 +-
 drivers/usb/core/message.c |4 +-
 drivers/usb/host/ohci-s3c2410.c|2 +-
 drivers/usb/misc/adutux.c  |4 +-
 drivers/usb/misc/iowarrior.c   |8 +++---
 drivers/usb/misc/phidgetmotorcontrol.c |2 +-
 drivers/usb/serial/ftdi_sio.c  |4 +-
 drivers/usb/serial/io_edgeport.c   |2 +-
 drivers/usb/serial/ipw.c   |   18 
 drivers/usb/serial/mos7720.c   |4 +-
 drivers/usb/serial/oti6858.c   |2 +-
 drivers/usb/serial/sierra.c|   10 
 drivers/video/gxt4500.c|2 +-
 drivers/video/omap/blizzard.c  |2 +-
 drivers/video/omap/dispc.c |6 ++--
 drivers/video/omap/hwa742.c|2 +-
 drivers/video/omap/rfbi.c  |4 +-
 drivers/video/s3c2410fb.c  |2 +-
 drivers/w1/masters/ds1wm.c |2 +-
 drivers/xen/xenbus/xenbus_probe.c  |5 ++-
 sound/arm/aaci.c   |4 +-
 51 files changed, 129 insertions(+), 119 deletions(-)

diff --git a/arch/ia64/sn/kernel/xpnet.c b/arch/ia64/sn/kernel/xpnet.c
index e58fcad..a5df672 100644
--- a/arch/ia64/sn/kernel/xpnet.c
+++ b/arch/ia64/sn/kernel/xpnet.c
@@ -269,8 +269,9 @@ xpnet_receive(partid_t partid, int channel, struct 
xpnet_message *msg)
skb->protocol = eth_type_trans(skb, xpnet_device);
skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-   dev_dbg(xpnet, "passing skb to network layer; \n\tskb->head=0x%p "
-   "skb->data=0x%p skb->tail=0x%p skb->end=0x%p skb->len=%d\n",
+   dev_dbg(xpnet, "passing skb to network layer\n"
+   KERN_DEBUG "\tskb->head=0x%p skb->data=0x%p skb->tail=0x%p "
+   "skb->end=0x%p skb->len=%d\n",
(void *)skb->head, (void *)skb->data, skb_tail_pointer(skb),
skb_end_pointer(skb), skb->len);
 
@@ -576,10 +577,10 @@ xpnet_dev_hard_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
msg->tailout_ignore = end_addr - (u64)skb_tail_pointer(skb);
msg->buf_pa = __pa(start_addr);
 
-   dev_dbg(xpnet, "sending XPC message to %d:%d\nmsg->buf_pa="
-   "0x%lx, msg->size=%u, msg->leadin_ignore=%u, "
-   "msg->tailout_ignore=%u\n", dest_partid,
-   XPC_NET_CHANNEL, msg->buf_pa, msg->size,
+   dev_dbg(xpnet, "sending XPC message to %d:%d\n"
+   KERN_DEBUG "msg->buf_pa=0x%lx, msg->size=%u, "
+   "msg->leadin_ignore=%u, msg->tailout_ignore=%u\n",
+   dest_partid, XPC_NET_CHANNEL, msg->buf_pa, msg->size,
msg->leadin_ignore, msg->tailout_ignore);
 
 
diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
index cb27e88..e988710 100644
--- a/drivers/block/xsysace.c
+++ b/drivers/block/xsysace.c
@@ -383,8 +383,8 @@ static inline void ace_dump_mem(void *base, int len)
 static void ace_dump_regs(struct ace_device *ace)
 {
dev_info(ace->dev, "ctrl:  %.8x  seccnt/cmd: %.4x  ver:%.4x\n"
-  

Re: [PATCH/RFT] finish i386 and x86-64 sysdata conversion

[Yinghai Lu]

On 8/7/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Muli Ben-Yehuda wrote:
>
> Strongly agreed.  It overall fixes bugs that existing _before_ the
> sysdata stuff went in.

what are those bugs?

the sysdata stuff try to fix:
when calgary iommu code was introduced, it is trying to share sysdata
that orginally is initialized k8_bus.c and used by pcibus_to_node. but
that only happen with AMD K8 platform. and have nothing to do with
calgary.
Then my patch get_mp_bus_to_node_as_early will use that sysdata as
node as early as possible before the pci_scan bus is called.

then Mul came out his patch ...to split the sharing that will never happen.

But andi picked muli patch even my patch stay a while in -mm.

Also i don't think anyone test muli sysdata patch with amd64 platform
with acpi=off. even muli himself.

calgary support bus numa at this time? i mean mult peer root bus on
different node..

anyway I will produce my patch in v3...

YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/RFC: [kdump] fix APIC shutdown sequence

[Eric W. Biederman]

A couple of questions.

How bad is it if you just run with irqpoll in the kdump kernel?
If running with irqpoll is usable that is probably preferable
to putting in a hardware work around we can survive without.


Have you done any looking at moving where the kernel initalizes
io_apics?  One of the todo items on the path is to leave
io_apic mode enabled and just startup the kernel in io_apic
mode.

When doing that a version of your work around (if needed)
would certainly be reasonable.

My general concern is that the trickier we get in the code
running in the crashed kernel the less reliable the entire
process will be.

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

[git patches] libata fixes

[Jeff Garzik]

The only non-fix are two sata_mv PCI ID additions.

Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git 
upstream-linus

to receive the following updates:

 drivers/ata/ata_piix.c|2 +-
 drivers/ata/pata_isapnp.c |2 ++
 drivers/ata/sata_mv.c |3 +++
 3 files changed, 6 insertions(+), 1 deletions(-)

Alan Cox (1):
  sata_mv: PCI IDs for Hightpoint RocketRaid 1740/1742

Jeff Garzik (1):
  [libata] pata_isapnp: replace missing module device table

Tejun Heo (1):
  ata_piix: update map 10b for ich8m

diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index a78832e..c5b4509 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -436,7 +436,7 @@ static const struct piix_map_db ich8_map_db = {
/* PM   PS   SM   SS   MAP */
{  P0,  P2,  P1,  P3 }, /* 00b (hardwired when in AHCI) */
{  RV,  RV,  RV,  RV },
-   {  IDE,  IDE,  NA,  NA }, /* 10b (IDE mode) */
+   {  P0,  P2, IDE, IDE }, /* 10b (IDE mode) */
{  RV,  RV,  RV,  RV },
},
 };
diff --git a/drivers/ata/pata_isapnp.c b/drivers/ata/pata_isapnp.c
index 5525518..91a396f 100644
--- a/drivers/ata/pata_isapnp.c
+++ b/drivers/ata/pata_isapnp.c
@@ -139,6 +139,8 @@ static struct pnp_device_id isapnp_devices[] = {
{.id = ""}
 };
 
+MODULE_DEVICE_TABLE(pnp, isapnp_devices);
+
 static struct pnp_driver isapnp_driver = {
.name   = DRV_NAME,
.id_table   = isapnp_devices,
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 8ec5208..3acf65e 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -621,6 +621,9 @@ static const struct pci_device_id mv_pci_tbl[] = {
{ PCI_VDEVICE(MARVELL, 0x5041), chip_504x },
{ PCI_VDEVICE(MARVELL, 0x5080), chip_5080 },
{ PCI_VDEVICE(MARVELL, 0x5081), chip_508x },
+   /* RocketRAID 1740/174x have different identifiers */
+   { PCI_VDEVICE(TTI, 0x1740), chip_508x },
+   { PCI_VDEVICE(TTI, 0x1742), chip_508x },
 
{ PCI_VDEVICE(MARVELL, 0x6040), chip_604x },
{ PCI_VDEVICE(MARVELL, 0x6041), chip_604x },
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bad temperature values from w83781d in 2.6.22

[Mark M. Hoffman]

Hi Joerg:

(I tried to follow-up using the gmane.org mail/news gateway... didn't seem
to work.)

* Joerg Sommrey <[EMAIL PROTECTED]> [2007-08-05 12:26:04 +0200]:
> Hi,
> 
> after upgrading from 2.6.21 to 2.6.22 the CPU temperatures shown by
> w83781d look unreal.  They were in a range from 40°C when idle to
> 75°C under full load with 2.6.21.  The values shown now are in a very
> small range from 77°C to 82°C.  From the (low) noise of the fan I can
> tell that the temperature is <50°C.
> The third temperature shown is completely wrong.
> 
> I have a Tyan Tiger MPX board with a w83782d chip. Output from
> "sensors":
> 
> w83782d-i2c-0-2d
> Adapter: SMBus AMD768 adapter at 80e0
>  +5 V: +4.81 V  (min =  +4.76 V, max =  +5.24 V)
> 3 VSB: +3.30 V  (min =  +2.85 V, max =  +3.15 V)   ALARM
> chs3 Fan: 2122 RPM  (min = 2657 RPM, div = 4)  ALARM
> VRM2 Temp:  -208°C  (high =  -176°C, hyst =  -181°C)   sensor = transistor 
> CPU1 Temp: +78.5°C  (high =   +80°C, hyst =   +75°C)   sensor = transistor   
> ALARM
> CPU2 Temp: +77.5°C  (high =   +80°C, hyst =   +75°C)   sensor = transistor   
> ALARM
> alarms:
> beep_enable:
>   Sound alarm enabled
> 
> # cat /sys/bus/i2c/devices/0-002d/temp*_input
> -209000
> 77500
> 77500
> 
> Any ideas?

Please run the following commands as root (against both kernel versions) and
reply-to-all with the results:

# modprobe i2c-dev
# i2cdump -y 0 0x2d b 0 0x4e
# i2cdump -y 0 0x48
# i2cdump -y 0 0x49

Also, can you confirm that you're using the sensors.conf from here:
http://www.tyan.com/support_download_utility.aspx?model=s.s2466

Finally, can you confirm that "sensors -s" is running (without error) some
time during system startup, w/ both kernel versions?

Thanks & regards,

-- 
Mark M. Hoffman
[EMAIL PROTECTED]

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

Re: [PATCH] serial inter-character timeout usage with async io

[Alan Cox]

> Currently, I only have this code enabled for i386 and arm, and only for
> the 8250 and pxa serial drivers. If no one thinks this is a terrible
> idea, I'll modify all of the other ioctl.h files and resubmit the patch.

What are you actually trying to achieve ?

Firstly we don't want stuff with deep internal knowledge of devices as
you'll have to modify and test something like 30 device drivers and it
will rapidly be unmaintainable.

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

Re: [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)

[Andrew Morton]

On Tue, 07 Aug 2007 20:45:34 -0400
Trond Myklebust <[EMAIL PROTECTED]> wrote:

> > - rename something so that unconverted filesystems will reliably fail to
> >   compile?
> > 
> > - leave existing filesystems alone, but add a new
> >   inode_operations.setattr_jeff, which the networked filesytems can
> >   implement, and teach core vfs to call setattr_jeff in preference to
> >   setattr?
> 
> If you really need to know that the filesystem is handling the flags,
> then how about instead having ->setattr() return something which
> indicates which flags it actually handled? That is likely to be a far
> more intrusive change, but it is one which is future-proof.

If we change ->setattr so that it will return a positive, non-zero value
which the caller can then check and reliably do printk("that filesystem
needs updating") then that addresses my concern, sure.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] drop unneeded variable in amd_apic_timer_broken

[Cal Peake]

On Wed, 8 Aug 2007, Andi Kleen wrote:

> Not sure why the MSR varies between cores though.

Yeah that boggled me too.

> It's better to just make it a global instead.

Haven't gotten to figuring out how to do *that* yet... but here's a 
cleanup for the detection function:

From: Cal Peake <[EMAIL PROTECTED]>

We only care about the lower 32-bits when reading the Interrupt Pending 
Message Register so drop the 'hi' variable and use rdmsrl() instead.

Signed-off-by: Cal Peake <[EMAIL PROTECTED]>

--- ./arch/i386/kernel/cpu/amd.c~orig   2007-08-07 20:22:26.0 -0400
+++ ./arch/i386/kernel/cpu/amd.c2007-08-07 20:23:22.0 -0400
@@ -34,7 +34,7 @@ __asm__(".align 4\nvide: ret");
 /* AMD systems with C1E don't have a working lAPIC timer. Check for that. */
 static __cpuinit int amd_apic_timer_broken(void)
 {
-   u32 lo, hi;
+   u32 msr;
u32 eax = cpuid_eax(CPUID_PROCESSOR_SIGNATURE);
switch (eax & CPUID_XFAM) {
case CPUID_XFAM_K8:
@@ -42,8 +42,8 @@ static __cpuinit int amd_apic_timer_brok
break;
case CPUID_XFAM_10H:
case CPUID_XFAM_11H:
-   rdmsr(MSR_K8_ENABLE_C1E, lo, hi);
-   if (lo & ENABLE_C1E_MASK)
+   rdmsrl(MSR_K8_ENABLE_C1E, msr);
+   if (msr & ENABLE_C1E_MASK)
return 1;
 break;
 default:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] xen-netfront: remove dead code

[Jeremy Fitzhardinge]

Jeff Garzik wrote:
> Yes.  It's in my pending-for-2.6.24 folder, since it's not a bug fix.

Great, thanks.

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

Re: [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)

[Trond Myklebust]

On Tue, 2007-08-07 at 17:15 -0700, Andrew Morton wrote:

> Is there any way in which we can prevent these problems?  Say

The problem here is that we occasionally DO need to add new flags, and
yes, they MAY be security related. The whole reason why we're now having
to change the semantics of setattr is because somebody tried to hack
their way around the write+suid issue.

I suspect we will see the exact same thing will happen again in a couple
of years with Serge's ATTR_KILL_PRIV flag.

> - rename something so that unconverted filesystems will reliably fail to
>   compile?
> 
> - leave existing filesystems alone, but add a new
>   inode_operations.setattr_jeff, which the networked filesytems can
>   implement, and teach core vfs to call setattr_jeff in preference to
>   setattr?

If you really need to know that the filesystem is handling the flags,
then how about instead having ->setattr() return something which
indicates which flags it actually handled? That is likely to be a far
more intrusive change, but it is one which is future-proof.

Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] xen-netfront: remove dead code

[Jeff Garzik]

Jeremy Fitzhardinge wrote:

Jeff Garzik wrote:
Please send drivers/net/* through me and netdev... 


Sure.  Did you pick this patch up?


Yes.  It's in my pending-for-2.6.24 folder, since it's not a bug fix.

Jeff



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

Re: [PATCH/RFT] finish i386 and x86-64 sysdata conversion

[Jeff Garzik]

Muli Ben-Yehuda wrote:

On Tue, Aug 07, 2007 at 03:49:11PM -0700, Andrew Morton wrote:


I am sooo tired of this thing.  Andi, someone, can we for heaven's
sake please just get it all sorted out?


With regards to the sysdata conversion: Riku says he cannot test new
kernel. I haven't heard anything from Andy Whitcroft. It passes all of
my tests and what we have now is obviously broken... I think we should
put the fix in.


Strongly agreed.  It overall fixes bugs that existing _before_ the 
sysdata stuff went in.


It was clear the NUMA node was /not initialized/ in all cases, and I 
think it's quite unfair to revert the sysdata stuff because of 
pre-existing bugs (that we are fixing right now anyway).


Jeff



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

[git patches] net driver fixes

[Jeff Garzik]

Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git 
upstream-linus

to receive the following updates:

 drivers/net/atl1/atl1_main.c|4 +--
 drivers/net/ehea/ehea.h |2 +-
 drivers/net/ehea/ehea_main.c|   44 ++
 drivers/net/ibmveth.c   |   27 +---
 drivers/net/ibmveth.h   |3 --
 drivers/net/phy/phy.c   |4 +-
 drivers/net/r8169.c |   24 ++-
 drivers/net/sis190.c|3 ++
 drivers/net/smc91x.h|4 +--
 drivers/net/ucc_geth_ethtool.c  |1 -
 drivers/net/ucc_geth_mii.c  |3 +-
 drivers/net/wireless/bcm43xx/bcm43xx_phy.c  |2 +-
 drivers/net/wireless/rtl8187_dev.c  |2 +-
 drivers/net/wireless/zd1211rw/zd_mac.c  |2 +-
 fs/compat_ioctl.c   |3 --
 net/ieee80211/softmac/ieee80211softmac_wx.c |   11 +--
 16 files changed, 69 insertions(+), 70 deletions(-)

Brian King (1):
  ibmveth: Fix rx pool deactivate oops

Domen Puncer (2):
  ucc_geth: fix section mismatch
  phy layer: fix phy_mii_ioctl for autonegotiation

Francois Romieu (1):
  r8169: avoid needless NAPI poll scheduling

Ingo Molnar (1):
  atl1: use spin_trylock_irqsave()

Jan Altenberg (1):
  ucc_geth: remove get_perm_addr from ucc_geth_ethtool.c

John W. Linville (1):
  Revert "[PATCH] bcm43xx: Fix deviation from specifications in 
set_baseband_attenuation"

Mariusz Kozlowski (1):
  drivers/net/ibmveth.c: memset fix

Masakazu Mokuno (1):
  remove duplicated ioctl entries in compat_ioctl.c

Michael Buesch (1):
  softmac: Fix deadlock of wx_set_essid with assoc work

Michael Wu (1):
  rtl8187: ensure priv->hwaddr is always valid

Neil Muller (1):
  sis190 check for ISA bridge on SiS966

Paul Mundt (1):
  net: smc91x: Build fixes for general sh boards.

Roger So (1):
  r8169: PHY power-on fix

Thomas Klein (3):
  ehea: Fix workqueue handling
  ehea: Simplify resource usage check
  ehea: Eliminated some compiler warnings

Ulrich Kunitz (1):
  zd1211rw: fix filter for PSPOLL frames

diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index 56f6389..3c1984e 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -1704,10 +1704,8 @@ static int atl1_xmit_frame(struct sk_buff *skb, struct 
net_device *netdev)
}
}
 
-   local_irq_save(flags);
-   if (!spin_trylock(>lock)) {
+   if (!spin_trylock_irqsave(>lock, flags)) {
/* Can't get lock - tell upper layer to requeue */
-   local_irq_restore(flags);
dev_printk(KERN_DEBUG, >pdev->dev, "tx locked\n");
return NETDEV_TX_LOCKED;
}
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 8ee2c2c..d67f97b 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@
 #include 
 
 #define DRV_NAME   "ehea"
-#define DRV_VERSION"EHEA_0072"
+#define DRV_VERSION"EHEA_0073"
 
 /* eHEA capability flags */
 #define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 58702f5..9756211 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -1326,7 +1326,6 @@ static void write_swqe2_TSO(struct sk_buff *skb,
u8 *imm_data = >u.immdata_desc.immediate_data[0];
int skb_data_size = skb->len - skb->data_len;
int headersize;
-   u64 tmp_addr;
 
/* Packet is TCP with TSO enabled */
swqe->tx_control |= EHEA_SWQE_TSO;
@@ -1347,9 +1346,8 @@ static void write_swqe2_TSO(struct sk_buff *skb,
/* set sg1entry data */
sg1entry->l_key = lkey;
sg1entry->len = skb_data_size - headersize;
-
-   tmp_addr = (u64)(skb->data + headersize);
-   sg1entry->vaddr = ehea_map_vaddr(tmp_addr);
+   sg1entry->vaddr =
+   ehea_map_vaddr(skb->data + headersize);
swqe->descriptors++;
}
} else
@@ -1362,7 +1360,6 @@ static void write_swqe2_nonTSO(struct sk_buff *skb,
int skb_data_size = skb->len - skb->data_len;
u8 *imm_data = >u.immdata_desc.immediate_data[0];
struct ehea_vsgentry *sg1entry = >u.immdata_desc.sg_entry;
-   u64 tmp_addr;
 
/* Packet is any nonTSO type
 *
@@ -1379,8 +1376,8 @@ static void write_swqe2_nonTSO(struct sk_buff *skb,
/* copy sg1entry data */
sg1entry->l_key = lkey;
sg1entry->len = skb_data_size - SWQE2_MAX_IMM;
-   tmp_addr = (u64)(skb->data + 

Re: [PATCH] ifdef struct task_struct::security

[Andrew Morton]

On Tue, 7 Aug 2007 11:12:02 -0500
"Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:

> Quoting Casey Schaufler ([EMAIL PROTECTED]):
> > 
> > --- "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> > 
> > > Quoting Andrew Morton ([EMAIL PROTECTED]):
> > > > On Mon, 6 Aug 2007 15:31:12 -0500 "Serge E. Hallyn" <[EMAIL PROTECTED]>
> > > wrote:
> > > > 
> > > > > Quoting Alexey Dobriyan ([EMAIL PROTECTED]):
> > > > > > For those who don't care about CONFIG_SECURITY.
> > > > > 
> > > > > I'm quite sure we started that way, but the ifdefs were considered
> > > > > too much of an eyesore.
> > > > 
> > > > argh, y'all stop top-posting at me.
> > > 
> > > (Hmm, I'm replying at the point in the email I'm replying to.  Is what
> > > I'm doing in this current email ok - i.e the one you replied to looked
> > > like pure top-posting - or do you actually want pure bottom posting?)
> > > 
> > > > > If this is now acceptable, then the same thing might be considered
> > > > > for inode->i_security, kern_ipc_perm.security, etc.  Getting rid of
> > > > > just the task->security seems overly half-hearted.
> > > > > 
> > > > > -serge
> > > > > 
> > > > > > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
> > > > > > ---
> > > > > > 
> > > > > >  include/linux/sched.h |3 ++-
> > > > > >  kernel/fork.c |2 ++
> > > > > >  2 files changed, 4 insertions(+), 1 deletion(-)
> > > > > > 
> > > > > > --- a/include/linux/sched.h
> > > > > > +++ b/include/linux/sched.h
> > > > > > @@ -1086,8 +1086,9 @@ struct task_struct {
> > > > > > int (*notifier)(void *priv);
> > > > > > void *notifier_data;
> > > > > > sigset_t *notifier_mask;
> > > > > > -   
> > > > > > +#ifdef CONFIG_SECURITY
> > > > > > void *security;
> > > > > > +#endif
> > > > > > struct audit_context *audit_context;
> > > > > > seccomp_t seccomp;
> > > > > >  
> > > > > > --- a/kernel/fork.c
> > > > > > +++ b/kernel/fork.c
> > > > > > @@ -1066,7 +1066,9 @@ static struct task_struct 
> > > > > > *copy_process(unsigned
> > > long clone_flags,
> > > > > > do_posix_clock_monotonic_gettime(>start_time);
> > > > > > p->real_start_time = p->start_time;
> > > > > > monotonic_to_bootbased(>real_start_time);
> > > > > > +#ifdef CONFIG_SECURITY
> > > > > > p->security = NULL;
> > > > > > +#endif
> > > > > > p->io_context = NULL;
> > > > > > p->io_wait = NULL;
> > > > > > p->audit_context = NULL;
> > > > > > 
> > > > 
> > > > I think it's OK.  Removing 4 or 8 bytes from the task_struct is a decent
> > > win,
> > > > and an ifdef at the definition site (unavoidable) and at a single
> > > > initialisation site where there are lots of other similar ifdefs is 
> > > > pretty
> > > > minimal hurt.
> > > 
> > > Then how about making it depend on CONFIG_SECURITY_SELINUX?  It's the
> > > only LSM actually using that field right now.  (As more come along, we
> > > can use a hidden CONFIG_SECURITY_ATTRS or somesuch bool select'ed by
> > > LSMs which need it)
> > 
> > I would greatly appreciate it if you didn't add yet another place
> > that requires deselinuxifation by anyone wanting to try something else.
> > The question is whether there is any LSM, not whether there is selinux.
> > Yes, I know that there are no other LSMs upstream today. I hope to
> > change that before too long, and dealing with places where the code is
> > using the LSM==SELinux assumption is tiresome.
> 
> So jump straight to using CONFIG_SECURITY_USE_LABELS or whatever, as I
> mentioned.
> 

Well I've lost the plot here, but I'm all for shrinking task_struct on
small systems, so I'll trollmerge Alexey's original diff.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/RFC: [kdump] fix APIC shutdown sequence

[Andrew Morton]

On Mon, 06 Aug 2007 17:08:05 +0200
Martin Wilck <[EMAIL PROTECTED]> wrote:

> PATCH/RFC: [kdump] fix APIC shutdown sequence
> 
> This patch fixes a problem that we have encountered
> with kdump under high I/O load on some machines.
> The machines showing the errors have an Intel ICH7
> chip set with a 6702PXH  PCI Express-to-PCI Bridge
> (8086:032c) containing an IO-APIC.
> 
> The bug symptom is that certain controllers connected
> to the 6702PXH bridge wouldn't receive any IRQs in the
> kdump kernel. In the error case (which is about 20% of
> all cases) the IRR bit of the IO-APIC pin for that
> controller is always set after the start of the kdump
> kernel, indicating an IRQ in progress. We haven't found
> a way to recover from this situation when it has once
> occured, except for a system reset.
> 
> The error is caused by IRQs arriving while the APIC
> subsystem is deactivated in machine_crash_shutdown().
> 
> Apparently, the IO-APIC gets stuck if it sends an IRQ
> message to a Local APIC and never receives an EOI for that
> message. This can have several possible reasons:
> 
> 1. If, under SMP, the IO-APIC logical destination field is
>set by the IRQ balancing code to one of the "other"
>CPUs (i.e. not the crashing_cpu), and an IRQ arrives
>on the respective pin after that CPU has shut down
>its local APIC (but before the IO-APIC pin is masked)
>the IRQ message can't be delivered.
> 
> 2. The crashing CPU itself disables its local APIC
>before the IO-APIC, leaving a short time window
>where the IOAPIC can receive IRQs, but not
>deliver them.
> 
> 3. An IRQ is received and delivered to a local APIC, but
>no CPU ever executes the IRQ handler and therefore no
>EOI is sent.
> 
> After a lot of failed attempts, i have come up with the
> following patch, which fixes the problem.
> 
> The patch first masks all IO-Apic pins to avoid a sitation
> where the IO-Apic can receive, but not deliver, the IRQs.
> Moreover, it enables interrupts for a short period before
> eventually starting the kdump kernel, so that EOIs can be
> sent to the APICs as necessary.
> 
> Notes:
> a) Simply calling disable_IO_APIC() early doesn't
> work, probably because that also clears the IRQ vector
> information, so that arriving EOI messages can't be
> associated with pins by the IO-APIC.
> b) We have tried patches that avoid re-enabling interrupts,
> but so far without success. Re-enabling IRQs is of course
> dangerous while dumping, and I'd rather find a way to avoid it.
> c) There are indications that besides the EOI, it's also
> necessary that the PCI IRQ pin is deasserted at least for
> a short time. That usually requires that the driver IRQ
> handler is called and tells the FW that the IRQ was received.
> Whether or not this is a requirement hasn't been finally
> clarified yet.
> d) The problem is only seen with the IO-APIC in the 6702PXH
> PCI bridge, which is the system's secondary IO-APIC. On the
> system's main IO-APIC, we see other IRQs (timer etc) arrive
> and never get an EOI, but we see no errors.
> 
> The patch below is against 2.6.23-rc1. The problem was
> originally analyzed and the patch developed against the
> Red Hat EL5 kernel (2.6.18-8.el5). I verified that the
> problem still occurs with 2.6.23-rc1, and that the patch
> below fixes the problem.
> 

Some little things..

Please feed the diff through scripts/checkpatch.pl.  It finds a lot of issues.

For some reason you added a lot of lines which start with space-tab rather
than tab.  checkpatch does detect this.


> diff -puN arch/x86_64/kernel/crash.c~kdump-fix-apic-shutdown-sequence 
> arch/x86_64/kernel/crash.c
> --- a/arch/x86_64/kernel/crash.c~kdump-fix-apic-shutdown-sequence
> +++ a/arch/x86_64/kernel/crash.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -30,6 +31,11 @@ static int crashing_cpu;
>  
>  #ifdef CONFIG_SMP
>  static atomic_t waiting_for_crash_ipi;
> +static atomic_t crash_ipi_stage2 = ATOMIC_INIT(0);
> +
> +extern void remove_siblinginfo(int);
> +extern void remove_cpu_from_maps(void);
> +extern void crash_mask_IO_APIC(int);

please neverevereverever put extern declarations in C files.  Find a
suitable header for it, ensure that the header is included by the
definition site and by all callers.

>  static int crash_nmi_callback(struct notifier_block *self,
>   unsigned long val, void *data)
> @@ -53,13 +59,30 @@ static int crash_nmi_callback(struct not
>   local_irq_disable();
>  
>   crash_save_cpu(regs, cpu);
> - disable_local_APIC();
> - atomic_dec(_for_crash_ipi);
> + disable_APIC_timer();
> +atomic_dec(_for_crash_ipi);
> +
> + while(atomic_read(_ipi_stage2) == 0)

Need a space here.  Everything I've mentioned thus far should have been
picked up by checkpatch, so I'll shut up now.

> +
> +static void nmi_shootdown_cpus_stage2(void)
> +{
> +
> + unsigned long msecs;
> + 

Re: Disk spin down issue on shut down/suspend to disk

[Robert Hancock]

Henrique de Moraes Holschuh wrote:

On Tue, 07 Aug 2007, Tejun Heo wrote:

Henrique de Moraes Holschuh wrote:

On Tue, 07 Aug 2007, Tejun Heo wrote:

Michael Sedkowski wrote:

Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
pulling unnecessary stunt.  Please apply the attached patch and report
when the disk spins down and up.

Disk spins down on "Pre-shutdown prepare" and then goes up and down on
"Power down".

Oh... crap, so acpi wants to sync cache on shutdown.  I wonder whether
it spins down the disk correctly.  Does emergency unload count increase
after each power down?  Also, please post the result of 'dmidecode'.

You know, this actually make a lot of sense, and one can't even complain
about firmware that pulls that off.

Well, I'm complaining.  I think the problem here is that it isn't clear
which one is who's responsibility.  There's a Korean saying which


The BIOS *has* to do it when in DOS mode, the HD manuals are very very clear
about it.  Doing it through ACPI ATA objects is at least non-broken as far
as these things go, as one knows when to do it directly ("non-ACPI mode"),
and one doesn't talk to the disk directly.


approximately translates into "if you have too many boatmen on a ship,
it goes to mountain".  We also have a bunch of Toshiba laptops which


Yeah, that's a problem.  But we can avoid it if we start snooping what ACPI
is asking us to deliver to the disks, which IMO is an extremely good idea
anyway.


Problem is I don't think we can do this. As far as I can tell, on my 
Compaq at least, it's not being done through ACPI AML in the DSDT, like 
in the _PTS function (which the kernel executes and can snoop), but when 
we actually do the power-off we write a value to a magic ACPI register. 
That likely triggers the BIOS to take control in SMM mode and access the 
controller directly before triggering the power off, which we have no 
control or knowledge of.





want the ATA controller to be in enabled state when ACPI suspend is
invoked because the suspend method apparently wants to execute some
commands before going to sleep.


That's just broken, since it is not even using a OS-backed SATA/ATA ACPI
method to do it.


I wish ACPI spec carries a big fat sign saying "stay f*** away from
anything which isn't essential to the requested operation".


Shutting down disks *is* essential to the power off operation.  ACPI would
have to mandate who is to do it, instead (ACPI table or OSI by itself).


Any chances of changing things
so that we inspect/snoop all tasks sent to the device, and filter them
out, or react to them accordingly?

No, we can't unless we snoop ACPI method execution and detect accesses
to IO ports or iomem regions.  It's not going through any driver.  This
is a gross mess.


I don't mean fixing the stuff clowns like Toshiba did.  The correct fix for
that is to blacklist the hell out of that crap and patch their DSDT into
something remotely sane.

I do mean snooping the ACPI methods that *return* a taskset to send to the
driver, and we send that taskset ourselves in libata and libpata(?).



--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

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

Re: [PATCH 04/10] mm: slub: add knowledge of reserve pages

[Christoph Lameter]

On Mon, 6 Aug 2007, Peter Zijlstra wrote:

> Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to allocation
> contexts that are entitled to it.

Is this patch actually necessary?

If you are in an atomic context and bound to a cpu then a per cpu slab is 
assigned to you and no one else can take object aways from that process 
since nothing else can run on the cpu. The point of the patch is to avoid 
other processes draining objects right? So you do not need the 
modifications in that case.

If you are not in an atomic context and are preemptable or can switch 
allocation context then you can create another context in which reclaim 
could be run to remove some clean pages and get you more memory. Again no 
need for the patch.

I guess you may be limited in not being able to call into reclaim again 
because it is already running. Maybe that can be fixed? F.e. zone reclaim 
does that for the NUMA case. It simply scans for easily reclaimable pages.

We could guarantee easily reclaimable pages to exist in much larger 
numbers than the reserves of min_free_kbytes. So in a tight spot one could 
reclaim from those.

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

Re: [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)

[Andrew Morton]

On Mon, 6 Aug 2007 09:54:03 -0400
Jeff Layton <[EMAIL PROTECTED]> wrote:

> Apologies for the resend, but the original sending had the date in the
> email header and it caused some of these to bounce...
> 
> ( Please consider trimming the Cc list if discussing some aspect of this
> that doesn't concern everyone.)
> 
> When an unprivileged process attempts to modify a file that has the
> setuid or setgid bits set, the VFS will attempt to clear these bits. The
> VFS will set the ATTR_KILL_SUID or ATTR_KILL_SGID bits in the ia_valid
> mask, and then call notify_change to clear these bits and set the mode
> accordingly.
> 
> With a networked filesystem (NFS in particular but most likely others),
> the client machine may not have credentials that allow for the clearing
> of these bits. In some situations, this can lead to file corruption, or
> to an operation failing outright because the setattr fails.
> 
> In this situation, we'd like to just leave the handling of this to
> the server and ignore these bits. The problem is that by the time
> nfs_setattr is called, the VFS has already reinterpreted the ATTR_KILL_*
> bits into a mode change. We can't fix this in the filesystems where
> this is a problem, as doing so would leave us having to second-guess
> what the VFS wants us to do. So we need to change it so that filesystems
> have more flexibility in how to interpret the ATTR_KILL_* bits.
> 
> The first patch in the following patchset moves this logic into a helper
> function, and then only calls this helper function for inodes that do
> not have a setattr operation defined. The subsequent patches fix up
> individual filesystem setattr functions to call this helper function.
> 
> The upshot of this is that with this change, filesystems that define
> a setattr inode operation are now responsible for handling the ATTR_KILL
> bits as well. They can trivially do so by calling the helper, but they
> must do so.
> 
> Some of the follow-on patches may not be strictly necessary, but I
> decided that it was better to take the conservative approach and call
> the helper when I wasn't sure. I've tried to CC the maintainers
> for the individual filesystems as well where I could find them,
> please let me know if there are others who should be informed.
> 
> Comments and suggestions appreciated...
> 

>From a purely practical standpoint: it's a concern that all filesytems need
patching to continue to correctly function after this change.  There might
be filesystems which you missed, and there are out-of-tree filesystems
which won't be updated.

And I think the impact upon the out-of-tree filesystems would be fairly
severe: they quietly and subtly get their secutiry guarantees broken (I
think?)

Is there any way in which we can prevent these problems?  Say

- rename something so that unconverted filesystems will reliably fail to
  compile?

- leave existing filesystems alone, but add a new
  inode_operations.setattr_jeff, which the networked filesytems can
  implement, and teach core vfs to call setattr_jeff in preference to
  setattr?

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

Re: Disk spin down issue on shut down/suspend to disk

[Robert Hancock]

Henrique de Moraes Holschuh wrote:

On Tue, 07 Aug 2007, Tejun Heo wrote:

emergency unload.  Emergency unload does shorten the lifespan of the
disk but you don't have to worry too much about it.  Disks are designed
to withstand certain number of emergency unloads.


You *do* have to worry about it in any box you turn off daily.  Desktop HDs
will croak fast in that scenario, laptop HDs less so, but still too fast.

A very good laptop HD can last about 20k emergency unloads (this is a unit
that can do about 600k normal unloads in its lifetime).  Desktop and server
HDs don't even come close to those numbers, last time I checked.


It only matters on hard drives which actually use load-unload heads. 
Lots of desktop/server drives (perhaps some laptop ones as well) still 
use contact start/stop, which doesn't remove the heads from the platters 
on shutdown but just parks the heads over the landing zone. I don't 
think arbitrary power-offs make too much difference on those drives. 
(However, these generally aren't rated to handle as many start/stop 
cycles, which is why laptop drives generally use load/unload instead.)


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

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

nmi_watchdog=2 regression in 2.6.21

[Daniel Walker]

This patch below hangs my system on boot if I set nmi_watchdog=2 . It
shows the NMI as stuck then the system hangs .. nmi_watchdog=1 works
fine, and the system boots without any watchdog options ..

The machine is an Intel allagash development board, and it has two dual
core Pentium-M cpus. I attached the .config I used.

bf8696ed6dfa561198b4736deaf11ab68dcc4845 is first bad commit
commit bf8696ed6dfa561198b4736deaf11ab68dcc4845
Author: Stephane Eranian <[EMAIL PROTECTED]>
Date:   Wed May 2 19:27:05 2007 +0200

[PATCH] i386: i386 make NMI use PERFCTR1 for architectural perfmon (take 2)

Hello,

This patch against 2.6.20-git14 makes the NMI watchdog use PERFSEL1/PERFCTR1
instead of PERFSEL0/PERFCTR0 on processors supporting Intel architectural
perfmon, such as Intel Core 2. Although all PMU events can work on
both counters, the Precise Event-Based Sampling (PEBS) requires that the
event be in PERFCTR0 to work correctly (see section 18.14.4.1 in the
IA32 SDM Vol 3b).

A similar patch for x86-64 is to follow.

Changelog:
- make the i386 NMI watchdog use PERFSEL1/PERFCTR1 instead of 
PERFSEL0/PERFCTR0
  on processors supporting the Intel architectural perfmon (e.g. 
Core 2 Duo).
  This allows PEBS to work when the NMI watchdog is active.

signed-off-by: stephane eranian <[EMAIL PROTECTED]>

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

:04 04 9cee0745798cb56da2ca82032b8ee88a2c32700a 
f59ee02e3cd8f13503edb7312a3494f4d7ec0069 M  arch

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21
# Tue Aug  7 16:40:44 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Processor type and features
#
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_SMP=y
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_PARAVIRT is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUMM=y
# CONFIG_MCORE2 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6

Re: ACPI on Averatec 2370

[Andi Kleen]

On Tue, Aug 07, 2007 at 06:15:37PM -0400, Cal Peake wrote:
> On Fri, 3 Aug 2007, Linus Torvalds wrote:
> 
> > > MSR_K8_ENABLE_C1E lo == 0x04c14015
> > > MSR_K8_ENABLE_C1E hi == 0x
> > > lo & ENABLE_C1E_MASK == 0
> > 
> > And yeah, that claims that C1E is not on, but:
> > 
> > > amd_apic_timer_broken: forcing return value of 1
> 
> So it seems my initial debugging report was, err, incomplete. I failed to 
> notice that the amd_apic_timer_broken function was getting called twice, 
> once for each core.
> 
> The second call shows this:
> 
>   MSR_K8_ENABLE_C1E == 0x14c14015

Ah interesting. Ok finally that all starts making sense.

Not sure why the MSR varies between cores though.

> which causes our ENABLE_C1E_MASK check to be true and thus properly 
> return 1 from the function. So when we call the above function from 
> init_amd we prolly need to do a
> 
>   set_bit(X86_FEATURE_LAPIC_TIMER_BROKEN, c->x86_capability);
> 
> for each core if any of them happen to return true upon checking for a 
> broken timer.

It's better to just make it a global instead.

-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: i386: kernel boot fail at check_irq_resend:69

[Robert Hancock]

Dave Young wrote:

On 8/7/07, Li Yang-r58472 <[EMAIL PROTECTED]> wrote:
  -Original Message-

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Young
Sent: Tuesday, August 07, 2007 2:32 PM
To: [EMAIL PROTECTED]
Cc: LKML
Subject: i386: kernel boot fail at check_irq_resend:69

Hi,
The kernerl 2.6.23-rc1-mm2 boot fail at check_irq_resend:69
   > if (WARN_ON_ONCE(desc->handle_irq != handle_edge_irq))
   >return;

Failed?  It's just a kernel Badness for me, and the boot can be finished.


No, my kernel panic after this. noapic does not help too.
Regards
dave


That warning should not cause a panic. Is there another message after it?

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

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

Re: allow non root users to set io priority "idle" ?

[Andi Kleen]

On Wed, Aug 08, 2007 at 12:18:12AM +0200, dragoran wrote:
> so there is no real reason not to allow it for non root users?
> removing the check is easy (3 lines) 
> or are there any other issues/problems?

Jens was only talking about the seek issue I mentioned I believe;
not about the PI problem.

-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: Data corruption

[Chris Snook]

paul wrote:
Since 2-3 month I have some random data corruption on my Linux server, after 
checking disks independently (i'm using raid1on 2 sata disk, the problem is 
the same w/o raid) and memory, hardware simce to be out of cause...


Here is my problem:
=> head --bytes=300m  /dev/urandom > test
=> for i in `seq 0 9` ; do cp test test$i ; done
=> md5sum test*
I got : 
014666c728c9e3b8299579fae499864a  test

014666c728c9e3b8299579fae499864a  test0
333fd93d093ac612cd8d5f65628f734e  test1
1ab6ee68c6a7d9ff5a05f9d63f0f6df6  test2
96e96483e3175a59c9c05b6720514e1e  test3
014666c728c9e3b8299579fae499864a  test4
b24dbccc9f4831f8825ab4a55a3be4aa  test5
8493efc9c14e4b5c162ac23696fbc16a  test6
6a5f4301f66d0379049d79d0e14e2a87  test7
2c81cfa1c3a03aba134574922ee5d75c  test8
2ea15c8392bfd0123472a80125bb3abe  test9

^^^ that sounds really bad for my data :(


It does indeed.  Can you try comparing the data to see precisely how much 
differs between the versions?  md5sums don't distinguish between a single-bit 
error and a block or page-sized error, but the distinction is critical in 
determining what broke.


Can you reproduce this on a recent upstream baremetal (non-Xen) kernel?  If so, 
does it go away when you boot with mem=3000M?


-- 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: refcounting problems with ibm_acpi but acpi=off

[Henrique de Moraes Holschuh]

On Tue, 07 Aug 2007, Pavel Machek wrote:
> > > --- a/drivers/acpi/ibm_acpi.c
> > > +++ b/drivers/acpi/ibm_acpi.c
> > > @@ -2695,6 +2695,9 @@ static void acpi_ibm_exit(void)
> > >  {
> > >   int i;
> > >  
> > > + if (acpi_disabled)
> > > + return;
> > > +
> > >   for (i = ARRAY_SIZE(ibms) - 1; i >= 0; i--)
> > >   ibm_exit([i]);
> > >  
> > > 
> > 
> > Indeed it is required, my bad.
> > 
> > Acked-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
> > 
> > Do you want me to forward a git patch to Len brown?
> 
> Yes, please. Hmm, seems like at least asus_acpi is affected by same problem.

I just tested it, and thinkpad-acpi with all accepted patches by Len is not
affected by this problem, only some versions of ibm-acpi is.  So there's
nothing to send to Len.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 3/5] pagemap: remove open-coded sizeof(unsigned long)

[Dave Hansen]

On Tue, 2007-08-07 at 18:40 -0500, Matt Mackall wrote:
> On Tue, Aug 07, 2007 at 03:33:02PM -0700, Dave Hansen wrote:
> > +#define PAGEMAP_ENTRY_SIZE_BYTES sizeof(unsigned long)
> > +
> >  static int add_to_pagemap(unsigned long addr, unsigned long pfn,
> >   struct pagemapread *pm)
> >  {
> > __put_user(pfn, pm->out);
> > pm->out++;
> > -   pm->pos += sizeof(unsigned long);
> > -   pm->count -= sizeof(unsigned long);
> > -   pm->next = addr + PAGE_SIZE;
> > +   pm->pos += PAGEMAP_ENTRY_SIZE_BYTES;
> > +   pm->count -= PAGEMAP_ENTRY_SIZE_BYTES;
> 
> I think deleting ->next is a little premature here?

It is.  I'll fix that up.

-- 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] powerpc: Use linux/elfcore-compat.h

[Roland McGrath]

> There is hardly anything interesting remaining in 
> arch/powerpc/kernel/binfmt_elf32.c after your patch.
> 
> Do you think it's reasonable to go one step further and
> turn the file into a completely generic fs/binfmt_elf32.c
> that can be used by all 32/64 compat architectures?

There is certainly more cleanup that can be done.  
This was just an easy incremental step.

It's not going to get quite to "completely generic".  On other machines the
32/64 flavors are not quite as similar as on powerpc, so there is some more
code required there.  There will have to be a lot of per-arch macros and
functions, even if they are unified to compat_* names.


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

Re: [RFC][PATCH 3/5] pagemap: remove open-coded sizeof(unsigned long)

[Matt Mackall]

On Tue, Aug 07, 2007 at 03:33:02PM -0700, Dave Hansen wrote:
> +#define PAGEMAP_ENTRY_SIZE_BYTES sizeof(unsigned long)
> +
>  static int add_to_pagemap(unsigned long addr, unsigned long pfn,
> struct pagemapread *pm)
>  {
>   __put_user(pfn, pm->out);
>   pm->out++;
> - pm->pos += sizeof(unsigned long);
> - pm->count -= sizeof(unsigned long);
> - pm->next = addr + PAGE_SIZE;
> + pm->pos += PAGEMAP_ENTRY_SIZE_BYTES;
> + pm->count -= PAGEMAP_ENTRY_SIZE_BYTES;

I think deleting ->next is a little premature here?

-- 
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: [PATCH] remove binfmts.h from header exports

[Rene Herman]

On 08/07/2007 10:16 PM, Olaf Hering wrote:


remove linux/binfmts.h from make headers_install

A recent patch added PAGE_SIZE to the part outside of __KERNEL__.
qemu and ia32el have their own define of MAX_ARG_PAGES.
No package uses linux/binfmts.h, so it is safe to not provide it.


How is "all packages" defined?

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

Re: [2.6.22.2 review 06/84] Add a PCI ID for santa rosas PATA controller.

[Chr]

On Tuesday, 7. August 2007, Greg KH wrote:
> 
> From: Christian Lamparter <[EMAIL PROTECTED]>
> 
> This is commit c1e6f28cc5de37dcd113b9668a185c0b9334ba8a which is
> merged during 23-rc1 window.  Considering the popularity of these
> chips, I think including it in -stable release would be good idea.
> 
> Signed-off-by: Christian Lamparter <[EMAIL PROTECTED]>
> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> 

I did not receive any complains. I guess it's stable enough for -stable ;-) ...

--- 

Not OT: 

There is another outstanding issue with ata_piix.c.
Intel has never officially supported anything faster than PATA 100MB/s.

But, the ata_piix.c driver "define" the ICH5 & ICH7 as UDMA6 (aka 133MB/s) 
capable.
[ Well, no one has probably noticed it before, because there is bug in 
do_pata_set_dmamode... 
Just look at libata_atapiix_enable_real_udma133.patch and you'll see what wrong 
with it. ] 

Here are Intel's datasheets for the affected chipsets:
ICH5 Datasheet: http://www.intel.com/design/chipsets/datashts/252516.htm
(See note on page 183: "... the ICH5 supports reads at the maximum rate of 
100MB/s.")

ICH7 Datasheet: http://www.intel.com/design/chipsets/datashts/307013.htm
(See first note on page 190: "... the ICH7 supports reads at the maximum rate 
of 100MB/s.")

-

They are two different ways to deal with it:

- Either -

1. replace all ich_pata_133 with ich_pata_100. 
   (libata_atapiix_disable_udma6.diff - diff from 2.6.22 )

- Or -

2. keep all ich_pata_133 and fix the bug in "do_pata_set_dmamode".
   (libata_atapiix_enable_real_udma133.patch - diff from 2.6.22) 
   If there are any concerns about the safety of the patch patch: 
   http://lkml.org/lkml/2007/7/6/292 (It was already tested by an Intel 
employee,
   but I guess a bit more user input is necessary here... )

Both ways have their pros and cons. Unfortunately, I don't have the time to 
follow this
discussion right now, so here's a: 

Signed-off-by: Christian Lamparter <[EMAIL PROTECTED]>
(Just in case, if one of the patches really gets merged!)

Thanks,
Chr. 

--- a/drivers/ata/ata_piix.c	2007-08-08 00:52:52.0 +0200
+++ b/drivers/ata/ata_piix.c	2007-08-08 00:55:45.0 +0200
@@ -122,7 +122,7 @@ enum {
 	ich_pata_33		= 1,	/* ICH up to UDMA 33 only */
 	ich_pata_66		= 2,	/* ICH up to 66 Mhz */
 	ich_pata_100		= 3,	/* ICH up to UDMA 100 */
-	ich_pata_133		= 4,	/* ICH up to UDMA 133 */
+	/* ICH up to UDMA 133 is not supported */
 	ich5_sata		= 5,
 	ich6_sata		= 6,
 	ich6_sata_ahci		= 7,
@@ -190,7 +190,7 @@ static const struct pci_device_id piix_p
 	{ 0x8086, 0x24CA, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 	{ 0x8086, 0x24CB, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 	/* Intel ICH5 */
-	{ 0x8086, 0x24DB, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_133 },
+	{ 0x8086, 0x24DB, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 	/* C-ICH (i810E2) */
 	{ 0x8086, 0x245B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 	/* ESB (855GME/875P + 6300ESB) UDMA 100  */
@@ -198,7 +198,7 @@ static const struct pci_device_id piix_p
 	/* ICH6 (and 6) (i915) UDMA 100 */
 	{ 0x8086, 0x266F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 	/* ICH7/7-R (i945, i975) UDMA 100*/
-	{ 0x8086, 0x27DF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_133 },
+	{ 0x8086, 0x27DF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 	{ 0x8086, 0x269E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 
 	/* NOTE: The following PCI ids must be kept in sync with the
@@ -479,7 +479,7 @@ static struct ata_port_info piix_port_in
 		.port_ops	= _pata_ops,
 	},
 
-	/* ich_pata_133: 4 	ICH with full UDMA6 */
+	/* ich_pata_133: 4 - Not supported - */
 	{
 		.sht		= _sht,
 		.flags		= PIIX_PATA_FLAGS | PIIX_FLAG_CHECKINTR,
--- a/drivers/ata/ata_piix.c	2007-08-08 00:52:52.0 +0200
+++ b/drivers/ata/ata_piix.c	2007-08-08 00:53:03.0 +0200
@@ -765,8 +765,8 @@ static void do_pata_set_dmamode (struct 
 		 *	   except UDMA0 which is 00
 		 */
 		u_speed = min(2 - (udma & 1), udma);
-		if (udma == 5)
-			u_clock = 0x1000;	/* 100Mhz */
+		if (udma >= 5)
+			u_clock = 0x1000;	/* 133Mhz */
 		else if (udma > 2)
 			u_clock = 1;		/* 66Mhz */
 		else

Re: [PATCH] msleep() with hrtimers

[Andrew Morton]

On Wed, 8 Aug 2007 01:16:49 +0200 (CEST)
Roman Zippel <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> On Tue, 7 Aug 2007, Andrew Morton wrote:
> 
> > I'd be surprised if there was significant overhead - the maximum frequency
> > at which msleep() can be called is 1000Hz.  We'd need an awful lot of
> > overhead for that to cause problems, surely?
> > 
> > 
> 
> _Anybody_ has yet to answer what's wrong with adding a nanosleep() and 
> using that instead.
> 

You mean that the implementation could be simplified if msleep() were to
simply call do_nanosleep()?

That would work, although a bit of refactoring would be needed so that we
could implement the TASK_UNINTERRUPTIBLE msleep() that way.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] serial inter-character timeout usage with async io

[Harvey Chapman]

I'm looking for comments, thanks.

This patch adds a timeout mode to n_tty that will only send SIGIO
signals (for input) when the UART's IIR indicates that a character
timeout has occurred. This reduces overhead by reducing the number of
SIGIO signals sent and consequently the unnecessary wake-ups of a
sleeping process waiting for serial input asynchronously.

two boolean values "timeout_enabled" and "timeout" are added to
tty_struct which enable/disable the mode and record whether an
inter-character timeout occurred during the last interrupt, respectively.

A new ioctl, TIOCSTIMEOUT, is added to set/clear "timeout_enabled." This
seemed to be the cleanest way to do that (that I saw, at least).

In n_tty_receive_buf(), some additional tests were added before the
kill_async() call to accommodate the old behavior and the newer timeout
behavior as well as adding a check to make sure the read buffer doesn't
overflow without a timeout received.

This should be 100% backwards compatible since the timeout mode is
disabled by default.

Currently, I only have this code enabled for i386 and arm, and only for
the 8250 and pxa serial drivers. If no one thinks this is a terrible
idea, I'll modify all of the other ioctl.h files and resubmit the patch.

Thanks,

Harvey


diff -urp -x '*.orig' -x '*.rej' -x '*~'
linux-2.6.22.1.orig/drivers/char/n_tty.c linux-2.6.22.1/drivers/char/n_tty.c
--- linux-2.6.22.1.orig/drivers/char/n_tty.c2007-07-10
14:56:30.0 -0400
+++ linux-2.6.22.1/drivers/char/n_tty.c 2007-08-07 18:23:44.0 -0400
@@ -957,7 +957,17 @@ static void n_tty_receive_buf(struct tty

n_tty_set_room(tty);

-   if (!tty->icanon && (tty->read_cnt >= tty->minimum_to_wake)) {
+   /*
+* Make sure we're not in canonical mode. If not in timeout mode,
+* use vmin setting as usual. If in timeout mode, only send if the
+* last interrupt was a timeout. As a last resort, check to make
+* sure the read buffer doesn't get too close to full. The factor of
+* 4 used is an arbitrary number.
+*/
+   if (!tty->icanon &&
+   ((!tty->timeout_enabled && (tty->read_cnt >= tty->minimum_to_wake)) 
||
+tty->timeout ||
+tty->receive_room < (4 * TTY_THRESHOLD_THROTTLE))) {
kill_fasync(>fasync, SIGIO, POLL_IN);
if (waitqueue_active(>read_wait))
wake_up_interruptible(>read_wait);
diff -urp -x '*.orig' -x '*.rej' -x '*~'
linux-2.6.22.1.orig/drivers/char/tty_ioctl.c
linux-2.6.22.1/drivers/char/tty_ioctl.c
--- linux-2.6.22.1.orig/drivers/char/tty_ioctl.c2007-07-10
14:56:30.0 -0400
+++ linux-2.6.22.1/drivers/char/tty_ioctl.c 2007-08-07
15:11:23.0 -0400
@@ -852,6 +852,15 @@ int n_tty_ioctl(struct tty_struct * tty,
 (arg ? CLOCAL : 0));
mutex_unlock(>termios_mutex);
return 0;
+
+   case TIOCSTIMEOUT:
+   if (get_user(arg, (unsigned int __user *) arg))
+   return -EFAULT;
+   tty->timeout_enabled = (arg ? 1 : 0);
+   tty->minimum_to_wake = 0;
+   MIN_CHAR(tty) = 0;
+   return 0;
+
default:
return -ENOIOCTLCMD;
}
diff -urp -x '*.orig' -x '*.rej' -x '*~'
linux-2.6.22.1.orig/drivers/serial/8250.c
linux-2.6.22.1/drivers/serial/8250.c
--- linux-2.6.22.1.orig/drivers/serial/8250.c   2007-07-10
14:56:30.0 -0400
+++ linux-2.6.22.1/drivers/serial/8250.c2007-08-07 17:29:24.0 
-0400
@@ -1466,6 +1466,12 @@ static irqreturn_t serial8250_interrupt(

iir = serial_in(up, UART_IIR);
if (!(iir & UART_IIR_NO_INT)) {
+   /* Flag an inter-character timeout */
+   if (up->port.info->tty->timeout_enabled &&
+   (iir & UART_IIR_TOD) == UART_IIR_TOD)
+   up->port.info->tty->timeout = 1;
+   else
+   up->port.info->tty->timeout = 0;
serial8250_handle_port(up);

handled = 1;
diff -urp -x '*.orig' -x '*.rej' -x '*~'
linux-2.6.22.1.orig/drivers/serial/pxa.c linux-2.6.22.1/drivers/serial/pxa.c
--- linux-2.6.22.1.orig/drivers/serial/pxa.c2007-07-10
14:56:30.0 -0400
+++ linux-2.6.22.1/drivers/serial/pxa.c 2007-08-07 17:29:59.0 -0400
@@ -238,6 +238,12 @@ static inline irqreturn_t serial_pxa_irq
iir = serial_in(up, UART_IIR);
if (iir & UART_IIR_NO_INT)
return IRQ_NONE;
+   /* Flag an inter-character timeout */
+   if (up->port.info->tty->timeout_enabled &&
+   (iir & UART_IIR_TOD) == UART_IIR_TOD)
+   up->port.info->tty->timeout = 1;
+   else
+   up->port.info->tty->timeout = 0;