Re: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
John Levon wrote:
>
> On Wed, 6 Sep 2000, George Anzinger wrote:
>
> > 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
> >
>
> So it seems to be a bug at least in terms of timing. Unfortunately I only
> got about 4 replies to the patches that touched 20+ drivers. I suppose I
> should just hassle maintainers until they fix it or tell me where I've
> gone wrong ...
>
Actually I was not quite correct. The call to timeout WILL return
immediately, however, the timeout code will clean up the timer, so there
should be no worry there. It is a bug in that the sleep does not happen
as expected. I saw at least one place where there were comments about
it not working.. and he did not set the state. For what its worth I
think the schedule_timeout() should be changed to __schedule_timeout()
and two new time out calls be used {un}interruptible_sleep_on_timeout(),
these calls to do the set up of state. In fact the interruptible
version already exists. Of course things like select would have to use
__schedule_timeout() as they are waiting for any of several events.
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: Question: slow network performance between Linux and Solaris 7
On Wed, 6 Sep 2000, Jack Duan wrote: > I have been using Linux since the early days... and recently that I have > installed RH6.2 with Linux kernel 2.2.16 on my Dell laptop (P3-500, > 256MB RAM). One thing that I found is the networking performance > between this Linux box and all my Solaris 7 based servers are very very > slow. I only get around 7-10k/s transfer rate over 100-BT link. I have > desperately searched all the websites that I can think of to find any > answers, but none helpful. Here is a detailed problem description: > I've seen the same when the switch and nic (tulip) do not seem to sense the same mode.. I have to force the tulip-driver to use 100Mbpx fullduplex and force it to the switch also. This way everything is happy. When the nic and switch have different transfer modes, connections to the 10Mbps boxes work well (at the full 10Mbps), but connections to the 100Mbps boxes are VERY slow. Something like 3-10k/s just like you said. On the other hand, if you get good transfer rates between linux-boxes this migth not be your problem.. - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. - 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
On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote: > scale in the end. We'll either see forking, see another OS like FreeBSD > fill the void, or (worst case) Solaris. Somehow I doubt that arguments from marketshare/field circus/etc. peppered with threats of coprorat world turning to Solaris, etc. will win you much love from FreeBSD core team. I _really_ doubt that they will make any effect on the development decisions. You see, these guys are bastards too - comes with the territory. So are NetBSD and OpenBSD folks - try to speak to Theo that way and you will realize that Linus _is_ a nice guy, after all. Could we please avoid bringing the moldy corpse of UniForum on l-k? Let it rot in purgatory, where it belongs. There are valid arguments for and against kernel dubuggers, but Wall Street and viability of someone's business models have nothing to them. - 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-test7 SB awe32 oddity
mazeone wrote: > > I have an older Creative Sound Blaster awe32 soundcard, which has worked > fine under many different kernels in the past. It is one of the older > models with jumpers, before the ISAPnP models became available. I also have a Sound Blaster Awe32; but mine is jumperless and doesn't respond to isapnp. It lives happily on io220, irq5, dma1,5 etc. I have the values set as options in /etc/conf.modules > With test7, things got odder. If I Mine works fine in test6 and earlier, but does NOT like test7. I have posted this before to lkml (Subject: "modprobe sound" causing oops under test7 / test8-pre1) but received no replies :( Brief recap: test7 spits out with "sb: I/O region in use." and then some dma left allocated messages (printk'd as the module shuts down I believe). Subsequently cat'ing /proc/interrupts or /proc/ioports oopses reliably (reliable oops?) test8-pre1 locks the machine tight on "modprobe sound", and test8-pre2 is about as polite(!) as test7 I'm waiting for the truncate "issues" to settle before looking into it again. > The one thing that I suspect might be related to this is that I have had > some problems with odd APIC stuff on this motherboard (Abit bp6 with 2 > celeron 533's). However, my soundcard does work in this machine using > kernel 2.2.16. Ooh! Same motherboard, but again, everything Works Fine with older kernels There appears to have been a fair few changes in the kernel regarding sound, and even such things as MOD_INC_USE() and variants have been moved / restructured; possibly something wasn't quite altered correctly :( Gerard Sharp Two Penguins, 2.4.0-test6 - 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 Wed, 6 Sep 2000, Jeff V. Merkey wrote: > Mike Galbraith wrote: > > > > On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > > > > > Ingo, > > > > > > KDB is a user mode debugger designed to debug user space apps that's > > > been hacked to run with a driver. It's not designed as a kernel level > > > debugger and in real world situations has tons of shortcomings period. > > > > ?!? KDB is a minimalist kernel mode debugger written at SGI. > > Mike, > > I've used it. It's better than stone knives and bearskins, but for > tough problems (like busted hardware or malfunctioning drivers) it has > serious problems, locks up, double faults, etc. > > Jeff For busted hardware, you need a lab full of hardware tools. For busted drivers, KDB is fine. It's not perfect.. doesn't handle prologue scheduling done by modern gcc for example. (and if your debugger does, I fully intend to examine/steal your method, ok?:) -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: We are as good as our tools
On Wed, 6 Sep 2000, Stephen Satchell wrote: > In other parts of the Open Source community, people point with pride to the > tools they use to do their work. Let's not forget that Ritchie decided > that he needed a language to speed his development of a quick-n-dirty > operating system using an old PDP-7 that had been discarded -- when the > "logical" way would have been to dig right in -- using assembler, the > language of the day, to try to get the job done. Interesting that the tool > came first, in the system that gave birth to the effort which is the > subject of this mailing list... Eh? PDP-7 version: 1969, assembler Transition to PDP-11: 1971, assembler v1: October 1971, assembler (B had been there, but almost nothing used it) v2: 1972, assembler NB, early C: 1972-1973 (dmr) v3: same timeframe, ken tried to use C in kernel but gave up on that v4: 1973, rewrite in C (ken and dmr). Notice that very large piece of the system as we know it was in place in v3. Moreover, assembler was the language of the day in many cultures, but not in the Multics one. BTW, EPL was done by Bell Labs group. So understanding that high-level languages were nice for the system programming was there. But implementing PL on -7 was obviously out of question. And B was not too suitable for the kernel (no structures, for one thing). C did not come first. Check the manpages of v1 if you doubt it. And keep in mind that v1 was two years from the beginning. And C was two years in the future... BTW, tools are really nice, but I wouldn't call conventional debuggers a-la [asg]db good ones. I've been _very_ impressed by Acid - after gdb it feels like a switch from MCR to sh. Small core providing a language with enough primitives to build the rest of debugger + library + ability to write new functions. _That_ would be very useful thing to have - you are not limited to stepping/poking anymore and can actually write functions that check state consistency/get stats/whatever and use them. I would really recommend everyone involved in that thread look through the papers on this thing (USENIX '94; available online on the plan9.bell-labs.com/sys/doc/) and look at it in work. Something similar could be really useful - unlike gbd it allows to look at the large picture without wearing your fingers to bones. Essentially, Acid libraries can be used as documentation on the state - very expressive beast. - 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?
Chris Evans <[EMAIL PROTECTED]> wrote:
> Well, in our own manpages
> man 7 socket
>It is possible to do non-blocking IO on sockets by setting
>the O_NONBLOCK flag on a socket file descriptor using
>fcntl(2). O_NONBLOCK is inherited through an accept.
Although accept(2) states the opposite:
original socket s is unaffected by this call. Note that
any per file descriptor flags (everything that can be set
with the F_SETFL fcntl, like non blocking or async state)
are not inherited across a accept.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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?] Extended PTBL partition check for 2.4
Andries Brouwer wrote: : Thanks for your exhaustive explanation as usual. > I think I prefer the current version over your patched version. > But will probably change my mind when many people complain. Why have different behavior ? Why have *fdisk or lilo trouble ? I still didn't see the gain. people++; luca -- -- E-mail..: Luca Montecchiani <[EMAIL PROTECTED]> W.W.W...: http://i.am/m.luca - http://luca.myip.org Speakfreely.: sflwl -hlwl.fourmilab.ch luca@ I.C.Q...: 17655604 ---=(Linux since 1995)=--- Non esiste vento favorevole per il marinaio che non sa dove andare Seneca - 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
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 It's the same kdb. (I do need to re-sync with Andrea though, memleak has been busted and fixed since way back then) It happens the other way around too.. sometimes ikd patches are against a more recent kernel than the standalone kdb patch. -Mike In any case, if the official release ikd is ever too old for anyone (ikd is maintenance intensive. Andrea wouldn't get any work done if he released for every pre-patch), drop a line via private mail and I'll extract/send what I'm running. #include ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On 2000-09-06T12:52:29, Linus Torvalds <[EMAIL PROTECTED]> said: I do agree with your assessment. Except for a single point: > And quite frankly, for most of the real problems (as opposed to the stupid > bugs - of which there are many, as the latest crap with "truncate()" has > shown us) a debugger doesn't much help. And the real problems are what I > worry about. The rest is just details. It will get fixed eventually. I want these to get fixed _soon_. Not later. I want fixing these to be made as easy as possible, because they are annoying and don't have to be, because the "simple" problems are easier spotted with a debugger. If a real problem gets spotted easier and fixed correctly, all the better. If some people are able to better understand the code and what it does with a debugger, all the better. The community peer review will weed out incorrect patches. I doubt there will be too many of them or that people will suddenly start patch bombing l-k with crap because a debugger has been added. Hell, if a debugger only supplies a single clue to make people go "Duh, I was looking in the entirely wrong direction, better get to understand how the networking code works instead of hunting it in the VM layer", it is well worth it. I don't need quick and shallow fixes any more than you do. I want the code to stabilize, and do The Right Thing(tm). For all "fixes" which lead to clumsy, harder to understand code - see figure 1. For those fixes which can be spotted because we can easily get a consistent view of what happened on the system the time it crashed - no more "What processes were you running, try disabling and see if it persists" -, debugger output which makes you go "Duh, I have a typo there", I _do_ care for a debugger. > I do realize that others disagree. And I'm not your Mom. You can use a > kernel debugger if you want to, and I won't give you the cold shoulder > because you have "sullied" yourself. But I'm not going to help you use > one, and I wuld frankly prefer people not to use kernel debuggers that > much. So I don't make it part of the standard distribution, and if the > existing debuggers aren't very well known I won't shed a tear over it. > > Because I'm a bastard, and proud of it! > > Linus This makes for a good Think Geek shirt, and I will personally buy one and try to get it signed by Alan. But for trying to shepherd a project the size of the Linux, I do think it is the wrong attitude if taken to the extremes. Not trying to make it easier for the masses to provide better QA data, or even fix the stupid errors themselves, so that the core team can focus on the real hard bugs and design issues, I call that wrong. Sincerely, Lars Marowsky-Brée <[EMAIL PROTECTED]> Development HA -- Perfection is our goal, excellence will be tolerated. -- J. Yahl - 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/
We are as good as our tools
At 06:40 PM 9/6/00 -0700, J. Dow wrote: >30 years of experience have proven this to me over and over again from >watching auto mechanics and ditch diggers through every engineering >discipline I have ever paused to observe. Only a damnfool eschews good >tools because of some sense of "pride" that doing it the caveman way >"forces me to think more." Let me add my 30-year's worth of experience in a number of nasty computer environments to Ms. Dow's comments. There are seven people in the world who I drove crazy by paying more attention to tools than to the "task at hand"... yet when it came to counting coup on projects that WORKED, my bosses quickly shut up about my building jigs and scaffolding and debug aids into code. In other parts of the Open Source community, people point with pride to the tools they use to do their work. Let's not forget that Ritchie decided that he needed a language to speed his development of a quick-n-dirty operating system using an old PDP-7 that had been discarded -- when the "logical" way would have been to dig right in -- using assembler, the language of the day, to try to get the job done. Interesting that the tool came first, in the system that gave birth to the effort which is the subject of this mailing list... On the subject of debuggers: All too often I have run into the situation with real-time code where the Heisenberg principle causes the system to work with the debugger in, and fail with the debugger out. Ditto with "test code" that is conditionally compiled as an aid to debugging. It's akin to a hardware engineer using 50pF capacitors to "make the prototype work" and never taking the time to understand just why adding a touch of slowdown made the circuit work. This is especially true when that "50pF capacitor" is a scope probe. Is that a good reason to "just say no" to debuggers? I don't think so. Too little reliance on debuggers and defensive code is just as bad, if not worse, than too much reliance. Debuggers are great for collecting the symptoms of the problem; it still takes thinking and role-playing to get to the heart of the problem. That thinking operator also has to know the effect of the tool he is using, just as the hardware guy has to know the effect of placing a scope probe right THERE on the circuit. Indeed, that scope probe can be a handy way to tweaking the system in subtle ways, and with analysis of the change in the symptoms that can point to the problem. "Why does placing a breakpoint THERE cause such a drastic change? AHA!" With the amount of state being thrown around in an operating system, only a good debugger in the hands of a thinking operator can isolate the fault to a particular block of code -- then the thinking operator gets off the machine and onto the source code to noodle out why the astonishing event is occurring. I'll crawl back into my writing cave now, content to watch for the moment. Satch - 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
Stephen, On Wed, Sep 06, 2000 at 10:55:06AM -0400, Stephen Frost wrote: > 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. Yes, that's odd. But why do you think it's because of eepro100 changes? You may use the driver from 2.2.16 kernel with 2.2.17 and visa versa. Please, report whether it's really eepro100 issue. Best regards Andrey V. Savochkin - 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
On Wed, 6 Sep 2000, Gregory Maxwell wrote: > On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote: > > If you'd read what I wrote in it's entirety, you'd know that I'm very well > > aware of this perspective. > > I read it. I just didn't agree with the level of importance I felt you > were assigning to corporate use. Well, what I'm trying to do is raise the issue. If it seems like I'm trying to make it overly important there's probably some miscommunication going on. > I think it's obvious you understand what Linus wrote. I think you > misunderstand the design focus of the Linux kernel. I think I understand the design focus as well. Like you said a bit later its focused on creating a very solid underlying structure. Maybe you're right that in the long-run Linux will win the race by having the solid structure with all the features layered properly on top of it. OTOH if Linux doesn't deliver the features soon, perhaps interest will go elsewhere so something which doesn't have a perfect platform but is more usable for those who need those features. Like I said, its an interesting experiment, we'll see who is right in the end... > > Perhaps to put a better spin on things what I should state is that I > > understand what Linus is trying to do, and I'm merely pointing out that > > he's really not filling the gap of supplying an IT-friendly open source > > OS. > > I don't believe he ever stated that he wanted to do that. I never stated that I believed that Linus wanted to do that. Lots of people seem to think that he's doing this though. I'm just pointing out that he's not. > > I don't know why this viewpoint creates such hostile responses from some > > people. I'm pointing out that Linux is not everything for everyone. > > Heresy. > > I certainly hope you didn't see my response as hostile. It certainly wasn't > intended to be that way. Actually yours wasn't at all. Some of the e-mail I'm getting privately hasn't quite been as polite though, and I was still doing a bit of a slow burn... - 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 SB awe32 oddity
I have an older Creative Sound Blaster awe32 soundcard, which has worked fine under many different kernels in the past. It is one of the older models with jumpers, before the ISAPnP models became available. In the past, I always set the io, irq, and dma in the menuconfig setup. However, I haven't been able to get it to work since that option was taken out of menuconfig/xconfig. I also haven't been able to get it to work by loading the module by hand, passing it the correct io, irq, and dma values on the command line. With test7, things got odder. If I insmod uart401 insmod sb_lib insmod sb io=0x220 irq=5 dma=1 I get a "No such device" error. However, if I cat /proc/interrupts, the Soundblaster shows up as using irq 5. If I subsequently unload the sb_lib module and try to cat /proc/interrupts, I get this: Unable to handle kernel paging request at virtual address c983f474 printing eip: c021cb0a *pde = 012c5063 *pte = Oops: CPU:1 EIP:0010:[] EFLAGS: 00010297 eax: c893f474 ebx: c473411c ecx: c983f474 edx: fffe esi: c40adf28 edi: ebp: c983f474 esp: c40adee8 ds: 0018 es: 0018 ss: 0018 Process cat (pid: 253, stackpage=c40ad000) Stack: c473411a c02efbe4 c4507480 0002 c02efbe4 c4507480 c021ccc8 c473411a c0226837 c40adf24 c010b91d c473411a c0226834 c983f474 c473410b c022682e c022b864 0c00 c4734000 1000 00a0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] Code: 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 89 44 24 10 8b 44 Segmentation fault If I play with the modules more, I can usually make it so I can cat /proc/interrupts again, but irq 5 shows up as used but sometimes instead of showing as used by soundblaster, it has a blank where it would normally give the device name. The one thing that I suspect might be related to this is that I have had some problems with odd APIC stuff on this motherboard (Abit bp6 with 2 celeron 533's). However, my soundcard does work in this machine using kernel 2.2.16. I'm not currently subscribed to lkml, but I'm curious to know if other people have seen similar problems with the older sb/awe32 cards. Also, why was the option to set the card up in the menuconfig/xconfig taken out? Something to do with the driver re-organization? I'm running modutils 2.3.14, kernel was compiled with gcc 2.95.2, the rest is a fairly up-to-date debian woody system. If anyone else has seen this, or solved this problem, I'd love to hear from them. Thanks. -- .michael lea \_\_ "baa" [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: Availability of kdb
> your email inundation by one. Er, why's the list setup without > a reply-to the list?) lists that add "reply-to: list" degenerate to chat rooms. so this is social-engineering, just like the lack of builtin kernel debugger. - 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
<[EMAIL PROTECTED]> said: [...] > It cuts the other way as well though. If it is prohibitively hard and > difficult to get fixes out for bugs in the Linux kernel, then companies > will tend to choose other operating systems to run their applications on. So what? I have been running Linux from long before the craze started, and I suspect I'll be doing so long after it dies down (if it does). In any case, in Linux (and OS software in general) I find it is much easier to get bugs fixed than with closed alternatives. The hard problem is to find bugs to fix... there are so few ;-) [...] > I'm really kind of surprised that companies like SuSE, VA and RedHat > haven't started talking about forking the kernel already. Those companies > are serving the administrators and managers whose needs you are openly > admitting that you are not concerned with. For those companies the > present state of affairs isn't sustainable. The people at the helm of those companies seem to think otherwise. And I suspect they know a bit more about their respective states of affairs than you do. In a way they have forked the kernel (mildly) already, just look at the patches they apply to the kernels they ship. But none of them can match the manpower of the full kernel hacker community, so they know they have to stay in synch with the official kernel in general terms. > And I don't ask you to care about it. I guess my point is just that the > linux kernel is an experiment in what happens when you ditch the managers > and administrators and business-types and try to write a major software > project entirely driven by developers. I will place a friendly wager that > the experiment will show that not all the needs of those people are as > dismissable as many software developers seem to think. Linux is doing fine, thank you. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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: Is it OK to release non-GPL network driver with source?
Dave Allen <[EMAIL PROTECTED]> said: [...] > The source code for the driver _is_ going to be available, but it will > not be GPL'd. There are no patches to the kernel involved. I > understand that there should be no problems, but the use of inline > functions in the kernel header files makes the situation a bit more > complicated. The compiled binary code then does contain GPL'd code, > so would it not then be considered a "derivative work"? AFAIU, .h files are meant to be #included without strings attached, so you should be safe here. It might be a good idea to clarify points like this one (it comes up now and then) and add some .../Documentation/legalese/ into the kernel... BTW, GPL covers distributing stuff only, so just whoever distributes the result could be in trouble. IANAL, and I'm not the copyright holder (who would have to decide if/when/who to sue for infringement in any case ;-) Experts on legal stuff and copyright you won't find here, I'm afraid. May I ask why not GPLing the driver? You could for example state that the code is under GPL for use in the Linux kernel only, even distribute under the GPL and some other license at the same time. By giving the Linux community the right to modify and redistribute the result it will benefit from the general work on drivers to port them forward and fix bugs. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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: [OT] incremental patch of two patches?
[Jorge Nerin] > How can I make a incremental patch of two other patches without > making two trees? There do exist tools for this but I have found them limiting. I'm working on my own utility to do this (and other patch manipulations, such as cdiff -> udiff) but don't have an ETA. I'll let you know if I ever release anything. > I think that this can be done without even using the original tree, > only using the patches, but I cant find a way. Yeah, my tool will do that, when done. 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: eepro100 trouble
On Wed, Sep 06, 2000 at 10:41:46AM -0400, Admin Mailing Lists wrote: > On Tue, 5 Sep 2000, Andrey Savochkin wrote: > > 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. If it worked for 2.2.15pre18, it will work for 2.2.17. Best regards Andrey V. Savochkin - 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: Glad we did not add NTFS stream support
On Wed, 06 Sep 2000, Trevor Harrison wrote: >Don't be a dim-wit. The only reason its a problem on NT is that MS decided to >not allow users to browse the other data streams (or forks, or whatever you >want to call them) in Explorer. > >Actually, this type of virus is probably easier to find and clean because its >isolated itself in a nice little package that you can nuke at via the file >system. Ummm maybe. A SANS newsletter indicated that none of the current virus scanners even look at the other data streams (yet). Determining if the default stream is actually infected could be problematical too - consider that the signature of the virus might be a VERY short piece of code that looks just like other pieces that do ligitimate functions (like start another process...). This could give many false positives, making a scan nearly useless. This also gives rise to the posibility of hiding a virus via a chain of block reads, where each block is read over the previous block, but offset by a few 10s of bytes. After 20 blocks are read the complete virus exists. The virus signature is scattered across many blocks and is not contigueous for a virus scanner. If the data is loaded from several different streams (interleaved, of course) it would be even harder to locate. Yet the virus signature is still missing since reading blocks of data is a fairly normal thing to do. Nasty little bugger. The current NT utilities also have a problem in that a stream could consume the entire disk, but not be visible to the standard utilities - they don't list file size of any but the default stream. Of an interesting note: one of the suggested fixes involved copying the infected file to a "non windows system such as Linux..." (paraphrased.. not real quote) and then copying it back without the alternate stream(s). -- - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - 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
On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote: > If you'd read what I wrote in it's entirety, you'd know that I'm very well > aware of this perspective. I read it. I just didn't agree with the level of importance I felt you were assigning to corporate use. > I don't need to have the volumes of idiocy > which come out of some management pointed out to me. Good. > At the same time my > entire point was that I think there's some valid business concerns that > they have /after/ removing all the crap, and that I wouldn't be surprised > if the market went against linux and in favor of other operating systems > that addressed them. They should use what is best for them. > And if you think I don't understand what Linux wrote you are very wrong. I think it's obvious you understand what Linus wrote. I think you misunderstand the design focus of the Linux kernel. > Perhaps to put a better spin on things what I should state is that I > understand what Linus is trying to do, and I'm merely pointing out that > he's really not filling the gap of supplying an IT-friendly open source > OS. I don't believe he ever stated that he wanted to do that. > He's providing an OS for developers. Cool. Fine. No worries. But It would be more accurately to say that he's creating a GPLed Unix compatible kernel which utilizes the best (in his unhumble opinion) available technologies while remaining reasonably compatible. The strongest development direction appears to be towards long-term sustainability and stability (vs short term) and a focus on features that are usable today (vs experimental stuff). > that does leave a void, in my opinion. Perhaps disributions adding > patches to the kernel will fill this void, but I tend to think it wont > scale in the end. We'll either see forking, see another OS like FreeBSD > fill the void, or (worst case) Solaris. None of those are necessarily bad things. I think Linuses design decisions will pay off in the long run. When the race has no ending line, who cares if you have a slower start. > I don't know why this viewpoint creates such hostile responses from some > people. I'm pointing out that Linux is not everything for everyone. > Heresy. I certainly hope you didn't see my response as hostile. It certainly wasn't intended to be that way. - 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
> Or, to misquote Feynman (another cantankorous bastard, but proud of it):
>
> "Look at the problem. Think really hard. And write the correct code."
In a smallish voice I note that the debugger helps you look at the problem.
It is your X-Ray vision.
{o.o}
-
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/
EEPRO Problems in 2.2.17 (sorry!)
Well, I thought the problems with the eepro driver from 2.2.16 were fixed in 2.2.17. Apparently the problems really weren't fixed - it did seem to get more stable though. I was copying some large over a NFS mount and when it got to about 6 megs, the NFS mount hung with symptoms similar to the 2.2.16 problems I had. Which was: no errors in the messages log, a hung NFS mount and reloading the driver module clears the problem up. So I started doing some tests with ping to see how long it would stay up. During those tests, I noticed some wierd DUP packets: 64 bytes from 1.2.3.4: icmp_seq=28 ttl=255 time=0.4 ms 64 bytes from 1.2.3.4: icmp_seq=18 ttl=255 time=10894.5 ms (DUP!) 64 bytes from 1.2.3.4: icmp_seq=29 ttl=255 time=0.4 ms They were all between 10-20 behind the icmp_seq and had at least a 6000ms time. In the middle of a 40meg nfs copy, the driver hung at least 4 times - but at fairly random intervals. Sometimes it will run for a long time - sometimes it locks up twice in a row fairly fast. With the 2.2.14 and previous drivers I did not once notice an error with this card. The only msg/error I see in the messages log is this: eth1: set Rx mode to 1 address. But I've got that message for years now with the eepro driver. If anyone familiar with this driver wishes to work with me in an attempt to reproduce this problem, I'd be happy to help. Thanks, Brian Hayward - 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
Quoth Linus
> Apparently, if you follow the arguments, not having a kernel debugger
> leads to various maladies:
> - you crash when something goes wrong, and you fsck and it takes forever
>and you get frustrated.
> - people have given up on Linux kernel programming because it's too hard
>and too time-consuming
> - it takes longer to create new features.
Quoth an unrepentant jdow.
Nice men of straw there. I note you properly demolished them.
> It's partly "source vs binary", but it's more than that. It's not that you
> have to look at the sources (of course you have to - and any good debugger
> will make that _easy_). It's that you have to look at the level _above_
> sources. At the meaning of things. Without a debugger, you basically have
> to go the next step: understand what the program does. Not just that
> particular line.
The point is that WITH a debugger you have to take that step as well.
A person without the self discipline to do that is still a child and should
not be in this business. The debugger gives you a better picture of what
is actually happening. If that leverage is considered to be a bad thing
I am surprised and dismayed. A bloody LOT of personal experience
and technological bloody noses suggests it is a very good thing.
> And quite frankly, for most of the real problems (as opposed to the stupid
> bugs - of which there are many, as the latest crap with "truncate()" has
> shown us) a debugger doesn't much help. And the real problems are what I
> worry about. The rest is just details. It will get fixed eventually.
Is somebody saying that a debugger is the key to heaven? I certainly
am not. It is the platform at the top of the ladder that holds your paint
bucket so that you don't have to climb up and down the ladder of your
understanding quite so often. It also beats you over the head with
facts when your head has it wrong. And I must admit that is a painful
hit direct to the ego. {^_-}
> Because I'm a bastard, and proud of it!
And I am an older bitch and proud of it. I've whupped bigger boys than
you.
{^,-}At least I ended on some humor.
(And I even arranged that you only see the list copy reducing
your email inundation by one. Er, why's the list setup without
a reply-to the list?)
-
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
On Wed, 6 Sep 2000, Gregory Maxwell wrote: > Finally, who says that acceptance by 'IT managers and CTOs' is actually a > measure of 'quality' that anyone here finds interesting or acceptable? The > very fact that many 'IT managers and CTOs' find NT acceptable speaks > volumes to counter the credibility of that as a useful product metric. If you'd read what I wrote in it's entirety, you'd know that I'm very well aware of this perspective. I don't need to have the volumes of idiocy which come out of some management pointed out to me. At the same time my entire point was that I think there's some valid business concerns that they have /after/ removing all the crap, and that I wouldn't be surprised if the market went against linux and in favor of other operating systems that addressed them. And if you think I don't understand what Linux wrote you are very wrong. Perhaps to put a better spin on things what I should state is that I understand what Linus is trying to do, and I'm merely pointing out that he's really not filling the gap of supplying an IT-friendly open source OS. He's providing an OS for developers. Cool. Fine. No worries. But that does leave a void, in my opinion. Perhaps disributions adding patches to the kernel will fill this void, but I tend to think it wont scale in the end. We'll either see forking, see another OS like FreeBSD fill the void, or (worst case) Solaris. I don't know why this viewpoint creates such hostile responses from some people. I'm pointing out that Linux is not everything for everyone. Heresy. - 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
On Wed, 6 Sep 2000, David S. Miller wrote: >Date: Wed, 6 Sep 2000 17:46:02 -0700 (PDT) >From: <[EMAIL PROTECTED]> > >I guarantee you that IT managers and CTOs do not share your >enthusiasm for slow, correct coding when faced with their business >being down, their revenue stream being interrupted and their stock >options losing value. > > What part of "I don't care" did you not understand when Linus said it? > > What part of "More Code, more people, more money. Why should I think > they are good things?" did you not understand when Linus said it? Apparently you didn't bother to read past the sentence that you quoted. I understand quite well that Linus doesn't care. I understand that he does not think that those things are good. I even agree with him that from where he's coming from and the kind of development process that he's trying to create that those things aren't good. Take a valium and read what I wrote 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: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
From: "Horst von Brand" <[EMAIL PROTECTED]>
> 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...
So you place your money into the bank until you have a "large enough sum
to be worth investing in a mutual fund or stock", I presume. If not then you
SHOULD understand the invest now for returns later ideas. If the time is
invested now the return on investment later will be far greater than if they
finally grudgingly try to do it later.
While I was at Magnavox I watched several software projects from
proposal through production code. The more time that was invested
up front in tools the more likely the project was to be on time and on
budget or even under budget. (And this was with that roundly dispised
thing called Ada. Go figure.)
I rather strongly think it is well past time to make the debugger
investment. But building a good one is hard to do. Where is someone
smart enough and capable enough to get the core built so that there
is a rational debugger project to parallel the kernel development?
It's not a glamorous job. But somebody ought to grit their teeth and
get their name on The Linux Kernel Debugger. I suspect the community
would remember THAT person a LONG time. I kinda wish I had the
time and that it better fit my skill sets. I know the people who fit the
project are out there earning REALLY big bucks from Raytheon
and Rockwell as well as some of the more often thought of companies.
> Witness the people who have argued _against_ integrating debugging code
> into the kernel, *even code they designed and wrote themselves*.
"If it was hard to design by God it should be hard to maintain, too."
> 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, I think you are pointing out one of the more
splendidly large worms in the Open Source apple. Better tools are
needed and if they exist they would be used. But nobody wants the
job. So it doesn't get done.
Alas, *I* do not have a solution other than maybe to embarrass someone
into doing what has to be done and geting intense satisfaction about that
when it is done.
{^_^}
-
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
> > 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
Sigh, one more try to get youse guys to understand.
I started out as an RF engineer. I note that I was considered damn good
at it. Part of the reason I worked the miracles I worked, designing radios
for the military with specifications straight out of science fiction, is tools.
The one indispensable tool was a deep understanding of which way the
electrons flow and how. Another was mathematics. A third is experience.
Without these basics no other tool would have led me to the solutions I
found.
But I also used other power tools. I built my own computer aided circuit
analysis program. With that program I found some problems early on
that would have kept me at the test bench for weeks tracking down. I
added one resistor to a variable tuned circuit and increased the circuit's
useable dynamic range 30dB. I confirmed it with another tool I consider
indispensable, the spectrum analyzer. A couple years later we got our
first network analyzer and I was in hog heaven. When we finally got a
computer controlled network analyzer I did even better. I wrote some
custom software for it that led to being able to calibrate the test set
for the GPS navigation data unit to 10 times the precision of the NDU
itself in 30 minutes from drag the equipment into the room to tear down.
When the poor sod from Bendix (the folks that made that iteration of the
NDU) who was visiting that day saw this he died. It took them a full day
to get to the same results AND they had not noticed some effects I
pointed out to him DURING that 30 minutes. *THIS* is what a debugger
is for. It is a window on the software you are attempting to debug that
allows even the best in the business to do better. I rather immodestly
lay claim to being one of the best RF engineers in the country in the
70s for high dynamic range antijam receivers and frequency synthesizers.
I might not have been so good except that I adopted tools and used them
WITH my knowledge gained from building ham radio equipment of my
own since the 9th grade. Experience, knowledge, AND TOOLS lead to
the best product. Cripple your tools and you cripple your product.
30 years of experience have proven this to me over and over again from
watching auto mechanics and ditch diggers through every engineering
discipline I have ever paused to observe. Only a damnfool eschews good
tools because of some sense of "pride" that doing it the caveman way
"forces me to think more." Son, if you need to be forced into thinking you
are in the wrong business. I got into SW because RF engineering was
getting boring and this was more challenging and fun. ('Sides, it gets VERY
tiring for a "guril" to fight most of the RF weenies her age who think that
since she is a "guril" she cannot POSSIBLY understand electrons. I had
to prove them wrong and fools too many times. I got bored. SW was more
"forgiving" in that regard. It allowed me more time to concentrate on
"doing it right and well." I figure I am "good" but not "great" with SW. Er,
the company I last worked for thought different. I got all the jobs nobody
else seemed able to do. Sadly I had to do most of them without adequate
tools. I really learned to like the leverage tools give. Tools do not SOLVE
the problems. But they leverage my knowledge so that *I* can solve the
problem. It is entirely up to me to have the self discipline to think through
what I can learn with the debugger until I have a solution that "makes
sense". "It works" does not always "make sense". So I usually do not
stop at "it works". That is being an adult and having some self discipline
as opposed to a being a child in a high tech playground. I get adult level
rewards and satisfaction that the children miss, too. The "hit" or the
"high" is greater the adult way.
{^_^}
-
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
Try LKCD. --Matt Gregory Maxwell wrote: > If this is your primary argument for a kernel debugger, a 'crash dump tool > with extra controls', then why not just cleanly implement a 'crash dump > tool with extra controls'. - 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
On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote: [snip] > I guarantee you that IT managers and CTOs do not share your enthusiasm for > slow, correct coding when faced with their business being down, their > revenue stream being interrupted and their stock options losing value. [snip] No company should have to face that sort of problem, any problem that severe should be easily found in preproduction testing. Linux'es low-cruft level usually causes pretty consistent and testable behavior, once it works it tends to keep working. Additionally, any problem so severe and repeatable to cause such problems should be easily fixed with or without a debugger. I've seen an example of a fast bugfix from a company with a wonderful in-kernel debugger. When the teardrop became common, Microsoft used their wonderful debugger to find a great point to insert a 'if packet looks like this' filter. They didn't fix the problem in their initial patch. They inserted a fast non-fix, the kind of behavior encouraged by debuggers (fix the symptom, not the problem). Just a few days later, they were being crashed again by a minor variant of the same bug. Linux on the other hand, had a true fix and were not subject to the revised attack. (Incidentally, Linux's true fix came out before MS's quick patch). Quick fixes bring about quick cruft. The 'expense' of maintain code grows exponentially with it's cruft level. A 'slower' fix today will likely improve long term sustainablity. Finally, who says that acceptance by 'IT managers and CTOs' is actually a measure of 'quality' that anyone here finds interesting or acceptable? The very fact that many 'IT managers and CTOs' find NT acceptable speaks volumes to counter the credibility of that as a useful product metric. - 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/
Question: slow network performance between Linux and Solaris 7
Hi, I have been using Linux since the early days... and recently that I have installed RH6.2 with Linux kernel 2.2.16 on my Dell laptop (P3-500, 256MB RAM). One thing that I found is the networking performance between this Linux box and all my Solaris 7 based servers are very very slow. I only get around 7-10k/s transfer rate over 100-BT link. I have desperately searched all the websites that I can think of to find any answers, but none helpful. Here is a detailed problem description: Linux box: -- Dell P3-500Mhz, 256 RAM -- RH 6.2 -- Kernel 2.2.14, 2.2.16, and I compiled 2.4.0-test7 -- Xircom CardBus Combo card 100/BT Solaris 7 -- Most high-end servers E4500 and above -- 100BT or Giga-Ether Doing a FTP or HTTP from Linux to Sun, transfer rate is around 3-10K/s. If I do FTP to another Linux box, the transfer rate is at least 1000k - 3000k/s Booting the laptop into Win2000, file transfer from it and Sun is at least 1000K/s, normally 3000k/s. I heard it might be Solaris TCP window scaling issue... how do I solve this besides telling me to switch from Linux to FreeBSD, which I will not do. Any help will be greatly appreciated. Thanks, Jack PS: By email to this mailing list is a desperate attempt to solve this problem... Please cc to my email address directly since I am not on the mailing list. Thanks! -- Jack Duan, [EMAIL PROTECTED] Systems Architect, iPlanet Infrastructure Services - 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
Date:Wed, 6 Sep 2000 17:46:02 -0700 (PDT) From: <[EMAIL PROTECTED]> I guarantee you that IT managers and CTOs do not share your enthusiasm for slow, correct coding when faced with their business being down, their revenue stream being interrupted and their stock options losing value. What part of "I don't care" did you not understand when Linus said it? What part of "More Code, more people, more money. Why should I think they are good things?" did you not understand when Linus said it? You miss the entire point. Linus is saying "I don't care" about the standard kernel. From this, you can consider that someone who does care is more than welcome to provide a service that: 1) Adds the debugger, kernel dump, whatever patch to the kernel for a customer. 2) Provides a support contract for that customer, where 24/7 they'll work on fixing trouble that customer has. None of this has any relevance to whether the standard kernel has this or that debugging facility. Just becuase it isn't in the standard kernel doesn't mean the whole world is disallowed from using it. "IT managers" and "enterprise wide client server, java brown stuff enabled" sites are going to want a support contract if they do anything serious with Linux, a fair assumption right? It then goes almost without saying that those entities providing such support services would be wise to, as a part of this service, have the site run kernels with KDB or whatever included. Right? Isn't this the whole beauty of open source, anybody can just add it in? I think this whole thread is becoming rediculious. Linus will not put KDB and other such debugging aides into the standard tree so live with it already. Later, David S. Miller [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: Availability of kdb
In article <[EMAIL PROTECTED]> you write: >I'm really kind of surprised that companies like SuSE, VA and RedHat >haven't started talking about forking the kernel already. Those companies >are serving the administrators and managers whose needs you are openly >admitting that you are not concerned with. For those companies the >present state of affairs isn't sustainable. If you haven't noticed, they already do. The kernel shipped from RedHat has quite a few patches applied that arent in Linus' tree. There's nothing stopping them from doing the same thing with the KGDB or IKD patch. /Christer -- "Just how much can I get away with and still go to heaven?" - 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
On Wed, 6 Sep 2000, Alan Cox wrote: > > Ehh? And exactly _how_ would a debugger help it. > > > > Especially as Alan quoted an example of a driver bug that didn't get fixed > > for several months because the maintainer didn't have the hardware. > > > > What would a debugger have done? > > Let the end user give me essential answers on what was happening at the failure > point. Think of it as a crash dump tool with extra controls [snip] If this is your primary argument for a kernel debugger, a 'crash dump tool with extra controls', then why not just cleanly implement a 'crash dump tool with extra controls'. I would suspect that such a tool could be accomplished much much safely (both code maintenance wise, as well as runtime and source bloat) then a full kernel debugger. Interactive postmortem shouldn't require any support code or tooling floating about in unrelated parts of the kernel. - 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
On 6 Sep 2000, Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, > Jeff V. Merkey <[EMAIL PROTECTED]> wrote: > >Linus Torvalds wrote: > > > >> Apparently, if you follow the arguments, not having a kernel debugger > >> leads to various maladies: > >> - you crash when something goes wrong, and you fsck and it takes forever > >>and you get frustrated. > >> - people have given up on Linux kernel programming because it's too hard > >>and too time-consuming > >> - it takes longer to create new features. > >> > >> And nobody has explained to me why these are _bad_ things. > > > >They are bad because they cost people money that could be spent more > >productively in other areas due to the lengthening of the development > >process and the support costs. > > Ehh.. > > Explain to me again why I should care? > > Read my posting again. Read the "I'm a bastard" part twice. Realize > that in the end, I don't care who speds money, time, and effort. In the > end, I think that we're better off _without_ code that hasn't been > thought through. > > More code, more people, more money. Why should I think they are good > things? > > The people, the projects, the companies that come though that test of > fire victorious are not only stronger for it, but more importantly, they > are the kind of people, projects adn companies who DID get through. > Dedicated. Smart. And careful. > > Think of rabbits. And think of how the wolf helps them in the end. Not > by being nice, no. But the rabbits breed, and they are better for having > to worry a bit. It cuts the other way as well though. If it is prohibitively hard and difficult to get fixes out for bugs in the Linux kernel, then companies will tend to choose other operating systems to run their applications on. I guarantee you that IT managers and CTOs do not share your enthusiasm for slow, correct coding when faced with their business being down, their revenue stream being interrupted and their stock options losing value. If you ignore those concerns then you may find that wolf at your door as IT managers choose other operating systems (e.g. FreeBSD, Solaris), kernel developers choose other operating systems to work on (e.g. FreeBSD), and Linux companies start going under. I'm really kind of surprised that companies like SuSE, VA and RedHat haven't started talking about forking the kernel already. Those companies are serving the administrators and managers whose needs you are openly admitting that you are not concerned with. For those companies the present state of affairs isn't sustainable. And I don't ask you to care about it. I guess my point is just that the linux kernel is an experiment in what happens when you ditch the managers and administrators and business-types and try to write a major software project entirely driven by developers. I will place a friendly wager that the experiment will show that not all the needs of those people are as dismissable as many software developers seem to think. - 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
Linus Torvalds writes: > On Wed, 6 Sep 2000, Alan Cox wrote: > > When was the last time you wrote a device driver for some warped piece of PCI > > technology that didn't work like the book says and for which you can neither > > get more info or pop over to the next cubicle and ask the hardware designer ? > > That would be the CardBus controller. Yeah, still fighting that one, > but we solved another bug today. Richard Gooch would have been able > to use a debugger for that one, but I don't know what he could have > done with one in that case. Well, it would have saved me several hours of inserting printk()s and rebooting to figure out where it was hanging. At one point I wasn't even sure if the yenta driver was hanging, or if it was causing another driver to hang. That would have gotten me to yenta_interrupt() quickly. Then it could have saved me more hours (and emails to you:-) if I could set traps and figure out what event masks were being read and whether clearing event masks would help (i.e. is it a device quirk or a driver bug?). So it would have gotten me faster to the point where I (or the bastard who wrote it:-) could sit back and think about *why* this was happening. I see the debugger as a tool for discarding the "obvious" ideas quickly. If you're lucky, it is an "obvious" (read: simple) bug and you can fix it there and then. If not, at least you've got some confidence that you haven't overlooked something at the local level, so it's worth investing the time thinking about the bigger picture. Personally, in my user-space code, I use the debugger rarely (don't need to: my code is almost perfect:-), because so often I don't need it. Either I see the equivalent of a BUG() and think "oh yeah, that's the foobar not frobbing the doohickey when we come in from this code path", or I get a SEGV and I just use the debugger to find out what function it happened in, so I know where to look and start thinking. Very occasionally I use it to inspect variables values. You can tell how rarely I do this by seeing how all my object code is compiled without -g. I have to go in and deliberately recompile to get more than a call trace. Even less often I single-step. Less than once a year (for a one-man part-time project of a couple of hundred thousand lines of code). But the important thing is that the debugger is available. I don't have to download the bloody thing. And certainly I don't have to keep downloading it because of bit-rot. For me, it brings me faster to the point where I sit down and think "why the fuck is it doing *that*?!?" and look at the bigger picture. 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: [PATCH?] Extended PTBL partition check for 2.4
On Thu, Sep 07, 2000 at 12:42:42AM +0200, Luca Montecchiani wrote:
> few ours ago I discover that my kernel 2.4.0-test8pre5 was unable to
> correctly identify the geometry of my second ide HD (*),
Always remember: a disk does not have a geometry.
> this is very bad
Why precisely?
> and fdisk come out with a lot of warnings
Ignore them if you do not also have DOS/Windows on the same disk.
> Follow the patch that works for me (tm):
>
> --- msdos.c.ORI Wed Jul 19 08:29:16 2000
> +++ msdos.c Wed Sep 6 23:46:29 2000
> @@ -398,9 +398,10 @@
> struct partition *q = &p[i];
> if (NR_SECTS(q)) {
> if ((q->sector & 63) == 1 &&
> - (q->end_sector & 63) == 63)
> + (q->end_sector & 63) == 63) {
> heads = q->end_head + 1;
> - break;
> + break;
> + }
> }
> }
> if (SYS_IND(p) == EZD_PARTITION) {
Yes, nothing wrong with your patch.
(There will be minor differences between 2.4.0 and 2.2.x and 2.0.x -
after writing the code for 2.3.21 or so, a largish change, I made
a smaller change to 2.2.14 and a still smaller change to 2.0.38.
That means that there will be people who see a different geometry
when they upgrade. That does not matter at all. On the one hand
one can always force a desired geometry by giving kernel boot
parameters or, for recent kernels, by echoing the desired numbers
to the appropriate /proc file. On the other hand, this geometry
only affects LILO and *fdisk. When there are LILO problems,
give the "linear" keyword or use a modern LILO. When fdisk warns
and there are no other operating systems on the same disk, ignore
the warnings. If there are, specify the desired geometry to fdisk.)
I think I prefer the current version over your patched version.
But will probably change my mind when many people complain.
Andries
-
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
On Wed, 06 Sep 2000, you wrote: > 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 the problems seems to be in the winbond driver (driver/isdn/hisax/w6692.[ch]) i tried to contact the author but the email address doen't exists anymore ([EMAIL PROTECTED]) could you help me ? ACPI and NE2000 seems to be ok... many thanx. -- -- bye, Guido Trentalancia please reply via email p.s. use gnupg ! ftp://ftp.gnupg.org use gnupg !...
Re: Fwd: ACPI & I4L irq confilct: bug reporting on kernel 2.4.0-test8-pre4
On Wed, 06 Sep 2000, you wrote: > On Wed, 6 Sep 2000, Guido Trentalancia wrote: > > On Wed, 06 Sep 2000, you wrote: > > > Guido Trentalancia schrieb: > > > > >Motherboard: ASUS P2B-F with the latest bios bx2f113.awd (microcode > > > > > update) ISDN: Winbond based card (Hisax type=36) > > > > >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 > > > > > > > > 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 > > > > 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. > > > > my bios irq settings are currently set to AUTO. > > i don't know why 3 resources (ne2k-pci, the winbond isdn module and the > > acpi) want the same irq 9 whereas there are a lot of free irqs... > > the manteiner of the ACPI driver sayd his driver is ok for irq > > sharing what about ne2k and winbond isdn ? i don't know how to > > contact the manteiners of this drivers > > The ne2k-pci driver will share IRQs. > The 'ne' driver will work for PCI cards, but is intended for ISA cards. It > will not share the IRQ. > > Documentation for the ne2k-pci driver is at >http://www.scyld.com/network/ne2k-pci.html > > > 1) ACPI > > 2) ISDN (Windbond - HiSax) > > 3) RealTek PCI NE2000 ethernet > > Is the ISDN card a PCI device? If not, it cannot share IRQs. yes it is > If it is a PCI device, the driver is broken. in fact this is the most probrably hypothesis of my problems this reply has been also forwarded to the author of the winbond driver (a guy from the czech republic) and to cornelius (many thanx for your comments). to confirm this hypotesis i can just compile the kernel with both acpi and ethernet but without the isdn driver. if irq sharing is ok then the problem must be in the file drivers/isdn/w6692.[ch] thanx a lot to everybody supporting linux and in particular to those who are helping me in this tedious problem. > > Donald Becker [EMAIL PROTECTED] > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Beowulf-II Cluster Distribution > Annapolis MD 21403 -- bye, Guido Trentalancia please reply via email: [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
Date: Wed, 6 Sep 2000 14:42:17 -0700 (PDT) From: Jonathan Walther <[EMAIL PROTECTED]> If the shared library is under GPL (not LGPL) that isn't a problem. No? Shared library linkage brings you into the same grey area that binary only kernel modules fall into, this means it's risky and this is almost certainly how the GCC team views this situation. Later, David S. Miller [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] linux-2.4.0-test7/driver/sbus/char/vfc_dev.c
Date:Tue, 5 Sep 2000 22:53:23 +0200 (CEST) From: Philipp Matthias Hahn <[EMAIL PROTECTED]> 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: Patch applied, but this driver is very unlikely to work at all. Later, David S. Miller [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] exporting IPv6 symbols
Date: Wed, 6 Sep 2000 14:15:08 +0300 (EEST) From: "Pekka Riikonen [Adm]" <[EMAIL PROTECTED]> I think that interface programmers should think whether their public interfaces might be needed from the modules and export symbols accordingly. Yes, but only when actually used. The ipv4 counterparts are exported because, lo' and behold, ipv6 makes use of them. Let's wait until your work is integrated into the kernel tree, or some other similar project, which makes use of these symbols. That is the appropriate time at which to decide what we export for modules. Later, David S. Miller [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: Availability of kdb
On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > How do you tell a customer who is giving you money to "be careful" when > their system crashes and the field service rep hasn't a clue as to > what's wrong? I've been supporting computer customers for over 20 > years, and this is not an answer that will give them warm and fuzzy > feelings about using your solution if you have no way of solving > problems quickly. so you add kdb to the kernel you ship to customers, teach your reps how to use it.. and hey presto. linus et al are happy cause the standard kernel is pure. you're happy cause your field reps in the event of a crash can tell you "this exact bit here was fubar'ed." whereupon you may apply the Ingo/Al/Linus/David patented MKDB method. regards, -- Paul Jakma [EMAIL PROTECTED] PGP5 key: http://www.clubi.ie/jakma/publickey.txt --- Fortune: panic: can't find / - 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/
VIA IDE Driver Problems, test8-pre5 & 6.
I'm having a problem with the new VIA IDE controller.
It initializes my drives correctly, then proceeds to start up the operating
system, gets to about crond, then the drive halts for about 30 seconds with its
light on solid. After 30 seconds, it says DMA timed out and disables DMA.
This does not happen on 2.4.0-test7, and DMA works like a charm.
Here's a boot log starting with IDE (and me hitting Alt+SysRq a couple of times):
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
hda: Maxtor 91303D6, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hdc: Pioneer DVD-ROM ATAPIModel DVD-115 0111, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 25450992 sectors (13031 MB) w/512KiB Cache, CHS=1584/255/63, UDMA(33)
hdc: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.11
Partition check:
hda: hda1 hda2
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
udf: registering filesystem
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP
enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
ttyS04 at port 0xec00 (irq = 5) is a 16550A
PPP generic driver version 2.4.1
PPP Deflate Compression module registered
PPP BSD Compression module registered
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 96M
agpgart: Detected Via Apollo Pro KX133 chipset
agpgart: AGP aperture is 32M @ 0xd000
[drm] AGP 0.99 on VIA Apollo KX133 @ 0xd000 32MB
[drm] Initialized mga 1.0.0 2719 on minor 63
ISAPnP reports AWE64 WaveTable at i/o 0x620
Soundblaster audio driver Copyright (C) by Hannu
Savolainen 1993-1996
sb: Creative SB AWE64 PnP detected
sb: ISAPnP reports 'Creative SB AWE64 PnP' at i/o 0x220, irq 10, dma 1, 5
sb: 1 Soundblaster PnP card(s) found.
kmem_create: Forcing size word alignment - nfs_fh
VFS: Mounted root (ext2 filesystem) readonly.
named startup succeeded
sshd startup succeeded
EIP: 0010:[default_idle+35/48] EFLAGS: 0246
EAX: EBX: c0108740 ECX: c1258250 EDX: c1258250
ESI: c029c000 EDI: c0108740 EBP: 0008e000 DS: 0018 ES: 0018
CR0: 8005003b CR2: 4006ded0 CR3: 013f7000 CR4: 0090
<30-second delay>
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hda: status timeout: status=0xd0 { Busy }
hda: DMA disabled
hda: drive not ready for command
ide0: reset: success
crond startup succeeded
...
- - -
With the old VIA driver, it did this:
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VT 8371
Chipset Core ATA-66
Split FIFO Configuration: 8 Primary buffers, threshold = 1/2
8 Second. buffers, threshold = 1/2
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
ide0: VIA Bus-Master (U)DMA Timing Config Success
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
ide1: VIA Bus-Master (U)DMA Timing Config Success
hda: Maxtor 91303D6, ATA DISK drive
hdc: Pioneer DVD-ROM ATAPIModel DVD-115 0111, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 25450992 sectors (13031 MB) w/512KiB Cache, CHS=1584/255/63, UDMA(33)
hdc: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.11
Partition check:
hda: hda1 hda2
and functioned pretty much normally.
Any ideas?
-Byron
--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [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/
Is it OK to release non-GPL network driver with source?
My company is currently working on a linux network driver (I'm sorry, but I can't disclose which company or the nature of the driver right now). However, recent discussions on this list have made me grow concerned about licensing problems with the GPL. The source code for the driver _is_ going to be available, but it will not be GPL'd. There are no patches to the kernel involved. I understand that there should be no problems, but the use of inline functions in the kernel header files makes the situation a bit more complicated. The compiled binary code then does contain GPL'd code, so would it not then be considered a "derivative work"? If indeed this is a violation of the GPL, is there any way around this by releasing only the source code (even though it isn't GPL'd)? I mean, the compiled binary code does contain GPL'd code, but the source code does not. Is it OK to distribute this? So, I'm asking the experts here for opinions or insights. -- Dave Allen [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: Availability of kdb
Linus Torvalds wrote: > > On Wed, 6 Sep 2000, Alan Cox wrote: > > > > > > What would a debugger have done? > > > > Let the end user give me essential answers on what was happening at the failure > > point. Think of it as a crash dump tool with extra controls > > Sure. I just don't see many end-users single-stepping through interrupt > handlers etc. > > But yes, there probably are a few. > > But problems that tend to be hard to debug are things that don't happen > all the time. Or require special timing to happen. And I don't think > you'll find that those are very easy to attach to with a debugger either. > So the guy at the debugger end has to be really good. > > Basically, I'd hate to depend on that. Then why not allow more complex post-failure analysis tools into the kernel as an option to debuggers? I agree that debugging should not act as a crutch for poor design up front, but at the same time, once you ship a product, you can't just ask the customer to "drop down into the debugger and give me a stack trace". If the system doesn't save the crash state for you, you might as well wave a magic wand over the system or pray that someone can read an Oops report. --Matt - 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/
Bug with EtherExpress on 2.4.0 test 7
All, We have been doing some testing with 2.4 and we are running into problems with the EtherExpress Driver. Symptoms: On some reboots it reports eth0 is out of resources. Also during heavy loads it will report being out of resources and the system drops of the network. The warning is printed on the status check at line 1576 of drivers/net/eepro100.c (linux-2.4.0-test7). We changed to a tulip based network card and have not been able to reproduce the problem. Let me know if additional information is needed, -- === Josue Emmanuel Amaro Linux Products Manager Oracle Corporation === begin:vcard n:Amaro;Josue Emmanuel tel;cell:650-245-5131 tel;fax:650-506-7369 tel;work:650-506-1239 x-mozilla-html:FALSE url:http://www.oracle.com org:Linux Strategic Business Unit version:2.1 email;internet:[EMAIL PROTECTED] title:Sr.Product Line Manager adr;quoted-printable:;;500 Oracle Parkway=0D=0AMS 1op7;Redwood Shores;CA;94065;United States fn:Josue Emmanuel Amaro end:vcard
Re: [OT] incremental patch of two patches?
On Thu, 7 Sep 2000, Jorge Nerin wrote: > This is a little offtopic, but as everybody here uses patches everyday,, > someone migth have an answer for this. > > How can I make a incremental patch of two other patches without making > two trees? have a look at interdiff (http://people.redhat.com/twaugh/interdiff/) c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) - 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 kernel Eth0 Errors
All- Sorry for the newbie-ish question, but today I installed the 2.4 test kernel with the following distributions: Caldera Linux Technology Preview Redhat 7.0 beta (pinstripe) Now, after install, I keep getting slammed with the following errors: eth0 card reports no RX buffers eth0 card reports no resources Put it to say i am at a loss, here is the hardware: Compaq ML350 Intel Dual 733 512 meg ram Compaq NC3163 Fast Ethernet NIC (embedded) PCI 10/100 WOL (Wake On LAN) Integrated ATI Rage IIC Video Controller with 4MB Video Memory 9.1 GB Wide Ultra2 (7200 rpm) 1" Any pointers or help would be appreciated. -Jesse Noller - 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] arcnet/com20020-isa.c - compile fix
The 'clock' field was removed from the arcnet_local struct somewhere recently, and was replaced by clockp. arcnet/com20020-isa.c still uses 'clock' somewhere, so we got a compile error. No maintainer for arcnet was mentioned in MAINTAINERS, So here's the fix, to be applied to test8-pre5: --- linux/drivers/net/arcnet/com20020-isa.c Sat May 13 17:50:25 2000 +++ linux.vanilla/drivers/net/arcnet/com20020-isa.c Tue Sep 5 22:53:18 2000 @@ -205,7 +205,7 @@ case 6: /* Timeout */ lp->timeout = ints[6]; case 5: /* CKP value */ - lp->clock = ints[5]; + lp->clockp = ints[5]; case 4: /* Backplane flag */ lp->backplane = ints[4]; case 3: /* Node ID */ Dan Aloni (dax) | "At first I was afraid, I was petrified ; [EMAIL PROTECTED] | Kept thinking why I'd get this Oops [EMAIL PROTECTED] | when your patch was applied" ... - 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?] Extended PTBL partition check for 2.4
Hi,
few ours ago I discover that my kernel 2.4.0-test8pre5 was unable to
correctly identify the geometry of my second ide HD (*), this is very
bad and fdisk come out with a lot of warnings, see:
Disk /dev/hdc: 16 heads, 63 sectors, 6296 cylinders
Units = cylinders of 1008 * 512 bytes
Device BootStart EndBlocks Id System
/dev/hdc1 1 2032 1024127+ 83 Linux
Partition 1 does not end on cylinder boundary:
phys=(253, 127, 63) should be (253, 15, 63)
/dev/hdc2 2033 2296133056 82 Linux swap
Partition 2 does not end on cylinder boundary:
phys=(286, 127, 63) should be (286, 15, 63)
/dev/hdc4 2297 6296 20160005 Extended
Partition 4 does not end on cylinder boundary:
phys=(786, 127, 63) should be (786, 15, 63)
/dev/hdc5 2297 2704205631+ 83 Linux
/dev/hdc6 2705 6296 1810367+ 83 Linux
This is how the kernel see the world:
hda: 26520480 sectors (13578 MB) w/1966KiB Cache, CHS=1650/255/63, (U)DMA
hdc: 6346368 sectors (3249 MB) w/96KiB Cache, CHS=6296/16/63, DMA
Partition check:
hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
hdc: hdc1 hdc2 hdc4 < hdc5 hdc6 >
Booting with 2.2.17 everything work fine, that kernel correctly
identify the [PTBL] nature of my hdc and apply all the necessary
conversion see:
hda: IBM-DJNA-371350, 12949MB w/1966kB Cache, CHS=1650/255/63
hdc: IBM-DAQA-33240, 3098MB w/96kB Cache, CHS=6296/16/63
Partition check:
hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
hdc: [PTBL] [787/128/63] hdc1 hdc2 hdc4 < hdc5 hdc6 >
fdisk is a lot happy now:
Disk /dev/hdc: 128 heads, 63 sectors, 787 cylinders
Units = cylinders of 8064 * 512 bytes
Device BootStart EndBlocks Id System
/dev/hdc1 1 254 1024127+ 83 Linux
/dev/hdc2 255 287133056 82 Linux swap
/dev/hdc4 288 787 20160005 Extended
/dev/hdc5 288 338205631+ 83 Linux
/dev/hdc6 339 787 1810367+ 83 Linux
Ok, to the code.
2.2.17/drivers/block/genhd.c :
for (i = 0; i < 4; i++) {
struct partition *q = &p[i];
if (NR_SECTS(q)
&& (q->sector & 63) == 1
&& (q->end_sector & 63) == 63) {
unsigned int heads = q->end_head + 1;
if (heads == 32 || heads == 64 ||
heads == 128 || heads == 240 ||
heads == 255) {
(void) ide_xlate_1024(dev, heads, " [PTBL]");
break;
}
}
2.4.0-pre8/fs/partitions/msdos.c :
for (i = 0; i < 4; i++) {
struct partition *q = &p[i];
if (NR_SECTS(q)) {
if ((q->sector & 63) == 1 &&
(q->end_sector & 63) == 63)
heads = q->end_head + 1;
break;
}
}
Debugging the code show that 2.4.0 always exit at the first
valid partition found, discarding the remaining ones and
to early to identify the PTBL nature of my hdc disk.
this is what 2.4.0-pre8 does:
i=0 NR=2048255 q->sector=2 q->end_sector=63 q->end_head=127
break
this is what 2.2.17 does:
i=0 NR=2048255 q->sector=2 q->end_sector=63 q->end_head=127
i=1 NR=266112 q->sector=1 q->end_sector=127 q->end_head=127 PTBL!
break
Follow the patch that works for me (tm):
--- msdos.c.ORI Wed Jul 19 08:29:16 2000
+++ msdos.c Wed Sep 6 23:46:29 2000
@@ -398,9 +398,10 @@
struct partition *q = &p[i];
if (NR_SECTS(q)) {
if ((q->sector & 63) == 1 &&
- (q->end_sector & 63) == 63)
+ (q->end_sector & 63) == 63) {
heads = q->end_head + 1;
- break;
+ break;
+ }
}
}
if (SYS_IND(p) == EZD_PARTITION) {
Seem that 2.4.0test8 follow the PTBL definition described
in the Large-Disk-HOWTO, only primary partition, 2.2.17 instead
extend the check all over the four partition.
(*) The hdc disk was autopartitioned by sfdisk over a 2.2.17
kernel
comments ?
luca
--
--
E-mail..: Luca Montecchiani <[EMAIL PROTECTED]>
W.W.W...: http://i.am/m.luca - http://luca.myip.org
Speakfreely.: sflwl -hlwl.fourmilab.ch luca@
I.C.Q...: 17655604
---=(Linux since 1995)=---
Non esiste vento favorevole per il marinaio che non sa dove andare
Seneca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Linux-2.4.0-test8-pre6
Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that we fixed it now several times, and I was always wrong. Time for some reverse phychology: I'm sure this one doesn't fix the truncate bug either. But I have this ugly feeling that I'm coming down with the same flu that everybody else in my family had the last week, so I'd better release this before I start puking on my keyboard. Linus test8: - pre1 - Oops. Moved back stallion.c to drivers/char. It's not a TV driver. Never has been, and I don't see it ever really becoming one ;) - mca.c: outp_b() should be outb_p(). Obviously nobody actually _uses_ the MCA bus any more ;) - umsdos should be ok again after the page_address() type-changes. - re-enable asynchronous read-ahead code. - Sun ESP driver update - netfilter debug fixes - IPv6 needs to register before proto_init() - socket() error code fix (EAFNOSUPPORT instead of EINVAL) - potential TCP socket leak fix - don't self-deadlock on the kbd_controller_lock when probing for the mouse - CONFIG_SMB_NLS_REMOTE didn't work. Silly typo. - scheduler wakeup race condition could cause delayed scheduling on SMP.. - net/packet/af_packet.c: use the standard macros for marking page resevredness - ncpfs buffer-overflow fix - thread groups, take 1. - USB storage driver update - pre2 - The TCP socket leak patch _really_ went in this time. - get rid of more suser() checks in networking.. It's "capable(CAP_NET_ADMIN)". - sparc updates - alpha updates. Fast alpha xor for raid. AP1000 updates. - Wonders never cease. digiboard driver updates. Christoph Lameter is BAAACK! - SiS frame buffer driver updates. Can be used without a BIOS. - nfsd interface cleanup. - fix potential buffer overruns in get_partition_list. Remove limitation of one page. - floppy driver capability cleanups. Use "request_region()". - handle dcache flushing when there are shared user mappings that may be dirty. - get rid of the "_ret()" user access macros. They are more complex than just doing the return directly and they hide what's going on. - fix up broken BIOSes that don't give unique ID's to different APICs - make more of the drm drivers compile on other platforms and know about the signal blocking issues. - net/atm/mpoa_proc.c: user-space access thinko - pcmcia: David Hinds: merge updates from 3.1.20 - pcmcia: non-ISA machines really shouldn't use ISA interrupts ;) - ext2: truncate races and error code return fixes - true shared signals for pthreads.. - pre3: - ext2: final truncate piece - fix the innd problem. - use "sfence" for x86 memory barrier when available. - remove the thread-group signal code for now: no feedback. Leave the cleanups in place so that we can add it back in cleanly later, but remove the new features. - ARM update. - released for Al Viro to check the truncate thing - pre4: - truncate really fixed this time. Everybody agrees. - 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) - network driver fixes (not checking for oom etc) - USB serial driver SMP locking fixes - fix memory leak on failed USB configuration queries - USB initialization using proper "init()" calls. - dvd capacity bug fix and other cdrom driver cleanups - sis5513 IDE chipset update - do_fork() - add "stack-top" for ia64 (and potentially other architectures that may care) - devfs support for LVM - quota transfer miscount fix - x86 checksum/copy prefetch - NFS sillydelete fix - mark_buffer_dirty() doesn't actually use the second argument. Delete it. - SCSI communications device - no need to complain about it - SCSI WP test fix (all pages, not just the first one) - epic driver update - fix pcmcia "driver asserts interrupts when booting up" issues - pre6: - trunate - the never-ending story. Makes me feel like a long Kurosawa movie. But in this one the hero _will_ survive, or my name isn't Maxwell. - SCSI tape driver potential memory leak. - XMM FP handler bug fix: we really must not change the FP error mask on exceptions. People care. - 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
None of my arguments for kernel debuggers add up to "add new things faster". If you want to be able to add new things faster than you need to radically restructure systems and your implementation process to better accommodate modularization; a different process altogether. My arguments for kernel debuggers add up to "understand the symptomological behavior faster." It has to do with reducing the overhead on those who are doing maintenance so that they will have the time to do the thinking necessary for doing the implementation right. Some people don't need these tools, and more power to them. The vast majority of programmers, including many of the careful effective ones you do want (or should want) contributing to your system, do. You can not social-engineer competence by depriving people of tools. You can reinforce competence by giving them tools and teaching them how and when to use them. We've done device driver development here, and absolutely needed the visibility provided by a kernel debugger because the hardware was broken or poorly documented and no amount of staring at source code would have helped us recognize that. I've used kernel data gathering and visualization any number of times to identify complex interactions of subsystems that no amount of staring at code would have uncovered. Doing so has allowed me to fix kernel problems in hours that would have taken months to fix otherwise - hours because it took minutes to correctly identify the bogus behavior and then hours to work through the code and figure out the best solution. There simply isn't "one right way" to do anything, even kernel development. -Original Message- From: Linus Torvalds [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 06, 2000 12:52 PM To: Tigran Aivazian Cc: Daniel Phillips; Mike Galbraith; [EMAIL PROTECTED] Subject: Re: Availability of kdb On Wed, 6 Sep 2000, Tigran Aivazian wrote: > > 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? I don't like debuggers. Never have, probably never will. I use gdb all the time, but I tend to use it not as a debugger, but as a disassembler on steroids that you can program. None of the arguments for a kernel debugger has touched me in the least. And trust me, over the years I've heard quite a lot of them. In the end, they tend to boil down to basically: - it would be so much easier to do development, and we'd be able to add new things faster. And quite frankly, I don't care. I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing. Apparently, if you follow the arguments, not having a kernel debugger leads to various maladies: - you crash when something goes wrong, and you fsck and it takes forever and you get frustrated. - people have given up on Linux kernel programming because it's too hard and too time-consuming - it takes longer to create new features. And nobody has explained to me why these are _bad_ things. To me, it's not a bug, it's a feature. Not only is it documented, but it's _good_, so it obviously cannot be a bug. "Takes longer to create new features" - this one in particular is not a very strong argument for having a debugger. It's not as if lack of features or new code would be a problem for Linux, or, in fact, for the software industry as a whole. Quite the reverse. My biggest job is to say "no" to new features, not trying to find them. Oh. And sure, when things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger. Quite frankly, I'd rather weed out the people who don't start being careful early rather than late. That sounds callous, and by God, it _is_ callous. But it's not the kind of "if you can't stand the heat, get out the the kitchen" kind of remark that some people take it for. No, it's something much more deeper: I'd rather not work with people who aren't careful. It's darwinism in software development. It's a cold, callous argument that says that there are two kinds of people, and I'd rather not work with the second kind. Live with it. I'm a bastard. I have absolutely no clue why people can ever think otherwise. Yet they do. People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work if it just results in what I consider to be a better system. And I'm not just saying that. I'm really not a very nice person. I can say "I don't care" with a straight
[patch-2.4.0-test8-pre5] take #2 on rtc fixes
Hi Linus,
Thanks to Jeff Garzik I slightly improved the patch (by returning the
proper err codes always). So, to reiterate:
The rtc driver does:
a) not handle failures from misc_register() gracefully
b) not handle failures from create_proc_read_entry() gracefully
c) use check_region() where request_region() would suffice
d) not use KERN_ERR priority for errors consistently
e) initialises some static variables to 0 unnecessarily
The patch below fixes these issues/bugs. Tested under 2.4.0-test8-pre5.
Regards,
Tigran
--- 240-test8-p5/drivers/char/rtc.c Fri Jul 28 09:58:59 2000
+++ linux/drivers/char/rtc.cWed Sep 6 15:16:11 2000
@@ -39,9 +39,10 @@
* 1.10a Andrea Arcangeli: Alpha updates
* 1.10b Andrew Morton: SMP lock fix
* 1.10c Cesar Barros: SMP locking fixes and cleanup
+ * 1.10d Tigran Aivazian: Restructured rtc_init and got rid of check_region
*/
-#define RTC_VERSION"1.10c"
+#define RTC_VERSION"1.10d"
#define RTC_IO_EXTENT 0x10/* Only really two ports, but...*/
@@ -132,9 +133,9 @@
* rtc_status but before mod_timer is called, which would then reenable the
* timer (but you would need to have an awful timing before you'd trip on it)
*/
-static unsigned long rtc_status = 0; /* bitmapped status byte. */
-static unsigned long rtc_freq = 0; /* Current periodic IRQ rate*/
-static unsigned long rtc_irq_data = 0; /* our output to the world */
+static unsigned long rtc_status; /* bitmapped status byte. */
+static unsigned long rtc_freq; /* Current periodic IRQ rate*/
+static unsigned long rtc_irq_data; /* our output to the world */
/*
* If this driver ever becomes modularised, it will be really nice
@@ -615,6 +616,7 @@
static int __init rtc_init(void)
{
+ int ret;
#if defined(__alpha__) || defined(__mips__)
unsigned int year, ctrl;
unsigned long uip_watchdog;
@@ -625,6 +627,17 @@
struct linux_ebus_device *edev;
#endif
+ ret = misc_register(&rtc_dev);
+ if (ret) {
+ printk(KERN_ERR "rtc: cannot misc_register on minor=%d\n", RTC_MINOR);
+ goto out;
+ }
+ if (!create_proc_read_entry("driver/rtc", 0, 0, rtc_read_proc, NULL)) {
+ printk(KERN_ERR "rtc: cannot create file /proc/driver/rtc\n");
+ ret = -ENOMEM;
+ goto outmisc;
+ }
+
#ifdef __sparc__
for_each_ebus(ebus) {
for_each_ebusdev(edev, ebus) {
@@ -633,8 +646,9 @@
}
}
}
- printk("rtc_init: no PC rtc found\n");
- return -EIO;
+ printk(KERN_ERR "rtc: no PC rtc found\n");
+ ret = -ENODEV;
+ goto outproc;
found:
rtc_port = edev->resource[0].start;
@@ -644,35 +658,34 @@
* PCI Slot 2 INTA# (and some INTx# in Slot 1). SA_INTERRUPT here
* is asking for trouble with add-on boards. Change to SA_SHIRQ.
*/
- if(request_irq(rtc_irq, rtc_interrupt, SA_INTERRUPT, "rtc", (void
*)&rtc_port)) {
+ ret = request_irq(rtc_irq, rtc_interrupt, SA_INTERRUPT, "rtc", (void
+*)&rtc_port);
+ if(ret) {
/*
* Standard way for sparc to print irq's is to use
* __irq_itoa(). I think for EBus it's ok to use %d.
*/
- printk("rtc: cannot register IRQ %d\n", rtc_irq);
- return -EIO;
+ printk(KERN_ERR "rtc: cannot register IRQ %d\n", rtc_irq);
+ goto outproc;
}
#else
- if (check_region (RTC_PORT (0), RTC_IO_EXTENT))
- {
- printk(KERN_ERR "rtc: I/O port %d is not free.\n", RTC_PORT (0));
- return -EIO;
+ if (!request_region(RTC_PORT (0), RTC_IO_EXTENT, "rtc")) {
+ printk(KERN_ERR "rtc: I/O port %d is not free\n", RTC_PORT (0));
+ ret = -EBUSY;
+ goto outproc;
}
#if RTC_IRQ
- if(request_irq(RTC_IRQ, rtc_interrupt, SA_INTERRUPT, "rtc", NULL))
- {
+ ret = request_irq(RTC_IRQ, rtc_interrupt, SA_INTERRUPT, "rtc", NULL);
+ if(ret) {
/* Yeah right, seeing as irq 8 doesn't even hit the bus. */
- printk(KERN_ERR "rtc: IRQ %d is not free.\n", RTC_IRQ);
- return -EIO;
+ printk(KERN_ERR "rtc: IRQ %d is not free\n", RTC_IRQ);
+ release_region(RTC_PORT (0), RTC_IO_EXTENT);
+ goto outproc;
}
#endif
- request_region(RTC_PORT(0), RTC_IO_EXTENT, "rtc");
#endif /* __sparc__ vs. others */
- misc_register(&rtc_dev);
- create_proc_read_entry ("driver/rtc", 0, 0, rtc_read_proc, NULL);
#if defined(__alpha__) || defined(__mips__)
rtc_freq = HZ;
@@ -716,34 +729,41 @@
rtc_freq = 1024;
#endif
+ ret = 0;
printk(KERN_INFO "Real Time Clock Driver v" RTC_VERSION "\n");
+out:
+ return
Re: [OT] incremental patch of two patches?
On Thu, 7 Sep 2000, Jorge Nerin wrote: > How can I make a incremental patch of two other patches without > making two trees? > I think that this can be done without even using the original > tree, only using the patches, but I cant find a way. You want interdiff(1) Go to freshmeat.net and search for `interdiff' 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: Availability of kdb
Marty Fouts wrote: > > > > While I think that Merkey has a skewed view and an axe to grind, I think > that the level of optimism on the other side borders on the naïve. > > They are not naive, just young, and the young don't know what they cannot do yet, and this gives them the ability to achive the impossible at times -- don't fault them for that. I have no axe to grind, but I do have a different view. I'm the 1 in 30 million men born with an extra Y chromosone (a double YY), so you are pertially right there. DOuble YY males have a different brain structure -- the lymbic system in my brain is so electrically active, it qualifies as a third brain. Normal humans have two brains, left and right. Like most double YY's I have three, left, right, lymbic. Fortunately for me, my frontal lobes are normal and do not exhibit the wiring problems that afflict 60% of double YY's, such as an uncontrollable urge to take an axe and chop someone to pieces because they pissed me off. Famous double YY's of history: Good: Nikolov Tesla Thomas Edison Albert Einstein Nostradomos (DNA analysis of remains in his grave) Bad: Charlse Manson Jack the Ripper (DNA analysis of 1800's evidence) Ted Bundy Jeffrey Dahmer My view is different, not skewed... :-) Jeff - 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
On Wed, 6 Sep 2000, Alan Cox wrote: > > > > What would a debugger have done? > > Let the end user give me essential answers on what was happening at the failure > point. Think of it as a crash dump tool with extra controls Sure. I just don't see many end-users single-stepping through interrupt handlers etc. But yes, there probably are a few. But problems that tend to be hard to debug are things that don't happen all the time. Or require special timing to happen. And I don't think you'll find that those are very easy to attach to with a debugger either. So the guy at the debugger end has to be really good. Basically, I'd hate to depend on that. > When was the last time you wrote a device driver for some warped piece of PCI > technology that didn't work like the book says and for which you can neither > get more info or pop over to the next cubicle and ask the hardware designer ? That would be the CardBus controller. Yeah, still fighting that one, but we solved another bug today. Richard Gooch would have been able to use a debugger for that one, but I don't know what he could have done with one in that case. 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/
[OT] incremental patch of two patches?
This is a little offtopic, but as everybody here uses patches everyday,, someone migth have an answer for this. How can I make a incremental patch of two other patches without making two trees? Let me explain, I want to know what has changed between test8-pre4 and test8-pre5, I remember sometime ago that this question or something similar has been answered, but the infamous truncate but bit some of my mailboxes and I can't find it. I think that this can be done without even using the original tree, only using the patches, but I cant find a way. Thanks. -- Jorge Nerin <[EMAIL PROTECTED]> <[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: Compiler warnings
> Out of curiousity, which compiler would you recommend for IA64 kernels? > The latest unwind code is in the bleeding edge version of gcc, which > just happens to have the problems with '##' as well. Im not familiar with the needs for the IA64 tree - 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
> Ehh? And exactly _how_ would a debugger help it. > > Especially as Alan quoted an example of a driver bug that didn't get fixed > for several months because the maintainer didn't have the hardware. > > What would a debugger have done? Let the end user give me essential answers on what was happening at the failure point. Think of it as a crash dump tool with extra controls > Testing is important for device drivers. Debuggers are not. When was the last time you wrote a device driver for some warped piece of PCI technology that didn't work like the book says and for which you can neither get more info or pop over to the next cubicle and ask the hardware designer ? Alan - 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: Compiler warnings
On Thu, Sep 07, 2000 at 08:53:29AM +1100, Keith Owens wrote: > On Wed, 6 Sep 2000 21:49:44 +0100 (BST), > Alan Cox <[EMAIL PROTECTED]> wrote: > >Use a different gcc. There are reasons people shipping 2.96 for intel x86 also > >include egcs. The kernel isnt ready for 2.96 > > Out of curiousity, which compiler would you recommend for IA64 kernels? > The latest unwind code is in the bleeding edge version of gcc, which > just happens to have the problems with '##' as well. Obviously 2.96. I'm using it for 2.4 x86 and sparc64 kernels as well. We were talking about 2.2.17 though, and I don't think 2.2 kernels work on ia64... If you want the '##' fix, grab http://gcc.gnu.org/ml/gcc-patches/2000-09/msg6.html Jakub - 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: modules directory
On Wed, 6 Sep 2000 18:07:13 -0400 (EDT), "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: >Ahaa! Aye... Does this imply that there will, in the future, be >other than '/kernel/drivers' as modules? Or is this (I fear) another >change that; "Doesn't have to be better, only different..." /lib/modules/`uname -r`/ modules.dep modules.pcimap System.map .config Any other text files that are kernel specific build symlink kernel/ modules that came from the kernel source tree pcmcia/ modules from external pcmcia package xyz/ modules from third party xyz package, e.g. vmware The old method of mixing multiple sources into fs/, drivers/ net/ etc. made it impossible to clean out old kernel modules automatically during make modules_install. A common class of problem was caused by old modules when somebody changed an option from a module to in kernel but did not clean out the old modules first. Not any more. The old modules_install method relied on human definition of the mapping from source tree to fs/, net/, misc/ etc. Kernel developers got this wrong all the time, which is why half the modules incorrectly ended up in misc/. Even worse, you could have multiple copies of modules, on in say fs/, the other in misc/ and you never knew which one was being used. Not any more. - 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 have been involved in the freely-distributable software community since 1975. (Yes, Virginia, it predates the Free Software Foundation, and, in fact, can be traced back to the '50s.) Freely-distributable software has some advantages, but I didn't see then and I don't see now any path by which it will replace commercial software development. Anyone who thinks that IBM, HP, et al adopting Linux is evidence to the contrary doesn't understand the lesson of the Open Software Foundation. It is fun to participate in this list, and, if I could find the synergy, I would be willing to direct my current company (which is using Linux) to develop some enhancements to Linux (that we might need as part of our product development) and to contribute those enhancements to the community. (That's why I subscribed, to find out what we could expect from Linux and what we could contribute.) I even have some long range projects that I might be willing to pay "Linux kernel experts" to do for me and then contribute to the community. What I'm trying to say is that I'd like to see Linux and Free BSD and the FSF and so on all to succeed at what they are trying to do, but I haven't seen anything change in 25 years that make me think that y'all are having any fundamental impact on the economics of software development. While I think that Merkey has a skewed view and an axe to grind, I think that the level of optimism on the other side borders on the naïve. -Original Message- From: Tigran Aivazian [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 06, 2000 1:57 PM To: Jeff V. Merkey Cc: Linus Torvalds; Daniel Phillips; Mike Galbraith; [EMAIL PROTECTED] Subject: Re: Availability of kdb On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > Then it may be that corporate America weeds out Linux over more likely is that corporate America weeds out commercial software as a model which was superseded by the free software. We (the creative anarchy community led by Linus) are here to help that happen, gradually and slowly without shocks and fits by those who love this world and the things that are therein so much they choose to serve Mammon and make money on that which should be inherently free (to wit, any form of information, isn't it just 1s and 0s? :) Regards, Tigran PS. If Linus objects to being a leader of such community, I may remind that the keyword there is "anarchy" and that assumes that, to some extent, the consent of a human to be or not to be its leader, may be freely ignored by those being lead, without even disturbing the symbiotic harmony between the leader and those he leads. - 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: modules directory
On Thu, 7 Sep 2000, Keith Owens wrote: > On Wed, 6 Sep 2000 15:09:02 -0400 (EDT), > Andrew Park <[EMAIL PROTECTED]> wrote: > >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? > > > Why don't you look in linux/Documentation/Changes? That file exist > precisely to stop repeated questions like this on the linux kernel > developers list. > > Ahaa! Aye... Does this imply that there will, in the future, be other than '/kernel/drivers' as modules? Or is this (I fear) another change that; "Doesn't have to be better, only different..." Remember Linus' comment about reorganization? 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/
[Fwd: help requested posting to linux-kernel]
Eric Buddington wrote: > David Ford, > > I seek your help posting to linux-kernel. Would you kindly forward this if > indeed [EMAIL PROTECTED] is still the right address? > > I am attempting to report a Linux bug, as you will see below. I get 'user > unknown' with no explanation (not obviously ORBS-related) whether sending > from my university account (blacklisted), my dial-up IP, or my ISP's relay > host (neither ORBS-listed). Trying to subscribe via > [EMAIL PROTECTED] gives the same 'user unknown'. > > Thanks for your help, if you're willing. > > -Eric > > - Forwarded message from Mail Delivery Subsystem ><[EMAIL PROTECTED]> - > > Envelope-to: [EMAIL PROTECTED] > Date: Wed, 6 Sep 2000 17:32:23 -0400 (EDT) > From: Mail Delivery Subsystem <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: Returned mail: see transcript for details > Auto-Submitted: auto-generated (failure) > > The original message was received at Wed, 6 Sep 2000 17:32:08 -0400 (EDT) > from [EMAIL PROTECTED] [24.51.237.159] > >- The following addresses had permanent fatal errors - > <[EMAIL PROTECTED]> > (reason: 550 <[EMAIL PROTECTED]>... User unknown) > >- Transcript of session follows - > ... while talking to vger.rutgers.edu.: > >>> RCPT To:<[EMAIL PROTECTED]> > <<< 550 <[EMAIL PROTECTED]>... User unknown > 550 5.1.1 <[EMAIL PROTECTED]>... User unknown > > Reporting-MTA: dns; mx1.buf.adelphia.net > Received-From-MTA: DNS; ma-northadams1-415.nad.adelphia.net > Arrival-Date: Wed, 6 Sep 2000 17:32:08 -0400 (EDT) > > Final-Recipient: RFC822; [EMAIL PROTECTED] > Action: failed > Status: 5.1.1 > Remote-MTA: DNS; vger.rutgers.edu > Diagnostic-Code: SMTP; 550 <[EMAIL PROTECTED]>... User unknown > Last-Attempt-Date: Wed, 6 Sep 2000 17:32:23 -0400 (EDT) > > Date: Wed, 6 Sep 2000 17:34:10 -0400 > From: Eric Buddington <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: 2.4.0-test7 reboots after uncompress on 486SX > Reply-To: [EMAIL PROTECTED] > User-Agent: Mutt/1.0.1i > Organization: ECS Labs > X-Eric-Conspiracy: there is no conspiracy > > 486 SX/25 trying to run Linux 2.4.0-test7, no patches. Compiled for > nfs-root with most things as modules. > > The kernel loads (via GRUB) and uncompresses itself, then immediately > reboots. No boot messages show up after the uncompressing message. > > I tried compiling for i386 and i486. Both showed his behavior. > > My Debian 2.2.15 kernel boots as expected on this machine. > > -Eric > > - End forwarded message - -- "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:;28256 fn:David Ford end:vcard
Re: Fwd: ACPI & I4L irq confilct: bug reporting on kernel 2.4.0-test8-pre4
On Wed, 6 Sep 2000, Guido Trentalancia wrote: > On Wed, 06 Sep 2000, you wrote: > > Guido Trentalancia schrieb: > > > >Motherboard: ASUS P2B-F with the latest bios bx2f113.awd (microcode > > > > update) ISDN: Winbond based card (Hisax type=36) > > > >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 > > > 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 > > > 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. > my bios irq settings are currently set to AUTO. > i don't know why 3 resources (ne2k-pci, the winbond isdn module and the > acpi) want the same irq 9 whereas there are a lot of free irqs... > the manteiner of the ACPI driver sayd his driver is ok for irq sharing > what about ne2k and winbond isdn ? i don't know how to contact the > manteiners of this drivers The ne2k-pci driver will share IRQs. The 'ne' driver will work for PCI cards, but is intended for ISA cards. It will not share the IRQ. Documentation for the ne2k-pci driver is at http://www.scyld.com/network/ne2k-pci.html > 1) ACPI > 2) ISDN (Windbond - HiSax) > 3) RealTek PCI NE2000 ethernet Is the ISDN card a PCI device? If not, it cannot share IRQs. If it is a PCI device, the driver is broken. Donald Becker [EMAIL PROTECTED] Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Beowulf-II Cluster Distribution Annapolis MD 21403 - 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
-BEGIN PGP SIGNED MESSAGE- If the shared library is under GPL (not LGPL) that isn't a problem. No? On Wed, 6 Sep 2000, David S. Miller wrote: > Because this allows proprietary software vendor X to write > closed-source compiler backend Y using GCC to provide the > front end. If it never becomes a shared library, this sort > of thing cannot happen. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBOba6OsK9HT/YfGeBAQEWlwP/TSHBmU93Yu4S2LkNxtOHGKZF21+zOchb 3Ado5qzdoCiXEXznWWlZWTpSbbPr2VvNxfO8D0QnHEQmZfMV+RddVQbFt3KIwAmz cv7Ws33rmfHfwjUSgpETxcc9HmJO1NU4LNo2XWXzRe2JCCdVCrmBOSQjQ1EXGzCa I4eLZcV0QNg= =jxhk -END PGP SIGNATURE- - 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: Compiler warnings
On Wed, 6 Sep 2000 21:49:44 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote: >Use a different gcc. There are reasons people shipping 2.96 for intel x86 also >include egcs. The kernel isnt ready for 2.96 Out of curiousity, which compiler would you recommend for IA64 kernels? The latest unwind code is in the bleeding edge version of gcc, which just happens to have the problems with '##' as well. - 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 about
Martin MaD Douda writes:
> 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.
>
> I can understand advantages the if(CONFIG_FOO) approach has, but I'm not
> sure it is worth compilation slowdown.
In response to Al (I don't think I've got his mail, still got 150 emails
to look at since last night):
Been there, done that, maybe you'd like to look at the ARM code which contains
the machine_is_xxx()? These essentially reduce down to one of three possible
values:
1. (0)
2. (MACH_TYPE_ASSABET == MACH_TYPE_ASSABET)
3. (__machine_type == MACH_TYPE_ASSABET)
The relevent definition is chosen by a set of pre-processor generated out of
arch/arm/tools/gen-mach-types.
Whilst it is good to remove redunant code, you still need #ifdefs...#endifs,
so I wouldn't recommend this style of configuration management for the
generic kernel.
Think about this:
struct bar foo_specific = {
...
};
struct bar *goo()
{
if (CONFIG_FOO)
return &foo_specific;
else
return NULL;
}
Unfortunately, the compiler always generates dataspace for both structures,
even if CONFIG_FOO is 0. So, how do we get rid of them? Simple, surround
them with #if CONFIG_FOO...#endif. Oh dear, the symbol is now undefined.
I guess we must add #if CONFIG_FOO around the if (CONFIG_FOO) as well. Ug,
I suppose we might as well just do:
struct bar *goo()
{
#if CONFIG_FOO
return &foo_specific;
#else
return NULL;
#endif
}
and be done with it.
Yes, I'd agree a good idea, and may apply to some small bits of code, but
not as a general kernel-wide thing. And converting the #ifdefs all to #ifs
is going to be a nightmarish large patch (before even thinking of making
configure produce the "define CONFIG_FOO as 0 or 1" you have first got to
make sure that there are no #ifdef CONFIG_FOO statements in existance.
(Note that the reason we do it on the ARM is NOT because we have a never
or always condition, but because we have never, maybe or always conditions,
and this is the easiest way to fix them up. But. We still need #ifdefs
#endifs).
_
|_| - ---+---+-
| | Russell King[EMAIL PROTECTED] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ - /\\\ |
-
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
Linus Torvalds wrote: > > On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > > > > > > Think of rabbits. And think of how the wolf helps them in the end. Not > > > by being nice, no. But the rabbits breed, and they are better for having > > > to worry a bit. > > > > You know those huge, sharp teeth on the wolf? Want to make them longer > > and sharper? Put in a kernel debugger, Linus, and the wolf will be even > > more ferocious. I appreciate the honest, open response, BTW. > > No, no. > > The debugger is akin to giving the _rabbits_ a bazooka. The poor wolf > doesn't get any sharper teeth. > > Yeah, it sure helps against wolves. They explode in pretty patterns of > read drops flying _everywhere_. Cool. Darren had to help me get up off the floor I was laughing so hard when I saw this. 10 points dude, good response:-) > > But it doesn't help against a rabbit gene pool that is slowly > deteriorating because there is nothing to keep them from breeding, and no > darwin to make sure that it's the fastest and strongest that breeds. > > You mentioned how NT has the nicest debugger out there. MANOS has the nicest debugger at present -- and soon you will have it too. Thay say that in human men, only 1% of our sperm are capable of fertilizing an egg, as opposed to chimpanzees and other primates, whiose sperm is almost 98% viable. Scientists state this is because since human evolution is no longer governed by natural selection but by social norms, men with inferior sperm were able to reproduce in ages past in the context of human society and that's why all human males have weak sperm these days -- nothing to weed out abberant genes -- which is why there's male pattern baldness, heart disease, etc. in the human gene pool today. I will give this some thought. What Alan said about hardware is valid, however, no matter how much Zen meditation one does, it does not make you "one with the 3C509 card". Hardware problems require a debugger or logic analyzer to fix. I never heard of anyone correcting timing problems with a PCI chipset by reviewing the chipset layouts :-) :-) :-) :-) Jeff > > Contemplate it. > > 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: making it hard (was kdb)
On Wed, 06 Sep 2000, Linus Torvalds wrote: When searching out some Venture Capital a while back, I heard the same words... We make it hard to get money intentionally, if you get frustrated, well you aren't the type of person that we want running the companies we invest in Oooops.. thread digressing.. > The people, the projects, the companies that come though that test of > fire victorious are not only stronger for it, but more importantly, they > are the kind of people, projects adn companies who DID get through. > Dedicated. Smart. And careful. > Linus -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - 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: Glad we did not add NTFS stream support
Don't be a dim-wit. The only reason its a problem on NT is that MS decided to not allow users to browse the other data streams (or forks, or whatever you want to call them) in Explorer. Actually, this type of virus is probably easier to find and clean because its isolated itself in a nice little package that you can nuke at via the file system. > > > Keith Owens wrote: > >> http://www.net-security.org/text/articles/viruses/generation.shtml >> describes a new generation of viruses which use NTFS stream support to >> hide themselves. >> >> "Certainly, this virus begins a new era in computer virus creation," >> said Eugene Kaspersky, Head of Anti-Virus Research at Kaspersky Lab. >> "The 'Stream Companion' technology the virus uses to plant itself into >> files makes its detection and disinfection extremely difficult to >> complete." >> > - 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
Date:Wed, 6 Sep 2000 08:59:56 -0600 From: Richard Gooch <[EMAIL PROTECTED]> Jamie Lokier writes: > Sorry, there's a GCC policy decision against putting it into a > shared library. Why? Because this allows proprietary software vendor X to write closed-source compiler backend Y using GCC to provide the front end. If it never becomes a shared library, this sort of thing cannot happen. Later, David S. Miller [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: modules directory
On Wed, 6 Sep 2000 15:09:02 -0400 (EDT), Andrew Park <[EMAIL PROTECTED]> wrote: >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? Why don't you look in linux/Documentation/Changes? That file exist precisely to stop repeated questions like this on the linux kernel developers list. - 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.2.17 - frame buffer
2.2.17 on Dell inspiron 7500 (ATI Mach64) using frame buffer no longer works. 2.2.16 was fine. I'm willing to try some pre if that would help. No longer works means no readable display. Bob - 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
On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > > > > Think of rabbits. And think of how the wolf helps them in the end. Not > > by being nice, no. But the rabbits breed, and they are better for having > > to worry a bit. > > You know those huge, sharp teeth on the wolf? Want to make them longer > and sharper? Put in a kernel debugger, Linus, and the wolf will be even > more ferocious. I appreciate the honest, open response, BTW. No, no. The debugger is akin to giving the _rabbits_ a bazooka. The poor wolf doesn't get any sharper teeth. Yeah, it sure helps against wolves. They explode in pretty patterns of read drops flying _everywhere_. Cool. But it doesn't help against a rabbit gene pool that is slowly deteriorating because there is nothing to keep them from breeding, and no darwin to make sure that it's the fastest and strongest that breeds. You mentioned how NT has the nicest debugger out there. Contemplate it. 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: Availability of kdb
On Wed, 6 Sep 2000, Marco Colombo wrote: > > As you said, the are two kinds of reactions. I don't understand why you > think that the presence of a debugger will *prevent* people from doing > the Right Thing and "think about problems another way". Are debuggers so > evil? Will a KDB option in the standard tarball seduce ALL the smart guys > , and even YOU, and lead you all to the Dark Side? Do you believe a > debugger has such a power? Go back. Read the mail again. Read the part about weeding out the people who are not careful. Think about it. Carefully. 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: Availability of kdb
On Wed, 6 Sep 2000, Dan Hollis wrote: > On Wed, 6 Sep 2000, Alan Cox wrote: > > For things like driver debugging its the only way to work. Hardware simply does > > not work like the manual says and no amount of Zen contemplation will ever > > make you at one with a 3c905B ethernet card. > > This is probably the best argument for a kernel debugger. > > Adding debug code (printk, if/then/BUG() etc) to track down a driver bug > sometimes changes behaviour enough to turn it into a heisenbug. In these > cases a kernel debugger is the best way to swat it. Ehh? And exactly _how_ would a debugger help it. Especially as Alan quoted an example of a driver bug that didn't get fixed for several months because the maintainer didn't have the hardware. What would a debugger have done? Are you _seriously_ expecting that non-programmers start using kernel debuggers to send in good bug-reports? Grow up, get a clue, and smell the roses. Not going to happen. Especially as a kernel debugger tends to require a second machine, and even then you only get to break automatically on events that would have caused a kernel oops anyway. Otherwise you need to know a hell of a lot more, like setting breakpoints etc. Testing is important for device drivers. Debuggers are not. 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: Availability of kdb
On Wed, 6 Sep 2000, Daniel Phillips wrote: > Linus Torvalds wrote: > > > > And quite frankly, for most of the real problems (as opposed to the stupid > > bugs - of which there are many, as the latest crap with "truncate()" has > > shown us) a debugger doesn't much help. And the real problems are what I > > worry about. The rest is just details. It will get fixed eventually. > > Yes, no doubt you agree that stepping through the code with a source > level debugger even once would have caught this one: No I definitely do not agree. In fact, I would never have seen that problem with _any_ debugger. It simply would not have happened for me. And guess what? I saw the bug without any debugger within minutes of having been told what the problem was. A debugger would not have helped. And that is the case in 99% of all cases. In most cases the people who see the problem aren't the same people who can debug them. Giving such a person a debugger doesn't help. 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: Availability of kdb
On Wed, 6 Sep 2000, Alan Cox wrote: > In many ways good crash dump tools and tracebacks (oopses do not count) are > the valuable bit - remote gdb happens to be a passable crash dump tool if you're lucky and can analyse the crash online, maybe. but offline crash dump analysis is the only option for a mission critical system with terabytes of attached data... you know, those problems you can never reproduce in testing, but are guaranteed to happy monday morning when everyone comes back from the weekend and slams the net. as much as i dislike solaris and veritas, i have to give their engineers credit for working from 6Gb crash dumps and responding with patches a few days later. (i'd put the word "enterprise" up there, but too many folks think it's just marketing... until they actually have to deal in that realm :) ObDebuggerReligion: i favour debuggers. i frequently learn how code is structured by walking into it with a debugger... i do this even when i want to add features rather than fix bugs. a debugger is a tool, it can't think for you; you're still in control. -dean - 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
Linus Torvalds wrote: > > In article <[EMAIL PROTECTED]>, > Jeff V. Merkey <[EMAIL PROTECTED]> wrote: > >Linus Torvalds wrote: > > > >> Apparently, if you follow the arguments, not having a kernel debugger > >> leads to various maladies: > >> - you crash when something goes wrong, and you fsck and it takes forever > >>and you get frustrated. > >> - people have given up on Linux kernel programming because it's too hard > >>and too time-consuming > >> - it takes longer to create new features. > >> > >> And nobody has explained to me why these are _bad_ things. > > > >They are bad because they cost people money that could be spent more > >productively in other areas due to the lengthening of the development > >process and the support costs. > > Ehh.. > > Explain to me again why I should care? > > Read my posting again. Read the "I'm a bastard" part twice. Realize > that in the end, I don't care who speds money, time, and effort. In the > end, I think that we're better off _without_ code that hasn't been > thought through. > > More code, more people, more money. Why should I think they are good > things? > > The people, the projects, the companies that come though that test of > fire victorious are not only stronger for it, but more importantly, they > are the kind of people, projects adn companies who DID get through. > Dedicated. Smart. And careful. > > Think of rabbits. And think of how the wolf helps them in the end. Not > by being nice, no. But the rabbits breed, and they are better for having > to worry a bit. You know those huge, sharp teeth on the wolf? Want to make them longer and sharper? Put in a kernel debugger, Linus, and the wolf will be even more ferocious. I appreciate the honest, open response, BTW. Jeff > > 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/ - 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-test8-pre5] bugfixes for rtc driver (fwd)
Tigran Aivazian wrote: > > sorry, I've done it again... > > -- Forwarded message -- > Date: Wed, 6 Sep 2000 21:29:20 +0100 (BST) > From: Tigran Aivazian <[EMAIL PROTECTED]> > To: Linus Torvalds <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: [patch-2.4.0-test8-pre5] bugfixes for rtc driver > > Hi Linus, > > The rtc driver does: > > a) not handle failures from misc_register() gracefully > > b) not handle failures from create_proc_read_entry() gracefully > > c) uses check_region() where request_region() would suffice > > The patch below fixes these issues/bugs. Looks ok. One comment is that you should propagate any valid return values too, such as the request_irq or misc_register return value. Jeff -- Jeff Garzik | "I can't die until the government Building 1024| finds a safe place to bury my liver." MandrakeSoft, Inc. |-- Phil Harris - 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/
Glad we did not add NTFS stream support
http://www.net-security.org/text/articles/viruses/generation.shtml describes a new generation of viruses which use NTFS stream support to hide themselves. "Certainly, this virus begins a new era in computer virus creation," said Eugene Kaspersky, Head of Anti-Virus Research at Kaspersky Lab. "The 'Stream Companion' technology the virus uses to plant itself into files makes its detection and disinfection extremely difficult to complete." - 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
On Wed, 6 Sep 2000, Linus Torvalds wrote: [...] > Oh. And sure, when things crash and you fsck and you didn't even get a > clue about what went wrong, you get frustrated. Tough. There are two kinds > of reactions to that: you start being careful, or you start whining about > a kernel debugger. > [...] > I happen to believe that not having a kernel debugger forces people to > think about their problem on a different level than with a debugger. I > think that without a debugger, you don't get into that mindset where you > know how it behaves, and then you fix it from there. Without a debugger, > you tend to think about problems another way. You want to understand > things on a different _level_. > > It's partly "source vs binary", but it's more than that. It's not that you > have to look at the sources (of course you have to - and any good debugger > will make that _easy_). It's that you have to look at the level _above_ > sources. At the meaning of things. Without a debugger, you basically have > to go the next step: understand what the program does. Not just that > particular line. As you said, the are two kinds of reactions. I don't understand why you think that the presence of a debugger will *prevent* people from doing the Right Thing and "think about problems another way". Are debuggers so evil? Will a KDB option in the standard tarball seduce ALL the smart guys , and even YOU, and lead you all to the Dark Side? Do you believe a debugger has such a power? You don't need to be blind to be able to listen to music. It just happens that you sometimes close your eyes, since it makes it a deeper experience. So, when you want to "look at the Source" (== "understand things on a different _level_"), just leave the debugger off. Don't compile it. People who don't understand this will keep looking at the debugger prompt. If the bug is a "easy" one, they'll fix it. If it's an hard one, one that needs an Higher Knowledge, they won't. And you'll never see a patch from them. So? Darwin rules anyway... That said, I believe that you don't need to explain why you don't include a kernel db in the standard kernel. As far as I'm concerned, the standard kernel is just a tarball of your kernel tree. And you put whatever YOU like in it. I call it "the standard kernel" only because *I* decided to think of it as a reference. It just happens that many people think that same way I do, and go and grab the latest 'official' tarball as soon as you release it. I do apply patches (e.g. RAID), but I won't tell you: "put them in YOUR kernel" the same why I don't tell you of what color you should paint the walls of your house... You can be as "bastard" as you like with your kernel since it's YOURS. You don't like debuggers. Fine. Maybe you don't like them because you think they will prevent YOU from thinking about bugs the right way. So they'll never make their way into YOUR kernel. But please don't say that debuggers are bad for everyone... others may be able to close their eyes and "look at the Source" even in the presence of a debugger... IMHO, there good reasons to leave a debugger out. Technical ones. You don't need a religious one. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: Availability of kdb
On Wed, 6 Sep 2000, Horst von Brand wrote: > Michael Peddemors <[EMAIL PROTECTED]> said: > > > > Because I'm a bastard, and proud of it! > > > > > > Linus > > > Any general thoughts on how to keep recruiting the next generation of > > bastards? > > Clean design, clean code. Modularization. Better (internal) documentation. I agree with this. Without these, we're nowhere. (and not even a debugger will help you) I've planned a cleanup of some VM code for 2.5 and will do my utmost best to make sure the code becomes more readable and better documented. Also, I'm willing to help people write documentation on any part of the kernel I know. I'm a bit too busy to write a lot of documention myself, but I'll gladly explain things to the people who will be writing docs. 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: Still ext2-corruption in test8-pre5 (incl. OOPS)
On Wed, 6 Sep 2000, Tim Waugh wrote: > On Wed, Sep 06, 2000 at 08:29:49AM -0700, Linus Torvalds wrote: > > > Just change block_truncate_page() to use b_this_page instead of b_next. > > That seems to fix it. I'm really really really looking forward to the first kernel since 2.3.7 that doesn't have the potential to eat my files... cheers, 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: Availability of kdb
On Wed, 6 Sep 2000, Alan Cox wrote: > For things like driver debugging its the only way to work. Hardware simply does > not work like the manual says and no amount of Zen contemplation will ever > make you at one with a 3c905B ethernet card. This is probably the best argument for a kernel debugger. Adding debug code (printk, if/then/BUG() etc) to track down a driver bug sometimes changes behaviour enough to turn it into a heisenbug. In these cases a kernel debugger is the best way to swat it. -Dan - 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
In article <[EMAIL PROTECTED]>, Jeff V. Merkey <[EMAIL PROTECTED]> wrote: >Linus Torvalds wrote: > >> Apparently, if you follow the arguments, not having a kernel debugger >> leads to various maladies: >> - you crash when something goes wrong, and you fsck and it takes forever >>and you get frustrated. >> - people have given up on Linux kernel programming because it's too hard >>and too time-consuming >> - it takes longer to create new features. >> >> And nobody has explained to me why these are _bad_ things. > >They are bad because they cost people money that could be spent more >productively in other areas due to the lengthening of the development >process and the support costs. Ehh.. Explain to me again why I should care? Read my posting again. Read the "I'm a bastard" part twice. Realize that in the end, I don't care who speds money, time, and effort. In the end, I think that we're better off _without_ code that hasn't been thought through. More code, more people, more money. Why should I think they are good things? The people, the projects, the companies that come though that test of fire victorious are not only stronger for it, but more importantly, they are the kind of people, projects adn companies who DID get through. Dedicated. Smart. And careful. Think of rabbits. And think of how the wolf helps them in the end. Not by being nice, no. But the rabbits breed, and they are better for having to worry a bit. 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: Reserving a (large) memory block
On 06 Sep 2000 13:54:49 +0800 Ryan Cumming <[EMAIL PROTECTED]> wrote: >> Problem is: I don't (think I) have filesystem access at init >> time, and can't safely reserve specific physical memory after >> init which seems to leave my only option being to pass in the >> reservation specs from the bootloader, which is what rather I'm >> trying to avoid. > Possibly... would it be pratical to have part of the module kernel > resident, and the pull its memory location/size off the kernel > command line? Is that possible? How? Modules seem to come a long ways after init (certainly after the memory stuff is built). -- J C Lawrence Home: [EMAIL PROTECTED] -(*)Work: [EMAIL PROTECTED] http://www.kanga.nu/~claw/Keys etc: finger [EMAIL PROTECTED] --=| A man is as sane as he is dangerous to his environment |=-- - 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
-BEGIN PGP SIGNED MESSAGE- To do this, we need to be taught how. Where are the manuals for these potential power saws? What books do we read? What courses do we take? What websites do we visit? In short, wheres the beef? Where does one learn the theory and concepts that go into these "advanced" wonders of the information toolmaking economy? I recently got my copy of "Debugging with GDB" from the FSF. While it is a good start, far more is needed. "Deep C Secrets", while a valuable read, doesn't go much farther in the use of "power tools". Would any of you advocates of kernel debuggers and advanced debugging power tools show us their intended use? I do light construction around my house, but I'm not going to start using a jackhammer or chainsaw without getting at least a little instruction beforehand from someone who knows the business. I like to program in the same way. Jonathan Walther Developer, Lineo On Wed, 6 Sep 2000, Daniel Phillips wrote: > 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. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBObatR8K9HT/YfGeBAQEZkAP+J3zsBoNTt2+BeJkUaLmW+p7wgL0oy2PU PqnS5xU/QnmTmP+x5OSLtbXTQ55VqZBalY1gLK8DnjCyYy/JH8ckivWs84lIxRW7 60cDZWlx5bmg5OHx2dYRTibOvkFUmFQuDWjPhZebqeOX2M1g1UcSDrEQ8qReW8fg 9xQY4RkpSYE= =gs3d -END PGP SIGNATURE- - 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
On Wed, 6 Sep 2000, George Anzinger wrote:
> 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
>
So it seems to be a bug at least in terms of timing. Unfortunately I only
got about 4 replies to the patches that touched 20+ drivers. I suppose I
should just hassle maintainers until they fix it or tell me where I've
gone wrong ...
john
-
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, Sep 06, 2000 at 08:29:49AM -0700, Linus Torvalds wrote: > Just change block_truncate_page() to use b_this_page instead of b_next. That seems to fix it. Thanks, 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: Availability of kdb
Tigran Aivazian wrote: > > On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > > Then it may be that corporate America weeds out Linux over > > more likely is that corporate America weeds out commercial software as a > model which was superseded by the free software. We (the creative anarchy > community led by Linus) are here to help that happen, gradually and slowly > without shocks and fits by those who love this world and the things that > are therein so much they choose to serve Mammon and make money on that > which should be inherently free (to wit, any form of information, isn't > it just 1s and 0s? :) Just remember, i am a part of "we" -- although it sometimes may not seem that way. I don't buy Linus' "Im the baddest ape in the jungle and made of stone" comments. He's not nice, but he does have feelings -- I've seen them. :-) Jeff > > Regards, > Tigran > > PS. If Linus objects to being a leader of such community, I may remind > that the keyword there is "anarchy" and that assumes that, to some extent, > the consent of a human to be or not to be its leader, may be freely > ignored by those being lead, without even disturbing the symbiotic harmony > between the leader and those he leads. - 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
> Apparently, if you follow the arguments, not having a kernel debugger > leads to various maladies: > - you crash when something goes wrong, and you fsck and it takes forever >and you get frustrated. 'It crashed.' [Spend hour teaching and end user to patch kdb] 'It crashed, it says foo, but this fsck took hours so I dont have time to help more' [Bug goes unfixed for 2 months because it only happens on a revision 8 card which the maintainer doesnt] > - people have given up on Linux kernel programming because it's too hard >and too time-consuming Programming isnt the problem to me - its debugging. I get a lot of awful patches that have good debugging behind them. That debugging is the valuable part. I used to reach each of Andrea's patches to find out what the bug was rather than how he fixed it for example (nowdays I tend to apply his patches of course) For things like driver debugging its the only way to work. Hardware simply does not work like the manual says and no amount of Zen contemplation will ever make you at one with a 3c905B ethernet card. In many ways good crash dump tools and tracebacks (oopses do not count) are the valuable bit - remote gdb happens to be a passable crash dump tool Alan - 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: Compiler warnings
> I'm trying to compile 2.2.17 with gcc 2.96, and it shows a lot of Dont > It's the update to gcc2.96 causing this problems?? How can i get to > compile the kernel? Use a different gcc. There are reasons people shipping 2.96 for intel x86 also include egcs. The kernel isnt ready for 2.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: Availability of kdb
Linus Torvalds wrote: > > And quite frankly, for most of the real problems (as opposed to the stupid > bugs - of which there are many, as the latest crap with "truncate()" has > shown us) a debugger doesn't much help. And the real problems are what I > worry about. The rest is just details. It will get fixed eventually. Yes, no doubt you agree that stepping through the code with a source level debugger even once would have caught this one: > >> Code; c012cae6<= >>0: 8b 00 movl (%eax),%eax <= > >Offset 0 is ->b_next... Huh? It should be ->b_this_page, no? > But that fits with your argument that debugging the kernel should not be easy, so there is no inconsistency. As long as having the kernel progress quickly doesn't matter to you, there's no inconsistency there either. It progresses fast enough for me. Right now, I'm debugging exactly the way you like to, and by coincidence, exactly the same code. If I wanted to, I could install sgi's kdb patch and do this more efficiently, but what the heck. Maybe tomorrow. I'm more than adequately entertained. I'm fortunate to be in the position where rapid forward progress just doesn't affect my paycheck. I can think about the things I like to think about, work on the problems that interest me. I have a dream job. Others are not so fortunate. -- 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: Availability of kdb
On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > Then it may be that corporate America weeds out Linux over more likely is that corporate America weeds out commercial software as a model which was superseded by the free software. We (the creative anarchy community led by Linus) are here to help that happen, gradually and slowly without shocks and fits by those who love this world and the things that are therein so much they choose to serve Mammon and make money on that which should be inherently free (to wit, any form of information, isn't it just 1s and 0s? :) Regards, Tigran PS. If Linus objects to being a leader of such community, I may remind that the keyword there is "anarchy" and that assumes that, to some extent, the consent of a human to be or not to be its leader, may be freely ignored by those being lead, without even disturbing the symbiotic harmony between the leader and those he leads. - 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
Michael Peddemors <[EMAIL PROTECTED]> said: [...] > > Because I'm a bastard, and proud of it! > > > > Linus > Any general thoughts on how to keep recruiting the next generation of > bastards? Clean design, clean code. Modularization. Better (internal) documentation. -- 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: Availability of kdb
} because you have "sullied" yourself. But I'm not going to help you use } one, and I wuld frankly prefer people not to use kernel debuggers that } much. So I don't make it part of the standard distribution, and if the } existing debuggers aren't very well known I won't shed a tear over it. The two extremes are not the only way to do it. PPC has had an in-kernel debugger for quite some time. It's not a full-featured point-and-click piece of crap but it is enough to be useful for digging through the memory and register state when the system decides it's time to give up and panic. I've solved a lot of problems with it, caught many mistakes and it hasn't resulted in the apocalyptic onslaught of features that you fear. - 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
On Wed, 6 Sep 2000, Michael Peddemors wrote: > Is there any sort of plan to help newbie kernel programmers to > get to the point where the Linus's and Alan's of the world will > take them under their wings? On the risk of repeating myself: http://kernelnewbies.org/ [EMAIL PROTECTED] (ask majordomo for details) irc.openprojects.net #kernelnewbies cheers, 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/
