Re: [PATCH 3/3] sh: add Video Output Unit (VOU) and AK8813 TV-encoder support to ms7724se
On Thu, Mar 11, 2010 at 02:45:00PM +0100, Guennadi Liakhovetski wrote: Add platform bindings, GPIO initialisation and allocation and AK8813 reset code to ms7724se. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Obviously depends on the previous two VOU and AK881x patches, sorry for not marking those with PATCH x/3 accordingly. Those two patches do not depend upon each other and initially I wasn't sure I'd be able to clean up this patch sufficiently for submission. Two 10us delays are pretty random, maybe they can be optimised out completely. I just tried to reproduced the reset procedure from the ak8813 datasheet, and it says nothing about the duration of respective stages. arch/sh/boards/mach-se/7724/setup.c | 88 --- 1 files changed, 81 insertions(+), 7 deletions(-) Now that the other two patches are upstream, I've applied this. -- 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: [PATCH] SH: add Video Output Unit and AK8813 video encoder support on ecovec
On Wed, Apr 21, 2010 at 10:45:25AM +0200, Guennadi Liakhovetski wrote: Ecovec uses the AK8813 video envoder similarly to the ms7724se platform with the only difference, that on ecovec GPIOs are used for resetting and powering up and down the chip. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- This patch extends the SuperH VOU / AK881x patch series: http://thread.gmane.org/gmane.linux.ports.sh.devel/7751/focus=7753 arch/sh/boards/mach-ecovec24/setup.c | 78 ++ 1 files changed, 78 insertions(+), 0 deletions(-) Applied, thanks. -- 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
[PATCH 9/27] drivers/media: Use memdup_user
From: Julia Lawall ju...@diku.dk
Use memdup_user when user data is immediately copied into the
allocated region.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
expression from,to,size,flag;
position p;
identifier l1,l2;
@@
- to = \(kmal...@p\|kzal...@p\)(size,flag);
+ to = memdup_user(from,size);
if (
- to==NULL
+ IS_ERR(to)
|| ...) {
+... when != goto l1;
- -ENOMEM
+ PTR_ERR(to)
...+
}
- if (copy_from_user(to, from, size) != 0) {
-+... when != goto l2;
--EFAULT
-...+
- }
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
drivers/media/dvb/dvb-core/dvb_demux.c | 10 +++---
drivers/media/video/dabusb.c | 13 -
2 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_demux.c
b/drivers/media/dvb/dvb-core/dvb_demux.c
index 977ddba..4a88a3e 100644
--- a/drivers/media/dvb/dvb-core/dvb_demux.c
+++ b/drivers/media/dvb/dvb-core/dvb_demux.c
@@ -1130,13 +1130,9 @@ static int dvbdmx_write(struct dmx_demux *demux, const
char __user *buf, size_t
if ((!demux-frontend) || (demux-frontend-source != DMX_MEMORY_FE))
return -EINVAL;
- p = kmalloc(count, GFP_USER);
- if (!p)
- return -ENOMEM;
- if (copy_from_user(p, buf, count)) {
- kfree(p);
- return -EFAULT;
- }
+ p = memdup_user(buf, count);
+ if (IS_ERR(p))
+ return PTR_ERR(p);
if (mutex_lock_interruptible(dvbdemux-mutex)) {
kfree(p);
return -ERESTARTSYS;
diff --git a/drivers/media/video/dabusb.c b/drivers/media/video/dabusb.c
index 0f50508..5b176bd 100644
--- a/drivers/media/video/dabusb.c
+++ b/drivers/media/video/dabusb.c
@@ -706,16 +706,11 @@ static long dabusb_ioctl (struct file *file, unsigned int
cmd, unsigned long arg
switch (cmd) {
case IOCTL_DAB_BULK:
- pbulk = kmalloc(sizeof (bulk_transfer_t), GFP_KERNEL);
+ pbulk = memdup_user((void __user *)arg,
+ sizeof(bulk_transfer_t));
- if (!pbulk) {
- ret = -ENOMEM;
- break;
- }
-
- if (copy_from_user (pbulk, (void __user *) arg, sizeof
(bulk_transfer_t))) {
- ret = -EFAULT;
- kfree (pbulk);
+ if (IS_ERR(pbulk)) {
+ ret = PTR_ERR(pbulk);
break;
}
--
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: Afatech 9035 + NXP 18291 = GT-U7200
Anyone? :-) Thanks On Sun, 2010-05-16 at 00:04 +0100, João Seabra wrote: Good evening, I have a gigabyte gt-u7200 but since it's new i believe there aren't any drivers available On the webpage http://www.gigabyte.com.tw/Products/TVCard/Products_Spec.aspx?ClassValue=TV+CardProductID=2875ProductName=GT-U7200 says it has a NXP18291 tuner and the decoder chip is Afatech 9035. All i found related to Afatech 9035 was this post from December 2008: http://www.linuxtv.org/pipermail/linux-dvb/2008-December/030923.html and the feature request in ubuntu : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/519544 I tried to compile the 9035 driver but it has no instructions and fails. Could someone give me some details if its simple/possible to have a driver for this usb pen? Kind Regards, João Seabra dmesg output: [ 115.175224] usbcore: registered new interface driver usbhid [ 115.175227] usbhid: v2.6:USB HID core driver [ 1967.463143] usb 2-1: USB disconnect, address 2 [ 6654.750267] usb 2-1: new high speed USB device using ehci_hcd and address 3 [ 6654.907301] usb 2-1: configuration #1 chosen from 1 choice [ 6654.914557] input: GIGABYTE Technologies Inc. U7200 USB TV Device as /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.1/input/input11 [ 6654.914771] generic-usb 0003:1044:7005.0002: input,hidraw0: USB HID v1.01 Keyboard [GIGABYTE Technologies Inc. U7200 USB TV Device] on usb-:00:1d.7-1/input1 lsusb -v: Bus 002 Device 003: ID 1044:7005 Chu Yuen Enterprise Co., Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1044 Chu Yuen Enterprise Co., Ltd idProduct 0x7005 bcdDevice2.00 iManufacturer 1 GIGABYTE Technologies Inc. iProduct2 U7200 USB TV Device iSerial 3 AF010202071 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 122 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 5 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 5 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface
Mystique SaTiX-S2 V2 CI Dual Mystique CI Interface f. Mystique SaTiX-S2 Dual
Hallo, I own the following cards: Mystique SaTiX-S2 V2 CI Dual Mystique CI Interface f. Mystique SaTiX-S2 Dual The Mystique SaTiX-S2 V2 CI Dual is working following the instructions on http://www.linuxtv.org/wiki/index.php/Mystique_SaTiX-S2_Dual and http://www.vdr-portal.de/board/thread.php?threadid=93616hilight=Mystique+SaTiX+S2+Dual The Mystique CI Interface f. Mystique SaTiX-S2 Dual isn't being recognized. Both are connected directly to each other. I even tested with the ci-interface connected, using the pcie bridge, directly to the motherboard. It only see the nGene pcie bridge but nothing else. If I can help in some way with testing the hardware, please let me know. I will not be a great help in programming, but I will help in any way I can. Greetings, Ronald. -- 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
VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs
Hi, As per the spec, the above ioctl codes are defined for inputs only - it would be useful if there were similar codes for outputs. I therefore propose to add the following: VIDIOC_G_OUTPUT_STD VIDIOC_S_OUTPUT_STD VIDIOC_ENUM_OUTPUT_STD which would behave similar to the above, but for output devices. Thoughts? Cheers, Andre' -- 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: VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs
On Sat, 2010-05-22 at 15:06 +0100, Andre Draszik wrote: Hi, As per the spec, the above ioctl codes are defined for inputs only - it would be useful if there were similar codes for outputs. I therefore propose to add the following: VIDIOC_G_OUTPUT_STD VIDIOC_S_OUTPUT_STD VIDIOC_ENUM_OUTPUT_STD which would behave similar to the above, but for output devices. Thoughts? Currently the ivtv driver, for the PVR-350's output, uses VIDIOC_S_STD. From what I see: ivtv/ioctl.c zoran/zoran_driver.c davinci/vpif_display.c all use VIDIOC_S_STD for setting the output standard. Note that the v4l2_subdev video_ops have a s_std_output method which is what you can grep for in the code to verify for yourself. Some thoughts: 1. to me it appears that the ivtv driver looks like it ties the output standard to the input standard currently (probably due to some firmware limitation). This need not be the case in general. 2. currently the ivtv driver uses sepearte device nodes for input device and an output device. If bridge drivers maintain that paradigm, then separate ioctl()s for S_STD, G_STD, and ENUMSTD are likely not needed. 3. ENUMSTD is currently handled by the v4l2 core in v4l2-ioctl.c with no hook for bridge drivers. The bridge drivers were all getting it wrong in some way or another for enumerating stanadrds on the input. 4. What's the harm in letting S_STD fail for an unsupported standard on an output? An application usually doesn't have much choice but to fail, if the hardware doesn't support the user's desired standard. ENUMSTD_OUTPUT for outputs seems superfulous. If you had an ENUM_STD_OUTPUT ioctl() to call, an application will either find the desired standard in the list and know S_STD should succeed, or it won't an will assume S_STD will fail. From an application writing perspective, it seems like less work for the application to just detect when S_STD fails. Regards, Andy -- 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
Fwd: cx18 module not loading
It was suggested at ivtv-users that this be reported to this list. Please let me know if I can provide some more information, or if there is something that will help my problem. Thanks, Jeff -- Forwarded message -- From: J McBride mcbride...@gmail.com Date: Sat, May 22, 2010 at 11:17 AM Subject: cx18 module not loading To: ivtv-us...@ivtvdriver.org I have attempted to get a Hauppauge HTV-1600 card working in SimpyMepis. I have generally followed the steps in the following how-to guides: http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers and http://ivtvdriver.org/index.php/Howto:Debian I had to run make config and not configure the FireTV due to a compilation error, then all seemed to work well until the command: #modprobe cx18 which resulted in the error: FATAL: Error inserting cx18 (/lib/modules/2.6.32-1-mepis64-smp/kernel/drivers/media/video/cx18/cx18.ko): Unknown symbol in module, or unknown parameter (see dmesg) Then I did: dmesg |grep cx18 cx18: Unknown symbol ir_codes_hauppauge_new_table So, I am at my limit here. I cannot find any similar errors through google. Any suggestions on how I get this to work? Thanks, Jeff -- 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
[PATCH 04/12] V4L/DVB: ngene: remove unused #include linux/version.h
Remove unused #include linux/version.h('s) in
drivers/media/dvb/ngene/ngene-dvb.c
drivers/media/dvb/ngene/ngene-i2c.c
Signed-off-by: Huang Weiyi weiyi.hu...@gmail.com
---
drivers/media/dvb/ngene/ngene-dvb.c |1 -
drivers/media/dvb/ngene/ngene-i2c.c |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-dvb.c
b/drivers/media/dvb/ngene/ngene-dvb.c
index 96013eb..e5ec893 100644
--- a/drivers/media/dvb/ngene/ngene-dvb.c
+++ b/drivers/media/dvb/ngene/ngene-dvb.c
@@ -37,7 +37,6 @@
#include linux/pci.h
#include linux/smp_lock.h
#include linux/timer.h
-#include linux/version.h
#include linux/byteorder/generic.h
#include linux/firmware.h
#include linux/vmalloc.h
diff --git a/drivers/media/dvb/ngene/ngene-i2c.c
b/drivers/media/dvb/ngene/ngene-i2c.c
index 2ef54ca..477fe0a 100644
--- a/drivers/media/dvb/ngene/ngene-i2c.c
+++ b/drivers/media/dvb/ngene/ngene-i2c.c
@@ -39,7 +39,6 @@
#include linux/pci_ids.h
#include linux/smp_lock.h
#include linux/timer.h
-#include linux/version.h
#include linux/byteorder/generic.h
#include linux/firmware.h
#include linux/vmalloc.h
--
1.6.1.3
--
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: VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs
On Saturday 22 May 2010, Andy Walls wrote: On Sat, 2010-05-22 at 15:06 +0100, Andre Draszik wrote: Hi, As per the spec, the above ioctl codes are defined for inputs only - it would be useful if there were similar codes for outputs. I therefore propose to add the following: VIDIOC_G_OUTPUT_STD VIDIOC_S_OUTPUT_STD VIDIOC_ENUM_OUTPUT_STD which would behave similar to the above, but for output devices. Thoughts? Currently the ivtv driver, for the PVR-350's output, uses VIDIOC_S_STD. From what I see: ivtv/ioctl.c zoran/zoran_driver.c davinci/vpif_display.c all use VIDIOC_S_STD for setting the output standard. Note that the v4l2_subdev video_ops have a s_std_output method which is what you can grep for in the code to verify for yourself. Some thoughts: 1. to me it appears that the ivtv driver looks like it ties the output standard to the input standard currently (probably due to some firmware limitation). This need not be the case in general. The ivtv limitation is the driver and not the firmware. The firmware itself seems quite happy with mixed standards in some cases will automatically switch the output standard itself (resulting in a standards mismatch between the cx23415 saa7127, breaking output). For the previous 2 months I've been running a patched version of the ivtv driver that separates the input output format with no noticeable issues. 2. currently the ivtv driver uses sepearte device nodes for input device and an output device. If bridge drivers maintain that paradigm, then separate ioctl()s for S_STD, G_STD, and ENUMSTD are likely not needed. This is how my patched version works, talk to an input device for the input an output device for the output. However, from my reading of the specs I do get the impression this is not the 'correct' way to do this and it should really be a separate ioctl. I don't know what other cards, if any, support mixed input output standards or how they handle it. -- Ian -- 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
[patch] em28xx: remove unneeded null checks
The dev variable is used as a list cursor in a list_for_each_entry()
loop and can never be null here so I removed the check.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/em28xx/em28xx-core.c
b/drivers/media/video/em28xx/em28xx-core.c
index 331e1ca..44c63cb 100644
--- a/drivers/media/video/em28xx/em28xx-core.c
+++ b/drivers/media/video/em28xx/em28xx-core.c
@@ -1186,8 +1186,7 @@ int em28xx_register_extension(struct em28xx_ops *ops)
mutex_lock(em28xx_devlist_mutex);
list_add_tail(ops-next, em28xx_extension_devlist);
list_for_each_entry(dev, em28xx_devlist, devlist) {
- if (dev)
- ops-init(dev);
+ ops-init(dev);
}
printk(KERN_INFO Em28xx: Initialized (%s) extension\n, ops-name);
mutex_unlock(em28xx_devlist_mutex);
@@ -1201,10 +1200,8 @@ void em28xx_unregister_extension(struct em28xx_ops *ops)
mutex_lock(em28xx_devlist_mutex);
list_for_each_entry(dev, em28xx_devlist, devlist) {
- if (dev)
- ops-fini(dev);
+ ops-fini(dev);
}
-
printk(KERN_INFO Em28xx: Removed (%s) extension\n, ops-name);
list_del(ops-next);
mutex_unlock(em28xx_devlist_mutex);
--
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
[patch] video/saa7134: potential null dereferences in debug code
I modified the dprintk and i2cdprintk macros to handle null dev and ir pointers. There are two couple places that call dprintk() when dev is null. One is in get_key_msi_tvanywhere_plus() and the other is in get_key_flydvb_trio(). Signed-off-by: Dan Carpenter erro...@gmail.com diff --git a/drivers/media/video/saa7134/saa7134-input.c b/drivers/media/video/saa7134/saa7134-input.c index e5565e2..e14f2f8 100644 --- a/drivers/media/video/saa7134/saa7134-input.c +++ b/drivers/media/video/saa7134/saa7134-input.c @@ -61,9 +61,9 @@ MODULE_PARM_DESC(disable_other_ir, disable full codes of alternative remotes from other manufacturers); #define dprintk(fmt, arg...) if (ir_debug) \ - printk(KERN_DEBUG %s/ir: fmt, dev-name , ## arg) + printk(KERN_DEBUG %s/ir: fmt, dev ? dev-name : null, ## arg) #define i2cdprintk(fmt, arg...)if (ir_debug) \ - printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg) + printk(KERN_DEBUG %s/ir: fmt, ir ? ir-name : null, ## arg) /* Helper functions for RC5 and NEC decoding at GPIO16 or GPIO18 */ static int saa7134_rc5_irq(struct saa7134_dev *dev); -- 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: [patch] video/saa7134: potential null dereferences in debug code
Hi Dan, On Sat, 22 May 2010 22:15:35 +0200, Dan Carpenter wrote: I modified the dprintk and i2cdprintk macros to handle null dev and ir pointers. There are two couple places that call dprintk() when dev is null. One is in get_key_msi_tvanywhere_plus() and the other is in get_key_flydvb_trio(). Signed-off-by: Dan Carpenter erro...@gmail.com diff --git a/drivers/media/video/saa7134/saa7134-input.c b/drivers/media/video/saa7134/saa7134-input.c index e5565e2..e14f2f8 100644 --- a/drivers/media/video/saa7134/saa7134-input.c +++ b/drivers/media/video/saa7134/saa7134-input.c @@ -61,9 +61,9 @@ MODULE_PARM_DESC(disable_other_ir, disable full codes of alternative remotes from other manufacturers); #define dprintk(fmt, arg...) if (ir_debug) \ - printk(KERN_DEBUG %s/ir: fmt, dev-name , ## arg) + printk(KERN_DEBUG %s/ir: fmt, dev ? dev-name : null, ## arg) #define i2cdprintk(fmt, arg...)if (ir_debug) \ - printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg) + printk(KERN_DEBUG %s/ir: fmt, ir ? ir-name : null, ## arg) /* Helper functions for RC5 and NEC decoding at GPIO16 or GPIO18 */ static int saa7134_rc5_irq(struct saa7134_dev *dev); I would have used (null) instead of null for consistency with lib/vsprintf.c:string(). But more importantly, I suspect that a better fix would be to not call these macros when dev or ir, respectively, is NULL. The faulty dprintk calls in get_key_msi_tvanywhere_plus() and get_key_flydvb_trio() could be replaced with i2cdprintk (which is misnamed IMHO, BTW.) -- Jean Delvare -- 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 oops with TT S2-3200
I'm running debian testing on an AMD Sempron box, kernel 2.6.32-3amd64, with a TT S2-3200. I've been setting the box up as a Myth TV backend. The stock kernel drivers for the S2-3200 appear to work (to the extent that I was able to scan for channels in Myth TV) however I was getting errors during channel scan (fec_inner not supported in the mythtv log) so I updated to v4l-dvb tip to see if this error disappeared. I now get a kernel oops on loading budget_ci as below. This is changeset 14873:b576509ea6d2. I see on the wiki that there is an hg bisect utility that I can use to narrow down where this has been introduced. Would it be useful I do so? Would any more information be useful? May 22 23:19:31 beta kernel: [ 98.394646] IR NEC protocol handler initialized May 22 23:19:31 beta kernel: [ 98.394857] saa7146: register extension 'budget_ci dvb'. May 22 23:19:31 beta kernel: [ 98.394966] budget_ci dvb :04:05.0: PCI INT A - GSI 20 (level, low) - IRQ 20 May 22 23:19:31 beta kernel: [ 98.395020] IRQ 20/: IRQF_DISABLED is not guaranteed on shared IRQs May 22 23:19:31 beta kernel: [ 98.395055] saa7146: found saa7146 @ mem c900116f8c00 (revision 1, irq 20) (0x13c2,0x1019). May 22 23:19:31 beta kernel: [ 98.395069] saa7146 (0): dma buffer size 192512 May 22 23:19:31 beta kernel: [ 98.395074] DVB: registering new adapter (TT-Budget S2-3200 PCI) May 22 23:19:31 beta kernel: [ 98.399843] IR RC5(x) protocol handler initialized May 22 23:19:31 beta kernel: [ 98.404301] IR RC6 protocol handler initialized May 22 23:19:31 beta kernel: [ 98.408724] IR JVC protocol handler initialized May 22 23:19:31 beta kernel: [ 98.413024] IR Sony protocol handler initialized May 22 23:19:31 beta kernel: [ 98.429164] adapter has MAC addr = 00:d0:5c:68:2c:ca May 22 23:19:31 beta kernel: [ 98.468015] Registered IR keymap rc-budget-ci-old May 22 23:19:31 beta kernel: [ 98.468261] PGD 0 May 22 23:19:31 beta kernel: [ 98.468479] CPU 0 May 22 23:19:31 beta kernel: [ 98.468549] Modules linked in: rc_budget_ci_old ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder budget_ci(+) ir_core budget_core ttpci_eeprom dvb_core saa7146 cryptd aes_x86_64 aes_generic xt_mac xt_TCPMSS xt_tcpudp ipt_LOG iptable_raw xt_conntrack xt_comment iptable_nat nf_nat xt_MARK ipt_REJECT ipt_addrtype xt_multiport iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables fuse nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc pppoatm ppp_generic slhc powernow_k8 it87 hwmon_vid loop arc4 ecb ath9k ath9k_common mac80211 ath9k_hw ath snd_hda_codec_realtek amd64_edac_mod shpchp cfg80211 i2c_piix4 edac_core k10temp edac_mce_amd i2c_core pci_hotplug rfkill snd_hda_intel parport_pc led_class snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm evdev parport snd_timer snd soundcore snd_page_alloc speedtch usbatm pcspkr atm psmouse processor serio_raw ext3 jbd mbcache fan ide_gd_mod ata_generic May 22 23:19:31 beta kernel: ohci_hcd ide_pci_generic ahci libata atiixp button thermal thermal_sys r8169 mii ehci_hcd scsi_mod ide_core usbcore nls_base [last unloaded: scsi_wait_scan] May 22 23:19:31 beta kernel: [ 98.472002] Pid: 2746, comm: work_for_cpu Not tainted 2.6.32-3-amd64 #1 A760G M2+ May 22 23:19:31 beta kernel: [ 98.472002] RIP: 0010:[a068db7e] [a068db7e] ir_register_class+0x4d/0x18f [ir_core] May 22 23:19:31 beta kernel: [ 98.472002] RSP: 0018:88007cf67db0 EFLAGS: 00010246 May 22 23:19:31 beta kernel: [ 98.472002] RAX: RBX: 88007c1a5400 RCX: a068ee60 May 22 23:19:31 beta kernel: [ 98.472002] RDX: RSI: a068e94a RDI: 88007c1a5400 May 22 23:19:31 beta kernel: [ 98.472002] RBP: R08: R09: 0073 May 22 23:19:31 beta kernel: [ 98.472002] R10: R11: 00dc R12: a06c0060 May 22 23:19:31 beta kernel: [ 98.472002] R13: 88007cf4c000 R14: 0286 R15: a0698ed3 May 22 23:19:31 beta kernel: [ 98.472002] FS: 7f498d78c6f0() GS:88000180() knlGS: May 22 23:19:31 beta kernel: [ 98.472002] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b May 22 23:19:31 beta kernel: [ 98.472002] CR2: CR3: 01001000 CR4: 06f0 May 22 23:19:31 beta kernel: [ 98.472002] DR0: DR1: DR2: May 22 23:19:31 beta kernel: [ 98.472002] DR3: DR6: 0ff0 DR7: 0400 May 22 23:19:31 beta kernel: [ 98.472002] Process work_for_cpu (pid: 2746, threadinfo 88007cf66000, task 88007b67cdb0) May 22 23:19:31 beta kernel: [ 98.472002] 88007c1a5400 88007cf4c000 a06c0060 002d May 22 23:19:31 beta kernel: [ 98.472002] 0 0286 a068d9b6 0004
