Re: Clock running at half speed in 2.6.20?
On Fri, 16 Feb 2007 08:24:54 -0800, Daniel Walker wrote: >On Fri, 2007-02-16 at 22:28 +0800, Adam J. Richter wrote: >> My system clock runs at approximately half speed in >> linux-2.6.20, 2.6.20-git10 and 2.6.20-git11. [...] >cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc >cat /sys/devices/system/clocksource/clocksource0/available_clocksource acpi_pm jiffies tsc When I rebooted with "max_cpus=1", available_clocksource included a fourth option "pit". I have some bad news. The problem is sporadic. Here are the logs of the tests that I have made, in the order in which I recall making them: 2.6.20-git11problem occurred 2.6.20-git10problem occurred 2.6.20 problem occurred 2.6.18.1no problem [At this point, I made my original posting.] 2.6.20-git11 maxcpus=1 no problem ...checked current_clocksource, was tsc 2.6.18.1no problem ...checked current_clocksource, was tsc 2.6.20-git11no problem (this is bad!) checked current_clocksource, was tsc set clocksource=acpi_pm, still no problem set clocksource=jiffies, still no problem power cycled computer, unplugging power supply and powered down monitor 2.6.20-git11no problem (this is bad!) checked current_clocksource, was tsc At first, I was very happy to see the problem disappear after rebooting 2.6.20-git11 with "max_cpus=1", as this would tend to indicate some mistake related to hyperthreading, but, after that I have been unable to reproduce the problem, so I really don't know that booting with maxcpus=1 fixed it. Perhaps the previous boot to 2.6.18.1 did. I should also mention, that around the time that I first noticed the problem, I observed audio stuttering under 2.6.20-git11 regularly, in intervals of perhaps 300 milliseconds, which I suspect is a symptom of the slow system clock causing the audio driver not to fill output buffers in time. Now, when I cannot reproduce the clock slowdown problem, audio is playing fine under the same 2.6.20-git11 kernel. I have observed the audio stuttering a few times in the past week or so. The next time it happens, I'll see if the clock slowdown has returned and I'll record and experiment with the other clock sources. I'll let you know when I have more useful information or mske other progress related to this problem. Thank you for your help! Adam Richter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Clock running at half speed in 2.6.20?
My system clock runs at approximately half speed in linux-2.6.20, 2.6.20-git10 and 2.6.20-git11. That is, it takes about two hours for "date" to report that one hour has elapsed. "hwclock" returns the correct time, of course. I do not have this problem in linuux 2.6.18.1. I will try to narrow down the kernel version where this problem began. The motherboard in question is an asus p4v8000-x, running a 2.8GHz Pentium 4 that has two hyperthreads, which I suspect may be the problem. I am just guessing, but perhaps some piece of code thinks the two hyperthreads are separate CPU's receving twice as many clock interrupts total. I expect to try to some experimentation to check this theory. For what it's worth, I am running CONFIG_PREEMPT=y, CONFIG_PREEMPT_BKL=y, CONFIG_HZ=1000. If there is a more specific mailing list for discussing this problem, I would be interested in knowning about it. The MAINTAINERS file lists several components with the word "clock" in them, but I believe that all are for drivers for hardware clocks or high resolution timer extensions. I tried a quick search of the linux-kernel mailing list for "clock" in the subject line, and did not notice anything that seemed like a match to this problem. I will post more information as I collect it, but I am posting this bug report now in case this problem rings a bell for anyone. Adam Richter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch: move struct sysfs_dirent to private header
Hi Greg,
This is a resubmission of a patch that fell through the
cracks long ago. I've posted it a couple of times, and don't recall
anyone objecting to it.
struct sysfs_dirent is private to the fs/sysfs/ subtree. It is
not even referenced as an opaque structure outside of that subtree.
The following patch moves the declaration from
include/linux/sysfs.h to fs/sysfs/sysfs.h, making it clearer
that nothing else in the kernel dereferences it.
I have been running this patch for years. Please integrate
and forward upstream if there are no objections.
Note that while this patch was generated by stgit, it
was not generated from a tree pulled from kernel.org, so perhaps
a git command that thinks that this patch was generated from a
common ancestor might get confused (I'm not sure). You may want
to integrate it by running patch and checking in the change.
The patch is against 2.6.20-git11.
Adam Richter
Move struct sysfs_dirent from incude/linux/sysfs.h to fs/sysfs/sysfs.h
From: <>
---
src/fs/sysfs/sysfs.h | 11 +++
src/include/linux/sysfs.h | 12
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/src/fs/sysfs/sysfs.h b/src/fs/sysfs/sysfs.h
index d976b00..a77c57e 100644
--- a/src/fs/sysfs/sysfs.h
+++ b/src/fs/sysfs/sysfs.h
@@ -1,3 +1,14 @@
+struct sysfs_dirent {
+ atomic_ts_count;
+ struct list_heads_sibling;
+ struct list_heads_children;
+ void* s_element;
+ int s_type;
+ umode_t s_mode;
+ struct dentry * s_dentry;
+ struct iattr* s_iattr;
+ atomic_ts_event;
+};
extern struct vfsmount * sysfs_mount;
extern struct kmem_cache *sysfs_dir_cachep;
diff --git a/src/include/linux/sysfs.h b/src/include/linux/sysfs.h
index 192de3a..567cdca 100644
--- a/src/include/linux/sysfs.h
+++ b/src/include/linux/sysfs.h
@@ -68,18 +68,6 @@ struct sysfs_ops {
ssize_t (*store)(struct kobject *,struct attribute *,const char *,
size_t);
};
-struct sysfs_dirent {
- atomic_ts_count;
- struct list_heads_sibling;
- struct list_heads_children;
- void* s_element;
- int s_type;
- umode_t s_mode;
- struct dentry * s_dentry;
- struct iattr* s_iattr;
- atomic_ts_event;
-};
-
#define SYSFS_ROOT 0x0001
#define SYSFS_DIR 0x0002
#define SYSFS_KOBJ_ATTR0x0004
Patch: move struct sysfs_dirent to private header
Hi Greg,
This is a resubmission of a patch that fell through the
cracks long ago. I've posted it a couple of times, and don't recall
anyone objecting to it.
struct sysfs_dirent is private to the fs/sysfs/ subtree. It is
not even referenced as an opaque structure outside of that subtree.
The following patch moves the declaration from
include/linux/sysfs.h to fs/sysfs/sysfs.h, making it clearer
that nothing else in the kernel dereferences it.
I have been running this patch for years. Please integrate
and forward upstream if there are no objections.
Note that while this patch was generated by stgit, it
was not generated from a tree pulled from kernel.org, so perhaps
a git command that thinks that this patch was generated from a
common ancestor might get confused (I'm not sure). You may want
to integrate it by running patch and checking in the change.
The patch is against 2.6.20-git11.
Adam Richter
Move struct sysfs_dirent from incude/linux/sysfs.h to fs/sysfs/sysfs.h
From:
---
src/fs/sysfs/sysfs.h | 11 +++
src/include/linux/sysfs.h | 12
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/src/fs/sysfs/sysfs.h b/src/fs/sysfs/sysfs.h
index d976b00..a77c57e 100644
--- a/src/fs/sysfs/sysfs.h
+++ b/src/fs/sysfs/sysfs.h
@@ -1,3 +1,14 @@
+struct sysfs_dirent {
+ atomic_ts_count;
+ struct list_heads_sibling;
+ struct list_heads_children;
+ void* s_element;
+ int s_type;
+ umode_t s_mode;
+ struct dentry * s_dentry;
+ struct iattr* s_iattr;
+ atomic_ts_event;
+};
extern struct vfsmount * sysfs_mount;
extern struct kmem_cache *sysfs_dir_cachep;
diff --git a/src/include/linux/sysfs.h b/src/include/linux/sysfs.h
index 192de3a..567cdca 100644
--- a/src/include/linux/sysfs.h
+++ b/src/include/linux/sysfs.h
@@ -68,18 +68,6 @@ struct sysfs_ops {
ssize_t (*store)(struct kobject *,struct attribute *,const char *,
size_t);
};
-struct sysfs_dirent {
- atomic_ts_count;
- struct list_heads_sibling;
- struct list_heads_children;
- void* s_element;
- int s_type;
- umode_t s_mode;
- struct dentry * s_dentry;
- struct iattr* s_iattr;
- atomic_ts_event;
-};
-
#define SYSFS_ROOT 0x0001
#define SYSFS_DIR 0x0002
#define SYSFS_KOBJ_ATTR0x0004
Clock running at half speed in 2.6.20?
My system clock runs at approximately half speed in linux-2.6.20, 2.6.20-git10 and 2.6.20-git11. That is, it takes about two hours for date to report that one hour has elapsed. hwclock returns the correct time, of course. I do not have this problem in linuux 2.6.18.1. I will try to narrow down the kernel version where this problem began. The motherboard in question is an asus p4v8000-x, running a 2.8GHz Pentium 4 that has two hyperthreads, which I suspect may be the problem. I am just guessing, but perhaps some piece of code thinks the two hyperthreads are separate CPU's receving twice as many clock interrupts total. I expect to try to some experimentation to check this theory. For what it's worth, I am running CONFIG_PREEMPT=y, CONFIG_PREEMPT_BKL=y, CONFIG_HZ=1000. If there is a more specific mailing list for discussing this problem, I would be interested in knowning about it. The MAINTAINERS file lists several components with the word clock in them, but I believe that all are for drivers for hardware clocks or high resolution timer extensions. I tried a quick search of the linux-kernel mailing list for clock in the subject line, and did not notice anything that seemed like a match to this problem. I will post more information as I collect it, but I am posting this bug report now in case this problem rings a bell for anyone. Adam Richter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Clock running at half speed in 2.6.20?
On Fri, 16 Feb 2007 08:24:54 -0800, Daniel Walker wrote: On Fri, 2007-02-16 at 22:28 +0800, Adam J. Richter wrote: My system clock runs at approximately half speed in linux-2.6.20, 2.6.20-git10 and 2.6.20-git11. [...] cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc cat /sys/devices/system/clocksource/clocksource0/available_clocksource acpi_pm jiffies tsc When I rebooted with max_cpus=1, available_clocksource included a fourth option pit. I have some bad news. The problem is sporadic. Here are the logs of the tests that I have made, in the order in which I recall making them: 2.6.20-git11problem occurred 2.6.20-git10problem occurred 2.6.20 problem occurred 2.6.18.1no problem [At this point, I made my original posting.] 2.6.20-git11 maxcpus=1 no problem ...checked current_clocksource, was tsc 2.6.18.1no problem ...checked current_clocksource, was tsc 2.6.20-git11no problem (this is bad!) checked current_clocksource, was tsc set clocksource=acpi_pm, still no problem set clocksource=jiffies, still no problem power cycled computer, unplugging power supply and powered down monitor 2.6.20-git11no problem (this is bad!) checked current_clocksource, was tsc At first, I was very happy to see the problem disappear after rebooting 2.6.20-git11 with max_cpus=1, as this would tend to indicate some mistake related to hyperthreading, but, after that I have been unable to reproduce the problem, so I really don't know that booting with maxcpus=1 fixed it. Perhaps the previous boot to 2.6.18.1 did. I should also mention, that around the time that I first noticed the problem, I observed audio stuttering under 2.6.20-git11 regularly, in intervals of perhaps 300 milliseconds, which I suspect is a symptom of the slow system clock causing the audio driver not to fill output buffers in time. Now, when I cannot reproduce the clock slowdown problem, audio is playing fine under the same 2.6.20-git11 kernel. I have observed the audio stuttering a few times in the past week or so. The next time it happens, I'll see if the clock slowdown has returned and I'll record and experiment with the other clock sources. I'll let you know when I have more useful information or mske other progress related to this problem. Thank you for your help! Adam Richter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: hdparm for lib_pata
>>> = Stephen Clark >> = Adam Richter > = Patrick Ale >> Do you know if these drives were advertising less capability >> than they were spec-ed at? Do you recall if the IDE driver without >> kernel arguments printed its rationale for reverting to the slower >> setting? [...] >Then, after 2 hours, and resyncing RAID1 MD 1 devices, I started >seeing things like: >"Drive not ready" >"DMA timeout on ..." I was not asking about Patrick's desktop computer, which was already established to be hardware problem that was fixed by replacing a broken fan. I was asking about Stephen Clark's two laptop computers, which seemed like they might be examples of a need for user level hdparm DMA setting, which is why I prefaced my question with the following quotation: >>On 2007-02-04 Stephen Clark wrote: >>>I have had two different laptops that had to have boot time command line >>>overrides to get the >>>driver to allow the hardware work at what it was spec-ed at. Adam Richter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: hdparm for lib_pata
On 2007-02-04 Stephen Clark wrote: >I have had two different laptops that had to have boot time command line >overrides to get the >driver to allow the hardware work at what it was spec-ed at. Do you know if these drives were advertising less capability than they were spec-ed at? Do you recall if the IDE driver without kernel arguments printed its rationale for reverting to the slower setting? I ask because I'd like to know if this sort of thing can ever happen with libata. If so, then that is yet another reason to have the ability to override DMA settings from user level in libata. Adam Richter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: hdparm for lib_pata
On 2007-02-04 Stephen Clark wrote: I have had two different laptops that had to have boot time command line overrides to get the driver to allow the hardware work at what it was spec-ed at. Do you know if these drives were advertising less capability than they were spec-ed at? Do you recall if the IDE driver without kernel arguments printed its rationale for reverting to the slower setting? I ask because I'd like to know if this sort of thing can ever happen with libata. If so, then that is yet another reason to have the ability to override DMA settings from user level in libata. Adam Richter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: hdparm for lib_pata
= Stephen Clark = Adam Richter = Patrick Ale Do you know if these drives were advertising less capability than they were spec-ed at? Do you recall if the IDE driver without kernel arguments printed its rationale for reverting to the slower setting? [...] Then, after 2 hours, and resyncing RAID1 MD 1 devices, I started seeing things like: Drive not ready DMA timeout on ... I was not asking about Patrick's desktop computer, which was already established to be hardware problem that was fixed by replacing a broken fan. I was asking about Stephen Clark's two laptop computers, which seemed like they might be examples of a need for user level hdparm DMA setting, which is why I prefaced my question with the following quotation: On 2007-02-04 Stephen Clark wrote: I have had two different laptops that had to have boot time command line overrides to get the driver to allow the hardware work at what it was spec-ed at. Adam Richter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]
On Sun, Dec 24, 2006 at 04:25:11PM -0800, Andrew Morton wrote:
> On Mon, 25 Dec 2006 05:21:24 +0800
> "Adam J. Richter" <[EMAIL PROTECTED]> wrote:
>
>> Under 2.6.20-rc1 and 2.6.20-rc2, I get the following complaint
>> for several network programs running on my system:
>>
>> [ 156.381868] BUG: sleeping function called from invalid context at
>> net/core/sock.c:1523
[...]
> There's a glaring bug in selinux_netlbl_inode_permission() - taking
> lock_sock() inside rcu_read_lock().
>
> I would again draw attention to Documentation/SubmitChecklist. In
> particular please always always always enable all kernel debugging options
> when developing and testing new kernel code. And everything else in that
> file, too.
>
>
I have not yet performed the 21 steps of
linux-2.6.20-rc3/Documentation/SubmitChecklist, which I think is a
great objectives list for future automation or some kind of community
web site. I hope to find time to make progress through that
checklist, but, in the meantime, I think the world may nevertheless be
infinitesmally better off if I post the patch that I'm currently
using that seems to fix the problem, seeing as how rc3 has passed
with no fix incorporated.
I think the intent of the offending code was to avoid doing
a lock_sock() in a presumably common case where there was no need to
take the lock. So, I have kept the presumably fast test to exit
early.
When it turns out to be necessary to take lock_sock(), RCU is
unlocked, then lock_sock is taken, the RCU is locked again, and
the test is repeated.
If I am wrong about lock_sock being expensive, I can
delete the lines that do the early return.
By the way, in a change not included in this patch,
I also tried consolidating the RCU locking in this file into a macro
IF_NLBL_REQUIRE(sksec, action), where "action" is the code
fragment to be executed with rcu_read_lock() held, although this
required splitting a couple of functions in half.
Anyhow, here is my current patch as MIME attachment.
Comments and labor in getting it through SubmitChecklist would
both be welcome.
Adam Richter
--- linux-2.6.20-rc3/security/selinux/ss/services.c 2007-01-02
01:47:40.0 +0800
+++ linux/security/selinux/ss/services.c2007-01-02 15:36:30.0
+0800
@@ -2658,14 +2658,22 @@
rcu_read_lock();
if (sksec->nlbl_state != NLBL_REQUIRE) {
rcu_read_unlock();
return 0;
}
+ rcu_read_unlock();
+
+
+ rc = 0;
lock_sock(sock->sk);
- rc = selinux_netlbl_socket_setsid(sock, sksec->sid);
- release_sock(sock->sk);
+ rcu_read_lock();
+
+ if (sksec->nlbl_state == NLBL_REQUIRE)
+ rc = selinux_netlbl_socket_setsid(sock, sksec->sid);
+
rcu_read_unlock();
+ release_sock(sock->sk);
return rc;
}
/**
Re: selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]
On Sun, Dec 24, 2006 at 04:25:11PM -0800, Andrew Morton wrote:
On Mon, 25 Dec 2006 05:21:24 +0800
Adam J. Richter [EMAIL PROTECTED] wrote:
Under 2.6.20-rc1 and 2.6.20-rc2, I get the following complaint
for several network programs running on my system:
[ 156.381868] BUG: sleeping function called from invalid context at
net/core/sock.c:1523
[...]
There's a glaring bug in selinux_netlbl_inode_permission() - taking
lock_sock() inside rcu_read_lock().
I would again draw attention to Documentation/SubmitChecklist. In
particular please always always always enable all kernel debugging options
when developing and testing new kernel code. And everything else in that
file, too.
guesses that this was tested on ia64
I have not yet performed the 21 steps of
linux-2.6.20-rc3/Documentation/SubmitChecklist, which I think is a
great objectives list for future automation or some kind of community
web site. I hope to find time to make progress through that
checklist, but, in the meantime, I think the world may nevertheless be
infinitesmally better off if I post the patch that I'm currently
using that seems to fix the problem, seeing as how rc3 has passed
with no fix incorporated.
I think the intent of the offending code was to avoid doing
a lock_sock() in a presumably common case where there was no need to
take the lock. So, I have kept the presumably fast test to exit
early.
When it turns out to be necessary to take lock_sock(), RCU is
unlocked, then lock_sock is taken, the RCU is locked again, and
the test is repeated.
If I am wrong about lock_sock being expensive, I can
delete the lines that do the early return.
By the way, in a change not included in this patch,
I also tried consolidating the RCU locking in this file into a macro
IF_NLBL_REQUIRE(sksec, action), where action is the code
fragment to be executed with rcu_read_lock() held, although this
required splitting a couple of functions in half.
Anyhow, here is my current patch as MIME attachment.
Comments and labor in getting it through SubmitChecklist would
both be welcome.
Adam Richter
--- linux-2.6.20-rc3/security/selinux/ss/services.c 2007-01-02
01:47:40.0 +0800
+++ linux/security/selinux/ss/services.c2007-01-02 15:36:30.0
+0800
@@ -2658,14 +2658,22 @@
rcu_read_lock();
if (sksec-nlbl_state != NLBL_REQUIRE) {
rcu_read_unlock();
return 0;
}
+ rcu_read_unlock();
+
+
+ rc = 0;
lock_sock(sock-sk);
- rc = selinux_netlbl_socket_setsid(sock, sksec-sid);
- release_sock(sock-sk);
+ rcu_read_lock();
+
+ if (sksec-nlbl_state == NLBL_REQUIRE)
+ rc = selinux_netlbl_socket_setsid(sock, sksec-sid);
+
rcu_read_unlock();
+ release_sock(sock-sk);
return rc;
}
/**
selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]
Under 2.6.20-rc1 and 2.6.20-rc2, I get the following complaint for several network programs running on my system: [ 156.381868] BUG: sleeping function called from invalid context at net/core/sock.c:1523 [ 156.381876] in_atomic():1, irqs_disabled():0 [ 156.381881] no locks held by kio_http/9693. [ 156.381886] [] show_trace_log_lvl+0x1a/0x2f [ 156.381900] [] show_trace+0x12/0x14 [ 156.381908] [] dump_stack+0x16/0x18 [ 156.381917] [] __might_sleep+0xe5/0xeb [ 156.381926] [] lock_sock_nested+0x1d/0xc4 [ 156.381937] [] selinux_netlbl_inode_permission+0x5a/0x8e [ 156.381946] [] selinux_file_permission+0x96/0x9b [ 156.381954] [] vfs_write+0x8d/0x167 [ 156.381962] [] sys_write+0x3f/0x63 [ 156.381971] [] syscall_call+0x7/0xb [ 156.381980] === I have 35 of these messages is my console log at the moment. The only difference that I've noticed between the messages is that they are for variety of processes: most for tor, xntpd, sendmail, procmail. The processes get to this point by sys_write, sys_send, or sys_sendto (procmail was doing a sys_sendto, so it was also doing something related to networking, even though it is not a program one normally would think of as doing any networking system calls). My system seems to work OK even with these warning messages. I can debug it futher. I just figure I should report it now, because I may have done everyone a disservice by putting off reporting it in rc1 in the hopes of finding time to debug it. Adam Richter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]
Under 2.6.20-rc1 and 2.6.20-rc2, I get the following complaint for several network programs running on my system: [ 156.381868] BUG: sleeping function called from invalid context at net/core/sock.c:1523 [ 156.381876] in_atomic():1, irqs_disabled():0 [ 156.381881] no locks held by kio_http/9693. [ 156.381886] [c01057a2] show_trace_log_lvl+0x1a/0x2f [ 156.381900] [c0105dab] show_trace+0x12/0x14 [ 156.381908] [c0105e48] dump_stack+0x16/0x18 [ 156.381917] [c011e30f] __might_sleep+0xe5/0xeb [ 156.381926] [c025942a] lock_sock_nested+0x1d/0xc4 [ 156.381937] [c01cc570] selinux_netlbl_inode_permission+0x5a/0x8e [ 156.381946] [c01c2505] selinux_file_permission+0x96/0x9b [ 156.381954] [c0175a0a] vfs_write+0x8d/0x167 [ 156.381962] [c017605a] sys_write+0x3f/0x63 [ 156.381971] [c01040c0] syscall_call+0x7/0xb [ 156.381980] === I have 35 of these messages is my console log at the moment. The only difference that I've noticed between the messages is that they are for variety of processes: most for tor, xntpd, sendmail, procmail. The processes get to this point by sys_write, sys_send, or sys_sendto (procmail was doing a sys_sendto, so it was also doing something related to networking, even though it is not a program one normally would think of as doing any networking system calls). My system seems to work OK even with these warning messages. I can debug it futher. I just figure I should report it now, because I may have done everyone a disservice by putting off reporting it in rc1 in the hopes of finding time to debug it. Adam Richter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: New SCM and commit list
he DMA mapping to the common bus code from individual drivers, fewer kmap's in crypto, I could go on). >It >seems better to throw something back to someone to rebase their diffs. ^^ I try to avoid a general subjective adjectives like "better" unless I am claiming that I've covered the trade-offs fully, and, even then, avoiding it keeps the focus on analyzing the trade-offs. __ __ Adam J. Richter\ / [EMAIL PROTECTED] | g g d r a s i l - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
On Mon, 11 Apr 2005 20:45:38 +0200, Peter Baudis wrote: > Hello, > please do not trim the cc list so agressively. Sorry. I read the list from a web site that does not show the cc lists. I'll try to cc more people from the relevant discussions though. On the other hand, I've dropped Linus from this message, as it just points to something he previously said. >Dear diary, on Mon, Apr 11, 2005 at 05:46:38PM CEST, I got a letter >where "Adam J. Richter" <[EMAIL PROTECTED]> told me that... >..snip.. >> Graydon Hoare. (By the way, I would prefer that git just punt to >> user level programs for diff and merge when all of the versions >> involved are different or at least have a very thin interface >> for extending the facility, because I would like to do some character >> based merge stuff.) >..snip.. >But this is what git already does. I agree it could do it even better, >by checking environment variables for the appropriate tools (then you >could use that to pass diff e.g. -p etc.). This message from Linus seemed to imply that git was going to get its own 3-way merge code: | Then the bad news: the merge algorithm is going to suck. It's going to be | just plain 3-way merge, the same RCS/CVS thing you've seen before. With no | understanding of renames etc. I'll try to find the best parent to base the | merge off of, although early testers may have to tell the piece of crud | what the most recent common parent was. ( from http://marc.theaimsgroup.com/?l=linux-kernel=111320013100822=2 ) __ __ Adam J. Richter\ / [EMAIL PROTECTED] | g g d r a s i l - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: New SCM and commit list
On 2005-04-11 Linus Torvalds wrote:
>Then the bad news: the merge algorithm is going to suck. It's going to be
>just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
>understanding of renames etc. I'll try to find the best parent to base the
>merge off of, although early testers may have to tell the piece of crud
>what the most recent common parent was.
I've been surprised at how well it works to put each character on a
separate line, pipe the input into diff3 and then join the lines
back together. For example, let's consider the case of
a adding parameters to a function. Here one version adds a parameter
before the existing parameter, and another version adds another parameter
after the existing parameter:
$ cat orig
call(bar);
$ cat ver1
call(foo,bar);
$ cat ver2
call(bar,baz);
$ charmerge ver1 orig ver2
call(foo,bar,baz);
A more practically scaled application that I tried was with
another filter that I wrote that would automatically resolve certain
types of diff3 conflicts[1]. With that filter, I took the SCSI
FlashPoint driver, and made an edited version by piping it through GNU
indent, which not only reindents, but also splits and joins lines.
I made a second edited version by changing all 146 instances of
"SYNC" to "GROP" in the original. It merged apparently successfully,
giving me a GNU indented version with all of the keyword changes.
The version of this resolution program dies if it his a diff3
conflict of a type that it is not prepared to resolve. I'll post
it once I've got it properly preserving the conflicts that it
doesn't try to fix. In the meantime, here is an illustrative
script to do get diff3 to do character-based merges, although it
gives garbage results if there are any conflicts.
[1] The type of conflict that was automatically resolved is as follows:
variant1 =
result -->
...this is actually exactly the order one would want in the
case where also occurs in variant2, but it was close
enough for this test.
__ __
Adam J. Richter\ /
[EMAIL PROTECTED] | g g d r a s i l
#!/bin/sh
# Usage: charmerge ver1_file orig_file ver2_file
lineify() {
sed 's/\([^\n]\)/\1\
/g'
}
unlineify() {
awk '/^$/ {print $0} /^..*/ { printf "%s", $0}'
}
tmpdir=/tmp/charmerge.$$
mkdir $tmpdir
lineify < "$1" > $tmpdir/1
lineify < "$2" > $tmpdir/2
lineify < "$3" > $tmpdir/3
diff3 -m $tmpdir/{1,2,3} | unlineify
rm -rf $tmpdir
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
On 2005-04-11, Linus Torvalds wrote:
>I'm inclined to go with GPLv2 just because it's the most common one [...]
You may want to use a file from GPL'ed monotone that
implements a substantial diff optimization described in the August
1989 paper by Sun Wu, Udi Manber and Gene Myers ("An O(NP) Sequence
Comparison Algorithm"). According to th file, that implementation
was a port of some Scheme code written by Aubrey Jaffer to C++ by
Graydon Hoare. (By the way, I would prefer that git just punt to
user level programs for diff and merge when all of the versions
involved are different or at least have a very thin interface
for extending the facility, because I would like to do some character
based merge stuff.)
It looks to me like the anti-patent provisions of OSLv2.1
could be circumvented by an offender creating a separate company
to do patent litigation. So, I think you'll find that the software
reuse benefits (both to GIT and to other software projects) of the
more widely used GPL ougtweigh the anti-patent benefits of OSLv2.1.
Although I like the idea of anti-patent provisions, such
as those in OSLv2.1, I think mutual compatability of free
software is probably more consequential, even from a purely
political perspective.
Perhaps you might want to consider offering the code
under the distributor's choice of either license if you want
to offer the very minor benefits of slightly easier compliance
to those who do not litigate software patents, or, perhaps more
importantly, the ability of the software to be copied into
OSLv2.1 projects (if there are any).
__ __________
Adam J. Richter\ /
[EMAIL PROTECTED] | g g d r a s i l
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
On 2005-04-11, Linus Torvalds wrote: I'm inclined to go with GPLv2 just because it's the most common one [...] You may want to use a file from GPL'ed monotone that implements a substantial diff optimization described in the August 1989 paper by Sun Wu, Udi Manber and Gene Myers (An O(NP) Sequence Comparison Algorithm). According to th file, that implementation was a port of some Scheme code written by Aubrey Jaffer to C++ by Graydon Hoare. (By the way, I would prefer that git just punt to user level programs for diff and merge when all of the versions involved are different or at least have a very thin interface for extending the facility, because I would like to do some character based merge stuff.) It looks to me like the anti-patent provisions of OSLv2.1 could be circumvented by an offender creating a separate company to do patent litigation. So, I think you'll find that the software reuse benefits (both to GIT and to other software projects) of the more widely used GPL ougtweigh the anti-patent benefits of OSLv2.1. Although I like the idea of anti-patent provisions, such as those in OSLv2.1, I think mutual compatability of free software is probably more consequential, even from a purely political perspective. Perhaps you might want to consider offering the code under the distributor's choice of either license if you want to offer the very minor benefits of slightly easier compliance to those who do not litigate software patents, or, perhaps more importantly, the ability of the software to be copied into OSLv2.1 projects (if there are any). __ __ Adam J. Richter\ / [EMAIL PROTECTED] | g g d r a s i l - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: New SCM and commit list
On 2005-04-11 Linus Torvalds wrote:
Then the bad news: the merge algorithm is going to suck. It's going to be
just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
understanding of renames etc. I'll try to find the best parent to base the
merge off of, although early testers may have to tell the piece of crud
what the most recent common parent was.
I've been surprised at how well it works to put each character on a
separate line, pipe the input into diff3 and then join the lines
back together. For example, let's consider the case of
a adding parameters to a function. Here one version adds a parameter
before the existing parameter, and another version adds another parameter
after the existing parameter:
$ cat orig
call(bar);
$ cat ver1
call(foo,bar);
$ cat ver2
call(bar,baz);
$ charmerge ver1 orig ver2
call(foo,bar,baz);
A more practically scaled application that I tried was with
another filter that I wrote that would automatically resolve certain
types of diff3 conflicts[1]. With that filter, I took the SCSI
FlashPoint driver, and made an edited version by piping it through GNU
indent, which not only reindents, but also splits and joins lines.
I made a second edited version by changing all 146 instances of
SYNC to GROP in the original. It merged apparently successfully,
giving me a GNU indented version with all of the keyword changes.
The version of this resolution program dies if it his a diff3
conflict of a type that it is not prepared to resolve. I'll post
it once I've got it properly preserving the conflicts that it
doesn't try to fix. In the meantime, here is an illustrative
script to do get diff3 to do character-based merges, although it
gives garbage results if there are any conflicts.
[1] The type of conflict that was automatically resolved is as follows:
variant1 = prepended-new-textoriginalappended-new-text
result -- prepended-new-textvariant2appended-new-text
...this is actually exactly the order one would want in the
case where original also occurs in variant2, but it was close
enough for this test.
__ __
Adam J. Richter\ /
[EMAIL PROTECTED] | g g d r a s i l
#!/bin/sh
# Usage: charmerge ver1_file orig_file ver2_file
lineify() {
sed 's/\([^\n]\)/\1\
/g'
}
unlineify() {
awk '/^$/ {print $0} /^..*/ { printf %s, $0}'
}
tmpdir=/tmp/charmerge.$$
mkdir $tmpdir
lineify $1 $tmpdir/1
lineify $2 $tmpdir/2
lineify $3 $tmpdir/3
diff3 -m $tmpdir/{1,2,3} | unlineify
rm -rf $tmpdir
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
On Mon, 11 Apr 2005 20:45:38 +0200, Peter Baudis wrote: Hello, please do not trim the cc list so agressively. Sorry. I read the list from a web site that does not show the cc lists. I'll try to cc more people from the relevant discussions though. On the other hand, I've dropped Linus from this message, as it just points to something he previously said. Dear diary, on Mon, Apr 11, 2005 at 05:46:38PM CEST, I got a letter where Adam J. Richter [EMAIL PROTECTED] told me that... ..snip.. Graydon Hoare. (By the way, I would prefer that git just punt to user level programs for diff and merge when all of the versions involved are different or at least have a very thin interface for extending the facility, because I would like to do some character based merge stuff.) ..snip.. But this is what git already does. I agree it could do it even better, by checking environment variables for the appropriate tools (then you could use that to pass diff e.g. -p etc.). This message from Linus seemed to imply that git was going to get its own 3-way merge code: | Then the bad news: the merge algorithm is going to suck. It's going to be | just plain 3-way merge, the same RCS/CVS thing you've seen before. With no | understanding of renames etc. I'll try to find the best parent to base the | merge off of, although early testers may have to tell the piece of crud | what the most recent common parent was. ( from http://marc.theaimsgroup.com/?l=linux-kernelm=111320013100822w=2 ) __ __ Adam J. Richter\ / [EMAIL PROTECTED] | g g d r a s i l - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: New SCM and commit list
a general subjective adjectives like better unless I am claiming that I've covered the trade-offs fully, and, even then, avoiding it keeps the focus on analyzing the trade-offs. __ __ Adam J. Richter\ / [EMAIL PROTECTED] | g g d r a s i l - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Squashfs without ./..
Jan Engelhardt wrote: >[...] . and .. do not need to show up (even they have been the >"leaders" of ls -l ;-), Midnight Commander (`mc`) for example synthesizes ".." >nevertheless. > >So - what about removing . and .. in readdir for all "standard harddisk >filesystems" (ext*,reiser*, [jx]fs)? I mean, one party always has to loose...~v Eliminating the "." and ".." emulation in many individual file systems would probably eliminate a moderate amount of code from libfs/fs.c, a number of other virtual file systems and probably every physical file system that does not actually store "." and "..". It is very appealing to me. Unfortunately, the description of readdir() in the Single Unix Specification version 3 says: | [...] If entries for dot or dot-dot exist, one entry shall be returned | for dot and one entry shall be returned for dot-dot; otherwise, they | shall not be returned. Unless attempts to access "." and ".." would really return -ENOENT, then at least the C library's readdir() function has to return them. At least that's how I read it. Although I do not believe that absolute compliance to SUSPv3 is a requirement demanded by those who make the "official" kernel releases, I think that complying closely to SUSPv3 and many other standards is considered to be worth a lot (in terms of technical trade-offs) so that software that complies to these standards is more likely to run properly on systems running the Linux kernel. So, I would expect that patches changing squashfs and other file systems whose readdir functions currently fail to return "." and ".." would be likely to be integrated (if they meet all the other usual quality standards), at least for now. That said, I can think of at least two approaches by which we could eliminate the "." and ".." emulation littering most Linux file system drivers. The first way would be to change the kernel so that the underlying readdir system call does not return "." or "..", but have the C library do the emulation. The C library can maintain the state information for this purpose easily because opendir() returns a pointer to an opaque structure that the C library allocates. Alternatively, we could preserve the opendir system call's behavior, but pick apart a few of the routines in fs/libfs.c to come up with some more general utiity routines to implement the common case where the first readdir returns ".", the second returns "..", a seek pointer of 0 means before the ".", a seek pointer of 1 means before the "..", and a seek pointer of 1 means immediately after the "..". The actual implementation would be pretty short, but having an interface that the client file systems could easily accomodate might take some care (for example, accomodating their locking schemes while keeping the interface simple enough so that the client file system drivers are still made smaller by using it). __ __ Adam J. Richter\ / [EMAIL PROTECTED] | g g d r a s i l - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Squashfs without ./..
Jan Engelhardt wrote: [...] . and .. do not need to show up (even they have been the leaders of ls -l ;-), Midnight Commander (`mc`) for example synthesizes .. nevertheless. So - what about removing . and .. in readdir for all standard harddisk filesystems (ext*,reiser*, [jx]fs)? I mean, one party always has to loose...~v Eliminating the . and .. emulation in many individual file systems would probably eliminate a moderate amount of code from libfs/fs.c, a number of other virtual file systems and probably every physical file system that does not actually store . and ... It is very appealing to me. Unfortunately, the description of readdir() in the Single Unix Specification version 3 says: | [...] If entries for dot or dot-dot exist, one entry shall be returned | for dot and one entry shall be returned for dot-dot; otherwise, they | shall not be returned. Unless attempts to access . and .. would really return -ENOENT, then at least the C library's readdir() function has to return them. At least that's how I read it. Although I do not believe that absolute compliance to SUSPv3 is a requirement demanded by those who make the official kernel releases, I think that complying closely to SUSPv3 and many other standards is considered to be worth a lot (in terms of technical trade-offs) so that software that complies to these standards is more likely to run properly on systems running the Linux kernel. So, I would expect that patches changing squashfs and other file systems whose readdir functions currently fail to return . and .. would be likely to be integrated (if they meet all the other usual quality standards), at least for now. That said, I can think of at least two approaches by which we could eliminate the . and .. emulation littering most Linux file system drivers. The first way would be to change the kernel so that the underlying readdir system call does not return . or .., but have the C library do the emulation. The C library can maintain the state information for this purpose easily because opendir() returns a pointer to an opaque structure that the C library allocates. Alternatively, we could preserve the opendir system call's behavior, but pick apart a few of the routines in fs/libfs.c to come up with some more general utiity routines to implement the common case where the first readdir returns ., the second returns .., a seek pointer of 0 means before the ., a seek pointer of 1 means before the .., and a seek pointer of 1 means immediately after the ... The actual implementation would be pretty short, but having an interface that the client file systems could easily accomodate might take some care (for example, accomodating their locking schemes while keeping the interface simple enough so that the client file system drivers are still made smaller by using it). __ __ Adam J. Richter\ / [EMAIL PROTECTED] | g g d r a s i l - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: linux-2.4.7-pre3/drivers/char/sonypi.c would hang some non-Sony notebooks
>From: "Robert J.Dunlop" <[EMAIL PROTECTED]> >Hi, >First off, it works for me on my VAIO PCG-Z600NE. Great. Thanks for testing it! [...] >Just a niggle however. This still isn't a very good test to finding a >Sony laptop. What'll happen on machines that have any sort of Sony >plugin device ? >How's about we test for a machine that has a host bridge with the Sony >subvendor ID, rather than any device. On my Sony Vaio C1VN PictureBook, the host bridge subsystem vendor ID is Transmeta, not Sony. The device with the Sony subsystem vendor ID are the firewire controller, sound devices, soft modem, cardbus bridge and video. So, you could would not work on it (although I did not actually try it). >I guess this'll still pickup Sony desktops. Sony desktops are also called "Vaio." I do not know whether they have the hardware that sonypi tries to talk to. >Perhaps we need a survey of lspci -nv results for sony and non-sony >machines ? Yes, although that is a task that is never complete. So, I would recommend that we adopt a simple test that should work into the stock kernels with the expectation that the test will probably be refined in the future. Perhaps we could check the Cardbus bridge. Does "lspci -v" on your Sony Vaio indicate that its cardbus bridge have a subsystem vendor ID of Sony? Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: linux-2.4.7-pre3/drivers/char/sonypi.c would hang some non-Sony notebooks
From: Robert J.Dunlop [EMAIL PROTECTED] Hi, First off, it works for me on my VAIO PCG-Z600NE. Great. Thanks for testing it! [...] Just a niggle however. This still isn't a very good test to finding a Sony laptop. What'll happen on machines that have any sort of Sony plugin device ? How's about we test for a machine that has a host bridge with the Sony subvendor ID, rather than any device. On my Sony Vaio C1VN PictureBook, the host bridge subsystem vendor ID is Transmeta, not Sony. The device with the Sony subsystem vendor ID are the firewire controller, sound devices, soft modem, cardbus bridge and video. So, you could would not work on it (although I did not actually try it). I guess this'll still pickup Sony desktops. Sony desktops are also called Vaio. I do not know whether they have the hardware that sonypi tries to talk to. Perhaps we need a survey of lspci -nv results for sony and non-sony machines ? Yes, although that is a task that is never complete. So, I would recommend that we adopt a simple test that should work into the stock kernels with the expectation that the test will probably be refined in the future. Perhaps we could check the Cardbus bridge. Does lspci -v on your Sony Vaio indicate that its cardbus bridge have a subsystem vendor ID of Sony? Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH: linux-2.4.7-pre3/drivers/char/sonypi.c would hang some non-Sony notebooks
The pci_device_id tables in linux-2.4.7-pre3/drivers/char/sonypi.c
claims that the driver wants to be loaded on all computers that have
an that have a PCI device with vendor id PCI_VENDOR_ID_INTEL and
a device ID of either PCI_DEVICE_ID_INTEL_82371AB_3 (0x7110) or
PCI_DEVICE_ID_INTEL_82801BA_10 (0x244c). My Kapok 1100m notebook
computer has an Intel 82371ab, so the sonypi module automatically
loads at boot time and hangs the computer.
sonypi_init_module needs to do some kind of test to figure out
if it is on a Sony Vaio and abort otherwise. Looking at the result of
"lspci -v" on my Sony Vaio Picturebook, I see that, while none of the
PCI devices have Sony's vendor ID, a number of them have Sony's
vendor ID as their subsystem vendor ID's. So, I have implemented the
following test to cause sonypi only to be loadable on machines that
have at least one PCI device that has a subsystem vendor ID of
PCI_VENDOR_ID_SONY.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.7-pre3/drivers/char/sonypi.c Sat Jul 7 18:00:12 2001
+++ linux/drivers/char/sonypi.c Sat Jul 7 18:00:28 2001
@@ -690,7 +690,11 @@
};
static int __init sonypi_init_module(void) {
- return pci_module_init(_driver);
+ if (pci_find_subsys(PCI_ANY_ID, PCI_ANY_ID,
+ PCI_VENDOR_ID_SONY, PCI_ANY_ID, NULL) != NULL)
+ return pci_module_init(_driver);
+ else
+ return -ENODEV;
}
static void __exit sonypi_cleanup_module(void) {
PATCH: linux-2.4.7-pre3/drivers/char/sonypi.c would hang some non-Sony notebooks
The pci_device_id tables in linux-2.4.7-pre3/drivers/char/sonypi.c
claims that the driver wants to be loaded on all computers that have
an that have a PCI device with vendor id PCI_VENDOR_ID_INTEL and
a device ID of either PCI_DEVICE_ID_INTEL_82371AB_3 (0x7110) or
PCI_DEVICE_ID_INTEL_82801BA_10 (0x244c). My Kapok 1100m notebook
computer has an Intel 82371ab, so the sonypi module automatically
loads at boot time and hangs the computer.
sonypi_init_module needs to do some kind of test to figure out
if it is on a Sony Vaio and abort otherwise. Looking at the result of
lspci -v on my Sony Vaio Picturebook, I see that, while none of the
PCI devices have Sony's vendor ID, a number of them have Sony's
vendor ID as their subsystem vendor ID's. So, I have implemented the
following test to cause sonypi only to be loadable on machines that
have at least one PCI device that has a subsystem vendor ID of
PCI_VENDOR_ID_SONY.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 Free Software For The Rest Of Us.
--- linux-2.4.7-pre3/drivers/char/sonypi.c Sat Jul 7 18:00:12 2001
+++ linux/drivers/char/sonypi.c Sat Jul 7 18:00:28 2001
@@ -690,7 +690,11 @@
};
static int __init sonypi_init_module(void) {
- return pci_module_init(sonypi_driver);
+ if (pci_find_subsys(PCI_ANY_ID, PCI_ANY_ID,
+ PCI_VENDOR_ID_SONY, PCI_ANY_ID, NULL) != NULL)
+ return pci_module_init(sonypi_driver);
+ else
+ return -ENODEV;
}
static void __exit sonypi_cleanup_module(void) {
Re: linux-2.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols
>> linux-2.4.6-pre8/drivers/mtd/nand/spia.c references four >> undefined symbols, presumably intended to be #define constants, >> although I am not sure what their values are supposed to be: >> >> IO_BASE >> FIO_BASE >> PEDR >> PEDDR >> >The way that I architected the raw NAND flash device driver was to >break it into 2 parts. 'nand.c' contains the actual driver code and >is considered to be device independent. 'spia.c' is the device >dependent part. You should write your own version of 'spia.c' and >"simply" fill in the addresses for the IO address and control >register address depending on your specific hardware. The above >symbols are only defined for my specific hardware. They should be >changed to values used on your hardware platform. Let me know if >you need further assistance. >-Steve >-- > Steven J. Hill - Embedded SW Engineer If there is no architecture on which linux-2.4.6-pre8/drivers/mtd/nand/spia.c will compile in its "pristine" form, then the CONFIG_MTD_NAND_SPIA should be commented out from drivers/mtd/nand/Config.in to avoid wasting the time of users and automated build processes alike that just want to build all available modules by default. (At the moment, this code is not even bracketed by CONFIG_EXPERIMENTAL, although changing that would not be a sufficient fix.) Alternatively, if you will send me a one line description of each of those four #define parameters, I will be happy to do the grunt work of submiting a patch to you or whoever is appropriate to replace those values with module and setup parameters that default to those values if there are #defined and otherwise will abort initialization if they are not #defined and no values were provided at run time. (Or, better, yet, you can do this work!) Please let me know how you want to proceed. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols
linux-2.4.6-pre8/drivers/mtd/nand/spia.c references four undefined symbols, presumably intended to be #define constants, although I am not sure what their values are supposed to be: IO_BASE FIO_BASE PEDR PEDDR The way that I architected the raw NAND flash device driver was to break it into 2 parts. 'nand.c' contains the actual driver code and is considered to be device independent. 'spia.c' is the device dependent part. You should write your own version of 'spia.c' and simply fill in the addresses for the IO address and control register address depending on your specific hardware. The above symbols are only defined for my specific hardware. They should be changed to values used on your hardware platform. Let me know if you need further assistance. -Steve -- Steven J. Hill - Embedded SW Engineer If there is no architecture on which linux-2.4.6-pre8/drivers/mtd/nand/spia.c will compile in its pristine form, then the CONFIG_MTD_NAND_SPIA should be commented out from drivers/mtd/nand/Config.in to avoid wasting the time of users and automated build processes alike that just want to build all available modules by default. (At the moment, this code is not even bracketed by CONFIG_EXPERIMENTAL, although changing that would not be a sufficient fix.) Alternatively, if you will send me a one line description of each of those four #define parameters, I will be happy to do the grunt work of submiting a patch to you or whoever is appropriate to replace those values with module and setup parameters that default to those values if there are #defined and otherwise will abort initialization if they are not #defined and no values were provided at run time. (Or, better, yet, you can do this work!) Please let me know how you want to proceed. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols
linux-2.4.6-pre8/drivers/mtd/nand/spia.c references four undefined symbols, presumably intended to be #define constants, although I am not sure what their values are supposed to be: IO_BASE FIO_BASE PEDR PEDDR Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs
>From: Russell King <[EMAIL PROTECTED]> >On Sat, Jun 30, 2001 at 08:26:22AM +0100, Alan Cox wrote: >> #2 >> dep_tristate $FOO $BAR >> >> to say 'FOO requires BAR and must be a similar setting _IF_CONFIGURED_' >Err, how can $BAR be undefined? Configure sets all config variables which >are answered with 'n' to 'n'. One example would be processing of the following line on a non-sparc computer (from linux-2.4.6-pre6/drivers/sbus/audio/Config.in): dep_tristate ' Sun Microsystems userflash support' CONFIG_MTD_SUN_UFLASH $CONFIG_SPARC64 I think this could also come up for drivers that depend on $CONFIG_ISA when configured for non-PC platforms that do not ask about ISA support. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs
From: Russell King [EMAIL PROTECTED] On Sat, Jun 30, 2001 at 08:26:22AM +0100, Alan Cox wrote: #2 dep_tristate $FOO $BAR to say 'FOO requires BAR and must be a similar setting _IF_CONFIGURED_' Err, how can $BAR be undefined? Configure sets all config variables which are answered with 'n' to 'n'. One example would be processing of the following line on a non-sparc computer (from linux-2.4.6-pre6/drivers/sbus/audio/Config.in): dep_tristate ' Sun Microsystems userflash support' CONFIG_MTD_SUN_UFLASH $CONFIG_SPARC64 I think this could also come up for drivers that depend on $CONFIG_ISA when configured for non-PC platforms that do not ask about ISA support. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs
The Config.in files in linux-2.4.6-pre6 have at least 28 cases where a dep_bool or dep_tristate of the following form: dep_bool CONFIG_SOMETHING $CONFIG_ARCH_somearch The problem with this is that, unlike most configuration variables, the $CONFIG_ARCH_ variables are often not set to "n" when they are not selected (they are often just not defined, for example, when they are archectures for a completely different CPU type). When those variables are not defined, that is essentially equivalent to passing "y" to dep_bool, and the user is incorrectly asked about these facilities. I will put together patch to convert this to ugly but correct "if then; ... ; fi" statements later today if nobody has any better suggestions. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs
The Config.in files in linux-2.4.6-pre6 have at least 28 cases where a dep_bool or dep_tristate of the following form: dep_bool CONFIG_SOMETHING $CONFIG_ARCH_somearch The problem with this is that, unlike most configuration variables, the $CONFIG_ARCH_ variables are often not set to n when they are not selected (they are often just not defined, for example, when they are archectures for a completely different CPU type). When those variables are not defined, that is essentially equivalent to passing y to dep_bool, and the user is incorrectly asked about these facilities. I will put together patch to convert this to ugly but correct if then; ... ; fi statements later today if nobody has any better suggestions. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [isocompr PATCH]: first comparison with HPA's zisofs (warning: rambling)
I wanted to provide some background on where isocompr came from make a few encouraging remarks about integrating this sort of functinality into the stock kernels, but somehow I've managed to ramble for 60 lines about it. It's safe to skip this article if you're in a hurry! The genesis of the isocompr code is Eric Youngdale's Transparent Compression Facility for ISO-9660 at ftp://tsx-11.mit.edu/pub/linux/BETA/cdrom/private/mkisofs/tcf.tar.gz, written in Junary 1994 for Linux 0.9x. Sometime before February 1998, I ported Eric's code to Linux 2.1.86, adding support for the page cache and making a few changes in the compressed file format (putting the table of contents at the end so that gzip could stream its output, and I think removing some unnecessary header fluff and possibly supporting larger files and different block sizes). iso9660-compress-2.0.tar.gz has been FTPable from ftp://ftp.yggdrasil.com/pub/dist/cdrom/ and ftp://metalab.unc.edu/pub/Linux/kernel/ since its announcement on comp.os.linux.development.system in February 1998 (http://groups.google.com/groups?q=iso9660-compress=en=off=1=1=6cdlme%24ai2%40freya.yggdrasil.com). I have been updating it and it is in the 2.4.5 build tree at Yggdrasil. Although I have distributed test CD's that use this system, I believe the only mass produced CD's that use it are from DemoLinux. I've sent people copies of updated versions as they've asked, but I never really championed integration of this code into the kernel, because (if memory serves) of some unsolved bug that escapes my recollection. One of the people was Vincent Balat, one of Professor Di Cosmo's students working on DemoLinux. Professor Di Cosmo (and his students?) have worked on it since then, starting with sending me that bug fix, and subsequently becoming the place where development was actually being done on it. I vaguely recall that because of a lack of support for 64 bit division and had to restrict block sizes to being a power of two (not a big practical problem) and then in the course of doing something for page-based IO support I think I only supported block sizes of less than or equal to the page size. So, I am glad to see that Peter's code supports block sizes bigger than 4kB, as I think this typically will improve gzip efficiency on objects and binaries by roughly 15%. The 12 byte headers on each block I do not understand the need for, since the data length is already known and there is already plenty of error checking in the CDROM data sectors, but it should only add about 500kB to a 680MB CD that is compressing 32kB data blocks and getting a 2:1 compression ratio (i.e., getting 16kB blocks). Although the duplication of effort frustrates me slightly, I'm glad to see both Professor Di Cosmo and Peter championing integration of this functionality into the kernel in one form or another. It not only makes it possible to distribute much bigger "live" filesystems on CD or DVD, but also should improve throughput on slower drives (and there are still lots of slower CD's out there). I hope this functionality will be integrated into the stock kernels relatively soon. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [isocompr PATCH]: first comparison with HPA's zisofs (warning: rambling)
I wanted to provide some background on where isocompr came from make a few encouraging remarks about integrating this sort of functinality into the stock kernels, but somehow I've managed to ramble for 60 lines about it. It's safe to skip this article if you're in a hurry! The genesis of the isocompr code is Eric Youngdale's Transparent Compression Facility for ISO-9660 at ftp://tsx-11.mit.edu/pub/linux/BETA/cdrom/private/mkisofs/tcf.tar.gz, written in Junary 1994 for Linux 0.9x. Sometime before February 1998, I ported Eric's code to Linux 2.1.86, adding support for the page cache and making a few changes in the compressed file format (putting the table of contents at the end so that gzip could stream its output, and I think removing some unnecessary header fluff and possibly supporting larger files and different block sizes). iso9660-compress-2.0.tar.gz has been FTPable from ftp://ftp.yggdrasil.com/pub/dist/cdrom/ and ftp://metalab.unc.edu/pub/Linux/kernel/ since its announcement on comp.os.linux.development.system in February 1998 (http://groups.google.com/groups?q=iso9660-compresshl=ensafe=offrnum=1ic=1selm=6cdlme%24ai2%40freya.yggdrasil.com). I have been updating it and it is in the 2.4.5 build tree at Yggdrasil. Although I have distributed test CD's that use this system, I believe the only mass produced CD's that use it are from DemoLinux. I've sent people copies of updated versions as they've asked, but I never really championed integration of this code into the kernel, because (if memory serves) of some unsolved bug that escapes my recollection. One of the people was Vincent Balat, one of Professor Di Cosmo's students working on DemoLinux. Professor Di Cosmo (and his students?) have worked on it since then, starting with sending me that bug fix, and subsequently becoming the place where development was actually being done on it. I vaguely recall that because of a lack of support for 64 bit division and had to restrict block sizes to being a power of two (not a big practical problem) and then in the course of doing something for page-based IO support I think I only supported block sizes of less than or equal to the page size. So, I am glad to see that Peter's code supports block sizes bigger than 4kB, as I think this typically will improve gzip efficiency on objects and binaries by roughly 15%. The 12 byte headers on each block I do not understand the need for, since the data length is already known and there is already plenty of error checking in the CDROM data sectors, but it should only add about 500kB to a 680MB CD that is compressing 32kB data blocks and getting a 2:1 compression ratio (i.e., getting 16kB blocks). Although the duplication of effort frustrates me slightly, I'm glad to see both Professor Di Cosmo and Peter championing integration of this functionality into the kernel in one form or another. It not only makes it possible to distribute much bigger live filesystems on CD or DVD, but also should improve throughput on slower drives (and there are still lots of slower CD's out there). I hope this functionality will be integrated into the stock kernels relatively soon. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
> = Alan Cox >> = [EMAIL PROTECTED]? >>> = ?? >>> AFAICS, the firmware is just a file served up to the device as needed >>> - no more a derivative work from the kernel than my homepage is a >>> derivative work of Apache. >> >> Indeed. But if you compiled your home page, linked it into Emacs to >> display on startup, and distributed the binary, the _combination_ >> "Emacs+homepage" binary would be a derived work, and you'd be required >> to offer source for both parts. >In which case GNU Emacs violates the GPL by containing a copy of COPYING which >is more restricted than the GPL. After all it displays copying on a hotkey >combination "M-x describe-copying" just displays the file /usr/share/emacs//etc/COPYING. The emacs binaries do not contain the text of GPL. By the way, if one wanted to #include the text of the GPL, then, in the specific case of the GPL, one could argue that the restrictions on modifying the GPL are part of the GPL and, therefore not further restrictions. (Even though those restrictions occur before the "preamble", they're just as binding and removing them would be a change to the GPL, so they are an existing restriction of the GPL rather than a further restriction.) That said, I have long advocated that authors use GPL-compatible copying conditions for everything, including plain text, to facilitate free software effects on platforms that comingle code and documentation, such as many web pages and some other interactive media. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 A +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
= Alan Cox = [EMAIL PROTECTED]? = ?? AFAICS, the firmware is just a file served up to the device as needed - no more a derivative work from the kernel than my homepage is a derivative work of Apache. Indeed. But if you compiled your home page, linked it into Emacs to display on startup, and distributed the binary, the _combination_ Emacs+homepage binary would be a derived work, and you'd be required to offer source for both parts. In which case GNU Emacs violates the GPL by containing a copy of COPYING which is more restricted than the GPL. After all it displays copying on a hotkey combination M-x describe-copying just displays the file /usr/share/emacs/version/etc/COPYING. The emacs binaries do not contain the text of GPL. By the way, if one wanted to #include the text of the GPL, then, in the specific case of the GPL, one could argue that the restrictions on modifying the GPL are part of the GPL and, therefore not further restrictions. (Even though those restrictions occur before the preamble, they're just as binding and removing them would be a change to the GPL, so they are an existing restriction of the GPL rather than a further restriction.) That said, I have long advocated that authors use GPL-compatible copying conditions for everything, including plain text, to facilitate free software effects on platforms that comingle code and documentation, such as many web pages and some other interactive media. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 A +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
James Sutherland wrote: >On Fri, 25 May 2001, Adam J. Richter wrote: >> Larry McVoy wrote: >> >On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote: >> >It's also about the concept of boundaries - if you think that that >> >concept is not a legal one then why aren't all programs which are run >> >on top of a GPLed kernel then GPLed? >> >> Apparently Linus felt that that was a sufficiently >> plausible gray area that he addressed it explicitly in >> /usr/src/linux/COPYING: >> >> | NOTE! This copyright does *not* cover user programs that use kernel >> | services by normal system calls - this is merely considered normal use >> | of the kernel, and does *not* fall under the heading of "derived work". >> | Also note that the GPL below is copyrighted by the Free Software >> | Foundation, but the instance of code that it refers to (the Linux >> | kernel) is copyrighted by me and others who actually wrote it. >Note the "derived work"; there is no way on this earth (or any other) that >you could regard the device's firmware as being a "derived work" of the >driver! AFAICS, the firmware is just a file served up to the device as >needed - no more a derivative work from the kernel than my homepage is a >derivative work of Apache. Nobody is arguing that it is illegal to copy the keyspan firmware by itself. What I think is clearly illegal is copying the whole keyspan .o file, not because it infringes the firmware copyrights, but because it infringes the GPL'ed material's copyrights. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
James Sutherland wrote: On Fri, 25 May 2001, Adam J. Richter wrote: Larry McVoy wrote: On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote: It's also about the concept of boundaries - if you think that that concept is not a legal one then why aren't all programs which are run on top of a GPLed kernel then GPLed? Apparently Linus felt that that was a sufficiently plausible gray area that he addressed it explicitly in /usr/src/linux/COPYING: | NOTE! This copyright does *not* cover user programs that use kernel | services by normal system calls - this is merely considered normal use | of the kernel, and does *not* fall under the heading of derived work. | Also note that the GPL below is copyrighted by the Free Software | Foundation, but the instance of code that it refers to (the Linux | kernel) is copyrighted by me and others who actually wrote it. Note the derived work; there is no way on this earth (or any other) that you could regard the device's firmware as being a derived work of the driver! AFAICS, the firmware is just a file served up to the device as needed - no more a derivative work from the kernel than my homepage is a derivative work of Apache. Nobody is arguing that it is illegal to copy the keyspan firmware by itself. What I think is clearly illegal is copying the whole keyspan .o file, not because it infringes the firmware copyrights, but because it infringes the GPL'ed material's copyrights. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
Larry McVoy wrote: >On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote: >> Contracts for slavery are specifically not enforceable due to >> the 13th Amendment, and there is also a stronger question of formation >Completely misses the point. THe point isn't about slavery, come on, Adam, >it's about putting unenforceable things into contracts. The point is you have to agree to the contract that is the GPL to get the right to make a copy of a GPL'ed work. You raised the ridiculous example of slavery apparently as an analogy to the requirements of permissions on copying conditions that go beyond restrictions one is subject to anyway by copyright. The point is that you can make require someone to agree to conditions that go beyond the restrictions already imposed by copyright in exchange for permission to, for example, make a copy, so your argument about the boundaries of copyright is inapplicable. The GPL is enforceable. >It's also about the concept of boundaries - if you think that that >concept is not a legal one then why aren't all programs which are run >on top of a GPLed kernel then GPLed? Apparently Linus felt that that was a sufficiently plausible gray area that he addressed it explicitly in /usr/src/linux/COPYING: | NOTE! This copyright does *not* cover user programs that use kernel | services by normal system calls - this is merely considered normal use | of the kernel, and does *not* fall under the heading of "derived work". | Also note that the GPL below is copyrighted by the Free Software | Foundation, but the instance of code that it refers to (the Linux | kernel) is copyrighted by me and others who actually wrote it. I believe you could enforce copying conditions on a kernel where, in order to have the right to make a copy of the kernel, you agree only to run certain types of programs. I believe Windows CE has historically been "licensed" this way. I did not say that you cannot define boundaries and I also think you can even make inferences that a judge is likely to agree with. What I am saying is that in order to have the right to make a copy of the of the GPL'ed code in the keyspan_usa drivers, you must agree to everything the GPL requires, and those requirements do not have to be limited to the boundaries of the author's existing copyright. The GPL is a contract. If you don't agree to it, don't do anything with GPL'ed material that the copyright monopoly restricts. I am not a lawyer, so please do not rely on this as legal advice. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
Doug Ledford wrote: >"Adam J. Richter" wrote: >> On the question of whether this is nothing more than >> aggregation, >Yes, on that very question, I would argue it is a mere aggregation. >> the firmware works intimately with the device driver to >> produce a unitary result. >Irrelevant. The 1991 Abridged 6th Edition of _Black's Law Dictionary_ defines "aggregation" thusly (unfortunately, talking in terms of patent law, but it is the most authoratitive definition I have found so far): Aggregation: The combination of two or more elements in patent claims, each of which is unrelated and each of which performs separately and without cooperation , where combination does not define a composite integrate mechanism. Term means that the elements of a claimed combination are incapabile of co-operation to produce a unitary result, and in its true sense does not need prior art patents to support it. If you want to argue that a court will use a different definition of aggregation, then please explain why and quote that definition. Also, it's important not to forget the word "mere." If the combination is anything *more* than aggregration, then it's not _merely_ aggregation. So, if you wanted to argue from the definition on webster.com: 1 : a group, body, or mass composed of many distinct parts or individuals 2 a : the collecting of units or parts into a mass or whole b : the condition of being so collected You have to argue that absolutely nothing more than this is being done. For example, the code the parts are not working together. >All drivers work with some sort of firmware on their respective >targets to produce a unitary result, even if that firmware is implemented with >silicon (as a ROM BIOS that loads the proper firmware code, or as >microcode/state hardware built into the chip(set) itself). As a closely >similar device, think about the 1542 SCSI controller. [...] Yes. It would also be illegal to distribute a GPL'ed driver .o that #include'd that proprietary firmware. >> You actually have to do some >> kernel development to remove the >> [proprietary firmware from the keyspan_usa drivers]. >That's because you are assuming that uploading garbage to the device is not an >option. No. If I you change the driver to upload garbage, your userland loader that just looks for the unitialized device ID will not be able to get to the uninitialized device before the device driver claims the interface and trashes it. So, your supposed act of disaggregation by zeroing out the effected bytes did not fully restore the old functionality. By the way, I'm pretty sure that the situation is even worse. The modified driver would not just load garbage to the ezusb device. It would tell the ezusb device to jump to it, so you would not be able to talk to it after that point, other than by telling the kernel to reset the hub port that the ezusb device is connected to, in which case, the keyspan_usa driver will again grab the device and trash it. I would also argue that searching for a lengthy bit string in file format and carefully zeroing it out is enough complexity so that the connection between the two pieces of information (the firmware integrated in the .o and the rest of the .o) are more than just aggregation. I'm not denying that you could imagine a case that is a gray area where the FSF's understood intention in writing the GPL as interpreted by a judge from the GPL _and other evidence_ under the four corner's rule may have been to allow it, but I don't think we're anywhere near it. But I agree that one could find some point where it's a judgement call. If you get sued and the judge agrees with the plaintiff, you can lose your house, you life's savings, etc. in statutory damages at, I believe, $50k per act of copying. If the judge agrees with you, well, then you have the satisfaction of winning that argument. I hope you appreciate the asymmetry of the risk and have similarly calibrate your standards for caution, at least when you advocate exposing others to these kinds of risks. >> you could just skip distribution of an extra file and have the rest of >> the functionality work. >That is exactly the case. The only change that must be made to remove that .h >file from the driver source is to tell the driver where the *new* location of >the correct firmware is. What do you mean "remove the .h file" from the .o and "tell the driver" (open your mouth and talk to the screen?). We are talking about a .o file. Copying the .o file is the act of infringement. Also, if you're going to respond further, please also answer the following question. Are you claiming that the FS
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
Here's a surprise. I think the problems with the keyspan
copyrights may have sprung from an administrative error. I notice that
the copyright notices in
linux-2.4.*/drivers/usb/serial/keyspan_usa{26,28,49}msg.h, which look
GPL compatible to me, look as if they were intended for
keyspan_usa{18x,19,28,28x,49w}_fw.h, since they refer to firmware
in their titles:
Copyright (c) 1998-2000 InnoSys Incorporated. All Rights Reserved
This file is available under a BSD-style copyright
Keyspan USB Async Firmware to run on Anchor EZ-USB
Yet, the keyspan*msg.h files have no firmware. The firmware
is in keyspan_usa*_fw.h.
Hugh, perhaps you could pass this up the chain of command
at Keyspan and see if they will simply grant permission to
replace the *_fw.h copyright notice with the one from *msg.h, which
is probably a lot simpler than having them spend lawyer and management
time on writing new terms.
I have cc'ed this to linux-kernel because there is a
current discussion going on there on this subject that I had just
responded to.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
>> = Aaron Lehmann <[EMAIL PROTECTED]>. > = Albert D. Cahalan <[EMAIL PROTECTED]> >> I believe this infringinges the copyrights of the authors >> of the code used in these drivers who released their code under GPL. >> Alan Cox, has gone on a campaign claiming that this is "mere aggregation" >As far as the Linux kernel is concerned, firmware images are >not software at all. They are large magic numbers that must >be written to the hardware. (they don't execute on your CPU) >If a driver writes 0x63f30e44 (4 bytes) to the card, no problem? >Fine, how about 0x52e590a84fc8231e (8 bytes) then? You can see >where this is leading I hope: 200 kB is perfectly fine. >It's obviously not size that matters. What matters is that Linux >doesn't transfer control into the firmware; that is, Linux does >not do a jump into firmware like this: >goto *((void*)firmware); I have never heard of this legal standard. A reference to some section of Title 17 in the United States Code (copyright), a relevant court precedent, etc. would be appreciated. I am not a lawyer, so please do not use this as legal advice. A software "license" typically grants you permission to do things that you would not otherwise be allowed to do with a copyrighted work in the absense of any permission (such as make a copy in most cases), provided that you meet certain conditions. Those conditions could be nearly anything. They're not necessarily limited to what is restricted by copyright. I used to think it was so limited due to copyright preemption of state law by title 17 of US Code section 301, http://www4.law.cornell.edu/uscode/17/301.html, but apparently this does not appear to be so according, for example, to http://www.richmond.edu/~jolt/v1i1/hardy.html#fn13, which references "Hines v. Davidowitz, 312 U.S. 52, 67 (1941), reaffirmed in Sears, Roebuck & Co. v. Stiffel Co., 376 U.S. 225, reh'g denied, 376 U.S. 973 (1964)", which I HAVE NOT READ, but I have read other things about this question and this just happens to be what I could dig up in a few seconds on google. If I recall correctly, doing something that is only legal if you had accepted an agreement is acceptance according to some provision of the uniform commercial code. (No, it's not new. I think at http://www.law.cornell.edu/ucc/2/2-206.html, section 1a, and the definition of goods to include "goods in action" in http://www.law.cornell.edu/ucc/2/2-105.html#Goods_2-105). From this, I hope we can agree that is possible to write copying conditions that prohibit make any copies of certain free software contained in the keyspan_usa drivers if the keyspan_usa firmware is also distributed in the same driver ".o" file, and that the question is simply whether the GPL does so. So, Albert, are you claiming that the FSF intended to allow a GPL'ed .o file that contains proprietary firmware for another microprocessor or are you claiming that FSF made a drafting error in the writing the GPL? If you believe you have found an error in the GPL, do you think a court would let you out of it given the four corners rule (basically using evidence of the understood meaning of an agreement to interpret what was actually written down)? On the question of whether this is nothing more than aggregation, the firmware works intimately with the device driver to produce a unitary result. The part of the driver that runs in the device and the CPU side speak a mutually agreed upon protocol, and the unitary result is that you do not have to preload the firmware as earlier versions of the driver required. You actually have to do some kernel development to remove the code. It's not simply the case that you could just skip distribution of an extra file and have the rest of the functionality work. In fact, even if you zeroed out the microcode, you would still not get the result of having the driver work (e.g., if you had loaded the code originally). Instead, the driver would fill the device with all zeroes. Greg Kroah-Hartman has already said he thinks removal is complicated enough that he does not want to voluntarily do it in 2.4. For these reasons, this situation is not just shipping two works next to each other (mere aggregation). I hope it should be clear now that the GPL can and does prohibit #include'ing this and that it is not mere aggregation. I also hope that people understand that while I think the stability argument for not including my fix in 2.4 (which everyone seems to like technically) is BS, I would be satisfied if the keyspan_usa drivers were now released under GPL-compatible copying conditions. However, it has now been weeks this has not been done. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
Doug Ledford wrote: Adam J. Richter wrote: On the question of whether this is nothing more than aggregation, Yes, on that very question, I would argue it is a mere aggregation. the firmware works intimately with the device driver to produce a unitary result. Irrelevant. The 1991 Abridged 6th Edition of _Black's Law Dictionary_ defines aggregation thusly (unfortunately, talking in terms of patent law, but it is the most authoratitive definition I have found so far): Aggregation: The combination of two or more elements in patent claims, each of which is unrelated and each of which performs separately and without cooperation , where combination does not define a composite integrate mechanism. Term means that the elements of a claimed combination are incapabile of co-operation to produce a unitary result, and in its true sense does not need prior art patents to support it. If you want to argue that a court will use a different definition of aggregation, then please explain why and quote that definition. Also, it's important not to forget the word mere. If the combination is anything *more* than aggregration, then it's not _merely_ aggregation. So, if you wanted to argue from the definition on webster.com: 1 : a group, body, or mass composed of many distinct parts or individuals 2 a : the collecting of units or parts into a mass or whole b : the condition of being so collected You have to argue that absolutely nothing more than this is being done. For example, the code the parts are not working together. All drivers work with some sort of firmware on their respective targets to produce a unitary result, even if that firmware is implemented with silicon (as a ROM BIOS that loads the proper firmware code, or as microcode/state hardware built into the chip(set) itself). As a closely similar device, think about the 1542 SCSI controller. [...] Yes. It would also be illegal to distribute a GPL'ed driver .o that #include'd that proprietary firmware. You actually have to do some kernel development to remove the [proprietary firmware from the keyspan_usa drivers]. That's because you are assuming that uploading garbage to the device is not an option. No. If I you change the driver to upload garbage, your userland loader that just looks for the unitialized device ID will not be able to get to the uninitialized device before the device driver claims the interface and trashes it. So, your supposed act of disaggregation by zeroing out the effected bytes did not fully restore the old functionality. By the way, I'm pretty sure that the situation is even worse. The modified driver would not just load garbage to the ezusb device. It would tell the ezusb device to jump to it, so you would not be able to talk to it after that point, other than by telling the kernel to reset the hub port that the ezusb device is connected to, in which case, the keyspan_usa driver will again grab the device and trash it. I would also argue that searching for a lengthy bit string in file format and carefully zeroing it out is enough complexity so that the connection between the two pieces of information (the firmware integrated in the .o and the rest of the .o) are more than just aggregation. I'm not denying that you could imagine a case that is a gray area where the FSF's understood intention in writing the GPL as interpreted by a judge from the GPL _and other evidence_ under the four corner's rule may have been to allow it, but I don't think we're anywhere near it. But I agree that one could find some point where it's a judgement call. If you get sued and the judge agrees with the plaintiff, you can lose your house, you life's savings, etc. in statutory damages at, I believe, $50k per act of copying. If the judge agrees with you, well, then you have the satisfaction of winning that argument. I hope you appreciate the asymmetry of the risk and have similarly calibrate your standards for caution, at least when you advocate exposing others to these kinds of risks. you could just skip distribution of an extra file and have the rest of the functionality work. That is exactly the case. The only change that must be made to remove that .h file from the driver source is to tell the driver where the *new* location of the correct firmware is. What do you mean remove the .h file from the .o and tell the driver (open your mouth and talk to the screen?). We are talking about a .o file. Copying the .o file is the act of infringement. Also, if you're going to respond further, please also answer the following question. Are you claiming that the FSF intended to allow a GPL'ed .o file that contains proprietary firmware for another microprocessor or are you claiming that FSF made a drafting error in the writing the GPL? Adam J
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
Larry McVoy wrote: On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote: Contracts for slavery are specifically not enforceable due to the 13th Amendment, and there is also a stronger question of formation Completely misses the point. THe point isn't about slavery, come on, Adam, it's about putting unenforceable things into contracts. The point is you have to agree to the contract that is the GPL to get the right to make a copy of a GPL'ed work. You raised the ridiculous example of slavery apparently as an analogy to the requirements of permissions on copying conditions that go beyond restrictions one is subject to anyway by copyright. The point is that you can make require someone to agree to conditions that go beyond the restrictions already imposed by copyright in exchange for permission to, for example, make a copy, so your argument about the boundaries of copyright is inapplicable. The GPL is enforceable. It's also about the concept of boundaries - if you think that that concept is not a legal one then why aren't all programs which are run on top of a GPLed kernel then GPLed? Apparently Linus felt that that was a sufficiently plausible gray area that he addressed it explicitly in /usr/src/linux/COPYING: | NOTE! This copyright does *not* cover user programs that use kernel | services by normal system calls - this is merely considered normal use | of the kernel, and does *not* fall under the heading of derived work. | Also note that the GPL below is copyrighted by the Free Software | Foundation, but the instance of code that it refers to (the Linux | kernel) is copyrighted by me and others who actually wrote it. I believe you could enforce copying conditions on a kernel where, in order to have the right to make a copy of the kernel, you agree only to run certain types of programs. I believe Windows CE has historically been licensed this way. I did not say that you cannot define boundaries and I also think you can even make inferences that a judge is likely to agree with. What I am saying is that in order to have the right to make a copy of the of the GPL'ed code in the keyspan_usa drivers, you must agree to everything the GPL requires, and those requirements do not have to be limited to the boundaries of the author's existing copyright. The GPL is a contract. If you don't agree to it, don't do anything with GPL'ed material that the copyright monopoly restricts. I am not a lawyer, so please do not rely on this as legal advice. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
Here's a surprise. I think the problems with the keyspan
copyrights may have sprung from an administrative error. I notice that
the copyright notices in
linux-2.4.*/drivers/usb/serial/keyspan_usa{26,28,49}msg.h, which look
GPL compatible to me, look as if they were intended for
keyspan_usa{18x,19,28,28x,49w}_fw.h, since they refer to firmware
in their titles:
Copyright (c) 1998-2000 InnoSys Incorporated. All Rights Reserved
This file is available under a BSD-style copyright
Keyspan USB Async Firmware to run on Anchor EZ-USB
Yet, the keyspan*msg.h files have no firmware. The firmware
is in keyspan_usa*_fw.h.
Hugh, perhaps you could pass this up the chain of command
at Keyspan and see if they will simply grant permission to
replace the *_fw.h copyright notice with the one from *msg.h, which
is probably a lot simpler than having them spend lawyer and management
time on writing new terms.
I have cc'ed this to linux-kernel because there is a
current discussion going on there on this subject that I had just
responded to.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 Free Software For The Rest Of Us.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 sluggish under fork load
>The fact that 2.4.4 gives the whole timeslice to the child >is just bogus to begin with. I only did that because I could not find another way to make the child run first that worked in practice. I tried other things before that. Since Peter Osterlund's SCHED_YIELD thing works, we no longer have to give all of the CPU to the child. The scheduler time slices are currently enormous, so as long as the child gets even one clock tick before the parent runs, it should reach the exec() if that is its plan. 1 tick = 10ms = 10 million cycles on a 1GHz CPU, which should be enough time to encrypt my /boot/vmlinux in twofish if it's in RAM. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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(?): bash-2.05/jobs.c loses interrupts
>> Linux-2.4.4 has a change, for which I must accept blame,
>> where fork() runs the child first, reducing unnecessary copy-on-write
>> page duplications, because the child will usually promptly do an
>> exec(). I understand this is pretty standard in most unixes.
>>
>> Peter Osterlund noticed an annoying side effect of this,
>> which I think is a bash bug. He wrote:
>>
>> > Another thing is that the bash loop "while true ; do /bin/true ; done" is
>> > not possible to interrupt with ctrl-c.
>>
>> I have reproduced this problem on a single CPU system.
>> I also modified my kernel to sometimes run the fork child first
>> and sometimes not. In that case, that loop would sometimes
>> abort on a control-C and sometimes ignore it, but ignoring it
>> would not make the loop less likely to abort on another control-C.
>> I'm pretty sure the control-C was being delivered only to the child
>> due to a race condition in bash, which may be mandated by posix.
>Did you reconfigure and rebuild bash on your machine running the 2.4
>kernel, or just use a bash binary built on a previous kernel version?
>Bash has an autoconf test that will, if it detects the need to do so,
>force the job control code to synchronize between parent and child
>when setting up the process group for a new pipeline. It may be the
>case that you have to reconfigure and rebuild bash to enable that code.
>Look for PGRP_PIPE in config.h.
Rebuilding bash from pristine 2.05 sources under such a kernel
does *not* solve the problem. PGRP_PIPE is undef'ed in the resulting
config.h.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 fork.c changes cause linuxconf to fail
Jeff Garzik wrote: >Michael Pakovic wrote: >> The changes to kernel/fork.c from 2.4.4-pre1 to 2.4.4-pre3 (and in >> 2.4.4) cause the RedHat 6.2 linuxconf utility to fail with the message >> "broken pipe". The linuxconf utility will run the first time, but all >> subsequent runs give the "broken pipe" error. The error message is >> generated as a result of a fflush command in linuxconf. I can provide >> more information upon request. >This patch is definitely breaking things, but AFAIK the fork.c change >only breaks buggy applications... Adam would you say that assertion is >correct? Yes, and they're probably all bugs that were biting us sporadically before. We should take the opportunity to squash them while they're out in the open. We'd better squash those bugs quickly too, because Peter Osterlund has produced a patch that runs the child first without giving all of the CPU allocation to the child, and this apparently is enough to eliminate the problems people have been seeing while retaining the benefit of running the child first. So, I imagine 2.4.5 will not expose these problems. Peter emailed his patch to linux-kernel, but, for some reason, I have only seen the copy that was cc'ed directly to me. I have tried his patch and added two lines so that the child is still run first even when current->counter == 0 (stealing some CPU allocation to do so). I have not benchmarked it, but I do know from testing that without my addition, the parent would still run first about a 1/4-1/5th of the time (consistent with the Linux's allocation of 5 ticks to a regular priority process), and, with this patch, that reduces to about 1/30th. If the performance benefit of running the child first is noticible on bencharks, it should be worth doing it the other 20% of the time as well. Anyhow, here is my modification of Peter Osterlund's patch, against 2.4.4: --- linux-2.4.4/kernel/fork.c Thu Apr 26 06:11:17 2001 +++ linux/kernel/fork.c Mon Apr 30 00:37:30 2001 @@ -666,16 +666,20 @@ p->pdeath_signal = 0; /* -* Give the parent's dynamic priority entirely to the child. The -* total amount of dynamic priorities in the system doesn't change -* (more scheduling fairness), but the child will run first, which -* is especially useful in avoiding a lot of copy-on-write faults -* if the child for a fork() just wants to do a few simple things -* and then exec(). This is only important in the first timeslice. -* In the long run, the scheduling behavior is unchanged. +* "share" dynamic priority between parent and child, thus the +* total amount of dynamic priorities in the system doesn't change, +* more scheduling fairness. The parent yields to let the child run +* first, which is especially useful in avoiding a lot of +* copy-on-write faults if the child for a fork() just wants to do a +* few simple things and then exec(). This is only important in the +* first timeslice. In the long run, the scheduling behavior is +* unchanged. */ - p->counter = current->counter; - current->counter = 0; + p->counter = (current->counter + 1) >> 1; + if (p->counter == 0) + p->counter = 1; + current->counter >>= 1; + current->policy |= SCHED_YIELD; current->need_resched = 1; /* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 fork.c changes cause linuxconf to fail
Jeff Garzik wrote: Michael Pakovic wrote: The changes to kernel/fork.c from 2.4.4-pre1 to 2.4.4-pre3 (and in 2.4.4) cause the RedHat 6.2 linuxconf utility to fail with the message broken pipe. The linuxconf utility will run the first time, but all subsequent runs give the broken pipe error. The error message is generated as a result of a fflush command in linuxconf. I can provide more information upon request. This patch is definitely breaking things, but AFAIK the fork.c change only breaks buggy applications... Adam would you say that assertion is correct? Yes, and they're probably all bugs that were biting us sporadically before. We should take the opportunity to squash them while they're out in the open. We'd better squash those bugs quickly too, because Peter Osterlund has produced a patch that runs the child first without giving all of the CPU allocation to the child, and this apparently is enough to eliminate the problems people have been seeing while retaining the benefit of running the child first. So, I imagine 2.4.5 will not expose these problems. Peter emailed his patch to linux-kernel, but, for some reason, I have only seen the copy that was cc'ed directly to me. I have tried his patch and added two lines so that the child is still run first even when current-counter == 0 (stealing some CPU allocation to do so). I have not benchmarked it, but I do know from testing that without my addition, the parent would still run first about a 1/4-1/5th of the time (consistent with the Linux's allocation of 5 ticks to a regular priority process), and, with this patch, that reduces to about 1/30th. If the performance benefit of running the child first is noticible on bencharks, it should be worth doing it the other 20% of the time as well. Anyhow, here is my modification of Peter Osterlund's patch, against 2.4.4: --- linux-2.4.4/kernel/fork.c Thu Apr 26 06:11:17 2001 +++ linux/kernel/fork.c Mon Apr 30 00:37:30 2001 @@ -666,16 +666,20 @@ p-pdeath_signal = 0; /* -* Give the parent's dynamic priority entirely to the child. The -* total amount of dynamic priorities in the system doesn't change -* (more scheduling fairness), but the child will run first, which -* is especially useful in avoiding a lot of copy-on-write faults -* if the child for a fork() just wants to do a few simple things -* and then exec(). This is only important in the first timeslice. -* In the long run, the scheduling behavior is unchanged. +* share dynamic priority between parent and child, thus the +* total amount of dynamic priorities in the system doesn't change, +* more scheduling fairness. The parent yields to let the child run +* first, which is especially useful in avoiding a lot of +* copy-on-write faults if the child for a fork() just wants to do a +* few simple things and then exec(). This is only important in the +* first timeslice. In the long run, the scheduling behavior is +* unchanged. */ - p-counter = current-counter; - current-counter = 0; + p-counter = (current-counter + 1) 1; + if (p-counter == 0) + p-counter = 1; + current-counter = 1; + current-policy |= SCHED_YIELD; current-need_resched = 1; /* - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch(?): bash-2.05/jobs.c loses interrupts
Linux-2.4.4 has a change, for which I must accept blame, where fork() runs the child first, reducing unnecessary copy-on-write page duplications, because the child will usually promptly do an exec(). I understand this is pretty standard in most unixes. Peter Osterlund noticed an annoying side effect of this, which I think is a bash bug. He wrote: Another thing is that the bash loop while true ; do /bin/true ; done is not possible to interrupt with ctrl-c. I have reproduced this problem on a single CPU system. I also modified my kernel to sometimes run the fork child first and sometimes not. In that case, that loop would sometimes abort on a control-C and sometimes ignore it, but ignoring it would not make the loop less likely to abort on another control-C. I'm pretty sure the control-C was being delivered only to the child due to a race condition in bash, which may be mandated by posix. Did you reconfigure and rebuild bash on your machine running the 2.4 kernel, or just use a bash binary built on a previous kernel version? Bash has an autoconf test that will, if it detects the need to do so, force the job control code to synchronize between parent and child when setting up the process group for a new pipeline. It may be the case that you have to reconfigure and rebuild bash to enable that code. Look for PGRP_PIPE in config.h. Rebuilding bash from pristine 2.05 sources under such a kernel does *not* solve the problem. PGRP_PIPE is undef'ed in the resulting config.h. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 sluggish under fork load
The fact that 2.4.4 gives the whole timeslice to the child is just bogus to begin with. I only did that because I could not find another way to make the child run first that worked in practice. I tried other things before that. Since Peter Osterlund's SCHED_YIELD thing works, we no longer have to give all of the CPU to the child. The scheduler time slices are currently enormous, so as long as the child gets even one clock tick before the parent runs, it should reach the exec() if that is its plan. 1 tick = 10ms = 10 million cycles on a 1GHz CPU, which should be enough time to encrypt my /boot/vmlinux in twofish if it's in RAM. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 sluggish under fork load
On rereading Linus's message, I see that he indicated that "while true ; do /bin/true ; done" was known to be a bash bug, not just a suggested possibility. Sorry for acting as if this were a new discovery. Anyhow, I hope that at least the proposed bash patch that I submitted may be of some use. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch(?): bash-2.05/jobs.c loses interrupts
Linux-2.4.4 has a change, for which I must accept blame,
where fork() runs the child first, reducing unnecessary copy-on-write
page duplications, because the child will usually promptly do an
exec(). I understand this is pretty standard in most unixes.
Peter Osterlund noticed an annoying side effect of this,
which I think is a bash bug. He wrote:
> Another thing is that the bash loop "while true ; do /bin/true ; done" is
> not possible to interrupt with ctrl-c.
I have reproduced this problem on a single CPU system.
I also modified my kernel to sometimes run the fork child first
and sometimes not. In that case, that loop would sometimes
abort on a control-C and sometimes ignore it, but ignoring it
would not make the loop less likely to abort on another control-C.
I'm pretty sure the control-C was being delivered only to the child
due to a race condition in bash, which may be mandated by posix.
I am pretty sure that the reason for this behavior is that
is that make_child() in bash-2.05/jobs.c has the child define itself
as a new process group and set the terminal's process group to it.
The parent will eventually also set its pgid to the child's pid when
it finally runs, but, in this example, /bin/true will probably run to
completion before that. So, there is a period of time when the
child has set itself up as a distinct process group and pointed
the terminal to it, but the parent has not yet joined that process
group, so only the child will receive a ^C that happens during this
time. This is the case basically 100% of the time if you do
a "while true ; do /bin/true ; done" loop under linux-2.4.4 on a
1GHz Pentium III (slower CPU's may not have enough cycles per time
slice to make this race happen reliably, as I do not see it on a
similar 866MHz Pentium III).
I think the correct fix is for bash to have the parent
set the controlling process of the terminal, not to have the child
do it. In fact, there are comments to this effect in bash-2.05/jobs.c,
although they do not explain why this is not currently done. I have
attached a patch which is my guess at how to implement the change.
I know it fixes the "while true ; do /bin/true ; done" example.
I think that there may be some other loose ends to clean up, though.
For example, there is now potentially a time window when only the
parent will receive a control-C, so it may be necessary for the
parent to signal the child if the parent sees a signal as soon as
it has unblocked them.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- bash-2.05/jobs.cMon Mar 26 10:08:24 2001
+++ bash/jobs.c Sat Apr 28 23:51:33 2001
@@ -1202,17 +1202,6 @@
#if defined (PGRP_PIPE)
if (pipeline_pgrp == mypid)
{
-#endif
- /* By convention (and assumption above), if
-pipeline_pgrp == shell_pgrp, we are making a child for
-command substitution.
-In this case, we don't want to give the terminal to the
-shell's process group (we could be in the middle of a
-pipeline, for example). */
- if (async_p == 0 && pipeline_pgrp != shell_pgrp)
- give_terminal_to (pipeline_pgrp, 0);
-
-#if defined (PGRP_PIPE)
pipe_read (pgrp_pipe);
}
#endif
@@ -1251,9 +1240,14 @@
if (pipeline_pgrp == 0)
{
pipeline_pgrp = pid;
- /* Don't twiddle terminal pgrps in the parent! This is the bug,
-not the good thing of twiddling them in the child! */
- /* give_terminal_to (pipeline_pgrp, 0); */
+ /* By convention (and assumption above), if
+pipeline_pgrp == shell_pgrp, we are making a child for
+command substitution.
+In this case, we don't want to give the terminal to the
+shell's process group (we could be in the middle of a
+pipeline, for example). */
+ if (async_p == 0 && pipeline_pgrp != shell_pgrp)
+ give_terminal_to (pipeline_pgrp, 0);
}
/* This is done on the recommendation of the Rationale section of
the POSIX 1003.1 standard, where it discusses job control and
Re: 2.4.4 sluggish under fork load
Peter Osterlund wrote: > Another thing is that the bash loop "while true ; do /bin/true ; done" is > not possible to interrupt with ctrl-c. I have reproduced this on a uniprocessor machine and determined that it is a bash bug. I will submit a bash bug report and sample patch that fixes the problem (but may be incorrect in other ways), and will cc it to linux-kernel. Look for the subject "Patch(?): bash-2.05/jobs.c loses interrupts." I have not yet investigated the other report of "sluggish" behavior. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 sluggish under fork load
Peter Osterlund wrote: Another thing is that the bash loop while true ; do /bin/true ; done is not possible to interrupt with ctrl-c. I have reproduced this on a uniprocessor machine and determined that it is a bash bug. I will submit a bash bug report and sample patch that fixes the problem (but may be incorrect in other ways), and will cc it to linux-kernel. Look for the subject Patch(?): bash-2.05/jobs.c loses interrupts. I have not yet investigated the other report of sluggish behavior. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch(?): bash-2.05/jobs.c loses interrupts
Linux-2.4.4 has a change, for which I must accept blame,
where fork() runs the child first, reducing unnecessary copy-on-write
page duplications, because the child will usually promptly do an
exec(). I understand this is pretty standard in most unixes.
Peter Osterlund noticed an annoying side effect of this,
which I think is a bash bug. He wrote:
Another thing is that the bash loop while true ; do /bin/true ; done is
not possible to interrupt with ctrl-c.
I have reproduced this problem on a single CPU system.
I also modified my kernel to sometimes run the fork child first
and sometimes not. In that case, that loop would sometimes
abort on a control-C and sometimes ignore it, but ignoring it
would not make the loop less likely to abort on another control-C.
I'm pretty sure the control-C was being delivered only to the child
due to a race condition in bash, which may be mandated by posix.
I am pretty sure that the reason for this behavior is that
is that make_child() in bash-2.05/jobs.c has the child define itself
as a new process group and set the terminal's process group to it.
The parent will eventually also set its pgid to the child's pid when
it finally runs, but, in this example, /bin/true will probably run to
completion before that. So, there is a period of time when the
child has set itself up as a distinct process group and pointed
the terminal to it, but the parent has not yet joined that process
group, so only the child will receive a ^C that happens during this
time. This is the case basically 100% of the time if you do
a while true ; do /bin/true ; done loop under linux-2.4.4 on a
1GHz Pentium III (slower CPU's may not have enough cycles per time
slice to make this race happen reliably, as I do not see it on a
similar 866MHz Pentium III).
I think the correct fix is for bash to have the parent
set the controlling process of the terminal, not to have the child
do it. In fact, there are comments to this effect in bash-2.05/jobs.c,
although they do not explain why this is not currently done. I have
attached a patch which is my guess at how to implement the change.
I know it fixes the while true ; do /bin/true ; done example.
I think that there may be some other loose ends to clean up, though.
For example, there is now potentially a time window when only the
parent will receive a control-C, so it may be necessary for the
parent to signal the child if the parent sees a signal as soon as
it has unblocked them.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 Free Software For The Rest Of Us.
--- bash-2.05/jobs.cMon Mar 26 10:08:24 2001
+++ bash/jobs.c Sat Apr 28 23:51:33 2001
@@ -1202,17 +1202,6 @@
#if defined (PGRP_PIPE)
if (pipeline_pgrp == mypid)
{
-#endif
- /* By convention (and assumption above), if
-pipeline_pgrp == shell_pgrp, we are making a child for
-command substitution.
-In this case, we don't want to give the terminal to the
-shell's process group (we could be in the middle of a
-pipeline, for example). */
- if (async_p == 0 pipeline_pgrp != shell_pgrp)
- give_terminal_to (pipeline_pgrp, 0);
-
-#if defined (PGRP_PIPE)
pipe_read (pgrp_pipe);
}
#endif
@@ -1251,9 +1240,14 @@
if (pipeline_pgrp == 0)
{
pipeline_pgrp = pid;
- /* Don't twiddle terminal pgrps in the parent! This is the bug,
-not the good thing of twiddling them in the child! */
- /* give_terminal_to (pipeline_pgrp, 0); */
+ /* By convention (and assumption above), if
+pipeline_pgrp == shell_pgrp, we are making a child for
+command substitution.
+In this case, we don't want to give the terminal to the
+shell's process group (we could be in the middle of a
+pipeline, for example). */
+ if (async_p == 0 pipeline_pgrp != shell_pgrp)
+ give_terminal_to (pipeline_pgrp, 0);
}
/* This is done on the recommendation of the Rationale section of
the POSIX 1003.1 standard, where it discusses job control and
Re: 2.4.4 sluggish under fork load
On rereading Linus's message, I see that he indicated that while true ; do /bin/true ; done was known to be a bash bug, not just a suggested possibility. Sorry for acting as if this were a new discovery. Anyhow, I hope that at least the proposed bash patch that I submitted may be of some use. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH: linux-2.4.4/drivers/video/Config.in offered drivers that would not compile on your architecture
linux-2.4.4/drivers/video/Config.in allowed the user to select some Atari and SuperH architecture video drivers that would not compile on other architectures. This patch causes those drivers to be offered only on architectures on which they will compile. By the way, this patch is much simpler than it looks. It just adds two "if" statements. The rest of the chanages is just the corresponding reindentation. -- Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." --- linux-2.4.4/drivers/video/Config.in Fri Apr 13 20:31:32 2001 +++ linux/drivers/video/Config.in Fri Apr 27 23:20:51 2001 @@ -98,10 +98,13 @@ bool 'CGsix (GX,TurboGX) support' CONFIG_FB_CGSIX fi fi - bool ' Epson 1355 framebuffer support' CONFIG_FB_E1355 - if [ "$CONFIG_FB_E1355" = "y" ]; then - hex 'Register Base Address' CONFIG_E1355_REG_BASE a800 - hex 'Framebuffer Base Address' CONFIG_E1355_FB_BASE a820 + + if [ "$CONFIG_SUPERH" = "y" ]; then + bool ' Epson 1355 framebuffer support' CONFIG_FB_E1355 + if [ "$CONFIG_FB_E1355" = "y" ]; then + hex 'Register Base Address' CONFIG_E1355_REG_BASE a800 + hex 'Framebuffer Base Address' CONFIG_E1355_FB_BASE a820 + fi fi if [ "$CONFIG_SH_DREAMCAST" = "y" ]; then tristate ' Dreamcast Frame Buffer support' CONFIG_FB_DC @@ -179,10 +182,12 @@ tristate '32 bpp packed pixels support' CONFIG_FBCON_CFB32 tristate 'Amiga bitplanes support' CONFIG_FBCON_AFB tristate 'Amiga interleaved bitplanes support' CONFIG_FBCON_ILBM - tristate 'Atari interleaved bitplanes (2 planes) support' CONFIG_FBCON_IPLAN2P2 - tristate 'Atari interleaved bitplanes (4 planes) support' CONFIG_FBCON_IPLAN2P4 - tristate 'Atari interleaved bitplanes (8 planes) support' CONFIG_FBCON_IPLAN2P8 -# tristate 'Atari interleaved bitplanes (16 planes) support' CONFIG_FBCON_IPLAN2P16 + if [ "$CONFIG_ATARI" = "y" ]; then +tristate 'Atari interleaved bitplanes (2 planes) support' +CONFIG_FBCON_IPLAN2P2 +tristate 'Atari interleaved bitplanes (4 planes) support' +CONFIG_FBCON_IPLAN2P4 +tristate 'Atari interleaved bitplanes (8 planes) support' +CONFIG_FBCON_IPLAN2P8 +# tristate 'Atari interleaved bitplanes (16 planes) support' +CONFIG_FBCON_IPLAN2P16 + fi tristate 'Mac variable bpp packed pixels support' CONFIG_FBCON_MAC tristate 'VGA 16-color planar support' CONFIG_FBCON_VGA_PLANES tristate 'VGA characters/attributes support' CONFIG_FBCON_VGA
PATCH(??): linux-2.4.4/drivers/scsi/pci2220i.c referred to undefined routine scsi_set_pci_info
linux-2.4.4 changes one line in drivers/scsi/pci2220i.c that used to call scsi_set_pci_device to call the undefined routine scsi_set_pci_info. That is the only change to pci2220i.c in linux-2.4.4. I don't know what the intention of this change was. Perhaps a renaming of scsi_set_pci_device is in the works, or perhaps somebody accidentally deleted a line in an editor and decided to try typing it in from memory. Anyhow, if reversing that change is the correct course of action, here is a patch to that effect. -- Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." --- linux-2.4.4/drivers/scsi/pci2220i.c Fri Apr 27 13:59:19 2001 +++ linux/drivers/scsi/pci2220i.c Sat Apr 28 01:16:37 2001 @@ -2657,7 +2676,7 @@ for ( z = 0; z < BIGD_MAXDRIVES; z++ ) DiskMirror[z].status = inb_p (padapter->regScratchPad + BIGD_RAID_0_STATUS + z); - scsi_set_pci_info(pshost, pcidev); + scsi_set_pci_device(pshost, pcidev); pshost->max_id = padapter->numberOfDrives; padapter->failRegister = inb_p (padapter->regScratchPad + BIGD_ALARM_IMAGE); for ( z = 0; z < padapter->numberOfDrives; z++ )
PATCH(??): linux-2.4.4/drivers/scsi/pci2220i.c referred to undefined routine scsi_set_pci_info
linux-2.4.4 changes one line in drivers/scsi/pci2220i.c that used to call scsi_set_pci_device to call the undefined routine scsi_set_pci_info. That is the only change to pci2220i.c in linux-2.4.4. I don't know what the intention of this change was. Perhaps a renaming of scsi_set_pci_device is in the works, or perhaps somebody accidentally deleted a line in an editor and decided to try typing it in from memory. Anyhow, if reversing that change is the correct course of action, here is a patch to that effect. -- Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. --- linux-2.4.4/drivers/scsi/pci2220i.c Fri Apr 27 13:59:19 2001 +++ linux/drivers/scsi/pci2220i.c Sat Apr 28 01:16:37 2001 @@ -2657,7 +2676,7 @@ for ( z = 0; z BIGD_MAXDRIVES; z++ ) DiskMirror[z].status = inb_p (padapter-regScratchPad + BIGD_RAID_0_STATUS + z); - scsi_set_pci_info(pshost, pcidev); + scsi_set_pci_device(pshost, pcidev); pshost-max_id = padapter-numberOfDrives; padapter-failRegister = inb_p (padapter-regScratchPad + BIGD_ALARM_IMAGE); for ( z = 0; z padapter-numberOfDrives; z++ )
PATCH: linux-2.4.4/drivers/video/Config.in offered drivers that would not compile on your architecture
linux-2.4.4/drivers/video/Config.in allowed the user to select some Atari and SuperH architecture video drivers that would not compile on other architectures. This patch causes those drivers to be offered only on architectures on which they will compile. By the way, this patch is much simpler than it looks. It just adds two if statements. The rest of the chanages is just the corresponding reindentation. -- Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. --- linux-2.4.4/drivers/video/Config.in Fri Apr 13 20:31:32 2001 +++ linux/drivers/video/Config.in Fri Apr 27 23:20:51 2001 @@ -98,10 +98,13 @@ bool 'CGsix (GX,TurboGX) support' CONFIG_FB_CGSIX fi fi - bool ' Epson 1355 framebuffer support' CONFIG_FB_E1355 - if [ $CONFIG_FB_E1355 = y ]; then - hex 'Register Base Address' CONFIG_E1355_REG_BASE a800 - hex 'Framebuffer Base Address' CONFIG_E1355_FB_BASE a820 + + if [ $CONFIG_SUPERH = y ]; then + bool ' Epson 1355 framebuffer support' CONFIG_FB_E1355 + if [ $CONFIG_FB_E1355 = y ]; then + hex 'Register Base Address' CONFIG_E1355_REG_BASE a800 + hex 'Framebuffer Base Address' CONFIG_E1355_FB_BASE a820 + fi fi if [ $CONFIG_SH_DREAMCAST = y ]; then tristate ' Dreamcast Frame Buffer support' CONFIG_FB_DC @@ -179,10 +182,12 @@ tristate '32 bpp packed pixels support' CONFIG_FBCON_CFB32 tristate 'Amiga bitplanes support' CONFIG_FBCON_AFB tristate 'Amiga interleaved bitplanes support' CONFIG_FBCON_ILBM - tristate 'Atari interleaved bitplanes (2 planes) support' CONFIG_FBCON_IPLAN2P2 - tristate 'Atari interleaved bitplanes (4 planes) support' CONFIG_FBCON_IPLAN2P4 - tristate 'Atari interleaved bitplanes (8 planes) support' CONFIG_FBCON_IPLAN2P8 -# tristate 'Atari interleaved bitplanes (16 planes) support' CONFIG_FBCON_IPLAN2P16 + if [ $CONFIG_ATARI = y ]; then +tristate 'Atari interleaved bitplanes (2 planes) support' +CONFIG_FBCON_IPLAN2P2 +tristate 'Atari interleaved bitplanes (4 planes) support' +CONFIG_FBCON_IPLAN2P4 +tristate 'Atari interleaved bitplanes (8 planes) support' +CONFIG_FBCON_IPLAN2P8 +# tristate 'Atari interleaved bitplanes (16 planes) support' +CONFIG_FBCON_IPLAN2P16 + fi tristate 'Mac variable bpp packed pixels support' CONFIG_FBCON_MAC tristate 'VGA 16-color planar support' CONFIG_FBCON_VGA_PLANES tristate 'VGA characters/attributes support' CONFIG_FBCON_VGA
Suggestion for module .init.{text,data} sections
A while ago, on linux-kernel, we had a discussion about adding support for __initdata and __init in modules. Somebody (whose name escapes me) had implemented it by essentially adding a vmrealloc() facility in the kernel. I think I've thought of a simpler way, that would require almost no kernel changes. Have insmod split the module into two parts and load them as two modules. First, create the regular part of the module as usual (without .data.init and .text.init), except with no initialization routine set. Second, create a module from the .data.init and the .text.init sections (if any), with it's initialization routine set to the module's init_module routine, even if that routine resides in the first module. Third, there will be cross references between these two modules, so will generally be necessary to resolve the relocations before loading either module. Fourth, load the first module. This will always succeed, since there is no initialization routine to fail. Fifth, load the second module, the one made of .data.init and .text.init. It will run the actual module_init function. If the module initialization routine fails, both modules are unloaded and the usual failure behavior happens. If the module initialization succeeds, the ".init" module (the second module) is unloaded. Potentially, this could save some memory footprint in highly modularized systems and cleanup linux/include/init.h. I guess I would imagine this as a potential 2.5 feature, or perhaps as a default-off option intended soley for stress testing in 2.4. I started looking through the modutils sources, but I was a little disappointed to discover that it is ELF-specific rather than written in bfd, as I am pretty unfamiliar with ELF innards but a little more conversant in bfd. Maybe I'll take a whack at it yet, but I figure I should at least pass the idea along and see if I'm overlooking anything obvious. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: #define HZ 1024 -- negative effects?
I have not tried it, but I would think that setting HZ to 1024 should make a big improvement in responsiveness. Currently, the time slice allocated to a standard Linux process is 5*HZ, or 50ms when HZ is 100. That means that you will notice keystrokes being echoed slowly in X when you have just one or two running processes, no matter how fast your CPU is, assuming these processes do not complete in that time. Setting HZ to 1000 should improve that a lot, and the cost of the extra context switches should still be quite small in comparison to time slice length (a 1ms time slize = 1 million cycles on a 1GHz processor or a maximum of 532kB of memory bus utilization on a PC-133 bus that transfer 8 bytes on an averge of every two cycles based to 5-1-1-1 memory timing). I would think this would be particularly noticible for internet service providers that offer shell accounts or VNC accounts (like WorkSpot and LastFoot). A few of other approaches to consider if one is feeling more ambitious are: 1. Make the time slice size scale to the number of currently runnable processes (more precisely, threads) divided by number of CPU's. I posted something about this a week or two ago. This way, responsiveness is maintained, but people who are worried about the extra context switch and caching effects can rest assured that this shorter time slices would only happen when responsiveness would otherwise be bad. 2. Like #1, but only shrink the time slices when at least one of the runnable processes is running at regular or high CPU priority. 3. Have the current process give up the CPU as soon as another process awaiting the CPU has a higher current->count value. That would increase the number of context switches like increasing HZ by 5X (with basically the same trade-offs), but without increasing the number of timer interrupts. By itself, this is probably not worth the complexity. 4. Similar to #3, but only switch on current->count!=0 when another process has just become unblocked. 5. I haven't looked at the code closely enough yet, but I tend to wonder about the usefulness of having "ticks" when you have a real time clock and avoid unnecessary "tick" interrupts by just accounting based on microroseconds or something. I understand there may be issues of inaccuracy due to not knowing exactly where you are in the current RTC tick, and the cost of the unnecessary tick interrupts is probably pretty small. I mention this just for completeness. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Suggestion for module .init.{text,data} sections
A while ago, on linux-kernel, we had a discussion about adding support for __initdata and __init in modules. Somebody (whose name escapes me) had implemented it by essentially adding a vmrealloc() facility in the kernel. I think I've thought of a simpler way, that would require almost no kernel changes. Have insmod split the module into two parts and load them as two modules. First, create the regular part of the module as usual (without .data.init and .text.init), except with no initialization routine set. Second, create a module from the .data.init and the .text.init sections (if any), with it's initialization routine set to the module's init_module routine, even if that routine resides in the first module. Third, there will be cross references between these two modules, so will generally be necessary to resolve the relocations before loading either module. Fourth, load the first module. This will always succeed, since there is no initialization routine to fail. Fifth, load the second module, the one made of .data.init and .text.init. It will run the actual module_init function. If the module initialization routine fails, both modules are unloaded and the usual failure behavior happens. If the module initialization succeeds, the .init module (the second module) is unloaded. Potentially, this could save some memory footprint in highly modularized systems and cleanup linux/include/init.h. I guess I would imagine this as a potential 2.5 feature, or perhaps as a default-off option intended soley for stress testing in 2.4. I started looking through the modutils sources, but I was a little disappointed to discover that it is ELF-specific rather than written in bfd, as I am pretty unfamiliar with ELF innards but a little more conversant in bfd. Maybe I'll take a whack at it yet, but I figure I should at least pass the idea along and see if I'm overlooking anything obvious. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
>>> = Rik van Riel <[EMAIL PROTECTED]> >> = Adam J. Richter <[EMAIL PROTECTED]> > = Michael O'Reilly <[EMAIL PROTECTED]> >> Rik van Riel <[EMAIL PROTECTED]> writes, regarding the idea >> of having do_fork() give all of the parent's remaining time slice to >> the newly created child: >> >>>It could upset programs which use threads to handle >>>relatively IO poor things (like, waiting on disk IO in a >>>thread, like glibc does to fake async file IO). >> >> Good point. >Is it really? If a program is using thread to handle IO things, >then: >a) It's not going to create a thread for every IO! So I think >the argument is suprious anyway. Maybe not that often, but, from my incomplete understanding of linux/kernel/sched.c, it looks like it can be a really long time before the recalculate loop in schedule() gets called. Currently, the time slice of a regular "nice 0" process in Linux is 50ms (NICE_TO_TICKS(20) = 5, and each tick is 10ms). So, if you're on a multiuser system or you're running some parallel algorithm that uses a bunch of threads so that nobody has to rendezvous to block on IO, then this could on the order of one second. Tangential note: I think the 50ms process time slice makes Linux boxes that have a lot of runnable threads or processes unresponsive in ways that will not show up in most benchmarks, making things like multi-user VNC servers much less scalable than they should be. I wish the Linux "recalculate" loop would scale the time slices to #cpu's/#runnable processes, such as by replacing changing the "p->counter = ..." line in the "recalculate" loop in schedule() to something like this: int runnables; ... runnables = 0; list_for_each(tmp, _head) runnables++; runnables /= smp_num_cpus; runnables = runnables ? runnables : 1; /* prevent division by 0 */ for_each_task(p) p->counter = (p->counter >> 1) + (NICE_TO_TICKS(p->nice) / runnables) + 1; (the "+ 1" at the end would ensure that the increment is never zero, even if runnables is very high.) Anyhow, getting back to the topic at hand... >b) You _still_ want the child to run first. The child >will start the I/O and block, then switching back >to the parent. This maximises the I/O thruput without >costing you any CPU. (Reasoning: The child running >2nd will increase the latency which automatically >reduces the number of ops/second you can get). Absolutely. I never said that it would be a good idea run the parent first in that case and Rik didn't either. Under Rik's idea, the child would still run first, but the parent could retain some CPU priority, so that it could get around to running again before the next call to the "recalculate" loop in schedule(), which might be 1 second if the system has 20 runnable runnable threads. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
Rik van Riel <[EMAIL PROTECTED]> writes, regarding the idea
of having do_fork() give all of the parent's remaining time slice to
the newly created child:
>It could upset programs which use threads to handle
>relatively IO poor things (like, waiting on disk IO in a
>thread, like glibc does to fake async file IO).
Good point.
[...]
>If it turns out to be beneficial to run the child first (you
>can measure this), why not leave everything the same as it is
>now but have do_fork() "switch threads" internally ?
That is an elegant idea. Not only would you save a few cycles by
avoiding what's left of the context switch, but, more imporantly, you
would be sure that no intervening process could be selected to run
between the parent giving up the CPU and the child running (which
could otherwise waste an additional full context swtich). Also, you
then would not necessarily have to make the parent give up all of its
remaining time slice. These two characteristics means that future
tweaks to the scheduler would be much less likely to accidentally
defeat running of the child first.
As far code cleanliness goes, you get to delete a line
from do_fork ("current->need_resched = 1;"), but I think that's about
it. You might even be able to avoid adding "current = p;" to do_fork
by having newly allocating task_struct assume the identity of the
parent and making the changes to "current", although I wonder
if anything else points to the current task or if that might
screw up any interrupts that occur during that process.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
Rik van Riel [EMAIL PROTECTED] writes, regarding the idea
of having do_fork() give all of the parent's remaining time slice to
the newly created child:
It could upset programs which use threads to handle
relatively IO poor things (like, waiting on disk IO in a
thread, like glibc does to fake async file IO).
Good point.
[...]
If it turns out to be beneficial to run the child first (you
can measure this), why not leave everything the same as it is
now but have do_fork() "switch threads" internally ?
That is an elegant idea. Not only would you save a few cycles by
avoiding what's left of the context switch, but, more imporantly, you
would be sure that no intervening process could be selected to run
between the parent giving up the CPU and the child running (which
could otherwise waste an additional full context swtich). Also, you
then would not necessarily have to make the parent give up all of its
remaining time slice. These two characteristics means that future
tweaks to the scheduler would be much less likely to accidentally
defeat running of the child first.
As far code cleanliness goes, you get to delete a line
from do_fork ("current-need_resched = 1;"), but I think that's about
it. You might even be able to avoid adding "current = p;" to do_fork
by having newly allocating task_struct assume the identity of the
parent and making the changes to "current", although I wonder
if anything else points to the current task or if that might
screw up any interrupts that occur during that process.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
= Rik van Riel [EMAIL PROTECTED] = Adam J. Richter [EMAIL PROTECTED] = Michael O'Reilly [EMAIL PROTECTED] Rik van Riel [EMAIL PROTECTED] writes, regarding the idea of having do_fork() give all of the parent's remaining time slice to the newly created child: It could upset programs which use threads to handle relatively IO poor things (like, waiting on disk IO in a thread, like glibc does to fake async file IO). Good point. Is it really? If a program is using thread to handle IO things, then: a) It's not going to create a thread for every IO! So I think the argument is suprious anyway. Maybe not that often, but, from my incomplete understanding of linux/kernel/sched.c, it looks like it can be a really long time before the recalculate loop in schedule() gets called. Currently, the time slice of a regular "nice 0" process in Linux is 50ms (NICE_TO_TICKS(20) = 5, and each tick is 10ms). So, if you're on a multiuser system or you're running some parallel algorithm that uses a bunch of threads so that nobody has to rendezvous to block on IO, then this could on the order of one second. Tangential note: I think the 50ms process time slice makes Linux boxes that have a lot of runnable threads or processes unresponsive in ways that will not show up in most benchmarks, making things like multi-user VNC servers much less scalable than they should be. I wish the Linux "recalculate" loop would scale the time slices to #cpu's/#runnable processes, such as by replacing changing the "p-counter = ..." line in the "recalculate" loop in schedule() to something like this: int runnables; ... runnables = 0; list_for_each(tmp, runqueue_head) runnables++; runnables /= smp_num_cpus; runnables = runnables ? runnables : 1; /* prevent division by 0 */ for_each_task(p) p-counter = (p-counter 1) + (NICE_TO_TICKS(p-nice) / runnables) + 1; (the "+ 1" at the end would ensure that the increment is never zero, even if runnables is very high.) Anyhow, getting back to the topic at hand... b) You _still_ want the child to run first. The child will start the I/O and block, then switching back to the parent. This maximises the I/O thruput without costing you any CPU. (Reasoning: The child running 2nd will increase the latency which automatically reduces the number of ops/second you can get). Absolutely. I never said that it would be a good idea run the parent first in that case and Rik didn't either. Under Rik's idea, the child would still run first, but the parent could retain some CPU priority, so that it could get around to running again before the next call to the "recalculate" loop in schedule(), which might be 1 second if the system has 20 runnable runnable threads. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
"John Fremlin" <[EMAIL PROTECTED]> writes: >"Adam J. Richter" <[EMAIL PROTECTED]> writes: >> "John Fremlin" <[EMAIL PROTECTED]> writes: >> > "Adam J. Richter" <[EMAIL PROTECTED]> writes: >The parent is not allowed to run until the child execs, if I >understand correctly. Read up on CLONE_VFORK. I thought that I had checked this a few months ago and discovered that Linux let the vfork parent run, but I wrote a test program just now, and you're apparently right about that, at least with respect to 2.4.3, although that's all the more reason to give the short term CPU priority to the process that can use it (the child), thereby slightly increasing the average runtime available in a timeslice, which in term slightly decreases the percentage of time spent in context switch overhead. This will usually be a really tiny amount, but my point is that since there is probably a tiny advantage to giving the remaining time slices to the child even here, there is no need to complicate my patch. >> Of course, in the vfork case, this change is probably only a very >> small win. The real advantage is with regular fork() followed by an >> exec, which happens quite a lot. For example, I do not see vfork >> anywhere in the bash sources. >If it is a real advantage you can get a bigger advantage by changing >the app to use vfork, i.e. you can solve the problem (if it exists) >better without hacking the kernel. It is impractical to change every application, including ones that you don't have access to, and many of them have reaons for using fork instead of vfork, and you don't even have access to them. For example, the setup that the child does between the fork and the exec is complex enough so that it might mess up the parent's memory or, more commonly, its error handling code for exec failure is. Even if you could show that vfork was the right choice in all cases (and it isn't), that would still be no reason for making do_fork unnecessary slow and complex. My change simplifies do_fork(), makes it runs a few cycles faster, and, I believe, makes it behave like more fork on most other systems. If you want to argue against this change, please justify the real benefits of the performance cost, the complexity and nonstandard behavior you are advocating. (Admittedly the last two are really small, but I believe they are positive). Note that I've dropped Linus's email address for this thread, as it does not appear to be arguing a real technical advantage to the old do_fork() behavior. So, while it may be interesting and informative and on topic for lkml, it is not seem to be an argument to Linus that he should reject or modify my patch. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
"John Fremlin" <[EMAIL PROTECTED]> writes: > "Adam J. Richter" <[EMAIL PROTECTED]> writes: >> Guess why you're seeing this email. That's right. Linux-2.4.3's >> fork() does not run the child first. >[...] If an app wants to fork and exec, it >should use *vfork* and exec, which is a performance win across many >OSs because the COW mappings don't even have to be set up, IIRC. Even in that case, you want to run the child first because it may block on I/O when it does the exec or the new program starts running, and you are likely to be able to use that time while the child is waiting on I/O for the parent to run (typically just to record the process in its internal data structures and then call wait()). Basically, you want to kick off some new I/O before running something that can run while that I/O is pending. Of course, in the vfork case, this change is probably only a very small win. The real advantage is with regular fork() followed by an exec, which happens quite a lot. For example, I do not see vfork anywhere in the bash sources. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
"John Fremlin" [EMAIL PROTECTED] writes: "Adam J. Richter" [EMAIL PROTECTED] writes: Guess why you're seeing this email. That's right. Linux-2.4.3's fork() does not run the child first. [...] If an app wants to fork and exec, it should use *vfork* and exec, which is a performance win across many OSs because the COW mappings don't even have to be set up, IIRC. Even in that case, you want to run the child first because it may block on I/O when it does the exec or the new program starts running, and you are likely to be able to use that time while the child is waiting on I/O for the parent to run (typically just to record the process in its internal data structures and then call wait()). Basically, you want to kick off some new I/O before running something that can run while that I/O is pending. Of course, in the vfork case, this change is probably only a very small win. The real advantage is with regular fork() followed by an exec, which happens quite a lot. For example, I do not see vfork anywhere in the bash sources. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
"John Fremlin" [EMAIL PROTECTED] writes: "Adam J. Richter" [EMAIL PROTECTED] writes: "John Fremlin" [EMAIL PROTECTED] writes: "Adam J. Richter" [EMAIL PROTECTED] writes: The parent is not allowed to run until the child execs, if I understand correctly. Read up on CLONE_VFORK. I thought that I had checked this a few months ago and discovered that Linux let the vfork parent run, but I wrote a test program just now, and you're apparently right about that, at least with respect to 2.4.3, although that's all the more reason to give the short term CPU priority to the process that can use it (the child), thereby slightly increasing the average runtime available in a timeslice, which in term slightly decreases the percentage of time spent in context switch overhead. This will usually be a really tiny amount, but my point is that since there is probably a tiny advantage to giving the remaining time slices to the child even here, there is no need to complicate my patch. Of course, in the vfork case, this change is probably only a very small win. The real advantage is with regular fork() followed by an exec, which happens quite a lot. For example, I do not see vfork anywhere in the bash sources. If it is a real advantage you can get a bigger advantage by changing the app to use vfork, i.e. you can solve the problem (if it exists) better without hacking the kernel. It is impractical to change every application, including ones that you don't have access to, and many of them have reaons for using fork instead of vfork, and you don't even have access to them. For example, the setup that the child does between the fork and the exec is complex enough so that it might mess up the parent's memory or, more commonly, its error handling code for exec failure is. Even if you could show that vfork was the right choice in all cases (and it isn't), that would still be no reason for making do_fork unnecessary slow and complex. My change simplifies do_fork(), makes it runs a few cycles faster, and, I believe, makes it behave like more fork on most other systems. If you want to argue against this change, please justify the real benefits of the performance cost, the complexity and nonstandard behavior you are advocating. (Admittedly the last two are really small, but I believe they are positive). Note that I've dropped Linus's email address for this thread, as it does not appear to be arguing a real technical advantage to the old do_fork() behavior. So, while it may be interesting and informative and on topic for lkml, it is not seem to be an argument to Linus that he should reject or modify my patch. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: List of all-zero .data variables in linux-2.4.3 available
>Thanks, but Andrey Panin did you one better -- he produced a patch which >fixes up a good number of these. You should follow lkml more closely :) I missed that patch and have been unable to find it on google/dejanews. However, my point is to provide an exhaustive list with sizes (and the tool for generating it), to make it easier to spot and prioritize ones that may have been missed. Anyhow, thanks for the tip. Perhaps I should run this program and post results again on a subsequent kernel release (presumably with Andrey's patch), although anyone else can run this program just as easily. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: List of all-zero .data variables in linux-2.4.3 available
>> I am aware of a couple of cases where code relied on static >> variables being allocated contiguously, but, in both cases, those >> variables were either all zeros or all non-zeros, so my proposed >> change would not break such code. >Continuous placement is not the only property defined by >initialization. There are many more. You cannot change this since it >will quite a few programs and libraries and subtle and hard to >impossible to identify ways. Simply educate programmers to not >initialize. If it is so simple to "educate" programmers on this, could you provide and example or some specifics, especially on why this should not even be a compiler option? Surely that will save you some iterations in this discussion. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
Hubertus Franke <[EMAIL PROTECTED]> writes: >Try this ... this will guarantee that (p->counter) > (current->counter) >and it seems not as radical > p->counter = (current->counter + 1) >> 1; >current->counter = (current->counter - 1) >> 1; >if (!current->counter) >current->need_resched = 1; >instead of this >- p->counter = (current->counter + 1) >> 1; >- current->counter >>= 1; >- if (!current->counter) >- current->need_resched = 1; >+ p->counter = current->counter; >+ current->counter = 0; >+ current->need_resched = 1; No. I tried your change and also tried it with setting current->need_resched to 1 in all cases, and it still seems to run the parent first in at least half of the tries. Evidently, current->counter must be zero to make the currently running process give up the CPU immediately, which is the important thing (so that the parent does not touch its virtual memory for a while). Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
>> = Adam J. Richter <[EMAIL PROTECTED]> > = Horst von Brand <[EMAIL PROTECTED]> >> I suppose that running the child first also has a minor >> advantage for clone() in that it should make programs that spawn lots >> of threads to do little bits of work behave better on machines with a >> small number of processors, since the threads that do so little work that >> they accomplish they finish within their time slice will not pile up >> before they have a chance to run. So, rather than give the parent's CPU >> priority to the child only if CLONE_VFORK is not set, I have decided to >> do a bit of machete surgery and have the child always inherit all of the >> parent's CPU priority all of the time. It simplifies the code and >> probably saves a few clock cycles (and before you say that this will >> cost a context switch, consider that the child will almost always run >> at least one time slice anyhow). >And opens the system up to DoS attacks: You can't have a process fork(2) >at will and so increase its (aggregate) CPU priority. My change does not increase the aggregate priority of parent+child. Perhaps I misunderstand your comment. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: List of all-zero .data variables in linux-2.4.3 available
[EMAIL PROTECTED] writes:
>Shouldn't a compiler be able to deal with this instead?
Yes. I sent some email to bug-gcc about this a couple of
months ago and even posted some (probably horribly incorrect) code
showing roughly the change I had in mind in the gcc source code
for the simple case of scalar variables. I was told that some code
to this was put in and then removed from gcc a long time ago, and
nobody seemed interested in putting it back in. I would think that this
would be a basic optimization that I would expect the compiler to make,
just like deleting "if(0) {..}" code, but gcc does not currently
do that. If somebody would like to fix gcc and do the necessary
lobbying to get such a change integrated, that would be great. However,
until that actually happens, I hope the file that I posted to
ftp://ftp.yggdrasil.com/private/adam/linux/zerovars/ will be useful
to individual maintainers and in identifying the largest arrays of
zeroes that can fix fixed in a few lines.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
List of all-zero .data variables in linux-2.4.3 available
For anyone who is interested, I have produced a list of all of the .data variables that contain all zeroes and could be moved to .bss within the kernel and all of the modules (all of the modules that we build at Yggdrasil for x86, which is almost all). These are global or static variables that have been declared int foo = 0; instead of int foo;/* = 0 */ The result is that the .o files are bigger than they have to be. The kernel memory image is not bigger, and gzip shrinks the runs of zeroes down to almost nothing, so it does not have a huge effect on bootable disks. Still, it would be nice to save the disk space of the approximately 75 kilobytes of zeroes and perhaps squeeze in another sector or two when building boot floppies. I have also included a copy of the program that I wrote to find these all-zero .data variables. The program and the output are FTPable from ftp://ftp.yggdrasil.com/private/adam/linux/zerovars/. Files with no all-zero .data variables are not included in the listing. If you maintain any code in the kernel, you might want to look at the output to see how your code stacks up. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH(?): linux-2.4.4-pre2: fork should run child first
I remember sometime in the late 80's a fellow at UniSoft
named Don whose last name escapes me just now told me about a
paper presented at a Usenix symposium that had some measurements
that purported that copy-on-write was a performance lose and
better performance would be achieve by having fork() just copy
all of the writable pages of the parent process.
It turned out that the particular unix-like system on which
these benchmarks were taken had a version of fork that did not run
the child first. As it was explained to me then, most of the time,
the child process from a fork will do just a few things and then do
an exec(), releasing its copy-on-write references to the parent's
pages, and that is the big win of copy-on-write for fork() in practice.
This oversight was considered a big embarassment for the operating
system in question, so I won't name it here.
Guess why you're seeing this email. That's right. Linux-2.4.3's
fork() does not run the child first. Consequently, the parent will
probably generate unnecessary copy-on-write page copies until it burns
through its remaining clock ticks (any COW's that the child causes will
basically happen no matter what the order of execution is) or calls
wait() (and while the wait is blocking, the parent's CPU priority will
decay as the scheduler periodically recalculates process priorities, so
that bit of dynamic priority has probably not been allocated where the
user will be able to use it, if we want to look at "fairness" in such
detail).
I suppose that running the child first also has a minor
advantage for clone() in that it should make programs that spawn lots
of threads to do little bits of work behave better on machines with a
small number of processors, since the threads that do so little work that
they accomplish they finish within their time slice will not pile up
before they have a chance to run. So, rather than give the parent's CPU
priority to the child only if CLONE_VFORK is not set, I have decided to
do a bit of machete surgery and have the child always inherit all of the
parent's CPU priority all of the time. It simplifies the code and
probably saves a few clock cycles (and before you say that this will
cost a context switch, consider that the child will almost always run
at least one time slice anyhow).
I have attached the patch below. I have also adjusted the
comment describing the code. Please let me know if this hand waving
explanation is sufficient. I'm trying to be lazy on not do a measurement
project to justify this relatively simple change. However, I do know, from
a simple test program ("printf ("%d", fork());"), that this patch has
the intended effect of running the child first.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.4-pre2/kernel/fork.c Thu Apr 12 01:31:53 2001
+++ linux/kernel/fork.c Thu Apr 12 01:35:53 2001
@@ -666,15 +666,17 @@
p->pdeath_signal = 0;
/*
-* "share" dynamic priority between parent and child, thus the
-* total amount of dynamic priorities in the system doesnt change,
-* more scheduling fairness. This is only important in the first
-* timeslice, on the long run the scheduling behaviour is unchanged.
+* Give the parent's dynamic priority entirely to the child. The
+* total amount of dynamic priorities in the system doesn't change
+* (more scheduling fairness), but the child will run first, which
+* is especially useful in avoiding a lot of copy-on-write faults
+* if the child for a fork() just wants to do a few simple things
+* and then exec(). This is only important in the first timeslice.
+* In the long run, the scheduling behavior is unchanged.
*/
- p->counter = (current->counter + 1) >> 1;
- current->counter >>= 1;
- if (!current->counter)
- current->need_resched = 1;
+ p->counter = current->counter;
+ current->counter = 0;
+ current->need_resched = 1;
/*
* Ok, add it to the run-queues and make it
PATCH(?): linux-2.4.4-pre2: fork should run child first
I remember sometime in the late 80's a fellow at UniSoft
named Don whose last name escapes me just now told me about a
paper presented at a Usenix symposium that had some measurements
that purported that copy-on-write was a performance lose and
better performance would be achieve by having fork() just copy
all of the writable pages of the parent process.
It turned out that the particular unix-like system on which
these benchmarks were taken had a version of fork that did not run
the child first. As it was explained to me then, most of the time,
the child process from a fork will do just a few things and then do
an exec(), releasing its copy-on-write references to the parent's
pages, and that is the big win of copy-on-write for fork() in practice.
This oversight was considered a big embarassment for the operating
system in question, so I won't name it here.
Guess why you're seeing this email. That's right. Linux-2.4.3's
fork() does not run the child first. Consequently, the parent will
probably generate unnecessary copy-on-write page copies until it burns
through its remaining clock ticks (any COW's that the child causes will
basically happen no matter what the order of execution is) or calls
wait() (and while the wait is blocking, the parent's CPU priority will
decay as the scheduler periodically recalculates process priorities, so
that bit of dynamic priority has probably not been allocated where the
user will be able to use it, if we want to look at "fairness" in such
detail).
I suppose that running the child first also has a minor
advantage for clone() in that it should make programs that spawn lots
of threads to do little bits of work behave better on machines with a
small number of processors, since the threads that do so little work that
they accomplish they finish within their time slice will not pile up
before they have a chance to run. So, rather than give the parent's CPU
priority to the child only if CLONE_VFORK is not set, I have decided to
do a bit of machete surgery and have the child always inherit all of the
parent's CPU priority all of the time. It simplifies the code and
probably saves a few clock cycles (and before you say that this will
cost a context switch, consider that the child will almost always run
at least one time slice anyhow).
I have attached the patch below. I have also adjusted the
comment describing the code. Please let me know if this hand waving
explanation is sufficient. I'm trying to be lazy on not do a measurement
project to justify this relatively simple change. However, I do know, from
a simple test program ("printf ("%d", fork());"), that this patch has
the intended effect of running the child first.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.4-pre2/kernel/fork.c Thu Apr 12 01:31:53 2001
+++ linux/kernel/fork.c Thu Apr 12 01:35:53 2001
@@ -666,15 +666,17 @@
p-pdeath_signal = 0;
/*
-* "share" dynamic priority between parent and child, thus the
-* total amount of dynamic priorities in the system doesnt change,
-* more scheduling fairness. This is only important in the first
-* timeslice, on the long run the scheduling behaviour is unchanged.
+* Give the parent's dynamic priority entirely to the child. The
+* total amount of dynamic priorities in the system doesn't change
+* (more scheduling fairness), but the child will run first, which
+* is especially useful in avoiding a lot of copy-on-write faults
+* if the child for a fork() just wants to do a few simple things
+* and then exec(). This is only important in the first timeslice.
+* In the long run, the scheduling behavior is unchanged.
*/
- p-counter = (current-counter + 1) 1;
- current-counter = 1;
- if (!current-counter)
- current-need_resched = 1;
+ p-counter = current-counter;
+ current-counter = 0;
+ current-need_resched = 1;
/*
* Ok, add it to the run-queues and make it
List of all-zero .data variables in linux-2.4.3 available
For anyone who is interested, I have produced a list of all of the .data variables that contain all zeroes and could be moved to .bss within the kernel and all of the modules (all of the modules that we build at Yggdrasil for x86, which is almost all). These are global or static variables that have been declared int foo = 0; instead of int foo;/* = 0 */ The result is that the .o files are bigger than they have to be. The kernel memory image is not bigger, and gzip shrinks the runs of zeroes down to almost nothing, so it does not have a huge effect on bootable disks. Still, it would be nice to save the disk space of the approximately 75 kilobytes of zeroes and perhaps squeeze in another sector or two when building boot floppies. I have also included a copy of the program that I wrote to find these all-zero .data variables. The program and the output are FTPable from ftp://ftp.yggdrasil.com/private/adam/linux/zerovars/. Files with no all-zero .data variables are not included in the listing. If you maintain any code in the kernel, you might want to look at the output to see how your code stacks up. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: List of all-zero .data variables in linux-2.4.3 available
[EMAIL PROTECTED] writes:
Shouldn't a compiler be able to deal with this instead?
Yes. I sent some email to bug-gcc about this a couple of
months ago and even posted some (probably horribly incorrect) code
showing roughly the change I had in mind in the gcc source code
for the simple case of scalar variables. I was told that some code
to this was put in and then removed from gcc a long time ago, and
nobody seemed interested in putting it back in. I would think that this
would be a basic optimization that I would expect the compiler to make,
just like deleting "if(0) {..}" code, but gcc does not currently
do that. If somebody would like to fix gcc and do the necessary
lobbying to get such a change integrated, that would be great. However,
until that actually happens, I hope the file that I posted to
ftp://ftp.yggdrasil.com/private/adam/linux/zerovars/ will be useful
to individual maintainers and in identifying the largest arrays of
zeroes that can fix fixed in a few lines.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
= Adam J. Richter [EMAIL PROTECTED] = Horst von Brand [EMAIL PROTECTED] I suppose that running the child first also has a minor advantage for clone() in that it should make programs that spawn lots of threads to do little bits of work behave better on machines with a small number of processors, since the threads that do so little work that they accomplish they finish within their time slice will not pile up before they have a chance to run. So, rather than give the parent's CPU priority to the child only if CLONE_VFORK is not set, I have decided to do a bit of machete surgery and have the child always inherit all of the parent's CPU priority all of the time. It simplifies the code and probably saves a few clock cycles (and before you say that this will cost a context switch, consider that the child will almost always run at least one time slice anyhow). And opens the system up to DoS attacks: You can't have a process fork(2) at will and so increase its (aggregate) CPU priority. My change does not increase the aggregate priority of parent+child. Perhaps I misunderstand your comment. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
Hubertus Franke [EMAIL PROTECTED] writes: Try this ... this will guarantee that (p-counter) (current-counter) and it seems not as radical p-counter = (current-counter + 1) 1; current-counter = (current-counter - 1) 1; if (!current-counter) current-need_resched = 1; instead of this - p-counter = (current-counter + 1) 1; - current-counter = 1; - if (!current-counter) - current-need_resched = 1; + p-counter = current-counter; + current-counter = 0; + current-need_resched = 1; No. I tried your change and also tried it with setting current-need_resched to 1 in all cases, and it still seems to run the parent first in at least half of the tries. Evidently, current-counter must be zero to make the currently running process give up the CPU immediately, which is the important thing (so that the parent does not touch its virtual memory for a while). Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: List of all-zero .data variables in linux-2.4.3 available
I am aware of a couple of cases where code relied on static variables being allocated contiguously, but, in both cases, those variables were either all zeros or all non-zeros, so my proposed change would not break such code. Continuous placement is not the only property defined by initialization. There are many more. You cannot change this since it will quite a few programs and libraries and subtle and hard to impossible to identify ways. Simply educate programmers to not initialize. If it is so simple to "educate" programmers on this, could you provide and example or some specifics, especially on why this should not even be a compiler option? Surely that will save you some iterations in this discussion. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: List of all-zero .data variables in linux-2.4.3 available
Thanks, but Andrey Panin did you one better -- he produced a patch which fixes up a good number of these. You should follow lkml more closely :) I missed that patch and have been unable to find it on google/dejanews. However, my point is to provide an exhaustive list with sizes (and the tool for generating it), to make it easier to spot and prioritize ones that may have been missed. Anyhow, thanks for the tip. Perhaps I should run this program and post results again on a subsequent kernel release (presumably with Andrey's patch), although anyone else can run this program just as easily. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch(?): linux-2.4.3-pre6/mm/vmalloc.c could return with init_mm.page_table_lock held
Marcelo Tosatti <[EMAIL PROTECTED]> writes: >There is no need to hold mm->page_table_lock for vmalloced memory. I don't know if it makes a difference, but I should clarify that mm == _mm throughout this code, not >mm. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch(?): linux-2.4.3-pre6/mm/vmalloc.c could return with init_mm.page_table_lock held
[Sorry for posting three messages to linux-kernel about this.
Each time I was pretty sure I was done for the night. Anyhow, I
hope this proposed patch makes up for it.]
In linux-2.4.3-pre6, a call to vmalloc can result in a call to
pte_alloc without the appropriate page_table_lock being held. Here is
the call graph, from my post of about half an hour ago:
vmalloc
__vmalloc
vmalloc_area_pages
alloc_area_pmd
pte_alloc ...which assumes (here incorrectly) that
mm->page_table_lock is held, and sometimes releases
and reacquires mm->page_table_lock.
Not only does pte_alloc expect mm->page_table_lock
to be held when it is called, but it also sometimes releases and
reacquires it. vmalloc did not release this lock either, of course.
So, the next attempt to acquire the same mm->page_table_lock spin lock
hangs.
The symptom that I had noticed was the agpgart.o module hanging
at module initialization, but it is a much more general problem, and
could explain all sorts of hangs in 2.4.3-pre6.
Anyhow, with this patch, agpgart.o loads just fine and the
kernel seems to have suffered no negative side effects. I am
not confident in exactly where I chose to put the spin_lock and
spin_unlock calls, so I would recommend a careful examination of
this patch before integrating.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.3-pre6/mm/vmalloc.c Fri Mar 23 02:16:41 2001
+++ linux/mm/vmalloc.c Fri Mar 23 02:09:58 2001
@@ -136,39 +136,41 @@
inline int vmalloc_area_pages (unsigned long address, unsigned long size,
int gfp_mask, pgprot_t prot)
{
pgd_t * dir;
unsigned long end = address + size;
int ret;
dir = pgd_offset_k(address);
flush_cache_all();
+ spin_lock(_mm.page_table_lock);
lock_kernel();
do {
pmd_t *pmd;
pmd = pmd_alloc(_mm, dir, address);
ret = -ENOMEM;
if (!pmd)
break;
ret = -ENOMEM;
if (alloc_area_pmd(pmd, address, end - address, gfp_mask, prot))
break;
address = (address + PGDIR_SIZE) & PGDIR_MASK;
dir++;
ret = 0;
} while (address && (address < end));
unlock_kernel();
+ spin_unlock(_mm.page_table_lock);
flush_tlb_all();
return ret;
}
struct vm_struct * get_vm_area(unsigned long size, unsigned long flags)
{
unsigned long addr;
struct vm_struct **p, *tmp, *area;
area = (struct vm_struct *) kmalloc(sizeof(*area), GFP_KERNEL);
Re: 2.4.3-pre6: agpart.o causes arch/i386/mm/ioremap.c hang
I wrote: > Under linux-2.4.3-pre6 compiled for SMP, loading agpgart.o >hangs the system in remap_area_pages (arch/i386/mm/ioremap.c) at >the call to spin_lock(_mm.page_table_lock), which is not in 2.4.2. [...] > agp_backend_initialize > agp_generic_create_gatt_table > io_remap_nocache > __ioremap > remap_area_pages [...] > I'm rebuilding the kernel now with a modified spin_lock() >routine that should tell me who acquired the lock previously [...] In case anyone is interested, the conflicting lock of init_mm.page_table_lock was acquired in line 1318 of mm/memory.c, in pte_alloc. One way that this might be happening is that it looks like no page_table_lock is every acquired by vmalloc, which results in the following call graph: vmalloc __vmalloc vmalloc_area_pages alloc_area_pmd pte_alloc ...which assumes (here incorrectly) that mm->page_table_lock is held, and sometimes releases and reacquires mm->page_table_lock. I will attempt to analyze this further tomorrow if nobody beats me to it. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.4.3-pre6: agpart.o causes arch/i386/mm/ioremap.c hang
Under linux-2.4.3-pre6 compiled for SMP, loading agpgart.o hangs the system in remap_area_pages (arch/i386/mm/ioremap.c) at the call to spin_lock(_mm.page_table_lock), which is not in 2.4.2. When I load agpgart.o, I get the following messages: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 690M agpgart: Detected Via Apollo Pro chipset After that, the console keys (RightAlt ScrollLock, Alt-F2, etc.) but there is not other response to my keystrokes and the system is no longer pingable. The call graphic is basically: agp_backend_initialize agp_generic_create_gatt_table io_remap_nocache __ioremap remap_area_pages I've made a cursory search through the kernel sources for what else might be holding this lock, but I have not yet found anything. I'm rebuilding the kernel now with a modified spin_lock() routine that should tell me who acquired the lock previously; however, I really do not understand this part of the kernel enough to know what the changes were intended to do in the first place. So, knowing where else the lock was acquired will not necessarily be enough for me to be able to generate a patch. Anyhow, I imagine that this lock is being held by some code that can block. We'll see. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.4.3-pre6: agpart.o causes arch/i386/mm/ioremap.c hang
Under linux-2.4.3-pre6 compiled for SMP, loading agpgart.o hangs the system in remap_area_pages (arch/i386/mm/ioremap.c) at the call to spin_lock(init_mm.page_table_lock), which is not in 2.4.2. When I load agpgart.o, I get the following messages: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 690M agpgart: Detected Via Apollo Pro chipset After that, the console keys (RightAlt ScrollLock, Alt-F2, etc.) but there is not other response to my keystrokes and the system is no longer pingable. The call graphic is basically: agp_backend_initialize agp_generic_create_gatt_table io_remap_nocache __ioremap remap_area_pages I've made a cursory search through the kernel sources for what else might be holding this lock, but I have not yet found anything. I'm rebuilding the kernel now with a modified spin_lock() routine that should tell me who acquired the lock previously; however, I really do not understand this part of the kernel enough to know what the changes were intended to do in the first place. So, knowing where else the lock was acquired will not necessarily be enough for me to be able to generate a patch. Anyhow, I imagine that this lock is being held by some code that can block. We'll see. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3-pre6: agpart.o causes arch/i386/mm/ioremap.c hang
I wrote: Under linux-2.4.3-pre6 compiled for SMP, loading agpgart.o hangs the system in remap_area_pages (arch/i386/mm/ioremap.c) at the call to spin_lock(init_mm.page_table_lock), which is not in 2.4.2. [...] agp_backend_initialize agp_generic_create_gatt_table io_remap_nocache __ioremap remap_area_pages [...] I'm rebuilding the kernel now with a modified spin_lock() routine that should tell me who acquired the lock previously [...] In case anyone is interested, the conflicting lock of init_mm.page_table_lock was acquired in line 1318 of mm/memory.c, in pte_alloc. One way that this might be happening is that it looks like no page_table_lock is every acquired by vmalloc, which results in the following call graph: vmalloc __vmalloc vmalloc_area_pages alloc_area_pmd pte_alloc ...which assumes (here incorrectly) that mm-page_table_lock is held, and sometimes releases and reacquires mm-page_table_lock. I will attempt to analyze this further tomorrow if nobody beats me to it. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch(?): linux-2.4.3-pre6/mm/vmalloc.c could return with init_mm.page_table_lock held
[Sorry for posting three messages to linux-kernel about this.
Each time I was pretty sure I was done for the night. Anyhow, I
hope this proposed patch makes up for it.]
In linux-2.4.3-pre6, a call to vmalloc can result in a call to
pte_alloc without the appropriate page_table_lock being held. Here is
the call graph, from my post of about half an hour ago:
vmalloc
__vmalloc
vmalloc_area_pages
alloc_area_pmd
pte_alloc ...which assumes (here incorrectly) that
mm-page_table_lock is held, and sometimes releases
and reacquires mm-page_table_lock.
Not only does pte_alloc expect mm-page_table_lock
to be held when it is called, but it also sometimes releases and
reacquires it. vmalloc did not release this lock either, of course.
So, the next attempt to acquire the same mm-page_table_lock spin lock
hangs.
The symptom that I had noticed was the agpgart.o module hanging
at module initialization, but it is a much more general problem, and
could explain all sorts of hangs in 2.4.3-pre6.
Anyhow, with this patch, agpgart.o loads just fine and the
kernel seems to have suffered no negative side effects. I am
not confident in exactly where I chose to put the spin_lock and
spin_unlock calls, so I would recommend a careful examination of
this patch before integrating.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.3-pre6/mm/vmalloc.c Fri Mar 23 02:16:41 2001
+++ linux/mm/vmalloc.c Fri Mar 23 02:09:58 2001
@@ -136,39 +136,41 @@
inline int vmalloc_area_pages (unsigned long address, unsigned long size,
int gfp_mask, pgprot_t prot)
{
pgd_t * dir;
unsigned long end = address + size;
int ret;
dir = pgd_offset_k(address);
flush_cache_all();
+ spin_lock(init_mm.page_table_lock);
lock_kernel();
do {
pmd_t *pmd;
pmd = pmd_alloc(init_mm, dir, address);
ret = -ENOMEM;
if (!pmd)
break;
ret = -ENOMEM;
if (alloc_area_pmd(pmd, address, end - address, gfp_mask, prot))
break;
address = (address + PGDIR_SIZE) PGDIR_MASK;
dir++;
ret = 0;
} while (address (address end));
unlock_kernel();
+ spin_unlock(init_mm.page_table_lock);
flush_tlb_all();
return ret;
}
struct vm_struct * get_vm_area(unsigned long size, unsigned long flags)
{
unsigned long addr;
struct vm_struct **p, *tmp, *area;
area = (struct vm_struct *) kmalloc(sizeof(*area), GFP_KERNEL);
Re: Patch(?): linux-2.4.3-pre6/mm/vmalloc.c could return with init_mm.page_table_lock held
Marcelo Tosatti [EMAIL PROTECTED] writes: There is no need to hold mm-page_table_lock for vmalloced memory. I don't know if it makes a difference, but I should clarify that mm == init_mm throughout this code, not current-mm. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: changing precision control setting in initial FPU context
IEEE-754 floating point is available under glibc-based systems, including most current GNU/Linux distributions, by linking with -lieee. Your example program produces the "9 10" result you wanted when linked this way, even when compiled with -O2 When not linked with "-lieee", Linux personality ELF x86 binaries start with Precision Control set to 3, just because that is how the x86 fninit instruction sets it. I thought that libieee was also available at run time for dynamic executables by doing something like "LD_PRELOAD=/usr/lib/libieee.so my_dynamic_exeuctable", so you could set it in your .bashrc if you wanted, but that apparently is not the case, at least under glibc-2.2.2. I will have to try to figure out why this is not available. I am a bit out of my depth when discussing the advantages of occasional 80 bit precision over 64 bit, but I think that there are situations where getting gratuitously more accurate results helps, like getting faster convergence in some scientific numerical methods, such as Newton's method. (You'll still find the same point of convergence if there is only one, but the program will run faster). Another example would be things like 3D lighting calculations (used in games?) where you want to produce the best images that you can within that CPU budget. I don't know of any sound encodings where a fully optimized implementation would use floating point, but it's possible. In general, I think most real uses of floating point are for "fast and sloppy" purposes, and programs that want to use floating point and care about exact reproducibility will link with "-lieee". On the other hand, if a GNU/Linux-x86 distribution did want to change the initial floating point control word in Linux to PC=2, I think you would still want old programs to run in their old PC=3 environment, just in case one relied on it. Your sys_setfpcw suggestion could do (to set the default floating point control word without flagging the process as one that was definitely going to use floating point), but I think a simpler approach would be to assign a different magic number argument setpersonality() for programs that expect to be initialized with floating point precision control set to 2. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: changing precision control setting in initial FPU context
IEEE-754 floating point is available under glibc-based systems, including most current GNU/Linux distributions, by linking with -lieee. Your example program produces the "9 10" result you wanted when linked this way, even when compiled with -O2 When not linked with "-lieee", Linux personality ELF x86 binaries start with Precision Control set to 3, just because that is how the x86 fninit instruction sets it. I thought that libieee was also available at run time for dynamic executables by doing something like "LD_PRELOAD=/usr/lib/libieee.so my_dynamic_exeuctable", so you could set it in your .bashrc if you wanted, but that apparently is not the case, at least under glibc-2.2.2. I will have to try to figure out why this is not available. I am a bit out of my depth when discussing the advantages of occasional 80 bit precision over 64 bit, but I think that there are situations where getting gratuitously more accurate results helps, like getting faster convergence in some scientific numerical methods, such as Newton's method. (You'll still find the same point of convergence if there is only one, but the program will run faster). Another example would be things like 3D lighting calculations (used in games?) where you want to produce the best images that you can within that CPU budget. I don't know of any sound encodings where a fully optimized implementation would use floating point, but it's possible. In general, I think most real uses of floating point are for "fast and sloppy" purposes, and programs that want to use floating point and care about exact reproducibility will link with "-lieee". On the other hand, if a GNU/Linux-x86 distribution did want to change the initial floating point control word in Linux to PC=2, I think you would still want old programs to run in their old PC=3 environment, just in case one relied on it. Your sys_setfpcw suggestion could do (to set the default floating point control word without flagging the process as one that was definitely going to use floating point), but I think a simpler approach would be to assign a different magic number argument setpersonality() for programs that expect to be initialized with floating point precision control set to 2. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH: linux-2.4.2-pre4/drivers/media/video/cpia_usb.c device ID update
The following one line patch updates the cpia_usb driver
in linux-2.4.2-pre4 to include the additional device ID that
already appears in http://download.sourceforge.net/webcam/cpia-1.2.tgz.
This patch is necessary to make cpia_usb work with the Intel QX3 microscope
and possibly other devices as well. I tested this patch by looking
through my QX3 microscope under XawTV, which did not work without this
change.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-CUT HERE---
--- linux-2.4.2-pre4/drivers/media/video/cpia_usb.c Thu Jan 4 13:15:32 2001
+++ linux/drivers/media/video/cpia_usb.cMon Feb 19 01:27:56 2001
@@ -558,6 +558,7 @@
static struct usb_device_id cpia_id_table [] = {
{ USB_DEVICE(0x0553, 0x0002) },
+ { USB_DEVICE(0x0813, 0x0001) },
{ } /* Terminating entry */
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
