Terry Barnaby wrote:
> Hi,
>
> We are doing work with FPGA's and have a Linux driver for a particular
> board that has these
> devices. For performance reasons the driver has the ability to DMA
> directly to process (user)
> memory. We have made use of the kiobuf routines such as
> "map_user_kiob
> yywrap is a hack rather than generally safe feature and its not guaranteed that
> your videoram wraps neatly. Really the driver should have spotted the hole I
> guess.
Well, vesafb really depends on what the vesa bios says...
That's why it has all may-have-problems features turned off by defau
> last 2 lines in dmesg output:
> mtrr: 0xd800,0x200 overlaps existing 0xd800,0x100
> mtrr: 0xd800,0x200 overlaps existing 0xd800,0x100
both *fb fbcon drivers and xfree 4 try to setup mtrr ranges, which
are the same for the video card => mtrr complains because the
> > Please tell me what you think the right interface is that provides a hook
> > on io completion and is asynchronous.
>
> Suggested fix to kiovec's: get rid of them. Immediately. Replace them with
> kiobuf's that can handle scatter-gather pages. kiobuf's have 90% of that
> support already.
>
>
to the hardware.
And the reverse to free everything when you are done of course.
Gerd
[1] IMHO it would be more useful if iobufs would use a scatterlist
instead of an struct page* array.
--
Gerd Knorr <[EMAIL PROTECTED]> -- SuSE Labs, Außenstelle Berlin
-
To unsubscribe fr
ss (needs
lots of I/O bandwidth, but doesn't need much address space).
Video capture does a better job on eating iommu resources ...
Gerd
[1] http://bytesex.org/bttv/, 0.8.x versions.
--
Gerd Knorr <[EMAIL PROTECTED]> -- SuSE Labs, Außenstelle Berlin
-
To unsubscribe from
> > Come to think of it .. then we'd start getting "buz drivers missing"
> > reports.
>
> So what?
> Refer them to [EMAIL PROTECTED] and we'll explain them how
> to use the new zoran driver until it's in the official kernel...
#warning "outdated, see http://whatever for current devel versions"
> to the driver which performs a map_user_kiobuf() on it, the resulting
> kiobuf
> structure has all of the pagelist[] physical address entries set to the
> same value
> and the maplist[] entries set to 0. The devices access to this memory
> now
> causes system problems.
> Is map_user_kiob
Werner Almesberger wrote:
> The BTTV driver 0.7.48 doesn't detect my old Hauppauge card anymore.
Yes. I've taken out the detection heuristics for bt848 cards. The code
is very old, from the days where only 2-3 different bt848 cards where
available. It simply did'nt work correctly and often use
Werner Almesberger wrote:
> Gerd Knorr wrote:
> > It simply did'nt work correctly and often used to misdetect
> > random bt848 cards as either MIRO or Hauppauge (which where the first
> > available cards).
>
> Well, this means there's yet another mandatory
> > Why? What is the point in compiling bttv statically into the kernel?
> > Unlike filesystems/ide/scsi/... you don't need it to get the box up.
> > No problem to compile the driver as module and configure it with
> > /etc/modules.conf ...
>
> Huh?
>
> Some systems are built without module sup
On Sun, 19 Nov 2000, David Lang wrote:
> there is a rootkit kernel module out there that, if loaded onto your
> system, can make it almost impossible to detect that your system has been
> compramised. with module support disabled this isn't possible.
Wrong. I've seen messages on bugtraq saying
On Mon, 20 Nov 2000, Keith Owens wrote:
> On 19 Nov 2000 12:56:17 GMT,
> [EMAIL PROTECTED] (Gerd Knorr) wrote:
> >Some generic way to make module args available as kernel args too
> >would be nice. Or at least some simple one-liner I could put next to
> >the MODULE_PA
> > This is true. What I suppose would be the solution is that if faulty
> > hardware is found, a reduction in performance should be made.
>
> Finding out if you've got bad RAM might take a few hours running mem86. Not
> exactly what I have in mind to do each boot...
Even if memtest doesn't fin
Justin Schoeman wrote:
> With the VIA chipset you should use the "triton1=1" module option.
> (Well, at least it worked for me!)
>
> -justin
>
> > [1.] One line summary of the problem:
> > bttv crashes kernel 2.4.0testX on a Vodoo3 2000
[ ... ]
> > PCI devices found:
> > Bus 0, device
> OK, that makes it somewhat clearer to me. However, I don't use modules
> and have everything compiled in, so I can't control the order in which
> the mixer devices get loaded.
Exactly that's why I compile nearly everything as modules :-)
The other reason is that the turn-around times for driver
7/einhorn.in-berlin.de--
ReSent-Date: Sun, 8 Oct 2000 13:56:41 +0200 (CEST)
ReSent-From: Gerd Knorr <[EMAIL PROTECTED]>
ReSent-To: [EMAIL PROTECTED]
ReSent-Subject: Re: bttv driver sometimes oopses
ReSent-Message-ID: <[EMAIL PROTECTED]>
Koos Vriezen wrote:
> Hi,
>
> Since i2
> bttv0: model: BT848A( *** UNKNOWN *** ) [autodetected]
How about fixing this first? The card list knows about a few
cards where it better should'nt load the msp3400 driver...
> i2c-dev.o: Registered 'bt848 #0' as minor 0
> msp34xx: I/O error #1 (read 0x12/0x1e)
> msp34xx: I/O error #2 (read
> I've got kiobuf diffs which allow you to (a) map any kernel memory
> (including vmalloced areas) into a kiobuf, and then (b) mmap any
> kiobuf into user space using sane, faulting vmas (with the option of
> prefaulting for performance if you want it). Nobody is using it right
> now so I wasn't
> This is very bizzare, as when I look at the debug output from the tuner
> module, it appears from the kernel messages that the card is being tuned
> to the correct frequency. I know there is a station on that frequency
> yet I
> don't get any picture or sound, so obviously the tuner driver is sa
> > > I have sent all this info to Gerd Knorr but, as far as I know, he hasn't
> > > been able to track down the bug yet. I thought that by posting here,
> > > more eyes might at least make more reports of similar situations that
> > > might help track d
> The card is a video only capture that came with a camera (and has a
> connector to power that camera next to the video connector).
Sure the box is really dead? These very cheap cards with just the bt848
and nothing else often have a non-working i2c bus (because they have no
chips connected to
> >There are no conflicts, and PCI should be able to share anyways.
>
> That's the theory now for some time, has never worked. Even hacking
> the SCSI driver, any attempted IRQ sharing kills my systems. Even my
> quad ethernet is not successful at sharing IRQs with itself, in 2+ very
> dif
On Mon, Jun 25, 2001 at 12:56:03PM +0200, Udo A. Steinberg wrote:
>
> Hello,
>
> Attached is the trace of an oops which seems to be caused by the
> tvmixer code. Tvmixer is compiled monolithically into the kernel,
> the rest of bttv is compiled as modules.
Any hints on how to reproduce that one
24 matches
Mail list logo
