date:20070505

Hi,

thanks for finding bugs in this patch. Although this path will likely
never happen, this is good to have it bug-free.

On Sat, 2007-05-05 at 09:25 +0530, Satyam Sharma wrote:
> Artem would have to step in here to verify if there really is a good
> reason why we kmalloc a fresh ubi_scan_leb every time we want to add
> one to a list. 
Particularly in vtbl.c there is no good reason. Leftover of itsy-bitsy
units. I'll make ubi_scan_add_to_list static, as well as
ubi_scan_add_used(). And I'll rename them to something shorter. They are
only useful in scan.c.

And it is fine to use list_add_tail() directly in vtbl.c. Will be fixed.

> If possible, the best solution would be to change
> ubi_scan_add_to_list() to take in a valid struct ubi_scan_leb and just
> add that to the specified list (using list_add_tail or whatever) --
> and leave allocation up to callers, 
In scan.c it is useful because _all_ callers have to allocate it. vtbl.c
is the only place which does not need it. I'll fix this.

> >though this likely requires a
> major cleanup of this driver w.r.t. ubi_scan_leb lifetime semantics.
What is wrong with the semantics, please be more specific.

I'll fix this shortly.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] CFS scheduler, -v8

2007-05-05 Thread Esben Nielsen




On Wed, 2 May 2007, Ingo Molnar wrote:



* Balbir Singh <[EMAIL PROTECTED]> wrote:


The problem is with comparing a s64 values with (s64)ULONG_MAX, which
evaluates to -1. Then we check if exec_delta64 and fair_delta64 are
greater than (s64)ULONG_MAX (-1), if so we assign (s64)ULONG_MAX to
the respective values.


ah, indeed ...


The fix is to compare these values against (s64)LONG_MAX and assign
(s64)LONG_MAX to exec_delta64 and fair_delta64 if they are greater
than (s64)LONG_MAX.

Tested on PowerPC, the regression is gone, tasks are load balanced as
they were in v7.


thanks, applied!

Ingo


I have been wondering why you use usigned for timers anyway. It is also 
like that in hrtimers. Why not use signed and avoid (almost) all worries 
about wrap around issues. The trick is that when all

  a < b
is be replaced by
  a - b < 0
the code will work on all 2-complement machines even if the (signed!) 
integers a and b wrap around.


In both the hrtimer and CFS patch 32 bit timers could be used internally 
on 32 bit architectures to avoid expensive 64 bit integer calculations.
The only thing is: timeouts can not be bigger than 2^31 in the chosen 
units.


I have successfully coded a (much more primitive) hrtimer system for 
another OS on both ARM and PPC using the above trick in my former job. 
On both I used the machine's internal clock as the internal 
representation of time and I only scaled to a struct timespec in the user 
interface.


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

Re: swap-prefetch: 2.6.22 -mm merge plans

2007-05-05 Thread Con Kolivas

On Friday 04 May 2007 22:10, Con Kolivas wrote:
> On Friday 04 May 2007 18:52, Ingo Molnar wrote:
> > agreed. Con, IIRC you wrote a testcase for this, right? Could you please
> > send us the results of that testing?
>
> Yes, sorry it's a crappy test app but works on 32bit. Timed with prefetch
> disabled and then enabled swap prefetch saves ~5 seconds on average
> hardware on this one test case. I had many users try this and the results
> were between 2 and 10 seconds, but always showed a saving on this testcase.
> This effect easily occurs on printing a big picture, editing a large file,
> compressing an iso image or whatever in real world workloads. Smaller, but
> much more frequent effects of this over the course of a day obviously also
> occur and do add up.

Here's a better swap prefetch tester. Instructions in file.

Machine with 2GB ram and 2GB swapfile

Prefetch disabled:
./sp_tester
Ram 2060352000  Swap 197342
Total ram to be malloced: 3047062000 bytes
Starting first malloc of 1523531000 bytes
Starting 1st read of first malloc
Touching this much ram takes 809 milliseconds
Starting second malloc of 1523531000 bytes
Completed second malloc and free
Sleeping for 600 seconds
Important part - starting reread of first malloc
Completed read of first malloc
Timed portion 53397 milliseconds

Enabled:
./sp_tester
Ram 2060352000  Swap 197342
Total ram to be malloced: 3047062000 bytes
Starting first malloc of 1523531000 bytes
Starting 1st read of first malloc
Touching this much ram takes 676 milliseconds
Starting second malloc of 1523531000 bytes
Completed second malloc and free
Sleeping for 600 seconds
Important part - starting reread of first malloc
Completed read of first malloc
Timed portion 26351 milliseconds

Note huge time difference.

-- 
-ck
/*
sp_tester.c

Build with:
gcc -o sp_tester sp_tester.c -lrt -W -Wall -O2

How to use:
echo 1 > /proc/sys/vm/overcommit_memory
swapoff -a
swapon -a
./sp_tester

then repeat with changed conditions eg
echo 0 > /proc/sys/vm/swap_prefetch

Each Test takes 10 minutes
*/

#include 
#include 
#include 
#include 
#include 
#include 
#include 

void fatal(const char *format, ...)
{
	va_list ap;

	if (format) {
		va_start(ap, format);
		vfprintf(stderr, format, ap);
		va_end(ap);
	}

	fprintf(stderr, "Fatal error - exiting\n");
	exit(1);
}

unsigned long ramsize, swapsize;

size_t get_ram(void)
{
	FILE *meminfo;
char aux[256];

	if(!(meminfo = fopen("/proc/meminfo", "r")))
		fatal("fopen\n");

	while( !feof(meminfo) && !fscanf(meminfo, "MemTotal: %lu kB", &ramsize) )
		fgets(aux,sizeof(aux),meminfo);
	while( !feof(meminfo) && !fscanf(meminfo, "SwapTotal: %lu kB", &swapsize) )
		fgets(aux,sizeof(aux),meminfo);
	if (fclose(meminfo) == -1)
		fatal("fclose");
	ramsize *= 1000;
	swapsize *= 1000;
	printf("Ram %lu  Swap %lu\n", ramsize, swapsize);
	return ramsize + (swapsize / 2);
}

unsigned long get_usecs(struct timespec *myts)
{
	if (clock_gettime(CLOCK_REALTIME, myts))
		fatal("clock_gettime");
	return (myts->tv_sec * 100 + myts->tv_nsec / 1000 );
}

int main(void)
{
	unsigned long current_time, time_diff;
	struct timespec myts;
	char *buf1, *buf2, *buf3, *buf4;
	size_t size = get_ram();
	int sleep_seconds = 600;

	if (size > ramsize / 2 * 3)
		size = ramsize / 2 * 3;
	printf("Total ram to be malloced: %u bytes\n", size);
	size /= 2;
	printf("Starting first malloc of %u bytes\n", size);
	buf1 = malloc(size);
	buf4 = malloc(1);
	if (buf1 == (char *)-1)
		fatal("Failed to malloc 1st buffer\n");
	memset(buf1, 0, size);
	time_diff = current_time = get_usecs(&myts);
	for (buf3 = buf1; buf3 < buf1 + size; buf3++)
		*buf4 = *buf3;
	printf("Starting 1st read of first malloc\n");
	current_time = get_usecs(&myts);
	time_diff = current_time - time_diff;
	printf("Touching this much ram takes %lu milliseconds\n",time_diff / 1000);
	printf("Starting second malloc of %u bytes\n", size);

	buf2 = malloc(size);
	if (buf2 == (char *)-1)
		fatal("Failed to malloc 2nd buffer\n");
	memset(buf2, 0, size);
	for (buf3 = buf2 + size; buf3 > buf2; buf3--)
		*buf4 = *buf3;
	free(buf2);
	printf("Completed second malloc and free\n");

	printf("Sleeping for %u seconds\n", sleep_seconds);
	sleep(sleep_seconds);

	printf("Important part - starting reread of first malloc\n");
	time_diff = current_time = get_usecs(&myts);
	for (buf3 = buf1; buf3 < buf1 + size; buf3++)
		*buf4 = *buf3;
	current_time = get_usecs(&myts);
	time_diff = current_time - time_diff;
	printf("Completed read of first malloc\n");
	printf("Timed portion %lu milliseconds\n",time_diff / 1000);

	free(buf1);
	free(buf4);

	return 0;
}

Re: [RFC/PATCH] ext3: remove inode constructor

On Fri, 4 May 2007, Andrew Morton wrote:
> I got 100% rejects against this because Christoph has already had
> his paws all over the slab constructor code everywhere.
> 
> Was going to fix it up but then decided that we ought to make changes
> like this to ext4 as well.  Ideally beforehand, but simultaneously is
> OK as long as it's simple enough.

I'll send you proper patches for them (and will convert other filesystems 
too).

On Fri, 4 May 2007, Andrew Morton wrote:
> btw, for a benchmark I'd suggest just a silly create-1-files
> tight loop rather than something more complex like postmark.

Do you want me to redo the benchmarks or are you happy enough with the 
postmark numbers?

Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 08/40] mm: kmem_cache_objsize

On Fri, 4 May 2007, Christoph Lameter wrote:
> He is not able to calculate it just using the object size since he does 
> not know where the slab put the slab management structure. And in case of 
> SLUB there is no slab management structure... Which means he would have to 
> special case based on the slab allocator selected.

Let me state this once more: he is interested in _rough approximation_. It 
makes no sense to me to add this kind of fuzzy logic in the slab. Now, as 
the slab clearly cannot give a _precise number_ either, it shouldn't be 
added there.

But, if both of you really want to stick it in mm/slab.c, I guess I won't 
be too violently opposed to it. It just doesn't make any sense to me.

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

Re: [RFC/PATCH] ext3: remove inode constructor

2007-05-05 Thread Andrew Morton

On Sat, 5 May 2007 11:58:45 +0300 (EEST) Pekka J Enberg <[EMAIL PROTECTED]> 
wrote:

> On Fri, 4 May 2007, Andrew Morton wrote:
> > I got 100% rejects against this because Christoph has already had
> > his paws all over the slab constructor code everywhere.
> > 
> > Was going to fix it up but then decided that we ought to make changes
> > like this to ext4 as well.  Ideally beforehand, but simultaneously is
> > OK as long as it's simple enough.
> 
> I'll send you proper patches for them (and will convert other filesystems 
> too).

May as well.

> On Fri, 4 May 2007, Andrew Morton wrote:
> > btw, for a benchmark I'd suggest just a silly create-1-files
> > tight loop rather than something more complex like postmark.
> 
> Do you want me to redo the benchmarks or are you happy enough with the 
> postmark numbers?

I doubt if this is measurable, really.  It'll be something like the
difference between an L1 hit and an L2 hit in amongst all the other stuff
we do on a per-inode basis.

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

Re: [RFC/PATCH] ext3: remove inode constructor

On Sat, 5 May 2007, Andrew Morton wrote:
> I doubt if this is measurable, really.  It'll be something like the
> difference between an L1 hit and an L2 hit in amongst all the other stuff
> we do on a per-inode basis.

The cache effects are probably not easily measurable but I was worried 
about CPU time. The slab constructors and destructors were originally 
designed to reduce CPU time spent on initializing objects. But I don't 
think that's relevant anymore on todays CPUs.

Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] tty_set_ldisc receive_room fix

2007-05-05 Thread Alan Cox

> Previously (< 2.6.18) this was not a problem because
> the tty flip buffer pushed data to the line discipline
> without regard for tty->receive room.

 
> Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>

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

Re: [patch 25/29] xen: Add the Xen virtual network device driver.

2007-05-05 Thread Christoph Hellwig

On Fri, May 04, 2007 at 04:21:16PM -0700, Jeremy Fitzhardinge wrote:
> +/*
> + * Mutually-exclusive module options to select receive data path:
> + *  rx_copy : Packets are copied by network backend into local memory
> + *  rx_flip : Page containing packet data is transferred to our ownership
> + * For fully-virtualised guests there is no option - copying must be used.
> + * For paravirtualised guests, flipping is the default.
> + */
> +static enum {
> + RX_COPY = 0,
> + RX_FLIP = 1,
> +} rx_mode = RX_FLIP;
> +MODULE_PARM_DESC(rx_mode, "How to get packets from card: 0->copy, 1->flip");

There only seems to be a module description but no actual paramter for
this.  I wish people would have listened to me back then and made the
description part of the modular_param statement..

> +
> +#define RX_COPY_THRESHOLD 256
> +
> +#define GRANT_INVALID_REF0
> +
> +#define NET_TX_RING_SIZE __RING_SIZE((struct xen_netif_tx_sring *)0, 
> PAGE_SIZE)
> +#define NET_RX_RING_SIZE __RING_SIZE((struct xen_netif_rx_sring *)0, 
> PAGE_SIZE)

__RING_SIZE is not in my tree, so it seems to be some kind of Xen
addition.  Can you make that clear in the name and give it a less
awkware calling convention, e.g. only pass in the type, not a null
pointer of the given type?


> +/*
> + * Implement our own carrier flag: the network stack's version causes delays
> + * when the carrier is re-enabled (in particular, dev_activate() may not
> + * immediately be called, which can cause packet loss).
> + */
> +#define netfront_carrier_on(netif)   ((netif)->carrier = 1)
> +#define netfront_carrier_off(netif)  ((netif)->carrier = 0)
> +#define netfront_carrier_ok(netif)   ((netif)->carrier)

This doesn't implement my review suggestion despite you ACKing
them.  Didn't you like it in the end or did you simply forget
about it?

> +/*
> + * Access macros for acquiring freeing slots in tx_skbs[].
> + */
> +
> +static void add_id_to_freelist(unsigned *head, union skb_entry *list, 
> unsigned short id)


no lines longer than 80 chars 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: Back to the future.

2007-05-05 Thread Pavel Machek

Hi!

> But the same functionality can be achieved by doing:
> 
> 1) Define a user password (e.g. /etc/shadow thing). (Once)
> 
> 2) When a user logs in: get random data and encrypt it with the password,
> this becomes the AES key. Store both the data and key in a secure way in
> memory, e.g. using the existing kernel key infrastructure.



> Advantage of this scheme is that it only need AES and can be done (mostly)
> in kernel space. It's also faster and simpler than the current RSA scheme.
> Disadvantage is that it wastes at least 32 bytes of memory when the system
> is running, to store the data and key.

Another disadvantage is that you need to hack into PAM infrastructure,
that your suspend password needs to be same as someone's login
password, and that it will really only work with single-user machine.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [RFC/PATCH] ext3: remove inode constructor

On Fri, 4 May 2007, Christoph Lameter wrote:
> Also could this be generalized to also apply to the generic inode 
> allocation in fs/inode.c?

I think we want to stick inode_init_ince() in alloc_inode() but we can't 
do that until all filesystems are converted over.

Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] suspend/resume debugging: device filter

2007-05-05 Thread Ingo Molnar


* Greg KH <[EMAIL PROTECTED]> wrote:

> Here's a (compile tested only) patch that does this on a per-device 
> basis, which is smaller, and should work just as well as your patch.
> 
> It creates a new file in the power/ directory for every device called 
> "can_suspend".  Write a '0' to it to prevent that device from being 
> suspended.
> 
> Does this work for you?

yeah, i was able to use this too to debug suspend/resume problems. But 
i've added the check to the resume path too - for example sw-suspend 
does a resume of devices during its suspend cycle, cutting off much of 
the netconsole output.

which makes the can_suspend flag mis-named - perhaps rename it to 
exclude_pm ?

updated patch below, against v2.6.21. Could we get this into v2.6.22 
please? It's a real time-saver.

Ingo

---
 drivers/base/power/resume.c  |6 ++
 drivers/base/power/suspend.c |2 +-
 drivers/base/power/sysfs.c   |   30 ++
 include/linux/device.h   |1 +
 4 files changed, 38 insertions(+), 1 deletion(-)

