linux-apus-devel

Re: 53c770 driver

[Geert U. <ge...@li...>]

On Fri, 8 Dec 2000 fh...@at... wrote:
> There is some very basic problem with making the 53c770 chip work with
> Linux or PowerPC.  The problem has to be PPC or APUS related because those
> same 53c8xx chips are used in PCI cards that work on a variety of other
> architectures and Linuxes.  I  have been trying  to figure out what the

FYI, I have a Sym53c875 PCI card in my PPC CHRP box, which works fine with
Linux.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[Fwd: MOL without OF]

[Michel <dae...@st...>]

Good news!


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

Re: 2.2 CVS kernel on M68K?

[Michel <dae...@st...>]

fh...@at... wrote:
> 
> If I install a M68K cross compiler and compile the APUS 2.2 CVS code for
> M68K Linux, will the kernel work?

As our 2.2 code is 100% based on m68k, it should.


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

2.2 CVS kernel on M68K?

[<fh...@at...>]

If I install a M68K cross compiler and compile the APUS 2.2 CVS code for
M68K Linux, will the kernel work?

Fred

Re: 53c770 driver

[<fh...@at...>]

In <200...@su...>, on 12/07/00 
   at 03:42 PM, gri...@ps... (Arno Griffioen) said:

>> > This sort of thing kills the init when CONFIG_PCI is defined:
>> > 
>> > #ifdef CONFIG_PCI
>> > static int ncr53c8xx_pci_init(Scsi_Host_Template *tpnt,
>> >              uchar bus, uchar device_fn, ncr_device *device);
>> > #else
>> > static int ncr53c770_init(Scsi_Host_Template *tpnt, unsigned long base,
>> >                           unsigned int irq, ncr_device *device);
>> > #endif
>> 
>> This doesn't make sense to me. I guess the 53c8xx code could just be removed
>> from the 53c770 code?

>Or a more elegant solution in which case there wouldn't need to be a
>separate 53c770 driver, but included in an existing 53c8xx driver.

This is the best solution IMHO.  Basically all the current LSI chips have
about the same scripts processor and share a lot of the same  features.  
Of course the very new chips began to diverge.
All of the 53c8xx drivers I have looked at have the same basic data
structures.  This is for the 53c810 chip on up.  The biggest stumbling
point I can see is that the 8xx series of chips is very PCI so the
routines that heavily depend on PCI has to have the correct logic figured
out to accommodate both.

>As this is basically development code I don't really care. Just took me 
>a while to figure out why it didn't seem tohave any effect when  I
>compiled in the driver.. 

I am playing with different driver code at the moment, the sym53c8xx.c
code.  My reason for switching is that it shares the new style data
structures and should be easier to merge into the newest versions, if that
ever becomes possible.  I have gotten the newer code to get to the cache
test, where it fails to execute the SCSI scripts code, though everything
looks "right".  For example, the correct addresses and so forth appear.

There is some very basic problem with making the 53c770 chip work with
Linux or PowerPC.  The problem has to be PPC or APUS related because those
same 53c8xx chips are used in PCI cards that work on a variety of other
architectures and Linuxes.  I  have been trying  to figure out what the
differences could be.  BTW the newer drivers  have a sort of generic mb()
support as well.  I really don't want to start  looking at assembly code,
but ultimately that may be what has to be done.   i.e. find the driver
sections that misbehave in the kernel assembler code and see if the code
looks "right."  (Any tips on how one goes about doing that would be
appreciated.)  Additionally, Richard Hirst has gotten  the 770 chip to
work on a HP system.  He had to make a few modifications  to the actual
SCSI routines in the code to take into account small  differences between
the 8xx and 770 SCSI processors.

There is another problem as well.  All the PCI based cards have ROMs or
NVRAM onboard that store the initial setting of the SCSI chip.  The
correct initial settings of the 53c770 chip has to be found.

Sorry in advance for rambling on and probably repeating myself from
previous posts.

Fred

Re: CVS 2.2 mol-branch

