On Mon, Nov 14, 2005 at 11:14:59PM +1100, Finn Thain wrote:
> On Sun, 13 Nov 2005, Brad Boyer wrote:
> > The CUDA ADB driver is very cavalier about poking bits in the VIA. It's
> > possible that it's conflicting with one of the VIA driver changes in one
> > of those patches.
>
> patch_b is confined to VIA2... Adding patch_c didn't make any difference.
>
> I didn't think ADB was related to VIA2?

That's true. There shouldn't be anything touching VIA2 in the ADB code. I
have to admit that I haven't looked at your patches very closely. In any
case, there are some things in the CUDA code that might affect timers in
particular, and perhaps other obscure parts on the side. It's not
exactly cleanly written, but I haven't taken the time to figure out
how the code is supposed to work. I'll try to find some time to work
on 68k code again sometime soon. Perhaps in a couple weeks when I have
some holidays from work.

	 Brad Boyer
	 flar@...

_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Sun, 13 Nov 2005, Brad Boyer wrote:

> On Mon, Nov 14, 2005 at 03:18:23PM +1100, Finn Thain wrote:
> > On Sun, 13 Nov 2005, bob_b@... wrote:
> > > I finally got rid of the error by disabling ADB in the 2.6.14
> > > kernel. It appears there is some conflict between that and esp. I
> > > tried disabling ADB because I came to remembered that both sonic and
> > > esp worked in 2.6.10 so I just duplicated that config in 2.6.14. Do
> > > you think the dma patch could have something to do with that??
> >
> > To answer that question I would have to eliminate the dma variable
> > emprically. ADB shares VIA1 with the timer interrupt, and so I think
> > that dma isn't the most likely culprit. But that is about the extent
> > of my ADB knowledge, I'm afraid.
>
> The CUDA ADB driver is very cavalier about poking bits in the VIA. It's
> possible that it's conflicting with one of the VIA driver changes in one
> of those patches.

patch_b is confined to VIA2... Adding patch_c didn't make any difference.

I didn't think ADB was related to VIA2?

-f

> The only CUDA box I have is a Q840AV, so I'm not sure if it would even
> be prone to the same errors.
>
>  Brad Boyer
>  flar@...
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Mon, Nov 14, 2005 at 03:18:23PM +1100, Finn Thain wrote:
> On Sun, 13 Nov 2005, bob_b@... wrote:
> > I finally got rid of the error by disabling ADB in the 2.6.14 kernel. It
> > appears there is some conflict between that and esp. I tried disabling
> > ADB because I came to remembered that both sonic and esp worked in
> > 2.6.10 so I just duplicated that config in 2.6.14. Do you think the dma
> > patch could have something to do with that??
>
> To answer that question I would have to eliminate the dma variable
> emprically. ADB shares VIA1 with the timer interrupt, and so I think that
> dma isn't the most likely culprit. But that is about the extent of my ADB
> knowledge, I'm afraid.

The CUDA ADB driver is very cavalier about poking bits in the VIA. It's
possible that it's conflicting with one of the VIA driver changes in
one of those patches. The only CUDA box I have is a Q840AV, so I'm
not sure if it would even be prone to the same errors.

	 Brad Boyer
	 flar@...

_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Sun, 13 Nov 2005, bob_b@... wrote:

> Finn Thain:
> > I wonder if the esp driver is sensitive to dma_supported() or some
> > other change? Maybe it would be worth trying it without the 42_dma
> > patch (and without sonic, obviously).
>
> Tried the patchc #3, no change...
>
> I finally got rid of the error by disabling ADB in the 2.6.14 kernel. It
> appears there is some conflict between that and esp. I tried disabling
> ADB because I came to remembered that both sonic and esp worked in
> 2.6.10 so I just duplicated that config in 2.6.14. Do you think the dma
> patch could have something to do with that??

To answer that question I would have to eliminate the dma variable
emprically. ADB shares VIA1 with the timer interrupt, and so I think that
dma isn't the most likely culprit. But that is about the extent of my ADB
knowledge, I'm afraid.

-f

>
> Bob
>
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

Finn Thain:
> I wonder if the esp driver is sensitive to dma_supported() or some other
> change? Maybe it would be worth trying it without the 42_dma patch (and
> without sonic, obviously).

Tried the patchc #3, no change...

I finally got rid of the error by disabling ADB in the 2.6.14 kernel. It appears
there is some conflict between that and esp. I tried disabling ADB because I
came to
remembered that both sonic and esp worked in 2.6.10 so I just duplicated that
config
in 2.6.14. Do you think the dma patch could have something to do with that??

Bob
--
/~\ The ASCII       | Robert E. Brose II    N0QBJ
\ / Ribbon Campaign | http://www.qbjnet.com/
  X  Help cure       | mailto:bob@...
/ \ HTML Email      | public key at http://www.qbjnet.com/key.html
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

Hi Kars,
Looks like it wasn't esp directly anyway. I disabled the adb driver in the
2.6.14 kernel and it works now..

Bob

Kars de Jong:
> On zo, 2005-11-13 at 01:15 -0600, bob_b@... wrote:
> > I'm wondering if perhaps it isn't the interrupts in the case of the esp and
> > instead is just a esp driver change? Esp DID look somewhat different to me
> > in 2.6.14 from 2.6.10. I could try hacking the 2.6.10 esp driver into
2.6.14...
>
> I looked at the differences too, but I doubt they are relevant. It's
> mostly some cleanups and changed semantics for the reset() function:
> apparently host_lock used to be acquired by the caller, now the reset()
> function must acquire it first.
>
> But you don't seem to experience lockups or bus resets, so I doubt this
> is it.
>
>
> Kind regards,
>
> Kars.
>
>

--
/~\ The ASCII       | Robert E. Brose II    N0QBJ
\ / Ribbon Campaign | http://www.qbjnet.com/
  X  Help cure       | mailto:bob@...
/ \ HTML Email      | public key at http://www.qbjnet.com/key.html
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Sun, 13 Nov 2005, Kars de Jong wrote:

