Re: [ql-developers] tk2
On Thu, Nov 18, 2004 at 12:22:58PM -, P Witte wrote: Hi, > Some time ago you asked me to look into a bug in the tk2 clone by HPR(?) but > I didnt have much success. Could you please tell me the status of that code. > Is it PD? Would it be ok for me to pass the source on to someone who might > be able to fix it? HPR wrote me that it is free of tk2 copyrights and he didn't impose any copyright restrictions himself. It is ok to pass the source to anyone. Distributing binaries would require a closer look at it, or just give it to people with legal tk2 license until we are sure. Richard
Re: [ql-developers] In search of a 68060RC 60MHz with 0E41J mask
On Tue, Aug 24, 2004 at 01:37:17AM +0200, Thierry Godefroy wrote: > MC68060RC60 are available... MC, not XC. Of course, I can't prove they > were available back in 2001, but that's beyond the point as even a RC50 > could have been overclocked to 66MHz... isn't RC the version without FPU and MMU? > I don't care about other processors, but if you remember all the fuss that > was made about just -one- bug in the Pentium FPU (the "divide bug", I bet > that Motorola was lucky that their processor was not as popular as the > Pentium... that would seem so. It is not just the 68060, 68040 has its problems too. As soon as you do things like MMU and cache your path is paved with workarounds for CPU bugs - and those guys who were doing SMP with m68k machines must really have white hair by now. Not to mention that the basic design of the MMU and cache is already extremely unforgiving.. Linux on 68060 has been debugged for almost a decade now and we are still finding cache and MMU related bugs. > I'm searching the proofs, but when you got a processor that can choke on as > simple a code as: > >.../... >Bcc LABEL_BANG >.../... > > LABEL_BANG MOVE An,USP <--- I11 errata: USP corrupted ! its SV mode code so you can reasonably work around by software. Have you actually seen QDOS code that would trigger that? The really worst bug is I16, except that is likely to be triggered only by intent. I did repeatedly look through the other bugs and don't think they would be triggered in QDOS code. Eg I could not think of any real life conditions where QDOS code would trigger I14.. now gcc has advanced to stage of producing such broken code. Richard
Re: [ql-developers] In search of a 68060RC 60MHz with 0E41J mask
On Mon, Aug 23, 2004 at 03:22:24PM +0200, Thierry Godefroy wrote: > > I'm quite upset !... > > I just discovered that my Q60 was fitted with a buggy 68060 ! > Yes, a pre-1996 mask 060 (1G65V mask), while my Q60 was built > as bought in 2001 !!!... This makes me wonder how many among > the Q60s have that same buggy processor fitted... > > I discovered this because Linux v2.4 got a recent fix for the > I14 errata of these buggy processor, and logs the activation > of the fix when the kernel boots. didn't look at it yet, does Linux actually test whether its an affected CPU, or just disable that optimisation? > This fix consists in setting > the bit 5 in the PCR (Processor Control Register), which > disables one of the optimisations of the 060. But there are no > less than 21 bugs in the maskset of my 060 !!!... No wonder why > I get weird results each time I try to modify SMSQ/E and QLib_run > in order make them work properly in copyback mode (currently, > QLiberated programs hang/crash/loop randomly when copyback is > enabled). I did once go through all the horrible 68060 errata and it doesn't appear SMSQ or QDOS would trigger any of these. > For the ones interested in the details about these bugs, they > will find the 68060 device errata document here: > http://www.freescale.com/files/32bit/doc/no_sub_type/MC68060DE.pdf > > Anyway... > > I'm now in search for a bug-less and full blown 60MHz 68060 > (0E41J mask ONLY)... does that exist? I think it exists only on paper or as RC/LC version :(( If you look at 68040 and 68060 errata lists you would be surprised that those CPUs ever worked, but apparently all but one of those bugs can be "managed" by OS software without significant performance degradation. Richard
Re: [ql-developers] Problem compiling Linux v2.4.27 on the Q60
On Fri, Aug 20, 2004 at 01:23:55AM +0200, Thierry Godefroy wrote: > Even weirder: by checking with ps the parameters passed by gcc to "as", I can > see that -m68040 of passed instead of -m68060, while gcc does receive the > -m68060 option ! historical baggage, 68060 support was added to gcc before it was added to binutils. Since than (2.7.2.3) gcc calls the assembler with -m68040 when 68060 was specified.. Richard
Re: [ql-developers] Problem compiling Linux v2.4.27 on the Q60
On Thu, Aug 19, 2004 at 12:46:48PM +0200, Thierry Godefroy wrote:
>
> On Thu, 19 Aug 2004 01:28:34 +0200, Richard Zidlicky wrote:
>
> >
> > On Thu, Aug 19, 2004 at 12:16:04AM +0200, Thierry Godefroy wrote:
> > >
> > > Hello...
> > >
> > > I tried to compile the v2.4.27 kernel for the Q60 today, but I came
> > > across a strange assembler error.
> > >
> > > I get:
> > >
> > > gcc -D__KERNEL__ -I/usr/src/linux-2.4.27/include -Wall -Wstrict-prototypes
> > > -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer
> > > -pipe -fno-strength-reduce -ffixed-a2 -m68060 -nostdinc -iwithprefix
> > > include -DKBUILD_BASENAME=setup -DEXPORT_SYMTAB -c setup.c
> > > {standard input}: Assembler messages:
> > > {standard input}:291: Error: invalid instruction for this architecture;
> > > needs fpu (68040, 68060 or 68881/68882) -- statement `frestore -4(%a6)'
> > > ignored
> > > make[1]: *** [setup.o] Error 1
> > >
> > > The weird thing is that the -m68060 option is passed and 'as' complains
> > > about no 68060 fpu...
> >
> > looks like a ".chip" directive from some earlier asm statement
> > did something strange, can you look at the assembler output?
>
> Yep, that's it apparently... The assembler produced (line 273 onwards):
> ---
> #APP
> .chip 68060; movec %pcr,%d2; .chip 68k
> #NO_APP
indeed, that is a recent change.
> I changed it for:
> asm __volatile__ (".chip 68060; frestore %0" : : "m" (zero));
>
> and everything seems to compile fine (resulting kernel still to be tested
> though)... Of course, there should be a different .chip directive for each
> processor type, I think (though frestore is perhaps assembled into the same
> opcode for all variations of CPU/FPU... I didn't check it either). It would
> be interesting to see what was in setup.c for Linux v2.4.23 (or 2.4.26),
> but I cruelly lack time and I no more got the sources handy.
>
> Nevertheless, it still sounds strange to me that "as" seems to ignore the
> -m68060 option passed to gcc (or is gcc not passing that option to "as" ?),
> as the '.chip 68060' should be implicit with -m68060 on...
pretty strange, ".chip m68k" should reset to the value defined by "-m"
or the default which would be 68020+fpu.
Strange thing is that it did never trigger before.. there are thousands
more .chip m68k directives in the sources and they always used to work
fine.
This is not Q40 specific, so has anyone else seen that?
BTW seems like you are the last hero compiling kernels on a m68k :)
Richard
Re: [ql-developers] Problem compiling Linux v2.4.27 on the Q60
On Thu, Aug 19, 2004 at 12:16:04AM +0200, Thierry Godefroy wrote:
>
> Hello...
>
> I tried to compile the v2.4.27 kernel for the Q60 today, but I came across a strange
> assembler error.
>
> I get:
>
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.27/include -Wall -Wstrict-prototypes
> -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe
> -fno-strength-reduce -ffixed-a2 -m68060 -nostdinc -iwithprefix include
> -DKBUILD_BASENAME=setup -DEXPORT_SYMTAB -c setup.c
> {standard input}: Assembler messages:
> {standard input}:291: Error: invalid instruction for this architecture; needs fpu
> (68040, 68060 or 68881/68882) -- statement `frestore -4(%a6)' ignored
> make[1]: *** [setup.o] Error 1
>
> The weird thing is that the -m68060 option is passed and 'as' complains about no
> 68060 fpu...
looks like a ".chip" directive from some earlier asm statement
did something strange, can you look at the assembler output?
> The v2.4.23 of the Linux kernel compiles just fine in this respect...
as did 2.4.26.
Richard
Re: [ql-developers] Debian support for the Q40
On Sat, May 08, 2004 at 04:03:33PM +0200, Peter Graf wrote: > > Richard Zidlicky wrote: > > >.. wait for an update, this kernel has not all necessary features > >turned on. New kernel will be there probably in the evening. > > > >BTW anyone interested in 68060-FEMU support in the kernel? > > Sure, I have an LC060 on my main machine. But probably not too soon. new kernel (date 8 May) is now available in the same place > > >> Why unmetered internet? Isn't it possible to install the packages > >manually > >> from a normal 68k Debian distro? > > > >installer support will be only in the newest bleeding edge > >tree, that means all stuff has to be downloaded.. certainly > >the debian-base images. > > Any estimates how long it'll take until it's in the normal distro? it won't take long untill it is in a "distributable" form. Installer for testing might be available next week. Richard
Re: [ql-developers] Debian support for the Q40
On Fri, May 07, 2004 at 10:49:04PM +0200, Peter Graf wrote: > > Richard, > > >we are curretnly working on debian support for the Q40, > >kernel images for test are available. > > > >First kernel images for test are here: > > > > http://master.debian.org/~cts/debian-m68k/kernel-image/ > > > >You can unpack the .deb package with "ar x deb" and > >install the kernel as usually. .. wait for an update, this kernel has not all necessary features turned on. New kernel will be there probably in the evening. BTW anyone interested in 68060-FEMU support in the kernel? > Many thanks. I hope that move will relieve you from distro maintainance > someday. > > >No specific support for installer yet, manual installation > >worked quite well last time tried. Currently this is only > >interesting for people with unmetered internet connection. > > Why unmetered internet? Isn't it possible to install the packages manually > from a normal 68k Debian distro? installer support will be only in the newest bleeding edge tree, that means all stuff has to be downloaded.. certainly the debian-base images. > I've ordered the full 68k 3.0r2 distro (+ Update 3.0r2-01) on CDs. If you'd > like copies, pls let me know. I wish Debian could use either names or numbers.. remembering which number is Sid, Woody, Potato, Sarge is a pain ;) The debian m68k disks are usable with the Q40 after manual installation.. not sure how usefull they are compared to ShoeString. Richard
[ql-developers] Debian support for the Q40
Hi, we are curretnly working on debian support for the Q40, kernel images for test are available. First kernel images for test are here: http://master.debian.org/~cts/debian-m68k/kernel-image/ You can unpack the .deb package with "ar x deb" and install the kernel as usually. No specific support for installer yet, manual installation worked quite well last time tried. Currently this is only interesting for people with unmetered internet connection. Richard --- Begin Message --- On Sat, May 01, 2004 at 08:57:38PM +0200, Richard Zidlicky wrote: > > I had a look at the relevant differences, should have additionally > to the debian config: Image liegt hier: http://master.debian.org/~cts/debian-m68k/kernel-image/ Ich hoffe, ich habe alle relevanten Aenderungen in das config eingebaut. Christian --- End Message ---
Re: [ql-developers] HTTP server speed test
On Sun, Feb 15, 2004 at 06:05:51PM +0100, Peter Graf wrote: > > Hi, > > is somebody out there who owns two networked PCs, one with a 10 Mbit/sec > ISA NE2000 (or clone) card, and could do a speed test using this PC as HTTP > server? > > With the Q60/QLwIP as server I currently get average 854 kBytes/sec HTTP > throughput, measured with Ethereal, transferring a file larger than 10MB. > It would be interesting how far from the optimal value this is still away. > if it is really reading all 10 MB of data from disk than thats very fast, the disk access wont allow for much faster operation. Otherwise pure networking speed over TCP gets very close to the theoretical 1.25 MB/s between 2 Linux computers Measuring with Ethereal is an overkill, better measure is ifconfig eth0; wget ; ifconfig eth0 ... returns raw and usable speed. I get this, 172.16.0.2 is the Q60 running Linux: ifconfig eth0; wget -O /dev/null http://172.16.0.2/file.xxx; ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:E0:7D:84:3B:FB inet addr:172.16.0.1 Bcast:172.16.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8278 errors:0 dropped:51 overruns:0 frame:8 TX packets:4756 errors:4 dropped:0 overruns:0 carrier:8 collisions:68 txqueuelen:1000 RX bytes:11069431 (10.5 Mb) TX bytes:398565 (389.2 Kb) Interrupt:12 Base address:0x2000 --18:22:46-- http://172.16.0.2/file.xxx => `/dev/null' Connecting to 172.16.0.2:80... connected. HTTP request sent, awaiting response... 200 OK Length: 10,485,760 [text/plain] 100%[>] 10,485,760 982.07K/sETA 00:00 18:22:56 (982.07 KB/s) - `/dev/null' saved [10485760/10485760] eth0 Link encap:Ethernet HWaddr 00:E0:7D:84:3B:FB inet addr:172.16.0.1 Bcast:172.16.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:15841 errors:0 dropped:51 overruns:0 frame:8 TX packets:8563 errors:4 dropped:0 overruns:0 carrier:8 collisions:68 txqueuelen:1000 RX bytes:22054706 (21.0 Mb) TX bytes:649940 (634.7 Kb) Interrupt:12 Base address:0x2000 So raw and usable speed are about 5% appart including HTTP overhead, 982 KB/s and 1028KB/s. Note that the timing may depend on the binary pattern of the file, eg a file consisting of all 0 should theoretically need considerably more time than a file with random patterns Richard
Re: [ql-developers] HD max size (was: Re: Linux Q40 Update)
On Wed, Dec 17, 2003 at 10:55:18AM +0100, Thierry Godefroy wrote: > All current day IDE drives are somewhat smaller than this upper limit, and > within a few years, ATAPI disk drives will raise the limit considerably. > == someone should update that text I guess ;) > I suppose your 'Gb' was 10^9 bytes one (the one HD manufacturers use in > their spec to make your believe that you got a bigger HD) and not the > -true- 1024^3 bytes Giga-byte, so I guess you simply hit the 128Gb limit > as described in the doc... pretty sure. Of course the limit is no longer there in any modern OS, it is only the complicated byteswapping that hit Q40 and Atari users again.. Richard
Re: [ql-developers] Linux Q40 Update
On Wed, Dec 17, 2003 at 01:19:47AM +0100, Thierry Godefroy wrote: > > On Mon, 15 Dec 2003 23:37:44 +0100, Richard Zidlicky wrote: > > > Hi, > > > > a short roundup of issues I am messing with: > > > > !!! WARNING !!! Kernel 2.4.18 (probably anything <2.4.21) > > will eat filesystems on disks>137GB. > > * chuckles * I didn't even figured out how to get this damned > atari_fdisk to properly enable and setup extended partitions, > so my 20Gb HD is pretty much underused already... strange, that was not the slightest problem for me.. currently there are 2x60GB disks under the hood. At least you dont have to think about the 137 GB problem. > > plenty of updated user packages and libs > > > > gcc issues: > > > > - libgcc_so in gcc3.3 is incompatible with previous versions > >due to a change (a real improvement actually ;) in m68k exception > >handling and version number wasnt bumped accordingly.. this makes > >system upgrades not practical for average user. > > No chance to install the two libraries in parallele ? would work, but each approach has some drawbacks: - different so-numbers, also different than the rest of the world, forgetting to patch a new gcc release would result in problems. I am not really sure if the version numbers could ever meet again. - different libdir, different loadpath. Default ld.so cant do that without help.. supposedly it is possible to hardcode ldpath into the old binaries but I have never tried. Even worse, having 2 versions of libgcc_so would probably mean to keep 2 version of some other c++ libs. So far I simply ignore the few hundred c++ programs that are broken by the new libs in the hope to get them recompiled soon. > > So a gcc v3.2 or 3.3 for the Q60 soon ? :-) perhaps 3.4, the coreutils/sha1 problem turned out to be very likely another 3.3.x bug.. one of those really nasty to debug ones. > > On an obscure sidetrack of development, I have a functional > > but slightly buggy native ocaml compiler for m68k > > (http://www.ocaml.org/).. needed a fast and reliable RAD > > language to update the dated, slow and insecure cgi scripts > > in the Q40 distribution. > > RAD ? rapid application development, buzzword but you get the idea. It beats most other langauages when comparing lines of code length while still beeing slightly more readable than APL or perl. Ocaml is also one of the few high level languages that can beat the speed of compiled c on many tasks. Richard
[ql-developers] Linux Q40 Update
Hi, a short roundup of issues I am messing with: !!! WARNING !!! Kernel 2.4.18 (probably anything <2.4.21) will eat filesystems on disks>137GB. Newer kernels will not eat anything but only use max 137GB on the Q40. The problem is well understood but not trivial to fix in a way that preserves compatibility and is clean enough to get accepted into mainstream. Actually, even a quick and dirty fix is anything but easy. Kernel 2.6 didnt boot last time I looked.. problem was probably introduced around 2.5.99+, appears like an issue with the fragmented Q40 memory map. rpm-4.2x works well with a patch ;) glibc-2.3 works :) plenty of updated user packages and libs gcc issues: - libgcc_so in gcc3.3 is incompatible with previous versions due to a change (a real improvement actually ;) in m68k exception handling and version number wasnt bumped accordingly.. this makes system upgrades not practical for average user. - patches to improve 68060 performance available (longlong instructions are most affected) - ide-cd ICE problem may have been fixed in CVS according to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12008 but I didnt have a chance to test yet. For gcc-3.0 I use a dirty workaround that simply disables the failing sanity check - global register variables problem still survives every attempt to get fixed properly. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7871 Current showstopper on the way to an updated distribution is coreutils - sha1sum produces wrong results and I need to figure out whether it is gcc or coreutils bug before proceeding. On an obscure sidetrack of development, I have a functional but slightly buggy native ocaml compiler for m68k (http://www.ocaml.org/).. needed a fast and reliable RAD language to update the dated, slow and insecure cgi scripts in the Q40 distribution. Richard
Re: [ql-developers] News RPMs for Q60-Linux
On Sun, Dec 14, 2003 at 11:40:14AM +0100, Thierry Godefroy wrote: > > Hello all ! > > I'm in the process of updating my Linux-Q60 website. New RPMs have already been > made available: > > - Patches for Linux kernel v2.4.23. > - Linux kernel v2.4.23 (with cryptoloop and supermount patches). wrt supermount, did you look at http://submount.sourceforge.net/? > - losetup/mount v2.11z: crypto-API aware, compatible with the old International > kernel crypto patch. Should also work with loop-AES (untested). it may work only partially with loop-AES, iirc some options are different > - dillo v0.8.0-pre: CVS pre-release (expect many core dumps !) with patch for > frames support ! very good news! Richard
Re: [ql-developers] Massive amount of job state transitions and re-scheduling
On Tue, Sep 09, 2003 at 01:37:53AM +0100, P Witte wrote: > > Peter Graf writes: > > > >Yes, this I know, thanks... I'm perfectly aware of the fragmentation and > of > > >out of order receipt of TCP packets... That doesn't change the fact you > could > > >use the fast interrupt to store as many TCP packet as needed (i.e. when > they > > >come in), into a buffer (organized as a linked list of recieved packets), > > >then to transfer the whole lot of packets to the higher level layers of > the > > >TCP/IP stack at once and every 1/50th of second... > > > > Obviously correct but useless. Try to understand that the problem in your > > approach is latency and can not be solved by buffering, no matter how > > efficient buffering is implemented. > > > > Simple example: A M$ or Unix machine sends a file to the QDOS machine via > > TCP. It will send one or two packets, then stop and wait for ACK. Further > > packets will only be sent after further ACKs. Your ACKs can only be > > generated in 50 Hz rhythm, so packets will crawl one-by-one in 50 Hz > > rhythm. (Or two-by-two, if you're lucky.) > > But does the incoming data need to be processed in any way before > acknowledgement? Why cant the ISR simply receive and buffer the data and > then send the ACK before exiting, leaving any processing to the higher > levels? my impression is that to do that for TCP you would have to do all of the protocol implementation into the ISR > In our January discussion you mentioned the case of echo. There is nothing > to stop you from implementing time-critical routines, like echo, in the > 'physical layer'. well there is, as long as QDOS won't allow reschedule after interrupts. Echo is supposed to be a normal application and you would not move it into the ISR layer. As I said it isn't hard to change ISR handling in QDOS and I will certainly do it, right now I have other things that need to be done. Richard
Re: [ql-developers] Massive amount of job state transitions and re-scheduling
On Sun, Sep 07, 2003 at 10:48:50PM +0200, BRANE wrote: > > > - Original Message - > From: "Peter Graf" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, September 07, 2003 9:53 PM > Subject: Re: [ql-developers] Massive amount of job state transitions and > re-scheduling > > > Simple example: A M$ or Unix machine sends a file to the QDOS machine via > > TCP. It will send one or two packets, then stop and wait for ACK. Further > > packets will only be sent after further ACKs. Your ACKs can only be > > generated in 50 Hz rhythm, so packets will crawl one-by-one in 50 Hz > > rhythm. (Or two-by-two, if you're lucky.) > > AFAIK with TCP/IP this is negotiable. There is no need for such small > window... don't forget this is a rather simple TCP/IP implementation and apparently it is already hard enough to make the simplest variant working reliably with the garden variety of TCP/IP implementations out there. Richard
Re: [ql-developers] Massive amount of job state transitions and re-scheduling
On Fri, Sep 05, 2003 at 09:18:52PM +0200, Thierry Godefroy wrote: > > Is it even possible that the number of SUSJB/RELJB/PRIOR calls per frame > > interrupt is limited? > > Well, I guess the problem is that all three calls are exiting via the > scheduler (they are not atomic traps). My guess is that calling them in > rapid succession (more than once every 1/50th of second) makes the job > to reenter recursively the scheduler and to fill up the supervisor stack... I don't see how this could happen. The calls will exit through scheduler which will cleanup supervisior stack before returning to usermode. The problem could only arise when you call either of this traps from supervisormode which is a very bad idea anyway. > Plus, I'm a bit surprised that you are apparently using jobs to fetch the > data from the ethernet card... It should be done via an interrupt handler > instead... Actually, the best design would be to have the Q60 fast interrupt > handler to fill a buffer, and a frame interrupt task to move the data from > that buffer into a bigger one for your job to fetch it in big chunks...). this was discussed a while ago here, the big problem is that neither QDOS nor SMSQ will attempt to reschedule after interrupt handling and there is no way to deal with the complexities of the TCP/IP protocol inside the interupt handler. That means sending of protocol replies would be very often delayed by 1/50s which would make especially TCP crawl.. Richard
Re: [ql-developers] Re: [ql-users] Dual IDE controller needed for Q40 - Will Exchange :-)
On Tue, Dec 02, 2003 at 04:48:26AM -0500, "Phoebus R. Dokos (?? ?. ??)" wrote: > BTW: For some reason Shoestring Linux recognizes all drives as 2.88 Meg > ones... anybody know why is that? this is because some of hardcoded value in , iirc it is used only for buffer allocation. If you get an ED controller it should work. Richard
Re: [ql-developers] ide-scsi option in Linux 2.4.21
On Mon, Sep 01, 2003 at 12:01:39PM +0200, Thierry Godefroy wrote: > > So you must compile as a module either the ATAPI CD-ROM driver or the > ide-scsi driver. I, for one, always built the IDE-ATAPI into the kernel > and the ide-scsi as a module, allways do it that way. Apparently stopped working now. But then again, ide-scsi can do everything ide-cd does so appart of saving a few bytes it should work fine to leave out ide-cd and have ide-scsi hardwired. Actually makes installation procedure simpler as CD will be always scd0 then ;) Richard
Re: [ql-developers] ide-scsi option in Linux 2.4.21 (was: Re: Linux v2.4.21 compilation error with gcc v3.1)
On Sun, Aug 31, 2003 at 08:04:05PM +, Branko wrote: > > > simply doesn't work if ide-cd is compiled into the kernel, ide-cd > > claims the driver and ide-scsi can't be activated. > > This can't be m68k specific but strangely I have't seen anything > > about it in the linux-kernel ml. > > > > Richard > > > > > > At least on Wintel, ide-cd and ide-scsi should always be compiled as a > modules... this does work, slightly impractical as it makes it more difficult to use the same kernel for rescue/installation and production use. Richard
Re: [ql-developers] ide-scsi option in Linux 2.4.21 (was: Re: Linux v2.4.21 compilation error with gcc v3.1)
On Sun, Aug 31, 2003 at 10:36:07AM +0200, Thierry Godefroy wrote: > > On Sat, 30 Aug 2003 11:30:21 +0200, Richard Zidlicky wrote: > > > Btw, did someone notice that hdX=ide-scsi is handled differently in > > 2.4.21? > > Hmm... Didn't notice any difference on ix86 plateforms where I use this > option (I don't use it on the Q60, for I got no CD-R writer on it)... > What's wrong with it ? simply doesn't work if ide-cd is compiled into the kernel, ide-cd claims the driver and ide-scsi can't be activated. This can't be m68k specific but strangely I have't seen anything about it in the linux-kernel ml. Richard
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Sun, Aug 24, 2003 at 11:25:05AM +0200, Thierry Godefroy wrote: Btw, did someone notice that hdX=ide-scsi is handled differently in 2.4.21? Richard
Re: [ql-developers] uQLx for Mac OS X!
On Thu, Aug 28, 2003 at 09:27:46AM -0400, "Phoebus R. Dokos (?? ?. ??)" wrote: > > On Thu, 28 Aug 2003 12:06:37 +0100, Mark Swift <[EMAIL PROTECTED]> > wrote: > > > > > > >Just downloaded this - it works on my 12" powerbook with 10.2.6 > >& Apple's X11 public beta 3. It also works for me on 10.2.3. fantastic! > > > >Originally I had XDarwin installed (non apple XFree86). This didn't work, > >so I dumped it and installed Apple's X11 instead. > > > >Does anyone know when the altered source is to be integrated into > >the current uqlx sources? Also, which gcc was used? I've tried and > >failed to build a working copy from the current sources many times :( > > > >Mark Swift > > Hi Mark, > I am not sure regarding the altered sources. Richard will have to answer > this. I am incorporating changes frequently, I just don't have the time to do thorough testing. If you want experimental sources just email me. To build it on MacOS X you probably need to disable the global register optimisation for PPC. gcc 3.1-3.3.1 is broken so you can either patch gcc as explained in the README or disable the optimisation in QL68000.h Since less people are likely to patch gcc I will disable it by default in the next version :( Richard
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Sat, Aug 23, 2003 at 08:55:28PM +0200, Thierry Godefroy wrote: > I got no compatibility problem with the crypto API but for when > they changed from 2.2 to 2.4 kernel (the data had to be transfered > to a new encrypted volume, but that's all). it will change again for 2.6, probably a few times yet. > Also, the crypto API is to become the standard, so I'd recommend > starting to get used to it right now instead of using a third party > software which seems pretty much incompatible with the crypto API > (as far as I could see by reading the loop-AES documentation). the standard is just emerging, it had 2 versions with incompatible disk formats last 2 weeks and mount options are still subject of discussion.. not a good time to get used to it. So far it seems loop-AES can encrypt or decrypt all formats except perhaps some of those with broken IV keys. > > that looks very strange. Perhaps I can make some sense out of > > it when I see the patch. > > Alas, there's some weirdness in the rc.sysinit script of ShoeString: > it looks like a line in fstab such as: > > /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0 no idea. What would "mount -a" do if that line is in /etc/fstab? Mine simply complains no such fs and that's it but I have newer version of the script. I don't see anything in the script itself. > # Source functions > . /etc/init.d/functions > > action $"Super-Mounting the CD-ROM: " mount /mnt/cdrom /mnt/cdrom -t supermount -o > fs=iso9660,dev=/dev/cdrom,ro > action $"Super-Mounting the floppy: " mount /mnt/floppy /mnt/floppy -t supermount -o > fs=vfat,dev=/dev/fd0 this is a good idea, much easier to provide as fully configured but optional addon. Richard
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Fri, Aug 22, 2003 at 03:47:05PM +0200, Thierry Godefroy wrote: > > have you seen this? > > Bruce Schneier CRYPTO-GRAM, September 15, 2002 > > http://www.counterpane.com/crypto-gram.html > > No, I didn't see it... Interesting... But you didn't quote the conclusion: I think it is not wise to quote any conclusion unless it is the mathematical proof of the possibility to crack (or not) the algorithm. Otherwise new attack techniques could be found any day. > Still, it's a good thing to stay tuned... Also, for really sensitive data, > it's better to use a double encryption scheme, using two different > algorythms (and keys, of course). this is a difficult subject, as far as I am aware opinions are fairly varied whether this will increase safety - in theory it might also hurt safety unless proven otherwise. > Yes, but even if a 060 can perform twice as fast as a Pentium at the same > frequency, the modern Pentiums/Athlons run at 20 times the 060 (core) > frequency... I have a datapoint with serpent256 here: # ll -rw-r--r--1 rz rz 98693120 Oct 5 2002 x.tar # time cat /tst-loop/x.tar >/dev/null real2m14.115s user0m0.190s sys 0m19.090s Loop dev used about 100s for the decryption. Depending on application this may be fast enough. Compared to raw read it appears to slow down things by factor 3 in the worst case. This is loop-AES with additional ciphers btw and I would recommend to stick with that as it will be maintained for the foreseeable future. The other intl patches are bound to suffer incompatible changes every week now that intl stuff was included into 2.6 I will send you the sources of patched util-linux, can be a real pain to sort out these patches. > > so it becomes immediately unmounted as soon as you close last > > reference? > > No, the device is permanently mounted and the driver reports an absent > medium when accessed without a proper medium in the drive... that looks very strange. Perhaps I can make some sense out of it when I see the patch. > ??? Never had a single problem compiling v2.4 kernels with gcc 2.95.3 > on Mandrake 7.2... _But_ I always used -fno-omit-frame-pointer to avoid > the -O2 optimization bug in gcc 2.95... it did strange things on m68k. Overwritten live registers as well as forgotten stack pointer and such. > Also, did you check this patch: > http://gcc.gnu.org/ml/gcc-regression/2000-11/msg2.html > It was for egcs but it looks like the cure to the same problem we got > in gcc... Looking at the various patches, perhaps I have some idea. So far I have simply disabled the check in the compiler because it appears to be internal consistency checking only and should not trigger any new errors. Richard
Re: [ql-developers] Mini Qx0 Linux distro
On Fri, Aug 22, 2003 at 01:56:06AM +0200, Thierry Godefroy wrote: > > apt_get is quite brilliant at sorting everything out. > > There are equivalent tools to app-get for RPMs now (urpmi, grpmi, etc)... iirc there is also apt-get for rpm now. Richard
Re: [ql-developers] uQLx for Mac OS X!
On Thu, Aug 21, 2003 at 10:03:12PM -0500, Mark Martin wrote:
>
> Quoting "Phoebus R. Dokos" <[EMAIL PROTECTED]>:
>
> > a uQLx port for Mac OS-X (with Apple's X11) has been added thanks to the
> > work of James Weatherley (You rock!) as you already know.
> > Now it is also available online!
>
> Has anyone else had luck getting this to run? On my G4, with 10.2.6, I only
> get bus errors. Running Apple's X11 public beta 3.
seems to work fine for some people but I have no way to test.
> I got the exact same thing
> when I tried building it a while back on my Sparc Slowaris box, so it's
> strangely comforting in it's familiarity. :)
which gcc? Versions 3.1-3.3.1 have the bug mentioned in README, this
also affects hppa, ppc and mips boxes at least.
Alternatives would be
- use earlier gcc, on ppc 2.95, mips/SPARC/hppa anything 2.6.2-2.8
- patch compiler (patch in README)
- disable global register usage in QL68000.h. To do this for SPARC
you would uncomment these lines:
#ifdef SPARC
register uw16 *pc asm("g5");
register gshort code asm("g6");
register int nInst asm("g7");
#define GREGS
#define MANYREGS
#endif
> I tried invoking ./qm, and then variations on that like ./qm -o
> romdir/Min166.rom. It's crashing in strlen(), which is being invoked
> (eventually) by QMParams() (which is invoked by SetParams()). I could go
> digging into the code and find why, but thought I'd see if it's just OE first..
that doesn't look familiar and may be something else than the mentioned
gcc bug.
A gdb baktrace would be definitely helpful.
Richard
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Fri, Aug 22, 2003 at 02:14:54AM +0200, Thierry Godefroy wrote: Hi, > Actually, this is not quite exact. It is true that more cryptoanalyis > was done on Serpent (which algorythm is easier to analyse). But so far > more rounds have been broken in AES (Rinjdael) than in Serpent (unless > I missed one of the lastest articles about thos algorythms, which is > possible). have you seen this? Bruce Schneier CRYPTO-GRAM, September 15, 2002 http://www.counterpane.com/crypto-gram.html << Let's start from the beginning. A few months ago, Courtois and Pieprzyk posted a paper outlining a new attack against Rijndael (AES) and Serpent. The authors used words like "optimistic evaluation" and "might be able to break" to soften their claims, but the paper described a better-than-brute-force attack against Serpent, and possibly one against Rijndael as well. Basically, the attack works by trying to express the entire algorithm as multivariate quadratic polynomials, and then using an innovative technique to treat the terms of those polynomials as individual variables. This gives you a system of linear equations in a quadratically large number of variables, which you have to solve. There are a bunch of minimization techniques, and several other clever tricks you can use to make the solution easier. (This is a gross oversimplification of the paper; read it for more detail.) The attack depends much more critically on the complexity of the nonlinear components than on the number of rounds. Ciphers with small S-boxes and simple structures are particularly vulnerable. Serpent has small S-boxes and a simple structure. AES has larger S-boxes, but a very simple algebraic description. (Twofish has small S-boxes, too, but a more complex nonlinear structure. No one has implemented the attack against Twofish, but I'm not willing to stand up and declare the cipher immune.) These are amazing results. Previously, the best attacks worked by breaking simplified variants of AES using very impractical attack models (e.g., requiring immense amounts of chosen plaintext). This paper claimed to break the entire algorithm, and with only one or two known plaintexts. Moreover, the first cipher broken was Serpent: the cipher universally considered to be the safest, most conservative choice. >> > The reason why Rinjdael was choosen as the AES instead of Serpent is > unclear and even highly suspicious to me... It is admitedly a little > faster than Serpent, but was pointed out as less secure than Serpent > too (and as it was not as much crypto-analyzed as Serpent, one may find > a shortcut attack on day or another...). My thought is that the NSA is > probably quite interested in having an AES algorythm which is not too > difficult to break... quite possible. There are other reasons, iirc AES was designed for easy use in smartcards and such, not necessarilly to protect gigabytes of sensitive information. > I personally use Serpent with 256 bits keys for > the encrypted partitions on my PCs. It's of course probably too slow > for the Q60 though (128 bits keys seem more reasonable for a poor > 68060 @ 66MHz to deal with...). might not be so bad on the Q60, remember that bitshuffling is traditionally the strongest domain of 680x0 CPU's. > > appart of the extra demon this sound really very much like what autofs > > does for me. How does it work to release a medium, eg CD or floppy? With > > autofs I have to wait until it timeouts. > > No wait with SuperMount. It's just like if you were using the medium under > DOS/Windoze (Yuck !), or SMSQ/E... It's 100% kernel based and done at the > driver level... The problem is that its author doesn't maintain it anymore > and all the maintnance is now done by the Mandrake developers, and scattered > in numerous patches to each kernel... I know, the details were a bit too fishy last time I looked. > It's like a filesystem driver. You configure it in fstab, example: > > /mnt/dos/a /mnt/dos/a supermount fs=vfat,dev=/dev/fd0 0 0 > /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0 so it becomes immediately unmounted as soon as you close last reference? Could do that with autofs as well but don't like it because it apparently looses cached buffers on CD roms. > > probably not, the problem is m68k specific afaics and Mandrake gets > > much less non-x86 testing than RedHat or Debian does. > > Mandrake doesn't develope at all for the m68k architecture, alas... certainly not, neither does RedHat. Otoh you will find patches for the stangest architectures in RH so there is apparently a lot of inofficial development or cross-distibution fertilisation going on. > Do you know if the same problem would arise with older gcc version > (I was thinking to compile it with gcc-2.95.3...) ? not this problem but more serious ones. gcc303 might work and is reasonably tested with 2.4 kernels. > > > If you got a file server (ftp, sftp, web) where to get them, I'd prefer > > > that w
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Wed, Aug 20, 2003 at 04:24:20PM +0200, Thierry Godefroy wrote:
Hi,
> I'm using the full crypto-API (with all the ciphers; AES being a rather
> weaker one than Serpent, for example...).
Serpent is distributed in the ciphers package of loop-AES.
It is an extra download but no hassle compile.
Btw some recent cryptoanalysis suggests AES is actually less
susceptible to a certain type of attack then Serpent so it
is far from easy which one is weaker. Still no immediate
threat.
> > What is the advantage of SuperMount over autofs?
>
> It's 100% automatic, doesn't need for any demon, and it doesn't hog the
> processor/drives by checking every few seconds that a new medium was
> inserted... As soon as an access is requested to a supermounted medium,
> then a check for changed/absent medium is made transparently for the user.
> It's the standard 'automounter' for Mandrake and I just love it. :-)
appart of the extra demon this sound really very much like what autofs
does for me.
How does it work to release a medium, eg CD or floppy? With autofs I have
to wait until it timeouts.
How do you configure it?
> Hmm... Strange... Mandrake's patched version of gcc v3.2.2 doesn't
> got this problem on i586 Linux... Perhaps would it be worth rebuilding
> the Mandrake gcc package for Linux-Q60 ?
probably not, the problem is m68k specific afaics and Mandrake gets
much less non-x86 testing than RedHat or Debian does.
I looked deeper into it, it is the assignment to error.all which
barfs the compiler. Translated to RTL this assignment is apparently
too complicated for the register life analysis to grok and it won't
set a REG_DEAD note to error.all where it should.. somewhere the
strict_low_part is in the way.
As a workaround try to declare
char xerr
assign to xerr and return xerr.
Also attached minimal testcase if you want to compare various compiler
versions, use "-da" to get dumped all RTL passes.
> If you got a file server (ftp, sftp, web) where to get them, I'd prefer
> that way (faster now that I got an ADSL link ;-)...
well I didn't get ADSL, the sourceforge site is still available of
course.
> Gnome2 is a real nightmare and it sucks big time !!! Man, was I pissed
> off when I installed Mandrake v9.1 to update my good ol' Mdk 7.2 on my
> PCs... This stupid new Gnome is not only utterly broken, but it's a
> Hell to configure (they made the configuration 'simpler' by removing
> most of the options: the net result is that you can't get it to work
> your own way. If the default behaviour is fine with you then it's
> alright, else, you can spend hours trying to figure out what to do
> to obtain what you want !). Plus it eats 24Mb more memory than Cnome
> 1.2 on my PCs and is utterly sloww: it's definitely a no-no for a
> Q60, forget it altogether and stick with Gnome v1.4... or better, use
> a lighter, standalone WM, like Icewm (v1.0.9 available on my website),
> Blackbox or the like...
I like fluxbox a lot, the libs of Gnome2 will be still needed though.
> I never had problems with rpm 4.0 on Mandrake, but they pretty much
> changed everything compared to rpm v3... Even the databases are
> incompatible... Who said "upward compatibility" ? It looks like
> this concept was lost and forgotten a couple of years ago already...
Mandrake seems a bit radical with updates. My problem with rpm-4.1x
on the Q60 is that computation of the signature is sometimes broken,
probably a compiler problem.
Rebuilding the database was a bit of a hassle but no problem, old
packages work fine.
Richard
typedef union {
unsigned all :8;
} x_t;
char test_x (char sv)
{
x_t error;
if (sv)
{
error.all = sv;
}
return error.all;
}
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Wed, Aug 20, 2003 at 01:22:19AM +0200, Thierry Godefroy wrote: > > Hi ! > > In an attempt to bring more pre-compiled packages for the ShoeString > distribution, I tried to compile the latest Linux kernel (with the > crypto API patch and the SuperMount patch). I was using loop-AES with additional ciphers which worked reliably for the last few months. What is the advantage of SuperMount over autofs? > Alas, the compiler stops > with an internat error; I tried twice, to check it was not due to > a corrupted memory or processor overheating error (unlikely as my > 060 is quite cool, equiped as it is with a heatsink+fan). I assume > it's a gcc bug... Did anyone else encountered it ? Did anyone > compiled a newer gcc version (Richard, perhaps ? :-) it is a compiler bug, the new ide core included since 2.4.21-rc6 triggers it and I didn't succeed to fix it in gcc-3.2. I am currently testing gcc-3.3.1. The gcc in ShoeString is not very good anyway. I have compiled gcc-3.2 and glibc-2.2.x (as well as 2/3 of RH 8.0) which appeared to work remarkably well (with patches) but something got terribly screwed up just before I could made a release - the compiler no longer bootstrapped :( I can mail you a CD with many new packages which would be useful for development purposes only, I can't spend any time to create update or installation routines when a few essential packages are broken (gnome-2.x) or have strange quirks (rpm-4.x) Anyway even 3.2 has this problem so I am currently testing gcc-3.3.1. Richard
Re: [ql-developers] Ethernet card for Q60
On Tue, Aug 12, 2003 at 06:46:27AM -0400, "Phoebus R. Dokos (?? ?. ??)" wrote: > >>I wonder if that will work with the Intel 100Mbps ISA adapters that I > >>had found > >>Peter is it possible for you to test it? > > > >You mean a DOS program on dosemu on qemu on Linux on Qx0 on your card? > >Right now I'd prefer to leave tests like this up to you > >:-) > > I would but I don't have the card anymore ;-) > Oh well, I will try to locate another one and try again! (But it may take > three to four weeks) wasn´t that a hardware problem? It won´t go away with software. Richard
Re: [ql-developers] Ethernet card for Q60
On Wed, Aug 13, 2003 at 08:23:38AM -0400, Phoebus R. Dokos wrote: > I don't think that it *EVER* was NE2000 compatible... The reason why I got > that card was that Shoestring Linux says that with the new kernel *ALL* > cards should work. Might need a little more explanation: with 2.4 kernels practically all Linux drivers for ISA network cards should be usable on the Q40. You will still need to find the right driver and compile it. I could have precompiled some of them but I have no idea what other than NE2K drivers are still usefull for ISA buses >I thought it was only a IRQ/Address problem. > Theoretically (and I cannot really remember now) the card should have an > EPROM on it that retains settings. Practically however (as I have seen on > other cards that claim to have that), once you remove it from the host > system, the EPROM is cleared () qemu perhaps could help there but io ports access using /dev/ports may not be implemented yet for dosemu so don´t showel too many complications on you. Richard
Re: [ql-developers] Ethernet card for Q60
On Mon, Aug 11, 2003 at 05:06:15PM +0200, Thierry Godefroy wrote: > > Hi all ! > > I'm trying to configure an ISA PnP card (RTL8019AS based) for use on > my Q60. The card got a "jumperless" mode (i.e. a mode where PnP is > disabled) that may be enabled via a DOS software (on a PC) ^ I have just ported qemu (http://fabrice.bellard.free.fr/qemu/) for linux-m68k so it should be possible to do it on the Q60 just as well :) Haven't tried dosemu or wine yet. > I tried several configurations, but only IRQ 10 seems to allow the Q60 > to boot properly (IRQ 5, although theorically available, makes the Q60 > unstable and it crashes either at SMSQ/E boot time, or at the Linux > loader execution time). Peter's explanation is the most likely. Richard
Re: [ql-developers] Job re-scheduling
On Sat, Jan 18, 2003 at 10:39:58AM -, P Witte wrote: > Since only a > specific effect is required in rather exceptional circumstances, wouldnt it > be better to handle that from the calling code instead? it isn't exceptional circumstances, I am really surprised why nobody noticed that before.. perhaps old QL devices were just so slow that another 1/50s didn't matter that much. Basically every interrupt except the 50 Hz timer will be on behalf of some job io so it seems quite natural to reschedule after interrupts. > Marcel has refined > his suggestion as follows. I quote: > > # By exiting the interrupt handler through the sms.rte function the > # requested re-schedule will be done immediately if possible (i.e. no > # supervisor code was running at that time). Example: > # > # include dev8_smsq_smsq_basekeys > # include dev8_keys_psf > # > # int_handler > # movem.l psf.reg,-(sp) > # > # [blah] > # > # st sys_rshd(a6); Request re-schedule > # move.l sms.rte,a5 ; ...now would be convenient > # jmp (a5) > > This, I believe, produces the same result, but without any chance of side > effects. if it works as advertised it would indeed solve the problem. It has an immediately obvious side effect - interrupt routines that are later in the chain will not be processed anymore. It would be cleaner if the interrupt routine would just set sys_rshd and QDOS/SMSQ would honour it after processing all other isr. > > sys_rshd is not a bad idea, it might be usefull if it had some > > at least this states: > > - no action > > - run through poll tasks > > - run complete scheduler > > > > That would probably require the complete rewrite of all the 10 lines > > of scheduler in jsrom :) > > Then why not go the whole hog and design a scheduler that will allow > time-critial "systems jobs" to run with "hard" priorities (while "user jobs" > get the remaining CPU cycles employing relative priorities, as before)? I don't have that good experience with hard priorities so I would think twice before complicating the scheduler for them. Otoh checking for sys_rschd after isr processing looks really trivial and top priority now. Richard
Re: [ql-developers] Job re-scheduling
On Thu, Jan 16, 2003 at 01:10:11AM -, P Witte wrote: > > > # He can request a re-schedule simply by setting the sys_rshd system > > > # variable to $FF. This will then be checked every time an SMSQ trap is > > > # invoked, which should normally happen very often. I think this should > > > # be good enough for his problem. > > > > this may help, but usually only in situations where it isn't needed > > anyway. A similar effect could be achieved on all QDOS variants by > > setting sv.pollm, although this has slide sideeffects. > > > > I looked at js rom and it appears really trivial to fix properly > > so why some workaround that doesn't help? > > Could you please be more specific as to what sort of "fix" you have in mind? look at the interrupt handling routine in jsrom (0x352-0x3a0). Instead of doing '0003A0 BRA L003B6' test for sys_rshd and conditionally branch to 0x936 Or a lot easier to patch, branch to 0x3a6 and let the EISR manipulate sv.pollm. sys_rshd is not a bad idea, it might be usefull if it had some at least this states: - no action - run through poll tasks - run complete scheduler That would probably require the complete rewrite of all the 10 lines of scheduler in jsrom :) Richard
Re: [ql-developers] Job re-scheduling
> >For me this means that I will wait for a fix of the OS > >before I care about writing a clean driver with ISR for > >ethernet. After the OS has been fixed: Wether the ISR will > >actually fill any RAM buffers or just wakes up a usermode > >job that reads from the hardware buffers on the network card > >and translates them directly into the TCP/IP stack's > >internal buffering scheme, remains to be seen. I tend to > >avoid double data copying. > > I brought this matter up with Marcel. Here is his suggestion: > > # He can request a re-schedule simply by setting the sys_rshd system > # variable to $FF. This will then be checked every time an SMSQ trap is > # invoked, which should normally happen very often. I think this should > # be good enough for his problem. this may help, but usually only in situations where it isn't needed anyway. A similar effect could be achieved on all QDOS variants by setting sv.pollm, although this has slide sideeffects. I looked at js rom and it appears really trivial to fix properly so why some workaround that doesn't help? Richard
Re: [ql-developers] Job re-scheduling
On Fri, Jan 03, 2003 at 09:12:52PM +0100, Peter Graf wrote: > > I still have problems to believe that QDOS/SMS is really that limited. > Every simple job can cause re-scheduling *immediately*, not only in a 20 > msec raster! There may be a way how an interrupt-driven device driver can > do that also. patch the OS or do your own scheduling in the ISR. Own scheduling in the ISR assumes known stack layout so it would likely require adaptation for a few QDOS variants. Patching JS and similar seems trivial. Richard
Re: [ql-developers] Job re-scheduling
On Wed, Jan 01, 2003 at 11:15:27PM +0100, Peter Graf wrote: > > Hi, > > a happy new year 2003! > > An issue regarding re-scheduling of jobs under QDOS/SMS: > > As far as I remember, the job scheduler is triggered only if: > (A) It is called directly from the frame interrupt about every 20 milisec. > or > (B) After certain non-atomic traps that can be called from user mode. > > Now imagine we have a high-priority job which is blocked waiting for input, > a low-priority job which the scheduler has switched into execution just a > milisec. ago, > and we have just received input data by an external interrupt routine. > > Has the external interrupt routine a chance to cause a re-scheduling of jobs, > before one of the events (A) or (B) takes place? in jsrom, the answer is no. Fixing the OS should be trivial. > If not, it would mean that the high-priority job needs to wait up to 20 > milisec. before it can actually use the asynchronously received data. Not > very nice for networking applications, where an average response time of 10 > milisec. is quite a lot these days. true. Richard
Re: [ql-developers] Q40 Linux 2: Phoebus : 1 (Score tied at half-time but with a goal on the first second of the second half Linux is ahead again... :-)
On Sat, Dec 21, 2002 at 12:41:37AM -0500, Phoebus Dokos wrote: > First the modprob fails on lo (to be expected as I was playing around with my >ethernet > card... fixed later by changing /etc/modules.conf -Btw: why are there two of them >there? iirc because reinstalling/upgrading modutils will overwrite /etc/modules.conf, this way it will never get completely lost. Only modules.conf is used by the system, make it a soft link to modules*q40. Btw the ethernet card should work immediately when you boot from CD, the q40 has 172.16.0.2 assigned. NFS client was tested in this config, bash tcp redirection should also work. > /etc/modules.conf and etc/modules.conf.q40 -changed them both to be on the safe > side), NFS fails (expected).., also 127.0.0.0 is not accepted as a address, >something > else is already using it... *.*.*.0 is network address, what are you doing? I know some people like to use addresses like that to confuse routers :). NFS client and server should work out of the box, for client enable 'portmap', for server also 'nfs' and nfs locking services. > Anyway come to the login prompt, login as root and... > > startx nothing (invalid command or something similar)... > > go to usr/XF86R11/bin ls... it's there... type it from there just in case the >environment > is not set properly... > nothing (invalid command again)... > > lynx fails too, with invalid library (don't remember exactly which but I can get the >correct > message) > . > lynx still fails and so does X and I am clueless... > > so the next logical step is cry for > > HEELL :-) did you look into /var/install? it looks very much like there were some read problems with the CD. > BTW: I left it a good one hour before i restarted after the first boot to give ample >time > for anacron to go about its business and the second boot was a lot faster... > > After I manage to get it working I need to test my ethernet (it's a 100 Mbit one so >I am > not exactly sure if it will work but if it does, i will order enough for the benefit >of > Q40/Q60 owners) and then start to clear the kernel from all the stuff i don't >need... If I > can get it to boot in under a minute I will be the happiest guy in the world :-) If you want quick boot disable all services you don't want. Kernel won't make much difference except for the pure time it needs to get loaded. There isn't much that can be done except rewriting the initscripts which are getting slower and slower with every version. > Also when I finish everything, the hard disk will come out of the Q40 and will >immediately > get the DriveImage 8.0 treatement (can deal with little endian AND big endian >formats...) .. and certainly not with the Q40 format if that matters anything. Do backup over ethernet or whatever. Richard
Re: [ql-developers] Q40 Linux: 1 - Phoebus: 0
On Fri, Dec 20, 2002 at 03:40:06AM -0500, Phoebus Dokos wrote: > > Hi all, > I am still having trouble getting Shoestring Linux to boot... > > Apparently x-install does not write inittab (Message is inittab file not found) and >stops > asking me to enter a runlevel.. Please boot with the installation CD again and look at the hda4 partition - in var/log/install there should be some hints what went wrong. Afaics there are 2 possibilites what could have gone wrong - CD ROM media error that caused some packages to be not installed correctly - or the myterious RPM installation error I am trying to hunt down. Possibly in some cases rpm simply exits without installing anything Quick workaournd would be to copy the contents of /cdrom/etc to the freshly installed root-partition, fix fstabs by hand, reboot into the new system and do something crude like. rpm -ihv --nodeps /cdrom/RedHat/RPMS/* Btw the environment on the installation CD is pretty complete system, there are tools like strace etc. > Additionally when I downloaded the files from sourceforge they ended up being 713 > Megs (I had to overburn the disk to fit it)... The MD5sums checked out and the >joining > was performed under WinXP in cmd in the following manner: > > copy /b cdxxa + cdxxb > cdtemp /b > then again copy /b cdtemp + cdxxc cdtemp1 /b (I used two temp files... theoretically >you > can do it in one go but the binary copy sometimes acts very weird under Windows NT > cmd. > > Anybody else got that file size and if not am I doing something VERY wrong there? cd image should be 688488448 bytes long, your NT is doing something strange. Richard