[Michel <da...@re...>]

Alan Buxey wrote:

> has anyone had any compile success with the recent 2.2 mol-branch (after
> Romans' extra addition last week)?
> 
> I ask simply because I had to edit head.S and place a \ just before a
> hook_num in a MOL Macro to get it to compile...

Yep, seen that, too.

> and also remove any APUS_PROGRESS calls within head.S too!

Just removing the first one made it build for me. I have committed the fix.

> it then compiled...however when trying to use it as a kernel, i just got a
> back screen followed by reset into AmigaOS.

Now you've finally got APUS_PROGRESS to watch ;)


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

CVS Update: 2.2

[Michel D. <mda...@us...>]

CVSROOT:	/cvsroot/linux-apus
Module name:	2.2
Repository:	2.2/arch/ppc/kernel/
Changes by:	mda...@sl....	00/12/07 18:31:08

Modified files:
	2.2/arch/ppc/kernel/: Tag: mol-branch head.S 

Log message:
	build fix

MOL without OF

[Michel <da...@re...>]

Does this work theoretically? During all the time we have tried to get MOL
working on APUS we never thought about it, until mol.o for 2.4 complained
about find_path_device being unresolved.


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

Re: 53c770 driver

[Alan B. <al...@ms...>]

hi,

> > #ifdef CONFIG_PCI
> > static int ncr53c8xx_pci_init(Scsi_Host_Template *tpnt,
> >              uchar bus, uchar device_fn, ncr_device *device);
> > #else
> > static int ncr53c770_init(Scsi_Host_Template *tpnt, unsigned long base,
> >                           unsigned int irq, ncr_device *device);
> > #endif
> 
> This doesn't make sense to me. I guess the 53c8xx code could just be removed
> from the 53c770 code?

yes, you dont need the if/else at all, just the static int ncr53c_blahblah
line
 
alan

Re: virgefb.c PATCH

[Alan B. <al...@ms...>]

hi,

> > BTW, ide-doubler fails to detect the third and fourth IDE drives.
> > It tries, but gets garbage instead of the drive names.

peculiar...i get all 4 IDE devices working fine. what interface do you
have? what does the 'report this!' value say for the driver interface?
 
alan

Re: 53c770 driver

[<gri...@ps...>]

> > This sort of thing kills the init when CONFIG_PCI is defined:
> > 
> > #ifdef CONFIG_PCI
> > static int ncr53c8xx_pci_init(Scsi_Host_Template *tpnt,
> >              uchar bus, uchar device_fn, ncr_device *device);
> > #else
> > static int ncr53c770_init(Scsi_Host_Template *tpnt, unsigned long base,
> >                           unsigned int irq, ncr_device *device);
> > #endif
> 
> This doesn't make sense to me. I guess the 53c8xx code could just be removed
> from the 53c770 code?

Or a more elegant solution in which case there wouldn't need to be a
separate 53c770 driver, but included in an existing 53c8xx driver.

As this is basically development code I don't really care. Just took me 
a while to figure out why it didn't seem tohave any effect when 
I compiled in the driver.. 

							Bye, Arno.

-- 
PSINetworks Europe         Phone: +31-23-5699846 | One disk to rule them all,
Siriusdreef 34               FAX: +31-20-8640234 | One disk to bind them,
2132WT Hoofddorp+--------------------------------+ One disk to hold the files
The Netherlands |   *  Musical Interlude  *      | And in the darkness grind 'em
----------------+--------------------------------+------------------------------

 We say Retribution, We say Vengeance is bliss, We say Revolution,
 With a Cast-Iron fist!                  (Megadeth, 'The Disintegrators')

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

Re: 53c770 driver

[Michel <da...@re...>]

Arno Griffioen wrote:
> 
> > > Undefining the 'PCI for Permedia2' option causes 'CONFIG_PCI' to go away
> > > and may help in getting the 53c770 to do a little more..
> >
> > I thought the 53c770 wasn't PCI so I don't understand how that can
> > interfere.
> 
> Fred's driver is based on the 53c8xx, which is PCI based and that code
> is still in there.
> 
> This sort of thing kills the init when CONFIG_PCI is defined:
> 
> #ifdef CONFIG_PCI
> static int ncr53c8xx_pci_init(Scsi_Host_Template *tpnt,
>              uchar bus, uchar device_fn, ncr_device *device);
> #else
> static int ncr53c770_init(Scsi_Host_Template *tpnt, unsigned long base,
>                           unsigned int irq, ncr_device *device);
> #endif

This doesn't make sense to me. I guess the 53c8xx code could just be removed
from the 53c770 code?


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

Re: virgefb.c PATCH

[Michel <da...@re...>]

Roberto Ragusa wrote:

> I don't know why but precompiled kernels 2000814 and 20000927
> don't start on my CyberstormPPC 604e@150; the screen goes
> white and nothing happens. According to bootmesg the kernel
> is launched.
> I'm running APUS since the first days, and I'm not doing silly
> errors: last boothack, correct options, etc...
> No problem with 20000518.

Anything interesting in the dmesg output?

> A couple of weeks ago I downloaded the 2.2 CVS tree to
> compile a kernel myself.
> Well, my own-compiled kernel does start and run. Good.

Any differences between your .config and the one of the precompiled kernels?

> But I found that the Virge (CV64/3D) console acceleration was
> corrupted (but X didn't suffer any problems): something was wrong
> with the blitting.
> 
> I compared the source with older versions and it was exactly
> identical!
> So I thought there was a compiler problem, and, yes, I was right.
> I'm using gcc 2.95.2 (from LinuxPPC 2000), which reorders memory
> access, and it's not a good thing if you reorder register writes.
> 
> I added a "-fno-scrict-aliasing" to CFLAGS in the main Makefile
> and patched the virgefb.c driver to be more careful about register
> access. Maybe I added too many mb(), but I really don't think they
> could cause mesaurable speed degradation, so I chose to be on the
> safe side.
> Here's the patch:

[patch omitted]

Can you please submit it to our Patch Manager at SourceForge?


> Now, if only someone could add X acceleration and mode switching...

For X acceleration, you'd have to modify the X 4.x s3virge driver. Several
people have had a look at it with no success so far :(


> BTW, ide-doubler fails to detect the third and fourth IDE drives.
> It tries, but gets garbage instead of the drive names.

Please also submit this to our Bug Tracker.


Stuff which is in the SourceForge database won't get forgotten. And if you are
logged in when submitting stuff, you'll always be notified on updates.


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

Re: 53c770 driver

[<gri...@ps...>]

> > Undefining the 'PCI for Permedia2' option causes 'CONFIG_PCI' to go away and
> > may help in getting the 53c770 to do a little more..
> 
> I thought the 53c770 wasn't PCI so I don't understand how that can interfere.

Fred's driver is based on the 53c8xx, which is PCI based and that code 
is still in there.

This sort of thing kills the init when CONFIG_PCI is defined:

#ifdef CONFIG_PCI
static int ncr53c8xx_pci_init(Scsi_Host_Template *tpnt,
             uchar bus, uchar device_fn, ncr_device *device);
#else
static int ncr53c770_init(Scsi_Host_Template *tpnt, unsigned long base,
                          unsigned int irq, ncr_device *device);
#endif


								Bye, Arno.

-- 
PSINetworks Europe         Phone: +31-23-5699846 | One disk to rule them all,
Siriusdreef 34               FAX: +31-20-8640234 | One disk to bind them,
2132WT Hoofddorp+--------------------------------+ One disk to hold the files
The Netherlands |   *  Musical Interlude  *      | And in the darkness grind 'em
----------------+--------------------------------+------------------------------

 We say Retribution, We say Vengeance is bliss, We say Revolution,
 With a Cast-Iron fist!                  (Megadeth, 'The Disintegrators')

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

Re: 53c770 driver

[Alan B. <al...@ms...>]

hi,

> > Undefining the 'PCI for Permedia2' option causes 'CONFIG_PCI' to go away and
> > may help in getting the 53c770 to do a little more..
> 
> I thought the 53c770 wasn't PCI so I don't understand how that can interfere.

is it located on the 'PCI bus' of the PowerUP cards though? Perhaps it was
easier/cheaper to implement it as such?

alan

Re: 53c770 driver

[Michel <da...@re...>]

Arno Griffioen wrote:

> Undefining the 'PCI for Permedia2' option causes 'CONFIG_PCI' to go away and
> may help in getting the 53c770 to do a little more..

I thought the 53c770 wasn't PCI so I don't understand how that can interfere.


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

Re: M68K Linux?

[<gri...@ps...>]

> I know this is not a good list for this quesion but
> where is the Amiga M68K Linux boothacks and whatever
> located?
> 
> I have not used M68K Linux for awhile, but I want to see
> if some of the driver code I have be playing with works
> "better" on it.

Check out:

http://www.linux-m68k.org/ftp.html

								Bye, Arno.

-- 
PSINetworks Europe         Phone: +31-23-5699846 | One disk to rule them all,
Siriusdreef 34               FAX: +31-20-8640234 | One disk to bind them,
2132WT Hoofddorp+--------------------------------+ One disk to hold the files
The Netherlands |   *  Musical Interlude  *      | And in the darkness grind 'em
----------------+--------------------------------+------------------------------

 We say Retribution, We say Vengeance is bliss, We say Revolution,
 With a Cast-Iron fist!                  (Megadeth, 'The Disintegrators')

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

Re: M68K Linux?

[Michel <da...@re...>]

fh...@at... wrote:
> 
> I know this is not a good list for this quesion but
> where is the Amiga M68K Linux boothacks and whatever
> located?

ftp://sunsite.auc.dk/projects/680x0


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

M68K Linux?

[<fh...@at...>]

I know this is not a good list for this quesion but
where is the Amiga M68K Linux boothacks and whatever
located?

I have not used M68K Linux for awhile, but I want to see
if some of the driver code I have be playing with works
"better" on it.

Fred

virgefb.c PATCH

[Roberto R. <rob...@te...>]

Hi,

I don't know why but precompiled kernels 2000814 and 20000927
don't start on my CyberstormPPC 604e@150; the screen goes
white and nothing happens. According to bootmesg the kernel
is launched.
I'm running APUS since the first days, and I'm not doing silly
errors: last boothack, correct options, etc...
No problem with 20000518.

A couple of weeks ago I downloaded the 2.2 CVS tree to
compile a kernel myself.
Well, my own-compiled kernel does start and run. Good.

But I found that the Virge (CV64/3D) console acceleration was
corrupted (but X didn't suffer any problems): something was wrong
with the blitting.

I compared the source with older versions and it was exactly
identical!
So I thought there was a compiler problem, and, yes, I was right.
I'm using gcc 2.95.2 (from LinuxPPC 2000), which reorders memory
access, and it's not a good thing if you reorder register writes.

I added a "-fno-scrict-aliasing" to CFLAGS in the main Makefile
and patched the virgefb.c driver to be more careful about register
access. Maybe I added too many mb(), but I really don't think they
could cause mesaurable speed degradation, so I chose to be on the
safe side.
Here's the patch:

--- virgefb.c_orig	Thu May 25 21:08:31 2000
+++ virgefb.c	Sun Nov 26 16:56:57 2000
@@ -51,18 +51,18 @@
 #if 1
 #define vgawb_3d(reg,dat) \
 	if (cv3d_on_zorro2) { \
-	*((unsigned char volatile *)((Cyber_vcode_switch_base) + 0x04)) = \
-	(0x01 & 0xffff); asm volatile ("nop"); \
+	mb(); *((unsigned char volatile *)((Cyber_vcode_switch_base) + 0x04)) = \
+	(0x01 & 0xffff); asm volatile ("nop"); mb(); \
 	} \
-	(*((unsigned char *)(CyberVGARegs + (reg ^ 3))) = dat); \
+	mb(); (*((unsigned char *)(CyberVGARegs + (reg ^ 3))) = dat); mb(); \
 	if (cv3d_on_zorro2) { \
-	*((unsigned char volatile *)((Cyber_vcode_switch_base) + 0x04)) = \
-	(0x02 & 0xffff); asm volatile ("nop"); \
+	mb(); *((unsigned char volatile *)((Cyber_vcode_switch_base) + 0x04)) = \
+	(0x02 & 0xffff); asm volatile ("nop"); mb(); \
 	}
 #define vgaww_3d(reg,dat) \
-                (*((unsigned word *)(CyberVGARegs + (reg ^ 2))) = swab16(dat))
+                mb(); (*((unsigned word *)(CyberVGARegs + (reg ^ 2))) = swab16(dat)); mb();
 #define vgawl_3d(reg,dat) \
-                (*((unsigned long *)(CyberVGARegs + reg)) = swab32(dat))
+                mb(); (*((unsigned long *)(CyberVGARegs + reg)) = swab32(dat)); mb();
 #else
      /*
       * Dunno why this doesn't work at the moment - we'll have to look at
@@ -80,18 +80,18 @@
       * We asume P5 mapped the big-endian version of these registers.
       */
 #define wb_3d(reg,dat) \
-                (*((unsigned char volatile *)(CyberRegs + reg)) = dat)
+                mb(); (*((unsigned char volatile *)(CyberRegs + reg)) = dat); mb();
 #define ww_3d(reg,dat) \
-                (*((unsigned word volatile *)(CyberRegs + reg)) = dat)
+                mb(); (*((unsigned word volatile *)(CyberRegs + reg)) = dat); mb();
 #define wl_3d(reg,dat) \
-                (*((unsigned long volatile *)(CyberRegs + reg)) = dat)
+                mb(); (*((unsigned long volatile *)(CyberRegs + reg)) = dat); mb();
 #define rl_3d(reg) \
-                (*((unsigned long volatile *)(CyberRegs + reg)))
+                (*((unsigned long volatile *)(CyberRegs + reg))); mb();
 
 #define Select_Zorro2_FrameBuffer(flag) \
 	do { \
-		*((unsigned char volatile *)((Cyber_vcode_switch_base) + 0x08)) = \
-		((flag * 0x40) & 0xffff); asm volatile ("nop"); \
+		mb(); *((unsigned char volatile *)((Cyber_vcode_switch_base) + 0x08)) = \
+		((flag * 0x40) & 0xffff); asm volatile ("nop"); mb(); \
 	} while (0)
 /*
  *	may be needed when we initialize the board?


Now, if only someone could add X acceleration and mode switching...

BTW, ide-doubler fails to detect the third and fourth IDE drives.
It tries, but gets garbage instead of the drive names.

-- 

 |||||||. |||||||.  *Roberto Ragusa* <rob...@te...>
 ||....|| ||....||    - electronic engineering student
 ||||||.. ||||||..    - Amiga user
 ||..||.. ||..||..    - satellite TV enthusiast
 ||....|| ||....||            (PGP public key available)

Re: 53c770 driver

[<gri...@ps...>]

OK.. 

Undefining the 'PCI for Permedia2' option causes 'CONFIG_PCI' to go away and
may help in getting the 53c770 to do a little more.. 

At least now it doesn't link anymore :-(

drivers/scsi/scsidrv.o(.text.init+0x2584): undefined reference to `zorro_find'
drivers/scsi/scsidrv.o(.text.init+0x2594): undefined reference to `zorro_get_board'
drivers/scsi/scsidrv.o(.text.init+0x25c4): undefined reference to `zorro_config_board'

I already got a bit worried when I saw this (among others) when it was 
compiling 53c770.c:

53c770.c: In function `ncr53c8xx_detect':
53c770.c:10101: warning: implicit declaration of function `zorro_find'
53c770.c:10102: warning: implicit declaration of function `zorro_get_board'
53c770.c:10102: warning: assignment makes pointer from integer without a cast
53c770.c:10108: warning: implicit declaration of function `zorro_config_board'

Weren't those calls obsoleted and replaced a while back? At least 
zorro_find() should be zorro_find_device(bla bla bla).

OK.. I'll try to hack it into a compilable format tonight.

								Bye, Arno.

-- 
PSINetworks Europe         Phone: +31-23-5699846 | One disk to rule them all,
Siriusdreef 34               FAX: +31-20-8640234 | One disk to bind them,
2132WT Hoofddorp+--------------------------------+ One disk to hold the files
The Netherlands |   *  Musical Interlude  *      | And in the darkness grind 'em
----------------+--------------------------------+------------------------------

 We say Retribution, We say Vengeance is bliss, We say Revolution,
 With a Cast-Iron fist!                  (Megadeth, 'The Disintegrators')

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

Re: A2232 driver question

[<gri...@ps...>]

> In that driver, I access the 64kB of the ZorroII board directly and I
> wonder if this
> is clean; that means if it at least does not only work under m68k but
> also under
> APUS/PPC.

Most of the drivers for the m68k will 'just work' on APUS as well. Nothing
special required. Only when you start doing memory mapping/protection
tricks (usually DMA engines and such) are there some differences.

The only thing that sometimes has to be added are some [rw]mb() calls
because the PPC chip will re-order reads and writes to optimise it's
I/O. This can cause problems when talking to peripheral chips, 
because they may need a certain specific order in which things are
written to their registers. (eg. address register first, then data)

Adding mb() around these specific I/O routines makes sure that the
PPC doesn't start to re-order the writes. Look at 'drivers/scsi/a3000.c'
for an obvious example.

							Bye, Arno.

-- 
PSINetworks Europe         Phone: +31-23-5699846 | One disk to rule them all,
Siriusdreef 34               FAX: +31-20-8640234 | One disk to bind them,
2132WT Hoofddorp+--------------------------------+ One disk to hold the files
The Netherlands |   *  Musical Interlude  *      | And in the darkness grind 'em
----------------+--------------------------------+------------------------------

 We say Retribution, We say Vengeance is bliss, We say Revolution,
 With a Cast-Iron fist!                  (Megadeth, 'The Disintegrators')

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

A2232 driver question

[AmigaLinux A. D. P. <A2...@gm...>]

Hello out there,

I just finished a driver for the A2232 multiserial board for the Amiga
computers.
You can find it at http://www.inf.fu-berlin.de/~ehaase .

In that driver, I access the 64kB of the ZorroII board directly and I
wonder if this
is clean; that means if it at least does not only work under m68k but
also under
APUS/PPC.

Or do I have to use something like "readb" stuff?

Greetings,
Enver

(please reply via mail also)

Re: keymap

[Ken T. <ke...@we...>]

On Tue, 5 Dec 2000, Geert Uytterhoeven wrote:

> On Mon, 4 Dec 2000, Ken Tyler wrote:

> Why put it in drivers/char/? Amikeyb has it's own keymap tables in amikeyb.c,
> which are copied over the tables in defkeymap.c anyway.

Way way back Jesper Skov's pre-built kernel wouldn't boot on my system
because of the A4091 hanging up, I cross-compiled a kernel on PC and ended
up with a PC keymap.

Ken.

Re: 53c770 driver

[<gri...@ps...>]

> I'll try a compiled-in version soon.

Tried it, but I see nothing.

Do I need a specific boothack version or boot-flags?

I'll try a complete rebuild just to be sure..

This is the dmesg I get with a compiled-in 53c770 driver (notice it's 
absence ;-):

Total memory = 127MB; using 512kB for hash table (at c0200000)
Linux version 2.4.0-test11 (ar...@ha...) (gcc version 2.95.2 
20000220 (Debian GNU/Linux)) #7 Mon Dec 4 21:04:40 CET 2000
Amiga hardware found: [A3000] VIDEO BLITTER AMBER_FF AUDIO FLOPPY A3000_SCSI KEY
BOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA DENISE_HR AGNUS_HR_PAL MAGI
C_REKICK ZORRO3 
On node 0 totalpages: 32640
zone(0): 32640 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: video=pm2fb: wd33c93=disconnect:2 root=/dev/sda1 60nsram si
ngle
amiga_enable_irq: Trying to enable auto-vector IRQ 1
amiga_enable_irq: Trying to enable auto-vector IRQ 3
amiga_enable_irq: Trying to enable auto-vector IRQ 4
amiga_enable_irq: Trying to enable auto-vector IRQ 5
amiga_enable_irq: Trying to enable auto-vector IRQ 7
amiga_enable_irq: Trying to enable auto-vector IRQ 2
amiga_enable_irq: Trying to enable auto-vector IRQ 6
APUS: BATs=1, BUS=67MHz, RAM=60ns, PCI bridge=1
time_init: decrementer frequency = 16.353125 MHz
Console: colour dummy device 80x25
Calibrating delay loop... 457.11 BogoMIPS
Memory: 126056k available (992k kernel code, 452k data, 220k init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Zorro: Probing AutoConfig expansion devices: 4 devices
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd v1.8
Console: switching to colour frame buffer device 80x30
fb0: CVisionPPC/BVisionPPC (Permedia2), using 8192K of video memory.
fb1: Amiga ECS frame buffer device, using 640K of video memory
pty: 256 Unix98 ptys configured
Amiga mouse installed.
SCSI subsystem driver Revision: 1.00
wd33c93-0: chip=WD33c93A/9 no_sync=0xff no_dma=0 debug_flags=0x00
           setup_args==disconnect:2,,,,,,,,,
           Version 1.25 - 09/Jul/1997, Compiled Dec  4 2000 at 21:10:15
scsi0 : Amiga 3000 built-in SCSI
 sending SDTR 0103016400sync_xfer=40  Vendor: FUJITSU   Model: M2909S-512       
 Rev: 0127
  Type:   Direct-Access                      ANSI SCSI revision: 02
 sending SDTR 0103015e00sync_xfer=30  Vendor: IBM       Model: DORS-32160       
 Rev: WA0A
  Type:   Direct-Access                      ANSI SCSI revision: 02
 sending SDTR -REJ-  Vendor: WANGTEK   Model: 5150ES SCSI FA03  Rev: 08  
  Type:   Sequential-Access                  ANSI SCSI revision: 01
 sending SDTR -REJ-  Vendor: YAMAHA    Model: CRW4260           Rev: 1.0h
  Type:   CD-ROM                             ANSI SCSI revision: 02
 sending SDTR   Vendor: SCANNER   Model:                   Rev: V100
  Type:   Scanner                            ANSI SCSI revision: 01 CCS
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
Detected scsi disk sdb at scsi0, channel 0, id 1, lun 0
SCSI device sda: 6054834 512-byte hdwr sectors (3100 MB)
Partition check:
 /dev/scsi/host0/bus0/target0/lun0: RDSK p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12
SCSI device sdb: 4226725 512-byte hdwr sectors (2164 MB)
 /dev/scsi/host0/bus0/target1/lun0: RDSK p1 p2
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
devfs: v0.102 (20000622) Richard Gooch (rg...@at...)
devfs: boot_options: 0x2
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 220k init
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Adding Swap: 127908k swap-space (priority -1)

								Bye, Arno.

-- 
PSINetworks Europe         Phone: +31-23-5699846 | One disk to rule them all,
Siriusdreef 34               FAX: +31-20-8640234 | One disk to bind them,
2132WT Hoofddorp+--------------------------------+ One disk to hold the files
The Netherlands |   *  Musical Interlude  *      | And in the darkness grind 'em
----------------+--------------------------------+------------------------------

 We say Retribution, We say Vengeance is bliss, We say Revolution,
 With a Cast-Iron fist!                  (Megadeth, 'The Disintegrators')

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