Re: [PATCH 1/1] iova: Allow compiling the library without IOMMU support
- Original Message - > From: "Sakari Ailus" > Sent: Thursday, January 3, 2019 2:11:27 PM Hi Laurent and Sakari, I don't have much else to offer here, but wanted to second Sakari's use case below. > Hi Laurent, > > On Thu, Jan 03, 2019 at 12:52:00AM +0200, Laurent Pinchart wrote: >> Hi Sakari, >> >> Thank you for the patch. >> >> On Wednesday, 2 January 2019 23:16:57 EET Sakari Ailus wrote: >> > Drivers such as the Intel IPU3 ImgU driver use the IOVA library to manage >> > the device's own virtual address space while not implementing the IOMMU >> > API. >> >> Why is that ? Could the IPU3 IOMMU be implemented as an IOMMU driver ? > > You could do that, but: > > - it's a single PCI device so there's no advantage in doing so and I also use the IOVA library for a PCI device (PCIe-VME bridge) that has IOMMU features, but isn't a general purpose IOMMU. I am eagerly following along. -Aaron > - doing that would render the device inoperable if an IOMMU is enabled in > the system, as chaining IOMMUs is not supported in the IOMMU framework > AFAIK. > >> >> > Currently the IOVA library is only compiled if the IOMMU support is >> > enabled, resulting into a failure during linking due to missing symbols. >> > >> > Fix this by defining IOVA library Kconfig bits independently of IOMMU >> > support configuration, and descending to the iommu directory >> > unconditionally during the build. >> > >> > Signed-off-by: Sakari Ailus
Editing 3
Hi, If you have photos for editing, please send email to: hansre...@outlook.com We have 12 in house image editors and we can help you for cutting out your photos, or path the photos. Includes retouching if needed. Used for products photos or portrait photos, catalog photos. You may drop us one photo, we can send you the testing work. Thanks, Aaron Williams Email: hansre...@outlook.com
Editing 5
Hi, If you have photos for editing, please send email to: hansre...@outlook.com We have 12 in house image editors and we can help you for cutting out your photos, or path the photos. Includes retouching if needed. Used for products photos or portrait photos, catalog photos. You may drop us one photo, we can send you the testing work. Thanks, Aaron Williams Email: hansre...@outlook.com
Editing 3
Hi, If you have photos for editing, please send email to: hansre...@outlook.com We have 12 in house image editors and we can help you for cutting out your photos, or path the photos. Includes retouching if needed. Used for products photos or portrait photos, catalog photos. You may drop us one photo, we can send you the testing work. Thanks, Aaron Williams Email: hansre...@outlook.com
Editing 4
Hi, If you have photos for editing, please send email to: hansre...@outlook.com We have 12 in house image editors and we can help you for cutting out your photos, or path the photos. Includes retouching if needed. Used for products photos or portrait photos, catalog photos. You may drop us one photo, we can send you the testing work. Thanks, Aaron Williams Email: hansre...@outlook.com
Editing 4
Hi, If you have photos for editing, please send email to: hansre...@outlook.com We have 12 in house image editors and we can help you for cutting out your photos, or path the photos. Includes retouching if needed. Used for products photos or portrait photos, catalog photos. You may drop us one photo, we can send you the testing work. Thanks, Aaron Williams Email: hansre...@outlook.com
Editing 1
Hi, If you have photos for editing, please send email to: hansre...@outlook.com We have 12 in house image editors and we can help you for cutting out your photos, or path the photos. Includes retouching if needed. Used for products photos or portrait photos, catalog photos. You may drop us one photo, we can send you the testing work. Thanks, Aaron Williams Email: hansre...@outlook.com
em2750 usb camera log as mentioned in dmesg
Hi, I have endless problems since upgarding to ubuntu12.04 with my usb microscope and it's a big problem cos i need it for work. As suggested in dmesg I have sent you the log.. Interestingly the em2750 camera is Ok on my desk pc with Xubuntu 12.04... go figure.. But the desk pC is kinda hard to carry to customer sites. I hope to find a solution soon thanks Aaron [12699.292580] em28xx: New device @ 480 Mbps (eb1a:2750, interface 0, class 0) [12699.292585] em28xx: Video interface 0 found: isoc [12699.292636] em28xx: chip ID is em2750 [12699.476200] em2750 #0: board has no eeprom [12699.547792] em2750 #0: No sensor detected [12699.583014] em2750 #0: found i2c device @ 0xba on bus 0 [webcam sensor or tvp5150a] [12699.595736] em2750 #0: Your board has no unique USB ID and thus need a hint to be detected. [12699.595742] em2750 #0: You may try to use card= insmod option to workaround that. [12699.595746] em2750 #0: Please send an email with this log to: [12699.595749] em2750 #0: V4L Mailing List [12699.595752] em2750 #0: Board eeprom hash is 0x [12699.595756] em2750 #0: Board i2c devicelist hash is 0x1bdd0080 [12699.595759] em2750 #0: Here is a list of valid choices for the card= insmod option: [12699.595764] em2750 #0: card=0 -> Unknown EM2800 video grabber [12699.595768] em2750 #0: card=1 -> Unknown EM2750/28xx video grabber [12699.595772] em2750 #0: card=2 -> Terratec Cinergy 250 USB [12699.595776] em2750 #0: card=3 -> Pinnacle PCTV USB 2 [12699.595779] em2750 #0: card=4 -> Hauppauge WinTV USB 2 [12699.595783] em2750 #0: card=5 -> MSI VOX USB 2.0 [12699.595786] em2750 #0: card=6 -> Terratec Cinergy 200 USB [12699.595790] em2750 #0: card=7 -> Leadtek Winfast USB II [12699.595793] em2750 #0: card=8 -> Kworld USB2800 [12699.595798] em2750 #0: card=9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker / Kworld DVD Maker 2 / Plextor ConvertX PX-AV100U [12699.595802] em2750 #0: card=10 -> Hauppauge WinTV HVR 900 [12699.595805] em2750 #0: card=11 -> Terratec Hybrid XS [12699.595809] em2750 #0: card=12 -> Kworld PVR TV 2800 RF [12699.595812] em2750 #0: card=13 -> Terratec Prodigy XS [12699.595816] em2750 #0: card=14 -> SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 [12699.595819] em2750 #0: card=15 -> V-Gear PocketTV [12699.595823] em2750 #0: card=16 -> Hauppauge WinTV HVR 950 [12699.595827] em2750 #0: card=17 -> Pinnacle PCTV HD Pro Stick [12699.595830] em2750 #0: card=18 -> Hauppauge WinTV HVR 900 (R2) [12699.595834] em2750 #0: card=19 -> EM2860/SAA711X Reference Design [12699.595838] em2750 #0: card=20 -> AMD ATI TV Wonder HD 600 [12699.595841] em2750 #0: card=21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder [12699.595845] em2750 #0: card=22 -> EM2710/EM2750/EM2751 webcam grabber [12699.595849] em2750 #0: card=23 -> Huaqi DLCW-130 [12699.595852] em2750 #0: card=24 -> D-Link DUB-T210 TV Tuner [12699.595856] em2750 #0: card=25 -> Gadmei UTV310 [12699.595859] em2750 #0: card=26 -> Hercules Smart TV USB 2.0 [12699.595863] em2750 #0: card=27 -> Pinnacle PCTV USB 2 (Philips FM1216ME) [12699.595867] em2750 #0: card=28 -> Leadtek Winfast USB II Deluxe [12699.595870] em2750 #0: card=29 -> EM2860/TVP5150 Reference Design [12699.595874] em2750 #0: card=30 -> Videology 20K14XUSB USB2.0 [12699.595877] em2750 #0: card=31 -> Usbgear VD204v9 [12699.595881] em2750 #0: card=32 -> Supercomp USB 2.0 TV [12699.595884] em2750 #0: card=33 -> Elgato Video Capture [12699.595888] em2750 #0: card=34 -> Terratec Cinergy A Hybrid XS [12699.595891] em2750 #0: card=35 -> Typhoon DVD Maker [12699.595895] em2750 #0: card=36 -> NetGMBH Cam [12699.595898] em2750 #0: card=37 -> Gadmei UTV330 [12699.595902] em2750 #0: card=38 -> Yakumo MovieMixer [12699.595906] em2750 #0: card=39 -> KWorld PVRTV 300U [12699.595909] em2750 #0: card=40 -> Plextor ConvertX PX-TV100U [12699.595913] em2750 #0: card=41 -> Kworld 350 U DVB-T [12699.595916] em2750 #0: card=42 -> Kworld 355 U DVB-T [12699.595920] em2750 #0: card=43 -> Terratec Cinergy T XS [12699.595924] em2750 #0: card=44 -> Terratec Cinergy T XS (MT2060) [12699.595927] em2750 #0: card=45 -> Pinnacle PCTV DVB-T [12699.595931] em2750 #0: card=46 -> Compro, VideoMate U3 [12699.595934] em2750 #0: card=47 -> KWorld DVB-T 305U [12699.595938] em2750 #0: card=48 -> KWorld DVB-T 310U [12699.595941] em2750 #0: card=49 -> MSI DigiVox A/D [12699.595945] em2750 #0: card=50 -> MSI DigiVox A/D II [12699.595948] em2750 #0: card=51 -> Terratec Hybrid XS Secam [12699.595952] em2750 #0: card=52 -> DNT DA2 Hybrid [12699.595955] em2750 #0: card=53 -> Pinnacle Hybrid Pro [12
Re: [PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic
On 12/20/2012 05:14 AM, Daniel Vetter wrote:
All drivers which implement this need to have some sort of refcount to
allow concurrent vmap usage. Hence implement this in the dma-buf core.
To protect against concurrent calls we need a lock, which potentially
causes new funny locking inversions. But this shouldn't be a problem
for exporters with statically allocated backing storage, and more
dynamic drivers have decent issues already anyway.
Inspired by some refactoring patches from Aaron Plattner, who
implemented the same idea, but only for drm/prime drivers.
v2: Check in dma_buf_release that no dangling vmaps are left.
Suggested by Aaron Plattner. We might want to do similar checks for
attachments, but that's for another patch. Also fix up ERR_PTR return
for vmap.
v3: Check whether the passed-in vmap address matches with the cached
one for vunmap. Eventually we might want to remove that parameter -
compared to the kmap functions there's no need for the vaddr for
unmapping. Suggested by Chris Wilson.
v4: Fix a brown-paper-bag bug spotted by Aaron Plattner.
The kernel spotted it when I tried to vunmap a buffer. :)
Cc: Aaron Plattner
Signed-off-by: Daniel Vetter
Reviewed-by: Aaron Plattner
Tested-by: Aaron Plattner
--
Aaron
---
Documentation/dma-buf-sharing.txt | 6 +-
drivers/base/dma-buf.c| 43 ++-
include/linux/dma-buf.h | 4 +++-
3 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index 0188903..4966b1b 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three
steps:
void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
The vmap call can fail if there is no vmap support in the exporter, or if
it
- runs out of vmalloc space. Fallback to kmap should be implemented.
+ runs out of vmalloc space. Fallback to kmap should be implemented. Note that
+ the dma-buf layer keeps a reference count for all vmap access and calls down
+ into the exporter's vmap function only when no vmapping exists, and only
+ unmaps it once. Protection against concurrent vmap/vunmap calls is provided
+ by taking the dma_buf->lock mutex.
3. Finish access
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..26b68de 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -39,6 +39,8 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
dmabuf = file->private_data;
+ BUG_ON(dmabuf->vmapping_counter);
+
dmabuf->ops->release(dmabuf);
kfree(dmabuf);
return 0;
@@ -482,12 +484,34 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
*/
void *dma_buf_vmap(struct dma_buf *dmabuf)
{
+ void *ptr;
+
if (WARN_ON(!dmabuf))
return NULL;
- if (dmabuf->ops->vmap)
- return dmabuf->ops->vmap(dmabuf);
- return NULL;
+ if (!dmabuf->ops->vmap)
+ return NULL;
+
+ mutex_lock(&dmabuf->lock);
+ if (dmabuf->vmapping_counter) {
+ dmabuf->vmapping_counter++;
+ BUG_ON(!dmabuf->vmap_ptr);
+ ptr = dmabuf->vmap_ptr;
+ goto out_unlock;
+ }
+
+ BUG_ON(dmabuf->vmap_ptr);
+
+ ptr = dmabuf->ops->vmap(dmabuf);
+ if (IS_ERR_OR_NULL(ptr))
+ goto out_unlock;
+
+ dmabuf->vmap_ptr = ptr;
+ dmabuf->vmapping_counter = 1;
+
+out_unlock:
+ mutex_unlock(&dmabuf->lock);
+ return ptr;
}
EXPORT_SYMBOL_GPL(dma_buf_vmap);
@@ -501,7 +525,16 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
- if (dmabuf->ops->vunmap)
- dmabuf->ops->vunmap(dmabuf, vaddr);
+ BUG_ON(!dmabuf->vmap_ptr);
+ BUG_ON(dmabuf->vmapping_counter == 0);
+ BUG_ON(dmabuf->vmap_ptr != vaddr);
+
+ mutex_lock(&dmabuf->lock);
+ if (--dmabuf->vmapping_counter == 0) {
+ if (dmabuf->ops->vunmap)
+ dmabuf->ops->vunmap(dmabuf, vaddr);
+ dmabuf->vmap_ptr = NULL;
+ }
+ mutex_unlock(&dmabuf->lock);
}
EXPORT_SYMBOL_GPL(dma_buf_vunmap);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index bd2e52c..e3bf2f6 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -119,8 +119,10 @@ struct dma_buf {
struct file *file;
struct list_head attachments;
const struct dma_buf_ops *ops;
- /* mutex to serialize list manipulation and attach/detach */
+ /* mutex to serialize list manipulation, attach/detach and vmap/unmap */
struct mutex lock;
+ unsigned
Re: [PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic
On 12/17/2012 03:58 PM, Daniel Vetter wrote:
All drivers which implement this need to have some sort of refcount to
allow concurrent vmap usage. Hence implement this in the dma-buf core.
To protect against concurrent calls we need a lock, which potentially
causes new funny locking inversions. But this shouldn't be a problem
for exporters with statically allocated backing storage, and more
dynamic drivers have decent issues already anyway.
Inspired by some refactoring patches from Aaron Plattner, who
implemented the same idea, but only for drm/prime drivers.
v2: Check in dma_buf_release that no dangling vmaps are left.
Suggested by Aaron Plattner. We might want to do similar checks for
attachments, but that's for another patch. Also fix up ERR_PTR return
for vmap.
v3: Check whether the passed-in vmap address matches with the cached
one for vunmap. Eventually we might want to remove that parameter -
compared to the kmap functions there's no need for the vaddr for
unmapping. Suggested by Chris Wilson.
Cc: Aaron Plattner
Signed-off-by: Daniel Vetter
---
Compile-tested only - Aaron has been bugging me too a bit too often
about this on irc.
Cheers, Daniel
---
Documentation/dma-buf-sharing.txt | 6 +-
drivers/base/dma-buf.c| 43 ++-
include/linux/dma-buf.h | 4 +++-
3 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index 0188903..4966b1b 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three
steps:
void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
The vmap call can fail if there is no vmap support in the exporter, or if
it
- runs out of vmalloc space. Fallback to kmap should be implemented.
+ runs out of vmalloc space. Fallback to kmap should be implemented. Note that
+ the dma-buf layer keeps a reference count for all vmap access and calls down
+ into the exporter's vmap function only when no vmapping exists, and only
+ unmaps it once. Protection against concurrent vmap/vunmap calls is provided
+ by taking the dma_buf->lock mutex.
3. Finish access
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..67d3cd5 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -39,6 +39,8 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
dmabuf = file->private_data;
+ BUG_ON(dmabuf->vmapping_counter);
+
dmabuf->ops->release(dmabuf);
kfree(dmabuf);
return 0;
@@ -482,12 +484,34 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
*/
void *dma_buf_vmap(struct dma_buf *dmabuf)
{
+ void *ptr;
+
if (WARN_ON(!dmabuf))
return NULL;
- if (dmabuf->ops->vmap)
- return dmabuf->ops->vmap(dmabuf);
- return NULL;
+ if (!dmabuf->ops->vmap)
+ return NULL;
+
+ mutex_lock(&dmabuf->lock);
+ if (dmabuf->vmapping_counter) {
+ dmabuf->vmapping_counter++;
+ BUG_ON(!dmabuf->vmap_ptr);
+ ptr = dmabuf->vmap_ptr;
+ goto out_unlock;
+ }
+
+ BUG_ON(dmabuf->vmap_ptr);
+
+ ptr = dmabuf->ops->vmap(dmabuf);
+ if (IS_ERR_OR_NULL(ptr))
+ goto out_unlock;
+
+ dmabuf->vmap_ptr = ptr;
+ dmabuf->vmapping_counter = 1;
+
+out_unlock:
+ mutex_unlock(&dmabuf->lock);
+ return ptr;
}
EXPORT_SYMBOL_GPL(dma_buf_vmap);
@@ -501,7 +525,16 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
- if (dmabuf->ops->vunmap)
- dmabuf->ops->vunmap(dmabuf, vaddr);
+ BUG_ON(!dmabuf->vmap_ptr);
+ BUG_ON(dmabuf->vmapping_counter > 0);
This should be BUG_ON(vmapping_counter == 0);
Otherwise, this seems to work fine.
--
Aaron
+ BUG_ON(dmabuf->vmap_ptr != vaddr);
+
+ mutex_lock(&dmabuf->lock);
+ if (--dmabuf->vmapping_counter == 0) {
+ if (dmabuf->ops->vunmap)
+ dmabuf->ops->vunmap(dmabuf, vaddr);
+ dmabuf->vmap_ptr = NULL;
+ }
+ mutex_unlock(&dmabuf->lock);
}
EXPORT_SYMBOL_GPL(dma_buf_vunmap);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index bd2e52c..e3bf2f6 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -119,8 +119,10 @@ struct dma_buf {
struct file *file;
struct list_head attachments;
const struct dma_buf_ops *ops;
- /* mutex to serialize list manipulation and attach/detach */
+ /* mutex to serialize list manipulation, attach/detach and vmap/unmap */
struct mutex lock;
+
Re: [PATCH v2] drm/exynos: use prime helpers
On 12/06/2012 10:36 PM, Inki Dae wrote: Hi, CCing media guys. I agree with you but we should consider one issue released to v4l2. As you may know, V4L2-based driver uses vb2 as buffer manager and the vb2 includes dmabuf feature>(import and export) And v4l2 uses streaming concept>(qbuf and dqbuf) With dmabuf and iommu, generally qbuf imports a fd into its own buffer and maps it with its own iommu table calling dma_buf_map_attachment(). And dqbuf calls dma_buf_unmap_attachment() to unmap that buffer from its own iommu table. But now vb2's unmap_dma_buf callback is nothing to do. I think that the reason is the below issue, If qbuf maps buffer with iomm table and dqbuf unmaps it from iommu table then it has performance deterioration because qbuf and dqbuf are called repeatedly. And this means map/unmap are repeated also. So I think media guys moved dma_unmap_sg call from its own unmap_dma_buf callback to detach callback instead. For this, you can refer to vb2_dc_dmabuf_ops_unmap and vb2_dc_dmabuf_ops_detach function. So I added the below patch to avoid that performance deterioration and am testing it now.(this patch is derived from videobuf2-dma-contig.c) http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git;a=commit;h=576b1c3de8b90cf1570b8418b60afd1edaae4e30 Thus, I'm not sure that your common set could cover all the cases including other frameworks. Please give me any opinions. It seems like this adjustment would make perfect sense to add to the helper layer I suggested. E.g., instead of having an exynos_attach structure that caches the sgt, there'd be a struct drm_gem_prime_attach that would do the same thing, and save the sgt it gets from driver->gem_prime_get_sg. Then it would benefit nouveau and radeon, too. Alternatively, patch #4 could be dropped and Exynos can continue to reimplement all of this core functionality, since the helpers are optional, but I don't see anything about this change that should make it Exynos-specific, unless I'm missing something. -- Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Prof 7500 demod crashing after many tunes
I wrote a scan program that steps through all the frequencies in a given range and tries to tune them in a for loop. This is my first C program so be nice, http://chinesebob.net/dvb/blindscan-s2/blindscan-s2-201104070153.tgz I'm using it with my Prof 7500, which uses the dvb-usb-dw2102 and stv0900 modules, this way I can use the blindscan algo and do a blind scan for all transponders in a satellite to find the symbol rates. A problem I'm having now is that after something like 60 tuning attempts the demod crashes and I cannot tune anything else unless I reset power on the tuning device, this is a usb device. Resetting the usb bus and removing/readding the drivers doesn't help. This happens on any version of s2-liplianin I've tried from 3 months ago to current. The current version of s2-liplianin tunes much faster but, that just means it will crash faster when I try my tuning loop. Please let me know what kind of debugging I should do and what I should post to the list that would be helpful to figure this out. When it's in this state I get a constant DEMOD LOCK OK, and it thinks it has 100% signal, is there some way to force the demod to think it is not locking, or force reset the demod somehow without resetting power to the device? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hauppauge hvr-2200 stops working when Hauppauge hvr-1110 is connected
Hello, I am using Mythbuntu 10.04 and have linux-firmware-nonfree from: https://bugs.launchpad.net/ubuntu/+source/linux-firmware-nonfree/+bug/579783 I have been happily using Mythbuntu with a Hauppauge hvr-2200 dual tuner DVB-T for many months (thanks Steven Toth!) and it records all my TV in MythTV. NZ has three DVB-T multiplexes, so I bought a second single-tuner DVB-T card, a Hauppauge hvr-1110, to cover the third multiplex and mean that, with multirec, I can record all channels and never hit a conflict. As I say, the hvr-2200 works really well. When I put the hvr-1110 in (and install the non-free firmware linked above), the hvr-1110 registers as an adapter and plays TV well as well. Unfortunately, when I have both cards in with their firmware, the hvr-1110 stops the hvr-2220 registering its two adapters. Dmesg is attached to my Launchpad bug here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/621578 I have now (before reporting the bug) removed the hvr-1110 so that I am back to my working dual-tuner hvr-2200 configuration. Interestingly to me, when I only have the hvr-2200 firmware installed, but with both cards in the machine, all three adapters register (create /dev/dvb/ nodes), but clearly only the hvr-2200 adapters actually work. Any suggestions would be greatly appreciated. I saw some things in dmesg about IRQ conflicts, but I really have no idea. Regards, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hauppauge hvr-2200 stops working when Hauppauge hvr-1110 is connected
Hello, I am using Mythbuntu 10.04 and have linux-firmware-nonfree from: https://bugs.launchpad.net/ubuntu/+source/linux-firmware-nonfree/+bug/579783 I have been happily using Mythbuntu with a Hauppauge hvr-2200 dual tuner DVB-T for many months (thanks Steven Toth!) and it records all my TV in MythTV. NZ has three DVB-T multiplexes, so I bought a second single-tuner DVB-T card, a Hauppauge hvr-1110, to cover the third multiplex and mean that, with multirec, I can record all channels and never hit a conflict. As I say, the hvr-2200 works really well. When I put the hvr-1110 in (and install the non-free firmware linked above), the hvr-1110 registers as an adapter and plays TV well as well. Unfortunately, when I have both cards in with their firmware, the hvr-1110 stops the hvr-2220 registering its two adapters. Dmesg is attached to my Launchpad bug here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/621578 I have now (before reporting the bug) removed the hvr-1110 so that I am back to my working dual-tuner hvr-2200 configuration. Interestingly to me, when I only have the hvr-2200 firmware installed, but with both cards in the machine, all three adapters register (create /dev/dvb/ nodes), but clearly only the hvr-2200 adapters actually work. Any suggestions would be greatly appreciated. I saw some things in dmesg about IRQ conflicts, but I really have no idea. Regards, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Twinhan DST stops working under latest v4l-dvb
It seems the latest v4l-dvb causes issues with my Twinhan 1020 bttv: driver version 0.9.17 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). ACPI: PCI Interrupt :05:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18 bttv0: Bt878 (rev 17) at :05:08.0, irq: 18, latency: 32, mmio: 0xcb00 bttv0: using: Twinhan DST + clones [card=113,insmod option] bttv0: gpio: en=, out= in=00fefffe [init] bttv0: tuner absent bttv0: add subdevice "dvb0" bt878: AUDIO driver version 0.0.0 loaded dvb_bt8xx: unable to determine DMA core of card 0, dvb_bt8xx: if you have the ALSA bt87x audio driver installed, try removing it. dvb-bt8xx: probe of dvb0 failed with error -14 i tried unloading all the sound modules made no difference (even though i didnt have the bt87x module loaded) This card works on earlier kernel modules. Any ideas? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel soft lockup on boot loading cx2388x based DVB-S card (TeVii S420)
Horay my TeVii DVB-S S420 is now working, only thing now is to work out why it wont load on boot before my DVB-T card On 16/01/2009 3:19 PM, Aaron Theodore wrote: I tried: make rmmod make rminstall Although there were still some drivers left over from "tevii_linuxdriver_0815" /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/dvb-usb/dvb-usb-s600.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/dvb-usb/dvb-usb-s650.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36067.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36060.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36050.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/saa7134/saa7134-oss.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36016.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/tuner-3036.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/videocodec.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/dpc7146.ko so i just removed manually and rebooted. Same issue occurred on reboot. So i thought to try manually unloading and reloading the module barry:~# rmmod cx8802 barry:~# modprobe cx8802 kernel: cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded kernel: cx88[0]/2: cx2388x 8802 Driver Manager kernel: ACPI: PCI Interrupt :05:08.2[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18 kernel: cx88[0]/2: found at :05:08.2, rev: 5, irq: 18, latency: 32, mmio: 0xd900 kernel: cx88/2: cx2388x dvb driver version 0.0.6 loaded kernel: cx88/2: registering cx8802 driver, type: dvb access: shared kernel: cx88[0]/2: subsystem: d420:9022, board: TeVii S420 DVB-S [card=73] kernel: cx88[0]/2: cx2388x based DVB/ATSC card kernel: cx8802_alloc_frontends() allocating 1 frontend(s) kernel: DVB: registering new adapter (cx88[0]) kernel: DVB: registering adapter 2 frontend 0 (ST STV0288 DVB-S)... This time it makes the devices in /dev/dvb/ Now unfortunately i can't test to see if it can actually Tune until a few hours time when i get home (i think i forgot to plug my satellite cable back in!) Will report back later Can i change the load order of kernel modules, it dosnt seem to like being loaded before my other dvb modules Aaron - "Mauro Carvalho Chehab" wrote: On Fri, 16 Jan 2009 06:56:05 +1100 Aaron Theodore wrote: Mauro, Thanks for the speedy patch! You should thanks to Andy. He is the author of this patch ;) My system can at least boot now, but has issues loading the frontend. DVB: Unable to find symbol stv0299_attach() DVB: Unable to find symbol stv0288_attach() It seems that you didn't compile those two frontends. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel soft lockup on boot loading cx2388x based DVB-S card (TeVii S420)
I tried: make rmmod make rminstall Although there were still some drivers left over from "tevii_linuxdriver_0815" /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/dvb-usb/dvb-usb-s600.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/dvb-usb/dvb-usb-s650.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36067.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36060.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36050.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/saa7134/saa7134-oss.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36016.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/tuner-3036.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/videocodec.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/dpc7146.ko so i just removed manually and rebooted. Same issue occurred on reboot. So i thought to try manually unloading and reloading the module barry:~# rmmod cx8802 barry:~# modprobe cx8802 kernel: cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded kernel: cx88[0]/2: cx2388x 8802 Driver Manager kernel: ACPI: PCI Interrupt :05:08.2[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18 kernel: cx88[0]/2: found at :05:08.2, rev: 5, irq: 18, latency: 32, mmio: 0xd900 kernel: cx88/2: cx2388x dvb driver version 0.0.6 loaded kernel: cx88/2: registering cx8802 driver, type: dvb access: shared kernel: cx88[0]/2: subsystem: d420:9022, board: TeVii S420 DVB-S [card=73] kernel: cx88[0]/2: cx2388x based DVB/ATSC card kernel: cx8802_alloc_frontends() allocating 1 frontend(s) kernel: DVB: registering new adapter (cx88[0]) kernel: DVB: registering adapter 2 frontend 0 (ST STV0288 DVB-S)... This time it makes the devices in /dev/dvb/ Now unfortunately i can't test to see if it can actually Tune until a few hours time when i get home (i think i forgot to plug my satellite cable back in!) Will report back later Can i change the load order of kernel modules, it dosnt seem to like being loaded before my other dvb modules Aaron - "Mauro Carvalho Chehab" wrote: > On Fri, 16 Jan 2009 06:56:05 +1100 > Aaron Theodore wrote: > > > Mauro, > > > > Thanks for the speedy patch! > > You should thanks to Andy. He is the author of this patch ;) > > > My system can at least boot now, but has issues loading the > frontend. > > DVB: Unable to find symbol stv0299_attach() > > DVB: Unable to find symbol stv0288_attach() > > It seems that you didn't compile those two frontends. > > Cheers, > Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel soft lockup on boot loading cx2388x based DVB-S card (TeVii S420)
Mauro, Thanks for the speedy patch! My system can at least boot now, but has issues loading the frontend. Linux video capture interface: v2.00 cx88/0: cx2388x v4l2 driver version 0.0.6 loaded ACPI: PCI Interrupt :05:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18 cx88[0]: subsystem: d420:9022, board: TeVii S420 DVB-S [card=73,autodetected], frontend(s): 1 cx88[0]: TV tuner type -1, Radio tuner type -1 cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded tuner' 2-0068: chip found @ 0xd0 (cx88[0]) cx88[0]/0: found at :05:08.0, rev: 5, irq: 18, latency: 32, mmio: 0xd800 cx88[0]/0: registered device video0 [v4l2] cx88[0]/0: registered device vbi0 tuner' 2-0068: tuner type not set cx88[0]/2: cx2388x 8802 Driver Manager ACPI: PCI Interrupt :05:08.2[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18 cx88[0]/2: found at :05:08.2, rev: 5, irq: 18, latency: 32, mmio: 0xd900 ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 22 ACPI: PCI Interrupt :00:04.0[A] -> Link [APCJ] -> GSI 22 (level, low) -> IRQ 17 PCI: Setting latency timer of device :00:04.0 to 64 cx88/2: cx2388x dvb driver version 0.0.6 loaded cx88/2: registering cx8802 driver, type: dvb access: shared cx88[0]/2: subsystem: d420:9022, board: TeVii S420 DVB-S [card=73] cx88[0]/2: cx2388x based DVB/ATSC card cx8802_alloc_frontends() allocating 1 frontend(s) DVB: Unable to find symbol stv0299_attach() DVB: Unable to find symbol stv0288_attach() cx88[0]/2: frontend initialization failed cx88[0]/2: dvb_register failed (err = -22) cx88[0]/2: cx8802 probe failed, err = -22 thanks Aaron On 16/01/2009 2:55 AM, Mauro Carvalho Chehab wrote: On Thu, 15 Jan 2009 11:25:38 + "Alec Christie" wrote: I am getting the same with the Haupauge HVR-4000 after a recent Kernel Upgrade in Ubuntu Hardy (8.04). Any help greatly appreciated. Alec Christie 2009/1/15 Aaron Theodore Hi I'm running Debian with kernel: 2.6.24-etchnhalf.1-686 I recently baught a TeVii S420 DVB-S card and have been tring to get it to work. Firstly i built the v4l from: http://linuxtv.org/hg/v4l-dvb (hg clone) as the card was not detected. On first reboot after new modules are installed i get a kernel soft lockup cx88[0]/2: cx2388x based DVB/ATSC card BUG: soft lockup - CPU#0 stuck for 11s! [modprobe:1767] I just merged on http://linuxtv.org/hg/v4l-dvb a patch for fixing this bug. Please test. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
kernel soft lockup on boot loading cx2388x based DVB-S card (TeVii S420)
Hi I'm running Debian with kernel: 2.6.24-etchnhalf.1-686 I recently baught a TeVii S420 DVB-S card and have been tring to get it to work. Firstly i built the v4l from: http://linuxtv.org/hg/v4l-dvb (hg clone) as the card was not detected. On first reboot after new modules are installed i get a kernel soft lockup - Linux video capture interface: v2.00 cx88/0: cx2388x v4l2 driver version 0.0.6 loaded ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18 ACPI: PCI Interrupt :05:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 21 cx88[0]: subsystem: d420:9022, board: TeVii S420 DVB-S [card=73,autodetected], frontend(s): 1 cx88[0]: TV tuner type -1, Radio tuner type -1 cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded tuner' 2-0068: chip found @ 0xd0 (cx88[0]) cx88[0]/0: found at :05:08.0, rev: 5, irq: 21, latency: 32, mmio: 0xd800 cx88[0]/0: registered device video0 [v4l2] cx88[0]/0: registered device vbi0 tuner' 2-0068: tuner type not set cx88[0]/2: cx2388x 8802 Driver Manager ACPI: PCI Interrupt :05:08.2[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 21 cx88[0]/2: found at :05:08.2, rev: 5, irq: 21, latency: 32, mmio: 0xd900 ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 22 ACPI: PCI Interrupt :00:04.0[A] -> Link [APCJ] -> GSI 22 (level, low) -> IRQ 17 cx88/2: cx2388x dvb driver version 0.0.6 loaded cx88/2: registering cx8802 driver, type: dvb access: shared cx88[0]/2: subsystem: d420:9022, board: TeVii S420 DVB-S [card=73] cx88[0]/2: cx2388x based DVB/ATSC card BUG: soft lockup - CPU#0 stuck for 11s! [modprobe:1767] Pid: 1767, comm: modprobe Not tainted (2.6.24-etchnhalf.1-686 #1) EIP: 0060:[] EFLAGS: 0286 CPU: 0 EIP is at _spin_lock+0x7/0xf EAX: [removed] ESI: [removed] DS: [removed] CR0: [removed] DR0: [removed] DR6: [removed] [] __mutex_lock_slowpath+0x17/0x7f [] sched_clock+0x8/0x18 [] mutex_lock+0xa/0xb [] videobuf_dvb_get_frontend+0x11/0x37 [videobuf_dvb] [] cx8802_dvb_probe+0xef/0x1a15 [cx88_dvb] [] check_preempt_wakeup+0x1e/0x7a [] cx8802_register_driver+0x128/0x1e3 [ex8802] [] sys_int_module+0x15e3/0x16fb [] vma_prio_tree_insert+0x17/0x2a [] msleep+0x0/0x12 [] sysenter_past_esp+0x6b/0xa1 == Only way i can boot my system is to remove the PCI card. So then i tried using the drivers from TeVii ( http://www.tevii.com/Tevii_linuxdriver_0815.rar ) These actually work but are based on what seems to be a v4l-dvb checkout from 2008-08-14. I can't use these old drivers because they conflict with other v4l-dvb modules i want to load for other tuner cards. Is there someway i can get the TeVii S420 working on the latest v4l-dvb modules? Also using the old drivers, just the following happens on boot --- cx88[0]/2: subsystem: d420:9022, board: TeVii S420 DVB-S [card=73] cx88[0]/2: cx2388x based DVB/ATSC card intel8x0_measure_ac97_clock: measured 54726 usecs intel8x0: clocking to 46908 stv0288 id 11 DVB: registering new adapter (cx88[0]) DVB: registering frontend 0 (ST STV0288 DVB-S)... --- Could this perhaps be an issue with the intel8x0 module? - -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
