[patch 02/24] uinput: use completions

[Dmitry Torokhov]

Input: uinput - use completions instead of events and manual
   wakeups in force feedback code.

Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---

 drivers/input/misc/uinput.c |   81 +++-
 include/linux/uinput.h  |5 +-
 2 files changed, 45 insertions(+), 41 deletions(-)

Index: work/drivers/input/misc/uinput.c
===
--- work.orig/drivers/input/misc/uinput.c
+++ work/drivers/input/misc/uinput.c
@@ -53,24 +53,23 @@ static int uinput_dev_event(struct input
return 0;
 }
 
-static int uinput_request_alloc_id(struct input_dev *dev, struct 
uinput_request *request)
+static int uinput_request_alloc_id(struct uinput_device *udev, struct 
uinput_request *request)
 {
/* Atomically allocate an ID for the given request. Returns 0 on 
success. */
-   struct uinput_device *udev = dev->private;
int id;
int err = -1;
 
-   down(>requests_sem);
+   spin_lock(>requests_lock);
 
for (id = 0; id < UINPUT_NUM_REQUESTS; id++)
if (!udev->requests[id]) {
-   udev->requests[id] = request;
request->id = id;
+   udev->requests[id] = request;
err = 0;
break;
}
 
-   up(>requests_sem);
+   spin_unlock(>requests_lock);
return err;
 }
 
@@ -79,70 +78,78 @@ static struct uinput_request* uinput_req
/* Find an input request, by ID. Returns NULL if the ID isn't valid. */
if (id >= UINPUT_NUM_REQUESTS || id < 0)
return NULL;
-   if (udev->requests[id]->completed)
-   return NULL;
return udev->requests[id];
 }
 
-static void uinput_request_init(struct input_dev *dev, struct uinput_request 
*request, int code)
+static inline int uinput_request_reserve_slot(struct uinput_device *udev, 
struct uinput_request *request)
 {
-   struct uinput_device *udev = dev->private;
+   /* Allocate slot. If none are available right away, wait. */
+   return wait_event_interruptible(udev->requests_waitq,
+   !uinput_request_alloc_id(udev, 
request));
+}
 
-   memset(request, 0, sizeof(struct uinput_request));
-   request->code = code;
-   init_waitqueue_head(>waitq);
+static void uinput_request_done(struct uinput_device *udev, struct 
uinput_request *request)
+{
+   complete(>done);
 
-   /* Allocate an ID. If none are available right away, wait. */
-   request->retval = wait_event_interruptible(udev->requests_waitq,
-   !uinput_request_alloc_id(dev, request));
+   /* Mark slot as available */
+   udev->requests[request->id] = NULL;
+   wake_up_interruptible(>requests_waitq);
 }
 
