Re: [Mjpeg-users] stability issues with 440BX and DC10plus?
[EMAIL PROTECTED] writes: > BUT: once in a while, the capturing with lavrec stops (ie: timer > stops, and after a while, I get the well-known "error syncing on a > buffer, timer expired" message. I have never been able to record more than 20 minutes with my DC10plus and 440BX motherboard (ASUS P2B-D). I've tried it with both a 36057 and a 36067 based board. Trying the newer videodev2 driver is still on my todo list. > And sometimes, this reinitializing won't work, and lavrec will keep > losing frames from that point. This is what I almost always get, at right around twenty minutes. It doesn't matter what I've got --file-flush, -U, -a, or -q set to, or what the video source is. > Is this a known problem? Oh yeah. I haven't found a known solution yet. If the videodev2 driver turns out to do the trick for you, I'd be quite interested in knowing. Brian. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Transcoding/scaling from 720x480 to (S)VCD
On Saturday 11 January 2003, at 23:05, Andrew Stevens wrote:
Hi Andrew and hi all.
> You have an old (and presumably broken) version of the hacked mpeg2dec...
>
> You want:
> mpeg2dec-0.2.1-mjpegtools-0.7
You are right! That solved the problem and
mpeg2dec -s -o YUVh sample.mpg | yuvplay
now plays well.
_Thank you_ very much for your help and patience!
Ciao,
beatrice.
--
Thunder only happens when it's raining,
players only love you when they're playing.
("Dreams" - Fleetwood Mac)
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] stability issues with 440BX and DC10plus?
Hello, On Sun, Jan 12, 2003 at 06:57:39AM -0800, Brian Edmonds wrote: > I have never been able to record more than 20 minutes with my DC10plus > and 440BX motherboard (ASUS P2B-D). I've tried it with both a 36057 and > a 36067 based board. Trying the newer videodev2 driver is still on my > todo list. According to the FAQ file in the videodev_2 branch, there are "early stepping" and "later stepping" versions of the 440BX. Just guessing, but maybe you have one of those early steppings? I can usually capture more than 20 minutes before I get the error. I assume you are using the original branch of the cvs driver. In case you've ever tried the zoran driver included in the kernel sources: did you have the same problem? Maybe you have never tried the version shipped with the (later 2.4) kernel? In that case, I would definitely recommend trying the videodev_2 branch. In my case, the kernel driver would give me an error syncing on a buffer, but I changed liblavrec.c from lavtools to exit cleanly when that occurs. I have written some python scripts to make capturing/encoding/ archiving easier, so in my recording script I just restart lavrec when it suddenly finishes and the total recording time hasn't been reached yet. So, in practice, I can capture almost reliably, but once in a while (quite often after more than your 20 minutes maximum, I have to add), I'm missing a few seconds because of the timer expired error. I can send you my scripts and explain where I've changed my liblavrec.c if it can help you. The normal cvs branch driver was worse, and I ended up with hanging lavrec processes. With the videodev_2 branch, I have the same results so far as with the kernel driver: occasional timer expired's, i.e. a workable but not perfect solution. > Oh yeah. I haven't found a known solution yet. If the videodev2 driver > turns out to do the trick for you, I'd be quite interested in knowing. I'd definitely give it a shot, if you have only tried the regular cvs or the old 8.0 release so far. Hope it helps. Kind regards, Jonas --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
[Mjpeg-users] jumping effect in encoded (svcd) videos...
Hi, I wanted to use mjpeg tool zu create svcds (with transcode). When playing those svcds on my dvd-player I notice every few seconds a small "jumping" in the sound. Then I watched the display of the player and saw that the time-display is also jumping at that moments, like this: 6..7..8..7..8..9..10..11..12..11..12..13.. when watching the same file with mplayer the display is jumping too, but I do not hear a disruption of the sound. The same happens when watching your demo-files from your web page (mpeg1-digital.mpg and pal-vid-svcd.mpg). Is this an error? What is this jumping effect when playing the videos? Or is it a fault of my dvd player (allthough the jumping can be seen in mplayer too) thanks for answering, regards, Michael Wohlwend --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: Re: [Mjpeg-users] seriously old dc10
> > I thus suggest that we change
> > printk(KERN_INFO "%s: " __func__ " - blabla ", zr->name);
> > to
> > printk(KERN_INFO "%s: %s - blabla ", zr->name, __func__ );
> > which would work for both gcc-2.95 and gcc-3.2, and be in accordance
> > with the C99 standard.
>
> Sounds good, let's do that. Are you gonna send up a patch or should I
> make up something myself? If me, then that'll be next week, I won't be
> home this weekend. If __func__ doesn't work (compiler screams about
> undefined thing), I'll use __FUNCTION__ instead - that always works.
Here's a patch which uses __func__ along with %s in the printk's. The debug
output in vpx3220.c should probably be rewritten, but as I'm not sure yet
which of vpx3220.c and vpx32xx.c will be kept, I won't do it for now :-)
The patch compiles fine with gcc-2.95, someone should test it with gcc-3.
Laurent Pinchart
diff -u -r1.1.2.6 vpx3220.c
--- vpx3220.c 27 Dec 2002 15:26:04 - 1.1.2.6
+++ vpx3220.c 12 Jan 2003 21:38:50 -
@@ -77,7 +77,7 @@
{
/* Write the 16-bit address to the FPWR register */
if (i2c_smbus_write_word_data(client, 0x27, swab16(fpaddr)) == -1) {
- DEBUG(printk(VPX3220_DEBUG __func__": failed\n"));
+ DEBUG(printk(VPX3220_DEBUG "%s: failed\n", __func__));
return -1;
}
@@ -86,7 +86,7 @@
/* Write the 16-bit data to the FPDAT register */
if (i2c_smbus_write_word_data(client, 0x28, swab16(data)) == -1) {
- DEBUG(printk(VPX3220_DEBUG __func__": failed\n"));
+ DEBUG(printk(VPX3220_DEBUG "%s: failed\n", __func__));
return -1;
}
@@ -99,7 +99,7 @@
/* Write the 16-bit address to the FPRD register */
if (i2c_smbus_write_word_data(client, 0x26, swab16(fpaddr)) == -1) {
- DEBUG(printk(VPX3220_DEBUG __func__": failed\n"));
+ DEBUG(printk(VPX3220_DEBUG "%s: failed\n", __func__));
return -1;
}
@@ -109,7 +109,7 @@
/* Read the 16-bit data from the FPDAT register */
data = i2c_smbus_read_word_data(client, 0x28);
if (data == -1) {
- DEBUG(printk(VPX3220_DEBUG __func__": failed\n"));
+ DEBUG(printk(VPX3220_DEBUG "%s: failed\n", __func__));
return -1;
}
@@ -452,7 +452,7 @@
int err;
struct i2c_client *client;
- DEBUG(printk(VPX3220_DEBUG __func__"\n"));
+ DEBUG(printk(VPX3220_DEBUG "%s\n", __func__));
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA |
@@ -477,7 +477,7 @@
id = vpx3220_read(client, 0x00);
if (id != 0xec) {
- printk(KERN_INFO "vpx3220_attach: Wrong manufacturer ID (0x%02x)\n", id);
+ printk(KERN_INFO "%s: Wrong manufacturer ID (0x%02x)\n", __func__, id);
kfree(client);
return 0;
}
@@ -494,7 +494,7 @@
strcpy(client->name, "vpx3214c");
break;
default:
- printk(KERN_INFO __func__ ": Wrong part number (0x%04x)\n", pn);
+ printk(KERN_INFO "%s: Wrong part number (0x%04x)\n", __func__, pn);
kfree(client);
return 0;
}
@@ -523,7 +523,7 @@
int ret;
ret = i2c_probe(adapter, &addr_data, &vpx3220_detect_client);
- DEBUG(printk(VPX3220_DEBUG __func__ ": i2c_probe returned %d\n", ret));
+ DEBUG(printk(VPX3220_DEBUG "%s: i2c_probe returned %d\n", __func__, ret));
return ret;
}
Re: [Mjpeg-users] Command line tools to mix/overlay/join two lavrec-AVIs?
Hi, i just wrote two programs that do some conversion on LAV AVI streams. They are standalone programs that processes images in RGBA (red-green-blue-alpha) and writes the resulting images to an output stream. pngoverlay just overlays some PNG files over the input stream (nice for animated logos and some special FX). pngblend reads two LAV streams (left- and right part) of the same x- and y-dimensions and mixes them according to either a blend mask file or a rule (-l xleft -r xright, result is taken from either leftstream or rightstream or mixed). It also contains some code to read/write PNG files to/from RGBA data. In the bash script "qwe" some example calls are contained, please provide some input data in ../lav_examples. I hope somebody finds this useful. Best regards, Torsten. > Hi Torsten, > > On Mon, 2003-01-06 at 20:05, Torsten Mohr wrote: > > In the documentation i only found references to "transist.flt", > > as i understand it this only enables the third effect i > > mentioned, for the others i'd have to write a filter, correct? > > There's one more, matteblend.flt. LVS also contains some more filters, > look in the effects/ directory of LVS. > > > It seems that writing a filter is not impossible, looking at > > the sources. > > > > Is anybody working on other filters? > > Not that I know of. > > > Is anybody using "blenderpublisher" (www.blender.org)? It can > > generate animations with background "invisible". I'd like to > > overlay those over an AVI as an animated logo. As an > > alpha channel is only available in single pictures, it would have > > to read in a LAV stream and single pictures. > > Matteblend can do this, though it's not easy with moving pictures. > > > What do you think of this? > > Hard, but not impossible. Most code already exists. :-). > > Ronald lavfilter.tar.bz2 Description: application/tbz
Re: [Mjpeg-users] stability issues with 440BX and DC10plus?
On Sat, 2003-01-11 at 15:41, [EMAIL PROTECTED] wrote: > -> Every time when I start recording for the first time since the modules >have been loaded, I get an "error syncing on a buffer: timer expired" >after about 2 seconds (= first write to disk). Urm...? On a 440BX mainboard?!? /me gets confused Last resort solution: --file-flush=0. ;-). If it doesn't help, even if the card has its own IRQ, please report it again and I'll have a closer look. Even first-time records should work (doh!). Ronald -- Ronald Bultje <[EMAIL PROTECTED]> Linux Video/Multimedia developer --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] stability issues with 440BX and DC10plus?
On Sunday 12 January 2003 15:57, Brian Edmonds wrote: > [EMAIL PROTECTED] writes: > > BUT: once in a while, the capturing with lavrec stops (ie: timer > > stops, and after a while, I get the well-known "error syncing on a > > buffer, timer expired" message. > > I have never been able to record more than 20 minutes with my DC10plus > and 440BX motherboard (ASUS P2B-D). I've tried it with both a 36057 and > a 36067 based board. Trying the newer videodev2 driver is still on my > todo list. > > > And sometimes, this reinitializing won't work, and lavrec will keep > > losing frames from that point. > > This is what I almost always get, at right around twenty minutes. It > doesn't matter what I've got --file-flush, -U, -a, or -q set to, or what > the video source is. The two of you; I know you have nice disks and all that, but anyway: What does hdparm -i on the relevant disk say? ...assuming you're using ATA, that is... /Sam --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] stability issues with 440BX and DC10plus?
Martin Samuelsson <[EMAIL PROTECTED]> writes:
> What does hdparm -i on the relevant disk say? ...assuming you're using
> ATA, that is...
# hdparm -i /dev/hda
/dev/hda:
Model=MAXTOR 6L040J2, FwRev=A93.0500, SerialNo=662132710203
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4
BuffType=DualPortCache, BuffSize=1819kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78177792
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6
Drive Supports : Reserved : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5
Kernel Drive Geometry LogicalCHS=4866/255/63 PhysicalCHS=77557/16/63
# hdparm -i /dev/hdc
/dev/hdc:
Model=MAXTOR 6L040J2, FwRev=A93.0500, SerialNo=662132710360
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4
BuffType=DualPortCache, BuffSize=1819kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78177792
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6
Drive Supports : Reserved : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5
Kernel Drive Geometry LogicalCHS=4866/255/63 PhysicalCHS=77557/16/63
A 30GB partition from each drive is striped together as /dev/md0, and
there are no other drives on this Promise ATA-100 controller. The
machine's CDR drive is on the motherboard's onboard ATA-33 controller.
# bonnie -s 512 (in a /dev/md0 directory)
Bonnie 1.2: File './Bonnie.9702', size: 536870912, volumes: 1
Writing with putc()... done: 2563 kB/s 85.5 %CPU
Rewriting... done: 10578 kB/s 52.9 %CPU
Writing intelligently... done: 9314 kB/s 61.8 %CPU
Reading with getc()... done: 2121 kB/s 78.2 %CPU
Reading intelligently... done: 21593 kB/s 69.4 %CPU
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek-
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)-
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
galad 1* 512 2563 85.5 9314 61.8 10578 52.9 2121 78.2 21593 69.4 245.1 12.6
(The machine has 384MB of RAM, so a 512MB test should be adequate to
eliminate cache effects.) The machine (dual P2/266) was also ripping
CDs, encoding OGGs, and playing (different) OGGs while I was testing. I
generally capture with -d2 and -q50, and with nothing else going on, so
I shouldn't be getting anywhere near the write transfer limit.
Brian.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] stability issues with 440BX and DC10plus?
On Monday 13 January 2003 01:28, Brian Edmonds wrote: > Martin Samuelsson <[EMAIL PROTECTED]> writes: > > What does hdparm -i on the relevant disk say? ...assuming you're using > > ATA, that is... > > # hdparm -i /dev/hda > DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6 > > # hdparm -i /dev/hdc > DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6 > > A 30GB partition from each drive is striped together as /dev/md0, and > there are no other drives on this Promise ATA-100 controller. The > machine's CDR drive is on the motherboard's onboard ATA-33 controller. With an ATA-100 controller, udma5 should be ok, I guess. The reason I asked is that the ATA controller (or the BIOS?) on my 440BX happily negotiates a nice, fast mode in the udma5 (IIRC) range with the disk, but anything above udma2 works like crap. With the built-in controller, that is. /Sam --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] stability issues with 440BX and DC10plus?
Martin Samuelsson <[EMAIL PROTECTED]> writes: > The reason I asked is that the ATA controller (or the BIOS?) on my > 440BX happily negotiates a nice, fast mode in the udma5 (IIRC) range > with the disk, but anything above udma2 works like crap. With the > built-in controller, that is. I've had this machine for quite a few years now, with no operational issues, apart from it running a bit hot. It's cool when idle, but gets pretty toasty when loaded. It's rock solid stable though, without a single unprovoked kernel panic, halt or reboot. I specifically went out and bought two new 40GB disks and the Promise controller when I put it back into use as a multimedia machine, and they've been operating without issue for about a year now. I had an attack of the stupids when I first built it years ago, and managed to short one of the fan pins. I caught that quickly when things started smelling like smoke. There's a teeny scortch mark on the board, and the CPU fans haven't worked since, but other than that it's been in 24/7 operation most of the time since without a single crash that wasn't due to fiddling with the kernel (2.4.19 USB routinely kills it, for example; 2.4.18 is fine). When I used it as a full-time mail/news/etc server I had an external fan blowing into it, which kept it nice and cool. Brian. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] stability issues with 440BX and DC10plus?
On Mon, Jan 13, 2003 at 12:35:50AM +0100, Ronald Bultje wrote: > On Sat, 2003-01-11 at 15:41, [EMAIL PROTECTED] wrote: > > -> Every time when I start recording for the first time since the modules > >have been loaded, I get an "error syncing on a buffer: timer expired" > >after about 2 seconds (= first write to disk). > > Urm...? On a 440BX mainboard?!? It's a Compaq, Pentium III 450. They have a reputation of slightly altering hardware sometimes :-s But it is definitely a 440BX chipset. Output of lspci: 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 00:0d.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 00:0d.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 00:0e.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) 00:10.0 Multimedia video controller: Zoran Corporation ZR36057PQC Video cutting chipset (rev 02) 00:14.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) 00:14.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) 00:14.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) 00:14.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02) 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 5c) /proc/interrupts: CPU0 0: 24116 XT-PIC timer 1:357 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 0 XT-PIC SoundBlaster 8: 3 XT-PIC rtc 9: 50 XT-PIC DC10plus[0] 11:110 XT-PIC eth0, bttv 14: 2648 XT-PIC ide0 15: 16 XT-PIC ide1 NMI: 0 LOC: 24079 ERR: 0 > Last resort solution: --file-flush=0. ;-). If it doesn't help, even if > the card has its own IRQ, please report it again and I'll have a closer > look. Even first-time records should work (doh!). Tried this before without success. Although right now, I do notice something else re: file-flush=0. I have a FAT filesystem on the disk where I record, because I used to have a windows installation where I wanted to be able to access the recorded material. Now, I have the timer expired problem both when I record to an ext2 with some free space, or the usual FAT fs (without special --file-flush setting). But with --file-flush=0, recording to an ext2 fs seems to be stable (although I can't record more than a few minutes on this ext2 because of disk space right now, but so far it has worked every time). What I mean by "stable": It seems: when running lavrec interactively, all the fields in the bottom status line are continuously being updated; but everytime on a sync() (or with file-flush=0: when the disks writes a chunk of data), there is a short pause: the values (time, int, ...) stay the same, and after the data has been written, the "int" field is close to 0 for a short time (instead of a normal value of 39-40 which I approximately get in between these sync's). So, while writing to disk, no frames are being fetched from the video device, and after writing, all pending frames are quickly retrieved at once - must be that we have been in kernel mode for that while I guess? I just say this because I'm not sure whether that's what is supposed to happen or not. Now, when I run lavrec on the ext2 fs and with --file-flush=0, lavrec doesn't hang anymore on every write to disk (it still does hang for a while sometimes, but only once every 20 seconds or so). I'll free some more space, or I'll convert the FAT to ext2 one of these days, and report further. Thanks for the hint. Thanks to all you guys working on the driver and the other software! Kind regards, Jonas --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] stability issues with 440BX and DC10plus?
On Mon, Jan 13, 2003 at 01:01:39AM +0100, Martin Samuelsson wrote:
> The two of you; I know you have nice disks and all that, but anyway:
>
> What does hdparm -i on the relevant disk say? ...assuming you're using ATA,
> that is...
In my kernel, I enable UDMA by default.
/dev/hdc:
Model=ST330630A, FwRev=3.21, SerialNo=3CK0DYN4
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=59777640
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4
AdvancedPM=no WriteCache=enabled
Drive Supports : Reserved : ATA-1 ATA-2 ATA-3 ATA-4
Looks ok. Explicitly doing hdparm -X66 /dev/hdc does't solve the problem
either.
Thanks for your reply.
Kind regards,
Jonas
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
