Re: [bmake] bmake sigint handling causing tty corruption

[Simon J. Gerraty]

Hi Dmitry

Thanks for the detailed report.

Will take a look

> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215572

> Now to fix this, I suggest that instead of killing itself, make should
> signal all its childs carefully and wait() on them, only then die
> itself.
> 
> Now after a quick glance at bmake sources it seems like the jobs control
> code
> 
> https://svnweb.freebsd.org/base/head/contrib/bmake/job.c?revision=317239=markup#l2633
> 
> does the very same thing that I've just described, however bmake is run
> in compat mode by default, and CompatInterrupt does exactly what ktrace
> shows - it just kills itself.
> 
> https://svnweb.freebsd.org/base/head/contrib/bmake/compat.c?revision=310304=markup#l180
> 
> So, to fix this problem it seems that CompatInterrupt should be improved
> as described above.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [base pkg] update !GENERIC kernel

[Ben Woods]

On Wed, 19 Jul 2017 at 7:37 pm, Boris Samorodov  wrote:

> Hi All,
>
> I use self-made base packages for an ARM board. The kernel I use
> is IMX6 one. While pkg update I get this:
> ---
> [271/302] Upgrading FreeBSD-kernel-imx6-debug from 12.0.s20170718113533
> to 12.0.s20170719070514...
> [271/302] Extracting FreeBSD-kernel-imx6-debug-12.0.s20170719070514:
> 100%
> kldxref: //boot/kernel: No such file or directory
> pkg: POST-INSTALL script failed
> [272/302] Upgrading FreeBSD-kernel-imx6 from 12.0.s20170718113533 to
> 12.0.s20170719070514...
> [272/302] Extracting FreeBSD-kernel-imx6-12.0.s20170719070514: 100%
>
> kldxref: //boot/kernel: No such file or directory
> pkg: POST-INSTALL script failed
> ---
>
> All is fine except those messages.
>
> There is no /boot/kernel, but there is /boot/kernel.IMX6. The kernel
> is defined at /boot/loader.conf:
> ---
> kernel="kernel.IMX6"
> ---
>
> Seems that for now pkg can't handle non-default kernel. Should I just
> ignore those messages? Or should I run some post-update commands/scripts
> by hand?


I had the same problem on my machine using pkg-base with a non-default
named kernel package.

As a workaround, I created a symlink at /boot/kernel pointing to the
correct kernel directory. This seemed to fix the problem, but required this
manual intervention.

It would be good if this wasn't required, and the kernel package used the
kernel parameter in loader.conf to determine where to run the post-install
script.

Regards,
Ben
-- 

--
From: Benjamin Woods
woods...@gmail.com
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [bmake] bmake sigint handling causing tty corruption

[Poul-Henning Kamp]

In message <20170718205700.GA2131@hades.panopticon>, Dmitry Marakasov writes:


>In short, when FreeBSD ports options dialog is interrupted by Ctrl+C,
>there's chance of sporadic terminal corruption. They are not always
>reproducible and seem to be dependent on a machine, shell, terminal,
>tmux used, but are not tied to any specific configuration.

I've noticed another quirk which may be related:

Start vi(1) on some file.

Type
!some_command_producing_significant_output | less

Ctrl-C

This leaves the less(1) alive and competing vi(1) for the terminal
in a most unworkable and annoying fashion.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Inter-VLAN routing on CURRENT: any known issues?

[Sergey Zhmylove]

Do you receive packets from 192.168.2.0/24 and 192.168.3.0/24 on igb1.2 
and igb1.3 respectively?
Do you really need NAT? As far as I can see, you're looking for basic 
static inter-VLAN routing.
Could you check the communication between 2.0/24 and 3.0/24 with 
unloaded ipfw module (just to exclude ipfw from the investigation)?


I have a lot of installations of such scheme on em(4) and re(4) devices 
-- no problems at all. Even maybe there was igb(4) devices too.


Sergey  Zhmylove
17.07.2017 0:31, O. Hartmann пишет:

Am Sun, 16 Jul 2017 23:14:41 +0200
Frank Steinborn  schrieb:


O. Hartmann  wrote:

