Got my new Mk2 and i want to replace 1.02 as the player reports or 1.03 as the kernel reports with 2.0b7

I am pretty sure my connection to the empeg is OK, cause i can "cat /dev/tts/0" and then power cycle the empeg to see the boot messgeas.

But when i run emptool it just says
empeg-car Upgrade client.
empegupgrade: Using upgrade file '../car2-consumer-v2.00-beta7.upgrade' to device '/dev/tts/0' (115200 baud)
Checking upgrade file integrity [100%]
Pumping player software
Upgrade file checked [100%]
ERROR: 5 empeg unit not found

Upgrade failed :-(

Upgrade failed with error 0x8004004c
Note that it doesn't wait looking for the unit, it exits out with that error pretty much instantly.

1) Did you install the latest version of emplode, and are you sure the EmpegUpgrade.exe you're running is the correct one from that version?

2) Did you leave the player power unplugged until it asked you to apply power?

3) Did you get a fresh copy of the upgrade file using GetRight to be absolutely certain the file was not corrupted?

4) Are you sure the cable and COM port are good? Can you type things into hypterterminal and have the player respond? Just seeing the boot messages is not necessarily enough. The communication needs to work both ways.

1)Indeed i was using beta3. I've upgraded to beta7 now, same results

2) it never gets to the point of asking me to apply power

3)The upgrade file passes the integrity check of the uploader. I don't
use GetRight but i've downloaded another copy with wget and it's
identical, and gives identical faliure results

4) I was using some serial cable i had used on the Mk1. Just tried the
cable that came with the Mk2 (looks identical on the outside) same
result. I'm pretty sure it is some problem with serial communication
though, i think i had this problem on my Mk1 when putting v2b3 on it and
i resorted to loading windows under vmware and using emplode to do the
upgrade, so it wasn't the serial cable or the com port.

Arggg and now the BBS has crashed again, or at least my route to it has
disappered again... yay, 2 hours later its back...

OK, here's some more info

1) i can view the boot msgs when i cat /dev/tts/0

2)i can connect with emptool over usb (if i force usb buffering) and it tells me i need to upgrade the player software because emptool is using a newer protocol

3)i can't connect with emptool over serial. or with upgclient over serial. It just errors out straight away, it doesn't stop and wait for me to power on the empeg. Perhaps it is having trouble opening the com port rather than reading from it? But i'm running as root so it should be able to.

4) i've tried the 2nd com port /dev/tts/1 with the same results

[root@danski empeg-car]# head /proc/tty/driver/serial
serinfo:1.0 driver:5.05c revision:2001-07-08
0: uart:16550A port:3F8 irq:4 baud:115200 tx:2119 rx:9104 fe:76 brk:5
1: uart:16550A port:2F8 irq:3 baud:9600 tx:195 rx:0
2: uart:unknown port:3E8 irq:4
3: uart:unknown port:2E8 irq:3
4: uart:unknown port:1A0 irq:9
5: uart:unknown port:1A8 irq:9
6: uart:unknown port:1B0 irq:9
7: uart:unknown port:1B8 irq:9
8: uart:unknown port:2A0 irq:5
[root@danski empeg-car]# ./emptool /dev/tts/0
4001 Failed to open device /dev/tts/0, errno:2
[root@danski empeg-car]# ./emptool /dev/ttyS0
4001 Failed to open device /dev/ttyS0, errno:17
[root@danski empeg-car]# ./emptool /dev/ttyUSB0
Unknown device character 188,0 - assuming serial buffering
4001 Failed to open device /dev/ttyUSB0, errno:17
[root@danski empeg-car]# ./emptool --usb /dev/ttyUSB0
2000 Checking connection
[Done]Protocol version of your player (4) is too old for emptool (6)
Please obtain an upgrade for your player
[root@danski empeg-car]# ./emptool /dev/usb/tts/0
Unknown device character 188,0 - assuming serial buffering
4001 Failed to open device /dev/usb/tts/0, errno:2
[root@danski empeg-car]# ./emptool --usb /dev/usb/tts/0
2000 Checking connection
[Done]Protocol version of your player (4) is too old for emptool (6)
Please obtain an upgrade for your player
[root@danski empeg-car]# ./upgclient ../car2-consumer-v2.00-beta7.upgrade
empeg-car Upgrade client.
empegupgrade: Using upgrade file '../car2-consumer-v2.00-beta7.upgrade'
to device '/dev/ttyS0' (115200 baud)
Checking upgrade file integrity
[100%]
Pumping player software
Upgrade file checked
[100%]
ERROR: 5 empeg unit not found

