Re: Accelerated frame buffer functions
Le mercredi 02 fvrier 2005 15:21 +0100, Haakon Riiser a crit : How can I use a frame buffer driver's optimized copyarea, fillrect, blit, etc. from userspace? The only way I've ever seen anyone use the frame buffer device is by mmap()ing it and doing everything manually in the mapped memory. I assume there must be ioctls for accessing the accelerated functions, but after several hours of grepping and googling, I give up. :-( Did you try DirectFB ? Xav - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.
Koichi Suzuki [EMAIL PROTECTED] writes: Itsuro Oda wrote: Hi, I can't understand why ELF format is necessary. I think the only necessary information is what physical address regions are valid to read. This information is necessary for any sort of dump tools. (and must get it while the system is normal.) The Eric's /proc/cpumem idea sounds nice to me. I agree. Format conversion should be done in healthy system separately and we should restrict what to do while taking the dump as few as possible. Conversion from just memory image to crash/lcrash format will be very useful to use existing tools and experiences. I already have such tool and (if my administration allows) I can make such tool open. Let me do some paperwork. The big part of the conversation that is happening right now is how do we uncouple dependencies between the various parts as much as possible. There is nothing here about format conversions except as to convert weird kernel formats into a stable interface. There are 3 pieces of code interacting. 1) The primary kernel that will call panic. 2) The kernel+initrd that takes over. 3) The user space that sets it all up (/sbin/kexec) while the primary kernel is still in a sane state. The goal is to make those 3 pieces as independent of each other as reasonably possible. So the kernel+initrd that captures a crash dump will live and execute in a reserved area of memory. It needs to know which memory regions are valid, and it needs to know small things like the final register state of each cpu. For the set of valid memory regions it is the intention to encode that as an array of ELF program headers. The information of what the final register contents were will be encoded as ELF notes. There will be one PT_NOTE segment per cpu that holds the notes needed to encode a given cpu's final state. It really does not matter to implementation that captures each cpu's final register state which format we record the data in so using a format designed not to change is not a problem. So all that needs to be communicated to the kernel+initrd that captures a crash dump is the location of an ELF header and it can figure out all of the rest. For the primary kernel except for remembering it's final cpu register state as it dies it does nothing except jump to the crash recover kernel. All of the interesting information will be exported to user space. /sbin/kexec is the glue that fills in the cracks. While the primary kernel is in a sane state it sets everything up including finding out which memory areas need to be looked at. And it stashes it all in a reserved area of memory, that has never been the target of DMA transfers. The goal is to reduce the dependencies as much as possible. So an old stable kernel can take a crash dump of a new buggy kernel. And so that you don't have to be running the latest and greatest user space simply to set everything up. Although it is still better to require a user-space upgrade to cope with new kernels than to require the crash capture kernel+initrd to be upgraded. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] pci: Block config access during BIST (resend)
Matthew Wilcox wrote:
On Tue, Feb 01, 2005 at 11:35:05AM -0600, Brian King wrote:
If we've done a write to config space while the adapter was blocked,
shouldn't we replay those accesses at this point?
I did not think that was necessary.
We have to do *something*. We can't just throw away writes.
I see a few options:
- Log all pending writes to config space and replay the log when the
device is unblocked.
- Fail writes to config space while the device is blocked.
- Write to the saved config space and then blat the saved config space
back to the device upon unblocking.
Here is an updated patch which will now fail writes to config space
while the device is blocked. I have also fixed up the caching to return
the correct data and tested it on both little endian and big endian
machines.
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
Some PCI adapters (eg. ipr scsi adapters) have an exposure today in that
they issue BIST to the adapter to reset the card. If, during the time
it takes to complete BIST, userspace attempts to access PCI config space,
the host bus bridge will master abort the access since the ipr adapter
does not respond on the PCI bus for a brief period of time when running BIST.
On PPC64 hardware, this master abort results in the host PCI bridge
isolating that PCI device from the rest of the system, making the device
unusable until Linux is rebooted. This patch is an attempt to close that
exposure by introducing some blocking code in the PCI code. When blocked,
writes will be humored and reads will return the cached value. Ben
Herrenschmidt has also mentioned that he plans to use this in PPC power
management.
Signed-off-by: Brian King [EMAIL PROTECTED]
---
linux-2.6.11-rc2-bk9-bjking1/drivers/pci/access.c| 86 +++
linux-2.6.11-rc2-bk9-bjking1/drivers/pci/pci-sysfs.c | 10 +-
linux-2.6.11-rc2-bk9-bjking1/drivers/pci/pci.h |7 +
linux-2.6.11-rc2-bk9-bjking1/drivers/pci/proc.c | 30 +++---
linux-2.6.11-rc2-bk9-bjking1/drivers/pci/syscall.c | 14 +--
linux-2.6.11-rc2-bk9-bjking1/include/linux/pci.h |7 +
6 files changed, 127 insertions(+), 27 deletions(-)
diff -puN drivers/pci/access.c~pci_block_user_config_io_during_bist_again
drivers/pci/access.c
---
linux-2.6.11-rc2-bk9/drivers/pci/access.c~pci_block_user_config_io_during_bist_again
2005-02-02 08:58:53.0 -0600
+++ linux-2.6.11-rc2-bk9-bjking1/drivers/pci/access.c 2005-02-02
09:15:30.0 -0600
@@ -60,3 +60,89 @@ EXPORT_SYMBOL(pci_bus_read_config_dword)
EXPORT_SYMBOL(pci_bus_write_config_byte);
EXPORT_SYMBOL(pci_bus_write_config_word);
EXPORT_SYMBOL(pci_bus_write_config_dword);
+
+static u32 pci_user_cached_config(struct pci_dev *dev, int pos)
+{
+ u32 data;
+
+ data = dev-saved_config_space[pos/sizeof(dev-saved_config_space[0])];
+ data = (pos % sizeof(dev-saved_config_space[0])) * 8;
+ return data;
+}
+
+#define PCI_USER_READ_CONFIG(size,type)
\
+int pci_user_read_config_##size
\
+ (struct pci_dev *dev, int pos, type *val) \
+{ \
+ unsigned long flags;\
+ int ret = 0;\
+ u32 data = -1; \
+ if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
+ spin_lock_irqsave(pci_lock, flags);\
+ if (likely(!dev-block_ucfg_access))\
+ ret = dev-bus-ops-read(dev-bus, dev-devfn, \
+ pos, sizeof(type), data); \
+ else if (pos sizeof(dev-saved_config_space)) \
+ data = pci_user_cached_config(dev, pos);\
+ spin_unlock_irqrestore(pci_lock, flags); \
+ *val = (type)data; \
+ return ret; \
+}
+
+#define PCI_USER_WRITE_CONFIG(size,type) \
+int pci_user_write_config_##size \
+ (struct pci_dev *dev, int pos, type val)\
+{ \
+ unsigned long flags;\
+ int ret = -EIO; \
+ if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
+ spin_lock_irqsave(pci_lock, flags);\
+ if (likely(!dev-block_ucfg_access))\
+ ret = dev-bus-ops-write(dev-bus, dev-devfn,\
+
Re: Accelerated frame buffer functions
[Xavier Bestel] Le mercredi 02 février 2005 à 15:21 +0100, Haakon Riiser a écrit : How can I use a frame buffer driver's optimized copyarea, fillrect, blit, etc. from userspace? The only way I've ever seen anyone use the frame buffer device is by mmap()ing it and doing everything manually in the mapped memory. I assume there must be ioctls for accessing the accelerated functions, but after several hours of grepping and googling, I give up. :-( Did you try DirectFB ? Thanks for the tip, I hadn't heard about it. I will take a look, but only to see if it can show me the user space API of /dev/fb. I don't need a general library that supports a bunch of different graphics cards. I'm writing my own frame buffer driver for the GX2 CPU, and I just want to know how to call the various functions registered in struct fb_ops, so that I can test my code. I mean, all those functions registered in fb_ops must be accessible somehow; if they weren't, what purpose would they serve? -- Haakon - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.
Vivek Goyal [EMAIL PROTECTED] writes: On Tue, 2005-02-01 at 20:56, Eric W. Biederman wrote: Vivek Goyal [EMAIL PROTECTED] writes: elfcorehdr= also looks good. Then let's go with that for now. It is not perfect but it seems a little more self explanatory at first glance. A clarification on terminology we are talking about struct Elf64_Phdr here. There is only one Elf header. That seems to be clear farther down. Exactly. There shall be one Elf header for whole of the image. In addition there will be one struct Elf64_Phdr, per contiguous physical memory area. One Elf64_Phdr of PT_NOTE type for notes section and one Elf64_Phdr for backup region. Actually if we are just pointing a kernel data structures we will need multiple Elf64_Phdr of PT_NOTE. Each cpu has it's own notes section and until the smoke clears we can't be confident about what is going to wind up there or how densely those will be packed. So collapsing everything into a single notes segment needs to happen after we have switched to the crash capture kernel. I have serious concerns about the kernel generating the ELF headers and only delivering them after the kernel has crashed. Because then we run into questions of what information can be trusted. If we avoid that issue I am not too concerned. I hope, all elf headers once prepared by kexec-tools need not to change later (Cannot think of any piece of information which shall change later). These shall be put in separate segment. And SHA-256 shall take care of authenticity of information after crash. That should work fine. We need to consider through throwing in an extra note section with information like kernel version that we can capture while the system is running. For notes section program header, virtual = physical = 0 and offset shall point to crash_notes[], so that notes can directly be read by the capture kernel (or user space). I agree. But see my caveat. I think we should have one PT_NOTE segment point at each element of the crash_notes[] array. I know it is technically a violation of the ELF spec. But in this case it makes sense. Since we can't guarantee that crash_notes will be packed properly I don't know that we could reliably see more than one cpu if we pointed a PT_NOTE header at the whole thing. If it turns out that we can reliably point a single PT_NOTE header at crash_notes so much the better but things are likely to be more robust if we don't start with that assumption. That at least allows us the freedom to capture some notes (like NT_UTSNAME) before the kernel crashes. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Really annoying bug in the mouse driver
On Wed, 02 Feb 2005 11:22:43 +0100, Victor Hahn [EMAIL PROTECTED] wrote: Dmitry Torokhov wrote: It still complains in dmesg about throwing away bytes, right? Please try loading the box some more to make sure mouse survives some abuse. No, it doesn't. The only message I still get is the one below. I've tried it with aprox. 90% CPU usage already and I didn't have any additional problems. Processor load we usually handle well, loaded disks are usually the ones that cause = 0.5 sec delays between bytes received by psmouse. Please let me know if it still works with busy disks. kernel: psmouse.c: bad data from KBC - bad parity Your keyboard controller reported that the byte transmitted from the mouse was mangled somehow and we should not trust it. I am not sure why it would make mouse jump.. was there any mention of reconnect in the logs? Did it happen just once? It happened once when I was at the computer and several times while I wasn't. Well, we won't be able to do anythng about parity errors themselves but hopefully the patch will make them almost invisible for you. I wonder if the jump could be explained by having a byte with 2 bits flipped. KBC then would not detect parity error and psmouse would process the byte as if it was good. This should not be happening too often. There's no reconnect in the logs: [EMAIL PROTECTED]:~$ cat /var/log/messages | grep reconnect [EMAIL PROTECTED]:~$ Ok, I was wondering if you hit parity error twice in a row and it decided to reconnect. -- 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: Accelerated frame buffer functions
On Wed, Feb 02, 2005 at 03:21:55PM +0100, Haakon Riiser wrote: X-Windows already does this. Yeah, I thought the X11 fbdev driver supported acceleration, but not according to its manpage: fbdev is an Xorg driver for framebuffer devices. This is a non-accelerated driver [...] Yepp, it would be cool, to move every low level graphical operation to the framebuffer devices ... So no more 'I would like to use framebuffer console _AND_ X at the same time without disturbing each other' problem, and also if X segfaults or such, consolse will not remain in unusable state. Also a solid low level graphical operation layer should provide even 3D acceleration for fbdev capable (but not X!) apps and of course for the X server ... without conflicting each other :) DirectFB seems to be a good idea anyway ... - Gbor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote: On Tue, Feb 01, 2005 at 11:41:48PM -0800, Pete Zaitcev wrote: On 30 Jan 2005 12:10:34 +0100, Peter Osterlund [EMAIL PROTECTED] wrote: - Slow motion of finger produces no motion, then a jump. So, it's very hard to target smaller UI elements and some web links. I see this too when I don't use the X touchpad driver. With the X driver there is no problem. I think the problem is that mousedev.c in the kernel has to use integer arithmetic, so probably small movements are rounded off to 0. I'll try to come up with a fix for this. Thanks for the hint. I tried various schemes and mathematical transformations and found one which gives unquestionably the best result, with smoothest, most precise and comfortable pointer movement: Well, you removed the scaling to the touchpad resolution, which will cause ALPS touchpad to be significantly slower than Synaptics touchpads. Yep, Synaptics I think has 4-5x higher resolution. Similarly, the screen size used to be taken into account, but probably that was a mistake, since the value is usually left at default and doesn't correspond to the real screen size. I wonder if we should just add speed factor (along with tap distance) options to mousedev. Vojtech, will you take such patch? I know you want to drop mousedev and have everyone use evdev but, although people started switching, it will not happen until distributions (or XOrg/XFree themselves) have these drivers available straight out of the box. -- 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/
[RFC] Linux Kernel Subversion Howto
Hi, I've played lately a bit with Subversion and used it for managing the kernel sources, using Larry McVoy's bk2cvs bridge and Ben Collins' bkcvs2svn conversion script. Since there is little information on the web on how to properly set up a SVN repository and use it for tracking the latest kernel tree, I wrote a small howto (modeled after the bk kernel howto) in case it can be useful for other people too. Feel free to comment on it (but let's not start a new BK flamewar or SVN bashing session please). If there is enough interest I'll submit a patch to include this in the kernel Documentation/ directory. I've put it also on my web page along with the necessary scripts: http://popies.net/svn-kernel/ And now a question to Larry and whoever else is involved in the bkcvs mirror on kernel.org: what is the periodicity of the CVS repository update ? Stelian. -8---8-- This document is intended mainly for kernel developers, occasional or full-time, but sysadmins and power users may find parts of it useful as well. This in *not* intended to replace the Subversion documentation. Always run 'svn command --help' or browse the manual at http://svnbook.red-bean.com for reference documentation. But I thought the kernel used BitKeeper not Subversion ? Indeed, some kernel developers, including Linus, use BitKeeper to manage the kernel sources. The Linus BitKeeper repository (hosted on http://linux.bkbits.net) is the reference repository for the latest kernel code. However, BitKeeper is not free software. It is provided either free of charge under a restrictive license or under a classical commercial license. For more details, read the BitKeeper license. This document is intended for those who can't or don't want to use BitKeeper to follow the kernel development, but still want to use a SCM tool to: * keep up to date to Linus tree * easily consult change logs * do kernel related development and merge them with the latest Linus changes * etc... In this document, the SCM tool used is Subversion. How does it work ? -- Thanks to Larry McVoy of BitMover, the kernel metadata (change logs, authors etc) are not only available in the BitKeeper tree, but are also made available through a special BK to CVS bridge. In the past, this bridge was accessible using a CVS pserver running on cvs.kernel.org, but due to several reasons this was changed and the only way to access the CVS repository today is by using rsync from: rsync://rsync.kernel.org/pub/scm/linux/kernel/bkcvs/ Ben Collins wrote a small tool which converts the kernel CVS repository into a SVN repository. The same script can be used in an incremental fashion afterwards to keep the two repositories synchronized. How can I setup a SVN repository ? -- Get the CVS repository: rsync -avz --delete \ rsync://rsync.kernel.org/pub/scm/linux/kernel/bkcvs/linux-2.5/ \ /repos/kernel/linux-2.6-bkcvs Create the SVN repository: svnadmin create /repos/kernel/linux-2.6-svn Convert the CVS repository to SVN: bkcvs2svn -s \ /repos/kernel/linux-2.6-svn \ /repos/kernel/linux-2.6-bkcvs The previous step will take a LONG time. On my AMD64 2000+ it took about 8 hours to complete. But you'll have to pay this price only once, subsequent re-syncs will be much quicker. You also need about 500 MB of disk space for the CVS repository and 900 MB for the SVN one (example for a kernel 2.6.11). In addition, each working copy of this repository will take 650 MB. How do I access this repository ? - You can use the SVN repository just to track the Linus latest commits. The SVN repository is not easily readable, you will want to get a 'working copy' of it, by doing a 'svn checkout': svn checkout file://repos/kernel/linux-2.6-svn/trunk \ /home/user/kernel/linux-2.6-linus You will then have a full kernel source tree in '/home/user/kernel/linux-2.6-linus'. In this document the repository and the working copy are on the same machine, but this is not required. You can easily have the repository on a remote machine and access it using directly SVN (svnserve) or SSH (svn+ssh). Please refer to the SVN documentation for more details. How can I update the repository to the latest version ? --- The repository can be updated on real-time to show Linus latest commits in his BitKeeper tree. The CVS tree exported by BitMover is updated each XXX hours and you can rerun 'bkcvs2svn' in an incremental fashion, to get only the new changes insert them into the SVN repository. You will then just redo the 'rsync' and 'bkcvs2svn' steps and you will obtain a full updated SVN repository. (the script 'bk2svn' does just that, and
Re: Touchpad problems with 2.6.11-rc2
On Wed, Feb 02, 2005 at 10:51:38AM -0500, Dmitry Torokhov wrote: I wonder if we should just add speed factor (along with tap distance) options to mousedev. Vojtech, will you take such patch? I know you want to drop mousedev and have everyone use evdev but, although people started switching, it will not happen until distributions (or XOrg/XFree themselves) have these drivers available straight out of the box. I would be OK with that if we take the default from the touchpad resolution, so that the driver uses a reasonable value without having to use the speed parameter. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
[trimming the Cc: list] * Jack O'Quin [EMAIL PROTECTED] wrote: Remember when I asked how you handle changes to sizeof(struct rusage)? That was a serious question. I hope there's a solution. [...] Ingo Molnar [EMAIL PROTECTED] writes: what does any of what we've talking about have to do with struct rusage? Your previous message implied that userspace programmers don't understand binary compatibility... you might ask yourself, 'why is this so, and why cannot the Linux guys apply pretty much any hack as e.g. userspace code might' I was just demonstating that I do. Does getrusage() return anything for this? How can a field be added to the rusage struct without breaking binary compatibility? Can we assume that no programs ever use sizeof(struct rusage)? rlimits are easily extended and there are no binary compatibility worries. The kernel doesnt export the maximum towards userspace. getrusage() will return the value on new kernels and will return -EINVAL on old kernels, so new userspace can deal with this accordingly. (and here i meant getrlimit(), not getrusage() - getrusage() is not affected by the patch at all.) Well, that was source of my question. I had asked about rusage. You said it did return a new value, but that this was not a problem. That made no sense to me. Thank you for clearing it up. Certainly getrlimit() works OK. I understood that already. -- joq - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dm_snapshot experimental? potential repercussions?
Hello, I have been told that dm_snapshot is still experimental in the 2.6.10 kernel, and I was advised not to have more than one snapshot created at a time for the same logical volume. Basically I am just wondering what the potential problems are with dm_snapshot. Is there anything particular that I should look out for? Thanks for any advice, Kristina - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Linux Kernel Subversion Howto
(first sorry for my poor English) Very nice howto. It's useful for generic use of svn too. The notations about converting bk to svn is really interesting... nice job! Just a little error: How to I ignore temporary build files ? - to should be do I would add this rule as a personal cross-development tecnique: Before any kind of changes and commits, it would be good to update the repository to prevent incompatibilities in the code if previous changes was made by other developers. On Wed, 2 Feb 2005 16:54:04 +0100, Stelian Pop [EMAIL PROTECTED] wrote: Hi, I've played lately a bit with Subversion and used it for managing the kernel sources, using Larry McVoy's bk2cvs bridge and Ben Collins' bkcvs2svn conversion script. Since there is little information on the web on how to properly set up a SVN repository and use it for tracking the latest kernel tree, I wrote a small howto (modeled after the bk kernel howto) in case it can be useful for other people too. Feel free to comment on it (but let's not start a new BK flamewar or SVN bashing session please). If there is enough interest I'll submit a patch to include this in the kernel Documentation/ directory. I've put it also on my web page along with the necessary scripts: http://popies.net/svn-kernel/ And now a question to Larry and whoever else is involved in the bkcvs mirror on kernel.org: what is the periodicity of the CVS repository update ? Stelian. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory leak in 2.6.11-rc1?
Positive, I only applied this single two-line change. I'm not capable of messing with kernel code myself so I prefer not to. Probably just a lucky shot that the vesa didn't go nuts with nvidia before... O well, with a bit more o'those pharmaceutical drugs even this 80x25 doesn't look too bad. Hurray! Lennert On Wednesday 02 February 2005 17:00, Linus Torvalds wrote: On Wed, 2 Feb 2005, Lennert Van Alboom wrote: I applied the patch and it works like a charm. As a kinky side effect: before this patch, using a compiled-in vesa or vga16 framebuffer worked with the proprietary nvidia driver, whereas now tty1-6 are corrupt when not using 80x25. Strangeness :) It really sounds like you should lay off those pharmaceutical drugs ;) That is _strange_. Is it literally just this single pipe merging change that matters to you? No other changces? I don't see how it could _possibly_ make any difference at all to anything else. Linus pgpAEbNCIOoA0.pgp Description: PGP signature
Re: Memory leak in 2.6.11-rc1?
On Wed, 2 Feb 2005, Lennert Van Alboom wrote: I applied the patch and it works like a charm. As a kinky side effect: before this patch, using a compiled-in vesa or vga16 framebuffer worked with the proprietary nvidia driver, whereas now tty1-6 are corrupt when not using 80x25. Strangeness :) It really sounds like you should lay off those pharmaceutical drugs ;) That is _strange_. Is it literally just this single pipe merging change that matters to you? No other changces? I don't see how it could _possibly_ make any difference at all to anything else. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 2/3] Access Control Lists for tmpfs
Add access control lists for tmpfs. There is more code in tmpfs itself
than in the generic acl layer, but at least the acl handling
complexities are hidden from the filesystem.
Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED]
Index: linux-2.6.11-rc2-mm2/mm/shmem.c
===
--- linux-2.6.11-rc2-mm2.orig/mm/shmem.c
+++ linux-2.6.11-rc2-mm2/mm/shmem.c
@@ -1617,6 +1617,8 @@ static int shmem_statfs(struct super_blo
return 0;
}
+static void shmem_destroy_inode(struct inode *inode);
+
/*
* File creation. Allocate an inode, and we're done..
*/
@@ -1627,6 +1629,11 @@ shmem_mknod(struct inode *dir, struct de
int error = -ENOSPC;
if (inode) {
+ error = shmem_acl_init(inode, dir);
+ if (error) {
+ shmem_destroy_inode(inode);
+ return error;
+ }
if (dir-i_mode S_ISGID) {
inode-i_gid = dir-i_gid;
if (S_ISDIR(mode))
@@ -1993,6 +2000,9 @@ static int shmem_fill_super(struct super
sbinfo-free_inodes = inodes;
}
sb-s_xattr = shmem_xattr_handlers;
+#ifdef CONFIG_TMPFS_POSIX_ACL
+ sb-s_flags |= MS_POSIXACL;
+#endif
#else
sb-s_flags |= MS_NOUSER;
#endif
@@ -2037,6 +2047,7 @@ static void shmem_destroy_inode(struct i
/* only struct inode is valid if it's an inline symlink */
mpol_free_shared_policy(SHMEM_I(inode)-policy);
}
+ shmem_acl_destroy_inode(inode);
kmem_cache_free(shmem_inode_cachep, SHMEM_I(inode));
}
@@ -2047,6 +2058,10 @@ static void init_once(void *foo, kmem_ca
if ((flags (SLAB_CTOR_VERIFY|SLAB_CTOR_CONSTRUCTOR)) ==
SLAB_CTOR_CONSTRUCTOR) {
inode_init_once(p-vfs_inode);
+#ifdef CONFIG_TMPFS_POSIX_ACL
+ p-i_acl = NULL;
+ p-i_default_acl = NULL;
+#endif
}
}
@@ -2095,6 +2110,8 @@ static struct inode_operations shmem_ino
.listxattr = generic_listxattr,
.removexattr= generic_removexattr,
#endif
+ .setattr= shmem_setattr,
+ .permission = shmem_permission,
};
static struct inode_operations shmem_dir_inode_operations = {
@@ -2114,6 +2131,8 @@ static struct inode_operations shmem_dir
.listxattr = generic_listxattr,
.removexattr= generic_removexattr,
#endif
+ .setattr= shmem_setattr,
+ .permission = shmem_permission,
#endif
};
@@ -2124,6 +2143,8 @@ static struct inode_operations shmem_spe
.listxattr = generic_listxattr,
.removexattr= generic_removexattr,
#endif
+ .setattr= shmem_setattr,
+ .permission = shmem_permission,
};
static struct super_operations shmem_ops = {
@@ -2182,6 +2203,10 @@ static struct xattr_handler shmem_xattr_
#ifdef CONFIG_TMPFS_XATTR
static struct xattr_handler *shmem_xattr_handlers[] = {
+#ifdef CONFIG_TMPFS_POSIX_ACL
+ shmem_xattr_acl_access_handler,
+ shmem_xattr_acl_default_handler,
+#endif
#ifdef CONFIG_TMPFS_SECURITY
shmem_xattr_security_handler,
#endif
Index: linux-2.6.11-rc2-mm2/include/linux/shmem_fs.h
===
--- linux-2.6.11-rc2-mm2.orig/include/linux/shmem_fs.h
+++ linux-2.6.11-rc2-mm2/include/linux/shmem_fs.h
@@ -19,6 +19,10 @@ struct shmem_inode_info {
swp_entry_t i_direct[SHMEM_NR_DIRECT]; /* first blocks */
struct list_headswaplist; /* chain of maybes on swap */
struct inodevfs_inode;
+#ifdef CONFIG_TMPFS_POSIX_ACL
+ struct posix_acl*i_acl;
+ struct posix_acl*i_default_acl;
+#endif
};
struct shmem_sb_info {
@@ -34,4 +38,25 @@ static inline struct shmem_inode_info *S
return container_of(inode, struct shmem_inode_info, vfs_inode);
}
+#ifdef CONFIG_TMPFS_POSIX_ACL
+int shmem_setattr(struct dentry *, struct iattr *);
+int shmem_permission(struct inode *, int, struct nameidata *);
+int shmem_acl_init(struct inode *, struct inode *);
+void shmem_acl_destroy_inode(struct inode *);
+
+extern struct xattr_handler shmem_xattr_acl_access_handler;
+extern struct xattr_handler shmem_xattr_acl_default_handler;
+#else
+#define shmem_setattr NULL
+#define shmem_permission NULL
+
+static inline int shmem_acl_init(struct inode *inode, struct inode *dir)
+{
+ return 0;
+}
+void shmem_acl_destroy_inode(struct inode *inode)
+{
+}
+#endif /* CONFIG_TMPFS_POSIX_ACL */
+
#endif
Index: linux-2.6.11-rc2-mm2/fs/Kconfig
===
--- linux-2.6.11-rc2-mm2.orig/fs/Kconfig
+++ linux-2.6.11-rc2-mm2/fs/Kconfig
@@ -884,6 +884,19 @@ config TMPFS_XATTR
If unsure, say N.
+config TMPFS_POSIX_ACL
+ bool tmpfs POSIX Access Control Lists
+ depends on TMPFS_XATTR
+
[RFC][PATCH 3/3] Access Control Lists for /dev/pts
/dev/pts is somewhat special: there are no directories, and so we
don't need default acls.
Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED]
Index: linux-2.6.11-rc2-mm2/fs/devpts/inode.c
===
--- linux-2.6.11-rc2-mm2.orig/fs/devpts/inode.c
+++ linux-2.6.11-rc2-mm2/fs/devpts/inode.c
@@ -19,15 +19,43 @@
#include linux/tty.h
#include linux/devpts_fs.h
#include linux/xattr.h
+#include linux/generic_acl.h
#define DEVPTS_SUPER_MAGIC 0x1cd1
+#ifdef CONFIG_DEVPTS_POSIX_ACL
+static struct inode *
+devpts_alloc_inode(struct super_block *sb)
+{
+ struct devpts_inode_info *ei;
+ ei = kmalloc(sizeof(*ei), SLAB_KERNEL);
+ if (!ei)
+ return NULL;
+ inode_init_once(ei-vfs_inode);
+ ei-i_acl = NULL;
+ return ei-vfs_inode;
+}
+
+static void
+devpts_destroy_inode(struct inode *inode)
+{
+ struct devpts_inode_info *ei = DEVPTS_I(inode);
+ if (ei-i_acl)
+ posix_acl_release(ei-i_acl);
+ kfree(ei);
+}
+#endif /* CONFIG_DEVPTS_POSIX_ACL */
+
extern struct xattr_handler devpts_xattr_security_handler;
+extern struct xattr_handler devpts_xattr_acl_access_handler;
static struct xattr_handler *devpts_xattr_handlers[] = {
#ifdef CONFIG_DEVPTS_FS_SECURITY
devpts_xattr_security_handler,
#endif
+#ifdef CONFIG_DEVPTS_POSIX_ACL
+ devpts_xattr_acl_access_handler,
+#endif
NULL
};
@@ -38,6 +66,10 @@ static struct inode_operations devpts_fi
.listxattr = generic_listxattr,
.removexattr= generic_removexattr,
#endif
+#ifdef CONFIG_DEVPTS_POSIX_ACL
+ .setattr= devpts_setattr,
+ .permission = devpts_permission,
+#endif
};
static struct vfsmount *devpts_mnt;
@@ -89,6 +121,10 @@ static int devpts_remount(struct super_b
}
static struct super_operations devpts_sops = {
+#ifdef CONFIG_DEVPTS_POSIX_ACL
+ .alloc_inode= devpts_alloc_inode,
+ .destroy_inode = devpts_destroy_inode,
+#endif
.statfs = simple_statfs,
.remount_fs = devpts_remount,
};
@@ -117,6 +153,9 @@ devpts_fill_super(struct super_block *s,
inode-i_op = simple_dir_inode_operations;
inode-i_fop = simple_dir_operations;
inode-i_nlink = 2;
+#ifdef CONFIG_TMPFS_POSIX_ACL
+ s-s_flags |= MS_POSIXACL;
+#endif
devpts_root = s-s_root = d_alloc_root(inode);
if (s-s_root)
Index: linux-2.6.11-rc2-mm2/fs/devpts/Makefile
===
--- linux-2.6.11-rc2-mm2.orig/fs/devpts/Makefile
+++ linux-2.6.11-rc2-mm2/fs/devpts/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_UNIX98_PTYS) += devpts.o
devpts-$(CONFIG_UNIX98_PTYS) := inode.o
devpts-$(CONFIG_DEVPTS_FS_SECURITY)+= xattr_security.o
+devpts-$(CONFIG_DEVPTS_POSIX_ACL) += acl.o
Index: linux-2.6.11-rc2-mm2/include/linux/devpts_fs.h
===
--- linux-2.6.11-rc2-mm2.orig/include/linux/devpts_fs.h
+++ linux-2.6.11-rc2-mm2/include/linux/devpts_fs.h
@@ -17,6 +17,23 @@
#ifdef CONFIG_UNIX98_PTYS
+#ifdef CONFIG_DEVPTS_POSIX_ACL
+struct devpts_inode_info {
+ struct posix_acl*i_acl;
+ struct inodevfs_inode;
+};
+
+static inline struct devpts_inode_info *DEVPTS_I(struct inode *inode)
+{
+ return container_of(inode, struct devpts_inode_info, vfs_inode);
+}
+
+/* acl.c */
+int devpts_setattr(struct dentry *, struct iattr *);
+int devpts_permission(struct inode *, int, struct nameidata *);
+#endif /* CONFIG_DEVPTS_POSIX_ACL */
+
+/* inode.c */
int devpts_pty_new(struct tty_struct *tty); /* mknod in devpts */
struct tty_struct *devpts_get_tty(int number); /* get tty structure */
void devpts_pty_kill(int number); /* unlink */
Index: linux-2.6.11-rc2-mm2/fs/Kconfig
===
--- linux-2.6.11-rc2-mm2.orig/fs/Kconfig
+++ linux-2.6.11-rc2-mm2/fs/Kconfig
@@ -850,6 +850,19 @@ config DEVPTS_FS_XATTR
If unsure, say N.
+config DEVPTS_POSIX_ACL
+ bool /dev/pts POSIX Access Control Lists
+ depends on DEVPTS_FS_XATTR
+ select GENERIC_ACL
+ help
+ POSIX Access Control Lists (ACLs) support permissions for users and
+ groups beyond the owner/group/world scheme.
+
+ To learn more about Access Control Lists, visit the POSIX ACLs for
+ Linux website http://acl.bestbits.at/.
+
+ If you don't know what Access Control Lists are, say N.
+
config DEVPTS_FS_SECURITY
bool /dev/pts Security Labels
depends on DEVPTS_FS_XATTR
Index: linux-2.6.11-rc2-mm2/fs/devpts/acl.c
===
--- /dev/null
+++ linux-2.6.11-rc2-mm2/fs/devpts/acl.c
@@ -0,0 +1,112 @@
+/*
+ * fs/devpts/acl.c
+ *
+ * (C) 2005 Andreas Gruenbacher [EMAIL PROTECTED]
+ *
+ * This file is released
[RFC][PATCH 1/3] Generic infrastructure for acls
Add some infrastructure for access control lists on in-memory
filesystems such as tmpfs and devpts. We can probably also use
this code from ext2 and ext3, but this hasn't been started, yet.
Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED]
Index: linux-2.6.11-rc2-mm2/fs/Kconfig
===
--- linux-2.6.11-rc2-mm2.orig/fs/Kconfig
+++ linux-2.6.11-rc2-mm2/fs/Kconfig
@@ -1809,6 +1809,10 @@ config AFS_FSCACHE
config RXRPC
tristate
+config GENERIC_ACL
+ bool
+ select FS_POSIX_ACL
+
endmenu
menu Partition Types
Index: linux-2.6.11-rc2-mm2/fs/Makefile
===
--- linux-2.6.11-rc2-mm2.orig/fs/Makefile
+++ linux-2.6.11-rc2-mm2/fs/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_BINFMT_FLAT) += binfmt_flat
obj-$(CONFIG_FS_MBCACHE) += mbcache.o
obj-$(CONFIG_FS_POSIX_ACL) += posix_acl.o xattr_acl.o
+obj-$(CONFIG_GENERIC_ACL) += generic_acl.o
obj-$(CONFIG_NFS_ACL_SUPPORT) += nfsacl.o
obj-$(CONFIG_QUOTA)+= dquot.o
Index: linux-2.6.11-rc2-mm2/include/linux/generic_acl.h
===
--- /dev/null
+++ linux-2.6.11-rc2-mm2/include/linux/generic_acl.h
@@ -0,0 +1,30 @@
+/*
+ * fs/generic_acl.c
+ *
+ * (C) 2005 Andreas Gruenbacher [EMAIL PROTECTED]
+ *
+ * This file is released under the GPL.
+ */
+
+#ifndef GENERIC_ACL_H
+#define GENERIC_ACL_H
+
+#include linux/posix_acl.h
+#include linux/xattr_acl.h
+
+struct generic_acl_operations {
+ struct posix_acl *(*getacl)(struct inode *, int);
+ void (*setacl)(struct inode *, int, struct posix_acl *);
+};
+
+size_t generic_acl_list(struct inode *, struct generic_acl_operations *, int,
+ char *, size_t);
+int generic_acl_get(struct inode *, struct generic_acl_operations *, int,
+ void *, size_t);
+int generic_acl_set(struct inode *, struct generic_acl_operations *, int,
+ const void *, size_t);
+int generic_acl_init(struct inode *, struct inode *,
+struct generic_acl_operations *);
+int generic_acl_chmod(struct inode *, struct generic_acl_operations *);
+
+#endif
Index: linux-2.6.11-rc2-mm2/fs/generic_acl.c
===
--- /dev/null
+++ linux-2.6.11-rc2-mm2/fs/generic_acl.c
@@ -0,0 +1,172 @@
+/*
+ * fs/generic_acl.c
+ *
+ * (C) 2005 Andreas Gruenbacher [EMAIL PROTECTED]
+ *
+ * This file is released under the GPL.
+ */
+
+#include linux/sched.h
+#include linux/fs.h
+#include linux/generic_acl.h
+
+size_t
+generic_acl_list(struct inode *inode, struct generic_acl_operations *ops,
+int type, char *list, size_t list_size)
+{
+ struct posix_acl *acl;
+ const char *name;
+ size_t size;
+
+ acl = ops-getacl(inode, type);
+ if (!acl)
+ return 0;
+ posix_acl_release(acl);
+
+ switch(type) {
+ case ACL_TYPE_ACCESS:
+ name = XATTR_NAME_ACL_ACCESS;
+ break;
+
+ case ACL_TYPE_DEFAULT:
+ name = XATTR_NAME_ACL_DEFAULT;
+ break;
+
+ default:
+ return 0;
+ }
+ size = strlen(name) + 1;
+ if (list size = list_size)
+ memcpy(list, name, size);
+ return size;
+}
+
+int
+generic_acl_get(struct inode *inode, struct generic_acl_operations *ops,
+ int type, void *buffer, size_t size)
+{
+ struct posix_acl *acl;
+ int error;
+
+ acl = ops-getacl(inode, type);
+ if (!acl)
+ return -ENODATA;
+ error = posix_acl_to_xattr(acl, buffer, size);
+ posix_acl_release(acl);
+
+ return error;
+}
+
+int
+generic_acl_set(struct inode *inode, struct generic_acl_operations *ops,
+ int type, const void *value, size_t size)
+{
+ struct posix_acl *acl = NULL;
+ int error;
+
+ if (S_ISLNK(inode-i_mode))
+ return -EOPNOTSUPP;
+ if ((current-fsuid != inode-i_uid) !capable(CAP_FOWNER))
+ return -EPERM;
+ if (value) {
+ acl = posix_acl_from_xattr(value, size);
+ if (IS_ERR(acl))
+ return PTR_ERR(acl);
+ }
+ if (acl) {
+ mode_t mode;
+
+ error = posix_acl_valid(acl);
+ if (error)
+ goto failed;
+ switch(type) {
+ case ACL_TYPE_ACCESS:
+ mode = inode-i_mode;
+ error = posix_acl_equiv_mode(acl, mode);
+ if (error 0)
+ goto failed;
+ inode-i_mode = mode;
+ if (error == 0) {
+
[RFC][PATCH 0/3] Access Control Lists for tmpfs and /dev/pts
Here is a set of three patches which implement some general infrastructure and on top of that, acls for tmpfs and /dev/pts files. We may want to factor out some of the current ext2 and ext3 acl code and use the generic layer instead. Comments welcome. Regards, -- Andreas Gruenbacher [EMAIL PROTECTED] SUSE Labs, SUSE LINUX PRODUCTS GMBH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2] Move linux/prio_tree.h down in linux/fs.h
On Tue, 2005-02-01 at 09:06 -0700, Tom Rini wrote: linux/prio_tree.h is unsafe for inclusion by userland apps, but it is in the userland-exposed portion of linux/fs.h. It's only needed in the __KERNEL__ protected portion of the file, so move the #include down to there. You accidentally posted this patch to the kernel list, not to the maintainers of the libc-kernelheaders package. And you might as well just remove the offending #include rather than moving it to a section of the file which is never used. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
automated response
THIS IS AN AUTOMATED RESPONSE. DO NOT RESPOND TO THIS EMAIL. Thank you for your comments. Customer Service emails are answered in the order in which they are received. The department is closed on weekends and holidays and there will be a delay in response for comments sent during these times. Replies are not instantaneous and are usually answered within 72 hours. IMPORTANT: We do not generally credit more than one or two minutes for shows with problems if you have chosen to continue to stay in the show. Please log off immediately to get full refunds for problems or technical issues. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser [EMAIL PROTECTED] wrote: Thanks for the tip, I hadn't heard about it. I will take a look, but only to see if it can show me the user space API of /dev/fb. I don't need a general library that supports a bunch of different graphics cards. I'm writing my own frame buffer driver for the GX2 CPU, and I just want to know how to call the various functions registered in struct fb_ops, so that I can test my code. I mean, all those functions registered in fb_ops must be accessible somehow; if they weren't, what purpose would they serve? You should look at writing a DRM driver. DRM implements the kernel interface to get 3D hardware running. It is a fully accelerated driver interface. They are located in drivers/char/drm -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2] Move linux/prio_tree.h down in linux/fs.h
On Wed, Feb 02, 2005 at 04:21:23PM +, David Woodhouse wrote: On Tue, 2005-02-01 at 09:06 -0700, Tom Rini wrote: linux/prio_tree.h is unsafe for inclusion by userland apps, but it is in the userland-exposed portion of linux/fs.h. It's only needed in the __KERNEL__ protected portion of the file, so move the #include down to there. You accidentally posted this patch to the kernel list, not to the maintainers of the libc-kernelheaders package. And you might as well just remove the offending #include rather than moving it to a section of the file which is never used. Ignoring your hint for a moment, since __KERNEL__ is still scattered all over the place, and I haven't see anything (changeset-wise) adding You must use libc-kernelheaders now in Documentation/feature-removal-schedule.txt this is still an actual problem. Thanks. Feel free to correct me by getting something added to Documentation/feature-removal-schedule.txt :) -- Tom Rini http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Linux Kernel Subversion Howto
(first sorry for my poor English) Very nice howto. It's useful for generic use of svn too. The notations about converting bk to svn is really interesting... nice job! Just a little error: How to I ignore temporary build files ? - to should be do I would add this rule as a personal cross-development tecnique: Before any kind of changes and commits, it would be good to update the repository to prevent incompatibilities in the code if previous changes was made by other developers. On Wed, 2 Feb 2005 16:54:04 +0100, Stelian Pop [EMAIL PROTECTED] wrote: Hi, I've played lately a bit with Subversion and used it for managing the kernel sources, using Larry McVoy's bk2cvs bridge and Ben Collins' bkcvs2svn conversion script. Since there is little information on the web on how to properly set up a SVN repository and use it for tracking the latest kernel tree, I wrote a small howto (modeled after the bk kernel howto) in case it can be useful for other people too. Feel free to comment on it (but let's not start a new BK flamewar or SVN bashing session please). If there is enough interest I'll submit a patch to include this in the kernel Documentation/ directory. I've put it also on my web page along with the necessary scripts: http://popies.net/svn-kernel/ And now a question to Larry and whoever else is involved in the bkcvs mirror on kernel.org: what is the periodicity of the CVS repository update ? Stelian. -- FyreBird Hosting Provider Technical Department Italian Open Source Network Founder - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
Bill Huey (hui) [EMAIL PROTECTED] writes: Also, as media apps get more sophisticated they're going to need some kind of access to the some traditional softirq facilities, possibily migrating it into userspace safely somehow, with how it handles IO processing such as iSCSI, FireWire, networking and all peripherals that need some kind of prioritized IO handling. It's akin to O_DIRECT, where folks need to determine policy over the kernel's own facilities, IO queues, but in a more broad way. This is inevitable for these category of apps. Scary ? yes I know. I believe Ingo's RT patches already support this on a per-IRQ basis. Each IRQ handler can run in a realtime thread with priority assigned by the sysadmin. Balancing the interrupt handler priorities with those of other realtime activities allows excellent control. This is really only useful within the context of a dedicated realtime system, of course. Stephane Letz reports a similar feature in Mac OS X. Whether this suitable for main stream inclusion is another matter. But as a person that wants to write apps of this nature, I came into this kernel stuff knowing that there's going to be a conflict between the the needs of media apps folks and what the Linux kernel folks will tolerate as a community. That's a price both groups pay for doing realtime within the context of a general-purpose OS. But, for many, many applications it's the best option. Fortunately, most of what we need also improves the general quality and responsiveness of the kernel. The important things like short lock hold times are really just good concurrent programming practice. The cost/performance characteristics of commodity PC's running Linux are quite compelling for a wide range of practical realtime applications. But, these are dedicated machines. The whole system must be carefully tuned. That is the only method that actually works. The scheduler is at most a peripheral concern; the best it can do is not screw up. It's very compelling and very deadly to the industry if these things become common place in the normal Linux kernel. It would instantly make Linux the top platform for anything media related, graphic and audio. Yes, many people want to take advantage of this. -- joq - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to add usbmon
Hi Pete, I think if cat is the prefered tool for viewing this file then it should be more human readable. If not, then a binary format should be choosen. Maybe we can implement both. Is this possible? Yes. Now you know why files were split as they were. still no reason for me to split things up. But if you or someone else were to hack on something like usbdump(1), it would be peachy, I think. I can start with usbdump if we agree on an interface. I personally would prefer a binary interface for that. If you want to start scoping it, it's fine by me. I was going to concentrate on fixing what's needed first, such as getting control setup packets captured and things like that. While I am really thinking about starting usbdump, I may ask why you have choosen to use debugfs as interface. This will not be available in normal distribution kernels and I think a general USB monitoring ability would be great. For example like we have it for Ethernet, Bluetooth and IrDA. So my idea is to create some /dev/usbmonX (for each bus one) where usbdump can read its information from. What do you think? 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: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: your concerns would be valid if this was impossible to achieve by an exploit, sadly, you'd be wrong too, it's possible to force an exploited application to call something like dl_make_stack_executable() and then execute the shellcode. [...] and how do you force a program to call that function and then to execute your shellcode? In other words: i challenge you to show a working (simulated) exploit on Fedora (on the latest fc4 devel version, etc.) that does that. You can simulate the overflow itself so no need to find any real application vulnerability, but show me _working code_ (or a convincing description) that can call glibc's do_make_stack_executable() (or the 'many ways of doing this'), _and_ will end up executing your shell code as well. if you can do this i fully accept there's a problem. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote: Well, you removed the scaling to the touchpad resolution, which will cause ALPS touchpad to be significantly slower than Synaptics touchpads. Similarly, the screen size used to be taken into account, but probably that was a mistake, since the value is usually left at default and doesn't correspond to the real screen size. Exactly. And it works much better now. -- 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: [RFC][PATCH 0/3] Access Control Lists for tmpfs and /dev/pts
On Wed, Feb 02, 2005 at 05:13:40PM +0100, Andreas Gruenbacher wrote: Here is a set of three patches which implement some general infrastructure and on top of that, acls for tmpfs and /dev/pts files. Why would you want ACLs on /dev/pts? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
On Wed, Feb 02, 2005 at 08:56:28AM -0800, Pete Zaitcev wrote: On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote: Well, you removed the scaling to the touchpad resolution, which will cause ALPS touchpad to be significantly slower than Synaptics touchpads. Similarly, the screen size used to be taken into account, but probably that was a mistake, since the value is usually left at default and doesn't correspond to the real screen size. Exactly. And it works much better now. With a Synaptics I suppose? You wouldn't like it with an ALPS. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][I2C] Marvell mv64xxx i2c driver
Alexey Dobriyan wrote:
On Tue, 01 Feb 2005 10:54:32 -0700, Mark A. Greer wrote:
+struct mv64xxx_i2c_data {
+ void *reg_base;
ioremap() returns void __iomem *.
Okay.
+static void __devexit
+mv64xxx_i2c_unmap_regs(struct mv64xxx_i2c_data *drv_data)
+{
+ if (!drv_data-reg_base) {
+ iounmap(drv_data-reg_base);
A typo? You're unmapping known to be invalid address.
Yes, a typo. Good catch.
+ drv_data-reg_base = 0;
Use NULL because drv_data-reg_base is a pointer.
Done.
+ if ((pd-id == 0) pdata) {
Rewrite this as:
if ((pd-id != 0) || !pdata)
return -ENODEV;
and save one level of indentation below.
Done.
snip of xxx_probe modifications
Done.
Alexey
P. S.: struct mv64xxx_i2c_data revisited...
+ uint state;
+ ulong reg_base_p;
Silly request, but... Maybe this should be changed to plain old unsigned
int
and unsigned long. Please. I just don't understand why people use uint,
u_int, uInt, UINT, uINT, uint_t which are always typedef'ed to
unsigned int.
Thanks Alexey Greg. How's this (a complete replacement for previous
patch)?
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
--
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig2005-02-02 10:24:30 -07:00
+++ b/drivers/i2c/busses/Kconfig2005-02-02 10:24:30 -07:00
@@ -476,4 +476,14 @@
This driver can also be built as a module. If so, the module
will be called i2c-pca-isa.
+config I2C_MV64XXX
+ tristate Marvell mv64xxx I2C Controller
+ depends on I2C MV64X60 EXPERIMENTAL
+ help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Marvell 64xxx line of host bridges
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mv64xxx.
+
endmenu
diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
--- a/drivers/i2c/busses/Makefile 2005-02-02 10:24:30 -07:00
+++ b/drivers/i2c/busses/Makefile 2005-02-02 10:24:30 -07:00
@@ -20,6 +20,7 @@
obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o
obj-$(CONFIG_I2C_KEYWEST) += i2c-keywest.o
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
+obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o
obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o
obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/busses/i2c-mv64xxx.c 2005-02-02 10:24:30 -07:00
@@ -0,0 +1,615 @@
+/*
+ * drivers/i2c/busses/i2c-mv64xxx.c
+ *
+ * Driver for the i2c controller on the Marvell line of host bridges for MIPS
+ * and PPC (e.g, gt642[46]0, mv643[46]0, mv644[46]0).
+ *
+ * Author: Mark A. Greer [EMAIL PROTECTED]
+ *
+ * 2005 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed as is without any warranty of any kind, whether express
+ * or implied.
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/spinlock.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/mv643xx.h
+#include asm/io.h
+
+/* Register defines */
+#defineMV64XXX_I2C_REG_SLAVE_ADDR 0x00
+#defineMV64XXX_I2C_REG_DATA0x04
+#defineMV64XXX_I2C_REG_CONTROL 0x08
+#defineMV64XXX_I2C_REG_STATUS 0x0c
+#defineMV64XXX_I2C_REG_BAUD0x0c
+#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR 0x10
+#defineMV64XXX_I2C_REG_SOFT_RESET 0x1c
+
+#defineMV64XXX_I2C_REG_CONTROL_ACK 0x0004
+#defineMV64XXX_I2C_REG_CONTROL_IFLG0x0008
+#defineMV64XXX_I2C_REG_CONTROL_STOP0x0010
+#defineMV64XXX_I2C_REG_CONTROL_START 0x0020
+#defineMV64XXX_I2C_REG_CONTROL_TWSIEN 0x0040
+#defineMV64XXX_I2C_REG_CONTROL_INTEN 0x0080
+
+/* Ctlr status values */
+#defineMV64XXX_I2C_STATUS_BUS_ERR 0x00
+#defineMV64XXX_I2C_STATUS_MAST_START 0x08
+#defineMV64XXX_I2C_STATUS_MAST_REPEAT_START0x10
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_NO_ACK 0x20
+#defineMV64XXX_I2C_STATUS_MAST_WR_ACK 0x28
+#defineMV64XXX_I2C_STATUS_MAST_WR_NO_ACK 0x30
+#defineMV64XXX_I2C_STATUS_MAST_LOST_ARB0x38
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_ACK 0x40
+#define
Re: dm_snapshot experimental? potential repercussions?
On Wed, Feb 02, 2005 at 11:02:49AM -0500, Kristina Clair wrote: I have been told that dm_snapshot is still experimental in the 2.6.10 kernel, and I was advised not to have more than one snapshot created at a time for the same logical volume. Each snapshot is independent and keeps its own separate copy of changes, so as you increase the number of parallel snapshots you quickly affect performance. This has always been the case for LVM and device-mapper snapshots. Daniel Phillips is working on a clustered snapshot implementation which at the same time addresses this issue, allowing parallel snapshots to share their metadata. Basically I am just wondering what the potential problems are with dm_snapshot. Is there anything particular that I should look out for? There are numerous memory allocation issues with the current dm-snapshot implementation: in simple terms, devices or your machine can lock up, and your system is especially vulnerable when snapshots are manipulated (create/activate) and when your system is under load. We think we understand the most important problems and are gradually fixing them, but this is not a quick process because the changes have a significant impact on the LVM2 and EVMS code bases (complex sequences of ioctls have to change). Join the dm-devel mailing list if you want to monitor progress. Alasdair -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/3] Access Control Lists for tmpfs and /dev/pts
On Wed, 2005-02-02 at 17:55, Christoph Hellwig wrote: On Wed, Feb 02, 2005 at 05:13:40PM +0100, Andreas Gruenbacher wrote: Here is a set of three patches which implement some general infrastructure and on top of that, acls for tmpfs and /dev/pts files. Why would you want ACLs on /dev/pts? That's actually a good question. The patch allows to give several people access to the same terminal, which sometimes comes in handy with tools like screen (at least in its current version), and that's what the patch originally was meant for. I've just talked this over this with one of the maintainers though, and there are probably better ways than handling this at the file permission level, like passing open file descriptors between processes. So unless somebody comes up with a convincing application, that patch probably should stay out. Cheers, -- Andreas Gruenbacher [EMAIL PROTECTED] SUSE Labs, SUSE LINUX GMBH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
[Jon Smirl] On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser [EMAIL PROTECTED] wrote: Thanks for the tip, I hadn't heard about it. I will take a look, but only to see if it can show me the user space API of /dev/fb. I don't need a general library that supports a bunch of different graphics cards. I'm writing my own frame buffer driver for the GX2 CPU, and I just want to know how to call the various functions registered in struct fb_ops, so that I can test my code. I mean, all those functions registered in fb_ops must be accessible somehow; if they weren't, what purpose would they serve? You should look at writing a DRM driver. DRM implements the kernel interface to get 3D hardware running. It is a fully accelerated driver interface. They are located in drivers/char/drm Have the standard frame buffer drivers been abandoned, even for devices that have no 3D acceleration (like the Geode GX2)? I took a quick look at the DRM stuff, and it looked like extreme overkill for what I need, if it even can be used for what I want to do. At first glance it looked like this is only relevant for OpenGL/X11 3D-stuff, which I have absolutely no use for. GX2 is an integrated CPU/graphics chip for embedded systems. We have third party applications that use the framebuffer device, and I was hoping to make things faster by writing an accelerated driver. The only thing I need answered is how to access fb_ops from userspace. If that is impossible because all the framebuffer code is leftover junk that no one uses anymore, or even /can/ use anymore because the userspace interface is gone, please let me know now so I don't have to waste any more time. -- Haakon - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory leak in 2.6.11-rc1?
I think there's still something funky going on in the pipe code, at least in 2.6.11-rc2-mm2, which does contain the misordered __free_page() fix in pipe.c. I'm noticing any leak pretty easily because I'm attempting memory removal of highmem areas, and these apparently leaked pipe pages the only things keeping those from succeeding. In any case, I'm running a horribly hacked up kernel, but this is certainly a new problem, and not one that I've run into before. Here's output from the new CONFIG_PAGE_OWNER code: Page (e0c4f8b8) pfn: 00566606 allocated via order 0 [0xc0162ef6] pipe_writev+542 [0xc0157f48] do_readv_writev+288 [0xc0163114] pipe_write+0 [0xc0134484] ltt_log_event+64 [0xc0158077] vfs_writev+75 [0xc01581ac] sys_writev+104 [0xc0102430] no_syscall_entry_trace+11 And some more information about the page (yes, it's in the vmalloc space) page: e0c4f8b8 pfn: 0008a54e 566606 count: 1 mapcount: 0 index: 786431 mapping: private: lru-prev: 00200200 lru-next: 00100100 PG_locked: 0 PG_error: 0 PG_referenced: 0 PG_uptodate:0 PG_dirty: 0 PG_lru: 0 PG_active: 0 PG_slab:0 PG_highmem: 1 PG_checked: 0 PG_arch_1: 0 PG_reserved:0 PG_private: 0 PG_writeback: 0 PG_nosave: 0 PG_compound:0 PG_swapcache: 0 PG_mappedtodisk:0 PG_reclaim: 0 PG_nosave_free: 0 PG_capture: 1 -- Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote: On Wed, Feb 02, 2005 at 08:56:28AM -0800, Pete Zaitcev wrote: On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote: Well, you removed the scaling to the touchpad resolution, which will cause ALPS touchpad to be significantly slower than Synaptics touchpads. Similarly, the screen size used to be taken into account, but probably that was a mistake, since the value is usually left at default and doesn't correspond to the real screen size. Exactly. And it works much better now. With a Synaptics I suppose? You wouldn't like it with an ALPS. No, it's a Dualpoint, and so ALPS. But never mind that, I think I see your point. However, while I see a possibility of serious regressions with the other variety, but isn't it striking that result is so radical? With all the arithmetics still in place I can move my finger all across the pad without causing any motions. We are not talking about ballistics or any fine tuning, simply the calculations are wrong. Let me add more, too. As long as the touchpad code in mousedev.c converts absolute mode data into relative events, there's no reason to scale _to the size of the screen_. Don't you see? User needs a scaling to the sensitivity, not the screen size. I have never seen a touchpad which allowed you to cross the screen in one motion if you moved it slowly, this is why acceleration feature exists. It's completely bogus. Scaling to the size of the screen would have made sense if we used touchpad to generate absolute events, as some sort of a miniature Wacom pad. In such a case, you wouldn't be able to reach corners of the screen without scaling. But a touchpad is operated in entirely different way. If Synaptics delivers much bigger deltas for small motions, it's up to the Synapics mode of alps.c to make them reasonable, if that. There's no need to penalize ALPS. But I seriously doubt that Synaptics can be so broken. I wish Peter tested the removal of scaling with his Synaptics. If he (and Dmitry) insist on running a special code in X, that's fine. But honestly, I expect that things will go well for them. -- 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: [PATCH 2.6.11-rc2] Move linux/prio_tree.h down in linux/fs.h
On Wed, Feb 02, 2005 at 09:34:21AM -0700, Tom Rini wrote:
On Wed, Feb 02, 2005 at 04:21:23PM +, David Woodhouse wrote:
On Tue, 2005-02-01 at 09:06 -0700, Tom Rini wrote:
linux/prio_tree.h is unsafe for inclusion by userland apps, but it
is in the userland-exposed portion of linux/fs.h. It's only needed
in the __KERNEL__ protected portion of the file, so move the #include
down to there.
You accidentally posted this patch to the kernel list, not to the
maintainers of the libc-kernelheaders package. And you might as well
just remove the offending #include rather than moving it to a section of
the file which is never used.
Ignoring your hint for a moment, since __KERNEL__ is still scattered all
over the place, and I haven't see anything (changeset-wise) adding You
must use libc-kernelheaders now in Documentation/feature-removal-schedule.txt
this is still an actual problem. Thanks.
Feel free to correct me by getting something added to
Documentation/feature-removal-schedule.txt :)
After talking with David a bit off-list, I'd like to ask that my
original patch get pushed in time for 2.6.11, and the following a bit
later (or now, that's fine too :)) (splitting the reverse was ~1400
lines in fs_kern.h in ~200 in fs.h).
Signed-off-by: Tom Rini [EMAIL PROTECTED]
include/linux/fs_user.h | 197 +
include/linux/fs.h | 209 ++--
2 files changed, 209 insertions(+), 197 deletions(-)
--- 1.377/include/linux/fs.h2005-01-25 14:43:48 -07:00
+++ edited/include/linux/fs.h 2005-02-02 10:42:06 -07:00
@@ -3,9 +3,13 @@
/*
* This file has definitions for some important file table
- * structures etc.
+ * structures etc. Any userspace visiable changes must go into
+ * linux/fs_user.h
*/
+#include linux/fs_user.h
+
+#ifdef __KERNEL__
#include linux/config.h
#include linux/linkage.h
#include linux/limits.h
@@ -16,9 +20,15 @@
#include linux/dcache.h
#include linux/stat.h
#include linux/cache.h
-#include linux/prio_tree.h
#include linux/kobject.h
+#include linux/list.h
+#include linux/radix-tree.h
+#include linux/prio_tree.h
+#include linux/audit.h
+#include linux/init.h
#include asm/atomic.h
+#include asm/semaphore.h
+#include asm/byteorder.h
struct iovec;
struct nameidata;
@@ -28,201 +38,6 @@
struct vm_area_struct;
struct vfsmount;
-/*
- * It's silly to have NR_OPEN bigger than NR_FILE, but you can change
- * the file limit at runtime and only root can increase the per-process
- * nr_file rlimit, so it's safe to set up a ridiculously high absolute
- * upper limit on files-per-process.
- *
- * Some programs (notably those using select()) may have to be
- * recompiled to take full advantage of the new limits..
- */
-
-/* Fixed constants first: */
-#undef NR_OPEN
-#define NR_OPEN (1024*1024)/* Absolute upper limit on fd num */
-#define INR_OPEN 1024 /* Initial setting for nfile rlimits */
-
-#define BLOCK_SIZE_BITS 10
-#define BLOCK_SIZE (1BLOCK_SIZE_BITS)
-
-/* And dynamically-tunable limits and defaults: */
-struct files_stat_struct {
- int nr_files; /* read only */
- int nr_free_files; /* read only */
- int max_files; /* tunable */
-};
-extern struct files_stat_struct files_stat;
-
-struct inodes_stat_t {
- int nr_inodes;
- int nr_unused;
- int dummy[5];
-};
-extern struct inodes_stat_t inodes_stat;
-
-extern int leases_enable, lease_break_time;
-
-#ifdef CONFIG_DNOTIFY
-extern int dir_notify_enable;
-#endif
-
-#define NR_FILE 8192 /* this can well be larger on a larger system */
-
-#define MAY_EXEC 1
-#define MAY_WRITE 2
-#define MAY_READ 4
-#define MAY_APPEND 8
-
-#define FMODE_READ 1
-#define FMODE_WRITE 2
-
-/* Internal kernel extensions */
-#define FMODE_LSEEK4
-#define FMODE_PREAD8
-#define FMODE_PWRITE FMODE_PREAD /* These go hand in hand */
-
-#define RW_MASK1
-#define RWA_MASK 2
-#define READ 0
-#define WRITE 1
-#define READA 2/* read-ahead - don't block if no resources */
-#define SPECIAL 4 /* For non-blockdevice requests in request queue */
-#define READ_SYNC (READ | (1 BIO_RW_SYNC))
-#define WRITE_SYNC (WRITE | (1 BIO_RW_SYNC))
-#define WRITE_BARRIER ((1 BIO_RW) | (1 BIO_RW_BARRIER))
-
-#define SEL_IN 1
-#define SEL_OUT2
-#define SEL_EX 4
-
-/* public flags for file_system_type */
-#define FS_REQUIRES_DEV 1
-#define FS_BINARY_MOUNTDATA 2
-#define FS_REVAL_DOT 16384 /* Check the paths ., .. for staleness */
-#define FS_ODD_RENAME 32768 /* Temporary stuff; will go away as soon
- * as nfs_rename() will be cleaned up
- */
-/*
- * These are the fs-independent mount-flags: up to 32 flags are supported
- */
-#define MS_RDONLY 1 /* Mount read-only */
-#define MS_NOSUID 2 /* Ignore suid and
Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)
On Wed, Feb 02, 2005 at 10:18:27PM +1000, [EMAIL PROTECTED] wrote: your concerns would be valid if this was impossible to achieve by an exploit, sadly, you'd be wrong too, it's possible to force an exploited application to call something like dl_make_stack_executable() and then execute the shellcode. If you can call mprotect() with a protected environment to unprotect it, you can as easily call exec. OG. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
buggy mlock() behaviour in 2.6.9 on ppc64?
I've got a simple test app that tries to mmap() and mlock() an amount of memory specified on the commandline. If I specify more than the amount of physical memory in the system, I get different behaviours between ppc and ppc64. With the ppc kernel, my mmap() call will eventually fail and return MAP_FAILED. With the ppc64 kernel, however, the system hangs, and the fans speed starts increasing. It seems like it doesn't realize that there is simply no way that it will ever be able to succeed. Is this expected behaviour for ppc64? Chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Joe User DOS kills Linux-2.6.10
When I compile and run the following program:
#include stdio.h
int main(int x, char **y)
{
pause();
}
... as:
./xxx `yes`
... the following occurs after about 30 seconds (your mileage
may vary):
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 34605780
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x2100101, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 34603748
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x2100103, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 34606804
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x213d5cd, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 33943668
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x213d5ce, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 33943676
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x213d5cf, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 33943684
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x213d5d0, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 33943692
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x2149672, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 9437375
Buffer I/O error on device sdb1, logical block 1179664
lost page write due to I/O error on sdb1
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x2149673, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 34903668
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x214967c, Current sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 34903676
This device, /dev/sdb1 is one of the mounted file-systems.
It is not being accessed. The root filesystem is on
an IDE drive (/proc/mounts):
rootfs / rootfs rw 0 0
/dev/root.old /initrd ext2 rw 0 0
/dev/root / ext3 rw 0 0
/proc /proc proc rw,nodiratime 0 0
/sys /sys sysfs rw 0 0
none /dev/pts devpts rw 0 0
none /dev/shm tmpfs rw 0 0
/dev/sdb1 /home/project ext2 rw 0 0
/dev/sda1 /dos/drive_C msdos rw,nodiratime,fmask=0022,dmask=0022 0 0
/dev/sda5 /dos/drive_D msdos rw,nodiratime,fmask=0022,dmask=0022 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
This continues until the system is too sick to even be re-booted
from the console. It requires the reset switch.
It looks like the command-line argument is probably overflowing
something in the kernel, resulting in non-related problems.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Memory leak in 2.6.11-rc1?
On Wed, 2 Feb 2005, Dave Hansen wrote: In any case, I'm running a horribly hacked up kernel, but this is certainly a new problem, and not one that I've run into before. Here's output from the new CONFIG_PAGE_OWNER code: Hmm.. Everything looks fine. One new thing about the pipe code is that it historically never allocated HIGHMEM pages, and the new code no longer cares and thus can allocate anything. So there's nothing strange in your output that I can see. How many of these pages do you see? It's normal for a single pipe to be associated with up to 16 pages (although that would only happen if there is no reader or a slow reader, which is obviously not very common). Now, if your memory freeing code depends on the fact that all HIGHMEM pages are always freeable (page cache + VM mappings only), then yes, the new pipe code introduces highmem pages that weren't highmem before. But such long-lived and unfreeable pages have been there before too: kernel modules (or any other vmalloc() user, for that matter) also do the same thing. Now, there _is_ another possibility here: we might have had a pipe leak before, and the new pipe code would potentially make it a lot more noticeable, with up to sixteen times as many pages lost if somebody freed a pipe inode without calling free_pipe_info(). I don't see where that would happen - all the normal release functions seem fine. Hmm.. Adding a WARN_ON(inode-i_pipe); to iput_final() might be a good idea - showing if somebody is releasing an inode while it still associated with a pipe-info data structure. Also, while I don't see how a write could leak, but maybe you could you add a WARN_ON(buf-ops); to the pipe_writev() case just before we insert a new buffer (ie to just after the comment that says Insert it into the buffer array). Just to see if the circular buffer handling might overwrite an old entry (although I _really_ don't see that - it's not like the code is complex, and it would also be accompanied by data-loss in the pipe, so we'd have seen that, methinks). Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Joe User DOS kills Linux-2.6.10
Additional information:
My swap-file is also on /dev/sdb2. It appears as though swap
is being written beyond the end of the SCSI device and the
device doesn't like it. Also on a subsequent re-boot the
signature in the swap file had been destroyed so that swapon
didn't like it. I needed to use `mkswap` again.
On Wed, 2 Feb 2005, linux-os wrote:
When I compile and run the following program:
#include stdio.h
int main(int x, char **y)
{
pause();
}
... as:
./xxx `yes`
... the following occurs after about 30 seconds (your mileage
may vary):
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 34605780
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x2100101, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 34603748
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x2100103, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 34606804
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x213d5cd, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 33943668
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x213d5ce, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 33943676
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x213d5cf, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 33943684
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x213d5d0, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 33943692
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x2149672, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 9437375
Buffer I/O error on device sdb1, logical block 1179664
lost page write due to I/O error on sdb1
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x2149673, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 34903668
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x214967c, Current sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 34903676
This device, /dev/sdb1 is one of the mounted file-systems.
It is not being accessed. The root filesystem is on
an IDE drive (/proc/mounts):
rootfs / rootfs rw 0 0
/dev/root.old /initrd ext2 rw 0 0
/dev/root / ext3 rw 0 0
/proc /proc proc rw,nodiratime 0 0
/sys /sys sysfs rw 0 0
none /dev/pts devpts rw 0 0
none /dev/shm tmpfs rw 0 0
/dev/sdb1 /home/project ext2 rw 0 0
/dev/sda1 /dos/drive_C msdos rw,nodiratime,fmask=0022,dmask=0022 0 0
/dev/sda5 /dos/drive_D msdos rw,nodiratime,fmask=0022,dmask=0022 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
This continues until the system is too sick to even be re-booted
from the console. It requires the reset switch.
It looks like the command-line argument is probably overflowing
something in the kernel, resulting in non-related problems.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: A scrub daemon (prezeroing)
On Thu, Jan 27, 2005 at 12:15:24PM +, David Woodhouse wrote: On Fri, 2005-01-21 at 12:29 -0800, Christoph Lameter wrote: Adds management of ZEROED and NOT_ZEROED pages and a background daemon called scrubd. scrubd is disabled by default but can be enabled by writing an order number to /proc/sys/vm/scrub_start. If a page is coalesced of that order or higher then the scrub daemon will start zeroing until all pages of order /proc/sys/vm/scrub_stop and higher are zeroed and then go back to sleep. Some architectures tend to have spare DMA engines lying around. There's no need to use the CPU for zeroing pages. How feasible would it be for scrubd to use these? Hi David, I suppose you are talking about DMA engines which are not being driven by any driver ? Sounds very interesting idea to me. Guess it depends on whether the cost of DMA write for memory zeroing, which is memory architecture/DMA engine dependant, offsets the cost of CPU zeroing. Do you have any thoughts on that? I wonder if such thing (using unrelated devices DMA engine's for zeroing) ever been done on other OS'es? AFAIK SGI's BTE is special purpose hardware for memory zeroing. BTW, Andrew noted on lkml sometime ago that disabling caches before doing zeroing could enhance overall system performance by decreasing cache thrashing. What are the conclusions about 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] Prevent NMI oopser
Marcelo Tosatti wrote:
On Tue, Jan 25, 2005 at 11:00:22AM +0300, Vasily Averin wrote:
You should unlock io_request_lock before msleep, like in latest versions
of megaraid2 drivers.
Andrey,
Can you please update your patch to unlock io_request_lock before sleeping
and locking after coming back?
What the driver is doing is indeed wrong.
Marcelo,
This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible
version that I've seen), taken from latest RHEL3 kernel update. I
believe it should prevent NMI in abort/reset handler.
Thank you,
Vasily Averin, SWSoft Linux Kernel Team
--- ./drivers/scsi/megaraid2.c.mr2 Wed Feb 2 08:27:13 2005
+++ ./drivers/scsi/megaraid2.c Wed Feb 2 10:28:52 2005
@@ -14,7 +14,7 @@
* - speed-ups (list handling fixes, issued_list, optimizations.)
* - lots of cleanups.
*
- * Version : v2.10.3 (Apr 08, 2004)
+ * Version : v2.10.8.2 (July 26, 2004)
*
* Authors:Atul Mukker [EMAIL PROTECTED]
* Sreenivas Bagalkote [EMAIL PROTECTED]
@@ -46,7 +46,7 @@
#include megaraid2.h
-#ifdef LSI_CONFIG_COMPAT
+#if defined(__x86_64__)
#include asm/ioctl32.h
#endif
@@ -90,10 +90,15 @@ static struct notifier_block mega_notifi
static struct mega_hbas mega_hbas[MAX_CONTROLLERS];
/*
+ * Lock to protect access to IOCTL
+ */
+static struct semaphore megaraid_ioc_mtx;
+
+/*
* The File Operations structure for the serial/ioctl interface of the driver
*/
static struct file_operations megadev_fops = {
- .ioctl = megadev_ioctl,
+ .ioctl = megadev_ioctl_entry,
.open = megadev_open,
.release= megadev_close,
.owner = THIS_MODULE,
@@ -107,7 +112,7 @@ static struct file_operations megadev_fo
static struct mcontroller mcontroller[MAX_CONTROLLERS];
/* The current driver version */
-static u32 driver_ver = 0x0210;
+static u32 driver_ver = 0x02104000;
/* major number used by the device for character interface */
static int major;
@@ -189,6 +194,11 @@ megaraid_detect(Scsi_Host_Template *host
*/
mega_reorder_hosts();
+ /*
+* Initialize the IOCTL lock
+*/
+ init_MUTEX( megaraid_ioc_mtx );
+
#ifdef CONFIG_PROC_FS
mega_proc_dir_entry = proc_mkdir(megaraid, proc_root);
@@ -223,7 +233,7 @@ megaraid_detect(Scsi_Host_Template *host
MegaRAID Shutdown routine not registered!!\n);
}
-#ifdef LSI_CONFIG_COMPAT
+#if defined(__x86_64__)
/*
* Register the 32-bit ioctl conversion
*/
@@ -273,6 +283,8 @@ mega_find_card(Scsi_Host_Template *host_
unsigned long tbase;
unsigned long flag = 0;
int i, j;
+ u8 did_int_pthru_f = 0;
+ u8 did_int_data_f = 0;
while((pdev = pci_find_device(pci_vendor, pci_device, pdev))) {
@@ -328,6 +340,7 @@ mega_find_card(Scsi_Host_Template *host_
(subsysvid != HP_SUBSYS_VID)
(subsysvid != INTEL_SUBSYS_VID)
(subsysvid != FSC_SUBSYS_VID)
+ (subsysvid != ACER_SUBSYS_VID)
(subsysvid != LSI_SUBSYS_VID) ) continue;
@@ -465,6 +478,33 @@ mega_find_card(Scsi_Host_Template *host_
alloc_scb_f = 1;
+ /*
+* Allocate memory for ioctls
+*/
+ adapter-int_pthru = pci_alloc_consistent (
+ adapter-dev,
+ sizeof(mega_passthru),
+ adapter-int_pthru_dma_hndl );
+
+ if( adapter-int_pthru == NULL ) {
+ printk(KERN_WARNING megaraid: out of RAM.\n);
+ goto fail_attach;
+ }
+ else
+ did_int_pthru_f = 1;
+
+ adapter-int_data = pci_alloc_consistent (
+ adapter-dev,
+ INT_MEMBLK_SZ,
+ adapter-int_data_dma_hndl );
+
+ if( adapter-int_data == NULL ) {
+ printk(KERN_WARNING megaraid: out of RAM.\n);
+ goto fail_attach;
+ }
+ else
+ did_int_data_f = 1;
+
/* Request our IRQ */
if( adapter-flag BOARD_MEMMAP ) {
if(request_irq(irq, megaraid_isr_memmapped, SA_SHIRQ,
@@ -676,6 +716,19 @@ mega_find_card(Scsi_Host_Template *host_
continue;
fail_attach:
+ if( did_int_data_f ) {
+ pci_free_consistent(
+ adapter-dev, INT_MEMBLK_SZ, adapter-int_data,
+
Real-Time Preemption and GFP_ATOMIC
While testing an older driver on an -RT kernel (currently using -V0.7.37-03), I noticed something strange. The driver was triggering a sleeping function called from invalid context BUG(). It was coming from a case where the driver was doing a __get_free_page(GFP_ATOMIC) while interrupts were disabled (example trace below). I know this is probably real bug and it shouldn't be allocating memory with interrupts disabled, but shouldn't this be possible? Isn't the role of GFP_ATOMIC to say that this caller cannot sleep. To produce the following trace, I wrote a simple moudle which just has this as its init_module routine: local_irq_disable(); p = __get_free_page(GFP_ATOMIC); local_irq_enable(); And here's the trace: BUG: sleeping function called from invalid context insmod(2126) at kernel/rt.c:1448 in_atomic():0 [], irqs_disabled():1 [c0102fa3] dump_stack+0x23/0x30 (20) [c01133c5] __might_sleep+0xe5/0x100 (36) [c012fbb8] __spin_lock+0x38/0x60 (24) [c012fc8d] _spin_lock_irqsave+0x1d/0x30 (16) [c0140e5c] buffered_rmqueue+0x1c/0x190 (40) [c01413ce] __alloc_pages+0x34e/0x390 (76) [c0141437] __get_free_pages+0x27/0x50 (12) [c883205a] kmod_init+0x5a/0x74 [kmod] (24) [c0138232] sys_init_module+0x232/0x260 (28) [c010299c] syscall_call+0x7/0xb (-8124) --- | preempt count: 0001 ] | 1-level deep critical section nesting: .. [c0133e3d] print_traces+0x1d/0x60 .[c0102fa3] .. ( = dump_stack+0x23/0x30) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Joe User DOS kills Linux-2.6.10
On Wed, 2 Feb 2005, linux-os wrote: When I compile and run the following program: ./xxx `yes` It looks like the program itself doesn't matter, since it's bash that's eating up memory like crazy, until the point where it is OOM killed. PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 32191 riel 18 0 436m 126m 312 R 45.9 86.9 0:13.37 bash 3 riel 15 0 3276 148 124 S 39.0 0.1 0:09.79 yes Additional sense: Peripheral device write fault end_request: I/O error, dev sdb, sector 34605780 SCSI error : 0 0 1 0 return code = 0x802 Info fld=0x2100101, Deferred sdb: sense key Medium Error Looks like your SCSI disk has some problems, you may want to try running 'badblocks' on the swap partition to verify that. The VM doesn't appear to have a problem with your test program, in my quick runs here. ObLKML: I was running the test inside Xen, and that seemed to hold up fine too ;) -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Joe User DOS kills Linux-2.6.10
linux-os [EMAIL PROTECTED] writes:
When I compile and run the following program:
#include stdio.h
int main(int x, char **y)
{
pause();
}
... as:
./xxx `yes`
This is roughly equivalent to this:
#include stdlib.h
int main(void) { while (1) malloc(1); }
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
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: Linux hangs during IDE initialization at boot for 30 sec
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Brade Sent: Tuesday, February 01, 2005 3:58 AM To: linux-kernel@vger.kernel.org Subject: Linux hangs during IDE initialization at boot for 30 sec [snip] I found additional lines in the log just before the line above: Probing IDE interface ide2... Probing IDE interface ide3... Probing IDE interface ide4... Probing IDE interface ide5... But I only have ide0 and ide1. This problem persists even with 2.6.11-rc2. For the last test I removed every option from the kernel that is not needed, but the problem stays. So I'm sure it's not because of ACPI or PNP or the like. With 2.6.11-rc2 I get in my syslog: Feb 1 11:30:02 newton kernel: ICH3M: chipset revision 2 Feb 1 11:30:02 newton kernel: ICH3M: not 100%% native mode: will probe irqs later Feb 1 11:30:02 newton kernel: ide0: BM-DMA at 0xcfa0-0xcfa7, BIOS settings: hda:DMA, hdb:pio Feb 1 11:30:02 newton kernel: ide1: BM-DMA at 0xcfa8-0xcfaf, BIOS settings: hdc:DMA, hdd:pio Feb 1 11:30:02 newton kernel: Probing IDE interface ide0... Feb 1 11:30:02 newton kernel: hda: HITACHI_DK23DA-30, ATA DISK drive Feb 1 11:30:02 newton kernel: DEV: registering device: ID = 'ide0' Feb 1 11:30:02 newton kernel: PM: Adding info for No Bus:ide0 Feb 1 11:30:02 newton kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Feb 1 11:30:02 newton kernel: DEV: registering device: ID = '0.0' Feb 1 11:30:02 newton kernel: PM: Adding info for ide:0.0 Feb 1 11:30:02 newton kernel: bus ide: add device 0.0 Feb 1 11:30:02 newton kernel: Probing IDE interface ide1... Feb 1 11:30:02 newton kernel: hdc: TOSHIBA DVD-ROM SD-R2212, ATAPI CD/DVD-ROM drive Feb 1 11:30:02 newton kernel: DEV: registering device: ID = 'ide1' Feb 1 11:30:02 newton kernel: PM: Adding info for No Bus:ide1 Feb 1 11:30:02 newton kernel: ide1 at 0x170-0x177,0x376 on irq 15 Feb 1 11:30:02 newton kernel: DEV: registering device: ID = '1.0' Feb 1 11:30:02 newton kernel: PM: Adding info for ide:1.0 Feb 1 11:30:02 newton kernel: bus ide: add device 1.0 Feb 1 11:30:02 newton kernel: bus pci: add driver PIIX_IDE Feb 1 11:30:02 newton kernel: bound device ':00:1f.1' to driver 'PIIX_IDE' Feb 1 11:30:02 newton kernel: bus pci: add driver PCI_IDE Feb 1 11:30:02 newton kernel: Probing IDE interface ide2... Feb 1 11:30:02 newton kernel: Probing IDE interface ide3... Feb 1 11:30:02 newton kernel: Probing IDE interface ide4... Feb 1 11:30:02 newton kernel: ide4: Wait for ready failed before probe ! --- I guess the line above is the reason for the wait --- Feb 1 11:30:02 newton kernel: Probing IDE interface ide5... Feb 1 11:30:02 newton kernel: hda: max request size: 128KiB Since you don't care about anything except ide0 ide1, try to add the following to the kernel's command line: ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe Aleks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Prevent NMI oopser
On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote: Marcelo Tosatti wrote: On Tue, Jan 25, 2005 at 11:00:22AM +0300, Vasily Averin wrote: You should unlock io_request_lock before msleep, like in latest versions of megaraid2 drivers. Andrey, Can you please update your patch to unlock io_request_lock before sleeping and locking after coming back? What the driver is doing is indeed wrong. Marcelo, This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible version that I've seen), taken from latest RHEL3 kernel update. I believe it should prevent NMI in abort/reset handler. Thank you, Vasily Averin, SWSoft Linux Kernel Team Thanks Vasily, I was just looking at this again yesterday. You'll also find that because the driver doesn't define its inline functions prior to their use, newest compilers refuse to compile this version of the driver. Earlier compilers just ignore it and don't inline anything. As a hack, one could #define inline /*nothing*/ in megaraid2.h to avoid this, but it would be nice if the functions could all get reordered such that inlining works properly, and the need for function declarations in megaraid2.h would disappear completely. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
On Tue, 2005-02-01 at 23:10 -0600, Jack O'Quin wrote: So in the Linux core code we have zero tolerance on crap. We are doing this for the long-term fun of it. So, we should never do anything boring, even though people actually need it? The fact that a large group of frustrated Linux audio developers could find no better outlet than to develop this solution is a rather strong indictment of the kernel requirements-gathering process. and if nobody ends up writing the 'proper' solution then there probably wasnt enough demand to begin with ... We'll rather live on with one less feature for another year than with a crappy feature that is twice as hard to get rid of! Is nobody responsible for figuring out what users need? I didn't realize kernel development had become so disconnected. Interesting point. The kernel development process has been written about at length, but you don't hear much about the requirements gathering process. It seems like aside from the internal forces of kernel developers wanting to improve the system, the big distros, do a lot of the requirements gathering. Makes sense, as the distros are in a very good position to know what users want, and can commit developer resources to get it done. For example there has been a big push from the distros to make Linux competitive with MS on the desktop, and it shows in the direction of Linux development. These days you can throw in a cd of a modern distro and the installer will get you to a working desktop easier than Windows (well, almost, your sound might not work ;-). Really, if the Linux audio community wants to get its requirements heard, then all the AGNULA and Planet CCRMA users should start to demand that Fedora and Debian be usable OOTB for low latency audio. If you want to run JACK in realtime mode on RH or Debian you have to be root for crying out loud. There's no reason Linux audio users should have to patch the kernel or install a bunch of specialized packages any more than people who want to use it as a web server. File bug reports, complain on your distro's user mailing lists, whatever. I do appreciate the progress that has been made, and that the Linux kernel developers really stepped up to address the latency issues. But, most of the push has come from outside the kernel development community, from individual Linux audio users and developers. If we had waited for the big distros to demand that low latency audio work OOTB, we would be exactly where we were in 2001 (or this time last year) still using 2.4 +ll+preempt and struggling to get that old kernel to work on our new hardware. IMHO the requirements gathering process usually works well. When someone with a redhat.com (for example) address posts a patch there's an implicit assumption that it addresses the needs of their gadzillions of users. Still, RH hires professional kernel developers, people who produce known good code will always have an easier time getting patches merged. If Linus co. don't know you from Adam and you show up with a patch that claims to solve a big problem, then I would expect them to be a bit skeptical. Especially if the problem is either low priority or not well understood by the major distros. Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory leak in 2.6.11-rc1?
On Wed, 2005-02-02 at 10:27 -0800, Linus Torvalds wrote: How many of these pages do you see? It's normal for a single pipe to be associated with up to 16 pages (although that would only happen if there is no reader or a slow reader, which is obviously not very common). Strangely enough, it seems to be one single, persistent page. Now, if your memory freeing code depends on the fact that all HIGHMEM pages are always freeable (page cache + VM mappings only), then yes, the new pipe code introduces highmem pages that weren't highmem before. But such long-lived and unfreeable pages have been there before too: kernel modules (or any other vmalloc() user, for that matter) also do the same thing. That might be it. For now, I just change the GFP masks for vmalloc() so that I don't have to deal with it, yet. But, I certainly can see that how this is a new user of highmem. I did go around killing processes like mad to see if any of them still had a hold of the pipe, but the shotgun approach didn't seem to help. Now, there _is_ another possibility here: we might have had a pipe leak before, and the new pipe code would potentially make it a lot more noticeable, with up to sixteen times as many pages lost if somebody freed a pipe inode without calling free_pipe_info(). I don't see where that would happen - all the normal release functions seem fine. Hmm.. Adding a WARN_ON(inode-i_pipe); to iput_final() might be a good idea - showing if somebody is releasing an inode while it still associated with a pipe-info data structure. Also, while I don't see how a write could leak, but maybe you could you add a WARN_ON(buf-ops); to the pipe_writev() case just before we insert a new buffer (ie to just after the comment that says Insert it into the buffer array). Just to see if the circular buffer handling might overwrite an old entry (although I _really_ don't see that - it's not like the code is complex, and it would also be accompanied by data-loss in the pipe, so we'd have seen that, methinks). I'll put the warnings in, and see if anything comes up. -- Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A scrub daemon (prezeroing)
On Wed, 2 Feb 2005, Marcelo Tosatti wrote: Sounds very interesting idea to me. Guess it depends on whether the cost of DMA write for memory zeroing, which is memory architecture/DMA engine dependant, offsets the cost of CPU zeroing. Do you have any thoughts on that? I wonder if such thing (using unrelated devices DMA engine's for zeroing) ever been done on other OS'es? AFAIK SGI's BTE is special purpose hardware for memory zeroing. Nope the BTE is a block transfer engine. Its an inter numa node DMA thing that is being abused to zero blocks. The same can be done with most DMA chips (I have done so on some other platforms not on i386) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
On Wed, Feb 02, 2005 at 09:58:51AM -0800, Pete Zaitcev wrote: On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote: On Wed, Feb 02, 2005 at 08:56:28AM -0800, Pete Zaitcev wrote: On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote: Well, you removed the scaling to the touchpad resolution, which will cause ALPS touchpad to be significantly slower than Synaptics touchpads. Similarly, the screen size used to be taken into account, but probably that was a mistake, since the value is usually left at default and doesn't correspond to the real screen size. Exactly. And it works much better now. With a Synaptics I suppose? You wouldn't like it with an ALPS. No, it's a Dualpoint, and so ALPS. But never mind that, I think I see your point. However, while I see a possibility of serious regressions with the other variety, but isn't it striking that result is so radical? With all the arithmetics still in place I can move my finger all across the pad without causing any motions. We are not talking about ballistics or any fine tuning, simply the calculations are wrong. Sorry for that. It's not my code (except to the pad resolution scaling). ;) Let me add more, too. As long as the touchpad code in mousedev.c converts absolute mode data into relative events, there's no reason to scale _to the size of the screen_. Well, there is a reason. You usually want to be able to get to the other edge of the screen with a few moves of the finger. So the preferred final sensitivity depends on the screen size. But, since we don't know the screen size, we can't do this properly and thus it's better not to do it at all. Don't you see? User needs a scaling to the sensitivity, not the screen size. I have never seen a touchpad which allowed you to cross the screen in one motion if you moved it slowly, this is why acceleration feature exists. It's completely bogus. I agree. We should give it the same perceived resolution as a standard 400 DPI mouse (which is what the firmware does in mouse emulation mode) regardless of the screen size. That's actually the only way how it can mix with normal mouse data properly. Scaling to the size of the screen would have made sense if we used touchpad to generate absolute events, as some sort of a miniature Wacom pad. In such a case, you wouldn't be able to reach corners of the screen without scaling. But a touchpad is operated in entirely different way. If Synaptics delivers much bigger deltas for small motions, It's different hardware. While the ALPS pad delivers X axis in the range of 0 to 1000, the Synaptics pad will give X axis values from approx 1500 to approx 5500. This is four times the resolution - the size of the pad is mostly the same. Synaptics or ALPS don't deliver deltas in native mode. They deliver absolute coordinates of the finger touching. That's why there is any math delivered at all. it's up to the Synapics mode of alps.c to make them reasonable, if that. The policy of input drivers is not to scale or otherwise modify the data. That's why the input_dev struct contains the ranges of the axes. Btw, what do you mean by synaptics mode of alps? There's no need to penalize ALPS. But I seriously doubt that Synaptics can be so broken. Neither are broken. But mousedev.c (and similarly the X touchpad driver) must take the pad resolution into account, otherwise the cursor will move four times faster with Synaptics than with ALPS. I wish Peter tested the removal of scaling with his Synaptics. If he (and Dmitry) insist on running a special code in X, that's fine. But honestly, I expect that things will go well for them. I added the scaling code, because my ALPS pad was *unbearably* slow. The original code in mousedev divided by 8 (instead of 2), because it was tuned for Synaptics. We need to divide by 2 for ALPS and by 8 for Synaptics, and that's basically all we need to do. But we must not do that by checking the pad manufacturer, because when a third pad type comes in (Say Logitech TouchPad 3), we shouldn't need to modify mousedev.c -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 to add usbmon
On Wed, 02 Feb 2005 17:40:17 +0100, Marcel Holtmann [EMAIL PROTECTED] wrote: While I am really thinking about starting usbdump, I may ask why you have choosen to use debugfs as interface. This will not be available in normal distribution kernels and I think a general USB monitoring ability would be great. For example like we have it for Ethernet, Bluetooth and IrDA. So my idea is to create some /dev/usbmonX (for each bus one) where usbdump can read its information from. What do you think? The debugfs will be available in distributions. And it's no different from having SOCK_PACKET enabled before tcpdump can work. There's no practical disadvantage, unless we consider a backport of usbmon into a legacy distribution such as RHEL 4 or SuSE 9.1. Since usbmon rides raw file_operations, it can use a chardev interface with a minimal change. The advantage of debugfs is only not needing to allocate a major and dealing with minor partitioning. I also thought it would help to shut up the namespace pollution whiners (the debate of /dbg versus /sys/kernel/debug was rather mild by comparison). It should make little difference for the tool anyway, the base path ought to be configurable. The biggest difference would be to scripts which launch the tool: in one case they need to mount debugfs if not mounted (if initscripts haven't), in other case they mknod if necessary (if hal hasn't done it). It is too early to care about this anyway. -- 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: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
On Tue, 2005-02-01 at 23:10 -0600, Jack O'Quin wrote: Is nobody responsible for figuring out what users need? I didn't realize kernel development had become so disconnected. Lee Revell [EMAIL PROTECTED] writes: IMHO the requirements gathering process usually works well. When someone with a redhat.com (for example) address posts a patch there's an implicit assumption that it addresses the needs of their gadzillions of users. Still, RH hires professional kernel developers, people who produce known good code will always have an easier time getting patches merged. If Linus co. don't know you from Adam and you show up with a patch that claims to solve a big problem, then I would expect them to be a bit skeptical. Especially if the problem is either low priority or not well understood by the major distros. I guess you're right, Lee. I hadn't thought of it that way. It just looks broken to me because we have no standing in any normal kernel requirements process. That's a shame, but it does seem less like a systemic issue. I think the distributions are getting more interested in these issues. Maybe that will help. The RT-LSM is available as a module in Debian sarge. Back when I did OS development for a living, there was a huge focus on defining user requirements. But, our kernel development was never organizationally separate from the rest of the OS. That makes a big difference. -- joq - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
Le mercredi 02 février 2005 à 15:21 +0100, Haakon Riiser a écrit : How can I use a frame buffer driver's optimized copyarea, fillrect, blit, etc. from userspace? The only way I've ever seen anyone use the frame buffer device is by mmap()ing it and doing everything manually in the mapped memory. I assume there must be ioctls for accessing the accelerated functions, but after several hours of grepping and googling, I give up. :-( Did you try DirectFB ? Thanks for the tip, I hadn't heard about it. I will take a look, but only to see if it can show me the user space API of /dev/fb. I don't need a general library that supports a bunch of different graphics cards. I'm writing my own frame buffer driver for the GX2 CPU, and I just want to know how to call the various functions registered in struct fb_ops, so that I can test my code. I mean, all those functions registered in fb_ops must be accessible somehow; if they weren't, what purpose would they serve? The reason for the accelerated functions is for the framebuffer console. Drawing pixel by pixel is to slow. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Copyright / licensing question
On Wed, 2 Feb 2005, Frank klein wrote: 1. For explaining the internals of a filesystem in detail, I need to take their code from kernel sources 'as it is' in the book. Do I need to take any permissions from the owner/maintainer regarding this ? Will it violate any license if reproduce the driver source code in my book ?? Reproducing GPL code is legal, though you may want to make sure that the copyright notice on the book doesn't accidentally try to prohibit your readers from further distributing said code ;) -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
You should look at writing a DRM driver. DRM implements the kernel interface to get 3D hardware running. It is a fully accelerated driver interface. They are located in drivers/char/drm Have the standard frame buffer drivers been abandoned, even for devices that have no 3D acceleration (like the Geode GX2)? No. It is still around. I took a quick look at the DRM stuff, and it looked like extreme overkill for what I need, if it even can be used for what I want to do. At first glance it looked like this is only relevant for OpenGL/X11 3D-stuff, which I have absolutely no use for. This is usually the case for embedded chips. This is the reason the fbdev userland interface is still around. GX2 is an integrated CPU/graphics chip for embedded systems. We have third party applications that use the framebuffer device, and I was hoping to make things faster by writing an accelerated driver. The only thing I need answered is how to access fb_ops from userspace. You can mmap the mmio address space and program the registers yourself. A bonus is the example code is in the driver :-) If that is impossible because all the framebuffer code is leftover junk that no one uses anymore, or even /can/ use anymore because the userspace interface is gone, please let me know now so I don't have to waste any more time. The userspace interface is still there. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Prevent NMI oopser
Hi Vasily Averin! On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote next: Marcelo Tosatti wrote: On Tue, Jan 25, 2005 at 11:00:22AM +0300, Vasily Averin wrote: You should unlock io_request_lock before msleep, like in latest versions of megaraid2 drivers. Andrey, Can you please update your patch to unlock io_request_lock before sleeping and locking after coming back? What the driver is doing is indeed wrong. Marcelo, This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible version that I've seen), Where ? Last version (i see announce + patch from 2.10.3) is 2.10.6. taken from latest RHEL3 kernel update. I believe it should prevent NMI in abort/reset handler. Thnx for patch, I try it on my server at next week. -- Best regards, TEMHOTA-RIPN aka MJA13-RIPE System Administrator. mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent NMI oopser
Hello Matt Matt Domsch wrote: On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote: Marcelo, This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible version that I've seen), taken from latest RHEL3 kernel update. I believe it should prevent NMI in abort/reset handler. Thanks Vasily, I was just looking at this again yesterday. You'll also find that because the driver doesn't define its inline functions prior to their use, newest compilers refuse to compile this version of the driver. Earlier compilers just ignore it and don't inline anything. As a hack, one could #define inline /*nothing*/ in megaraid2.h to avoid this, but it would be nice if the functions could all get reordered such that inlining works properly, and the need for function declarations in megaraid2.h would disappear completely. Could you fix it by additional patch? Or you going to prepare a new one? Thank you, Vasily Averin, SWSoft Linux Kernel Team - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
On Wed, 2 Feb 2005, Haakon Riiser wrote:
On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser
[EMAIL PROTECTED] wrote:
Thanks for the tip, I hadn't heard about it. I will take a look,
but only to see if it can show me the user space API of /dev/fb.
I don't need a general library that supports a bunch of different
graphics cards. I'm writing my own frame buffer driver for the
GX2 CPU, and I just want to know how to call the various functions
registered in struct fb_ops, so that I can test my code. I mean,
all those functions registered in fb_ops must be accessible
somehow; if they weren't, what purpose would they serve?
You should look at writing a DRM driver. DRM implements the kernel
interface to get 3D hardware running. It is a fully accelerated driver
interface. They are located in drivers/char/drm
Have the standard frame buffer drivers been abandoned, even
for devices that have no 3D acceleration (like the Geode GX2)?
No.
GX2 is an integrated CPU/graphics chip for embedded systems.
We have third party applications that use the framebuffer device,
and I was hoping to make things faster by writing an accelerated
driver. The only thing I need answered is how to access fb_ops
from userspace. If that is impossible because all the framebuffer
code is leftover junk that no one uses anymore, or even /can/
use anymore because the userspace interface is gone, please let
me know now so I don't have to waste any more time.
mmap() the MMIO registers to userspace, and program the acceleration engine
from userspace, like DirectFB (and XF*_FBDev 3.x for Matrox and Mach64) does.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
On Wed, 2 Feb 2005 09:58:51 -0800, Pete Zaitcev [EMAIL PROTECTED] wrote: On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote: On Wed, Feb 02, 2005 at 08:56:28AM -0800, Pete Zaitcev wrote: On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote: Well, you removed the scaling to the touchpad resolution, which will cause ALPS touchpad to be significantly slower than Synaptics touchpads. Similarly, the screen size used to be taken into account, but probably that was a mistake, since the value is usually left at default and doesn't correspond to the real screen size. Exactly. And it works much better now. With a Synaptics I suppose? You wouldn't like it with an ALPS. No, it's a Dualpoint, and so ALPS. But never mind that, I think I see your point. However, while I see a possibility of serious regressions with the other variety, but isn't it striking that result is so radical? With all the arithmetics still in place I can move my finger all across the pad without causing any motions. We are not talking about ballistics or any fine tuning, simply the calculations are wrong. It works fine for my Synaptics with default resolution, I don't have ALPS to try but I think Peter tried to make it behave similarly. Still, I agree that relying on the screen coordinates is a bad idea. If Synaptics delivers much bigger deltas for small motions, it's up to the Synapics mode of alps.c to make them reasonable, if that. There's no need to penalize ALPS. But I seriously doubt that Synaptics can be so broken. Why is that having 5x better resolution is considered broken? And how synaptics should make them reasonable? Driver emits pretty much raw coordinate values and it is up to the consumer to make sense of them. I wish Peter tested the removal of scaling with his Synaptics. If he (and Dmitry) insist on running a special code in X, that's fine. Yes, because there are other things we can do in that special code. Do you like default tochpad sensitivity? What if someone does not? Do you like verical and horisontal scrolling? Circular scrolling? multi-finger tappng (synaptics only)? Corner tapping? What about rebooting every time you change an option? But honestly, I expect that things will go well for them. Well, your code will make my touchpad (Synaptics) go ballistic. It really has resolution of about 4000 points across. -- 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/
[Patch] keep ide disk sleeping when resuming
Hello,
I need this patch (against linux-2.6.11-rc2), to keep ide disk sleeping,
when resuming from ACPI S1.
In fact, it's just removing a patch from 22 Jun 2004 by Jens Axboe. He has
told me, that We can probably kill the patch completely.
So, this is what I'm doing now.
Kind regards, Peter
--- drivers/ide/ide-disk.c.orig 2005-02-02 20:30:12.0 +0100
+++ drivers/ide/ide-disk.c 2005-02-02 20:32:21.0 +0100
@@ -864,9 +864,7 @@
enum {
idedisk_pm_flush_cache = ide_pm_state_start_suspend,
idedisk_pm_standby,
-
- idedisk_pm_idle = ide_pm_state_start_resume,
- idedisk_pm_restore_dma,
+ idedisk_pm_restore_dma = ide_pm_state_start_resume
};
static void idedisk_complete_power_step (ide_drive_t *drive, struct request
*rq, u8 stat, u8 error)
@@ -881,9 +879,6 @@
case idedisk_pm_standby:/* Suspend step 2 (standby) complete */
rq-pm-pm_step = ide_pm_state_completed;
break;
- case idedisk_pm_idle: /* Resume step 1 (idle) complete */
- rq-pm-pm_step = idedisk_pm_restore_dma;
- break;
}
}
@@ -914,12 +909,6 @@
args-handler = task_no_data_intr;
return do_rw_taskfile(drive, args);
- case idedisk_pm_idle: /* Resume step 1 (idle) */
- args-tfRegister[IDE_COMMAND_OFFSET] = WIN_IDLEIMMEDIATE;
- args-command_type = IDE_DRIVE_TASK_NO_DATA;
- args-handler = task_no_data_intr;
- return do_rw_taskfile(drive, args);
-
case idedisk_pm_restore_dma:/* Resume step 2 (restore DMA) */
/*
* Right now, all we do is call hwif-ide_dma_check(drive),
--
http://pmrb.free.fr/contact/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
On Wed, Feb 02, 2005 at 11:39:29AM -0800, Pete Zaitcev wrote: On Wed, 2 Feb 2005 20:11:35 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote: It's different hardware. While the ALPS pad delivers X axis in the range of 0 to 1000, the Synaptics pad will give X axis values from approx 1500 to approx 5500. This is four times the resolution - the size of the pad is mostly the same. We need to divide by 2 for ALPS and by 8 for Synaptics, and that's basically all we need to do. But we must not do that by checking the pad manufacturer, because when a third pad type comes in (Say Logitech TouchPad 3), we shouldn't need to modify mousedev.c What you say is valid. I see now that this is what had to be addressed by this statement: size = dev-absmax[ABS_Y] - dev-absmin[ABS_Y]; Removing that was my mistake and I wish I had a different pad for testing. I'll do some measurements here and return something of that nature into the patched code and give it a try. OK. But I still think that using yres here is wrong. It may be a fine idea, but adding another divisor here ruined the precision of small movements. This was my problem. Trying to line up two windows was hugely frustrating with 2.6.11-rc2 Peter's patches. But also, it was unnecessary to use yres, because the reach or maximum moving distance is to be accomplished with ballistics, not scaling. I agree. If one wants full precision even at the ballistic speeds of movement (and Synaptics can do that simply by not dividing the values), one can use the special X driver. No need to be overclever in mousedev. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Prevent NMI oopser
Hello Matt Matt Domsch wrote: On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote: This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible version that I've seen), taken from latest RHEL3 kernel update. I believe it should prevent NMI in abort/reset handler. Thanks Vasily, I was just looking at this again yesterday. You'll also find that because the driver doesn't define its inline functions prior to their use, newest compilers refuse to compile this version of the driver. Earlier compilers just ignore it and don't inline anything. As a hack, one could #define inline /*nothing*/ in megaraid2.h to avoid this, but it would be nice if the functions could all get reordered such that inlining works properly, and the need for function declarations in megaraid2.h would disappear completely. Could you fix it by additional patch? Or do you going to prepare a new one? Thank you, Vasily Averin, SWSoft Linux Kernel Team - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
On Wed, 2 Feb 2005 20:11:35 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote: It's different hardware. While the ALPS pad delivers X axis in the range of 0 to 1000, the Synaptics pad will give X axis values from approx 1500 to approx 5500. This is four times the resolution - the size of the pad is mostly the same. We need to divide by 2 for ALPS and by 8 for Synaptics, and that's basically all we need to do. But we must not do that by checking the pad manufacturer, because when a third pad type comes in (Say Logitech TouchPad 3), we shouldn't need to modify mousedev.c What you say is valid. I see now that this is what had to be addressed by this statement: size = dev-absmax[ABS_Y] - dev-absmin[ABS_Y]; Removing that was my mistake and I wish I had a different pad for testing. I'll do some measurements here and return something of that nature into the patched code and give it a try. But I still think that using yres here is wrong. It may be a fine idea, but adding another divisor here ruined the precision of small movements. This was my problem. Trying to line up two windows was hugely frustrating with 2.6.11-rc2 Peter's patches. But also, it was unnecessary to use yres, because the reach or maximum moving distance is to be accomplished with ballistics, not scaling. There's nothing new about the pad being too small, actually. Old Logitech Genius mouse in 1992 ran out of its green pad easily. The answer was to accelerate the movement. If you moved quicker, you crossed whole screen. The good news is that this adjustment is individual for the user and is easily configurable. -- 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: Linux hangs during IDE initialization at boot for 30 sec
-Original Message- From: Michael Brade [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 11:55 AM To: Aleksey Gorelov Subject: Re: Linux hangs during IDE initialization at boot for 30 sec Hi, Since you don't care about anything except ide0 ide1, try to add the following to the kernel's command line: ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe Awesome! Thanks, booting is finally acceptably fast again :-) Just strange that it worked for the last 3 years (in fact, 7 years) with just about every kernel version that's out there... but I'm happy with the workaround. Was it exact same hardware ? Cheers, -- Michael Brade; KDE Developer, Student of Computer Science |-mail: echo brade !#|tr -d c oh|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2' °--web: http://www.kde.org/people/michaelb.html KDE 3: The Next Generation in Desktop Experience - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
[Geert Uytterhoeven] mmap() the MMIO registers to userspace, and program the acceleration engine from userspace, like DirectFB (and XF*_FBDev 3.x for Matrox and Mach64) does. Right, this was how I originally intended to do it. The reason why I started to obsess about the accelerated fb_ops functions was that I hoped that, by creating a driver that registered accelerated versions of these functions, other frame buffer-using applications would instantly take advantage of it, requiring no changes in those applications. I thought the frame buffer device was supposed to serve as an an abstraction layer between the graphics card and the application, allowing for 2D acceleration without having to know anything about the underlying hardware. But if no one uses the frame buffer device in this way, I might as well do as you suggest and mmap() the registers to userspace. Anyway, thanks to everyone who participated in this thread. Even if I didn't get the answers I was hoping for, at least now I can put the matter to rest. -- Haakon - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] update email address of Pedro Roque Marques
I tried to send a Cc of a patch in a file in the Linux kernel that is credited to Pedro Roque Marques, but the email bounced. The patch below (already ACK'ed by Pedro Roque Marques) updates his email address. This patch was already included in Marcelo's 2.4 tree. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- This patch was already sent on: - 15 Jul 2004 - 6 Aug 2004 - 1 Sep 2004 Documentation/isdn/CREDITS |2 +- Documentation/isdn/README.pcbit |2 +- drivers/isdn/pcbit/callbacks.c |2 +- drivers/isdn/pcbit/callbacks.h |2 +- drivers/isdn/pcbit/capi.c |2 +- drivers/isdn/pcbit/capi.h |2 +- drivers/isdn/pcbit/drv.c|2 +- drivers/isdn/pcbit/edss1.c |2 +- drivers/isdn/pcbit/edss1.h |2 +- drivers/isdn/pcbit/layer2.c |2 +- drivers/isdn/pcbit/layer2.h |2 +- drivers/isdn/pcbit/module.c |2 +- drivers/isdn/pcbit/pcbit.h |2 +- include/linux/in6.h |2 +- include/linux/ipv6_route.h |2 +- include/net/if_inet6.h |2 +- include/net/ip6_fib.h |2 +- include/net/ipv6.h |2 +- include/net/neighbour.h |2 +- net/core/neighbour.c|2 +- net/ipv6/addrconf.c |2 +- net/ipv6/af_inet6.c |2 +- net/ipv6/datagram.c |2 +- net/ipv6/exthdrs.c |2 +- net/ipv6/icmp.c |2 +- net/ipv6/ip6_fib.c |2 +- net/ipv6/ip6_input.c|2 +- net/ipv6/ip6_output.c |2 +- net/ipv6/ipv6_sockglue.c|2 +- net/ipv6/mcast.c|2 +- net/ipv6/ndisc.c|2 +- net/ipv6/protocol.c |2 +- net/ipv6/raw.c |2 +- net/ipv6/reassembly.c |2 +- net/ipv6/route.c|2 +- net/ipv6/sit.c |2 +- net/ipv6/tcp_ipv6.c |2 +- net/ipv6/udp.c |2 +- 38 files changed, 38 insertions(+), 38 deletions(-) --- linux-2.6.8-rc1-full/Documentation/isdn/CREDITS.old 2004-06-16 07:18:58.0 +0200 +++ linux-2.6.8-rc1-full/Documentation/isdn/CREDITS 2004-07-15 22:33:03.0 +0200 @@ -37,7 +37,7 @@ Andreas Kool ([EMAIL PROTECTED]) For contribution of the isdnlog/isdnrep-tool -Pedro Roque Marques ([EMAIL PROTECTED]) +Pedro Roque Marques ([EMAIL PROTECTED]) For lot of new ideas and the pcbit driver. Eberhard Moenkeberg ([EMAIL PROTECTED]) --- linux-2.6.8-rc1-full/Documentation/isdn/README.pcbit.old2004-06-16 07:19:52.0 +0200 +++ linux-2.6.8-rc1-full/Documentation/isdn/README.pcbit2004-07-15 22:33:03.0 +0200 @@ -37,4 +37,4 @@ regards, Pedro. -[EMAIL PROTECTED] +[EMAIL PROTECTED] --- linux-2.6.8-rc1-full/drivers/isdn/pcbit/edss1.c.old 2004-06-16 07:18:57.0 +0200 +++ linux-2.6.8-rc1-full/drivers/isdn/pcbit/edss1.c 2004-07-15 22:33:03.0 +0200 @@ -4,7 +4,7 @@ * * Copyright (C) 1996 Universidade de Lisboa * - * Written by Pedro Roque Marques ([EMAIL PROTECTED]) + * Written by Pedro Roque Marques ([EMAIL PROTECTED]) * * This software may be used and distributed according to the terms of * the GNU General Public License, incorporated herein by reference. --- linux-2.6.8-rc1-full/drivers/isdn/pcbit/pcbit.h.old 2004-06-16 07:18:58.0 +0200 +++ linux-2.6.8-rc1-full/drivers/isdn/pcbit/pcbit.h 2004-07-15 22:33:03.0 +0200 @@ -3,7 +3,7 @@ * * Copyright (C) 1996 Universidade de Lisboa * - * Written by Pedro Roque Marques ([EMAIL PROTECTED]) + * Written by Pedro Roque Marques ([EMAIL PROTECTED]) * * This software may be used and distributed according to the terms of * the GNU General Public License, incorporated herein by reference. --- linux-2.6.8-rc1-full/drivers/isdn/pcbit/layer2.h.old2004-06-16 07:18:58.0 +0200 +++ linux-2.6.8-rc1-full/drivers/isdn/pcbit/layer2.h2004-07-15 22:33:03.0 +0200 @@ -3,7 +3,7 @@ * * Copyright (C) 1996 Universidade de Lisboa * - * Written by Pedro Roque Marques ([EMAIL PROTECTED]) + * Written by Pedro Roque Marques ([EMAIL PROTECTED]) * * This software may be used and distributed according to the terms of * the GNU General Public License, incorporated herein by reference. --- linux-2.6.8-rc1-full/drivers/isdn/pcbit/module.c.old2004-06-16 07:19:37.0 +0200 +++ linux-2.6.8-rc1-full/drivers/isdn/pcbit/module.c2004-07-15 22:33:03.0 +0200 @@ -3,7 +3,7 @@ * * Copyright (C) 1996 Universidade de Lisboa * - * Written by Pedro Roque Marques ([EMAIL PROTECTED]) + * Written by Pedro Roque Marques ([EMAIL PROTECTED]) * * This software may be used and distributed according to the terms of * the GNU General Public License, incorporated herein by reference. --- linux-2.6.8-rc1-full/drivers/isdn/pcbit/drv.c.old 2004-06-16 07:19:43.0 +0200
Re: [PATCH] Prevent NMI oopser
Matt Domsch wrote: On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote: This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible version that I've seen), taken from latest RHEL3 kernel update. I believe it should prevent NMI in abort/reset handler. Thanks Vasily, I was just looking at this again yesterday. You'll also find that because the driver doesn't define its inline functions prior to their use, newest compilers refuse to compile this version of the driver. Earlier compilers just ignore it and don't inline anything. As a hack, one could #define inline /*nothing*/ in megaraid2.h to avoid this, but it would be nice if the functions could all get reordered such that inlining works properly, and the need for function declarations in megaraid2.h would disappear completely. Could you fix it by additional fix? Or you going to release new driver version for 2.4 kernels? Thank you, Vasily Averin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
-jedi kernel patches
Hello, This is the unique announcement that will be sent to LKML. I'm maintaining a small patch against the -mm tree that might be useful to other people. Almost every time Andrew releases a new -mm version, it brings nice bug fixes, and it also often introduces new exciting features. Unfortunately, there are often nasty buglets. Like typos that prevent the kernel from compiling, like nasty bugs that get fixed 5 minutes later with a 2-lines patch, etc. These buglets are fixed in the next -mm release, but since the next release introduces new experimental stuff, it also introduces new buglets, etc. The -jedi patches contains the last-minute fixes against the -mm tree. There's no new feature here, nor new code to test. It only contains important bug fixes that are discussed on LKML just after a new -mm release. If you read LKML and if you're testing -mm kernels, you probably already applied the same patches. The -jedi patch is just here to make things easier to apply. In addition, it also includes the latest device-mapper updates and the requirements for EVMS. The patches can be downloaded from: ftp://ftp.c9x.org/pub/linux-kernel/ Mirrors are welcome. -Frank. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
* Jack O'Quin [EMAIL PROTECTED] wrote: The LSM was a stop-gap measure intended to tide us over until a real fix could be done right for 2.8. It had the advantage of being minimally disruptive to the kernel and its maintainability. [...] i'm not opposed to the LSM solution per se, especially given that none of the other solutions in existence are fully satisfactory (and thus acceptable for the scheduler currently). The LSM patch is clearly the least intrusive solution. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[bk-patches] [resend] Needed input fixes for 2.6.11
Hi! I pretty much screwed up in the last update you merged for 2.6.11, making USB input devices rather annoying to use. These four patches fix the damage made: 1) The MUX mode disabling had a bug that caused it to not work at all. 2) MSC_SCAN events backpropagating into hid-input.c caused a flood of 'event field not found' messages in the syslog. 3) USB keyboad LEDs stopped working due to a fix for Logitech mouse fake LEDs. 4) The fourth patch is a documentation update from Andries Brouwer. Please include these before the final 2.6.11, or drop the last input update. As usual, they're available at: bk://kernel.bkbits.net/vojtech/for-linus as well as in the following mails of this thread. Thanks, -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] Fix MUX mode disabling.
You can pull this changeset from: bk://kernel.bkbits.net/vojtech/for-linus === [EMAIL PROTECTED], 2005-01-28 21:11:52+01:00, [EMAIL PROTECTED] input: Fix MUX mode disabling. Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED] i8042.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) === diff -Nru a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c --- a/drivers/input/serio/i8042.c 2005-02-02 20:29:55 +01:00 +++ b/drivers/input/serio/i8042.c 2005-02-02 20:29:55 +01:00 @@ -482,7 +482,7 @@ if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != 0x0f) return -1; param = mode ? 0x56 : 0xf6; - if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != 0xa9) + if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != (mode ? 0xa9 : 0x09)) return -1; param = mode ? 0xa4 : 0xa5; if (i8042_command(param, I8042_CMD_AUX_LOOP) || param == (mode ? 0x5b : 0x5a)) @@ -787,7 +787,8 @@ * Disable MUX mode if present. */ - i8042_set_mux_mode(0, NULL); + if (i8042_mux_present) + i8042_set_mux_mode(0, NULL); /* * Restore the original control register setting. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
* Jack O'Quin [EMAIL PROTECTED] wrote: I guess you're right, Lee. I hadn't thought of it that way. It just looks broken to me because we have no standing in any normal kernel requirements process. That's a shame, but it does seem less like a systemic issue. you have just as much standing, and you certainly went to great lengths (writing patches, testing stuff, etc.) to address this issue - it is just an unfortunate situation that the issue here is _not_ clear-cut at all. It is a longstanding habit on lkml to try to solve things as cleanly and generally as possible, but there are occasional cases where this is just not possible. e.g. technically it was much harder to write all the latency-fix patches (and infrastructure around it) that are now in 2.6.11-rc2, but it was also a much clearer issue, with clean solutions; so there was no conflict about whether to do it and you'll reap the benefits of that in 2.6.11. so forgive us this stubborness, it's not directed against you in person or against any group of users, it's always directed at the problem at hand. I think we can do the LSM thing, and if this problem comes up in the future again, then maybe by that time there will be a better solution. (e.g. it's quite possible that something nice will come out of the various virtualization projects, for this problem area.) Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent NMI oopser
On Wed, Feb 02, 2005 at 10:32:28PM +0300, Vasily Averin wrote: As a hack, one could #define inline /*nothing*/ in megaraid2.h to avoid this, but it would be nice if the functions could all get reordered such that inlining works properly, and the need for function declarations in megaraid2.h would disappear completely. Could you fix it by additional patch? Or you going to prepare a new one? Here's the hack patch (will apply after yours). Signed-off-by: Matt Domsch [EMAIL PROTECTED] -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com = drivers/scsi/megaraid2.h 1.6 vs edited = --- 1.6/drivers/scsi/megaraid2.h2005-02-02 13:48:22 -06:00 +++ edited/drivers/scsi/megaraid2.h 2005-02-02 13:55:42 -06:00 @@ -5,6 +5,18 @@ #include linux/spinlock.h +/* This is an ugly hack, but gets around the fact that earlier + * versions of gcc ignores the inline specification when + * the function definition comes after function use (thereby + * not inlining the code), and newer gcc fails to compile the + * code. This should be removed once the functions are properly + * ordered in megaraid2.c, and the function declarations removed + * in megaraid2.h. + */ +#undef inline +#define inline /*nothing*/ + + #define MEGARAID_VERSION \ v2.10.8.2 (Release Date: Mon Jul 26 12:15:51 EDT 2004)\n - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
Marcelo Tosatti [EMAIL PROTECTED] wrote: What are your thoughts about inclusion of Mel's allocator work on -mm ? It's sitting in my to-do pile. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] Document the atkbd.softraw module parameter.
You can pull this changeset from: bk://kernel.bkbits.net/vojtech/for-linus === [EMAIL PROTECTED], 2005-01-29 12:27:56+01:00, [EMAIL PROTECTED] input: Document the atkbd.softraw module parameter. From: Andries Brouwer [EMAIL PROTECTED] Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED] kernel-parameters.txt | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) === diff -Nru a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt --- a/Documentation/kernel-parameters.txt 2005-02-02 20:29:48 +01:00 +++ b/Documentation/kernel-parameters.txt 2005-02-02 20:29:48 +01:00 @@ -226,15 +226,19 @@ atascsi=[HW,SCSI] Atari SCSI - atkbd.extra=[HW] Enable extra LEDs and keys on IBM RapidAccess, EzKey - and similar keyboards + atkbd.extra=[HW] Enable extra LEDs and keys on IBM RapidAccess, + EzKey and similar keyboards atkbd.reset=[HW] Reset keyboard during initialization atkbd.set= [HW] Select keyboard code set Format: int (2 = AT (default) 3 = PS/2) - atkbd.scroll= [HW] Enable scroll wheel on MS Office and similar keyboards + atkbd.scroll= [HW] Enable scroll wheel on MS Office and similar + keyboards + + atkbd.softraw= [HW] Choose between synthetic and real raw mode + Format: bool (0 = real, 1 = synthetic (default)) atkbd.softrepeat= [HW] Use software keyboard repeat - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] Fix HID LED mapping.
You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus
===
[EMAIL PROTECTED], 2005-02-02 17:54:35+01:00, [EMAIL PROTECTED]
input: Fix HID LED mapping. LEDs were ignored because the usage
value contains the page code in high 16 bits.
Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED]
hid-debug.h |2 +-
hid-input.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
===
diff -Nru a/drivers/usb/input/hid-debug.h b/drivers/usb/input/hid-debug.h
--- a/drivers/usb/input/hid-debug.h 2005-02-02 20:29:32 +01:00
+++ b/drivers/usb/input/hid-debug.h 2005-02-02 20:29:32 +01:00
@@ -86,12 +86,12 @@
{0, 0x92, D-PadRight},
{0, 0x93, D-PadLeft},
{ 7, 0, Keyboard },
+ { 8, 0, LED },
{0, 0x01, NumLock},
{0, 0x02, CapsLock},
{0, 0x03, ScrollLock},
{0, 0x04, Compose},
{0, 0x05, Kana},
- { 8, 0, LED },
{ 9, 0, Button },
{ 10, 0, Ordinal },
{ 12, 0, Consumer },
diff -Nru a/drivers/usb/input/hid-input.c b/drivers/usb/input/hid-input.c
--- a/drivers/usb/input/hid-input.c 2005-02-02 20:29:32 +01:00
+++ b/drivers/usb/input/hid-input.c 2005-02-02 20:29:32 +01:00
@@ -185,9 +185,9 @@
break;
case HID_UP_LED:
- if (usage-hid - 1 = LED_MAX)
+ if (((usage-hid - 1) 0x) = LED_MAX)
goto ignore;
- map_led(usage-hid - 1);
+ map_led((usage-hid - 1) 0x);
break;
case HID_UP_DIGITIZER:
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] Altix : ioc4 serial driver support
Christoph Hellwig wrote: On Mon, Jan 31, 2005 at 04:45:05PM -0600, Pat Gefre wrote: Please kill ioc4_ide_init as it's completely unused and make ioc4_serial_init a normal module_init() handler in ioc4_serial, there's no need to call them from the generic driver. I want ioc4_serial_init called before pci_register_driver() if I make it a module_init() call I have no control over order ?? Do you need to use ide_pci_register_driver? IOC4 doesn't have the legacy IDE problems, and it's never used together with such devices in a system, so a plain pci_register_driver should do it. So ide_pci_register_driver is only for legacy devices with certain IDE problems - I think that is what you are saying (just trying to make sure I have it right) ?? Thanks for the review, -- Pat - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] Ignore non-LED events in hid-input hidinput_event().
You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus
===
[EMAIL PROTECTED], 2005-01-29 13:09:24+01:00, [EMAIL PROTECTED]
input: Ignore non-LED events in hid-input hidinput_event(). This gets rid
of the event field not found message caused by EV_MSC type events.
Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED]
hid-input.c |3 +++
1 files changed, 3 insertions(+)
===
diff -Nru a/drivers/usb/input/hid-input.c b/drivers/usb/input/hid-input.c
--- a/drivers/usb/input/hid-input.c 2005-02-02 20:29:40 +01:00
+++ b/drivers/usb/input/hid-input.c 2005-02-02 20:29:40 +01:00
@@ -492,6 +492,9 @@
if (type == EV_FF)
return hid_ff_event(hid, dev, type, code, value);
+ if (type != EV_LED)
+ return -1;
+
if ((offset = hid_find_field(hid, type, code, field)) == -1) {
warn(event field not found);
return -1;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
Hi Andrew, What are your thoughts about inclusion of Mel's allocator work on -mm ? On Wed, Feb 02, 2005 at 12:31:36AM +, Mel Gorman wrote: On Tue, 1 Feb 2005, Christoph Lameter wrote: On Tue, 1 Feb 2005, Mel Gorman wrote: Would it not be better to zero the global 2^MAX_ORDER pages by the scrub daemon and have a global zeroed page list? That way you may avoid zeroing when splitting pages? Maybe, but right now when there are no 2^MAX_ORDER pages, the scrub daemon is going to be doing nothing which is why I think it needs to look at the free pages of lower orders. That is solveable though in one of two ways. One, the scrub daemon can zero pages from the global list and then add them to the USERZERO pool. It has the advantage of requiring no more memory and is simple. The second is to create a second global list. However, I think it only makes sense to have this as part of the scrub daemon patch (I can write it if thats a problem) rather than a standalone patch from me. Approach one is fine and I will do an update the remaining prezero patches to do just that. There is another problem with approach one. Assuming all 2^MAX_ORDER pages have been zeroed and in USERZERO pool and there are no other free pages, an allocation for the USERRCLM pool would search all the other pools before finding the zerod pages. This could really slow things up but it is not a problem approach two suffers from. When will your patches be in Linus tree? ;-) Your guess is as good as mine :) . I am fairly sure the allocator is somewhere in Andrew's list of patches to look at to consider for inclusion into -mm so I suppose it'll get a spin in that tree when he feels it's ready. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
Pete Zaitcev [EMAIL PROTECTED] writes:
On 30 Jan 2005 12:10:34 +0100, Peter Osterlund [EMAIL PROTECTED] wrote:
- Slow motion of finger produces no motion, then a jump. So, it's very
hard to
target smaller UI elements and some web links.
I see this too when I don't use the X touchpad driver. With the X
driver there is no problem. I think the problem is that mousedev.c in
the kernel has to use integer arithmetic, so probably small movements
are rounded off to 0. I'll try to come up with a fix for this.
Thanks for the hint. I tried various schemes and mathematical transformations
and found one which gives unquestionably the best result, with smoothest, most
precise and comfortable pointer movement:
Please try this patch instead. It works well with my alps touchpad. (I
don't have a synaptics touchpad.) It does the following:
* Compensates for the lack of floating point arithmetic by keeping
track of remainders from the integer divisions.
* Removes the xres/yres scaling so that you get the same speed in the
X and Y directions even if your screen is not square.
* Sets scale factors so that the speed for synaptics and alps should
be equal to each other and equal to the synaptics speed from 2.6.10.
Signed-off-by: Peter Osterlund [EMAIL PROTECTED]
---
linux-petero/drivers/input/mousedev.c | 26 +-
1 files changed, 17 insertions(+), 9 deletions(-)
diff -puN drivers/input/mousedev.c~mousedev-roundoff drivers/input/mousedev.c
--- linux/drivers/input/mousedev.c~mousedev-roundoff2005-02-02
20:54:23.0 +0100
+++ linux-petero/drivers/input/mousedev.c 2005-02-02 21:42:39.0
+0100
@@ -71,6 +71,7 @@ struct mousedev {
struct mousedev_hw_data packet;
unsigned int pkt_count;
int old_x[4], old_y[4];
+ int frac_dx, frac_dy;
unsigned long touch;
};
@@ -117,24 +118,31 @@ static struct mousedev mousedev_mix;
static void mousedev_touchpad_event(struct input_dev *dev, struct mousedev
*mousedev, unsigned int code, int value)
{
- int size;
+ int size, tmp;
+#define FRACTION_DENOM 100
if (mousedev-touch) {
+ size = dev-absmax[ABS_X] - dev-absmin[ABS_X];
+ if (size == 0) size = xres;
switch (code) {
case ABS_X:
- size = dev-absmax[ABS_X] - dev-absmin[ABS_X];
- if (size == 0) size = xres;
fx(0) = value;
- if (mousedev-pkt_count = 2)
- mousedev-packet.dx = ((fx(0) - fx(1))
/ 2 + (fx(1) - fx(2)) / 2) * xres / (size * 2);
+ if (mousedev-pkt_count = 2) {
+ tmp = ((fx(0) - fx(2)) * (250 *
FRACTION_DENOM)) / size;
+ tmp += mousedev-frac_dx;
+ mousedev-packet.dx = tmp /
FRACTION_DENOM;
+ mousedev-frac_dx = tmp -
mousedev-packet.dx * FRACTION_DENOM;
+ }
break;
case ABS_Y:
- size = dev-absmax[ABS_Y] - dev-absmin[ABS_Y];
- if (size == 0) size = yres;
fy(0) = value;
- if (mousedev-pkt_count = 2)
- mousedev-packet.dy = -((fy(0) - fy(1))
/ 2 + (fy(1) - fy(2)) / 2) * yres / (size * 2);
+ if (mousedev-pkt_count = 2) {
+ tmp = -((fy(0) - fy(2)) * (250 *
FRACTION_DENOM)) / size;
+ tmp += mousedev-frac_dy;
+ mousedev-packet.dy = tmp /
FRACTION_DENOM;
+ mousedev-frac_dy = tmp -
mousedev-packet.dy * FRACTION_DENOM;
+ }
break;
}
}
_
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] savagefb.c: make some code static
The patch below makes some needlessly global code static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 21 Nov 2004
drivers/video/savage/savagefb.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.10-rc2-mm2-full/drivers/video/savage/savagefb.c.old
2004-11-21 14:57:29.0 +0100
+++ linux-2.6.10-rc2-mm2-full/drivers/video/savage/savagefb.c 2004-11-21
14:58:53.0 +0100
@@ -1458,7 +1458,7 @@
}
-void savage_disable_mmio (struct savagefb_par *par)
+static void savage_disable_mmio (struct savagefb_par *par)
{
unsigned char val;
@@ -2241,7 +2241,7 @@
/* * init in-kernel code ** */
-int __init savagefb_setup(char *options)
+static int __init savagefb_setup(char *options)
{
#ifndef MODULE
char *this_opt;
@@ -2256,7 +2256,7 @@
return 0;
}
-int __init savagefb_init(void)
+static int __init savagefb_init(void)
{
char *option;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 scrub daemon (prezeroing)
On Wed, 2 Feb 2005, Marcelo Tosatti wrote: Some architectures tend to have spare DMA engines lying around. There's no need to use the CPU for zeroing pages. How feasible would it be for scrubd to use these? [...] I suppose you are talking about DMA engines which are not being driven by any driver ? E.g. the Broadcom's MIPS64-based SOCs have four general purpose DMA engines onchip which can transfer data to/from the memory controller in 32-byte chunks over the 256-bit internal bus. We have hardly any use for these devices and certainly not for all four of them. Sounds very interesting idea to me. Guess it depends on whether the cost of DMA write for memory zeroing, which is memory architecture/DMA engine dependant, offsets the cost of CPU zeroing. I suppose so, at least with the Broadcom's chips you avoid cache trashing, yet you don't need to care about stale data as coherency between CPUs and the onchip memory controller is maintained automatically by hardware. Maciej - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] update Computone MAINTAINERS entry
On Mon, Jan 17, 2005 at 08:56:04PM -0500, Michael H. Warfield wrote: On Sat, Jan 01, 2005 at 06:28:32PM +0100, Adrian Bunk wrote: ... It seems you are still active :-) , so why is it Orphaned? Good question. Probably someone jumping the gun a bit because I haven't been very active on that driver lately. I do tend to drop off the radar for months at a time, depending on other projects and engagements. I haven't done updates to the driver in the 2.6 kernel and, yes, it is broken. ... What about the patch below? cu Adrian -- snip -- Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- linux-2.6.11-rc2-mm2-full/MAINTAINERS.old 2005-02-02 18:51:25.0 +0100 +++ linux-2.6.11-rc2-mm2-full/MAINTAINERS 2005-02-02 18:52:13.0 +0100 @@ -561,10 +561,9 @@ COMPUTONE INTELLIPORT MULTIPORT CARD P: Michael H. Warfield -M: Michael H. Warfield [EMAIL PROTECTED] +M: [EMAIL PROTECTED] W: http://www.wittsend.com/computone.html -L: [EMAIL PROTECTED] -S: Orphaned +S: Maintained COSA/SRP SYNC SERIAL DRIVER P: Jan Yenya Kasprzak - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 scrub daemon (prezeroing)
On Wed, Feb 02, 2005 at 11:05:14AM -0800, Christoph Lameter wrote: On Wed, 2 Feb 2005, Marcelo Tosatti wrote: Sounds very interesting idea to me. Guess it depends on whether the cost of DMA write for memory zeroing, which is memory architecture/DMA engine dependant, offsets the cost of CPU zeroing. Do you have any thoughts on that? I wonder if such thing (using unrelated devices DMA engine's for zeroing) ever been done on other OS'es? AFAIK SGI's BTE is special purpose hardware for memory zeroing. Nope the BTE is a block transfer engine. Its an inter numa node DMA thing that is being abused to zero blocks. Ah, OK. Is there a driver for normal BTE operation or is not kernel-controlled ? The same can be done with most DMA chips (I have done so on some other platforms not on i386) Nice! What kind of DMA chip was that and through which kind of bus was it connected to CPU ? I wonder what has to be done to have active DMA engines be abused for zeroing when idle and what are the implications of that. Some kind of notification mechanism is necessary to inform idleness ? Someone should try implementing the zeroing driver for a fast x86 PCI device. :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
On Wed, Feb 02, 2005 at 10:44:22AM -0600, Jack O'Quin wrote: Bill Huey (hui) [EMAIL PROTECTED] writes: Also, as media apps get more sophisticated they're going to need some kind of access to the some traditional softirq facilities, possibily migrating it into userspace safely somehow, with how it handles IO processing such as iSCSI, FireWire, networking and all peripherals that need some kind of prioritized IO handling. It's akin to O_DIRECT, where folks need to determine policy over the kernel's own facilities, IO queues, but in a more broad way. This is inevitable for these category of apps. Scary ? yes I know. I believe Ingo's RT patches already support this on a per-IRQ basis. Each IRQ handler can run in a realtime thread with priority assigned by the sysadmin. Balancing the interrupt handler priorities with those of other realtime activities allows excellent control. No they don't. That's a physical mapping of these kernel entities, not a logic organization that projects upward to things like individual sockets or file streams. The current irq-thread patches are primarily for dealing with the low level acks and stuff for the devices in question. It does not deal with queuing policy or how these things are scheduler on a logical basis, which is what softirqs do. softirqs group a number of things together in one big uncontrollable chunk. Really, a bit of time spent in the kernel regarding this would clarify it more in the future. Don't speculate. This misunderstanding, often babble, from app folks is why kernel folks partially dismiss the needs requested from this subgroup. It's important to understand your needs before articulating it to a wider community. The kernel community must understand the true nature of these needs and then facilitate them. If the relationship is where kernel folks dictate what apps folks have, you basically pervert the relationbship and the responsiblities of overall development, which fatally cripples app and all development of this nature. It's a two way street, but kernel folks can be more proactive about it, definitely. Step one in this is to acknowlege that Unix scheduling semantics is inantiquated with regard to media apps. Some notion of scoping needs to be put in. Everybody on the same page ? This is really only useful within the context of a dedicated realtime system, of course. Stephane Letz reports a similar feature in Mac OS X. OS X is very coarse grained (two funnels) and I would seriously doubt that it would perform without scheduling side effects to the overall system because of that. With a largely stalled FreeBSD SMPng project where they hijack a good chunk of their code into an antiquate and bloated Mach threading system, that situation isn't helping it. What the Linux community has with the RT patches is potentially light years ahead of OS X regarding overall system latency, since RT and SMP performance is tightly related. It's just a matter of getting right folks to understand the problem space and then make changes so that the overall picture is completed. bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dm-crypt crypt_status reports key?
From looking at the dm_crypt code, it appears that it can be interrogated to report the current key. Some quick testing shows: # dmsetup table /dev/mapper/volume1 0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0 Obviously, root can in principle recover this password from the running kernel but it seems silly to make it so easy. Moreover, it seems this facility exists to support some form of automated table storage (LVM?). As we don't want anyone/anything accidentally storing our passwords on disk in the clear, we probably shouldn't facilitate this. Perhaps we can stick something here like secret that the dm_crypt constructor can reject. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
On Wed, 02 Feb 2005 13:07:21 -0800 (PST), Peter Osterlund
[EMAIL PROTECTED] wrote:
+ if (mousedev-pkt_count = 2) {
+ tmp = ((fx(0) - fx(2)) * (250 *
FRACTION_DENOM)) / size;
+ tmp += mousedev-frac_dx;
+ mousedev-packet.dx = tmp /
FRACTION_DENOM;
+ mousedev-frac_dx = tmp -
mousedev-packet.dx * FRACTION_DENOM;
+ }
What about setting scale to 256 and fractions to 128 - that should
save some cycles? Or it will be too much?
--
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: A scrub daemon (prezeroing)
On Wed, 2005-02-02 at 21:00 +, Maciej W. Rozycki wrote: E.g. the Broadcom's MIPS64-based SOCs have four general purpose DMA engines onchip which can transfer data to/from the memory controller in 32-byte chunks over the 256-bit internal bus. We have hardly any use for these devices and certainly not for all four of them. On machines like the Ocelot, I keep intending to abuse one of the DMA engines for access to the DiskOnChip. Really must dig the Ocelot out of the dusty pile of toys... :) -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
On Wed, Feb 02, 2005 at 10:21:00PM +0100, Ingo Molnar wrote: yes and no. You are right in that the individual workloads (e.g. softirqs) are not separated and identified/credited to the thread that requested them. (in part due to the fact that you cannot e.g. credit a thread for e.g. unrequested workloads like incoming sockets, or for 'merged' workloads like writeout of a commonly accessed file.) What's not being addressed here is a need for pervasive QoS across all kernel systems. The power of this patch is multiplicative. It's not about a specific component of the system having microsecond latencies, it's about how all parts, softirqs, hardirqs, VM, etc... work together so that the entire system is suitable for (near) hard real time. It's unconstrained, unlike dual kernel RT systems, across all component boundaries. Those constraints create large chunks of glue logic between systems, which is exploded the complexity of things that app folks much deal with. This is where properly written Linux apps (non exist right now because of kernel issues) can really overtake competing apps from other OSes (ignoring how crappy X11 is). but Jack is right in practical terms: the audio folks achieved pretty good results with the current IRQ threading mechanism, partly due to the fact that the audio stack doesnt use softirqs, so all the latency-critical activities are in the audio IRQ thread and the application itself. It's clever that they do that, but additional control is needed in the future. jackd isn't the most sophisticate media app on this planet (not too much of an insult :)) and the demands from this group is bound to increase as their group and competing projects get more and more sophisticated. When I mean kernel folks needs to be proactive, I really mean it. The Linux kernel latency issues and poor driver support is largely why media apps are way below even being second rate with regard to other operating systems such as Apple's OS X for instance. bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] readahead: factor out duplicated code
Oleg Nesterov wrote:
This patch introduces make_ahead_window() function for
simplification of page_cache_readahead.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 2.6.11-rc2/mm/readahead.c~ 2005-01-27 22:14:39.0 +0300
+++ 2.6.11-rc2/mm/readahead.c 2005-01-29 15:51:04.0 +0300
@@ -406,6 +406,37 @@ blockable_page_cache_readahead(struct ad
return check_ra_success(ra, nr_to_read, actual);
}
+static int make_ahead_window(struct address_space *mapping, struct file *filp,
+ struct file_ra_state *ra, int force)
+{
+ int block, ret;
+
+ ra-ahead_size = get_next_ra_size(ra);
+ ra-ahead_start = ra-start + ra-size;
+
+ block = force || (ra-prev_page = ra-ahead_start);
+ ret = blockable_page_cache_readahead(mapping, filp,
+ ra-ahead_start, ra-ahead_size, ra, block);
+
+ if (!ret !force) {
This really needs to be
if (!ret !block) {
otherwise we can have an aheadwindow which was never populated which
will cause slow reads which we want to avoid in all cases.
+ /* A read failure in blocking mode, implies pages are
+ * all cached. So we can safely assume we have taken
+ * care of all the pages requested in this call.
+ * A read failure in non-blocking mode, implies we are
+ * reading more pages than requested in this call. So
+ * we safely assume we have taken care of all the pages
+ * requested in this call.
+ *
+ * Just reset the ahead window in case we failed due to
+ * congestion. The ahead window will any way be closed
+ * in case we failed due to excessive page cache hits.
+ */
Hmmm.. I realize that this piece is not really new, but I don't like
the fact that we can zero out the ahead window just because of a
complete cache hit. This will screw up logic for closing the window on
repeated cache hits by possibly repeatedly getting hits on the same
pages over and over again.
I guess this raises the question in my mind, which is Is all of the
congestion code really worth it? It is pretty much a corner case that
we don't want to block, plus that fact that we might block anyway even
with the congestion code (timing hole), and more than likely since we
are in sequential read pattern already and the device is really slow(ie
congested) we will most likely block soon anyway when we come back for
these pages. Just a thought.
+ ra-ahead_start = 0;
+ ra-ahead_size = 0;
+ }
+
+ return ret;
+}
/*
* page_cache_readahead is the main function. If performs the adaptive
* readahead window size management and submits the readahead I/O.
@@ -415,9 +446,8 @@ page_cache_readahead(struct address_spac
struct file *filp, unsigned long offset,
unsigned long req_size)
{
- unsigned long max;
- unsigned long newsize = req_size;
- unsigned long block;
+ unsigned long max, newsize = req_size;
+ int sequential = (offset == ra-prev_page + 1);
/*
* Here we detect the case where the application is performing
@@ -428,6 +458,7 @@ page_cache_readahead(struct address_spac
if (offset == ra-prev_page req_size == 1 ra-size != 0)
goto out;
+ ra-prev_page = offset;
max = get_max_readahead(ra);
newsize = min(req_size, max);
@@ -435,13 +466,16 @@ page_cache_readahead(struct address_spac
newsize = 1;
goto out; /* No readahead or file already in cache */
}
+
+ ra-prev_page += newsize - 1;
+
/*
* Special case - first read. We'll assume it's a whole-file read if
* at start of file, and grow the window fast. Or detect first
* sequential access
*/
if ((ra-size == 0 offset == 0) /* first io and start of file */
- || (ra-size == -1 ra-prev_page == offset - 1)) {
+ || (ra-size == -1 sequential)) {
/* First sequential */
ra-size = get_init_ra_size(newsize, max);
ra-start = offset;
@@ -457,12 +491,9 @@ page_cache_readahead(struct address_spac
* IOs,* thus preventing stalls. so issue the ahead window
* immediately.
*/
- if (req_size = max) {
- ra-ahead_size = get_next_ra_size(ra);
- ra-ahead_start = ra-start + ra-size;
- blockable_page_cache_readahead(mapping, filp,
-ra-ahead_start, ra-ahead_size, ra, 1);
- }
+ if (req_size = max)
+ make_ahead_window(mapping, filp, ra, 1);
+
goto out;
}
@@ -471,7 +502,7 @@ page_cache_readahead(struct address_spac
* partial page reads and first access were handled above,
* so this must be the next page otherwise it is random
*/
- if ((offset != (ra-prev_page+1) || (ra-size == 0))) {
+ if (!sequential || (ra-size == 0)) {
Re: A scrub daemon (prezeroing)
On Wed, 2005-02-02 at 14:31 -0200, Marcelo Tosatti wrote: Someone should try implementing the zeroing driver for a fast x86 PCI device. :) The BT848/BT878 seems like an ideal candidate. That kind of abuse is probably only really worth it on an architecture with cache-coherent DMA though. If you have to flush the cache anyway, you might as well just zero it from the CPU. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Altix : ioc4 serial driver support
On Wed, 02 Feb 2005 14:36:15 -0600, Patrick Gefre [EMAIL PROTECTED] wrote: Christoph Hellwig wrote: Do you need to use ide_pci_register_driver? IOC4 doesn't have the legacy IDE problems, and it's never used together with such devices in a system, so a plain pci_register_driver should do it. So ide_pci_register_driver is only for legacy devices with certain IDE problems - I think that is what you are saying (just trying to make sure I have it right) ?? ide_pci_register() is needed because of legacy ordering assumptions (from BIOS and/or Windows) in case of many PCI IDE devices. If there is no possibility of other IDE PCI devices on your architecture it is safe to call pci_register_driver() directly (see ide_scan_pcibus() in setup-pci.c). BTW IDE part of the patch looks OK. Thanks, Bartlomiej - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
What does one need to do to: a) put tapping back in, and b) fix the severe jerkiness with small movements 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: Touchpad problems with 2.6.11-rc2
Dmitry Torokhov [EMAIL PROTECTED] writes:
On Wed, 02 Feb 2005 13:07:21 -0800 (PST), Peter Osterlund
[EMAIL PROTECTED] wrote:
+ if (mousedev-pkt_count = 2) {
+ tmp = ((fx(0) - fx(2)) * (250 *
FRACTION_DENOM)) / size;
+ tmp += mousedev-frac_dx;
+ mousedev-packet.dx = tmp /
FRACTION_DENOM;
+ mousedev-frac_dx = tmp -
mousedev-packet.dx * FRACTION_DENOM;
+ }
What about setting scale to 256 and fractions to 128 - that should
save some cycles? Or it will be too much?
It at least saves 32 bytes of object code. The mouse pointer speed
increase will only be 256/250, or 2.4%, so shouldn't be a problem.
Setting FRACTION_DENOM to a larger value is actually a good thing as
long as it doesn't cause arithmetic overflow.
Here is an updated patch:
Signed-off-by: Peter Osterlund [EMAIL PROTECTED]
---
linux-petero/drivers/input/mousedev.c | 26 +-
1 files changed, 17 insertions(+), 9 deletions(-)
diff -puN drivers/input/mousedev.c~mousedev-roundoff drivers/input/mousedev.c
--- linux/drivers/input/mousedev.c~mousedev-roundoff2005-02-02
20:54:23.0 +0100
+++ linux-petero/drivers/input/mousedev.c 2005-02-02 22:20:15.0
+0100
@@ -71,6 +71,7 @@ struct mousedev {
struct mousedev_hw_data packet;
unsigned int pkt_count;
int old_x[4], old_y[4];
+ int frac_dx, frac_dy;
unsigned long touch;
};
@@ -117,24 +118,31 @@ static struct mousedev mousedev_mix;
static void mousedev_touchpad_event(struct input_dev *dev, struct mousedev
*mousedev, unsigned int code, int value)
{
- int size;
+ int size, tmp;
+#define FRACTION_DENOM 128
if (mousedev-touch) {
+ size = dev-absmax[ABS_X] - dev-absmin[ABS_X];
+ if (size == 0) size = xres;
switch (code) {
case ABS_X:
- size = dev-absmax[ABS_X] - dev-absmin[ABS_X];
- if (size == 0) size = xres;
fx(0) = value;
- if (mousedev-pkt_count = 2)
- mousedev-packet.dx = ((fx(0) - fx(1))
/ 2 + (fx(1) - fx(2)) / 2) * xres / (size * 2);
+ if (mousedev-pkt_count = 2) {
+ tmp = ((fx(0) - fx(2)) * (256 *
FRACTION_DENOM)) / size;
+ tmp += mousedev-frac_dx;
+ mousedev-packet.dx = tmp /
FRACTION_DENOM;
+ mousedev-frac_dx = tmp -
mousedev-packet.dx * FRACTION_DENOM;
+ }
break;
case ABS_Y:
- size = dev-absmax[ABS_Y] - dev-absmin[ABS_Y];
- if (size == 0) size = yres;
fy(0) = value;
- if (mousedev-pkt_count = 2)
- mousedev-packet.dy = -((fy(0) - fy(1))
/ 2 + (fy(1) - fy(2)) / 2) * yres / (size * 2);
+ if (mousedev-pkt_count = 2) {
+ tmp = -((fy(0) - fy(2)) * (256 *
FRACTION_DENOM)) / size;
+ tmp += mousedev-frac_dy;
+ mousedev-packet.dy = tmp /
FRACTION_DENOM;
+ mousedev-frac_dy = tmp -
mousedev-packet.dy * FRACTION_DENOM;
+ }
break;
}
}
_
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] Linux Kernel Subversion Howto
Il giorno 02/feb/05, alle 16:54, Stelian Pop ha scritto: Hi, I've played lately a bit with Subversion and used it for managing the kernel sources, using Larry McVoy's bk2cvs bridge and Ben Collins' bkcvs2svn conversion script. Really useful, thanks ! I'm using svn to manage a very small part of the kernel tree (2 files). It is difficult to keep in sync with mainstream development without having to fetch and keep huge amounts of data (this regardless of the version control system used). For now I'm keeping the latest stable 2.6 release of the files I need in the svn repo, then when I need to sync with the rest of the world, I get the latest -bk patch and see if there are some related changes. If so, I create a new branch, apply the -bk patch (only the interesting part) and then apply my modifications on top of that. That still means I have to download usually a 1MB compressed file for ~60KB of interesting (uncompressed) data, but that is still much better than the gigabytes of network traffic needed for a full kernel tree and up to date working copies. Thanks, bye. -- Daniele Vezano http://teg.homeunix.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
Bill Huey (hui) wrote: On Tue, Feb 01, 2005 at 11:10:48PM -0600, Jack O'Quin wrote: Ingo Molnar [EMAIL PROTECTED] writes: (also, believe me, this is not arrogance or some kind of game on our part. If there was a nice clean solution that solved your and others' problems equally well then it would already be in Linus' tree. But there is no such solution yet, at the moment. Moreover, the pure fact that so many patch proposals exist and none looks dominantly convincing shows that this is a problem area for which there are no easy solutions. We hate such moments just as much as you do, but they do happen.) The actual requirement is nowhere near as difficult as you imagine. You and several others continue to view realtime in a multi-user context. That doesn't work. No wonder you have no good solution. A notion of process/thread scoping is needed from my point of view. How to implement that is another matter and there are no clear solutions that don't involve major changes in some way to fundamental syscalls like fork/clone() and underlying kernel structures from what I see. The very notion of Unix fork semantics isn't sufficient enough to contain these semantics. It's more about controlling things with known quantities over time, not about process creation relationships, and therein lies the mismatch. Also, as media apps get more sophisticated they're going to need some kind of access to the some traditional softirq facilities, possibily migrating it into userspace safely somehow, with how it handles IO processing such as iSCSI, FireWire, networking and all peripherals that need some kind of prioritized IO handling. It's akin to O_DIRECT, where folks need to determine policy over the kernel's own facilities, IO queues, but in a more broad way. This is inevitable for these category of apps. Scary ? yes I know. Think XFS streaming with guaranteed rate IO, then generalize this for all things that can be streamed in the kernel. A side note, they'll also be pegging CPU usage and attempting to draw to the screen at the same time. It would be nice to have slack from scheduler frames be use for less critical things such as drawing to the screen. The policy for scheduling these IO requests maybe divorced from the actual priority of the thread requesting it which present some problems with the current Linux code as I understand it. Whether this suitable for main stream inclusion is another matter. But as a person that wants to write apps of this nature, I came into this kernel stuff knowing that there's going to be a conflict between the the needs of media apps folks and what the Linux kernel folks will tolerate as a community. The humble RT-LSM was actually optimal for the multi-user scenario: don't load it. Then it adds no security issues, complexity or scheduler pathlength. As an added benefit, the sysadmin can easily verify that it's not there. The cost/performance characteristics of commodity PC's running Linux are quite compelling for a wide range of practical realtime applications. But, these are dedicated machines. The whole system must be carefully tuned. That is the only method that actually works. The scheduler is at most a peripheral concern; the best it can do is not screw up. It's very compelling and very deadly to the industry if these things become common place in the normal Linux kernel. It would instantly make Linux the top platform for anything media related, graphic and audio. (Hopefully, I can get back to kernel coding RT stuff after this current distraction that has me reassigned onto an emergency project) I hope I clarified some of this communication and not completely scare Ingo and others too much. Just a little bit is ok. :) As Ingo said in an earlier a post, with a little ingenuity this problem can be solved in user space. The programs in question can be setuid root so that they can set RT scheduling policy BUT have their permissions set so that they only executable by owner and group with the group set to a group that only contains those users that have permission to run this program in RT mode. If you wish to allow other users to run the program but not in RT mode then you would need two copies of the program: one set up as above and the other with normal permissions. It may be necessary for users that are members of this RT group to do a newgrp before running this program if it isn't their primary group. But that could be done in a shell wrapper. If you have the source code for the programs then they could be modified to drop the root euid after they've changed policy. Or even do the group membership check inside the program and if the user that launches the program is not a member of the group drop root euid immediately on start up. Peter -- Peter Williams [EMAIL PROTECTED] Learning, n. The kind of ignorance distinguishing the studious. -- Ambrose Bierce - To unsubscribe from this list: send the line unsubscribe linux-kernel
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
On Wed, 2 Feb 2005, Andrew Morton wrote: Marcelo Tosatti [EMAIL PROTECTED] wrote: What are your thoughts about inclusion of Mel's allocator work on -mm ? It's sitting in my to-do pile. Tell me when you need my prezeroing patches on top of mel's patches - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
