[2.6 patch] kernel/resource.c: make resource_op static

[Adrian Bunk]

This patch makes resource_op static.

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

---

This patch was already sent on:
- 12 Dec 2004

--- linux-2.6.10-rc2-mm4-full/kernel/resource.c.old 2004-12-12 
03:15:10.0 +0100
+++ linux-2.6.10-rc2-mm4-full/kernel/resource.c 2004-12-12 03:15:20.0 
+0100
@@ -91,7 +91,7 @@
return 0;
 }
 
-struct seq_operations resource_op = {
+static struct seq_operations resource_op = {
.start  = r_start,
.next   = r_next,
.stop   = r_stop,

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

[2.6 patch] kernel/sys.c: make some code static

[Adrian Bunk]

This patch makes some needlessly global code static.

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

---

 kernel/signal.c |2 --
 kernel/sys.c|4 ++--
 2 files changed, 2 insertions(+), 4 deletions(-)

This patch was already sent on:
- 12 Dec 2004

--- linux-2.6.10-rc2-mm4-full/kernel/sys.c.old  2004-12-12 03:18:40.0 
+0100
+++ linux-2.6.10-rc2-mm4-full/kernel/sys.c  2004-12-12 03:19:19.0 
+0100
@@ -90,7 +90,7 @@
  */
 
 static struct notifier_block *reboot_notifier_list;
-DEFINE_RWLOCK(notifier_lock);
+static DEFINE_RWLOCK(notifier_lock);
 
 /**
  * notifier_chain_register - Add notifier to a notifier chain
@@ -1544,7 +1544,7 @@
  * given child after it's reaped, or none so this sample is before reaping.
  */
 
-void k_getrusage(struct task_struct *p, int who, struct rusage *r)
+static void k_getrusage(struct task_struct *p, int who, struct rusage *r)
 {
struct task_struct *t;
unsigned long flags;
--- linux-2.6.10-rc2-mm4-full/kernel/signal.c.old   2004-12-12 
03:18:25.0 +0100
+++ linux-2.6.10-rc2-mm4-full/kernel/signal.c   2004-12-12 03:18:32.0 
+0100
@@ -27,8 +27,6 @@
 #include 
 #include 
 
-extern void k_getrusage(struct task_struct *, int, struct rusage *);
-
 /*
  * SLAB caches for signal bits.
  */

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

[PATCH] Prevent NMI oopser

[Vasily Averin]

Marcello, Andrey
I believe this patch is wrong.
First, it prevent nothing: NMI watchdog is a signal that you wait too 
long with disabled interrupts. Your controller was not answered too 
long, obviously it is a hardware issue.
Second, you could not call schedule() with io_request_lock spinlock taken.

You should unlock io_request_lock before msleep, like in latest versions 
of megaraid2 drivers.

Please fix it.
Thank you,
 Vasily Averin, SWSoft Linux Kernel Team
# ChangeSet
#   2005/01/19 14:16:32-02:00 [EMAIL PROTECTED]
#   [PATCH] Prevent NMI oopser from triggering when megaraid2 waits
#   for abort/reset cmd completion
#
#   > We should backport msleep() in 2.4.29-pre1.
#
#   Ok, msleep() backported, but driver isn't fixed. This patch
#   acceptable?
#
#   Prevent NMI oopser kill kernel thread when megaraid2 driver waiting
#   abort or reset command completion.
#
#   Signed-off-by: Andrey Melnikov <[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/

[2.6 patch] OSS sb_card.c: no need to include mca.h

[Adrian Bunk]

I didn't find any reason why this file includes mca.h .
Paul Laufer already ACK'ed this patch.

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

---

This patch was already sent on:
- 1 Dec 2004

--- linux-2.6.10-rc2-mm4-full/sound/oss/sb_card.c.old   2004-12-01 
08:17:23.0 +0100
+++ linux-2.6.10-rc2-mm4-full/sound/oss/sb_card.c   2004-12-01 
08:17:28.0 +0100
@@ -26,9 +26,6 @@
 #include 
 #include 
 #include 
-#ifdef CONFIG_MCA
-#include 
-#endif /* CONFIG_MCA */
 #include "sound_config.h"
 #include "sb_mixer.h"
 #include "sb.h"

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

Re: [RFC][PATCH] new timeofday core subsystem (v. A2)

[Ulrich Windl]

On 24 Jan 2005 at 15:24, Christoph Lameter wrote:

> On Mon, 24 Jan 2005, john stultz wrote:
> 
> > +/* __monotonic_clock():
> > + * private function, must hold system_time_lock lock when being
> > + * called. Returns the monotonically increasing number of
> > + * nanoseconds since the system booted (adjusted by NTP 
> > scaling)
> > + */
> > +static nsec_t __monotonic_clock(void)
> > +{
> > +   nsec_t ret, ns_offset;
> > +   cycle_t now, delta;
> > +
> > +   /* read timesource */
> > +   now = read_timesource(timesource);
> > +
> > +   /* calculate the delta since the last clock_interrupt */
> > +   delta = (now - offset_base) & timesource->mask;
> > +
> > +   /* convert to nanoseconds */
> > +   ns_offset = cyc2ns(timesource, delta, NULL);
> > +
> > +   /* apply the NTP scaling */
> > +   ns_offset = ntp_scale(ns_offset);
> 
> The monotonic clock is the time base for the gettime and gettimeofday
> functions. This means ntp_scale() is called every time that the kernel or
> an application access time.

It depends on what you want: There is little sense in implementing a nanosecond 
clock model with NTP when the result is wrong by several microseconds IMHO. You 
don't know what the time is used for, so just get the best you can. Thos only 
wanting some crude time, could be happy with the jiffies (or their equivalent), 
right?

Regards,
Ulrich

> 
> As pointed out before this will dramatically worsen the performance
> compared to the current code base.
> 
> ntp_scale() also will make it difficult to implement optimized arch
> specific version of function for timer access.
> 
> The fastcalls would have to be disabled on ia64 to make this work. Its
> likely extremely difficult to implement a fastcall if it involves
> ntp_scale().
> 


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

i8042 access timings

[Dmitry Torokhov]

Hi,

Recently there was a patch from Alan regarding access timing violations
in i8042. It made me curious as we only wait between accesses to status
register but not data register. I peeked into FreeBSD code and they use
delays to access both registers and I wonder if that's the piece that
makes i8042 mysteriously fail on some boards.

Anyway, regardless of whether access to data register should be done with
delay as well there seem to be another timing access violation - in
i8042_command we do i8042_wait_read which reads STR and then immediately
do i8042_read_status to check AUXDATA bit.

Does the patch below makes any sense?

-- 
Dmitry

= drivers/input/serio/i8042.c 1.79 vs edited =
--- 1.79/drivers/input/serio/i8042.c2005-01-25 00:54:50 -05:00
+++ edited/drivers/input/serio/i8042.c  2005-01-25 02:04:56 -05:00
@@ -137,8 +137,8 @@
 static int i8042_wait_read(void)
 {
int i = 0;
-   while ((~i8042_read_status() & I8042_STR_OBF) && (i < 
I8042_CTL_TIMEOUT)) {
-   udelay(50);
+   while ((~i8042_read_status() & I8042_STR_OBF) && i < I8042_CTL_TIMEOUT) 
{
+   udelay(I8042_STR_DELAY);
i++;
}
return -(i == I8042_CTL_TIMEOUT);
@@ -147,8 +147,8 @@
 static int i8042_wait_write(void)
 {
int i = 0;
-   while ((i8042_read_status() & I8042_STR_IBF) && (i < 
I8042_CTL_TIMEOUT)) {
-   udelay(50);
+   while ((i8042_read_status() & I8042_STR_IBF) && i < I8042_CTL_TIMEOUT) {
+   udelay(I8042_STR_DELAY);
i++;
}
return -(i == I8042_CTL_TIMEOUT);
@@ -162,17 +162,20 @@
 static int i8042_flush(void)
 {
unsigned long flags;
-   unsigned char data;
+   unsigned char str, data;
int i = 0;
 
spin_lock_irqsave(_lock, flags);
 
-   while ((i8042_read_status() & I8042_STR_OBF) && (i++ < 
I8042_BUFFER_SIZE)) {
-   udelay(50);
+   do {
+   str = i8042_read_status();
+   if (~str & I8042_STR_OBF)
+   break;
+   udelay(I8042_DATA_DELAY);
data = i8042_read_data();
-   dbg("%02x <- i8042 (flush, %s)", data,
-   i8042_read_status() & I8042_STR_AUXDATA ? "aux" : 
"kbd");
-   }
+   dbg("%02x <- i8042 (flush, %s)", data, str & I8042_STR_AUXDATA 
? "aux" : "kbd");
+   udelay(I8042_STR_DELAY);
+   } while (i++ < I8042_BUFFER_SIZE);
 
spin_unlock_irqrestore(_lock, flags);
 
@@ -190,6 +193,7 @@
 static int i8042_command(unsigned char *param, int command)
 {
unsigned long flags;
+   unsigned char str;
int retval = 0, i = 0;
 
if (i8042_noloop && command == I8042_CMD_AUX_LOOP)
@@ -213,7 +217,10 @@
if (!retval)
for (i = 0; i < ((command >> 8) & 0xf); i++) {
if ((retval = i8042_wait_read())) break;
-   if (i8042_read_status() & I8042_STR_AUXDATA)
+   udelay(I8042_STR_DELAY);
+   str = i8042_read_status();
+   udelay(I8042_DATA_DELAY);
+   if (str & I8042_STR_AUXDATA)
param[i] = ~i8042_read_data();
else
param[i] = i8042_read_data();
@@ -424,6 +431,7 @@
ret = 0;
goto out;
}
+   udelay(I8042_DATA_DELAY);
data = i8042_read_data();
spin_unlock_irqrestore(_lock, flags);
 
= drivers/input/serio/i8042.h 1.12 vs edited =
--- 1.12/drivers/input/serio/i8042.h2005-01-22 02:22:51 -05:00
+++ edited/drivers/input/serio/i8042.h  2005-01-25 01:44:36 -05:00
@@ -30,12 +30,19 @@
 #endif
 
 /*
- * This is in 50us units, the time we wait for the i8042 to react. This
+ * i8042 I/O recovery times
+ */
+#define I8042_STR_DELAY20
+#define I8042_DATA_DELAY   7
+
+
+/*
+ * This is in 20us units, the time we wait for the i8042 to react. This
  * has to be long enough for the i8042 itself to timeout on sending a byte
  * to a non-existent mouse.
  */
 
-#define I8042_CTL_TIMEOUT  1
+#define I8042_CTL_TIMEOUT  25000
 
 /*
  * When the device isn't opened and it's interrupts aren't used, we poll it at
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Avoiding fragmentation through different allocator

[Andi Kleen]

Steve Lord <[EMAIL PROTECTED]> writes:
>
> I realize this is one data point on one end of the scale, but I
> just wanted to make the point that there are cases where it
> does matter. Hopefully William's little change from last
> year has helped out a lot.

There are more datapoints: 

e.g. performance on megaraid controllers (very popular because a big
PC vendor ships them) was always quite bad on Linux. Up to the point
that specific IO workloads run half as fast on a megaraid compared to
other controllers. I heard they do work better on Windows.

Also I did some experiments with coalescing SG lists in the Opteron IOMMU
some time ago. With a MPT fusion controller and forcing all SG lists
through the IOMMU so that the SCSI controller always only contiguous mappings
I saw ~5% improvement on some IO tests.

Unfortunately there are some problems that doesn't allow to enable
this unconditionally. But it gives strong evidence that MPT Fusion prefers
shorter SG lists too.

So it seems to be worthwhile to optimize for shorter SG lists.

Ideally the Linux IO patterns would look similar to the Windows IO patterns,
then we could reuse all the optimizations the controller vendors
did for Windows :)
 
-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 6/29] x86-apic-virtwire-on-shutdown

[Len Brown]

On Tue, 2005-01-25 at 01:39, Eric W. Biederman wrote:
> Len Brown <[EMAIL PROTECTED]> writes:
> 
> > On Wed, 2005-01-19 at 02:31, Eric W. Biederman wrote:
> > > When coming out of apic mode attempt to set the appropriate
> > > apic back into virtual wire mode.  This improves on previous
> versions
> > > of this patch by by never setting bot the local apic and the
> ioapic
> > > into veritual wire mode.
> > >
> > > This code looks at data from the mptable to see if an ioapic has
> > > an ExtInt input to make this decision.  A future improvement
> > > is to figure out which apic or ioapic was in virtual wire mode
> > > at boot time and to remember it.  That is potentially a more
> accurate
> > > method, of selecting which apic to place in virutal wire mode.
> > >
> >
> > The call to find_isa_irq_pin() will always fail on ACPI-enabled
> systems,
> > so this patch is a NO-OP unless the system is booted in MPS mode.
> >
> > Do we really want to be adding this complexity for obsolete systems?
> > Are there systems that fail without this patch?
> 
> Yes there are bleeding edge systems that fail without this patch.
> And I have them.  That is why I wrote the code.

What bleeding edge system support MPS and does not support ACPI?

> I do agree that find_isa_irq_pin is a suboptimal way to get this
> information, looking at the ioapics at boot time would be better.
> However it works for me, the code is not wrong, and as you said
> usually the code becomes a noop.
> 
> If I can find the appropriate place in the boot path to examine
> the ioapics before they get stomped I am more than willing to write
> code that will handle this even in the presence of acpi data.

I belive we don't touch the IO_APICS in either MPS or ACPI mode before
setup_IO_APIC.
 
> In addition this code is not a complete noop because when
> find_isa_irq_pin fails it does put the local apic in virtual wire
> mode.

If the goal of this patch is to restore the hardware to the state
that it was before Linux scribbed on it, then it might be a better
ideal to save/restore the actual register values the BIOS gave us rather
than writing hard-coded values, no?

-Len


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

Re: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram back in place

[Christoph Hellwig]

On Tue, Jan 25, 2005 at 01:41:17AM +0100, Sytse Wielinga wrote:
> Linus, could you please put skb_copy_datagram back in place? It's not used
> anymore in the kernel, but the vmnet module (in vmware) still uses this
> interface to skb_copy_datagram_iovec.
> 
> Patch for 2.6.11-rc2 follows. It compiles cleanly; I have not tested it yet,
> but I assume it's okay. I'll test it right after sending this mail and report
> back here if something goes wrong.

Just fix vmware.  Or upgrade to a fixed version that Petr mentioned already.

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

Re: [PATCH] fix bad locking in drivers/base/driver.c

[Mike Waychison]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greg KH wrote:
> On Mon, Jan 24, 2005 at 07:25:19PM +0100, Jirka Kosina wrote:
> 
>>Hi,
>>
>>there has been (for quite some time) a bug in function driver_unregister() 
>>- the lock/unlock sequence is protecting nothing and the actual 
>>bus_remove_driver() is called outside critical section.
>>
>>Please apply.
> 
> 
> No, please read the comment in the code about why this is the way it is.
> The code is correct as is.
> 

Why don't we clean this up as in the proposed attached patch (against
2.6.10).  Compile-tested only.

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice

~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB9fYjdQs4kOxk3/MRAgzrAJ96+aEawx/A0Sf0d5HqArsasgYrqQCZAVzp
wuGctEJpxqtxezPD7LNGS+U=
=77WW
-END PGP SIGNATURE-
Get rid of semaphore abuse by converting device_driver->unload_sem semaphore to device_driver->unloaded completion.

This should get rid of any confusion as well as save a few bytes in the
process.

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

 drivers/base/bus.c |2 +-
 drivers/base/driver.c  |   13 ++---
 include/linux/device.h |2 +-
 3 files changed, 8 insertions(+), 9 deletions(-)

Index: linux-2.6.10/drivers/base/bus.c
===
--- linux-2.6.10.orig/drivers/base/bus.c	2004-12-24 16:34:26.0 -0500
+++ linux-2.6.10/drivers/base/bus.c	2005-01-25 02:14:10.0 -0500
@@ -65,7 +65,7 @@ static struct sysfs_ops driver_sysfs_ops
 static void driver_release(struct kobject * kobj)
 {
 	struct device_driver * drv = to_driver(kobj);
-	up(>unload_sem);
+	complete(>unloaded);
 }
 
 static struct kobj_type ktype_driver = {
Index: linux-2.6.10/drivers/base/driver.c
===
--- linux-2.6.10.orig/drivers/base/driver.c	2004-12-24 16:35:25.0 -0500
+++ linux-2.6.10/drivers/base/driver.c	2005-01-25 02:16:31.0 -0500
@@ -79,14 +79,14 @@ void put_driver(struct device_driver * d
  *	since most of the things we have to do deal with the bus
  *	structures.
  *
- *	The one interesting aspect is that we initialize @drv->unload_sem
- *	to a locked state here. It will be unlocked when the driver
- *	reference count reaches 0.
+ *	The one interesting aspect is that we setup @drv->unloaded
+ *	as a completion that gets complete when the driver reference 
+ *	count reaches 0.
  */
 int driver_register(struct device_driver * drv)
 {
 	INIT_LIST_HEAD(>devices);
-	init_MUTEX_LOCKED(>unload_sem);
+	init_completion(>unloaded);
 	return bus_add_driver(drv);
 }
 
@@ -97,7 +97,7 @@ int driver_register(struct device_driver
  *
  *	Again, we pass off most of the work to the bus-level call.
  *
- *	Though, once that is done, we attempt to take @drv->unload_sem.
+ *	Though, once that is done, we wait until @drv->unloaded is copmleted.
  *	This will block until the driver refcount reaches 0, and it is
  *	released. Only modular drivers will call this function, and we
  *	have to guarantee that it won't complete, letting the driver
@@ -107,8 +107,7 @@ int driver_register(struct device_driver
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	down(>unload_sem);
-	up(>unload_sem);
+	wait_for_completion(>unloaded);
 }
 
 /**
Index: linux-2.6.10/include/linux/device.h
===
--- linux-2.6.10.orig/include/linux/device.h	2004-12-24 16:35:28.0 -0500
+++ linux-2.6.10/include/linux/device.h	2005-01-25 02:13:13.716384240 -0500
@@ -102,7 +102,7 @@ struct device_driver {
 	char			* name;
 	struct bus_type		* bus;
 
-	struct semaphore	unload_sem;
+	struct completion	unloaded;
 	struct kobject		kobj;
 	struct list_head	devices;
 

Re: 2.6.11-rc2-mm1: fuse patch needs new libs

[Miklos Szeredi]

> > fuse-transfer-readdir-data-through-device.patch
> >   fuse: transfer readdir data through device
> It is great that this is fixed, don't remove it, but it does require the fuse
> libs to be updated at the same time, or opening dirs for listings will break
> like this:
> 
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOSYS (Function
> not implemented)
> 
> As I personally like for my ls to keep on working, and I assume
> others will, too, I would appreciate it if you could add a warning
> to your announcements the following one or two weeks or so, so that
> people can remove this patch if they don't want to update their
> libs.

This is my fault, sorry.

I promise, that there'll be no more backward incompatible changes (and
if there will, a big warning about library dependency will be added :).

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

Re: 2.6.11-rc2-mm1 kernel BUG at kernel/workqueue.c:104

[Zwane Mwaikambo]

On Mon, 24 Jan 2005, Andrew Morton wrote:

> I can't reproduce it from a quick test here.  I'd assume that the keystroke
> came in before the vt's workqueue is initialised.  fn_enter() calls
> put_queue() calls con_schedule_flip() calls schedule_work() which goes BUG:

Boot into runlevel 1 (console will then be on serial, nothing on any of 
the VTs), then press a key. This can be any time after it's booted into 
runlevel 1.

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

RE: possible CPU bug and request for Intel contacts

[Seth, Rohit]

Kirill Korotaev  wrote on Monday, January 24, 2005
1:51 AM:

> Hello Rohit,
> 
>> Thanks for sending the detailed information. Based on our experiments
>> and analysis, we believe at this point that this is a known E80 issue
>> mentioned in the PIII spec update at this location
>> (http://www.intel.com/design/pentiumiii/specupdt/24445351.pdf)
> 
>> Could you please try one of the suggested work arounds for this
>> issue. 
> Yes, double cr3 reload and cpuid helps us. But rdtsc doesn't.
> 

I will have to get back to you about rdtsc.


> BTW, can you explain why making pages non-global is the cure? Is it
>   safe workaround for this bug?

There is a boundary condition that can have non-global pages containing
the CR3 load to also hit this issue on affected PIII.  Though for this
to happen, mov to cr3 has to be the very last instruction on a page.
And the page following that page (containing CR3 load) has to have
different mapping between user and kernel spaces.

> Double cr3 reload looks a bit unsafe to me, since interrupts or NMI
> can 
> occur between the reloads and probably reuse stale iTLB mappings...

Interruptions will ensure that stale mapping don't exist in ITLB fill
buffer.  So, you are okay with double CR3 laods.

Thanks, rohit

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Enforce USB interface claims

[Chris Wedgwood]

On Mon, Jan 24, 2005 at 10:05:55PM -0800, Greg KH wrote:

> Um, why?  I think this is there to help with "broken" userspace code
> that was written before we enforced the rules of "you must claim an
> interface before using it.  As such, I don't think we can apply this
> patch.

right now such broken userspace spams kern.log, etc.  also it means
you can run two or more instances of something that fail to claim the
endpoint and then fight over packets from it
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [torvalds@osdl.org: Re: Memory leak in 2.6.11-rc1?]

[Andrew Morton]

Bryce Harrington <[EMAIL PROTECTED]> wrote:
>
> There is a new behavior, though.  Now the test is hanging indefinitely
>  on the nptl01 test.  I am assuming that since it passed the spot that it
>  had failed before, that this is an unrelated issue.

I'm finding that nptl01 somtimes gets stuck and sometimes works OK.  Try
running it by hand a few times.

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

RE: possible CPU bug and request for Intel contacts

[Seth, Rohit]

Pavel Machek  wrote on Saturday, January 22, 2005
2:03 AM:

> Hi!
> 
>> Here are the details about CPU bug I mentioned in my previous post.
>> Though it turned out later that it happens on P-III systems only I
>> still hope it can be of interest.
> 
> What about Pentium-M? They are based on P-III and are certainly *very*
> interesting.
>   Pavel

This issue does not happen on Pentium-M.  This issue happens only on
some PIII steppings.  Information about the affected stepping is
provided in the spec update link.

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

Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage

[Christoph Hellwig]

On Mon, Jan 24, 2005 at 10:02:56PM -0800, Greg KH wrote:
> > It would be a lot more productive to follow the normal rules, though.
> > That is posting them on lkml as properly split up patches, and with
> > proper descriptions of what they're doing.
> 
> As previously mentioned, these patches have had that, on the sensors
> mailing list.  Lots of review and comments went into them there, and the
> code was reworked quite a lot based on it.
> 
> Surely you don't want me to forward _every_ driver patch that I get to
> lkml first?  :)

If you add completely new subsystems please send them to lkml first.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] m68k csum_partial_copy_* (was: Re: [PATCH] csum_and_copy_from_user gcc4 warning fixes)

[Geert Uytterhoeven]

On Sat, 15 Jan 2005, Linux Kernel Mailing List wrote:
> ChangeSet 1.2408, 2005/01/15 15:33:46-08:00, [EMAIL PROTECTED]
> 
>   [PATCH] csum_and_copy_from_user gcc4 warning fixes
>   
>   This patch kills tons of gcc4 warnings:

You forgot to update include/asm-m68k/checksum.h. Here's a fix:

--- linux-2.6.11-rc2/include/asm-m68k/checksum.h2004-05-24 
11:13:52.0 +0200
+++ linux-m68k-2.6.11-rc2/include/asm-m68k/checksum.h   2005-01-24 
14:58:28.0 +0100
@@ -25,11 +25,14 @@ unsigned int csum_partial(const unsigned
  * better 64-bit) boundary
  */
 
-extern unsigned int csum_partial_copy_from_user(const char *src, char *dst,
-   int len, int sum, int 
*csum_err);
-
-extern unsigned int csum_partial_copy_nocheck(const char *src, char *dst,
- int len, int sum);
+extern unsigned int csum_partial_copy_from_user(const unsigned char *src,
+   unsigned char *dst,
+   int len, int sum,
+   int *csum_err);
+
+extern unsigned int csum_partial_copy_nocheck(const unsigned char *src,
+ unsigned char *dst, int len,
+ int sum);
 
 /*
  * This is a version of ip_compute_csum() optimized for IP headers,

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/13] Qsort

[Andi Kleen]

> FWIW, we already have a Shell sort for the ngroups stuff in
> kernel/sys.c:groups_sort() that could be made generic.

Sounds like a good plan. Any takers?

-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 6/29] x86-apic-virtwire-on-shutdown

[Eric W. Biederman]

Len Brown <[EMAIL PROTECTED]> writes:

> On Wed, 2005-01-19 at 02:31, Eric W. Biederman wrote:
> > When coming out of apic mode attempt to set the appropriate
> > apic back into virtual wire mode.  This improves on previous versions
> > of this patch by by never setting bot the local apic and the ioapic
> > into veritual wire mode.
> > 
> > This code looks at data from the mptable to see if an ioapic has
> > an ExtInt input to make this decision.  A future improvement
> > is to figure out which apic or ioapic was in virtual wire mode
> > at boot time and to remember it.  That is potentially a more accurate
> > method, of selecting which apic to place in virutal wire mode.
> > 
> 
> The call to find_isa_irq_pin() will always fail on ACPI-enabled systems,
> so this patch is a NO-OP unless the system is booted in MPS mode.
> 
> Do we really want to be adding this complexity for obsolete systems? 
> Are there systems that fail without this patch?

Yes there are bleeding edge systems that fail without this patch.
And I have them.  That is why I wrote the code.

I do agree that find_isa_irq_pin is a suboptimal way to get this
information, looking at the ioapics at boot time would be better.
However it works for me, the code is not wrong, and as you said
usually the code becomes a noop. 

If I can find the appropriate place in the boot path to examine
the ioapics before they get stomped I am more than willing to write
code that will handle this even in the presence of acpi data.

In addition this code is not a complete noop because when
find_isa_irq_pin fails it does put the local apic in virtual wire mode.


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

Re: [PATCH 4/29] x86-i8259-shutdown

[Eric W. Biederman]

Dave Jones <[EMAIL PROTECTED]> writes:

> On Mon, Jan 24, 2005 at 10:32:50PM -0500, Len Brown wrote:
>  > On Wed, 2005-01-19 at 02:31, Eric W. Biederman wrote:
>  > > From: Eric W. Biederman <[EMAIL PROTECTED]>
>  > > 
>  > > This patch disables interrupt generation from the legacy pic on
>  > > reboot.  Now that there is a sys_device class it should not be called
>  > > while drivers are still using interrupts.
>  > > 
>  > > There is a report about this breaking ACPI power off on some systems.
>  > > http://bugme.osdl.org/show_bug.cgi?id=4041
>  > > However the final comment seems to exhonorate this code.  So until
>  > > I get more information I believe that was a false positive.
>  > 
>  > No, the last comment in the bug report
>  > (davej says that there were poweroff problems in FC)
>  > does not exhonerate this patch.
>  > All it says is that there are additional poweroff bugs out there.
> 
> Indeed. Since dropping the kexec bits from the Fedora kernel,
> the 'hangs at poweroff' bug went away for a lot of folks,
> but there still remain some people affected by some other regression.
> https://bugzilla.redhat.com/beta/show_bug.cgi?id=acpi_power_off
> has the gory details.

Ok.  I misunderstood that one then.  I thought a separate fix
had cured the bug.  With the kexec bits remaining.

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

[PATCH] trivial fix for i386 cross compile

[Tony Lindgren]

Hi all,

I used to be be able to cross compile for i386 on my x86_64 machine,
but recently something (gcc/binutils?) changed, and it stopped working.

Following patch makes cross compile work with:

make ARCH=i386 CFLAGS_KERNEL="-m32" AFLAGS_KERNEL="-m32" bzImage

Without the patch I'm getting the following error:

  SYSCALL arch/i386/kernel/vsyscall-syms.o
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld:
Relocatable linking with relocations from format elf32-i386
(arch/i386/kernel/vsyscall-sysenter.o) to format elf64-x86-64
(arch/i386/kernel/vsyscall-syms.o) is not supported
collect2: ld returned 1 exit status

Regards,

Tony

--- a/arch/i386/kernel/Makefile 2004-10-28 00:39:50 -07:00
+++ b/arch/i386/kernel/Makefile 2005-01-22 22:57:49 -08:00
@@ -46,7 +46,7 @@
 
 # The DSO images are built using a special linker script.
 quiet_cmd_syscall = SYSCALL $@
-  cmd_syscall = $(CC) -nostdlib $(SYSCFLAGS_$(@F)) \
+  cmd_syscall = $(CC) -m elf_i386 -nostdlib $(SYSCFLAGS_$(@F)) \
  -Wl,-T,$(filter-out FORCE,$^) -o $@
 
 export CPPFLAGS_vsyscall.lds += -P -C -U$(ARCH)

Re: [patch, 2.6.11-rc2] sched: /proc/sys/kernel/rt_cpu_limit tunable

[Nick Piggin]

Jack O'Quin wrote:
Ingo Molnar <[EMAIL PROTECTED]> writes:

* Ingo Molnar <[EMAIL PROTECTED]> wrote:
this patch adds the /proc/sys/kernel/rt_cpu_limit tunable: the maximum
amount of CPU time all RT tasks combined may use, in percent. Defaults
to 80%.
just apply the patch to 2.6.11-rc2 and you should be able to run e.g. 
"jackd -R" as an unprivileged user.

This is a far better idea from an API perspective.  We can continue
writing to the POSIX realtime standard interfaces.  Yet users can
actually take advantage of them.  I like it.
This still doesn't solve your privlige problem though. If I can't
renice something as a regular user, it makes no sense to allow such
realtime behaviour.
I still think the ulimit patches aren't a bad idea to solve your
privilege problem. At that point, is there still a need for
rt_cpu_limit?
Nick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Complex logging in the kernel

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

What systems exist for complex logging and security auditing in the kernel?

For example, let's say I wanted to register my specific code (i.e. a
security module) to log, and adjust to log level N.  I also want another
module to log at log level L, which is lower than N.  I want to print
logs at log level N..+2 and below to the console, but silently log all
log messages >N+2 to the syslog.

Anything?

If there's nothing, I'll write one.  Shouldn't be too hard.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

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

Re: [1/1] superio: remove unneded exports and make some functions static.

[Greg KH]

On Mon, Jan 24, 2005 at 05:14:04PM +0300, Evgeniy Polyakov wrote:
> Remove unneded exports and make some functions static.
> 
> Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>

Applied, thanks.

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

Re: [1/1] superio: change scx200 module name to scx.

[Greg KH]

On Mon, Jan 24, 2005 at 11:37:20PM +0300, Evgeniy Polyakov wrote:
> Change scx200 module name to scx.
> 
> Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>

Applied, thanks.

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

Re: [1/1] superio: change scx200 module name to scx.

[Greg KH]

On Tue, Jan 25, 2005 at 01:13:30AM +0300, Evgeniy Polyakov wrote:
> On Mon, 24 Jan 2005 13:41:33 -0800
> Nish Aravamudan <[EMAIL PROTECTED]> wrote:
> 
> > > +   set_current_state(TASK_INTERRUPTIBLE);
> > > +   schedule_timeout(HZ);
> > > +
> > > +   if (current->flags & PF_FREEZE)
> > > +   refrigerator(PF_FREEZE);
> > > +
> > > +   if (signal_pending(current))
> > > +   flush_signals(current);
> > > +   }
> > 
> > 
> > 
> > I believe this schedule_timeout() call can be an msleep_interruptible(1000).
> 
> Patch was already sent to Greg, it will be included in next release.
> Attached one with fixed scx200/scx filename.

Applied, thanks.

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

Re: [PATCH] move common compat ioctls to hash

[Andi Kleen]

On Mon, Jan 24, 2005 at 10:26:09PM +0200, Michael S. Tsirkin wrote:
> Hi!
> The new ioctl code in fs/compat.c can be streamlined a little
> using the compat hash instead of an explicit switch statement.
> 
> The attached patch is against 2.6.11-rc2-bk2.
> Andi, could you please comment? Does this make sence?

Problem is that when a compat_ioctl handler returns -EINVAL
instead of -ENOIOCTLCMD on unknown ioctl it won't check the common
ones.

I fear this mistake would be common, that is why I put in the switch.

-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] Enforce USB interface claims

[Greg KH]

On Sun, Jan 23, 2005 at 03:12:58AM -0800, Chris Wedgwood wrote:
> Greg,

Adding linux-usb-devel to the CC:

> How would you feel about something like this?
> 
> Index: cw-current/drivers/usb/core/devio.c
> ===
> --- cw-current.orig/drivers/usb/core/devio.c  2005-01-19 14:52:27.987890276 
> -0800
> +++ cw-current/drivers/usb/core/devio.c   2005-01-22 18:09:22.753895659 
> -0800
> @@ -417,10 +417,7 @@
>   return -EINVAL;
>   if (test_bit(ifnum, >ifclaimed))
>   return 0;
> - /* if not yet claimed, claim it for the driver */
> - dev_warn(>dev->dev, "usbfs: process %d (%s) did not claim interface 
> %u before use\n",
> -current->pid, current->comm, ifnum);
> - return claimintf(ps, ifnum);
> + return -EINVAL;
>  }
>  
>  static int findintfep(struct usb_device *dev, unsigned int ep)


Um, why?  I think this is there to help with "broken" userspace code
that was written before we enforced the rules of "you must claim an
interface before using it."  As such, I don't think we can apply this
patch.

thanks,

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

Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage

[Greg KH]

On Mon, Jan 24, 2005 at 09:47:51PM +, Christoph Hellwig wrote:
> On Mon, Jan 24, 2005 at 01:34:42PM -0800, Greg KH wrote:
> > And as for the "these patches have never been reviewed" comments, that's
> > why I put them in my tree, and have them show up in -mm.  It's getting
> > them a wider exposure and finding out these kinds of issues.  So the
> > process is working properly :)
> 
> It would be a lot more productive to follow the normal rules, though.
> That is posting them on lkml as properly split up patches, and with
> proper descriptions of what they're doing.

As previously mentioned, these patches have had that, on the sensors
mailing list.  Lots of review and comments went into them there, and the
code was reworked quite a lot based on it.

Surely you don't want me to forward _every_ driver patch that I get to
lkml first?  :)

That's what all of the subsystem specific mailing lists are for...

thanks,

greg k-h

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

Re: memory leak in 2.6.11-rc2

[Andrew Morton]

Andrew Tridgell <[EMAIL PROTECTED]> wrote:
>
>  > I'm trying the little leak tracking patch from Alexander Nyberg now.
> 
>  Here are the results (only backtraces with more than 10k counts
>  included). The leak was at 1G of memory at the time I ran this, so its
>  safe to say 10k page allocations ain't enough to explain it :-)
> 
>  I also attach a hacked version of the pgown sort program that sorts
>  the output by count, and isn't O(n^2). It took 10 minutes to run the
>  old version :-)
> 
>  I'm guessing the leak is in the new xattr code given that is what
>  dbench and nbench were beating on. Andreas, can you look at the
>  following and see if you can spot anything?
> 
>  This was on 2.6.11-rc2 with the pipe leak patch from Linus. The
>  machine had leaked 1G of ram in 10 minutes, and was idle (only thing
>  running was sshd).
> 
>  175485 times:
>  Page allocated via order 0
>  [0xc0132258] generic_file_buffered_write+280
>  [0xc011b6a9] current_fs_time+77
>  [0xc0132a1e] __generic_file_aio_write_nolock+642
>  [0xc0132e70] generic_file_aio_write+100
>  [0xc017e586] ext3_file_write+38
>  [0xc014b7f5] do_sync_write+169
>  [0xc015f6de] fcntl_setlk64+286
>  [0xc01295a8] autoremove_wake_function+0

It would be pretty strange for plain old pagecache pages to leak in this
manner.  A few things come to mind.

- The above trace is indistinguishable from the normal situation of
  having a lot of pagecache floating about.  IOW: we don't know if the
  above pages have really leaked or not.

- It's sometimes possible for ext3 pages to remain alive (on the page
  LRU) after a truncate, but with no other references to them.  These pages
  are trivially reclaimable.  So even if you've deleted the files which the
  benchmark created, there _could_ be pages left over.  Although it would
  be unusual.

So what you should do before generating the leak tool output is to put
heavy memory pressure on the machine to try to get it to free up as much of
that pagecache as possible.  bzero(malloc(lots)) will do it - create a real
swapstorm, then do swapoff to kill remaining swapcache as well.

If we still see a lot of pages with the above trace then something really
broke.  Where does one get the appropriate dbench version?  How are you
mkfsing the filesystem?  Was mke2fs patched?  How is the benchmark being
invoked?

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

Re: inter_module_get and __symbol_get

[Chris Wedgwood]

On Mon, Jan 24, 2005 at 11:31:04PM -0600, Terence Ripperda wrote:

> this is probably a stupid question, but how are weak references
> used?

the linker sets them to zero, so "if (foo) { ... }" works nicely

it does mean if a module that set foo to non-zero is loaded, we need
to zero it again when it's unloaded or else we have stale bogus
pointers left around
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fix bad locking in drivers/base/driver.c

[Greg KH]

On Mon, Jan 24, 2005 at 07:25:19PM +0100, Jirka Kosina wrote:
> Hi,
> 
> there has been (for quite some time) a bug in function driver_unregister() 
> - the lock/unlock sequence is protecting nothing and the actual 
> bus_remove_driver() is called outside critical section.
> 
> Please apply.

No, please read the comment in the code about why this is the way it is.
The code is correct as is.

Also, please CC the driver core maintainer next time for patches like
this so I don't miss them when they go by.

thanks,

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

Re: Announce: kdb v4.4 is available for kernel 2.6.10

[Jack F Vogel]

On Tue, Jan 25, 2005 at 03:44:26PM +1100, Keith Owens wrote:
> On Tue, 25 Jan 2005 09:55:55 +0530, 
> Saravanan s <[EMAIL PROTECTED]> wrote:
> >Hi Keith,
> >
> >> I have no hardware to test on, so I have
> >> to rely on HP to keep the USB patches in KDB up to date. 
> >
> >Does that mean that there is USB support for KDBv4.4 for kernel 2.6 
> >for i386 machines? Or the patch for i386 also comes from the HP guys.
> 
> All the USB console patches for kdb came from HP, both i386 and ia64.
> Neither work in 2.6 kernels at the moment.
  
I have been looking at the USB code and talked with gregkh about 
it a bit, it looks to me that in order for this to work its going
to take a self-contained polling driver. I've been busy so I havent
looked too far yet for any pre-existent code that could be utilized.
It may need to be written from scratch, which I also might attempt
once I get my queue a bit reduced.

But as is the code thats there isnt even close to working, its just
a bit of infrastructure.

Cheers,

Jack

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

Re: 2.6.11-rc2-mm1 kernel BUG at kernel/workqueue.c:104

[Andrew Morton]

Zwane Mwaikambo <[EMAIL PROTECTED]> wrote:
>
> I pressed a key on a VT during boot and got the following;
> 
>  usb-storage: device scan complete
>  [ cut here ]
>  kernel BUG at kernel/workqueue.c:104!
>  invalid operand:  [#1]
>  PREEMPT SMP DEBUG_PAGEALLOC
>  Modules linked in:
>  CPU:0
>  EIP:0060:[]Not tainted VLI
>  EFLAGS: 00010017   (2.6.11-rc2-mm1)
>  EIP is at queue_work+0x8f/0xa0
>  eax: f5ebe0e4   ebx: f5ebe0e0   ecx: 0001   edx: 
>  esi: c19adef8   edi:    ebp: f5e4fe14   esp: f5e4fe08
>  ds: 007b   es: 007b   ss: 0068
>  Process udev.hotplug (pid: 1351, threadinfo=f5e4e000 task=f5817ac0)
>  Stack: c1815000 001c 0001 f5e4fe20 c0388d3d c1815000 f5e4fe2c 
> c03890c1
> 0002 f5e4fe64 c0389be1 f5e4ffc4 c011a7b8  0002 
> 0086
> 0001 0020 c1815000 f5e4ffc4 0001 f7b09674 001c 
> f5e4fe80
>  Call Trace:
>   [] show_stack+0x7a/0x90
>   [] show_registers+0x156/0x1c0
>   [] die+0x100/0x190
>   [] do_invalid_op+0xa9/0xc0
>   [] error_code+0x2b/0x30
>   [] fn_enter+0x1d/0x60
>   [] k_spec+0x31/0x50
>   [] kbd_keycode+0x1a1/0x300
>   [] kbd_event+0x93/0xf0
>   [] input_event+0xd3/0x3b0
>   [] atkbd_report_key+0x2f/0x70
>   [] atkbd_interrupt+0x1ee/0x510
>   [] serio_interrupt+0x43/0x74
>   [] i8042_interrupt+0x17d/0x270
>   [] handle_IRQ_event+0x2a/0x60

I can't reproduce it from a quick test here.  I'd assume that the keystroke
came in before the vt's workqueue is initialised.  fn_enter() calls
put_queue() calls con_schedule_flip() calls schedule_work() which goes BUG:

BUG_ON(!list_empty(>entry));

I bet the list_head pointers are null.

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

Re: inter_module_get and __symbol_get

[Terence Ripperda]

On Tue, Jan 25, 2005 at 09:44:18AM +1100, kaos@ocs.com.au wrote:
> Weak references are only done once, when the module is loaded.  We
> already use weak references for static determination of symbol
> availability.  inter_module_* and __symbol_* are aimed at the dynamic
> reference problem, not static.

this is probably a stupid question, but how are weak references used?
Usually if a symbol is referenced by a module, but isn't resolved at
load time, the module refuses to load. dynamic references allow a way
to work around this for some applications, but I'm unfamiliar with
weak references being used in this regard.

or does that statement really mean "if we supported weak references,
they would only be done once..."

Thanks,
Terence 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Jack O'Quin]

Ingo Molnar <[EMAIL PROTECTED]> writes:

> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>
>>   First, only SCHED_FIFO worked reliably in my tests.  In Con's tests
>>   even that did not work.  My system is probably better tuned for low
>>   latency than his.  Until we can determine why there were so many
>>   xruns, it is premature to declare victory for either scheduler.
>>   Preferably, we should compare them on a well-tuned low-latency
>>   system running your Realtime Preemption kernel.
>
> i didnt declare victory - the full range of latency fixes is in the -RT
> tree. Merging of relevant bits is an ongoing process - in 2.6.10 you've
> already seen some early results, but it's by no means complete. 

I didn't mean to insult you, Ingo.  

I have nothing but praise for what you've accomplished with 2.6.10.
My tests yesterday demonstrated slightly better SCHED_FIFO performance
with 2.6.10 than 2.4.19 with Andrew's low-latency patches.  For a
mainstream kernel that is a huge accomplishment, never before
achieved.  We should celebrate.

I was just pointing out that saying nice(-20) works as well as
SCHED_ISO, though true, doesn't mean much since neither of them
(currently) work well enough to be useful.

>>   Second, the nice(-20) scheduler provides no clear way to support
>>   multiple realtime priorities. [...]
>
> why? You could use e.g. nice -20, -19 and -18. (see the patch below that
> implements this.)

Which of the the POSIX 1-99 range do you map into those three
priorities?  (I can't figure it out from the patch.)

How does one go about deciding which priority differences "matter" and
which do not?  Why not honor the realtime programmer's choice of
priorities?

For good reasons, most audio developers prefer the POSIX realtime
interfaces.  They are far from perfect, but remain the only workable,
portable solution available.  That is why I like your rt_cpu_limit
proposal so much better that this one.
-- 
  joq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Modules: Allow sysfs module paramaters to be written to.

[Greg KH]

On Sun, Jan 23, 2005 at 07:54:21AM +0100, Marcel Holtmann wrote:
> Hi Greg,
> 
> > > It looks like module parameters are not setable via sysfs in 2.6.11-rc1
> > > 
> > > E.g.
> > > arise parameters # echo -en Y > 
> > > /sys/module/usbcore/parameters/old_scheme_first
> > > -bash: /sys/module/usbcore/parameters/old_scheme_first: Permission denied
> > > arise parameters # id
> > > uid=0(root) gid=0(root) 
> > > groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
> > > arise parameters # 
> > > arise parameters # ls -la /sys/module/usbcore/parameters/old_scheme_first
> > > -rw-r--r--  1 root root 0 Jan 13 22:22 
> > > /sys/module/usbcore/parameters/old_scheme_first
> > > arise parameters # 
> > > 
> > > This is sad because it seems that my usb flash stick (transcebd jetflash)
> > > doesn't like new USB device initialization scheme introduced in 2.6.10.
> > 
> > I'm seeing the same problem here.  I'll dig into it later tonight.
> 
> any updates on this? It still results in a permission denied with a
> recent 2.6.11-rc2 kernel.

Here's a patch that fixes this for me.  It's as if the function was
never implemented at all for some reason.  Sorry for not catching this
when tj's patches went in that changed all of this logic.

Let me know if this fixes the problem for you or not.

thanks,

greg k-h

-
Modules: Allow sysfs module paramaters to be written to.

Fixes a bug in the current tree preventing the sysfs module paramaters from 
being able
to be changed at all from userspace.  It's as if someone just forgot to write 
this function...

Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

diff -Nru a/kernel/params.c b/kernel/params.c
--- a/kernel/params.c   2005-01-24 21:07:40 -08:00
+++ b/kernel/params.c   2005-01-24 21:07:40 -08:00
@@ -640,9 +640,33 @@
return ret;
 }
 
+static ssize_t module_attr_store(struct kobject *kobj,
+   struct attribute *attr,
+   const char *buf, size_t len)
+{
+   struct module_attribute *attribute;
+   struct module_kobject *mk;
+   int ret;
+
+   attribute = to_module_attr(attr);
+   mk = to_module_kobject(kobj);
+
+   if (!attribute->store)
+   return -EPERM;
+
+   if (!try_module_get(mk->mod))
+   return -ENODEV;
+
+   ret = attribute->store(attribute, mk->mod, buf, len);
+
+   module_put(mk->mod);
+
+   return ret;
+}
+
 static struct sysfs_ops module_sysfs_ops = {
.show = module_attr_show,
-   .store = NULL,
+   .store = module_attr_store,
 };
 
 #else
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [torvalds@osdl.org: Re: Memory leak in 2.6.11-rc1?]

[Bryce Harrington]

Hi Chris,

I applied the patch and reran the test on a RH 9.0 system.  LTP is
continuing past where it failed before, and processes are not getting
killed, so I assume the OOM killer is no longer getting activated.

There is a new behavior, though.  Now the test is hanging indefinitely
on the nptl01 test.  I am assuming that since it passed the spot that it
had failed before, that this is an unrelated issue.

Bryce


On Mon, 24 Jan 2005, Chris Wright wrote:
> Any chance you could re-try with this patch applied?
>
> - Forwarded message from Linus Torvalds <[EMAIL PROTECTED]> -
>
> Date: Mon, 24 Jan 2005 14:35:47 -0800 (PST)
> From: Linus Torvalds <[EMAIL PROTECTED]>
> To: Andrew Morton <[EMAIL PROTECTED]>
> cc: Jens Axboe <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED],
>linux-kernel@vger.kernel.org, [EMAIL PROTECTED]
> Subject: Re: Memory leak in 2.6.11-rc1?
>
>
>
> On Mon, 24 Jan 2005, Andrew Morton wrote:
> >
> > Would indicate that the new pipe code is leaking.
>
> Duh. It's the pipe merging.
>
>   Linus
>
> 
> --- 1.40/fs/pipe.c2005-01-15 12:01:16 -08:00
> +++ edited/fs/pipe.c  2005-01-24 14:35:09 -08:00
> @@ -630,13 +630,13 @@
>   struct pipe_inode_info *info = inode->i_pipe;
>
>   inode->i_pipe = NULL;
> - if (info->tmp_page)
> - __free_page(info->tmp_page);
>   for (i = 0; i < PIPE_BUFFERS; i++) {
>   struct pipe_buffer *buf = info->bufs + i;
>   if (buf->ops)
>   buf->ops->release(info, buf);
>   }
> + if (info->tmp_page)
> + __free_page(info->tmp_page);
>   kfree(info);
>  }
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
> - End forwarded message -
>
>



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

Re: memory leak in 2.6.11-rc2

[Andrew Tridgell]

 > I'm trying the little leak tracking patch from Alexander Nyberg now.

Here are the results (only backtraces with more than 10k counts
included). The leak was at 1G of memory at the time I ran this, so its
safe to say 10k page allocations ain't enough to explain it :-)

I also attach a hacked version of the pgown sort program that sorts
the output by count, and isn't O(n^2). It took 10 minutes to run the
old version :-)

I'm guessing the leak is in the new xattr code given that is what
dbench and nbench were beating on. Andreas, can you look at the
following and see if you can spot anything?

This was on 2.6.11-rc2 with the pipe leak patch from Linus. The
machine had leaked 1G of ram in 10 minutes, and was idle (only thing
running was sshd).

Cheers, Tridge


175485 times:
Page allocated via order 0
[0xc0132258] generic_file_buffered_write+280
[0xc011b6a9] current_fs_time+77
[0xc0132a1e] __generic_file_aio_write_nolock+642
[0xc0132e70] generic_file_aio_write+100
[0xc017e586] ext3_file_write+38
[0xc014b7f5] do_sync_write+169
[0xc015f6de] fcntl_setlk64+286
[0xc01295a8] autoremove_wake_function+0

141512 times:
Page allocated via order 0
[0xc0132258] generic_file_buffered_write+280
[0xc0132a1e] __generic_file_aio_write_nolock+642
[0xc0132e70] generic_file_aio_write+100
[0xc017e586] ext3_file_write+38
[0xc014b7f5] do_sync_write+169
[0xc015f6de] fcntl_setlk64+286
[0xc01295a8] autoremove_wake_function+0
[0xc014b8d5] vfs_write+157

67641 times:
Page allocated via order 0
[0xc0132258] generic_file_buffered_write+280
[0xc014dc69] __getblk+29
[0xc011b6a9] current_fs_time+77
[0xc0132a1e] __generic_file_aio_write_nolock+642
[0xc018d368] ext3_xattr_user_get+108
[0xc0132e70] generic_file_aio_write+100
[0xc017e586] ext3_file_write+38
[0xc014b7f5] do_sync_write+169

52758 times:
Page allocated via order 0
[0xc0132258] generic_file_buffered_write+280
[0xc014dc69] __getblk+29
[0xc0132a1e] __generic_file_aio_write_nolock+642
[0xc018d368] ext3_xattr_user_get+108
[0xc0132e70] generic_file_aio_write+100
[0xc017e586] ext3_file_write+38
[0xc014b7f5] do_sync_write+169
[0xc0120c0b] kill_proc_info+47

19610 times:
Page allocated via order 0
[0xc0132258] generic_file_buffered_write+280
[0xc011b6a9] current_fs_time+77
[0xc0132a1e] __generic_file_aio_write_nolock+642
[0xc0132c3a] generic_file_aio_write_nolock+54
[0xc0132def] generic_file_write_nolock+151
[0xc011b7cb] __do_softirq+95
[0xc01295a8] autoremove_wake_function+0
[0xc01295a8] autoremove_wake_function+0

16874 times:
Page allocated via order 0
[0xc0132258] generic_file_buffered_write+280
[0xc011b6a9] current_fs_time+77
[0xc0132a1e] __generic_file_aio_write_nolock+642
[0xc0132c3a] generic_file_aio_write_nolock+54
[0xc0132def] generic_file_write_nolock+151
[0xc01295a8] autoremove_wake_function+0
[0xc01295a8] autoremove_wake_function+0
[0xc0152d4a] blkdev_file_write+38



pgown-fast.c
Description: Binary data

Re: 2.6.11-rc2-mm1 Random related problems

[Zwane Mwaikambo]

On Mon, 24 Jan 2005, Matt Mackall wrote:

> On Mon, Jan 24, 2005 at 09:36:37PM -0700, Zwane Mwaikambo wrote:
> > I'm having trouble booting here, were those random-* patches tested?
> 
> Works here, can you send me a copy of your init script?

#!/bin/bash
#
# randomScript to snapshot random state and reload it at boot time.
#
# Author:   Theodore Ts'o <[EMAIL PROTECTED]>
#
# chkconfig: 2345 20 80
# description: Saves and restores system entropy pool for higher quality \
#  random number generation.

. /etc/init.d/functions

random_seed=/var/lib/random-seed

# See how we were called.
case "$1" in
  start)
# Carry a random seed from start-up to start-up
# Load and then save 512 bytes, which is the size of the entropy pool
if [ -f $random_seed ]; then
cat $random_seed >/dev/urandom
else
touch $random_seed
fi
action $"Initializing random number generator: " /bin/true
chmod 600 $random_seed
dd if=/dev/urandom of=$random_seed count=1 bs=512 2>/dev/null
touch /var/lock/subsys/random

;;
  stop)
# Carry a random seed from shut-down to start-up
# Save 512 bytes, which is the size of the entropy pool
touch $random_seed
chmod 600 $random_seed
action $"Saving random seed: " dd if=/dev/urandom of=$random_seed 
count=1 bs=512 2>/dev/null

rm -f /var/lock/subsys/random
;;
  status)
# this is way overkill, but at least we have some status output...
if [ -c /dev/random ] ; then
echo $"The random data source exists"
else
echo $"The random data source is missing"
fi
;;
  restart|reload)
