Re: Serial device with very large buffer
Alex Belits wrote: > On Thu, 1 Feb 2001, Joe deBlaquiere wrote: > > >> Hi Alex! >> >> I'm a little confused here... why are we overrunning? This thing is >> running externally at 19200 at best, even if it does all come in as a >> packet. > > > Different Merlin -- original Merlin is 19200, "Merlin for Ricochet" is > 128Kbps (or faster), and uses Metricom/Ricochet network. so can you still limit the mru? -- Joe - To unsubscribe from this list: send 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: Serial device with very large buffer
Hi Alex! I'm a little confused here... why are we overrunning? This thing is running externally at 19200 at best, even if it does all come in as a packet. I would think the flip buffer would never contain more than a few characters. Are you running it at a higher rate internally? Does it buffer up a whole packet if you do this? Wouldn't it be a little easier to drop somthing like "AT#MRU=500\r" to the modem than to change the tty driver? -- Joe Alex Belits wrote: > On Thu, 1 Feb 2001, Alan Cox wrote: > > >>> I also propose to increase the size of flip buffer to 640 bytes (so the >>> flipping won't occur every time in the middle of the full buffer), however >>> I understand that it's a rather drastic change for such a simple goal, and >>> not everyone will agree that it's worth the trouble: >> >> Going to a 1K flip buffer would make sense IMHO for high speed devices too > > > 1K flip buffer makes the tty_struct exceed 4096 bytes, and I don't think, > it's a good idea to change the allocation mechanism for it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0
David Woodhouse wrote: > On Thu, 1 Feb 2001, Pavel Machek wrote: > > >> I thought that Vtech Helio folks already have XIP supported... > > > Plenty of people are doing XIP of the kernel. I'm not aware of anyone > doing XIP of userspace pages. uClinux does XIP (readonly) for userspace programs in the Dragonball port. Of course it's a different executable format than Linux, so there are some hooks for it. -- Joe - To unsubscribe from this list: send 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: novatel minstrel on 2.4
Adam Fritzler wrote:
> We've been trying to set up a laptop here to use a Novatel Minstrel PCMCIA
> modem (wireless Richocet network). The card shows up as a serial port
> (ttySx) and accepts AT commands just like a normal modem.
>
I'm in the process of bringing up a Novatel Merlin now (tomorrow morning
actually). I don't know how similar it is, but they do at least use some
common hardware on the Merlin and Sage products.
> It dials fine, PPP connects, gets IPs, etc just as it should. However,
> any packet over about 400 bytes gets dropped on the recieve. Also, the RX
> errors on ppp0 increment occasionally.
>
According to http://people.freebsd.org/~nsayer/ you have to set the mru
to 576 for the Merlin. There is some fairly detailed info on
http://www.mrollins.com/newtmerlin.html about setting it up for (of all
things) a Newton including all the expected commands which implies that
you should adjust the mru setting on the card and then match that with ppp.
> TCP connections connect (because the SYN's are small), but as soon as you
> start trying to do bulk transfers (`ls -la` in an ssh window, or an HTTP
> GET), the connection stalls. Pinging other hosts also works fine, except
> when you do -s with a value larger than 300 or so.
>
> It doesn't work with anything we've tried on 2.4 (changing mtu/mru, serial
> port speed, etc). However, under 2.2.x, we were able to get connections to
> stay running and not stall by setting the MTU on ppp0 to 120 after the ppp
> comes up. As you can imagine, this makes the modem seem even slower than
> it already is.
>
> Not that its relevent, but pppstats shows 0 in the 'vjcomp' fields of
> both rx and tx (as well as 'vjerr'). I've tried starting pppd with and
> without 'novj' just in case. Same result.
>
> Any ideas? The 'rx error' count going up is kind of suspicious. My
> attempts at getting pppd to print more debugging output have been
> futile; aparently the debug and kdebug options no longer work ('debug'
> produces the LCP traffic, yes, but thats working fine).
>
> af
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax : (256)-837-3839
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0
David Woodhouse wrote: On Thu, 1 Feb 2001, Pavel Machek wrote: I thought that Vtech Helio folks already have XIP supported... Plenty of people are doing XIP of the kernel. I'm not aware of anyone doing XIP of userspace pages. uClinux does XIP (readonly) for userspace programs in the Dragonball port. Of course it's a different executable format than Linux, so there are some hooks for it. -- Joe - To unsubscribe from this list: send 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: Serial device with very large buffer
Hi Alex! I'm a little confused here... why are we overrunning? This thing is running externally at 19200 at best, even if it does all come in as a packet. I would think the flip buffer would never contain more than a few characters. Are you running it at a higher rate internally? Does it buffer up a whole packet if you do this? Wouldn't it be a little easier to drop somthing like "AT#MRU=500\r" to the modem than to change the tty driver? -- Joe Alex Belits wrote: On Thu, 1 Feb 2001, Alan Cox wrote: I also propose to increase the size of flip buffer to 640 bytes (so the flipping won't occur every time in the middle of the full buffer), however I understand that it's a rather drastic change for such a simple goal, and not everyone will agree that it's worth the trouble: Going to a 1K flip buffer would make sense IMHO for high speed devices too 1K flip buffer makes the tty_struct exceed 4096 bytes, and I don't think, it's a good idea to change the allocation mechanism for it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial device with very large buffer
Alex Belits wrote: On Thu, 1 Feb 2001, Joe deBlaquiere wrote: Hi Alex! I'm a little confused here... why are we overrunning? This thing is running externally at 19200 at best, even if it does all come in as a packet. Different Merlin -- original Merlin is 19200, "Merlin for Ricochet" is 128Kbps (or faster), and uses Metricom/Ricochet network. so can you still limit the mru? -- Joe - To unsubscribe from this list: send 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: Support for 802.11 cards?
There is a rather informative discussion of wireless support at : http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.drivers.html Though possibly a little out of date, the author of this obviously did their research. Kudos! -- Joe Michael H. Warfield wrote: > On Sun, Jan 28, 2001 at 05:07:33PM -0500, John Jasen wrote: > >> On Sun, 28 Jan 2001, Mike Pontillo wrote: > > >>> I was wondering what 802.11 PCI cards anyone knows of that run >>> under Linux-2.4. (or 2.2 for that matter) >> > >> I _think_ a good many of the 802.11 wireless ISA and PCI cards are just >> bus to PCMCIA adapters, so it would be a question of whether or not the >> PCMCIA card is supported and if the bridge is supported. > > > Last I knew (straight from the Lucent people), the ISA bridge > card worked fine and the PCI card did NOT work at all. I've since > confirmed that, first hand, myself (I currently have the ISA bridge in > operation) on the 2.2 kernels. The ISA bridge also works on the 2.4 > kernels but I have not retested the PCI bridge on 2.4. The Lucent > people claim that the Linux pcmcia people are aware of the problem. > > 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: [linux-audio-dev] low-latency scheduling patch for 2.4.0
Andrew Morton wrote: > There has been surprisingly little discussion here about the > desirability of a preemptible kernel. > And I think that is a very intersting topic... (certainly more interesting than hotmail's firewalling policy ;o) Alright, so suppose I dream up an application which I think really really needs preemption (linux heart pacemaker project? ;o) I'm just not convinced that linux would ever be the correct codebase to start with. The fundamental design of every driver in the system presumes that there is no preemption. A recent example I came across is in the MTD code which invokes the erase algorithm for CFI memory. This algorithm spews a command sequence to the flash chips followed by a list of sectors to erase. Following each sector adress, the chip will wait for 50usec for another address, after which timeout it begins the erase cycle. With a RTLinux-style approach the driver is eventually going to fail to issue the command in time. There isn't any logic to detect and correct the preemption case, so it just gets confused and thinks the erase failed. Ergo, RTLinux and MTD are mutually exclusive. (I should probably note that I do not intend this as an indictment of RTLinux or MTD, but just an example of why preemption breaks the Linux driver model). So what is the solution in the preemption case? Should we re-write every driver to handle the preemption? Do we need a cli_yes_i_mean_it() for the cases where disabling interrupts is _absolutely_ required? Do we push drivers like MTD down into preemptable-Linux? Do we push all drivers down? In the meantime, fixing the few places where the kernel spends an extended period of time performing a task makes sense to me. If you're going to be busy for a while it is 'courteous' to allow the scheduler a chance to give some time to other threads. Of course it's hard to know when to draw the line. So now I am starting to wonder about what needs to be profiled. Is there a mechanism in place now to measure the time spent with interrupts off, for instance? I know this has to have been quantified to some extent, right? -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0
Andrew Morton wrote: There has been surprisingly little discussion here about the desirability of a preemptible kernel. And I think that is a very intersting topic... (certainly more interesting than hotmail's firewalling policy ;o) Alright, so suppose I dream up an application which I think really really needs preemption (linux heart pacemaker project? ;o) I'm just not convinced that linux would ever be the correct codebase to start with. The fundamental design of every driver in the system presumes that there is no preemption. A recent example I came across is in the MTD code which invokes the erase algorithm for CFI memory. This algorithm spews a command sequence to the flash chips followed by a list of sectors to erase. Following each sector adress, the chip will wait for 50usec for another address, after which timeout it begins the erase cycle. With a RTLinux-style approach the driver is eventually going to fail to issue the command in time. There isn't any logic to detect and correct the preemption case, so it just gets confused and thinks the erase failed. Ergo, RTLinux and MTD are mutually exclusive. (I should probably note that I do not intend this as an indictment of RTLinux or MTD, but just an example of why preemption breaks the Linux driver model). So what is the solution in the preemption case? Should we re-write every driver to handle the preemption? Do we need a cli_yes_i_mean_it() for the cases where disabling interrupts is _absolutely_ required? Do we push drivers like MTD down into preemptable-Linux? Do we push all drivers down? In the meantime, fixing the few places where the kernel spends an extended period of time performing a task makes sense to me. If you're going to be busy for a while it is 'courteous' to allow the scheduler a chance to give some time to other threads. Of course it's hard to know when to draw the line. So now I am starting to wonder about what needs to be profiled. Is there a mechanism in place now to measure the time spent with interrupts off, for instance? I know this has to have been quantified to some extent, right? -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 - To unsubscribe from this list: send 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: kernel boot problems
A few things come to mind: 1. Is your init statically linked or linked with shared libraries? If it's shared, do you have all the shared objects on your disk image in a place where they can be found (/lib, I hope)? You might try linking it statically (but stripped) just to make sure. 2. Is it in the path that the kernel is looking in? check init/main.c to see what your kernel is looking for (it's some educational reading anyway). 3. Even if 'init' isn't found, it should try to run /bin/sh as a last resort. I can't imagine you don't have one of those. 4. Is init executable? 5. "unable to open an initial console" probably means you don't have the necesary device nodes (refer to init/main.c) 6. If this doesn't help, there is a ramdisk FAQ that is well written... Good luck with it! Joe Ryan Hairyes wrote: > Hello all, > > I was wondering if someone might be able to help me. > I have just compiled my kernel and set it up on a floppy > to boot off a disk. I have it then use an image file to uncompress > and get the filesystem off ,etc. Well when it boots it says it has > uncompressed the filesystem image and then gives me this: > Mounted Root (ext2 filesystem) readonly > Freeing unused kernel memory: 212K freed > Warning: unable to open an initial console > Kernel panic: no init found. Try passing init= option to the kernel. > > I know that I have init on the image, so what could I be doing wrong. > It is probably something stupid that I am overlooking, but I thank you in > advance. > > Ryan > > - > To unsubscribe from this list: send 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: kernel boot problems
A few things come to mind: 1. Is your init statically linked or linked with shared libraries? If it's shared, do you have all the shared objects on your disk image in a place where they can be found (/lib, I hope)? You might try linking it statically (but stripped) just to make sure. 2. Is it in the path that the kernel is looking in? check init/main.c to see what your kernel is looking for (it's some educational reading anyway). 3. Even if 'init' isn't found, it should try to run /bin/sh as a last resort. I can't imagine you don't have one of those. 4. Is init executable? 5. "unable to open an initial console" probably means you don't have the necesary device nodes (refer to init/main.c) 6. If this doesn't help, there is a ramdisk FAQ that is well written... Good luck with it! Joe Ryan Hairyes wrote: Hello all, I was wondering if someone might be able to help me. I have just compiled my kernel and set it up on a floppy to boot off a disk. I have it then use an image file to uncompress and get the filesystem off ,etc. Well when it boots it says it has uncompressed the filesystem image and then gives me this: Mounted Root (ext2 filesystem) readonly Freeing unused kernel memory: 212K freed Warning: unable to open an initial console Kernel panic: no init found. Try passing init= option to the kernel. I know that I have init on the image, so what could I be doing wrong. It is probably something stupid that I am overlooking, but I thank you in advance. Ryan - To unsubscribe from this list: send 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/
Is it possible to force don't fragment on a socket?
I'm trying to test a communications path to a remote system and was wondering if I could force the DF bit on some UDP traffic. Does anybody know of a way to do this?? TIA, Joe - To unsubscribe from this list: send 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 possible to force don't fragment on a socket?
I'm trying to test a communications path to a remote system and was wondering if I could force the DF bit on some UDP traffic. Does anybody know of a way to do this?? TIA, Joe - To unsubscribe from this list: send 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?] Coding Style
Too bad we can't just do a "Prince" and invent unpronouncable symbols to use as function names... or perhaps just use something from the chinese fonts ;o)... Mike Harrold wrote: >> This message is in MIME format. Since your mail reader does not understand >> this format, some or all of this message may not be legible. >> >> --_=_NextPart_001_01C08552.FFC336D0 >> Content-Type: text/plain; >> charset="ISO-8859-1" >> >> I prefer descriptive variable and function names - like comments, they help >> to make code so much easier to read. >> >> One thing I wonder though... why do people prefer 'some_function_name()' >> over 'SomeFunctionName()'? I personally don't like the underscore character >> - it's an odd character to type when you're trying to get the name typed in, >> and the shifted character, I find, is easier to input. >> > > > For exactly the reverse of that reason. Typing capital letters is a heck > of a lot more difficult that addint an underscore. > > Then there is reasability. > > void ThisIsMyDumbassFunctionName > > if MUCH more difficult to read than > > void this_is_my_clear_and_easy_function_name > > Regards, > > /Mike > > >> Cheers! >> Jon >> >> >>> -Original Message- >>> From: Steve Underwood [mailto:[EMAIL PROTECTED]] >> >> Some people still seem to be living in the age of K C, with 6 or 7 >> character variable names that demand some explanation. Maybe some day >> they will awake to the expressive power of long (and well chosen) names. >> >> --_=_NextPart_001_01C08552.FFC336D0 >> Content-Type: text/html; >> charset="ISO-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> > charset=3DISO-8859-1"> >> > 5.5.2652.35"> >> RE: [OT?] Coding Style >> >> >> >> I prefer descriptive variable and function names - = >> like comments, they help to make code so much easier to read. >> >> >> One thing I wonder though... why do people prefer = >> 'some_function_name()' over 'SomeFunctionName()'? I personally = >> don't like the underscore character - it's an odd character to type = >> when you're trying to get the name typed in, and the shifted character, = >> I find, is easier to input. >> >> Cheers! >> Jon >> >> >> -Original Message- >> From: Steve Underwood [> HREF=3D"mailto:[EMAIL PROTECTED]">mailto:[EMAIL PROTECTED]]= >> >> >> >> Some people still seem to be living in the age of = >> KR C, with 6 or 7 >> character variable names that demand some = >> explanation. Maybe some day >> they will awake to the expressive power of long (and = >> well chosen) names. >> >> >> >> >> --_=_NextPart_001_01C08552.FFC336D0-- >> - >> To unsubscribe from this list: send 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/ -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 - To unsubscribe from this list: send 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?] Coding Style
Too bad we can't just do a "Prince" and invent unpronouncable symbols to use as function names... or perhaps just use something from the chinese fonts ;o)... Mike Harrold wrote: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --_=_NextPart_001_01C08552.FFC336D0 Content-Type: text/plain; charset="ISO-8859-1" I prefer descriptive variable and function names - like comments, they help to make code so much easier to read. One thing I wonder though... why do people prefer 'some_function_name()' over 'SomeFunctionName()'? I personally don't like the underscore character - it's an odd character to type when you're trying to get the name typed in, and the shifted character, I find, is easier to input. For exactly the reverse of that reason. Typing capital letters is a heck of a lot more difficult that addint an underscore. Then there is reasability. void ThisIsMyDumbassFunctionName if MUCH more difficult to read than void this_is_my_clear_and_easy_function_name Regards, /Mike Cheers! Jon -Original Message- From: Steve Underwood [mailto:[EMAIL PROTECTED]] Some people still seem to be living in the age of KR C, with 6 or 7 character variable names that demand some explanation. Maybe some day they will awake to the expressive power of long (and well chosen) names. --_=_NextPart_001_01C08552.FFC336D0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" HTML HEAD META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3DISO-8859-1" META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2652.35" TITLERE: [OT?] Coding Style/TITLE /HEAD BODY PFONT SIZE=3D2I prefer descriptive variable and function names - = like comments, they help to make code so much easier to read./FONT /P PFONT SIZE=3D2One thing I wonder though... why do people prefer = 'some_function_name()' over 'SomeFunctionName()'?nbsp; I personally = don't like the underscore character - it's an odd character to type = when you're trying to get the name typed in, and the shifted character, = I find, is easier to input./FONT/P PFONT SIZE=3D2Cheers!/FONT BRFONT SIZE=3D2Jon/FONT /P PFONT SIZE=3D2gt; -Original Message-/FONT BRFONT SIZE=3D2gt; From: Steve Underwood [A = HREF=3D"mailto:[EMAIL PROTECTED]"mailto:[EMAIL PROTECTED]/A]/FONT= /P PFONT SIZE=3D2Some people still seem to be living in the age of = Kamp;R C, with 6 or 7/FONT BRFONT SIZE=3D2character variable names that demand some = explanation. Maybe some day/FONT BRFONT SIZE=3D2they will awake to the expressive power of long (and = well chosen) names./FONT /P /BODY /HTML --_=_NextPart_001_01C08552.FFC336D0-- - To unsubscribe from this list: send 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/ -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 - To unsubscribe from this list: send 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: more on scheduler benchmarks
Maybe I've been off in the hardware lab for too long, but how about 1. using ioperm to give access to the parallel port. 2. have your program write a byte (thread id % 256 ?) constantly to the port during it's other activity 3. capture the results from another computer with an ecp port This way you don't run the risk of altering the scheduler behavior with your logging procedure. Mike Kravetz wrote: > Last week while discussing scheduler benchmarks, Bill Hartner > made a comment something like the following "the benchmark may > not even be invoking the scheduler as you expect". This comment > did not fully sink in until this weekend when I started thinking > about changes made to sched_yield() in 2.4.0. (I'm cc'ing Ingo > Molnar because I think he was involved in the changes). If you > haven't taken a look at sys_sched_yield() in 2.4.0, I suggest > that you do that now. > > A result of new optimizations made to sys_sched_yield() is that > calling sched_yield() does not result in a 'reschedule' if there > are no tasks waiting for CPU resources. Therefore, I would claim > that running 'scheduler benchmarks' which loop doing sched_yield() > seem to have little meaning/value for runs where the number of > looping tasks is less than then number of CPUs in the system. Is > that an accurate statement? > > If the above is accurate, then I am wondering what would be a > good scheduler benchmark for these low task count situations. > I could undo the optimizations in sys_sched_yield() (for testing > purposes only!), and run the existing benchmarks. Can anyone > suggest a better solution? > > Thanks, -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 - To unsubscribe from this list: send 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: more on scheduler benchmarks
Maybe I've been off in the hardware lab for too long, but how about 1. using ioperm to give access to the parallel port. 2. have your program write a byte (thread id % 256 ?) constantly to the port during it's other activity 3. capture the results from another computer with an ecp port This way you don't run the risk of altering the scheduler behavior with your logging procedure. Mike Kravetz wrote: Last week while discussing scheduler benchmarks, Bill Hartner made a comment something like the following "the benchmark may not even be invoking the scheduler as you expect". This comment did not fully sink in until this weekend when I started thinking about changes made to sched_yield() in 2.4.0. (I'm cc'ing Ingo Molnar because I think he was involved in the changes). If you haven't taken a look at sys_sched_yield() in 2.4.0, I suggest that you do that now. A result of new optimizations made to sys_sched_yield() is that calling sched_yield() does not result in a 'reschedule' if there are no tasks waiting for CPU resources. Therefore, I would claim that running 'scheduler benchmarks' which loop doing sched_yield() seem to have little meaning/value for runs where the number of looping tasks is less than then number of CPUs in the system. Is that an accurate statement? If the above is accurate, then I am wondering what would be a good scheduler benchmark for these low task count situations. I could undo the optimizations in sys_sched_yield() (for testing purposes only!), and run the existing benchmarks. Can anyone suggest a better solution? Thanks, -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 - To unsubscribe from this list: send 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: sysmips call and glibc atomic set
Ralf, firstly, thank you for the answers :)
Ralf Baechle wrote:
>
> Ok, but since the kernel disables MIPS III you're limited to MIPS II anyway ...
>
This makes sense...
>
>
> Read the ISA manual; sc will fail if the LL-bit in c0_status is cleared
> which will be cleared when the interrupt returns using the eret instruction.
>
I tried to find a MIPSIII manual from mips.com but all I could find was
mips32 and mips64 (which are not the same as MIPSII/MIPSIII/MIPSIV).
>
>
> Not having swap doesn't mean you're safe. Think of any kind of previously
> unmapped page.
>
Is there a reason why it doesn't just force that page to be mapped first?
>
>> QUESTION 2) Wouldn't it be better to pass back the initial value of
>> *arg1 in *arg3 and return zero or negative error code?
>
>
> The semantics of this syscall were previously defined by Risc/OS and later
> on continued to be used by IRIX.
>
>
>> case MIPS_ATOMIC_SET: {
>> /* This is broken in case of page faults and SMP ...
>> Risc/OS faults after maximum 20 tries with EAGAIN. */
>> unsigned int tmp;
>>
>> p = (int *) arg1;
>> errno = verify_area(VERIFY_WRITE, p, sizeof(*p));
>> if (errno)
>> return errno;
>> errno = 0;
>> save_and_cli(flags);
>> errno |= __get_user(tmp, p);
>> errno |= __put_user(arg2, p);
>> restore_flags(flags);
>>
>> if (errno)
>> return tmp;
>>
>> return tmp; /* This is broken ... */
>> }
>>
>> QUESTION 3) I notice that the code for this particular case of sysmips
>> has changed recently. The old code looked more like the 'll/sc' version
>> of glibc above. I would think that the 'll/sc' code would be better on
>> SMP systems.
>
>
> Don't think about SMP without ll/sc. There's algorithems available for
> that but their complexity leaves them a unpractical, theoretical construct.
>
>
>> Is there a good reason why this reverted?
>
Looking at 2.4.0-test5 I see the ll/sc code, but -test12 doesn't use it.
I was just curious at why it was taken out.
>
> Above code will break if the old content of memory has bit 31 set or you take
> pagefaults. The latter problem is a problem even on UP - think multi-
> threading.
>
> Finally, post such things to one of the MIPS-related mailing lists. If
> you're unlucky nobody of the MIPS'ers might see your posting on l-k.
>
> Ralf
--
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax : (256)-837-3839
-
To unsubscribe from this list: send 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: sysmips call and glibc atomic set
Ralf, firstly, thank you for the answers :)
Ralf Baechle wrote:
Ok, but since the kernel disables MIPS III you're limited to MIPS II anyway ...
This makes sense...
Read the ISA manual; sc will fail if the LL-bit in c0_status is cleared
which will be cleared when the interrupt returns using the eret instruction.
I tried to find a MIPSIII manual from mips.com but all I could find was
mips32 and mips64 (which are not the same as MIPSII/MIPSIII/MIPSIV).
Not having swap doesn't mean you're safe. Think of any kind of previously
unmapped page.
Is there a reason why it doesn't just force that page to be mapped first?
QUESTION 2) Wouldn't it be better to pass back the initial value of
*arg1 in *arg3 and return zero or negative error code?
The semantics of this syscall were previously defined by Risc/OS and later
on continued to be used by IRIX.
case MIPS_ATOMIC_SET: {
/* This is broken in case of page faults and SMP ...
Risc/OS faults after maximum 20 tries with EAGAIN. */
unsigned int tmp;
p = (int *) arg1;
errno = verify_area(VERIFY_WRITE, p, sizeof(*p));
if (errno)
return errno;
errno = 0;
save_and_cli(flags);
errno |= __get_user(tmp, p);
errno |= __put_user(arg2, p);
restore_flags(flags);
if (errno)
return tmp;
return tmp; /* This is broken ... */
}
QUESTION 3) I notice that the code for this particular case of sysmips
has changed recently. The old code looked more like the 'll/sc' version
of glibc above. I would think that the 'll/sc' code would be better on
SMP systems.
Don't think about SMP without ll/sc. There's algorithems available for
that but their complexity leaves them a unpractical, theoretical construct.
Is there a good reason why this reverted?
Looking at 2.4.0-test5 I see the ll/sc code, but -test12 doesn't use it.
I was just curious at why it was taken out.
Above code will break if the old content of memory has bit 31 set or you take
pagefaults. The latter problem is a problem even on UP - think multi-
threading.
Finally, post such things to one of the MIPS-related mailing lists. If
you're unlucky nobody of the MIPS'ers might see your posting on l-k.
Ralf
--
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax : (256)-837-3839
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
sysmips call and glibc atomic set
I'm working with a vr4181 target and started digging into the atomic
test and set stuff in the kernel and glibc. The first problem I had was
that the glibc code assumes that all mips III targets implement the mips
III ISA (funny assumption, no?) but the vr4181 doesn't include the
miltiprocessor oriented LL/SC operations for atomic test and set.
So I started looking at the glibc code (yes, I know this is the kernel
list... I'm getting there I promise) and notice the following operations:
__asm__ __volatile__
(".set mips2\n\t"
"/* Inline spinlock test & set */\n\t"
"1:\n\t"
"ll %0,%3\n\t"
".set push\n\t"
".set noreorder\n\t"
"bnez %0,2f\n\t"
" li %1,1\n\t"
".set pop\n\t"
"sc %1,%2\n\t"
"beqz %1,1b\n"
"2:\n\t"
"/* End spinlock test & set */"
: "=" (ret), "=" (temp), "=m" (*spinlock)
: "m" (*spinlock)
: "memory");
The significant code here being the 'll' and 'sc' operations which are
supposed to ensure that the operation is atomic.
QUESTION 1) Will this _ALWAYS_ work from user land? I realize the
operations are temporally close, but isn't there the possibility that an
interrupt occurs in the meantime?
Of course none of this code applies to my case anyway, since the vr4181
doesn't implement these ops. So once I hack^H^H^H^Hadjust glibc to use
the 'mips1' implementation, it uses the sysmips system call. regard :
_test_and_set (int *p, int v) __THROW
{
return sysmips (MIPS_ATOMIC_SET, (int) p, v, 0);
}
So then I looked at the kernel and find the code below. The system I'm
working with is expressedly uniprocessor and doesn't have any swap, so
it looks like the initial caveats are met, but it looks to me like there
could be some confusion if the value of *arg1 at entry looks like
-ENOSYS or something like that.
QUESTION 2) Wouldn't it be better to pass back the initial value of
*arg1 in *arg3 and return zero or negative error code?
case MIPS_ATOMIC_SET: {
/* This is broken in case of page faults and SMP ...
Risc/OS faults after maximum 20 tries with EAGAIN. */
unsigned int tmp;
p = (int *) arg1;
errno = verify_area(VERIFY_WRITE, p, sizeof(*p));
if (errno)
return errno;
errno = 0;
save_and_cli(flags);
errno |= __get_user(tmp, p);
errno |= __put_user(arg2, p);
restore_flags(flags);
if (errno)
return tmp;
return tmp; /* This is broken ... */
}
QUESTION 3) I notice that the code for this particular case of sysmips
has changed recently. The old code looked more like the 'll/sc' version
of glibc above. I would think that the 'll/sc' code would be better on
SMP systems. Is there a good reason why this reverted?
Sorry For the Long Post (tm)! Thanks In Advance! Merry Xmas!
--
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
sysmips call and glibc atomic set
I'm working with a vr4181 target and started digging into the atomic
test and set stuff in the kernel and glibc. The first problem I had was
that the glibc code assumes that all mips III targets implement the mips
III ISA (funny assumption, no?) but the vr4181 doesn't include the
miltiprocessor oriented LL/SC operations for atomic test and set.
So I started looking at the glibc code (yes, I know this is the kernel
list... I'm getting there I promise) and notice the following operations:
__asm__ __volatile__
(".set mips2\n\t"
"/* Inline spinlock test set */\n\t"
"1:\n\t"
"ll %0,%3\n\t"
".set push\n\t"
".set noreorder\n\t"
"bnez %0,2f\n\t"
" li %1,1\n\t"
".set pop\n\t"
"sc %1,%2\n\t"
"beqz %1,1b\n"
"2:\n\t"
"/* End spinlock test set */"
: "=r" (ret), "=r" (temp), "=m" (*spinlock)
: "m" (*spinlock)
: "memory");
The significant code here being the 'll' and 'sc' operations which are
supposed to ensure that the operation is atomic.
QUESTION 1) Will this _ALWAYS_ work from user land? I realize the
operations are temporally close, but isn't there the possibility that an
interrupt occurs in the meantime?
Of course none of this code applies to my case anyway, since the vr4181
doesn't implement these ops. So once I hack^H^H^H^Hadjust glibc to use
the 'mips1' implementation, it uses the sysmips system call. regard :
_test_and_set (int *p, int v) __THROW
{
return sysmips (MIPS_ATOMIC_SET, (int) p, v, 0);
}
So then I looked at the kernel and find the code below. The system I'm
working with is expressedly uniprocessor and doesn't have any swap, so
it looks like the initial caveats are met, but it looks to me like there
could be some confusion if the value of *arg1 at entry looks like
-ENOSYS or something like that.
QUESTION 2) Wouldn't it be better to pass back the initial value of
*arg1 in *arg3 and return zero or negative error code?
case MIPS_ATOMIC_SET: {
/* This is broken in case of page faults and SMP ...
Risc/OS faults after maximum 20 tries with EAGAIN. */
unsigned int tmp;
p = (int *) arg1;
errno = verify_area(VERIFY_WRITE, p, sizeof(*p));
if (errno)
return errno;
errno = 0;
save_and_cli(flags);
errno |= __get_user(tmp, p);
errno |= __put_user(arg2, p);
restore_flags(flags);
if (errno)
return tmp;
return tmp; /* This is broken ... */
}
QUESTION 3) I notice that the code for this particular case of sysmips
has changed recently. The old code looked more like the 'll/sc' version
of glibc above. I would think that the 'll/sc' code would be better on
SMP systems. Is there a good reason why this reverted?
Sorry For the Long Post (tm)! Thanks In Advance! Merry Xmas!
--
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
-
To unsubscribe from this list: send 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: Linus's include file strategy redux
Last I recall you have to at least have newlib around to get through the build process of gcc. libgcc doesn't affect the kernel but you can't do 'make install' without building it. BTW : The Linux newlib stuff should go a long way toward solving some of these problems (at least for x86 these days... other arches sure to follow) Peter Samuelson wrote: > [Joe deBlaquiere] > >> might be a good newbie filter... but actually the best thing about it >> is that the compiler people of the work might make generating a >> proper cross-toolchain less difficult by one or two magnitudes... > > > *WHAT*? How much less difficult could it possibly get? This is the > kernel, there is no cross-libc to worry about, so a cross-toolchain is > already down to a pair of CMMIs[1]. > > I do agree that anyone who can't do *that* should probably be using a > distro-packaged kernel > > Peter > > [1] configure-make-make-install -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 - To unsubscribe from this list: send 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: Linus's include file strategy redux
Werner Almesberger wrote: > Joe deBlaquiere wrote: > >> My solution to this has always been to make a cross compiler environment > > > ;-))) I think lots of people would really enjoy to have "build a > cross-gcc" added to the prerequisites for installing some driver > module ;-) > > I know, it's not *that* bad. But it still adds quite a few possible > points of failure. Also, it adds a fair amount of overhead to any > directory name change or creation of a new kernel tree. > might be a good newbie filter... but actually the best thing about it is that the compiler people of the work might make generating a proper cross-toolchain less difficult by one or two magnitudes... > >> The other advantage to this is that I can switch my host environment >> (within reason - compatible host glibcs, ok) and not have to change the >> target compiler. > > > Hmm, I don't quite understand what you mean here. > This way I can upgrade my host system from RH6.2 to RH7 and not worry about compiler differences affecting my kernel builds for the various projects I'm working on... including systems based on 2.0, 2.2 and 2.4... If anybody thinks gcc-2.96 messes up a 2.4 kernel, you should see what happens when you compile 2.0.33 ;o). > - Werner -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 - To unsubscribe from this list: send 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: Linus's include file strategy redux
My solution to this has always been to make a cross compiler environment (even if it is the same processor family). Thusly i386-linux-gcc knows that the target system's include files are in: /usr/local/-tools/i386-linux/include (/linux, /asm) The other advantage to this is that I can switch my host environment (within reason - compatible host glibcs, ok) and not have to change the target compiler. Werner Almesberger wrote: > [EMAIL PROTECTED] wrote: > >> Just out of curiosity, what would happen with redirection if your source >> tree for 'the currently running kernel' version happens to be configured >> for a different 'the currently running kernel', perhaps a machine of a >> foreign arch that you are cross-compiling for? > > > Two choices: > 1) try to find an alternative. If there's none, fail. > 2) make the corresponding asm or asm/arch branch available (non-trivial > and maybe not desirable) > > >> I do this: I use ONE machine to compile kernels for five: four i386 and >> one SUN4C. My other machines don't even HAVE /usr/src/linux, so where does >> this redirection leave them? > > > Depends on your distribution: if it doesn't install any kernel-specific > headers, you wouldn't be able to compile programs requiring anything > beyond what it provided by your libc. Otherwise, there could be a > default location (such as /usr/src/linux is a default location now). > > The main advantage of a script would be that one could easily compile > for multiple kernels, e.g. with > > export TARGET_KERNEL=2.0.4 > make > > Even if your system is running 2.4.13-test1. > > The architecture could be obtained from the tree or the tree could be > picked based on the architecture. This is a policy decision that could > be hidden in the script. > > - Werner -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 - To unsubscribe from this list: send 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: Linus's include file strategy redux
My solution to this has always been to make a cross compiler environment (even if it is the same processor family). Thusly i386-linux-gcc knows that the target system's include files are in: /usr/local/project-tools/i386-linux/include (/linux, /asm) The other advantage to this is that I can switch my host environment (within reason - compatible host glibcs, ok) and not have to change the target compiler. Werner Almesberger wrote: [EMAIL PROTECTED] wrote: Just out of curiosity, what would happen with redirection if your source tree for 'the currently running kernel' version happens to be configured for a different 'the currently running kernel', perhaps a machine of a foreign arch that you are cross-compiling for? Two choices: 1) try to find an alternative. If there's none, fail. 2) make the corresponding asm or asm/arch branch available (non-trivial and maybe not desirable) I do this: I use ONE machine to compile kernels for five: four i386 and one SUN4C. My other machines don't even HAVE /usr/src/linux, so where does this redirection leave them? Depends on your distribution: if it doesn't install any kernel-specific headers, you wouldn't be able to compile programs requiring anything beyond what it provided by your libc. Otherwise, there could be a default location (such as /usr/src/linux is a default location now). The main advantage of a script would be that one could easily compile for multiple kernels, e.g. with export TARGET_KERNEL=2.0.4 make Even if your system is running 2.4.13-test1. The architecture could be obtained from the tree or the tree could be picked based on the architecture. This is a policy decision that could be hidden in the script. - Werner -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 - To unsubscribe from this list: send 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: Linus's include file strategy redux
Werner Almesberger wrote: Joe deBlaquiere wrote: My solution to this has always been to make a cross compiler environment ;-))) I think lots of people would really enjoy to have "build a cross-gcc" added to the prerequisites for installing some driver module ;-) I know, it's not *that* bad. But it still adds quite a few possible points of failure. Also, it adds a fair amount of overhead to any directory name change or creation of a new kernel tree. might be a good newbie filter... but actually the best thing about it is that the compiler people of the work might make generating a proper cross-toolchain less difficult by one or two magnitudes... The other advantage to this is that I can switch my host environment (within reason - compatible host glibcs, ok) and not have to change the target compiler. Hmm, I don't quite understand what you mean here. This way I can upgrade my host system from RH6.2 to RH7 and not worry about compiler differences affecting my kernel builds for the various projects I'm working on... including systems based on 2.0, 2.2 and 2.4... If anybody thinks gcc-2.96 messes up a 2.4 kernel, you should see what happens when you compile 2.0.33 ;o). - Werner -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
