misc/147757: zoneinfo out of date
>Number: 147757 >Category: misc >Synopsis: zoneinfo out of date >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Thu Jun 10 07:50:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Jim Mercer >Release:8.0-RELEASE + cvsup >Organization: Reptilian Research >Environment: FreeBSD ocms.pk.innexiv.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Wed Jun 9 23:05:15 PKST 2010 t...@ocms.pk.innexiv.com:/usr/obj/usr/src/sys/GENERIC i386 >Description: the data in /usr/src/share/zoneinfo is out of date. in particular, Pakistan has recinded DST. but a diff between the current FreeBSD data and that located at ftp://elsie.nci.nih.gov/pub/ indicates numerous other changes. it might be an idea to have someone check those files periodically, so that the current timezone info is relevant. >How-To-Repeat: >Fix: update /usr/src/share/zoneinfo with data from ftp://elsie.nci.nih.gov/pub/ >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: conf/147757: zoneinfo out of date
Synopsis: zoneinfo out of date Responsible-Changed-From-To: freebsd-bugs->edwin Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jun 10 09:30:51 UTC 2010 Responsible-Changed-Why: IIRC edwin has been looking after zoneinfo. http://www.freebsd.org/cgi/query-pr.cgi?pr=147757 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144948: mdconfig(8): mdconfig -l doesn't properly increment device number
Synopsis: mdconfig(8): mdconfig -l doesn't properly increment device number State-Changed-From-To: patched->feedback State-Changed-By: jh State-Changed-When: Thu Jun 10 15:13:31 UTC 2010 State-Changed-Why: Can you clarify which revision(s) should be MFCd? http://www.freebsd.org/cgi/query-pr.cgi?pr=144948 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/147767: route -n change operation with INVARIANTS kernel causes mutex radix node head not owned ASSERTION failure
>Number: 147767
>Category: kern
>Synopsis: route -n change operation with INVARIANTS kernel causes mutex
>radix node head not owned ASSERTION failure
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Jun 10 17:00:13 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Haven Hash
>Release:7.3 Release
>Organization:
Isilon
>Environment:
FreeBSD 7.3-RELEASE FreeBSD 7.3-RELEASE #1: Thu Jun 10 01:24:18 UTC 2010
root@:/usr/obj/usr/src/sys/GENERIC i386
>Description:
When running certain route operations via the userspace route utility on
kernels built with the following options:
INVARIANTS
INVARIANT_SUPPORT
a lock assertion causes a kernel panic, the panic requires these options
because the assertion is only checked when INVARIANT support is enabled,
however it seems likely that other consistency problems could occur on
non-INVARIANT kernels.
>How-To-Repeat:
Compile and install a kernel with the following two lines included in the
kernel configuration file:
option INVARIANTS
option INVARIANT_SUPPORT
If your machine does not have multiple external interfaces then you can create
multiple vlan interfaces to substitute in for the following examples.
Add an IP address to an external interface (i.e. ifconfig em0 1.1.1.1 netmask
255.255.0.0).
Add another IP address in the same subnet to another external interface (i.e.
ifconfig em1 1.1.1.2 netmask 255.255.0.0)
Attempt to use the route command to move the subnet route associated with the
previously assigned IP addresses to go out the other interface (i.e. route -n
change 1.1.0.0 -netmask 255.255.0.0 -ifp em1)
With INVARIANTS enabled a RNH (radix node head) lock assertion is hit.
A partial stack from one machine is as follows:
panic @ time 1276188167.945, thread 0x907f8000: mutex radix node head not owned
Panic occurred in module kernel loaded at 0x8020:
Stack: --
kernel:_mtx_assert+0x72
kernel:rt_setgate+0xb9
kernel:arp_rtrequest+0x91
kernel:route_output+0x8d7
kernel:raw_usend+0x63
kernel:rts_send+0x27
kernel:sosend_generic+0x4f7
kernel:sosend+0x2e
>Fix:
It looks like rev: 189026 (a collection of merged revisions) added this assert
and from the stack it looks like the calling of rt_setgate() from
arp_rtrequest() does not take the necessary RNH lock being checked for. This
code path is not the same in 8.x (nor have I been able to reproduce the issue
on 8.x) as the arp code has been restructured in that line.
Attached patch which works for me, basically looks up the appropriate RNH from
the global rt_tables and other available local variables, locks it before
calling rt_setgate and unlocks it afterwards. Modified from similar code in
route_output which does take this lock before calling rt_setgate().
Patch attached with submission follows:
Index: sys/netinet/if_ether.c
===
--- sys/netinet/if_ether.c (revision 206544)
+++ sys/netinet/if_ether.c (working copy)
@@ -154,6 +154,7 @@
static struct sockaddr_dl null_sdl = {sizeof(null_sdl), AF_LINK};
struct in_ifaddr *ia;
struct ifaddr *ifa;
+ struct radix_node_head *rnh;
RT_LOCK_ASSERT(rt);
@@ -177,8 +178,15 @@
/*
* Case 1: This route should come from a route to iface.
*/
+ rnh =
rt_tables[rt->rt_fibnum][info->rti_info[RTAX_DST]->sa_family];
+ if (rnh == NULL)
+ break;
+ RT_UNLOCK(rt);
+ RADIX_NODE_HEAD_LOCK(rnh);
+ RT_LOCK(rt);
rt_setgate(rt, rt_key(rt),
(struct sockaddr *)&null_sdl);
+ RADIX_NODE_HEAD_UNLOCK(rnh);
gate = rt->rt_gateway;
SDL(gate)->sdl_type = rt->rt_ifp->if_type;
SDL(gate)->sdl_index = rt->rt_ifp->if_index;
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/147769: 'ifconfig epair0 create' hangs the whole system
>Number: 147769 >Category: kern >Synopsis: 'ifconfig epair0 create' hangs the whole system >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 10 17:50:00 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Michael Moll >Release:9.0-CURRENT >Organization: >Environment: FreeBSD fujisan.kvedulv.de 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu Jun 10 18:09:12 CEST 2010 r...@fujisan.kvedulv.de:/usr/obj/usr/src/sys/VIMAGE sparc64 >Description: This might be specific to sparc64 - or a general VImage problem. I use r208975 and the following kernel config: include GENERIC ident VIMAGE nooptions SCTP options VIMAGE options BREAK_TO_DEBUGGER When doing a 'ifconfig epair0 create' the whole machine hangs (no I/O, no ping). A backtrace after breaking shows: db> bt Tracing pid 2135 tid 100124 td 0xf800045f9270 uart_intr() at uart_intr+0x1ac intr_event_handle() at intr_event_handle+0x5c intr_execute_handlers() at intr_execute_handlers+0x8 intr_fast() at intr_fast+0x68 -- interrupt level=0xc pil=0 %o7=0xc0088ff8 -- -- fast data access mmu miss tar=0x127d2a000 %o7=0xc03d7d40 -- mtx_init() at mtx_init+0x134 epair_modevent() at epair_modevent+0xe4 module_register_init() at module_register_init+0xdc linker_load_module() at linker_load_module+0xbd8 kern_kldload() at kern_kldload+0xd0 kldload() at kldload+0x60 syscallenter() at syscallenter+0x268 syscall() at syscall+0x74 -- syscall (304, FreeBSD ELF64, kldload) %o7=0x102fe0 -- userland() at 0x408c2028 user trace: trap %o7=0x102fe0 pc 0x408c2028, sp 0x7fdd8e1 pc 0x104504, sp 0x7fdda11 pc 0x102510, sp 0x7fde291 pc 0x40226f54, sp 0x7fde351 done >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/147769: 'ifconfig epair0 create' hangs the whole system
Synopsis: 'ifconfig epair0 create' hangs the whole system Responsible-Changed-From-To: freebsd-bugs->bz Responsible-Changed-By: bz Responsible-Changed-When: Thu Jun 10 17:59:41 UTC 2010 Responsible-Changed-Why: epair(4) is mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=147769 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/143558: [patch] Add verbose option to pkill(1)
The following reply was made to PR bin/143558; it has been noted by GNATS.
From: Eitan Adler
To: bug-follo...@freebsd.org, eitanadlerl...@gmail.com
Cc:
Subject: Re: bin/143558: [patch] Add verbose option to pkill(1)
Date: Thu, 10 Jun 2010 23:43:05 +0300
Changing stdout to stderr.
Index: pkill.1
===
--- pkill.1(revision 208656)
+++ pkill.1(working copy)
@@ -168,9 +168,9 @@
If used in conjunction with
.Fl f ,
print the process ID and the full argument list for each matching process.
-This option can only be used with the
-.Nm pgrep
-command.
+If used in conjunction with the
+.Nm pkill
+command, it lists the signal sent as well.
.It Fl n
Select only the newest (most recently started) of the matching processes.
.It Fl o
Index: pkill.c
===
--- pkill.c(revision 208656)
+++ pkill.c(working copy)
@@ -246,8 +246,6 @@
criteria = 1;
break;
case 'l':
- if (!pgrep)
- usage();
longfmt = 1;
break;
case 'n':
@@ -529,16 +527,26 @@
/*
* Take the appropriate action for each matched process, if any.
*/
+ int didAction = 0;
for (i = 0, rv = 0, kp = plist; i < nproc; i++, kp++) {
if (PSKIP(kp))
continue;
if (selected[i]) {
+ if (longfmt && !pgrep)
+ {
+ didAction = 1;
+ printf("kill -%d %d\n",signum,kp->ki_pid);
+ }
if (inverse)
continue;
} else if (!inverse)
continue;
rv |= (*action)(kp);
}
+ if (!didAction && !pgrep && longfmt)
+ {
+ fprintf(stderr,"No matching processes belonging to you were
found\n");
+ }
exit(rv ? STATUS_MATCH : STATUS_NOMATCH);
}
@@ -551,7 +559,7 @@
if (pgrep)
ustr = "[-LSfilnovx] [-d delim]";
else
- ustr = "[-signal] [-ILfinovx]";
+ ustr = "[-signal] [-ILfilnovx]";
fprintf(stderr,
"usage: %s %s [-F pidfile] [-G gid] [-M core] [-N system]\n"
--
Eitan Adler
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/147082: [uart] Serial ports unusable
On 2010-06-04, at 20:47 , Garrett Cooper wrote: > On Fri, Jun 4, 2010 at 5:28 PM, Mayo Jordanov wrote: >> Hi Andy, >> >> Thanks for the suggestion. I have all my ports mapped directly as you have, >> and I also tried setting the bios to reserve the IRQs so nothing else gets >> to use them. >> >> Thank you for the suggestions and keeping an eye on this. >> mayo >> >> On 2010-06-04, at 16:43 , Andy Farkas wrote: >> >>> On Sat, Jun 5, 2010 at 5:00 AM, Mayo Jordanov wrote: One more report, I loaded FreeBSD 6.4 on this machine, and the serial = ports work without any problems.= >>> >>> Hi Mayo, >>> >>> You might remember that I was having this problem as well, no output on >>> serial ports, on my HP ProLiant ML 100 box. >>> >>> I solved it by going into BIOS and explicitly setting the COM ports to >>> 3F8/4 and 2F8/3. They were set to AUTO before. As a side note, when set >>> to AUTO, COM2 did not show up in dmesg. >>> >>> What are your BIOS settings? > > Was this an upgrade or a fresh install? If it was an upgrade, what > version of FreeBSD did you upgrade from? Can you please provide your > device.hints file? > Thanks, > -Garrett Hi Garrett, I started looking at the code a bit. I'm not very experienced with inner workings of serial or kernel drivers, but here are a few observations I made: With the uart in current state and terminal application on each end (using cuau3 atm), the FreeBSD side gets DTR, RTS On and CD, DST, CTS, RI are off. If I change device.hints and set flags for the port and add 0x100 to it (UART_FLAGS_FCR_RX_LOW) followed by a reboot and repeat the setup, I get: DST, CTS, DTR, RTS on and CD, RI off. The odd thing there is even at this point if I connect two terminal applications and turn off flow control, I can't get them to send stuff back and forth. So, the signals on port are detected, but there is still something that prevents data to be sent/received. I see the data arrive on the pins when I scope them, so the data must be lost somewhere in software. I've noticed this when I compared the 6.4 sio driver with 7.3's sio driver. 6.4 uses FIFO_RX_LOW, whereas 7 switched to using FIFO_RX_HIGH. In 7.x the driver doesn't work and reports silo overflows. Changing the FIFO_RX_HIGH to FIFO_RX_LOW (sio.c line 976 -- "sio_setreg(com, com_fifo, FIFO_ENABLE | FIFO_RX_HIGH);" ) fixes things in 7.x and then works same as in 6.4.w Similarly, there are quite a few differences in how some of the other registers are setup in _attach, _probe and other functions. There are definitely more DELAY calls in the old driver. Like I said, I'm not very familiar with lower levels of serial comms or I'm not sure what exactly this means for the driver, but may give you some ideas. Also, opening /dev/cuau* devices is quick, but closing them always times out in ttyclos() (when exiting kermit, etc). Thanks, mayo ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