# do not do anything; this is unreasonable
:
;;
  *)
# do not advertise unreasonable commands that there is no reason
# to use with this device
echo $"Usage: $0 {start|stop|status|restart|reload}"
exit 1
esac

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

ATI drivers working under realtime-preempt linux

[John Gilbert]

Hello all,
Here are two patches that are needed to get this working. It's not 
perfect, but quake3 runs, bzflag runs, noof runs, and that's a start.
So here's the recipe...

Linux-2.6.10 source
the linux-2.6.11-rc2 patch
the realtime-preempt-2.6.11-rc2-V0.7.36-03 patch
the fglrx_6_8_0-8.8.25-1.i386.rpm proprietary drivers
the two included patches.
xorg 6.8.x and some hardware (Radeon 8500+)
install the kernel source with the rc2 and realtime-preempt patches. Mix 
in some configuration options CONFIG_MODULES=y, CONFIG_MODULE_UNLOAD=y,  
CONFIG_KMOD=y, CONFIG_MTRR=y, #CONFIG_FB= is not set, CONFIG_DRM=y, 
CONFIG_TMPFS=y, plus whatever else runs your system.
Build kernel, fix lilo/grub,  add the line "tmpfs /dev/shm tmpfs 
defaults 0 0" to the fstab
and reboot.