> On zo, 2005-11-13 at 01:15 -0600, bob_b@... wrote:
> > I'm wondering if perhaps it isn't the interrupts in the case of the
> > esp and instead is just a esp driver change? Esp DID look somewhat
> > different to me in 2.6.14 from 2.6.10. I could try hacking the 2.6.10
> > esp driver into 2.6.14...
>
> I looked at the differences too, but I doubt they are relevant. It's
> mostly some cleanups and changed semantics for the reset() function:
> apparently host_lock used to be acquired by the caller, now the reset()
> function must acquire it first.
>
> But you don't seem to experience lockups or bus resets, so I doubt this
> is it.

I wonder if the esp driver is sensitive to dma_supported() or some other
change? Maybe it would be worth trying it without the 42_dma patch (and
without sonic, obviously).

-f

>
>
> Kind regards,
>
> Kars.
>
>
>
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

Finn Thain:

> Anyway, there is one other patch. It is a more aggressive reworking of the
> VIA and NuBus IRQ code,
>
>
http://www.telegraphics.com.au/~fthain/patches/hacks/patch_c-interrupts-again-ag\
ain2.diff
>
> You need to reverse patch_c-irq-fixes2.diff before applying it. It was an
> attempt to get sonic, scsi and ide working simultaneously on the LC 630
> without wedging the NuBus. If you get time, it would be great if you could
> try it.

Same result unfortunately. I tried it with and without the via_alt_mapping
code.

I'm wondering if perhaps it isn't the interrupts in the case of the esp and
instead is just a esp driver change? Esp DID look somewhat different to me
in 2.6.14 from 2.6.10. I could try hacking the 2.6.10 esp driver into 2.6.14...

Bob
--
/~\ The ASCII       | Robert E. Brose II    N0QBJ
\ / Ribbon Campaign | http://www.qbjnet.com/
  X  Help cure       | mailto:bob@...
/ \ HTML Email      | public key at http://www.qbjnet.com/key.html
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Sat, 12 Nov 2005, bob_b@... wrote:

> Finn Thain:
> >
> > You could try sg_verify from the sg3-utils package ... I'd probably
> > run that in single user mode, but only because I don't know what
> > happens when a disk gets accessed during a verify. Or you could use
> > Hard Disk Toolkit or similar under Mac OS.
>
> Tried with the patched 2.6.10 and it went through the whole disk without
> a problem.

Hmm. I hate regressions.

> > Sorry, I just remembered that the old patch_b is liable to break CUDA
> > ADB. Best to avoid the old ones and just use these instead,
> >
> >
http://www.telegraphics.com.au/~fthain/patches/sent/patch_b-mac68k_cvs_via_clean\
up_and_fix2.diff
> >
> > ...(which you already have), and then apply,
> >
> > http://www.telegraphics.com.au/~fthain/patches/hacks/patch_c-irq-fixes2.diff
>
> I tried it with your newest b and c patches above in 2.6.14 and it fails
> randomly. Here is a typical message:
>
> VERIFY(10) command problem: Host_status=0x06 [DID_PARITY]
> Verify(10) failed near lba=2176 [0x880]

