calling call_usermodehelper from interrupt context

[Payasam Manohar]

hai all,
Is it possible to call call_usermodehelper from interrupt context.
I want to call a user program from the keyboard driver. When am calling, 
it is hanging, and giving the error that
   <0> Kernel panic : Aiee, killing interrupt handler
   In interrupt handler -- not syncing.
I am using Redhat linux 9.

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

linux-kernel-announce@vger.kernel.org Your Application Confirmation Fri, 25 Feb 2005 22:17:57 -0800

[[EMAIL PROTECTED]]

Hi,

Did you know?
You can now get $347,000 for as little as $607 a month!
Why should you pay more when you can save thousands re-financing at our low 
rates?
Remember, that rates are due to jump withint he next few months.
Bad credit? Doesn't matter, low rates are fixed no matter what!

Use the extra for home additions, improvements, or whatever you could not 
afford to do before.
Fill out this 30 sec. form and be approved within the next 24 hours.

http://www.123ratezz.com/x/loan.php?id=a17

Best Regards,
Quincy Washburn



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

Re: [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map

[Sven Luther]

On Sat, Feb 26, 2005 at 04:39:45AM +0100, Christian wrote:
> Sven Luther wrote:
> >Some backports that i got from the list. The complete list of patches is 
> >at :
> >
> >  
> > http://svn.debian.org/wsvn/kernel/trunk/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/?rev=0&sc=0
> 
> dooh, these websvn patches are giving me a headache will have to 
> learn /usr/bin/svn first :-\

Well : 

  svn co 
svn://svn.debian.org/kernel/trunk/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches

> >--- kernel-source-2.6.8.orig/arch/ppc/platforms/prep_pci.c   2004-12-28
> 
> yes, the prep_pci.c and its irq-mappings. the PowerStackII lines were 
> changed back and forth, and a current 2.6-BK is only different in one 
> line to the patch you mentioned:

I guess the one line is the one for the IDE device, ..., indeed. The one line
in question is to enable the onboard IDE controller, which exist but is
probably not used, since the place on the board where it should be has no
connector soldered. I hear that there is an IDE powerstack II model though, so
...

> http://nerdbynature.de/bits/hal/2.6.11-rc5.patched/powerpc-prep-powerstack-irq_2.6.11-rc5.patch
> 
> unfortunately it did not help either and i'll switch back to vanilla 
> 2.6.8 again and hopefully find out exactly when scsi stopped working.

As i understand leigh's and other post, i believe that this is the fix, but
that other stuff went in too which did break.

> http://nerdbynature.de/bits/hal/2.6.11-rc5/
> http://nerdbynature.de/bits/hal/2.6.11-rc5.patched/

Friendly,

Sven Luther

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

Re: split kobject creation and hotplug event generation

[Kay Sievers]

Sorry, the first patch has a typo.

On Sat, Feb 26, 2005 at 06:53:16AM +0100, Kay Sievers wrote:
> This splits the implicit generation of a hotplug events from
> kobject_add() and kobject_del(), to give the user of of these
> functions control over the time the event is created.
> 
> The kobject_register() and unregister functions still have the same
> behavior and emit the events by themselves.
> 
> The class, block and device core is changed now to emit the hotplug
> event _after_ the "dev" file, the "device" symlink and the default
> attributes are created. This will save udev from spinning in a stat() loop
> to wait for the files to appear, which is expensive if we have a lot of
> concurrent events.

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

= drivers/base/class.c 1.62 vs edited =
--- 1.62/drivers/base/class.c   2005-02-18 19:44:34 +01:00
+++ edited/drivers/base/class.c 2005-02-26 04:49:37 +01:00
@@ -430,6 +430,7 @@ int class_device_add(struct class_device
sysfs_create_link(&class_dev->kobj,
  &class_dev->dev->kobj, "device");
 
+   kobject_hotplug(&class_dev->kobj, KOBJ_ADD);
  register_done:
if (error && parent)
class_put(parent);
@@ -461,6 +462,7 @@ void class_device_del(struct class_devic
sysfs_remove_link(&class_dev->kobj, "device");
class_device_remove_attrs(class_dev);
 
+   kobject_hotplug(&class_dev->kobj, KOBJ_REMOVE);
kobject_del(&class_dev->kobj);
 
if (parent)
= drivers/base/core.c 1.91 vs edited =
--- 1.91/drivers/base/core.c2004-11-12 13:16:42 +01:00
+++ edited/drivers/base/core.c  2005-02-26 04:55:10 +01:00
@@ -260,6 +260,8 @@ int device_add(struct device *dev)
/* notify platform of device entry */
if (platform_notify)
platform_notify(dev);
+
+   kobject_hotplug(&dev->kobj, KOBJ_ADD);
  Done:
put_device(dev);
return error;
@@ -349,6 +351,7 @@ void device_del(struct device * dev)
platform_notify_remove(dev);
bus_remove_device(dev);
device_pm_remove(dev);
+   kobject_hotplug(&dev->kobj, KOBJ_REMOVE);
kobject_del(&dev->kobj);
if (parent)
put_device(parent);
= drivers/usb/host/hc_crisv10.c 1.7 vs edited =
--- 1.7/drivers/usb/host/hc_crisv10.c   2004-12-21 02:15:10 +01:00
+++ edited/drivers/usb/host/hc_crisv10.c2005-02-26 04:56:09 +01:00
@@ -4396,6 +4396,7 @@ static int __init etrax_usb_hc_init(void
 device_initialize(&fake_device);
 kobject_set_name(&fake_device.kobj, "etrax_usb");
 kobject_add(&fake_device.kobj);
+kobject_hotplug(&fake_device.kobj, KOBJ_ADD);
 hc->bus->controller = &fake_device;
usb_register_bus(hc->bus);
 
= fs/partitions/check.c 1.129 vs edited =
--- 1.129/fs/partitions/check.c 2005-01-31 07:33:40 +01:00
+++ edited/fs/partitions/check.c2005-02-26 06:58:33 +01:00
@@ -337,6 +337,7 @@ void register_disk(struct gendisk *disk)
if ((err = kobject_add(&disk->kobj)))
return;
disk_sysfs_symlinks(disk);
+   kobject_hotplug(&disk->kobj, KOBJ_ADD);
 
/* No minors to use for partitions */
if (disk->minors == 1) {
@@ -441,5 +442,6 @@ void del_gendisk(struct gendisk *disk)
sysfs_remove_link(&disk->driverfs_dev->kobj, "block");
put_device(disk->driverfs_dev);
}
+   kobject_hotplug(&disk->kobj, KOBJ_REMOVE);
kobject_del(&disk->kobj);
 }
= lib/kobject.c 1.58 vs edited =
--- 1.58/lib/kobject.c  2005-02-18 08:56:36 +01:00
+++ edited/lib/kobject.c2005-02-26 04:48:18 +01:00
@@ -184,8 +184,6 @@ int kobject_add(struct kobject * kobj)
unlink(kobj);
if (parent)
kobject_put(parent);
-   } else {
-   kobject_hotplug(kobj, KOBJ_ADD);
}
 
return error;
@@ -207,7 +205,8 @@ int kobject_register(struct kobject * ko
printk("kobject_register failed for %s (%d)\n",
   kobject_name(kobj),error);
dump_stack();
-   }
+   } else
+   kobject_hotplug(kobj, KOBJ_ADD);
} else
error = -EINVAL;
return error;
@@ -301,7 +300,6 @@ int kobject_rename(struct kobject * kobj
 
 void kobject_del(struct kobject * kobj)
 {
-   kobject_hotplug(kobj, KOBJ_REMOVE);
sysfs_remove_dir(kobj);
unlink(kobj);
 }
@@ -314,6 +312,7 @@ void kobject_del(struct kobject * kobj)
 void kobject_unregister(struct kobject * kobj)
 {
pr_debug("kobject %s: unregistering\n",kobject_name(kobj));
+   kobject_hotplug(kobj, KOBJ_REMOVE);
kobject_del(kobj);
kobject_put(kobj);
 }
= net/bridge/br_sysfs_if.c 1.2 vs edited =
--- 1.2/net/bridge/br_sysfs_if.c2004-06-18 22:15:34 +02:00
+++ edited/net/bridge

split kobject creation and hotplug event generation

[Kay Sievers]

This splits the implicit generation of a hotplug events from
kobject_add() and kobject_del(), to give the user of of these
functions control over the time the event is created.

The kobject_register() and unregister functions still have the same
behavior and emit the events by themselves.

The class, block and device core is changed now to emit the hotplug
event _after_ the "dev" file, the "device" symlink and the default
attributes are created. This will save udev from spinning in a stat() loop
to wait for the files to appear, which is expensive if we have a lot of
concurrent events.

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

= drivers/base/class.c 1.62 vs edited =
--- 1.62/drivers/base/class.c   2005-02-18 19:44:34 +01:00
+++ edited/drivers/base/class.c 2005-02-26 04:49:37 +01:00
@@ -430,6 +430,7 @@ int class_device_add(struct class_device
sysfs_create_link(&class_dev->kobj,
  &class_dev->dev->kobj, "device");
 
+   kobject_hotplug(&class_dev->kobj, KOBJ_ADD);
  register_done:
if (error && parent)
class_put(parent);
@@ -461,6 +462,7 @@ void class_device_del(struct class_devic
sysfs_remove_link(&class_dev->kobj, "device");
class_device_remove_attrs(class_dev);
 
+   kobject_hotplug(&class_dev->kobj, KOBJ_REMOVE);
kobject_del(&class_dev->kobj);
 
if (parent)
= drivers/base/core.c 1.91 vs edited =
--- 1.91/drivers/base/core.c2004-11-12 13:16:42 +01:00
+++ edited/drivers/base/core.c  2005-02-26 04:55:10 +01:00
@@ -260,6 +260,8 @@ int device_add(struct device *dev)
/* notify platform of device entry */
if (platform_notify)
platform_notify(dev);
+
+   kobject_hotplug(&dev->kobj, KOBJ_ADD);
  Done:
put_device(dev);
return error;
@@ -349,6 +351,7 @@ void device_del(struct device * dev)
platform_notify_remove(dev);
bus_remove_device(dev);
device_pm_remove(dev);
+   kobject_hotplug(&dev->kobj, KOBJ_REMOVE);
kobject_del(&dev->kobj);
if (parent)
put_device(parent);
= drivers/usb/host/hc_crisv10.c 1.7 vs edited =
--- 1.7/drivers/usb/host/hc_crisv10.c   2004-12-21 02:15:10 +01:00
+++ edited/drivers/usb/host/hc_crisv10.c2005-02-26 04:56:09 +01:00
@@ -4396,6 +4396,7 @@ static int __init etrax_usb_hc_init(void
 device_initialize(&fake_device);
 kobject_set_name(&fake_device.kobj, "etrax_usb");
 kobject_add(&fake_device.kobj);
+kobject_hotplug(&fake_device.kobj, KOBJ_ADD);
 hc->bus->controller = &fake_device;
usb_register_bus(hc->bus);
 
= fs/partitions/check.c 1.129 vs edited =
--- 1.129/fs/partitions/check.c 2005-01-31 07:33:40 +01:00
+++ edited/fs/partitions/check.c2005-02-26 04:50:56 +01:00
@@ -337,6 +337,7 @@ void register_disk(struct gendisk *disk)
if ((err = kobject_add(&disk->kobj)))
return;
disk_sysfs_symlinks(disk);
+   kobject_add(&disk->kobj);
 
/* No minors to use for partitions */
if (disk->minors == 1) {
@@ -441,5 +442,6 @@ void del_gendisk(struct gendisk *disk)
sysfs_remove_link(&disk->driverfs_dev->kobj, "block");
put_device(disk->driverfs_dev);
}
+   kobject_hotplug(&disk->kobj, KOBJ_REMOVE);
kobject_del(&disk->kobj);
 }
= lib/kobject.c 1.58 vs edited =
--- 1.58/lib/kobject.c  2005-02-18 08:56:36 +01:00
+++ edited/lib/kobject.c2005-02-26 04:48:18 +01:00
@@ -184,8 +184,6 @@ int kobject_add(struct kobject * kobj)
unlink(kobj);
if (parent)
kobject_put(parent);
-   } else {
-   kobject_hotplug(kobj, KOBJ_ADD);
}
 
return error;
@@ -207,7 +205,8 @@ int kobject_register(struct kobject * ko
printk("kobject_register failed for %s (%d)\n",
   kobject_name(kobj),error);
dump_stack();
-   }
+   } else
+   kobject_hotplug(kobj, KOBJ_ADD);
} else
error = -EINVAL;
return error;
@@ -301,7 +300,6 @@ int kobject_rename(struct kobject * kobj
 
 void kobject_del(struct kobject * kobj)
 {
-   kobject_hotplug(kobj, KOBJ_REMOVE);
sysfs_remove_dir(kobj);
unlink(kobj);
 }
@@ -314,6 +312,7 @@ void kobject_del(struct kobject * kobj)
 void kobject_unregister(struct kobject * kobj)
 {
pr_debug("kobject %s: unregistering\n",kobject_name(kobj));
+   kobject_hotplug(kobj, KOBJ_REMOVE);
kobject_del(kobj);
kobject_put(kobj);
 }
= net/bridge/br_sysfs_if.c 1.2 vs edited =
--- 1.2/net/bridge/br_sysfs_if.c2004-06-18 22:15:34 +02:00
+++ edited/net/bridge/br_sysfs_if.c 2005-02-26 04:51:32 +01:00
@@ -248,6 +248,7 @@ int br_sysfs_addif(struct net_bridge_por
if (err)
   

Re: 2.6.11-rc5

[Bill Davidsen]

Lee Revell wrote:
On Fri, 2005-02-25 at 16:47 -0500, Bill Davidsen wrote:
- sound: hasn't worked since FC1...

The ALSA lists have been deluged with reports like "sound worked in FC1,
upgraded to FC3, no sound".   AFAICT it's just sloppiness on the part of
the Fedora userspace tools.  For example, last I heard
system-config-soundcard tries to load the emu10k1 module for cards that
need the (completely different) emu10k1x driver.
The modules look good to me, they are the Intel modules which should 
would with ICH4-M.

--
bill davidsen <[EMAIL PROTECTED]>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Potentially dead bttv cards from 2.6.10

[James Bruce]

Hi I've read elsewhere that the following message:
  "tveeprom(bttv internal): Huh, no eeprom present (err=-121)?"
Means that a bttv card is dead.  If so, then I've apparently found a way 
to kill bttv cards in vanilla 2.6.10.  They worked fine a few days ago, 
but after running some "cleaned up" userspace caputure code today it led 
to a hard lockup.  Even after power-cycling the machine the cards no 
longer seem to work in that captured video is garbled.

I was testing only one card, but two were installed in the machine and 
both appear to no longer work, using either S-video or composite input. 
 I don't use the TV-tuners but they are present on the cards.

I can gather more information, and I even have a third card still in its 
box, but obviously I'm hesitant to test anything immediately.  Before 
proceeding I'd like to know any general pointers about how to find out 
what may be wrong, and if anyone knows any potential causes offhand.

I can supply a test case, but It's a large C++ program and kind of 
unweildy.  I'd narrow it down to a small test case but I don't have 
log(N) cards to fry in the process of searching for the root cause.

I would have expected a dud card, but these cards worked flawlessly just 
a few days ago, and both of them died at exactly the same time.

Thanks,
  Jim Bruce
 Capture Card Model 
  V-Stream Xpert TV-PVR 878
On the card, the following chip is visible:
  Conexant FUSION 878A
  25878-13
  E403069.1
  0330 TAIWAN
 Relevant dmesg output 
Linux video capture interface: v1.00
bttv: driver version 0.9.15 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
PCI: Found IRQ 12 for device :00:0b.0
PCI: Sharing IRQ 12 with :00:0b.1
bttv0: Bt878 (rev 17) at :00:0b.0, irq: 12, latency: 32, mmio: 
0xe3001000
bttv0: using:  *** UNKNOWN/GENERIC ***  [card=0,autodetected]
bttv0: gpio: en=, out= in=003f [init]
tveeprom(bttv internal): Huh, no eeprom present (err=-121)?
bttv0: using tuner=-1
bttv0: i2c: checking for MSP34xx @ 0x80... not found
bttv0: i2c: checking for TDA9875 @ 0xb0... not found
bttv0: i2c: checking for TDA7432 @ 0x8a... not found
bttv0: i2c: checking for TDA9887 @ 0x86... not found
bttv0: registered device video0
bttv0: registered device vbi0
bttv: Bt8xx card found (1).
PCI: Found IRQ 11 for device :00:0c.0
PCI: Sharing IRQ 11 with :00:09.0
PCI: Sharing IRQ 11 with :00:0c.1
bttv1: Bt878 (rev 17) at :00:0c.0, irq: 11, latency: 32, mmio: 
0xe3003000
bttv1: using:  *** UNKNOWN/GENERIC ***  [card=0,autodetected]
bttv1: gpio: en=, out= in=003f [init]
tveeprom(bttv internal): Huh, no eeprom present (err=-121)?
bttv1: using tuner=-1
bttv1: i2c: checking for MSP34xx @ 0x80... not found
bttv1: i2c: checking for TDA9875 @ 0xb0... not found
bttv1: i2c: checking for TDA7432 @ 0x8a... not found
bttv1: i2c: checking for TDA9887 @ 0x86... not found
bttv1: registered device video1
bttv1: registered device vbi1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: ICH7 SATA drive not detected.

[Jeff Garzik]

Comment out the function call to piix_disable_ahci() and see what happens.
if (port_info[0]->host_flags & PIIX_FLAG_AHCI) {
int rc = piix_disable_ahci(pdev);
if (rc)
return rc;
}
Regards,
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] USB: Fix usbfs regression

[Greg KH]

You are correct, the patch is valid, nice catch.  Linus, please apply.



I have just tested kernel version 2.6.11-rc5 and noticed it is not
possible to do an USB transfer by submitting an URB to an output 
endpoint. This breaks newest versions of libusb and thus SANE, 
gphoto2, and a lot of software.

The bug has been introduced in version 2.6.11-rc1 and is due to a 
wrong comparison.

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

diff -urN linux-2.6.11-rc5.orig/drivers/usb/core/devio.c 
linux-2.6.11-rc5/drivers/usb/core/devio.c
--- linux-2.6.11-rc5.orig/drivers/usb/core/devio.c  2005-02-26 
03:15:14.0 +0100
+++ linux-2.6.11-rc5/drivers/usb/core/devio.c   2005-02-26 03:16:15.0 
+0100
@@ -841,7 +841,7 @@
if ((ret = checkintf(ps, ifnum)))
return ret;
}
-   if ((uurb.endpoint & ~USB_ENDPOINT_DIR_MASK) != 0)
+   if ((uurb.endpoint & USB_ENDPOINT_DIR_MASK) != 0)
ep = ps->dev->ep_in [uurb.endpoint & USB_ENDPOINT_NUMBER_MASK];
else
ep = ps->dev->ep_out [uurb.endpoint & USB_ENDPOINT_NUMBER_MASK];


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