If you have an older ATI rpm installed, remove it.
Install the new ATI drivers. I used "rpm -i --nodeps fglrx...". 
Slackware doesn't use RPMs so dependency tables are useless.
It will install all the files, but will fail.
cd to  /lib/modules/fglrx/build_mod and patch the two files. "sh 
make.sh", "cd .."
"sh make_install.sh", "depmod -e", "modprobe fglrx"
if this works, the kernel module is done.

Run fglrxconfig, answer the questions, and it will create a broken 
XF86Config-4 file for you (if you are running 6.8.1). in /etc/X11 create 
a symbolic link to XF86Config-4 called xorg.conf, and change the line ' 
Driver "Keyboard" ' , to 'Driver "kbd" '.
Keep fingers crossed, run startx.

 Bugs and Rants Follow 
Seems to have a problem exiting, leaves video blank.
There's still some compile time warnings.
I suspect that if you ran a 32 bit kernel with AMD-8150 hardware, you 
would see some things blow up (see line 3788 of agpgart_be.c).

Xv isn't supported. DRI isn't supported.
ATI (and NVIDIA) should be all over the hard-realtime kernel, as this 
has the potential of making video and games frame accurate (never 
missing frames, no page tears).
The documentation from Linux user's web pages are better than ATI's.

Making this work should have been someone at ATI's job, not mine. I'm 
working blind here.