-static void uinput_request_submit(struct input_dev *dev, struct uinput_request 
*request)
+static int uinput_request_submit(struct input_dev *dev, struct uinput_request 
*request)
 {
-   struct uinput_device *udev = dev->private;
int retval;
 
/* Tell our userspace app about this new request by queueing an input 
event */
uinput_dev_event(dev, EV_UINPUT, request->code, request->id);
 
/* Wait for the request to complete */
-   retval = wait_event_interruptible(request->waitq, request->completed);
-   if (retval)
-   request->retval = retval;
+   retval = wait_for_completion_interruptible(>done);
+   if (!retval)
+   retval = request->retval;
 
-   /* Release this request's ID, let others know it's available */
-   udev->requests[request->id] = NULL;
-   wake_up_interruptible(>requests_waitq);
+   return retval;
 }
 
 static int uinput_dev_upload_effect(struct input_dev *dev, struct ff_effect 
*effect)
 {
struct uinput_request request;
+   int retval;
 
if (!test_bit(EV_FF, dev->evbit))
return -ENOSYS;
 
-   uinput_request_init(dev, , UI_FF_UPLOAD);
-   if (request.retval)
-   return request.retval;
+   request.id = -1;
+   init_completion();
+   request.code = UI_FF_UPLOAD;
request.u.effect = effect;
-   uinput_request_submit(dev, );
-   return request.retval;
+
+   retval = uinput_request_reserve_slot(dev->private, );
+   if (!retval)
+   retval = uinput_request_submit(dev, );
+
+   return retval;
 }
 
 static int uinput_dev_erase_effect(struct input_dev *dev, int effect_id)
 {
struct uinput_request request;
+   int retval;
 
if (!test_bit(EV_FF, dev->evbit))
return -ENOSYS;
 
-   uinput_request_init(dev, , UI_FF_ERASE);
-   if (request.retval)
-   return request.retval;
+   request.id = -1;
+   init_completion();
+   request.code = UI_FF_ERASE;
request.u.effect_id = effect_id;
-   uinput_request_submit(dev, );

[patch 03/24] serio: add modalias

[Dmitry Torokhov]

Input: serio - add modalias attribute and environment variable to
   simplify hotplug scripts.

Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---

 drivers/input/serio/serio.c |   42 ++
 1 files changed, 26 insertions(+), 16 deletions(-)

Index: work/drivers/input/serio/serio.c
===
--- work.orig/drivers/input/serio/serio.c
+++ work/drivers/input/serio/serio.c
@@ -389,6 +389,14 @@ static ssize_t serio_show_description(st
return sprintf(buf, "%s\n", serio->name);
 }
 
+static ssize_t serio_show_modalias(struct device *dev, struct device_attribute 
*attr, char *buf)
+{
+   struct serio *serio = to_serio_port(dev);
+
+   return sprintf(buf, "serio:ty%02Xpr%02Xid%02Xex%02X\n",
+   serio->id.type, serio->id.proto, serio->id.id, 
serio->id.extra);
+}
+
 static ssize_t serio_show_id_type(struct device *dev, struct device_attribute 
*attr, char *buf)
 {
struct serio *serio = to_serio_port(dev);
@@ -487,6 +495,7 @@ static ssize_t serio_set_bind_mode(struc
 
 static struct device_attribute serio_device_attrs[] = {
__ATTR(description, S_IRUGO, serio_show_description, NULL),
+   __ATTR(modalias, S_IRUGO, serio_show_modalias, NULL),
__ATTR(drvctl, S_IWUSR, NULL, serio_rebind_driver),
__ATTR(bind_mode, S_IWUSR | S_IRUGO, serio_show_bind_mode, 
serio_set_bind_mode),
__ATTR_NULL
@@ -785,36 +794,37 @@ static int serio_bus_match(struct device
 
 #ifdef CONFIG_HOTPLUG
 
-#define PUT_ENVP(fmt, val) \
-do {   \
-   envp[i++] = buffer; \
-   length += snprintf(buffer, buffer_size - length, fmt, val); \
-   if (buffer_size - length <= 0 || i >= num_envp) \
-   return -ENOMEM; \
-   length++;   \
-   buffer += length;   \
-} while (0)
+#define SERIO_ADD_HOTPLUG_VAR(fmt, val...) \
+   do {\
+   int err = add_hotplug_env_var(envp, num_envp, ,   \
+   buffer, buffer_size, ,  \
+   fmt, val);  \
+   if (err)\
+   return err; \
+   } while (0)
+
 static int serio_hotplug(struct device *dev, char **envp, int num_envp, char 
*buffer, int buffer_size)
 {
struct serio *serio;
int i = 0;
-   int length = 0;
+   int len = 0;
 
if (!dev)
return -ENODEV;
 
serio = to_serio_port(dev);
 
-   PUT_ENVP("SERIO_TYPE=%02x", serio->id.type);
-   PUT_ENVP("SERIO_PROTO=%02x", serio->id.proto);
-   PUT_ENVP("SERIO_ID=%02x", serio->id.id);
-   PUT_ENVP("SERIO_EXTRA=%02x", serio->id.extra);
-
+   SERIO_ADD_HOTPLUG_VAR("SERIO_TYPE=%02x", serio->id.type);
+   SERIO_ADD_HOTPLUG_VAR("SERIO_PROTO=%02x", serio->id.proto);
+   SERIO_ADD_HOTPLUG_VAR("SERIO_ID=%02x", serio->id.id);
+   SERIO_ADD_HOTPLUG_VAR("SERIO_EXTRA=%02x", serio->id.extra);
+   SERIO_ADD_HOTPLUG_VAR("MODALIAS=serio:ty%02Xpr%02Xid%02Xex%02X",
+   serio->id.type, serio->id.proto, serio->id.id, 
serio->id.extra);
envp[i] = NULL;
 
return 0;
 }
-#undef PUT_ENVP
+#undef SERIO_ADD_HOTPLUG_VAR
 
 #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: kernel 2.6 speed

[Willy Tarreau]

On Mon, Jul 25, 2005 at 12:10:15AM -0400, Florin Malita wrote:
> On 7/24/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> > time() isn't a hot
> > path in the real world.
> 
> That's what you would expect but I've straced stuff calling
> gettimeofday() in huge bursts every other second. Obviously braindead
> stuff but so is "the real world" most of the time() ... :)

gettimeofday() is known to be called very often (after any select() or
poll() returns), and is optimized for such conditions. There was even
an implementation, which I don't know if it finally became mainstream,
which optimized this particular system call. Some networking applications
might call it tens of thousands of times per second.

But as Alan said, time() (not to be confused with gettimeofday()) is
not a hot path.

Willy

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

Re: 2.6.11-rc5 and 2.6.12: cannot transmit anything

[David S. Miller]

Probably your link is never coming up.  We won't send packets
over the wire unless the device is in the link-up state.

However, if ->dequeue() is returning NULL, there really aren't
any packets in the device queue to be sent.

If you want, add more tracing to pfifo_fast_dequeue() since
that's almost certainly which queueing discipline is hooked
up to your VIA Rhine device as it's the 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: Problem with Asus P4C800-DX and P4 -Northwood-

[Willy Tarreau]

Hi,

On Mon, Jul 25, 2005 at 02:50:05AM +0200, Andreas Baer wrote:
> Hi everyone,
> 
> First I want to say sorry for this BIG post, but it seems that I have no 
> other chance. :)

It's not big enough, you did not explain us what your database does nor
how it does work, what type of resource it consumes most, any vmstat
capture during operation. There are so many possibilities here :
  - poor optimisation from gcc => CPU bound

  - many random disk accesses => I/O bound, but changing/tuning the I/O
scheduler could help

  - intensive disk reads => perhaps your windows and linux partitions are
on the same disk and windows is the first one, then you have 50 MB/s
on the windows one and 25 MB/s on the linux one ?

  - task scheduling : if your application is multi-process/multi-thread,
it is possible that you hit some corner cases. 

So please start "vmstat 1" before your 3min request, and stop it at the
end, so that it covers all the work. It will tell us many more useful
information.

Regards,
Willy

> I have a Asus P4C800-DX with a P4 2,4 GHz 512 KB L2 Cache "Northwood" 
> Processor (lowest Processor that supports HyperThreading) and 1GB DDR400 
> RAM. I'm also running S-ATA disks with about 50 MB/s (just to show that 
> it shouldn't be due to hard disk speed). Everything was bought back in 
> 2003 and I recently upgraded to the lastest BIOS Version. I've installed 
> Gentoo Linux and WinXP with dual-boot on this system.
> 
> Now to my problem:
> 
> I'm currently developing a little database in C++ (runs currently under 
> Windows and Linux) that internally builds up an R-Tree and does a lot of 
> equality tests and other time consuming checks. For perfomance issue I 
> ran a test with 20 entries and it took me about 3 minutes to 
> complete under Gentoo Linux.
> 
> So I ran the same test in Windows on the same platform and it took about 
> 30(!) seconds. I was a little bit surprised about this result so I 
> started to run several tests on different machines like an Athlon XP 
> 2000+ platform and on my P4 3GHz "Prescott" Notebook and they all showed 
> something about 30 seconds or below. Then I began to search for errors 
> or any misconfiguration in Gentoo, in my code and also for people that 
> have made equal experiences with that hardware configuration on the 
> internet. I thought I have a problem with a broken gcc or libraries like 
> glibc or libstdc++ and so I recompiled my whole system with the stable 
> gcc 3.3.5 release, but that didn't make any changes. I also tried an 
> Ubuntu and a Suse LiveCD to verify that it has nothing to do with Gentoo 
> and my kernel version and they had the same problem and ran the test in 
> about 3 min.
> 
> Currently I'm at a loss what to do. I'm beginning to think that this is 
> maybe a kernel problem because I have no problems under Windows and it 
> doesn't matter whether I change any software or any configuration in 
> Gentoo. I'm currently running kernel-2.6.12, but the Livecd's had other 
> kernels.
> 
> HyperThreading(HT) is also not the reason for the loss of power, because 
> I tried to disable it and to create a uniprocessor kernel, but that 
> didn't solve the problem.
> 
> If you need some output of my configuration/log files or anything like 
> that, just mail me.
> 
> Is it possible that the kernel has a lack of support for P4 with 
> "Northwood" core? Maybe only this one? Could I solve the problem if I 
> change the processor to a "Prescott" core? Perhaps someone could provide 
> any information if this would make any sense or not.
> 
> Thanks in advance for anything that could help.
> 
> ...sorry for bad english :)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.11-rc5 and 2.6.12: cannot transmit anything

[Denis Vlasenko]

[resend. Did not reach mailing lists, most probably due
to KMail's unstoppable desire to use base64 encoding :)]

Hi folks,

I reported earlied that around linux-2.6.11-rc5 my home box sometimes
does not want to send anything over ethetnet. That report is repeated below
sig.

I finally managed to nail down where this happens.
I instrumented sch_generic.c to trace what happens with packets
to be sent over interface named "if". 

On 'good' boot, I see   

2005-07-12_17:26:29.72158 kern.info: qdisc_restart: start
2005-07-12_17:26:29.72164 kern.info: qdisc_restart: skb!=NULL
2005-07-12_17:26:29.72166 kern.info: qdisc_restart: if !netif_queue_stopped...
2005-07-12_17:26:29.72167 kern.info: qdisc_restart: ...hard_start_xmit

in the log, on 'bad' one only "qdisc_restart: start".

Below is first report and instrumented part of sch_generic.c.
--
vda

Subject: linux-2.6.11-rc5: mysterious loss of tx

My home box has onboard via-rhine NIC.

Several days ago my father called me and said that
it does not send anything (tcpdump shows only rx'ed pkts
despite pings being attempted etc). I did not investigate
then.

Yesterday I've seen it myself. I bumped up ethtool msglvl.
Looks like via-rhine's hard_start_xmit was not called at all
from network core code! (I did not see debug printks from
rhine's hard_stat_xmit routine)

Whatever I tried (ifconfig down/up, reinit IP config from scratch),
nothing helped. No tx whatsoever was attempted by kernel, it seems.

Reboot 'fixed' things.

It hever happened on the same hardware before I switched to rc5.

int qdisc_restart(struct net_device *dev)
{
struct Qdisc *q = dev->qdisc;
struct sk_buff *skb;
int track = (dev->name[0]=='i' && dev->name[1]=='f' && dev->name[2]=='\0');

//'via rhine bug':
//I see ONLY "qdisc_restart: start",
//but not any of below msgs.
//On 'good' boots, it looks like this:
//...
//2005-07-12_17:26:29.72158 kern.info: qdisc_restart: start
//2005-07-12_17:26:29.72164 kern.info: qdisc_restart: skb!=NULL
//2005-07-12_17:26:29.72166 kern.info: qdisc_restart: if !netif_queue_stopped...
//2005-07-12_17:26:29.72167 kern.info: qdisc_restart: ...hard_start_xmit
//...
if(track) { printk("qdisc_restart: start\n"); }
/* Dequeue packet */
if ((skb = q->dequeue(q)) != NULL) {
if(track) { printk("qdisc_restart: skb!=NULL\n"); }
unsigned nolock = (dev->features & NETIF_F_LLTX);
/*
 * When the driver has LLTX set it does its own locking
 * in start_xmit. No need to add additional overhead by
 * locking again. These checks are worth it because
 * even uncongested locks can be quite expensive.
 * The driver can do trylock like here too, in case
 * of lock congestion it should return -1 and the packet
 * will be requeued.
 */
if (!nolock) {
if (!spin_trylock(>xmit_lock)) {
collision:
if(track) { printk("qdisc_restart: collision\n"); }
/* So, someone grabbed the driver. */

/* It may be transient configuration error,
   when hard_start_xmit() recurses. We detect
   it by checking xmit owner and drop the
   packet when deadloop is detected.
*/
if (dev->xmit_lock_owner == smp_processor_id()) 
{
kfree_skb(skb);
if (net_ratelimit())
printk(KERN_DEBUG "Dead loop on 
netdevice %s, fix it urgently!\n", dev->name);
return -1;
}
__get_cpu_var(netdev_rx_stat).cpu_collision++;
goto requeue;
}
/* Remember that the driver is grabbed by us. */
dev->xmit_lock_owner = smp_processor_id();
}

{
/* And release queue */
spin_unlock(>queue_lock);


//vda
if(track) { printk("qdisc_restart: if !netif_queue_stopped...\n"); }
if (!netif_queue_stopped(dev)) {
int ret;
if (netdev_nit)
dev_queue_xmit_nit(skb, dev);
if(track) { printk("qdisc_restart: ...hard_start_xmit\n"); }
ret = dev->hard_start_xmit(skb, dev);
if (ret == NETDEV_TX_OK) {
if (!nolock) {
dev->xmit_lock_owner = -1;
spin_unlock(>xmit_lock);

Re: [PATCH] driver core: Add the ability to unbind drivers to devices from userspace

[Dmitry Torokhov]

On Sunday 24 July 2005 23:09, Jon Smirl wrote:
> I just pulled from GIT to test bind/unbind. I couldn't get it to work;
> it isn't taking into account the CR on the end of the input value of
> the sysfs attribute.  This patch will fix it but I'm sure there is a
> cleaner solution.
> 

"echo -n" should take care of this problem I think.

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

Re: device_remove_file and disconnect

[Greg KH]

On Thu, Jun 30, 2005 at 10:31:44PM +0200, matthieu castet wrote:
> >Then they should be fixed.  Any specific examples?
> >
> >
> I am a little lasy to list all, but some drivers in driver/usb should 
> have this problem : the first driver I look : ./misc/phidgetkit.c do 
> [1]. So sysfs read don't check if to_usb_interface or usb_get_intfdata 
> return NULL pointer...
> And it is a bit your fault, as many developper should have read your 
> great tutorial [2] ;)

You are correct, I'll go fix those drivers, thanks for pointing it out.
Others pointed out the same thing this week at OLS :)

> >>Also I always see driver free their privatre data in device disconnect,
> >>so if read/write from sysfs aren't serialized with device disconnect
> >>there are still a possible race like I show in my example.
> >
> >
> >Yes, you are correct.  Again, any specific drivers you see with this
> >problem?
> I believe near all drivers that use sysfs via device_create_file, as I 
> never see them use mutex in read/write in order to check there aren't in 
> the same time in their disconnect that could free there private data 
> when they do operation on it...
> 
> 
> Couldn't be possible the make device_remove_file blocking until all the 
> open file are closed ?

Hm, do we even know that those files are opened then?  I'll poke around
in sysfs and see if we could do that.

thanks,

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

Re: [PATCH 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (2/9)

[Greg KH]

On Wed, Jul 20, 2005 at 11:46:03PM +0200, Jean Delvare wrote:
> 
> So, the approximate timeline would be 1* to 3* right now, 4* after that
> as time permits, and 5* when we estimate that 3* happened long enough
> ago (roughly 1st half of 2006?)
> 
> I hope I explained it correctly this time. If not, just complain ;)

Ah, much better, thanks.  Sounds like a great plan, I'll go apply your
patches in a day or so when I catch up from my travels.

thanks,

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

Re: kernel 2.6 speed

[Florin Malita]

On 7/24/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> time() isn't a hot
> path in the real world.

That's what you would expect but I've straced stuff calling
gettimeofday() in huge bursts every other second. Obviously braindead
stuff but so is "the real world" most of the 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] driver core: Add the ability to unbind drivers to devices from userspace

[Jon Smirl]

I just pulled from GIT to test bind/unbind. I couldn't get it to work;
it isn't taking into account the CR on the end of the input value of
the sysfs attribute.  This patch will fix it but I'm sure there is a
cleaner solution.

-- 
Jon Smirl
[EMAIL PROTECTED]


diff --git a/drivers/base/bus.c b/drivers/base/bus.c
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -137,9 +137,11 @@ decl_subsys(bus, _bus, NULL);
 static int driver_helper(struct device *dev, void *data)
 {
const char *name = data;
-
-   if (strcmp(name, dev->bus_id) == 0)
+printk(KERN_ERR "unbind: %s %s\n", name, dev->bus_id);
+   if (strncmp(name, dev->bus_id, strlen(dev->bus_id)) == 0) {
+printk(KERN_ERR "match\n");
return 1;
+   }
return 0;
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] fix compilation in collie.c

[Pavel Machek]

This fixes wrong number of arguments in call to write_scoop_reg and
John's email. Please apply,
Pavel

Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>

diff --git a/arch/arm/mach-sa1100/collie.c b/arch/arm/mach-sa1100/collie.c
--- a/arch/arm/mach-sa1100/collie.c
+++ b/arch/arm/mach-sa1100/collie.c
@@ -11,7 +11,7 @@
  * published by the Free Software Foundation.
  *
  * ChangeLog:
- *  03-06-2004 John Lenz <[EMAIL PROTECTED]>
+ *  03-06-2004 John Lenz <[EMAIL PROTECTED]>
  *  06-04-2002 Chris Larson <[EMAIL PROTECTED]>
  *  04-16-2001 Lineo Japan,Inc. ...
  */
@@ -111,16 +180,18 @@ static struct mtd_partition collie_parti
 
 static void collie_set_vpp(int vpp)
 {
-   write_scoop_reg(SCOOP_GPCR, read_scoop_reg(SCOOP_GPCR) | 
COLLIE_SCP_VPEN);
+   struct device *dev = _device.dev;
+
+   write_scoop_reg(dev, SCOOP_GPCR, read_scoop_reg(dev, SCOOP_GPCR) | 
COLLIE_SCP_VPEN);
if (vpp) {
-   write_scoop_reg(SCOOP_GPWR, read_scoop_reg(SCOOP_GPWR) | 
COLLIE_SCP_VPEN);
+   write_scoop_reg(dev, SCOOP_GPWR, read_scoop_reg(dev, 
SCOOP_GPWR) | COLLIE_SCP_VPEN);
} else {
-   write_scoop_reg(SCOOP_GPWR, read_scoop_reg(SCOOP_GPWR) & 
~COLLIE_SCP_VPEN);
+   write_scoop_reg(dev, SCOOP_GPWR, read_scoop_reg(dev, 
SCOOP_GPWR) & ~COLLIE_SCP_VPEN);
}
 }
 
 static struct flash_platform_data collie_flash_data = {
.map_name   = "cfi_probe",
.set_vpp= collie_set_vpp,
.parts  = collie_partitions,
.nr_parts   = ARRAY_SIZE(collie_partitions),

-- 
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: Problem while inserting pciehp (PCI Express Hot-plug) driver

[Rajat Jain]

> On Tue, Jul 12, 2005 at 06:01:22PM +0900, Rajat Jain
> wrote:
>
> > Hi,
> > 
> > I'm trying to use the PCI Express Hot-Plug Controller driver
> > (pciehp.ko) with Kernel 2.6 so that I can get hot-plug events 
> > whenever I add a card to my PCI Express slot.
> > 
> > I built the driver as a module, and am trying to load it 
> > manually using modprobe. However, when trying to insert,
> > I'm getting the following error:
> >
> > pciehp: acpi_pciehprm:\_SB.PCI0 _OSC fails=0x5
> > pciehp: Both _OSC and OSHP methods do not exist
> > FATAL: Error inserting pciehp
> >
> > (/lib/modules/2.6.9-5.18AXcustom-hotplug/kernel/drivers/pci/hotplug/pciehp.ko):
> > No such device
> >

> --- Greg KH <[EMAIL PROTECTED]> wrote:
> Your bios does not support pci express hotplug.  Are
> you sure you have pci express hotplug hardware in your
> system?  If so, contact your bios vendor to get an 
> updated version.
> 
> Good luck,
> 
>  greg k-h

Thanks for replying Greg. I checked again, I have the hardware in my
system. I asked the vendor for bios update, but he says mine is the
latest version.

I downloaded the Intel "iasl" compiler
(http://developer.intel.com/technology/iapc/acpi/downloads.htm),  and
used it to decompile "/proc/acpi/dsdt" file (in AML) to its equivalent
ACPI source code. I could not find the _OSC and OSHP control methods
there. Is this information sufficient enough to deduce that I need a
BIOS update? And the hardware is OK but the problem is with the bios?

Just out of curosity, I would appreciate if you could provide me
pointers to OSHP and _OSC methods. What exactly do they mean? Does
every hardware containing a hot-plug controller necessarily has to
implement them both? I checked with ACPI Specs but it contains no
refrence to "OSHP" method.

Any pointers are more than appreciated,

TIA,

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

(was Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG) Fw: Mail delivery failed: returning message to sender

[David S. Miller]

Well, this may be the reason why Evgeniy thinks nobody
has any concrete objections to his connector layer :-(
--- Begin Message ---
This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  [EMAIL PROTECTED]
SMTP error from remote mail server after initial connection:
host mailer.campus.mipt.ru [194.85.82.4]: 554 mailer.campus.mipt.ru ESMTP 
not accepting messages

-- This is a copy of the message, including all the headers. --

Return-path: <[EMAIL PROTECTED]>
Received: from localhost ([127.0.0.1] ident=davem)
by sunset.davemloft.net with esmtp (Exim 4.52)
id 1DwsXV-0007pe-24; Sun, 24 Jul 2005 19:17:57 -0700
Date: Sun, 24 Jul 2005 19:17:56 -0700 (PDT)
Message-Id: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
 linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG
From: "David S. Miller" <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
X-Mailer: Mew version 4.2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Sat, 23 Jul 2005 13:14:55 +0400

> Andrew has no objection against connector and it lives in -mm

A patch sitting in -mm has zero significance.  A lot of junk
and useless things end up there as often Andrew incorporates
just about every single patch he sees posted to linux-kernel
unless he personally knows of some reason why the change might
be wrong.

So "it's in -mm" is not a metric to use.

> All objections against it was only type of - "I do not like it"
> Dmitry had some bugfixes which were added.

People like James Morris had very specific objections about it.

You are a control freak and in general very very difficult to work
with, so nobody wants to help you fix things up.
--- End Message ---

Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG

[David S. Miller]

From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Sat, 23 Jul 2005 13:14:55 +0400

> Andrew has no objection against connector and it lives in -mm

A patch sitting in -mm has zero significance.  A lot of junk
and useless things end up there as often Andrew incorporates
just about every single patch he sees posted to linux-kernel
unless he personally knows of some reason why the change might
be wrong.

So "it's in -mm" is not a metric to use.

> All objections against it was only type of - "I do not like it"
> Dmitry had some bugfixes which were added.

People like James Morris had very specific objections about it.

You are a control freak and in general very very difficult to work
with, so nobody wants to help you fix things up.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[no subject]

[Matt Heler]

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

Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG

[David S. Miller]

From: Harald Welte <[EMAIL PROTECTED]>
Date: Sat, 23 Jul 2005 09:33:53 -0400

> I strongly disrecommend increasing NPROTO.  Maybe we should look into
> reusing NETLINK_FIREWALL (which was an old 2.2.x kernel interface).

ip_queue.c still uses NETLINK_FIREWALL so we really can't use
that.

So instead, as in the patch below, I solved this for now by using
the NETLINK_SKIP value which was reserved years ago yet never
made use of.

diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c
--- a/drivers/w1/w1_int.c
+++ b/drivers/w1/w1_int.c
@@ -88,7 +88,7 @@ static struct w1_master * w1_alloc_dev(u
 
dev->groups = 23;
dev->seq = 1;
-   dev->nls = netlink_kernel_create(NETLINK_NFLOG, NULL);
+   dev->nls = netlink_kernel_create(NETLINK_W1, NULL);
if (!dev->nls) {
printk(KERN_ERR "Failed to create new netlink socket(%u) for w1 
master %s.\n",
NETLINK_NFLOG, dev->dev.bus_id);
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -5,7 +5,7 @@
 #include 
 
 #define NETLINK_ROUTE  0   /* Routing/device hook  
*/
-#define NETLINK_SKIP   1   /* Reserved for ENskip  
*/
+#define NETLINK_W1 1   /* 1-wire subsystem 
*/
 #define NETLINK_USERSOCK   2   /* Reserved for user mode socket 
protocols  */
 #define NETLINK_FIREWALL   3   /* Firewalling hook 
*/
 #define NETLINK_TCPDIAG4   /* TCP socket monitoring
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[no subject]

[Matt]

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

Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG

[David S. Miller]

From: Harald Welte <[EMAIL PROTECTED]>
Date: Sat, 23 Jul 2005 09:33:53 -0400

> I strongly disrecommend increasing NPROTO.  Maybe we should look into
> reusing NETLINK_FIREWALL (which was an old 2.2.x kernel interface).

That is how I will fix this 1-wire case, by reusing the NETLINK_FIREWALL
thing.

> But to be honest, I don't really care all that much as long as existing
> and still very actively used values are not just overloaded.

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

Incorrect driver getting loaded for Qlogic FC-HBA

[Rajat Jain]

Hi,

I do not know which list to put this problem on. And hence ...

I'm using Kernel 2.6.9 and am having a Qlogic QLE2362 FC-HBA in my
system. I selected all the Qlogic SCSI drivers while buiding the
kernel. Now the problem is that every time I reboot, I have to
MANUALLY modprobe the qla2322.ko module in the kernel and only then my
HBA works. By default, the kernel loads qla2300.ko, which is not the
correct driver for the card, and hence the HBA does not work. Here is
the lspci output:

-
0d:07.1 Fibre Channel: QLogic Corp.: Unknown device 2322 (rev 03)
Subsystem: QLogic Corp.: Unknown device 0118
Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 185
I/O ports at 6400 [size=256]
Memory at d0401000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Capabilities: [4c] PCI-X non-bridge device.
Capabilities: [54] Message Signalled Interrupts: 64bit+ Queue=0/3 
Enable-
---

Here is the relevant extract from modules.pcimap:
---
#module  vendor device subvendor  subdevice  class 
class_mask driver_data
qla2300  0x1077 0x2300 0x 0x 0x 0x 0x0
qla2300  0x1077 0x2312 0x 0x 0x 0x 0x0
qla2322  0x1077 0x2322 0x 0x 0x 0x 0x0
---

As can be seen from above, qla2322 is the correct driver for device
2322 (My QLE2362 HBA has a device no 2322, as seen in lspci output).
But for some reason the kernel always loads qla2300 instead on
qla2322. I even tried putting the "qla2322" line on top of the two
"qla2300" lines in the modules.pcimap file. But with no result.

TIA,

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

Fault tolerance. . .

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm playing Skies of Arcadia Legends on my GameCube and noticing that
software bugs continuously produce errors (no scratch on the disk; I can
have an error, reset, play through it easy).  This leads me on and on,
but now it's lead me into thinking about fault tolerance.

Leaving the GameCube and moving to my computer, I'm wondering if
something could be done kernel-end to provide automatic application and
system fault recovery.  Thinking about it, I can come up with a few cute
ideas, though they don't really seem all that realistic.  Still, it
might be fun to share them and see what kinds of comments I get.

I'm thinking of application level fault tolerance using roll-back states
or something weird, to restore the system as affected by that
application to a point before the error.  The obvious visual effect
would be that if an application were to crash, it and potentially
interrelated applications would suddenly reset to a state a few seconds
to a few minutes earlier.

Like I said, this is a really dumb idea, but it's kind of cute to think
about.  In the 5 minutes I think about this, I'll type some crap here,
then go back to my game and leave this for you all so you can take a
break from real work and read something mildly ammusing.

Interrelating applications:

 - Tasks sharing memory are synchronized at state saves
 - Tasks having mappings to files where writing to the mapping writes to
the file have state saves synchronized starting where one could affect
another and ending where they no longer can affect eachother
  - When a process opens a file another process has open for writing,
the two both have a state save made
  - Following state saves are sychronized temporally between the tasks
  - When neither task can affect the other by writing to said file, the
state saves no longer are required to be synchronized
 - Tasks communicating over sockets are synchronized at save states
 - Tasks communicating via pipes are synchronized at save states
 - When a parent is rolled back to precede a fork(), the fork() child dies

"Synchronized" means that when the state is set to be saved for
roll-back in one task, interrelated tasks are also frozen and saved at
the same time.

Saving a state is easy:

 - Lock a spinlock
 - Add an entry to a linked list for a state save, with registers and such
 - Remove entries older than the limit for the oldest save
 - Open spinlock

Maintaining the state is also easy:

 - When a file is changed, track the changes and attach them to the last
state save
 - When memory pages are written to, cache the old copies first
(unfortunately each page has to be made CoW after every state save)

Restoring a state is also easy:

 - At untrapped sigsegv, sigabrt, roll back changes and related changes
 - Repeted incident means rolling back farther

This of course raises many questions and concerns that make this
rediculous and probably not entirely possible:

 - What about huge modifications to files in a short time?  Make a new
file, then write 10,000,000,000 bytes past the end and watch it crash.
 - What about lost work in interrelated applications?
 - Will the system state remain consistent?
 - Will it crash over and over and over?
 - Connecting to named pipes? (easily handled, not discussed here)
 - Crashes are usually trappable, and then programs exit cleanly.  They
won't care about this
 - How does a process know to change course if it gets restored?
 - We can probably use this to do some deep-and-dirty espionage, relying
on the fault tolerance when we crash something trying to leak information
 - Darth Vader will use this to find Luke Skywalker

Anyway, whatever.  Comment if you want, I just thought the idea was
cute.  Not practical, but cute.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
 -- Eric Steven Raymond
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC5EeehDd4aOud5P8RAhK/AJ90BXofS/XPJcr5xsGFhqlf9jJiBQCfcbSG
v2Di7VqKv29jlRjoJiphy0c=
=5H6M
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Memory Management

[Márcio Oliveira]

Neil Horman wrote:


On Sat, Jul 23, 2005 at 08:16:20PM -0300, Márcio Oliveira wrote:
 


Neil,

   

The best way I can think to do that is take a look at /proc/slabinfo.  
That will

likely give you a pointer to which area of code is eating up your memory.


 


OK. I will monitor the /proc/slabinfo file.

   


Based on the sysrq-m info you posted it looks like due to fragmentation the
largest chunk of memory you can allocate is 2MB (perhaps less depending on
address space availability).  If you can build a test kernel to do a 
show_state
rather than a show_mem at the beginning of oom_kil, then you should be 
able to

tell who is trying to do an allocation that leads to kswapd calling
out_of_memory.


 

Neil, I'm trying to recompile the kernel source 2.4.21-32.0.1 and get 
some error messages:


In file included from 
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/prefetch.h:13,
   from 
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/list.h:6,
   from 
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:12,

   from 3w-.c:172:
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:61: warning: 
parameter names (without types) in function declaration
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:61: field 
`loops_per_jiffy_R_ver_str' declared as a function
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: invalid 
suffix on integer constant
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: syntax error 
before numeric constant
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: warning: 
function declaration isn't a prototype
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: invalid 
suffix on integer constant
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: syntax 
error before numeric constant
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: warning: 
function declaration isn't a prototype
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:273: warning: 
parameter names (without types) in function declaration

In file included from 3w-.c:172:
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: invalid 
suffix on integer constant
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: syntax error 
before numeric constant
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: 
`inter_module_register_R_ver_str' declared as function returning a function
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: warning: 
function declaration isn't a prototype
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: invalid 
suffix on integer constant
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: syntax error 
before numeric constant
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: 
`inter_module_unregister_R_ver_str' declared as function returning a 
function
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: warning: 
function declaration isn't a prototype
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:192: 
`inter_module_get_R_ver_str' declared as function returning a function
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:192: warning: 
parameter names (without types) in function declaration
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:193: 
`inter_module_get_request_R_ver_str' declared as function returning a 
function
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:193: warning: 
parameter names (without types) in function declaration
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: invalid 
suffix on integer constant
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: syntax error 
before numeric constant
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: 
`inter_module_put_R_ver_str' declared as function returning a function
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: warning: 
function declaration isn't a prototype
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:203: 
`try_inc_mod_count_R_ver_str' declared as function returning a function
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:203: warning: 
parameter names (without types) in function declaration

make[3]: *** [3w-_10200033.o] Error 1
make[3]: Leaving directory 
`/usr/src/linux-2.4.21-32.0.1.EL/drivers/addon/3w-_10200033'

make[2]: *** [_modsubdir_3w-_10200033] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.21-32.0.1.EL/drivers/addon'
make[1]: *** [_modsubdir_addon] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.21-32.0.1.EL/drivers'
make: *** [_mod_drivers] Error 2

Is there any relationship between the sysrq-m changes to do show_state() 
rather than a show_mem() and the compiling erros?


/usr/src/linux-2.4.21-32.0.1.EL/include/linux/prefetch.h, line 13:
  #include 

/usr/src/linux-2.4.21-32.0.1.EL/include/linux/list.h ,line 6:
  #include 

/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h, line 12:
  #include 

3w-.c, line 

Re: [PATCH] pcibios_bus_to_resource for parisc [Was: Re: [PATCH 8/8] pci and yenta: pcibios_bus_to_resource]

[Grant Grundler]

On Sat, Jul 23, 2005 at 09:54:11PM +0200, Dominik Brodowski wrote:
> Oh, yes, I seem to have missed it. Sorry. Does this patch look good?

Yes.

Acked-by: Grant Grundler <[EMAIL PROTECTED]>

I'll commit this to the cvs.parisc-linux.org tree as well.
Willy can let me deal with the collision if it's not trivial
on his next merge.

thanks,
grant

> 
> 
> Add pcibios_bus_to_resource for parisc.
> 
> Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
> 
> Index: 2.6.13-rc3-git2/arch/parisc/kernel/pci.c
> ===
> --- 2.6.13-rc3-git2.orig/arch/parisc/kernel/pci.c
> +++ 2.6.13-rc3-git2/arch/parisc/kernel/pci.c
> @@ -255,8 +255,26 @@ void __devinit pcibios_resource_to_bus(s
>   pcibios_link_hba_resources(>lmmio_space, bus->resource[1]);
>  }
>  
> +void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
> +   struct pci_bus_region *region)
> +{
> + struct pci_bus *bus = dev->bus;
> + struct pci_hba_data *hba = HBA_DATA(bus->bridge->platform_data);
> +
> + if (res->flags & IORESOURCE_MEM) {
> + res->start = PCI_HOST_ADDR(hba, region->start);
> + res->end = PCI_HOST_ADDR(hba, region->end);
> + }
> +
> + if (res->flags & IORESOURCE_IO) {
> + res->start = region->start;
> + res->end = region->end;
> + }
> +}
> +
>  #ifdef CONFIG_HOTPLUG
>  EXPORT_SYMBOL(pcibios_resource_to_bus);
> +EXPORT_SYMBOL(pcibios_bus_to_resource);
>  #endif
>  
>  /*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Problem with Asus P4C800-DX and P4 -Northwood-

[Andreas Baer]

Hi everyone,

First I want to say sorry for this BIG post, but it seems that I have no 
other chance. :)


I have a Asus P4C800-DX with a P4 2,4 GHz 512 KB L2 Cache "Northwood" 
Processor (lowest Processor that supports HyperThreading) and 1GB DDR400 
RAM. I'm also running S-ATA disks with about 50 MB/s (just to show that 
it shouldn't be due to hard disk speed). Everything was bought back in 
2003 and I recently upgraded to the lastest BIOS Version. I've installed 
Gentoo Linux and WinXP with dual-boot on this system.


Now to my problem:

I'm currently developing a little database in C++ (runs currently under 
Windows and Linux) that internally builds up an R-Tree and does a lot of 
equality tests and other time consuming checks. For perfomance issue I 
ran a test with 20 entries and it took me about 3 minutes to 
complete under Gentoo Linux.


So I ran the same test in Windows on the same platform and it took about 
30(!) seconds. I was a little bit surprised about this result so I 
started to run several tests on different machines like an Athlon XP 
2000+ platform and on my P4 3GHz "Prescott" Notebook and they all showed 
something about 30 seconds or below. Then I began to search for errors 
or any misconfiguration in Gentoo, in my code and also for people that 
have made equal experiences with that hardware configuration on the 
internet. I thought I have a problem with a broken gcc or libraries like 
glibc or libstdc++ and so I recompiled my whole system with the stable 
gcc 3.3.5 release, but that didn't make any changes. I also tried an 
Ubuntu and a Suse LiveCD to verify that it has nothing to do with Gentoo 
and my kernel version and they had the same problem and ran the test in 
about 3 min.


Currently I'm at a loss what to do. I'm beginning to think that this is 
maybe a kernel problem because I have no problems under Windows and it 
doesn't matter whether I change any software or any configuration in 
Gentoo. I'm currently running kernel-2.6.12, but the Livecd's had other 
kernels.


HyperThreading(HT) is also not the reason for the loss of power, because 
I tried to disable it and to create a uniprocessor kernel, but that 
didn't solve the problem.


If you need some output of my configuration/log files or anything like 
that, just mail me.


Is it possible that the kernel has a lack of support for P4 with 
"Northwood" core? Maybe only this one? Could I solve the problem if I 
change the processor to a "Prescott" core? Perhaps someone could provide 
any information if this would make any sense or not.


Thanks in advance for anything that could help.

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

Re: Lack of Documentation about SA_RESTART...

[Theodore Ts'o]

On Sat, Jul 23, 2005 at 05:30:42PM -0700, Linus Torvalds wrote:
> On Mon, 11 Jul 2005, Theodore Ts'o wrote:
> > 
> > According to the Single Unix Specification V3, all functions that
> > return EINTR are supposed to restart if a process receives a signal
> > where signal handler has been installed with the SA_RESTART flag.  
> 
> That can't be right.
> 
> Some operations, like "select()" and "pause()" always return EINTR, and 
> indeed, real applications will break if you always restart. Restarting a 
> pause() would be nonsensical.

The spect says "unless otherwise specified".  The description for
pause() states that the process will sleep until receiving a signal
that terminates the process or causes it to call signal-handling
function.  That would presumably count as an "otherwise specified".

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

[-mm PATCH] v4l: hybrid dvb: rename CFLAGS from CONFIG_DVB_xxxx back to original HAVE_xxxx

[Michael Krufky]

The #define CONFIG_DVB_* are actually CFLAGS set by Makefile.
CONFIG_* namespace is reserved for Kconfig. This renames them back to HAVE_*

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

 linux/drivers/media/video/cx88/Makefile |8 ++--
 linux/drivers/media/video/cx88/cx88-dvb.c   |   26 
 linux/drivers/media/video/saa7134/Makefile  |4 +-
 linux/drivers/media/video/saa7134/saa7134-dvb.c |   16 -
 4 files changed, 27 insertions(+), 27 deletions(-)

diff -u linux-2.6.13/drivers/media/video/cx88/cx88-dvb.c 
linux/drivers/media/video/cx88/cx88-dvb.c
--- linux-2.6.13/drivers/media/video/cx88/cx88-dvb.c2005-07-24 
17:59:15.0 +
+++ linux/drivers/media/video/cx88/cx88-dvb.c   2005-07-24 18:21:52.0 
+
@@ -1,5 +1,5 @@
 /*
- * $Id: cx88-dvb.c,v 1.51 2005/07/24 19:09:28 mkrufky Exp $
+ * $Id: cx88-dvb.c,v 1.52 2005/07/24 22:12:47 mkrufky Exp $
  *
  * device driver for Conexant 2388x based TV cards
  * MPEG Transport Stream (DVB) routines
@@ -35,17 +35,17 @@
 #include "cx88.h"
 #include "dvb-pll.h"
 
-#ifdef CONFIG_DVB_MT352
+#ifdef HAVE_MT352
 # include "mt352.h"
 # include "mt352_priv.h"
 #endif
-#ifdef CONFIG_DVB_CX22702
+#ifdef HAVE_CX22702
 # include "cx22702.h"
 #endif
-#ifdef CONFIG_DVB_OR51132
+#ifdef HAVE_OR51132
 # include "or51132.h"
 #endif
-#ifdef CONFIG_DVB_LGDT3302
+#ifdef HAVE_LGDT3302
 # include "lgdt3302.h"
 #endif
 
@@ -104,7 +104,7 @@
 
 /* -- */
 
-#ifdef CONFIG_DVB_MT352
+#ifdef HAVE_MT352
 static int dvico_fusionhdtv_demod_init(struct dvb_frontend* fe)
 {
static u8 clock_config []  = { CLOCK_CTL,  0x38, 0x39 };
@@ -174,7 +174,7 @@
 };
 #endif
 
-#ifdef CONFIG_DVB_CX22702
+#ifdef HAVE_CX22702
 static struct cx22702_config connexant_refboard_config = {
.demod_address = 0x43,
.output_mode   = CX22702_SERIAL_OUTPUT,
@@ -190,7 +190,7 @@
 };
 #endif
 
-#ifdef CONFIG_DVB_OR51132
+#ifdef HAVE_OR51132
 static int or51132_set_ts_param(struct dvb_frontend* fe,
int is_punctured)
 {
@@ -207,7 +207,7 @@
 };
 #endif
 
-#ifdef CONFIG_DVB_LGDT3302
+#ifdef HAVE_LGDT3302
 static int lgdt3302_pll_set(struct dvb_frontend* fe,
struct dvb_frontend_parameters* params,
u8* pllbuf)
@@ -258,7 +258,7 @@
 
/* init frontend */
switch (dev->core->board) {
-#ifdef CONFIG_DVB_CX22702
+#ifdef HAVE_CX22702
case CX88_BOARD_HAUPPAUGE_DVB_T1:
dev->dvb.frontend = cx22702_attach(_novat_config,
   >core->i2c_adap);
@@ -269,7 +269,7 @@
   >core->i2c_adap);
break;
 #endif
-#ifdef CONFIG_DVB_MT352
+#ifdef HAVE_MT352
case CX88_BOARD_DVICO_FUSIONHDTV_DVB_T1:
dev->core->pll_addr = 0x61;
dev->core->pll_desc = _pll_lg_z201;
@@ -291,13 +291,13 @@
 >core->i2c_adap);
break;
 #endif
-#ifdef CONFIG_DVB_OR51132
+#ifdef HAVE_OR51132
case CX88_BOARD_PCHDTV_HD3000:
dev->dvb.frontend = or51132_attach(_hd3000,
 >core->i2c_adap);
break;
 #endif
-#ifdef CONFIG_DVB_LGDT3302
+#ifdef HAVE_LGDT3302
case CX88_BOARD_DVICO_FUSIONHDTV_3_GOLD_Q:
dev->ts_gen_cntrl = 0x08;
{
diff -u linux-2.6.13/drivers/media/video/saa7134/saa7134-dvb.c 
linux/drivers/media/video/saa7134/saa7134-dvb.c
--- linux-2.6.13/drivers/media/video/saa7134/saa7134-dvb.c  2005-07-24 
17:56:27.0 +
+++ linux/drivers/media/video/saa7134/saa7134-dvb.c 2005-07-24 
18:21:52.0 +
@@ -1,5 +1,5 @@
 /*
- * $Id: saa7134-dvb.c,v 1.22 2005/07/23 10:08:00 mkrufky Exp $
+ * $Id: saa7134-dvb.c,v 1.23 2005/07/24 22:12:47 mkrufky Exp $
  *
  * (c) 2004 Gerd Knorr <[EMAIL PROTECTED]> [SuSE Labs]
  *
@@ -35,11 +35,11 @@
 #include "saa7134-reg.h"
 #include "saa7134.h"
 
-#ifdef CONFIG_DVB_MT352
+#ifdef HAVE_MT352
 # include "mt352.h"
 # include "mt352_priv.h" /* FIXME */
 #endif
-#ifdef CONFIG_DVB_TDA1004X
+#ifdef HAVE_TDA1004X
 # include "tda1004x.h"
 #endif
 
@@ -53,7 +53,7 @@
 
 /* -- */
 
-#ifdef CONFIG_DVB_MT352
+#ifdef HAVE_MT352
 static int pinnacle_antenna_pwr(struct saa7134_dev *dev, int on)
 {
u32 ok;
@@ -152,7 +152,7 @@
 
 /* -- */
 
-#ifdef CONFIG_DVB_TDA1004X
+#ifdef HAVE_TDA1004X
 static int philips_tu1216_pll_init(struct dvb_frontend *fe)
 {
struct saa7134_dev *dev = fe->dvb->priv;
@@ -384,7 +384,7 @@
return 0;
 }
 
-#ifdef CONFIG_DVB_TDA1004X
+#ifdef HAVE_TDA1004X
 static struct tda1004x_config medion_cardbus = {
.demod_address = 0x08,
.invert= 1,
@@ -547,14 +547,14 

Re: [PATCH NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()

[Trond Myklebust]

su den 24.07.2005 Klokka 19:09 (-0400) skreiv Trond Myklebust:
> su den 24.07.2005 Klokka 16:36 (+0200) skreiv Rene Scharfe:
> > [PATCH NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()
> > 
> > Function nfs_block_bits() an open-coded version of (the non-existing)
> > rounddown_pow_of_two().  That means that for non-power-of-two target
> > sizes it returns half the size needed for a block to fully contain
> > the target.  I guess this is wrong. :-)  The patch uses the built-in
> > roundup_pow_of_two() instead.
> 
> What non-power-of-two target? Anything _not_ aligned to a power of two
> boundary is a BUG!

Furthermore, rounding UP in order to "correct" this non-alignment would
definitely be a bug.

If users choose to override the default rsize/wsize, that is almost
always in order to limit the UDP fragmentation per read/write request on
lossy networks. By rounding up, you are doubling the number of fragments
that the user requested instead of respecting the limit.

Cheers,
  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: kernel 2.6 speed

[Alan Cox]

On Sul, 2005-07-24 at 12:12 -0700, Ciprian wrote:
> I'm not an OS guru, but I ran a little and very simple
> test. The program bellow, as you can see, measures the
> number of cycles performed in 30 seconds.

No it measures the performance of the "time()" call. Windows has some
funky optimisations that we never bother with because time() isn't a hot
path in the real world.

Instead try code which does


time();
while(count++ < LOTS) {
  Do_stuff
}
time()

and you'll find the numbers on pure CPU work are essentially CPU bound
not OS affected at all

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

Re: Device supported by the OSS trident driver not supported by ALSA

[Alan Cox]

On Sad, 2005-07-23 at 22:04 +0200, Adrian Bunk wrote:
> The OSS trident driver has 5 different pci_device_id entries.
> 
> For 4 of them there seems to be similar ALSA support, but I can't find 
> any ALSA equivalent for the following entry:
> {PCI_VENDOR_ID_INTERG, PCI_DEVICE_ID_INTERG_5050,
>  PCI_ANY_ID, PCI_ANY_ID, 0, 0, CYBER5050},
> 
> Can anyone tell my why this device is supported by the OSS trident 
> driver but not by ALSA?

The OSS driver supports the CyberPro T-squared core integrated into the
cyberpro chipset while the ALSA driver only supports the others. Should
be easy for someone to resolve. I don't have any 5000 hardware to test
it however.

Alan

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

Re: [PATCH NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()

[Trond Myklebust]

su den 24.07.2005 Klokka 16:36 (+0200) skreiv Rene Scharfe:
> [PATCH NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()
> 
> Function nfs_block_bits() an open-coded version of (the non-existing)
> rounddown_pow_of_two().  That means that for non-power-of-two target
> sizes it returns half the size needed for a block to fully contain
> the target.  I guess this is wrong. :-)  The patch uses the built-in
> roundup_pow_of_two() instead.

What non-power-of-two target? Anything _not_ aligned to a power of two
boundary is a BUG!

Cheers,
  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] fix compilation in collie.c

[Richard Purdie]

On Sun, 2005-07-24 at 23:35 +0100, Russell King wrote:
> I'd like John (or someone) to look at this.  I'm particularly worred
> about:
> 
> 1. passing NULL into (read|write)_scoop_reg() - which use dev_get_drvdata()
>on this.  Given the choice between creating code which will definitely
>oops but not error or warn vs not compiling, I'll take not compiling
>any day.

They should read write_scoop_reg(_device.dev, ...); in this
case. 

There is a similar problem with drivers/input/keyboard/corgikbd.c for
which the patch has been in the input maintainer's queue for months :-(.

> 2. whether this is supposed to be using the sharp chip driver rather
>than the cfi stuff.

I think the aim was to use the cfi code but there were problems with it
not working so the sharp chip driver was being used in the meantime.
John will hopefully be able to comment more about this.

Richard

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

ping^2: [PATCH] move /proc/ppc_htab creating self-contained in arch/ppc/ code

[Christoph Hellwig]

On Mon, Jun 27, 2005 at 11:05:02PM +0200, Christoph Hellwig wrote:
> On Wed, May 04, 2005 at 08:44:39PM +0200, Christoph Hellwig wrote:
> > additional benefit is cleaning up the ifdef mess in ppc_htab.c
> > 
> > 
> > Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
> 
> ping?


Index: arch/ppc/kernel/ppc_htab.c
===
--- b023d524fb0a3b71aa0b957ce7c5540611497370/arch/ppc/kernel/ppc_htab.c  
(mode:100644 sha1:ca810025993f3a9ab882fb46722cd46543b6e85e)
+++ uncommitted/arch/ppc/kernel/ppc_htab.c  (mode:100644)
@@ -32,9 +32,6 @@
 #include 
 #include 
 
-static int ppc_htab_show(struct seq_file *m, void *v);
-static ssize_t ppc_htab_write(struct file * file, const char __user * buffer,
- size_t count, loff_t *ppos);
 extern PTE *Hash, *Hash_end;
 extern unsigned long Hash_size, Hash_mask;
 extern unsigned long _SDR1;
@@ -46,19 +43,7 @@
 extern unsigned int primary_pteg_full;
 extern unsigned int htab_hash_searches;
 
-static int ppc_htab_open(struct inode *inode, struct file *file)
-{
-   return single_open(file, ppc_htab_show, NULL);
-}
-
-struct file_operations ppc_htab_operations = {
-   .open   = ppc_htab_open,
-   .read   = seq_read,
-   .llseek = seq_lseek,
-   .write  = ppc_htab_write,
-   .release= single_release,
-};
-
+#ifdef CONFIG_PROC_FS
 static char *pmc1_lookup(unsigned long mmcr0)
 {
switch ( mmcr0 & (0x7f<<7) )
@@ -132,6 +117,16 @@
return 0;
}
 
+   seq_printf(m, "PTE Hash Table Information\n"
+ "Size\t\t: %luKb\n"
+ "Buckets\t\t: %lu\n"
+ "Address\t\t: %08lx\n"
+ "Entries\t\t: %lu\n",
+  (unsigned long)(Hash_size>>10),
+ (Hash_size/(sizeof(PTE)*8)),
+ (unsigned long)Hash,
+ Hash_size/sizeof(PTE));
+
 #ifndef CONFIG_PPC64BRIDGE
for (ptr = Hash; ptr < Hash_end; ptr++) {
unsigned int mctx, vsid;
@@ -146,32 +141,16 @@
else
uptes++;
}
-#endif
 
-   seq_printf(m,
- "PTE Hash Table Information\n"
- "Size\t\t: %luKb\n"
- "Buckets\t\t: %lu\n"
- "Address\t\t: %08lx\n"
- "Entries\t\t: %lu\n"
-#ifndef CONFIG_PPC64BRIDGE
- "User ptes\t: %u\n"
+   seq_printf(m, "User ptes\t: %u\n"
  "Kernel ptes\t: %u\n"
- "Percent full\t: %lu%%\n"
-#endif
-  , (unsigned long)(Hash_size>>10),
- (Hash_size/(sizeof(PTE)*8)),
- (unsigned long)Hash,
- Hash_size/sizeof(PTE)
-#ifndef CONFIG_PPC64BRIDGE
-  , uptes,
+ "Percent full\t: %lu%%\n",
+ uptes,
  kptes,
- ((kptes+uptes)*100) / (Hash_size/sizeof(PTE))
+ ((kptes+uptes)*100) / (Hash_size/sizeof(PTE)));
 #endif
-   );
 
-   seq_printf(m,
- "Reloads\t\t: %lu\n"
+   seq_printf(m, "Reloads\t\t: %lu\n"
  "Preloads\t: %lu\n"
  "Searches\t: %u\n"
  "Overflows\t: %u\n"
@@ -180,20 +159,19 @@
  primary_pteg_full, htab_evicts);
 #endif /* CONFIG_PPC_STD_MMU */
 
-   seq_printf(m,
- "Non-error misses: %lu\n"
+   seq_printf(m, "Non-error misses: %lu\n"
  "Error misses\t: %lu\n",
  pte_misses, pte_errors);
return 0;
 }
 
+#ifdef CONFIG_PPC_STD_MMU
 /*
  * Allow user to define performance counters and resize the hash table
  */
 static ssize_t ppc_htab_write(struct file * file, const char __user * ubuffer,
  size_t count, loff_t *ppos)
 {
-#ifdef CONFIG_PPC_STD_MMU
unsigned long tmp;
char buffer[16];
 
@@ -312,12 +290,43 @@
}
 
return count;
+}
 #else /* CONFIG_PPC_STD_MMU */
+static ssize_t ppc_htab_write(struct file * file, const char __user * ubuffer,
+ size_t count, loff_t *ppos)
+{
return 0;
+}
 #endif /* CONFIG_PPC_STD_MMU */
+
+static int ppc_htab_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, ppc_htab_show, NULL);
 }
 
-int proc_dol2crvec(ctl_table *table, int write, struct file *filp,
+static struct file_operations ppc_htab_operations = {
+   .open   = ppc_htab_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .write  = ppc_htab_write,
+   .release= single_release,
+};
+
+static int __init ppc_htab_proc_init(void)
+{
+   struct proc_dir_entry *entry;
+
+   entry = create_proc_entry("ppc_htab", 

Re: kernel 2.6 speed

[Lee Revell]

On Sun, 2005-07-24 at 17:03 -0400, Florin Malita wrote:
> the x86 timer interrupt
> frequency has increased from 100Hz to 1KHz (it's about to be lowered
> to 250Hz)

This is by no means a done deal.  So far no one has posted ANY evidence
that dropping HZ to 250 helps (except one result on a atypically large
system), and there's plenty of evidence that it doesn't.

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 2/6] Rename __lock_page to lock_page_slow

[Christoph Hellwig]

On Sun, Jul 24, 2005 at 11:17:02PM +0100, Christoph Hellwig wrote:
> On Mon, Jun 20, 2005 at 09:54:04PM +0530, Suparna Bhattacharya wrote:
> > In order to allow for interruptible and asynchronous versions of
> > lock_page in conjunction with the wait_on_bit changes, we need to
> > define low-level lock page routines which take an additional
> > argument, i.e a wait queue entry and may return non-zero status,
> > e.g -EINTR, -EIOCBRETRY, -EWOULDBLOCK etc. This patch renames 
> > __lock_page to lock_page_slow, so that __lock_page and 
> > __lock_page_slow can denote the versions which take a wait queue 
> > parameter.
> 
> How many users that don't use a waitqueue parameter will be left
> once all AIO patches go in?

Actually looking at the later patches we always seem to pass
current->io_wait anyway, so is there a real point for having the
argument?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 compilation in collie.c

[Russell King]

On Thu, Jul 21, 2005 at 07:25:27AM +0200, Pavel Machek wrote:
> This fixes wrong number of arguments in call to write_scoop_reg, fixes
> map_name and John's email. Please apply,
> 
> Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>

Nacked.

I'd like John (or someone) to look at this.  I'm particularly worred
about:

1. passing NULL into (read|write)_scoop_reg() - which use dev_get_drvdata()
   on this.  Given the choice between creating code which will definitely
   oops but not error or warn vs not compiling, I'll take not compiling
   any day.

2. whether this is supposed to be using the sharp chip driver rather
   than the cfi stuff.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/6] Rename __lock_page to lock_page_slow

[Christoph Hellwig]

On Mon, Jun 20, 2005 at 09:54:04PM +0530, Suparna Bhattacharya wrote:
> In order to allow for interruptible and asynchronous versions of
> lock_page in conjunction with the wait_on_bit changes, we need to
> define low-level lock page routines which take an additional
> argument, i.e a wait queue entry and may return non-zero status,
> e.g -EINTR, -EIOCBRETRY, -EWOULDBLOCK etc. This patch renames 
> __lock_page to lock_page_slow, so that __lock_page and 
> __lock_page_slow can denote the versions which take a wait queue 
> parameter.

How many users that don't use a waitqueue parameter will be left
once all AIO patches go in?

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

Re: xor as a lazy comparison

[Puneet Vyas]

Jan Engelhardt wrote:

To confuse you, coders with assembly or hardware background throw in 
   



I doubt that. I'm good enough assembly to see this :)

 

equivalent bit operations to succinctly describe their visualisation 
of solution space...  Perhaps the writer _wanted_ you to pause and 
think?  Maybe the compiler produces better code?  Try it and see.
   



It produces a simple CMP. Should not be inefficient, though.


Jan Engelhardt
 

I just compiled two identical program , one with "!=" and other with 
"^". The assembly output is identical.

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

Re: 2.6.13-rc3 test: finding compile errors with make randconfig

[Grant Coady]

On Sun, 24 Jul 2005 23:27:22 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>Looking at the .config, the problem is actually:
>  CONFIG_BROKEN=y
>
>You should edit init/Kconfig to disallow CONFIG_CLEAN_COMPILE=n, since 
>any errors you see with CONFIG_BROKEN=y aren't interesting.

Very good point.

$ grep CONFIG_BROKEN=y *config |wc -l
24

>From 106 .configs, trap for young players...  I'll skip compiling 
"CONFIG_BROKEN=y" .configs then.

Thanks,
Grant.

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

Re: kernel 2.6 speed

[Jan Engelhardt]

>I got a question for you. Apparently kernel 2.6 is
>much slower then 2.4 and about 30 times slower then
>the windows one.
>
>I'm not an OS guru, but I ran a little and very simple
>test. The program bellow, as you can see, measures the
>number of cycles performed in 30 seconds.

I suggest that you take out the time stuff and measure the whole running time, 
at the shell level.
Under Linux you can do that using "time ./myprog" - how you do it under 
Windows is another concern, but you can write a small "time" program for 
windows, too.


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

Re: xor as a lazy comparison

[Jan Engelhardt]

>To confuse you, coders with assembly or hardware background throw in 

I doubt that. I'm good enough assembly to see this :)

>equivalent bit operations to succinctly describe their visualisation 
>of solution space...  Perhaps the writer _wanted_ you to pause and 
>think?  Maybe the compiler produces better code?  Try it and see.

It produces a simple CMP. Should not be inefficient, though.


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

Re: RTC Timezone

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> My RTC clock is set to the local timezone. However, when I boot linux using 
> the -b option, to stop by a shell before the bootscripts begin, the clock is 
> exaclty two hours ahead.

The problem is that the clock is correct, but the timezone of your system is
not set yet. You can fix this by running the clock in UTC or not stop the boot
process that early.

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

Re: kernel page size explanation

[Nix]

On Mon, 25 Jul 2005, VASM wrote:
> i had one question 
> does the linux kernel support only one default page size even if the
> processor on which it is working supports multiple ?

No. Some architectures have compile-time support for multiple different
page sizes (e.g. Itanium, SPARC64); many have support for a
(non-swappable) `large pages) system, and a filesystem backed by huge
pages. (Often, the kernel is stored in huge pages, to keep the number
of page table entries wasted by the nonswappable kernel to a minimum.)

What is *not* presently supported is using multiple page sizes to
back userspace processes; that size is currently fixed at compile-time,
even on architectures supporting multiple variably-sized pages.

-- 
`But of course, GR is the very best relativity for the masses.'
 --- Wayne Throop
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc3 test: finding compile errors with make randconfig

[Adrian Bunk]

On Mon, Jul 25, 2005 at 07:13:02AM +1000, Grant Coady wrote:
> On Sun, 24 Jul 2005 22:39:32 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> 
> >On Mon, Jul 25, 2005 at 05:42:58AM +1000, Grant Coady wrote:
> >> On Sun, 24 Jul 2005 11:13:27 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >> >
> >> >it's generally useful, but the target kernel should be the latest -mm
> >> >kernel. 
> >> 097-error:drivers/char/drm/drm_memory.h:163: error: redefinition of 
> >> `drm_ioremap_nocache'
> >> 097-error:drivers/char/drm/drm_memory.h:163: error: `drm_ioremap_nocache' 
> >> previously defined here
> >> 097-error:drivers/char/drm/drm_memory.h:174: error: redefinition of 
> >> `drm_ioremapfree'
> >> 097-error:drivers/char/drm/drm_memory.h:174: error: `drm_ioremapfree' 
> >> previously defined here
> >
> >This requires the .config for debugging.
> Here:
>   ftp://ftp.scatter.mine.nu/develop/trial4-097-config.gz
> 
> >My first guess is that drm_memory.h requires a simple #ifdef to allow 
> >multiple inclusions.
> 
> I can tell you:
> --- linux-2.6.12.3b/drivers/char/drm/drm_memory.h.orig2005-06-18 
> 05:48:29.0 +1000
> +++ linux-2.6.12.3b/drivers/char/drm/drm_memory.h 2005-07-25 
> 06:57:41.0 +1000
> @@ -33,6 +33,9 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
> +#ifndef DRM_MEMORY_H
> +#define DRM_MEMORY_H
> +
>  #include 
>  #include 
>  #include 
> @@ -194,4 +197,5 @@
>   iounmap(pt);
>  }
>  
> +#endif
> 
> does not fix it, though it's probably not what you had in mind, first try...

That's what I had in mind.

> Simple fix didn't...  Now I got to read the code, takes a little more 
> effort :)
>...

Looking at the .config, the problem is actually:
  CONFIG_BROKEN=y

You should edit init/Kconfig to disallow CONFIG_CLEAN_COMPILE=n, since 
any errors you see with CONFIG_BROKEN=y aren't interesting.

> Grant.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: 2.6.13-rc3 test: finding compile errors with make randconfig

[Grant Coady]

On Sun, 24 Jul 2005 22:39:32 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:

>On Mon, Jul 25, 2005 at 05:42:58AM +1000, Grant Coady wrote:
>> On Sun, 24 Jul 2005 11:13:27 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>> >
>> >it's generally useful, but the target kernel should be the latest -mm
>> >kernel. 
>> 097-error:drivers/char/drm/drm_memory.h:163: error: redefinition of 
>> `drm_ioremap_nocache'
>> 097-error:drivers/char/drm/drm_memory.h:163: error: `drm_ioremap_nocache' 
>> previously defined here
>> 097-error:drivers/char/drm/drm_memory.h:174: error: redefinition of 
>> `drm_ioremapfree'
>> 097-error:drivers/char/drm/drm_memory.h:174: error: `drm_ioremapfree' 
>> previously defined here
>
>This requires the .config for debugging.
Here:
  ftp://ftp.scatter.mine.nu/develop/trial4-097-config.gz

>My first guess is that drm_memory.h requires a simple #ifdef to allow 
>multiple inclusions.

I can tell you:
--- linux-2.6.12.3b/drivers/char/drm/drm_memory.h.orig  2005-06-18 
05:48:29.0 +1000
+++ linux-2.6.12.3b/drivers/char/drm/drm_memory.h   2005-07-25 
06:57:41.0 +1000
@@ -33,6 +33,9 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#ifndef DRM_MEMORY_H
+#define DRM_MEMORY_H
+
 #include 
 #include 
 #include 
@@ -194,4 +197,5 @@
iounmap(pt);
 }
 
+#endif

does not fix it, though it's probably not what you had in mind, first try...
Simple fix didn't...  Now I got to read the code, takes a little more 
effort :)
...
>You aren't running into problems that are already fixed (see your second 
>example above).
I see your point, thanks for feedback.  

Grant.

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

Re: IRQ routing problem in 2.6.10-rc2

[Pierre Ossman]

Jesper Juhl wrote:

>
>Have you tried the suggestion given "... As a temporary workaround,
>the "pci=routeirq" argument..." ?
>You could also try the pci=noacpi boot option to see if that changes anything.
>  
>

No, I missed that one. The machine works fine with either of those two
options. I sent a comment with lspci to Bjorn Helgaas as suggested.

>Also, that's a fairly old kernel you have there, could you try
>2.6.13-rc3, 2.6.13-rc3-git6 or 2.6.13-rc3-mm1 ?
>
>  
>

I discovered the problem running 2.6.12. I only tried these kernels to
pinpoint where the problem began.

Rgds
Pierre


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

Re: kernel 2.6 speed

[Florin Malita]

On 7/24/05, Ciprian <[EMAIL PROTECTED]> wrote:
> test /= 10;
> test *= 10;
> test += 10;
> test -= 10;

You're not trying to benchmark the kernel with those arithmetic
operations are you?! That's completely bogus, the kernel is not
involved in any of that.

As it has been already pointed out, the only OS-dependent and (by far)
the most expensive operation in your loop is the time() function call
- so that's the only thing you're really benchmarking there (besides
compiler optimizations).

> In windows were performed about 300 millions cycles,
> while in Linux about 10 millions. This test was run on
> Fedora 4 and Suse 9.2 as Linux machines, and Windows
> XP Pro with VS .Net 2003 on the MS side. My CPU is a
> P4 @3GHz HT 800MHz bus.

I can only speculate as of why the windoze time() call seems so much
faster: maybe it is implemented in userspace and doesn't involve a
system call. Somebody with more knowledge in the area might
confirm/infirm this.

Even in Linux your results will vary a lot depending on whether the
kernel and glibc support vsyscalls. The FC kernels disable vsyscall
because it's incompatible with NX, not sure about the Suse kernels.
Here's what I get on a P4 1.7 with a vsyscall enabled kernel
(2.6.11.12):

No. of cycles: 65688977

Check this thread for a FC4 kernel performance discussion:
http://www.redhat.com/archives/fedora-devel-list/2005-June/msg01126.html


> Now, can anyone explain this and suggest what other
> optimizations I should use? The 2.4 version was a lot
> faster. 

Your bogus test aside, a certain userland performance degradation when
moving from 2.4 to 2.6 is expected as the x86 timer interrupt
frequency has increased from 100Hz to 1KHz (it's about to be lowered
to 250Hz) - so your apps are interrupted more often. But I wouldn't
expect that degradation to be substantial. If you want to dig in and
measure it you should use asm/rdtsc instead of 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: kernel 2.6 speed

[Puneet Vyas]

Ciprian wrote:


Hi guys!

I got a question for you. Apparently kernel 2.6 is
much slower then 2.4 and about 30 times slower then
the windows one.

I'm not an OS guru, but I ran a little and very simple
test. The program bellow, as you can see, measures the
number of cycles performed in 30 seconds.

//- START CODE 

#include 
#include 


int main()
{
time_t initialTime;
time_t testTime;
long counter = 0;
double test = 1;


time();
testTime = initialTime;

printf("Here we go...\n");

while((testTime-initialTime) < 30)
{
time();
test /= 10;
test *= 10;
test += 10;
test -= 10;

counter ++;

}

printf("No. of cycles: %ld\n", counter);

return 0;
}

// END CODE ---


In windows were performed about 300 millions cycles,
while in Linux about 10 millions. This test was run on
Fedora 4 and Suse 9.2 as Linux machines, and Windows
XP Pro with VS .Net 2003 on the MS side. My CPU is a
P4 @3GHz HT 800MHz bus.

I published my little test on several forums and I
wasn't the only one who got these results. All the
other users using 2.6 kernel obtained similar results
regardless of the CPU they had (Intel or AMD). 


Also I downloaded the latest kernel (2.6.12),
configured it specifically for my machine, disabled
all the modules I don't need and compiled it. The
result was a 1.7 MB kernel on which KDE moves faster,
but the processing speed it's the same - same huge
speed ratios.

Also, it shouldn't have any importance, but my HDD is
SATA so the specific modules were required. I don't
think its SCSI modules have any impact on the
processing speed, but you know more on the kernel
architecture then I do.

Now, can anyone explain this and suggest what other
optimizations I should use? The 2.4 version was a lot
faster. I thought the newer versions were supposed to
work faster (or at least just as fast) AND to offer
extra features.

Any help would appreciate.

Thanks,
Ciprian



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-

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

 



Want to increase the latest kernel "speed" by 5 times ? Use the 
follwoing code instead. :)


// -- Start Code
#include 
#include 


int main()
{
clock_t initialTime;
clock_t testTime;
long counter = 0;
double test = 1;


initialTime = clock() / CLOCKS_PER_SEC;
testTime = initialTime;

printf("Here we go...\n");

while((testTime-initialTime) < 30)
{
testTime = clock()/CLOCKS_PER_SEC;
test /= 10;
test *= 10;
test += 10;
test -= 10;

counter ++;

}

printf("No. of cycles: %ld\n", counter);

return 0;
}
//  End code

so essentially you are timing just the time() function.

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

Re: 2.6.13-rc3 test: finding compile errors with make randconfig

[Adrian Bunk]

On Mon, Jul 25, 2005 at 05:42:58AM +1000, Grant Coady wrote:
> On Sun, 24 Jul 2005 11:13:27 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> >it's generally useful, but the target kernel should be the latest -mm
> >kernel. 
> 097-error:drivers/char/drm/drm_memory.h:163: error: redefinition of 
> `drm_ioremap_nocache'
> 097-error:drivers/char/drm/drm_memory.h:163: error: `drm_ioremap_nocache' 
> previously defined here
> 097-error:drivers/char/drm/drm_memory.h:174: error: redefinition of 
> `drm_ioremapfree'
> 097-error:drivers/char/drm/drm_memory.h:174: error: `drm_ioremapfree' 
> previously defined here

This requires the .config for debugging.

My first guess is that drm_memory.h requires a simple #ifdef to allow 
multiple inclusions.

> 098-error:drivers/usb/gadget/ether.c:2510: error: `STATUS_BYTECOUNT' 
> undeclared (first use in this function)
> 098-error:drivers/usb/gadget/ether.c:2510: error: (Each undeclared identifier 
> is reported only once
> 098-error:drivers/usb/gadget/ether.c:2510: error: for each function it 
> appears in.)

Already fixed in 2.6.13-rc3.

> [EMAIL PROTECTED]:/opt/linux/trial4$ grep error *-error |wc -l
> 2105
> 
> With > 2k (raw) errors in 97.something builds of 2.6.12.3, why go 
> looking for trouble in -mm?  
>...

You aren't running into problems that are already fixed (see your second 
example above).

> Grant.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: 2.6.13-rc3 test: finding compile errors with make randconfig

[Jesper Juhl]

On 7/24/05, Grant Coady <[EMAIL PROTECTED]> wrote:
> On Sun, 24 Jul 2005 11:13:27 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> 
> With > 2k (raw) errors in 97.something builds of 2.6.12.3, why go
> looking for trouble in -mm?

Because -mm is the development tree. The things in -mm are what's
eventually going to end up in mainline, so that's what you want to be
testing and fixing, and it's also further ahead than 2.6.12.3 (which
is esentially a dead branch except for critical fixes) so stuff may
already have been fixed there that was broken in 2.6.12.3

> >
> >And doing the compilations is really the trivial part of the work, the
> Got to start somewhere :)
> 
Right you are, and I for one am glad you do it. I build randconfig
kernels myself to look for trouble spots, but I can't get anywhere
near building 200+ configs. On a good day I may build 5 or 6
randconfigs of the latest kernel inbetween doing other things, so
getting hold of the results of several hundred randconfig builds gives
me a lot of material to work on that I would never have the time to
gather myself. Thanks.

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: xor as a lazy comparison

[Grant Coady]

On Sun, 24 Jul 2005 18:40:25 +0200 (MEST), Jan Engelhardt <[EMAIL PROTECTED]> 
wrote:
>
>I have seen this in kernel/signal.c:check_kill_permission()
>
>&& (current->euid ^ t->suid) && (current->euid ^ t->uid)
>
>If current->euid and t->suid are the same, the xor returns 0, so these 
>statements are effectively the same as a !=
>
>   current->euid != t->suid ...
>
>Why ^ ?
To confuse you, coders with assembly or hardware background throw in 
equivalent bit operations to succinctly describe their visualisation 
of solution space...  Perhaps the writer _wanted_ you to pause and 
think?  Maybe the compiler produces better code?  Try it and see.

Grant.

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

Re: Supermount

[zhilla]

well, for a bit of OT discussion sake, here's how it imho SHOULD work, 
from user (noobs and non guru) desktop point of view:
cd/dvds: mounted automatically on insert / first access. if a program is 
running from it (or a file is open from it), and user tries to eject it 
using button, or any eject-like software, kernel sends a signal to a 
central place. which is, for example, picked up from a window manager, 
or even X itself. which, in a friendly and non intrusive way, displays 
something like this: "drive hdc busy, please close the following 
processes first: 1. mplayer 2. blabla".

also, if a blank media is detected on access, it should not be mounted.
usb drives: similar. if user plugs it out without unmounting, its 
unmounted, and processes using files on it gracefully killed, or somehow 
"warned". how to "warn" them? ill let someonbe smarter think of the way 
:) and about ripping it out without closing, wm/anything should yell 
"bad user!! you should ALWAYS unmount first!"
floppys: i suggest leaving things 100% same. btw. i saw some distros 
having problem with accessing ie /mnt/floppy when there is no floppy 
present. bash goes wild with autocompletion. programs pause for a looong 
time. this could be a kernel bug.
other stuff: dont want to sound like troll, but i guess 98% of people 
dont use anything else.
system partitions: make a clear cut between folders which should be seen 
at all by anyone but root, kernel, special software. in other words: 
reduce clutter in / by hiding almost anything! and partition specific 
mount option such as

"userinvisiblefolder=/dev;/sys;/lib;/proc;/sys;/var"
should also be possible. face it, for regular user in varoius distros, / 
is to crowded.
i'm not saying this is all 100% correct or possible. couse this is, 
imho, greatest ugliness, user friendlyness and productivity reducer in 
linux. m$ has it a bit better in some ways, but crappier in other. any 
of these could be a killer feature for 2.8 kernel series. or 2.6.2x :)

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

Re: [PATCH 2.6.13-rc3] pcmcia: pcmcia_request_irq for !IRQ_HANDLE_PRESENT

[Dominik Brodowski]

On Sun, Jul 24, 2005 at 12:40:40PM +0100, Russell King wrote:
> On Sat, Jul 23, 2005 at 10:11:13PM +0200, Dominik Brodowski wrote:
> > Thanks for the excellent debugging. Your patch seems to work, however it
> > might be better to do just this:
> 
> This can be racy if two drivers are simultaneously trying to request an
> IRQ.  'data' must be unique to different threads if they are to avoid
> interfering with each other.

As it's enough to keep PCMCIA functions apart (there can't be two drivers
registering with the same PCMCIA function at the same moment), I'll use that
now.
void *data = _dev->dev.driver; /* something unique to this device */


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

Re: kernel 2.6 speed

[Dag Nygren]

> In windows were performed about 300 millions cycles,
> while in Linux about 10 millions. This test was run on
> Fedora 4 and Suse 9.2 as Linux machines, and Windows
> XP Pro with VS .Net 2003 on the MS side. My CPU is a
> P4 @3GHz HT 800MHz bus.
> 
> I published my little test on several forums and I
> wasn't the only one who got these results. All the
> other users using 2.6 kernel obtained similar results
> regardless of the CPU they had (Intel or AMD). 

Looking at the gcc-produced code from youe test program I 
can see the floating point math beeing optimized away all
together as you are not using the result and the rest more
or less boils down to the call to time() and a few moves
and compares of the time values.
In other words it seems like you are testing the efficiency of
the time() function...

BRGDS
Dag

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

Re: 2.6.13-rc3 test: finding compile errors with make randconfig

[Grant Coady]

On Sun, 24 Jul 2005 11:13:27 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
>it's generally useful, but the target kernel should be the latest -mm
>kernel. 
097-error:drivers/char/drm/drm_memory.h:163: error: redefinition of 
`drm_ioremap_nocache'
097-error:drivers/char/drm/drm_memory.h:163: error: `drm_ioremap_nocache' 
previously defined here
097-error:drivers/char/drm/drm_memory.h:174: error: redefinition of 
`drm_ioremapfree'
097-error:drivers/char/drm/drm_memory.h:174: error: `drm_ioremapfree' 
previously defined here
098-error:drivers/usb/gadget/ether.c:2510: error: `STATUS_BYTECOUNT' undeclared 
(first use in this function)
098-error:drivers/usb/gadget/ether.c:2510: error: (Each undeclared identifier 
is reported only once
098-error:drivers/usb/gadget/ether.c:2510: error: for each function it appears 
in.)
[EMAIL PROTECTED]:/opt/linux/trial4$ grep error *-error |wc -l
2105

With > 2k (raw) errors in 97.something builds of 2.6.12.3, why go 
looking for trouble in -mm?  
>
>And doing the compilations is really the trivial part of the work, the 
Got to start somewhere :)  

Grant.

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

Re: 2.6.13-rc3 test: finding compile errors with make randconfig

[Jesper Juhl]

On 7/24/05, Grant Coady <[EMAIL PROTECTED]> wrote:
> On Sun, 24 Jul 2005 15:01:22 +0200, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> >> context.  Deliberately simplistic for traceability at the moment, truncated
> >> error length for this post.
> >>
> >If you could put the data online somewhere I'd be interrested in
> >taking a look at it.
> 7.4MB raw data --> low info content.  Needs garbage removal.  Good
> test case for gzip vs bzip2 --> 1.4MB vs 481kB,
> 
>   ftp://ftp.scatter.mine.nu/develop/first_run.tar.bz2 (481kB)
> 
> If you mean online info-sys, I don't have bandwidth for that :(
> 
Ok. Would you be able to bzip2 the raw data and email it to me off list ?


-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel page size explanation

[Fawad Lateef]

On 7/25/05, VASM <[EMAIL PROTECTED]> wrote:
> i had one question
> does the linux kernel support only one default page size even if the
> processor on which it is working supports multiple ?
> 

The PAGE_SIZE depends on the architecture and it do supports different
page_sizes depending on the architecture (AFAIK for almost all
supported architectures)

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

Re: 2.6.13-rc3 test: finding compile errors with make randconfig

[Grant Coady]

On Sun, 24 Jul 2005 15:01:22 +0200, Jesper Juhl <[EMAIL PROTECTED]> wrote:
>> context.  Deliberately simplistic for traceability at the moment, truncated
>> error length for this post.
>> 
>If you could put the data online somewhere I'd be interrested in
>taking a look at it.
7.4MB raw data --> low info content.  Needs garbage removal.  Good 
test case for gzip vs bzip2 --> 1.4MB vs 481kB, 

  ftp://ftp.scatter.mine.nu/develop/first_run.tar.bz2 (481kB)

If you mean online info-sys, I don't have bandwidth for that :(

>An easy way to look at the build log and grab the matching .config for
>any given run would be great.

Revisit the data extraction and build an errorlog line_index...  
Will let you know.  

Grant.

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

kernel 2.6 speed

[Ciprian]

Hi guys!

I got a question for you. Apparently kernel 2.6 is
much slower then 2.4 and about 30 times slower then
the windows one.

I'm not an OS guru, but I ran a little and very simple
test. The program bellow, as you can see, measures the
number of cycles performed in 30 seconds.

//- START CODE 

#include 
#include 


int main()
{
time_t initialTime;
time_t testTime;
long counter = 0;
double test = 1;


time();
testTime = initialTime;

printf("Here we go...\n");

while((testTime-initialTime) < 30)
{
time();
test /= 10;
test *= 10;
test += 10;
test -= 10;

counter ++;

}

printf("No. of cycles: %ld\n", counter);

return 0;
}

// END CODE ---


In windows were performed about 300 millions cycles,
while in Linux about 10 millions. This test was run on
Fedora 4 and Suse 9.2 as Linux machines, and Windows
XP Pro with VS .Net 2003 on the MS side. My CPU is a
P4 @3GHz HT 800MHz bus.

I published my little test on several forums and I
wasn't the only one who got these results. All the
other users using 2.6 kernel obtained similar results
regardless of the CPU they had (Intel or AMD). 

Also I downloaded the latest kernel (2.6.12),
configured it specifically for my machine, disabled
all the modules I don't need and compiled it. The
result was a 1.7 MB kernel on which KDE moves faster,
but the processing speed it's the same - same huge
speed ratios.

Also, it shouldn't have any importance, but my HDD is
SATA so the specific modules were required. I don't
think its SCSI modules have any impact on the
processing speed, but you know more on the kernel
architecture then I do.

Now, can anyone explain this and suggest what other
optimizations I should use? The 2.4 version was a lot
faster. I thought the newer versions were supposed to
work faster (or at least just as fast) AND to offer
extra features.

Any help would appreciate.

Thanks,
Ciprian



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Giving developers clue how many testers verified certain kernel version

[Martin MOKREJŠ]

Hi Adrian,
 I think you don't understand me. I do report bugs and will always
do. The point was that developers could be "assured" there is possibly
no problem when people do NOT report bugs in that piece of code
because they would know that it _was_ tested by 1000 people on 357 different
HW's. And they could even check the .configs, lshw etc. Sure the people
would report a problem, but if you do NOT hear of one then there is either no
problem or nobody cared to report that or nobody tested. So you known
just nothing and you better wait some days, weeks so the patch get's lost
in lkml archives if it doesn't happend it gets into -ac or -mm.

 And that is exactly why I proposed this. Then you will know that 1000
people really cared and used that and most probably then it is reasonable
to expect there is really no bug in the code.

 Take it the other way around. You may be reluctant to commit some
patch to the official tree. ;) The guy who wrote the patch says "It was tested,
please apply". ;-) If he says the patch is lying in -mm or -ac tree for
a while - like 2 months you might be more in favor to commit, right?
If you know the patch was tested between -git5 and -git6 by 1000 people
within 5 days you wouldn't wait either, right?
Martin

Adrian Bunk wrote:

On Sun, Jul 24, 2005 at 08:45:16PM +0200, Martin MOKREJ? wrote:

well, the idea was to give you a clue how many people did NOT complain
because it either worked or they did not realize/care. The goal
was different. For example, I have 2 computers and both need current acpi
patch to work fine. I went to bugzilla and found nobody has filed such bugs
before - so I did and said it is already fixed in current acpi patch.
But you'd never know that I tested that successfully. And I don't believe
to get emails from lkml that I installed a patch and it did not break
anything. I hope you get the idea now. ;)



in your ACPI example there is a bug/problem (ACPI needs updating).

And ACPI is a good example where even 1000 success reports wouldn't help 
because a slightly different hardware or BIOS version might make the 
difference.


Usually "no bug report" indicates that something is OK.
And if you are unsure whether an unusual setup or hardware is actually 
tested, it's usually the best to ask on linux-kernel whether someone 
could test it.

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

Re: kernel page size explanation

[VASM]

i had one question 
does the linux kernel support only one default page size even if the
processor on which it is working supports multiple ?

On 7/25/05, Nix <[EMAIL PROTECTED]> wrote:
> On 22 Jul 2005, Jesper Juhl suggested tentatively:
> > You can
> >  A) look in the .config file for your current kernel (if your arch
> > supports different page sizes at all).
> >  B) You can use the  getpagesize(2) syscall at runtime. getpagesize()
> > returns the nr of bytes in a page - man getpagesize - I'm not sure
> > that's universally supported though.
> >  C) You can look at /proc/cpuinfo or /proc/meminfo , IIRC some archs
> > report page size there - not quite sure, can't remember...
> 
> D) getconf PAGE_SIZE should work, although what it does on arches
>   with variable page sizes isn't clear to me.
> 
> --
> `But of course, GR is the very best relativity for the masses.'
>  --- Wayne Throop
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Memory Management

[Neil Horman]

On Sat, Jul 23, 2005 at 08:16:20PM -0300, Márcio Oliveira wrote:
> Neil,
> 
> >The best way I can think to do that is take a look at /proc/slabinfo.  
> >That will
> >likely give you a pointer to which area of code is eating up your memory.
> > 
> >
> OK. I will monitor the /proc/slabinfo file.
> 
> >Based on the sysrq-m info you posted it looks like due to fragmentation the
> >largest chunk of memory you can allocate is 2MB (perhaps less depending on
> >address space availability).  If you can build a test kernel to do a 
> >show_state
> >rather than a show_mem at the beginning of oom_kil, then you should be 
> >able to
> >tell who is trying to do an allocation that leads to kswapd calling
> >out_of_memory.
> > 
> >
> Neil, I'm trying to recompile the kernel source 2.4.21-32.0.1 and get 
> some error messages:
> 
> In file included from 
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/prefetch.h:13,
> from 
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/list.h:6,
> from 
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:12,
> from 3w-.c:172:
> /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:61: warning: 
> parameter names (without types) in function declaration
> /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:61: field 
> `loops_per_jiffy_R_ver_str' declared as a function
> /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: invalid 
> suffix on integer constant
> /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: syntax error 
> before numeric constant
> /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: warning: 
> function declaration isn't a prototype
> /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: invalid 
> suffix on integer constant
> /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: syntax 
> error before numeric constant
> /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: warning: 
> function declaration isn't a prototype
> /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:273: warning: 
> parameter names (without types) in function declaration
> In file included from 3w-.c:172:
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: invalid 
> suffix on integer constant
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: syntax error 
> before numeric constant
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: 
> `inter_module_register_R_ver_str' declared as function returning a function
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: warning: 
> function declaration isn't a prototype
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: invalid 
> suffix on integer constant
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: syntax error 
> before numeric constant
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: 
> `inter_module_unregister_R_ver_str' declared as function returning a 
> function
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: warning: 
> function declaration isn't a prototype
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:192: 
> `inter_module_get_R_ver_str' declared as function returning a function
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:192: warning: 
> parameter names (without types) in function declaration
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:193: 
> `inter_module_get_request_R_ver_str' declared as function returning a 
> function
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:193: warning: 
> parameter names (without types) in function declaration
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: invalid 
> suffix on integer constant
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: syntax error 
> before numeric constant
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: 
> `inter_module_put_R_ver_str' declared as function returning a function
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: warning: 
> function declaration isn't a prototype
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:203: 
> `try_inc_mod_count_R_ver_str' declared as function returning a function
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:203: warning: 
> parameter names (without types) in function declaration
> make[3]: *** [3w-_10200033.o] Error 1
> make[3]: Leaving directory 
> `/usr/src/linux-2.4.21-32.0.1.EL/drivers/addon/3w-_10200033'
> make[2]: *** [_modsubdir_3w-_10200033] Error 2
> make[2]: Leaving directory `/usr/src/linux-2.4.21-32.0.1.EL/drivers/addon'
> make[1]: *** [_modsubdir_addon] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.4.21-32.0.1.EL/drivers'
> make: *** [_mod_drivers] Error 2
> 
> Is there any relationship between the sysrq-m changes to do show_state() 
> rather than a show_mem() and the compiling erros?
> 
> /usr/src/linux-2.4.21-32.0.1.EL/include/linux/prefetch.h, line 13:
>#include 
> 
> 

