On Tue, 22 Jun 1999, [iso-8859-1] Tor-Åke Fransson wrote:
> - The serial performance is *really* bad. [...]
> So, what's the story on the serial driver? What is missing?  NetBSD seemed
> to do a much better job in this area, and 57600 was no problem. [...]
> differencies in interrupt handling causing buffer overrun in linux?

I've noticed this too under recent 2.2 kernels, although I haven't had
my connection dropped.  For what it's worth, just from watching the
modem lights, downloads are "bursty" with significant hangtime before
resuming transmission.  Doesn't seem to be the case in 2.0.36 (I need
to reconfirm this, but I recall serial performance being okay), so I'm
going to guess that it is related to the changes in interrupt handling.
(hmm, also need to try downloading to /dev/null to make sure disk i/o
isn't a factor)

> - Three button emulation does not work at all (in X, i haven't installed
> gpm). I've scanned the list archive (mac69k) for clues, but apart from the
> adb_buttons=0x7c,0x7d kernel option i haven't seen anything in that
> direction, so i guess noone else has this problem (My keyboard is an
> A E II, swedish keymap, showkey gives 55 and 54 for the left option and
> control key) ?

Does the adb_buttons option work for anyone else?  I've not had any
luck with it either.  xev reports 63 and 66 as the keycodes for my
option and control keys (same keyboard, US keymap), but no effect
from adb_buttons=63,66.  I tried every other key on the keyboard too,
just to be safe, still to no avail.  Haven't had a chance to pull
down a copy of the 2.2.6 code and pepper it with debugging yet.

Quadra 605 in my case.
-jp




------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

On Tue, 22 Jun 1999, [iso-8859-1] Tor-Åke Fransson wrote:

> ppp echo requests, which causes the connection to drop (i'm using a null
> modem to my pc, it showed out that a AAUI<->10BaseT transciever would cost
> me almost as much as the Quadra (screen included).

I got my 10baseT transciever for about $10 each.  Check eBay, etc.
   --s
                                                          @ @
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-oOO-(_)-OOo-=-=-=-=-=
  C. Scott Ananian: cananian@...  /  Declare the Truth boldly and
  Laboratory for Computer Science/Crypto /       without hindrance.
  Massachusetts Institute of Technology /META-PARRESIAS AKOLUTOS:Acts 28:31
  -.-. .-.. .. ..-. ..-. --- .-. -..  ... -.-. --- - -  .- -. .- -. .. .- -.
  PGP key available via finger and from http://www.pdos.lcs.mit.edu/~cananian

supercomputer fissionable blowfish Albanian Waihopai Flintlock [Hello to all my
fans in domestic surveillance]
Legion of Doom Sabana Seca class struggle cryptographic Milosevic




------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

Hi all.

I got my hands on a very dusty Quadra 700 a few weeks ago, and decided to
let it accompany my linux pc. First action after digging up a working
keyboard and mouse (From Cash Converters, it seems to be impossible to buy
the simplest piece of hardware for these macs in computer stores here) was
tossing out MacOS 8.something and installing 7.0.1 and NetBSD 1.4.

After about a week i decided linux was funnier (see below) so i threw
NetBSD out and installed Debian 2.1 base and tools necessary to compile a
kernel, and got the 2.2.6cvs source from June 15.

I have discovered the following, some on which i hope you guys can shed
some light:

- Compressed ext2 fs (from kernel patch archive, the patch for 2.2.5)
seems to work perfectly, which is good, since i only have a 230M disk, and
can't seem to get any other SCSI drives recognized by the controller (may
be a termination issue, not sure) Despite a compressed kernel tree, the
Quadra still compiles a kernel in little over two hours.

- XF68_FBDev from Debian 2.1 now works fine in 8bpp

- The serial performance is *really* bad. When doing a little bit heavier
disk i/o (even when not compressing) the Quadra fails to respond to
ppp echo requests, which causes the connection to drop (i'm using a null
modem to my pc, it showed out that a AAUI<->10BaseT transciever would cost
me almost as much as the Quadra (screen included).

- Three button emulation does not work at all (in X, i haven't installed
gpm). I've scanned the list archive (mac69k) for clues, but apart from the
adb_buttons=0x7c,0x7d kernel option i haven't seen anything in that
direction, so i guess noone else has this problem (My keyboard is an
A E II, swedish keymap, showkey gives 55 and 54 for the left option and
control key) ?

..

So, what's the story on the serial driver? What is missing?  NetBSD seemed
to do a much better job in this area, and 57600 was no problem. I have
looked at the code for the drivers briefly, and i can't see any vast
differences there (except that netbsd seems to do some kind of clock
source scan when setting up the speed). Is it that, or is there
differencies in interrupt handling causing buffer overrun in linux?

NetBSD doesn't do compressed fs (afaik) and it doesn't do >1bpp X on
the Quadra either (afaik) and i value those features higher than serial
performance, but still, it's nice to have (ISP hookup).

Also, zub biespiel, MacOS 7.0.1 doesn't want to switch resolution on my
monitor. Any tips on software that takes care of that?


Regards,
T-Å
----------------------------------------------------
      _______          _        _    _
     / /_   _|__  _ __| | _____| |  / / Tor-Åke Fransson
    / /  | |/ torkel@.../ /  Södertälje, Sweden
   / /   | | (_) | |  |   <  __/ |/ /
  /_/    |_|\___/|_|  |_|\_\___|_/_/    073-9802227 (Mobile)




------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

I should correct what I said earlier, the debug messages actually appear 2
at a time, every half second - exactly the same timing as the cursor
blinking.

If anyone has any idea why the cursor blink code would mess up the A/UX
bit, I'd really like to know, otherwise I'm going to call it quits on this
problem and leave it for someone else to figure out.

As a side note, I tried disabling the RTC read/write stuff, but that made
no difference, as I would expect.


I think I might relax a while and write some more of that documentation I
started earlier while I look about for a cheap 68k powerbook to play with...

Cheers - Tony :)


--
Tony Mantler         Renaissance Nerd Extraordinaire         eek@...
Winnipeg, Manitoba, Canada                       http://www.escape.ca/~eek





------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

bsullivan@... wrote:

> ...
>
> So I suspect it's a serial port config issue. I've checked the PPP scripts,
> and they specify a high port speed (tried 115.2 and 57.6) as well as

Try setting the port speed no higher than 38600.

> ...
> Also, any ideas about some strange ADB behavior I've been seeing? Every two
> or three startups all the lights on my keyboard light up and stay on.

Buggy IIsi-style adb. As I understand it, the great adb reoganization is going
to begin Real Soon Now. I've been waiting for that to see if the adb gets fixed
on my IIsi. After you lose adb, the machine is still running, btw. If you can
access it some way other than the console, you can still use it & shut it down
safely after losing adb. I use telnet for that; others have talked about using
a serial console. Check the mailing list archive
http://www.egroups.com/group/linux-mac68k/info.html and
http://www.egroups.com/group/linux-mac69k/info.html (for messages up through
May) for details.

