[PATCH] cx88-dvb.c: DVB net latency using Hauppauge HVR4000
Hi linux-media developers, We are from School On Internet Asia (SOI Asia) project that uses satellite communication to deliver educational content. We used Hauppauge HVR 4000 to carry IP traffic over ULE. However, there is an issue with high latency jitter. My boss, Husni, identified the problem and provided a patch for this problem. We have tested this patch since kernel 2.6.30 on our partner sites and it hasn't cause any issue. The default buffer size of 32 TS frames on cx88 causes the high latency, so our deployment changes that to 6 TS frames. This patch made the buffer size tunable, while keeping the default buffer size of 32 TS frames unchanged. Sorry, I have to use attachment for the patch. I couldn't figure out how to copy and paste the patch without converting the tab to spaces in thunderbird. Signed-off-by: Achmad Husni Thamrin hu...@ai3.net diff --git a/drivers/media/video/cx88/cx88-dvb.c b/drivers/media/video/cx88/cx88-dvb.c index 367a653..90717ee 100644 --- a/drivers/media/video/cx88/cx88-dvb.c +++ b/drivers/media/video/cx88/cx88-dvb.c @@ -67,6 +67,10 @@ static unsigned int debug; module_param(debug, int, 0644); MODULE_PARM_DESC(debug,enable debug messages [dvb]); +static unsigned int dvb_buf_tscnt = 32; +module_param(dvb_buf_tscnt, int, 0644); +MODULE_PARM_DESC(dvb_buf_tscnt, DVB Buffer TS count [dvb]); + DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr); #define dprintk(level,fmt, arg...) if (debug = level) \ @@ -80,10 +84,10 @@ static int dvb_buf_setup(struct videobuf_queue *q, struct cx8802_dev *dev = q-priv_data; dev-ts_packet_size = 188 * 4; - dev-ts_packet_count = 32; + dev-ts_packet_count = dvb_buf_tscnt; *size = dev-ts_packet_size * dev-ts_packet_count; - *count = 32; + *count = dvb_buf_tscnt; return 0; }
(no subject)
unsubscribe linux-media -- 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: hvr4000 in general
That card definitely works on DVB-S2. The only problem I had with that card is its fragility. I have a few burnt HVR 4000 (lite) cards in the lab. Lars Schotte wrote: hi all hvr4000 friends i am wondering if someone has this card working a little more then I do. i have dvb-s working quite good. the only thing what I can say positively about thisc card is that it at least reports a better signal strength and also SNR. so it is possible that the part before the chipset from the viewpoint of the signal arriving from space it may have a better tuner. but so far ... has someone dvb-s2 working? (on linux/not freebsd!!) -- 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: hvr4000 in general
Lars Schotte wrote: yes? it works definitely? and how is that? again, I need something to see and as long as it doesnt tune in and as long as no data is flowing i can NOT see how it could be working. Definitely works using szap-s2. Tuning works and so is the data. I don't have access to the system right now. what fragility do you mean? did she burned out/ overheating, or what kind of fragility? One of the chip on the board got burned for all the burnt cards. On Sun, 06 Jun 2010 16:30:31 +0800 Ang Way Chuang wcan...@gmail.com wrote: That card definitely works on DVB-S2. The only problem I had with that card is its fragility. I have a few burnt HVR 4000 (lite) cards in the lab. Lars Schotte wrote: hi all hvr4000 friends i am wondering if someone has this card working a little more then I do. i have dvb-s working quite good. the only thing what I can say positively about thisc card is that it at least reports a better signal strength and also SNR. so it is possible that the part before the chipset from the viewpoint of the signal arriving from space it may have a better tuner. but so far ... has someone dvb-s2 working? (on linux/not freebsd!!) -- 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
[PATCH] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.
This patch was generated and tested against the latest Linus's pre
2.6.35-rc1 tree.
Signed-off-by: Ang Way Chuang wc...@nav6.org
---
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index f6dac2b..6c3a8a0 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -351,6 +351,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
const u8 *ts, *ts_end, *from_where = NULL;
u8 ts_remain = 0, how_much = 0, new_ts = 1;
struct ethhdr *ethh = NULL;
+ bool error = false;
#ifdef ULE_DEBUG
/* The code inside ULE_DEBUG keeps a history of the last 100 TS cells
processed. */
@@ -460,10 +461,16 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
/* Drop partly decoded SNDU,
reset state, resync on PUSI. */
if (priv-ule_skb) {
- dev_kfree_skb(
priv-ule_skb );
+ error = true;
+
dev_kfree_skb(priv-ule_skb);
+ }
+
+ if (error ||
priv-ule_sndu_remain) {
dev-stats.rx_errors++;
dev-stats.rx_frame_errors++;
+ error = false;
}
+
reset_ule(priv);
priv-need_pusi = 1;
continue;
@@ -535,6 +542,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
from_where += 2;
}
+ priv-ule_sndu_remain = priv-ule_sndu_len + 2;
/*
* State of current TS:
* ts_remain (remaining bytes in the current TS cell)
@@ -544,6 +552,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
*/
switch (ts_remain) {
case 1:
+ priv-ule_sndu_remain--;
priv-ule_sndu_type = from_where[0]
8;
priv-ule_sndu_type_1 = 1; /* first
byte of ule_type is set. */
ts_remain -= 1; from_where += 1;
@@ -557,6 +566,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
default: /* complete ULE header is present in
current TS. */
/* Extract ULE type field. */
if (priv-ule_sndu_type_1) {
+ priv-ule_sndu_type_1 = 0;
priv-ule_sndu_type |=
from_where[0];
from_where += 1; /* points to
payload start. */
ts_remain -= 1;
--
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: dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
Jarod Wilson wrote: On Fri, May 21, 2010 at 11:40:34AM +0800, Ang Way Chuang wrote: Hi Jarod, Thanks for the review. My answers are inlined. Jarod Wilson wrote: On Thu, May 06, 2010 at 02:52:22PM -, Ang Way Chuang wrote: ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation code has a bug that incorrectly treats ULE SNDU packed into the remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer field on the subsequent MPEG2-TS frame. This patch was generated and tested against v2.6.34-rc6. I suspect that this bug was introduced in kernel version 2.6.15, but had not verified it. Care has been taken not to introduce more bug by fixing this bug, but please scrutinize the code because I always produces buggy code. ... @@ -534,6 +535,7 @@ static void dvb_net_ule( struct net_device *dev, const u8 *buf, size_t buf_len ) from_where += 2; } + priv-ule_sndu_remain = priv-ule_sndu_len + 2; /* * State of current TS: * ts_remain (remaining bytes in the current TS cell) Is this *always* true? Your description says ...the remaining 2 or 3 bytes, indicating this could sometimes need to be +3. Is +0 also a possibility? Not sure whether I understand your question correctly. Here is my attempt to answer your question. The encapsulation format always mandate that at least of 2 bytes of ULE SNDU (the LENGTH field) must be present within a MPEG2-TS frame. So, if only 1 byte of the ULE SNDU get packed into the remaining MPEG2-TS frame, then it is invalid. Of course, there is no issue regarding 0 byte as that would be the case of filling MPEG2-TS frame up to its boundary. New ULE SNDU will have to packed into the next MPEG2-TS frame in that case. Now the problem with existing code is the interpretation of remainder length when 2 or 3 bytes of ULE SNDU are packed into the remainder of MPEG2-TS frame. In the 2 bytes case, only the LENGTH field is available while in the case 3 bytes, only the 1st octet of the 2-octets TYPE field and the LENGTH field are available. The ule_sndu_remain should carry the value of length of ULE SNDU following the the TYPE field. Technically, this would mean that remainder byte of ULE SNDU that need to be received is going to be: Value(LENGTH) + 2 (We owe 2 bytes of TYPE field here) if only 2 bytes of ULE SNDU is packed (as in the case of case 0: at line 550). This is addressed by adding the priv-ule_sndu_remain = priv-ule_sndu_len + 2; Value(LENGTH) + 1 (We owe 1 byte of TYPE field here) if 3 bytes of ULE SNDU is packed (as in the case of case 1: at 545). This is addressed by adding priv-ule_sndu_remain--; If complete ULE header (= 4 bytes) is available: priv-ule_sndu_remain = priv-ule_sndu_len; at line 582 takes care of the rest and it works just fine in the existing code. Due to the wrong interpretation of remaining length of ULE SNDU when 2 or 3 bytes of ULE SNDU are packed into a MPEG2-TS frame, the subsequent checking of payload pointer (line 455) always fails leading to unnecessary packet drops. Looking back at the fix after a few months, I had trouble understanding how these few lines fixed the problem at first glance. Yeah, my question was whether or not the +2 would account for both the +2 bytes and +3 bytes situations, and it seems that's handled appropriately by the ts_remain switch. Thank you for the detailed explanation. If you'd alter that nested check for freeing the skb and give it a quick test, I'm happy to throw an acked-by or reviewed-by on a followup submission. Got it. Thank you. I shall get that patch to you next week because I'm not in the lab now. -- 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: dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
Hi Jarod,
Thanks for the review. My answers are inlined.
Jarod Wilson wrote:
On Thu, May 06, 2010 at 02:52:22PM -, Ang Way Chuang wrote:
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.
This patch was generated and tested against v2.6.34-rc6. I suspect
that this bug was introduced in kernel version 2.6.15, but had not
verified it.
Care has been taken not to introduce more bug by fixing this bug, but
please scrutinize the code because I always produces buggy code.
Signed-off-by: Ang Way Chuang wc...@nav6.org
---
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 441c064..35a4afb 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -458,8 +458,9 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
field: %u.\n,
priv-ts_count, *from_where);
/* Drop partly decoded SNDU,
reset state, resync on PUSI. */
- if (priv-ule_skb) {
- dev_kfree_skb(
priv-ule_skb );
+ if (priv-ule_skb ||
priv-ule_sndu_remain) {
+ if (priv-ule_skb)
+ dev_kfree_skb(
priv-ule_skb );
dev-stats.rx_errors++;
dev-stats.rx_frame_errors++;
}
That code block looks odd that way, but after staring at it for a minute,
it makes sense. Another way to do it that might read cleaner (and reduce
excessive tab indent levels) would be to add a 'bool errors', then:
bool errors = false;
...
if (priv-ule_skb) {
errors = true;
dev_kfree_skb(priv-ule_skb);
}
if (errors || priv-ule_sndu_remain) {
dev-stats.rx_errors++;
dev-stats.rx_frame_errors++;
}
Yeap, I'm a lazy person.
@@ -534,6 +535,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
from_where += 2;
}
+ priv-ule_sndu_remain = priv-ule_sndu_len + 2;
/*
* State of current TS:
* ts_remain (remaining bytes in the current TS cell)
Is this *always* true? Your description says ...the remaining 2 or 3
bytes, indicating this could sometimes need to be +3. Is +0 also a
possibility?
Not sure whether I understand your question correctly. Here is my attempt to answer your question.
The encapsulation format always mandate that at least of 2 bytes of ULE SNDU (the LENGTH field) must
be present within a MPEG2-TS frame. So, if only 1 byte of the ULE SNDU get packed into the
remaining MPEG2-TS frame, then it is invalid. Of course, there is no issue regarding 0 byte as that
would be the case of filling MPEG2-TS frame up to its boundary. New ULE SNDU will have to packed
into the next MPEG2-TS frame in that case.
Now the problem with existing code is the interpretation of remainder length when 2 or 3 bytes of ULE
SNDU are packed into the remainder of MPEG2-TS frame. In the 2 bytes case, only the LENGTH field is
available while in the case 3 bytes, only the 1st octet of the 2-octets TYPE field and the LENGTH field
are available. The ule_sndu_remain should carry the value of length of ULE SNDU following the the TYPE
field. Technically, this would mean that remainder byte of ULE SNDU that need to be received is going
to be:
Value(LENGTH) + 2 (We owe 2 bytes of TYPE field here) if only 2 bytes of ULE SNDU is packed (as in the
case of case 0: at line 550).
This is addressed by adding the priv-ule_sndu_remain = priv-ule_sndu_len + 2;
Value(LENGTH) + 1 (We owe 1 byte of TYPE field here) if 3 bytes of ULE SNDU is packed (as in the case of
case 1: at 545).
This is addressed by adding priv-ule_sndu_remain--;
If complete ULE header (= 4 bytes) is available:
priv-ule_sndu_remain = priv-ule_sndu_len; at line 582 takes care of the rest and it works just fine in
the existing code.
Due to the wrong interpretation of remaining length of ULE SNDU when 2 or 3 bytes of ULE SNDU are packed
into a MPEG2-TS frame, the subsequent checking of payload pointer (line 455) always fails leading to
unnecessary packet drops.
Looking back at the fix after a few months, I had trouble understanding how these few lines fixed the
problem at first glance.
@@ -543,6
Re: [GIT PULL for 2.6.35] V4L/DVB updates
Hi Mauro/Linux DVB developers, Can someone please review the following patch asap? https://patchwork.kernel.org/patch/97358/ I may not have access to the testbed for long because I'm leaving my university soon. I had been using the fix introduced through this patch on my testbed since 2.6.32 and had not experienced any issue of dropped packets yet. If there is any problem with this patch, I can follow up while I'm still here. I would like take this opportunity to express my gratitude towards Linux DVB developers. Without you guys, I won't have any platform for my research. Thanks a lot. Regards, Ang Way Chuang -- 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
this is a test mail
Please ignore this email. why can't i get my email through linux media mailing list when i can receive it? -- 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] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.
This patch was generated and tested against v2.6.34-rc6. I suspect
that this bug was introduced in kernel version 2.6.15, but had not
verified it.
Care has been taken not to introduce more bug by fixing this bug, but
please scrutinize the code because I always produces buggy code.
Signed-off-by: Ang Way Chuang wc...@nav6.org
---
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 441c064..35a4afb 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -458,8 +458,9 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
field: %u.\n,
priv-ts_count, *from_where);
/* Drop partly decoded SNDU,
reset state, resync on PUSI. */
- if (priv-ule_skb) {
- dev_kfree_skb(
priv-ule_skb );
+ if (priv-ule_skb ||
priv-ule_sndu_remain) {
+ if (priv-ule_skb)
+ dev_kfree_skb(
priv-ule_skb );
dev-stats.rx_errors++;
dev-stats.rx_frame_errors++;
}
@@ -534,6 +535,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
from_where += 2;
}
+ priv-ule_sndu_remain = priv-ule_sndu_len + 2;
/*
* State of current TS:
* ts_remain (remaining bytes in the current TS cell)
@@ -543,6 +545,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
*/
switch (ts_remain) {
case 1:
+ priv-ule_sndu_remain--;
priv-ule_sndu_type = from_where[0]
8;
priv-ule_sndu_type_1 = 1; /* first
byte of ule_type is set. */
ts_remain -= 1; from_where += 1;
@@ -556,6 +559,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
default: /* complete ULE header is present in
current TS. */
/* Extract ULE type field. */
if (priv-ule_sndu_type_1) {
+ priv-ule_sndu_type_1 = 0;
priv-ule_sndu_type |=
from_where[0];
from_where += 1; /* points to
payload start. */
ts_remain -= 1;
--
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: this is a test mail
That's weird. You can receive my email, yet I don't receive my email from the mailing list. Does that mean my patch went through as well? Jed wrote: Try sending via your ISP's SMTP host instead of Google's. I had issues with this list until I made the switch. On 7/05/10 12:51 AM, Ang Way Chuang wrote: Please ignore this email. why can't i get my email through linux media mailing list when i can receive it? -- 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 -- 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: this is a test mail
Oops, my bad. Jed wrote: Anyone know why we're getting 2 emails every time one sends only to linux-media@vger.kernel.org ? It's a tincy bit irritating, not that I'm complaining ;) On 7/05/10 12:57 AM, Jed wrote: Try sending via your ISP's SMTP host instead of Google's. I had issues with this list until I made the switch. On 7/05/10 12:51 AM, Ang Way Chuang wrote: Please ignore this email. why can't i get my email through linux media mailing list when i can receive it? -- 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 -- 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: this is a test mail
Thanks. Mauro. It's there. Hope the patch will be accepted. Mauro Carvalho Chehab wrote: Ang Way Chuang wrote: That's weird. You can receive my email, yet I don't receive my email from the mailing list. Does that mean my patch went through as well? Just check at patchwork.kernel.org. If you sent a patch correctly (e. g., in plain text only, no html, no line wrap), your patches should be there. Jed wrote: Try sending via your ISP's SMTP host instead of Google's. I had issues with this list until I made the switch. On 7/05/10 12:51 AM, Ang Way Chuang wrote: Please ignore this email. why can't i get my email through linux media mailing list when i can receive it? -- 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 -- 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: [PATCH] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
Okay, resending. Hope it won't do line wrapping.
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.
This patch was generated and tested against v2.6.32-rc8. Similar patch
was applied and tested using 2.6.27 which is similar to the latest
dvb_net.c, except for network device statistical data structure. I
suspect that this bug was introduced in kernel version 2.6.15, but had
not verified it.
Care has been taken not to introduce more bug by fixing this bug, but
please scrutinize the code for I always produces buggy code.
Signed-off-by: Ang Way Chuang wc...@nav6.org
---
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 0241a7c..7e0db86 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -458,8 +458,9 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
field: %u.\n,
priv-ts_count, *from_where);
/* Drop partly decoded SNDU,
reset state, resync on PUSI. */
- if (priv-ule_skb) {
- dev_kfree_skb(
priv-ule_skb );
+ if (priv-ule_skb ||
priv-ule_sndu_remain) {
+ if (priv-ule_skb)
+ dev_kfree_skb(
priv-ule_skb );
dev-stats.rx_errors++;
dev-stats.rx_frame_errors++;
}
@@ -533,6 +534,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
from_where += 2;
}
+ priv-ule_sndu_remain = priv-ule_sndu_len + 2;
/*
* State of current TS:
* ts_remain (remaining bytes in the current TS cell)
@@ -542,6 +544,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
*/
switch (ts_remain) {
case 1:
+ priv-ule_sndu_remain--;
priv-ule_sndu_type = from_where[0]
8;
priv-ule_sndu_type_1 = 1; /* first
byte of ule_type is set. */
ts_remain -= 1; from_where += 1;
@@ -555,6 +558,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
default: /* complete ULE header is present in
current TS. */
/* Extract ULE type field. */
if (priv-ule_sndu_type_1) {
+ priv-ule_sndu_type_1 = 0;
priv-ule_sndu_type |=
from_where[0];
from_where += 1; /* points to
payload start. */
ts_remain -= 1;
--
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] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
Sorry, line wrap again. I shall test and fix the problem first before
resending the patch.
On Tue, Nov 24, 2009 at 4:04 PM, Ang Way Chuang wcan...@gmail.com wrote:
Okay, resending. Hope it won't do line wrapping.
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.
This patch was generated and tested against v2.6.32-rc8. Similar patch
was applied and tested using 2.6.27 which is similar to the latest
dvb_net.c, except for network device statistical data structure. I
suspect that this bug was introduced in kernel version 2.6.15, but had
not verified it.
Care has been taken not to introduce more bug by fixing this bug, but
please scrutinize the code for I always produces buggy code.
Signed-off-by: Ang Way Chuang wc...@nav6.org
---
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 0241a7c..7e0db86 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -458,8 +458,9 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
field: %u.\n,
priv-ts_count, *from_where);
/* Drop partly decoded SNDU,
reset state, resync on PUSI. */
- if (priv-ule_skb) {
- dev_kfree_skb(
priv-ule_skb );
+ if (priv-ule_skb ||
priv-ule_sndu_remain) {
+ if (priv-ule_skb)
+
dev_kfree_skb( priv-ule_skb );
dev-stats.rx_errors++;
dev-stats.rx_frame_errors++;
}
@@ -533,6 +534,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
from_where += 2;
}
+ priv-ule_sndu_remain = priv-ule_sndu_len + 2;
/*
* State of current TS:
* ts_remain (remaining bytes in the current TS cell)
@@ -542,6 +544,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
*/
switch (ts_remain) {
case 1:
+ priv-ule_sndu_remain--;
priv-ule_sndu_type = from_where[0]
8;
priv-ule_sndu_type_1 = 1; /* first
byte of ule_type is set. */
ts_remain -= 1; from_where += 1;
@@ -555,6 +558,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
default: /* complete ULE header is present in
current TS. */
/* Extract ULE type field. */
if (priv-ule_sndu_type_1) {
+ priv-ule_sndu_type_1 = 0;
priv-ule_sndu_type |=
from_where[0];
from_where += 1; /* points to
payload start. */
ts_remain -= 1;
--
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] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.
This patch was generated and tested against v2.6.32-rc8. Similar patch
was applied and tested using 2.6.27 which is similar to the latest
dvb_net.c, except for network device statistical data structure. I
suspect that this bug was introduced in kernel version 2.6.15, but had
not verified it.
Care has been taken not to introduce more bug by fixing this bug, but
please scrutinize the code for I always produces buggy code.
Signed-off-by: Ang Way Chuang wc...@nav6.org
---
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 0241a7c..7e0db86 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -458,8 +458,9 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
field: %u.\n,
priv-ts_count, *from_where);
/* Drop partly decoded SNDU,
reset state, resync on PUSI. */
- if (priv-ule_skb) {
- dev_kfree_skb(
priv-ule_skb );
+ if (priv-ule_skb ||
priv-ule_sndu_remain) {
+ if (priv-ule_skb)
+ dev_kfree_skb(
priv-ule_skb );
dev-stats.rx_errors++;
dev-stats.rx_frame_errors++;
}
@@ -533,6 +534,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
from_where += 2;
}
+ priv-ule_sndu_remain = priv-ule_sndu_len + 2;
/*
* State of current TS:
* ts_remain (remaining bytes in the current TS cell)
@@ -542,6 +544,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
*/
switch (ts_remain) {
case 1:
+ priv-ule_sndu_remain--;
priv-ule_sndu_type = from_where[0]
8;
priv-ule_sndu_type_1 = 1; /* first
byte of ule_type is set. */
ts_remain -= 1; from_where += 1;
@@ -555,6 +558,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
default: /* complete ULE header is present in
current TS. */
/* Extract ULE type field. */
if (priv-ule_sndu_type_1) {
+ priv-ule_sndu_type_1 = 0;
priv-ule_sndu_type |=
from_where[0];
from_where += 1; /* points to
payload start. */
ts_remain -= 1;
--
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] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.
This patch was generated and tested against v2.6.32-rc8. Similar patch
was applied and tested using 2.6.27 which is similar to the latest
dvb_net.c, except for network device statistical data structure. I
suspect that this bug was introduced in kernel version 2.6.15, but had
not verified it.
Care has been taken not to introduce more bug by fixing this bug, but
please scrutinize the code for I always produces buggy code.
Signed-off-by: Ang Way Chuang wc...@nav6.org
---
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 0241a7c..7e0db86 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -458,8 +458,9 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
field: %u.\n,
priv-ts_count, *from_where);
/* Drop partly decoded
SNDU, reset state, resync on PUSI. */
- if (priv-ule_skb) {
- dev_kfree_skb(
priv-ule_skb );
+ if (priv-ule_skb ||
priv-ule_sndu_remain) {
+ if (priv-ule_skb)
+
dev_kfree_skb( priv-ule_skb );
dev-stats.rx_errors++;
dev-stats.rx_frame_errors++;
}
@@ -533,6 +534,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
from_where += 2;
}
+ priv-ule_sndu_remain = priv-ule_sndu_len + 2;
/*
* State of current TS:
* ts_remain (remaining bytes in the current TS cell)
@@ -542,6 +544,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
*/
switch (ts_remain) {
case 1:
+ priv-ule_sndu_remain--;
priv-ule_sndu_type = from_where[0] 8;
priv-ule_sndu_type_1 = 1; /*
first byte of ule_type is set. */
ts_remain -= 1; from_where += 1;
@@ -555,6 +558,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
default: /* complete ULE header is
present in current TS. */
/* Extract ULE type field. */
if (priv-ule_sndu_type_1) {
+ priv-ule_sndu_type_1 = 0;
priv-ule_sndu_type |=
from_where[0];
from_where += 1; /*
points to payload start. */
ts_remain -= 1;
--
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] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation code has a bug that incorrectly treats ULE SNDU packed into the remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer field on the subsequent MPEG2-TS frame. This patch was generated against v2.6.32-rc7, however it wasn't tested using that kernel. Similar patch was applied and tested using 2.6.27 which is similar to the latest dvb_net.c, except for network device statistical data structure. I suspect that this bug was introduced in kernel version 2.6.15, but had not verified it. Care has been taken not to introduce more bug by fixing this bug, but please scrutinize the code for I always produces buggy code. Signed-off-by: Ang Way Chuang wc...@nav6.org -- 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] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the remaining
2 or 3 bytes of a MPEG2-TS frame as having invalid pointer field on the
subsequent MPEG2-TS frame.
This patch was generated against v2.6.32-rc7, however it wasn't tested
using that kernel. Similar patch was applied and tested using 2.6.27 which
is similar to the latest dvb_net.c, except for network device statistical data
structure. I suspect that this bug was introduced in kernel version 2.6.15,
but had not verified it.
Care has been taken not to introduce more bug by fixing this bug, but
please scrutinize the code for I always produces buggy code.
Signed-off-by: Ang Way Chuang wc...@nav6.org
---
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 0241a7c..a521395 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -533,6 +533,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
from_where += 2;
}
+ priv-ule_sndu_remain = priv-ule_sndu_len + 2;
/*
* State of current TS:
* ts_remain (remaining bytes in the current TS cell)
@@ -542,6 +543,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
*/
switch (ts_remain) {
case 1:
+ priv-ule_sndu_remain--;
priv-ule_sndu_type = from_where[0]
8;
priv-ule_sndu_type_1 = 1; /* first
byte of ule_type is set. */
ts_remain -= 1; from_where += 1;
@@ -555,6 +557,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
default: /* complete ULE header is present in
current TS. */
/* Extract ULE type field. */
if (priv-ule_sndu_type_1) {
+ priv-ule_sndu_type_1 = 0;
priv-ule_sndu_type |=
from_where[0];
from_where += 1; /* points to
payload start. */
ts_remain -= 1;
--
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: No subsystem id (and therefore no cx88_dvb loaded) after reboot
Ang Way Chuang wrote: I experience similar problem with HVR4000 Lite cards that we have in the lab. The card can't tune after cold boot, but a reboot will fix the problem. I will check whether it has the similar invalid subsystem id problem. Unfortunately, I can't reproduce the cold boot tuning problem now. We'll send syslog information if our partner universities report the similar issue. Sorry. Grant Gardner wrote: I'm looking for some pointers on debugging a problem with my DVICO FusionHDTV Hybrid DVB-T card. The device was working perfectly prior to a reconfiguration of my machine, kernel upgrade etc... Now, on a cold start everything seems to start smoothly but I can't tune channels. Then, after a reboot the device is not detected due to invalid subsystem id. As below lspci reports no subsystem information at all. Comparing the lspci output seems to be around the Region 0: Memory at ee00 v de00, but I'm not sure what this means, and whether fixing the reboot problem will fix the channel tuning problem. Running mythbuntu 8.10 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux lspci -vvnn after cold start 00:0a.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (5000ns min, 13750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at de00 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx8800 Kernel modules: cx8800 00:0a.1 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] [14f1:8811] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (1000ns min, 63750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at df00 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel modules: cx88-alsa 00:0a.2 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] [14f1:8802] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (1500ns min, 22000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at e000 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) currently, though we're working on a commercial implementation of the RTP profile. If you're interested in the GPL'ed UDP profile code, we can email it to you in a week or two (we'll eventually make it available on our website as well, but currently it needs to be cleaned up a bit). T.C. Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx88-mpeg driver manager Kernel modules: cx8802 lspci -vvnn after warm reboot 00:0a.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (5000ns min, 13750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at ee00 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx8800 Kernel modules: cx8800 -- 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
Re: No subsystem id (and therefore no cx88_dvb loaded) after reboot
I experience similar problem with HVR4000 Lite cards that we have in the lab. The card can't tune after cold boot, but a reboot will fix the problem. I will check whether it has the similar invalid subsystem id problem. Grant Gardner wrote: I'm looking for some pointers on debugging a problem with my DVICO FusionHDTV Hybrid DVB-T card. The device was working perfectly prior to a reconfiguration of my machine, kernel upgrade etc... Now, on a cold start everything seems to start smoothly but I can't tune channels. Then, after a reboot the device is not detected due to invalid subsystem id. As below lspci reports no subsystem information at all. Comparing the lspci output seems to be around the Region 0: Memory at ee00 v de00, but I'm not sure what this means, and whether fixing the reboot problem will fix the channel tuning problem. Running mythbuntu 8.10 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux lspci -vvnn after cold start 00:0a.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (5000ns min, 13750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at de00 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx8800 Kernel modules: cx8800 00:0a.1 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] [14f1:8811] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (1000ns min, 63750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at df00 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel modules: cx88-alsa 00:0a.2 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] [14f1:8802] (rev 05) Subsystem: DViCO Corporation Device [18ac:db40] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (1500ns min, 22000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at e000 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx88-mpeg driver manager Kernel modules: cx8802 lspci -vvnn after warm reboot 00:0a.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (5000ns min, 13750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at ee00 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx8800 Kernel modules: cx8800 -- 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: SNR status for demods
Thank you very much, Devin Heitmueller. This list is a god-sent :). Devin Heitmueller wrote: Hello all, I have updated my compiled list of the various demods and how they currently report SNR info (including feedback from people in the last round). http://www.devinheitmueller.com/snr.txt Here's how you can help out: If you are a maintainer for a device in this list, please let me know so I can update the document. If you are the maintainer and somebody else's name is listed by the device, please do not take offense to this (it's probably just an error on my part [please email and correct me]). If you have specs for a device in this list where the format is currently unknown, please let me know as this will be helpful in identifying which demods we can get accurate information for. If you know something about how SNR is currently reported by the driver, and it is not reflected in this list, please let me know and I will update the document. All of the above information will be helpful once a format has been decided on, so we can pull together and finally get a consistent interface. Thank you for your time, Devin -- 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 in dvb_net
Hi linux-tver, Not sure whether this is the right mailing list or not. I've encountered a kernel oops in dvb_net. My receiver card is HVR-4000 Lite. I'm running a rawhide kernel on Fedora 10. Attached is the syslog just before when nuts. I tested with rawhide kernel version 2.6.29-0.124.rc5.fc10.i586 and vanilla kernel 2.6.28.7. I'm using the receiver card for ULE decapsulation. Should you need more information, please drop me a mail. Attached are the kernel oops message of the 2 kernels just before the system freeze. Thanks. Regards, Ang Way Chuang Mar 9 16:18:44 localhost kernel: dvb0_0: no ts feed to stop Mar 9 16:18:44 localhost kernel: dvb_net: removed network interface dvb0_0 Mar 9 16:18:44 localhost kernel: 1802201963: Expected 1802201963 more SNDU bytes, but got PUSI (pf 0, ts_remain 183). Flushing incomplete payload. Mar 9 16:18:44 localhost kernel: BUG: unable to handle kernel paging request at 6b6b6c1f Mar 9 16:18:44 localhost kernel: IP: [c065c31f] kfree_skb+0x9/0x32 Mar 9 16:18:44 localhost kernel: *pde = Mar 9 16:18:44 localhost kernel: Oops: [#1] SMP Mar 9 16:18:44 localhost kernel: last sysfs file: /sys/devices/virtual/net/dvb0_0/flags Mar 9 16:18:44 localhost kernel: Modules linked in: sco bridge stp llc bnep l2cap bluetooth ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath uinput isl6421 cx24116 snd_hda_codec_realtek cx88_dvb cx88_vp3054_i2c snd_hda_intel videobuf_dvb dvb_core tuner cx8802 cx8800 cx88_alsa snd_hda_codec snd_hwdep cx88xx snd_seq_dummy snd_seq_oss ir_common tveeprom snd_seq_midi_event v4l2_common snd_seq videodev snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm v4l1_compat videobuf_dma_sg videobuf_core iTCO_wdt btcx_risc iTCO_vendor_support ppdev floppy pcspkr snd_timer snd i2c_i801 r8169 soundcore parport_pc via_velocity parport snd_page_alloc mii crc_ccitt ata_generic pata_acpi i915 drm i2c_algo_bit i2c_core [last unloaded: microcode] Mar 9 16:18:44 localhost kernel: Mar 9 16:18:44 localhost kernel: Pid: 4024, comm: cx88[0] dvb Tainted: G W (2.6.29-0.124.rc5.fc10.i586 #1) Prime Series Mar 9 16:18:44 localhost kernel: EIP: 0060:[c065c31f] EFLAGS: 00010002 CPU: 1 Mar 9 16:18:44 localhost kernel: EIP is at kfree_skb+0x9/0x32 Mar 9 16:18:44 localhost kernel: EAX: 6b6b6b6b EBX: fa4ca301 ECX: 6b6b6b6b EDX: 01a2c000 Mar 9 16:18:44 localhost kernel: ESI: f4d415e0 EDI: f4d41060 EBP: f4e09ec4 ESP: f4e09ec4 Mar 9 16:18:44 localhost kernel: DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Mar 9 16:18:44 localhost kernel: Process cx88[0] dvb (pid: 4024, ti=f4e09000 task=f4f029e0 task.ti=f4e09000) Mar 9 16:18:44 localhost kernel: Stack: Mar 9 16:18:44 localhost kernel: f4e09f40 f81939fd f81973d1 6b6b6b6b 6b6b6b6b 00b7 f4c0d3c0 Mar 9 16:18:44 localhost kernel: f4d415e0 fa4ca318 f4d41060 b7a5b100 fa4ca31d fa4ca3d4 f4d411c4 f4d4162c Mar 9 16:18:44 localhost kernel: b4b6ba84 0be6 f4e09f20 f4d022a4 f4d022a4 f4d02294 0293 Mar 9 16:18:44 localhost kernel: Call Trace: Mar 9 16:18:44 localhost kernel: [f81939fd] ? dvb_net_ts_callback+0x340/0xa57 [dvb_core] Mar 9 16:18:44 localhost kernel: [f818ce97] ? dvb_dmx_swfilter_packet+0x122/0x300 [dvb_core] Mar 9 16:18:44 localhost kernel: [c06e66b2] ? _spin_lock_irqsave+0x63/0x6d Mar 9 16:18:44 localhost kernel: [f818e073] ? dvb_dmx_swfilter+0xce/0x10d [dvb_core] Mar 9 16:18:44 localhost kernel: [f80e25f2] ? videobuf_dvb_thread+0xad/0x12f [videobuf_dvb] Mar 9 16:18:44 localhost kernel: [f80e2545] ? videobuf_dvb_thread+0x0/0x12f [videobuf_dvb] Mar 9 16:18:44 localhost kernel: [c043fe95] ? kthread+0x3b/0x61 Mar 9 16:18:44 localhost kernel: [c043fe5a] ? kthread+0x0/0x61 Mar 9 16:18:44 localhost kernel: [c04046f7] ? kernel_thread_helper+0x7/0x10 Mar 9 16:18:44 localhost kernel: Code: 00 00 88 4b 65 f0 ff 0a 0f 94 c0 84 c0 74 10 8d 93 48 ff ff ff a1 34 37 8b c0 e8 1f 44 e4 ff 5b 5d c3 55 85 c0 89 e5 89 c1 74 27 8b 80 b4 00 00 00 48 75 07 0f ae e8 89 f6 eb 10 8d 81 b4 00 00 Mar 9 16:18:44 localhost kernel: EIP: [c065c31f] kfree_skb+0x9/0x32 SS:ESP 0068:f4e09ec4 Mar 9 16:18:44 localhost kernel: ---[ end trace 265db78d6888b949 ]--- Mar 9 16:18:44 localhost kernel: = Mar 9 16:18:44 localhost kernel: BUG kmalloc-2048 (Tainted: G D W ): Poison overwritten Mar 9 16:18:44 localhost kernel: - Mar 9 16:18:44 localhost kernel: Mar 9 16:18:44 localhost kernel: INFO: 0xf4d410c0-0xf4d416bc. First byte 0x6c instead of 0x6b Mar 9 16:18:44 localhost kernel: INFO: Allocated in alloc_netdev_mq+0x3d/0x11c age=1499438 cpu=1 pid=3815 Mar 9 16:18:44 localhost kernel: INFO: Freed in netdev_release+0x2f/0x32 age=126 cpu=1 pid=4277 Mar 9 16:18:44 localhost kernel: INFO: Slab 0xc1f66b00 objects=15 used=0 fp=0xf4d4 flags
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
VDR User wrote: On Thu, Mar 12, 2009 at 6:53 PM, Ang Way Chuang wc...@nav6.org wrote: Hi all, I've looked through the mailing list and there seems to be no standard way to interpret to content of SNR, signal strength and BER returned from the DVB API. So, I wonder if someone knows how to interpret these values at least for HVR 4000 Lite? Thanks. I've seen talk about converting everything to report SNR/STR in dB which is a great idea if it ever happens. I know a lot of guys not on the mailing list who've been waiting for that. Yes, please :) -- 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
