freebsd-hackers Digest, Vol 364, Issue 3
freebsd-hac...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
or, via email, send a message with subject or body 'help' to
freebsd-hac...@freebsd.org
You can reach the person managing the list at
freebsd-ha...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-hackers digest..."
Today's Topics:
1. Kernel dump crash (Glenn Camilleri)
2. Re: Kernel dump crash (John Baldwin)
3. Re: Drop cache (Pieter de Goeje)
4. Re: [RFC] DTrace SYSCALL provider (was Re: [RFC] Saving the
latest errno from syscalls.) (Jung-uk Kim)
5. Re: How to slow down SATA to 1.5 GBit/s ? (Juergen Lock)
6. Re: How to slow down SATA to 1.5 GBit/s ? (Thomas Schmitt)
7. ATA 4K sector issues (Mohacsi Janos)
8. Re: ATA 4K sector issues (Andriy Gapon)
9. Re: ATA 4K sector issues (Kent Stewart)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Mar 2010 13:13:39 +0100
From: Glenn Camilleri <glen...@gmail.com>
Subject: Kernel dump crash
To: freebsd...@freebsd.org
Message-ID:
<c0e6d201003160513p50f...@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Hi,
I have some processes and programs that are custom made to run on FreeBSD. I
suspect some poor implementation of tcp in these programs, but don’t have
the real proof.
This is the info I got from the crash dump:
root@scat /usr/obj/usr/src/sys/SMP # uname -a
FreeBSD scat.setcom 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30
UTC 2007 ro...@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386
root@scat /usr/obj/usr/src/sys/SMP # kgdb kernel.debug /home/dump/vmcore.0
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x8
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc06e0d3c
stack pointer = 0x28:0xe3832910
frame pointer = 0x28:0xe3832a2c
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 12 (swi1: net)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 6h41m17s
Dumping 1014 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1014MB (259552 pages) 998 982 966 950 934 918 902 886 870 854 838
822 806 790 774 758 742 726 710 694 678 662 646 630 614 598 582 566 550 534
518 502 486 470 454 438 422 406 390 374 358 342 326 310 294 278 262 246 230
214 198 182 166 150 134 118 102 86 70 54 38 22 6
#0 doadump () at pcpu.h:165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc067550a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc0675831 in panic (fmt=0xc08e46e1 "%s") at
/usr/src/sys/kern/kern_shutdown.c:565
#3 0xc088e29c in trap_fatal (frame=0xe38328d0, eva=8) at
/usr/src/sys/i386/i386/trap.c:837
#4 0xc088dfdb in trap_pfault (frame=0xe38328d0, usermode=0, eva=8) at
/usr/src/sys/i386/i386/trap.c:745
#5 0xc088dc15 in trap (frame=
{tf_fs = -969277432, tf_es = -1066532824, tf_ds = -969277400, tf_edi =
0, tf_esi = -975366656, tf_ebp = -477943252, tf_isp = -477943556, tf_ebx =
4, tf_edx = -975366656, tf_ecx = -975366572, tf_eax = 0, tf_trapno = 12,
tf_err = 0, tf_eip = -1066529476, tf_cs = 32, tf_eflags = 66178, tf_esp = 0,
tf_ss = 4})
at /usr/src/sys/i386/i386/trap.c:435
#6 0xc0879d4a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc06e0d3c in bpf_mtap2 (bp=0x0, data=0x0, dlen=4, m=0xc5dd1600) at
/usr/src/sys/net/bpf.c:1374
#8 0xc06e95bb in if_simloop (ifp=0xc51b3800, m=0xc5dd1600, af=2, hlen=0) at
/usr/src/sys/net/if_loop.c:284
#9 0xc06e954c in looutput (ifp=0xc51b3800, m=0xc5dd1600, dst=0xe3832aac,
rt=0xc5440c60) at /usr/src/sys/net/if_loop.c:234
#10 0xc0717a34 in ip_output (m=0xc5dd1600, opt=0xc51b3800, ro=0xe3832aa8,
flags=0, imo=0x0, inp=0xc61e85a0) at /usr/src/sys/netinet/ip_output.c:777
#11 0xc0720c0e in tcp_output (tp=0xc63871d0) at
/usr/src/sys/netinet/tcp_output.c:1080
#12 0xc071eeed in tcp_input (m=0xc63ae100, off0=20) at
/usr/src/sys/netinet/tcp_input.c:2471
#13 0xc0715a89 in ip_input (m=0xc63ae100) at
/usr/src/sys/netinet/ip_input.c:785
#14 0xc06ef243 in netisr_processqueue (ni=0xc09e6878) at
/usr/src/sys/net/netisr.c:236
#15 0xc06ef442 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349
#16 0xc065fe99 in ithread_execute_handlers (p=0xc4ed0860, ie=0xc4f25600) at
/usr/src/sys/kern/kern_intr.c:682
#17 0xc065ffa9 in ithread_loop (arg=0xc4f11140) at
/usr/src/sys/kern/kern_intr.c:765
#18 0xc065ec4d in fork_exit (callout=0xc065ff54 <ithread_loop>,
arg=0xc4f11140, frame=0xe3832d38) at /usr/src/sys/kern/kern_fork.c:821
#19 0xc0879dac in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:208
(kgdb)
Can you kindly advise ?
BR,
Glenn Camilleri
--
Best Regards,
Glenn Camilleri
------------------------------
Message: 2
Date: Tue, 16 Mar 2010 10:34:07 -0400
From: John Baldwin <j...@freebsd.org>
Subject: Re: Kernel dump crash
To: freebsd...@freebsd.org
Cc: Glenn Camilleri <glen...@gmail.com>
Message-ID: <20100316103...@freebsd.org>
Content-Type: Text/Plain; charset="windows-1252"
On Tuesday 16 March 2010 08:13:39 am Glenn Camilleri wrote:
> Hi,
>
>
>
> I have some processes and programs that are custom made to run on FreeBSD.
> I suspect some poor implementation of tcp in these programs, but don’t
> have the real proof.
I think this is an old bug that was fixed in 6.3. It was fixed in 6.x by this
commit:
jhb 2007-01-19 23:01:34 UTC
FreeBSD src repository
Modified files: (Branch: RELENG_6)
sys/contrib/pf/net if_pfsync.c
sys/dev/arl if_arl.c
sys/dev/ath if_ath.c
sys/dev/awi awi.c
sys/dev/ce if_ce.c
sys/dev/cp if_cp.c
sys/dev/ctau if_ct.c
sys/dev/cx if_cx.c
sys/dev/en midway.c
sys/dev/firewire if_fwip.c
sys/dev/gem if_gem.c
sys/dev/ipw if_ipw.c
sys/dev/iwi if_iwi.c
sys/dev/my if_my.c
sys/dev/ppbus if_plip.c
sys/dev/ral rt2560.c rt2661.c
sys/dev/usb if_ural.c
sys/dev/wi if_wi.c
sys/i4b/driver i4b_ipr.c
sys/net bpf.c bpf.h bpfdesc.h if_disc.c if_enc.c
if_faith.c if_fwsubr.c if_gif.c if_gre.c
if_loop.c if_sl.c if_stf.c if_tun.c
sys/net80211 ieee80211_input.c
sys/netgraph ng_iface.c ng_sppp.c
sys/netinet ip_carp.c ip_gre.c
Log:
MFC: Change the life cycle of bpf interface objects to close attach/detach
races with bpf(4). This includes shims to preserve the ABI for any old
modules. For more details see the commit log for 1.166 of sys/net/bpf.c.
Revision Changes Path
1.19.2.5 +5 -1 src/sys/contrib/pf/net/if_pfsync.c
1.10.2.2 +1 -1 src/sys/dev/arl/if_arl.c
1.94.2.29 +5 -4 src/sys/dev/ath/if_ath.c
1.37.2.5 +2 -2 src/sys/dev/awi/awi.c
1.3.6.2 +4 -4 src/sys/dev/ce/if_ce.c
1.24.2.2 +2 -4 src/sys/dev/cp/if_cp.c
1.25.2.2 +2 -4 src/sys/dev/ctau/if_ct.c
1.45.2.3 +2 -4 src/sys/dev/cx/if_cx.c
1.65.2.2 +2 -2 src/sys/dev/en/midway.c
1.7.2.4 +2 -2 src/sys/dev/firewire/if_fwip.c
1.29.2.6 +1 -2 src/sys/dev/gem/if_gem.c
1.7.2.6 +3 -3 src/sys/dev/ipw/if_ipw.c
1.8.2.11 +3 -3 src/sys/dev/iwi/if_iwi.c
1.29.2.5 +2 -2 src/sys/dev/my/if_my.c
1.37.2.3 +5 -5 src/sys/dev/ppbus/if_plip.c
1.9.2.2 +7 -7 src/sys/dev/ral/rt2560.c
1.10.2.2 +5 -5 src/sys/dev/ral/rt2661.c
1.10.2.10 +5 -5 src/sys/dev/usb/if_ural.c
1.180.2.9 +3 -3 src/sys/dev/wi/if_wi.c
1.34.2.2 +4 -4 src/sys/i4b/driver/i4b_ipr.c
1.153.2.9 +76 -71 src/sys/net/bpf.c
1.39.2.3 +29 -4 src/sys/net/bpf.h
1.29.2.3 +0 -13 src/sys/net/bpfdesc.h
1.48.2.2 +1 -1 src/sys/net/if_disc.c
1.5.2.2 +1 -1 src/sys/net/if_enc.c
1.36.2.2 +1 -1 src/sys/net/if_faith.c
1.12.2.6 +2 -2 src/sys/net/if_fwsubr.c
1.52.2.7 +2 -4 src/sys/net/if_gif.c
1.32.2.7 +1 -1 src/sys/net/if_gre.c
1.106.2.3 +2 -2 src/sys/net/if_loop.c
1.129.2.1 +4 -4 src/sys/net/if_sl.c
1.50.2.2 +2 -2 src/sys/net/if_stf.c
1.152.2.4 +1 -1 src/sys/net/if_tun.c
1.62.2.15 +4 -4 src/sys/net80211/ieee80211_input.c
1.43.2.3 +1 -1 src/sys/netgraph/ng_iface.c
1.8.2.3 +2 -4 src/sys/netgraph/ng_sppp.c
1.27.2.10 +1 -1 src/sys/netinet/ip_carp.c
1.19.2.4 +2 -2 src/sys/netinet/ip_gre.c
--
John Baldwin
------------------------------
Message: 3
Date: Tue, 16 Mar 2010 17:00:12 +0100
From: Pieter de Goeje <pie...@degoeje.nl>
Subject: Re: Drop cache
To: freebsd...@freebsd.org
Cc: Havacci <hav...@gmail.com>
Message-ID: <201003161700...@degoeje.nl>
Content-Type: Text/Plain; charset="iso-8859-1"
On Monday 15 March 2010 04:33:04 Havacci wrote:
> How I can drop cache memory of my FreeBSD ? I search a lot about this
> and don't find anything.
> In Linux i usualy use this command:
> sync; echo 3 > /proc/sys/vm/drop_caches
Something comparable can be achieved by unmounting and remounting the test
filesystem.
- Pieter
------------------------------
Message: 4
Date: Tue, 16 Mar 2010 12:38:20 -0400
From: Jung-uk Kim <jk...@FreeBSD.org>
Subject: Re: [RFC] DTrace SYSCALL provider (was Re: [RFC] Saving the
latest errno from syscalls.)
To: freebsd...@freebsd.org
Cc: Kostik Belousov <kost...@gmail.com>, Marcel Moolenaar
<xcl...@mac.com>
Message-ID: <20100316123...@FreeBSD.org>
Content-Type: text/plain; charset="iso-8859-1"
On Monday 15 March 2010 02:10 pm, Jung-uk Kim wrote:
> On Friday 12 March 2010 01:32 pm, Jung-uk Kim wrote:
> > On Friday 12 March 2010 04:29 am, Kostik Belousov wrote:
> > > On Thu, Mar 11, 2010 at 06:15:07PM -0500, Jung-uk Kim wrote:
> > > > On Thursday 11 March 2010 04:55 pm, Marcel Moolenaar wrote:
> > > > > On Mar 11, 2010, at 1:24 PM, Jung-uk Kim wrote:
> > > > > > While I was debugging syscalls, I found a very useful
> > > > > > field in struct thread, td_errno. It seems it was added
> > > > > > for dtrace but it is only populated on amd64 and i386.
> > > > > > Is the attached patch acceptable for maintainers of other
> > > > > > platforms?
> > > > >
> > > > > Isn't it better to do it in cpu_set_syscall_retval()?
> > > > > That way you catch all cases, plus you can save the
> > > > > translated error as well...
> > > >
> > > > I just took amd64/i386 as an example and I was not sure
> > > > whether it was meant to store translated error or not. Does
> > > > anyone with DTrace internal knowledge answer the question?
> > >
> > > I do not know that much about DTrace, but it seems that setting
> > > td_errno in cpu_set_syscall_retval() is too late. Dtrace has a
> > > probe after the syscall return, and it is called right before
> > > cpu_set_syscall_retval() can be reasonably called. The probe
> > > only issued for syscall that goes into sysent.
> >
> > Ah, I can see that now. So, if/when we implement DTrace SYSCALL
> > provider for other arches, this is the right place. :-)
>
> I went ahead and implemented DTrace SYSCALL providers for non-x86
> arches. It passes 'make universe' test but I don't know if it
> works. Can maintainers of other arches test or review the attached
> patch?
I realized there are too many missing pieces for DTrace to work on
other arches. :-(
Please ignore this patch.
Jung-uk Kim
------------------------------
Message: 5
Date: Tue, 16 Mar 2010 23:51:09 +0100 (CET)
From: Juergen Lock <n...@jelal.kn-bremen.de>
Subject: Re: How to slow down SATA to 1.5 GBit/s ?
To: scdb...@gmx.net
Cc: freebsd...@freebsd.org
Message-ID: <201003162251....@triton8.kn-bremen.de>
In article <1060877...@192.168.2.69> you write:
>Hi,
Hi!
>
>> I have Cc'd mav@ who afaik did most of the ahci(4) work,
>
>I found a similar PR
> http://www.mail-archive.com/freebsd...@freebsd.org/msg70510.html
Hm thats my post, wrong link? :)
>and bothered mav for instructions how to upgrade
>to a system that would suffice for diagnosing.
>
That's also documented in the handbook, starting with `24.5.2 Staying
Stable with FreeBSD' here:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html
>Meanwhile i suspect that there is a general
>problem with SCSI commands which report error
>codes. I even found a little bug in cdrskin
>by watching when it gets stuck.
>(SCSI error or "sense" replies are not
> necessarily a sign of a program error. They
> are often just part of the dialog.)
>
>
>> Well I guess drives simply don't like `random other' commands being
>> sent to them while a burn is in progress...
>
>It depends on the media type.
>CD and DVD-R[W] are vulnerable. It's a classic
>side effect of hald.
>On Linux, the burn just ends with some more or
>less plausible SCSI error.
>FreeBSD 8.0 freshly from DVD was less graceful.
>Now it seems to know when not to let me touch
>the drive. ("Now" is already before ahci.)
>
>
>> I don't know if hald also sends direct scsi
>> commands via pass(4) devices, so that
>> may even need to be blocked too
>
>Making drive access exclusive is quite a tragic
>drama on Linux. Most burn programs rely on an
>undocumented meaning of open(O_EXCL). That would
>work well ... if there wasn't an older slightly
>incompatible undocumented meaning.
>(Cough.)
>O_EXCL works on inode level, whereas we actually
>would need locking on SCSI generic level, where
>all possible users of a drive come together.
>
>FreeBSD offers at least as many bypasses to the
>drive as Linux does. I imagine that it is not
>easy to lock them all.
>I'm not done with exploring yet.
>
Or maybe burning apps should just invoke hal-disable-polling(1), I
suspect that's intended for these kind of things...
>
>> > The port of xfburn generously (or daringly)
>> > writes into /etc/devfs.rules :
>> Ouch! :)
>
>Yeah. What happened to good old group "floppy" ?
>
>camcontrol devlist tells the particular device
>files. (I learned today on my way to ahci.)
>
Yep.
>
>Have a nice day :)
>
>Thomas
Ditto!
Juergen
------------------------------
Message: 6
Date: Wed, 17 Mar 2010 00:45:58 +0100
From: "Thomas Schmitt" <scdb...@gmx.net>
Subject: Re: How to slow down SATA to 1.5 GBit/s ?
To: freebsd...@freebsd.org
Message-ID: <1057305...@192.168.2.69>
Hi,
> > I found a similar PR
> > http://www.mail-archive.com/freebsd...@freebsd.org/msg70510.html
>
> Hm thats my post, wrong link? :)
Indeed. I copied the wrong URL from my mail to
mav. The PR is at
http://www.freebsd.org/cgi/query-pr.cgi?pr=amd64/144151
This here would match my theory:
>> cdrecord: Input/output error. test unit ready: scsi sendcmd: cmd timeout after 40.010 (40) s
>> CDB: 00 00 00 00 00 00
because the command is sent especially to see
whether any eventual error condition is gone.
It should get a reply within milliseconds.
> > and bothered mav for instructions how to upgrade
> That's also documented in the handbook, starting with `24.5.2 Staying
> Stable with FreeBSD'
I read that before asking. It seems a bit
outdated ("7-STABLE") and it is full of warnings.
Actually i hardly feel ripe for makeworld.html
I will combine that with my endeavor to install
another FreeBSD from scratch.
> Or maybe burning apps should just invoke hal-disable-polling(1), I
> suspect that's intended for these kind of things...
Interesting. I'll try to find out whether it
works. (Often hal stuff on Linux does not work.
The usual remedy is killall hald-addon-storage.)
First i'll have to learn how to get a X desktop.
Then i have to see whether hald does any harm.
Have a nice day :)
Thomas
------------------------------
Message: 7
Date: Wed, 17 Mar 2010 11:16:16 +0100 (CET)
From: Mohacsi Janos <moh...@niif.hu>
Subject: ATA 4K sector issues
To: freebsd...@freebsd.org
Message-ID: <alpine.BSF.2.00.1...@mignon.ki.iif.hu>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Dear FreeBSD hackers,
What is the situation with ATA 4K dirves in FreeBSD? Are there any
support for them in fdisk or disklabel?
More information at:
http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues
Janos Mohacsi
Head of HBONE+ project
Network Engineer, Deputy Director of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
------------------------------
Message: 8
Date: Wed, 17 Mar 2010 12:37:12 +0200
From: Andriy Gapon <a...@icyb.net.ua>
Subject: Re: ATA 4K sector issues
To: Mohacsi Janos <moh...@niif.hu>
Cc: freebsd...@freebsd.org
Message-ID: <4BA0B0D8...@icyb.net.ua>
Content-Type: text/plain; charset=ISO-8859-1
on 17/03/2010 12:16 Mohacsi Janos said the following:
> Dear FreeBSD hackers,
> What is the situation with ATA 4K dirves in FreeBSD? Are there any
> support for them in fdisk or disklabel?
> More information at:
> http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues
Did you mean to say gpart(1)? :)
AFAIK, the tool(s) do not auto-align on 4K boundaries, but they give user an
ability to do that by hand.
Besides, some 4K sector disks lie that they have 512 sectors.
--
Andriy Gapon
------------------------------
Message: 9
Date: Wed, 17 Mar 2010 04:11:04 -0700
From: Kent Stewart <kste...@owt.com>
Subject: Re: ATA 4K sector issues
To: freebsd...@freebsd.org
Cc: Andriy Gapon <a...@icyb.net.ua>, Mohacsi Janos <moh...@niif.hu>
Message-ID: <201003170411....@owt.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wednesday 17 March 2010 03:37:12 am Andriy Gapon wrote:
> on 17/03/2010 12:16 Mohacsi Janos said the following:
> > Dear FreeBSD hackers,
> > What is the situation with ATA 4K dirves in FreeBSD? Are there
> > any support for them in fdisk or disklabel?
> > More information at:
> > http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues
>
> Did you mean to say gpart(1)? :)
> AFAIK, the tool(s) do not auto-align on 4K boundaries, but they give
> user an ability to do that by hand.
> Besides, some 4K sector disks lie that they have 512 sectors.
An article on the effect is located at
http://storageeffect.media.seagate.com/2010/03/storage-effect/y2-011k-looming-for-windows-xp-users/
Kent
--
Kent Stewart
Richland, WA
http://users.owt.com/kstewart/index.html
------------------------------
End of freebsd-hackers Digest, Vol 364, Issue 3
***********************************************