Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
Paul Mackerras schrieb: Andrew Morton writes: Bizarrely, the original author of the patch (Anton) has fallen off the cc. Could whoever did that please thwap himself? Anyway, my head is now officially spinning. Did anyone actually have a reason why we shouldn't proceed with Anton's patch? I was wondering if it would be sufficient to provide alternative versions of fb_readl, fb_writel etc. that do byte-swapping. That would mean that all framebuffers would have to have the same endianness, but that would suffice for embedded systems such as Anton's and would end up a lot simpler IMHO. Yes. At least the affected PowerPC platforms can do byte-swapping on the fly, so this should be sufficient and without performance penalty, AFAICS. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
Paul Mackerras schrieb: Andrew Morton writes: Bizarrely, the original author of the patch (Anton) has fallen off the cc. Could whoever did that please thwap himself? Anyway, my head is now officially spinning. Did anyone actually have a reason why we shouldn't proceed with Anton's patch? I was wondering if it would be sufficient to provide alternative versions of fb_readl, fb_writel etc. that do byte-swapping. That would mean that all framebuffers would have to have the same endianness, but that would suffice for embedded systems such as Anton's and would end up a lot simpler IMHO. Yes. At least the affected PowerPC platforms can do byte-swapping on the fly, so this should be sufficient and without performance penalty, AFAICS. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
Andrew Morton schrieb: On Tue, 19 Feb 2008 12:27:54 +0100 Clemens Koller <[EMAIL PROTECTED]> wrote: Benjamin Herrenschmidt schrieb: On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote: [EMAIL PROTECTED] schrieb: On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said: I know two fb drivers which use endianess information (pm2fb and s3c2410fb). Both resolve endianess at driver level. Actually, both handle it by setting special bits so the graphics chip itself reorder bytes to transform foreign endianess. I understand that this patch is for chips which cannot reorder bytes by themselves. Does anybody know of such a chip that's actually available in the wild? Or are we writing drivers for speculative possible chips? I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC PCI vs. LocalBus. The chip also has a register to swap endianess, but that seems to only affect some LocalBus modes. The current fb and X drivers are working, but when it comes to font aliasing and hw-acceleration, the problems start to rise again... Most "sane" gfx chips nowadays provide configurable surfaces that allow to perform the swap when writing/reading from regions of the framebuffer, with the ability to set a different swapper setting (based on bit depth) per region. Most! But not the SM50x. I still hope I would be wrong here. :-( Then there is also the risk that your PCI<->Localbus has been wired improperly :-) That's not an issue in my case. The SM50x can be connected to either an PCI or some Local/CPU-whateverbus IF. I.e. on the MPC85xx PowerPC, PCI and LocalBus are separate bussses. If the sm501 is attached to the MPC85xx' PCI like any other video card, the PCI config-space is can be accessed as usual, whereas the framebuffer memory area is byte-swapped compared to other common video cards. So, to get back on topic: I would welcome endianess swapping in SW. Some architectures (PowerPC) should also be able to do swapped-endian mmapping. I just haven't had time for a closer look but it looks also interesting way to do it that way. Bizarrely, the original author of the patch (Anton) has fallen off the cc. Could whoever did that please thwap himself? Propably my bad, being subscribed to several CCed lists... Anyway, my head is now officially spinning. Did anyone actually have a reason why we shouldn't proceed with Anton's patch? Since it seem that there are some odd chips out in the wild, I guess Valdis (also readded to CC:) has no more objections to give it a try. :-) Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is Infineon PEB 3332 EL supported in Linux?
CIJOML schrieb: Hi there, I would like flash my D-link DVG-G1402S with linux ADM5120 port. It should be possible, but I would like still use it as a SIP gateway. There is Infineon PEB 3332 EL responsible for that job, so my question is if it is supported. BTW this router's internals photos are there: Quick answer: No. The VINETIC-CPE (PEB3332EL) is doing the analog voice processing and needs DSP firmware as well as device drivers provided by Infineon. I don't think you will get this stuff from Infineon easily. But you can try to extract it from the current D-link firmware. YMMV. I could ask a friend who is working on the DSL-Chipsets at Infineon about their code/driver policy/availability. Ping me off-list in 2 weeks, he is on holiday right now. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
Benjamin Herrenschmidt schrieb: On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote: [EMAIL PROTECTED] schrieb: On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said: I know two fb drivers which use endianess information (pm2fb and s3c2410fb). Both resolve endianess at driver level. Actually, both handle it by setting special bits so the graphics chip itself reorder bytes to transform foreign endianess. I understand that this patch is for chips which cannot reorder bytes by themselves. Does anybody know of such a chip that's actually available in the wild? Or are we writing drivers for speculative possible chips? I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC PCI vs. LocalBus. The chip also has a register to swap endianess, but that seems to only affect some LocalBus modes. The current fb and X drivers are working, but when it comes to font aliasing and hw-acceleration, the problems start to rise again... Most "sane" gfx chips nowadays provide configurable surfaces that allow to perform the swap when writing/reading from regions of the framebuffer, with the ability to set a different swapper setting (based on bit depth) per region. Most! But not the SM50x. I still hope I would be wrong here. :-( Then there is also the risk that your PCI<->Localbus has been wired improperly :-) That's not an issue in my case. The SM50x can be connected to either an PCI or some Local/CPU-whateverbus IF. I.e. on the MPC85xx PowerPC, PCI and LocalBus are separate bussses. If the sm501 is attached to the MPC85xx' PCI like any other video card, the PCI config-space is can be accessed as usual, whereas the framebuffer memory area is byte-swapped compared to other common video cards. So, to get back on topic: I would welcome endianess swapping in SW. Some architectures (PowerPC) should also be able to do swapped-endian mmapping. I just haven't had time for a closer look but it looks also interesting way to do it that way. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
Benjamin Herrenschmidt schrieb: On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote: [EMAIL PROTECTED] schrieb: On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said: I know two fb drivers which use endianess information (pm2fb and s3c2410fb). Both resolve endianess at driver level. Actually, both handle it by setting special bits so the graphics chip itself reorder bytes to transform foreign endianess. I understand that this patch is for chips which cannot reorder bytes by themselves. Does anybody know of such a chip that's actually available in the wild? Or are we writing drivers for speculative possible chips? I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC PCI vs. LocalBus. The chip also has a register to swap endianess, but that seems to only affect some LocalBus modes. The current fb and X drivers are working, but when it comes to font aliasing and hw-acceleration, the problems start to rise again... Most sane gfx chips nowadays provide configurable surfaces that allow to perform the swap when writing/reading from regions of the framebuffer, with the ability to set a different swapper setting (based on bit depth) per region. Most! But not the SM50x. I still hope I would be wrong here. :-( Then there is also the risk that your PCI-Localbus has been wired improperly :-) That's not an issue in my case. The SM50x can be connected to either an PCI or some Local/CPU-whateverbus IF. I.e. on the MPC85xx PowerPC, PCI and LocalBus are separate bussses. If the sm501 is attached to the MPC85xx' PCI like any other video card, the PCI config-space is can be accessed as usual, whereas the framebuffer memory area is byte-swapped compared to other common video cards. So, to get back on topic: I would welcome endianess swapping in SW. Some architectures (PowerPC) should also be able to do swapped-endian mmapping. I just haven't had time for a closer look but it looks also interesting way to do it that way. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
Andrew Morton schrieb: On Tue, 19 Feb 2008 12:27:54 +0100 Clemens Koller [EMAIL PROTECTED] wrote: Benjamin Herrenschmidt schrieb: On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote: [EMAIL PROTECTED] schrieb: On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said: I know two fb drivers which use endianess information (pm2fb and s3c2410fb). Both resolve endianess at driver level. Actually, both handle it by setting special bits so the graphics chip itself reorder bytes to transform foreign endianess. I understand that this patch is for chips which cannot reorder bytes by themselves. Does anybody know of such a chip that's actually available in the wild? Or are we writing drivers for speculative possible chips? I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC PCI vs. LocalBus. The chip also has a register to swap endianess, but that seems to only affect some LocalBus modes. The current fb and X drivers are working, but when it comes to font aliasing and hw-acceleration, the problems start to rise again... Most sane gfx chips nowadays provide configurable surfaces that allow to perform the swap when writing/reading from regions of the framebuffer, with the ability to set a different swapper setting (based on bit depth) per region. Most! But not the SM50x. I still hope I would be wrong here. :-( Then there is also the risk that your PCI-Localbus has been wired improperly :-) That's not an issue in my case. The SM50x can be connected to either an PCI or some Local/CPU-whateverbus IF. I.e. on the MPC85xx PowerPC, PCI and LocalBus are separate bussses. If the sm501 is attached to the MPC85xx' PCI like any other video card, the PCI config-space is can be accessed as usual, whereas the framebuffer memory area is byte-swapped compared to other common video cards. So, to get back on topic: I would welcome endianess swapping in SW. Some architectures (PowerPC) should also be able to do swapped-endian mmapping. I just haven't had time for a closer look but it looks also interesting way to do it that way. Bizarrely, the original author of the patch (Anton) has fallen off the cc. Could whoever did that please thwap himself? Propably my bad, being subscribed to several CCed lists... Anyway, my head is now officially spinning. Did anyone actually have a reason why we shouldn't proceed with Anton's patch? Since it seem that there are some odd chips out in the wild, I guess Valdis (also readded to CC:) has no more objections to give it a try. :-) Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is Infineon PEB 3332 EL supported in Linux?
CIJOML schrieb: Hi there, I would like flash my D-link DVG-G1402S with linux ADM5120 port. It should be possible, but I would like still use it as a SIP gateway. There is Infineon PEB 3332 EL responsible for that job, so my question is if it is supported. BTW this router's internals photos are there: Quick answer: No. The VINETIC-CPE (PEB3332EL) is doing the analog voice processing and needs DSP firmware as well as device drivers provided by Infineon. I don't think you will get this stuff from Infineon easily. But you can try to extract it from the current D-link firmware. YMMV. I could ask a friend who is working on the DSL-Chipsets at Infineon about their code/driver policy/availability. Ping me off-list in 2 weeks, he is on holiday right now. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
[EMAIL PROTECTED] schrieb: On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said: I know two fb drivers which use endianess information (pm2fb and s3c2410fb). Both resolve endianess at driver level. Actually, both handle it by setting special bits so the graphics chip itself reorder bytes to transform foreign endianess. I understand that this patch is for chips which cannot reorder bytes by themselves. Does anybody know of such a chip that's actually available in the wild? Or are we writing drivers for speculative possible chips? I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC PCI vs. LocalBus. The chip also has a register to swap endianess, but that seems to only affect some LocalBus modes. The current fb and X drivers are working, but when it comes to font aliasing and hw-acceleration, the problems start to rise again... Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
[EMAIL PROTECTED] schrieb: On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said: I know two fb drivers which use endianess information (pm2fb and s3c2410fb). Both resolve endianess at driver level. Actually, both handle it by setting special bits so the graphics chip itself reorder bytes to transform foreign endianess. I understand that this patch is for chips which cannot reorder bytes by themselves. Does anybody know of such a chip that's actually available in the wild? Or are we writing drivers for speculative possible chips? I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC PCI vs. LocalBus. The chip also has a register to swap endianess, but that seems to only affect some LocalBus modes. The current fb and X drivers are working, but when it comes to font aliasing and hw-acceleration, the problems start to rise again... Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2
Andrew Morton schrieb: On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak <[EMAIL PROTECTED]> wrote: The second util-linux-ng 2.13.1 release candidate is available at ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/ Interesting. Thanks. Which distros are using this, or plan to do so? We (CRUX community, http://crux.nu ) just switched to the -ng. The old non -ng version doesn't seem to be maintained well. Regards, -- Clemens Koller ___ R Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2
Andrew Morton schrieb: On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak [EMAIL PROTECTED] wrote: The second util-linux-ng 2.13.1 release candidate is available at ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/ Interesting. Thanks. Which distros are using this, or plan to do so? We (CRUX community, http://crux.nu ) just switched to the -ng. The old non -ng version doesn't seem to be maintained well. Regards, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
What's this __dummy in asm-cris/bitops.h?
Hello,
while looking for some assembly out of order / optimization stuff
for something else, I found some strange code in
.../linux/include/asm-cris/bitops.h:22
/*
* Some hacks to defeat gcc over-optimizations..
*/
struct __dummy { unsigned long a[100]; };
#define ADDR (*(struct __dummy *) addr)
#define CONST_ADDR (*(const struct __dummy *) addr)
CONST_ADDR is never used in the kernel.
Maybe some -cris people could have a look.
Thanks,
--
Clemens Koller
__
R Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
What's this __dummy in asm-cris/bitops.h?
Hello,
while looking for some assembly out of order / optimization stuff
for something else, I found some strange code in
.../linux/include/asm-cris/bitops.h:22
/*
* Some hacks to defeat gcc over-optimizations..
*/
struct __dummy { unsigned long a[100]; };
#define ADDR (*(struct __dummy *) addr)
#define CONST_ADDR (*(const struct __dummy *) addr)
CONST_ADDR is never used in the kernel.
Maybe some -cris people could have a look.
Thanks,
--
Clemens Koller
__
RD Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: printf internals
David Newall schrieb: > Siva Prasad wrote: >> I am looking at how exactly does the printf in user programs succeeds in >> displaying characters to the serial console. > > Is it a student assignment? This is so not the right mailing list. Come on, are we playing hide and seek here? You can use strace to follow a typical hello world example and see what device it opens to feed the hello out. I.e. it can be to the current /dev/ttyX and not to /dev/console or if you are logged in via SSH to a machine, the device is again different... or if you use screen, ... Work your way from there and then use a Linux Source code Cross Reference (lxr, ask Google for one) and follow the code. Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: printf internals
David Newall schrieb: Siva Prasad wrote: I am looking at how exactly does the printf in user programs succeeds in displaying characters to the serial console. Is it a student assignment? This is so not the right mailing list. Come on, are we playing hide and seek here? You can use strace to follow a typical hello world example and see what device it opens to feed the hello out. I.e. it can be to the current /dev/ttyX and not to /dev/console or if you are logged in via SSH to a machine, the device is again different... or if you use screen, ... Work your way from there and then use a Linux Source code Cross Reference (lxr, ask Google for one) and follow the code. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi_wait_scan Kconfig option
Nick Warne schrieb: I am bringing this up again - primarily as I forgot about it after patching my build tree ages ago: http://lkml.org/lkml/2007/10/27/68 Please see the patch I sent some days ago, which does the very same thing: http://marc.info/?l=linux-kernel=119677244318528=2 I would extend the help text a bit more to make clear what it really does, since there is not much documentation around. I try not to build a modular kernel, but only have modules ON due to nVidia (sigh). So I was semi-surprised when I saw the scsi_wait_scan module being built again, yet NO WHERE in menuconfig is it present to turn OFF. Even if I hand edit .config, make puts it back again... True... Regards, -- Clemens Koller ___ R Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi_wait_scan Kconfig option
Nick Warne schrieb: I am bringing this up again - primarily as I forgot about it after patching my build tree ages ago: http://lkml.org/lkml/2007/10/27/68 Please see the patch I sent some days ago, which does the very same thing: http://marc.info/?l=linux-kernelm=119677244318528w=2 I would extend the help text a bit more to make clear what it really does, since there is not much documentation around. I try not to build a modular kernel, but only have modules ON due to nVidia (sigh). So I was semi-surprised when I saw the scsi_wait_scan module being built again, yet NO WHERE in menuconfig is it present to turn OFF. Even if I hand edit .config, make puts it back again... True... Regards, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Allow to disable CONFIG_SCSI_WAIT_SCAN=m in menuconfig.
Hi there! This was already discussed in May: http://lkml.org/lkml/2007/5/13/75 without any valuable results. I don't want to have the scsi_wait_scan.ko around but still need SCSI for usb disks and module support for driver development. Otherwise, I am working with a monolithic kernel on embedded machines. The attached patch is another try to at least allow to get rid of this module. Feedback is welcome. Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com Allow to disable to build the scsi_wait_scan.ko module if not needed. Signed-off-by: Clemens Koller <[EMAIL PROTECTED]> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index a6676be..1dc452d 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -248,10 +248,19 @@ config SCSI_SCAN_ASYNC or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate "create module which waits for SCSI scanning to finish" default m depends on SCSI depends on MODULES + help + When this module is loaded, it will do nothing else than wait for + SCSI low-level drivers to finish asynchronous scanning for devices. + This module will be called scsi_wait_scan. + + It's default and safe to create this module even if it's not used + in your distro's init scripts. You can override this if you are + really sure you don't need or want it. It does not make sense to + compile this into the kernel with Y. menu "SCSI Transports" depends on SCSI
[PATCH] Allow to disable CONFIG_SCSI_WAIT_SCAN=m in menuconfig.
Hi there! This was already discussed in May: http://lkml.org/lkml/2007/5/13/75 without any valuable results. I don't want to have the scsi_wait_scan.ko around but still need SCSI for usb disks and module support for driver development. Otherwise, I am working with a monolithic kernel on embedded machines. The attached patch is another try to at least allow to get rid of this module. Feedback is welcome. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com Allow to disable to build the scsi_wait_scan.ko module if not needed. Signed-off-by: Clemens Koller [EMAIL PROTECTED] diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index a6676be..1dc452d 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -248,10 +248,19 @@ config SCSI_SCAN_ASYNC or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate create module which waits for SCSI scanning to finish default m depends on SCSI depends on MODULES + help + When this module is loaded, it will do nothing else than wait for + SCSI low-level drivers to finish asynchronous scanning for devices. + This module will be called scsi_wait_scan. + + It's default and safe to create this module even if it's not used + in your distro's init scripts. You can override this if you are + really sure you don't need or want it. It does not make sense to + compile this into the kernel with Y. menu SCSI Transports depends on SCSI
Re: [PATCH] Documentation/BUG-HUNTING whitespace cleanup, take 2
Randy Dunlap schrieb: > On Mon, 03 Dec 2007 14:33:29 +0100 Clemens Koller wrote: > >> Just a little whitespace cleanup patch for Documentation/BUG-HUNTING. >> >> Signed-off-by: Clemens Koller <[EMAIL PROTECTED]> > > > Mostly looks OK, except for the last chunk: why delete that line? > missing a + line? > > > @@ -130,7 +130,6 @@ You will then do: > that makes the difference. > > Finally, you take all the info that you have, kernel revisions, bug > -description, the extent to which you have narrowed it down, and pass > that off to whomever you believe is the maintainer of that section. > A post to linux.dev.kernel isn't such a bad idea if you've done some > work to narrow it down. Hmm... that was not intended, updated patch attached. Thank you, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com Just a little whitespace cleanup patch for Documentation/BUG-HUNTING Signed-off-by: Clemens Koller <[EMAIL PROTECTED]> diff --git a/Documentation/BUG-HUNTING b/Documentation/BUG-HUNTING index 35f5bd2..6c81675 100644 --- a/Documentation/BUG-HUNTING +++ b/Documentation/BUG-HUNTING @@ -53,7 +53,7 @@ Finding it the old way [Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO [EMAIL PROTECTED] (Larry McVoy)] -This is how to track down a bug if you know nothing about kernel hacking. +This is how to track down a bug if you know nothing about kernel hacking. It's a brute force approach but it works pretty well. You need: @@ -66,12 +66,12 @@ You will then do: . Rebuild a revision that you believe works, install, and verify that. . Do a binary search over the kernels to figure out which one - introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but + introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but you know that 1.3.69 does. Pick a kernel in the middle and build that, like 1.3.50. Build & test; if it works, pick the mid point between .50 and .69, else the mid point between .28 and .50. . You'll narrow it down to the kernel that introduced the bug. You - can probably do better than this but it gets tricky. + can probably do better than this but it gets tricky. . Narrow it down to a subdirectory @@ -81,27 +81,27 @@ You will then do: directories: Copy the non-working directory next to the working directory -as "dir.63". +as "dir.63". One directory at time, try moving the working directory to -"dir.62" and mv dir.63 dir"time, try +"dir.62" and mv dir.63 dir"time, try mv dir dir.62 mv dir.63 dir find dir -name '*.[oa]' -print | xargs rm -f And then rebuild and retest. Assuming that all related -changes were contained in the sub directory, this should -isolate the change to a directory. +changes were contained in the sub directory, this should +isolate the change to a directory. Problems: changes in header files may have occurred; I've -found in my case that they were self explanatory - you may +found in my case that they were self explanatory - you may or may not want to give up when that happens. . Narrow it down to a file - You can apply the same technique to each file in the directory, -hoping that the changes in that file are self contained. - +hoping that the changes in that file are self contained. + . Narrow it down to a routine - You can take the old file and the new file and manually create @@ -130,7 +130,7 @@ You will then do: that makes the difference. Finally, you take all the info that you have, kernel revisions, bug -description, the extent to which you have narrowed it down, and pass +description, the extent to which you have narrowed it down, and pass that off to whomever you believe is the maintainer of that section. A post to linux.dev.kernel isn't such a bad idea if you've done some work to narrow it down.
[PATCH] Documentation/BUG-HUNTING whitespace cleanup
Just a little whitespace cleanup patch for Documentation/BUG-HUNTING. Signed-off-by: Clemens Koller <[EMAIL PROTECTED]> -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com diff --git a/Documentation/BUG-HUNTING b/Documentation/BUG-HUNTING index 35f5bd2..a41cb24 100644 --- a/Documentation/BUG-HUNTING +++ b/Documentation/BUG-HUNTING @@ -53,7 +53,7 @@ Finding it the old way [Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO [EMAIL PROTECTED] (Larry McVoy)] -This is how to track down a bug if you know nothing about kernel hacking. +This is how to track down a bug if you know nothing about kernel hacking. It's a brute force approach but it works pretty well. You need: @@ -66,12 +66,12 @@ You will then do: . Rebuild a revision that you believe works, install, and verify that. . Do a binary search over the kernels to figure out which one - introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but + introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but you know that 1.3.69 does. Pick a kernel in the middle and build that, like 1.3.50. Build & test; if it works, pick the mid point between .50 and .69, else the mid point between .28 and .50. . You'll narrow it down to the kernel that introduced the bug. You - can probably do better than this but it gets tricky. + can probably do better than this but it gets tricky. . Narrow it down to a subdirectory @@ -81,27 +81,27 @@ You will then do: directories: Copy the non-working directory next to the working directory -as "dir.63". +as "dir.63". One directory at time, try moving the working directory to -"dir.62" and mv dir.63 dir"time, try +"dir.62" and mv dir.63 dir"time, try mv dir dir.62 mv dir.63 dir find dir -name '*.[oa]' -print | xargs rm -f And then rebuild and retest. Assuming that all related -changes were contained in the sub directory, this should -isolate the change to a directory. +changes were contained in the sub directory, this should +isolate the change to a directory. Problems: changes in header files may have occurred; I've -found in my case that they were self explanatory - you may +found in my case that they were self explanatory - you may or may not want to give up when that happens. . Narrow it down to a file - You can apply the same technique to each file in the directory, -hoping that the changes in that file are self contained. - +hoping that the changes in that file are self contained. + . Narrow it down to a routine - You can take the old file and the new file and manually create @@ -130,7 +130,6 @@ You will then do: that makes the difference. Finally, you take all the info that you have, kernel revisions, bug -description, the extent to which you have narrowed it down, and pass that off to whomever you believe is the maintainer of that section. A post to linux.dev.kernel isn't such a bad idea if you've done some work to narrow it down.
[PATCH] Documentation/BUG-HUNTING whitespace cleanup
Just a little whitespace cleanup patch for Documentation/BUG-HUNTING. Signed-off-by: Clemens Koller [EMAIL PROTECTED] -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com diff --git a/Documentation/BUG-HUNTING b/Documentation/BUG-HUNTING index 35f5bd2..a41cb24 100644 --- a/Documentation/BUG-HUNTING +++ b/Documentation/BUG-HUNTING @@ -53,7 +53,7 @@ Finding it the old way [Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO [EMAIL PROTECTED] (Larry McVoy)] -This is how to track down a bug if you know nothing about kernel hacking. +This is how to track down a bug if you know nothing about kernel hacking. It's a brute force approach but it works pretty well. You need: @@ -66,12 +66,12 @@ You will then do: . Rebuild a revision that you believe works, install, and verify that. . Do a binary search over the kernels to figure out which one - introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but + introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but you know that 1.3.69 does. Pick a kernel in the middle and build that, like 1.3.50. Build test; if it works, pick the mid point between .50 and .69, else the mid point between .28 and .50. . You'll narrow it down to the kernel that introduced the bug. You - can probably do better than this but it gets tricky. + can probably do better than this but it gets tricky. . Narrow it down to a subdirectory @@ -81,27 +81,27 @@ You will then do: directories: Copy the non-working directory next to the working directory -as dir.63. +as dir.63. One directory at time, try moving the working directory to -dir.62 and mv dir.63 dirtime, try +dir.62 and mv dir.63 dirtime, try mv dir dir.62 mv dir.63 dir find dir -name '*.[oa]' -print | xargs rm -f And then rebuild and retest. Assuming that all related -changes were contained in the sub directory, this should -isolate the change to a directory. +changes were contained in the sub directory, this should +isolate the change to a directory. Problems: changes in header files may have occurred; I've -found in my case that they were self explanatory - you may +found in my case that they were self explanatory - you may or may not want to give up when that happens. . Narrow it down to a file - You can apply the same technique to each file in the directory, -hoping that the changes in that file are self contained. - +hoping that the changes in that file are self contained. + . Narrow it down to a routine - You can take the old file and the new file and manually create @@ -130,7 +130,6 @@ You will then do: that makes the difference. Finally, you take all the info that you have, kernel revisions, bug -description, the extent to which you have narrowed it down, and pass that off to whomever you believe is the maintainer of that section. A post to linux.dev.kernel isn't such a bad idea if you've done some work to narrow it down.
Re: [PATCH] Documentation/BUG-HUNTING whitespace cleanup, take 2
Randy Dunlap schrieb: On Mon, 03 Dec 2007 14:33:29 +0100 Clemens Koller wrote: Just a little whitespace cleanup patch for Documentation/BUG-HUNTING. Signed-off-by: Clemens Koller [EMAIL PROTECTED] Mostly looks OK, except for the last chunk: why delete that line? missing a + line? @@ -130,7 +130,6 @@ You will then do: that makes the difference. Finally, you take all the info that you have, kernel revisions, bug -description, the extent to which you have narrowed it down, and pass that off to whomever you believe is the maintainer of that section. A post to linux.dev.kernel isn't such a bad idea if you've done some work to narrow it down. Hmm... that was not intended, updated patch attached. Thank you, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com Just a little whitespace cleanup patch for Documentation/BUG-HUNTING Signed-off-by: Clemens Koller [EMAIL PROTECTED] diff --git a/Documentation/BUG-HUNTING b/Documentation/BUG-HUNTING index 35f5bd2..6c81675 100644 --- a/Documentation/BUG-HUNTING +++ b/Documentation/BUG-HUNTING @@ -53,7 +53,7 @@ Finding it the old way [Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO [EMAIL PROTECTED] (Larry McVoy)] -This is how to track down a bug if you know nothing about kernel hacking. +This is how to track down a bug if you know nothing about kernel hacking. It's a brute force approach but it works pretty well. You need: @@ -66,12 +66,12 @@ You will then do: . Rebuild a revision that you believe works, install, and verify that. . Do a binary search over the kernels to figure out which one - introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but + introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but you know that 1.3.69 does. Pick a kernel in the middle and build that, like 1.3.50. Build test; if it works, pick the mid point between .50 and .69, else the mid point between .28 and .50. . You'll narrow it down to the kernel that introduced the bug. You - can probably do better than this but it gets tricky. + can probably do better than this but it gets tricky. . Narrow it down to a subdirectory @@ -81,27 +81,27 @@ You will then do: directories: Copy the non-working directory next to the working directory -as dir.63. +as dir.63. One directory at time, try moving the working directory to -dir.62 and mv dir.63 dirtime, try +dir.62 and mv dir.63 dirtime, try mv dir dir.62 mv dir.63 dir find dir -name '*.[oa]' -print | xargs rm -f And then rebuild and retest. Assuming that all related -changes were contained in the sub directory, this should -isolate the change to a directory. +changes were contained in the sub directory, this should +isolate the change to a directory. Problems: changes in header files may have occurred; I've -found in my case that they were self explanatory - you may +found in my case that they were self explanatory - you may or may not want to give up when that happens. . Narrow it down to a file - You can apply the same technique to each file in the directory, -hoping that the changes in that file are self contained. - +hoping that the changes in that file are self contained. + . Narrow it down to a routine - You can take the old file and the new file and manually create @@ -130,7 +130,7 @@ You will then do: that makes the difference. Finally, you take all the info that you have, kernel revisions, bug -description, the extent to which you have narrowed it down, and pass +description, the extent to which you have narrowed it down, and pass that off to whomever you believe is the maintainer of that section. A post to linux.dev.kernel isn't such a bad idea if you've done some work to narrow it down.
Re: HELP: Internal error: Oops: f5 [#1]
wuhm schrieb: Unable to handle kernel paging request at virtual address c3c0 pgd = c3a5c000 [c3c0] *pgd= Internal error: Oops: f5 [#1] Modules linked in: dm642 mv_sata ixp400_eth ixp400 dm642 is an out-of-tree module. Contact the author of that module. CPU: 0 PC is at .c2u_0cpynopld+0x8/0x24 LR is at mpeg_read+0x19c/0x35c [dm642] pc : []lr : []Tainted: P Your Kernel is tainted. The proprietary module seems to crash. You won't get help from us regarding this module. Please read: http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html Regards, -- Clemens Koller ___ R Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP: Internal error: Oops: f5 [#1]
wuhm schrieb: Unable to handle kernel paging request at virtual address c3c0 pgd = c3a5c000 [c3c0] *pgd= Internal error: Oops: f5 [#1] Modules linked in: dm642 mv_sata ixp400_eth ixp400 dm642 is an out-of-tree module. Contact the author of that module. CPU: 0 PC is at .c2u_0cpynopld+0x8/0x24 LR is at mpeg_read+0x19c/0x35c [dm642] pc : [c0106934]lr : [bf0c8a98]Tainted: P Your Kernel is tainted. The proprietary module seems to crash. You won't get help from us regarding this module. Please read: http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html Regards, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OT: Re: System reboot triggered by just reading a device file....!?
Hi, Roland! Please don't top-post. [EMAIL PROTECTED] schrieb: > > [was: it would be easy to disable the kernel watchdog] > thanks, but i know i could do this. Good. I was also curious and just checked again. The watchdog subsystem is by default _disabled_ in the kernel configuration. If you use some distro's kernel, where they turned it on, complain to them! If you turned it on yourself, you are really on your own... the Kconfig help there is IMO sufficient and very clear and, "If unsure, say N". Hmm... sorry?! > this thread is not meant to protect myself from this curiousity but it is meant > to protect others. it`s a trap. I guess I understand your position. But I don't see no way to improve the kernel in that point. Complain to the guys who enabled the watchdog / setup this trap for any reason. > i stepped into that. > now i know that trap, so i can easily sidestep. > it maybe very seldom that someone steps into this. > but it may happen and then someone will have trouble and spend time on this. > i think every admin can tell you about weird random reboots of his systems > which he cannot explain what was the reason for it. That's one possible way of "learning by doing suicide (tm);" > this maybe some of those reasons and this one could be avoided. > i`m thinking of something simple like echo "now you`re armed" > /dev/watchdog Read some details about watchdogs to get more background and why the watchdog is triggered so easily and why it's good this way. i.e: http://www.ganssle.com/watchdogs.pdf Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OT: Re: System reboot triggered by just reading a device file....!?
Hi, Roland! Please don't top-post. [EMAIL PROTECTED] schrieb: [was: it would be easy to disable the kernel watchdog] thanks, but i know i could do this. Good. I was also curious and just checked again. The watchdog subsystem is by default _disabled_ in the kernel configuration. If you use some distro's kernel, where they turned it on, complain to them! If you turned it on yourself, you are really on your own... the Kconfig help there is IMO sufficient and very clear and, If unsure, say N. Hmm... sorry?! this thread is not meant to protect myself from this curiousity but it is meant to protect others. it`s a trap. I guess I understand your position. But I don't see no way to improve the kernel in that point. Complain to the guys who enabled the watchdog / setup this trap for any reason. i stepped into that. now i know that trap, so i can easily sidestep. it maybe very seldom that someone steps into this. but it may happen and then someone will have trouble and spend time on this. i think every admin can tell you about weird random reboots of his systems which he cannot explain what was the reason for it. That's one possible way of learning by doing suicide (tm); this maybe some of those reasons and this one could be avoided. i`m thinking of something simple like echo now you`re armed /dev/watchdog Read some details about watchdogs to get more background and why the watchdog is triggered so easily and why it's good this way. i.e: http://www.ganssle.com/watchdogs.pdf Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: System reboot triggered by just reading a device file....!?
[EMAIL PROTECTED] schrieb: > [was: reading /dev/watchdog triggers reboot as intended] > need to change my own philosophy now, because i learned that reading isn`t harmless. ;) If you want to protect you from your curiosity (or from reading anything), you could just disable the watchdog in the kernel. See: Device Drivers -> Character devices -> Watchdog Timer Support -> ... Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: System reboot triggered by just reading a device file....!?
[EMAIL PROTECTED] schrieb: [was: reading /dev/watchdog triggers reboot as intended] need to change my own philosophy now, because i learned that reading isn`t harmless. ;) If you want to protect you from your curiosity (or from reading anything), you could just disable the watchdog in the kernel. See: Device Drivers - Character devices - Watchdog Timer Support - ... Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange delays / what usually happens every 10 min?
Chris Snook schrieb: > Florian Boelstler wrote: >> While running that test driver a delay of about 10ms _exactly_ occurs >> every 10 minutes. > > This is precisely the sort of thing that BIOS/firmware-level SMI > handlers do, particularly those that have monitoring or management > features. Try to determine if the kernel is doing anything during this > time. If the entire kernel seems to be frozen, talk to the people who > wrote the firmware. There is no such thing as BIOS on this MPC8540 embedded system. I guess he is also using some bootloader which just gives full control to the linux kernel. Florian: Check the IP route chache flushes, as Eric mentioned. I'm working on the MPC854x as well. If you send me your scripts, I can give them a run here to gather more information. (I'm about to update my kernels here) Regards, Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange delays / what usually happens every 10 min?
Chris Snook schrieb: Florian Boelstler wrote: While running that test driver a delay of about 10ms _exactly_ occurs every 10 minutes. This is precisely the sort of thing that BIOS/firmware-level SMI handlers do, particularly those that have monitoring or management features. Try to determine if the kernel is doing anything during this time. If the entire kernel seems to be frozen, talk to the people who wrote the firmware. There is no such thing as BIOS on this MPC8540 embedded system. I guess he is also using some bootloader which just gives full control to the linux kernel. Florian: Check the IP route chache flushes, as Eric mentioned. I'm working on the MPC854x as well. If you send me your scripts, I can give them a run here to gather more information. (I'm about to update my kernels here) Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Truecrypt in kernel ?
Michal Schmidt schrieb: > On Mon, 5 Nov 2007 20:42:39 -0500 > "Zurk Tech" <[EMAIL PROTECTED]> wrote: >> just wondering why the truecrypt module isnt in the mainline kernel ? >> its the only cross platform encrypted disk solution out there and it >> should be less of a chore to use it in linux...is there something >> wrong with the truecrypt kernel driver ? > > Two reasons: > The author hasn't sent patches. > It looks to me the license is incompatible with the GPLv2. Just FYI: http://www.truecrypt.org/license.php Regards, Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Truecrypt in kernel ?
Michal Schmidt schrieb: On Mon, 5 Nov 2007 20:42:39 -0500 Zurk Tech [EMAIL PROTECTED] wrote: just wondering why the truecrypt module isnt in the mainline kernel ? its the only cross platform encrypted disk solution out there and it should be less of a chore to use it in linux...is there something wrong with the truecrypt kernel driver ? Two reasons: The author hasn't sent patches. It looks to me the license is incompatible with the GPLv2. Just FYI: http://www.truecrypt.org/license.php Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: system stops sending IOs for long time
saeed bishara schrieb: > Hi, > I have a performance issue with my system that runs samba server, once > in a while (6 seconds) I see that the throughput falls almost to to > zero when doing read for large file. I'm running kernel 2.6.22.10. I > don't see this issue when using kernel 2.6.12. > > when observing the activity leds on my sata controller, I see that it > get off for about 1 second meaning no commands sent to the HDD for > that long time. I used the blktrace in order to have a look into the > IOs, and found that the system really stops sending commands for long > periods, here is the section of the blkparse that shows this problem: > 8,2012747 5.55000 328 D R 108068834 + 512 [smbd] > 8,2012748 5.55000 328 D R 108069346 + 512 [smbd] > 8,2012749 5.55000 328 D R 108069858 + 512 [smbd] > 8,2012750 5.55000 328 D R 108070370 + 512 [smbd] > 8,2012751 5.55000 328 U N [smbd] 5 > 8,2012752 5.55000 0 C R 108068834 + 512 [0] > 8,2012753 5.56000 0 C R 108069346 + 512 [0] > 8,2012754 5.57000 0 C R 108069858 + 512 [0] > 8,2012755 5.57000 0 C R 108070370 + 512 [0] > 8,2012756 6.57000 0 C R 108066786 + 512 [0] > 8,2012757 6.59000 328 Q R 108070882 + 8 [smbd] > 8,2012758 6.59000 328 G R 108070882 + 8 [smbd] > 8,2012759 6.59000 328 P N [smbd] > 8,2012760 6.59000 328 I R 108070882 + 8 [smbd] > 8,2012761 6.59000 328 Q R 108070890 + 8 [smbd] > 8,2012762 6.59000 328 M R 108070890 + 8 [smbd] > > any idea how to fix this issue? Not really. I've had a similar looking problem with a md raid-1 set of harddisks running 2.6.18. md0_raid1 took every 10 seconds all of the cpu blocking other stuff on the machine for some other 2 secons doing no disk writes. $ uname -a Linux rio 2.6.22.9 #1 Mon Oct 1 19:48:54 CEST 2007 i686 pentium3 i386 GNU/Linux $ lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) 00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) 00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) 00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0b.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 50) 00:0b.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 50) 00:0b.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51) 00:0c.0 Mass storage controller: Promise Technology, Inc. 20269 (rev 02) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G100 [Productiva] AGP (rev 01) The raid is on the Promise PDC20269 $ mdadm --misc --detail /dev/md0 /dev/md0: Version : 00.90.03 Creation Time : Sat Oct 29 20:51:41 2005 Raid Level : raid1 Array Size : 293049600 (279.47 GiB 300.08 GB) Used Dev Size : 293049600 (279.47 GiB 300.08 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Tue Oct 30 19:20:12 2007 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : b2d7f60d:008fa0df:136207f1:ae0e7a9e Events : 0.432306 Number Major Minor RaidDevice State 0 3310 active sync /dev/hde1 1 3411 active sync /dev/hdg1 I didn't dare to report a bug against the old kernel. I moved to 2.6.22.9 and the problem disappeared... Any ways to debug that (non-intrusive on a production machine)? Regards, Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: system stops sending IOs for long time
saeed bishara schrieb: Hi, I have a performance issue with my system that runs samba server, once in a while (6 seconds) I see that the throughput falls almost to to zero when doing read for large file. I'm running kernel 2.6.22.10. I don't see this issue when using kernel 2.6.12. when observing the activity leds on my sata controller, I see that it get off for about 1 second meaning no commands sent to the HDD for that long time. I used the blktrace in order to have a look into the IOs, and found that the system really stops sending commands for long periods, here is the section of the blkparse that shows this problem: 8,2012747 5.55000 328 D R 108068834 + 512 [smbd] 8,2012748 5.55000 328 D R 108069346 + 512 [smbd] 8,2012749 5.55000 328 D R 108069858 + 512 [smbd] 8,2012750 5.55000 328 D R 108070370 + 512 [smbd] 8,2012751 5.55000 328 U N [smbd] 5 8,2012752 5.55000 0 C R 108068834 + 512 [0] 8,2012753 5.56000 0 C R 108069346 + 512 [0] 8,2012754 5.57000 0 C R 108069858 + 512 [0] 8,2012755 5.57000 0 C R 108070370 + 512 [0] 8,2012756 6.57000 0 C R 108066786 + 512 [0] 8,2012757 6.59000 328 Q R 108070882 + 8 [smbd] 8,2012758 6.59000 328 G R 108070882 + 8 [smbd] 8,2012759 6.59000 328 P N [smbd] 8,2012760 6.59000 328 I R 108070882 + 8 [smbd] 8,2012761 6.59000 328 Q R 108070890 + 8 [smbd] 8,2012762 6.59000 328 M R 108070890 + 8 [smbd] any idea how to fix this issue? Not really. I've had a similar looking problem with a md raid-1 set of harddisks running 2.6.18. md0_raid1 took every 10 seconds all of the cpu blocking other stuff on the machine for some other 2 secons doing no disk writes. $ uname -a Linux rio 2.6.22.9 #1 Mon Oct 1 19:48:54 CEST 2007 i686 pentium3 i386 GNU/Linux $ lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) 00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) 00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) 00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0b.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 50) 00:0b.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 50) 00:0b.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51) 00:0c.0 Mass storage controller: Promise Technology, Inc. 20269 (rev 02) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G100 [Productiva] AGP (rev 01) The raid is on the Promise PDC20269 $ mdadm --misc --detail /dev/md0 /dev/md0: Version : 00.90.03 Creation Time : Sat Oct 29 20:51:41 2005 Raid Level : raid1 Array Size : 293049600 (279.47 GiB 300.08 GB) Used Dev Size : 293049600 (279.47 GiB 300.08 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Tue Oct 30 19:20:12 2007 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : b2d7f60d:008fa0df:136207f1:ae0e7a9e Events : 0.432306 Number Major Minor RaidDevice State 0 3310 active sync /dev/hde1 1 3411 active sync /dev/hdg1 I didn't dare to report a bug against the old kernel. I moved to 2.6.22.9 and the problem disappeared... Any ways to debug that (non-intrusive on a production machine)? Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major SATA / EXT3 Issue?
Chris Holvenstot schrieb: I am curious if anyone else has had major problems with SATA drives on the current series of kernels. I have (or rather had) two SATA drives on my system - the first was a Maxtor MaxLine 500 and the second was a Maxtor MaxLine 250. [...] If harddisks get too hot they die pretty quickly. The current harddisks usually support SMART. Ask the disks what they think it's wrong: http://smartmontools.sourceforge.net/ Then, check the disks with different hardware... I have seen several issues with bad cables and broken hardware. If you think that the problem is kernel related, you can boot some other distro or change the kernel to see if this problem still persists. Please post the dmesg output if you are sure the problem is kernel related... Regards, -- Clemens Koller ___ R Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major SATA / EXT3 Issue?
Chris Holvenstot schrieb: I am curious if anyone else has had major problems with SATA drives on the current series of kernels. I have (or rather had) two SATA drives on my system - the first was a Maxtor MaxLine 500 and the second was a Maxtor MaxLine 250. [...] If harddisks get too hot they die pretty quickly. The current harddisks usually support SMART. Ask the disks what they think it's wrong: http://smartmontools.sourceforge.net/ Then, check the disks with different hardware... I have seen several issues with bad cables and broken hardware. If you think that the problem is kernel related, you can boot some other distro or change the kernel to see if this problem still persists. Please post the dmesg output if you are sure the problem is kernel related... Regards, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleepy linux 2.6.23-rc9
Pavel Machek schrieb: I played with powertop a bit, and found a fairly interesting failure mode. If I boot init=/bin/bash vga=1, I get ~2 wakeups a second, nice. When I boot init=/bin/bash vga=791 (vesa framebuffer), most wakeups are caused by cursor painting (I should fix that some day, I guess). But... the cursor blinking does not even work properly! It blinks at normal speed, then (randomly) it blinks slowly, then gets back to normal speed, then inserts longer delay. Is the effect a beat that it has roughly the frequency of your Notebooks screen refresh rate (60Hz)? (in german: Schwebung) The effect is so nice that I thought about youtube ;-). Thinkpad x60.. question is, how to debug it? No idea... check where the register of the HW cursor blink rate gets written? But as it seems to be so nice, please submit a patch which enables this for all platforms. ;-) Regards, -- Clemens Koller ___ R Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleepy linux 2.6.23-rc9
Pavel Machek schrieb: I played with powertop a bit, and found a fairly interesting failure mode. If I boot init=/bin/bash vga=1, I get ~2 wakeups a second, nice. When I boot init=/bin/bash vga=791 (vesa framebuffer), most wakeups are caused by cursor painting (I should fix that some day, I guess). But... the cursor blinking does not even work properly! It blinks at normal speed, then (randomly) it blinks slowly, then gets back to normal speed, then inserts longer delay. Is the effect a beat that it has roughly the frequency of your Notebooks screen refresh rate (60Hz)? (in german: Schwebung) The effect is so nice that I thought about youtube ;-). Thinkpad x60.. question is, how to debug it? No idea... check where the register of the HW cursor blink rate gets written? But as it seems to be so nice, please submit a patch which enables this for all platforms. ;-) Regards, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Promise SATA300 TX4: errors, oops in ext3 code
Alexander Sabourenkov schrieb:
> Hardware: Athlon64, Asus A8V, Promise SATA300 TX4, 2xSeagate 7200.10
> 320G, jumper-limited to SATA150.
> Kernel : 2.6.22.9 amd64
>
> Problem:
> Heavy load causes errors and triggers oops.
>
> History:
> Problems were first encountered on kernel 2.6.19, both i686 ("old"
> system) and amd64 (gentoo installation CD).
> Can't say anything about older kernels. Most probably they have same
> issues (or worse).
>
> Problems were blamed:
> - SATA300 being too 'hot' (jumpered the drives)
Did you turn it back to SATA300 and does it basically still work?
Then cool it actively and see if the error rate depends on it.
In one of my Promise HDD (PDC20275) controller designs I forgot to connect
the thermal pad (they call it E-PAD) properly to a GND plane so it just
worked with lots of errors which were also temperature sensitive (so, a
typical hardware design flaw :-).
On a PCI add-on card with the same chip, the E-PAD also didn't look
soldered over it's whole E-PAD area but it was working.
As you might have noticed, I am more into hardware debugging.
Propably some kernel gurus might have other ideas (related to software).
Regards,
Clemens Koller
__
R Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Promise SATA300 TX4: errors, oops in ext3 code
Alexander Sabourenkov schrieb: >> Have you checked your memory already (memtest86)? > [...] >> Again... sounds like bad memory to me. > Nightly memtest86 run : 11 hours, 23 passes, 0 errors. Okay, I have no idea about any bugs there. You have several options: Find a 100% working vanilla kernel for your problem (minimal configuration, skip i.e. the sound stuff, ...). And then git bisect with a known bad kernel. Same thing in hardware: move components (Controllers + HDD) to/from a working machine and verify... Regards, Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Promise SATA300 TX4: errors, oops in ext3 code
Alexander Sabourenkov schrieb: Have you checked your memory already (memtest86)? [...] Again... sounds like bad memory to me. Nightly memtest86 run : 11 hours, 23 passes, 0 errors. Okay, I have no idea about any bugs there. You have several options: Find a 100% working vanilla kernel for your problem (minimal configuration, skip i.e. the sound stuff, ...). And then git bisect with a known bad kernel. Same thing in hardware: move components (Controllers + HDD) to/from a working machine and verify... Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Promise SATA300 TX4: errors, oops in ext3 code
Alexander Sabourenkov schrieb: Hardware: Athlon64, Asus A8V, Promise SATA300 TX4, 2xSeagate 7200.10 320G, jumper-limited to SATA150. Kernel : 2.6.22.9 amd64 Problem: Heavy load causes errors and triggers oops. History: Problems were first encountered on kernel 2.6.19, both i686 (old system) and amd64 (gentoo installation CD). Can't say anything about older kernels. Most probably they have same issues (or worse). Problems were blamed: - SATA300 being too 'hot' (jumpered the drives) Did you turn it back to SATA300 and does it basically still work? Then cool it actively and see if the error rate depends on it. In one of my Promise HDD (PDC20275) controller designs I forgot to connect the thermal pad (they call it E-PAD) properly to a GND plane so it just worked with lots of errors which were also temperature sensitive (so, a typical hardware design flaw :-). On a PCI add-on card with the same chip, the E-PAD also didn't look soldered over it's whole E-PAD area but it was working. As you might have noticed, I am more into hardware debugging. Propably some kernel gurus might have other ideas (related to software). Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-2.6.18 reiserfs on raid1 blocks io until rebooted - why?
rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) 00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) 00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) 00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0b.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 50) 00:0b.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 50) 00:0b.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51) 00:0c.0 Mass storage controller: Promise Technology, Inc. 20269 (rev 02) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G100 [Productiva] AGP (rev 01) $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 2 cpu MHz : 451.024 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 902.79 $ mdadm --detail /dev/md0 /dev/md0: Version : 00.90.03 Creation Time : Sat Oct 29 20:51:41 2005 Raid Level : raid1 Array Size : 293049600 (279.47 GiB 300.08 GB) Used Dev Size : 293049600 (279.47 GiB 300.08 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Mon Oct 1 14:59:30 2007 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : b2d7f60d:008fa0df:136207f1:ae0e7a9e Events : 0.432306 Number Major Minor RaidDevice State 0 3310 active sync /dev/hde1 1 341 1 active sync /dev/hdg1 Thank you in advance, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Promise SATA300 TX4: errors, oops in ext3 code
Alexander Sabourenkov schrieb: > Hardware: Athlon64, Asus A8V, Promise SATA300 TX4, 2xSeagate 7200.10 > 320G, jumper-limited to SATA150. > Kernel : 2.6.22.9 amd64 > > Problem: > Heavy load causes errors and triggers oops. Have you checked your memory already (memtest86)? We have several applications with Promise controllers on strange hardware and we never had integrity problems with i.e. not so standard SATA connections over custom vaccum-tight connectors. > Problems were blamed: > - SATA300 being too 'hot' (jumpered the drives) Is this a common known problem with your harddrives or controller? (ask google) Otherwise, it sounds like a problem with broken hardware. > - cables (work perfectly on onboard controller) > - interrupt sharing (found the only slot which does not share > interrupt line) > - cooling (3 fans installed, smartctl-reported temperature at max load > dropped to 35C) Try to heat up your memory a little (your wife's hair blower). If it fails more often, your memory is most likely broken. > - weak PSU (installed 600W FSP) > - kernel bugs (upgraded to 2.6.22.9) > > All those measures significantly dropped error rate (from about 20 to > 2-4 per mirror rebuild) but did not eliminate the problem. Again... sounds like bad memory to me. Juat my $0.05. Regards, Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Promise SATA300 TX4: errors, oops in ext3 code
Alexander Sabourenkov schrieb: Hardware: Athlon64, Asus A8V, Promise SATA300 TX4, 2xSeagate 7200.10 320G, jumper-limited to SATA150. Kernel : 2.6.22.9 amd64 Problem: Heavy load causes errors and triggers oops. Have you checked your memory already (memtest86)? We have several applications with Promise controllers on strange hardware and we never had integrity problems with i.e. not so standard SATA connections over custom vaccum-tight connectors. Problems were blamed: - SATA300 being too 'hot' (jumpered the drives) Is this a common known problem with your harddrives or controller? (ask google) Otherwise, it sounds like a problem with broken hardware. - cables (work perfectly on onboard controller) - interrupt sharing (found the only slot which does not share interrupt line) - cooling (3 fans installed, smartctl-reported temperature at max load dropped to 35C) Try to heat up your memory a little (your wife's hair blower). If it fails more often, your memory is most likely broken. - weak PSU (installed 600W FSP) - kernel bugs (upgraded to 2.6.22.9) All those measures significantly dropped error rate (from about 20 to 2-4 per mirror rebuild) but did not eliminate the problem. Again... sounds like bad memory to me. Juat my $0.05. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-2.6.18 reiserfs on raid1 blocks io until rebooted - why?
/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) 00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) 00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) 00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0b.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 50) 00:0b.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 50) 00:0b.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51) 00:0c.0 Mass storage controller: Promise Technology, Inc. 20269 (rev 02) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G100 [Productiva] AGP (rev 01) $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 2 cpu MHz : 451.024 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 902.79 $ mdadm --detail /dev/md0 /dev/md0: Version : 00.90.03 Creation Time : Sat Oct 29 20:51:41 2005 Raid Level : raid1 Array Size : 293049600 (279.47 GiB 300.08 GB) Used Dev Size : 293049600 (279.47 GiB 300.08 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Mon Oct 1 14:59:30 2007 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : b2d7f60d:008fa0df:136207f1:ae0e7a9e Events : 0.432306 Number Major Minor RaidDevice State 0 3310 active sync /dev/hde1 1 3411 active sync /dev/hdg1 Thank you in advance, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] update CFI URI n mtd kconfig
Mike Frysinger schrieb: On Thursday 13 September 2007, Robin Getz wrote: Why not from the place that you can get the standard? http://jedec.org/ i found jedec.org a nightmare to navigate or http://www.jedec.org/download/search/jesd68-01.pdf i'll add that to wikipedia ;) -mike ...done. Regards, Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] update CFI URI n mtd kconfig
Mike Frysinger schrieb: On Thursday 13 September 2007, Robin Getz wrote: Why not from the place that you can get the standard? http://jedec.org/ i found jedec.org a nightmare to navigate or http://www.jedec.org/download/search/jesd68-01.pdf i'll add that to wikipedia ;) -mike ...done. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC+PATCH] RTC calibration
Dag-Erling Smørgrav schrieb: > Clemens Koller <[EMAIL PROTECTED]> writes: >> I am talking about _how_ the calibration register is addressed from >> userspace. It's a simple register, some bits at address 7 and I would >> expect to read/modify/write registers to do all the things you want >> to do. Register access in userspace doesn't put any limitation >> to applications. > > It requires the application to know the hardware intimately. That's right... there is no need to put that into the kernel and hide this trivial functionality from userspace. > Calibration of the M41T11 is implemented using the lower 6 bits of > register 7; this is not necessarily the case for other existing or > future chips. I've read the datasheet. Your driver is specific for the M41T11 chip as mentioned in your first mail, isn't it? If any future driver comes up with 8 bits you wouldn't need to change a generic interface to read/modify/write these 8 bits, right? > Let's say I normalize this to [-128;127]; Why do any normalization in the driver? That's what userspace can do in any way it might be necessary to do. >> Having only incs and decs without getting the actual value back seems >> to be an absolutely unnecessary limitation here. >> You cannot get the current value back to see if it's i.e. in saturation in >> a way that it doesn't make sense to inc/decrement it further or in bigger steps >> or reset it to zero... > > The driver will return EINVAL if you try to increment or decrement the > calibration register beyond its limits. That behaviour seems also odd to me... I can increment/decrement by an unknown number and then I get an EINVAL. And I cannot reset it to some default value easily. I still don't see any reason to implement relative changes to an otherwise unknown value if it's possible to give absolute values to work with. Well, that's my opinion, my five cents... I don't want to get into a lenghtly discussion... I just used common sense how a interface to a register might look like and your way of a relative manipulation just looks very uncommon to me, having seen lot's of drivers. Best regards, Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC+PATCH] RTC calibration
Dag-Erling Smørgrav schrieb: > Clemens Koller <[EMAIL PROTECTED]> writes: >> It looks odd to me to do only differential up and down adjustments. >> I would prefer read_calibration_register and write_calibration_register >> access and let the userspace decide how much it wants to >> increment/decrement the register. > > Without knowing exacly which chip is present, there is no way for the > userland calibration tool to know how big a difference a calibration > step makes. I am not talking about the calibration algorithm and it's quality. I am talking about _how_ the calibration register is addressed from userspace. It's a simple register, some bits at address 7 and I would expect to read/modify/write registers to do all the things you want to do. Register access in userspace doesn't put any limitation to applications. Having only incs and decs without getting the actual value back seems to be an absolutely unnecessary limitation here. You cannot get the current value back to see if it's i.e. in saturation in a way that it doesn't make sense to inc/decrement it further or in bigger steps or reset it to zero... Regards, Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC+PATCH] RTC calibration
Dag-Erling Smørgrav schrieb: > The STMicroelectronics M41T11 is an RTC chip which is similar in most > ways to the Dallas/Maxim DS1307 or DS1337, except that it supports > software calibration: > > http://www.st.com/stonline/books/pdf/docs/6103.pdf > > I want to use this calibration feature [...] > [...] > In order to access this from userland, I've added two ioctls, > (RTC_SPEED_UP and RTC_SPEED_DOWN) with corresponding functions in > drivers/rtc/interface.c (rtc_speed_up() and rtc_speed_down()) and > corresponding slots in rtc_class_ops (speed_up and speed_down). It looks odd to me to do only differential up and down adjustments. I would prefer read_calibration_register and write_calibration_register access and let the userspace decide how much it wants to increment/decrement the register. Or - do you adjust your date also after you changed your battery with +1567days,7h,34m,12sec instead of telling it's 11th Sept. 2007, 4:33pm ? Regards, Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC+PATCH] RTC calibration
Dag-Erling Smørgrav schrieb: The STMicroelectronics M41T11 is an RTC chip which is similar in most ways to the Dallas/Maxim DS1307 or DS1337, except that it supports software calibration: http://www.st.com/stonline/books/pdf/docs/6103.pdf I want to use this calibration feature [...] [...] In order to access this from userland, I've added two ioctls, (RTC_SPEED_UP and RTC_SPEED_DOWN) with corresponding functions in drivers/rtc/interface.c (rtc_speed_up() and rtc_speed_down()) and corresponding slots in rtc_class_ops (speed_up and speed_down). It looks odd to me to do only differential up and down adjustments. I would prefer read_calibration_register and write_calibration_register access and let the userspace decide how much it wants to increment/decrement the register. Or - do you adjust your date also after you changed your battery with +1567days,7h,34m,12sec instead of telling it's 11th Sept. 2007, 4:33pm ? Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC+PATCH] RTC calibration
Dag-Erling Smørgrav schrieb: Clemens Koller [EMAIL PROTECTED] writes: It looks odd to me to do only differential up and down adjustments. I would prefer read_calibration_register and write_calibration_register access and let the userspace decide how much it wants to increment/decrement the register. Without knowing exacly which chip is present, there is no way for the userland calibration tool to know how big a difference a calibration step makes. I am not talking about the calibration algorithm and it's quality. I am talking about _how_ the calibration register is addressed from userspace. It's a simple register, some bits at address 7 and I would expect to read/modify/write registers to do all the things you want to do. Register access in userspace doesn't put any limitation to applications. Having only incs and decs without getting the actual value back seems to be an absolutely unnecessary limitation here. You cannot get the current value back to see if it's i.e. in saturation in a way that it doesn't make sense to inc/decrement it further or in bigger steps or reset it to zero... Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC+PATCH] RTC calibration
Dag-Erling Smørgrav schrieb: Clemens Koller [EMAIL PROTECTED] writes: I am talking about _how_ the calibration register is addressed from userspace. It's a simple register, some bits at address 7 and I would expect to read/modify/write registers to do all the things you want to do. Register access in userspace doesn't put any limitation to applications. It requires the application to know the hardware intimately. That's right... there is no need to put that into the kernel and hide this trivial functionality from userspace. Calibration of the M41T11 is implemented using the lower 6 bits of register 7; this is not necessarily the case for other existing or future chips. I've read the datasheet. Your driver is specific for the M41T11 chip as mentioned in your first mail, isn't it? If any future driver comes up with 8 bits you wouldn't need to change a generic interface to read/modify/write these 8 bits, right? Let's say I normalize this to [-128;127]; Why do any normalization in the driver? That's what userspace can do in any way it might be necessary to do. Having only incs and decs without getting the actual value back seems to be an absolutely unnecessary limitation here. You cannot get the current value back to see if it's i.e. in saturation in a way that it doesn't make sense to inc/decrement it further or in bigger steps or reset it to zero... The driver will return EINVAL if you try to increment or decrement the calibration register beyond its limits. That behaviour seems also odd to me... I can increment/decrement by an unknown number and then I get an EINVAL. And I cannot reset it to some default value easily. I still don't see any reason to implement relative changes to an otherwise unknown value if it's possible to give absolute values to work with. Well, that's my opinion, my five cents... I don't want to get into a lenghtly discussion... I just used common sense how a interface to a register might look like and your way of a relative manipulation just looks very uncommon to me, having seen lot's of drivers. Best regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Blackfin BF54x NAND Flash Controller driver
Hi, Bryan! Bryan Wu schrieb: This is the driver for latest Blackfin BF54x nand flash controller - use nand_chip and mtd_info common nand driver interface - provide both PIO and dma operation - compiled with ezkit bf548 configuration - use hardware 1-bit ECC - tested with YAFFS2 and can mount YAFFS2 filesystem as rootfs Looks great! Will this driver also work for the new BF52x series of the Blackfin Series? (Or is it planned to make it work for... anytime soon.) Thank you! -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Blackfin BF54x NAND Flash Controller driver
Hi, Bryan! Bryan Wu schrieb: This is the driver for latest Blackfin BF54x nand flash controller - use nand_chip and mtd_info common nand driver interface - provide both PIO and dma operation - compiled with ezkit bf548 configuration - use hardware 1-bit ECC - tested with YAFFS2 and can mount YAFFS2 filesystem as rootfs Looks great! Will this driver also work for the new BF52x series of the Blackfin Series? (Or is it planned to make it work for... anytime soon.) Thank you! -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OT: Re: request for Linux kernel related project ideas
Robert P. J. Day schrieb: On Thu, 23 Aug 2007, Clemens Koller wrote: shaneed cm schrieb: Hi, This is a request for Linux kernel related project ideas. I am Computer Science Engineering final year student. We have to do a project of one year duration . I formed a group of two and we decided to do a project in Linux kernel. Our interests are in Virtual memory management, file system, process scheduling and load balancing in Linux clusters. Last year we did a study of Linux's page replacement mechanism. As I am not experienced as you people, please suggest me some ideas. Just for an example: Checkout what filesystem / caching / scheduling policy is most suitable for Solid State PATA/SATA Flashdisks and write / modify a kernel scheduler to support it. i'm not sure that it's appropriate for LKML folks to be giving anyone suggestions for projects. I don't care so much. The answer should have been a hint that just some minutes ago, we had a thread on this list about Solid State Flash disks... it could be interesting to spend some brain cells in that area - just for an example ...and there are so many. > the eventual choice of project should be based on what *shaneed* wants, not what other people tell him he should be doing. Propably he doesn't know yet what he wants? in addition, sometimes part of the work involved in a school project involves doing enough research to just make the *choice*. what shaneed is asking is that others do that work for him. IMHO, he should be told politely but firmly that selecting a topic is *his* problem. that's just part of the academic process. Asking people with more experience what's needed is in my point of view also a reasonably academic process to make progress in the right direction. IMHO that's one of the main reasons why open projects work. Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for Linux kernel related project ideas
shaneed cm schrieb: Hi, This is a request for Linux kernel related project ideas. I am Computer Science Engineering final year student. We have to do a project of one year duration . I formed a group of two and we decided to do a project in Linux kernel. Our interests are in Virtual memory management, file system, process scheduling and load balancing in Linux clusters. Last year we did a study of Linux's page replacement mechanism. As I am not experienced as you people, please suggest me some ideas. Just for an example: Checkout what filesystem / caching / scheduling policy is most suitable for Solid State PATA/SATA Flashdisks and write / modify a kernel scheduler to support it. Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for Linux kernel related project ideas
shaneed cm schrieb: Hi, This is a request for Linux kernel related project ideas. I am Computer Science Engineering final year student. We have to do a project of one year duration . I formed a group of two and we decided to do a project in Linux kernel. Our interests are in Virtual memory management, file system, process scheduling and load balancing in Linux clusters. Last year we did a study of Linux's page replacement mechanism. As I am not experienced as you people, please suggest me some ideas. Just for an example: Checkout what filesystem / caching / scheduling policy is most suitable for Solid State PATA/SATA Flashdisks and write / modify a kernel scheduler to support it. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OT: Re: request for Linux kernel related project ideas
Robert P. J. Day schrieb: On Thu, 23 Aug 2007, Clemens Koller wrote: shaneed cm schrieb: Hi, This is a request for Linux kernel related project ideas. I am Computer Science Engineering final year student. We have to do a project of one year duration . I formed a group of two and we decided to do a project in Linux kernel. Our interests are in Virtual memory management, file system, process scheduling and load balancing in Linux clusters. Last year we did a study of Linux's page replacement mechanism. As I am not experienced as you people, please suggest me some ideas. Just for an example: Checkout what filesystem / caching / scheduling policy is most suitable for Solid State PATA/SATA Flashdisks and write / modify a kernel scheduler to support it. i'm not sure that it's appropriate for LKML folks to be giving anyone suggestions for projects. I don't care so much. The answer should have been a hint that just some minutes ago, we had a thread on this list about Solid State Flash disks... it could be interesting to spend some brain cells in that area - just for an example ...and there are so many. the eventual choice of project should be based on what *shaneed* wants, not what other people tell him he should be doing. Propably he doesn't know yet what he wants? in addition, sometimes part of the work involved in a school project involves doing enough research to just make the *choice*. what shaneed is asking is that others do that work for him. IMHO, he should be told politely but firmly that selecting a topic is *his* problem. that's just part of the academic process. Asking people with more experience what's needed is in my point of view also a reasonably academic process to make progress in the right direction. IMHO that's one of the main reasons why open projects work. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [3/4] x86_64: Change PMDS invocation to single macro
Andi Kleen schrieb: Very old binutils (2.12.90...) seem to have trouble with newlines in assembler macro invocation. They put them into the resulting argument expansion. In this case this lead to a parse error because a .rept expression ended up spread over multiple lines. Change the PMDS() invocation to a single line. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Index: linux/arch/x86_64/kernel/head.S === --- linux.orig/arch/x86_64/kernel/head.S +++ linux/arch/x86_64/kernel/head.S @@ -345,8 +345,7 @@ NEXT_PAGE(level2_kernel_pgt) /* 40MB kernel mapping. The kernel code cannot be bigger than that. When you change this change KERNEL_TEXT_SIZE in page.h too. */ /* (2^48-(2*1024*1024*1024)-((2^39)*511)-((2^30)*510)) = 0 */ - PMDS(0x, __PAGE_KERNEL_LARGE_EXEC|_PAGE_GLOBAL, - KERNEL_TEXT_SIZE/PMD_SIZE) + PMDS(0x, __PAGE_KERNEL_LARGE_EXEC|_PAGE_GLOBAL, KERNEL_TEXT_SIZE/PMD_SIZE) Can you please add a comment, that this line must stay in a single line for the above reason? I would expect that the next who does some code clean up will break it again. /* Module mapping starts here */ .fill (PTRS_PER_PMD - (KERNEL_TEXT_SIZE/PMD_SIZE)),8,0 Regards, -- Clemens Koller ___ R Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [3/4] x86_64: Change PMDS invocation to single macro
Andi Kleen schrieb: Very old binutils (2.12.90...) seem to have trouble with newlines in assembler macro invocation. They put them into the resulting argument expansion. In this case this lead to a parse error because a .rept expression ended up spread over multiple lines. Change the PMDS() invocation to a single line. Signed-off-by: Andi Kleen [EMAIL PROTECTED] Index: linux/arch/x86_64/kernel/head.S === --- linux.orig/arch/x86_64/kernel/head.S +++ linux/arch/x86_64/kernel/head.S @@ -345,8 +345,7 @@ NEXT_PAGE(level2_kernel_pgt) /* 40MB kernel mapping. The kernel code cannot be bigger than that. When you change this change KERNEL_TEXT_SIZE in page.h too. */ /* (2^48-(2*1024*1024*1024)-((2^39)*511)-((2^30)*510)) = 0 */ - PMDS(0x, __PAGE_KERNEL_LARGE_EXEC|_PAGE_GLOBAL, - KERNEL_TEXT_SIZE/PMD_SIZE) + PMDS(0x, __PAGE_KERNEL_LARGE_EXEC|_PAGE_GLOBAL, KERNEL_TEXT_SIZE/PMD_SIZE) Can you please add a comment, that this line must stay in a single line for the above reason? I would expect that the next who does some code clean up will break it again. /* Module mapping starts here */ .fill (PTRS_PER_PMD - (KERNEL_TEXT_SIZE/PMD_SIZE)),8,0 Regards, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: k8temp on 2.6.18
shacky schrieb: Hi. I'm using the 2.6.18 kernel (and I cannot upgrade it), but I need the "k8temp" module which is available only from the 2.6.21 version. Is there a way to use this module on my 2.6.18? What is your problem that you cannot upgrade your kernel? Backporting the k8temp is propably more difficult as installing a newer kernel. Have a look at: http://lists.debian.org/debian-amd64/2007/03/msg5.html Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: k8temp on 2.6.18
shacky schrieb: Hi. I'm using the 2.6.18 kernel (and I cannot upgrade it), but I need the k8temp module which is available only from the 2.6.21 version. Is there a way to use this module on my 2.6.18? What is your problem that you cannot upgrade your kernel? Backporting the k8temp is propably more difficult as installing a newer kernel. Have a look at: http://lists.debian.org/debian-amd64/2007/03/msg5.html Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: D-Link DFE-580TX 4 port NIC problems
Hi, Mario! Mario Doering schrieb: Hello, are there any news or questions on this issue? Can you try the latest kernel to see if the same problem persists? Is there any kernel version where it was working fine? On Wed, 9 May 2007 03:27:00 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: On Wed, 9 May 2007 12:01:42 +0200 Mario Doering <[EMAIL PROTECTED]> wrote: Hello, we have a D-Link DFE-580TX 4 port network card in our main router. It works pretty well most of the time, even though an error message pops up in dmesg every now and then (sometimes once a day sometimes once every few hours). But every few weeks those error messages increase rapidly, spamming dmesg. When this happens the system does not react anymore and pushing the reset button is the only option left. I googled around and found out that other users have same problem, but no solution to this. Part of the message log is located here: http://test.dedenet.de/messages.gz or http://test.dedenet.de/messages.txt uname -a Linux router1 2.6.19-gentoo-r5 #1 Sat Feb 17 17:04:03 CET 2007 i686 AMD Athlon(tm) XP AuthenticAMD GNU/Linux driver: [ 17.364707] sundance.c:v1.2 11-Sep-2006 Written by Donald Becker [ 17.364711] http://www.scyld.com/network/sundance.html [ 17.364844] ACPI: PCI Interrupt :03:04.0[A] -> GSI 17 (level, low) -> IRQ 17 [ 17.365396] eth1: D-Link DFE-580TX 4 port Server Adapter at 0001bc00, 00:0d:88:cc:a5:f0, IRQ 17. [ 17.366350] eth1: MII PHY found at address 1, status 0x7829 advertising 01e1. [ 17.676491] ACPI: PCI Interrupt :03:05.0[A] -> GSI 18 (level, low) -> IRQ 18 [ 17.676912] eth2: D-Link DFE-580TX 4 port Server Adapter at 0001b800, 00:0d:88:cc:a5:f1, IRQ 18. [ 17.677864] eth2: MII PHY found at address 1, status 0x7809 advertising 01e1. [ 17.987730] ACPI: PCI Interrupt :03:06.0[A] -> GSI 19 (level, low) -> IRQ 16 [ 17.988107] eth3: D-Link DFE-580TX 4 port Server Adapter at 0001b400, 00:0d:88:cc:a5:f2, IRQ 16. [ 17.989059] eth3: MII PHY found at address 1, status 0x7829 advertising 01e1. [ 18.298910] ACPI: PCI Interrupt :03:07.0[A] -> GSI 16 (level, low) -> IRQ 19 [ 18.299320] eth4: D-Link DFE-580TX 4 port Server Adapter at 0001b000, 00:0d:88:cc:a5:f3, IRQ 19. [ 18.300272] eth4: MII PHY found at address 1, status 0x7809 advertising 01e1. No such error message appears for about 7-10 days after a reboot. Maybe there is some kind of buffer running full? Do you need any additional info? Please CC me :-) (cc netdev) Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: D-Link DFE-580TX 4 port NIC problems
Hi, Mario! Mario Doering schrieb: Hello, are there any news or questions on this issue? Can you try the latest kernel to see if the same problem persists? Is there any kernel version where it was working fine? On Wed, 9 May 2007 03:27:00 -0700 Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 9 May 2007 12:01:42 +0200 Mario Doering [EMAIL PROTECTED] wrote: Hello, we have a D-Link DFE-580TX 4 port network card in our main router. It works pretty well most of the time, even though an error message pops up in dmesg every now and then (sometimes once a day sometimes once every few hours). But every few weeks those error messages increase rapidly, spamming dmesg. When this happens the system does not react anymore and pushing the reset button is the only option left. I googled around and found out that other users have same problem, but no solution to this. Part of the message log is located here: http://test.dedenet.de/messages.gz or http://test.dedenet.de/messages.txt uname -a Linux router1 2.6.19-gentoo-r5 #1 Sat Feb 17 17:04:03 CET 2007 i686 AMD Athlon(tm) XP AuthenticAMD GNU/Linux driver: [ 17.364707] sundance.c:v1.2 11-Sep-2006 Written by Donald Becker [ 17.364711] http://www.scyld.com/network/sundance.html [ 17.364844] ACPI: PCI Interrupt :03:04.0[A] - GSI 17 (level, low) - IRQ 17 [ 17.365396] eth1: D-Link DFE-580TX 4 port Server Adapter at 0001bc00, 00:0d:88:cc:a5:f0, IRQ 17. [ 17.366350] eth1: MII PHY found at address 1, status 0x7829 advertising 01e1. [ 17.676491] ACPI: PCI Interrupt :03:05.0[A] - GSI 18 (level, low) - IRQ 18 [ 17.676912] eth2: D-Link DFE-580TX 4 port Server Adapter at 0001b800, 00:0d:88:cc:a5:f1, IRQ 18. [ 17.677864] eth2: MII PHY found at address 1, status 0x7809 advertising 01e1. [ 17.987730] ACPI: PCI Interrupt :03:06.0[A] - GSI 19 (level, low) - IRQ 16 [ 17.988107] eth3: D-Link DFE-580TX 4 port Server Adapter at 0001b400, 00:0d:88:cc:a5:f2, IRQ 16. [ 17.989059] eth3: MII PHY found at address 1, status 0x7829 advertising 01e1. [ 18.298910] ACPI: PCI Interrupt :03:07.0[A] - GSI 16 (level, low) - IRQ 19 [ 18.299320] eth4: D-Link DFE-580TX 4 port Server Adapter at 0001b000, 00:0d:88:cc:a5:f3, IRQ 19. [ 18.300272] eth4: MII PHY found at address 1, status 0x7809 advertising 01e1. No such error message appears for about 7-10 days after a reboot. Maybe there is some kind of buffer running full? Do you need any additional info? Please CC me :-) (cc netdev) Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: other potential candidates for removal?
Robert P. J. Day schrieb: a while back, i threw together this wiki page: http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed feel free to comment. Won't miss anything there. However, removal of kernel_threads() needs some updated drivers... Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/33] powerpc: Refuse to build 64-bit with GCC-4.2.0 and CONFIG_MODULES
Sam Ravnborg schrieb: From: Segher Boessenkool <[EMAIL PROTECTED]> ...since this won't work (compiler bug, see <http://gcc.gnu.org/PR31490>). The bug report says IA64 is broken, too. Please verify and extend the patch if possible... gcc-4.2.1 will be released soon. Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/33] powerpc: Refuse to build 64-bit with GCC-4.2.0 and CONFIG_MODULES
Sam Ravnborg schrieb: From: Segher Boessenkool [EMAIL PROTECTED] ...since this won't work (compiler bug, see http://gcc.gnu.org/PR31490). The bug report says IA64 is broken, too. Please verify and extend the patch if possible... gcc-4.2.1 will be released soon. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: other potential candidates for removal?
Robert P. J. Day schrieb: a while back, i threw together this wiki page: http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed feel free to comment. Won't miss anything there. However, removal of kernel_threads() needs some updated drivers... Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reading a physical memory location
Manu Abraham schrieb: On 7/11/07, Nobin Mathew <[EMAIL PROTECTED]> wrote: See this in the documentation The returned virtual address is a current CPU mapping for the memory address given. It is only valid to use this function on addresses that have a kernel mapping This function does not handle bus mappings for DMA transfers. In almost all conceivable cases a device driver should not be using this function To get a better idea, look here http://tldp.org/LDP/khg/HyperNews/get/devices/addrxlate.html Very nice! I have two more questions: 1. Is the document up to date? 2. Can anybody give an example how to "map" lots of pages (which got filled by i.e. a scatter gather DMA chain) from a driver (kernel space) to userspace? Thanks -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reading a physical memory location
Manu Abraham schrieb: On 7/11/07, Nobin Mathew [EMAIL PROTECTED] wrote: See this in the documentation The returned virtual address is a current CPU mapping for the memory address given. It is only valid to use this function on addresses that have a kernel mapping This function does not handle bus mappings for DMA transfers. In almost all conceivable cases a device driver should not be using this function To get a better idea, look here http://tldp.org/LDP/khg/HyperNews/get/devices/addrxlate.html Very nice! I have two more questions: 1. Is the document up to date? 2. Can anybody give an example how to map lots of pages (which got filled by i.e. a scatter gather DMA chain) from a driver (kernel space) to userspace? Thanks -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] introduce panic_gently
Chuck Ebbert schrieb: On 07/06/2007 03:57 AM, Clemens Koller wrote: The 180seconds reboot timeout also doesn't make sense here. The problem won't go away after a reboot without user interaction. What about GRUB fallbacks? The fallback image/kernel will start automatically on reboot if you use that feature. Yes, you are right. Regards, -- Clemens Koller ___ R Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] introduce panic_gently
Chuck Ebbert schrieb: On 07/06/2007 03:57 AM, Clemens Koller wrote: The 180seconds reboot timeout also doesn't make sense here. The problem won't go away after a reboot without user interaction. What about GRUB fallbacks? The fallback image/kernel will start automatically on reboot if you use that feature. Yes, you are right. Regards, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] introduce panic_gently
Bodo Eggert schrieb: If the boot process failes to find init or the root fs, the cause has usually scrolled off the screen, and because of the panic, it can't be reached anymore. This patch introduces panic_gently, which will allow to use the scrollback buffer and to reboot, but it can't be called from unsafe context. In the case where you introduced panic_gently() there is IMHO no reason to panic() at all. There is no bug which got hit, the machine just needs user intervention because of wrong boot parameters (in most cases). What about asking the user for the correct root= or init= parameters and just retry/continue the boot process? The 180seconds reboot timeout also doesn't make sense here. The problem won't go away after a reboot without user interaction. Regards, -- Clemens Koller ___ R Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] introduce panic_gently
Bodo Eggert schrieb: If the boot process failes to find init or the root fs, the cause has usually scrolled off the screen, and because of the panic, it can't be reached anymore. This patch introduces panic_gently, which will allow to use the scrollback buffer and to reboot, but it can't be called from unsafe context. In the case where you introduced panic_gently() there is IMHO no reason to panic() at all. There is no bug which got hit, the machine just needs user intervention because of wrong boot parameters (in most cases). What about asking the user for the correct root= or init= parameters and just retry/continue the boot process? The 180seconds reboot timeout also doesn't make sense here. The problem won't go away after a reboot without user interaction. Regards, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 june 30th to july 1st date hang?
Chris Friesen schrieb: However, in order to trigger the problem you also need to have NTP servers that were erroneously broadcasting the addition of a leap second. No matter what NTP servers send, it shouldn't result in a DoS. So most people didn't see the issue because there wasn't supposed to be a leap second added this year...but they would have seen it the next time a leap second was added. True. It seems like we will have another one next year. Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 june 30th to july 1st date hang?
Hello, Chris! Chris Wright schrieb: * Uli Luckas ([EMAIL PROTECTED]) wrote: On Tuesday, 3. July 2007, Chuck Ebbert wrote: On 07/03/2007 03:28 PM, Chris Friesen wrote: Arne Georg Gleditsch wrote: An interesting exercise might be to code up a small program to call adjtimex with timex.status |= STA_INS, to see if this can trigger the problem. Setting the date to just before midnight June 30 UTC and then running the following as root triggered the crash on a modified 2.6.10. Anyone see anything wrong with the code below, or is this a valid indication of a bug in the leap second code? Fixed: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=comm itdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b Hi Chris, does that qualify for inclusion into 2.6.21.6? Yes, it has already been sent to -stable. Okay, we all survived Y2K and this little glitch. Puh! ;-) Can you please explain in which configuration this problem got triggered. Does it make sense to have some testing environments which have the date set to about one month in the future to catch any crashes like that, preventing machines in production from failing?! Best regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 june 30th to july 1st date hang?
Hello, Chris! Chris Wright schrieb: * Uli Luckas ([EMAIL PROTECTED]) wrote: On Tuesday, 3. July 2007, Chuck Ebbert wrote: On 07/03/2007 03:28 PM, Chris Friesen wrote: Arne Georg Gleditsch wrote: An interesting exercise might be to code up a small program to call adjtimex with timex.status |= STA_INS, to see if this can trigger the problem. Setting the date to just before midnight June 30 UTC and then running the following as root triggered the crash on a modified 2.6.10. Anyone see anything wrong with the code below, or is this a valid indication of a bug in the leap second code? Fixed: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=comm itdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b Hi Chris, does that qualify for inclusion into 2.6.21.6? Yes, it has already been sent to -stable. Okay, we all survived Y2K and this little glitch. Puh! ;-) Can you please explain in which configuration this problem got triggered. Does it make sense to have some testing environments which have the date set to about one month in the future to catch any crashes like that, preventing machines in production from failing?! Best regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 june 30th to july 1st date hang?
Chris Friesen schrieb: However, in order to trigger the problem you also need to have NTP servers that were erroneously broadcasting the addition of a leap second. No matter what NTP servers send, it shouldn't result in a DoS. So most people didn't see the issue because there wasn't supposed to be a leap second added this year...but they would have seen it the next time a leap second was added. True. It seems like we will have another one next year. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 june 30th to july 1st date hang?
Hi, Vincent!
Fortier,Vincent [Montreal] schrieb:
Hi all,
All my servers and workstations running a 2.6.21.5 kernel hanged exactly
when the date shift from june 30th to july 1st.
On my monitoring system every single station running a 2.6.21.5 kernel
stoped responding exactly after midnight on the date shift from June
30th to July 1st. Although, stations still running 2.6.18 to 2.6.20.11
worked flawlessly.
I first tought there had been an electricity outage but two of my
servers (dell PE 2950 dual-quad core) on UPS in our server room also
hanged:
Jun 30 23:55:01 urpdev1 /USR/SBIN/CRON[31298]: (root) CMD ([ -x
/usr/lib/sysstat/sa1 ] && { [ -r "$DEFAULT" ] && . "$DEFAULT" ; [
"$ENABLED" = "true" ] && exec /usr/lib/sysstat/sa1; })
Jul 3 11:54:03 urpdev1 syslogd 1.4.1#17: restart.
I could not get anything on any of the 20+ consoles... All the systems
hanged at around the exact same time... When the date shifted from June
30th to July 1st in UTC ...?
Any clue any one?
No problems over here with plain 2.6.21.5 on x686
You could just reset the date back on one of these machines and
check the transition again... and see if it was really the kernel
who crashed.... and check your cron configuration.
Regards,
--
Clemens Koller
__
R Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 june 30th to july 1st date hang?
Hi, Vincent!
Fortier,Vincent [Montreal] schrieb:
Hi all,
All my servers and workstations running a 2.6.21.5 kernel hanged exactly
when the date shift from june 30th to july 1st.
On my monitoring system every single station running a 2.6.21.5 kernel
stoped responding exactly after midnight on the date shift from June
30th to July 1st. Although, stations still running 2.6.18 to 2.6.20.11
worked flawlessly.
I first tought there had been an electricity outage but two of my
servers (dell PE 2950 dual-quad core) on UPS in our server room also
hanged:
Jun 30 23:55:01 urpdev1 /USR/SBIN/CRON[31298]: (root) CMD ([ -x
/usr/lib/sysstat/sa1 ] { [ -r $DEFAULT ] . $DEFAULT ; [
$ENABLED = true ] exec /usr/lib/sysstat/sa1; })
Jul 3 11:54:03 urpdev1 syslogd 1.4.1#17: restart.
I could not get anything on any of the 20+ consoles... All the systems
hanged at around the exact same time... When the date shifted from June
30th to July 1st in UTC ...?
Any clue any one?
No problems over here with plain 2.6.21.5 on x686
You could just reset the date back on one of these machines and
check the transition again... and see if it was really the kernel
who crashed and check your cron configuration.
Regards,
--
Clemens Koller
__
RD Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5: BUG: usbtouchscreen.c DMC TSC-10 wrong descriptor type / type->init() failed.
Hello, Dimitry! Dmitry Torokhov schrieb: Hi, On 6/27/07, Clemens Koller <[EMAIL PROTECTED]> wrote: drivers/usb/input/usbtouchscreen.c: usbtouch_probe - type->init() failed, err: -19 dmc_tsc10_init() returns -ENODEV (-19) when device responds with something other than 0x06 0x00 to the "reset" and "set rate" commands. It would be interesting to see what your touchscreen responses are. I found the problem: After the reset, I got a 0x06 0x00 back, which is fine. But when the driver sets the coordinate output rate, the TSC-103 answered 0x15 0x01 which means that the TSC-10 is used with an EEPROM but the EEPROM data is empty (which is correct). In that case the driver should at least continue to allow initialization of the EEPROM later on. But as we don't have the infrastructure to write the calibration data back to EEPROM, only touch screen manufacturers which want to use the EEPROM will run into that problem... The same is true if there is no EEPROM present but the EEPROM is enabled. Anyway, I disabled my EEPROM by pulling the SEL4 pin high because I don't need/want it (yet). So, it *works for me* but just for future reference: The DMC TSC-10 driver doesn't start, when it has an empty (new) EEPROM attached. I started to do some more error handling, but it's propably not worth doing so if the driver(s) has only limited functionality (and no userspace app using it). Thank you, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5: BUG: usbtouchscreen.c DMC TSC-10 wrong descriptor type / type-init() failed.
Hello, Dimitry! Dmitry Torokhov schrieb: Hi, On 6/27/07, Clemens Koller [EMAIL PROTECTED] wrote: drivers/usb/input/usbtouchscreen.c: usbtouch_probe - type-init() failed, err: -19 dmc_tsc10_init() returns -ENODEV (-19) when device responds with something other than 0x06 0x00 to the reset and set rate commands. It would be interesting to see what your touchscreen responses are. I found the problem: After the reset, I got a 0x06 0x00 back, which is fine. But when the driver sets the coordinate output rate, the TSC-103 answered 0x15 0x01 which means that the TSC-10 is used with an EEPROM but the EEPROM data is empty (which is correct). In that case the driver should at least continue to allow initialization of the EEPROM later on. But as we don't have the infrastructure to write the calibration data back to EEPROM, only touch screen manufacturers which want to use the EEPROM will run into that problem... The same is true if there is no EEPROM present but the EEPROM is enabled. Anyway, I disabled my EEPROM by pulling the SEL4 pin high because I don't need/want it (yet). So, it *works for me* but just for future reference: The DMC TSC-10 driver doesn't start, when it has an empty (new) EEPROM attached. I started to do some more error handling, but it's propably not worth doing so if the driver(s) has only limited functionality (and no userspace app using it). Thank you, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5: BUG: usbtouchscreen.c DMC TSC-10 wrong descriptor type / type->init() failed.
Hello, Dimitry! Dmitry Torokhov schrieb: On 6/27/07, Clemens Koller <[EMAIL PROTECTED]> wrote: drivers/usb/input/usbtouchscreen.c: usbtouch_probe - type->init() failed, err: -19 dmc_tsc10_init() returns -ENODEV (-19) when device responds with something other than 0x06 0x00 to the "reset" and "set rate" commands. It would be interesting to see what your touchscreen responses are. Yes, thank you! I just had a look into the datasheet. (tsc10usb_pi_e.pdf, Rev. 1.2 from November 1, 2005) and I will need more debugging info to the dmc_tsc10_init()... As I wrote, I am using the TSC-103 without EEPROM. (I can add one if it's of any use.) The PanelID is 0 (pin 3 [SEL1] is low), so it's the "first" device on the bus. What exact chip version and EEPROM configuration do you use? I guess there are different firmware releases for the different TSC-10* devices which behave... well... different. :-( Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21.5: BUG: usbtouchscreen.c DMC TSC-10 wrong descriptor type / type->init() failed.
Hello, again!
Well, with lots of debugging enabled, I got to some more details about the
non working DMC TSC-10 USB Touchscreen:
(see also: http://lkml.org/lkml/2007/6/26/228 )
Whenever I plug in the TSC-10 I get the following output
hub 3-0:1.0: state 7 ports 4 chg evt 0004
ehci_hcd :00:14.2: GetStatus port 2 status 001403 POWER sig=k CSC CONNECT
hub 3-0:1.0: port 2, status 0501, change 0001, 480 Mb/s
hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501
ehci_hcd :00:14.2: port 2 low speed --> companion
ehci_hcd :00:14.2: GetStatus port 2 status 003402 POWER OWNER sig=k CSC
hub 3-0:1.0: state 7 ports 4 chg evt 0004
hub 2-0:1.0: state 7 ports 2 chg evt 0002
ohci_hcd :00:14.1: GetStatus roothub.portstatus [0] = 0x00010301 CSC LSDA
PPS CCS
hub 2-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s
hub 2-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x301
ohci_hcd :00:14.1: GetStatus roothub.portstatus [0] = 0x00100303 PRSC LSDA
PPS PES CCS
usb 2-1: new low speed USB device using ohci_hcd and address 16
ohci_hcd :00:14.1: GetStatus roothub.portstatus [0] = 0x00100303 PRSC LSDA
PPS PES CCS
usb 2-1: default language 0x0054
usb 2-1: wrong descriptor type 00 for string 1 ("TSC-10 DM")
usb 2-1: new device strings: Mfr=1, Product=0, SerialNumber=0
usb 2-1: Manufacturer: TSC-10 DM
usb 2-1: uevent
usb 2-1: usb_probe_device
usb 2-1: configuration #1 chosen from 1 choice
usb 2-1: adding 2-1:1.0 (config #1, interface 0)
usb 2-1:1.0: uevent
usbtouchscreen 2-1:1.0: usb_probe_interface
usbtouchscreen 2-1:1.0: usb_probe_interface - got id
drivers/usb/input/usbtouchscreen.c: usbtouch_probe - type->init() failed, err:
-19
drivers/usb/core/inode.c: creating file '016'
hub 2-0:1.0: state 7 ports 2 chg evt 0002
And when I unplug it, it cleans up the device properly:
hub 2-0:1.0: state 7 ports 2 chg evt 0002
ohci_hcd :00:14.1: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
hub 2-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
usb 2-1: USB disconnect, address 16
usb 2-1: unregistering device
usb 2-1: usb_disable_device nuking all URBs
usb 2-1: unregistering interface 2-1:1.0
usbdev2.16_ep81: ep_device_release called for usbdev2.16_ep81
usb 2-1:1.0: uevent
usbdev2.16_ep00: ep_device_release called for usbdev2.16_ep00
usb 2-1: uevent
hub 2-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
Any ideas of what's wrong here before I have to start to
dig deeper in the source?!
The touchscreen controller chip is a TSC-103 088 F3J0
it has no EEPROM attached. (which should be optional to save
calibration data)
The USB controller is a Philips ISP1563BM PCI Host Controller
DateCode April-2006.
The same problem appears with 2.6.21.5 and 2.6.20.1-ubuntu-something
on x86 platform.
--
Clemens Koller
__
R Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 BUG: USB FTDI FT323BM usb exports duplicate symbols
Oliver Neukum schrieb: Am Mittwoch, 27. Juni 2007 schrieb Clemens Koller: Whenever I plug/unplug the FTDI FT232BM USB-RS232 converter, the latest 2.6.21.5 kernel complains: usb 2-1: USB disconnect, address 7 ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 ftdi_sio 2-1:1.0: device disconnected usb 3-1: new full speed USB device using ohci_hcd and address 43 usb 3-1: configuration #1 chosen from 1 choice ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232BM usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0 usbcore: exports duplicate symbol usb_buffer_unmap_sg (owned by kernel) usbserial: exports duplicate symbol usb_serial_port_softint (owned by kernel) Please rebuild your kernel and modules from scratch. It looks like you are mixing builds. Okay, I rebuilt the kernel in a new tree and cleaned up /lib/modules/* so, the problem is solved. Thank you. -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 BUG: USB FTDI FT323BM usb exports duplicate symbols
Hi, Oliver! Oliver Neukum schrieb: Am Mittwoch, 27. Juni 2007 schrieb Clemens Koller: Whenever I plug/unplug the FTDI FT232BM USB-RS232 converter, the latest 2.6.21.5 kernel complains: usb 2-1: USB disconnect, address 7 ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 ftdi_sio 2-1:1.0: device disconnected usb 3-1: new full speed USB device using ohci_hcd and address 43 usb 3-1: configuration #1 chosen from 1 choice ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232BM usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0 usbcore: exports duplicate symbol usb_buffer_unmap_sg (owned by kernel) usbserial: exports duplicate symbol usb_serial_port_softint (owned by kernel) Please rebuild your kernel and modules from scratch. It looks like you are mixing builds. Thanks, I will give it a try. -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21.5 BUG: USB FTDI FT323BM usb exports duplicate symbols
Whenever I plug/unplug the FTDI FT232BM USB-RS232 converter, the latest 2.6.21.5 kernel complains: usb 2-1: USB disconnect, address 7 ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 ftdi_sio 2-1:1.0: device disconnected usb 3-1: new full speed USB device using ohci_hcd and address 43 usb 3-1: configuration #1 chosen from 1 choice ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232BM usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0 usbcore: exports duplicate symbol usb_buffer_unmap_sg (owned by kernel) usbserial: exports duplicate symbol usb_serial_port_softint (owned by kernel) kobject_add failed for ftdi_sio with -EEXIST, don't try to register things with the same name in the same directory. Call Trace: [C4A6DE10] [C0009018] show_stack+0x4c/0x1ac (unreliable) [C4A6DE50] [C013DF80] kobject_shadow_add+0x160/0x1a4 [C4A6DE70] [C003A250] mod_sysfs_setup+0x28/0xd4 [C4A6DE90] [C003B4BC] sys_init_module+0xfc4/0x149c [C4A6DF40] [C0002304] ret_from_syscall+0x0/0x3c usb 3-1: USB disconnect, address 43 ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 ftdi_sio 3-1:1.0: device disconnected usb 3-1: new full speed USB device using ohci_hcd and address 44 usb 3-1: configuration #1 chosen from 1 choice ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232BM usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0 usbcore: exports duplicate symbol usb_buffer_unmap_sg (owned by kernel) usbserial: exports duplicate symbol usb_serial_port_softint (owned by kernel) kobject_add failed for ftdi_sio with -EEXIST, don't try to register things with the same name in the same directory. Call Trace: [C50BFE10] [C0009018] show_stack+0x4c/0x1ac (unreliable) [C50BFE50] [C013DF80] kobject_shadow_add+0x160/0x1a4 [C50BFE70] [C003A250] mod_sysfs_setup+0x28/0xd4 [C50BFE90] [C003B4BC] sys_init_module+0xfc4/0x149c [C50BFF40] [C0002304] ret_from_syscall+0x0/0x3c Is this considered harmful? Let me know if you need more debugging information. Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21.5 BUG: USB FTDI FT323BM usb exports duplicate symbols
Whenever I plug/unplug the FTDI FT232BM USB-RS232 converter, the latest 2.6.21.5 kernel complains: usb 2-1: USB disconnect, address 7 ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 ftdi_sio 2-1:1.0: device disconnected usb 3-1: new full speed USB device using ohci_hcd and address 43 usb 3-1: configuration #1 chosen from 1 choice ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232BM usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0 usbcore: exports duplicate symbol usb_buffer_unmap_sg (owned by kernel) usbserial: exports duplicate symbol usb_serial_port_softint (owned by kernel) kobject_add failed for ftdi_sio with -EEXIST, don't try to register things with the same name in the same directory. Call Trace: [C4A6DE10] [C0009018] show_stack+0x4c/0x1ac (unreliable) [C4A6DE50] [C013DF80] kobject_shadow_add+0x160/0x1a4 [C4A6DE70] [C003A250] mod_sysfs_setup+0x28/0xd4 [C4A6DE90] [C003B4BC] sys_init_module+0xfc4/0x149c [C4A6DF40] [C0002304] ret_from_syscall+0x0/0x3c usb 3-1: USB disconnect, address 43 ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 ftdi_sio 3-1:1.0: device disconnected usb 3-1: new full speed USB device using ohci_hcd and address 44 usb 3-1: configuration #1 chosen from 1 choice ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232BM usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0 usbcore: exports duplicate symbol usb_buffer_unmap_sg (owned by kernel) usbserial: exports duplicate symbol usb_serial_port_softint (owned by kernel) kobject_add failed for ftdi_sio with -EEXIST, don't try to register things with the same name in the same directory. Call Trace: [C50BFE10] [C0009018] show_stack+0x4c/0x1ac (unreliable) [C50BFE50] [C013DF80] kobject_shadow_add+0x160/0x1a4 [C50BFE70] [C003A250] mod_sysfs_setup+0x28/0xd4 [C50BFE90] [C003B4BC] sys_init_module+0xfc4/0x149c [C50BFF40] [C0002304] ret_from_syscall+0x0/0x3c Is this considered harmful? Let me know if you need more debugging information. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 BUG: USB FTDI FT323BM usb exports duplicate symbols
Hi, Oliver! Oliver Neukum schrieb: Am Mittwoch, 27. Juni 2007 schrieb Clemens Koller: Whenever I plug/unplug the FTDI FT232BM USB-RS232 converter, the latest 2.6.21.5 kernel complains: usb 2-1: USB disconnect, address 7 ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 ftdi_sio 2-1:1.0: device disconnected usb 3-1: new full speed USB device using ohci_hcd and address 43 usb 3-1: configuration #1 chosen from 1 choice ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232BM usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0 usbcore: exports duplicate symbol usb_buffer_unmap_sg (owned by kernel) usbserial: exports duplicate symbol usb_serial_port_softint (owned by kernel) Please rebuild your kernel and modules from scratch. It looks like you are mixing builds. Thanks, I will give it a try. -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 BUG: USB FTDI FT323BM usb exports duplicate symbols
Oliver Neukum schrieb: Am Mittwoch, 27. Juni 2007 schrieb Clemens Koller: Whenever I plug/unplug the FTDI FT232BM USB-RS232 converter, the latest 2.6.21.5 kernel complains: usb 2-1: USB disconnect, address 7 ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 ftdi_sio 2-1:1.0: device disconnected usb 3-1: new full speed USB device using ohci_hcd and address 43 usb 3-1: configuration #1 chosen from 1 choice ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232BM usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0 usbcore: exports duplicate symbol usb_buffer_unmap_sg (owned by kernel) usbserial: exports duplicate symbol usb_serial_port_softint (owned by kernel) Please rebuild your kernel and modules from scratch. It looks like you are mixing builds. Okay, I rebuilt the kernel in a new tree and cleaned up /lib/modules/* so, the problem is solved. Thank you. -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21.5: BUG: usbtouchscreen.c DMC TSC-10 wrong descriptor type / type-init() failed.
Hello, again! Well, with lots of debugging enabled, I got to some more details about the non working DMC TSC-10 USB Touchscreen: (see also: http://lkml.org/lkml/2007/6/26/228 ) Whenever I plug in the TSC-10 I get the following output hub 3-0:1.0: state 7 ports 4 chg evt 0004 ehci_hcd :00:14.2: GetStatus port 2 status 001403 POWER sig=k CSC CONNECT hub 3-0:1.0: port 2, status 0501, change 0001, 480 Mb/s hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501 ehci_hcd :00:14.2: port 2 low speed -- companion ehci_hcd :00:14.2: GetStatus port 2 status 003402 POWER OWNER sig=k CSC hub 3-0:1.0: state 7 ports 4 chg evt 0004 hub 2-0:1.0: state 7 ports 2 chg evt 0002 ohci_hcd :00:14.1: GetStatus roothub.portstatus [0] = 0x00010301 CSC LSDA PPS CCS hub 2-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s hub 2-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x301 ohci_hcd :00:14.1: GetStatus roothub.portstatus [0] = 0x00100303 PRSC LSDA PPS PES CCS usb 2-1: new low speed USB device using ohci_hcd and address 16 ohci_hcd :00:14.1: GetStatus roothub.portstatus [0] = 0x00100303 PRSC LSDA PPS PES CCS usb 2-1: default language 0x0054 usb 2-1: wrong descriptor type 00 for string 1 (TSC-10 DM) usb 2-1: new device strings: Mfr=1, Product=0, SerialNumber=0 usb 2-1: Manufacturer: TSC-10 DM usb 2-1: uevent usb 2-1: usb_probe_device usb 2-1: configuration #1 chosen from 1 choice usb 2-1: adding 2-1:1.0 (config #1, interface 0) usb 2-1:1.0: uevent usbtouchscreen 2-1:1.0: usb_probe_interface usbtouchscreen 2-1:1.0: usb_probe_interface - got id drivers/usb/input/usbtouchscreen.c: usbtouch_probe - type-init() failed, err: -19 drivers/usb/core/inode.c: creating file '016' hub 2-0:1.0: state 7 ports 2 chg evt 0002 And when I unplug it, it cleans up the device properly: hub 2-0:1.0: state 7 ports 2 chg evt 0002 ohci_hcd :00:14.1: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS hub 2-0:1.0: port 1, status 0100, change 0001, 12 Mb/s usb 2-1: USB disconnect, address 16 usb 2-1: unregistering device usb 2-1: usb_disable_device nuking all URBs usb 2-1: unregistering interface 2-1:1.0 usbdev2.16_ep81: ep_device_release called for usbdev2.16_ep81 usb 2-1:1.0: uevent usbdev2.16_ep00: ep_device_release called for usbdev2.16_ep00 usb 2-1: uevent hub 2-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100 Any ideas of what's wrong here before I have to start to dig deeper in the source?! The touchscreen controller chip is a TSC-103 088 F3J0 it has no EEPROM attached. (which should be optional to save calibration data) The USB controller is a Philips ISP1563BM PCI Host Controller DateCode April-2006. The same problem appears with 2.6.21.5 and 2.6.20.1-ubuntu-something on x86 platform. -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5: BUG: usbtouchscreen.c DMC TSC-10 wrong descriptor type / type-init() failed.
Hello, Dimitry! Dmitry Torokhov schrieb: On 6/27/07, Clemens Koller [EMAIL PROTECTED] wrote: drivers/usb/input/usbtouchscreen.c: usbtouch_probe - type-init() failed, err: -19 dmc_tsc10_init() returns -ENODEV (-19) when device responds with something other than 0x06 0x00 to the reset and set rate commands. It would be interesting to see what your touchscreen responses are. Yes, thank you! I just had a look into the datasheet. (tsc10usb_pi_e.pdf, Rev. 1.2 from November 1, 2005) and I will need more debugging info to the dmc_tsc10_init()... As I wrote, I am using the TSC-103 without EEPROM. (I can add one if it's of any use.) The PanelID is 0 (pin 3 [SEL1] is low), so it's the first device on the bus. What exact chip version and EEPROM configuration do you use? I guess there are different firmware releases for the different TSC-10* devices which behave... well... different. :-( Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
no luck with DMC TSC-10 touchscreen on USB
CONFIG_INPUT_JOYSTICK is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_INPUT_MISC is not set
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
$ udevinfo -V
udevinfo, version 096
$ udevinfo -a -p /sys/devices/pci:00/:00:14.1/usb3/3-1
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci:00/:00:14.1/usb3/3-1':
KERNEL=="3-1"
SUBSYSTEM=="usb"
SYSFS{manufacturer}=="TSC-10 DM"
SYSFS{quirks}=="0x0"
SYSFS{maxchild}=="0"
SYSFS{version}==" 1.00"
SYSFS{devnum}=="24"
SYSFS{speed}=="1.5"
SYSFS{bMaxPacketSize0}=="8"
SYSFS{bNumConfigurations}=="1"
SYSFS{bDeviceProtocol}=="ff"
SYSFS{bDeviceSubClass}=="00"
SYSFS{bDeviceClass}=="ff"
SYSFS{bcdDevice}=="0110"
SYSFS{idProduct}=="03e8"
SYSFS{idVendor}=="0afa"
SYSFS{bMaxPower}=="100mA"
SYSFS{bmAttributes}=="a0"
SYSFS{bConfigurationValue}=="1"
SYSFS{bNumInterfaces}==" 1"
SYSFS{configuration}==""
looking at parent device '/devices/pci:00/:00:14.1/usb3':
ID=="usb3"
BUS=="usb"
DRIVER=="usb"
SYSFS{serial}==":00:14.1"
SYSFS{product}=="OHCI Host Controller"
SYSFS{manufacturer}=="Linux 2.6.21.5 ohci_hcd"
SYSFS{quirks}=="0x0"
SYSFS{maxchild}=="2"
SYSFS{version}==" 1.10"
SYSFS{devnum}=="1"
SYSFS{speed}=="12"
SYSFS{bMaxPacketSize0}=="64"
SYSFS{bNumConfigurations}=="1"
SYSFS{bDeviceProtocol}=="00"
SYSFS{bDeviceSubClass}=="00"
SYSFS{bDeviceClass}=="09"
SYSFS{bcdDevice}=="0206"
SYSFS{idProduct}==""
SYSFS{idVendor}==""
SYSFS{bMaxPower}==" 0mA"
SYSFS{bmAttributes}=="e0"
SYSFS{bConfigurationValue}=="1"
SYSFS{bNumInterfaces}==" 1"
SYSFS{configuration}==""
looking at parent device '/devices/pci:00/:00:14.1':
ID==":00:14.1"
BUS=="pci"
DRIVER=="ohci_hcd"
SYSFS{msi_bus}==""
SYSFS{broken_parity_status}=="0"
SYSFS{enable}=="1"
SYSFS{modalias}=="pci:v1131d1561sv1131sd1561bc0Csc03i10"
SYSFS{local_cpus}=="1"
SYSFS{irq}=="51"
SYSFS{class}=="0x0c0310"
SYSFS{subsystem_device}=="0x1561"
SYSFS{subsystem_vendor}=="0x1131"
SYSFS{device}=="0x1561"
SYSFS{vendor}=="0x1131"
looking at parent device '/devices/pci:00':
ID=="pci:00"
BUS==""
DRIVER==""
--
Clemens Koller
__
R Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
no luck with DMC TSC-10 touchscreen on USB
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
$ udevinfo -V
udevinfo, version 096
$ udevinfo -a -p /sys/devices/pci:00/:00:14.1/usb3/3-1
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci:00/:00:14.1/usb3/3-1':
KERNEL==3-1
SUBSYSTEM==usb
SYSFS{manufacturer}==TSC-10 DM
SYSFS{quirks}==0x0
SYSFS{maxchild}==0
SYSFS{version}== 1.00
SYSFS{devnum}==24
SYSFS{speed}==1.5
SYSFS{bMaxPacketSize0}==8
SYSFS{bNumConfigurations}==1
SYSFS{bDeviceProtocol}==ff
SYSFS{bDeviceSubClass}==00
SYSFS{bDeviceClass}==ff
SYSFS{bcdDevice}==0110
SYSFS{idProduct}==03e8
SYSFS{idVendor}==0afa
SYSFS{bMaxPower}==100mA
SYSFS{bmAttributes}==a0
SYSFS{bConfigurationValue}==1
SYSFS{bNumInterfaces}== 1
SYSFS{configuration}==
looking at parent device '/devices/pci:00/:00:14.1/usb3':
ID==usb3
BUS==usb
DRIVER==usb
SYSFS{serial}==:00:14.1
SYSFS{product}==OHCI Host Controller
SYSFS{manufacturer}==Linux 2.6.21.5 ohci_hcd
SYSFS{quirks}==0x0
SYSFS{maxchild}==2
SYSFS{version}== 1.10
SYSFS{devnum}==1
SYSFS{speed}==12
SYSFS{bMaxPacketSize0}==64
SYSFS{bNumConfigurations}==1
SYSFS{bDeviceProtocol}==00
SYSFS{bDeviceSubClass}==00
SYSFS{bDeviceClass}==09
SYSFS{bcdDevice}==0206
SYSFS{idProduct}==
SYSFS{idVendor}==
SYSFS{bMaxPower}== 0mA
SYSFS{bmAttributes}==e0
SYSFS{bConfigurationValue}==1
SYSFS{bNumInterfaces}== 1
SYSFS{configuration}==
looking at parent device '/devices/pci:00/:00:14.1':
ID==:00:14.1
BUS==pci
DRIVER==ohci_hcd
SYSFS{msi_bus}==
SYSFS{broken_parity_status}==0
SYSFS{enable}==1
SYSFS{modalias}==pci:v1131d1561sv1131sd1561bc0Csc03i10
SYSFS{local_cpus}==1
SYSFS{irq}==51
SYSFS{class}==0x0c0310
SYSFS{subsystem_device}==0x1561
SYSFS{subsystem_vendor}==0x1131
SYSFS{device}==0x1561
SYSFS{vendor}==0x1131
looking at parent device '/devices/pci:00':
ID==pci:00
BUS==
DRIVER==
--
Clemens Koller
__
RD Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cross-architecture ELF clean up
Hi, Roman! Roman Zippel schrieb: Hi, On Mon, 25 Jun 2007, David Woodhouse wrote: On Wed, 2007-06-20 at 16:08 -0700, Jeremy Fitzhardinge wrote: This patch cleans up the ELF headers and their users. It does several related things: Looks good. We can get away with exporting a lot less of this to userspace too, can't we? glibc provides its own version, so it doesn't has to be exported at all. AFAIK the glibc folks want to rely more on the linux kernel headers in the future and not provide more or less redundant headers anymore... Please talk to them about the future plans. Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cross-architecture ELF clean up
Hi, Roman! Roman Zippel schrieb: Hi, On Mon, 25 Jun 2007, David Woodhouse wrote: On Wed, 2007-06-20 at 16:08 -0700, Jeremy Fitzhardinge wrote: This patch cleans up the ELF headers and their users. It does several related things: Looks good. We can get away with exporting a lot less of this to userspace too, can't we? glibc provides its own version, so it doesn't has to be exported at all. AFAIK the glibc folks want to rely more on the linux kernel headers in the future and not provide more or less redundant headers anymore... Please talk to them about the future plans. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