I'm also interested to know which kernels you get to work; the only one I can
really use is the 2.0.36 distribution kernel. Anything newer dies with a SCSI
error.

Hope that helps,
Frank




------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

At 6:50 PM -0500 6/21/99, Allen Briggs wrote:
>> Just for the heck of it, I added some reset code into the a/ux int
>> debugging code I put in the via1 int handler, and had it spit out a debug
>> message for every reset up to a sane value (32) at which point it spits out
>> another debug message and lets the a/ux ints die peacefully.
>
>Hmmm...  Have you tried turning the DDR back to 0 for that bit after
>clearing it in the buffer?  I'm not finding that necessary in NetBSD,
>but we're not touching the data or direction registers at interrupt
>time.  We just set the latch and run.  I haven't looked to see how
>y'all are doing it.

I think I tried at one point setting the DDR to output, flipping the A/UX
bit,then switching the DDR it to input again, but I seem to recall that not
working, most likely because the VIA probably wouldn't be designed to drive
the line when it's trying to read it's value in input mode. If I get stuck,
I'll try it again to confirm.


>> I seem to be getting a feeling that resetting the timer countdown for the
>> next interrupt also resets PB[6|7] regardless of the settings on vACR
>
>If this is happening, it should be something in the code that you can
>disable.

Well, theoretically clearing bits 5 and 7 on the ACR should keep the timers
from messing with PB[6|7], atleast according to the documentation I've read.

Still, being that this technically isn't a real VIA, apple could have done
something weird and undocumented to the chip that some of the other code is
tickling indirectly. Either that, or vBufB/vDirB is being mangled in some
function that I haven't looked at.

On with the search I guess...


--
Tony Mantler         Renaissance Nerd Extraordinaire         eek@...
Winnipeg, Manitoba, Canada                       http://www.escape.ca/~eek





------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

> Just for the heck of it, I added some reset code into the a/ux int
> debugging code I put in the via1 int handler, and had it spit out a debug
> message for every reset up to a sane value (32) at which point it spits out
> another debug message and lets the a/ux ints die peacefully.

Hmmm...  Have you tried turning the DDR back to 0 for that bit after
clearing it in the buffer?  I'm not finding that necessary in NetBSD,
but we're not touching the data or direction registers at interrupt
time.  We just set the latch and run.  I haven't looked to see how
y'all are doing it.