Thanks for trying. I would try to reproduce this myself, but my macs are
stored about 500 km from my present location. I do have a powerbook 150
with me, but it didn't like the 2.6.12 kernel at all (though it uses 5380
scsi, not ESP). I intend to test 2.6.14, but at the moment, I don't have a
way to get a kernel onto it (I'm working on that problem).

Anyway, there is one other patch. It is a more aggressive reworking of the
VIA and NuBus IRQ code,

http://www.telegraphics.com.au/~fthain/patches/hacks/patch_c-interrupts-again-ag\
ain2.diff

You need to reverse patch_c-irq-fixes2.diff before applying it. It was an
attempt to get sonic, scsi and ide working simultaneously on the LC 630
without wedging the NuBus. If you get time, it would be great if you could
try it.

-f


> The drive doesn't have a jumper for disabling parity. Seems likely though
> that something else is up since it worked fine in 2.6.10.
>
> Bob
>
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

Finn Thain:
>
> You could try sg_verify from the sg3-utils package ... I'd probably run
> that in single user mode, but only because I don't know what happens when
> a disk gets accessed during a verify. Or you could use Hard Disk Toolkit
> or similar under Mac OS.

Tried with the patched 2.6.10 and it went through the whole disk without
a problem.

> Sorry, I just remembered that the old patch_b is liable to break CUDA ADB.
> Best to avoid the old ones and just use these instead,
>
>
http://www.telegraphics.com.au/~fthain/patches/sent/patch_b-mac68k_cvs_via_clean\
up_and_fix2.diff
>
> ...(which you already have), and then apply,
>
> http://www.telegraphics.com.au/~fthain/patches/hacks/patch_c-irq-fixes2.diff
>
> -f

I tried it with your newest b and c patches above in 2.6.14 and it fails
randomly. Here is a typical message:

VERIFY(10) command problem: Host_status=0x06 [DID_PARITY]
Verify(10) failed near lba=2176 [0x880]

The drive doesn't have a jumper for disabling parity. Seems likely though
that something else is up since it worked fine in 2.6.10.

Bob
--
/~\ The ASCII       | Robert E. Brose II    N0QBJ
\ / Ribbon Campaign | http://www.qbjnet.com/
  X  Help cure       | mailto:bob@...
/ \ HTML Email      | public key at http://www.qbjnet.com/key.html
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Fri, 11 Nov 2005, bob@... wrote:

> I haven't tried the patch_c yet. I did look at the source for the mac
> esp in the 2.6.10 with the 2.6.8 patches a,b, and c and compared it to
> the source for the mac esp on 2.6.14. There seem to be significant
> differences.
>
> After loading the machine down heavily (with a boinc seti client) and
> running a kernel compile I got a scsi error. (i/o error and illegal
> seek).
>
> I guess those esp0: Warning, live target 0 not responding to selection.
> messages might not be as harmless as I thought.
>
> I rechecked the HW, disconnected the CD so the HD is the only device on
> the scsi bus. It's jumpered and terminated properly. I tried it with and
> without disable unit attention jumpered and it didn't make any
> difference.

You could try sg_verify from the sg3-utils package ... I'd probably run
that in single user mode, but only because I don't know what happens when
a disk gets accessed during a verify. Or you could use Hard Disk Toolkit
or similar under Mac OS.

>
> with the alt interrupt patch, here is /proc/interrupts:
> auto  0:          0   spurious int
> auto  1:          0   software
> auto  2:      27266   via2
> auto  3:       9194   sonic
> auto  4:          0   scc
> auto  5:          0   int5 handler
> auto  6:    3389816   via1
> auto  7:          0   NMI
> via1  9:    1275769   framebuffer vbl
>                       framebuffer vbl
> via1 10:        292   ADB
> via1 14:    2119663   timer
> via2 17:          0 F nubus
> via2 19:      27266   Mac ESP SCSI
>
> Looks like everything is on a seperate int now.

Yep, looks good.

> I'll try backing off the patch_b-mac68k_cvs_via_cleanup_and_fix2 patch
> and applying the old b and c patch and see if anything changes for the
> better...

Sorry, I just remembered that the old patch_b is liable to break CUDA ADB.
Best to avoid the old ones and just use these instead,

http://www.telegraphics.com.au/~fthain/patches/sent/patch_b-mac68k_cvs_via_clean\
up_and_fix2.diff

...(which you already have), and then apply,

http://www.telegraphics.com.au/~fthain/patches/hacks/patch_c-irq-fixes2.diff

-f

> Thanks,
> Bob
>
>
> Finn Thain:
> >
> > On Fri, 11 Nov 2005, Kars de Jong wrote:
> >
> > > On do, 2005-11-10 at 20:12 -0600, Bob wrote:
> > > > I see something similar to that on my old source directory:
> > > > patch_a-sonic-overhaul-and-update-new.diff
> > > > patch_b-mac68k_cvs_via_cleanup.diff
> > > > patch_c-irq-fixes.diff
> > > > Looks like those were for 2.6.8 and I bet I applied at least some if not
all
> > > > of them to 2.6.10 which might explain why it worked....
> > > >
> > > > I've just built and booted a new kernel with the patch_b...
> > > > Looks like patch_b-mac68k_cvs_via_cleanup_and_fix2.diff
> > > > fixed the sonic problem but I'm still getting lots of the scsi messages:
> > > > esp0: Warning, live target 0 not responding to selection,
> > > > however the machine is still running.
> > >
> > > You should probably also apply patch_c, according to the original mail
> > > that went with these patches:
> > >
> > > > The patches don't change the ESP or 8390 driver code, those
> > > > drivers benfit only from the interrupt handling fixes in patches b and
c.
> >
> > It is certainly worth a try. The original patch_b and patch_c can be used
> > together, but neither one can be used with
patch_b-mac68k_cvs_via_cleanup_and_fix2.
> >
> > -f
> >
> > >
> > >
> > > Kind regards,
> > >
> > > Kars.
> > >
> > >
> > >
> >
>
>
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

I haven't tried the patch_c yet. I did look at the source for the mac esp
in the 2.6.10 with the 2.6.8 patches a,b, and c and compared it to the
source for the mac esp on 2.6.14. There seem to be significant differences.

After loading the machine down heavily (with a boinc seti client) and
running a kernel compile I got a scsi error. (i/o error and illegal seek).

I guess those esp0: Warning, live target 0 not responding to selection.
messages might not be as harmless as I thought.

I rechecked the HW, disconnected the CD so the HD is the only device
on the scsi bus. It's jumpered and terminated properly. I tried it with and
without disable unit attention jumpered and it didn't make any difference.

with the alt interrupt patch, here is /proc/interrupts:
auto  0:          0   spurious int
auto  1:          0   software
auto  2:      27266   via2
auto  3:       9194   sonic
auto  4:          0   scc
auto  5:          0   int5 handler
auto  6:    3389816   via1
auto  7:          0   NMI
via1  9:    1275769   framebuffer vbl
                       framebuffer vbl
via1 10:        292   ADB
via1 14:    2119663   timer
via2 17:          0 F nubus
via2 19:      27266   Mac ESP SCSI

Looks like everything is on a seperate int now.

I'll try backing off the  patch_b-mac68k_cvs_via_cleanup_and_fix2
patch and applying the old b and c patch and see if anything changes
for the better...

Thanks,
Bob


Finn Thain:
>
> On Fri, 11 Nov 2005, Kars de Jong wrote:
>
> > On do, 2005-11-10 at 20:12 -0600, Bob wrote:
> > > I see something similar to that on my old source directory:
> > > patch_a-sonic-overhaul-and-update-new.diff
> > > patch_b-mac68k_cvs_via_cleanup.diff
> > > patch_c-irq-fixes.diff
> > > Looks like those were for 2.6.8 and I bet I applied at least some if not
all
> > > of them to 2.6.10 which might explain why it worked....
> > >
> > > I've just built and booted a new kernel with the patch_b...
> > > Looks like patch_b-mac68k_cvs_via_cleanup_and_fix2.diff
> > > fixed the sonic problem but I'm still getting lots of the scsi messages:
> > > esp0: Warning, live target 0 not responding to selection,
> > > however the machine is still running.
> >
> > You should probably also apply patch_c, according to the original mail
> > that went with these patches:
> >
> > > The patches don't change the ESP or 8390 driver code, those
> > > drivers benfit only from the interrupt handling fixes in patches b and c.
>
> It is certainly worth a try. The original patch_b and patch_c can be used
> together, but neither one can be used with
patch_b-mac68k_cvs_via_cleanup_and_fix2.
>
> -f
>
> >
> >
> > Kind regards,
> >
> > Kars.
> >
> >
> >
>

--
/~\ The ASCII       | Robert E. Brose II    N0QBJ
\ / Ribbon Campaign | http://www.qbjnet.com/
  X  Help cure       | mailto:bob@...
/ \ HTML Email      | public key at http://www.qbjnet.com/key.html

_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Fri, 11 Nov 2005, Kars de Jong wrote:

> On do, 2005-11-10 at 20:12 -0600, Bob wrote:
> > I see something similar to that on my old source directory:
> > patch_a-sonic-overhaul-and-update-new.diff
> > patch_b-mac68k_cvs_via_cleanup.diff
> > patch_c-irq-fixes.diff
> > Looks like those were for 2.6.8 and I bet I applied at least some if not all
> > of them to 2.6.10 which might explain why it worked....
> >
> > I've just built and booted a new kernel with the patch_b...
> > Looks like patch_b-mac68k_cvs_via_cleanup_and_fix2.diff
> > fixed the sonic problem but I'm still getting lots of the scsi messages:
> > esp0: Warning, live target 0 not responding to selection,
> > however the machine is still running.
>
> You should probably also apply patch_c, according to the original mail
> that went with these patches:
>
> > The patches don't change the ESP or 8390 driver code, those
> > drivers benfit only from the interrupt handling fixes in patches b and c.

It is certainly worth a try. The original patch_b and patch_c can be used
together, but neither one can be used with
patch_b-mac68k_cvs_via_cleanup_and_fix2.

-f

>
>
> Kind regards,
>
> Kars.
>
>
>
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Thu, 10 Nov 2005, Bob wrote:

> I've just built and booted a new kernel with the patch_b... Looks like
> patch_b-mac68k_cvs_via_cleanup_and_fix2.diff fixed the sonic problem but
> I'm still getting lots of the scsi messages: esp0: Warning, live target
> 0 not responding to selection, however the machine is still running.

Hmm.. I guess this can't be a hardware problem if 2.6.10 doesn't print
these diagnostics...

> What is the via_alt_mapping set?

You need a patch like this. I haven't actually tested via_alt_mapping on
MAC_MODEL_P575 and MAC_MODEL_P588. The others work, however.

--- a/arch/m68k/mac/via.c 2005-03-06 21:36:01.197341937 +1100
+++ b/arch/m68k/mac/via.c 2005-03-11 12:59:11.000000000 +1100
@@ -193,8 +193,15 @@
 	 /* that the IIfx emulates this alternate mapping using the OSS. */

 	 switch(macintosh_config->ident) {
+  case MAC_MODEL_P475:
+  case MAC_MODEL_P475F:
+  case MAC_MODEL_P575:
+  case MAC_MODEL_P588:
+  case MAC_MODEL_Q605:
+  case MAC_MODEL_Q605_ACC:
 		 case MAC_MODEL_C610:
 		 case MAC_MODEL_Q610:
+  case MAC_MODEL_Q630:
 		 case MAC_MODEL_C650:
 		 case MAC_MODEL_Q650:
 		 case MAC_MODEL_Q700:


> Any idea about the genrtc oops?

I gather from the repo that this bug is an old one. There is a compiler
#warning pragma that relates to it which shows up during compilation. It
looks like the oops was preferred over code that wouldn't compile.

Fixing it is fairly low on my priority list. Now that you have ethernet,
NTP should be able to take care of the clock (you may want to disable the
date-triggered fsck with tune2fs).

> Thanks Much...

Thanks for your help with testing.

-f

>
> Bob
>
> Finn Thain:
> >
> > Please try this patch,
> >
> >
http://www.telegraphics.com.au/~fthain/patches/sent/patch_b-mac68k_cvs_via_clean\
up_and_fix2.diff
> >
> > It was needed to get SCSI working on my Q650, but it might help with SONIC
> > too since you have the SONIC IRQ on VIA2.
> >
> > > I can reproduce this easily with flood pings from a another machine on
> > > the net. 2.6.10 goes for hours without trouble. 2.6.14 dies pretty fast.
> > >
> > > Also, I'm getting some messages from the scsi driver that were not in
2.6.10:
> > > esp0: Warning, live target 0 not responding to selection.
> > > Though this doesn't appear to kill the drive.
> > >
> > > I'm wondering if the macsonic and esp problems are lost interrupts?
> > > cat interrupts-2.6.14-adb
> > > auto  0:          0   spurious int
> > > auto  1:      31268   via1
> > > auto  2:       3515   via2
> > > auto  3:          0   int3 handler
> > > auto  4:          0   scc
> > > auto  5:          0   int5 handler
> > > auto  6:          0   int6 handler
> > > auto  7:          0   NMI
> > > via1  9:      12213   framebuffer vbl
> > >                       framebuffer vbl
> > > via1 10:        341   ADB
> > > via1 14:      19721   timer
> > > via2 17:        788 F nubus
> > > via2 19:       2727   Mac ESP SCSI
> > > nbus 56:        788 F sonic
> >
> > This machine should work with via_alt_mapping set. You may want to try
> > that if the patch doesn't help with the SONIC.
> >
> > -f
> >
>
>
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

Oh DARN!

I see something similar to that on my old source directory:
patch_a-sonic-overhaul-and-update-new.diff
patch_b-mac68k_cvs_via_cleanup.diff
patch_c-irq-fixes.diff
Looks like those were for 2.6.8 and I bet I applied at least some if not all
of them to 2.6.10 which might explain why it worked....

I've just built and booted a new kernel with the patch_b...
Looks like patch_b-mac68k_cvs_via_cleanup_and_fix2.diff
fixed the sonic problem but I'm still getting lots of the scsi messages:
esp0: Warning, live target 0 not responding to selection,
however the machine is still running.

What is the via_alt_mapping set?

Any idea about the genrtc oops?

Thanks Much...

Bob

Finn Thain:
>
> Please try this patch,
>
>
http://www.telegraphics.com.au/~fthain/patches/sent/patch_b-mac68k_cvs_via_clean\
up_and_fix2.diff
>
> It was needed to get SCSI working on my Q650, but it might help with SONIC
> too since you have the SONIC IRQ on VIA2.
>
> > I can reproduce this easily with flood pings from a another machine on
> > the net. 2.6.10 goes for hours without trouble. 2.6.14 dies pretty fast.
> >
> > Also, I'm getting some messages from the scsi driver that were not in
2.6.10:
> > esp0: Warning, live target 0 not responding to selection.
> > Though this doesn't appear to kill the drive.
> >
> > I'm wondering if the macsonic and esp problems are lost interrupts?
> > cat interrupts-2.6.14-adb
> > auto  0:          0   spurious int
> > auto  1:      31268   via1
> > auto  2:       3515   via2
> > auto  3:          0   int3 handler
> > auto  4:          0   scc
> > auto  5:          0   int5 handler
> > auto  6:          0   int6 handler
> > auto  7:          0   NMI
> > via1  9:      12213   framebuffer vbl
> >                       framebuffer vbl
> > via1 10:        341   ADB
> > via1 14:      19721   timer
> > via2 17:        788 F nubus
> > via2 19:       2727   Mac ESP SCSI
> > nbus 56:        788 F sonic
>
> This machine should work with via_alt_mapping set. You may want to try
> that if the patch doesn't help with the SONIC.
>
> -f
>

--
/~\ The ASCII       | Robert E. Brose II    N0QBJ
\ / Ribbon Campaign | http://www.qbjnet.com/
  X  Help cure       | mailto:bob@...
/ \ HTML Email      | public key at http://www.qbjnet.com/key.html
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Fri, 10 Nov 2005, bob wrote:

> Thanks for the OSX compile help!
>
> I'm now running 2.6.14-m68k on a Performa 575 w/ 68040 (not LC).
> The ADB seems to work fine now with light testing, the console is
> back, whee...

Great!

> On the downside though, the macsonic driver which worked fine in 2.6.10-m68k
> is misbehaving. It just dies at times, when under load with a single
> message:
> NETDEV WATCHDOG: eth0: transmit timed out
> The ethernet is unusable after this point.

Please try this patch,

http://www.telegraphics.com.au/~fthain/patches/sent/patch_b-mac68k_cvs_via_clean\
up_and_fix2.diff

It was needed to get SCSI working on my Q650, but it might help with SONIC
too since you have the SONIC IRQ on VIA2.

> I can reproduce this easily with flood pings from a another machine on
> the net. 2.6.10 goes for hours without trouble. 2.6.14 dies pretty fast.
>
> Also, I'm getting some messages from the scsi driver that were not in 2.6.10:
> esp0: Warning, live target 0 not responding to selection.
> Though this doesn't appear to kill the drive.
>
> I'm wondering if the macsonic and esp problems are lost interrupts?
> cat interrupts-2.6.14-adb
> auto  0:          0   spurious int
> auto  1:      31268   via1
> auto  2:       3515   via2
> auto  3:          0   int3 handler
> auto  4:          0   scc
> auto  5:          0   int5 handler
> auto  6:          0   int6 handler
> auto  7:          0   NMI
> via1  9:      12213   framebuffer vbl
>                       framebuffer vbl
> via1 10:        341   ADB
> via1 14:      19721   timer
> via2 17:        788 F nubus
> via2 19:       2727   Mac ESP SCSI
> nbus 56:        788 F sonic

This machine should work with via_alt_mapping set. You may want to try
that if the patch doesn't help with the SONIC.

-f

_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

Thanks for the OSX compile help!

I'm now running 2.6.14-m68k on a Performa 575 w/ 68040 (not LC).
The ADB seems to work fine now with light testing, the console is
back, whee...

On the downside though, the macsonic driver which worked fine in 2.6.10-m68k
is misbehaving. It just dies at times, when under load with a single
message:
NETDEV WATCHDOG: eth0: transmit timed out
The ethernet is unusable after this point.

I can reproduce this easily with flood pings from a another machine on
the net. 2.6.10 goes for hours without trouble. 2.6.14 dies pretty fast.

Also, I'm getting some messages from the scsi driver that were not in 2.6.10:
esp0: Warning, live target 0 not responding to selection.
Though this doesn't appear to kill the drive.

I'm wondering if the macsonic and esp problems are lost interrupts?
cat interrupts-2.6.14-adb
auto  0:          0   spurious int
auto  1:      31268   via1
auto  2:       3515   via2
auto  3:          0   int3 handler
auto  4:          0   scc
auto  5:          0   int5 handler
auto  6:          0   int6 handler
auto  7:          0   NMI
via1  9:      12213   framebuffer vbl
                       framebuffer vbl
via1 10:        341   ADB
via1 14:      19721   timer
via2 17:        788 F nubus
via2 19:       2727   Mac ESP SCSI
nbus 56:        788 F sonic

Finally, the rtc driver oops in both versions:

Generic RTC Driver v1.07
Unable to handle kernel NULL pointer dereference at virtual address 00000000
Oops: 00000000
Modules linked in: genrtc
PC: [<00000000>] 0x0

SR: 2014  SP: 07c81ec0  a2: 080f8a60
d0: 00000000    d1: 00000000    d2: 00000002    d3: ffffffe7
d4: 00000003    d5: 00000001    a0: 00000000    a1: 08262108
Process hwclock (pid: 91, stackpage=080f9a60)
Stack from 07c81ec0:
         00000000 00000002 ffffffe7 00000003 00000001 00000000 08262108 080f8a60
         00000000 ffffffff 00000000 20140000 00007008 07c81f4c 05e60005 00000005
         00000000 07c81f98 000363a4 001c9030 08392618 c0034090 00000000 083730d0
         083f5800 c0034090 0890c1b8 00000000 07c81f6c 80247009 ffffffe7 00000003
         0000000f 083ffe70 effffc14 00000000 000005e2 00000000 0000000f 000e5ec1
         07c81f98 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Call Trace: [<0000219e>] buserr+0x1e/0x28
  [<00050178>] sys_ioctl+0x8e/0x1ba
  [<0008c003>] isofs_export_get_parent+0x1f/0x114
  [<00002280>] system_call+0x30/0x46
  [<0000c00b>] res_func+0x1293/0x1482


Linux version 2.6.14-m68k (bob@...) (gcc version 2.95.4 20011002 (Debi
an prerelease)) #5 Wed Nov 9 23:31:24 CST 2005
Detected Macintosh model: 92
  Penguin bootinfo data:
  Video: addr 0xf9000080 row 0x680 depth 10 dimensions 800 x 600
  Videological 0xf0100080 phys. 0x51900080, SCC at 0x50f0c020
  Boottime: 0x43728a59 GMTBias: 0xfffffe98
  Machine ID: 92 CPUid: 0x2 memory size: 0x84
VIA1 at 50f00000 is a 6522 or clone
VIA2 at 50f02000 is <6>a 6522 or clone
Apple Macintosh Performa 575
On node 0 totalpages: 33792
   DMA zone: 33792 pages, LIFO batch:15
   Normal zone: 0 pages, LIFO batch:1
   HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: root=/dev/sda5 video=font:VGA8x16
Killing onboard sonic... Done.
PID hash table entries: 1024 (order: 10, 16384 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 131456k/135168k available (1584k kernel code, 2016k data, 96k init)
Calibrating delay loop... 26.52 BogoMIPS (lpj=132608)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
NuBus: Scanning NuBus slots.
SCSI subsystem initialized
Initializing Cryptographic API
macfb: framebuffer at 0xf9000080, mapped to 0x08800080, size 975k
macfb: mode is 800x600x16, linelength=1664
macfb: scrolling: redraw
macfb: directcolor: size=1:5:5:5, shift=15:10:5:0
fbcon_startup: No VBL detected, using timer based cursor.
mac_delete_irq: tried to remove invalid irq
Console: switching to colour frame buffer device 100x37
fb0: Macintosh DAFB built-in frame buffer device
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
Checking for internal Macintosh ethernet (SONIC).. yes
sonic.c:v0.92 20.9.98 tsbogend@...
macsonic.0: onboard / comm-slot SONIC at 0x50f0a000
macsonic.0: revision 0x0100, using 32 bit DMA and register offset 2
eth0: MAC 00:a0:40:23:be:de IRQ 56
mac_esp: io base at 0x50f10000
esp: using quick version
esp: addr at 0x50f10000
SCSI ID 7 Clk 16MHz CCF=4 TOut 138 NCR53C9x(esp236)

mac_esp: 1 esp controllers found
scsi0 : ESP236 (NCR53C9x)
   Vendor: WDIGTL    Model: ENTERPRISE        Rev: 1.80
   Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 8515173 512-byte hdwr sectors (4360 MB)
SCSI device sda: drive cache: write through
SCSI device sda: 8515173 512-byte hdwr sectors (4360 MB)
SCSI device sda: drive cache: write through
  sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
input: Macintosh mouse button emulation
Macintosh CUDA driver v0.5 for Unified ADB.
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
adb: starting probe task...
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
adb devices: [2]: 2 2 [3]: 3 1
ADB keyboard at 2, handler set to 3
Detected ADB keyboard, type ANSI.
input: ADB keyboard on adb2:2.02/input
ADB mouse at 3, handler set to 4<6>
kjournald starting.  Commit interval 5 second s
input: ADB mouse on adb3:3.01/input
adb: finished probe task...
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
esp0: Warning, live target 0 not responding to selection.
esp0: Warning, live target 0 not responding to selection.
Adding 131064k swap on /dev/sda4.  Priority:-1 extents:1 across:131064k
EXT3 FS on sda5, internal journal
esp0: Warning, live target 0 not responding to selection.
esp0: Warning, live target 0 not responding to selection.
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
IPv4 over IPv4 tunneling driver
NET: Registered protocol family 5

Bob

_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

I'm currently running 2.6.10-m68k on a Performa 575 w/ 68040 (not LC).
I'd like to compile the current 2.6, mainly to see if the non-functional
ADB has been fixed.

I'm using the cross compiling instructions at:
http://www.mac.linux-m68k.org/docs/cross-dev-os-x.php

Everything is setup fine, following the instructions EXACTLY and though the
patch at sourceforge is for 2.6.12 it applies to the cvs 2.6.14-m68k
kernel well enough.

When I get to the compile stage I get :

make
   CHK     include/linux/version.h
   HOSTCC  scripts/basic/fixdep
   HOSTCC  scripts/basic/split-include
   HOSTCC  scripts/basic/docproc
   SPLIT   include/linux/autoconf.h -> include/config/*
   CC      arch/m68k/kernel/asm-offsets.s
   GEN     include/asm-m68k/asm-offsets.h
   HOSTCC  scripts/genksyms/genksyms.o
   HOSTCC  scripts/genksyms/lex.o
   HOSTCC  scripts/genksyms/parse.o
   HOSTLD  scripts/genksyms/genksyms
   CC      scripts/mod/empty.o
   HOSTCC  scripts/mod/mk_elfconfig
   MKELF   scripts/mod/elfconfig.h
   HOSTCC  scripts/mod/file2alias.o
   HOSTCC  scripts/mod/modpost.o
   HOSTCC  scripts/mod/sumversion.o
   HOSTLD  scripts/mod/modpost
   HOSTCC  scripts/kallsyms
scripts/kallsyms.c: In function `compress_symbols':
scripts/kallsyms.c:366: warning: implicit declaration of function `memmem'
scripts/kallsyms.c:366: warning: assignment makes pointer from integer without a
cast
scripts/kallsyms.c:385: warning: assignment makes pointer from integer without a
cast
ld: Undefined symbols:
_memmem
make[1]: *** [scripts/kallsyms] Error 1
make: *** [scripts] Error 2

Any ideas??

Thanks,
Bob
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

Hey,

Samual Acorn wrote:
>
> just wondering if anyone on this list knows of any terminal emulation
> software (usable over serial port... not just telnet) for the mac that
> wont choke on the linux console?
>
> pref something free
minicom usually does it... or seyon under X11

-R
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Thu, Oct 13, 2005 at 10:45:26PM +0200, Laurent Vivier wrote:
> I have a "mac_do_irq_list: spurious interrupt 17".
> This is the same as for the 840AV.
> On LCIII, I can correct it using mac_disable_irq() in the loop,
> on the 840AV, in fact, my modification doesn't work ("lock nubus" is
> not working)
> I can avoid the problem by disabling video IRQ from EMILE (csCode =7,
> flag = 1, PBControl() on ".Apple_Video...")
>
> Any Ideas ?

If I had to speculate, I'd say that they attached the video partially
into the NuBus system, but didn't really make it a full NuBus device.
It probably injects interrupts directly into the system, and it's
possible that the only way to stop the interrupts is to tell the
video circuits to stop sending them. The driver call almost certainly
reprograms the video rather than fiddling around with VIA bits.
Stranger things have happened in Apple hardware.

	 Brad Boyer
	 flar@...

_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Oct 14, 2005, at 1:41 AM, Samual Acorn wrote:

> ive been using a duo280c as a dumb (serial) terminal for quite some
> time...
> black night is the best emulator i could find.. but try using it with
> mp3blaster...

Have you tried ZTerm?

Josh

_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

just wondering if anyone on this list knows of any terminal emulation
software (usable over serial port... not just telnet) for the mac that
wont choke on the linux console?

pref something free


--
--sam
http://mephitus.renamon.org/
"When you've done something right, no one will be sure you've done
anything at all." -- Futurama
--
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

before anyone asks.. i need the 2.4 kernel because 2.2 doesnt support
powerbook keyboards....

On 13/10/05, Samual Acorn <sam.acorn@...> wrote:
> anyone have a list of the options the mac kernel (2.4) supports?
>
> and heres the big one;
> anyone out there have a 2.4 kernel with serial support compiled in?
> anyone out there have a ramdisk with minicom in it?
>
>
> ive been using a duo280c as a dumb (serial) terminal for quite some time...
> black night is the best emulator i could find.. but try using it with
> mp3blaster...
>
> then i discovered linux was available so i figured of all the
> 'emulators' out there linux would be the best... now i just need to
> get ahold of a kernel/ramdisk that does what i need it to do (cross
> compiling isnt my forte)
>
>
> --
> --sam
> http://mephitus.renamon.org/
> "When you've done something right, no one will be sure you've done
> anything at all." -- Futurama
> --
>


--
--sam
http://mephitus.renamon.org/
"When you've done something right, no one will be sure you've done
anything at all." -- Futurama
--
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

anyone have a list of the options the mac kernel (2.4) supports?

and heres the big one;
anyone out there have a 2.4 kernel with serial support compiled in?
anyone out there have a ramdisk with minicom in it?


ive been using a duo280c as a dumb (serial) terminal for quite some time...
black night is the best emulator i could find.. but try using it with
mp3blaster...

then i discovered linux was available so i figured of all the
'emulators' out there linux would be the best... now i just need to
get ahold of a kernel/ramdisk that does what i need it to do (cross
compiling isnt my forte)


--
--sam
http://mephitus.renamon.org/
"When you've done something right, no one will be sure you've done
anything at all." -- Futurama
--
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Wed, 12 Oct 2005, Laurent Vivier wrote:

> OK, I remove this part and search the real reason...

Thanks. If you can find out which spurious interrupts are getting though,
I'll help eye-ball the code (my LC III is not here unfortunately).

-f
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

Le mer 12/10/2005 à 07:42, Finn Thain a écrit :
> On Tue, 11 Oct 2005, Laurent Vivier wrote:
>
> > Le mar 11/10/2005 à 03:18, Finn Thain a écrit :
> > > On Tue, 11 Oct 2005, Laurent Vivier wrote:
> > [...]
> > > > Index: linux-mac68k-2.2/arch/m68k/mac/macints.c
> > > > ===================================================================
> > > > --- linux-mac68k-2.2.orig/arch/m68k/mac/macints.c 2005-09-05
21:03:25.000000000 +0200
> > > > +++ linux-mac68k-2.2/arch/m68k/mac/macints.c 2005-10-09
20:00:23.000000000 +0200
> > > > @@ -193,6 +193,7 @@
> > > >  void mac_nmi_handler(int, void *, struct pt_regs *);
> > > >  void mac_debug_handler(int, void *, struct pt_regs *);
> > > >  void mac_SCC_handler(int, void *, struct pt_regs *);
> > > > +void mac_clear_irq( unsigned int irq );
> > > >
> > > >  /* #define DEBUG_MACINTS */
> > > >  /* #define DEBUG_SPURIOUS */
> > > > @@ -207,6 +208,8 @@
> > > >   /* Initialize the IRQ handler lists. Initially each list is empty, */
> > > >
> > > >   for (i = 0; i < NUM_MAC_SOURCES; i++) {
> > > > +  mac_disable_irq(i);
> > > > +  mac_clear_irq(i);
> > > >  	 mac_irq_list[i] = NULL;
> > > >   }
> > > >
> > >
> > > I think this is the wrong place for this. The fact that you need it just
> > > means there is a bug in iop_init(), via_init(), oss_init(), psc_init()
> > > and/or baboon_init(). Fixing the early bug will eliminate suprious
> > > interrupts before mac_init_IRQ() is called.
> >
> > In fact this part was made to boot Linux from EMILE on LCIII.
> >
> > I agree with your arguments, but it's really, really, easier to make
> > work like this...
>
> Which spurious interrupts were occurring? Why is it so difficult to find
> the bug/ommission in the RBV initialisation?
>
> NUM_MAC_SOURCES is 72. This is the slowest way to disable and clear them,
> and doing so is redundant given they have already been deliberately
> disabled and cleared during initialisation (notwithstanding the bug).
>
> While it may be easier to do it your way, it doesn't fix the bug, it just
> hides it without actually preventing spurious interrupts post VIA
> initialisation.

OK, I remove this part and search the real reason...

Cheers,
Laurent

_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Tue, 11 Oct 2005, Laurent Vivier wrote:

> Le mar 11/10/2005 à 03:18, Finn Thain a écrit :
> > On Tue, 11 Oct 2005, Laurent Vivier wrote:
> [...]
> > > Index: linux-mac68k-2.2/arch/m68k/mac/macints.c
> > > ===================================================================
> > > --- linux-mac68k-2.2.orig/arch/m68k/mac/macints.c 2005-09-05
21:03:25.000000000 +0200
> > > +++ linux-mac68k-2.2/arch/m68k/mac/macints.c 2005-10-09 20:00:23.000000000
+0200
> > > @@ -193,6 +193,7 @@
> > >  void mac_nmi_handler(int, void *, struct pt_regs *);
> > >  void mac_debug_handler(int, void *, struct pt_regs *);
> > >  void mac_SCC_handler(int, void *, struct pt_regs *);
> > > +void mac_clear_irq( unsigned int irq );
> > >
> > >  /* #define DEBUG_MACINTS */
> > >  /* #define DEBUG_SPURIOUS */
> > > @@ -207,6 +208,8 @@
> > >   /* Initialize the IRQ handler lists. Initially each list is empty, */
> > >
> > >   for (i = 0; i < NUM_MAC_SOURCES; i++) {
> > > +  mac_disable_irq(i);
> > > +  mac_clear_irq(i);
> > >  	 mac_irq_list[i] = NULL;
> > >   }
> > >
> >
> > I think this is the wrong place for this. The fact that you need it just
> > means there is a bug in iop_init(), via_init(), oss_init(), psc_init()
> > and/or baboon_init(). Fixing the early bug will eliminate suprious
> > interrupts before mac_init_IRQ() is called.
>
> In fact this part was made to boot Linux from EMILE on LCIII.
>
> I agree with your arguments, but it's really, really, easier to make
> work like this...

Which spurious interrupts were occurring? Why is it so difficult to find
the bug/ommission in the RBV initialisation?

NUM_MAC_SOURCES is 72. This is the slowest way to disable and clear them,
and doing so is redundant given they have already been deliberately
disabled and cleared during initialisation (notwithstanding the bug).

While it may be easier to do it your way, it doesn't fix the bug, it just
hides it without actually preventing spurious interrupts post VIA
initialisation.

-f

_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Tue, 11 Oct 2005, Brad Boyer wrote:

> > > some other models, it is actually an interrupt line. According to the
> > > _Guide to the Macintosh Family Hardware_, the IIci hides the IRQ for
> > > the internal video in that location. It's one of the many pitfalls
> > > awaiting all of us. This is something that should depend on via type.
> >
> > Yes, but I think dangerous cases are protected by the nubus_active mask.
> > However, this modification should not be really needed: I put it
> > because, when debugging my problem, I received an IRQ src 7 with IRQ idx
> > 7. I'll make some tests on my 840AV without it.
> > And I think "< 7" is not better than "< 8", if we want to run a really
> > protected behavior, we should use "< 6" (RAM bank).
>
> True, 6 would be the safe choice.

Slot F is IDE, so 7 is the minimum.

> I suppose it is better to just go ahead and use 8, but be sure that all
> the functions that actually affect the register in question are safe.

It isn't really the top mask bit that is the problem, the thing is you
can't clear the top flag bit. So it is a waste of an iteration (in a fast
path).

> In the version of via.c that I have checked out from the m68k CVS,
> via_irq_enable() has a check for the model types to ignore the upper
> bits, but via_irq_disable() does not. We should be more consistent about
> these things. I haven't been a big contributor to the via code, but I
> suppose it's at least partly my fault. All of those (via.c, oss.c,
> psc.c) need a good cleanup. I'd actually like to split out the RBV code
> from via.c as well, but that's a tougher argument to win.

This really is a good idea. Roman's new interrupt code provides an
opportunity. And it was done that way in BSD. If we change to that scheme,
we only have to keep it that way for as long as there are strange problems
caused by the differences between genuine VIA, emulated VIA and RBV (and I
can certainly attest to the presence of such problems).

This means some duplication of logic (different logic to that already
which is already duplicated between VIA/PSC/OSS/Baboon), but the still
duplication should be factored away only _after_ everything works, if and
when it makes sense to do so.

Given our scarcity of resources, it is not feasible for one developer to
test all three hardware variations, so what inevitably happens is that a
fix to the shared code for one model breaks another, and the breakage is
not discovered for a long time. What also happens is that other patches to
VIA code will get refused as too dangerous.

-f

>
>  Brad Boyer
>  flar@...
>
>
_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k

On Wed, Oct 12, 2005 at 01:22:12AM +0200, Laurent Vivier wrote:
> I receive this signal (7th Nubus IRQ).
> I'm able to boot linux on Q840AV because I disable it in EMILE by
> calling the MacOS driver.
> I think it should be cleaner to disable it in the kernel.
> Do you know how ?
> (I don't have the GMFH)

Just so you know, the Guide only covers really old models. It has
information about the old classic models, plus a few categories of
the 020/030 based models. Specifically, it covers the IIfx, the IIci,
and the old MacII style boards (II,IIx,IIcx,SE/30). Anything newer
than that was after the book was written.

The IIci is the only covered model that has this "7th" NuBus IRQ,
which is used for RBV video according to the documentation. The
control is just as if it really was a 7th slot, so there is one
more bit in all of the relevant registers that means something.
Of course, since that's RBV rather than a real VIA, the handling
is somewhat different anyway.

We probably should initialize more of the VIA state during the
boot sequence to try to prevent spurious interrupts due to
hardware that wasn't shutdown by the MacOS. Based on the tree
I have, the value of nubus_active is never initialized, so
we may have some interrupts enabled that we don't expect.

	 Brad Boyer
	 flar@...

_______________________________________________
linux-mac68k mailing list
linux-mac68k@...
http://lists.purplehat.net/listinfo/linux-mac68k