To anyone playing with this, good luck. It would be good to have real 
kernel developers look at what I've probably messed up trying to get 
this working. If you can fix some more warnings or some bugs, please let 
me know ;^)

ATI: please work with and support the realtime-preempt developers, 
there's lots of things Linux will be able to do shortly that only 
expensive Silicon Graphics systems could do before (and not open source).
Be a help, not a hindrance. Open up more code. Help make Linux the 
uber-media/games OS.

Thanks, Hope this helps.
John Gilbert
[EMAIL PROTECTED]
--- agpgart_be.c.orig   2004-12-14 09:55:47.0 -0800
+++ agpgart_be.c2005-01-24 17:09:15.0 -0800
@@ -117,6 +117,10 @@
 #include 
 #include 
 
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,9)
+#define pci_find_class pci_get_class
+#endif
+
 #if (LINUX_VERSION_CODE >= 0x020400)
 #define FGL_PM_PRESENT
 #else
@@ -6469,6 +6473,7 @@
 
 // FGL - end
 
+#ifdef __x86_64__
 static int agp_check_supported_device(struct pci_dev *dev) 
 {
 
@@ -6483,13 +6488,16 @@
 
   return 0;
 }
+#endif
 
 /* Supported Device Scanning routine */
 
 static int __init agp_find_supported_device(void)
 {
struct pci_dev *dev = NULL;
+#ifdef __x86_64__
 u8 cap_ptr = 0x00;
+#endif
 
 // locate host bridge device
 #ifdef __x86_64__
--- firegl_public.c.orig2005-01-04 17:05:05.0 -0800
+++ firegl_public.c 2005-01-24 16:50:28.0 -0800
@@ -2590,13 +2590,13 @@
 #endif /* __ia64__ */
 vma->vm_flags |= VM_IO; /* not in core dump */
 }
