Segmentation fault when running ldm

My goal: TV-out without having to worry about running another whole X system with compiz and resources used
up (what seems nvidia is doing with their drivers)

Kubuntu
2.6.22-14-generic

I tried using the ubuntu em8300 driver packages but couldn't figure out how to get them running (never could
install the module or get /dev/83* devices)

I downloaded the newest stable from dxr3.sourceforge.net and followed instructions as best as I could.
I think I did the kernel stuff properly but somehow a little confused with the ubuntu way of kernel
recompilation (was able to do a make menuconfig but the following 'make' failed with nothing todo),  I then
downloaded the supposed dep modules for the kernel and had to assume that was all that was needed.
continuing on...
everything compiles with a hitch and goes well until

I get to ./ldm and it returns a SEGMENTATION FAULT

good news: it creates /dev/em8300* for what appears 4 cards 
crw-rw--w- 1 root root 121,  0 2008-03-02 01:07 /dev/em8300-0
crw-rw--w- 1 root root 121,  4 2008-03-02 01:07 /dev/em8300-1
crw-rw--w- 1 root root 121,  8 2008-03-02 01:07 /dev/em8300-2
crw-rw--w- 1 root root 121, 12 2008-03-02 01:07 /dev/em8300-3
crw-rw--w- 1 root root 121,  1 2008-03-02 01:07 /dev/em8300_mv-0
crw-rw--w- 1 root root 121,  5 2008-03-02 01:07 /dev/em8300_mv-1
crw-rw--w- 1 root root 121,  9 2008-03-02 01:07 /dev/em8300_mv-2
crw-rw--w- 1 root root 121, 13 2008-03-02 01:07 /dev/em8300_mv-3
crw-rw--w- 1 root root 121,  3 2008-03-02 01:07 /dev/em8300_sp-0
crw-rw--w- 1 root root 121,  7 2008-03-02 01:07 /dev/em8300_sp-1

Re: SEGMENTATION FAULT bypassed with new issues

I finally got it going somehow (random buttons/reboots/compiles/slot swaps/etc)

It plays files but I am now having 2 issues.

1) I need to be root as the others don't have permission to write to /dev/em* (I think this is easy to fix for a
more permanent solution?) [I did a chown to my username but I think that will reset with a reboot with the way
the drivers load?]
2) playback with a avi file just over 4 minutes has sound end at 3 1/2 minutes
single core cpu (file plays normal under non-dxr3 vo)
top set to 0.5sec updates reports 75%id->85%id