> I seem to be getting a feeling that resetting the timer countdown for the
> next interrupt also resets PB[6|7] regardless of the settings on vACR

If this is happening, it should be something in the code that you can
disable.

-allen




------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

Just for the heck of it, I added some reset code into the a/ux int
debugging code I put in the via1 int handler, and had it spit out a debug
message for every reset up to a sane value (32) at which point it spits out
another debug message and lets the a/ux ints die peacefully.

The /proc/kmsg log is attached. /proc/interrupts showed a total of 700-800
via1 interrupts on IPL6, up quite a bit from before.

The debug messages seemed to come about once every second (atleast during
the ramdisk decompression, when I could actually watch it properly), which
implies the timer 2(?) interrupt at fault?

Anyways, where do I find the interesting bits of code relating to timer int
handling?

I seem to be getting a feeling that resetting the timer countdown for the
next interrupt also resets PB[6|7] regardless of the settings on vACR, in
which case the only way to fix the A/UX ints would be to modify the timer
int handler to reset the PB[6|7] bits when it resets the timer countdown, I
guess. I certainly hope this isn't the case.


Oh, and while I'm posting this log, I might as well nitpick at the
unessacary scsi error messages generated by my empty zip drive (sda). Does
this happen on other ports too or is it a peculiarity of the macs?

Also, can the fsck checktime be disabled on the ramdisk image? The message
might confuse new users.

the log:

[...]
<4>macfb: framebuffer at 0xf9000080, mapped to 0xd0000080, size 978k
<4>macfb: mode is 1152x870x8, linelength=1152
<4>macfb: scrolling: redraw
<4>fbcon_startup: No VBL detected, using timer based cursor.
<4>A/UX ints dying for the 1 time; reviving...
<4>A/UX ints dying for the 2 time; reviving...
<4>Console: switching to colour frame buffer device 144x54
<4>fb0: DAFB built-in frame buffer device
<7>Configuring keyboard:
<7>leds on ...
<7>configuring coding mode ...
<4>A/UX ints dying for the 3 time; reviving...
<4>A/UX ints dying for the 4 time; reviving...
<7>keyboard init done
<6>M68K Serial driver version 1.01
<4>Mac68K Z8530 serial driver version 1.01
<6>ttyS0 at 0x50f0c022: 8350 ESCC w/o DMA
<6>ttyS1 at 0x50f0c020: 8350 ESCC w/o DMA
<4>A/UX ints dying for the 5 time; reviving...
<4>A/UX ints dying for the 6 time; reviving...
<4>A/UX ints dying for the 7 time; reviving...
<6>Macintosh ADB mouse driver installed.
<4>RAM disk driver initialized:  16 RAM disks of 4096K size
<6>loop: registered device at major 7
<4>mac_esp: io base at 0x50f10000
<4>esp: using quick version
<4>esp: addr at 0x50f10000
<4>SCSI ID 7 Clk 16MHz CCF=4 TOut 138 NCR53C9x(esp236)
<4>
<4>mac_esp: 1 esp controllers found
<4>scsi0 : ESP236 (NCR53C9x)
<4>scsi : 1 host.
<4>A/UX ints dying for the 8 time; reviving...
<4>A/UX ints dying for the 9 time; reviving...
<4>A/UX ints dying for the 10 time; reviving...
<4>A/UX ints dying for the 11 time; reviving...
<4>A/UX ints dying for the 12 time; reviving...
<4>A/UX ints dying for the 13 time; reviving...
<4>  Vendor: PIONEER   Model: CD-ROM DR-766     Rev: 1.00
<4>  Type:   CD-ROM                             ANSI SCSI revision: 02
<4>Detected scsi CD-ROM sr0 at scsi0, channel 0, id 4, lun 0
<4>  Vendor: IOMEGA    Model: ZIP 100           Rev: J.02
<4>  Type:   Direct-Access     A/UX ints dying for the 14 time; reviving...
<4>A/UX ints dying for the 15 time; reviving...
<4>                 ANSI SCSI revision: 02
<4>Detected scsi removable disk sda at scsi0, channel 0, id 5, lun 0
<4>  Vendor: QUANTUM   Model: LIGHTNING 730S    Rev: 2417
<4>  Type:   Direct-Access                      ANSI SCSI revision: 02
<4>Detected scsi disk sdb at scsi0, channel 0, id 6, lun 0
<4>scsi : detected 1 SCSI cdrom 2 SCSI disks total.
<4>sr0: scsi3-mmc drive: 32x/32x cd/rw xa/form2 cdda tray
<6>Uniform CDROM driver Revision: 2.54
<4>A/UX ints dying for the 16 time; reviving...
<4>A/UX ints dying for the 17 time; reviving...
<4>sda : READ CAPACITY failed.
<4>sda : status = 0, message = 00, host = 0, driver = 28
<4>sda : extended sense code = 2
<4>sda : block size assumed to be 512 bytes, disk size 1GB.
<4>SCSI device sdb: hdwr sector= 512 bytes. Sectors= 1431518 [698 MB] [0.7 GB]
<6>PPP: version 2.3.3 (demand dialling)
<6>TCP compression code copyright 1989 Regents of the University of California
<6>PPP line discipline registered.
<4>A/UX ints dying for the 18 time; reviving...
<4>A/UX ints dying for the 19 time; reviving...
<4>Partition check:
<4> sda:scsidisk I/O error: dev 08:00, sector 0
<4>08:00: error reading partition table
<4> sdb: MAC sdb1 sdb2 sdb3 sdb4
<5>RAMDISK: Compressed image found at block 0
<4>A/UX ints dying for the 20 time; reviving...
<4>A/UX ints dying for the 21 time; reviving...
<4>A/UX ints dying for the 22 time; reviving...
<4>A/UX ints dying for the 23 time; reviving...
<4>A/UX ints dying for the 24 time; reviving...
<4>A/UX ints dying for the 25 time; reviving...
<4>A/UX ints dying for the 26 time; reviving...
<4>A/UX ints dying for the 27 time; reviving...
<4>A/UX ints dying for the 28 time; reviving...
<4>A/UX ints dying for the 29 time; reviving...
<4>A/UX ints dying for the 30 time; reviving...
<4>A/UX ints dying for the 31 time; reviving...
<4>The A/UX ints are dead, Jim.
<4>EXT2-fs warning: checktime reached, running e2fsck is recommended
<4>VFS: Mounted root (ext2 filesystem).