-if (remap_page_range(FGL_VMA_API_PASS
+if (remap_pfn_range(FGL_VMA_API_PASS
  vma->vm_start,
- __ke_vm_offset(vma),
+ vma->vm_pgoff,
  vma->vm_end - vma->vm_start,
  vma->vm_page_prot))
 {
-__KE_DEBUG("remap_page_range failed\n");
+__KE_DEBUG("remap_pfn_range failed\n");
 return -EAGAIN;
 }
 vma->vm_flags |= VM_SHM | VM_RESERVED; /* Don't swap */
@@ -2655,15 +2655,15 @@
 #else
//  else
{
-   if (__ke_vm_offset(vma) >= __pa(high_memory))
+   if (vma->vm_pgoff >= __pa(high_memory))
vma->vm_flags |= VM_IO; /* not in core 
dump */
-   if (remap_page_range(FGL_VMA_API_PASS
+   if (remap_pfn_range(FGL_VMA_API_PASS
 
vma->vm_start,
-
__ke_vm_offset(vma),
+   

Re: 2.6.11-rc2-mm1 Random related problems

[Matt Mackall]

On Mon, Jan 24, 2005 at 09:36:37PM -0700, Zwane Mwaikambo wrote:
> I'm having trouble booting here, were those random-* patches tested?

Works here, can you send me a copy of your init script?

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

2.6.11-rc2-mm1 kernel BUG at kernel/workqueue.c:104

[Zwane Mwaikambo]

I pressed a key on a VT during boot and got the following;

usb-storage: device scan complete
[ cut here ]
kernel BUG at kernel/workqueue.c:104!
invalid operand:  [#1]
PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010017   (2.6.11-rc2-mm1)
EIP is at queue_work+0x8f/0xa0
eax: f5ebe0e4   ebx: f5ebe0e0   ecx: 0001   edx: 
esi: c19adef8   edi:    ebp: f5e4fe14   esp: f5e4fe08
ds: 007b   es: 007b   ss: 0068
Process udev.hotplug (pid: 1351, threadinfo=f5e4e000 task=f5817ac0)
Stack: c1815000 001c 0001 f5e4fe20 c0388d3d c1815000 f5e4fe2c c03890c1
   0002 f5e4fe64 c0389be1 f5e4ffc4 c011a7b8  0002 0086
   0001 0020 c1815000 f5e4ffc4 0001 f7b09674 001c f5e4fe80
Call Trace:
 [] show_stack+0x7a/0x90
 [] show_registers+0x156/0x1c0
 [] die+0x100/0x190
 [] do_invalid_op+0xa9/0xc0
 [] error_code+0x2b/0x30
 [] fn_enter+0x1d/0x60
 [] k_spec+0x31/0x50
 [] kbd_keycode+0x1a1/0x300
 [] kbd_event+0x93/0xf0
 [] input_event+0xd3/0x3b0
 [] atkbd_report_key+0x2f/0x70
 [] atkbd_interrupt+0x1ee/0x510
 [] serio_interrupt+0x43/0x74
 [] i8042_interrupt+0x17d/0x270
 [] handle_IRQ_event+0x2a/0x60
 [] __do_IRQ+0xe9/0x140
 [] do_IRQ+0x33/0x70
 [] common_interrupt+0x1a/0x20
Code: e8 37 92 fe ff b8 00 e0 ff ff 21 e0 8b 40 08 a8 08 75 11 89 f8 8b 1c 
24 8b 74 24 04 8b 7c 2408 89 ec 5d c3 e8 33 7b 4b 00 eb e8 <0f> 0b 68 00 
a3 55 62 c0 eb b1 8d b4 26 00 00 00 00 55 89 e5 83
 <0>Kernel panic - not syncing: Fatal exception in interrupt

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

Re: Announce: kdb v4.4 is available for kernel 2.6.10

[Keith Owens]

On Tue, 25 Jan 2005 09:55:55 +0530, 
Saravanan s <[EMAIL PROTECTED]> wrote:
>Hi Keith,
>
>> I have no hardware to test on, so I have
>> to rely on HP to keep the USB patches in KDB up to date. 
>
>Does that mean that there is USB support for KDBv4.4 for kernel 2.6 
>for i386 machines? Or the patch for i386 also comes from the HP guys.

All the USB console patches for kdb came from HP, both i386 and ia64.
Neither work in 2.6 kernels at the moment.

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

2.6.11-rc2-mm1 Random related problems

[Zwane Mwaikambo]

I'm having trouble booting here, were those random-* patches tested?

Initializing random number generator:  [  OK  ]
Unable to handle kernel paging request at virtual address f5e5
 printing eip:
c037a0a5
*pde = 0086e067
Oops:  [#1]
PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010006   (2.6.11-rc2-mm1)
EIP is at __add_entropy_words+0xc5/0x1c0
eax: 002d   ebx: 000f   ecx: 007b   edx: f5e5
esi: c0810980   edi: 000f   ebp: f5e4fea4   esp: f5e4fe5c
ds: 007b   es: 007b   ss: 0068
Process dd (pid: 2255, threadinfo=f5e4e000 task=ebdd7ac0)
Stack: 0010 7800 c07043e0 0286 007b 001f 0001 0007
   000e 0014 001a  002d f5e5 c07043c0 0080
   c0704340 c07043c0 f5e4ff40 c037a4e0  0010 2cda69d0 f7b9f75e
Call Trace:
 [] show_stack+0x7a/0x90
 [] show_registers+0x156/0x1c0
 [] die+0x100/0x190
 [] do_page_fault+0x349/0x63f
 [] error_code+0x2b/0x30
 [] xfer_secondary_pool+0xb0/0xe0
 [] extract_entropy_user+0x1e/0xd0
 [] vfs_read+0xe8/0x1a0
 [] sys_read+0x41/0x70
 [] sysenter_past_esp+0x52/0x75
Code: ff 0f 84 cf 00 00 00 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 
b6 4d c8 89 f8 d3 c0 8945 bc 8b 45 e8 85 c0 7e 0e 8b 55 ec <8b> 0a 83 c2 
04 89 55 ec 89 4d c8 8b 4d cc 4b 8d 47 0e 8b 55 e0
 <3>Debug: sleeping function called from invalid context at 
include/linux/rwsem.h:43
in_atomic():1, irqs_disabled():0
 [] dump_stack+0x17/0x20
 [] __might_sleep+0xac/0xc0
 [] profile_task_exit+0x23/0x60
 [] do_exit+0x1c/0x450
 [] die+0x188/0x190
 [] do_page_fault+0x349/0x63f
 [] error_code+0x2b/0x30
 [] xfer_secondary_pool+0xb0/0xe0
 [] extract_entropy_user+0x1e/0xd0
 [] vfs_read+0xe8/0x1a0
 [] sys_read+0x41/0x70
 [] sysenter_past_esp+0x52/0x75
note: dd[2255] exited with preempt_count 1
scheduling while atomic: dd/0x1001/2255
 [] dump_stack+0x17/0x20
 [] schedule+0xc82/0xc90
 [] cond_resched+0x2a/0x50
 [] unmap_vmas+0x189/0x260
 [] exit_mmap+0x8b/0x160
 [] mmput+0x41/0xf0
 [] do_exit+0xa7/0x450
 [] die+0x188/0x190
 [] do_page_fault+0x349/0x63f
 [] error_code+0x2b/0x30
 [] xfer_secondary_pool+0xb0/0xe0
 [] extract_entropy_user+0x1e/0xd0
 [] vfs_read+0xe8/0x1a0
 [] sys_read+0x41/0x70
 [] sysenter_past_esp+0x52/0x75
/etc/rc3.d/S20random: line 57:  2255 Segmentation fault  dd 
if=/dev/urandom of=$random_seed count=1 bs=512 2>/dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

insmod problem

[Muruganandam]

When i execute the command insmod module.o ,its giving the eror version 
mismatch.i am using the kernel 2.4.21-4.el.but it says 2.4.20.what is 
the problem.

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

Re: Fwd: Patch to control VGA bus routing and active VGA device.

[Greg KH]

On Mon, Jan 24, 2005 at 07:55:23PM +, Russell King wrote:
> On Mon, Jan 24, 2005 at 02:42:57PM -0500, Jeff Garzik wrote:
> > Jon Smirl wrote:
> > > Is this a justification for doing device drivers for bridge chips? It
> > > has been mentioned before but no one has done it.
> > 
> > 
> > Yeah, people are usually slack and work around the problem.
> > 
> > A bridge driver is really wanted for several situations in today's 
> > hardware...
> 
> There's a very good reason not to have a bridge driver at the moment -
> some PCI to PCI bridges need special drivers.  Currently, as the device
> model stands today, we can only have ONE PCI to PCI bridge driver for
> all P2P bridges, which is bad news if you need a specific driver for,
> eg, a mobility docking station P2P bridge.
> 
> As I said back in 2002, the device model needs a way to have driver
> priories - how well a driver matches the hardware.
> 
> My idea was for the bus match function to return the "goodness"
> factor of the match.  For PCI, matching on just the class IDs would
> be low goodness, but an exact match with both the vendor and device
> IDs would yeild a good match.

This can be done today in the bus specific match functions.  And because
of that, I would argue that this belongs in the bus specific code, and
not in the driver core, as it's up to the bus to know what the different
types of "matches" that can happen, and what the priority is.

And yes, I agree that this needs to be done, I've been talking with a
few other people who are interested in it.  I think the lock-rework code
needs to be finished before it can happen properly, so that we can do
the "unbind from one driver and give it to another one" type logic
properly.

thanks,

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

Re: Announce: kdb v4.4 is available for kernel 2.6.10

[Saravanan s]

Hi Keith,

> I have no hardware to test on, so I have
> to rely on HP to keep the USB patches in KDB up to date. 

Does that mean that there is USB support for KDBv4.4 for kernel 2.6 
for i386 machines? Or the patch for i386 also comes from the HP guys.

Regards
Saravanan S

On Tue, 25 Jan 2005 02:34:52 +1100, Keith Owens <[EMAIL PROTECTED]> wrote:
> On Mon, 24 Jan 2005 15:21:08 -,
> [EMAIL PROTECTED] wrote:
> >All:
> >I tried to get Kdb working on SuSe 9 ia64 box (kernel version
> >2.6.5-7.111.19). Turns out that the keyboard/machine goes into a hang state.
> >I have a usb keyboard!
> >
> >Googling around I found that Keith had disabled the USB keyboard support
> >some time back due to changes in some APIs (kernel version
> >linux-2.6.5-SLES9_SP1_BRANCH).
> >
> >Is this something that could be a cause for my problem? Should I think about
> >upgrading my kernel to 2.6.10 (hoping that the issue's been fixed in this
> >version)?
> 
> The USB keyboard support in KDB was written by HP, because their
> systems have USB keyboards.  I have no hardware to test on, so I have
> to rely on HP to keep the USB patches in KDB up to date.  That has not
> happened recently.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

disabling Hyperthreading online

[regatta]

Hi

Is there anyway to disable CPU Hyperthreading without rebooting the system ?


-- 
Best Regards,

-*- If Linux doesn't have the solution, you have the wrong problem -*-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/7] posix-timers: tidy up clock interfaces and consolidate dispatch logic

[Ulrich Drepper]

George Anzinger wrote:
As I understand it modern machines, the indirect call does really bad 
things to the pipeline.
Unless the call happens often, really often, you'll not be able to 
measure differences.  Indirect jump obviously cause pipeline stalls 
which often, but not always, can be avoided with direct calls.  But we 
are not talking here about huge delays.  And the delays are equivalent 
in cost to a mispredicted branch.  If you have a couple of ifs in a row 
you are likely to incur problems with the branch prediction.  I would 
just use the indirect jumps but if you want, do some timing and see 
whether you can filter the difference out of the noise.

--
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â


signature.asc
Description: OpenPGP digital signature

Re: undefined references

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



[EMAIL PROTECTED] wrote:
> On Mon, 24 Jan 2005 19:04:53 EST, John Richard Moser said:
> 
> 
>>fs/built-in.o(.text+0xe413): In function `link_path_walk':
>>: undefined reference to `gr_inode_follow_link'
>>fs/built-in.o(.text+0xe933): In function `link_path_walk':
>>: undefined reference to `gr_inode_follow_link'
>>fs/built-in.o(.text+0x10c28): In function `sys_link':
>>: undefined reference to `gr_inode_hardlink'
>>fs/built-in.o(.text+0x10c52): In function `sys_link':
>>: undefined reference to `gr_inode_handle_create'
>>make: *** [.tmp_vmlinux1] Error 1
>>
>>What would cause this kind of error?
> 
> 
> link_path_walk() still has a reference to gr_inode_follow_link (the code
> you probably want to move to an LSM exit), and sys_ling() still calls
> gr_inode_hardlink() and gr_inode_handle_create() - but the actual functions
> you're calling either don't exist anymore, or they didn't get compiled and 
> linked
> in.  If those functions are supposed to exist, you need to get them into a .o.
> If those are (as I suspect) becoming LSM exit hooks, then you need to clean up
> the direct calls in link_path_walk() and sys_link().

I figured it out.

I had in the makefile

subdir-$(CONFIG_GRSECURITY) += grsecurity/

I had to use obj- instead.


This is just an academic thing-- I'm rewriting GrSecurity's invasive
code as a bunch of hooks, collapsing what I can down, and making a
stackable (easy) security framework from scratch (what the hell am I
doing?).  I'm not modifying LSM, though I did rip off the
security_initcall things (did I just create a new .text section in
vmlinuz?  o.o).

Thanks for your comments though.  I'll look to them if I have trouble in
the future.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

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

Re: [PATCH] lib/qsort

[Matt Mackall]

On Mon, Jan 24, 2005 at 12:15:27PM -0800, Matt Mackall wrote:
> Here are some benchmarks of cycle count averages for 10 runs on the
> same random datasets, interrupts disabled. Percentages are performance
> relative to the glibc algorithm. A bunch of other variants dropped for
> brevity.

I've discovered a bug in this benchmark that gives a big advantage to
a couple of variants I tried. Corrected benchmarks later.

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

Re: [patch 1/13] Qsort

[Eric St-Laurent]

On Mon, 2005-01-24 at 21:43 -0300, Horst von Brand wrote:
> AFAICS, this is just a badly implemented Shellsort (the 10/13 increment
> sequence starting with the number of elements is probably not very good,
> besides swapping stuff is inefficient (just juggling like Shellsort does
> gives you almost a third less copies)).
> 
> Have you found a proof for the O(n log n) claim?

"Why a Comb Sort is NOT a Shell Sort

A shell sort completely sorts the data for each gap size. A comb sort
takes a more optimistic approach and doesn't require data be completely
sorted at a gap size. The comb sort assumes that out-of-order data will
be cleaned-up by smaller gap sizes as the sort proceeds. "

Reference:

http://world.std.com/~jdveale/combsort.htm

Another good reference:

http://yagni.com/combsort/index.php

Personally, i've used it in the past because of it's small size.  With
C++ templates you can have a copy of the routine generated for a
specific datatype, thus skipping the costly function call used for each
compare.  With some C macro magic, i presume something similar can be
done, for time-critical applications.

Best regards,

Eric St-Laurent


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/29] x86-i8259-shutdown

[Dave Jones]

On Mon, Jan 24, 2005 at 10:32:50PM -0500, Len Brown wrote:
 > On Wed, 2005-01-19 at 02:31, Eric W. Biederman wrote:
 > > From: Eric W. Biederman <[EMAIL PROTECTED]>
 > > 
 > > This patch disables interrupt generation from the legacy pic on
 > > reboot.  Now that there is a sys_device class it should not be called
 > > while drivers are still using interrupts.
 > > 
 > > There is a report about this breaking ACPI power off on some systems.
 > > http://bugme.osdl.org/show_bug.cgi?id=4041
 > > However the final comment seems to exhonorate this code.  So until
 > > I get more information I believe that was a false positive.
 > 
 > No, the last comment in the bug report
 > (davej says that there were poweroff problems in FC)
 > does not exhonerate this patch.
 > All it says is that there are additional poweroff bugs out there.

Indeed. Since dropping the kexec bits from the Fedora kernel,
the 'hangs at poweroff' bug went away for a lot of folks,
but there still remain some people affected by some other regression.
https://bugzilla.redhat.com/beta/show_bug.cgi?id=acpi_power_off
has the gory details.

Dave

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

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Con Kolivas wrote:
-cc list trimmed to those who have recently responded.
Here is a patch to go on top of 2.6.11-rc2-mm1 that fixes some bugs in 
the general SCHED_ISO code, fixes the priority support between ISO 
threads, and implements SCHED_ISO_RR and SCHED_ISO_FIFO as separate 
policies. Note the bugfixes and cleanups mean the codepaths in this are 
leaner than the original ISO2 implementation despite the extra features.

This works safely and effectively on UP (but not tested on SMP yet) so 
Jack if/when you get a chance I'd love to see more benchmarks from you 
on this one. It seems on my machine the earlier ISO2 implementation 
without priority nor FIFO was enough for good results, but not on yours, 
which makes your testcase a more discriminating one.
Sorry, I see yet another flaw in the design and SMP is broken so hold 
off testing for a bit.

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

Re: [PATCH 6/29] x86-apic-virtwire-on-shutdown

[Len Brown]

On Wed, 2005-01-19 at 02:31, Eric W. Biederman wrote:
> When coming out of apic mode attempt to set the appropriate
> apic back into virtual wire mode.  This improves on previous versions
> of this patch by by never setting bot the local apic and the ioapic
> into veritual wire mode.
> 
> This code looks at data from the mptable to see if an ioapic has
> an ExtInt input to make this decision.  A future improvement
> is to figure out which apic or ioapic was in virtual wire mode
> at boot time and to remember it.  That is potentially a more accurate
> method, of selecting which apic to place in virutal wire mode.
> 

The call to find_isa_irq_pin() will always fail on ACPI-enabled systems,
so this patch is a NO-OP unless the system is booted in MPS mode.

Do we really want to be adding this complexity for obsolete systems? 
Are there systems that fail without this patch?

-Len


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

Re: memory leak in 2.6.11-rc2

[Dave Jones]

On Tue, Jan 25, 2005 at 02:19:24PM +1100, Andrew Tridgell wrote:
 > The problem I've hit now is a severe memory leak. I have applied the
 > patch from Linus for the leak in free_pipe_info(), and still I'm
 > leaking memory at the rate of about 100Mbyte/minute.
 > I've tested with both 2.6.11-rc2 and with 2.6.11-rc1-mm2, both with
 > the pipe leak fix. The setup is:

That's a little more extreme than what I'm seeing, so it may be
something else, but my firewall box needs rebooting every
few days. It leaks around 50MB a day for some reason.
Given it's not got a lot of ram, after 4-5 days or so, it's
completely exhausted its swap too.

It's currently on a 2.6.10-ac kernel, so it's entirely possible that
we're not looking at the same issue, though it could be something
thats been there for a while if your workload makes it appear
quicker than a firewall/ipsec gateway would.
Do you see the same leaks with an earlier kernel ?

post OOM (when there was about 2K free after named got oom-killed)
this is what slabinfo looked like..

dentry_cache1502   3775160   251 : tunables  120   600 : 
slabdata151151  0
vm_area_struct  1599   2021 84   471 : tunables  120   600 : 
slabdata 43 43  0
size-1283431   6262128   311 : tunables  120   600 : 
slabdata202202  0
size-64 4352   4575 64   611 : tunables  120   600 : 
slabdata 75 75  0
avtab_node  7073   7140 32  1191 : tunables  120   600 : 
slabdata 60 60  0
size-32 7256   7616 32  1191 : tunables  120   600 : 
slabdata 64 64  0

Dave

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

Re: [patch 1/13] Qsort

[Horst von Brand]

[EMAIL PROTECTED] (H. Peter Anvin) said:

[...]

> In klibc, I use combsort:
> 
> /*
>  * qsort.c
>  *
>  * This is actually combsort.  It's an O(n log n) algorithm with
>  * simplicity/small code size being its main virtue.
>  */
> 
> #include 
> #include 
> 
> static inline size_t newgap(size_t gap)
> {
>   gap = (gap*10)/13;
>   if ( gap == 9 || gap == 10 )
> gap = 11;
> 
>   if ( gap < 1 )
> gap = 1;
>   return gap;
> }
> 
> void qsort(void *base, size_t nmemb, size_t size,
>int (*compar)(const void *, const void *))
> {
>   size_t gap = nmemb;
>   size_t i, j;
>   char *p1, *p2;
>   int swapped;
> 
>   do {
> gap = newgap(gap);
> swapped = 0;
> 
> for ( i = 0, p1 = base ; i < nmemb-gap ; i++, p1 += size ) {
>   j = i+gap;
>   if ( compar(p1, p2 = (char *)base+j*size) > 0 ) {
> memswap(p1, p2, size);
> swapped = 1;
>   }
> }
>   } while ( gap > 1 || swapped );
> }

AFAICS, this is just a badly implemented Shellsort (the 10/13 increment
sequence starting with the number of elements is probably not very good,
besides swapping stuff is inefficient (just juggling like Shellsort does
gives you almost a third less copies)).

Have you found a proof for the O(n log n) claim?

I'd write as attached (careful, a local element on stack!)

/*
 * shellsort.c: Shell sort
 *
 * Copyright (c) 2005, Horst H. von Brand <[EMAIL PROTECTED]>
 * All rights reserved.
 * 
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 
 * * Redistributions of source code must retain the above copyright
 *   notice, this list of conditions and the following disclaimer.
 * * Redistributions in binary form must reproduce the above
 *   copyright notice, this list of conditions and the following
 *   disclaimer in the documentation and/or other materials provided
 *   with the distribution.
 * * Neither the name of Horst H. von Brand nor the names of its
 *   contributors may be used to endorse or promote products derived
 *   from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
 * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
 * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
 * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
 * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
 * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
 * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
 * OF THE POSSIBILITY OF SUCH DAMAGE.
 */

#include 

void qsort(void *base, size_t nmemb, size_t size, 
   int (*compar)(const void *, const void *))

{
  int i, j, h;
  char tmp[size];

  for(h = 1; h < nmemb; h = 3 * h + 1)
;

  do {
h /= 3;
for(i = h; i < nmemb; i++) {
  memcpy(tmp, base + i * size, size);
  for(j = i - h; j >= 0 && compar(tmp, base + j * size); j -= h)
	memcpy(base + (j + h) * size, base + j * size, size);
  memcpy(base + (j + h) * size, tmp, size);
}
  } while(h > 1);
}
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513

Re: memory leak in 2.6.11-rc2

[Andrew Tridgell]

Randy,

 > I have applied the patch from Linus for the leak in
 > free_pipe_info()
...
 > Do you have today's memleak patch applied?  (cut-n-paste below).

yes :-)

I'm trying the little leak tracking patch from Alexander Nyberg now.

Cheers, Tridge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/29] x86-i8259-shutdown

[Len Brown]

On Wed, 2005-01-19 at 02:31, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
> 
> This patch disables interrupt generation from the legacy pic on
> reboot.  Now that there is a sys_device class it should not be called
> while drivers are still using interrupts.
> 
> There is a report about this breaking ACPI power off on some systems.
> http://bugme.osdl.org/show_bug.cgi?id=4041
> However the final comment seems to exhonorate this code.  So until
> I get more information I believe that was a false positive.

No, the last comment in the bug report
(davej says that there were poweroff problems in FC)
does not exhonerate this patch.
All it says is that there are additional poweroff bugs out there.

-Len


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

Re: memory leak in 2.6.11-rc2

[Randy.Dunlap]

Andrew Tridgell wrote:
I've fixed up the problems I had with raid, and am now testing the
recent xattr changes with dbench and nbench.
The problem I've hit now is a severe memory leak. I have applied the
patch from Linus for the leak in free_pipe_info(), and still I'm
leaking memory at the rate of about 100Mbyte/minute.
I've tested with both 2.6.11-rc2 and with 2.6.11-rc1-mm2, both with
the pipe leak fix. The setup is:
 - 4 way PIII with 4G ram
 - qla2200 adapter with ibm fastt200 disk array 
 - running dbench -x and nbench on separate disks, in a loop

The oom killer kicks in after about 30 minutes. Naturally the oom
killer decided to kill my sshd, which was running vmstat :-) 
Do you have today's memleak patch applied?  (cut-n-paste below).
--
~Randy

--- 1.40/fs/pipe.c  2005-01-15 12:01:16 -08:00
+++ edited/fs/pipe.c2005-01-24 14:35:09 -08:00
@@ -630,13 +630,13 @@
struct pipe_inode_info *info = inode->i_pipe;
inode->i_pipe = NULL;
-   if (info->tmp_page)
-   __free_page(info->tmp_page);
for (i = 0; i < PIPE_BUFFERS; i++) {
struct pipe_buffer *buf = info->bufs + i;
if (buf->ops)
buf->ops->release(info, buf);
}
+   if (info->tmp_page)
+   __free_page(info->tmp_page);
kfree(info);
 }
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: BUG: 2.6.11-rc2 and -rc1 hang during boot on PowerMacs

[Benjamin Herrenschmidt]

On Mon, 2005-01-24 at 18:42 +0100, Mikael Pettersson wrote:
> Benjamin Herrenschmidt writes:
>  > On Sun, 2005-01-23 at 11:43 +1100, Benjamin Herrenschmidt wrote:
>  > 
>  > > I know about this problem, I'm working on a proper fix. Thanks for your
>  > > report.
>  > 
>  > Can you send me the PVR value for both of these CPUs
>  > (cat /proc/cpuinfo) ? I can't find right now why they would lock up
>  > unless the default idle loop is _not_ run properly, that is for some
>  > reason, NAP or DOZE mode end up not beeing enabled. Can you send me
>  > your .config as well ?
> 
> === cpuinfo.emac ===
> processor : 0
> cpu   : 7447/7457, altivec supported
> clock : 1249MHz
> revision  : 1.1 (pvr 8002 0101)
> bogomips  : 830.66
> machine   : PowerMac6,4
> motherboard   : PowerMac6,4 MacRISC3 Power Macintosh 
> detected as   : 287 (Unknown Intrepid-based)
> pmac flags: 
> L2 cache  : 512K unified
> memory: 256MB
> pmac-generation   : NewWorld

Ok, it's normal that the Beige G3 doesn't do NAP, and the 7455 cannot do
DOZE, so I suspect it's all normal and my patch fixes it.

However, the eMac should have been doing NAP. Can you check what's up in
arch/ppc/plaform/pmac_feature.c with powersave_nap ? is it set at all ?
It should be visible from userland at /proc/sys/kernel/powersave-nap
and should be set to 1 by default on your machine... unless your cpu
node in the device-tree has the "flush-on-lock" property...
 
Ben.


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

memory leak in 2.6.11-rc2

[Andrew Tridgell]

I've fixed up the problems I had with raid, and am now testing the
recent xattr changes with dbench and nbench.

The problem I've hit now is a severe memory leak. I have applied the
patch from Linus for the leak in free_pipe_info(), and still I'm
leaking memory at the rate of about 100Mbyte/minute.

I've tested with both 2.6.11-rc2 and with 2.6.11-rc1-mm2, both with
the pipe leak fix. The setup is:

 - 4 way PIII with 4G ram
 - qla2200 adapter with ibm fastt200 disk array 
 - running dbench -x and nbench on separate disks, in a loop

The oom killer kicks in after about 30 minutes. Naturally the oom
killer decided to kill my sshd, which was running vmstat :-) 

Killing the dbench and nbench processes does not recovery the memory.
Here is what it looks like after I kill all processes except a sshd
after about 15 minutes of running:

 total   used   free sharedbuffers cached
Mem:   373430424716081262696  0  26820 921440
-/+ buffers/cache:15233482210956
Swap:  4194272  04194272

so we've lost nearly 1.5G in that time.

here is /proc/meminfo:

dev4-003:~# cat /proc/meminfo 
MemTotal:  3734304 kB
MemFree:   1266944 kB
Buffers: 27000 kB
Cached: 921464 kB
SwapCached:  0 kB
Active: 292524 kB
Inactive:  2108928 kB
HighTotal: 2850752 kB
HighFree:   472768 kB
LowTotal:   883552 kB
LowFree:794176 kB
SwapTotal: 4194272 kB
SwapFree:  4194272 kB
Dirty:   4 kB
Writeback:   0 kB
Mapped:   6872 kB
Slab:54236 kB
CommitLimit:   6061424 kB
Committed_AS:41660 kB
PageTables:344 kB
VmallocTotal:   114680 kB
VmallocUsed:  2204 kB
VmallocChunk:   112472 kB

and here is /proc/slabinfo 

slabinfo - version: 2.1
# name
 : tunables: slabdata
   
ip_fib_alias   9226 16  2261 : tunables  120   608 : 
slabdata  1  1  0
ip_fib_hash9119 32  1191 : tunables  120   608 : 
slabdata  1  1  0
fib6_nodes 7119 32  1191 : tunables  120   608 : 
slabdata  1  1  0
ip6_dst_cache  7 36224   181 : tunables  120   608 : 
slabdata  2  2  0
ndisc_cache1 25160   251 : tunables  120   608 : 
slabdata  1  1  0
rawv6_sock 6  667261 : tunables   54   278 : 
slabdata  1  1  0
udpv6_sock 0  064061 : tunables   54   278 : 
slabdata  0  0  0
tcpv6_sock 4  6   118462 : tunables   24   128 : 
slabdata  1  1  0
unix_sock  2  941691 : tunables   54   278 : 
slabdata  1  1  0
ip_mrt_cache   0  0 96   411 : tunables  120   608 : 
slabdata  0  0  0
tcp_tw_bucket  0  0128   311 : tunables  120   608 : 
slabdata  0  0  0
tcp_bind_bucket2226 16  2261 : tunables  120   608 : 
slabdata  1  1  0
tcp_open_request   0  0 96   411 : tunables  120   608 : 
slabdata  0  0  0
inet_peer_cache1 61 64   611 : tunables  120   608 : 
slabdata  1  1  0
secpath_cache  0  0128   311 : tunables  120   608 : 
slabdata  0  0  0
xfrm_dst_cache 0  0256   151 : tunables  120   608 : 
slabdata  0  0  0
ip_dst_cache   6 15256   151 : tunables  120   608 : 
slabdata  1  1  0
arp_cache  1 25160   251 : tunables  120   608 : 
slabdata  1  1  0
raw_sock   5  751271 : tunables   54   278 : 
slabdata  1  1  0
udp_sock   3  851281 : tunables   54   278 : 
slabdata  1  1  0
tcp_sock   1  7   105672 : tunables   24   128 : 
slabdata  1  1  0
flow_cache 0  0 96   411 : tunables  120   608 : 
slabdata  0  0  0
qla2xxx_srbs 256310128   311 : tunables  120   608 : 
slabdata 10 10  0
scsi_cmd_cache22 22352   111 : tunables   54   278 : 
slabdata  2  2  0
cfq_ioc_pool   0  0 24  1561 : tunables  120   608 : 
slabdata  0  0  0
cfq_pool   0  0104   381 : tunables  120   608 : 
slabdata  0  0  0
crq_pool   0  0 56   701 : tunables  120   608 : 
slabdata  0  0  0
deadline_drq   0  0 52   751 : tunables  120   608 : 
slabdata  0  0  0
as_arq61 61 64   611 : tunables  120   608 : 
slabdata  1  

Re: [PATCH] BUG in io_destroy (fs/aio.c:1248)

[Suparna Bhattacharya]

Anything wrong with just a get_ioctx() instead ?


--- aio.c   2005-01-12 09:30:44.0 +0530
+++ aio.c.fix   2005-01-25 08:51:31.0 +0530
@@ -1284,7 +1284,7 @@
ret = put_user(ioctx->user_id, ctxp);
if (!ret)
return 0;
-
+   get_ioctx(ioctx); /* as io_destroy() expects us to hold a ref */
io_destroy(ioctx);
}
 


On Mon, Jan 24, 2005 at 04:43:21PM -0800, Darrick J. Wong wrote:
> Andrew Morton wrote:
> 
> > So...  Will someone be sending a new patch?
> 
> Here's a cheesy patch that simply marks the ioctx as dead before
> destroying it.  Though I'd like to simply mark the ioctx as dead until
> it actually gets used, I don't know enough about the code to make that
> sort of invasive change.
> 
> --D
> 
> -
> Signed-off-by: Darrick Wong <[EMAIL PROTECTED]>
> 
> --- linux-2.6.10/fs/aio.c.old 2005-01-24 16:12:46.0 -0800
> +++ linux-2.6.10/fs/aio.c 2005-01-24 16:30:53.0 -0800
> @@ -1285,6 +1285,10 @@
>   if (!ret)
>   return 0;
>  
> + spin_lock_irq(>ctx_lock);
> + ctx->dead = 1;
> + spin_unlock_irq(>ctx_lock);
> +
>   io_destroy(ioctx);
>   }
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-aio' in
> the body to [EMAIL PROTECTED]  For more info on Linux AIO,
> see: http://www.kvack.org/aio/
> Don't email: mailto:"[EMAIL PROTECTED]">[EMAIL PROTECTED]

-- 
Suparna Bhattacharya ([EMAIL PROTECTED])
Linux Technology Center
IBM Software Lab, India

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

Re: [PATCH 1/7] posix-timers: tidy up clock interfaces and consolidate dispatch logic

[Andrew Morton]

George Anzinger  wrote:
>
>  >  /*
>   > + * Define this to initialize every k_clock function table so all its
>   > + * function pointers are non-null, and always do indirect calls through 
> the
>   > + * table.  Leave it undefined to instead leave null function pointers and
>   > + * decide at the call sites between a direct call (maybe inlined) to the
>   > + * default function and an indirect call through the table when it's 
> filled
>   > + * in.  Which style is preferable is whichever performs better in the
>   > + * common case of using the default functions.
> 
>   > +#define CLOCK_DISPATCH_DIRECT
> 
>  As I understand it modern machines, the indirect call does really bad things 
> to 
>  the pipeline.  The default call, even preceeded by the if, will be much 
> faster 
>  by this reasoning.  I would, therefor, prefer not defining 
> CLOCK_DISPATCH_DIRECT.

We do need to do one or the other.  I assume the current indecision is
pending some benchmarking work?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] new timeofday arch specific hooks (v. A2)

[Benjamin Herrenschmidt]

On Mon, 2005-01-24 at 14:52 -0800, john stultz wrote:
> All,
>   This patch implements the minimal architecture specific hooks to enable
> the new time of day subsystem code for i386, x86-64, and ppc64. It
> applies on top of my linux-2.6.11-rc1_timeofday-core_A2 patch and with
> this patch applied, you can test the new time of day subsystem. 
> 
>   Basically it adds the call to timeofday_interrupt_hook() and cuts alot
> of code out of the build via #ifdefs. I know, I know, #ifdefs' are ugly
> and bad, and the final patch will just remove the old code. For now this
> allows us to be flexible and easily switch between the two
> implementations with a single define. Also it makes the patch a bit
> easier to read.

I haven't seen your other patch. Do you mean that with this patch, ppc64
stops using it's own gettimeofday implementation based on the CPU
hardware timebase ?

There are reasons why I plan to keep that. First, our implementation is
very efficient. It allows a timeofday computation without locks or
barriers thanks to carefully hand crafted data dependencies in the
operation. Second, we have an ABI issue here. For historical reasons, we
have this "systemcfg" data structure that can be mmap'ed to userland,
and which contains copy of some of the ppc64 internal time keeping
infos. Some userland stuff use it to implement a fully userland
gettimeofday (again, without barrier nor locks). This is done at least
by IBM's JVM. My still-to-be-merged vDSO patch will also use this for
the userland implementation of gettimeofday syscall itself.

Ben.


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

Re: 2.6.11-rc2: Badness in local_bh_enable at kernel/softirq.c:140

[Ernst Herzberg]

sorry for answering to myself, but someone (:-) send me a mail with the 
message

> Fixed in -bk on Sunday.

Thx :-)


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

[PATCH] ppc64: Missing call to ioremap in pci_iomap()

[Benjamin Herrenschmidt]

On Mon, 2005-01-24 at 15:46 -0600, Kumar Gala wrote: 
> The PPC version of pci_iomap seems to be missing a call to ioremap. This 
> patch corrects that oversight and has been tested on a IBM PPC750FX Eval 
> board.

Looks like the ppc64 version as well !

This patch adds the missing ioremap call to pci_iomap on ppc64.

Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

Index: linux-work/arch/ppc64/kernel/iomap.c
===
--- linux-work.orig/arch/ppc64/kernel/iomap.c   2005-01-24 11:42:36.0 
+1100
+++ linux-work/arch/ppc64/kernel/iomap.c2005-01-25 13:33:13.0 
+1100
@@ -113,7 +113,7 @@
if (flags & IORESOURCE_IO)
return ioport_map(start, len);
if (flags & IORESOURCE_MEM)
-   return (void __iomem *) start;
+   return ioremap(start, len);
/* What? */
return NULL;
 }




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/7] posix-timers: CPU clock support for POSIX timers

