Re: "scheduling while atomic" ?
On Tue, 12 Jul 2005, Mateusz Berezecki wrote: Hi LKML, What does the message saying "scheduling while atomic" mean? The kernel prints a stack backtrace after this message appears so I suppose this is not a good behaviour. I am finishing an open source driver, and I need to do all of this locking stuff, etc. and this really makes me wonder what I am doing wrong. here is some part of a backtrace... scheduling while atomic: insmod/0x0001/12692 [] schedule+0x632/0x640 [] __wake_up_common+0x41/0x70 [] wait_for_completion+0x8f/0xf0 [] default_wake_function+0x0/0x20 [] default_wake_function+0x0/0x20 [] queue_work+0x8d/0xa0 [] __call_usermodehelper+0x0/0x70 [] call_usermodehelper_keys+0xc5/0xd0 [] __call_usermodehelper+0x0/0x70 [] sprintf+0x28/0x30 [] kobject_hotplug+0x29d/0x310 [] sysfs_create_link+0x3e/0x60 [] class_device_add+0x161/0x1e0 [] netdev_register_sysfs+0x3e/0x100 [] netdev_run_todo+0x1eb/0x220 [] register_netdev+0x5e/0x90 I enable a lock at the beginning of device attach routine and I disable it at the end. Whats wrong with it? You probably have the interrupts disabled (a spin-lock locked) when some timer or other routine that will schedule() is called. Also, make sure that you initialize all your spin-locks and semaphores before you try to use them. Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386: Selectable Frequency of the Timer Interrupt
On Tue, 12 Jul 2005, Jan Engelhardt wrote: Hi, Vojtech Pavlik @ Tue, 12 Jul 2005 14:10:08 +0200 wrote: (http://lkml.org/lkml/2005/7/12/122) On Mon, Jul 11, 2005 at 05:38:05PM -0700, George Anzinger wrote: HZ TICK RATE jiffie(ns) second(ns) error (ppbillion) 100 1193180100010 0 The PIT crystal runs at 14.3181818 MHz (CGA dotclock, found on ISA, ...) and is divided by 12 to get PIT tick rate 14.3181818 MHz / 12 = 1193182 Hz What exactly is the frequency of the PIT? Many internet resources say 1193180 (including the original post), some say 1193181, and you say 1193182 Hz. Which one is correct? (Ignoring temperature for now..) The original specification was based upon the NTSC color subcarrier frequency of 3.579545. The dotclock is 4 times this: 3.579745 * 4 = 14.31818000 You can type 3.579545 into google and see it's used practically everywhere as the magic number that started it all ;^) The crooked-earth society uses this for PI (just kidding). IMO 1193181 could be, because it matches the almost-magical number 0x1234DD. Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cannot fix unresolved module symbols
On Tue, 12 Jul 2005, Mark Williams (MWP) wrote: Greetings all, First, im using 2.6.12 with version 3.1 of module-install-utils and GCC 4.0.1. I simply cannot get kernel modules to install. Building the kernel and modules works perfecty, no errors. But on running "make modules_install" i get: depmod: QM_MODULES: Function not implemented INSTALL drivers/net/wireless/atmel.ko if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 2.6.12; fi depmod: *** Unresolved symbols in /lib/modules/2.6.12/kernel/drivers/net/wireless/atmel.ko depmod: __netdev_watchdog_up depmod: preempt_schedule depmod: _mmx_memcpy depmod: eth_type_trans depmod: param_get_charp depmod: __kfree_skb depmod: alloc_skb and many more Ive had this problem since i started using 2.6.x, and have always compiled drivers into the kernel to avoid it. But now i do need to get this fixed so i can get ndiswrapper working. Does anyone know what could be wrong? Thanks. depmod: QM_MODULES: Function not implemented ^^^ The hint: Upgrade your modules tools. (module-init-tools-3.2.tar.gz) Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel guide to space
On Tue, 12 Jul 2005, Patrick McHardy wrote:
Denis Vlasenko wrote:
text with 8-char tabs:
struct s {
int n; /* comment */
unsigned int u; /* comment */
};
Same text viewed with tabs set to 4-char width:
struct s {
int n; /* comment */
unsigned int u; /* comment */
};
Comments are not aligned anymore
Best rule IMO is to use tabs for indentation and spaces for alignment.
This way tab size can be changed without breaking alignment.
Or just disallow tabs altogether. At Analogic we had several hundred
thousand lines of imaging code from various engineers around the world.
They would set their tabs so everything looked fine on their computers.
On other computers, it looked like hell so engineers who had to
merge code spent hundreds of wasted hours lining up the code. The
"cleanup" work never stopped! That was until, we made a rule that
all code would be run through a filter that would remove tabs and
substitute spaces (of the width the writer intended). No code that
is released contains even a single tab anymode.
The files are larger of course, but even lap-tops have gigabyte
drives now-days and the duplicate spaces give compression utilities
something to do.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel guide to space
On Tue, 12 Jul 2005, Patrick McHardy wrote:
Denis Vlasenko wrote:
text with 8-char tabs:
struct s {
int n; /* comment */
unsigned int u; /* comment */
};
Same text viewed with tabs set to 4-char width:
struct s {
int n; /* comment */
unsigned int u; /* comment */
};
Comments are not aligned anymore
Best rule IMO is to use tabs for indentation and spaces for alignment.
This way tab size can be changed without breaking alignment.
Or just disallow tabs altogether. At Analogic we had several hundred
thousand lines of imaging code from various engineers around the world.
They would set their tabs so everything looked fine on their computers.
On other computers, it looked like hell so engineers who had to
merge code spent hundreds of wasted hours lining up the code. The
cleanup work never stopped! That was until, we made a rule that
all code would be run through a filter that would remove tabs and
substitute spaces (of the width the writer intended). No code that
is released contains even a single tab anymode.
The files are larger of course, but even lap-tops have gigabyte
drives now-days and the duplicate spaces give compression utilities
something to do.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Cannot fix unresolved module symbols
On Tue, 12 Jul 2005, Mark Williams (MWP) wrote: Greetings all, First, im using 2.6.12 with version 3.1 of module-install-utils and GCC 4.0.1. I simply cannot get kernel modules to install. Building the kernel and modules works perfecty, no errors. But on running make modules_install i get: depmod: QM_MODULES: Function not implemented INSTALL drivers/net/wireless/atmel.ko if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 2.6.12; fi depmod: *** Unresolved symbols in /lib/modules/2.6.12/kernel/drivers/net/wireless/atmel.ko depmod: __netdev_watchdog_up depmod: preempt_schedule depmod: _mmx_memcpy depmod: eth_type_trans depmod: param_get_charp depmod: __kfree_skb depmod: alloc_skb and many more Ive had this problem since i started using 2.6.x, and have always compiled drivers into the kernel to avoid it. But now i do need to get this fixed so i can get ndiswrapper working. Does anyone know what could be wrong? Thanks. depmod: QM_MODULES: Function not implemented ^^^ The hint: Upgrade your modules tools. (module-init-tools-3.2.tar.gz) Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386: Selectable Frequency of the Timer Interrupt
On Tue, 12 Jul 2005, Jan Engelhardt wrote: Hi, Vojtech Pavlik @ Tue, 12 Jul 2005 14:10:08 +0200 wrote: (http://lkml.org/lkml/2005/7/12/122) On Mon, Jul 11, 2005 at 05:38:05PM -0700, George Anzinger wrote: HZ TICK RATE jiffie(ns) second(ns) error (ppbillion) 100 1193180100010 0 The PIT crystal runs at 14.3181818 MHz (CGA dotclock, found on ISA, ...) and is divided by 12 to get PIT tick rate 14.3181818 MHz / 12 = 1193182 Hz What exactly is the frequency of the PIT? Many internet resources say 1193180 (including the original post), some say 1193181, and you say 1193182 Hz. Which one is correct? (Ignoring temperature for now..) The original specification was based upon the NTSC color subcarrier frequency of 3.579545. The dotclock is 4 times this: 3.579745 * 4 = 14.31818000 You can type 3.579545 into google and see it's used practically everywhere as the magic number that started it all ;^) The crooked-earth society uses this for PI (just kidding). IMO 1193181 could be, because it matches the almost-magical number 0x1234DD. Jan Engelhardt -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scheduling while atomic ?
On Tue, 12 Jul 2005, Mateusz Berezecki wrote: Hi LKML, What does the message saying scheduling while atomic mean? The kernel prints a stack backtrace after this message appears so I suppose this is not a good behaviour. I am finishing an open source driver, and I need to do all of this locking stuff, etc. and this really makes me wonder what I am doing wrong. here is some part of a backtrace... scheduling while atomic: insmod/0x0001/12692 [c03e7352] schedule+0x632/0x640 [c0119bb1] __wake_up_common+0x41/0x70 [c03e74df] wait_for_completion+0x8f/0xf0 [c0119b50] default_wake_function+0x0/0x20 [c0119b50] default_wake_function+0x0/0x20 [c012e2dd] queue_work+0x8d/0xa0 [c012e070] __call_usermodehelper+0x0/0x70 [c012e1a5] call_usermodehelper_keys+0xc5/0xd0 [c012e070] __call_usermodehelper+0x0/0x70 [c020c028] sprintf+0x28/0x30 [c020955d] kobject_hotplug+0x29d/0x310 [c019fc6e] sysfs_create_link+0x3e/0x60 [c028b601] class_device_add+0x161/0x1e0 [c036f38e] netdev_register_sysfs+0x3e/0x100 [c03650db] netdev_run_todo+0x1eb/0x220 [c0364dce] register_netdev+0x5e/0x90 I enable a lock at the beginning of device attach routine and I disable it at the end. Whats wrong with it? You probably have the interrupts disabled (a spin-lock locked) when some timer or other routine that will schedule() is called. Also, make sure that you initialize all your spin-locks and semaphores before you try to use them. Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Instruction Tracing for Linux
Please read: http://www.adapti.com/instruction-trace.html It's part of an advertisement, but will tell you the problems you will have with a "software solution". Basically, software can't do it. Also, even hardware won't give you the real picture because there is too much going on inside the CPUs that you can't see. However a hardware/software solution can produce some useful information but it's not very accurate. On Fri, 8 Jul 2005, Adnan Khaleel wrote: Hi there, I'm a hardware designer and I'm interested in collecting dynamic execution traces in Linux. I've looked at several trace toolkits available for Linux currently but none of them offer the level of detail that I need. Ideally I would like to be able to record the instructions being executed on an SMP system along with markers for system or user space in addition to process id. I need these traces in order to evaluate the data sharing, coherence traffic etc in larger SMP systems. I've tried several other approaches to collecting execution traces namely via machine emulators etc but so far I've been dogged with the problem of trying to get any OS up and running stably on a multiprocessor configuration. Is there a Linux kernel patch that will let me do this? I have considered using User Mode Linux but I'm not sure if this is the correct approach either - if any of you think that this is the easier path, I'd be interested in exploring this more. Other things that have crossed my mind is to use a gdb or the kernel debugger interface in order to collect the instructions but I'm not sure if this would be the correct path. Also I do require the tool/patch to be stable enough so that I can run commercial benchmarks on it reliably. I understand that recording every executed instruction can considerably slow down the application and may be considerably different from the freely running application but nevertheless I think that some trace is better than no trace and this is where I am at the moment. If any of you have had experiences in profiling the kernel etc by collecting actual kernel instructions executed, I'd be interested in seeing if that may be extended for my purpose. Thanks Adnan PS: I'm not subscribed to this mailing list so I'd appreciated if you would cc me on the responses. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Instruction Tracing for Linux
Please read: http://www.adapti.com/instruction-trace.html It's part of an advertisement, but will tell you the problems you will have with a software solution. Basically, software can't do it. Also, even hardware won't give you the real picture because there is too much going on inside the CPUs that you can't see. However a hardware/software solution can produce some useful information but it's not very accurate. On Fri, 8 Jul 2005, Adnan Khaleel wrote: Hi there, I'm a hardware designer and I'm interested in collecting dynamic execution traces in Linux. I've looked at several trace toolkits available for Linux currently but none of them offer the level of detail that I need. Ideally I would like to be able to record the instructions being executed on an SMP system along with markers for system or user space in addition to process id. I need these traces in order to evaluate the data sharing, coherence traffic etc in larger SMP systems. I've tried several other approaches to collecting execution traces namely via machine emulators etc but so far I've been dogged with the problem of trying to get any OS up and running stably on a multiprocessor configuration. Is there a Linux kernel patch that will let me do this? I have considered using User Mode Linux but I'm not sure if this is the correct approach either - if any of you think that this is the easier path, I'd be interested in exploring this more. Other things that have crossed my mind is to use a gdb or the kernel debugger interface in order to collect the instructions but I'm not sure if this would be the correct path. Also I do require the tool/patch to be stable enough so that I can run commercial benchmarks on it reliably. I understand that recording every executed instruction can considerably slow down the application and may be considerably different from the freely running application but nevertheless I think that some trace is better than no trace and this is where I am at the moment. If any of you have had experiences in profiling the kernel etc by collecting actual kernel instructions executed, I'd be interested in seeing if that may be extended for my purpose. Thanks Adnan PS: I'm not subscribed to this mailing list so I'd appreciated if you would cc me on the responses. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: function Named
On Thu, 7 Jul 2005, Jens Axboe wrote:
On Thu, Jul 07 2005, Richard B. Johnson wrote:
On Thu, 7 Jul 2005, raja wrote:
hi,
Is there any way to get the function address by only knowing the
function Name
thanking you,
-
printf("%p\n", function()); // User code
printk("%p\n", function()); // Kernel code
Yup that'll work fine, provided 'function' takes no arguments and
returns its own address.
Sorry meant..
printf("%p\n", function); // User code
I wanted to show that 'function' was a `function()`.
--
Jens Axboe
Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: function Named
On Thu, 7 Jul 2005, raja wrote:
hi,
Is there any way to get the function address by only knowing the
function Name
thanking you,
-
printf("%p\n", function()); // User code
printk("%p\n", function()); // Kernel code
This gives you the offset in virtual address-space. Inside the
kernel, one can obtain the physical address. User-code code
can't find out the physical address in any direct way.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo?
On Thu, 7 Jul 2005, Michael Tokarev wrote: Richard B. Johnson wrote: On Wed, 6 Jul 2005, Michael Tokarev wrote: kernel: 192.168.4.2 sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo [] All the IP addresses mentioned are local to this box. [] Are you sure `lo` is configured properly, i.e. Yes. More, rp_filter is activated on all interfaces. ifconfig lo 127.0.0.1 netmask 255.0.0.0 route add -net 127.0.0.0 netmask 255.0.0.0 dev lo There should be no LAN routes going through lo. There's no. It looks as though there are: kernel: 192.168.4.2 sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo | 192.168.4.2 pinged lo Only the 127.0.0.0 network should be routed through the loop-back device. Again: All the IP addresses mentioned are local to this box. If you ping an IP address on your eth0, the traffic will "go" over loopback. You can verify it using tcpdump: If you ping an IP address on your computer, the traffic will go through lo. However, I think that the IP address shown is the result of an instrumentation error because it is impossible to put, for instance your 192.168.1.1, through a 127.0.0.0 network, the ONLY route through lo. This shows that 'local' traffic bypasses the lo route filtering altogether. You can verify this by deleting the lo route altogether, you can still ping the local addresses. Somebody else mentioned that lo was 'perfectly happy' to carry whatever. The fact that something bogus appears on lo can be a sign of a misconfiguration error, just as the reserved 127.0.0.0 network must never appear on ethernet. In the case of 0.0.0.0 (a possible broadcast), there is no "local" address that could cause a bypass via lo. Instead, any such traffic should have been on the ethernet wire. This shows the possible configuration error that I mentioned. 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo This looks as though there is no netmask set. My configuration shows: loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 This is a possible configuration error. 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:a0:d2:1d:a7:63 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0 # tcpdump -npi lo proto ICMP tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes 15:55:13.679234 IP 192.168.1.1 > 192.168.1.1: icmp 64: echo request seq 1 15:55:13.679269 IP 192.168.1.1 > 192.168.1.1: icmp 64: echo reply seq 1 [SNIPPED rest] /mjt Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo?
On Thu, 7 Jul 2005, Michael Tokarev wrote: Richard B. Johnson wrote: On Wed, 6 Jul 2005, Michael Tokarev wrote: kernel: 192.168.4.2 sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo [] All the IP addresses mentioned are local to this box. [] Are you sure `lo` is configured properly, i.e. Yes. More, rp_filter is activated on all interfaces. ifconfig lo 127.0.0.1 netmask 255.0.0.0 route add -net 127.0.0.0 netmask 255.0.0.0 dev lo There should be no LAN routes going through lo. There's no. It looks as though there are: kernel: 192.168.4.2 sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo | 192.168.4.2 pinged lo Only the 127.0.0.0 network should be routed through the loop-back device. Again: All the IP addresses mentioned are local to this box. If you ping an IP address on your eth0, the traffic will go over loopback. You can verify it using tcpdump: If you ping an IP address on your computer, the traffic will go through lo. However, I think that the IP address shown is the result of an instrumentation error because it is impossible to put, for instance your 192.168.1.1, through a 127.0.0.0 network, the ONLY route through lo. This shows that 'local' traffic bypasses the lo route filtering altogether. You can verify this by deleting the lo route altogether, you can still ping the local addresses. Somebody else mentioned that lo was 'perfectly happy' to carry whatever. The fact that something bogus appears on lo can be a sign of a misconfiguration error, just as the reserved 127.0.0.0 network must never appear on ethernet. In the case of 0.0.0.0 (a possible broadcast), there is no local address that could cause a bypass via lo. Instead, any such traffic should have been on the ethernet wire. This shows the possible configuration error that I mentioned. 1: lo: LOOPBACK,UP mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo This looks as though there is no netmask set. My configuration shows: loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 This is a possible configuration error. 2: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:a0:d2:1d:a7:63 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0 # tcpdump -npi lo proto ICMP tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes 15:55:13.679234 IP 192.168.1.1 192.168.1.1: icmp 64: echo request seq 1 15:55:13.679269 IP 192.168.1.1 192.168.1.1: icmp 64: echo reply seq 1 [SNIPPED rest] /mjt Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: function Named
On Thu, 7 Jul 2005, raja wrote: hi, Is there any way to get the function address by only knowing the function Name thanking you, - printf(%p\n, function()); // User code printk(%p\n, function()); // Kernel code This gives you the offset in virtual address-space. Inside the kernel, one can obtain the physical address. User-code code can't find out the physical address in any direct way. Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: function Named
On Thu, 7 Jul 2005, Jens Axboe wrote: On Thu, Jul 07 2005, Richard B. Johnson wrote: On Thu, 7 Jul 2005, raja wrote: hi, Is there any way to get the function address by only knowing the function Name thanking you, - printf(%p\n, function()); // User code printk(%p\n, function()); // Kernel code Yup that'll work fine, provided 'function' takes no arguments and returns its own address. Sorry meant.. printf(%p\n, function); // User code I wanted to show that 'function' was a `function()`. -- Jens Axboe Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: please remove reserved word "new" from kernel headers
On Wed, 6 Jul 2005, Alexey Dobriyan wrote:
On Wednesday 06 July 2005 13:26, Rob Prowel wrote:
When kernel headers are included in compilation of c++
programs the compile fails because some header files
use "new" in a way that is illegal for c++. This
shows up when compiling mySQL under linux 2.6. It
uses $KERNELSOURCE/include/asm-i386/system.h.
Please read http://marc.theaimsgroup.com/?t=1116301=2=2
where people discuss this brokeness of MySQL.
Just for kicks, see if this 'fixes' it. Then contact the MySQL
people and complain.
--- /usr/src/linux-2.6.12/include/asm-i386/system.h.orig2005-07-06
14:01:25.0 -0400
+++ /usr/src/linux-2.6.12/include/asm-i386/system.h 2005-07-06
14:03:42.0 -0400
@@ -235,7 +235,7 @@
/*
* Atomic compare and exchange. Compare OLD with MEM, if identical,
- * store NEW in MEM. Return the initial value in MEM. Success is
+ * store New in MEM. Return the initial value in MEM. Success is
* indicated by comparing RETURN with OLD.
*/
@@ -244,26 +244,26 @@
#endif
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
- unsigned long new, int size)
+ unsigned long New, int size)
{
unsigned long prev;
switch (size) {
case 1:
__asm__ __volatile__(LOCK_PREFIX "cmpxchgb %b1,%2"
: "=a"(prev)
-: "q"(new), "m"(*__xg(ptr)), "0"(old)
+: "q"(New), "m"(*__xg(ptr)), "0"(old)
: "memory");
return prev;
case 2:
__asm__ __volatile__(LOCK_PREFIX "cmpxchgw %w1,%2"
: "=a"(prev)
-: "q"(new), "m"(*__xg(ptr)), "0"(old)
+: "q"(New), "m"(*__xg(ptr)), "0"(old)
: "memory");
return prev;
case 4:
__asm__ __volatile__(LOCK_PREFIX "cmpxchgl %1,%2"
: "=a"(prev)
-: "q"(new), "m"(*__xg(ptr)), "0"(old)
+: "q"(New), "m"(*__xg(ptr)), "0"(old)
: "memory");
return prev;
}
Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo?
On Wed, 6 Jul 2005, Michael Tokarev wrote: On our gateway machine, wich is running 2.6 kernel, I'm seeing quite several messages like this: kernel: 192.168.4.2 sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo last message repeated 3 times kernel: 192.168.4.2 sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo last message repeated 3 times kernel: 81.13.90.174 sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo gate last message repeated 10 times kernel: 81.13.90.174 sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo last message repeated 9 times All the IP addresses mentioned are local to this box. It's always like this, type11 code0 to 0.0.0.0 on lo. The box is a gateway, which have "external" interface, several "LAN" ifaces, DMZ, dialin modem pool and accepts vtund connections. And it has iptables-based firewall and NAT enabled. Here's a lis of network-related modules: ppp_deflate 4736 0 zlib_deflate 21528 1 ppp_deflate zlib_inflate 16640 1 ppp_deflate ppp_async 8576 0 crc_ccitt 1920 1 ppp_async ppp_generic19860 2 ppp_deflate,ppp_async slhc6144 1 ppp_generic tun 8320 13 crc32 3968 1 tun ipt_ECN 2944 163 iptable_mangle 2304 1 ipt_REJECT 4096 1 ipt_LOG 6272 3 ipt_state 1664 3 ipt_comment 1536 22 iptable_filter 2432 1 iptable_nat19420 1 ipt_NOTRACK 1920 3 iptable_raw 1792 1 ip_tables 18304 10 ipt_ECN,iptable_mangle,ipt_REJECT,ipt_LOG,ipt_state,ipt_comment,iptable_filter,iptable_nat,ipt_NOTRACK,iptable_raw md5 3840 1 ipv6 218688 12 ip_conntrack 37560 3 ipt_state,iptable_nat,ipt_NOTRACK aes_i586 38656 1 airo 63520 0 3c509 11476 0 I've seen several posts about problems *like* this, but they're all not from the same box (usually it's some problem with *another* device on the network which is sending bogus packets, or with hubs/switches or cables). In this case, it looks like it is this same box who's generating those bad packets. So far, I wasn't able to relate this message with any particular network activity. It happens "randomly". What it can be? Thanks. Are you sure `lo` is configured properly, i.e. ifconfig lo 127.0.0.1 netmask 255.0.0.0 route add -net 127.0.0.0 netmask 255.0.0.0 dev lo There should be no LAN routes going through lo. It looks as though there are: kernel: 192.168.4.2 sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo | 192.168.4.2 pinged lo Only the 127.0.0.0 network should be routed through the loop-back device. Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo?
On Wed, 6 Jul 2005, Michael Tokarev wrote: On our gateway machine, wich is running 2.6 kernel, I'm seeing quite several messages like this: kernel: 192.168.4.2 sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo last message repeated 3 times kernel: 192.168.4.2 sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo last message repeated 3 times kernel: 81.13.90.174 sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo gate last message repeated 10 times kernel: 81.13.90.174 sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo last message repeated 9 times All the IP addresses mentioned are local to this box. It's always like this, type11 code0 to 0.0.0.0 on lo. The box is a gateway, which have external interface, several LAN ifaces, DMZ, dialin modem pool and accepts vtund connections. And it has iptables-based firewall and NAT enabled. Here's a lis of network-related modules: ppp_deflate 4736 0 zlib_deflate 21528 1 ppp_deflate zlib_inflate 16640 1 ppp_deflate ppp_async 8576 0 crc_ccitt 1920 1 ppp_async ppp_generic19860 2 ppp_deflate,ppp_async slhc6144 1 ppp_generic tun 8320 13 crc32 3968 1 tun ipt_ECN 2944 163 iptable_mangle 2304 1 ipt_REJECT 4096 1 ipt_LOG 6272 3 ipt_state 1664 3 ipt_comment 1536 22 iptable_filter 2432 1 iptable_nat19420 1 ipt_NOTRACK 1920 3 iptable_raw 1792 1 ip_tables 18304 10 ipt_ECN,iptable_mangle,ipt_REJECT,ipt_LOG,ipt_state,ipt_comment,iptable_filter,iptable_nat,ipt_NOTRACK,iptable_raw md5 3840 1 ipv6 218688 12 ip_conntrack 37560 3 ipt_state,iptable_nat,ipt_NOTRACK aes_i586 38656 1 airo 63520 0 3c509 11476 0 I've seen several posts about problems *like* this, but they're all not from the same box (usually it's some problem with *another* device on the network which is sending bogus packets, or with hubs/switches or cables). In this case, it looks like it is this same box who's generating those bad packets. So far, I wasn't able to relate this message with any particular network activity. It happens randomly. What it can be? Thanks. Are you sure `lo` is configured properly, i.e. ifconfig lo 127.0.0.1 netmask 255.0.0.0 route add -net 127.0.0.0 netmask 255.0.0.0 dev lo There should be no LAN routes going through lo. It looks as though there are: kernel: 192.168.4.2 sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo | 192.168.4.2 pinged lo Only the 127.0.0.0 network should be routed through the loop-back device. Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: please remove reserved word new from kernel headers
On Wed, 6 Jul 2005, Alexey Dobriyan wrote:
On Wednesday 06 July 2005 13:26, Rob Prowel wrote:
When kernel headers are included in compilation of c++
programs the compile fails because some header files
use new in a way that is illegal for c++. This
shows up when compiling mySQL under linux 2.6. It
uses $KERNELSOURCE/include/asm-i386/system.h.
Please read http://marc.theaimsgroup.com/?t=1116301r=2w=2
where people discuss this brokeness of MySQL.
Just for kicks, see if this 'fixes' it. Then contact the MySQL
people and complain.
--- /usr/src/linux-2.6.12/include/asm-i386/system.h.orig2005-07-06
14:01:25.0 -0400
+++ /usr/src/linux-2.6.12/include/asm-i386/system.h 2005-07-06
14:03:42.0 -0400
@@ -235,7 +235,7 @@
/*
* Atomic compare and exchange. Compare OLD with MEM, if identical,
- * store NEW in MEM. Return the initial value in MEM. Success is
+ * store New in MEM. Return the initial value in MEM. Success is
* indicated by comparing RETURN with OLD.
*/
@@ -244,26 +244,26 @@
#endif
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
- unsigned long new, int size)
+ unsigned long New, int size)
{
unsigned long prev;
switch (size) {
case 1:
__asm__ __volatile__(LOCK_PREFIX cmpxchgb %b1,%2
: =a(prev)
-: q(new), m(*__xg(ptr)), 0(old)
+: q(New), m(*__xg(ptr)), 0(old)
: memory);
return prev;
case 2:
__asm__ __volatile__(LOCK_PREFIX cmpxchgw %w1,%2
: =a(prev)
-: q(new), m(*__xg(ptr)), 0(old)
+: q(New), m(*__xg(ptr)), 0(old)
: memory);
return prev;
case 4:
__asm__ __volatile__(LOCK_PREFIX cmpxchgl %1,%2
: =a(prev)
-: q(new), m(*__xg(ptr)), 0(old)
+: q(New), m(*__xg(ptr)), 0(old)
: memory);
return prev;
}
Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: man sendto ENOBUFS desc. wrong
On Tue, 5 Jul 2005, Karel Kulhavy wrote: man send(2): " ENOBUFS The output queue for a network interface was full. This gener- ally indicates that the interface has stopped sending, but may be caused by transient congestion. (Normally, this does not occur ^^^ in Linux. Packets are just silently dropped when a device queue ^^^ overflows.)" ^^ Which is not true, because just happened to me with kernel Linux version 2.6.11-gentoo-r9. Where should I report? CL< The `man` pages concatenate send() sendmsg() sendto(), etc. So, what are you trying to do? If you are using a CONNECTED STREAM socket, the end-points get perfect data-buffers with nothing dropped, even if you disconnect the physical wire for quite some time (hours). In that case, the errors returned are EAGAIN, EBADF, ECONNRESET, EFAULT, EINTR, EINVAL, ENOTCON, etc. No errors about the interface are returned because the kernel transparently retries those errors. Data-grams can be dropped on the floor for any number of reasons including the phase of the moon. If you are not prepared to handle this, you must use a CONNECTED STREAM socket. You can't have it both ways. You either have a perfect data-transmission path with its associated overhead, or you get a faster transmission but are not guaranteed anything, including the even one packet gets to the end-point. Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sending ethernet frames one after another
On Tue, 5 Jul 2005, Karel Kulhavy wrote: Hello I have written a software to test connected optical datalink in loopback mode which works by sending a burst of e. g. 1024 raw Ethernet frames directly to that interface, then waiting a little bit, and counting from ifconfig how many were received. Some people report a problem that on their eepro100 in IBM Thinkpad, the program (probably sendto) is returning error "No buffer space available". Why doesn't the sendto block instead? Does it mean that I cannot use this testing mode with that card? I need to send as fast as possible, because it's necessary to constantly transmit, as the link must be tested in load going in both directions simultaneously, to catch possible crosstalks. If sendto is used on a data-gram socket, it may just dump extra packets on the floor. If you have a connected socket, sendto will return an error when no buffers are available. If you want RELIABLE communication, then you use a connected stream socket and send() or write(). These handle transmission problems transparently. Or is that an error that should be handled by the application? In which way, then? Generally, it is least expensive as far as performance is concerned if you let the kernel handle errors, retries, duplicate packets, etc. That's what you get with a connected stream socket. However, since every packet is ACKed, the round-trip time can be a performance killer. So, a private protocol for talking through satellites which have awful round-trip time might be to number packets at the application level, send everything, then query the receiver software about the missing packets. This continues until all the packets have been received. Regards, CL< Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A "new driver model" and EXPORT_SYMBOL_GPL question
On Sun, 3 Jul 2005, Michal Jaegermann wrote: It dawned on me only now that a "new driver model" introduced in patches from GKH export symbols like that: EXPORT_SYMBOL_GPL(class_create); EXPORT_SYMBOL_GPL(class_destroy); and so on. The problem is that corresponding old symbols, which are still present in 2.6.12, were exported EXPORT_SYMBOL(class_simple_create); EXPORT_SYMBOL(class_simple_destroy); This creates a problem. There exist out-of-tree drivers which are using those symbols and, even if sources are available, are not licensed GPL for whatever reasons. No, I am not the author of any of those so I cannot do very much about re-licensing. As an effect a conversion to a "new driver model", even if simple, does not work. In particular I bumped into that with Myrinet card drivers. Was a decision to use EXPORT_SYMBOL_GPL deliberate and if yes then what considerations dictated it, other then the patch author wrote it that way, and what drivers in question are supposed to use when this change will show up in the mainline? It looks that 2.6.13 will do this. Thanks, Michal - This problem will continue. Eventually there will be no general exported symbols. The apparent idea is to prevent the use of the kernel in proprietary systems. Not to worry. The tools provided with a typical Linux distribution are capable of resolving those symbols. You can make a script that `greps` System.map for the correct offsets of those symbols. You can use those offsets in a linker script. Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new driver model and EXPORT_SYMBOL_GPL question
On Sun, 3 Jul 2005, Michal Jaegermann wrote: It dawned on me only now that a new driver model introduced in patches from GKH export symbols like that: EXPORT_SYMBOL_GPL(class_create); EXPORT_SYMBOL_GPL(class_destroy); and so on. The problem is that corresponding old symbols, which are still present in 2.6.12, were exported EXPORT_SYMBOL(class_simple_create); EXPORT_SYMBOL(class_simple_destroy); This creates a problem. There exist out-of-tree drivers which are using those symbols and, even if sources are available, are not licensed GPL for whatever reasons. No, I am not the author of any of those so I cannot do very much about re-licensing. As an effect a conversion to a new driver model, even if simple, does not work. In particular I bumped into that with Myrinet card drivers. Was a decision to use EXPORT_SYMBOL_GPL deliberate and if yes then what considerations dictated it, other then the patch author wrote it that way, and what drivers in question are supposed to use when this change will show up in the mainline? It looks that 2.6.13 will do this. Thanks, Michal - This problem will continue. Eventually there will be no general exported symbols. The apparent idea is to prevent the use of the kernel in proprietary systems. Not to worry. The tools provided with a typical Linux distribution are capable of resolving those symbols. You can make a script that `greps` System.map for the correct offsets of those symbols. You can use those offsets in a linker script. Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sending ethernet frames one after another
On Tue, 5 Jul 2005, Karel Kulhavy wrote: Hello I have written a software to test connected optical datalink in loopback mode which works by sending a burst of e. g. 1024 raw Ethernet frames directly to that interface, then waiting a little bit, and counting from ifconfig how many were received. Some people report a problem that on their eepro100 in IBM Thinkpad, the program (probably sendto) is returning error No buffer space available. Why doesn't the sendto block instead? Does it mean that I cannot use this testing mode with that card? I need to send as fast as possible, because it's necessary to constantly transmit, as the link must be tested in load going in both directions simultaneously, to catch possible crosstalks. If sendto is used on a data-gram socket, it may just dump extra packets on the floor. If you have a connected socket, sendto will return an error when no buffers are available. If you want RELIABLE communication, then you use a connected stream socket and send() or write(). These handle transmission problems transparently. Or is that an error that should be handled by the application? In which way, then? Generally, it is least expensive as far as performance is concerned if you let the kernel handle errors, retries, duplicate packets, etc. That's what you get with a connected stream socket. However, since every packet is ACKed, the round-trip time can be a performance killer. So, a private protocol for talking through satellites which have awful round-trip time might be to number packets at the application level, send everything, then query the receiver software about the missing packets. This continues until all the packets have been received. Regards, CL Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: man sendto ENOBUFS desc. wrong
On Tue, 5 Jul 2005, Karel Kulhavy wrote: man send(2): ENOBUFS The output queue for a network interface was full. This gener- ally indicates that the interface has stopped sending, but may be caused by transient congestion. (Normally, this does not occur ^^^ in Linux. Packets are just silently dropped when a device queue ^^^ overflows.) ^^ Which is not true, because just happened to me with kernel Linux version 2.6.11-gentoo-r9. Where should I report? CL The `man` pages concatenate send() sendmsg() sendto(), etc. So, what are you trying to do? If you are using a CONNECTED STREAM socket, the end-points get perfect data-buffers with nothing dropped, even if you disconnect the physical wire for quite some time (hours). In that case, the errors returned are EAGAIN, EBADF, ECONNRESET, EFAULT, EINTR, EINVAL, ENOTCON, etc. No errors about the interface are returned because the kernel transparently retries those errors. Data-grams can be dropped on the floor for any number of reasons including the phase of the moon. If you are not prepared to handle this, you must use a CONNECTED STREAM socket. You can't have it both ways. You either have a perfect data-transmission path with its associated overhead, or you get a faster transmission but are not guaranteed anything, including the even one packet gets to the end-point. Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux with disabled interrupts
On Wed, 20 Apr 2005, Francesco Oppedisano wrote: Hi, i'd like to know how much time does linux kernel run with disabled interrupts. So i would like to remap the instructions capable of disabling interrupt to other ones which count how much this time is... Does already exist a patch or tool capable to give me a magnitude order of the time spent by the kernel with disables interrupts? In uniprocessor systems, can i state that the only instruction capable of disabling interrupts is cli? How do you propose to "remap" the CLI instruction? The kernel isn't going to trap on this perfectly legal instruction in kernel mode. Also, interrupts can be disabled by masking them off in the controller(s) so there are many ways that any/all interrupts can be disabled. Thank u very much Francesco Oppedisano - Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux with disabled interrupts
On Wed, 20 Apr 2005, Francesco Oppedisano wrote: Hi, i'd like to know how much time does linux kernel run with disabled interrupts. So i would like to remap the instructions capable of disabling interrupt to other ones which count how much this time is... Does already exist a patch or tool capable to give me a magnitude order of the time spent by the kernel with disables interrupts? In uniprocessor systems, can i state that the only instruction capable of disabling interrupts is cli? How do you propose to remap the CLI instruction? The kernel isn't going to trap on this perfectly legal instruction in kernel mode. Also, interrupts can be disabled by masking them off in the controller(s) so there are many ways that any/all interrupts can be disabled. Thank u very much Francesco Oppedisano - Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL violation by CorAccess?
On Tue, 19 Apr 2005, Chris Friesen wrote: Richard B. Johnson wrote: No. Accompany it with a written offer to __provide__ the source code for any GPL stuff they used (like the kernel or drivers). Anything at the application-level is NOT covered by the GPL. They do not have to give away their trade-secrets. GPL'd applications would still be covered by the GPL, no? You mean like `ls` and `init` ??? Sure. I don't think any serious embedded stuff would use that, though. Typically an embedded system would start with a new application called 'init'. It wouldn't use a SYS-V startup and certainly wouldn't have a shell. The new init would do everything including mounting any file- systems and initializing networking all by itself without any help from the usual applications. It might fork-off a few different tasks to handle different things. For instance, the system shown probably handles the furnace and air-conditioner as a separate task. The shades and blinds are probably another and, certainly, communicating with the robot that mows the lawn would require a separate task just to handle GPS. If I buy their product, I should be able to ask them for the source to all GPL'd entities that are present in the system, including the kernel, drivers, and all GPL'd userspace apps. Any *new* apps that they wrote they would of course be free to keep private. Yep. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL violation by CorAccess?
On Tue, 19 Apr 2005, Chris Friesen wrote: Richard B. Johnson wrote: Violation? They proudly reply in their article in http://www.linuxdevices.com that they use Linux, that they embedded a version of Red Hat, etc. It's likely that they didn't modify anything in the kernel and just used some stripped-down C-libraries to make everything fit. Right. They're distributing products licensed under the GPL, so sections 3-a and 3-b of the GPL apply. Thus they can either a) accompany it with the source code, or b) accompany it with a written offer to give any third party a copy of the source code. Chris No. Accompany it with a written offer to __provide__ the source code for any GPL stuff they used (like the kernel or drivers). Anything at the application-level is NOT covered by the GPL. They do not have to give away their trade-secrets. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL violation by CorAccess?
Violation? They proudly reply in their article in http://www.linuxdevices.com that they use Linux, that they embedded a version of Red Hat, etc. It's likely that they didn't modify anything in the kernel and just used some stripped-down C-libraries to make everything fit. On Tue, 19 Apr 2005, Lennart Sorensen wrote: On Tue, Apr 19, 2005 at 05:57:43PM +, Karel Kulhavy wrote: I have seen a device by CorAccess which apparently uses Linux and didn't find anything that would suggest it complies to GPL, though I had access to the complete shipping package. Does anyone know about known cause of violation by this company or should I investigate further? Well what is the case if you use unmodified GPL code, do you still have to provide sources to the end user if you give them binaries? I would guess yes, but IANAL. As far as I can tell their system is a geode GX1 so runs standard x86 software. Maybe they didn't have to modify any of the linux kernel to run what they needed. Their applications are their business of course. It looks like they use QT as the gui toolkit, which I don't off hand know the current license conditions of. Then there is the web browser and such, which has it's own license conditions. Of course for all I know their user manual has an offer of sending a CD with the sources if you ask. Does anyone actually have their product that could check for that? Len Sorensen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL violation by CorAccess?
On Tue, 19 Apr 2005, Chris Friesen wrote: Richard B. Johnson wrote: Violation? They proudly reply in their article in http://www.linuxdevices.com that they use Linux, that they embedded a version of Red Hat, etc. It's likely that they didn't modify anything in the kernel and just used some stripped-down C-libraries to make everything fit. Right. They're distributing products licensed under the GPL, so sections 3-a and 3-b of the GPL apply. Thus they can either a) accompany it with the source code, or b) accompany it with a written offer to give any third party a copy of the source code. Chris No. Accompany it with a written offer to __provide__ the source code for any GPL stuff they used (like the kernel or drivers). Anything at the application-level is NOT covered by the GPL. They do not have to give away their trade-secrets. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL violation by CorAccess?
On Tue, 19 Apr 2005, Chris Friesen wrote: Richard B. Johnson wrote: No. Accompany it with a written offer to __provide__ the source code for any GPL stuff they used (like the kernel or drivers). Anything at the application-level is NOT covered by the GPL. They do not have to give away their trade-secrets. GPL'd applications would still be covered by the GPL, no? You mean like `ls` and `init` ??? Sure. I don't think any serious embedded stuff would use that, though. Typically an embedded system would start with a new application called 'init'. It wouldn't use a SYS-V startup and certainly wouldn't have a shell. The new init would do everything including mounting any file- systems and initializing networking all by itself without any help from the usual applications. It might fork-off a few different tasks to handle different things. For instance, the system shown probably handles the furnace and air-conditioner as a separate task. The shades and blinds are probably another and, certainly, communicating with the robot that mows the lawn would require a separate task just to handle GPS. If I buy their product, I should be able to ask them for the source to all GPL'd entities that are present in the system, including the kernel, drivers, and all GPL'd userspace apps. Any *new* apps that they wrote they would of course be free to keep private. Yep. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intercepting syscalls
On Fri, 15 Apr 2005, Daniel Souza wrote: On 4/15/05, Arjan van de Ven <[EMAIL PROTECTED]> wrote: On Fri, 2005-04-15 at 13:10 -0700, Daniel Souza wrote: You're welcome, Igor. I needed to intercept syscalls in a little project that I were implementing, to keep track of filesystem changes, I assume you weren't about tracking file content changing... since you can't do that with syscall hijacking.. (that is a common misconception by people who came from a MS Windows environment and did things like anti virus tools there this way) No, I was tracking file creations/modifications/attemps of access/directory creations|modifications/file movings/program executions with some filter exceptions (avoid logging library loads by ldd to preserve disk space). It was a little module that logs file changes and program executions to syslog (showing owner,pid,ppid,process name, return of operation,etc), that, used with remote syslog logging to a 'strictly secure' machine (just receive logs), keep security logs of everything (like, it was possible to see apache running commands as "ls -la /" or "ps aux", that, in fact, were signs of intrusion of try of intrusion, because it's not a usual behavior of httpd. Maybe anyone exploited a php page to execute arbitrary scripts...) -- The requirements can be easily met in user-mode, probably a lot easier than anything in the kernel. LD_PRELOAD some custom 'C' runtime library functions, grab open() read(), write(), etc. Write information to a pipe. Secure reader daemon logs whatever it wants, based upon configuration settings. After writing information to the pipe, executes the appropriate syscall. Done, no hacks, everything working in the correct context. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Rootkits
On Fri, 15 Apr 2005, Allison wrote: Hi, I was curious about how kernel rootkits become a part of the kernel ? One way I guess is by inserting a kernel module. And rootkits also manage to hide themselves from rootkit detectors. I'm not sure there really are any "kernel" rootkits. You need to be root to install a module and you need to be root to replace a kernel with a new (possibly altered) one. If you are root, you don't need an exploit. few questions: 1. Are there any other ways by which rootkits become part of the kernel ? Anybody with knowledge of kernel internals could write some code and put it into the kernel. The code could do anything the kernel can do. That kernel could replace an existing one. You can make your own development system where you know the root password. You can make a new kernel with whatever Trojans you want, create a bootable floppy (or Flash RAM disk), then reboot the target machine with that boot device. The new kernel and its startup code that you develop could mount the target-machine root file-system and replace its kernel with yours. A subsequent reboot brings up the target machine as though normal. Then, whenever you are logged onto the target machine, even as a normal user, you could call your new kernel function with a simple 'C' program. 2. If modules can access only exported symbols, how is it that kernel rootkits manage to get hold of other information from the kernel ? For ex, the process table. Modules can access any symbol that is in /boot/System.map if it's the correct System.map for the current kernel version. I am not familiar with the /dev/kmem interface. Does this interface let any kernel module read any symbol (even non-exported) from the kernel ? That doesn't contain symbols. It's a binary image of the executing kernel. You need to be root to read the contents. 3. If I want to hide a function which is part of the kernel from kernel modules, is this possible ideally ? It is possible to obfuscate the function by indirection. As a practical matter, a module can be built which can access anything in the kernel address-space. Exporting symbols isn't necessary at all. It's just a protocol. thanks, Allison - Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Rootkits
On Fri, 15 Apr 2005, Allison wrote: Hi, I was curious about how kernel rootkits become a part of the kernel ? One way I guess is by inserting a kernel module. And rootkits also manage to hide themselves from rootkit detectors. I'm not sure there really are any kernel rootkits. You need to be root to install a module and you need to be root to replace a kernel with a new (possibly altered) one. If you are root, you don't need an exploit. few questions: 1. Are there any other ways by which rootkits become part of the kernel ? Anybody with knowledge of kernel internals could write some code and put it into the kernel. The code could do anything the kernel can do. That kernel could replace an existing one. You can make your own development system where you know the root password. You can make a new kernel with whatever Trojans you want, create a bootable floppy (or Flash RAM disk), then reboot the target machine with that boot device. The new kernel and its startup code that you develop could mount the target-machine root file-system and replace its kernel with yours. A subsequent reboot brings up the target machine as though normal. Then, whenever you are logged onto the target machine, even as a normal user, you could call your new kernel function with a simple 'C' program. 2. If modules can access only exported symbols, how is it that kernel rootkits manage to get hold of other information from the kernel ? For ex, the process table. Modules can access any symbol that is in /boot/System.map if it's the correct System.map for the current kernel version. I am not familiar with the /dev/kmem interface. Does this interface let any kernel module read any symbol (even non-exported) from the kernel ? That doesn't contain symbols. It's a binary image of the executing kernel. You need to be root to read the contents. 3. If I want to hide a function which is part of the kernel from kernel modules, is this possible ideally ? It is possible to obfuscate the function by indirection. As a practical matter, a module can be built which can access anything in the kernel address-space. Exporting symbols isn't necessary at all. It's just a protocol. thanks, Allison - Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intercepting syscalls
On Fri, 15 Apr 2005, Daniel Souza wrote: On 4/15/05, Arjan van de Ven [EMAIL PROTECTED] wrote: On Fri, 2005-04-15 at 13:10 -0700, Daniel Souza wrote: You're welcome, Igor. I needed to intercept syscalls in a little project that I were implementing, to keep track of filesystem changes, I assume you weren't about tracking file content changing... since you can't do that with syscall hijacking.. (that is a common misconception by people who came from a MS Windows environment and did things like anti virus tools there this way) No, I was tracking file creations/modifications/attemps of access/directory creations|modifications/file movings/program executions with some filter exceptions (avoid logging library loads by ldd to preserve disk space). It was a little module that logs file changes and program executions to syslog (showing owner,pid,ppid,process name, return of operation,etc), that, used with remote syslog logging to a 'strictly secure' machine (just receive logs), keep security logs of everything (like, it was possible to see apache running commands as ls -la / or ps aux, that, in fact, were signs of intrusion of try of intrusion, because it's not a usual behavior of httpd. Maybe anyone exploited a php page to execute arbitrary scripts...) -- The requirements can be easily met in user-mode, probably a lot easier than anything in the kernel. LD_PRELOAD some custom 'C' runtime library functions, grab open() read(), write(), etc. Write information to a pipe. Secure reader daemon logs whatever it wants, based upon configuration settings. After writing information to the pipe, executes the appropriate syscall. Done, no hacks, everything working in the correct context. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: screensaver
On Thu, 14 Apr 2005, sauro wrote:
Greetings.
I am using a 2.4 Linux workstation in text mode (no graphic interface).
After some time, Linux activates the "screensaver" and the monitor goes blank
on "stand by" mode until activity is detected from the mouse or keyboard.
Is it possible to disable this screensaver, so that the monitor keeps on all
the time?
Thanks in advance.
Yes, but you need to send the screen some escape sequences, the
last time I checked. Subroutines included do the following:
noblank() Stops screen blanker (what you want).
scr() Resets ANSI mode to return from shifted to normal.
Sometimes the screen gets shifted after accidentally
reading binary files.
cls() Clear the screen.
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// This program may be distributed under the GNU Public License
// version 2, as published by the Free Software Foundation, Inc.,
// 59 Temple Place, Suite 330 Boston, MA, 02111.
//
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
#include
#include
#include
static const char fix[]={27, '[', '3', 'g',
27, '[', 'H', 27, '[', 'H', 27, '[', 'H',
27, '[', 'H', 27, '[', 'H', 27, '[', 'H',
27, '[', 'H', 27, '[', 'H', 27, '[', 'H',
27, 'c', 27, ']', 'R' };
static const char blk[]={27, '[', '9', ';', '0', ']'};
static const char clr[]={27, '[', 'H', 27, '[', 'J' };
void noblank(int fd){ write(fd, blk, sizeof(blk)); }
void cls(int fd){ write(fd, clr, sizeof(clr)); }
void scr(int fd){ write(fd, fix, sizeof(fix)); }
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: screensaver
On Thu, 14 Apr 2005, sauro wrote:
Greetings.
I am using a 2.4 Linux workstation in text mode (no graphic interface).
After some time, Linux activates the screensaver and the monitor goes blank
on stand by mode until activity is detected from the mouse or keyboard.
Is it possible to disable this screensaver, so that the monitor keeps on all
the time?
Thanks in advance.
Yes, but you need to send the screen some escape sequences, the
last time I checked. Subroutines included do the following:
noblank() Stops screen blanker (what you want).
scr() Resets ANSI mode to return from shifted to normal.
Sometimes the screen gets shifted after accidentally
reading binary files.
cls() Clear the screen.
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// This program may be distributed under the GNU Public License
// version 2, as published by the Free Software Foundation, Inc.,
// 59 Temple Place, Suite 330 Boston, MA, 02111.
//
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
#include stdio.h
#include unistd.h
#include stdlib.h
static const char fix[]={27, '[', '3', 'g',
27, '[', 'H', 27, '[', 'H', 27, '[', 'H',
27, '[', 'H', 27, '[', 'H', 27, '[', 'H',
27, '[', 'H', 27, '[', 'H', 27, '[', 'H',
27, 'c', 27, ']', 'R' };
static const char blk[]={27, '[', '9', ';', '0', ']'};
static const char clr[]={27, '[', 'H', 27, '[', 'J' };
void noblank(int fd){ write(fd, blk, sizeof(blk)); }
void cls(int fd){ write(fd, clr, sizeof(clr)); }
void scr(int fd){ write(fd, fix, sizeof(fix)); }
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Why system call need to copy the date from the userspace before using it
On Wed, 13 Apr 2005, Theodore Ts'o wrote: On Wed, Apr 13, 2005 at 08:40:05AM -0400, Richard B. Johnson wrote: The kernel does NOT have to copy data from user-space before using it. Incorrect. It must, or the kernel code in question is by definition buggy. What? Explain why a memory-mapped buffer can't be DMAed directly? In fact, user-mode pointers are valid in kernel-space when the kernel is performing a function on behalf of the user- mode code. On some architectures, this is true. But not all architectures, and not in all circumstances. For example, even on the x86 architecture, in the 4G/4G mode, a user-mode pointer is *not* valid when kernel code is running. You must use copy_to_user()/copy_from_user(). Simply dereferencing a user-mode pointer is a BUG. It might work sometimes, on some architectures, but not everywhere. Therefore, for correctly written kernel code, you must not do it. You apparently didn't even bother to read my explanation why the copy/to/from user was necessary unless the buffer(s) were memory- mapped, marked reserved, and set to no-cache. In that case you can DMA directly to/from user-space. Perhaps you just wanted to argue? - Ted Again, as long as you can guarantee that the RAM you are using is reserved so the kernel won't use it for paged RAM, and as long as it's accessible in both user-mode and kernel-mode, which means memory-mapped, either the kernel or the user can use it as it sees fit. If it can't, the kernel is buggy. In fact, there is no way the kernel could prevent it from being used in this manner. Since, by definition, the kernel will leave reserved memory alone, and memory-mapped space will not fault, there is no way for the kernel to even know how it is being accessed. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXPORT_SYMBOL_GPL for __symbol_get replacing EXPORT_SYMBOL for deprecated inter_module_get
On Wed, 13 Apr 2005, Dave Jones wrote: On Wed, Apr 13, 2005 at 06:55:00PM +0930, Yuri Vilmanis wrote: > The case in point for me is ATI's binary openGL accelerated drivers (fglrx) - > these used inter_module_get() to communicate with the agp gart module, for > obvious reasons - this AGP communication is essential to the functionality of > the driver. No, I don't like ATI only having closed-source drivers any more > than you, but given the extremely competetive nature of high end video card > sales, I can see why they want to do it this way. > > Am I take it to mean that no closed-source / binary-only driver may use AGP > acceleration in the future, including ones that have in the past? They can use the in-kernel GART driver just fine. Of course, they choose to take a bastardised version from some ancient tree, mangle it to all hell, strip off the GPL MODULE_VERSION, and weld it to their own driver, but that's their decision. Which is btw, whats partly causing your problem. (They still would've needed to change some code, but the AGP side of the fence would be taken care of). Dave As a practical matter, one can make or modify the source-code of a driver to use any symbols available in System.map. One can even make a "preloader" program that gets the right stuff for the correct kernel, puts it into the module, then has the standard module loader load it. There is way too much effort being applied to hiding kernel symbols. As long as you have the tools available to build a kernel, you have the tools available to use any symbol. Here is the kernel offset of 'sys_call_table' and 'sys_ni_syscall' TABLE := $(shell grep sys_call_table /boot/System.map | cut -f1 -d' ') NISYS := $(shell grep sys_ni_syscall /boot/System.map | cut -f1 -d' ') DEFS = -D__KERNEL__ -DMODULE -DMAJOR_NR=$(MAJR) -DCONFIG_SMP DEFS += -DMODNAME=$(NAME) -DTABLE=0x$(TABLE) -DNISYS=0x$(NISYS) You just initialize your module pointers to these values and you have access to these objects. Simple. Although I haven't tried it, I think one can even borrow a __mod_licensexxx by using /proc/kallsyms. The point being that trying to prevent one from using existing kernel code in kernel modules will, eventually, fail completely unless we only get binaries with no source-code. Even in that case, many symbols within /proc/kallsyms are useful. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why system call need to copy the date from the userspace before using it
On Wed, 13 Apr 2005, Hacksaw wrote: Why not use it directly Some of these reasons are: It seems like you gave reason why userland pointers shouldn't be trusted, not why userland data should be copied into kernel land. All the problems you mentioned would have to be solved by the kernel regardless of copying the data around. You do not seem to understand. Assume that I did a read(fd, buf, len) and the length would overflow a user-mode buffer. One needs to make sure that the kernel is protected and the user gets a seg-fault. Since the kernel, in kernel mode, can do anything it pleases, including destroying itself, one needs to make sure that it won't. Therefore a special kind of memcpy() was designed, called copy_to/from_user to protect the kernel. Ummm... Except for the who's mapped now problem. That's pretty weird. I guess that's something that comes with trying to use tons of RAM in a 32 bit system. I thought the big issue was the need to lock the page(s) during the call, and maybe some tricky races which made the idea difficult. -- The kernel does NOT have to copy data from user-space before using it. In fact, user-mode pointers are valid in kernel-space when the kernel is performing a function on behalf of the user- mode code. The problem is that data-space is usually allocated in user-mode code (like using malloc()). When the kernel needs to access that buffer, it has no clue how much the user-code allocated. It can't trust that the user-code put in the right buffer length. Therefore, it needs to set up a user-mode trap if the access attempts to go beyond the buffer length. Examples of not copying to/from user mode is memory-mapped data. The kernel knows how much data was actually mapped. It also knows if it will page-fault when being accessed. If DMA is being performed to such memory, it needs to be reserved so it won't be paged. It also has to be non-cached so that writes that the CPU didn't do can be read properly by the CPU. Under these conditions, the kernel-mode code writes or DMAs directly to some user buffer. User-mode code needs to find out when new data are available, perhaps using select() or poll(). If you are writing a driver, never attempt to copy/to/from/user with a spin-lock held. You need to allow page-faults to occur because the user's RAM may have been "borrowed" by somebody else (paged out). A page-fault needs to occur to replace the user's RAM-data and reconnect to the user's working-set. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why system call need to copy the date from the userspace before using it
On Wed, 13 Apr 2005, Hacksaw wrote: Why not use it directly Some of these reasons are: It seems like you gave reason why userland pointers shouldn't be trusted, not why userland data should be copied into kernel land. All the problems you mentioned would have to be solved by the kernel regardless of copying the data around. You do not seem to understand. Assume that I did a read(fd, buf, len) and the length would overflow a user-mode buffer. One needs to make sure that the kernel is protected and the user gets a seg-fault. Since the kernel, in kernel mode, can do anything it pleases, including destroying itself, one needs to make sure that it won't. Therefore a special kind of memcpy() was designed, called copy_to/from_user to protect the kernel. Ummm... Except for the who's mapped now problem. That's pretty weird. I guess that's something that comes with trying to use tons of RAM in a 32 bit system. I thought the big issue was the need to lock the page(s) during the call, and maybe some tricky races which made the idea difficult. -- The kernel does NOT have to copy data from user-space before using it. In fact, user-mode pointers are valid in kernel-space when the kernel is performing a function on behalf of the user- mode code. The problem is that data-space is usually allocated in user-mode code (like using malloc()). When the kernel needs to access that buffer, it has no clue how much the user-code allocated. It can't trust that the user-code put in the right buffer length. Therefore, it needs to set up a user-mode trap if the access attempts to go beyond the buffer length. Examples of not copying to/from user mode is memory-mapped data. The kernel knows how much data was actually mapped. It also knows if it will page-fault when being accessed. If DMA is being performed to such memory, it needs to be reserved so it won't be paged. It also has to be non-cached so that writes that the CPU didn't do can be read properly by the CPU. Under these conditions, the kernel-mode code writes or DMAs directly to some user buffer. User-mode code needs to find out when new data are available, perhaps using select() or poll(). If you are writing a driver, never attempt to copy/to/from/user with a spin-lock held. You need to allow page-faults to occur because the user's RAM may have been borrowed by somebody else (paged out). A page-fault needs to occur to replace the user's RAM-data and reconnect to the user's working-set. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXPORT_SYMBOL_GPL for __symbol_get replacing EXPORT_SYMBOL for deprecated inter_module_get
On Wed, 13 Apr 2005, Dave Jones wrote: On Wed, Apr 13, 2005 at 06:55:00PM +0930, Yuri Vilmanis wrote: The case in point for me is ATI's binary openGL accelerated drivers (fglrx) - these used inter_module_get() to communicate with the agp gart module, for obvious reasons - this AGP communication is essential to the functionality of the driver. No, I don't like ATI only having closed-source drivers any more than you, but given the extremely competetive nature of high end video card sales, I can see why they want to do it this way. Am I take it to mean that no closed-source / binary-only driver may use AGP acceleration in the future, including ones that have in the past? They can use the in-kernel GART driver just fine. Of course, they choose to take a bastardised version from some ancient tree, mangle it to all hell, strip off the GPL MODULE_VERSION, and weld it to their own driver, but that's their decision. Which is btw, whats partly causing your problem. (They still would've needed to change some code, but the AGP side of the fence would be taken care of). Dave As a practical matter, one can make or modify the source-code of a driver to use any symbols available in System.map. One can even make a preloader program that gets the right stuff for the correct kernel, puts it into the module, then has the standard module loader load it. There is way too much effort being applied to hiding kernel symbols. As long as you have the tools available to build a kernel, you have the tools available to use any symbol. Here is the kernel offset of 'sys_call_table' and 'sys_ni_syscall' TABLE := $(shell grep sys_call_table /boot/System.map | cut -f1 -d' ') NISYS := $(shell grep sys_ni_syscall /boot/System.map | cut -f1 -d' ') DEFS = -D__KERNEL__ -DMODULE -DMAJOR_NR=$(MAJR) -DCONFIG_SMP DEFS += -DMODNAME=$(NAME) -DTABLE=0x$(TABLE) -DNISYS=0x$(NISYS) You just initialize your module pointers to these values and you have access to these objects. Simple. Although I haven't tried it, I think one can even borrow a __mod_licensexxx by using /proc/kallsyms. The point being that trying to prevent one from using existing kernel code in kernel modules will, eventually, fail completely unless we only get binaries with no source-code. Even in that case, many symbols within /proc/kallsyms are useful. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why system call need to copy the date from the userspace before using it
On Wed, 13 Apr 2005, Theodore Ts'o wrote: On Wed, Apr 13, 2005 at 08:40:05AM -0400, Richard B. Johnson wrote: The kernel does NOT have to copy data from user-space before using it. Incorrect. It must, or the kernel code in question is by definition buggy. What? Explain why a memory-mapped buffer can't be DMAed directly? In fact, user-mode pointers are valid in kernel-space when the kernel is performing a function on behalf of the user- mode code. On some architectures, this is true. But not all architectures, and not in all circumstances. For example, even on the x86 architecture, in the 4G/4G mode, a user-mode pointer is *not* valid when kernel code is running. You must use copy_to_user()/copy_from_user(). Simply dereferencing a user-mode pointer is a BUG. It might work sometimes, on some architectures, but not everywhere. Therefore, for correctly written kernel code, you must not do it. You apparently didn't even bother to read my explanation why the copy/to/from user was necessary unless the buffer(s) were memory- mapped, marked reserved, and set to no-cache. In that case you can DMA directly to/from user-space. Perhaps you just wanted to argue? - Ted Again, as long as you can guarantee that the RAM you are using is reserved so the kernel won't use it for paged RAM, and as long as it's accessible in both user-mode and kernel-mode, which means memory-mapped, either the kernel or the user can use it as it sees fit. If it can't, the kernel is buggy. In fact, there is no way the kernel could prevent it from being used in this manner. Since, by definition, the kernel will leave reserved memory alone, and memory-mapped space will not fault, there is no way for the kernel to even know how it is being accessed. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Call to atention about using hash functions as content indexers (SCM saga)
On Mon, 11 Apr 2005, Petr Baudis wrote: Dear diary, on Tue, Apr 12, 2005 at 12:40:21AM CEST, I got a letter where Pedro Larroy <[EMAIL PROTECTED]> told me that... Hi Hello, I had a quick look at the source of GIT tonight, I'd like to warn you about the use of hash functions as content indexers. As probably you are aware, hash functions such as SHA-1 are surjective not bijective (1-to-1 map), so they have collisions. Here one can argue about the low probability of such a collision, I won't get into subjetive valorations of what probability of collision is tolerable for me and what is not. I my humble opinion, choosing deliberately, as a design decision, a method such as this one, that in some cases could corrupt data in a silent and very hard to detect way, is not very good. One can also argue that the probability of data getting corrupted in the disk, or whatever could be higher than that of the collision, again this is not valid comparison, since the fact that indexing by hash functions without additional checking could make data corruption legal between the reasonable working parameters of the program is very dangerous. (i) 1461501637330902918203684832716283019655932542976 possible SHA1 hashes. (ii) In git-pasky, there's (turnable off) detection of collisions. (iii) Your argument against comparing with the probability of a hardware error does not make sense to me. (iv) You fail to propose a better solution. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. This is a standard, free (no patents) hash-function that works. The fact that somebody can write a program, designed to create collisions, and demonstrate that after many weeks of processing, iteratively building upon the previous result, and finally cause a collision, really isn't relevant for this application. There is a good possibility that there are no hash-functions that can't be broken. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Call to atention about using hash functions as content indexers (SCM saga)
On Mon, 11 Apr 2005, Petr Baudis wrote: Dear diary, on Tue, Apr 12, 2005 at 12:40:21AM CEST, I got a letter where Pedro Larroy [EMAIL PROTECTED] told me that... Hi Hello, I had a quick look at the source of GIT tonight, I'd like to warn you about the use of hash functions as content indexers. As probably you are aware, hash functions such as SHA-1 are surjective not bijective (1-to-1 map), so they have collisions. Here one can argue about the low probability of such a collision, I won't get into subjetive valorations of what probability of collision is tolerable for me and what is not. I my humble opinion, choosing deliberately, as a design decision, a method such as this one, that in some cases could corrupt data in a silent and very hard to detect way, is not very good. One can also argue that the probability of data getting corrupted in the disk, or whatever could be higher than that of the collision, again this is not valid comparison, since the fact that indexing by hash functions without additional checking could make data corruption legal between the reasonable working parameters of the program is very dangerous. (i) 1461501637330902918203684832716283019655932542976 possible SHA1 hashes. (ii) In git-pasky, there's (turnable off) detection of collisions. (iii) Your argument against comparing with the probability of a hardware error does not make sense to me. (iv) You fail to propose a better solution. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. This is a standard, free (no patents) hash-function that works. The fact that somebody can write a program, designed to create collisions, and demonstrate that after many weeks of processing, iteratively building upon the previous result, and finally cause a collision, really isn't relevant for this application. There is a good possibility that there are no hash-functions that can't be broken. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11.7 1/1] x86 reboot: Add reboot fixup for gx1/cs5530a
On Mon, 11 Apr 2005, H. Peter Anvin wrote:
[EMAIL PROTECTED] wrote:
Hi Riley, Dave, Peter, i386 boot/workaround maintainers,
I'm resending this patch (from March 28).
This patch incorporates the suggestions from the previous thread and also
switches to using pci_get_device since pci_find_device is deprecated, and
made some of the variables static.
Please let me know if it's okay.
+#define mach_reboot_fixups(x) do {} while (0)
As I stated last time, this should be:
#define mach_reboot_fixup(x)((void)(x))
... to preserve side effects, and be expression-like.
-hpa
Shouldn't it just be:
#define mach_reboot_fixup(x)
|___ Nothing here.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11.7 1/1] x86 reboot: Add reboot fixup for gx1/cs5530a
On Mon, 11 Apr 2005, H. Peter Anvin wrote:
[EMAIL PROTECTED] wrote:
Hi Riley, Dave, Peter, i386 boot/workaround maintainers,
I'm resending this patch (from March 28).
This patch incorporates the suggestions from the previous thread and also
switches to using pci_get_device since pci_find_device is deprecated, and
made some of the variables static.
Please let me know if it's okay.
+#define mach_reboot_fixups(x) do {} while (0)
As I stated last time, this should be:
#define mach_reboot_fixup(x)((void)(x))
... to preserve side effects, and be expression-like.
-hpa
Shouldn't it just be:
#define mach_reboot_fixup(x)
|___ Nothing here.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.11 can't disable CAD
It wasn't the kernel. Many thanks to those who helped me track down this problem. It seems that the 'C' runtime library was trapping the call to reboot() which probably should have been _reboot() in earlier code to prevent this. Anyway, the fix is to call the kernel directly so it doesn't get blamed for something it didn't do. Simple external procedure is attached if anybody else is interested. It ends up being only 0x30 bytes in length. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction.#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # # Copyright(c) 2005 Analogic Corporation # # This program may be distributed under the GNU Public License # version 2, as published by the Free Software Foundation, Inc., # 59 Temple Place, Suite 330 Boston, MA, 02111. # #-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # # Disable Ctl-Alt-Del # Test environment 'C' runtime libraries are screwing with # this so I have to call the kernel directly. This is now # handled in assembly. # #-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= .extern __set_errno .LREBOOT = 88 .LMAGIC1 = 0xfee1dead .LMAGIC2 = 672274793 .LCADOFF = 0x disable_shutdown: pushl %ebx# Save precious registers pushl %esi movl$.LREBOOT, %eax # Reboot command movl$.LMAGIC1, %ebx # First magic parameter movl$.LMAGIC2, %ecx # Second magic parameter movl$.LCADOFF, %edx # Command xorl%esi, %esi # Zero ignored pointer int $0x80 # Make the call popl%esi# Restore precious registers popl%ebx orl %eax,%eax # Check return value jns 1f # It's okay negl%eax# Make positive pushl %eax call__set_errno # Set new errno addl$0x04, %esp # Level stack movl$-1, %eax 1: ret .size disable_shutdown,.-disable_shutdown .type disable_shutdown,@function .global disable_shutdown #-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= .end
Re: Linux-2.6.11 can't disable CAD
On Fri, 8 Apr 2005, Daniel Jacobowitz wrote: On Thu, Apr 07, 2005 at 04:50:32PM -0400, Richard B. Johnson wrote: On Thu, 7 Apr 2005, Jan Harkes wrote: On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote: In the not-too distant past, one could disable Ctl-Alt-DEL. Can't do it anymore. ... Observe that reboot() returns 0 and `strace` understands what parameters were passed. The result is that, if I hit Ctl-Alt-Del, `init` will still execute the shutdown-order (INIT 0). Actually, if CAD is enabled in the kernel, it will just reboot. If CAD is disabled in the kernel a SIGINT is sent to pid 1 (/sbin/init). No, that's not how it ever worked. There are parameters that are available in the reboot-system call that define the operation that will occur when the 3-finger salute occurs. Execute man 2 reboot. Take your own advice. From the man page: LINUX_REBOOT_CMD_CAD_ON (RB_ENABLE_CAD, 0x89abcdef). CAD is enabled. This means that the CAD keystroke will immediately cause the action associated with LINUX_REBOOT_CMD_RESTART. LINUX_REBOOT_CMD_CAD_OFF (RB_DISABLE_CAD, 0). CAD is disabled. This means that the CAD keystroke will cause a SIGINT signal to be sent to init (process 1), whereupon this process may decide upon a proper action (maybe: kill all processes, sync, reboot). -- Daniel Jacobowitz CodeSourcery, LLC The 'init' in use is not SYS-V init. Instead, it is the startup program, mother-of-all-programs, of a complete embedded system that has no shells, etc. It's just a system that's designed to make images. There are handlers in place for all signals, either to ignore signals or to perform things like X-ON and X-OFF. This 'init' will never shut down the system. It doesn't know how. It also ignores any "harmful" signals and, in fact, will never exit the main program. Again, it doesn't know how. It just forks off some processes and then sleeps, occasionally waking to get and throw away the exit-status of some child's children. Also, this has been working for many years. It is unknown how many linux-versions this worked with since it was first tested with 2.4.x circa 2000 to 2001. It appears that the 'C' runtime library is now trapping reboot() and turning it into a single-parameter function call. It is possible that the correct 4-parameter reboot() is not even making it to the kernel. I am investigating this. I made another function called disable() that will directly make a system-call, thereby bypassing the 'C' runtime library altogether. I am working on this. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.11 can't disable CAD
On Fri, 8 Apr 2005, Daniel Jacobowitz wrote: On Thu, Apr 07, 2005 at 04:50:32PM -0400, Richard B. Johnson wrote: On Thu, 7 Apr 2005, Jan Harkes wrote: On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote: In the not-too distant past, one could disable Ctl-Alt-DEL. Can't do it anymore. ... Observe that reboot() returns 0 and `strace` understands what parameters were passed. The result is that, if I hit Ctl-Alt-Del, `init` will still execute the shutdown-order (INIT 0). Actually, if CAD is enabled in the kernel, it will just reboot. If CAD is disabled in the kernel a SIGINT is sent to pid 1 (/sbin/init). No, that's not how it ever worked. There are parameters that are available in the reboot-system call that define the operation that will occur when the 3-finger salute occurs. Execute man 2 reboot. Take your own advice. From the man page: LINUX_REBOOT_CMD_CAD_ON (RB_ENABLE_CAD, 0x89abcdef). CAD is enabled. This means that the CAD keystroke will immediately cause the action associated with LINUX_REBOOT_CMD_RESTART. LINUX_REBOOT_CMD_CAD_OFF (RB_DISABLE_CAD, 0). CAD is disabled. This means that the CAD keystroke will cause a SIGINT signal to be sent to init (process 1), whereupon this process may decide upon a proper action (maybe: kill all processes, sync, reboot). -- Daniel Jacobowitz CodeSourcery, LLC The 'init' in use is not SYS-V init. Instead, it is the startup program, mother-of-all-programs, of a complete embedded system that has no shells, etc. It's just a system that's designed to make images. There are handlers in place for all signals, either to ignore signals or to perform things like X-ON and X-OFF. This 'init' will never shut down the system. It doesn't know how. It also ignores any harmful signals and, in fact, will never exit the main program. Again, it doesn't know how. It just forks off some processes and then sleeps, occasionally waking to get and throw away the exit-status of some child's children. Also, this has been working for many years. It is unknown how many linux-versions this worked with since it was first tested with 2.4.x circa 2000 to 2001. It appears that the 'C' runtime library is now trapping reboot() and turning it into a single-parameter function call. It is possible that the correct 4-parameter reboot() is not even making it to the kernel. I am investigating this. I made another function called disable() that will directly make a system-call, thereby bypassing the 'C' runtime library altogether. I am working on this. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.11 can't disable CAD
It wasn't the kernel. Many thanks to those who helped me track down this problem. It seems that the 'C' runtime library was trapping the call to reboot() which probably should have been _reboot() in earlier code to prevent this. Anyway, the fix is to call the kernel directly so it doesn't get blamed for something it didn't do. Simple external procedure is attached if anybody else is interested. It ends up being only 0x30 bytes in length. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction.#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # # Copyright(c) 2005 Analogic Corporation # # This program may be distributed under the GNU Public License # version 2, as published by the Free Software Foundation, Inc., # 59 Temple Place, Suite 330 Boston, MA, 02111. # #-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # # Disable Ctl-Alt-Del # Test environment 'C' runtime libraries are screwing with # this so I have to call the kernel directly. This is now # handled in assembly. # #-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= .extern __set_errno .LREBOOT = 88 .LMAGIC1 = 0xfee1dead .LMAGIC2 = 672274793 .LCADOFF = 0x disable_shutdown: pushl %ebx# Save precious registers pushl %esi movl$.LREBOOT, %eax # Reboot command movl$.LMAGIC1, %ebx # First magic parameter movl$.LMAGIC2, %ecx # Second magic parameter movl$.LCADOFF, %edx # Command xorl%esi, %esi # Zero ignored pointer int $0x80 # Make the call popl%esi# Restore precious registers popl%ebx orl %eax,%eax # Check return value jns 1f # It's okay negl%eax# Make positive pushl %eax call__set_errno # Set new errno addl$0x04, %esp # Level stack movl$-1, %eax 1: ret .size disable_shutdown,.-disable_shutdown .type disable_shutdown,@function .global disable_shutdown #-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= .end
Re: Linux-2.6.11 can't disable CAD
On Thu, 7 Apr 2005, Jan Harkes wrote: On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote: In the not-too distant past, one could disable Ctl-Alt-DEL. Can't do it anymore. ... Observe that reboot() returns 0 and `strace` understands what parameters were passed. The result is that, if I hit Ctl-Alt-Del, `init` will still execute the shutdown-order (INIT 0). Actually, if CAD is enabled in the kernel, it will just reboot. If CAD is disabled in the kernel a SIGINT is sent to pid 1 (/sbin/init). No, that's not how it ever worked. There are parameters that are available in the reboot-system call that define the operation that will occur when the 3-finger salute occurs. Execute man 2 reboot. So what you probably had in the not-too-distant past was a disabled CAD in the kernel _and_ you had modified the following line in /etc/inittab, The systems to which I refer do not, and never even had a file-system, much-less any inittab. That's SYS-V init stuff for interactive access. # What to do when CTRL-ALT-DEL is pressed. ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now AFAIK this hasn't ever really changed. Jan The kernel's response (or the 'C' runtime-library interface) has changed so that it is now possible for somebody at the keyboard of a machine to destroy the machine's operation by executing Ctl-Alt-Del. I don't know how long this potential catastrophe has existed, but when the machine(s) were initially certified there was no possible way for a user to kill the machine from the keyboard. It is possible that a 'C' runtime library was changed in the tarket so it's not a kernel problem. I'm checking it out now. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.11 can't disable CAD
On Thu, 7 Apr 2005, Randy.Dunlap wrote: On Thu, 7 Apr 2005 15:46:20 -0400 (EDT) Richard B. Johnson wrote: | On Thu, 7 Apr 2005, Randy.Dunlap wrote: | | > On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote: | > | > | | > | In the not-too distant past, one could disable Ctl-Alt-DEL. | > | Can't do it anymore. | > | > What should disabling C_A_D do? | > | > | Script started on Thu 07 Apr 2005 10:58:11 AM EDT | > | [SNIPPED leading stuff...] | > | | > | mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0 | > | brk(0) = 0x804a000 | > | brk(0x8053000) = 0x8053000 | > | reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF) | > = 0 | > | pause( | > | _exit(0)= ? | > | # exit | > | Script done on Thu 07 Apr 2005 10:58:21 AM EDT | > | | It's a program that executes the __NR_reboot syscall (88) after | putting the documented values into the appropriate registers. Yeah, I understood that much. Just wondering if it was available somewhere... | > What program is that? I'm just echoing 0 | 1 into | > /proc/sys/kernel/ctrl-alt-del , is that equivalent? | > or have you tried that? | > | | Doesn't matter. Many embedded systems don't have /proc because | they don't have any file-systems. It matters if they are equivalent (and I don't have that program above). | > | Observe that reboot() returns 0 and `strace` understands what | > | parameters were passed. The result is that, if I hit Ctl-Alt-Del, | > | `init` will still execute the shutdown-order (INIT 0). | > | > echo 0 > /proc/sys/kernel/ctrl-alt-del | > is same as CAD_OFF | > echo 1 | > is same as CAD_ON | > | > I tested 2.4.28, 2.6.3, 2.6.9, 2.6.11, and all of them behaved | > the same way for me. If it's an issue with using a syscall | > to change the setting, I'll be glad to look into that too. | > | > observed behaviors: | > CAD enabled + C_A_D keys => call machine_reboot() | > to reboot quickly, no normal shutdown sequence; | > CAD disabled + C_A_D keys => kill init, go thru normal | > clean shutdown sequence; | > are these the expected behaviors? | | The expected behavior of the reported operation is for | Ctl-Alt-Del to no longer do anything. If the system-call | has been depreciated, then the call should return -1 and | errno should be ENOSYS. In such a case, I would have | to trap the key-sequence in some other way, not that | I know how without modifying the kernel. Have you looked at 'man 2 reboot'? It seems to agree with the observed behavior (above). or where should I look to find documentation of the expected behavior that you described? man 2 reboot on my system documents the system call interface through the C runtime library. Bbuuu then tells how glib-C munged it into a one-parameter 'C' call. Hmmm. Maybe it's screwing me. I will check into this. I don't know why `strace` shows the correct stuff when I am making the 4-parameter call. Maybe something is really confused Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.11 can't disable CAD
On Thu, 7 Apr 2005, Randy.Dunlap wrote: On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote: | | In the not-too distant past, one could disable Ctl-Alt-DEL. | Can't do it anymore. What should disabling C_A_D do? | Script started on Thu 07 Apr 2005 10:58:11 AM EDT | [SNIPPED leading stuff...] | | mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0 | brk(0) = 0x804a000 | brk(0x8053000) = 0x8053000 | reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF) = 0 | pause( | _exit(0)= ? | # exit | Script done on Thu 07 Apr 2005 10:58:21 AM EDT It's a program that executes the __NR_reboot syscall (88) after putting the documented values into the appropriate registers. What program is that? I'm just echoing 0 | 1 into /proc/sys/kernel/ctrl-alt-del , is that equivalent? or have you tried that? Doesn't matter. Many embedded systems don't have /proc because they don't have any file-systems. | Observe that reboot() returns 0 and `strace` understands what | parameters were passed. The result is that, if I hit Ctl-Alt-Del, | `init` will still execute the shutdown-order (INIT 0). echo 0 > /proc/sys/kernel/ctrl-alt-del is same as CAD_OFF echo 1 is same as CAD_ON I tested 2.4.28, 2.6.3, 2.6.9, 2.6.11, and all of them behaved the same way for me. If it's an issue with using a syscall to change the setting, I'll be glad to look into that too. observed behaviors: CAD enabled + C_A_D keys => call machine_reboot() to reboot quickly, no normal shutdown sequence; CAD disabled + C_A_D keys => kill init, go thru normal clean shutdown sequence; are these the expected behaviors? The expected behavior of the reported operation is for Ctl-Alt-Del to no longer do anything. If the system-call has been depreciated, then the call should return -1 and errno should be ENOSYS. In such a case, I would have to trap the key-sequence in some other way, not that I know how without modifying the kernel. | A side note, while researching this problem, I think I found | that LINUX_REBOOT_MAGIC2 is Linus' birthday (in hex). Maybe | the problem is that he no longer observes his birthday? --- ~Randy Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] disable built-in modules V2
On Thu, 7 Apr 2005, Randy.Dunlap wrote:
On Thu, 7 Apr 2005 10:23:32 +0200 Magnus Damm wrote:
| On Apr 7, 2005 4:23 AM, Roland Dreier <[EMAIL PROTECTED]> wrote:
| > > > -#define module_init(x) __initcall(x);
| > > > +#define module_init(x) __initcall(x); __module_init_disable(x);
| > >
| > > It would be better if there is brackets around them... like
| > >
| > > #define module_init(x) { __initcall(x); __module_init_disable(x); }
| > >
| > > then we know it wont break some code like
| > >
| > > if (..)
| > > module_init(x);
| >
| > This is all completely academic, since module_init() is a declaration
| > that won't be inside any code, but in general it's better still to use
| > the do { } while (0) idiom like
| >
| > #define module_init(x) do { __initcall(x); __module_init_disable(x); }
while (0)
| >
| > so it won't break code like
| >
| > if (..)
| > module_init(x);
| > else
| > something_else();
| >
| > (Yes, that code is nonsense but if you're going to nitpick, go all the
way...)
|
| Right. =)
| Anyway, besides nitpicking, is there any reason not to include this
| code? Or is the added feature considered plain bloat? Yes, the kernel
| will become a bit larger, but all the data added by this patch will go
| into the init section.
Looks like a good idea to me.
---
~Randy
Can't you disable module-loading with a module? I think so.
You don't need to modify the kernel. Boot-scripts could
just load the "final" module and there is nothing that
can be done to add another module (or even unload existing
ones).
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: crash in entry.S restore_all, 2.6.12-rc2, x86, PAGEALLOC
On Thu, 7 Apr 2005, Dave Jones wrote: On Thu, Apr 07, 2005 at 07:47:41AM -0700, Linus Torvalds wrote: > So the sysenter sequence might as well look like > >pushl $(__USER_DS) >pushl %ebp >sti >pushfl >.. > > which actually does three protected pushes thanks to the one-instruction > "interrupt shadow" after an sti. Is this guaranteed on every x86 variant (or rather, every one that has SEP). ? Dave The i486 book says that if the next instruction lets the IF flag remain enabled, then any interrupts pending occur after the next instruction. If the next instruction is CLI, no interrupts will occur. There is a note: "In case of an NM1, trap, or fault following ST1, the interrupt will be taken before executing the next sequential instruction in the code." The use of "NM1" and "ST1" is (sic). I don't know what NM1 is, it can't be NMI because, by definition NMI is not maskable so CLI and STI could not affect this pin. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux-2.6.11 can't disable CAD
In the not-too distant past, one could disable Ctl-Alt-DEL. Can't do it anymore. Script started on Thu 07 Apr 2005 10:58:11 AM EDT [SNIPPED leading stuff...] mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0 brk(0) = 0x804a000 brk(0x8053000) = 0x8053000 reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF) = 0 pause( _exit(0)= ? # exit Script done on Thu 07 Apr 2005 10:58:21 AM EDT Observe that reboot() returns 0 and `strace` understands what parameters were passed. The result is that, if I hit Ctl-Alt-Del, `init` will still execute the shutdown-order (INIT 0). A side note, while researching this problem, I think I found that LINUX_REBOOT_MAGIC2 is Linus' birthday (in hex). Maybe the problem is that he no longer observes his birthday? Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, 7 Apr 2005, Humberto Massa wrote: David Schmitt wrote: On Thursday 07 April 2005 09:25, Jes Sorensen wrote: [snip] I got it from Alteon under a written agreement stating I could distribute the image under the GPL. Since the firmware is simply data to Linux, hence keeping it under the GPL should be just fine. Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. First, there is *NOT* any requirement in the GPL at all that requires making compilers available. Otherwise it would not be possible, for instance, have a Visual Basic GPL'd application. And yes, it is possible. Second, up until the present day I have personal experience with hardware producers that do not have enough money to buy expensive toolchains and used a lot of hand-work to code hardware parameters. So, at least for them, hand-hexcoding-days are still going. HTH, Massa Well it doesn't make any difference. If GPL has degenerated to where one can't upload microcode to a device as part of its initialization, without having the "source" that generated that microcode, we are in a lot of hurt. Intel isn't going to give their designs away. Last time I checked, GPL was about SOFTware, not FIRMware, and not MICROcode. If somebody has decided to rename FIRMware to SOFTware, then they need to complete the task and call it DORKware, named after themselves. This whole thread and gotten truly bizarre. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, 7 Apr 2005, Humberto Massa wrote: David Schmitt wrote: On Thursday 07 April 2005 09:25, Jes Sorensen wrote: [snip] I got it from Alteon under a written agreement stating I could distribute the image under the GPL. Since the firmware is simply data to Linux, hence keeping it under the GPL should be just fine. Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. First, there is *NOT* any requirement in the GPL at all that requires making compilers available. Otherwise it would not be possible, for instance, have a Visual Basic GPL'd application. And yes, it is possible. Second, up until the present day I have personal experience with hardware producers that do not have enough money to buy expensive toolchains and used a lot of hand-work to code hardware parameters. So, at least for them, hand-hexcoding-days are still going. HTH, Massa Well it doesn't make any difference. If GPL has degenerated to where one can't upload microcode to a device as part of its initialization, without having the source that generated that microcode, we are in a lot of hurt. Intel isn't going to give their designs away. Last time I checked, GPL was about SOFTware, not FIRMware, and not MICROcode. If somebody has decided to rename FIRMware to SOFTware, then they need to complete the task and call it DORKware, named after themselves. This whole thread and gotten truly bizarre. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux-2.6.11 can't disable CAD
In the not-too distant past, one could disable Ctl-Alt-DEL. Can't do it anymore. Script started on Thu 07 Apr 2005 10:58:11 AM EDT [SNIPPED leading stuff...] mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0 brk(0) = 0x804a000 brk(0x8053000) = 0x8053000 reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF) = 0 pause( unfinished ... _exit(0)= ? # exit Script done on Thu 07 Apr 2005 10:58:21 AM EDT Observe that reboot() returns 0 and `strace` understands what parameters were passed. The result is that, if I hit Ctl-Alt-Del, `init` will still execute the shutdown-order (INIT 0). A side note, while researching this problem, I think I found that LINUX_REBOOT_MAGIC2 is Linus' birthday (in hex). Maybe the problem is that he no longer observes his birthday? Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: crash in entry.S restore_all, 2.6.12-rc2, x86, PAGEALLOC
On Thu, 7 Apr 2005, Dave Jones wrote: On Thu, Apr 07, 2005 at 07:47:41AM -0700, Linus Torvalds wrote: So the sysenter sequence might as well look like pushl $(__USER_DS) pushl %ebp sti pushfl .. which actually does three protected pushes thanks to the one-instruction interrupt shadow after an sti. Is this guaranteed on every x86 variant (or rather, every one that has SEP). ? Dave The i486 book says that if the next instruction lets the IF flag remain enabled, then any interrupts pending occur after the next instruction. If the next instruction is CLI, no interrupts will occur. There is a note: In case of an NM1, trap, or fault following ST1, the interrupt will be taken before executing the next sequential instruction in the code. The use of NM1 and ST1 is (sic). I don't know what NM1 is, it can't be NMI because, by definition NMI is not maskable so CLI and STI could not affect this pin. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] disable built-in modules V2
On Thu, 7 Apr 2005, Randy.Dunlap wrote:
On Thu, 7 Apr 2005 10:23:32 +0200 Magnus Damm wrote:
| On Apr 7, 2005 4:23 AM, Roland Dreier [EMAIL PROTECTED] wrote:
| -#define module_init(x) __initcall(x);
| +#define module_init(x) __initcall(x); __module_init_disable(x);
|
|It would be better if there is brackets around them... like
|
|#define module_init(x) { __initcall(x); __module_init_disable(x); }
|
|then we know it wont break some code like
|
|if (..)
| module_init(x);
|
| This is all completely academic, since module_init() is a declaration
| that won't be inside any code, but in general it's better still to use
| the do { } while (0) idiom like
|
| #define module_init(x) do { __initcall(x); __module_init_disable(x); }
while (0)
|
| so it won't break code like
|
| if (..)
| module_init(x);
| else
| something_else();
|
| (Yes, that code is nonsense but if you're going to nitpick, go all the
way...)
|
| Right. =)
| Anyway, besides nitpicking, is there any reason not to include this
| code? Or is the added feature considered plain bloat? Yes, the kernel
| will become a bit larger, but all the data added by this patch will go
| into the init section.
Looks like a good idea to me.
---
~Randy
Can't you disable module-loading with a module? I think so.
You don't need to modify the kernel. Boot-scripts could
just load the final module and there is nothing that
can be done to add another module (or even unload existing
ones).
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.11 can't disable CAD
On Thu, 7 Apr 2005, Randy.Dunlap wrote: On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote: | | In the not-too distant past, one could disable Ctl-Alt-DEL. | Can't do it anymore. What should disabling C_A_D do? | Script started on Thu 07 Apr 2005 10:58:11 AM EDT | [SNIPPED leading stuff...] | | mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0 | brk(0) = 0x804a000 | brk(0x8053000) = 0x8053000 | reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF) = 0 | pause( unfinished ... | _exit(0)= ? | # exit | Script done on Thu 07 Apr 2005 10:58:21 AM EDT It's a program that executes the __NR_reboot syscall (88) after putting the documented values into the appropriate registers. What program is that? I'm just echoing 0 | 1 into /proc/sys/kernel/ctrl-alt-del , is that equivalent? or have you tried that? Doesn't matter. Many embedded systems don't have /proc because they don't have any file-systems. | Observe that reboot() returns 0 and `strace` understands what | parameters were passed. The result is that, if I hit Ctl-Alt-Del, | `init` will still execute the shutdown-order (INIT 0). echo 0 /proc/sys/kernel/ctrl-alt-del is same as CAD_OFF echo 1 is same as CAD_ON I tested 2.4.28, 2.6.3, 2.6.9, 2.6.11, and all of them behaved the same way for me. If it's an issue with using a syscall to change the setting, I'll be glad to look into that too. observed behaviors: CAD enabled + C_A_D keys = call machine_reboot() to reboot quickly, no normal shutdown sequence; CAD disabled + C_A_D keys = kill init, go thru normal clean shutdown sequence; are these the expected behaviors? The expected behavior of the reported operation is for Ctl-Alt-Del to no longer do anything. If the system-call has been depreciated, then the call should return -1 and errno should be ENOSYS. In such a case, I would have to trap the key-sequence in some other way, not that I know how without modifying the kernel. | A side note, while researching this problem, I think I found | that LINUX_REBOOT_MAGIC2 is Linus' birthday (in hex). Maybe | the problem is that he no longer observes his birthday? --- ~Randy Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.11 can't disable CAD
On Thu, 7 Apr 2005, Randy.Dunlap wrote: On Thu, 7 Apr 2005 15:46:20 -0400 (EDT) Richard B. Johnson wrote: | On Thu, 7 Apr 2005, Randy.Dunlap wrote: | | On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote: | | | | | In the not-too distant past, one could disable Ctl-Alt-DEL. | | Can't do it anymore. | | What should disabling C_A_D do? | | | Script started on Thu 07 Apr 2005 10:58:11 AM EDT | | [SNIPPED leading stuff...] | | | | mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0 | | brk(0) = 0x804a000 | | brk(0x8053000) = 0x8053000 | | reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF) | = 0 | | pause( unfinished ... | | _exit(0)= ? | | # exit | | Script done on Thu 07 Apr 2005 10:58:21 AM EDT | | | It's a program that executes the __NR_reboot syscall (88) after | putting the documented values into the appropriate registers. Yeah, I understood that much. Just wondering if it was available somewhere... | What program is that? I'm just echoing 0 | 1 into | /proc/sys/kernel/ctrl-alt-del , is that equivalent? | or have you tried that? | | | Doesn't matter. Many embedded systems don't have /proc because | they don't have any file-systems. It matters if they are equivalent (and I don't have that program above). | | Observe that reboot() returns 0 and `strace` understands what | | parameters were passed. The result is that, if I hit Ctl-Alt-Del, | | `init` will still execute the shutdown-order (INIT 0). | | echo 0 /proc/sys/kernel/ctrl-alt-del | is same as CAD_OFF | echo 1 | is same as CAD_ON | | I tested 2.4.28, 2.6.3, 2.6.9, 2.6.11, and all of them behaved | the same way for me. If it's an issue with using a syscall | to change the setting, I'll be glad to look into that too. | | observed behaviors: | CAD enabled + C_A_D keys = call machine_reboot() | to reboot quickly, no normal shutdown sequence; | CAD disabled + C_A_D keys = kill init, go thru normal | clean shutdown sequence; | are these the expected behaviors? | | The expected behavior of the reported operation is for | Ctl-Alt-Del to no longer do anything. If the system-call | has been depreciated, then the call should return -1 and | errno should be ENOSYS. In such a case, I would have | to trap the key-sequence in some other way, not that | I know how without modifying the kernel. Have you looked at 'man 2 reboot'? It seems to agree with the observed behavior (above). or where should I look to find documentation of the expected behavior that you described? man 2 reboot on my system documents the system call interface through the C runtime library. Bbuuu then tells how glib-C munged it into a one-parameter 'C' call. Hmmm. Maybe it's screwing me. I will check into this. I don't know why `strace` shows the correct stuff when I am making the 4-parameter call. Maybe something is really confused Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.11 can't disable CAD
On Thu, 7 Apr 2005, Jan Harkes wrote: On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote: In the not-too distant past, one could disable Ctl-Alt-DEL. Can't do it anymore. ... Observe that reboot() returns 0 and `strace` understands what parameters were passed. The result is that, if I hit Ctl-Alt-Del, `init` will still execute the shutdown-order (INIT 0). Actually, if CAD is enabled in the kernel, it will just reboot. If CAD is disabled in the kernel a SIGINT is sent to pid 1 (/sbin/init). No, that's not how it ever worked. There are parameters that are available in the reboot-system call that define the operation that will occur when the 3-finger salute occurs. Execute man 2 reboot. So what you probably had in the not-too-distant past was a disabled CAD in the kernel _and_ you had modified the following line in /etc/inittab, The systems to which I refer do not, and never even had a file-system, much-less any inittab. That's SYS-V init stuff for interactive access. # What to do when CTRL-ALT-DEL is pressed. ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now AFAIK this hasn't ever really changed. Jan The kernel's response (or the 'C' runtime-library interface) has changed so that it is now possible for somebody at the keyboard of a machine to destroy the machine's operation by executing Ctl-Alt-Del. I don't know how long this potential catastrophe has existed, but when the machine(s) were initially certified there was no possible way for a user to kill the machine from the keyboard. It is possible that a 'C' runtime library was changed in the tarket so it's not a kernel problem. I'm checking it out now. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NOMMU - How to reserve 1 MB in top of memory in a clean way
On Wed, 6 Apr 2005, Catalin Marinas wrote: Bas Vermeulen <[EMAIL PROTECTED]> wrote: I am currently working on the bfinnommu linux port for the BlackFin 533. I need to grab the top 1 MB of memory so I can give it out to drivers that need non-cached memory for DMA operations. I did this long time ago (on a 2.4 kernel), trying to avoid a hardware problem. I re-ordered the zones so that ZONE_DMA came after ZONE_NORMAL. Since the DMA memory was quite small (less than 1MB), I also put a "break" before "case ZONE_DMA" in the build_zonelists_node() functions to avoid the allocation fallback. -- Catalin 1 Megabyte of DMA RAM should be available using conventional means __get_dma_pages(GFP_KERNEL, 0x100) soon after boot. Or just use mem= on the boot command line. This will tell the kernel the extent of memory to use. Any RAM after that is available. Your driver can access kernel variable, "num_physpages" to find the last page it is supposed to use. Some kernel versions actually touch the next page so, to be safe, your code can use: mem = (num_physpages * PAGE_SIZE) + PAGE_SIZE; ... for the first available free RAM. Note that there may be PCI BARS allocated in this address-space if you have 4 Gb of RAM. You need to be carefull. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [BUG mm] "fixed" i386 memcpy inlining buggy
Attached is inline ix86 memcpy() plus test code that tests its
corner-cases. The in-line code makes no jumps, but uses longword
copies, word copies and any spare byte copy. It works at all
offsets, doesn't require alignment but would work fastest if
both source and destination were longword aligned.
On Wed, 6 Apr 2005, Dave Korn wrote:
Original Message
From: Dave Korn
Sent: 06 April 2005 12:13
Original Message
From: Dave Korn
Sent: 06 April 2005 12:06
Me and my big mouth.
OK, that one does work.
Sorry for the outburst.
well, actually, maybe it doesn't after all.
What's that uninitialised variable ecx doing there eh?
cheers,
DaveK
--
Can't think of a witty .sigline today
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
#include
#include
//
// Inline ix86 memcpy() that contains no jumps. Not copied from
// anybody.Contributed by [EMAIL PROTECTED]
//
static __inline__ void *memcpy(void *dst, void *src, size_t len) {
void *ret = dst;
__asm__ __volatile__( \
"cld\n" \
"shr $1, %%ecx\n" \
"pushf\n" \
"shr $1, %%ecx\n" \
"pushf\n" \
"rep\n" \
"movsl\n" \
"popf\n"\
"adcl %%ecx, %%ecx\n" \
"rep\n" \
"movsw\n" \
"popf\n"\
"adcl %%ecx, %%ecx\n" \
"rep\n" \
"movsb\n" \
: "=D" (dst), "=S" (src), "=c"(len)
: "0" (dst), "1" (src), "2" (len)
: "memory" );
return ret;
}
const char tester[]="0123456789"
"0123456789"
"0123456789"
"0123456789"
"0123456789"
"0123456789"
"0123456789"
"0123456789";
char allocated[0x1000];
int main()
{
size_t i;
char buf[0x1000];
memset(buf, 0x00, sizeof(buf));
for(i=0; i< sizeof(buf); i++)
puts(memcpy(buf, (char *)tester, i));
memset(buf, 0x00, sizeof(buf));
for(i=0; i< sizeof(buf)-1; i++)
puts(memcpy([1], (char *)tester, i));
memset(buf, 0x00, sizeof(buf));
for(i=0; i< sizeof(buf)-2; i++)
puts(memcpy([2], (char *)tester, i));
memset(buf, 0x00, sizeof(buf));
for(i=0; i< sizeof(buf)-3; i++)
puts(memcpy([3], (char *)tester, i));
return 0;
}
Re: How's the nforce4 support in Linux?
On Tue, 5 Apr 2005, Julien Wajsberg wrote:
On Apr 5, 2005 4:10 PM, Richard B. Johnson <[EMAIL PROTECTED]> wrote:
On Tue, 5 Apr 2005, Julien Wajsberg wrote:
On Mar 26, 2005 12:59 AM, Julien Wajsberg <[EMAIL PROTECTED]> wrote:
I own an Asus A8N-Sli motherboard with the Nforce4-Sli chipset, and I
experiment the following problem :
Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
DriveReady SeekComplete DataRequest }
Mar 25 22:42:55 evenflow kernel:
Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
Mar 25 22:42:55 evenflow kernel:
Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
^
Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
Of course, if I disable DMA with hdparm, this problem disappear.. but
it isn't a long-term solution ;-)
The long-term solution is to replace either the drive, cable, or the
motherboard that can't do DMA.
It's a recent drive that did ultra DMA on another motherboard, and a
recent motherboard with a cable that did ultra DMA before.It was ultra
DMA2 on this old motherboard, but it still was ultra DMA.
A bad DMA operation can write data
anywhere (right into the middle of the kernel). There isn't
anything software can do about it. Software sets up the
controller for a DMA operation, then waits for an interrupt
that tells it has completed or failed. Software can retry failed
operations until software gets destroyed by the hardware, but
there isn't anything else that can be done.
The fact that disabling DMA makes the problem(s) go away is
proof that it isn't a software problem. There are flash-RAM
devices that emulate IDE drives. Most of these can't do DMA
and the IDE driver doesn't accept that fact. That is a known
bug. One needs to use hdparm to tell it to stop trying to
use DMA. In your case, the driver stopped using DMA when
it found out that it didn't work. There is no bug.
In my case, the driver stopped for hdb, that is my dvd-burner/player.
It did nothing for hda or hdc, I had to disable DMA myself.
Will I have to install Windows XP to prove ultra DMA works correctly
on this setup ? I really don't hope...
How would you know? Windows will just run it as PIOW and be done
with it. Did you ever try to copy a large file in XP? Try it.
Try the same thing in linux on the same hardware. You don't need
a stop-watch. On Win-XP, a 10 megabyte file (hardly large) takes
about 10 seconds. That's 1 megabyte/second. Linux tries to be
a bit faster.
--
Julien
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
On Tue, 5 Apr 2005, Julien Wajsberg wrote:
On Apr 5, 2005 4:10 PM, Richard B. Johnson [EMAIL PROTECTED] wrote:
On Tue, 5 Apr 2005, Julien Wajsberg wrote:
On Mar 26, 2005 12:59 AM, Julien Wajsberg [EMAIL PROTECTED] wrote:
I own an Asus A8N-Sli motherboard with the Nforce4-Sli chipset, and I
experiment the following problem :
Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
DriveReady SeekComplete DataRequest }
Mar 25 22:42:55 evenflow kernel:
Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
Mar 25 22:42:55 evenflow kernel:
Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
^
Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
Of course, if I disable DMA with hdparm, this problem disappear.. but
it isn't a long-term solution ;-)
The long-term solution is to replace either the drive, cable, or the
motherboard that can't do DMA.
It's a recent drive that did ultra DMA on another motherboard, and a
recent motherboard with a cable that did ultra DMA before.It was ultra
DMA2 on this old motherboard, but it still was ultra DMA.
A bad DMA operation can write data
anywhere (right into the middle of the kernel). There isn't
anything software can do about it. Software sets up the
controller for a DMA operation, then waits for an interrupt
that tells it has completed or failed. Software can retry failed
operations until software gets destroyed by the hardware, but
there isn't anything else that can be done.
The fact that disabling DMA makes the problem(s) go away is
proof that it isn't a software problem. There are flash-RAM
devices that emulate IDE drives. Most of these can't do DMA
and the IDE driver doesn't accept that fact. That is a known
bug. One needs to use hdparm to tell it to stop trying to
use DMA. In your case, the driver stopped using DMA when
it found out that it didn't work. There is no bug.
In my case, the driver stopped for hdb, that is my dvd-burner/player.
It did nothing for hda or hdc, I had to disable DMA myself.
Will I have to install Windows XP to prove ultra DMA works correctly
on this setup ? I really don't hope...
How would you know? Windows will just run it as PIOW and be done
with it. Did you ever try to copy a large file in XP? Try it.
Try the same thing in linux on the same hardware. You don't need
a stop-watch. On Win-XP, a 10 megabyte file (hardly large) takes
about 10 seconds. That's 1 megabyte/second. Linux tries to be
a bit faster.
--
Julien
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [BUG mm] fixed i386 memcpy inlining buggy
Attached is inline ix86 memcpy() plus test code that tests its
corner-cases. The in-line code makes no jumps, but uses longword
copies, word copies and any spare byte copy. It works at all
offsets, doesn't require alignment but would work fastest if
both source and destination were longword aligned.
On Wed, 6 Apr 2005, Dave Korn wrote:
Original Message
From: Dave Korn
Sent: 06 April 2005 12:13
Original Message
From: Dave Korn
Sent: 06 April 2005 12:06
Me and my big mouth.
OK, that one does work.
Sorry for the outburst.
well, actually, maybe it doesn't after all.
What's that uninitialised variable ecx doing there eh?
cheers,
DaveK
--
Can't think of a witty .sigline today
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
#include stdio.h
#include string.h
//
// Inline ix86 memcpy() that contains no jumps. Not copied from
// anybody.Contributed by [EMAIL PROTECTED]
//
static __inline__ void *memcpy(void *dst, void *src, size_t len) {
void *ret = dst;
__asm__ __volatile__( \
cld\n \
shr $1, %%ecx\n \
pushf\n \
shr $1, %%ecx\n \
pushf\n \
rep\n \
movsl\n \
popf\n\
adcl %%ecx, %%ecx\n \
rep\n \
movsw\n \
popf\n\
adcl %%ecx, %%ecx\n \
rep\n \
movsb\n \
: =D (dst), =S (src), =c(len)
: 0 (dst), 1 (src), 2 (len)
: memory );
return ret;
}
const char tester[]=0123456789
0123456789
0123456789
0123456789
0123456789
0123456789
0123456789
0123456789;
char allocated[0x1000];
int main()
{
size_t i;
char buf[0x1000];
memset(buf, 0x00, sizeof(buf));
for(i=0; i sizeof(buf); i++)
puts(memcpy(buf, (char *)tester, i));
memset(buf, 0x00, sizeof(buf));
for(i=0; i sizeof(buf)-1; i++)
puts(memcpy(buf[1], (char *)tester, i));
memset(buf, 0x00, sizeof(buf));
for(i=0; i sizeof(buf)-2; i++)
puts(memcpy(buf[2], (char *)tester, i));
memset(buf, 0x00, sizeof(buf));
for(i=0; i sizeof(buf)-3; i++)
puts(memcpy(buf[3], (char *)tester, i));
return 0;
}
Re: NOMMU - How to reserve 1 MB in top of memory in a clean way
On Wed, 6 Apr 2005, Catalin Marinas wrote: Bas Vermeulen [EMAIL PROTECTED] wrote: I am currently working on the bfinnommu linux port for the BlackFin 533. I need to grab the top 1 MB of memory so I can give it out to drivers that need non-cached memory for DMA operations. I did this long time ago (on a 2.4 kernel), trying to avoid a hardware problem. I re-ordered the zones so that ZONE_DMA came after ZONE_NORMAL. Since the DMA memory was quite small (less than 1MB), I also put a break before case ZONE_DMA in the build_zonelists_node() functions to avoid the allocation fallback. -- Catalin 1 Megabyte of DMA RAM should be available using conventional means __get_dma_pages(GFP_KERNEL, 0x100) soon after boot. Or just use mem= on the boot command line. This will tell the kernel the extent of memory to use. Any RAM after that is available. Your driver can access kernel variable, num_physpages to find the last page it is supposed to use. Some kernel versions actually touch the next page so, to be safe, your code can use: mem = (num_physpages * PAGE_SIZE) + PAGE_SIZE; ... for the first available free RAM. Note that there may be PCI BARS allocated in this address-space if you have 4 Gb of RAM. You need to be carefull. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, 5 Apr 2005, Josselin Mouette wrote: Le mardi 05 avril 2005 ÿÿ 11:50 -0400, Richard B. Johnson a ÿÿcrit : You are mixing apples and oranges. The fact that the GFDL sucks has nothing to do with the firmware issue. With the current situation of firmwares in the kernel, it is illegal to redistribute binary images of the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still be willing to distribute such binary images, but it isn't our problem. Wrong! It is perfectly legal in the United States, and I'm pretty sure in your country, to distribute or redistribute copyrighted works. Otherwise there wouldn't be any bookstores or newspaper stands. It is not legal to distribute the mix of a GPL software (the Linux kernel) and a proprietary file (the firmware). I wasn't aware of the "mere aggregation" interpretation, and I'm probably a bit late to say I disagree with it - mainly because you'd have a hard time convincing a court this is the case. There is nothing about firmware that is any different than any other component of a product. If the product was legally obtained and it requires firmware to run, then there are no special considerations about how one inserts the firmware into the product. Indeed, but that's not what I'm talking about. If you are a GPL-religious-zealot who believes that you are supposed to get the technical design (i.e. the software schematics) of the hardware device for free so you can copy it, then you are going to have to learn something about intellectual property. Maybe you should try to understand what people are saying before teaching them anything. The firmware, in most cases, are the bits generated by a design program that creates the function of the device. It's what the manufacturer paid 5-10 engineers over a period of a year or so to produce. The rest of the design is just some chips you can get off-the-shelf. Even if the manufacturer said; "Here you are You can have the design". You don't have the "compilers" and other stuff necessary to turn this design into the firmware unless you planned to steal the design. So, you either accept the firmware component, thanking the manufacturer for it, or you go cry foul someplace else. This whole firmware thing is a non-issue, blown way out of proportion by people who don't have a clue. You are completely missing the point. I don't care whether the firmwares should be free, or whether they could be free. The fact is they are not free, and Debian doesn't distribute non-free software in the "main" archive. The fact is also that mixing them with a GPLed software gives an result you can't redistribute - although it seems many people disagree with that assertion now. As previously explained, if I buy a screen-card I get a driver that will allow it to run under Windows. If I extract the stuff from that driver that allows me to run it under Linux, that constitutes fair use. Otherwise there are criminal issues like restraint-of-trade and similar problems for the manufacturer. That firmware is free for use on/in the device you purchased. Finally, you shouldn't forget that, technically speaking, using hotplug for uploading the firmware is much more flexible and elegant than including it in the kernel. Upgrading the firmware and the module should be two independent operations. People who are advocating the current situation are refusing technical improvements just because they are brought by people they find convenient to call "zealots". Throwing in a bit of truth to a pile of bullshit still leaves the bullshit. It isn't relevant to the issue whether or not upgrading firmware as a separate function from loading a module is "good" or "bad". -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction.
Re: debug: sleeping function...slab.c:2090
On Tue, 5 Apr 2005, Steven Rostedt wrote: On Tue, 2005-04-05 at 10:38 -0400, Richard B. Johnson wrote: On Tue, 5 Apr 2005, John M Flinchbaugh wrote: I got the debug statement below during boot. Environment: Pentium M, Thinkpad R40 Debian unstable Linux 2.6.12-rc2 Gnu C 3.3.5 binutils 2.15 Debug: sleeping function called from invalid context at mm/slab.c:2090 in_atomic():1, irqs_disabled():0 [] dump_stack+0x17/0x20 [] __might_sleep+0xac/0xc0 [] kmem_cache_alloc+0x5e/0x60 [] kmem_cache_create+0xe3/0x570 [] proto_register+0x99/0xc0 [] inet6_init+0x16/0x1d0 [ipv6] [] sys_init_module+0x172/0x230 [] syscall_call+0x7/0xb -- John M Flinchbaugh [EMAIL PROTECTED] What module was being loaded at the time? Looks to me that it happened while loading the inet6 module. Yes and somebody is working on it. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, 5 Apr 2005, Humberto Massa wrote: Josselin Mouette wrote: You are mixing apples and oranges. The fact that the GFDL sucks has nothing to do with the firmware issue. With the current situation of firmwares in the kernel, it is illegal to redistribute binary images of the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still be willing to distribute such binary images, but it isn't our problem. Wrong! It is perfectly legal in the United States, and I'm pretty sure in your country, to distribute or redistribute copyrighted works. Otherwise there wouldn't be any bookstores or newspaper stands. There is nothing about firmware that is any different than any other component of a product. If the product was legally obtained and it requires firmware to run, then there are no special considerations about how one inserts the firmware into the product. If you are a GPL-religious-zealot who believes that you are supposed to get the technical design (i.e. the software schematics) of the hardware device for free so you can copy it, then you are going to have to learn something about intellectual property. The firmware, in most cases, are the bits generated by a design program that creates the function of the device. It's what the manufacturer paid 5-10 engineers over a period of a year or so to produce. The rest of the design is just some chips you can get off-the-shelf. Even if the manufacturer said; "Here you are You can have the design". You don't have the "compilers" and other stuff necessary to turn this design into the firmware unless you planned to steal the design. So, you either accept the firmware component, thanking the manufacturer for it, or you go cry foul someplace else. This whole firmware thing is a non-issue, blown way out of proportion by people who don't have a clue. Sometimes a manufacturer doesn't have a separate bag-of-bits to supply competing operating systems. Instead, only one "driver" for one OS was produced by the manufacturer. Extracting those bits, from offset-N to offset-M in that driver likely constitutes fair use as long as the product wasn't stolen and the driver was distributed with the product, or was publicly available. Yes, GFDL has nothing to do with the main issue. No, it is not necessarily illegal to redistribute binary images of the kernel as they are today (see below). The first problem is that they (the complete w/firmware kernel binary images) are not DFSG-free, anyway. The second problem is that some firmware blobs don't have explicitly stated in the kernel tree which exactly are their licensing terms for redistribution -- those are, in principle, undistributable. Putting the firmwares outside the kernel makes them distributable. Some distributions will want to include them, some others not. But the important point is that it makes that redistribution legal. If putting the firmwares outside the kernel makes *them* distributable, then the binary kernel image is already distributable -- just not DFSG-free. The important fact WRT Debian, IMHO, is that putting the firmwares outside the kernel makes the kernel binary image DFSG-free. HTH, Massa Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: debug: sleeping function...slab.c:2090
On Tue, 5 Apr 2005, John M Flinchbaugh wrote: I got the debug statement below during boot. Environment: Pentium M, Thinkpad R40 Debian unstable Linux 2.6.12-rc2 Gnu C 3.3.5 binutils 2.15 Debug: sleeping function called from invalid context at mm/slab.c:2090 in_atomic():1, irqs_disabled():0 [] dump_stack+0x17/0x20 [] __might_sleep+0xac/0xc0 [] kmem_cache_alloc+0x5e/0x60 [] kmem_cache_create+0xe3/0x570 [] proto_register+0x99/0xc0 [] inet6_init+0x16/0x1d0 [ipv6] [] sys_init_module+0x172/0x230 [] syscall_call+0x7/0xb -- John M Flinchbaugh [EMAIL PROTECTED] What module was being loaded at the time? Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
On Tue, 5 Apr 2005, Julien Wajsberg wrote:
On Mar 26, 2005 12:59 AM, Julien Wajsberg <[EMAIL PROTECTED]> wrote:
I own an Asus A8N-Sli motherboard with the Nforce4-Sli chipset, and I
experiment the following problem :
Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
DriveReady SeekComplete DataRequest }
Mar 25 22:42:55 evenflow kernel:
Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
Mar 25 22:42:55 evenflow kernel:
Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
^
Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
Of course, if I disable DMA with hdparm, this problem disappear.. but
it isn't a long-term solution ;-)
The long-term solution is to replace either the drive, cable, or the
motherboard that can't do DMA. A bad DMA operation can write data
anywhere (right into the middle of the kernel). There isn't
anything software can do about it. Software sets up the
controller for a DMA operation, then waits for an interrupt
that tells it has completed or failed. Software can retry failed
operations until software gets destroyed by the hardware, but
there isn't anything else that can be done.
The fact that disabling DMA makes the problem(s) go away is
proof that it isn't a software problem. There are flash-RAM
devices that emulate IDE drives. Most of these can't do DMA
and the IDE driver doesn't accept that fact. That is a known
bug. One needs to use hdparm to tell it to stop trying to
use DMA. In your case, the driver stopped using DMA when
it found out that it didn't work. There is no bug.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Use of C99 int types
On Mon, 4 Apr 2005, Kyle Moffett wrote: On Apr 04, 2005, at 17:25, Richard B. Johnson wrote: I don't find stdint.h in the kernel source (up to 2.6.11). Is this going to be a new addition? Uhh, no. stdint.h is part of glibc, not the kernel. It would be very helpful to start using the uint(8,16,32,64)_t types because they are self-evident, a lot more than size_t or, my favorite wchar_t. You miss the point of size_t and ssize_t/ptrdiff_t. They are types guaranteed to be at least as big as the pointer size. uint8/16/32/64, on the other hand, are specific bit-sizes, which may not be as fast or correct as a simple size_t. Linus has pointed out that while it doesn't matter which of __u32, u32, uint32_t, etc you use for kernel private interfaces, you *cannot* use anything other than __u32 in the parts of headers that userspace will see, because __u32 is defined only by the kernel and so there is no risk for conflicts, as opposed to uint32_t, which is also defined by libc, resulting in collisions in naming. Cheers, Kyle Moffett Actually not. I think the whole point of the C99 (POSIX integer) types is to avoid problems like you cite. Nobody should be using types that begin with an underscore in user-code anyway. That name-space is reserved. One cannot just use 'int' or 'long', in particular when interfacing with an operating system. For example, look at the socket interface code. Parameters are put into an array of longs and a pointer to this array is passed to the socket interface. It's a mess when converting this code to 64-bit world. If originally one used a structure of the correct POSIX integer types, and a pointer to the structure was passed, then absolutely nothing in the source- code would have to be changed at all when compiling that interface for a 64-bit machine. The continual short-cuts, with the continual "special-case" hacks is what makes porting difficult. That's what the POSIX types was supposed to help prevent. That's why I think if there was a stdint.h file in the kernel, when people were performing maintenance or porting their code, they could start using those types. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, 5 Apr 2005, Josselin Mouette wrote: Le mardi 05 avril 2005 ÿÿ 11:50 -0400, Richard B. Johnson a ÿÿcrit : You are mixing apples and oranges. The fact that the GFDL sucks has nothing to do with the firmware issue. With the current situation of firmwares in the kernel, it is illegal to redistribute binary images of the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still be willing to distribute such binary images, but it isn't our problem. Wrong! It is perfectly legal in the United States, and I'm pretty sure in your country, to distribute or redistribute copyrighted works. Otherwise there wouldn't be any bookstores or newspaper stands. It is not legal to distribute the mix of a GPL software (the Linux kernel) and a proprietary file (the firmware). I wasn't aware of the mere aggregation interpretation, and I'm probably a bit late to say I disagree with it - mainly because you'd have a hard time convincing a court this is the case. There is nothing about firmware that is any different than any other component of a product. If the product was legally obtained and it requires firmware to run, then there are no special considerations about how one inserts the firmware into the product. Indeed, but that's not what I'm talking about. If you are a GPL-religious-zealot who believes that you are supposed to get the technical design (i.e. the software schematics) of the hardware device for free so you can copy it, then you are going to have to learn something about intellectual property. Maybe you should try to understand what people are saying before teaching them anything. The firmware, in most cases, are the bits generated by a design program that creates the function of the device. It's what the manufacturer paid 5-10 engineers over a period of a year or so to produce. The rest of the design is just some chips you can get off-the-shelf. Even if the manufacturer said; Here you are You can have the design. You don't have the compilers and other stuff necessary to turn this design into the firmware unless you planned to steal the design. So, you either accept the firmware component, thanking the manufacturer for it, or you go cry foul someplace else. This whole firmware thing is a non-issue, blown way out of proportion by people who don't have a clue. You are completely missing the point. I don't care whether the firmwares should be free, or whether they could be free. The fact is they are not free, and Debian doesn't distribute non-free software in the main archive. The fact is also that mixing them with a GPLed software gives an result you can't redistribute - although it seems many people disagree with that assertion now. As previously explained, if I buy a screen-card I get a driver that will allow it to run under Windows. If I extract the stuff from that driver that allows me to run it under Linux, that constitutes fair use. Otherwise there are criminal issues like restraint-of-trade and similar problems for the manufacturer. That firmware is free for use on/in the device you purchased. Finally, you shouldn't forget that, technically speaking, using hotplug for uploading the firmware is much more flexible and elegant than including it in the kernel. Upgrading the firmware and the module should be two independent operations. People who are advocating the current situation are refusing technical improvements just because they are brought by people they find convenient to call zealots. Throwing in a bit of truth to a pile of bullshit still leaves the bullshit. It isn't relevant to the issue whether or not upgrading firmware as a separate function from loading a module is good or bad. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction.
Re: Use of C99 int types
On Mon, 4 Apr 2005, Kyle Moffett wrote: On Apr 04, 2005, at 17:25, Richard B. Johnson wrote: I don't find stdint.h in the kernel source (up to 2.6.11). Is this going to be a new addition? Uhh, no. stdint.h is part of glibc, not the kernel. It would be very helpful to start using the uint(8,16,32,64)_t types because they are self-evident, a lot more than size_t or, my favorite wchar_t. You miss the point of size_t and ssize_t/ptrdiff_t. They are types guaranteed to be at least as big as the pointer size. uint8/16/32/64, on the other hand, are specific bit-sizes, which may not be as fast or correct as a simple size_t. Linus has pointed out that while it doesn't matter which of __u32, u32, uint32_t, etc you use for kernel private interfaces, you *cannot* use anything other than __u32 in the parts of headers that userspace will see, because __u32 is defined only by the kernel and so there is no risk for conflicts, as opposed to uint32_t, which is also defined by libc, resulting in collisions in naming. Cheers, Kyle Moffett Actually not. I think the whole point of the C99 (POSIX integer) types is to avoid problems like you cite. Nobody should be using types that begin with an underscore in user-code anyway. That name-space is reserved. One cannot just use 'int' or 'long', in particular when interfacing with an operating system. For example, look at the socket interface code. Parameters are put into an array of longs and a pointer to this array is passed to the socket interface. It's a mess when converting this code to 64-bit world. If originally one used a structure of the correct POSIX integer types, and a pointer to the structure was passed, then absolutely nothing in the source- code would have to be changed at all when compiling that interface for a 64-bit machine. The continual short-cuts, with the continual special-case hacks is what makes porting difficult. That's what the POSIX types was supposed to help prevent. That's why I think if there was a stdint.h file in the kernel, when people were performing maintenance or porting their code, they could start using those types. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
On Tue, 5 Apr 2005, Julien Wajsberg wrote:
On Mar 26, 2005 12:59 AM, Julien Wajsberg [EMAIL PROTECTED] wrote:
I own an Asus A8N-Sli motherboard with the Nforce4-Sli chipset, and I
experiment the following problem :
Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
DriveReady SeekComplete DataRequest }
Mar 25 22:42:55 evenflow kernel:
Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
Mar 25 22:42:55 evenflow kernel:
Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
^
Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
Of course, if I disable DMA with hdparm, this problem disappear.. but
it isn't a long-term solution ;-)
The long-term solution is to replace either the drive, cable, or the
motherboard that can't do DMA. A bad DMA operation can write data
anywhere (right into the middle of the kernel). There isn't
anything software can do about it. Software sets up the
controller for a DMA operation, then waits for an interrupt
that tells it has completed or failed. Software can retry failed
operations until software gets destroyed by the hardware, but
there isn't anything else that can be done.
The fact that disabling DMA makes the problem(s) go away is
proof that it isn't a software problem. There are flash-RAM
devices that emulate IDE drives. Most of these can't do DMA
and the IDE driver doesn't accept that fact. That is a known
bug. One needs to use hdparm to tell it to stop trying to
use DMA. In your case, the driver stopped using DMA when
it found out that it didn't work. There is no bug.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: debug: sleeping function...slab.c:2090
On Tue, 5 Apr 2005, John M Flinchbaugh wrote: I got the debug statement below during boot. Environment: Pentium M, Thinkpad R40 Debian unstable Linux 2.6.12-rc2 Gnu C 3.3.5 binutils 2.15 Debug: sleeping function called from invalid context at mm/slab.c:2090 in_atomic():1, irqs_disabled():0 [c0103707] dump_stack+0x17/0x20 [c0114e6c] __might_sleep+0xac/0xc0 [c014394e] kmem_cache_alloc+0x5e/0x60 [c0142aa3] kmem_cache_create+0xe3/0x570 [c0268d39] proto_register+0x99/0xc0 [e0bea096] inet6_init+0x16/0x1d0 [ipv6] [c0132902] sys_init_module+0x172/0x230 [c01030e5] syscall_call+0x7/0xb -- John M Flinchbaugh [EMAIL PROTECTED] What module was being loaded at the time? Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, 5 Apr 2005, Humberto Massa wrote: Josselin Mouette wrote: You are mixing apples and oranges. The fact that the GFDL sucks has nothing to do with the firmware issue. With the current situation of firmwares in the kernel, it is illegal to redistribute binary images of the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still be willing to distribute such binary images, but it isn't our problem. Wrong! It is perfectly legal in the United States, and I'm pretty sure in your country, to distribute or redistribute copyrighted works. Otherwise there wouldn't be any bookstores or newspaper stands. There is nothing about firmware that is any different than any other component of a product. If the product was legally obtained and it requires firmware to run, then there are no special considerations about how one inserts the firmware into the product. If you are a GPL-religious-zealot who believes that you are supposed to get the technical design (i.e. the software schematics) of the hardware device for free so you can copy it, then you are going to have to learn something about intellectual property. The firmware, in most cases, are the bits generated by a design program that creates the function of the device. It's what the manufacturer paid 5-10 engineers over a period of a year or so to produce. The rest of the design is just some chips you can get off-the-shelf. Even if the manufacturer said; Here you are You can have the design. You don't have the compilers and other stuff necessary to turn this design into the firmware unless you planned to steal the design. So, you either accept the firmware component, thanking the manufacturer for it, or you go cry foul someplace else. This whole firmware thing is a non-issue, blown way out of proportion by people who don't have a clue. Sometimes a manufacturer doesn't have a separate bag-of-bits to supply competing operating systems. Instead, only one driver for one OS was produced by the manufacturer. Extracting those bits, from offset-N to offset-M in that driver likely constitutes fair use as long as the product wasn't stolen and the driver was distributed with the product, or was publicly available. Yes, GFDL has nothing to do with the main issue. No, it is not necessarily illegal to redistribute binary images of the kernel as they are today (see below). The first problem is that they (the complete w/firmware kernel binary images) are not DFSG-free, anyway. The second problem is that some firmware blobs don't have explicitly stated in the kernel tree which exactly are their licensing terms for redistribution -- those are, in principle, undistributable. Putting the firmwares outside the kernel makes them distributable. Some distributions will want to include them, some others not. But the important point is that it makes that redistribution legal. If putting the firmwares outside the kernel makes *them* distributable, then the binary kernel image is already distributable -- just not DFSG-free. The important fact WRT Debian, IMHO, is that putting the firmwares outside the kernel makes the kernel binary image DFSG-free. HTH, Massa Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: debug: sleeping function...slab.c:2090
On Tue, 5 Apr 2005, Steven Rostedt wrote: On Tue, 2005-04-05 at 10:38 -0400, Richard B. Johnson wrote: On Tue, 5 Apr 2005, John M Flinchbaugh wrote: I got the debug statement below during boot. Environment: Pentium M, Thinkpad R40 Debian unstable Linux 2.6.12-rc2 Gnu C 3.3.5 binutils 2.15 Debug: sleeping function called from invalid context at mm/slab.c:2090 in_atomic():1, irqs_disabled():0 [c0103707] dump_stack+0x17/0x20 [c0114e6c] __might_sleep+0xac/0xc0 [c014394e] kmem_cache_alloc+0x5e/0x60 [c0142aa3] kmem_cache_create+0xe3/0x570 [c0268d39] proto_register+0x99/0xc0 [e0bea096] inet6_init+0x16/0x1d0 [ipv6] [c0132902] sys_init_module+0x172/0x230 [c01030e5] syscall_call+0x7/0xb -- John M Flinchbaugh [EMAIL PROTECTED] What module was being loaded at the time? Looks to me that it happened while loading the inet6 module. Yes and somebody is working on it. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use of C99 int types
On Mon, 4 Apr 2005, Al Viro wrote: On Mon, Apr 04, 2005 at 10:30:52PM +0200, Renate Meijer wrote: When used improperly. The #define Al Viro objected to, is objectionable. It's highly misleading, as Mr. Viro pointed out. I fail to see where he made comments on stdint.h as such. Comments on stdint.h are very simple: ...fast... type names are misleading in exactly the same way as that define. The fact that they are in standard does not outweight the confusion potential. I don't find stdint.h in the kernel source (up to 2.6.11). Is this going to be a new addition? It would be very helpful to start using the uint(8,16,32,64)_t types because they are self-evident, a lot more than size_t or, my favorite wchar_t. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmap() and ioctl()
On Mon, 4 Apr 2005, Matthew Dharm wrote: This probably is a silly question, but Is is possible to open a file, mmap() it into memory, then pass the address of that map via an ioctl() call to the kernel, which will copy_from_user() that data? Yes. A user-mode pointer, passed via ioctl() is valid in the kernel in the context of the user, i.e., during read() write() ioctl(). However, it is not valid if it is accessed by some other process or an interrupt. In other words, you can't store it somewhere and access it later in some other context. Yeah, that's an odd concept, I know... I could always malloc() some memory, read the file in, and then ioctl() it. But, if I could get away with a direct mmap(), that would be much better for me. Matt Since you need to copy anyway, you could mmap() your kernel data (impliment mmap in your driver). Then you mmap both "files" the same way and copy to/from in user-mode. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iomapping a big endian area
On Mon, 4 Apr 2005, David Vrabel wrote: James Bottomley wrote: so can you provide an example of a BE bus (or device) used on a LE platform that would actually benefit from this abstraction? The Network Processing Engines in the Intel IXP425 are big-endian and its XScale core may be run in little-endian mode. There's a bunch of gotchas related to running in little-endian mode so you typically run the IXP425 in big-endian mode, though. But the Linux interface (on the CPU side of the PCI bus interface) doesn't care about the implimentation details in the XScale Core. That's why it's a complete subsystem, isolated from the ix86 by the PCI/Bus interface. David Vrabel -- David Vrabel, Design Engineer Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233 Cambridge CB1 7EA, UK Web: http://www.arcom.com/ Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iomapping a big endian area
On Mon, 4 Apr 2005, David Vrabel wrote: James Bottomley wrote: so can you provide an example of a BE bus (or device) used on a LE platform that would actually benefit from this abstraction? The Network Processing Engines in the Intel IXP425 are big-endian and its XScale core may be run in little-endian mode. There's a bunch of gotchas related to running in little-endian mode so you typically run the IXP425 in big-endian mode, though. But the Linux interface (on the CPU side of the PCI bus interface) doesn't care about the implimentation details in the XScale Core. That's why it's a complete subsystem, isolated from the ix86 by the PCI/Bus interface. David Vrabel -- David Vrabel, Design Engineer Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233 Cambridge CB1 7EA, UK Web: http://www.arcom.com/ Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmap() and ioctl()
On Mon, 4 Apr 2005, Matthew Dharm wrote: This probably is a silly question, but Is is possible to open a file, mmap() it into memory, then pass the address of that map via an ioctl() call to the kernel, which will copy_from_user() that data? Yes. A user-mode pointer, passed via ioctl() is valid in the kernel in the context of the user, i.e., during read() write() ioctl(). However, it is not valid if it is accessed by some other process or an interrupt. In other words, you can't store it somewhere and access it later in some other context. Yeah, that's an odd concept, I know... I could always malloc() some memory, read the file in, and then ioctl() it. But, if I could get away with a direct mmap(), that would be much better for me. Matt Since you need to copy anyway, you could mmap() your kernel data (impliment mmap in your driver). Then you mmap both files the same way and copy to/from in user-mode. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use of C99 int types
On Mon, 4 Apr 2005, Al Viro wrote: On Mon, Apr 04, 2005 at 10:30:52PM +0200, Renate Meijer wrote: When used improperly. The #define Al Viro objected to, is objectionable. It's highly misleading, as Mr. Viro pointed out. I fail to see where he made comments on stdint.h as such. Comments on stdint.h are very simple: ...fast... type names are misleading in exactly the same way as that define. The fact that they are in standard does not outweight the confusion potential. I don't find stdint.h in the kernel source (up to 2.6.11). Is this going to be a new addition? It would be very helpful to start using the uint(8,16,32,64)_t types because they are self-evident, a lot more than size_t or, my favorite wchar_t. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clean up kernel messages
On Fri, 1 Apr 2005, Steven Rostedt wrote: On Fri, 2005-04-01 at 16:18 -0500, Steven Rostedt wrote: On Fri, 2005-04-01 at 12:46 -0800, Matt Mackall wrote: On Fri, Apr 01, 2005 at 12:26:41PM -0800, Andrew Morton wrote: Matt Mackall <[EMAIL PROTECTED]> wrote: This patch tidies up those annoying kernel messages. A typical kernel boot now looks like this: Loading Linux... Uncompressing kernel... # See? Much nicer. This patch saves about 375k on my laptop config and nearly 100k on minimal configs. heh. Please take a look at http://www.uwsg.iu.edu/hypermail/linux/kernel/0004.2/0709.html, see if Graham did anything which you missed. He's got a bunch of stuff that's not strictly related in there and stuff I've already dealt with (vprintk and the like) and stuff that's still forthcoming (panic tweaks, etc.). I also leave in all the APIs like dmesg, they just no longer do anything. Looking at your other patches, I'm assuming that this is just another April 1st type of patch. Is it? Arg! I'm too tired. I took another look at your other patches and they look more legit now. On first glance, I thought you were just bluntly removing BUGs and error messages to quiet things down. But after taking another look, I see that they are more than that. I wouldn't of thought about that on any other day. Sorry, -- Steve Methinks he still is kidding. We have "quiet" as a parameter now to quiet things down on a boot. Now if he would just get rid of the annoying... Loading Linux... Uncompressing kernel... He'd have something. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Low file-system performance for 2.6.11 compared to 2.4.26
On Thu, 31 Mar 2005, Nick Piggin wrote: linux-os wrote: For those interested, some file-system tests and a test-tools are attached. I'll give it a run when I get a chance. Thanks. In the meantime, can you try with different io schedulers? I was trying to emulate some old servers that had new kernels installed. These servers are used to send medical images around. One used to get a 512x512x16-bit image to a work-station in a few hundred milliseconds. It takes seconds with the newer kernels. I found out that the SCSI disk(s) were running continuously and sampled their I/O patterns. The 'C' code comes very close to emulating that. The installation involved an "ugrade" to linux-2.6.5-1.358 that came with a RedHat Fedora distibution. The provided code will even HALT that distibution. Everything goes into the 'D' state and waits forever (at least overnight). Later versions like linux-2.6.8 will run to completion but with verrry slow through-put. Never versions, like linux-2.6.11 will run, but with a strange slowness, everything in 'D' and the file-system can end up with missing files. The SCSI controller is AIC7XXX, and the fs is ext3 with jbd, just as it comes from Red Hat. Also, my .signature disappeared during the file-system tests. There were no errors and e2fsck thinks everything is fine! You seem to be constantly plagued by gremlins. I don't know whether to laugh or cry. I test many, many (too many) systems as part of my job. When somebody writes a hardware device-driver and I get to check it, sometimes it blows up or doesn't otherwise work. I then test the bare kernel(s) and I often find some really strange things going on. For instance, there was a recent change that make the BKL be held during an ioctl(). This has devistating performance consequences with a lot of drivers. For instance, the stuff that writes CD/ROMs. It does a lot of the work using ioctl(), the firewire drivers also use ioctl() for I/O. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] : remove unreliable, unused and unmainained arch from kernel.
On Fri, 1 Apr 2005, Dmitry Torokhov wrote: On Apr 1, 2005 10:16 AM, Richard B. Johnson <[EMAIL PROTECTED]> wrote: On Fri, 1 Apr 2005, Renate Meijer wrote: On Apr 1, 2005, at 3:09 PM, linux-os wrote: [PATCH snipped] Cruel joke. Now 80 percent of the Intel clones won't boot. Those are the ones that run industry, you know, the stuff that is necessary to earn money. Without i386 support, you don't have any embedded systems. You need to use the garbage Motorola CPUs and the proprietary operating systems in embedded stuff. Have you checked your calender yet? I'm quite aware of the date and time, thank you. The 'i386 architecture is the Intel-like stuff that doesn't have all the newer gee-whiz things that are of little value in the embedded area. ... So, basically, you guys think you can single-handedly remove Linux from the embedded market and re-do it just for servers? Or are you going to leave some capability for desk-tops, too? Please check the calendar again. Don't worry about the year part, concentrate on the month and day... ;) -- Dmitry Ahhh! . APRIL Fool-I-am-one Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] : remove unreliable, unused and unmainained arch from kernel.
On Fri, 1 Apr 2005, [iso-8859-1] Måns Rullgård wrote: linux-os <[EMAIL PROTECTED]> writes: [PATCH snipped] Cruel joke. Now 80 percent of the Intel clones won't boot. Those are the ones that run industry, you know, the stuff that is necessary to earn money. For now, yes. Hopefully it will change some day. Without i386 support, you don't have any embedded systems. You need to use the garbage Motorola CPUs and the proprietary operating systems in embedded stuff. In front me at the moment are two embedded devices, one PPC based, the other MIPS, both running Linux. You can't be serious. Software doesn't get the opportunity to select the hardware. With Linux on PC-like machines, we have been able to write and debug 90 or more percent of the software on our work-stations before embedding it in the target machines. You get rid of that capability just because you don't __like__ i386??? Did you ever have a job? Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction.
Re: [RFC] : remove unreliable, unused and unmainained arch from kernel.
On Fri, 1 Apr 2005, Renate Meijer wrote: On Apr 1, 2005, at 3:09 PM, linux-os wrote: [PATCH snipped] Cruel joke. Now 80 percent of the Intel clones won't boot. Those are the ones that run industry, you know, the stuff that is necessary to earn money. Without i386 support, you don't have any embedded systems. You need to use the garbage Motorola CPUs and the proprietary operating systems in embedded stuff. Have you checked your calender yet? Besides... Never heard of ARM? Atmel has a complete line of those, which seem very usefull. I'm quite aware of the date and time, thank you. The 'i386 architecture is the Intel-like stuff that doesn't have all the newer gee-whiz things that are of little value in the embedded area. And, ARM is an exploded-cost over-hyped RISC device with poor I/O capability that assumes that the world is interfaced in 32-bit chunks. It also can't take advantage of the cost economies that you get from the devices used in the PC mass-market like memory-controllers, PCI-IO bridges and etc. Although these are used in the new "high-definition" TVs I can assure you that there are many more PC components being manufactured now than high-definition TV sets. Eventually, the ARM, or something that supersedes it might make sense. Right not, forget it. So, basically, you guys think you can single-handedly remove Linux from the embedded market and re-do it just for servers? Or are you going to leave some capability for desk-tops, too? Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] : remove unreliable, unused and unmainained arch from kernel.
On Fri, 1 Apr 2005, Renate Meijer wrote: On Apr 1, 2005, at 3:09 PM, linux-os wrote: [PATCH snipped] Cruel joke. Now 80 percent of the Intel clones won't boot. Those are the ones that run industry, you know, the stuff that is necessary to earn money. Without i386 support, you don't have any embedded systems. You need to use the garbage Motorola CPUs and the proprietary operating systems in embedded stuff. Have you checked your calender yet? Besides... Never heard of ARM? Atmel has a complete line of those, which seem very usefull. I'm quite aware of the date and time, thank you. The 'i386 architecture is the Intel-like stuff that doesn't have all the newer gee-whiz things that are of little value in the embedded area. And, ARM is an exploded-cost over-hyped RISC device with poor I/O capability that assumes that the world is interfaced in 32-bit chunks. It also can't take advantage of the cost economies that you get from the devices used in the PC mass-market like memory-controllers, PCI-IO bridges and etc. Although these are used in the new high-definition TVs I can assure you that there are many more PC components being manufactured now than high-definition TV sets. Eventually, the ARM, or something that supersedes it might make sense. Right not, forget it. So, basically, you guys think you can single-handedly remove Linux from the embedded market and re-do it just for servers? Or are you going to leave some capability for desk-tops, too? Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] : remove unreliable, unused and unmainained arch from kernel.
On Fri, 1 Apr 2005, [iso-8859-1] Måns Rullgård wrote: linux-os [EMAIL PROTECTED] writes: [PATCH snipped] Cruel joke. Now 80 percent of the Intel clones won't boot. Those are the ones that run industry, you know, the stuff that is necessary to earn money. For now, yes. Hopefully it will change some day. Without i386 support, you don't have any embedded systems. You need to use the garbage Motorola CPUs and the proprietary operating systems in embedded stuff. In front me at the moment are two embedded devices, one PPC based, the other MIPS, both running Linux. You can't be serious. Software doesn't get the opportunity to select the hardware. With Linux on PC-like machines, we have been able to write and debug 90 or more percent of the software on our work-stations before embedding it in the target machines. You get rid of that capability just because you don't __like__ i386??? Did you ever have a job? Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction.
Re: [RFC] : remove unreliable, unused and unmainained arch from kernel.
On Fri, 1 Apr 2005, Dmitry Torokhov wrote: On Apr 1, 2005 10:16 AM, Richard B. Johnson [EMAIL PROTECTED] wrote: On Fri, 1 Apr 2005, Renate Meijer wrote: On Apr 1, 2005, at 3:09 PM, linux-os wrote: [PATCH snipped] Cruel joke. Now 80 percent of the Intel clones won't boot. Those are the ones that run industry, you know, the stuff that is necessary to earn money. Without i386 support, you don't have any embedded systems. You need to use the garbage Motorola CPUs and the proprietary operating systems in embedded stuff. Have you checked your calender yet? I'm quite aware of the date and time, thank you. The 'i386 architecture is the Intel-like stuff that doesn't have all the newer gee-whiz things that are of little value in the embedded area. ... So, basically, you guys think you can single-handedly remove Linux from the embedded market and re-do it just for servers? Or are you going to leave some capability for desk-tops, too? Please check the calendar again. Don't worry about the year part, concentrate on the month and day... ;) -- Dmitry Ahhh! . APRIL Fool-I-am-one Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Low file-system performance for 2.6.11 compared to 2.4.26
On Thu, 31 Mar 2005, Nick Piggin wrote: linux-os wrote: For those interested, some file-system tests and a test-tools are attached. I'll give it a run when I get a chance. Thanks. In the meantime, can you try with different io schedulers? I was trying to emulate some old servers that had new kernels installed. These servers are used to send medical images around. One used to get a 512x512x16-bit image to a work-station in a few hundred milliseconds. It takes seconds with the newer kernels. I found out that the SCSI disk(s) were running continuously and sampled their I/O patterns. The 'C' code comes very close to emulating that. The installation involved an ugrade to linux-2.6.5-1.358 that came with a RedHat Fedora distibution. The provided code will even HALT that distibution. Everything goes into the 'D' state and waits forever (at least overnight). Later versions like linux-2.6.8 will run to completion but with verrry slow through-put. Never versions, like linux-2.6.11 will run, but with a strange slowness, everything in 'D' and the file-system can end up with missing files. The SCSI controller is AIC7XXX, and the fs is ext3 with jbd, just as it comes from Red Hat. Also, my .signature disappeared during the file-system tests. There were no errors and e2fsck thinks everything is fine! You seem to be constantly plagued by gremlins. I don't know whether to laugh or cry. I test many, many (too many) systems as part of my job. When somebody writes a hardware device-driver and I get to check it, sometimes it blows up or doesn't otherwise work. I then test the bare kernel(s) and I often find some really strange things going on. For instance, there was a recent change that make the BKL be held during an ioctl(). This has devistating performance consequences with a lot of drivers. For instance, the stuff that writes CD/ROMs. It does a lot of the work using ioctl(), the firewire drivers also use ioctl() for I/O. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