Re: Giving developers clue how many testers verified certain kernel version

[Adrian Bunk]

On Sun, Jul 24, 2005 at 08:45:16PM +0200, Martin MOKREJ? wrote:

> Hi Adrian,

Hi Martin,

>  well, the idea was to give you a clue how many people did NOT complain
> because it either worked or they did not realize/care. The goal
> was different. For example, I have 2 computers and both need current acpi
> patch to work fine. I went to bugzilla and found nobody has filed such bugs
> before - so I did and said it is already fixed in current acpi patch.
> But you'd never know that I tested that successfully. And I don't believe
> to get emails from lkml that I installed a patch and it did not break
> anything. I hope you get the idea now. ;)

in your ACPI example there is a bug/problem (ACPI needs updating).

And ACPI is a good example where even 1000 success reports wouldn't help 
because a slightly different hardware or BIOS version might make the 
difference.

Usually "no bug report" indicates that something is OK.
And if you are unsure whether an unusual setup or hardware is actually 
tested, it's usually the best to ask on linux-kernel whether someone 
could test it.

> Martin

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: Giving developers clue how many testers verified certain kernel version

[Martin MOKREJŠ]

Hi Adrian,
 well, the idea was to give you a clue how many people did NOT complain
because it either worked or they did not realize/care. The goal
was different. For example, I have 2 computers and both need current acpi
patch to work fine. I went to bugzilla and found nobody has filed such bugs
before - so I did and said it is already fixed in current acpi patch.
But you'd never know that I tested that successfully. And I don't believe
to get emails from lkml that I installed a patch and it did not break
anything. I hope you get the idea now. ;)
Martin

