Re: [Fastboot] Re: kdump on non-boot cpu
Itsuro Oda <[EMAIL PROTECTED]> writes: > > So I believe the fix needs to be to enable apics before we calibrate > > the delay timer. I'm not certain off the top of my head what that > > patch will look like but it should not be fundamentally hard. > > With that code in place we also don't need to do any APIC shutdown > > as the kernel knows enough to completely setup the apics. > > I see. Thank you for your explanation. I have done a bit more digging. For some reason, likely historical we don't initialize the IO_APIC in init_IRQ(). Instead we wait until smp_prepare_cpus() or smp_init(). Both functions are called much later in the init process than calibrate_delay(). Given the separation that has happened between apics and SMP it should be possible to initialize the local apic and the IO_APIC of the boot cpu much earlier in the game. It looks like it may take some heavy lifting though. 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/
2.6.11-rc3-mm1 bad scheduling while atomic + lockup
Hello,
I just want to report a lockup on my 2.6.11-rc3-mm1 machine.
I was working on it via ssh and suddenly the machine stopped
responding. When, the next day I came up to the console
it was printing over and over this oops.
In the logs I could find the oops. I am posting it inline here
along with some logs before that (maybe it is related)
Feb 6 17:07:47 dns kernel: hdc: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 6 17:07:47 dns kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC
}
Feb 6 17:07:47 dns kernel: ide: failed opcode was: unknown
Feb 6 17:07:47 dns kernel: hdc: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 6 17:07:47 dns kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC
}
Feb 6 17:07:47 dns kernel: ide: failed opcode was: unknown
Feb 6 17:07:47 dns kernel: hdc: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 6 17:07:47 dns kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC
}
Feb 6 17:07:47 dns kernel: ide: failed opcode was: unknown
Feb 6 17:07:47 dns kernel: hdc: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 6 17:07:47 dns kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC
}
Feb 6 17:07:47 dns kernel: ide: failed opcode was: unknown
Feb 6 17:07:47 dns kernel: scheduling while atomic: swapper/0x00010001/0
Feb 6 17:07:47 dns kernel: [schedule+1379/1392] schedule+0x563/0x570
Feb 6 17:07:47 dns kernel: [__call_console_drivers+87/96]
__call_console_drivers+0x57/0x60
Feb 6 17:07:47 dns kernel: [__mod_timer+350/480] __mod_timer+0x15e/0x1e0
Feb 6 17:07:47 dns kernel: [schedule_timeout+99/192]
schedule_timeout+0x63/0xc0
Feb 6 17:07:47 dns kernel: [process_timeout+0/16] process_timeout+0x0/0x10
Feb 6 17:07:47 dns kernel: [ide_pin_hwgroup+97/208] ide_pin_hwgroup+0x61/0xd0
Feb 6 17:07:47 dns kernel: [ide_set_xfer_rate+28/96]
ide_set_xfer_rate+0x1c/0x60
Feb 6 17:07:47 dns kernel: [check_dma_crc+72/112] check_dma_crc+0x48/0x70
Feb 6 17:07:47 dns kernel: [do_reset1+99/544] do_reset1+0x63/0x220
Feb 6 17:07:47 dns kernel: [ide_do_reset+23/32] ide_do_reset+0x17/0x20
Feb 6 17:07:47 dns kernel: [ide_error+143/160] ide_error+0x8f/0xa0
Feb 6 17:07:47 dns kernel: [ide_dma_intr+91/192] ide_dma_intr+0x5b/0xc0
Feb 6 17:07:47 dns kernel: [ide_dma_intr+0/192] ide_dma_intr+0x0/0xc0
Feb 6 17:07:47 dns kernel: [ide_intr+246/432] ide_intr+0xf6/0x1b0
Feb 6 17:07:47 dns kernel: [handle_IRQ_event+48/112]
handle_IRQ_event+0x30/0x70
Feb 6 17:07:47 dns kernel: [__do_IRQ+230/352] __do_IRQ+0xe6/0x160
Feb 6 17:07:47 dns kernel: [__do_softirq+120/144] __do_softirq+0x78/0x90
Feb 6 17:07:47 dns kernel: [do_IRQ+35/64] do_IRQ+0x23/0x40
Feb 6 17:07:47 dns kernel: [common_interrupt+26/32] common_interrupt+0x1a/0x20
Feb 6 17:07:47 dns kernel: [default_idle+35/48] default_idle+0x23/0x30
Feb 6 17:07:47 dns kernel: [cpu_idle+72/96] cpu_idle+0x48/0x60
Feb 6 17:07:47 dns kernel: [start_kernel+338/368] start_kernel+0x152/0x170
Feb 6 17:07:47 dns kernel: [unknown_bootoption+0/432]
unknown_bootoption+0x0/0x1b0
Best Regards
Maciej
This is my .config:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.11-rc3-mm1
# Fri Feb 4 19:41:09 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_BASE_FULL=y
CONFIG_BASE_SMALL=0
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON
Re: COMMAND_LINE_SIZE increasing in 2.6.11-rc1-bk6
Andi Kleen wrote: > It's dependent on the architecture already. I would like to enable > it on i386/x86-64 because the kernel command line is often used > to pass parameters to installers, and having a small limit there > can be awkward. Something to keep in mind when extending the command line is that we'll probably need a mechanism for passing additional (and possibly large) data blocks from the boot loader soon. The reason for this is that, if booting through kexec, it would be attractive to pass device scan results, so that the second kernel doesn't have to repeat the work. As an obvious extension, anyone who wants to boot *quickly* could also pass such data from persistent storage without actually performing the device scan at all when the machine is booted. The command line may be suitable for this, but to allow for passing a lot of data, its place in memory should perhaps just be reserved, at least until the system has passed initialization, without trying to copy it to a "safe" place early in kernel startup. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.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: [PATCH] Linux joydev joystick disconnect patch 2.6.11-rc2
On Sun, Feb 06, 2005 at 08:21:13PM -0500, Dmitry Torokhov wrote:
> On Sunday 06 February 2005 08:12, Vojtech Pavlik wrote:
> > On Tue, Feb 01, 2005 at 10:24:39AM -0500, Dmitry Torokhov wrote:
> > > On Tue, 1 Feb 2005 08:52:15 -0600, David Fries <[EMAIL PROTECTED]> wrote:
> > > > Currently a blocking read, select, or poll call will not return if a
> > > > joystick device is unplugged. This patch allows them to return.
> > > >
> > > ...
> > > > static unsigned int joydev_poll(struct file *file, poll_table *wait)
> > > > {
> > > > + int mask = 0;
> > > > struct joydev_list *list = file->private_data;
> > > > poll_wait(file, >joydev->wait, wait);
> > > > - if (list->head != list->tail || list->startup <
> > > > list->joydev->nabs + list->joydev->nkey)
> > > > - return POLLIN | POLLRDNORM;
> > > > - return 0;
> > > > + if(!list->joydev->exist)
> > > > + mask |= POLLERR;
> > >
> > > Probably need POLLHUP in addition (or instead of POLLERR).
> > >
> > > > if (joydev->open)
> > > > + {
> > > > input_close_device(handle);
> > > > + wake_up_interruptible(>wait);
> > > > + }
> > > > else
> > > > + {
> > > > joydev_free(joydev);
> > > > + }
> > >
> > > Opening braces should go on the same line as the statement (if (...) {).
> >
> > How about this patch?
>
> Looks fine now. Hmm, wait a sec... Don't we also need kill_fasync calls in
> disconnect routines as well?
Yes, we do.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: msdos/vfat defaults are annoying
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/2005 09:36 AM, Al Viro wrote: > On Mon, Feb 07, 2005 at 12:21:08AM +0100, Pozsar Balazs wrote: > >>On Sun, Feb 06, 2005 at 07:06:59AM +, Christoph Hellwig wrote: >> >>>On Sun, Feb 06, 2005 at 12:33:43AM -0500, John Richard Moser wrote: >>> I dunno. I can never understand the innards of the kernel devs' minds. >>> >>>filesystem detection isn't handled at the kerne level. >> >>Yeah, but the link order could be changed... Patch inlined. > > > And just what does the link order (or changes thereof) have to do with that? because some distributions (eg gentoo) make a symlink to /proc/filesystems jupiter root # ls -l /etc/filesystems lrwxrwxrwx 1 root root 19 Oct 25 11:18 /etc/filesystems -> ../proc/filesystems and then its impossible to change the order. (unless you make a "hand made" file of course). - -- [ Clemens Schwaighofer -=:~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCBxBLjBz/yQjBxz8RAsCXAKCHwURn6UJjrtEOhjaXHa0min94NQCdFlBa EgBrVpGuASFNepZigjV1p5E= =ol2B -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6: USB disk unusable level of data corruption
On Sun, 2005-02-06 at 21:15 -0800, David Brownell wrote: > And I didn't see an "unusual_devs.h" entry for it, but it does > look to need the CONFIG_USB_STORAGE_HP8200e support, which I > see is labeled "experimental". I don't know how solid the > support for that is. But I see Greg's checked in a big patch > against the file with that driver, which should make the next > MM patchset against 2.6.11-rc3 ... mostly to support some > new hardware, but with that many changes I suspect there'll > be some bugfixes too. OK, I'll check once that comes through, thanks. > This would be www.macpower.com.tw/produts/hdd2/daisycutter/dc_usb2 > maybe? The www.qbik.ch/usb/devices database has a report from one > user saying they had problems with a different MacPower adapter until > they fixed its jumpers. Also worth a check. Actually, it's http://www.macpower.com.tw/products/hdd2/clearlight/cl_400plus I didn't put the drive in myself, but I'll unscrew it and check the jumpers. A simple DIRECT_IO 4096-byte read-write on the block device does reveal corruption after an hour or so, so I should be able to track this down. Might move my home dir back off it for a while though 8) Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
out-of-line x86 "put_user()" implementation
I was looking at some of the code we generate, and happened to notice that we have this strange situation where the x86 "get_user()" macros generate out-of-line code to do all the address verification etc, but the "put_user()" ones do not, and do everything inline. I also noticed that (probably as a result of this), our "put_user()" on old i386 machines does not do the full magic manual page-following. Which means that copy-on-write doesn't necessarily work right due to the broken paging hw on the original 386 core. I didn't fix the second part, but at least making things out-of-line makes it possible. And making "put_user()" be out-of-line seemed quite doable. I no longer use x86 as my main machine, so this patch is totally untested. I've compiled it to see that things look somewhat sane, but that doesn't mean much. If I forgot some register or screwed something else up, this will result in a totally nonworking kernel, but I thought that maybe somebody else would be interested in looking at whether this (a) works, (b) migth even shrink the kernel and (c) might make us able to DTRT wrt the page table following crud (old i386 cores may be hard to find these days, so maybe people don't care). Linus # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/02/06 22:10:04-08:00 [EMAIL PROTECTED] # x86: make "put_user()" be out-of-line # # It's really too big to be inlined. # # arch/i386/lib/putuser.S # 2005/02/06 22:09:53-08:00 [EMAIL PROTECTED] +87 -0 # # include/asm-i386/uaccess.h # 2005/02/06 22:09:53-08:00 [EMAIL PROTECTED] +27 -3 # x86: make "put_user()" be out-of-line # # It's really too big to be inlined. # # arch/i386/lib/putuser.S # 2005/02/06 22:09:53-08:00 [EMAIL PROTECTED] +0 -0 # BitKeeper file /home/torvalds/v2.6/linux/arch/i386/lib/putuser.S # # arch/i386/lib/Makefile # 2005/02/06 22:09:53-08:00 [EMAIL PROTECTED] +1 -1 # x86: make "put_user()" be out-of-line # # It's really too big to be inlined. # # arch/i386/kernel/i386_ksyms.c # 2005/02/06 22:09:53-08:00 [EMAIL PROTECTED] +5 -0 # x86: make "put_user()" be out-of-line # # It's really too big to be inlined. # diff -Nru a/arch/i386/kernel/i386_ksyms.c b/arch/i386/kernel/i386_ksyms.c --- a/arch/i386/kernel/i386_ksyms.c 2005-02-06 22:12:01 -08:00 +++ b/arch/i386/kernel/i386_ksyms.c 2005-02-06 22:12:01 -08:00 @@ -97,6 +97,11 @@ EXPORT_SYMBOL(__get_user_2); EXPORT_SYMBOL(__get_user_4); +EXPORT_SYMBOL(__put_user_1); +EXPORT_SYMBOL(__put_user_2); +EXPORT_SYMBOL(__put_user_4); +EXPORT_SYMBOL(__put_user_8); + EXPORT_SYMBOL(strpbrk); EXPORT_SYMBOL(strstr); diff -Nru a/arch/i386/lib/Makefile b/arch/i386/lib/Makefile --- a/arch/i386/lib/Makefile2005-02-06 22:12:01 -08:00 +++ b/arch/i386/lib/Makefile2005-02-06 22:12:01 -08:00 @@ -3,7 +3,7 @@ # -lib-y = checksum.o delay.o usercopy.o getuser.o memcpy.o strstr.o \ +lib-y = checksum.o delay.o usercopy.o getuser.o putuser.o memcpy.o strstr.o \ bitops.o lib-$(CONFIG_X86_USE_3DNOW) += mmx.o diff -Nru a/arch/i386/lib/putuser.S b/arch/i386/lib/putuser.S --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/arch/i386/lib/putuser.S 2005-02-06 22:12:01 -08:00 @@ -0,0 +1,87 @@ +/* + * __put_user functions. + * + * (C) Copyright 2005 Linus Torvalds + * + * These functions have a non-standard call interface + * to make them more efficient, especially as they + * return an error value in addition to the "real" + * return value. + */ +#include + + +/* + * __put_user_X + * + * Inputs: %eax[:%edx] contains the data + * %ecx contains the address + * + * Outputs:%eax is error code (0 or -EFAULT) + * %ecx is corrupted + * + * These functions should not modify any other registers, + * as they get called from within inline assembly. + */ + +#define ENTER pushl %ecx ; pushl %ebx ; GET_THREAD_INFO(%ebx) +#define EXIT popl %ebx ; popl %ecx ; ret + +.text +.align 4 +.globl __put_user_1 +__put_user_1: + ENTER + cmpl TI_addr_limit(%ebx),%ecx + jae bad_put_user +1: movb %al,(%ecx) + xorl %eax,%eax + EXIT + +.align 4 +.globl __put_user_2 +__put_user_2: + ENTER + addl $1,%ecx + jc bad_put_user + cmpl TI_addr_limit(%ebx),%ecx + jae bad_put_user +2: movw %ax,-1(%ecx) + xorl %eax,%eax + EXIT + +.align 4 +.globl __put_user_4 +__put_user_4: + ENTER + addl $3,%ecx + jc bad_put_user + cmpl TI_addr_limit(%ebx),%ecx + jae bad_put_user +3: movl %eax,-3(%ecx) + xorl %eax,%eax + EXIT + +.align 4 +.globl __put_user_8 +__put_user_8: + ENTER + addl $7,%ecx + jc bad_put_user + cmpl TI_addr_limit(%ebx),%ecx + jae bad_put_user +3: movl %eax,-7(%ecx) +4: movl %edx,-3(%ecx) + xorl %eax,%eax + EXIT + +bad_put_user: + movl $-14,%eax + EXIT + +.section __ex_table,"a" + .long 1b,bad_put_user +
How to read file in kernel module?
Hello, I have written one /proc file creation kernel module. This module creates /proc/file and defied operations on it. Also i have written user program that will read & write to /proc files from user space. Now what i want is to use same bufproc_read & bufproc_write functions defined in /proc file handling kernel module to be used in another kernel module to read that /proc/file in kernel module.The second kernel module only used to read /proc file in kernel. I am not understanding how can i open that /proc/file in second kenrel module to read in kernel? regards, linux_lover. __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.4.21 gives kernel panic at boot time
Hi, I have compiled the kerne 2.4.21. Compilation went well. but i got follwing message at boot time. = . . /lib/mptscsih.o : unresolved symbol mpt_deregister_Rsmp_6fb5ab71 /lib/mptscsih.o : Unresolved symbol mpt_event_register_Rsmp_34ace96b ERROR : /bin/insmod exited abnormally Mounting /proc filesystem Creating block devices VFS : cannot open root device "LABEL=/ or 00:00 Please append corrrect "root=" boot option Kernel panic : VFS : Unable to mount root fs on 00:00 === I have following lines in my elilo.conf , -- #original kernel image=vmlinuz-2.4.21-9.EL label=linux initrd=initrd-2.4.21-9.EL.img read-only append="root=LABEL=/" #icc-O2 image=iccvmlinux label=icc_O2 initrd=iccinitrd-preBasicc.img read-only append="root=LABEL=/" --- First one works fine. Any clues why i am getting this error. Is it related to SCSI Driver ? Further "/sbin/mkinitrd -f -v " gave follwing messge, == . . . Looking for deps of module scsi_mod Looking for deps of module sd_mod Looking for deps of module unknown Looking for deps of module mptbase Looking for deps of module mptscsih mptbase Looking for deps of module mptbase Looking for deps of module ide-disk Looking for deps of module ext3 Using modules: ./kernel/drivers/message/fusion/mptbase.o ./kernel/drivers/message/fusion/mptscsih.o Using loopback device /dev/loop0 /sbin/nash -> /tmp/initrd.EsIvQ9/bin/nash /sbin/insmod.static -> /tmp/initrd.EsIvQ9/bin/insmod `/lib/modules/2.4.21preBasicc/./kernel/drivers/message/fusion/mptbase.o' -> `/tmp/initrd.EsIvQ9/lib/mptbase.o' `/lib/modules/2.4.21preBasicc/./kernel/drivers/message/fusion/mptscsih.o' -> `/tmp/initrd.EsIvQ9/lib/mptscsih.o' Loading module mptbase Loading module mptscsih === Any clues will be great help ? Thanx, Baswaraj __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Generating NLS modules
Nobody answered so i repeat the question. I think i found a way to make use of NLS table for HFS filesystem and i'm going to try to implement it. But first i need to create NLS module for codepage 10007 (Mac cyrillic). In the beginning of every existing NLS module code i see comment which says that this file is automatically generated from data found at unicode.org. Could you tell me where i can find a convertor and what data it can use as input? I explored unicode.org and found some conversion data at oss.software.ibm.com/icu/. The data is available in UCM and XML formats. Are those files suitable? -- Best regards, Pavel Fedin, mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/RFT] Better handling of bad xfers/interrupt delays in psmouse
On Sun, Feb 06, 2005 at 12:55:00PM -0500, Dmitry Torokhov wrote: > > Hmm, wouldn't it be nice if they put spell checker in GCC? ;) Isn't the resulting beast called "emacs"? -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] module-init-tools: generate modules.seriomap
On Sunday 06 February 2005 22:41, Rusty Russell wrote:
> On Sun, 2005-02-06 at 02:55 -0500, Dmitry Torokhov wrote:
> > Hi Rusty,
> >
> > I have converted serio bus to use ID matching and changed serio drivers
> > to use MODULE_DEVICE_TABLE. Now that Vojtech pulled the changes into his
> > tree it would be nice if official module-init-tools generated the module
> > map so that hotplug scripts could automatically load proper drivers.
>
> Sure, applied.
Thanks!
> I would appreciated tests, however: you can download the
> testsuite from the same place you get module-init-tools. I don't expect
> you to be able to compile for all endian/size combinations, but I can do
> that for you.
Ok, I will take a look at it but it will take couple of days...
> You should also put the logic into the kernel's scripts/mod/file2alias,
> which is where this is supposed to go these days (I haven't removed the
> modules.XXX files, since hotplug has enough deployment problems without
> me making things worse).
Oh, I see. I wasn't sure where it should go and FC3 hotplug uses modules.*map
so I went that route. What do you think about the patch below then?
I am a little bit confused - is anybody using module aliases at the moment?
I could not find anything on my box...
--
Dmitry
===
[EMAIL PROTECTED], 2005-02-07 00:14:52-05:00, [EMAIL PROTECTED]
Input: adjust file2alias utility to export aliases for
serio drivers (serio:tyNprNidNexN).
Move serio_device_id from serio.h to mod_devicetable.h
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
include/linux/mod_devicetable.h | 10 ++
include/linux/serio.h | 10 +-
scripts/mod/file2alias.c| 23 ++-
3 files changed, 33 insertions(+), 10 deletions(-)
===
diff -Nru a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
--- a/include/linux/mod_devicetable.h 2005-02-07 00:15:11 -05:00
+++ b/include/linux/mod_devicetable.h 2005-02-07 00:15:11 -05:00
@@ -165,4 +165,14 @@
};
+#define SERIO_ANY 0xff
+
+struct serio_device_id {
+ __u8 type;
+ __u8 extra;
+ __u8 id;
+ __u8 proto;
+};
+
+
#endif /* LINUX_MOD_DEVICETABLE_H */
diff -Nru a/include/linux/serio.h b/include/linux/serio.h
--- a/include/linux/serio.h 2005-02-07 00:15:11 -05:00
+++ b/include/linux/serio.h 2005-02-07 00:15:11 -05:00
@@ -19,13 +19,7 @@
#include
#include
#include
-
-struct serio_device_id {
- unsigned char type;
- unsigned char extra;
- unsigned char id;
- unsigned char proto;
-};
+#include
struct serio {
void *port_data;
@@ -173,8 +167,6 @@
#define SERIO_TIMEOUT 1
#define SERIO_PARITY 2
#define SERIO_FRAME4
-
-#define SERIO_ANY 0xff
/*
* Serio types
diff -Nru a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
--- a/scripts/mod/file2alias.c 2005-02-07 00:15:11 -05:00
+++ b/scripts/mod/file2alias.c 2005-02-07 00:15:11 -05:00
@@ -4,7 +4,7 @@
*
* Copyright 2002-2003 Rusty Russell, IBM Corporation
* 2003 Kai Germaschewski
- *
+ *
*
* This software may be used and distributed according to the terms
* of the GNU General Public License, incorporated herein by reference.
@@ -181,6 +181,24 @@
return 1;
}
+/* Looks like: "serio:tyNprNidNexN" */
+static int do_serio_entry(const char *filename,
+ struct serio_device_id *id, char *alias)
+{
+ id->type = TO_NATIVE(id->type);
+ id->proto = TO_NATIVE(id->proto);
+ id->id = TO_NATIVE(id->id);
+ id->extra = TO_NATIVE(id->extra);
+
+ strcpy(alias, "serio:");
+ ADD(alias, "ty", id->type != SERIO_ANY, id->type);
+ ADD(alias, "pr", id->proto != SERIO_ANY, id->proto);
+ ADD(alias, "id", id->id != SERIO_ANY, id->id);
+ ADD(alias, "ex", id->extra != SERIO_ANY, id->extra);
+
+ return 1;
+}
+
/* looks like: "pnp:dD" */
static int do_pnp_entry(const char *filename,
struct pnp_device_id *id, char *alias)
@@ -270,6 +288,9 @@
else if (sym_is(symname, "__mod_ccw_device_table"))
do_table(symval, sym->st_size, sizeof(struct ccw_device_id),
do_ccw_entry, mod);
+ else if (sym_is(symname, "__mod_serio_device_table"))
+ do_table(symval, sym->st_size, sizeof(struct serio_device_id),
+do_serio_entry, mod);
else if (sym_is(symname, "__mod_pnp_device_table"))
do_table(symval, sym->st_size, sizeof(struct pnp_device_id),
do_pnp_entry, mod);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [linux-usb-devel] 2.6: USB disk unusable level of data corruption
On Sunday 06 February 2005 6:55 pm, Rusty Russell wrote: > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize064 > idVendor 0x0dc4 Macpower Peripherals, Ltd > idProduct 0x00c4 > bcdDevice0.02 > iManufacturer 1 Macpower > iProduct2 2.5HDD > iSerial 3 8000D1 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 32 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 4 Myson 8818 Not one I'd be familiar with, but that doesn't mean anything. And I didn't see an "unusual_devs.h" entry for it, but it does look to need the CONFIG_USB_STORAGE_HP8200e support, which I see is labeled "experimental". I don't know how solid the support for that is. But I see Greg's checked in a big patch against the file with that driver, which should make the next MM patchset against 2.6.11-rc3 ... mostly to support some new hardware, but with that many changes I suspect there'll be some bugfixes too. This would be www.macpower.com.tw/produts/hdd2/daisycutter/dc_usb2 maybe? The www.qbik.ch/usb/devices database has a report from one user saying they had problems with a different MacPower adapter until they fixed its jumpers. Also worth a check. - Dave > bmAttributes 0xc0 > Self Powered > MaxPower 10mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 8 Mass Storage > bInterfaceSubClass 5 SFF-8070i > bInterfaceProtocol 80 > iInterface 5 USB2.0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x03 EP 3 OUT > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x84 EP 4 IN > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Device Qualifier (for other device speed): > bLength10 > bDescriptorType 6 > bcdUSB 2.00 > bDeviceClass0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize064 > bNumConfigurations 1 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 04/09] ide: convert REQ_DRIVE_TASK to REQ_DRIVE_TASKFILE
Bartlomiej Zolnierkiewicz wrote:
I put some more thought into this change... details below...
On Sat, 5 Feb 2005 11:15:56 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote:
@@ -705,24 +705,17 @@ static int idedisk_issue_flush(request_q
{
ide_drive_t *drive = q->queuedata;
struct request *rq;
+ ide_task_t args;
int ret;
ide_task_t task please
Okay.
@@ -730,8 +723,9 @@ static int idedisk_issue_flush(request_q
* if we failed and caller wants error offset, get it
*/
if (ret && error_sector)
- *error_sector = ide_get_error_location(drive, rq->cmd);
+ *error_sector = ide_get_error_location(drive, );
+ rq->special = NULL; /* just in case */
In what case?
As the request is allocated and freed by the generic block layer, I
was kinda worrying about cases where the request outlives
blk_put_request() and somehow somebody accesses ->special. Probably
unnecessary but dangling pointers pointing stack area really scares me.
@@ -55,22 +55,19 @@
#include
#include
-static void ide_fill_flush_cmd(ide_drive_t *drive, struct request *rq)
+void ide_init_flush_task(ide_drive_t *drive, ide_task_t *args)
ide_task_t *task
@@ -80,7 +77,9 @@ static void ide_fill_flush_cmd(ide_drive
static struct request *ide_queue_flush_cmd(ide_drive_t *drive,
struct request *rq, int post)
{
- struct request *flush_rq = (drive)->wrq;
+ ide_hwgroup_t *hwgroup = drive->hwif->hwgroup;
+ struct request *flush_rq = >flush_rq;
+ ide_task_t *args = >flush_args;
ide_task_t *task
@@ -221,41 +223,37 @@ static void ide_complete_pm_request (ide
/*
* FIXME: probably move this somewhere else, name is bad too :)
*/
-u64 ide_get_error_location(ide_drive_t *drive, char *args)
+u64 ide_get_error_location(ide_drive_t *drive, ide_task_t *args)
ide_task_t *task
{
u32 high, low;
u8 hcyl, lcyl, sect;
- u64 sector;
- high = 0;
- hcyl = args[5];
- lcyl = args[4];
- sect = args[3];
-
- if (ide_id_has_flush_cache_ext(drive->id)) {
- low = (hcyl << 16) | (lcyl << 8) | sect;
- HWIF(drive)->OUTB(drive->ctl|0x80, IDE_CONTROL_REG);
- high = ide_read_24(drive);
- } else {
- u8 cur = HWIF(drive)->INB(IDE_SELECT_REG);
- if (cur & 0x40)
- low = (hcyl << 16) | (lcyl << 8) | sect;
- else {
- low = hcyl * drive->head * drive->sect;
- low += lcyl * drive->sect;
- low += sect - 1;
- }
- }
+ if (ide_id_has_flush_cache_ext(drive->id) &&
+ (drive->capacity64 >= (1UL << 28)))
Please just use if (drive->addressing), it is simpler and still correct.
Since we are now using ide_task_t 'high' will be 0 when
ide_id_has_flush_cache() == 0 and drive->addressing == 1
(such combination is unlikely but...). Also thanks to this change
ide_get_error_location() becomes a really *generic* helper and
can be later used by other code.
Sure.
@@ -1201,9 +1224,14 @@ extern ide_startstop_t ide_do_reset (ide
extern void ide_init_drive_cmd (struct request *rq);
/*
+ * This function initializes @task to WIN_FLUSH_CACHE[_EXT] command.
+ */
+void ide_init_flush_task(ide_drive_t *drive, ide_task_t *args);
comment is wrong and not needed,
void ide_init_flush_task(ide_drive_t *, ide_task_t *);
should be enough
Okay.
There is one problem left with this change - FLUSH_CACHE_{EXT}
command handling becomes slower for drive's supporting LBA48
(also next patches make ide_{task,cmd}_ioctl() slower). Why is so?
See do_rw_taskfile(), HOB registers are written/read unconditionally
if (drive->addressing == 1). This can be fixed by i.e. adding
'unsigned long flags' to ide_task_t and IDE_TASK_LBA48 flag.
BTW this fix is needed also to implement LBA48 optimization for
read/write requests (not writing HOB registers when not needed).
IMHO there are some things worth mentioning in the patch description,
do_rw_taskfile() vs execute_drive_cmd()+ide_cmd() details:
some registers are written now in different order and timeout is bumped
(these changes shouldn't make any harm but I'm paranoid :).
Yeah, sure.
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 05/09] ide: map ide_task_ioctl() to ide_taskfile_ioctl()
Bartlomiej Zolnierkiewicz wrote: On Sat, 5 Feb 2005 11:15:56 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote: - int err = 0; - u8 args[7], *argbuf = args; - int argsize = 7; + u8 args[7]; + ide_task_t task; + task_ioreg_t *regs = task.tfRegister; u8 *regs please Sure. + int ret; What is the reason for changing the name of variable (other than making the patch bigger ;) ? Heh, Heh, I thought I could get away with it. I'll restore it. :-) Please also read comments to patch #4. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 08/09] ide: map ide_cmd_ioctl() to ide_taskfile_ioctl()
Bartlomiej Zolnierkiewicz wrote:
I have not fully reviewed it yet but I've noticed two things...
@@ -648,11 +648,11 @@ u8 eighty_ninty_three (ide_drive_t *driv
EXPORT_SYMBOL(eighty_ninty_three);
-int ide_ata66_check (ide_drive_t *drive, ide_task_t *args)
+int ide_ata66_check(ide_drive_t *drive, task_ioreg_t *regs)
{
- if ((args->tfRegister[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
- (args->tfRegister[IDE_SECTOR_OFFSET] > XFER_UDMA_2) &&
- (args->tfRegister[IDE_FEATURE_OFFSET] == SETFEATURES_XFER)) {
+ if (regs[IDE_COMMAND_OFFSET] == WIN_SETFEATURES &&
+ regs[IDE_SECTOR_OFFSET] > XFER_UDMA_2 &&
+ regs[IDE_FEATURE_OFFSET] == SETFEATURES_XFER) {
#ifndef CONFIG_IDEDMA_IVB
if ((drive->id->hw_config & 0x6000) == 0) {
#else /* !CONFIG_IDEDMA_IVB */
What is the rationale for this change?
ide_task_t is available in ide_cmd_ioctl().
Sorry, it was for the previous map to ide_taskfile_ioctl()
implementation, where ide_cmd_ioctl() didn't have ide_task_t. I'll
restore it. Also, I've forgot to update the description of this patch.
I'll fix that too.
@@ -678,11 +678,11 @@ int ide_ata66_check (ide_drive_t *drive,
* 1 : Safe to update drive->id DMA registers.
* 0 : OOPs not allowed.
*/
-int set_transfer (ide_drive_t *drive, ide_task_t *args)
+int set_transfer(ide_drive_t *drive, task_ioreg_t *regs)
{
- if ((args->tfRegister[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
- (args->tfRegister[IDE_SECTOR_OFFSET] >= XFER_SW_DMA_0) &&
- (args->tfRegister[IDE_FEATURE_OFFSET] == SETFEATURES_XFER) &&
+ if (regs[IDE_COMMAND_OFFSET] == WIN_SETFEATURES &&
+ regs[IDE_SECTOR_OFFSET] >= XFER_SW_DMA_0 &&
+ regs[IDE_FEATURE_OFFSET] == SETFEATURES_XFER &&
(drive->id->dma_ultra ||
drive->id->dma_mword ||
drive->id->dma_1word))
ditto
ditto. :-)
+ io_32bit = drive->io_32bit;
+ drive->io_32bit = 0;/* racy */
+ ret = ide_diag_taskfile(drive, , in_size, buf);
+ drive->io_32bit = io_32bit;
It wasn't racy before this patch. I know that it is like that
in ide_taskfile_ioctl() but it is not an excuse for propagating
the bug. It can be easily fixed if you use drive_cmd_intr()
instead of task_in_intr() as task->handler.
Fixing the race condition in taskfile ioctl was on my to-do list, so I
was thinking unifying the problem wouldn't be bad such that it can be
fixed together later (soon). I think I can make a patch to fix taskfile
ioctl first and then submit this patch again without the race.
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] relayfs crash
On Sun, Feb 06, 2005 at 10:42:27PM -0600, Tom Zanussi wrote: > Kingsley Cheung writes: > > > > To solve the problem I applied a patch similar to the one you posted > > back in July and it fixed the problem. Could we consider putting this > > patch into relayfs? Its similar to the one posted in July 2004, except > > it also moves clear_readers() before INIT_WORK in relay_release (is > > that acceptable?). > > > > Yes, for some reason the July patch never got applied to that (now > outdated) 2.6.10 version of relayfs - either that patch or yours > should fix the problem - thanks for sending it. In any case, the > version of relayfs you're using is now ancient history - the latest > redux versions of relayfs recently posted to lkml have completely > changed or removed all that code, so you might want to try testing > with the latest patch (which I'm still reworking parts of even now). > > Thanks, > > Tom > Okay. I'll give the new patch a go when I can. Thanks, -- Kingsley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc][patch] ide: fix unneeded LBA48 taskfile registers access
Hello, Bartlomiej.
Bartlomiej Zolnierkiewicz wrote:
[ against ide-dev-2.6 tree, boot tested on LBA48 drive ]
This small patch fixes unneeded writes/reads to LBA48 taskfile registers
on LBA48 capable disks for following cases:
* Power Management requests
(WIN_FLUSH_CACHE[_EXT], WIN_STANDBYNOW1, WIN_IDLEIMMEDIATE commands)
* special commands (WIN_SPECIFY, WIN_RESTORE, WIN_SETMULT)
* Host Protected Area support (WIN_READ_NATIVE_MAX, WIN_SET_MAX)
* /proc/ide/ SMART support (WIN_SMART with SMART_ENABLE,
SMART_READ_VALUES and SMART_READ_THRESHOLDS subcommands)
* write cache enabling/disabling in ide-disk
(WIN_SETFEATURES with SETFEATURES_{EN,DIS}_WCACHE)
* write cache flushing in ide-disk (WIN_FLUSH_CACHE[_EXT])
* acoustic management in ide-disk
(WIN_SETFEATURES with SETFEATURES_{EN,DIS}_AAM)
* door (un)locking in ide-disk (WIN_DOORLOCK, WIN_DOORUNLOCK)
* /proc/ide/hd?/identify support (WIN_IDENTIFY)
Patch adds 'unsinged long flags' to ide_task_t and uses ATA_TFLAG_LBA48
flag (from ) to indicate need of accessing LBA48 taskfile
registers.
ide_task_t already has fields to enable/disable writing/reading of
taskfile and hob registers (tf_in_flags and tf_out_flags). How about
adding the following two helpers.
static inline ide_init_task[_std](ide_task_t *task)
{
memset(task, 0, sizeof(*task));
task->tf_out_flags = IDE_TASKFILE_STD_OUT_FLAGS;
task->tf_in_flags = IDE_TASKFILE_STD_IN_FLAGS;
}
static inline ide_init_task_lba48(ide_task_t *task)
{
memset(task, 0, sizeof(*task));
task->tf_out_flags = IDE_TASKFILE_STD_OUT_FLAGS
| (IDE_HOB_STD_OUT_FLAGS << 8);
task->tf_in_flags = IDE_TASKFILE_STD_IN_FLAGS
| (IDE_HOB_STD_IN_FLAGS << 8);
}
And, when writing taskfile,
if (task->tf_out_flags & 0xf == IDE_TASKFILE_STD_OUT_FLAGS) {
/* Write taskfile regs without testing flags */
} else {
/* Flagged taskfile */
}
if (task->tf_out_flags & 0xf0 == IDE_TASKFILE_HOB_OUT_FLAGS) {
/* Write hob regs without testing flags */
} else {
/* Flagged hob */
}
And, when reading taskfile back,
if (task->tf_in_flags & 0xf0) {
/* Read all hob regs */
}
/* Read all taskfile regs */
And, we need to check if any of in/out flags is zero in ioctl
functions and set STD flags appropriately. So, basically, in kernel,
tf_{in|out}_flags == 0 now means 0, not default.
By doing like above,
1. Virtually the same effect
2. No need to add new field to ide_task_t
3. Cleaner semantics (ATA_TFLAG_LBA48 and tf_{in|out}_flags carry
duplicate information.)
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] relayfs crash
Kingsley Cheung writes: > > To solve the problem I applied a patch similar to the one you posted > back in July and it fixed the problem. Could we consider putting this > patch into relayfs? Its similar to the one posted in July 2004, except > it also moves clear_readers() before INIT_WORK in relay_release (is > that acceptable?). > Yes, for some reason the July patch never got applied to that (now outdated) 2.6.10 version of relayfs - either that patch or yours should fix the problem - thanks for sending it. In any case, the version of relayfs you're using is now ancient history - the latest redux versions of relayfs recently posted to lkml have completely changed or removed all that code, so you might want to try testing with the latest patch (which I'm still reworking parts of even now). Thanks, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-usb-devel] 2.6: USB disk unusable level of data corruption
On Sunday 06 February 2005 7:59 am, Giuseppe Bilotta wrote: > > I have a MAGNEX/ViPower USB/FirWire external HD enclosure. I > found that it works pretty fine (albeit slowly) when connected > to the USB 1.1 ports built in my Dell Inspiron 8200, but trying > to connect it via the Hamlet PCMCIA USB2 Card Adapter doesn't > work (it seems it gets assigned minors 1,2,3,4,5,6,... and so > on forever until I unplug it). What do you mean "minors"? Addresses or actual /dev/sdN numbers? If it's addresses, that would be an an enumeration problem. Some recent changes have caused prolems there, 2.6.11-rc3-mm2 ought to have a patch making it better. (Well, working around one of the two problems that'd suggest.) If it's actual /dev/sdN numbers, that would seem to be an issue more at the level of usb-storage. Quite possibly related to the bugs you didn't exactly detail (below). - Dave > OTOH, I'm not sure if it's a PCMCIA adapter problem or USB2 > enclosure problem. Indeed, if I don't load the EHCI modules, > and thus limit myself to the USB1.1 capabilities of the PCMCIA > adapters, I get other errors (I'll have to write a cleaner bug > report on this. And try the PCMCIA card with some other USB > device. Wish I could use my softmodem under Linux :(). (Using > kernel 2.6.10-3 from Debian.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] module-init-tools: generate modules.seriomap
On Sun, 2005-02-06 at 02:55 -0500, Dmitry Torokhov wrote: > Hi Rusty, > > I have converted serio bus to use ID matching and changed serio drivers > to use MODULE_DEVICE_TABLE. Now that Vojtech pulled the changes into his > tree it would be nice if official module-init-tools generated the module > map so that hotplug scripts could automatically load proper drivers. Sure, applied. I would appreciated tests, however: you can download the testsuite from the same place you get module-init-tools. I don't expect you to be able to compile for all endian/size combinations, but I can do that for you. You should also put the logic into the kernel's scripts/mod/file2alias, which is where this is supposed to go these days (I haven't removed the modules.XXX files, since hotplug has enough deployment problems without me making things worse). Thanks, Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: M7101
On Sun, Feb 06, 2005 at 03:26:15PM +0100, Jean Delvare wrote: > Maarten Deprez then converted it to the proper kernel coding-style: > http://marc.theaimsgroup.com/?l=linux-kernel=110726276414532 ... > Any chance we could get the PCI folks to review the code and push it > upwards if it is OK? I'm not the maintainer, but it looks fine to me except for use of numeric constants (e.g 0x5f, 0x18) instead of adding #defines to name the values. But if no one knows what those offsets are for we'll just have to leave it. > For reference, here are links to the original m7101 unhiding driver code > and help file: > http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/prog/hotplug/m7101.c Unfortunately, I didn't anything documenting 0x5f and 0x18. Will m7101.c be modified once quirks enabling the device? hth, grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling
Jack O'Quin wrote: Werner Almesberger <[EMAIL PROTECTED]> writes: [ Cc:s trimmed, added abiss-general ] Con Kolivas wrote: Possibly reiserfs journal related. That has larger non-preemptible code sections. If I understand your workload right, it should consist mainly of computation, networking (?), and disk reads. The jack_test3.2 is basically a multiprocess realtime audio test. A fair amount of computation, signifcant task switch overhead, but most I/O is to the sound card. There's some disk activity starting clients and probably some other system activity in the background. I don't know much about ReiserFS, but in some experiments with ext3, using ABISS, we found that a reader application competing with best effort readers would experience worst-case delays of dozens of milliseconds. They were caused by journaled atime updates. Mounting the file system with "noatime" reduced delays to a few hundred microseconds (still worst-case). Interesting. Worth a try to verify. Con was seeing a 6msec delay every 20 seconds. This was devastating to the test, which tries to run a full realtime audio cycle every 1.45msec. They already were mounted noatime :( Con signature.asc Description: OpenPGP digital signature
Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling
Werner Almesberger <[EMAIL PROTECTED]> writes: > [ Cc:s trimmed, added abiss-general ] > > Con Kolivas wrote: >> Possibly reiserfs journal related. That has larger non-preemptible code >> sections. > > If I understand your workload right, it should consist mainly of > computation, networking (?), and disk reads. The jack_test3.2 is basically a multiprocess realtime audio test. A fair amount of computation, signifcant task switch overhead, but most I/O is to the sound card. There's some disk activity starting clients and probably some other system activity in the background. > I don't know much about ReiserFS, but in some experiments with ext3, > using ABISS, we found that a reader application competing with best > effort readers would experience worst-case delays of dozens of > milliseconds. > > They were caused by journaled atime updates. Mounting the file > system with "noatime" reduced delays to a few hundred microseconds > (still worst-case). Interesting. Worth a try to verify. Con was seeing a 6msec delay every 20 seconds. This was devastating to the test, which tries to run a full realtime audio cycle every 1.45msec. -- joq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] relayfs crash
Kingsley Cheung wrote: > To solve the problem I applied a patch similar to the one you posted > back in July and it fixed the problem. Could we consider putting this > patch into relayfs? Its similar to the one posted in July 2004, except > it also moves clear_readers() before INIT_WORK in relay_release (is > that acceptable?). Tom, correct me if I'm wrong but these fixes were integrated in the first relayfs redux I sent to LKML a few weeks back, right? Karim -- Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Regression? in USB support w/r/t libusb
Kernel developer's, if you don't think this is a kernel regression, please ignore this note. In FC3, with kernel 2.6.9-1.715_FC3smp, I hotplugged a formatted mini external hard drive in a new enclosure into a USB 2.0 hub. I expected to find its device node, but could not find it in my maze of USB devices. I might have searched further, but, instead, I unplugged it, and plugged it into another PC running FC1, with kernel 2.4.22-1.2174. I expected to have to reboot to see it, but hotplug worked, and I found the hard drive in the Hardware Browser, mounted its partitions, and used NFS to copy data into the FC3 machine. FC1 provided me an easy way to find the device node for a hotplugged USB hard drive, but I found no such easy way in FC3. Is this a regression, or is there an easy way that I missed? I am sending this note to both the Fedora mailing list and the kernel mailing list to find out where the regression is, if any. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling
[ Cc:s trimmed, added abiss-general ] Con Kolivas wrote: > Possibly reiserfs journal related. That has larger non-preemptible code > sections. If I understand your workload right, it should consist mainly of computation, networking (?), and disk reads. I don't know much about ReiserFS, but in some experiments with ext3, using ABISS, we found that a reader application competing with best effort readers would experience worst-case delays of dozens of milliseconds. They were caused by journaled atime updates. Mounting the file system with "noatime" reduced delays to a few hundred microseconds (still worst-case). - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.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/
[PATCH] relayfs crash
Hi Tom, I've been stress testing a module that uses relayfs on a custom built 2.6 kernel with relayfs patches in it. This test simply loaded and unloaded the module while a script loaded the system with forks of 'ls' in the background. It was conducted on a dual 3.00GHz Xeon box (I couldn't reproduce the bug on slower machines I had) and produced oopses of the following type: wembley login: Oops: [#1] SMP CPU:2 EIP:0060:[]Tainted: GF U EFLAGS: 00010292 (2.6.5-7.97ZP2-smp) EIP is at relayfs_remove_file+0x10/0xc0 [relayfs] eax: ebx: 0292 ecx: f0cf3918 edx: c193810c esi: edi: f0cf391c ebp: f0cf3000 esp: f7fabf4c ds: 007b es: 007b ss: 0068 Process events/2 (pid: 12, threadinfo=f7faa000 task=cdea2730) Stack: 0292 c1938100 f0cf391c c0138cc7 c180c960 c180c960 c1938120 f9822cb0 f7faa000 c193810c 0001 c0122b10 0001 00f0 cdea2730 c0122b10 Call Trace: [] worker_thread+0x187/0x230 [] remove_rchan_file+0x0/0xb [relayfs] [] default_wake_function+0x0/0x10 [] default_wake_function+0x0/0x10 [] worker_thread+0x0/0x230 [] kthread+0xd4/0x118 [] kthread+0x0/0x118 [] kernel_thread_helper+0x5/0x10 Code: 8b 58 64 b8 ea ff ff ff 85 db 74 5b 8b 46 0c 0f b7 40 20 25 This oops looks like one mentioned in http://www.listserv.shafik.org/pipermail/ltt/2004-July/000627.html It seems to be the same problem where the rchan work queue is scheduled to run, but rchan has already been destroyed when the tries it. This still happens in the latest patch against 2.6.10 at http://www.opersys.com/ftp/pub/relayfs/patch-relayfs-2.6.10-050113 To solve the problem I applied a patch similar to the one you posted back in July and it fixed the problem. Could we consider putting this patch into relayfs? Its similar to the one posted in July 2004, except it also moves clear_readers() before INIT_WORK in relay_release (is that acceptable?). Thanks, -- Kingsley --- linux-2.6.5-7.97ZP2/fs/relayfs/relay.c.old 2005-02-02 18:43:24.918844376 +1100 +++ linux-2.6.5-7.97ZP2/fs/relayfs/relay.c 2005-02-02 18:44:33.725384192 +1100 @@ -184,6 +184,7 @@ struct rchan *rchan = (struct rchan *)private; relayfs_remove_file(rchan->dentry); + kfree(rchan); } @@ -212,12 +213,10 @@ goto exit; rchan_free_id(rchan->id); + clear_readers(rchan); INIT_WORK(>work, remove_rchan_file, rchan); schedule_delayed_work(>work, 1); - - clear_readers(rchan); - kfree(rchan); exit: return err; }
[PATCH] twiddler compile fix.
Hi,
Somehow this part of one of the earlier patches was lost...
--
Dmitry
===
[EMAIL PROTECTED], 2005-02-06 20:25:21-05:00, [EMAIL PROTECTED]
Input: fix compie error in twidjoy.c
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
twidjoy.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
===
diff -Nru a/drivers/input/joystick/twidjoy.c b/drivers/input/joystick/twidjoy.c
--- a/drivers/input/joystick/twidjoy.c 2005-02-06 21:56:05 -05:00
+++ b/drivers/input/joystick/twidjoy.c 2005-02-06 21:56:05 -05:00
@@ -58,7 +58,9 @@
#include
#include
-MODULE_DESCRIPTION("Handykey Twiddler keyboard as a joystick driver");
+#define DRIVER_DESC"Handykey Twiddler keyboard as a joystick driver"
+
+MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL");
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-usb-devel] 2.6: USB disk unusable level of data corruption
On Fri, 2005-02-04 at 12:41 -0800, David Brownell wrote:
> On Friday 04 February 2005 4:16 am, Rusty Russell wrote:
> >
> > Is USB/SCSI just terminally broken under 2.6?
>
> I don't think so, but there are problems that appear in some
> hardware configs and not others. Many folk report no problems;
> a (very) few report nothing but.
>
> If you've verified this on 2.6.10, then you certainly have
> have the ehci-hcd (re)queueing race fix that has made a big
> difference for some folk. I don't know of any other issues
> in that driver that could explain usb-storage problems.
>
> What hardware config do you have?
>
> - Whose EHCI controller and revision? I've never had
> good luck with VIA VT6202. ("lspci -v".)
OK, it's an IBM Thinkpad X31:
:00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI
Controller (rev 01) (prog-if 20 [EHCI])
Subsystem: IBM: Unknown device 052e
Flags: bus master, medium devsel, latency 0, IRQ 11
Memory at c000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] #0a [2080]
Kernel messages when plugged in:
usb 4-3: new high speed USB device using address 5
scsi3 : SCSI emulation for USB Mass Storage devices
Vendor: HTS72606 Model: 0M9AT00 Rev: MH4O
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
sda: assuming drive cache: write through
/dev/scsi/host3/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 p9 >
Attached scsi disk sda at scsi3, channel 0, id 0, lun 0
USB Mass Storage device found at 5
> - Whose USB storage adapter? ("lsusb -v", or in this
> case the /proc/bus/usb/devices entry would be ok.)
> GeneSys adapters have been the most problematic,
> but they're hardly the only ones with quirks.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x0dc4 Macpower Peripherals, Ltd
idProduct 0x00c4
bcdDevice0.02
iManufacturer 1 Macpower
iProduct2 2.5HDD
iSerial 3 8000D1
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 Myson 8818
bmAttributes 0xc0
Self Powered
MaxPower 10mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 5 SFF-8070i
bInterfaceProtocol 80
iInterface 5 USB2.0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
bNumConfigurations 1
> Thing is, that driver stack isn't especially thin: SCSI isn't
> the top, and it's got usb-storage, usbcore, and a USB HCD under
> it. That makes it harder to track down root causes, even when
> there is just a single one and it's in those drivers (rather
> than being hardware misbehavior).
I have some spare partitions on the disk, so I've written a program
which writes using DIRECT_IO and verifies the results. It took less
than an hour under my filesystem load, so I'll see if I can get this to
trigger it (currently N children writing to separate blocks, but if that
doesn't trigger it I'll get more sophisticated with readers and
writers).
Thanks for the response,
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [PATCH] Re: msdos/vfat defaults are annoying
On 2005.02.07 00:42, Pozsár Balázs wrote:
On Mon, Feb 07, 2005 at 12:36:10AM +, Al Viro wrote:
> On Mon, Feb 07, 2005 at 12:21:08AM +0100, Pozsar Balazs wrote:
> > On Sun, Feb 06, 2005 at 07:06:59AM +, Christoph Hellwig wrote:
> > > filesystem detection isn't handled at the kerne level.
^
IIRC currently if both msdos and vfat are compiled in (not modules),
and
you try to mount a vfat filesystem without explicitly specifying the fs
type, it will be mounted with the msdos type. With the, it will mounted
vfat.
But since filesystem detection isn't handled in the kernel, changing the
link order is pointless. Please fix your /etc/filesystems instead.
~# grep camera /etc/fstab
/dev/sda1 /mnt/camera auto users,noauto 0 0
~# strace -o mount.trace mount /mnt/camera
~# grep filesystems mount.trace
open("/etc/filesystems", O_RDONLY|O_LARGEFILE) = 3
~# cat /etc/filesystems
ext2
ext3
nodev proc
nodev devpts
iso9660
reiserfs
vfat
udf
Also check man 8 mount, specifically option -t:
[...] Creating a file /etc/filesystems can be useful to change the probe
order (e.g., to try vfat before msdos) ...
This is from man-pages 1.66, btw.
Regards,
Nuno
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Linux Kernel Subversion Howto
On Mon, Feb 07, 2005 at 02:45:22AM +0100, Roman Zippel wrote: [same wankfest] *plonk* If you ever need to send me mail - send it directly. Anything from you to l-k will be handled by /dev/null here. And it would better on saner topics not involving your crusades, TYSoFsckingM. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Linux Kernel Subversion Howto
> Bzzt. Larry, I will make this one very easy, so that even you can follow > it. Let's take a simple file: > > $ rlog REPORTING-BUGS,v | grep 'total revisions' > total revisions: 3; selected revisions: 3 > $ rlog REPORTING-BUGS,v | egrep '\(Logical change 1.[0-9]+\)' > (Logical change 1.31) > (Logical change 1.3) Exactly. The second one shows 2 revs, which is what you counted, and the first shows 3 which is what is actually there. See, all you have to do is look: slovax /tmp/linux-2.5-cvs/linux-2.5 rlog REPORTING-BUGS,v RCS file: REPORTING-BUGS,v Working file: REPORTING-BUGS head: 1.3 branch: locks: strict access list: symbolic names: keyword substitution: o total revisions: 3; selected revisions: 3 description: BitKeeper to RCS/CVS export revision 1.3 date: 2002/02/05 18:07:03; author: patch; state: Exp; lines: +3 -4 Import patch diff (Logical change 1.31) revision 1.2 date: 2002/02/05 17:40:40; author: torvalds; state: Exp; lines: +58 -0 (Logical change 1.3) revision 1.1 date: 2002/02/05 17:40:40; author: torvalds; state: Exp; Initial revision As for your pointer to the revision history on the web which shows 2 revs, you just don't understand BK. There is a 1.0 delta in every file that we hide by default. That would be the matching delta to the RCS 1.1 delta. > > Fourth, it is your choice to not use BitKeeper because you want to compete > > with the people who are helping you. It's not that unreasonable that > > you find yourself at something of a disadvantage because of that choice. > > And the disadvantage is very slight as has been shown. You can argue > > all you want about the amount of disadvantage but it is your choice that > > has placed you in that position. > > Well, I'm not the one who claimed "We don't do lockins. Period." > I'm just trying to figure out what that means... Hey, Roman, the statement above stands. You made the choice that you want to go write a competing system. If you hadn't you could just use BK and stop whining. Since you have made that choice, which is your right, how about you produce your competing system? And stop whining that we aren't giving you enough help. What is that you say? It's hard? It's way harder if we don't give you a roadmap? Well gosh darn, that must really suck for you. I'm really sorry that you can't figure it out without our help but that's sort of the whole point, isn't it? -- --- Larry McVoylm at bitmover.com http://www.bitkeeper.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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
hi all, I would like point to work done by Li-Ta Lo. It allows you to completely initalize the VGA BIOS w/out using PC BIOS at all. http://www.clustermatic.org/pipermail/linuxbios/2005-January/010236.html unforunatelly the information the web is somewhat sparse, but you can get more info by following the archive of the thread (which head I listed above) and perhaps by posting to linuxbios mailing list (Ollie, is somewhat buy those days with his new baby). Either way quite amazing feat that should bring LinuxBIOS closer to desktop. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Executive Summary: Bad page state at prep_new_page
This might or might not be useful to anybody but I googled with the above error and tried to track down how many of these errors had actually been resolved. [It is possible that people don't come back to summarize once the problem is resolved]. I only tracked once that did not get reported on lkml. And I tried to drill down to get as much info as I can. there were 12 in total that I tracked down starting 04/04/04 till 01/26/05 None had a good resolution reported 4 out of 12 had extensive memtest runs without any errors. 12/12 were for 2.6.7-rc3 onwards. 4/12 had mapping all zeroes [rest did not report or had non-zero mapping] I might be barking up the wrong tree here without much knowledge, but I have a summary gnumeric spreadsheet [which I won't even think of attaching here] if it is going to be useful to anyone I would be glad to email personally. It also has html links to the original reports. Thanks, Jay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Linux Kernel Subversion Howto
Hi,
On Sun, 6 Feb 2005, Larry McVoy wrote:
> > $ find -name \*,v -a ! -path ./BitKeeper\* -a ! -name ChangeSet,v | xargs
> > rlog | egrep '\(Logical change 1.[0-9]+\)' | wc -l
> > 187576
>
> Bzzt. You forgot all the intial deltas which are not marked with the
> logical change comment. And just to double check my logic I tried it
> with rlog (much slower but whatever):
>
> $ /tmp/linux-2.5-cvs find linux-2.5/ -name '*,v' |
> xargs rlog | grep 'total revisions' |
> awk 'BEGIN { n = 0 }; { n = n + $NF }; END { print n }'
> 237338
> $ /tmp/linux-2.5-cvs perl REVS
> files=22966 revs=237338
>
> Imagine that, the numbers match perfectly.
Bzzt. Larry, I will make this one very easy, so that even you can follow
it. Let's take a simple file:
$ rlog REPORTING-BUGS,v | grep 'total revisions'
total revisions: 3; selected revisions: 3
$ rlog REPORTING-BUGS,v | egrep '\(Logical change 1.[0-9]+\)'
(Logical change 1.31)
(Logical change 1.3)
Now please check http://linux.bkbits.net:8080/linux-2.6/hist/REPORTING-BUGS
and tell me which number is correct.
> It's always possible I've made a mistake but you really ought to check
> your work a little bit before making false claims. It's trivial to do
> what I did which is run the script over a single file and hand verify
> that it is correct.
Ditto.
> > [Questionable complaints that he isn't getting enough information]
I challenge you to quote a single complaint I did in this mail.
All I did was adding the missing facts, which you like to forget to
mention and giving anyone the necessary information to verify them.
> First, you can get all the granularity that you want from bkbits.net.
> Find the file you want, find the revision, and go backwards to the
> changeset. It takes you a few clicks to do that.
Once again our dear Larry tells only half the story. It's true that single
file changes (which are in bkcvs are only available to 85%) are completely
available via bkweb to 100%. The problem is again how all these changes
relate to each other (the 44% number for bkcvs).
To give everyone an idea what this means, let's take a bit more
complicated file like http://linux.bkbits.net:8080/linux-2.6/hist/MAINTAINERS
Now try to figure out what all the revisions saying "Auto merged" actually
merge. It's actually possible, but one has to use heuristics which can
fail, so while one can restore most of the history of a single file, it's
not reliable anymore as soon as the branching becomes more complex.
The real trouble starts if one wants to know how all these files relate to
each other. Right now the bk tree contains over 59000 snapshots of how the
kernel looked at a specific point. To restore these snapshots again one
must apply the changesets in the correct order (this is equally true for
the commit mails), IOW one must know the parent revisions of a changeset
to really restore the history and to not just look at a part of it, but
bkweb unfortunately doesn't provide this information in full. Within a
branch the patch order is of course obvious, but one must also know where
a branch starts and ends, which is unfortunately not as obvious as one
might think. E.g. SCCS files are limited to a single branch level and bk
inherited this, so a branch of 1.2.3.4 is not 1.2.3.4.1.1 but something
like 1.2.4.1.
Larry, so far I have only stated facts, which are easily verifiable, how
about you come up with some facts of your own to prove me wrong? If I'm
just "complaining" and all the information is out there, it should be easy
for you to do...
> Fourth, it is your choice to not use BitKeeper because you want to compete
> with the people who are helping you. It's not that unreasonable that
> you find yourself at something of a disadvantage because of that choice.
> And the disadvantage is very slight as has been shown. You can argue
> all you want about the amount of disadvantage but it is your choice that
> has placed you in that position.
Well, I'm not the one who claimed "We don't do lockins. Period."
I'm just trying to figure out what that means...
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-tracecalls, a clarification
Carl Spalletta wrote: > +#The name of an operations structure member, wrongly interpreted by > +#cscope as the name of an actual function - it should be ignored, > +#since it has been confused by cscope with the name of some actual > +#caller. HOWEVER the callbacks are found anyway, under their actual > names. > +#and if any function pointed to by a callback is part of a chain to > +#our initial target it _will_ be found, the same as any other caller. Hmm, but it doesn't seem to follow function pointers anyway. Example: http://www.linuxrd.com/~carl/cgi-bin/lnxtc.pl?file=fs/jbd/transaction.c=do_get_write_access should contain, among many others, this call chain: fs/read_write.c:sys_read fs/read_write.c:vfs_read fs/ext3/file.c:ext3_file_operations.read = fs/read_write.c:do_sync_read fs/ext3/file.c:ext3_file_operations.aio_read = mm/filemap.c:generic_file_aio_read mm/filemap.c:__generic_file_aio_read include/linux/fs.h:do_generic_file_read mm/filemap.c:do_generic_mapping_read include/linux/fs.h:file_accessed include/linux/fs.h:touch_atime fs/inode.c:update_atime include/linux/fs.h:mark_inode_dirty_sync fs/fs-writeback.c:__mark_inode_dirty fs/ext3/super.c:ext3_sops.dirty_inode = fs/ext3/inode.c:ext3_dirty_inode include/linux/ext3_jbd.h:ext3_journal_get_write_access fs/jbd/transaction.c:journal_get_write_access fs/jbd/transaction.c:do_get_write_access Note the three functions pointers that were used in this. This kind of construct is extremely common in the kernel, and it's usually the main source of confusion that will actually make one want to use a call chain discovery tool. I see that you're handling inline functions correctly. Another thing that seems to be missing are macros. E.g. this query http://www.linuxrd.com/~carl/cgi-bin/lnxtc.pl?file=include/linux/seqlock.h=seqcount_init should probably have found the reference in fs.h (it's somewhat obscured by #ifdefs, so, depending on how your tree was set up, the response may actually be correct). Also, this query should have returned something: http://www.linuxrd.com/~carl/cgi-bin/lnxtc.pl?file=include/linux/blkdev.h=blk_queue_plugged Since the call trees fan out very quickly (in either direction), I think an interactive browser that lets you select which branch(es) to follow (while remembering the chain you've already visited) would be more useful than a huge dump that may require significant post-processing. It would also be nice to be able to go both ways, from called to caller, and from caller to called. Again, the tricky bit here are the function pointers. I think that a tool that can handle the most common idioms found in the kernel would be very useful. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.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: [PATCH] Linux joydev joystick disconnect patch 2.6.11-rc2
On Sunday 06 February 2005 08:12, Vojtech Pavlik wrote:
> On Tue, Feb 01, 2005 at 10:24:39AM -0500, Dmitry Torokhov wrote:
> > On Tue, 1 Feb 2005 08:52:15 -0600, David Fries <[EMAIL PROTECTED]> wrote:
> > > Currently a blocking read, select, or poll call will not return if a
> > > joystick device is unplugged. This patch allows them to return.
> > >
> > ...
> > > static unsigned int joydev_poll(struct file *file, poll_table *wait)
> > > {
> > > + int mask = 0;
> > > struct joydev_list *list = file->private_data;
> > > poll_wait(file, >joydev->wait, wait);
> > > - if (list->head != list->tail || list->startup <
> > > list->joydev->nabs + list->joydev->nkey)
> > > - return POLLIN | POLLRDNORM;
> > > - return 0;
> > > + if(!list->joydev->exist)
> > > + mask |= POLLERR;
> >
> > Probably need POLLHUP in addition (or instead of POLLERR).
> >
> > > if (joydev->open)
> > > + {
> > > input_close_device(handle);
> > > + wake_up_interruptible(>wait);
> > > + }
> > > else
> > > + {
> > > joydev_free(joydev);
> > > + }
> >
> > Opening braces should go on the same line as the statement (if (...) {).
>
> How about this patch?
Looks fine now. Hmm, wait a sec... Don't we also need kill_fasync calls in
disconnect routines as well?
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: msdos/vfat defaults are annoying
On Mon, Feb 07, 2005 at 12:36:10AM +, Al Viro wrote: > On Mon, Feb 07, 2005 at 12:21:08AM +0100, Pozsar Balazs wrote: > > On Sun, Feb 06, 2005 at 07:06:59AM +, Christoph Hellwig wrote: > > > On Sun, Feb 06, 2005 at 12:33:43AM -0500, John Richard Moser wrote: > > > > I dunno. I can never understand the innards of the kernel devs' minds. > > > > > > filesystem detection isn't handled at the kerne level. > > > > Yeah, but the link order could be changed... Patch inlined. > > And just what does the link order (or changes thereof) have to do with that? IIRC currently if both msdos and vfat are compiled in (not modules), and you try to mount a vfat filesystem without explicitly specifying the fs type, it will be mounted with the msdos type. With the, it will mounted vfat. -- pozsy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Re: msdos/vfat defaults are annoying
On Mon, Feb 07, 2005 at 12:21:08AM +0100, Pozsar Balazs wrote: > On Sun, Feb 06, 2005 at 07:06:59AM +, Christoph Hellwig wrote: > > On Sun, Feb 06, 2005 at 12:33:43AM -0500, John Richard Moser wrote: > > > I dunno. I can never understand the innards of the kernel devs' minds. > > > > filesystem detection isn't handled at the kerne level. > > Yeah, but the link order could be changed... Patch inlined. And just what does the link order (or changes thereof) have to do with that? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] tridentfb.c: make some code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/video/tridentfb.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
This patch was already sent on:
- 21 Nov 2004
--- linux-2.6.10-rc2-mm2-full/drivers/video/tridentfb.c.old 2004-11-21
15:01:33.0 +0100
+++ linux-2.6.10-rc2-mm2-full/drivers/video/tridentfb.c 2004-11-21
15:03:19.0 +0100
@@ -31,7 +31,7 @@
void __iomem * io_virt; //iospace virtual memory address
};
-unsigned char eng_oper;//engine operation...
+static unsigned char eng_oper; //engine operation...
static struct fb_ops tridentfb_ops;
static struct tridentfb_par default_par;
@@ -91,7 +91,7 @@
static int chip3D;
static int chipcyber;
-int is3Dchip(int id)
+static int is3Dchip(int id)
{
return ((id == BLADE3D) || (id == CYBERBLADEE4) ||
(id == CYBERBLADEi7) || (id == CYBERBLADEi7D) ||
@@ -104,7 +104,7 @@
(id == CYBERBLADEXPAi1));
}
-int iscyber(int id)
+static int iscyber(int id)
{
switch (id) {
case CYBER9388:
@@ -1223,9 +1223,9 @@
.remove = __devexit_p(trident_pci_remove)
};
-int tridentfb_setup(char *options);
+static int tridentfb_setup(char *options);
-int __init tridentfb_init(void)
+static int __init tridentfb_init(void)
{
#ifndef MODULE
char *option = NULL;
@@ -1238,7 +1238,7 @@
return pci_module_init(_pci_driver);
}
-void __exit tridentfb_exit(void)
+static void __exit tridentfb_exit(void)
{
pci_unregister_driver(_pci_driver);
}
@@ -1249,7 +1249,8 @@
* example:
* video=trident:800x600,bpp=16,noaccel
*/
-int tridentfb_setup(char *options)
+#ifndef MODULE
+static int tridentfb_setup(char *options)
{
char * opt;
if (!options || !*options)
@@ -1279,6 +1280,7 @@
}
return 0;
}
+#endif
static struct fb_ops tridentfb_ops = {
.owner = THIS_MODULE,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/intermodule.c: make inter_module_get static
There's no longer any user of inter_module_get outside of
intermodule.c .
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/module.h |1 -
kernel/intermodule.c |3 +--
2 files changed, 1 insertion(+), 3 deletions(-)
This patch was already sent on:
- 12 Dec 2004
--- linux-2.6.10-rc2-mm4-full/include/linux/module.h.old2004-12-12
02:53:34.0 +0100
+++ linux-2.6.10-rc2-mm4-full/include/linux/module.h2004-12-12
02:53:50.0 +0100
@@ -571,7 +571,6 @@
extern void __deprecated inter_module_register(const char *,
struct module *, const void *);
extern void __deprecated inter_module_unregister(const char *);
-extern const void * __deprecated inter_module_get(const char *);
extern const void * __deprecated inter_module_get_request(const char *,
const char *);
extern void __deprecated inter_module_put(const char *);
--- linux-2.6.10-rc2-mm4-full/kernel/intermodule.c.old 2004-12-12
02:53:57.0 +0100
+++ linux-2.6.10-rc2-mm4-full/kernel/intermodule.c 2004-12-12
02:54:17.0 +0100
@@ -113,7 +113,7 @@
* Try to increment the use count on the owning module, if that fails
* then return NULL. Otherwise return the userdata.
*/
-const void *inter_module_get(const char *im_name)
+static const void *inter_module_get(const char *im_name)
{
struct list_head *tmp;
struct inter_module_entry *ime;
@@ -178,6 +178,5 @@
EXPORT_SYMBOL(inter_module_register);
EXPORT_SYMBOL(inter_module_unregister);
-EXPORT_SYMBOL(inter_module_get);
EXPORT_SYMBOL(inter_module_get_request);
EXPORT_SYMBOL(inter_module_put);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] SCSI ultrastor.c: make a variable static
This patch makes a needlessly global variable static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 15 Nov 2004
--- linux-2.6.10-rc1-mm5-full/drivers/scsi/ultrastor.c.old 2004-11-14
01:31:07.0 +0100
+++ linux-2.6.10-rc1-mm5-full/drivers/scsi/ultrastor.c 2004-11-14
01:31:20.0 +0100
@@ -259,7 +259,7 @@
} config = {0};
/* Set this to 1 to reset the SCSI bus on error. */
-int ultrastor_bus_reset;
+static int ultrastor_bus_reset;
/* Allowed BIOS base addresses (NULL indicates 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/
[2.6 patch] SCSI sym53c416.c: make a function static
This patch makes a needlessly global function static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 15 Nov 2004
--- linux-2.6.10-rc1-mm5-full/drivers/scsi/sym53c416.c.old 2004-11-14
01:30:23.0 +0100
+++ linux-2.6.10-rc1-mm5-full/drivers/scsi/sym53c416.c 2004-11-14
01:30:32.0 +0100
@@ -616,7 +616,7 @@
MODULE_DEVICE_TABLE(isapnp, id_table);
-void sym53c416_probe(void)
+static void sym53c416_probe(void)
{
int *base = probeaddrs;
int ints[2];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: msdos/vfat defaults are annoying
On Sun, Feb 06, 2005 at 07:06:59AM +, Christoph Hellwig wrote: > On Sun, Feb 06, 2005 at 12:33:43AM -0500, John Richard Moser wrote: > > I dunno. I can never understand the innards of the kernel devs' minds. > > filesystem detection isn't handled at the kerne level. Yeah, but the link order could be changed... Patch inlined. -- pozsy diff -Naurd a/fs/Makefile b/fs/Makefile --- a/fs/Makefile 2004-08-04 10:52:28.0 +0200 +++ b/fs/Makefile 2004-08-04 11:32:04.510913663 +0200 @@ -57,8 +57,8 @@ obj-$(CONFIG_MINIX_FS) += minix/ obj-$(CONFIG_FAT_FS) += fat/ obj-$(CONFIG_UMSDOS_FS)+= umsdos/ -obj-$(CONFIG_MSDOS_FS) += msdos/ obj-$(CONFIG_VFAT_FS) += vfat/ +obj-$(CONFIG_MSDOS_FS) += msdos/ obj-$(CONFIG_BFS_FS) += bfs/ obj-$(CONFIG_ISO9660_FS) += isofs/ obj-$(CONFIG_DEVFS_FS) += devfs/ Signed-off-by: Pozsar Balazs <[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: VIA VT610 IDE support for 2.4.28 (trivial) - now for 2.4.29/via82cxxx
Mathias Kretschmer wrote:
Jeff Garzik wrote:
Mathias Kretschmer wrote:
hi,
I found an older version of this patch (against 2.4.22) on some
website. After a little bit of editing it applied cleanly to 2.4.27
(and now 2.4.28). It works fine for me on a ASUS P4P800-Deluxe with
4x 300GB disks.
Maybe someone finds this patch helpful. Any reason why the original
patch did not make it into the kernel ?
Why not add it to the existing via82cxxx driver, and get better
performance and device tuning?
OK, the attached patch adds support for the VIA 6410 chip to the
via82cxxx driver (instead of the generic driver).
I've tested it on the board mentioned above. Works fine for me.
Cheers,
Mathias
diff -aurN linux-2.4.29/drivers/ide/pci/via82cxxx.c
linux-2.4.29-vanilla/drivers/ide/pci/via82cxxx.c
--- linux-2.4.29/drivers/ide/pci/via82cxxx.c2003-08-25 04:44:41.0
-0700
+++ linux-2.4.29-vanilla/drivers/ide/pci/via82cxxx.c2005-02-06
14:45:20.0 -0800
@@ -74,6 +74,7 @@
u8 rev_max;
u16 flags;
} via_isa_bridges[] = {
+ { "vt6410", PCI_DEVICE_ID_VIA_6410, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8237", PCI_DEVICE_ID_VIA_8237, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8235", PCI_DEVICE_ID_VIA_8235, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8233a",PCI_DEVICE_ID_VIA_8233A,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
@@ -641,6 +642,7 @@
static struct pci_device_id via_pci_tbl[] __devinitdata = {
{ PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C576_1, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 1},
+ { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_6410, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 2},
{ 0, },
};
diff -aurN linux-2.4.29/drivers/ide/pci/via82cxxx.h
linux-2.4.29-vanilla/drivers/ide/pci/via82cxxx.h
--- linux-2.4.29/drivers/ide/pci/via82cxxx.h2003-06-13 07:51:33.0
-0700
+++ linux-2.4.29-vanilla/drivers/ide/pci/via82cxxx.h2005-02-06
14:45:16.0 -0800
@@ -56,6 +56,19 @@
.enablebits = {{0x40,0x02,0x02}, {0x40,0x01,0x01}},
.bootable = ON_BOARD,
.extra = 0,
+},{ /* 2 */
+.vendor = PCI_VENDOR_ID_VIA,
+.device = PCI_DEVICE_ID_VIA_6410,
+.name = "VP_IDE",
+.init_chipset = init_chipset_via82cxxx,
+.init_iops = NULL,
+.init_hwif = init_hwif_via82cxxx,
+.init_dma = init_dma_via82cxxx,
+.channels = 2,
+.autodma= AUTODMA,
+.enablebits = {{0x00,0x00,0x00}, {0x00,0x00,0x00}},
+.bootable = ON_BOARD,
+.extra = 0,
},{
.vendor = 0,
.device = 0,
diff -aurN linux-2.4.29/include/linux/pci_ids.h
linux-2.4.29-vanilla/include/linux/pci_ids.h
--- linux-2.4.29/include/linux/pci_ids.h2005-01-19 06:10:12.0
-0800
+++ linux-2.4.29-vanilla/include/linux/pci_ids.h2005-02-06
14:46:48.0 -0800
@@ -1136,6 +1136,7 @@
#define PCI_DEVICE_ID_VIA_8233A0x3147
#define PCI_DEVICE_ID_VIA_P4M266 0x3148
#define PCI_DEVICE_ID_VIA_8237_SATA0x3149
+#define PCI_DEVICE_ID_VIA_6410 0x3164
#define PCI_DEVICE_ID_VIA_P4X333 0x3168
#define PCI_DEVICE_ID_VIA_8235 0x3177
#define PCI_DEVICE_ID_VIA_8377_0 0x3189
[rfc][patch] ide: fix unneeded LBA48 taskfile registers access
[ against ide-dev-2.6 tree, boot tested on LBA48 drive ]
This small patch fixes unneeded writes/reads to LBA48 taskfile registers
on LBA48 capable disks for following cases:
* Power Management requests
(WIN_FLUSH_CACHE[_EXT], WIN_STANDBYNOW1, WIN_IDLEIMMEDIATE commands)
* special commands (WIN_SPECIFY, WIN_RESTORE, WIN_SETMULT)
* Host Protected Area support (WIN_READ_NATIVE_MAX, WIN_SET_MAX)
* /proc/ide/ SMART support (WIN_SMART with SMART_ENABLE,
SMART_READ_VALUES and SMART_READ_THRESHOLDS subcommands)
* write cache enabling/disabling in ide-disk
(WIN_SETFEATURES with SETFEATURES_{EN,DIS}_WCACHE)
* write cache flushing in ide-disk (WIN_FLUSH_CACHE[_EXT])
* acoustic management in ide-disk
(WIN_SETFEATURES with SETFEATURES_{EN,DIS}_AAM)
* door (un)locking in ide-disk (WIN_DOORLOCK, WIN_DOORUNLOCK)
* /proc/ide/hd?/identify support (WIN_IDENTIFY)
Patch adds 'unsinged long flags' to ide_task_t and uses ATA_TFLAG_LBA48
flag (from ) to indicate need of accessing LBA48 taskfile
registers.
diff -Nru a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
--- a/drivers/ide/ide-disk.c2005-02-06 23:47:44 +01:00
+++ b/drivers/ide/ide-disk.c2005-02-06 23:47:44 +01:00
@@ -362,6 +362,9 @@
args.tfRegister[IDE_COMMAND_OFFSET] = WIN_READ_NATIVE_MAX_EXT;
args.command_type = IDE_DRIVE_TASK_NO_DATA;
args.handler= _no_data_intr;
+
+ args.flags |= ATA_TFLAG_LBA48;
+
/* submit command request */
ide_raw_taskfile(drive, , NULL);
@@ -431,6 +434,9 @@
args.hobRegister[IDE_CONTROL_OFFSET_HOB]= (drive->ctl|0x80);
args.command_type = IDE_DRIVE_TASK_NO_DATA;
args.handler= _no_data_intr;
+
+ args.flags |= ATA_TFLAG_LBA48;
+
/* submit command request */
ide_raw_taskfile(drive, , NULL);
/* if OK, compute maximum address value */
diff -Nru a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
--- a/drivers/ide/ide-io.c 2005-02-06 23:47:44 +01:00
+++ b/drivers/ide/ide-io.c 2005-02-06 23:47:44 +01:00
@@ -487,7 +487,7 @@
args->tfRegister[IDE_SELECT_OFFSET] =
hwif->INB(IDE_SELECT_REG);
args->tfRegister[IDE_STATUS_OFFSET] = stat;
- if (drive->addressing == 1) {
+ if (args->flags & ATA_TFLAG_LBA48) {
hwif->OUTB(drive->ctl|0x80, IDE_CONTROL_REG);
args->hobRegister[IDE_FEATURE_OFFSET] =
hwif->INB(IDE_FEATURE_REG);
args->hobRegister[IDE_NSECTOR_OFFSET] =
hwif->INB(IDE_NSECTOR_REG);
diff -Nru a/drivers/ide/ide-taskfile.c b/drivers/ide/ide-taskfile.c
--- a/drivers/ide/ide-taskfile.c2005-02-06 23:47:44 +01:00
+++ b/drivers/ide/ide-taskfile.c2005-02-06 23:47:44 +01:00
@@ -101,7 +101,7 @@
ide_hwif_t *hwif= HWIF(drive);
task_struct_t *taskfile = (task_struct_t *) task->tfRegister;
hob_struct_t *hobfile = (hob_struct_t *) task->hobRegister;
- u8 HIHI = (drive->addressing == 1) ? 0xE0 : 0xEF;
+ u8 HIHI = (task->flags & ATA_TFLAG_LBA48) ? 0xE0 : 0xEF;
/* ALL Command Block Executions SHALL clear nIEN, unless otherwise */
if (IDE_CONTROL_REG) {
@@ -110,7 +110,7 @@
}
SELECT_MASK(drive, 0);
- if (drive->addressing == 1) {
+ if (task->flags & ATA_TFLAG_LBA48) {
hwif->OUTB(hobfile->feature, IDE_FEATURE_REG);
hwif->OUTB(hobfile->sector_count, IDE_NSECTOR_REG);
hwif->OUTB(hobfile->sector_number, IDE_SECTOR_REG);
@@ -577,6 +577,9 @@
args.tf_out_flags = req_task->out_flags;
args.data_phase = req_task->data_phase;
args.command_type = req_task->req_cmd;
+
+ if (drive->addressing == 1)
+ args.flags |= ATA_TFLAG_LBA48;
drive->io_32bit = 0;
switch(req_task->data_phase) {
diff -Nru a/include/linux/ide.h b/include/linux/ide.h
--- a/include/linux/ide.h 2005-02-06 23:47:44 +01:00
+++ b/include/linux/ide.h 2005-02-06 23:47:44 +01:00
@@ -1258,6 +1258,7 @@
* struct hd_drive_hob_hdr hobf;
* hob_struct_thobf;
*/
+ unsigned long flags; /* ATA_TFLAG_xxx */
task_ioreg_ttfRegister[8];
task_ioreg_thobRegister[8];
ide_reg_valid_t tf_out_flags;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Problem in accessing executable files
Hi John, Thanks for suggesting the single / few bytes encryption test. I tried doing that, but in vain. Maybe I am going wrong somewhere else. I will briefly tell the functions I have written and the sequence if I am doing any mistake in the logic, please let me know. In file.c I have added the info about the functions my_generic_file_read and my_generic_file_write in ext2_file_operations. For decrypting, the sequence is: my_generic_file_read ---> my_do_generic_file_read ---> my_file_read_actor ---> my_decrypt_data I have not made any changes in my_generic_file_read and my_do_generic_file_read. In the function my_file_read_actor, I copy the page to my buffer (1 page - allocated at the time of mounting) I decrypt that buffer and pass it to the __copy_to_user() function. for encrypting, the sequence is: my_generic_file_write ---> my_encrypt_data In function my_generic_file_write, between functions __copy_from_user() and commit_write(), I am calling my_encrypt_data() by passing address of the page that is passed to __copy_from_user() My encrypt / decrypt routine is very basic at this time - just xoring every byte of the page as: *to = *to ^ 0xff; *to++; If I change my encrypt/decrypt routines to encrypt / decrypt just first or last byte of the page, then I get a different error saying the file is not executable - when I try to execute it. I thought there might be a problem with executable header, but I guess when I encrypt last byte of the page, header should have been bypassed. Is it something like, for executables, the data is refered in some other functions - that is, before do_generic_file_read geting called? Thanks and regards, Vineet --- On Tue 02/01, John T. Williams < [EMAIL PROTECTED] > wrote: From: John T. Williams [mailto: [EMAIL PROTECTED] To: [EMAIL PROTECTED], linux-kernel@vger.kernel.org Cc: linux-c-programming@vger.kernel.org Date: Tue, 1 Feb 2005 10:37:30 -0500 Subject: Re: Problem in accessing executable files This is just a thought.Text files are better able to handle small faults. ie an extra space orcharacters or even an unreadable piece of data might not cause the file tobecome unreadable by most text editors. Binary files aren't as flexible.Every bit could be an instruction to the processor and might cause a segfault.Just to test the theory, I would start by making the encrypt decryptfunction only effect the first byte. If doing this doesn't cause a segfault, I would recheck my decrypt encrypt algorithm to make sure it doesn'tpad or expand at any point. maybe use them on a regular file and the anmd5sum on the file before and after, just to make extra sure.- Original Message - From: "Vineet Joglekar" <[EMAIL PROTECTED]>To: Cc: Sent: Tuesday, February 01, 2005 8:58 AMSubject: Problem in accessing executable files>> Hi all,>> I am trying to add some cryptographic functionality to ext2 file systemfor my masters project. I am working with kernel 2.4.21>> since the routines do_generic_file_read and do_generic_file_write are usedin reading and writing, I am decrypting and encrypting the data in the resp.functions. This is working fine for regular data files. If I try to copy /execute executable files, I am getting segmentation fault. In kernelmessages, I see same functions (read and write) getting called for theexecutables also. If I comment encrypt/decrypt functions, its working fine.>> Now since it is working for regular text files, I suppose there is not aproblem in my encrypt/decrypt routines, then what might be going wrong?>> Thanks and regards,>> Vineet>> ___> Join Excite! - http://www.excite.com> The most personalized portal on the Web!> -> To unsubscribe from this list: send the line "unsubscribelinux-c-programming" in> the body of a message to [EMAIL PROTECTED]> More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dell Inspiron sensors (was: Re: Huge unreliability - does Linux have something to do with it?)
kernel wrote: > You might want to try this; > > Remove the keyboard, remove the cover beneath. Take a can of air dust > (or equivalent) and *carefully* blow out the inside of the laptop. > > -then- > > Look at the back side and the right side of the laptop. You'll see the > intake for air and the A/C unit. Take that air dust and blow in such > that the plastic fan whirls away. Take a snapshot of the dust bunnies > and send them to Dell. > > I have a 5150 Inspiron. In less than 1 year this thing started powering > off (hard) on its own, no matter the OS installed (multi-boot). I dug > around the 'net and found similar issues, all relating to OVERHEATING. > Poorly designed was the culprit, but Dell has not yet admitted to this > (but look at the Dell Linux forum or just Dell laptop forum and see > Dell's techs replies) - think of the numbers sold and it makes sense. Thank you very much for the pointers. I had just reached the same conclusion this afternoon, when pissed off by finding the CPU was at 85 C despite the fans being on at the max I did exactly what you suggest; although I didn't find any dust bunny, a thorough cleanup and blowing plus some toothpicking of hair and whatnot, I find myself with a computer that is running finely --again :) Too bad, I'll need another excuse to buy myself the new hard disk ... What about the sensors? -- Giuseppe "Oblomov" Bilotta Can't you see It all makes perfect sense Expressed in dollar and cents Pounds shillings and pence (Roger Waters) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-maintainer] [2.6 patch] DVB: remove bouncing address of Alex Woods
On Sun, Feb 06, 2005 at 09:59:21PM +0100, Holger Waechtler wrote: > Have you ever considered asking on the linux-dvb mailing list for a more > recent address? stop trolling and do something useful. please. I sent this patch to linux-dvb-maintainer (linux-dvb is useless for me since it requires subscription) and if someone knows a more recent email address of Alex Woods my patch is equivalent to the question you requested. > Bounces are sometimes temporary, contacting linux dvb developers is If the mail bounces because it wasn't able for the MTA to establish an SMTP connection for 7 days I'd not call that temporary. > usually easiest over the linux-dvb mailing list. Subscribe there if you > have a dvb-related problem and want to solve it. I'm sending small patches for many different areas of the kernel, and I do not plan to subscribe to 100 different subscribers-only mailing lists. > Holger 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: Intel AGP support attaching to wrong PCI IDs
Dave Jones wrote: Another way forward (somewhat hacky in one sense, but a lot cleaner in another) would be to change the PCI code so that it'll load and init multiple drivers that claim to support the same PCI ID. This may cause issues for some other drivers however where we have an old and a new driver with ID overlap. This sounds like it would allow the use of the parallel ATA interfaces on SATA controllers, which would make a lot of people happy. -- Ian Pilcher[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm1
Peter Osterlund <[EMAIL PROTECTED]> writes: > Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > > > On Sun, 2005-02-06 at 11:07 +0100, Peter Osterlund wrote: > > > Andrew Morton <[EMAIL PROTECTED]> writes: > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm1/ > > > > > > It gives me a kernel panic at boot if I have CONFIG_FB_RADEON > > > enabled. If I also have CONFIG_FRAMEBUFFER_CONSOLE enabled, I get this > > > output: > > > > > > Unable to handle kernel NULL pointer dereference at virtual > > > address > > > ... > > > PREEMPT > > > ... > > > EIP is a strncpy_from_user+0x33/0x47 > > > ... > > > Call Trace: > > > getname+0x69/0xa5 > > > sys_open+0x12/0xc6 > > > sysenter_past_esp+0x52/0x75 > > > ... > > > Kernel panic - not syncing: Attempted to kill init! > > > > > > If I don't have CONFIG_FRAMEBUFFER_CONSOLE enabled, I get a screen > > > with random junk and some blinking colored boxes, and the machine > > > hangs. > > > > That's very strange... I don't see what in radeonfb could cause this. > > Just in case, can you try commenting out the call to radeon_pm_init() in > > radeon_base.c, see if it makes any difference (though I don't think so). > > No, it didn't make any difference. I found the if I disable CONFIG_INOTIFY, the problem goes away. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BK PATCHES] ide-dev-2.6 update
Hi,
ChangeLog:
* sync with linux-2.6 tree
* merge "convert IDE device drivers to driver model" serie
(except the last patch which is the actual conversion :)
* fix ATAPI Power Management
BK users:
bk pull bk://bart.bkbits.net/ide-dev-2.6
This will update the following files:
drivers/ide/ide-default.c | 73 -
drivers/ide/Kconfig|8 -
drivers/ide/Makefile |3
drivers/ide/ide-cd.c | 220 +--
drivers/ide/ide-cd.h |4
drivers/ide/ide-disk.c | 327 +++--
drivers/ide/ide-dma.c |4
drivers/ide/ide-floppy.c | 172 +
drivers/ide/ide-io.c | 215 +-
drivers/ide/ide-iops.c | 20 ++
drivers/ide/ide-probe.c| 184 +++
drivers/ide/ide-proc.c | 20 +-
drivers/ide/ide-tape.c | 227 +---
drivers/ide/ide-taskfile.c | 20 +-
drivers/ide/ide.c | 166
drivers/ide/pci/pdc202xx_new.c |6
drivers/ide/pci/pdc202xx_old.c | 17 --
drivers/ide/pci/via82cxxx.c|7
drivers/ide/setup-pci.c| 15 -
drivers/scsi/ide-scsi.c| 111 -
include/linux/ide.h| 15 -
21 files changed, 1081 insertions(+), 753 deletions(-)
through these ChangeSets:
<[EMAIL PROTECTED](none)> (05/02/06 1.2130)
[ide] fix ATAPI Power Management
I've introduced bug in ATAPI Power Management handling,
idedisk_pm_idle shouldn't be done for ATAPI devices.
<[EMAIL PROTECTED](none)> (05/02/06 1.2129)
[ide] fix pdc202xx_{new,old}.c after linux-2.6 merge
<[EMAIL PROTECTED](none)> (05/02/04 1.2040.4.18)
[ide] kill ide-default
* add ide_drives list to list devices without a driver
* add __ide_add_setting() and use it for adding no auto remove entries
* kill ide-default pseudo-driver
<[EMAIL PROTECTED](none)> (05/02/04 1.2040.4.17)
[ide] get driver from rq->rq_disk->private_data
* add ide_driver_t * to device drivers objects
* set it to point at driver's ide_driver_t
* store address of this entry in disk->private_data
* fix ide_{cd,disk,floppy,tape,scsi}_g accordingly
* use rq->rq_disk->private_data instead of drive->driver
to obtain driver (this allows us to kill ide-default)
<[EMAIL PROTECTED](none)> (05/02/04 1.2040.4.16)
[ide] kill ide_drive_t->disk
* move ->disk from ide_drive_t to driver specific objects
* make drivers allocate struct gendisk and setup rq->rq_disk
(there is no need to do this for REQ_DRIVE_TASKFILE requests)
* add ide_init_disk() helper and kill alloc_disks() in ide-probe.c
* kill no longer needed ide_open() and ide_fops[] in ide.c
<[EMAIL PROTECTED](none)> (05/02/04 1.2040.4.15)
[ide] add ide_{un}register_region()
Add ide_{un}register_region() and fix ide-{tape,scsi}.c to register
block device number ranges. In ata_probe() only probe for modules.
Behavior is unchanged because:
* if driver is already loaded and attached to drive ata_probe()
is not called et all
* if driver is loaded by ata_probe() it will register new number range
for a drive and this range will be found by kobj_lookup()
If this is not clear please read http://lwn.net/Articles/25711/
and see drivers/base/map.c.
This patch makes it possible to move drive->disk allocation from
ide-probe.c to device drivers.
<[EMAIL PROTECTED](none)> (05/02/04 1.2040.4.14)
[ide] destroy_proc_ide_device() cleanup
When this function is called device is already unbinded from a
driver so there are no driver /proc entries to remove.
<[EMAIL PROTECTED](none)> (05/02/04 1.2040.4.13)
[ide] drive->dsc_overlap fix
drive->dsc_overlap is supported only by ide-{cd,tape} drivers.
Add missing clearing of ->dsc_overlap to ide_{cd,tape}_release()
and move ->dsc_overlap setup from ide_register_subdriver() to
ide_cdrom_setup() (ide-tape enables it unconditionally).
<[EMAIL PROTECTED](none)> (05/02/04 1.2040.4.12)
[ide] drive->nice1 fix
It is drive's property independent of the driver being used so move
drive->nice1 setup from ide_register_subdriver() to probe_hwif() in
ide-probe.c. As a result changing a driver which controls the drive
no longer affects this flag.
<[EMAIL PROTECTED](none)> (05/02/04 1.2040.4.11)
[ide] ide-tape: fix character device ->open() vs ->cleanup() race
Similar to the same race but for the block device.
* store pointer to struct ide_tape_obj in idetape_chrdevs[]
* rename idetape_chrdevs[] to idetape_devs[] and kill idetape_chrdev_t
* add ide_tape_chrdev_get() for getting reference to the tape
* store tape pointer in file->private_data and fix all users of it
* fix idetape_chrdev_{open,release}() to get/put reference to the tape
<[EMAIL PROTECTED](none)> (05/02/03 1.2040.4.10)
[ide] fix via82cxxx resume failure
Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)
On Sun, Feb 06, 2005 at 09:30:18PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
> How about this; Ignore entries addrconf_dst_alloc'ed entries in rt6_ifdown()?
Great, that definitely fixes the local address problem.
I'm not sure about anycast routes though. Who's going to delete them
when the real device goes down?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-maintainer] [2.6 patch] DVB: remove bouncing address of Alex Woods
Have you ever considered asking on the linux-dvb mailing list for a more
recent address? stop trolling and do something useful. please.
Bounces are sometimes temporary, contacting linux dvb developers is
usually easiest over the linux-dvb mailing list. Subscribe there if you
have a dvb-related problem and want to solve it.
Holger
Adrian Bunk wrote:
This patch removes the bouncing email address [EMAIL PROTECTED] of
Alex Woods.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/media/dvb/ttusb-dec/ttusb_dec.c |4 ++--
drivers/media/dvb/ttusb-dec/ttusbdecfe.c |2 +-
drivers/media/dvb/ttusb-dec/ttusbdecfe.h |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
--- linux-2.6.11-rc3-mm1-full/drivers/media/dvb/ttusb-dec/ttusbdecfe.h.old
2005-02-06 21:18:09.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/media/dvb/ttusb-dec/ttusbdecfe.h
2005-02-06 21:18:31.0 +0100
@@ -1,7 +1,7 @@
/*
* TTUSB DEC Driver
*
- * Copyright (C) 2003-2004 Alex Woods <[EMAIL PROTECTED]>
+ * Copyright (C) 2003-2004 Alex Woods
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
--- linux-2.6.11-rc3-mm1-full/drivers/media/dvb/ttusb-dec/ttusb_dec.c.old
2005-02-06 21:18:43.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/media/dvb/ttusb-dec/ttusb_dec.c
2005-02-06 21:18:53.0 +0100
@@ -1,7 +1,7 @@
/*
* TTUSB DEC Driver
*
- * Copyright (C) 2003-2004 Alex Woods <[EMAIL PROTECTED]>
+ * Copyright (C) 2003-2004 Alex Woods
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -1583,7 +1583,7 @@
module_init(ttusb_dec_init);
module_exit(ttusb_dec_exit);
-MODULE_AUTHOR("Alex Woods <[EMAIL PROTECTED]>");
+MODULE_AUTHOR("Alex Woods");
MODULE_DESCRIPTION(DRIVER_NAME);
MODULE_LICENSE("GPL");
MODULE_DEVICE_TABLE(usb, ttusb_dec_table);
--- linux-2.6.11-rc3-mm1-full/drivers/media/dvb/ttusb-dec/ttusbdecfe.c.old
2005-02-06 21:19:01.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/media/dvb/ttusb-dec/ttusbdecfe.c
2005-02-06 21:19:06.0 +0100
@@ -1,7 +1,7 @@
/*
* TTUSB DEC Frontend Driver
*
- * Copyright (C) 2003-2004 Alex Woods <[EMAIL PROTECTED]>
+ * Copyright (C) 2003-2004 Alex Woods
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: [PATCH-2.6] Add helper function to lock multiple page cache pages.
Anton Altaparmakov <[EMAIL PROTECTED]> wrote: > > On Thu, 3 Feb 2005, Andrew Morton wrote: > > I did a patch which switched loop to use the file_operations.read/write > > about a year ago. Forget what happened to it. It always seemed the right > > thing to do.. > > How did you implement the write? It was Urban, actually. Memory fails me. http://marc.theaimsgroup.com/?l=linux-fsdevel=102133217310200=2 It won't work properly for crypto transformations - iirc we decided it would need to perform a copy. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6] I2C: New chip driver: sis5595 (resubmit)
Hi Greg, Please find below the new version of the patch against kernel 2.6.11-rc3-mm1 to add the sis5595 driver (sensor part). As you suggested, I have changed the PCI part of the driver, taking the via686a driver as an example. I have also changed the comparison of jiffies by using time_after. Please apply. Thanks, Aurelien Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]> diff -urN linux-2.6.11-rc3-mm1.orig/drivers/i2c/chips/Kconfig linux-2.6.11-rc3-mm1/drivers/i2c/chips/Kconfig --- linux-2.6.11-rc3-mm1.orig/drivers/i2c/chips/Kconfig 2005-02-06 19:23:59.0 +0100 +++ linux-2.6.11-rc3-mm1/drivers/i2c/chips/Kconfig 2005-02-06 20:30:07.0 +0100 @@ -262,6 +262,18 @@ This driver can also be built as a module. If so, the module will be called smsc47b397. +config SENSORS_SIS5595 + tristate "Silicon Integrated Systems Corp. SiS5595" + depends on I2C && PCI && EXPERIMENTAL + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get support for the integrated sensors in + SiS5595 South Bridges. + + This driver can also be built as a module. If so, the module + will be called sis5595. + config SENSORS_SMSC47M1 tristate "SMSC LPC47M10x and compatibles" depends on I2C && EXPERIMENTAL diff -urN linux-2.6.11-rc3-mm1.orig/drivers/i2c/chips/Makefile linux-2.6.11-rc3-mm1/drivers/i2c/chips/Makefile --- linux-2.6.11-rc3-mm1.orig/drivers/i2c/chips/Makefile2005-02-06 19:23:59.0 +0100 +++ linux-2.6.11-rc3-mm1/drivers/i2c/chips/Makefile 2005-02-06 20:30:07.0 +0100 @@ -31,6 +31,7 @@ obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o obj-$(CONFIG_SENSORS_RTC8564) += rtc8564.o +obj-$(CONFIG_SENSORS_SIS5595) += sis5595.o obj-$(CONFIG_SENSORS_SMSC47B397)+= smsc47b397.o obj-$(CONFIG_SENSORS_SMSC47M1) += smsc47m1.o obj-$(CONFIG_SENSORS_VIA686A) += via686a.o diff -urN linux-2.6.11-rc3-mm1.orig/drivers/i2c/chips/sis5595.c linux-2.6.11-rc3-mm1/drivers/i2c/chips/sis5595.c --- linux-2.6.11-rc3-mm1.orig/drivers/i2c/chips/sis5595.c 1970-01-01 01:00:00.0 +0100 +++ linux-2.6.11-rc3-mm1/drivers/i2c/chips/sis5595.c2005-02-06 21:14:44.0 +0100 @@ -0,0 +1,794 @@ +/* +sis5595.c - Part of lm_sensors, Linux kernel modules + for hardware monitoring + +Copyright (C) 1998 - 2001 Frodo Looijaard <[EMAIL PROTECTED]>, + Kyösti Mälkki <[EMAIL PROTECTED]>, and + Mark D. Studebaker <[EMAIL PROTECTED]> +Ported to Linux 2.6 by Aurelien Jarno <[EMAIL PROTECTED]> with +the help of Jean Delvare <[EMAIL PROTECTED]> + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or +(at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +*/ + +/* + SiS southbridge has a LM78-like chip integrated on the same IC. + This driver is a customized copy of lm78.c + + Supports following revisions: + Version PCI ID PCI Revision + 1 1039/0008 AF or less + 2 1039/0008 B0 or greater + + Note: these chips contain a 0008 device which is incompatible with the +5595. We recognize these by the presence of the listed +"blacklist" PCI ID and refuse to load. + + NOT SUPPORTED PCI ID BLACKLIST PCI ID +54000080540 +55000080550 + 551300085511 + 558100085597 + 558200085597 + 559700085597 + 559800085597/5598 +63000080630 +64500080645 +73000080730 +73500080735 +*/ + +#include +#include +#include +#include +#include +#include +#include +#include + + +/* If force_addr is set to anything different from 0, we forcibly enable + the device at the given address. */ +static u16 force_addr; +module_param(force_addr, ushort, 0); +MODULE_PARM_DESC(force_addr, +"Initialize the base address of the sensors"); + +/* Addresses to scan. + Note that we can't determine the ISA address until we have initialized + our
Re: Intel AGP support attaching to wrong PCI IDs
On Sun, 6 Feb 2005, Dave Jones wrote: > Another way forward (somewhat hacky in one sense, but a lot cleaner in > another) > would be to change the PCI code so that it'll load and init > multiple drivers that claim to support the same PCI ID. That might actually be useful to support some weird hardware. E.g. I have a single-function PCI device which reports as a graphics adapter (either VGA or other, depending on the configuration), but besides the actual graphics adapter the chip includes a frame grabber, an USB host controller, an Ethernet interface, an IEEE 1284 parallel port, an UART, an I2C controller and a PS/2 keybard/mouse controller. ;-) All of these mapped with a single PCI BAR; the chip can also be configured for legacy mapping of some devices, like the PS/2 stuff. Maciej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OOPS] 2.6.10-ac9 while watching TV and disk IO
This oops happened while watching TV and burning a CD. Other oopses (I guess, didn't verify at that time) happened while copying many large files and watching TV at the same time. Note1: /proc/ksyms does not exist. What to do? Note2: ksymoops prints this error message to /dev/stderr: ksymoops: No such file or directory This message should IMO include the file name. ksymoops 2.4.9 on i686 2.6.10-ac9. Options used -v /home/7eggert/l/linux/2.6/linux-2.6.10-ac9/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.6.10-ac9/ (default) -m /home/7eggert/l/linux/2.6/linux-2.6.10-ac9/System.map (specified) Error (regular_file): read_ksyms stat /proc/ksyms failed No modules in ksyms, skipping objects No ksyms, skipping lsmod Unable to handle kernel paging request at virtual address 3c73a7d9 c01365e6 *pde = Oops: 0002 [#1] CPU:0 EIP:0060:[]Not tainted VLI Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010016 (2.6.10-ac9) eax: 3c73a7d5 ebx: c7a7d000 ecx: c7a7de40 edx: d9f09020 esi: dffb4860 edi: 0017 ebp: dffb486c esp: c1547e8c ds: 007b es: 007b ss: 0068 Stack: dffb487c 001b dffbf970 dffbf970 dffb4860 d4d9db90 c14d5960 c013669d 001b dffbf960 dffbf960 0292 d4d9db90 0080 c013687a d4d9dbdc c1547efc 0020 c0163255 d4d9dbdc c016347f c1546000 c7a7de8c 0080 Call Trace: [] cache_flusharray+0x4d/0xf0 [] kmem_cache_free+0x3a/0x50 [] destroy_inode+0x35/0x40 [] dispose_list+0x1f/0xa0 [] prune_icache+0x186/0x200 [] shrink_icache_memory+0x14/0x40 [] shrink_slab+0xff/0x160 [] balance_pgdat+0x1ee/0x2d0 [] kswapd+0xb8/0xd0 [] autoremove_wake_function+0x0/0x50 [] ret_from_fork+0x6/0x14 [] autoremove_wake_function+0x0/0x50 [] kswapd+0x0/0xd0 [] kernel_thread_helper+0x5/0x18 Code: 43 04 47 3b 7c 24 04 7d 64 8b 44 24 08 8b 15 d0 22 4f c0 8b 0c b8 8d 81 00 00 00 40 c1 e8 0c c1 e0 05 8b 5c 02 1c 8b 53 04 8b 03 <89> 50 04 89 02 c7 43 04 00 02 20 00 2b 4b 0c c7 03 00 01 10 00 >>EIP; c01365e6<= >>ebx; c7a7d000 >>ecx; c7a7de40 >>edx; d9f09020 >>esi; dffb4860 >>ebp; dffb486c >>esp; c1547e8c Trace; c013669d Trace; c013687a Trace; c0163255 Trace; c016347f Trace; c0163896 Trace; c0163924 Trace; c013843f Trace; c01397fe Trace; c0139998 Trace; c0126c00 Trace; c0102512 Trace; c0126c00 Trace; c01398e0 Trace; c010082d This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt. Code; c01365bb <_EIP>: Code; c01365bb 0: 43inc%ebx Code; c01365bc 1: 04 47 add$0x47,%al Code; c01365be 3: 3b 7c 24 04 cmp0x4(%esp,1),%edi Code; c01365c2 7: 7d 64 jge6d <_EIP+0x6d> Code; c01365c4 9: 8b 44 24 08 mov0x8(%esp,1),%eax Code; c01365c8 d: 8b 15 d0 22 4f c0 mov0xc04f22d0,%edx Code; c01365ce 13: 8b 0c b8 mov(%eax,%edi,4),%ecx Code; c01365d1 16: 8d 81 00 00 00 40 lea0x4000(%ecx),%eax Code; c01365d7 1c: c1 e8 0c shr$0xc,%eax Code; c01365da 1f: c1 e0 05 shl$0x5,%eax Code; c01365dd 22: 8b 5c 02 1c mov0x1c(%edx,%eax,1),%ebx Code; c01365e1 26: 8b 53 04 mov0x4(%ebx),%edx Code; c01365e4 29: 8b 03 mov(%ebx),%eax This decode from eip onwards should be reliable Code; c01365e6 <_EIP>: Code; c01365e6<= 0: 89 50 04 mov%edx,0x4(%eax) <= Code; c01365e9 3: 89 02 mov%eax,(%edx) Code; c01365eb 5: c7 43 04 00 02 20 00 movl $0x200200,0x4(%ebx) Code; c01365f2 c: 2b 4b 0c sub0xc(%ebx),%ecx Code; c01365f5 f: c7 03 00 01 10 00 movl $0x100100,(%ebx) Unable to handle kernel paging request at virtual address 00200204 c01365e1 *pde = Oops: [#2] CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010016 (2.6.10-ac9) eax: 0035a0c0 ebx: 00200200 ecx: dad06030 edx: c100 esi: dffb4860 edi: 000a ebp: dffb486c esp: c14e9efc ds: 007b es: 007b ss: 0068 Stack: dffb487c 000b dffbf970 dffbf970 dffbf960 000b dffb4860 c0136bd3 dffb47fc dffb4860 c14e8000 0002 c0136c6e dffb47fc c14e8000 dffb48d0 c14da17c c04f21e0 c14e8000 c04f21e4 0297 c012296d c14e9f70 Call Trace: [] drain_array_locked+0x73/0xa0 [] cache_reap+0x6e/0x1b0 [] worker_thread+0x1ad/0x290 [] activate_task+0x5c/0x70 [] cache_reap+0x0/0x1b0 [] default_wake_function+0x0/0x10 [] __wake_up_common+0x37/0x60 [] default_wake_function+0x0/0x10 [] worker_thread+0x0/0x290 [] kthread+0x95/0xd0 [] kthread+0x0/0xd0 [] kernel_thread_helper+0x5/0x18 Code: 24 89 5e 1c 89 43 04 47
[2.6 patch] DVB: remove bouncing address of Alex Woods
This patch removes the bouncing email address [EMAIL PROTECTED] of
Alex Woods.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/media/dvb/ttusb-dec/ttusb_dec.c |4 ++--
drivers/media/dvb/ttusb-dec/ttusbdecfe.c |2 +-
drivers/media/dvb/ttusb-dec/ttusbdecfe.h |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
--- linux-2.6.11-rc3-mm1-full/drivers/media/dvb/ttusb-dec/ttusbdecfe.h.old
2005-02-06 21:18:09.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/media/dvb/ttusb-dec/ttusbdecfe.h
2005-02-06 21:18:31.0 +0100
@@ -1,7 +1,7 @@
/*
* TTUSB DEC Driver
*
- * Copyright (C) 2003-2004 Alex Woods <[EMAIL PROTECTED]>
+ * Copyright (C) 2003-2004 Alex Woods
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
--- linux-2.6.11-rc3-mm1-full/drivers/media/dvb/ttusb-dec/ttusb_dec.c.old
2005-02-06 21:18:43.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/media/dvb/ttusb-dec/ttusb_dec.c
2005-02-06 21:18:53.0 +0100
@@ -1,7 +1,7 @@
/*
* TTUSB DEC Driver
*
- * Copyright (C) 2003-2004 Alex Woods <[EMAIL PROTECTED]>
+ * Copyright (C) 2003-2004 Alex Woods
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -1583,7 +1583,7 @@
module_init(ttusb_dec_init);
module_exit(ttusb_dec_exit);
-MODULE_AUTHOR("Alex Woods <[EMAIL PROTECTED]>");
+MODULE_AUTHOR("Alex Woods");
MODULE_DESCRIPTION(DRIVER_NAME);
MODULE_LICENSE("GPL");
MODULE_DEVICE_TABLE(usb, ttusb_dec_table);
--- linux-2.6.11-rc3-mm1-full/drivers/media/dvb/ttusb-dec/ttusbdecfe.c.old
2005-02-06 21:19:01.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/media/dvb/ttusb-dec/ttusbdecfe.c
2005-02-06 21:19:06.0 +0100
@@ -1,7 +1,7 @@
/*
* TTUSB DEC Frontend Driver
*
- * Copyright (C) 2003-2004 Alex Woods <[EMAIL PROTECTED]>
+ * Copyright (C) 2003-2004 Alex Woods
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3] IBM Trackpoint support
I'm a bit late, sorry. Haven't seen these mentioned in replies:
On 03/02/05 17:43 -0500, Stephen Evanchik wrote:
> +int tp_sens = TP_DEF_SENS;
> +module_param_named(sens, tp_sens, uint, 0);
> +MODULE_PARM_DESC(sens, "Sensitivity");
I don't see out-of-file usages... these could be static.
...
> + static int name(char* page, char** start, off_t off, int count, int*
> eof, void* data) \
> + { \
> + int len; \
> + struct psmouse *psmouse = (struct psmouse *)data; \
> + struct trackpoint_data *tp = (struct
> trackpoint_data*)psmouse->private; \
No need to cast (void *).
...
> +static int scroll_write_func(struct file *file, const char __user
> *buffer, unsigned long count, void *data)
> +{
> + int len = count;
> + unsigned char tmp[5];
> + struct psmouse *psmouse = (struct psmouse *)data;
> + struct trackpoint_data *tp = (struct trackpoint_data*)psmouse->private;
> + if(count > sizeof(tmp) - 1)
> + len = sizeof(tmp) - 1;
How about: len = min(count, sizeof(tmp) - 1);?
...
> +no_ext_dev:
Nitpick:
Some like ' ' before label (makes diff -pu patches more readable)
Domen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-rc3 BUG: using smp_processor_id() in preemptible [00000001] code: ip/6840
Frank van Maarseveen wrote: While executing iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport https -j DNAT --to 192.168.0.1 iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport http -j DNAT --to 192.168.0.1 ip route del default ip addr del 80.126.170.174 dev eth0 on a dual PIII during a shutdown: kernel: BUG: using smp_processor_id() in preemptible [0001] code: ip/6840 kernel: caller is get_next_corpse+0x13/0x260 kernel: [] dump_stack+0x1e/0x30 kernel: [] smp_processor_id+0xaf/0xc0 kernel: [] get_next_corpse+0x13/0x260 kernel: [] ip_ct_iterate_cleanup+0x36/0xc0 kernel: [] masq_inet_event+0x3a/0x70 kernel: [] notifier_call_chain+0x2d/0x50 kernel: [] inet_del_ifa+0x99/0x150 kernel: [] inet_rtm_deladdr+0x12b/0x170 kernel: [] rtnetlink_rcv+0x347/0x410 kernel: [] netlink_data_ready+0x60/0x70 kernel: [] netlink_sendskb+0x31/0x60 kernel: [] netlink_sendmsg+0x259/0x310 kernel: [] sock_sendmsg+0xbb/0xe0 kernel: [] sys_sendmsg+0x1c4/0x230 kernel: [] sys_socketcall+0x21c/0x240 kernel: [] syscall_call+0x7/0xb kernel: BUG: using smp_processor_id() in preemptible [0001] code: ip/6840 kernel: caller is get_next_corpse+0x23f/0x260 kernel: [] dump_stack+0x1e/0x30 kernel: [] smp_processor_id+0xaf/0xc0 kernel: [] get_next_corpse+0x23f/0x260 kernel: [] ip_ct_iterate_cleanup+0x36/0xc0 kernel: [] masq_inet_event+0x3a/0x70 kernel: [] notifier_call_chain+0x2d/0x50 kernel: [] inet_del_ifa+0x99/0x150 kernel: [] inet_rtm_deladdr+0x12b/0x170 kernel: [] rtnetlink_rcv+0x347/0x410 kernel: [] netlink_data_ready+0x60/0x70 kernel: [] netlink_sendskb+0x31/0x60 kernel: [] netlink_sendmsg+0x259/0x310 kernel: [] sock_sendmsg+0xbb/0xe0 kernel: [] sys_sendmsg+0x1c4/0x230 kernel: [] sys_socketcall+0x21c/0x240 kernel: [] syscall_call+0x7/0xb Hi! You have to use get_cpu() or __smp_processor_id() to avoid this debug message. Have a look at inlcude/linux/smp.h and include/asm-i386/smp.h. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] hid-core: Configurable USB HID Mouse Interrupt Polling Interval
Thanks for the suggestions. :)
I'm wondering if there perhaps is a more clean way to do this? Perhaps
something that would give the user the possibility to change the
polling interface per device, or something like that, perhaps exported
to sysfs? Though, since you mentioned that the endpoint descriptor
should be considered read only, I guess not.
And oh, would adding other parameters make sense? For instance for
gamepads, joysticks etc.? Also, is there any chance of this getting
into the driver? :)
Thanks,
Mikkel
On Sun, 6 Feb 2005 20:07:24 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 19, 2004 at 01:52:06AM +, Mikkel Krautz wrote:
> > On Sat, 18 Dec 2004 08:53:31 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > > On Sat, Dec 18, 2004 at 05:39:25PM +, Mikkel Krautz wrote:
> > > > On Fri, 17 Dec 2004 18:59:48 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > > > > What about makeing it a module paramater then, that is exported to
> > > > > sysfs? That makes it easier to adjust on the fly (before the mouse is
> > > > > inserted), and doesn't require the kernel to be rebuilt.
> > > >
> > > > I really like the idea. I'm start to think that this is the ideal way to
> > > > accomplish this.
> > > >
> > > > Here's a new patch. Let's hope it doesn't wrap!
> > >
> > > It was eaten :(
> > >
> > > > module_init(hid_init);
> > > > module_exit(hid_exit);
> > > > +module_param(hid_mouse_polling_interval, int, 644);
> > >
> > > 0644, or use the proper #defines instead.
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> >
> > Here's an updated version, with your and Marcel's suggestions:
>
> Some more suggestions:
>
> A MODULE_PARM_DESC() would be good, as well as a patch to
> kernel-parameters.txt.
>
> Also, it'd be better instead of changing the bInterval in the endpoint
> descriptor to change the "interval" variable. This way one wouldn't need
> to think about whether the device is Full-speed or High-speed when
> setting the parameter. Also the endpoint descriptor should be considered
> read only.
>
> > Signed-off-by: Mikkel Krautz <[EMAIL PROTECTED]>
> > ---
> >
> >
> > hid-core.c |9 -
> > 1 files changed, 8 insertions(+), 1 deletion(-)
> >
> >
> > --- clean/drivers/usb/input/hid-core.c
> > +++ dirty/drviers/usb/input/hid-core.c
> > @@ -37,11 +37,12 @@
> > * Version Information
> > */
> >
> > -#define DRIVER_VERSION "v2.0"
> > +#define DRIVER_VERSION "v2.01"
> > #define DRIVER_AUTHOR "Andreas Gal, Vojtech Pavlik"
> > #define DRIVER_DESC "USB HID core driver"
> > #define DRIVER_LICENSE "GPL"
> >
> > +static unsigned int hid_mousepoll_interval;
> > static char *hid_types[] = {"Device", "Pointer", "Mouse", "Device",
> > "Joystick",
> > "Gamepad", "Keyboard", "Keypad", "Multi-Axis
> > Controller"};
> >
> > @@ -1663,6 +1664,11 @@
> > if ((endpoint->bmAttributes & 3) != 3) /* Not an
> > interrupt endpoint */
> > continue;
> >
> > + /* Change the polling interval of mice. */
> > + if (hid->collection->usage == HID_GD_MOUSE
> > + && hid_mousepoll_interval > 0)
> > + endpoint->bInterval = hid_mousepoll_interval;
> > +
> > /* handle potential highspeed HID correctly */
> > interval = endpoint->bInterval;
> > if (dev->speed == USB_SPEED_HIGH)
> > @@ -1910,6 +1916,7 @@
> >
> > module_init(hid_init);
> > module_exit(hid_exit);
> > +module_param_named(mousepoll, hid_mousepoll_interval, uint, 0644);
> >
> > MODULE_AUTHOR(DRIVER_AUTHOR);
> > MODULE_DESCRIPTION(DRIVER_DESC);
> >
>
> --
> Vojtech Pavlik
> SuSE Labs, SuSE CR
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/input/gameport/cs461x.c: remove bouncing email address
On Sun, Feb 06, 2005 at 08:30:14PM +0100, Adrian Bunk wrote:
> This patch remoces the bouncing email address of Victor Krapivin from
> MODULE_AUTHOR.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> --- linux-2.6.11-rc3-mm1-full/drivers/input/gameport/cs461x.c.old
> 2005-02-06 20:24:35.0 +0100
> +++ linux-2.6.11-rc3-mm1-full/drivers/input/gameport/cs461x.c 2005-02-06
> 20:24:49.0 +0100
> @@ -16,7 +16,7 @@
> #include
> #include
>
> -MODULE_AUTHOR("Victor Krapivin <[EMAIL PROTECTED]>");
> +MODULE_AUTHOR("Victor Krapivin");
> MODULE_LICENSE("GPL");
Thanks; applied.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.11-rc3 BUG: using smp_processor_id() in preemptible [00000001] code: ip/6840
While executing iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport https -j DNAT --to 192.168.0.1 iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport http -j DNAT --to 192.168.0.1 ip route del default ip addr del 80.126.170.174 dev eth0 on a dual PIII during a shutdown: kernel: BUG: using smp_processor_id() in preemptible [0001] code: ip/6840 kernel: caller is get_next_corpse+0x13/0x260 kernel: [] dump_stack+0x1e/0x30 kernel: [] smp_processor_id+0xaf/0xc0 kernel: [] get_next_corpse+0x13/0x260 kernel: [] ip_ct_iterate_cleanup+0x36/0xc0 kernel: [] masq_inet_event+0x3a/0x70 kernel: [] notifier_call_chain+0x2d/0x50 kernel: [] inet_del_ifa+0x99/0x150 kernel: [] inet_rtm_deladdr+0x12b/0x170 kernel: [] rtnetlink_rcv+0x347/0x410 kernel: [] netlink_data_ready+0x60/0x70 kernel: [] netlink_sendskb+0x31/0x60 kernel: [] netlink_sendmsg+0x259/0x310 kernel: [] sock_sendmsg+0xbb/0xe0 kernel: [] sys_sendmsg+0x1c4/0x230 kernel: [] sys_socketcall+0x21c/0x240 kernel: [] syscall_call+0x7/0xb kernel: BUG: using smp_processor_id() in preemptible [0001] code: ip/6840 kernel: caller is get_next_corpse+0x23f/0x260 kernel: [] dump_stack+0x1e/0x30 kernel: [] smp_processor_id+0xaf/0xc0 kernel: [] get_next_corpse+0x23f/0x260 kernel: [] ip_ct_iterate_cleanup+0x36/0xc0 kernel: [] masq_inet_event+0x3a/0x70 kernel: [] notifier_call_chain+0x2d/0x50 kernel: [] inet_del_ifa+0x99/0x150 kernel: [] inet_rtm_deladdr+0x12b/0x170 kernel: [] rtnetlink_rcv+0x347/0x410 kernel: [] netlink_data_ready+0x60/0x70 kernel: [] netlink_sendskb+0x31/0x60 kernel: [] netlink_sendmsg+0x259/0x310 kernel: [] sock_sendmsg+0xbb/0xe0 kernel: [] sys_sendmsg+0x1c4/0x230 kernel: [] sys_socketcall+0x21c/0x240 kernel: [] syscall_call+0x7/0xb -- Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove pointless <0 comparisons for unsigned vars, and avoid a few signed vs unsigned comparisons in drivers/char/keyboard.c
On Mon, Nov 22, 2004 at 12:21:55AM +0100, Jesper Juhl wrote: > > Hi, > > Sorry about the possibly irrelevant CC list, but I couldn't find a > maintainer for drivers/char/keyboard.c listed anywhere, so I ended up > sending to lkml and CC'ing a few people who has worked on the file, and > akpm as a fallback person due to his 2.6 maintainer role. > > Here's a patch that removes a few pointless comparisons; "scancode" is > unsigned so it can never be <0 which makes the test pointless. > Also, there are a few instances where signed and unsigned variables are > comared, and as far as I can tell they really should just all be unsigned. > > Comments welcome (I must confess that I've only compile tested this so > far). > > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> Looks sane: Applied. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] i386/x86_64: acpi/sleep.c: kill unused acpi_save_state_disk
On Sun, Feb 06, 2005 at 07:44:47PM +0100, Adrian Bunk wrote: > acpi_save_state_disk does nothing and is completely unused. > > This patch was already ACK'ed by Pavel Machek. Since it affects both i386 and x86-64 it should be pushed by the ACPI people. However it's no bugfix and so definitely nothing for 2.6.11, so it'll take quite some time anyways. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: [PATCH-2.6] Add helper function to lock multiple page cache pages.
On Thu, 3 Feb 2005, Andrew Morton wrote:
> I did a patch which switched loop to use the file_operations.read/write
> about a year ago. Forget what happened to it. It always seemed the right
> thing to do..
How did you implement the write? At the moment the loop driver gets hold
of both source and destination pages (the latter via grab_cache_page() and
aops->prepare_write()) and copies/transforms directly from the source to
the destination page (and then calls commit_write() on the destination
page). Did you allocate a buffer for each request, copy/transform to the
buffer and then submit the buffer via file_operations->write? That would
clearly be not very efficient but given fops->write() is not atomic I
don't see how that could be optimised further...
Perhaps the loop driver should work as is when
aops->{prepare,commit}_write() are not NULL and should fall back to
a buffered fops->write() otherwise?
Or have I missed some way in which the fops->write() case can be
optimized?
Best regards,
Anton
--
Anton Altaparmakov (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] raw1394 : Fix hang on unload
I was seeing rmmod getting stuck consistently in D state while removing
raw1394. Looking at raw1394.c:cleanup_raw1394 - the order of doing
things seemed incorrect to me after comparing other places in raw1394.c
which do the same thing but with a different order.
bash R running task 0 4319 38843900
(NOTLB)
rmmod D 008428792a16 0 4490 3900
(NOTLB)
81001cff9dd8 0082 0001
0074 8100211c9070 097b
81002c8a2800
80397c97 81002b6f9360
Call Trace:{__down+421}
{default_wake_function+0}
{__down_failed+53}
{generic_delete_inode+0}
{.text.lock.driver+5}
{:raw1394:cleanup_raw1394+16}
{sys_delete_module+497}
{__up_write+514}
{sys_munmap+107} {system_call
+126}
Attached patch fixes the rmmod raw1394 hang. Tested.
Parag
--- drivers/ieee1394/raw1394.c.orig 2005-02-06 14:34:58.0 -0500
+++ drivers/ieee1394/raw1394.c 2005-02-06 14:36:18.0 -0500
@@ -2758,10 +2758,10 @@
static void __exit cleanup_raw1394(void)
{
- hpsb_unregister_protocol(_driver);
cdev_del(_cdev);
devfs_remove(RAW1394_DEVICE_NAME);
hpsb_unregister_highlevel(_highlevel);
+ hpsb_unregister_protocol(_driver);
}
module_init(init_raw1394);
[2.6 patch] drivers/input/gameport/cs461x.c: remove bouncing email address
This patch remoces the bouncing email address of Victor Krapivin from
MODULE_AUTHOR.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.11-rc3-mm1-full/drivers/input/gameport/cs461x.c.old
2005-02-06 20:24:35.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/input/gameport/cs461x.c 2005-02-06
20:24:49.0 +0100
@@ -16,7 +16,7 @@
#include
#include
-MODULE_AUTHOR("Victor Krapivin <[EMAIL PROTECTED]>");
+MODULE_AUTHOR("Victor Krapivin");
MODULE_LICENSE("GPL");
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bug in tty_io.c after changes between 2.6.9-rc1-bk1 and 2.6.9-rc1-bk2
On Sun, Feb 06, Olaf Hering wrote: > Do you have an outdated udev package with bogus udev.rules? Your strace clearly shows /dev/tty as a directory. Go and ask Linus to revert your broken patch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc3-mm1: softlockup and suspend/resume
Hi,
On Saturday, 5 of February 2005 20:07, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > I've attached a patch for touch_softlockup_watchdog() below - but i think
> > > what we really need is another mechanism. I'm wondering what the primary
> > > reason for the lockup-detection is - did swsuspend stop the the softlockup
> > > threads?
> >
> > If my understanding is correct, the time between suspend (ie the
> > creation of the image) and resume (ie the resotration of the image) is
> > considered as spent in the kernel, so it triggers softlockup as soon
> > as its threads are woken up (is that correct, Pavel?).
>
> ah, ok. Could you try my patch and add touch_softlockup_watchdog() to
> the resume code (before interrupts are re-enabled)?
I did:
--- /home/rafael/tmp/kernel/testing/linux-2.6.11-rc3-mm1/kernel/power/swsusp.c
2005-02-05 20:57:03.0 +0100
+++ linux-2.6.11-rc3-mm1/kernel/power/swsusp.c 2005-02-06 19:07:39.0
+0100
@@ -871,6 +869,7 @@
restore_processor_state();
restore_highmem();
device_power_up();
+ touch_softlockup_watchdog();
local_irq_enable();
return error;
}
and it still complains, but the call trace is now different:
BUG: soft lockup detected on CPU#0!
Feb 6 19:50:02 albercik kernel:
Feb 6 19:50:03 albercik kernel: Modules linked in: snd_seq snd_seq_device
usbserial parport_pc lp parport thermal processor fan button battery ac snd_pc
m_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore
snd_page_alloc ipt_TOS ipt_LOG ipt_limit ipt_pkttype af_packet ipt_state
ipt_REJECT iptable_mangle iptable_filter ip6table_mangle ip_nat_ftp iptable_nat
ip_conntrack_ftp ip_conntrack ip_tables ip6table_filter ip6_tables ipv6 p
cmcia binfmt_misc joydev sg st sd_mod sr_mod scsi_mod ide_cd cdrom ohci1394
ieee1394 yenta_socket rsrc_nonstatic pcmcia_core sk98lin usbhid ehci_hcd i2c_
nforce2 i2c_core ohci_hcd dm_mod evdev
Feb 6 19:50:05 albercik kernel: Pid: 8679, comm: do_acpi_sleep Not tainted
2.6.11-rc3-mm1
Feb 6 19:50:07 albercik kernel: RIP: 0010:[]
{acpi_ut_find_allocation+50}
Feb 6 19:50:11 albercik kernel: RSP: :81000d8af818 EFLAGS: 0202
Feb 6 19:50:14 albercik kernel: RAX: 81001c91fa80 RBX: 8100123caeb0
RCX: 8100123caeb0
Feb 6 19:50:16 albercik kernel: RDX: 81001ed73878 RSI: 8100123caeb0
RDI:
Feb 6 19:50:17 albercik kernel: RBP: 803ea5b8 R08: 21e7
R09: 803f478a
Feb 6 19:50:19 albercik kernel: R10: R11:
R12: 803ea6b9
Feb 6 19:50:21 albercik kernel: R13: 0400 R14: 0246
R15: 21e7
Feb 6 19:50:22 albercik kernel: FS: 2b28b800()
GS:80567800() knlGS:
Feb 6 19:50:24 albercik kernel: CS: 0010 DS: ES: CR0:
8005003b
Feb 6 19:50:25 albercik kernel: CR2: 2ac4e642 CR3: 0d876000
CR4: 06e0
Feb 6 19:50:27 albercik kernel:
Feb 6 19:50:28 albercik kernel: Call
Trace:{acpi_ut_find_allocation+13}
{acpi_ut_track_allocation+169}
Feb 6 19:50:28 albercik kernel:
{acpi_ut_callocate_and_track+95}
Feb 6 19:50:29 albercik kernel:
{acpi_ut_acquire_from_cache+62}
{acpi_ut_create_generic_state+17}
Feb 6 19:50:32 albercik kernel:
{acpi_ds_result_stack_push+42}
{acpi_ds_create_walk_state+152}
Feb 6 19:50:37 albercik kernel:
{acpi_ut_create_thread_state+106}
Feb 6 19:50:39 albercik kernel:
{acpi_ps_delete_parse_tree+113}
{acpi_ps_complete_this_op+476}
Feb 6 19:50:39 albercik kernel:
{acpi_ps_parse_loop+1897}
{acpi_ds_delete_walk_state+297}
Feb 6 19:50:41 albercik kernel:
{acpi_ps_parse_aml+237}
{acpi_psx_execute+546}
Feb 6 19:50:42 albercik kernel:
{acpi_ex_enter_interpreter+114}
{acpi_ns_execute_control_method+260}
Feb 6 19:50:44 albercik kernel:
{acpi_ns_evaluate_by_handle+249}
Feb 6 19:50:45 albercik kernel:
{acpi_ns_evaluate_relative+400}
{acpi_rs_set_srs_method_data+250}
Feb 6 19:50:45 albercik kernel:{check_poison_obj+48}
{acpi_set_current_resources+122}
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] hid-core: Configurable USB HID Mouse Interrupt Polling Interval
On Sun, Dec 19, 2004 at 01:52:06AM +, Mikkel Krautz wrote:
> On Sat, 18 Dec 2004 08:53:31 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Sat, Dec 18, 2004 at 05:39:25PM +, Mikkel Krautz wrote:
> > > On Fri, 17 Dec 2004 18:59:48 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > > > What about makeing it a module paramater then, that is exported to
> > > > sysfs? That makes it easier to adjust on the fly (before the mouse is
> > > > inserted), and doesn't require the kernel to be rebuilt.
> > >
> > > I really like the idea. I'm start to think that this is the ideal way to
> > > accomplish this.
> > >
> > > Here's a new patch. Let's hope it doesn't wrap!
> >
> > It was eaten :(
> >
> > > module_init(hid_init);
> > > module_exit(hid_exit);
> > > +module_param(hid_mouse_polling_interval, int, 644);
> >
> > 0644, or use the proper #defines instead.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Here's an updated version, with your and Marcel's suggestions:
Some more suggestions:
A MODULE_PARM_DESC() would be good, as well as a patch to
kernel-parameters.txt.
Also, it'd be better instead of changing the bInterval in the endpoint
descriptor to change the "interval" variable. This way one wouldn't need
to think about whether the device is Full-speed or High-speed when
setting the parameter. Also the endpoint descriptor should be considered
read only.
> Signed-off-by: Mikkel Krautz <[EMAIL PROTECTED]>
> ---
>
>
> hid-core.c |9 -
> 1 files changed, 8 insertions(+), 1 deletion(-)
>
>
> --- clean/drivers/usb/input/hid-core.c
> +++ dirty/drviers/usb/input/hid-core.c
> @@ -37,11 +37,12 @@
> * Version Information
> */
>
> -#define DRIVER_VERSION "v2.0"
> +#define DRIVER_VERSION "v2.01"
> #define DRIVER_AUTHOR "Andreas Gal, Vojtech Pavlik"
> #define DRIVER_DESC "USB HID core driver"
> #define DRIVER_LICENSE "GPL"
>
> +static unsigned int hid_mousepoll_interval;
> static char *hid_types[] = {"Device", "Pointer", "Mouse", "Device",
> "Joystick",
> "Gamepad", "Keyboard", "Keypad", "Multi-Axis
> Controller"};
>
> @@ -1663,6 +1664,11 @@
> if ((endpoint->bmAttributes & 3) != 3) /* Not an
> interrupt endpoint */
> continue;
>
> + /* Change the polling interval of mice. */
> + if (hid->collection->usage == HID_GD_MOUSE
> + && hid_mousepoll_interval > 0)
> + endpoint->bInterval = hid_mousepoll_interval;
> +
> /* handle potential highspeed HID correctly */
> interval = endpoint->bInterval;
> if (dev->speed == USB_SPEED_HIGH)
> @@ -1910,6 +1916,7 @@
>
> module_init(hid_init);
> module_exit(hid_exit);
> +module_param_named(mousepoll, hid_mousepoll_interval, uint, 0644);
>
> MODULE_AUTHOR(DRIVER_AUTHOR);
> MODULE_DESCRIPTION(DRIVER_DESC);
>
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 04/09] ide: convert REQ_DRIVE_TASK to REQ_DRIVE_TASKFILE
I forgot about this one...
> @@ -55,22 +55,19 @@
> #include
> #include
>
> -static void ide_fill_flush_cmd(ide_drive_t *drive, struct request *rq)
> +void ide_init_flush_task(ide_drive_t *drive, ide_task_t *args)
> {
> - char *buf = rq->cmd;
> -
> - /*
> -* reuse cdb space for ata command
> -*/
> - memset(buf, 0, sizeof(rq->cmd));
> -
> - rq->flags = REQ_DRIVE_TASK | REQ_STARTED;
> - rq->buffer = buf;
> - rq->buffer[0] = WIN_FLUSH_CACHE;
> + memset(args, 0, sizeof(*args));
>
> if (ide_id_has_flush_cache_ext(drive->id) &&
> (drive->capacity64 >= (1UL << 28)))
> - rq->buffer[0] = WIN_FLUSH_CACHE_EXT;
> + args->tfRegister[IDE_COMMAND_OFFSET] = WIN_FLUSH_CACHE_EXT;
> + else
> + args->tfRegister[IDE_COMMAND_OFFSET] = WIN_FLUSH_CACHE;
> +
> + args->command_type = IDE_DRIVE_TASK_NO_DATA;
> + args->data_phase = TASKFILE_NO_DATA;
> + args->handler = task_no_data_intr;
> }
Isn't EXPORT_SYMBOL_{GPL} needed for ide_init_flush_task()?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Logitech MX-Series "Cruise Control" buttons
I recently posted an update to http://bugme.osdl.org/show_bug.cgi?id=1786 that shows the bug escalating on newer hardware, such that there is no user-accessable workaround. It seem that where an MX-series mouse's cruise-control buttons are concerned, the mouse (by default) produces two events for each button press: The button itself, as well as a scroll event simulating a keyboard-style press-delay-repeat cycle on the scroll wheel axis/buttons. Utilities such as logitech_applet (unmaintained afaict) seem to be able to change some settings. For example, on my MX1000 mouse it's able to disable the cruise-control scroll button simulation, which would allow me to use the buttons as ordinary mouse buttons. What I'd love to do is to be able to disable the button's native function and use *only* the cruise-control function, as the mouse was intended. If such a hardware reconfiguration is not possible, perhaps it would be easier to leave the mouse in the default configuration, but filter one event or the other before it reaches userspace? Or is it more natural to filter out the mouse's scroll-simulation, and do a mapping & key-repeat simulation in userspace somewhere? Please CC me in replies. -- Jeremy Nickurak -= Email: [EMAIL PROTECTED] =- Remember, when you buy major label CD's, you're paying companies to sue families and independant music. Learn more now at downhillbattle.org. signature.asc Description: Digital signature
Re: 3TB disk hassles
On Sun, 6 Feb 2005, Neil Conway wrote: > Since writing the above, I've been searching for more info. I > downloaded four different versions of grub (GNU Grub Legacy, GNU Grub2, > gentoo and Fedora Core 3). NONE of these showed any evidence of GPT > support (I was in a hurry, so I searched for strings EFI, GUID, GPT, > TB). I'd use lilo in that case. AFAI understood it can start from any device provided the BIOS can access the boot files. (May require a 5MB /boot partition if the disk is larger than the BIOS can access) HTH > I fail to see how grub can work on a GPT boot device if it can't parse > the partition table. I conclude that I'm still missing something. > Perhaps a layer before grub is supposed to parse the GPT instead? If > so, isn't that getting us straight back to a GPT-aware BIOS? If grub parses the partition table, it will do that without any BIOS support (except maybe for reading the raw data). So even a GPT-aware BIOS should not change a thing. -- Funny quotes: 23. If at first you don't succeed, destroy all evidence that you tried. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 08/09] ide: map ide_cmd_ioctl() to ide_taskfile_ioctl()
I have not fully reviewed it yet but I've noticed two things...
> @@ -648,11 +648,11 @@ u8 eighty_ninty_three (ide_drive_t *driv
>
> EXPORT_SYMBOL(eighty_ninty_three);
>
> -int ide_ata66_check (ide_drive_t *drive, ide_task_t *args)
> +int ide_ata66_check(ide_drive_t *drive, task_ioreg_t *regs)
> {
> - if ((args->tfRegister[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
> - (args->tfRegister[IDE_SECTOR_OFFSET] > XFER_UDMA_2) &&
> - (args->tfRegister[IDE_FEATURE_OFFSET] == SETFEATURES_XFER)) {
> + if (regs[IDE_COMMAND_OFFSET] == WIN_SETFEATURES &&
> + regs[IDE_SECTOR_OFFSET] > XFER_UDMA_2 &&
> + regs[IDE_FEATURE_OFFSET] == SETFEATURES_XFER) {
> #ifndef CONFIG_IDEDMA_IVB
> if ((drive->id->hw_config & 0x6000) == 0) {
> #else /* !CONFIG_IDEDMA_IVB */
What is the rationale for this change?
ide_task_t is available in ide_cmd_ioctl().
> @@ -678,11 +678,11 @@ int ide_ata66_check (ide_drive_t *drive,
> * 1 : Safe to update drive->id DMA registers.
> * 0 : OOPs not allowed.
> */
> -int set_transfer (ide_drive_t *drive, ide_task_t *args)
> +int set_transfer(ide_drive_t *drive, task_ioreg_t *regs)
> {
> - if ((args->tfRegister[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
> - (args->tfRegister[IDE_SECTOR_OFFSET] >= XFER_SW_DMA_0) &&
> - (args->tfRegister[IDE_FEATURE_OFFSET] == SETFEATURES_XFER) &&
> + if (regs[IDE_COMMAND_OFFSET] == WIN_SETFEATURES &&
> + regs[IDE_SECTOR_OFFSET] >= XFER_SW_DMA_0 &&
> + regs[IDE_FEATURE_OFFSET] == SETFEATURES_XFER &&
> (drive->id->dma_ultra ||
> drive->id->dma_mword ||
> drive->id->dma_1word))
ditto
> + io_32bit = drive->io_32bit;
> + drive->io_32bit = 0;/* racy */
> + ret = ide_diag_taskfile(drive, , in_size, buf);
> + drive->io_32bit = io_32bit;
It wasn't racy before this patch. I know that it is like that
in ide_taskfile_ioctl() but it is not an excuse for propagating
the bug. It can be easily fixed if you use drive_cmd_intr()
instead of task_in_intr() as task->handler.
Thanks,
Bartlomiej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] fs/nfs/: make some code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 8 Jan 2005
fs/nfs/inode.c |8 +---
fs/nfs/mount_clnt.c |4 ++--
fs/nfs/nfs4proc.c |9 +
fs/nfs/nfsroot.c|4 ++--
fs/nfs/read.c |2 +-
fs/nfs/write.c | 29 +++--
include/linux/nfs_fs.h | 24
include/linux/nfs_xdr.h |2 --
8 files changed, 38 insertions(+), 44 deletions(-)
--- linux-2.6.10-mm2-full/include/linux/nfs_xdr.h.old 2005-01-08
16:36:56.0 +0100
+++ linux-2.6.10-mm2-full/include/linux/nfs_xdr.h 2005-01-08
16:37:13.0 +0100
@@ -731,7 +731,5 @@
extern struct rpc_version nfs_version2;
extern struct rpc_version nfs_version3;
extern struct rpc_version nfs_version4;
-extern struct rpc_program nfs_program;
-extern struct rpc_stat nfs_rpcstat;
#endif
--- linux-2.6.10-mm2-full/fs/nfs/inode.c.old2005-01-08 16:35:25.0
+0100
+++ linux-2.6.10-mm2-full/fs/nfs/inode.c2005-01-08 16:38:33.0
+0100
@@ -64,6 +64,8 @@
static int nfs_statfs(struct super_block *, struct kstatfs *);
static int nfs_show_options(struct seq_file *, struct vfsmount *);
+static struct rpc_program nfs_program;
+
static struct super_operations nfs_sops = {
.alloc_inode= nfs_alloc_inode,
.destroy_inode = nfs_destroy_inode,
@@ -78,7 +80,7 @@
/*
* RPC cruft for NFS
*/
-struct rpc_statnfs_rpcstat = {
+static struct rpc_stat nfs_rpcstat = {
.program= _program
};
static struct rpc_version *nfs_version[] = {
@@ -95,7 +97,7 @@
#endif
};
-struct rpc_program nfs_program = {
+static struct rpc_program nfs_program = {
.name = "nfs",
.number = NFS_PROGRAM,
.nrvers = sizeof(nfs_version) / sizeof(nfs_version[0]),
@@ -792,7 +794,7 @@
* Wait for the inode to get unlocked.
* (Used for NFS_INO_LOCKED and NFS_INO_REVALIDATING).
*/
-int
+static int
nfs_wait_on_inode(struct inode *inode, int flag)
{
struct rpc_clnt *clnt = NFS_CLIENT(inode);
--- linux-2.6.10-mm2-full/fs/nfs/mount_clnt.c.old 2005-01-08
16:38:47.0 +0100
+++ linux-2.6.10-mm2-full/fs/nfs/mount_clnt.c 2005-01-08 16:39:04.0
+0100
@@ -31,7 +31,7 @@
static struct rpc_clnt * mnt_create(char *, struct sockaddr_in *,
int, int);
-struct rpc_program mnt_program;
+static struct rpc_program mnt_program;
struct mnt_fhstatus {
unsigned intstatus;
@@ -174,7 +174,7 @@
static struct rpc_stat mnt_stats;
-struct rpc_program mnt_program = {
+static struct rpc_program mnt_program = {
.name = "mount",
.number = NFS_MNT_PROGRAM,
.nrvers = sizeof(mnt_version)/sizeof(mnt_version[0]),
--- linux-2.6.10-mm2-full/include/linux/nfs_fs.h.old2005-01-08
16:41:00.0 +0100
+++ linux-2.6.10-mm2-full/include/linux/nfs_fs.h2005-01-08
16:47:58.0 +0100
@@ -385,11 +385,8 @@
* return value!)
*/
extern int nfs_sync_inode(struct inode *, unsigned long, unsigned int, int);
-extern int nfs_flush_inode(struct inode *, unsigned long, unsigned int, int);
-extern int nfs_flush_list(struct list_head *, int, int);
#if defined(CONFIG_NFS_V3) || defined(CONFIG_NFS_V4)
extern int nfs_commit_inode(struct inode *, unsigned long, unsigned int, int);
-extern int nfs_commit_list(struct list_head *, int);
#else
static inline int
nfs_commit_inode(struct inode *inode, unsigned long idx_start, unsigned int
npages, int how)
@@ -430,7 +427,6 @@
* Allocate and free nfs_write_data structures
*/
extern mempool_t *nfs_wdata_mempool;
-extern mempool_t *nfs_commit_mempool;
static inline struct nfs_write_data *nfs_writedata_alloc(void)
{
@@ -447,23 +443,6 @@
mempool_free(p, nfs_wdata_mempool);
}
-extern void nfs_writedata_release(struct rpc_task *task);
-
-static inline struct nfs_write_data *nfs_commit_alloc(void)
-{
- struct nfs_write_data *p = mempool_alloc(nfs_commit_mempool, SLAB_NOFS);
- if (p) {
- memset(p, 0, sizeof(*p));
- INIT_LIST_HEAD(>pages);
- }
- return p;
-}
-
-static inline void nfs_commit_free(struct nfs_write_data *p)
-{
- mempool_free(p, nfs_commit_mempool);
-}
-
/* Hack for future NFS swap support */
#ifndef IS_SWAPFILE
# define IS_SWAPFILE(inode)(0)
@@ -475,7 +454,6 @@
extern int nfs_readpage(struct file *, struct page *);
extern int nfs_readpages(struct file *, struct address_space *,
struct list_head *, unsigned);
-extern int nfs_pagein_list(struct list_head *, int);
extern void nfs_readpage_result(struct rpc_task *);
/*
[2.6 patch] fs/nfsd/: possible cleanups
The patch below contains the following possible cleanups:
- make some needlessly global code static
- #if 0 the following EXPORT_SYMBOL'ed but unused function:
- nfs4acl.c: nfs4_acl_permission
- remove the following unused global function:
- nfs4state.c: set_no_grace
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent om:
- 8 Jan 2005
fs/nfsd/export.c | 22 +-
fs/nfsd/lockd.c|2
fs/nfsd/nfs4acl.c |9 ++--
fs/nfsd/nfs4callback.c |7 +--
fs/nfsd/nfs4idmap.c| 12 ++---
fs/nfsd/nfs4state.c| 75 -
fs/nfsd/nfs4xdr.c |4 -
fs/nfsd/nfsfh.c| 11 ++---
fs/nfsd/nfssvc.c |2
fs/nfsd/vfs.c |8 +--
include/linux/nfs4_acl.h |2
include/linux/nfsd/state.h |1
12 files changed, 75 insertions(+), 80 deletions(-)
--- linux-2.6.10-mm2-full/fs/nfsd/export.c.old 2005-01-08 16:50:29.0
+0100
+++ linux-2.6.10-mm2-full/fs/nfsd/export.c 2005-01-08 16:52:01.0
+0100
@@ -79,9 +79,9 @@
}
}
-void expkey_request(struct cache_detail *cd,
- struct cache_head *h,
- char **bpp, int *blen)
+static void expkey_request(struct cache_detail *cd,
+ struct cache_head *h,
+ char **bpp, int *blen)
{
/* client fsidtype \xfsid */
struct svc_expkey *ek = container_of(h, struct svc_expkey, h);
@@ -95,7 +95,7 @@
}
static struct svc_expkey *svc_expkey_lookup(struct svc_expkey *, int);
-int expkey_parse(struct cache_detail *cd, char *mesg, int mlen)
+static int expkey_parse(struct cache_detail *cd, char *mesg, int mlen)
{
/* client fsidtype fsid [path] */
char *buf;
@@ -284,9 +284,9 @@
}
}
-void svc_export_request(struct cache_detail *cd,
- struct cache_head *h,
- char **bpp, int *blen)
+static void svc_export_request(struct cache_detail *cd,
+ struct cache_head *h,
+ char **bpp, int *blen)
{
/* client path */
struct svc_export *exp = container_of(h, struct svc_export, h);
@@ -345,7 +345,7 @@
}
-int svc_export_parse(struct cache_detail *cd, char *mesg, int mlen)
+static int svc_export_parse(struct cache_detail *cd, char *mesg, int mlen)
{
/* client path expiry [flags anonuid anongid fsid] */
char *buf;
@@ -515,8 +515,8 @@
return ek;
}
-int exp_set_key(svc_client *clp, int fsid_type, u32 *fsidv,
- struct svc_export *exp)
+static int exp_set_key(svc_client *clp, int fsid_type, u32 *fsidv,
+ struct svc_export *exp)
{
struct svc_expkey key, *ek;
@@ -1004,7 +1004,7 @@
exp_readunlock();
}
-struct flags {
+static struct flags {
int flag;
char *name[2];
} expflags[] = {
--- linux-2.6.10-mm2-full/fs/nfsd/lockd.c.old 2005-01-08 16:52:18.0
+0100
+++ linux-2.6.10-mm2-full/fs/nfsd/lockd.c 2005-01-08 16:52:30.0
+0100
@@ -60,7 +60,7 @@
fput(filp);
}
-struct nlmsvc_binding nfsd_nlm_ops = {
+static struct nlmsvc_binding nfsd_nlm_ops = {
.fopen = nlm_fopen,/* open file for locking */
.fclose = nlm_fclose, /* close file */
};
--- linux-2.6.10-mm2-full/include/linux/nfs4_acl.h.old 2005-01-08
16:53:13.0 +0100
+++ linux-2.6.10-mm2-full/include/linux/nfs4_acl.h 2005-01-08
16:54:37.0 +0100
@@ -44,8 +44,10 @@
int nfs4_acl_add_ace(struct nfs4_acl *, u32, u32, u32, int, uid_t);
int nfs4_acl_get_whotype(char *, u32);
int nfs4_acl_write_who(int who, char *p);
+#if 0
int nfs4_acl_permission(struct nfs4_acl *acl, uid_t owner, gid_t group,
uid_t who, u32 mask);
+#endif
#define NFS4_ACL_TYPE_DEFAULT 0x01
#define NFS4_ACL_DIR 0x02
--- linux-2.6.10-mm2-full/fs/nfsd/nfs4acl.c.old 2005-01-08 16:53:33.0
+0100
+++ linux-2.6.10-mm2-full/fs/nfsd/nfs4acl.c 2005-01-08 16:54:32.0
+0100
@@ -117,8 +117,7 @@
static short ace2type(struct nfs4_ace *);
static int _posix_to_nfsv4_one(struct posix_acl *, struct nfs4_acl *, unsigned
int);
static struct posix_acl *_nfsv4_to_posix_one(struct nfs4_acl *, unsigned int);
-int nfs4_acl_add_ace(struct nfs4_acl *, u32, u32, u32, int, uid_t);
-int nfs4_acl_split(struct nfs4_acl *, struct nfs4_acl *);
+static int nfs4_acl_split(struct nfs4_acl *, struct nfs4_acl *);
struct nfs4_acl *
nfs4_acl_posix_to_nfsv4(struct posix_acl *pacl, struct posix_acl *dpacl,
@@ -768,7 +767,7 @@
return pacl;
}
-int
+static int
nfs4_acl_split(struct nfs4_acl *acl, struct nfs4_acl *dacl)
{
struct list_head *h, *n;
@@ -940,6 +939,7 @@
}
}
+#if 0
/* 0 = granted, -EACCES = denied; mask is an nfsv4 mask, not mode bits */
int
[2.6 patch] smp{,boot}.c cleanups
This patch contains the following cleanups on several architectures:
- make some needlessly global code static
- remove the following write-only (except for printk's) variables:
- cache_decay_ticks
- smp_threads_ready
- cacheflush_time
I've only tried the compilation on i386, but I hope all mistakes I made
are on unimportant architectures. ;-)
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
Except for a rediff in one place due to an unrelated context change,this
patch was already sent on:
- 16 Jan 2005
arch/alpha/kernel/smp.c | 11 ---
arch/i386/kernel/smpboot.c | 27 ++-
arch/i386/mach-voyager/voyager_smp.c | 12
arch/ia64/kernel/smpboot.c | 15 ---
arch/m32r/kernel/smpboot.c |5 -
arch/mips/kernel/smp.c | 20 +---
arch/parisc/kernel/smp.c |4
arch/ppc/kernel/smp.c|2 --
arch/ppc64/kernel/smp.c |2 --
arch/s390/kernel/smp.c |3 ---
arch/sh/kernel/smp.c |3 ---
arch/sparc/kernel/smp.c |3 ---
arch/sparc/kernel/sun4d_smp.c|1 -
arch/sparc/kernel/sun4m_smp.c|1 -
arch/sparc64/kernel/smp.c| 27 +++
arch/um/kernel/smp.c |6 --
arch/x86_64/kernel/smpboot.c | 25 ++---
include/asm-alpha/timex.h|1 -
include/asm-arm/timex.h |2 --
include/asm-arm26/timex.h|2 --
include/asm-i386/smp.h |3 ---
include/asm-i386/timex.h |2 --
include/asm-m32r/timex.h |2 --
include/asm-mips/timex.h |1 -
include/asm-parisc/timex.h |2 --
include/asm-ppc/timex.h |2 --
include/asm-s390/timex.h |2 --
include/asm-sh/timex.h |2 --
include/asm-sh64/timex.h |2 --
include/asm-sparc/timex.h|1 -
include/asm-um/timex.h |2 --
include/asm-x86_64/timex.h |2 --
include/linux/sched.h|1 -
include/linux/smp.h |6 --
init/main.c |1 -
35 files changed, 12 insertions(+), 191 deletions(-)
--- linux-2.6.11-rc1-mm1-full/include/linux/sched.h.old 2005-01-16
04:51:35.0 +0100
+++ linux-2.6.11-rc1-mm1-full/include/linux/sched.h 2005-01-16
04:51:41.0 +0100
@@ -174,7 +174,6 @@
extern void trap_init(void);
extern void update_process_times(int user);
extern void scheduler_tick(void);
-extern unsigned long cache_decay_ticks;
/* Attach to any functions which should be ignored in wchan output. */
#define __sched__attribute__((__section__(".sched.text")))
--- linux-2.6.11-rc1-mm1-full/arch/i386/kernel/smpboot.c.old2005-01-16
04:51:49.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/kernel/smpboot.c2005-01-16
05:12:49.0 +0100
@@ -80,9 +80,6 @@
{ [0 ... NR_CPUS-1] = 0xff };
EXPORT_SYMBOL(x86_cpu_to_apicid);
-/* Set when the idlers are all forked */
-int smp_threads_ready;
-
/*
* Trampoline 80x86 program as an array.
*/
@@ -95,6 +92,8 @@
/* State of each CPU. */
DEFINE_PER_CPU(int, cpu_state) = { 0 };
+static void map_cpu_to_logical_apicid(void);
+
/*
* Currently trivial. Write the real->protected mode
* bootstrap into the page concerned. The caller
@@ -325,7 +324,7 @@
static atomic_t init_deasserted;
-void __init smp_callin(void)
+static void __init smp_callin(void)
{
int cpuid, phys_id;
unsigned long timeout;
@@ -416,7 +415,7 @@
synchronize_tsc_ap();
}
-int cpucount;
+static int cpucount;
/*
* Activate a secondary processor.
@@ -510,7 +509,7 @@
u8 cpu_2_logical_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
-void map_cpu_to_logical_apicid(void)
+static void map_cpu_to_logical_apicid(void)
{
int cpu = smp_processor_id();
int apicid = logical_smp_processor_id();
@@ -519,7 +518,7 @@
map_cpu_to_node(cpu, apicid_to_node(apicid));
}
-void unmap_cpu_to_logical_apicid(int cpu)
+static void unmap_cpu_to_logical_apicid(int cpu)
{
cpu_2_logical_apicid[cpu] = BAD_APICID;
unmap_cpu_to_node(cpu);
@@ -851,9 +850,6 @@
return boot_error;
}
-cycles_t cacheflush_time;
-unsigned long cache_decay_ticks;
-
static void smp_tune_scheduling (void)
{
unsigned long cachesize; /* kB */
@@ -874,7 +870,6 @@
* this basically disables processor-affinity
* scheduling on SMP without a TSC.
*/
- cacheflush_time = 0;
return;
} else {
cachesize = boot_cpu_data.x86_cache_size;
@@ -882,17 +877,7 @@
cachesize = 16; /* Pentiums,
[2.6 patch] i386/x86_64: acpi/sleep.c: kill unused acpi_save_state_disk
acpi_save_state_disk does nothing and is completely unused.
This patch was already ACK'ed by Pavel Machek.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 16 Jan 2005
arch/i386/kernel/acpi/sleep.c |9 -
arch/x86_64/kernel/acpi/sleep.c |9 -
include/asm-i386/acpi.h |1 -
include/asm-i386/suspend.h |1 -
include/asm-x86_64/acpi.h |1 -
include/asm-x86_64/suspend.h|1 -
6 files changed, 22 deletions(-)
--- linux-2.6.11-rc1-mm1-full/include/asm-i386/acpi.h.old 2005-01-16
04:25:17.0 +0100
+++ linux-2.6.11-rc1-mm1-full/include/asm-i386/acpi.h 2005-01-16
04:25:23.0 +0100
@@ -174,7 +174,6 @@
/* routines for saving/restoring kernel state */
extern int acpi_save_state_mem(void);
-extern int acpi_save_state_disk(void);
extern void acpi_restore_state_mem(void);
extern unsigned long acpi_wakeup_address;
--- linux-2.6.11-rc1-mm1-full/include/asm-i386/suspend.h.old2005-01-16
04:25:31.0 +0100
+++ linux-2.6.11-rc1-mm1-full/include/asm-i386/suspend.h2005-01-16
04:25:35.0 +0100
@@ -61,5 +61,4 @@
/* routines for saving/restoring kernel state */
extern int acpi_save_state_mem(void);
-extern int acpi_save_state_disk(void);
#endif
--- linux-2.6.11-rc1-mm1-full/include/asm-x86_64/acpi.h.old 2005-01-16
04:25:44.0 +0100
+++ linux-2.6.11-rc1-mm1-full/include/asm-x86_64/acpi.h 2005-01-16
04:25:48.0 +0100
@@ -153,7 +153,6 @@
/* routines for saving/restoring kernel state */
extern int acpi_save_state_mem(void);
-extern int acpi_save_state_disk(void);
extern void acpi_restore_state_mem(void);
extern unsigned long acpi_wakeup_address;
--- linux-2.6.11-rc1-mm1-full/include/asm-x86_64/suspend.h.old 2005-01-16
04:25:56.0 +0100
+++ linux-2.6.11-rc1-mm1-full/include/asm-x86_64/suspend.h 2005-01-16
04:26:00.0 +0100
@@ -55,5 +55,4 @@
/* routines for saving/restoring kernel state */
extern int acpi_save_state_mem(void);
-extern int acpi_save_state_disk(void);
#endif
--- linux-2.6.11-rc1-mm1-full/arch/i386/kernel/acpi/sleep.c.old 2005-01-16
04:26:23.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/kernel/acpi/sleep.c 2005-01-16
04:26:30.0 +0100
@@ -47,15 +47,6 @@
return 0;
}
-/**
- * acpi_save_state_disk - save kernel state to disk
- *
- */
-int acpi_save_state_disk (void)
-{
- return 1;
-}
-
/*
* acpi_restore_state - undo effects of acpi_save_state_mem
*/
--- linux-2.6.11-rc1-mm1-full/arch/x86_64/kernel/acpi/sleep.c.old
2005-01-16 04:26:43.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/x86_64/kernel/acpi/sleep.c 2005-01-16
04:26:50.0 +0100
@@ -87,15 +87,6 @@
return 0;
}
-/**
- * acpi_save_state_disk - save kernel state to disk
- *
- */
-int acpi_save_state_disk (void)
-{
- return 1;
-}
-
/*
* acpi_restore_state
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] i386/crypto/aes.c: make some code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 16 Jan 2005
--- linux-2.6.11-rc1-mm1-full/arch/i386/crypto/aes.c.old2005-01-16
04:21:08.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/crypto/aes.c2005-01-16
04:22:06.0 +0100
@@ -93,12 +93,12 @@
u32 ft_tab[4][256];
u32 fl_tab[4][256];
-u32 ls_tab[4][256];
-u32 im_tab[4][256];
+static u32 ls_tab[4][256];
+static u32 im_tab[4][256];
u32 il_tab[4][256];
u32 it_tab[4][256];
-void gen_tabs(void)
+static void gen_tabs(void)
{
u32 i, w;
u8 pow[512], log[256];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] i386/kernel/i387.c: misc cleanups
This patch contains the following cleanups:
- make a needlessly global variable static
- #if 0 four unused global functions
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 16 Jan 2005
arch/i386/kernel/i387.c |8 +++-
include/asm-i386/i387.h |6 --
2 files changed, 7 insertions(+), 7 deletions(-)
--- linux-2.6.11-rc1-mm1-full/include/asm-i386/i387.h.old 2005-01-16
04:32:43.0 +0100
+++ linux-2.6.11-rc1-mm1-full/include/asm-i386/i387.h 2005-01-16
04:34:41.0 +0100
@@ -17,7 +17,6 @@
#include
#include
-extern unsigned long mxcsr_feature_mask;
extern void mxcsr_feature_mask_init(void);
extern void init_fpu(struct task_struct *);
/*
@@ -86,13 +85,8 @@
*/
extern unsigned short get_fpu_cwd( struct task_struct *tsk );
extern unsigned short get_fpu_swd( struct task_struct *tsk );
-extern unsigned short get_fpu_twd( struct task_struct *tsk );
extern unsigned short get_fpu_mxcsr( struct task_struct *tsk );
-extern void set_fpu_cwd( struct task_struct *tsk, unsigned short cwd );
-extern void set_fpu_swd( struct task_struct *tsk, unsigned short swd );
-extern void set_fpu_twd( struct task_struct *tsk, unsigned short twd );
-
/*
* Signal frame handlers...
*/
--- linux-2.6.11-rc1-mm1-full/arch/i386/kernel/i387.c.old 2005-01-16
04:33:07.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/kernel/i387.c 2005-01-16
04:35:11.0 +0100
@@ -24,7 +24,7 @@
#define HAVE_HWFP 1
#endif
-unsigned long mxcsr_feature_mask = 0x;
+static unsigned long mxcsr_feature_mask = 0x;
void mxcsr_feature_mask_init(void)
{
@@ -175,6 +175,7 @@
}
}
+#if 0
unsigned short get_fpu_twd( struct task_struct *tsk )
{
if ( cpu_has_fxsr ) {
@@ -183,6 +184,7 @@
return (unsigned short)tsk->thread.i387.fsave.twd;
}
}
+#endif /* 0 */
unsigned short get_fpu_mxcsr( struct task_struct *tsk )
{
@@ -193,6 +195,8 @@
}
}
+#if 0
+
void set_fpu_cwd( struct task_struct *tsk, unsigned short cwd )
{
if ( cpu_has_fxsr ) {
@@ -220,6 +224,8 @@
}
}
+#endif /* 0 */
+
/*
* FXSR floating point environment conversions.
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] i386/x86_64 i8259.c: make mask_and_ack_8259A static
The patch below makes a needlessly global function static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 16 Jan 2005
arch/i386/kernel/i8259.c |4 ++--
arch/x86_64/kernel/i8259.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--- linux-2.6.11-rc1-mm1-full/arch/i386/kernel/i8259.c.old 2005-01-16
04:36:28.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/kernel/i8259.c 2005-01-16
04:36:48.0 +0100
@@ -50,7 +50,7 @@
#define shutdown_8259A_irq disable_8259A_irq
-void mask_and_ack_8259A(unsigned int);
+static void mask_and_ack_8259A(unsigned int);
unsigned int startup_8259A_irq(unsigned int irq)
{
@@ -170,7 +170,7 @@
* first, _then_ send the EOI, and the order of EOI
* to the two 8259s is important!
*/
-void mask_and_ack_8259A(unsigned int irq)
+static void mask_and_ack_8259A(unsigned int irq)
{
unsigned int irqmask = 1 << irq;
unsigned long flags;
--- linux-2.6.11-rc1-mm1-full/arch/x86_64/kernel/i8259.c.old2005-01-16
04:38:11.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/x86_64/kernel/i8259.c2005-01-16
04:37:07.0 +0100
@@ -149,7 +149,7 @@
#define shutdown_8259A_irq disable_8259A_irq
-void mask_and_ack_8259A(unsigned int);
+static void mask_and_ack_8259A(unsigned int);
static unsigned int startup_8259A_irq(unsigned int irq)
{
@@ -273,7 +273,7 @@
* first, _then_ send the EOI, and the order of EOI
* to the two 8259s is important!
*/
-void mask_and_ack_8259A(unsigned int irq)
+static void mask_and_ack_8259A(unsigned int irq)
{
unsigned int irqmask = 1 << irq;
unsigned long flags;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fs/ncpfs/ncplib_kernel.c: make a function static
This patch makes a needlessly global function static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 8 Jan 2005 --- linux-2.6.10-mm2-full/fs/ncpfs/ncplib_kernel.c.old 2005-01-08 04:31:10.0 +0100 +++ linux-2.6.10-mm2-full/fs/ncpfs/ncplib_kernel.c 2005-01-08 04:31:19.0 +0100 @@ -933,7 +933,7 @@ return 0; } -int +static int ncp_RenameNSEntry(struct ncp_server *server, struct inode *old_dir, char *old_name, __le16 old_type, struct inode *new_dir, char *new_name) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] fix sound/isa/gus/interwave.c compile with PNP=n
Emmanuel Colbus sent this patch one month ago with the following description: There is a trivial bug in the file sound/isa/gus/interwave.c . The variable isapnp is defined only if CONFIG_PNP is enabled, but it is always used few lines after. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- a/sound/isa/gus/interwave.c Fri Dec 24 22:34:58 2004 +++ b/sound/isa/gus/interwave.c Wed Jan 5 14:06:53 2005 @@ -79,8 +79,10 @@ MODULE_PARM_DESC(id, "ID string for InterWave soundcard."); module_param_array(enable, bool, NULL, 0444); MODULE_PARM_DESC(enable, "Enable InterWave soundcard."); +#ifdef CONFIG_PNP module_param_array(isapnp, bool, NULL, 0444); MODULE_PARM_DESC(isapnp, "ISA PnP detection for specified soundcard."); +#endif module_param_array(port, long, NULL, 0444); MODULE_PARM_DESC(port, "Port # for InterWave driver."); #ifdef SNDRV_STB - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 input event extending tool exist?
On Wed, Dec 15, 2004 at 11:41:38PM -0500, Eric Lammerts wrote: > Vojtech Pavlik wrote: > >You can use evtest (attached). It's often found in the joystick RPMs. > >It's also in the linuxconsole.sf.net CVS repository. On recent kernels > >it'll show the scancodes as well as the generated keycodes. > > Vojtech, are you aware that this doesn't work well with 32-bit apps on > x86-64 kernels? The ioctls don't work (no compat definitions), and > struct input_event is 24 bytes instead of 16. Yes, I do. It's a bug, and will be a hard one to solve. The ioclt()s are easy, but the event size difference is pretty nasty. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 05/09] ide: map ide_task_ioctl() to ide_taskfile_ioctl()
On Sat, 5 Feb 2005 11:15:56 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote: > - int err = 0; > - u8 args[7], *argbuf = args; > - int argsize = 7; > + u8 args[7]; > + ide_task_t task; > + task_ioreg_t *regs = task.tfRegister; u8 *regs please > + int ret; What is the reason for changing the name of variable (other than making the patch bigger ;) ? Please also read comments to patch #4. Thanks, Bartlomiej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROPOSAL/PATCH] Remove PT_GNU_STACK support before 2.6.11
> [1] glibc-2.3.4 kill buggy bins at the load time. > (please look into: elf/dl-load.c, elf/dl-support.c, elf/rtld.c) I don't see how that can work for arbitary code executed in some arbitary mmap. Please explain. > This works on i386/PaX systems too (hardware NX isn't required). But it's for the 99.9% of other users who don't use such weird third party patches. > The execstack req. disappeard (~99% of broken sources). My problem is basically that the effort of fixing these sources seems to be shifted to x86-64 now in mainstream linux. And I don't like that. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 04/09] ide: convert REQ_DRIVE_TASK to REQ_DRIVE_TASKFILE
I put some more thought into this change... details below...
On Sat, 5 Feb 2005 11:15:56 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote:
> @@ -705,24 +705,17 @@ static int idedisk_issue_flush(request_q
> {
> ide_drive_t *drive = q->queuedata;
> struct request *rq;
> + ide_task_t args;
> int ret;
ide_task_t task please
> @@ -730,8 +723,9 @@ static int idedisk_issue_flush(request_q
> * if we failed and caller wants error offset, get it
> */
> if (ret && error_sector)
> - *error_sector = ide_get_error_location(drive, rq->cmd);
> + *error_sector = ide_get_error_location(drive, );
>
> + rq->special = NULL; /* just in case */
In what case?
> @@ -55,22 +55,19 @@
> #include
> #include
>
> -static void ide_fill_flush_cmd(ide_drive_t *drive, struct request *rq)
> +void ide_init_flush_task(ide_drive_t *drive, ide_task_t *args)
ide_task_t *task
> @@ -80,7 +77,9 @@ static void ide_fill_flush_cmd(ide_drive
> static struct request *ide_queue_flush_cmd(ide_drive_t *drive,
>struct request *rq, int post)
> {
> - struct request *flush_rq = (drive)->wrq;
> + ide_hwgroup_t *hwgroup = drive->hwif->hwgroup;
> + struct request *flush_rq = >flush_rq;
> + ide_task_t *args = >flush_args;
ide_task_t *task
> @@ -221,41 +223,37 @@ static void ide_complete_pm_request (ide
> /*
> * FIXME: probably move this somewhere else, name is bad too :)
> */
> -u64 ide_get_error_location(ide_drive_t *drive, char *args)
> +u64 ide_get_error_location(ide_drive_t *drive, ide_task_t *args)
ide_task_t *task
> {
> u32 high, low;
> u8 hcyl, lcyl, sect;
> - u64 sector;
>
> - high = 0;
> - hcyl = args[5];
> - lcyl = args[4];
> - sect = args[3];
> -
> - if (ide_id_has_flush_cache_ext(drive->id)) {
> - low = (hcyl << 16) | (lcyl << 8) | sect;
> - HWIF(drive)->OUTB(drive->ctl|0x80, IDE_CONTROL_REG);
> - high = ide_read_24(drive);
> - } else {
> - u8 cur = HWIF(drive)->INB(IDE_SELECT_REG);
> - if (cur & 0x40)
> - low = (hcyl << 16) | (lcyl << 8) | sect;
> - else {
> - low = hcyl * drive->head * drive->sect;
> - low += lcyl * drive->sect;
> - low += sect - 1;
> - }
> - }
> + if (ide_id_has_flush_cache_ext(drive->id) &&
> + (drive->capacity64 >= (1UL << 28)))
Please just use if (drive->addressing), it is simpler and still correct.
Since we are now using ide_task_t 'high' will be 0 when
ide_id_has_flush_cache() == 0 and drive->addressing == 1
(such combination is unlikely but...). Also thanks to this change
ide_get_error_location() becomes a really *generic* helper and
can be later used by other code.
> @@ -1201,9 +1224,14 @@ extern ide_startstop_t ide_do_reset (ide
> extern void ide_init_drive_cmd (struct request *rq);
>
> /*
> + * This function initializes @task to WIN_FLUSH_CACHE[_EXT] command.
> + */
> +void ide_init_flush_task(ide_drive_t *drive, ide_task_t *args);
comment is wrong and not needed,
void ide_init_flush_task(ide_drive_t *, ide_task_t *);
should be enough
There is one problem left with this change - FLUSH_CACHE_{EXT}
command handling becomes slower for drive's supporting LBA48
(also next patches make ide_{task,cmd}_ioctl() slower). Why is so?
See do_rw_taskfile(), HOB registers are written/read unconditionally
if (drive->addressing == 1). This can be fixed by i.e. adding
'unsigned long flags' to ide_task_t and IDE_TASK_LBA48 flag.
BTW this fix is needed also to implement LBA48 optimization for
read/write requests (not writing HOB registers when not needed).
IMHO there are some things worth mentioning in the patch description,
do_rw_taskfile() vs execute_drive_cmd()+ide_cmd() details:
some registers are written now in different order and timeout is bumped
(these changes shouldn't make any harm but I'm paranoid :).
Thanks,
Bartlomiej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Dynamic tick, version 050127-1
Hi!
> > > > Ok, works slightly better: time no longer runs 2x too fast. When TSC
> > > > is used, I get same behaviour as before ("sleepy machine"). With
> > > > "notsc", machine seems to work okay, but I still get 1000 timer
> > > > interrupts a second.
> > >
> > > Sounds like dyn-tick did not get enabled then, maybe you don't have
> > > CONFIG_X86_PM_TIMER, or don't have ACPI PM timer on your board?
> >
> > I do have CONFIG_X86_PM_TIMER enabled, but it seems by board does not
> > have such piece of hardware:
> >
> > [EMAIL PROTECTED]:/usr/src/linux-mm$ dmesg | grep -i "time\|tick\|apic"
> > PCI: Setting latency timer of device :00:11.5 to 64
> > [EMAIL PROTECTED]:/usr/src/linux-mm$
> >
> > [Strange, I should see some messages about apic, no?]
>
> Yeah, looks like you don't have a local APIC then? Let me test the
> patch here with just PIT timer only.
>
> It also looks like you don't have TSC either? Or do you still have
> notsc cmdline option?
It definitely does have TSC, it is athlon64. It was probably disabled
in this particular run.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bug in tty_io.c after changes between 2.6.9-rc1-bk1 and 2.6.9-rc1-bk2
On Thu, Feb 03, Linux Kernel Mailing List wrote: > ChangeSet 1.1992.2.73, 2005/02/02 08:48:23-08:00, [EMAIL PROTECTED] > > [PATCH] Bug in tty_io.c after changes between 2.6.9-rc1-bk1 and > 2.6.9-rc1-bk2 > > Fix http://bugzilla.kernel.org/show_bug.cgi?id=3736 > > Finally located that a problem seems to be a simple typo. > > Acked-by: Al Viro <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > tty_io.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > > diff -Nru a/drivers/char/tty_io.c b/drivers/char/tty_io.c > --- a/drivers/char/tty_io.c 2005-02-02 10:45:08 -08:00 > +++ b/drivers/char/tty_io.c 2005-02-02 10:45:08 -08:00 > @@ -1156,8 +1156,8 @@ > int i = index + driver->name_base; > /* ->name is initialized to "ttyp", but "tty" is expected */ > sprintf(p, "%s%c%x", > - driver->subtype == PTY_TYPE_SLAVE ? "tty" : > driver->name, > - ptychar[i >> 4 & 0xf], i & 0xf); > + driver->subtype == PTY_TYPE_SLAVE ? "pty" : driver->name, > + ptychar[i >> 4 & 0xf], i & 0xf); > } This change looks very bogus, what are you trying to fix here? if pty_driver->subtype == PTY_TYPE_MASTER, a node ptyXY has to be created. if pty_driver->subtype == PTY_TYPE_SLAVE, a node ttyXY has to be created. See Documentation/devices.txt, line 108ff and 183ff With your change, the ttyXY becomes ptyXY? Why does that fix anything? Do you have an outdated udev package with bogus udev.rules? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dev documentation?
On Sun, Feb 06, 2005 at 12:35:32AM -0800, Garrett Cooper wrote: > Hello, > I was wondering where I might find some good dev > documentation (if possible free since I am on a tight > budget currently), because I wish to port a 2.4 kernel > modem driver to 2.6 so I can use the driver properly. http://lwn.net/Articles/driver-porting/ -- Tomasz Torcz "Never underestimate the bandwidth of a station [EMAIL PROTECTED]wagon filled with backup tapes." -- Jim Gray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROPOSAL/PATCH] Remove PT_GNU_STACK support before 2.6.11
On Sun, 2005-02-06 at 10:04 -0800, Linus Torvalds wrote: > > Ok so what to do for 2.6.11... the setarch workaround is there; that > > works. My patch patches the worst issues and is quite minimal. What you > > propose will be more invasive and more suitable for 2.6.11-bk1... > > I can do such a patch no problem (although the next two days I won't > > have time). > > Hmm.. I can take your initial patch now. Can somebody explain why this > hassn't come up before, though? somehow things got "cleaned up" around 2.6.10-ish to change the default... it's quite rare so few people noticed. It seems Andi got a few reports in the last week or so and started investigating. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROPOSAL/PATCH] Remove PT_GNU_STACK support before 2.6.11
On Sunday 06 of February 2005 13:47, you wrote:
> On Sun, Feb 06, 2005 at 01:03:11PM +0100, Pawel Sikora wrote:
> > On Sunday 06 of February 2005 12:36, you wrote:
> > > Worse is that even when the program has trampolines and has
> > > PT_GNU_STACK header with an E bit on the stack it still won't get an
> > > executable heap by default (this is what broke grub)
> > > (...)
> > > My proposal is to turn this all off at least for 2.6.11.
> >
> > My proposal is to recompile broken software with cflags +=
> > -Wa,--noexecstack
>
> By how do you detect broken software? There doesn't seem to be any
> fool proof way other than a extensive test on a NX capable system
> with correct kernel.
[1] glibc-2.3.4 kill buggy bins at the load time.
(please look into: elf/dl-load.c, elf/dl-support.c, elf/rtld.c)
This works on i386/PaX systems too (hardware NX isn't required).
[2] `readelf -Wl |grep GNU_STACK` shows RWE ;-)
Please look at this quick example.
# gcc tmp1.c tmp2-invalid.S -o tmp -s
# readelf -Wl tmp
(...)
GNU_STACK 0x00 0x 0x 0x0 0x0 RWE 0x4
^ execstack?
PAX_FLAGS 0x00 0x 0x 0x0 0x0 0x4
(...)
Now, let's add section note to the asm. file and rebuild.
# gcc tmp1.c tmp2-valid.S -o tmp -s
# readelf -Wl tmp
(...)
GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0x4
PAX_FLAGS 0x00 0x 0x 0x0 0x0 0x4
(...)
The execstack req. disappeard (~99% of broken sources).
I get the same effect with fixed cflags and invalid source.
# gcc tmp1.c tmp2-invalid.S -o tmp -s -Wa,--noexecstack
# readelf -Wl tmp
(...)
GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0x4
PAX_FLAGS 0x00 0x 0x 0x0 0x0 0x4
(...)
I known several apps that really need executable data/stack (eg. jvm, xorg).
The rest of RWE-marked binaries have IMHO buggy sources.
> It would be fine if there was a compile time error or something,
> but there isn't.
IMHO the `as` should warn about missed (.note.GNU-stack) section.
Regards,
PaweÅ.
--
/* Copyright (C) 2003, SCO, Inc. This is valuable Intellectual Property. */
#define say(x) lie(x)
extern void test();
int main(int argc, char** argv)
{
test();
return 0;
}
.text
.global test
test:
ret
.end
.section .note.GNU-stack,"",@progbits; .previous
.text
.global test
test:
ret
.end
Re: [PATCH] Add as-option to top-level Makefile
On Sun, Feb 06, 2005 at 07:03:47PM +0200, Paul Mundt wrote: > cc-option can presently not be used for checking as flags. It seems like > MIPS ran into this already and added their own as-option (which at this > point seems to be completely unused on MIPS, so perhaps it's worth > removing entirely from there). > > This patch moves the definition to the top-level Makefile so that others > can make use of it (sh wants this with newer binutils that allow for ISA > tuning, for instance). > > Additionally, it may make more sense to move the -Wa$(comma) stuff into > as-option directly so it doesn't get repeated all over the place (though > it seems unlikely that there will be enough users that actually care > about this). For MIPS as-option became unused when old binutils versions finally had to be retired. Patch looks good to me but since it's sort of a no-op patch I won't merge it into linux-mips.org but if accepted rather wait until it comes to me vi Linus's patches, as usual. Thanks, Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROPOSAL/PATCH] Remove PT_GNU_STACK support before 2.6.11
On Sun, 6 Feb 2005, Arjan van de Ven wrote: > > > > And if you want to split things up, there's at least three flags there: > > "stack" vs "file mapping" vs "anonymous mapping". For example, it might > > lets add "brk" as 4th I guess. I thought about that, but no normal user program uses brk() natively. They all just use "malloc()" and friends, and pretty much every implementation of those in turn just mixes brk/anon-mmap freely. > Ok so what to do for 2.6.11... the setarch workaround is there; that > works. My patch patches the worst issues and is quite minimal. What you > propose will be more invasive and more suitable for 2.6.11-bk1... > I can do such a patch no problem (although the next two days I won't > have time). Hmm.. I can take your initial patch now. Can somebody explain why this hassn't come up before, though? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [patch] Make User Mode Linux compile in 2.6.11-rc3
On Saturday 05 February 2005 01:00 pm, Frank Sorenson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Rob Landley wrote: > | As of yesterday afternoon, the UML build still breaks in > | sys_call_table.c, ... > This patch for sys_call_table.c was merged into the main tree in this > changeset: > http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]|ChangeSet >@-2d > > The patch fixes both the sys_call_table and the pud_alloc breakage, and > as of 2.6.11-rc3-bk2, the main tree compiles again for UML. Verified. 2.6.11-rc3-bk2 does indeed build, and the result is chugging through my big compile script. It seems to be working fine, although ye olde display glitch is still there: binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.rd binutils-2.14/ld/testsuite/lde/ld-/ld-sld-spd-spa-sparsparcparc/arc/trc/tlc/tls/tlsstlssulssunssunbsunbiunbinnbin6bin64in64.n64.s64.s4.s.ss binubinutinutinutilutilstils-ils-2ls-2.s-2.1-2.142.14/.14/l14/ld4/ld//ld/tld/ted/tes/testtestsestsustsuitsuitsuiteuite/ite/lte/lde/ld-/ld-sld-spd-spa-sparsparcparc/tlssunbin64.sd binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.td But that's a purely cosmetic bug. Thanks, Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROPOSAL/PATCH] Remove PT_GNU_STACK support before 2.6.11
On Sun, Feb 06, 2005 at 09:05:05AM -0800, Linus Torvalds wrote: > > > On Sun, 6 Feb 2005, Andi Kleen wrote: > > > > There are probably more. > > So? Do you expect to never fix them, or what? Someone will fix them, but it's not the job of the 32bit emulation of x86-64 to break compatibility. It's whole point is to be compatible, not expose bugs. If someone else wants to break existing programs they can do that if they think they have the capability to deal with (rightfully) annoyed user space people. But not with x86-64 compat mode leading the front here. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROPOSAL/PATCH] Remove PT_GNU_STACK support before 2.6.11
On Sun, Feb 06, 2005 at 09:08:47AM -0800, Linus Torvalds wrote: > > > On Sun, 6 Feb 2005, Andi Kleen wrote: > > > > Force READ_IMPLIES_EXEC for all 32bit processes to fix > > the 32bit source compatibility. > > Andi, stop this. We're _not_ going to say "32-bit executables don't need > PROT_EXEC. The executables would need to be marked broken per-executable, > not some kind of "we don't do this globally" setting. The thing I'm annoyed about is that all the testing for this change seems to go towards the x86-64 32bit emulation (because effectively near nobody uses 32bit PAE+NX right now) And the main job of the 32bit emulation is not to prove as a testing ground for experimental stuff, but to be compatible. And changes like this break it and cause me a lot of additional work. Here's a slightly different patch to only turn it off for 32bit x86-64. If the 32bit experimental security people can get their stuff tested properly and 32bit NX CPUs are actually used widely and all the third party sources fixed I can probably follow in a few months. But I really don't have the capacity to track third party software fixes for stuff that really has nothing to do with compatible 32bit emulation. Please consider applying this patch. It only touches x86-64. Thanks: -Andi Always enable PROT_READ implies PROT_EXEC for 32bit programs running on x86-64. This reverts behaviour back to what 2.6.9 did. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> diff -u linux-2.6.11rc3/arch/x86_64/kernel/process.c-o linux-2.6.11rc3/arch/x86_64/kernel/process.c --- linux-2.6.11rc3/arch/x86_64/kernel/process.c-o 2005-02-04 09:12:52.0 +0100 +++ linux-2.6.11rc3/arch/x86_64/kernel/process.c2005-02-06 15:26:45.0 +0100 @@ -577,6 +577,11 @@ /* Make sure to be in 64bit mode */ clear_thread_flag(TIF_IA32); + + /* Clear in case it was set from a 32bit parent. + Bug: this overwrites the user choice. Would need + a second bit too. */ + current->personality &= ~READ_IMPLIES_EXEC; } asmlinkage long sys_fork(struct pt_regs *regs) diff -u linux-2.6.11rc3/arch/x86_64/ia32/ia32_binfmt.c-o linux-2.6.11rc3/arch/x86_64/ia32/ia32_binfmt.c --- linux-2.6.11rc3/arch/x86_64/ia32/ia32_binfmt.c-o2005-02-04 09:12:52.0 +0100 +++ linux-2.6.11rc3/arch/x86_64/ia32/ia32_binfmt.c 2005-02-06 15:23:33.0 +0100 @@ -262,6 +262,7 @@ set_thread_flag(TIF_ABI_PENDING); \ else\ clear_thread_flag(TIF_ABI_PENDING); \ + current->personality |= READ_IMPLIES_EXEC; \ } while (0) /* Override some function names */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
