On Thu, Aug 04, 2005 at 03:02:51PM -0700, Andrew Morton wrote:
> Roland McGrath <[EMAIL PROTECTED]> wrote:
> >
> > That's wrong. It has to be done only by the last thread in the group to go.
> > Just revert Ingo's change.
> >
>
> OK..
>
> +++ 25-akpm/kernel/exit.c Thu Aug 4 15:01:06 2005
>
Hi,
Somewhere between 2.6.11 and 2.6.12 the regression in $subject
was added to the linux kernel. Testcase below.
Ideas on that anyone?
Gerd
==[ test_exec_alarm.c
]==
#include
#include
#include
int main(int argc, char ** argv)
{
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Now, if somebody wants to make nicer helper functions so that you can say
>
> timeout = ms_from_now(500);
We already have something very simliar:
timeout = jiffies + msecs_to_jiffies(500);
;)
Gerd
--
panic("it works"); /* avoid bei
> - #if 0 the EXPORT_SYMBOL'ed but unused function tveeprom_dump
That's a debug helper function, please don't drop it. #if 0 might be
ok, not sure though, the tveeprom module is also used by a out-of-kernel
driver (ivtv). Otherwise the patch looks fine to me.
Gerd
-
To unsubscribe from this
> > struct dvb_pll_desc {
[ ... ]
> > struct {
[ ... ]
> > } entries[];
> > };
> >
> > while 2.6.11-mm3 changed it into entries[0].
>
> The original code failed to compile with gcc-2.95.4, so I stuck the [0] in
> there, then was vaguely surprised when no warnings
from earth, I will be available
for questions and patch reviews for some time, but I'll stop
doing active development and most likely will not have the
time to act as central patch relay for all video4linux stuff.
cheers,
Gerd
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
MA
Hi,
This patch adds a new ATSC frontend driver, needed by the cx88-based
pcHDTV 3000 card. Also includes a tiny chunk to activate the or51132
support in the cx88-dvb driver.
This patch depends on the cx88 dvb driver update.
Gerd
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
d
Add a ioctl to set mpeg hardware encoder parameters.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
include/linux/videodev2.h | 136 ++
1 files changed, 82 insertions(+), 54 deletions(-)
Index: linux-2.6.11-rc4/include/linux/video
n the dvb list, going to submit
directly because the saa7134 driver update depends on this.
Gerd
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/dvb/frontends/mt352.c | 197 ++--
drivers/media/dvb/frontends/mt352.h | 15 +-
2 files changed, 144
finally get out of the door depends on this one I'll
go submit it myself instead of waiting for the dvb guys doing
it.
Gerd
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/dvb/frontends/Makefile |1
drivers/media/dvb/frontends/dvb-p
$subject says all ;)
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
Documentation/video4linux/CARDLIST.saa7134 | 41 ++---
Documentation/video4linux/README.cx88 |3 -
Documentation/video4linux/bttv/Cards |7 ++-
Documentation/video4linux/bttv/
Hi,
the patch below simplifies the videotext drivers saa5246a and saa5249 by
using the I2C_CLIENT_INSMOD macro.
Thanks to Kai Volkmar.
Michael
Signed-off-by: Michael Geng <[EMAIL PROTECTED]>
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/video/saa52
Add some new tuners to the list.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/video/tveeprom.c | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
Index: linux-2.6.11/drivers/media/video/tvee
Minor update for the tuner module: Add some new entries,
fix a bug in the tda8290 driver.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/video/mt20xx.c |3 ++-
drivers/media/video/tda8290.c |4 ++--
drivers/media/video/tuner-simple.c |9 -
i
This is a bttv driver update, changes:
* add support for a new card.
* add some debug code (bt878 risc disassembler).
* drop some obsolete i2c code.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/video/btcx-risc.c | 12 +-
drivers/media/video/bttv-cards.c
Changes:
* add some keytables which are used by both bttv and cx88 driver
so they can be shared.
* add IR decoding helper functions.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/common/ir-common.c | 164 ++-
include/media/ir-co
minor bttv IR driver update: drop a keytable and use the one in
ir-common.ko instead.
This patch depends on the ir-common update.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/video/ir-kbd-gpio.c | 51 +-
1 files changed, 3 insertions(
Bugfix: catch pci_map_sg() failures.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/video/video-buf.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff -u linux-2.6.11/drivers/media/video/video-buf.c
linux/drivers/media/video/video-buf.c
---
On Sun, Mar 06, 2005 at 07:55:25PM +0200, James Bottomley wrote:
> Looking through this, the only things I really noticed that need work
> are:
>
> ch_do_scsi(): It looks like this has an effective reimplementation of
> scsi_wait_req. We're trying to deprecate the usage of scsi_do_req so we
> ca
On Fri, Mar 04, 2005 at 02:39:17AM -0500, Dave Jones wrote:
> On Thu, Mar 03, 2005 at 11:17:16PM -0800, Andrew Morton wrote:
>
> > > The reason this wasn't picked up is that neither `make allyesconfig' or
> > > `make allmodconfig' enables CONFIG_VIDEO_CX88_DVB or
> > > CONFIG_VIDEO_CX88_DVB_
> I did notice one strange thing though; the card= option is only applied
> to the first bttv card. All remaining cards in the system are still
> autodetected (which ends up assuming card=0 in my case). Not sure if
> this is the intended behavior or not, since someone really could run two
> d
James Bruce <[EMAIL PROTECTED]> writes:
> If you could suggest a very well tested kernel for bttv (2.6.9?),
What do you expect? With just one single report and not remotely
being clear what exactly caused it ...
> I've heard that there is some way to dump eeproms; Is there a way to
> write them
> I remember something about that you shouldn't use the teletext-decoder
> at the same time as viewing regular tv. That would damage the eeprom.
> Maybe it is related?
No. Thats (a) very old and about two drivers banging on the bt848 card
at the same time, where the second doesn't even exist for
James Bruce <[EMAIL PROTECTED]> writes:
> Well, are there any theories as to why it would work flawlessly, then
> after a hard lockup (due to what I think is a buggy V4L2 application),
> that the cards no longer work?
No idea why the eeprom doesn't respond any more. Maybe it's really
broken. No
On Fri, Feb 25, 2005 at 11:57:49PM -0500, James Bruce wrote:
> Hi I've read elsewhere that the following message:
> "tveeprom(bttv internal): Huh, no eeprom present (err=-121)?"
> Means that a bttv card is dead.
Or i2c communication to the eeprom failed. There used to be some -mm
kernels with e
> > + list_for_each(item,&ch_devlist) {
> > + tmp = list_entry(item, scsi_changer, list);
>
> list_for_each_entry
Oh, a new fancy toy I havn't notices yet ;)
When this was added btw.?
New version of the patch is below.
Gerd
======[
it ;)
Recently I went over it and did some 2.6 cleanups, module parameters
and the like. And now, finally, here it is.
Please apply,
Gerd
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
Documentation/scsi-changer.txt | 184 +
drivers/scsi/Kconfig | 18
driver
Just a new PCI Subsystem ID and a PM fix from Pavel.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/video/bttv-cards.c |4 +++-
drivers/media/video/bttv-driver.c |4 ++--
drivers/media/video/bttv.h|2 +-
drivers/media/video/bttvp.h |2 +-
4
> > That one should go into 2.6.11.
> > - fix initialization order bug.
>
> I applied your earlier patch already. Can you verify that I merged
> everything correctly, and that my current BK tree matches yours?
Yep, it is fine. Just a whitespace sneaked in somehow, otherwise
current bk is identi
Hi,
That one should go into 2.6.11.
- fix initialization order bug.
- disable + comment current secam tweak, will not work that way ...
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/video/tda9887.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
> > > mt2032_set_if_freq failed with -121
>
> OK here you go.
Thanks, seems to be a initialization order bug which changes the default
state of the tda9887 output ports. The patch below should fix that.
Gerd
diff -u linux-2.6.11/drivers/media/video/tda9887.c
linux/drivers/media/video/tda988
On Tue, Feb 01, 2005 at 08:19:17PM -0500, Eric Lammerts wrote:
>
> Hi,
> I had a lot of problems with the transport stream input on the
> SAA7134. Even the slighest bit of other system activity caused data
> corruption. This patch corrects the switching of the two DMA
> buffers.
Thanks, merged (a
Markus Trippelsdorf <[EMAIL PROTECTED]> writes:
> tuner: chip found at addr 0xc0 i2c-bus bt878 #0 [sw]
> tuner: type set to 33 (MT20xx universal) by bt878 #0 [sw]
> tuner: microtune: companycode=4d54 part=04 rev=04
> tuner: microtune MT2032 found, OK
> tda9885/6/7: chip found @ 0x86
> ...
> mt2032
> 0x1a is reserved for TI PCILynx in the i2c project, although I never took
> the time to forward the update to the kernel trees. Could you please use
> 0x1b instead?
Ok, here is a new version of the patch, using 0x1b.
Gerd
Index: linux-2005-01-23/include/linux/i2c-id.h
===
Hi,
$subject says all. Please apply,
Gerd
Index: linux-2.6.11-rc2/include/linux/i2c-id.h
===
--- linux-2.6.11-rc2.orig/include/linux/i2c-id.h2005-01-24
09:11:12.0 +0100
+++ linux-2.6.11-rc2/include/linux/i2c-id
> > The patch below should fix this.
>
> Not completely:
> CC drivers/media/video/saa7134/saa7134-core.o
> drivers/media/video/saa7134/saa7134-core.c: In function `saa7134_initdev':
> drivers/media/video/saa7134/saa7134-core.c:997: error: `need_empress'
> undeclared (first use in this fun
On Mon, Jan 24, 2005 at 12:17:13PM +0100, Adrian Bunk wrote:
> On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> >...
> > +v4l-saa7134-module.patch
>
> This patch broke compilation with CONFIG_MODULES=n:
>
> drivers/media/video/saa7134/saa7134-core.c: In function `pending_call':
>
Add new tuner type to the v4l2 API.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
include/linux/videodev2.h |1 +
1 files changed, 1 insertion(+)
diff -u linux-2.6.10/include/linux/videodev2.h linux/include/linux/videodev2.h
--- linux-2.6.10/include/linux/videodev2.h 2005-01
- Fix a memory leak in video-buf.c
- Small update for the video-buf-dvb.c module.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/video/video-buf-dvb.c | 11 +++
drivers/media/video/video-buf.c |4 +++-
include/media/video-buf-dvb.h |4 +++-
3
- add new tuner types.
- add support for digital tv tuning.
- make tda9887 output ports more configurable.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/video/tda9887.c | 38 +++--
drivers/media/video/tuner.c
Add a module which can parse config informations out of
TV card eeproms. Will be used by bttv, cx88 and ivtv.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/Kconfig |3
drivers/media/video/Makefile |1
drivers/media/video/tveeprom.c
This patch enables IR support for one AverMedia card and
drops a obsolete function.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/common/ir-common.c |3 ++-
drivers/media/video/ir-kbd-gpio.c |4 ++--
drivers/media/video/ir-kbd-i2c.c | 14 ++
3
- some cleanups merged.
- use new tveeprom module to configure Hauppauge cards.
- add new tv cards.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/video/Kconfig |1
drivers/media/video/btcx-risc.c |3
drivers/media/video/bttv-cards.c
- fix saa7134 module loading issues.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
drivers/media/video/saa7134/saa7134-core.c | 47 -
1 files changed, 45 insertions(+), 2 deletions(-)
Index: linux-2.6.10/drivers/media/video/saa7134/saa7134-
ation/ioctl.h to reflect that change.
and deletes a unused struct in include/linux/videotext.h.
Signed-off-by: Gerd Knorr <[EMAIL PROTECTED]>
---
Documentation/ioctl-number.txt |3 -
drivers/media/video/saa5246a.c | 49 +++
drivers/media/video/saa5246a.h |2
drivers/
> About 100 pixels from my windowmaker background got garbled (I also ran
> xrefresh) while panicking ;-> and "rpm -V mozilla" showed three modified
> libs.
> However, the libs were OK after reboot (maybe because no time for syncing),
> but reiserfsck found vpf-10640 error for /var partition.
Tha
Andreas Gruenbacher <[EMAIL PROTECTED]> writes:
> The user does a ``make menuconfig'', and expects to see sane defaults.
> What kconfig really does is take the running kernel's configuration
> instead. This is a ad choice; it makes much more sense to take
> arch/$ARCH/defconfig.
IIRC the vanilla
> This patch was already sent on:
> - 9 Nov 2004
Damn, yes. I have it. I don't consider those patches *that* important
that I instantly forward the stuff, they'll go out with the next batch
of v4l updates because it's less work that way.
If you want to have a look at my latest (not submitted ye
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
> >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
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
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
> 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
> > 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"
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
> 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
> > > 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
> 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
> > 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.
>
>
> 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
> 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
> 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
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
> > 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
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
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
> > 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
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
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
> 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
> 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
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
72 matches
Mail list logo
