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.

Mmm.. I could use pgrp==0 if that works here.. ?

I don't know if 0 will work, it might need to match player's pgrp if player has ttyS1 for std*

i'll try when I get home

Okeydoeky. Also, I just noticed that stdin == /dev/null already for EXECs.

Cheers

Hate to interrupt a good hacking discussion, but I hadn't received a "yay" or "nay" as to whether this patch is okay for inclusion in Hijack. It allows user apps to (a) get a copy of the player's screenbuf and (b) get the UI flags status. I will be making extensive use of these for my next release, and I think they're good things to have available. Any thoughts?

In fact, pgrp = 0, still "failed to set up serial port".

Fine, you win. Here's a patch to disable the pgrp check. Tested: it works.

Rather than breaking telnetd and friends, how about the attached patch?

patch war?

Sure. It looks like a different ugly patch

Let me ask this: why does the player get ttyS1 as std(in,out,err) when I've selected "apps" and not "player" for the serial port? Because fundamentally I think fixing that is the answer, but I'm fuzzy on *why* it's happening, because I think I haven't found the right place to look yet.

Man, I go away from the BBS for a day and come back, and my tiny little bug report has sparked this whole complicated thing.

Cool.

The player, when started up (by init, presumably), is given /dev/console for stdin/stdout/stderr. It later then opens /dev/ttyS1 for serial port control notify and control features.

When "apps use serial port" is selected, Hijack intercepts the startup of the player, and appends an option flag that tells the player to not open /dev/ttyS1 for serial port control and notify. Regardless, it still already has /dev/console.

On the Empeg, /dev/console is mapped to the serial port. Which confused the heck out of me the first time I looked there when writing the original Hijack code that intercepts the notify info and makes it available under /proc/empeg_notify --> the serial output from the player arrives in two distinct streams, from two logical devices, all heading to the same serial port.

Cheers

I feel silly now. /dev/console mapping to ttyS1 was something I thought of, and then forgot. Doh.

Hijack v364 has this fix in it (untested by me).

Cheers

I tried Hijack 365 and still get "Failed to set up serial port".

Did we also need a new GPSapp, or just the change in Hijack?

If we need a new GPSapp, would this one suffice, or do we need those changes as well as additional ones?

I didn't test it yet either. I see Tony says not. I'll see later what the deal is.

Naw, my bug.

I'll fix it shortly.

Cheers

You already know what's wrong then?

I'm in an interview now so I can't look.

Okay, try this one.

Cheers

Okay, try this one.

Since there was no attachment, I assume you mean v366 at the web site. Grabbed it, tried it.

Good= I don't get the "failed to set up serial port" error.

Bad= GPS doesn't work.

If it's in the home sled (no GPS attached) and I use force-DC mode to make GPSapp available, the GPSapp program locks up with a black screen when I invoke it.

If it's in the car sled (GPS actually attached), it sits there at "Waiting for data from GPS receiver" but never gets past it.

I will concede that it's possible my GPS unit failed sometime between yesterday (last time I used GPSapp) and today, but I'm betting it's not a likely enough possibility that warrants me putting an older hijack back into place and doing another run out to the car again.

This would be a different gpsapp issue, then. Also, don't use v3alpha for this -- something about serial has changed in v3 as well.

-ml

I've been using 2.0 final for this, but thanks for checking.

/me goes back to Hijack v354 so he can continue to use GPSapp...

I was using v3 alpha6, and a real gps receiver, and that gpsapp binary that I posted, and the first patch (the one that doesn't change pgrp) and telnetd worked, and gpsapp saw satellites, and I got music.

What problem should I have had?

Geez, that reads really snide, and I didn't mean it that way.

But seriously, is there some problem I should be looking for/at?

I dunno. Tony??

The patch in Hijack is somewhat different than that I posted here, but should be even less restrictive. Tony said no issues with serial port messages, at least, but beyond that.. dunno.

But seriously, is there some problem I should be looking for/at?

My problem is that when I run any version of Hijack later than the one I posted above (what was it, 360?), I can't use GPSapp because gpsapp either says "failed to set up serial port" or it locks up completely.

Yeah, but I said "with the patch I posted", and that was alpha 6, post 360, modern gpsapp. I was asking Mark what problem he saw.

I'll look at diffs, I guess.

I don't see any problem. The patch I actually applied should achieve the same behaviour, but without impacting the behaviour of background processes that are not using /dev/ttyS1.

Cheers

Yeah, but I said "with the patch I posted",

Oh, sorry.

Well, um, yeah, the amended version of the patch looks ok. I guess I'll dig the GPS out again and try.

Looks like read() on the serial port now returns EIO.

Hm. So, I commented out the pgrp line again and reverted the change to tty_check_change back to what it was in 363, and I still lose. I very definitely won in 363 with just the pgrp change. I guess I should diff 363 to 367.

Hm.
in read_chan I see
else if (current->pgrp != tty->pgrp) {
if (is_ignored(SIGTTIN) ||
is_orphaned_pgrp(current->pgrp))
return -EIO;
kill_pg(current->pgrp, SIGTTIN, 1);
return -ERESTARTSYS;
}
I wonder if SIGTTIN is ignored. This check of course bypasses the thing you patched.

Make read_chan be symmetric with tty_check_change.

--- drivers/char/n_tty.c 11 Oct 2003 22:14:12 -0000 1.2
+++ drivers/char/n_tty.c 10 Feb 2004 06:33:05 -0000
@@ -956,7 +956,8 @@
current->tty == tty) {
if (tty->pgrp <= 0)
printk("read_chan: tty->pgrp <= 0!\n");
- else if (current->pgrp != tty->pgrp) {
+ else if ((current->pgrp != tty->pgrp) &&
+ (tty->device != MKDEV(TTY_MAJOR,65))) {
if (is_ignored(SIGTTIN) ||
is_orphaned_pgrp(current->pgrp))
return -EIO;

Okay. v368 will have this change in a few minutes.

Thanks Mark,

The Charcoalgray99 Empeg web (Now Playing Info) was also broken after my upgrade to Alpha6 and HiJack V363. But it works now again...

bye

Okay. v368 will have this change in a few minutes.

Tested! It works! Mark and Derrick, thanks very much for your time and your attention to detail. Too cool.

The Charcoalgray99 Empeg web (Now Playing Info) was also broken after my upgrade to Alpha6

Yes, I posted a note about this in the Merry Christmas thread (which is really the v3alpha thread).

Basically, v3alpha6 has the two serial streams (console messages vs. output->notify messages) reversed from normal somewhere. I haven't the foggiest how/why, but I did recently just update Hijack to reverse it's processing of them internally to compensate, whenever running a v3alpha release. Very peculiar.

Cheers

I didn't really follow all the technicalities of this thread, but should telnetd be broken as of Hijack v372 ?
The connection is killed immediately.

Probably not. I'm telnetted in now, seems to not be dying

Crap. That means I screwed something up when upgrading to v3a7. I wonder what though - the connection is made so the server is running...

You zapped all the ttys. Run the devs script again.

Doh! Thanks. I'd completely forgotten about that little detail.