--
Tony Mantler         Renaissance Nerd Extraordinaire         eek@...
Winnipeg, Manitoba, Canada                       http://www.escape.ca/~eek





------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

Jason Harris wrote:
> I'm getting kernel panics booting with the recent CVS kernels.  The
> kernel panics after my root partition is fsck'ed.   The 6/9 kernel gives
> a bit more information than the 6/13 kernel
>
> the 6/9/99 kernel reports:
>
> Parallelizing fsck version 1.12 (9-Jul-98)
> /dev/sdb6:  clean, 6165/51200 files, 45797/204800 blocks
> p -> mh_alloc == ((char) 0xf7)
> Report this to bash-maintainers@...
> INIT:  PANIC:  segmentation violation!  giving up..

That would be either during the init script which contains the fsck, or
later.
Probably within that same script because the root file system wasn't
remounted
r/w yet.

How much RAM do you have, and might it be a FPU problem?

	 Michael



------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

On Mon, Jun 21, 1999 at 01:27:04PM -0400, Joshua M. Thompson wrote:
> problem. take my 630 for example. It has an unsupported PDS slot Ethernet
> card. If I boot with the ethernet cable plugged in, the first time the
> card sends an interrupt all Nubus interrupts wil be permanently locked out
> due to the nature of the Nubus interupt design. This means IDE stops

If I understand you correctly, then, clearing SLOTINT does not guarantee
that the NuBus interrupt will actually be cleared unless you clear every
card's internal interrupt flag - otherwise their interrupt lines will stay
high, and therefore, so will SLOTINT, and therefore, we will never get
another Nubus interrupt.  I think I'm starting to grok this.

The reason, then, that this problem affects us is that we don't do an
adequate job of turning off everyone's interrupts when we shut down MacOS to
boot Linux?

> working. I've confirmed the nature of this problem using the old
> /proc/mac_via interface; IDE interrupts _do_ happen occur in the slot
> interrupt register but the master SLOTIRQ never gets triggered.

Yes, this is exactly what happens when I enable VBL interrupts.  If I don't
poll the NuBus interrupt in the VIA1 handler, I get no VIA2 NuBus interrupts
whatsoever.

Now that I think of it, this makes perfect sense.  This would explain the
great lengths which NetBSD goes to in order to make sure video cards'
NuBus interrupts are properly shut up.

Therefore, in order to get my Q630 to work properly with VBL interrupts
enabled, I just have to figure out what NuBus interrupt the Valkyrie is
spitting out and how to clear it?

Hm.  I think I'm starting to understand this now.  Sorry to pester you with
my cluelessness :-)

--
dhd@... (wearing my Linux/m68k+Mac+Debian hat)
   Latest kernels/patches: http://maclinux.plcom.on.ca/pub/



------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

Hiya!

