Re: Raspberry Pi 2, nfs mount hangs after some time

[Emile `iMil' Heitor]

On Mon, 26 Oct 2015, Robert Elz wrote:


For workarounds, mount using tcp (won't cure the problem, but will
make it far less common), and use interruptible mounts (mount_nfs -T -i)
so when it does hang, you can kill the process(es) at least.


A mee-too reply.

I've setup a NetBSD 7.0/amd64 bulk-build domU as I did for NetBSD 6.1/amd64, it
uses our platform's NetApp NFS servers (thousands of Linux domUs are using
those, the hardware is not guilty).
I'm trying to get rid of those hangs for weeks now, tried every mount flag
combination without success, the system would freeze randomly, leaving the whole
OS unresponsive. There's no log, no kernel message, the domU actually responds
to network solicitations (ping, telnet 22...) but once it's frozen, it is
impossible to run any command, it will just hang.

The exact same setup is successfully running since Sept 2014 on
NetBSD 6.1/amd64.

Any idea how to get some valuable information to help tracking down this
awful behaviour?


Emile `iMil' Heitor * 
  _
| http://imil.net| ASCII ribbon campaign ( )
| http://www.NetBSD.org  |  - against HTML email  X
| http://gcu.info|  & vCards / \

Re: Raspberry Pi 2, nfs mount hangs after some time

[Emile `iMil' Heitor]

On Mon, 2 Nov 2015, Christos Zoulas wrote:


Can you get into ddb?


unfortunately no, the system hangs but does not panic, it just becomes unusable.


Emile `iMil' Heitor * 
  _
| http://imil.net| ASCII ribbon campaign ( )
| http://www.NetBSD.org  |  - against HTML email  X
| http://gcu.info|  & vCards / \

Re: Raspberry Pi 2, nfs mount hangs after some time

[Christos Zoulas]

In article ,
Emile `iMil' Heitor  wrote:
>On Mon, 2 Nov 2015, Christos Zoulas wrote:
>
>> Can you get into ddb?
>
>unfortunately no, the system hangs but does not panic, it just becomes 
>unusable.

If you start running crash on the console and leave it running, is
crash responsive when it hangs. Alternatively since it is pingable
you can implement a ping of death that calls the debugger or
crash-dumps and reboots. It seems strange to me though that the
system would be pingable and you can't get into the debugger.

christos

Re: NetBSD on Dedibox SC Gen2

[Swift Griggs]

On Sun, 1 Nov 2015, Nils Ratusznik wrote:
I can clearly live with it, since the KVM is only used for installations 
and for first tasks. However, I experienced freezes on these two 
machines : there is no answer to a ping or ssh, and I get no display 
from the console (but I suppose this is related to the KVM problem).


I have a very similar problem with NetBSD 7.0 i386 and amd64. I started 
experiencing it with the 7.0_RC releases. I filed a PR (50182) for it. I 
just uploaded some more information for it today. I can reproduce it by 
just hitting my KVM switch until my machine crashes.


This is what I added to the PR today:

I get two different backtraces and a pretty consistent dmesg:

Backtrace #1 (this is what mostly happens):
(gdb) bt
#0  0xc06cdf06 in cpu_reboot ()
#1  0xc0918752 in vpanic ()
#2  0xc09187dc in panic ()
#3  0xc096ad3a in trap ()
#4  0xc010ce78 in alltraps ()
#5  0xdc125f0c in ?? ()
#6  0xc09ee48c in usb_task_thread ()
#7  0xc0100321 in lwp_trampoline ()

Backtrace #2 (this happens occasionally):

0xc06cdf06 in cpu_reboot ()
(gdb) bt
#0  0xc06cdf06 in cpu_reboot ()
#1  0xc0918752 in vpanic ()
#2  0xc09187dc in panic ()
#3  0xc096ad3a in trap ()
#4  0xc010ce78 in alltraps ()
#5  0xdd99fbe0 in ?? ()
#6  0xc0300082 in ehci_allocm ()
#7  0xc09f2123 in usbd_transfer ()
#8  0xc09f248c in usbd_open_pipe_intr ()
#9  0xc09c525c in uhidev_open ()
#10 0xc09e7ec4 in ums_enable ()
#11 0xc0a6965a in wsmuxopen ()
#12 0xc090b40d in cdev_open ()
#13 0xc08f4125 in spec_open ()
#14 0xc0a474e4 in VOP_OPEN ()
#15 0xc0a31d04 in vn_open ()
#16 0xc0a2b23d in do_open ()
#17 0xc0a2b37c in do_sys_openat ()
#18 0xc0a2b442 in sys_open ()
#19 0xc093ccff in syscall ()
#20 0xc010055d in Xsyscall ()
#21 0xdd99ffa8 in ?? ()

Here is the dmesg:

uvm_fault(0xc0ff0d00, 0x62756000, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c09f2e0f cs 8 eflags 210246 cr2 62756877 ilevel 0 
esp c4bf0324

curlwp 0xc4b73d20 pid 0 lid 38 lowest kstack 0xdc1242c0
panic: trap
cpu0: Begin traceback...
vpanic(c0dc7a1b,dc125e84,dc125f00,c096ad3a,c0dc7a1b,dc125f0c,dc125f0c,26,dc1242c0,210246) 
at netbsd:vpanic+0x121
snprintf(c0dc7a1b,dc125f0c,dc125f0c,26,dc1242c0,210246,62756877,0,c4bf0324,c0fa6d20) 
at netbsd:snprintf

trap_tss() at netbsd:trap_tss
--- trap via task gate ---
c4bf0324:
cpu0: End traceback...

Re: NetBSD on Dedibox SC Gen2

[Christos Zoulas]

In article ,
Swift Griggs   wrote:
>On Sun, 1 Nov 2015, Nils Ratusznik wrote:
>> I can clearly live with it, since the KVM is only used for installations 
>> and for first tasks. However, I experienced freezes on these two 
>> machines : there is no answer to a ping or ssh, and I get no display 
>> from the console (but I suppose this is related to the KVM problem).
>
>I have a very similar problem with NetBSD 7.0 i386 and amd64. I started 
>experiencing it with the 7.0_RC releases. I filed a PR (50182) for it. I 
>just uploaded some more information for it today. I can reproduce it by 
>just hitting my KVM switch until my machine crashes.
>
>This is what I added to the PR today:
>
>I get two different backtraces and a pretty consistent dmesg:

Do you have a netbsd.gdb for this kernel?
I would uncomment:

#makeoptionsDEBUG="-g"  # compile full symbol table

and use netbsd.gdb for this backtrace...

christos

Poor man's solution to /etc when upgrading system?

[Ottavio Caruso]

Hello,

following up from the multiple recent thread regarding best way to
upgrade the system and etcmanage, I wonder if a quicker and better
solution could be the following:

1) Insert installation cd/usb and boot
2) mount the installed system and mv /etc to /etc.old
3) Upgrade all sets, including etc
4) Copy/restore individual files from /etc.old if/when needed

Alternatively, I remember (but memory may fail) that old Slackware
versions came with a script to rename all copies of /etc files with a
.new suffix.

Maybe one could write a script to detect if a file exists, and if so,
install a new file with a .new extension.

I am not sure if etcmanage already does that.

Thanks

-- 
Ottavio

Re: Console Resolution

[Michael van Elst]

On Sun, Nov 01, 2015 at 09:26:19PM -0500, Bob Bernstein wrote:
> On Sun, 1 Nov 2015, Michael van Elst wrote:
> 
> >The other path was already mentioned, you can configure the bootloader in
> >/boot.cfg to disable the framebuffer console.
> 
> Thanks. May I infer that this problem of an unreadably small console font is
> not an issue for those who use display managers to boot directly into X? It
> seems, almost "by definition," that that would be the case (but it pays to
> check as they say.)

I guess for most people it isn't an issue. And here it was probably
a decision wether to enable the DRM code for NetBSD-7 or wait even
longer until the console got smarter.

Don't think that the unreadably small console font on high resolution
displays isn't considered a problem. On a Retina display or 4K monitor
it can be an issue also for people with good eyesight.


> Which reminds me, Michael: why did you warn against the possible loss of X
> if that approach -- removing the drm code -- was used with NetBSD 7.0?

If you disable the drm code, then you might only be able to use X in vesa
mode, which might not support your display. I'm not sure if you can disable
only the framebuffer console and still use drm for X.



Greetings,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: Poor man's solution to /etc when upgrading system?

[Greg Troxel]

Ottavio Caruso  writes:

> following up from the multiple recent thread regarding best way to
> upgrade the system and etcmanage, I wonder if a quicker and better
> solution could be the following:
>
> 1) Insert installation cd/usb and boot
> 2) mount the installed system and mv /etc to /etc.old
> 3) Upgrade all sets, including etc
> 4) Copy/restore individual files from /etc.old if/when needed
>
> Alternatively, I remember (but memory may fail) that old Slackware
> versions came with a script to rename all copies of /etc files with a
> .new suffix.
>
> Maybe one could write a script to detect if a file exists, and if so,
> install a new file with a .new extension.
>
> I am not sure if etcmanage already does that.

etcmanage essentially does this.  it  unpacks the new etc (and xetc) in
/usr/netbsd-etc, and then it syncs all the files into /etc in the case
when the old file is registered as automatically managed and not changed
From upstream.  Once you are set up you just run "INSTALL-NetBSD
install" from a releasedir and it all happens automatically, usually
entirely correctly.

So rather than reinvent the wheel I would suggest that you read the
etcmanage README (in the source and in the binary pacakge).  It would be
great if someone turned the README into a man page.


signature.asc
Description: PGP signature

systemd stance

[Mitt Green]

Hello everyone,

You've probably heard of all these systemd rants, which are
especially rough in Debian community.

There is a Debian fork, named Devuan (devuan.org) which is
currently in alpha stage, but is fairly usable (I have it on my desktop for 
daily usage), that promotes init freedom and
ships with sysvinit by default‎.

We are having a thread discussing Unix distributions
that have made their decision not to go with systemd
(all threads available at lists.dyne.org). Since systemd
is made for Linux-only (and glibc also I believe), do
you have any opinions on it, regarding NetBSD future
and at all?

As far as I understand NetBSD is made
to follow Unix philosophy of keeping things simple and
minimal, which probably excludes software like systemd.

Thanks,

                    Mitt

Re: systemd stance

[Tobias Nygren]

On Mon, 02 Nov 2015 22:40:34 +0300
Mitt Green  wrote:

> Hello everyone,
> 
> You've probably heard of all these systemd rants, which are
> especially rough in Debian community.
> 
> There is a Debian fork, named Devuan (devuan.org) which is
> currently in alpha stage, but is fairly usable (I have it on my desktop for 
> daily usage), that promotes init freedom and
> ships with sysvinit by default?.
> 
> We are having a thread discussing Unix distributions
> that have made their decision not to go with systemd
> (all threads available at lists.dyne.org). Since systemd
> is made for Linux-only (and glibc also I believe), do
> you have any opinions on it, regarding NetBSD future
> and at all?
> 
> As far as I understand NetBSD is made
> to follow Unix philosophy of keeping things simple and
> minimal, which probably excludes software like systemd.

Hello,

Not a stance, just my personal thoughts on the subject:
The BSDs tend to prefer properly engineered solutions, not necessarily
minimalistic ones.

No doubt somebody will at some point write a BSD licensed init(8)
replacement with some degree of builtin hardware peripheral and service
management that could theoretically be included in base. There's
however not much to debate until such suitable BSD licensed init
replacement exists.

I imagine it would be engineered so that it can coexist in the file
system alongside init+rc.d and the kernel would grow a boot option to
toggle which init system to execute.

IMHO from a desktop/mobile usability perspective there are many other
higher value projects that should prioritized before writing a hugely
complex init system just to unify device hotplug and get 5 seconds
faster bootup. (But we might get there some day!)

Kind regards,
-Tobias

Re: Poor man's solution to /etc when upgrading system?

[Mayuresh]

On Mon, Nov 02, 2015 at 06:40:29PM +, Ottavio Caruso wrote:
> following up from the multiple recent thread regarding best way to
> upgrade the system and etcmanage, I wonder if a quicker and better
> solution could be the following:
> 
> 1) Insert installation cd/usb and boot
> 2) mount the installed system and mv /etc to /etc.old
> 3) Upgrade all sets, including etc
> 4) Copy/restore individual files from /etc.old if/when needed
> 
> Alternatively, I remember (but memory may fail) that old Slackware
> versions came with a script to rename all copies of /etc files with a
> .new suffix.
> 
> Maybe one could write a script to detect if a file exists, and if so,
> install a new file with a .new extension.
> 
> I am not sure if etcmanage already does that.

I skip etc set when upgrading and later on update using "etcupdate".
Worked for me so far.

(What is etcmanage? Different from etcupdate?)

Mayuresh