Re: Q: "kapm-idled" and CPU usage
[EMAIL PROTECTED] (Jeff Garzik) writes: > Is there some way to hack the scheduler statistics so that idle > processes are special cases, which do not accumulate CPU time nor > contribute to the load average? I wondered about getting kapm-idled to take the CPU time allocated to itself, and reallocate to the idle task. Something like the following at a strategic point inside the apm loop. unsigned long user, system; user = current->times.tms_utime; system = current->times.tms_stime; current->times.tms_utime = current->times.tms_stime = 0; idle->times.tms_utime += user; idle->times.tms_stime += system; I haven't looked to see what point would be a good idea, and investigated what locks need to be held. I've also just peeked at the 2.4 code, and seen "current->per_cpu_utime[cpu]" -- does this need handling? Is it visible to user space? If you looked closely, you might see the CPU time falling for kapm-idled, but generally you would see it allocated to the idle task, and not kapm-idled. > I agree that it's not pretty to special case idle function process(es), > but those idle functions in turn are causing an incorrect picture of the > system state to be presented to userland. At least with this scheme, the special casing is inside the kapm specific code, and not within the general timer handling. Of course, this is no more than an idea. I haven't got as far as running 2.4 on my only APM machine (486 Thinkpad), let alone trying out this scheme. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Q: kapm-idled and CPU usage
[EMAIL PROTECTED] (Jeff Garzik) writes: Is there some way to hack the scheduler statistics so that idle processes are special cases, which do not accumulate CPU time nor contribute to the load average? I wondered about getting kapm-idled to take the CPU time allocated to itself, and reallocate to the idle task. Something like the following at a strategic point inside the apm loop. unsigned long user, system; user = current-times.tms_utime; system = current-times.tms_stime; current-times.tms_utime = current-times.tms_stime = 0; idle-times.tms_utime += user; idle-times.tms_stime += system; I haven't looked to see what point would be a good idea, and investigated what locks need to be held. I've also just peeked at the 2.4 code, and seen "current-per_cpu_utime[cpu]" -- does this need handling? Is it visible to user space? If you looked closely, you might see the CPU time falling for kapm-idled, but generally you would see it allocated to the idle task, and not kapm-idled. I agree that it's not pretty to special case idle function process(es), but those idle functions in turn are causing an incorrect picture of the system state to be presented to userland. At least with this scheme, the special casing is inside the kapm specific code, and not within the general timer handling. Of course, this is no more than an idea. I haven't got as far as running 2.4 on my only APM machine (486 Thinkpad), let alone trying out this scheme. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Improved version reporting
[EMAIL PROTECTED] writes:
> From: Riley Williams <[EMAIL PROTECTED]>
> {Shrug} Please explain why I was unable to get ver_linux to report a
>
> % ./loadkeys -h 2>&1 | head -1
> loadkeys version 1.06
>
> Maybe nothing has changed here the past eight years. It just works.
> Perhaps you tried some modified version.
Debian 2.2 has loadkeys from a console-tools package, which can be found
at http://lct.sourceforge.net/
$ loadkeys --version
loadkeys: (console-tools) 0.2.3
--
`O O' | [EMAIL PROTECTED]
// ^ \\ | http://www.pyrites.org.uk/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Improved version reporting
[EMAIL PROTECTED] writes:
From: Riley Williams [EMAIL PROTECTED]
{Shrug} Please explain why I was unable to get ver_linux to report a
% ./loadkeys -h 21 | head -1
loadkeys version 1.06
Maybe nothing has changed here the past eight years. It just works.
Perhaps you tried some modified version.
Debian 2.2 has loadkeys from a console-tools package, which can be found
at http://lct.sourceforge.net/
$ loadkeys --version
loadkeys: (console-tools) 0.2.3
--
`O O' | [EMAIL PROTECTED]
// ^ \\ | http://www.pyrites.org.uk/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.2.18: Remove bogus "Wrong buffer length" warnings from aha1542
I've just installed an AHA1542 SCSI card, and when performing a backup,
I'm finding the kernel is spewing out the following message:
Wrong buffer length supplied for request sense (256)
This is because the sense_buffer is 16 bytes, but the buffer supplied
is 256 bytes.
Looking at the 2.4 version of the driver, I see that this message has
been disabled, because scsi_request_sense() provides a buffer of size 256.
The following is a version of the 2.4 patch applied to 2.2. Please apply.
I did notice that aha1740.c also has the same bogus check on the buffer,
but I haven't provided a patch, as this is still present in 2.4, and a
patch for that should also be included.
--- linux-2.2/drivers/scsi/aha1542.c~ Wed Feb 21 10:13:02 2001
+++ linux-2.2/drivers/scsi/aha1542.cWed Feb 21 10:15:51 2001
@@ -560,7 +560,9 @@
done(SCpnt); return 0;});
if(*cmd == REQUEST_SENSE){
-#ifndef DEBUG
+#if 0
+ /* scsi_request_sense() provides a buffer of size 256,
+ so there is no reason to expect equality */
if (bufflen != sizeof(SCpnt->sense_buffer)) {
printk("Wrong buffer length supplied for request sense (%d)\n",bufflen);
};
--
`O O' | [EMAIL PROTECTED]
// ^ \\ | http://www.pyrites.org.uk/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.2.18: Remove bogus Wrong buffer length warnings from aha1542
I've just installed an AHA1542 SCSI card, and when performing a backup,
I'm finding the kernel is spewing out the following message:
Wrong buffer length supplied for request sense (256)
This is because the sense_buffer is 16 bytes, but the buffer supplied
is 256 bytes.
Looking at the 2.4 version of the driver, I see that this message has
been disabled, because scsi_request_sense() provides a buffer of size 256.
The following is a version of the 2.4 patch applied to 2.2. Please apply.
I did notice that aha1740.c also has the same bogus check on the buffer,
but I haven't provided a patch, as this is still present in 2.4, and a
patch for that should also be included.
--- linux-2.2/drivers/scsi/aha1542.c~ Wed Feb 21 10:13:02 2001
+++ linux-2.2/drivers/scsi/aha1542.cWed Feb 21 10:15:51 2001
@@ -560,7 +560,9 @@
done(SCpnt); return 0;});
if(*cmd == REQUEST_SENSE){
-#ifndef DEBUG
+#if 0
+ /* scsi_request_sense() provides a buffer of size 256,
+ so there is no reason to expect equality */
if (bufflen != sizeof(SCpnt-sense_buffer)) {
printk("Wrong buffer length supplied for request sense (%d)\n",bufflen);
};
--
`O O' | [EMAIL PROTECTED]
// ^ \\ | http://www.pyrites.org.uk/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Newbie ask for help: cramfs port to isofs
[EMAIL PROTECTED] (Andrzej Krzysztofowicz) writes: > "zhaoway wrote:" > > - int len; > > - int map; > > + int len = 0; > > This will be the most probably rejected. > Zero initializers are intentionally removed from the code to decrease > the kernel image size. A little knowledge is a dangerous thing. The zero initializers can be removed from _static_ variables (those not within function scope), where the initialization to zero is guarenteed. In the case above, the variable being initialized is an automatic variable (allocated on the stack), and so needs to be initialized. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Newbie ask for help: cramfs port to isofs
[EMAIL PROTECTED] (Andrzej Krzysztofowicz) writes: "zhaoway wrote:" - int len; - int map; + int len = 0; This will be the most probably rejected. Zero initializers are intentionally removed from the code to decrease the kernel image size. A little knowledge is a dangerous thing. The zero initializers can be removed from _static_ variables (those not within function scope), where the initialization to zero is guarenteed. In the case above, the variable being initialized is an automatic variable (allocated on the stack), and so needs to be initialized. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Change of policy for future 2.2 driver submissions
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: > Either I'm blind, or especially dense today, or both (quite possible :-) but I > don't see any reference in patch-kernel to the extra version information. > EXTRAVERSION is defined in the kernel Makefile, and I tried using the script > found in the 2.4.0-test1 source like this: > > patch-kernel /usr/src/linux /pub/linux/kernel/v2.4/test-kernels > > but the test-2 and following patches are not applied. All I get is "Current > kernel version is 2.4.0." What am I missing? The distributed version of patch-kernel has only ever known about the "standard" progression x.y.z => x.y.z+1. This all gets horribly broken when Linus gets imaginative with his kernel numbering. I have said before that I thought this was OK, because the people that need to cope with the EXTRAVERSION guff are people on the development branch, and should be able to patch the kernel themselves. The main users of patch-kernel are less experienced people. However, this does conflict with the aim of getting users into testing kernels late in the development branch cycle. It also affects people like me who are lazy. I don't think that getting the kernel version to support the naming scheme du-jour will work, as this would require Linus to update patch-kernel when he dreams up a new scheme -- and Linus is the one person I'm fairly sure does not use it! For myself, I have a version of patch-kernel that does know how to deal with the wacky naming versions (because I'm lazy). In future I'll make this available to anyone that wants to download it for their own use, but I won't push to get it included. A (temporary) location for the current version is: http://www.alfie.demon.co.uk/download/patch-kernel -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Change of policy for future 2.2 driver submissions
In [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Either I'm blind, or especially dense today, or both (quite possible :-) but I don't see any reference in patch-kernel to the extra version information. EXTRAVERSION is defined in the kernel Makefile, and I tried using the script found in the 2.4.0-test1 source like this: patch-kernel /usr/src/linux /pub/linux/kernel/v2.4/test-kernels but the test-2 and following patches are not applied. All I get is "Current kernel version is 2.4.0." What am I missing? The distributed version of patch-kernel has only ever known about the "standard" progression x.y.z = x.y.z+1. This all gets horribly broken when Linus gets imaginative with his kernel numbering. I have said before that I thought this was OK, because the people that need to cope with the EXTRAVERSION guff are people on the development branch, and should be able to patch the kernel themselves. The main users of patch-kernel are less experienced people. However, this does conflict with the aim of getting users into testing kernels late in the development branch cycle. It also affects people like me who are lazy. I don't think that getting the kernel version to support the naming scheme du-jour will work, as this would require Linus to update patch-kernel when he dreams up a new scheme -- and Linus is the one person I'm fairly sure does not use it! For myself, I have a version of patch-kernel that does know how to deal with the wacky naming versions (because I'm lazy). In future I'll make this available to anyone that wants to download it for their own use, but I won't push to get it included. A (temporary) location for the current version is: http://www.alfie.demon.co.uk/download/patch-kernel -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] generic_serial's block_til_ready
[EMAIL PROTECTED] (Patrick van de Lageweg) writes: > This patch renames the block_til_ready of generic serial to > gs_block_til_ready. > > it helps when other modules have a "static block_til_ready" defined when > used older modutils. Do you mean older than the version specified as being required in Documention/CHANGES? If so, then I'm not surprised the patch has not been applied (how many times have you sent it?). -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] generic_serial's block_til_ready
[EMAIL PROTECTED] (Patrick van de Lageweg) writes: This patch renames the block_til_ready of generic serial to gs_block_til_ready. it helps when other modules have a "static block_til_ready" defined when used older modutils. Do you mean older than the version specified as being required in Documention/CHANGES? If so, then I'm not surprised the patch has not been applied (how many times have you sent it?). -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kapm-idled : is this a bug?
[EMAIL PROTECTED] (Rik van Riel) writes: > On Mon, 11 Dec 2000 [EMAIL PROTECTED] wrote: > [snip whine] > > > I've consistently re-produced this on my Dell Latitude CS laptop. I'm > > wondering if this will reduce battery life since the CPU is constantly > > being loaded instead of properly idled. > > What do you suppose the 'idled' in 'kapm-idled' stands for? We know it was an attempt to stop people complaining about the fact that "kapm" was hogging the CPU. Looks like it doesn't work. At the time, I had a look at the kernel source, and came to the conclusion that there was no easy way for the cpu accounting in "do_process_times()" to automatically assign ticks from a particular process to the idle process. However, would it be possible for apm_cpu_idle() to periodically assign the values for per_cpu_*time for the kernel thread to the idle process? This isn't a performance critical part of the kernel, and would lead to less false reports (as above). -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Small tidyup patch to drivers/net/Space.c
A tidyup patch I've been meaning to do for a while. Following the move
of dev->name from char* to char[], the need for padding of the strings
when initialising dev->name is no longer required.
Patch is against 2.4.0-test10. The patch is only required to remove a
potential source of confusion from the source.
--- linux-2.4/drivers/net/Space.c~ Thu Nov 16 08:49:43 2000
+++ linux-2.4/drivers/net/Space.c Thu Nov 16 09:41:17 2000
@@ -459,14 +459,6 @@
#endif
-/* Pad device name to IFNAMSIZ=16. F.e. __PAD6 is string of 9 zeros. */
-#define __PAD6 "\0\0\0\0\0\0\0\0\0"
-#define __PAD5 __PAD6 "\0"
-#define __PAD4 __PAD5 "\0"
-#define __PAD3 __PAD4 "\0"
-#define __PAD2 __PAD3 "\0"
-
-
#ifdef CONFIG_NET_FC
static int fcif_probe(struct net_device *dev)
{
@@ -486,14 +478,14 @@
#ifdef CONFIG_ETHERTAP
-static struct net_device tap0_dev = { "tap0" __PAD4, 0, 0, 0, 0, NETLINK_TAPBASE,
0, 0, 0, 0, NEXT_DEV, ethertap_probe, };
+static struct net_device tap0_dev = { "tap0", 0, 0, 0, 0, NETLINK_TAPBASE, 0, 0,
+0, 0, NEXT_DEV, ethertap_probe, };
# undef NEXT_DEV
# define NEXT_DEV(_dev)
#endif
#ifdef CONFIG_SDLA
extern int sdla_init(struct net_device *);
-static struct net_device sdla0_dev = { "sdla0" __PAD5, 0, 0, 0, 0, 0, 0, 0, 0, 0,
NEXT_DEV, sdla_init, };
+static struct net_device sdla0_dev = { "sdla0", 0, 0, 0, 0, 0, 0, 0, 0, 0,
+NEXT_DEV, sdla_init, };
# undef NEXT_DEV
# define NEXT_DEV(_dev)
@@ -502,7 +494,7 @@
#if defined(CONFIG_LTPC)
extern int ltpc_probe(struct net_device *);
static struct net_device dev_ltpc = {
-"lt0" __PAD3,
+"lt0",
0, 0, 0, 0,
0x0, 0,
0, 0, 0, NEXT_DEV, ltpc_probe };
@@ -512,9 +504,9 @@
#if defined(CONFIG_COPS)
extern int cops_probe(struct net_device *);
-static struct net_device cops2_dev = { "lt2" __PAD3, 0, 0, 0, 0, 0x0, 0, 0, 0, 0,
NEXT_DEV, cops_probe };
-static struct net_device cops1_dev = { "lt1" __PAD3, 0, 0, 0, 0, 0x0, 0, 0, 0, 0,
_dev, cops_probe };
-static struct net_device cops0_dev = { "lt0" __PAD3, 0, 0, 0, 0, 0x0, 0, 0, 0, 0,
_dev, cops_probe };
+static struct net_device cops2_dev = { "lt2", 0, 0, 0, 0, 0x0, 0, 0, 0, 0,
+NEXT_DEV, cops_probe };
+static struct net_device cops1_dev = { "lt1", 0, 0, 0, 0, 0x0, 0, 0, 0, 0,
+_dev, cops_probe };
+static struct net_device cops0_dev = { "lt0", 0, 0, 0, 0, 0x0, 0, 0, 0, 0,
+_dev, cops_probe };
# undef NEXT_DEV
# define NEXT_DEV (_dev)
#endif /* COPS */
@@ -535,22 +527,22 @@
#define ETH_NOPROBE_ADDR 0xffe0
static struct net_device eth7_dev = {
-"eth%d" __PAD5, 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, NEXT_DEV,
ethif_probe };
+"eth%d", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, NEXT_DEV, ethif_probe };
static struct net_device eth6_dev = {
-"eth%d" __PAD5, 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev,
ethif_probe };
+"eth%d", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev, ethif_probe
+};
static struct net_device eth5_dev = {
-"eth%d" __PAD5, 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev,
ethif_probe };
+"eth%d", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev, ethif_probe
+};
static struct net_device eth4_dev = {
-"eth%d" __PAD5, 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev,
ethif_probe };
+"eth%d", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev, ethif_probe
+};
static struct net_device eth3_dev = {
-"eth%d" __PAD5, 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev,
ethif_probe };
+"eth%d", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev, ethif_probe
+};
static struct net_device eth2_dev = {
-"eth%d" __PAD5, 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev,
ethif_probe };
+"eth%d", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev, ethif_probe
+};
static struct net_device eth1_dev = {
-"eth%d" __PAD5, 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev,
ethif_probe };
+"eth%d", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev, ethif_probe
+};
static struct net_device eth0_dev = {
-"eth%d" __PAD5, 0, 0, 0, 0, ETH0_ADDR, ETH0_IRQ, 0, 0, 0, _dev, ethif_probe
};
+"eth%d", 0, 0, 0, 0, ETH0_ADDR, ETH0_IRQ, 0, 0, 0, _dev, ethif_probe };
# undef NEXT_DEV
# define NEXT_DEV(_dev)
@@ -582,21 +574,21 @@
return 0;
}
static struct net_device tr7_dev = {
-"tr%d" __PAD3,0,0,0,0,0,0,0,0,0, NEXT_DEV, trif_probe };
+"tr%d",0,0,0,0,0,0,0,0,0, NEXT_DEV, trif_probe };
static struct net_device tr6_dev = {
-"tr%d" __PAD3,0,0,0,0,0,0,0,0,0, _dev, trif_probe };
+"tr%d",0,0,0,0,0,0,0,0,0, _dev, trif_probe };
static struct net_device tr5_dev = {
-"tr%d" __PAD3,0,0,0,0,0,0,0,0,0, _dev, trif_probe };
+"tr%d",0,0,0,0,0,0,0,0,0, _dev, trif_probe };
static struct net_device tr4_dev = {
-"tr%d" __PAD3,0,0,0,0,0,0,0,0,0, _dev, trif_probe };
+
Re: [PATCH] Re: test11-pre5
[EMAIL PROTECTED] (Dan Aloni) writes: > Is there a special reason why dev->name is not a pointer? One of the changes in 2.3 was to change dev->name from a pointer to the char array. A little bit painful (in terms of the number of changes, rather than the complexity). The reason for this is that dev->name needs to be writeable, each instance of dev->name must not be shared, and there needs to be at least IFNAMSIZ bytes allocated. The problem that first triggered the change was that gcc was sharing all instances of "eth%d", so there was a problem with multiple adaptors referenced from the same source file. It just happens that the kernel does not implement read-only strings (as userspace does), but it could do in the future. This would cause problem if dev->name is a pointer. Finally, looking through the many net drivers, many failed to reserve IFNAMSIZ (currently 16) bytes. Some allocated 8, some 9, some 17. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: test11-pre5
[EMAIL PROTECTED] (Dan Aloni) writes: Is there a special reason why dev-name is not a pointer? One of the changes in 2.3 was to change dev-name from a pointer to the char array. A little bit painful (in terms of the number of changes, rather than the complexity). The reason for this is that dev-name needs to be writeable, each instance of dev-name must not be shared, and there needs to be at least IFNAMSIZ bytes allocated. The problem that first triggered the change was that gcc was sharing all instances of "eth%d", so there was a problem with multiple adaptors referenced from the same source file. It just happens that the kernel does not implement read-only strings (as userspace does), but it could do in the future. This would cause problem if dev-name is a pointer. Finally, looking through the many net drivers, many failed to reserve IFNAMSIZ (currently 16) bytes. Some allocated 8, some 9, some 17. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Small tidyup patch to drivers/net/Space.c
A tidyup patch I've been meaning to do for a while. Following the move
of dev-name from char* to char[], the need for padding of the strings
when initialising dev-name is no longer required.
Patch is against 2.4.0-test10. The patch is only required to remove a
potential source of confusion from the source.
--- linux-2.4/drivers/net/Space.c~ Thu Nov 16 08:49:43 2000
+++ linux-2.4/drivers/net/Space.c Thu Nov 16 09:41:17 2000
@@ -459,14 +459,6 @@
#endif
-/* Pad device name to IFNAMSIZ=16. F.e. __PAD6 is string of 9 zeros. */
-#define __PAD6 "\0\0\0\0\0\0\0\0\0"
-#define __PAD5 __PAD6 "\0"
-#define __PAD4 __PAD5 "\0"
-#define __PAD3 __PAD4 "\0"
-#define __PAD2 __PAD3 "\0"
-
-
#ifdef CONFIG_NET_FC
static int fcif_probe(struct net_device *dev)
{
@@ -486,14 +478,14 @@
#ifdef CONFIG_ETHERTAP
-static struct net_device tap0_dev = { "tap0" __PAD4, 0, 0, 0, 0, NETLINK_TAPBASE,
0, 0, 0, 0, NEXT_DEV, ethertap_probe, };
+static struct net_device tap0_dev = { "tap0", 0, 0, 0, 0, NETLINK_TAPBASE, 0, 0,
+0, 0, NEXT_DEV, ethertap_probe, };
# undef NEXT_DEV
# define NEXT_DEV(tap0_dev)
#endif
#ifdef CONFIG_SDLA
extern int sdla_init(struct net_device *);
-static struct net_device sdla0_dev = { "sdla0" __PAD5, 0, 0, 0, 0, 0, 0, 0, 0, 0,
NEXT_DEV, sdla_init, };
+static struct net_device sdla0_dev = { "sdla0", 0, 0, 0, 0, 0, 0, 0, 0, 0,
+NEXT_DEV, sdla_init, };
# undef NEXT_DEV
# define NEXT_DEV(sdla0_dev)
@@ -502,7 +494,7 @@
#if defined(CONFIG_LTPC)
extern int ltpc_probe(struct net_device *);
static struct net_device dev_ltpc = {
-"lt0" __PAD3,
+"lt0",
0, 0, 0, 0,
0x0, 0,
0, 0, 0, NEXT_DEV, ltpc_probe };
@@ -512,9 +504,9 @@
#if defined(CONFIG_COPS)
extern int cops_probe(struct net_device *);
-static struct net_device cops2_dev = { "lt2" __PAD3, 0, 0, 0, 0, 0x0, 0, 0, 0, 0,
NEXT_DEV, cops_probe };
-static struct net_device cops1_dev = { "lt1" __PAD3, 0, 0, 0, 0, 0x0, 0, 0, 0, 0,
cops2_dev, cops_probe };
-static struct net_device cops0_dev = { "lt0" __PAD3, 0, 0, 0, 0, 0x0, 0, 0, 0, 0,
cops1_dev, cops_probe };
+static struct net_device cops2_dev = { "lt2", 0, 0, 0, 0, 0x0, 0, 0, 0, 0,
+NEXT_DEV, cops_probe };
+static struct net_device cops1_dev = { "lt1", 0, 0, 0, 0, 0x0, 0, 0, 0, 0,
+cops2_dev, cops_probe };
+static struct net_device cops0_dev = { "lt0", 0, 0, 0, 0, 0x0, 0, 0, 0, 0,
+cops1_dev, cops_probe };
# undef NEXT_DEV
# define NEXT_DEV (cops0_dev)
#endif /* COPS */
@@ -535,22 +527,22 @@
#define ETH_NOPROBE_ADDR 0xffe0
static struct net_device eth7_dev = {
-"eth%d" __PAD5, 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, NEXT_DEV,
ethif_probe };
+"eth%d", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, NEXT_DEV, ethif_probe };
static struct net_device eth6_dev = {
-"eth%d" __PAD5, 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth7_dev,
ethif_probe };
+"eth%d", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth7_dev, ethif_probe
+};
static struct net_device eth5_dev = {
-"eth%d" __PAD5, 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth6_dev,
ethif_probe };
+"eth%d", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth6_dev, ethif_probe
+};
static struct net_device eth4_dev = {
-"eth%d" __PAD5, 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth5_dev,
ethif_probe };
+"eth%d", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth5_dev, ethif_probe
+};
static struct net_device eth3_dev = {
-"eth%d" __PAD5, 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth4_dev,
ethif_probe };
+"eth%d", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth4_dev, ethif_probe
+};
static struct net_device eth2_dev = {
-"eth%d" __PAD5, 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth3_dev,
ethif_probe };
+"eth%d", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth3_dev, ethif_probe
+};
static struct net_device eth1_dev = {
-"eth%d" __PAD5, 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth2_dev,
ethif_probe };
+"eth%d", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth2_dev, ethif_probe
+};
static struct net_device eth0_dev = {
-"eth%d" __PAD5, 0, 0, 0, 0, ETH0_ADDR, ETH0_IRQ, 0, 0, 0, eth1_dev, ethif_probe
};
+"eth%d", 0, 0, 0, 0, ETH0_ADDR, ETH0_IRQ, 0, 0, 0, eth1_dev, ethif_probe };
# undef NEXT_DEV
# define NEXT_DEV(eth0_dev)
@@ -582,21 +574,21 @@
return 0;
}
static struct net_device tr7_dev = {
-"tr%d" __PAD3,0,0,0,0,0,0,0,0,0, NEXT_DEV, trif_probe };
+"tr%d",0,0,0,0,0,0,0,0,0, NEXT_DEV, trif_probe };
static struct net_device tr6_dev = {
-"tr%d" __PAD3,0,0,0,0,0,0,0,0,0, tr7_dev, trif_probe };
+"tr%d",0,0,0,0,0,0,0,0,0, tr7_dev, trif_probe };
static struct net_device tr5_dev = {
-"tr%d" __PAD3,0,0,0,0,0,0,0,0,0, tr6_dev, trif_probe };
+"tr%d",0,0,0,0,0,0,0,0,0, tr6_dev, trif_probe };
Re: Modprobe local root exploit
[EMAIL PROTECTED] (Torsten Duwe) writes: > Chris Evans <[EMAIL PROTECTED]> writes: > > What's wrong with isalnum() ? > > Hm, must admit that I wasn't 100% sure if that's in the kernel lib or an evil > gcc expands it inline to some static array lookup. Now I see that it's > already in the kernel. Do some of you also sometimes wonder why the kernel is > so big ;-) ? Someone could make it a bit smaller by patching fs/jffs/interp.c and arch/ppc/xmon/xmon.c to use the kernel lib, rather than their own versions. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modprobe local root exploit
[EMAIL PROTECTED] (Torsten Duwe) writes: Chris Evans [EMAIL PROTECTED] writes: What's wrong with isalnum() ? Hm, must admit that I wasn't 100% sure if that's in the kernel lib or an evil gcc expands it inline to some static array lookup. Now I see that it's already in the kernel. Do some of you also sometimes wonder why the kernel is so big ;-) ? Someone could make it a bit smaller by patching fs/jffs/interp.c and arch/ppc/xmon/xmon.c to use the kernel lib, rather than their own versions. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: vesafb doesn't work in 240t10?
[EMAIL PROTECTED] (Jeff Garzik) writes: > vga takes a decimal number, but the number in vesafb.txt is > hexidecimal. You can specify the value to lilo as a hexidecimal number: "vga=0x317". -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: vesafb doesn't work in 240t10?
[EMAIL PROTECTED] (Jeff Garzik) writes: vga takes a decimal number, but the number in vesafb.txt is hexidecimal. You can specify the value to lilo as a hexidecimal number: "vga=0x317". -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Attempting to mount Zip causes floppy access (2.2.16)
On Sat, Sep 16, 2000 at 10:23:13PM +0200, Andries Brouwer wrote: > On Sat, Sep 16, 2000 at 11:35:24AM +0100, Nick Holloway wrote: > > There are two questions. Firstly, why did the mount process get stuck > > in the kernel, and secondly (and more importantly) what was it doing > > accessing "/dev/fd0"? > > Does that follow? Maybe the floppy I/O error occurred at some other > time, or for some other reason. Can you reproduce access of device 02:00 > using mount /dev/sda4? The floppy I/O error occurred 13 seconds after the partition table was printed (I'd removed the timestamps to make the messages easier to read), and the machine wasn't doing anything else -- that is why I believe the floppy access was triggered by attempting to mount the zip. However, I have just tried to reproduce it, and I just get the hang in wait_on_buffer, and not the floppy access. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Attempting to mount Zip causes floppy access (2.2.16)
On Sat, Sep 16, 2000 at 10:23:13PM +0200, Andries Brouwer wrote: On Sat, Sep 16, 2000 at 11:35:24AM +0100, Nick Holloway wrote: There are two questions. Firstly, why did the mount process get stuck in the kernel, and secondly (and more importantly) what was it doing accessing "/dev/fd0"? Does that follow? Maybe the floppy I/O error occurred at some other time, or for some other reason. Can you reproduce access of device 02:00 using mount /dev/sda4? The floppy I/O error occurred 13 seconds after the partition table was printed (I'd removed the timestamps to make the messages easier to read), and the machine wasn't doing anything else -- that is why I believe the floppy access was triggered by attempting to mount the zip. However, I have just tried to reproduce it, and I just get the hang in wait_on_buffer, and not the floppy access. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Attempting to mount Zip causes floppy access (2.2.16)
I have a zip disk which I attempted to mount using the following fstab entry: /dev/sda4 /zip vfat noauto,nodev,nosuid,user This caused a spew of "bread failed" errors, and the mount process ended up blocked in "wait_on_buffer". I thought at first that Zip disk had gone to silicon heaven. After rebooting, I had a look at the kernel messages, and was _amazed_ to see the following: SCSI device sda: hdwr sector= 512 bytes. Sectors= 196608 [96 MB] [0.1 GB] sda: Write Protect is off sda: sda1 sda2 sda3 sda4 floppy0: disk absent or changed during operation end_request: I/O error, dev 02:00 (floppy), sector 1 bread in fat_access failed [...] There are two questions. Firstly, why did the mount process get stuck in the kernel, and secondly (and more importantly) what was it doing accessing "/dev/fd0"? The Zip is a bit suspect, as when I attempted to transfer stuff from a Windows machine, it reported the size as a few Mb, and had to be formatted. I don't know if the media is going bad, but I have just dd'd the contents off without problems. If I try and look at the partition table, "cfdisk" refuses, and "fdisk" complains bitterly. If I try and "dd if=/dev/sda4" then this just hangs, again in "wait_on_buffer". Regardless of bad media and corrupt partition tables, I don't see why the kernel is accessing a completely unrelated device. I'll leave the zip disk as it is, so if needed I can run any tests to try and isolate the problem. Details; Kernel 2.2.16; Debian 2.2; Zip+ 100 accessed through aha152x. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Attempting to mount Zip causes floppy access (2.2.16)
I have a zip disk which I attempted to mount using the following fstab entry: /dev/sda4 /zip vfat noauto,nodev,nosuid,user This caused a spew of "bread failed" errors, and the mount process ended up blocked in "wait_on_buffer". I thought at first that Zip disk had gone to silicon heaven. After rebooting, I had a look at the kernel messages, and was _amazed_ to see the following: SCSI device sda: hdwr sector= 512 bytes. Sectors= 196608 [96 MB] [0.1 GB] sda: Write Protect is off sda: sda1 sda2 sda3 sda4 floppy0: disk absent or changed during operation end_request: I/O error, dev 02:00 (floppy), sector 1 bread in fat_access failed [...] There are two questions. Firstly, why did the mount process get stuck in the kernel, and secondly (and more importantly) what was it doing accessing "/dev/fd0"? The Zip is a bit suspect, as when I attempted to transfer stuff from a Windows machine, it reported the size as a few Mb, and had to be formatted. I don't know if the media is going bad, but I have just dd'd the contents off without problems. If I try and look at the partition table, "cfdisk" refuses, and "fdisk" complains bitterly. If I try and "dd if=/dev/sda4" then this just hangs, again in "wait_on_buffer". Regardless of bad media and corrupt partition tables, I don't see why the kernel is accessing a completely unrelated device. I'll leave the zip disk as it is, so if needed I can run any tests to try and isolate the problem. Details; Kernel 2.2.16; Debian 2.2; Zip+ 100 accessed through aha152x. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
