Re: [Linux-fbdev-devel] [RFC 2.6.20 1/1] fbdev, mm: Deferred IO and hecubafb driver
On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Fri, 2007-02-23 at 07:32 +0100, Jaya Kumar wrote:
Can you create 2 separate patches, one for the deferred_io and another
for the driver that uses it?
Will do.
> +static struct vm_operations_struct hecubafb_vm_ops = {
> + .nopage = hecubafb_vm_nopage,
> + .page_mkwrite = fb_deferred_io_mkwrite,
> +};
> +
It would seem to me that the above can be made generic, so we have this
instead:
We could. But I think fb_deferred_io_vm_nopage would then have to
handle the different types or possible combinations of framebuffer
allocations, if they kmalloced or vmalloced or maybe combinations. Ok.
I'll try to implement that. Maybe we'll need a flag where the driver
informs us of the type of allocation.
> +static struct fb_deferred_io hecubafb_defio = {
> + .delay = HZ,
> + .deferred_io= hecubafb_dpy_deferred_io,
> +};
Leaving the drivers to just fill up the above. This would result in a
decrease of code duplication and it will be easier for driver writers.
I agree it'll be much cleaner that way but was worried if having
fb_defio do that would prevent driver writers from having their own
nopage and controlling other vm related functionality. Looking at
drivers/video/* shows no one touching vm_ops, so I guess we'll be
fine. If fb_defio takes ownership of the driver's nopage, vm_ops, etc,
then it could be just the above struct and the
fb_deferred_io_init/cleanup functions that are exposed to the driver.
ie: if an fbdev driver calls fb_deferred_io_init, we setup their mmap,
vm_ops and the necessary bits. I'll give that a shot.
I would prefer to have the init and cleanup functions called by the
driver themselves, instead of piggy-backing them to the
framebuffer_register/unregister.
Understood. I had done it that way originally but changed just before
posting. I'll revert back. :)
This basically dumps the entire framebuffer to the hardware, doesn't it?
This framebuffer has only 2 pages at the most, so it doesn't matter. But
for hardware with MB's of RAM, I don't think this is feasible.
Yup, hecuba doesn't have clean partial update functionality. But the
callback exposed to drivers is:
+ void (*deferred_io)(struct fb_info *info, struct list_head *pagelist);
which gives the drivers the list of dirty pages in pagelist. So other
drivers for hardware with the right capabilities can implement
selective or partial updates. As you mentioned, I imagine that the
drivers internally could have a bit array to enable them to mark and
find sequential partial updates. I would leave the page bitmap for
drivers to do since it would be specific to their hardware.
Thanks,
jaya
Is there a way to selectively update only the touched pages, ie from the
fbdevio->pagelist? struct page has a field (pgoff_t index), is this
usable? If not, can we just create a bit array, just to tell the driver
which are the dirty pages?
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2.6.20 1/1] fbdev,mm: Deferred IO and hecubafb driver
On 2/23/07, Paul Mundt <[EMAIL PROTECTED]> wrote: On Fri, Feb 23, 2007 at 07:32:28AM +0100, Jaya Kumar wrote: > This is a first pass at abstracting deferred IO out from hecubafb and > into fbdev as was discussed before: > http://marc.theaimsgroup.com/?l=linux-fbdev-devel&m=117187443327466&w=2 > > Please let me know your feedback and if it looks okay so far. > How about this for an fsync()? I wonder if this will be sufficient for msync() based flushing, or whether the ->sync VMA op is needed again.. Looks fine to me. Thanks, jaya - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [PATCH] nvidiafb: allow ignoring EDID info
On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote: > > The snowy is constant and abundant, and it seems to be independent of > video size (640 through 1600) and screen occupation (single prompt > line to fullscreen mc session) and usage. > > > I presume that X's nv driver or vesafb does not exhibit this problem? > > X's nv gives a very clean display, /unless/ I load nvidiafb before: if > I modprobe nvidiafb (it's a module, and it's blacklisted precisely for > this reason), then the screen is very snowy with X's nv too. > Hmm..., I really don't know how to fix this except to look at Xorg's code and look for a difference. Keep in mind that setting nvidiafb to totally ignore the EDID (either by not compiling in EDID support or by using e.g. the ignoreedid patch I had proposed) the snow effect is extremely reduced, to the point of being barely perceptible during normal usage (not as clean as X, but still very good). Also, I'm wondering if it might be worth looking at the progress done in nouveau, and the drm stuff they've implemented (or at least the new memory management and maybe some of the 2D stuff). -- Giuseppe "Oblomov" Bilotta - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Undo some of the pseudo-security madness
* Samium Gromoff: > Lisp environments can produce standalone executables If you've got a stand-alone executable, you don't need MAP_FIXED. The ELF loader maps the program at a fixed address anyway (at least on i386 and x86_64, I haven't checked others). AFAIK, PolyML has recently made the switch to stand-alone executables for this reason. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Undo some of the pseudo-security madness
> Randomisation has nothing to do with C. In fact from a C perspective the > compiler and linker do a lot of work to deal with ELF and loading code at > arbitary addresses for dynamic linking and the like, not the user and > not as language constructs. Perhaps the Lisp universe should wake up and > meet the 1980s 8) Uhm, C++ folks and others have run into loader performance issues due to the way DSOs are handled. The problem is more severe in the lisp context because a typical image contains hundreds of thousands of small objects on startup. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
REQ_HARDBARRIER and REQ_SOFTBARRIER
Hi, I'm trying to modify the ordering of I/O requests in Linux kernel, and came across the barrier flags REQ_HARDBARRIER and REQ_SOFTBARRIER. One thing I noticed (which might be wrong) is that all the requests have both these flags set. What is the significance of these flags? Is it a must for a request to have this? Can I reorder two requests with these flags set? How is SOFTBARRIER different from HARDBARRIER? I appreciate your time and help. Thanks much. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] coredump: core dump masking support v3
Markus Gutschke <[EMAIL PROTECTED]> wrote: > As an alternative to your kernel patch, you could achieve the same goal in > user space, by linking my coredumper How does it work when you can't actually get back to userspace to have userspace do the coredump? You still have to handle the userspace equivalents of double/triple faults. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[QUESTION] Sata RAID
Hi, Quick question, Since I am going to open my server today to do some pata tests (for the weird detection problems people are giving me fantastic help with, no sarcasm, I really mean it) I thought: why not add two 320GB SATA disks on the SATA controller that the mainboard has. I am wondering: should I use the onboard RAID function? Is this supported by Linux? I remember back in "the old days (TM)" there were seperate (spelling) drivers for ataraid, how does the current 2.6 branch cope with the RAID functions of modern motherboards? I am aware that it is NOT hardware raid, the raid is done in the driver, which is why you need this fancy boot disk before installing Windows on your RAID set. Or would you suggest me to stick with MD devices? Cheers, Patrick Ale [EMAIL PROTECTED] "kun kasvan isoksi, halun olla poro" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
why is asm-parisc/ioctl.h subtly different from asm-generic/ioctl.h?
just noticed that parisc's ioctl.h file, rather than simply
including asm-generic/ioctl.h, has its own copy whose sole
(meaningful) difference from the generic one is:
$ diff include/{asm-generic,asm-parisc}/ioctl.h
...
41,42c54,55
< #define _IOC_WRITE1U
< #define _IOC_READ 2U
---
> #define _IOC_WRITE2U
> #define _IOC_READ 1U
so parisc is identical except that it switches the meaning of the
direction field? is there a reason for this? just curious.
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers/mfd/sm501.c: Replace pci_module_init with pci_register_driver
Replace pci_module_init with pci_register_driver
Signed-off-by: Richard Knutson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386
diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
index 5c5a1e2..c707c8e 100644
--- a/drivers/mfd/sm501.c
+++ b/drivers/mfd/sm501.c
@@ -1131,7 +1131,7 @@ static struct platform_driver sm501_plat_drv = {
static int __init sm501_base_init(void)
{
platform_driver_register(&sm501_plat_drv);
- return pci_module_init(&sm501_pci_drv);
+ return pci_register_driver(&sm501_pci_drv);
}
static void __exit sm501_base_exit(void)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm] drivers/net/vioc/vioc_driver.c: Replace pci_module_init with pci_register_driver
Replace pci_module_init with pci_register_driver
Signed-off-by: Richard Knutson <[EMAIL PROTECTED]>
---
Not compile-tested (but should be correct!)
--- a/drivers/net/vioc/vioc_driver.c2007-02-24 10:04:03.0 +0100
+++ b/drivers/net/vioc/vioc_driver.c2007-02-24 10:05:01.0 +0100
@@ -841,9 +841,9 @@ static int __init vioc_module_init(void)
vioc_irq_init();
spp_init();
- ret = pci_module_init(&vioc_driver);
+ ret = pci_register_driver(&vioc_driver);
if (ret) {
- printk(KERN_ERR "%s: pci_module_init() -> %d\n", __FUNCTION__,
+ printk(KERN_ERR "%s: pci_register_driver() -> %d\n",
__FUNCTION__,
ret);
vioc_irq_exit();
return ret;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: I2O block driver broken in kernel 2.6.19?
(cc's restored. Please, always do reply-to-all) > On Fri, 23 Feb 2007 22:57:27 + (UTC) Mark Gray <[EMAIL PROTECTED]> wrote: > > i2o/hda:<3>Buffer I/O error on device i2o/hda, logical block 0 > > Buffer I/O error on device i2o/hda, logical block 0 > > Same error here. Both 2.6.19 and 2.6.20 kernels, using Adaptec 2400A RAID. Is Adaptec 2400 controlled by drivers/message/i2o? I assume so... If so, thats's at least three people reporting breakage in 2.6.19 and later. Is anyone able perform a git-bisect to identify the offending commit? It would really help. 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: isapnp: broken API
> On Fri, 23 Feb 2007 16:25:05 +0100 Sacher Khoudari <[EMAIL PROTECTED]> wrote: > --- linux-2.6.20.1/drivers/pnp/isapnp/core.c.old 2007-02-23 > 16:20:46.0 +0100 > +++ linux-2.6.20.1/drivers/pnp/isapnp/core.c 2007-02-23 16:21:25.0 > +0100 > @@ -943,9 +943,7 @@ > EXPORT_SYMBOL(isapnp_present); > EXPORT_SYMBOL(isapnp_cfg_begin); > EXPORT_SYMBOL(isapnp_cfg_end); > -#if 0 > EXPORT_SYMBOL(isapnp_read_byte); > -#endif > EXPORT_SYMBOL(isapnp_write_byte); Yeah, that was a rather silly unexport. I'll apply this, 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/
[PATCH] MIPS: Remove unreferenced _IOC_SLMASK macro in ioctl.h.
Delete the definition of the apparently unreferenced macro _IOC_SLMASK. Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> --- diff --git a/include/asm-mips/ioctl.h b/include/asm-mips/ioctl.h index cba641a..2036fcb 100644 --- a/include/asm-mips/ioctl.h +++ b/include/asm-mips/ioctl.h @@ -38,11 +38,6 @@ #define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS) /* - * We to additionally limit parameters to a maximum 255 bytes. - */ -#define _IOC_SLMASK0xff - -/* * Direction bits _IOC_NONE could be 0, but OSF/1 gives it a bit. * And this turns out useful to catch old ioctl numbers in header * files for us. -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: framebuffer/console boot failure
> On Fri, 23 Feb 2007 13:35:50 - (GMT) "Andrew" <[EMAIL PROTECTED]> wrote: > Hi, > > 2.6.21-rc1 fails to boot on my machine. As soon as I switch > from grub the screen turns and remains black with no sign > of Tux or any output. > > I've run a git-bisect between 2.6.20 (which works fine) and > 2.6.21-rc1 and found the first bad commit to be > #59b8175c771040afcd4ad67022b0cc80c216b866 which seems bizarre > to me since this is a mostly an ARM commit. > > I haven't tried to revert this commit because frankly I don't > know where to go from there with a multi-parent commit. > > I'm running on on a Asus A8N-VM CSM motherboard with a single > core AMD64 processor, with a nVidia GPU in the PCI-ex slot > using the standard VESA frame buffer driver. > > Relevant config's can be found here: > http://homepage.ntlworld.com/anelless/linux/2.6.21-rc1/ > and, later, > I have just discovered 2.6.21-rc1 boots with > pci=noacpi ... Presumably this regression was caused by the ACPI merge. Are you able to capture the dmesg output from the 2.6.20-rc1 boot? netconsole might be useful here, thanks. (You get added to the post-2.6.20 regression list, so you'll be hearing from us quite a lot for the next month. Sorry ;)) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Nvidiafb broken in 2.6.21-rc1
With 2.6.21-rc1 I get no video signal from nvidiafb on PowerMac G5. Bisection has identified this patch: commit 599a52d12629394236d785615808845823875868 Author: Richard Purdie <[EMAIL PROTECTED]> Date: Sat Feb 10 23:07:48 2007 + backlight: Separate backlight properties from backlight ops pointers Per device data such as brightness belongs to the indivdual device and should therefore be separate from the the backlight operation function pointers. This patch splits the two types of data and allows simplifcation of some code. Signed-off-by: Richard Purdie <[EMAIL PROTECTED]> Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] coredump: core dump masking support v3
> Kawai, Hidehiro wrote: > >This patch series is version 3 of the core dump masking feature, > >which provides a per-process flag not to dump anonymous shared > >memory segments. > > I just wanted to remind you that you need to be careful about dumping > the [vdso] segment no matter whether you omit other segments. I didn't > actually try running your patches, and if the kernel doesn't actually > consider this segment anonymous and shared, things might already work > fine as is. > > In any case, you can check with "readelf -a", if the [vdso] segment is > there. And you will find that if you forget to dump it, "gdb" can no > longer give you stack traces on call chains that involve signal handlers. > > As an alternative to your kernel patch, you could achieve the same goal > in user space, by linking my coredumper > http://code.google.com/p/google-coredumper/ into your binaries and > setting up appropriate signal handlers. An equivalent patch for > selectively omitting memory regions would be trivial to add. While this > does give you more flexibility, it of course has the drawback of > requiring you to change your applications, so there still is some > benefit in a kernelspace solution. "We are too lazy to change 0.01% of apps that actually need it" is not good enough reason to push the feature into kernel, I'd say. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][RFC] Make asm-generic/ioctl.h extensible by adding conditionals.
Add some preprocessor checking to asm-generic/ioctl.h to allow other ioctl.h headers to simply override what are normally trivial differences. Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> --- as a followup to my earlier post, is it worth making this change to allow at least a couple arch-specific ioctl.h files to be massively simplified? diff --git a/include/asm-generic/ioctl.h b/include/asm-generic/ioctl.h index cd02729..e035e6d 100644 --- a/include/asm-generic/ioctl.h +++ b/include/asm-generic/ioctl.h @@ -21,8 +21,15 @@ */ #define _IOC_NRBITS8 #define _IOC_TYPEBITS 8 -#define _IOC_SIZEBITS 14 -#define _IOC_DIRBITS 2 +/* + * Let any architecture override either of the following. + */ +#ifndef _IOC_SIZEBITS +# define _IOC_SIZEBITS 14 +#endif +#ifndef _IOC_DIRBITS +# define _IOC_DIRBITS 2 +#endif #define _IOC_NRMASK((1 << _IOC_NRBITS)-1) #define _IOC_TYPEMASK ((1 << _IOC_TYPEBITS)-1) @@ -35,11 +42,17 @@ #define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS) /* - * Direction bits. + * Direction bits, which any architecture can choose to override. */ -#define _IOC_NONE 0U -#define _IOC_WRITE 1U -#define _IOC_READ 2U +#ifndef _IOC_NONE +# define _IOC_NONE 0U +#endif +#ifndef _IOC_WRITE +# define _IOC_WRITE1U +#endif +#ifndef _IOC_READ +# define _IOC_READ 2U +#endif #define _IOC(dir,type,nr,size) \ (((dir) << _IOC_DIRSHIFT) | \ -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] usbatm: Create sysfs link "device" from atm class device to usb interface.
There is currently no path from the ATM device in /sys to the USB device's
interface that the driver is using; this patch creates a "device" symlink. It
is then possible to get to the cxacru ADSL statistics
(http://lkml.org/lkml/2007/2/23/328):
/sys/class/atm/cxacru0/device $ ls *_rate *_margin *_attenuation
downstream_attenuation downstream_snr_margin upstream_rate
downstream_rate upstream_attenuation upstream_snr_margin
If this link is not appropriate I'd have to create device files in
/sys/class/atm/cxacru0 instead - which seems less appropriate since the ADSL
statistics are for the USB device not ATM (which is running over the ADSL).
Signed-off-by: Simon Arlott <[EMAIL PROTECTED]>
---
drivers/usb/atm/usbatm.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/atm/usbatm.c b/drivers/usb/atm/usbatm.c
index d91ed11..d0f1976 100644
--- a/drivers/usb/atm/usbatm.c
+++ b/drivers/usb/atm/usbatm.c
@@ -969,6 +969,12 @@ static int usbatm_atm_init(struct usbatm
/* temp init ATM device, set to 128kbit */
atm_dev->link_rate = 128 * 1000 / 424;
+ ret = sysfs_create_link(&atm_dev->class_dev.kobj,
&instance->usb_intf->dev.kobj, "device");
+ if (ret) {
+ atm_err(instance, "%s: sysfs_create_link failed: %d\n",
__func__, ret);
+ goto fail_sysfs;
+ }
+
if (instance->driver->atm_start && ((ret =
instance->driver->atm_start(instance, atm_dev)) < 0)) {
atm_err(instance, "%s: atm_start failed: %d!\n", __func__, ret);
goto fail;
@@ -987,6 +993,8 @@ static int usbatm_atm_init(struct usbatm
return 0;
fail:
+ sysfs_remove_link(&atm_dev->class_dev.kobj, "device");
+ fail_sysfs:
instance->atm_dev = NULL;
atm_dev_deregister(atm_dev); /* usbatm_atm_dev_close will eventually be
called */
return ret;
@@ -1319,8 +1327,10 @@ void usbatm_usb_disconnect(struct usb_in
kfree(instance->cell_buf);
/* ATM finalize */
- if (instance->atm_dev)
+ if (instance->atm_dev) {
+ sysfs_remove_link(&instance->atm_dev->class_dev.kobj, "device");
atm_dev_deregister(instance->atm_dev);
+ }
usbatm_put_instance(instance); /* taken in usbatm_usb_probe */
}
--
1.4.3.1
--
Simon Arlott
signature.asc
Description: OpenPGP digital signature
Memory sharing question
Hi. I'd like to know if it is possible to get two processes to share a memory segment at the same address, e.g. both mmap() the same file and have it return the same address in both. This could be done by mmap()ing it in one of them, communicating the address to the other (via a socket or whatever), which then mmap()s it with the address as the "start" parameter and MAP_FIXED. However, that tends to fail, and MAP_FIXED can have annoying side-effects (killing off other mappings). Is it possible to reliably make the same address in two different processes point to the same bit of physical memory? The point of all this is that I want to pass a large, complex (full of pointers) data structure to a different process, and I don't want the overhead of serialising it down a socket and then parsing it at the other end (the data structure's pretty big, and the other process won't need it all). Is this possible? Thanks, Stephen Dolan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.20-almost-rc1: usb oops during resume
Hi! ...is it "use after free"? Greg, could we reduce verbosity of driver model? "PM: Adding info for No Bus:vcs*" is not very useful. I have some patches in bluetooth, but nothing that should really matter. Pavel Bluetooth: L2CAP ver 2.8 Bluetooth: L2CAP socket layer initialized Bluetooth: SCO (Voice Link) ver 0.5 Bluetooth: SCO socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 Bluetooth: BNEP (Ethernet Emulation) ver 1.2 Bluetooth: BNEP filters: protocol multicast Bluetooth: HIDP (Human Interface Emulation) ver 1.1 ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation <[EMAIL PROTECTED]> ieee80211_crypt: registered algorithm 'NULL' ieee80211_crypt: registered algorithm 'WEP' Starting balanced_irq Using IPI No-Shortcut mode swsusp: Resume From Partition /dev/sda1 PM: Checking swsusp image. Time: acpi_pm clocksource has been installed. PM: Resume from disk failed. md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 280k freed PM: Adding info for No Bus:vcs1 PM: Adding info for No Bus:vcsa1 PM: Removing info for No Bus:vcs1 PM: Removing info for No Bus:vcsa1 PM: Adding info for No Bus:vcs1 PM: Adding info for No Bus:vcsa1 PM: Removing info for No Bus:vcs1 PM: Removing info for No Bus:vcsa1 PM: Adding info for No Bus:vcs1 PM: Adding info for No Bus:vcsa1 PM: Removing info for No Bus:vcs1 PM: Removing info for No Bus:vcsa1 PM: Adding info for No Bus:vcs1 PM: Adding info for No Bus:vcsa1 PM: Removing info for No Bus:vcs1 PM: Removing info for No Bus:vcsa1 PM: Adding info for No Bus:vcs1 PM: Adding info for No Bus:vcsa1 PM: Removing info for No Bus:vcs1 PM: Removing info for No Bus:vcsa1 PM: Adding info for No Bus:vcs1 PM: Adding info for No Bus:vcsa1 PM: Removing info for No Bus:vcs1 PM: Removing info for No Bus:vcsa1 PM: Adding info for No Bus:vcs1 PM: Adding info for No Bus:vcsa1 PM: Removing info for No Bus:vcs1 PM: Removing info for No Bus:vcsa1 PM: Adding info for No Bus:vcs1 PM: Adding info for No Bus:vcsa1 PM: Removing info for No Bus:vcs1 PM: Removing info for No Bus:vcsa1 PM: Adding info for No Bus:vcs1 PM: Adding info for No Bus:vcsa1 PM: Removing info for No Bus:vcs1 PM: Removing info for No Bus:vcsa1 PM: Adding info for No Bus:vcs1 PM: Adding info for No Bus:vcsa1 PM: Adding info for No Bus:vcs23 PM: Adding info for No Bus:vcsa23 EXT3 FS on sda4, internal journal Adding 987988k swap on /dev/sda1. Priority:-1 extents:1 across:987988k kjournald starting. Commit interval 5 seconds EXT3 FS on sda2, internal journal EXT3-fs: mounted filesystem with ordered data mode. PM: Adding info for No Bus:vcs12 PM: Adding info for No Bus:vcsa12 pcmcia: Detected deprecated PCMCIA ioctl usage from process: cardmgr. pcmcia: This interface will soon be removed from the kernel; please expect breakage unless you upgrade to new tools. pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details. cs: IO port probe 0x310-0x380: clean. cs: IO port probe 0xa00-0xaff: clean. PM: Adding info for No Bus:vcs10 PM: Adding info for No Bus:vcsa10 Clocksource tsc unstable (delta = -299687739 ns) PM: Adding info for No Bus:vcs11 PM: Adding info for No Bus:vcsa11 PM: Adding info for No Bus:vcs2 PM: Adding info for No Bus:vcs4 PM: Adding info for No Bus:vcs3 PM: Adding info for No Bus:vcs5 PM: Adding info for No Bus:vcs6 PM: Adding info for No Bus:vcs8 PM: Adding info for No Bus:vcs7 PM: Adding info for No Bus:vcsa4 PM: Adding info for No Bus:vcsa3 PM: Adding info for No Bus:vcsa5 PM: Adding info for No Bus:vcsa6 PM: Adding info for No Bus:vcsa8 PM: Adding info for No Bus:vcsa7 PM: Adding info for No Bus:vcsa2 coda_read_super: Bad mount data coda_read_super: device index: 0 coda_read_super: rootfid is (01234567..080519b0.) PM: Removing info for No Bus:vcs10 PM: Removing info for No Bus:vcsa10 coda_upcall: Venus dead on (op,un) (7.2) flags 10 Failure of coda_cnode_make for root: error -19 usb 5-1: new full speed USB device using uhci_hcd and address 3 PM: Adding info for usb:5-1 PM: Adding info for No Bus:usbdev5.3_ep00 usb 5-1: configuration #1 chosen from 1 choice PM: Adding info for usb:5-1:1.0 PM: Adding info for No Bus:hci0 PM: Adding info for No Bus:usbdev5.3_ep81 PM: Adding info for No Bus:usbdev5.3_ep82 PM: Adding info for No Bus:usbdev5.3_ep02 PM: Adding info for usb:5-1:1.1 PM: Adding info for No Bus:usbdev5.3_ep83 PM: Adding info for No Bus:usbdev5.3_ep03 PM: Adding info for usb:5-1:1.2 PM: Adding info for No Bus:usbdev5.3_ep84 PM: Adding info for No Bus:usbdev5.3_ep04 PM: Adding info for usb:5-1:1.3 PM: Adding info for No Bus:usbdev5.3 hci_cmd_task: hci0 command tx timeout PM: Adding
Re: 2.6.20-ck1
On 2/16/07, Con Kolivas <[EMAIL PROTECTED]> wrote: This patchset is designed to improve system responsiveness and interactivity. It is configurable to any workload but the default -ck patch is aimed at the desktop and -cks is available with more emphasis on serverspace. Hi Con. I usually don't pay a lot of attention to benchmarks. Responsiveness under load is much important to me. But this is nice: I use FC6 with initng as boot process manager. With vanilla 2.6.20 boot process takes 21 to 23 seconds; with 2.6.20-ck1 (same config, of course), boot process takes 17 to 19 seconds. So your patchset has become my patchset of choice. Regards, Fabio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A quick fio test (was Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3)
On Fri, Feb 23 2007, Joel Becker wrote: > On Fri, Feb 23, 2007 at 01:52:47PM +0100, Jens Axboe wrote: > > Results: > > > > Engine Depth Bw (MiB/sec) > > > > libaio1 441 > > syslet1 574 > > sync 1 589 > > libaio 32 613 > > syslet 32 681 > > Can we get runs with large I/Os, large I/O depths, and most > importantly tons of processes? I can absolutely believe that syslets > would compete well with one process on the system. But with 1000 > processes doing 1000s of blocking I/Os, I'd really be interested to see > how that plays out. Sure, I'll add this to the testing list for monday. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] needs to include
sysdev.h uses THIS_MODULE so should include . Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> diff --git a/include/linux/sysdev.h b/include/linux/sysdev.h index 389ccf8..e699ab2 100644 --- a/include/linux/sysdev.h +++ b/include/linux/sysdev.h @@ -22,6 +22,7 @@ #define _SYSDEV_H_ #include +#include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] MIPS: Remove unreferenced _IOC_SLMASK macro in ioctl.h.
On Sat, Feb 24, 2007 at 06:17:09AM -0500, Robert P. J. Day wrote: > Delete the definition of the apparently unreferenced macro > _IOC_SLMASK. Applied. Thanks, Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ioctls.h (Re: [PATCH][RFC] Make asm-generic/ioctl.h extensible by adding conditionals.)
> From: "Robert P. J. Day" > Newsgroups: gmane.linux.kernel > Subject: [PATCH][RFC] Make asm-generic/ioctl.h extensible by adding > conditionals. > Date: Sat, 24 Feb 2007 06:45:20 -0500 (EST) > as a followup to my earlier post, is it worth making this change to > allow at least a couple arch-specific ioctl.h files to be massively > simplified? And i wonder, why there is no generic ioctls.h, hm? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] USB Elan FTDI: check for workqueue creation v2
> From: Cyrill Gorcunov > Newsgroups: gmane.linux.kernel > Subject: bss zeroing ([PATCH] USB Elan FTDI: check for workqueue creation v2) > Date: Sat, 24 Feb 2007 10:41:15 +0300 [] > Btw, Pete, you are right! C99 ANSI standart says that static pointer > if it not initialized explicitly has to be set to NULL by compiler ;) > Thanks a lot for comments and Ack the patch please. Are you sure about "by compiler"? I mean, why not by OS, in case of uCs by code/data memory image generator? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: REQ_HARDBARRIER and REQ_SOFTBARRIER
On Sat, Feb 24 2007, V P wrote: > Hi, > > I'm trying to modify the ordering of I/O requests in Linux kernel, and > came across the barrier flags REQ_HARDBARRIER and REQ_SOFTBARRIER. > > One thing I noticed (which might be wrong) is that all the requests > have both these flags set. What is the significance of these flags? Is Uhm? That's definitely not true. > it a must for a request to have this? Can I reorder two requests with > these flags set? How is SOFTBARRIER different from HARDBARRIER? Both imply a reordering barrier in the io scheduler, and the hard barrier further implies a barrier at the drive/driver side. So you may not reorder across a barrier. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory sharing question
> with the address as the "start" parameter and MAP_FIXED. However, that > tends to fail, and MAP_FIXED can have annoying side-effects (killing > off other mappings). MAP_FIXED requires you know in advance a good place to put the memory, which isn't too hard with some planning but does get fairly platform specific and requires good knowledge. > The point of all this is that I want to pass a large, complex (full of > pointers) data structure to a different process, and I don't want the > overhead of serialising it down a socket and then parsing it at the > other end (the data structure's pretty big, and the other process > won't need it all). Is this possible? You can also just use relative pointers, which is actually pretty fast on most modern processors - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
typo in include/linux/irqflags.h ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi ! Seems like there was a cut&past error in include/linux/riqflags.h. - --- linux-2.6.20/include/linux/irqflags.h 2007-02-04 09:44:54.0 -0900 +++ linux-2.6.20xm/include/linux/irqflags.h 2008-01-27 20:29:26.0 -0900 @@ -91,6 +91,6 @@ }) #define irqs_disabled_flags(flags) raw_irqs_disabled_flags(flags) - -#endif /* CONFIG_X86 */ +#endif /* CONFIG_TRACE_IRQFLAGS_SUPPORT */ #endif thx ! hofrat -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFF4CVPnU7rXZKfY2oRAmrDAJ9eFu3APdl0Y5LoYoUAPGXzipx2wwCgl3gM 28KVNI1v+DM/LyTWEv2XhQc= =aAnC -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel warning from Matrox Framebuffer in 2.6.20.1
Hi, I have just booted 2.6.20.1 on my Pentium 3 machine, which has a G400 MAX graphics card. This machine uses the Matrox framebuffer and TV-OUT modules, and I have found these warnings in the kernel log: **WARNING** I2C adapter driver [DDC:fb0 #0] forgot to specify physical device; fix it! **WARNING** I2C adapter driver [DDC:fb0 #1] forgot to specify physical device; fix it! **WARNING** I2C adapter driver [MAVEN:fb0] forgot to specify physical device; fix it! The relevant kernel modules seem to be: matroxfb_maven 13228 0 i2c_matroxfb4064 0 i2c_algo_bit6312 1 i2c_matroxfb Cheers, Chris ___ All New Yahoo! Mail Tired of unwanted email come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.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: typo in include/linux/irqflags.h ?
On Sat, Feb 24, 2007 at 12:45:16PM +0100, Nicholas Mc Guire wrote: > > Hi ! > > Seems like there was a cut&past error in include/linux/riqflags.h. > > > --- linux-2.6.20/include/linux/irqflags.h 2007-02-04 09:44:54.0 > -0900 > +++ linux-2.6.20xm/include/linux/irqflags.h 2008-01-27 20:29:26.0 > -0900 > @@ -91,6 +91,6 @@ > }) > > #define irqs_disabled_flags(flags) raw_irqs_disabled_flags(flags) > -#endif /* CONFIG_X86 */ > +#endif /* CONFIG_TRACE_IRQFLAGS_SUPPORT */ Just yet rid of the comment - you can see the corresponding #ifdef on the screen without paging up or down so it seems pointless to have such a comment - it just adds additional unnecessary clutter to the screen. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/3] VM throttling: avoid blocking occasional writers
Tomoki Sekiyama writes: > Hi, Hello, > [...] > > While Dirty+Writeback pages get more than 40% of memory, process-B is > blocked in balance_dirty_pages() until writeback of some (`write_chunk', > typically = 1536) dirty pages on disk-b is started. May be the simpler solution is to use separate variables to control ratelimit and write chunk? writeback_set_ratelimit() adjusts ratelimit_pages to avoid too frequent calls to balance_dirty_pages(), but once we are inside of writeback_inodes(), there is no need to write especially many pages in one go: overhead of any additional looping is negligible, when compared with the cost of writing. Speaking of which, now that expensive get_writeback_state() is gone from page-writeback.c why do we need adjustable ratelimiting at all? It looks like writeback_set_ratelimit() can be dropped, and fixed ratelimit used instead. Nikita. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] sk98lin: handle pci_enable_device() return value in skge_resume()
Dmitriy Monakhov <[EMAIL PROTECTED]> writes:
> This thread looks dead but issue was't fixed.
>
> Jiri Kosina <[EMAIL PROTECTED]> writes:
>>> > - pci_enable_device(pdev);
>>> > + ret = pci_enable_device(pdev);
>>> > + if (ret) {
>>> > + printk(KERN_ERR "sk98lin: Cannot enable PCI device %s during
>>> > resume\n",
>>> > + dev->name);
>>> > + unregister_netdev(dev);
>>> This looks rather wrong - skge_exit() will run unregister_netdev() again.
>>
>> You are of course right (the problem was also spotted by Russell King).
>> This I believe is the correct one for the sk98lin case.
>>
>> [PATCH] fix sk98lin driver, ignoring return value from pci_enable_device()
>>
>> add check of return value to _resume() function of sk98lin driver.
>>
>> Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
>>
>> ---
>>
>> --- a/drivers/net/sk98lin/skge.c
>> +++ b/drivers/net/sk98lin/skge.c
>> @@ -5070,7 +5070,12 @@ static int skge_resume(struct pci_dev *p
>>
>> pci_set_power_state(pdev, PCI_D0);
>> pci_restore_state(pdev);
>> -pci_enable_device(pdev);
>> +ret = pci_enable_device(pdev);
>> +if (ret) {
>> +printk(KERN_WARNING "sk98lin: unable to enable device %s in
>> resume\n",
>> +dev->name);
>> +goto out_err;
>> +}
> [snip]
>> +out_err:
>> +pAC->AllocFlag &= ~SK_ALLOC_IRQ;
>> +dev->irq = 0;
>> +pci_disable_device(pdev);
> < Ok what happend if we jump here right after pci_disable_device() has
OOPs.Of course i mean pci_enable_device() here^
I'm sorry about this. (Option complete_word not always good, some times
brain work required too :) )
So correct comment looks like:
< Ok what happend if we jump here right after pci_enable_device() has
failed, but pci_disable_device() was called anyway, this is wrong and
may be fatal because pdev->enable_cnt may becomes negative.
>> +
>> +return ret;
>> +
>> }
>> #else
>> #define skge_suspend NULL
> This is reworked Jiri's patch:
>
> [PATCH] sk98lin: handle pci_enable_device() return value in skge_resume()
>
> Signed-off-by: Monakhov Dmitriy <[EMAIL PROTECTED]>
> ---
> drivers/net/sk98lin/skge.c | 20 +++-
> 1 files changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/sk98lin/skge.c b/drivers/net/sk98lin/skge.c
> index e94ab25..eea753a 100644
> --- a/drivers/net/sk98lin/skge.c
> +++ b/drivers/net/sk98lin/skge.c
> @@ -5125,7 +5125,12 @@ static int skge_resume(struct pci_dev *pdev)
>
> pci_set_power_state(pdev, PCI_D0);
> pci_restore_state(pdev);
> - pci_enable_device(pdev);
> + ret = pci_enable_device(pdev);
> + if (ret) {
> + printk(KERN_WARNING "sk98lin: unable to enable device %s "
> + "in resume\n", dev->name);
> + goto err_out;
> + }
> pci_set_master(pdev);
> if (pAC->GIni.GIMacsFound == 2)
> ret = request_irq(dev->irq, SkGeIsr, IRQF_SHARED, "sk98lin",
> dev);
> @@ -5133,10 +5138,8 @@ static int skge_resume(struct pci_dev *pdev)
> ret = request_irq(dev->irq, SkGeIsrOnePort, IRQF_SHARED,
> "sk98lin", dev);
> if (ret) {
> printk(KERN_WARNING "sk98lin: unable to acquire IRQ %d\n",
> dev->irq);
> - pAC->AllocFlag &= ~SK_ALLOC_IRQ;
> - dev->irq = 0;
> - pci_disable_device(pdev);
> - return -EBUSY;
> + ret = -EBUSY;
> + goto err_out_disable_pdev;
> }
>
> netif_device_attach(dev);
> @@ -5153,6 +5156,13 @@ static int skge_resume(struct pci_dev *pdev)
> }
>
> return 0;
> +
> +err_out_disable_pdev:
> + pci_disable_device(pdev);
> +err_out:
> + pAC->AllocFlag &= ~SK_ALLOC_IRQ;
> + dev->irq = 0;
> + return ret;
> }
> #else
> #define skge_suspend NULL
> --
> 1.4.4.4
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: [KJ][RFC][PATCH] BIT macro cleanup
On Fri, Feb 23, 2007 at 01:44:41PM +0530, Milind Choudhary wrote: > Hi all > working towards the cleanup of BIT macro, > I've added one to & cleaned some obvious users. > > include/linux/input.h also has a BIT macro > which does a wrap > so currently i've done something like > > +#undef BIT > #define BIT(nr)(1UL << ((nr) % BITS_PER_LONG)) Since the previous definition of #define BIT(nr) (1UL << (nr)) gives the same results as the above one for all reasonable usage scenarios (you don't want to supply nr larger than BITS_PER_LONG), why not just use the modulo version everywhere? The only problem I see is that the compiler would not warn where nr IS too large. -- Vojtech Pavlik Director SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [KJ][RFC][PATCH] BIT macro cleanup
On Fri, Feb 23, 2007 at 11:43:44PM +0100, Richard Knutsson wrote:
> >I am saying that IMO input's BIT definition should be
> >adequate for 99% of potential users and that I would be OK with moving
> >said BIT definition from input.h to bitops.h and maybe supplementing
> >it with LLBIT. I am also saying that I do not want BITWRAP, BITSWAP
> >(what swap btw?) nor BIT(x % BITS_PER_LONG) in input drivers.
And I totally agree with Dmitry. The "% BITS_PER_LONG" doesn't hurt
other users, and it's needed for larger-than-single-long bit arrays.
> Is the reason for the modulo to put a bitmask larger then the variable
> into an array?
The complementary LONG() macro will tell you the index of an array of
longs where the bit should be set.
> I did just a quick 'grep' for "BIT(" in drivers/input/
> and from what I saw, most (or all?) of the values are defined constants
> and those in input.h were noway near the limits of a 'long'.
Well, many do not need it, but for example BIT(BTN_LEFT) does, and
that's used in a lot of places.
> The reason I don't like it with modulo is simply because it hides
> potential bugs (when x is to big).
That would be my only concern - losing compiler warnings.
> And what about the "1%"?
The 1% will need either LLBIT or an extra % 8.
> IMHO BIT should be as simple as possible.
--
Vojtech Pavlik
Director SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [KJ][RFC][PATCH] BIT macro cleanup
Vojtech Pavlik wrote: On Fri, Feb 23, 2007 at 11:43:44PM +0100, Richard Knutsson wrote: Is the reason for the modulo to put a bitmask larger then the variable into an array? The complementary LONG() macro will tell you the index of an array of longs where the bit should be set. This may be a little OT, but how come it is not done as an function? Maybe something like "(set/get)_long_mask(...)". The reason I don't like it with modulo is simply because it hides potential bugs (when x is to big). That would be my only concern - losing compiler warnings. And what bugs me is that this will effect the whole tree for a feature used in only input, right? And what about the "1%"? The 1% will need either LLBIT or an extra % 8. Oh, that's true Richard Knutsson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Undo some of the pseudo-security madness
At Sat, 24 Feb 2007 10:40:51 +0100, Florian Weimer wrote: > > * Samium Gromoff: > > > Lisp environments can produce standalone executables > > If you've got a stand-alone executable, you don't need MAP_FIXED. The > ELF loader maps the program at a fixed address anyway (at least on > i386 and x86_64, I haven't checked others). Not so. The thing is that the picture is of two pieces: - the executable - the unrelocatable lisp core (which is unrelocatable by the virtue of non-PIC code) which is mapped into the AS of the executable. It is the latter which breaks, as its map can overlap with randomized pieces of the executable (along with its libraries). > AFAIK, PolyML has recently made the switch to stand-alone executables > for this reason. regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Undo some of the pseudo-security madness
At Sat, 24 Feb 2007 10:51:20 +0100, Florian Weimer wrote: > > > Randomisation has nothing to do with C. In fact from a C perspective the > > compiler and linker do a lot of work to deal with ELF and loading code at > > arbitary addresses for dynamic linking and the like, not the user and > > not as language constructs. Perhaps the Lisp universe should wake up and > > meet the 1980s 8) > > Uhm, C++ folks and others have run into loader performance issues due > to the way DSOs are handled. The problem is more severe in the lisp > context because a typical image contains hundreds of thousands of > small objects on startup. Well: [EMAIL PROTECTED]:/mnt/shared/video1 # cat /proc/`pgrep sbcl | head -n1`/maps | wc -l 1378 regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: typo in include/linux/irqflags.h ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Feb 24, 2007 at 12:45:16PM +0100, Nicholas Mc Guire wrote: Hi ! Seems like there was a cut&past error in include/linux/riqflags.h. --- linux-2.6.20/include/linux/irqflags.h 2007-02-04 09:44:54.0 -0900 +++ linux-2.6.20xm/include/linux/irqflags.h 2008-01-27 20:29:26.0 -0900 @@ -91,6 +91,6 @@ }) #define irqs_disabled_flags(flags)raw_irqs_disabled_flags(flags) -#endif /* CONFIG_X86 */ +#endif /* CONFIG_TRACE_IRQFLAGS_SUPPORT */ Just yet rid of the comment - you can see the corresponding #ifdef on the screen without paging up or down so it seems pointless to have such a comment - it just adds additional unnecessary clutter to the screen. well not for people that only have one line on the braille-screen, for it helps but it better be right or we get lost completly ;) hofrat -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFF4DX6nU7rXZKfY2oRAg6zAJ4kK0c6T+fEXavRELt5vJnpLQxbYACfQhvR bWg4oR0/6ng+1Cmlzwn7Igc= =hQd0 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
* Samium Gromoff: >> > Lisp environments can produce standalone executables >> >> If you've got a stand-alone executable, you don't need MAP_FIXED. The >> ELF loader maps the program at a fixed address anyway (at least on >> i386 and x86_64, I haven't checked others). > > Not so. > > The thing is that the picture is of two pieces: > > - the executable > - the unrelocatable lisp core (which is unrelocatable by the virtue >of non-PIC code) which is mapped into the AS of the executable. > > It is the latter which breaks, as its map can overlap with randomized > pieces of the executable (along with its libraries). I think it boils down to the question if you can use ELF relocations to create a relocatable (but not necessarily position-independent) object that ld can link with the SBCL run-time system to produce an executable. This executable would truly be stand-alone because no separate core file is required anymore. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Soft lockup on shutdown in nf_ct_iterate_cleanup()
Chuck Ebbert wrote: > Chuck Ebbert wrote: > >>I was testing a 2.6.20 kernel and got a soft >>lockup on shutdown: >> >>_raw_write_lock+0x5a >>nf_ct_iterate_cleanup+0x3e >>kill_l3proto+0x0 >>nf_conntrack_l3proto_unregister+0x85 >>nf_conntrack_l3proto_ipv4_fini+0x1e >>sys_delete_module+0x18a >>remove_vma+0x45 >>do_munmap+0x196 >>syscall_call+0x7 > > > Happened three times in a row, trying to remove > netfilter modules. Does it happen when you unload only nf_conntrack_ipv4, or do you need to unload other modules previously? Does it really lock up? Please also send your config. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20-almost-rc1: usb oops during resume
Hi Pavel, > ...is it "use after free"? > > Greg, could we reduce verbosity of driver model? "PM: Adding info for > No Bus:vcs*" is not very useful. > > I have some patches in bluetooth, but nothing that should really > matter. can you try to remove the hci_usb_close() in hci_usb_disconnect(), because hci_unregister_dev() is calling this one anyway. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] the overdue removal of X86_SPEEDSTEP_CENTRINO_ACPI
Ack.
Dave: Can you add this patch to cpufreq.git -> mm.
Thanks,
Venki
>-Original Message-
>From: Adrian Bunk [mailto:[EMAIL PROTECTED]
>Sent: Monday, February 19, 2007 4:07 PM
>To: Pallipadi, Venkatesh
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
>linux-kernel@vger.kernel.org
>Subject: [2.6 patch] the overdue removal of X86_SPEEDSTEP_CENTRINO_ACPI
>
>This patch contains the overdue removal of X86_SPEEDSTEP_CENTRINO_ACPI.
>
>Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
>---
>
> Documentation/feature-removal-schedule.txt| 22 -
> arch/i386/kernel/cpu/cpufreq/Kconfig | 19
> arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c | 280
>--
> arch/x86_64/kernel/cpufreq/Kconfig|7
> 4 files changed, 21 insertions(+), 307 deletions(-)
>
>---
>linux-2.6.19-rc6-mm2/arch/i386/kernel/cpu/cpufreq/Kconfig.old
>2006-12-01 07:23:38.0 +0100
>+++ linux-2.6.19-rc6-mm2/arch/i386/kernel/cpu/cpufreq/Kconfig
>2006-12-01 07:24:02.0 +0100
>@@ -109,7 +109,7 @@
> config X86_SPEEDSTEP_CENTRINO
> tristate "Intel Enhanced SpeedStep"
> select CPU_FREQ_TABLE
>- select X86_SPEEDSTEP_CENTRINO_TABLE if
>(!X86_SPEEDSTEP_CENTRINO_ACPI)
>+ select X86_SPEEDSTEP_CENTRINO_TABLE
> help
> This adds the CPUFreq driver for Enhanced SpeedStep enabled
> mobile CPUs. This means Intel Pentium M (Centrino)
>CPUs. However,
>@@ -121,21 +121,6 @@
>
> If in doubt, say N.
>
>-config X86_SPEEDSTEP_CENTRINO_ACPI
>- bool "Use ACPI tables to decode valid frequency/voltage
>(deprecated)"
>- depends on X86_SPEEDSTEP_CENTRINO && ACPI_PROCESSOR
>- depends on !(X86_SPEEDSTEP_CENTRINO = y && ACPI_PROCESSOR = m)
>- default y
>- help
>-This is deprecated and this functionality is now merged into
>-acpi_cpufreq (X86_ACPI_CPUFREQ). Use that driver instead of
>-speedstep_centrino.
>-Use primarily the information provided in the BIOS ACPI tables
>-to determine valid CPU frequency and voltage pairings. It is
>-required for the driver to work on non-Banias CPUs.
>-
>-If in doubt, say Y.
>-
> config X86_SPEEDSTEP_CENTRINO_TABLE
> bool "Built-in tables for Banias CPUs"
> depends on X86_SPEEDSTEP_CENTRINO
>@@ -222,7 +207,7 @@
> config X86_ACPI_CPUFREQ_PROC_INTF
> bool "/proc/acpi/processor/../performance interface
>(deprecated)"
> depends on PROC_FS
>- depends on X86_ACPI_CPUFREQ ||
>X86_SPEEDSTEP_CENTRINO_ACPI || X86_POWERNOW_K7_ACPI ||
>X86_POWERNOW_K8_ACPI
>+ depends on X86_ACPI_CPUFREQ || X86_POWERNOW_K7_ACPI ||
>X86_POWERNOW_K8_ACPI
> help
> This enables the deprecated
>/proc/acpi/processor/../performance
> interface. While it is helpful for debugging, the generic,
>---
>linux-2.6.19-rc6-mm2/arch/x86_64/kernel/cpufreq/Kconfig.old
>2006-12-01 07:24:11.0 +0100
>+++ linux-2.6.19-rc6-mm2/arch/x86_64/kernel/cpufreq/Kconfig
>2006-12-01 07:24:21.0 +0100
>@@ -42,11 +42,6 @@
>
> If in doubt, say N.
>
>-config X86_SPEEDSTEP_CENTRINO_ACPI
>- bool
>- depends on X86_SPEEDSTEP_CENTRINO
>- default y
>-
> config X86_ACPI_CPUFREQ
> tristate "ACPI Processor P-States driver"
> select CPU_FREQ_TABLE
>@@ -65,7 +60,7 @@
> config X86_ACPI_CPUFREQ_PROC_INTF
> bool "/proc/acpi/processor/../performance interface
>(deprecated)"
> depends on PROC_FS
>- depends on X86_ACPI_CPUFREQ ||
>X86_SPEEDSTEP_CENTRINO_ACPI || X86_POWERNOW_K8_ACPI
>+ depends on X86_ACPI_CPUFREQ || X86_POWERNOW_K8_ACPI
> help
> This enables the deprecated
>/proc/acpi/processor/../performance
> interface. While it is helpful for debugging, the generic,
>---
>linux-2.6.20-mm1/arch/i386/kernel/cpu/cpufreq/speedstep-centrin
o.c.old 2007-02-17 23:29:53.0 +0100
>+++
>linux-2.6.20-mm1/arch/i386/kernel/cpu/cpufreq/speedstep-cen
trino.c 2007-02-17 23:30:44.0 +0100
>@@ -21,12 +21,6 @@
> #include
> #include
>
>-#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI
>-#include
>-#include
>-#include
>-#endif
>-
> #include
> #include
> #include
>@@ -257,9 +251,7 @@
> /* Matched a non-match */
> dprintk("no table support for CPU model \"%s\"\n",
> cpu->x86_model_id);
>-#ifndef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI
>- dprintk("try compiling with
>CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI enabled\n");
>-#endif
>+ dprintk("try using the acpi-cpufreq driver\n");
> return -ENOENT;
> }
>
>@@ -346,213 +338,6 @@
> }
>
>
>-#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI
>-
>-static struct acpi_processor_performance *acpi_perf_data[NR_CPUS];
>-
>-/*
>- * centrino_cpu_early_init_acpi - Do the preregistering with
>ACPI P-States
>- * library
>- *
>- * Before doing the actual init, we need to do _PSD related
>setup whenever
>- * supported by the BIOS. These are handled b
Re: [PATCH] USB Elan FTDI: check for workqueue creation v2
On Sat, Feb 24, 2007 at 01:46:44PM +0100, Oleg Verych wrote: | > From: Cyrill Gorcunov | > Newsgroups: gmane.linux.kernel | > Subject: bss zeroing ([PATCH] USB Elan FTDI: check for workqueue creation v2) | > Date: Sat, 24 Feb 2007 10:41:15 +0300 | [] | > Btw, Pete, you are right! C99 ANSI standart says that static pointer | > if it not initialized explicitly has to be set to NULL by compiler ;) | > Thanks a lot for comments and Ack the patch please. | | Are you sure about "by compiler"? I mean, why not by OS, in case of uCs | by code/data memory image generator? | | | I don't think that is the point... C compiler may put that data to a special section of image (which is to be filled by zero) or add a few explicit instructions... I don't care the method for a while, I need the result ;) Cyrill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [QUESTION] Sata RAID
use device mapper and dmraid http://people.redhat.com/~heinzm/sw/dmraid/ and please read http://linux-ata.org/faq-sata-raid.html On Saturday 24 February 2007, Patrick Ale wrote: > Hi, > > Quick question, > > Since I am going to open my server today to do some pata tests (for > the weird detection problems people are giving me fantastic help with, > no sarcasm, I really mean it) I thought: why not add two 320GB SATA > disks on the SATA controller that the mainboard has. > > I am wondering: should I use the onboard RAID function? Is this > supported by Linux? I remember back in "the old days (TM)" there were > seperate (spelling) drivers for ataraid, how does the current 2.6 > branch cope with the RAID functions of modern motherboards? > > I am aware that it is NOT hardware raid, the raid is done in the > driver, which is why you need this fancy boot disk before installing > Windows on your RAID set. > > Or would you suggest me to stick with MD devices? > > > Cheers, > > Patrick Ale > [EMAIL PROTECTED] > > "kun kasvan isoksi, halun olla poro" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
round_jiffies and load average
I've modified the driver of an USB device (cxacru) to schedule the next poll for status every 1s using round_jiffies_relative instead of just waiting 1s since the last poll was completed. This process takes on average 11ms to complete and while it is waiting for a response it's considered running. The load average is calculated every 5 seconds equivalent to round_jiffies, so I have a problem with the load average always tending towards 1.00: 14:26:19 up 6 days, 14:45, 5 users, load average: 1.10, 1.04, 1.02 14:27:19 up 6 days, 14:46, 5 users, load average: 1.03, 1.03, 1.01 14:28:19 up 6 days, 14:47, 5 users, load average: 0.95, 1.01, 1.00 14:29:19 up 6 days, 14:48, 5 users, load average: 0.90, 0.97, 0.99 14:30:19 up 6 days, 14:49, 5 users, load average: 0.93, 0.96, 0.98 14:31:19 up 6 days, 14:50, 5 users, load average: 0.90, 0.94, 0.97 14:32:20 up 6 days, 14:51, 5 users, load average: 0.96, 0.95, 0.97 14:33:20 up 6 days, 14:52, 5 users, load average: 0.98, 0.95, 0.97 14:34:20 up 6 days, 14:53, 5 users, load average: 1.09, 0.99, 0.98 14:35:20 up 6 days, 14:54, 5 users, load average: 1.03, 0.99, 0.98 14:36:20 up 6 days, 14:55, 5 users, load average: 1.01, 0.99, 0.98 14:37:20 up 6 days, 14:56, 5 users, load average: 1.00, 0.99, 0.98 14:38:21 up 6 days, 14:57, 5 users, load average: 1.22, 1.05, 1.00 14:39:21 up 6 days, 14:58, 5 users, load average: 1.08, 1.04, 1.00 14:40:21 up 6 days, 14:59, 5 users, load average: 1.03, 1.03, 1.00 14:41:21 up 6 days, 15:00, 5 users, load average: 0.95, 1.01, 0.99 14:42:21 up 6 days, 15:01, 5 users, load average: 0.90, 0.97, 0.98 14:43:21 up 6 days, 15:02, 5 users, load average: 0.99, 0.99, 0.99 14:44:22 up 6 days, 15:03, 5 users, load average: 0.86, 0.94, 0.97 14:45:22 up 6 days, 15:04, 5 users, load average: 0.97, 0.95, 0.97 14:46:22 up 6 days, 15:05, 5 users, load average: 1.08, 0.99, 0.98 14:47:22 up 6 days, 15:06, 5 users, load average: 1.03, 0.99, 0.98 14:48:22 up 6 days, 15:07, 5 users, load average: 1.32, 1.07, 1.01 Perhaps the load average count could be run just before or in the middle of a second instead? -- Simon Arlott signature.asc Description: OpenPGP digital signature
Re: module-init-tools-3.3-pre10 available
On Feb 23 2007 10:41, Jon Masters wrote: > > I think it's like the configure/Makefile.in situation. These files should > technically not be in the repo either (and you removed them in your tree) but > I > re-added them because people have an expectation that: > > ./configure > make > > will do something "out of the box". Out of the box perhaps if it is the .tar.bz2 archive, but the same does not always hold for CVS repos, much less SVNs [random guess on svn]. He who pulls from a developer tree mostly knows to run 'autogen.sh' or 'autoreconf -fi' beforehand. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/mfd/sm501.c: Replace pci_module_init with pci_register_driver
On Sat, Feb 24, 2007 at 11:46:06AM +0100, Richard Knutsson wrote:
> Replace pci_module_init with pci_register_driver
Thankyou for spotting this.
> Signed-off-by: Richard Knutson <[EMAIL PROTECTED]>
Acked-by: Ben Dooks <[EMAIL PROTECTED]>
> ---
> Compile-tested with "allyes", "allmod" & "allno" on i386
>
> diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
> index 5c5a1e2..c707c8e 100644
> --- a/drivers/mfd/sm501.c
> +++ b/drivers/mfd/sm501.c
> @@ -1131,7 +1131,7 @@ static struct platform_driver sm501_plat_drv = {
> static int __init sm501_base_init(void)
> {
> platform_driver_register(&sm501_plat_drv);
> - return pci_module_init(&sm501_pci_drv);
> + return pci_register_driver(&sm501_pci_drv);
> }
>
> static void __exit sm501_base_exit(void)
--
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.16.41 & 2.6.18.7 OK, 2.6.19.5 NOT, 2.6.18.8 KERNEL PANIC
2.6.18.7 vanilla & 2.6.16.41 vanilla: /dev/hda CD/DVD /dev/hda1 / IDE HD 160GB /dev/hda2 swap /dev/sda1 /xyz SATA HD 320GB /dev/sda2 swap /dev/sdb1 /zzz SATA HD 320GB /dev/sdb2 swap /dev/sdc1 /usb USB KEY 512MB all 100% OK since 12-Dec-2006 2.6.19.5 vanilla: /dev/hda, /dev/hdb OK fsck 1.38 (30-Jun-2005) /dev/sda1: clean 2960/125696 files, 12379/125692 blocks but /dev/sda1 is only partially mounted, du -hs says 33M ... /sbin/e2fsck: No such file or directory while trying to open /dev/sdb1 ... same for /dev/sdc1 ... swapon: cannot stat /dev/sda2: No such file or directory same for /dev/sdb2, so only 2GB swap, not 6GB --- 2.6.18.8 vanilla: !!! screen eating leftmost characters, then kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,65) POWER SWITCH ultima ratio --- all 4 kernels same .config from 2.6.18.6, make oldconfig, Enter on all new questions AUSUS P4R800V, P4HT3400, 2GB mem Slackware 11.0, udev-105, gcc-3.4.6, glibc-2.3.6, all ext2 4096 formated Rebooting 2.6.18.7 vanilla: all devices OK, 6GB swap FEEDBACK ONLY, _not_ in LMKL Kind regards Mario Vanoni - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MOST(Media Oriented Systems Transport) Interface?
On Fri 23 Feb 2007 20:47, Rik van Riel wrote: > Robin Getz wrote: > > Does anyone have a pointer for a MOST (Media Oriented Systems Transport) > > driver? > > Are there any applications that use that protocol? Many - all automotive embedded - If you drive a recent car - from Audi, Aston Martin, Ford, BMW, Honda, Hyundai/Kia, DaimlerChrysler, Jaguar, Land Rover, Nissan, Porsche, Toyota, Volvo, or VW - you may be using it today. > Specifically, any applications worth caring about? Again - depends on who you are. If you are one of the above - yes, you care allot. If you are a enthusiast you wants low level access to entertainment system in your car - then you care too. It is like asking if I should care about applications using 100Base-T - as a user - I just want it to work and I only care when it doesn't work; as a driver developer - I care alot, but am agnostic to the application. I found a spec that says MOST runs IP - http://www.mostcooperation.com/downloads/Specifications/MOST%20Specifications/MAMAC%20Specification but thought I would ask if anyone else has any public work about the non-IP protocols. For those that might care, full spec is at: http://www.mostcooperation.com/downloads/Specifications/MOST%20Specifications/MOSTSpecification.pdf -Robin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] scsi: eata.c potential namespace collision and optimisation
This fixes a potential namespace collision and does an optimisation for
2.6.20 drivers/scsi/eata.c:
* sort() is renamed to eata_sort() to avoid conflict with kernel
proper sort(). It does _not_ conflict currently in 2.6.20 so
this is a pre-emptive change.
* in eata_sort(), one if-condition per loop iteration is avoided
by moving the comparison out of the loop
Warning: The patch compiles but is not tested with real hardware since I
don't have the card.
diffstat:
eata.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
Signed-off-by: Heikki Orsila <[EMAIL PROTECTED]>
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] "Math is hard, let's go shopping!"
http://www.iki.fi/shd
diff -upr linux-2.6.20-org/drivers/scsi/eata.c linux-2.6.20/drivers/scsi/eata.c
--- linux-2.6.20-org/drivers/scsi/eata.c2007-02-04 20:44:54.0
+0200
+++ linux-2.6.20/drivers/scsi/eata.c2007-02-24 15:43:08.0 +0200
@@ -2089,8 +2089,8 @@ int eata2x_bios_param(struct scsi_device
return 0;
}
-static void sort(unsigned long sk[], unsigned int da[], unsigned int n,
-unsigned int rev)
+static void eata_sort(unsigned long sk[], unsigned int da[], unsigned int n,
+ unsigned int rev)
{
unsigned int i, j, k, y;
unsigned long x;
@@ -2098,14 +2098,17 @@ static void sort(unsigned long sk[], uns
for (i = 0; i < n - 1; i++) {
k = i;
- for (j = k + 1; j < n; j++)
- if (rev) {
+ if (rev) {
+ for (j = k + 1; j < n; j++) {
if (sk[j] > sk[k])
k = j;
- } else {
+ }
+ } else {
+ for (j = k + 1; j < n; j++) {
if (sk[j] < sk[k])
k = j;
}
+ }
if (k != i) {
x = sk[k];
@@ -2116,8 +2119,6 @@ static void sort(unsigned long sk[], uns
da[i] = y;
}
}
-
- return;
}
static int reorder(struct hostdata *ha, unsigned long cursec,
@@ -2194,7 +2195,7 @@ static int reorder(struct hostdata *ha,
rev = 0;
if (!((rev && r) || (!rev && s)))
- sort(sl, il, n_ready, rev);
+ eata_sort(sl, il, n_ready, rev);
if (!input_only)
for (n = 0; n < n_ready; n++) {
@@ -2214,7 +2215,7 @@ static int reorder(struct hostdata *ha,
}
if (overlap)
- sort(pl, il, n_ready, 0);
+ eata_sort(pl, il, n_ready, 0);
if (link_statistics) {
if (cursec > sl[0])
Re: (Sparc64) 2.6.20 seems to ignore initramfs
On Feb 23 2007 15:47, Andrew Walrond wrote: >On Friday 23 February 2007 15:17, Tomasz Chmielewski wrote: >> >> Try to decrease the initramfs size just to know if it boots correctly. >> >> I.e., put just a sh/bash/ash/dash binary there (probably /dev/console >> node, too), executed in init. >> >> Then, try to start the kernel with initramfs embedded in the kernel, >> then as initrd etc. - this will show if the fault is on your side, or >> kernel's. > >I have tracked this down to a broken version of gnu cpio (latest release, 2.7) >which was used to create the initramfs archive. Bloody annoying since this >has bitten me before! Last time I even sent the maintainer a bug report, and >apparently a fix is in CVS waiting for the next release. Ho hum. Forgot the -c flag, right? Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ioctls.h (Re: [PATCH][RFC] Make asm-generic/ioctl.h extensible by adding conditionals.)
On Sat, 24 Feb 2007, Oleg Verych wrote: > > From: "Robert P. J. Day" > > Newsgroups: gmane.linux.kernel > > Subject: [PATCH][RFC] Make asm-generic/ioctl.h extensible by adding > > conditionals. > > Date: Sat, 24 Feb 2007 06:45:20 -0500 (EST) > > > as a followup to my earlier post, is it worth making this change > > to allow at least a couple arch-specific ioctl.h files to be > > massively simplified? > > And i wonder, why there is no generic ioctls.h, hm? beats me, but it seems that there are a *number* of arch-specific header files that could be treated this way -- a single generic file, allowing the small number of customizations that seem to be necessary across all architectures. but i figured i'd start with ioctl.h first and see where it went from there. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: module-init-tools-3.3-pre10 available
Jan Engelhardt wrote: Out of the box perhaps if it is the .tar.bz2 archive, but the same does not always hold for CVS repos, much less SVNs [random guess on svn]. He who pulls from a developer tree mostly knows to run 'autogen.sh' or 'autoreconf -fi' beforehand. You know what, you're right of course. Ok, I'm taking those back *out* of the repo in the next update and then will have a script generate these for the tarball. That does sound like the right thing. Thanks! Jon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] Fast assurate clock readable from user space and NMI handler
Hi,
I am trying to improve the Linux kernel time source so it can be read
without seqlock from NMI handlers. I have also seen some interest for
such an accurate monotonic clock readable from user space. It mainly
implies an atomic update of the time value. I am also trying to figure a
way to support architectures with multiple CPUs with non-synchronized
TSCs.
I would like to have your comments on the following idea.
Thanks in advance,
Mathieu
Monotonic accurate time
The goal of this design is to provide a monotonic time :
Readable from userspace without a system call
Readable from NMI handler
Readable without disabling interrupts
Readable without disabling preemption
Only one clock source (most precise available : tsc)
Support architectures with variable TSC frequency.
Main difference with wall time currently implemented in the Linux kernel : the
time update is done atomically instead of using a write seqlock. It permits
reading time from NMI handler and from userspace.
struct time_info {
u64 tsc;
u64 freq;
u64 walltime;
}
static struct time_struct {
struct time_info time_sel[2];
long update_count;
}
DECLARE_PERCPU(struct time_struct, cpu_time);
/* Number of times the scheduler is called on each CPU */
DECLARE_PERCPU(unsigned long, sched_nr);
/* On frequency change event */
/* In irq context */
void freq_change_cb(unsigned int new_freq)
{
struct time_struct this_cpu_time =
per_cpu(cpu_time, smp_processor_id());
struct time_info *write_time, *current_time;
write_time =
this_cpu_time->time_sel[(this_cpu_time->update_count+1)&1];
current_time =
this_cpu_time->time_sel[(this_cpu_time->update_count)&1];
write_time->tsc = get_cycles();
write_time->freq = new_freq;
/* We cumulate the division imprecision. This is the downside of using
* the TSC with variable frequency as a time base. */
write_time->walltime =
current_time->walltime +
(write_time->tsc - current_time->tsc) /
current_time->freq;
wmb();
this_cpu_time->update_count++;
}
/* Init cpu freq */
init_cpu_freq()
{
struct time_struct this_cpu_time =
per_cpu(cpu_time, smp_processor_id());
struct time_info *current_time;
memset(this_cpu_time, 0, sizeof(this_cpu_time));
current_time = this_cpu_time->time_sel[this_cpu_time->update_count&1];
/* Init current time */
/* Get frequency */
/* Reset cpus to 0 ns, 0 tsc, start their tsc. */
}
/* After a CPU comes back from hlt */
/* The trick is to sync all the other CPUs on the first CPU up when they come
* up. If all CPUs are down, then there is no need to increment the walltime :
* let's simply define the useful walltime on a machine as the time elapsed
* while there is a CPU running. If we want, when no cpu is active, we can use
* a lower resolution clock to somehow keep track of walltime. */
wake_from_hlt()
{
/* TODO */
}
/* Read time from anywhere in the kernel. Return time in walltime. (ns) */
/* If the update_count changes while we read the context, it may be invalid.
* This would happen if we are scheduled out for a period of time long enough to
* permit 2 frequency changes. We simply start the loop again if it happens.
* We detect it by comparing the update_count running counter.
* We detect preemption by incrementing a counter sched_nr within schedule().
* This counter is readable by user space through the vsyscall page. */
*/
u64 read_time(void)
{
u64 walltime;
long update_count;
struct time_struct this_cpu_time;
struct time_info *current_time;
unsigned int cpu;
long prev_sched_nr;
do {
cpu = _smp_processor_id();
prev_sched_nr = per_cpu(sched_nr, cpu);
if(cpu != _smp_processor_id())
continue; /* changed CPU between CPUID and getting
sched_nr */
this_cpu_time = per_cpu(cpu_time, cpu);
update_count = this_cpu_time->update_count;
current_time = this_cpu_time->time_sel[update_count&1];
walltime = current_time->walltime +
(get_cycles() - current_time->tsc) /
current_time->freq;
if(per_cpu(sched_nr, cpu) != prev_sched_nr)
continue; /* been preempted */
} while(this_cpu_time->update_count != update_count);
return walltime;
}
/* Userspace */
/* Export all this data to user space through the vsyscall page. Use a function
* like read_time to read the walltime. This function can be implemented as-is
* because it doesn't need to disable preemption. */
--
Mathieu Desnoyers
Computer Engineering Ph.D. Ca
Re: ioctls.h (Re: [PATCH][RFC] Make asm-generic/ioctl.h extensible by adding conditionals.)
On Sat, Feb 24, 2007 at 10:59:42AM -0500, Robert P. J. Day wrote: > On Sat, 24 Feb 2007, Oleg Verych wrote: > > > > From: "Robert P. J. Day" > > > Newsgroups: gmane.linux.kernel > > > Subject: [PATCH][RFC] Make asm-generic/ioctl.h extensible by adding > > > conditionals. > > > Date: Sat, 24 Feb 2007 06:45:20 -0500 (EST) > > > > > as a followup to my earlier post, is it worth making this change > > > to allow at least a couple arch-specific ioctl.h files to be > > > massively simplified? > > > > And i wonder, why there is no generic ioctls.h, hm? > > beats me, but it seems that there are a *number* of arch-specific > header files that could be treated this way -- a single generic file, > allowing the small number of customizations that seem to be necessary > across all architectures. > > but i figured i'd start with ioctl.h first and see where it went from > there. Indeed. Thank you! > -- > > Robert P. J. Day > Linux Consulting, Training and Annoying Kernel Pedantry > Waterloo, Ontario, CANADA > > http://fsdev.net/wiki/index.php?title=Main_Page > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ipv4 and ipv6 stacks for new link layers?
> This is a pity, because it would be so easy to make the both stacks > totally independent of the actual link layers. It only needs one (or > two) new function pointer in net_device. This function should do the > conversion from IPv4/IPv6 address into corresponding hardware > multicast/broadcast address. You mean, the link layer drivers should know of IP addressing modes? Sounds like a layering violation to me. The mapping from IP to MAC address is (for a good reason) part of the IP specs, not of the Ethernet, Token Ring etc. specs, so the right place to implement it is not the network drivers. Olaf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ipv4 and ipv6 stacks for new link layers?
> > > This is a pity, because it would be so easy to make the both stacks > > totally independent of the actual link layers. It only needs one (or > > two) new function pointer in net_device. This function should do the > > conversion from IPv4/IPv6 address into corresponding hardware > > multicast/broadcast address. > > You mean, the link layer drivers should know of IP addressing modes? > Sounds like a layering violation to me. The mapping from IP to MAC > address is (for a good reason) part of the IP specs, not of the > Ethernet, Token Ring etc. specs, so the right place to implement it is > not the network drivers. I disagree. In current architecture, you have to patch kernel IPv6 and IPv4 protocols when you add new link layer that they don't recognize. I think that is worse than allow a new driver to provide a simple service function which maps IPv4/6 multicast address into link layer address, when asked. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: input.c: start on release
On Friday 23 February 2007 19:44, Pete Zaitcev wrote:
> On Fri, 23 Feb 2007 10:06:14 -0500, "Dmitry Torokhov" <[EMAIL PROTECTED]>
> wrote:
> > On 2/23/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
>
> > > void input_release_device(struct input_handle *handle)
> > > {
> > >
> > >if (handle->handler->start)
> > >handle->handler->start(handle);
>
> > It should be ->start(). You are probably confused a little by the name
> > of the function. input_release_device() is called when userspace
> > issues ioctl(fd, EVIOCGRAB, 0) releasing (or ungrabbing) the device
> > (as opposed to xxx_release(file, inode) type functions that are called
> > when last user of a file drops off). In our case we want to give
> > handlers a chance to resume their control over device. Right now
> > standard keyboard driver uses start method do bring back in sync LED
> > state of a keyborad-like device after it was released (ungrabbed).
>
> Thanks for the explanation. I suspect people asked you 100 times before.
> I can see why we would want to do this when a grab ends, but why do
> we do this on every close of /dev/input/mice? The call path is:
>
> mousedev_release ->
> mixdev_release (optional for some majors)
> input_close_device ->
> input_release_device
>
The actual work withing input_release_device happens only when called
for handle that grabbed the device earlier. The reason why we call it
when closing a device so that device is not left in grabbed state if
userspace forgot to release it voluntarily.
> Same thing happens upon disconnect, though this is probably harmless,
> as the device is gone already anyway.
>
> To tell you the truth, all I really want is to hold a static mutex
> across a call to input_close_device(). Can I do that?
Are you trying to fix locking in mousedev?
--
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: [QUESTION] Sata RAID
But using 'fakeraid' (i.e. BIOS RAID) together with dmraid is generally discouraged in favour of using the more stable and well supported Linux Software RAID functionality. Michael-Luke On 24 Feb 2007, at 15:24, Bartlomiej Zolnierkiewicz wrote: use device mapper and dmraid http://people.redhat.com/~heinzm/sw/dmraid/ and please read http://linux-ata.org/faq-sata-raid.html On Saturday 24 February 2007, Patrick Ale wrote: Hi, Quick question, Since I am going to open my server today to do some pata tests (for the weird detection problems people are giving me fantastic help with, no sarcasm, I really mean it) I thought: why not add two 320GB SATA disks on the SATA controller that the mainboard has. I am wondering: should I use the onboard RAID function? Is this supported by Linux? I remember back in "the old days (TM)" there were seperate (spelling) drivers for ataraid, how does the current 2.6 branch cope with the RAID functions of modern motherboards? I am aware that it is NOT hardware raid, the raid is done in the driver, which is why you need this fancy boot disk before installing Windows on your RAID set. Or would you suggest me to stick with MD devices? Cheers, Patrick Ale [EMAIL PROTECTED] "kun kasvan isoksi, halun olla poro" - To unsubscribe from this list: send the line "unsubscribe linux- kernel" in the body of a message 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: [QUESTION] Sata RAID
On 2/24/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote: But using 'fakeraid' (i.e. BIOS RAID) together with dmraid is generally discouraged in favour of using the more stable and well supported Linux Software RAID functionality. Michael-Luke I think I actually used dmraid, and the problem I had in those days was that it was just a layer over your legacy IDE drivers. With 2.4 you had "real" drivers whom created block devices if I recall correctly which you could really treat as disks. If dmraid still works as it did in the days I used it it's just a layer, like LVM, and the kernel itself doesnt care at all for the disks being in a RAID set or not and will access the disks independently, this I really found a reason to not use dmraid and stick with MD devices. And by the reactions from you guys I guess those reasons still exist :) So MD it is, Thanks! Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel warning from Matrox Framebuffer in 2.6.20.1
On Saturday 24 February 2007 14:08, Chris Rankin wrote: > Hi, > > I have just booted 2.6.20.1 on my Pentium 3 machine, which has a G400 MAX > graphics card. This machine uses the Matrox framebuffer and TV-OUT modules, > and I have found these warnings in the kernel log: > > **WARNING** I2C adapter driver [DDC:fb0 #0] forgot to specify physical > device; fix it! **WARNING** I2C adapter driver [DDC:fb0 #1] forgot to > specify physical device; fix it! **WARNING** I2C adapter driver [MAVEN:fb0] > forgot to specify physical device; fix it! I'm seeing something like that since installing 2.6.20.1 yesterday: matroxfb: Matrox Mystique (PCI) detected PInS memtype = 0 matroxfb: MTRR's turned on matroxfb: 1024x768x8bpp (virtual: 1024x4096) matroxfb: framebuffer at 0xE100, mapped to 0xcc88, size 4194304 Console: switching to colour frame buffer device 128x48 fb0: MATROX frame buffer device **WARNING** I2C adapter driver [DDC:fb0 #0] forgot to specify physical device; fix it! > The relevant kernel modules seem to be: > > matroxfb_maven 13228 0 > i2c_matroxfb4064 0 > i2c_algo_bit6312 1 i2c_matroxfb > > Cheers, > Chris -- Ondrej Zary - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SLUB: The unqueued Slab allocator
On Fri, 23 Feb 2007, David Miller wrote: > > The general caches already merge lots of users depending on their sizes. > > So we already have the situation and we have tools to deal with it. > > But this doesn't happen for things like biovecs, and that will > make debugging painful. > > If a crash happens because of a corrupted biovec-256 I want to know > it was a biovec not some anonymous clone of kmalloc256. > > Please provide at a minimum a way to turn the merging off. Ok. Its currently a compile time option. Will make it possible to specify a boot option. > I also agree with Andi in that merging could mess up how object type > local lifetimes help reduce fragmentation in object pools. If that is a problem for particular object pools then we may be able to except those from the merging. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system
Hi folks, Second attempt now: I already reported to Linus Torvalds and Andrew Morton that it is impossible to mount a conventional floppy drive without hanging up the whole system. Andrew's reaction was quite ambiguous: "We did not break it" Once again and for the last time: I do not state that floppy.c is broken. I only state that it is immpossible to mount a floppy drive with kernel 2.6.21-rc1-git1. Kernel 2.6.20 is OK. But 2.6.21-rc1-git1 is definitely buggy! I did some work already: a. I copied the following modules from the intact and sane kernel 2.6.20 into the 2.6.21-rc1-git1 tree: cdrom.h, floppy.c, init.h, io.h, proc_misc.c, setup.c, timer.h, uaccess.h b. I adjusted some hunks of the patch for module main.c (part of patch-2.6.21-rc1) to make the kernel compile without errors. But the problem still persists, and I do not have any idea anymore where the offensive hunks in patch-2.6.21-rc1 could reside. Questions: a. Can someone please confirm the described problem? b. Can someone please take action to find out where the buggy code resides? c. Why is this untested material being pushed into main vanilla - what is going on at kernel.org please? Please take action! The bug was introduced somewhere at the transition of 2.6.20 towards 2.6.20-git14. Yours sincerely Uwe P. S.: I once again repeat my proposal: Every patch code should be tested before it is being pushed into main vanilla. The testing tree is the mm-tree. If this policy producing regressions persists noone takes advantage of! So please avoid those regressions in future! If this rule "test your changes, however small, on at least 4 or 5 people" does not apply to absolutely everybody then it is worth nothing! My platform is i386, Intel ICH4 and I am using floppy.c (Normal floppy disk support). -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Fast assurate clock readable from user space and NMI handler
On Sat, 2007-02-24 at 11:19 -0500, Mathieu Desnoyers wrote:
> Hi,
>
> I am trying to improve the Linux kernel time source so it can be read
> without seqlock from NMI handlers. I have also seen some interest for
> such an accurate monotonic clock readable from user space. It mainly
> implies an atomic update of the time value. I am also trying to figure a
> way to support architectures with multiple CPUs with non-synchronized
> TSCs.
>
> I would like to have your comments on the following idea.
>
> Thanks in advance,
>
> Mathieu
>
>
> Monotonic accurate time
>
> The goal of this design is to provide a monotonic time :
>
> Readable from userspace without a system call
> Readable from NMI handler
> Readable without disabling interrupts
> Readable without disabling preemption
> Only one clock source (most precise available : tsc)
> Support architectures with variable TSC frequency.
I don't think you could use only the tsc. From reviewing John, and
Thomas work it's pretty clear the TSC isn't going to work correctly all
the time.
> /* On frequency change event */
> /* In irq context */
> void freq_change_cb(unsigned int new_freq)
> {
It's possible for the TSC to change frequencies without notification. It
can also completely stop when the system goes idle.
> /* Userspace */
> /* Export all this data to user space through the vsyscall page. Use a
> function
> * like read_time to read the walltime. This function can be implemented as-is
> * because it doesn't need to disable preemption. */
What would be the benefit of using this over the vsyscall gettimeofday()
from userspace ?
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system
> On Sat, 24 Feb 2007 18:54:24 +0100 "Uwe Bugla" <[EMAIL PROTECTED]> wrote: > Hi folks, > Second attempt now: > I already reported to Linus Torvalds and Andrew Morton that it is impossible > to mount a conventional floppy drive without hanging up the whole system. > Andrew's reaction was quite ambiguous: "We did not break it" Sorry, what I meant was "Neither Linus nor I broke it". ie: please report this in a place where the person who did break it can see it. This you have done. > Once again and for the last time: I do not state that floppy.c is broken. I > only state that it is immpossible to mount a floppy drive with kernel > 2.6.21-rc1-git1. Kernel 2.6.20 is OK. But 2.6.21-rc1-git1 is definitely buggy! > I did some work already: > a. I copied the following modules from the intact and sane kernel 2.6.20 into > the 2.6.21-rc1-git1 tree: > cdrom.h, floppy.c, init.h, io.h, proc_misc.c, setup.c, timer.h, uaccess.h > b. I adjusted some hunks of the patch for module main.c (part of > patch-2.6.21-rc1) to make the kernel compile without errors. > But the problem still persists, and I do not have any idea anymore where the > offensive hunks in patch-2.6.21-rc1 could reside. > > Questions: > a. Can someone please confirm the described problem? > b. Can someone please take action to find out where the buggy code resides? > c. Why is this untested material being pushed into main vanilla - what is > going on at kernel.org please? > > Please take action! The bug was introduced somewhere at the transition of > 2.6.20 towards 2.6.20-git14. > I think we'll find that it works OK for hundreds of other people, so it got broken in some manner which is specific to a very small number of machines, of which yours is one. If that theory proves to be correct, I'm afraid that the most proactical way of fixing this is to ask you to run a git-bisect to find the changeset which introduced the regression. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system
Original-Nachricht Datum: Sat, 24 Feb 2007 10:07:29 -0800 Von: Andrew Morton <[EMAIL PROTECTED]> An: "Uwe Bugla" <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system > > On Sat, 24 Feb 2007 18:54:24 +0100 "Uwe Bugla" <[EMAIL PROTECTED]> wrote: > > Hi folks, > > Second attempt now: > > I already reported to Linus Torvalds and Andrew Morton that it is > impossible to mount a conventional floppy drive without hanging up the whole > system. > > Andrew's reaction was quite ambiguous: "We did not break it" > > Sorry, what I meant was "Neither Linus nor I broke it". ie: please report > this in a place where the person who did break it can see it. This you > have > done. OK, accepted - sorry! > > > Once again and for the last time: I do not state that floppy.c is > broken. I only state that it is immpossible to mount a floppy drive with > kernel > 2.6.21-rc1-git1. Kernel 2.6.20 is OK. But 2.6.21-rc1-git1 is definitely > buggy! > > I did some work already: > > a. I copied the following modules from the intact and sane kernel 2.6.20 > into the 2.6.21-rc1-git1 tree: > > cdrom.h, floppy.c, init.h, io.h, proc_misc.c, setup.c, timer.h, > uaccess.h > > b. I adjusted some hunks of the patch for module main.c (part of > patch-2.6.21-rc1) to make the kernel compile without errors. > > But the problem still persists, and I do not have any idea anymore where > the offensive hunks in patch-2.6.21-rc1 could reside. > > > > Questions: > > a. Can someone please confirm the described problem? > > b. Can someone please take action to find out where the buggy code > resides? > > c. Why is this untested material being pushed into main vanilla - what > is going on at kernel.org please? > > > > Please take action! The bug was introduced somewhere at the transition > of 2.6.20 towards 2.6.20-git14. > > > > I think we'll find that it works OK for hundreds of other people, so it > got > broken in some manner which is specific to a very small number of > machines, > of which yours is one. > > If that theory proves to be correct, I'm afraid that the most proactical > way of fixing this is to ask you to run a git-bisect to find the changeset > which introduced the regression. Guess this theory is wrong but lets wait and see to prove who is right! > OK, Andrew, Problem: I do not have internet at home, I am sitting in a friends flat now. So you cannot expect me to download all git patches of 2.6.20 to test. Could you please explain the procedure of bisecting? Above that I've spent hours to find out the essence of the problem and I am really beat to the bone! And my linuxtv patches should be ported into kernel please, with or without Abraham, with or without Chehab. I swear you that they are OK and not buggy at all. It is the wrong policy to execute protectionism on people having lots of administration power but in reality lacking the experience, who are not able to tolerate justified criticism. I enjoyed Gerd and I enjoyed most of all german guys of the convergence crew. Those were real fine and honest people, especially Gerd himself. Sincerely Uwe -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (Sparc64) 2.6.20 seems to ignore initramfs
On Saturday 24 February 2007 15:23, Jan Engelhardt wrote: > On Feb 23 2007 15:47, Andrew Walrond wrote: > > > >I have tracked this down to a broken version of gnu cpio (latest release, > > 2.7) which was used to create the initramfs archive. Bloody annoying > > since this has bitten me before! Last time I even sent the maintainer a > > bug report, and apparently a fix is in CVS waiting for the next release. > > Ho hum. > > Forgot the -c flag, right? > No, I use '-H newc' as per the instrucions in Documentation/filesystems/ramfs-rootfs-initramfs.txt. Does -c do the same thing? [checks man cpio...] But there is a real bug in cpio 2.7 which can break the archive. Its been fixed in cpio cvs awaiting the next release. My report to the cpio ML: Hello list, I've been experimenting with large (500Mb) initramfs cpio archives on linux, x86_64, using cpio 2.7, compiled 64bit with gcc4.1.1. If I create a cpio archive, then extract it and compare with the original, I see broken symlinks. I don't know if the archives themselves are corrupt, or whether the extraction code is broken, but I guess you guys can work that out. An example: [EMAIL PROTECTED] initramfs $ cd rootfs [EMAIL PROTECTED] rootfs $ find . | cpio -o -H newc > ../rootfs.cpio 857030 blocks [EMAIL PROTECTED] rootfs $ cd .. [EMAIL PROTECTED] initramfs $ mkdir tmp [EMAIL PROTECTED] initramfs $ cd tmp [EMAIL PROTECTED] tmp $ cpio -i -d -H newc -F ../rootfs.cpio --no-absolute-filenames 857030 blocks [EMAIL PROTECTED] tmp $ ll ../rootfs/pkg/linux/lib/modules/2.6.19.2/ total 1.1M lrwxrwxrwx 1 root root 17 Jan 11 13:39 build -> /pkg/linux/source drwxrwxr-x 11 root root 4.0K Jan 11 11:14 kernel -rw-rw-r-- 1 root root 229K Jan 11 11:14 modules.alias -rw-rw-r-- 1 root root 69 Jan 11 11:14 modules.ccwmap -rw-rw-r-- 1 root root 246K Jan 11 11:14 modules.dep -rw-rw-r-- 1 root root 813 Jan 11 11:14 modules.ieee1394map -rw-rw-r-- 1 root root 788 Jan 11 11:14 modules.inputmap -rw-rw-r-- 1 root root 2.6K Jan 11 11:14 modules.isapnpmap -rw-rw-r-- 1 root root 74 Jan 11 11:14 modules.ofmap -rw-rw-r-- 1 root root 161K Jan 11 11:14 modules.pcimap -rw-rw-r-- 1 root root 967 Jan 11 11:14 modules.seriomap -rw-rw-r-- 1 root root 100K Jan 11 11:14 modules.symbols -rw-rw-r-- 1 root root 306K Jan 11 11:14 modules.usbmap lrwxrwxrwx 1 root root 17 Jan 11 13:39 source -> /pkg/linux/source [EMAIL PROTECTED] tmp $ ll pkg/linux/lib/modules/2.6.19.2/ total 1.1M lrwxrwxrwx 1 root root 23 Jan 12 12:08 build -> /pkg/linux/sourceodules drwxrwxr-x 11 root root 4.0K Jan 12 12:08 kernel -rw-rw-r-- 1 root root 229K Jan 12 12:08 modules.alias -rw-rw-r-- 1 root root 69 Jan 12 12:08 modules.ccwmap -rw-rw-r-- 1 root root 246K Jan 12 12:08 modules.dep -rw-rw-r-- 1 root root 813 Jan 12 12:08 modules.ieee1394map -rw-rw-r-- 1 root root 788 Jan 12 12:08 modules.inputmap -rw-rw-r-- 1 root root 2.6K Jan 12 12:08 modules.isapnpmap -rw-rw-r-- 1 root root 74 Jan 12 12:08 modules.ofmap -rw-rw-r-- 1 root root 161K Jan 12 12:08 modules.pcimap -rw-rw-r-- 1 root root 967 Jan 12 12:08 modules.seriomap -rw-rw-r-- 1 root root 100K Jan 12 12:08 modules.symbols -rw-rw-r-- 1 root root 306K Jan 12 12:08 modules.usbmap lrwxrwxrwx 1 root root 23 Jan 12 12:08 source -> /pkg/linux/sourceodules [EMAIL PROTECTED] tmp $ The extra 'odules' is suspiciously like 'modules'... I am now using version 2.6 with debian patches to 2.6-17, and this works fine. I've tried making a small test case, but it only seems to occur with my large (500Mb) root filesystem archives. If I just archive the modules directory in the example above, the corruption does not occur. Anyhow; if I can do anything to chase this down further, let me know. I have joined the ML. Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 18/29] netfilter: notify about NF_QUEUE vs emergency skbs
Peter Zijlstra wrote:
> Emergency skbs should never touch user-space, however NF_QUEUE is fully user
> configurable. Notify the user of his mistake and try to continue.
>
> --- linux-2.6-git.orig/net/netfilter/core.c 2007-02-14 12:09:07.0
> +0100
> +++ linux-2.6-git/net/netfilter/core.c2007-02-14 12:09:18.0
> +0100
> @@ -187,6 +187,11 @@ next_hook:
> kfree_skb(*pskb);
> ret = -EPERM;
> } else if ((verdict & NF_VERDICT_MASK) == NF_QUEUE) {
> + if (unlikely((*pskb)->emergency)) {
> + printk(KERN_ERR "nf_hook: NF_QUEUE encountered for "
> + "emergency skb - skipping rule.\n");
> + goto next_hook;
> + }
If I'm not mistaken any skb on the receive side might get
allocated from the reserve. I don't see how the user could
avoid this except by not using queueing at all.
I also didn't see a patch dropping packets allocated from
the reserve that are forwarded or processed directly without
getting queued to a socket, so this would allow them to
bypass userspace queueing and still go through.
I think the user should just exclude packets necessary for
swapping from queueing manually, based on IP addresses,
port numbers or something like that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/29] netfilter: notify about NF_QUEUE vs emergency skbs
On Sat, 2007-02-24 at 16:27 +0100, Patrick McHardy wrote:
> Peter Zijlstra wrote:
> > Emergency skbs should never touch user-space, however NF_QUEUE is fully user
> > configurable. Notify the user of his mistake and try to continue.
> >
> > --- linux-2.6-git.orig/net/netfilter/core.c 2007-02-14 12:09:07.0
> > +0100
> > +++ linux-2.6-git/net/netfilter/core.c 2007-02-14 12:09:18.0
> > +0100
> > @@ -187,6 +187,11 @@ next_hook:
> > kfree_skb(*pskb);
> > ret = -EPERM;
> > } else if ((verdict & NF_VERDICT_MASK) == NF_QUEUE) {
> > + if (unlikely((*pskb)->emergency)) {
> > + printk(KERN_ERR "nf_hook: NF_QUEUE encountered for "
> > + "emergency skb - skipping rule.\n");
> > + goto next_hook;
> > + }
>
> If I'm not mistaken any skb on the receive side might get
> allocated from the reserve. I don't see how the user could
> avoid this except by not using queueing at all.
Well, the rules could be setup so that the storage path will never hit
the queue.
> I also didn't see a patch dropping packets allocated from
> the reserve that are forwarded or processed directly without
> getting queued to a socket, so this would allow them to
> bypass userspace queueing and still go through.
>
> I think the user should just exclude packets necessary for
> swapping from queueing manually, based on IP addresses,
> port numbers or something like that.
Indeed, this patch will just warn the user that he did something very
wrong and should avoid this situation.
Perhaps skipping is not the proper action, but dropping them will most
certainly freeze the box. Either way seems unlucky. Might as well stick
BUG() in there :-(.
Any ideas on how to resolve this are most welcome, detecting the
situation on either rule insert or swapon and failing the respective
action would be most ideal, but I have no idea if that is feasible.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 18/29] netfilter: notify about NF_QUEUE vs emergency skbs
Peter Zijlstra wrote:
> On Sat, 2007-02-24 at 16:27 +0100, Patrick McHardy wrote:
>
>>> } else if ((verdict & NF_VERDICT_MASK) == NF_QUEUE) {
>>>+if (unlikely((*pskb)->emergency)) {
>>>+printk(KERN_ERR "nf_hook: NF_QUEUE encountered for "
>>>+"emergency skb - skipping rule.\n");
>>>+goto next_hook;
>>>+}
>>
>>If I'm not mistaken any skb on the receive side might get
>>allocated from the reserve. I don't see how the user could
>>avoid this except by not using queueing at all.
>
>
> Well, the rules could be setup so that the storage path will never hit
> the queue.
Sure, but other packets might still get allocated from the
reserve and trigger this.
>>I think the user should just exclude packets necessary for
>>swapping from queueing manually, based on IP addresses,
>>port numbers or something like that.
>
>
> Indeed, this patch will just warn the user that he did something very
> wrong and should avoid this situation.
>
> Perhaps skipping is not the proper action, but dropping them will most
> certainly freeze the box. Either way seems unlucky. Might as well stick
> BUG() in there :-(.
At this point we don't know whether the packet is destined for
a SOCK_VMIO socket or not. The only thing we know is that is
was allocated from the reserve, but it could be anything.
There is really nothing you can do at this point.
> Any ideas on how to resolve this are most welcome, detecting the
> situation on either rule insert or swapon and failing the respective
> action would be most ideal, but I have no idea if that is feasible.
Unfortunately this is not possible either. I don't really see why
queueing is special though, dropping the packets in the ruleset
will break things just as well, as will routing them to a blackhole.
I guess the user just needs to be smart enough not to do this.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 18/29] netfilter: notify about NF_QUEUE vs emergency skbs
On Sat, 2007-02-24 at 17:17 +0100, Patrick McHardy wrote: > I don't really see why > queueing is special though, dropping the packets in the ruleset > will break things just as well, as will routing them to a blackhole. > I guess the user just needs to be smart enough not to do this. Its user-space and no emergency packet may rely on user-space because it most likely is needed to maintain user-space. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 18/29] netfilter: notify about NF_QUEUE vs emergency skbs
Peter Zijlstra wrote: > On Sat, 2007-02-24 at 17:17 +0100, Patrick McHardy wrote: > > >>I don't really see why >>queueing is special though, dropping the packets in the ruleset >>will break things just as well, as will routing them to a blackhole. >>I guess the user just needs to be smart enough not to do this. > > > Its user-space and no emergency packet may rely on user-space because it > most likely is needed to maintain user-space. I believe I might have misunderstood the intention of this patch. Assuming the user is smart enough not to queue packets destined to a SOCK_VMIO socket, are you worried about unrelated packets allocated from the emergency reserve not getting freed fast enough because they're sitting in a queue? In that case simply dropping the packets would be fine I guess. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 18/29] netfilter: notify about NF_QUEUE vs emergency skbs
On Sat, 2007-02-24 at 17:40 +0100, Patrick McHardy wrote: > Peter Zijlstra wrote: > > On Sat, 2007-02-24 at 17:17 +0100, Patrick McHardy wrote: > > > > > >>I don't really see why > >>queueing is special though, dropping the packets in the ruleset > >>will break things just as well, as will routing them to a blackhole. > >>I guess the user just needs to be smart enough not to do this. > > > > > > Its user-space and no emergency packet may rely on user-space because it > > most likely is needed to maintain user-space. > > I believe I might have misunderstood the intention of this patch. > > Assuming the user is smart enough not to queue packets destined > to a SOCK_VMIO socket, are you worried about unrelated packets > allocated from the emergency reserve not getting freed fast > enough because they're sitting in a queue? In that case simply > dropping the packets would be fine I guess. OK, that sounds good. I shall make NF_QUEUE a black hole for emergency packets. Alas, that leaves no way to warn a user about a SOCK_VMIO bound packet treated this way, since, as you said, that is unknown at this point in the chain. Thanks, Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] div64_64 support
On Fri, Feb 23, 2007 at 17:05:27 -0800, Stephen Hemminger wrote: > Since there already two users of full 64 bit division in the kernel, > and other places maybe hiding out as well. Add a full 64/64 bit divide. > > Yes this expensive, but there are places where it is necessary. > It is not clear if doing the scaling buys any advantage on 64 bit platforms, > so for them a full divide is done. Still does not work after these fixes... how came? WARNING: "div64_64" [net/netfilter/xt_connbytes.ko] undefined! WARNING: "div64_64" [net/ipv4/tcp_cubic.ko] undefined! --- linux-2.6.19/include/asm-i386/div64.h.bak 2006-11-29 23:57:37.0 +0200 +++ linux-2.6.19/include/asm-i386/div64.h 2007-02-24 16:24:55.822529880 +0200 @@ -45,4 +45,7 @@ div_ll_X_l_rem(long long divs, long div, return dum2; } + +extern uint64_t div64_64(uint64_t dividend, uint64_t divisor); + #endif --- linux-2.6.19/lib/div64.c.bak2007-02-24 16:10:03.686084000 +0200 +++ linux-2.6.19/lib/div64.c2007-02-24 17:01:11.224517353 +0200 @@ -80,4 +80,6 @@ uint64_t div64_64(uint64_t dividend, uin return dividend; } +EXPORT_SYMBOL(div64_64); + #endif /* BITS_PER_LONG == 32 */ -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: why is asm-parisc/ioctl.h subtly different from asm-generic/ioctl.h?
On Sat, Feb 24, 2007 at 05:34:15AM -0500, Robert P. J. Day wrote:
>
> just noticed that parisc's ioctl.h file, rather than simply
> including asm-generic/ioctl.h, has its own copy whose sole
> (meaningful) difference from the generic one is:
>
> $ diff include/{asm-generic,asm-parisc}/ioctl.h
> ...
> 41,42c54,55
> < #define _IOC_WRITE1U
> < #define _IOC_READ 2U
> ---
> > #define _IOC_WRITE2U
> > #define _IOC_READ 1U
>
> so parisc is identical except that it switches the meaning of the
> direction field? is there a reason for this? just curious.
>
HP-UX compatibility.
#define IOC_OUT 0x4000
#define IOC_IN (int)0x8000
PS: It would be wise to ask questions on the pertinent mailing lists...
--Kyle
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Detecting section mismatches in vmlinux
On Thu, 22 Feb 2007 00:57:28 +0900 (JST), Atsushi Nemoto <[EMAIL PROTECTED]> wrote: > $ ../build-i386/scripts/mod/modpost ../build-i386/mm/built-in.o > WARNING: ../build-i386/mm/built-in.o - Section mismatch: reference to > .init.data:initkmem_list3 from .text between 'set_up_list3s' (at offset > 0x18382) and '__kmem_cache_destroy' > > set_up_list3s() in slab.c is not marked as __init and it references > initkmem_list3[] which is marked as __initdata. So it is not false > positive. But "modpost vmlinux" does not report it. For this set_up_list3s() case, it is not a fatal since it is only called during early bootstrap phase. But anyway I think we should detect these case at compile time. I found refenrence_*.pl was removed on these commits at 2.6.17: > commit eae0f536f640bb95f2ad437a57c40c7d5683d1ac > Author: Sam Ravnborg <[EMAIL PROTECTED]> > Date: Tue Mar 21 07:28:24 2006 +0100 > > kbuild: remove obsoleted scripts/reference_* files > > commit b39927cf4cc5a9123d2b157ffd396884cb8156eb > Author: Sam Ravnborg <[EMAIL PROTECTED]> > Date: Fri Feb 17 22:42:02 2006 +0100 > > kbuild: check for section mismatch during modpost stage Reviving these perl scripts looks overkill for me. This is a dirty hack to check all built-in.o just after linking vmlinux. But this can not detect mismatches in libs.a files, and modpost fails with "... is truncated" message on empty built-in.o files. Maybe checking at each $(LD) invocation should detect all mismatches, but I'm not familer with kbuild to do it by myself. Could someone make perfect solution? diff --git a/Makefile b/Makefile index d442d4b..4e8015d 100644 --- a/Makefile +++ b/Makefile @@ -738,6 +738,7 @@ ifdef CONFIG_HEADERS_CHECK endif $(call if_changed_rule,vmlinux__) $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost $@ + -scripts/mod/modpost $(filter-out $(libs-y1),$(vmlinux-init) $(vmlinux-main)) $(Q)rm -f .old_version # The actual objects are generated when descending, --- Atsushi Nemoto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Print error code in page faults
Glauber de Oliveira Costa wrote:
> When a page faults comes from a kernel space, the printed summary
> leaves us clueless about what kind of access was being tried (which
> is encoded in the error_code variable).
>
> Having it promply available may ease debugging in a bunch of
> situations.
>
> Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
>
>
>
>
>
> diff --git a/arch/x86_64/mm/fault.c b/arch/x86_64/mm/fault.c
> index 6ada723..e65522e 100644
> --- a/arch/x86_64/mm/fault.c
> +++ b/arch/x86_64/mm/fault.c
> @@ -539,7 +539,7 @@ no_context:
> printk(KERN_ALERT "Unable to handle kernel NULL pointer
> dereference");
> else
> printk(KERN_ALERT "Unable to handle kernel paging request");
> - printk(" at %016lx RIP: \n" KERN_ALERT,address);
> + printk(" at %016lx (error=0x%02lx) RIP: \n" KERN_ALERT, error_code,
> address);
> printk_address(regs->rip);
> dump_pagetable(address);
> tsk->thread.cr2 = address;
Umm, it's already there, right after the word "Oops".
Oops: 0002 [1] SMP
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system
Original-Nachricht Datum: Sat, 24 Feb 2007 10:07:29 -0800 Von: Andrew Morton <[EMAIL PROTECTED]> An: "Uwe Bugla" <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system > > On Sat, 24 Feb 2007 18:54:24 +0100 "Uwe Bugla" <[EMAIL PROTECTED]> wrote: > > Hi folks, > > Second attempt now: > > I already reported to Linus Torvalds and Andrew Morton that it is > impossible to mount a conventional floppy drive without hanging up the whole > system. > > Andrew's reaction was quite ambiguous: "We did not break it" > > Sorry, what I meant was "Neither Linus nor I broke it". ie: please report > this in a place where the person who did break it can see it. This you > have > done. > > > Once again and for the last time: I do not state that floppy.c is > broken. I only state that it is immpossible to mount a floppy drive with > kernel > 2.6.21-rc1-git1. Kernel 2.6.20 is OK. But 2.6.21-rc1-git1 is definitely > buggy! > > I did some work already: > > a. I copied the following modules from the intact and sane kernel 2.6.20 > into the 2.6.21-rc1-git1 tree: > > cdrom.h, floppy.c, init.h, io.h, proc_misc.c, setup.c, timer.h, > uaccess.h > > b. I adjusted some hunks of the patch for module main.c (part of > patch-2.6.21-rc1) to make the kernel compile without errors. > > But the problem still persists, and I do not have any idea anymore where > the offensive hunks in patch-2.6.21-rc1 could reside. > > > > Questions: > > a. Can someone please confirm the described problem? > > b. Can someone please take action to find out where the buggy code > resides? > > c. Why is this untested material being pushed into main vanilla - what > is going on at kernel.org please? > > > > Please take action! The bug was introduced somewhere at the transition > of 2.6.20 towards 2.6.20-git14. > > > > I think we'll find that it works OK for hundreds of other people, so it > got > broken in some manner which is specific to a very small number of > machines, > of which yours is one. > > If that theory proves to be correct, I'm afraid that the most proactical > way of fixing this is to ask you to run a git-bisect to find the changeset > which introduced the regression. > Andrew, it is definitely NOT my job to repair errors that other responsibility-free people pushed into vanilla mainline without the slightest test effort in some mm-tree for example. Who wasted it must repair it, without the slightest discussion! I have provided enough information and energy to establish guidelines how to fix that error. Above that I am still waiting for my linuxtv patches being applied which would be a nice and honest gesture. Any further questions, Mr. Morton, or did I pronounce clear? So take action now please! Yours sincerely Uwe -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: input.c: start on release
On Sat, 24 Feb 2007 11:57:07 -0500, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > To tell you the truth, all I really want is to hold a static mutex > > across a call to input_close_device(). Can I do that? > > Are you trying to fix locking in mousedev? Yes. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system
it is definitely NOT my job to repair errors that other responsibility-free people pushed into vanilla mainline without the slightest test effort in some mm-tree for example. Who wasted it must repair it, without the slightest discussion! You're assuming the author didn't test it. For things like floppy.c, it's possible it was tested and worked on their system just fine, but is broken on yours. As you can replicate the problem, you're the natural person to help narrow down the cause. This is the way all development works, not just Linux or free software. Please start by assuming that people mean well and are trying to do the right thing, and you'll get a lot more productive responses. So take action now please! And please remember that the vast majority of us, just like you, are volunteers. Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
On 2/23/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > This is a fundamental misconception. [...] > The scheduler, on the other hand, has to blow and reload all of the > hidden state associated with force-loading the PC and wherever your > architecture keeps its TLS (maybe not the whole TLB, but not nothing, > either). [...] please read up a bit more about how the Linux scheduler works. Maybe even read the code if in doubt? In any case, please direct kernel newbie questions to http://kernelnewbies.org/, not [EMAIL PROTECTED] This is not the first kernel I've swum around in, and I've been mucking with the Linux kernel since early 2.2 and coding assembly for heavily pipelined processors on and off since 1990. So I may be a newbie to your lingo, and I may even be a loud-mouthed idiot, but I'm not a wet-behind-the-ears undergrad, OK? Now, I've addressed the non-free-ness of a TLS swap elsewhere; what about function pointers in state machines (with or without flipping "supervisor mode" bits)? Just because loading the PC from a data register is one opcode in the instruction stream does not mean that it is not quite expensive in terms of blown pipeline state and I-cache stalls. Really fast state machines exploit PC-relative branches that really smart CPUs can speculatively execute past (after a few traversals) because there are a small number of branch targets actually hit. The instruction prefetch / scheduler unit actually keeps a table of PC-relative jump instructions found in I-cache, with a little histogram of destinations eventually branched to, and speculatively executes down the top branch or two. (Intel Pentiums have a fairly primitive but effective variant of this; see http://www.x86.org/articles/branch/branchprediction.htm.) More general mechanisms are called "branch target buffers" and US Patent 6609194 is a good hook into the literature. A sufficiently smart CPU designer may have figured out how to do something similar with computed jumps (add pc, pc, foo), but odds are high that it cuts out when you throw function pointers around. Syscall dispatch is a special and heavily optimized case, though -- so it's quite conceivable that a well designed userland switch/case state machine that makes syscalls will outperform an in-kernel state machine data structure traversal. If this doesn't happen to be true on today's desktop, it may be on tomorrow's desktop or today's NUMA monstrosity or embedded mega-multi-MIPS. There can also be other reasons why tabulated PC-relative jumps and immediate PC loads are faster than PC loads from data registers. Take, for instance, the Transmeta Crusoe, which (AIUI) used a trick similar to the FX!32 x86 emulation on Alpha/NT. If you're going to "translate" CISC to RISC on the fly, you're going to recognize switch/case idioms (including tabulated PC-relative branches), and fix up the translated branch table to contain offsets to the RISC-translated branch targets. So the state transitions are just as cheap as if they had been compiled to RISC in the first place. Do it with function pointers, and the the execution machine is going to have to stall while it looks up the text location to see if it has it translated in I-cache somewhere. Guess what: the PIV works the same way (http://www.karbosguide.com/books/pcarchitecture/chapter12.htm). Are you starting to get the picture that syslets -- clever as they might have been on a VAX -- defeat many of the mechanisms that CPU and compiler architects have negotiated over decades for accelerating real code? Especially now that we have hyper-threaded CPUs (parallel instruction decode/issue units sharing almost all of their cache hierarchy), you can almost treat the kernel as if it were microcode for a syscall coprocessor. If you try to migrate application code across the syscall boundary, you may perform well on micro-benchmarks but you're storing up trouble for the future. If you don't think this kind of fallout is real, talk to whoever had the bright idea of hijacking FPU registers to implement memcpy in 1996. The PIII designers rolled over and added XMM so micro-optimizers would get their dirty mitts off the FPU, which it appears that Doug Ledford and Jim Blandy duly acted on in 1999. Yes, you still need to use FXSAVE/FXRSTOR when you want to mess with the XMM stuff, but the CPU is smart enough to keep a shadow copy of all the microstate that the flag states represent. So if all you do between FXSAVE and FXRSTOR is shlep bytes around with MOVAPS, the FXRSTOR costs you little or nothing. What hurts is an FXRSTOR from a location that isn't the last location you FXSAVEd to, or an FXRSTOR after actual FP arithmetic instructions have altered status flags. The preceding may contain errors in detail -- I am neither a CPU architect nor an x86 compiler writer nor even a serious kernel hacker. But hopefully it's at least food for thought. If not, you know where the "ignore this prolix nitwit" key is to be found on yo
Re: current git crashes on bootup with pci_iounmap()
On Wed, 2007-02-21 at 20:34 +0900, Tejun Heo wrote: > Kay Sievers wrote: > > On 2/13/07, Kay Sievers <[EMAIL PROTECTED]> wrote: > >> On Tue, 2007-02-13 at 17:04 +0100, Marcel Holtmann wrote: > >> > > kernel BUG at lib/iomap.c:254! > >> > > invalid opcode: [#1] > >> > > ... > >> > > > >> > > The screen picture is here: > >> > > http://vrfy.org/pci_iounmap.jpg > >> > > > >> > > It's a Thinkpad T43p. > >> > > > >> > > 2.6.20 was working fine. > >> > > > >> > > Commenting out: > >> > > IO_COND(addr, /* nothing */, iounmap(addr)); > >> > > in: > >> > > lib/iomap.c:254 > >> > > makes at least booting up possible. > >> > > >> > I saw a similar one on my X41. Disabling the AHCI driver made the > >> > machine booting again. > >> > >> Hey Marcel, > >> yeah, that works fine here too. > > > > Tejun, Jeff, any ideas what's going wrong with the iomap change and > > the AHCI driver? > > The following commit should have fixed the problem, at least the oops. > Care to give the current git head a shot? Yes, it boots fine now with the AHCI driver compiled in. 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: [PATCH 0/4] coredump: core dump masking support v3
David Howells wrote: How does it work when you can't actually get back to userspace to have userspace do the coredump? You still have to handle the userspace equivalents of double/triple faults. My experience shows that there are only very rare occurrences of situations where you cannot get back into userspace to do the coredump, and the coredumper tries very hard never to cause additional faults. While I am sure you could construct scenarios where this would happen, realistically the only one I have run into were stack overflows, and they can be handled by carefully setting up an alternate stack for signal handlers -- just make sure the entire stack is already dirtied before you run out of memory (or, turn of overcommitting). Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Detecting section mismatches in vmlinux
On Sun, Feb 25, 2007 at 03:53:15AM +0900, Atsushi Nemoto wrote: > > This is a dirty hack to check all built-in.o just after linking > vmlinux. But this can not detect mismatches in libs.a files, and > modpost fails with "... is truncated" message on empty built-in.o > files. > > Maybe checking at each $(LD) invocation should detect all mismatches, > but I'm not familer with kbuild to do it by myself. Could someone > make perfect solution? I would prefer to find out why it fails when running the check on full vmlinux. Your suggestion is like papering over the real bug - and only if something prevent us from detecting this in full vmlinux should we do it for each LD invocation. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Changelog question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi ! looking at the Changelogs of the last 2.6.17 kernel and the first 2.6.18 it is obvious that a lot happened in between - are there some changelogs related to 2.6.18 development that are not found at http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.18.# + http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.18-rc# For assessment purposes it would be helpfull to know what low level changes happened i.e. when and where were __raw_spin_* introduced ? but I was not able to extract such infos from the ChangeLogs in the above directories. thx ! hofrat -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFF4JH/nU7rXZKfY2oRAk0OAJ9oFplfJIWhYK7jc0bpMGXw5mnWTgCfVAk+ p03G4C+kgiIimCBzXhkIL84= =FoIv -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] workqueue: kill NOAUTOREL works
We don't have any users, and it is not so trivial to use NOAUTOREL works
correctly. It is better to simplify API.
Delete NOAUTOREL support and rename work_release to work_clear_pending to
avoid a confusion.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- 6.20-rc6-mm3/include/linux/workqueue.h~kill_nar 2007-02-12
03:26:54.0 +0300
+++ 6.20-rc6-mm3/include/linux/workqueue.h 2007-02-24 22:40:15.0
+0300
@@ -24,15 +24,13 @@ typedef void (*work_func_t)(struct work_
struct work_struct {
atomic_long_t data;
#define WORK_STRUCT_PENDING 0 /* T if work item pending execution */
-#define WORK_STRUCT_NOAUTOREL 1/* F if work item automatically
released on exec */
#define WORK_STRUCT_FLAG_MASK (3UL)
#define WORK_STRUCT_WQ_DATA_MASK (~WORK_STRUCT_FLAG_MASK)
struct list_head entry;
work_func_t func;
};
-#define WORK_DATA_INIT(autorelease) \
- ATOMIC_LONG_INIT((autorelease) << WORK_STRUCT_NOAUTOREL)
+#define WORK_DATA_INIT() ATOMIC_LONG_INIT(0)
struct delayed_work {
struct work_struct work;
@@ -44,14 +42,8 @@ struct execute_work {
};
#define __WORK_INITIALIZER(n, f) { \
- .data = WORK_DATA_INIT(0), \
-.entry = { &(n).entry, &(n).entry }, \
- .func = (f),\
- }
-
-#define __WORK_INITIALIZER_NAR(n, f) { \
- .data = WORK_DATA_INIT(1), \
-.entry = { &(n).entry, &(n).entry }, \
+ .data = WORK_DATA_INIT(), \
+ .entry = { &(n).entry, &(n).entry }, \
.func = (f),\
}
@@ -60,23 +52,12 @@ struct execute_work {
.timer = TIMER_INITIALIZER(NULL, 0, 0), \
}
-#define __DELAYED_WORK_INITIALIZER_NAR(n, f) { \
- .work = __WORK_INITIALIZER_NAR((n).work, (f)), \
- .timer = TIMER_INITIALIZER(NULL, 0, 0), \
- }
-
#define DECLARE_WORK(n, f) \
struct work_struct n = __WORK_INITIALIZER(n, f)
-#define DECLARE_WORK_NAR(n, f) \
- struct work_struct n = __WORK_INITIALIZER_NAR(n, f)
-
#define DECLARE_DELAYED_WORK(n, f) \
struct delayed_work n = __DELAYED_WORK_INITIALIZER(n, f)
-#define DECLARE_DELAYED_WORK_NAR(n, f) \
- struct dwork_struct n = __DELAYED_WORK_INITIALIZER_NAR(n, f)
-
/*
* initialize a work item's function pointer
*/
@@ -95,16 +76,9 @@ struct execute_work {
* assignment of the work data initializer allows the compiler
* to generate better code.
*/
-#define INIT_WORK(_work, _func)\
- do {\
- (_work)->data = (atomic_long_t) WORK_DATA_INIT(0); \
- INIT_LIST_HEAD(&(_work)->entry);\
- PREPARE_WORK((_work), (_func)); \
- } while (0)
-
-#define INIT_WORK_NAR(_work, _func)\
+#define INIT_WORK(_work, _func)
\
do {\
- (_work)->data = (atomic_long_t) WORK_DATA_INIT(1); \
+ (_work)->data = (atomic_long_t) WORK_DATA_INIT(); \
INIT_LIST_HEAD(&(_work)->entry);\
PREPARE_WORK((_work), (_func)); \
} while (0)
@@ -115,12 +89,6 @@ struct execute_work {
init_timer(&(_work)->timer);\
} while (0)
-#define INIT_DELAYED_WORK_NAR(_work, _func)\
- do {\
- INIT_WORK_NAR(&(_work)->work, (_func)); \
- init_timer(&(_work)->timer);\
- } while (0)
-
/**
* work_pending - Find out whether a work item is currently pending
* @work: The work item in question
@@ -136,25 +104,7 @@ struct execute_work {
#define delayed_work_pending(w) \
work_pending(&(w)->work)
-/**
- * work_release - Release a work item under execution
- * @work: The work item to release
- *
- * This is used to release a work item that has been initialised with automatic
- * release mode disabled (WORK_STRUCT_NOAUTOREL is set). This gives the work
- * function the opportunity to grab auxiliary data from the container of the
- * work_struct before clearing the pending bit as the work_struct may be
- * subject to deallocation the moment the pending bit is cleared.
- *
- * In such a case, this should be called in the work function after it has
- * fetched an
RE: questions about 8250 uart support for adhoc boards
From: On Behalf Of Rob Prowel > Russell King wrote: > > You don't even need to do that. Just configure SERIAL_8250_NR_UARTS > > and SERIAL_8250_RUNTIME_UARTS appropriately for your > system. There's > > absolutely no need to build any of the additional modules. > > > Unfortunately what I'm seeing in 2.6.20.1 seems to differ > from this. If PC104 is really an ISA bus. The ISA ports are stored in a table in the 8250 driver (instead of allocated dynamically like PCI ports); the config option _NR_UARTS just tells the driver how large to make the table. > I use the options below: > > CONFIG_SERIAL_8250=y > CONFIG_SERIAL_8250_CONSOLE=y > CONFIG_SERIAL_8250_PCI=y > CONFIG_SERIAL_8250_NR_UARTS=32 This makes the internal table be 32 ports big. The first four ports end up configured for legacy/standard com ports, the rest are unconfigured. You should be able to see them as unknowns with setserial. > CONFIG_SERIAL_8250_RUNTIME_UARTS=16 > CONFIG_SERIAL_8250_EXTENDED=y > CONFIG_SERIAL_8250_MANY_PORTS=y > # CONFIG_SERIAL_8250_FOURPORT is not set All _FOURPORT does is specifically config ports 4-7 in the table to have specific address/irqs for the FourPort board. What you do with setserial is then change that config info to match your board. You shouldn't need to do this, and I quickly reviewed 2.6.20.1 and it looks like you don't. As long as _NR_UARTS is big enough, thus making the internal table big enough, you should be able to configure, with setserial, any of the ports in the table, including the first four. > Then I can only access ttyS0 through ttyS3 sith setserial. > Only after I add > CONFIG_SERIAL_8250_FOURPORT=y am I actually able to do > anything with the > additional ports. I would otherwise get the evil setserial: invalid > parameter error. Very odd. You get this error when doing "setserial /dev/ttySxx", no configuration? If so, that would imply that the table wasn't made big enough, and the unconfigured ports haven't been registered with the serial core. > OK. Fair enough. My question then becomes, how does the driver deal > with this now? scan all applicable uarts when any relevant > interrupt is > detected (as identified in setserial)? With our boards, the multiport is just a status register; it shows which port has produced the interrupt, so the driver doesn't have to loop through all the ports on the board looking for the correct one. It doesn't actually enable/disable the sharing of the interrupt. The setting of "irq 12" on multiple ports (from your original post) is what enables the sharing, from the driver-side view. Maybe your hardware is unusual and requires this ISR port to be set properly to enable sharing; more likely is that the board itself has one or more jumpers to set which interrupt it's using, and that's what enables the sharing from the hardware-side view. If I get some time tomorrow, I'll set up 2.6.20.1 and see what the current options are doing. If you can't get your board working, we have similar boards that do. ..Stu -- We make multiport serial products. http://www.connecttech.com/ (800) 426-8979 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SLUB: The unqueued Slab allocator
On Sat, 24 February 2007 09:32:49 -0800, Christoph Lameter wrote: > > If that is a problem for particular object pools then we may be able to > except those from the merging. How much of a gain is the merging anyway? Once you start having explicit whitelists or blacklists of pools that can be merged, one can start to wonder if the result is worth the effort. Jörn -- Joern's library part 6: http://www.gzip.org/zlib/feldspar.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] fbdev driver for S3 Trio/Virge, updated
On Fri, 2007-02-23 at 13:45 +0100, Ondrej Zajicek wrote: > On Thu, Feb 22, 2007 at 08:05:33AM +0800, Antonino A. Daplas wrote: > > On Fri, 2007-02-09 at 20:34 +0100, Ondrej Zajicek wrote: > > > This patch adds driver for S3 Trio / S3 Virge. Driver is tested > > > with most versions of S3 Trio and S3 Virge, on i386. > > > It is tested both as compiled-in and module. It is against > > > linux-2.6.20 . > > > > > > This is version 3. There are some minor modifications from version 2 > > > (mostly coding style cleanups). > > > > Nice, the first driver to use tileblit :-) > > > > Since this driver is already in the -mm tree, can you resubmit a diff > > against that? > > This driver was removed from -mm tree, because it is in 2.6.21-rc1 . > So it is probably unnnecessary to resubmit a diff, isn't it? > Okay, I thought the one in the tree was an older version. Thanks for clarifying. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
On Sat, 24 Feb 2007, Michael K. Edwards wrote: > The preceding may contain errors in detail -- I am neither a CPU > architect nor an x86 compiler writer nor even a serious kernel hacker. Ok, roger that. But why are you playing "Google & Preach" games to Ingo, that ate bread and CPUs for the last 15 years? - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 04/13] syslets: core code
On Sat, 24 Feb 2007, Ingo Molnar wrote: > * Davide Libenzi wrote: > > > > +asmlinkage long > > > +sys_threadlet_on(unsigned long restore_stack, > > > + unsigned long restore_eip, > > > + struct async_head_user __user *ahu) > > > > +asmlinkage long sys_threadlet_off(void) > > > If we have a new syscall that does the exec, we can save the two > > on/off calls. > > the on/off calls are shaped in a way that makes them ultimately > vsyscall-able - the kernel only needs to know about the fact that we are > in a threadlet (so that the scheduler can do its special > push-head-to-another-context thing) - and this can be signalled via a > small user-space-side info structure as well, put into the TLS. IMO it's not a matter of speed. We'll have those two new syscalls, that I don't see other practical use for. IMO the best thing would be to hide all inside the sys_threadlet_exec (or whatever name). > > [...] Also, the complete_thread() thingy can be done automatically > > from inside the kernel upon function return, by hence making the > > threadlet function look like a normal thread function: > > yeah - and that's how it works in my current codebase already, > threadlet_off() takes a 'completion event' pointer as well, and the ahu. > I'll release v4 so that you can have a look. Ok. Will look into it... - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [PATCH] nvidiafb: allow ignoring EDID info
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> > >
> > > The snowy is constant and abundant, and it seems to be independent of
> > > video size (640 through 1600) and screen occupation (single prompt
> > > line to fullscreen mc session) and usage.
> > >
> > > > I presume that X's nv driver or vesafb does not exhibit this problem?
> > >
> > > X's nv gives a very clean display, /unless/ I load nvidiafb before: if
> > > I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
> > > this reason), then the screen is very snowy with X's nv too.
> > >
> >
> > Hmm..., I really don't know how to fix this except to look at Xorg's
> > code and look for a difference.
>
> Keep in mind that setting nvidiafb to totally ignore the EDID (either
> by not compiling in EDID support or by using e.g. the ignoreedid patch
> I had proposed) the snow effect is extremely reduced,
I did not know that, just scanned the entire thread. Try this patch, it
makes use of fb_ddc_read*() which I believe has extra steps to prevent
display corruption. It also incorporates Luca's i2c fix.
Tony
nvidiafb: Bring back generic ddc reading
Make nvidiafb use fb_ddc_read(). This patch was submitted before but was
reverted due to problems in a non-x86 platform. This includes a fix for that
where ddc reading is bypassed if there is no DDC bus (duh).
Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]>
---
drivers/video/nvidia/nv_i2c.c | 44 ++---
1 files changed, 2 insertions(+), 42 deletions(-)
diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
index b858897..b91d404 100644
--- a/drivers/video/nvidia/nv_i2c.c
+++ b/drivers/video/nvidia/nv_i2c.c
@@ -70,8 +70,6 @@ static int nvidia_gpio_getscl(void *data
if (VGA_RD08(par->PCIO, 0x3d5) & 0x04)
val = 1;
- val = VGA_RD08(par->PCIO, 0x3d5);
-
return val;
}
@@ -159,51 +157,13 @@ void nvidia_delete_i2c_busses(struct nvi
}
-static u8 *nvidia_do_probe_i2c_edid(struct nvidia_i2c_chan *chan)
-{
- u8 start = 0x0;
- struct i2c_msg msgs[] = {
- {
-.addr = 0x50,
-.len = 1,
-.buf = &start,
-}, {
-.addr = 0x50,
-.flags = I2C_M_RD,
-.len = EDID_LENGTH,
-},
- };
- u8 *buf;
-
- if (!chan->par)
- return NULL;
-
- buf = kmalloc(EDID_LENGTH, GFP_KERNEL);
- if (!buf) {
- dev_warn(&chan->par->pci_dev->dev, "Out of memory!\n");
- return NULL;
- }
- msgs[1].buf = buf;
-
- if (i2c_transfer(&chan->adapter, msgs, 2) == 2)
- return buf;
- dev_dbg(&chan->par->pci_dev->dev, "Unable to read EDID block.\n");
- kfree(buf);
- return NULL;
-}
-
int nvidia_probe_i2c_connector(struct fb_info *info, int conn, u8 **out_edid)
{
struct nvidia_par *par = info->par;
u8 *edid = NULL;
- int i;
- for (i = 0; i < 3; i++) {
- /* Do the real work */
- edid = nvidia_do_probe_i2c_edid(&par->chan[conn - 1]);
- if (edid)
- break;
- }
+ if (par->chan[conn - 1].par)
+ edid = fb_ddc_read(&par->chan[conn - 1].adapter);
if (!edid && conn == 1) {
/* try to get from firmware */
Re: 2.6.19: ACPI reports AC not present after resume from STD
Hi, On Saturday, 24 February 2007 10:55, Andrey Borzenkov wrote: > On Вторник 13 февраля 2007, Andrey Borzenkov wrote: > > On Четверг 07 декабря 2006, Lebedev, Vladimir P wrote: > > > Please register new bug, attach acpidump and dmesg. > > > > http://bugzilla.kernel.org/show_bug.cgi?id=7995 > > > > regards > > > > Well, this starts looking like ACPI is not at fault. > > When reporting AC state ACPI just reads contents of system memory (I presume > it gets updated by BIOS/ACPI when AC state changes). It looks like this > memory area is restored during resume from STD. I updated mentioned bug > report with more detailed description. Now if someone could suggest a way to > catch if specific physical address gets saved/restored this would finally > explain it. First, if you want the reserved memory areas to be left alone by swsusp, you need to mark them as 'nosave'. On x86_64 this is done by the function e820_mark_nosave_range() in arch/x86_64/kernel/e820.c that can be ported to i386 with no problems. However, we haven't found that very useful, so far, since no one has ever reported any problems with the current approach, which is to save and restore them. Second, if you want to know if a suspicious page frame is saved by swsusp, it's best to stick a test and a printk in kernel/power/pack_pfns() and artificially fail the suspend, eg. by making swsusp_write() always return an error. > Gratefully waiting for patches to test :) Sorry, no patches this time. I have more urgent problem to fix. :-) Greetings, Rafael > > > -Original Message- > > > From: Alexey Starikovskiy [mailto:[EMAIL PROTECTED] > > > > > > Sent: Thursday, December 07, 2006 10:49 PM > > > To: Rafael J. Wysocki > > > Cc: Karasyov, Konstantin A; Andrey Borzenkov; > > > linux-acpi@vger.kernel.org; Lebedev, Vladimir P > > > Subject: Re: 2.6.19: ACPI reports AC not present after resume from STD > > > > > > Rafael J. Wysocki wrote: > > > > Hi, > > > > > > > > On Thursday, 7 December 2006 19:57, Karasyov, Konstantin A wrote: > > > >> Hi, > > > >> > > > >> Unfortunately, I cannot reproduce this bug on my system, but the > > > > > > problem > > > > > > >> could be solved by adding a resume handler for AC adapter device. > > > > > > Could > > > > > > >> you try the attached patch to see if it helps. > > > > > > > > I can reproduce it and the patch doesn't help. > > > > > > > > Greetings, > > > > Rafael > > > > > > Any ACPI errors in dmesg? > > > > > > Regards, > > > Alex. > > > > -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1: T60 resume from suspend to RAM issues
> Quoting Andrew Morton <[EMAIL PROTECTED]>: > Subject: Re: 2.6.21-rc1: T60 resume from suspend to RAM issues > > > On Fri, 23 Feb 2007 01:38:03 +0200 "Michael S. Tsirkin" <[EMAIL PROTECTED]> > > wrote: > > I tested this: > > commit 9654640d0af8f2de40ff3807d3695109d3463f54 > > and see 2 issues: > > > > 1. After suspend to RAM, system wakes up but no screen. > > I can log in through ssh though. > > dmesg output at this point below. > > Works fine on 2.6.20 and below, with same .config > > .config and log file for this issue attached. > > > > 2. As a separate test, I enabled DynTicks in .config. > > Seems to work fine but won't come out of suspend to memory at all: > > pressing Fn/F4 seems to have no effect. > > > > Do you believe that the second problem was caused by dynticks? Assuming these are 2 different problems, yes, the second one seems to be caused by dyntics. -- MST - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH][0/4] Memory controller (RSS Control) (
This patch applies on top of Paul Menage's container patches (V7) posted at http://lkml.org/lkml/2007/2/12/88 It implements a controller within the containers framework for limiting memory usage (RSS usage). The memory controller was discussed at length in the RFC posted to lkml http://lkml.org/lkml/2006/10/30/51 This is version 2 of the patch, version 1 was posted at http://lkml.org/lkml/2007/2/19/10 I have tried to incorporate all comments, more details can be found in the changelog's of induvidual patches. Any remaining mistakes are all my fault. The next question could be why release version 2? 1. It serves a decision point to decide if we should move to a per-container LRU list. Walking through the global LRU is slow, in this patchset I've tried to address the LRU churning issue. The patch memcontrol-reclaim-on-limit has more details 2. I;ve included fixes for several of the comments/issues raised in version 1 Steps to use the controller -- 0. Download the patches, apply the patches 1. Turn on CONFIG_CONTAINER_MEMCONTROL in kernel config, build the kernel and boot into the new kernel 2. mount -t container container -o memcontrol / 3. cd / optionally do (mkdir ; cd ) under / 4. echo $$ > tasks (attaches the current shell to the container) 5. echo -n (limit value) > memcontrol_limit 6. cat memcontrol_usage 7. Run tasks, check the usage of the controller, reclaim behaviour 8. Report bugs, get bug fixes and iterate (goto step 0). Advantages of the patchset -- 1. Zero overhead in struct page (struct page is not expanded) 2. Minimal changes to the core-mm code 3. Shared pages are not reclaimed unless all mappings belong to overlimit containers. 4. It can be used to debug drivers/applications/kernel components in a constrained memory environment (similar to mem=XXX option), except that several containers can be created simultaneously without rebooting and the limits can be changed. NOTE: There is no support for limiting kernel memory allocations and page cache control (presently). Testing --- Created containers, attached tasks to containers with lower limits than the memory the tasks require (memory hog tests) and ran some basic tests on them. Tested the patches on UML and PowerPC. On UML tried the patches with the config enabled and disabled (sanity check) and with containers enabled but the memory controller disabled. TODO's and improvement areas 1. Come up with cool page replacement algorithms for containers - still holds good (if possible without any changes to struct page) 2. Add page cache control 3. Add kernel memory allocator control 4. Extract benchmark numbers and overhead data Comments & criticism are welcome. Series -- memcontrol-setup.patch memcontrol-acct.patch memcontrol-reclaim-on-limit.patch memcontrol-doc.patch -- Warm Regards, Balbir Singh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH][1/4] RSS controller setup (
Changelog
1. Change the name from memctlr to memcontrol
2. Coding style changes, call the API and then check return value (for kmalloc).
3. Change the output format, to print sizes in both pages and kB
4. Split the usage and limit files to be independent (cat memcontrol_usage
no longer prints the limit)
TODO's
1. Implement error handling mechansim for handling container_add_file()
failures (this would depend on the containers code).
This patch sets up the basic controller infrastructure on top of the
containers infrastructure. Two files are provided for monitoring
and control memcontrol_usage and memcontrol_limit.
memcontrol_usage shows the current usage (in pages, of RSS) and the limit
set by the user.
memcontrol_limit can be used to set a limit on the RSS usage of the resource.
A special value of 0, indicates that the usage is unlimited. The limit
is set in units of pages.
Signed-off-by: <[EMAIL PROTECTED]>
---
include/linux/memcontrol.h | 33 +++
init/Kconfig |7 +
mm/Makefile|1
mm/memcontrol.c| 193 +
4 files changed, 234 insertions(+)
diff -puN /dev/null include/linux/memcontrol.h
--- /dev/null 2007-02-02 22:51:23.0 +0530
+++ linux-2.6.20-balbir/include/linux/memcontrol.h 2007-02-24
19:39:03.0 +0530
@@ -0,0 +1,33 @@
+/*
+ * memcontrol.h - Memory Controller for containers
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2.1 of the GNU Lesser General Public License
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * © Copyright IBM Corporation, 2006-2007
+ *
+ * Author: Balbir Singh <[EMAIL PROTECTED]>
+ *
+ */
+
+#ifndef _LINUX_MEMCONTROL_H
+#define _LINUX_MEMCONTROL_H
+
+#ifdef CONFIG_CONTAINER_MEMCONTROL
+#ifndef kB
+#define kB 1024/* One Kilo Byte */
+#endif
+
+#else /* CONFIG_CONTAINER_MEMCONTROL */
+
+#endif /* CONFIG_CONTAINER_MEMCONTROL */
+#endif /* _LINUX_MEMCONTROL_H */
diff -puN init/Kconfig~memcontrol-setup init/Kconfig
--- linux-2.6.20/init/Kconfig~memcontrol-setup 2007-02-20 21:01:28.0
+0530
+++ linux-2.6.20-balbir/init/Kconfig2007-02-20 21:01:28.0 +0530
@@ -306,6 +306,13 @@ config CONTAINER_NS
for instance virtual servers and checkpoint/restart
jobs.
+config CONTAINER_MEMCONTROL
+ bool "A simple RSS based memory controller"
+ select CONTAINERS
+ help
+ Provides a simple Resource Controller for monitoring and
+ controlling the total Resident Set Size of the tasks in a container
+
config RELAY
bool "Kernel->user space relay support (formerly relayfs)"
help
diff -puN mm/Makefile~memcontrol-setup mm/Makefile
--- linux-2.6.20/mm/Makefile~memcontrol-setup 2007-02-20 21:01:28.0
+0530
+++ linux-2.6.20-balbir/mm/Makefile 2007-02-20 21:01:28.0 +0530
@@ -29,3 +29,4 @@ obj-$(CONFIG_MEMORY_HOTPLUG) += memory_h
obj-$(CONFIG_FS_XIP) += filemap_xip.o
obj-$(CONFIG_MIGRATION) += migrate.o
obj-$(CONFIG_SMP) += allocpercpu.o
+obj-$(CONFIG_CONTAINER_MEMCONTROL) += memcontrol.o
diff -puN /dev/null mm/memcontrol.c
--- /dev/null 2007-02-02 22:51:23.0 +0530
+++ linux-2.6.20-balbir/mm/memcontrol.c 2007-02-24 19:39:24.0 +0530
@@ -0,0 +1,193 @@
+/*
+ * memcontrol.c - Memory Controller for containers
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2.1 of the GNU Lesser General Public License
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * © Copyright IBM Corporation, 2006-2007
+ *
+ * Author: Balbir Singh <[EMAIL PROTECTED]>
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define RES_USAGE_NO_LIMIT 0
+static const char version[] = "0.1";
+
+struct res_counter {
+ atomic_long_t usage;/* The current usage of the resource being */
+ /* counted */
+ atomic_long_t limit;/* The limit on the resource */
+};
+
+/*
+ * Each task belong
[RFC][PATCH][2/4] Add RSS accounting and control (
Changelog
1. Be consistent, use the C style of returning 0 on success and negative
values on failure
2. Change and document the locking used by the controller
(I hope I got it right this time :-))
3. Remove memctlr_double_(un)lock routines
4. Comment the usage of MEMCONTROL_DONT_CHECK_LIMIT
This patch adds the basic accounting hooks to account for pages allocated
into the RSS of a process. Accounting is maintained at two levels, in
the mm_struct of each task and in the memory controller data structure
associated with each node in the container.
When the limit specified for the container is exceeded, the task is killed.
RSS accounting is consistent with the current definition of RSS in the
kernel. Shared pages are accounted into the RSS of each process as is
done in the kernel currently. The code is flexible in that it can be easily
modified to work with any definition of RSS.
Signed-off-by: <[EMAIL PROTECTED]>
---
fs/exec.c |4 +
include/linux/memcontrol.h | 47
include/linux/sched.h | 11 +++
kernel/fork.c | 10 +++
mm/memcontrol.c| 130 ++---
mm/memory.c| 34 ++-
mm/rmap.c |5 +
mm/swapfile.c |2
8 files changed, 234 insertions(+), 9 deletions(-)
diff -puN fs/exec.c~memcontrol-acct fs/exec.c
--- linux-2.6.20/fs/exec.c~memcontrol-acct 2007-02-24 19:39:29.0
+0530
+++ linux-2.6.20-balbir/fs/exec.c 2007-02-24 19:39:29.0 +0530
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
#include
@@ -313,6 +314,9 @@ void install_arg_page(struct vm_area_str
if (unlikely(anon_vma_prepare(vma)))
goto out;
+ if (memcontrol_update_rss(mm, 1, MEMCONTROL_CHECK_LIMIT))
+ goto out;
+
flush_dcache_page(page);
pte = get_locked_pte(mm, address, &ptl);
if (!pte)
diff -puN include/linux/memcontrol.h~memcontrol-acct include/linux/memcontrol.h
--- linux-2.6.20/include/linux/memcontrol.h~memcontrol-acct 2007-02-24
19:39:29.0 +0530
+++ linux-2.6.20-balbir/include/linux/memcontrol.h 2007-02-24
19:39:29.0 +0530
@@ -22,12 +22,59 @@
#ifndef _LINUX_MEMCONTROL_H
#define _LINUX_MEMCONTROL_H
+/*
+ * MEMCONTROL_DONT_CHECK_LIMIT is useful for the following cases
+ * 1. During fork(), since pages are shared COW, we don't enforce limits
+ *on fork
+ * 2. During zeromap_pte_range(), again we don't enforce the limit for
+ *sharing ZERO_PAGE() in this case
+ * 3. When we actually reduce the RSS, add -1 to the rss
+ * It is generally useful when we do not want to enforce limits
+ */
+enum {
+ MEMCONTROL_CHECK_LIMIT = true,
+ MEMCONTROL_DONT_CHECK_LIMIT = false,
+};
+
#ifdef CONFIG_CONTAINER_MEMCONTROL
+
#ifndef kB
#define kB 1024/* One Kilo Byte */
#endif
+struct res_counter {
+ atomic_long_t usage;/* The current usage of the resource being */
+ /* counted */
+ atomic_long_t limit;/* The limit on the resource */
+};
+
+extern int memcontrol_mm_init(struct mm_struct *mm);
+extern void memcontrol_mm_free(struct mm_struct *mm);
+extern void memcontrol_mm_assign_container(struct mm_struct *mm,
+ struct task_struct *p);
+extern int memcontrol_update_rss(struct mm_struct *mm, int count, bool check);
+
#else /* CONFIG_CONTAINER_MEMCONTROL */
+static inline int memcontrol_mm_init(struct mm_struct *mm)
+{
+ return 0;
+}
+
+static inline void memcontrol_mm_free(struct mm_struct *mm)
+{
+}
+
+static inline void memcontrol_mm_assign_container(struct mm_struct *mm,
+ struct task_struct *p)
+{
+}
+
+static inline int memcontrol_update_rss(struct mm_struct *mm, int count,
+ bool check)
+{
+ return 0;
+}
+
#endif /* CONFIG_CONTAINER_MEMCONTROL */
#endif /* _LINUX_MEMCONTROL_H */
diff -puN include/linux/sched.h~memcontrol-acct include/linux/sched.h
--- linux-2.6.20/include/linux/sched.h~memcontrol-acct 2007-02-24
19:39:29.0 +0530
+++ linux-2.6.20-balbir/include/linux/sched.h 2007-02-24 19:39:29.0
+0530
@@ -83,6 +83,7 @@ struct sched_param {
#include
#include
#include
+#include
#include
@@ -373,6 +374,16 @@ struct mm_struct {
/* aio bits */
rwlock_tioctx_list_lock;
struct kioctx *ioctx_list;
+#ifdef CONFIG_CONTAINER_MEMCONTROL
+ /*
+* Each mm_struct's container, sums up in the container's counter
+* We can extend this such that, VMA's counters sum up into this
+* counter
+*/
+ struct res_counter *counter;
+ struct container*container;
+ rwlock_tcontainer_lock;
+#en
[RFC][PATCH][3/4] Add reclaim support (
Changelog
1. Move void *container to struct container (in scan_control and vmscan.c
and rmap.c)
2. The last set of patches churned the LRU list, in this release, pages
that can do not belong to the container are moved to a skipped_pages
list. At the end of the isolation they are added back to the zone
list using list_spice_tail (a new function added in list.h).
The disadvantage of this approach is that pages moved to skipped_pages
will not be available for general reclaim. General testing on UML
and a powerpc box showed that the changes worked.
Other alternatives tried
a. Do not delete the page from lru list, but that quickly lead to
a panic, since the page was on LRU and we released the lru_lock
in page_in_container
TODO's
1. Try a per-container LRU list, but that would mean expanding the page
struct or special tricks like overloading the LRU pointer. A per-container
list would also make it more difficult to handle shared pages, as a
page will belong to just one container at-a-time.
This patch reclaims pages from a container when the container limit is hit.
The executable is oom'ed only when the container it is running in, is overlimit
and we could not reclaim any pages belonging to the container
A parameter called pushback, controls how much memory is reclaimed when the
limit is hit. It should be easy to expose this knob to user space, but
currently it is hard coded to 20% of the total limit of the container.
isolate_lru_pages() has been modified to isolate pages belonging to a
particular container, so that reclaim code will reclaim only container
pages. For shared pages, reclaim does not unmap all mappings of the page,
it only unmaps those mappings that are over their limit. This ensures
that other containers are not penalized while reclaiming shared pages.
Parallel reclaim per container is not allowed. Each controller has a wait
queue that ensures that only one task per control is running reclaim on
that container.
Signed-off-by: <[EMAIL PROTECTED]>
---
include/linux/list.h | 26 +
include/linux/memcontrol.h | 12
include/linux/rmap.h | 20 ++-
include/linux/swap.h |3 +
mm/memcontrol.c| 122 +
mm/migrate.c |2
mm/rmap.c | 100 +++-
mm/vmscan.c| 114 +-
8 files changed, 370 insertions(+), 29 deletions(-)
diff -puN include/linux/memcontrol.h~memcontrol-reclaim-on-limit
include/linux/memcontrol.h
--- linux-2.6.20/include/linux/memcontrol.h~memcontrol-reclaim-on-limit
2007-02-24 19:40:56.0 +0530
+++ linux-2.6.20-balbir/include/linux/memcontrol.h 2007-02-24
19:50:34.0 +0530
@@ -37,6 +37,7 @@ enum {
};
#ifdef CONFIG_CONTAINER_MEMCONTROL
+#include
#ifndef kB
#define kB 1024/* One Kilo Byte */
@@ -53,6 +54,9 @@ extern void memcontrol_mm_free(struct mm
extern void memcontrol_mm_assign_container(struct mm_struct *mm,
struct task_struct *p);
extern int memcontrol_update_rss(struct mm_struct *mm, int count, bool check);
+extern int memcontrol_mm_overlimit(struct mm_struct *mm, void *sc_cont);
+extern wait_queue_head_t memcontrol_reclaim_wq;
+extern bool memcontrol_reclaim_in_progress;
#else /* CONFIG_CONTAINER_MEMCONTROL */
@@ -76,5 +80,13 @@ static inline int memcontrol_update_rss(
return 0;
}
+/*
+ * In the absence of memory control, we always free mappings.
+ */
+static inline int memcontrol_mm_overlimit(struct mm_struct *mm, void *sc_cont)
+{
+ return 1;
+}
+
#endif /* CONFIG_CONTAINER_MEMCONTROL */
#endif /* _LINUX_MEMCONTROL_H */
diff -puN include/linux/rmap.h~memcontrol-reclaim-on-limit include/linux/rmap.h
--- linux-2.6.20/include/linux/rmap.h~memcontrol-reclaim-on-limit
2007-02-24 19:40:56.0 +0530
+++ linux-2.6.20-balbir/include/linux/rmap.h2007-02-24 19:40:56.0
+0530
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
/*
* The anon_vma heads a list of private "related" vmas, to scan if
@@ -90,7 +91,17 @@ static inline void page_dup_rmap(struct
* Called from mm/vmscan.c to handle paging out
*/
int page_referenced(struct page *, int is_locked);
-int try_to_unmap(struct page *, int ignore_refs);
+int try_to_unmap(struct page *, int ignore_refs, struct container *container);
+#ifdef CONFIG_CONTAINER_MEMCONTROL
+bool page_in_container(struct page *page, struct zone *zone,
+ struct container *container);
+#else
+static inline bool page_in_container(struct page *page, struct zone *zone,
+ struct container *container)
+{
+ return true;
+}
+#endif /* CONFIG_CONTAINER_MEMCONTROL */
/*
* Called from mm/filemap_xip.c to unmap empty zero page
@@ -118,7 +129,1