Re: pty_chars_in_buffer NULL pointer (kernel oops)

[Linus Torvalds]

On Fri, 25 Feb 2005, Marcelo Tosatti wrote:
> 
> BTW, I fail to see any drivers/char/pty.c change related to the race which 
> triggers
> the pty_chars_in_buffer->0 oops.

Indeed, I don't think 2.6.x got that merged, because it was never really 
clear _which_ fix was the right one (the extra locking was absolutely 
deadly for performance, the hacky one was a tad _too_ hacky ;)

Alan, did you ever decide what the proper locking would be? I've applied
the hacky "works by hiding the problem" patch for 2.6.11 which didn't have 
any subtle performance issues associated with it.

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

Re: [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map

[Christian]

Sven Luther wrote:
Some backports that i got from the list. The complete list of patches is at :
  http://svn.debian.org/wsvn/kernel/trunk/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/?rev=0&sc=0
dooh, these websvn patches are giving me a headache will have to 
learn /usr/bin/svn first :-\


--- kernel-source-2.6.8.orig/arch/ppc/platforms/prep_pci.c	2004-12-28
yes, the prep_pci.c and its irq-mappings. the PowerStackII lines were 
changed back and forth, and a current 2.6-BK is only different in one 
line to the patch you mentioned:

http://nerdbynature.de/bits/hal/2.6.11-rc5.patched/powerpc-prep-powerstack-irq_2.6.11-rc5.patch
unfortunately it did not help either and i'll switch back to vanilla 
2.6.8 again and hopefully find out exactly when scsi stopped working.

http://nerdbynature.de/bits/hal/2.6.11-rc5/
http://nerdbynature.de/bits/hal/2.6.11-rc5.patched/
thank you for your concern,
Christian.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux RT question - __up_mutex calling pi_setprio

[Steven Rostedt]

Hi Ingo,

I have a couple of questions about __up_mutex in rt.c. I'm still using
RT-V0.7.38-06 and this may have changed. I haven't checked.

1) can old_owner ever not be the same as current. IOW can a process
unlock a lock owned by another process?

2) Is it really necessary to call pi_setprio on the old_owner (I guess
if the previous question is true, then this would be too).  If the
process is unlocking a lock, I don't expect it to be also blocked on a
lock so it would not need to iterate the priority list. Wouldn't just
calling mutex_setprio be sufficient?

Thanks,

-- Steve


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

Re: Loan User - 177

[Ryan Mann]

What does this have to do with the Linux kernel?  Have I 
been selected for a loan because I run the Linux operating 
system?  I'm honored!!!  

On Fri, 25 Feb 2005, Hershel Ricks wrote:
Thank you for your attention.
You have been pre-approved for a new home loan.
This offer is unconditional and your credit is in no way a factor.
Please find all details below:
___SUMMARY___
Interest: 3.95
Term: 360 months
Max Price: $350,000
Closing Date: 30 days
Please follow this link for your instant activation:
http://www.m0rtgagesource.com/index2.php?refid=phade
-
To unsubscribe from this list: send the line "unsubscribe 
linux-kernel-announce" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pty_chars_in_buffer NULL pointer (kernel oops)

[Marcelo Tosatti]

Hi, 

On Fri, Feb 18, 2005 at 10:56:53AM +0200, nuclearcat wrote:

> Is discussed at

> http://kerneltrap.org/mailarchive/1/message/12508/thread 

> bug fixed in 2.4.x tree? Cause seems i have downloaded 2.4.29, and it
> is not fixed (still my kernel on vpn server crashing almost at start),
> i have grepped fast pre and bk patches, but didnt found any fixed
> related to tty/pty.

Can you please post the oops? Have you done so already? 

What makes you think it is the same race discussed in the above thread? 

BTW, I fail to see any drivers/char/pty.c change related to the race which 
triggers
the pty_chars_in_buffer->0 oops.

Quoting the first message from thread you mention:
"That last call trace entry is the call in pty_chars_in_buffer() to 

/* The ldisc must report 0 if no characters available to be read */ 
count = to->ldisc.chars_in_buffer(to);
"

Alan, Linus, what correction to the which the above thread discusses has 
been deployed? 

> Provided in thread patch from Linus working, but after night i have
> checked server, and see load average jumped to 700.
> Can anybody help in that? I am not kernel guru to provide a patch, but
> seems by search in google it is actual problem for people, who own
> poptop vpn servers, it is really causing serious instability for
> servers.

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

Re: ALPS touchpad not seen by 2.6.11 kernels

[Dmitry Torokhov]

On Friday 25 February 2005 17:20, Johan Braennlund wrote:
> 
> --- Dmitry Torokhov wrote:
> 
> > Does i8042 detect presence of an AUX port (check dmesg)? 
> 
> No.
> 
> > If not try booting with i8042.noacpi kernel boot option.
> 
> Yes, that helped - everything's working now. Thank you.
> 

Could you please send me contents of your DSDT
(cat /proc/acpi/dsdt > dsdt.hex)

Thanks!

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

Loan User - 177

[Hershel Ricks]

Thank you for your attention.

You have been pre-approved for a new home loan.
This offer is unconditional and your credit is in no way a factor.

Please find all details below:

___SUMMARY___
Interest: 3.95
Term: 360 months
Max Price: $350,000
Closing Date: 30 days


Please follow this link for your instant activation: 
http://www.m0rtgagesource.com/index2.php?refid=phade

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.4.29: Zombies not detected or removed

[Marcelo Tosatti]

On Mon, Feb 21, 2005 at 12:32:33PM +0100, Schwarz wrote:
> 
> 
> Hi everyone,
> 
> since 2.4.29 we discovered a strange behaviour.
> 
> Severall tasks are no longer detected as destroyed.
> means, these tasks have ended but arn't removed from
> the processlist.
> 
> An example from today:
> 
> [EMAIL PROTECTED] ]# date
> Mon Feb 21 10:14:06 CET 2005
> [EMAIL PROTECTED] ]# strace -p 33326
> attach: ptrace(PTRACE_ATTACH, ...): No such process
> [EMAIL PROTECTED] ]# ps aux | grep 29579
> 3332629579  0.0  0.2 10696 4332 ?SN   10:11   0:00 -f
> /home/ajondoco
> root 19168  0.0  0.0  1768  628 pts/0S10:15   0:00 grep 29579
> [EMAIL PROTECTED] ]# strace -p 33326
> attach: ptrace(PTRACE_ATTACH, ...): No such process
> [EMAIL PROTECTED] ]#
> 
> As you can see the process in question "29579" was started
> 10:11 , but as finished its activity already. After 10
> minutes it's still not removed from the processlist and 
> it's not detected as a zombie.  
> 
> the task was an Apache 1.3.3 child over a wrapper calling php
> with -f option. 
> 
> We think it's unimportant if its forked or execev(),because on
> another maschine it was not even an apache invoked. 
> 
> Some of the these processes enter zombie state, but were never
> fully removed !
> 
> Any ideas why it and what happens?

I don't, no. Quite strange.

Can you reproduce this? If sys_ptrace() failed the process is not present. 

Can you please "cat /proc//status" when ptrace fails but the ps shows the 
process existance ?

I suppose you haven't been seeing this behaviour with v2.4.28 ? 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fix audit inode filter

[Chris Wright]

Audit inode filter drops high bits on inode number by cut 'n paste mistake.

Signed-off-by: Chris Wright <[EMAIL PROTECTED]>