I tried some of the options listed but the only thing that did anything was autosync (didn't fix the issue,
just didn't have the message pop-up in the normal amount of time)

The exiting was me just quiting as it would have just continued until both audio and video finished.

sudo mplayer -vo dxr3 -ao alsa  new1.avi
MPlayer 2:1.0~rc1-0ubuntu13.1 (C) 2000-2006 MPlayer Team
CPU: AMD Opteron(tm) Processor 144 (Family: 15, Model: 39, Stepping: 1)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing new1.avi.
AVI file format detected.
VIDEO:  [XVID]  640x480  24bpp  30.000 fps  827.1 kbps (101.0 kbyte/s)
[VO_DXR3] Opened: /dev/em8300-0.

EEPROM and DVD zones

Hi,

I thought it would be possible to identify different models of 
Hollywood+/DXR3 boards by reading the contents of the embedded EEPROM.

Right now, I have received 40 model reports, with 20 different EEPROM 
contents. That's a lot, and I can hardly think that there reaaly are 
that many different models of Hollywood+/DXR3 boards. Moreover, that 
only makes a mere 2 reports per EEPROM content on average, so I guess 
more are still missing.

Thinking a little more, I thought that the EEPROM may be use to store 
some region information for the Windows driver. Googling around confirms 
this: the current zone is supposed to be stored on some EEPROM, as well 
as a counter that allows only 5 region changes. (Moreover, it is 
possible to reset the counter, but only 5 times; I guess there is a 
second counter to handle this.)

If we can find where this information is stored on the EEPROM, then it 
becomes possible to define a mask that might drastically reduce the 
number of different EEPROM contents, and hopefully make it possible to 
identify the different models.

Note that the EEPROM contents of Hollywood+ and DXR3 boards seem quite 
different. The location of this information may be different as well.

Reverse-engineering the Windows driver would probably work, but it would 
certainly be a hard task. I think a much easier solution is to play with 
the Windows driver, changing the region several times, and resetting the 
counter, and using the Linux driver to dump the EEPROM contents after 

Re: ALSA audio with em8300

Nicolas,

Sorry for the delay.

I am little confused; shouldn't the modprobe line be audio_driver=alsa
rather than sound_driver=alsa? I have tried both but it doesn't seem to
make much difference. I can't get audio to work with my dxr3 using any of
oss,osslike or alsa.

> Looks fine; ALSA sould work.
> Still with "sound_driver=alsa", does "mpg123 -o alsa -a default:EM8300
> yourfile.mp3" work fine?
>

No. Here is the output:

mpg123 -o alsa -a default:EM8300 /music/Dance/Funky/Cameo\ -\ Word\ Up.mp3
ALSA lib confmisc.c:768:(parse_card) cannot find card 'EM8300'
ALSA lib conf.c:3510:(_snd_config_evaluate) function snd_func_card_driver
returned error: No such device
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:3510:(_snd_config_evaluate) function snd_func_concat
returned error: No such device
ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
ALSA lib conf.c:3510:(_snd_config_evaluate) function snd_func_refer
returned error: No such device
ALSA lib conf.c:3982:(snd_config_expand) Evaluate error: No such device
ALSA lib pcm.c:2145:(snd_pcm_open_noupdate) Unknown PCM default:EM8300
[alsa.c:144] error: cannot open device default:EM8300
[audio.c:505] error: failed to open audio device

** AUTOMATIC CONFIGURATION needs testers **

Hi,

I think I have finally managed to implement detection of models of 
H+/DXR3 boards and automatic configuration for them.

The code was committed to my mercurial repository. It would be nice if 
as many people as possible could give it a try, to ensure it works as 
fine as I hope.

To give it a try, run:

$ hg clone http://dxr3.sf.net/hg/em8300-nboullis
$ cd em8300-nboullis/modules/
$ make
$ su
# make install
# modrobe em8300 # Yes, forget about all your hardware-specific configuration!

and enjoy!

Note that the good encoder module is expected to be loaded 
(and configured, for the adv717x module) automatically.

You may also have a look at your kernel log and see something like
  em8300.c: detected card: Hollywood+ type 1.

Please provide some feedback!

Cheers,

Re: ** AUTOMATIC CONFIGURATION needs testers **

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Dxr3-devel mailing list
Dxr3-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

Re: ** AUTOMATIC CONFIGURATION needs testers **

On Wednesday 05 March 2008, Nicolas Boullis wrote:

> Note that the good encoder module is expected to be loaded
> (and configured, for the adv717x module) automatically.
>
> You may also have a look at your kernel log and see something like
>   em8300.c: detected card: Hollywood+ type 1.
>
> Please provide some feedback!

Does not work for me :(

em8300: EM8300 8300 (rev 2) bus: 2, devfn: 32, irq: 20, memory: 0xe7000000.
em8300: mapped-memory at 0xe0c80000
em8300: using MTRR
em8300.c: unable to identify model...
em8300_main.o: Chip revision: 2

This is a card I normally configure with:

options em8300 dicom_other_pal=0 dicom_control=0 audio_driver=oss
options adv717x pixelport_other_pal=0 output_mode=yuv

/proc/em8300/0 right after the above modprobe which failed to recognize the 
card:

----- Driver Info -----
em8300 module version hg-37d8ce9c7f65
Card revision 2
Chip revision 2
No known video encoder found.
EEPROM data:
        0000000000000000000000000000000000000000000000000000000000000000
        0000000000000000000000000000000000000000000000000000000000000000
        73a95aa4f4fb8f2a6b647199d3ffd4d700000000000000000000000000000000
        0000000000000000000000000000000000000000000000000000000000000055
        ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
        ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
        ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
        ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
EEPROM checksum: 88d608b3599fabd0cecc5a0b504670c4
Memory mapped at address range 0xe0c80000->0xe0d80000 (FIFOs using MTRR)
Microcode not loaded
Analog audio output

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: ** AUTOMATIC CONFIGURATION needs testers **

Hi,

could somebody please provide a tarball ?

S.

Am Mittwoch, 5. März 2008 01:04:01 schrieb Nicolas Boullis:
> Hi,
>
> I think I have finally managed to implement detection of models of
> H+/DXR3 boards and automatic configuration for them.
>
> The code was committed to my mercurial repository. It would be nice if
> as many people as possible could give it a try, to ensure it works as
> fine as I hope.
>
> To give it a try, run:
>
> $ hg clone http://dxr3.sf.net/hg/em8300-nboullis
> $ cd em8300-nboullis/modules/
> $ make
> $ su
> # make install
> # modrobe em8300 # Yes, forget about all your hardware-specific
> configuration!
>
> and enjoy!
>
> Note that the good encoder module is expected to be loaded
> (and configured, for the adv717x module) automatically.
>
> You may also have a look at your kernel log and see something like
>   em8300.c: detected card: Hollywood+ type 1.
>
>
> Please provide some feedback!
>
>
> Cheers,
>
> Nicolas
>
> PS: for those who don't want to use mercurial, I pack a tarball. Feel
> free to ask on this list, and I'll see how many people request it.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Dxr3-devel mailing list
> Dxr3-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dxr3-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: ** AUTOMATIC CONFIGURATION needs testers **

Hi,

On Wed, Mar 05, 2008 at 08:53:16PM +0200, Ville Skyttä wrote:
> On Wednesday 05 March 2008, Nicolas Boullis wrote:
> 
> > Note that the good encoder module is expected to be loaded
> > (and configured, for the adv717x module) automatically.
> >
> > You may also have a look at your kernel log and see something like
> >   em8300.c: detected card: Hollywood+ type 1.
> >
> > Please provide some feedback!
> 
> Does not work for me :(

Sorry, that's a point I forgot to mention. I got 40 reports, and I could 
find 4 (I should perhaps even say 3, since "Hollywood+ type 1" and "DXR3 
with ADV7175A" look much alike and apparently use the same 
configuration) "kinds" of boards to classify 39 of them. As for the 
40th, it's yours, according to your report, it is a Hollywood+ type 1 
with an ADV7170 encoder, but it looks like a DXR3 with a BT865...

Since this first implementation is only a kind of a "technology preview" 
and I expect some improvements, I though I would not support it at 
first. Not that you can force the model of your card with the parameter 
"card_model=3"; it's still easier than finding the correct set of 
parameters.

Ville, did you buy this board new? Do you have any reason to think its 
hardware was modified? Do you know if it works with the windows drivers?

The second point is that this technology preview is almost not using the 
eeprom's content. (If I decided to merge "Hollywood+ type 1" with "DXR3 
with ADV7175A", and to mis-detect Ville's card, I could avoid reading 
the eeprom at all.) But I think the eeprom content might give some 
interesting information, once we are able to mask the relevant parts 
(DVD region and number of tries). Hence, it would still be useful if one 
could try playing with the windows driver and change the region (see my 
message on this topic). Even if it seems to me that it will work fine 
for most, I don't think it is finished yet.

Cheers,

Nicolas

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: ** AUTOMATIC CONFIGURATION needs testers **

Hi,

On Wed, Mar 05, 2008 at 02:01:36AM +0100, Christian Gmeiner wrote:
> Hi Nicolas,
> 
> em8300: EM8300 8300 (rev 2) bus: 0, devfn: 72, irq: 5, memory: 0xcfe00000.
> em8300: mapped-memory at 0xf8980000
> em8300: using MTRR
> em8300.c: detected card: DXR3 with ADV7175A.

Is your card actually a DXR3 one with an ADV7175A video encoder?

> PS: I have here a resume/suspend patch almost ready to commit :)

This sounds interesting, especially since I have absolutely no idea how 
it is supposed to work...

Cheers,

Nicolas

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/