I'm getting kernel panics booting with the recent CVS kernels.  The
kernel panics after my root partition is fsck'ed.   The 6/9 kernel gives
a bit more information than the 6/13 kernel

the 6/9/99 kernel reports:

Parallelizing fsck version 1.12 (9-Jul-98)
/dev/sdb6:  clean, 6165/51200 files, 45797/204800 blocks
p -> mh_alloc == ((char) 0xf7)
Report this to bash-maintainers@...
INIT:  PANIC:  segmentation violation!  giving up..




the 6/13/99 kernel reports:

Parallelizing fsck version 1.12 (9-Jul-98)
INIT:  PANIC:  segmentation violation!  giving up..

I don't know if I need to update any other components to get the 2.2.6
kernel working - everything else is stock Debian Slink, except the
modules, which are from the 5/25/99 release.

I'm running a Quadra 610 with nothing in the PDS slot.

Finally, using the 6/13/99 kernel and booting into a ramdisk image, I
can't use the keyboard.  But I've seen this problem noted in the mailing
list archives and the consensus seems to be that it's a separate problem.

jason harris



------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

Just use what I am planning to use:

a performa 636CD, which has an o40 chip. Of course, going to the extream
and putting in a powerpc would move you to mklinux or such...

but you can get an 040 in the same way as they describe.

-andy


Michael Schmitz wrote:
>
> Andrew Diller wrote:
> >
> > If you have a color classic, please visit the page:
> >
> > http://homepages.tesco.net/~macaddict/PowerCC.html
> >
> > After doing this, you can run what you choose.
>
> I fail to see how you would run Linux/m68k on such an upgraded CC though.
>
>         Michael



------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

David Huggins-Daines wrote:
> Basically it's a massive, horrible kludge to catch the IDE interrupts that
> are somehow getting lost in the process of handling VIA2 stuff.  But like I
> said, I think we might be running into the "IDE driver does sti() where it
> shouldn't and therefore cocks up on level-triggered systems" problem that
> recently prompted a mini-flamewar on linux-m68k.

Note to the uninitiated: that was davem making a lot of noise about how
all the world should follow i386 interrupt handling rules. On the
particular hardware in question
(Q40) this isn't even possible in a clean way.

> > > I'm still somewhat at a loss as to why enabling VBL interrupts prevents
IDE
> > > and SONIC interrupts from triggering SLOTINT
> >
> > That is curious.  This is the VIA1 VBL interrupt?
>
> Well, it's whatever the Penguin booter disables, which is (I think) whatever
> MacOS calls the "slot 0" interrupt.

It seeems this is a VBL rerouted to Nubus (and since it doesn't get
cleared it prevents the proper edge detection of other slot interrupts)

	 Michael



------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

Andrew Diller wrote:
>
> If you have a color classic, please visit the page:
>
> http://homepages.tesco.net/~macaddict/PowerCC.html
>
> After doing this, you can run what you choose.

I fail to see how you would run Linux/m68k on such an upgraded CC though.

	 Michael



------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

On Mon, 21 Jun 1999, David Huggins-Daines wrote:

> When we had a single unified VIA handler, we would simply poll the slot
> interrupt on every VIA interrupt.  With two separate handlers, there's no
> point in doing this in the VIA2 handler, since we've already seen the slot
> interrupt.

No it definately fixes _a_ problem. Maybe not the only problem, but a
problem. take my 630 for example. It has an unsupported PDS slot Ethernet
card. If I boot with the ethernet cable plugged in, the first time the
card sends an interrupt all Nubus interrupts wil be permanently locked out
due to the nature of the Nubus interupt design. This means IDE stops
working. I've confirmed the nature of this problem using the old
/proc/mac_via interface; IDE interrupts _do_ happen occur in the slot
interrupt register but the master SLOTIRQ never gets triggered.

This is also the problem CSA had with multiple Ethernet cards in his IIci.
You can get a subtle race condition that causes you to lose a Nubus
interrupt, causing it to stick and thus stick all future Nubus interrupts.
It doesn't hang the _machine_ like you're seeing (that is a different
problem), it just hangs Nubus interrupts. At least in this case it'll get
unstuck eventually when the ethernet IRQ routine is finally called, unlike
my 630 where there is no routine to call since the card is unsupported.

> Basically it's a massive, horrible kludge to catch the IDE interrupts that
> are somehow getting lost in the process of handling VIA2 stuff.  But like I
> said, I think we might be running into the "IDE driver does sti() where it
> shouldn't and therefore cocks up on level-triggered systems" problem that
> recently prompted a mini-flamewar on linux-m68k.

This probably just amplifies the problem I mentioned above (i have been
following that discussion on linux-m68k with interest as well.)

