mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: thomas schorpp <t.schorpp@gmx.de>
To: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	"Ballentine, Casey" <crballentine@essvote.com>,
	video4linux-list@redhat.com,
	linux-usb-devel@lists.sourceforge.net,
	usb-storage@lists.one-eyed-alien.net,
	v4l-dvb-maintainer@linuxtv.org, mdharm-usb@one-eyed-alien.net,
	linux-kernel@vger.kernel.org, Adrian Bunk <bunk@stusta.de>
Subject: Re: [linux-usb-devel] RE: [usb-storage] Re: [v4l-dvb-maintainer] 2.6.16-rc: saa7134 + u sb-storage = freeze
Date: Thu, 23 Mar 2006 00:49:41 +0100	[thread overview]
Message-ID: <4421E295.9090008@gmx.de> (raw)
In-Reply-To: <1142953149.4749.21.camel@praia>

Mauro Carvalho Chehab wrote:
> Alan,
> Em Seg, 2006-03-20 às 23:09 +0100, thomas schorpp escreveu:
> 
>>Alan Stern wrote:
>>
>>>On Wed, 15 Mar 2006, Ballentine, Casey wrote:
> 
> 
>>what DMA problem? ive always used via chipsets with usb. now the 8237. 
> 
> 
>>the via pci-busmaster dma hangs the system?
> 
> No. it is PCI to PCI transfers ocurring while you have DMA transfers.

i see

> 
> Video capture boards allow you to transfer information from his capture
> memory to video memory without CPU.

classic vga video overlay, e.g., right?

> The problem is that some chipsets
> (or BIOS) can't handle concurrency between such transfers and normal PCI
> busmaster transfers.

maybe the reason for the green flashes in the picture i have with epox 8kha+ 
and asrock k7vt4a+ (both via 82xx).
its gone since i added a sil680 pci ide-controller for the disks and using 
the via ide only for dvdr/dvdrw drives now..

> 
>> try setting pci latency to 64.
>>most bioses initialize with 32. this had been a known problem, for me too.
>>this has been left out of the discussion at via forums.
>>
>>and what knows a usb controller about MPEG? thats another layer.
>>
>>so a bios fixes this and other os have no problem with this, 
>>so its fixable by software. then do it now, pls.
> 
> If you have such a fix, great, but while we don't have it, it is better
> to blacklist pci2pci transfers (there are other supported methods that
> are a little slow, but works as well as), than to offer a risk of mass
> corruption at their disks.

yes, indeed a good point. remember i blamed the v4l bt87x driver with xawtv for 
corrupting my root fs on kernel 2.4 some years ago, you can find the bug report on 
the v4l list, if i remember it right... 

> 
> Btw, are you sure that other OS offers pci2pci transfers for those
> devices/chipsets?

the question is *if* the hardware can handle this, as you said, so 
blacklisting hardware that cannot handle this error free should be ok,
sorry.

but if windos hadnt had support for this, i wouldnt have been able 
to use overlay video with the hauppauge wintv bt87x for years without 
any issue i can remember... right?

> 
> 
>>and stop this "blacklisting habit", all these nowadays chips are designed-to-cost 
>>"consumer crap" somewhow.
>>or do you want linux-usb to be blacklisted as "broken" by the manufacturers blacklists? ;)
>>
>>
>>y
>>tom
>>
> 
> Cheers, 
> Mauro.
> 
> 

cheers,
tom

      reply	other threads:[~2006-03-22 23:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <820212CF2FD63647B52A8F64B35352B20B942298@essomaexc1.essvote.com>
2006-03-15 23:44 ` Alan Cox
2006-03-15 23:49   ` Adrian Bunk
2006-05-17 14:13     ` Alan Cox
2006-03-16 19:55   ` Mauro Carvalho Chehab
2006-03-16 21:27     ` Alan Cox
2006-03-16 15:41 ` [linux-usb-devel] " Alan Stern
2006-03-20 22:09   ` thomas schorpp
2006-03-21 14:59     ` Mauro Carvalho Chehab
2006-03-22 23:49       ` thomas schorpp [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4421E295.9090008@gmx.de \
    --to=t.schorpp@gmx.de \
    --cc=bunk@stusta.de \
    --cc=crballentine@essvote.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=mchehab@infradead.org \
    --cc=mdharm-usb@one-eyed-alien.net \
    --cc=stern@rowland.harvard.edu \
    --cc=usb-storage@lists.one-eyed-alien.net \
    --cc=v4l-dvb-maintainer@linuxtv.org \
    --cc=video4linux-list@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®