Re: [ql-developers] In search of a 68060RC 60MHz with 0E41J mask
On Mon, 23 Aug 2004 23:45:18 +0200, Peter Graf wrote: > On 23 Aug 2004 at 15:22, 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... > > Probably all full-blown 66 MHz Q60 will have that mask revision. There is > nothing wrong about that. Especially as you have the "A" labelled > 68060RC60, which should be the best full-blown 68060 silicon ever for > overclocking. I don't know were you got that info (or impression) from, but the XC68060 is said by Amiga folks to be _less_ overclockable than the MC68060. Example : http://www.amiga-hardware.com/mc68060.html Citation: "The MC versions tends to be much more tolerant of heat and is more tolerant of being overclocked." I also browsed many Amiga sites today, and all the folks there use 50MHz MC68060s to overclock them at 66MHz without a single problem... > I toiled hard to locate them, and you could be a proud owner > instead of lamenting. I didn't accuse -you- and I didn't lament either. I said I was (and still am) upset. I'm upset, because when my board was built, full blown and -bugless- MC68060 existed and I end up with a buggy processor that I will have to replace. I'm upset because Motorola continued to sell buggy processors from their stock. I'm upset because I was stupid enough to believe that I would not have to worry about such bugs. I'm uspet because I didn't check in the available docs before ordering the card and as a result could not check with you what processor was to be used. > (The only full-blown chips leaving Motorola fabs at the time I built > your board were 50 MHz, and I'm quite sure that was not what you wanted.) http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC68060&nodeId=018rH3YTLC4622#orderables 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... > The 1G65V mask revision is normal mainstream production, The 1G65V mask _was_ normal mainstream production... It has been replaced in 1999 with the 0E41J, at which point the processor was renamed from XC68060 into MC68060: XC is used by Motorola for "Pilot production device" while MC is used for "Fully qualified parts", clearly indicating that prior to 0E41J maskset, the 68060 was still considered "experimental" by Motorola. References: Product identification: http://www.cpu-world.com/info/id/Motorola-identification.html 0E41J product change notice: http://www.freescale.com/files/shared/doc/pcn/945048375992collateral.html > the 50 MHz speed > grade is used in many thousands of Amiga and VME machines. The errata are > business as usual, no need to spread public FUD here. I don't know what 'FUD' means, but I'm simply searching for a bug-less 68060. I'm not trying to spread anything neither to badmouth you. My message was simply here to both warn people that they could be in the same situation as mine and to ask for anyone with an available replacement processor. At least, my warning will have the positive effect to get the future versions of SMSQ/E fixed for the I14/I15 errata... > > 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. 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 !!!... > > If you're already upset about 21 bugs, I wonder how you'd deal with modern > chips that have far more bugs. Like a PowerPC derivative to which I've been > porting eCos recently :-( 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... On the other hand, the MC68060, which is the "fully qualified" device, is bugless, and the buggy XC68060 was clearly just a pre-release... > > 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). > > Any proof or just guessing? Reminds me of another "hardware bug&q
[ql-developers] In search of a 68060RC 60MHz with 0E41J mask
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. 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). 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)... Is anyone, by any luck, selling one ? Thierry Godefroy.
[ql-developers] Linux kernel v2.4.27 for Q40/Q60/Q60LC available.
Yep, they are available from my website: http://q60linux.dyns.net/ Also available is nedit v5.5rc1 and Xdialog v2.1.2. Thierry Godefroy.
Re: [ql-developers] Problem compiling Linux v2.4.27 on the Q60
On Thu, 19 Aug 2004 14:27:07 +0200, [EMAIL PROTECTED] wrote: > Thierry Godefroy wrote: > > > If the shebang compiles properly, new pre-compiled Q60-Linux kernels should > > be available "soon" (the poor 68060/66MHz is so slow when compared to a > > 2GHz Athlon XP...) from my website. > > If you're interested in faster 68k machines with Linux, you might consider > to port the kernel to a MCF5475 (266 MHz, MMU, FPU). If you hurry a bit, > you can still be the first one who provides a decent Linux for that chip. That chip would still be 10 times slower than modern processors... Motorola screwed up the 68k while there could pefectly be 2GHz 68060s nowadays... > BTW I could provide drivers for some of the peripherals (Ethernet, Serial, > etc.) that are on the MCF5475. > > Thanks a lot for the kernels, I shall try them after my holiday in > September. They should be ready by then... :-P In fact I'm running v2.4.27 on the Q60 right now and the kernel for the Q40 is being compiled (it will take the night...). Then I'll have to do the Q60LC one, but I'll be absent from my home tomorrow, so it will be for this week-end... Thierry Godefroy.
Re: [ql-developers] Problem compiling Linux v2.4.27 on the Q60
On Thu, 19 Aug 2004 16:33:13 +0200, Richard Zidlicky wrote:
> On Thu, Aug 19, 2004 at 12:46:48PM +0200, Thierry Godefroy wrote:
>
> .../...
>
> > 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.
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 !... This should not make any difference for the above problem
as the 68040 also got a FPU, but it shows that "as" recieves the wrong option
from gcc 3.1...
Thierry Godefroy.
Re: [ql-developers] Problem compiling Linux v2.4.27 on the Q60
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
bfextu %d2{#16:#8},%d0
moveq.l #5,%d1
cmp.l %d0,%d1
jbcc .L117
.L45:
bftst m68k_fputype+3{#4:#4}
jbeq .L47
clr.l -4(%a6)
#APP
frestore -4(%a6)
#NO_APP
---
And in setup.c, one can find:
---
if (CPU_IS_060) {
u32 pcr;
asm (".chip 68060; movec %%pcr,%0; .chip 68k"
: "=d" (pcr));
if (((pcr >> 8) & 0xff) <= 5) {
printk("Enabling workaround for errata I14\n");
asm (".chip 68060; movec %0,%%pcr; .chip 68k"
: : "d" (pcr | 0x20));
}
}
/* FIXME: m68k_fputype is passed in by Penguin booter, which can
* be confused by software FPU emulation. BEWARE.
* We should really do our own FPU check at startup.
* [what do we do with buggy 68LC040s? if we have problems
* with them, we should add a test to check_bugs() below] */
#ifndef CONFIG_M68KFPU_EMU_ONLY
/* clear the fpu if we have one */
if (m68k_fputype & (FPU_68881|FPU_68882|FPU_68040|FPU_68060)) {
volatile int zero = 0;
asm __volatile__ ("frestore %0" : : "m" (zero));
}
#endif
So, there's obviously a .chip directive missing in:
asm __volatile__ ("frestore %0" : : "m" (zero));
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...
If the shebang compiles properly, new pre-compiled Q60-Linux kernels should
be available "soon" (the poor 68060/66MHz is so slow when compared to a
2GHz Athlon XP...) from my website.
Thierry Godefroy.
[ql-developers] Problem compiling Linux v2.4.27 on the Q60
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...
The version for 'as' is 2.11.90.0.25, gcc is v3.1.
The v2.4.23 of the Linux kernel compiles just fine in this respect...
Any idea ?
Thierry Godefroy.
Fw: Re: [ql-developers] 2GHz 68060
Erf... I meant 'come on', of course... --- Begin forwarded message: Date: Wed, 17 Dec 2003 10:56:37 +0100 From: Thierry Godefroy <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [ql-developers] 2GHz 68060 On Wed, 17 Dec 2003 08:03:21 +0100, Peter Graf wrote: > You might run 8 in parallel (not that I'd design the board :) Aww common !... ;-) Thierry.
[ql-developers] HD max size (was: Re: Linux Q40 Update)
On Mon, 15 Dec 2003 23:37:44 +0100, Richard Zidlicky wrote: > !!! WARNING !!! Kernel 2.4.18 (probably anything <2.4.21) > will eat filesystems on disks>137GB. Read in Documentation/ide.txt of the Linux kernel sources: == How To Use *Big* ATA/IDE drives with Linux -- The ATA Interface spec for IDE disk drives allows a total of 28 bits (8 bits for sector, 16 bits for cylinder, and 4 bits for head) for addressing individual disk sectors of 512 bytes each (in "Linear Block Address" (LBA) mode, there is still only a total of 28 bits available in the hardware). This "limits" the capacity of an IDE drive to no more than 128GB (Giga-bytes). 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. == 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... Thierry.
Re: [ql-developers] 2GHz 68060
On Wed, 17 Dec 2003 08:03:21 +0100, Peter Graf wrote: > You might run 8 in parallel (not that I'd design the board :) Aww common !... ;-) Thierry.
Re: [ql-developers] Linux Q40 Update
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... > 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. Not a big deal... Even on PCs, many 'old' (read 'one or to years old' !) BIOSes don't even accept hard drives over 60Gb... at least there is no stupid BIOS to impose such limits on the Q60. > 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 :) Cool ! v2.1 is really limitating and some software can't be ported to the Q40/Q60 because of that (e.g. IceWM v1.2.x). > 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 ? > - patches to improve 68060 performance available (longlong >instructions are most affected) Everything that can squeeze the latest drop of power out of the 68060 is a Good Thing(tm) :-) BTW, who could we bribe, at Motorola, so that they relaunch the 68060 production with modern technology ?... I'm still dreaming about a 2GHz 68060... I bet it would not be ridiculous at all when compared to Intel/AMD's over-complicated and bloated processors... > - 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 So a gcc v3.2 or 3.3 for the Q60 soon ? :-) > 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. Check the Mandrake site: they updated coreutils recently (I don't remember exactly why though). > 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 ? Thierry.
Re: [ql-developers] News RPMs for Q60-Linux
On Mon, 15 Dec 2003 00:56:30 +0100, Richard Zidlicky wrote: > On Sun, Dec 14, 2003 at 11:40:14AM +0100, Thierry Godefroy wrote: > > .../... > > - Linux kernel v2.4.23 (with cryptoloop and supermount patches). > > wrt supermount, did you look at http://submount.sourceforge.net/? Interesting, but it is still in alpha state, while supermount is well tested and in MAndrake production kernels for years (so it's unlikely a major bug was missed)... Otherwise, from the user point of view, submount and supermount seem pretty much equivalent. I did bookmark the page for submount though. Time will tell if it's worth replacing supermount with it. Thierry.
[ql-developers] News RPMs for Q60-Linux
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). - losetup/mount v2.11z: crypto-API aware, compatible with the old International kernel crypto patch. Should also work with loop-AES (untested). - dillo v0.8.0-pre: CVS pre-release (expect many core dumps !) with patch for frames support ! In the pipeline (i.e. being compiled right now): - gnupg v1.2.3 (fixes a critical security hole in previous gnupg versions). - nedit v5.4RC2. Enjoy ! Thierry Godefroy.
Re: [ql-developers] Massive amount of job state transitions and re-scheduling
On Sun, 07 Sep 2003 21:53:34 +0200, Peter Graf wrote: > Thierry wrote: > > >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. >From the computer sending packets to a Qx0, the latency would just be seen as a longer route... When you ping a computer on Internet, you have to wait a variable amount of time for the reply, depending on how many routers must be crossed, on how long are the wires (for trans-oceanic links, or worst for satellite links, it's far than neglectable), and how fast and/or busy is the receiver... If the topographic design of the network between a PC and a Q60 should lead to, say, a 200ms delay in the reply, then the TCP/IP implementation on the Q60 would simply add a 20ms latency to this number, but in the end, the sender should still receive its ACKs between 200 and 220ms after the packets are sent... Of course, this supposes that the acknowledgement is -actually- done every 20ms in the Q60, which is -NOT- the case if it's done at the job level (jobs are elected or not, depending on their cumulated priority and are therefore -NOT- running each 20ms unless they are alone in memory)... The code for reassembling the fragmented packets and acknowledging them must be implemented either as a frame interrupt, or (if frame interrupts are still too slow for your taste), by using a polled routine triggered by the Q60 fast interrupt (the one used by the sound system). The struture for the whole TCP/IP stack would then be: 1.- IP packets fetching from the I/F and buffering: - External interrupt handler (best), or fast interrupt polling loop. 2.- IP packets reassembling and acknowledging: - polled task: fast interrupt handler (best) or frame interrupt. 3.- TCP/IP high level protocols: - High priority (127) job. How does this sound ? Thierry.
Re: [ql-developers] Massive amount of job state transitions and re-scheduling
On Sat, 06 Sep 2003 00:24:18 +0200, Peter Graf wrote: > > Thierry wrote: > > .../... > > >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... > > At first sight it looks like that of course. QDOS/SMS reality is different > though. > > >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...). > > Wrong. > > 1. TCP is not a linear flow of data into one direction, even if the purpose > is file transfer. 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... > QDOS (and likely SMSQ/E, too) is so primitive that an > interrupt service routine can _not_ trigger immediate rescheduling of jobs > after it has completed. The time until the next rescheduling can be 20 ms > (worst case) so the user job has to wait that time until it can process the > data. The effect is that the other TCP endpoint in the network has to wait > 20 ms + processing + transfer time until it can react to the response > packet. Given MTU=1460=1.5KB your interrupt driven approach can not > guarantee more than a throughput of 1.5 KB / 20 ms = 75 KB/s with TCP, even > if the other endpoint needs zero time to process it's packets. (75 KB/s is > not quite what I want.) Wrong... With my method, you simply get a 20ms penalty (at worst) on the acknowledgment of all the packets that were bufered... I.e. you'll have a (worst case) 20ms penalty when pinging a Q60 on a network, compared to another computer... > Unlike an ISR, a job _can_ trigger immediate rescheduling! You don't need > to always poll the NIC, a clever approach can lead to full TCP throughput > during network activity, but zero polling waste (except for a a few tens of > instructions per 50 Hz) when the network is inactive. You don't need to poll the hardware as long as you can use an interrupt to signal the arrival of each new packet. Is the Q60 able to trigger an extrenal interrupt on such conditions ? If yes, then the lowest layer of the TCP/IP stack (actually of the Ethernet driver) could be implemented as the external interrupt handler... > The details are > somewhat complex, but as long the OS isn't changed, I have no better choice. > > 2. You waste response (and processor) time by your second copying level. > Imagine running the TCP/IP stack on a SuperGoldCard. Copying or not copying > about 1 MB every second _does_ matter. Well, aren't we speaking about the Q60 (or Q40) here ? I mean, there's not even an Ethernet I/F on (S)GCs... > 3. The idea of collecting fragments into larger buffers is not feasible, > unless you implement the TCP/IP stack itself within ISRs. (There are good > reasons not to do that!) This is wrong... The low level part is only responsible for moving the data from the hardware into an area of the memory wher it can wait until it's processed... I see no problem at all... Thierry.
Re: [ql-developers] Massive amount of job state transitions and re-scheduling
On Thu, 04 Sep 2003 20:23:08 +0200, Peter Graf wrote: > Hi, > > I made an experimental boost of QLwIP speed to the Ethernet maximum of 10 > Mbit/sec, which results in a massive amount of calls to MT.SUSJB, MT.RELJB > and MT.PRIOR, typically several thousands per second. > > After days of of debugging attempts, I still have strange effects that lead > me to a slight concern about the scheduler. The problem is hard to > reproduce and even harder to debug lack of appropriate tools. It seems like > under rare timing conditions a job is not released after a call to > MT.RELJB. The problem does no longer occur when I reduce the amount of the > three mentioned OS calls to several hundreds per second. > > It can still be a side effect of a bug in my code, nevertheless I'd like to > know if such a massive use of job state transition and rescheduling has > ever been tested before. Any ideas? > > 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... It might work under SMSQ/E (bigger stack, much better and faster scheduler), but this is definitely not recommended under QDOS... 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...). Thierry.
Re: [ql-developers] ide-scsi option in Linux 2.4.21
On Sun, 31 Aug 2003 18:57:54 +0200, Richard Zidlicky wrote: > 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. The HOWTOs say that if -both- the CD-ROM ATAPI native support and the ide-scsi emulation support are compiled into the kernel itself, then the first (native support) takes precedences automatically. See, for example: http://www.kernel-panic.org/index.pl/ide-scsi_howto and: http://user.cs.tu-berlin.de/~gregorrg/compaq/cdr_howto.html 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, so I couldn't tell if it ever worked in any kernel version when both are compiled into the kernel itself. Thierry.
[ql-developers] ide-scsi option in Linux 2.4.21 (was: Re: Linux v2.4.21 compilationerror with gcc v3.1)
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 ? Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Sun, 24 Aug 2003 00:24:26 +0200, Richard Zidlicky wrote:
> 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.
Well, v2.4 kernels are not concerned by these changes, and v2.6
doesn't even exist officially yet (it's still in 'test' stage)...
> So far it seems loop-AES can encrypt or decrypt all formats except
> perhaps some of those with broken IV keys.
It lacks quite a lot of algorithms from what I saw... loop-AES can
do AES, Serpent, Twofish and Blowfish, while the crypto-API knows
about: 3DES, AES, Blowfish, CAST5, IDEA, Mars, RC5, RC6, Serpent and
Twofish for the ciphers, plus: MD5, RIPEMD160, SHA1, SHA256, SHA384,
SHA512 for the digests. And I don't even cite the "deprecated" (unsafe)
ciphers and digests...
> > > 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?
It works just fine in that case (it's how I tested it before rebooting
the first time)... As I told you, this has nothing to do with supermount
itself, as the same behaviour appears on supermount-less kernels...
> Mine simply complains no such fs and that's it but I have newer
> version of the script.
That might explain things... Also, there are quite a few "quirks" in
ShoeString installation, one of them being that you end up with two
different directories holding the init.d scripts (with either different
scripts or two versions of the same...): /etc/init.d (which should be
a symlink instead), and /etc/rc.d/init.d. I moved all the scripts in
/etc/rc.d/init.d and made /etc/init.d a symlink, so I may have ended
up with a deprecated script... But rc.sysinit is in /etc/rc.d and
should not be affected.
For info (it may be of some use to all the users of ShoeString),
there's also a missing symling to /usr/bin/cpp in /lib (ln -s
/usr/bin/cpp /lib/cpp) which prevents .Xdefault of being parsed
at 'startx' time. There are also missing links to the kernel
headers directories in /usr/include ('linux' and 'asm'), preventing
to compile any software (but those symlinks are automatically setup
by my kernel-headers package).
Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Sat, 23 Aug 2003 11:06:08 +0200, Richard Zidlicky wrote: > 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 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). 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 crypto API also brings more cyphers as well as all the digest algorithms... > I will send you the sources of patched util-linux, can be a real > pain to sort out these patches. I re-compiled util-linux (the mount and losetup parts) for use with the crypto API, already... ;-) > > > 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. 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 hangs up the booting process when the local filesystems are mounted by rc.sysinit... This also happens if 'noauto' is added to the options (thus preventing the supermount device to be mounted at startup), or when a kernel without supermount support is started (I tried with the original v2.4.18rz kernel and get the same crash after the "no such filesystem" report). It's obviously a problem with the script and not with supermount, which works just fine. I start it in rc.local as a work around, by adding these lines in it: # 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 By the time you will read this message, the new v2.4.21 kernels and the mount/losetup updates will be available on my website. ;-) Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Fri, 22 Aug 2003 13:50:48 +0200, Richard Zidlicky wrote: > On Fri, Aug 22, 2003 at 02:14:54AM +0200, Thierry Godefroy wrote: > > > 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 No, I didn't see it... Interesting... But you didn't quote the conclusion: <> Well, Serpent is still safer than AES... Plus, all these attacks are based on known clear text attack, which leads to this comment in the article: <> 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). > > 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. 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... > > > 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? No, the device is permanently mounted and the driver reports an absent medium when accessed without a proper medium in the drive... > Could do that with autofs as well but don't like it because > it apparently looses cached buffers on CD roms. Never experimented such problems with SuperMount. > > 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 ??? 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... > gcc303 might work and is reasonably tested with 2.4 kernels. Thanks to your indications, I managed to patch the v2.4 kernel sources so to work around the gcc bug... I'll release the kernel packages as soon as possible. ;-) Note that the bug is trigered by all four ide-cd.c, ide-floppy.c, ide-tape.c and ide-scsi.c... 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... > > There are no SRPMS in it though... Or do I look in the wrong place ? > > they are still on my HD and quite uninteresting because I have > newer ones that ought to be uploaded. > > I think I will try to rebuild glibc/binutils/rpm from RH 9 or rwhide > with gcc-3.3.1 and see what happens, if that works I would try to base > a new distribution on top of this. That would be cool :-) Also, try to think "Manndrake": they got really cool packages and good patches to fix various problems encountered in many pieces of software. Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Thu, 21 Aug 2003 09:58:01 +0200, Richard Zidlicky wrote: > 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. 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). 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... 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...). > > > 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. 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... There are times were you just can't find a proper (set of) patch(es) applying cleanly to a given kernel... Well, I could make one out of Mandrake's patches for Linux-vanilla v2.4.21 and I use it since v2.4.21 is out without a single problem. I'll put the patch on my q60linux website. ;-) > How do you configure it? 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 More option can be passed to the underlying driver. A doc short is supplied in the patch and appears in the patched Linux sources tree as: Documentation/filesystems/supermount.txt > > 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. Mandrake doesn't develope at all for the m68k architecture, alas... > 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. I patched the sources and I'm trying to compile them as I write this message... Do you know if the same problem would arise with older gcc version (I was thinking to compile it with gcc-2.95.3...) ? > > 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. There are no SRPMS in it though... Or do I look in the wrong place ? Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Mini Qx0 Linux distro
On Thu, 21 Aug 2003 22:31:45 +0100, Tony Firshman wrote: > Debian is worth getting _just_ for the apt_get etc. > > There were many packages I simply did not install under Redhat 'cos the > dependencies were just too complicated. Dependencies exist in all the Linux distributions and they are a nightmare to solve in all of them. Mandrake tried to solve them by splitting each software into numerous packages (one for the libraries, another for the binaries, another for the headers and devel tools, etc) and making the major number of the version a part of the packages basename. That way you can easily install newer versions of the libraries (keeping the old libs but removing all the old binaries, headers and the like in favour of the newer version ones) without breaking the dependencies of the oldest software installed on your system and without the need for a specific compatibilty package (like when the switch was made from libc5 to glibc: you had to install a libc5-compat package for the old apps to keep working on you glibc-upgraded system). Example: You got 'whatever v1.0' and you want to intall 'whatever v2.0' Under Redhat or debian, you typically got: wathever-1.0.arch.rpm & wathever-devel-1.0.arch.rpm or wathever-1.0.arch.deb & wathever-devel-1.0.arch.deb Under Mandrake you got: wathever-1.0.arch.rpm wathever-devel-1.0.arch.rpm libwhatever1-1.0.arch.rpm whatever-doc-1.0.arch.rpm Now, you want to upgrade to v2.0 but alas 'somethingelse v0.5' depends on the libraries in whatever-1.0... Under Redhat you'll either loose the dependency for 'somethingelse v0.5'if you upgrade (-U) the 'whatever' package, or you'll get conflicts on the packages files if you try to install (-i) instead the new whatever (does trying to keep the old files of the old package). With some luck, Redhat will provide a compatibility package (e.g.: libwhatever-compat), else you're stuck and must solve the conflicts manually... With Mandrake, you just upgrade everything and will get in the end: wathever-2.0.arch.rpm wathever-devel-2.0.arch.rpm libwhatever1-1.0.arch.rpm libwhatever2-2.0.arch.rpm whatever-doc-2.0.arch.rpm The dynamic libraries in libwhatever1 and libwhatever2 having different names (libwhatever.so.1 and libwhatever.so.2), you have no conflict at all and 'somethingelse v0.5' will keep working happily after the upgrade... I'm not sure how Debian works out those dependencies, but I find Mandrake's approach rather elegant. > apt_get is quite brilliant at sorting everything out. There are equivalent tools to app-get for RPMs now (urpmi, grpmi, etc)... Also, did you ever try to -uninstall- a .deb package on a Debian distribution (properly, i.e. getting rid of all the files that were installed by app-get) ? Well... good luck ! Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Mini Qx0 Linux distro
On Thu, 21 Aug 2003 14:38:48 +0200, Peter Graf wrote: > Hi Thierry, > > nice to see that you are active again! Only half-active, alas... Not yet enough free time to do serious development (i.e. SMSQ/E one)... > I'd like to ask if you are still > absolutely opposed to the idea of Debian based Qx0 Linux? I'm absolutely opposed to loose my (already very sparse) time learning a new system: I'm now quite used to Mandrake/Redhat and can build RPMs pretty much "on the fly" while working at something else (yes, I can multitask too :-P). This doesn't mean you can't build a Debian distribution for the Q60, but this does mean that you should not expect anything coming from me for this distribution. Sorry. Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Wed, 20 Aug 2003 10:55:50 +0200, Richard Zidlicky wrote: > 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. I'm using the full crypto-API (with all the ciphers; AES being a rather weaker one than Serpent, for example...). > 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. :-) > > 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. 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 ? > 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 :( Eeeps... ;-( > I can mail you a CD with many new packages 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 ;-)... > 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) 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 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... :-( Thierry ([EMAIL PROTECTED]).
[ql-developers] Linux v2.4.21 compilation error with gcc v3.1
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). 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 ? :-) Here is the report I get everytime (with either the vanilla or the patched kernel sources): ide-cd.c: In function "ide_cdrom_dump_status" ide-cd.c:619: compiler internal error in verify_local_live_at_start, at flow.c:609 .../... Thierry Godefroy ([EMAIL PROTECTED]). PS: more cool stuff is available from my q60linux site, enjoy ! ( http://q60linux.dyns.net/ or http://thgodef.nerim.net/q60linux/ )
[ql-developers] New RPMs for ShoeString v1.0a (Linux Q40/Q60)
Hi all ! I started again to compile some cool software for Linux-Qx0. More to come ! http://q60linux.dyns.net/ http://thgodef.nerim.net/q60linux/ (in the case the first doesn't work...) Thierry Godefroy ([EMAIL PROTECTED]).
[ql-developers] Ethernet card for Q60
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) and its parameters (I/O address, IRQ, Duplex/Simplex modes) can be set via this software too. The parameters are retained in a flash memory on the Ethernet card. 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). The problem is: Linux (Shoebox v1.0a) hangs when trying to bring up eth0 at boot time... The configuration of the card is: IRQ 10 I/O 300h Full duplex It is connected to a 10/100Mbps switch and the network parameters are properly set in Linux. Any idea of what happens and the way to fix this ? Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Ethernet card for Q60
On Mon, 11 Aug 2003 20:09:16 +0200, Peter Graf wrote: > .../... > > If someone buys a new ethernet card with the RTL8019AS for Qx0, other than > from D&D Systems, he should be prepared to deal with cutting the IRQ10+11 > lines on the Ethernet card near the ISA connector. The corresponding pins > on the ISA connector are D3 and D4. > > Soldering side of the ethernet card, ISA connector: > > B1B31 D1 D2 D3 D4..D18 > > No guarantees. Please don't cut something you don't really want to cut :-) > To be on the save side, there are tested new cards available from D&D Systems. > I can also provide one for you if you find it more convenient. > > For use with Qx0, it is strongly recommended to use jumpered mode, IRQ5 and > iobase 0x300. Tracks cut, IRQ set to 5, I/O base to 0x300: It works !!! :-) For info, my Ethernet card is a Fiber Line FL-1840 (made in China) and the RTL8019AS (buggy) chip got 08019S1 / 045F as its serial number. Many thanks !! Expect the Q60/Q40 Linux website back 'soon' with plenty of RPMs compiled for the Linux shoestring distribution. Thierry. PS: I happen to remember someone mentionning the port of lwIP or uIP for SMSQ/E. Does it work ? If yes, where to get it ?