--
funaho@...             | Voodoo is a very interesting religion for the
http://www.jurai.org/~funaho | whole family, even those members of it who are
                              | dead.
                              |  -- (Terry Pratchett & Neil Gaiman, Good Omens)





------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

I hope the level and nature of this request is suitable for this list, you
guys appear to be light years ahead of me on this stuff. So, pardon the
newbie question.

Recently installed the current Debian linux/m68k distribution (2.1) on a
IIsi. Most things seem to work, and configured PPP without any trouble, or
so I thought. Trouble is, the modem always connects at 9600. I feel pretty
confident I can rule out the modem and cable as the cause of these problems.
I use the same equipment and init string under the mac OS and consistently
get 28.8+ connections. Even so, I have tried several different stings with
no success. The modem is a USR voice 33.6, which appears to not have the
option of reporting serial port speed, a situation which has hampered my
diagnosis attempts. Other modems I've had in the past gave the choice of
reporting DTE or DCE speed, not this one.

So I suspect it's a serial port config issue. I've checked the PPP scripts,
and they specify a high port speed (tried 115.2 and 57.6) as well as
enabling RTS/CTS. I've also messed with setserial a little and tried both
the spd_hi and spd_vhi flags, with no success. I know the IIsi serial ports
are far from ideal, but I know I've never had any trouble with a 57.6 port
speed under the mac OS.

Any ideas?

Also, any ideas about some strange ADB behavior I've been seeing? Every two
or three startups all the lights on my keyboard light up and stay on.
There's a startup message right around the same time on screen saying
something like "lighting keyboard LEDs." Whenever this happens, the keyboard
is frozen from then on and I end up force rebooting the machine.

If there are resources where I should be going for questions like this,
please let me know. I'll do the legwork, I just ran out of resources.

Thanks,
Brian
----------------------------------------------
Brian Sullivan
Production Analyst
PC Connection/Mac Connection
Tel (603) 423-2429
Fax (603) 423-5770




------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

On Mon, Jun 21, 1999 at 11:54:53AM -0400, David Huggins-Daines wrote:
> On Mon, Jun 21, 1999 at 10:59:58AM -0400, Allen Briggs wrote:
> > Is this a safety scan?  Nubus interrupts are on VIA2, so VIA1 shouldn't
> > affect them (except that you're busier...).
>
> No, rather, it's a "this sucks, but we lose IDE interrupts unless we do it"
> thing :-)

Hm, I guess that is a safety scan.  Ignore me, I didn't sleep much last
night :-)

--
dhd@... (wearing my Linux/m68k+Mac+Debian hat)
   Latest kernels/patches: http://maclinux.plcom.on.ca/pub/



------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

On Mon, Jun 21, 1999 at 10:59:58AM -0400, Allen Briggs wrote:
> Is this a safety scan?  Nubus interrupts are on VIA2, so VIA1 shouldn't
> affect them (except that you're busier...).

No, rather, it's a "this sucks, but we lose IDE interrupts unless we do it"
thing :-)

When we had a single unified VIA handler, we would simply poll the slot
interrupt on every VIA interrupt.  With two separate handlers, there's no
point in doing this in the VIA2 handler, since we've already seen the slot
interrupt.

Basically it's a massive, horrible kludge to catch the IDE interrupts that
are somehow getting lost in the process of handling VIA2 stuff.  But like I
said, I think we might be running into the "IDE driver does sti() where it
shouldn't and therefore cocks up on level-triggered systems" problem that
recently prompted a mini-flamewar on linux-m68k.

Someone suggested that doing this also prevented their (non-IDE) Mac from
dying when using two Ethernet cards.  Unfortunately, it does no such thing
for me - using two Ethernet cards still locks up my Q630 solid in a
wonderfully non-deterministic fashion (i.e. maybe 5 minutes after booting,
or maybe an hour).  I mean *solid* - no SysRq, no NMI, no nothing.  It
resembles a SONIC DMA transfer gone awry, actually - the problem is that
it's rather hard to catch it in the act...

Luckily Asante left the debugging symbols in the driver for my comm-slot
SONIC card :-)

> > I'm still somewhat at a loss as to why enabling VBL interrupts prevents IDE
> > and SONIC interrupts from triggering SLOTINT
>
> That is curious.  This is the VIA1 VBL interrupt?

Well, it's whatever the Penguin booter disables, which is (I think) whatever
MacOS calls the "slot 0" interrupt.

When we do disable it, SONIC shows up on slot 9, and IDE shows up on the
"fictitious" slot F...  putting the IDE interrupt on the SLOTINT line
strikes me as one of the more evil things Apple's hardware people have
done...