Upgrade failed :-(

Upgrade failed with error 0x8004004c
[root@danski empeg-car]#

Well...
By running emplode under win95 under vmware under linux i was able to do the upgrade.
So i guess the cabling is fine, must be some problem with the setup of my com ports under linux and emptool.

However, during the upgrade process it complained about a bad response from pump. And now when it boot it says no hard disk found contact support It found it before the upgrade...

However, during the upgrade process it complained about a bad response from pump. And now when it boot it says no hard disk found contact support

Pump error is a FAQ Entry.

Have phun.

It has also been reported that a bad pump error can be caused by a loose or faulty disk drive cable.

I'm guessing it's this one, seen as the kernel can't find my disc anymore.

I'd open it and check but i don't wanna void the warrenty so i'll wait to here back from them.

OK, so there i was writing a nice bug report to send to bugs@empeg, going through all the steps to demonstrate the problem when whadayaknow, it works!

I've figured it out, i can connect over serial no probs, with my normal user account. If i run emptool or upgclient as root then it won't connect. This makes no sense to me at all, becuase root should have full access to everything.

[dantheperson@danski empeg-car]$ ./emptool --serial /dev/tts/0
2000 Checking connection [Done] 2121 Downloading
[...snip...]

[root@danski empeg-car]# ./emptool --serial /dev/tts/0
4001 Failed to open device /dev/tts/0, errno:2

[dantheperson@danski empeg-car]$ ./emptool --serial /dev/tts/0
2000 Checking connection [Done] 2121 Downloading
[...snip...]

[root@danski empeg-car]# ./emptool --serial /dev/tts/0
4001 Failed to open device /dev/tts/0, errno:2

2 is ENOENT, file not found. What exactly are the permissions on /dev/tts/0? Isn't that a devfs filename? in which case I expect you should be complaining to Mr Gooch on linux-kernel (it seems you might as well; everyone else on linux-kernel does).

Peter

Yeah, mandrakes been running devfs for a while now.

[dantheperson@danski JEmplode_2.0]$ ls -l /dev/tts/0
crwxrwxrwx 1 danthepe tty 4, 64 Jan 31 00:16 /dev/tts/0

(yes i've been playing with the permissions.)
Everyone has read write but root can't see it... odd.

Everyone has read write but root can't see it... odd.

# echo foo <>/dev/tts/0

# strace emptool --serial /dev/tts/0

Peter

[root@danski empeg-car]# echo foo <>/dev/tts/0
foo
[root@danski empeg-car]# strace ./emptool --serial /dev/tts/0
execve("./emptool", ["./emptool", "--serial", "/dev/tts/0"], [/* 44 vars */]) = 0
uname({sys="Linux", node="danski", ...}) = 0
brk(0) = 0x80b3bb4
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=59585, ...}) = 0
old_mmap(NULL, 59585, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3) = 0
open("/lib/libz.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\36"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=55576, ...}) = 0
old_mmap(NULL, 58480, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40026000
mprotect(0x40033000, 5232, PROT_NONE) = 0
old_mmap(0x40033000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xc000) = 0x40033000
close(3) = 0
open("/lib/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 P\0\000"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=554033, ...}) = 0
old_mmap(NULL, 91164, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40035000
mprotect(0x40044000, 29724, PROT_NONE) = 0
old_mmap(0x40044000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xe000) = 0x40044000
close(3) = 0
open("/lib/libm.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340H\0"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=139200, ...}) = 0
old_mmap(NULL, 141716, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4004c000
mprotect(0x4006e000, 2452, PROT_NONE) = 0
old_mmap(0x4006e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x21000) = 0x4006e000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\306"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1285480, ...}) = 0
old_mmap(NULL, 1301800, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4006f000
mprotect(0x401a4000, 36136, PROT_NONE) = 0
old_mmap(0x401a4000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x134000) = 0x401a4000
old_mmap(0x401a9000, 15656, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401a9000
close(3) = 0
mprotect(0x40026000, 53248, PROT_READ|PROT_WRITE) = 0
mprotect(0x40026000, 53248, PROT_READ|PROT_EXEC) = 0
munmap(0x40017000, 59585) = 0
getrlimit(0x3, 0xbffff744) = 0
setrlimit(RLIMIT_STACK, {rlim_cur=2044*1024, rlim_max=RLIM_INFINITY}) = 0
getpid() = 23906
rt_sigaction(SIGRT_0, {0x4003ed70, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x4003e0c0, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_2, {0x4003ee00, [], 0x4000000}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [32], NULL, 8) = 0
_sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbffff4fc, 32, (nil), 0}) = 0
brk(0) = 0x80b3bb4
brk(0x80b3be4) = 0x80b3be4
brk(0x80b4000) = 0x80b4000
stat64("/dev/tts/0", {st_mode=S_IFCHR|0777, st_rdev=makedev(4, 64), ...}) = 0
brk(0x80c5000) = 0x80c5000
ioctl(-1, 0x5401, 0xbffff680) = -1 EBADF (Bad file descriptor)
nanosleep({0, 5000000}, NULL) = 0
ioctl(-1, 0x5404, {B115200 -opost -isig -icanon -echo ...}) = -1 EBADF (Bad file descriptor)
stat64("/var/lock", {st_mode=S_IFDIR|0775, st_size=1024, ...}) = 0
gettimeofday({1012392205, 695732}, NULL) = 0
getpid() = 23906
open("/var/lock/empeg-JwUC0X", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
getpid() = 23906
write(3, " 23906 empeg\n", 17) = 17
close(3) = 0
link("/var/lock/empeg-JwUC0X", "/var/lock/LCK..tts/0") = -1 ENOENT (No such file or directory)
stat64("/var/lock/empeg-JwUC0X", {st_mode=S_IFREG|0600, st_size=17, ...}) = 0
unlink("/var/lock/empeg-JwUC0X") = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
write(1, "4001 Failed to open device /dev/"..., 474001 Failed to open device /dev/tts/0, errno:2
) = 47
munmap(0x40017000, 4096) = 0
_exit(1) = ?
[root@danski empeg-car]#

Is that what you were asking for?

Is that what you were asking for?

Yes. Aaaaah. Urrrrrgh. It's constructing a lockfile name from the device name, and it's not dealing with the device being in a subdirectory of /dev.

Does anyone know how one is supposed to generate lockfile names from devfs device names?

In the meantime, you should use the backwards-compatibility stuff in devfsd to make it appear as /dev/ttyS<n>.

Peter

It would be interesting to know why it would work as a non-root user, though. It should have the same problem regardless of what the uid is.

It would be interesting to know why it would work as a non-root user, though. It should have the same problem regardless of what the uid is.

The way you're meant to lock serial ports is quite elaborate (it was designed to cope with broken NFS locking implementations). First you create a file in /var/lock named after your program and its PID, then you (supposedly atomically) rename that to the name of the lock file you actually want. If the rename fails, someone's beaten you to it, so you report the failure. (In this case, though, the rename has failed for a different reason.)

A non-root user probably can't create the initial file in /var/lock in the first place; this is not a failure (distros probably shouldn't make /var/lock world-writable), it just means that access to your serial port isn't lockfile-locked properly.

NB. Modern Unixes probably don't require lockfile-locking to protect their serial ports, but, for portability, emptool does it anyway.

Peter

A non-root user probably can't create the initial file in /var/lock in the first place; this is not a failure

Duh. I knew that -- I'm just an idiot, I guess.