Re: 2.6.11 cpufreq: Device or resource busy
Hugo Mills <[EMAIL PROTECTED]> wrote:
>
>I've just upgraded my laptop (ASUS M3000 -- see below) from 2.6.10
> to 2.6.11. It now seems to be unable to load the acpi_cpufreq module:
>
> [EMAIL PROTECTED]:hrm $ sudo modprobe acpi-cpufreq
> FATAL: Error inserting acpi_cpufreq
> (/lib/modules/2.6.11-plain/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko):
> Device or resource busy
Presumably there's already a cpufreq driver regisered when you try to load
the acpi_cpufreq module.
If you can work out how to enable cpufreq debugging, then do so. Or apply
the below patch, see what driver is being registered.
--- 25/drivers/cpufreq/cpufreq.c~a 2005-03-08 23:45:21.0 -0800
+++ 25-akpm/drivers/cpufreq/cpufreq.c 2005-03-08 23:45:28.0 -0800
@@ -1351,7 +1351,7 @@ int cpufreq_register_driver(struct cpufr
((!driver_data->setpolicy) && (!driver_data->target)))
return -EINVAL;
- dprintk("trying to register driver %s\n", driver_data->name);
+ printk("trying to register driver %s\n", driver_data->name);
if (driver_data->setpolicy)
driver_data->flags |= CPUFREQ_CONST_LOOPS;
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-mm2 vs audio for kino and tvtime
On Wednesday 09 March 2005 01:44, Andrew Morton wrote: >Gene Heskett <[EMAIL PROTECTED]> wrote: >> Greetings Andrew; > >g'day. > g'day to you, sir. >> 2.6.11-mm2 seems to work, mostly. >> >> First, the ieee1394 stuff seems to have fixed up that driver, and >> kino can access my movie cameras video over the firewire very >> nicely without applying the bk-ieee1394-patch. The camera has >> builtin stereo mics in it, but nary a peep can be heard from it >> thru the firewire. Am I supposed to be able to hear that? > >Was it working with 2.6.11+bk-ieee1394.patch? Or with anything > else? It did work previously with the svn download from the ieee1394 site for the kernels in the series of RT stuff that Ingo Molnar was working on. Also, since I posted this, I tried catting a .wav file to /dev/dsp, which is the output that kino is expecting to use, and that sort of worked, playing the file at half speed and pitch. So I believe its the upload from the camera, and the stripping of the audio data from the stream from the camera thats at fault. But thats just a SWAG on my part, & I probably should not have used the S there. :) >Cc'ed [EMAIL PROTECTED] > >> Second, I have a pdHDTV-3000 card, and up till now I've been >> overwriting the bttv stuffs with the drivers in pcHDTV-1.6.tar.gz >> by doing a make clean;make;make install. But now thats broken, >> and the error message doesn't seem to make sense to this old K C >> guy. >> >> The error exit: >> make[1]: Entering directory `/usr/src/linux-2.6.11-mm2' >> CC >> [M] >> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o >> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36 >>2: error: unknown field `id' specified in initializer >> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36 >>2: warning: missing braces around initializer >> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36 >>2: warning: (near initialization for >> `bttv_i2c_client_template.released') >> make[2]: *** >> [/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o] >> Error 1 >> make[1]: *** >> [_module_/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver] >> Error 2 >> make[1]: Leaving directory `/usr/src/linux-2.6.11-mm2' >> make: *** [modules] Error 2 >> >> The braces are indeed there. > >What's pcHDTV-1.6.tar.gz? If it was merged up then these things > wouldn't happen. > This is the latest driver set for this card, downloadable from the pcHDTV site. It overwrites, when it builds and installs, the bttv and cx88xx stuffs in the modules dir. And it has worked up to 2.6.11-mm2, but I didn't get around to trying mm1. It worked with the last of the RT's from Ingo, and for 2.6.11(.1). >CC'ed video4linux-list@redhat.com >> Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've >> lost my sensors except for one on the motherboard called THRM by >> gkrellm-2.28. Nothing seems to be able to bring the w83627hf back >> to life. I'm back on 2.6.11-rc5 and thats working as expected now. >CC'ed [EMAIL PROTECTED] -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 08:19:42AM +0100, Dominik Brodowski wrote:
> On Wed, Mar 09, 2005 at 04:45:09PM +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2005-03-09 at 00:16 +0100, Dominik Brodowski wrote:
> > > > Dominik Brodowski <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Most pcmcia devices are matched to drivers using "product ID strings"
> > > > > embedded in the devices' Card Information Structures, as "manufactor
> > > > > ID /
> > > > > card ID" matches are much less reliable. Unfortunately, these
> > > > > strings cannot
> > > > > be passed to userspace for easy userspace-based loading of
> > > > > appropriate
> > > > > modules (MODNAME -- hotplug), so my suggestion is to also store
> > > > > crc32 hashes
> > > > > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> > > > >
> > > > > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
> > > >
> > > > What is the difficulty in passing these strings via /sbin/hotplug
> > > > arguments?
> > >
> > > The difficulty is that extracting and evaluating them breaks the
> > > wonderful
> > > bus-independent MODNAME implementation for hotplug suggested by Roman
> > > Kagan
> > > ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that
> > > these
> > > strings may contain spaces and other "strange" characters. The latter may
> > > be
> > > worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks
> > > really
> > > clean because of this MODNAME implementation:
> >
> > Same goes with Open Firmware match strings that we are about to pass
> > down to userspace as well. Hotplug will have to learn to deal with
> > those.
>
> Hotplug isn't the tricky part. file2alias is. Any idea on how to do that?
I do not, sorry. Rusty's the person to bug about that.
good luck,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
> > > The difficulty is that extracting and evaluating them breaks the > > > wonderful > > > bus-independent MODNAME implementation for hotplug suggested by Roman > > > Kagan > > > ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that > > > these > > > strings may contain spaces and other "strange" characters. The latter may > > > be > > > worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks > > > really > > > clean because of this MODNAME implementation: > > > > Same goes with Open Firmware match strings that we are about to pass > > down to userspace as well. Hotplug will have to learn to deal with > > those. > > Ok, any suggestions that don't involve hashes? Not sure, I haven't looked at the details & issues involves (I just "spotted" the issue about space while quick-reading lkml). I suppose quotes around the strings are good enough, at least for OF, I yet have to see a "compatible", "name" or "type" property with quotes in it... Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] -stable, how it's going to work.
So here's a first cut at how this 2.6 -stable release process is going to work that Chris and I have come up with. Does anyone have any problems/issues/questions with this? thanks, greg k-h --- Everything you ever wanted to know about Linux 2.6 -stable releases. Rules on what kind of patches are accepted, and what ones are not, into the "-stable" tree: - It must be obviously correct and tested. - It can not bigger than 100 lines, with context. - It must fix only one thing. - It must fix a real bug that bothers people (not a, "This could be a problem..." type thing.) - It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical. - No "theoretical race condition" issues, unless an explanation of how the race can be exploited. - It can not contain any "trivial" fixes in it (spelling changes, whitespace cleanups, etc.) - It must be accepted by the relevant subsystem maintainer. - It must follow Documentation/SubmittingPatches rules. Procedure for submitting patches to the -stable tree: - Send the patch, after verifying that it follows the above rules, to [EMAIL PROTECTED] - The sender will receive an ack when the patch has been accepted into the queue, or a nak if the patch is rejected. This response might take a few days, according to the developer's schedules. - If accepted, the patch will be added to the -stable queue, for review by other developers. - Security patches should not be sent to this alias, but instead to the documented [EMAIL PROTECTED] Review cycle: - When the -stable maintainers decide for a review cycle, the patches will be sent to the review committee, and the maintainer of the affected area of the patch (unless the submitter is the maintainer of the area) and CC: to the linux-kernel mailing list. - The review committee has 48 hours in which to ack or nak the patch. - If the patch is rejected by a member of the committee, or linux-kernel members object to the patch by bringing up issues that the maintainer and members did not realize, the patch will be dropped from the queue. - At the end of the review cycle, the acked patches will be added to the latest -stable release, and a new -stable release will happen. - Security patches will be accepted into the -stable tree directly from the security kernel team, and not go through the normal review cycle. Contact the kernel security team for more details on this procedure. Review committe: - This will be made up of a number of kernel developers who have volunteered for this task, and a few that haven't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-ac1
On Mon, Mar 07, 2005 at 09:34:22PM +, Alan Cox wrote: > For a couple of reasons I've not yet merged Greg's 2.6.11.1 yet but this > diff should actually apply to either right now. > > 2.6.11-ac1 > o Fix jbd race in ext3(Stephen Tweedie) > > Carried over from 2.6.10-ac BTW. What's the probability of the ITE driver making it into the stock kernel? -- Red herrings strewn hither and yon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 04:45:09PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-09 at 00:16 +0100, Dominik Brodowski wrote:
> > > Dominik Brodowski <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Most pcmcia devices are matched to drivers using "product ID strings"
> > > > embedded in the devices' Card Information Structures, as "manufactor
> > > > ID /
> > > > card ID" matches are much less reliable. Unfortunately, these strings
> > > > cannot
> > > > be passed to userspace for easy userspace-based loading of appropriate
> > > > modules (MODNAME -- hotplug), so my suggestion is to also store crc32
> > > > hashes
> > > > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> > > >
> > > > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
> > >
> > > What is the difficulty in passing these strings via /sbin/hotplug
> > > arguments?
> >
> > The difficulty is that extracting and evaluating them breaks the wonderful
> > bus-independent MODNAME implementation for hotplug suggested by Roman Kagan
> > ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these
> > strings may contain spaces and other "strange" characters. The latter may
> > be
> > worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really
> > clean because of this MODNAME implementation:
>
> Same goes with Open Firmware match strings that we are about to pass
> down to userspace as well. Hotplug will have to learn to deal with
> those.
Hotplug isn't the tricky part. file2alias is. Any idea on how to do that?
Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--update-- Re: [CHECKER] crash after fsync causing serious FS corruptions (ext2, 2.6.11)
> the mouth.) It is *expected* behaviour, yes, and it is mitigated by > two factors. (1) Metadata for ext2 is synced out every 5 seconds, > while data is synced out every 60, so the max window for this race > described above is 5 seconds, and in practice rarely shows up if you > are not using fsync. (2) Unlike BSD's fsck, when a block is owned by > two different files, we offer an option to clone the affected files so > data isn't lost, while BSD's fsck shoots both files and asks questions > later. FiSC detects another related warning: a file's data are not what they should be after fsync. Turns out that e2fsck -y clears invalid indirect blocks before it clones the shared blocks, causing file to lose data when these invalid blocks are also shared blocks. Considering the following case: file A has block 100 as indirect block on disk file B has block 100 as data block, and user writes garbage to block 100, then fsync(B). Now clearing block 100 before cloning in e2fsck would cause file B to loose its data block. Possible fix would be to clone duplicate blocks before clear invalid blocks? Any thoughts? Or user has to run e2fsck twice in this case? to reproduce the warning, get http://fisc.stanford.edu/bug5/crash.c. it uses fixed mount point /mnt/sbd0. e2fsck output: e2fsck 1.36 (05-Feb-2005) /dev/ide/host0/bus0/target0/lun0/part9 was not cleanly unmounted, check forced. Pass 1: Checking inodes, blocks, and sizes Inode 12 has illegal block(s). Clear? yes Illegal block #-2 (2517328384) in inode 12. CLEARED. Inode 12, i_blocks is 24, should be 16. Fix? yes Duplicate blocks found... invoking duplicate block passes. Pass 1B: Rescan for duplicate/bad blocks Duplicate/bad block(s) in inode 12: 22 25 26 27 Duplicate/bad block(s) in inode 13: 22 Duplicate/bad block(s) in inode 16: 25 26 27 Pass 1C: Scan directories for inodes with dup blocks. Pass 1D: Reconciling duplicate blocks (There are 3 inodes containing duplicate/bad blocks.) File ... (inode #12, mod time Tue Mar 8 21:32:38 2005) has 4 duplicate block(s), shared with 2 file(s): ... (inode #16, mod time Tue Mar 8 21:32:40 2005) ... (inode #13, mod time Tue Mar 8 21:32:39 2005) Clone duplicate/bad blocks? yes File ... (inode #13, mod time Tue Mar 8 21:32:39 2005) has 1 duplicate block(s), shared with 1 file(s): ... (inode #12, mod time Tue Mar 8 21:32:38 2005) Duplicated blocks already reassigned or cloned. File ... (inode #16, mod time Tue Mar 8 21:32:40 2005) has 3 duplicate block(s), shared with 1 file(s): ... (inode #12, mod time Tue Mar 8 21:32:38 2005) Duplicated blocks already reassigned or cloned. Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Unattached inode 12 Connect to /lost+found? yes Inode 12 ref count is 2, should be 1. Fix? yes Unattached inode 13 Connect to /lost+found? yes Inode 13 ref count is 2, should be 1. Fix? yes Unattached inode 16 Connect to /lost+found? yes Inode 16 ref count is 2, should be 1. Fix? yes Pass 5: Checking group summary information Free blocks count wrong for group #0 (28, counted=24). Fix? yes Free blocks count wrong (28, counted=24). Fix? yes Inode bitmap differences: -(14--15) Fix? yes Free inodes count wrong for group #0 (0, counted=2). Fix? yes Directories count wrong for group #0 (4, counted=2). Fix? yes Free inodes count wrong (0, counted=2). Fix? yes -Junfeng - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
On Tue, 2005-03-08 at 22:50 -0800, Matt Mackall wrote: > On Tue, Mar 08, 2005 at 10:25:58PM -0800, Dmitry Yusupov wrote: > > On Tue, 2005-03-08 at 22:05 -0800, Matt Mackall wrote: > > > On Tue, Mar 08, 2005 at 09:51:39PM -0800, Alex Aizman wrote: > > > > Matt Mackall wrote: > > > > > > > > >How big is the userspace client? > > > > > > > > > Hmm.. x86 executable? source? > > > > > > > > Anyway, there's about 12,000 lines of user space code, and growing. In > > > > the kernel we have approx. 3,300 lines. > > > > > > > > >>- 450MB/sec Read on a single connection (2-way 2.4Ghz Opteron, 64KB > > > > >>block > > > > >>size); > > > > > > > > > >With what network hardware and drives, please? > > > > > > > > > Neterion's 10GbE adapters. RAM disk on the target side. > > > > > > Ahh. > > > > > > Snipped my question about userspace deadlocks - that was the important > > > one. It is in fact why the sfnet one is written as it is - it > > > originally had a userspace component and turned out to be easy to > > > deadlock under load because of it. > > > > As Scott Ferris pointed out, the main reason for deadlock in sfnet was > > blocking behavior of page cache when daemon tried to do filesystem IO, > > namely syslog(). > > That was just one of several problems. And ISTR deciding that > particular one was quite nasty when we first encountered it though I > no longer remember the details. that's bad. since all those details might help us to avoid problems and save time in the future daemon design. I will really appreciate you will point me to other potential problems once you recall. > > > That was 2.4.x kernel. We don't know whether it is > > fixed in 2.6.x. If someone knows, please let us know. Meanwhile we came > > up with work-around design in user-space. "Paged out" problem fixed > > already in our subversion repository by utilizing mlockall() > > syscall. > > I presume this is dynamically linked against glibc? over time it will be linked against klibc as dm-multipath do. It will also help to implement iSCSI boot, when control plane daemon will be part of initramfs image. > > Also we have IMHO, working solution for OOM during ERL=0 TCP re-connect. > > Care to describe it? sure. the idea was to always keep second reserved/redundant TCP connection per session opened. (please note, TCP connection, not iSCSI connection). This way during recovery cycle in case of sane target, initiator will switch into redundant TCP connection and send Login request over. This could be implemented as a feature and might be disabled via configuration utility if needed. 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: [2.6 patch] drivers/acpi/: make some code static
Applied.
thanks,
-Len
On Thu, 2005-02-24 at 18:38, Adrian Bunk wrote:
> This patch makes some needlessly global code static.
> This patch contains only changes to files that should according to
> Len Brown not cause extra work for the ACPI maintainers.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> This patch was already sent on:
> - 30 Jan 2005
>
> drivers/acpi/ac.c | 18 +-
> drivers/acpi/battery.c |2 +-
> drivers/acpi/button.c |4 ++--
> drivers/acpi/container.c|4 ++--
> drivers/acpi/debug.c|4 ++--
> drivers/acpi/ec.c |2 +-
> drivers/acpi/fan.c | 14 +++---
> drivers/acpi/ibm_acpi.c |4 ++--
> drivers/acpi/osl.c | 10 +-
> drivers/acpi/pci_irq.c |4 ++--
> drivers/acpi/power.c| 10 +-
> drivers/acpi/processor_core.c |6 +++---
> drivers/acpi/processor_thermal.c|2 +-
> drivers/acpi/processor_throttling.c |2 +-
> drivers/acpi/scan.c | 12
> drivers/acpi/thermal.c |2 +-
> drivers/acpi/toshiba_acpi.c |2 +-
> drivers/acpi/video.c|2 +-
> include/acpi/acpi_bus.h |1 -
> include/acpi/processor.h|2 --
> include/linux/acpi.h|2 --
> 21 files changed, 54 insertions(+), 55 deletions(-)
>
> --- linux-2.6.11-rc2-mm1-full/drivers/acpi/ac.c.old 2005-01-26
> 19:55:44.0 +0100
> +++ linux-2.6.11-rc2-mm1-full/drivers/acpi/ac.c 2005-01-26
> 19:57:37.0 +0100
> @@ -51,8 +51,8 @@
> MODULE_DESCRIPTION(ACPI_AC_DRIVER_NAME);
> MODULE_LICENSE("GPL");
>
> -int acpi_ac_add (struct acpi_device *device);
> -int acpi_ac_remove (struct acpi_device *device, int type);
> +static int acpi_ac_add (struct acpi_device *device);
> +static int acpi_ac_remove (struct acpi_device *device, int type);
> static int acpi_ac_open_fs(struct inode *inode, struct file *file);
>
> static struct acpi_driver acpi_ac_driver = {
> @@ -108,9 +108,9 @@
>FS Interface (/proc)
>
> -- */
>
> -struct proc_dir_entry *acpi_ac_dir;
> +static struct proc_dir_entry *acpi_ac_dir;
>
> -int acpi_ac_seq_show(struct seq_file *seq, void *offset)
> +static int acpi_ac_seq_show(struct seq_file *seq, void *offset)
> {
> struct acpi_ac *ac = (struct acpi_ac *) seq->private;
>
> @@ -200,7 +200,7 @@
> Driver Model
>
> -- */
>
> -void
> +static void
> acpi_ac_notify (
> acpi_handle handle,
> u32 event,
> @@ -232,7 +232,7 @@
> }
>
>
> -int
> +static int
> acpi_ac_add (
> struct acpi_device *device)
> {
> @@ -286,7 +286,7 @@
> }
>
>
> -int
> +static int
> acpi_ac_remove (
> struct acpi_device *device,
> int type)
> @@ -315,7 +315,7 @@
> }
>
>
> -int __init
> +static int __init
> acpi_ac_init (void)
> {
> int result = 0;
> @@ -337,7 +337,7 @@
> }
>
>
> -void __exit
> +static void __exit
> acpi_ac_exit (void)
> {
> ACPI_FUNCTION_TRACE("acpi_ac_exit");
> --- linux-2.6.11-rc2-mm1-full/drivers/acpi/battery.c.old
> 2005-01-26 19:57:52.0 +0100
> +++ linux-2.6.11-rc2-mm1-full/drivers/acpi/battery.c2005-01-26
> 19:58:07.0 +0100
> @@ -341,7 +341,7 @@
>FS Interface (/proc)
>
> -- */
>
> -struct proc_dir_entry *acpi_battery_dir;
> +static struct proc_dir_entry *acpi_battery_dir;
> static int acpi_battery_read_info(struct seq_file *seq, void *offset)
> {
> int result = 0;
> --- linux-2.6.11-rc2-mm1-full/drivers/acpi/button.c.old 2005-01-26
> 19:58:24.0 +0100
> +++ linux-2.6.11-rc2-mm1-full/drivers/acpi/button.c 2005-01-26
> 19:58:34.0 +0100
> @@ -275,7 +275,7 @@
> Driver Interface
>
> -- */
>
> -void
> +static void
> acpi_button_notify (
> acpi_handle handle,
> u32 event,
> @@ -302,7 +302,7 @@
> }
>
>
> -acpi_status
> +static acpi_status
> acpi_button_notify_fixed (
> void*data)
> {
> --- linux-2.6.11-rc2-mm1-full/drivers/acpi/container.c.old
> 2005-01-26 19:58:51.0 +0100
> +++ linux-2.6.11-rc2-mm1-full/drivers/acpi/container.c 2005-01-26
> 19:59:05.0 +0100
> @@ -255,7 +255,7 @@
> }
>
>
> -int __init
> +static int __init
>
Re: [PATCH] drm missing memset can crash X server...
* Dave Airlie ([EMAIL PROTECTED]) wrote: > > Egbert Eich reported a bug 2673 on bugs.freedesktop.org and tracked it > down to a missing memset in the setversion ioctl, this causes X server > crashes so I would like to see the fix in a 2.6.11.x tree if possible.. Could you please add Signed-off-by? Do I read this patch correctly that it effectively disables the DRM_COPY in ->version callbacks? thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Query: Kdump: Core Image ELF Format
Hi, > Now the issue is, on i386, whether to prepare core headers in ELF32 or > ELF64 format. gdb can not analyze ELF64 core image for i386 system. I > don't know about "crash". Can "crash" support ELF64 core image file for > i386 system? Of course, It must be ELF64. It is important to include all information. ELF core can be easily transfered to LKCD format. Then lcrash can be used. (I use an own tool.) Thanks. On Tue, 08 Mar 2005 18:20:10 +0530 vivek goyal <[EMAIL PROTECTED]> wrote: > Hi, > > Kdump (A kexec based crash dumping mechanism) is going to export the > kernel core image in ELF format. ELF was chosen as a format, keeping in > mind that gdb can be used for limited debugging and "Crash" can be used > for advanced debugging. > > Core image ELF headers are prepared before crash and stored at a safe > place in memory. These headers are retrieved over a kexec boot and final > elf core image is prepared for analysis. > > Given the fact physical memory can be dis-contiguous, One program header > of type PT_LOAD is created for every contiguous memory chunk present in > the system. Other information like register states etc. is captured in > notes section. > > Now the issue is, on i386, whether to prepare core headers in ELF32 or > ELF64 format. gdb can not analyze ELF64 core image for i386 system. I > don't know about "crash". Can "crash" support ELF64 core image file for > i386 system? > > Given the limitation of analysis tools, if core headers are prepared in > ELF32 format then how to handle PAE systems? > > Any thoughts or suggestions on this? > > Thanks > Vivek > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Itsuro ODA <[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: [ANNOUNCE 6/6] Open-iSCSI High-Performance Initiator for Linux
On Sun, Mar 06, 2005 at 11:19:03PM -0800, Alex Aizman wrote: > +The latest development release is available at: > +http://www.open-iscsi.org I think a URL in Kconfig and the source is sufficient, as this requires a userspace component which is a better place to bundle the docs. -- 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: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
On Tue, Mar 08, 2005 at 10:25:58PM -0800, Dmitry Yusupov wrote: > On Tue, 2005-03-08 at 22:05 -0800, Matt Mackall wrote: > > On Tue, Mar 08, 2005 at 09:51:39PM -0800, Alex Aizman wrote: > > > Matt Mackall wrote: > > > > > > >How big is the userspace client? > > > > > > > Hmm.. x86 executable? source? > > > > > > Anyway, there's about 12,000 lines of user space code, and growing. In > > > the kernel we have approx. 3,300 lines. > > > > > > >>- 450MB/sec Read on a single connection (2-way 2.4Ghz Opteron, 64KB > > > >>block > > > >>size); > > > > > > > >With what network hardware and drives, please? > > > > > > > Neterion's 10GbE adapters. RAM disk on the target side. > > > > Ahh. > > > > Snipped my question about userspace deadlocks - that was the important > > one. It is in fact why the sfnet one is written as it is - it > > originally had a userspace component and turned out to be easy to > > deadlock under load because of it. > > As Scott Ferris pointed out, the main reason for deadlock in sfnet was > blocking behavior of page cache when daemon tried to do filesystem IO, > namely syslog(). That was just one of several problems. And ISTR deciding that particular one was quite nasty when we first encountered it though I no longer remember the details. > That was 2.4.x kernel. We don't know whether it is > fixed in 2.6.x. If someone knows, please let us know. Meanwhile we came > up with work-around design in user-space. "Paged out" problem fixed > already in our subversion repository by utilizing mlockall() > syscall. I presume this is dynamically linked against glibc? > Also we have IMHO, working solution for OOM during ERL=0 TCP re-connect. Care to describe it? -- 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: 2.6.11-mm2 vs audio for kino and tvtime
Gene Heskett <[EMAIL PROTECTED]> wrote: > > Greetings Andrew; g'day. > 2.6.11-mm2 seems to work, mostly. > > First, the ieee1394 stuff seems to have fixed up that driver, and kino > can access my movie cameras video over the firewire very nicely > without applying the bk-ieee1394-patch. The camera has builtin > stereo mics in it, but nary a peep can be heard from it thru the > firewire. Am I supposed to be able to hear that? Was it working with 2.6.11+bk-ieee1394.patch? Or with anything else? Cc'ed [EMAIL PROTECTED] > Second, I have a pdHDTV-3000 card, and up till now I've been > overwriting the bttv stuffs with the drivers in pcHDTV-1.6.tar.gz by > doing a make clean;make;make install. But now thats broken, and the > error message doesn't seem to make sense to this old K C guy. > > The error exit: > make[1]: Entering directory `/usr/src/linux-2.6.11-mm2' > CC > [M] /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o > /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362: > error: unknown field `id' specified in initializer > /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362: > warning: missing braces around initializer > /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362: > warning: (near initialization for > `bttv_i2c_client_template.released') > make[2]: *** > [/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o] > Error 1 > make[1]: *** > [_module_/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver] Error > 2 > make[1]: Leaving directory `/usr/src/linux-2.6.11-mm2' > make: *** [modules] Error 2 > > The braces are indeed there. What's pcHDTV-1.6.tar.gz? If it was merged up then these things wouldn't happen. CC'ed video4linux-list@redhat.com > Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've lost > my sensors except for one on the motherboard called THRM by > gkrellm-2.28. Nothing seems to be able to bring the w83627hf back to > life. CC'ed [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: Query: Kdump: Core Image ELF Format
On Tue, 2005-03-08 at 11:00 -0700, Eric W. Biederman wrote: > vivek goyal <[EMAIL PROTECTED]> writes: > > > Hi, > > > > Kdump (A kexec based crash dumping mechanism) is going to export the > > kernel core image in ELF format. ELF was chosen as a format, keeping in > > mind that gdb can be used for limited debugging and "Crash" can be used > > for advanced debugging. > > When I suggested ELF for this purpose it was not so much that it was > directly usable. But rather it was an existing file format that could > do the job, was well understood, and had enough extensibility > through the PT_NOTES segment to handle the weird cases. > > > Core image ELF headers are prepared before crash and stored at a safe > > place in memory. These headers are retrieved over a kexec boot and final > > elf core image is prepared for analysis. > > > > Given the fact physical memory can be dis-contiguous, One program header > > of type PT_LOAD is created for every contiguous memory chunk present in > > the system. Other information like register states etc. is captured in > > notes section. > > > > Now the issue is, on i386, whether to prepare core headers in ELF32 or > > ELF64 format. gdb can not analyze ELF64 core image for i386 system. I > > don't know about "crash". Can "crash" support ELF64 core image file for > > i386 system? > > > > Given the limitation of analysis tools, if core headers are prepared in > > ELF32 format then how to handle PAE systems? > > > > Any thoughts or suggestions on this? > > Generate it ELF64. We also have the problem that the kernels virtual > addresses are not used in the core dump either. Which a post-processing > tool will also have to address as well. That sounds good. But we loose the advantage of doing limited debugging with gdb. Crash (or other analysis tools) will still take considerable amount of time before before they are fully ready and tested. How about giving user the flexibility to choose. What I mean is introducing a command line option in kexec-tools to choose between ELF32 and ELF64 headers. For the users who are not using PAE systems, they can very well go with ELF32 headers and do the debugging using gdb. This also requires, setting the kernel virtual addresses while preparing the headers. KVA for linearly mapped region is known in advance and can be filled at header creation time and gdb can directly operate upon this region. > > What I aim on at was a simple picture of memory decorated with the > register state. We should be able to derive everything beyond that. > And the fact that it is all in user space should make it straight > forward to change if needed. > > 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/
[RFC] Kdump: Dump Capture Mechanism
Hi, Well this discussion has been going on for quite sometime now that what's the best way to capture the dump? There seems to be two lines of arguments. Export ELF view through /proc/vmcore This basically involves retrieving saved core image headers and exporting those through /proc/vmcore interface. Further user space applications can be built on top of it to do advanced processing. Do Everything in user space --- The whole idea is that do all the processing from user space (preferably from ramdisk or so). When it comes to requirements, Distros and developers seem to be having somewhat different requirements. Distros: --- - Fully automate the dump generation/capture process. - Configure everything in advance (like, dump storage location). - Upon crash, store dump image at pre-configured location and reboot into production kernel ASAP. Developers: -- - Keyword is simple and easy to use solution. - Should work well in a development environment where, not necessarily all the components (user space, kernel space) are in perfect harmony and things are yet to be stabilized. IMO, exporting /proc/vmcore is a good idea. It offers wide variety of choices to both developers and distros. - It provides the basic dump capturing mechanism in kernel. - Developers can store the dump image locally (cp) or transfer it over network (scp, ftp) using standard utilities and don't have to deal with additional user space utilites specifically designed for this purpose. - Developers can directly run gdb on /proc/vmcore generated image and do the limited debugging without need of any other dump capture/analysis utility. - Distros can build additional fully automated dump saving solutions on top of /proc/vmcore. Be it a init script or a custom initial ramdisk or something else... So the whole idea is, that /proc/vmcore and user space solutions can co- exist. And let the user/distros choose between these based on their requirements. I was planning to implement /proc/vmcore. Do you have any comments or suggestions? Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE 2/6] Open-iSCSI High-Performance Initiator for Linux
On Sun, Mar 06, 2005 at 11:12:06PM -0800, Alex Aizman wrote:
> +#define iscsi_ptr(_handle) ((void*)(unsigned long)_handle)
> +#define iscsi_handle(_ptr) ((uint64_t)(unsigned long)_ptr)
This is a bit wonky. Why is there a distinction?
> +#ifndef ISCSI_PROTO_H
> +#define ISCSI_PROTO_H
> +
> +#define ISCSI_VERSION_STR"0.1.0"
> +#define ISCSI_DATE_STR "17-Jan-2005"
> +#define ISCSI_DRAFT20_VERSION0x00
> +
> +/* default iSCSI listen port for incoming connections */
> +#define ISCSI_LISTEN_PORT3260
> +
> +/* Padding word length */
> +#define PAD_WORD_LEN 4
Namespace.
> +
> +/*
> + * useful common(control and data pathes) macro
> + */
> +#define ntoh24(p) (((p)[0] << 16) | ((p)[1] << 8) | ((p)[2]))
> +#define hton24(p, v) { \
> +p[0] = (((v) >> 16) & 0xFF); \
> +p[1] = (((v) >> 8) & 0xFF); \
> +p[2] = ((v) & 0xFF); \
> +}
> +#define zero_data(p) {p[0]=0;p[1]=0;p[2]=0;}
These are specific to dlength, yes? Can we instead roll dlength and
hlength together, and do this with masking?
#define iscsi_hlen(hdr) (ntohl(hdr->hdlen)>>24)
#define iscsi_dlen(hdr) (ntohl(hdr->hdlen) & 0xff)
#define iscsi_set_hlen(hdr, len) (hdr->hdlen=htonl(iscsi_dlen(hdr)|(len<<24)))
#define iscsi_set_hlen(hdr, len) (hdr->hdlen=htonl(len|(iscsi_hlen(hdr)<<24)))
The last two obviously have multiple evaluation, but you get the idea.
> +/* SNACK Header */
Mmm, snacks.
> +/* Reason for Reject */
> +#define CMD_BEFORE_LOGIN 1
> +#define DATA_DIGEST_ERROR2
> +#define DATA_SNACK_REJECT3
> +#define ISCSI_PROTOCOL_ERROR 4
> +#define CMD_NOT_SUPPORTED5
> +#define IMM_CMD_REJECT 6
> +#define TASK_IN_PROGRESS 7
> +#define INVALID_SNACK8
> +#define BOOKMARK_REJECTED9
> +#define BOOKMARK_NO_RESOURCES10
> +#define NEGOTIATION_RESET11
> +
> +/* Max. number of Key=Value pairs in a text message */
> +#define MAX_KEY_VALUE_PAIRS 8192
> +
> +/* maximum length for text keys/values */
> +#define KEY_MAXLEN 64
> +#define VALUE_MAXLEN 255
> +#define TARGET_NAME_MAXLEN VALUE_MAXLEN
> +
> +#define DEFAULT_MAX_RECV_DATA_SEGMENT_LENGTH 8192
Namespace.
--
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: Direct io on block device has performance regression on 2.6.x kernel
"Chen, Kenneth W" <[EMAIL PROTECTED]> wrote: > > Direct I/O on block device running 2.6.X kernel is a lot SLOWER > than running on a 2.4 Kernel! > A little bit slower, it appears. It used to be faster. > ... > > synchronous I/O AIO > (pread/pwrite/read/write) io_submit > 2.4.21 based > (RHEL3) 265,122 229,810 > > 2.6.9218,565 206,917 > 2.6.10 213,041 205,891 > 2.6.11 212,284 201,124 What sort of CPU? What speed CPU? What size requests? Reads or writes? At 5 usecs per request I figure that's 3% CPU utilisation for 16k requests at 100 MB/sec. Once you bolt this onto a real device driver the proportional difference will fall, due to addition of the constant factor. Once you bolt all this onto a real disk controller all the numbers will get worse (but in a strictly proportional manner) due to the disk transfers depriving the CPU of memory bandwidth. The raw driver is deprecated and we'd like to remove it. The preferred way of doing direct-IO against a blockdev is by opening it with O_DIRECT. Your patches don't address blockdevs opened with O_DIRECT. What you should do is to make def_blk_aops.direct_IO point at a new function. That will then work correctly with both raw and with open(/dev/hdX, O_DIRECT). But before doing anything else, please bench this on real hardware, see if it is worth pursuing. And gather an oprofile trace of the existing code. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
Matt Mackall wrote: On Tue, Mar 08, 2005 at 09:51:39PM -0800, Alex Aizman wrote: Matt Mackall wrote: How big is the userspace client? Hmm.. x86 executable? source? Anyway, there's about 12,000 lines of user space code, and growing. In the kernel we have approx. 3,300 lines. - 450MB/sec Read on a single connection (2-way 2.4Ghz Opteron, 64KB block size); With what network hardware and drives, please? Neterion's 10GbE adapters. RAM disk on the target side. Ahh. Snipped my question about userspace deadlocks - that was the important one. It is in fact why the sfnet one is written as it is - it originally had a userspace component and turned out to be easy to deadlock under load because of it. There's (or at least was up until today) an ongoing discussion on our mailing list at http://groups-beta.google.com/group/open-iscsi. The short and long of it: the problem can be solved, and it will. Couple simple things we already do: mlockall() to keep the daemon un-swapped, and also looking into potential dependency created by syslog (there's one for 2.4 kernel, not sure if this is an issue for 2.6). The sfnet is a learning experience; it is by no means a proof that it cannot be done. Alex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
On Tue, 2005-03-08 at 22:05 -0800, Matt Mackall wrote: > On Tue, Mar 08, 2005 at 09:51:39PM -0800, Alex Aizman wrote: > > Matt Mackall wrote: > > > > >How big is the userspace client? > > > > > Hmm.. x86 executable? source? > > > > Anyway, there's about 12,000 lines of user space code, and growing. In > > the kernel we have approx. 3,300 lines. > > > > >>- 450MB/sec Read on a single connection (2-way 2.4Ghz Opteron, 64KB block > > >>size); > > > > > >With what network hardware and drives, please? > > > > > Neterion's 10GbE adapters. RAM disk on the target side. > > Ahh. > > Snipped my question about userspace deadlocks - that was the important > one. It is in fact why the sfnet one is written as it is - it > originally had a userspace component and turned out to be easy to > deadlock under load because of it. As Scott Ferris pointed out, the main reason for deadlock in sfnet was blocking behavior of page cache when daemon tried to do filesystem IO, namely syslog(). That was 2.4.x kernel. We don't know whether it is fixed in 2.6.x. If someone knows, please let us know. Meanwhile we came up with work-around design in user-space. "Paged out" problem fixed already in our subversion repository by utilizing mlockall() syscall. Also we have IMHO, working solution for OOM during ERL=0 TCP re-connect. 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: Pktcdvd and DVD RW drive.
Jo?o Luis Meloni Assirati <[EMAIL PROTECTED]>, on Tue Mar 08, 2005 [10:56:34 PM] said: > Hello, > > I have an > > hdc: HL-DT-ST DVDRAM GSA-4120B, ATAPI CD/DVD-ROM drive > > from LG. My kernel is a vanilla 2.6.11 with packet writing enabled. I > noticed, > however, that I can mount and write a CD-RW udf formatted with > > # cdrwtool -d /dev/hdc -q > > without the need of the pktcdvd driver (with the module unloaded, indeed), > simply with > > # mount -t udf /dev/hdc /mnt > > I thought that this was a property only of DVD+RW and DVDRAM media. Am I > missing something here? What is then the use of pktcdvd driver? > > Thanks in advice, > Joao Luis M. Assirati. Hi; Well, I have only tested this with dvd+rw (and mount with the noatime option, to avoid wearing out your media), and it is just *way* to slow, vs. pktcdvd. I gave up on a copy that would have taken a minute or two under pktcdvd after over an hour with just the block device mount. Of course, pktcdvd gives me and others pretty consistant data corruption. (see bug 4290 on bugzilla.kernel.org) Paul [EMAIL PROTECTED] ps. others have reported that mt. rainier support works well, and obviates pktcdvd. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE 1/6] Open-iSCSI High-Performance Initiator for Linux
On Sun, Mar 06, 2005 at 11:04:51PM -0800, Alex Aizman wrote:
> SCSI LLDD consists of 3 files:
> - iscsi_if.c (iSCSI open interface over netlink);
> - iscsi_tcp.[ch] (iSCSI transport over TCP/IP).
>
> Signed-off-by: Alex Aizman <[EMAIL PROTECTED]>
> Signed-off-by: Dmitry Yusupov <[EMAIL PROTECTED]>
Some minor comments..
> +int
> +iscsi_control_recv_pdu(iscsi_cnx_h cp_cnx, struct iscsi_hdr *hdr,
> + char *data, uint32_t data_size)
Return value on the same line as the function name, please.
> +{
> + struct nlmsghdr *nlh;
> + struct sk_buff *skb;
Tabs except at the beginning of the line are a nuisance.
> + if (!skb) {
> + return -ENOMEM;
> + }
Drop the braces around single statements.
> +EXPORT_SYMBOL_GPL(iscsi_control_recv_pdu);
Is this more than one module?
> +iscsi_control_cnx_error(iscsi_cnx_h cp_cnx, iscsi_err_e error)
Your type-naming scheme is a little unusual for the kernel. err_e
appears redundant. And _h for handle could simply be _t for (opaque)
type.
> +static void
> +iscsi_if_rx(struct sock *sk, int len)
> +{
> + struct sk_buff *skb;
> + while ((skb = skb_dequeue(>sk_receive_queue)) != NULL) {
Assignments in tests are somewhat discouraged and !f is preferred to f
!= NULL.
> +#ifndef DEBUG_ASSERT
> +#ifdef BUG_ON
> +#undef BUG_ON
> +#endif
> +#define BUG_ON(expr)
> +#endif
Don't do that, please. An assertion that's not enabled is worse than
no assertion at all.
> +static inline void
> +iscsi_buf_init_hdr(struct iscsi_conn *conn, struct iscsi_buf *ibuf,
> +char *vbuf, u8 *crc)
> +{
> + iscsi_buf_init_virt(ibuf, vbuf, sizeof(struct iscsi_hdr));
> + if (conn->hdrdgst_en) {
> + crypto_digest_init(conn->tx_tfm);
> + crypto_digest_update(conn->tx_tfm, >sg, 1);
> + crypto_digest_final(conn->tx_tfm, crc);
I believe you'll find that crypto_digest_digest does that all for you.
> +#define iscsi_conn_get(rdd) (struct iscsi_conn*)(rdd)->arg.data
> +#define iscsi_conn_set(rdd, conn) (rdd)->arg.data = conn
Inlines, please. The second one is slightly broken without parens.
> + * PDU header scattered accross SKB's,
"across"
> + switch(conn->in.opcode) {
> + case ISCSI_OP_SCSI_CMD_RSP:
This switch looks like it could happily be in another function. The
indentation is making it cramped.
> +/*
> + * iscsi_ctask_copy - copy skb bits to the destanation cmd task
> + *
> + * The function calls skb_copy_bits() and updates per-connection and
> + * per-cmd byte counters.
> + */
> +static inline int
> +iscsi_ctask_copy(struct iscsi_conn *conn, struct iscsi_cmd_task *ctask,
> + void *buf, int buf_size)
> +{
Almost kerneldoc style, but not quite.
> + BUG_ON(ctask != (void*)sc->SCp.ptr);
Strange cast here.
> + if (sc->use_sg) {
> + int i;
Mixed tabs and spaces.
> + default:
> + BUG_ON(1);
BUG()?
> +static void
> +iscsi_tcp_data_ready(struct sock *sk, int flag)
> +{
> + struct iscsi_conn *conn = (struct iscsi_conn*)sk->sk_user_data;
Redundant cast here.
> +static void
> +iscsi_write_space(struct sock *sk)
> +{
> + struct iscsi_conn *conn = (struct iscsi_conn*)sk->sk_user_data;
> + conn->old_write_space(sk);
> + debug_tcp("iscsi_write_space: cid %d\n", conn->id);
> + conn->suspend = 0; wmb();
Sneaky. Separate line, please, and maybe a comment as to why the
barrier is needed.
> + debug_tcp("sendhdr %lx %d bytes at offset %d sent %d res %d\n",
> + (long)page_address(buf->sg.page), size, offset, buf->sent, res);
%p for page_address?
> +static inline int
> +iscsi_sendpage(struct iscsi_conn *conn, struct iscsi_buf *buf,
> +int *count, int *sent)
> +{
> + ssize_t (*sendpage)(struct socket *, struct page *, int, size_t, int);
[...]
> + sendpage = sk->ops->sendpage ? : sock_no_sendpage;
> +
> + res = sendpage(sk, buf->sg.page, offset, size, flags);
Can't we just do an if (a) a() else b() here? The ? : syntax
is nonstandard.
> +iscsi_solicit_data_cont(struct iscsi_conn *conn, struct iscsi_cmd_task
> *ctask,
> + struct iscsi_r2t_info *r2t, int left)
> +{
> + struct iscsi_data *hdr;
> + struct iscsi_data_task *dtask;
> + struct scsi_cmnd *sc = ctask->sc;
> + int new_offset;
> +
> + dtask = mempool_alloc(ctask->datapool, GFP_ATOMIC);
> + hdr = >hdr;
> + hdr->flags = 0;
> + hdr->rsvd2[0] = hdr->rsvd2[1] = hdr->rsvd3 =
> + hdr->rsvd4 = hdr->rsvd5 = hdr->rsvd6 = 0;
That looks odd, memset?
> +static void
> +iscsi_unsolicit_data_init(struct iscsi_conn *conn, struct iscsi_cmd_task
> *ctask)
> +{
> + struct iscsi_data *hdr;
> + struct iscsi_data_task *dtask;
> +
> + dtask = mempool_alloc(ctask->datapool, GFP_ATOMIC);
> + hdr = >hdr;
> + hdr->rsvd2[0] = hdr->rsvd2[1] = hdr->rsvd3 =
> + hdr->rsvd4
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 04:45:09PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-09 at 00:16 +0100, Dominik Brodowski wrote:
> > > Dominik Brodowski <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Most pcmcia devices are matched to drivers using "product ID strings"
> > > > embedded in the devices' Card Information Structures, as "manufactor
> > > > ID /
> > > > card ID" matches are much less reliable. Unfortunately, these strings
> > > > cannot
> > > > be passed to userspace for easy userspace-based loading of appropriate
> > > > modules (MODNAME -- hotplug), so my suggestion is to also store crc32
> > > > hashes
> > > > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> > > >
> > > > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
> > >
> > > What is the difficulty in passing these strings via /sbin/hotplug
> > > arguments?
> >
> > The difficulty is that extracting and evaluating them breaks the wonderful
> > bus-independent MODNAME implementation for hotplug suggested by Roman Kagan
> > ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these
> > strings may contain spaces and other "strange" characters. The latter may
> > be
> > worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really
> > clean because of this MODNAME implementation:
>
> Same goes with Open Firmware match strings that we are about to pass
> down to userspace as well. Hotplug will have to learn to deal with
> those.
Ok, any suggestions that don't involve hashes?
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ patch 6/7] drivers/serial/jsm: new serial device driver
On Tue, Mar 08, 2005 at 01:42:31PM -0500, Wen Xiong wrote: > The following email I got from Scott Kilau in digi: > Scott Kilau wrote: > >The DPA program is very old, and is shared among other drivers > and OS's, >so changing the code to read the sysfs instead of doing ioctls > is not possible. Hm, so we are supposed to support, for forever, custom ioctls just because another OS, that we care nothing about, supports it? Hm, I just can't think this is a acceptable thing, sorry. Especially due to the nasty 64/32 bit issues... >However, any *new* tools I write, will use sysfs, which is why > we need to have both the ioctl calls and sysfs files. Please, no new ioctls, end of story. >The digi.h file has extra structures and ioctls that may not be > used in the driver, as that header >is shared among other drivers and OS's. Please remove them as they are not needed in this OS, right? As you already had to change the naming, structure definitions, and format, you aren't sharing the file. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ patch 4/7] drivers/serial/jsm: new serial device driver
On Tue, Mar 08, 2005 at 08:36:57PM -0600, Kilau, Scott wrote: > > > > > > If you were to open up the port with an "stty -a" to get the current > > > > settings and signals, you would unintentionally raise RTS and DTR. > > > > Why not fix the driver to not change the current line settings if it > is > > not being opened for the first time? That seems like a much simpler > way > > to solve this, and probably the saner way, as you don't want any user > to > > be able to mess up your modem... > > > > Oh, when the port is already open, the driver correctly would not muck > with DTR/RTS. > > I am talking about when the port is currently not open. > > On first port open, DTR (and usually RTS) will always be raised. > The serial device would see this DTR raise, and under some > circumstances, react to it... Ok, well, that sounds like something that all serial devices should support, right? And if so, why not add this to the serial core for everyone to benifit? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
On Tue, Mar 08, 2005 at 09:51:39PM -0800, Alex Aizman wrote: > Matt Mackall wrote: > > >How big is the userspace client? > > > Hmm.. x86 executable? source? > > Anyway, there's about 12,000 lines of user space code, and growing. In > the kernel we have approx. 3,300 lines. > > >>- 450MB/sec Read on a single connection (2-way 2.4Ghz Opteron, 64KB block > >>size); > > > >With what network hardware and drives, please? > > > Neterion's 10GbE adapters. RAM disk on the target side. Ahh. Snipped my question about userspace deadlocks - that was the important one. It is in fact why the sfnet one is written as it is - it originally had a userspace component and turned out to be easy to deadlock under load because of it. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VGA arbitration: draft of kernel side
On Wed, 2005-03-09 at 00:58 -0500, Jon Smirl wrote: > On Wed, 09 Mar 2005 16:37:13 +1100, Benjamin Herrenschmidt > <[EMAIL PROTECTED]> wrote: > > On Tue, 2005-03-08 at 23:35 -0500, Jon Smirl wrote: > > > This is from /linux-2.5/Documentation/filesystems/sysfs-pci.txt. It > > > describes how ia64 is achieving legacy IO. The VGA control code > > > probably needs to be coordinated with this. > > > > This is a different thing, and I will implement it on ppc one of these > > days. This is for issuing the IO cycles on the bus. It has nothing > > to do with the actual arbitration work. > > Each one of these legacy spaces corresponds to an allowable > simultaneous VGA use. There should be one arbiter per legacy space. Ugh ? They are or they are not independant, that's a platform thing and has nothing to do with arbitration. They aren't VGA specific neither. The arbitrer uses the vga_conflicts() callback for that purpose. It is defined to always return 1 by default, but the platform can override it if it has separate PCI domains, in order to tell the arbitrer wether 2 cards can conflict or not. Based on that, the arbitrer will, or will not, let you lock the VGA legacy resources simultaneously. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [announce 0/7] fbsplash - The Framebuffer Splash
On Wed, 9 Mar 2005 13:01:15 +0800, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > On Tuesday 08 March 2005 09:57, Michal Januszewski wrote: > > Fbsplash - The Framebuffer Splash - is a feature that allows displaying > > images in the background of consoles that use fbcon. The project is > > partially descended from bootsplash. > > > > Unlike bootsplash, fbsplash has no in-kernel image decoder. Picture > > decompression is handled by a userspace helper which provides raw image > > data to the kernel. There is also no support for things like the silent > > mode and progress bars, as these are best handled by userspace programs. > > > > If splash support is really, really, really wanted in the kernel, it's > probably better > to just add minimal Overlay support for the framebuffer. If overlay is > added, it > won't be necessary to modify fbcon and the drivers, just core fb. > > We can have 3 levels of support. In it's most basic form, we have the display > layer (what get's shown in your monitor) plus 2 buffers in system ram, the > primary layer (where the console output is written) and the overlay, the > static image in raw framebuffer format. Then we replace the basic > framebuffer operations (imageblit, fillrect and copyarea) with ones that > will read the contents of both buffers, do basic raster ops (colorkey, alpha > blend, etc) before writing to the actual display buffer. > > The next level is both buffers are in video ram. This will need basic driver > support, at least to subdivide the framebuffer memory to display, primary, > and overlay. We can use the drivers accelerated drawing functions to > write to the primary layer, then use software to write the processed > contents to the display layer. > > Finally, we can enable full hardware video overlay. Another idea would be to build a console is user space. Think of it as a full screen xterm. A user space console has access to full hardware acceleration using the DRM interface. -- 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] VGA arbitration: draft of kernel side
On Wed, 09 Mar 2005 16:37:13 +1100, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > On Tue, 2005-03-08 at 23:35 -0500, Jon Smirl wrote: > > This is from /linux-2.5/Documentation/filesystems/sysfs-pci.txt. It > > describes how ia64 is achieving legacy IO. The VGA control code > > probably needs to be coordinated with this. > > This is a different thing, and I will implement it on ppc one of these > days. This is for issuing the IO cycles on the bus. It has nothing > to do with the actual arbitration work. Each one of these legacy spaces corresponds to an allowable simultaneous VGA use. There should be one arbiter per legacy space. -- 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: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, 2005-03-09 at 00:16 +0100, Dominik Brodowski wrote:
> > Dominik Brodowski <[EMAIL PROTECTED]> wrote:
> > >
> > > Most pcmcia devices are matched to drivers using "product ID strings"
> > > embedded in the devices' Card Information Structures, as "manufactor ID /
> > > card ID" matches are much less reliable. Unfortunately, these strings
> > > cannot
> > > be passed to userspace for easy userspace-based loading of appropriate
> > > modules (MODNAME -- hotplug), so my suggestion is to also store crc32
> > > hashes
> > > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> > >
> > > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
> >
> > What is the difficulty in passing these strings via /sbin/hotplug arguments?
>
> The difficulty is that extracting and evaluating them breaks the wonderful
> bus-independent MODNAME implementation for hotplug suggested by Roman Kagan
> ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these
> strings may contain spaces and other "strange" characters. The latter may be
> worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really
> clean because of this MODNAME implementation:
Same goes with Open Firmware match strings that we are about to pass
down to userspace as well. Hotplug will have to learn to deal with
those.
> #!/bin/sh
>
> cd /etc/hotplug
> . ./hotplug.functions
>
> if [ "$ACTION" = "" ]; then
> mesg Bad PCMCIA agent invocation, no action
> exit 1
> fi
>
> case $ACTION in
>
> add)
> modprobe $MODNAME
>
> ... work around some exotic buggy PCMCIA hardware ...
> ...
>
> and I would very much like to avoid breaking the line "modprobe $MODNAME".
>
> On Tue, Mar 08, 2005 at 02:54:57PM -0800, Linus Torvalds wrote:
> >
> >
> > On Tue, 8 Mar 2005, Dominik Brodowski wrote:
> > >
> > >Unfortunately, these strings cannot
> > > be passed to userspace for easy userspace-based loading of appropriate
> > > modules (MODNAME -- hotplug), so my suggestion is to also store crc32
> > > hashes
> > > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> > >
> > > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
> >
> > Hmm.. I'm with Andrew on this one - I'd much rather really pass them to
> > user space as strings. We already pass a number of strings as environment
> > variables.
> >
> > In fact, what's wrong with DEVPATH? Which we already expose as the
> > NAME=xxx environment variable. So if the kboject associated with a device
> > has has this string associated with its name (which it should)
> drivers/base/core.c::device_add()
> kobject_set_name(>kobj, "%s", dev->bus_id);
> and the bus_id isn't the device's name for common buses.
>
> Nontheless, the strings _are_ exported at DEVPATH/prod_id[1-4], but for the
> reasons mentioned above I'd prefer not to use them.
>
>
> On Tue, Mar 08, 2005 at 12:34:26PM -0800, Andrew Morton wrote:
> > > ...
> > > To make the life easier for device driver authors,
> > > - a big warning is put into dmesg if a pcmcia driver is inserted
> > > into the kernel and the hash mentioned in PCMCIA_DEVICE_PROD_ID()
> > > is incorrect,
> >
> > As long as the kernel shouts loudly at the driver developer at
> > development-time, and that shouting mentions a bit of documentation in
> > Documentation/somewhere, I expect we'll be OK.
>
> Andrew, please apply this patch on top of 2.6.11-mm2, if you and Linus still
> agree:
>
>
> Add some information useful for PCMCIA device driver authors to
> Documentation/pcmcia/, and reference it in dmesg in case of hash mismatches.
>
> Also add a reference to pcmciautils to Documentation/Changes. With recent
> changes, you don't need to concern yourself with pcmcia-cs even if you have
> PCMCIA hardware, so the example above the list needed to be adapted as well.
>
> Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
> Index: 2.6.11+/Documentation/Changes
> ===
> --- 2.6.11+.orig/Documentation/Changes2005-03-08 23:23:30.0
> +0100
> +++ 2.6.11+/Documentation/Changes 2005-03-08 23:23:33.0 +0100
> @@ -44,9 +44,9 @@
>
> Again, keep in mind that this list assumes you are already
> functionally running a Linux 2.4 kernel. Also, not all tools are
> -necessary on all systems; obviously, if you don't have any PCMCIA (PC
> -Card) hardware, for example, you probably needn't concern yourself
> -with pcmcia-cs.
> +necessary on all systems; obviously, if you don't have any ISDN
> +hardware, for example, you probably needn't concern yourself with
> +isdn4k-utils.
>
> o Gnu C 2.95.3 # gcc --version
> o Gnu make 3.79.1 # make --version
> @@ -57,6 +57,7 @@
> o jfsutils 1.1.3 # fsck.jfs -V
> o reiserfsprogs 3.6.3 # reiserfsck -V
Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
Matt Mackall wrote: How big is the userspace client? Hmm.. x86 executable? source? Anyway, there's about 12,000 lines of user space code, and growing. In the kernel we have approx. 3,300 lines. - 450MB/sec Read on a single connection (2-way 2.4Ghz Opteron, 64KB block size); With what network hardware and drives, please? Neterion's 10GbE adapters. RAM disk on the target side. Alex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops tracing and /proc
On Wed, Mar 09, 2005 at 12:36:27AM -0500, Lee Revell wrote: > I am trying to decode an Oops per the instructions in > Documentation/oops-tracing.txt. The instructions say to run it through > ksymoops with the "-k /proc/ksyms" argument. > > But, I do not have this file! The closest thing I have > is /proc/kallsyms. ksymoops complains that it does not understand the > syntax of this file. > > What am I doing wrong? If you have CONFIG_KALLSYMS enabled, you don't need ksymoops as the backtrace gets decoded to symbol names for you. The only use for ksymoops in a 2.6 kernel is probably the disassembly of the Code: line. http://www.kernel.org/pub/linux/utils/kernel/ksymoops/ Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VGA arbitration: draft of kernel side
On Tue, 2005-03-08 at 23:35 -0500, Jon Smirl wrote: > This is from /linux-2.5/Documentation/filesystems/sysfs-pci.txt. It > describes how ia64 is achieving legacy IO. The VGA control code > probably needs to be coordinated with this. This is a different thing, and I will implement it on ppc one of these days. This is for issuing the IO cycles on the bus. It has nothing to do with the actual arbitration work. > -- > > Accessing legacy resources through sysfs > > Legacy I/O port and ISA memory resources are also provided in sysfs if the > underlying platform supports them. They're located in the PCI class > heirarchy, > e.g. > > /sys/class/pci_bus/:17/ > |-- bridge -> ../../../devices/pci:17 > |-- cpuaffinity > |-- legacy_io > `-- legacy_mem > > The legacy_io file is a read/write file that can be used by applications to > do legacy port I/O. The application should open the file, seek to the desired > port (e.g. 0x3e8) and do a read or a write of 1, 2 or 4 bytes. The legacy_mem > file should be mmapped with an offset corresponding to the memory offset > desired, e.g. 0xa for the VGA frame buffer. The application can then > simply dereference the returned pointer (after checking for errors of course) > to access legacy memory space. > > Supporting PCI access on new platforms > > In order to support PCI resource mapping as described above, Linux platform > code must define HAVE_PCI_MMAP and provide a pci_mmap_page_range function. > Platforms are free to only support subsets of the mmap functionality, but > useful return codes should be provided. > > Legacy resources are protected by the HAVE_PCI_LEGACY define. Platforms > wishing to support legacy functionality should define it and provide > pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions. > > -- Benjamin Herrenschmidt <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops tracing and /proc
I am trying to decode an Oops per the instructions in Documentation/oops-tracing.txt. The instructions say to run it through ksymoops with the "-k /proc/ksyms" argument. But, I do not have this file! The closest thing I have is /proc/kallsyms. ksymoops complains that it does not understand the syntax of this file. What am I doing wrong? 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/
Boot sequence of /proc filesystem
Hi, I am writing some piece of code in the linux kernel 2.6.8 , in the files linux-2.6.8/kernel/fork.c ( in function do_fork() ) and linux-2.6.8/kernel/exit.c ( in the function do_exit() ). My objective is to execute the code immediately after the kernel has mounted the /proc filesystem. This is because i am creating new subdirectories in the /proc fs. What is the checking condition i should place inside the kernel so that i can verify that the /proc fs has been mounted during booting and now my code can be executed by the kernel. Is there any global variable that gets turned on when the /proc fs is mounted during booting. Also my code should continue executing until the /proc fs has been unmounted during shutdown process. It would really help me if you can suggest a wayout. Thanks in advance. Sounak Yahoo! India Matrimony: Find your partner online. http://yahoo.shaadi.com/india-matrimony/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
On Sun, Mar 06, 2005 at 11:03:14PM -0800, Alex Aizman wrote: > As far as user/kernel, the existing iSCSI initiators bloat the kernel with > ever-growing control plane code, including but not limited to: iSCSI > discovery, Login (Authentication and Operational), session and connection > management, connection-level error processing, iSCSI Text, Nop-Out/In, Async > Message, iSNS, SLP, Radius... Open-iSCSI puts the entire control plane in > the user space. This control plane talks to the data plane via well defined > interface over the netlink transport. How big is the userspace client? How does this perform under memory pressure? If the userspace iSCSI client is paged out for whatever reason, and flushing _to_ an iSCSI device is necessary to page the usersace portion back in, and the connection needs restarting or the like to flush... > Performance. > This is the major goal and motivation for this project. As it happens, iSCSI > has to compete with Fibre Channel, which is a more entrenched technology in > the storage space. In addition, the "soft" iSCSI implementation have to show > good results in presence of specialized hardware offloads. > > Our today's performance numbers are: > > - 450MB/sec Read on a single connection (2-way 2.4Ghz Opteron, 64KB block > size); With what network hardware and drives, please? -- 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/
IA32 (2.6.11 - 2005-03-08.16.00) - 1 New warnings
drivers/w1/w1.c:525: warning: assignment makes pointer from integer without a cast - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [announce 0/7] fbsplash - The Framebuffer Splash
On Tuesday 08 March 2005 09:57, Michal Januszewski wrote: > Fbsplash - The Framebuffer Splash - is a feature that allows displaying > images in the background of consoles that use fbcon. The project is > partially descended from bootsplash. > > Unlike bootsplash, fbsplash has no in-kernel image decoder. Picture > decompression is handled by a userspace helper which provides raw image > data to the kernel. There is also no support for things like the silent > mode and progress bars, as these are best handled by userspace programs. > If splash support is really, really, really wanted in the kernel, it's probably better to just add minimal Overlay support for the framebuffer. If overlay is added, it won't be necessary to modify fbcon and the drivers, just core fb. We can have 3 levels of support. In it's most basic form, we have the display layer (what get's shown in your monitor) plus 2 buffers in system ram, the primary layer (where the console output is written) and the overlay, the static image in raw framebuffer format. Then we replace the basic framebuffer operations (imageblit, fillrect and copyarea) with ones that will read the contents of both buffers, do basic raster ops (colorkey, alpha blend, etc) before writing to the actual display buffer. The next level is both buffers are in video ram. This will need basic driver support, at least to subdivide the framebuffer memory to display, primary, and overlay. We can use the drivers accelerated drawing functions to write to the primary layer, then use software to write the processed contents to the display layer. Finally, we can enable full hardware video overlay. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VGA arbitration: draft of kernel side
This is from /linux-2.5/Documentation/filesystems/sysfs-pci.txt. It describes how ia64 is achieving legacy IO. The VGA control code probably needs to be coordinated with this. -- Accessing legacy resources through sysfs Legacy I/O port and ISA memory resources are also provided in sysfs if the underlying platform supports them. They're located in the PCI class heirarchy, e.g. /sys/class/pci_bus/:17/ |-- bridge -> ../../../devices/pci:17 |-- cpuaffinity |-- legacy_io `-- legacy_mem The legacy_io file is a read/write file that can be used by applications to do legacy port I/O. The application should open the file, seek to the desired port (e.g. 0x3e8) and do a read or a write of 1, 2 or 4 bytes. The legacy_mem file should be mmapped with an offset corresponding to the memory offset desired, e.g. 0xa for the VGA frame buffer. The application can then simply dereference the returned pointer (after checking for errors of course) to access legacy memory space. Supporting PCI access on new platforms In order to support PCI resource mapping as described above, Linux platform code must define HAVE_PCI_MMAP and provide a pci_mmap_page_range function. Platforms are free to only support subsets of the mmap functionality, but useful return codes should be provided. Legacy resources are protected by the HAVE_PCI_LEGACY define. Platforms wishing to support legacy functionality should define it and provide pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions. -- 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/
2.6.11-mm2 vs audio for kino and tvtime
Greetings Andrew; 2.6.11-mm2 seems to work, mostly. First, the ieee1394 stuff seems to have fixed up that driver, and kino can access my movie cameras video over the firewire very nicely without applying the bk-ieee1394-patch. The camera has builtin stereo mics in it, but nary a peep can be heard from it thru the firewire. Am I supposed to be able to hear that? Second, I have a pdHDTV-3000 card, and up till now I've been overwriting the bttv stuffs with the drivers in pcHDTV-1.6.tar.gz by doing a make clean;make;make install. But now thats broken, and the error message doesn't seem to make sense to this old K C guy. The error exit: make[1]: Entering directory `/usr/src/linux-2.6.11-mm2' CC [M] /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362: error: unknown field `id' specified in initializer /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362: warning: missing braces around initializer /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362: warning: (near initialization for `bttv_i2c_client_template.released') make[2]: *** [/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o] Error 1 make[1]: *** [_module_/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.11-mm2' make: *** [modules] Error 2 The braces are indeed there. Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've lost my sensors except for one on the motherboard called THRM by gkrellm-2.28. Nothing seems to be able to bring the w83627hf back to life. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][Documentation update]Re: diff command line?
On Sat, 2005-03-05 at 11:45, Jim Nelson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Russell King wrote: > | On Sat, Mar 05, 2005 at 10:48:00AM -0500, Gene Heskett wrote: > | > |>What are the options normally used to generate a diff for public > |>consumption on this list? > | > | > | diff -urpN orig new > | > | where "orig" and "new" both contain the top level "linux" directory, > | so the resulting patch can be applied with patch -p1. > | > > You'd also want to add "-x dontdiff", using > > http://developer.osdl.org/rddunlap/scripts/dontdiff-osdl > > That way, you can do a diff, even if you have run a compile in one of the > directory trees. Hey, why isn't that is the documentation? I didn't hear of it until now. Is this what most developers are using for 2.6, if so then we need the following trivial documentation update. Created against the Docs in 2.6.11 --- SubmittingPatches.orig 2005-03-08 23:09:19.496223848 -0500 +++ SubmittingPatches 2005-03-08 23:18:52.192160832 -0500 @@ -60,6 +60,9 @@ the build process, and should be ignored in any diff(1)-generated patch. dontdiff is maintained by Tigran Aivazian <[EMAIL PROTECTED]> +For 2.6 kernels you can fetch dontdiff-osdl maintained by Randy Dunlap. +wget http://developer.osdl.org/rddunlap/scripts/dontdiff-osdl + - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.10 - direct-io async short read bug
On Tue, Mar 08, 2005 at 03:54:04PM -0800, Badari Pulavarty wrote: > > 1. return EINVAL if the DIO goes past EOF. > > > > 2. truncate the request to file size (which is what your patch does) > > and if it works, it works. > > > > 3. truncate the request to a size that actually works - like a multiple > > of 512. > > > > 4. Do the full i/o since the user buffer is big enough, truncate the > > result returned to file size (and clear out the user buffer where it > > read past EOF). > > > > Number 4 would make it easy on the user-level code, but AIO DIO might be > > a bit tricky and might be a security hole since the data would be dma'ed > > there and then cleared. I need to look at the code some more. Solaris, which does forcedirectio as a mount option, actually will do buffered I/O on the trailing part. Consider it like a bounce buffer. That way they don't DMA the trailing data and succeed the I/O. The I/O returns actual bytes till EOF, just like read(2) is supposed to. Either this or a fully DMA'd number 4 is really what we should do. If security can only be solved via a bounce buffer, who cares? If the user created themselves a non-aligned file to open O_DIRECT, that's their problem if the last part-sector is negligably slower. Joel -- Life's Little Instruction Book #3 "Watch a sunrise at least once a year." Joel Becker Senior Member of Technical Staff Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [request for inclusion] Realtime LSM
Matt Mackall <[EMAIL PROTECTED]> writes: > On Tue, Mar 08, 2005 at 09:39:24PM -0600, Jack O'Quin wrote: >> >> 4. is undocumented and has never been tested in any real music studios >> > >> > Well you'll have a bit to test it before it goes to Linus. >> >> Only toy tests will be possible without the required userspace tools. > > Chris posted the requisite change to pam_limits as well. Sure. You and Chris and I can find a way to test it. Those are "toy tests". The RT-LSM has been used for over a year by hundreds (probably thousands) of musicians in studios making real music. That's what I mean by "real music studios". We won't be able to do that kind of testing for the rlimits solution until next year. -- joq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PPC64 NUMA memory fixup
This patch is from Mike Kravetz <[EMAIL PROTECTED]>.
When I booted my new 720 on a kernel configured for NUMA, I received
the following during bootup:
WARNING: Unexpected node layout: region start 4400 length 200
NUMA is disabled
This is due to memory 'holes' within nodes. If such holes are
encountered, then NUMA is disabled. The following patch adds support
for such configurations. My 720 now boots with the following message:
[boot]0012 Setup Arch
Node 0 Memory: 0x0-0x800 0x4400-0x12a00
Node 1 Memory: 0x800-0x4400 0x12a00-0x1ea00
Signed-off-by: Mike Kravetz <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -Naupr linux-2.6.11-rc3/arch/ppc64/mm/numa.c
linux-2.6.11-rc3.work/arch/ppc64/mm/numa.c
--- linux-2.6.11-rc3/arch/ppc64/mm/numa.c 2005-02-03 01:57:16.0
+
+++ linux-2.6.11-rc3.work/arch/ppc64/mm/numa.c 2005-03-01 19:39:21.0
+
@@ -40,7 +40,6 @@ int nr_cpus_in_node[MAX_NUMNODES] = { [0
struct pglist_data *node_data[MAX_NUMNODES];
bootmem_data_t __initdata plat_node_bdata[MAX_NUMNODES];
-static unsigned long node0_io_hole_size;
static int min_common_depth;
/*
@@ -49,7 +48,8 @@ static int min_common_depth;
*/
static struct {
unsigned long node_start_pfn;
- unsigned long node_spanned_pages;
+ unsigned long node_end_pfn;
+ unsigned long node_present_pages;
} init_node_data[MAX_NUMNODES] __initdata;
EXPORT_SYMBOL(node_data);
@@ -348,33 +348,28 @@ new_range:
if (max_domain < numa_domain)
max_domain = numa_domain;
- /*
-* For backwards compatibility, OF splits the first node
-* into two regions (the first being 0-4GB). Check for
-* this simple case and complain if there is a gap in
-* memory
+ /*
+* Initialize new node struct, or add to an existing one.
*/
- if (init_node_data[numa_domain].node_spanned_pages) {
- unsigned long shouldstart =
- init_node_data[numa_domain].node_start_pfn +
- init_node_data[numa_domain].node_spanned_pages;
- if (shouldstart != (start / PAGE_SIZE)) {
- /* Revert to non-numa for now */
- printk(KERN_ERR
- "WARNING: Unexpected node layout: "
- "region start %lx length %lx\n",
- start, size);
- printk(KERN_ERR "NUMA is disabled\n");
- goto err;
- }
- init_node_data[numa_domain].node_spanned_pages +=
+ if (init_node_data[numa_domain].node_end_pfn) {
+ if ((start / PAGE_SIZE) <
+ init_node_data[numa_domain].node_start_pfn)
+ init_node_data[numa_domain].node_start_pfn =
+ start / PAGE_SIZE;
+ else
+ init_node_data[numa_domain].node_end_pfn =
+ (start / PAGE_SIZE) +
+ (size / PAGE_SIZE);
+
+ init_node_data[numa_domain].node_present_pages +=
size / PAGE_SIZE;
} else {
node_set_online(numa_domain);
init_node_data[numa_domain].node_start_pfn =
start / PAGE_SIZE;
- init_node_data[numa_domain].node_spanned_pages =
+ init_node_data[numa_domain].node_end_pfn =
+ init_node_data[numa_domain].node_start_pfn +
size / PAGE_SIZE;
}
@@ -391,14 +386,6 @@ new_range:
node_set_online(i);
return 0;
-err:
- /* Something has gone wrong; revert any setup we've done */
- for_each_node(i) {
- node_set_offline(i);
- init_node_data[i].node_start_pfn = 0;
- init_node_data[i].node_spanned_pages = 0;
- }
- return -1;
}
static void __init setup_nonnuma(void)
@@ -426,12 +413,11 @@ static void __init setup_nonnuma(void)
node_set_online(0);
init_node_data[0].node_start_pfn = 0;
- init_node_data[0].node_spanned_pages = lmb_end_of_DRAM() / PAGE_SIZE;
+ init_node_data[0].node_end_pfn = lmb_end_of_DRAM() / PAGE_SIZE;
+ init_node_data[0].node_present_pages = total_ram / PAGE_SIZE;
for (i = 0 ; i < top_of_ram; i += MEMORY_INCREMENT)
numa_memory_lookup_table[i >> MEMORY_INCREMENT_SHIFT] = 0;
-
- node0_io_hole_size = top_of_ram - total_ram;
}
static
Re: [PATCH] VGA arbitration: draft of kernel side
On Tue, 2005-03-08 at 22:17 -0500, Jon Smirl wrote:
> How do I do the 'disable all, post, renable last active' sequence in
> this scheme?
You don't do it that way. You vga_get(IO|MEM) the card you want to
POST, do the POST, then vga_put().
Subsequent user will get back ownership when it does vga_get(something)
again.
BTW. I have a draft of the userland API. It will be a /dev entry (so
other OSes can implement the same API, also, it's just doing too much
for sysfs, I debated it with a few kernel folks and we decided it should
be that way) :
* open: open user instance of the arbitrer. by default, it's
*attached to the default VGA device of the system.
*
* close : close user instance, release locks
*
* read: return a string indicating the status of the target.
*an IO state string is of the form {mem,io,mem+io,none},
*mc and ic are respectively mem and io lock counts (for
*debugging/diagnostic only). "decodes" indicate what the
*card currently decodes, "owns" indicates what is currently
*enabled on it, and "locks" indicates what is locked by this
*card.
*
* ":decodes=,owns=,locks= (mc,ic)"
*
* write: write a command to the arbiter. List of commands is:
*
* target: switch target to card (see below)
* lock : acquires locks on target ("none" is invalid io_state)
* trylock : non-blocking acquire locks on target
* unlock : release locks on target
* decodes : set the legacy decoding attributes for the card
*
* poll : event if something change on any card (not just the target)
I also added nesting counters (mostly to make things safer, though it could
be useful for scenarios where IRQ stuffs are doing a tryget kind of thing
as described in a previous message).
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [request for inclusion] Realtime LSM
On Tue, Mar 08, 2005 at 09:39:24PM -0600, Jack O'Quin wrote: > >> 4. is undocumented and has never been tested in any real music studios > > > > Well you'll have a bit to test it before it goes to Linus. > > Only toy tests will be possible without the required userspace tools. Chris posted the requisite change to pam_limits as well. -- 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/
Please help me update my address book on Ringo
Hi I'm updating my address book. Please click on the link below and enter your contact info for me: http://ringo.com/i?uid=k1WylYvS5KZyLvy5; I'm using a new, free service where I put in my contact info for you, you put in your contact info for me, and everyone stays up to date automatically. It's surprisingly easy and useful. Thanks for your help. Gaurav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Please help me update my address book on Ringo
Hi I'm updating my address book. Please click on the link below and enter your contact info for me: http://ringo.com/i?uid=k1WylYvS5KZyLvy5; I'm using a new, free service where I put in my contact info for you, you put in your contact info for me, and everyone stays up to date automatically. It's surprisingly easy and useful. Thanks for your help. Gaurav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix suspend/resume problems with b44
On Tue, 8 Mar 2005 22:55:37 +0100 Pavel Machek <[EMAIL PROTECTED]> wrote: > Any idea what to do there? I'd say that request_irq is very unlikely > to fail given that it worked okay before suspend... What you have is fine for now. It is just a general issue that ->resume() has no way to cleanly fail. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [request for inclusion] Realtime LSM
>> Andrew Morton <[EMAIL PROTECTED]> writes: >> > Does anyone have serious objections to this approach? > On Mon, Mar 07, 2005 at 11:30:57PM -0600, Jack O'Quin wrote: >> 1. is likely to introduce multiuser system security holes like the one >> created recently when the mlock() rlimits bug was fixed (DoS attacks) Matt Mackall <[EMAIL PROTECTED]> writes: > I wouldn't say "likely". But anything's possible, so I wouldn't rule > it out entirely. I wasn't predicting a bug in your code, just pointing to a known PAM problem. The lack of good documentation and overly obscure PAM interfaces cause some (most?) distributions to ship with broken PAM configurations. Debian includes pam_limits.so in seven different /etc/pam.d files, yet their /etc/security/limits.conf is empty. When the recent mlock() rlimits bug fix was merged, it had the unintended effect of suddenly granting almost every user unlimited mlock() privileges. I suspect something similar will happen for this new rlimit. Mounting a DoS attack becomes child's play for anyone. This is OK for me, but a disaster for shared system admins. That is why these kinds of API changes should be avoided in a stable release. The big advantage of the LSM approach is that we can be confident it will have no effect on systems that do not load it. Further, the sysadmin can easily check that it's not present. None of that is true for this rlimits API change. >> 2. requires updates to all the shells > > Requires update to the PAM distro for our purposes. That, too. >> 3. forces Windows and Mac musicians to learn and understand PAM > > Or for the distro (ubuntu or whatever) to catch up. The alternative is > for the user to compile their own kernel module and mess with its > arcane interface. No, this LSM is already included in several distributions. >> 4. is undocumented and has never been tested in any real music studios > > Well you'll have a bit to test it before it goes to Linus. Only toy tests will be possible without the required userspace tools. -- 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/
[2.6 patch] sound/isa/: possible cleanups
This patch contains the following possible cleanups:
- make needlesly global code static
- remove the following unused global functions:
- gus/gus_volume.c: snd_gf1_gvol_to_lvol_raw
- gus/gus_volume.c: snd_gf1_calc_ramp_rate
- gus/gus_volume.c: snd_gf1_compute_vibrato
- gus/gus_volume.c: snd_gf1_compute_pitchbend
- gus/gus_volume.c: snd_gf1_compute_freq
- gus/gus_io.c: snd_gf1_i_adlib_write
- gus/gus_io.c: snd_gf1_i_write_addr
- gus/gus_io.c: snd_gf1_pokew
- gus/gus_io.c: snd_gf1_peekw
- gus/gus_io.c: snd_gf1_dram_setmem
- gus/gus_io.c: snd_gf1_print_global_registers
- gus/gus_io.c: snd_gf1_print_setup_registers
- gus/gus_io.c: snd_gf1_peek_print_block
- gus/gus_io.c: snd_gf1_print_setup_registers
- gus/gus_io.c: snd_gf1_peek_print_block
- remove the following unused global variable:
- gus/gus_tables.h: snd_gf1_scale_table
- remove the following unneeded EXPORT_SYMBOL's:
- gus/gus_main.c: snd_gf1_i_write16
- gus/gus_main.c: snd_gf1_start
- gus/gus_main.c: snd_gf1_stop
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
sound/isa/gus/gus_mem.c| 12 +-
sound/isa/gus/gus_reset.c |3
sound/isa/gus/gus_synth.c |3
sound/isa/gus/gus_tables.h | 27
sound/isa/gus/gus_volume.c | 141
sound/isa/wavefront/wavefront_fx.c | 39 +++---
include/sound/gus.h| 23
sound/isa/gus/gus_io.c | 164 -
sound/isa/gus/gus_main.c |3
9 files changed, 34 insertions(+), 381 deletions(-)
--- linux-2.6.11-mm1-full/sound/isa/gus/gus_mem.c.old 2005-03-06
23:43:49.0 +0100
+++ linux-2.6.11-mm1-full/sound/isa/gus/gus_mem.c 2005-03-06
23:44:50.0 +0100
@@ -39,8 +39,8 @@
}
}
-snd_gf1_mem_block_t *snd_gf1_mem_xalloc(snd_gf1_mem_t * alloc,
- snd_gf1_mem_block_t * block)
+static snd_gf1_mem_block_t *snd_gf1_mem_xalloc(snd_gf1_mem_t * alloc,
+ snd_gf1_mem_block_t * block)
{
snd_gf1_mem_block_t *pblock, *nblock;
@@ -105,8 +105,8 @@
return 0;
}
-snd_gf1_mem_block_t *snd_gf1_mem_look(snd_gf1_mem_t * alloc,
- unsigned int address)
+static snd_gf1_mem_block_t *snd_gf1_mem_look(snd_gf1_mem_t * alloc,
+unsigned int address)
{
snd_gf1_mem_block_t *block;
@@ -118,8 +118,8 @@
return NULL;
}
-snd_gf1_mem_block_t *snd_gf1_mem_share(snd_gf1_mem_t * alloc,
- unsigned int *share_id)
+static snd_gf1_mem_block_t *snd_gf1_mem_share(snd_gf1_mem_t * alloc,
+ unsigned int *share_id)
{
snd_gf1_mem_block_t *block;
--- linux-2.6.11-mm1-full/sound/isa/gus/gus_reset.c.old 2005-03-06
23:45:07.0 +0100
+++ linux-2.6.11-mm1-full/sound/isa/gus/gus_reset.c 2005-03-06
23:45:20.0 +0100
@@ -161,7 +161,8 @@
#endif
}
-void snd_gf1_clear_voices(snd_gus_card_t * gus, unsigned short v_min, unsigned
short v_max)
+static void snd_gf1_clear_voices(snd_gus_card_t * gus, unsigned short v_min,
+unsigned short v_max)
{
unsigned long flags;
unsigned int daddr;
--- linux-2.6.11-mm1-full/sound/isa/gus/gus_synth.c.old 2005-03-06
23:47:13.0 +0100
+++ linux-2.6.11-mm1-full/sound/isa/gus/gus_synth.c 2005-03-06
23:47:29.0 +0100
@@ -99,7 +99,8 @@
snd_seq_instr_list_free_cond(p->gus->gf1.ilist, , client, 0);
}
-int snd_gus_synth_event_input(snd_seq_event_t *ev, int direct, void
*private_data, int atomic, int hop)
+static int snd_gus_synth_event_input(snd_seq_event_t *ev, int direct,
+void *private_data, int atomic, int hop)
{
snd_gus_port_t * p = (snd_gus_port_t *) private_data;
--- linux-2.6.11-mm1-full/sound/isa/gus/gus_volume.c.old2005-03-06
23:47:56.0 +0100
+++ linux-2.6.11-mm1-full/sound/isa/gus/gus_volume.c2005-03-06
23:49:10.0 +0100
@@ -55,59 +55,6 @@
return (e << 8) | m;
}
-unsigned int snd_gf1_gvol_to_lvol_raw(unsigned short gf1_vol)
-{
- unsigned int rvol;
- unsigned short e, m;
-
- if (!gf1_vol)
- return 0;
- e = gf1_vol >> 8;
- m = (unsigned char) gf1_vol;
- rvol = 1 << e;
- if (e > 8)
- return rvol | (m << (e - 8));
- return rvol | (m >> (8 - e));
-}
-
-unsigned int snd_gf1_calc_ramp_rate(snd_gus_card_t * gus,
- unsigned short start,
- unsigned short end,
- unsigned int us)
-{
- static unsigned char vol_rates[19] =
- {
- 23, 24, 26, 28, 29, 31, 32, 34,
- 36, 37, 39, 40, 42, 44, 45, 47,
- 49, 50, 52
- };
-
[2.6 patch] sound/pci/: make code static
This patch makes needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
sound/pci/ac97/ac97_codec.c|9 ++---
sound/pci/ac97/ac97_local.h|3 ---
sound/pci/ca0106/ca0106_proc.c |2 +-
sound/pci/hda/hda_codec.c |6 --
sound/pci/hda/patch_realtek.c |2 +-
5 files changed, 12 insertions(+), 10 deletions(-)
--- linux-2.6.11-mm2-full/sound/pci/ac97/ac97_local.h.old 2005-03-09
03:11:25.0 +0100
+++ linux-2.6.11-mm2-full/sound/pci/ac97/ac97_local.h 2005-03-09
03:12:41.0 +0100
@@ -43,9 +43,6 @@
int snd_ac97_get_volsw(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t *
ucontrol);
int snd_ac97_put_volsw(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t *
ucontrol);
int snd_ac97_try_bit(ac97_t * ac97, int reg, int bit);
-int snd_ac97_remove_ctl(ac97_t *ac97, const char *name, const char *suffix);
-int snd_ac97_rename_ctl(ac97_t *ac97, const char *src, const char *dst, const
char *suffix);
-int snd_ac97_swap_ctl(ac97_t *ac97, const char *s1, const char *s2, const char
*suffix);
void snd_ac97_rename_vol_ctl(ac97_t *ac97, const char *src, const char *dst);
void snd_ac97_restore_status(ac97_t *ac97);
void snd_ac97_restore_iec958(ac97_t *ac97);
--- linux-2.6.11-mm2-full/sound/pci/ac97/ac97_codec.c.old 2005-03-09
03:11:47.0 +0100
+++ linux-2.6.11-mm2-full/sound/pci/ac97/ac97_codec.c 2005-03-09
03:12:55.0 +0100
@@ -2280,7 +2280,8 @@
}
/* remove the control with the given name and optional suffix */
-int snd_ac97_remove_ctl(ac97_t *ac97, const char *name, const char *suffix)
+static int snd_ac97_remove_ctl(ac97_t *ac97, const char *name,
+ const char *suffix)
{
snd_ctl_elem_id_t id;
memset(, 0, sizeof(id));
@@ -2299,7 +2300,8 @@
}
/* rename the control with the given name and optional suffix */
-int snd_ac97_rename_ctl(ac97_t *ac97, const char *src, const char *dst, const
char *suffix)
+static int snd_ac97_rename_ctl(ac97_t *ac97, const char *src,
+ const char *dst, const char *suffix)
{
snd_kcontrol_t *kctl = ctl_find(ac97, src, suffix);
if (kctl) {
@@ -2317,7 +2319,8 @@
}
/* swap controls */
-int snd_ac97_swap_ctl(ac97_t *ac97, const char *s1, const char *s2, const char
*suffix)
+static int snd_ac97_swap_ctl(ac97_t *ac97, const char *s1,
+const char *s2, const char *suffix)
{
snd_kcontrol_t *kctl1, *kctl2;
kctl1 = ctl_find(ac97, s1, suffix);
--- linux-2.6.11-mm2-full/sound/pci/ca0106/ca0106_proc.c.old2005-03-09
03:13:05.0 +0100
+++ linux-2.6.11-mm2-full/sound/pci/ca0106/ca0106_proc.c2005-03-09
03:13:15.0 +0100
@@ -95,7 +95,7 @@
};
-void snd_ca0106_proc_dump_iec958( snd_info_buffer_t *buffer, u32 value)
+static void snd_ca0106_proc_dump_iec958( snd_info_buffer_t *buffer, u32 value)
{
int i;
u32 status[4];
--- linux-2.6.11-mm2-full/sound/pci/hda/hda_codec.c.old 2005-03-09
03:19:28.0 +0100
+++ linux-2.6.11-mm2-full/sound/pci/hda/hda_codec.c 2005-03-09
03:21:48.0 +0100
@@ -655,7 +655,8 @@
/*
* read/write AMP value. The volume is between 0 to 0x7f, 0x80 = mute bit.
*/
-int snd_hda_codec_amp_read(struct hda_codec *codec, hda_nid_t nid, int ch, int
direction, int index)
+static int snd_hda_codec_amp_read(struct hda_codec *codec, hda_nid_t nid,
+ int ch, int direction, int index)
{
struct hda_amp_info *info = get_alloc_amp_hash(codec, HDA_HASH_KEY(nid,
direction, index));
if (! info)
@@ -664,7 +665,8 @@
return info->vol[ch];
}
-int snd_hda_codec_amp_write(struct hda_codec *codec, hda_nid_t nid, int ch,
int direction, int idx, int val)
+static int snd_hda_codec_amp_write(struct hda_codec *codec, hda_nid_t nid,
+ int ch, int direction, int idx, int val)
{
struct hda_amp_info *info = get_alloc_amp_hash(codec, HDA_HASH_KEY(nid,
direction, idx));
if (! info)
--- linux-2.6.11-mm2-full/sound/pci/hda/patch_realtek.c.old 2005-03-09
03:22:02.0 +0100
+++ linux-2.6.11-mm2-full/sound/pci/hda/patch_realtek.c 2005-03-09
03:22:26.0 +0100
@@ -1115,7 +1115,7 @@
{ 2, NULL },
};
-snd_kcontrol_new_t alc260_base_mixer[] = {
+static snd_kcontrol_new_t alc260_base_mixer[] = {
HDA_CODEC_VOLUME("PCM Playback Volume", 0x08, 0x0, HDA_OUTPUT),
HDA_CODEC_MUTE("PCM Playback Switch", 0x0f, 0x0, HDA_OUTPUT),
HDA_CODEC_VOLUME("CD Playback Volume", 0x07, 0x04, HDA_INPUT),
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] VGA arbitration: draft of kernel side
How do I do the 'disable all, post, renable last active' sequence in this scheme? -- 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/
Bug fix in slab.c:alloc_arraycache
Kmem_cache_alloc_node is not capable of handling a null cachep
pointer as its input argument.
If I try to increase a slab limit by echoing a very large number
into /proc/slabinfo, kernel will panic from alloc_arraycache()
because Kmem_find_general_cachep() can actually return a NULL
pointer if the size argument is sufficiently large.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
--- linux-2.6.11/mm/slab.c Mon Oct 18 14:55:43 2004
+++ linux-2.6.11.ken/mm/slab.c Tue Mar 1 19:14:07 2005
@@ -643,8 +645,10 @@
struct array_cache *nc = NULL;
if (cpu != -1) {
- nc = kmem_cache_alloc_node(kmem_find_general_cachep(memsize,
- GFP_KERNEL), cpu_to_node(cpu));
+ kmem_cache_t * cachep;
+ cachep = kmem_find_general_cachep(memsize, GFP_KERNEL);
+ if (cachep)
+ nc = kmem_cache_alloc_node(cachep, cpu_to_node(cpu));
}
if (!nc)
nc = kmalloc(memsize, GFP_KERNEL);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] No-exec support for ppc64
On Tue, 2005-03-08 at 17:13 -0600, Jake Moilanen wrote:
> diff -puN arch/ppc64/kernel/iSeries_setup.c~nx-kernel-ppc64
> arch/ppc64/kernel/iSeries_setup.c
> --- linux-2.6-bk/arch/ppc64/kernel/iSeries_setup.c~nx-kernel-ppc64
> 2005-03-08 16:08:57 -06:00
> +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/iSeries_setup.c 2005-03-08
> 16:08:57 -06:00
> @@ -624,6 +624,7 @@ static void __init iSeries_bolt_kernel(u
> {
> unsigned long pa;
> unsigned long mode_rw = _PAGE_ACCESSED | _PAGE_COHERENT | PP_RWXX;
> + unsigned long tmp_mode;
> HPTE hpte;
>
> for (pa = saddr; pa < eaddr ;pa += PAGE_SIZE) {
> @@ -632,6 +633,12 @@ static void __init iSeries_bolt_kernel(u
> unsigned long va = (vsid << 28) | (pa & 0xfff);
> unsigned long vpn = va >> PAGE_SHIFT;
> unsigned long slot = HvCallHpt_findValid(, vpn);
> +
> + tmp_mode = mode_rw;
> +
> + /* Make non-kernel text non-executable */
> + if (!is_kernel_text(ea))
> + tmp_mode = mode_rw | HW_NO_EXEC;
>
> if (hpte.dw0.dw0.v) {
> /* HPTE exists, so just bolt it */
tmp_mode doesn't seem to be ever used here ...
> /* Free memory returned from module_alloc */
> diff -puN arch/ppc64/mm/fault.c~nx-kernel-ppc64 arch/ppc64/mm/fault.c
> --- linux-2.6-bk/arch/ppc64/mm/fault.c~nx-kernel-ppc642005-03-08
> 16:08:57 -06:00
> +++ linux-2.6-bk-moilanen/arch/ppc64/mm/fault.c 2005-03-08 16:08:57
> -06:00
> @@ -76,6 +76,21 @@ static int store_updates_sp(struct pt_re
> return 0;
> }
>
> +pte_t *lookup_address(unsigned long address)
> +{
> + pgd_t *pgd = pgd_offset_k(address);
> + pmd_t *pmd;
> +
> + if (pgd_none(*pgd))
> + return NULL;
> +
> + pmd = pmd_offset(pgd, address);
> + if (pmd_none(*pmd))
> + return NULL;
> +
> +return pte_offset_kernel(pmd, address);
> +}
Use find_linux_pte() here (asm-ppc64/pgtable.h). It will return NULL of
the PTE is not present too, so no need to dbl check that. That way, I
won't have to fix your copy of the function when I get the proper 4L
headers patch in ;)
> /*
> * The error_code parameter is
> * - DSISR for a non-SLB data access fault,
> @@ -94,6 +109,7 @@ int do_page_fault(struct pt_regs *regs,
> unsigned long is_write = error_code & 0x0200;
> unsigned long trap = TRAP(regs);
> unsigned long is_exec = trap == 0x400;
> + pte_t *ptep;
>
> BUG_ON((trap == 0x380) || (trap == 0x480));
>
> @@ -253,6 +269,15 @@ bad_area_nosemaphore:
> info.si_addr = (void __user *) address;
> force_sig_info(SIGSEGV, , current);
> return 0;
> + }
> +
> + ptep = lookup_address(address);
> +
> + if (ptep && pte_present(*ptep) && !pte_exec(*ptep)) {
> + if (printk_ratelimit())
> + printk(KERN_CRIT "kernel tried to execute NX-protected
> page - exploit attempt? (uid: %d)\n", current->uid);
> + show_stack(current, (unsigned long *)__get_SP());
> + do_exit(SIGKILL);
> }
Can you try to limit to 80 columns ? (I know, I'm not the best for that
neither, but I'm trying to cure myself here, I promise my next rewrite
of radeonfb will be fully 80-columns safe :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Alsa-devel] Re: intel 8x0 went silent in 2.6.11
On Tue, 2005-03-08 at 20:53 -0500, Mark Canter wrote:
> I think I've gone through every possible value here from asound.state to
> each setting in KDE itself. Still, the only sound that works is the one
> coming from line-out, without the port replicator, no sound exists
> whatsoever. Both of the below controls are set to false in asound.state
> and cooresponding KDE settings in kmix.
>
> I think the concern becomes though, regardless of what kde was doing after
> the fact, this condition didn't exits in <= 2.6.10 when no other
> applications where changed around it.
If you revert both the attached patches, does it work?
They are against alsa CVS, so to back these patches out from your 2.6.11
tree do this:
cd linux-2.6.11/sound/pci/ac97
patch -p0 -R < ac97-2.patch
patch -p0 -R < ac97.patch
Lee
Index: ac97_patch.c
===
RCS file: /cvsroot/alsa/alsa-kernel/pci/ac97/ac97_patch.c,v
retrieving revision 1.69
retrieving revision 1.70
diff -u -r1.69 -r1.70
--- ac97_patch.c 17 Jan 2005 13:47:20 - 1.69
+++ ac97_patch.c 20 Jan 2005 11:43:19 - 1.70
@@ -1113,6 +1113,7 @@
switch (subid) {
case 0x103c0890: /* HP nc6000 */
case 0x103c006d: /* HP nx9105 */
+ case 0x17340088: /* FSC Scenic-W */
/* enable headphone jack sense */
snd_ac97_update_bits(ac97, AC97_AD_JACK_SPDIF, 1<<11, 1<<11);
break;
Index: ac97_patch.c
===
RCS file: /cvsroot/alsa/alsa-kernel/pci/ac97/ac97_patch.c,v
retrieving revision 1.68
retrieving revision 1.69
diff -u -r1.68 -r1.69
--- ac97_patch.c 11 Jan 2005 15:57:20 - 1.68
+++ ac97_patch.c 17 Jan 2005 13:47:20 - 1.69
@@ -1107,13 +1107,25 @@
#endif
};
+static void check_ad1981_hp_jack_sense(ac97_t *ac97)
+{
+ u32 subid = ((u32)ac97->subsystem_vendor << 16) | ac97->subsystem_device;
+ switch (subid) {
+ case 0x103c0890: /* HP nc6000 */
+ case 0x103c006d: /* HP nx9105 */
+ /* enable headphone jack sense */
+ snd_ac97_update_bits(ac97, AC97_AD_JACK_SPDIF, 1<<11, 1<<11);
+ break;
+ }
+}
+
int patch_ad1981a(ac97_t *ac97)
{
patch_ad1881(ac97);
ac97->build_ops = _ad1981a_build_ops;
snd_ac97_update_bits(ac97, AC97_AD_MISC, AC97_AD198X_MSPLT, AC97_AD198X_MSPLT);
ac97->flags |= AC97_STEREO_MUTES;
- snd_ac97_update_bits(ac97, AC97_AD_JACK_SPDIF, 1<<11, 1<<11); /* HP jack sense */
+ check_ad1981_hp_jack_sense(ac97);
return 0;
}
@@ -1144,7 +1156,7 @@
ac97->build_ops = _ad1981b_build_ops;
snd_ac97_update_bits(ac97, AC97_AD_MISC, AC97_AD198X_MSPLT, AC97_AD198X_MSPLT);
ac97->flags |= AC97_STEREO_MUTES;
- snd_ac97_update_bits(ac97, AC97_AD_JACK_SPDIF, 1<<11, 1<<11); /* HP jack sense */
+ check_ad1981_hp_jack_sense(ac97);
return 0;
}
RE: Direct io on block device has performance regression on 2.6.x kernel - fix sync I/O path
Christoph Hellwig wrote on Tuesday, March 08, 2005 6:20 PM > this is not the blockdevice, but the obsolete raw device driver. Please > benchmark and if nessecary fix the blockdevice O_DIRECT codepath insted > as the raw driver is slowly going away. >From performance perspective, can raw device be resurrected? (just asking) - Ken - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ patch 4/7] drivers/serial/jsm: new serial device driver
> > > > If you were to open up the port with an "stty -a" to get the current > > settings and signals, you would unintentionally raise RTS and DTR. > > Why not fix the driver to not change the current line settings if it is > not being opened for the first time? That seems like a much simpler way > to solve this, and probably the saner way, as you don't want any user to > be able to mess up your modem... > > thanks, > > greg k-h Oh, when the port is already open, the driver correctly would not muck with DTR/RTS. I am talking about when the port is currently not open. On first port open, DTR (and usually RTS) will always be raised. The serial device would see this DTR raise, and under some circumstances, react to it... We have customers that use *really* *really* old serial devices on our products, (we are talking 110 baud and even 50 baud (!!!)), where an unintentional raise of DTR/RTS will freak the device out. At any rate, that's the reason I exported the values to sysfs in the original "dgnc" (outside-the-kernel-sources) driver. Thanks, Scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Direct io on block device has performance regression on 2.6.x kernel - fix sync I/O path
> --- linux-2.6.9/drivers/char/raw.c2004-10-18 14:54:37.0 -0700 > +++ linux-2.6.9.ken/drivers/char/raw.c2005-03-08 17:22:07.0 > -0800 this is not the blockdevice, but the obsolete raw device driver. Please benchmark and if nessecary fix the blockdevice O_DIRECT codepath insted as the raw driver is slowly going away. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.10 - direct-io async short read bug
On Tue, 2005-03-08 at 11:18, Badari Pulavarty wrote: > > Andrew, please don't apply the original patch. We shouldn't even attempt > > to submit IO beyond the filesize. We should truncate the IO request to > > filesize. I will send a patch today to fix this. > > > > Well, spoke too soon. This is an ugly corner case :( But I have > a ugly hack to fix it :) > > Let me ask you a basic question: Do we support DIO reads on a file > which is not blocksize multiple in size ? (say 12K - 10 bytes) ? > > What about the ones which are not 4K but 512 byte multiple ? (say 7K) ? > > I need answer to those, to figure out how hard I should try to fix this. > > Anyway, here is ugly version of the patch - which will limit the IO > size to filesize and uses lower blocksizes to read the file (since > the filesize is only 3K, it would go down to 512 byte blocksize). > BTW, I got a compile error because the 'iov' parameter is declared with 'const', so your patch is changing a read-only value. :( Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Direct io on block device has performance regression on 2.6.x kernel - fix AIO path
This patch adds block device direct I/O for AIO path.
30% performance gain!!
AIO (io_submit)
2.6.9 206,917
2.6.9+patches 268,484
- Ken
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
--- linux-2.6.9/drivers/char/raw.c 2005-03-08 17:22:07.0 -0800
+++ linux-2.6.9.ken/drivers/char/raw.c 2005-03-08 17:25:38.0 -0800
@@ -385,21 +385,148 @@ static ssize_t raw_file_write(struct fil
return raw_file_rw(file, (char __user *) buf, count, ppos, WRITE);
}
-static ssize_t raw_file_aio_write(struct kiocb *iocb, const char __user *buf,
- size_t count, loff_t pos)
+int raw_end_aio(struct bio *bio, unsigned int bytes_done, int error)
{
- struct iovec local_iov = {
- .iov_base = (char __user *)buf,
- .iov_len = count
- };
+ struct kiocb* iocb = bio->bi_private;
+ atomic_t* bio_count = (atomic_t*) >private;
+
+ if ((bio->bi_rw & 0x1) == READ)
+ bio_check_pages_dirty(bio);
+ else {
+ int i;
+ struct bio_vec *bvec = bio->bi_io_vec;
+ struct page *page;
+ for (i = 0; i < bio->bi_vcnt; i++) {
+ page = bvec[i].bv_page;
+ if (page)
+ put_page(page);
+ }
+ bio_put(bio);
+ }
+ if (atomic_dec_and_test(bio_count))
+ aio_complete(iocb, iocb->ki_nbytes, 0);
- return generic_file_aio_write_nolock(iocb, _iov, 1,
>ki_pos);
+ return 0;
}
+static ssize_t raw_file_aio_rw(struct kiocb *iocb, char __user *buf,
+ size_t count, loff_t pos, int rw)
+{
+ struct inode * inode = iocb->ki_filp->f_mapping->host;
+ unsigned long blkbits = inode->i_blkbits;
+ unsigned long blocksize_mask = (1<< blkbits) - 1;
+ struct page * quick_list[PAGE_QUICK_LIST];
+ int nr_pages, cur_offset, cur_len;
+ struct bio * bio;
+ unsigned long ret;
+ unsigned long addr = (unsigned long) buf;
+ loff_t size;
+ int pg_idx;
+ atomic_t *bio_count = (atomic_t *) >private;
+
+ if (count == 0)
+ return 0;
+
+ /* first check the alignment */
+ if (addr & blocksize_mask || count & blocksize_mask ||
+ count < 0 || pos & blocksize_mask)
+ return -EINVAL;
+
+ size = i_size_read(inode);
+ if (pos >= size)
+ return -ENXIO;
+ if (pos + count > size)
+ count = size - pos;
+
+ nr_pages = (addr + count + PAGE_SIZE - 1) / PAGE_SIZE -
+ addr / PAGE_SIZE;
+
+ pg_idx = PAGE_QUICK_LIST;
+ atomic_set(bio_count, 1);
+
+start:
+ bio = bio_alloc(GFP_KERNEL, nr_pages);
+ if (unlikely(bio == NULL)) {
+ if (atomic_read(bio_count) == 1)
+ return -ENOMEM;
+ else {
+ iocb->ki_nbytes = addr - (unsigned long) buf;
+ goto out;
+ }
+ }
+
+ /* initialize bio */
+ bio->bi_bdev = I_BDEV(inode);
+ bio->bi_end_io = raw_end_aio;
+ bio->bi_private = iocb;
+ bio->bi_sector = pos >> blkbits;
+
+ while (count > 0) {
+ cur_offset = addr & ~PAGE_MASK;
+ cur_len = PAGE_SIZE - cur_offset;
+ if (cur_len > count)
+ cur_len = count;
+
+ if (pg_idx >= PAGE_QUICK_LIST) {
+ down_read(>mm->mmap_sem);
+ ret = get_user_pages(current, current->mm, addr,
+ min(nr_pages, PAGE_QUICK_LIST),
+ rw==READ, 0, quick_list, NULL);
+ up_read(>mm->mmap_sem);
+ if (unlikely(ret < 0)) {
+ bio_put(bio);
+ if (atomic_read(bio_count) == 1)
+ return ret;
+ else {
+ iocb->ki_nbytes = addr - (unsigned
long) buf;
+ goto out;
+ }
+ }
+ pg_idx = 0;
+ }
+
+ if (unlikely(!bio_add_page(bio, quick_list[pg_idx], cur_len,
cur_offset))) {
+ atomic_inc(bio_count);
+ if (rw == READ)
+ bio_set_pages_dirty(bio);
+ submit_bio(rw, bio);
+ pos += addr - (unsigned long) buf;
+ goto start;
+ }
+
+ addr += cur_len;
+ count -= cur_len;
+ pg_idx++;
+ nr_pages--;
+ }
+
+ atomic_inc(bio_count);
+ if (rw == READ)
+
Re: [Alsa-devel] Re: intel 8x0 went silent in 2.6.11
I think I've gone through every possible value here from asound.state to each setting in KDE itself. Still, the only sound that works is the one coming from line-out, without the port replicator, no sound exists whatsoever. Both of the below controls are set to false in asound.state and cooresponding KDE settings in kmix. I think the concern becomes though, regardless of what kde was doing after the fact, this condition didn't exits in <= 2.6.10 when no other applications where changed around it. On Tue, 8 Mar 2005, Takashi Iwai wrote: My question is its 'value'. The entry in /etc/asound.state should have a boolean value. Let me repeat the explanation of the situation: The existence of 'Headphone Jack Sense' and 'Line-in Jack Sense' controls themselves are not the problem. If they are set off, the behavior of the driver must be identical with the older version. No regression. The patch I mentionted turns off them as default unless the device is known to work. But the controls still exist, and you can change them afterward manually. So, the solution is once to turn off these controls via a mixer and save the state via alsactl (usually the system does at shutdown), so that the correct states are restored at the next reboot. That's why I asked you - to check the saved status of these controls. If the correct values are saved there and still the problem exists, someone else must have changed the mixer status. For example, KDE (kmix) seems to set up the mixer status by itself, and does not always correctly. That was my suspect. I don't know GNOME does something like that, too. Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select(2), usbserial, tty's and disconnect
Joerg Pommnitz wrote: Hello all, currently it seems that select keeps blocking when the USB device behind ttyUSBx gets unplugged. My understanding is, that select should return when the next call to one of the operations (read/write) will not block. This is certainly true for failing with ENODEV. So, is this an issue that will be fixed or should I poll (not the syscall) the device? Or is there another way to monitor for a vanishing tty (it should not be USB specific). If you just do a blocking read() on the USB serial port, what happens when you pull the device? At one point (2.4.20 is the last I checked) nothing happened when you did this, the process would just sit there forever. There was discussion at one point about doing a tty_hangup() when the USB device was disconnected (this causes the read() to return with 0 bytes and future open attempts to fail), and a patch was put out to do this. I thought this had been merged, but I could be wrong. I should think that if that works, then your select should be working as well.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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/
Large Page Support for ARM (Intel Xscale)
Hello, I am looking for Large Page Implmentation (similar to the hugetlb effort) for ARM processors, specifically Xscale. Is there an ongoing project any one can point me to? I tried searching for before posting this message but couldn't find anything relevant. If this questions had already been asked, please bear with me and point me to the right URL. I am not subscribed to this list. So please include me in your replies. Thanks, Venkat - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Pktcdvd and DVD RW drive.
Hello, I have an hdc: HL-DT-ST DVDRAM GSA-4120B, ATAPI CD/DVD-ROM drive from LG. My kernel is a vanilla 2.6.11 with packet writing enabled. I noticed, however, that I can mount and write a CD-RW udf formatted with # cdrwtool -d /dev/hdc -q without the need of the pktcdvd driver (with the module unloaded, indeed), simply with # mount -t udf /dev/hdc /mnt I thought that this was a property only of DVD+RW and DVDRAM media. Am I missing something here? What is then the use of pktcdvd driver? Thanks in advice, Joao Luis M. Assirati. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [announce 7/7] fbsplash - documentation
On Wed, Mar 09, 2005 at 01:17:11AM +0100, Arnd Bergmann wrote: > You also shouldn't create a class device every time you want to call > kobject_hotplug. Note that every character device already has a class > device associated with it, so you might be able to just use that to > call kobject_hotplug on it. > > If there is no obvious way to do that, just leave the code as it is > for calling the helper. OK, thanks forthe explanation and advice. I'll look into it. > > The reason for calling init in that place is the ability to use the > > userspace helper to display a nice picture while the kernel is still > > loading. Sure, you can just drop it and use the 'quiet' command line > > option, but that will give you a black screen for a good few seconds. > > And people who want eye-candy like fbsplash generally don't like > > that. > > Ok, understood. I think you should make that an extra patch and completely > remove that feature from the base patchset in order to make it less > controversial. That can be done. The funny thing is, a week ago or so, it was proposed in a thread about bootsplash that the code for the initial call could be merged first and serve as a base for merging fbsplash :) > > > That sounds really dangerous. Can you guarantee that nothing > > > unexpected happens when a malicious user calls the ioctls with > > > FB_SPLASH_IO_ORIG_KERNEL from a regular user process? > > > > This is pretty nasty, right, but I just can't see a way around it. > > The thing is, when the splash helper is called from the kernel, the > > console semaphore is already held so we have to avoid trying to acquire > > it again. And we can't just release it prior to calling the helper, as > > it would break things badly. > > I don't understand. Does the kernel code need to wait for the helper > to finish while holding the semaphore? AFAICS, the helper is > completely asynchronous, so it can simply do its job when the kernel > has given up the semaphore. > > And we can't do ioctls on ttys when > > answering a kernel request because to the console sem problems > > (opening a tty = a call to acquire_console_sem(), which we need to > > avoid). > > Hmm. One of us has misunderstood the interaction between > call_usermodehelper() and acquire_console_sem(). If I'm the one > who's wrong, please tell me where that semaphore is held. It think this will be best explained with an example. Consider the following situation - we have two ttys - tty1 and tty2. tty1 is using theme 'foo' an it's the foreground console. tty2 is using theme 'bar'. Fbsplash is enabled on both these ttys. Now the user decides to switch to tty2. He/she presses Alt+F2. The keypress is handled somewhere and an item is added to the console_work workqueue. console_callback() gets called asynchronously. acquire_console_sem() is the first thing done in that function. Now we have the following call stack (all done with the console sem held): change_console() complete_change_console() switch_screen() == redraw_screen() con_switch() == fbcon_switch() From inside fbcon_switch(), we need to call the splash helper to get a new picture for the theme 'bar' which is used on tty2. The splash helper does an ioctl and we're back in the kernel.. with the console semaphore already held. > > The original idea behind this was to group the fields that are > > common to all fbsplash ioctl calls (ie. vc and origin) in one place. > > Of course, it can be changed to three differents structs, each > > containing the vc and origin fields and an int/struct vc_splash/struct > > fb_image, if that is the preferred way of doing things. > > It definitely is. Actually, it would be preferred to have only a > single value as ioctl argument (or even better, no ioctl at all), > but if you need to pass an aggregate data type, it should at least > have an identical layout for all architectures. That means every > member should be naturally aligned and you can't use pointers or other > types that have sizeof(x) == sizeof(long). What are the alternatives to the ioctl? A relatively clean way of feeding the data back to the kernel would be using sysfs. However, to make it sane we would have to export the various components of struct vc_splash in /sys/class/tty/tty (otherwise, we would probabky have to pass aggreaget data types through a sysfs entry -- something that is IMO much worse than an ioctl). That however could be a little problematic -- tty_class is currently defined as a class_simple. To add entries other than the standard 'dev' we would have to define a completely new class, right? That sounds like a rather intrusive change.. Live long and prosper. -- Michal 'Spock' JanuszewskiGentoo Linux Developer cell: +48504917690 http://dev.gentoo.org/~spock/ JID: [EMAIL PROTECTED] freenode: #gentoo-dev, #gentoo-pl pgpdoH5LwDpT0.pgp Description: PGP signature
Re: 2.6.11-mm2
On Wed, Mar 09, 2005 at 01:20:46AM +0100, Adrian Bunk wrote: > On Tue, Mar 08, 2005 at 03:38:46AM -0800, Andrew Morton wrote: > >... > > Changes since 2.6.11-mm1: > >... > > +drivers-isdn-tpam-convert-to-pci_register_driver.patch > >... > > Little code tweaks. > >... > > Please drop this patch. > > Karsten has a patch ready to remove this driver (because the hardware it > was supposed to drive never went into production), and such patches only > cause needless rediffs. > > @Karsten: > Could you submit your patch to remove tpam to Andrew? > :-) already done few houres ago (against -mm2) -- Karsten Keil SuSE Labs ISDN development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Direct io on block device has performance regression on 2.6.x kernel - pseudo disk driver
The pseudo disk driver that I used to stress the kernel I/O stack
(anything above block layer, AIO/DIO/BIO).
- Ken
diff -Nur zero/blknull.c blknull/blknull.c
--- zero/blknull.c 1969-12-31 16:00:00.0 -0800
+++ blknull/blknull.c 2005-03-03 19:04:07.0 -0800
@@ -0,0 +1,97 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define BLK_NULL_MAJOR 60
+#define BLK_NULL_NAME "blknull"
+
+
+MODULE_AUTHOR("Ken Chen");
+MODULE_DESCRIPTION("null block driver");
+MODULE_LICENSE("GPL");
+
+
+spinlock_t driver_lock;
+struct request_queue *q;
+struct gendisk *disk;
+
+
+static int null_open(struct inode *inode, struct file *filp)
+{
+ return 0;
+}
+
+static int null_release(struct inode *inode, struct file *filp)
+{
+ return 0;
+}
+
+static struct block_device_operations null_fops = {
+ .owner = THIS_MODULE,
+ .open = null_open,
+ .release= null_release,
+};
+
+static void do_null_request(request_queue_t *q)
+{
+ struct request *req;
+
+ while (!blk_queue_plugged(q)) {
+ req = elv_next_request(q);
+ if (!req)
+ break;
+
+ blkdev_dequeue_request(req);
+
+ end_that_request_first(req, 1, req->nr_sectors);
+ end_that_request_last(req);
+ }
+}
+
+static int __init init_blk_null_module(void)
+{
+
+ if (register_blkdev(BLK_NULL_MAJOR, BLK_NULL_NAME)) {
+ printk(KERN_ERR "Unable to register null blk device\n");
+ return 0;
+ }
+
+ spin_lock_init(_lock);
+ q = blk_init_queue(do_null_request, _lock);
+ if (q) {
+ disk = alloc_disk(1);
+
+ if (disk) {
+ disk->major = BLK_NULL_MAJOR;
+ disk->first_minor = 0;
+ disk->fops = _fops;
+ disk->capacity = 1<<30;
+ disk->queue = q;
+ memcpy(disk->disk_name, BLK_NULL_NAME,
sizeof(BLK_NULL_NAME));
+ add_disk(disk);
+ return 1;
+ }
+
+ blk_cleanup_queue(q);
+ }
+ unregister_blkdev(BLK_NULL_MAJOR, BLK_NULL_NAME);
+ return 0;
+}
+
+static void __exit exit_blk_null_module(void)
+{
+ del_gendisk(disk);
+ blk_cleanup_queue(q);
+ unregister_blkdev(BLK_NULL_MAJOR, BLK_NULL_NAME);
+}
+
+module_init(init_blk_null_module);
+module_exit(exit_blk_null_module);
diff -Nur zero/Makefile blknull/Makefile
--- zero/Makefile 1969-12-31 16:00:00.0 -0800
+++ blknull/Makefile2005-03-03 18:42:55.0 -0800
@@ -0,0 +1 @@
+obj-m := blknull.o
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel mmap() and friends.
linux-os wrote: > If one uses x = __get_dma_pages(GFP_KERNEL, nr), finds the physical > address with b = virt_to_bus(x), then attempts to mmap(,,b,,,) the result > _does_not_fail_, yet the user ends up with memory ...somewhere > that is R/W able and WRONG. I don't think virt_to_bus is the correct function to be using for this translation (or pretty much anything, these days). What is this memory that you are attempting to do an mmap on, and where is this code going? Unless this is an ISA device and you need physical memory for DMA, __get_dma_pages is not correct either. > > Yet, if the code executes SetPageReserved(virt_to_page(x)), the > mmap() works and the user gets the CORRECT page(s). > > I think that if mmap() needs a physical buffer to be reserved > then that's fine. However, silently returning some different > buffer is a BUG. > > Is anyone aware of this BUG? Does anybody else care? The kernel isn't responsible for checking that the memory ranges you attempt to remap are what you intended - if you get this wrong, things can blow up, that's just the way it is. I would suggest following some similar driver/code in the kernel as an example if possible.. -- Robert Hancock Saskatoon, SK, Canada Home Page: http://www.roberthancock.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: Direct io on block device has performance regression on 2.6.x kernel
OK, last one in the series: user level test programs that stress
the kernel I/O stack. Pretty dull stuff.
- Ken
diff -Nur zero/aio_null.c blknull_test/aio_null.c
--- zero/aio_null.c 1969-12-31 16:00:00.0 -0800
+++ blknull_test/aio_null.c 2005-03-08 00:46:17.0 -0800
@@ -0,0 +1,76 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MAXAIO 1024
+
+char buf[4096] __attribute__((aligned(4096)));
+
+io_context_t io_ctx;
+struct iocbiocbpool[MAXAIO];
+struct io_eventioevent[MAXAIO];
+
+void aio_setup(int n)
+{
+ int res = io_queue_init(n, _ctx);
+ if (res != 0) {
+ printf("io_queue_setup(%d) returned %d (%s)\n",
+ n, res, strerror(-res));
+ exit(0);
+ }
+}
+
+main(int argc, char* argv[])
+{
+ int fd, i, status, batch;
+ struct iocb* iocbbatch[MAXAIO];
+ int devidx;
+ off_t offset;
+ unsigned long start, end;
+
+ batch = argc < 2 ? 100: atoi(argv[1]);
+ if (batch >= MAXAIO)
+ batch = MAXAIO;
+
+ aio_setup(MAXAIO);
+ fd = open("/dev/raw/raw1", O_RDONLY);
+
+ if (fd == -1) {
+ perror("error opening\n");
+ exit (0);
+ }
+ for (i=0; i
+#include
+#include
+#include
+
+main(int argc, char* argv[])
+{
+ int fd;
+ char *addr;
+
+ fd = open("/dev/raw/raw1", O_RDONLY);
+ if (fd == -1) {
+ perror("error opening\n");
+ exit(0);
+ }
+
+ addr = memalign(4096, 4096);
+ if (addr == 0) {
+ printf("no memory\n");
+ exit(0);
+ }
+
+ while (1) {
+ pread(fd, addr, 4096, 0);
+ }
+
+}
diff -Nur zero/makefile blknull_test/makefile
--- zero/makefile 1969-12-31 16:00:00.0 -0800
+++ blknull_test/makefile 2005-03-08 17:10:39.0 -0800
@@ -0,0 +1,10 @@
+all: pread_null aio_null
+
+pread_null: pread_null.c
+ gcc -O3 -o $@ pread_null.c
+
+aio_null: aio_null.c
+ gcc -O3 -o $@ aio_null.c -laio
+
+clean:
+ rm -f pread_null aio_null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] drivers/char/isicom.c: section fixes
This patch fixes the following bugs:
- __exit unregister_ioregion and unregister_drivers were called by
__init isicom_init
- __init isicom_init was called by __devinit isicom_setup
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/char/isicom.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
--- linux-2.6.11-mm2-full/drivers/char/isicom.c.old 2005-03-09
02:05:14.0 +0100
+++ linux-2.6.11-mm2-full/drivers/char/isicom.c 2005-03-09 02:22:05.0
+0100
@@ -1756,7 +1756,7 @@
}
-static int __init register_ioregion(void)
+static int __devinit register_ioregion(void)
{
int count, done=0;
for (count=0; count < BOARD_COUNT; count++ ) {
@@ -1771,7 +1771,7 @@
return done;
}
-static void __exit unregister_ioregion(void)
+static void unregister_ioregion(void)
{
int count;
for (count=0; count < BOARD_COUNT; count++ )
@@ -1803,7 +1803,7 @@
.tiocmset = isicom_tiocmset,
};
-static int __init register_drivers(void)
+static int __devinit register_drivers(void)
{
int error;
@@ -1834,7 +1834,7 @@
return 0;
}
-static void __exit unregister_drivers(void)
+static void unregister_drivers(void)
{
int error = tty_unregister_driver(isicom_normal);
if (error)
@@ -1842,7 +1842,7 @@
put_tty_driver(isicom_normal);
}
-static int __init register_isr(void)
+static int __devinit register_isr(void)
{
int count, done=0;
unsigned long irqflags;
@@ -1883,7 +1883,7 @@
}
}
-static int __init isicom_init(void)
+static int __devinit isicom_init(void)
{
int card, channel, base;
struct isi_port * port;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Direct io on block device has performance regression on 2.6.x kernel - fix sync I/O path
This patch adds block device direct I/O for synchronous path.
I added in the raw device code to demo the performance effect.
48% performance gain!!
synchronous I/O
(pread/pwrite/read/write)
2.6.9 218,565
2.6.9+patches 323,016
- Ken
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
diff -Nurp linux-2.6.9/drivers/char/raw.c linux-2.6.9.ken/drivers/char/raw.c
--- linux-2.6.9/drivers/char/raw.c 2004-10-18 14:54:37.0 -0700
+++ linux-2.6.9.ken/drivers/char/raw.c 2005-03-08 17:22:07.0 -0800
@@ -238,15 +238,151 @@ out:
return err;
}
+struct rio {
+ atomic_t bio_count;
+ struct task_struct *p;
+};
+
+int raw_end_io(struct bio *bio, unsigned int bytes_done, int error)
+{
+ struct rio * rio = bio->bi_private;
+
+ if ((bio->bi_rw & 0x1) == READ)
+ bio_check_pages_dirty(bio);
+ else {
+ int i;
+ struct bio_vec *bvec = bio->bi_io_vec;
+ struct page *page;
+ for (i = 0; i < bio->bi_vcnt; i++) {
+ page = bvec[i].bv_page;
+ if (page)
+ put_page(page);
+ }
+ bio_put(bio);
+ }
+
+ if (atomic_dec_and_test(>bio_count))
+ wake_up_process(rio->p);
+ return 0;
+}
+
+#define PAGE_QUICK_LIST16
+static ssize_t raw_file_rw(struct file *filp, char __user *buf,
+ size_t count, loff_t *ppos, int rw)
+{
+ struct inode * inode = filp->f_mapping->host;
+ unsigned long blkbits = inode->i_blkbits;
+ unsigned long blocksize_mask = (1<< blkbits) - 1;
+ struct page * quick_list[PAGE_QUICK_LIST];
+ int nr_pages, cur_offset, cur_len, pg_idx;
+ struct bio * bio;
+ unsigned long ret;
+ unsigned long addr = (unsigned long) buf;
+ loff_t pos = *ppos, size;
+ struct rio rio;
+
+ if (count == 0)
+ return 0;
+
+ /* first check the alignment */
+ if (addr & blocksize_mask || count & blocksize_mask ||
+ count < 0 || pos & blocksize_mask)
+ return -EINVAL;
+
+ size = i_size_read(inode);
+ if (pos >= size)
+ return -ENXIO;
+ if (pos + count > size)
+ count = size - pos;
+
+ nr_pages = (addr + count + PAGE_SIZE - 1) / PAGE_SIZE -
+ addr / PAGE_SIZE;
+
+ pg_idx = PAGE_QUICK_LIST;
+ atomic_set(_count, 1);
+ rio.p = current;
+
+start:
+ bio = bio_alloc(GFP_KERNEL, nr_pages);
+ if (unlikely(bio == NULL)) {
+ if (atomic_read(_count) == 1)
+ return -ENOMEM;
+ else {
+ goto out;
+ }
+ }
+
+ /* initialize bio */
+ bio->bi_bdev = I_BDEV(inode);
+ bio->bi_end_io = raw_end_io;
+ bio->bi_private =
+ bio->bi_sector = pos >> blkbits;
+
+ while (count > 0) {
+ cur_offset = addr & ~PAGE_MASK;
+ cur_len = PAGE_SIZE - cur_offset;
+ if (cur_len > count)
+ cur_len = count;
+
+ if (pg_idx >= PAGE_QUICK_LIST) {
+ down_read(>mm->mmap_sem);
+ ret = get_user_pages(current, current->mm, addr,
+ min(nr_pages, PAGE_QUICK_LIST),
+ rw==READ, 0, quick_list, NULL);
+ up_read(>mm->mmap_sem);
+ if (unlikely(ret < 0)) {
+ bio_put(bio);
+ if (atomic_read(_count) == 1)
+ return ret;
+ else {
+ goto out;
+ }
+ }
+ pg_idx = 0;
+ }
+
+ if (unlikely(!bio_add_page(bio, quick_list[pg_idx], cur_len,
+ cur_offset))) {
+ atomic_inc(_count);
+ if (rw == READ)
+ bio_set_pages_dirty(bio);
+ submit_bio(rw, bio);
+ pos += addr - (unsigned long) buf;
+ goto start;
+ }
+
+ addr += cur_len;
+ count -= cur_len;
+ pg_idx++;
+ nr_pages--;
+ }
+
+ atomic_inc(_count);
+ if (rw == READ)
+ bio_set_pages_dirty(bio);
+ submit_bio(rw, bio);
+out:
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ blk_run_address_space(inode->i_mapping);
+ if (!atomic_dec_and_test(_count))
+ io_schedule();
+ set_current_state(TASK_RUNNING);
+
+ ret = addr - (unsigned long) buf;
+ *ppos += ret;
+
[2.6 patch] unexport console_unblank
I didn't find any possible modular usage of console_unblank in the kernel. This patch was already ACK'ed by Alan Cox. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 3 Mar 2005 --- linux-2.6.11-rc5-mm1-full/kernel/printk.c.old 2005-03-03 17:04:18.0 +0100 +++ linux-2.6.11-rc5-mm1-full/kernel/printk.c 2005-03-03 17:04:24.0 +0100 @@ -757,7 +757,6 @@ c->unblank(); release_console_sem(); } -EXPORT_SYMBOL(console_unblank); /* * Return the console tty driver structure and its associated index - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] kernel/power/smp.c: make a variable static
This patch makes a needlessly global variable static.
This patch was already ACK'ed by Pavel Machek.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 3 Mar 2005
--- linux-2.6.11-rc5-mm1-full/kernel/power/smp.c.old2005-03-03
17:00:30.0 +0100
+++ linux-2.6.11-rc5-mm1-full/kernel/power/smp.c2005-03-03
17:00:38.0 +0100
@@ -42,7 +42,7 @@
__restore_processor_state();
}
-cpumask_t oldmask;
+static cpumask_t oldmask;
void disable_nonboot_cpus(void)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Direct io on block device has performance regression on 2.6.x kernel
I don't know where to start, but let me start with the bombshell: Direct I/O on block device running 2.6.X kernel is a lot SLOWER than running on a 2.4 Kernel! Processing a direct I/O request on 2.6 is taking a lot more cpu time compare to the same I/O request running on a 2.4 kernel. The proof: easy. I started off by having a pseudo disk, a software disk that has zero access latency. By hooking this pseudo disk into the block layer API, I can effectively stress the entire I/O stack above the block level. Combined with user level test programs that simply submit direct I/O in a simple while loop, I can measure how fast kernel can process these I/O requests. The performance metric can be either throughput (# of I/O per second) or per unit of work (processing time per I/O). For the data presented below, I'm using throughput metric (meaning larger number is better performance). Pay attention to relative percentage as absolute number depends on platform/CPU that test suite runs on. synchronous I/O AIO (pread/pwrite/read/write) io_submit 2.4.21 based (RHEL3) 265,122 229,810 2.6.9 218,565 206,917 2.6.10 213,041 205,891 2.6.11 212,284 201,124 >From the above chart, you can see that 2.6 kernel is at least 18% slower in processing direct I/O (on block device) in the synchronous path and 10% slower in the AIO path compare to a distributor's 2.4 kernel. What's worse, with each advance of kernel version, the I/O path is becoming slower and slower. Most of the performance regression for 2.6.9 came from dio layer (I still have to find where the regression came from with 2.6.10 and 2.6.11). DIO is just overloaded with too many areas to cover. I think it's better to break things up a little bit. For example, by having a set of dedicated functions that do direct I/O on block device improves the performance dramatically: synchronous I/O AIO (pread/pwrite/read/write) io_submit 2.4.21 based (RHEL3) 265,122 229,810 2.6.9 218,565 206,917 2.6.9+patches 323,016 268,484 See, we can be actually 22% faster in synchronous path and 17% faster In the AIO path, if we do it right! Kernel patch and test suite to follow in the next couple postings. - Ken - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec 29160 + Promise Ultratrak100 TX8 problems
Maarten de Boer <[EMAIL PROTECTED]> wrote: > > I am having nasty problems with an Adaptec 29160 and Promise > Ultratrak100 TX8 external RAID. (kernel 2.6.11) Does it work correctly under any other kernel versions? If so, which? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange memory leak in 2.6.x
Tobias Hennerich <[EMAIL PROTECTED]> wrote:
>
> we kindly ask for some suggestions about how to trace a memory leak
> which we suspect in the linux kernel version 2.6:
Please grab 2.6.11, apply the below patch, set CONFIG_PAGE_OWNER and follow
the below instructions.
From: Alexander Nyberg <[EMAIL PROTECTED]>
Introduces CONFIG_PAGE OWNER that keeps track of the call chain under which
a page was allocated. Includes a user-space helper in
Documentation/page_owner.c to sort the enormous amount of output that this
may give (thanks tridge).
Information available through /proc/page_owner
x86_64 introduces some stack noise in certain call chains so for exact
output use of x86 && CONFIG_FRAME_POINTER is suggested. Tested on x86, x86
&& CONFIG_FRAME_POINTER, x86_64
Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/Documentation/page_owner.c | 140 +
25-akpm/fs/proc/proc_misc.c| 63
25-akpm/include/linux/mm.h |4 +
25-akpm/lib/Kconfig.debug | 10 ++
25-akpm/mm/page_alloc.c| 56 ++
5 files changed, 273 insertions(+)
diff -puN /dev/null Documentation/page_owner.c
--- /dev/null 2003-09-15 06:40:47.0 -0700
+++ 25-akpm/Documentation/page_owner.c 2005-02-22 18:17:32.0 -0800
@@ -0,0 +1,140 @@
+/*
+ * User-space helper to sort the output of /proc/page_owner
+ *
+ * Example use:
+ * cat /proc/page_owner > page_owner.txt
+ * ./sort page_owner.txt sorted_page_owner.txt
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct block_list {
+ char *txt;
+ int len;
+ int num;
+};
+
+
+static struct block_list *list;
+static int list_size;
+static int max_size;
+
+struct block_list *block_head;
+
+int read_block(char *buf, FILE *fin)
+{
+ int ret = 0;
+ int hit = 0;
+ char *curr = buf;
+
+ for (;;) {
+ *curr = getc(fin);
+ if (*curr == EOF) return -1;
+
+ ret++;
+ if (*curr == '\n' && hit == 1)
+ return ret - 1;
+ else if (*curr == '\n')
+ hit = 1;
+ else
+ hit = 0;
+ curr++;
+ }
+}
+
+static int compare_txt(struct block_list *l1, struct block_list *l2)
+{
+ return strcmp(l1->txt, l2->txt);
+}
+
+static int compare_num(struct block_list *l1, struct block_list *l2)
+{
+ return l2->num - l1->num;
+}
+
+static void add_list(char *buf, int len)
+{
+ if (list_size != 0 &&
+ len == list[list_size-1].len &&
+ memcmp(buf, list[list_size-1].txt, len) == 0) {
+ list[list_size-1].num++;
+ return;
+ }
+ if (list_size == max_size) {
+ printf("max_size too small??\n");
+ exit(1);
+ }
+ list[list_size].txt = malloc(len+1);
+ list[list_size].len = len;
+ list[list_size].num = 1;
+ memcpy(list[list_size].txt, buf, len);
+ list[list_size].txt[len] = 0;
+ list_size++;
+ if (list_size % 1000 == 0) {
+ printf("loaded %d\r", list_size);
+ fflush(stdout);
+ }
+}
+
+int main(int argc, char **argv)
+{
+ FILE *fin, *fout;
+ char buf[1024];
+ int ret, i, count;
+ struct block_list *list2;
+ struct stat st;
+
+ fin = fopen(argv[1], "r");
+ fout = fopen(argv[2], "w");
+ if (!fin || !fout) {
+ printf("Usage: ./program \n");
+ perror("open: ");
+ exit(2);
+ }
+
+ fstat(fileno(fin), );
+ max_size = st.st_size / 100; /* hack ... */
+
+ list = malloc(max_size * sizeof(*list));
+
+ for(;;) {
+ ret = read_block(buf, fin);
+ if (ret < 0)
+ break;
+
+ buf[ret] = '\0';
+ add_list(buf, ret);
+ }
+
+ printf("loaded %d\n", list_size);
+
+ printf("sorting \n");
+
+ qsort(list, list_size, sizeof(list[0]), compare_txt);
+
+ list2 = malloc(sizeof(*list) * list_size);
+
+ printf("culling\n");
+
+ for (i=count=0;i
+#include
+static ssize_t
+read_page_owner(struct file *file, char __user *buf, size_t count, loff_t
*ppos)
+{
+ struct page *start = pfn_to_page(min_low_pfn);
+ static struct page *page;
+ char *kbuf, *modname;
+ const char *symname;
+ int ret = 0, next_idx = 1;
+ char namebuf[128];
+ unsigned long offset = 0, symsize;
+ int i;
+
+ page = start + *ppos;
+ for (; page < pfn_to_page(max_pfn); page++) {
+ if (page->order >= 0)
+ break;
+ next_idx++;
+ continue;
+ }
+
+ if (page >= pfn_to_page(max_pfn))
+ return 0;
+
+ *ppos += next_idx;
+
+
Re: 2.6.11-mm2
Andrew Morton wrote: Adrian Bunk <[EMAIL PROTECTED]> wrote: On Tue, Mar 08, 2005 at 03:38:46AM -0800, Andrew Morton wrote: ... Changes since 2.6.11-mm1: ... -fix-buggy-ieee80211_crypt_-selects.patch Was wrong. ... I'd say my patch was correct. Uh, OK. Make that "was subject of interminable bunfight". Feel free to resend and I'll keep spamming Jeff with it. It's quite simple: one specifies dependencies in one place, so that one does not have specify dependencies in _every_ place. AFAICS the thread already reaches that point, people [most of them] agree with me, and then throw up their hands as to a fix. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [patch] dvb: add pll lib
(linux-dvb list removed from Cc: because it is subscribers only) On Tue, Mar 08, 2005 at 11:57:26AM +0100, Gerd Knorr wrote: > This adds some helper code to handle tuning for dvb cards, > with a struct describing the pll and a function calculating > the command sequence needed to program it. > > This one was discussed + accepted on the linuxtv list and > also is in the linuxtv cvs. As the the cx88 driver update > I want finally get out of the door depends on this one I'll > go submit it myself instead of waiting for the dvb guys doing > it. Michael Hunold is somewhat busy with his new job at Toshiba, so I want to takeover patch submission for now. However, one thing that makes it difficult to create kernel patches from linuxtv.org CVS is that there are a large number of whitespace differences between the kernel tree and CVS. There's also some corrupted indentation in the kernel, e.g. drivers/media/dvb/frontends/tda1004x.c:tda1004x_sleep(). I wanted to get this issue out of the way before I start to submit other patches from linuxtv.org CVS. I merged some whitespace cleanups from the kernel into CVS, and created a patch to clean up whitespace in the kernel, removing lots of whitespace at end-of-line in the go. The problem with this patch is that it is huge (600K) :-(. I was crazy enough to mail it to Linus anyway on Sunday, and it looks like it got dropped on the floor :-(( It would be nice if I could get some advice how to submit this kind of cleanup (i.e. if I should split it up in tiny fragments), or if I should ignore the issue for now and concentrate on functional improvements. The DVB related patches submitted by Gerd are non-controversial and should be applied. Johannes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE][PATCH 2.6.11 1/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
On Tue, Mar 08, 2005 at 06:05:11PM -0500, Bagalkote, Sreenivas wrote: > > > >> source "drivers/scsi/megaraid/Kconfig.megaraid" > >> +source "drivers/scsi/megaraid/Kconfig.megaraid_sas" > >> > > > >why a fully separate file and not add your ONE config option to > >Kconfig.megaraid instead ?? > > > > Arjan, I didn't want to needlessly couple megaraid and megaraid_sas. > Since they are in the same directory, I couldn't avoid having single > Makefile. I thought at least these two should be separate to be consistent > with their independent nature. > > If this is not a good enough reason, I will merge these two files. Please merge them. Whether they are in the same Kconfig file or not does not in any way imply any relation between them. E.g. drivers/scsi/Kconfig contains many drivers that are not in any way coupled to each other. > Thanks, > Sreenivas cu Adrian BTW: Why does the text say "(New Driver)"? -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BK PATCH] USB update for 2.6.11
Hi, Here are a lot of USB patches for 2.6.11. All of these patches have been in the past few -mm releases. Most notable is the change of two USB api functions to accept milliseconds instead of jiffies. All USB drivers in the kernel tree that use these functions have been fixed up properly. There are also three new USB drivers included here. Please pull from: bk://kernel.bkbits.net/gregkh/linux/usb-2.6 Patches will be posted to linux-usb-devel as a follow-up thread for those who want to see them. thanks, greg k-h CREDITS | 12 Documentation/usb/error-codes.txt | 28 Documentation/usb/sn9c102.txt | 13 MAINTAINERS | 40 drivers/bluetooth/bfusb.c |8 drivers/char/watchdog/pcwd_usb.c |2 drivers/media/dvb/b2c2/b2c2-usb-core.c| 10 drivers/media/dvb/cinergyT2/cinergyT2.c |4 drivers/media/dvb/dibusb/dvb-dibusb-firmware.c|2 drivers/media/dvb/dibusb/dvb-dibusb.h |2 drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c |4 drivers/media/dvb/ttusb-dec/ttusb_dec.c |8 drivers/media/video/cpia_usb.c|4 drivers/net/irda/irda-usb.c |2 drivers/net/irda/stir4200.c |6 drivers/usb/Kconfig |2 drivers/usb/Makefile |2 drivers/usb/atm/speedtch.c|8 drivers/usb/class/audio.c | 56 drivers/usb/class/cdc-acm.c | 86 drivers/usb/class/cdc-acm.h | 49 drivers/usb/class/usblp.c |2 drivers/usb/core/config.c |3 drivers/usb/core/devices.c| 25 drivers/usb/core/devio.c | 260 + drivers/usb/core/hcd-pci.c| 159 - drivers/usb/core/hcd.c| 310 +- drivers/usb/core/hcd.h| 74 drivers/usb/core/hub.c| 126 drivers/usb/core/hub.h|1 drivers/usb/core/message.c| 79 drivers/usb/core/sysfs.c | 92 drivers/usb/core/usb.c|5 drivers/usb/gadget/Kconfig|8 drivers/usb/gadget/dummy_hcd.c| 81 drivers/usb/gadget/ether.c| 250 - drivers/usb/gadget/gadget_chips.h |6 drivers/usb/gadget/net2280.c | 25 drivers/usb/gadget/omap_udc.c | 30 drivers/usb/gadget/pxa2xx_udc.c |1 drivers/usb/gadget/rndis.c|2 drivers/usb/gadget/serial.c | 157 - drivers/usb/gadget/zero.c |2 drivers/usb/host/Kconfig | 40 drivers/usb/host/ehci-hcd.c | 53 drivers/usb/host/ehci-hub.c |4 drivers/usb/host/ehci-q.c |6 drivers/usb/host/ehci-sched.c |8 drivers/usb/host/ehci.h |8 drivers/usb/host/ohci-au1xxx.c| 136 drivers/usb/host/ohci-dbg.c |4 drivers/usb/host/ohci-hcd.c | 47 drivers/usb/host/ohci-lh7a404.c | 138 drivers/usb/host/ohci-omap.c | 197 - drivers/usb/host/ohci-ppc-soc.c | 422 ++ drivers/usb/host/ohci-pxa27x.c| 127 drivers/usb/host/ohci-q.c |9 drivers/usb/host/ohci-sa.c| 130 drivers/usb/host/ohci.h | 48 drivers/usb/host/sl811-hcd.c | 73 drivers/usb/host/uhci-debug.c |9 drivers/usb/host/uhci-hcd.c | 1501 -- drivers/usb/host/uhci-q.c | 1488 ++ drivers/usb/image/mdc800.c| 42 drivers/usb/input/aiptek.c| 23 drivers/usb/input/ati_remote.c| 38 drivers/usb/input/hid-core.c | 38 drivers/usb/input/mtouchusb.c | 22 drivers/usb/input/powermate.c |2 drivers/usb/input/touchkitusb.c | 19 drivers/usb/input/usbkbd.c| 20 drivers/usb/input/usbmouse.c | 19 drivers/usb/input/wacom.c | 672 ++-- drivers/usb/media/ibmcam.c|4 drivers/usb/media/konicawc.c |2
Re: 2.6.11-mm2
Adrian Bunk <[EMAIL PROTECTED]> wrote: > > On Tue, Mar 08, 2005 at 03:38:46AM -0800, Andrew Morton wrote: > >... > > Changes since 2.6.11-mm1: > >... > > -fix-buggy-ieee80211_crypt_-selects.patch > > > > Was wrong. > >... > > I'd say my patch was correct. Uh, OK. Make that "was subject of interminable bunfight". Feel free to resend and I'll keep spamming Jeff with it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ANNOUNCE][PATCH 2.6.11 1/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
> >> source "drivers/scsi/megaraid/Kconfig.megaraid" >> +source "drivers/scsi/megaraid/Kconfig.megaraid_sas" >> > >why a fully separate file and not add your ONE config option to >Kconfig.megaraid instead ?? > Arjan, I didn't want to needlessly couple megaraid and megaraid_sas. Since they are in the same directory, I couldn't avoid having single Makefile. I thought at least these two should be separate to be consistent with their independent nature. If this is not a good enough reason, I will merge these two files. Thanks, Sreenivas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.10 - direct-io async short read bug
On Tue, 2005-03-08 at 11:18, Badari Pulavarty wrote: > > Andrew, please don't apply the original patch. We shouldn't even attempt > > to submit IO beyond the filesize. We should truncate the IO request to > > filesize. I will send a patch today to fix this. > > > > Well, spoke too soon. This is an ugly corner case :( But I have > a ugly hack to fix it :) > > Let me ask you a basic question: Do we support DIO reads on a file > which is not blocksize multiple in size ? (say 12K - 10 bytes) ? > What about the ones which are not 4K but 512 byte multiple ? (say 7K) ? > > I need answer to those, to figure out how hard I should try to fix this. > > Anyway, here is ugly version of the patch - which will limit the IO > size to filesize and uses lower blocksizes to read the file (since > the filesize is only 3K, it would go down to 512 byte blocksize). Badari, Just to be clear, are you just asking about what we should support on a DIO read that spans EOF? For DIO reads past EOF the options are: 1. return EINVAL if the DIO goes past EOF. 2. truncate the request to file size (which is what your patch does) and if it works, it works. 3. truncate the request to a size that actually works - like a multiple of 512. 4. Do the full i/o since the user buffer is big enough, truncate the result returned to file size (and clear out the user buffer where it read past EOF). Number 4 would make it easy on the user-level code, but AIO DIO might be a bit tricky and might be a security hole since the data would be dma'ed there and then cleared. I need to look at the code some more. 1 and 2 both seem valid and are better than returning the wrong result. 3 seems like it would confuse applications. Thoughts? Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Tue, Mar 08, 2005 at 03:37:07PM -0800, Greg KH wrote: > module aliases, and fixing up modprobe to handle spaces in module > aliases wouldn't work out easier. spaces _and_ characters. And characters are already used to separate different fields. pcmcia:pa"some string"pb"some other string" doesn't look bad though, indeed. Problem is: how to access the strings in file2alias.c? They're in different sections than the __mod_devicetables, and you'd need to get architecture-dependant relocation... so this doesn't seem feasible... or am I missing something? Dominik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [announce 7/7] fbsplash - documentation
On Dinsdag 08 MÃrz 2005 23:37, Michal Januszewski wrote: > On Tue, Mar 08, 2005 at 04:18:07AM +0100, Arnd Bergmann wrote: > > > It should probably just use its own hotplug agent instead of calling > > the helper directly. > > I've just had a look at it, and it seems possible. From what I have seen > in the firmware_class.c code, it would require: > - registering a class somewhere in the initializaton code > - every time a request from fbcon is generated: >- register the class device >- create a timer >- call kobject_hotplug() to send the event to userspace >- unregister the device > > This requests sent to userspace are generated while switching consoles > and resetting the graphics mode. This whole create device - send the > event - remove device thing seems a little long to me. Would it be > acceptable? Sorry, I had forgotten about the recent changes to the kernel side of the hotplug interface, i.e. that it now needs a kobject to work. It used to be possible to just call_usermodehelper() with hotplug_path as its argv[0], but that is currently being phased out. You also shouldn't create a class device every time you want to call kobject_hotplug. Note that every character device already has a class device associated with it, so you might be able to just use that to call kobject_hotplug on it. If there is no obvious way to do that, just leave the code as it is for calling the helper. > > > + When the userspace helper is called in an early phase of the boot > > > process > > > + (right after the initialization of fbcon), no filesystems will be > > > mounted. > > > + The helper program should mount sysfs and then create the appropriate > > > + framebuffer, fbsplash and tty0 devices (if they don't already exist) to > > > get > > > + current display settings and to be able to communicate with the kernel > > > side. > > > + It should probably also mount the procfs to be able to parse the kernel > > > + command line parameters. > > Nothing about the init command seems really necessary. Why not just do > > that stuff from an /sbin/init script? > > The reason for calling init in that place is the ability to use the > userspace helper to display a nice picture while the kernel is still > loading. Sure, you can just drop it and use the 'quiet' command line > option, but that will give you a black screen for a good few seconds. > And people who want eye-candy like fbsplash generally don't like that. Ok, understood. I think you should make that an extra patch and completely remove that feature from the base patchset in order to make it less controversial. > > > +FB_SPLASH_IO_ORIG_KERNEL instructs fbsplash not to try to acquire the > > > console > > > +semaphore. Not surprisingly, FB_SPLASH_IO_ORIG_USER instructs it to > > > acquire > > > +the console sem. > > > > That sounds really dangerous. Can you guarantee that nothing unexpected > > happens > > when a malicious user calls the ioctls with FB_SPLASH_IO_ORIG_KERNEL from a > > regular user process? > > This is pretty nasty, right, but I just can't see a way around it. The > thing is, when the splash helper is called from the kernel, the console > semaphore is already held so we have to avoid trying to acquire it > again. And we can't just release it prior to calling the helper, as it > would break things badly. I don't understand. Does the kernel code need to wait for the helper to finish while holding the semaphore? AFAICS, the helper is completely asynchronous, so it can simply do its job when the kernel has given up the semaphore. > > > +Info on used structures: > > > + > > > +Definition of struct vc_splash can be found in linux/console_splash.h. > > > It's > > > +heavily commented. Note that the 'theme' field should point to a string > > Not that heavily documented, actually ;-). > > Anything that needs some clearing-up? No, probably not. Maybe just remove that sentence from the text. > > > +no longer than FB_SPLASH_THEME_LEN. When FBIOSPLASH_GETCFG call is > > > +performed, the theme field should point to a char buffer of length > > > +FB_SPLASH_THEME_LEN. > > Then don't make it pointer but instead a field of that length. Pointers > > in ioctl arguments only cause trouble in mixed 32/64 bit environments. > > That could be arranged, but this would require a separate structure for > communicating with userspace and with in-kernel data storage (currently > both these tasks are handled with struct vc_splash), or changing > vc_splash in vc_data to a pointer to a structure. The latter option > would be better I think. Yes, that makes sense. > - fbsplash calls aren't really related to a particular framebuffer > device, they are related to a tty. ok. > And we can't do ioctls on ttys when > answering a kernel request because to the console sem problems > (opening a tty = a call to acquire_console_sem(), which we need to > avoid). Hmm. One of us has misunderstood the
Re: 2.6.11-mm2
HI all... On 03.08, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm2/ > (replied to this because this is the kernel I am testing on :) ) Can cpu affinity really be changed for a running process ? Does it need something like io or yielding to take effect ? I am playin with Robert Love's taskset (symlinked to runon, it is easier to type and I'm more used to it), because I want to play with hyperthreading and wanted a method to force two threads on the same physical package. It works fine to bound a new process to a cpu set, but I does not change anything for a running process. I try runon -c -p 0 for my numbercruncher and it does nothing, top shows it is in the same cpus where it started: werewolf:~# runon -c -p 0 8277 pid 8277's current affinity list: 0-3 pid 8277's new affinity list: 0 werewolf:~# runon -c -p 8277 pid 8277's current affinity list: 0 The program uses posix threads, 2 in this case. The two threads change from cpu sometimes (not too often), but do not go into the same processor immediately as when I start the program directly with runon/taskset. Any idea ? TIA -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Cooker) for i586 Linux 2.6.11-jam3 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #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 1/2] BDI: Provide backing device capability information [try #3]
David Howells <[EMAIL PROTECTED]> wrote: > > The attached patch replaces backing_dev_info::memory_backed with capabilitied > bitmap. Looks sane to me, thanks. I hope you got all the conversions correct - breakage in the writeback dirty accounting manifests in subtle ways. I'll double-check it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Wed, 2005-03-09 at 00:25 +0100, szonyi calin wrote: > --- Dave Jones <[EMAIL PROTECTED]> a écrit : > Taking into account that nobody responded on lkml nor > on alsa (the message was awaiting modderator aprouval > on alsa-devel) i don't think i will send more bug reports > to alsa. How long ago was this? alsa-devel has been accepting messages from non-subscribers for at least 6 months. 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: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 12:16:36AM +0100, Dominik Brodowski wrote:
> > Dominik Brodowski <[EMAIL PROTECTED]> wrote:
> > >
> > > Most pcmcia devices are matched to drivers using "product ID strings"
> > > embedded in the devices' Card Information Structures, as "manufactor ID /
> > > card ID" matches are much less reliable. Unfortunately, these strings
> > > cannot
> > > be passed to userspace for easy userspace-based loading of appropriate
> > > modules (MODNAME -- hotplug), so my suggestion is to also store crc32
> > > hashes
> > > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> > >
> > > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
> >
> > What is the difficulty in passing these strings via /sbin/hotplug arguments?
>
> The difficulty is that extracting and evaluating them breaks the wonderful
> bus-independent MODNAME implementation for hotplug suggested by Roman Kagan
> ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these
> strings may contain spaces and other "strange" characters. The latter may be
> worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really
> clean because of this MODNAME implementation:
I think that MODNAME should be replaced with MODALIAS, but that's a
different email thread...
Anyway, hashes are icky, I still don't see why using the string as
module aliases, and fixing up modprobe to handle spaces in module
aliases wouldn't work out easier.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
i386 / sysenter safety test case
Code inspection of entry.S on i386 showed a potential problem - load
through segment without verifying "flatness" on the sysenter path.
Turns out this code is safe, but only by a thread ..
ENTRY(sysenter_entry)
movl TSS_sysenter_esp0(%esp),%esp
sysenter_past_esp:
sti
pushl $(__USER_DS)
pushl %ebp
pushfl
pushl $(__USER_CS)
pushl $SYSENTER_RETURN
/*
* Load the potential sixth argument from user stack.
* Careful about security.
*/
cmpl $__PAGE_OFFSET-3,%ebp
jae syscall_fault
1: movl (%ebp),%ebp
If it weren't for the fact that %ebp relative addresses default to using
the SS segment, we could have loaded through a user segment here to read
arbitrary memory (sysenter does nothing to DS segment). Perhaps this
was considered before, but because of the implications, I thought this
might be worth annotating in the source. Also provided a test case.
Obviously only works on sysenter capable processors. Tested on 2.6.8.
Zach Amsden
[EMAIL PROTECTED]
#include
.text
.global sysenter_call
.global sysenter_call_2
/* void sysenter_call(pid_t pid, int signo, short ds, void *addr) */
sysenter_call:
push %ebx
push %edi
push %ebp
push %ds
movl %esp, %edi
movl 20(%esp), %ebx /* pid */
movl 24(%esp), %ecx /* signo */
movl 28(%esp), %ds/* exploit DS */
movl 32(%esp), %ebp
movl %ebp, %esp
push $sysenter_return
push %ecx
push %edx
subl $16, %ebp
push $0xbaadf00d
movl $SYS_kill, %eax
sysenter
/* vsyscall page will ret to us here */
sysenter_return:
mov %edi, %esp
pop %ds
pop %ebp
pop %edi
pop %ebx
ret
sysenter_call_2:
push %ebx
push %ebp
movl 20(%esp), %ebx /* pid */
movl 24(%esp), %ecx /* signo */
movl 28(%esp), %ebp
movl $SYS_kill, %eax
sysenter
.data
test: .long 0
/*
* Copyright (c) 2005, Zachary Amsden ([EMAIL PROTECTED])
* This is licensed under the GPL.
*/
#include
#include
#include
#include
#include
#include
#include
#define __KERNEL__
#include
extern void sysenter_call(pid_t pid, int signo, short ds, void *addr);
extern void sysenter_call_2(pid_t pid, int signo, void *addr);
void catch_sig(int signo, struct sigcontext ctx)
{
__asm__ __volatile__("mov %0, %%ds" : : "r" (__USER_DS));
printf("interrupted %%ebp = 0x%x\n", ctx.ebp);
if (ctx.ebp == 0xbaadf00d)
printf("phew\n");
}
void main(void)
{
struct user_desc desc;
short ds;
unsigned long addr;
unsigned *stack;
unsigned long offset;
stack = (unsigned *)mmap(0, 4096, PROT_EXEC|PROT_READ|PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
stack = [1024];
addr = 0xf; /* Try to read BIOS */
offset = __PAGE_OFFSET-(unsigned)stack+addr+16;
signal(SIGUSR1, catch_sig);
desc.entry_number = 0;
desc.base_addr = offset;
desc.limit = 0xff;
desc.seg_32bit = 1;
desc.contents = MODIFY_LDT_CONTENTS_DATA;
desc.read_exec_only = 0;
desc.limit_in_pages = 1;
desc.seg_not_present = 0;
desc.useable = 1;
if (modify_ldt(1, , sizeof(desc)) != 0) {
perror("modify_ldt");
}
ds = 0x7; /* TI | RPL 3 */
sysenter_call(getpid(), SIGUSR1, ds, stack);
sysenter_call_2(getpid(), SIGSTOP, __PAGE_OFFSET+4096);
printf("not reached - core should show %%eax == -EFAULT\n");
}
Re: [ patch 4/7] drivers/serial/jsm: new serial device driver
On Tue, Mar 08, 2005 at 03:47:45PM -0600, Kilau, Scott wrote: > > Who needs to know if a port is open or not? > > > > > > > +static ssize_t jsm_tty_baud_show(struct class_device *class_dev, char *buf) > > > No, please delete these, and the other sysfs files that duplicate the > > same info that you can get by using the standard Linux termios calls. > > There is no need for them here. > > Our serial port monitoring tools need to know these things, and to > find them out *without* opening up the serial port to do an ioctl(). > > For example, lets say a customer has a modem connected to a serial port. > > If you were to open up the port with an "stty -a" to get the current > settings and signals, you would unintentionally raise RTS and DTR. Why not fix the driver to not change the current line settings if it is not being opened for the first time? That seems like a much simpler way to solve this, and probably the saner way, as you don't want any user to be able to mess up your modem... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI: One more Asus SMBus quirk
On Tue, Mar 08, 2005 at 05:18:16PM -0500, Bill Davidsen wrote: > Greg KH wrote: > >ChangeSet 1.1998.11.27, 2005/02/25 15:48:28-08:00, [EMAIL PROTECTED] > > > >[PATCH] PCI: One more Asus SMBus quirk > > > >One more Asus laptop requiring the SMBus quirk (W1N model). > > > >Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> > >Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > Hopefully this and the double-free patch will be included in 2.6.11.n+1? what double-free patch? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ patch 4/7] drivers/serial/jsm: new serial device driver
On Tue, Mar 08, 2005 at 01:55:33PM -0500, Wen Xiong wrote:
> +static ssize_t jsm_driver_boards_show(struct device_driver *ddp, char *buf)
> +{
> + int adapter_count = 0;
> + adapter_count = jsm_total_boardnum();
> + return snprintf(buf, PAGE_SIZE, "%d\n", adapter_count);
> +}
> +static DRIVER_ATTR(boards, S_IRUSR, jsm_driver_boards_show, NULL);
Why is this file even needed? You can just look at the number of sysfs
directories attached to this device, right?
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-mm2
On Tue, Mar 08, 2005 at 03:38:46AM -0800, Andrew Morton wrote: >... > Changes since 2.6.11-mm1: >... > -fix-buggy-ieee80211_crypt_-selects.patch > > Was wrong. >... I'd say my patch was correct. If it was buggy, I have yet to see a better patch. With the current dependencies, IEEE80211_CRYPT_CCMP and IEEE80211_CRYPT_TKIP can't be included into Linus' tree since selecting them can result in invalid .config's [1]. cu Adrian [1] no matter how you think to be guilty - from a user's point of view it's simply currently broken -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-mm2
On Tue, Mar 08, 2005 at 03:38:46AM -0800, Andrew Morton wrote: >... > Changes since 2.6.11-mm1: >... > +drivers-isdn-tpam-convert-to-pci_register_driver.patch >... > Little code tweaks. >... Please drop this patch. Karsten has a patch ready to remove this driver (because the hardware it was supposed to drive never went into production), and such patches only cause needless rediffs. @Karsten: Could you submit your patch to remove tpam to Andrew? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VGA arbitration: draft of kernel side
On Tue, 2005-03-08 at 18:47 -0500, Jon Smirl wrote: > This very similar to the reset support patch I have been working on. > > In the reset patch there is a 'vga' attribute on each VGA device. Set > it to 0/1 to make the device active. This lets you move the console > around betweem VGA devices. > > You can also set it to 3, which disables all VGA devices but remembers > the active one. Setting it to 4 disables all VGA devices then restores > the active one. To use, set it to 3, post, set it to 4. > > GregKH wants this code out of the pci directory but it needs hooks > into pci_destroy_dev() to delete the arbiter. You also need a hook on > add for when a hotplug device appears. > > I'll try merging my sysfs support into your code. Please wait. I don't want that semantic for sysfs. First, I don't want to "move around" the VGA device. This is very arch specific and will not work in a variety if circumstances. Also, "outb's" to legacy VGA ports will only work with some PCI domains on archs like PPC, even vgacon can't deal with that, so let's avoid putting such "knowledge" in the arbiter itself. I prefer for now defining a "default" vga device which is the one used by vgacon. If you want to move vgacon around, do some arch specific stuff or add way to change the default device, but that isn't directly related to the arbitration process. Also, I want the sysfs entry (or /dev if I can't get the proper semantics in sysfs) to have open & release() callbacks like a char device. The reason is that I want the vga "locks" owned by a process to be automatically released if the process dies. Without that, kill -9 on X will end up requiring a reboot in most circumstances :) Finally, I want to keep the distinction between memory and IO enables. That's quite important imho, since a lot of cards can operate with IO disabled (all ATIs for example), which is good as I'm not completely sure I can disable legacy IO port decoding on them (well, I don't know how to do it). Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-mm2
On 03.09, Robert Love wrote: > On Tue, 2005-03-08 at 23:36 +, J.A. Magallon wrote: > > > Can cpu affinity really be changed for a running process ? > > Yes. > > > Does it need something like io or yielding to take effect ? > > No. > ... > > Although, you have the syntax wrong. It should be > > taskset -c 0 -p 8277 > That was what I first tried, but: werewolf:~> ps -ef | grep box magallon 8638 8629 99 00:47 pts/000:01:54 box-d --out box.srf @opt magallon 8733 8643 0 00:48 pts/200:00:00 grep box werewolf:~> taskset -c 0 -p 8638 execvp: No such file or directory failed to execute -p > > > The program uses posix threads, 2 in this case. The two threads change from > > cpu sometimes (not too often), but do not go into the same processor > > immediately as when I start the program directly with runon/taskset. > > You have to bind all of the threads individually. > Ahh, damn, that explains it. I use a main thread that does nothing but wait for the worker threads. So it sure gets moved to CPU0, but as it does not waste CPU time, I do not see it... Thanks. Will see what can I do with my threads. cpusets, perhaps... -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Cooker) for i586 Linux 2.6.11-jam3 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #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: RFD: Kernel release numbering
On Wed, 2005-03-09 at 00:25 +0100, szonyi calin wrote: > I reported once a bug on alsa-devel and cc-ed on lkml > The sequencer isn't working with my card cs4239 with alsa. > What exactly do you mean by "it isn't working"? 90% of "MIDI does not work" bug reports are from users who expect playing MIDI files to work OOTB like it does on Mac and Windows. This only works because those OS'es come bundled with a toy softsynth. With ALSA, you either need a supported hardware wavetable synth (emu10k1) or a real soft synth like Timidity or Fluidsynth. Anyway, please repost your bug report to alsa-devel. There is no point in cc'ing LKML for ALSA problems, unless you find a problem like a regression in ALSA functionality from one kernel release to another. 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/