Index: linux/drivers/base/power/resume.c
===
--- linux.orig/drivers/base/power/resume.c
+++ linux/drivers/base/power/resume.c
@@ -24,6 +24,9 @@ int resume_device(struct device * dev)
 {
int error = 0;
 
+   if (dev->no_suspend)
+   return 0;
+
TRACE_DEVICE(dev);
TRACE_RESUME(0);
down(&dev->sem);
@@ -52,6 +55,9 @@ static int resume_device_early(struct de
 {
int error = 0;
 
+   if (dev->no_suspend)
+   return 0;
+
TRACE_DEVICE(dev);
TRACE_RESUME(0);
if (dev->bus && dev->bus->resume_early) {
Index: linux/drivers/base/power/suspend.c
===
--- linux.orig/drivers/base/power/suspend.c
+++ linux/drivers/base/power/suspend.c
@@ -78,7 +78,7 @@ int suspend_device(struct device * dev, 
suspend_report_result(dev->class->suspend, error);
}
 
-   if (!error && dev->bus && dev->bus->suspend && 
!dev->power.power_state.event) {
+   if (!error && !dev->no_suspend && dev->bus && dev->bus->suspend && 
!dev->power.power_state.event) {
dev_dbg(dev, "%s%s\n",
suspend_verb(state.event),
((state.event == PM_EVENT_SUSPEND)
Index: linux/drivers/base/power/sysfs.c
===
--- linux.orig/drivers/base/power/sysfs.c
+++ linux/drivers/base/power/sysfs.c
@@ -141,12 +141,42 @@ wake_store(struct device * dev, struct d
 
 static DEVICE_ATTR(wakeup, 0644, wake_show, wake_store);
 
+static ssize_t can_suspend_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   return sprintf(buf, "%s\n", dev->no_suspend ? "no" : "yes");
+}
+
+static ssize_t can_suspend_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t n)
+{
+   if (!n)
+   return -EINVAL;
+
+   switch (buf[0]) {
+   case 'y':
+   case 'Y':
+   case '1':
+   dev->no_suspend = 0;
+   break;
+   case 'n':
+   case 'N':
+   case '0':
+   dev->no_suspend = 1;
+   break;
+   }
+
+   return n;
+}
+static DEVICE_ATTR(can_suspend, 0644, can_suspend_show, can_suspend_store);
 
 static struct attribute * power_attrs[] = {
 #ifdef CONFIG_PM_SYSFS_DEPRECATED
&dev_attr_state.attr,
 #endif
&dev_attr_wakeup.attr,
+   &dev_attr_can_suspend.attr,
NULL,
 };
 static struct attribute_group pm_attr_group = {
Index: linux/include/linux/device.h
===
--- linux.orig/include/linux/device.h
+++ linux/include/linux/device.h
@@ -402,6 +402,7 @@ struct device {
charbus_id[BUS_ID_SIZE];/* position on parent bus */
struct device_type  *type;
unsignedis_registered:1;
+   unsignedno_suspend:1;
struct device_attribute uevent_attr;
struct device_attribute *devt_attr;
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Remove constructor from buffer_head

2007-05-05 Thread Andi Kleen

On Fri, May 04, 2007 at 04:45:29PM -0700, Andrew Morton wrote:
> On Sat, 5 May 2007 01:22:05 +0200
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> 
> > > 2.6.21:
> > > 
> > > akpm2:/home/akpm# opreport -l /boot/vmlinux-$(uname -r) | head -50
> > > opreport error: No sample file found: try running opcontrol --dump
> > > or specify a session containing sample files
> > 
> > For me it works on a slightly post 2.6.21 kernel with suse oprofile-0.9.2-21
> > 
> > Did you try opcontrol --dump? 
> 
> Yes, tried various things.  There's just nothing turning up in 
> /var/lib/oprofile.
> 
> Chuck appears to be claiming that 2.6.21 oprofile is known to be broken,
> but I never heard anything about that.

Hmm, after a opcontrol --reset i see the same issue now. Don't know what's 
wrong, but it must be something different from the .20 perfctr allocation
problem.

It looks like the daemon doesn't get any data from the kernel


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

Re: [patch] suspend/resume debugging: device filter

On Saturday, 5 May 2007 11:24, Ingo Molnar wrote:
> 
> * Greg KH <[EMAIL PROTECTED]> wrote:
> 
> > Here's a (compile tested only) patch that does this on a per-device 
> > basis, which is smaller, and should work just as well as your patch.
> > 
> > It creates a new file in the power/ directory for every device called 
> > "can_suspend".  Write a '0' to it to prevent that device from being 
> > suspended.
> > 
> > Does this work for you?
> 
> yeah, i was able to use this too to debug suspend/resume problems. But 
> i've added the check to the resume path too - for example sw-suspend 
> does a resume of devices during its suspend cycle, cutting off much of 
> the netconsole output.
> 
> which makes the can_suspend flag mis-named - perhaps rename it to 
> exclude_pm ?
> 
> updated patch below, against v2.6.21. Could we get this into v2.6.22 
> please? It's a real time-saver.

ACK

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

Re: cpufreq longhaul locks up

2007-05-05 Thread Jan Engelhardt

On May 5 2007 07:40, Rafał Bilski wrote:
>Jan,
>
>Can You send output of x86info program and output of 

Where do I find this?

>lspci command? Longhaul wasn't working for You since 2.6.18 right?

# lspci
00:00.0 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
00:0f.0 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge 
[KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 
AC97 Audio Controller (rev 60)
01:00.0 VGA compatible controller: VIA Technologies, Inc. S3 Unichrome Pro VGA 
Adapter (rev 02)

# dmidecode
Handle 0x, DMI type 0, 20 bytes
BIOS Information
Vendor: Phoenix Technologies, LTD
Version: 6.00 PG
Release Date: 11/30/2005
Address: 0xE
Runtime Size: 128 kB
ROM Size: 512 kB
Characteristics:

>I'm going to work now, but I will be available after 14:00 UTC.

2.6.20.2 (2.6.20.2-ccj45-default, slightly different config
than openSUSE 10.2), no preemption, lockup.

2.6.21 (openSUSE 10.3 Alpha 3 2.6.21-3-default), voluntary
preemption, lockup.

If I shall try more combinations, let me know.

>If You have problem with longhaul+powersave there may be one thing 
>related. When I started to change Longhaul it was causing lockups 
>on Epia 800. I added transition protection. Helped, but not for 
>long. After one or two hours machine locked up anyway. I found 
>datasheet in Google and changed "disable BMDMA bit on PCI device" to 
>northbridge support. Problem fixed. Somehow CLE133 chipset didn't 
>like touching "BMDMA master" bits.
>Second: I didn't get answer from VIA why they are blocking ACPI C3 on CPU's 
>faster then 1GHz. I don't know if it is standard practice and if
>Intel and AMD are doing it too.
>
>Things worth checking: disable PREEMPT, change it to "Voluntary preemption". 
>Check if using conservative governor makes any difference. I know that 
>this may sound strange, but transition latency is directly proportional to 
>difference between current and destination frequency. Maybe for faster 
>processors it isn't allowed to change frequency directly from min to max?

I'll try that .. too.

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

Re: [RFC 2/3] SLUB: Implement targeted reclaim and partial list defragmentation

2007-05-05 Thread Andi Kleen

[EMAIL PROTECTED] writes:
> 
> NOTE: This patch is for conceptual review. I'd appreciate any feedback
> especially on the locking approach taken here. It will be critical to
> resolve the locking issue for this approach to become feasable.

Do you have any numbers on how this improves dcache reclaim under memory 
pressure?

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

Re: [PATCH 00/40] Swap over Networked storage -v12

2007-05-05 Thread Christoph Hellwig

On Fri, May 04, 2007 at 12:27:16PM -0700, David Miller wrote:
> From: Peter Zijlstra <[EMAIL PROTECTED]>
> Date: Fri, 04 May 2007 12:26:51 +0200
> 
> > There is a fundamental deadlock associated with paging;
> 
> I know you'd really like people like myself to review this work, but a
> set of 40 patches is just too much to try and digest at once
> especially when I have other things going on.  When I have lots of
> other things already on my plate, when I see a huge patch set like
> this I have to just say "delete" because I don't kid myself since
> I know I'll never get to it.
> 
> Sorry there's now way I can review this with my current workload.

There also quite alot of only semi-related thing in there.  It would
be much better to only do the network stack and iscsi parts first
and leave nfs out for a while.  Especially as the former are definitively
useful while I strongly doubt that for swap over nfs.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Blacklist Dell Optiplex 320 from using the HPET

2007-05-05 Thread Thomas Gleixner

Guilherme,

On Fri, 2007-05-04 at 16:27 -0700, john stultz wrote: 
> > Before going to hard to maintain DMI black lists we should first check 
> > if it's a more general problem and can't it be solved better? Most likely
> > that system isn't the one with this issue and I don't want to apply
> > DMI patches forever.
> 
> We can give it a whirl, I just didn't want to add yet another "compare
> with some other counter that may or may not work" check. In this case,
> probably reading three times in a row and getting the same result would
> be a clearly broken box. 

can you please undo John's patch and check whether the patch below works
for you.

Thanks,

tglx

Index: linux-2.6.21/arch/i386/kernel/hpet.c
===
--- linux-2.6.21.orig/arch/i386/kernel/hpet.c
+++ linux-2.6.21/arch/i386/kernel/hpet.c
@@ -231,6 +231,7 @@ int __init hpet_enable(void)
 {
unsigned long id;
uint64_t hpet_freq;
+   cycle_t t1;
u64 tmp;
 
if (!is_hpet_capable())
@@ -278,6 +279,14 @@ int __init hpet_enable(void)
/* Start the counter */
hpet_start_counter();
 
+   /* Verify whether hpet counter works */
+   t1 = hpet_read();
+   udelay(50);
+   if (t1 == hpet_read()) {
+   printk(KERN_WARNING "HPET counter is defect\n");
+   goto out_nohpet;
+   }
+
/* Initialize and register HPET clocksource
 *
 * hpet period is in femto seconds per cycle


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Blacklist Dell Optiplex 320 from using the HPET

2007-05-05 Thread Thomas Gleixner

Guilherme,

please discard the previous patch. I missed to refresh it before sending
it out. Correct version below.

tglx

On Sat, 2007-05-05 at 16:26 +0200, Thomas Gleixner wrote:
> can you please undo John's patch and check whether the patch below works
> for you.

Index: linux-2.6.21/arch/i386/kernel/hpet.c
===
--- linux-2.6.21.orig/arch/i386/kernel/hpet.c
+++ linux-2.6.21/arch/i386/kernel/hpet.c
@@ -231,6 +231,7 @@ int __init hpet_enable(void)
 {
unsigned long id;
uint64_t hpet_freq;
+   cycle_t t1;
u64 tmp;
 
if (!is_hpet_capable())
@@ -278,6 +279,14 @@ int __init hpet_enable(void)
/* Start the counter */
hpet_start_counter();
 
+   /* Verify whether hpet counter works */
+   t1 = read_hpet();
+   udelay(50);
+   if (t1 == read_hpet()) {
+   printk(KERN_WARNING "HPET counter is defect\n");
+   goto out_nohpet;
+   }
+
/* Initialize and register HPET clocksource
 *
 * hpet period is in femto seconds per cycle


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] UBI: dereference after kfree in create_vtbl

On 5/5/07, Artem Bityutskiy <[EMAIL PROTECTED]> wrote:

On Sat, 2007-05-05 at 19:18 +0530, Satyam Sharma wrote:
> Well, you're developing / maintaining this right now, so it's your
> call. Though I bet most people would find keeping that list_add_tail
> local to scan.c more tasteful.

I do not think so. If you are interested, try to find "UBI take 2"
patches in lkml. Look how it looked liked. It consisted of many
independent units and units could access other units _only_ via
interfaces. I would do what you say there.

But what you're doing now is *worse*, don't you see it? You _think_
that you are not exporting any add_to_list function from scan.c
because you removed the wrapper from scan.h, but then you open-code it
anyway in create_vtbl (yes, that list_add _is_ the *only* meaningful
code in add_to_list; it just so _happens_ that most of its callers
till now also wanted to allocate a ubi_scan_leb too at that time so
you pushed that too into add_to_list rather than do it in the callers
-- via a separate alloc_leb, for example). Now that means there is an
*undocumented* use of the "add to list" _functionality_ outside of
scan.c anyway and which wouldn't even come up if someone tries to
analyse / overhaul the code some day in the future. I know it's just
_one_ exception, but still, I'm a heckler for style.

Read Teo's comments - I actually now agree with them. And after I had
changed UBI i got rid of several thousands lines of code, and the code
became simpler.

So, my argument is:
1. It makes no sense to introduce one more non-static function to _just_
encapsulate list_add_tail and _just_ for one caller.

Well, introducing one more non-static function is *not* what I
originally had in mind (it was proposed only as a temporary measure
till all users of ubi_scan_add_to_list could be updated to use the
other version, explained below).

I actually planned to _replace_ ubi_scan_add_to_list with another
version that does *not* allocate memory (the __ubi_scan_add_to_list I
proposed above), and leave allocation up to its *callers* who
therefore pass a valid ubi_scan_leb to it. But that is where I ran
into ubi_scan_add_used().

2. It is _C_, it is _kernel_, and it is OK sometimes _not_ to follow
computer since rules.

Ah, well, forget it. It's all a matter of taste and maintainability. I
guess in the end it needs to be fine with you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: parallel port problems with 2.6.21_rc5 and 2.6.21_rc6_git3-20070410174235

2007-05-05 Thread Markus Koßmann

Am Donnerstag, 3. Mai 2007 schrieb Randy Dunlap:
> On Wed, 11 Apr 2007 20:40:23 +0200 Markus Koßmann wrote:
> > When using either the unpatched  2.6.21_rc5   or SUSEs patched
> > 2.6.21_rc6_git3-20070410174235 on a SUSE-10.2 x86_64 system the parallel
> > port doesn't work right. If I "cat some_asciifile >/dev/lp0"  the output
> > on my Epson Stylus Color 880 is unreadable.  "cat /dev/zero >/dev/lp0" 
> > creates random characters on the paper. Printing using cups also doesn't
> > work any more.
> > Switching back to SUSEs  2.6.18.8-0.1 kernel fixes the problem.
> > Any Ideas, what might be broken here ?
>
> Nope, but I have the same problem.
> I'll dig into it some day, but it's not very high priority for me.
>
> I haven't tested it lately.  Do you still see this problem?
>
Yes, it still exists with SUSEs  2.6.21-20070502152652 kernel. Didn't check 
with vanilla 2.6.21 yet. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-discuss] Re: [PATCH 3/8] Universal power supply class (was: battery class)

2007-05-05 Thread pHilipp Zabel


On 5/5/07, Anton Vorontsov <[EMAIL PROTECTED]> wrote:

Hello Henrique, Shem,

On Sat, May 05, 2007 at 12:54:13AM -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 04 May 2007, Shem Multinymous wrote:
> > >+enum power_supply_type {
> > >+   POWER_SUPPLY_TYPE_BATTERY = 0,
> > >+   POWER_SUPPLY_TYPE_UPS,
> > >+   POWER_SUPPLY_TYPE_AC,
> > >+   POWER_SUPPLY_TYPE_USB,
> > >+};
> >
> > How about dumb (non-USB) DC power? Any reason to distinguish it from AC?
>
> Hmm, if it should not be distinguished, it is better to rename AC to
> something that means continuous power.  But I'd rather have it AC and DC, as
> something might have both supplies separate, and you might want to
> differentiate them for some (human interface) reason.  After all, USB and DC
> are not really different anyway...
>
> Anyway, what IS the difference between UPS and battery, or UPS and AC/DC for
> that matter?  When should UPS be used?  If you have UPS there, should not
> MGG (motor-generator group) also be provided?
>
> Given that USB-power *is* usually also "dumb" (i.e. it doesn't do any
> control signaling over the USB bus for power-control purposes), IMHO it
> might be better to have just battery, AC and DC as types.  And a primary and
> secondary notion too, as that is common.  It would be generic.
>
> Or maybe I just didn't get the idea behind the "type" attribute :-)
>
> I'd appreciate if these were documented in the text file.

I think I got the start point of confusion. It's indeed bad to call such
power supply type as AC. Maybe I should it rename to ADAPTER? Or WALL?


or MAINS?


type, is really `type' of power supply: imagine icon GUI application will
use for different types. Type is not alternating/direct current stuff,
it will be better to impelemnt `current_type' attribute for such matter.

As for Battery/UPS difference.. yes, they're quite similar.. but again,
imagine laptop with battery, and connected to UPS. ;-) How userspace
will differ internal battery from UPS? Yup, by type attribute. I hope
it makes sense... If not, we simply can remove UPS type.


And again, much thanks for your review and ideas!

--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.org/bd2
___
Kernel-discuss mailing list
[EMAIL PROTECTED]
https://handhelds.org/mailman/listinfo/kernel-discuss


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

Re: [PATCH 4/10] ARM: OMAP: gpio init section cleanups

2007-05-05 Thread Russell King

On Mon, Apr 09, 2007 at 05:01:06PM -0400, Tony Lindgren wrote:
> From: David Brownell <[EMAIL PROTECTED]>
> 
> Minor GPIO cleanups:  remove needless #include, and omap_gpio_init()
> should be __init, as well as all the board init code calling it.
> 
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>

I've applied 8 patches from this series by cherry picking it from your
git tree, minus this patch which git wouldn't apply due to fuzz in
arch/arm/plat-omap/gpio.c.

> ---
>  arch/arm/mach-omap1/board-fsample.c   |2 +-
>  arch/arm/mach-omap1/board-h3.c|2 +-
>  arch/arm/mach-omap1/board-innovator.c |2 +-
>  arch/arm/mach-omap1/board-perseus2.c  |2 +-
>  arch/arm/plat-omap/gpio.c |3 +--
>  5 files changed, 5 insertions(+), 6 deletions(-)
> 
> --- a/arch/arm/mach-omap1/board-fsample.c
> +++ b/arch/arm/mach-omap1/board-fsample.c
> @@ -246,7 +246,7 @@ static void __init fsample_init_smc91x(void)
>   mdelay(50);
>  }
>  
> -void omap_fsample_init_irq(void)
> +static void __init omap_fsample_init_irq(void)
>  {
>   omap1_init_common_hw();
>   omap_init_irq();
> --- a/arch/arm/mach-omap1/board-h3.c
> +++ b/arch/arm/mach-omap1/board-h3.c
> @@ -455,7 +455,7 @@ static void __init h3_init_smc91x(void)
>   }
>  }
>  
> -void h3_init_irq(void)
> +static void __init h3_init_irq(void)
>  {
>   omap1_init_common_hw();
>   omap_init_irq();
> --- a/arch/arm/mach-omap1/board-innovator.c
> +++ b/arch/arm/mach-omap1/board-innovator.c
> @@ -308,7 +308,7 @@ static void __init innovator_init_smc91x(void)
>   }
>  }
>  
> -void innovator_init_irq(void)
> +static void __init innovator_init_irq(void)
>  {
>   omap1_init_common_hw();
>   omap_init_irq();
> --- a/arch/arm/mach-omap1/board-perseus2.c
> +++ b/arch/arm/mach-omap1/board-perseus2.c
> @@ -246,7 +246,7 @@ static void __init perseus2_init_smc91x(void)
>   mdelay(50);
>  }
>  
> -void omap_perseus2_init_irq(void)
> +static void __init omap_perseus2_init_irq(void)
>  {
>   omap1_init_common_hw();
>   omap_init_irq();
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -13,7 +13,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -1329,7 +1328,7 @@ void omap2_gpio_resume_after_retention(void)
>   * This may get called early from board specific init
>   * for boards that have interrupts routed via FPGA.
>   */
> -int omap_gpio_init(void)
> +int __init omap_gpio_init(void)
>  {
>   if (!initialized)
>   return _omap_gpio_init();
> -- 
> 1.4.4.2
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: [git pull] Input patches for 2.6.20

2007-05-05 Thread Martin Schwidefsky

On Fri, 2007-05-04 at 23:03 -0700, Greg KH wrote:
> > Martin, in the process I noticed that the new file
> > 
> >   arch/s390/kernel/ipl.c
> > 
> > seems to be broken by the same thing after the driver core merge. The fix 
> > _looks_ equally trivial (change *subsys.kset.kobj into just *subsys.kobj), 
> > but I didn't do that trivial thing, because I cannot even test-compile the 
> > end result. So can you give it a quick look, please?
> 
> Martin, Cornelia already sent me (and lkml) a patch to fix this all up
> if you want to just use that instead.

Nod, Cornelia already found and fixed this problem, so it will be easy
for us to correct the code even if it gets broken in the upstream tree
for a short while. So from our perspective just go ahead and pull.

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] UBI: dereference after kfree in create_vtbl


On 5/5/07, Artem Bityutskiy <[EMAIL PROTECTED]> wrote:

[...]
I've put the fix here:
http://git.infradead.org/?p=users/dedekind/ubi-2.6.git;a=commit;h=5125237efb6a3309fbf5b9a7a21aaf716787f2a2



write_error:
if (err == -EIO && ++tries <= 5) {
/*
 * Probably this physical eraseblock went bad, try to pick
 * another one.
 */
list_add_tail(&new_seb->u.list, &si->corr);
goto retry;
}
kfree(new_seb);
out_free:
ubi_free_vid_hdr(ubi, vid_hdr);
return err;


Ummm ...

1. "if (err == -EIO)" applies to adding new_seb to the corrupted list,
and not to retrying. We wouldn't want _not_ to retry if there's some
other error, or would we?
2. "if (++tries <= 5)" applies to "goto retry" and not to adding
new_seb to the corrupted list. If we hit write failure for the 5th
time and err == -EIO, we should still be adding it to corrupted list,
but not retry, of course. Otherwise we would add the first 4 write
failure (with -EIO) eraseblocks to si->corr, but the 5th _similar_
case is ... just freed?

So:

write_error:
/*
 * Probably this physical eraseblock went bad, add it to the
 * corrupted list. Else, just release it.
 */
if (err == -EIO)
/* list_add_tail(&new_seb->u.list, &si->corr); */
__ubi_scan_add_to_list(si, new_seb, &si->corr);
else
kfree(new_seb);
/* Try to pick another one */
if (++tries <= 5)
goto retry;
out_free:
ubi_free_vid_hdr(ubi, vid_hdr);
return err;

And in case you want to avoid the list_add_tail there, the following
(I'm fine with whichever way, of course):

diff -ruNp a/drivers/mtd/ubi/scan.c b/drivers/mtd/ubi/scan.c
--- a/drivers/mtd/ubi/scan.c2007-05-05 10:52:47.0 +0530
+++ b/drivers/mtd/ubi/scan.c2007-05-05 11:47:26.0 +0530
@@ -55,29 +55,37 @@ static int paranoid_check_si(const struc
static struct ubi_ec_hdr *ech;
static struct ubi_vid_hdr *vidh;

-int ubi_scan_add_to_list(struct ubi_scan_info *si, int pnum, int ec,
-struct list_head *list)
+void __ubi_scan_add_to_list(struct ubi_scan_info *si,
+   struct ubi_scan_leb *seb,
+   struct list_head *list)
{
-   struct ubi_scan_leb *seb;
-
if (list == &si->free)
-   dbg_bld("add to free: PEB %d, EC %d", pnum, ec);
+   dbg_bld("add to free: PEB %d, EC %d", seb->pnum, seb->ec);
else if (list == &si->erase)
-   dbg_bld("add to erase: PEB %d, EC %d", pnum, ec);
+   dbg_bld("add to erase: PEB %d, EC %d", seb->pnum, seb->ec);
else if (list == &si->corr)
-   dbg_bld("add to corrupted: PEB %d, EC %d", pnum, ec);
+   dbg_bld("add to corrupted: PEB %d, EC %d", seb->pnum, seb->ec);
else if (list == &si->alien)
-   dbg_bld("add to alien: PEB %d, EC %d", pnum, ec);
+   dbg_bld("add to alien: PEB %d, EC %d", seb->pnum, seb->ec);
else
BUG();

+   list_add_tail(&seb->u.list, list);
+}
+
+int ubi_scan_add_to_list(struct ubi_scan_info *si, int pnum, int ec,
+struct list_head *list)
+{
+   struct ubi_scan_leb *seb;
+
seb = kmalloc(sizeof(struct ubi_scan_leb), GFP_KERNEL);
if (unlikely(!seb))
return -ENOMEM;

seb->pnum = pnum;
seb->ec = ec;
-   list_add_tail(&seb->u.list, list);
+   __ubi_scan_add_to_list(si, seb, list);
+
return 0;
}

diff -ruNp a/drivers/mtd/ubi/scan.h b/drivers/mtd/ubi/scan.h
--- a/drivers/mtd/ubi/scan.h2007-05-05 10:55:24.0 +0530
+++ b/drivers/mtd/ubi/scan.h2007-05-05 10:55:01.0 +0530
@@ -147,6 +147,9 @@ static inline void ubi_scan_move_to_list
list_add_tail(&seb->u.list, list);
}

+void __ubi_scan_add_to_list(struct ubi_scan_info *si,
+   struct ubi_scan_leb *seb,
+   struct list_head *list);
int ubi_scan_add_to_list(struct ubi_scan_info *si, int pnum, int ec,
 struct list_head *list);
int ubi_scan_add_used(const struct ubi_device *ubi, struct ubi_scan_info *si,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.21-mm1: many processes end up in D state

2007-05-05 Thread Tejun Heo

Mikael Pettersson wrote:
>> I.e. no freezing of ports...
> 
> Your patch to delete the 'return 1;' on error is correct,
> and makes the code match exactly the behaviour of previous
> versions of sata_promise, except for the additional error
> decoding.
> 
> ahci and sata_sil24 do the return in this situation. I don't
> yet understand why they can get away with it while sata_promise
> cannot, but for now the return should be removed.

That's because sata_sil24 and ahci call either ata_port_abort() or
ata_port_freeze() prior to finishing error_intr routine.  Both functions
abort all in-flight command and schedule EH.

--
tejun

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

Re: [PATCH] UBI: dereference after kfree in create_vtbl

On Sat, 2007-05-05 at 19:18 +0530, Satyam Sharma wrote:
> Well, you're developing / maintaining this right now, so it's your
> call. Though I bet most people would find keeping that list_add_tail
> local to scan.c more tasteful.

I do not think so. If you are interested, try to find "UBI take 2"
patches in lkml. Look how it looked liked. It consisted of many
independent units and units could access other units _only_ via
interfaces. I would do what you say there.

Read Teo's comments - I actually now agree with them. And after I had
changed UBI i got rid of several thousands lines of code, and the code
became simpler.

So, my argument is:
1. It makes no sense to introduce one more non-static function to _just_
encapsulate list_add_tail and _just_ for one caller.
2. It is _C_, it is _kernel_, and it is OK sometimes _not_ to follow
computer since rules.

> I wish you'd commented it better than "This function returns zero in
> case of success and a negative error code in case of failure." in that
> case :-)
Agreed, I'll add more comments, thanks.

> Again, you're developing and maintaining this right now, so it's your
> call. Though it would be easier on you if you remove these exceptions
> that could be quite easily removed, actually.
I do not see any nice way to do this. If you suggest one, I will do.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

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

Re: [PATCH 4/10] ARM: OMAP: gpio init section cleanups

2007-05-05 Thread Russell King

On Sat, May 05, 2007 at 11:04:26AM +0100, Russell King wrote:
> On Mon, Apr 09, 2007 at 05:01:06PM -0400, Tony Lindgren wrote:
> > From: David Brownell <[EMAIL PROTECTED]>
> > 
> > Minor GPIO cleanups:  remove needless #include, and omap_gpio_init()
> > should be __init, as well as all the board init code calling it.
> > 
> > Signed-off-by: David Brownell <[EMAIL PROTECTED]>
> > Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> 
> I've applied 8 patches from this series by cherry picking it from your
> git tree, minus this patch which git wouldn't apply due to fuzz in
> arch/arm/plat-omap/gpio.c.

Incidentally, when doing a build after these patches, I'm seeing:

arch/arm/plat-omap/dma.c: In function `omap_get_dma_src_pos':
arch/arm/plat-omap/dma.c:750: warning: 'offset' might be used uninitialized in 
this function
arch/arm/plat-omap/dma.c: In function `omap_get_dma_dst_pos':
arch/arm/plat-omap/dma.c:772: warning: 'offset' might be used uninitialized in 
this function

These look like they're valid warnings to me.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-discuss] Re: [PATCH 3/8] Universal power supply class (was: battery class)

2007-05-05 Thread Paul Sokolovsky

Hello Anton,

Saturday, May 5, 2007, 3:32:30 PM, you wrote:

> Hello Henrique, Shem,

> On Sat, May 05, 2007 at 12:54:13AM -0300, Henrique de Moraes Holschuh wrote:
>> On Fri, 04 May 2007, Shem Multinymous wrote:
>> > >+enum power_supply_type {
>> > >+   POWER_SUPPLY_TYPE_BATTERY = 0,
>> > >+   POWER_SUPPLY_TYPE_UPS,
>> > >+   POWER_SUPPLY_TYPE_AC,
>> > >+   POWER_SUPPLY_TYPE_USB,
>> > >+};
>> > 
>> > How about dumb (non-USB) DC power? Any reason to distinguish it from AC?
>> 

[]

> I think I got the start point of confusion. It's indeed bad to call such
> power supply type as AC.

Ok, let's try to at least find the root of this confusion. Of
course, course, what we mean by "AC" is exactly continuous, "infinite"
power source. Of course, from real physicist point of view, this is
incorrect - hardly any device in topic domain (i.e.
portable/battery-power) has AC cord sticking out of case. There's usually
an AC/DC adapter, and DC is what really fed into device.

But in real world, it's rather common to colloquially name
such kind of power "AC", and that's "term" is known to many-many
people, and intuitively understood even for those, who didn't hit it yet.
Actually, this discussion is good confirmation that's the case -
people understand in what meaning it is used here, and go to point
that it's not "scientifically" correct.

> Maybe I should it rename to ADAPTER? Or WALL?

Well-well, above was pointed out, that "AC" even if not fully
correct, that at least colloquial term of choice for the phenomena inq
question. Words above on the other hand seems like out-of-scope and
ambiguous. There's actually a nice and terse term for that - mains,
but I wonder how well non-English speaking people are familiar with it
(I personally saw them only in manuals, which, as well known, nobody
reads).

Summing up, it may be worth a quick thought, should it be
"absolutely correct and absolutely useless", or just well-understood
up to the level that even elementary school pupil could write an
eloquence essay criticizing it ;-).

[]

-- 
Best regards,
 Paulmailto:[EMAIL PROTECTED]

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

[PATCH] lguest: don't use paravirt_probe, it's dying

2007-05-05 Thread Rusty Russell

On Sat, 2007-05-05 at 13:22 +1000, Rusty Russell wrote:
> On Fri, 2007-05-04 at 20:53 -0600, Eric W. Biederman wrote:
> > Frankly I think the least risk of problems comes from just doing a
> > separate entry point for lguest for now.  It means we don't even have
> > to touch the common code path and later dropping will be trivially 
> > lguest specific, and certain to not break anything else.
> 
> Hmm, I railed for so long against Xen doing that, it feels... wrong...
> to do that now 8)

And here's the patch.  It's pretty trivial actually.  It even worked
first time.  It applies against -mm (ie. before the "boot with P=V"
patches I showed before).

Thanks!
Rusty.
==
paravirt_probe() and its infrastructure proved as popular as it was
pretty.  In anticipation of its imminent demise, this switches lguest to
use a magic string to identify a different entry point.

This is not the long-term solution: that will take a new bootloader rev
and will hopefully be done in the next few months.

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>

diff -r 9cfbf629088e Documentation/lguest/lguest.c
--- a/Documentation/lguest/lguest.c Sat May 05 13:06:53 2007 +1000
+++ b/Documentation/lguest/lguest.c Sat May 05 17:33:25 2007 +1000
@@ -96,6 +96,19 @@ static void *map_zeroed_pages(unsigned l
return (void *)addr;
 }
 
+/* Find magic string marking entry point, return entry point. */
+static unsigned long entry_point(void *start, void *end,
+unsigned long page_offset)
+{
+   void *p;
+
+   for (p = start; p < end; p++)
+   if (memcmp(p, "GenuineLguest", strlen("GenuineLguest")) == 0)
+   return (long)p + strlen("GenuineLguest") + page_offset;
+
+   err(1, "Is this image a genuine lguest?");
+}
+
 /* Returns the entry point */
 static unsigned long map_elf(int elf_fd, const Elf32_Ehdr *ehdr,
 unsigned long *page_offset)
@@ -103,6 +116,7 @@ static unsigned long map_elf(int elf_fd,
void *addr;
Elf32_Phdr phdr[ehdr->e_phnum];
unsigned int i;
+   unsigned long start = -1UL, end = 0;
 
/* Sanity checks. */
if (ehdr->e_type != ET_EXEC
@@ -131,6 +145,11 @@ static unsigned long map_elf(int elf_fd,
*page_offset = phdr[i].p_vaddr - phdr[i].p_paddr;
else if (*page_offset != phdr[i].p_vaddr - phdr[i].p_paddr)
errx(1, "Page offset of section %i different", i);
+
+   if (phdr[i].p_paddr < start)
+   start = phdr[i].p_paddr;
+   if (phdr[i].p_paddr + phdr[i].p_filesz > end)
+   end = phdr[i].p_paddr + phdr[i].p_filesz;
 
/* We map everything private, writable. */
addr = mmap((void *)phdr[i].p_paddr,
@@ -143,8 +162,7 @@ static unsigned long map_elf(int elf_fd,
i, addr, (void *)phdr[i].p_paddr);
}
 
-   /* Entry is physical address: convert to virtual */
-   return ehdr->e_entry + *page_offset;
+   return entry_point((void *)start, (void *)end, *page_offset);
 }
 
 /* This is amazingly reliable. */
@@ -175,8 +193,7 @@ static unsigned long unpack_bzimage(int 
verbose("Unpacked size %i addr %p\n", len, img);
*page_offset = intuit_page_offset(img, len);
 
-   /* Entry is physical address: convert to virtual */
-   return (unsigned long)img + *page_offset;
+   return entry_point(img, img + len, *page_offset);
 }
 
 static unsigned long load_bzimage(int fd, unsigned long *page_offset)
diff -r 9cfbf629088e drivers/lguest/lguest.c
--- a/drivers/lguest/lguest.c   Sat May 05 13:06:53 2007 +1000
+++ b/drivers/lguest/lguest.c   Sat May 05 17:21:44 2007 +1000
@@ -43,7 +43,6 @@ extern const char lgstart_popf[], lgend_
 extern const char lgstart_popf[], lgend_popf[];
 extern const char lgstart_pushf[], lgend_pushf[];
 extern const char lgstart_iret[], lgend_iret[];
-extern asmlinkage void lguest_maybe_init(void);
 extern void lguest_iret(void);
 
 struct lguest_data lguest_data = {
@@ -497,4 +496,3 @@ __init void lguest_init(void)
pm_power_off = lguest_power_off;
start_kernel();
 }
-paravirt_probe(lguest_maybe_init);
diff -r 9cfbf629088e drivers/lguest/lguest_asm.S
--- a/drivers/lguest/lguest_asm.S   Sat May 05 13:06:53 2007 +1000
+++ b/drivers/lguest/lguest_asm.S   Sat May 05 17:21:38 2007 +1000
@@ -1,29 +1,24 @@
 #include 
 #include 
 #include 
+#include 
 
 /* FIXME: Once asm/processor-flags.h goes in, include that */
 #define X86_EFLAGS_IF 0x0200
 
 /*
- * This is where we begin: head.S notes that paging is already enabled (which
- * doesn't happen in native boot) and calls the registered paravirt_probe
- * functions one at a time.  Ours is a simple assembler test for magic
- * registers.  If they're correct we jump to lguest_init.
+ * This is where we begin: we have a magic signature which the launcher looks
+ * for.  The plan is that

Re: [RFC 2/3] SLUB: Implement targeted reclaim and partial list defragmentation

On Fri, 4 May 2007, William Lee Irwin III wrote:

> kick_object() doesn't return an indicator of success, which might be
> helpful for determining whether an object was successfully removed. The
> later-added kick_dentry_object(), for instance, can't remove dentries
> where reference counts are still held.
> 
> I suppose one could check to see if the ->inuse counter decreased, too.

Yes that is exactly what is done. The issue is that concurrent frees may 
occur. So we just kick them all and see if all objects are gone at the 
end.
 
> In either event, it would probably be helpful to abort the operation if
> there was a reclamation failure for an object within the slab.

Hmmm... The failure may be because another process is attempting 
a kmem_cache_free on an object. But we are holding the lock. The free
will succeed when we drop it.

> This is a relatively minor optimization concern. I think this patch
> series is great and a significant foray into the problem of slab
> reclaim vs. fragmentation.

Thanks.

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

Con Kolivas wrote:
This patchset is designed to improve system responsiveness and interactivity.
It is configurable to any workload but the default -ck patch is aimed at the
desktop and -cks is available with more emphasis on serverspace.

Apply to 2.6.21
http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.21/2.6.21-ck1/patch-2.6.21-ck1.bz2

Hi all,

i am using this patch for the first time and i am reporting my experience.

Before this patch with all the programs i usually keep running
(opera/iceweasel with lots of tabs, icedove mail client, konversation
irc client, akregator feed reader, and the super-hog second life client,
vim, among others) the reponse was a bit slugish (waiting for program
focus, wait for redrawing specially when i change from one virtual
desktop to another).

After I started using this patch the response/interactivity seems
improved and faster, i never used Linux so responsive as now. I can
switch between virtual desktops with immediate response. Even with a
load of 2.0 (now, while i am writing this) thse system it's very
responsive and the audio and video still work without glitches.

Just for the record, and if it matters i am using it on a laptop with a
T2500 CPU, 1 GB RAM.

If there's any way i can help, providing data, running any kind of
benchmark to quantify the beahaviour, etc... please ask.

Thanks all who made/tested this patch. Good work. Thanks.

[...]

乾杯

Com os melhores cumprimentos/Best regards,

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

Re: [PATCH] UBI: dereference after kfree in create_vtbl

On 5/5/07, Artem Bityutskiy <[EMAIL PROTECTED]> wrote:

On Sat, 2007-05-05 at 17:56 +0530, Satyam Sharma wrote:
> > And it is fine to use list_add_tail() directly in vtbl.c. Will be fixed.
> Ah, good to know that, but please keep list_add_tail (or whatever is
> the implementation abstraction of the various ubi_scan_info lists)
> local to scan.c -- you could expose a version of ubi_scan_add_to_list
> that does not do kmalloc through scan.h and use that in vtbl.c. That
> way you won't lose those debug printk's when adding an eraseblock to a
> list, for example, and it's always much cleaner not exposing an
> object's implementation innards to others.

It's error path and that print is not really needed. We'll see other
complaints in that case. And this is _the only_ place outside scan.c, so
it makes sense to use list_add_tail(). We do not really need to hide
this behind some other call (ubi_scan_add_to_list())

Well, you're developing / maintaining this right now, so it's your
call. Though I bet most people would find keeping that list_add_tail
local to scan.c more tasteful.

>  Physical eraseblocks are allocated in ubi_scan_add_to_list
> (which shouldn't be doing that)
Yes, per-PEB scanning information is allocated in ubi_scan_add_to_list()
and ubi_scan_add_to_used(). I do not see why it shouldn't be doing that.

>  and ubi_scan_add_used (which is a maze)
It actually is rather complex because it does a rather complex thing.

I wish you'd commented it better than "This function returns zero in
case of success and a negative error code in case of failure." in that
case :-)

But any patch/idea to make it simpler is welcome.
> and freed pretty much all over the place
It is only freed in ubi_scan_destroy_si(). Yes, there is one exception
in create_vtbl, but this is because I did not want to introduce any
special version of ubi_scan_add_used().

It does not hurt at all that we do one extra allocation, because it is
called _only_ 2 times (once for each volume table copy).

>  (because we allocate
> new seb's for ourselves to add to the lists, we need to go about
> kfree'ing all of them when destroying a ubi_scan_destroy_si too, for
> example -- perhaps this driver needs to be told about krefs).

Sorry. not sure what you mean. They are allocated in 2 places, and freed
in one, with one exception in vtbl_create() which does not matter much.

>  So it
> makes life easier if you know there's only one place when/where an
> object is born,
May be it is, but I have 2 places and do not see any problem.

Again, you're developing and maintaining this right now, so it's your
call. Though it would be easier on you if you remove these exceptions
that could be quite easily removed, actually.

Thanks,
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] s390: fix subsystem removal fallout.

2007-05-05 Thread Heiko Carstens

[patch] s390: fix subsystem removal fallout.

From: Cornelia Huck <[EMAIL PROTECTED]>

This patch fixes compilation on s390.

Cc: Martin Schwidefsky <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
---
 arch/s390/hypfs/inode.c |2 +-
 arch/s390/kernel/ipl.c  |   26 +-
 2 files changed, 14 insertions(+), 14 deletions(-)

Index: linux-2.6/arch/s390/hypfs/inode.c
===
--- linux-2.6.orig/arch/s390/hypfs/inode.c
+++ linux-2.6/arch/s390/hypfs/inode.c
@@ -477,7 +477,7 @@ static int __init hypfs_init(void)
goto fail_diag;
}
}
-   kset_set_kset_s(&s390_subsys, hypervisor_subsys);
+   kobj_set_kset_s(&s390_subsys, hypervisor_subsys);
rc = subsystem_register(&s390_subsys);
if (rc)
goto fail_sysfs;
Index: linux-2.6/arch/s390/kernel/ipl.c
===
--- linux-2.6.orig/arch/s390/kernel/ipl.c
+++ linux-2.6/arch/s390/kernel/ipl.c
@@ -816,23 +816,23 @@ static int __init ipl_register_fcp_files
 {
int rc;
 
-   rc = sysfs_create_group(&ipl_subsys.kset.kobj,
+   rc = sysfs_create_group(&ipl_subsys.kobj,
&ipl_fcp_attr_group);
if (rc)
goto out;
-   rc = sysfs_create_bin_file(&ipl_subsys.kset.kobj,
+   rc = sysfs_create_bin_file(&ipl_subsys.kobj,
   &ipl_parameter_attr);
if (rc)
goto out_ipl_parm;
-   rc = sysfs_create_bin_file(&ipl_subsys.kset.kobj,
+   rc = sysfs_create_bin_file(&ipl_subsys.kobj,
   &ipl_scp_data_attr);
if (!rc)
goto out;
 
-   sysfs_remove_bin_file(&ipl_subsys.kset.kobj, &ipl_parameter_attr);
+   sysfs_remove_bin_file(&ipl_subsys.kobj, &ipl_parameter_attr);
 
 out_ipl_parm:
-   sysfs_remove_group(&ipl_subsys.kset.kobj, &ipl_fcp_attr_group);
+   sysfs_remove_group(&ipl_subsys.kobj, &ipl_fcp_attr_group);
 out:
return rc;
 }
@@ -846,7 +846,7 @@ static int __init ipl_init(void)
return rc;
switch (ipl_info.type) {
case IPL_TYPE_CCW:
-   rc = sysfs_create_group(&ipl_subsys.kset.kobj,
+   rc = sysfs_create_group(&ipl_subsys.kobj,
&ipl_ccw_attr_group);
break;
case IPL_TYPE_FCP:
@@ -854,11 +854,11 @@ static int __init ipl_init(void)
rc = ipl_register_fcp_files();
break;
case IPL_TYPE_NSS:
-   rc = sysfs_create_group(&ipl_subsys.kset.kobj,
+   rc = sysfs_create_group(&ipl_subsys.kobj,
&ipl_nss_attr_group);
break;
default:
-   rc = sysfs_create_group(&ipl_subsys.kset.kobj,
+   rc = sysfs_create_group(&ipl_subsys.kobj,
&ipl_unknown_attr_group);
break;
}
@@ -885,7 +885,7 @@ static int __init reipl_nss_init(void)
 
if (!MACHINE_IS_VM)
return 0;
-   rc = sysfs_create_group(&reipl_subsys.kset.kobj, &reipl_nss_attr_group);
+   rc = sysfs_create_group(&reipl_subsys.kobj, &reipl_nss_attr_group);
if (rc)
return rc;
strncpy(reipl_nss_name, kernel_nss_name, NSS_NAME_SIZE + 1);
@@ -900,7 +900,7 @@ static int __init reipl_ccw_init(void)
reipl_block_ccw = (void *) get_zeroed_page(GFP_KERNEL);
if (!reipl_block_ccw)
return -ENOMEM;
-   rc = sysfs_create_group(&reipl_subsys.kset.kobj, &reipl_ccw_attr_group);
+   rc = sysfs_create_group(&reipl_subsys.kobj, &reipl_ccw_attr_group);
if (rc) {
free_page((unsigned long)reipl_block_ccw);
return rc;
@@ -938,7 +938,7 @@ static int __init reipl_fcp_init(void)
reipl_block_fcp = (void *) get_zeroed_page(GFP_KERNEL);
if (!reipl_block_fcp)
return -ENOMEM;
-   rc = sysfs_create_group(&reipl_subsys.kset.kobj, &reipl_fcp_attr_group);
+   rc = sysfs_create_group(&reipl_subsys.kobj, &reipl_fcp_attr_group);
if (rc) {
free_page((unsigned long)reipl_block_fcp);
return rc;
@@ -990,7 +990,7 @@ static int __init dump_ccw_init(void)
dump_block_ccw = (void *) get_zeroed_page(GFP_KERNEL);
if (!dump_block_ccw)
return -ENOMEM;
-   rc = sysfs_create_group(&dump_subsys.kset.kobj, &dump_ccw_attr_group);
+   rc = sysfs_create_group(&dump_subsys.kobj, &dump_ccw_attr_group);
if (rc) {
free_page((unsigned long)dump_block_ccw);
return rc;
@@ -1014,7 +1014,7 @@ static int __init dump_fcp_init(void)
dump_block_fcp = (void *) get_zeroed_page

[patch] af_iucv: compile fix - adopt to skbuff changes.

2007-05-05 Thread Heiko Carstens

[patch] af_iucv: compile fix - adopt to skbuff changes.

From: Heiko Carstens <[EMAIL PROTECTED]>

  CC [M]  net/iucv/af_iucv.o
net/iucv/af_iucv.c: In function `iucv_fragment_skb':
net/iucv/af_iucv.c:984: error: structure has no member named `h'
net/iucv/af_iucv.c:985: error: structure has no member named `nh'
net/iucv/af_iucv.c:988: error: incompatible type for argument 1 of
`skb_queue_tail'

Cc: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Cc: David Miller <[EMAIL PROTECTED]>
Cc: Martin Schwidefsky <[EMAIL PROTECTED]>
Cc: Frank Pavlic <[EMAIL PROTECTED]>
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
---
 net/iucv/af_iucv.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

Index: linux-2.6/net/iucv/af_iucv.c
===
--- linux-2.6.orig/net/iucv/af_iucv.c
+++ linux-2.6/net/iucv/af_iucv.c
@@ -961,7 +961,7 @@ static void iucv_callback_connack(struct
 }
 
 static int iucv_fragment_skb(struct sock *sk, struct sk_buff *skb, int len,
-struct sk_buff_head fragmented_skb_q)
+struct sk_buff_head *fragmented_skb_q)
 {
int dataleft, size, copied = 0;
struct sk_buff *nskb;
@@ -981,8 +981,8 @@ static int iucv_fragment_skb(struct sock
copied += size;
dataleft -= size;
 
-   nskb->h.raw = nskb->data;
-   nskb->nh.raw = nskb->data;
+   skb_reset_transport_header(nskb);
+   skb_reset_network_header(nskb);
nskb->len = size;
 
skb_queue_tail(fragmented_skb_q, nskb);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

2007/5/5, Paul Fulghum <[EMAIL PROTECTED]>:

On Fri, 2007-05-04 at 17:30 -0600, Paul Fulghum wrote:
> OK, this behavior is so unexpected I must be missing
> something basic.

And so I was. Try this patch.

--- a/drivers/char/tty_io.c 2007-05-04 05:46:55.0 -0500
+++ b/drivers/char/tty_io.c 2007-05-05 03:23:46.0 -0500

Great! Really good job, Paul. The patch now boot properly and solves
completely the testcase with two serial lines:

In [1]: import serial
In [2]: s0 = serial.Serial(0, timeout=1)
In [3]: s1 = serial.Serial(1, timeout=1)
In [4]: s0.write('test\n')
In [5]: s1.inWaiting()
Out[5]: 5L
In [6]: s1.readline()
Out[6]: 'test\n'
In [7]: for i in xrange(1000):
   ...: s0.write(str(i).zfill(8)+'\n')
   ...:
In [8]: s1.inWaiting()
Out[8]: 4095L
In [9]: s1.flushInput()
In [10]: s1.inWaiting()
Out[10]: 0L
In [11]: s0.write('test\n')
In [12]: s1.inWaiting()
Out[12]: 5L
In [13]: s1.readline()
Out[13]: 'test\n'

I've done more tests with other scripts and all works perfectly (the
input buffer is really totally flushed the first time). Many thanks! I
think this patch should be included in mainline, since if one flushes
the input buffer, really want to flush the entire buffer chain and
doesn't want to read any old data _after_ a flush.

However I also tested a usb-serial device (that uses the cdc-acm
driver) and in this case I still need _two_ flushInput() to totally
flush the input buffer.

There can be another *secondary buffer* in the usb-serial driver? Can
this buffer be emptied out too?

I bet the same behavior can be reproduced with another FTDI-based
usb-serial device that I haven't at hand now (but that I can test the
next week).

Many thanks for the help so far.

Regards,

 ~ Antonio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] UBI: dereference after kfree in create_vtbl

On Sat, 2007-05-05 at 17:56 +0530, Satyam Sharma wrote:
> > And it is fine to use list_add_tail() directly in vtbl.c. Will be fixed.
> Ah, good to know that, but please keep list_add_tail (or whatever is
> the implementation abstraction of the various ubi_scan_info lists)
> local to scan.c -- you could expose a version of ubi_scan_add_to_list
> that does not do kmalloc through scan.h and use that in vtbl.c. That
> way you won't lose those debug printk's when adding an eraseblock to a
> list, for example, and it's always much cleaner not exposing an
> object's implementation innards to others.

It's error path and that print is not really needed. We'll see other
complaints in that case. And this is _the only_ place outside scan.c, so
it makes sense to use list_add_tail(). We do not really need to hide
this behind some other call (ubi_scan_add_to_list())

>  Physical eraseblocks are allocated in ubi_scan_add_to_list
> (which shouldn't be doing that)
Yes, per-PEB scanning information is allocated in ubi_scan_add_to_list()
and ubi_scan_add_to_used(). I do not see why it shouldn't be doing that.

>  and ubi_scan_add_used (which is a maze) 
It actually is rather complex because it does a rather complex thing.
But any patch/idea to make it simpler is welcome.

> and freed pretty much all over the place
It is only freed in ubi_scan_destroy_si(). Yes, there is one exception
in create_vtbl, but this is because I did not want to introduce any
special version of ubi_scan_add_used().

It does not hurt at all that we do one extra allocation, because it is
called _only_ 2 times (once for each volume table copy).

>  (because we allocate
> new seb's for ourselves to add to the lists, we need to go about
> kfree'ing all of them when destroying a ubi_scan_destroy_si too, for
> example -- perhaps this driver needs to be told about krefs).

Sorry. not sure what you mean. They are allocated in 2 places, and freed
in one, with one exception in vtbl_create() which does not matter much.

>  So it
> makes life easier if you know there's only one place when/where an
> object is born,
May be it is, but I have 2 places and do not see any problem.

>  if you know that it'll remain alive as long as you
> need it and have a reference on it, and if you destroy it a known
> single time/location too.
I have 1 destroy location. And one exception where I allocate it
temporarily and destroy in the same function. And it is done only 2
times and only if one attaches un-formatted flash.

>  I wish I could be more specific than this,
> but I've only spent a few hours with ubi :-)
Thanks for your analysis, it would be helpful if more people did this.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

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

Re: [RFC 0/3] Slab Defrag / Slab Targeted Reclaim and general Slab API changes

On Sat, 5 May 2007, Eric Dumazet wrote:

> > Then add ___cacheline_aligned_in_smp or specify the alignment in the various
> > other ways that exist. Practice is that most slabs specify
> > SLAB_HWCACHE_ALIGN. So most slabs are cache aligned today.
> 
> Yes but this alignement is dynamic, not at compile time.
> 
> include/asm-i386/processor.h:739:#define cache_line_size()
> (boot_cpu_data.x86_cache_alignment)

Ahh.. I did not see that before.

> So adding cacheline_aligned  to 'struct file' for example would be a
> regression for people with PII or PIII

Yuck.

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

REGRESSION: cannot change file access permissions on files NFS-mounted

2007-05-05 Thread Florin Iucha

Hello,

This morning I updated the kernel on my workstation to the current git 
tree (62ea6d80211ecc88ef516927ecebf64cb505be3f).   Upon reboot, I
cannot change file access permissions of files in a directory that is
nfs mounted (using NFS4):

   $ chmod 0600 $path
   chmod: Changing permissions of `$path': Input/output error

In the kernel log I am getting these gems:

   [  275.990233] decode_attr_group: reply buffer overflowed in line
   2678.<4>decode
   _attr_group: reply buffer overflowed in line
   2678.<4>decode_attr_group: reply bu
   ffer overflowed in line 2678.<4>decode_attr_group: reply buffer
   overflowed in li
   ne 2678.<4>decode_attr_group: reply buffer overflowed in line
   2678.<4>decode_att
   r_group: reply buffer overflowed in line 2678.

The server is Linux running Debian testing with the kernel updated to 
2.6.20-1-686 from
(http://ftp.us.debian.org/debian/pool/main/l/linux-2.6/linux-image-2.6.20-1-686_2.6.20-3_i386.deb)

Kernel 2.6.21 works fine on the client.

Cheers,
florin

-- 
Bruce Schneier expects the Spanish Inquisition.
  http://geekz.co.uk/schneierfacts/fact/163


signature.asc
Description: Digital signature

Re: [Kernel-discuss] Re: [PATCH 3/8] Universal power supply class (was: battery class)

2007-05-05 Thread Paul Sokolovsky

Hello ian,

Saturday, May 5, 2007, 4:46:26 PM, you wrote:

> On Sat, 2007-05-05 at 00:54 -0300, Henrique de Moraes Holschuh wrote:

>> Given that USB-power *is* usually also "dumb" (i.e. it doesn't do any
>> control signaling over the USB bus for power-control purposes),

> it might be dumb, but it is useful to know wether the PDA is charging
> from usb or mains power. and some devices allow one to switch on / off
> the ability to charge via usb

And USB does have power budgetting requirements, etc. (like
was already pointed in own of initial review messages). So, USB
is definitely not the same thing as "dumb DC".


-- 
Best regards,
 Paulmailto:[EMAIL PROTECTED]

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

Re: [RFC 2/3] SLUB: Implement targeted reclaim and partial list defragmentation

On Sat, 5 May 2007, Andi Kleen wrote:

> [EMAIL PROTECTED] writes:
> > 
> > NOTE: This patch is for conceptual review. I'd appreciate any feedback
> > especially on the locking approach taken here. It will be critical to
> > resolve the locking issue for this approach to become feasable.
> 
> Do you have any numbers on how this improves dcache reclaim under memory 
> pressure?

How does one measure something like that?

I wanted to first make sure that the thing is sane. If there is a gaping 
race here then I may have to add more code to cover that.

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

Re: [RFC 1/3] SLUB: slab_ops instead of constructors / destructors

2007-05-05 Thread Pekka Enberg


On 5/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

This patch gets rid constructors and destructors and replaces them
with a slab operations structure that is passed into SLUB.


Looks good to me.

On 5/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

+struct slab_ops {
+   /* FIXME: ctor should only take the object as an argument. */
+   void (*ctor)(void *, struct kmem_cache *, unsigned long);
+   /* FIXME: Remove all destructors ? */
+   void (*dtor)(void *, struct kmem_cache *, unsigned long);
+};


For consistency with other operations structures, can we make this
struct kmem_cache_operations or kmem_cache_ops, 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: [RFC 1/3] SLUB: slab_ops instead of constructors / destructors

On Sat, 5 May 2007, Pekka Enberg wrote:

> For consistency with other operations structures, can we make this
> struct kmem_cache_operations or kmem_cache_ops, please?

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

Re: Ext3 vs NTFS performance

2007-05-05 Thread Theodore Tso

On Sat, May 05, 2007 at 11:13:36AM +0800, Xu CanHao wrote:
> On 5 Mai, 10:20, Theodore Tso <[EMAIL PROTECTED]> wrote:
> >
> >This is being worked on already.  XFS has a per-filesystem ioctl, but
> >we want to create a filesystem-independent system call,
> >sys_fallocate(), that would wired into the already existing
> >posix_fallocate() function exported by glibc.
> 
> The story told us: an application must look to the file-systems, ext3
> is good at aaa, is not good at bbb; XFS is good at ccc, is not good at
> ddd; reiserfs is good at eee, is not good at fff
> 
> For this scenario, XFS is good at dealing with fragmentation while ext3 not.

That's true.  XFS has the ability to do delayed allocations, so that
the blocks don't get allocated until they are written out.  Hence, a
workload that writes a pattern which uses random access writes in
strides of 128k, and then goes back to fill them in, will result in
fragmentation given ext3's current block reservation allocation
algorithm --- but, as long as the system isn't under high memory
pressure, XFS will do better in this particular scenario.

Actually, ext3 does have a block reservation system, which will
prevent this scenario if the random access writes are within a range
of 32k or so --- which is enough to protect against the bad effects of
more common random access write patterns, such as those used when
writing out ELF object files, for example.  Increasing
EXT3_DEFAULT_RESERVE_BLOCKS by a factor of 4 would adaopt the ext3
block reservation system to this pathalogical workload, and we could
easily add a tunable mount option to change the reservation size used
by ext3.  Unfortunately, this could make fragmentation work for other
workloads.  So adding delayed allocation to ext4 is a better solution.

But as has already been discussed on this thread, in situations where
the fileserver is under high memory pressure, any filesystem (XFS or
ext4) would still end up allocating blocks out of order, resulting in
fragmentation.  Explicit preallocation, as opposed to delayed
allocation, is really the best long-term solution; and in order to do
that, Samba needs to detect this scenario --- which as has been noted,
there appears to be no good reason for the Windows CIFS client (or any
other application)to be doing this, other than perhaps to deliberate
trigger a worst case allocation pattern in ext3 --- and translate it
into a explicit preallocation request.

Regards,

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

Re: [PATCH -mm] PM: Separate hibernation code from suspend code

On Saturday, 5 May 2007 12:16, Rafael J. Wysocki wrote:
> On Saturday, 5 May 2007 08:31, Andrew Morton wrote:
> > On Fri, 4 May 2007 11:32:31 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]> 
> > wrote:
> > 
> > > Separate the hibernation (aka suspend to disk code) from the other 
> > > suspend code.
> > > In particular:
> > >  * Remove the definitions related to hibernation from include/linux/pm.h
> > >  * Introduce struct hibernation_ops and a new hibernate() function to 
> > > hibernate
> > >the system, defined in include/linux/suspend.h
> > >  * Separate suspend code in kernel/power/main.c from hibernation-related 
> > > code
> > >in kernel/power/disk.c and kernel/power/user.c (with the help of
> > >hibernation_ops)
> > >  * Switch ACPI (the only user of pm_ops.pm_disk_mode) to hibernation_ops
> > 
> > This causes the long-suffering Vaio to fail to power off during suspend
> > to disk.  It says "Please power me down manually".
> 
> Hmm, looks like a failure of acpi_hibernation_enter().  Can you please put a
> printk() in there, after local_irq_restore()?

Anyway, we should power off the system rather than halt it if hibernation_ops
is not set.

---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>

Power off the system instead of halting it if the 'platform' mode of hibernation
has been requested, but hibernation_ops is not set.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 kernel/power/disk.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: linux-2.6.21/kernel/power/disk.c
===
--- linux-2.6.21.orig/kernel/power/disk.c   2007-05-05 12:24:33.0 
+0200
+++ linux-2.6.21/kernel/power/disk.c2007-05-05 13:51:45.0 +0200
@@ -99,9 +99,6 @@ static void power_down(void)
case HIBERNATION_TEST:
case HIBERNATION_TESTPROC:
break;
-   case HIBERNATION_SHUTDOWN:
-   kernel_power_off();
-   break;
case HIBERNATION_REBOOT:
kernel_restart(NULL);
break;
@@ -111,6 +108,9 @@ static void power_down(void)
hibernation_ops->enter();
break;
}
+   case HIBERNATION_SHUTDOWN:
+   kernel_power_off();
+   break;
}
kernel_halt();
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 -mm] PM: Separate hibernation code from suspend code

On Saturday, 5 May 2007 14:27, Johannes Berg wrote:
> On Sat, 2007-05-05 at 14:21 +0200, Rafael J. Wysocki wrote:
> > 
> > Power off the system instead of halting it if the 'platform' mode of
> > hibernation
> > has been requested, but hibernation_ops is not set. 
> 
> Ehm, unless you made a mistake in the patch then that shouldn't be
> possible.

Hmm, right, but the patch is correct nevertheless. :-)

I see where the problem is.  hibernation_mode is 0 by default
(HIBERNATION_INVALID) and it's not changed to anything else later if
defaults are used.

Something like this is necessary, I think:

---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>

Make sure that hibernation_mode is set to a reasonable value by default.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 kernel/power/disk.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

Index: linux-2.6.21/kernel/power/disk.c
===
--- linux-2.6.21.orig/kernel/power/disk.c   2007-05-05 13:51:45.0 
+0200
+++ linux-2.6.21/kernel/power/disk.c2007-05-05 15:45:23.0 +0200
@@ -30,8 +30,6 @@ char resume_file[256] = CONFIG_PM_STD_PA
 dev_t swsusp_resume_device;
 sector_t swsusp_resume_block;
 
-static int hibernation_mode;
-
 enum {
HIBERNATION_INVALID,
HIBERNATION_PLATFORM,
@@ -45,6 +43,8 @@ enum {
 #define HIBERNATION_MAX (__HIBERNATION_AFTER_LAST-1)
 #define HIBERNATION_FIRST (HIBERNATION_INVALID + 1)
 
+static int hibernation_mode = HIBERNATION_SHUTDOWN;
+
 struct hibernation_ops *hibernation_ops;
 
 /**
@@ -60,6 +60,9 @@ void hibernation_set_ops(struct hibernat
}
mutex_lock(&pm_mutex);
hibernation_ops = ops;
+   if (ops)
+   hibernation_mode = HIBERNATION_PLATFORM;
+
mutex_unlock(&pm_mutex);
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]


On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:

Antonino:

Can you try two tests (with my patch applied):

1. comment out the tty_flush_buffer() call in tty_ldisc_flush() and test

2. uncomment (reenable) the above call and comment out the
tty_flush_buffer() call in tty_ioctl() and test


I assume you meant tty_buffer_flush(). I've built kernel 1). In kernel
2), do you mean:

   /*if (ld->ioctl)
   tty_buffer_flush(tty);*/
   tty_ldisc_deref(ld);

right? This is what I'm building... I'll report these new tests soon.

While waiting for kernel building I'll document the testing procedure.
In this way someone else can easily try to reproduce the problem.

1. Hardware.

Two serial ports required. Connect the two port witth a null-modem
cable, or patch, for each port the Tx pin with the Rx of the other
port[0].

2. Software

I assume python is installed. Install also pyserial[1] (in debian
python-serial), if you manually download the package you can put the
"serial" dir in the dir you use to perform the test (no need to
install system-wide). If you can, install also the ipython shell that
has colored output and auto-completition.

3. Test


From the python shell:


   import serial
   s0 = serial.Serial(0, timeout=1)

open the /dev/ttyS0 port with default values, hit 's0' [enter] to see
the serial parameters.

   s1 = serial.Serial(1, timeout=1)

with the previous comma we open /dev/ttyS1 with the same serial port
settings. To write to one serial port:

   s0.write('test\n')

and to read use the .read() or .readline() method:

   s1.readline()

The .inWaiting() methods gives the numbers of bytes in the input
buffer. The .flushInput() method flushes the input buffer:

In [6]: s0.write('test\n')

In [7]: s1.inWaiting()
Out[7]: 5L

In [8]: s1.readline()
Out[8]: 'test\n'

In [9]: s1.inWaiting()
Out[9]: 0L

If all works, now fill one serial port with a bunch of data (an
increasing 8-digit number):

   for i in xrange(1):
   s0.write(str(i).zfill(8)+'\n')

we can see that the s1 input buffer is full:

   s1.inWaiting()
   Out[21]: 4095L

then empty the buffer and see what happens:

In [22]: s1.flushInput()
In [23]: s1.inWaiting()
Out[23]: 4095L

the buffer is still full. You have to flush the buffer more then once
to completely flush all the buffer chain (including the flip buffer).
With the patched kernel at this point I get correctly:

In [22]: s1.flushInput()
In [23]: s1.inWaiting()
Out[23]: 0L

but then I can't read any other byte from the serial without closing
and reopening it:

In [24]: s0.write('test\n')

In [25]: s1.inWaiting()
Out[25]: 0L

In [26]: s1.read()
Out[26]: ''

In [27]: s1.close()

In [28]: s1.open()

In [29]: s1.inWaiting()
Out[29]: 0L

In [30]: s0.write('test\n')

In [31]: s1.inWaiting()
Out[31]: 5L

In [32]: s1.readline()
Out[32]: 'test\n'

Hope the explanation is clear If someone else want to try...

Regards,

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

2007-05-05 Thread Maciej Rutecki

Andrew Morton pisze:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
> 
> 

CC [M]  lib/zlib_deflate/deflate_syms.o
  LD [M]  lib/zlib_deflate/zlib_deflate.o
  Building modules, stage 2.
  MODPOST 791 modules
ERROR: "ssb_pcihost_register" [drivers/net/b44.ko] undefined!
ERROR: "ssb_pcihost_unregister" [drivers/net/b44.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/usr/src/linux-mm'
make: *** [debian/stamp-build-kernel] Error 2

Config:
http://www.unixy.pl/maciek/download/kernel/2.6.21-mm1/config-2.6.21-mm1.gz

-- 
Maciej Rutecki
www.unixy.pl
Kernel Monkeys
(http://kernel.wikidot.com/)



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH] Blacklist Dell Optiplex 320 from using the HPET

2007-05-05 Thread Henrique de Moraes Holschuh

On Sat, 05 May 2007, Thomas Gleixner wrote:
> + printk(KERN_WARNING "HPET counter is defect\n");

What about
printk(KERN_WARNING "HPET counter is stopped\n");

which is far more descriptive?

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

Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]


Antonino Ingargiola wrote:

The patch now boot properly and solves
completely the testcase with two serial lines:


Good, thanks for testing.


I think this patch should be included in mainline, since if one flushes
the input buffer, really want to flush the entire buffer chain and
doesn't want to read any old data _after_ a flush.


I will submit the patch, it's clearly needed.


However I also tested a usb-serial device (that uses the cdc-acm
driver) and in this case I still need _two_ flushInput() to totally
flush the input buffer.

There can be another *secondary buffer* in the usb-serial driver? Can
this buffer be emptied out too?


Very possible, but I'm not familiar with that.

There is not an input flush method for the tty driver
and individual drivers don't process that ioctl.
The tty drivers I've seen immediately pass receive data to the
tty buffering and I'm not sure why a driver would
behave otherwise.

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

Re: [PATCH -mm] PM: Separate hibernation code from suspend code

On Saturday, 5 May 2007 08:31, Andrew Morton wrote:
> On Fri, 4 May 2007 11:32:31 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]> 
> wrote:
> 
> > Separate the hibernation (aka suspend to disk code) from the other suspend 
> > code.
> > In particular:
> >  * Remove the definitions related to hibernation from include/linux/pm.h
> >  * Introduce struct hibernation_ops and a new hibernate() function to 
> > hibernate
> >the system, defined in include/linux/suspend.h
> >  * Separate suspend code in kernel/power/main.c from hibernation-related 
> > code
> >in kernel/power/disk.c and kernel/power/user.c (with the help of
> >hibernation_ops)
> >  * Switch ACPI (the only user of pm_ops.pm_disk_mode) to hibernation_ops
> 
> This causes the long-suffering Vaio to fail to power off during suspend
> to disk.  It says "Please power me down manually".

Hmm, looks like a failure of acpi_hibernation_enter().  Can you please put a
printk() in there, after local_irq_restore()?

> 
> 
> machine_ops.halt(); points at native_machine_halt(), which is a no-op.
> 
> However `halt -p' still works OK.  How come it is not similarly affected?

'halt -p' probably uses acpi_power_off() (which calls
acpi_enter_sleep_state(ACPI_STATE_S5))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFT][PATCH] swsusp: Change code ordering related to ACPI

On Saturday, 5 May 2007 01:11, Ray Lee wrote:
> On 5/4/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > The change of the hibernation/suspend code ordering made before 2.6.21 has
> > caused some systems to have problems related to ACPI.  In particular, the
> > 'platform' hibernation mode doesn't work any more on some systems.
> 
> It seems that somewhere between 2.6.21-rc4 and 2.6.21 final my laptop
> stopped being able to come out of suspend to RAM. Before I start
> bisecting (again, sigh), is this ringing any bells for anyone? In
> particular your, patch (snipped) that deals with hibernation, would it
> also affect suspend to RAM?

Not this particular one, but you may try to move pm_finish() after
resume_console() in kernel/power/main.c:suspend_prepare() and see if that
helps.

If it doesn't help, then try to compile the kernel with NO_HZ and
HIGH_RES_TIMERS unset.  If that doesn't help, you may try with HPET_TIMER
unset additionally.

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

Re: cpufreq longhaul locks up

2007-05-05 Thread Rafał Bilski

>> Can You send output of x86info program and output of
>> lspci command? Longhaul wasn't working for You since 2.6.18 right?
> 
> Output from x86info (I know you didn't ask me, but hey, information
> wants to be free)
> 
> x86info v1.20.  Dave Jones 2001-2006
> Feedback to <[EMAIL PROTECTED]>.
> 
> Found 1 CPU
> --
> Family: 6 Model: 9 Stepping: 8
> CPU Model : VIA C3 (Nehemiah) [C5XL]
> Feature flags:
> fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse
> Extended feature flags:
Sorry. I'm asking You now. Can You send entire output?


--
NIE KUPUJ!!!
...zanim nie porownasz cen >> http://link.interia.pl/f1a5e



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

Re: cpufreq longhaul locks up

2007-05-05 Thread Rafał Bilski

> Switching from acpi_pm+performance to acpi_pm+ondemand also
> locks up after a few minutes.
 Yep. Sounds like an ondemand issue. Thanks for verifying this for me.
>>> Nah, it also happens with cpufreq_powersave. I just need to check 
>>> through some archives and try booting with governor=powersave so that it 
>>> always stays low. 
>> You have a lockup when switching from other governor to powersave? Or if  
>> You are using it for some time?
> 
> After some time.
Don't understand me wrong, but this is very weird. I think that powersave is  
changing frequency only one time, when it is loaded. I will look into its code 
to be sure. Probably Longhaul is making something what isn't allowed or there 
is hardware bug somewhere.
> Jan
Rafał



--
Po meczu.kurde...:)
>>> http://link.interia.pl/f1a72

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

Re: Back to the future.

2007-05-05 Thread Indan Zupancic

Hello,

On Sat, May 5, 2007 11:16, Pavel Machek wrote:
>> But the same functionality can be achieved by doing:
>>
>> 1) Define a user password (e.g. /etc/shadow thing). (Once)
>>
>> 2) When a user logs in: get random data and encrypt it with the password,
>> this becomes the AES key. Store both the data and key in a secure way in
>> memory, e.g. using the existing kernel key infrastructure.
>
>
>
>> Advantage of this scheme is that it only need AES and can be done (mostly)
>> in kernel space. It's also faster and simpler than the current RSA scheme.
>> Disadvantage is that it wastes at least 32 bytes of memory when the system
>> is running, to store the data and key.
>
> Another disadvantage is that you need to hack into PAM infrastructure,
> that your suspend password needs to be same as someone's login
> password, and that it will really only work with single-user machine.

The first two are only true if you want to integrate it with user login, so
that a user only needs to sign in once, which seems like a convenient thing.
But if you don't want to integrate with the existing login infrastructure,
then just don't. And those disadvantages are true for any system that wants
users to login once.

Then the disadvantage is reduced to a user needing to provide the password
at suspend if the system wasn't booted from a snapshot. But no need for
users to generate any files, just to choose a resume password.

If the resume key is stored per user instead of a single global instance, it
will work with a multi-user system too. A more interesting question is what
should happen when one user did the suspend and the other wants to resume.
Throw away the snapshot? Refuse booting? Or boot and switch "active user"?

If you don't want people to resume each other's suspends then a key per user
works. If you want them to, then it becomes a bit tricky, especially if you
don't integrate with the login system. You don't want that a user can resume
someone else's snapshot and have access to everything that other user left
open. Nor do you want users to give a password twice.

If you want users to be able to resume each other's snapshots, you probably
also want the system to switch users after the resume. No matter what scheme
is used, this becomes hairy and hard to get watertight. (Perhaps "impossible"
is more realistic: how to be able to read the suspend image and copying it
to RAM again, without having access to all data within?)

But if it's an "us" against "them" case, and you want users to resume each
other's snapshots, you're right that the scheme I proposed will fall apart.
In which case it needs to be adjusted a bit to handle this case:

Have one global suspend/resume key, and for each user store it on disk,
encrypted with that user's password. Also store the key in memory as
before. Now when the system is suspended any user needs to have provided
his password once for everyone to be able to suspend without giving a
password. Also everyone can resume, if they have access to the file with
the list of encrypted keys and provide the right password. (Notice that
this looks more like the current scheme, where the private part of the
RSA key is encrypted with a passphrase and all stored in a file.)

Though it seems that using suspend to disk on a real multi-user system is
always asking for problems, because the suspend image may contain valuable
data which shouldn't be thrown away, but easily can by other users. Nor do
you want users to claim the machine, so it's a lose/lose situation. Also
with resume every user effectively gets root access, because of all the
memory access. So inter-user security is down the drain anyway.

Only sane usage I can see is when the users trust each other, in which case
they can as well agree on one resume password. ;-)

Greetings,

Indan

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

[PATCH 1/4] ext2: remove inode constructor

From: Pekka Enberg <[EMAIL PROTECTED]>

As alloc_inode() touches the same cache line as init_once(), we gain
nothing from using slab constructors.

Cc: Stephen C. Tweedie <[EMAIL PROTECTED]>
Cc: Andreas Dilger <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
 fs/ext2/super.c |   32 +---
 1 file changed, 13 insertions(+), 19 deletions(-)

Index: 26-mm/fs/ext2/super.c
===
--- 26-mm.orig/fs/ext2/super.c  2007-05-05 12:26:15.0 +0300
+++ 26-mm/fs/ext2/super.c   2007-05-05 12:30:50.0 +0300
@@ -140,16 +140,24 @@ static struct kmem_cache * ext2_inode_ca
 static struct inode *ext2_alloc_inode(struct super_block *sb)
 {
struct ext2_inode_info *ei;
-   ei = (struct ext2_inode_info *)kmem_cache_alloc(ext2_inode_cachep,
-   GFP_KERNEL|__GFP_RECLAIMABLE);
+   struct inode *inode;
+
+   ei = kmem_cache_alloc(ext2_inode_cachep, GFP_KERNEL|__GFP_RECLAIMABLE);
if (!ei)
return NULL;
+   rwlock_init(&ei->i_meta_lock);
+#ifdef CONFIG_EXT2_FS_XATTR
+   init_rwsem(&ei->xattr_sem);
+#endif
+   mutex_init(&ei->truncate_mutex);
 #ifdef CONFIG_EXT2_FS_POSIX_ACL
ei->i_acl = EXT2_ACL_NOT_CACHED;
ei->i_default_acl = EXT2_ACL_NOT_CACHED;
 #endif
-   ei->vfs_inode.i_version = 1;
-   return &ei->vfs_inode;
+   inode = &ei->vfs_inode;
+   inode_init_once(inode);
+   inode->i_version = 1;
+   return inode;
 }
 
 static void ext2_destroy_inode(struct inode *inode)
@@ -157,27 +165,13 @@ static void ext2_destroy_inode(struct in
kmem_cache_free(ext2_inode_cachep, EXT2_I(inode));
 }
 
-static void init_once(void * foo, struct kmem_cache * cachep, unsigned long 
flags)
-{
-   struct ext2_inode_info *ei = (struct ext2_inode_info *) foo;
-
-   if (flags & SLAB_CTOR_CONSTRUCTOR) {
-   rwlock_init(&ei->i_meta_lock);
-#ifdef CONFIG_EXT2_FS_XATTR
-   init_rwsem(&ei->xattr_sem);
-#endif
-   mutex_init(&ei->truncate_mutex);
-   inode_init_once(&ei->vfs_inode);
-   }
-}
- 
 static int init_inodecache(void)
 {
ext2_inode_cachep = kmem_cache_create("ext2_inode_cache",
 sizeof(struct ext2_inode_info),
 0, (SLAB_RECLAIM_ACCOUNT|
SLAB_MEM_SPREAD),
-init_once, NULL);
+NULL, NULL);
if (ext2_inode_cachep == NULL)
return -ENOMEM;
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] ext3: remove inode constructor

From: Pekka Enberg <[EMAIL PROTECTED]>

As alloc_inode() touches the same cache line as init_once(), we gain
nothing from using slab constructors.

Cc: Stephen C. Tweedie <[EMAIL PROTECTED]>
Cc: Andreas Dilger <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
 fs/ext3/super.c |   29 -
 1 file changed, 12 insertions(+), 17 deletions(-)

Index: 26-mm/fs/ext3/super.c
===
--- 26-mm.orig/fs/ext3/super.c  2007-05-05 12:26:49.0 +0300
+++ 26-mm/fs/ext3/super.c   2007-05-05 12:27:17.0 +0300
@@ -444,17 +444,26 @@ static struct kmem_cache *ext3_inode_cac
 static struct inode *ext3_alloc_inode(struct super_block *sb)
 {
struct ext3_inode_info *ei;
+   struct inode *inode;
 
ei = kmem_cache_alloc(ext3_inode_cachep, GFP_NOFS|__GFP_RECLAIMABLE);
if (!ei)
return NULL;
+   INIT_LIST_HEAD(&ei->i_orphan);
+#ifdef CONFIG_EXT3_FS_XATTR
+   init_rwsem(&ei->xattr_sem);
+#endif
+   mutex_init(&ei->truncate_mutex);
 #ifdef CONFIG_EXT3_FS_POSIX_ACL
ei->i_acl = EXT3_ACL_NOT_CACHED;
ei->i_default_acl = EXT3_ACL_NOT_CACHED;
 #endif
ei->i_block_alloc_info = NULL;
-   ei->vfs_inode.i_version = 1;
-   return &ei->vfs_inode;
+
+   inode = &ei->vfs_inode;
+   inode_init_once(inode);
+   inode->i_version = 1;
+   return inode;
 }
 
 static void ext3_destroy_inode(struct inode *inode)
@@ -462,27 +471,13 @@ static void ext3_destroy_inode(struct in
kmem_cache_free(ext3_inode_cachep, EXT3_I(inode));
 }
 
-static void init_once(void * foo, struct kmem_cache * cachep, unsigned long 
flags)
-{
-   struct ext3_inode_info *ei = (struct ext3_inode_info *) foo;
-
-   if (flags & SLAB_CTOR_CONSTRUCTOR) {
-   INIT_LIST_HEAD(&ei->i_orphan);
-#ifdef CONFIG_EXT3_FS_XATTR
-   init_rwsem(&ei->xattr_sem);
-#endif
-   mutex_init(&ei->truncate_mutex);
-   inode_init_once(&ei->vfs_inode);
-   }
-}
-
 static int init_inodecache(void)
 {
ext3_inode_cachep = kmem_cache_create("ext3_inode_cache",
 sizeof(struct ext3_inode_info),
 0, (SLAB_RECLAIM_ACCOUNT|
SLAB_MEM_SPREAD),
-init_once, NULL);
+NULL, NULL);
if (ext3_inode_cachep == NULL)
return -ENOMEM;
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] ext4: remove inode constructor

From: Pekka Enberg <[EMAIL PROTECTED]>

As alloc_inode() touches the same cache line as init_once(), we gain
nothing from using slab constructors.

Cc: Stephen C. Tweedie <[EMAIL PROTECTED]>
Cc: Andreas Dilger <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
 fs/ext4/super.c |   28 +++-
 1 file changed, 11 insertions(+), 17 deletions(-)

Index: 26-mm/fs/ext4/super.c
===
--- 26-mm.orig/fs/ext4/super.c  2007-05-05 12:26:44.0 +0300
+++ 26-mm/fs/ext4/super.c   2007-05-05 12:28:56.0 +0300
@@ -496,16 +496,21 @@ static struct kmem_cache *ext4_inode_cac
 static struct inode *ext4_alloc_inode(struct super_block *sb)
 {
struct ext4_inode_info *ei;
+   struct inode *inode;
 
ei = kmem_cache_alloc(ext4_inode_cachep, GFP_NOFS);
if (!ei)
return NULL;
+   INIT_LIST_HEAD(&ei->i_orphan);
+#ifdef CONFIG_EXT4DEV_FS_XATTR
+   init_rwsem(&ei->xattr_sem);
+#endif
+   mutex_init(&ei->truncate_mutex);
 #ifdef CONFIG_EXT4DEV_FS_POSIX_ACL
ei->i_acl = EXT4_ACL_NOT_CACHED;
ei->i_default_acl = EXT4_ACL_NOT_CACHED;
 #endif
ei->i_block_alloc_info = NULL;
-   ei->vfs_inode.i_version = 1;
memset(&ei->i_cached_extent, 0, sizeof(struct ext4_ext_cache));
 
/* FIXME: these wb-related fields could be initialized once */
@@ -514,7 +519,10 @@ei->i_md_reserved = 0;
atomic_set(&ei->i_wb_writers, 0);
spin_lock_init(&ei->i_wb_reserved_lock);
 
-   return &ei->vfs_inode;
+   inode = &ei->vfs_inode;
+   inode_init_once(inode);
+   inode->i_version = 1;
+   return inode;
 }
 
 static void ext4_destroy_inode(struct inode *inode)
@@ -522,27 +530,13 @@ static void ext4_destroy_inode(struct in
kmem_cache_free(ext4_inode_cachep, EXT4_I(inode));
 }
 
-static void init_once(void * foo, struct kmem_cache * cachep, unsigned long 
flags)
-{
-   struct ext4_inode_info *ei = (struct ext4_inode_info *) foo;
-
-   if (flags & SLAB_CTOR_CONSTRUCTOR) {
-   INIT_LIST_HEAD(&ei->i_orphan);
-#ifdef CONFIG_EXT4DEV_FS_XATTR
-   init_rwsem(&ei->xattr_sem);
-#endif
-   mutex_init(&ei->truncate_mutex);
-   inode_init_once(&ei->vfs_inode);
-   }
-}
-
 static int init_inodecache(void)
 {
ext4_inode_cachep = kmem_cache_create("ext4_inode_cache",
 sizeof(struct ext4_inode_info),
 0, (SLAB_RECLAIM_ACCOUNT|
SLAB_MEM_SPREAD),
-init_once, NULL);
+NULL, NULL);
if (ext4_inode_cachep == NULL)
return -ENOMEM;
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] UBI: dereference after kfree in create_vtbl

On 5/5/07, Artem Bityutskiy <[EMAIL PROTECTED]> wrote:

[...]
On Sat, 2007-05-05 at 09:25 +0530, Satyam Sharma wrote:
> Artem would have to step in here to verify if there really is a good
> reason why we kmalloc a fresh ubi_scan_leb every time we want to add
> one to a list.
Particularly in vtbl.c there is no good reason. Leftover of itsy-bitsy
units. I'll make ubi_scan_add_to_list static, as well as
ubi_scan_add_used(). And I'll rename them to something shorter. They are
only useful in scan.c.

And it is fine to use list_add_tail() directly in vtbl.c. Will be fixed.

Ah, good to know that, but please keep list_add_tail (or whatever is
the implementation abstraction of the various ubi_scan_info lists)
local to scan.c -- you could expose a version of ubi_scan_add_to_list
that does not do kmalloc through scan.h and use that in vtbl.c. That
way you won't lose those debug printk's when adding an eraseblock to a
list, for example, and it's always much cleaner not exposing an
object's implementation innards to others.

> >though this likely requires a
> major cleanup of this driver w.r.t. ubi_scan_leb lifetime semantics.
What is wrong with the semantics, please be more specific.

It's wrong to be allocating and freeing any object in more than one
place . Physical eraseblocks are allocated in ubi_scan_add_to_list
(which shouldn't be doing that) and ubi_scan_add_used (which is a
maze) and freed pretty much all over the place (because we allocate
new seb's for ourselves to add to the lists, we need to go about
kfree'ing all of them when destroying a ubi_scan_destroy_si too, for
example -- perhaps this driver needs to be told about krefs). So it
makes life easier if you know there's only one place when/where an
object is born, if you know that it'll remain alive as long as you
need it and have a reference on it, and if you destroy it a known
single time/location too. I wish I could be more specific than this,
but I've only spent a few hours with ubi :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

On Sat, 2007-05-05 at 10:43 -0600, Paul Fulghum wrote:
> There is not an input flush method for the tty driver
> and individual drivers don't process that ioctl.
> The tty drivers I've seen immediately pass receive data to the
> tty buffering and I'm not sure why a driver would
> behave otherwise.

cdc-acm does its own buffering.

In your case, the line discipline throttled the tty device
because the ldisc buffer was full.

If the line discipline throttles the driver input,
the cdc-acm driver stops giving data to the tty buffering
and instead stores them internally.

In the serial driver this usually just results in dropping
RTS to signal the remote end to stop sending. The serial
driver always immediately gives receive data to the tty buffering
without regard to the throttled state.

I would argue that cdc-acm should do the same as the serial driver.

--
Paul

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

[PATCH 4/4] reiserfs: remove inode constructor

From: Pekka Enberg <[EMAIL PROTECTED]>

As alloc_inode() touches the same cache line as init_once(), we gain
nothing from using slab constructors.

Cc: <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
 fs/reiserfs/super.c |   33 ++---
 1 file changed, 14 insertions(+), 19 deletions(-)

Index: 26-mm/fs/reiserfs/super.c
===
--- 26-mm.orig/fs/reiserfs/super.c  2007-05-03 11:14:12.0 +0300
+++ 26-mm/fs/reiserfs/super.c   2007-05-05 12:34:56.0 +0300
@@ -495,12 +495,21 @@ static struct kmem_cache *reiserfs_inode
 static struct inode *reiserfs_alloc_inode(struct super_block *sb)
 {
struct reiserfs_inode_info *ei;
-   ei = (struct reiserfs_inode_info *)
-   kmem_cache_alloc(reiserfs_inode_cachep,
-   GFP_KERNEL|__GFP_RECLAIMABLE);
+   struct inode *inode;
+
+   ei = kmem_cache_alloc(reiserfs_inode_cachep,
+ GFP_KERNEL|__GFP_RECLAIMABLE);
if (!ei)
return NULL;
-   return &ei->vfs_inode;
+
+   INIT_LIST_HEAD(&ei->i_prealloc_list);
+#ifdef CONFIG_REISERFS_FS_POSIX_ACL
+   ei->i_acl_access = NULL;
+   ei->i_acl_default = NULL;
+#endif
+   inode = &ei->vfs_inode;
+   inode_init_once(inode);
+   return inode;
 }
 
 static void reiserfs_destroy_inode(struct inode *inode)
@@ -508,20 +517,6 @@ static void reiserfs_destroy_inode(struc
kmem_cache_free(reiserfs_inode_cachep, REISERFS_I(inode));
 }
 
-static void init_once(void *foo, struct kmem_cache * cachep, unsigned long 
flags)
-{
-   struct reiserfs_inode_info *ei = (struct reiserfs_inode_info *)foo;
-
-   if (flags & SLAB_CTOR_CONSTRUCTOR) {
-   INIT_LIST_HEAD(&ei->i_prealloc_list);
-   inode_init_once(&ei->vfs_inode);
-#ifdef CONFIG_REISERFS_FS_POSIX_ACL
-   ei->i_acl_access = NULL;
-   ei->i_acl_default = NULL;
-#endif
-   }
-}
-
 static int init_inodecache(void)
 {
reiserfs_inode_cachep = kmem_cache_create("reiser_inode_cache",
@@ -529,7 +524,7 @@ static int init_inodecache(void)
 reiserfs_inode_info),
  0, (SLAB_RECLAIM_ACCOUNT|
SLAB_MEM_SPREAD),
- init_once, NULL);
+ NULL, NULL);
if (reiserfs_inode_cachep == NULL)
return -ENOMEM;
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: 2.6.21-mm1

2007-05-05 Thread Gabriel C


Andrew Morton wrote:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/

  


I get a lot ' warning: 'warn_unused_result' attribute ignored ' from 
mutex.h:128


I've uploaded full build-log , config and ver_linux there -> 
http://crazy.dev.frugalware.org/2.6.21-mm1/



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

2007-05-05 Thread Pekka Enberg


On 5/5/07, Andrew Morton <[EMAIL PROTECTED]> wrote:


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/


Someone broke UML.

$ make ARCH=um defconfig
$ make

[snip]

 UPD include/linux/version.h
 CHK include/linux/utsrelease.h
 UPD include/linux/utsrelease.h
 SYMLINK include/asm -> include/asm-um
 CC  arch/um/kernel/asm-offsets.s
In file included from include/asm/cpufeature.h:4,
from include/asm/arch/system.h:6,
from include/asm/system-generic.h:4,
from include/asm/system.h:4,
from include/linux/spinlock.h:57,
from include/linux/capability.h:73,
from include/linux/sched.h:46,
from arch/um/include/sysdep/kernel-offsets.h:2,
from arch/um/kernel/asm-offsets.c:1:
include/asm/arch/cpufeature.h:13:35: error: asm/required-features.h:
No such file or directory
make[1]: *** [arch/um/kernel/asm-offsets.s] Error 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -mm] PM: Separate hibernation code from suspend code

2007-05-05 Thread Johannes Berg

On Sat, 2007-05-05 at 14:21 +0200, Rafael J. Wysocki wrote:
> 
> Power off the system instead of halting it if the 'platform' mode of
> hibernation
> has been requested, but hibernation_ops is not set. 

Ehm, unless you made a mistake in the patch then that shouldn't be
possible.

johannes


signature.asc
Description: This is a digitally signed message part

Re: [patch 25/29] xen: Add the Xen virtual network device driver.

2007-05-05 Thread Rusty Russell

On Sat, 2007-05-05 at 10:16 +0100, Christoph Hellwig wrote:
> I wish people would have listened to me back then and made the
> description part of the modular_param statement..

Sometimes we weary of change.  However, come up with a decent name and
implement it and we can deprecate module_param() by say... 2012?

Cheers,
Rusty.


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

Re: [PATCH 3/8] Universal power supply class (was: battery class)

2007-05-05 Thread Anton Vorontsov

Hello Henrique, Shem,

On Sat, May 05, 2007 at 12:54:13AM -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 04 May 2007, Shem Multinymous wrote:
> > >+enum power_supply_type {
> > >+   POWER_SUPPLY_TYPE_BATTERY = 0,
> > >+   POWER_SUPPLY_TYPE_UPS,
> > >+   POWER_SUPPLY_TYPE_AC,
> > >+   POWER_SUPPLY_TYPE_USB,
> > >+};
> > 
> > How about dumb (non-USB) DC power? Any reason to distinguish it from AC?
> 
> Hmm, if it should not be distinguished, it is better to rename AC to
> something that means continuous power.  But I'd rather have it AC and DC, as
> something might have both supplies separate, and you might want to
> differentiate them for some (human interface) reason.  After all, USB and DC
> are not really different anyway...
> 
> Anyway, what IS the difference between UPS and battery, or UPS and AC/DC for
> that matter?  When should UPS be used?  If you have UPS there, should not
> MGG (motor-generator group) also be provided?
> 
> Given that USB-power *is* usually also "dumb" (i.e. it doesn't do any
> control signaling over the USB bus for power-control purposes), IMHO it
> might be better to have just battery, AC and DC as types.  And a primary and
> secondary notion too, as that is common.  It would be generic.
> 
> Or maybe I just didn't get the idea behind the "type" attribute :-)
> 
> I'd appreciate if these were documented in the text file.

I think I got the start point of confusion. It's indeed bad to call such
power supply type as AC. Maybe I should it rename to ADAPTER? Or WALL?

type, is really `type' of power supply: imagine icon GUI application will
use for different types. Type is not alternating/direct current stuff,
it will be better to impelemnt `current_type' attribute for such matter.

As for Battery/UPS difference.. yes, they're quite similar.. but again,
imagine laptop with battery, and connected to UPS. ;-) How userspace
will differ internal battery from UPS? Yup, by type attribute. I hope
it makes sense... If not, we simply can remove UPS type.


And again, much thanks for your review and ideas!

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.org/bd2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] synclink_gt add compat_ioctl


Arnd Bergmann wrote:

On Friday 04 May 2007, Paul Fulghum wrote:

- It is fishy that apart from one outlier in kexec.h, synclink.h is the
  only header file which uses compat_ulong_t.  Are we doing this right?

Arnd, do you have any comment on this?


I think most others just define the compat data structures in the
same file that implements the headers, inside the same #ifdef that
hides the functions using them.
This makes sense, because the data structures here don't define
an interface, but rather describe what the interface looks like
in the 32 bit case.


OK, moving the compatible structure declarations from the header
to the individual source files will fix all the header mess and
the odd compilation errors on i386 when using the compat.h header
inside of another header.

That declaration will need to be duplicated in each driver that
uses it (4 drivers in my case). In that sense (a structure declaration
used by multiple code modules) it does seem like an interface definition.

If that is what is needed, I will do it.

--
Paul

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

Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

On Fri, 2007-05-04 at 17:30 -0600, Paul Fulghum wrote:
> OK, this behavior is so unexpected I must be missing
> something basic.

And so I was. Try this patch.

--- a/drivers/char/tty_io.c 2007-05-04 05:46:55.0 -0500
+++ b/drivers/char/tty_io.c 2007-05-05 03:23:46.0 -0500
@@ -365,6 +365,29 @@ static void tty_buffer_free(struct tty_s
 }
 
 /**
+ * tty_buffer_flush-   flush full tty buffers
+ * @tty: tty to flush
+ *
+ * flush all the buffers containing receive data
+ *
+ * Locking: none
+ */
+
+static void tty_buffer_flush(struct tty_struct *tty)
+{
+   struct tty_buffer *thead;
+   unsigned long flags;
+
+   spin_lock_irqsave(&tty->buf.lock, flags);
+   while((thead = tty->buf.head) != NULL) {
+   tty->buf.head = thead->next;
+   tty_buffer_free(tty, thead);
+   }
+   tty->buf.tail = NULL;
+   spin_unlock_irqrestore(&tty->buf.lock, flags);
+}
+
+/**
  * tty_buffer_find -   find a free tty buffer
  * @tty: tty owning the buffer
  * @size: characters wanted
@@ -1240,6 +1263,7 @@ void tty_ldisc_flush(struct tty_struct *
ld->flush_buffer(tty);
tty_ldisc_deref(ld);
}
+   tty_buffer_flush(tty);
 }
 
 EXPORT_SYMBOL_GPL(tty_ldisc_flush);
@@ -3336,6 +3360,15 @@ int tty_ioctl(struct inode * inode, stru
case TIOCMBIC:
case TIOCMBIS:
return tty_tiocmset(tty, file, cmd, p);
+   case TCFLSH:
+   switch (arg) {
+   case TCIFLUSH:
+   case TCIOFLUSH:
+   /* flush tty buffer and allow ldisc to process 
ioctl */
+   tty_buffer_flush(tty);
+   break;
+   }
+   break;
}
if (tty->driver->ioctl) {
retval = (tty->driver->ioctl)(tty, file, cmd, arg);


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

Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

On Sat, 2007-05-05 at 11:08 -0500, Paul Fulghum wrote:
> I would argue that cdc-acm should do the same as the serial driver.

Try this patch for the usb ports. (I don't have that hardware)

--- a/drivers/usb/class/cdc-acm.c   2007-04-25 22:08:32.0 -0500
+++ b/drivers/usb/class/cdc-acm.c   2007-05-05 11:12:10.0 -0500
@@ -355,18 +355,9 @@ next_buffer:
spin_lock_irqsave(&acm->throttle_lock, flags);
throttled = acm->throttle;
spin_unlock_irqrestore(&acm->throttle_lock, flags);
-   if (!throttled)
-   tty_insert_flip_string(tty, buf->base, buf->size);
+   tty_insert_flip_string(tty, buf->base, buf->size);
tty_flip_buffer_push(tty);
 
-   if (throttled) {
-   dbg("Throttling noticed");
-   spin_lock_irqsave(&acm->read_lock, flags);
-   list_add(&buf->list, &acm->filled_read_bufs);
-   spin_unlock_irqrestore(&acm->read_lock, flags);
-   return;
-   }
-
spin_lock_irqsave(&acm->read_lock, flags);
list_add(&buf->list, &acm->spare_read_bufs);
spin_unlock_irqrestore(&acm->read_lock, flags);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] UBI: dereference after kfree in create_vtbl

On Sat, 2007-05-05 at 19:02 +0530, Satyam Sharma wrote:
> > write_error:
> > if (err == -EIO && ++tries <= 5) {
> > /*
> >  * Probably this physical eraseblock went bad, try to pick
> >  * another one.
> >  */
> > list_add_tail(&new_seb->u.list, &si->corr);
> > goto retry;
> > }
> > kfree(new_seb);
> > out_free:
> > ubi_free_vid_hdr(ubi, vid_hdr);
> > return err;
> 
> Ummm ...
> 
> 1. "if (err == -EIO)" applies to adding new_seb to the corrupted list,
> and not to retrying. We wouldn't want _not_ to retry if there's some
> other error, or would we?

In case of other error - no, we do not want to retry. Only in case of
-EIO because we just might have hit a new badblock, which is unlikely,
but possible.

If it is anything else then -EIO, then we just return an error and
_refuse_ to attach this MTD device. In this case it does not matter
where we add new_seb. We just drop it. We free all allocated data
structures.

> 2. "if (++tries <= 5)" applies to "goto retry" and not to adding
> new_seb to the corrupted list. If we hit write failure for the 5th
> time and err == -EIO, we should still be adding it to corrupted list,
> but not retry, of course. Otherwise we would add the first 4 write
> failure (with -EIO) eraseblocks to si->corr, but the 5th _similar_
> case is ... just freed?

If we hit -EIO more then five times, there is probably something _really
bad_ with this MTD device and we _refuse_ attaching it. We return error,
and every data structure is freed. It does not matter if we add new_seb
anywhere or not. It is anyway just freed.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] UBI: dereference after kfree in create_vtbl

On Sat, 2007-05-05 at 09:25 +0530, Satyam Sharma wrote:
> Again, I saw that too, but would still prefer using the higher level
> function ubi_scan_add_to_list() to add to the corrupted list, but with
> a different identifier for the return value to avoid overwriting err.
> list_add_tail seems best left as an implementation detail below
> ubi_scan_add_to_list(), IMO. So if it fails in the error path, we'd
> have to return with the original (write error) return value and the
> ENOMEM sort of goes ... unreturned. Alas!

I've put the fix here:
http://git.infradead.org/?p=users/dedekind/ubi-2.6.git;a=commit;h=5125237efb6a3309fbf5b9a7a21aaf716787f2a2

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

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

Re: cpufreq longhaul locks up

2007-05-05 Thread Rafał Bilski

>> Can You send output of x86info program and output of 
> 
> Where do I find this?

http://www.codemonkey.org.uk/projects/x86info/
It needs msr device support in kernel.


--
NIE KUPUJ!!!
...zanim nie porownasz cen >> http://link.interia.pl/f1a5e



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

git-tree compilation error "pci_module_init" [drivers/scsi/tmscsim.ko] undefined!

2007-05-05 Thread art


pull 20070505 0830 UTC-06
...
scripts/kconfig/gconf arch/x86_64/Kconfig
drivers/net/Kconfig:2279:warning: 'select' used by config symbol  
'UCC_GETH' refer to undefined symbol 'UCC_FAST'
drivers/input/keyboard/Kconfig:170:warning: 'select' used by config  
symbol 'KEYBOARD_ATARI' refer to undefined symbol 'ATARI_KBD_CORE'
drivers/input/mouse/Kconfig:161:warning: 'select' used by config  
symbol 'MOUSE_ATARI' refer to undefined symbol 'ATARI_KBD_CORE'

  CHK include/linux/version.h
  CHK include/linux/utsrelease.h
  CHK include/linux/compile.h
  MODPOST vmlinux
  Building modules, stage 2.
Kernel: arch/x86_64/boot/bzImage is ready  (#113)
  MODPOST 1234 modules
WARNING: "pci_module_init" [drivers/scsi/tmscsim.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2


xboom

[EMAIL PROTECTED]

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

Re: [patch 25/29] xen: Add the Xen virtual network device driver.

2007-05-05 Thread Jeremy Fitzhardinge

Christoph Hellwig wrote:
> There only seems to be a module description but no actual paramter for
> this.  I wish people would have listened to me back then and made the
> description part of the modular_param statement..
>   

Uh, what did I miss?  Oh, I see, I need a module_param(rx_mode, int,
0600) or something?  Or maybe with a callback if we can change it on the
fly?  And enum type?  Or maybe I string?

I'll sort it out.

>> +
>> +#define RX_COPY_THRESHOLD 256
>> +
>> +#define GRANT_INVALID_REF   0
>> +
>> +#define NET_TX_RING_SIZE __RING_SIZE((struct xen_netif_tx_sring *)0, 
>> PAGE_SIZE)
>> +#define NET_RX_RING_SIZE __RING_SIZE((struct xen_netif_rx_sring *)0, 
>> PAGE_SIZE)
>> 
>
> __RING_SIZE is not in my tree, so it seems to be some kind of Xen
> addition.  Can you make that clear in the name and give it a less
> awkware calling convention, e.g. only pass in the type, not a null
> pointer of the given type?
>   

Yeah.  The Xen ring stuff is a bit full of magic macros, so I was going
to look at inlineizing/re-namespacing it in a separate patch.

>> +/*
>> + * Implement our own carrier flag: the network stack's version causes delays
>> + * when the carrier is re-enabled (in particular, dev_activate() may not
>> + * immediately be called, which can cause packet loss).
>> + */
>> +#define netfront_carrier_on(netif)  ((netif)->carrier = 1)
>> +#define netfront_carrier_off(netif) ((netif)->carrier = 0)
>> +#define netfront_carrier_ok(netif)  ((netif)->carrier)
>> 
>
> This doesn't implement my review suggestion despite you ACKing
> them.  Didn't you like it in the end or did you simply forget
> about it?
>   

Sorry, I forgot about it.  I was waiting to hear back from network
people about what this is actually for, and whether we really need it. 
Rusty said in his review:
> Well, you only call netfront_carrier_on() from one place, so it's pretty
> easy to do "netif_carrier_on(); dev_activate();" there.
>
> I don't think this is critical though.
>   

It wasn't obvious to me whether this meant that we could avoid having a
netfront-private carrier flag but still get quick response by using
"netif_carrier_on(); dev_activate();".

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

PATCH : tuner-simple.c add suport for SECAM-BG with FI1216MF

2007-05-05 Thread matthieu castet


Hi,

this patch allow to use SECAM-BG with the FI1216MF tuner.


Matthieu

allow to use SECAM-BG with the FI1216MF tuner.

The selection is done with the secam=B module argument.
The default behaviour should be the same as before.

Signed-off-by: Matthieu CASTET <[EMAIL PROTECTED]>
Index: linux-2.6.21/drivers/media/video/tuner-simple.c
===
--- linux-2.6.21.orig/drivers/media/video/tuner-simple.c2007-05-05 
14:21:56.0 +0200
+++ linux-2.6.21/drivers/media/video/tuner-simple.c 2007-05-05 
14:33:58.0 +0200
@@ -205,9 +205,13 @@
/* 0x01 -> ??? no change ??? */
/* 0x02 -> PAL BDGHI / SECAM L */
/* 0x04 -> ??? PAL others / SECAM others ??? */
-   cb &= ~0x02;
-   if (t->std & V4L2_STD_SECAM)
-   cb |= 0x02;
+   cb &= ~0x03;
+   if (t->std & V4L2_STD_SECAM_L) //also valid for V4L2_STD_SECAM 
+   cb |= PHILIPS_MF_SET_PAL_L;
+   else if (t->std & V4L2_STD_SECAM_LC) 
+   cb |= PHILIPS_MF_SET_PAL_L2;
+   else /* V4L2_STD_B|V4L2_STD_GH */
+   cb |= PHILIPS_MF_SET_BG;
break;
 
case TUNER_TEMIC_4046FM5:

Re: [patch 3/3] clockevents: Fix resume logic

2007-05-05 Thread Ingo Molnar


* Andrew Morton <[EMAIL PROTECTED]> wrote:

> > Fixup the existing users.
> 
> This one makes the Vaio-of-fun hang during suspend to disk.  It gets 
> up to "swsusp: critical section/: done (%d pages copied)" then it 
> freezes.

after trying to reproduce it on 2 boxes without success it did trigger 
some sw-suspend weirdness on a third box :) We are debugging it now.

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

Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]


2007/5/5, Paul Fulghum <[EMAIL PROTECTED]>:

On Sat, 2007-05-05 at 11:08 -0500, Paul Fulghum wrote:
> I would argue that cdc-acm should do the same as the serial driver.

Try this patch for the usb ports. (I don't have that hardware)


Building... thanks.

The HW is a cypress demo-board for their micro-controllers with an USB
interface. Linux had recognized it as a cdc_acm modem, but it's only a
very simple serial device that can stream data on request.

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

Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

2007-05-05 Thread Alan Cox

> In the serial driver this usually just results in dropping
> RTS to signal the remote end to stop sending. The serial
> driver always immediately gives receive data to the tty buffering
> without regard to the throttled state.
> 
> I would argue that cdc-acm should do the same as the serial driver.

This is a bug in cdc-acm really. It should not double buffer, but to be
fair to the authors prior to the new tty buffering it *had* to do this.

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/

[-mm patch] mutex.h bogus __must_check (was Re: 2.6.21-mm1)

2007-05-05 Thread Frederik Deweerdt

On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
> 
__must_check was added to mutex_lock_nested() which returns void. This
causes the following warnings:
include/linux/mutex.h:128: warning: 'warn_unused_result' attribute ignored

This was introduced by
broken-out/mutex_lock_interruptible-add-__must_check.patch

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 616500e..85e4225 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -124,8 +124,8 @@ extern void fastcall mutex_lock(struct mutex *lock);
 extern int fastcall mutex_lock_interruptible(struct mutex *lock);
 
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
-extern void __must_check mutex_lock_nested(struct mutex *lock,
-   unsigned int subclass);
+extern void mutex_lock_nested(struct mutex *lock,
+ unsigned int subclass);
 extern int __must_check mutex_lock_interruptible_nested(struct mutex *lock,
unsigned int subclass);
 #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/

DC390: replace pci_module_init in dc390_module_init

2007-05-05 Thread Niklas Steinkamp


Hi,

while compiling the DC930 SCSI driver, i got this message:

drivers/built-in.o: In function `dc390_module_init':
tmscsim.c:(.init.text+0x124c4): undefined reference to `pci_module_init'
make: *** [.tmp_vmlinux1] Fehler 1

so i replaced "pci_module_init" with "pci_register_device"
and it works just fine.
--

diff --git a/drivers/scsi/tmscsim.c b/drivers/scsi/tmscsim.c
index a583e89..3158949 100644
--- a/drivers/scsi/tmscsim.c
+++ b/drivers/scsi/tmscsim.c
@@ -2680,7 +2680,7 @@ static int __init dc390_module_init(void)
printk (KERN_INFO "DC390: Using safe settings.\n");
}

-   return pci_module_init(&dc390_driver);
+   return pci_register_driver(&dc390_driver);
 }

 static void __exit dc390_module_exit(void)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.21-mm1

2007-05-05 Thread Gabriel C


Andrew Morton wrote:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/

  

Some warnings again on i386.

...

scripts/kconfig/mconf arch/i386/Kconfig
drivers/macintosh/Kconfig:116:warning: 'select' used by config symbol 
'PMAC_APM_EMU' refers to undefined symbol 'SYS_SUPPORTS_APM_EMULATION'
drivers/net/Kconfig:2336:warning: 'select' used by config symbol 
'UCC_GETH' refers to undefined symbol 'UCC_FAST'


...


Gabriel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fix fs/nfs/nfsroot.c compile error

2007-05-05 Thread Adrian Bunk

On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.21-rc7-mm2:
>...
>  git-net.patch
>...
>  git trees
>...

match_table_t was made "const" and gcc doesn't like "const __initdata":

<--  snip  -->

...
  CC  fs/nfs/nfsroot.o
/home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/nfs/nfsroot.c:131: error: 
tokens causes a section type conflict
make[3]: *** [fs/nfs/nfsroot.o] Error 1

<--  snip  -->

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

BTW: Why is this change to include/linux/parser.h in the net tree?

--- linux-2.6.21-mm1/fs/nfs/nfsroot.c.old   2007-05-05 18:36:26.0 
+0200
+++ linux-2.6.21-mm1/fs/nfs/nfsroot.c   2007-05-05 18:36:44.0 +0200
@@ -128,7 +128,7 @@
Opt_err
 };
 
-static match_table_t __initdata tokens = {
+static match_table_t tokens = {
{Opt_port, "port=%u"},
{Opt_rsize, "rsize=%u"},
{Opt_wsize, "wsize=%u"},
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-discuss] Re: [PATCH 3/8] Universal power supply class (was: battery class)

2007-05-05 Thread Damien Tournoud


Paul Sokolovsky wrote:

There's actually a nice and terse term for that - mains,
but I wonder how well non-English speaking people are familiar with it
(I personally saw them only in manuals, which, as well known, nobody
reads).


I, for one, wasn't :)

My 2 cents: ADAPTER seems better than AC, which is, as you pointed out, 
technically incorrect.


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

Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

2007-05-05 Thread Oliver Neukum

Am Samstag, 5. Mai 2007 18:08 schrieb Paul Fulghum:

> If the line discipline throttles the driver input,
> the cdc-acm driver stops giving data to the tty buffering
> and instead stores them internally.

So do usb serial drivers.

> In the serial driver this usually just results in dropping
> RTS to signal the remote end to stop sending. The serial

This may take considerable time in the case of usb devices.

> driver always immediately gives receive data to the tty buffering
> without regard to the throttled state.
> 
> I would argue that cdc-acm should do the same as the serial driver.

Has this been tested?
If so we could reduce the complexity of the throtteling logic in the usb
drivers.

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

Re: [PATCH 0/2] Add percpu smp cacheline align section

On Fri, 4 May 2007, Fenghua Yu wrote:

> This is follow-up for Suresh's runqueue align in smp patch at:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0704.1/0340.html
> 
> The patches place all of smp cacheline aligned percpu data into 
> .data.percpu.cacheline_aligned_in_smp. Other percpu data is still in 
> data.percpu section. The patches can reduce cache line access in SMP and 
> reduce alignment gap waste. The patches also define PERCPU macro for 
> vmlinux.lds.S for code clean up.

Ummm... The per cpu area is for exclusive use of a particular processor. 
If there is contention in the per cpu area then a data object needs to be 
removed from the per cpu area because the object is *not* accessed only 
from a certain cpu.

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

[PATCH 1/2] ATA: sata_promise, do not freeze ports

2007-05-05 Thread Jiri Slaby

If no objections, here comes the revert of the return 1 issue.

--

sata_promise, do not freeze ports

revert return 1 thing in the error isr, that causes port freezing, so that the
system is unusable when exception is thrown.

See http://lkml.org/lkml/2007/4/30/268

Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Mikael Pettersson <[EMAIL PROTECTED]>
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>

---
commit a38d21f4b5d5029b0b083fe2651e78c7657fda3b
tree 0a2019a34227906bc5fb0e60d90cc7f4759ee934
parent b5c1fc64195b18d3919bfa7dddfb76e9f2a05786
author Jiri Slaby <[EMAIL PROTECTED]> Sat, 05 May 2007 16:43:22 +0200
committer Jiri Slaby <[EMAIL PROTECTED]> Sat, 05 May 2007 16:43:22 +0200

 drivers/ata/sata_promise.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/ata/sata_promise.c b/drivers/ata/sata_promise.c
index f56549b..a0024ae 100644
--- a/drivers/ata/sata_promise.c
+++ b/drivers/ata/sata_promise.c
@@ -668,10 +668,8 @@ static inline unsigned int pdc_host_intr( struct ata_port 
*ap,
else
err_mask &= ~PDC2_ERR_MASK;
port_status = readl(port_mmio + PDC_GLOBAL_CTL);
-   if (unlikely(port_status & err_mask)) {
+   if (unlikely(port_status & err_mask))
pdc_error_intr(ap, qc, port_status, err_mask);
-   return 1;
-   }
 
switch (qc->tf.protocol) {
case ATA_PROT_DMA:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] V4L2: videodev, allow debugging

2007-05-05 Thread Jiri Slaby

videodev, allow debugging

fix typo? in videodev.c to allow debugging

Cc: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>

---
commit 94b6ccaf1ca50632014202d3eeb99a0e23185ddb
tree 55e2ac37ca4e12846d851b863b620b154e9df500
parent a38d21f4b5d5029b0b083fe2651e78c7657fda3b
author Jiri Slaby <[EMAIL PROTECTED]> Sat, 05 May 2007 16:44:18 +0200
committer Jiri Slaby <[EMAIL PROTECTED]> Sat, 05 May 2007 16:44:18 +0200

 drivers/media/video/videodev.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/videodev.c b/drivers/media/video/videodev.c
index 5263b50..a3cef80 100644
--- a/drivers/media/video/videodev.c
+++ b/drivers/media/video/videodev.c
@@ -433,7 +433,7 @@ static int __video_do_ioctl(struct inode *inode, struct 
file *file,
int  ret = -EINVAL;
 
if ( (vfd->debug & V4L2_DEBUG_IOCTL) &&
-   !(vfd->debug | V4L2_DEBUG_IOCTL_ARG)) {
+   !(vfd->debug & V4L2_DEBUG_IOCTL_ARG)) {
v4l_print_ioctl(vfd->name, cmd);
}
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

2007-05-05 Thread Oliver Neukum

Am Samstag, 5. Mai 2007 18:36 schrieb Alan Cox:
> > In the serial driver this usually just results in dropping
> > RTS to signal the remote end to stop sending. The serial
> > driver always immediately gives receive data to the tty buffering
> > without regard to the throttled state.
> > 
> > I would argue that cdc-acm should do the same as the serial driver.
> 
> This is a bug in cdc-acm really. It should not double buffer, but to be
> fair to the authors prior to the new tty buffering it *had* to do this.

I assume this applies to all serial drivers in the wider sense?

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

Re: [linux-cifs-client] Re: [PATCH] CIFS: make sec=none force an anonymous mount

2007-05-05 Thread Jeff Layton

On Sat, May 05, 2007 at 05:41:35AM -0500, Shirish S Pargaonkar wrote:
> 
> When a session setup request is sent as an anonymous user (NUL user),
> should/could there be
> password associated with that?
> Right now, sec=none option, will prompt you for a password.

We should probably turn off password prompting if sec=none is specified.

> And when we add code to retry session setup as anonymous user if the first
> session setup request
> fails, should that retry request be sent with the password or without
> password?
> 
> When smbfs sends requests as an anonymous user, it does not send a password
> along with it.
> 

I'd say we'd want to avoid sending along the password in any situation where
it wasn't really needed.

-- Jeff

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

Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

On Sat, 2007-05-05 at 18:46 +0200, Oliver Neukum wrote:
> Am Samstag, 5. Mai 2007 18:08 schrieb Paul Fulghum:
> > I would argue that cdc-acm should do the same as the serial driver.
> 
> Has this been tested?
> If so we could reduce the complexity of the throtteling logic in the usb
> drivers.

Antonino is doing so now.

I think Alan nailed it: with the old tty buffering the extra
logic was required to avoid data loss. The new tty buffering
handles large blocks of data with no problem.

Removing this part of the throttle logic makes
the input flushing mechanism complete.

--
Paul

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

Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]