I have not have any success on this and I must ask now, to not make a fool out 
of my
self, whether the concept of having several vlan over one single NIC is 
possible with
FreeBSD (12-CURRENT, as of today, r321055.

Since it is even not possible to "route" from a non-tagged igb1 to a tagged vlan
igb1.2 or igb1.66 (for instance) on the same NIC, I have a faint suspect that 
I'm
doing something terribly wrong.

I think everyone working with vlan should have those problems, but since I can 
not
find anything on the list, I must do something wrong - my simple conclusion.

What is it?

Do you have enabled net.inet.ip.forwarding?


Of course I have. As I stated earlier, ICMP pings from on VLAN to another over 
this
router works, but any IP (UDP, TCP) is vanishing into thin air.

I don't have a FBSD-11-STABLE reference system at hand, so that I can check 
with another
revision/major release of the OS, but I work on that.



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[bmake] bmake sigint handling causing tty corruption

[Dmitry Marakasov]

Hi!

Me and Ilya Arkhipov were investigating the cause of this bug:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215572

In short, when FreeBSD ports options dialog is interrupted by Ctrl+C,
there's chance of sporadic terminal corruption. They are not always
reproducible and seem to be dependent on a machine, shell, terminal,
tmux used, but are not tied to any specific configuration.

The investigation led us to the following conclusion:

- the corruption is caused by dialog4ports program (which handles ports
  options dialogs) not being able to restore terminal state on exit
- dialog4ports does indeed try to restore terminal state, but the
  corresponding ioctl (TIOCSETAW) fails with EIO
- examining kern/tty.c suggests that this happens likely because the make
  which is the session leader or something dies before dialog4ports
- which led us to bmake as a culprit

Here's the ktrace of the problem (the process hierarchy here is make ->
sh -> dialog4ports)

---
78337 dialog4ports CALL  sigaction(SIGTSTP,0x800a80228,0)
78337 dialog4ports RET   sigaction 0
78337 dialog4ports CALL  clock_gettime(0xd,0x7fffde08)
78337 dialog4ports RET   clock_gettime 0
78337 dialog4ports CALL  gettimeofday(0x7fffdc90,0)
78337 dialog4ports RET   gettimeofday 0
78337 dialog4ports CALL  poll(0x7fffdca0,0x2,0x)

(make and sh receive SIGINT first)

78265 make RET   wait4 RESTART
78335 sh   RET   wait4 -1 errno 4 Interrupted system call
78265 make PSIG  SIGINT caught handler=0x402530 mask=0x0 code=SI_KERNEL
78335 sh   PSIG  SIGINT caught handler=0x41b950 mask=0x0 code=SI_KERNEL
78265 make CALL  lstat(0x800ab9900,0x7fffd1f0)
78265 make NAMI  "do-config"
78335 sh   CALL  sigreturn(0x7fffd280)
78335 sh   RET   sigreturn JUSTRETURN
78265 make RET   lstat -1 errno 2 No such file or directory
78335 sh   CALL  wait4(0x,0x7fffd6ec,0,0)
78265 make CALL  sigaction(SIGINT,0x7fffd250,0x7fffd230)
78265 make RET   sigaction 0
78265 make CALL  kill(0x131b9,SIGINT)
78265 make RET   kill 0
78265 make CALL  sigreturn(0x7fffd2d0)
78265 make RET   sigreturn JUSTRETURN

(make kills itself)

78265 make PSIG  SIGINT SIG_DFL code=SI_USER

(dialog4ports finally starts to process the signal)

78337 dialog4ports RET   poll -1 errno 4 Interrupted system call
78337 dialog4ports PSIG  SIGINT caught handler=0x800855e00 mask=0x0 
code=SI_KERNEL
78337 dialog4ports CALL  sigaction(SIGINT,0x7fffd7c0,0)
78337 dialog4ports RET   sigaction 0
78337 dialog4ports CALL  ioctl(0x1,TIOCGETA,0x7fffd770)
78337 dialog4ports RET   ioctl 0
78337 dialog4ports CALL  write(0x1,0x801676a00,0x17)
78337 dialog4ports GIO   fd 1 wrote 23 bytes
78337 dialog4ports RET   write 23/0x17

