Oh, duh.. I just clued into what that means: -40 was probably an errno return from some function that normally returns a pointer on success.

So.. -40 = -ELOOP = "Too many levels of symbolic links".

Does that filesystem have a symbolic link that points at itself, or at the same directory that contains the link, or something ?

A way to perhaps get more debug info, would be to kill off the player after booting, and then rerun it with strace:

rwm
strace -f player &> /drive0/log
rom

Then post the /drive0/log file here as an attachment.

In case you don't already have strace, I'm attaching it again to this post. Put it onto your empeg, mark it as executable, and give the full pathname for it in the above command.

Cheers

Hi,

I have to demonstrate my inexperience again.

How do I load the strace into the the player and make it executable? After it is loaded is it just a reane and permissions thing?

Do you want it loaded into root?

Thanks,

Ross

Using your favourite serial terminal program:

Or just FTP it over, which might be simpler than Zmodem in this era.

Doh! Forgot that Hijack has FTP. Nah. Go old-school.

Hi,

I tried this, the log file is not being updated. I put the strace executable in root. This is what I am doing...


After the player boots, I do the following

Prolux 4 empeg car - 2.1434 Jul 5 2004
Vcb: 0x4086d000
q
Dead temp.sensor, status=0x00
Restored terminal settings
Remounting first music partition read-only
Remounting second music partition read-only
No secondary hard disk
Player exited normally: 0
Switching to shell-player loop
Starting bash.
empeg:/empeg/bin# rwm
empeg:/empeg/bin# strace -f player &> /drive0/log
empeg:/empeg/bin# rom
empeg:/empeg/bin# exit
logout
Shell exit
Starting player
Timezone: GB
Hijack: intercepting config.ini

player.cpp : 385:empeg-car 2.01 2004/07/06.
Prolux 4 empeg car - 2.1434 Jul 5 2004
Vcb: 0x4086d000


After this, I loaded emplode and loaded a few smaller (5MB), which it worked, then a few more small files. It even worked with a 41MB load. When I tried a 120MB load, it choked (actually, it completed instantly).

I checked the log file on /drive0/log and there was no change from the time it was created and only had 32 Bytes. When I tried to stop the player, it said that it couldn't find a shell and just continued to complete an exit. I was however, able to ftp into the player and the log file was unchanged.

After I powered down the player, and rebooted, it returned a shell prompt when I exited. I checked the log file and it was unchanged (byte count, date & time). The player operated normally (played the tunes I loaded except the 3 songs that made up the 120MB files).

What am I doing wrong?

Ross

strace -f player &> /drive0/log

Load the database and all while that instance of the player (above) is running. Do not control^C or exit until done with the test.

??

Hi,

Per the above listing, you do want me to quit, set-up the strace, and then ** Not exit ** right?

I tried that first (not exiting). It was not able to find the player with emplode, it looked like the player software wasn't running. I think I was able to ftp into the player though. After I exited, emplode could see the player.

That's why I exited. That was the only way emplode would see the player.

Are writes to the log file not allowed by permissions or the rom command?


Guess I need a list of commands to cover my lack of understanding (yeah, I know I'm embarrased to ask, I'm sure you have other things to do...).

Thanks,

Ross

The player will run V E R Y S L O W L Y with strace, so be extra patient. The log file it produces will be enormous. The "rwm" command stands for "readable/writable music" partition, which is the biggest place to save a big log file.

Since the whole idea is to capture an "strace" log of the player, it is not useful to run the player without strace, because doing that won't give us the log.

So if you cannot get it working under strace, then forget about it. It just might not be feasible.

"strace" stands for "system-call tracer". It's a program that installs itself between the application ("player") and the Linux kernel (operating system), and records every single event where the application invokes any kernel service. So it's a great way to see what a program is really doing under the hood, especially if the program is crashing at some point.

Cheers

What are you actually doing to make the player crash, anyway?

You said something about "tried a 120MB load", but what does that statement actually mean?

Thanks

I would assume that means he tried to transfer 120 mb of music to the empeg via emplode.

I might assume that too, but I'd really like know.
And it might be useful to know at what stage the thing dies -- during the file transfers, or during the database build ?

cheers

I wonder if any of the player code "steals bits" from sector/block numbers for other purposes, eg. an "in use" bit for sectors in the dynamic data partition?