[Christoph Lameter]

On Mon, 24 Jan 2005, George Anzinger wrote:

> > The apparent pervasive changes to posix-timers.c are simply that some
> > fields of struct k_itimer have changed name and moved into a union.
> > This was appropriate since the data structures required for the existing
> > real-time timer support and for the new thread/process CPU-time timers are
> > quite different.
>
> Possibly you could bury these name changes in defines.  I suspect the code 
> would
> be easier to read and that we really don't need to be reminded that it is a
> union on each reference.

It would be great to have a kind of private field that other clocks (like
clock drivers) could use for their purposes. mmtimer f.e. does use some
of the fields for the tick based timers for its purposes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ppc32: fix powersave with interrupts disabled

[Benjamin Herrenschmidt]

On Mon, 2005-01-24 at 15:51 -0600, Kumar Gala wrote:
> It looks like the problem has to do with entering the powersave routine 
> with irqs disabled. Here is a patch that will only enter powersave if irqs 
> are enabled.
> 
> Entering powersave on PPC while irqs are disabled causes a hang. Only 
> enter powersave if irqs are disabled.

I have a different fix which is to re-enable them (basically to move the
local_irq_disable we do in #ifdef CONFIG_SMP above the whole block,
removing the #else case).

I'm waiting for Ingo's ack about what exact race he's trying to fix
though...

Ben.


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

Re: [PATCH 4/7] posix-timers: CPU clock support for POSIX timers

[George Anzinger]

Roland McGrath wrote:
POSIX requires that when you claim _POSIX_CPUTIME and _POSIX_THREAD_CPUTIME,
not only the clock_* calls but also timer_* calls must support the thread
and process CPU time clocks.  This patch provides that support, building on
my recent additions to support these clocks in the POSIX clock_* interfaces.
This patch will not work without those changes, as well as the patch fixing
the timer lock-siglock deadlock problem.
The apparent pervasive changes to posix-timers.c are simply that some
fields of struct k_itimer have changed name and moved into a union.
This was appropriate since the data structures required for the existing
real-time timer support and for the new thread/process CPU-time timers are
quite different.
Possibly you could bury these name changes in defines.  I suspect the code would 
be easier to read and that we really don't need to be reminded that it is a 
union on each reference.

--
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/7] posix-timers: tidy up clock interfaces and consolidate dispatch logic

[George Anzinger]

Where were you when I was writing this stuff :).  I agree with most all of it, 
save the following:

>  /*
> + * Define this to initialize every k_clock function table so all its
> + * function pointers are non-null, and always do indirect calls through the
> + * table.  Leave it undefined to instead leave null function pointers and
> + * decide at the call sites between a direct call (maybe inlined) to the
> + * default function and an indirect call through the table when it's filled
> + * in.  Which style is preferable is whichever performs better in the
> + * common case of using the default functions.
> +#define CLOCK_DISPATCH_DIRECT
As I understand it modern machines, the indirect call does really bad things to 
the pipeline.  The default call, even preceeded by the if, will be much faster 
by this reasoning.  I would, therefor, prefer not defining CLOCK_DISPATCH_DIRECT.

--
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: undefined references

[Valdis . Kletnieks]

On Mon, 24 Jan 2005 19:04:53 EST, John Richard Moser said:

> fs/built-in.o(.text+0xe413): In function `link_path_walk':
> : undefined reference to `gr_inode_follow_link'
> fs/built-in.o(.text+0xe933): In function `link_path_walk':
> : undefined reference to `gr_inode_follow_link'
> fs/built-in.o(.text+0x10c28): In function `sys_link':
> : undefined reference to `gr_inode_hardlink'
> fs/built-in.o(.text+0x10c52): In function `sys_link':
> : undefined reference to `gr_inode_handle_create'
> make: *** [.tmp_vmlinux1] Error 1
> 
> What would cause this kind of error?

link_path_walk() still has a reference to gr_inode_follow_link (the code
you probably want to move to an LSM exit), and sys_ling() still calls
gr_inode_hardlink() and gr_inode_handle_create() - but the actual functions
you're calling either don't exist anymore, or they didn't get compiled and 
linked
in.  If those functions are supposed to exist, you need to get them into a .o.
If those are (as I suspect) becoming LSM exit hooks, then you need to clean up
the direct calls in link_path_walk() and sys_link().


pgpXY6B6tSTT6.pgp
Description: PGP signature

Re: [PATCH] BUG in io_destroy (fs/aio.c:1248)

[Daniel McNeil]

On Mon, 2005-01-24 at 16:58, Andrew Morton wrote:
> "Darrick J. Wong" <[EMAIL PROTECTED]> wrote:
> >
> > Andrew Morton wrote:
> > 
> > > So...  Will someone be sending a new patch?
> > 
> > Here's a cheesy patch that simply marks the ioctx as dead before
> > destroying it.
> 
> super-cheesy, given that `ctx' is an unsigned long.
> 
> > +   spin_lock_irq(>ctx_lock);
> > +   ctx->dead = 1;
> > +   spin_unlock_irq(>ctx_lock);
> > +
> 
> Even with this fixed up, the locking looks very odd.
> 
> Needs more work, please.  Or we just run with the original patch which I
> assume was tested.  It's a rare error path and performance won't matter.

The use of 'dead' looks very strange.  It is set to 1 in
aio_cancel_all() while holding spin_lock_irq(>ctx_lock);
but it is set to 1 in io_destroy() holding
write_lock(>ioctx_list_lock);

The io_destroy() comment says
"Protects against races with itself via ->dead."

I assume the race the comment is talking about is
multiple threads calling io_destroy() on the same
ctx.  io_destroy() in only called from sys_io_destroy() or
from sys_io_setup() in the failure case that is trying
to be fixed.

aio_cancel_all() is only called from exit_aio() when the
mm is going away.  So this path is using 'dead' for something
else since the mm cannot go away twice (and there cannot be
an io_destroy() in progress or the mm would not be going away).

The overloading of 'dead' is ugly and confusing.

The use of spin_lock_irq(>ctx_lock) in sys_io_setup()
does not do any good AFAICT.

Daniel





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] new timeofday core subsystem (v. A2)

[Christoph Lameter]

On Mon, 24 Jan 2005, john stultz wrote:

> We talked about this last time. I do intend to re-work ntp_scale() so
> its not a function call, much as you describe above.
>
> hopelessly endeavoring,

hehe But seriously: The easiest approach may be to modify the time
sources to allow a fine tuning of the scaling factor. That way ntp_scale
may be moved into tick processing where it would adjust the scaling of the
time sources up or downward. Thus no ntp_scale in the monotonic clock
processing anymore.

Monotonic clocks could be calculated

monotime = ns_at_last_tick + (time_source_cycles_since_tick *
current_scaling_factor) >> shift_factor.

This would also be easy to implement in asm if necessary.

tick processing could then increment or decrement the current scaling
factor to minimize the error between ticks. It could also add
nanoseconds to ns_at_last_tick to correct the clock forward.

With the appropiate shift_factor one should be able to fine tune time much
more accurately than ntp_scale would do. Over time the necessary
corrections could be minimized to just adding a few ns once in a while.

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

Re: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram b

[Petr Vandrovec]

On 25 Jan 05 at 1:41, Sytse Wielinga wrote:
> Linus, could you please put skb_copy_datagram back in place? It's not used
> anymore in the kernel, but the vmnet module (in vmware) still uses this
> interface to skb_copy_datagram_iovec.

There is no reason for doing this.  Just grab latest vmmon & vmnet
from http://platan.vc.cvut.cz/ftp/pub/vmware/vmware-any-any-update89.tar.gz,
and enjoy latest and greatest modules.  Besides this one you'll get lot
of other fixes and improvements for free ;-)
Petr Vandrovec

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

Re: 2.6.11-rc2-mm1 (AE_AML_NO_OPERAND)

[Len Brown]

On Mon, 2005-01-24 at 20:01, Brice Goglin wrote:
> Andrew Morton a écrit :

> 
> ACPI does not work anymore on my Compaq Evo N600c
> (no thermal zone, no fan, no battery, ...).
> It works great on Linus' 2.6.11-rc2, and (from what I remember)
> it was working on the last -mm releases I tried.
> 
> Here's a bunch of lines from dmesg.
...
> 
> 
> exresnte-0133 [24] ex_resolve_node_to_val: No object attached to node
> e7fcd548
>   dswexec-0446 [21] ds_exec_end_op: [Acquire]: Could not
> resolve operands, AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed
> [\_SB_.C03E.C053.C0D1.C12A] (Node c15e5788), AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed [\_SB_.C1A2._PSR]
> (Node c15ed8c8), AE_AML_NO_OPERAND
>   acpi_ac-0098 [12] acpi_ac_get_state : Error reading AC Adapter
> state
> ACPI: Battery Slot [C19F] (battery absent)
> ACPI: Battery Slot [C1A0] (battery absent)
> ACPI: Power Button (FF) [PWRF]
> ACPI: Sleep Button (CM) [C1A3]
> ACPI: Lid Switch [C1A4]
> ACPI: Fan [C1F6] (off)
> ACPI: Fan [C1F7] (off)
> ACPI: Fan [C1F8] (off)
> ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
> exresnte-0133 [31] ex_resolve_node_to_val: No object attached to node
> e7fcd548
>   dswexec-0446 [28] ds_exec_end_op: [Acquire]: Could not
> resolve operands, AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed
> [\_SB_.C03E.C053.C0D1.C11A] (Node c15e5b48), AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed [\_TZ_.C11A] (Node
> c15ef3c8), AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed [\_TZ_.C1F1] (Node
> c15ef0c8), AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed [\_TZ_.TZ1_._TMP]
> (Node c15f05c8), AE_AML_NO_OPERAND
> ACPI wakeup devices:
> C052 C17E C185 C0A4 C0AA C19F C1A0 C1A3 C1A4
> ACPI: (supports S0 S1 S3 S4 S4bios S5)
> exresnte-0133 [26] ex_resolve_node_to_val: No object attached to node
> e7fcd548
>   dswexec-0446 [23] ds_exec_end_op: [Acquire]: Could not
> resolve operands, AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed
> [\_SB_.C03E.C053.C0D1.C119] (Node c15e5b88), AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed [\_GPE._L10] (Node
> c15f0248), AE_AML_NO_OPERAND
> evgpe-0552: *** Error: AE_AML_NO_OPERAND while evaluating method
> [_L10] for GPE[ 0]

Please patch -Rp1 this file:
http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/broken-out/bk-acpi.patch
to verify that the issue goes away when backing out the ACPI part of the
latest mm patch.

We'll likely need your acpidmp output to bottom out on this.
Please open a bug here:

http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
Category: AML-interpreter

and attach (don't paste) the output from acpidmp, available in /usr/sbin
or in pmtools here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
along with the complete dmesg -s64000 output of the failure case.

thanks,
-Len


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

Re: [2.6.11-rc2] kernel BUG at fs/reiserfs/journal.c:2966!

[Andrew Morton]

Ramón Rey Vicente <[EMAIL PROTECTED]> wrote:
>
> I get this with 2.6.11-rc2
> 
>  kernel BUG at fs/reiserfs/journal.c:2966!

Is this repeatable?

/* we aren't allowed to close a nested transaction on a different
** filesystem from the one in the task struct
*/
if (cur_th->t_super != th->t_super)
  BUG() ;

very strange.  What mount options are you using on that fs?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.27-1-386 compiling 2.6.10 getting errors

[Aurash Mahbod]

I am compiling 2.6.10 and am getting crc errors.

lib/gen_crc32table.c:10: error: parse error before "crc32table_le"
lib/gen_crc32table.c:10: warning: type defaults to `int' in
declaration of `crc32table_le'
lib/gen_crc32table.c:10: warning: data definition has no type or storage class
lib/gen_crc32table.c:11: error: parse error before "crc32table_be"
lib/gen_crc32table.c:11: warning: type defaults to `int' in
declaration of `crc32table_be'
lib/gen_crc32table.c:11: warning: data definition has no type or storage class
lib/gen_crc32table.c: In function `crc32init_le':
lib/gen_crc32table.c:23: error: `uint32_t' undeclared (first use in
this function)
lib/gen_crc32table.c:23: error: (Each undeclared identifier is
reported only once
lib/gen_crc32table.c:23: error: for each function it appears in.)
lib/gen_crc32table.c:23: error: parse error before "crc"
lib/gen_crc32table.c:28: error: `crc' undeclared (first use in this function)
lib/gen_crc32table.c: In function `crc32init_be':
lib/gen_crc32table.c:40: error: `uint32_t' undeclared (first use in
this function)
lib/gen_crc32table.c:40: error: parse error before "crc"
lib/gen_crc32table.c:45: error: `crc' undeclared (first use in this function)
lib/gen_crc32table.c: At top level:
lib/gen_crc32table.c:51: error: parse error before "table"
lib/gen_crc32table.c:52: warning: function declaration isn't a prototype
lib/gen_crc32table.c: In function `output_table':
lib/gen_crc32table.c:55: error: `len' undeclared (first use in this function)
lib/gen_crc32table.c:58: error: `trans' undeclared (first use in this function)
lib/gen_crc32table.c:58: error: `table' undeclared (first use in this function)
make[2]: *** [lib/gen_crc32table] Error 1
make[1]: *** [lib] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.10'
make: *** [stamp-build] Error 2

Motherboard: Soyo Dragon Plus
CPU: Athlon XP 1800+
ram: 512MB PC2700
video card: nvidia GeForce 4 4400ti

thanks for the help!

-Aurash Mahbod
[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 12/13] ACL umask handling workaround in nfs client

[Andreas Gruenbacher]

Hello,

this patch has an NFSv2 problem that I haven't tripped over until today. The 
fix is this:

--- 8< ---
Fix NFSv2 null pointer access

With NFSv2 we would try to follow a NULL getacl and setacl function
pointer here. Add the missing checks.

Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>

