[PATCH 2/2] efi: Export efi_query_variable_store() for efivars.ko
Fixes build with CONFIG_EFI_VARS=m which was broken after the commit "x86, efivars: firmware bug workarounds should be in platform code". Signed-off-by: Sergey Vlasov --- arch/x86/platform/efi/efi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 4959e3f..4f364c7 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -1144,3 +1144,4 @@ efi_status_t efi_query_variable_store(u32 attributes, unsigned long size) return EFI_SUCCESS; } +EXPORT_SYMBOL_GPL(efi_query_variable_store); -- 1.8.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] x86/Kconfig: Make EFI select UCS2_STRING
The commit "efi: Distinguish between "remaining space" and actually used space" added usage of ucs2_*() functions to arch/x86/platform/efi/efi.c, but the only thing which selected UCS2_STRING was EFI_VARS, which is technically optional and can be built as a module. Signed-off-by: Sergey Vlasov --- arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index a4f24f5..01af853 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1549,6 +1549,7 @@ config X86_SMAP config EFI bool "EFI runtime service support" depends on ACPI + select UCS2_STRING ---help--- This enables the kernel to use EFI runtime services that are available (such as the EFI variable services). -- 1.8.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] x86/Kconfig: Make EFI select UCS2_STRING
The commit efi: Distinguish between remaining space and actually used space added usage of ucs2_*() functions to arch/x86/platform/efi/efi.c, but the only thing which selected UCS2_STRING was EFI_VARS, which is technically optional and can be built as a module. Signed-off-by: Sergey Vlasov v...@altlinux.ru --- arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index a4f24f5..01af853 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1549,6 +1549,7 @@ config X86_SMAP config EFI bool EFI runtime service support depends on ACPI + select UCS2_STRING ---help--- This enables the kernel to use EFI runtime services that are available (such as the EFI variable services). -- 1.8.1.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] efi: Export efi_query_variable_store() for efivars.ko
Fixes build with CONFIG_EFI_VARS=m which was broken after the commit x86, efivars: firmware bug workarounds should be in platform code. Signed-off-by: Sergey Vlasov v...@altlinux.ru --- arch/x86/platform/efi/efi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 4959e3f..4f364c7 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -1144,3 +1144,4 @@ efi_status_t efi_query_variable_store(u32 attributes, unsigned long size) return EFI_SUCCESS; } +EXPORT_SYMBOL_GPL(efi_query_variable_store); -- 1.8.1.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tulip Ethernet driver messes up USB keyboard
On Fri, Sep 14, 2012 at 12:49:45PM +0300, Marti Raudsepp wrote:
> After installing an old 100Mbit PCI Ethernet card to my machine, it has
> complained a few times about spurious interrupts ("nobody cared") at a
> random time of the day. After the oops is reported, my USB keyboard (HP
> smart card keyboard) stops working properly -- it has lots of delay, it
> misses some keystrokes and also causes "stuck keys". Strangely enough my USB
> mouse continues to work without problems. Apparently the USB controller and
> the Ethernet card share an interrupt line. Un-/replugging the keyboard does
> not help.
>
> So far I have simply rebooted to fix the issue. I haven't been able to
> reproduce this on will despite my best attempts.
>
> The Ethernet card is driven by the tulip driver and is listed as "ADMtek
> NC100 Network Everywhere Fast Ethernet 10/100 (rev 11)" in lspci. My
> motherboard uses the Intel H77 chipset (ASRock H77 Pro4/MVP)
This board uses the ASMedia ASM1083 PCIe-to-PCI bridge (or maybe ASM1085 -
hard to see from photos available on the net, and the PCI IDs for these
chips are the same), which is known to have problems with interrupt
handling:
https://lkml.org/lkml/2012/1/30/216
I experience the same problem with ASUS P8P67 LE (except in my case the
interrupt is not shared with anything, and the network card does not stop
working completely, just gives horrible performance with > 100ms pings).
Some people use "noirqdebug irqpoll" as a workaround:
http://lkml.indiana.edu/hypermail/linux/kernel/1204.1/03451.html
But this workaround basically turns off the protection against stuck
interrupts in the kernel, so the system could potentially be busy handling
a stuck interrupt forever.
You can also try to move the PCI card to another slot, so that it would
use another interrupt, which might be not shared with USB or another
important device.
signature.asc
Description: Digital signature
Re: tulip Ethernet driver messes up USB keyboard
On Fri, Sep 14, 2012 at 12:49:45PM +0300, Marti Raudsepp wrote: After installing an old 100Mbit PCI Ethernet card to my machine, it has complained a few times about spurious interrupts (nobody cared) at a random time of the day. After the oops is reported, my USB keyboard (HP smart card keyboard) stops working properly -- it has lots of delay, it misses some keystrokes and also causes stuck keys. Strangely enough my USB mouse continues to work without problems. Apparently the USB controller and the Ethernet card share an interrupt line. Un-/replugging the keyboard does not help. So far I have simply rebooted to fix the issue. I haven't been able to reproduce this on will despite my best attempts. The Ethernet card is driven by the tulip driver and is listed as ADMtek NC100 Network Everywhere Fast Ethernet 10/100 (rev 11) in lspci. My motherboard uses the Intel H77 chipset (ASRock H77 Pro4/MVP) This board uses the ASMedia ASM1083 PCIe-to-PCI bridge (or maybe ASM1085 - hard to see from photos available on the net, and the PCI IDs for these chips are the same), which is known to have problems with interrupt handling: https://lkml.org/lkml/2012/1/30/216 I experience the same problem with ASUS P8P67 LE (except in my case the interrupt is not shared with anything, and the network card does not stop working completely, just gives horrible performance with 100ms pings). Some people use noirqdebug irqpoll as a workaround: http://lkml.indiana.edu/hypermail/linux/kernel/1204.1/03451.html But this workaround basically turns off the protection against stuck interrupts in the kernel, so the system could potentially be busy handling a stuck interrupt forever. You can also try to move the PCI card to another slot, so that it would use another interrupt, which might be not shared with USB or another important device. signature.asc Description: Digital signature
Re: USB regression (and other failures) in 2.6.2[45]*
On Sat, Feb 16, 2008 at 04:33:41PM -0500, Andrew Buehler wrote: > The associated dmesg (obtained yesterday from booting with the > Flash drive connected) is attached. This dmesg shows that ACPI is not enabled in your kernel config - most likely this is the problem. Try to enable it: 1) In the "Power management options" submenu enable the "Power Management support" option (CONFIG_PM) - if this option is disabled, you will not see the option to enable ACPI below. 2) In the same submenu enable the "ACPI (Advanced Configuration and Power Interface) Support" option (CONFIG_ACPI). Without ACPI support the kernel can use legacy interrupt routing tables from BIOS, but on new systems these tables are often broken due to lack of testing (because all modern operating systems use ACPI instead of these legacy tables). signature.asc Description: Digital signature
Re: USB regression (and other failures) in 2.6.2[45]*
On Sat, Feb 16, 2008 at 04:33:41PM -0500, Andrew Buehler wrote: The associated dmesg (obtained yesterday from booting with the Flash drive connected) is attached. This dmesg shows that ACPI is not enabled in your kernel config - most likely this is the problem. Try to enable it: 1) In the Power management options submenu enable the Power Management support option (CONFIG_PM) - if this option is disabled, you will not see the option to enable ACPI below. 2) In the same submenu enable the ACPI (Advanced Configuration and Power Interface) Support option (CONFIG_ACPI). Without ACPI support the kernel can use legacy interrupt routing tables from BIOS, but on new systems these tables are often broken due to lack of testing (because all modern operating systems use ACPI instead of these legacy tables). signature.asc Description: Digital signature
Re: acpi dsts loading and populate_rootfs
On Sun, 10 Feb 2008 12:58:09 +0100 Eric Piel wrote: > (adding some CC's) > Christoph Hellwig wrote: > > On Sun, Feb 10, 2008 at 08:12:26AM +0100, Christoph Hellwig wrote: > >> Folks, moving this call around hidden behing in completely unreviewed > >> acpi junk is not acceptable. > >> > >> Either populate_rootfs _is_ safe to be called earlier and then we should > >> do it always or it's not. Either way such a change should be posted > >> separately and reviewd on lkml. > Hi, > > I agree with you, the order of the initialization should not be changed > by some config options. Either it works, or it doesn't! So the question > now is : "is fine to move populate_rootfs() earlier?" > > Some data points: > * It used to be called earlier. It was moved to be called later about a > year ago by Linus (8d610dd52dd1da696e199e4b4545f33a2a5de5c6) with this log: > > Make sure we populate the initroot filesystem late enough > > > > We should not initialize rootfs before all the core initializers have > > run. So do it as a separate stage just before starting the regular > > driver initializers. > So there must be some good reasons to keep it late enough... > > * This patch is used in SuSE, and it seems noone has ever had a problem > with the initramfs early init. > > I guess the problem that Linus solved by moving populate_rootfs() > happens only rarely or on only few configurations. Linus, do you > remember what kind of problem it was? How can I reproduce it? AFAIR the problem was that the kernel was trying to exec /sbin/hotplug before some kernel subsystems (e.g., pipe support) were completely initialized, which caused oopses during boot. Initramfs images generated by distro tools usually do not contain /sbin/hotplug, and therefore avoid the problem. (The kernel might also call /sbin/modprobe by itself, but it either does not do it during early boot, or /sbin/modprobe does not use kernel features which had not been initialized yet). > One different solution that I implemented [1] was to have an > "early_populate_rootfs()" before the acpi_early_init(), leaving > populate_rootfs() at the normal place. If the early version fails, it's > ok: we can't override the DSDT, but the later version will work as usual > anyway. This solution also seems to work quite often (it's used in > Ubuntu, Mandriva and PCLinuxOS) This would not solve the problem, because /sbin/hotplug (if present in the initramfs image) will exist too early. > Would that seem an acceptable solution? Or what other way exists? Disabling call_usermodehelper() until all core initializers had completed would fix the problem too; will such change be acceptable? pgpYOMvgE9z9E.pgp Description: PGP signature
Re: acpi dsts loading and populate_rootfs
On Sun, 10 Feb 2008 12:58:09 +0100 Eric Piel wrote: (adding some CC's) Christoph Hellwig wrote: On Sun, Feb 10, 2008 at 08:12:26AM +0100, Christoph Hellwig wrote: Folks, moving this call around hidden behing in completely unreviewed acpi junk is not acceptable. Either populate_rootfs _is_ safe to be called earlier and then we should do it always or it's not. Either way such a change should be posted separately and reviewd on lkml. Hi, I agree with you, the order of the initialization should not be changed by some config options. Either it works, or it doesn't! So the question now is : is fine to move populate_rootfs() earlier? Some data points: * It used to be called earlier. It was moved to be called later about a year ago by Linus (8d610dd52dd1da696e199e4b4545f33a2a5de5c6) with this log: Make sure we populate the initroot filesystem late enough We should not initialize rootfs before all the core initializers have run. So do it as a separate stage just before starting the regular driver initializers. So there must be some good reasons to keep it late enough... * This patch is used in SuSE, and it seems noone has ever had a problem with the initramfs early init. I guess the problem that Linus solved by moving populate_rootfs() happens only rarely or on only few configurations. Linus, do you remember what kind of problem it was? How can I reproduce it? AFAIR the problem was that the kernel was trying to exec /sbin/hotplug before some kernel subsystems (e.g., pipe support) were completely initialized, which caused oopses during boot. Initramfs images generated by distro tools usually do not contain /sbin/hotplug, and therefore avoid the problem. (The kernel might also call /sbin/modprobe by itself, but it either does not do it during early boot, or /sbin/modprobe does not use kernel features which had not been initialized yet). One different solution that I implemented [1] was to have an early_populate_rootfs() before the acpi_early_init(), leaving populate_rootfs() at the normal place. If the early version fails, it's ok: we can't override the DSDT, but the later version will work as usual anyway. This solution also seems to work quite often (it's used in Ubuntu, Mandriva and PCLinuxOS) This would not solve the problem, because /sbin/hotplug (if present in the initramfs image) will exist too early. Would that seem an acceptable solution? Or what other way exists? Disabling call_usermodehelper() until all core initializers had completed would fix the problem too; will such change be acceptable? pgpYOMvgE9z9E.pgp Description: PGP signature
Re: [PATCH] fs: Add romfs version 2
On Fri, 13 Jul 2007 16:01:48 +1000 Lindsay Roberts wrote: > * Increases romfs partition size limit from 2GB to 4GB. This should be a separate patch. > * Adds new derivative of romfs filesystem (rom2fs) with > block aligned regular file data to bring performance > parity with ext2/3. This is about 225% of the read > speed of the existing romfs. > > Signed-off-by: Lindsay Roberts <[EMAIL PROTECTED]> > --- > genromfs patch available at http://rom2fs.googlepages.com . > > Documentation/filesystems/romfs.txt | 34 +-- > fs/romfs/inode.c| 195 > +-- > include/linux/romfs_fs.h|1 + > 3 files changed, 187 insertions(+), 43 deletions(-) > > diff --git a/Documentation/filesystems/romfs.txt > b/Documentation/filesystems/romfs.txt > index 2d2a7b2..170b1cc 100644 > --- a/Documentation/filesystems/romfs.txt > +++ b/Documentation/filesystems/romfs.txt > @@ -7,6 +7,10 @@ similar feature, and even the possibility of a small > kernel, with a > file system which doesn't take up useful memory from the router > functions in the basement of your office. > > +The romfs version 2 filesystem is a slight derivation created to fix > +performance issues with file data unaligned to logical disk blocks. > +It differs only in its placement of regular file data. > + > For comparison, both the older minix and xiafs (the latter is now > defunct) filesystems, compiled as module need more than 2 bytes, > while romfs is less than a page, about 4000 bytes (assuming i586 > @@ -18,7 +22,10 @@ with romfs, it needed 3079 blocks. > > To create such a file system, you'll need a user program named > genromfs. It is available via anonymous ftp on sunsite.unc.edu and > -its mirrors, in the /pub/Linux/system/recovery/ directory. > +its mirrors, in the /pub/Linux/system/recovery/ directory, as well as > +at the sourceforge project http://romfs.sourceforge.net/ . A genromfs > +patch to support version 2 is available at > +http://rom2fs.googlepages.com/ . > > As the name suggests, romfs could be also used (space-efficiently) on > various read-only media, like (E)EPROM disks if someone will have the > @@ -43,6 +50,11 @@ from the network, and you will have all the > tools/modules available > from a nearby server, so you don't want to carry two disks for this > purpose, just because it won't fit into ext2. > > +romfs also has a secondary use in reproducibility. The absence of > +both timestamps and permission information coupled with the read-only > +nature of the file system gives it amazing capability as a byte > +reproducible medium for a given directory structure. Not sure about this - the placement of file headers in romfs is completely unspecified (a linked list is used), file names in directories are not required to be in a sorted order... Of course, a particular genromfs implementation could always produce the same bytestream for a given set of files, but the format itself does not really have any particular advantages. > + > romfs operates on block devices as you can expect, and the underlying > structure is very simple. Every accessible structure begins on 16 > byte boundaries for fast access. The minimum space a file will take > @@ -50,7 +62,8 @@ is 32 bytes (this is an empty file, with a less than > 16 character > name). The maximum overhead for any non-empty file is the header, and > the 16 byte padding for the name and the contents, also 16+14+15 = 45 > bytes. This is quite rare however, since most file names are longer > -than 3 bytes, and shorter than 15 bytes. > +than 3 bytes, and shorter than 15 bytes. romfs version 2 adds > +additional overhead in order to align file data to (1k) disk blocks. > > The layout of the filesystem is the following: > > @@ -59,7 +72,7 @@ offset content > +---+---+---+---+ >0 | - | r | o | m | \ > +---+---+---+---+ The ASCII representation of those bytes > - 4 | 1 | f | s | - | /(i.e. "-rom1fs-") > + 4 | 1 | f | s | - | /(i.e. "-rom1fs-" or "-rom2fs-") > +---+---+---+---+ >8 | full size | The number of accessible bytes in this fs. > +---+---+---+---+ > @@ -101,8 +114,10 @@ offset content > 16 | file name | The zero terminated name of the file, > : : padded to 16 byte boundary > +---+---+---+---+ > - xx | file data | > - : : > + xx | file data | In the case of romfs version 2 - regular > + : : files, this offset is padded to the next > +1024 byte block relative to the start of > +the filesystem. You add padding between the file header and data. But you can also add padding before the file header to make it end on a block boundary; I don't see any requirement that the next file header must be placed immediately after the previous file data (the header
Re: [PATCH] fs: Add romfs version 2
On Fri, 13 Jul 2007 16:01:48 +1000 Lindsay Roberts wrote: * Increases romfs partition size limit from 2GB to 4GB. This should be a separate patch. * Adds new derivative of romfs filesystem (rom2fs) with block aligned regular file data to bring performance parity with ext2/3. This is about 225% of the read speed of the existing romfs. Signed-off-by: Lindsay Roberts [EMAIL PROTECTED] --- genromfs patch available at http://rom2fs.googlepages.com . Documentation/filesystems/romfs.txt | 34 +-- fs/romfs/inode.c| 195 +-- include/linux/romfs_fs.h|1 + 3 files changed, 187 insertions(+), 43 deletions(-) diff --git a/Documentation/filesystems/romfs.txt b/Documentation/filesystems/romfs.txt index 2d2a7b2..170b1cc 100644 --- a/Documentation/filesystems/romfs.txt +++ b/Documentation/filesystems/romfs.txt @@ -7,6 +7,10 @@ similar feature, and even the possibility of a small kernel, with a file system which doesn't take up useful memory from the router functions in the basement of your office. +The romfs version 2 filesystem is a slight derivation created to fix +performance issues with file data unaligned to logical disk blocks. +It differs only in its placement of regular file data. + For comparison, both the older minix and xiafs (the latter is now defunct) filesystems, compiled as module need more than 2 bytes, while romfs is less than a page, about 4000 bytes (assuming i586 @@ -18,7 +22,10 @@ with romfs, it needed 3079 blocks. To create such a file system, you'll need a user program named genromfs. It is available via anonymous ftp on sunsite.unc.edu and -its mirrors, in the /pub/Linux/system/recovery/ directory. +its mirrors, in the /pub/Linux/system/recovery/ directory, as well as +at the sourceforge project http://romfs.sourceforge.net/ . A genromfs +patch to support version 2 is available at +http://rom2fs.googlepages.com/ . As the name suggests, romfs could be also used (space-efficiently) on various read-only media, like (E)EPROM disks if someone will have the @@ -43,6 +50,11 @@ from the network, and you will have all the tools/modules available from a nearby server, so you don't want to carry two disks for this purpose, just because it won't fit into ext2. +romfs also has a secondary use in reproducibility. The absence of +both timestamps and permission information coupled with the read-only +nature of the file system gives it amazing capability as a byte +reproducible medium for a given directory structure. Not sure about this - the placement of file headers in romfs is completely unspecified (a linked list is used), file names in directories are not required to be in a sorted order... Of course, a particular genromfs implementation could always produce the same bytestream for a given set of files, but the format itself does not really have any particular advantages. + romfs operates on block devices as you can expect, and the underlying structure is very simple. Every accessible structure begins on 16 byte boundaries for fast access. The minimum space a file will take @@ -50,7 +62,8 @@ is 32 bytes (this is an empty file, with a less than 16 character name). The maximum overhead for any non-empty file is the header, and the 16 byte padding for the name and the contents, also 16+14+15 = 45 bytes. This is quite rare however, since most file names are longer -than 3 bytes, and shorter than 15 bytes. +than 3 bytes, and shorter than 15 bytes. romfs version 2 adds +additional overhead in order to align file data to (1k) disk blocks. The layout of the filesystem is the following: @@ -59,7 +72,7 @@ offset content +---+---+---+---+ 0 | - | r | o | m | \ +---+---+---+---+ The ASCII representation of those bytes - 4 | 1 | f | s | - | /(i.e. -rom1fs-) + 4 | 1 | f | s | - | /(i.e. -rom1fs- or -rom2fs-) +---+---+---+---+ 8 | full size | The number of accessible bytes in this fs. +---+---+---+---+ @@ -101,8 +114,10 @@ offset content 16 | file name | The zero terminated name of the file, : : padded to 16 byte boundary +---+---+---+---+ - xx | file data | - : : + xx | file data | In the case of romfs version 2 - regular + : : files, this offset is padded to the next +1024 byte block relative to the start of +the filesystem. You add padding between the file header and data. But you can also add padding before the file header to make it end on a block boundary; I don't see any requirement that the next file header must be placed immediately after the previous file data (the header contains an explicit pointer to the next file header in the directory). The only file header which
Re: Is PIE randomization breaking klibc binaries?
On Wed, 25 Jul 2007 08:32:43 +0200 Ulrich Kunitz wrote: [...] > Here is some output from objdump: > > $ objdump -x bin/sleep > > bin/sleep: file format elf64-x86-64 > bin/sleep > architecture: i386:x86-64, flags 0x0102: > EXEC_P, D_PAGED > start address 0x0040014c > > Program Header: > PHDR off0x0040 vaddr 0x00400040 paddr > 0x00400040 align 2**3 > filesz 0x00e0 memsz 0x00e0 flags r-x > INTERP off0x0120 vaddr 0x00400120 paddr > 0x00400120 align 2**0 > filesz 0x002a memsz 0x002a flags r-- > LOAD off0x vaddr 0x0040 paddr > 0x0040 align 2**21 > filesz 0x01c3 memsz 0x01c3 flags r-x >STACK off0x vaddr 0x paddr > 0x align 2**3 > filesz 0x memsz 0x flags rwx > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .interp 002a 00400120 00400120 0120 2**0 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 1 .text 0059 0040014c 0040014c 014c 2**2 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 2 .rodata 001e 004001a5 004001a5 01a5 2**0 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 3 .gnu_debuglink 000c 01c3 > 2**0 > CONTENTS, READONLY > SYMBOL TABLE: > no symbols > > > $ objdump -x lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so What version of klibc is this? > > lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so: file format elf64-x86-64 > lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so > architecture: i386:x86-64, flags 0x0102: > EXEC_P, D_PAGED > start address 0x00200200 > > Program Header: > LOAD off0x vaddr 0x0020 paddr > 0x0020 align 2**21 > filesz 0x0001197e memsz 0x0001197e flags r-x > LOAD off0x00011980 vaddr 0x00411980 paddr > 0x00411980 align 2**21 Note that the vaddr here can overlap the binary which is linked starting at 0x40. This is the bug which I have found and fixed some time ago: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=10df6dfb13ffefe716f12136bbc667f18ff64744 The fix was included in klibc-1.4.35, but does not seem to be applied in your case (the alignment is still 2**21 - it should be 2**20) - so either you are using an old klibc, or the "-z max-page-size=0x10" option does not take effect for some reason. In my case the buggy klibc worked fine with a stock 2.6.18 kernel, but broke when the execshield patch was applied - and the commit 60bfba7e code comes from execshield, so it looks like the same problem. > filesz 0x0100 memsz 0x4288 flags rw- >STACK off0x vaddr 0x paddr > 0x align 2**3 > filesz 0x memsz 0x flags rwx > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text da94 00200200 00200200 0200 2**2 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 1 .rodata 3cde 0020dca0 0020dca0 dca0 2**5 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 2 .data 0100 00411980 00411980 00011980 2**5 > CONTENTS, ALLOC, LOAD, DATA > 3 .bss 4188 00411a80 00411a80 00011a80 2**5 > ALLOC > 4 .gnu_debuglink 002c 00011a80 > 2**0 > CONTENTS, READONLY > SYMBOL TABLE: > no symbols > pgpK6wcG8x976.pgp Description: PGP signature
Re: Is PIE randomization breaking klibc binaries?
On Wed, 25 Jul 2007 08:32:43 +0200 Ulrich Kunitz wrote: [...] Here is some output from objdump: $ objdump -x bin/sleep bin/sleep: file format elf64-x86-64 bin/sleep architecture: i386:x86-64, flags 0x0102: EXEC_P, D_PAGED start address 0x0040014c Program Header: PHDR off0x0040 vaddr 0x00400040 paddr 0x00400040 align 2**3 filesz 0x00e0 memsz 0x00e0 flags r-x INTERP off0x0120 vaddr 0x00400120 paddr 0x00400120 align 2**0 filesz 0x002a memsz 0x002a flags r-- LOAD off0x vaddr 0x0040 paddr 0x0040 align 2**21 filesz 0x01c3 memsz 0x01c3 flags r-x STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .interp 002a 00400120 00400120 0120 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .text 0059 0040014c 0040014c 014c 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .rodata 001e 004001a5 004001a5 01a5 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .gnu_debuglink 000c 01c3 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols $ objdump -x lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so What version of klibc is this? lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so: file format elf64-x86-64 lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so architecture: i386:x86-64, flags 0x0102: EXEC_P, D_PAGED start address 0x00200200 Program Header: LOAD off0x vaddr 0x0020 paddr 0x0020 align 2**21 filesz 0x0001197e memsz 0x0001197e flags r-x LOAD off0x00011980 vaddr 0x00411980 paddr 0x00411980 align 2**21 Note that the vaddr here can overlap the binary which is linked starting at 0x40. This is the bug which I have found and fixed some time ago: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=10df6dfb13ffefe716f12136bbc667f18ff64744 The fix was included in klibc-1.4.35, but does not seem to be applied in your case (the alignment is still 2**21 - it should be 2**20) - so either you are using an old klibc, or the -z max-page-size=0x10 option does not take effect for some reason. In my case the buggy klibc worked fine with a stock 2.6.18 kernel, but broke when the execshield patch was applied - and the commit 60bfba7e code comes from execshield, so it looks like the same problem. filesz 0x0100 memsz 0x4288 flags rw- STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .text da94 00200200 00200200 0200 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 3cde 0020dca0 0020dca0 dca0 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 0100 00411980 00411980 00011980 2**5 CONTENTS, ALLOC, LOAD, DATA 3 .bss 4188 00411a80 00411a80 00011a80 2**5 ALLOC 4 .gnu_debuglink 002c 00011a80 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols pgpK6wcG8x976.pgp Description: PGP signature
Re: [PATCH 2.6.21.3] ppp_mppe: account for osize too small errors in mppe_decompress()
On Tue, 05 Jun 2007 22:23:02 +1100 Konstantin Sharlaimov wrote:
> Prevent mppe_decompress() from generating "osize too small" errors when
> checking
> for output buffer size. When receiving a packet of mru size the output buffer
> for decrypted data is 1 byte too small since mppe_decompress() tries to
> account
> for possible PFC, however later in code it is assumed no PFC.
>
> Adjusting the check prevented there errors from occurring.
>
> Signed-off-by: Konstantin Sharlaimov <[EMAIL PROTECTED]>
> ---
> --- linux-2.6.21.3/drivers/net/ppp_mppe.c.orig2007-06-01
> 20:57:04.0 +1100
> +++ linux-2.6.21.3/drivers/net/ppp_mppe.c 2007-06-05 21:46:30.0
> +1100
> @@ -493,14 +493,14 @@ mppe_decompress(void *arg, unsigned char
>
> /*
>* Make sure we have enough room to decrypt the packet.
> - * Note that for our test we only subtract 1 byte whereas in
> - * mppe_compress() we added 2 bytes (+MPPE_OVHD);
> - * this is to account for possible PFC.
> + * To account for possible PFC we should only subtract 1
> + * byte whereas in mppe_compress() we added 2 bytes (+MPPE_OVHD);
> + * However, we assume no PFC, thus subtracting 2 bytes.
>*/
> - if (osize < isize - MPPE_OVHD - 1) {
> + if (osize < isize - MPPE_OVHD - 2) {
> printk(KERN_DEBUG "mppe_decompress[%d]: osize too small! "
> "(have: %d need: %d)\n", state->unit,
> -osize, isize - MPPE_OVHD - 1);
> +osize, isize - MPPE_OVHD - 2);
> return DECOMP_ERROR;
> }
> osize = isize - MPPE_OVHD - 2; /* assume no PFC */
Seems that this patch is not correct - even though the comment above
says "assume no PFC", the subsequent code actually supports PFC:
/*
* Do PFC decompression.
* This would be nicer if we were given the actual sk_buff
* instead of a char *.
*/
if ((obuf[0] & 0x01) != 0) {
obuf[1] = obuf[0];
obuf[0] = 0;
obuf++;
osize++;
}
Therefore, depending on the packet contents, the decompressor may
really need that extra byte in the output buffer, and changing the
check may cause buffer overflows.
pgp8XBA6f7esb.pgp
Description: PGP signature
Re: [PATCH 2.6.21.3] ppp_mppe: account for osize too small errors in mppe_decompress()
On Tue, 05 Jun 2007 22:23:02 +1100 Konstantin Sharlaimov wrote:
Prevent mppe_decompress() from generating osize too small errors when
checking
for output buffer size. When receiving a packet of mru size the output buffer
for decrypted data is 1 byte too small since mppe_decompress() tries to
account
for possible PFC, however later in code it is assumed no PFC.
Adjusting the check prevented there errors from occurring.
Signed-off-by: Konstantin Sharlaimov [EMAIL PROTECTED]
---
--- linux-2.6.21.3/drivers/net/ppp_mppe.c.orig2007-06-01
20:57:04.0 +1100
+++ linux-2.6.21.3/drivers/net/ppp_mppe.c 2007-06-05 21:46:30.0
+1100
@@ -493,14 +493,14 @@ mppe_decompress(void *arg, unsigned char
/*
* Make sure we have enough room to decrypt the packet.
- * Note that for our test we only subtract 1 byte whereas in
- * mppe_compress() we added 2 bytes (+MPPE_OVHD);
- * this is to account for possible PFC.
+ * To account for possible PFC we should only subtract 1
+ * byte whereas in mppe_compress() we added 2 bytes (+MPPE_OVHD);
+ * However, we assume no PFC, thus subtracting 2 bytes.
*/
- if (osize isize - MPPE_OVHD - 1) {
+ if (osize isize - MPPE_OVHD - 2) {
printk(KERN_DEBUG mppe_decompress[%d]: osize too small!
(have: %d need: %d)\n, state-unit,
-osize, isize - MPPE_OVHD - 1);
+osize, isize - MPPE_OVHD - 2);
return DECOMP_ERROR;
}
osize = isize - MPPE_OVHD - 2; /* assume no PFC */
Seems that this patch is not correct - even though the comment above
says assume no PFC, the subsequent code actually supports PFC:
/*
* Do PFC decompression.
* This would be nicer if we were given the actual sk_buff
* instead of a char *.
*/
if ((obuf[0] 0x01) != 0) {
obuf[1] = obuf[0];
obuf[0] = 0;
obuf++;
osize++;
}
Therefore, depending on the packet contents, the decompressor may
really need that extra byte in the output buffer, and changing the
check may cause buffer overflows.
pgp8XBA6f7esb.pgp
Description: PGP signature
Re: Size of kernel modules
On Sat, 9 Jun 2007 15:59:55 +0200 (CEST) Jan Engelhardt wrote: > On Jun 9 2007 08:08, Jon Masters wrote: > > > >So I missed half of this conversation - you're saying that on a > >CONFIG_DEBUG_KERNEL, you have such large .ko module files that depmod > >segfaults? Can I get a core dump or any further information? :-) > > Just make sure your /lib/modules/ is like 300 megabytes or > even more. Then depmod will clog up quite a lot memory already. > (Taking a 256 mb ram machine for example, no swap or just very > little.) I have noticed such problems before - the depmod code just loads whole module files into memory. The situation is especially bad when module-init-tools is configured with --enable-zlib - in this case memory for all module files is allocated with malloc(). (Without --enable-zlib depmod just mmaps all module files, which at least does not eat swap, and probably does not bring unused pages into memory.) I have made some patches to module-init-tools - unfortunately, they probably don't apply to the current version (they were based on v3.3-pre4): git://git.altlinux.org/people/vsu/packages/module-init-tools.git (release-module-data branch) http://git.altlinux.org/people/vsu/packages/?p=module-init-tools.git;a=shortlog;h=release-module-data pgpDeN8a3oPz6.pgp Description: PGP signature
Re: Size of kernel modules
On Sat, 9 Jun 2007 15:59:55 +0200 (CEST) Jan Engelhardt wrote: On Jun 9 2007 08:08, Jon Masters wrote: So I missed half of this conversation - you're saying that on a CONFIG_DEBUG_KERNEL, you have such large .ko module files that depmod segfaults? Can I get a core dump or any further information? :-) Just make sure your /lib/modules/kernel is like 300 megabytes or even more. Then depmod will clog up quite a lot memory already. (Taking a 256 mb ram machine for example, no swap or just very little.) I have noticed such problems before - the depmod code just loads whole module files into memory. The situation is especially bad when module-init-tools is configured with --enable-zlib - in this case memory for all module files is allocated with malloc(). (Without --enable-zlib depmod just mmaps all module files, which at least does not eat swap, and probably does not bring unused pages into memory.) I have made some patches to module-init-tools - unfortunately, they probably don't apply to the current version (they were based on v3.3-pre4): git://git.altlinux.org/people/vsu/packages/module-init-tools.git (release-module-data branch) http://git.altlinux.org/people/vsu/packages/?p=module-init-tools.git;a=shortlog;h=release-module-data pgpDeN8a3oPz6.pgp Description: PGP signature
Re: D-Link DFE-580TX 4 port Server Adapter problem: only 2 of 4 ports
On Fri, 13 Apr 2007 03:48:22 +0200 Pallai Roland wrote: > I've got a problem with my DFE-580TX cards when I installed thoose into > a new server box. One card has been worked before in a test box, > it's sure, here is a dmesg snippet when everything was OK: > > Apr 3 22:10:38 cyrax kernel: sundance.c:v1.2 11-Sep-2006 Written by Donald > Becker > Apr 3 22:10:38 cyrax kernel: http://www.scyld.com/network/sundance.html > Apr 3 22:10:38 cyrax kernel: ACPI: PCI Interrupt :02:04.0[A] -> GSI 21 > (level, low) -> IRQ 23 > Apr 3 22:10:38 cyrax kernel: eth2: D-Link DFE-580TX 4 port Server Adapter at > 0001a800, 00:0d:88:cc:da:dc, IRQ 23. > Apr 3 22:10:38 cyrax kernel: eth2: MII PHY found at address 1, status 0x7809 > advertising 01e1. > Apr 3 22:10:38 cyrax kernel: ACPI: PCI Interrupt :02:05.0[A] -> GSI 22 > (level, low) -> IRQ 18 > Apr 3 22:10:39 cyrax kernel: eth3: D-Link DFE-580TX 4 port Server Adapter at > 0001b000, 00:0d:88:cc:da:dd, IRQ 18. > Apr 3 22:10:39 cyrax kernel: eth3: MII PHY found at address 1, status 0x7809 > advertising 01e1. > Apr 3 22:10:39 cyrax kernel: ACPI: PCI Interrupt :02:06.0[A] -> GSI 23 > (level, low) -> IRQ 19 > Apr 3 22:10:39 cyrax kernel: eth4: D-Link DFE-580TX 4 port Server Adapter at > 0001b400, 00:0d:88:cc:da:de, IRQ 19. > Apr 3 22:10:39 cyrax kernel: eth4: MII PHY found at address 1, status 0x7809 > advertising 01e1. > Apr 3 22:10:39 cyrax kernel: ACPI: PCI Interrupt :02:07.0[A] -> GSI 20 > (level, low) -> IRQ 20 > Apr 3 22:10:39 cyrax kernel: eth5: D-Link DFE-580TX 4 port Server Adapter at > 0001b800, 00:0d:88:cc:da:df, IRQ 20. > Apr 3 22:10:39 cyrax kernel: eth5: MII PHY found at address 1, status 0x7809 > advertising 01e1. > > And the current dmesg from the new box, when I've only 2 of 4 ports on each > card: > > sundance.c:v1.2 11-Sep-2006 Written by Donald Becker > http://www.scyld.com/network/sundance.html > ACPI: PCI Interrupt :05:04.0[A] -> GSI 21 (level, low) -> IRQ 22 > eth2: D-Link DFE-580TX 4 port Server Adapter at 00012180, 00:00:00:00:00:00, > IRQ 22. > eth2: No MII transceiver found, aborting. ASIC status > ACPI: PCI Interrupt :05:05.0[A] -> GSI 22 (level, low) -> IRQ 23 > eth2: D-Link DFE-580TX 4 port Server Adapter at 00012100, 00:00:00:00:00:00, > IRQ 23. > eth2: No MII transceiver found, aborting. ASIC status > ACPI: PCI Interrupt :05:06.0[A] -> GSI 23 (level, low) -> IRQ 19 > eth2: D-Link DFE-580TX 4 port Server Adapter at 00012080, 00:0d:88:cc:da:ee, > IRQ 19. > eth2: MII PHY found at address 1, status 0x7809 advertising 01e1. > ACPI: PCI Interrupt :05:07.0[A] -> GSI 20 (level, low) -> IRQ 21 > eth3: D-Link DFE-580TX 4 port Server Adapter at 00012000, 00:0d:88:cc:da:ef, > IRQ 21. > eth3: MII PHY found at address 1, status 0x7809 advertising 01e1. > ACPI: PCI Interrupt :06:04.0[A] -> GSI 22 (level, low) -> IRQ 23 > eth4: D-Link DFE-580TX 4 port Server Adapter at 00011180, 00:00:00:00:00:00, > IRQ 23. > eth4: No MII transceiver found, aborting. ASIC status > ACPI: PCI Interrupt :06:05.0[A] -> GSI 21 (level, low) -> IRQ 22 > eth4: D-Link DFE-580TX 4 port Server Adapter at 00011100, 00:00:00:00:00:00, > IRQ 22. > eth4: No MII transceiver found, aborting. ASIC status > ACPI: PCI Interrupt :06:06.0[A] -> GSI 20 (level, low) -> IRQ 21 > eth4: D-Link DFE-580TX 4 port Server Adapter at 00011080, 00:0d:88:cc:da:de, > IRQ 21. > eth4: MII PHY found at address 1, status 0x7809 advertising 01e1. > ACPI: PCI Interrupt :06:07.0[A] -> GSI 23 (level, low) -> IRQ 19 > eth5: D-Link DFE-580TX 4 port Server Adapter at 00011000, 00:0d:88:cc:da:df, > IRQ 19. > eth5: MII PHY found at address 1, status 0x7809 advertising 01e1. > > > Kernel version is vanilla 2.6.20.3, Sundance MMIO disabled in the > config. I can send lspci, full dmesg, .config if anyone interested > in. Maybe it's a BIOS problem? What should I try? Sergey Afonin (cc'd) ran into the same problem when trying to use the DFE-580TX card on a new machine with the Intel 945G chipset (I don't have exact motherboard info - PCI subsystem ID matches Intel D945GTP) and 2.6.18-based x86_64 kernel. ALT Linux Bugzilla entry (sorry - it's in Russian): https://bugzilla.altlinux.org/show_bug.cgi?id=11687 Full dmesg output: https://bugzilla.altlinux.org/attachment.cgi?id=1940 lspci -vvxxx output:https://bugzilla.altlinux.org/attachment.cgi?id=1942 I have tracked down this problem to a bad I/O base address assignment for network chips. As you may find from the lspci -vvxxx info, the following addresses were assigned to region 0 of these chips: 05:04.0 - 0x1180 05:05.0 - 0x1100 05:06.0 - 0x1080 05:07.0 - 0x1000 Chips at 0x1000 and 0x1080 work fine; however, chips at 0x1100 and 0x1180 are not reachable, because the PCI-PCI bridge 04:00.0 has the NoISA bit in the BridgeCtl register set, and these addresses are being treated as ISA port aliases and not forwarded to the internal PCI
Re: D-Link DFE-580TX 4 port Server Adapter problem: only 2 of 4 ports
On Fri, 13 Apr 2007 03:48:22 +0200 Pallai Roland wrote: I've got a problem with my DFE-580TX cards when I installed thoose into a new server box. One card has been worked before in a test box, it's sure, here is a dmesg snippet when everything was OK: Apr 3 22:10:38 cyrax kernel: sundance.c:v1.2 11-Sep-2006 Written by Donald Becker Apr 3 22:10:38 cyrax kernel: http://www.scyld.com/network/sundance.html Apr 3 22:10:38 cyrax kernel: ACPI: PCI Interrupt :02:04.0[A] - GSI 21 (level, low) - IRQ 23 Apr 3 22:10:38 cyrax kernel: eth2: D-Link DFE-580TX 4 port Server Adapter at 0001a800, 00:0d:88:cc:da:dc, IRQ 23. Apr 3 22:10:38 cyrax kernel: eth2: MII PHY found at address 1, status 0x7809 advertising 01e1. Apr 3 22:10:38 cyrax kernel: ACPI: PCI Interrupt :02:05.0[A] - GSI 22 (level, low) - IRQ 18 Apr 3 22:10:39 cyrax kernel: eth3: D-Link DFE-580TX 4 port Server Adapter at 0001b000, 00:0d:88:cc:da:dd, IRQ 18. Apr 3 22:10:39 cyrax kernel: eth3: MII PHY found at address 1, status 0x7809 advertising 01e1. Apr 3 22:10:39 cyrax kernel: ACPI: PCI Interrupt :02:06.0[A] - GSI 23 (level, low) - IRQ 19 Apr 3 22:10:39 cyrax kernel: eth4: D-Link DFE-580TX 4 port Server Adapter at 0001b400, 00:0d:88:cc:da:de, IRQ 19. Apr 3 22:10:39 cyrax kernel: eth4: MII PHY found at address 1, status 0x7809 advertising 01e1. Apr 3 22:10:39 cyrax kernel: ACPI: PCI Interrupt :02:07.0[A] - GSI 20 (level, low) - IRQ 20 Apr 3 22:10:39 cyrax kernel: eth5: D-Link DFE-580TX 4 port Server Adapter at 0001b800, 00:0d:88:cc:da:df, IRQ 20. Apr 3 22:10:39 cyrax kernel: eth5: MII PHY found at address 1, status 0x7809 advertising 01e1. And the current dmesg from the new box, when I've only 2 of 4 ports on each card: sundance.c:v1.2 11-Sep-2006 Written by Donald Becker http://www.scyld.com/network/sundance.html ACPI: PCI Interrupt :05:04.0[A] - GSI 21 (level, low) - IRQ 22 eth2: D-Link DFE-580TX 4 port Server Adapter at 00012180, 00:00:00:00:00:00, IRQ 22. eth2: No MII transceiver found, aborting. ASIC status ACPI: PCI Interrupt :05:05.0[A] - GSI 22 (level, low) - IRQ 23 eth2: D-Link DFE-580TX 4 port Server Adapter at 00012100, 00:00:00:00:00:00, IRQ 23. eth2: No MII transceiver found, aborting. ASIC status ACPI: PCI Interrupt :05:06.0[A] - GSI 23 (level, low) - IRQ 19 eth2: D-Link DFE-580TX 4 port Server Adapter at 00012080, 00:0d:88:cc:da:ee, IRQ 19. eth2: MII PHY found at address 1, status 0x7809 advertising 01e1. ACPI: PCI Interrupt :05:07.0[A] - GSI 20 (level, low) - IRQ 21 eth3: D-Link DFE-580TX 4 port Server Adapter at 00012000, 00:0d:88:cc:da:ef, IRQ 21. eth3: MII PHY found at address 1, status 0x7809 advertising 01e1. ACPI: PCI Interrupt :06:04.0[A] - GSI 22 (level, low) - IRQ 23 eth4: D-Link DFE-580TX 4 port Server Adapter at 00011180, 00:00:00:00:00:00, IRQ 23. eth4: No MII transceiver found, aborting. ASIC status ACPI: PCI Interrupt :06:05.0[A] - GSI 21 (level, low) - IRQ 22 eth4: D-Link DFE-580TX 4 port Server Adapter at 00011100, 00:00:00:00:00:00, IRQ 22. eth4: No MII transceiver found, aborting. ASIC status ACPI: PCI Interrupt :06:06.0[A] - GSI 20 (level, low) - IRQ 21 eth4: D-Link DFE-580TX 4 port Server Adapter at 00011080, 00:0d:88:cc:da:de, IRQ 21. eth4: MII PHY found at address 1, status 0x7809 advertising 01e1. ACPI: PCI Interrupt :06:07.0[A] - GSI 23 (level, low) - IRQ 19 eth5: D-Link DFE-580TX 4 port Server Adapter at 00011000, 00:0d:88:cc:da:df, IRQ 19. eth5: MII PHY found at address 1, status 0x7809 advertising 01e1. Kernel version is vanilla 2.6.20.3, Sundance MMIO disabled in the config. I can send lspci, full dmesg, .config if anyone interested in. Maybe it's a BIOS problem? What should I try? Sergey Afonin (cc'd) ran into the same problem when trying to use the DFE-580TX card on a new machine with the Intel 945G chipset (I don't have exact motherboard info - PCI subsystem ID matches Intel D945GTP) and 2.6.18-based x86_64 kernel. ALT Linux Bugzilla entry (sorry - it's in Russian): https://bugzilla.altlinux.org/show_bug.cgi?id=11687 Full dmesg output: https://bugzilla.altlinux.org/attachment.cgi?id=1940 lspci -vvxxx output:https://bugzilla.altlinux.org/attachment.cgi?id=1942 I have tracked down this problem to a bad I/O base address assignment for network chips. As you may find from the lspci -vvxxx info, the following addresses were assigned to region 0 of these chips: 05:04.0 - 0x1180 05:05.0 - 0x1100 05:06.0 - 0x1080 05:07.0 - 0x1000 Chips at 0x1000 and 0x1080 work fine; however, chips at 0x1100 and 0x1180 are not reachable, because the PCI-PCI bridge 04:00.0 has the NoISA bit in the BridgeCtl register set, and these addresses are being treated as ISA port aliases and not forwarded to the internal PCI bus of the card. (The bridge at 00:1e.0 also has NoISA set, but this is not a problem, because
"IPV6: Disallow RH0 by default" patch looks broken (Re: Linux 2.6.20.9)
On Thu, 26 Apr 2007 00:25:03 -0700 Greg KH wrote:
[...]
> diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
> index 0711f92..5fd7cf9 100644
> --- a/net/ipv6/exthdrs.c
> +++ b/net/ipv6/exthdrs.c
[...]
> @@ -378,6 +395,22 @@ static int ipv6_rthdr_rcv(struct sk_buff **skbp)
>
> hdr = (struct ipv6_rt_hdr *) skb->h.raw;
>
> + switch (hdr->type) {
> +#ifdef CONFIG_IPV6_MIP6
> + break;
I suppose "case IPV6_SRCRT_TYPE_2:" is missing before "break"?
The same broken patch went in 2.6.21.
> +#endif
> + case IPV6_SRCRT_TYPE_0:
> + if (accept_source_route > 0)
> + break;
> + kfree_skb(skb);
> + return -1;
> + default:
> + IP6_INC_STATS_BH(ip6_dst_idev(skb->dst),
> + IPSTATS_MIB_INHDRERRORS);
> + icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, (>type) -
> skb->nh.raw);
> + return -1;
> + }
> +
> if (ipv6_addr_is_multicast(>nh.ipv6h->daddr) ||
> skb->pkt_type != PACKET_HOST) {
> IP6_INC_STATS_BH(ip6_dst_idev(skb->dst),
[...]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
IPV6: Disallow RH0 by default patch looks broken (Re: Linux 2.6.20.9)
On Thu, 26 Apr 2007 00:25:03 -0700 Greg KH wrote:
[...]
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 0711f92..5fd7cf9 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
[...]
@@ -378,6 +395,22 @@ static int ipv6_rthdr_rcv(struct sk_buff **skbp)
hdr = (struct ipv6_rt_hdr *) skb-h.raw;
+ switch (hdr-type) {
+#ifdef CONFIG_IPV6_MIP6
+ break;
I suppose case IPV6_SRCRT_TYPE_2: is missing before break?
The same broken patch went in 2.6.21.
+#endif
+ case IPV6_SRCRT_TYPE_0:
+ if (accept_source_route 0)
+ break;
+ kfree_skb(skb);
+ return -1;
+ default:
+ IP6_INC_STATS_BH(ip6_dst_idev(skb-dst),
+ IPSTATS_MIB_INHDRERRORS);
+ icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, (hdr-type) -
skb-nh.raw);
+ return -1;
+ }
+
if (ipv6_addr_is_multicast(skb-nh.ipv6h-daddr) ||
skb-pkt_type != PACKET_HOST) {
IP6_INC_STATS_BH(ip6_dst_idev(skb-dst),
[...]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [mit-devel] Re: module-init-tools-3.3-pre10 available
On Sat, Feb 24, 2007 at 11:13:45AM -0500, Jon Masters wrote: > Jan Engelhardt wrote: > > >Out of the box perhaps if it is the .tar.bz2 archive, but the same does not > >always hold for CVS repos, much less SVNs [random guess on svn]. He who > >pulls > >from a developer tree mostly knows to run 'autogen.sh' or 'autoreconf -fi' > >beforehand. > > You know what, you're right of course. Ok, I'm taking those back *out* > of the repo in the next update and then will have a script generate > these for the tarball. That does sound like the right thing. Has a final decision about generated files been made? I don't see any updates in the git repo, and man pages are still broken (any attempt to regenerate them will cause changes to the generated files to be lost). signature.asc Description: Digital signature
Re: [mit-devel] Re: module-init-tools-3.3-pre10 available
On Sat, Feb 24, 2007 at 11:13:45AM -0500, Jon Masters wrote: Jan Engelhardt wrote: Out of the box perhaps if it is the .tar.bz2 archive, but the same does not always hold for CVS repos, much less SVNs [random guess on svn]. He who pulls from a developer tree mostly knows to run 'autogen.sh' or 'autoreconf -fi' beforehand. You know what, you're right of course. Ok, I'm taking those back *out* of the repo in the next update and then will have a script generate these for the tarball. That does sound like the right thing. Has a final decision about generated files been made? I don't see any updates in the git repo, and man pages are still broken (any attempt to regenerate them will cause changes to the generated files to be lost). signature.asc Description: Digital signature
Re: Sleeping thread not receive signal until it wakes up
On Fri, 9 Mar 2007 16:10:29 -0800 Luong Ngo wrote: > Thanks Parav, adding singal_allow(SIGALRM) wakeup the blocking > interruptible_sleep_on and checking the signal_pending would return > true now. This means that there is also a bug in your userspace program - somehow when it invokes ioctl(), it has SIGALRM blocked. Use sigprocmask() (or pthread_sigmask() if your program is multithreaded) to ensure that SIGALRM is not blocked when you are expecting it to be processed. (Even if your program does not block SIGALRM, it may inherit a blocked SIGALRM from another program which have started it, so the safest way is to unblock SIGALRM explicitly.) Using allow_signal() is needed only if you create a kernel thread and want that thread to handle signals. > But a quick question is when detecting signal_pending, I > return -ERESTARTSYS, but the user process receive the return value of > ioctl call is -1, shouldn't it be -4 for EINTR? This is handled by syscall wrappers in libc - when the kernel returns an error code from a syscall, the syscall wrapper function puts the code into the per-thread errno variable and returns -1 to its caller. Your userspace code should check errno for the actual error code when it receives -1 from ioctl(). And the ERESTARTSYS error is really special - it never actually gets returned to the userspace program; instead, the syscall return code in the kernel catches it and either restarts the syscall after the signal handler completes, or converts the error code to EINTR; one of these actions is selected by the SA_RESTART flag to sigaction(). pgpxaYpQbtPFb.pgp Description: PGP signature
Re: Sleeping thread not receive signal until it wakes up
On Fri, 9 Mar 2007 16:10:29 -0800 Luong Ngo wrote: Thanks Parav, adding singal_allow(SIGALRM) wakeup the blocking interruptible_sleep_on and checking the signal_pending would return true now. This means that there is also a bug in your userspace program - somehow when it invokes ioctl(), it has SIGALRM blocked. Use sigprocmask() (or pthread_sigmask() if your program is multithreaded) to ensure that SIGALRM is not blocked when you are expecting it to be processed. (Even if your program does not block SIGALRM, it may inherit a blocked SIGALRM from another program which have started it, so the safest way is to unblock SIGALRM explicitly.) Using allow_signal() is needed only if you create a kernel thread and want that thread to handle signals. But a quick question is when detecting signal_pending, I return -ERESTARTSYS, but the user process receive the return value of ioctl call is -1, shouldn't it be -4 for EINTR? This is handled by syscall wrappers in libc - when the kernel returns an error code from a syscall, the syscall wrapper function puts the code into the per-thread errno variable and returns -1 to its caller. Your userspace code should check errno for the actual error code when it receives -1 from ioctl(). And the ERESTARTSYS error is really special - it never actually gets returned to the userspace program; instead, the syscall return code in the kernel catches it and either restarts the syscall after the signal handler completes, or converts the error code to EINTR; one of these actions is selected by the SA_RESTART flag to sigaction(). pgpxaYpQbtPFb.pgp Description: PGP signature
Re: Sleeping thread not receive signal until it wakes up
On Thu, 8 Mar 2007 14:52:07 -0800 Luong Ngo wrote:
[...]
> static irqreturn board_isr(int irq, void *dev_id, struct pt_regs* regs)
> {
> spin_lock(>lock);
>if (dev->irqMask & (1 << irqBit)) {
> // Set the interrupt event mask
> dev->irqEvent |= (1 << irqBit);
>
> // Disable this irq, it will be reenabled after processed by board task
> disable_irq(irq);
I assume that your device does not support shared interrupts? If it
does (and a PCI device is required to support them), you cannot use
disable_irq() here (and you need to check a register in the device to
find out if it really did generate an IRQ)...
> // Wake up Board thread that calling IOCTL
> wake_up(&(dev->boardIRQWaitQueue));
> }
> spin_unlock(>lock);
>
> return IRQ_HANDLED;
...and return IRQ_NONE here if the IRQ is not from your device.
>
> }
>
> static int ats89_ioctl(struct inode *inode, struct file *file, u_int
> cmd, u_long arg)
> {
>
> switch(cmd){
>case GET_IRQ_CMD: {
> u32 regMask32;
>
>spin_lock_irq(dev->lock);
>while ((dev->irqMask & dev->irqEvent) == 0) {
> // Sleep until board interrupt happens
> spin_unlock_irq(dev->lock);
> interruptible_sleep_on(&(dev->boardIRQWaitQueue));
> if (uncond_wakeup) {
> /* don't go back to loop */
> break;
> }
> spin_lock_irq(dev->lock);
> }
>
> uncond_wakeup = 0;
>
> // Board interrupt happened
> regMask32 = dev->irqMask & dev->irqEvent;
> if(copy_to_user(&(((ATS89_IOCTL_S *)arg)->mask32),
> , sizeof(u32))) {
> spin_unlock_irq(dev->lock);
> return -EAGAIN;
> }
>
> // Clear the event mask
> dev->irqEvent = 0;
> spin_unlock_irq(dev->lock);
> }
> break;
>
>
>}
> }
And this code is full of bugs:
1) As you have been told already, interruptible_sleep_on() and
sleep_on() functions are broken and should not be used (they are
left in the kernel only to support some obsolete code). Either
use wait_event_interruptible() or work with wait queues directly
(prepare_to_wait(), finish_wait(), ...).
2) The code to handle pending signals is missing - you need to have
this after wait_event_interruptible():
if (signal_pending(current))
return -ERESTARTSYS;
(but be careful - you might need to clean up something before
returning).
This is what causes your problem - interruptible_sleep_on()
returns if a signal is pending, but your code does not check for
signals and therefore invokes interruptible_sleep_on() again; but
if a signal is pending, interruptible_sleep_on() returns
immediately, causing your driver to eat 100% CPU looping in kernel
mode until some device event finally happens.
3) If uncond_wakeup is set, you break out of the loop with dev->lock
unlocked; however, if dev->irqEvent gets set, you exit the loop
with dev->lock locked. The subsequent code always unlocks
dev->lock, so in the uncond_wakeup case you have double unlock.
4) You are doing copy_to_user() while holding a spinlock - this is
prohibited (as any other form of sleep inside a spinlock).
5) The return code for the copy_to_user() failure is wrong - it
should be -EFAULT (this is not a fatal bug, but an annoyance for
users of your driver, who might get such nonstandard error codes
while debugging their programs and wonder what is going on).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Sleeping thread not receive signal until it wakes up
On Thu, 8 Mar 2007 14:52:07 -0800 Luong Ngo wrote:
[...]
static irqreturn board_isr(int irq, void *dev_id, struct pt_regs* regs)
{
spin_lock(dev-lock);
if (dev-irqMask (1 irqBit)) {
// Set the interrupt event mask
dev-irqEvent |= (1 irqBit);
// Disable this irq, it will be reenabled after processed by board task
disable_irq(irq);
I assume that your device does not support shared interrupts? If it
does (and a PCI device is required to support them), you cannot use
disable_irq() here (and you need to check a register in the device to
find out if it really did generate an IRQ)...
// Wake up Board thread that calling IOCTL
wake_up((dev-boardIRQWaitQueue));
}
spin_unlock(dev-lock);
return IRQ_HANDLED;
...and return IRQ_NONE here if the IRQ is not from your device.
}
static int ats89_ioctl(struct inode *inode, struct file *file, u_int
cmd, u_long arg)
{
switch(cmd){
case GET_IRQ_CMD: {
u32 regMask32;
spin_lock_irq(dev-lock);
while ((dev-irqMask dev-irqEvent) == 0) {
// Sleep until board interrupt happens
spin_unlock_irq(dev-lock);
interruptible_sleep_on((dev-boardIRQWaitQueue));
if (uncond_wakeup) {
/* don't go back to loop */
break;
}
spin_lock_irq(dev-lock);
}
uncond_wakeup = 0;
// Board interrupt happened
regMask32 = dev-irqMask dev-irqEvent;
if(copy_to_userATS89_IOCTL_S *)arg)-mask32),
regMask32, sizeof(u32))) {
spin_unlock_irq(dev-lock);
return -EAGAIN;
}
// Clear the event mask
dev-irqEvent = 0;
spin_unlock_irq(dev-lock);
}
break;
}
}
And this code is full of bugs:
1) As you have been told already, interruptible_sleep_on() and
sleep_on() functions are broken and should not be used (they are
left in the kernel only to support some obsolete code). Either
use wait_event_interruptible() or work with wait queues directly
(prepare_to_wait(), finish_wait(), ...).
2) The code to handle pending signals is missing - you need to have
this after wait_event_interruptible():
if (signal_pending(current))
return -ERESTARTSYS;
(but be careful - you might need to clean up something before
returning).
This is what causes your problem - interruptible_sleep_on()
returns if a signal is pending, but your code does not check for
signals and therefore invokes interruptible_sleep_on() again; but
if a signal is pending, interruptible_sleep_on() returns
immediately, causing your driver to eat 100% CPU looping in kernel
mode until some device event finally happens.
3) If uncond_wakeup is set, you break out of the loop with dev-lock
unlocked; however, if dev-irqEvent gets set, you exit the loop
with dev-lock locked. The subsequent code always unlocks
dev-lock, so in the uncond_wakeup case you have double unlock.
4) You are doing copy_to_user() while holding a spinlock - this is
prohibited (as any other form of sleep inside a spinlock).
5) The return code for the copy_to_user() failure is wrong - it
should be -EFAULT (this is not a fatal bug, but an annoyance for
users of your driver, who might get such nonstandard error codes
while debugging their programs and wonder what is going on).
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Sleeping thread not receive signal until it wakes up
On Tue, 6 Mar 2007 21:31:37 -0800 Luong Ngo wrote: > I am having this problem. I have a process with 2 threads created. One > of the thread will keep calling IOCTL to get information from the > kernel and will be blocked if there is no new information. If there is > information retured, the thread will be checked to see if any error > happens and trigger an action. Since we have no way to know if the > error is gone (Hardware provides no signal), so what we do is when > trigger an action for the error, we will set an timer using alarm() > and register a SIGALRM handler in the thread by using sigaction. After > setting the alarm, the thread will loop back and call IOCTL, which > could cause it to be put to sleep. The problem is the SIGALRM handler > does not receive the SIGALRM while the thread is being blocked by > IOCTL. And if we generated some event so that the IOCTL is returned > with new information, the SIGALRM handler is invoked right away. > However, as I read the manual, which says a thread/process should be > waken up even when it sleeps if there is a signal delivered to it. Am > I right? Probably the ioctl handler of the driver you are calling does not use interruptible sleeps, therefore it cannot be interrupted by a signal. In this case you need to fix the driver to use interruptible sleeps and return -ERESTARTSYS when some signal is pending. pgp2knAYEyo8q.pgp Description: PGP signature
Re: Sleeping thread not receive signal until it wakes up
On Tue, 6 Mar 2007 21:31:37 -0800 Luong Ngo wrote: I am having this problem. I have a process with 2 threads created. One of the thread will keep calling IOCTL to get information from the kernel and will be blocked if there is no new information. If there is information retured, the thread will be checked to see if any error happens and trigger an action. Since we have no way to know if the error is gone (Hardware provides no signal), so what we do is when trigger an action for the error, we will set an timer using alarm() and register a SIGALRM handler in the thread by using sigaction. After setting the alarm, the thread will loop back and call IOCTL, which could cause it to be put to sleep. The problem is the SIGALRM handler does not receive the SIGALRM while the thread is being blocked by IOCTL. And if we generated some event so that the IOCTL is returned with new information, the SIGALRM handler is invoked right away. However, as I read the manual, which says a thread/process should be waken up even when it sleeps if there is a signal delivered to it. Am I right? Probably the ioctl handler of the driver you are calling does not use interruptible sleeps, therefore it cannot be interrupted by a signal. In this case you need to fix the driver to use interruptible sleeps and return -ERESTARTSYS when some signal is pending. pgp2knAYEyo8q.pgp Description: PGP signature
Re: via irq quirk breakage
On Tue, 30 Jan 2007 08:54:05 +0100 Jean Delvare wrote:
> You have an old VT82C686 south bridge, which was tagged as "special" by
> Alan. For this chip, Alan's code only allows devices 00:00.x to be quirked.
> As my code was merely a reimplementation of Alan's idea, it does the same.
> Your USB controllers are at 00:07.x, so I'm not surprised they weren't
> quirked.
>
> Alan, why were dev_lo and dev_hi both set to 0 for the VT82C868 in your
> implementation? Is it a typo, or...?
>
> Nick, I guess the following patch would work better for you? I've listed
> devices 00:07.x as quirkable for the VT82C686.
The VT82C686 is very different from other devices, because it is
a PCI chip, and its device number is determined by IDSEL wiring.
Google shows that several different assignments are in use:
00:01.0:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016642.html
(but that's PPC)
00:04.0: http://www.cs.helsinki.fi/linux/linux-kernel/2001-36/0083.html
00:05.0: http://lkml.org/lkml/2003/12/11/78
00:07.0: this example and lots of other links
00:14.0: http://forum.freespire.org/showthread.php?t=2998
> +static void quirk_via_bridge(struct pci_dev *dev)
> +{
> + /* See what bridge we have and find the device ranges */
> + switch (dev->device) {
> + case PCI_DEVICE_ID_VIA_82C686:
> + /* 82C686 is special */
> + via_vlink_dev_lo = 7;
> + via_vlink_dev_hi = 7;
So this should probably be:
/*
* 82C686 attaches to PCI and can have any device number, but
* all its subdevices are functions of that single device.
*/
via_vlink_dev_lo = via_vlink_dev_hi = PCI_SLOT(dev->devfn);
pgpSdks0TKG8G.pgp
Description: PGP signature
Re: via irq quirk breakage
On Tue, 30 Jan 2007 08:54:05 +0100 Jean Delvare wrote:
You have an old VT82C686 south bridge, which was tagged as special by
Alan. For this chip, Alan's code only allows devices 00:00.x to be quirked.
As my code was merely a reimplementation of Alan's idea, it does the same.
Your USB controllers are at 00:07.x, so I'm not surprised they weren't
quirked.
Alan, why were dev_lo and dev_hi both set to 0 for the VT82C868 in your
implementation? Is it a typo, or...?
Nick, I guess the following patch would work better for you? I've listed
devices 00:07.x as quirkable for the VT82C686.
The VT82C686 is very different from other devices, because it is
a PCI chip, and its device number is determined by IDSEL wiring.
Google shows that several different assignments are in use:
00:01.0:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016642.html
(but that's PPC)
00:04.0: http://www.cs.helsinki.fi/linux/linux-kernel/2001-36/0083.html
00:05.0: http://lkml.org/lkml/2003/12/11/78
00:07.0: this example and lots of other links
00:14.0: http://forum.freespire.org/showthread.php?t=2998
+static void quirk_via_bridge(struct pci_dev *dev)
+{
+ /* See what bridge we have and find the device ranges */
+ switch (dev-device) {
+ case PCI_DEVICE_ID_VIA_82C686:
+ /* 82C686 is special */
+ via_vlink_dev_lo = 7;
+ via_vlink_dev_hi = 7;
So this should probably be:
/*
* 82C686 attaches to PCI and can have any device number, but
* all its subdevices are functions of that single device.
*/
via_vlink_dev_lo = via_vlink_dev_hi = PCI_SLOT(dev-devfn);
pgpSdks0TKG8G.pgp
Description: PGP signature
Re: [linux-usb-devel] 2.6.20-rc6 pb_fnmode regression
On Mon, Jan 29, 2007 at 10:55:48AM +0100, Jiri Kosina wrote: > Changing module parameter values through sysfs is not a very nice idea, > because the change of the value is indeed silent - the driver is not > notified in any way, that the value has changed. So the driver should take > care of it by itself, which is not a nice thing. There is module_param_call() - used at least by drivers/md/md.c: static int get_ro(char *buffer, struct kernel_param *kp) ... static int set_ro(const char *val, struct kernel_param *kp) ... module_param_call(start_ro, set_ro, get_ro, NULL, S_IRUSR|S_IWUSR); pgpRrgp6hqJW1.pgp Description: PGP signature
Re: [linux-usb-devel] 2.6.20-rc6 pb_fnmode regression
On Mon, Jan 29, 2007 at 10:55:48AM +0100, Jiri Kosina wrote: Changing module parameter values through sysfs is not a very nice idea, because the change of the value is indeed silent - the driver is not notified in any way, that the value has changed. So the driver should take care of it by itself, which is not a nice thing. There is module_param_call() - used at least by drivers/md/md.c: static int get_ro(char *buffer, struct kernel_param *kp) ... static int set_ro(const char *val, struct kernel_param *kp) ... module_param_call(start_ro, set_ro, get_ro, NULL, S_IRUSR|S_IWUSR); pgpRrgp6hqJW1.pgp Description: PGP signature
NTFS deadlock on 2.6.18.6
Hello! I have encountered a deadlock in the NTFS filesystem on a 2.6.18.6-based kernel (x86_64, CONFIG_SMP set, but the machine has only one CPU (Athlon64 3200+), no PREEMPT). The kswapd0 and mklocatedb processes were apparently involved in the deadlock: kswapd0 D 810005dea304 0 163 7 164 162 (L-TLB) 81003fd6bcc8 0046 0020 021aaac0 000a 81003fe93820 81003fb157a0 027894893008 000308da 81003fe93a20 8100 810001641670 Call Trace: [] __mutex_lock_slowpath+0x5d/0x98 [] .text.lock.mutex+0x5/0x14 DWARF2 unwinder stuck at .text.lock.mutex+0x5/0x14 Leftover inexact backtrace: [] :ntfs:ntfs_put_inode+0x38/0x7a [] iput+0x3b/0x84 [] :ntfs:ntfs_clear_big_inode+0x107/0x121 [] clear_inode+0xc5/0xf6 [] dispose_list+0x56/0xf6 [] shrink_icache_memory+0x1d4/0x203 [] shrink_slab+0xdc/0x154 [] kswapd+0x320/0x424 [] autoremove_wake_function+0x0/0x2e [] keventd_create_kthread+0x0/0x61 [] kswapd+0x0/0x424 [] keventd_create_kthread+0x0/0x61 [] kthread+0xd4/0x107 [] child_rip+0xa/0x12 [] keventd_create_kthread+0x0/0x61 [] kthread+0x0/0x107 [] child_rip+0x0/0x12 mklocatedbD 810001e0d400 0 4586 4585 (NOTLB) 810021fd5c48 0082 000a 81002728f7e0 8048b3c0 02789a2349cf 25c4 81002728f9e0 8100 Call Trace: [] __wait_on_freeing_inode+0x82/0xa0 [] find_inode+0x3d/0x6c [] ifind+0x34/0x91 [] iget5_locked+0x6c/0x1a9 [] :ntfs:ntfs_attr_iget+0x5a/0x5eb [] :ntfs:ntfs_readdir+0x3f1/0xce1 [] vfs_readdir+0x77/0xa9 [] sys_getdents+0x75/0xbd [] system_call+0x7e/0x83 DWARF2 unwinder stuck at system_call+0x7e/0x83 Leftover inexact backtrace: There were some other processes stuck in the D state, but that seems to be just a result of the above deadlock: linuxdcpp D 810001e0d400 0 4912 4910 4914 4911 (NOTLB) 8100283d1bf0 0082 81000181cf38 8100283d1b98 0007 81002ca0c0c0 8048b3c0 0279f4c0a091 00026b39 81002ca0c2c0 Call Trace: [] __mutex_lock_slowpath+0x5d/0x98 [] .text.lock.mutex+0x5/0x14 DWARF2 unwinder stuck at .text.lock.mutex+0x5/0x14 Leftover inexact backtrace: [] shrink_icache_memory+0x40/0x203 [] shrink_slab+0xdc/0x154 [] try_to_free_pages+0x179/0x254 [] __alloc_pages+0x1a8/0x2a9 [] __do_page_cache_readahead+0x95/0x206 [] force_page_cache_readahead+0x5f/0x81 [] sys_madvise+0x2f7/0x3ec [] system_call+0x7e/0x83 (apparently waiting for kswapd0 to release iprune_mutex; this path does not seem to have any FS-related locking, but sys_madvise() has taken ->mm->mmap_sem for write.) Other linuxdcpp threads and several ps processes then were stuck waiting on its ->mm->mmap_sem taken by sys_madvise() above. So the deadlock seems to be between kswapd0 and mklocatedb. Note that vfs_readdir() invoked by mklocatedb has taken i_mutex for the directory, and kswapd0 is waiting on some i_mutex... I suspect the following scenario: 1) kswapd0 runs shrink_icache_memory() (and prune_icache(), which apparently was inlined there); prune_icache() notices that some attribute inode (probably the index bitmap) for the directory is unused, marks that attribute inode with I_FREEING and subsequently invokes dispose_list() to free marked inodes. 2) mklocatedb invokes sys_readdir() on the directory, which grabs i_mutex of the directory and proceeds to call the filesystem readdir method - ntfs_readdir(), which then finds that it needs the bitmap inode and invokes ntfs_attr_iget() to find it. ntfs_attr_iget() proceeds down to find_inode(), which notices that the inode has I_FREEING set and goes to __wait_on_freeing_inode(). 3) kswapd0 proceeds to call clear_inode() on the attribute inode. ntfs_clear_big_inode() calls iput(VFS_I(ni->ext.base_ntfs_ino)) to put the base inode (the directory). 4) iput() calls ntfs_put_inode() for the directory. At this point the directory by chance has exactly two references accounted for in ->i_count - one from the file descriptor open by mklocatedb, another from the attribute inode (which that iput() is dropping now), so ntfs_put_inode() goes to the path which releases ni->itype.index.bmp_ino - but it needs to grab ->i_mutex for the directory, and that mutex is held by mklocatedb. 5) Now kswapd0 is waiting for mklocatedb to release ->i_mutex for the directory, and mklocatedb is waiting for kswapd0 to finish freeing of the attribute inode - deadlock. Seems that grabbing i_mutex in ntfs_put_inode() is not safe after all (and lockdep cannot see this deadlock possibility, because one of waits is __wait_on_freeing_inode - not a standard locking primitive). -- Sergey Vlasov signature.asc Description: Digital signature
NTFS deadlock on 2.6.18.6
to the path which releases ni-itype.index.bmp_ino - but it needs to grab -i_mutex for the directory, and that mutex is held by mklocatedb. 5) Now kswapd0 is waiting for mklocatedb to release -i_mutex for the directory, and mklocatedb is waiting for kswapd0 to finish freeing of the attribute inode - deadlock. Seems that grabbing i_mutex in ntfs_put_inode() is not safe after all (and lockdep cannot see this deadlock possibility, because one of waits is __wait_on_freeing_inode - not a standard locking primitive). -- Sergey Vlasov signature.asc Description: Digital signature
Re: ip_tables init broken
On Sat, 30 Dec 2006 18:14:35 +0100 (MET) Jan Engelhardt wrote: > when the ip_tables module is loaded automatically when inserting the > first rule, something gets screwed up, as -L -v -n shows: > > > 17:39 ichi:~ # lsmod | grep ip_tables > 17:39 ichi:~ # iptables -t mangle -A FORWARD -i eth1 -j MARK --set-mark 161 > 17:39 ichi:~ # iptables -t mangle -A FORWARD -i eth1 -j MARK --set-mark 161 > 17:39 ichi:~ # iptables -t mangle -L -v -n | grep eth1 > p b targ pr opt in out src dst > 0 0 MARK 0 -- eth1 * 0.0.0.0/0 0.0.0.0/0 0xa1 > 0 0 MARK 0 -- eth1 * 0.0.0.0/0 0.0.0.0/0 MARK set 0xa1 > > Everything is fine if ip_tables was loaded before. > > This box runs 2.6.18.5. Can anyone confirm this bug? Looks like this problem was fixed between iptables releases 1.3.5 and 1.3.7 (the old buggy version was trying to detect whether the kernel supports the newer MARK target version before loading the ip_tables module, therefore the check was giving bogus results). pgpNGUDVbz5Dv.pgp Description: PGP signature
Re: ip_tables init broken
On Sat, 30 Dec 2006 18:14:35 +0100 (MET) Jan Engelhardt wrote: when the ip_tables module is loaded automatically when inserting the first rule, something gets screwed up, as -L -v -n shows: 17:39 ichi:~ # lsmod | grep ip_tables 17:39 ichi:~ # iptables -t mangle -A FORWARD -i eth1 -j MARK --set-mark 161 17:39 ichi:~ # iptables -t mangle -A FORWARD -i eth1 -j MARK --set-mark 161 17:39 ichi:~ # iptables -t mangle -L -v -n | grep eth1 p b targ pr opt in out src dst 0 0 MARK 0 -- eth1 * 0.0.0.0/0 0.0.0.0/0 0xa1 0 0 MARK 0 -- eth1 * 0.0.0.0/0 0.0.0.0/0 MARK set 0xa1 Everything is fine if ip_tables was loaded before. This box runs 2.6.18.5. Can anyone confirm this bug? Looks like this problem was fixed between iptables releases 1.3.5 and 1.3.7 (the old buggy version was trying to detect whether the kernel supports the newer MARK target version before loading the ip_tables module, therefore the check was giving bogus results). pgpNGUDVbz5Dv.pgp Description: PGP signature
Re: RFC: PCI quirks update for 2.6.16
On Thu, Dec 07, 2006 at 06:27:40PM +0100, Bauke Jan Douma wrote: > Sergey Vlasov wrote on 07-12-06 14:53: > >On Thu, 7 Dec 2006 14:24:30 +0100 Adrian Bunk wrote: > > > >>While checking how to fix the VIA quirk regressions for several users > >>introduced into -stable in 2.6.16.17, I started looking through all > >>drivers/pci/quirks.c updates up to both -stable and 2.6.19. > >> > [snip] > >> > >>Bauke Jan Douma (1): > >> PCI: quirk for asus a8v and a8v delux motherboards > > > >This quirk will cause breakage for people who used an external PCI > >soundcard with these boards - the builtin sound chip which was > >invisible before may become the first audio device. > > I'm afraid I don't understand the problem described here, when > ALSA can assign any arbitrary index number of a user's choice > to cards that are detected. The problem is that -stable patches should not introduce regression. And if this patch would be included in the next -stable release, people who upgrade to this release may get unexpected changes of sound cards indexes. This may be OK for a new 2.6.x release, but not for a new 2.6.16.y. > Indeed, on my system (an A8V Deluxe motherboard, with this > quirk active), my first soundcard (given index=0) is an offboard > Creative SB Live, and the onboard card I have assigned index=1. Yes, now I have exactly the same setup. But before this patch I did not have any index=N assignments in my configuration; after the patch I needed to add them to get my system working as before. > I for one need this quirk to get both soundcards at all (which > I need) -- no matter what indexing order. I don't question the need for this patch in mainline; however, it does not seem to be suitable for -stable. > >It also enables the MC97 device, which does not really work (there is > >no MC97 codec attached to the controller at least on A8V Deluxe; I'm > >not sure if there is some other variant of this board which has MC97, > >but it seems unlikely). > > This one can be disabled separate of the AC97 -- let me get back > on that. I, for one (however much that is), don't need it either. Currently I get: VIA 82xx Modem: probe of :00:11.6 failed with error -13 on every boot (and snd_via82xx_modem module in memory). Not a grave bug, but not a good thing either (and another reason for not adding this patch to 2.6.16.y). signature.asc Description: Digital signature
Re: RFC: PCI quirks update for 2.6.16
On Thu, 7 Dec 2006 14:24:30 +0100 Adrian Bunk wrote: > While checking how to fix the VIA quirk regressions for several users > introduced into -stable in 2.6.16.17, I started looking through all > drivers/pci/quirks.c updates up to both -stable and 2.6.19. > > Below is the selection the seemed good and safe. > > Any comments on whether it's really good or whether I should change > anything? > > TIA > Adrian > > > Bauke Jan Douma (1): > PCI: quirk for asus a8v and a8v delux motherboards This quirk will cause breakage for people who used an external PCI soundcard with these boards - the builtin sound chip which was invisible before may become the first audio device. It also enables the MC97 device, which does not really work (there is no MC97 codec attached to the controller at least on A8V Deluxe; I'm not sure if there is some other variant of this board which has MC97, but it seems unlikely). [...] pgpyaXzriv0an.pgp Description: PGP signature
Re: RFC: PCI quirks update for 2.6.16
On Thu, 7 Dec 2006 14:24:30 +0100 Adrian Bunk wrote: While checking how to fix the VIA quirk regressions for several users introduced into -stable in 2.6.16.17, I started looking through all drivers/pci/quirks.c updates up to both -stable and 2.6.19. Below is the selection the seemed good and safe. Any comments on whether it's really good or whether I should change anything? TIA Adrian Bauke Jan Douma (1): PCI: quirk for asus a8v and a8v delux motherboards This quirk will cause breakage for people who used an external PCI soundcard with these boards - the builtin sound chip which was invisible before may become the first audio device. It also enables the MC97 device, which does not really work (there is no MC97 codec attached to the controller at least on A8V Deluxe; I'm not sure if there is some other variant of this board which has MC97, but it seems unlikely). [...] pgpyaXzriv0an.pgp Description: PGP signature
Re: RFC: PCI quirks update for 2.6.16
On Thu, Dec 07, 2006 at 06:27:40PM +0100, Bauke Jan Douma wrote: Sergey Vlasov wrote on 07-12-06 14:53: On Thu, 7 Dec 2006 14:24:30 +0100 Adrian Bunk wrote: While checking how to fix the VIA quirk regressions for several users introduced into -stable in 2.6.16.17, I started looking through all drivers/pci/quirks.c updates up to both -stable and 2.6.19. [snip] Bauke Jan Douma (1): PCI: quirk for asus a8v and a8v delux motherboards This quirk will cause breakage for people who used an external PCI soundcard with these boards - the builtin sound chip which was invisible before may become the first audio device. I'm afraid I don't understand the problem described here, when ALSA can assign any arbitrary index number of a user's choice to cards that are detected. The problem is that -stable patches should not introduce regression. And if this patch would be included in the next -stable release, people who upgrade to this release may get unexpected changes of sound cards indexes. This may be OK for a new 2.6.x release, but not for a new 2.6.16.y. Indeed, on my system (an A8V Deluxe motherboard, with this quirk active), my first soundcard (given index=0) is an offboard Creative SB Live, and the onboard card I have assigned index=1. Yes, now I have exactly the same setup. But before this patch I did not have any index=N assignments in my configuration; after the patch I needed to add them to get my system working as before. I for one need this quirk to get both soundcards at all (which I need) -- no matter what indexing order. I don't question the need for this patch in mainline; however, it does not seem to be suitable for -stable. It also enables the MC97 device, which does not really work (there is no MC97 codec attached to the controller at least on A8V Deluxe; I'm not sure if there is some other variant of this board which has MC97, but it seems unlikely). This one can be disabled separate of the AC97 -- let me get back on that. I, for one (however much that is), don't need it either. Currently I get: VIA 82xx Modem: probe of :00:11.6 failed with error -13 on every boot (and snd_via82xx_modem module in memory). Not a grave bug, but not a good thing either (and another reason for not adding this patch to 2.6.16.y). signature.asc Description: Digital signature
Re: [RFC] Include ACPI DSDT from INITRD patch into mainline
On Sat, 02 Dec 2006 11:30:32 +0100 Arjan van de Ven wrote:
> On Fri, 2006-12-01 at 13:36 -0500, Ben Collins wrote:
> > I'd be willing to bet that most distros have this patch in their kernel.
> > One of those things we can't really live without.
> >
> > What I haven't understood is why it isn't included in the mainline
> > kernel yet.
>
> it's not that hard ;)
>
> replacing the DSDT code *while it's live* is just a bad idea.
But the suggested patch does not do this.
> The kernel already has a facility to override the DSDT, but that one
> does it *from the start*. Sounds like that one should be used or
> maybe enhanced a little to make it more distro friendly if something
> is lacking.
The patch replaces the DSDT with the binary from initramfs in the same
acpi_os_table_override() function as the currently available
CONFIG_ACPI_CUSTOM_DSDT does:
@@ -226,13 +291,20 @@ acpi_os_table_override(struct acpi_table
if (!existing_table || !new_table)
return AE_BAD_PARAMETER;
+ *new_table = NULL;
+
#ifdef CONFIG_ACPI_CUSTOM_DSDT
if (strncmp(existing_table->signature, "DSDT", 4) == 0)
*new_table = (struct acpi_table_header *)AmlCode;
- else
- *new_table = NULL;
-#else
- *new_table = NULL;
+#endif
+#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
+ if (strncmp(existing_table->signature, "DSDT", 4) == 0) {
+ struct acpi_table_header* initrd_table =
acpi_find_dsdt_initrd();
+ if (initrd_table) {
+ *new_table = initrd_table;
+ acpi_must_unregister_table = TRUE;
+ }
+ }
#endif
return AE_OK;
}
However, this patch slightly changes initialization order of some
kernel parts:
- The call to populate_rootfs() is moved before calls to
smp_prepare_cpus(max_cpus), do_pre_smp_initcalls(), smp_init(),
sched_init_smp() and cpuset_init_smp().
- The call to acpi_early_init() is moved from start_kernel() (where
it is done just before rest_init()) to rest_init(), where it is now
preceded by lock_kernel(), set_cpus_allowed(current, CPU_MASK_ALL),
child_reaper = current and the moved populate_rootfs().
Not sure if this reordering is safe in theory, but it works for many
users of the patch.
pgpYK4YlI1xHu.pgp
Description: PGP signature
Re: [RFC] Include ACPI DSDT from INITRD patch into mainline
On Sat, 02 Dec 2006 11:30:32 +0100 Arjan van de Ven wrote:
On Fri, 2006-12-01 at 13:36 -0500, Ben Collins wrote:
I'd be willing to bet that most distros have this patch in their kernel.
One of those things we can't really live without.
What I haven't understood is why it isn't included in the mainline
kernel yet.
it's not that hard ;)
replacing the DSDT code *while it's live* is just a bad idea.
But the suggested patch does not do this.
The kernel already has a facility to override the DSDT, but that one
does it *from the start*. Sounds like that one should be used or
maybe enhanced a little to make it more distro friendly if something
is lacking.
The patch replaces the DSDT with the binary from initramfs in the same
acpi_os_table_override() function as the currently available
CONFIG_ACPI_CUSTOM_DSDT does:
@@ -226,13 +291,20 @@ acpi_os_table_override(struct acpi_table
if (!existing_table || !new_table)
return AE_BAD_PARAMETER;
+ *new_table = NULL;
+
#ifdef CONFIG_ACPI_CUSTOM_DSDT
if (strncmp(existing_table-signature, DSDT, 4) == 0)
*new_table = (struct acpi_table_header *)AmlCode;
- else
- *new_table = NULL;
-#else
- *new_table = NULL;
+#endif
+#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
+ if (strncmp(existing_table-signature, DSDT, 4) == 0) {
+ struct acpi_table_header* initrd_table =
acpi_find_dsdt_initrd();
+ if (initrd_table) {
+ *new_table = initrd_table;
+ acpi_must_unregister_table = TRUE;
+ }
+ }
#endif
return AE_OK;
}
However, this patch slightly changes initialization order of some
kernel parts:
- The call to populate_rootfs() is moved before calls to
smp_prepare_cpus(max_cpus), do_pre_smp_initcalls(), smp_init(),
sched_init_smp() and cpuset_init_smp().
- The call to acpi_early_init() is moved from start_kernel() (where
it is done just before rest_init()) to rest_init(), where it is now
preceded by lock_kernel(), set_cpus_allowed(current, CPU_MASK_ALL),
child_reaper = current and the moved populate_rootfs().
Not sure if this reordering is safe in theory, but it works for many
users of the patch.
pgpYK4YlI1xHu.pgp
Description: PGP signature
Re: [2.4.31] - USB device numbering in /proc/bus/usb
On Tue, 23 Aug 2005 15:14:38 +0200 Paul Rolland wrote: > I've just rebooted a machine, and the eagle ADSL modem I was using, > presented as /proc/bus/usb/002/005 in now presented as > /proc/bus/usb/002/003 (same bus, but device ID changed from 5 to 3). > > Is this an expected behavior, when running a 2.4.31 kernel ? Yes. Addresses for USB devices are assigned dynamically. If you disconnect the modem from USB and connect it again, its address will change. > I would have been expecting some more stability in the numbering across > reboot, the same way IDE disks numbers are stable. Use some other identifier which is stable - e.g., serial number of the USB device (unfortunately, many devices don't have it). pgpWDerdwRRlJ.pgp Description: PGP signature
Re: [2.4.31] - USB device numbering in /proc/bus/usb
On Tue, 23 Aug 2005 15:14:38 +0200 Paul Rolland wrote: I've just rebooted a machine, and the eagle ADSL modem I was using, presented as /proc/bus/usb/002/005 in now presented as /proc/bus/usb/002/003 (same bus, but device ID changed from 5 to 3). Is this an expected behavior, when running a 2.4.31 kernel ? Yes. Addresses for USB devices are assigned dynamically. If you disconnect the modem from USB and connect it again, its address will change. I would have been expecting some more stability in the numbering across reboot, the same way IDE disks numbers are stable. Use some other identifier which is stable - e.g., serial number of the USB device (unfortunately, many devices don't have it). pgpWDerdwRRlJ.pgp Description: PGP signature
Re: VIA VT6410 IDE support for 2.6.11-rc3/via82cxxx
(sending this again, because did not see the message in linux-kernel for 2 days and suspect that it has been lost; sorry if someone receives a duplicate) On Fri, Feb 11, 2005 at 07:33:59PM +0100, Bartlomiej Zolnierkiewicz wrote: > On Mon, 07 Feb 2005 12:27:47 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote: > > Mathias Kretschmer wrote: > > > Mathias Kretschmer wrote: > > >> 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. > > > > > > as above, but for 2.6.11-rc3 > > > > Bart, got this one? > > I applied it (after whitespace cleanup) to ide-dev-2.6. Sorry to bother you, but what's the status of this patch? Since that time, 2.6.11 and 2.6.12 kernels were released, now 2.6.13 is almost ready, and the VT6410 support does not seem to appear even in -mm. Has the patch been lost, or is it broken? pgphCmKBdyGwj.pgp Description: PGP signature
Re: VIA VT6410 IDE support for 2.6.11-rc3/via82cxxx
(sending this again, because did not see the message in linux-kernel for 2 days and suspect that it has been lost; sorry if someone receives a duplicate) On Fri, Feb 11, 2005 at 07:33:59PM +0100, Bartlomiej Zolnierkiewicz wrote: On Mon, 07 Feb 2005 12:27:47 -0500, Jeff Garzik [EMAIL PROTECTED] wrote: Mathias Kretschmer wrote: Mathias Kretschmer wrote: 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. as above, but for 2.6.11-rc3 Bart, got this one? I applied it (after whitespace cleanup) to ide-dev-2.6. Sorry to bother you, but what's the status of this patch? Since that time, 2.6.11 and 2.6.12 kernels were released, now 2.6.13 is almost ready, and the VT6410 support does not seem to appear even in -mm. Has the patch been lost, or is it broken? pgphCmKBdyGwj.pgp Description: PGP signature
Re: VIA VT6410 IDE support for 2.6.11-rc3/via82cxxx
On Fri, Feb 11, 2005 at 07:33:59PM +0100, Bartlomiej Zolnierkiewicz wrote: > On Mon, 07 Feb 2005 12:27:47 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote: > > Mathias Kretschmer wrote: > > > Mathias Kretschmer wrote: > > >> 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. > > > > > > as above, but for 2.6.11-rc3 > > > > Bart, got this one? > > I applied it (after whitespace cleanup) to ide-dev-2.6. Sorry to bother you, but what's the status of this patch? Since that time, 2.6.11 and 2.6.12 kernels were released, now 2.6.13 is almost ready, and the VT6410 support does not seem to appear even in -mm. Has the patch been lost, or is it broken? pgpxyCFjspz7x.pgp Description: PGP signature
Re: VIA VT6410 IDE support for 2.6.11-rc3/via82cxxx
On Fri, Feb 11, 2005 at 07:33:59PM +0100, Bartlomiej Zolnierkiewicz wrote: On Mon, 07 Feb 2005 12:27:47 -0500, Jeff Garzik [EMAIL PROTECTED] wrote: Mathias Kretschmer wrote: Mathias Kretschmer wrote: 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. as above, but for 2.6.11-rc3 Bart, got this one? I applied it (after whitespace cleanup) to ide-dev-2.6. Sorry to bother you, but what's the status of this patch? Since that time, 2.6.11 and 2.6.12 kernels were released, now 2.6.13 is almost ready, and the VT6410 support does not seem to appear even in -mm. Has the patch been lost, or is it broken? pgpxyCFjspz7x.pgp Description: PGP signature
Re: [git patches] 2.4.x SATA update
On Thu, 28 Jul 2005 15:46:32 -0400 Jeff Garzik wrote: > +/** > + * ata_sg_init_one - Associate command with memory buffer > + * @qc: Command to be associated > + * @buf: Memory buffer > + * @buflen: Length of memory buffer, in bytes. > + * > + * Initialize the data-related elements of queued_cmd @qc > + * to point to a single memory buffer, @buf of byte length @buflen. > + * > + * LOCKING: > + * spin_lock_irqsave(host_set lock) > + */ > + > + > + > +/** > + * ata_sg_init_one - Prepare a one-entry scatter-gather list. > + * @qc: Queued command > + * @buf: transfer buffer > + * @buflen: length of buf > + * > + * Builds a single-entry scatter-gather list to initiate a > + * transfer utilizing the specified buffer. > + * > + * LOCKING: > + */ Which one of the above duplicated comments for ata_sg_init_one is correct? > +/** > + * ata_sg_init - Associate command with scatter-gather table. > + * @qc: Command to be associated > + * @sg: Scatter-gather table. > + * @n_elem: Number of elements in s/g table. > + * > + * Initialize the data-related elements of queued_cmd @qc > + * to point to a scatter-gather table @sg, containing @n_elem > + * elements. > + * > + * LOCKING: > + * spin_lock_irqsave(host_set lock) > + */ > + > + > +/** > + * ata_sg_init - Assign a scatter gather list to a queued command > + * @qc: Queued command > + * @sg: Scatter-gather list > + * @n_elem: length of sg list > + * > + * Attaches a scatter-gather list to a queued command. > + * > + * LOCKING: > + */ More duplicated comments. pgpEYVL9vwpVi.pgp Description: PGP signature
Re: [git patches] 2.4.x SATA update
On Thu, 28 Jul 2005 15:46:32 -0400 Jeff Garzik wrote: +/** + * ata_sg_init_one - Associate command with memory buffer + * @qc: Command to be associated + * @buf: Memory buffer + * @buflen: Length of memory buffer, in bytes. + * + * Initialize the data-related elements of queued_cmd @qc + * to point to a single memory buffer, @buf of byte length @buflen. + * + * LOCKING: + * spin_lock_irqsave(host_set lock) + */ + + + +/** + * ata_sg_init_one - Prepare a one-entry scatter-gather list. + * @qc: Queued command + * @buf: transfer buffer + * @buflen: length of buf + * + * Builds a single-entry scatter-gather list to initiate a + * transfer utilizing the specified buffer. + * + * LOCKING: + */ Which one of the above duplicated comments for ata_sg_init_one is correct? +/** + * ata_sg_init - Associate command with scatter-gather table. + * @qc: Command to be associated + * @sg: Scatter-gather table. + * @n_elem: Number of elements in s/g table. + * + * Initialize the data-related elements of queued_cmd @qc + * to point to a scatter-gather table @sg, containing @n_elem + * elements. + * + * LOCKING: + * spin_lock_irqsave(host_set lock) + */ + + +/** + * ata_sg_init - Assign a scatter gather list to a queued command + * @qc: Queued command + * @sg: Scatter-gather list + * @n_elem: length of sg list + * + * Attaches a scatter-gather list to a queued command. + * + * LOCKING: + */ More duplicated comments. pgpEYVL9vwpVi.pgp Description: PGP signature
Re: Fw: Oops in hidinput_hid_event
On Tue, 19 Jul 2005 09:30:58 -0400 Vojtech Pavlik wrote:
> On Mon, Jul 18, 2005 at 02:16:37PM -0700, Pete Zaitcev wrote:
>
> > I think this patch is rather obvious, so maybe I should ask Andrew to
> > apply it to -mm for now, to get some testing. Would that help to verify
> > it for acceptance?
>
> Your patch is perfectly OK, my NULL check was indeed completely wrong.
>
> I need to find out how there can be an input event happening without its
> associated input structure, though, since the oops actually reveals a
> deeper problem.
hidinput_connect() does:
for (k = HID_INPUT_REPORT; k <= HID_OUTPUT_REPORT; k++)
... loop which calls hidinput_configure_usage(),
which initializes report->hidinput pointers ...
So ->hidinput is getting set only for fields of input and output
reports, but the device may also support feature reports, and for their
fields ->hidinput will remain NULL. When such report is requested with
hid_submit_report(hid, report, USB_DIR_IN), the completed urb will be
handled by hid_ctrl(), which will call hid_input_report() for it; this
corresponds to the traceback in oops.
BTW, the driver requests all feature reports during initialization (in
hid_init_reports()), but it does not oops there, because
hidinput_connect() is called only later, and therefore HID_CLAIMED_INPUT
is not yet set.
However, I still don't understand where hid_submit_report() gets called
for a feature report in the reported case (hidinput_input_event() can
submit only output reports, and a call from hiddev is unlikely to be
triggered by a NumLock press).
> So that's why I didn't apply the patch yet.
>
> > Begin forwarded message:
> >
> > Date: Tue, 28 Jun 2005 15:00:23 -0700
> > From: Pete Zaitcev <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED], linux-usb-devel@lists.sourceforge.net
> > Subject: Oops in hidinput_hid_event
> >
> > Hi, Vojtech:
> >
> > Someone reported a bug in Fedora, which runs a largely unmodified upstream
> > kernel in this area. Whenever the user hits a key which switches LED,
> > the system oopses. Here's a trace:
> >
> > Unable to handle kernel NULL pointer dereference at virtual address 00c8
> > EFLAGS: 00010006 (2.6.11-1.1369_FC4smp)
> > EIP is at hidinput_hid_event+0x2d/0x292
> >
> > Call Trace:
> > [] hid_process_event+0x57/0x5f
> > [] hid_input_field+0x2a2/0x2ac
> > [] hid_input_report+0x9e/0xb8
> > [] hid_ctrl+0x14c/0x151
> > [] uhci_destroy_urb_priv+0xb5/0x10a [uhci_hcd]
> > [] usb_hcd_giveback_urb+0x24/0x67
> > [] uhci_finish_urb+0x2d/0x38 [uhci_hcd]
> > [] uhci_finish_completion+0x44/0x56 [uhci_hcd]
> > [] uhci_scan_schedule+0xaa/0x13a [uhci_hcd]
> > [] i8042_interrupt+0x121/0x234
> > [] uhci_irq+0x47/0x10d [uhci_hcd]
> >
> > Full trace at
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160709
> >
> > Any ideas?
> >
> > By the way, it seems that I see a bug in hidinput_hid_event.
> > The check for NULL can never work, becaue >input
> > is nonzero at all times. How about this?
> >
> > --- linux-2.6.12/drivers/usb/input/hid-input.c 2005-06-21
> > 12:58:47.0 -0700
> > +++ linux-2.6.12-lem/drivers/usb/input/hid-input.c 2005-06-28
> > 14:57:22.0 -0700
> > @@ -397,11 +397,12 @@
> >
> > void hidinput_hid_event(struct hid_device *hid, struct hid_field *field,
> > struct hid_usage *usage, __s32 value, struct pt_regs *regs)
> > {
> > - struct input_dev *input = >hidinput->input;
> > + struct input_dev *input;
> > int *quirks = >quirks;
> >
> > - if (!input)
> > + if (!field->hidinput)
> > return;
> > + input = >hidinput->input;
> >
> > input_regs(input, regs);
> >
> >
> > -- Pete
> >
>
> --
> Vojtech Pavlik
> SuSE Labs, SuSE CR
pgpnei1ldC3Fg.pgp
Description: PGP signature
Re: Fw: Oops in hidinput_hid_event
On Tue, 19 Jul 2005 09:30:58 -0400 Vojtech Pavlik wrote:
On Mon, Jul 18, 2005 at 02:16:37PM -0700, Pete Zaitcev wrote:
I think this patch is rather obvious, so maybe I should ask Andrew to
apply it to -mm for now, to get some testing. Would that help to verify
it for acceptance?
Your patch is perfectly OK, my NULL check was indeed completely wrong.
I need to find out how there can be an input event happening without its
associated input structure, though, since the oops actually reveals a
deeper problem.
hidinput_connect() does:
for (k = HID_INPUT_REPORT; k = HID_OUTPUT_REPORT; k++)
... loop which calls hidinput_configure_usage(),
which initializes report-hidinput pointers ...
So -hidinput is getting set only for fields of input and output
reports, but the device may also support feature reports, and for their
fields -hidinput will remain NULL. When such report is requested with
hid_submit_report(hid, report, USB_DIR_IN), the completed urb will be
handled by hid_ctrl(), which will call hid_input_report() for it; this
corresponds to the traceback in oops.
BTW, the driver requests all feature reports during initialization (in
hid_init_reports()), but it does not oops there, because
hidinput_connect() is called only later, and therefore HID_CLAIMED_INPUT
is not yet set.
However, I still don't understand where hid_submit_report() gets called
for a feature report in the reported case (hidinput_input_event() can
submit only output reports, and a call from hiddev is unlikely to be
triggered by a NumLock press).
So that's why I didn't apply the patch yet.
Begin forwarded message:
Date: Tue, 28 Jun 2005 15:00:23 -0700
From: Pete Zaitcev [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], linux-usb-devel@lists.sourceforge.net
Subject: Oops in hidinput_hid_event
Hi, Vojtech:
Someone reported a bug in Fedora, which runs a largely unmodified upstream
kernel in this area. Whenever the user hits a key which switches LED,
the system oopses. Here's a trace:
Unable to handle kernel NULL pointer dereference at virtual address 00c8
EFLAGS: 00010006 (2.6.11-1.1369_FC4smp)
EIP is at hidinput_hid_event+0x2d/0x292
Call Trace:
[c02872e0] hid_process_event+0x57/0x5f
[c028758a] hid_input_field+0x2a2/0x2ac
[c0287632] hid_input_report+0x9e/0xb8
[c0287f62] hid_ctrl+0x14c/0x151
[e0a21060] uhci_destroy_urb_priv+0xb5/0x10a [uhci_hcd]
[c027dab5] usb_hcd_giveback_urb+0x24/0x67
[e0a22360] uhci_finish_urb+0x2d/0x38 [uhci_hcd]
[e0a223af] uhci_finish_completion+0x44/0x56 [uhci_hcd]
[e0a224a2] uhci_scan_schedule+0xaa/0x13a [uhci_hcd]
[c023413d] i8042_interrupt+0x121/0x234
[e0a226d0] uhci_irq+0x47/0x10d [uhci_hcd]
Full trace at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160709
Any ideas?
By the way, it seems that I see a bug in hidinput_hid_event.
The check for NULL can never work, becaue hidinput-input
is nonzero at all times. How about this?
--- linux-2.6.12/drivers/usb/input/hid-input.c 2005-06-21
12:58:47.0 -0700
+++ linux-2.6.12-lem/drivers/usb/input/hid-input.c 2005-06-28
14:57:22.0 -0700
@@ -397,11 +397,12 @@
void hidinput_hid_event(struct hid_device *hid, struct hid_field *field,
struct hid_usage *usage, __s32 value, struct pt_regs *regs)
{
- struct input_dev *input = field-hidinput-input;
+ struct input_dev *input;
int *quirks = hid-quirks;
- if (!input)
+ if (!field-hidinput)
return;
+ input = field-hidinput-input;
input_regs(input, regs);
-- Pete
--
Vojtech Pavlik
SuSE Labs, SuSE CR
pgpnei1ldC3Fg.pgp
Description: PGP signature
Re: Synaptics and TrackPoint problems in 2.6.12
On Wed, Jul 20, 2005 at 10:05:13AM -0500, Dmitry Torokhov wrote: > On 7/20/05, Sergey Vlasov <[EMAIL PROTECTED]> wrote: > > Another option is to change the > > PSMOUSE_TRACKPOINT value so that it is less than PSMOUSE_GENPS, > > No, protocol numbers should not be changed as userspace drivers/setups > check them and rely on them being stable. Found that now: psmouse->dev.id.product = psmouse->type; So the type is visible through the input device interface. Probably this should be mentioned in a comment near "enum psmouse_type" - its definition in drivers/input/mouse/psmouse.h looks just like some driver-internal enum. > > In theory, someone could attach a device which uses 6-byte packets to > > the Synaptics pass-thru port; I'm not sure what would happen in this > > case, but with Synaptics confugured for 3-byte packets (as the patch > > below will do) this configuration even has a chance of working. > > I don't think it can support more than 4 byte packets. bytes 0 and 3 > are protocol markers and can't be readily used for transmitting other > protocols data. At least the Synaptics protocol description mentions that its 6-byte protocol was designed to look like two 3-byte PS/2 mouse packets, so that it would work even if the controller looks at those markers; other such protocols are likely to have the same property for the same reason. Now, if the Synaptics touchpad would be able to accept a 6-byte packet from the pass-thru port as two 3-byte packets... pgpUDXsWiQVCK.pgp Description: PGP signature
Re: Synaptics and TrackPoint problems in 2.6.12
On Tue, 19 Jul 2005 23:40:18 -0400 Stephen Evanchik wrote:
> I have been receiving a lot of complaints that TrackPoints on
> Synaptics pass-thru ports stopped working with 2.6.12. I retested
> 2.6.9 and 2.6.11-rc3 successfully, I believe 2.6.11.7 may also work
> but that is unconfirmed at this point.
>
> The behavior is always the same .. after sending the read secondary ID
> command, the TrackPoint seems to be disabled from that point forward.
>
> Any ideas?
Looks like this problem was introduced by the change from PSMOUSE_PS2 to
PSMOUSE_TRACKPOINT in the TrackPoint support patch. The Synaptics
driver needs to know whether the device on the pass-thru port is using
3-byte or 4-byte packets; however, instead of checking child->pktsize,
it checks child->type >= PSMOUSE_GENPS - and this check is now giving a
wrong result. Therefore the Synaptics driver configures the pass-thru
port for 4-byte packets, and all 3-byte packets from TrackPoint seem to
be thrown away.
The patch below is reported to fix the problem - now the 4-byte mode is
used only if child->pktsize == 4. Another option is to change the
PSMOUSE_TRACKPOINT value so that it is less than PSMOUSE_GENPS, however,
I think that checking child->pktsize is more correct in this case.
In theory, someone could attach a device which uses 6-byte packets to
the Synaptics pass-thru port; I'm not sure what would happen in this
case, but with Synaptics confugured for 3-byte packets (as the patch
below will do) this configuration even has a chance of working.
---
Subject: [PATCH] Fix pass-thru port configuration in the Synaptics driver
The Synaptics driver uses child->type to select either 3-byte or 4-byte
packet size for the pass-thru port; this gives wrong results at least
for PSMOUSE_TRACKPOINT. Change the check to use child->pktsize instead.
Signed-off-by: Sergey Vlasov <[EMAIL PROTECTED]>
--- linux-2.6.12/drivers/input/mouse/synaptics.c.alt-synaptics-with-trackpoint
2005-06-17 23:48:29 +0400
+++ linux-2.6.12/drivers/input/mouse/synaptics.c2005-07-09 21:09:01
+0400
@@ -219,7 +219,7 @@ static void synaptics_pass_pt_packet(str
serio_interrupt(ptport, packet[1], 0, NULL);
serio_interrupt(ptport, packet[4], 0, NULL);
serio_interrupt(ptport, packet[5], 0, NULL);
- if (child->type >= PSMOUSE_GENPS)
+ if (child->pktsize == 4)
serio_interrupt(ptport, packet[2], 0, NULL);
} else
serio_interrupt(ptport, packet[1], 0, NULL);
@@ -233,7 +233,7 @@ static void synaptics_pt_activate(struct
/* adjust the touchpad to child's choice of protocol */
if (child) {
- if (child->type >= PSMOUSE_GENPS)
+ if (child->pktsize == 4)
priv->mode |= SYN_BIT_FOUR_BYTE_CLIENT;
else
priv->mode &= ~SYN_BIT_FOUR_BYTE_CLIENT;
pgpjH4BFSX2rM.pgp
Description: PGP signature
Re: Synaptics and TrackPoint problems in 2.6.12
On Tue, 19 Jul 2005 23:40:18 -0400 Stephen Evanchik wrote:
I have been receiving a lot of complaints that TrackPoints on
Synaptics pass-thru ports stopped working with 2.6.12. I retested
2.6.9 and 2.6.11-rc3 successfully, I believe 2.6.11.7 may also work
but that is unconfirmed at this point.
The behavior is always the same .. after sending the read secondary ID
command, the TrackPoint seems to be disabled from that point forward.
Any ideas?
Looks like this problem was introduced by the change from PSMOUSE_PS2 to
PSMOUSE_TRACKPOINT in the TrackPoint support patch. The Synaptics
driver needs to know whether the device on the pass-thru port is using
3-byte or 4-byte packets; however, instead of checking child-pktsize,
it checks child-type = PSMOUSE_GENPS - and this check is now giving a
wrong result. Therefore the Synaptics driver configures the pass-thru
port for 4-byte packets, and all 3-byte packets from TrackPoint seem to
be thrown away.
The patch below is reported to fix the problem - now the 4-byte mode is
used only if child-pktsize == 4. Another option is to change the
PSMOUSE_TRACKPOINT value so that it is less than PSMOUSE_GENPS, however,
I think that checking child-pktsize is more correct in this case.
In theory, someone could attach a device which uses 6-byte packets to
the Synaptics pass-thru port; I'm not sure what would happen in this
case, but with Synaptics confugured for 3-byte packets (as the patch
below will do) this configuration even has a chance of working.
---
Subject: [PATCH] Fix pass-thru port configuration in the Synaptics driver
The Synaptics driver uses child-type to select either 3-byte or 4-byte
packet size for the pass-thru port; this gives wrong results at least
for PSMOUSE_TRACKPOINT. Change the check to use child-pktsize instead.
Signed-off-by: Sergey Vlasov [EMAIL PROTECTED]
--- linux-2.6.12/drivers/input/mouse/synaptics.c.alt-synaptics-with-trackpoint
2005-06-17 23:48:29 +0400
+++ linux-2.6.12/drivers/input/mouse/synaptics.c2005-07-09 21:09:01
+0400
@@ -219,7 +219,7 @@ static void synaptics_pass_pt_packet(str
serio_interrupt(ptport, packet[1], 0, NULL);
serio_interrupt(ptport, packet[4], 0, NULL);
serio_interrupt(ptport, packet[5], 0, NULL);
- if (child-type = PSMOUSE_GENPS)
+ if (child-pktsize == 4)
serio_interrupt(ptport, packet[2], 0, NULL);
} else
serio_interrupt(ptport, packet[1], 0, NULL);
@@ -233,7 +233,7 @@ static void synaptics_pt_activate(struct
/* adjust the touchpad to child's choice of protocol */
if (child) {
- if (child-type = PSMOUSE_GENPS)
+ if (child-pktsize == 4)
priv-mode |= SYN_BIT_FOUR_BYTE_CLIENT;
else
priv-mode = ~SYN_BIT_FOUR_BYTE_CLIENT;
pgpjH4BFSX2rM.pgp
Description: PGP signature
Re: Synaptics and TrackPoint problems in 2.6.12
On Wed, Jul 20, 2005 at 10:05:13AM -0500, Dmitry Torokhov wrote: On 7/20/05, Sergey Vlasov [EMAIL PROTECTED] wrote: Another option is to change the PSMOUSE_TRACKPOINT value so that it is less than PSMOUSE_GENPS, No, protocol numbers should not be changed as userspace drivers/setups check them and rely on them being stable. Found that now: psmouse-dev.id.product = psmouse-type; So the type is visible through the input device interface. Probably this should be mentioned in a comment near enum psmouse_type - its definition in drivers/input/mouse/psmouse.h looks just like some driver-internal enum. In theory, someone could attach a device which uses 6-byte packets to the Synaptics pass-thru port; I'm not sure what would happen in this case, but with Synaptics confugured for 3-byte packets (as the patch below will do) this configuration even has a chance of working. I don't think it can support more than 4 byte packets. bytes 0 and 3 are protocol markers and can't be readily used for transmitting other protocols data. At least the Synaptics protocol description mentions that its 6-byte protocol was designed to look like two 3-byte PS/2 mouse packets, so that it would work even if the controller looks at those markers; other such protocols are likely to have the same property for the same reason. Now, if the Synaptics touchpad would be able to accept a 6-byte packet from the pass-thru port as two 3-byte packets... pgpUDXsWiQVCK.pgp Description: PGP signature
Re: via82xx driver: reporting dxs_support experience
On Sun, 17 Apr 2005 12:53:24 -0400 TJ wrote: > I was using the 2.6.7 kernel without APIC or ACPI support, and the via82xx > driver worked perfectly, compiled as a module, without any options. I built a > new 2.6.7 kernel on the same hardware with APIC and ACPI support in the > kernel, as the board supports it, and the driver did not work correctly. 2.6.7 is pretty old; there were many bugfixes in both ACPI and sound drivers since that time. > When sound was played, a short, 1 second long bit of the sound to be > played was looped. Possibly this is the clicking noise described by > some people? Does not look like it. The most common cause of looping sound are interrupt problems, and unfortunately ACPI (especially when coupled with APIC support) often triggers them (sometimes because of bugs in the kernel ACPI support, sometimes because a buggy BIOS supplies broken data). If interrupts are not working, usually this happens: - The driver sets up a circular buffer which contains the first portion of sound samples to be played, and starts the playback hardware. - The sound card reads the samples from the buffer; when it reaches some point in the buffer, it sends the interrupt signal, notifying the driver about it. - Normally, when the driver handles the interrupt, it will place more sound data in the circular buffer (or, in the mmap mode, it will notify the application, which will write to the buffer directly). However, if interrupts are not working, the driver will never get such notification, and the same portion of sound samples will stay in the buffer forever. The sound card does not know that the buffer was not updated and will play that piece of sound forever. Another symptom of not working interrupts is that aplay just hangs forever (aplay -vv should draw a histogram of played data). > The driver works fine with this new kernel after adding the option > "dxs_support=1". This is very strange - the dxs_support option should not cause such changes. Usually the problem caused by a wrong dxs_support value is that sound is basically there, but distorted. Also, seems that dxs_support=1 should not work at all (at least in theory). dxs_support=4 seems to be more correct; latest code in ALSA CVS supports dxs_support=5, which uses more capabilities of the hardware (apparently the VIA VT8233/5/7 chips are able to perform sample rate conversion from arbitrary rates to 48000 Hz with 4 independent channels). > I hope this interaction with ACPI and APIC sheds some light on some > of the troubles with this driver. Most likely you have some trouble with ACPI (either with the buggy implementation in 2.6.7, or with the buggy BIOS, or maybe both). > I can provide more information if > anyone wants it. Please CC me, I'm not on the list. > > TJ > > Motherboard: MSI K7T266 Pro2 > > 00:11.5 Class 0401: 1106:3059 (rev 10) Hmm, seems to be some old chip revision: #define VIA_REV_PRE_82330x10/* not in market */ > Subsystem: 4005:4710 Not in the known devices list of snd-via82xx (this list contains working values of the dxs_support option for known boards). But you should report it to ALSA developers (e.g., in their bug tracking system, https://bugtrack.alsa-project.org/alsa-bug/ ) - your message to LKML will likely be lost. > Flags: medium devsel, IRQ 28 > I/O ports at bc00 [size=256] > Capabilities: [c0] Power Management version 2 pgpCEtZpQwkB4.pgp Description: PGP signature
Re: via82xx driver: reporting dxs_support experience
On Sun, 17 Apr 2005 12:53:24 -0400 TJ wrote: I was using the 2.6.7 kernel without APIC or ACPI support, and the via82xx driver worked perfectly, compiled as a module, without any options. I built a new 2.6.7 kernel on the same hardware with APIC and ACPI support in the kernel, as the board supports it, and the driver did not work correctly. 2.6.7 is pretty old; there were many bugfixes in both ACPI and sound drivers since that time. When sound was played, a short, 1 second long bit of the sound to be played was looped. Possibly this is the clicking noise described by some people? Does not look like it. The most common cause of looping sound are interrupt problems, and unfortunately ACPI (especially when coupled with APIC support) often triggers them (sometimes because of bugs in the kernel ACPI support, sometimes because a buggy BIOS supplies broken data). If interrupts are not working, usually this happens: - The driver sets up a circular buffer which contains the first portion of sound samples to be played, and starts the playback hardware. - The sound card reads the samples from the buffer; when it reaches some point in the buffer, it sends the interrupt signal, notifying the driver about it. - Normally, when the driver handles the interrupt, it will place more sound data in the circular buffer (or, in the mmap mode, it will notify the application, which will write to the buffer directly). However, if interrupts are not working, the driver will never get such notification, and the same portion of sound samples will stay in the buffer forever. The sound card does not know that the buffer was not updated and will play that piece of sound forever. Another symptom of not working interrupts is that aplay just hangs forever (aplay -vv should draw a histogram of played data). The driver works fine with this new kernel after adding the option dxs_support=1. This is very strange - the dxs_support option should not cause such changes. Usually the problem caused by a wrong dxs_support value is that sound is basically there, but distorted. Also, seems that dxs_support=1 should not work at all (at least in theory). dxs_support=4 seems to be more correct; latest code in ALSA CVS supports dxs_support=5, which uses more capabilities of the hardware (apparently the VIA VT8233/5/7 chips are able to perform sample rate conversion from arbitrary rates to 48000 Hz with 4 independent channels). I hope this interaction with ACPI and APIC sheds some light on some of the troubles with this driver. Most likely you have some trouble with ACPI (either with the buggy implementation in 2.6.7, or with the buggy BIOS, or maybe both). I can provide more information if anyone wants it. Please CC me, I'm not on the list. TJ Motherboard: MSI K7T266 Pro2 00:11.5 Class 0401: 1106:3059 (rev 10) Hmm, seems to be some old chip revision: #define VIA_REV_PRE_82330x10/* not in market */ Subsystem: 4005:4710 Not in the known devices list of snd-via82xx (this list contains working values of the dxs_support option for known boards). But you should report it to ALSA developers (e.g., in their bug tracking system, https://bugtrack.alsa-project.org/alsa-bug/ ) - your message to LKML will likely be lost. Flags: medium devsel, IRQ 28 I/O ports at bc00 [size=256] Capabilities: [c0] Power Management version 2 pgpCEtZpQwkB4.pgp Description: PGP signature
Re: [OOPS] on usb removal, and minicom closing 2.6.11.7
On Thu, 14 Apr 2005 14:40:36 +0200 Grzegorz Piotr Jaskiewicz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Works great, I would like to ask everyone here on lkml to consider
> adding this patch to mainline.
> This ain't naughty solution, checking for object/pointer/whatever if
> exists before doing anything with it, is good.
No, this patch is broken. It just avoids the problem in 99% of cases,
but it is not reliable. The real problem is that refcounting in cdc-acm
is broken, and the kernel is accessing freed memory.
The patches which really seem to fix the underlying problem can be found
in this thread:
http://thread.gmane.org/gmane.linux.usb.devel/32977
(see "[PATCH] N/3 cdc acm errors").
You also need this driver core fix:
http://thread.gmane.org/gmane.linux.usb.devel/33132
> Anyone?
>
> Buy the way, I am also looking for usblan for 2.6, can I use usbnet
> instead ? Anyone ported usblan to 2.6 (it's on GPL).
>
> JustMan wrote:
> >>So,
> >>
> >>I plugged in e680 motorola phone, played a bit with minicom on
> >>/dev/ttyACM0, and when I closed minicom, got this oops. USB is useless,
> >>got to reboot computer to use it again!
> >>it's vanilla 2.6.11.7
> >>
> >>oops attached.
> >>
> >
> >
> > Try attached patch... (nasty solution, but it work for my C350 motorola
> > phone)
> >
> >
> >>
> >
> >
> >
> >
> > diff -uNrp linux/drivers/base/class.orig.c linux/drivers/base/class.c
> > --- linux/drivers/base/class.orig.c 2005-03-10 12:19:00.0 +0300
> > +++ linux/drivers/base/class.c 2005-03-10 13:59:27.0 +0300
> > @@ -307,12 +307,14 @@ static int class_hotplug(struct kset *ks
> > if (class_dev->dev) {
> > /* add physical device, backing this device */
> > struct device *dev = class_dev->dev;
> > - char *path = kobject_get_path(>kobj, GFP_KERNEL);
> >
> > - add_hotplug_env_var(envp, num_envp, , buffer, buffer_size,
> > - , "PHYSDEVPATH=%s", path);
> > - kfree(path);
> > + if(kobject_name(>kobj)) {
> > + char *path = kobject_get_path(>kobj, GFP_KERNEL);
> >
> > + add_hotplug_env_var(envp, num_envp, , buffer,
> > buffer_size,
> > + , "PHYSDEVPATH=%s", path);
> > + kfree(path);
> > + }
> > /* add bus name of physical device */
> > if (dev->bus)
> > add_hotplug_env_var(envp, num_envp, ,
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.0 (GNU/Linux)
>
> iD8DBQFCXmTEi0HtPCVkDAURAvIMAJ4+8tKj6jt/ErTtCrsmNYtM2aDfNACgigLA
> 4GbLbHStQJBq+Ez1lFe+lPo=
> =UWvD
> -END PGP SIGNATURE-
pgpUenWk4qHrf.pgp
Description: PGP signature
Re: [OOPS] on usb removal, and minicom closing 2.6.11.7
On Thu, 14 Apr 2005 14:40:36 +0200 Grzegorz Piotr Jaskiewicz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Works great, I would like to ask everyone here on lkml to consider
adding this patch to mainline.
This ain't naughty solution, checking for object/pointer/whatever if
exists before doing anything with it, is good.
No, this patch is broken. It just avoids the problem in 99% of cases,
but it is not reliable. The real problem is that refcounting in cdc-acm
is broken, and the kernel is accessing freed memory.
The patches which really seem to fix the underlying problem can be found
in this thread:
http://thread.gmane.org/gmane.linux.usb.devel/32977
(see [PATCH] N/3 cdc acm errors).
You also need this driver core fix:
http://thread.gmane.org/gmane.linux.usb.devel/33132
Anyone?
Buy the way, I am also looking for usblan for 2.6, can I use usbnet
instead ? Anyone ported usblan to 2.6 (it's on GPL).
JustMan wrote:
So,
I plugged in e680 motorola phone, played a bit with minicom on
/dev/ttyACM0, and when I closed minicom, got this oops. USB is useless,
got to reboot computer to use it again!
it's vanilla 2.6.11.7
oops attached.
Try attached patch... (nasty solution, but it work for my C350 motorola
phone)
diff -uNrp linux/drivers/base/class.orig.c linux/drivers/base/class.c
--- linux/drivers/base/class.orig.c 2005-03-10 12:19:00.0 +0300
+++ linux/drivers/base/class.c 2005-03-10 13:59:27.0 +0300
@@ -307,12 +307,14 @@ static int class_hotplug(struct kset *ks
if (class_dev-dev) {
/* add physical device, backing this device */
struct device *dev = class_dev-dev;
- char *path = kobject_get_path(dev-kobj, GFP_KERNEL);
- add_hotplug_env_var(envp, num_envp, i, buffer, buffer_size,
- length, PHYSDEVPATH=%s, path);
- kfree(path);
+ if(kobject_name(dev-kobj)) {
+ char *path = kobject_get_path(dev-kobj, GFP_KERNEL);
+ add_hotplug_env_var(envp, num_envp, i, buffer,
buffer_size,
+ length, PHYSDEVPATH=%s, path);
+ kfree(path);
+ }
/* add bus name of physical device */
if (dev-bus)
add_hotplug_env_var(envp, num_envp, i,
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCXmTEi0HtPCVkDAURAvIMAJ4+8tKj6jt/ErTtCrsmNYtM2aDfNACgigLA
4GbLbHStQJBq+Ez1lFe+lPo=
=UWvD
-END PGP SIGNATURE-
pgpUenWk4qHrf.pgp
Description: PGP signature
Re: Last night Linus bk - netfilter busted?
On Fri, 11 Mar 2005 10:51:36 -0800 David S. Miller wrote: > On Fri, 11 Mar 2005 15:00:56 +0100 > Patrick McHardy <[EMAIL PROTECTED]> wrote: > > > Works fine here. You could try if reverting one of these two patches > > helps (second one only if its a SMP box). > > > > [EMAIL PROTECTED], 2005-03-09 20:28:17-08:00, [EMAIL PROTECTED] > >[NETFILTER]: Reduce call chain length in netfilter (take 2) > > It's this change, I know it is, because Linus sees the same problem > on his workstation. > > You wouldn't happen to be seeing this problem on a PPC box would > you? Since Linus's machine is a PPC machine too, that would support > my theory that this could be a compiler issue on that platform. > > Damn, wait, Patrick, I think I know what's happening. The iptables > IPT_* verdicts are dependant upon the NF_* values, and they don't > cope with Bart's changes I bet. Can you figure out what the exact > error would be? This kind of issue would explain the looping inside > of ipt_do_table(), wouldn't it? This is not just some buggy code - that patch also breaks interfaces: include/linux/netfilter_ipv4/ip_tables.h: #define IPT_RETURN (-NF_MAX_VERDICT - 1) And this value is visible in userspace. Therefore we cannot modify NF_MAX_VERDICT without breaking all existing iptables binaries. pgpz60SKWdZA8.pgp Description: PGP signature
Re: Last night Linus bk - netfilter busted?
On Fri, 11 Mar 2005 10:51:36 -0800 David S. Miller wrote: On Fri, 11 Mar 2005 15:00:56 +0100 Patrick McHardy [EMAIL PROTECTED] wrote: Works fine here. You could try if reverting one of these two patches helps (second one only if its a SMP box). [EMAIL PROTECTED], 2005-03-09 20:28:17-08:00, [EMAIL PROTECTED] [NETFILTER]: Reduce call chain length in netfilter (take 2) It's this change, I know it is, because Linus sees the same problem on his workstation. You wouldn't happen to be seeing this problem on a PPC box would you? Since Linus's machine is a PPC machine too, that would support my theory that this could be a compiler issue on that platform. Damn, wait, Patrick, I think I know what's happening. The iptables IPT_* verdicts are dependant upon the NF_* values, and they don't cope with Bart's changes I bet. Can you figure out what the exact error would be? This kind of issue would explain the looping inside of ipt_do_table(), wouldn't it? This is not just some buggy code - that patch also breaks interfaces: include/linux/netfilter_ipv4/ip_tables.h: #define IPT_RETURN (-NF_MAX_VERDICT - 1) And this value is visible in userspace. Therefore we cannot modify NF_MAX_VERDICT without breaking all existing iptables binaries. pgpz60SKWdZA8.pgp Description: PGP signature
Re: [PATCH] lookup traps, for compact autofs/devfs functionality
On Fri, Nov 05, 2004 at 11:38:22PM -0800, Adam J. Richter wrote: > The following patch implements a facility for invoking a user > level helper program whenever a program attempts to access a > nonexistent file on a given tmpfs file system. It can provide > functionality like autofs or devfs. At 1708 bytes of object code, it > should result in smaller implementations when it can be used, and > may avoid some potential recursion problems. A patch that shrinks > devfs by much more than the size of this facility depends on it, > so I would like to get it into the kernel soon. What's the status of this patch - do you still plan to push it into the kernel? > Documentation/filesystems/lookup-trap.txt provides cookbook > examples of how to use lookup traps with scripts or short C programs > to for a variety of uses. For example, here a way to create a create > a simple automounter for remote file systems: > > % cat > /usr/sbin/tmpfs-automount > #!/bin/sh > mkdir $3 > mount -t nfs $3:/ $1/$3 > ^D > % chmod a+x /usr/sbin/tmpfs-automount > % mkdir /auto > % mount -t tmpfs -o helper="/usr/sbin/tmpfs-automount /auto" x /auto > > > I will soon post a small devfs replacement based on this > facility. The lookup traps and the devfs patch are an evolution of > the shrunken devfs reimplementation that I posted almost two years > ago, which I have been running continuously on a number of computers > ever since, although the use of tmpfs is only a few days old. > > The implementation is small. The total increase in object > code size on x86 is 1708 bytes (mm/shmem.o change + fs/userhelper.o + > fs/lookuptrap.o), and I've made it a configuration option, so people > who don't want it will only be victimized by 180 object bytes of > changes I had to make outside of the ifdef's to mm/shmem.c (those > changes are counted in those 1708 byte tally, by the way). > > By line count, if you don't count the Documentation > subdirectory, the devfs replacement and lookup traps taken together > are actually a net reduction of more than 1800 lines of code from the > kernel. The lookup traps patch taken by itself is a net increase of > 533 lines of code, most of which is in two files outside the tmpfs > sources to facilitate possible use by other file systems. In > comparison, fs/autofs/*.[ch] is more than triple that line count. > > Over the past few days, I have posted earlier versions of > these patches on linux-fsdevel, originally under the name "trapfs." > This latest patch incorporate feedback expressed by a few people on > that list. Greg Kroah-Hartmann prefered the facility being a tmpfs > option, which I saw some advantages to as well. Mike Waychison and > Matthew Wilcox got me to take a harder look at a user level race > condition that I mentioned in the original posting, which eventually > led to an apparent solution that is incorporated into this version. > > Finally, I should mention a limitation and couple of > deficiencies that I'm aware of with respect to lookup traps to save > everyone some discussion time. > > 1. As Mike Waychison pointed out, this facility in tmpfs > cannot be used to trap accesses to the root of a file system or create > directories and then trap accesses when a program attempts to "cd" in. > Such functionality could provide a more consistent and informative > user interface for an automatic mounter of a small to moderate number > of remote file systems, in the style of autofs. The good news is that > this patch provides a facility in fs/userhelper.c that could be called > by another file system to provide functionality on > inode_operations->follow_link() events similar to what this patch does > for inode_operations->lookup() under tmpfs, hopefully allowing such an > implementation to be smaller. > > 2. Like sysfs and ramfs, tmpfs uses a struct inode and a > struct dentry for every file system node, consuming something like 500 > bytes per node. A backing store patch similar to the sysfs backing > store patch could dramatically reduce the memory used by the > tmpfs-based devfs, implementation. the devfs application of , > although devfs file systems tend to have fewer nodes, since they are > created on demand, and devfs memory consumption pales in comparison to > sysfs. I think that at some point in the future, it might be useful > to implement some kind of release of struct inode's for device files > at least, similar to the "sysfs backing store" patch that is supposed > to be on its way into the stock kernel. > > 3. Until the trapfs helper exits, it is impossible to > control-C out of the access that invoked the helper. This is a > deficiency of the synchronous call_usermodehelper interface. Every > kernel facility that uses call_usermodehelper has this problem. There > are a number of ways to fix synchronous call_usermodehelper, and I > surely expect trapfs to use
Re: [PATCH] lookup traps, for compact autofs/devfs functionality
On Fri, Nov 05, 2004 at 11:38:22PM -0800, Adam J. Richter wrote: The following patch implements a facility for invoking a user level helper program whenever a program attempts to access a nonexistent file on a given tmpfs file system. It can provide functionality like autofs or devfs. At 1708 bytes of object code, it should result in smaller implementations when it can be used, and may avoid some potential recursion problems. A patch that shrinks devfs by much more than the size of this facility depends on it, so I would like to get it into the kernel soon. What's the status of this patch - do you still plan to push it into the kernel? Documentation/filesystems/lookup-trap.txt provides cookbook examples of how to use lookup traps with scripts or short C programs to for a variety of uses. For example, here a way to create a create a simple automounter for remote file systems: % cat /usr/sbin/tmpfs-automount #!/bin/sh mkdir $3 mount -t nfs $3:/ $1/$3 ^D % chmod a+x /usr/sbin/tmpfs-automount % mkdir /auto % mount -t tmpfs -o helper=/usr/sbin/tmpfs-automount /auto x /auto I will soon post a small devfs replacement based on this facility. The lookup traps and the devfs patch are an evolution of the shrunken devfs reimplementation that I posted almost two years ago, which I have been running continuously on a number of computers ever since, although the use of tmpfs is only a few days old. The implementation is small. The total increase in object code size on x86 is 1708 bytes (mm/shmem.o change + fs/userhelper.o + fs/lookuptrap.o), and I've made it a configuration option, so people who don't want it will only be victimized by 180 object bytes of changes I had to make outside of the ifdef's to mm/shmem.c (those changes are counted in those 1708 byte tally, by the way). By line count, if you don't count the Documentation subdirectory, the devfs replacement and lookup traps taken together are actually a net reduction of more than 1800 lines of code from the kernel. The lookup traps patch taken by itself is a net increase of 533 lines of code, most of which is in two files outside the tmpfs sources to facilitate possible use by other file systems. In comparison, fs/autofs/*.[ch] is more than triple that line count. Over the past few days, I have posted earlier versions of these patches on linux-fsdevel, originally under the name trapfs. This latest patch incorporate feedback expressed by a few people on that list. Greg Kroah-Hartmann prefered the facility being a tmpfs option, which I saw some advantages to as well. Mike Waychison and Matthew Wilcox got me to take a harder look at a user level race condition that I mentioned in the original posting, which eventually led to an apparent solution that is incorporated into this version. Finally, I should mention a limitation and couple of deficiencies that I'm aware of with respect to lookup traps to save everyone some discussion time. 1. As Mike Waychison pointed out, this facility in tmpfs cannot be used to trap accesses to the root of a file system or create directories and then trap accesses when a program attempts to cd in. Such functionality could provide a more consistent and informative user interface for an automatic mounter of a small to moderate number of remote file systems, in the style of autofs. The good news is that this patch provides a facility in fs/userhelper.c that could be called by another file system to provide functionality on inode_operations-follow_link() events similar to what this patch does for inode_operations-lookup() under tmpfs, hopefully allowing such an implementation to be smaller. 2. Like sysfs and ramfs, tmpfs uses a struct inode and a struct dentry for every file system node, consuming something like 500 bytes per node. A backing store patch similar to the sysfs backing store patch could dramatically reduce the memory used by the tmpfs-based devfs, implementation. the devfs application of , although devfs file systems tend to have fewer nodes, since they are created on demand, and devfs memory consumption pales in comparison to sysfs. I think that at some point in the future, it might be useful to implement some kind of release of struct inode's for device files at least, similar to the sysfs backing store patch that is supposed to be on its way into the stock kernel. 3. Until the trapfs helper exits, it is impossible to control-C out of the access that invoked the helper. This is a deficiency of the synchronous call_usermodehelper interface. Every kernel facility that uses call_usermodehelper has this problem. There are a number of ways to fix synchronous call_usermodehelper, and I surely expect trapfs to use whatever solution is implemented. Any feedback would be welcome. __
Re: [PATCH] raw1394 missing failure handling
On Wed, 02 Mar 2005 12:10:50 +0100 Panagiotis Issaris wrote: > In the raw1394 driver the failure handling for > a __copy_to_user call is missing. > > With friendly regards, > Takis > > -- > K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group > http://people.mech.kuleuven.ac.be/~pissaris/ > > > > [pi-20050302T114855-linux_2_6_11-raw1394_copy_to_user_failure_handling.diff > text/x-patch (922 bytes)] > diff -pruN linux-2.6.11/drivers/ieee1394/raw1394.c > linux-2.6.11-pi/drivers/ieee1394/raw1394.c > --- linux-2.6.11/drivers/ieee1394/raw1394.c 2005-03-02 11:44:26.0 > +0100 > +++ linux-2.6.11-pi/drivers/ieee1394/raw1394.c2005-03-02 > 11:47:38.0 +0100 > @@ -443,7 +443,8 @@ static ssize_t raw1394_read(struct file > req->req.error = RAW1394_ERROR_MEMFAULT; > } > } > -__copy_to_user(buffer, >req, sizeof(req->req)); > +if (__copy_to_user(buffer, >req, sizeof(req->req))) > +return -EFAULT; Bug: "req" is not freed in the failure case. > > free_pending_request(req); > return sizeof(struct raw1394_request); > pgphuQbAxMGnG.pgp Description: PGP signature
Re: [PATCH] raw1394 missing failure handling
On Wed, 02 Mar 2005 12:10:50 +0100 Panagiotis Issaris wrote: In the raw1394 driver the failure handling for a __copy_to_user call is missing. With friendly regards, Takis -- K.U.Leuven, Mechanical Eng., Mechatronics Robotics Research Group http://people.mech.kuleuven.ac.be/~pissaris/ [pi-20050302T114855-linux_2_6_11-raw1394_copy_to_user_failure_handling.diff text/x-patch (922 bytes)] diff -pruN linux-2.6.11/drivers/ieee1394/raw1394.c linux-2.6.11-pi/drivers/ieee1394/raw1394.c --- linux-2.6.11/drivers/ieee1394/raw1394.c 2005-03-02 11:44:26.0 +0100 +++ linux-2.6.11-pi/drivers/ieee1394/raw1394.c2005-03-02 11:47:38.0 +0100 @@ -443,7 +443,8 @@ static ssize_t raw1394_read(struct file req-req.error = RAW1394_ERROR_MEMFAULT; } } -__copy_to_user(buffer, req-req, sizeof(req-req)); +if (__copy_to_user(buffer, req-req, sizeof(req-req))) +return -EFAULT; Bug: req is not freed in the failure case. free_pending_request(req); return sizeof(struct raw1394_request); pgphuQbAxMGnG.pgp Description: PGP signature
Re: [PATCH] New operation for kref to help avoid locks
On Sat, 26 Feb 2005 09:55:41 -0600 Corey Minyard wrote:
> Greg,
>
> This is the patch for krefs that we talked about. If you don't like it
> but like the docs, feel free just to take the documentation and cut out
> the stuff at the end about the new operation.
See below for comments to the patch.
>
> Thanks,
>
> -Corey
>
>
> [kref_checked.diff text/plain (10576 bytes)]
> Add a routine to kref that allows the kref_put() routine to be
> unserialized even when the get routine attempts to kref_get()
> an object without first holding a valid reference to it. This is
> useful in situations where this happens multiple times without
> freeing the object, as it will avoid having to do a lock/semaphore
> except on the final kref_put().
>
> This also adds some kref documentation to the Documentation
> directory.
>
> Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
>
> Index: linux-2.6.11-rc4/include/linux/kref.h
> ===
> --- linux-2.6.11-rc4.orig/include/linux/kref.h
> +++ linux-2.6.11-rc4/include/linux/kref.h
> @@ -28,5 +28,11 @@
> void kref_get(struct kref *kref);
> void kref_put(struct kref *kref, void (*release) (struct kref *kref));
>
> +/* Get a kref if the count is not already zero. This can be used to
> + avoid a lock in the routine that calls kref_put(). Returns 1 if
> + successful or zero if the count was already zero. See
> + Documentation/kref.txt for details on how to use this. */
> +int kref_get_with_check(struct kref *kref);
> +
> #endif /* __KERNEL__ */
> #endif /* _KREF_H_ */
> Index: linux-2.6.11-rc4/lib/kref.c
> ===
> --- linux-2.6.11-rc4.orig/lib/kref.c
> +++ linux-2.6.11-rc4/lib/kref.c
> @@ -52,6 +52,21 @@
> release(kref);
> }
>
> +/**
> + * kref_get_with_check - increment refcount if the refcount is not already 0.
> + * @kref: object.
> + */
> +int kref_get_with_check(struct kref *kref)
> +{
> + atomic_inc(>refcount);
> + if (atomic_read(>refcount) == 1) {
> + atomic_dec(>refcount);
> + return 0;
> + }
> + return 1;
> +}
Consider this situation:
initially refcount is 1
CPU1 does kref_get_with_check() CPU2 does kref_put()
atomic_inc(>refcount)
(increments refcount to 2)
atomic_dec_and_test(>refcount)
(decrements refcount to 1)
(kref_put() does nothing more
because the refcount did not
reach zero)
atomic_read(>refcount)
(finds refcount == 1 and decides
that the entry was being deleted)
atomic_dec(>refcount);
(decrements refcount to 0)
(then proceeds thinking that the
entry was about to be finalized,
thus creating a leak)
Because of this, separate atomic_inc+atomic_read sequence is unsafe -
you need atomic_inc_return() here instead:
int kref_get_with_check(struct kref *kref)
{
if (atomic_inc_return(>refcount) == 1) {
atomic_dec(>refcount);
return 0;
}
return 1;
}
> +
> EXPORT_SYMBOL(kref_init);
> EXPORT_SYMBOL(kref_get);
> EXPORT_SYMBOL(kref_put);
> +EXPORT_SYMBOL(kref_get_with_check);
> Index: linux-2.6.11-rc4/Documentation/kref.txt
> ===
> --- /dev/null
> +++ linux-2.6.11-rc4/Documentation/kref.txt
> @@ -0,0 +1,274 @@
> +krefs allow you to add reference counters to your objects. If you
> +have objects that are used in multiple places and passed around, and
> +you don't have refcounts, your code is almost certainly broken. If
> +you want refcounts, krefs are the way to go.
> +
> +To use a kref, add a one to your data structures like:
> +
> +struct my_data
> +{
> + .
> + .
> + struct kref refcount;
> + .
> + .
> +};
> +
> +The kref can occur anywhere within the data structure.
> +
> +You must initialize the kref after you allocate it. To do this, call
> +kref init as so:
> +
> + struct my_data *data;
> +
> + data = kmalloc(sizeof(*data), GFP_KERNEL);
> + if (!data)
> +return -ENOMEM;
> + kref_init(>refcount);
> +
> +This sets the refcount in the kref to 1.
> +
> +Once you have a refcount, you must follow the following rules:
> +
> +1) If you make a non-temporary copy of a pointer, especially if
> + it can be passed to another thread of execution, you must
> + increment the refcount with kref_get() before passing it off:
> + kref_get(>refcount);
> + If you already have a valid pointer to a kref-ed structure (the
> + refcount cannot go to zero) you may do this without a lock.
> +
> +2) When you are done with a pointer, you must call kref_put():
> + kref_put(>refcount, data_release);
> + If this is the last reference to the
Re: [PATCH] New operation for kref to help avoid locks
On Sat, 26 Feb 2005 09:55:41 -0600 Corey Minyard wrote:
Greg,
This is the patch for krefs that we talked about. If you don't like it
but like the docs, feel free just to take the documentation and cut out
the stuff at the end about the new operation.
See below for comments to the patch.
Thanks,
-Corey
[kref_checked.diff text/plain (10576 bytes)]
Add a routine to kref that allows the kref_put() routine to be
unserialized even when the get routine attempts to kref_get()
an object without first holding a valid reference to it. This is
useful in situations where this happens multiple times without
freeing the object, as it will avoid having to do a lock/semaphore
except on the final kref_put().
This also adds some kref documentation to the Documentation
directory.
Signed-off-by: Corey Minyard [EMAIL PROTECTED]
Index: linux-2.6.11-rc4/include/linux/kref.h
===
--- linux-2.6.11-rc4.orig/include/linux/kref.h
+++ linux-2.6.11-rc4/include/linux/kref.h
@@ -28,5 +28,11 @@
void kref_get(struct kref *kref);
void kref_put(struct kref *kref, void (*release) (struct kref *kref));
+/* Get a kref if the count is not already zero. This can be used to
+ avoid a lock in the routine that calls kref_put(). Returns 1 if
+ successful or zero if the count was already zero. See
+ Documentation/kref.txt for details on how to use this. */
+int kref_get_with_check(struct kref *kref);
+
#endif /* __KERNEL__ */
#endif /* _KREF_H_ */
Index: linux-2.6.11-rc4/lib/kref.c
===
--- linux-2.6.11-rc4.orig/lib/kref.c
+++ linux-2.6.11-rc4/lib/kref.c
@@ -52,6 +52,21 @@
release(kref);
}
+/**
+ * kref_get_with_check - increment refcount if the refcount is not already 0.
+ * @kref: object.
+ */
+int kref_get_with_check(struct kref *kref)
+{
+ atomic_inc(kref-refcount);
+ if (atomic_read(kref-refcount) == 1) {
+ atomic_dec(kref-refcount);
+ return 0;
+ }
+ return 1;
+}
Consider this situation:
initially refcount is 1
CPU1 does kref_get_with_check() CPU2 does kref_put()
atomic_inc(kref-refcount)
(increments refcount to 2)
atomic_dec_and_test(kref-refcount)
(decrements refcount to 1)
(kref_put() does nothing more
because the refcount did not
reach zero)
atomic_read(kref-refcount)
(finds refcount == 1 and decides
that the entry was being deleted)
atomic_dec(kref-refcount);
(decrements refcount to 0)
(then proceeds thinking that the
entry was about to be finalized,
thus creating a leak)
Because of this, separate atomic_inc+atomic_read sequence is unsafe -
you need atomic_inc_return() here instead:
int kref_get_with_check(struct kref *kref)
{
if (atomic_inc_return(kref-refcount) == 1) {
atomic_dec(kref-refcount);
return 0;
}
return 1;
}
+
EXPORT_SYMBOL(kref_init);
EXPORT_SYMBOL(kref_get);
EXPORT_SYMBOL(kref_put);
+EXPORT_SYMBOL(kref_get_with_check);
Index: linux-2.6.11-rc4/Documentation/kref.txt
===
--- /dev/null
+++ linux-2.6.11-rc4/Documentation/kref.txt
@@ -0,0 +1,274 @@
+krefs allow you to add reference counters to your objects. If you
+have objects that are used in multiple places and passed around, and
+you don't have refcounts, your code is almost certainly broken. If
+you want refcounts, krefs are the way to go.
+
+To use a kref, add a one to your data structures like:
+
+struct my_data
+{
+ .
+ .
+ struct kref refcount;
+ .
+ .
+};
+
+The kref can occur anywhere within the data structure.
+
+You must initialize the kref after you allocate it. To do this, call
+kref init as so:
+
+ struct my_data *data;
+
+ data = kmalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+return -ENOMEM;
+ kref_init(data-refcount);
+
+This sets the refcount in the kref to 1.
+
+Once you have a refcount, you must follow the following rules:
+
+1) If you make a non-temporary copy of a pointer, especially if
+ it can be passed to another thread of execution, you must
+ increment the refcount with kref_get() before passing it off:
+ kref_get(data-refcount);
+ If you already have a valid pointer to a kref-ed structure (the
+ refcount cannot go to zero) you may do this without a lock.
+
+2) When you are done with a pointer, you must call kref_put():
+ kref_put(data-refcount, data_release);
+ If this is the last reference to the pointer, the release
+ routine will be called. If the code never
Re: 2.6.11-rc5
On Thu, 24 Feb 2005 16:57:56 +0200 M.Baris Demiray wrote: > Steven Rostedt wrote: > > > [...] > > > > Anyone know if the linux-2.6.11-rc5.tar.bz2 has all the changes in it? > > The tarball rc5 is smaller than rc4. Was there a lot taken out? > > Take a look at the diffview of 2.6.11-rc4-rc5 incremental patch. > > > 5599 files changed, 166396 insertions(+), 293627 deletions(-) > And especially at this chunk: --- linux-2.6.11-rc4/Makefile 2005-02-23 20:53:50.707759849 -0800 +++ linux-2.6.11-rc5/Makefile 2004-12-24 13:35:01.0 -0800 @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 -SUBLEVEL = 11 -EXTRAVERSION =-rc4 +SUBLEVEL = 10 +EXTRAVERSION = NAME=Woozy Numbat # *DOCUMENTATION* Obviously 2.6.11-rc5 is screwed up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc5
On Thu, 24 Feb 2005 16:57:56 +0200 M.Baris Demiray wrote: Steven Rostedt wrote: [...] Anyone know if the linux-2.6.11-rc5.tar.bz2 has all the changes in it? The tarball rc5 is smaller than rc4. Was there a lot taken out? Take a look at the diffview of 2.6.11-rc4-rc5 incremental patch. snip 5599 files changed, 166396 insertions(+), 293627 deletions(-) /snip And especially at this chunk: --- linux-2.6.11-rc4/Makefile 2005-02-23 20:53:50.707759849 -0800 +++ linux-2.6.11-rc5/Makefile 2004-12-24 13:35:01.0 -0800 @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 -SUBLEVEL = 11 -EXTRAVERSION =-rc4 +SUBLEVEL = 10 +EXTRAVERSION = NAME=Woozy Numbat # *DOCUMENTATION* Obviously 2.6.11-rc5 is screwed up. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pty is losing bytes
On Tue, Feb 15, 2005 at 10:58:02PM +0300, Sergey Vlasov wrote:
> On Tue, 15 Feb 2005 11:08:07 -0800 (PST) Linus Torvalds wrote:
>
> > On Tue, 15 Feb 2005, Andreas Schwab wrote:
> > >
> > > Recent kernel are losing bytes on a pty.
> >
> > Great catch.
> >
> > I think it may be a n_tty line discipline bug, brought on by the fact that
> > the PTY buffering is now 4kB rather than 2kB. 4kB is also the
> > N_TTY_BUF_SIZE, and if n_tty has some off-by-one error, that would explain
> > it.
> >
> > Does the problem go away if you change the default value of "chunk" (in
> > drivers/char/tty_io.c:do_tty_write) from 4096 to 2048? If so, that means
> > that the pty code has _claimed_ to have written 4kB, and only ever wrote
> > 4kB-1 bytes. That in turn implies that "ldisc.receive_room()" disagrees
> > with "ldisc.receive_buf()".
>
> The problem also goes away after unsetting ECHO on the slave terminal.
> This seems to point to this code in n_tty_receive_char():
>
> if (L_ECHO(tty)) {
> if (tty->read_cnt >= N_TTY_BUF_SIZE-1) {
> put_char('\a', tty); /* beep if no space */
> return;
> }
> ...
> }
>
> This code sets the maximum number of buffered characters to
> N_TTY_BUF_SIZE-1, however, put_tty_queue() considers the maximum to be
> N_TTY_BUF_SIZE, and n_tty_receive_room() also returns N_TTY_BUF_SIZE for
> canonical mode if the canon_data buffer is empty - therefore after
> unsetting ECHO bytes are no longer lost.
But all this really is not important, because n_tty_receive_char() can
put more than one char into buffer for a single input char in lots of
cases. Therefore n_tty_receive_room() can overestimate the available
space at least by 2 times.
pgpFTJQt2jdWs.pgp
Description: PGP signature
Re: Pty is losing bytes
On Tue, 15 Feb 2005 11:08:07 -0800 (PST) Linus Torvalds wrote:
> On Tue, 15 Feb 2005, Andreas Schwab wrote:
> >
> > Recent kernel are losing bytes on a pty.
>
> Great catch.
>
> I think it may be a n_tty line discipline bug, brought on by the fact that
> the PTY buffering is now 4kB rather than 2kB. 4kB is also the
> N_TTY_BUF_SIZE, and if n_tty has some off-by-one error, that would explain
> it.
>
> Does the problem go away if you change the default value of "chunk" (in
> drivers/char/tty_io.c:do_tty_write) from 4096 to 2048? If so, that means
> that the pty code has _claimed_ to have written 4kB, and only ever wrote
> 4kB-1 bytes. That in turn implies that "ldisc.receive_room()" disagrees
> with "ldisc.receive_buf()".
The problem also goes away after unsetting ECHO on the slave terminal.
This seems to point to this code in n_tty_receive_char():
if (L_ECHO(tty)) {
if (tty->read_cnt >= N_TTY_BUF_SIZE-1) {
put_char('\a', tty); /* beep if no space */
return;
}
...
}
This code sets the maximum number of buffered characters to
N_TTY_BUF_SIZE-1, however, put_tty_queue() considers the maximum to be
N_TTY_BUF_SIZE, and n_tty_receive_room() also returns N_TTY_BUF_SIZE for
canonical mode if the canon_data buffer is empty - therefore after
unsetting ECHO bytes are no longer lost.
BTW, for the noncanonical mode n_tty_receive_room() calculates the
result assuming that the buffer can hold at most N_TTY_BUF_SIZE-1
characters - not the full N_TTY_BUF_SIZE.
pgpxnDQSGHPVE.pgp
Description: PGP signature
Re: Pty is losing bytes
On Tue, 15 Feb 2005 11:08:07 -0800 (PST) Linus Torvalds wrote:
On Tue, 15 Feb 2005, Andreas Schwab wrote:
Recent kernel are losing bytes on a pty.
Great catch.
I think it may be a n_tty line discipline bug, brought on by the fact that
the PTY buffering is now 4kB rather than 2kB. 4kB is also the
N_TTY_BUF_SIZE, and if n_tty has some off-by-one error, that would explain
it.
Does the problem go away if you change the default value of chunk (in
drivers/char/tty_io.c:do_tty_write) from 4096 to 2048? If so, that means
that the pty code has _claimed_ to have written 4kB, and only ever wrote
4kB-1 bytes. That in turn implies that ldisc.receive_room() disagrees
with ldisc.receive_buf().
The problem also goes away after unsetting ECHO on the slave terminal.
This seems to point to this code in n_tty_receive_char():
if (L_ECHO(tty)) {
if (tty-read_cnt = N_TTY_BUF_SIZE-1) {
put_char('\a', tty); /* beep if no space */
return;
}
...
}
This code sets the maximum number of buffered characters to
N_TTY_BUF_SIZE-1, however, put_tty_queue() considers the maximum to be
N_TTY_BUF_SIZE, and n_tty_receive_room() also returns N_TTY_BUF_SIZE for
canonical mode if the canon_data buffer is empty - therefore after
unsetting ECHO bytes are no longer lost.
BTW, for the noncanonical mode n_tty_receive_room() calculates the
result assuming that the buffer can hold at most N_TTY_BUF_SIZE-1
characters - not the full N_TTY_BUF_SIZE.
pgpxnDQSGHPVE.pgp
Description: PGP signature
Re: Pty is losing bytes
On Tue, Feb 15, 2005 at 10:58:02PM +0300, Sergey Vlasov wrote:
On Tue, 15 Feb 2005 11:08:07 -0800 (PST) Linus Torvalds wrote:
On Tue, 15 Feb 2005, Andreas Schwab wrote:
Recent kernel are losing bytes on a pty.
Great catch.
I think it may be a n_tty line discipline bug, brought on by the fact that
the PTY buffering is now 4kB rather than 2kB. 4kB is also the
N_TTY_BUF_SIZE, and if n_tty has some off-by-one error, that would explain
it.
Does the problem go away if you change the default value of chunk (in
drivers/char/tty_io.c:do_tty_write) from 4096 to 2048? If so, that means
that the pty code has _claimed_ to have written 4kB, and only ever wrote
4kB-1 bytes. That in turn implies that ldisc.receive_room() disagrees
with ldisc.receive_buf().
The problem also goes away after unsetting ECHO on the slave terminal.
This seems to point to this code in n_tty_receive_char():
if (L_ECHO(tty)) {
if (tty-read_cnt = N_TTY_BUF_SIZE-1) {
put_char('\a', tty); /* beep if no space */
return;
}
...
}
This code sets the maximum number of buffered characters to
N_TTY_BUF_SIZE-1, however, put_tty_queue() considers the maximum to be
N_TTY_BUF_SIZE, and n_tty_receive_room() also returns N_TTY_BUF_SIZE for
canonical mode if the canon_data buffer is empty - therefore after
unsetting ECHO bytes are no longer lost.
But all this really is not important, because n_tty_receive_char() can
put more than one char into buffer for a single input char in lots of
cases. Therefore n_tty_receive_room() can overestimate the available
space at least by 2 times.
pgpFTJQt2jdWs.pgp
Description: PGP signature
[PATCH 2.6 2/2] Fix documentation build failure
Hello!
In linux-2.6.11-rc4-bk2 building of the documentation (make htmldocs)
fails on "DOCPROC Documentation/DocBook/kernel-api.sgml" because of
these errors:
Error(/home/vsu/src/linux-2.6.11-rc4-bk2/include/linux/skbuff.h:936): cannot
understand prototype: '#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB '
Error(/home/vsu/src/linux-2.6.11-rc4-bk2/drivers/video/fbmem.c:1265): cannot
understand prototype: 'const char *global_mode_option; '
This patch fixes htmldocs build failure on drivers/video/fbmem.c.
I think this patch (or an equivalent one) should be merged before the
2.6.11 release.
Signed-off-by: Sergey Vlasov <[EMAIL PROTECTED]>
--- linux-2.6.11-rc4-bk2/drivers/video/fbmem.c.doc-build2005-02-14
20:12:33 +0300
+++ linux-2.6.11-rc4-bk2/drivers/video/fbmem.c 2005-02-14 23:02:45 +0300
@@ -1261,9 +1261,6 @@ int fb_get_options(char *name, char **op
* Returns zero.
*
*/
-
-extern const char *global_mode_option;
-
int __init video_setup(char *options)
{
int i, global = 0;
@@ -1277,6 +1274,8 @@ int __init video_setup(char *options)
}
if (!global && !strstr(options, "fb:")) {
+ extern const char *global_mode_option;
+
global_mode_option = options;
global = 1;
}
--
Sergey Vlasov
pgpIUk3jjoOpJ.pgp
Description: PGP signature
[PATCH 2.6 1/2] Fix documentation build failure
Hello!
In linux-2.6.11-rc4-bk2 building of the documentation (make htmldocs)
fails on "DOCPROC Documentation/DocBook/kernel-api.sgml" because of
these errors:
Error(/home/vsu/src/linux-2.6.11-rc4-bk2/include/linux/skbuff.h:936): cannot
understand prototype: '#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB '
Error(/home/vsu/src/linux-2.6.11-rc4-bk2/drivers/video/fbmem.c:1265): cannot
understand prototype: 'const char *global_mode_option; '
This patch fixes htmldocs build failure on include/linux/skbuff.h; it
does not change any code. I think this patch should be merged before
the 2.6.11 release.
Signed-off-by: Sergey Vlasov <[EMAIL PROTECTED]>
--- linux-2.6.11-rc4-bk2/include/linux/skbuff.h.doc-build 2005-02-14
20:12:37 +0300
+++ linux-2.6.11-rc4-bk2/include/linux/skbuff.h 2005-02-14 22:46:20 +0300
@@ -921,6 +921,7 @@ static inline void __skb_queue_purge(str
kfree_skb(skb);
}
+#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB
/**
* __dev_alloc_skb - allocate an skbuff for sending
* @length: length to allocate
@@ -933,7 +934,6 @@ static inline void __skb_queue_purge(str
*
* %NULL is returned in there is no free memory.
*/
-#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB
static inline struct sk_buff *__dev_alloc_skb(unsigned int length,
int gfp_mask)
{
--
Sergey Vlasov
pgpbtPVrs4DNj.pgp
Description: PGP signature
[PATCH 2.6 1/2] Fix documentation build failure
Hello!
In linux-2.6.11-rc4-bk2 building of the documentation (make htmldocs)
fails on DOCPROC Documentation/DocBook/kernel-api.sgml because of
these errors:
Error(/home/vsu/src/linux-2.6.11-rc4-bk2/include/linux/skbuff.h:936): cannot
understand prototype: '#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB '
Error(/home/vsu/src/linux-2.6.11-rc4-bk2/drivers/video/fbmem.c:1265): cannot
understand prototype: 'const char *global_mode_option; '
This patch fixes htmldocs build failure on include/linux/skbuff.h; it
does not change any code. I think this patch should be merged before
the 2.6.11 release.
Signed-off-by: Sergey Vlasov [EMAIL PROTECTED]
--- linux-2.6.11-rc4-bk2/include/linux/skbuff.h.doc-build 2005-02-14
20:12:37 +0300
+++ linux-2.6.11-rc4-bk2/include/linux/skbuff.h 2005-02-14 22:46:20 +0300
@@ -921,6 +921,7 @@ static inline void __skb_queue_purge(str
kfree_skb(skb);
}
+#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB
/**
* __dev_alloc_skb - allocate an skbuff for sending
* @length: length to allocate
@@ -933,7 +934,6 @@ static inline void __skb_queue_purge(str
*
* %NULL is returned in there is no free memory.
*/
-#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB
static inline struct sk_buff *__dev_alloc_skb(unsigned int length,
int gfp_mask)
{
--
Sergey Vlasov
pgpbtPVrs4DNj.pgp
Description: PGP signature
[PATCH 2.6 2/2] Fix documentation build failure
Hello!
In linux-2.6.11-rc4-bk2 building of the documentation (make htmldocs)
fails on DOCPROC Documentation/DocBook/kernel-api.sgml because of
these errors:
Error(/home/vsu/src/linux-2.6.11-rc4-bk2/include/linux/skbuff.h:936): cannot
understand prototype: '#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB '
Error(/home/vsu/src/linux-2.6.11-rc4-bk2/drivers/video/fbmem.c:1265): cannot
understand prototype: 'const char *global_mode_option; '
This patch fixes htmldocs build failure on drivers/video/fbmem.c.
I think this patch (or an equivalent one) should be merged before the
2.6.11 release.
Signed-off-by: Sergey Vlasov [EMAIL PROTECTED]
--- linux-2.6.11-rc4-bk2/drivers/video/fbmem.c.doc-build2005-02-14
20:12:33 +0300
+++ linux-2.6.11-rc4-bk2/drivers/video/fbmem.c 2005-02-14 23:02:45 +0300
@@ -1261,9 +1261,6 @@ int fb_get_options(char *name, char **op
* Returns zero.
*
*/
-
-extern const char *global_mode_option;
-
int __init video_setup(char *options)
{
int i, global = 0;
@@ -1277,6 +1274,8 @@ int __init video_setup(char *options)
}
if (!global !strstr(options, fb:)) {
+ extern const char *global_mode_option;
+
global_mode_option = options;
global = 1;
}
--
Sergey Vlasov
pgpIUk3jjoOpJ.pgp
Description: PGP signature
Re: [RFC UPDATE PATCH] add wait_event_*_lock() functions and comments
On Sat, 12 Feb 2005 12:38:26 +0100 Arnd Bergmann wrote:
> On Freedag 11 Februar 2005 20:55, Nishanth Aravamudan wrote:
>
> > + * If the macro name contains:
> > + * lock, then @lock should be held before calling wait_event*().
> > + * It is released before sleeping and grabbed after
> > + * waking, saving the current IRQ mask in @flags. This lock
> > + * should also be held when changing any variables
> > + * affecting the condition and when waking up the process.
>
> Hmm, I see two problems with that approach:
>
> 1. It might lead to people not thinking about their locking order
> thoroughly if you introduce a sleeping function that is called with
> a spinlock held. Anyone relying on that lock introduces races because
> it actually is given up by the macro. I'd prefer it to be called
> without the lock and then have it acquire the lock only to check the
> condition, e.g:
>
> #define __wait_event_lock(wq, condition, lock, flags) \
> do { \
>DEFINE_WAIT(__wait);\
>\
>for (;;) { \
>prepare_to_wait(, &__wait, TASK_UNINTERRUPTIBLE);\
>spin_lock_irqsave(lock, flags); \
>if (condition) \
>break; \
>spin_unlock_irqrestore(lock, flags);\
>schedule(); \
>} \
>spin_unlock_irqrestore(lock, flags);\
>finish_wait(, &__wait); \
> } while (0)
But in this case the result of testing the condition becomes useless
after spin_unlock_irqrestore - someone might grab the lock and change
things. Therefore the calling code would need to add a loop around
wait_event_lock - and the wait_event_* macros were added precisely to
encapsulate such a loop and avoid the need to code it manually.
pgpWr8tJ7VL0F.pgp
Description: PGP signature
Re: [RFC UPDATE PATCH] add wait_event_*_lock() functions and comments
On Sat, 12 Feb 2005 12:38:26 +0100 Arnd Bergmann wrote:
On Freedag 11 Februar 2005 20:55, Nishanth Aravamudan wrote:
+ * If the macro name contains:
+ * lock, then @lock should be held before calling wait_event*().
+ * It is released before sleeping and grabbed after
+ * waking, saving the current IRQ mask in @flags. This lock
+ * should also be held when changing any variables
+ * affecting the condition and when waking up the process.
Hmm, I see two problems with that approach:
1. It might lead to people not thinking about their locking order
thoroughly if you introduce a sleeping function that is called with
a spinlock held. Anyone relying on that lock introduces races because
it actually is given up by the macro. I'd prefer it to be called
without the lock and then have it acquire the lock only to check the
condition, e.g:
#define __wait_event_lock(wq, condition, lock, flags) \
do { \
DEFINE_WAIT(__wait);\
\
for (;;) { \
prepare_to_wait(wq, __wait, TASK_UNINTERRUPTIBLE);\
spin_lock_irqsave(lock, flags); \
if (condition) \
break; \
spin_unlock_irqrestore(lock, flags);\
schedule(); \
} \
spin_unlock_irqrestore(lock, flags);\
finish_wait(wq, __wait); \
} while (0)
But in this case the result of testing the condition becomes useless
after spin_unlock_irqrestore - someone might grab the lock and change
things. Therefore the calling code would need to add a loop around
wait_event_lock - and the wait_event_* macros were added precisely to
encapsulate such a loop and avoid the need to code it manually.
pgpWr8tJ7VL0F.pgp
Description: PGP signature
Re: System beeper - no sound from mobo's own speaker
On Sun, 23 Jan 2005 19:37:53 + Stephen Kitchener wrote: > I seem to have a problem that, in that when I am using the kernel supplied > with Mandrake 10.0 and 10.1 and also fedora 3, there seems to be a distinct > lack of beeps coming from the system, once it is up and running. I am NOT > talking about sounds that might be coming from any sound card that might be > connected to the system, but the plain old speaker that sits in the PC case. Does "modprobe pcspkr" help? In 2.6.x kernels the PC speaker support can be built as a loadable module; probably the startup scripts do not load it automatically. pgpdBKge1ndhx.pgp Description: PGP signature
Re: kernel oops!
On Sat, 22 Jan 2005 22:43:50 -0800 (PST) Linus Torvalds wrote: > Interesting. That last call trace entry is the call in > pty_chars_in_buffer() to > > /* The ldisc must report 0 if no characters available to be read */ > count = to->ldisc.chars_in_buffer(to); > > and it looks like it has jumped to address zero. > > However, we _just_ compared the fn pointer to zero immediately before, and > while there could certainly have been a race that cleared it in between > the test and the call, normally we wouldn't even have re-loaded the value > at all, but kept it in a register instead. > > That said, it does act like a race. Somebody clearing the ldisc and racing > with somebody using it? > > Can you do a > > gdb vmlinux > > disassemble pty_chars_in_buffer > > to show what it looks like (whether it reloads the value, and what the > registers are - it looks like either %eax or %edi is all zeroes, but I'd > like to verify that it matches your code generation). > > Alan? Any ideas? The tty_select() path seems to take a ldisc reference, > but does that guarantee that the ldisc won't _change_? tty_poll() grabs ldisc reference for the tty it was called with; however, in this case pty_chars_in_buffer() accesses another ldisc (tty->link->ldisc) without grabbing a reference to it. BTW, many other pty_* functions do the same thing. Is calling tty_ldisc_ref(tty->link) safe here? There is a comment warning about possible deadlocks before pty_write(). pgprNeK4PSxNY.pgp Description: PGP signature
Re: kernel oops!
On Sat, 22 Jan 2005 22:43:50 -0800 (PST) Linus Torvalds wrote: Interesting. That last call trace entry is the call in pty_chars_in_buffer() to /* The ldisc must report 0 if no characters available to be read */ count = to-ldisc.chars_in_buffer(to); and it looks like it has jumped to address zero. However, we _just_ compared the fn pointer to zero immediately before, and while there could certainly have been a race that cleared it in between the test and the call, normally we wouldn't even have re-loaded the value at all, but kept it in a register instead. That said, it does act like a race. Somebody clearing the ldisc and racing with somebody using it? Can you do a gdb vmlinux disassemble pty_chars_in_buffer to show what it looks like (whether it reloads the value, and what the registers are - it looks like either %eax or %edi is all zeroes, but I'd like to verify that it matches your code generation). Alan? Any ideas? The tty_select() path seems to take a ldisc reference, but does that guarantee that the ldisc won't _change_? tty_poll() grabs ldisc reference for the tty it was called with; however, in this case pty_chars_in_buffer() accesses another ldisc (tty-link-ldisc) without grabbing a reference to it. BTW, many other pty_* functions do the same thing. Is calling tty_ldisc_ref(tty-link) safe here? There is a comment warning about possible deadlocks before pty_write(). pgprNeK4PSxNY.pgp Description: PGP signature
Re: System beeper - no sound from mobo's own speaker
On Sun, 23 Jan 2005 19:37:53 + Stephen Kitchener wrote: I seem to have a problem that, in that when I am using the kernel supplied with Mandrake 10.0 and 10.1 and also fedora 3, there seems to be a distinct lack of beeps coming from the system, once it is up and running. I am NOT talking about sounds that might be coming from any sound card that might be connected to the system, but the plain old speaker that sits in the PC case. Does modprobe pcspkr help? In 2.6.x kernels the PC speaker support can be built as a loadable module; probably the startup scripts do not load it automatically. pgpdBKge1ndhx.pgp Description: PGP signature
Re: permissions of /proc/tty/driver
On Sun, 16 Jan 2005 14:13:46 +0100, Thomas Viehmann wrote: > Christoph Hellwig wrote: >> Counter-question: What information is available in >> /proc/tty/driver/usbserial but not in sysfs? > > Thanks for this hint, is there a way of finding vendor and product ids > of all ttyUSB devices better than > looking for /sys/bus/usb/devices/*-*/*-*:*/ttyUSB* and then ckecking the > obvious files in the grandparent directory? /sys/bus/usb-serial/devices/* looks like what you need... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: permissions of /proc/tty/driver
On Sun, 16 Jan 2005 14:13:46 +0100, Thomas Viehmann wrote: Christoph Hellwig wrote: Counter-question: What information is available in /proc/tty/driver/usbserial but not in sysfs? Thanks for this hint, is there a way of finding vendor and product ids of all ttyUSB devices better than looking for /sys/bus/usb/devices/*-*/*-*:*/ttyUSB* and then ckecking the obvious files in the grandparent directory? /sys/bus/usb-serial/devices/* looks like what you need... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