Adrian Bunk wrote:

On Fri, Jul 22, 2005 at 03:34:09AM +0200, Martin MOKREJ? wrote:



Hi,



Hi Martin,



I think the discussion going on here in another thread about lack
of positive information on how many testers successfully tested certain
kernel version can be easily solved with real solution.

How about opening separate "project" in bugzilla.kernel.org named
kernel-testers or whatever, where whenever cvs/svn/bk gatekeepers
would release some kernel patch, would open an empty "bugreport"
for that version, say for 2.6.13-rc3-git4.

Anybody willing to join the crew who cared to download the patch
and tested the kernel would post just a single comment/follow-up
to _that_ "bugreport" with either "positive" rating or URL
of his own bugreport with some new bug. When the bug get's closed
it would be immediately obvious in the 2.6.13-rc3-git4 bug ticket
as that bug will be striked-through as closed.

Then, we could easily just browse through and see that 2.6.13-rc2
was tested by 33 fellows while 3 of them found a problem and 2 such
problems were closed since then.
...



most likely, only a small minory of the people downloading a patch would 
register at such a "project".


The important part of the work, the bug reports, can already today go to 
lnux-kernel and/or the Bugzilla.


You'd spend efforts for such a "project" that would only produce some 
numbers of questionable value.




Martin



