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
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: 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;
}
/**
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/
Re: New SCM and commit list
oadable (not not yet removable) module, sysfs memory shrink, factoring much of the 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&m=111320013100822&w=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: 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/
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/
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/
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&hl=en&safe=off&rnum=1&ic=1&selm=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
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
Larry McVoy writes: >On Fri, May 25, 2001 at 10:02:08AM -0700, Adam J. Richter wrote: >> 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: >Adam, the point is not what the GPL says or what the definition is. >The point is "what is legal". You can, for example, write a license >which says > By running the software covered by this license, you agree to > become my personal slave and you will be obligated to bring > me coffee each morning for the rest of my life, greating > me with a "Good morning, master, here is your coffee oh > most magnificent one". >If anyone is stupid enough to obey such a license, they need help. >The problem is that licenses can write whatever they want, but what they >say only has meaning if it is enforceable. The "license" above would >be found to be unenforceable by the courts in about 30 seconds or so. Contracts for slavery are specifically not enforceable due to the 13th Amendment, and there is also a stronger question of formation of a binding contract in your example, because the proposed mode of acceptance (related to the pointers I provided before) is doing something that you might have the right to do regardless of copyright (running the program as opposed to distributing copies). I believe that people write contracts all the time that prohibit distribution of certain works with others, for marketing reasons. >OK, so what does this have to do with aggregration? The prevailing >legal opinions seem to be that viral licenses cannot extend their >terms across boundaries. We're not talking about mythically changing the copyright status of another work. If your opinion is "prevailing" please include a reference to a section of the US code, a court decision or some reference that one could actually track down. By the way, I have asked a lawyer at an IP litigation firm that we use about this and he indicated the copyright infringement case was quite strong. 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 furthe
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
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 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/
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++ )
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/
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
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
"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: 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
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 ¤t->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(&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: 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/
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: 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/
PATCH: linux-2.4.2-pre3/arch/i386/boot/Makefile breaks with binutils-2.10.1.0.7
The "ld" program in binutils-2.10.1.0.7 and in binutils-2.10.91.0.2 now requires "--oformat" instead of "-oformat". This breaks linux-2.4.2-pre3/arch/i386/boot/Makefile. I have attached the fix below. I am running a kernel built with this updated Makefile. -- 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.2-pre3/arch/i386/boot/MakefileMon Dec 20 14:43:39 1999 +++ linux/arch/i386/boot/Makefile Fri Feb 9 15:37:53 2001 @@ -43,7 +43,7 @@ $(HOSTCC) $(HOSTCFLAGS) -o $@ $< -I$(TOPDIR)/include bootsect: bootsect.o - $(LD) -Ttext 0x0 -s -oformat binary -o $@ $< + $(LD) -Ttext 0x0 -s --oformat binary -o $@ $< bootsect.o: bootsect.s $(AS) -o $@ $< @@ -52,7 +52,7 @@ $(CPP) $(CPPFLAGS) -traditional $(SVGA_MODE) $(RAMDISK) $< -o $@ bbootsect: bbootsect.o - $(LD) -Ttext 0x0 -s -oformat binary $< -o $@ + $(LD) -Ttext 0x0 -s --oformat binary $< -o $@ bbootsect.o: bbootsect.s $(AS) -o $@ $< @@ -61,7 +61,7 @@ $(CPP) $(CPPFLAGS) -D__BIG_KERNEL__ -traditional $(SVGA_MODE) $(RAMDISK) $< -o $@ setup: setup.o - $(LD) -Ttext 0x0 -s -oformat binary -e begtext -o $@ $< + $(LD) -Ttext 0x0 -s --oformat binary -e begtext -o $@ $< setup.o: setup.s $(AS) -o $@ $< @@ -70,7 +70,7 @@ $(CPP) $(CPPFLAGS) -traditional $(SVGA_MODE) $(RAMDISK) $< -o $@ bsetup: bsetup.o - $(LD) -Ttext 0x0 -s -oformat binary -e begtext -o $@ $< + $(LD) -Ttext 0x0 -s --oformat binary -e begtext -o $@ $< bsetup.o: bsetup.s $(AS) -o $@ $<
hotplugging with regular PCI cards
I saw an interesting demonstration at LinuxWorld last week. Compaq had a machine that did hot plugging with regular PCI cards (not Compact PCI). If anyone out there is familiar with this machine, I would be interested in knowing what the status is on getting the support for that backplain integrated into the stock kernels. When that occurs, that will be yet another reason to treat all new style PCI drivers as potentially hot pluggable, even if those cards are not currently available in a CardBus or CompactPCI form, and in particular to change all of the xxx_pci_tbl declarations in PCI drivers that are currently marked as __initdata back to __devinitdata. 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] Please read the FAQ at http://www.tux.org/lkml/
PATCH: linux-2.4.1/drivers/acpi/amfldio.c will fail if bit_granularity==32
I hope this bug was not the result of my cc'ing Linus
on some emails and not on others, because this bug is a mistake
that I made a few weeks ago and then fixed when it was immediately
pointed out to me by some smart person on the acpi list.
The test "((1 << bit_granularity) -1) & ~mask" will always
fail on x86+gcc if bit_granularity == 32, because the value of 1<<32
on x86 + gcc-2.95.2 is 1, not 0. The value of 1<= bitsizeof(result), so we should not do this anyhow.
Anyhow, here is a patch that should fix the problem.
--
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.1/drivers/acpi/interpreter/amfldio.c Mon Jan 29 10:15:59 2001
+++ linux/drivers/acpi/interpreter/amfldio.cWed Jan 31 05:23:48 2001
@@ -415,7 +415,8 @@
/* Check if update rule needs to be applied (not if mask is all ones)
*/
- if (((1 << bit_granularity) -1) & ~mask) {
+ /* The left shift drops the bits we want to ignore. */
+ if ((~mask << (sizeof(mask)*8 - bit_granularity)) != 0) {
/*
* Read the current contents of the byte/word/dword containing
* the field, and merge with the new field value.
PATCH: linux-2.4.1/drivers/md.c unnecessarily referenced unexported symbol name_to_dev_t when md.c is built as module
md_setup() in linux-2.4.1/drivers/md.c references name_to_kdev_t.
Since name_to_kdev_t is not exported from the kenrel, this causes an
undefined symbol problem when md is built as a module. However,
md_setup is not used when md is a module. So, the correct fix
is to make sure that md_setup() is compiled only when md.c
is not a module. Here is the 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."
--- linux-2.4.1/drivers/md/md.c Mon Jan 29 13:16:00 2001
+++ linux/drivers/md/md.c Wed Jan 31 20:21:36 2001
@@ -3665,6 +3666,7 @@
* elements in device-list are read by name_to_kdev_t so can be
* a hex number or something like /dev/hda1 /dev/sdb
*/
+#ifndef MODULE
extern kdev_t name_to_kdev_t(char *line) md__init;
static int md__init md_setup(char *str)
{
@@ -3740,6 +3742,7 @@
md_setup_args.device_set[minor] = 1;
return 1;
}
+#endif /* !MODULE */
void md__init md_setup_drive(void)
{
Re: hotmail not dealing with ECN
I am surprised that anyone is seriously considering denying service to sites that do not implement an _experimental_ facility and have firewalls that try to play things safe by dropping packets which have 1's in bit positions that in the RFC "must be zero." If Microsoft were to do this with their favorite experimental network extensions for msnbc.com, how do you think the non-Microsoft world would feel and react? Well, that's about how the rest of the world is likely to view this. That said, I wonder if some tweak to the Linux networking stack is possible whereby it would automatically disable ECN and retry on per socket basis if the connection establishment otherwise seems to be timing out. This may be tricky given that the purpose of this facility is congestion notification, but, if someone is smart enough to be able to implement this, it would provide a much less disruptive migration path for adoption across firewalls that drop these packets. Far more sites could then safely activate this feature without limiting the hosts that they can reach. 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] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] linux-2.4.1-pre9/include/linux/acpi.h broke acpid compilation
linux-2.4.1-pre9/include/linux/acpi.h contains declares the routine acpi_get_rsdp_ptr returning the kernel-only type "u64", without bracketing the declaration in "#ifdef __KERNEL__...#endif". Consequently, a user level program that attempts to include , such as acpid, gets a compilation error. The following patch fix the problem by stretching an earlier "#ifdef __KERNEL__...#endif" area to cover the acpi_get_rsdp_ptr declaration. -- 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.1-pre9/include/linux/acpi.h Fri Dec 29 14:07:24 2000 +++ linux/include/linux/acpi.h Sun Jan 21 00:14:59 2001 @@ -26,9 +26,9 @@ #ifdef __KERNEL__ #include #include -#endif /* __KERNEL__ */ -u64 acpi_get_rsdp_ptr(void); +extern u64 acpi_get_rsdp_ptr(void); +#endif /* __KERNEL__ */ /* * System sleep states
[PATCH] linux-2.4.1-pre9/drivers/usb/serial/mct_u232.c usb_device_id table broken by new format
The format of usb_device_id tables was recently changed
(just before 2.4.0, I think) to include a match_flags field. A bit
set to one in that field indicates that a given member of the structure
contains a valid value that must match. A bit set to zero indicates
a wildcard (skip the comparison). Compiling a driver that uses the old
format results in that driver having a usb_device_id structure that
has an all zeroes match_flags, which means don't compare anything.
That is, it is a completely wildcard and will match every USB interface.
As of 2.4.1-pre9, there appears to be only USB driver that
was missed: drivers/usb/serial/mct_u232.c. This patch fixes the problem.
--
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.1-pre9/drivers/usb/serial/mct_u232.c Thu Dec 7 16:13:38 2000
+++ linux/drivers/usb/serial/mct_u232.c Sat Jan 20 02:52:44 2001
@@ -102,7 +102,7 @@
* All of the device info needed for the MCT USB-RS232 converter.
*/
static __devinitdata struct usb_device_id id_table [] = {
- { idVendor: MCT_U232_VID, idProduct: MCT_U232_PID },
+ { USB_DEVICE(MCT_U232_VID, MCT_U232_PID) },
{ } /* Terminating entry */
};
Patch(?): linux-2.4.1-pre3/include/asm-i386/xor.h referenced undefined HAVE_XMM
linux-2.4.1-pre2 changed cpu_has_xmm references in
include/asm-i386/xor.h into HAVE_XMM references, which it that
patch also defined. linux-2.4.1-pre3 removed the definition of
HAVE_XMM but did not revert the references in include/asm-i386/xor.h.
My guess is that cpu_has_xmm is the prefered name, so here is a patch
fixing include/asm-i386/xor.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."
--- linux-2.4.1-pre3/include/asm-i386/xor.h Fri Jan 12 05:29:00 2001
+++ linux/include/asm-i386/xor.hFri Jan 12 13:46:23 2001
@@ -843,7 +843,7 @@
do {\
xor_speed(&xor_block_8regs);\
xor_speed(&xor_block_32regs); \
- if (HAVE_XMM) \
+ if (cpu_has_xmm)\
xor_speed(&xor_block_pIII_sse); \
if (md_cpu_has_mmx()) { \
xor_speed(&xor_block_pII_mmx); \
@@ -855,4 +855,4 @@
We may also be able to load into the L1 only depending on how the cpu
deals with a load to a line that is being prefetched. */
#define XOR_SELECT_TEMPLATE(FASTEST) \
- (HAVE_XMM ? &xor_block_pIII_sse : FASTEST)
+ (cpu_has_xmm ? &xor_block_pIII_sse : FASTEST)
Re: [PATCH] one-liner fix for bforget() honoring BH_Protected; was: Re: Patch (repost): cramfs memory corruption fix
>From: "David L. Parsley" <[EMAIL PROTECTED]> >Linus Torvalds wrote: >> On Sat, 6 Jan 2001, Adam J. Richter wrote: >> > >> > This sounds like a bug that I posted a fix for a long time ago. >> > cramfs calls bforget on the superblock area, destroying that block of >> > the ramdisk, even when the ramdisk does not contain a cramfs file system. >> > Normally, bforget is called on block that really can be trashed, >> > such as blocks release by truncate or unlink. >> >> I'd really prefer just not letting bforget() touch BH_Protected buffers. >> bforget() is also used by other things than unlink/truncate: it's used by >> various partition codes etc, and it's used by the raid logic. >Yup, I backed out Adam's one-liner in favor of the attached one-liner. >Tested on 2.4.0, but should patch cleanly to just about anything. ;-) Applying Linus's patch is fine, but I think my patch should also be applied (in addition), although for a less important reason. The bforget in cramfs is going to force unnecessary device IO if cramfs is in the list of file systems that you are trying to detect when mounting a file system from a physical device. 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] Please read the FAQ at http://www.tux.org/lkml/
Patch: linux-2.4.0-pre1/arch/i386/i386_ksyms.c needs to export mmu_cr4_features
linux-2.4.1-pre1/drivers/md/xor.c calls the macro XOR_TRY_TEMPLATES, which is defined in include/asm-i386/xor.h to use HAVE_XMM, which is defined in include/asm-i386/processor.h to reference mmu_cr4_features. So, to support compilation of raid5 as a module, i386_ksyms.c needs to export mmu_cr4_features. I have attached the one line patch below. Let me also add that 2.4.1-pre1 so far has been really smooth sailing. The problems with 2.4.0 hanging on the Sony PictureBook PCG-C1VN have somehow disappeared with this version, usb-uhci.c does not generate a kernel oops on that hardware, and this minor addition to i386_ksyms.c was the only change that I had to make to get a clean build. Hooray! -- 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.1-pre1/arch/i386/kernel/i386_ksyms.c Wed Dec 6 21:00:12 2000 +++ linux/arch/i386/kernel/i386_ksyms.c Tue Jan 9 15:46:14 2001 @@ -49,6 +50,7 @@ /* platform dependent support */ EXPORT_SYMBOL(boot_cpu_data); +EXPORT_SYMBOL(mmu_cr4_features); #ifdef CONFIG_EISA EXPORT_SYMBOL(EISA_bus); #endif
Patch (repost): cramfs memory corruption fix
>From: "David L. Parsley" <[EMAIL PROTECTED]>
>
>Using root=/dev/ram0 and a cramfs initrd gives me 'wrong magic' when it
>tries to boot. Even more bizarre, if cramfs is compiled in the kernel
>when I use a romfs root, it says 'wrong magic' then mounts the romfs but
>can't find init. If I take cramfs out of the kernel, the romfs mounts &
>init runs fine. I just saw this with ac3.
>
>ramfs croaks with 'kernel BUG in filemap.c line 2559' anytime I make a
>file in ac2 and ac3. Works fine in 2.4.0 vanilla. Should be quite
>repeatable...
This sounds like a bug that I posted a fix for a long time ago.
cramfs calls bforget on the superblock area, destroying that block of
the ramdisk, even when the ramdisk does not contain a cramfs file system.
Normally, bforget is called on block that really can be trashed,
such as blocks release by truncate or unlink. If it worked for
you before, you were just getting lucky. Here is the patch.
Linus, please consider applying this. Thank you.
By the way, the other approach to fixing this problem would
be to change bforget not to trash blocks marked with BH_Protected
(I think that is just ramdisk blocks), but that would waste memory,
because we really can release blocks from things like truncating
or unlinking files.
--
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."
--- /tmp/adam/linux-2.4.0/fs/cramfs/inode.c Fri Dec 29 14:07:57 2000
+++ linux/fs/cramfs/inode.c Sat Dec 30 02:12:06 2000
@@ -138,7 +138,7 @@
struct buffer_head * bh = bh_array[i];
if (bh) {
memcpy(data, bh->b_data, PAGE_CACHE_SIZE);
- bforget(bh);
+ brelse(bh);
} else
memset(data, 0, PAGE_CACHE_SIZE);
data += PAGE_CACHE_SIZE;
Re: devfs breakage in 2.4.0 release
On my Sony PictureBook PCG-C1VN, 2.4.0 hangs in the boot process while 2.4.0-prerelease boots just fine. At first I thought the problem was devfs-related, but skipping devfsd just caused the hang to occur a little later, this time in ifconfig. The kernel call trace looked something like this: neigh_ifdown sys_ioctl sock_ioctl [some addresses in modules] stext_lock __down_failed __down What surprised me more was that attempting to remount the root filesystem for writing just before this (to record the module kernel symbols) caused a kenel BUG() in slab.c:1542 becuase kmalloc was being called with a huge negative number. I know I could run ksymoops to get this trace, but I now think the cause of the problem probably happens much earlier than the symptoms. So, I trying backing out different 2.4.0 changes. So far, I can tell you that reverting the linux/mm subdirectory to its 2.4.0-prerelease contents had no effect. I will let you know if I diagnose or fix the problem, as I think you may be experiencing the same problem. 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] Please read the FAQ at http://www.tux.org/lkml/
minor acpi cleanups against 2.4.0-prerelease
I have not yet isolated the problem that causes acpi to hang
on initialization on my Sony PCG-1VN PictureBook (and which Suresh
reports also occurs on a Sony Vaio F250), but in the course of
tracking down the problem, I have noticed some code that needed
to be cleaned up, so I would like to at least hit that ball out
of my court. I have attached the patch to this email.
The changes are as follows:
o namesapce/nsxfobj.c: acpi_ns_get_device_callback
had two identical calls to acpi_cm_release_mutex,
each of which was the first statement executed
depending on the result of an if statement, and
the condition being evaluated did not need the lock.
This folds the acpi_cm_release_mutex calls into a single
one before the if.
o namespace/nseval.c: acpi_ns_evaluate_by_handle
had a goto target that was only reachable from one
point in the code. Moving the target code to where
the goto used to be further simplified it.
o BUG: namespace/nseval.c: acpi_ns_execute_control_method
would not would return without releasing the
ACPI_MTX_NAMESPACE mutex if acpi_ns_get_attached_obect
returned NULL.
--
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.0-prerelease/drivers/acpi/namespace/nsxfobj.c Fri Dec 29 14:07:21
2000
+++ linux/drivers/acpi/namespace/nsxfobj.c Mon Jan 1 01:37:10 2001
@@ -578,15 +578,13 @@
info = context;
acpi_cm_acquire_mutex (ACPI_MTX_NAMESPACE);
-
node = acpi_ns_convert_handle_to_entry (obj_handle);
+ acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
+
if (!node) {
- acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
return (AE_BAD_PARAMETER);
}
- acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
-
/*
* Run _STA to determine if device is present
*/
@@ -694,4 +692,4 @@
acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
return (status);
-}
\ No newline at end of file
+}
--- linux-2.4.0-prerelease/drivers/acpi/namespace/nseval.c Fri Dec 29 14:07:21
2000
+++ linux/drivers/acpi/namespace/nseval.c Mon Jan 1 01:37:10 2001
@@ -253,8 +253,8 @@
node = acpi_ns_convert_handle_to_entry (handle);
if (!node) {
- status = AE_BAD_PARAMETER;
- goto unlock_and_exit;
+ acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
+ return (AE_BAD_PARAMETER);
}
@@ -316,12 +316,6 @@
* so we just return
*/
return (status);
-
-
-unlock_and_exit:
-
- acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
- return (status);
}
@@ -357,10 +351,6 @@
/* Verify that there is a method associated with this object */
obj_desc = acpi_ns_get_attached_object ((ACPI_HANDLE) method_node);
- if (!obj_desc) {
- return (AE_ERROR);
- }
-
/*
* Unlock the namespace before execution. This allows namespace access
@@ -371,6 +361,10 @@
*/
acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
+
+ if (!obj_desc) {
+ return (AE_ERROR);
+ }
/*
* Excecute the method via the interpreter
Re: Patch(?): linux-2.4.0-prerelease/drivers/char/drm/Makefile libdrm symbol versioning fix
>> = Adam Richter > = Keith Owens >> There is a thread in linux-kernel about how somewhere in >>linux-2.4.0-test13-preX, the Makefile for drivers/char/drm started >>building libdrm.a and not versioning the symbols. I believe the >>following patch fixes the problem, but I have not tried it for the >>nonmodular case. >> >> The change is that libdrm.o is built instead of libdrm.a. This >>object is linked into the kernel if at least one driver that needs it >>is also linked into the kernel. Otherwise, it is built as a helper >>module which is automatically loaded by modprobe when a module that >>needs it is loaded. >Having drmlib.o as a helper module will defeat the requirements listed >in drivers/char/drm/Makefile (below). You end up with one copy of the >library being used by all modules. See my patch earlier today on l-k >that builds two versions of drmlib.a, for kernel and module. That >patch preserves the drm requirements. ># libs-objs are included in every module so that radical changes to the ># architecture of the DRM support library can be made at a later time. ># ># The downside is that each module is larger, and a system that uses ># more than one module (i.e., a dual-head system) will use more memory ># (but a system that uses exactly one module will use the same amount of ># memory). ># ># The upside is that if the DRM support library ever becomes insufficient ># for new families of cards, a new library can be implemented for those new ># cards without impacting the drivers for the old cards. This is significant, ># because testing architectural changes to old cards may be impossible, and ># may delay the implementation of a better architecture. We've traded slight ># memory waste (in the dual-head case) for greatly improved long-term ># maintainability. >BTW, I disagree with this approach but I guess it is up to the drm >maintainers. Like you, I disagree with this approach, but, if I have not missed some important information, then I hope the drm maintainers with see the light or, failing that, the Linus will just delete those comments from linux/drivers/char/drm/Makefile anyhow and integrate a patch like the one I posted. Kernel interfaces change radically all the time, and we make better tradeoffs to deal with the same issues of maintaining support for old hardware which might not be tested right away all the time. For example, we currently maintain two styles of PCI device drivers. The drm maintainers could just write a libdrm2 library if the need arose and depmod/modprobe would automatically load it when necessary if they designed it the normal way. Imagine how huge the kernel modules would be if every facility in the kernel duplicated itself as an object file in every module. Why should drm be treated differently? It an especially bad tradeoff to take on the maintenance costs of a weird kernel build (that drm users are already complaining about on linux-kernel) for a facility like drm, which is a graphics optimization for applications that are willing to go to some trouble to use it. Users of these applications will be disproprionately quick to upgrade or (for example, in embedded applications) some organization will care enough and have resources enough to at least report bugs and test fixes. This is like recoding i386 floating point emulation into assembly. The performance/maintence tradeoff is not worth it, because 386's have already obscelesced from those applications, and still would have, even with FP emulation in assembly. It's not my call to make, and I think we will follow the stock kernels' drivers/char/drm even if it continues this weirdness, but I certainly hope this duplication of libdrm in every module will be dropped. 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] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch(?): linux-2.4.0-prerelease/drivers/char/drm/Makefile libdrm symbol versioning fix
On Mon, Jan 01, 2001 at 05:45:05PM +1100, Keith Owens wrote: > Having drmlib.o as a helper module will defeat the requirements listed > in drivers/char/drm/Makefile (below). You end up with one copy of the > library being used by all modules. See my patch earlier today on l-k > that builds two versions of drmlib.a, for kernel and module. That > patch preserves the drm requirements. > > # libs-objs are included in every module so that radical changes to the > # architecture of the DRM support library can be made at a later time. > # > # The downside is that each module is larger, and a system that uses > # more than one module (i.e., a dual-head system) will use more memory > # (but a system that uses exactly one module will use the same amount of > # memory). > # > # The upside is that if the DRM support library ever becomes insufficient > # for new families of cards, a new library can be implemented for those new > # cards without impacting the drivers for the old cards. This is significant, > # because testing architectural changes to old cards may be impossible, and > # may delay the implementation of a better architecture. We've traded slight > # memory waste (in the dual-head case) for greatly improved long-term > # maintainability. > > BTW, I disagree with this approach but I guess it is up to the drm > maintainers. Like you, I also disagree with this approach, but I think it is ugly enough and has so little justification that I see, that I _currently_ hope that those comments from the Makefile will simply be deleted. If radical changes were necessary, the drm maintainers could always write libdrm2 and modules that needed that would pick it up via depmod/modprobe. We have radical changes all the time in kernel interfaces (for example, the "new style" PCI initilialization) and deal with the same issues of wanting to support old methods for old hardware for a while. Imagine if the rest of the kernel took this approach. The issue of supporting old hardware is particularly inapplicable to drm, because drm, given that the shortcut to the framebuffer that is drm is for situations where one is willing to go some trouble to get really fast graphics performance. Users of those applications will be disproprortionately likely to keep up with hardware. This is like recoding i386 floating point into assembly language: the performance vs. maintenance trade off is not worth it because 386's have migrated to tasks where that performance is not valued at all (otherwise they'd be upgraded to 486's at least). And, yes, I am saying that the approach of replicating the .o files is *harder* to maintain, because it is an unusual build scheme and increases the resource cost of enabling drm, encouraging small (such as boot-over-network) systems to drop it. Also, from looking in the list of external symbols that the drm modules resolve, it is also clear to me that replicating these object files will not result in binary modules that work with many kernel versions, if that is what they were aiming for. Anyhow, it is not my call, and there probably aren't any more keystrokes for me to generate with respect to this issue, but if there is not some information that I have missed about this issue, then I sure hope that the drm maintainers will see the light or, if not, that Linus overrules the drm maintainers if necessary and integrates a patch like the one I posted and just deletes those comments from drivers/char/drm/Makefile. 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] Please read the FAQ at http://www.tux.org/lkml/
Patch(?): linux-2.4.0-prerelease/drivers/char/drm/Makefile libdrm symbol versioning fix
There is a thread in linux-kernel about how somewhere in linux-2.4.0-test13-preX, the Makefile for drivers/char/drm started building libdrm.a and not versioning the symbols. I believe the following patch fixes the problem, but I have not tried it for the nonmodular case. The change is that libdrm.o is built instead of libdrm.a. This object is linked into the kernel if at least one driver that needs it is also linked into the kernel. Otherwise, it is built as a helper module which is automatically loaded by modprobe when a module that needs it is loaded. This change takes advantage of the new style Makefile rules to achieve this end. I think it basically is the correct approach, although I have not yet tested compilation into the kernel. Any testing and feedback would be appreciated. -- 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.0-prerelease/drivers/char/drm/MakefileFri Dec 29 14:07:21 2000 +++ linux/drivers/char/drm/Makefile Fri Dec 22 01:50:11 2000 @@ -44,43 +44,37 @@ mga-objs := mga_drv.o mga_dma.o mga_context.o mga_bufs.o mga_state.o i810-objs := i810_drv.o i810_dma.oi810_context.o i810_bufs.o -obj-$(CONFIG_DRM_GAMMA) += gamma.o -obj-$(CONFIG_DRM_TDFX) += tdfx.o -obj-$(CONFIG_DRM_R128) += r128.o -obj-$(CONFIG_DRM_FFB) += ffb.o -obj-$(CONFIG_DRM_MGA) += mga.o -obj-$(CONFIG_DRM_I810) += i810.o +obj-$(CONFIG_DRM_GAMMA) += gamma.o drmlib.o +obj-$(CONFIG_DRM_TDFX) += tdfx.o drmlib.o +obj-$(CONFIG_DRM_R128) += r128.o drmlib.o +obj-$(CONFIG_DRM_FFB) += ffb.o drmlib.o +obj-$(CONFIG_DRM_MGA) += mga.o drmlib.o +obj-$(CONFIG_DRM_I810) += i810.o drmlib.o # When linking into the kernel, link the library just once. # If making modules, we include the library into each module -ifdef MAKING_MODULES - lib = drmlib.a -else - obj-y += drmlib.a -endif - include $(TOPDIR)/Rules.make -drmlib.a: $(lib-objs) +drmlib.o: $(lib-objs) rm -f $@ - $(AR) $(EXTRA_ARFLAGS) rcs $@ $(lib-objs) + $(LD) -r -o $@ $(lib-objs) -gamma.o: $(gamma-objs) $(lib) - $(LD) -r -o $@ $(gamma-objs) $(lib) +gamma.o: $(gamma-objs) + $(LD) -r -o $@ $(gamma-objs) -tdfx.o: $(tdfx-objs) $(lib) - $(LD) -r -o $@ $(tdfx-objs) $(lib) +tdfx.o: $(tdfx-objs) + $(LD) -r -o $@ $(tdfx-objs) -mga.o: $(mga-objs) $(lib) - $(LD) -r -o $@ $(mga-objs) $(lib) +mga.o: $(mga-objs) + $(LD) -r -o $@ $(mga-objs) -i810.o: $(i810-objs) $(lib) - $(LD) -r -o $@ $(i810-objs) $(lib) +i810.o: $(i810-objs) + $(LD) -r -o $@ $(i810-objs) -r128.o: $(r128-objs) $(lib) - $(LD) -r -o $@ $(r128-objs) $(lib) +r128.o: $(r128-objs) + $(LD) -r -o $@ $(r128-objs) -ffb.o: $(ffb-objs) $(lib) - $(LD) -r -o $@ $(ffb-objs) $(lib) +ffb.o: $(ffb-objs) + $(LD) -r -o $@ $(ffb-objs)
PATCH: linux-2.4.0-prerelease/drivers/scsi/ibmmca.c module fixes
linux-2.4.0-prerelease/drivers/scsi/ibmmca.c does not link
as a module because some necessary code is bracketed in
"#ifdef CONFIG_SCSI_IBMMCA", when it should be brakceted in
"#if defined(CONFIG_SCSI_IBMMCA) || defined(CONFIG_SCSI_IBMMCA_MODULE)".
The driver also had a symbol versioning problem a while ago,
which was somehow related to the fact that it included
pretty late in the source code. I am not sure if that problem still
exists, but putting "#include " in the initial block of
includes without any ifdefs seems to be the standard, so this change
should be regarded as a stylistic cleanup even if we are not forced
to make the 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."
--- linux-2.4.0-prerelease/drivers/scsi/ibmmca.cSun Dec 31 09:36:15 2000
+++ linux/drivers/scsi/ibmmca.c Sun Dec 31 21:21:20 2000
@@ -16,6 +16,8 @@
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
#error "This driver works only with kernel 2.4.0 or higher!"
#endif
+
+#include
#include
#include
#include
@@ -443,7 +445,6 @@
(that is kernel version 2.1.x) */
#if defined(MODULE)
static char *boot_options = NULL;
-#include
MODULE_PARM(boot_options, "s");
MODULE_PARM(io_port, "1-" __MODULE_STRING(IM_MAX_HOSTS) "i");
MODULE_PARM(scsi_id, "1-" __MODULE_STRING(IM_MAX_HOSTS) "i");
@@ -1399,7 +1400,7 @@
return 0;
}
-#ifdef CONFIG_SCSI_IBMMCA
+#if defined(CONFIG_SCSI_IBMMCA) || defined(CONFIG_SCSI_IBMMCA_MODULE)
void internal_ibmmca_scsi_setup (char *str, int *ints)
{
int i, j, io_base, id_base;
PATCH: __bad_udelay fixes(?) for linux-2.4.0-prerelease
linux-2.4.0-prerelease changes the udelay() macro defined
in linux/include/asm-i386/delay.h to reference the undefined symbol
__bad_udelay if udelay is called with a constant exceeding 2
(that is, 20 milliseconds). I guess the purpose of this change is
to tell driver maintainers to either take a harder look at whether they
really need to do a busy sleep for that long (you can still do it with
a loop) or have them give up the CPU during the sleep (although I do not see
a simple helper routine in the kernel to do this). This change prevents
four modules in 2.4.0-prerelease from linking. I have attached a patch
allowing them to link, but I would appreciate feedback on whether my
patches are the best approach. Here is a summary:
drivers/net/tokenring/smctr.c - I think this is the only file that had
a real bug. The comments say it is
delaying for 2ms in two places, but the
code actually asks for a delay of 200ms
in each place. I have changed it to
really only delay 2ms in each place.
I would like to know if it still drives
the hardware correctly. PLEASE TEST.
drivers/net/irda/tohoboe.c - The code already has a FIXME and it
currently does 10 iterations of 100ms
delays, checking a register at each loop.
I have changed it to do 1000 iterations of
1ms. It is the same maximum delay, but
it will exit faster once the event that
it is looking for occurs. Is there a
better fix?
drivers/video/atyfb.c - An intentional 50ms delay.
drivers/video/clgenfb.c - An intentional 100ms delay.
I've changed both files to keep the
delays by using mdelay instead of udelay.
Perhaps somebody could check the
approaprirate documentation and test
on real hardware to determine if the
delays really need to be this long.
Anyhow, I think we should try to resolve the __bad_udelay
problems somehow by, say, linux-2.4.0-prerelease79. :-)
--
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.0-prerelease/drivers/net/tokenring/smctr.cMon Oct 16 12:58:51
2000
+++ linux/drivers/net/tokenring/smctr.c Sun Dec 31 21:23:07 2000
@@ -4445,10 +4445,10 @@
int ioaddr = dev->base_addr;
/* Reseting the NIC will put it in a halted and un-initialized state. */
smctr_set_trc_reset(ioaddr);
-udelay(20); /* ~2 ms */
+udelay(2000); /* ~2 ms */
smctr_clear_trc_reset(ioaddr);
-udelay(20); /* ~2 ms */
+udelay(2000); /* ~2 ms */
/* Remove any latched interrupts that occured prior to reseting the
* adapter or possibily caused by line glitches due to the reset.
--- linux-2.4.0-prerelease/drivers/net/irda/toshoboe.c Sun Nov 12 20:43:11 2000
+++ linux/drivers/net/irda/toshoboe.c Sun Dec 31 21:23:07 2000
@@ -881,7 +892,7 @@
static void
toshoboe_gotosleep (struct toshoboe_cb *self)
{
- int i = 10;
+ int i = 1000;
printk (KERN_WARNING "ToshOboe: suspending\n");
@@ -896,7 +907,7 @@
/*FIXME: can't sleep here wait one second */
while ((i--) && (self->txpending))
-udelay (10);
+udelay (1000);
toshoboe_stopchip (self);
toshoboe_disablebm (self);
--- linux-2.4.0-prerelease/drivers/video/atyfb.cSun Dec 3 17:45:23 2000
+++ linux/drivers/video/atyfb.c Sun Dec 31 21:23:07 2000
@@ -1754,7 +1797,7 @@
aty_st_8(CLOCK_CNTL + info->clk_wr_offset, old_clock_cntl | CLOCK_STROBE,
info);
-udelay(5); /* delay for 50 (15) ms */
+mdelay(50); /* delay for 50 (15) ms */
aty_st_8(CLOCK_CNTL + info->clk_wr_offset,
((pll->locationAddr & 0x0F) | CLOCK_STROBE), info);
--- linux-2.4.0-prerelease/drivers/video/clgenfb.c Tue Nov 7 10:59:43 2000
+++ linux/drivers/video/clgenfb.c Sun Dec 31 21:23:07 2000
@@ -1899,7 +1926,7 @@
break;
case BT_PICASSO4:
vga_wcrt (fb_info->regs, CL_CRT51, 0x00); /* disable
flickerfixer */
- udelay (10);
+ mdelay (100);
vga_wgfx (fb_info
test13-pre[567]: acpi infinite loop on Sony PictureBook (Transmeta version)
At least when I build acpi as a module under 2.4.0-test13-pre5
(which requires tweaking the Makefiles and a config.in, but no
modifications to .c or .h files), acpi gets into an infinite loop
when it is loaded as a module on a Transmeta-based Sony PictureBook.
The same kernel+module loads fine on a desktop machine that I tried,
and doing the same on 2.4.0-test13-pre3 works fine on both computers.
The problem is still in test13-pre7.
From a day of reboots and printk's, I know that the infinite
loop includes at the following call hierarchy:
acpi_resolve_to_value
acpi_resolve_node_to_value
acpi_aml_access_named_field
acpi_aml_read_field
acpi_aml_read_field_data
I also know that, elsewhere in the inifinite loop,
acpi_release_parse_tree is called, as are acpi_cm_{acquire,release}_mutex.
I know that the following calls are made shortly before
the infinite loop starts:
acpi_aml_exec_store
acpi_aml_store_object_to_node
acpi_aml_access_named_field
acpi_aml_write_field
acpi_aml_write_field_data
I will explore this more tomorrow, but I have been exploring
this problem on and off for three days, so I thought I ought to
mention it on linux-kernel.
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]
Please read the FAQ at http://www.tux.org/lkml/
linux-2.4.0-test13-pre6 undefined symbols: prepare_etherdev, publish_netdev
It looks like 2.4.0-test13-pre6 contains a partially applied patch in net/atm/lec.c. It adds references to the symbols prepare_etherdev and publish_netdev, which are not defined anywhere. 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] Please read the FAQ at http://www.tux.org/lkml/
PATCH: test13-pre5/drivers/sound/via82cxxx_audio.c did not compile
linux-2.4.0-test13-pre5 eliminated vm_operations_struct->swapout,
but this change was not reflected in drivers/sound/via82cxxx_audio.c,
causing that file to fail to compile. I have attached what I believe
is the correct fix below.
via82cxxx_audio.c has Jeff Garzik's name on it, but I understand
that he is taking a break for a few weeks to recover from typing strain.
(Hope you recover soon, Jeff.) Consequently, I am not sure whom I should
ask to "bless" this change. So, I'll just send this to linux-kernel
and Linus and will leave it to linux-kernel readers to sound the alarm
if I botched the 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."
--- linux-2.4.0-test13-pre5/drivers/sound/via82cxxx_audio.c Mon Oct 30 12:24:22
2000
+++ linux/drivers/sound/via82cxxx_audio.c Fri Dec 29 16:53:22 2000
@@ -1727,20 +1727,8 @@
}
-#ifndef VM_RESERVE
-static int via_mm_swapout (struct page *page, struct file *filp)
-{
- return 0;
-}
-#endif /* VM_RESERVE */
-
-
struct vm_operations_struct via_mm_ops = {
nopage: via_mm_nopage,
-
-#ifndef VM_RESERVE
- swapout:via_mm_swapout,
-#endif
};
Proposal: devfs names ending in %d or %u
It seems that just about everything that uses devfs
contains some logic that attempts to construct an unused
device name with something like:
static devnum = 0;
sprintf (name, "lp%d", devnum++);
devfs_register_device(..., name,...);
Besides duplicating a lot of logic, making devfs support
more of a pain to add and uglier to look at, the numbering behvior
of these drivers can be inconsistent, especially if some devices
are being removed. For example, as I insert and remove my PCMCIA
flash card, it becomes /dev/discs/disc1, /dev/discs/disc2,
/dev/discs/disc3, etc.
I propose to change the devfs registration functions
to allow registrations of devices ending in %d or %u, in which
case it will use the first value, starting at 0, that generates a
string that already registered. So, if I have disc0, disc1, and disc2,
and I remove the device containing disc1, then disc1 will be next
disc device name to be registered, then disc3, then disc4, etc.
Just to illustrate, I have attached a patch that should
do it for device files, but I also want to do this for symlinks and
possibly directories. So, I am not suggesting that anyone should
integrate this patch yet.
This will make it a bit simpler to add devfs support to
the remaining drivers that do not have it, and it will make
numbering within devfs much simpler by default. Of course, drivers
that want to do their own thing the current way would not be impeded
from doing so by this change.
Anyhow, I thought I should post this suggestion to see if
anyone has any objections, better ideas, improvements or comments.
--
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.0-test13-pre4/fs/devfs/base.c Fri Nov 17 11:36:27 2000
+++ linux/fs/devfs/base.c Sun Dec 10 13:50:29 2000
@@ -1238,6 +1253,7 @@
{
int is_new;
struct devfs_entry *de;
+int numeric_suffix;
if (name == NULL)
{
@@ -1292,8 +1308,16 @@
minor = next_devnum_block & 0xff;
++next_devnum_block;
}
-de = search_for_entry (dir, name, strlen (name), TRUE, TRUE, &is_new,
- FALSE);
+numeric_suffix = 0;
+do {
+ char realname[strlen(name)+11]; /* max 32-bit decimal integer is 10
+ characters, plus one for
+ terminating null. */
+ sprintf(realname, name, numeric_suffix);
+ numeric_suffix++;
+de = search_for_entry (dir, realname, strlen (realname), TRUE, TRUE,
+ &is_new, FALSE);
+} while (!is_new && de != NULL && strcmp(name+strlen(name)-2, "%d") == 0);
if (de == NULL)
{
printk ("%s: devfs_register(): could not create entry: \"%s\"\n",
fork/wait race in 2.4.0-pre?
I reported this problem a few months ago in bug-glibc and did not get any response, although that is not unexpected since it is unclear where the problem is. So that bug report and this report will probably serve just to chronicle the problem in case anybody sees something similar. Anyhow, the problem is that somehow fork or vfork (makes no difference) will return an apparently valid pid and then the child process will disappear. Calling wait or waitpid will return errno 10 (ECHILD, "no child process"), and will continue to return errno 10 if wait or waitpid is called again. I got lucky with some strategically placed printf's at a point where this problem sometimes appears and was able to determine that, at least when wait() is called, the signal handler for SIGCLD (17) is SIG_IGN (1), so it seems less likely that some userland facility is reaping the process, especially since one of the places where this problem occurs is a very simple program that does little more than fork and wait. This usually happens during the "configure" phase of our build process, which is right after about 2.5GB of sources have been extracted from CVS to a directory tree, so there may be some IO congestion that could lead to unusual timing relationships, leading to unsual results from race conditions. Also, the problem started occurring occasionally when the machine in question got an 866MHz CPU, and started occuring more often when it got a 1GHz CPU. So, more instructions per time slice seems to be a relevant factor. Anyhow, I know this is a very slippery bug and it may be months before it is tracked down either here or elsewhere, but I thought it would be helpful to at least document it for the linux-kernel archives. 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] Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] 2.4.0-test13pre3 acpi circular dependency
The following fixes a circular depency problem between
drivers/acpi/ and arch/{i386,ia64}/kernel/acpi.c. I think the
problem only occurs if you manually tweak the build to make
acpi.o as a module, but it still should be fixed. This patch
also fixes the Makefiles in drivers/acpi so that they do not
blow up if you try to build drivers/acpi as a module (these
are corrections to some variable names, not a new functional
addition to the Makefiles).
I have deliberately not included the patch to change
CONFIG_ACPI into a tristate because I wonder if there is some problem
with acpi.o as a module that I am not aware of that is the reason
that CONFIG_ACPI in the stock kernels is configured as a boolean, even
though there is module initialization code in drivers/acpi, that seems
to work just fine, at least for my purposes of deactivating the
power after a shutdown. Does anybody know if there some known problem
with acpi.o as a module?
I have attached my kernel patch below. If this meets with
no obections, can somebody bless this and "send" it to Linus for
integration?
On Tue, Dec 19, 2000 at 06:00:15PM -0800, Grover, Andrew wrote:
> I'm thinking arch/i386/kernel/acpi.c should just go away, yes?
>
> Its purpose is probably better served by an ifdef, like you mentioned.
[...]
> > From: Adam J. Richter [mailto:[EMAIL PROTECTED]]
> >
> > Although the stock linux-2.4.0-test13pre3 does not allow
> > one to build the acpi interpreter as a loadable module, I had
> > tweaked the Makefiles in previous kernels to do this (the supporting
> > code is there and it seemed to work, at least for shutting off the
> > power after a shutdown). Unfortunately, in 2.4.0-test13pre3, this
> > is no harder to do, because there is a circular dependency:
> >
> > drivers/acpi/ references acpi_get_rsdp_ptr in arch/i386/kernel/acpi.c,
> > and
> > arch/i386/kernel/acpi.c references acp_find_root_pointer in
> > drivers/acpi/.
> >
> >
> > I would like to recommend that the contents of
> > arch/i{386,a64}/kernel/acpi.c be merged back somewhere in
> > drivers/acpi/,
> > and just selected with Makefile options, ifdefs, or perhaps runtime
> > options (if the ia64 code is potentionally useable to an i386 kernel
> > that find itself running on an ia64 CPU, which will probably
> > be the case
> > with most Linux distributions initially installed on ia64 hardware).
> >
> > If need be, I would be willing to at least write a quick and
> > dirty #ifdef-based version of this proposed 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."
diff --new-file -r -u linux-2.4.0-test13-pre3/drivers/acpi/Makefile
linux/drivers/acpi/Makefile
--- linux-2.4.0-test13-pre3/drivers/acpi/Makefile Wed Dec 20 00:49:37 2000
+++ linux/drivers/acpi/Makefile Wed Dec 20 00:03:27 2000
@@ -3,6 +3,7 @@
#
O_TARGET := acpi.o
+obj-m := $(O_TARGET)
export-objs := ksyms.o
@@ -25,13 +26,23 @@
subdir-$(CONFIG_ACPI) += $(acpi-subdirs)
-obj-$(CONFIG_ACPI) := $(patsubst %,%.o,$(acpi-subdirs))
-obj-$(CONFIG_ACPI) += os.o ksyms.o
+obj-y := $(patsubst %,%.o,$(acpi-subdirs))
+obj-y += os.o ksyms.o
+
+$(patsubst %,%.o,$(acpi-subdirs)):
+ $(MAKE) $(MFLAGS) -C $$(basename $@ .o) ../$@
ifdef CONFIG_ACPI_KERNEL_CONFIG
- obj-$(CONFIG_ACPI) += acpiconf.o osconf.o
+ obj-y += acpiconf.o osconf.o
else
- obj-$(CONFIG_ACPI) += driver.o cmbatt.o cpu.o ec.o ksyms.o sys.o table.o
+ obj-y += driver.o cmbatt.o cpu.o ec.o ksyms.o sys.o table.o
+endif
+
+ifdef CONFIG_X86
+ obj-y += rsdp_x86.o
+endif
+ifdef CONFIG_IA64
+ obj-y += rsdp_ia64.o
endif
include $(TOPDIR)/Rules.make
diff --new-file -r -u linux-2.4.0-test13-pre3/drivers/acpi/common/Makefile
linux/drivers/acpi/common/Makefile
--- linux-2.4.0-test13-pre3/drivers/acpi/common/MakefileWed Dec 20 00:49:37
2000
+++ linux/drivers/acpi/common/Makefile Tue Dec 19 08:58:42 2000
@@ -4,7 +4,7 @@
O_TARGET := ../$(shell basename `pwd`).o
-obj-$(CONFIG_ACPI) := $(patsubst %.c,%.o,$(wildcard *.c))
+obj-y := $(patsubst %.c,%.o,$(wildcard *.c))
EXTRA_CFLAGS += -I../include
diff --new-file -r -u linux-2.4.0-test13-pre3/drivers/acpi/dispatcher/Makefile
linux/drivers/acpi/dispatcher/Makefile
--- linux-2.4.0-test13-pre3/drivers/acpi/dispatcher/MakefileWed Dec 20 00:49:37
2000
+++ linux/drivers/acpi/dispatcher/Makefile Tue Dec 19 08:58:42 2000
@@ -4,7 +4,7 @@
O_TARGET := ../$(shell basename `pwd`).o
-obj-$(CONFIG_ACPI) := $(patsubst %.c,%.o,$(wildcard *.c))
+obj-y := $(patsubst %.c,%.o,$(wildcard *
2.4.0-test13pre3 acpi circular dependency
Although the stock linux-2.4.0-test13pre3 does not allow
one to build the acpi interpreter as a loadable module, I had
tweaked the Makefiles in previous kernels to do this (the supporting
code is there and it seemed to work, at least for shutting off the
power after a shutdown). Unfortunately, in 2.4.0-test13pre3, this
is no harder to do, because there is a circular dependency:
drivers/acpi/ references acpi_get_rsdp_ptr in arch/i386/kernel/acpi.c,
and
arch/i386/kernel/acpi.c references acp_find_root_pointer in drivers/acpi/.
I would like to recommend that the contents of
arch/i{386,a64}/kernel/acpi.c be merged back somewhere in drivers/acpi/,
and just selected with Makefile options, ifdefs, or perhaps runtime
options (if the ia64 code is potentionally useable to an i386 kernel
that find itself running on an ia64 CPU, which will probably be the case
with most Linux distributions initially installed on ia64 hardware).
If need be, I would be willing to at least write a quick and
dirty #ifdef-based version of this proposed 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."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
PATCH: linux-2.4.0-test13pre3/arch/i386/math-emu/fpu_system.h compilation error
In linux-2.4.0-test13pre3 (or maybe pre1 or pre2), mm_struct->segments became mm_struct->context.segmnets. This change adjusts linux-2.4.0-test13pre3/arch/i386/math-emu/fpu_system.h accordingly so that i386 math emulation will compile again. -- 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.0-test13-pre3/arch/i386/math-emu/fpu_system.h Mon Dec 11 13:34:33 2000 +++ linux/arch/i386/math-emu/fpu_system.h Mon Dec 18 21:10:35 2000 @@ -20,7 +20,7 @@ of the stack frame of math_emulate() */ #define SETUP_DATA_AREA(arg) FPU_info = (struct info *) &arg -#define LDT_DESCRIPTOR(s) (((struct desc_struct *)current->mm->segments)[(s) >> 3]) +#define LDT_DESCRIPTOR(s) (((struct desc_struct +*)current->mm->context.segments)[(s) >> 3]) #define SEG_D_SIZE(x) ((x).b & (3 << 21)) #define SEG_G_BIT(x) ((x).b & (1 << 23)) #define SEG_GRANULARITY(x) (((x).b & (1 << 23)) ? 4096 : 1)
PATCH: linux-2.4.0-test12pre8/include/linux/module.h breaks sysklogd compilation
linux-2.4.0test12pre8/include/linux/module.h contains some kernel-specific declarations that now reference struct list_head, which which is only defined when __KERNEL__ is set. This causes sysklogd and probably any other user level program that needs to include to fail to compile. The following patch brackets the (unused) offending declarations in #ifdef __KERNEL__...#endif. -- 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." Index: linux/include/linux/module.h === RCS file: /usr/src.repository/repository/linux/include/linux/module.h,v retrieving revision 1.2 diff -u -r1.2 module.h --- linux/include/linux/module.h2000/12/04 11:57:16 1.2 +++ linux/include/linux/module.h2000/12/11 22:54:20 @@ -168,6 +168,7 @@ * Keith Owens <[EMAIL PROTECTED]> 28 Oct 2000. */ +#ifdef __KERNEL__ #define HAVE_INTER_MODULE extern void inter_module_register(const char *, struct module *, const void *); extern void inter_module_unregister(const char *); @@ -183,6 +184,7 @@ }; extern int try_inc_mod_count(struct module *mod); +#endif #if defined(MODULE) && !defined(__GENKSYMS__)
PATCH: linux-2.4.0-test12pre8: 17 files with compiler errors due to tq_struct->list.
I believe the following patch should complete the
conversion of tq_struct->next to tq_struct->list, at least for x86
platforms. There were seventeen files in 2.4.0-test12pre8 for x86 that
needed to be updated.
Please integrate with caution. I had never looked at the
contents of struct tq_struct before this.
--
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."
diff -u -r linux-2.4.0-test12pre8.ygg.orig/drivers/char/drm/gamma_dma.c
linux-2.4.0-test12pre8.ygg/drivers/char/drm/gamma_dma.c
--- linux-2.4.0-test12pre8.ygg.orig/drivers/char/drm/gamma_dma.cTue Oct 3
16:29:08 2000
+++ linux-2.4.0-test12pre8.ygg/drivers/char/drm/gamma_dma.c Sun Dec 10 19:34:25
+2000
@@ -651,7 +651,7 @@
dev->dma->next_queue = NULL;
dev->dma->this_buffer = NULL;
- dev->tq.next = NULL;
+ INIT_LIST_HEAD(&dev->tq.list);
dev->tq.sync = 0;
dev->tq.routine = gamma_dma_schedule_tq_wrapper;
dev->tq.data = dev;
diff -u -r linux-2.4.0-test12pre8.ygg.orig/drivers/char/drm/i810_dma.c
linux-2.4.0-test12pre8.ygg/drivers/char/drm/i810_dma.c
--- linux-2.4.0-test12pre8.ygg.orig/drivers/char/drm/i810_dma.c Tue Oct 3 16:29:09
2000
+++ linux-2.4.0-test12pre8.ygg/drivers/char/drm/i810_dma.c Sun Dec 10 19:35:01
+2000
@@ -924,7 +924,7 @@
dev->dma->next_queue = NULL;
dev->dma->this_buffer = NULL;
- dev->tq.next = NULL;
+ INIT_LIST_HEAD(&dev->tq.list);
dev->tq.sync = 0;
dev->tq.routine = i810_dma_task_queue;
dev->tq.data = dev;
diff -u -r linux-2.4.0-test12pre8.ygg.orig/drivers/char/drm/mga_dma.c
linux-2.4.0-test12pre8.ygg/drivers/char/drm/mga_dma.c
--- linux-2.4.0-test12pre8.ygg.orig/drivers/char/drm/mga_dma.c Mon Dec 4 03:35:45
2000
+++ linux-2.4.0-test12pre8.ygg/drivers/char/drm/mga_dma.c Sun Dec 10 19:35:44
+2000
@@ -818,7 +818,7 @@
dev->dma->next_buffer = NULL;
dev->dma->next_queue = NULL;
dev->dma->this_buffer = NULL;
- dev->tq.next = NULL;
+ INIT_LIST_HEAD(&dev->tq.list);
dev->tq.sync = 0;
dev->tq.routine = mga_dma_task_queue;
dev->tq.data = dev;
diff -u -r linux-2.4.0-test12pre8.ygg.orig/drivers/char/n_r3964.c
linux-2.4.0-test12pre8.ygg/drivers/char/n_r3964.c
--- linux-2.4.0-test12pre8.ygg.orig/drivers/char/n_r3964.c Wed May 3 05:34:57
2000
+++ linux-2.4.0-test12pre8.ygg/drivers/char/n_r3964.c Sun Dec 10 19:30:17 2000
@@ -1157,12 +1157,12 @@
* Add 'on_timer' to timer task queue
* (will be called from timer bh)
*/
- pInfo->bh_1.next = NULL;
+ INIT_LIST_HEAD(&pInfo->bh_1.list);
pInfo->bh_1.sync = 0;
pInfo->bh_1.routine = &on_timer_1;
pInfo->bh_1.data = pInfo;
- pInfo->bh_2.next = NULL;
+ INIT_LIST_HEAD(&pInfo->bh_2.list);
pInfo->bh_2.sync = 0;
pInfo->bh_2.routine = &on_timer_2;
pInfo->bh_2.data = pInfo;
@@ -1174,7 +1174,7 @@
static void r3964_close(struct tty_struct *tty)
{
- struct tq_struct *tq, *prev;
+ struct list_head *tq, *next;
struct r3964_info *pInfo=(struct r3964_info*)tty->disc_data;
struct r3964_client_info *pClient, *pNext;
struct r3964_message *pMsg;
@@ -1190,14 +1190,13 @@
save_flags(flags);
cli();
-for (tq=tq_timer, prev=0; tq; prev=tq, tq=tq->next) {
- if ((tq == &pInfo->bh_1) || (tq==&pInfo->bh_2)) {
- if (prev)
- prev->next = tq->next;
- else
- tq_timer = tq->next;
- break;
- }
+tq = &tq_timer;
+while (tq != NULL) {
+ next = tq->next;
+ if ((tq == (struct list_head*) &pInfo->bh_1) ||
+(tq == (struct list_head*) &pInfo->bh_2))
+ list_del(tq);
+tq = next;
}
restore_flags(flags);
diff -u -r linux-2.4.0-test12pre8.ygg.orig/drivers/i2o/i2o_lan.c
linux-2.4.0-test12pre8.ygg/drivers/i2o/i2o_lan.c
--- linux-2.4.0-test12pre8.ygg.orig/drivers/i2o/i2o_lan.c Wed Dec 6 23:36:42
2000
+++ linux-2.4.0-test12pre8.ygg/drivers/i2o/i2o_lan.cSun Dec 10 19:40:09 2000
@@ -113,7 +113,10 @@
static int lan_context;
static struct tq_struct i2o_post_buckets_task = {
- 0, 0, (void (*)(void *))i2o_lan_receive_post, (void *) 0
+ list: LIST_HEAD_INIT(i2o_post_buckets_task.list),
+ sync: 0,
+ routine: (void (*)(void *))i2o_lan_receive_post,
+ data: (void *) 0
};
/* Functions to handle message failur
Re: [PATCH] for YMF PCI sound cards
This ALSA-based Yamaha PCI driver does not have the changes from ALSA that were necessary to make it run on the Transmeta-based Sony PictureBooks, right? I tried the driver in 2.4.0-test12pre7, and that driver with Pavel's patch, and that driver with Pavel's patch with "#include , #undef CONFIG_SMP", and got the same behavior in all three cases: Loading the module would cause a very loud monotone squeal, like some kind of theft detection device. The computer would still work while it was sqealing, but sync'ing the discs would never return. rmmod'ing the module would cause a second noise to be superimposed on the first, one that sounded like a worn down fan or the purr that some BIOS'es make when they are testing RAM. If this version does not have whatever changes were need for the Transmeta-baed Picturebook, then never mind. If it is not some obvious oversight, I guess I will try installing ALSA and comparing the drivers. 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] Please read the FAQ at http://www.tux.org/lkml/
Patch: linux-2.4.0-test12-pre5/fs/udf/inode.c writepage still had extra parameter
Apparently, in linux 2.4.0-test12-pre5, address_space_operations->writepage went from having two parameters to just one. fs/udf/inode.c apparently was overlooked in the patch. Here is the one line 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." Index: linux/fs/udf/inode.c === RCS file: /usr/src.repository/repository/linux/fs/udf/inode.c,v retrieving revision 1.22 diff -u -r1.22 inode.c --- linux/fs/udf/inode.c2000/12/05 10:21:27 1.22 +++ linux/fs/udf/inode.c2000/12/05 11:27:54 @@ -202,7 +202,7 @@ mark_buffer_dirty(bh); udf_release_data(bh); - inode->i_data.a_ops->writepage(NULL, page); + inode->i_data.a_ops->writepage(page); UnlockPage(page); page_cache_release(page);
Re: Any good reason why these is so much memory "reserved"?
Gábor Lénárt writes: >On Tue, Dec 05, 2000 at 02:18:59AM -0800, Adam J. Richter wrote: >> Recently, I have had occasion to build a system on a floppy >> for a 4MB machine that we use as a router. In the past, the kernels > >I've played with this too. You can't use ramdisk easily on such a system. [snip] We are using such a system and have been for years. If you'll reread my posting, you will see that it is about relatively recent changes to the kernel that apparently have broken this. 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] Please read the FAQ at http://www.tux.org/lkml/
Any good reason why these is so much memory "reserved"?
Recently, I have had occasion to build a system on a floppy for a 4MB machine that we use as a router. In the past, the kernels that we have listed something like 400kB as the amount of memory "reserved" when they boot. Now, they claim to reserved 4MB when configured with CONFIG_HIGHMEM4G and 2MB when configured with CONFIG_NOHIGHMEM. The initial ramdisk then does not have enough space to decompress and the system halts (out of memory and no killable process). I am tracking this down and fix it (because the problem of building a small system has broader application than just this box). My current suspicion is that it is some problem with the "bootmem" changes of about six months ago. However, I thought I should post this message, in case there is some reason why the kernel really does need have to reserve all of this memory and that I should not try to change things back. 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] Please read the FAQ at http://www.tux.org/lkml/
Patch: x86 PCI IRQ's were not being routed in some cases (against 2.4.0-test11pre4)
I don't know if this is the fault of my notebook's BIOS
or Linux. However, Linux should work around bad BIOS'es where
feasible. So, here goes.
I have a Kapok 1100M notebook computer, which has a Pentium II,
apparently with a 440BX chipset. The BIOS fills in the PCI interrupt
routing tables (the thing that begins with "$PIR" in memory) with
information indicating that the USB controller is routed to IRQ 10,
and that that is the only IRQ that it can be routed to.
Linux apparently looks at this data and takes that to mean
that the wiring has already been done. However, this is not the case.
As far as I can tell, the BIOS is just suggesting that Linux configure
the 440BX chipset to that routing. (This BIOS does not have a
"Plug & Play OS" option.)
This has not always been a problem. If I recall correctly, kernels
up to somewhere in early 2.3.x worked.
To fix this problem, I have deleted a conditional in
pcibios_enable_irq, so that it will route the IRQ, even if it
thinks the work has already been done. Now, USB and my PCMCIA
flash cards work in that notebook computer again.
I do not have that solid of an understanding of PCI
initialization in Linux. I am still rather confused about what
routines are supposed to set up an interrupt if one is needed
and has not yet been routed for the device and which ones are supposed
to punt in case. For example, there is another problem that I
am trying to fix, where the motherboard BIOS on that other computer
sets the IRQ associated with the USB controller to zero, no matter
how I program the BIOS, and pcibios_lookup_irq takes this as reason
enough to refuse to allocate and route a new IRQ.
Anyhow, I have attached the patch for the lack of PCI IRQ
initialization below. The only change was to delete the first
"if" statement. The rest of the diff lines are just the resulting
intentation and bracketing 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."
--- linux-2.4.0-test12-pre4/arch/i386/kernel/pci-irq.c Mon Dec 4 03:28:20 2000
+++ linux/arch/i386/kernel/pci-irq.cTue Dec 5 00:20:25 2000
@@ -576,19 +576,17 @@
void pcibios_enable_irq(struct pci_dev *dev)
{
- if (!dev->irq) {
- u8 pin;
- pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
- if (pin && !pcibios_lookup_irq(dev, 1)) {
- char *msg;
- if (io_apic_assign_pci_irqs)
- msg = " Probably buggy MP table.";
- else if (pci_probe & PCI_BIOS_IRQ_SCAN)
- msg = "";
- else
- msg = " Please try using pci=biosirq.";
- printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %c of
device %s.%s\n",
- 'A' + pin - 1, dev->slot_name, msg);
- }
+ u8 pin;
+ pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
+ if (pin && !pcibios_lookup_irq(dev, 1)) {
+ char *msg;
+ if (io_apic_assign_pci_irqs)
+ msg = " Probably buggy MP table.";
+ else if (pci_probe & PCI_BIOS_IRQ_SCAN)
+ msg = "";
+ else
+ msg = " Please try using pci=biosirq.";
+ printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %c of device
+%s.%s\n",
+ 'A' + pin - 1, dev->slot_name, msg);
}
}
Transmeta and Linux-2.4.0-test12-pre3
Minutes after slashdot ran their article saying that the
Transmeta recall was limited to about 300 Fujitsu computers, I ran
to Fry's and bought a Sony PictureBook PCG-C1VN. Thank heavens for
those extended Christmas hours I thought, while praying that the
statements about the Crusoe problems being that limited would turn
out to be true.
This device is the only commercially available computer in the
world that uses a processor made by Transmeta (a 600MHz TMS5600, stepping
03). I thought surely that there would be a little subculture of
Linux PictureBook users at transmeta making sure that this particular
combination would work.
Well, alas, it appears that linux-2.4.0-test12-pre3 freezes hard
while reading the base address registers of the first PCI device
(the "host bridge"). Actually, I think the problem is some kind of
system management interrupt occuring at about this time, since the
exact point where the printk's stop gets earlier as I add more
printk's. With few printk's the printk's stop while the 6th base
address configuration register is being read; with more printk's it
stops at the second one, and it will stop in different places with
different boots, at least with the not-quite-stock kernels that I usually
use. Also, turning off interrupts during this code has no effect, so
I do not think it is directly caused by the something in the PictureBook
pepperring the processor with unexpected interrupts (I thought it might have
to do with the USB-based floppy disk).
Although the results of the debugging printk's that I added from
a somewhat modified linux-2.4.0-tset12-pre3 built for CONFIG_M386, I
also tried "pristine" linux-2.4.0-test12-pre3. When built with
CONFIG_M386 (which has historically been the way to get a kernel that
runs on all x86 processors), I get no output or other apparent
activity after the boot loader jumps to it. When buid with
CONFIG_MCRUSOE, it hangs after printing "PCI: Probing PCI Hardware",
just like our kernels (which, oddly, do work up this point even though
they are build with CONFIG_M386). In case anyone is curious, I have
put the .config file from the pristine CONFIG_MCRUOSOE build in
ftp://ftp.yggdrasil.com/private/adam/linux-crusoe/.config.
My initial attempts to find a processor manual on the tms5600
on the web and on Transmeta's web site have no yet turned up anything,
and I understand that the tms5600 includes the north bridge. So, I
assume that that would be the first place to look for ideas about
any weirdness that occurs during PCI initialization of the PCI host
bridge.
One sin that I am committing in these builds is that I am bulding
them under gcc-2.95.2, although I do not think this is the sort of
behavior that an optimizer bug is likely to produce.
If anyone out there is using Linux 2.4.0-test on a Sony
PictureBook PCG-C1VN (the Transmeta version), I would be interested in
at least trying to build from your .config file.
Memo to Transmeta management: buy Linus a PictureBook. :-)
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]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0"
Michael Meissner wrote:
>On Sat, Nov 25, 2000 at 11:55:11PM +, Tim Waugh wrote:
>> On Sat, Nov 25, 2000 at 10:53:00PM +, James A Sutherland wrote:
>>
>> > Which is silly. The variable is explicitly defined to be zero
>> > anyway, whether you put this in your code or not.
>>
>> Why doesn't the compiler just leave out explicit zeros from the
>> 'initial data' segment then? Seems like it ought to be tought to..
>
>Because sometimes it matters. For example, in kernel mode (and certainly for
>embedded programs that I'm more familiar with), the kernel does go through and
>zero out the so called BSS segment, so that normally uninitialized static
>variables will follow the rules as laid out under the C standards (both C89 and
>C99). I can imagine however, that the code that is executed before the BSS
>area is zeroed out needs to be extra careful in terms of statics that it
>references, and those must be hand initialized.
Since that code is already careful to hand initialize what
it needs and explicitly zeroes the BSS, that sounds like an argument
that it *is* safe to change gcc to move data that is intialized to
all zeroes into bss, either as a compiler option or even not
optionally.
I am not a gcc hacker, but it looks to me like one could
copy the code from output_constant and the functions that it
calls (in gcc-2.95.2/gcc/gcc/varasm.c) to walk the tree to figure
out if the data was all zeroes. I even started writing a routine
for assemble_variable to call to try to test just for the integer case
(basically just by cutting and pasting code). I include it here just
to illustrate. Note: this code doesn't even type check properly when
I try to compile it, so I know it's very wrong, but it's as good as
posting pseudo code to explain my thinking).
void
clear_zero_initialization(tree decl)
{
tree exp = DECL_INITIAL(decl);
enum tree_code code;
if (exp == NULL)
return;
code = TREE_CODE (TREE_TYPE (exp));
if (lang_expand_constant)
exp = (*lang_expand_constant) (exp);
while ((TREE_CODE (exp) == NOP_EXPR
&& (TREE_TYPE (exp) == TREE_TYPE (TREE_OPERAND (exp, 0))
|| AGGREGATE_TYPE_P (TREE_TYPE (exp
|| TREE_CODE (exp) == NON_LVALUE_EXPR)
exp = TREE_OPERAND (exp, 0);
if (code == INTEGER_TYPE && exp == const0_rtx)
DECL_INITIAL(decl) = NULL;
}
At the moment, I have started daydreaming about instead
writing an "elf squeezer" to do this and other space optimizations
by modifying objdump. However, I do think that such an improvement
to gcc would be at least a bit useful to the larger user base than
just those people who use binutils-based systems.
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]
Please read the FAQ at http://www.tux.org/lkml/
Re: initdata for modules?
Keith Owens <[EMAIL PROTECTED]> wrote:
>"Adam J. Richter" <[EMAIL PROTECTED]> wrote:
>> In reading include/linux/init.h, I was surprised to discover
>>that __init{,data} expands to nothing when compiling a module.
>>I was wondering if anyone is contemplating adding support for
>>__init{,data} in module loading, to reduce the memory footprints
>>of modules after they have been loaded.
>It has been discussed a few times but nothing was ever done about it.
>AFAIK the savings were not seen to be that important because modules
>occupy complete pages. __init would have to be stored in a separate
>page which was then discarded. [...]
No, you could just discard the part after the next page
boundary. The expected savings would be about the same, since
the cases where the original code had just creeped over a page
boundary in many cases would result in dropping more memory savings
that the actual init size, from dropping those unused bytes
between the very end of the init section and the end of that page.
I say "about" the same becuase the distribution of text and data
sizes is not uniformly random within some fixed interval.
Since you would not have to bump the start address of a
section to the next page boundary, I wonder if it would still
complicate insmod et al.
In case there is any confusion, I am not suggesting that
this should go into the stock 2.4.0 releases.
However, I do find it helpful in allocating my time to
cosider that saving one page by something like this or by enhancing
gcc's variable placement saves as much space as 1024 eliminations
of "= 0" or "= NULL" static variable initializations.
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]
Please read the FAQ at http://www.tux.org/lkml/
initdata for modules?
In reading include/linux/init.h, I was surprised to discover
that __init{,data} expands to nothing when compiling a module.
I was wondering if anyone is contemplating adding support for
__init{,data} in module loading, to reduce the memory footprints
of modules after they have been loaded.
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]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0"
Is there some reason why gcc does not put static data that is explicitly initialized to zero in .bss? If not, then fixing gcc would provide more space savings than these patches, and improve more software than just the Linux kernel. 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] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch: linux-2.4.0-test11ac4/drivers/net/tokenring/{tmspci,abyss}.c __devinit fixes
>From: Jeff Garzik <[EMAIL PROTECTED]> >"Adam J. Richter" wrote: >> I hope this patch will be applied both to the development >> version of the driver and, ideally, to Alan's tree, and really ideally, >> propagated to Linus with the rest of Adam Fritzler's port. >These are not fixes, please do not apply. > Jeff Please explain. 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] Please read the FAQ at http://www.tux.org/lkml/
Patch: 2.4.0-test11ac4 version of pci and isapnp device ID's patch
For those of you playing with Alan Cox's linux-2.4.0-test11ac4 release, I have made a separate patch of the remaining device ID changes which patches against that kernel and builds cleanly (the primary difference is that it omits the files that have gained the same ID tables in Alan's ac4 release). The patch is FTPable from: ftp://ftp.yggdrasil.com/pub/dist/device_control/kernel/pci_id_tables-2.4.0-test11-ac4.patch4.gz -- 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] Please read the FAQ at http://www.tux.org/lkml/
Patch: linux-2.4.0-test11ac4/drivers/net/tokenring/{tmspci,abyss}.c __devinit fixes
Hooray! I see that Alan has included a port of the
drivers/net/tokenring/{tmspci,abyss}.c to the new PCI interface,
presumably by Adam Fritzler.
This patch correct some minor errors where __devinit{,data}
should be used instead of __init{,data} so the driver does not
make illegal memory references in a hot plugging event. Even if
there is currently no hot pluggable version of these cards, I believe
the scenario would occur if you were to plug a notebook into
a PCI docking station that supports hot docking and had one of these
cards plugged in. So, the scenario can happen. I also added
__devinit to the eeprom reading routines, which are only called
by another __devinit routine.
I hope this patch will be applied both to the development
version of the driver and, ideally, to Alan's tree, and really ideally,
propagated to Linus with the rest of Adam Fritzler's port.
--
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."
diff -u -r linux-2.4.0-test11-ac4/drivers/net/tokenring/tmspci.c
linux-2.4.0-test11-ac4.hacked/drivers/net/tokenring/tmspci.c
--- linux-2.4.0-test11-ac4/drivers/net/tokenring/tmspci.c Sat Nov 25 21:15:17
2000
+++ linux-2.4.0-test11-ac4.hacked/drivers/net/tokenring/tmspci.cSat Nov 25
+21:51:49 2000
@@ -41,7 +41,7 @@
#include
#include "tms380tr.h"
-static char version[] __initdata =
+static char version[] __devinitdata =
"tmspci.c: v1.02 23/11/2000 by Adam Fritzler\n";
#define TMS_PCI_IO_EXTENT 32
@@ -58,7 +58,7 @@
{ {0x03, 0x01}, "3Com Token Link Velocity"},
};
-static struct pci_device_id tmspci_pci_tbl[] __initdata = {
+static struct pci_device_id tmspci_pci_tbl[] __devinitdata = {
{ PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_TOKENRING, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0 },
{ PCI_VENDOR_ID_SYSKONNECT, PCI_DEVICE_ID_SYSKONNECT_TR, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 1 },
{ PCI_VENDOR_ID_TCONRAD, PCI_DEVICE_ID_TCONRAD_TOKENRING, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 2 },
@@ -67,7 +67,7 @@
};
MODULE_DEVICE_TABLE(pci, tmspci_pci_tbl);
-static void tms_pci_read_eeprom(struct net_device *dev);
+static void __devinit tms_pci_read_eeprom(struct net_device *dev);
static unsigned short tms_pci_setnselout_pins(struct net_device *dev);
static unsigned short tms_pci_sifreadb(struct net_device *dev, unsigned short reg)
@@ -90,7 +90,7 @@
outw(val, dev->base_addr + reg);
}
-static int __init tms_pci_attach(struct pci_dev *pdev, const struct pci_device_id
*ent)
+static int __devinit tms_pci_attach(struct pci_dev *pdev, const struct pci_device_id
+*ent)
{
static int versionprinted;
struct net_device *dev;
@@ -192,7 +192,7 @@
* machine hard when this is called. Luckily, its supported in a
* seperate driver. --ASF
*/
-static void tms_pci_read_eeprom(struct net_device *dev)
+static void __devinit tms_pci_read_eeprom(struct net_device *dev)
{
int i;
@@ -219,7 +219,7 @@
return val;
}
-static void __exit tms_pci_detach (struct pci_dev *pdev)
+static void __devexit tms_pci_detach (struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
diff -u -r linux-2.4.0-test11-ac4/drivers/net/tokenring/abyss.c
linux-2.4.0-test11-ac4.hacked/drivers/net/tokenring/abyss.c
--- linux-2.4.0-test11-ac4/drivers/net/tokenring/abyss.cSat Nov 25 21:15:17
2000
+++ linux-2.4.0-test11-ac4.hacked/drivers/net/tokenring/abyss.c Sat Nov 25 21:52:49
+2000
@@ -41,12 +41,12 @@
#include "tms380tr.h"
#include "abyss.h"/* Madge-specific constants */
-static char version[] __initdata =
+static char version[] __devinitdata =
"abyss.c: v1.02 23/11/2000 by Adam Fritzler\n";
#define ABYSS_IO_EXTENT 64
-static struct pci_device_id abyss_pci_tbl[] __initdata = {
+static struct pci_device_id abyss_pci_tbl[] __devinitdata = {
{ PCI_VENDOR_ID_MADGE, PCI_DEVICE_ID_MADGE_MK2,
PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_NETWORK_TOKEN_RING << 8, 0x00ff, },
{ } /* Terminating entry */
@@ -91,7 +91,7 @@
outw(val, dev->base_addr + reg);
}
-static int __init abyss_attach(struct pci_dev *pdev, const struct pci_device_id *ent)
+static int __devinit abyss_attach(struct pci_dev *pdev, const struct pci_device_id
+*ent)
{
static int versionprinted;
struct net_device *dev;
@@ -390,7 +390,7 @@
* Read configuration data from the AT24 SEEPROM on Madge cards.
*
*/
-static void abyss_read_eeprom(struct net_device *dev)
+static void __devinit abyss_read_eeprom(struct net_device *dev)
{
struct net_local *tp;
unsigned long ioaddr;
@@ -432,7 +432,7 @@
Re: Patch(?): isapnp_card_id tables for all isapnp drivers in 2.4.0-test11
> == Kai Germaschewski
>> == Keith Owens
>>> == Adam Richter
>>> [...] I plan to go
>>>through all of the changes and bracket all of these new tables
>>>with #ifdef MODULE...#endif so they do not result in complaints
>>>about the table being defined static and never used in cases where
>>>the driver is compiled directly into the kernel.
(I have now done this and release the patch at
ftp://ftp.yggdrasil.com/pub/dist/device_control/kernel/.)
>> This is cleaner. Append MODULE_ONLY after __initdata and remove the
>> ifdef. It increases the size of initdata in the kernel, compared to
>> ifdef, but since initdata is promptly reused as scratch space it should
>> not be a problem.
[...]
>> +#define MODULE_ONLY __attribute__ ((unused))
>What about the making MODULE_DEVICE_TABLE reference this table? This has
>the same disadvantage (i.e. having a little unneeded __initdata in the
>kernel image), but it wouldn't need the rather ugly MODULE_ONLY macro.
>I'ld suggest something like this in module.h, #ifndef MODULE part:
>#define MODULE_DEVICE_TABLE(type,name) \
>static struct type##_device_id *__dummy_##name \
> __attribute__ ((unused, __section__(".text.exit"))) \
> = name;
I did not realize that this thread had been posted to
linux-kernel. Here is a response that I emailed to Keith Owens
and Kai Germaschewski that explains my reasons for sticking with
#ifndef MODULE...#endif rather than creating a new kernel facility
for something that, by the way, should become completely unused in
the next couple of months after 2.4.0 is released and the device
drivers are converted to the new PCI and isapnp interfaces:
|From: "Adam J. Richter" <[EMAIL PROTECTED]>
|To: [EMAIL PROTECTED]
|
|Thanks for the patch, but I think I'll stick with the ifdefs
|for now, for the following reasons.
|
|1. I think ifdef MODULE is more understandable to the casual observer.
|2. There is often some other condition that I need to combine
| with (CONFIG_PCI, CONFIG_ISAPNP, CONFIG_ISAPNP_MODULE).
|3. There is often an existing ifdef in the right place that I
| can just tuck the code into.
|4. I would prefer that this change not have even a file size cost
| to people who want to build minimal monolithic kernels
| for applicance applications.
|5. My feeling is that just the few kilobytes of file size cost
| associated with #4 and knowing that absolutely nothing is
| added for non-module usage will psychologically make
| maintainers feel better about it and have even fewer misgivings
| about integrating it.
|6. We can expect the lines bracketing these table declarations
| to be changed in the near future as the drivers are changed
| to use the new PCI and isapnp interfaces or to use the ID
| tables just to eliminate the old custom data structures that
| hold the same information.
|
|Thanks for the patch anyhow, though. It's a clever idea that
|may be useful in other situations.
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]
Please read the FAQ at http://www.tux.org/lkml/
Re: Patch(?): isapnp_card_id tables for all isapnp drivers in 2.4.0-test11
Keith Owens <[EMAIL PROTECTED]> wrote: >"Adam J. Richter" <[EMAIL PROTECTED]> wrote: >> Note that this is not a "final" version. I plan to go >>through all of the changes and bracket all of these new tables >>with #ifdef MODULE...#endif so they do not result in complaints >>about the table being defined static and never used in cases where >>the driver is compiled directly into the kernel. >This is cleaner. Append MODULE_ONLY after __initdata and remove the >ifdef. It increases the size of initdata in the kernel, compared to >ifdef, but since initdata is promptly reused as scratch space it should >not be a problem. [patch elided] Thanks for the patch, but I think I'll stick with the ifdefs for now, for the following reasons. 1. I think ifdef MODULE is more understandable to the casual observer. 2. There is often some other condition that I need to combine with (CONFIG_PCI, CONFIG_ISAPNP, CONFIG_ISAPNP_MODULE). 3. There is often an existing ifdef in the right place that I can just tuck the code into. 4. I would prefer that this change not have even a file size cost to people who want to build minimal monolithic kernels for applicance applications. 5. My feeling is that just the few kilobytes of file size cost associated with #4 and knowing that absolutely nothing is added for non-module usage will psychologically make maintainers feel better about it and have even fewer misgivings about integrating it. 6. We can expect the lines bracketing these table declarations to be changed in the near future as the drivers are changed to use the new PCI and isapnp interfaces or to use the ID tables just to eliminate the old custom data structures that hold the same information. Thanks for the patch anyhow, though. It's a clever idea that may be useful in other situations. 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] Please read the FAQ at http://www.tux.org/lkml/
Patch(?): isapnp_card_id tables for all isapnp drivers in 2.4.0-test11
I have made added isapnp_card_id table to all isapnp drivers.
This is the isapnp equivalent of the pci MODULE_DEVICE_TABLE declarations.
They allow a user level software agent to know which modules correspond
to your hardware configuration and to load them. One such implementation
(GPL'ed) is available from
ftp://ftp.yggdrasil.com/pub/dist/device_control/isapnpmodules/.
There previously were no isapnp_card_id tables in the kernel
drivers. I believe this patch adds isapnp_card_id tables to all of
them, completing the coverage of Keith Owens's
/lib/modules//modules.{pci,usb,isapnp}map files. I have
attached a patch below that covers just the files that have the
isapnp changes. Note that it includes a couple of pci_device_id
table declarations that happened to flow into the same "diff" sections
as the isapnp_card_id declarations. A complete set of patches
with both pci and isapnp declarations is available from
ftp://ftp.yggdrasil.com/pub/dist/device_control/kernel/pci_id_tables-2.4.0-test11.patch2.gz
Note that this is not a "final" version. I plan to go
through all of the changes and bracket all of these new tables
with #ifdef MODULE...#endif so they do not result in complaints
about the table being defined static and never used in cases where
the driver is compiled directly into the kernel. After 2.4.0, I
imainge most of those #ifdef MODULE conditions will go away
as the tables come to be actually used by the driver code.
Any comments are welcome.
--
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.0-test11/drivers/char/serial.cMon Oct 16 12:58:51 2000
+++ linux/drivers/char/serial.c Fri Nov 24 14:07:01 2000
@@ -4682,6 +4682,287 @@
unsigned short device;
};
+#define ISPNP_TBL_ENTRY(v1,v2,v3,func) { \
+ card_vendor: ISAPNP_ANY_ID, \
+ card_device: ISAPNP_ANY_ID, \
+ devs: { ISAPNP_DEVICE_ID(v1,v2,v3,func ) }, \
+}
+
+# ifdef MODULE
+static struct isapnp_card_id ixj_isa_ids[] __initdata = {
+ /* Archtek America Corp. */
+ /* Archtek SmartLink Modem 3334BT Plug & Play */
+ ISAPNP_TBL_ENTRY('A', 'A', 'C', 0x000F),
+ /* Anchor Datacomm BV */
+ /* SXPro 144 External Data Fax Modem Plug & Play */
+ ISAPNP_TBL_ENTRY('A', 'D', 'C', 0x0001),
+ /* SXPro 288 External Data Fax Modem Plug & Play */
+ ISAPNP_TBL_ENTRY('A', 'D', 'C', 0x0002),
+ /* Rockwell 56K ACF II Fax+Data+Voice Modem */
+ ISAPNP_TBL_ENTRY('A', 'K', 'Y', 0x1021),
+ /* AZT3005 PnP SOUND DEVICE */
+ ISAPNP_TBL_ENTRY('A', 'Z', 'T', 0x4001),
+ /* Best Data Products Inc. Smart One 336F PnP Modem */
+ ISAPNP_TBL_ENTRY('B', 'D', 'P', 0x3336),
+ /* Boca Research */
+ /* Boca Complete Ofc Communicator 14.4 Data-FAX */
+ ISAPNP_TBL_ENTRY('B', 'R', 'I', 0x0A49),
+ /* Boca Research 33,600 ACF Modem */
+ ISAPNP_TBL_ENTRY('B', 'R', 'I', 0x1400),
+ /* Boca 33.6 Kbps Internal FD34FSVD */
+ ISAPNP_TBL_ENTRY('B', 'R', 'I', 0x3400),
+ /* Boca 33.6 Kbps Internal FD34FSVD */
+ ISAPNP_TBL_ENTRY('B', 'R', 'I', 0x0A49),
+ /* Best Data Products Inc. Smart One 336F PnP Modem */
+ ISAPNP_TBL_ENTRY('B', 'D', 'P', 0x3336),
+ /* Computer Peripherals Inc */
+ /* EuroViVa CommCenter-33.6 SP PnP */
+ ISAPNP_TBL_ENTRY('C', 'P', 'I', 0x4050),
+ /* Creative Labs */
+ /* Creative Labs Phone Blaster 28.8 DSVD PnP Voice */
+ ISAPNP_TBL_ENTRY('C', 'T', 'L', 0x3001),
+ /* Creative Labs Modem Blaster 28.8 DSVD PnP Voice */
+ ISAPNP_TBL_ENTRY('C', 'T', 'L', 0x3011),
+ /* Creative */
+ /* Creative Modem Blaster Flash56 DI5601-1 */
+ ISAPNP_TBL_ENTRY('D', 'M', 'B', 0x1032),
+ /* Creative Modem Blaster V.90 DI5660 */
+ ISAPNP_TBL_ENTRY('D', 'M', 'B', 0x2001),
+ /* FUJITSU */
+ /* Fujitsu 33600 PnP-I2 R Plug & Play */
+ ISAPNP_TBL_ENTRY('F', 'U', 'J', 0x0202),
+ /* Fujitsu FMV-FX431 Plug & Play */
+ ISAPNP_TBL_ENTRY('F', 'U', 'J', 0x0205),
+ /* Fujitsu 33600 PnP-I4 R Plug & Play */
+ ISAPNP_TBL_ENTRY('F&#x
RFC: Security fix for demand loading of filesystem and network interface modules
I want to slightly change the way filesystems and network drivers are demand loaded via request_module. Currently, querying a nonexistant network interface named, say, "eth0" results in a result_module call for "eth0". I want to change that to "if-eth0". This will make it impossible for users to pass things like "-C/my/bogus/modules.config", or to cause the loading of legitimate but buggy module to crash the system. The changes to modutils that Keith Owens posted address the former problem, but not the latter, which is a pretty real possibility given that our current builds install 786 modules. This renaming is also useful because it will make it possible to make generic rules for modprobe that handle names that are unrecognized but are know to be a networking interface (for example, "if-funkylan0" might load all relevant modules that have PCI or USB class information indicating that they are network interfaces and which correspond to hardware that is present). Likewise, I want to change request_module calls that load file system modules (in fs/supser.c and fs/fat/cvf.c) to prefix them with "fs-". Of course these changes will add string length checking. Comments? Are the "fs-" and "if-" prefixes OK? (There are currently no real modules that have names beginning with those strings.) 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] Please read the FAQ at http://www.tux.org/lkml/
Patch: MODULE_DEVICE_TABLE's for all remaining PCI drivers in linux-2.4.0-test11
Anyhow, here is the patch for the drivers that I had not covered
in my previous posts. This includes atm, ieee1394, isdn, media/video,
video, and one driver in telephony. The larger pci_device_id tables
now use a macro to make the table more readable, as suggested by
Keith Owens and refined a bit by Jeff Garzik. Since this addresses
the reduncancy and readability issue with large tables, all of these
new tables use named initializers (by the way, I did not invent that
practice for pci_device_id tables; I think it originated in usb/usb-ohci.c
by David Brownell). Again, the complete patch covering all of the
MODULE_DEVICE_TABLE changes is FTPable from
ftp://ftp.yggdrasil.com/pub/dist/device_control/kernel/pci_id_tables-2.4.0-test11.patch.gz.
--
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.0-test11/include/linux/pci_ids.h Wed Nov 8 17:15:13 2000
+++ linux/include/linux/pci_ids.h Thu Nov 23 19:40:26 2000
@@ -119,6 +119,9 @@
/* Vendors and devices. Sort key: vendor first, device next. */
+#define PCI_VENDOR_ID_ASUSCOM 0x0675
+#define PCI_DEVICE_ID_ASUSCOM_TA1 0x1702
+
#define PCI_VENDOR_ID_COMPAQ 0x0e11
#define PCI_DEVICE_ID_COMPAQ_TOKENRING 0x0508
#define PCI_DEVICE_ID_COMPAQ_1280 0x3033
@@ -380,6 +383,10 @@
#define PCI_DEVICE_ID_OPTI_82C861 0xc861
#define PCI_DEVICE_ID_OPTI_82C825 0xd568
+#define PCI_VENDOR_ID_ELSA 0x1048
+#define PCI_DEVICE_ID_ELSA_MIRCOLINK 0x1000
+#define PCI_DEVICE_ID_ELSA_QS3000 0x3000
+
#define PCI_VENDOR_ID_SGS 0x104a
#define PCI_DEVICE_ID_SGS_2000 0x0008
#define PCI_DEVICE_ID_SGS_1764 0x0009
@@ -470,6 +477,7 @@
#define PCI_VENDOR_ID_APPLE0x106b
#define PCI_DEVICE_ID_APPLE_BANDIT 0x0001
#define PCI_DEVICE_ID_APPLE_GC 0x0002
+#define PCI_DEVICE_ID_APPLE_PLANB 0x0004
#define PCI_DEVICE_ID_APPLE_HYDRA 0x000e
#define PCI_DEVICE_ID_APPLE_UNINORTH 0x0020
@@ -561,15 +569,20 @@
#define PCI_DEVICE_ID_WINBOND_837690x0001
#define PCI_DEVICE_ID_WINBOND_82C105 0x0105
#define PCI_DEVICE_ID_WINBOND_83C553 0x0565
+#define PCI_DEVICE_ID_WINBOND_6692 0x6692
#define PCI_VENDOR_ID_DATABOOK 0x10b3
#define PCI_DEVICE_ID_DATABOOK_87144 0xb106
#define PCI_VENDOR_ID_PLX 0x10b5
+#define PCI_DEVICE_ID_SATSAGEM_NICCY 0x1016
+#define PCI_DEVICE_ID_PLX_R685 0x1030
#define PCI_VENDOR_ID_PLX_ROMULUS 0x106a
#define PCI_DEVICE_ID_PLX_SPCOM800 0x1076
#define PCI_DEVICE_ID_PLX_1077 0x1077
#define PCI_DEVICE_ID_PLX_SPCOM200 0x1103
+#define PCI_DEVICE_ID_PLX_DJINN_ITOO 0x1151
+#define PCI_DEVICE_ID_PLX_R753 0x1152
#define PCI_DEVICE_ID_PLX_9050 0x9050
#define PCI_DEVICE_ID_PLX_9060 0x9060
#define PCI_DEVICE_ID_PLX_9060ES 0x906E
@@ -798,6 +811,11 @@
#define PCI_DEVICE_ID_PHILIPS_SAA7145 0x7145
#define PCI_DEVICE_ID_PHILIPS_SAA7146 0x7146
+#define PCI_VENDOR_ID_EICON0x1133
+#define PCI_DEVICE_ID_EICON_DIVA20 0xe002
+#define PCI_DEVICE_ID_EICON_DIVA20_U 0xe004
+#define PCI_DEVICE_ID_EICON_DIVA2010xe005
+
#define PCI_VENDOR_ID_CYCLONE 0x113c
#define PCI_DEVICE_ID_CYCLONE_SDK 0x0001
@@ -1328,6 +1346,7 @@
#define PCI_VENDOR_ID_TIGERJET 0xe159
#define PCI_DEVICE_ID_TIGERJET_300 0x0001
+#define PCI_DEVICE_ID_TIGERJET_100 0x0002
#define PCI_VENDOR_ID_ARK 0xedd8
#define PCI_DEVICE_ID_ARK_STING0xa091
--- linux-2.4.0-test11/drivers/atm/ambassador.c Thu Jul 6 21:37:24 2000
+++ linux/drivers/atm/ambassador.c Thu Nov 23 21:08:24 2000
@@ -326,6 +326,17 @@
static const unsigned long onegigmask = -1 << 30;
+static struct pci_device_id ambassador_pci_tbl[] __initdata = {
+ {
+ vendor: PCI_VENDOR_ID_MADGE,
+ device: PCI_DEVICE_ID_MADGE_AMBASSADOR,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ },
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, ambassador_pci_tbl);
+
/** access to adapter **/
static inline void wr_plain (const amb_dev * dev, size_t addr, u32 data) {
--- linux-2.4.0-test11/drivers/atm/fore200e.c Mon Oct 16 12:56:50 2000
+++ linux/drivers/atm/fore200e.cThu Nov 23 21:03:28 2000
@@ -101,6 +101,17 @@
MODULE_AUTHOR("Christophe Lizzi - credits to Uwe Dannowski and Heikki Vatiainen");
MODULE_DESCRIPTION("FORE Systems 200E-series ATM driver - version " FORE200E_VERSION);
MODULE_SUPPORTED_DEVICE("PCA-200E, SBA-200E");
+
+static struct pci_device_id fore200e_pci_tbl[] __initdata = {
+ {
+ vendor: P
ohci1394 PCI device ID's
Sorry for the rather lengthy email list. I am not sure exactly which of you it would be appropriate to put this question to. I am writing a pci_device_id table for ohci1394.c. This will allow a userland program to automatically load the module when an ohci1394 card is present. There is a PCI device class for ohci1394 controllers (pci_dev->class == 0x0c0310). So, is there some reason why linux-2.4.0-test11/drivers/ieee1394/ohci1934.c contains a list of vendor_id/device_id pairs? If ohci1394.c really needs to match based on vendor_id and device_id, then I will generate a pci_device_id table accordingly. On the other hand, if ohci1394.c really does not need to care about vendor_id/device_id pairs, I will add the generic pci_device_id table for an ohci1394 controller, and I would also be happy to generate a patch for you folks that eliminates the use of the vendor_id / device_id pairs, and, if you want, ports the driver to the new hotplug PCI interface, which might be useful, considering that I see ieee1394 CardBus cards everywhere. Any feedback would be appreciated. Thanks in advance. 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] Please read the FAQ at http://www.tux.org/lkml/
