From marius@ractech.co.za  Mon Feb  3 09:47:01 2003
From: marius@ractech.co.za (Marius van Wyk)
Date: 03 Feb 2003 11:47:01 +0200
Subject: [pxc] pxc driver with RH8
Message-ID: <1044265621.23524.129.camel@satyr.ractech.co.za>

I'm getting quite a few kernel warning messages when I load the pc
drivers... should I worry?

Also, I have noticed that I need to give a larger mem= line in
grub.conf/lilo.conf  - why is that?

(I also still get lots of Unexpected IRQ messages while the driver is
running...)

This all with 0.81 version on RedHat 8 standard.

I'm going to try the cvs-snapshot next...

Regards,
Marius.

-- 
Marius van Wyk <marius@ractech.co.za>
RACTech


From marius@ractech.co.za  Mon Feb 17 10:01:01 2003
From: marius@ractech.co.za (Marius van Wyk)
Date: 17 Feb 2003 12:01:01 +0200
Subject: [pxc] Kernel parameter "mem=xxM" problems...
Message-ID: <1045476061.13894.46.camel@satyr.ractech.co.za>

Someone reported to me that the kernel parameter they added does not
seem to work.

The machine has 256Meg of RAM, and we added a "mem=240M" line.

The machine failed to boot! (I'm using RedHat8 standard with grub
bootloader)

This problem seems only to occur on his hardware, and I have not been
able to reproduce it.

The error with wich it fails to boot is similar to the error when you
add a mem= line that is more than the actual memory...

We eventually for it to run specifying "mem=60M"... as if the OS/boot
loader thinks that the machine only has 64M of physical memory.

Also another point is that I have noticed that on RedHat8 my usual 4
megs less (specifying mem=60M for a 64Meg system) is too little, and I
have to specify 5-10 megs for me to use the pxc.o to actually be able to
do an "mmap"

PS: Is there no better way to configure the mem=kernel thing? I want to
create a bootable installation CD that will automate an install, and
currently people have to type "install mem=60M" on the installation
bootup screen and I then later in the installation look at
/mnt/sysimage/proc/cmdline to get the parameters and then to write them
to the /etc/lilo.conf or /etc/grub.conf

Anyone else have similar experience or thoughts?

Regards,
Marius.



-- 
Marius van Wyk <marius@ractech.co.za>
RACTech


From rubini@gnu.org  Tue Feb 18 06:39:50 2003
From: rubini@gnu.org (Alessandro Rubini)
Date: Tue, 18 Feb 2003 07:39:50 +0100
Subject: [pxc] Kernel parameter "mem=xxM" problems...
In-Reply-To: <1045476061.13894.46.camel@satyr.ractech.co.za>
References: <1045476061.13894.46.camel@satyr.ractech.co.za>
Message-ID: <20030218073950.A11767@morgana.systemy.it>

> Someone reported to me that the kernel parameter they added does not
> seem to work.
> 
> The machine has 256Meg of RAM, and we added a "mem=240M" line.
> 
> The machine failed to boot! (I'm using RedHat8 standard with grub
> bootloader)

Interesting. I'm using grub on most of my computers too, but I have
never had any problem.
 
> This problem seems only to occur on his hardware, and I have not been
> able to reproduce it.

I have no idea about what is happening there. Moreso because grub has
the horrible habit to pass a "mem=" parameter itself, if not
specifically disabled (I don't know if redhat disables it, although
there are very good reasons to do that -- but the grub maintainer
won't make that the default because he claims linux is bugged).

> The error with wich it fails to boot is similar to the error when you
> add a mem= line that is more than the actual memory...

It would be interesting to see what /proc/iomem says when the
system boots normally. And also /proc/cmdline, to know if grub is
adding the mem= itself or not.

Hmm... is that user having an ISA hole configured in his own system?

> We eventually for it to run specifying "mem=60M"... as if the OS/boot
> loader thinks that the machine only has 64M of physical memory.

Ok. Then no ISA hole. 
 
> Also another point is that I have noticed that on RedHat8 my usual 4
> megs less (specifying mem=60M for a 64Meg system) is too little, and I
> have to specify 5-10 megs for me to use the pxc.o to actually be able to
> do an "mmap"

Again, I'd like to see what /proc/iomem is saying. Redhat kernels used to
(and probably still use to) have a different management of the
mem= parameter. So if you say mem=60M it's taken as 60 useable megs,
thus extending to 60M+384k . That's why seeing /proc/iomem would
be interesting.
 
> PS: Is there no better way to configure the mem=kernel thing?

With a vanilla kernel, not. You might use the bigphysarea patch, and
fix pxc to use that mechanism. With bigphysarea you preallocate a
buffer in low memory, leaving top-of-memory management to the standard
mechanisms.

Or pxc can be fixed to have a smarter management of its DMA buffer, so
vmalloc can be used. It's a boring task, though, and it's not in my
todo list, unless someone really needs it.

> I want to create a bootable installation CD that will automate an
> install, and currently people have to type "install mem=60M" on the
> installation bootup screen and I then later in the installation look
> at /mnt/sysimage/proc/cmdline to get the parameters and then to
> write them to the /etc/lilo.conf or /etc/grub.conf

Yes, not completely straightforward. Well, if you install your kernel
you might use bigphysarea (but pxc must be modified to use that
mechanism).

Last time I heard about that patch, it was at
http://frmb.home.cern.ch/frmb/download/bigphysarea-2.4.18.patch

/alessandro
-- 
Alessandro Rubini, free software developer.
Device drivers, embedded systems, courses.
http://ar.linux.it/

From luislloret@visarcontrol.es  Tue Feb 18 14:42:18 2003
From: luislloret@visarcontrol.es (Luis Lloret)
Date: Tue, 18 Feb 2003 15:42:18 +0100
Subject: [pxc] Problems with unexpected IRQ with three frame grabbers
Message-ID: <004e01c2d75b$f90cda00$2217000a@VISAR>

Hi all.

    We are having some trouble when trying to handle three frame grabbers
simultaneously. When we execute three instances of pxc_live, one with
/dev/pxc0Hpgm, other with /dev/pxc1Hpgm and other with /dev/pxc2Hpgm, we get
this kind of errors (through dmesg):

pxc200: Unexpected IRQ 0xXXXXXXX, IP 0xXXXXXX X times
pxc200:     irq bit 02: hsync
pxc200:     irq bit 03: overflow
pxc200:     irq bit 12: fifo overrun, drop data

and

pxc200: lockup detected
pxc200: serious error (X times), restart
pxc200:     irq bit 03: overflow
pxc200:     irq bit 11: RISC irq
pxc200:     irq bit 18: opcode error


When we are using only two of the instances of pxc_live, no errors appear,
but as soon as we start the other... they do. We also see that some of the
lines of the image appear in black, as though they hadn´t been captured.
The same happens with our applications, when we use three or more grabbers.

If we execute in field mode instead of frame mode, then no errors appear.

I suspected of IRQ conflicts, but each PXC200AL has its own interrupt (5, 7,
10). Maybe we are beyond the PCI bandwidth or something like that?

We are using Linux 2.4.18 + RTAI 24.1.9, on a Pentium III with 512MB of RAM.
No RTAI modules loaded while testing this.

Any help or idea will be greatly appreciated (the sooner, the better).

Thanks a lot.


--------------------------------------------------------
Luis Lloret Portillo
VISAR CONTROL INDUSTRIAL, S.L.
Jefe Área Informática
Tfn: +34 918 041 013
Fax: +34 918 043 195
e-mail: luislloret@visarcontrol.es
web: http://www.visarcontrol.es
--------------------------------------------------------


