|
[20061115]
|
EuroBSDCon 2006 presentation: The redesign of pkg_install for pkgsrc
Jörg Sonnenberger has worked on redesigning and rewriting
pkg_install, the framework that pkgsrc is built upon, during the
Google Summer-of-Code's "pkg_install" project
and he also gave a talk at EuroBSDCon 2006 on the topic.
He has made
his slides
and
his paper
available now, for everyone interested.
[Tags: eurobsdcon, google-soc, pkg_install, pkgsrc]
|
|
[20061115]
|
Search-engine for pkgsrc in Firefox 2
The NetBSD.se team has a nice frontend to pkgsrc, and
Viktor Homlund from the NetBSD.se team wrote me that there's
a search-engine plugin for pkgsrc.se in Firefox 2
now available.
Available are searches in comments, for maintainers and
a general package search.
For those not sure what this is about: you probably know the
Google search box in Firefox. This can replaced with other
search engines in FF2, and there's your favourite cool aid
now. See
the upper right corner of this screenshot
for how it looks, and what it returns.
[Tags: firefox, images, pkgsrc]
|
|
[20061115]
|
Post mortem debugging, or: what happened before it crashed? (Updated)
So your machine paniced, and as you were running X you have no
clue what went on? Here's a nice way to find out, assuming you have
a kernel crash dump. To ensure the latter, set
kern.dump_on_panic=1 in /etc/sysctl.conf.
Now, what to do with those crashdumps?
% ls -l /var/crash/
total 3183838
-rw-r--r-- 1 root wheel 3 Nov 2 02:09 bounds
-rw-r--r-- 1 root wheel 5 Jun 30 2004 minfree
...
-rw------- 1 root wheel 181265401 Nov 2 02:11 netbsd.26.core.gz
-rw------- 1 root wheel 2162696 Nov 2 02:11 netbsd.26.gz
In /var/crash, "bounds" contains an increasing counter for the
crashdump number (it would be "27" in the above example),
and "minfree" contains the minimum amount of free space
in kilobytes that should keep free - both files are read by
savecore(8) when /etc/rc.conf has "savecore=yes", which is
the default.
The actual crashdump consists of two gzipped files - the
actual memory dump "netbsd.XX.core.gz" and a copy of the
running kernel "netbsd.xx.gz". After uncompressing the
files can be used for looking at the system at the point
of it's panic:
# gunzip netbsd.26*.gz
#
Note that the crashdump may contain sensitive data and is such
only readable by root!
The crashdump can be read by programs that use libkvm to
read through the crashdump's kernel memory, e.g.
gdb(1), dmesg(8), ps(1), fstat(8), ipcs(1), netstat(8), nfsstat(8),
pmap(1), w(1), pstat(8), vmstat(8) etc.,
using the -M and -N switches.
Some examples:
- To show the system's message buffer at the time
of the crash:
% dmesg -M netbsd.26.core -N netbsd.26
...
unmounting /home (/dev/wd1e)...
unmounting /tmp (mfs:371)...warning: mfs read during shutdown
dev = 0xff00, block = 10496, fs = /tmp
panic: blkfree: freeing free block
Begin traceback...
uvm_fault(0xcbfd07f0, 0x2000, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c0305083 cs 8 eflags 10246 cr2 2900 ilevel 0
panic: trap
Faulted in mid-traceback; aborting...
dumping to dev 0,1 offset 2024327
dump 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496
495 494 493 ...
Apparently the system tried to free a block that was
already fred here when umounting /tmp.
- Display virtual memory parameters:
% vmstat -M netbsd.26.core -N netbsd.26 -s
4096 bytes per page
8 page colors
127888 pages managed
...
- Attach the GNU debugger gdb(1) to the system crash dumpQ,
to poke around deeply:
% gdb netbsd.26
...
(gdb) target kcore netbsd.26.core
panic: blkfree: freeing free block
#0 0x0ac04000 in ?? ()
(gdb) bt
#0 0x0ac04000 in ?? ()
#1 0xc03084b5 in cpu_reboot ()
#2 0xc02a57aa in panic ()
#3 0xc0313127 in trap ()
#4 0xc0102dfd in calltrap ()
#5 0xc0182544 in db_get_value ()
#6 0xc03058f1 in db_stack_trace_print ()
#7 0xc02a577c in panic ()
#8 0xc0205db7 in ffs_blkfree ()
#9 0xc020b8d5 in ffs_indirtrunc ()
...
- Unfortunately there are a number of programs that I
didn't get to work with my crashdump, but that may be
due to its point after/during system shutdown, e.g.
ps(1) didn't work.
Still that should give some start for poking around...
Update: Apparently 'target kcore' was renamed
to 'target kvm' in gdb6, see
this posting.
[Tags: debugging, dmesg, gdb]
|
|
[20061115]
|
Ready for testing: Hardware accelerated IPsec with IPv6 (and IPv4)
As reported previously, Degroote Arnaud has worked on adding IPv6 support
for the
fast_ipsec(4)
IPsec implementation in NetBSD
as part of the ipsec6 Google SoC project,
see
his previous status report.
Before the project, the situation in NetBSD was that there
were two IPsec implementations: the KAME implementation which
worked for both IPv4 and IPv6 but didn't support crypto hardware,
and the fast_ipsec(4) implementation from FreeBSD that
did support crypto hardware but only IPv4, no IPv6.
With the success of the ipsec6 Google SoC project, the code
for hardware-accelerated IPsec with IPv6 (and IPv4) is now
ripe for testing, and the author has sent a second mail
asking for code review and testing:
``It would be nice too if some people can test the code in more real cases and
report success and failure.''
The pointer to the latest patch is
in his second mail.
Happy testing!
[Tags: google-soc, ipsec, ipv6]
|
|