--- linus-2.6/kernel/auditsc.c~audit-inode-filter-fix   2005-02-24 
16:55:32.0 -0800
+++ linus-2.6/kernel/auditsc.c  2005-02-25 18:23:15.0 -0800
@@ -358,7 +358,7 @@ static int audit_filter_rules(struct tas
case AUDIT_INODE:
if (ctx) {
for (j = 0; j < ctx->name_count; j++) {
-   if (MINOR(ctx->names[j].ino)==value) {
+   if (ctx->names[j].ino == value) {
++result;
break;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Fix USB stack regression in 2.6.11-rc5

[Aurelien Jarno]

Hi all,

I have just tested kernel version 2.6.11-rc5 and noticed it is not
possible to do an USB transfer by submitting an URB to an output 
endpoint. This breaks newest versions of libusb and thus SANE, 
gphoto2, and a lot of software.

The bug has been introduced in version 2.6.11-rc1 and is due to a 
wrong comparison. Please find a patch below to fix that.

Bye,
Aurelien


Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>

diff -urN linux-2.6.11-rc5.orig/drivers/usb/core/devio.c 
linux-2.6.11-rc5/drivers/usb/core/devio.c
--- linux-2.6.11-rc5.orig/drivers/usb/core/devio.c  2005-02-26 
03:15:14.0 +0100
+++ linux-2.6.11-rc5/drivers/usb/core/devio.c   2005-02-26 03:16:15.0 
+0100
@@ -841,7 +841,7 @@
if ((ret = checkintf(ps, ifnum)))
return ret;
}
-   if ((uurb.endpoint & ~USB_ENDPOINT_DIR_MASK) != 0)
+   if ((uurb.endpoint & USB_ENDPOINT_DIR_MASK) != 0)
ep = ps->dev->ep_in [uurb.endpoint & USB_ENDPOINT_NUMBER_MASK];
else
ep = ps->dev->ep_out [uurb.endpoint & USB_ENDPOINT_NUMBER_MASK];


-- 
  .''`.  Aurelien Jarno   GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] seccomp: don't say it was more or less mandatory

[Andrea Arcangeli]

On Fri, Feb 25, 2005 at 10:14:54PM +0100, Adrian Bunk wrote:
> You don't need this feature unless you know you need it.

But you may not know that you need it since in the help text I
intentionally didn't mention which software requires the option to be
set to Y (I didn't mention it, since I didn't want to use the kernel
configuration help text to get free advertisement, but OTOH if people is
unsure while they configure the kernel I certainly prefer that they set
it to Y ;).

> It's not about risk or the actual size of the code - there are many 
> small or big features in the kernel that might be useful under some 
> circumstances, but even the IPv6 help text still suggests to say N
> to IPv6.

IPV6 is some relevant amount of code and complexity, seccomp is only a
few bytes and very simple, it's not even a kbyte of ram that you're
paying if you enable it. Only embedded cares about bytes, and that's why
the option exists for embedded.

One thing I'm concerned about (more than the "Y" in the help text) is
that the distributions will enable the option in their binary kernel
images. I hope they will given it's only a matter of a few bytes.

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: [Linux-fbdev-devel] Re: 2.6.11-rc5

[Benjamin Herrenschmidt]

> This patch has already been posted to linux-fbdev on 2005-02-10 by David 
> Vrabel
> and made me ask
>   Is there any reason why this has been originally flagged "__init"?
>   "vesa_modes" is not "__init". That's why I changed "intelfb" to
>   use "vesa_modes".
> 
> Maybe time has come to decide, if availability of "modedb" outside
> of init functions is more important than freeing (unused) kernel memory.

Well, I wonder why we need that mode db at all ... We should probably
use VESA modes and calculate using the standard formula if the user
requests a mode that isn't in the vesa table... Most monitors will
provide additional detailed timings for non-vesa modes they may
support.

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

[Benjamin Herrenschmidt]

On Sat, 2005-02-26 at 01:41 +0100, Olaf Hering wrote:

> 
> modedb can not be __init because fb_find_mode() may get db == NULL.
> fb_find_mode() is called from modules.

Ahhh, good catch ! I though that was fixed long ago, looks like I was
wrong.

Ben.

> Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
> 
> diff -purNx tags linux-2.6.11-rc5.orig/drivers/video/modedb.c 
> linux-2.6.11-rc5/drivers/video/modedb.c
> --- linux-2.6.11-rc5.orig/drivers/video/modedb.c  2005-02-24 
> 17:40:24.0 +0100
> +++ linux-2.6.11-rc5/drivers/video/modedb.c   2005-02-26 01:37:43.138003474 
> +0100
> @@ -37,7 +37,7 @@ const char *global_mode_option;
>  
>  #define DEFAULT_MODEDB_INDEX 0
>  
> -static const __init struct fb_videomode modedb[] = {
> +static const struct fb_videomode modedb[] = {
>  {
>   /* 640x400 @ 70 Hz, 31.5 kHz hsync */
>   NULL, 70, 640, 400, 39721, 40, 24, 39, 9, 96, 2,
-- 
Benjamin Herrenschmidt <[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: [Linux-fbdev-devel] Re: 2.6.11-rc5

[Buttchereit, Axel (XL)]

Linus Torvalds wrote:
> 
> On Sat, 26 Feb 2005, Olaf Hering wrote:
> 
>>modedb can not be __init because fb_find_mode() may get db == NULL.
>>fb_find_mode() is called from modules.
> 
> 
> Ack. Maybe somebody should run the scripts again to check that we don't 
> reference __init data from non-init functions.
> 
>   Linus
> 
This patch has already been posted to linux-fbdev on 2005-02-10 by David Vrabel
and made me ask
Is there any reason why this has been originally flagged "__init"?
"vesa_modes" is not "__init". That's why I changed "intelfb" to
use "vesa_modes".

Maybe time has come to decide, if availability of "modedb" outside
of init functions is more important than freeing (unused) kernel memory.

--Axel



  

  
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] allow vma merging with mlock et. al.

[Chris Wright]

* Andrea Arcangeli ([EMAIL PROTECTED]) wrote:
> The object of the merge is to save memory, and to reduce the size of the
> rbtree that might payoff during other operations (with a smaller tree,
> lookups will be faster too). If you only measure the time of creating
> and removing a mapping then it should be normal that you see a slowdown
> since merging involves more work than non-merging. The payoff is
> supposed to be in the other operations.

I agree, that test is pathological worst case.

> The reason mlock doesn't merge is that nobody asked for it yet, but it
> was originally supposed to merge too (I stopped at mremap since mlock
> wasn't high prio to fixup). But the long term plan was to eventually add
> merging to mlock too and it's good that you're optimizing it now.

Do you support merging this patch?  Or did you mean further optimizations?

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: ICH7 SATA drive not detected.

[Greg Felix]

Jeff,

I forgot: in dmesg I see the following:

ata_piix: probe of :00:1f.2 failed with error -5

Greg Felix


On Fri, 25 Feb 2005 18:02:59 -0700, Greg Felix <[EMAIL PROTECTED]> wrote:
> > Jeff Garzik wrote:
> > See REPORTING-BUGS for the sort of information you should provide.  This
> > is a "it doesn't work" report without much more info.
> >
> > I would suggest doing a "modprobe ata_piix" or "modprobe ahci"
> > (depending on ICH7 mode and hardware) and see what happens in 'dmesg'.
> >
> > Jeff
> 
> Let me try and do this right.
> Here's the bug report:
> 
> ICH7 SATA drive not detected.
> 
> I have two new OEM machines that are both ICH7 chipsets.  Both
> machines give the same vendor and device PCI ids for their storage
> controllers. 8086:27df and 8086:27c0.  One of the machines' disks is
> being detected correctly (sda).  The other one is not.  I have tried
> modprobing both ata_piix and ahci with negative results.  It is very
> new hardware.  There is also a broadcom NIC that is not being
> detected, but I don't NEED that to work. (I'll file a bug if requested
> of me.)
> 
> keywords: piix, ICH7, SATA, ata_piix, ahci
> 
> I'm running 2.6.11-rc5 in a custom distribution in a ram disk from a
> pxe boot.  I also have a USB memory device inserted into the machine
> being detected as sda for the reports below.
> 
> Here's the output of ver_linux:
> Linux (none) 2.6.11-rc5 #1 Fri Feb 25 12:31:16 MST 2005 i686 unknown
> unknown GNU/Linux
> 
> Gnu C  18:
> mount  2.12p
> module-init-tools  3.1
> reiserfsprogs  line
> reiser4progs   line
> Dynamic linker (ldd)   2.3.4
> Procps 3.2.3
> Net-tools  1.60
> Kbd81:
> Sh-utils   5.2.1
> Modules Loaded
> 
> /proc/cpuinfo reads:
> processor   : 0
> vendor_id   : GenuineIntel
> cpu family  : 15
> model   : 4
> model name  : Genuine Intel(R) CPU 3.20GHz
> stepping: 1
> cpu MHz : 3193.334
> cache size  : 1024 KB
> fdiv_bug: no
> hlt_bug : no
> f00f_bug: no
> coma_bug: no
> fpu : yes
> fpu_exception   : yes
> cpuid level : 5
> wp  : yes
> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx
> pni monitor ds_cpl cid xtpr
> bogomips: 6307.84
> 
> /proc/modules reads:
> ahci 5508 0 - Live 0xe0086000
> nls_cp437 4608 1 - Live 0xe0083000
> msdos 5248 1 - Live 0xe0018000
> fat 27548 1 msdos, Live 0xe008e000
> nls_base 4352 2 nls_cp437,fat, Live 0xe001b000
> sd_mod 11152 2 - Live 0xe0038000
> usb_storage 25216 1 - Live 0xe0065000
> usbhid 21376 0 - Live 0xe0047000
> edd 6496 0 - Live 0xe0007000
> ide_cd 29956 0 - Live 0xe007a000
> cdrom 30112 1 ide_cd, Live 0xe0071000
> ide_disk 11520 0 - Live 0xe0034000
> ata_piix 4228 0 - Live 0xe0031000
> libata 28804 2 ahci,ata_piix, Live 0xe003e000
> piix 6404 0 [permanent], Live 0xe0002000
> generic 2432 0 [permanent], Live 0xe0005000
> ide_core 85676 5 usb_storage,ide_cd,ide_disk,piix,generic, Live 0xe004f000
> ehci_hcd 21000 0 - Live 0xe0011000
> uhci_hcd 22416 0 - Live 0xe000a000
> usbcore 72696 5 usb_storage,usbhid,ehci_hcd,uhci_hcd, Live 0xe001e000
> 
> /proc/ioports reads:
> -001f : dma1
> 0020-0021 : pic1
> 0040-0043 : timer0
> 0050-0053 : timer1
> 0060-006f : keyboard
> 0080-008f : dma page reg
> 00a0-00a1 : pic2
> 00c0-00df : dma2
> 00f0-00ff : fpu
> 01f0-01f7 : ide0
> 03c0-03df : vga+
> 03f6-03f6 : ide0
> 0cf8-0cff : PCI conf1
> 1000-101f : :00:1d.0
>   1000-101f : uhci_hcd
> 1020-103f : :00:1d.1
>   1020-103f : uhci_hcd
> 1040-105f : :00:1d.2
>   1040-105f : uhci_hcd
> 1060-107f : :00:1d.3
>   1060-107f : uhci_hcd
> 10a0-10af : :00:1f.1
>   10a0-10a7 : ide0
>   10a8-10af : ide1
> 10b0-10bf : :00:1f.2
> 10c0-10c7 : :00:02.0
> 10d8-10df : :00:1f.2
> 10e0-10e7 : :00:1f.2
> 10f0-10f3 : :00:1f.2
> 10f4-10f7 : :00:1f.2
> 
> /proc/iomem reads:
> -0009fbff : System RAM
> 0009fc00-0009 : reserved
> 000a-000b : Video RAM area
> 000c-000c7fff : Video ROM
> 000ca800-000cb7ff : Adapter ROM
> 000cb800-000ccfff : Adapter ROM
> 000f-000f : System ROM
> 0010-1f7e27ff : System RAM
>   0010-00210717 : Kernel code
>   00210718-0024c37f : Kernel data
> 1f7e2800-1fff : reserved
> d000-dfff : :00:02.0
> e040-e047 : :00:02.0
> e048-e04b : :00:02.0
> e04c-e04c3fff : :00:1b.0
> e04c4000-e04c43ff : :00:1d.7
>   e04c4000-e04c43ff : ehci_hcd
> e04c4400-e04c47ff : :00:1f.2
> e050-e07f : PCI Bus #3f
>   e050-e050 : :3f:00.0
> f000-f3ff : reserved
> fec0- : reserved
> 
> lspci -vvv gives:
> 00:00.0 Class 0600: 8086:2770
> Subsystem: 103c:3011
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR+ FastB2B-
>

Re: 2.6.11-rc5

[Linus Torvalds]

On Sat, 26 Feb 2005, Olaf Hering wrote:
> 
> sparse doesnt do that, yet? (I never looked at it.)

No, it doesn't look at the section info. I guess I could do it, but there 
_is_ a "make buildcheck" which does it based on perl stuff and the link 
information. 

And I can do "make buildcheck" myself, but some people have done it before
and know which ones are false positives etc, so I was hoping..

Hint hint, wherever you are..

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

PROBLEM: ICH7 SATA drive not detected.

[Greg Felix]

> Jeff Garzik wrote:
> See REPORTING-BUGS for the sort of information you should provide.  This
> is a "it doesn't work" report without much more info.
> 
> I would suggest doing a "modprobe ata_piix" or "modprobe ahci"
> (depending on ICH7 mode and hardware) and see what happens in 'dmesg'.
> 
> Jeff

Let me try and do this right.
Here's the bug report:

ICH7 SATA drive not detected.

I have two new OEM machines that are both ICH7 chipsets.  Both
machines give the same vendor and device PCI ids for their storage
controllers. 8086:27df and 8086:27c0.  One of the machines' disks is
being detected correctly (sda).  The other one is not.  I have tried
modprobing both ata_piix and ahci with negative results.  It is very
new hardware.  There is also a broadcom NIC that is not being
detected, but I don't NEED that to work. (I'll file a bug if requested
of me.)

keywords: piix, ICH7, SATA, ata_piix, ahci

I'm running 2.6.11-rc5 in a custom distribution in a ram disk from a
pxe boot.  I also have a USB memory device inserted into the machine
being detected as sda for the reports below.

Here's the output of ver_linux:
Linux (none) 2.6.11-rc5 #1 Fri Feb 25 12:31:16 MST 2005 i686 unknown
unknown GNU/Linux

Gnu C  18:
mount  2.12p
module-init-tools  3.1
reiserfsprogs  line
reiser4progs   line
Dynamic linker (ldd)   2.3.4
Procps 3.2.3
Net-tools  1.60
Kbd81:
Sh-utils   5.2.1
Modules Loaded


/proc/cpuinfo reads:
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 4
model name  : Genuine Intel(R) CPU 3.20GHz
stepping: 1
cpu MHz : 3193.334
cache size  : 1024 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx
pni monitor ds_cpl cid xtpr
bogomips: 6307.84


/proc/modules reads:
ahci 5508 0 - Live 0xe0086000
nls_cp437 4608 1 - Live 0xe0083000
msdos 5248 1 - Live 0xe0018000
fat 27548 1 msdos, Live 0xe008e000
nls_base 4352 2 nls_cp437,fat, Live 0xe001b000
sd_mod 11152 2 - Live 0xe0038000
usb_storage 25216 1 - Live 0xe0065000
usbhid 21376 0 - Live 0xe0047000
edd 6496 0 - Live 0xe0007000
ide_cd 29956 0 - Live 0xe007a000
cdrom 30112 1 ide_cd, Live 0xe0071000
ide_disk 11520 0 - Live 0xe0034000
ata_piix 4228 0 - Live 0xe0031000
libata 28804 2 ahci,ata_piix, Live 0xe003e000
piix 6404 0 [permanent], Live 0xe0002000
generic 2432 0 [permanent], Live 0xe0005000
ide_core 85676 5 usb_storage,ide_cd,ide_disk,piix,generic, Live 0xe004f000
ehci_hcd 21000 0 - Live 0xe0011000
uhci_hcd 22416 0 - Live 0xe000a000
usbcore 72696 5 usb_storage,usbhid,ehci_hcd,uhci_hcd, Live 0xe001e000


/proc/ioports reads:
-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
03c0-03df : vga+
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
1000-101f : :00:1d.0
  1000-101f : uhci_hcd
1020-103f : :00:1d.1
  1020-103f : uhci_hcd
1040-105f : :00:1d.2
  1040-105f : uhci_hcd
1060-107f : :00:1d.3
  1060-107f : uhci_hcd
10a0-10af : :00:1f.1
  10a0-10a7 : ide0
  10a8-10af : ide1
10b0-10bf : :00:1f.2
10c0-10c7 : :00:02.0
10d8-10df : :00:1f.2
10e0-10e7 : :00:1f.2
10f0-10f3 : :00:1f.2
10f4-10f7 : :00:1f.2


/proc/iomem reads:
-0009fbff : System RAM
0009fc00-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000ca800-000cb7ff : Adapter ROM
000cb800-000ccfff : Adapter ROM
000f-000f : System ROM
0010-1f7e27ff : System RAM
  0010-00210717 : Kernel code
  00210718-0024c37f : Kernel data
1f7e2800-1fff : reserved
d000-dfff : :00:02.0
e040-e047 : :00:02.0
e048-e04b : :00:02.0
e04c-e04c3fff : :00:1b.0
e04c4000-e04c43ff : :00:1d.7
  e04c4000-e04c43ff : ehci_hcd
e04c4400-e04c47ff : :00:1f.2
e050-e07f : PCI Bus #3f
  e050-e050 : :3f:00.0
f000-f3ff : reserved
fec0- : reserved


lspci -vvv gives:
00:00.0 Class 0600: 8086:2770
Subsystem: 103c:3011
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
Reset- FastB2B-
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
  

Re: [Linux-fbdev-devel] Re: 2.6.11-rc5

[Benjamin Herrenschmidt]

On Sat, 2005-02-26 at 00:30 +0100, Olaf Hering wrote:
>  On Fri, Feb 25, Olaf Hering wrote:
> 
> >  On Fri, Feb 25, Olaf Hering wrote:
> > 
> > >  On Fri, Feb 25, James Simmons wrote:
> > > 
> > > > 
> > > > > cfb_imageblit(320) dst1 fa51a800 base e0b8 bitstart 1999a800
> > > > > fast_imageblit(237) s daea4000 dst1 fa51a800
> > > > > fast_imageblit(269) j 1 fa51a800 0
> > > > > Unable to handle kernel paging request at virtual address fa51a800
> > > > > 
> > > > > is bitstart incorrect or is the thing just not (yet) mapped?
> > > > 
> > > > Looks like the screen_base is not mapped to.
> > > 
> > > rc3 worked ok, rc4 does not. testing the -bk snapshots now.
> > 
> > bk8 works, bk9 breaks, it contains the radeonfb update.
> > it works ok if the driver is compiled into the kernel.
> 
> 
>  modedb = rinfo->mon1_modedb; passes some shit to fb_find_mode() which
>  kills my screen(1) when DPRINTK is enabled. it dies because bitstart
>  relies on xres_virtual which is 0xcc or whatever.

I think the problem is that you have totally bogus EDID data coming from
DDC. I'm still curious what makes a difference between module and
built-in. Either we try to set a bogus mode, or we just fail setting a
mode at all and fbdev doesn't deal with that properly.

Did you try plugging a different monitor ? Also, do you have output with
a recent X.org (6.8.2 for example) ? Can you send me that log too ?

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: [Linux-fbdev-devel] Re: 2.6.11-rc5

[Benjamin Herrenschmidt]

On Fri, 2005-02-25 at 22:21 +0100, Olaf Hering wrote:
>  On Fri, Feb 25, Olaf Hering wrote:
> 
> >  On Fri, Feb 25, James Simmons wrote:
> > 
> > > 
> > > > cfb_imageblit(320) dst1 fa51a800 base e0b8 bitstart 1999a800
> > > > fast_imageblit(237) s daea4000 dst1 fa51a800
> > > > fast_imageblit(269) j 1 fa51a800 0
> > > > Unable to handle kernel paging request at virtual address fa51a800
> > > > 
> > > > is bitstart incorrect or is the thing just not (yet) mapped?
> > > 
> > > Looks like the screen_base is not mapped to.
> > 
> > rc3 worked ok, rc4 does not. testing the -bk snapshots now.
> 
> bk8 works, bk9 breaks, it contains the radeonfb update.
> it works ok if the driver is compiled into the kernel.

Ah, that's a good point. Can you send me the dmesg outputs of in kernel
vs. in module with radeonfb verbose debug enabled ?

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: [Linux-fbdev-devel] Re: 2.6.11-rc5

[Benjamin Herrenschmidt]

On Fri, 2005-02-25 at 21:24 +0100, Olaf Hering wrote:
>  On Fri, Feb 25, James Simmons wrote:
> 
> > 
> > > cfb_imageblit(320) dst1 fa51a800 base e0b8 bitstart 1999a800
> > > fast_imageblit(237) s daea4000 dst1 fa51a800
> > > fast_imageblit(269) j 1 fa51a800 0
> > > Unable to handle kernel paging request at virtual address fa51a800
> > > 
> > > is bitstart incorrect or is the thing just not (yet) mapped?
> > 
> > Looks like the screen_base is not mapped to.
> 
> rc3 worked ok, rc4 does not. testing the -bk snapshots now.

Oh, it's probably the new radeonfb, I have no doubt about that, but I
think the problems has to do with a bogus mode. Maybe set_par is simply
failing and the fbdev layer still tries to tap the card or something
like that. Please, enable verbose debug, add some printk's around
set_par to check what the mode looks like and what gets ioremap'ed.

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] allow vma merging with mlock et. al.

[Andrea Arcangeli]

On Fri, Feb 25, 2005 at 03:38:06PM -0800, Chris Wright wrote:
> I don't have a good sampling of applications.  The one's I've used are
> temporal like gpg, or they mlockall the whole thing and never look back.
> But I did a quick benchmark since I was curious, a simple loop of a
> million lock/unlock cycles of a page that could trigger a merge:
> 
> vanilla
> (no merge): 659706 usecs
> 
> patched
> (merge):3567020 usecs
> 
> Heh, I was surprised to see it that much slower.

The object of the merge is to save memory, and to reduce the size of the
rbtree that might payoff during other operations (with a smaller tree,
lookups will be faster too). If you only measure the time of creating
and removing a mapping then it should be normal that you see a slowdown
since merging involves more work than non-merging. The payoff is
supposed to be in the other operations.

The reason mlock doesn't merge is that nobody asked for it yet, but it
was originally supposed to merge too (I stopped at mremap since mlock
wasn't high prio to fixup). But the long term plan was to eventually add
merging to mlock too and it's good that you're optimizing it now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5

[Benjamin Herrenschmidt]

> > It seem to detect the flat panel incorrectly, or the EDID data is bogus,
> > maybe that's wrecking something in the new modelist management in
> > fbdev ? It might be causing us to use a bogus mode that itself casues
> > atyfb to crash. Tried forcing a mode ?
> 
> cfb_imageblit(320) dst1 fa51a800 base e0b8 bitstart 1999a800
> fast_imageblit(237) s daea4000 dst1 fa51a800
> fast_imageblit(269) j 1 fa51a800 0
> Unable to handle kernel paging request at virtual address fa51a800
> 
> is bitstart incorrect or is the thing just not (yet) mapped?

It should be all mapped, i suspect the mode set is totally bogus. To
check it, can you enable radeonfb verbose debug ?


> radeonfb: Found Intel x86 BIOS ROM Image
> radeonfb: Retreived PLL infos from BIOS
> radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=133.00 Mhz, System=133.00 MHz
> radeonfb: PLL min 12000 max 35000
> radeonfb: Monitor 1 type DFP found
> radeonfb: EDID probed
> radeonfb: Monitor 2 type no found
> radeonfb: Assuming panel size 8x1
> radeonfb: Can't find mode for panel size, going back to CRT
> cfb_imageblit(320) dst1 fa51a800 base e0b8 bitstart 1999a800
> fast_imageblit(237) s daea4000 dst1 fa51a800
> fast_imageblit(269) j 1 fa51a800 0
> Unable to handle kernel paging request at virtual address fa51a800
>  printing eip:
> c020f17e
> *pde = 
> Oops: 0002 [#1]
> Modules linked in: ohci1394 ieee1394 radeonfb i2c_algo_bit i2c_core ehci_hcd 
> uhci_hcd capability usbcore
> CPU:0
> EIP:0060:[]Tainted: G U VLI
> EFLAGS: 00010282   (2.6.11-rc5-20050225-default)
> EIP is at cfb_imageblit+0x57e/0x67c
> eax:    ebx: 0001   ecx:    edx: fa51a800
> esi: fa51a804   edi: daea4000   ebp: 0004   esp: dcae9c14
> ds: 007b   es: 007b   ss: 0068
> Process modprobe (pid: 2080, threadinfo=dcae8000 task=dc4a7550)
> Stack: c01110ac 0001 c0321d60 dcae9c20 dcae9c20 c01303a2 0001 c03c87a8
>000a dae23ca8 c011c783 0046  dc202000 0046 dcae9c64
>c010513d 384d dc202290 0007 c032db20 daea4000  000f
> Call Trace:
>  [] smp_local_timer_interrupt+0xc/0x50
>  [] handle_IRQ_event+0x32/0x70
>  [] __do_softirq+0x43/0xa0
>  [] do_IRQ+0x3d/0x60
>  [] soft_cursor+0x190/0x200
>  [] bit_cursor+0x48c/0x4f0
>  [] radeonfb_prim_fillrect+0xf1/0x120 [radeonfb]
>  [] msleep+0x2f/0x40
>  [] fbcon_cursor+0x1a8/0x280
>  [] hide_cursor+0x18/0x30
>  [] redraw_screen+0x174/0x200
>  [] fbcon_prepare_logo+0x39a/0x3a0
>  [] fbcon_init+0x2b0/0x370
>  [] visual_init+0xe9/0x170
> 
-- 
Benjamin Herrenschmidt <[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: 2.6.11-rc5

[Olaf Hering]

 On Fri, Feb 25, Linus Torvalds wrote:

> 
> 
> On Sat, 26 Feb 2005, Olaf Hering wrote:
> > 
> > modedb can not be __init because fb_find_mode() may get db == NULL.
> > fb_find_mode() is called from modules.
> 
> Ack. Maybe somebody should run the scripts again to check that we don't 
> reference __init data from non-init functions.

sparse doesnt do that, yet? (I never looked at 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: 2.6.11-rc5

[Benjamin Herrenschmidt]

On Fri, 2005-02-25 at 14:30 +0100, Mws wrote:
> hi,
> 
> i also have problems with 2.6.11-rc5 and radeon:
> 
> i am using a ATI Radeon X600 PciExpress.
> 
> a) now the console framebuffer seems to bee working, thx benjamin :)
> b) when bootup seq ist completed and i want to start X (xorg-x11) with 
> ati-drivers
> x is freezing - not your problem, but the console is not correctly 
> restored :/ the only way
> out is to reset the machine :/
> 2.6.11-rc3 was running fine in this case

Hrm, the binary drivers ? oh well... some users had them freezing vs.
radeonfb before and not now. I don't know what they do and don't have
access to a machine with them (there are no ppc versions) so it will be
difficult to track. I suspect they completely reconfigure the chip and
don't restore it properly tho.

What exactly is happening. Does X launches at all ? When does it
freeze ? On X launch or when exiting it ? Have you tried disabling
dynamic clock tweaking ? (radeonfb.default_dynclk=-1 or 0 on the
cmdline, first one means "don't touch the registers", secoond one means
"disable dynamic clocks").

> i have attached my lspci -vv & lspci -tv output and following a small seq of 
> the dmesg output
> when initializing the radeon fb.
> 
> if i can provide/assit  you with testing, i am available to do so, also if 
> you need more information
> on my system.
> 
> i am subscribed to lkml, but i would like to be included into cc seprately, 
> thx.
> 
> 
>  radeonfb_pci_register BEGIN
> ACPI: PCI interrupt :05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
> radeonfb (:05:00.0): Found 131072k of DDR 128 bits wide videoram
> radeonfb (:05:00.0): mapped 16384k videoram
> radeonfb: Found Intel x86 BIOS ROM Image
> radeonfb: Retreived PLL infos from BIOS
> radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=400.00 Mhz, System=300.00 MHz
> radeonfb: PLL min 2 max 4
> 1 chips in connector info
>  - chip 1 has 2 connectors
>   * connector 0 of type 2 (CRT) : 2300
>   * connector 1 of type 3 (DVI-I) : 3221
> Starting monitor auto detection...
> radeonfb: I2C (port 1) ... not found
> radeonfb: I2C (port 2) ... not found
> radeonfb: I2C (port 3) ... found CRT display
> radeonfb: I2C (port 4) ... not found
> radeonfb: I2C (port 2) ... not found
> radeonfb: I2C (port 4) ... not found
> radeonfb: I2C (port 3) ... found CRT display
> radeonfb: Monitor 1 type CRT found
> radeonfb: EDID probed
> radeonfb: Monitor 2 type no found
>   Display is GTF capable
> hStart = 1344, hEnd = 1504, hTotal = 1728
> vStart = 1025, vEnd = 1028, vTotal = 1072
> h_total_disp = 0x9f00d7  hsync_strt_wid = 0x14054a
> v_total_disp = 0x3ff042f vsync_strt_wid = 0x30400
> pixclock = 6349
> freq = 15750
> freq = 15750, PLL min = 2, PLL max = 4
> ref_div = 12, ref_clk = 2700, output_freq = 31500
> ref_div = 12, ref_clk = 2700, output_freq = 31500
> post div = 0x1
> fb_div = 0x8c
> ppll_div_3 = 0x1008c
> Console: switching to colour frame buffer device 160x64
> radeonfb (:05:00.0): ATI Radeon [b 
> radeonfb_pci_register END
> 
-- 
Benjamin Herrenschmidt <[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: 2.6.11-rc5

[Linus Torvalds]

On Sat, 26 Feb 2005, Olaf Hering wrote:
> 
> modedb can not be __init because fb_find_mode() may get db == NULL.
> fb_find_mode() is called from modules.

Ack. Maybe somebody should run the scripts again to check that we don't 
reference __init data from non-init functions.

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

Re: prism54 not releasing region

[Panagiotis Issaris]

Andrew Morton wrote:
Panagiotis Issaris <[EMAIL PROTECTED]> wrote:
 

To my newbie eye it looked as if the region requested at line 154
weren't released in case of the line 166 failure handling. Is
my assumption right?
   

It is.  I can take care of this patch for you, thanks.
 

Great! :-) Thanks!
With friendly regards,
Takis
--
 K.U.Leuven, Mechanical Eng.,  Mechatronics & Robotics Research Group
 http://people.mech.kuleuven.ac.be/~pissaris/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5

[Olaf Hering]

 On Thu, Feb 24, Olaf Hering wrote:

>  On Wed, Feb 23, Linus Torvalds wrote:
> 
> > This time it's really supposed to be a quickie, so people who can, please 
> > check it out, and we'll make the real 2.6.11 asap.
> 
> radeonfb oopses on intel.
> Havent checked yet when it started with it.
> 
> ACPI: PCI interrupt :00:12.0[A] -> GSI 11 (level, low) -> IRQ 11
> eth0: VIA Rhine II at 0x1c400, 00:11:5b:83:1e:76, IRQ 11.
> eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.
> usb 5-1: new low speed USB device using uhci_hcd and address 2
> ACPI: PCI interrupt :01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
> radeonfb: Found Intel x86 BIOS ROM Image
> radeonfb: Retreived PLL infos from BIOS
> radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=133.00 Mhz, System=133.00 MHz
> radeonfb: PLL min 12000 max 35000
> NET: Registered protocol family 23
> radeonfb: Monitor 1 type DFP found
> radeonfb: EDID probed
> radeonfb: Monitor 2 type no found
> radeonfb: Assuming panel size 8x1
> radeonfb: Can't find mode for panel size, going back to CRT
> Unable to handle kernel paging request at virtual address f3fb4000
>  printing eip:
> c01dec14
> *pde = 
> Oops: 0002 [#1]
> Modules linked in: via_ircc irda crc_ccitt snd_via82xx snd_ac97_codec snd_pcm 
> snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device 
> snd soundcore radeonfb i2c_algo_bit i2c_core via_rhine mii pci_hotplug 
> ohci1394 ehci_hcd ieee1394 uhci_hcd via_agp agpgart usbcore reiserfs dm_mod 
> ext3 jbd
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00010202   (2.6.11-rc4-bk10-200502230204-usbtest)
> EIP is at cfb_imageblit+0x364/0x610
> eax:    ebx: f3fb4004   ecx:    edx: f3fb4000
> esi: 0004   edi: df282000   ebp: 0007   esp: dbef1c1c
> ds: 007b   es: 007b   ss: 0068
> Process modprobe (pid: 3180, threadinfo=dbef task=da303580)
> Stack: 0001 0008 0001 0008 0001 c04a7428 000a da302628
>c011b293 0046 da36e23c da36e000 0046 051f c01043cf c0102eca
>051f 1c46ece9 002b c036a2c0 df282000  000f 0001
> Call Trace:
>  [] __do_softirq+0x43/0xa0
>  [] do_IRQ+0x1f/0x30
>  [] common_interrupt+0x1a/0x20
>  [] soft_cursor+0x190/0x200
>  [] bit_cursor+0x464/0x4e0
>  [] msleep+0x2f/0x40
>  [] fbcon_cursor+0x1a8/0x280
>  [] hide_cursor+0x18/0x30
>  [] redraw_screen+0x174/0x200
>  [] fbcon_prepare_logo+0x39a/0x3a0
>  [] fbcon_init+0x260/0x300
>  [] visual_init+0xe9/0x170
>  [] take_over_console+0x176/0x350
>  [] fbcon_takeover+0x5a/0x90
>  [] fbcon_fb_registered+0x5a/0x70
>  [] fbcon_event_notify+0x52/0x80
>  [] notifier_call_chain+0x18/0x30
>  [] register_framebuffer+0xd7/0x150
>  [] release_console_sem+0x13/0x90
>  [] sysfs_new_dirent+0x17/0x60
>  [] sysfs_make_dirent+0x10/0x70
>  [] sysfs_add_file+0x3a/0x60
>  [] radeonfb_pci_register+0x308/0x510 [radeonfb]
>  [] pci_device_probe_static+0x32/0x50
>  [] __pci_device_probe+0x27/0x40
>  [] pci_device_probe+0x1b/0x40
>  [] driver_probe_device+0x21/0x60
>  [] driver_attach+0x4d/0x80
>  [] bus_add_driver+0x6d/0xa0
>  [] driver_register+0x28/0x30
>  [] pci_register_driver+0x54/0x70
>  [] sys_init_module+0x112/0x190
>  [] sysenter_past_esp+0x52/0x79
> Code: 24 60 8b 54 24 58 29 ce 0f be 07 89 f1 d3 f8 21 d0 8b 54 24 4c 8b 4c 24 
> 54 23 0c 82 8b 54 24 64 89 c8 31 d0 89 da 83 c3 04 85 f6 <89> 02 75 06 be 08 
> 00 00 00 47 8b 04 24 48 89 04 24 83 3c 24 ff
>  <6>usbcore: registered new driver hiddev
> input: USB HID v1.10 Mouse [Logitech Apple Optical USB Mouse] on 
> usb-:00:10.2-1
> usbcore: registered new driver usbhid
> drivers/usb/input/hid-core.c: v2.0:USB HID core driver

modedb can not be __init because fb_find_mode() may get db == NULL.
fb_find_mode() is called from modules.

Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>

diff -purNx tags linux-2.6.11-rc5.orig/drivers/video/modedb.c 
linux-2.6.11-rc5/drivers/video/modedb.c
--- linux-2.6.11-rc5.orig/drivers/video/modedb.c2005-02-24 
17:40:24.0 +0100
+++ linux-2.6.11-rc5/drivers/video/modedb.c 2005-02-26 01:37:43.138003474 
+0100
@@ -37,7 +37,7 @@ const char *global_mode_option;
 
 #define DEFAULT_MODEDB_INDEX   0
 
-static const __init struct fb_videomode modedb[] = {
+static const struct fb_videomode modedb[] = {
 {
/* 640x400 @ 70 Hz, 31.5 kHz hsync */
NULL, 70, 640, 400, 39721, 40, 24, 39, 9, 96, 2,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix panic in 2.6 with bounced bio and dm

[Linus Torvalds]

On Fri, 25 Feb 2005, Andrew Morton wrote:
> 
> It seems very weird for dm to be shoving NULL page*'s into the middle of a
> bio's bvec array, so your fix might end up being a workaround pending a
> closer look at what's going on in there.

Yes. I don't see how this patch can be anything but bandaid to hide the 
real bug. Where do these "non-page" bvec's originate?

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

Re: Inconsistent kallsyms data (since 2.6.11-rc3 or so)

[Keith Owens]

On Fri, 25 Feb 2005 11:33:48 +0100 (CET), 
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
>
>One of my m68k configs has been giving
>
>| Inconsistent kallsyms data
>| Try setting CONFIG_KALLSYMS_EXTRA_PASS
>
>since 2.6.11-rc3 or so. Setting CONFIG_KALLSYMS_EXTRA_PASS, or applying Keith
>Owen's patch to fix an issue for SH
>(http://seclists.org/lists/linux-kernel/2005/Jan/0017.html) doesn't help.
>
>The diffs between the human-readable tables (as generated by Keith's
>kallsyms_uncompress.pl) show lots of changes (see below).
>
>Related config settings:
>
>| anakin$ grep kallsyms .config
>| CONFIG_KALLSYMS=y
>| # CONFIG_KALLSYMS_ALL is not set
>| CONFIG_KALLSYMS_EXTRA_PASS=y
>| anakin$
>
>Any other info that's needed to solve this issue? Thanks!

Apply the patch below to preserve the .S files, turn off
CONFIG_KALLSYMS_EXTRA_PASS, make vmlinux and send me the tarball from
these commands

objdump -h .tmp_vmlinux* > .tmp_objdump
nm -A .tmp_vmlinux* > .tmp_nm
tar czvf kallsyms-m68k.tar.gz .tmp_kallsyms* .tmp_objdump .tmp_nm

Index: linux/Makefile
===
--- linux.orig/Makefile 2005-02-12 18:40:12.0 +1100
+++ linux/Makefile  2005-02-26 11:32:19.300871801 +1100
@@ -685,7 +685,7 @@ define verify_kallsyms
$(Q)cmp -s System.map .tmp_System.map ||  \
(echo Inconsistent kallsyms data; \
 echo Try setting CONFIG_KALLSYMS_EXTRA_PASS; \
-rm .tmp_kallsyms* ; /bin/false )
+rm .tmp_kallsyms*.o ; /bin/false )
 endef
 
 # Update vmlinux version before link


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

Re: prism54 not releasing region

[Andrew Morton]

Panagiotis Issaris <[EMAIL PROTECTED]> wrote:
>
> To my newbie eye it looked as if the region requested at line 154
> weren't released in case of the line 166 failure handling. Is
> my assumption right?

It is.  I can take care of this patch for you, 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: [PATCH] Fix panic in 2.6 with bounced bio and dm

[Andrew Morton]

Mark Haverkamp <[EMAIL PROTECTED]> wrote:
>
> 
> Last September a fix was checked in for a memory leak problem in
> bounce_end_io causing the entire bio to be checked.  This ended up
> causing some dm cloned bios that had bounce buffers to free NULL pages
> because their bi_idx can be non-zero.   This patch skips NULL pages in
> the bio's bio_vec.  I'm not sure if this is the most optimal fix but I
> think that it is safe since bvec_alloc memsets the bio_vec to zero.
> 

Thanks, we should get fixed for 2.6.11.

It seems very weird for dm to be shoving NULL page*'s into the middle of a
bio's bvec array, so your fix might end up being a workaround pending a
closer look at what's going on in there.

> 
> = mm/highmem.c 1.55 vs edited =
> --- 1.55/mm/highmem.c 2005-01-07 21:44:13 -08:00
> +++ edited/mm/highmem.c   2005-02-25 07:54:21 -08:00
> @@ -319,7 +319,7 @@
>*/
>   __bio_for_each_segment(bvec, bio, i, 0) {
>   org_vec = bio_orig->bi_io_vec + i;
> - if (bvec->bv_page == org_vec->bv_page)
> + if (!bvec->bv_page || bvec->bv_page == org_vec->bv_page)
>   continue;
>  
>   mempool_free(bvec->bv_page, pool);  
> 
> -- 
> Mark Haverkamp <[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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

prism54 not releasing region

[Panagiotis Issaris]

Hi,

To my newbie eye it looked as if the region requested at line 154
weren't released in case of the line 166 failure handling. Is
my assumption right?

With friendly regards,
Takis

diff -uprN linux-2.6.11-rc5-orig/drivers/net/wireless/prism54/islpci_hotplug.c 
linux-2.6.11-rc5-pi/drivers/net/wireless/prism54/islpci_hotplug.c
--- linux-2.6.11-rc5-orig/drivers/net/wireless/prism54/islpci_hotplug.c 
2005-02-26 00:33:19.0 +0100
+++ linux-2.6.11-rc5-pi/drivers/net/wireless/prism54/islpci_hotplug.c   
2005-02-26 00:34:13.0 +0100
@@ -163,7 +163,7 @@ prism54_probe(struct pci_dev *pdev, cons
if (rvalue || !mem_addr) {
printk(KERN_ERR "%s: PCI device memory region not configured; 
fix your BIOS or CardBus bridge/drivers\n",
   DRV_NAME);
-   goto do_pci_disable_device;
+   goto do_pci_release_regions;
}
 
/* enable PCI bus-mastering */

-- 
OpenPGP key: http://lumumba.luc.ac.be/takis/takis_public_key.txt
fingerprint: 6571 13A3 33D9 3726 F728  AA98 F643 B12E ECF3 E029
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Intel ICH7 SATA support question for ATA_PIIX

[Jeff Garzik]

Greg Felix wrote:
I have two new OEM machines that are both ICH7 chipsets.  
Both machines give the same vendor and device PCI ids for their
storage controllers.

8086:27df and 8086:27c0
I noticed that Jason Gaston submitted a patch that made it into
2.6.11-rc1 to add support for ICH7 into ata_piix.  I'm using
2.6.11-rc5 and am getting good results on one of my machines.
The problem I'm having is that the other machine doesn't seem to be
supported even though it appears to be the same controller (by PCI ID
at least).  My modules.pcimap file shows that x27df and x27c0 are both
mapped to the piix driver.  I'm seeing nothing in /proc/partitions.
Perhaps someone at Intel, or HP, or Jason Gaston, or Jeff Garzik even
can shed some light on this or tell me where I can look to determine a
chipset version number that can be used to differentiate the two
boxes?  I'll gladly provide any more information I've forgotten.
See REPORTING-BUGS for the sort of information you should provide.  This 
is a "it doesn't work" report without much more info.

I would suggest doing a "modprobe ata_piix" or "modprobe ahci" 
(depending on ICH7 mode and hardware) and see what happens in 'dmesg'.

Jeff

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

Re: Help tracking down problem --- endless loop in __find_get_block_slow

[Jeff Mahoney]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew Morton wrote:
> Jeff Mahoney <[EMAIL PROTECTED]> wrote:
> 
>>In my experience, the loop is actually outside of
>>__find_get_block_slow(), in __getblk_slow(). I've been using xmon to
>>interrupt the kernel, and the results vary but are all rooted in the
>>for(;;) loop in __getblk_slow. It appears as though grow_buffers is
>>finding/creating the page, but then __find_get_block can't locate the
>>buffer it needs.
> 
> 
> Yes, that'll happen.  Because there are still buffers attached to the page
> which have the wrong blocksize.  Say, if someone is trying to read a 2k
> buffer_head which is backed by a page which already has 1k buffer_heads
> attached to it.
> 
> Does your kernel not have that big printk in __find_get_block_slow()?  If
> it does, maybe some of the buffers are unmapped.  Try:

I think it's likely I'm experiencing a different bug than the original
poster. I've tried making the printk unconditional, and I get no output.
However, I've continued to track it down, and I believe I've found a
umount race. I can also reproduce it without subfs, with the attached
script.

I added some debug output to aid in my search:
__find_get_block_slow: find_get_page
[block=17508,blksize=2048,index=8754,sizebits=1,size=512] returned null
returning page [index=2188,block=17504,size=512,sizebits=3]
Couldn't find buffer @ block 17508

What I'm observing is that __find_get_block_slow is calculating the
index using the blocksize for the device, and the grow_buffers call is
using the blocksize handed down from the filesystem via sb_bread(). They
*should* be the same, but here's where my suspected race comes in. Since
the buffers are being searched for in the wrong place, they're never
found, causing the infinite loop.

The open_bdev_excl() call in get_sb_bdev() should be keeping callers out
until the block device is actually closed, but it uses the fs_type
struct as the holder which, given that the filesystem to be mounted is
the same one as the one being umounted, will be the same. This allows
the mount attempt to continue. If the superblock for the umounting
filesystem is already in the process of getting shut down, sget() will
create a new superblock and the mount attempt will use that one. The
umount will continue, destroying the old superblock and setting the
blocksize back to its original value, dropping all buffers in the process.

If kill_block_super resets the blocksize while an sb_bread is in
progress, the sizes won't match up and we'll get stuck in the loop.

I'll be working on a fix, but figured I'd send out a quick update.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCH7zXLPWxlyuTD7IRAr/WAJ9B6MLsKl6cv48Qlcklx1saYERv7ACdHWGW
UBXAsQBiEAge3T1R4akLKd0=
=w1zP
-END PGP SIGNATURE-


test.sh
Description: Bourne shell script

Re: [PATCH] Symlink /sys/class/block to /sys/block

[Greg KH]

On Sat, Feb 26, 2005 at 12:53:49AM +0100, Kay Sievers wrote:
> On Fri, Feb 25, 2005 at 02:39:27PM -0800, Greg KH wrote:
> > > The hotplug events will still have the /block/* devpath, so this symlink
> > > will give us nothing than problems.
> > 
> > It will not give hotplug programs issues, as the block devpath still
> > remains the same.
> 
> No, but anything like udevstart or HAL coldplugging will have a problem
> with that inconsistency.

Damm, forgot about that, good point :)

Ok, forget the symlink.  Or, for that matter, ever moving from
/sys/block/...

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] Symlink /sys/class/block to /sys/block

[Kay Sievers]

On Fri, Feb 25, 2005 at 02:39:27PM -0800, Greg KH wrote:
> On Fri, Feb 25, 2005 at 01:35:13AM +, Kay Sievers wrote:
> > Greg KH  suse.de> writes:
> > 
> > > 
> > > On Wed, Feb 23, 2005 at 09:43:35AM +, Malcolm Rowe wrote:
> > > > Greg KH writes: 
> > > > 
> > > > >>Following the discussion in [1], the attached patch creates 
> > > > >>/sys/class/block
> > > > >>as a symlink to /sys/block. The patch applies to 2.6.11-rc4-bk7.  
> > > > >>
> > > > >>Please cc: me on any replies - I'm not subscribed to the mailing 
> > > > >>list. 
> > > > >Hm, your patch is linewrapped, and can't be applied :(
> > > > 
> > > > Bah, and I did send it to myself first, but I guess my mailer un-flowed 
> > > > it 
> > > > for me .  I'll try to find a better mailer. 
> > > > 
> > > > >But more importantly:
> > > > >>static void disk_release(struct kobject * kobj)
> > > > >
> > > > >Did you try to remove a disk (like a usb device) and see what happens
> > > > >here?  Hint, this isn't the proper place to remove the symlink...
> > > > 
> > > > Er, yeah. Oops. 
> > > > 
> > > > *Is* there a sensible place to remove the symlink from, though?  Nobody 
> > > > seems to call subsystem_unregister(&block_subsys), which is the place 
> > > > I'd 
> > > > expect to add a call to, and I can't see anything that's otherwise 
> > > > obvious... 
> > > 
> > > If the subsystem is never unregistered, then don't worry about undoing
> > > the symlink.
> > 
> > This symlink will break a lot of applications out there. If there is not a
> > _very_ good reason for it, we should not do that.
> 
> People seem to want it for some odd reason, I haven't seen a good reason
> yet though, let alone a working patch :)

Good.

> > The "dev" file unfortunately does not tell you if it's a char or block
> > device node and that should be solved by something better than matching a
> > magic string somewhere in the middle of a devpath.
> 
> Use the subsystem value.  If it's "block", it's a block device,
> otherwise it's a char device.  Don't we already do this in udev today?

You don't have any subsystem value if you get a device list from
sysfs, right?

> > The hotplug events will still have the /block/* devpath, so this symlink
> > will give us nothing than problems.
> 
> It will not give hotplug programs issues, as the block devpath still
> remains the same.

No, but anything like udevstart or HAL coldplugging will have a problem
with that inconsistency.

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

Re: Greg's Decree! (was Re: Linus' decrees?)

[jmerkey]

His point and direction (or lack thereof) are easy to see, and 
consistent. Linux has been a war of attrition
with an interesting rat's maze model of human intereaction -- always 
interesting to see new mice traverse the
maze (only there's no cheese at the end of this maze -- just the smell 
of cheese -- the cheese is on Linus'
desk outside the maze, and all the mice inside the maze are madly 
looking for it, and being driven
quite mad). :-)

Cheers,
Jeff
Andre Hedrick wrote:
Greg,
Linus is not always correct, sometimes his point of view is hard to see.
My shoulders got in the way most of the time; however, Linus is
consistant.  Well until he changes his mind.
Crack ??  Get some plumber's putty to smooth over the gap.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Thu, 24 Feb 2005, Greg Folkert wrote:
 

On Thu, 2005-02-24 at 15:03 -0500, Stuart MacDonald wrote:
   

Recently I ran across
http://groups.google.ca/groups?hl=en&lr=lang_en&safe=off&selm=1033074519.2698.5.
camel%40localhost.localdomain
Is there a collection point for Linus' decrees?
The LSB (http://www.linuxbase.org/) seems to be mostly involved with
how a distro is laid out, and not much to do with the kernel.
 

Okay, Linus decreed... oh yeah.
Exactly what is wrong with the method anyway?
You on Crack?
And no... that is not a decree in the traditional sense. It is more like
me saying:
   "I decree that Linus Torvalds is the lead maintainer of the
   Linux Kernel"
Make TONS-O-SENSE to state the obvious. IOW the statement was all meant
to say *DO IT THIS WAY AND NO OTHER* as nobody else honors any other
method.
--
greg, [EMAIL PROTECTED]
The technology that is
Stronger, better, faster: Linux
   

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

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

Re: [RFC][PATCH] add driver matching priorities

[Greg KH]

On Thu, Feb 10, 2005 at 04:37:03PM -0500, Adam Belay wrote:
> On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
> > On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > > > I think the issue that Al raises about drivers grabbing devices, and
> > > > then trying to unbind them might be a real problem.
> > > 
> > > I agree.  Do you think registering every in-kernel driver before probing
> > > hardware would solve this problem?
> > 
> > In which case, consider whether we should be tainting the kernel if
> > someone loads a device driver, it binds to a device, and then they
> > unload that driver.
> > 
> > It's precisely the same situation, and precisely the same mechanics
> > as what I've suggested should be going on here.  If one scenario is
> > inherently buggy, so is the other.
> > 
> 
> I think it would depend on whether the user makes the device busy before
> the driver is unloaded.  Different device classes may have different
> requirements for when and how a device can be removed.  Are there other
> issues as well?  Maybe there are ways to improve driver start and stop
> mechanics.

We never fail a device unbind from a driver, so this isn't as big a deal
as I originally thought.  Yes, userspace can get messy, but as userspace
was the one that loaded the new driver to bind, it's acceptable.

So, care to resubmit your 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: [RFC] PCI bridge driver rewrite

[Greg KH]

On Thu, Feb 24, 2005 at 01:22:01AM -0500, Adam Belay wrote:
> Hi all,
> 
> For the past couple weeks I have been reorganizing the PCI subsystem to
> better utilize the driver model.  Specifically, the bus detection code
> is now using a standard PCI driver.  It turns out to be a major
> undertaking, as the PCI probing code is closely tied into a lot of other
> PCI components, and is spread throughout various architecture specific
> areas.  I'm hoping that these changes will allow for a much cleaner and
> more functional PCI implementation.
> 
> The basic flow of the new code is as follows:
> 1.) A standard "driver core" driver binds to a bridge device.
> 2.) When "*probe" is called it sets up the hardware and allocates a
> "struct pci_bus".
> 3.) The "struct pci_bus" is filled with information about the detected
> bridge.
> 4.) The driver then registers the "struct pci_bus" with the PCI Bus
> Class.
> 5.) The PCI Bus Class makes the bridge available to sysfs.
> 6.) It then detects hardware attached to the bridge.
> 7.) Each new PCI bridge device is registered with the driver model.
> 8.) All remaining PCI devices are registered with the driver model.
> 
> Steps 7 and 8 allow for better resource management.
> 
> 
> I've attached an early version of my code.  It has most of the new PCI
> bus class registration code in place, and an early implementation of the
> PCI-to-PCI bridge driver.  The following remains to be done:
> 
> 1.) refine and cleanup the new PCI Bus API
> 2.) export the new API in "linux/pci.h", and cleanup any users of the
> old code.
> 3.) fix every PCI hotplug driver.
> 4.) write a bridge driver for the PCI root bridge
> 5.) write a bridge driver for Cardbus hardware
> 6.) refine device registration order
> 7.) redesign PCI bus number assignment and support bus renumbering
> 8.) redesign PCI resource management to be compatible with the new code
> 9.) testing on various architectures
> 10.) Write "*suspend" and "*resume" routines for PCI bridges.  Any ideas
> on what needs to be done?
> 11.) fix "PCI_LEGACY" (I may have broke it, but it should be trivial)
> 
> I look forward to any comments or suggestions.

I like it all :)

If you want to submit patches now that rearrange the code to make it
easier for you to modify in the future to achieve the above goals, feel
free, I'll gladly take them.

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] allow vma merging with mlock et. al.

[Chris Wright]

* Darren Hart ([EMAIL PROTECTED]) wrote:
> As I understand it, the reason we don't merge is because 
> it is expected that a task will lock and unlock the same memory range 
> more than once and we don't want to waste our time merging and splitting 
> the VMAs.

I don't have a good sampling of applications.  The one's I've used are
temporal like gpg, or they mlockall the whole thing and never look back.
But I did a quick benchmark since I was curious, a simple loop of a
million lock/unlock cycles of a page that could trigger a merge:

vanilla
(no merge): 659706 usecs

patched
(merge):3567020 usecs

Heh, I was surprised to see it that much slower.

cheers,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Intel ICH7 SATA support question for ATA_PIIX

[Greg Felix]

I have two new OEM machines that are both ICH7 chipsets.  
Both machines give the same vendor and device PCI ids for their
storage controllers.

8086:27df and 8086:27c0

I noticed that Jason Gaston submitted a patch that made it into
2.6.11-rc1 to add support for ICH7 into ata_piix.  I'm using
2.6.11-rc5 and am getting good results on one of my machines.

The problem I'm having is that the other machine doesn't seem to be
supported even though it appears to be the same controller (by PCI ID
at least).  My modules.pcimap file shows that x27df and x27c0 are both
mapped to the piix driver.  I'm seeing nothing in /proc/partitions.

Perhaps someone at Intel, or HP, or Jason Gaston, or Jeff Garzik even
can shed some light on this or tell me where I can look to determine a
chipset version number that can be used to differentiate the two
boxes?  I'll gladly provide any more information I've forgotten.

Also the machine that isn't working has a Broadcom Gigabit NIC that
isn't being recognized by the tg3 module.  I'm seeing no eth0 in
/sys/class/net. It's PCI ID is 14e4:1600.

Greg Felix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-fbdev-devel] Re: 2.6.11-rc5

[Olaf Hering]

 On Fri, Feb 25, Olaf Hering wrote:

>  On Fri, Feb 25, Olaf Hering wrote:
> 
> >  On Fri, Feb 25, James Simmons wrote:
> > 
> > > 
> > > > cfb_imageblit(320) dst1 fa51a800 base e0b8 bitstart 1999a800
> > > > fast_imageblit(237) s daea4000 dst1 fa51a800
> > > > fast_imageblit(269) j 1 fa51a800 0
> > > > Unable to handle kernel paging request at virtual address fa51a800
> > > > 
> > > > is bitstart incorrect or is the thing just not (yet) mapped?
> > > 
> > > Looks like the screen_base is not mapped to.
> > 
> > rc3 worked ok, rc4 does not. testing the -bk snapshots now.
> 
> bk8 works, bk9 breaks, it contains the radeonfb update.
> it works ok if the driver is compiled into the kernel.


 modedb = rinfo->mon1_modedb; passes some shit to fb_find_mode() which
 kills my screen(1) when DPRINTK is enabled. it dies because bitstart
 relies on xres_virtual which is 0xcc or whatever.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Xterm Hangs - Possible scheduler defect?

[Lee Revell]

On Fri, 2005-02-25 at 16:02 -0500, Chad N. Tindel wrote:
> They're expensive and customers don't expect a single userspace thread to
> tie up the other 63 CPUs no matter how buggy it is.  It is intuitively obvious
> that a buggy kernel can bring a system to its knees, but it is not intuitively
> obvious that a buggy userspace app can do the same thing.  It is more of a 
> supportability issue than anything, because you expect the other processors
> to function properly so you can get in and live-debug the application when it
> hits a bug that makes it CPU-bound.  This is especially important if the box 
> is, say, in a remote jungle of China or something where you don't have access 
> to the console.

"Unix policy is to not stop root from doing stupid things because
that would also stop him from doing clever things." - Andi Kleen

"It's such a fine line between stupid and clever" - Derek Smalls

Lee

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

Re: [2.6 patch] unexport do_settimeofday

[Andrew Morton]

Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > +#ifdef MODULE
> > +#define __deprecated_in_modules __deprecated
> > +#else
> > +#define __deprecated_in_modules /* OK in non-modular code */
> > +#endif
> > +
> >...
> 
> Looks good.
> 
> 
> One more question:
> 
> You get a false positive if the file containing the symbol is itself a 
> module.

I don't understand what you mean.

You mean that a module is doing an EXPORT_SYMBOL of a symbol which is on
death row?

If so: err, not sure.  I guess we could just live with the warning.

> Is there any way to solve this without additional #define's and #ifdef's 
> for each symbol?

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

[OT] Re: M$ gets into autos!

[Wakko Warner]

linux-os wrote:
> Sorry officer. I had to reboot!

I'll keep all computer OS's from my car if I can help it !  =)

> Microsoft collaborates with Samsung, ScanSoft, Siemens, SiRF, Xilinx
> and auto component player Magneti Marelli to develop a telematics
> system to be integrated into an Italian line of cars.
> http://email.electronicnews.com/cgi-bin2/DM/y/ek4S0GGtJE0DbD0CQa30E3

Reminds me of the mechanical, electrical, and M$ engineer in a car and it
stalls.

mechanical engineer wants to disect the car to find a mechanical fault.
electrical engineer wants to pull out all the wiring to find an electrical
fault.
M$ engineer suggests they roll up the windows, turn off the car, get out,
close the doors, get back in and start the car again.

God imaging how many cars you'd see on the side of the road with people
getting in and out to restart them.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] unexport do_settimeofday

[Adrian Bunk]

On Fri, Feb 25, 2005 at 01:55:04PM -0800, Andrew Morton wrote:
>...
> --- 25/include/linux/compiler.h~a 2005-02-25 13:53:32.0 -0800
> +++ 25-akpm/include/linux/compiler.h  2005-02-25 13:54:45.0 -0800
> @@ -86,6 +86,12 @@ extern void __chk_io_ptr(void __iomem *)
>  # define __deprecated/* unimplemented */
>  #endif
>  
> +#ifdef MODULE
> +#define __deprecated_in_modules __deprecated
> +#else
> +#define __deprecated_in_modules /* OK in non-modular code */
> +#endif
> +
>...

Looks good.


One more question:

You get a false positive if the file containing the symbol is itself a 
module.

Is there any way to solve this without additional #define's and #ifdef's 
for each symbol?


cu
Adrian

-- 

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

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

Re: [PATCH] I2C patch 2 - break up the SMBus formatting

[Greg KH]

On Fri, Feb 25, 2005 at 04:46:35PM -0600, Corey Minyard wrote:
> Greg KH wrote:
> 
> >On Thu, Feb 24, 2005 at 05:27:25PM -0600, Corey Minyard wrote:
> > 
> >
> >>+
> >>+   /* It's wierd, but we use a usecount to track if an q entry is
> >>+  in use and when it should be reported back to the user. */
> >>+   atomic_t usecount;
> >>   
> >>
> >
> >Please use a kref here instead of rolling your own.
> > 
> >
> There's a trick I'm playing to avoid having to use a lock on the normal 
> entry_put() case.  It let's the entry_get() routine detect that the 
> object is about to be destroyed.  You can't do it with the current kref, 
> but you could easily extend kref to allow it.

No, kref is ment to have an external lock protect it from this kind of
race.  That's documented.

> It's simple to implement, but the documentation on how to use it will
> be 10 times larger than the code :).
> 
> I'll work on a patch to kref to add that, if you don't mind.

I'll always look at patches :)

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] Symlink /sys/class/block to /sys/block

[Greg KH]

On Fri, Feb 25, 2005 at 01:35:13AM +, Kay Sievers wrote:
> Greg KH  suse.de> writes:
> 
> > 
> > On Wed, Feb 23, 2005 at 09:43:35AM +, Malcolm Rowe wrote:
> > > Greg KH writes: 
> > > 
> > > >>Following the discussion in [1], the attached patch creates 
> > > >>/sys/class/block
> > > >>as a symlink to /sys/block. The patch applies to 2.6.11-rc4-bk7.  
> > > >>
> > > >>Please cc: me on any replies - I'm not subscribed to the mailing list. 
> > > >Hm, your patch is linewrapped, and can't be applied :(
> > > 
> > > Bah, and I did send it to myself first, but I guess my mailer un-flowed 
> > > it 
> > > for me .  I'll try to find a better mailer. 
> > > 
> > > >But more importantly:
> > > >>static void disk_release(struct kobject * kobj)
> > > >
> > > >Did you try to remove a disk (like a usb device) and see what happens
> > > >here?  Hint, this isn't the proper place to remove the symlink...
> > > 
> > > Er, yeah. Oops. 
> > > 
> > > *Is* there a sensible place to remove the symlink from, though?  Nobody 
> > > seems to call subsystem_unregister(&block_subsys), which is the place I'd 
> > > expect to add a call to, and I can't see anything that's otherwise 
> > > obvious... 
> > 
> > If the subsystem is never unregistered, then don't worry about undoing
> > the symlink.
> 
> This symlink will break a lot of applications out there. If there is not a
> _very_ good reason for it, we should not do that.

People seem to want it for some odd reason, I haven't seen a good reason
yet though, let alone a working patch :)

> The "dev" file unfortunately does not tell you if it's a char or block
> device node and that should be solved by something better than matching a
> magic string somewhere in the middle of a devpath.

Use the subsystem value.  If it's "block", it's a block device,
otherwise it's a char device.  Don't we already do this in udev today?

> The hotplug events will still have the /block/* devpath, so this symlink
> will give us nothing than problems.

It will not give hotplug programs issues, as the block devpath still
remains the same.

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: USB IDE Connector

[Greg KH]

On Fri, Feb 25, 2005 at 10:30:27AM +0530, Sumit Narayan wrote:
> Hi,
> 
> I have an external IDE connector through USB port. Where could I get
> the exact point inside the kernel, from where I would get information
> such as Block No., Request size, partition details for a particular
> request, _just_ before being sent to the disk.
> 
> Like, for a normal IDE, I could gather these details from inside the
> function __ide_do_rw_disk from "struct request". Is there anyway for
> finding out the same for a USB mass storage device?

Why would you want to know this information for a controller device that
acts like a scsi one, not an IDE one (that's what usb storage devices
do...)

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: ARM undefined symbols. Again.

[Linus Torvalds]

On Fri, 25 Feb 2005, Linus Torvalds wrote:
> 
> And one year of apparently "no progress" smells. Bad.

Side note: I don't actually remember how long it's been. Maybe it just 
feels a lot longer than it actually is.

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

Re: ARM undefined symbols. Again.

[Linus Torvalds]

On Fri, 25 Feb 2005, Russell King wrote:
> 
> That's fine until you consider the wide number of machines for ARM,
> any of which could have this problem.

Fair enough. "ARM" doesn't end up being just one architecture, and that's 
a good point.

> Unless of course, you believe that one person should carry everything,
> which is what I feel your above comment is effectively saying.

No, let me be the last to argue for centralized Q&A. Doesn't work. I'd
rather argue that it's not an issue of trying to get everybody to upgrade
and making old versions "not supported". It seems more benign than that,
in that it should be sufficient if there were just enough new versions out
there, for some arbitrary value of "enough".

In particular, it seems downright _wrong_ that an issue like this has been 
around forever, and nothing has actually been done about the fundamental 
problem. At some point, "kernel build bandages" are just not worth it any 
more, if people aren't even trying to actually fix the real issue.

And one year of apparently "no progress" smells. Bad.

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

[2.6 patch] drivers/char/mxser.c cleanups

[Adrian Bunk]

On Fri, Feb 25, 2005 at 10:43:14AM +0200, Denis Vlasenko wrote:
> On Friday 25 February 2005 01:38, Adrian Bunk wrote:
> >...
> > -unsigned int Gmoxa_uart_id[UART_TYPE_NUM] = {
> > +static unsigned int Gmoxa_uart_id[UART_TYPE_NUM] = {
> > MOXA_MUST_MU150_HWID,
> > MOXA_MUST_MU860_HWID
> >  };
> 
> You can add 'const' too.


Thanks for this suggestion.

Updated patch:


<--  snip  -->


This patch contains the following cleanups:
- make two needlessly global structs static const
- remove the unused global function SDS_PORT8_DTR

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

---

 drivers/char/mxser.c |   21 ++---
 1 files changed, 2 insertions(+), 19 deletions(-)

--- linux-2.6.11-rc2-mm2-full/drivers/char/mxser.c.old  2005-01-31 
13:20:44.0 +0100
+++ linux-2.6.11-rc2-mm2-full/drivers/char/mxser.c  2005-01-31 
13:22:07.0 +0100
@@ -179,7 +179,7 @@
 
 #define UART_TYPE_NUM  2
 
-unsigned int Gmoxa_uart_id[UART_TYPE_NUM] = {
+static const unsigned int Gmoxa_uart_id[UART_TYPE_NUM] = {
MOXA_MUST_MU150_HWID,
MOXA_MUST_MU860_HWID
 };
@@ -197,7 +197,7 @@
long max_baud;
 };
 
-struct mxpciuart_info Gpci_uart_info[UART_INFO_NUM] = {
+static const struct mxpciuart_info Gpci_uart_info[UART_INFO_NUM] = {
{MOXA_OTHER_UART, 16, 16, 16, 14, 14, 1, 921600L},
{MOXA_MUST_MU150_HWID, 64, 64, 64, 48, 48, 16, 230400L},
{MOXA_MUST_MU860_HWID, 128, 128, 128, 96, 96, 32, 921600L}
@@ -3174,22 +3174,5 @@
outb(0x00, port + 4);
 }
 
-// added by James 03-05-2004.
-// for secure device server:
-// stat = 1, the port8 DTR is set to ON.
-// stat = 0, the port8 DTR is set to OFF.
-void SDS_PORT8_DTR(int stat)
-{
-   int _sds_oldmcr;
-   _sds_oldmcr = inb(mxvar_table[7].base + UART_MCR);  // get old MCR
-   if (stat == 1) {
-   outb(_sds_oldmcr | 0x01, mxvar_table[7].base + UART_MCR);   
// set DTR ON
-   }
-   if (stat == 0) {
-   outb(_sds_oldmcr & 0xfe, mxvar_table[7].base + UART_MCR);   
// set DTR OFF
-   }
-   return;
-}
-
 module_init(mxser_module_init);
 module_exit(mxser_module_exit);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] I2C patch 2 - break up the SMBus formatting

[Corey Minyard]

Greg KH wrote:
On Thu, Feb 24, 2005 at 05:27:25PM -0600, Corey Minyard wrote:
 

+
+	/* It's wierd, but we use a usecount to track if an q entry is
+	   in use and when it should be reported back to the user. */
+	atomic_t usecount;
   

Please use a kref here instead of rolling your own.
 

There's a trick I'm playing to avoid having to use a lock on the normal 
entry_put() case.  It let's the entry_get() routine detect that the 
object is about to be destroyed.  You can't do it with the current kref, 
but you could easily extend kref to allow it.  It's simple to implement, 
but the documentation on how to use it will be 10 times larger than the 
code :).

I'll work on a patch to kref to add that, if you don't mind.
Oh, and can you cc: your patches to the sensors mailing list so the
other i2c developers are aware of them and can comment?  I'll stick with
just applying your first patch for now.
 

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

Re: init process and task_struct

[Robert Love]

On Fri, 2005-02-25 at 23:26 +0100, Josef E. Galea wrote:

> Does the init process have a task_struct associated with it, and if yes 
> where is this structure created?

Of course.

Stored directly in init_task, declared in , defined in
arch-specific code (arch/i386/kernel/init_task.c on x86).

Robert Love


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

Re: arch/xen is a bad idea

[Andrew Morton]

"Ian Pratt" <[EMAIL PROTECTED]> wrote:
>
>  
> > The Xen team still believe that it's best to keep arch/xen, 
> > arch/xen/i386,
> > arch/xen/x86_64, etc.  And I believe that Andi (who is the 
> > world expert on
> > maintaining an i386 derivative) thinks that this is will be a 
> > long-term
> > maintenance problem.
> 
> I think there's an interim compromise position that everyone might go
> for:
> 
> Phase 1 is for us to submit a load of patches that squeeze out the low
> hanging fruit in unifying xen/i386 and i386. Most of these will be
> strict cleanups to i386, and the result will be to almost halve the
> number of files that we need to modify.

OK.  It would be good to have a phase 0: any refactoring, abstracting, etc
to the core kernel and to i386 which is a preparatory step, prior to
introducing any Xen code.  After phase 0 everything should still compile
and run.  The subsequent Xen patches should merely add stuff and not move
existing code around.

> The next phase is that we re-organise the current arch/xen as follows:
> 
> We move the remaining (reduced) contents of arch/xen/i386 to
> arch/i386/xen (ditto for x86_64). We then move the xen-specific files
> that are shared between all the different xen architectures to
> drivers/xen/core. I know this last step is a bit odd, but it's the best
> location that Rusty Russel and I could come up with.
> 
> At this point, I'd hope that we could get xen into the main-line tree.

What would you propose doing with the i386 header files?  Such as the
pagetable handling?

> The final phase is to see if we can further unify more native and xen
> files. This is going to require some significant i386 code refactoring,
> and I think its going to be much easier to do if all the code is in the
> main-line tree so that people can see the motivation for what's going
> on.
> 
> What do you think?

It sounds decent.  The main objective is to minimise code duplication.  The
question of where in the tree all the resulting code actually lands is
secondary from a maintainability POV.

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

Re: [2.6 patch] better CRYPTO_AES <-> CRYPTO_AES_586 dependencies

[Adrian Bunk]

On Fri, Feb 25, 2005 at 04:08:07PM -0600, Chris Friesen wrote:
> Adrian Bunk wrote:
> 
> >--- linux-2.6.11-rc4-mm1-full/crypto/Kconfig.old 2005-02-25 
> >22:26:20.0 +0100
> >+++ linux-2.6.11-rc4-mm1-full/crypto/Kconfig 2005-02-25 
> >22:28:44.0 +0100
> >@@ -133,7 +133,9 @@
> > 
> > config CRYPTO_AES
> > tristate "AES cipher algorithms"
> >-depends on CRYPTO && !(X86 && !X86_64)
> >+depends on CRYPTO
> >+select CRYPTO_AES_GENERIC if !(X86 && !X86_64)
> >+select CRYPTO_AES_586 if (X86 && !X86_64)
> 
> Wouldn't the 586 one also work on x86_64?

I'd assume yes.

But the CRYPTO_AES_586 were already this way, and since I don't know the 
history of these dependencies this isn't changed by my patch.

> Chris

cu
Adrian

-- 

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

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

Re: [PATCH] allow vma merging with mlock et. al.

[Darren Hart]

Chris Wright wrote:
* Chris Wright ([EMAIL PROTECTED]) wrote:
* Darren Hart ([EMAIL PROTECTED]) wrote:
The were a couple long standing (since at least 2.4.21) superfluous 
variables and two unnecessary assignments in do_mlock().  The intent of 
the resulting code is also more obvious.

Tested on a 4 way x86 box running a simple mlock test program.  No 
problems detected.
Did you test with multiple page ranges, and locking subsets of vmas?
Seems that splitting could cause a problem since you now sample vm_end
before and after fixup, where the vma could be changed in the middle.

Actually I think it winds up being fine since we don't do merging with
mlock.  But why not?  Patch below remedies that.
We don't merge, but we do split if necessary, so the temp variables are 
still needed.  As I understand it, the reason we don't merge is because 
it is expected that a task will lock and unlock the same memory range 
more than once and we don't want to waste our time merging and splitting 
the VMAs.

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

init process and task_struct

[Josef E. Galea]

Hi,
Does the init process have a task_struct associated with it, and if yes 
where is this structure created?

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

Re: ALPS touchpad not seen by 2.6.11 kernels

[Johan Braennlund]

--- Dmitry Torokhov wrote:

> Does i8042 detect presence of an AUX port (check dmesg)? 

No.

> If not try booting with i8042.noacpi kernel boot option.

Yes, that helped - everything's working now. Thank you.

- Johan


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

Re: [PATCH] vm: mlock superfluous variable

[Darren Hart]

Chris Wright wrote:
* Darren Hart ([EMAIL PROTECTED]) wrote:
The were a couple long standing (since at least 2.4.21) superfluous 
variables and two unnecessary assignments in do_mlock().  The intent of 
the resulting code is also more obvious.

Tested on a 4 way x86 box running a simple mlock test program.  No 
problems detected.

Did you test with multiple page ranges, and locking subsets of vmas?
Seems that splitting could cause a problem since you now sample vm_end
before and after fixup, where the vma could be changed in the middle.
Thanks for catching that Chris.  Both the tmp variable and the next 
variable are indeed needed since mlock_fixup could modify both.  Please 
disregard this patch.

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

Re: [Lse-tech] Re: A common layer for Accounting packages

[Jay Lan]

Andrew Morton wrote:
Jay Lan <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
> Kaigai Kohei <[EMAIL PROTECTED]> wrote:
> 
>>In my understanding, what Andrew Morton said is "If target functionality can
>> implement in user space only, then we should not modify the kernel-tree".
> 
> 
> fork, exec and exit upcalls sound pretty good to me.  As long as
> 
> a) they use the same common machinery and
> 
> b) they are next-to-zero cost if something is listening on the netlink
>socket but no accounting daemon is running.
> 
> Question is: is this sufficient for CSA?

Yes, fork, exec, and exit upcalls are sufficient for CSA.
The framework i proposed earlier should satisfy your requirement a
and b, and provides upcalls needed by BSD, ELSA and CSA. Maybe i
misunderstood your concern of the 'very light weight' framework
i proposed besides being "overkill"?

"upcall" is poorly defined.
What I meant was that ELSA can perform its function when the kernel merely
sends asynchronous notifications of forks out to userspace via netlink.
Further, I'm wondering if CSA can perform its function with the same level
of kernel support, perhaps with the addition of netlink-based notification
of exec and exit as well.
The framework patch which you sent was designed to permit the addition of
more kernel accounting code, which is heading in the opposite direction.
In other words: given that ELSA can do its thing via existing accounting
interfaces and a fork notifier, why does CSA need to add lots more kernel
code?
Here are some codes from do_exit() starting line 813 (based on
2.6.11-rc4-mm1):
813acct_update_integrals(tsk);
814update_mem_hiwater(tsk);
815group_dead = atomic_dec_and_test(&tsk->signal->live);
816if (group_dead) {
817del_timer_sync(&tsk->signal->real_timer);
818acct_process(code);
819}
820exit_mm(tsk);
The acct_process() is called to save off BSD accounting data at
line 818. The next statement at 820, tsk->mm is disposed and all
data saved at tsk->mm is gone, including memory hiwater marks
information saved at line 814. The complete tsk is disposed
before exit of do_exit() routine.
In separate emails discussion thread among interested parties,
i asked Guillaume to clarify this question. I suspect ELSA counts
on BSD's acct_process() at line 818 to save most accounting data.
If that is the case and since ELSA wants extended accounting data
collection, a way to save the extended acct data would be essential
to ELSA as well.
I can better asnwer your "why ELSA can do but CSA can't" question
after i learn more from Guilluame.
Later,
 - jay
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Lse-tech mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/lse-tech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] better CRYPTO_AES <-> CRYPTO_AES_586 dependencies

[Chris Friesen]

Adrian Bunk wrote:
--- linux-2.6.11-rc4-mm1-full/crypto/Kconfig.old	2005-02-25 22:26:20.0 +0100
+++ linux-2.6.11-rc4-mm1-full/crypto/Kconfig	2005-02-25 22:28:44.0 +0100
@@ -133,7 +133,9 @@
 
 config CRYPTO_AES
 	tristate "AES cipher algorithms"
-	depends on CRYPTO && !(X86 && !X86_64)
+	depends on CRYPTO
+	select CRYPTO_AES_GENERIC if !(X86 && !X86_64)
+	select CRYPTO_AES_586 if (X86 && !X86_64)
Wouldn't the 586 one also work on x86_64?
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] allow vma merging with mlock et. al.

[Chris Wright]

* Chris Wright ([EMAIL PROTECTED]) wrote:
> * Darren Hart ([EMAIL PROTECTED]) wrote:
> > The were a couple long standing (since at least 2.4.21) superfluous 
> > variables and two unnecessary assignments in do_mlock().  The intent of 
> > the resulting code is also more obvious.
> > 
> > Tested on a 4 way x86 box running a simple mlock test program.  No 
> > problems detected.
> 
> Did you test with multiple page ranges, and locking subsets of vmas?
> Seems that splitting could cause a problem since you now sample vm_end
> before and after fixup, where the vma could be changed in the middle.

Actually I think it winds up being fine since we don't do merging with
mlock.  But why not?  Patch below remedies that.

thanks,
-chris
--

Successive mlock/munlock calls can leave fragmented vmas because they can
be split but not merged.  Give mlock et. al. full vma merging support.

Signed-off-by: Chris Wright <[EMAIL PROTECTED]>

= mm/mlock.c 1.19 vs edited =
--- 1.19/mm/mlock.c 2005-02-11 11:07:35 -08:00
+++ edited/mm/mlock.c   2005-02-24 23:53:10 -08:00
@@ -7,18 +7,32 @@
 
 #include 
 #include 
+#include 
 #include 
 
 
-static int mlock_fixup(struct vm_area_struct * vma, 
+static int mlock_fixup(struct vm_area_struct *vma, struct vm_area_struct 
**prev,
unsigned long start, unsigned long end, unsigned int newflags)
 {
struct mm_struct * mm = vma->vm_mm;
+   pgoff_t pgoff;
int pages;
int ret = 0;
 
-   if (newflags == vma->vm_flags)
+   if (newflags == vma->vm_flags) {
+   *prev = vma;
goto out;
+   }
+
+   pgoff = vma->vm_pgoff + ((start - vma->vm_start) >> PAGE_SHIFT);
+   *prev = vma_merge(mm, *prev, start, end, newflags, vma->anon_vma,
+ vma->vm_file, pgoff, vma_policy(vma));
+   if (*prev) {
+   vma = *prev;
+   goto success;
+   }
+
+   *prev = vma;
 
if (start != vma->vm_start) {
ret = split_vma(mm, vma, start, 1);
@@ -32,6 +46,7 @@ static int mlock_fixup(struct vm_area_st
goto out;
}
 
+success:
/*
 * vm_flags is protected by the mmap_sem held in write mode.
 * It's okay if try_to_unmap_one unmaps a page just after we
@@ -59,7 +74,7 @@ out:
 static int do_mlock(unsigned long start, size_t len, int on)
 {
unsigned long nstart, end, tmp;
-   struct vm_area_struct * vma, * next;
+   struct vm_area_struct * vma, * prev;
int error;
 
len = PAGE_ALIGN(len);
@@ -68,7 +83,7 @@ static int do_mlock(unsigned long start,
return -EINVAL;
if (end == start)
return 0;
-   vma = find_vma(current->mm, start);
+   vma = find_vma_prev(current->mm, start, &prev);
if (!vma || vma->vm_start > start)
return -ENOMEM;
 
@@ -81,18 +96,19 @@ static int do_mlock(unsigned long start,
if (!on)
newflags &= ~VM_LOCKED;
 
-   if (vma->vm_end >= end) {
-   error = mlock_fixup(vma, nstart, end, newflags);
-   break;
-   }
-
tmp = vma->vm_end;
-   next = vma->vm_next;
-   error = mlock_fixup(vma, nstart, tmp, newflags);
+   if (tmp > end)
+   tmp = end;
+   error = mlock_fixup(vma, &prev, nstart, tmp, newflags);
if (error)
break;
nstart = tmp;
-   vma = next;
+   if (nstart < prev->vm_end)
+   nstart = prev->vm_end;
+   if (nstart >= end)
+   break;
+
+   vma = prev->vm_next;
if (!vma || vma->vm_start != nstart) {
error = -ENOMEM;
break;
@@ -141,7 +157,7 @@ asmlinkage long sys_munlock(unsigned lon
 
 static int do_mlockall(int flags)
 {
-   struct vm_area_struct * vma;
+   struct vm_area_struct * vma, * prev;
unsigned int def_flags = 0;
 
if (flags & MCL_FUTURE)
@@ -150,7 +166,7 @@ static int do_mlockall(int flags)
if (flags == MCL_FUTURE)
goto out;
 
-   for (vma = current->mm->mmap; vma ; vma = vma->vm_next) {
+   for (prev = vma = current->mm->mmap; vma ; vma = vma->vm_next) {
unsigned int newflags;
 
newflags = vma->vm_flags | VM_LOCKED;
@@ -158,7 +174,8 @@ static int do_mlockall(int flags)
newflags &= ~VM_LOCKED;
 
/* Ignore errors */
-   mlock_fixup(vma, vma->vm_start, vma->vm_end, newflags);
+   mlock_fixup(vma, &prev, vma->vm_start, vma->vm_end, newflags);
+   vma = prev;
}
 out:
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

Re: ARM undefined symbols. Again.

[Daniel Jacobowitz]

On Fri, Feb 25, 2005 at 08:23:49PM +, Russell King wrote:
> On Fri, Feb 25, 2005 at 11:59:01AM -0800, Linus Torvalds wrote:
> > On Fri, 25 Feb 2005, Russell King wrote:
> > > So, what's happening about this?
> > 
> > Btw, is there any real reason why the ARM _tools_ can't just be fixed? I 
> > don't see why this isn't a tools bug?
> 
> It is a tools bug.  But the issue is that *all* versions of binutils
> currently available which are kernel-capable (since the inclusion of
> the kbuild .incbin requirement on binutils) have this bug, with the
> exception of maybe CVS versions.
> 
> We can't say "you must use the current CVS binutils to build the
> kernel" because that's not a sane toolchain base to build products
> on.
> 
> I've been wanting to see a version of binutils released pretty damn
> quick so I can say "kernel only builds with latest toolchain" but
> I suspect even that's going to be seen as being unreasonable.

Not sure who you asked, but since I run the binutils releases...

I am fairly positive that this bug has been fixed in the binutils CVS:

2004-07-02  Nick Clifton  <[EMAIL PROTECTED]>

* config/tc-arm.c (md_apply_fix3:BFD_RELOC_ARM_IMMEDIATE): Do not
allow values which have come from undefined symbols.
Always consider this fixup to have been processed as a reloc
cannot be generated for it.

I know several ARM kernel developers who are using tools with this
patch applied already.  Also, I anticipate the release of binutils 2.16
including the fix in about a month.

> And yes, the toolchain peoples point of view is "fix the kernel".

Huh?  Obviously the kernel isn't broken, unless you're talking about
the kallsyms checks now.

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

Re: [2.6 patch] better CRYPTO_AES <-> CRYPTO_AES_586 dependencies

[James Morris]

On Fri, 25 Feb 2005, Adrian Bunk wrote:

> 2.6.11-rc4-mm1 contains an option (IEEE80211_CRYPT_CCMP) that selects 
> CRYPTO_AES - but this is currently wrong on i386.
> 
> This patch changes CRYPTO_AES to being the only user-visible options and 
> selecting either CRYPTO_AES_586 or a new CRYPTO_AES_GENERIC option 
> depending on the platform.

Good thinking, didn't think to chain selects.

> BTW: Does CRYPTO_AES_586 work on an 386 or 486?

>From memory it is generic i386 asm optimize for P5.


- James
-- 
James Morris
<[EMAIL PROTECTED]>


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

Re: [2.6 patch] unexport do_settimeofday

[Andrew Morton]

Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> On Thu, Feb 24, 2005 at 09:24:48PM -0800, Andrew Morton wrote:
> > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >
> > > 
> > >  I haven't found any possible modular usage of do_settimeofday in the 
> > >  kernel.
> > 
> > Please,
> > 
> > - Add deprecated_if_module
> >...
> 
> What's the correct header file for __deprecated_if_module ?

Actually, __deprecated_in_modules would be a better name.

> module.h ?

compiler.h, I guess.

--- 25/include/linux/compiler.h~a   2005-02-25 13:53:32.0 -0800
+++ 25-akpm/include/linux/compiler.h2005-02-25 13:54:45.0 -0800
@@ -86,6 +86,12 @@ extern void __chk_io_ptr(void __iomem *)
 # define __deprecated  /* unimplemented */
 #endif
 
+#ifdef MODULE
+#define __deprecated_in_modules __deprecated
+#else
+#define __deprecated_in_modules /* OK in non-modular code */
+#endif
+
 #ifndef __must_check
 #define __must_check
 #endif
_


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

Re: 2.6.11-rc5

[Lee Revell]

On Fri, 2005-02-25 at 16:47 -0500, Bill Davidsen wrote:
> - sound: hasn't worked since FC1...
> 

The ALSA lists have been deluged with reports like "sound worked in FC1,
upgraded to FC3, no sound".   AFAICT it's just sloppiness on the part of
the Fedora userspace tools.  For example, last I heard
system-config-soundcard tries to load the emu10k1 module for cards that
need the (completely different) emu10k1x driver.

Lee

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

Re: [PATCH] I2C patch 2 - break up the SMBus formatting

[Greg KH]

On Thu, Feb 24, 2005 at 05:27:25PM -0600, Corey Minyard wrote:
> This is one in a series of patches for adding a non-blocking interface 
> to the I2C driver for supporting the IPMI SMBus driver.

> This patch reorganizes the formatting code to  make it more
> suitable for the upcoming non-blocking changes.  It also adds
> an op queue entry that is used to pass data around (for now)
> and will be used for queueing in the non-blocking case.

Hm, ick.  Can you break this up into 2 pieces?  One that reorders the
formatting of the code, and then one that adds the new functionality?
Otherwise it's very hard to follow the changes that are happening in
here.

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] I2C patch 1 - minor I2C cleanups

[Greg KH]

On Thu, Feb 24, 2005 at 05:25:22PM -0600, Corey Minyard wrote:
> This is one in a series of patches for adding a non-blocking interface 
> to the I2C driver for supporting the IPMI SMBus driver.  This patch is a 
> simply some minor cleanups and is in addition to the patch by Mickey 
> Stein (http://marc.theaimsgroup.com/?l=linux-kernel&m=110919738708916&w=2).

> Clean up some general I2C things.  Fix some grammar and put ()
> around all the #defines that are compound to avoid nasty
> side-effects.
> 
> Signed-off-by: Corey Minyard <[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/

[2.6 patch] better CRYPTO_AES <-> CRYPTO_AES_586 dependencies

[Adrian Bunk]

2.6.11-rc4-mm1 contains an option (IEEE80211_CRYPT_CCMP) that selects 
CRYPTO_AES - but this is currently wrong on i386.

This patch changes CRYPTO_AES to being the only user-visible options and 
selecting either CRYPTO_AES_586 or a new CRYPTO_AES_GENERIC option 
depending on the platform.

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

---

BTW: Does CRYPTO_AES_586 work on an 386 or 486?

 crypto/Kconfig  |   26 +++---
 crypto/Makefile |2 +-
 2 files changed, 8 insertions(+), 20 deletions(-)

--- linux-2.6.11-rc4-mm1-full/crypto/Kconfig.old2005-02-25 
22:26:20.0 +0100
+++ linux-2.6.11-rc4-mm1-full/crypto/Kconfig2005-02-25 22:28:44.0 
+0100
@@ -133,7 +133,9 @@
 
 config CRYPTO_AES
tristate "AES cipher algorithms"
-   depends on CRYPTO && !(X86 && !X86_64)
+   depends on CRYPTO
+   select CRYPTO_AES_GENERIC if !(X86 && !X86_64)
+   select CRYPTO_AES_586 if (X86 && !X86_64)
help
  AES cipher algorithms (FIPS-197). AES uses the Rijndael 
  algorithm.
@@ -151,25 +153,11 @@
 
  See  for more information.
 
-config CRYPTO_AES_586
-   tristate "AES cipher algorithms (i586)"
-   depends on CRYPTO && (X86 && !X86_64)
-   help
- AES cipher algorithms (FIPS-197). AES uses the Rijndael 
- algorithm.
+config CRYPTO_AES_GENERIC
+   tristate
 
- Rijndael appears to be consistently a very good performer in
- both hardware and software across a wide range of computing 
- environments regardless of its use in feedback or non-feedback 
- modes. Its key setup time is excellent, and its key agility is 
- good. Rijndael's very low memory requirements make it very well 
- suited for restricted-space environments, in which it also 
- demonstrates excellent performance. Rijndael's operations are 
- among the easiest to defend against power and timing attacks. 
-
- The AES specifies three key sizes: 128, 192 and 256 bits
-
- See  for more information.
+config CRYPTO_AES_586
+   tristate
 
 config CRYPTO_CAST5
tristate "CAST5 (CAST-128) cipher algorithm"
--- linux-2.6.11-rc4-mm1-full/crypto/Makefile.old   2005-02-25 
22:29:33.0 +0100
+++ linux-2.6.11-rc4-mm1-full/crypto/Makefile   2005-02-25 22:29:42.0 
+0100
@@ -19,7 +19,7 @@
 obj-$(CONFIG_CRYPTO_BLOWFISH) += blowfish.o
 obj-$(CONFIG_CRYPTO_TWOFISH) += twofish.o
 obj-$(CONFIG_CRYPTO_SERPENT) += serpent.o
-obj-$(CONFIG_CRYPTO_AES) += aes.o
+obj-$(CONFIG_CRYPTO_AES_GENERIC) += aes.o
 obj-$(CONFIG_CRYPTO_CAST5) += cast5.o
 obj-$(CONFIG_CRYPTO_CAST6) += cast6.o
 obj-$(CONFIG_CRYPTO_ARC4) += arc4.o


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

Re: ALPS touchpad not seen by 2.6.11 kernels

[Dmitry Torokhov]

On Fri, 25 Feb 2005 13:33:36 -0800 (PST), Johan Braennlund
<[EMAIL PROTECTED]> wrote:
> Hi. I've had trouble with my ALPS touchpad on my Acer Aspire, ever
> since ALPS support was merged into the kernel. I've tried various
> kernels from 2.6.11-rc3 to -rc5 (including some -mm kernels) and none
> of them detect the pad. After sprinkling some printk's in the mouse
> drivers, it seems like psmouse_connect in psmouse-base.c is never even
> called.
> 
> On the other hand, using earlier kernels (such as 2.6.9) with the
> kernel patch from Peter Osterlund's driver package works fine. In that
> case, I get lines like this in syslog:
> 
> kernel: alps.c: E6 report: 00 00 64
> kernel: alps.c: E7 report: 73 02 14
> kernel: alps.c: E6 report: 00 00 64
> kernel: alps.c: E7 report: 73 02 14
> kernel: alps.c: Status: 15 01 0a
> kernel: ALPS Touchpad (Glidepoint) detected
> kernel: input: AlpsPS/2 ALPS TouchPad on isa0060/serio4
> 
> With the newer kernels, there's nothing ALPS-related in the log. Any
> pointers on what to look for would be appreciated. My kernel config is
> at http://nullinfinity.org/config-2.6.11-rc5
> 

Hi,

Does i8042 detect presence of an AUX port (check dmesg)? If not try
booting with i8042.noacpi kernel boot option.

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

Re: [PATCH] I2C patch 2 - break up the SMBus formatting

[Greg KH]

On Thu, Feb 24, 2005 at 05:27:25PM -0600, Corey Minyard wrote:
> +/*
> + * Hold a queue of I2C operations to perform, and used to pass data
> + * around.
> + */
> +typedef void (*i2c_op_done_cb)(struct i2c_op_q_entry *entry);
> +
> +#define I2C_OP_I2C   0
> +#define I2C_OP_SMBUS 1
> +struct i2c_op_q_entry {
> + /* The result will be set to the result of the operation when
> +it completes. */
> + s32 result;
> +
> + /**/
> + /* Public interface.  The user should set these up (and the
> +proper structure below). */
> + intxfer_type;
> +
> + /* Handler may be called from interrupt context, so be
> +careful. */
> + i2c_op_done_cb handler;
> + void   *handler_data;
> +
> + /* Note that this is not a union because an smbus operation
> +may be converted into an i2c operation (thus both
> +structures will be used).  The data in these may be changd
> +by the driver. */
> + struct {
> + struct i2c_msg *msgs;
> + int num;
> + } i2c;
> + struct {
> + /* Addr and flags are filled in by the non-blocking
> +send routine that takes a client. */
> + u16 addr;
> + unsigned short flags;
> +
> + char read_write;
> + u8 command;
> +
> + /* Note that the size is *not* the length of the data.
> +It is the transaction type, like I2C_SMBUS_QUICK
> +and the ones after that below.  If this is a block
> +transaction, the length of the rest of the data is
> +in the first byte of the data, for both transmit
> +and receive. */
> + int size;
> + union i2c_smbus_data *data;
> + } smbus;
> +
> + /**/
> + /* For use by the bus interface.  The bus interface sets the
> +timeout in microseconds until the next poll operation.
> +This *must* be set in the start operation.  The time_left
> +and data can be used for anything the bus interface likes.
> +data will be set to NULL before being started so the bus
> +interface can use that to tell if it has been set up
> +yet. */
> + unsigned int call_again_us;
> + long time_left;
> + void *data;
> +
> + /**/
> + /* Internals */
> + struct list_head  link;
> + struct completion *start;
> + atomic_t  completed;
> + unsigned int  started : 1;
> + unsigned int  use_timer : 1;
> + u8swpec;
> + u8partial;
> + void (*complete)(struct i2c_adapter*adap,
> +  struct i2c_op_q_entry *entry);
> +
> + /* It's wierd, but we use a usecount to track if an q entry is
> +in use and when it should be reported back to the user. */
> + atomic_t usecount;

Please use a kref here instead of rolling your own.

Oh, and can you cc: your patches to the sensors mailing list so the
other i2c developers are aware of them and can comment?  I'll stick with
just applying your first patch for now.

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 patch] unexport do_settimeofday

[Adrian Bunk]

On Thu, Feb 24, 2005 at 09:24:48PM -0800, Andrew Morton wrote:
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > 
> >  I haven't found any possible modular usage of do_settimeofday in the 
> >  kernel.
> 
> Please,
> 
> - Add deprecated_if_module
>...

What's the correct header file for __deprecated_if_module ?
module.h ?

cu
Adrian

-- 

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

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

Re: 2.6.11-rc5

[Bill Davidsen]

Linus Torvalds wrote:
Hey, I hoped -rc4 was the last one, but we had some laptop resource
conflicts, various ppc TLB flush issues, some possible stack overflows in
networking and a number of other details warranting a quick -rc5 before
the final 2.6.11.
This time it's really supposed to be a quickie, so people who can, please 
check it out, and we'll make the real 2.6.11 asap.

Mostly pretty small changes (the largest is a new SATA driver that crept
in, our bad). But worth another quick round.
Three bugs down, one to go...
- backlight poweroff from screensaver: WORKING
- power off on shutdown: RELIABLE
- detection of the DVD drive without a disk in it at boot: WORKING
- sound: hasn't worked since FC1...
ASUS 1681 Pentium-M, 512MB, 80GB, 1400x1050 screen
FC1 worked, clean install FC2 had display issues, upgrade to FC3 doesn't 
use full screen size and sound is totally NFG. I'm going to drop back to 
oss over the weekend and see if that helps.

If anyone cares, the relevant lspci, dmesg, lsmod, etc, etc, are at
  //216.238.38.194/nosound
and it will be up unless some development breaks it. I have posted this 
elsewhere, could see attaching all the cruft to a message for the whole 
list.

--
   -bill davidsen ([EMAIL PROTECTED])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 ide-dev 3/9] merge LBA28 and LBA48 Host Protected Area support code

[Greg Freemyer]

Retested with Hitachi drive and 2.6.10 vanilla kernel.

Same behavior, HPA is not reset to native max.

Greg
-- 
Greg Freemyer

On Thu, 24 Feb 2005 15:19:52 -0500, Greg Freemyer
<[EMAIL PROTECTED]> wrote:
> On Thu, 24 Feb 2005 17:30:55 +0100, Bartlomiej Zolnierkiewicz
> <[EMAIL PROTECTED]> wrote:
> > On Thursday 24 February 2005 17:10, Greg Freemyer wrote:
> > > I have generic question about HPA, not the patch.
> > >
> > > I have noticed with a SUSE 2.6.8 vendor kernel, the HPA behavior is
> > > not consistent.
> >
> > Please retry with vanilla kernel.
> >
> Will do.  I assume 2.6.10 is fine?
> 
> > > ie. With exactly the same computer/controller, but with different disk
> > > drives (models/manufacturers) the HPA behavior varies.
> > >
> > > In all my testing the HPA was always properly detected, but sometimes
> > > the max_address is set to the native_max_address during bootup and
> > > sometimes it is not.
> >
> > Please be more precise.
> >
> > What do you mean by 'sometimes'?
> >
> Seems to be disk drive specific.
> 
> For instance my records show that for a:
>  Maxtor model 32049h2
>  20 GB
>  Manufactured Mar. 2001
> drive I was working with last week the maximum available capacity was
> set to the native max.  At power on the max. avail. was slightly
> smaller than native max.
> 
> With exactly the same computer I just tested a HPA test drive of mine:
>  Hitachi Deskstar
>  model HDS728080PLAT20
>  82.3 GB (per label)
>  Manufactured Oct. 2004
> and the max. avail. was not reset.  From boot.msg
> 
> <6>hdc: max request size: 1024KiB
> <6>hdc: Host Protected Area detected.
> <4> current capacity is 50001 sectors (25 MB)
> <4> native  capacity is 160836480 sectors (82348 MB)
> <4>hdc: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> <4>hdc: task_no_data_intr: error=0x04 { DriveStatusError }
> <4>ide: failed opcode was: 0x37
> <6>hdc: 50001 sectors (25 MB) w/1719KiB Cache, CHS=49/255/63, UDMA(100)
> <7>hdc: cache flushes supported
> <6> hdc: hdc1
> 
> Looking in /proc/ide/hdc/capacity after boot I show 50001 sectors.
> 
> Note this is still with the SUSE 2.6.8 vendor kernel and I don't know
> what the Drive errors are, but they seem to be a driver issue, not a
> hardware issue.  Concievably they are related to the behavior, but I
> don't know.
> 
> > What are the exact differences between machines?
> >
> Same machine / OS, just connecting different drives.  By chance, the
> machine had been powered off between the 2 tests.  (It is a portable
> machine that is normally locked away when not in use.)
> 
> > Are there any differences in software configurations
> > (i.e. kernel parameters) between this machines?
> >
> no
> 
> > > Is there some reason for this behavior or is one case or the other a bug?
> >
> > Dunno, not enough info.
> >
> > > Does this patch somehow address the inconsistency?
> >
> > No.
> >
> > > Am I right in assuming this behavior also exists in the vanilla
> > > kernels?.  ie. I doubt that vendors are patching this behavior.
> >
> > Recent vanilla kernels always set maximum available capacity.
> >
> Was 2.6.8 recent enough to have this behavior?
> 
> Greg
> --
> Greg Freemyer
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ALPS touchpad not seen by 2.6.11 kernels

[Johan Braennlund]

Hi. I've had trouble with my ALPS touchpad on my Acer Aspire, ever
since ALPS support was merged into the kernel. I've tried various
kernels from 2.6.11-rc3 to -rc5 (including some -mm kernels) and none
of them detect the pad. After sprinkling some printk's in the mouse
drivers, it seems like psmouse_connect in psmouse-base.c is never even
called. 

On the other hand, using earlier kernels (such as 2.6.9) with the
kernel patch from Peter Osterlund's driver package works fine. In that
case, I get lines like this in syslog:

kernel: alps.c: E6 report: 00 00 64
kernel: alps.c: E7 report: 73 02 14
kernel: alps.c: E6 report: 00 00 64
kernel: alps.c: E7 report: 73 02 14
kernel: alps.c: Status: 15 01 0a
kernel: ALPS Touchpad (Glidepoint) detected
kernel: input: AlpsPS/2 ALPS TouchPad on isa0060/serio4

With the newer kernels, there's nothing ALPS-related in the log. Any
pointers on what to look for would be appreciated. My kernel config is
at http://nullinfinity.org/config-2.6.11-rc5

Thanks,

Johan




__ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Lse-tech] Re: A common layer for Accounting packages

[Andrew Morton]

Jay Lan <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
>  > Kaigai Kohei <[EMAIL PROTECTED]> wrote:
>  > 
>  >>In my understanding, what Andrew Morton said is "If target functionality 
> can
>  >> implement in user space only, then we should not modify the kernel-tree".
>  > 
>  > 
>  > fork, exec and exit upcalls sound pretty good to me.  As long as
>  > 
>  > a) they use the same common machinery and
>  > 
>  > b) they are next-to-zero cost if something is listening on the netlink
>  >socket but no accounting daemon is running.
>  > 
>  > Question is: is this sufficient for CSA?
> 
>  Yes, fork, exec, and exit upcalls are sufficient for CSA.
> 
>  The framework i proposed earlier should satisfy your requirement a
>  and b, and provides upcalls needed by BSD, ELSA and CSA. Maybe i
>  misunderstood your concern of the 'very light weight' framework
>  i proposed besides being "overkill"?

"upcall" is poorly defined.

What I meant was that ELSA can perform its function when the kernel merely
sends asynchronous notifications of forks out to userspace via netlink.

Further, I'm wondering if CSA can perform its function with the same level
of kernel support, perhaps with the addition of netlink-based notification
of exec and exit as well.

The framework patch which you sent was designed to permit the addition of
more kernel accounting code, which is heading in the opposite direction.

In other words: given that ELSA can do its thing via existing accounting
interfaces and a fork notifier, why does CSA need to add lots more kernel
code?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-fbdev-devel] Re: 2.6.11-rc5

[Olaf Hering]

 On Fri, Feb 25, Olaf Hering wrote:

>  On Fri, Feb 25, James Simmons wrote:
> 
> > 
> > > cfb_imageblit(320) dst1 fa51a800 base e0b8 bitstart 1999a800
> > > fast_imageblit(237) s daea4000 dst1 fa51a800
> > > fast_imageblit(269) j 1 fa51a800 0
> > > Unable to handle kernel paging request at virtual address fa51a800
> > > 
> > > is bitstart incorrect or is the thing just not (yet) mapped?
> > 
> > Looks like the screen_base is not mapped to.
> 
> rc3 worked ok, rc4 does not. testing the -bk snapshots now.

bk8 works, bk9 breaks, it contains the radeonfb update.
it works ok if the driver is compiled into the kernel.


config-radeonfb-i386.gz
Description: application/gunzip

Re: ARM undefined symbols. Again.

[Paulo Marques]

Sam Ravnborg wrote:
On Fri, Feb 25, 2005 at 08:54:56PM +, Paulo Marques wrote:
The patch (against 2.6.11-rc5) is attached, should you decide to use it.
How does the patch help rmk with respect to the tools issue?
From the thread I gathered that the problem Russell King was having was 
caused by the fact that kallsyms used "weak" symbols.

He proposed a solution where he created an empty assembly file with just 
the symbols defined to make the symbols exist already on the first pass. 
This way they wouldn't have to be defined as weak anymore.

His patch created the assembly file using "echo's" from the Makefile. I 
just suggested that it would be better to do it from scripts/kallsyms.c 
directly, so that it would be easier to maintain in case new symbols 
need to be added in the future.

That's what this patch does.
By the way, I'm not really sure about my changes to the Makefile, 
although they comply with Linus Confidence Level 3(*). I think you're 
the one with the best understanding on the kbuild process to comment on 
them.

--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
(*) It works
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] seccomp: don't say it was more or less mandatory

[Adrian Bunk]

On Thu, Feb 24, 2005 at 11:41:34PM +0100, Andrea Arcangeli wrote:

> Hello Adrian,

Hi Andrea,

> On Thu, Feb 24, 2005 at 10:51:36PM +0100, Adrian Bunk wrote:
> > seccomp might be a nice feature under some circumstances.
> > But the suggestion in the help text is IMHO too strong and therefore 
> > removed by this patch.
> 
> Why too strong? The reason there is a config option is for the embedded
> space, where clearly they want to compile into the kernel only the
> strict features they use.
> 
> There are no risks in enabling seccomp and the size of the kernel image
> won't change in any significant way either.
> 
> So I'd prefer to keep the "If unsure, say Y." and it seems appropriate
> to me.
> 
> You have to say Y, if later on you want to sell your CPU resources with
> Cpushare.  BTW, you can already test it if you download version 0.8 of
> the LGPL'd Cpushare software, it'll connect to the server and it'll
> execute a remote seccomp computation and then it'll hang around until
> you stop it with ./stop_cpushare.sh (and you will see your client
> connected in the homepage stats). I didn't finish writing all the code
> yet but it's already a decent demo for the seccomp part at least.
>...

this sounds more like an "If unsure, say N.":
You don't need this feature unless you know you need it.

It's not about risk or the actual size of the code - there are many 
small or big features in the kernel that might be useful under some 
circumstances, but even the IPv6 help text still suggests to say N
to IPv6.

cu
Adrian

-- 

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

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

M$ gets into autos!

[linux-os]

Sorry officer. I had to reboot!
Microsoft collaborates with Samsung, ScanSoft, Siemens, SiRF, Xilinx
and auto component player Magneti Marelli to develop a telematics
system to be integrated into an Italian line of cars.
http://email.electronicnews.com/cgi-bin2/DM/y/ek4S0GGtJE0DbD0CQa30E3
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Xterm Hangs - Possible scheduler defect?

[Chad N. Tindel]

> What's so special about a 64-way box?

They're expensive and customers don't expect a single userspace thread to
tie up the other 63 CPUs no matter how buggy it is.  It is intuitively obvious
that a buggy kernel can bring a system to its knees, but it is not intuitively
obvious that a buggy userspace app can do the same thing.  It is more of a 
supportability issue than anything, because you expect the other processors
to function properly so you can get in and live-debug the application when it
hits a bug that makes it CPU-bound.  This is especially important if the box 
is, say, in a remote jungle of China or something where you don't have access 
to the console.

The horse is dead, so lets not beat it anymore for the time being.  It is 
quite clear that people don't want Linux to (by default) not have the gun
cocked and pointed at the application developer's feet.  People who want a 
kernel that doesn't hang in the face of bad-acting userspace apps can change
the priority of important kernel threads, which seems like a reasonable 
workaround for now.

Regards,

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

Re: ARM undefined symbols. Again.

[Paulo Marques]

Linus Torvalds wrote:
[...]
That makes no sense. Or, more likely, it means that the toolchain people 
are incompetent bastards who don't care about bugs and have no pride at 
all in what they do.
Errmm... I really feel pretty small coming in on a Russell King / Linus 
Torvalds discussion, but I was the one who promised the patch and I just 
wanted to keep my promises.

The patch (against 2.6.11-rc5) is attached, should you decide to use it.
IMHO it makes the kallsyms code look nicer, by getting rid of the 
__attribute__((weak)) statements int kernel/kallsyms.c code.

Me getting out of here now
--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
diff -uprN -X dontdiff linux-2.6.11-rc5-vanilla/kernel/kallsyms.c 
linux-2.6.11-rc5/kernel/kallsyms.c
--- linux-2.6.11-rc5-vanilla/kernel/kallsyms.c  2005-02-25 20:36:44.0 
+
+++ linux-2.6.11-rc5/kernel/kallsyms.c  2005-02-25 20:15:19.0 +
@@ -29,14 +29,14 @@
 #endif
 
 /* These will be re-linked against their real values during the second link 
stage */
-extern unsigned long kallsyms_addresses[] __attribute__((weak));
-extern unsigned long kallsyms_num_syms __attribute__((weak,section("data")));
-extern u8 kallsyms_names[] __attribute__((weak));
+extern unsigned long kallsyms_addresses[];
+extern unsigned long kallsyms_num_syms;
+extern u8 kallsyms_names[];
 
-extern u8 kallsyms_token_table[] __attribute__((weak));
-extern u16 kallsyms_token_index[] __attribute__((weak));
+extern u8 kallsyms_token_table[];
+extern u16 kallsyms_token_index[];
 
-extern unsigned long kallsyms_markers[] __attribute__((weak));
+extern unsigned long kallsyms_markers[];
 
 static inline int is_kernel_inittext(unsigned long addr)
 {
diff -uprN -X dontdiff linux-2.6.11-rc5-vanilla/Makefile 
linux-2.6.11-rc5/Makefile
--- linux-2.6.11-rc5-vanilla/Makefile   2005-02-25 20:36:15.0 +
+++ linux-2.6.11-rc5/Makefile   2005-02-25 20:25:44.0 +
@@ -702,14 +702,20 @@ quiet_cmd_kallsyms = KSYM$@
   cmd_kallsyms = $(NM) -n $< | $(KALLSYMS) \
  $(if $(CONFIG_KALLSYMS_ALL),--all-symbols) > $@
 
-.tmp_kallsyms1.o .tmp_kallsyms2.o .tmp_kallsyms3.o: %.o: %.S scripts FORCE
+quiet_cmd_kallsyms0 = KSYM$@
+  cmd_kallsyms0 = $(KALLSYMS) -0 > $@
+
+.tmp_kallsyms0.o .tmp_kallsyms1.o .tmp_kallsyms2.o .tmp_kallsyms3.o: %.o: %.S 
scripts FORCE
$(call if_changed_dep,as_o_S)
 
+.tmp_kallsyms0.S: $(KALLSYMS) FORCE
+   $(call cmd,kallsyms0)
+
 .tmp_kallsyms%.S: .tmp_vmlinux% $(KALLSYMS)
$(call cmd,kallsyms)
 
 # .tmp_vmlinux1 must be complete except kallsyms, so update vmlinux version
-.tmp_vmlinux1: $(vmlinux-lds) $(vmlinux-all) FORCE
+.tmp_vmlinux1: $(vmlinux-lds) $(vmlinux-all) .tmp_kallsyms0.o FORCE
$(call if_changed_rule,ksym_ld)
 
 .tmp_vmlinux2: $(vmlinux-lds) $(vmlinux-all) .tmp_kallsyms1.o FORCE
diff -uprN -X dontdiff linux-2.6.11-rc5-vanilla/scripts/kallsyms.c 
linux-2.6.11-rc5/scripts/kallsyms.c
--- linux-2.6.11-rc5-vanilla/scripts/kallsyms.c 2005-02-25 20:36:45.0 
+
+++ linux-2.6.11-rc5/scripts/kallsyms.c 2005-02-25 20:33:25.0 +
@@ -93,7 +93,7 @@ unsigned char best_table_len[256];
 static void
 usage(void)
 {
-   fprintf(stderr, "Usage: kallsyms [--all-symbols] < in.map > out.S\n");
+   fprintf(stderr, "Usage: kallsyms [--all-symbols] [-0] < in.map > 
out.S\n");
exit(1);
 }
 
@@ -230,6 +230,20 @@ static void output_label(char *label)
printf("%s:\n",label);
 }
 
+static void output_header(void)
+{
+   printf("#include \n");
+   printf("#if BITS_PER_LONG == 64\n");
+   printf("#define PTR .quad\n");
+   printf("#define ALGN .align 8\n");
+   printf("#else\n");
+   printf("#define PTR .long\n");
+   printf("#define ALGN .align 4\n");
+   printf("#endif\n");
+
+   printf(".data\n");
+}
+
 /* uncompress a compressed symbol. When this function is called, the best table
  * might still be compressed itself, so the function needs to be recursive */
 static int expand_symbol(unsigned char *data, int len, char *result)
@@ -257,6 +271,25 @@ static int expand_symbol(unsigned char *
return total;
 }
 
+/* this function writes an empty assembly output with just the definitions
+ * of the variables */
+
+static void write_src_zero_pass(void)
+{
+   output_header();
+
+   output_label("kallsyms_addresses");
+   output_label("kallsyms_num_syms");
+   output_label("kallsyms_names");
+   output_label("kallsyms_markers");
+   output_label("kallsyms_token_table");
+   output_label("kallsyms_token_index");
+
+   printf("\t.byte\t0\n");
+}
+
+/* this one writes the real deal */
+
 static void
 write_src(void)
 {
@@ -265,16 +298,7 @@ write_src(void)
unsigned int *markers;
char buf[KSYM_NAME_LEN+1];
 
-   printf("#include \n");
-   printf("#if BITS_PER_LONG == 64\n");
-   printf("#define 

Re: why one stack per thread and one heap for all the threads?

[Helge Hafting]

On Fri, Feb 25, 2005 at 12:03:19PM +, tony osborne wrote:
> Hi,
> 
> I wish to be personally CC'ed the answers/comments posted to the list in 
> response to this post
> 
> 
> why in multithreading, each thread has its own stack, but all share the 
> same heap?
> I understand that one stack is needed for each thread as each could have 
> its own procedure call. but why we don't associate a heap for each thread 
> since each thread can also create dynamically its own data?
> 
> 
Because stack memory management is so simple - all memory above the
stack pointer is assumed to be free.  (Or below, depending
on which way the stack grows.)  You allocate more
simply by incrementing the stack pointer, and free memory by
decrementing it.  Such a structure isnï't trivially shareable!

Heaps on the other hand, have more complex memory management.
You call into a routine, such as malloc() to reserve memory
there.  Having several threads doing so simultaneosuly is not
a problem, so there is no need for separate heaps.  Separate heaps
would waste memory, as the threads might have very different needs
for memory.  Sharing is better, when possible.

If you want separate memory for each thread, consider separate processes
instead.

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

Re: ARM undefined symbols. Again.

[Linus Torvalds]

On Fri, 25 Feb 2005, Russell King wrote:
> 
> We can't say "you must use the current CVS binutils to build the
> kernel" because that's not a sane toolchain base to build products
> on.

Sure. But it's probably enough that just a couple of core developers would 
have a CVS version to make sure that when it occasionally happens, it gets 
noticed quickly enough.

In other words, I don't think you can say "get the CVS version" to most 
users, but I do not see for example you you or some of the people around 
you don't have at least one setup set up with that fixed version.

This has been going on for at least a year, probably longer. I could 
understand it if it was a "we found this old bug, and haven't had time to 
get around it", but what I don't understand is when there's been a tools 
bug that's been known about for a long time, and apparently nobody has 
ever even bothered to try the fixed versions.

> And yes, the toolchain peoples point of view is "fix the kernel".

For a known bug where just having _one_ active developer using a fixed 
tool would mean that this doesn't happen?

That makes no sense. Or, more likely, it means that the toolchain people 
are incompetent bastards who don't care about bugs and have no pride at 
all in what they do.

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

Re: ARM undefined symbols. Again.

[Russell King]

On Fri, Feb 25, 2005 at 11:59:01AM -0800, Linus Torvalds wrote:
> On Fri, 25 Feb 2005, Russell King wrote:
> > So, what's happening about this?
> 
> Btw, is there any real reason why the ARM _tools_ can't just be fixed? I 
> don't see why this isn't a tools bug?

It is a tools bug.  But the issue is that *all* versions of binutils
currently available which are kernel-capable (since the inclusion of
the kbuild .incbin requirement on binutils) have this bug, with the
exception of maybe CVS versions.

We can't say "you must use the current CVS binutils to build the
kernel" because that's not a sane toolchain base to build products
on.

I've been wanting to see a version of binutils released pretty damn
quick so I can say "kernel only builds with latest toolchain" but
I suspect even that's going to be seen as being unreasonable.

So, my only option is to ensure that the problem with current toolchains
*is* detectable, rather than having what appears to be a perfectly good
kernel built, which may appear to run fine for the most part, but may
randomly fail due to wrongly built assembly code.

And yes, the toolchain peoples point of view is "fix the kernel".

Sorry, I'm stuck between a rock and a hard place, much like everything
else I'm faced with at the moment... ARMv6 cache patch for example.

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

Re: [Linux-fbdev-devel] Re: 2.6.11-rc5

[Olaf Hering]

 On Fri, Feb 25, James Simmons wrote:

> 
> > cfb_imageblit(320) dst1 fa51a800 base e0b8 bitstart 1999a800
> > fast_imageblit(237) s daea4000 dst1 fa51a800
> > fast_imageblit(269) j 1 fa51a800 0
> > Unable to handle kernel paging request at virtual address fa51a800
> > 
> > is bitstart incorrect or is the thing just not (yet) mapped?
> 
> Looks like the screen_base is not mapped to.

rc3 worked ok, rc4 does not. testing the -bk snapshots now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Xterm Hangs - Possible scheduler defect?

[Helge Hafting]

On Thu, Feb 24, 2005 at 02:22:37PM -0500, Chad N. Tindel wrote:
> > If you keep a learning attitude, there is a chance for this discussion 
> > to go on. However, if you keep the "Come now, don't bullshit me, this is 
> > a broken architecture and you're just trying to cover up" attitude, 
> > you're just going to get discarded as a troll.
> 
> I'm not trying to troll here; I suppose I'm just coming from a different 
> background.  I'll try to adjust my tone.
> 
> > I personally like the linux way: "root has the ability to shoot himself 
> > in the foot if he wants to". This is my computer, damn it, I am the one 
> > who tells it what to do.
> 
> I'm all for allowing people to shoot themselves in the foot.  That doesn't
> mean that it is OK for a single userspace thread to mess up a 64-way box.
> 
What's so special about a 64-way box?

Note that the box wasn't messed up - the thread merely used too much cpu.  It 
is perfectly ok - even on a 64-way box - to have a thread that runs with 
higher priority than all the kernel threads - *ïif* it occationally sleeps.  
That means the thread can get very low latency work done, and the kernel 
threads will simply wait a little.  Then the thread sleeps, and those 
cruical kernel  threads move on.  A high-priority thread that doesn't 
run all the time is no problem. and it may need the ability to preempt
kernel threads occationally due to timing constraints.  

In the case mentioned, the high-priority thread ran all the time.  That's bad, 
but there is no way the kernel can guess that is was a bad idea in that case.  
The kernel does what it is told.  An ordinary user canï't use such priorities,
so there is no security problem here.  Only root can, and root has the
power to disrupt service anyway (shutdown, kill any process, delete any file.)

Someone who runs as root is _trusted_ to do the right thing, this trust
might be outside the scope of the os.  In other words, some people are
allowed to run special processes, by the machine owner.  Some gets
the root password - and they are supposed to be above the "crowds" and
not crash the machine just because they can.

Helge Hafting

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

Re: [PATCH 2.6] Remove NULL client checks in rtc8564 driver

[Greg KH]

On Thu, Feb 24, 2005 at 10:49:57PM +0100, Jean Delvare wrote:
> Hi Stefan,
> 
> Several functions in your rtc8564 driver verify the non-NULLity of the
> i2c client that is passed to them. It doesn't seem to be necessary, as I
> can't think of any case where these functions could possibly be called
> with a NULL i2c client. As a matter of fact, I couldn't find any similar
> driver doing such checks.
> 
> My attention was brought on this by Coverity's SWAT which correctly
> noticed that three of these functions contain explicit or hidden
> dereferences of the i2c client pointer *before* the NULL check. I guess
> it wasn't a problem because the NULL case cannot happen (unless I miss
> something), but this still is confusing code.
> 
> Thus I propose the following changes:

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] [i2c]: Fix some gcc 4.0 compile failures and warnings

[Greg KH]

On Wed, Feb 23, 2005 at 02:12:44PM -0800, Mickey Stein wrote:
> From: Mickey Stein
> Versions:   linux-2.6.11-rc4-bk11, gcc4 (GCC) 4.0.0 20050217 (latest fc 
> rawhide from 19Feb DL)
> 
> gcc 4.0.x cvs seems to dislike "include/linux/i2c.h file" and others 
> due to a current gcc 4.0.x change having to do with
> array declarations.
> 
> Example error msg:   include/linux/i2c.h:{55,194} error: array type has 
> incomplete element type
> 
> A. Daplas has recently done a workaround for this on another header 
> file. A thread discussing this
> can be found by following the link below:
> 
> http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html
> 
> The patch changes the array(struct i2c_msg) declaration used by 
> *i2c_transfer and *master_xfer
> from "struct i2c_msg msg[]" format to "struct i2c_msg *msg".
> 
> After some grepping, I came up with about a dozen files that used the 
> format disliked by gcc4 that're addressed by the attached patch.
> Tested on gcc 3.x & gcc 4.x by configuring kernel with all i2c switches 
> enabled as module, and saw no errors or warnings in i2c.
> 
> Signed-off-by: Mickey Stein <[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/