Because with a 1TB drive, 31 bits are needed just to address sectors, leaving only one bit "spare".

Roger?

Not as far as I'm aware. It's unlikely. That's not the kind of hack we'd have gone for. Validating checksums and block bitmaps are more in keeping with the empeg style.

Might it be a bit faster/more feasible if the strace logging is
restricted to a particular set of calls?

Hi,

More information...

Mark asked:

I would assume that means he tried to transfer 120 mb of music to the empeg via emplode.


I might assume that too, but I'd really like know.
And it might be useful to know at what stage the thing dies -- during the file transfers, or during the database build ?


Answer:

Yes it was 120MB of song database load through emplode. Mark has a valid point, I do weird things sometimes. <grin>

I hope what is listed below might help with his second question.
*****************************************************************

strace information
------------------
I was able to get strace to work. What I hadn't realized is that I needed to tell it where strace was. I decided to put strace in the root of drive0 (I thought it would run from the root of the empeg, I thought wrong). When I looked at the contents of the log file, it kept saying it was a bad command. As soon as I pointed to where strace was, as in ./strace ...., it worked. The log file does quickly fill with LOTS of data with the system call data. Dumb mistake, I know.

Unfortunately, as soon as I used it, in emplode, it needed to perform a Check on the Media. Without strace, it doesn't need to. Even on known good drives with fully rebuilt media (doesn't matter the size - 250GB or 500GB or interface type - EIDE or SATA), needs 2 passes to go through it, and dies. This included a drive with and without song database, all drives had been fixed for the missing tags and include the rom lock. I can re-create a log file if you need it.