--
You do{} stuff.  Then it's $done.  Then you die().



------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

If you have a color classic, please visit the page:

http://homepages.tesco.net/~macaddict/PowerCC.html


After doing this, you can run what you choose.


-andy



Michael Schmitz wrote:
>
> Cameron Robert C Romeril wrote:
> >
> > HI, I will keep it short- is there any chance that mkLinux can run on a
> > color classic with 8mb RAM and an 80 MB HD?
>
> Short answer: MkLinux: never. Linux/m68k: probably (if it's a 68030). 80
> MB disk are
> barely sufficient for the absolute mininum (i.e. useless) installation.
>
>         Michael



------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

> This is essentially the same problem as we've noticed with the onboard SONIC
> Ethernet.  It makes the computer slow because now that VBL interrupts are
> enabled, there are almost twice as many VIA1 interrupts, and we have to run
> through the NuBus slots on every one (which was even worse when we did the
> looping thing in the interrupt handler).

Is this a safety scan?  Nubus interrupts are on VIA2, so VIA1 shouldn't
affect them (except that you're busier...).

> I'm still somewhat at a loss as to why enabling VBL interrupts prevents IDE
> and SONIC interrupts from triggering SLOTINT

That is curious.  This is the VIA1 VBL interrupt?

-allen




------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

On Mon, Jun 21, 1999 at 03:55:33AM -0400, David Huggins-Daines wrote:
> -  /* We need to continuously poll the NuBus slot irq
> - 	   bits to avoid losing interrupts.  Level-triggered
> - 	   interrupts suck. */
> -
> -  if (!oss_present) {
> - 	 via_nubus_irq(IRQ_MAC_NUBUS, (void*) via2, regs);
> -  }
> + if (!oss_present) {
> +  /* This (still) seems to be necessary to get IDE
> + 	   working.  However, if you enable VBL interrupts,
> + 	   you're screwed... */
> +  via_irq_disable(IRQ_MAC_NUBUS);
> +  via_irq_clear(IRQ_MAC_NUBUS);
> +  mac_do_irq_list(IRQ_MAC_NUBUS, regs);
> +  via_irq_enable(IRQ_MAC_NUBUS);

I should add that I have an idea as to why not disabling VBL interrupts
causes us to lose so badly on the Q630.  Basically, if VBL interrupts are
enabled, IDE no longer seems to trigger the SLOTINT bit in vIFR, despite the
fact that it still shows up in the "Slot F" bit in vBufB.

This is essentially the same problem as we've noticed with the onboard SONIC
Ethernet.  It makes the computer slow because now that VBL interrupts are
enabled, there are almost twice as many VIA1 interrupts, and we have to run
through the NuBus slots on every one (which was even worse when we did the
looping thing in the interrupt handler).

I'm still somewhat at a loss as to why enabling VBL interrupts prevents IDE
and SONIC interrupts from triggering SLOTINT (in fact it looks like other
NuBus devices are not really working either...)

--
dhd@... (wearing my Linux/m68k+Mac+Debian hat)
   Latest kernels/patches: http://maclinux.plcom.on.ca/pub/



------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

On Sun, 20 Jun 1999, David Huggins-Daines wrote:

> On Sun, Jun 20, 1999 at 11:10:29AM -0400, Joshua M. Thompson wrote:
> > The 68K MACE driver is broken. Unfortunately nobody's been able to figure
> > out how to fix it yet. :(
>
> Anyone want to lend me an AV? :-)

I may be playing wiht mine again soon. Looks like one of the 16 meg SIMMs
in my IIfx is flakey because it's acting -real- weird all of a sudden
(wouldn't boot at all, now it boots but launching Linux makes the kernel
oops or otherwise die at odd random spots.) That leaves me with only 4
megs until i get around to replacing the SIMMs, which isn't really enough
to do any serious work.

--
funaho@...             | Voodoo is a very interesting religion for the
http://www.jurai.org/~funaho | whole family, even those members of it who are
                              | dead.
                              |  -- (Terry Pratchett & Neil Gaiman, Good Omens)





------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

Since neither of the existing archives for the mailing list have been
resubscribed to and/or updated to receive from the new list host, I've
set a new archive up...
	 http://www.egroups.com/group/linux-mac68k/info.html

Archives from when wave.lm.com was the host (July '98 through the
changeover in late April '99) are also available, albeit under an
odd choice of names.  Still working on getting those messages moved
into the above list.  Again, if anyone here set this up, please drop
me a line...
	 http://www.egroups.com/group/linux-mac69k/info.html
-jp




------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

On Sun, Jun 20, 1999 at 11:10:29AM -0400, Joshua M. Thompson wrote:
> The 68K MACE driver is broken. Unfortunately nobody's been able to figure
> out how to fix it yet. :(

Anyone want to lend me an AV? :-)

--
dhd@... (wearing my Linux/m68k+Mac+Debian hat)
   Latest kernels/patches: http://maclinux.plcom.on.ca/pub/



------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

Ryan Rafferty wrote:
> The Debian scripts try to issue the command:
>
> route add -net 192.168.1.0
>
> which fails under the 2.2.6 kernel with the message,
>
> SIOCADDRT: invalid argument
>
> or something similar. I'm thinking that the version of network tools that
> came with this version of Debian (HAMM) are too old to work with the
> 2.2-series kernels. Is this correct? If so, where can I grab an updated
> version of the tools for Linux/m68k?

Wait for Debian 2.2 (potato), install the sysvinit stuff for potato or
just comment out the route command. The net tools are OK, but with 2.1
kernels you don't need to explicitly set the route to the network the
interface is directly attached to. The kernel already does this with
setting the interface address and netmask.

(And I believe that's explained in Documentation/Changes.txt in the 2.2.6
CVS tree)

	 Michael



------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

Cameron Robert C Romeril wrote:
>
> HI, I will keep it short- is there any chance that mkLinux can run on a
> color classic with 8mb RAM and an 80 MB HD?

Short answer: MkLinux: never. Linux/m68k: probably (if it's a 68030). 80
MB disk are
barely sufficient for the absolute mininum (i.e. useless) installation.

	 Michael



------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

On Sun, 20 Jun 1999, Ryan Rafferty wrote:

> Only problem is, I can't get the networking to configure. eth0 shows up
> under ifconfig, and it's configured correctly: IP address 192.168.1.1,
> netmask 255.255.255.0, etc. But I notice that the "route" command doesn't
> work as Debian expects it to.

The 68K MACE driver is broken. Unfortunately nobody's been able to figure
out how to fix it yet. :(

--
funaho@...             | Voodoo is a very interesting religion for the
http://www.jurai.org/~funaho | whole family, even those members of it who are
                              | dead.
                              |  -- (Terry Pratchett & Neil Gaiman, Good Omens)





------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

I'm trying to get Linux on this Q660AV and I succeed except for
networking. I've installed the Debian distribution (HAMM) and I'm using
the 2.2.6 kernel with MACE ethernet support.

Other than the irritating all-blue text (didn't FB with color work back
with the 2.0.36 kernel on the 660AV?) the system installed well.

Only problem is, I can't get the networking to configure. eth0 shows up
under ifconfig, and it's configured correctly: IP address 192.168.1.1,
netmask 255.255.255.0, etc. But I notice that the "route" command doesn't
work as Debian expects it to.

The Debian scripts try to issue the command:

route add -net 192.168.1.0

which fails under the 2.2.6 kernel with the message,

SIOCADDRT: invalid argument

or something similar. I'm thinking that the version of network tools that
came with this version of Debian (HAMM) are too old to work with the
2.2-series kernels. Is this correct? If so, where can I grab an updated
version of the tools for Linux/m68k?

Thanks,
Ryan Rafferty





------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

HI, I will keep it short- is there any chance that mkLinux can run on a
color classic with 8mb RAM and an 80 MB HD?

Thanks in advance,
Cam

;-)




------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications

On Fri, Jun 18, 1999 at 11:42:11AM -0400, C. Scott Ananian wrote:
> 68030 CPU?  The FPU emulation *should* work, but I haven't tested recent
> kernels so it's *possible* something broke.  More likely is that the
> memory mapping is odd on the duo; the boot problems I had with my IIci
> involved trying the mmap executables into screen space.

No, there is nothing wrong with the memory mapping on the Duo.  My Duo works
just fine with the current CVS sources (aside from the lack of ADB, and the
tendency to freeze within 5 minutes of being netbooted, and the FIFO
overruns in the SONIC...).  I wouldn't have been able to test SONIC ethernet
and Jet framebuffer support otherwise :-)

I guess I'll put up a new binary kernel image soon. (though the frequency
with which I've been uploading these seems to have resulted in a fair amount
of confusion on the list and the newsgroup)

BTW, the serial ports on the Duo are at different locations depending on
whether it's docked or not.  If it's docked, they are located in NuBus slot
E along with the framebuffer and SONIC.  This might be why serial consoles
are not always working. (I've been busy getting the framebuffer and SONIC
working so I haven't yet investigated)

Cheers

--
dhd@... (wearing my Linux/m68k+Mac+Debian hat)
   Latest kernels/patches: http://maclinux.plcom.on.ca/pub/



------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/linux-mac68k
http://www.egroups.com - Simplifying group communications