Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
[EMAIL PROTECTED] (Martin Dalecki) wrote on 06.09.00 in <[EMAIL PROTECTED]>: > Alexander Viro wrote: > > > > On Wed, 6 Sep 2000, Martin Dalecki wrote: > > > > > Easy - the same way you do for cross compilation. Basically just: > > > > > > export CC=g++ --some-magic-long-option-i-dont-remember; make > > > > ... and you still have only a subset of the tree, simply because it is fed > > through cpp before it reaches the parser. And cpp cuts away many pieces. > > Different config options and you've got a different subset. Good luck > > providing the coverage. > > That's not quite the problem - with the exception of the boundary cases > of compleatly broken CONFIG_BLAH combinations... You have the fine > .confg file there you know... Count them n and take the n! for all the > possible config choices. Then you will see that THERE CAN'T be any > better > automatic approach then just what I have described above (ie. going > directly into the compiler) and doing the CONFIG_ handling by hand. > (I mean scripting for the most appriopriate choices...) Rather, then you'll see that that approach is completely unviable because the n! is a fscking unbelievable labre number. MfG Kai - 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: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
John Levon wrote:
>
> Am I right ? against test8pre1
>
> Also, is it a bug to not set TASK_{UN}INTERRUPTIBLE before doing a
> schedule_timeout() ? What will happen ?
>
Well, first the "timeout" call will return immediately. Next, when the
time out actually happens, if the task is not TASK_RUNNING (i.e. it is
waiting for some other thing) it will wake_up. So the sleep is lost and
it is possible to have a false wake up (could even wake up a zombie).
If the actual timeout happens while the task is TASK_RUNNING it is
ignored.
George
-
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: Bug Report: Kernel 2.4.0-test7 - Floppy Drive?
Greetings... Of all the bugs i've run into, this is one of the oddest. Hopefully, i've a) got all the req'd information here and b)a hope of finding a solution/workaround/a facsimile thereof to the problem. System Spec's: K6-2/500 64 MB RAM 9.2 Quantum HD 2.4.0-test7 kernel Panasonic 1.44M FloppyDrive Distro: SusE 6.4 Problem: mounting /dev/fd0 or /floppy gives the following output: /dev/fd0 has a wrong major or minor number! News to me.../dev/fd0 is still 2, 0, just like it's always been. 8) The floppy drive was tested with a boot kernel, and works; mke2fs -m 0 /dev/fd0 also works well, as does make bzdisk. I checked the /etc/fstab parameters which are automatically set up upon installation of SuSE, and these read as follows: /dev/fd0/floppy autoauto,user 0 0 All the other devices seem to be working properly. Any clues as to what might be a good workaround to the problem would be really appreciated...the -t option with mount has done nothing, nor has rebooting. Thanks for your time and help. "Alpha" - 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: Bug Report: Kernel 2.4.0-test7 - Floppy Drive?
On Wed, 6 Sep 2000, S.J. Black wrote: >Of all the bugs i've run into, this is one of the oddest. Hopefully, >i've a) got all the req'd information here and b)a hope of finding a >solution/workaround/a facsimile thereof to the problem. > >System Spec's: K6-2/500 > 64 MB RAM > 9.2 Quantum HD > 2.4.0-test7 kernel > Panasonic 1.44M >FloppyDrive > Distro: SusE 6.4 > >Problem: mounting /dev/fd0 or >/floppy gives the following output: >/dev/fd0 has a wrong major >or minor number! Hmm.. How did you get your console in 40 column mode? ;o) -- Mike A. Harris | Computer Consultant | Capslock Consulting Linux Advocate / Open Source Advocate Red Hat FAQ tip: Having trouble upgrading RPM 3.0.x to RPM 4.0.x? Upgrade first to version 3.0.5, and then to 4.0.x. All packages are available on Red Hat's ftp sites: ftp://ftp.redhat.com ftp://rawhide.redhat.com - 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/
Oops early in RH 6.2 boot disk kernel load
Hi. Im getting an oops almost right after 'unpacking linux...'. It is from a RH 6.2 install process boot floppy. I have tried several floppies to eliminate bad media. So I guess it is bad hw, probably RAM. It is an old P75 with 32MB RAM. It runs win98 fine, but that is not saying much ;) I was hoping that someone would take a look at the oops and confirm that it is RAM. It is at www.jaquet.dk/kernel/oops. It is copied by hand so the standard disclaimers about that apply. Also, there is more than what I could copy down since I cannot scroll the screen back. Thanks in advance, Rasmus PS: Replies offlist, please. - 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] devfs support for LVM
Christoph Hellwig wrote: > > > + lvm_devfs_handle = devfs_register( > > > + 0 , "lvm", 0, 0, LVM_CHAR_MAJOR, > > > > Does this really have to go into /dev rather than a subdirectory? > > Yes. The userlevel tool can't handle other things without recompiling. > I can't use /dev/lvm, too because this is the name of the control file > without lvm (and the lvm tools will barf if this is a dircetory. How about making a proper tree and use devfsd to make the backwards compatible symlinks. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;-12480 fn:David Ford end:vcard
Re: Remarks about sigtestsetmask()
> 1. This function is only used in the poorly maintained ftape driver. >The usage there isn't appriopriate for modern kernels. The ftape driver isnt exactly poorly maintained. Its just not integrated into 2.3/2.4. Ftape 4.0 is still elsewhere - 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/
Processes still get stuck when killed with -9
# pse|grep defunct 7854 [gftp ] exit_notify 7855 [gftp ] exit_notify 31281 [xmms ] exit_notify 31282 [xmms ] exit_notify 31285 [xmms ] exit_notify 31717 [xmms ] exit_notify test8-pre5 -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;-12480 fn:David Ford end:vcard
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
> As readability - it's definitely at least as readable as > #if[def]. It also provides more consistent syntax. And when you are > using ifdef to violate scoping - your code is in need of rewrite anyway. You still need the #ifdef stuff as well for half of it so I dont see what it buys you - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, Sep 06, 2000 at 01:28:45PM +1200, Chris Wedgwood wrote: > else > a = 5; > 10: c7 05 00 00 00 00 05movl $0x5,0x0 In current GCC, this is optimised away even at -O0, because it's generally quicker to do dead code elimination than to emit the dead code at all. Tim. */ - 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] 2.2: /proc/config.gz
Chip Salzenberg <[EMAIL PROTECTED]> writes:
|> According to Andi Kleen:
|> > You probably don't have a .config.gz that is longer than a page
|> > (4K), because in that case it'll badly corrupt your memory (or you
|> > just haven't noticed the corruption yet ;)
|>
|> Hm... they're all <4K, but a few are pushing it.
Use this instead. It has the additional advantage of avoiding the useless
memcpy.
diff -urN linux-2.2.16.tmp/fs/proc/array.c linux-2.2.16.SuSE/fs/proc/array.c
--- linux-2.2.16.tmp/fs/proc/array.cSat Jul 15 00:37:00 2000
+++ linux-2.2.16.SuSE/fs/proc/array.c Sat Jul 15 00:38:18 2000
@@ -414,6 +414,25 @@
return strlen(buffer);
}
+#ifdef CONFIG_PROC_CONFIG
+static int get_proc_config(char *buffer, char **start, off_t offset, off_t length)
+{
+ extern char *kernel_config_data;
+ extern int kernel_config_data_size;
+ off_t i;
+
+ i = kernel_config_data_size - offset;
+ if (i > 0) {
+ if (i > length)
+ i = length;
+ *start = kernel_config_data + offset;
+ return i;
+ }
+ else
+ return 0;
+}
+#endif
+
static int get_cmdline(char * buffer)
{
extern char saved_command_line[];
@@ -1460,6 +1479,11 @@
case PROC_STRAM:
return get_stram_list(page);
#endif
+#ifdef CONFIG_PROC_CONFIG
+ case PROC_CONFIG:
+ return get_proc_config(page, start, offset, length);
+#endif
+
}
return -EBADF;
}
Andreas.
--
Andreas Schwab "And now for something
SuSE Labscompletely different."
[EMAIL PROTECTED]
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
-
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] sr.c 2.4.0-test8-pre5 breakage
Heya acme... seems you fixed the sr.c driver a bit too much and
killed an #ifdef MODULE that was needed if you build without
modules (as I do on some of my SPARCs)... this change was made
in 2.4.0-test8-pre5...
drivers/scsi/scsidrv.o: In function `init_sr':
drivers/scsi/scsidrv.o(.text+0x1ece8): undefined reference to
`scsi_register_module'
drivers/scsi/scsidrv.o: In function `exit_sr':
drivers/scsi/scsidrv.o(.text+0x1ed08): undefined reference to
`scsi_unregister_module'
make: *** [vmlinux] Error 1
Patch is as follows:
--- linux/drivers/scsi/sr.c Wed Sep 6 02:38:24 2000
+++ linux-test/drivers/scsi/sr.cWed Sep 6 02:37:18 2000
@@ -848,6 +848,8 @@
return;
}
+#ifdef MODULE
+
int init_sr(void)
{
sr_template.module = THIS_MODULE;
@@ -880,3 +882,5 @@
module_init(init_sr);
module_exit(exit_sr);
+
+#endif /* MODULE */
-
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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Chris Wedgwood wrote:
[Gcc not eliminating trivial dead code...
did you compile without optimisation?]
Gcc 2.96 does remove the unreached code in your example,
but it still emits string constants.
int func()
{
if (1)
a = "foo";
else
a = "bar";
}
.LC0:
.string "foo"
.LC1:
.string "bar"
.text
.align 4
.globl func
.typefunc,@function
func:
pushl %ebp
movl%esp, %ebp
movl$.LC0, a
popl%ebp
ret
-- Jamie
-
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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Linus Torvalds wrote: > And I'm saying that if people really want to do this, then use the > computer to do it for you, having more than just "grep", and making your > tools aware of it. I'd just like to add, for the benefit of onlookers, that this is quite easy. Temporarily change name of `count' in struct page in your private tree; recompile. Voila! Every occurence of page->count will show as a compile error, with line number. Step through each one and make the change. Use editor macro if preferred. -- Jamie - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Chris Wedgwood wrote: > I think would be really cool if all this 'magic' in gcc (whatever > part of gcc is irrelevant right now) would be exported into a library > or shared object which editors could then load and use... dynamically > perhaps. Sorry, there's a GCC policy decision against putting it into a shared library. -- Jamie - 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] exporting IPv6 symbols
Enclosed is a patch that exports some IPv6 specific symbols on 2.4 so that finally IPv6 is accessible from modules. I bet there are bunch of other functions that needs to be exported as well but this is a start. There are also various IPv6 functions in 2.2 that should be exported for the same reasons; I can make a patch for 2.2 if there are no objections. This patch is against 2.4.0test7. -snip- diff -uNr ./net/netsyms.c ../linux-2.4-new/net/netsyms.c --- ./net/netsyms.c Fri Aug 18 20:26:25 2000 +++ ../linux-2.4-new/net/netsyms.c Wed Sep 6 13:02:10 2000 @@ -55,6 +55,7 @@ #include #include #include +#include #include #include @@ -255,6 +256,13 @@ #ifdef CONFIG_IPV6 EXPORT_SYMBOL(ipv6_addr_type); EXPORT_SYMBOL(icmpv6_send); +EXPORT_SYMBOL(ip6_route_input); +EXPORT_SYMBOL(ip6_route_output); +EXPORT_SYMBOL(rt6_lookup); +EXPORT_SYMBOL(ipv6_rcv); +EXPORT_SYMBOL(ip6_input); +EXPORT_SYMBOL(ip6_output); +EXPORT_SYMBOL(ip6_forward); #endif #if defined (CONFIG_IPV6_MODULE) || defined (CONFIG_KHTTPD) || defined (CONFIG_KHTTPD_MODULE) /* inet functions common to v4 and v6 */ -snip- Pekka Pekka Riikonen| Email: [EMAIL PROTECTED] SSH Communications Security Corp. | http://poseidon.pspt.fi/~priikone Tel. +358 (0)40 580 6673 | Kasarmikatu 11 A4, SF-70110 Kuopio PGP KeyID A924ED4F: http://poseidon.pspt.fi/~priikone/pubkey.asc - 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: O_CLOEXEC (was Re: thread rant)
dean gaudet wrote: > suppose you're building a threaded server to scale to 20k connections, > and you want to support fork()/exec() of CGIs dirctly (rather than > through a separate daemon process). > > if you don't use close-on-exec, then after fork before exec you have > to iterate over the 20k descriptors to close them all -- or you have > to walk your own data structures (a list of open sockets) to find what > descriptors are open and close them. > if you use O_CLOEXEC then it's not possible for an fd to be open which > isn't marked to be closed on the exec, and so you've no extra work to > do before exec. > > but if you try to use FD_CLOEXEC there's a critical section between > the open/socket/accept/pipe/... and the fcntl(). you pretty much have > to put it under a semaphore (although you can get away with a rwlock), > or iterate over all the descriptors. Yes, this is the worst part. Having to synchronise threads. > i've a hairbrained idea for replacing fd integers with pointers which > might actually scale better if anyone wants to hear it again. Completely hairbrained, would make no difference to scalability, and make accessing your user space data structures slower. (Think X window ids and the need to use a hash table instead of a flat table). O_ANYFD would, in principle, improve scalability. It was proposed a few years ago -- it means "kernel can return any fd, not necessarily the next free one". I don't think it was considered worth the effort. -- Jamie - 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/
if (CONFIG_FOO) Re: 2.4.0-test8-pre1 is quite bad / how aboutintegrating Rik's VM
On Tue, 5 Sep 2000, Alexander Viro wrote: > > The _real_ problem is preprocessor abuse. BTW, could we schedule for > 2.5 the following? > * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is. > * #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c. gcc will kill the unused > branches just fine. > * Yes, Virginia, it means that controlflow-affecting expansion has to > go. Good riddance, IMO. > > Goal: making sure that every bloody line of the files we choose to > compile goes through the parser. Will do wonders with test coverage and will > make analysis tools like tags viable. Then we can just use the gcc frontend > output as input for such beasts. > Problem: every bloody line will go through the parser. There is too many lines. Compilation is realy slow today. I'm affraid this approach would make it worse. Note that 2.4.0-test7 has more than 2.75 milion lines. Or did you mean drivers will be (optionally?) excluded from this compile-it-all-and-then-optimize-it-away? I can understand advantages the if(CONFIG_FOO) approach has, but I'm not sure it is worth compilation slowdown. Martin Martin "MaD" Douda WEB: http://martin.douda.net/ PHONE:+420603752779 ICQ# 86467013 EMAIL: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> (160 characters only) PGP:ID=0x6FE43023 Fingerprint:E495 11DA EF6E 0DD6 965A 54F3 888E CC9E 6FE4 3023 [1]+ Done rm -rf / - 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: linux-2.4.0-test8-pre5
[Linus] > - pre5 > - truncate. Guess what? We threw away the key to the clue-box. > - simplify signal notification. And remember the spinlock. > - VIA ide driver update (well, rewrite - the old one was buggy and broken) Can someone explain this line from the VIA update? #define FIT(v,min,max) (((v)>(max)?(max):(v))<(min)?(min):(v)) Barring side effects on the variables, it is equivalent to #define FIT(v,min,max) ((v)<(min)?(min):(v)) Why do I get the feeling that this was *not* the intent? Peter - 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: linux-2.4.0-test8-pre5
On Wed, 6 Sep 2000, Peter Samuelson wrote: > > - VIA ide driver update (well, rewrite - the old one was buggy and broken) > > Can someone explain this line from the VIA update? > #define FIT(v,min,max) (((v)>(max)?(max):(v))<(min)?(min):(v)) > Barring side effects on the variables, it is equivalent to > #define FIT(v,min,max) ((v)<(min)?(min):(v)) > > Why do I get the feeling that this was *not* the intent? Correct. The last v should be replaced with whatever that we got from (v)>(max)?(max):(v), like: #define FIT(v,min,max) (((v)>(max)?(max):(v))<(min)?(min):((v)>(max)?(max):(v))) Or perhaps this is a lot better: #define FIT(v,min,max) ((v)>(max)?(max):((v)<(min)?(min):(v))) Dan Aloni (dax) [EMAIL PROTECTED] - 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: eepro100 trouble
On Tue, Sep 05, 2000 at 12:35:16PM -0400, Kernel Related Emails wrote: > Has this been integrated into the 2.4.0-testX kernels? And if so which > version? No, it hasn't. A version with a workaround is at ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/v2.3/ It has been submitted it to Linus, but wasn't included in the kernel. I'll try to work more on this problem this weekend and submit the new code. Best regards Andrey V. Savochkin > On Tue, 5 Sep 2000, Andrey Savochkin wrote: [snip] > > But I expected 2.2.17pre20 to work, it contains a work-around which helped > > all other people complaining about the same things. > > Try the driver from > > ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/test/eepro100.c-nores-wa2 > > > > [snip] > > > eth0: card reports no RX buffers. > > > eth0: card reports no resources. - 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/
Clearing of Ram?
Hi all When I'm in user mode and malloc ram this portion of ram is cleared (zeroed) or? i think it is! My question is who cleared it the kernel or the malloc function in glibc?? (i found some code in glibc but nothing in kernel) thx mfg Frank Peters - 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: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
On Tue, 5 Sep 2000, Jeff V. Merkey wrote: >"Mike A. Harris" wrote: > >Here Mike, we need to update your email signature block to reflect your >new avocation (this is where I try to be your mega-buddy). I think the >reason I'm so obtuse is that God gave me such a thick skin (or perhaps a >thick skull). Oh, don't get me wrong Jeff... I'm saddened for the injury of your friend, as I don't like to hear of any human tradgedy such as that. I surely hope that he recovers indeed. That is separate however from my comments concerning yourself. When someone comes on linux-kernel, presumeably because they are interested deeply in Linux and supporting it by developing new code for it, drivers, etc.., and then every time there is a "writers block" or some other problem comes up, they denounce Linux as a platform, claim it is inferior to other OS's which they are developing for, retract code, etc... it wears thin after a while. Especially when they attack core developers for no real apparent reason other than perhaps programmers frustration, and then apologize 10 minutes later, just to do it again the next day. I've watched your threads for as long as you've been here, and I don't doubt that you're a skilled programmer at all. I just don't agree with your methods every time a problem occurs. Politely pointing out problems with Linux and discussing a sane manner in how to correct the problem is fine. Complaining and denouncing Linux and putting it behind NT, etc.. on the linux-kernel mailing list, is a sure-fire way to get messages back such as what I wrote. The Linux community consists of a group of many people who think very highly of Linux, for their own reasons, and when it becomes attacked needlessly by someone such as yourself, in a forum like this, it is just flame bait. Emotions towards Linux in here are like emotions towards Ford trucks to a truck nut. Offend a Ford, deal with the wrath of the truck guy. Words get spoken, life goes on. You choose to vent about your Linux frustrations in here knowing full well, that you'll offend people or upset people when you do. My response is nothing more than a reaction to that. I normally don't respond to your posts about these sort of things because I try to get beyond that type of thing. But just as you need to vent about how much Linux sucks, I need to vent about how much it pisses me off when people make FUD about Linux by saying it sucks. Your mail had no mention whatsoever of any hint of a "joke", and your tone didn't hint at that either. I don't think there was any joke. Either you were dead serious, trolling, or were venting frustrations. When you do so, you get brown stuff back. I vent now and again too, and I get brown stuff back sometimes because of it as well. I change my shirt and go on... So, do what you need to do for yourself, but realize that everyone else will do what they need to do for themselves as well. Offending most of the core linux developers all the time is hardly going to make you look good, or get anywhere. If you don't like Linux, and cant do what you'd like with it in a costly manner, then _please_ use NT, or Novell, or MANOS, and DO IT rather than talking about how much better they are, and sticking with Linux for development. I just don't understand the logic, thats all. -- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate If you're interested in computer security, and want to stay on top of the latest security exploits, and other information, visit: http://www.securityfocus.com - 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: Clearing of Ram?
[Frank Peters] > My question is > who cleared it the kernel or the malloc function in glibc?? > (i found some code in glibc but nothing in kernel) The kernel. Not to do so would be a security hole. (That memory could have been used for *anything*.) Peter - 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/
pagecache sysctl ignored? (fwd)
argggh couldn't they keep the rutgers.edu to be valid... or keep redhat.com - it's much easier to remember than kernel.org :) -- Forwarded message -- Date: Wed, 6 Sep 2000 12:31:06 +0100 (BST) From: Tigran Aivazian <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Rik van Riel <[EMAIL PROTECTED]> Subject: pagecache sysctl ignored? Hi guys, I always suspected that Linux VM is perfect but the apparent horrible performance thereof is merely due to bad choice of default tunables. Now, I changed /proc/sys/vm/pagecache to be "2 15 50" but I still see pagecache taking up more than 99% of my memory (instead of 50 or 65?). So I grepped the source and see that the tunable is in fact totally ignored. Is this what needs to be done to solve all so-called "Linux VM problems"? I.e. to find which parts of pagecache code need to be aware of the pagecache tunable (defined in mm/swap.c)? Regards, Tigran - 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: pagecache sysctl ignored? (fwd)
On Wed, Sep 06, 2000 at 12:52:42PM +0100, Tigran Aivazian <[EMAIL PROTECTED]> wrote: > > argggh couldn't they keep the rutgers.edu to be valid... or keep > redhat.com - it's much easier to remember than kernel.org :) redhat.com easier to remember than kernel.org? We're talking bout the kernel here, not redhat - this makes me wonder whether your logic goes beyond mine or what else goes wrong :) Ciao, Thomas -- Thomas Köhler Email: [EMAIL PROTECTED] | LCARS - Linux <>
Re: Quick memory corruption with cramfs
Hi! > > Is anyone using cramfs? > > We use cramfs everyday at http://handhelds.org with Linux > 2.4.0-test6-rmk1-np2-hh1. We have no problems. I use test4-pre3 from linux-vr tree. > > I copy cramfs image from nfs onto /dev/ram0, then mount it. It mounts, > > and first few accesses are okay, but then it breaks. ls shows garbage > > etc. > > We run the cramfs image out of flash instead of ram. Are you mounting the > cramfs image as 'ro'?? I used not to. Now I mounted it ro, and, well, it did not help. ls -al /mnt/bin followed by ls -al /mnt/etc; and I end up with garbage. I mount cramfs by mount -tcramfs -n -o ro /dev/ram0 /mnt after listing of /mnt/bin, md5sum of [relevant part of] /dev/ram0 changes. What is also strange is that ls -al reports error 'file not found' on on dangling symlinks. (But this is ls from busybox, so it maybe well its fault.) Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - 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/
Multiple Keyboards in 2.2/2.4?
Is it / will it be possible to run multiple, or at least two keyboards before the new linux console code in 2.5? What we would like to do is to run multiple user sessions off a single machine. Using either Dualhead graphics cards, or simply using two graphics cards, the display is not a problem (although console support would be nice we only really need X), and multiple mice is not a problem with either two USB mice or one USB and one PS/2. However, there does not seem to be a way to address a second keyboard seperately at the moment. Looking at the linux console project the multi-head code "ruby" seems to be aimed at 2.5. I was wondering if there is any chance of being able to address keyboards before then? Nick Ie. Given that displays and mice almost work, we think it would be really cool to have two people work from a single box. AFAIK keyboard is the only issue stopping this... -- Nick Towers : Systems developer, Dept. of Computing, Imperial College [EMAIL PROTECTED] or mailto:[EMAIL PROTECTED] for point and click If you feel lucky visit my web site - http://www.doc.ic.ac.uk/~ncet/ - 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] devfs support for LVM
On Tue, 5 Sep 2000, Richard Gooch wrote: > > Yes. The userlevel tool can't handle other things without recompiling. > > Don't worry about that. I can add a rule to devfsd so it creates > appropriate compatibility entries. But the userlevel tool needs fixed too. Recompiling is fine, as long as it is easy to configure, a config file might be nice also. I know devfsd is nice and good, but I don't use it. At this point I have ALL my programs working without it. > > I can't use /dev/lvm, too because this is the name of the control file > > without lvm (and the lvm tools will barf if this is a dircetory. > > Well, how about another directory name? Can you think of something > else that would be appropriate? And no, "LVM" is not on! How about releasing a new version of the userlevel tools. Just list it as the required version in the Changes file. Have the new version check to see if /dev/lvm is a directory or file. It probally isn't the best idea to assume too much based on that fact, but it could be used as a basis for devfs vs. traditional /dev compatibility in one executable without needing a recompile. > But we really should stop namespace pollution in /dev, and doing it > before 2.4 is released is the best time. In fact, given that this > patch has only gone in recently, I'd be inclined to go with the names > I suggested and just break the userspace tools. People have to expect > that things may change before a production kernel is released. We just required a modutils upgrade. No one really complained. A few people (not many at all) cried about things breaking. But a quick pointer to the Changes file set them straight. So yes, do this now. -Chris -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - 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: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
On Wed, Sep 06, 2000 at 09:36:08PM +1100, [EMAIL PROTECTED] wrote: [...] > > Lots of people (myself included) would like to be able to debug and > generally hack the Linux kernel but cannot due to lack of time and the > steep learning curve imposed by the lack of a debugger and good > documentation. Good documentation is really the main point, more than an appropriate debugger. [...] > > -d > > -- > | ``The power of accurate observation is | Damien Miller <[EMAIL PROTECTED]> > | commonly called cynicism by those who | @Work <[EMAIL PROTECTED]> > | have not got it'' - George Bernard Shaw | http://www.mindrot.org > -- Thierry Danis - 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: Clearing of Ram?
On Wed, 6 Sep 2000, Frank Peters wrote: > My question is who cleared it the kernel or the malloc function in > glibc?? (i found some code in glibc but nothing in kernel) thx it's the second clear_user_highpage() in mm/memory.c that does the page clearing in the typical malloc()-ed memory case. It's only allocated and cleared once you or glibc accesses it, with page granularity. Ingo - 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: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: "Ingo Molnar" <[EMAIL PROTECTED]>
> > If the Kernel Debugger creates faulty solutions through lack of
> > thinking, and asking why, then surely printk is at least as bad
> > because it allows somebody to view the operation of the kernel through
> > a keyhole darkly. [...]
>
> i'd like to quote David here, because i cannot put it any simpler:
>
> " It is hoped that because it isn't the default, some new people
>will take the quantum leap to actually try debugging using the
>best debugger any of us have, our brains, instead of relying on
>automated tools. "
I note again that the same arguement applies vis a vis printk
and desk checks with a paper and pencil. The printk leverages
the capable person's time. The kernel debugger leverages
the capable person's time. What IS this urge to be handicapped
when trying to debug the most important pieces of what gets
delivered on the distribution CDROMs. Is it, "I'm so hairy chested
that I can code with one metaphorical arm tied behind my
equally cliched back?" Rather seriously this seems to be a
rather transparent attempt to keep the old boy's club closed
rather than an attempt to get the most bang for each old boy's
hour of debugging and coding time.
Good tools do not foster bad code. People foster bad code.
The converse is also true.
> my claim (which others share) is that we need more people who can debug
> the really tough problems (for which there are no tools in any OS) with
> their brains, and also we need people who will produce code with less bugs
> in the future.
And absense of tools fosters this? I would think it would drive many
serious people off figuring it is a fancy toy regardless of how effective
it may be serving up web pages for ever and ever amen.
In that regard I enjoy my "Yes!" (with a raised "I won" fist) reactions
when I finally knock down a problem. But I have gotten older now and
realize that 16 million seconds per year is about all I get on a practical
basis for generating these moments. I want to leverage my talents
for the best chances of creating these moments and knowing these
moments are valid and not spurious. A good debugger is a very
good leveraging agent. I can cut a 2x4 with a largish pocket knife,
in theory. (I have never wasted the time.) In a pinch I have cut a
2X4 with a hand saw. I can see that if I wanted to do this for any
serious work power tools are required. The same logic seems
to fall into the programming realm.
> There is also the important question of 'bug prevention'. The kernel isnt
> some magical soup which must be debugged only, code is *added* and
> debugged. If people who write code use more code reviews to fix bugs, then
> as a side-effect they'll sooner or later write code that is less prone to
> bugs. This is because they identify the bug-risks based on the code
> pattern - if you use a debugger mainly then you dont really see the code
> pattern but the current state of the system, which you validate. So the
> difference is this:
>
> - compare code, algorithm and concept with the original intention;
>analyze the symptoms and find the bug
>
> - compare the system state discovered through the debugger with the
>intended state of the system. Potentially step through the code before
>and after the faulty behavior, try to identify the 'point of bug' and
>constantly compare actual system state with intended system state.
>(it's certainly more complex than this, but you get the point.) This is
>why tools/features visualizing system state are so popular.
>
> i claim that the second behavior is 'passive', 'disconnected' and has no
> connection to the code itself, and thus tends to lead to inferior code. It
> leads to the frequent behavior of 'patching the state', not modifying the
> code itself. Eg. 'ok, we have a NULL here, lets return then so it wont
> crash later in the function.'
>
> The first behavior IMO produces a more 'integrated' coding style, where
> designing, writing and debugging code is closely interwoven, and naturally
> leads to higher quality code. Eg. 'we must never get a NULL here, who
> called this function and why??'.
This is all motherhood and has little or nothing to do with the presence or
absense of leveraging agents. Sure a dolt will produce more doltish code
per mega disk revolution with the leveraging agent than without. On the
other extremity a guru will produce more good code per mega disk
revolution, too.
Linux's Open Source nature leverages quantities of people fairly effectively.
Some attention appears to be needed to leverage the abilities of the few
GOOD people. (And I note that a good debugger is a good way to figure
out how the code works for some people who do not visualize from written
code all that well. Since Linux documentation is little or no better than NT
documentation these people are stranded unless they can see what is
happening "in vitro".)
{^_^}
-
To unsubscribe from this list: send the line "unsubscribe lin
Re: Remarks about sigtestsetmask()
Alan Cox wrote: > > > 1. This function is only used in the poorly maintained ftape driver. > >The usage there isn't appriopriate for modern kernels. > > The ftape driver isnt exactly poorly maintained. Its just not integrated into > 2.3/2.4. Ftape 4.0 is still elsewhere This is wrong, since last time I checked the maintainer stepped back from the tast. And I understand reintegration into the mainstream kernel proper maintainance as well. (The two versions are *VERY* different). - 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]2.4.0-test6 "spinlock" preemption patch
George Anzinger wrote: > > This patch, for 2.4.0-test6, allows the kernel to be built with full > preemption. Neat. Congratulations. > ... > The measured context switch latencies with this patch > have been as high as 12 ms, however, we are actively working to > isolate and fix the areas of the system where this occurs. That has already been done! From memory, there are three long-lived spinlocks which affect latency. Try applying http://www.uow.edu.au/~andrewm/linux/low-latency.patch Also, review Ingo's ll-patch. He may have picked up on some extra ones. http://www.redhat.com/~mingo/lowlatency-patches/ - 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] sr.c 2.4.0-test8-pre5 breakage
Em Wed, Sep 06, 2000 at 02:42:02AM -0700, Joshua Uziel escreveu:
> Heya acme... seems you fixed the sr.c driver a bit too much and
> killed an #ifdef MODULE that was needed if you build without
Nope, I didn't touched this, Jens?
- Arnaldo
> modules (as I do on some of my SPARCs)... this change was made
> in 2.4.0-test8-pre5...
>
> drivers/scsi/scsidrv.o: In function `init_sr':
> drivers/scsi/scsidrv.o(.text+0x1ece8): undefined reference to
> `scsi_register_module'
> drivers/scsi/scsidrv.o: In function `exit_sr':
> drivers/scsi/scsidrv.o(.text+0x1ed08): undefined reference to
> `scsi_unregister_module'
> make: *** [vmlinux] Error 1
>
> Patch is as follows:
>
> --- linux/drivers/scsi/sr.c Wed Sep 6 02:38:24 2000
> +++ linux-test/drivers/scsi/sr.c Wed Sep 6 02:37:18 2000
> @@ -848,6 +848,8 @@
> return;
> }
>
> +#ifdef MODULE
> +
> int init_sr(void)
> {
> sr_template.module = THIS_MODULE;
> @@ -880,3 +882,5 @@
>
> module_init(init_sr);
> module_exit(exit_sr);
> +
> +#endif /* MODULE */
-
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] sr.c 2.4.0-test8-pre5 breakage
On Wed, Sep 06 2000, Arnaldo Carvalho de Melo wrote: > Em Wed, Sep 06, 2000 at 02:42:02AM -0700, Joshua Uziel escreveu: > > Heya acme... seems you fixed the sr.c driver a bit too much and > > killed an #ifdef MODULE that was needed if you build without > > Nope, I didn't touched this, Jens? Yeah, this is my booboo not Arnaldo's. -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - 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/
Fwd: ACPI & I4L irq confilct: bug reporting on kernel 2.4.0-test8-pre4
>Hi ! >This is a bug reporting, included are the output of various /proc file on >my system: >Motherboard: ASUS P2B-F with the latest bios bx2f113.awd (microcode update) >ISDN: Winbond based card (Hisax type=36) >Distribution: based on updated SuSE 6.4 >The problem is that if I compile the kernel (2.4.0-test8 pre1,pre2,pre3,pre4) >with both ACPI support and ISDN support there is a conflict in irq 9. >I think ACPI first get irq 9 and then Hisax can't get it. Consequentially >Hisax doesn't work if ACPI support is enabled. >With ACPI turned off, everything works fine as with previous kernel test6 >and test5 and >Many thanx. after further testing the problem seems to be in IRQ SHARING. in fact, with acpi disabled, once the hisax has got irq 9 (it is not possible for card type 36 to change the irq), i can load the ethernet modules 8390 and ne2k-pci for my ethernet PCI NE2000 card, but the ne2k-pci driver also set its irq=9, so everytime i try to do: ifconfig eth0 up i get: SIOCSIFFLAGS: resource temporarily unavailable why don't add the irq parameter to the hisax winbond driver and to the ne2k-pci driver ? p.s. my motherboard has pci slot 4 and slot 5 condivided and the isdn card is on slot 4 while ethernet on slot 5 so one may say "change your motherboard", but everything worked fine with previous kernels (ACPI, Hisax, ethernet) Please help me. Many thanx. Please answer only via email: [EMAIL PROTECTED] -- bye, Guido Trentalancia CPU0 0: 140258 XT-PIC timer 1: 4460 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 425229 XT-PIC es1371 9: 9840 XT-PIC HiSax 10: 16940 XT-PIC aic7xxx 12: 53956 XT-PIC PS/2 Mouse 13: 1 XT-PIC fpu NMI: 0 ERR: 0 Character devices: 1 mem 2 pty 3 ttyp 4 ttyS 5 cua 7 vcs 10 misc 14 sound 43 ttyI 44 cui 45 isdn 128 ptm 136 pts 162 raw Block devices: 8 sd 65 sd 66 sd -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 02f8-02ff : serial(auto) 03c0-03df : vga+ 03f8-03ff : serial(auto) 0cf8-0cff : PCI conf1 b000-b01f : Realtek Semiconductor Co., Ltd. RTL-8029(AS) b000-b01f : ne2k-pci b400-b4ff : Adaptec AHA-2940U2/W b400-b4fe : aic7xxx b800-b83f : Ensoniq ES1371 [AudioPCI-97] b800-b83f : es1371 d000-d0ff : Dynalink IS64PH ISDN Adapter d000-d0ff : TA XXX d400-d41f : Intel Corporation 82371AB PIIX4 USB d800-d80f : Intel Corporation 82371AB PIIX4 IDE e400-e43f : Intel Corporation 82371AB PIIX4 ACPI e800-e81f : Intel Corporation 82371AB PIIX4 ACPI Linux version 2.4.0-test8 (root@kleopatra) (gcc version 2.95.2 19991024 (release)) #1 Wed Sep 6 13:11:45 CEST 2000 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 701.599904 cache size : 256 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr xmm bogomips: 1399.19 Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: IBM Model: DNES-309170W Rev: SA30 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: PLEXTOR Model: CD-ROM PX-32TS Rev: 1.02 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 02 Lun: 00 Vendor: YAMAHA Model: CRW8424S Rev: 1.0j Type: CD-ROM ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 03 Lun: 00 Vendor: Model: Scanner 636A4Rev: 1.10 Type: Scanner ANSI SCSI revision: 02
Re: [PATCH] devfs support for LVM
On Wed, Sep 06, 2000 at 08:46:46AM +0200, Christoph Hellwig wrote: > On Tue, Sep 05, 2000 at 11:51:14PM -0600, Richard Gooch wrote: > > > I can't use /dev/lvm, too because this is the name of the control file > > > without lvm (and the lvm tools will barf if this is a dircetory. > > > > Well, how about another directory name? Can you think of something > > else that would be appropriate? And no, "LVM" is not on! > > I used lvm.d in my early version, but this is a little bit ugly, too ... > > > But we really should stop namespace pollution in /dev, and doing it > > before 2.4 is released is the best time. In fact, given that this > > patch has only gone in recently, I'd be inclined to go with the names > > I suggested and just break the userspace tools. > > Please don't do it now. Yes! > I can add a patch that does full-blown devfs > checking to the tools, but this needs a lot of work. Actually changing the tools to recognize devfs seems fairly simple. I am already working on it. _But_ the LVM Metadata on disk has the old names stored which causes the need to have an old naming sceme to new naming sceme admin change tool for handling this. > Until then please leave it the old way so people don't have to remount > root just to create the device nodes. > When the new tools are out, they can be put into 'Changes' > as required version and the devfs names can be changed. Yep. > > Christoph > > -- > Always remember that you are unique. Just like everyone else. > - > 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/ -- Regards, Heinz -- The LVM guy -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Heinz Mauelshagen Sistina Software Inc. Senior Consultant/Developer Bartningstr. 12 64289 Darmstadt Germany [EMAIL PROTECTED] +49 6151 7103 86 FAX 7103 96 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - 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: scheduler policy question
Hubert Tonneau wrote: > > Benchmarking Pliant (http://pliant.cx/) semaphores led to unexpectedly > low results. The problem to either kernel bad features or bugs in my > program since Pliant uses no glue library such as glibc: it calls > directly kernel funtions. > > Not enough scheduling problem: > - > I traced the problem to the fact that when the semaphore is locked, > I call sched_yield kernel function expecting that it will switch > to another thread, whereas my results seem to mean that it does not. > On the other hand, calling nanosleep kernel function with 0 as tv_sec and > tv_nsec does exactly what I would have expected from sched_yield. > Did I misunderstood sched_yield semantic ? NO. Yield has been broken more than not. It is broken in 2.4.0-test6 for example. > So, sched_yield function seems to do nothing on my 2.2.15 UP box. On the other > hand, on my 2.0.38 SMP box, it seems to work as expected (same as nanosleep 0) > > Too much scheduling problem: > --- > In order to restart a stopped thread (which sent a SIGSTOP signal to itself), > I send a SIGCONT signal to the target thread using kill kernel function. > The problem here is that it seems (also what I deduced from benchmarks) that > the calling thread will be preempted immediatly. > This is a big problem in the case I want to restart a set of threads > at once (in case they are waiting for read access on a semaphore) and also a > small one in the very general case since they is too much ping pong between > the various threads dealing with the semaphore resulting in too much wasted > time in the kernel scheduler. > So my question is how can I restart another thread and continue running > the current one until it's time slice ends ? One answer is to jump to a real time priority. Fall back when you want to yield. Problem is you need root priv to do the call. George - 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: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
> What IS this urge to be handicapped > when trying to debug the most important pieces of what gets > delivered on the distribution CDROMs. Is it, "I'm so hairy chested > that I can code with one metaphorical arm tied behind my > equally cliched back?" There are those that like to visualize things and there are those that like to experience them. Neither is _necessarily_ wrong but Linux tends to have more of the former, and the latter have yet to write what they consider to be a good kernel debugger. (Yes, a debugger is a tool for _experiencing_ not a tool for _visualizing_) > A good debugger is a very > good leveraging agent. I can cut a 2x4 with a largish pocket knife, > in theory. (I have never wasted the time.) In a pinch I have cut a > 2X4 with a hand saw. I can see that if I wanted to do this for any > serious work power tools are required. The same logic seems > to fall into the programming realm. I disagree. No one here is dumb enough to use a wholely inappropriate tool for a particular task. But using a debugger is often (but not always) like sawing bits off your 2x4 until it happens to fit the gap. What you need to do is to understand the problem parameters, measure them, mark your 2x4, then cut using whatever tool is best suited to the job. In woodwork the results tend to be superior :-) Mike - 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] devfs support for LVM
On Wed, Sep 06, 2000 at 03:48:53PM +, Heinz J. Mauelshagen wrote: > > I can add a patch that does full-blown devfs > > checking to the tools, but this needs a lot of work. > > Actually changing the tools to recognize devfs seems fairly simple. > I am already working on it. > > _But_ the LVM Metadata on disk has the old names stored which causes the > need to have an old naming sceme to new naming sceme admin change tool > for handling this. That's the most difficult thing I was thinking about. My idea was to simply ignore the actual name of the pv and use it as UUID instead. I'll post the proposal to linux-lvm soon. Christoph -- Always remember that you are unique. Just like everyone else. - 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: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
"J. Dow" <[EMAIL PROTECTED]> said: [...] > I note again that the same arguement applies vis a vis printk > and desk checks with a paper and pencil. The printk leverages > the capable person's time. The kernel debugger leverages > the capable person's time. What IS this urge to be handicapped > when trying to debug the most important pieces of what gets > delivered on the distribution CDROMs. Problem is: - Debugging code has to be written, integrated and debugged. It has to be designed for collecting certain types of data. If you get the data to be collected wrong, it is useless (and as you don't know what bugs you are looking for, you _will_ get it wrong most of the time, unless you collect everything in sight) - Debugging code impacts readability, writeability, and performance of the instrumented code, specially if it is pervasive (and most functionality isn't localized) - Debugging harnesses have to evolve together with the instrumented code. If they don't, they are just a liability. If they do, they double (probably more) the development time, as they have to be kept in synch. - Broken debugging code impacts stability Do we want Linus & Co. writing cool kernel code or writing a whiz-bang kernel code debugger? Developer time _is_ finite, you know... Witness the people who have argued _against_ integrating debugging code into the kernel, *even code they designed and wrote themselves*. Check out stuff like the user-level kernel, AFAIU there it is possible to attach a run-of-the-mill debugger to a live kernel. Or look at the remote debugging stubs for gdb. It is not that they don't want better tools, the problem is that the tools available (or buildable at a reasonable cost) are woefully inadequate to the task at hand. Typical (low-level!) question when debugging is "Where the $EXPLETIVE does this $WRONG_VALUE in $RANDOM_VARIABLE come from?", and no current debugger is able to give you even that little. Sure, you can single-step to the point of failure, but it is often faster to just grep for the places where it can be changed. Don't even think about asking stuff like "Why is $RANDOM_FUNCTION being called so much?". Given this scenario, the only useful tool is a good understanding of the kernel; instrumentation which gets more in the way than its usefulness warrants is just left out, or rots away. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forlinux
Hello all, I feel the need to shed some light on this subject from the viewpoint of one MUCH less capable than the others here. Recently I purchased a PPC 7200. It is a beat up old mac that I could pick up cheap. I have used intels since I was a boy (SysV3.3 on 386!) and saw some characteristics of the mac that were lacking in the intel boxes. Finally, I tried to use the box to do some video grabbing only to find that the 2.2, 2.3, and 2.4 kernel all failed. I Attempted to read the code, and use kdb, only it doesn't appear to work on the mac very well. And I don't have a mac serial to 9/25-pin adapter. So I have to go to Orlando to get one. This is a two hour drive for me, and not worth my time, thus gdb is out of the question. I have sent some questions out to that community and they have been unresponsive on this one (I guess no one uses the happauge wintv on those boxes). The result is a powerpc that will be used for little more than a file server. (I am greatful that it can be used for this much.) Some more options for this little machine would have been useful at the time. And while I realize that the push for intel far outweighs the push for Mac or Sparc, there is a following that could use some (more) kernel level help. This really is an issue that spans far beyond just which, if any, kernel debugger should be available in the kernel sources. This gets back to the organization on the whole. While I might be calling on a giant with a roaches voice, where does Linus stand on this? Mechanics fought computers and the analysis tools that went with them for years. Now, a good mechanic can turn around more cars than ever possible with accurate use of the excellent tools available to him. Please don't nix this tool before it gets a chance to prove its worth. I sometimes feel that the linux community, possibly from the top, has forgotten that this community was founded on making 'it' work, and work well. Part of this is incorperating good ideas where they are seen. And discarding good (and of course bad) ideas where they are not valuable. Some of the other OS's (notably the BSD's) have some good ideas. Possibly the manos debugger is one of them. We should not discard those ideas because 'It has been done this way since 1993!' Please don't forget this! This type of mindset could be very costly in the long-run. Thanks for your time, and I hope this has been useful. -- Matt Berglund One guy for a unified OPERATING SYSTEM (not just a kernel) on all platforms, from Palmtop to Mainframe. And linux has the best shot. darkstar.sourceforge.net - 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] devfs support for LVM
On Wed, Sep 06, 2000 at 04:02:15PM +0200, Christoph Hellwig wrote: > On Wed, Sep 06, 2000 at 03:48:53PM +, Heinz J. Mauelshagen wrote: > > > I can add a patch that does full-blown devfs > > > checking to the tools, but this needs a lot of work. > > > > Actually changing the tools to recognize devfs seems fairly simple. > > I am already working on it. > > > > _But_ the LVM Metadata on disk has the old names stored which causes the > > need to have an old naming sceme to new naming sceme admin change tool > > for handling this. > > That's the most difficult thing I was thinking about. > My idea was to simply ignore the actual name of the pv and > use it as UUID instead. I already did that in the actual 0.9 LVM source. Every PV has its own UUID now and a list of all the UUIDs of all PVs of the VG in case it belongs to one. > > I'll post the proposal to linux-lvm soon. > > > Christoph > > -- > Always remember that you are unique. Just like everyone else. > - > 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/ -- Regards, Heinz -- The LVM guy -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Heinz Mauelshagen Sistina Software Inc. Senior Consultant/Developer Bartningstr. 12 64289 Darmstadt Germany [EMAIL PROTECTED] +49 6151 7103 86 FAX 7103 96 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - 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: Linux 2.2 - BSD/OS 4.1 ARP incompatibility
On Mon, 4 Sep 2000, Andi Kleen wrote: > > /proc/sys/net/ipv4/\"correct\"_arp_reply_interface_selection > It is called arpfilter. Here is the old 2.2.16 version (applies to 2.4 > with minor changes) > > It is useful for various things, one of them being automatic load > balancing for incoming connections using multipath routes. Cute. Is there a chance that this might sneak into an official kernel someday? Matthew. - 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: Still ext2-corruption in test8-pre5 (incl. OOPS)
--On 09/05/00 21:35:13 -0400 Chris Mason <[EMAIL PROTECTED]> wrote: > > Ok, hopefully this will make sense... > > __block_commit_write calls balance_dirty, which might wait on bdflush, > running all the io on the page. The async_end_io handlers will unlock > the page once io on all the buffer heads is done. > > So, by the time generic_file_write (or the new truncate code) calls > UnlockPage, the page could have been unlocked by i/o, and relocked by > another process. > > Or am I missing something? > Ah, I was missing that __block_prepare_write and __block_write_fullpage both set the end_io handler to end_io_sync. In one case, reiserfs is doing i/o without properly setting the handler, which is why I was seeing bugs caused by the above problem, and ext2 wasn't. -chris - 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: Still ext2-corruption in test8-pre5 (incl. OOPS)
On Tue, Sep 05, 2000 at 07:14:02PM -0700, Linus Torvalds wrote: > How about this patch? Got this oops. Tim. */ ksymoops 2.3.3 on i586 2.4.0-test8-pre5+trfix. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test8-pre5+trfix/ (default) -m /boot/System.map-2.4.0-test8-pre5+trfix (specified) Unable to handle kernel NULL pointer dereference at virtual address c012cae6 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: ebx: 0080 ecx: edx: 0c00 esi: c10f02c0 edi: 0400 ebp: 0242 esp: c39d5e38 ds: 0018 es: 0018 ss: 0018 Process pine (pid: 1295, stackpage=c39d5000) Stack: 0084 c63353c0 c1299e0a c10f02c0 c654b2c0 c63353c0 0081 0dbe 0020 c0148487 c633545c 00020dbe c014786c c63353c0 0048 c39d5f70 00020dbe c3c0d600 c1299e00 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 8b 00 ff 44 24 20 89 44 24 2c 39 54 24 24 73 ea 8b 54 24 2c >>EIP; c012cae6<= Trace; c0148487 Trace; c014786c Trace; c012036b Trace; c011e685 Trace; c011e776 Trace; c013c41a Trace; c013c4e8 Trace; c0128b99 Trace; c0128e00 Trace; c0108e4f Code; c012cae6 <_EIP>: Code; c012cae6<= 0: 8b 00 movl (%eax),%eax <= Code; c012cae8 2: ff 44 24 20 incl 0x20(%esp,1) Code; c012caec 6: 89 44 24 2c movl %eax,0x2c(%esp,1) Code; c012caf0 a: 39 54 24 24 cmpl %edx,0x24(%esp,1) Code; c012caf4 e: 73 ea jaefffa <_EIP+0xfffa> c012cae0 Code; c012caf6 10: 8b 54 24 2c movl 0x2c(%esp,1),%edx - 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: ps2esdi maintainer?
On Wed, 06 Sep 2000, A Duston wrote: > Hello, > > I am trying to contact the ps2esdi maintainer, as I have > some questions about the driver. I have an ancient PS/2 > Thinkpad that gives an annoying but cosmetic error when > it boots. I can't recall a time where that cosmetic error didn't exist. Something to do with probing for a second drive, IIRC, which never exists on the Integrated ESDI controller of the TP. >I contacted David Weinehall earlier, but he > isn't sure who the mainainer is. The last "maintainer" that I know of was myself, but all I was ever able to do was ensure that it didn't crash and burn on the TP and model 55SX. I only have the TP now, so I don't intend to go messing with it (last time I did that, we lost support for multiple ESDI drives). It's a little difficult to maintain drivers with no documentation and insufficient test hardware... Unforunately, the original author disappeared years ago. c. -- [EMAIL PROTECTED] Aviation and Defence Services Environment Canada CFB Trenton (613) 965-2762 - 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: Should O_NONBLOCK be copied from listening socket to accepting socket?
David S. Miller wrote: > Alexey tried to do this "fix" and when I tested his change we spotted > this issue and thus did not put the "fix" in what we sent to Linus. Is this patch available somewhere on the net? I really need it. - 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: Fwd: ACPI & I4L irq confilct: bug reporting on kernel 2.4.0-test8-pre4
Guido Trentalancia schrieb: Hello Guido, > > >Hi ! > >This is a bug reporting, included are the output of various /proc file on > >my system: > >Motherboard: ASUS P2B-F with the latest bios bx2f113.awd (microcode update) > >ISDN: Winbond based card (Hisax type=36) > >Distribution: based on updated SuSE 6.4 > > >The problem is that if I compile the kernel (2.4.0-test8 pre1,pre2,pre3,pre4) > >with both ACPI support and ISDN support there is a conflict in irq 9. > >I think ACPI first get irq 9 and then Hisax can't get it. Consequentially > >Hisax doesn't work if ACPI support is enabled. > >With ACPI turned off, everything works fine as with previous kernel test6 > >and test5 and > >Many thanx. > > after further testing the problem seems to be in IRQ SHARING. > in fact, with acpi disabled, once the hisax has got irq 9 (it is not possible > for card type 36 to change the irq), i can load the ethernet modules > 8390 and ne2k-pci for my ethernet PCI NE2000 card, but the ne2k-pci > driver also set its irq=9, so everytime i try to do: > > ifconfig eth0 up > > i get: > > SIOCSIFFLAGS: resource temporarily unavailable > > why don't add the irq parameter to the hisax winbond driver and to the > ne2k-pci driver ? there is no need or even sense to add such parameter, as irqs are assigned by the bios or OS for PCI type cards. The driver is supplied with the selected irq which is normally assigned during boot by the systems bios. You should change the bios PCI/Pnp setup to reflect your needs. I don't know if the Winbond driver supports IRQ-sharing, but other i4l drivers like the HFC-PCI which I maintain allow irq sharing without any problems even if 3 cards share it. So please setup your bios correctly and everything will work fine. > > p.s. > my motherboard has pci slot 4 and slot 5 condivided and the isdn card is > on slot 4 while ethernet on slot 5 so one may say "change your > motherboard", but everything worked fine with previous kernels (ACPI, Hisax, > ethernet) > > Please help me. > Many thanx. > Please answer only via email: [EMAIL PROTECTED] > -- > bye, > Guido Trentalancia > Werner - 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: eepro100 trouble
On Tue, 5 Sep 2000, Andrey Savochkin wrote: > Hello, > > On Sun, Sep 03, 2000 at 02:57:54PM -0300, Cesar Eduardo Barros wrote: > > > > I'm having endless problem with an eepro100 here. After some trying found out > > that doing a soft reset (ctrl+alt+del) fixed the problem, and that a power > > cycle made it happen again. > > > > Kernel version is 2.2.17pre20 > > The problem you faced is a known one. > But I expected 2.2.17pre20 to work, it contains a work-around which helped > all other people complaining about the same things. is it fixed in 2.2.17 final or any of the 2.2.18 releases? My eepro100 has been working fine (i'm in 2.2.15pre18) and i'm planning to upgarde to 2.2.17. Wondering if it's a longstanding problem or a NEW one. -Cygnus .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://www.asteroid-b612.orghttp://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. - 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: eepro100 trouble
* Admin Mailing Lists ([EMAIL PROTECTED]) wrote: > On Tue, 5 Sep 2000, Andrey Savochkin wrote: > > > On Sun, Sep 03, 2000 at 02:57:54PM -0300, Cesar Eduardo Barros wrote: > > > > > > I'm having endless problem with an eepro100 here. After some trying found out > > > that doing a soft reset (ctrl+alt+del) fixed the problem, and that a power > > > cycle made it happen again. > > > > > > Kernel version is 2.2.17pre20 > > > > The problem you faced is a known one. > > But I expected 2.2.17pre20 to work, it contains a work-around which helped > > all other people complaining about the same things. > > is it fixed in 2.2.17 final or any of the 2.2.18 releases? My eepro100 has > been working fine (i'm in 2.2.15pre18) and i'm planning to upgarde to > 2.2.17. Wondering if it's a longstanding problem or a NEW one. In 2.2.17pre20 I started running into *really* annoying issues w/ an eepro100, I'm going to go back to 2.2.16 and see if they clear up. Basically things were constantly seeming to stall for me. Not everything though, it seemed like larger things would whereas smaller things wouldn't, but only sometimes. :) Examples: dmesg consistantly would stall ps awux had no real issues (small process list) top worked okay switching between windows under screen quickly would stall it grabbing kernel source wasn't a problem scp'ing a couple >1M files wasn't an issue Very odd. Never had any problems w/ eepro100's under 2.2.16 or earlier. Stephen PGP signature
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Jamie Lokier writes: > Chris Wedgwood wrote: > > I think would be really cool if all this 'magic' in gcc (whatever > > part of gcc is irrelevant right now) would be exported into a library > > or shared object which editors could then load and use... dynamically > > perhaps. > > Sorry, there's a GCC policy decision against putting it into a > shared library. Why? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
acenic-v0.46 update
Hi
Here is a patch for the acenic-v0.46 driver relative to whats in
test8-pre4 - it solves a few bugs and cleans up a few minor issues in
the code and comments.
I have been unable to test this patch but looking over the changes I
cannot see any reason why it would cause problems.
Jes
--- ../linux/drivers/net/acenic.c Fri Jul 28 15:47:19 2000
+++ drivers/net/acenic.cTue Sep 5 15:21:11 2000
@@ -29,7 +29,12 @@
* infrastructure and Sparc support
* Pierrick Pinasseau (CERN): For lending me an Ultra 5 to test the
* driver under Linux/Sparc64
- * Matt Domsch <[EMAIL PROTECTED]>: Detect 1000baseT cards
+ * Matt Domsch <[EMAIL PROTECTED]>: Detect Alteon 1000baseT cards
+ * Chip Salzenberg <[EMAIL PROTECTED]>: Fix race condition between tx
+ * handler and close() cleanup.
+ * Ken Aaker <[EMAIL PROTECTED]>: Correct check for whether
+ * memory mapped IO is enabled to
+ * make the driver work on RS/6000.
*/
#include
@@ -83,8 +88,13 @@
#define PCI_VENDOR_ID_NETGEAR 0x1385
#define PCI_DEVICE_ID_NETGEAR_GA6200x620a
#endif
+#ifndef PCI_DEVICE_ID_NETGEAR_GA620T
+#define PCI_DEVICE_ID_NETGEAR_GA620T 0x630a
+#endif
+
/*
- * They used the DEC vendor ID by mistake
+ * Farallon used the DEC vendor ID by mistake and they seem not
+ * to care - stinky!
*/
#ifndef PCI_DEVICE_ID_FARALLON_PN9000SX
#define PCI_DEVICE_ID_FARALLON_PN9000SX0x1a
@@ -389,7 +399,7 @@
static int dis_pci_mem_inval[ACE_MAX_MOD_PARMS] = {1, 1, 1, 1, 1, 1, 1, 1};
static const char __initdata *version =
- "acenic.c: v0.44 05/11/2000 Jes Sorensen, [EMAIL PROTECTED]\n"
+ "acenic.c: v0.46 09/05/2000 Jes Sorensen, [EMAIL PROTECTED]\n"
"http://home.cern.ch/~jes/gige/acenic.html\n";
static struct net_device *root_dev = NULL;
@@ -429,7 +439,8 @@
!((pdev->vendor == PCI_VENDOR_ID_3COM) &&
(pdev->device == PCI_DEVICE_ID_3COM_3C985)) &&
!((pdev->vendor == PCI_VENDOR_ID_NETGEAR) &&
- (pdev->device == PCI_DEVICE_ID_NETGEAR_GA620)) &&
+ ((pdev->device == PCI_DEVICE_ID_NETGEAR_GA620) ||
+ (pdev->device == PCI_DEVICE_ID_NETGEAR_GA620T))) &&
/*
* Farallon used the DEC vendor ID on their cards by
* mistake for a while
@@ -480,7 +491,7 @@
pci_read_config_word(pdev, PCI_COMMAND, &ap->pci_command);
/* OpenFirmware on Mac's does not set this - DOH.. */
- if (!ap->pci_command & PCI_COMMAND_MEMORY) {
+ if (!(ap->pci_command & PCI_COMMAND_MEMORY)) {
printk(KERN_INFO "%s: Enabling PCI Memory Mapped "
"access - was not enabled by BIOS/Firmware\n",
dev->name);
@@ -597,7 +608,6 @@
}
-#ifdef MODULE
MODULE_AUTHOR("Jes Sorensen <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("AceNIC/3C985/GA620 Gigabit Ethernet driver");
MODULE_PARM(link, "1-" __MODULE_STRING(8) "i");
@@ -607,7 +617,6 @@
MODULE_PARM(rx_coal_tick, "1-" __MODULE_STRING(8) "i");
MODULE_PARM(max_rx_desc, "1-" __MODULE_STRING(8) "i");
-#endif
void __exit ace_module_cleanup(void)
{
@@ -1994,18 +2003,34 @@
if (txcsm != idx) {
do {
struct sk_buff *skb;
- dma_addr_t mapping;
skb = ap->skb->tx_skbuff[idx].skb;
- mapping = ap->skb->tx_skbuff[idx].mapping;
+ /*
+* Race condition between the code cleaning
+* the tx queue in the interrupt handler and the
+* interface close,
+*
+* This is a kludge that really should be fixed
+* by preventing the driver from generating a tx
+* interrupt when the packet has already been
+* removed from the tx queue.
+*
+* Nailed by Don Dugger and Chip Salzenberg of
+* VA Linux.
+*/
+ if (skb) {
+ dma_addr_t mapping;
- ap->stats.tx_packets++;
- ap->stats.tx_bytes += skb->len;
- pci_unmap_single(ap->pdev, mapping, skb->len,
-PCI_DMA_TODEVICE);
- dev_kfree_skb_irq(skb);
+ mapping = ap->skb->tx_skbuff[idx].mapping;
+
+ ap->stats.tx_packets++;
+ ap->stats.tx_bytes += skb->len;
+ p
Re: Still ext2-corruption in test8-pre5 (incl. OOPS)
On Wed, 6 Sep 2000, Chris Mason wrote:
>
> Ah, I was missing that __block_prepare_write and __block_write_fullpage
> both set the end_io handler to end_io_sync. In one case, reiserfs is doing
> i/o without properly setting the handler, which is why I was seeing bugs
> caused by the above problem, and ext2 wasn't.
We might actually want to get away from the default handler: it made sense
as we were gradually rewriting old code to conform to new rules, but these
days it's just dangerous when it can result in something like the above. I
_almost_ had the same bug in the truncate patch I sent out yesterday, and
I caught it only because I was thinking hard about it.
It migth be something as simple as doing a
static void uninitialized_bh_io_handler(struct buffer_head *bh, int uptodate)
{
printk("Uhhuh, bh without uninitialized end-io function\n");
/* ..but fall back on the old default after complaining */
end_buffer_io_async(bh, uptodate);
}
which will still _work_, but complain quite loudly if somebody just relies
on the old default hander..
Linus
-
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: Still ext2-corruption in test8-pre5 (incl. OOPS)
On Wed, 6 Sep 2000, Tim Waugh wrote: > On Tue, Sep 05, 2000 at 07:14:02PM -0700, Linus Torvalds wrote: > > > How about this patch? > > Got this oops. This one I cannot explain. It's a bh that is NULL, but it's a new case completely. It looks like you have a 1kB blocksize, no? It furthermore looks like the page only had two buffers on it, and accessing the fourth one blows up (accessing the third one gets NULL, which is why it only blows up on the fourth one). But it _has_ to have four buffers on it. Two buffers just aren't enough to cover a 4kB page. Uh. DUH! I found the bug. It shouldn't be "bh->b_next". That's just the next buffer on the hash chain. It should be "bh->b_this_page". Just change block_truncate_page() to use b_this_page instead of b_next. The "good news" is that me testing this would neve rhave found it, because all my filesystems are 4kB blocks, so the "next bh" case never triggers at all. Thanks, and THIS time it really is fixed. I mean, how many times can we get it wrong? At some point, we just have to run out of really bad ideas.. Linus - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Alan Cox wrote: > > As readability - it's definitely at least as readable as > > #if[def]. It also provides more consistent syntax. And when you are > > using ifdef to violate scoping - your code is in need of rewrite anyway. > > You still need the #ifdef stuff as well for half of it so I dont see what > it buys you I suspect that it will be way less than half, but there is only one way to check it... I'll try to do it, if it will not give visible benefits - too bad, I'll waste some time checking the wrong assumption... - 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: pagecache sysctl ignored?
On Wed, 6 Sep 2000, Rik van Riel wrote: > Nope. These magic numbers were added as a stopgap > measure when VM was completely fouled up in 2.1.89. ok, but at least do you agree that that tunable is unused and therefore can be thrown away? Or are you saying it is unused today but shall be used tomorrow? Regards, Tigran - 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: if (CONFIG_FOO) Re: 2.4.0-test8-pre1 is quite bad / how aboutintegrating Rik's VM
On Wed, 6 Sep 2000, Martin MaD Douda wrote: > Problem: every bloody line will go through the parser. There is too many > lines. Compilation is realy slow today. I'm affraid this approach would > make it worse. Note that 2.4.0-test7 has more than 2.75 milion lines. > Or did you mean drivers will be (optionally?) excluded from this > compile-it-all-and-then-optimize-it-away? Do you always compile all *.c files? Notice that it doesn't equate to ifdefs - e.g. if you have CONFIG_EXT2 undefined ext2 will not be compiled at all, but there is no instance of CONFIG_EXT2 anywhere in *.[ch]. As for reducing compile time, try to feed the current tree through cpp and see how much is included (and ignored) by preprocessor. I mean, just check how much do we actually include and how little do we really need... - 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: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Mike Jagdis wrote: > I disagree. No one here is dumb enough to use a wholely inappropriate > tool for a particular task. But using a debugger is often (but not > always) like sawing bits off your 2x4 until it happens to fit the > gap. What you need to do is to understand the problem parameters, > measure them, mark your 2x4, then cut using whatever tool is best > suited to the job. In woodwork the results tend to be superior :-) Yes, you've put your finger on it. When you take a power saw and try to use it like a chisel, it doesn't work very well. If you are philosophically opposed to power saws, you may pick one up, try to use it as a chisel, and then claim that it is a very poor tool. This is what is happening here. The proponents of the 'withhold the power tools' camp have fixated on the idea of using a debugger to chisel away at a problem. This is a poor way to use a debugger. Instead, use the debugger to cut a large problem space into small pieces - pieces that are too small for a bug to hide in. Use the debugger as a power saw, not as a chisel, and you will have more respect for its capabilities. -- Daniel - 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: Still ext2-corruption in test8-pre5 (incl. OOPS)
On Wed, 6 Sep 2000, Tim Waugh wrote: > On Tue, Sep 05, 2000 at 07:14:02PM -0700, Linus Torvalds wrote: > > > How about this patch? > > Got this oops. > Code; c012cae6<= >0: 8b 00 movl (%eax),%eax <= Offset 0 is ->b_next... Huh? It should be ->b_this_page, no? - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Richard Gooch wrote: > Jamie Lokier writes: > > Chris Wedgwood wrote: > > > I think would be really cool if all this 'magic' in gcc (whatever > > > part of gcc is irrelevant right now) would be exported into a library > > > or shared object which editors could then load and use... dynamically > > > perhaps. > > > > Sorry, there's a GCC policy decision against putting it into a > > shared library. > > Why? Not-so-wild guess: GPL issues, mixed with serious lack of enthisiasm about making the internal API frozen by exposure to library users. Besides, there is another issue: WTF is wrong with good old pipes? - 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: pagecache sysctl ignored?
On Wed, 6 Sep 2000, Tigran Aivazian wrote: > On Wed, 6 Sep 2000, Rik van Riel wrote: > > Nope. These magic numbers were added as a stopgap > > measure when VM was completely fouled up in 2.1.89. > > ok, but at least do you agree that that tunable is unused and > therefore can be thrown away? I can agree with that. regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - 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: acenic-v0.46 update
Jes,
I've been debugging a new acenic device for HP and have been using a
linux machine for bring up. One of the problems we encountered was a
need to change the cards MAC address. Under linux ia32, the driver set
an invalid MAC address. If I would
say
ifconfig eth0 hw ether 00:01:23:45:67:89 (for example only)
Linux would know of it's correct MAC address, but the card had a
different
address. Through reading of the MAC registers (offset 0xb80-0xbf0), the
card
thought it's MAC address was 01:00:45:23:89:67. Attached is a patch
that
would not do the halfword byte swapping.
Also, I have tested this device driver on a HP XU-800 Kayak (IA32) using
the HP 1000Base-T Lan Adapter A4929A device (copper), but it should also
work on the HP 1000Base-SX Lan Adapter A4926A (fiber). Both of these
devices are 64-bit PCI. I've not been able to test the A4924A or A4925A
because they are both on the (HP's) HSC bus.
These device specs can be found at:
A4926A -
http://www.unixsolutions.hp.com/products/networking/links/1000base.html
A4929A -
http://www.unixsolutions.hp.com/products/networking/links/gigetlpg.html
The attached patch is against version 0.46. I also have a device driver
that allows me to dump all the acenic registers. Let me know if you're
interested in a #define'd out patch.
-Stephen Hack
[EMAIL PROTECTED]
Jes Sorensen wrote:
>
> Hi
>
> Here is a patch for the acenic-v0.46 driver relative to whats in
> test8-pre4 - it solves a few bugs and cleans up a few minor issues in
> the code and comments.
>
> I have been unable to test this patch but looking over the changes I
> cannot see any reason why it would cause problems.
>
> Jes
>
diff -c drivers.old/net/acenic.c drivers/net/acenic.c
*** drivers.old/net/acenic.cTue Sep 5 13:21:11 2000
--- drivers/net/acenic.cWed Sep 6 09:52:25 2000
***
*** 35,40
--- 35,42
* Ken Aaker <[EMAIL PROTECTED]>: Correct check for whether
* memory mapped IO is enabled to
* make the driver work on RS/6000.
+ * Stephen Hack <[EMAIL PROTECTED]>: Fixed ace_set_mac_addr for little
+ * endian systems.
*/
#include
***
*** 2554,2560
{
struct sockaddr *addr=p;
struct ace_regs *regs;
! u16 *da;
struct cmd cmd;
if(netif_running(dev))
--- 2556,2562
{
struct sockaddr *addr=p;
struct ace_regs *regs;
! u8 *da;
struct cmd cmd;
if(netif_running(dev))
***
*** 2562,2572
memcpy(dev->dev_addr, addr->sa_data,dev->addr_len);
! da = (u16 *)dev->dev_addr;
regs = ((struct ace_private *)dev->priv)->regs;
! writel(da[0], ®s->MacAddrHi);
! writel((da[1] << 16) | da[2], ®s->MacAddrLo);
cmd.evt = C_SET_MAC_ADDR;
cmd.code = 0;
--- 2564,2574
memcpy(dev->dev_addr, addr->sa_data,dev->addr_len);
! da = (u8 *)dev->dev_addr;
regs = ((struct ace_private *)dev->priv)->regs;
! writel(da[0] << 8 | da[1], ®s->MacAddrHi);
! writel((da[2] << 24) | (da[3] << 16) | (da[4] << 8) | da[5] ,
®s->MacAddrLo);
cmd.evt = C_SET_MAC_ADDR;
cmd.code = 0;
begin:vcard
n:Hack;Stephen
tel;home:(970) 225-0820
tel;work:(970) 898-1545
x-mozilla-html:FALSE
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28608
fn:Stephen Hack
end:vcard
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro writes: > > > > On Wed, 6 Sep 2000, Richard Gooch wrote: > > > Jamie Lokier writes: > > > Chris Wedgwood wrote: > > > > I think would be really cool if all this 'magic' in gcc (whatever > > > > part of gcc is irrelevant right now) would be exported into a library > > > > or shared object which editors could then load and use... dynamically > > > > perhaps. > > > > > > Sorry, there's a GCC policy decision against putting it into a > > > shared library. > > > > Why? > > Not-so-wild guess: GPL issues, mixed with serious lack of enthisiasm about ^^ That was my guess. Politics. Ideology. Bah. > making the internal API frozen by exposure to library users. An exercise in decent API design. BFD. > Besides, there is another issue: WTF is wrong with good old pipes? In this context, I agree. It's not as if there's an awful lot of data being thrown around. Compilation costs are likely to dominate over in-core copies. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: [RFC] my current kernel todo list
On Mon, 4 Sep 2000, Tigran Aivazian wrote: > On Fri, 25 Aug 2000, Arnaldo Carvalho de Melo wrote: > > now the driver init sequence is not > > serialized anymore, so races are possible > > since when? In 2.4.0-test8-pre2 mod->init and mod->cleanup are called > under global kernel lock. As for static drivers they are initialised from > either start_kernel() or init()->do_basic_setup() both of which take > global kernel lock. > Ok, I understand this now - just cheched the cardbus/pcihotplug code. Ok, now if you do this, please leave out ne.c and hp100.c - I have the cards for these two so I can do it and test it myself. Regards, Tigran - 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-test7: PCMCIA misc rem
A reboot with 2.4.0-test7 (on i386 at least) doesn't properly "release" the card and hang the computer after displaying Linux PCMCIA options, just before YENTA IRQ is displayed no matter which kernel is then used to boot or segfault windows 98SE. Only way is to turn down computer. With the same machine (Dell Inspiron 7000) and card (D-Link DMF-560TXD) and a 2.3.99-pre9 (ie before the Linus reboot "improvement") everything was working fine. Going to sleep mode (APM, APIC not tested) and turning back on doesn't restore IP address with 2.4.0-test7 while it does using 2.3.99-pre9 Doing the following sequence with my D-Link DMF-560TXD (combo 56k/10/100Mb) block any sort of transmission through the modem (other sequence might lead to the same?!): - connect Internet with the modem - connect to an ethernet switch (link beat) - disconnect from the switch (unlink) reconnecting to the switch (new link beat) is then the only way of continuing sending/receiving through the modem (!This has not been tested yet with other kernel than the 2.4.0-test7) (For David) By upgrading my pcmcia-cs package, I noticed that cardmgr.c includes which by the cc option -I refers to the pcmcia/version.h from the kernel instead(?) of the one from the pcmcia-cs package /\/\arceric - 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: [RFC] my current kernel todo list
Em Wed, Sep 06, 2000 at 05:37:50PM +0100, Tigran Aivazian escreveu:
> On Mon, 4 Sep 2000, Tigran Aivazian wrote:
>
> > On Fri, 25 Aug 2000, Arnaldo Carvalho de Melo wrote:
> > > now the driver init sequence is not
> > > serialized anymore, so races are possible
> >
> > since when? In 2.4.0-test8-pre2 mod->init and mod->cleanup are called
> > under global kernel lock. As for static drivers they are initialised from
> > either start_kernel() or init()->do_basic_setup() both of which take
> > global kernel lock.
> >
>
> Ok, I understand this now - just cheched the cardbus/pcihotplug code.
>
> Ok, now if you do this, please leave out ne.c and hp100.c - I have the
> cards for these two so I can do it and test it myself.
humm, In fact I've already sent a patch to Paul Gortmaker only, asking
for feedback about the PCI case (that I think should be removed from it,
as ne2k-pci already has this), here it is, maybe it'll help you in the
process.
--- linux-2.4.0-test8-pre1/drivers/net/ne.c Sat Jul 8 23:38:16 2000
+++ linux-2.4.0-test8-pre1.acme/drivers/net/ne.cFri Sep 1 20:13:37 2000
@@ -18,6 +18,7 @@
Changelog:
+Arnaldo Melo : get rid of check_region
Paul Gortmaker : use ENISR_RDC to monitor Tx PIO uploads, made
sanity checks and bad clone support optional.
Paul Gortmaker : new reset code, reset card after probe at boot.
@@ -211,8 +212,7 @@
/* Last resort. The semi-risky ISA auto-probe. */
for (base_addr = 0; netcard_portlist[base_addr] != 0; base_addr++) {
int ioaddr = netcard_portlist[base_addr];
- if (check_region(ioaddr, NE_IO_EXTENT))
- continue;
+
if (ne_probe1(dev, ioaddr) == 0)
return 0;
}
@@ -328,13 +328,6 @@
}
}
- /* We should have a "dev" from Space.c or the static module table. */
- if (dev == NULL)
- {
- printk(KERN_ERR "ne.c: Passed a NULL device.\n");
- dev = init_etherdev(0, 0);
- }
-
if (ei_debug && version_printed++ == 0)
printk(version);
@@ -473,6 +466,9 @@
#endif
}
+ if (!request_region(ioaddr, NE_IO_EXTENT, name))
+ return -EBUSY;
+
if (pci_irq_line)
dev->irq = pci_irq_line;
@@ -519,7 +515,6 @@
}
}
dev->base_addr = ioaddr;
- request_region(ioaddr, NE_IO_EXTENT, name);
for(i = 0; i < ETHER_ADDR_LEN; i++) {
printk(" %2.2x", SA_prom[i]);
-
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: linux-2.4.0-test8-pre5
Also sprach Dan Aloni: } On Wed, 6 Sep 2000, Peter Samuelson wrote: } } > Can someone explain this line from the VIA update? } > #define FIT(v,min,max) (((v)>(max)?(max):(v))<(min)?(min):(v)) } > Barring side effects on the variables, it is equivalent to } > #define FIT(v,min,max) ((v)<(min)?(min):(v)) } > } > Why do I get the feeling that this was *not* the intent? } } Correct. The last v should be replaced with whatever that we got from } (v)>(max)?(max):(v), like: } } #define FIT(v,min,max) (((v)>(max)?(max):(v))<(min)?(min):((v)>(max)?(max):(v))) } } Or perhaps this is a lot better: } } #define FIT(v,min,max) ((v)>(max)?(max):((v)<(min)?(min):(v))) } *pukes* Wouldn't an inline'd function be much much more readable/maintainable?? -- || Bill Wendling[EMAIL PROTECTED] - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
In article <[EMAIL PROTECTED]>, Andrew Morton <[EMAIL PROTECTED]> wrote: > >But still, doing the conditional compilation at compile-time rather than >preprocessing-time is so *nice* that if you don't have too many literal >strings floating about it may be justifiable. > >In cs89x0.c you reduce the object size by 1.5k by setting DEBUGGING to >literal zero - no #ifdefs in sight. Yes. The i387.c thing uses this too to make for much more readable code (instead of using CONFIG_MATH_EMULATION etc, it uses it's own #defines and variables, and lets the compiler sort it all out). It definitely has many advantages, especially in that it allows real C flow and thus much nicer syntax. And a lot of code becomes much nicer if instead of having #ifdef CONFIG_FOO do_this_thing(); #endif you have an unconditional do_this_thing(); and you just define that to possibly end up being zero code for the cases you don't care about - even if you use the pre-processor for that phase. I basically always prefer that kind of syntax. At the same time, there is no question that true #ifdef's have advantages, even outside the issue of gcc's inability to forget literal strings. They are often required for data structures in general: C does not have "conditional data structures". Certain fields just do not exist when SMP is disabled, for example. And we don't _want_ them to exist, because they bloat out data structures that we're trying to keep reasonably small. So I disagree with the notion that we should try to avoid using #ifdefs etc completely. But I agree that in many cases you can _locally_ try to avoid it, resulting in nicer and more flexible code that also has the advantage of making sure it can be parsed regardless of what the configuration is. Linus - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
In article <[EMAIL PROTECTED]>, Jamie Lokier <[EMAIL PROTECTED]> wrote: >Linus Torvalds wrote: >> And I'm saying that if people really want to do this, then use the >> computer to do it for you, having more than just "grep", and making your >> tools aware of it. > >I'd just like to add, for the benefit of onlookers, that this is >quite easy. > >Temporarily change name of `count' in struct page in your private tree; >recompile. Voila! Every occurence of page->count will show as a >compile error, with line number. Yes. This is, in fact, how a lot of these things have been done. Often the name-change isn't even just temporary - it stays, because that way nobody will be able to compile old code that depends on old conventions even by mistake. However, what I think Al Viro dislikes about this is that it does tend to leave code that won't compile, just because some of the accesses are in places that the compiler doesn't see due to the pre-processor (or due to other build-rules: like in architectures that aren't the one that the developer uses). That said, it works. This is also the reason why I want the kernel to use as tight type-checking as C allows: because it again allows people to change things _without_ having to be perfectly aware of every single detail that depends on the old calling sequences, as the compiler will warn if the types are mis-used. Linus - 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/
Race condition in 2.2.15 and 2.2.16
There is a race condition somewhere in linux-2.2.15 and 2.2.16 that is demonstrated here. Cut and save the included 'Makefile'. Execute: mkdir zam mv Makefile zam cd zam Make sure you are in the empty directory with only "Makefile" Execute: while true ; do make clean ; done The file, Makefile, will be deleted. A zero-length one will sometimes remain in /tmp - Makefile --- # # Warning!! Put this in an EMPTY subdirectory. # all:foo foo: touch foo clean: mv Makefile /tmp rm -r * mv /tmp/Makefile . - Now I know that you don't DO things like this. Please, this is a demonstration, specifically designed to show a problem that sometimes occurs in much more subtle ways. This problem can result in missing source-code files in large directory trees after working on them for 8-10 solid hours. NotGood(tm). Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
In article <8p5u21$r0$[EMAIL PROTECTED]> you wrote: > However, what I think Al Viro dislikes about this is that it does tend > to leave code that won't compile, just because some of the accesses are > in places that the compiler doesn't see due to the pre-processor (or due > to other build-rules: like in architectures that aren't the one that the > developer uses). That's why there are people that try to built all possible combinations of .config options. Granted, that doesn't happen for non-i386 yet, but that is just a matter of available hardware :) Greetings, Arjan van de Ven - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
We could use some more infrastructure here. (1) A 'make randomconfig' tool that generates a random configuration. (2) Make the architecture a configuration variable (!) (3) A collection of RPM's so that people can download and install all the cross tools easily. With this stuff available, I would spend my idle cycles building random kernels and catching the syntax errors. Michael - 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: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for
Isn't it time to offer the platitude about working smarter rather than harder? Nah, probably not. Marty -Original Message- From: Alan Cox [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 06, 2000 2:20 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for >Attempting to change people's habits by making it hard to debug. > > Hard work now leads to less work later. Hard work now leads to less work full stop - 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/ - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On 6 Sep 2000, Linus Torvalds wrote: > At the same time, there is no question that true #ifdef's have > advantages, even outside the issue of gcc's inability to forget literal > strings. They are often required for data structures in general: C does > not have "conditional data structures". Certain fields just do not > exist when SMP is disabled, for example. And we don't _want_ them to > exist, because they bloat out data structures that we're trying to keep > reasonably small. True. But right now we have a heap of CONFIG_FOO and that heap falls into three parts: 1) stuff that is not used in *.[chS]. At all. CONFIG_EXT2, for one. Makefiles - yes, but that's basically "what we link" kind of influence. 2) stuff that _is_ used, but doesn't really have to be #ifdefs 3) tiny group of options that really have to affect the compile in non-trivial ways. CONFIG_SMP is an obvious example. CONFIG_PROC_FS _may_ be another, simply due to the amount of instances in the current code. Architecture is probably one more (even though we could do nicer here). There may be several other (some networking-related ones may be candidates). IWBNI they would be clearly separated and #2 would shrink (some of these guys should be in #1). > So I disagree with the notion that we should try to avoid using #ifdefs > etc completely. But I agree that in many cases you can _locally_ try to > avoid it, resulting in nicer and more flexible code that also has the > advantage of making sure it can be parsed regardless of what the > configuration is. Oh, we certainly can't completely avoid ifdefs without major braindamage. But there is a difference between several hundreds of options and a dozen that decides what would be seen by parser. And even essential ones are, in many cases, used in uglier ways than they have to. - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote: > We could use some more infrastructure here. > > (1) A 'make randomconfig' tool that generates a random configuration. > > (2) Make the architecture a configuration variable (!) > > (3) A collection of RPM's so that people can download and install > all the cross tools easily. (0) knowledge that CONFIG_FOO15 doesn't affect anything other than set of source files being compiled. Providing better tools is nice, but simplifying the problem domain sometimes pays better... - 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/
WinTV problem (Was: Re: [ANNOUNCE] Withdrawl of Open Source NDS
On Wed, 6 Sep 2000, mberglund wrote: > Recently I purchased a PPC 7200. It is a beat up old mac that I could pick > up cheap. I have used intels since I was a boy (SysV3.3 on 386!) and saw > some characteristics of the mac that were lacking in the intel boxes. > > Finally, I tried to use the box to do some video grabbing only to find > that the 2.2, 2.3, and 2.4 kernel all failed. I Attempted to read the > code, and use kdb, only it doesn't appear to work on the mac very > well. And I don't have a mac serial to 9/25-pin adapter. So I have to go > to Orlando to get one. This is a two hour drive for me, and not worth my > time, thus gdb is out of the question. I have sent some questions out to > that community and they have been unresponsive on this one (I guess no one > uses the happauge wintv on those boxes). I remember reading a problem report in linuxppc-user mailing list. If that was you, I'd say you are asking a wrong list. Only very few PPC kernel developers read messages from that list as far as I know. I'd think linuxppc-dev for PPC specific problem and video4linux mailing list for wintv specific problem would have been more appropriate. Anyhow, since your card probably lacks Mac-compatible bios, make sure that PCI memory and/or io accesses are enabled for your card. For pmac/chrp(/prep?) variant of PPC platform, a (very localized) low-level kernel debugger called xmon is included with the source tree. So, if you absolutely need one, it's there. Takashi Oe - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote: > > We could use some more infrastructure here. > > (1) A 'make randomconfig' tool that generates a random configuration. There already are people that do this. The problem is that developers are lazy. All good programmers are lazy. They want to fix the problem - they don't want to wait for a day or two until all combinations have been tested. They want a "grep"-like thing. Not that it matters much. In the end, non-compiling kernel versions are quite acceptable as they fix bugs and they'll get fixed themselves eventually. So this is not probably that big of an issue in real life. Just a beauty wart. > (2) Make the architecture a configuration variable (!) Why? You still need to have all the damn cross-compilers etc. At which point being a configuration variable is the _least_ of your worries. You're better off with just a new tree. > (3) A collection of RPM's so that people can download and install > all the cross tools easily. Hey, maybe you have a few 18GB disks lying around, but none of the machines I use every day could afford to have another 5-6 cross- compilation environments lying around. It's just not practical. Linus - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On 6 Sep 2000, Linus Torvalds wrote: > However, what I think Al Viro dislikes about this is that it does tend > to leave code that won't compile, just because some of the accesses are > in places that the compiler doesn't see due to the pre-processor (or due > to other build-rules: like in architectures that aren't the one that the > developer uses). Add "and that broken code gets fixed in utterly bogus ways 20 versions down the road, when nobody remembers WTF had happened". Repeat several times (and rarely-used parts _will_ accumulate such crap) and you've got Lovecraftian beasts lurking in the tree. To some extent it's inevitable, but frequency of such events matters... - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
r > (0) knowledge that CONFIG.FOO15 doesn't affect anything other than set of > source files being compiled. The Makefiles already know this. Specifically, mkdep.c analyzes which C files depend on which options. Look at some of your .depend files. Michael - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Linus writes ... mec> (2) Make the architecture a configuration variable (!) linus> Why? The real reason is that it's the right thing to do. Part of a configuration is "what machine it's for". Here are some benefits: (a) Arjan's testing machinery would catch problems in all architectures, not just the x86. (b> The sparc / sparc64 people can manage their builds a lot easier. (c) With separate source and build trees, which I've implemented, it becomes a lot more feaasible to manage kernel builds for multiple platforms. > Hey, maybe you have a few 18GB disks lying around, but none of the > machines I use every day could afford to have another 5-6 cross- > compilation environments lying around. It's just not practical. So don't do it. You build with your favorite configuration, and I'll build with my favorite 100 configurations. Michael - 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/
SCSI cdrom is broken in 2.4.0-test8-pre5
It appears that SCSI cdroms as modules are broken in 2.4.0-test8. It works fine 2.4.0-test7. cat /dev/scd0 cat: /dev/scd0: No such device Module Size Used by isofs 20168 0 (autoclean) sg 21712 0 (unused) sr_mod 13224 0 (autoclean) (unused) cdrom 26780 0 (autoclean) [sr_mod] nls_iso8859-1 2872 0 (autoclean) vfat 10668 0 (autoclean) fat30944 0 (autoclean) [vfat] agpgart14564 2 (autoclean) ipx13452 2 (autoclean) emu10k143384 0 soundcore 3748 4 [emu10k1] ipchains 32996 0 (unused) 3c59x 22664 1 the-penguin:/usr/src/linux/scripts# sh ver_linux -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux the-penguin 2.4.0-test8 #3 Tue Sep 5 16:27:14 PDT 2000 i686 unknown Kernel modules 2.3.14 Gnu C 2.95.2 Binutils 2.10.0.24 Linux C Library2.1.3 Dynamic linker ldd: version 1.9.11 Procps 2.0.6 Mount 2.10o Net-tools 2.05 Console-tools 0.2.3 Sh-utils 2.0i Modules Loaded isofs sg sr_mod cdrom nls_iso8859-1 vfat fat agpgart ipx emu10k1 soundcore ipchains 3c59x # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_M686FXSR is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PM=y CONFIG_ACPI=y # CONFIG_ACPI_INTERPRETER is not set # CONFIG_ACPI_S1_SLEEP is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_LVM=m CONFIG_LVM_PROC_FS=y # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 # CONFIG_BLK_DEV_INITRD is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set CONFIG_INET_ECN=y CONFIG_SYN_COOKIES=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_UNCLEAN=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_MIRROR=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_COMPAT_IPCHAINS=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_COMPAT_IPFWADM=m CONFI
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: > > On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote: > > > We could use some more infrastructure here. > > > > (1) A 'make randomconfig' tool that generates a random configuration. > > > > (2) Make the architecture a configuration variable (!) > > > > (3) A collection of RPM's so that people can download and install > > all the cross tools easily. > > (0) knowledge that CONFIG_FOO15 doesn't affect anything other than set of > source files being compiled. > > Providing better tools is nice, but simplifying the problem domain > sometimes pays better... So may I just suggest to repleace the usage of cpp at all with something more suitable for the task at hand and with a much more regular/stringent syntax better fitting into the syntax of the pure C language like m4 for example? I think Java has the perfect solution for conditional compilation - don't make it possible at al in a sane standard way! Coditional compilation is evil like gotos (despite the fact that even every pascal implementation out there provided them). The main problem with the CONFIG_ blah's isn't either the syntax nor they current usage - the problem is inherent to the simple fact that the number of possible combinations is of a very high order due to simple combinatorics. Hmm maybe the first irony is a quite serious suggestion at least in the case of CONFIG_ options? - 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: SCSI cdrom is broken in 2.4.0-test8-pre5
On Wed, Sep 06 2000, Lawrence Walton wrote:
> It appears that SCSI cdroms as modules are broken in 2.4.0-test8.
> It works fine 2.4.0-test7.
>
>
> cat /dev/scd0
> cat: /dev/scd0: No such device
Yup, apparently I was a bit too trigger happy.
--
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
--- /opt/kernel/linux-2.4.0-test8-pre5/drivers/scsi/sr.cWed Sep 6 02:34:30
2000
+++ drivers/scsi/sr.c Wed Sep 6 20:07:28 2000
@@ -848,9 +848,10 @@
return;
}
+#ifdef MODULE
int init_sr(void)
{
- sr_template.module = THIS_MODULE;
+ sr_template.module = &__this_module;
return scsi_register_module(MODULE_SCSI_DEV, &sr_template);
}
@@ -877,6 +878,7 @@
sr_template.dev_max = 0;
}
+#endif
module_init(init_sr);
module_exit(exit_sr);
Availability of kdb
Mike Galbraith wrote: > > On Wed, 6 Sep 2000, Damien Miller wrote: > > > Tools like a KDB would make the kernel a lot more accessible to the > > time-poor. > > Kdb is available to all. I think it should be _integrated_ mostly > because of the (potential) improvement in bug report quality. Well, yes and no. As maintained by SGI, kdb is up to date: ftp://oss.sgi.com/www/projects/kdb/download/ix86/kdb-v1.3-2.4.0-test8-pre4.gz As maintained in the official ikd package, kdb is unusuably out of date, at least for me: ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/ikd/v2.4/2.4.0-test2-ikd2.bz2 Q: If kdb were a kernel option, would the official version be out of date, the way it is now? A: no. Q: If kdb were a kernel option, would Linus be called on to fix it when it breaks? A: no, obviously not, Linus is too busy Q: Who would fix it then? A: Whoever breaks it. Q: What if Linus breaks it? A: That's a special case. I personally will drop whatever I'm doing and try to fix it. I will cordially invite J. Dow, J. Merkey, R. Gootch, and various other degenerate powertool lovers to help. Q: Would kdb in the kernel result in more bugs getting fixed faster? A: Yes, no doubt Q: Do we need more bugs fixed faster? A: Yes, we need that desperately. Q: Would kdb in the kernel give us more eyes on the bugs, making them even shallower than they already are? A: Why, yes it would. Q: Will kdb make your kernel bigger or slow it down? A: Not if you don't use it. Q: Is kdb a big patch? A: It's only 93K, zipped. Q: Then why isn't kdb in the kernel? A: Uh... -- Daniel "With enough Q's and A's, all arguments are shallow" - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Alexander Viro wrote:
>
>
> On 6 Sep 2000, Linus Torvalds wrote:
>
> > However, what I think Al Viro dislikes about this is that it does tend
> > to leave code that won't compile, just because some of the accesses are
> > in places that the compiler doesn't see due to the pre-processor (or due
> > to other build-rules: like in architectures that aren't the one that the
> > developer uses).
>
> Add "and that broken code gets fixed in utterly bogus ways 20 versions
> down the road, when nobody remembers WTF had happened". Repeat several
> times (and rarely-used parts _will_ accumulate such crap) and you've got
> Lovecraftian beasts lurking in the tree. To some extent it's inevitable,
> but frequency of such events matters...
... or they get #if 0'd, as in the case below:
diff -urN rc8-5/arch/mips64/kernel/linux32.c rc8-5-mips/arch/mips64/kernel/linux32.c
--- rc8-5/arch/mips64/kernel/linux32.c Thu Jul 27 21:36:54 2000
+++ rc8-5-mips/arch/mips64/kernel/linux32.c Wed Sep 6 13:59:36 2000
@@ -275,30 +275,33 @@
int do_execve32(char * filename, u32 * argv, u32 * envp, struct pt_regs * regs)
{
struct linux_binprm bprm;
- struct dentry * dentry;
+ struct file *file;
int retval;
int i;
- bprm.p = PAGE_SIZE*MAX_ARG_PAGES-sizeof(void *);
- memset(bprm.page, 0, MAX_ARG_PAGES*sizeof(bprm.page[0]));
+ file = open_exec(filename);
- dentry = open_namei(filename, 0, 0);
- retval = PTR_ERR(dentry);
- if (IS_ERR(dentry))
+ retval = PTR_ERR(file);
+ if (IS_ERR(file))
return retval;
- bprm.dentry = dentry;
+ bprm.p = PAGE_SIZE*MAX_ARG_PAGES-sizeof(void *);
+ memset(bprm.page, 0, MAX_ARG_PAGES*sizeof(bprm.page[0]));
+
+ bprm.file = file;
bprm.filename = filename;
bprm.sh_bang = 0;
bprm.loader = 0;
bprm.exec = 0;
if ((bprm.argc = count32(argv, bprm.p / sizeof(u32))) < 0) {
- dput(dentry);
+ allow_write_access(file);
+ fput(file);
return bprm.argc;
}
if ((bprm.envc = count32(envp, bprm.p / sizeof(u32))) < 0) {
- dput(dentry);
+ allow_write_access(file);
+ fput(file);
return bprm.envc;
}
@@ -326,8 +329,9 @@
out:
/* Something went wrong, return the inode and free the argument pages*/
- if (bprm.dentry)
- dput(bprm.dentry);
+ allow_write_access(bprm.file);
+ if (bprm.file)
+ fput(bprm.file);
/* Assumes that free_page() can take a NULL argument. */
/* I hope this is ok for all architectures */
I suspect that after that patch #if 0 around the whole mess may go to
hell. Ralf?
Notice that in this case code simply was not available in the tree when
changes were done. Right now I've just repeated the grep done back in May
and it brought the instances above. Folks, it didn't compile for 4
months...
-
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: Availability of kdb
I agree completely. I'd love to see it there. I'd even help break^W fix it. ~Randy ___ |Randy Dunlap Intel Corp., DALSr. SW Engr.| |randy.dunlap.at.intel.com503-696-2055| |NOTE: Any views presented here are mine alone | |and may not represent the views of my employer. | |_| > -Original Message- > From: Daniel Phillips > [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, September 06, 2000 11:12 AM > To: Mike Galbraith; [EMAIL PROTECTED] > Subject: Availability of kdb > > > Mike Galbraith wrote: > > > > On Wed, 6 Sep 2000, Damien Miller wrote: > > > > > Tools like a KDB would make the kernel a lot more > accessible to the > > > time-poor. > > > > Kdb is available to all. I think it should be _integrated_ mostly > > because of the (potential) improvement in bug report quality. > > Well, yes and no. As maintained by SGI, kdb is up to date: > ftp://oss.sgi.com/www/projects/kdb/download/ix86/kdb-v1.3-2.4. > 0-test8-pre4.gz > > As maintained in the official ikd package, kdb is unusuably out of > date, at least for me: > ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/ikd/v2.4/2 .4.0-test2-ikd2.bz2 Q: If kdb were a kernel option, would the official version be out of date, the way it is now? A: no. Q: If kdb were a kernel option, would Linus be called on to fix it when it breaks? A: no, obviously not, Linus is too busy Q: Who would fix it then? A: Whoever breaks it. Q: What if Linus breaks it? A: That's a special case. I personally will drop whatever I'm doing and try to fix it. I will cordially invite J. Dow, J. Merkey, R. Gootch, and various other degenerate powertool lovers to help. Q: Would kdb in the kernel result in more bugs getting fixed faster? A: Yes, no doubt Q: Do we need more bugs fixed faster? A: Yes, we need that desperately. Q: Would kdb in the kernel give us more eyes on the bugs, making them even shallower than they already are? A: Why, yes it would. Q: Will kdb make your kernel bigger or slow it down? A: Not if you don't use it. Q: Is kdb a big patch? A: It's only 93K, zipped. Q: Then why isn't kdb in the kernel? A: Uh... -- Daniel - 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: SCSI cdrom is broken in 2.4.0-test8-pre5
On Wed, Sep 06 2000, Jens Axboe wrote:
> > It appears that SCSI cdroms as modules are broken in 2.4.0-test8.
> > It works fine 2.4.0-test7.
Bah, try this one instead...
--
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
--- /opt/kernel/linux-2.4.0-test8-pre5/drivers/scsi/sr.cWed Sep 6 02:34:30
2000
+++ drivers/scsi/sr.c Wed Sep 6 20:19:52 2000
@@ -848,9 +848,10 @@
return;
}
+#ifdef MODULE
int init_sr(void)
{
- sr_template.module = THIS_MODULE;
+ sr_template.module = &__this_module;
return scsi_register_module(MODULE_SCSI_DEV, &sr_template);
}
@@ -880,3 +881,4 @@
module_init(init_sr);
module_exit(exit_sr);
+#endif
Re: Availability of kdb
Daniel, very nice monologue, thanks. It would be great to know Linus' opinion. I mean, I knew Linus' opinion of some years' ago but perhaps it changed? He is a living being and not some set of rules written in stone so perhaps current stability/highquality of kdb suggests to Linus that it may be (just maybe) acceptable into official tree? (hence I cc'd Linus, please forgive me (Linus) if you don't want to hear about kdb again) Regards, Tigran On Wed, 6 Sep 2000, Daniel Phillips wrote: > Mike Galbraith wrote: > > > > On Wed, 6 Sep 2000, Damien Miller wrote: > > > > > Tools like a KDB would make the kernel a lot more accessible to the > > > time-poor. > > > > Kdb is available to all. I think it should be _integrated_ mostly > > because of the (potential) improvement in bug report quality. > > Well, yes and no. As maintained by SGI, kdb is up to date: > ftp://oss.sgi.com/www/projects/kdb/download/ix86/kdb-v1.3-2.4.0-test8-pre4.gz > > As maintained in the official ikd package, kdb is unusuably out of > date, at least for me: > ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/ikd/v2.4/2.4.0-test2-ikd2.bz2 > > Q: If kdb were a kernel option, would the official version be out of >date, the way it is now? > A: no. > > Q: If kdb were a kernel option, would Linus be called on to fix it >when it breaks? > A: no, obviously not, Linus is too busy > > Q: Who would fix it then? > A: Whoever breaks it. > > Q: What if Linus breaks it? > A: That's a special case. I personally will drop whatever I'm doing >and try to fix it. I will cordially invite J. Dow, J. Merkey, R. >Gootch, and various other degenerate powertool lovers to help. > > Q: Would kdb in the kernel result in more bugs getting fixed faster? > A: Yes, no doubt > > Q: Do we need more bugs fixed faster? > A: Yes, we need that desperately. > > Q: Would kdb in the kernel give us more eyes on the bugs, making them >even shallower than they already are? > A: Why, yes it would. > > Q: Will kdb make your kernel bigger or slow it down? > A: Not if you don't use it. > > Q: Is kdb a big patch? > A: It's only 93K, zipped. > > Q: Then why isn't kdb in the kernel? > A: Uh... > > -- > Daniel > > "With enough Q's and A's, all arguments are shallow" > - > 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/ > - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Martin Dalecki wrote: > > So may I just suggest to repleace the usage of cpp at all with something > more > suitable for the task at hand and with a much more regular/stringent > syntax > better fitting into the syntax of the pure C language like m4 for > example? > No. Still "better tools" variant. Check blk_dev_init() and tell me how do you like the end of this function (drivers/block/ll_rw_blk.c). BTW, check how many of these CONFIG_... are needed anywhere on C level. Hint: see module_init macro. > > I think Java has the perfect solution for conditional compilation - > don't > make it possible at al in a sane standard way! Coditional compilation is > evil > like gotos (despite the fact that even every pascal implementation out > there > provided them). > > > The main problem with the CONFIG_ blah's isn't either the syntax nor > they current usage - the problem is inherent to the simple fact > that the number of possible combinations is of a very high order due > to simple combinatorics. It's not a fact, it's a problem... It doesn't _have_ to be very high order on cc level. ld - sure, but that's much simpler to deal with. - 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: zero-copy TCP
Alan Cox wrote: > I've spent over 2 years trying to extract eepro100 server docs out of Intel > and failed. Sounds familiar :-) According to group legend here (I wasn't around but will repeat what I was told), we spent about 1 year trying to get docs on Intel's i960 based gigabit card so we could program it. Eventually we gave up and moved to Alteon, who are very helpful. -- Jamie - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Alexander Viro wrote: > > Add "and that broken code gets fixed in utterly bogus ways 20 versions > down the road, when nobody remembers WTF had happened". Repeat several > times (and rarely-used parts _will_ accumulate such crap) and you've got > Lovecraftian beasts lurking in the tree. "Lovecraftian beasts". I like it. To some degree that also ends up showing that not many people seem to care about that particular beast. In the end, it might be phased out altogether - something that _has_ happened, exactly for these kinds of reasons. Who still remembers xiafs? We have 33 different filesystems in the kernel tree - something that is quite impressive, and something that I don't think anybody else has ever tried to support. But we could have had 34.. Linus - 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: 2.4.0-test8-pre1 is quite bad / Kernel build tools
In article <[EMAIL PROTECTED]> you wrote: > Linus writes ... > mec> (2) Make the architecture a configuration variable (!) > linus> Why? > The real reason is that it's the right thing to do. Part of a > configuration is "what machine it's for". > Here are some benefits: > (a) Arjan's testing machinery would catch problems in all architectures, > not just the x86. This is technically not true. I can cross-compile with my tools just fine, it "just" requires a decent cross-compiler on my system[1] [2]. Greetings, Arjan van de Ven [1] I do have a 18Gb disk available for it [2] Or someone should get me access on a - 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: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: > > On Wed, 6 Sep 2000, Martin Dalecki wrote: > > > > > So may I just suggest to repleace the usage of cpp at all with something > > more > > suitable for the task at hand and with a much more regular/stringent > > syntax > > better fitting into the syntax of the pure C language like m4 for > > example? > > > > No. Still "better tools" variant. Check blk_dev_init() and tell me how do > you like the end of this function (drivers/block/ll_rw_blk.c). BTW, check Yes you are right here I don't like this particular piece of code in esp since: 1. The macro hackery may very well be replaced with "vanishing macros" at the declaration level. 2. This is basically an fully unrolled loop of calls into a function pointer table. 3. It's making the corresponding driver code non self contained. > how many of these CONFIG_... are needed anywhere on C level. Hint: see > module_init macro. Yes I like the introduction of the ld hackere there very much: It's basically solving the problems 1. 2. and 3. by doing the proper thing ;-) i.e. provide an statically initialized list of addresses and call them out of a loop. > > The main problem with the CONFIG_ blah's isn't either the syntax nor > > they current usage - the problem is inherent to the simple fact > > that the number of possible combinations is of a very high order due > > to simple combinatorics. > > It's not a fact, it's a problem... It doesn't _have_ to be very high > order on cc level. ld - sure, but that's much simpler to deal with. But in some cases the driver api in linux are not quite supportiv for this. Please have a look at the strattegy routine (please allow me to use the proper UNIX terminology here ;-) declaration hackery inside of ide.h, oh sorry it gote moved and I can't quite find it again... ;-) - 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: zero-copy TCP
Alan Cox wrote: > I've spent over 2 years trying to extract eepro100 server docs out of Intel > and failed. [EMAIL PROTECTED] said: > Sounds familiar :-) Very familiar. I have a whole development environment for the i960RP (we use the processor on boards we make) and by looking at pictures I was able to figure out that it uses a standard PCI ethernet chipset on the secondary bus. I asked Intel, and no one said I could not have the information I wanted, I just got passed around until I got bored. All I needed out of Intel was a memory map (there was a PLD that I presume does address decoding) and a few hints how the prom monitor worked. If anybody has that stuff, I have a GPL development environment, built around gcc, that I can quickly (days?) port to the board, as I have considerable experience with the i960RP/RD processors. *sigh* It's pointless, isn't it? -- Steve Williams"The woods are lovely, dark and deep. [EMAIL PROTECTED] But I have promises to keep, [EMAIL PROTECTED]and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." - 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/
modules directory
Hi, Just installed linux-2.4.0-test7, but I noticed that the modules get installed /lib/modules/`uname -r`/kernel/drivers/... which is different from previous kernels. Do I need to modify modules path in conf.modules in order that the modules can be found during boot? or is there an updated modutils that'll search that path? Thanks Andrew Park - 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-test7/driver/sbus/char/vfc_dev.c
Hello! I'm just trying to compile a kernel for my sparc and found a bug in the above file: In line 170: dev->de = devfs_register (devfs_handle, devname, DEVFS_FL_DEFAULT, VFC_MAJOR, instance, S_IFCHR | S_IRUSR | S_IWUSR, &vfc_fops, NULL); the call needs static struct file_operations vfc_fops; which is not defined until line 642. A forward declaration at the beginning fixes the problem: --- linux/drivers/sbus/char/vfc_dev.c.orig Mon Sep 4 20:36:04 2000 +++ linux/drivers/sbus/char/vfc_dev.c Mon Sep 4 20:31:28 2000 @@ -42,6 +42,7 @@ #include "vfc.h" #include +static struct file_operations vfc_fops; static devfs_handle_t devfs_handle = NULL; /* For the directory */ struct vfc_dev **vfc_dev_lst; static char vfcstr[]="vfc"; The mentioned author can't be reached anymore so I'm sending this directly to this list. Philipp -- / / (_)__ __ __ Philipp Hahn / /__/ / _ \/ // /\ \/ / //_/_//_/\_,_/ /_/\_\ [EMAIL PROTECTED] - 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] sr.c 2.4.0-test8-pre5 breakage
* Jens Axboe <[EMAIL PROTECTED]> [000906 06:32]: > On Wed, Sep 06 2000, Arnaldo Carvalho de Melo wrote: > > Em Wed, Sep 06, 2000 at 02:42:02AM -0700, Joshua Uziel escreveu: > > > Heya acme... seems you fixed the sr.c driver a bit too much and > > > killed an #ifdef MODULE that was needed if you build without > > > > Nope, I didn't touched this, Jens? > > Yeah, this is my booboo not Arnaldo's. Cool... at least you guys know now... acme - I thought it was you because I saw the change occur with your comment at the top (and it seemed like cleanup). :) - 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: [RFC] my current kernel todo list
On Wed, 6 Sep 2000, Arnaldo Carvalho de Melo wrote: > Em Wed, Sep 06, 2000 at 05:37:50PM +0100, Tigran Aivazian escreveu: > > On Mon, 4 Sep 2000, Tigran Aivazian wrote: > > > > > On Fri, 25 Aug 2000, Arnaldo Carvalho de Melo wrote: > > > > now the driver init sequence is not > > > > serialized anymore, so races are possible > > > > > > since when? In 2.4.0-test8-pre2 mod->init and mod->cleanup are called > > > under global kernel lock. As for static drivers they are initialised from > > > either start_kernel() or init()->do_basic_setup() both of which take > > > global kernel lock. > > > > > > > Ok, I understand this now - just cheched the cardbus/pcihotplug code. > > > > Ok, now if you do this, please leave out ne.c and hp100.c - I have the > > cards for these two so I can do it and test it myself. > > humm, In fact I've already sent a patch to Paul Gortmaker only, asking > for feedback about the PCI case (that I think should be removed from it, > as ne2k-pci already has this), here it is, maybe it'll help you in the > process. excellent idea (about removing PCI code from ne.c) - what did Paul say? Also, omit pcnet32.c from your list as I have it too (well, vmware virtual one) so I'll do it as well. Regards, Tigran - 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/