(this call should restore terminal state, but it fails)

78337 dialog4ports CALL  ioctl(0x1,TIOCSETAW,0x80161604c)
78337 dialog4ports RET   ioctl -1 errno 5 Input/output error
78337 dialog4ports CALL  exit(0x1)
---

Here's the ktrace of the case which didn't cause terminal corruption:

---
79506 dialog4ports CALL  poll(0x7fffdc00,0x2,0x)
79506 dialog4ports RET   poll -1 errno 4 Interrupted system call

(dialog4ports is lucky enough to start processing the signal before make)

79506 dialog4ports PSIG  SIGINT caught handler=0x800855e00 mask=0x0 
code=SI_KERNEL
79506 dialog4ports CALL  sigaction(SIGINT,0x7fffd720,0)
79506 dialog4ports RET   sigaction 0
79506 dialog4ports CALL  ioctl(0x1,TIOCGETA,0x7fffd6d0)
79506 dialog4ports RET   ioctl 0
79506 dialog4ports CALL  write(0x1,0x801676a00,0x17)
79506 dialog4ports GIO   fd 1 wrote 23 bytes
79506 dialog4ports RET   write 23/0x17

(and cleanup succeeds)

79506 dialog4ports CALL  ioctl(0x1,TIOCSETAW,0x80161604c)
79506 dialog4ports RET   ioctl 0
79506 dialog4ports CALL  exit(0x1)
79433 make RET   wait4 RESTART
79433 make PSIG  SIGINT caught handler=0x402530 mask=0x0 code=SI_KERNEL
79433 make CALL  lstat(0x800ab4980,0x7fffd140)
79433 make NAMI  "do-config"
79433 make RET   lstat -1 errno 2 No such file or directory
79433 make CALL  sigaction(SIGINT,0x7fffd1a0,0x7fffd180)
79433 make RET   sigaction 0
79433 make CALL  kill(0x13649,SIGINT)
79433 make RET   kill 0
79433 make CALL  sigreturn(0x7fffd220)
79433 make RET   sigreturn JUSTRETURN
79433 make PSIG  SIGINT SIG_DFL code=SI_USER
79504 sh   RET   wait4 -1 errno 4 Interrupted system call
79504 sh   PSIG  SIGINT caught handler=0x41b950 mask=0x0 code=SI_KERNEL
79504 sh   CALL  sigreturn(0x7fffd1d0)
79504 sh   RET   sigreturn JUSTRETURN
---

For reference, here's the program which demonstrates the tty layer
behaviour which causes this:

---
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main() {
struct termios t;
int ret;

// save terminal state
ret = ioctl(1, TIOCGETA, );
fprintf(stderr, "ioctl(1, TIOCGETA) -> %d / 

[base pkg] update !GENERIC kernel

[Boris Samorodov]

Hi All,

I use self-made base packages for an ARM board. The kernel I use
is IMX6 one. While pkg update I get this:
---
[271/302] Upgrading FreeBSD-kernel-imx6-debug from 12.0.s20170718113533 
to 12.0.s20170719070514...
[271/302] Extracting FreeBSD-kernel-imx6-debug-12.0.s20170719070514: 
100%

kldxref: //boot/kernel: No such file or directory
pkg: POST-INSTALL script failed
[272/302] Upgrading FreeBSD-kernel-imx6 from 12.0.s20170718113533 to 
12.0.s20170719070514...
[272/302] Extracting FreeBSD-kernel-imx6-12.0.s20170719070514: 100% 


kldxref: //boot/kernel: No such file or directory
pkg: POST-INSTALL script failed
---

All is fine except those messages.

There is no /boot/kernel, but there is /boot/kernel.IMX6. The kernel
is defined at /boot/loader.conf:
---
kernel="kernel.IMX6"
---

Seems that for now pkg can't handle non-default kernel. Should I just
ignore those messages? Or should I run some post-update commands/scripts
by hand?

BTW, I did not find any evidence of POST-INSTALL scripts at the .txz
file. Are they hard-coded at pkg?

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"