So... I wanted to find out if it is a software or hardware problem. Now that I have a better understanding of ftp (didn't know it had the capability or how to use it a couple of days ago), I was able to get a better definition of what works and what doesn't.


I prepared a 250GB EIDE drive and placed 1GB of song database on it through emplode. I then opened an ftp session with the player, directed to the fids on drive0 and changed to an ftp session in Windows. I created a directory for the fids on my PC and copied the fids database from the player to the new fids directory on my PC. That obviously took a few minutes to do.

I then changed out the player drive, built a new drive on the player (put in the 500 GB SATA interfaced drive), opened a HyperTerm, quit the player software, made the music read/writable (RWM), and exited. I know this is dangerous, but, this is all development anyway.

I opened an ftp session in Windows and copied about 350MB of the fids database from the Windows directory into the drive0/fids directory. This took some time as well. After the copy completed, I mounted the drive (mount -n -o remount,rw,nocheck /drive0 - probably not neccessary at this point), CTRL^D to force a rebuild, Ctrl^C to stop it, and rom to lock.

It worked! The player has all that I down loaded, the structure is correct. It operates normally.

So I am able to copy large files across the SATA Adapter through an ftp session onto a 500 GB drive which points to some kind of other problem. Not a full fuzzy that the hardware path works but it helps define the problem more.


I could run strace in the ftp session if you want it as well.


What do you think?

Thanks,

Ross

So it sounds like something in the emplode<-->player path was causing the problems. Again, since it's closed source, our best bet would be to see an strace log of that happening.

The reason it keeping doing "media checks" is probably because we mounted the music partition read/write so that we could put the huge strace log there.

So, to get this trace to work, I guess we'd need to find somewhere different to put the log file. Like perhaps a second non-built drive, or an otherwise unused partition on the main drive.

This could get complicated to explain, though.

Cheers

Hi,

I tried to do something like what you asked (kind of a feeble attempt). I was still bothered by the rwm of the file system being open, it still got hung up on the media check, but I got a longer log file.

I used a 12GB drive that the file system was missing on, and directed the log file to that drive (drive1).

I have attached the strace file that I sent to drive1.


I can trash this drive if you will help to provide you the data you need.

Thanks,

Ross

If you want to continue with this, then the idea is to get rid of the media check issue, by NOT USING rwm. If you can send the log elsewhere, not to the music drive, then the music drive does not need to be writeable any more, so no rwm command.

Cheers

Hi,

Dumb question, can it be sent to my PC via ftp?

Ross

After the file is created locally, you can use FTP to transfer it to your PC.

If you want it to go directly to your PC, then you'll need more software on the empeg (this gets complicated rather quickly).

Eg. NFS configured on the empeg, so it can mount a (Linux) PC filesystem for writing out the log file directly.

Or perhaps run telnetd on the empeg, so that you can telnet in from another PC (putty on MS-Win) and run the strace player from within the telnet session. No log file required with this method, instead just let strace spew its output directly over telnet to the remote PC. Save the session log afterwards to save the log messages.

But again, this may all be beyond your current level of expertise.

Cheers

Hi,

Yup, that stuff is way beyond my expertise level.

Ross

Okay. Another way to capture the strace log locally on the empeg, is to install a second drive, which is not formatted for empeg use.

So basically start with a blank second (slave) drive -- no partitions, and boot into the empeg software. Hit control^C to kill off the player and get a command prompt.

At the command prompt, format the drive. Use as small a drive as you have available to you, because the larger the drive, the slower this step will be:

mke2fs /dev/sdb ## and say "y" when prompted

Then, mount it r/w:

mkdir /t ; mount /dev/sdb /t

If that works, then you can try the strace, without the rwm:

/strace player &> /t/strace.log

And afterwards use FTP to retrieve /t/strace.log from the empeg to a PC.

Cheers

Hi,

I tried this and it produced the following results (I probably did something wrong):



Starting bash.
empeg:/empeg/bin# cd ../..
empeg:/# cd drive1
empeg:/drive1# ls -la
total 2
drwxr-xr-x 2 0 0 1024 Jun 2 1999 .
drwxr-xr-x 15 502 220 1024 Nov 24 13:28 ..
empeg:/drive1# cd ..
empeg:/# mke2fs /dev/sdb
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Could not stat /dev/sdb --- No such file or directory

The device apparently does not exist; did you specify it correctly?
empeg:/# mke2fs /dev/hdb
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Could not stat /dev/hdb --- No such file or directory

The device apparently does not exist; did you specify it correctly?
empeg:/# mke2fs /dev/hdc
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
/dev/hdc is entire device, not just one partition!
Proceed anyway? (y,n) y
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hdc is mounted.
mke2fs: Device not configured while trying to determine filesystem size
empeg:/#


I tried to show that drive1 was blank. Then I tried the mke2fs command on sdb, it wasn't able to find it. Then on hdb, then it hdc (which it found). It doesn't look like it was mounted (no file system of course)?

What am I doing wrong?

Thanks,

Ross

Oh, right. I forgot that the empeg screws around with drive names in a non-standard fashion -- it's trying to assign the same names as a Mk1 empeg would.

So just change all occurances of "sdb" to "sdc" and try again.

Cheers

Hi,

Still having trouble. It says that it can't stat the drive. It has the same response as above shown below:

empeg:/empeg/bin# mke2fs /dev/sdc ##
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Could not stat /dev/sdc --- No such file or directory

The device apparently does not exist; did you specify it correctly?
empeg:/empeg/bin#


It does the same thing with and without the ##. I also went dierctly to the /bin directory and ran it from there with the same result.


I changed drives (another 12GB drive), tried it with hdc (instead of sdb or sdc), and it formatted fine (12GB, 90 inode tables). I was not able to get drive1 to mount. It gave the following response:

empeg:/empeg/bin# mkdir /t ; mount /dev/sdc /t
mkdir: cannot create directory `/t': File exists
mount: you must specify the filesystem type
empeg:/empeg/bin# mkdir /t ; mount /dev/hdc /t
mkdir: cannot create directory `/t': File exists
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended


I tried the strace as written above. It would not write an strace.log. I used the older method (./strace -f player &> /drive1/log), and it did write a 60k log file to drive1.

I tried to run emplode and it still thinks it needs to check the media and dies - but does write the log file on drive1. Is this because I am using hdc instead of sdc?

Meanwhile, I was able to format drive1 and write an strace log file to it. We at least know the hardware path works to drive1.

I still have something wrong somewhere, I guess.

What do you think?

Thanks for your time,

Ross

Except that the empeg uses hda and hdc, not sda and sdc.

Duh... you get that, Ross?

Thanks Roger!

Hi,

Yeah, that's what I did.

The responses above were using hdc.

It still had a problem somewhere.

Thanks,

Ross