Hijack v354: Gpsapp works.

Install Hijack v362: Gpsapp says "Failed to set up serial port" when you start it and never detects the GPS.

Reinstall v354: Gpsapp works again.

Note that in both cases, "Apps use serial port" was properly selected in the Hijack menu.

You'll have to narrow it down better. Was it v361 that affected this?

Also, try starting GPSapp "by hand" from kftpd SITE EXEC, and see if that makes any difference.

Cheers

/me goes to download a couple of intermediate versions <grumble grumble>

You'll have to narrow it down better. Was it v361 that affected this?

Yes.

Install v360: No error message.
Install v361: "Failed to set up serial port" error message.

Haven't tried Site Exec, gonna sign off for the night and maybe mess with it tomorrow.

Mark probably knows exactly what broke, but I'm looking at a diff now.

v363. alpha6. Forced to "DC/Car mode" (I'm in the house). Set to "App's use serial port" (and I still dislike that apostrophe )

Works fine, I'm looking at the output on the screen. 4 satellites despite the GPS receiver being indoors.

I have
[serial]
car_rate=4800
in my config.ini. Nothing else is special.

So, I think you have some other problem?

I have, AND ALWAYS HAVE HAD...

[serial]
car_rate=115200

because otherwise I always got strange pauses and slowdowns during regular MP3 playback as the player toodles along and writes useless stuff like "seek failed" etc. to the serial port.

For some reason, the GPS works fine even if I do that. I think it's because something else throttles it down to 4800 when it needs to talk to the GPS. I never understood it, it was all FM to me.

Would be interesting to see if you get the same failure modes with that setting.

Aha. No, it doesn't work, *when the kernel started it*. The problem before was when I attached with strace it interrupted the system call and it exited, so I reran it from the shell.

GPSapp uses termios to set 4800. I used to have the strange slowdowns, but they stopped. I wonder why.

Modified the app slightly so I can attach with strace after it's running and have the ioctl get restarted.
Now, I see:
open("/dev/ttyS1", O_RDWR|O_NONBLOCK|O_NOCTTY) = 4
ioctl(4, SNDCTL_TMR_TIMEBASE, {B115200 opost isig icanon echo ...}) = 0
ioctl(4, TCSETS, {B4800 -opost -isig -icanon -echo ...}) = -1 EIO (Input/output error)
ioctl(4, TCFLSH, 0x2) = -1 EIO (Input/output error)
close(4) = 0

I have a copy of 363 checked out from CVS and I'm tweaking some stuff. If it works, I'll put it somewhere.

It does.
http://empeg.dementia.org/v363-hacked-for-tfabris.zImage

Mark: the diff is:
--- arch/arm/special/kexec.c 26 Jan 2004 05:03:50 -0000 1.4
+++ arch/arm/special/kexec.c 8 Feb 2004 19:46:28 -0000
@@ -42,7 +42,10 @@
int i;

current->session = 1;
+#if 0
current->pgrp = 1;
+#endif
+
use_init_filesystem_context();

// Block parent process signals

why the process group matters, I'm honestly not sure.

Mmm.. good find.

Now we need to figure out why GPSapp fails with pgrp pointing at "init". Hijack will not be fixed for this -- other commands work just fine with the existing EXEC stuff, so in this case the app needs fixing.

Meanwhile, I'm off to nuke the apostrophe.

Cheers

Well, you tell me why a termios ioctl should ever return EIO... Seriously, I have no idea. Other applications may work, but do any of them do termios ioctls? Do any of them use the serial port? Are you offering me an orange to compare to my apple?

Does it OPEN /dev/ttyS0 first? or just rely on stdin/stdout/stderr ??

serial_sa1100.c doesn't look like it should be returning the EIO either. The rs_ioctl routine can, but we should be calling rs_set_termios directly from tty_ioctl.c.

A thought: the serial code seems to dislike the pgrp of a process not matching that with which a serial port was opened. However, we're getting ttyS1 attached to stdout and stderr when we start.

It opens /dev/ttyS1 (not S0). If it didn't, it wouldn't work when you telnet'd in and ran it, since /dev/pty0 or whatever won't have a gps receiver on it.

In fact in this message the strace output shows the port being open()d and ioctl()d, and that's a direct excerpt.

So what happens when it opens the serial port itself, rather than relying on stdin/stdout ? (which I'm now thinking more and more about binding to /dev/null for all EXEC operations..).

Cheers

What happens is it breaks, since that's already what it's doing, and it's already breaking

Like I said, it's not relying on stdin/stdout.

A thought: the serial code seems to dislike the pgrp of a process not matching that with which a serial port was opened. However, we're getting ttyS1 attached to stdout and stderr when we start.

How about we just remove that check from the serial drivers? Try it and let me know if things work. (and.. patchfile?)

Cheers

Actually, I'm tempted to bind std(in,out,err) to /dev/null with a patch and try that; I almost did that last night.

Or just close them on program startup.

Yuck.

I don't recall every process getting ttyS1 for std(out,err) before 361; Is there a reason that changed?

I tried that last night, FWIW, with no luck; There's something subtle I'm missing. But every other process on the system including player also gets ttyS1 for std(out, err), which seems wrong.

Right, I guess it's not serial_sa1100.c which matters because this is a tty ioctl.

But tty_ioctl itself also doesn't return EIO. That means it should be passing to n_tty_ioctl. n_tty_ioctl passes to set_termios. Neither (directly) can return EIO.

But... set_termios calls tty_check_change, where I see:
if (is_orphaned_pgrp(current->pgrp))
return -EIO;

So is 1 an orphaned pgrp? I'm still looking for the macro.

Not a macro, a function in kernel/exit.c.

Wait, where are you getting "1" from, anyway?

ps -eo "%p %r %G"

shows init's process group is 0. The kernel threads have a process group id of 1. With the patch I posted, gpsapp's pgrp is 8. So is the player's. Perhaps the open serial port attached to std(in,out,err) of the player is thus not coincidental but the crux of the problem, and unbinding /dev/ttyS1 from std(in,out,err) is the answer after all.

I'll try it.

Wait. Player has:
player 86 0 0u CHR 4,65 48 /dev/ttyS1
player 86 0 1u CHR 4,65 48 /dev/ttyS1
player 86 0 2u CHR 4,65 48 /dev/ttyS1

but this is orthogonal to the exec code. (Well, it "matters" because the pgrp is now different and wasn't before)

So fixing the exec code to use /dev/null instead of /dev/console isn't helpful.