Re: [9fans] file server page faulting

Re: [9fans] file server page faulting

[nigel]

> the hardware is an older pentium (90?) it has 40 mb of ram with integrated
> s3 video and uses a symbios scsi adapter with a 2.5gb hard drive. No
> dump media is attached. The ethernet card is a i82557 mini-nic. I can
> make this happen by usually accessing lots and lotsof data. For example
> if i cat /dev/zero into a file then cat it back out a couple of times
> it usually breaks. I swapped the scsi setup into another system (my
> terminal actually), which does not have an integrated video controller
> and the same type of nic. It had the same problem. The crash is known
> to happen seemingly sporadically also.
>
> is it worth reinstalling onto ide drives? I can backup all my changes
> fairly easily.

It may be. When it breaks, what is the address it happens at?
When you say integrated S3 do you mean in the chip set? Does it used
shared memory?

The possible issues here are

1. the S3 is sharing the memory; there is no allowance for this, and
    when the buffer cache meets the frame buffer horrible things happen

2. which symbios controller? check that the PCI bus specs. match, as
    older symbios controllers don't work on newer PCI busses

If it is the scsi controller, and the bus specs. match, then I get more
interested, having written the symbios driver.

Re: [9fans] file server page faulting

[Andrew]

On Fri, Sep 13, 2002 at 04:14:04PM +0100, nigel@9fs.org wrote:
> > the hardware is an older pentium (90?) it has 40 mb of ram with integrated
> > s3 video and uses a symbios scsi adapter with a 2.5gb hard drive. No
> > dump media is attached. The ethernet card is a i82557 mini-nic. I can
> > make this happen by usually accessing lots and lotsof data. For example
> > if i cat /dev/zero into a file then cat it back out a couple of times
> > it usually breaks. I swapped the scsi setup into another system (my
> > terminal actually), which does not have an integrated video controller
> > and the same type of nic. It had the same problem. The crash is known
> > to happen seemingly sporadically also.
> >
> > is it worth reinstalling onto ide drives? I can backup all my changes
> > fairly easily.
>
> It may be. When it breaks, what is the address it happens at?
> When you say integrated S3 do you mean in the chip set? Does it used
> shared memory?
i will try and get the address.
>
> The possible issues here are
>
> 1. the S3 is sharing the memory; there is no allowance for this, and
>     when the buffer cache meets the frame buffer horrible things happen

the reason i doubt this is that i get the same results on a different
machine that does not have an integrated controller, it has an isa video
card of trident genre so i doubt that the memory is shared between those two.

>
> 2. which symbios controller? check that the PCI bus specs. match, as
>     older symbios controllers don't work on newer PCI busses
it is a fairly new, working, symbios controller I am 99% certain it is
the one specified in the supported hardware section. i will check when
i get home from work. but i believe its listed as scsi0=type=ncr53c8xx
in the plan9.ini file.
>
> If it is the scsi controller, and the bus specs. match, then I get more
> interested, having written the symbios driver.
>
Im planning on putting the scsi setup in one of my linux machines and
seeing what happens if i cat the whole drive out. That way if theres
any blocks that its having trouble with i can find out.

thanks for your help.

Re: [9fans] file server page faulting

[Andrew]

> 1. the S3 is sharing the memory; there is no allowance for this, and
>     when the buffer cache meets the frame buffer horrible things happen
>
> 2. which symbios controller? check that the PCI bus specs. match, as
>     older symbios controllers don't work on newer PCI busses

it is a symbios 53c810ae is that indicative of anything?

Re: [9fans] file server page faulting

[Douglas A. Gwyn]

Andrew wrote:
> >     older symbios controllers don't work on newer PCI busses
> it is a symbios 53c810ae is that indicative of anything?

I don't think it's a matter of age of the controller as much as
to whether it was built for a restrictive subset of PCI, such as
INTA-only.  Some of the cheaper 810-based controllers were indeed
like this, but others are fine.  I'm using an old ASUS SC200 and a
cheaper, newer generic 810-based PCI controller on my Pentium IIIs
under several different OSes.

Re: [9fans] file server page faulting

[Jack Johnson]

Douglas A. Gwyn wrote:
> like this, but others are fine.  I'm using an old ASUS SC200 and a
> cheaper, newer generic 810-based PCI controller on my Pentium IIIs
> under several different OSes.

Could you tell us which card that is?

I'm always on the lookout for cheaper.  ;)

-Jack

Re: [9fans] file server page faulting

[Andrew]

On Mon, Sep 16, 2002 at 08:13:51AM -0700, Jack Johnson wrote:
> Douglas A. Gwyn wrote:
> >like this, but others are fine.  I'm using an old ASUS SC200 and a
> >cheaper, newer generic 810-based PCI controller on my Pentium IIIs
> >under several different OSes.
>
> Could you tell us which card that is?
symbios 53c810ae

it doesnt matter though since the problem was actually a bad nic (i hope
i hope i hope!)and I believe i was getting the same problems with ide
disks (which is what im using in my 'new' file server).

> I'm always on the lookout for cheaper.  ;)
>
cheaper gave me a motherboard with onboard sound and ethernet neither
of which i can use because certain sequences of DMA accesses will lock
the the motherboard.

the only kind of cheap hardware i get now is of the older and free variety.

[9fans] Writing (new) drivers

[Jack Johnson]

I've never written a device driver and my C skills are poor, but device
drivers under Plan 9 seem straightforward and I'm considering taking the
plunge.  I'd love to have a driver for my 3Ware IDE RAID controller:

	http://www.3ware.com/products/pdf/Escalade7500DS6-7.qk.pdf

(By the way, thanks for the newer ghostscript with ps2pdf and pdf2ps!)

The cards are supported under Linux and FreeBSD (and NetBSD too, I
believe), so I think I'll have good references to use to figure out
where to start.  Plus, it behaves as if it were just another SCSI
controller, which should simplify things even further.

Needless to say, I'm a little nervous mucking around with a drive
controller.  Is there anything I should watch out for, other than not
testing it on important data?

-Jack

Re: [9fans] Writing (new) drivers

[Russ Cox]

> Have you tried that under VMWare?  Not that it would help with driver
> development, but I would think for other kernel work it might be handy.

I've been meaning to, but haven't.  I do run Plan 9 under
VMware, but I need to get some more memory for my laptop
in order to run more VMs.

Russ

Re: [9fans] Writing (new) drivers

[Jack Johnson]

Russ Cox wrote:
> You'll be much happier if you can set up two Plan 9 systems,
> one as a crash box and one to do your development on.

Thanks!

Have you tried that under VMWare?  Not that it would help with driver
development, but I would think for other kernel work it might be handy.

-Jack

Re: [9fans] Writing (new) drivers

[Russ Cox]

You'll be much happier if you can set up two Plan 9 systems,
one as a crash box and one to do your development on.
Connect the two with a serial line and ethernet, and
then you can load kernels over the ether (set up tftpd
and dhcpd on the real machine), boot from your development
machine (man kfscmd, look for listen), type at the crash box
via the serial line (set up consolefs), and run the
debugger over the console (man rdbfs).

It sounds like a bit of effort, and it is, but once you
try it you'll never want to use a less helpful system.
The really nice thing about what I've described is that
the crash box has no real persistent state, so you don't
have to worry about losing your file system, and being
able to keep your editing context while the other machine
reboots is really great.

I still do one-machine kernel development more often
than I'd like, and it's just no fun.

Russ