Index: linux-2.6.10/fs/nfs/dir.c
===
--- linux-2.6.10.orig/fs/nfs/dir.c
+++ linux-2.6.10/fs/nfs/dir.c
@@ -984,6 +984,9 @@ static int nfs_set_default_acl(struct in
struct posix_acl *dfacl, *acl;
int error = 0;
 
+   if (NFS_PROTO(inode)->version != 3 ||
+   !NFS_PROTO(dir)->getacl || !NFS_PROTO(inode)->setacls)
+   return 0;
dfacl = NFS_PROTO(dir)->getacl(dir, ACL_TYPE_DEFAULT);
if (IS_ERR(dfacl)) {
error = PTR_ERR(dfacl);


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

[RFC][PATCH] new timeofday arch specific timesources (v. A2)

[john stultz]

All,
This patch implements most of the time sources for i386, x86-64, and
ppc64 (tsc, pit, cyclone, acpi-pm, hpet and timebase). It applies on top
of my linux-2.6.11-rc2_timeofday-arch_A2 patch. It provides real
timesources (opposed to the example jiffies timesource) that can be used
for more realistic testing.

This patch is the shabbiest of the three. It needs to be broken up, and
cleaned. The i386_pit.c is broken. Also, acpi_pm and hpet need to be
made generic so they can be shared between i386 and x86-64. But for now
it will get you going so you can test and play with the core code.

New in this release:
o ppc64_timebase code
o move tsc code to TIMESOURCE_CYCLES
o add tsc_update_callback for cpufreq changes (untested)
o move hpet code to TIMESOURCE_MMIO_32

thanks
-john

linux-2.6.11-rc2_timeofday-timesources_A2.patch
===
diff -Nru a/arch/i386/kernel/Makefile b/arch/i386/kernel/Makefile
--- a/arch/i386/kernel/Makefile 2005-01-24 13:36:22 -08:00
+++ b/arch/i386/kernel/Makefile 2005-01-24 13:36:22 -08:00
@@ -7,7 +7,7 @@
 obj-y  := process.o semaphore.o signal.o entry.o traps.o irq.o vm86.o \
ptrace.o time.o ioport.o ldt.o setup.o i8259.o sys_i386.o \
pci-dma.o i386_ksyms.o i387.o dmi_scan.o bootflag.o \
-   doublefault.o quirks.o
+   doublefault.o quirks.o tsc.o
 
 obj-y  += cpu/
 obj-$(!CONFIG_NEWTOD)  += timers/
diff -Nru a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
--- a/arch/i386/kernel/setup.c  2005-01-24 13:36:22 -08:00
+++ b/arch/i386/kernel/setup.c  2005-01-24 13:36:22 -08:00
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "setup_arch_pre.h"
 #include 
 
@@ -1439,6 +1440,7 @@
conswitchp = _con;
 #endif
 #endif
+   tsc_init();
 }
 
 #include "setup_arch_post.h"
diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c   2005-01-24 13:36:22 -08:00
+++ b/arch/i386/kernel/time.c   2005-01-24 13:36:22 -08:00
@@ -461,6 +461,7 @@
 
 void __init time_init(void)
 {
+#ifndef CONFIG_NEWTOD
 #ifdef CONFIG_HPET_TIMER
if (is_hpet_capable()) {
/*
@@ -478,6 +479,7 @@
 
cur_timer = select_timer();
printk(KERN_INFO "Using %s for high-res timesource\n",cur_timer->name);
+#endif
 
time_init_hook();
 }
diff -Nru a/arch/i386/kernel/timers/common.c b/arch/i386/kernel/timers/common.c
--- a/arch/i386/kernel/timers/common.c  2005-01-24 13:36:22 -08:00
+++ b/arch/i386/kernel/timers/common.c  2005-01-24 13:36:22 -08:00
@@ -22,8 +22,6 @@
  * device.
  */
 
-#define CALIBRATE_TIME (5 * 120/HZ)
-
 unsigned long __init calibrate_tsc(void)
 {
mach_prepare_counter();
diff -Nru a/arch/i386/kernel/tsc.c b/arch/i386/kernel/tsc.c
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/arch/i386/kernel/tsc.c2005-01-24 13:36:22 -08:00
@@ -0,0 +1,111 @@
+#include 
+#include 
+#include 
+#include 
+#include "mach_timer.h"
+
+unsigned long cpu_freq_khz;
+#ifdef CONFIG_NEWTOD
+int tsc_disable;
+#endif
+
+void tsc_init(void)
+{
+   unsigned long long start, end;
+   unsigned long count;
+   u64 delta64;
+   int i;
+
+   /* repeat 3 times to make sure the cache is warm */
+   for(i=0; i < 3; i++) {
+   mach_prepare_counter();
+   rdtscll(start);
+   mach_countup();
+   rdtscll(end);
+   }
+   delta64 = end - start;
+
+   /* cpu freq too fast */
+   if(delta64 > (1ULL<<32))
+   return;
+   /* cpu freq too slow */
+   if (delta64 <= CALIBRATE_TIME)
+   return;
+
+   delta64 *= 1000;
+   do_div(delta64,CALIBRATE_TIME);
+   cpu_freq_khz = (unsigned long)delta64;
+
+   cpu_khz = cpu_freq_khz;
+
+   printk("Detected %lu.%03lu MHz processor.\n",
+   cpu_khz / 1000, cpu_khz % 1000);
+
+}
+
+
+/* All of the code below comes from arch/i386/kernel/timers/timer_tsc.c
+ * XXX: severly needs better comments and the ifdef's killed.
+ */
+
+#ifdef CONFIG_CPU_FREQ
+static unsigned int cpufreq_init = 0;
+
+/* If the CPU frequency is scaled, TSC-based delays will need a different
+ * loops_per_jiffy value to function properly.
+ */
+
+static unsigned int  ref_freq = 0;
+static unsigned long loops_per_jiffy_ref = 0;
+
+#ifndef CONFIG_SMP
+static unsigned long cpu_khz_ref = 0;
+#endif
+
+static int time_cpufreq_notifier(struct notifier_block *nb,
+   unsigned long val, void *data)
+{
+   struct cpufreq_freqs *freq = data;
+
+   if (val != CPUFREQ_RESUMECHANGE)
+   write_seqlock_irq(_lock);
+   if (!ref_freq) {
+   ref_freq = freq->old;
+   loops_per_jiffy_ref = cpu_data[freq->cpu].loops_per_jiffy;
+#ifndef CONFIG_SMP
+   cpu_khz_ref = cpu_khz;
+#endif
+   }
+
+   if ((val == CPUFREQ_PRECHANGE  && freq->old < freq->new) ||
+   

Re: sata_vsc problem.... Please help me.

[David Sims]

On Mon, 24 Jan 2005, Marcelo Tosatti wrote:

> On Mon, Jan 24, 2005 at 04:09:08PM -0600, David Sims wrote:
> > Hi,
> > 
> >   With kernel 2.6.10 on Intel (Dell Powervault 745N) When I insert the
> > sata_vsc module via 'modprobe sata_vsc' from the command line, the module
> > immediately recognizes the controller card and then enumerates the
> > attached disks. During this process I am getting errors logged in syslog
> > for each disk as follows:
> > 
> > Jan 24 13:55:37 linux kernel: irq 3: nobody cared!
> > Jan 24 13:55:37 linux kernel:  [] __report_bad_irq+0x22/0x90
> > Jan 24 13:55:37 linux kernel:  [] note_interrupt+0x58/0x90
> > Jan 24 13:55:37 linux kernel:  [] __do_IRQ+0xd8/0xe0
> > Jan 24 13:55:37 linux kernel:  [] do_IRQ+0x1a/0x30
> > Jan 24 13:55:37 linux kernel:  [] common_interrupt+0x1a/0x20
> > Jan 24 13:55:37 linux kernel:  [] __do_softirq+0x30/0x90
> > Jan 24 13:55:37 linux kernel:  [] do_softirq+0x35/0x40
> > Jan 24 13:55:37 linux kernel:  [] do_IRQ+0x1f/0x30
> > Jan 24 13:55:37 linux kernel:  [] common_interrupt+0x1a/0x20
> > Jan 24 13:55:37 linux kernel:  [] default_idle+0x0/0x40
> > Jan 24 13:55:37 linux kernel:  [] default_idle+0x24/0x40
> > Jan 24 13:55:37 linux kernel:  [] cpu_idle+0x2e/0x40
> > Jan 24 13:55:37 linux kernel:  [] start_kernel+0x15b/0x190
> > Jan 24 13:55:37 linux kernel: handlers:
> > Jan 24 13:55:37 linux kernel: [] (ide_intr+0x0/0x120)
> > Jan 24 13:55:37 linux kernel: [] (ide_intr+0x0/0x120)
> > Jan 24 13:55:37 linux kernel: [] (vsc_sata_interrupt+0x0/0xa0
> > [sata_vsc])
> > Jan 24 13:55:37 linux kernel: Disabling IRQ #3
> > 
> > and in /proc/interrupts the count for irq3 advances by 500,000 (i.e.,
> > 100,000 for the controller and 100,000 for each attached disk).
> > 
> > 
> >   It seems to me that this driver is initializing itself and enabling
> > interrupts before it is fully loaded and ready to deal with them 
> > 
> >   If I insert the module during the boot up process, the machine just
> > hangs trying to read/identify the first disk... 
> > 
> >   Is there a way to disable or ignore these interrupts until the driver is
> > fully loaded, the disks are identified and all of the necessary
> > housekeeping is finished and the driver is finished loading?? 
> >
> >   Once the sata_vsc module finishes identifying the attached drives and
> > the 'modprobe sata_vsc' returns to the command prompt the errors stop
> > coming and it seems to work just fine You can fdisk and format the
> > disks and all is well... If I could just get it load at boot time I would
> > be happy
> > 
> >   Any advice would be welcome at this point. ;)
> 
> 
> You can use the following to disable the interrupt debugging: 
> 
> Documentation/kernel-parameters.txt:
> 
> noirqdebug  [IA-32] Disables the code which attempts to detect and
> disable unhandled interrupt sources.
> 
> But there is definately something wrong with the driver. Jeff?
> 

Hi,

  With 'noirqdebug' passed to the kernel, then it just hangs while trying
to talk to the first disk much like calling the driver from
rc.modules

Dave


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

patch to enable Nvidia v5336 on v2.6.11 kernel (was Re: inter_module_get and __symbol_get)

[David Mosberger]

> On Tue, 25 Jan 2005 10:03:01 +1100, Keith Owens  said:

  Keith> I have always hated the dynamic resolution model used by
  Keith> DRM/AGP and (originally) MTD.

Well, the attached patch does the trick for me for Nvidia driver v5336
on ia64.  It compiles with a minimum amount of fuss with gcc v3.4
(just a handful of warnings about deprecated pm_{un,}register() and
inter_module_put()).

I have only tried it against 2.6.11-rc2 (really: Linus' bk tree as of
today) but I hope I didn't screw up backwards compatibility for older
kernels too badly.

Note: I removed the super-user sanity check---I hate that one since it
prevents me from building the module on an NFS-mounted file-system.
If you don't care for that bit, just omit the patch to conftest.sh.

--david

diff -urN -x nv_compiler.h -x '*.mod.c' -x '*.ko' -x '*.d' -x '*.o' -x '*~' -x 
build -x Makefile -x '.*' 
NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/Makefile.kbuild 
NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/Makefile.kbuild
--- NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/Makefile.kbuild  2004-01-16 
12:46:59.0 -0800
+++ NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/Makefile.kbuild   
2005-01-24 15:49:37.0 -0800
@@ -73,7 +73,7 @@
 #
 
 EXTRA_CFLAGS += -I$(src)
-EXTRA_CFLAGS += -Wall -Wimplicit -Wreturn-type -Wswitch -Wformat 
-Wchar-subscripts -Wparentheses -Wpointer-arith  -Wno-multichar  -Werror -O -MD 
$(DEFINES) $(INCLUDES) -Wno-cast-qual -Wno-error
+EXTRA_CFLAGS += -Wall -Wimplicit -Wreturn-type -Wswitch -Wformat 
-Wchar-subscripts -Wparentheses -Wno-multichar  -Werror -O2 -MD $(DEFINES) 
$(INCLUDES) -Wno-cast-qual -Wno-error
 
 #
 # We rely on these two definitions below; if they aren't set, we set them to
@@ -199,7 +199,7 @@
 #
 
 module: gcc-sanity-check
-   @make CC=$(CC) $(KBUILD_PARAMS) modules; \
+   @make CC=$(CC) CROSS_COMPILE=$(CROSS_COMPILE) $(KBUILD_PARAMS) modules; 
\
if ! [ -f $(MODULE_OBJECT) ]; then \
  echo "$(MODULE_OBJECT) failed to build!"; \
  exit 1; \
diff -urN -x nv_compiler.h -x '*.mod.c' -x '*.ko' -x '*.d' -x '*.o' -x '*~' -x 
build -x Makefile -x '.*' 
NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/conftest.sh 
NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/conftest.sh
--- NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/conftest.sh  2004-01-16 
12:46:59.0 -0800
+++ NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/conftest.sh   
2005-01-24 15:49:33.0 -0800
@@ -129,7 +129,7 @@
 echo -en "\033[1;31m";
 echo -e  "*** Failed super-user sanity check. Bailing out! ***";
 echo -en "\033[0m";
-exit 1
+exit 0
 else
 exit 0
 fi
diff -urN -x nv_compiler.h -x '*.mod.c' -x '*.ko' -x '*.d' -x '*.o' -x '*~' -x 
build -x Makefile -x '.*' NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/nv-linux.h 
NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/nv-linux.h
--- NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/nv-linux.h   2004-01-16 
12:46:59.0 -0800
+++ NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/nv-linux.h
2005-01-24 16:09:14.0 -0800
@@ -24,7 +24,7 @@
 #  define KERNEL_2_4
 #elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 0)
 #  error This driver does not support 2.5 kernels!
-#elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 7, 0) && defined(NVCPU_X86)
+#elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 7, 0)
 #  define KERNEL_2_6
 #else
 #  error This driver does not support development kernels!
@@ -293,13 +293,13 @@
 #if defined(NVCPU_IA64)
 #define NV_VMALLOC(ptr, size) \
 { \
-(void *) (ptr) = vmalloc_dma(size); \
+(ptr) = __vmalloc(size, GFP_KERNEL|GFP_DMA, PAGE_KERNEL); \
 VM_ALLOC_RECORD(ptr, size, "vm_alloc"); \
 }
 #else
 #define NV_VMALLOC(ptr, size) \
 { \
-(void *) (ptr) = vmalloc_32(size); \
+(ptr) = vmalloc_32(size); \
 VM_ALLOC_RECORD(ptr, size, "vm_alloc"); \
 }
 #endif
@@ -333,13 +333,13 @@
  */
 #define NV_KMALLOC(ptr, size) \
 { \
-(void *) (ptr) = kmalloc(size, GFP_KERNEL); \
+(ptr) = kmalloc(size, GFP_KERNEL); \
 KM_ALLOC_RECORD(ptr, size, "km_alloc"); \
 }
 
 #define NV_KMALLOC_ATOMIC(ptr, size) \
 { \
-(void *) (ptr) = kmalloc(size, GFP_ATOMIC); \
+(ptr) = kmalloc(size, GFP_ATOMIC); \
 KM_ALLOC_RECORD(ptr, size, "km_alloc_atomic"); \
 }  
 
@@ -352,7 +352,7 @@
 
 #define NV_GET_FREE_PAGES(ptr, order) \
 { \
-(void *) (ptr) = __get_free_pages(NV_GFP_HW, order); \
+(ptr) = __get_free_pages(NV_GFP_HW, order); \
 }
 
 #define NV_FREE_PAGES(ptr, order) \
@@ -454,14 +454,22 @@
  * relevant releases to date use it. This version was backported to 2.4 
  * without means to identify the change, hence this hack.
  */
-#if defined(REMAP_PAGE_RANGE_5)
-#define NV_REMAP_PAGE_RANGE(a, b...)remap_page_range(vma, a, ## b)
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 11)
+#define 

[PATCH 4/4] cleanup firmware loading printks

[Johannes Stezenbach]

- [DVB] frontends: sp887x: improve confusing firmware loading messages

Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>

diff -rupN linux-2.6.11-rc2-bk2/drivers/media/dvb/frontends/sp8870.c 
linux-2.6.11-rc2-bk2-dvb/drivers/media/dvb/frontends/sp8870.c
--- linux-2.6.11-rc2-bk2/drivers/media/dvb/frontends/sp8870.c   2004-12-24 
22:35:40.0 +0100
+++ linux-2.6.11-rc2-bk2-dvb/drivers/media/dvb/frontends/sp8870.c   
2005-01-25 00:40:10.0 +0100
@@ -313,7 +313,7 @@ static int sp8870_init (struct dvb_front
 
 
/* request the firmware, this will block until someone uploads it */
-   printk("sp8870: waiting for firmware upload...\n");
+   printk("sp8870: waiting for firmware upload (%s)...\n", 
SP8870_DEFAULT_FIRMWARE);
if (state->config->request_firmware(fe, , SP8870_DEFAULT_FIRMWARE)) {
printk("sp8870: no firmware upload (timeout or file not 
found?)\n");
release_firmware(fw);
@@ -325,6 +325,7 @@ static int sp8870_init (struct dvb_front
release_firmware(fw);
return -EIO;
}
+   printk("sp8870: firmware upload complete\n");
 
/* enable TS output and interface pins */
sp8870_writereg(state, 0xc18, 0x00d);
diff -rupN linux-2.6.11-rc2-bk2/drivers/media/dvb/frontends/sp887x.c 
linux-2.6.11-rc2-bk2-dvb/drivers/media/dvb/frontends/sp887x.c
--- linux-2.6.11-rc2-bk2/drivers/media/dvb/frontends/sp887x.c   2004-12-24 
22:35:24.0 +0100
+++ linux-2.6.11-rc2-bk2-dvb/drivers/media/dvb/frontends/sp887x.c   
2005-01-25 00:41:31.0 +0100
@@ -518,7 +518,7 @@ static int sp887x_init(struct dvb_fronte
 
if (!state->initialised) {
/* request the firmware, this will block until someone uploads it */
-   printk("sp887x: waiting for firmware upload...\n");
+   printk("sp887x: waiting for firmware upload (%s)...\n", 
SP887X_DEFAULT_FIRMWARE);
ret = state->config->request_firmware(fe, , 
SP887X_DEFAULT_FIRMWARE);
if (ret) {
printk("sp887x: no firmware upload (timeout or file not 
found?)\n");
@@ -531,6 +531,7 @@ static int sp887x_init(struct dvb_fronte
release_firmware(fw);
return ret;
}
+   printk("sp887x: firmware upload complete\n");
state->initialised = 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: 2.6.11-rc2-mm1

[Brice Goglin]

Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
- On my test box there is no flashing cursor on the vga console.  Known bug,
  please don't report it.
  Binary searching shows that the bug was introduced by
  cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
Hi Andrew,
ACPI does not work anymore on my Compaq Evo N600c
(no thermal zone, no fan, no battery, ...).
It works great on Linus' 2.6.11-rc2, and (from what I remember)
it was working on the last -mm releases I tried.
Here's a bunch of lines from dmesg.
.config and lspci attached.
Regards,
Brice
exresnte-0133 [24] ex_resolve_node_to_val: No object attached to node 
e7fcd548
 dswexec-0446 [21] ds_exec_end_op: [Acquire]: Could not resolve 
operands, AE_AML_NO_OPERAND
 psparse-1138: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C12A] 
(Node c15e5788), AE_AML_NO_OPERAND
 psparse-1138: *** Error: Method execution failed [\_SB_.C1A2._PSR] (Node 
c15ed8c8), AE_AML_NO_OPERAND
 acpi_ac-0098 [12] acpi_ac_get_state : Error reading AC Adapter state
ACPI: Battery Slot [C19F] (battery absent)
ACPI: Battery Slot [C1A0] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [C1A3]
ACPI: Lid Switch [C1A4]
ACPI: Fan [C1F6] (off)
ACPI: Fan [C1F7] (off)
ACPI: Fan [C1F8] (off)
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
exresnte-0133 [31] ex_resolve_node_to_val: No object attached to node e7fcd548
 dswexec-0446 [28] ds_exec_end_op: [Acquire]: Could not resolve 
operands, AE_AML_NO_OPERAND
 psparse-1138: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C11A] 
(Node c15e5b48), AE_AML_NO_OPERAND
 psparse-1138: *** Error: Method execution failed [\_TZ_.C11A] (Node c15ef3c8), 
AE_AML_NO_OPERAND
 psparse-1138: *** Error: Method execution failed [\_TZ_.C1F1] (Node c15ef0c8), 
AE_AML_NO_OPERAND
 psparse-1138: *** Error: Method execution failed [\_TZ_.TZ1_._TMP] (Node 
c15f05c8), AE_AML_NO_OPERAND
ACPI wakeup devices:
C052 C17E C185 C0A4 C0AA C19F C1A0 C1A3 C1A4
ACPI: (supports S0 S1 S3 S4 S4bios S5)
exresnte-0133 [26] ex_resolve_node_to_val: No object attached to node e7fcd548
 dswexec-0446 [23] ds_exec_end_op: [Acquire]: Could not resolve 
operands, AE_AML_NO_OPERAND
 psparse-1138: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C119] 
(Node c15e5b88), AE_AML_NO_OPERAND
 psparse-1138: *** Error: Method execution failed [\_GPE._L10] (Node c15f0248), 
AE_AML_NO_OPERAND
   evgpe-0552: *** Error: AE_AML_NO_OPERAND while evaluating method [_L10] for 
GPE[ 0]


config.gz
Description: application/gunzip


lspci.gz
Description: application/gunzip

Re: [PATCH] drivers/block/scsi_ioctl.c, Video DVD playback support

[Alan Cox]

On Llu, 2005-01-24 at 22:10, Elias da Silva wrote:
> This is exactly the point: if the kernel wants to be safe, the
> authentication procedure should be totally implemented in the kernel
> and be protected against further changes via "alternative" ways...
> but it isn't now and probably won't be although it could be.

It provides the DVD_AUTH ioctls to handle this. Why are you banging raw
commands at hardware when there is an abstraction for it ?

Someone did actually have a demo of a small fs that allowed you to
fiddle with the status but possibly the code could get smarter for
"exclusive user of media". I'm not sure if that is worth it.


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

Re: [PATCH] Remove special case in kmem_getpages()

[Matthew Wilcox]

On Mon, Jan 24, 2005 at 07:58:03PM -0500, Brian Gerst wrote:
> Matthew Wilcox wrote:
> >__get_free_pages() calls alloc_pages, finds the page_address() and
> >throws away the struct page *.  Slab then calls virt_to_page to get it
> >back again.  Much more efficient for slab to call alloc_pages itself,
> >as well as making the NUMA and non-NUMA cases more similarr to each other.
> 
> Here is a better patch:

I disagree.  This disables the alloc_pages_current() optimisation.
I considered this option and rejected it.

> Remove the special case of nodeid == -1.  Instead, use numa_node_id() 
> when calling cache_grow().
> 
> Signed-off-by: Brian Gerst <[EMAIL PROTECTED]>

> diff -urN linux-2.6.11-rc2-bk/mm/slab.c linux/mm/slab.c
> --- linux-2.6.11-rc2-bk/mm/slab.c 2005-01-22 01:58:25.0 -0500
> +++ linux/mm/slab.c   2005-01-24 15:35:08.0 -0500
> @@ -893,17 +893,11 @@
>   int i;
>  
>   flags |= cachep->gfpflags;
> - if (likely(nodeid == -1)) {
> - addr = (void*)__get_free_pages(flags, cachep->gfporder);
> - if (!addr)
> - return NULL;
> - page = virt_to_page(addr);
> - } else {
> - page = alloc_pages_node(nodeid, flags, cachep->gfporder);
> - if (!page)
> - return NULL;
> - addr = page_address(page);
> - }
> +
> + page = alloc_pages_node(nodeid, flags, cachep->gfporder);
> + if (!page)
> + return NULL;
> + addr = page_address(page);
>  
>   i = (1 << cachep->gfporder);
>   if (cachep->flags & SLAB_RECLAIM_ACCOUNT)
> @@ -2065,7 +2059,7 @@
>  
>   if (unlikely(!ac->avail)) {
>   int x;
> - x = cache_grow(cachep, flags, -1);
> + x = cache_grow(cachep, flags, numa_node_id());
>   
>   // cache_grow can reenable interrupts, then ac could change.
>   ac = ac_data(cachep);


-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: inter_module_get and __symbol_get

[Jon Smirl]

On Tue, 25 Jan 2005 10:03:01 +1100, Keith Owens  wrote:
> On Mon, 24 Jan 2005 14:58:29 -0800,
> David Mosberger <[EMAIL PROTECTED]> wrote:
> >> On Tue, 25 Jan 2005 09:54:36 +1100, Keith Owens  said:
> >
> >  Keith> Does DRM support this model?

DRM will compile two different modules depending of the state of
CONFIG_AGP. A module compiled for a system with AGP will not load into
one without it.

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

Re: [PATCH] BUG in io_destroy (fs/aio.c:1248)

[Andrew Morton]

"Darrick J. Wong" <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> 
> > So...  Will someone be sending a new patch?
> 
> Here's a cheesy patch that simply marks the ioctx as dead before
> destroying it.

super-cheesy, given that `ctx' is an unsigned long.

> + spin_lock_irq(>ctx_lock);
> + ctx->dead = 1;
> + spin_unlock_irq(>ctx_lock);
> +

Even with this fixed up, the locking looks very odd.

Needs more work, please.  Or we just run with the original patch which I
assume was tested.  It's a rare error path and performance won't matter.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Remove special case in kmem_getpages()

[Brian Gerst]

Matthew Wilcox wrote:
__get_free_pages() calls alloc_pages, finds the page_address() and
throws away the struct page *.  Slab then calls virt_to_page to get it
back again.  Much more efficient for slab to call alloc_pages itself,
as well as making the NUMA and non-NUMA cases more similarr to each other.
Here is a better patch:
Remove the special case of nodeid == -1.  Instead, use numa_node_id() 
when calling cache_grow().

Signed-off-by: Brian Gerst <[EMAIL PROTECTED]>
diff -urN linux-2.6.11-rc2-bk/mm/slab.c linux/mm/slab.c
--- linux-2.6.11-rc2-bk/mm/slab.c   2005-01-22 01:58:25.0 -0500
+++ linux/mm/slab.c 2005-01-24 15:35:08.0 -0500
@@ -893,17 +893,11 @@
int i;
 
flags |= cachep->gfpflags;
-   if (likely(nodeid == -1)) {
-   addr = (void*)__get_free_pages(flags, cachep->gfporder);
-   if (!addr)
-   return NULL;
-   page = virt_to_page(addr);
-   } else {
-   page = alloc_pages_node(nodeid, flags, cachep->gfporder);
-   if (!page)
-   return NULL;
-   addr = page_address(page);
-   }
+
+   page = alloc_pages_node(nodeid, flags, cachep->gfporder);
+   if (!page)
+   return NULL;
+   addr = page_address(page);
 
i = (1 << cachep->gfporder);
if (cachep->flags & SLAB_RECLAIM_ACCOUNT)
@@ -2065,7 +2059,7 @@
 
if (unlikely(!ac->avail)) {
int x;
-   x = cache_grow(cachep, flags, -1);
+   x = cache_grow(cachep, flags, numa_node_id());

// cache_grow can reenable interrupts, then ac could change.
ac = ac_data(cachep);

Re: DVD burning still have problems

[Alan Cox]

On Llu, 2005-01-24 at 23:01, Kasper Sandberg wrote:
> > there are certainly chipset and CPU errata in this area.
> would this mean that i should not use cpu frequency scaling?

Worth an experiment but I'd be suprised if it was your fix. The more
data the better however 

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

Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking

[Edward Peschko]

On Mon, Jan 24, 2005 at 06:08:52PM -0500, Mike Frysinger wrote:
> On Monday 24 January 2005 05:24 pm, Edward Peschko wrote:
> > After spending *two weeks* on various ways of building glibc,
> > I'm convinced that the gnu/linux toolchain is in great danger of
> > losing interoperability.
> 
> sounds like what you want is already being tackled by OSDL and their Binary 
> Regression Testing group ...
> http://groups.osdl.org/apps/group_public/workgroup.php?wg_abbrev=binary_sig
> http://www.osdl.org/docs/isv_issues_and_binary_testing.pdf
> -mike

well of course the osdl is going to focus on this, but they need tools
and functionality to do it correctly.. 

In particular, the statement 'Vendor lock-in (at any level) is not 
desirable' is false - there *is* vendor lock-in, and the suggestion 
of relative pathing for LD_LIBRARY_PATH is just one way to migrate 
back to doing things the right way.


Distributions are basically hoist by their own petard - they need to 
support old legacy executables, which have nonstandard glibc's. And since
they need to support legacy executables in the past, they need 
to support them in the future.


What I'd envision is that the distributions split basically into two: 
executables using the old style glibc/libraries, and executables using the 
new, standard glibcs. There would be two paths,


/usr/bin

and

/usr/standard/bin


The first directory would contain old executables which haven't been ported to
the standard glibc. The second would contain executables that have. The relative
pathing in LD_LIBRARY_PATH would insure that each tree used the correct 
libraries.


In the process of making /usr/standard/bin, linux vendors would need
to make their rpms both path-neutral and build clean. However, they would
*not* need to hold up their release process until everything is ported - 
they could pick and choose which applications were the most important to 
port. Ultimately, /usr/standard/bin would go away, and be moved back to 
/usr/bin, and perhaps the cycle could begin again, with upgrades going into 
a new /usr/standard/bin.

Ed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] support up to six DVB cards

[Johannes Stezenbach]

- [DVB] core: add support for up to six DVB cards by using
  32bit dev_t capabilities

Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>

--- linux-2.6.11-rc2-bk2/drivers/media/dvb/dvb-core/dvbdev.c2004-12-24 
22:34:26.0 +0100
+++ linux-2.6.11-rc2-bk2-dvb/drivers/media/dvb/dvb-core/dvbdev.c
2005-01-25 00:35:45.0 +0100
@@ -31,6 +31,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "dvbdev.h"
 
@@ -50,8 +52,9 @@ static const char * const dnames[] = {
 };
 
 
-#define DVB_MAX_IDS  4
+#define DVB_MAX_IDS  6
 #define nums2minor(num,type,id)  ((num << 6) | (id << 4) | type)
+#define MAX_DVB_MINORS   (DVB_MAX_IDS*64)
 
 struct class_simple *dvb_class;
 EXPORT_SYMBOL(dvb_class);
@@ -109,6 +112,11 @@ static struct file_operations dvb_device
 };
 
 
+static struct cdev dvb_device_cdev = {
+   .kobj   = {.name = "dvb", },
+   .owner  =   THIS_MODULE,
+};
+
 int dvb_generic_open(struct inode *inode, struct file *file)
 {
 struct dvb_device *dvbdev = file->private_data;
@@ -400,25 +408,41 @@ out:
 static int __init init_dvbdev(void)
 {
int retval;
+   dev_t dev = MKDEV(DVB_MAJOR, 0);
+
+   if ((retval = register_chrdev_region(dev, MAX_DVB_MINORS, "DVB")) != 0) 
{
+   printk("dvb-core: unable to get major %d\n", DVB_MAJOR);
+   return retval;
+   }
 
-   if ((retval = register_chrdev(DVB_MAJOR,"DVB", _device_fops)))
+   cdev_init(_device_cdev, _device_fops);
+   if ((retval = cdev_add(_device_cdev, dev, MAX_DVB_MINORS)) != 0) {
printk("dvb-core: unable to get major %d\n", DVB_MAJOR);
+   goto error;
+   }
 
devfs_mk_dir("dvb");
 
dvb_class = class_simple_create(THIS_MODULE, "dvb");
-   if (IS_ERR(dvb_class))
-   return PTR_ERR(dvb_class);
+   if (IS_ERR(dvb_class)) {
+   retval = PTR_ERR(dvb_class);
+   goto error;
+   }
+   return 0;
 
+error:
+   cdev_del(_device_cdev);
+   unregister_chrdev_region(dev, MAX_DVB_MINORS);
return retval;
 }
 
 
 static void __exit exit_dvbdev(void)
 {
-   unregister_chrdev(DVB_MAJOR, "DVB");
 devfs_remove("dvb");
class_simple_destroy(dvb_class);
+   cdev_del(_device_cdev);
+unregister_chrdev_region(MKDEV(DVB_MAJOR, 0), MAX_DVB_MINORS);
 }
 
 module_init(init_dvbdev);

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

[Johannes Stezenbach]

- [DVB] core: fix access to freed memory when unloading frontend
  drivers (fix by Gerd Knorr)

Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>

diff -rupN linux-2.6.11-rc2-bk2/drivers/media/dvb/dvb-core/dvb_frontend.c 
linux-2.6.11-rc2-bk2-dvb/drivers/media/dvb/dvb-core/dvb_frontend.c
--- linux-2.6.11-rc2-bk2/drivers/media/dvb/dvb-core/dvb_frontend.c  
2005-01-24 23:18:39.0 +0100
+++ linux-2.6.11-rc2-bk2-dvb/drivers/media/dvb/dvb-core/dvb_frontend.c  
2005-01-25 00:17:56.0 +0100
@@ -912,8 +912,9 @@ int dvb_unregister_frontend(struct dvb_f
fe->ops->release(fe);
else
printk("dvb_frontend: Demodulator (%s) does not have a release 
callback!\n", fe->ops->info.name);
-   if (fe->frontend_priv)
-   kfree(fe->frontend_priv);
+   /* fe is invalid now */
+   if (fepriv)
+   kfree(fepriv);
up (_mutex);
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: Linux 2.6.11-rc2: vmnet breaks; put skb_copy_datagram back in place

[Sytse Wielinga]

Linus, could you please put skb_copy_datagram back in place? It's not used
anymore in the kernel, but the vmnet module (in vmware) still uses this
interface to skb_copy_datagram_iovec.

Patch for 2.6.11-rc2 follows. It compiles cleanly; I have not tested it yet,
but I assume it's okay. I'll test it right after sending this mail and report
back here if something goes wrong.

Sytse

diff -ru a/include/linux/skbuff.h b/include/linux/skbuff.h
--- a/include/linux/skbuff.h2005-01-25 01:27:00.0 +0100
+++ b/include/linux/skbuff.h2005-01-25 01:31:20.0 +0100
@@ -1086,6 +1086,8 @@
 int noblock, int *err);
 extern unsigned intdatagram_poll(struct file *file, struct socket *sock,
 struct poll_table_struct *wait);
+extern intskb_copy_datagram(const struct sk_buff *from,
+int offset, char __user *to, int size);
 extern intskb_copy_datagram_iovec(const struct sk_buff *from,
   int offset, struct iovec *to,
   int size);
diff -ru a/net/core/datagram.c b/net/core/datagram.c
--- a/net/core/datagram.c   2005-01-25 01:27:01.0 +0100
+++ b/net/core/datagram.c   2005-01-25 01:31:20.0 +0100
@@ -199,6 +199,19 @@
kfree_skb(skb);
 }
 
+/*
+ * Copy a datagram to a linear buffer.
+ */
+int skb_copy_datagram(const struct sk_buff *skb, int offset, char __user *to, 
int size)
+{
+   struct iovec iov = {
+   .iov_base = to,
+   .iov_len =size,
+   };
+
+   return skb_copy_datagram_iovec(skb, offset, , size);
+}
+
 /**
  * skb_copy_datagram_iovec - Copy a datagram to an iovec.
  * @skb - buffer to copy
@@ -477,6 +490,7 @@
 
 EXPORT_SYMBOL(datagram_poll);
 EXPORT_SYMBOL(skb_copy_and_csum_datagram_iovec);
+EXPORT_SYMBOL(skb_copy_datagram);
 EXPORT_SYMBOL(skb_copy_datagram_iovec);
 EXPORT_SYMBOL(skb_free_datagram);
 EXPORT_SYMBOL(skb_recv_datagram);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] BUG in io_destroy (fs/aio.c:1248)

[Darrick J. Wong]

Andrew Morton wrote:

> So...  Will someone be sending a new patch?

Here's a cheesy patch that simply marks the ioctx as dead before
destroying it.  Though I'd like to simply mark the ioctx as dead until
it actually gets used, I don't know enough about the code to make that
sort of invasive change.

--D

-
Signed-off-by: Darrick Wong <[EMAIL PROTECTED]>

--- linux-2.6.10/fs/aio.c.old   2005-01-24 16:12:46.0 -0800
+++ linux-2.6.10/fs/aio.c   2005-01-24 16:30:53.0 -0800
@@ -1285,6 +1285,10 @@
if (!ret)
return 0;
 
+   spin_lock_irq(>ctx_lock);
+   ctx->dead = 1;
+   spin_unlock_irq(>ctx_lock);
+
io_destroy(ioctx);
}

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

Re: Page fault in umount

[Andrew Morton]

Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
> When I yank out my MP3 player, the programs trying to umount the disk 
> cause the following page fault:
> 
> ...
> EIP is at scsi_device_put+0xf/0x70 [scsi_mod]

This should be fixed in 2.6.11-rc2-mm1, via bk-scsi-rc-fixes.patch.  Could you
retest with either

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/2.6.11-rc2-mm1.bz2

or

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/broken-out/bk-scsi-rc-fixes.patch

applied?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] follow USB __le16 changes

[Johannes Stezenbach]

- [DVB] dibusb: follow USB changes (idVendor, idProduct, bcdDevice
  and bcdUSB fields are now __le16)

Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>

diff -rupN linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c 
linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb-core.c
--- linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c 
2005-01-24 23:31:05.0 +0100
+++ linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb-core.c 
2005-01-24 23:16:27.0 +0100
@@ -358,8 +360,8 @@ static struct dibusb_usb_device * dibusb
for (i = 0; i < sizeof(dibusb_devices)/sizeof(struct 
dibusb_usb_device); i++) {
for (j = 0; j < DIBUSB_ID_MAX_NUM && 
dibusb_devices[i].cold_ids[j] != NULL; j++) {
deb_info("check for cold %x 
%x\n",dibusb_devices[i].cold_ids[j]->idVendor, 
dibusb_devices[i].cold_ids[j]->idProduct);
-   if (dibusb_devices[i].cold_ids[j]->idVendor == 
udev->descriptor.idVendor &&
-   dibusb_devices[i].cold_ids[j]->idProduct == 
udev->descriptor.idProduct) {
+   if (dibusb_devices[i].cold_ids[j]->idVendor == 
le16_to_cpu(udev->descriptor.idVendor) &&
+   dibusb_devices[i].cold_ids[j]->idProduct == 
le16_to_cpu(udev->descriptor.idProduct)) {
*cold = 1;
return _devices[i];
}
@@ -367,8 +369,8 @@ static struct dibusb_usb_device * dibusb
 
for (j = 0; j < DIBUSB_ID_MAX_NUM && 
dibusb_devices[i].warm_ids[j] != NULL; j++) {
deb_info("check for warm %x 
%x\n",dibusb_devices[i].warm_ids[j]->idVendor, 
dibusb_devices[i].warm_ids[j]->idProduct);
-   if (dibusb_devices[i].warm_ids[j]->idVendor == 
udev->descriptor.idVendor &&
-   dibusb_devices[i].warm_ids[j]->idProduct == 
udev->descriptor.idProduct) {
+   if (dibusb_devices[i].warm_ids[j]->idVendor == 
le16_to_cpu(udev->descriptor.idVendor) &&
+   dibusb_devices[i].warm_ids[j]->idProduct == 
le16_to_cpu(udev->descriptor.idProduct)) {
*cold = 0;
return _devices[i];
}
@@ -391,7 +393,7 @@ static int dibusb_probe(struct usb_inter
 
if ((dibdev = dibusb_find_device(udev,)) == NULL) {
err("something went very wrong, "
-   "unknown product ID: 
%.4x",udev->descriptor.idProduct);
+   "unknown product ID: 
%.4x",le16_to_cpu(udev->descriptor.idProduct));
return -ENODEV;
}


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

[PATCH 0/4] 2.6.11-rc2-bk2 DVB fixes

[Johannes Stezenbach]

Hi Linus,

the following patches correct a few bugs which were found
shortly after submission of the previous patchset :-(
(except 03-core-more-cards which I just submit while I'm at it)

01-dibusb-le16  follow USB __le16 changes
02-core-fe-release  fix access to freed memory on module unload
03-core-more-cards  support up to six DVB cards (instead of just four)
04-frontendscleanup some confusing firmware loading printks

I also saw that there is a large amount of whitespace/indentation
corruption throughout the DVB subsystem (some of it shows through
in the 04-frontends patch), which was not introduced
by the latest patchset but already exists in linux-2.6.10-rc2 at least.
I will try to sort this out over the next few days.

Johannes

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