Re: noflushd segfault (was Re: Spin down of pismo's Disk and sound) (fwd)
> > This sounds like an excellent idea, but when I run apt-get I get a > > segfault: > > > > Setting up noflushd (2.4-2) ... > > Starting No Flush Daemon: BUG at disk_info.c line 169: Unable to determine > > device dir at /dev/ide/host0/bus0/target0/lun0/disc > > /etc/init.d/noflushd: line 47: 1018 Segmentation fault > > start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid --exec > > $DAEMON -- $PARAMS > > noflushd. > > Have you looked at line 47 of that script to see what command segfaults? The segfault is bogus, it's triggered by noflushd hitting a BUG(). The line before is the interesting one. Actually, this is a FAQ. You're running noflushd on a kernel compiled with devfs support, but without devfs mounted. noflushd is terminally lost here, see the README for details. The solution is to mount devfs, either to /dev if you want to go full pace, or to a different, 'safe' place like /devfs. Regards, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net
Little-endian sound broken on TiBook/dmasound_pmac?
Moi! Is 16bit little-endian sound working for anyone using dmasound_pmac? I've tried with various pristine 2.4 kernels as well as benh's latest 2.4.4 an my TiBook. (Awacs/Screamer Codec Mfct: 1 Rev 3 it reports.) Big-endian sound output works fine. Little-endian sound on the other hand produces only garbage, and I very much suspect it's the wrong endianness. /dev/sndstat tells me that the soft format is correctly set to little-endian, hard format is big-endian though, so I suspect the hw byte swap isn't working correctly. I'd really like to know whether this problem is specific to TiBooks, or if there's a general bug in the dmasound_pmac driver. You can try to reproduce this behaviour by using bplay to play a simple wav file. Don't use something more fancy like esdplay which sends data in native endianness. (And don't use play from the sox package. It sets the soft format to litte-endian but sends big-endian data. Nice for the TiBook of course, since the two bugs cancel out themselves. ;-) Regards, Daniel.
Re: Little-endian sound broken on TiBook/dmasound_pmac?
On Mon, May 21, 2001 at 01:38:46PM +0200, Michel Dänzer wrote: > Daniel Kobras wrote: > > Is 16bit little-endian sound working for anyone using dmasound_pmac? I've > > tried with various pristine 2.4 kernels as well as benh's latest 2.4.4 an my > > TiBook. (Awacs/Screamer Codec Mfct: 1 Rev 3 it reports.) Big-endian sound > > output works fine. Little-endian sound on the other hand produces only > > garbage, and I very much suspect it's the wrong endianness. /dev/sndstat > > tells me that the soft format is correctly set to little-endian, hard format > > is big-endian though, so I suspect the hw byte swap isn't working correctly. > > I'd really like to know whether this problem is specific to TiBooks, or if > > there's a general bug in the dmasound_pmac driver. > > The latter. > > Recent Apple sound hardware (Pismos and G4s as well AFAIK) can't do the byte > order conversion. Ah, I see. Thanks for the explanation. > Iain Sandoe put software conversion in the dmasound driver at some point, but > that's arguably a wrong approach. Of course it shouldn't advertise the > ability to play little endian when in fact it can't... In a perfect world, yes. But there are simply too many broken programs out there that rely on AFMT_S16_LE being available without properly checking for it. (And even if they check, few have a suitable fallback.) Most of the programs using the old SNDCTL_DSP_SAMPLESIZE call rather than SNDCTL_DSP_SETFMT belong into this category. They push a value of 16, and rarely realise this implies little-endianness of the data. Stuffing a conversion layer into the driver therefore makes tons of sense, and avoids a pile of legacy problems. Regards, Daniel.
Re: Bug#400919: Bug #400919: Bug affecting Kino (and Cinelerra) on PowerPC, any ideas?
On Sun, Jan 07, 2007 at 03:47:56PM +0100, Michael Schmitz wrote: > To be honest, I haven't used kino for a while - I had worked out a crude > endianness fix for video, that got corrected by someone even, and dropped > the matter when the ffmpeg packages were available. It was too slow to be > useable. The only video-related endianness bug in kino/libdv I'm aware of turned out the be an Xv problem. That was in 2002. Please file a bug if there are still issues on ppc. > > ffmpeg is available in debian main since some time. > > So we need to convince the kino maintainer to use it - and ask Guido for > details. Please keep in mind that we need the altivec optimized ffmpeg > code ... ffmpeg is supposed to be used for decoding by default already, but the ppc build of kino 0.92-1 isn't liked with libavcodec. The ppc buildd log is missing on buildd.d.o, so I don't know why, but it might well be due to a botched build environment. Unless Paul already knows more about what's going wrong here, could you please try to simply rebuild kino on ppc and see whether it picks up the proper libavcodec dependency? Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wmappl
On Thu, Jul 11, 2002 at 12:09:43AM +0200, Mij wrote: > That's right, but as Theo noted, expliciting the char "signed" clears > the problem. > That's really strange. I think this depends on two's complement notation > AND endianess, > but I'm really curious to know something more. > "Signed" is an implicit keyword, and it doesn't implies any specific > behaviour. It's simply > implied. Then, I think the problem comes from a gcc optimization. 'char' defaults to 'unsigned char' on ppc, while it's 'signed char' on most other platforms. Therefore, 'if (some_char < 0)' doesn't make sense on ppc, but it's perfectly fine on, say, x86. But as already noted, the correct fix shall use 'int' instead of 'char' because 'fgetc()' needs to return 257 distinct values. Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3 issue on powerpc with benh kernel
On Sat, Oct 12, 2002 at 06:30:07PM +0200, Vincent Bernat wrote: > A new feature will be added for 2.4.20 which will allow to increase > this delay at mount time. Therefore, it will be possible to use ext3 > with noflushd. It is not possible for the moment. You may find more > information on this issue on the site of noflushd. I'd rather put it as: 2.4.20 will make it possible for noflushd to (sanely) support ext3 filesystems. noflushd does not implement it yet (and I have this vision of yet another pile of devfs and aliasing issues before it does). Regards, Daniel.
Re: xfs install on powermac?
On Mon, Oct 14, 2002 at 08:57:03PM -0700, Evan Martin wrote: > I'd like to reinstall with a better file system, but I read that Reiser > doesn't work with noflushd and XFS does. Err, does it? For all I know, noflushd sucks with any journalling FS. Do you remember where you read about XFS working? Regards, Daniel.
Re: powerbook 17" install
On Sun, Jun 22, 2003 at 11:21:36PM +1000, Brendan J Simon wrote: > For some reason I can't nfs mount an intel box to copy my backup fs to > my new partitions. wget fails too. I think this is because the .tgz > file is 3.1GB and the busybox version of wget is not so capable. I have > a macosx partition so I should be able to copy the file to it and > hopefully I might be able to find a ext2/3 driver for macos so I can > unarchive the .tgz files to my linux partition. Any one know of such a > driver ??? Try http://sourceforge.net/projects/ext2fsx. There have been errors when copying files to ext2 via the Finder. Not sure whether this has been fixed by now. If you want to play it safe, use the command line to copy files over. Regards, Daniel.
Re: powerbook 17" install
On Sun, Jun 22, 2003 at 05:02:11PM +0200, Jens Schmalzing wrote: > I would advise against this driver for serious use; when I tried the > latest version it crashed Mac OS X and ate the filesystem. I've seen corruption as well, but only when using the Finder. Command-line usage has proven solid so far for me. I'd say this driver's definitely good enough to populate a newly created filesystem. Regards, Daniel.
Re: problems building kino from .tar.gz
On Thu, Jun 12, 2003 at 08:12:42PM +0200, Pander wrote: > Building kino from .tar.gz halts on errors like: > /usr/include/libintl.h:40: error: parse error before `__const' > on a PowerPC as seen below. What should be the best way to fix this? Localization in the C++ headers shipped with g++ 3.3 exposes some brain damage in the Gnome 1 headers. The latest Debian version (kino 0.64-3) contains a workaround, and compiles fine with g++ 3.3. Regards, Daniel.
Re: date problems
On Wed, Jan 30, 2002 at 12:12:59PM +, Liam Bedford wrote: > I can reset the date with date, but as soon as I put the machine to sleep or > reboot it, it'll jump forward a month. > > (Actually, now that I think about it, it's now jumped forward another month, > so I'm now 2 months ahead). Check the first entry of /etc/adjtime for a really large value. If so, rm /etc/adjtime, adjust the system clock, and set the hardware clock. Your system somehow got to think it has to correct for a massive systematic drift in the hardware clock. More information is to be found eg. in the adjust section of hwclock's man page. Regards, Daniel.
Re: gramofile wav format not accepted by other sound programs
On Mon, Jan 24, 2005 at 10:27:10PM +1100, Erik de Castro Lopo wrote: > My guess is that gramofile uses its own WAV file writing code instead of > using something proven like libsndfile: > > http://www.mega-nerd.com/libsndfile/ > > Try grabbing the the sndfile-programs package and use sndfile-info on > the file. You can post the output here and I'll have a look. Gramofile uses a forked version of bplay for all audio i/o, and a quick look confirms that it indeed suffers from the usual endianness issues. Nick, feel free to file me a bug on gramofile about this. It should be fairly easy to fix, but I'm a bit busy right now and might need a few days to provide a patch. Regards, Daniel (gramofile maintainer). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289182: kino endianness issues on powerpc
On Mon, Feb 14, 2005 at 05:41:26PM +0100, Michael Schmitz wrote:
> I can confirm the XV problem is the same old problem that a patch had
> been posted for in http://jira.schirmacher.de/jira-kino/browse/KINO-76.
> I've added some #ifdef __BIG_ENDIAN__ around that, the following patch
> should finally fix the display issue:
Err, this patch did fix the display problems for you!? It does not touch
a single line of code that was executed in the Debian build that uses
libdv to do the decoding. (Actually, this is no longer true as of today.
Now with ffmpeg in main, I've uploaded a new version that uses
libavcodec instead of libdv for the decoding part.) Furthermore, it
looks obviously buggy. Eg. the little-endian version of the first loop
uses values Y[0] and Y[1], while the big-endian variant reuses Y[0]
twice. And I can't make sense of the other array indices, either. I was
expecting something like dest_big_endian = bswap_32(dest_little_endian);
maybe that's what was intended, and the current version of the patch
makes little difference with smooth input data? Anyway, what I remember
from years ago, Xv did expect image data in host-endian format with DRI
turned off, and in PCI-endian (little-endian) format with DRI turned on.
I'd be very interested to know whether this still holds true. (Cc'ing
debian-powerpc, hoping someone there might be able to help.)
> --- src/frame.cc.org 2005-02-14 16:59:13.798585200 +0100
> +++ src/frame.cc 2005-02-14 17:14:01.196680184 +0100
> @@ -1052,7 +1052,11 @@
>
> for ( int x = 0; x < width; x += 2 )
> {
> +#if defined __BIG_ENDIAN__ || defined _BIG_ENDIAN
> + *reinterpret_cast( dest ) = Cr[ 0 ]
> + ( Y[ 0 ] << 8 ) + ( Cb[ 1 ] << 16 ) + ( Y[ 0 ] << 24 );
> +#else
> *reinterpret_cast( dest ) = Y[ 0 ] +
> ( Cb[ 0 ] << 8 ) + ( Y[ 1 ] << 16 ) + ( Cr[ 0 ] << 24 );
> +#endif
>
> dest += 4;
> Y += 2;
> @@ -1071,8 +1075,13 @@
>
> for ( int x = 0; x < width; x += 4 )
> {
> +#if defined __BIG_ENDIAN__ || defined _BIG_ENDIAN
> + *reinterpret_cast( dest ) = Cr[ 0 ]
> + ( Y[ 0 ] << 8 ) + ( Cb[ 1 ] << 16 ) + ( Y[ 0 ] << 24 );
> + *reinterpret_cast( dest + 4 ) = Cr[
> 2 ] + ( Y[ 0 ] << 8 ) + ( Cb[ 3 ] << 16 ) + ( Y[ 0 ] << 24 );
> +#else
> *reinterpret_cast( dest ) = Y[ 0 ] +
> ( Cb[ 0 ] << 8 ) + ( Y[ 1 ] << 16 ) + ( Cr[ 0 ] << 24 );
> *reinterpret_cast( dest + 4 ) = Y[ 2
> ] + ( Cb[ 0 ] << 8 ) + ( Y[ 3 ] << 16 ) + ( Cr[ 0 ] << 24 );
> +#endif
>
> dest += 8;
> Y += 4;
>
> Waiting for your audio export fix now :-)
I've uploaded kino 0.75-5 that should make the archive by today's
dinstall run. It includes a comprehensive patch that might fix the
endianness problems with audio. Alas, I had to do some guessing on the
endianness of the input data, so it might actually do worse than before,
but in any case the framework is now in place to fix this with a few
keypresses. The second change in 0.75-5 related to this bug was the
mentioned switch from libdv to libavcodec for video decoding. There's a
small chance that it fixes the display problem out of the box already.
Otherwise, I'll have to apply a cleaned up version of the cited patch.
In any case, this move should significantly boost decoding performance
on non-x86 and bring us a bit closer to getting kino usable on ppc and
friends as well.
Regards,
Daniel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#289182: kino endianness issues on powerpc
On Tue, Mar 22, 2005 at 08:36:01PM +, Paul Brossier wrote:
> On Tue, Mar 08, 2005 at 03:39:16PM +0100, Daniel Kobras wrote:
> > Furthermore, it looks obviously buggy. Eg. the little-endian
> > version of the first loop uses values Y[0] and Y[1], while the
> > big-endian variant reuses Y[0] twice. And I can't make sense of
> > the other array indices, either. I was expecting something like
> > dest_big_endian = bswap_32(dest_little_endian); maybe that's
> > what was intended, and the current version of the patch makes
> > little difference with smooth input data?
>
> well, i am not familiar with these maths, but it does look like
> there's some logic:
>
> LE -> BE
>
> Cr[0] << 24 -> Cr[0]
> Y [1] << 16 -> Y [0] << 8
> Cb[0] << 8 -> Cb[1] << 16
> Y [0]-> Y [0] << 24
Certainly, but as I noted before, this logic is flawed, incorrectly
reusing an old luminance value and shifting the blue component by one
pixel. (In a smooth image, artifacts might be small, though.)
> there is probably a better mean to do so though, ie checking what
> type of conversion is needed according to libavcodec, but it does
> effectively fixes the XV Display of kino.
Actually, we should probably check the value of component_order[] in the
struct returned by XvListImageFormats() and shuffle components as
appropriate, but from the feedback so far, apparently nowadays it is
sufficient to keep the order of YUV components fixed, independent of
host arch. I've attached a patch to this effect, and would welcome
feedback from testers.
> audio seems to work better now. there are a few glitches but at
> least it's not white noise. oh and export to mpeg2 and wav bot
> work.
Great. We're getting closer, it seems. Does the video part of mpeg2
export also work correctly now?
Paul, thanks a lot for looking into this issue!
Regards,
Daniel.
#! /bin/sh /usr/share/dpatch/dpatch-run
## 40_yuvdisplay_endian_fixes.dpatch by Daniel Kobras <[EMAIL PROTECTED]>
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Always unroll YUV formats in same order, independent of host
## DP: endianness.
@DPATCH@
diff -urNad kino/src/frame.cc /tmp/dpep.thGYPG/kino/src/frame.cc
--- kino/src/frame.cc 2005-03-25 00:52:58.0 +0100
+++ /tmp/dpep.thGYPG/kino/src/frame.cc 2005-03-25 00:57:04.0 +0100
@@ -1052,12 +1052,10 @@
for ( int x = 0; x < width; x += 2 )
{
- *reinterpret_cast( dest ) = Y[ 0 ] +
( Cb[ 0 ] << 8 ) + ( Y[ 1 ] << 16 ) + ( Cr[ 0 ] << 24 );
-
- dest += 4;
- Y += 2;
- ++Cb;
- ++Cr;
+ *dest++ = *Y++;
+ *dest++ = *Cb++;
+ *dest++ = *Y++;
+ *dest++ = *Cr++;
}
}
}
@@ -1071,13 +1069,14 @@
for ( int x = 0; x < width; x += 4 )
{
- *reinterpret_cast( dest ) = Y[ 0 ] +
( Cb[ 0 ] << 8 ) + ( Y[ 1 ] << 16 ) + ( Cr[ 0 ] << 24 );
- *reinterpret_cast( dest + 4 ) = Y[ 2
] + ( Cb[ 0 ] << 8 ) + ( Y[ 3 ] << 16 ) + ( Cr[ 0 ] << 24 );
-
- dest += 8;
- Y += 4;
- ++Cb;
- ++Cr;
+ *dest++ = *Y++;
+ *dest++ = *Cb;
+ *dest++ = *Y++;
+ *dest++ = *Cr;
+ *dest++ = *Y++;
+ *dest++ = *Cb++;
+ *dest++ = *Y++;
+ *dest++ = *Cr++;
}
}
}
Re: Building mozart-gtk on powerpc [request for help]
On Tue, Aug 24, 2004 at 06:21:57PM +0200, Kevin Glynn wrote: > fyi, it is because va_list is declared as a one-element array of > structs on powerpc, unlike other architectures so code like: > > va_list Arg4 = (va_list) OZ_getForeignPointer((*(_OZ_LOC[(4)]))); > > fails on powerpc, because you can't cast to an array. And you may not assign to a va_list. Use va_copy() instead to be portable. Daniel.
Re: Building mozart-gtk on powerpc [request for help]
On Wed, Aug 25, 2004 at 01:52:13PM +0200, Kevin Glynn wrote: > I don't see how va_copy will help me. OZ_getForeignPointer(...) > returns a void*, so I will still need to cast it to a va_list to be > able to call va_copy. Ah, I wasn't quite sure what you're trying to do. A va_list is an object you can read and copy, but you cannot construct it or assign to it. Regards, Daniel.
Re: Laptop Mode
On Mon, Sep 13, 2004 at 08:16:09AM +0200, Jens Axboe wrote: > On Sun, Sep 12 2004, Bryan Forbes wrote: > > 1. What's the difference between that and noflushd? > > noflushd is dumb, Heh, don't call the baby dumb. It's had a difficult childhood; evil parents that didn't care. No, really, a bit retarded maybe... > it just tries to postpone writes. laptop mode is more > involved, the vm knows when the computer is in laptop mode. > additionally, laptop mode can do things like automatic flushing of dirty > data when you spin your drive up for other activity. The latter being included in noflushd as well. It comes with a few more fancy feature like different policies per disk, optionally preventing spindown when machine is used interactively, etc. Oh, and it works with kernels that predate the laptop-mode patch. The ordinary laptop user won't care, and is usually better off with laptop-mode these days. Regards, Daniel.
Re: Laptop Mode
On Tue, Sep 14, 2004 at 08:32:28AM +0200, Jens Axboe wrote: > On Mon, Sep 13 2004, Daniel Kobras wrote: > > On Mon, Sep 13, 2004 at 08:16:09AM +0200, Jens Axboe wrote: > > > additionally, laptop mode can do things like automatic flushing of dirty > > > data when you spin your drive up for other activity. > > > > The latter being included in noflushd as well. It comes with a few more > > How does that work reliably? Reliability is a different matter. The current implementation watches the read stats for a sleeping disk. If new activity is detected, the disk is synced. I'm quite aware of the shortcomings in this heuristic, but it catches the common case, and works fairly well in practice. > > fancy feature like different policies per disk, optionally preventing > > spindown when machine is used interactively, etc. Oh, and it works with > > kernels that predate the laptop-mode patch. The ordinary laptop user > > won't care, and is usually better off with laptop-mode these days. > > Sounds useful. laptop mode support in kernel should only do the > absolutely necessary, like spin-up detection. You should adapt your > stuff to laptop mode. > > The noflushd approach was never very clean imho, it was a case of 'this > is where we can do it with a hook' and not designed in place. It was a kludge from the very beginning, when bdflush was pushed into the kernel, but its sleep support had to stay out. Therefore, noflushd was coded as an all-userland solution, and has been hunting for information that would be readily available in-kernel ever since. Actually, I'd guess the biggest part of the code deals with digging stuff out of /proc. For this reason, it might be better to throw away all the cruft and include the few features in a clean, new, and shiny laptop-mode-daemon. Hey, even noflushd's name is crappy! Regards, Daniel.
Re: libdv2-dev? battery monitor?
On Tue, Dec 07, 2004 at 11:38:24AM +0100, peter plessas wrote: > i am searching for libdv2-dev via apt, but only have libdv4 available. > Does anyone know the appropriate apt sources? libdv2-dev is obsolete and has been superceded by libdv4-dev. You can get old packages from snapshot.debian.net, but I recommend that you fix whatever still requires libdv2-dev to use libdv4-dev instead. Daniel.
Re: ext2 -> ext3
On Mon, Feb 02, 2004 at 05:53:59PM +0100, mammique wrote: > i'd like to resize an ext3 (i removed OSX, so i want to merge my ext3 > home partition with), but parted don't want ext3 fs, it's ok, i just > need to switch to ext2, resize, and switch again to ext3. But the only > way i know to switch from ext3 to ext2 is removing the .journal file in > the root directory, but it's not present ?! Do ext3 works the same on > powerpc as on x86 (my x86 machines have a .journal file), what's wrong > doc ? how to switch to ext3 fs ? Use tune2fs -O^has_journal /dev/hdaX to switch to ext2, tune2fs -j /dev/hdaX to switch back to ext3. Regards, Daniel.
Re: Screenshot from vt
On Sun, Apr 25, 2004 at 06:48:33PM +0200, Elimar Riesebieter wrote: > I want to make a screenshot from a _VirtualTerminal_, well > known as console, and not from X ;-) If this is an option for you, run screen and use its hardcopy feature (Ctrl-a h). Regards, Daniel.
