PATCH(?): linux-2.4.4-pre2: fork should run child first
I remember sometime in the late 80's a fellow at UniSoft
named Don whose last name escapes me just now told me about a
paper presented at a Usenix symposium that had some measurements
that purported that copy-on-write was a performance lose and
better performance would be achieve by having fork() just copy
all of the writable pages of the parent process.
It turned out that the particular unix-like system on which
these benchmarks were taken had a version of fork that did not run
the child first. As it was explained to me then, most of the time,
the child process from a fork will do just a few things and then do
an exec(), releasing its copy-on-write references to the parent's
pages, and that is the big win of copy-on-write for fork() in practice.
This oversight was considered a big embarassment for the operating
system in question, so I won't name it here.
Guess why you're seeing this email. That's right. Linux-2.4.3's
fork() does not run the child first. Consequently, the parent will
probably generate unnecessary copy-on-write page copies until it burns
through its remaining clock ticks (any COW's that the child causes will
basically happen no matter what the order of execution is) or calls
wait() (and while the wait is blocking, the parent's CPU priority will
decay as the scheduler periodically recalculates process priorities, so
that bit of dynamic priority has probably not been allocated where the
user will be able to use it, if we want to look at "fairness" in such
detail).
I suppose that running the child first also has a minor
advantage for clone() in that it should make programs that spawn lots
of threads to do little bits of work behave better on machines with a
small number of processors, since the threads that do so little work that
they accomplish they finish within their time slice will not pile up
before they have a chance to run. So, rather than give the parent's CPU
priority to the child only if CLONE_VFORK is not set, I have decided to
do a bit of machete surgery and have the child always inherit all of the
parent's CPU priority all of the time. It simplifies the code and
probably saves a few clock cycles (and before you say that this will
cost a context switch, consider that the child will almost always run
at least one time slice anyhow).
I have attached the patch below. I have also adjusted the
comment describing the code. Please let me know if this hand waving
explanation is sufficient. I'm trying to be lazy on not do a measurement
project to justify this relatively simple change. However, I do know, from
a simple test program ("printf ("%d", fork());"), that this patch has
the intended effect of running the child first.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.4-pre2/kernel/fork.c Thu Apr 12 01:31:53 2001
+++ linux/kernel/fork.c Thu Apr 12 01:35:53 2001
@@ -666,15 +666,17 @@
p->pdeath_signal = 0;
/*
-* "share" dynamic priority between parent and child, thus the
-* total amount of dynamic priorities in the system doesnt change,
-* more scheduling fairness. This is only important in the first
-* timeslice, on the long run the scheduling behaviour is unchanged.
+* Give the parent's dynamic priority entirely to the child. The
+* total amount of dynamic priorities in the system doesn't change
+* (more scheduling fairness), but the child will run first, which
+* is especially useful in avoiding a lot of copy-on-write faults
+* if the child for a fork() just wants to do a few simple things
+* and then exec(). This is only important in the first timeslice.
+* In the long run, the scheduling behavior is unchanged.
*/
- p->counter = (current->counter + 1) >> 1;
- current->counter >>= 1;
- if (!current->counter)
- current->need_resched = 1;
+ p->counter = current->counter;
+ current->counter = 0;
+ current->need_resched = 1;
/*
* Ok, add it to the run-queues and make it
List of all-zero .data variables in linux-2.4.3 available
For anyone who is interested, I have produced a list of all of the .data variables that contain all zeroes and could be moved to .bss within the kernel and all of the modules (all of the modules that we build at Yggdrasil for x86, which is almost all). These are global or static variables that have been declared int foo = 0; instead of int foo;/* = 0 */ The result is that the .o files are bigger than they have to be. The kernel memory image is not bigger, and gzip shrinks the runs of zeroes down to almost nothing, so it does not have a huge effect on bootable disks. Still, it would be nice to save the disk space of the approximately 75 kilobytes of zeroes and perhaps squeeze in another sector or two when building boot floppies. I have also included a copy of the program that I wrote to find these all-zero .data variables. The program and the output are FTPable from ftp://ftp.yggdrasil.com/private/adam/linux/zerovars/. Files with no all-zero .data variables are not included in the listing. If you maintain any code in the kernel, you might want to look at the output to see how your code stacks up. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: List of all-zero .data variables in linux-2.4.3 available
[EMAIL PROTECTED] writes:
>Shouldn't a compiler be able to deal with this instead?
Yes. I sent some email to bug-gcc about this a couple of
months ago and even posted some (probably horribly incorrect) code
showing roughly the change I had in mind in the gcc source code
for the simple case of scalar variables. I was told that some code
to this was put in and then removed from gcc a long time ago, and
nobody seemed interested in putting it back in. I would think that this
would be a basic optimization that I would expect the compiler to make,
just like deleting "if(0) {..}" code, but gcc does not currently
do that. If somebody would like to fix gcc and do the necessary
lobbying to get such a change integrated, that would be great. However,
until that actually happens, I hope the file that I posted to
ftp://ftp.yggdrasil.com/private/adam/linux/zerovars/ will be useful
to individual maintainers and in identifying the largest arrays of
zeroes that can fix fixed in a few lines.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
>> = Adam J. Richter <[EMAIL PROTECTED]>
> = Horst von Brand <[EMAIL PROTECTED]>
>> I suppose that running the child first also has a minor
>> advantage for clone() in that it should make programs that spawn lots
>> of threads to do little bits of work behave better on machines with a
>> small number of processors, since the threads that do so little work that
>> they accomplish they finish within their time slice will not pile up
>> before they have a chance to run. So, rather than give the parent's CPU
>> priority to the child only if CLONE_VFORK is not set, I have decided to
>> do a bit of machete surgery and have the child always inherit all of the
>> parent's CPU priority all of the time. It simplifies the code and
>> probably saves a few clock cycles (and before you say that this will
>> cost a context switch, consider that the child will almost always run
>> at least one time slice anyhow).
>And opens the system up to DoS attacks: You can't have a process fork(2)
>at will and so increase its (aggregate) CPU priority.
My change does not increase the aggregate priority of
parent+child. Perhaps I misunderstand your comment.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
Hubertus Franke <[EMAIL PROTECTED]> writes: >Try this ... this will guarantee that (p->counter) > (current->counter) >and it seems not as radical > p->counter = (current->counter + 1) >> 1; >current->counter = (current->counter - 1) >> 1; >if (!current->counter) >current->need_resched = 1; >instead of this >- p->counter = (current->counter + 1) >> 1; >- current->counter >>= 1; >- if (!current->counter) >- current->need_resched = 1; >+ p->counter = current->counter; >+ current->counter = 0; >+ current->need_resched = 1; No. I tried your change and also tried it with setting current->need_resched to 1 in all cases, and it still seems to run the parent first in at least half of the tries. Evidently, current->counter must be zero to make the currently running process give up the CPU immediately, which is the important thing (so that the parent does not touch its virtual memory for a while). Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: List of all-zero .data variables in linux-2.4.3 available
>> I am aware of a couple of cases where code relied on static >> variables being allocated contiguously, but, in both cases, those >> variables were either all zeros or all non-zeros, so my proposed >> change would not break such code. >Continuous placement is not the only property defined by >initialization. There are many more. You cannot change this since it >will quite a few programs and libraries and subtle and hard to >impossible to identify ways. Simply educate programmers to not >initialize. If it is so simple to "educate" programmers on this, could you provide and example or some specifics, especially on why this should not even be a compiler option? Surely that will save you some iterations in this discussion. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: List of all-zero .data variables in linux-2.4.3 available
>Thanks, but Andrey Panin did you one better -- he produced a patch which >fixes up a good number of these. You should follow lkml more closely :) I missed that patch and have been unable to find it on google/dejanews. However, my point is to provide an exhaustive list with sizes (and the tool for generating it), to make it easier to spot and prioritize ones that may have been missed. Anyhow, thanks for the tip. Perhaps I should run this program and post results again on a subsequent kernel release (presumably with Andrey's patch), although anyone else can run this program just as easily. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
"John Fremlin" <[EMAIL PROTECTED]> writes: > "Adam J. Richter" <[EMAIL PROTECTED]> writes: >> Guess why you're seeing this email. That's right. Linux-2.4.3's >> fork() does not run the child first. >[...] If an app wants to fork and exec, it >should use *vfork* and exec, which is a performance win across many >OSs because the COW mappings don't even have to be set up, IIRC. Even in that case, you want to run the child first because it may block on I/O when it does the exec or the new program starts running, and you are likely to be able to use that time while the child is waiting on I/O for the parent to run (typically just to record the process in its internal data structures and then call wait()). Basically, you want to kick off some new I/O before running something that can run while that I/O is pending. Of course, in the vfork case, this change is probably only a very small win. The real advantage is with regular fork() followed by an exec, which happens quite a lot. For example, I do not see vfork anywhere in the bash sources. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
"John Fremlin" <[EMAIL PROTECTED]> writes: >"Adam J. Richter" <[EMAIL PROTECTED]> writes: >> "John Fremlin" <[EMAIL PROTECTED]> writes: >> > "Adam J. Richter" <[EMAIL PROTECTED]> writes: >The parent is not allowed to run until the child execs, if I >understand correctly. Read up on CLONE_VFORK. I thought that I had checked this a few months ago and discovered that Linux let the vfork parent run, but I wrote a test program just now, and you're apparently right about that, at least with respect to 2.4.3, although that's all the more reason to give the short term CPU priority to the process that can use it (the child), thereby slightly increasing the average runtime available in a timeslice, which in term slightly decreases the percentage of time spent in context switch overhead. This will usually be a really tiny amount, but my point is that since there is probably a tiny advantage to giving the remaining time slices to the child even here, there is no need to complicate my patch. >> Of course, in the vfork case, this change is probably only a very >> small win. The real advantage is with regular fork() followed by an >> exec, which happens quite a lot. For example, I do not see vfork >> anywhere in the bash sources. >If it is a real advantage you can get a bigger advantage by changing >the app to use vfork, i.e. you can solve the problem (if it exists) >better without hacking the kernel. It is impractical to change every application, including ones that you don't have access to, and many of them have reaons for using fork instead of vfork, and you don't even have access to them. For example, the setup that the child does between the fork and the exec is complex enough so that it might mess up the parent's memory or, more commonly, its error handling code for exec failure is. Even if you could show that vfork was the right choice in all cases (and it isn't), that would still be no reason for making do_fork unnecessary slow and complex. My change simplifies do_fork(), makes it runs a few cycles faster, and, I believe, makes it behave like more fork on most other systems. If you want to argue against this change, please justify the real benefits of the performance cost, the complexity and nonstandard behavior you are advocating. (Admittedly the last two are really small, but I believe they are positive). Note that I've dropped Linus's email address for this thread, as it does not appear to be arguing a real technical advantage to the old do_fork() behavior. So, while it may be interesting and informative and on topic for lkml, it is not seem to be an argument to Linus that he should reject or modify my patch. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
Rik van Riel <[EMAIL PROTECTED]> writes, regarding the idea
of having do_fork() give all of the parent's remaining time slice to
the newly created child:
>It could upset programs which use threads to handle
>relatively IO poor things (like, waiting on disk IO in a
>thread, like glibc does to fake async file IO).
Good point.
[...]
>If it turns out to be beneficial to run the child first (you
>can measure this), why not leave everything the same as it is
>now but have do_fork() "switch threads" internally ?
That is an elegant idea. Not only would you save a few cycles by
avoiding what's left of the context switch, but, more imporantly, you
would be sure that no intervening process could be selected to run
between the parent giving up the CPU and the child running (which
could otherwise waste an additional full context swtich). Also, you
then would not necessarily have to make the parent give up all of its
remaining time slice. These two characteristics means that future
tweaks to the scheduler would be much less likely to accidentally
defeat running of the child first.
As far code cleanliness goes, you get to delete a line
from do_fork ("current->need_resched = 1;"), but I think that's about
it. You might even be able to avoid adding "current = p;" to do_fork
by having newly allocating task_struct assume the identity of the
parent and making the changes to "current", although I wonder
if anything else points to the current task or if that might
screw up any interrupts that occur during that process.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
>>> = Rik van Riel <[EMAIL PROTECTED]> >> = Adam J. Richter <[EMAIL PROTECTED]> > = Michael O'Reilly <[EMAIL PROTECTED]> >> Rik van Riel <[EMAIL PROTECTED]> writes, regarding the idea >> of having do_fork() give all of the parent's remaining time slice to >> the newly created child: >> >>>It could upset programs which use threads to handle >>>relatively IO poor things (like, waiting on disk IO in a >>>thread, like glibc does to fake async file IO). >> >> Good point. >Is it really? If a program is using thread to handle IO things, >then: >a) It's not going to create a thread for every IO! So I think >the argument is suprious anyway. Maybe not that often, but, from my incomplete understanding of linux/kernel/sched.c, it looks like it can be a really long time before the recalculate loop in schedule() gets called. Currently, the time slice of a regular "nice 0" process in Linux is 50ms (NICE_TO_TICKS(20) = 5, and each tick is 10ms). So, if you're on a multiuser system or you're running some parallel algorithm that uses a bunch of threads so that nobody has to rendezvous to block on IO, then this could on the order of one second. Tangential note: I think the 50ms process time slice makes Linux boxes that have a lot of runnable threads or processes unresponsive in ways that will not show up in most benchmarks, making things like multi-user VNC servers much less scalable than they should be. I wish the Linux "recalculate" loop would scale the time slices to #cpu's/#runnable processes, such as by replacing changing the "p->counter = ..." line in the "recalculate" loop in schedule() to something like this: int runnables; ... runnables = 0; list_for_each(tmp, &runqueue_head) runnables++; runnables /= smp_num_cpus; runnables = runnables ? runnables : 1; /* prevent division by 0 */ for_each_task(p) p->counter = (p->counter >> 1) + (NICE_TO_TICKS(p->nice) / runnables) + 1; (the "+ 1" at the end would ensure that the increment is never zero, even if runnables is very high.) Anyhow, getting back to the topic at hand... >b) You _still_ want the child to run first. The child >will start the I/O and block, then switching back >to the parent. This maximises the I/O thruput without >costing you any CPU. (Reasoning: The child running >2nd will increase the latency which automatically >reduces the number of ops/second you can get). Absolutely. I never said that it would be a good idea run the parent first in that case and Rik didn't either. Under Rik's idea, the child would still run first, but the parent could retain some CPU priority, so that it could get around to running again before the next call to the "recalculate" loop in schedule(), which might be 1 second if the system has 20 runnable runnable threads. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 $@ $<
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/
Re: RFC: changing precision control setting in initial FPU context
IEEE-754 floating point is available under glibc-based systems, including most current GNU/Linux distributions, by linking with -lieee. Your example program produces the "9 10" result you wanted when linked this way, even when compiled with -O2 When not linked with "-lieee", Linux personality ELF x86 binaries start with Precision Control set to 3, just because that is how the x86 fninit instruction sets it. I thought that libieee was also available at run time for dynamic executables by doing something like "LD_PRELOAD=/usr/lib/libieee.so my_dynamic_exeuctable", so you could set it in your .bashrc if you wanted, but that apparently is not the case, at least under glibc-2.2.2. I will have to try to figure out why this is not available. I am a bit out of my depth when discussing the advantages of occasional 80 bit precision over 64 bit, but I think that there are situations where getting gratuitously more accurate results helps, like getting faster convergence in some scientific numerical methods, such as Newton's method. (You'll still find the same point of convergence if there is only one, but the program will run faster). Another example would be things like 3D lighting calculations (used in games?) where you want to produce the best images that you can within that CPU budget. I don't know of any sound encodings where a fully optimized implementation would use floating point, but it's possible. In general, I think most real uses of floating point are for "fast and sloppy" purposes, and programs that want to use floating point and care about exact reproducibility will link with "-lieee". On the other hand, if a GNU/Linux-x86 distribution did want to change the initial floating point control word in Linux to PC=2, I think you would still want old programs to run in their old PC=3 environment, just in case one relied on it. Your sys_setfpcw suggestion could do (to set the default floating point control word without flagging the process as one that was definitely going to use floating point), but I think a simpler approach would be to assign a different magic number argument setpersonality() for programs that expect to be initialized with floating point precision control set to 2. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 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/
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;
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
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.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)
[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-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
smc-ircc.c typo in linux-2.4.0-test11-pre4
linux-2.4.0-test11-pre{3,4}/drivers/net/irda/smc-ircc.c contains
a reference to the undefined symbol smcc_ircc_change_speed. I guess
this should be a reference to ircc_change_speed. Because I am not
positive, I am not sending this message directly to Linus, but I
am cc'ing it to linux-kernel. If I am right or if you have a better
patch, can you please send it to Linus? Thank you.
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-pre4/drivers/net/irda/smc-ircc.c Mon Nov 13 13:36:50 2000
+++ linux/drivers/net/irda/smc-ircc.c Mon Nov 13 13:58:31 2000
@@ -620,7 +620,7 @@
if ((speed = irda_get_speed(skb)) != self->io.speed) {
/* Check for empty frame */
if (!skb->len) {
- smc_ircc_change_speed(self, speed);
+ ircc_change_speed(self, speed);
return 0;
} else
self->new_speed = speed;
-
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/
toshoboe.c typo in linux-2.4.0-test11-pre4
linux-2.4.0-test11-pre{3,4}/drivers/net/irda/toshoboe.c contains
a reference to the undefined symbol toshoboe_change_speed. I guess
this should be a reference to toshoboe_setbaud. Because I am not
positive, I am not sending this message directly to Linus, but I
am cc'ing it to linux-kernel. If I am right or if you have a better
patch, can you please send it to Linus? Thank you.
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-pre4/drivers/net/irda/toshoboe.c Mon Nov 13 13:36:50 2000
+++ linux/drivers/net/irda/toshoboe.c Mon Nov 13 13:57:32 2000
@@ -275,7 +275,7 @@
if ((speed = irda_get_speed(skb)) != self->io.speed) {
/* Check for empty frame */
if (!skb->len) {
- toshoboe_change_speed(self, speed);
+ toshoboe_setbaud(self, speed);
return 0;
} else
self->new_speed = speed;
-
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-test11-pre4/drivers/sound/yss225.c compile failure
linux-2.4.0-test11-pre4/drivers/sound/yss225.c uses __initdata
but does not include , so it could not compile. I have
attached below.
Note that I am a bit uncertain about the correctness of
the __initdata prefix here in the first place. Is yss225 a PCI
device? If so, a kernel that supports PCI hot plugging should
be prepared to support the possibility of a hot pluggable yss225
card being inserted after the module has already been initialized.
Even if no CardBus or CompactPCI version of yss225 hardware exists
yet, it will require less maintenance for PCI drivers to be prepared
for this possibility from the outset (besides, is it possible to have a
hot pluggable PCI bridge card that bridges to a regular PCI bus?).
So, if yss225 is a PCI device, the declaration should use
__devinitdata. On the other hand, if it is ISA only, then __initdata
should be correct.
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-pre4/drivers/sound/yss225.c Mon Nov 13 13:36:50 2000
+++ linux/drivers/sound/yss225.cMon Nov 13 09:11:02 2000
@@ -1,3 +1,4 @@
+#include
unsigned char page_zero[] __initdata = {
0x01, 0x7c, 0x00, 0x1e, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf5, 0x00,
0x11, 0x00, 0x20, 0x00, 0x32, 0x00, 0x40, 0x00, 0x13, 0x00, 0x00,
-
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: Local root exploit with kmod and modutils > 2.1.121
>The only secure fix I can see is to add SAFEMODE=1 to modprobe's >environment and change exec_modprobe. SAFEMODE may mean other things to other programs, so that an ordinary user might set that environment variable for some other reason, and then get weird behavior if he or she has occasion to su to root. In general, you only want to use environment variables if either it is a user interface issue to keep the commands short (not an issue here, since nobody is typing in the command that requrest_module generates) or there is some well established convention that will handled in a particular way by subordinate child processes (e.g., PATH=). It would be much better to just add a command line option to modprobe that request_module() would cause it treat the following argument as the module to load (you do not ever have to force argument processing to stop at that point, since module will be fully contained in the next argument, even if it contains space or linefeed). Another possible approach would be to create a separate /sbin/safe_modprobe. modprobe already behaves differently based on whether argv[0] ends in "modprobe", "insmod", "depmod", or "rmmod". So this would be in keeping with that convention. It would also be trivial to retrofit old systems. Just have some system boot script do: echo /sbin/safe_modprobe > /proc/sys/kernel/modprobe The issue of the kernel doing request_module() on arbitrary strings is not just a security problem. It is also a namespace collision problem, which this security concern will give us the opportunity to fix. I have just been glad that no company has shipped a networking device called, say, "ext2". The non-constant module names that are loaded by request_module should have names like: fs-msdos fs-ext2 netif-eth0 netif-wvlan0 etc. That way, a malicious user cannot cause a denial of service by identifying one module with a loading bug (our kernels have 774 modules) and doing, "ifconfig ". The extra work of doing the snprintf() into a buffer before invoking request_module will resolve the buffer overrun issues too. I would be happy to assist in coding this up. The 50 lines of text that I have written in this email probably only translate into 20 lines of code. 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-test11-pre4/drivers/sound/yss225.c compilefailure
In the particular case of yss225.c, I understand now that it
is ISA only, which is not hot pluggable, so __initdata should be fine;
however, I would like to respond to some other points that Jeff Garzik
raised.
Jeff Garzik wrote:
>Please err on the conservative side -- IMHO you shouldn't mark a driver
>as hotpluggable (by using the '__dev' prefix) unless you know it is
>necessary.
To the best of my knowledge, using __devinit does not "mark" a
driver as hot pluggable. All __devinit{,data} does is resolve to
__init{,data} if CONFIG_HOTPLUG is undefined, and resolve to nothing
if CONFIG_HOTPLUG is defined.
If a programmer errs in favor of __devinit, the result is
extra memory consumption under CONFIG_HOTPLUG. If a programmer
errs in favor of __init, the result is a crash during hot p
ug insertion. Avoiding crashes at the expensive of a pretty small
amount of memory usage is the more "conservative" way to err.
>Otherwise, you rob CONFIG_HOTPLUG people of some memory that could
>otherwise be freed at boot. And the number of CONFIG_HOTPLUG people is
>not small, it includes not only the CardBus users but USB users too...
We have been discussing this on linux-devel-usb. The
latest patches submitted to Linus and in 2.4.0-test10-pre{3,4}
support USB hot plugging regardless of whether CONFIG_HOTPLUG is
specified.
bash% find linux-2.4.0-test11-pre4/drivers/usb -type f | xargs egrep HOTPLUG
bash%
Having USB hot plugging without needing to build in PCI
hot plugging is useful, since there are lots of devices that lack
PCI hot plugging hardware but support USB hot plugging, including,
for example, almost all desktop PC's and typical "appliance" devices.
In addition, other places in the USB code have always relied on hot
plugging by simulating a disconnect and reconnect to recover from
some errors, a kludge which could potentially result in loss of some
device state, but which is too complex to fix before 2.4.0.
After 2.4.0, and after the fake disconnect/reconnect code in
drivers/usb/{devio,storage/scsiglue}.c is designed out, then we may
want to explore adding __usbdevinit{,data} defines in include/linux/init.h
that would be controlled by a new CONFIG_USB_HOTPLUG option, as in
the patches that I posted for this to linux-usb-devel.
In that case, CONFIG_USB_HOTPLUG=y would give you the current
behavior and CONFIG_USB_HOTPLUG=n would give you a slightly smaller kernel
that lacked the ability to support USB hot plugging. There is some
question as to whether CONFIG_USB_HOTPLUG=n would just be a cool hack
or if someone actually would use it. I am very interested in feeback
on this question.
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-test11-pre4/drivers/sound/yss225.c compilefailure
Jeff Garzik wrote:
>"Adam J. Richter" wrote:
>> If a programmer errs in favor of __devinit, the result is
>> extra memory consumption under CONFIG_HOTPLUG. If a programmer
>> errs in favor of __init, the result is a crash during hot p
>> ug insertion. Avoiding crashes at the expensive of a pretty small
>> amount of memory usage is the more "conservative" way to err.
>You suggest avoiding correctness in order to protect against dumb
>programmers. That path leads to Windows.
No, I was saying that if you are unsure whether to use
__devinit{,data} or __init{,data}, using __dev version more closely
fulfulls your request that we "Please err on the conservative side."
If you are sure of the correct one to use, then, of
course, I am sure we all agree you should use it.
>> Having USB hot plugging without needing to build in PCI
>> hot plugging is useful,
>Of course. But CONFIG_HOTPLUG does not mean PCI hotplugging. It means
>any hotplug support in the kernel. That is why __devinit exists and is
>used in a generic fashion.
Could you please cite an example or two of where __devinit
is currently correctly used for a non-PCI non-USB device? I think you
can skip the places in the ISA parallel port code where it is apparently
being incorrectly used (where some non-hot-pluggable ISA code that could
safely be freed will be retained if the kernel is compied with
CONFIG_HOTPLUG).
Earlier in your email, you made an argument about the
development culture ("That path leads to Windows"). In that
same spirit, let's not rely on bureaucratic doctrines like "But
CONFIG_HOTPLUG does not mean..." and, instead, let's look at
the underlying technical issues, which I believe are:
1. there is essentially no call graph dependency between
the hot plugging mechanisms of different busses,
2. we agree that having USB hot plugging without needing
to build in PCI hot plugging is useful.
>> After 2.4.0, [...] we may
>> want to explore adding __usbdevinit{,data} defines in include/linux/init.h
>> that would be controlled by a new CONFIG_USB_HOTPLUG option, as in
>> the patches that I posted for this to linux-usb-devel.
>This is not just a USB issue. Please discuss this on linux-kernel, so
>we can have a coherent hotplug strategy for the entire kernel.
>If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate-
>CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and
>CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus.
s/must/should/ (since you are not changing the resulting binary)
I agree that CONFIG_HOTPLUG should be renamed CONFIG_PCI_HOTPLUG
and I would further like to see __devinit{,data} become __pcidevinit{,data}.
Not only does this configurability have real world uses, but the clearer
labelling would also make the effected code a little more self documenting
as to why the code and data in question is not just __init{,data}.
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-test11-pre4/drivers/sound/yss225.c compilefailure
> = Greg KH
>> = Jeff Garzik
>> I -want- there to be only one hotplug strategy, but Adam seemed to be
>> talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion.
>Here's Adam's proposal for CONFIG_USB_HOTPLUG:
> http://www.geocrawler.com/lists/3/SourceForge/2571/250/4599696/
Thanks, Greg!
>>From what I remember (and from looking at this message), all he seems to
>want is to redefine the __init and __initdata macros depending on a
>config item. There's no other grander scheme of things, right Adam?
Yes, I would have __usbdev{init,exit}{,data} be defined based
on CONFIG_USB_HOTPLUG.
>Although such a small memory savings for turning a bus whose main goal
>in life is to enable hot plugged devices into a fixed connection doesn't
>seem worth it.
[...]
>Comments Adam?
There would be more memory savings from tagging all USB
device driver initialization and exit routines with __usbdevinit
and __usbdevexit.
Although hot plugging is a convenient feature of USB, there
are plenty of applications of USB that do not use hot plugging. For
example, imagine some kind of kiosk or internet appliciance that
uses a USB keyboard or camera, because that is the commodity hardware,
but which the user is not able to physically unplug. Perhaps this
embedded would get cost benefits from a smaller kernel. That is the
sort of potential use that I can imagine for "CONFIG_USB_HOTPLUG=n".
As I said, I am interested in feedback from potential users of
CONFIG_USB_HOTPLUG=n to determine if anyone would use it or if
it is just an intellectual exercise.
The part that is more clearly useful is being able to have USB
hot plugging without compiling in PCI hot plugging. So, CONFIG_HOTPLUG
be CONFIG_PCI_HOTPLUG, or at least should be thought of that way,
regardless of whether CONFIG_USB_HOTPLUG is added.
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/
CONFIG_USB_HOTPLUG (was Patch(?): linux-2.4.0-test11-pre4/drivers/sound/yss225.c compile failure)
>From [EMAIL PROTECTED] Wed Nov 15 09:04:36 2000
>> From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
>>
>> Greg KH wrote:
>> > On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote:
>> > > If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate-
>> > > CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and
>> > > CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus.
>> >
>> > Argh!
>> > I thought the whole point of this was to make there be only
>> one hotplug
>> > strategy, due to the fact that this is a real need.
>> >
>> > Please let's not go down this path. It was all starting to look so
>> > nice...
>>
>> I -want- there to be only one hotplug strategy, but Adam seemed to be
>> talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion.
>I told Adam that I didn't want that patch, but it's not
>up to me now.
You said you wanted to "hold of on CONFIG_USB_HOTPLUG for now",
which I take to mean up to 2.4.0.
I have not asked that CONFIG_USB_HOTPLUG be put in 2.4.0, although
I would not mind. I am just agreeing with you (Randy) when you
identified the problem and wrote in linux-usb-devel "[Why] is it safe to
use __devinitdata on the usb_device_id table? It's used during any new
device connect, after driver init, right ...?" You were right: the
__devinitdata being used in the USB drivers will probably crash the
kernel if CONFIG_HOTPLUG is not defined and the USB code attempts to
recover from an error by faking disconnect/reconnect.
The statements about how we might address this issue more
fully have been about in the context of after 2.4.0. To refresh your
memory, in my first message on this thread I wrote:
|After 2.4.0, and after the fake disconnect/reconnect code in
^^^
| drivers/usb/{devio,storage/scsiglue}.c is designed out, then we may
| want to explore adding __usbdevinit{,data} defines in include/linux/init.h
| that would be controlled by a new CONFIG_USB_HOTPLUG option, as in
| the patches that I posted for this to linux-usb-devel.
Until there is __usbdev{init,exit}{,data}, the incorrect
__devinitdata qualifiers should be removed from the USB device
drivers (but not from the host controller drivers, which are PCI drivers).
Would you like to propose a different solution, Randy?
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: CONFIG_USB_HOTPLUG (was Patch(?): linux-2.4.0-test11-pre4/drivers/sound/yss225.c compile failure)
Jeff Garzik wrote:
>"Adam J. Richter" wrote:
>> You were right: the
>> __devinitdata being used in the USB drivers will probably crash the
>> kernel if CONFIG_HOTPLUG is not defined and the USB code attempts to
>> recover from an error by faking disconnect/reconnect.
>[...]
>> Until there is __usbdev{init,exit}{,data}, the incorrect
>> __devinitdata qualifiers should be removed from the USB device
>> drivers (but not from the host controller drivers, which are PCI drivers).
>If a user hotplugs a device into a kernel which does not support
>CONFIG_HOTPLUG, they are shooting themselves in the foot.
I have always agreed with that (ultimately, I would have the
non-hot-plug kernel simply ignore hot insert events, which would
make it a bit smaller anyhow). That was not the scenario I was
warning about. Please reread this section of the message you
were resonding to:
| __devinitdata being used in the USB drivers will probably crash the
| kernel if CONFIG_HOTPLUG is not defined and the USB code attempts to
| recover from an error by faking disconnect/reconnect.
It has nothing to do with the user physically trying
to do hot plugging.
>I don't see that __devinitdata should be removed.
The reason that __devinitdata should be removed from
the USB drivers (or replaced with __usbdevinitdata) is that
under the status quo, USB storage error recovery code and the
usbdevfs reset code will crash on any non-CONFIG_HOTPLUG kernel
without the user doing anything wrong.
>*plonk*
I expect an apology for that.
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-test11-pre5/drivers/net/hamradio compile problems
linux-2.4.0-test11-pre5/drivers/net/hamradio/baycomm_epp.c and
linux-2.4.0-test11-pre5/drivers/net/hamradio/soundmodem.h refer to
current_cpu.x86_capability, which has changed from an integer to
an array, causing compile errors in these files. Here is a proposed
patch. Thomas, will you handle feeding these patches to Linus if
they look good, or do you want me 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."
--- linux-2.4.0-test11-pre5/drivers/net/hamradio/baycom_epp.c Fri Oct 27 10:55:01
2000
+++ linux/drivers/net/hamradio/baycom_epp.c Wed Nov 15 17:20:16 2000
@@ -814,7 +814,7 @@
#ifdef __i386__
#define GETTICK(x)\
({\
- if (current_cpu_data.x86_capability & X86_FEATURE_TSC)\
+ if (test_bit(X86_FEATURE_TSC, ¤t_cpu_data.x86_capability))\
__asm__ __volatile__("rdtsc" : "=a" (x) : : "dx");\
})
#else /* __i386__ */
--- linux-2.4.0-test11-pre5/drivers/net/hamradio/soundmodem/sm.hWed Aug 18
11:38:50 1999
+++ linux/drivers/net/hamradio/soundmodem/sm.h Wed Nov 15 16:46:57 2000
@@ -299,7 +299,7 @@
#ifdef __i386__
-#define HAS_RDTSC (current_cpu_data.x86_capability & X86_FEATURE_TSC)
+#define HAS_RDTSC (test_bit(X86_FEATURE_TSC, ¤t_cpu_data.x86_capability))
/*
* only do 32bit cycle counter arithmetic; we hope we won't overflow.
-
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-test11-pre5 ISAPNP_DEVICE simplification
I think the definition of ISAPNP_DEVICE in linux-2.4.0-test11-pre5/include/linux/isapnp.h is unnecessarily complex. Here is a proposed 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/include/linux/isapnp.h.orig Thu Nov 16 02:20:14 2000 +++ linux/include/linux/isapnp.hThu Nov 16 02:20:33 2000 @@ -42,10 +42,8 @@ #define ISAPNP_VENDOR(a,b,c) (a)-'A'+1)&0x3f)<<2)|\ b)-'A'+1)&0x18)>>3)|b)-'A'+1)&7)<<13)|\ c)-'A'+1)&0x1f)<<8)) -#define ISAPNP_DEVICE(x) x)&0xf000)>>8)|\ -(((x)&0x0f00)>>8)|\ -(((x)&0x00f0)<<8)|\ -(((x)&0x000f)<<8)) +#define ISAPNP_DEVICE(x) x)&0xff00)>>8)|\ +(((x)&0x00ff)<<8)) #define ISAPNP_FUNCTION(x) ISAPNP_DEVICE(x) /* - 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/
announce: isapnpmodules
I have written an isapnpmodules program that reads /lib/modules//modules.isapnpmap and lists any kernel modules corresponding to any ISA Plug'n'Play devices you have in your system. You must have the isa-pnp module itself either loaded or compiled in when you run this program, because it uses /proc/isapnp. isapnpmodules is FTPable from ftp://ftp.yggdrasil.com/pub/dist/device_control/isapnpmodules/isapnpmodules-0.1.tar.gz. Note that, no modules in the stock 2.4.0-test11-pre5 tree use the isapnp version of MODULE_DEVICE_TABLE yet, so isapnpmodules is not yet of practical 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] Please read the FAQ at http://www.tux.org/lkml/
duplicate entries in rtl8129 driver
Both linux-2.4.0-test12-pre6/drivers/net/rtl8129.c and Don Becker's version at ftp.sycld.com appear to have identical PCI device ID and vendor ID values for these two cards: SMC1211TX EZCard 10/100 (RealTek RTL8139) Accton MPX5030 (RealTek RTL8139) So, I do not see how the latter entry in pci_tbl is ever matched. I think the result would be that users of either card will be told that they have an SMC1211TX EZCard 10/100. I suggest deleting the latter entry and combine its label into the previous one, so it will be described as: SMC1211TX EZCard 10/100 or Accton MPX5030 (RealTek RTL8139) 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." - 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/
sound and scsi pci MODULE_DEVICE_TABLE entries? (primary for Alan Cox)
I tried sending this to Alan Cox, but his mailer complained that we are connected via AboveNet, which blocks ORBS (which is true, and which I have complained about to our ISP many times). It is primary intended for Alan, but anyone else who wants to chime in is welcome to. Adam -- Hello Alan, Jeff Garzik tells me that you, with some help from some other kernel developers, are hacking on the sound drivers right now. I would like to add PCI MODULE_DEVICE_TABLE entries to three of the four PCI sound drivers: cmpci, cs46xx and nm256_audio. (I have already sent a similar patch to Zach Brown for maestro, although that was a port to the new PCI interface.) This will enable depmod to record the PCI ID's that they care about in /lib/modules//modules.pcimap, which, in turn, will enable more automated module loading based on hardware configuration. Would this submission be duplicative of what you are working on? If not, can I submit them to you or is there someone more appropriate for me to submit changes to right now (e.g., each driver's author, someone else)? Since there are only four PCI sound drivers right now, I would like to be able to fix the whole category. Also, do you know if there is someone shepherding the drivers/scsi patches? That is a more important category for automated loading, since it may be needed in booting. 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: sunhme.c patch for new PCI interface (UNTESTED)
Albert D. Cahalan <[EMAIL PROTECTED]> writes:
>PCI is certainly hot-plug hardware, but not on common desktop PCs.
>Since PCI is so popular and so often not hot-plug, users should
>not be forced to have hot-plug PCI support when they only need
>hot-plug SCSI, etc.
>Obvious hack: __pciinit, __pciexit, __pciinitdata...
Yes, as I mentioned in a previous discussion, sometime after
2.4.0, I would like to see CONFIG_HOTPLUG replaced with CONFIG_PCI_HOTPLUG
with __pci{init,exit}{,data}, and CONFIG_USB_HOTPLUG with
__usb{init,exit}{,data} and likewise for other busses, since these
facilities are completely independent, and there are reasons for
wanting to compile in one facility compiled in and not the others,
and it would make drivers self-document which hotplug facility
is the reason why something should be marked as __dev{init,exit}{,data}.
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/
sunhme.c patch for new PCI interface (UNTESTED)
I don't have access to a Sun HME card, but, for some neurotic
reason, I decided to try porting sunhme.c to the new PCI interface.
I believe it has simplified the code slightly. More importantly, it
causes the module to export a table with the PCI ID's that it cares
about, which is used by depmod to generate /lib/modules/.../modules.pcimap,
which can be used to support automatic loading (I wrote a small
program for this purpose, "pcimodules", which I have submitted
hopefully for inclusion in pciutils, and I'd be glad to provide
that patch if anyone is interested).
The patch also eliminates some places where a struct netdevice
that was *always* null was being passed around. Also note that, under
this patch, root_happy_dev has become a list of only the sbus interfaces.
Anyhow, I know that this compiles without any complaint other
than Dave Miller's built in warning message ("This needs to be corrected
... -DaveM"). I would appreciate it if you or anyone else interested
would test it and, if it works and is generally approved of, then
have Dave bless it and send it to Linus.
It looks like sunhme was one of only seven drivers remaining
in the drivers/net (excluding subdirectories) that used the old PCI
probing interface.
This patch is against 2.4.0-test11-pre5, and includes Dave's
changes to make it compile.
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-pre5/drivers/net/sunhme.cWed Nov 15 22:07:59 2000
+++ linux/drivers/net/sunhme.c Thu Nov 16 00:07:15 2000
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#ifdef __sparc__
#include
@@ -48,7 +49,6 @@
#ifndef __sparc_v9__
#include
#endif
-#include
#endif
#include
@@ -73,9 +73,8 @@
/* accept MAC address of the form macaddr=0x08,0x00,0x20,0x30,0x40,0x50 */
MODULE_PARM(macaddr, "6i");
-static struct happy_meal *root_happy_dev = NULL;
-
#ifdef CONFIG_SBUS
+static struct happy_meal *root_happy_dev = NULL;
static struct quattro *qfe_sbus_list = NULL;
#endif
@@ -101,6 +100,7 @@
unsigned int status;
};
#define TX_LOG_LEN 128
+
static struct hme_tx_logent tx_log[TX_LOG_LEN];
static int txlog_cur_entry = 0;
static __inline__ void tx_add_log(struct happy_meal *hp, unsigned int a, unsigned int
s)
@@ -1600,6 +1600,10 @@
HMD(("happy_meal_init: old[%08x] bursts<",
hme_read32(hp, gregs + GREG_CFG)));
+#ifndef __sparc__
+ /* It is always PCI and can handle 64byte bursts. */
+ hme_write32(hp, gregs + GREG_CFG, GREG_CFG_BURST64);
+#else
if ((hp->happy_bursts & DMA_BURST64) &&
((hp->happy_flags & HFLAG_PCI) != 0
#ifdef CONFIG_SBUS
@@ -1633,6 +1637,7 @@
HMD(("XXX>"));
hme_write32(hp, gregs + GREG_CFG, 0);
}
+#endif /* __sparc__ */
/* Turn off interrupts we do not want to hear. */
HMD((", enable global interrupts, "));
@@ -2553,10 +2558,9 @@
#endif /* CONFIG_PCI */
#ifdef CONFIG_SBUS
-static int __init happy_meal_sbus_init(struct net_device *dev,
- struct sbus_dev *sdev,
- int is_qfe)
+static int __init happy_meal_sbus_init(struct sbus_dev *sdev, int is_qfe)
{
+ struct net_device *dev;
struct quattro *qp = NULL;
struct happy_meal *hp;
int i, qfe_slot = -1;
@@ -2571,13 +2575,7 @@
if (qfe_slot == 4)
return -ENODEV;
}
- if (dev == NULL) {
- dev = init_etherdev(0, sizeof(struct happy_meal));
- } else {
- dev->priv = kmalloc(sizeof(struct happy_meal), GFP_KERNEL);
- if (dev->priv == NULL)
- return -ENOMEM;
- }
+ dev = init_etherdev(0, sizeof(struct happy_meal));
if (hme_version_printed++ == 0)
printk(KERN_INFO "%s", version);
@@ -2741,7 +2739,8 @@
#endif
#ifdef CONFIG_PCI
-static int __init happy_meal_pci_init(struct net_device *dev, struct pci_dev *pdev)
+static int __devinit happy_meal_pci_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
{
struct quattro *qp = NULL;
#ifdef __sparc__
@@ -2752,6 +2751,10 @@
unsigned long hpreg_base;
int i, qfe_slot = -1;
char prom_name[64];
+ struct net_device *dev;
+
+ if (pci_enable_device(pdev))
+ return -EIO;
/* Now make sure pci_dev cookie is there. */
#ifdef __sparc__
@@ -2778,13 +2781,7 @@
if (qfe_slot == 4)
Re: sunhme.c patch for new PCI interface (UNTESTED)
>Sorry, I don't like this change. Can you at least add the MODULE_DEVICE_TABLE declaration and the pci_device_id table that it refers to, even if the code does not directly reference it? (You can make it as __initdata rather than __devinitdata, since it can safely be thrown away.) That was automatic PCI ID recognition will work. 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-test11/drivers/sound/maestro.c port to new PCI interface
Here is a patch which ports drivers/sound/maestro.c to the new PCI
interface, which Zach Brown asked me to post here for comments.
This patch includes Zach's changes eliminating the ioctl lockups which
he posted separately, just to make it easier to generate the final
product from pristine 2.4.0-test11. I could actually divide this
patch into three phases if need be:
(a) The ioctl lockup fix which Zach has already submitted for
(presumably) the next "-pre" release.
(b) The pci_device_id table declaration and MODULE_DEVICE_TABLE.
(c) Moving to the new PCI interface. If I were to conform to
Jeff Garzick's requests on __initdata and __devinitdata, this would
include changes that would change an __initdata delcaration in
(b) to __devinitdata.
At this point, my preference would be to see (a) in test12-pre1, and
(b) or (b)+(c) in test12-pre2; however, I do not feel strongly about it.
Anyhow, I am sure any 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-test11/drivers/sound/maestro.c Sat Nov 11 18:33:13 2000
+++ linux/drivers/sound/maestro.c Wed Nov 15 22:25:42 2000
@@ -243,7 +243,6 @@
#include
#include
-static int maestro_pm_callback(struct pm_dev *dev, pm_request_t rqst, void *d);
#include "maestro.h"
@@ -355,6 +354,51 @@
TYPE_MAESTRO2E
};
+static struct pci_device_id maestro_pci_ids[] __devinitdata = {
+ {
+ vendor: PCI_VENDOR_ESS,
+ device: PCI_DEVICE_ID_ESS_ESS1968,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ driver_data: TYPE_MAESTRO2
+ },
+ {
+ vendor: PCI_VENDOR_ESS,
+ device: PCI_DEVICE_ID_ESS_ESS1978,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ driver_data: TYPE_MAESTRO2E
+ },
+ {
+ vendor: PCI_VENDOR_ESS_OLD,
+ device: PCI_DEVICE_ID_ESS_ESS0100,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ driver_data: TYPE_MAESTRO
+ },
+ { } /* Terminating entry */
+};
+
+MODULE_DEVICE_TABLE(pci, maestro_pci_ids);
+
+static int __devinit maestro_probe(struct pci_dev *pcidev,
+ const struct pci_device_id *id);
+static void __devexit maestro_remove(struct pci_dev *pdev);
+static void maestro_suspend(struct pci_dev *pcidev);
+static void maestro_resume(struct pci_dev *pcidev);
+
+static struct pci_driver maestro_driver = {
+ name: "maestro",
+ id_table: maestro_pci_ids,
+ probe: maestro_probe,
+ remove: maestro_remove,
+#ifdef CONFIG_PM
+ suspend:maestro_suspend,
+ resume: maestro_resume,
+#endif /* PM */
+};
+
+
static const char *card_names[]={
[TYPE_MAESTRO] = "ESS Maestro",
[TYPE_MAESTRO2] = "ESS Maestro 2",
@@ -1958,6 +2002,7 @@
static int mixer_ioctl(struct ess_card *card, unsigned int cmd, unsigned long arg)
{
int i, val=0;
+ unsigned long flags;
VALIDATE_CARD(card);
if (cmd == SOUND_MIXER_INFO) {
@@ -1990,9 +2035,9 @@
if(!card->mix.recmask_io) {
val = 0;
} else {
- spin_lock(&card->lock);
+ spin_lock_irqsave(&card->lock, flags);
val = card->mix.recmask_io(card,1,0);
- spin_unlock(&card->lock);
+ spin_unlock_irqrestore(&card->lock, flags);
}
break;
@@ -2019,9 +2064,9 @@
return -EINVAL;
/* do we ever want to touch the hardware? */
-/* spin_lock(&card->lock);
+/* spin_lock_irqsave(&card->lock, flags);
val = card->mix.read_mixer(card,i);
- spin_unlock(&card->lock);*/
+ spin_unlock_irqrestore(&card->lock, flags);*/
val = card->mix.mixer_state[i];
/* M_printk("returned 0x%x for mixer %d\n",val,i);*/
@@ -2046,9 +2091,9 @@
if(!val) return 0;
if(! (val &= card->mix.record_sources)) return -EINVAL;
- spin_lock(&card->lock);
+ spin_lock_irqsave(&card->lock, flags);
card->mix.recmask_io(card,0,val);
-
Re: Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface
hether the drivers/net changes that I sent to you for
shepherding into Linus's kernel actually get incorporated (presumably
with your changes the pci_device_id table format, which we are arguing
about). Finally, if driver maintainer specifically insists one format
or the other, I am happy to accomodate for that driver, again, because
I think that will make it more likely that this facility will get into
Linus's released and will achieve full ubiquity.
Let me also say that I appreciate the effort that you (Jeff) put
into critiquing my patches and those of others and your quick
responsiveness. I try to quickly implement your requests that I do
not have a problem with, and I think that higher quality has resulted
from your input. I also keep in mind that we are arguing about how to
achieve the same goal (make the best patches).
>To make Zab's life a little easier, use pci_{get,set}_drvdata to make it
>easier to port the code back to 2.2.x. Since pci_dev::driver_data
>doesn't exist on 2.2.x, you have to ugly up the code with ifdefs, or use
>a compatibility macro (like, say, pci_xxx_drvdata.. :))
Thanks for the tip. I have done this in the patch attached.
>Unrelated to your change: the maestro reboot notifier shouldn't need to
>unregister all that stuff. Who cares if the sound devices are freed,
>since we are rebooting. free_irq+maestro_power seems sufficient. or
>maybe stop_dma+free_irq+poweroff.
I think the idea here is to avoid having to maintain
a data structure to keep track of all of the PCI cards when the
PCI subsystem already does this.
>Unrelated to your change: Feel free to submit patches to update
>Documentation/pci.txt if you feel it is missing information.
Thanks for that suggestion. Documentation/pci.txt does not
give examples one way or the the other on initializing the
pci_device_id table. I would be happy to submit an example using
named fields, but preferably not in a way that would be taken as flame
war tactic.
I guess at some point I would also like to change
Documentation/pci.txt to recommend that all PCI drivers be hotplug
drivers when feasible so as to support "hot" docking stations
(regardless of whether the core PCI Linux code supports this yet),
pluggable bridges, and possible future versions of the device, since
any device with the same core logic is allowed to have the same PCI
device ID and vendor ID.
Anyhow, here is the maestro.c patch, version 1.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."
-CUT HERE-
--- linux-2.4.0-test11/drivers/sound/maestro.c Sat Nov 11 18:33:13 2000
+++ linux/drivers/sound/maestro.c Tue Nov 21 16:15:17 2000
@@ -243,7 +243,6 @@
#include
#include
-static int maestro_pm_callback(struct pm_dev *dev, pm_request_t rqst, void *d);
#include "maestro.h"
@@ -355,6 +354,51 @@
TYPE_MAESTRO2E
};
+static struct pci_device_id maestro_pci_ids[] __devinitdata = {
+ {
+ vendor: PCI_VENDOR_ESS,
+ device: PCI_DEVICE_ID_ESS_ESS1968,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ driver_data: TYPE_MAESTRO2
+ },
+ {
+ vendor: PCI_VENDOR_ESS,
+ device: PCI_DEVICE_ID_ESS_ESS1978,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ driver_data: TYPE_MAESTRO2E
+ },
+ {
+ vendor: PCI_VENDOR_ESS_OLD,
+ device: PCI_DEVICE_ID_ESS_ESS0100,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ driver_data: TYPE_MAESTRO
+ },
+ { } /* Terminating entry */
+};
+
+MODULE_DEVICE_TABLE(pci, maestro_pci_ids);
+
+static int __devinit maestro_probe(struct pci_dev *pcidev,
+ const struct pci_device_id *id);
+static void __devexit maestro_remove(struct pci_dev *pdev);
+static void maestro_suspend(struct pci_dev *pcidev);
+static void maestro_resume(struct pci_dev *pcidev);
+
+static struct pci_driver maestro_driver = {
+ name: "maestro",
+ id_table: maestro_pci_ids,
+ probe: maestro_probe,
+ remove: maestro_remove,
+#ifdef CONFIG_PM
+ suspend:maestro_suspend,
+ resume: maestro_resume,
+#endif /* PM */
+};
+
+
static const char *card_names[]={
[TYPE_MAESTRO] = "ESS Maestro",
[TYPE_MAESTRO2] = "ESS Maestro 2",
@@ -814,7 +858,7 @@
* The PT101 setup is untested.
*/
-static u16 __init maestro_ac97_init(struct ess_card *card)
+static u16 __devinit maestro_ac
Re: Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface
I forgot to mention that I have tested the updated maestro.c patch that I just submitted by loading the module on a notebook computer, playing some sound, and unloading 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] Please read the FAQ at http://www.tux.org/lkml/
Patch(?): pci_device_id tables for drivers/scsi in 2.4.0-test11
Here is my first pass at adding pci_device_id tables to all
PCI scsi drivers in linux-2.4.0-test11. It implements a compromise
regarding named initializers for pci_device_id table entries: shorter
tables or tables that contain anonymous constants use the named fields,
but the few longer tables where the purpose of the constants are more
clearly labelled do not use named fields, because those tables would
be really big otherwise (in terms of lines of source code, not what
they compile into). The theory in this is that the number of tables
that use the unlabelled structure initializers is still kept relatively
small, so a change to pci_device_id that would require changing the
initializers would involve changing only a relatively small number
of drivers, as opposed to potentially all ~150 PCI 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."
--- /tmp/adam/linux-2.4.0-test11/drivers/scsi/3w-.c Wed Nov 8 17:09:50 2000
+++ 3w-.c Wed Nov 22 04:04:27 2000
@@ -87,6 +87,7 @@
#include
#include
#include
+#include
#include
#include
@@ -100,6 +101,17 @@
#include "hosts.h"
#include "3w-.h"
+
+static struct pci_device_id tw_scsi_pci_tbl[] __initdata = {
+ {
+ vendor: TW_VENDOR_ID,
+ device: TW_DEVICE_ID,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ },
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, tw_scsi_pci_tbl);
static int tw_copy_info(TW_Info *info, char *fmt, ...);
static void tw_copy_mem_info(TW_Info *info, char *data, int len);
--- /tmp/adam/linux-2.4.0-test11/drivers/scsi/AM53C974.cSun Nov 12 20:40:42
2000
+++ AM53C974.c Wed Nov 22 04:28:10 2000
@@ -340,6 +340,18 @@
#define TAG_NONE -2 /* Establish I_T_L nexus instead of I_T_L_Q
* even on SCSI-II devices */
+static struct pci_device_id am53c974_pci_tbl[] __initdata = {
+ {
+ vendor: PCI_VENDOR_ID_AMD,
+ device: PCI_DEVICE_ID_AMD_SCSI,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ },
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, am53c974_pci_tbl);
+
+
/ LILO overrides */
typedef struct _override_t {
int host_scsi_id; /* SCSI id of the bus controller */
--- /tmp/adam/linux-2.4.0-test11/drivers/scsi/BusLogic.cSat Nov 11 19:01:11
2000
+++ BusLogic.c Wed Nov 22 04:07:16 2000
@@ -54,6 +54,29 @@
#include "FlashPoint.c"
+static struct pci_device_id buslogic_pci_tbl[] __initdata = {
+ {
+ vendor: PCI_VENDOR_ID_BUSLOGIC,
+ device: PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ },
+ {
+ vendor: PCI_VENDOR_ID_BUSLOGIC,
+ device: PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER_NC,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ },
+ {
+ vendor: PCI_VENDOR_ID_BUSLOGIC,
+ device: PCI_DEVICE_ID_BUSLOGIC_FLASHPOINT,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ },
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, buslogic_pci_tbl);
+
/*
BusLogic_DriverOptionsCount is a count of the number of BusLogic Driver
Options specifications provided via the Linux Kernel Command Line or via
--- /tmp/adam/linux-2.4.0-test11/drivers/scsi/NCR53C9x.cMon Jun 19 17:59:41
2000
+++ NCR53C9x.c Sat Nov 18 03:22:01 2000
@@ -21,10 +21,7 @@
* 4) Maybe change use of "esp" to something more "NCR"'ish.
*/
-#ifdef MODULE
#include
-#endif
-
#include
#include
#include
@@ -3604,6 +3601,15 @@
spin_unlock_irqrestore(&io_request_lock, flags);
}
#endif
+
+EXPORT_SYMBOL(esp_intr);
+EXPORT_SYMBOL(esp_allocate);
+EXPORT_SYMBOL(esp_initialize);
+EXPORT_SYMBOL(esp_reset);
+EXPORT_SYMBOL(esp_abort);
+EXPORT_SYMBOL(esps_in_use);
+EXPORT_SYMBOL(esp_deallocate);
+EXPORT_SYMBOL(esp_queue);
#ifdef MODULE
int init_module(void) { return 0; }
--- /tmp/adam/linux-2.4.0-test11/drivers/scsi/advansys.cSat Nov 11 19:01:11
2000
+++ advansys.c Wed Nov 22 04:02:15 2000
@@ -4071,6 +4071,18 @@
#endif /* ASC_CONFIG_PCI */
#endif /* version < v2.1.93 */
+#if LINUX_VERSION_CODE >= ASC_LINUX_VERSION(2,4,0)
+static struct pci_device_id advansys_pci_tbl[] __initdata = {
+{ ADV_PCI_VENDOR_ID, ASC_PCI_DEVICE_ID_1100, PCI_ANY_ID, PCI_ANY_ID },
+{ ADV_PCI_VENDOR_ID, ASC_PCI_DEVICE_ID_1200, PCI_ANY_ID, PCI_ANY_ID },
+{ ADV_PCI_VENDOR_ID, ASC_PCI_DEVICE_ID_1300, PCI_ANY_ID, PCI_ANY_ID },
+{ ADV_PCI_VENDOR_ID,
Re: Patch(?): pci_device_id tables for drivers/scsi in 2.4.0-test11
Christoph Hellwig <[EMAIL PROTECTED]> writes: >Neither there are lots of NULL-initilized fields nor is >there any reason to add new fields (the pci tables are external >API, because of MODULE_DEVICE_TABLE). PCI ID matching relies on the zeros being filled in for an empty value in the case of class_mask. depmod deliberately includes a format comment at the start of modules.pcimap so that the structure can be changed in the future. However, thanks for your feedback. I will take it into consideration. 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(?): pci_device_id tables for linux-2.4.0-test11/drivers/block
Just to avoid duplication of effort, I am posting this preliminary
patch which adds PCI MODULE_DEVICE_TABLE declarations to the three PCI
drivers in linux-2.4.0-test11/drivers/block. In response to input from
Christoph Hellwig, I have reduced my threshhold on using named initializers
to three entries, although I think that may be going to far, as I would
really like to keep the number of files that initialize the pci_device_id
arrays this way low so that changing struct pci_device_id remains feasible.
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/block/DAC960.c Thu Oct 26 23:35:47 2000
+++ linux/drivers/block/DAC960.cWed Nov 22 12:42:23 2000
@@ -40,11 +40,22 @@
#include
#include
#include
+#include
#include
#include
#include
#include "DAC960.h"
+
+static struct pci_device_id DAC960_pci_tbl[] __initdata = {
+ { PCI_VENDOR_ID_MYLEX, PCI_DEVICE_ID_MYLEX_DAC960_BA, PCI_ANY_ID, PCI_ANY_ID},
+ { PCI_VENDOR_ID_MYLEX, PCI_DEVICE_ID_MYLEX_DAC960_LP, PCI_ANY_ID, PCI_ANY_ID},
+ { PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_21285, PCI_ANY_ID, PCI_ANY_ID},
+ { PCI_VENDOR_ID_MYLEX, PCI_DEVICE_ID_MYLEX_DAC960_PG, PCI_ANY_ID, PCI_ANY_ID},
+ { PCI_VENDOR_ID_MYLEX, PCI_DEVICE_ID_MYLEX_DAC960_PD, PCI_ANY_ID, PCI_ANY_ID},
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, DAC960_pci_tbl);
/*
DAC960_ControllerCount is the number of DAC960 Controllers detected.
--- linux-2.4.0-test11/drivers/block/cciss.cThu Oct 26 23:35:47 2000
+++ linux/drivers/block/cciss.c Wed Nov 22 12:29:27 2000
@@ -50,6 +50,17 @@
/* Embedded module documentation macros - see modules.h */
MODULE_AUTHOR("Charles M. White III - Compaq Computer Corporation");
MODULE_DESCRIPTION("Driver for Compaq Smart Array Controller 5300");
+static struct pci_device_id cciss_pci_tbl[] __initdata = {
+ {
+ vendor: PCI_VENDOR_ID_COMPAQ,
+ device: PCI_DEVICE_ID_COMPAQ_CISS,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ },
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, cciss_pci_tbl);
+
#include "cciss_cmd.h"
#include "cciss.h"
--- linux-2.4.0-test11/drivers/block/cpqarray.c Thu Nov 16 11:30:29 2000
+++ linux/drivers/block/cpqarray.c Wed Nov 22 12:34:53 2000
@@ -52,6 +52,16 @@
MODULE_AUTHOR("Compaq Computer Corporation");
MODULE_DESCRIPTION("Driver for Compaq Smart2 Array Controllers");
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
+static struct pci_device_id cpqarray_pci_tbl[] __initdata = {
+ { PCI_VENDOR_ID_DEC,PCI_DEVICE_ID_COMPAQ_42XX, PCI_ANY_ID, PCI_ANY_ID},
+ { PCI_VENDOR_ID_NCR,PCI_DEVICE_ID_NCR_53C1510, PCI_ANY_ID, PCI_ANY_ID},
+ { PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_SMART2P,PCI_ANY_ID, PCI_ANY_ID},
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, cpqarray_pci_tbl);
+#endif
+
#define MAJOR_NR COMPAQ_SMART2_MAJOR
#include
#include
-
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(?): pci_device_id tables for linux-2.4.0-test11/drivers/block
>"Adam J. Richter" wrote: >> Just to avoid duplication of effort, I am posting this preliminary >> patch which adds PCI MODULE_DEVICE_TABLE declarations to the three PCI >> drivers in linux-2.4.0-test11/drivers/block. In response to input from >> Christoph Hellwig, I have reduced my threshhold on using named initializers >> to three entries, although I think that may be going to far, as I would >> really like to keep the number of files that initialize the pci_device_id >> arrays this way low so that changing struct pci_device_id remains feasible. >*This* is the over-engineering attitude I was talking about. The only >reason why you are preferring named initializers is because >pci_device_id MIGHT be changed. And if it is changed, it makes the >changeover just tad easier. It is also much easier to spot an initialization bug, if, say, a class is being initialized with a class_mask. It also make the code much more self-documenting. I frequently have to bring up a copy of include/linux/pci.h to decipher usb_devicde_id tables. >For that, you ugly up the code and make it >more difficult to maintain. I think this makes it easier to maintain, especially by driver authors who want to think more about their pet hardware than how a generic kernel data structure is ordered. Also bear in mind that once these drivers are ported to the new PCI interface, many will use pci_device_id->driver_data, which will cause all of the entries that are not in "field:value" form to no longer fit on one line anyhow. >_I_ am one of the people that works on maintaining these random PCI >drivers that no one gives a shit about. I don't believe that using "field:value" format makes centralized maintenance harder, but, if you find it that way, you should consider the position of driver author a driver author who is more knowledgeable about the hardware and has less repetitive need to memorize the arrangement of an obscure kernel data structure. The __initdata vs __devinitdata for the pci_device_id tables is the same sort of issue. I believe that named initializers also make it easier for developers whose focus is not on the central kernel data structures to spot and fix bugs and develop new drivers, and that this is a more scalable approach to kernel development. In any case, if you want, I would be happy to send you patches that include only the changes that do the initilization anonymously. Until those appear in Linus's releases, I see it is a more definitely positive contribution on my part to focus on writing pci_device_id tables for other drivers that lack 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." - 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-test11/drivers/char pci_device_id tables
The following patch adds a pci_device_id table and a
MODULE_DEVICE_TABLE delcaration to each remaining PCI driver
in linux-2.4.0-test11/drivers/char/. I have used the named initializer
format for drivers that have only one or two PCI entries, initialize from
anonymous integers or where the unlabelled format would still
result in more than one line per entry in spite of any spacing
tricks.
I believe I have now posted patches that completes pci_device_id
table coverage for the following directories:
drivers/block
drivers/char
drivers/net
drivers/scsi
drivers/sound
Here is a summary of the number of files in other kernel
directories remaining to be updated (generated by counting the number
of files with "pci_find" and without "MODULE_DEVICE_TABLE" and removing
some obviously inapplicable cases):
drivers/acpi1
drivers/atm 6
drivers/ide 5
drivers/ieee13943
drivers/isdn/avmb1 3
drivers/isdn/eicon 2
drivers/isdn/hisax 13
drivers/isdn/hysdn 1
drivers/media/radio 1
drivers/media/video 4
drivers/mtd 1
drivers/net/tokenring 1
drivers/pcmcia 1
drivers/sbus/char 1
drivers/telephony 1
drivers/video 7
As you can see, we are converging on complete MODULE_DEVICE_TABLE
coverage for all PCI 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."
--- linux-2.4.0-test11/drivers/char/agp/agpgart_be.cThu Nov 16 13:59:53 2000
+++ linux/drivers/char/agp/agpgart_be.c Wed Nov 22 17:28:09 2000
@@ -56,6 +56,18 @@
EXPORT_SYMBOL(agp_enable);
EXPORT_SYMBOL(agp_backend_acquire);
EXPORT_SYMBOL(agp_backend_release);
+static struct pci_device_id specialix_pci_tbl[] __initdata = {
+ {
+ vendor: PCI_ANY_ID,
+ device: PCI_ANY_ID,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ class: PCI_CLASS_BRIDGE_PCI << 8,
+ class_mask: 0x00,
+ },
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, specialix_pci_tbl);
static void flush_cache(void);
--- linux-2.4.0-test11/drivers/char/applicom.c Wed Jul 12 21:58:42 2000
+++ linux/drivers/char/applicom.c Wed Nov 22 16:54:48 2000
@@ -72,6 +72,31 @@
"PCI2000PFB"
};
+#if LINUX_VERSION_CODE < 0x20300
+static struct pci_device_id mxser_pci_tbl[] __initdata = {
+ {
+ vendor: PCI_VENDOR_ID_APPLICOM,
+ device: PCI_DEVICE_ID_APPLICOM_PCIGENERIC,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID
+ },
+ {
+ vendor: PCI_VENDOR_ID_APPLICOM,
+ device: PCI_DEVICE_ID_APPLICOM_PCI2000IBS_CAN,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID
+ },
+ {
+ vendor: PCI_VENDOR_ID_APPLICOM,
+ device: PCI_DEVICE_ID_APPLICOM_PCI2000PFB,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID
+ },
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, mxser_pci_tbl);
+#endif
+
MODULE_AUTHOR("David Woodhouse & Applicom International");
MODULE_DESCRIPTION("Driver for Applicom Profibus card");
MODULE_PARM(irq, "i");
--- linux-2.4.0-test11/drivers/char/cyclades.c Wed Nov 15 00:41:03 2000
+++ linux/drivers/char/cyclades.c Wed Nov 22 18:19:49 2000
@@ -877,6 +877,20 @@
PCI_DEVICE_ID_CYCLOM_Z_Hi, /* Z PCI > 1Mb */
0 /* end of table */
};
+
+static struct pci_device_id cyclades_pci_tbl[] __initdata = {
+ {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_Y_Lo, PCI_ANY_ID, PCI_ANY_ID},
+ {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_Y_Hi, PCI_ANY_ID, PCI_ANY_ID},
+ {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_4Y_Lo, PCI_ANY_ID, PCI_ANY_ID},
+ {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_4Y_Hi, PCI_ANY_ID, PCI_ANY_ID},
+ {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_8Y_Lo, PCI_ANY_ID, PCI_ANY_ID},
+ {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_8Y_Hi, PCI_ANY_ID, PCI_ANY_ID},
+ {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_Z_Lo, PCI_ANY_ID, PCI_ANY_ID},
+ {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_Z_Hi, PCI_ANY_ID, PCI_ANY_ID},
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, cyclades_pci_tbl);
+
#endif
static void cy_start(struct tty_struct *);
--- linux-2.4.0-test11/drivers/char/i810-tco.c Sun Oct 1 19:45:29 2000
+++ linux/drivers/char/i810-tco.c Wed Nov 22 16:55:39 2000
@@ -51,6 +51,17 @@
#define PCI_DEVICE_ID_INTEL_82801AA_0 0x2410
#endi
Re: Patch(?): pci_device_id tables for drivers/scsi in 2.4.0-test11
>Keith Owens wrote:
>>
>> [Adam J. Richter]
>> > +static struct pci_device_id atp870u_pci_tbl[] __initdata = {
>> > +{vendor: 0x1191, device: 0x8002, subvendor: PCI_ANY_ID, subdevice: PCI_ANY_ID},
>> > +{vendor: 0x1191, device: 0x8010, subvendor: PCI_ANY_ID, subdevice: PCI_ANY_ID},
>>
>> It would make it easier to read and safer to type if you used a macro
>> to generate the fields.
>>
>> #define PCITBL(v,d,sv,sd) \
>> { PCI_VENDOR_ID_##v, PCI_DEVICE_ID_##d, \
>>PCI_VENDOR_ID_##sv, PCI_DEVICE_ID_##sd }
>>
>> #define PCITBL_END {0,0,0,0}
>>
>> static struct pci_device_id foo_pci_tbl[] __initdata = {
>> PCITBL(INTEL, INTEL_82437VX, ANY, ANY),
>> PCITBL_END
>> }
>* your macro fails for the 'ANY' case, because the proper macro is
>PCI_ANY_ID not PCI_{VENDOR,DEVICE}_ID_ANY.
>* many drivers need to set the driver_data field
>That said, the general idea presented above is quite good. The PCITBL
>macro will probably change on a per-driver basis... I don't think it
>belongs in a common header. For example, ethernet drivers might want to
>have a macro that always checks for PCI-CLASS-ETHERNET under the hood,
>while visibly looking like
>PCITBL(INTEL, 82437VX, {a driver_data value}),
>PCITBL(INTEL, 82987VX, {another driver_data value}),
>PCITBL_END
> Jeff
Jaroslav Kysela's isapnp MODULE_DEVICE_TABLE support uses a
a similar scheme (see Documentation/isapnp.txt and
include/linux/isapnp.h). I also used similar macros to add
support usb MODULE_DEVICE_TABLE support for usb/storage/
(not yet in 2.4.0-test11 yet) and usb/pegasus.c.
Note that, in all of these cases, the macros expand to field:value
form, which addresses my concerns about modifiability.
The cases where I implemented this sort of thing in the USB code
were where there was a big tables of values that included device
ID information plus more information than could comfortably fit in
in id->driver_data. Using a trick used in the gcc sources, I changed
the table entries into a calls to a macro and moved them into a
separate .h file, which was included multiple times with different
definitions of the macro to construct the usb_device_id table and a
parallel table of additional driver specific data. There are a bunch
of cases in the code that I have been adding pci_device_id tables
to where an approach like this will probably end up being used
when somebody gets around to eliminating the duplication of data
between the pci_device_id table and the "old" way the driver
organized the PCI ID information.
In the specific case of the current drivers/scsi/atp870u.c,
I think a macro would not help yet becuase the pci entries
still fit on one line without the macro. So, it would just
make the code longer and perhaps less clear. However, when the
devid[] array in that driver is eliminated and perhaps the
driver is ported to the new PCI interface, then the
vendor_data field will probably be used and it will probably be
worthwhile to define a macro as you describe (at least that's
my prediction; I don't claim to be the maintainer of any of these
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: More PCI ID's for linux-2.4.0-test11/include/linux/pci_ids.h
The following patch adds some missing PCI_VENDOR_ID's and PCI_DEVICE_ID's that are scattered throughout a bunch of .c files in drivers/isdn/hisax/. The definitions in the .c files are protected by '#ifndef PCI_VENDOR_ID_...', so it is not necessary to remove those declarations from the .c files during the code freeze unless you want to (and I would be happy to provide a patch for that too). I would like you to incorporate this patch, because it simplifies a change that I have already made adding a PCI MODULE_DEVICE_TABLE declaration to the hisax driver, needs to reference all of these values in a single .c file (because all of those disparate .c files are currently linked into a single module). Anyhow, it is a harmless patch. Will you please apply it? Please let me know if you have any questions. Thank you. -- 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 17:49:57 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 @@ -561,15 +568,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 +810,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 +1345,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
imsttfb.c PCI ID's?
In writing a pci_device_id table for linux-2.4.0-test11/drivers/video/imsttfb.c, I see that that driver theoretically attepts to bind to any PCI video display with a vendor ID set to PCI_VENDOR_ID_IMS, although the code does mention device ID's 0x9128 and 0x9135. Does anybody know if there are other device ID's besides 0x9128 and 0x9135 that imsttfb.c is interested in, or is it OK to write the pci_device_id table to just specify those two rather than all PCI video cards made by IMS? 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/
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/
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
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(?): 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
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/
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/
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 @@
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/
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/
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/
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: 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/
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: sunhme.c patch for new PCI interface (UNTESTED)
Jeff Garzik writes:
>Are you aware of any hotplug sunhme hardware? If no, don't change it to
>__devinit...
Can I have a hot plug PCI bridge card that connects to
a regular PCI backplane (perhaps as some kind of CardBus docking
station card)? If so, all PCI drivers should use __dev{init,exit}{,data}.
The other excellent points that you raise apply equally to
the driver before and after my patch (although my patch made it
more clear that the struct netdevice parameters previously being
passed around were always null). It is important to realize this
becase, as of yesterday, Dave had said that he was not going to
apply the new style PCI changes at this point, but had integrated
the MODULE_DEVICE_TABLE changes. So, Dave: you should look at
the points that Jeff raised, even if you are not integrating
the rest of my new style PCI 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]
Please read the FAQ at http://www.tux.org/lkml/
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: sunhme.c patch for new PCI interface (UNTESTED)
>I am willing to consider adding __devxxx only when other __devxxx
>entries already exist.
>These conversions to _devxxx are too late in the freeze, and only have
>value for isolated cases --which you admit you don't even know exist--.
>Linus Rule 1: Don't overdesign.
Even ignoring CardBus, there apparently are docking
stations that have PCI busses, such as shown in
http://www.pangolin.com/LD2000/dock/gateway.htm ("Each supports hot
docking, so you can attach or detach your system without turning it
off"), and a web search turns up plenty of hits, at least for mobile
chipsets apparently designed for this. It looks like this is a
pretty standard capability.
Even if we were unsure, the more conservative approach would
be to use __devinitdata. The only cost of incorrectly using __devinitdata
instead of __initdata, would be to make the effected kernel module
use ~100 bytes more unswappable kernel memory when CONFIG_HOTPLUG is
defined and the module is loaded (28 bytes per entry, including a null
entry). On the other side that risk comparison, the cost of incorrectly
using __initdata when __devinitdata was correct is that the user's
KERNEL WILL CRASH when the notebook is inserted or removed from such a
docking station, even when the kernel is built with CONFIG_HOTPLUG.
Although I'm not into quoting any programmer like some religious
figure, I will say that I think you're misinterpreting the meaning of
an admonition like "Don't overdesign." We are not talking about designing
some new abstraction or making the code more complex, but rather
selecting rather a choice between two words, one of which is the more
conservatively crash resistant __devinitdata, the other of which would
save 28 bytes in CONFIG_HOTPLUG kernels only, and at the expense of
probably causing kernel crashes.
>Even if such cases do exist, and this
>is a need, it should be addressed some other way.
1. Why?
2. What other way did you have in mind?
By the way, although I do not have the PCI standard here, I do
see from _PCI System Architecture_, 4th edition, chapter 19,
"Configuration Registers", in the "Device ID Register" section that
devices "designed around the same third party core logic" are allowed
to have the same device ID (and they are even complaint to PCI 2.2 if
they have different Subsystem ID values). So, my approach also has
the minor advantage that if a vendor wants to ship a hot pluggable
version of their PCI card in the future with the same device ID
(a likely decision), then there may not need to coordinate a new
release of the Linux driver. (This is a really small benefit; the
kernel crashes that you want to change my existing patches to produce
is the big issue.)
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: sunhme.c patch for new PCI interface (UNTESTED)
I wrote:
>[...] the cost of incorrectly
>using __initdata when __devinitdata was correct is that the user's
>KERNEL WILL CRASH when the notebook is inserted or removed from such a
>docking station, even when the kernel is built with CONFIG_HOTPLUG.
My statement above, without some missing qualification, is wrong.
I should have qualified this statement more carefully. (I'm sure the
flames are already in the mail about this.) The kernel will crash in
any case if the relevant driver does not support hot plugging.and the
notebook is being removed with the PCI driver still loaded.
For drivers that do not support hot plugging, we could use
__initdata instead of __devinitdata, since they will crash in any
case. However, violating the instructions in Documentation/pci.txt
("The ID table array should be marked __devinitdata") in this way
will provoke a slew of driver bugs as the over one hundred remaining
PCI drivers are converted to the new PCI interface and some authors
overlook the need to change the MODULE_DEVICE_TABLE storage class.
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/
2.4.0-test11-pre5/drivers/net/sunhme.c compile failure on x86
linux-2.4.0-test11-pre5/drivers/net/sunhme.c fails to compile
on x86 because it uses the undefined symbols DMA_BURST{BITS,8,16,32,64},
which are not defined anywhere in include/asm-i386/*.h. For sparc,
these symbols are defined in include/asm-sparc/dma.h, so I copied them
in sunhme.c and bracketted them if #ifndef DMA_BURSTBITS...#endif, which
made the code compile. However, that is probably not exactly the cleanest
change (it should give correct behavior, however, since the PCI bus
behavior is just to set the mask in question to all ones, so that the
tests for different DMA types all succeed, if I understand correctly).
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);
}
}
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/
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/
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);
PATCH: 2.4.0-test10-pre5 mktime name collision fix
2.4.0-test9 consolidated all of the duplicative declarations
of mktime from various include/asm-.../ files into include/linux/time.h.
This was the right thing to do, but a lot of C code includes ,
mostly older code, like the libc5 sources. This causes compiles of
the effected code to error out due to a collision with the C library
function by the same name.
The following patch simply renames "mktime" to the unused name
"maketime" everywhere, including comments (one exception: this patch
deletes an unused "struct mktime;" line in include/asm-m68k/machdep.h).
Linus, could you please apply this patch? 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."
diff -u -r linux-2.4.0-test10-pre5/arch/alpha/kernel/time.c
linux/arch/alpha/kernel/time.c
--- linux-2.4.0-test10-pre5/arch/alpha/kernel/time.cFri Sep 22 14:09:00 2000
+++ linux/arch/alpha/kernel/time.c Tue Oct 24 23:21:22 2000
@@ -6,7 +6,7 @@
* This file contains the PC-specific time handling details:
* reading the RTC at bootup, etc..
* 1994-07-02Alan Modra
- * fixed set_rtc_mmss, fixed time.year for >= 2000, new mktime
+ * fixed set_rtc_mmss, fixed time.year for >= 2000, new maketime
* 1995-03-26Markus Kuhn
* fixed 500 ms bug at call to set_rtc_mmss, fixed DS12887
* precision CMOS clock update
@@ -250,7 +250,7 @@
if ((year += epoch) < 1970)
year += 100;
- xtime.tv_sec = mktime(year, mon, day, hour, min, sec);
+ xtime.tv_sec = maketime(year, mon, day, hour, min, sec);
xtime.tv_usec = 0;
if (HZ > (1<<16)) {
diff -u -r linux-2.4.0-test10-pre5/arch/arm/kernel/time.c linux/arch/arm/kernel/time.c
--- linux-2.4.0-test10-pre5/arch/arm/kernel/time.c Mon Sep 18 15:15:25 2000
+++ linux/arch/arm/kernel/time.cTue Oct 24 23:21:23 2000
@@ -12,7 +12,7 @@
* reading the RTC at bootup, etc...
*
* 1994-07-02 Alan Modra
- * fixed set_rtc_mmss, fixed time.year for >= 2000, new mktime
+ * fixed set_rtc_mmss, fixed time.year for >= 2000, new maketime
* 1998-12-20 Updated NTP code according to technical memorandum Jan '96
* "A Kernel Model for Precision Timekeeping" by Dave Mills
*/
diff -u -r linux-2.4.0-test10-pre5/arch/i386/kernel/time.c
linux/arch/i386/kernel/time.c
--- linux-2.4.0-test10-pre5/arch/i386/kernel/time.c Tue Oct 24 23:16:58 2000
+++ linux/arch/i386/kernel/time.c Tue Oct 24 23:21:22 2000
@@ -6,7 +6,7 @@
* This file contains the PC-specific time handling details:
* reading the RTC at bootup, etc..
* 1994-07-02Alan Modra
- * fixed set_rtc_mmss, fixed time.year for >= 2000, new mktime
+ * fixed set_rtc_mmss, fixed time.year for >= 2000, new maketime
* 1995-03-26Markus Kuhn
* fixed 500 ms bug at call to set_rtc_mmss, fixed DS12887
* precision CMOS clock update
@@ -541,7 +541,7 @@
}
if ((year += 1900) < 1970)
year += 100;
- return mktime(year, mon, day, hour, min, sec);
+ return maketime(year, mon, day, hour, min, sec);
}
static struct irqaction irq0 = { timer_interrupt, SA_INTERRUPT, 0, "timer", NULL,
NULL};
diff -u -r linux-2.4.0-test10-pre5/arch/ia64/kernel/efi.c linux/arch/ia64/kernel/efi.c
--- linux-2.4.0-test10-pre5/arch/ia64/kernel/efi.c Tue Oct 24 23:16:58 2000
+++ linux/arch/ia64/kernel/efi.cTue Oct 24 23:21:23 2000
@@ -108,7 +108,7 @@
if ((*efi.get_time)(&tm, 0) != EFI_SUCCESS)
return;
- tv->tv_sec = mktime(tm.year, tm.month, tm.day, tm.hour, tm.minute, tm.second);
+ tv->tv_sec = maketime(tm.year, tm.month, tm.day, tm.hour, tm.minute,
+tm.second);
tv->tv_usec = tm.nanosecond / 1000;
}
diff -u -r linux-2.4.0-test10-pre5/arch/m68k/kernel/time.c
linux/arch/m68k/kernel/time.c
--- linux-2.4.0-test10-pre5/arch/m68k/kernel/time.c Mon Sep 11 08:39:48 2000
+++ linux/arch/m68k/kernel/time.c Tue Oct 24 23:21:22 2000
@@ -113,7 +113,7 @@
if ((year += 1900) < 1970)
year += 100;
- xtime.tv_sec = mktime(year, mon, day, hour, min, sec);
+ xtime.tv_sec = maketime(year, mon, day, hour, min, sec);
xtime.tv_usec = 0;
mach_sched_init(timer_interrupt);
diff -u -r linux-2.4.0-test10-pre5/arch/m68k/mac/misc.c linux/arch/m68k/mac/misc.c
--- linux-2.4.0-test10-pre5/arch/m68k/mac/misc.cMon Sep 11 08:39:48 2000
+++ linux/arch/m68k/mac/misc.c Tue Oct 24 23:29:12 2000
@@ -624,7 +624,7 @@
t->year + 1900, t->mon + 1, t->day, t->hour, t->min, t->sec);
#i
Re: / on ramfs, possible?
Anders Eriksson <[EMAIL PROTECTED]> writes: >I want my / to be a ramfs filesystem. I intend to populate it from an >initrd image, and then remount / as the ramfs filesystem. Is that at >all possible? The way I see it the kernel requires / on a device >(major,minor) or nfs. > >Am I out of luck using ramfs as /? If it's easy to fix, how do I fix it? We do that right now with cramfs. You might want to examine ftp://ftp.yggdrasil.com/pub/dist/booting/make-ramdisk-0.19.tar.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: modularizing partition parsing in linux-2.4.0-test10-pre6
Ages ago, I modularized the partition parsing code and
posted the patch to linux-kernel. I received a few suggestions
for some small improvements, and I confess it took me a while
to get around to producing a new patch. Anyhow, here is the
new partitioning modularization patch. It now longer has any
"#ifdef MODULE" code in it. It just has one module-centric
SMP-safe initialization scheme.
I would appreciate it if people would try this patch
and make sure that it works for 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."
--CUT HERE
diff --new-file -u -r linux-2.4.0-test10-pre6/fs/partitions/Config.in
linux/fs/partitions/Config.in
--- linux-2.4.0-test10-pre6/fs/partitions/Config.in Sun Jul 9 22:21:41 2000
+++ linux/fs/partitions/Config.in Sat Oct 28 22:57:06 2000
@@ -3,7 +3,7 @@
#
bool 'Advanced partition selection' CONFIG_PARTITION_ADVANCED
if [ "$CONFIG_PARTITION_ADVANCED" = "y" ]; then
- bool ' Acorn partition support' CONFIG_ACORN_PARTITION
+ tristate ' Acorn partition support' CONFIG_ACORN_PARTITION
if [ "$CONFIG_ACORN_PARTITION" != "n" ]; then
# bool 'Cumana partition support' CONFIG_ACORN_PARTITION_CUMANA
bool 'ICS partition support' CONFIG_ACORN_PARTITION_ICS
@@ -11,22 +11,22 @@
bool 'PowerTec partition support' CONFIG_ACORN_PARTITION_POWERTEC
bool 'RISCiX partition support' CONFIG_ACORN_PARTITION_RISCIX
fi
- bool ' Alpha OSF partition support' CONFIG_OSF_PARTITION
- bool ' Amiga partition table support' CONFIG_AMIGA_PARTITION
- bool ' Atari partition table support' CONFIG_ATARI_PARTITION
+ tristate ' Alpha OSF partition support' CONFIG_OSF_PARTITION
+ tristate ' Amiga partition table support' CONFIG_AMIGA_PARTITION
+ tristate ' Atari partition table support' CONFIG_ATARI_PARTITION
if [ "$CONFIG_ARCH_S390" = "y" ]; then
bool ' IBM disk label and partition support' CONFIG_IBM_PARTITION
fi
- bool ' Macintosh partition map support' CONFIG_MAC_PARTITION
- bool ' PC BIOS (MSDOS partition tables) support' CONFIG_MSDOS_PARTITION
- if [ "$CONFIG_MSDOS_PARTITION" = "y" ]; then
+ tristate ' Macintosh partition map support' CONFIG_MAC_PARTITION
+ tristate ' PC BIOS (MSDOS partition tables) support' CONFIG_MSDOS_PARTITION
+ if [ "$CONFIG_MSDOS_PARTITION" != "n" ]; then
bool 'BSD disklabel (FreeBSD partition tables) support' CONFIG_BSD_DISKLABEL
bool 'Solaris (x86) partition table support' CONFIG_SOLARIS_X86_PARTITION
bool 'Unixware slices support' CONFIG_UNIXWARE_DISKLABEL
fi
- bool ' SGI partition support' CONFIG_SGI_PARTITION
- bool ' Ultrix partition table support' CONFIG_ULTRIX_PARTITION
- bool ' Sun partition tables support' CONFIG_SUN_PARTITION
+ tristate ' SGI partition support' CONFIG_SGI_PARTITION
+ tristate ' Ultrix partition table support' CONFIG_ULTRIX_PARTITION
+ tristate ' Sun partition tables support' CONFIG_SUN_PARTITION
else
if [ "$ARCH" = "alpha" ]; then
define_bool CONFIG_OSF_PARTITION y
diff --new-file -u -r linux-2.4.0-test10-pre6/fs/partitions/Makefile
linux/fs/partitions/Makefile
--- linux-2.4.0-test10-pre6/fs/partitions/Makefile Tue Jul 18 22:49:47 2000
+++ linux/fs/partitions/MakefileFri Jul 14 09:59:40 2000
@@ -14,7 +14,7 @@
obj-$(CONFIG_AMIGA_PARTITION) += amiga.o
obj-$(CONFIG_ATARI_PARTITION) += atari.o
obj-$(CONFIG_MAC_PARTITION) += mac.o
-obj-$(CONFIG_MSDOS_PARTITION) += msdos.o
+obj-$(CONFIG_MSDOS_PARTITION) += msdos_part.o
obj-$(CONFIG_OSF_PARTITION) += osf.o
obj-$(CONFIG_SGI_PARTITION) += sgi.o
obj-$(CONFIG_SUN_PARTITION) += sun.o
diff --new-file -u -r linux-2.4.0-test10-pre6/fs/partitions/acorn.c
linux/fs/partitions/acorn.c
--- linux-2.4.0-test10-pre6/fs/partitions/acorn.c Mon Sep 18 15:15:26 2000
+++ linux/fs/partitions/acorn.c Sat Oct 28 22:54:04 2000
@@ -478,8 +478,9 @@
*
* Returns: -1 on error, 0 if not ADFS format, 1 if ok.
*/
-int acorn_partition(struct gendisk *hd, kdev_t dev,
- unsigned long first_sect, int first_minor)
+static int
+acorn_partition(struct gendisk *hd, kdev_t dev,
+ unsigned long first_sect, int first_minor)
{
int r = 0, i;
@@ -492,3 +493,6 @@
printk("\n&q
Questions on lack of piix4 usb interrupts
I am trying to determine how I should try to fix the
problem of my notebook computer not receiving USB interrupts.
I seem to have gotten it to sort of work by kludging to the USB UHCI
driver's millisecond timer routine to also invoke the interrupt
handler, but I hope I do not have to resort to this as a final
patch.
Searching the net, I get the impression that most notebook
computers do not have this problem, but that I am not alone in it. For
example, [EMAIL PROTECTED] seems to have described the same
problem at http://www.mobilx.org/usb_linux.html for his ProStar 1200
notebok computer. I think the problem may be a fairly deep IRQ assignment
problem which may effect other functionality. So, resolving this problem
may help Linux run better on more than just my Kapok 1100M notebook
computer.
Anyhow, if nobody wants to take a crack at the questions,
at least this message will archive them on deja.com so anyone who comes
across the same problem will be able to contact me for status.
My questions are as follows:
1. [Mostly to linux-usb-devel:] The Intel PIIX3 and PIIX4
specifications, in the section that talks about the LEGSUP
("legacy support"?) PCI configuration register for the uhci usb
controller built into the piix3 and piix4 chips, seem to suggest that
there are some UHCI controllers that do not generate interrupts
(I guess that's why the LEGSUP register provides a bit for masking
disabling the USB interrupts). Therefore, do we need to have support
in the uhci drivers for not receiving interrupts anyhow?
2. [Mostly to mj and linux-kernel:] In
linux-2.4.0-test9/drivers/pci/quirks.c, the comments in routine
quirk_piix3usb seem to describe a scenario very similar to the one
I am experiencing with piix4:
* PIIX3 USB: We have to disable USB interrupts that are
* hardwired to PIRQD# and may be shared with an
* external device.
The piix4 documentation says that the USB interrupt connects
only to PCI interrupt pin D of the piix4 device. On my computer, I
examined the PCI interrupt routing table (this is built into the
computer, not a native kernel data structure), and discovered that
the piix4's pin D is only connectable to IRQ 10, which is shared
with the i82365 PCMCIA controller, and sometimes the computer's
ethernet CardBus card. This sounds just like the scenario described
for quirk_piix3usb.
Causing the piix3 fixup to execute on my piix4 system
(the effected bits are in the same location on the piix3 and piix4)
had no visible effect, and I also verified that USB interrupts are
turned on in the LEGSUP register.
My question is: could I get a slightly more detailed
explanation of what exactly the quirk_piix3usb routine was
trying to fix so I can better understand if I am bumping into
the same problem? Do I understand correctly that the piix3 fixup
makes the current uhci drivers unusable on the effected hardware?
3. [Mostly to linux-kernel]: I think the code in
arch/i386/pci-irq.c will sometimes not check the PCI Interrupt Routing
Table to see if it can assign a particular PCI interrupt pin to a
particular IRQ. Although assigning my notebook's USB interrupts to
IRQ 10 is allowed by my computer's PCI interrupt routing table
(in fact, it's the only legal assignment according to it), a number
of other PCI interrupt pins appear not to have IRQ 10 available in the
PCI Interrupt Routing Table, and yet seem also to have been assigned to
IRQ 10 by the kernel. Am I barking up the wrong tree to think
that the bug probably is here, somewhere in the IRQ configuration
and that my hardware probably really is cabable of generating USB
interrupts?
Note that I am sending this to both linux-kernel and usb-devel.
Unless your response is about both USB and IRQ routing, you probably
want to trim your response list.
Any help in answering these questions will make it a lot
more likely that I will be able to generate a higher quality a patch
sooner to fix this 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/
Patch: linux-2.4.0-test10-pre7/drivers/usb/usb.c driver matching bug
linux-2.4.0-test10-pre7/drivers/usb/usb.c introduced a really
cool feature, where USB drivers can declare a data structure that
describes the various ID bytes of the USB devices that they are
relevant to. Updated versions of depmod and hotplug are then
used so that the appropriate USB drivers can then be loaded
automatically as soon as you plug in a device, without any
need to create additional system configuration files.
Anyhow, the USB implementation of this has a tiny bug,
where it does an apples-and-oranges comparison. The patch is
attached below.
Since the USB device table support is in
linux-2.4.0-test10-pre7 and not in the HEAD branch of the
linux-usb CVS tree on sourceforge.net, and since the bug fix
is very clear and small, I am sending this patch to Linus and
linux-kernel in addition to linux-usb-devel. If there is some
better way that I should submit a patch in this sort of situation,
please let me know. I don't mean to step on anyone's toes.
By the way, I was able to test this all the way to the
point of plugging in a USB printer and watching the module
automatically load and bind to the printer interface. (I
will submit the usb/printer.c device table support patch to
linux-usb-devel momentarily.)
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-test10-pre7/drivers/usb/usb.c Tue Oct 31 02:42:50 2000
+++ linux/drivers/usb/usb.c Tue Oct 31 19:26:14 2000
@@ -540,7 +540,7 @@
if (id->bInterfaceClass
&& id->bInterfaceClass == intf->bInterfaceClass) {
if (id->bInterfaceSubClass && id->bInterfaceSubClass
- != intf->bInterfaceClass)
+ != intf->bInterfaceSubClass)
continue;
if (id->bInterfaceProtocol && id->bInterfaceProtocol
!= intf->bInterfaceProtocol)
-
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] 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-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
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-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)
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/
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 *
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/
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",
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
};
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/
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/
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
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(?): 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)
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/
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/
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
2.4.3-pre6: agpart.o causes arch/i386/mm/ioremap.c hang
Under linux-2.4.3-pre6 compiled for SMP, loading agpgart.o hangs the system in remap_area_pages (arch/i386/mm/ioremap.c) at the call to spin_lock(&init_mm.page_table_lock), which is not in 2.4.2. When I load agpgart.o, I get the following messages: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 690M agpgart: Detected Via Apollo Pro chipset After that, the console keys (RightAlt ScrollLock, Alt-F2, etc.) but there is not other response to my keystrokes and the system is no longer pingable. The call graphic is basically: agp_backend_initialize agp_generic_create_gatt_table io_remap_nocache __ioremap remap_area_pages I've made a cursory search through the kernel sources for what else might be holding this lock, but I have not yet found anything. I'm rebuilding the kernel now with a modified spin_lock() routine that should tell me who acquired the lock previously; however, I really do not understand this part of the kernel enough to know what the changes were intended to do in the first place. So, knowing where else the lock was acquired will not necessarily be enough for me to be able to generate a patch. Anyhow, I imagine that this lock is being held by some code that can block. We'll see. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3-pre6: agpart.o causes arch/i386/mm/ioremap.c hang
I wrote: > Under linux-2.4.3-pre6 compiled for SMP, loading agpgart.o >hangs the system in remap_area_pages (arch/i386/mm/ioremap.c) at >the call to spin_lock(&init_mm.page_table_lock), which is not in 2.4.2. [...] > agp_backend_initialize > agp_generic_create_gatt_table > io_remap_nocache > __ioremap > remap_area_pages [...] > I'm rebuilding the kernel now with a modified spin_lock() >routine that should tell me who acquired the lock previously [...] In case anyone is interested, the conflicting lock of init_mm.page_table_lock was acquired in line 1318 of mm/memory.c, in pte_alloc. One way that this might be happening is that it looks like no page_table_lock is every acquired by vmalloc, which results in the following call graph: vmalloc __vmalloc vmalloc_area_pages alloc_area_pmd pte_alloc ...which assumes (here incorrectly) that mm->page_table_lock is held, and sometimes releases and reacquires mm->page_table_lock. I will attempt to analyze this further tomorrow if nobody beats me to it. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch(?): linux-2.4.3-pre6/mm/vmalloc.c could return with init_mm.page_table_lock held
[Sorry for posting three messages to linux-kernel about this.
Each time I was pretty sure I was done for the night. Anyhow, I
hope this proposed patch makes up for it.]
In linux-2.4.3-pre6, a call to vmalloc can result in a call to
pte_alloc without the appropriate page_table_lock being held. Here is
the call graph, from my post of about half an hour ago:
vmalloc
__vmalloc
vmalloc_area_pages
alloc_area_pmd
pte_alloc ...which assumes (here incorrectly) that
mm->page_table_lock is held, and sometimes releases
and reacquires mm->page_table_lock.
Not only does pte_alloc expect mm->page_table_lock
to be held when it is called, but it also sometimes releases and
reacquires it. vmalloc did not release this lock either, of course.
So, the next attempt to acquire the same mm->page_table_lock spin lock
hangs.
The symptom that I had noticed was the agpgart.o module hanging
at module initialization, but it is a much more general problem, and
could explain all sorts of hangs in 2.4.3-pre6.
Anyhow, with this patch, agpgart.o loads just fine and the
kernel seems to have suffered no negative side effects. I am
not confident in exactly where I chose to put the spin_lock and
spin_unlock calls, so I would recommend a careful examination of
this patch before integrating.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.3-pre6/mm/vmalloc.c Fri Mar 23 02:16:41 2001
+++ linux/mm/vmalloc.c Fri Mar 23 02:09:58 2001
@@ -136,39 +136,41 @@
inline int vmalloc_area_pages (unsigned long address, unsigned long size,
int gfp_mask, pgprot_t prot)
{
pgd_t * dir;
unsigned long end = address + size;
int ret;
dir = pgd_offset_k(address);
flush_cache_all();
+ spin_lock(&init_mm.page_table_lock);
lock_kernel();
do {
pmd_t *pmd;
pmd = pmd_alloc(&init_mm, dir, address);
ret = -ENOMEM;
if (!pmd)
break;
ret = -ENOMEM;
if (alloc_area_pmd(pmd, address, end - address, gfp_mask, prot))
break;
address = (address + PGDIR_SIZE) & PGDIR_MASK;
dir++;
ret = 0;
} while (address && (address < end));
unlock_kernel();
+ spin_unlock(&init_mm.page_table_lock);
flush_tlb_all();
return ret;
}
struct vm_struct * get_vm_area(unsigned long size, unsigned long flags)
{
unsigned long addr;
struct vm_struct **p, *tmp, *area;
area = (struct vm_struct *) kmalloc(sizeof(*area), GFP_KERNEL);
Re: Patch(?): linux-2.4.3-pre6/mm/vmalloc.c could return with init_mm.page_table_lock held
Marcelo Tosatti <[EMAIL PROTECTED]> writes: >There is no need to hold mm->page_table_lock for vmalloced memory. I don't know if it makes a difference, but I should clarify that mm == &init_mm throughout this code, not ¤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/
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/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)
{
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.