cu
Adrian



--
Martin Mokrejs
Email: 'bW9rcmVqc21Acmlib3NvbWUubmF0dXIuY3VuaS5jeg==\n'.decode('base64')
GPG key is at http://www.natur.cuni.cz/~mmokrejs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel page size explanation

[Nix]

On 22 Jul 2005, Jesper Juhl suggested tentatively:
> You can
>  A) look in the .config file for your current kernel (if your arch
> supports different page sizes at all).
>  B) You can use the  getpagesize(2) syscall at runtime. getpagesize()
> returns the nr of bytes in a page - man getpagesize - I'm not sure
> that's universally supported though.
>  C) You can look at /proc/cpuinfo or /proc/meminfo , IIRC some archs
> report page size there - not quite sure, can't remember...

D) getconf PAGE_SIZE should work, although what it does on arches
   with variable page sizes isn't clear to me.

-- 
`But of course, GR is the very best relativity for the masses.'
 --- Wayne Throop
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

do_gettimeofday monotony?

[bert hubert]

Is do_gettimeofday supposed to be monotonous? I'm seeing time go backward by
tiny amounts, and then progressing.

I'm using do_gettimeofday on a single processor, CONFIG_PREEMPT_NONE=y, and
saving stuff from generic_make_request - see http://ds9a.nl/diskstat for the
source. 2.6.13-rc3-mm1, HZ=250.

I'll try to figure out how much it is going back, and it is some kind of
magic interval.

Is there another monotonous clock in the kernel that doesn't wrap (all
that often)? Doesn't really need to be wall time.

Thanks!

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://netherlabs.nl  Open and Closed source services
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 build empty object files in drivers/media?

[Johannes Stezenbach]

On Sun, Jul 24, 2005 at 08:58:45AM +, Sam Ravnborg wrote:
> On Sun, Jul 24, 2005 at 04:10:13PM +1000, Keith Owens wrote:
> > >
> > >diff --git a/drivers/media/Makefile b/drivers/media/Makefile
> > >--- a/drivers/media/Makefile
> > >+++ b/drivers/media/Makefile
> > >@@ -2,4 +2,7 @@
> > > # Makefile for the kernel multimedia device drivers.
> > > #
> > > 
> > >-obj-y:= video/ radio/ dvb/ common/
> > >+obj-y   := common/
> > >+obj-$(CONFIG_VIDEO_DEV) := video/
> > >+obj-$(CONFIG_VIDEO_DEV) := radio/
> > >+obj-$(CONFIG_DVB)   := dvb/
> > 
> > That should be +=, not :=
> > 
> > +obj-$(CONFIG_VIDEO_DEV) += video/
> > +obj-$(CONFIG_VIDEO_DEV) += radio/
> > +obj-$(CONFIG_DVB)   += dvb/
> 
> Correct - thanks!

OK, I'll pick this up and put it in CVS.

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

Re: CIFS slowness & crashes

[Lasse Kärkkäinen / Tronic]

>>nor umount -f
> What are the errors?  What is the version of cifs.ko module?

umount2: Device or resource busy
umount: /tmpmnt: device is busy
umount2: Device or resource busy
umount: /tmpmnt: device is busy

Without -f it doesn't print those umount2 errors, just the other two.

The version is whatever comes with 2.6.12 or 2.6.13rc1.

> My tests of reconnection after server crash or network reconnection with
> smbfs works (for the past year or two) and also of course for cifs. 
> cifs also reconnects state (open files) not just the connection to
> \\server\share

Reconnection usually (or perhaps always, with new versions) works, but
nothing cannot be done if the server goes permanently offline (nor until
it comes back online). When the server is down, the programs that were
using the CIFS mount or that try to access it will halt.

> My informal tests (cifs->samba) showed a maximum of about 20%
> utilization of gigabit doing large file writes and about double that for
> large file reads with a single cifs client to Samba over gigabit. Should
> be somewhat simalar to Windows server.

This seems quite bad. Is it waiting for packet confirmations or what?

However, I have never got anything better than about 40 Mo/s with a
gigabit network so far. Jumbo frames and using direct cross-over cable
between the clients make no difference. Still, all protocols that I have
tried, except for SMB and CIFS, can reach that easily. I'll try to get
two Windows machines that I can test with. Perhaps the problem is with
Linux network drivers.

Anyway, 20 Mo/s or something like that would not be a big problem. The
real problem occurs when the speed drops under 3 Mo/s.

> The most common cause of widely varying speeds are the following:
> 1) memory fragmentation - some versions of the kernel badly fragment
> slab allocations greater than 4 pages (cifs by default allocates 16.5K
> buffers - which results in larger size allocations when more than 5
> processes are accessing the mount and the cifs buffer pool is exceeded)

Wouldn't this show up as increased system loads?

> 2) write behind due to oplock - smbfs does not do oplock, cifs does -
> which means that cifs client caching can cause a large amount of
> writebehind data to accumulate (with great performance for a while) -
> then when memory gets tight due to the inode caching in linux's mm
> layer, the cifs client is asked to write out a large amount of file data
> at one time (which it does synchronously). 
> 
> Both of these are being improved.  You can bypass the inode caching on
> the client by using the cifs mount option
>   "forcedirectio"

This option has little or no effect. Still runs slowly (2.4 Mo/s right now).

My benchmark is reading data in 50 Mio chunks, as quickly as it can,
calculating the average read speed. The files being read are bigger than
4 Gio. I haven't tried writing anything (the shares that I play with are
read-only).

For the record, I am using O_RDONLY | O_LARGEFILE on open and then pread
 for all reads. However, I am getting similar results with all programs,
so I don't think that the reading method really matters that much.

- Tronic -



signature.asc
Description: OpenPGP digital signature

Re: [patch 1/2] Touchscreen support for sharp sl-5500

[randy_dunlap]

On Sun, 24 Jul 2005 17:47:56 +0100 Russell King wrote:

> On Fri, Jul 22, 2005 at 08:01:09PM +0200, Pavel Machek wrote:
> > This adds support for reading ADCs (etc), neccessary to operate touch
> > screen on Sharp Zaurus sl-5500.
> 
> I would like to know what the diffs are between my version (attached)
> and this version before they get applied.
> 
> The only reason my version has not been submitted is because it lives
> in the drivers/misc directory, and mainline kernel folk don't like
> drivers which clutter up that directory.  In fact, I had been told
> that drivers/misc should remain completely empty - which makes this
> set of miscellaneous drivers homeless.

but clearly drivers/misc/ is not empty, unless you mean at its
top level.

The IBM ASM service processor driver is there (added in 2.6.x)
as well as some hdpuftrs/ driver, which is not in any Kconfig file
or defconfig file.  :(

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

Re: [patch 1/2] Touchscreen support for sharp sl-5500

[Richard Purdie]

On Sun, 2005-07-24 at 17:47 +0100, Russell King wrote:
> On Fri, Jul 22, 2005 at 08:01:09PM +0200, Pavel Machek wrote:
> > This adds support for reading ADCs (etc), neccessary to operate touch
> > screen on Sharp Zaurus sl-5500.
> 
> I would like to know what the diffs are between my version (attached)
> and this version before they get applied.
> 
> The only reason my version has not been submitted is because it lives
> in the drivers/misc directory, and mainline kernel folk don't like
> drivers which clutter up that directory.  In fact, I had been told
> that drivers/misc should remain completely empty - which makes this
> set of miscellaneous drivers homeless.

I've been wondering about suggesting the creation of a drivers/soc
directory. The idea would be for it to contain "system on chip" type
support code. I use that description loosely to fit any code which needs
to support drivers in multiple driver subsections.

An example use in my Zaurus tree is the TSC2101 which contains a
touchscreen, battery monitoring and sound. Handhelds.org has devices
such as the ASIC2/ASIC3 in the ipaqs (and other handhelds) which cover
many different drivers subsections.

Where practical, the sub drivers such as the touchscreen could be placed
into the specific driver areas such as drivers/input/touchscreen/ but
the core chip specific support would be in drivers/soc and the files
would be connected. 

Would that be acceptable in mainline?

Richard








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

Re: [patch 1/2] Touchscreen support for sharp sl-5500

[Russell King]

On Fri, Jul 22, 2005 at 08:01:09PM +0200, Pavel Machek wrote:
> This adds support for reading ADCs (etc), neccessary to operate touch
> screen on Sharp Zaurus sl-5500.

I would like to know what the diffs are between my version (attached)
and this version before they get applied.

The only reason my version has not been submitted is because it lives
in the drivers/misc directory, and mainline kernel folk don't like
drivers which clutter up that directory.  In fact, I had been told
that drivers/misc should remain completely empty - which makes this
set of miscellaneous drivers homeless.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core


ucb1x00.tar.gz
Description: GNU Zip compressed data

xor as a lazy comparison

[Jan Engelhardt]

Hi list,


I have seen this in kernel/signal.c:check_kill_permission()

&& (current->euid ^ t->suid) && (current->euid ^ t->uid)

If current->euid and t->suid are the same, the xor returns 0, so these 
statements are effectively the same as a !=

current->euid != t->suid ...

Why ^ ?


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

Re: 2.6.13-rc3-mm1

[Richard Purdie]

On Fri, 2005-07-15 at 01:36 -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/

On the Zaurus I'm seeing a couple of false "BUG: soft lockup detected on
CPU#0!" reports. These didn't show under 2.6.12-mm1 which was the last
-mm kernel I tested. softlockup.c seems identical between these versions
so it looks like some other change has caused this to appear...

Both of these are triggered from the nand driver. The functions
concerned (nand_wait_ready and nand_read_buf) are known to be slow (they
wait on hardware).

Richard

BUG: soft lockup detected on CPU#0!
Pid: 1, comm:  swapper
CPU: 0
PC is at sharpsl_nand_dev_ready+0x14/0x28
LR is at nand_wait_ready+0x30/0x50
pc : []lr : []Not tainted
sp : c034fa24  ip : c034fa34  fp : c034fa30
r10: c3c09400  r9 : c035e890  r8 : c75a
r7 : c022533c  r6 : c3c09580  r5 : c3c09400  r4 : 8fc3
r3 : c027f0bc  r2 : c4856000  r1 : c4856000  r0 : c3c09400
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  Segment kernel
Control: 397F  Table: A0004000  DAC: 0017
[] (show_regs+0x0/0x4c) from [] (softlockup_tick
+0x7c/0xb0)
 r4 = C034E000
[] (softlockup_tick+0x0/0xb0) from [] (do_timer
+0x278/0x500)
 r5 =   r4 = 0001
[] (do_timer+0x0/0x500) from [] (timer_tick
+0xb4/0xf8)
[] (timer_tick+0x0/0xf8) from []
(pxa_timer_interrupt+0x48/0xa8)
 r6 = C034F9DC  r5 = C034E000  r4 = F2A0
[] (pxa_timer_interrupt+0x0/0xa8) from [] (__do_irq
+0x6c/0xc4)
 r8 = C034F9DC  r7 =   r6 =   r5 = C034E000
 r4 = C0226314
[] (__do_irq+0x0/0xc4) from [] (do_level_IRQ
+0x68/0xb8)
[] (do_level_IRQ+0x0/0xb8) from [] (asm_do_IRQ
+0x54/0x164)
 r6 = 0400  r5 = F2D0  r4 = 
[] (asm_do_IRQ+0x0/0x164) from [] (__irq_svc
+0x38/0x78)
[] (sharpsl_nand_dev_ready+0x0/0x28) from []
(nand_wait_ready+0x30/0x50)
[] (nand_wait_ready+0x0/0x50) from [] (nand_command
+0x9c/0x1f0)
 r7 =   r6 = C3C09400  r5 = C3C09580  r4 = 
[] (nand_command+0x0/0x1f0) from []
(nand_do_read_ecc+0x720/0x7c8)
 r8 = C034FACC  r7 = 0200  r6 = C3C09580  r5 = C75A
 r4 = 
[] (nand_do_read_ecc+0x0/0x7c8) from []
(nand_read_ecc+0x44/0x4c)
[] (nand_read_ecc+0x0/0x4c) from [] (part_read_ecc
+0xa4/0xbc)
 r4 = 
[] (part_read_ecc+0x0/0xbc) from []
(jffs2_flash_read+0x1fc/0x2b0)
 r7 =   r6 = 011E8B70  r5 =   r4 = C034FBF0
[] (jffs2_flash_read+0x0/0x2b0) from []
(jffs2_fill_scan_buf+0x2c/0x4c)
[] (jffs2_fill_scan_buf+0x0/0x4c) from []
(jffs2_scan_medium+0x63c/0x1884)
 r4 = 011E8B7C
[] (jffs2_scan_medium+0x0/0x1884) from []
(jffs2_do_mount_fs+0x1bc/0x6cc)
[] (jffs2_do_mount_fs+0x0/0x6cc) from []
(jffs2_do_fill_super+0x130/0x2b4)
[] (jffs2_do_fill_super+0x0/0x2b4) from []
(jffs2_get_sb_mtd+0xf4/0x134)
 r8 = 8401  r7 = C3C4B4E0  r6 = C3C4B4FC  r5 = C3C4B200
 r4 = C3C4B400
[] (jffs2_get_sb_mtd+0x0/0x134) from []
(jffs2_get_sb_mtdnr+0x50/0x5c)
[] (jffs2_get_sb_mtdnr+0x0/0x5c) from []
(jffs2_get_sb+0x130/0x1c0)
 r7 = 8001  r6 = C034FD5C  r5 = C3C5  r4 = FFEA
[] (jffs2_get_sb+0x0/0x1c0) from [] (do_kern_mount
+0x50/0xf4)
[] (do_kern_mount+0x0/0xf4) from [] (do_mount
+0x3ac/0x650)
[] (do_mount+0x0/0x650) from [] (sys_mount
+0x9c/0xe8)
[] (sys_mount+0x0/0xe8) from [] (mount_block_root
+0xb0/0x264)
 r7 = C0343000  r6 = C034FF54  r5 = C0343006  r4 = C0343000
[] (mount_block_root+0x0/0x264) from [] (mount_root
+0x5c/0x6c)
[] (mount_root+0x0/0x6c) from [] (prepare_namespace
+0x40/0xe4)
 r5 = C0019C70  r4 = C0019CC0
[] (prepare_namespace+0x0/0xe4) from [] (init
+0x190/0x1fc)
 r5 = C034E000  r4 = C01F5AA0
[] (init+0x0/0x1fc) from [] (do_exit+0x0/0xd8c)
 r8 =   r7 =   r6 =   r5 = 
 r4 = 
VFS: Mounted root (jffs2 filesystem) readonly.

and 

BUG: soft lockup detected on CPU#0!
Pid: 1063, comm:  busybox
CPU: 0
PC is at nand_read_buf+0x28/0x3c
LR is at 0x100
pc : []lr : [<0100>]Not tainted
sp : c355dac8  ip : 003b  fp : c355dad4
r10: c3c09400  r9 : c3b20884  r8 : 0002
r7 :   r6 : c3c09580  r5 :   r4 : c3b20884
r3 : c4856014  r2 : 00d3  r1 : c3b20884  r0 : c3c09580
Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 397F  Table: A354C000  DAC: 0015
[] (show_regs+0x0/0x4c) from [] (softlockup_tick
+0x7c/0xb0)
 r4 = C355C000
[] (softlockup_tick+0x0/0xb0) from [] (do_timer
+0x278/0x500)
 r5 =   r4 = 0001
[] (do_timer+0x0/0x500) from [] (timer_tick
+0xb4/0xf8)
[] (timer_tick+0x0/0xf8) from []
(pxa_timer_interrupt+0x48/0xa8)
 r6 = C355DA80  r5 = C355C000  r4 = F2A0
[] (pxa_timer_interrupt+0x0/0xa8) from [] (__do_irq
+0x6c/0xc4)
 r8 = C355DA80  r7 =   r6 =   r5 = C355C000
 r4 = C0226314
[] (__do_irq+0x0/0xc4) from [] (do_level_IRQ
+0x68/0xb8)
[] (do_level_IRQ+0x0/0xb8) from [] (asm_do_IRQ
+0x54/0x164)
 r6 = 0400  r5 = F2D0  r4 = 
[] (asm_do_IRQ+0x0/0x164) from [] (__irq_svc
+0x38/0x78)
[] (nand_read_buf+0x0/0x3c) from []

Re: IRQ routing problem in 2.6.10-rc2

[Jesper Juhl]

On 7/24/05, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >> PCI: Using ACPI for IRQ routing
> >> ** PCI interrupts are no longer routed automatically.  If this
> >> ** causes a device to stop working, it is probably because the
> >> ** driver failed to call pci_enable_device().  As a temporary
> >> ** workaround, the "pci=routeirq" argument restores the old
> >> ** behavior.  If this argument makes the device work again,
> >> ** please email the output of "lspci" to [EMAIL PROTECTED]
> >> ** so I can fix the driver.
> >Have you tried the suggestion given "... As a temporary workaround,
> >the "pci=routeirq" argument..." ?
> >You could also try the pci=noacpi boot option to see if that changes 
> >anything.
> 
> Hi,
> 
> and what's the proper fix for pci=routeirq? I got a driver that is only
> maintained by myself and would like to fix up the issue.
> 
While I don't /know/ exactely what the proper fix is I'll venture a
guess based on the information in the text above : The driver probably
doesn't call pci_enable_device().
Quoting the message at bootup time "If this causes a device to stop
working, it is probably because the driver failed to call
pci_enable_device().".
Also, the Kernel Janitors TODO list
(http://janitor.kernelnewbies.org/TODO) has this to say about
pci_enable_device() :
  - ALL PCI drivers should call pci_enable_device --before-- reading
pdev->irq or pdev->resource[].  irq and resource[] may not have correct
values until after PCI hotplug setup occurs at pci_enable_device()
time.  Many PCI drivers need to be evaluated and checked for this.

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [stable] Re: [05/11] SMP fix for 6pack driver

[Adrian Bunk]

On Sun, Jul 17, 2005 at 05:09:39PM -0400, Ralf Baechle wrote:
> On Fri, Jul 15, 2005 at 09:35:56PM +0200, Adrian Bunk wrote:
> 
> > I do agree with Francois regarding this issue:
> > 
> > AFAIR, there has been not one 2.6 kernel where this driver was available 
> > for SMP kernels.
> 
> Eh...  That after all is the raison d'etre for this patch :)
> 
> > It's therefore untested which problems might arise with 
> > this driver on SMP systems. I'm not arguing against including this 
> > driver in 2.6.13, but 2.6.12.3 isn't the right place.
> 
> Nonsense.  Most development activity for this stuff happens not on the
> internet and you won't be able to follow it unless you're a licensed ham.
> I've been circulating things patch since a while and nobody has been unhappy.

So why was it important to get it into 2.6.12.3?

I must have missed the announcement that the original -stable goals have 
been declared obsolete.

> > What surprises me most is that you accepted this patch is neither in 
> > 2.6.13-rc3 nor in 2.6.13-rc3-mm1. There seems to be either an
> > (IMHO unfortunate) change in your policy of what patches to accept,
> > or there's a serious problem in your patch review process.
> 
> I've sent it to jgarzik so it's somewhere on it's long way there.
> 
>   Ralf

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)

[Jan Engelhardt]

>Maybe you want to put your development machines on ext*2* while doing
>this ;-). Or perhaps reiserfs/xfs/something.

Or perhaps into at the VFS level, so any fs can benefit from it.



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

Re: IRQ routing problem in 2.6.10-rc2

[Jan Engelhardt]

>> PCI: Using ACPI for IRQ routing
>> ** PCI interrupts are no longer routed automatically.  If this
>> ** causes a device to stop working, it is probably because the
>> ** driver failed to call pci_enable_device().  As a temporary
>> ** workaround, the "pci=routeirq" argument restores the old
>> ** behavior.  If this argument makes the device work again,
>> ** please email the output of "lspci" to [EMAIL PROTECTED]
>> ** so I can fix the driver.
>Have you tried the suggestion given "... As a temporary workaround,
>the "pci=routeirq" argument..." ?
>You could also try the pci=noacpi boot option to see if that changes anything.

Hi,

and what's the proper fix for pci=routeirq? I got a driver that is only 
maintained by myself and would like to fix up the issue.



Jan Engelhardt
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.12.3] dyntick 050610-1 breaks makes S3 suspend

[Jan De Luyck]

On Sunday 24 July 2005 16:23, Pavel Machek wrote:
> Hi!
>
> > > I recently tried out dyntick 050610-1 against 2.6.12.3, works great, it
> > > actually makes a noticeable difference on my laptop's battery life. I
> > > don't have hard numbers, lets just say that instead of the usual ~3
> > > hours i get out of it, i was ~4 before it started nagging, usual use
> > > pattern at work.
> > >
> > > The only gripe I have with it that it stops S3 from working. If the
> > > patch is compiled in the kernel, it makes S3 suspend correctly, but
> > > resuming goes into a solid hang (nothing get's it back alive, have to
> > > keep the powerbutton for ~5 secs to shutdown the system)
> > >
> > > Anything I could test? The logs don't give anything useful..
> >
> > I reported this some time ago [1], but there's no sulution so far...
> >
> > [1] http://groups.google.com/groups?selm=4b4NI-7mJ-9%40gated-at.bofh.it
>
> Does it also break if swsusp? Does it break if you replace enter sleep
> function with some kind of dummy functions? (Or perhaps S1 is enough
> for this test?)

I have only tried with S3.. how do I test with S1?

Jan

-- 
YOW!!  I'm in a very clever and adorable INSANE ASYLUM!!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RTC Timezone

[Jan Engelhardt]

Hi,


My RTC clock is set to the local timezone. However, when I boot linux using 
the -b option, to stop by a shell before the bootscripts begin, the clock is 
exaclty two hours ahead.
Is the timezone stored in the RTC? If no, how can Linux know I am in UTC+0200?



Jan Engelhardt
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 NFS 2/3] Lose second parameter of nfs_block_bits

[Rene Scharfe]

[PATCH NFS 2/3] Lose second parameter of nfs_block_bits

Two of the three calls were passing a NULL pointer and we can simply
calculate the number of bits ourselves.

Signed-off-by: Rene Scharfe <[EMAIL PROTECTED]>
---

 fs/nfs/inode.c |   17 -
 1 files changed, 8 insertions(+), 9 deletions(-)

d81155b5789ac9d7e05261f5f4bf639e7982fa4b
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -187,17 +187,15 @@ nfs_umount_begin(struct super_block *sb)
 
 
 static inline unsigned long
-nfs_block_bits(unsigned long bsize, unsigned char *nrbitsp)
+nfs_block_bits(unsigned long bsize)
 {
/* make sure blocksize is a power of two */
-   if ((bsize & (bsize - 1)) || nrbitsp) {
+   if (bsize & (bsize - 1)) {
unsigned char   nrbits;
 
for (nrbits = 31; nrbits && !(bsize & (1 << nrbits)); nrbits--)
;
bsize = 1 << nrbits;
-   if (nrbitsp)
-   *nrbitsp = nrbits;
}
 
return bsize;
@@ -224,7 +222,7 @@ nfs_block_size(unsigned long bsize)
else if (bsize >= NFS_MAX_FILE_IO_BUFFER_SIZE)
bsize = NFS_MAX_FILE_IO_BUFFER_SIZE;
 
-   return nfs_block_bits(bsize, NULL);
+   return nfs_block_bits(bsize);
 }
 
 /*
@@ -320,10 +318,11 @@ nfs_sb_init(struct super_block *sb, rpc_
 server->wsize = server->wpages << PAGE_CACHE_SHIFT;
}
 
-   if (sb->s_blocksize == 0)
-   sb->s_blocksize = nfs_block_bits(server->wsize,
->s_blocksize_bits);
-   server->wtmult = nfs_block_bits(fsinfo.wtmult, NULL);
+   if (sb->s_blocksize == 0) {
+   sb->s_blocksize = nfs_block_bits(server->wsize);
+   sb->s_blocksize_bits = fls(sb->s_blocksize - 1);
+   }
+   server->wtmult = nfs_block_bits(fsinfo.wtmult);
 
server->dtsize = nfs_block_size(fsinfo.dtpref);
if (server->dtsize > PAGE_CACHE_SIZE)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()

[Rene Scharfe]

[PATCH NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()

Function nfs_block_bits() an open-coded version of (the non-existing)
rounddown_pow_of_two().  That means that for non-power-of-two target
sizes it returns half the size needed for a block to fully contain
the target.  I guess this is wrong. :-)  The patch uses the built-in
roundup_pow_of_two() instead.

Signed-off-by: Rene Scharfe <[EMAIL PROTECTED]>
---

 fs/nfs/inode.c |   22 +++---
 1 files changed, 3 insertions(+), 19 deletions(-)

4130722d1eeb5eb22c38df9f09dfa6be554bc72c
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -185,22 +185,6 @@ nfs_umount_begin(struct super_block *sb)
rpc_killall_tasks(rpc);
 }
 
-
-static inline unsigned long
-nfs_block_bits(unsigned long bsize)
-{
-   /* make sure blocksize is a power of two */
-   if (bsize & (bsize - 1)) {
-   unsigned char   nrbits;
-
-   for (nrbits = 31; nrbits && !(bsize & (1 << nrbits)); nrbits--)
-   ;
-   bsize = 1 << nrbits;
-   }
-
-   return bsize;
-}
-
 /*
  * Calculate the number of 512byte blocks used.
  */
@@ -222,7 +206,7 @@ nfs_block_size(unsigned long bsize)
else if (bsize >= NFS_MAX_FILE_IO_BUFFER_SIZE)
bsize = NFS_MAX_FILE_IO_BUFFER_SIZE;
 
-   return nfs_block_bits(bsize);
+   return roundup_pow_of_two(bsize);
 }
 
 /*
@@ -319,10 +303,10 @@ nfs_sb_init(struct super_block *sb, rpc_
}
 
if (sb->s_blocksize == 0) {
-   sb->s_blocksize = nfs_block_bits(server->wsize);
+   sb->s_blocksize = roundup_pow_of_two(server->wsize);
sb->s_blocksize_bits = fls(sb->s_blocksize - 1);
}
-   server->wtmult = nfs_block_bits(fsinfo.wtmult);
+   server->wtmult = roundup_pow_of_two(fsinfo.wtmult);
 
server->dtsize = nfs_block_size(fsinfo.dtpref);
if (server->dtsize > PAGE_CACHE_SIZE)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 NFS 1/3] Lose second parameter of nfs_block_size().

[Rene Scharfe]

[PATCH NFS 1/3] Lose second parameter of nfs_block_size().

Most calls to nfs_block_size() were done with a NULL pointer as second
parameter anyway.  We can simply calculate the number of bits ourselves
instead of using that ugly pointer thingy.

Signed-off-by: Rene Scharfe <[EMAIL PROTECTED]>
---

 fs/nfs/inode.c |   30 --
 1 files changed, 16 insertions(+), 14 deletions(-)

6ba4cb36d1e905852917305146fbe0076ad1d86f
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -217,14 +217,14 @@ nfs_calc_block_size(u64 tsize)
  * Compute and set NFS server blocksize
  */
 static inline unsigned long
-nfs_block_size(unsigned long bsize, unsigned char *nrbitsp)
+nfs_block_size(unsigned long bsize)
 {
if (bsize < 1024)
bsize = NFS_DEF_FILE_IO_BUFFER_SIZE;
else if (bsize >= NFS_MAX_FILE_IO_BUFFER_SIZE)
bsize = NFS_MAX_FILE_IO_BUFFER_SIZE;
 
-   return nfs_block_bits(bsize, nrbitsp);
+   return nfs_block_bits(bsize, NULL);
 }
 
 /*
@@ -293,16 +293,16 @@ nfs_sb_init(struct super_block *sb, rpc_
server->namelen = pathinfo.max_namelen;
/* Work out a lot of parameters */
if (server->rsize == 0)
-   server->rsize = nfs_block_size(fsinfo.rtpref, NULL);
+   server->rsize = nfs_block_size(fsinfo.rtpref);
if (server->wsize == 0)
-   server->wsize = nfs_block_size(fsinfo.wtpref, NULL);
+   server->wsize = nfs_block_size(fsinfo.wtpref);
 
if (fsinfo.rtmax >= 512 && server->rsize > fsinfo.rtmax)
-   server->rsize = nfs_block_size(fsinfo.rtmax, NULL);
+   server->rsize = nfs_block_size(fsinfo.rtmax);
if (fsinfo.wtmax >= 512 && server->wsize > fsinfo.wtmax)
-   server->wsize = nfs_block_size(fsinfo.wtmax, NULL);
+   server->wsize = nfs_block_size(fsinfo.wtmax);
 
-   max_rpc_payload = nfs_block_size(rpc_max_payload(server->client), NULL);
+   max_rpc_payload = nfs_block_size(rpc_max_payload(server->client));
if (server->rsize > max_rpc_payload)
server->rsize = max_rpc_payload;
if (server->wsize > max_rpc_payload)
@@ -325,7 +325,7 @@ nfs_sb_init(struct super_block *sb, rpc_
 >s_blocksize_bits);
server->wtmult = nfs_block_bits(fsinfo.wtmult, NULL);
 
-   server->dtsize = nfs_block_size(fsinfo.dtpref, NULL);
+   server->dtsize = nfs_block_size(fsinfo.dtpref);
if (server->dtsize > PAGE_CACHE_SIZE)
server->dtsize = PAGE_CACHE_SIZE;
if (server->dtsize > server->rsize)
@@ -419,12 +419,14 @@ nfs_fill_super(struct super_block *sb, s
server   = NFS_SB(sb);
sb->s_blocksize_bits = 0;
sb->s_blocksize = 0;
-   if (data->bsize)
-   sb->s_blocksize = nfs_block_size(data->bsize, 
>s_blocksize_bits);
+   if (data->bsize) {
+   sb->s_blocksize = nfs_block_size(data->bsize);
+   sb->s_blocksize_bits = fls(sb->s_blocksize - 1);
+   }
if (data->rsize)
-   server->rsize = nfs_block_size(data->rsize, NULL);
+   server->rsize = nfs_block_size(data->rsize);
if (data->wsize)
-   server->wsize = nfs_block_size(data->wsize, NULL);
+   server->wsize = nfs_block_size(data->wsize);
server->flags= data->flags & NFS_MOUNT_FLAGMASK;
 
server->acregmin = data->acregmin*HZ;
@@ -1619,9 +1621,9 @@ static int nfs4_fill_super(struct super_
sb->s_blocksize = 0;
server = NFS_SB(sb);
if (data->rsize != 0)
-   server->rsize = nfs_block_size(data->rsize, NULL);
+   server->rsize = nfs_block_size(data->rsize);
if (data->wsize != 0)
-   server->wsize = nfs_block_size(data->wsize, NULL);
+   server->wsize = nfs_block_size(data->wsize);
server->flags = data->flags & NFS_MOUNT_FLAGMASK;
server->caps = NFS_CAP_ATOMIC_OPEN;
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 NFS 0/3] Cleanup/fix nfs_block_size() and nfs_block_bits()

[Rene Scharfe]

[PATCH NFS 0/3] Cleanup/fix nfs_block_size() and nfs_block_bits()

The Plan 9 filesystem for Linux had some code which wrongly calculated
the size of blocks.  A comment said this code has been taken from NFS.

Patch 3 of this series contains a fix for the bug, the first two patches
are preparation work and shouldn't change the results.  I didn't went so
far and actually test the patch, so please be careful. =)  Compiles fine
here, at least.

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: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)

[Pavel Machek]

Hi!

> Thanks for your suggestions and help.
> 
> We started it from 2.6.7 last year and then it was sitting idle for several 
> months for lack of resources. We'll go back to that version and generate a 
> diff that's easier to read.
> 
> Yes, changing the name has made the task of rebasing wrt. changing kernels 
> lot 
> difficult. Our original intention was to make testing easier by keeping ext3 
> and checkfs filesystems in the same kernel. Had we continued it at that 
> point, we would have posted differences wrt. ext3 sources themselves. There 
> was compelling reason to change the name.

Maybe you want to put your development machines on ext*2* while doing
this ;-). Or perhaps reiserfs/xfs/something.
Pavel

-- 
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.12.3] dyntick 050610-1 breaks makes S3 suspend

[Pavel Machek]

Hi!

> > I recently tried out dyntick 050610-1 against 2.6.12.3, works great, it
> > actually makes a noticeable difference on my laptop's battery life. I don't
> > have hard numbers, lets just say that instead of the usual ~3 hours i get
> > out of it, i was ~4 before it started nagging, usual use pattern at work.
> >
> > The only gripe I have with it that it stops S3 from working. If the patch
> > is compiled in the kernel, it makes S3 suspend correctly, but resuming goes
> > into a solid hang (nothing get's it back alive, have to keep the
> > powerbutton for ~5 secs to shutdown the system)
> >
> > Anything I could test? The logs don't give anything useful..
> 
> I reported this some time ago [1], but there's no sulution so far...
> 
> [1] http://groups.google.com/groups?selm=4b4NI-7mJ-9%40gated-at.bofh.it

Does it also break if swsusp? Does it break if you replace enter sleep
function with some kind of dummy functions? (Or perhaps S1 is enough
for this test?)
Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IRQ routing problem in 2.6.10-rc2

[Jesper Juhl]

On 7/24/05, Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Sorry about reporting this error so late but the machine in question had
> gone some time without upgrades.
> 
> The problem I'm seeing is that IRQs stop working for one of the IRQ
> slots on the machine. It's only that slot, not the entire IRQ, since the
> two slots (it's a small machine) both get routed to IRQ 10.
> 
> I've included dmesg from 2.6.10-rc1 (which works) and 2.6.10-rc2 (which
> doesn't).
> 
> I've also tried reverting the patches that modifies
> arch/i386/kernel/irq.c and arch/i386/pci/irq.c but it didn't solve the
> problem. So now I need some more input on which patches to try.
> 
[snip]
> 
> Linux version 2.6.10-rc2 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 (Red 
> Hat Linux 3.3.3-7)) #8 Wed Jul 20 02:57:15 CEST 2005
[snip]
> ACPI: Using PIC for interrupt routing
[snip]
> PCI: Using ACPI for IRQ routing
> ** PCI interrupts are no longer routed automatically.  If this
> ** causes a device to stop working, it is probably because the
> ** driver failed to call pci_enable_device().  As a temporary
> ** workaround, the "pci=routeirq" argument restores the old
> ** behavior.  If this argument makes the device work again,
> ** please email the output of "lspci" to [EMAIL PROTECTED]
> ** so I can fix the driver.
[snip]
Have you tried the suggestion given "... As a temporary workaround,
the "pci=routeirq" argument..." ?
You could also try the pci=noacpi boot option to see if that changes anything.

Also, that's a fairly old kernel you have there, could you try
2.6.13-rc3, 2.6.13-rc3-git6 or 2.6.13-rc3-mm1 ?

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IRQ routing problem in 2.6.10-rc2

[Pierre Ossman]

Pierre Ossman wrote:
> ** PCI interrupts are no longer routed automatically.  If this
> ** causes a device to stop working, it is probably because the
> ** driver failed to call pci_enable_device().  As a temporary
> ** workaround, the "pci=routeirq" argument restores the old
> ** behavior.  If this argument makes the device work again,
> ** please email the output of "lspci" to [EMAIL PROTECTED]
> ** so I can fix the driver.

If I had just bothered to diff the dmesg:es properly I would have found
the problem... Sorry for the noice.

Bjorn, the 3c59x driver breaks on this system, but only in one specific
slot. lspci -vv included.

(The problem is still present on 2.6.12 so I haven't just tried 2.6.10.)

Rgds
Pierre
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 
03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 

00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- Reset- FastB2B+

00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- 
SERR- TAbort- 
SERR- 

Re: kernel debugging

[Jesper Juhl]

On 7/24/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 7/24/05, UmaMaheswari Devi <[EMAIL PROTECTED]> wrote:
> > I am new to kernel hacking and am facing problems in trying to peek at the
> > runtime values of some kernel variables using gdb.
> >
> > I am issuing the gdb command as follows:
> >  gdb vmlinux /proc/kcore
> > This displays the message
> > /proc/kcore: Operation not permitted
> > before the (gdb) prompt is displayed.
> > gdb then prints a value of 0 for any valid variable that is requested.
> >
> > vmlinux appears to be OK, as gdb correctly identifies undefined variables.
> > The problem seems to be with /proc/kcore. This file has a permission of 
> > 400. I
> > am using the Red Hat distribution.
> >
> > Any help is appreciated.
> >
> If you want to use gdb to debug the kernel you should probably
> investigate UML (User Mode Linux). Take a look at this link :
> http://user-mode-linux.sourceforge.net/debugging.html
> 
> Alternatives include kgdb - http://kgdb.sourceforge.net/
> and kdb - http://oss.sgi.com/projects/kdb/
> 
> You can also find many documents on Linux Kernel debugging aids and
> techniques via google.
> 
Ohh, and do search the LKML archives, kernel debuggers have been
discussed endlessly over the years on the list, so you should be able
to find many threads covering that.

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel debugging

[Jesper Juhl]

On 7/24/05, UmaMaheswari Devi <[EMAIL PROTECTED]> wrote:
> I am new to kernel hacking and am facing problems in trying to peek at the
> runtime values of some kernel variables using gdb.
> 
> I am issuing the gdb command as follows:
>  gdb vmlinux /proc/kcore
> This displays the message
> /proc/kcore: Operation not permitted
> before the (gdb) prompt is displayed.
> gdb then prints a value of 0 for any valid variable that is requested.
> 
> vmlinux appears to be OK, as gdb correctly identifies undefined variables.
> The problem seems to be with /proc/kcore. This file has a permission of 400. I
> am using the Red Hat distribution.
> 
> Any help is appreciated.
> 
If you want to use gdb to debug the kernel you should probably
investigate UML (User Mode Linux). Take a look at this link :
http://user-mode-linux.sourceforge.net/debugging.html

Alternatives include kgdb - http://kgdb.sourceforge.net/ 
and kdb - http://oss.sgi.com/projects/kdb/

You can also find many documents on Linux Kernel debugging aids and
techniques via google.

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][V4L] fix tuning with MXB driver

[Michael Hunold]

Hello Linus, Andrew,

I noticed that some past changes to the gerneric Video4Linux tuner
module for analog tuners broke my "Multimedia eXtension Board" driver.

The tuner driver was made aware of Video4Linux2 tuning ioctls, but my
driver was not ported and still uses the Video4Linux1 ioctls. This does
not work anymore as intendend, the tuning is currently broken.

The attached patch fixes non-working tuning in MXB driver introduced by
some recent generic tuner changes by replacing Video4Linux1 tuner ioctls
with proper Video4Linux2 tuner ioctls.

Please apply.

Thanks!
Michael.

- fix non-working tuning in MXB driver introduced by some recent generic tuner changes
by replacing Video4Linux1 tuner ioctls with proper Video4Linux2 tuner ioctls

Signed-off-by: Michael Hunold <[EMAIL PROTECTED]>

diff -ura xx-linux-2.6.12.1/drivers/media/video/mxb.c linux-2.6.12.1/drivers/media/video/mxb.c
--- xx-linux-2.6.12.1/drivers/media/video/mxb.c	2005-07-24 13:00:17.0 +0200
+++ linux-2.6.12.1/drivers/media/video/mxb.c	2005-07-24 13:08:02.0 +0200
@@ -142,8 +142,8 @@
 
 	int	cur_mode;	/* current audio mode (mono, stereo, ...) */
 	int	cur_input;	/* current input */
-	int	cur_freq;	/* current frequency the tuner is tuned to */
 	int	cur_mute;	/* current mute status */
+	struct v4l2_frequency	cur_freq;	/* current frequency the tuner is tuned to */
 };
 
 static struct saa7146_extension extension;
@@ -349,8 +349,13 @@
 	mxb->saa7111a->driver->command(mxb->saa7111a,DECODER_SET_VBI_BYPASS, );
 
 	/* select a tuner type */
-	i = 5; 
+	i = TUNER_PHILIPS_PAL; 
 	mxb->tuner->driver->command(mxb->tuner,TUNER_SET_TYPE, );
+	/* tune in some frequency on tuner */
+	mxb->cur_freq.tuner = 0;
+	mxb->cur_freq.type = V4L2_TUNER_ANALOG_TV;
+	mxb->cur_freq.frequency = freq;
+	mxb->tuner->driver->command(mxb->tuner, VIDIOC_S_FREQUENCY, >cur_freq);
 	
 	/* mute audio on tea6420s */
 	mxb->tea6420_1->driver->command(mxb->tea6420_1,TEA6420_SWITCH, _line[6][0]);
@@ -368,12 +373,8 @@
 	vm.out = 13;
 	mxb->tea6415c->driver->command(mxb->tea6415c,TEA6415C_SWITCH, );
 
-	/* tune in some frequency on tuner */
-	mxb->tuner->driver->command(mxb->tuner, VIDIOCSFREQ, );
-
 	/* the rest for mxb */
 	mxb->cur_input = 0;
-	mxb->cur_freq = freq;
 	mxb->cur_mute = 1;
 
 	mxb->cur_mode = V4L2_TUNER_MODE_STEREO;
@@ -816,18 +817,14 @@
 			return -EINVAL;
 		}
 
-		memset(f,0,sizeof(*f));
-		f->type = V4L2_TUNER_ANALOG_TV;
-		f->frequency =  mxb->cur_freq;
+		*f = mxb->cur_freq;
 
-		DEB_EE(("VIDIOC_G_FREQ: freq:0x%08x.\n", mxb->cur_freq));
+		DEB_EE(("VIDIOC_G_FREQ: freq:0x%08x.\n", mxb->cur_freq.frequency));
 		return 0;
 	}
 	case VIDIOC_S_FREQUENCY:
 	{
 		struct v4l2_frequency *f = arg;
-		int t_locked = 0;
-		int v_byte = 0;
 
 		if (0 != f->tuner)
 			return -EINVAL;
@@ -840,20 +837,11 @@
 			return -EINVAL;
 		}
 
-		DEB_EE(("VIDIOC_S_FREQUENCY: freq:0x%08x.\n",f->frequency));
-
-		mxb->cur_freq = f->frequency;
+		mxb->cur_freq = *f;
+		DEB_EE(("VIDIOC_S_FREQUENCY: freq:0x%08x.\n", mxb->cur_freq.frequency));
 
 		/* tune in desired frequency */			
-		mxb->tuner->driver->command(mxb->tuner, VIDIOCSFREQ, >cur_freq);
-
-		/* check if pll of tuner & saa7111a is locked */
-//		mxb->tuner->driver->command(mxb->tuner,TUNER_IS_LOCKED, _locked);
-		mxb->saa7111a->driver->command(mxb->saa7111a,DECODER_GET_STATUS, _byte);
-
-		/* not locked -- anything to do here ? */
-		if( 0 == t_locked || 0 == (v_byte & DECODER_STATUS_GOOD)) {
-		}
+		mxb->tuner->driver->command(mxb->tuner, VIDIOC_S_FREQUENCY, >cur_freq);
 
 		/* hack: changing the frequency should invalidate the vbi-counter (=> alevt) */
 		spin_lock(>slock);

Re: [PATCH] Filesystem capabilities support

[Arnout Engelen]

Nicholas Hans Simmonds wrote:
> This is a simple attempt at providing capability support

Very good to see progress in this field. I'm not familiar with the 
technical details yet, but this seems an important security feature imho.

How does this patch relate to the one at
http://www.olafdietsche.de/linux/capability ?

I do think the LD_PRELOAD / LD_LIBRARY_PATH problem (also described by
Olaf) should be mentioned in the kernel config, and fs capabilities should 
remain marked EXPERIMENTAL until that's resolved.


Kind regards,

-- 
Arnout Engelen <[EMAIL PROTECTED]>

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

IRQ routing problem in 2.6.10-rc2

[Pierre Ossman]

Sorry about reporting this error so late but the machine in question had
gone some time without upgrades.

The problem I'm seeing is that IRQs stop working for one of the IRQ
slots on the machine. It's only that slot, not the entire IRQ, since the
two slots (it's a small machine) both get routed to IRQ 10.

I've included dmesg from 2.6.10-rc1 (which works) and 2.6.10-rc2 (which
doesn't).

I've also tried reverting the patches that modifies
arch/i386/kernel/irq.c and arch/i386/pci/irq.c but it didn't solve the
problem. So now I need some more input on which patches to try.

Rgds
Pierre
Linux version 2.6.10-rc1 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 (Red 
Hat Linux 3.3.3-7)) #3 Sun Jul 17 03:03:28 CEST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 000a (usable)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 0fffe000 (usable)
 BIOS-e820: 0fffe000 - 1000 (reserved)
 BIOS-e820: ffe0 - 0001 (reserved)
0MB HIGHMEM available.
255MB LOWMEM available.
On node 0 totalpages: 65534
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 61438 pages, LIFO batch:14
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.2 present.
ACPI: RSDP (v000 DELL  ) @ 0x000fdf50
ACPI: RSDT (v001 DELLGX1 0x0002 ASL  0x0061) @ 0x000fdf64
ACPI: FADT (v001 DELLGX1 0x0002 ASL  0x0061) @ 0x000fdf8c
ACPI: DSDT (v001   DELLdt_ex 0x1000 MSFT 0x010b) @ 0x
ACPI: PM-Timer IO Port: 0x808
Built 1 zonelists
Kernel command line: ro root=/dev/hda3 rhgb acpi=force
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 598.602 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 255268k/262136k available (2408k kernel code, 6204k reserved, 620k 
data, 160k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 1187.84 BogoMIPS (lpj=593920)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0383f9ff   
CPU: After vendor identify, caps:  0383f9ff   
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU: After all inits, caps:0383f9ff   0040
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium III (Katmai) stepping 03
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: IRQ9 SCI: Edge set to Level Trigger.
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 202k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfcaee, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040816
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 *10 11 12 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11 12 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11 12 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
ACPI: PCI interrupt :00:07.2[D] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
ACPI: PCI interrupt :00:0d.0[A] -> GSI 10 (level, low) -> IRQ 10
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI interrupt :00:0e.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI interrupt :00:11.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
ACPI: PCI interrupt :01:00.0[A] -> GSI 10 (level, low) -> IRQ 10
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
apm: overridden by ACPI.
audit: initializing netlink socket (disabled)
audit(1121904612.812:0): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
SELinux:  Registering netfilter hooks
Initializing Cryptographic API
Limiting direct PCI/PCI transfers.
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
vesafb: probe of vesafb0 failed with error -6
ACPI: Processor [CPU0] 

ext2: buffer_head usage with and without O_DIRECT

[li nux]

This is with respect to 2.4.28 on
http://lxr.linux.no/source/?v=2.4.18 

When i do read/write on ext2 without opening files
with O_DIRECT, i can see buffer_head constantly
increasing in /proc/slabinfo.

But when I open files with O_DIRECT, the i/o is done
without using buffer_head, /proc/slabinfo shows this
as constant throughout the i/o.
There is no other i/o activity on the box.

Stacks below show that both of them creates
buffer_head's. Any idea why this is happening ?

As per the code, Without O_DIRECT, stack is:
(See fs/buffer.c)
submit_bh_rsector
submit_bh
block_read_full_page (This calls create_buffers to
create buffer_head's)
ext2_readpage
do_generic_file_read
generic_file_new_read
generic_file_read

With O_DIRECT:
brw_kiovec (This creates buffer_head's)
generic_direct_sector_IO (cals
prepare_direct_IO_iobuf)
ext2_direct_IO
generic_file_direct_IO 
generic_file_new_read
generic_file_read

-Thanks.




Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc3 test: finding compile errors with make randconfig

[Jesper Juhl]

On 7/24/05, Grant Coady <[EMAIL PROTECTED]> wrote:
> Greetings,
> 
> Few days ago I compiled 241 random configurations of 2.6.13-rc3, today
> I finally got around to parsing the results, top 40, sorted by name.
> Percentage is error_builds / total_builds.
> 
> build script similar to:
> count=0
> while [ $((++count)) -le $limit ]; do
> trial=$(printf %003d $count)
> make randconfig
> cp .config "$store/$trial-config"
> make clean
> make -j2 2> "$store/$trial-error"
> done
> 
> Curious whether this is worth doing, I'm about to start a run for 2.6.12.3,
> any interesting errors I can find the particular config + error to recover
> context.  Deliberately simplistic for traceability at the moment, truncated
> error length for this post.
> 
If you could put the data online somewhere I'd be interrested in
taking a look at it.
An easy way to look at the build log and grab the matching .config for
any given run would be great.

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

[Bill Davidsen]

Jesper Juhl wrote:


On 7/24/05, randy_dunlap <[EMAIL PROTECTED]> wrote:
 


On Fri, 15 Jul 2005 05:46:44 +0200 Jesper Juhl wrote:

   


+static int __init jiffies_increment_setup(char *str)
+{
+ printk(KERN_NOTICE "setting up jiffies_increment : ");
+ if (str) {
+ printk("kernel_hz = %s, ", str);
+ } else {
+ printk("kernel_hz is unset, ");
+ }
+ if (!strncmp("100", str, 3)) {
 


BTW, if someone enters "kernel_hz=1000", this check (above) for "100"
matches (detects) 100, not 1000.

   


ouch. You are right - thanks. I'll be sure to fix that.
I haven't had time to look more at this little thing for the last few
days, but I'll get back to it soon. Thank you for the feedback.

 

I have to admit that I like paranoid programming, and would rather see 
this look for "kernel_hz=" then convert the digits after to an integer 
and validate that. It would catch invalid values far better, allow other 
values to be either implemented as best as is possible if desired, and 
NOT ignore invalid values if they didn't match these predefined strings.


--
bill davidsen <[EMAIL PROTECTED]>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

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

Re: [PATCH 2.6.13-rc3] pcmcia: pcmcia_request_irq for !IRQ_HANDLE_PRESENT

[Russell King]

On Sat, Jul 23, 2005 at 10:11:13PM +0200, Dominik Brodowski wrote:
> Thanks for the excellent debugging. Your patch seems to work, however it
> might be better to do just this:

This can be racy if two drivers are simultaneously trying to request an
IRQ.  'data' must be unique to different threads if they are to avoid
interfering with each other.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: HELP: NFS mount hangs when attempting to copy file

[Michael Clark]

Timothy Miller wrote:

>On 7/23/05, Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
>  
>
>>I beg to disagree. A lot of these VPN solutions are unfriendly to MTU
>>path discovery over UDP. Sun uses TCP by default when mounting NFS
>>partitions. Have you tried this on your Linux box?
>>
>>
>
>I changed the protocol to TCP and changed rsize and wsize to 1024.  I
>don't know which of those fixed it, but I'm going to leave it for now.
>
>As for MTU, yeah, the Watchguard box seems to have some hard-coded
>limits, and for whatever reason KDE and GNOME graphical logins do
>something that exceeds those limits, completely independent of NFS,
>and hang up hard.
>  
>

If possible it would also be good to fix the misconfigured VPN box
that's breaking the PMTU discovery if you can (usually it's too
aggressive blocking of ICMP messages). Although a wsize/rzise of 1024
and using TCP probably makes sense for NFS over a VPN (avoid
framentation overhead and let TCP handle the retransmission).

My guess is the Watchguard is blocking ICMP "fragmentation needed"
messages (which is resulting in the PMTU discovery breakage).

Enabling ICMP "fragmentation needed" messages to pass through the VPNs
firewall if you can should fix your other problems aswell.

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

Re: [shorty: Re: 2.6.12 debian powerpc kernels and ppc64 ...]

[Sven Luther]

On Mon, Jul 18, 2005 at 10:39:05PM +0200, Wolfgang Pfeiffer wrote:
> The first try to send the message below didn't work. Hoping it does
> now ... :)
> 
> Regards
> Wolfgang
> 
> - Forwarded message from Wolfgang Pfeiifer -
> 
> To: Sven Luther <[EMAIL PROTECTED]>
> Cc: debian-powerpc@lists.debian.org, debian-kernel@lists.debian.org,
>   linux-kernel@vger.kernel.org
> Subject: Re: 2.6.12 debian powerpc kernels and ppc64 ...
> Date: Mon, 18 Jul 2005 22:17:37 +0200
> User-Agent: Mutt/1.5.9i
> X-URL: http://www.wolfgangpfeiffer.com
> 
> On Mon, Jul 18, 2005 at 07:23:05AM +0200, Sven Luther wrote:
> > On Sun, Jul 17, 2005 at 07:52:30PM +0200, Wolfgang Pfeiffer wrote:
> > > Hi Sven
> > > 
> > > On Fri, Jul 15, 2005 at 11:04:17PM +0200, Sven Luther wrote:
> > > > Hello,
> > > > 
> > > > I would like testers who want to test new powerpc kernels on ppc64 
> > > > machines :
> > > > 
> > > > These i have uploaded here :
> > > > 
> > > >   
> > > > http://people.debian.org/~luther/ppc64/kernel-image-2.6.12-sven_1_powerpc.deb
> > > 
> > > At least the latter one works here. Or at least it boots here without any 
> > > probs,
> > > as it seems .. :
> > > 
> > > $ uname -a
> > > Linux debby 2.6.12-sven #1 Fri Jul 15 13:44:26 UTC 2005 ppc GNU/Linux
> > > 
> > > $ cat /proc/cpuinfo 
> > > processor   : 0
> > > cpu : 7455, altivec supported
> > > clock   : 867MHz
> > > revision: 0.2 (pvr 8001 0302)
> > > bogomips: 865.18
> > > machine : PowerBook3,5
> > > motherboard : PowerBook3,5 MacRISC2 MacRISC Power Macintosh
> > > detected as : 80 (PowerBook Titanium IV)
> > > pmac flags  : 001b
> > > L2 cache: 256K unified
> > > memory  : 768MB
> > > pmac-generation : NewWorld
> > 
> > As was expectet, the 64bit is the one i am not sure about.
> > 
> > > But how come this kernel still does not have the necessary patches
> > > applied to run kismet: 
> > 
> > Please provide a bug report with this info, 
> 
> No. Please see:
> http://lkml.org/lkml/2004/8/27/303
> 
> As you can see I sent them a bug report once. It won't happen again in
> the foreseeable future.

Send a bug report to the debian kernel package i meant, not upstream, altough
ther policy is to follow upstream on this, there may be exceptions.

The debian kernel maintainer is a team, not just me, and sending personal mail
and nort an archived bug report, is bound to get lost in my (huge) inbox,
especially now that i am mostly offline 2 weeks.

> that page nobody seemed to be interested in the problem. IIRC I could
> not compile for weeks or perhaps even months a new 2.4 kernel version
> because of the mentioned errors.

2.4 is dead on desktop powerpc for over a year and a half now, so ...

> > i will apply as soon as i am back
> > in 2 weeks, if someone from the kernel team doesn't beat me to it.
> 
> The site for the patch I used, IIRC:
> 
> 
> wget http://www.kismetwireless.net/code/orinoco-2.6.12-rfmon-dragorn-1.diff
> 
> The md5sum for the latter that I have here is 
> 41fb7cec09f4de93cd2432eb1aceba92
> 
> So if yours will be different you can let me know.

Nice , but please apply this info to a debian bug report (reportbug kernel on
a running debian system).

> 
> And I applied the patch to 2.6.12. Or better: I probably patched a
> 2.6.11 (tarball) source with patch-2.6.12.bz2, and then applied the
> above orinoco patch. (Uncertainty because it's already a few weeks ago
> I compiled this kernel ... ) 
> 
> And just in case it might help someone else:
> The following snippet might serve as an example of how to compile this
> more or less wifi ready patched source [Please check for yourself in
> case I made any mistakes ... :) ... ]:
> 
> 
> tar xzvf linux-2.6.11.tar.gz
> cd linux-2.6.11/
> bzip2 -cd  /path/to/patch-2.6.12.bz2 | patch -p1
> 
> [then applying the orinoco patch from above]
> 
> cp /boot/someconfig .
> make oldconfig
> fakeroot make-kpkg clean
> 
> time MAKEFLAGS="CC=gcc-4.0"  fakeroot make-kpkg --append-to-version=-somename 
> --revision +anothername kernel_image
> 
> or
> 
>  time MAKEFLAGS="CC=gcc-4.0"  fakeroot make-kpkg 
> --append-to-version=+orinoco-patched --revision +050703 kernel_image
> 
> 
> HTH
> 
> Thanks for responding, Sven ... and yes: for your work, too :)
> 
> And sorry for refusing to play nice if things run ugly ..

Well, just provide a debian bug report so we can continue having this
conversation the right way.

TW, is this a different patch than the one Jens had applied back them in the
2.6.4 debian powerpc kenrel days ? And which was removed for bugginess or
something ?

Friendly,

Sven Luther

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] autofs4 - fix infamous "Busy inodes after umount ..." message.

[Andreas Gruenbacher]

Hi Ian,

On Sunday 24 July 2005 04:12, Ian Kent wrote:
> If the automount daemon receives a signal which causes it to sumarily
> terminate the autofs4 module leaks dentries. The same problem exists with
> detached mount requests without the warning.
>
> This patch cleans these dentries at umount.

thanks for working on this. For credits, SGI reported this bug, helped with 
debugging, and verified the fix.

Cheers,
-- 
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX PRODUCTS GMBH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [1/5+1] menu -> menuconfig part 1

[Bodo Eggert]

On Thu, 21 Jul 2005, randy_dunlap wrote:
> On Sun, 17 Jul 2005 13:29:03 +0200 (CEST) Bodo Eggert wrote:

> > > These patches change some menus into menuconfig options.

> When using xconfig (not menuconfig), the drivers/MTD menu
> needs some help IMO, but it's not clear where/why.
> 
> Before the patch, there was only "Memory Technology
> Devices (MTD)" in the left xconfig panel.  After the patch,
> under that heading there are 4 other MTD entries,
> which are in the right-side panel before the patch and should
> remain there.  These are:
> 
>   RAM/ROM/Flash chip drivers
>   Mapping drivers for chip access
>   Self-contained MTD device drivers
>   NAND Flash Device support

That's because of the xconfig way of handling menus. Off cause this should 
not happen, but I'll need something like a submenuconfig option to 
resolve that issue. It would need to be like a menu in menuconfig, and 
like a config in xconfig.


BTW: Thanks for testing.
-- 
Top 100 things you don't want the sysadmin to say:
83. Damn, and I just bought that pop...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] sound drivers select'ing ISAPNP must depend on PNP && ISA

[Bodo Eggert]

On Sat, 23 Jul 2005, Adrian Bunk wrote:
> On Tue, Jul 19, 2005 at 10:50:53PM +0200, Bodo Eggert wrote:

> > OTOH, the build system
> > should automatically propagate the dependencies. I asume that should be
> > easy, except for having the time to implement that.
> >...
> 
> There are nontrivial problems:
> E.g. what should happen if you select option A that depends on (B || C)?

You should in effect depend on ($original_depends) && (B || C). You'll 
just need to append all (recursive) dependencies in the selecting option.


last_length:=-1; /* impossible value */
while |options_with_unresolved_selects| > 0 do begin
if |options_with_unresolved_selects| == last_length
then goto circular_recursion_detected;
last_length:=|options_with_unresolved_selects|;

for i in options_with_unresolved_selects do begin
for s in i->unresolved_selects do
if 0 == |s->unresolved_selects|
then begin
add(i->depends, s->depends)
delete_from(i->unresolved_selects, s)
end
if 0 == |i->unresolved_selects|
then delete_from(options_with_unresolved_selects, i);
end
end

> There's one opinion that options should be either select'able _or_ user 
> visible.

That would only result in ugly workarounds. Think about the kernel 
libraries. You'll want to manually select them, and you'll want to 
automatically select them, and you want both to be visible.

-- 
Funny quotes:
22. When everything's going your way, you're in the wrong lane and and going
the wrong 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/