tmux fix when renaming session with no client attached

2018-04-10 Thread Ryan Freeman
Hey,

After upgrading OpenBSD 6.2 -> 6.3, a program I am building for $DAYJOB
started malfunctioning.

Basically, we use tmux to manage running sessions of this program, which
does automated work on things with console ports.

The session is started in a detached state with temp session name derived
from a date(1) stamp (date +%s) plus a few random digits:

$ tmux -S /var/someprog/default new-session -s tmp1234456789

After the program is running, a command is executed by the running
program to give it a proper session id, fetched from a database:

exec /usr/bin/tmux -S /var/someprog/default rename-session $SESSIONID

Tmux in OpenBSD 6.2 worked a-okay, tmux in 6.3 would return an error
indicating no current client.  This seems similar to here:

https://marc.info/?l=openbsd-cvs=152183263526828=2

I took a stab at fixing this in cmd-rename-session.c like was done
for cmd-rename-window.c, and the rebuilt tmux seems happy renaming
sessions from a program running within it again.

OK?  Flames? :-)

-ryan

Index: cmd-rename-session.c
===
RCS file: /cvs/src/usr.bin/tmux/cmd-rename-session.c,v
retrieving revision 1.27
diff -u -p -r1.27 cmd-rename-session.c
--- cmd-rename-session.c1 Mar 2018 12:53:08 -   1.27
+++ cmd-rename-session.c10 Apr 2018 23:21:52 -
@@ -47,7 +47,7 @@ static enum cmd_retval
 cmd_rename_session_exec(struct cmd *self, struct cmdq_item *item)
 {
struct args *args = self->args;
-   struct client   *c = cmd_find_client(item, NULL, 0);
+   struct client   *c = cmd_find_client(item, NULL, 1);
struct session  *s = item->target.s;
char*newname;



Re: sunfire v120 gem interfaces

2015-11-20 Thread Ryan Freeman
On Fri, Nov 13, 2015 at 12:36:40PM +1000, David Gwynne wrote:
> 
> > On 13 Nov 2015, at 12:16, Ryan Freeman <r...@slipgate.org> wrote:
> > 
> > On Tue, Nov 10, 2015 at 08:27:36PM +1000, David Gwynne wrote:
> >> any joy? i mean, failure?
> > 
> > Well I got something different.  I've noticed the failures only seem to 
> > happen
> > when my roommates arrive home.  I can use my stuff remotely all day from 
> > work
> > without a hitch, roommates come home and usually within an hr there is an
> > internet complaint.
> > 
> > Since I started using the little scripts to detect connection failure
> > and down/up the iface in question, things had been pretty good simply in the
> > fact that nobody could really notice before it fixed itself.
> > 
> > Today the machine dropped to ddb>!  of course i couldn't remember a damn
> > thing to type :(  i got trace, terribly sorry it wasn't more...
> > 
> > ddb> trace
> > extent_free(400012600c0, 0, 0, 0, 1fef078, 800012fa) at 
> > extent_free
> > +0x174
> > iommu_dvmamap_unload(40001266300, 0, 4000129f080, 0, 0, 2) at 
> > iommu_dvmamap_unl
> > oad+0x74
> > gem_rint(400014ac000, 40016ff, 7fff, e0017c48, 4000, 
> > 80
> > 00) at gem_rint+0x160
> > gem_intr(400014ac000, c00ca000, 2000, 0, 0, 8000) at gem_intr+0x154
> > intr_handler(e0017ec8, 4000117ae00, 4bca3020, 0, 800, 2) at intr_handler+0xc
> > sparc_interrupt(0, 400014b, 80206910, 400171b7c60, 40009ec0810, 0) at 
> > sparc
> > _interrupt+0x298
> > gem_ioctl(400014ac048, 400014ac000, 400171b7c60, 400171b7c60, 0, 
> > 40009b73c10) a
> > t gem_ioctl+0x19c
> > ifioctl(0, 80206910, 400171b7c60, 40009b73c10, 1012d74, 0) at ifioctl+0x38c
> > sys_ioctl(0, 400171b7db8, 400171b7df8, 0, 0, 14b) at sys_ioctl+0x190
> > syscall(400171b7ed0, 436, bec8920888, bec892088c, 0, 0) at syscall+0x3c4
> > softtrap(3, 80206910, fffe3018, 0, 0, 1ff7fff6df8) at softtrap+0x19c
> > ddb>
> 
> that is interesting. if you're still in ddb, can you go sh panic?
> 
> if not, not biggy.
> 
> my gut feeling is our ring accounting is wonky. mpi@ and jmatthew@ have 
> tweaks to gem(4) for mpsafety which might fix this. ill poke them to see if 
> they would share.

I scraped some more stuff from another panic, not running w/ the jmatthew patch 
yet
though...


Connected to /dev/cuaU0 (speed 9600)

ddb> trace
extent_free(400012600c0, 0, 0, 0, 1fef078, 86fc) at extent_free
+0x174 
iommu_dvmamap_unload(40001266300, 0, 4000129f080, 0, 0, 2) at iommu_dvmamap_unl
oad+0x74   
gem_rint(400014ac000, 40016ff, 7fff, e0017c48, 4000, 80
00) at gem_rint+0x160  
gem_intr(400014ac000, c005, 2000, 0, 0, 8000) at gem_intr+0x154
intr_handler(e0017ec8, 4000117ae00, 1b5e78e1, 0, 800, 2) at intr_handler+0xc
sparc_interrupt(0, 400014b, 80206910, 40017d87c60, 40009f34cb0, 0) at sparc
_interrupt+0x298   
gem_ioctl(400014ac048, 400014ac000, 40017d87c60, 40017d87c60, 0, 400096ca950) a
t gem_ioctl+0x19c  
ifioctl(0, 80206910, 40017d87c60, 400096ca950, 1012d74, 0) at ifioctl+0x38c
sys_ioctl(0, 40017d87db8, 40017d87df8, 0, 0, 14b) at sys_ioctl+0x190   
syscall(40017d87ed0, 436, 198ac20888, 198ac2088c, 0, 0) at syscall+0x3c4
softtrap(3, 80206910, fffd8138, 0, 0, 1ff7fff6df8) at softtrap+0x19c
ddb> sh panic   
extent_free: extent `psycho0 dvma', region not within extent
ddb> ps 
   PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
*22395   2599  32097  0  7 0x2ifconfig
  2599  32097  32097  0  30x8a  pause sh  
 32097   1585  32097  0  30x8a  pause sh
  1585  27132  27132  0  30x80  piperdcron
 21846  1  21846 77  20x90dhclient
 13160  1  13160  0  30x80  poll  dhclient
  5578   7747   5578   1000  30x83  ttyin ksh 
  7747  16002  16002   1000  30x90  selectsshd
 16002  28625  16002  0  30x92  poll  sshd
  4106195195  0  30x83  poll  pftop
   195  24715195   1000  30x8b  pause ksh  
 24715   5976   5976   1000  30x90  selectsshd
  5976  28625   5976  0  30x92  poll   

Re: sunfire v120 gem interfaces

2015-11-12 Thread Ryan Freeman
On Fri, Nov 13, 2015 at 12:36:40PM +1000, David Gwynne wrote:
> 
> > On 13 Nov 2015, at 12:16, Ryan Freeman <r...@slipgate.org> wrote:
> > 
> > On Tue, Nov 10, 2015 at 08:27:36PM +1000, David Gwynne wrote:
> >> any joy? i mean, failure?
> > 
> > Well I got something different.  I've noticed the failures only seem to 
> > happen
> > when my roommates arrive home.  I can use my stuff remotely all day from 
> > work
> > without a hitch, roommates come home and usually within an hr there is an
> > internet complaint.
> > 
> > Since I started using the little scripts to detect connection failure
> > and down/up the iface in question, things had been pretty good simply in the
> > fact that nobody could really notice before it fixed itself.
> > 
> > Today the machine dropped to ddb>!  of course i couldn't remember a damn
> > thing to type :(  i got trace, terribly sorry it wasn't more...
> > 
> > ddb> trace
> > extent_free(400012600c0, 0, 0, 0, 1fef078, 800012fa) at 
> > extent_free
> > +0x174
> > iommu_dvmamap_unload(40001266300, 0, 4000129f080, 0, 0, 2) at 
> > iommu_dvmamap_unl
> > oad+0x74
> > gem_rint(400014ac000, 40016ff, 7fff, e0017c48, 4000, 
> > 80
> > 00) at gem_rint+0x160
> > gem_intr(400014ac000, c00ca000, 2000, 0, 0, 8000) at gem_intr+0x154
> > intr_handler(e0017ec8, 4000117ae00, 4bca3020, 0, 800, 2) at intr_handler+0xc
> > sparc_interrupt(0, 400014b, 80206910, 400171b7c60, 40009ec0810, 0) at 
> > sparc
> > _interrupt+0x298
> > gem_ioctl(400014ac048, 400014ac000, 400171b7c60, 400171b7c60, 0, 
> > 40009b73c10) a
> > t gem_ioctl+0x19c
> > ifioctl(0, 80206910, 400171b7c60, 40009b73c10, 1012d74, 0) at ifioctl+0x38c
> > sys_ioctl(0, 400171b7db8, 400171b7df8, 0, 0, 14b) at sys_ioctl+0x190
> > syscall(400171b7ed0, 436, bec8920888, bec892088c, 0, 0) at syscall+0x3c4
> > softtrap(3, 80206910, fffe3018, 0, 0, 1ff7fff6df8) at softtrap+0x19c
> > ddb>
> 
> that is interesting. if you're still in ddb, can you go sh panic?
> 
> if not, not biggy.

Sadly, I am not.  as it is my router, I had to reboot to get back online to
send the mail.  If it triggers again I will make sure I include that.

> my gut feeling is our ring accounting is wonky. mpi@ and jmatthew@ have 
> tweaks to gem(4) for mpsafety which might fix this. ill poke them to see if 
> they would share.

I am willing to try anything! :)  I will reiterate that I am just running 5.8
stable (with mtier binpatches for errata); if it requires me to bump up to
-current, no biggie :)

> 
> dlg
> 
> > 
> > 
> > 
> >> 
> >>> On 9 Nov 2015, at 10:40 AM, Ryan Freeman <r...@slipgate.org> wrote:
> >>> 
> >>> On Mon, Nov 09, 2015 at 10:07:31AM +1000, David Gwynne wrote:
> >>>> can you get the ifconfig output when its locked up? and a copy of what 
> >>>> systat mb is showing?
> >>>> 
> >>>> cheers,
> >>>> dlg
> >>> 
> >>> Thanks David,
> >>> 
> >>> I have setup a script to try and capture this immediately when it happens.
> >>> 
> >>> FWIW here is the output as it is now, working:
> >>> 
> >>> 16:35 ryan@void:~$ ifconfig
> >>> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
> >>>   priority: 0
> >>>   groups: lo
> >>>   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
> >>>   inet6 ::1 prefixlen 128
> >>>   inet 127.0.0.1 netmask 0xff00
> >>> gem0: flags=8867<UP,BROADCAST,DEBUG,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> 
> >>> mtu 1500
> >>>   lladdr 00:03:ba:2b:47:70
> >>>   priority: 0
> >>>   groups: egress
> >>>   media: Ethernet autoselect (100baseTX full-duplex)
> >>>   status: active
> >>>   inet 96.54.13.103 netmask 0xfc00 broadcast 96.54.15.255
> >>> gem1: 
> >>> flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST>
> >>>  mtu 1500
> >>>   lladdr 00:03:ba:2b:47:71
> >>>   priority: 0
> >>>   media: Ethernet autoselect (100baseTX full-duplex)
> >>>   status: active
> >>>   inet 10.16.1.30 netmask 0xffe0 broadcast 10.16.1.31
> >>>   inet6 fe80::203:baff:fe2b:4771%gem1 prefixlen 64 scopeid 0x2
> >>>   inet6 2001:470:b:6cf::1 prefixlen 64
> >>> enc0: flag

Re: sunfire v120 gem interfaces

2015-11-12 Thread Ryan Freeman
On Tue, Nov 10, 2015 at 08:27:36PM +1000, David Gwynne wrote:
> any joy? i mean, failure?

Well I got something different.  I've noticed the failures only seem to happen
when my roommates arrive home.  I can use my stuff remotely all day from work
without a hitch, roommates come home and usually within an hr there is an
internet complaint.

Since I started using the little scripts to detect connection failure
and down/up the iface in question, things had been pretty good simply in the
fact that nobody could really notice before it fixed itself.

Today the machine dropped to ddb>!  of course i couldn't remember a damn
thing to type :(  i got trace, terribly sorry it wasn't more...

ddb> trace
extent_free(400012600c0, 0, 0, 0, 1fef078, 800012fa) at extent_free
+0x174
iommu_dvmamap_unload(40001266300, 0, 4000129f080, 0, 0, 2) at iommu_dvmamap_unl
oad+0x74
gem_rint(400014ac000, 40016ff, 7fff, e0017c48, 4000, 80
00) at gem_rint+0x160
gem_intr(400014ac000, c00ca000, 2000, 0, 0, 8000) at gem_intr+0x154
intr_handler(e0017ec8, 4000117ae00, 4bca3020, 0, 800, 2) at intr_handler+0xc
sparc_interrupt(0, 400014b, 80206910, 400171b7c60, 40009ec0810, 0) at sparc
_interrupt+0x298
gem_ioctl(400014ac048, 400014ac000, 400171b7c60, 400171b7c60, 0, 40009b73c10) a
t gem_ioctl+0x19c
ifioctl(0, 80206910, 400171b7c60, 40009b73c10, 1012d74, 0) at ifioctl+0x38c
sys_ioctl(0, 400171b7db8, 400171b7df8, 0, 0, 14b) at sys_ioctl+0x190
syscall(400171b7ed0, 436, bec8920888, bec892088c, 0, 0) at syscall+0x3c4
softtrap(3, 80206910, fffe3018, 0, 0, 1ff7fff6df8) at softtrap+0x19c
ddb>



> 
> > On 9 Nov 2015, at 10:40 AM, Ryan Freeman <r...@slipgate.org> wrote:
> > 
> > On Mon, Nov 09, 2015 at 10:07:31AM +1000, David Gwynne wrote:
> >> can you get the ifconfig output when its locked up? and a copy of what 
> >> systat mb is showing?
> >> 
> >> cheers,
> >> dlg
> > 
> > Thanks David,
> > 
> > I have setup a script to try and capture this immediately when it happens.
> > 
> > FWIW here is the output as it is now, working:
> > 
> > 16:35 ryan@void:~$ ifconfig
> > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
> >priority: 0
> >groups: lo
> >inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
> >inet6 ::1 prefixlen 128
> >inet 127.0.0.1 netmask 0xff00
> > gem0: flags=8867<UP,BROADCAST,DEBUG,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> 
> > mtu 1500
> >lladdr 00:03:ba:2b:47:70
> >priority: 0
> >groups: egress
> >media: Ethernet autoselect (100baseTX full-duplex)
> >status: active
> >inet 96.54.13.103 netmask 0xfc00 broadcast 96.54.15.255
> > gem1: 
> > flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST>
> >  mtu 1500
> >lladdr 00:03:ba:2b:47:71
> >priority: 0
> >media: Ethernet autoselect (100baseTX full-duplex)
> >status: active
> >inet 10.16.1.30 netmask 0xffe0 broadcast 10.16.1.31
> >inet6 fe80::203:baff:fe2b:4771%gem1 prefixlen 64 scopeid 0x2
> >inet6 2001:470:b:6cf::1 prefixlen 64
> > enc0: flags=0<>
> >priority: 0
> >groups: enc
> >status: active
> > vlan100: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> >lladdr 00:03:ba:2b:47:71
> >description: servers
> >priority: 0
> >vlan: 100 parent interface: gem1
> >groups: vlan
> >status: active
> >inet 10.21.1.30 netmask 0xffe0 broadcast 10.21.1.31
> >inet6 fe80::203:baff:fe2b:4771%vlan100 prefixlen 64 scopeid 0x5
> >inet6 2001:470:eac8:666::1 prefixlen 64
> > vlan101: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> >lladdr 00:03:ba:2b:47:71
> >description: workstations
> >priority: 0
> >vlan: 101 parent interface: gem1
> >groups: vlan
> >status: active
> >inet 10.21.8.254 netmask 0xff80 broadcast 10.21.8.255
> >inet6 fe80::203:baff:fe2b:4771%vlan101 prefixlen 64 scopeid 0x6
> >inet6 2001:470:eac8:a::1 prefixlen 64
> > vlan102: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> >lladdr 00:03:ba:2b:47:71
> >description: wireless
> >priority: 0
> >vlan: 102 parent interface: gem1
> >groups: vlan
> >status: active
> >inet 10.21.9.254 netmask 0xff80 broadcast 10.21.9.255
> >inet6 fe80::203

Re: sunfire v120 gem interfaces

2015-11-10 Thread Ryan Freeman
  
pflow0  
pflog0   

> 
> > On 9 Nov 2015, at 10:40 AM, Ryan Freeman <r...@slipgate.org> wrote:
> > 
> > On Mon, Nov 09, 2015 at 10:07:31AM +1000, David Gwynne wrote:
> >> can you get the ifconfig output when its locked up? and a copy of what 
> >> systat mb is showing?
> >> 
> >> cheers,
> >> dlg
> > 
> > Thanks David,
> > 
> > I have setup a script to try and capture this immediately when it happens.
> > 
> > FWIW here is the output as it is now, working:
> > 
> > 16:35 ryan@void:~$ ifconfig
> > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
> >priority: 0
> >groups: lo
> >inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
> >inet6 ::1 prefixlen 128
> >inet 127.0.0.1 netmask 0xff00
> > gem0: flags=8867<UP,BROADCAST,DEBUG,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> 
> > mtu 1500
> >lladdr 00:03:ba:2b:47:70
> >priority: 0
> >groups: egress
> >media: Ethernet autoselect (100baseTX full-duplex)
> >status: active
> >inet 96.54.13.103 netmask 0xfc00 broadcast 96.54.15.255
> > gem1: 
> > flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST>
> >  mtu 1500
> >lladdr 00:03:ba:2b:47:71
> >priority: 0
> >media: Ethernet autoselect (100baseTX full-duplex)
> >status: active
> >inet 10.16.1.30 netmask 0xffe0 broadcast 10.16.1.31
> >inet6 fe80::203:baff:fe2b:4771%gem1 prefixlen 64 scopeid 0x2
> >inet6 2001:470:b:6cf::1 prefixlen 64
> > enc0: flags=0<>
> >priority: 0
> >groups: enc
> >status: active
> > vlan100: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> >lladdr 00:03:ba:2b:47:71
> >description: servers
> >priority: 0
> >vlan: 100 parent interface: gem1
> >groups: vlan
> >status: active
> >inet 10.21.1.30 netmask 0xffe0 broadcast 10.21.1.31
> >inet6 fe80::203:baff:fe2b:4771%vlan100 prefixlen 64 scopeid 0x5
> >inet6 2001:470:eac8:666::1 prefixlen 64
> > vlan101: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> >lladdr 00:03:ba:2b:47:71
> >description: workstations
> >priority: 0
> >vlan: 101 parent interface: gem1
> >groups: vlan
> >status: active
> >inet 10.21.8.254 netmask 0xff80 broadcast 10.21.8.255
> >inet6 fe80::203:baff:fe2b:4771%vlan101 prefixlen 64 scopeid 0x6
> >inet6 2001:470:eac8:a::1 prefixlen 64
> > vlan102: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> >lladdr 00:03:ba:2b:47:71
> >description: wireless
> >priority: 0
> >vlan: 102 parent interface: gem1
> >groups: vlan
> >status: active
> >inet 10.21.9.254 netmask 0xff80 broadcast 10.21.9.255
> >inet6 fe80::203:baff:fe2b:4771%vlan102 prefixlen 64 scopeid 0x7
> >inet6 2001:470:eac8:b::1 prefixlen 64
> > vlan2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> >lladdr 00:03:ba:2b:47:71
> >description: transit
> >priority: 0
> >vlan: 2 parent interface: gem1
> >groups: vlan
> >status: active
> >inet 172.21.1.2 netmask 0xfffc broadcast 172.21.1.3
> > tun0: flags=51<UP,POINTOPOINT,RUNNING> mtu 1500
> >priority: 0
> >groups: tun
> >status: down
> >inet 10.21.2.1 --> 10.21.2.2 netmask 0xfffc
> > gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
> >priority: 0
> >groups: gif egress
> >tunnel: inet 96.54.13.103 -> 216.218.226.238
> >inet6 fe80::203:baff:fe2b:4770%gif0 ->  prefixlen 64 scopeid 0xa
> >inet6 2001:470:a:6cf::2 -> 2001:470:a:6cf::1 prefixlen 128
> > pflow0: flags=41<UP,RUNNING> mtu 1492
> >priority: 0
> >pflow: sender: 127.0.0.1 receiver: 127.0.0.1:9995 version: 5
> >groups: pflow
> > pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33144
> >priority: 0
> >groups: pflog
> > 
> > 16:36 ryan@void:~$ systat -b mb
> >8 usersLoad 0.21 0.25 0.26 Sun Nov  8 16:37:1

sunfire v120 gem interfaces

2015-11-08 Thread Ryan Freeman
Hey tech@,

At my wits end here, I recently got a sunfire v120 from work for pretty cheap.
Quite excited to have some non x86 hardware, I set it up as a router.

However, for some reason after sometimes mere hours -- othertimes days at a
time,  the gem0 interface needs to be cycled:

ifconfig gem0 down
ifconfig gem0 up
dhclient gem0

no packets pass until that has been done.   At first I have been placing the
blame squarely on the Hitron modem we have in the house from shaw cable,
but now I've noticed the issue happen twice on the internal interface as well,
gem1.  All VLANs I have setup stop responding until gem1 is cycled.

gem1 is just used by a collection of vlan(4) interfaces, so traffic resumes
immediately after interface gem1 down/up.

I've tried to turn on ifconfig gem0 debug to catch anything wierd, but there
has been nothing of interest there.   Dmesg attached,  starting to wonder
if this machine is at its EOL and the network ports are dying :(

This issue occurred with the 5.7 release as well.

dmesg:
console is /pci@1f,0/pci@1,1/isa@7/serial@0,3f8
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.8 (GENERIC) #0: Thu Oct 22 00:24:09 PDT 2015
r...@void.inter.lan:/usr/src/sys/arch/sparc64/compile/GENERIC
real mem = 1073741824 (1024MB)
avail mem = 1039228928 (991MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: Sun Fire V120 (UltraSPARC-IIe 648MHz)
cpu0 at mainbus0: SUNW,UltraSPARC-IIe (rev 3.3) @ 648 MHz
cpu0: physical 16K instruction (32 b/l), 16K data (32 b/l), 512K external (64 
b/l)
psycho0 at mainbus0: SUNW,sabre, impl 0, version 0, ign 7c0
psycho0: bus range 0-2, PCI bus 0
psycho0: dvma map c000-dfff
pci0 at psycho0
ppb0 at pci0 dev 1 function 1 "Sun Simba" rev 0x13
pci1 at ppb0 bus 1
ebus0 at pci1 dev 12 function 0 "Sun RIO EBus" rev 0x01
"flashprom" at ebus0 addr 0-f not configured
clock1 at ebus0 addr 0-1fff: mk48t59
lom0 at ebus0 addr 20-23 ivec 0x2a: LOMlite2 rev 3.12
alipm0 at pci1 dev 3 function 0 "Acer Labs M7101 Power" rev 0x00: 74KHz clock
iic0 at alipm0
"max1617" at alipm0 addr 0x18 skipped due to alipm0 bugs
spdmem0 at iic0 addr 0x54: 512MB SDRAM registered ECC PC133CL2
spdmem1 at iic0 addr 0x55: 512MB SDRAM registered ECC PC133CL2
ebus1 at pci1 dev 7 function 0 "Acer Labs M1533 ISA" rev 0x00
power0 at ebus1 addr 2000-2007 ivec 0x25
com0 at ebus1 addr 3f8-3ff ivec 0x2b: ns16550a, 16 byte fifo
com0: console
com1 at ebus1 addr 2e8-2ef ivec 0x2b: ns16550a, 16 byte fifo
gem0 at pci1 dev 12 function 1 "Sun ERI Ether" rev 0x01: ivec 0x7c6, address 
00:03:ba:2b:47:70
ukphy0 at gem0 phy 1: Generic IEEE 802.3u media interface, rev. 1: OUI 
0x0010dd, model 0x0002
ohci0 at pci1 dev 12 function 3 "Sun USB" rev 0x01: ivec 0x7e4, version 1.0, 
legacy support
pciide0 at pci1 dev 13 function 0 "Acer Labs M5229 UDMA IDE" rev 0xc3: DMA, 
channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide0: using ivec 0x7cc for native-PCI interrupt
atapiscsi0 at pciide0 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 disabled (no drives)
gem1 at pci1 dev 5 function 1 "Sun ERI Ether" rev 0x01: ivec 0x7dc, address 
00:03:ba:2b:47:71
ukphy1 at gem1 phy 1: Generic IEEE 802.3u media interface, rev. 1: OUI 
0x0010dd, model 0x0002
ohci1 at pci1 dev 5 function 3 "Sun USB" rev 0x01: ivec 0x7e6, version 1.0, 
legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 "Sun OHCI root hub" rev 1.00/1.00 addr 1
usb1 at ohci1: USB revision 1.0
uhub1 at usb1 "Sun OHCI root hub" rev 1.00/1.00 addr 1
ppb1 at pci0 dev 1 function 0 "Sun Simba" rev 0x13
pci2 at ppb1 bus 2
siop0 at pci2 dev 8 function 0 "Symbios Logic 53c896" rev 0x07: ivec 0x7e0, 
using 8K of on-board RAM
scsibus2 at siop0: 16 targets, initiator 7
sym0 at scsibus2 targ 0 lun 0:  SCSI3 0/direct 
fixed serial.SEAGATE_ST336607LSUN36G_3JA0DGN8731804D9
sd0 at scsibus0 targ 0 lun 0:  SCSI3 0/direct 
fixed serial.SEAGATE_ST336607LSUN36G_3JA0DGN8731804D9
sd0: 34732MB, 512 bytes/sector, 71132959 sectors
probe(siop0:1:0): Check Condition (error 0x70) on opcode 0x0
SENSE KEY: Hardware Error
 ASC/ASCQ: Defect List Error
 FRU CODE: 0x7
sym1 at scsibus2 targ 1 lun 0:  SCSI3 0/direct 
fixed serial.SEAGATE_ST336607LSUN36G_3JA0BZL12316NCUL
sd1 at scsibus0 targ 1 lun 0:  SCSI3 0/direct 
fixed serial.SEAGATE_ST336607LSUN36G_3JA0BZL12316NCUL
siop1 at pci2 dev 8 function 1 "Symbios Logic 53c896" rev 0x07: ivec 0x7e0, 
using 8K of on-board RAM
scsibus3 at siop1: 16 targets, initiator 7
siop0: target 0 now using tagged 16 bit 40.0 MHz 31 REQ/ACK offset xfers
vscsi0 at 

Re: sunfire v120 gem interfaces

2015-11-08 Thread Ryan Freeman
On Mon, Nov 09, 2015 at 10:07:31AM +1000, David Gwynne wrote:
> can you get the ifconfig output when its locked up? and a copy of what systat 
> mb is showing?
> 
> cheers,
> dlg

Thanks David,

I have setup a script to try and capture this immediately when it happens.

FWIW here is the output as it is now, working:

16:35 ryan@void:~$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
priority: 0
groups: lo
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff00
gem0: flags=8867<UP,BROADCAST,DEBUG,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 
1500
lladdr 00:03:ba:2b:47:70
priority: 0
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 96.54.13.103 netmask 0xfc00 broadcast 96.54.15.255
gem1: 
flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> 
mtu 1500
lladdr 00:03:ba:2b:47:71
priority: 0
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 10.16.1.30 netmask 0xffe0 broadcast 10.16.1.31
inet6 fe80::203:baff:fe2b:4771%gem1 prefixlen 64 scopeid 0x2
inet6 2001:470:b:6cf::1 prefixlen 64
enc0: flags=0<>
priority: 0
groups: enc
status: active
vlan100: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:03:ba:2b:47:71
description: servers
priority: 0
vlan: 100 parent interface: gem1
groups: vlan
status: active
inet 10.21.1.30 netmask 0xffe0 broadcast 10.21.1.31
inet6 fe80::203:baff:fe2b:4771%vlan100 prefixlen 64 scopeid 0x5
inet6 2001:470:eac8:666::1 prefixlen 64
vlan101: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:03:ba:2b:47:71
description: workstations
priority: 0
vlan: 101 parent interface: gem1
groups: vlan
status: active
inet 10.21.8.254 netmask 0xff80 broadcast 10.21.8.255
inet6 fe80::203:baff:fe2b:4771%vlan101 prefixlen 64 scopeid 0x6
inet6 2001:470:eac8:a::1 prefixlen 64
vlan102: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:03:ba:2b:47:71
description: wireless
priority: 0
vlan: 102 parent interface: gem1
groups: vlan
status: active
inet 10.21.9.254 netmask 0xff80 broadcast 10.21.9.255
inet6 fe80::203:baff:fe2b:4771%vlan102 prefixlen 64 scopeid 0x7
inet6 2001:470:eac8:b::1 prefixlen 64
vlan2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:03:ba:2b:47:71
description: transit
priority: 0
vlan: 2 parent interface: gem1
groups: vlan
status: active
inet 172.21.1.2 netmask 0xfffc broadcast 172.21.1.3
tun0: flags=51<UP,POINTOPOINT,RUNNING> mtu 1500
priority: 0
groups: tun
status: down
inet 10.21.2.1 --> 10.21.2.2 netmask 0xfffc
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
priority: 0
groups: gif egress
tunnel: inet 96.54.13.103 -> 216.218.226.238
inet6 fe80::203:baff:fe2b:4770%gif0 ->  prefixlen 64 scopeid 0xa
inet6 2001:470:a:6cf::2 -> 2001:470:a:6cf::1 prefixlen 128
pflow0: flags=41<UP,RUNNING> mtu 1492
priority: 0
pflow: sender: 127.0.0.1 receiver: 127.0.0.1:9995 version: 5
groups: pflow
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33144
priority: 0
groups: pflog

16:36 ryan@void:~$ systat -b mb
8 usersLoad 0.21 0.25 0.26 Sun Nov  8 16:37:12 2015

IFACE LIVELOCKS  SIZE ALIVE   LWM   HWM   CWM   
System0   25648 129 
 2048241025 
lo0 
gem0 204811 4   12411   
gem1 204812 4   12412   
enc0
vlan100 
vlan101 
vlan102 
vlan2   
tun0
gif0
pflow0      
pflog0  

> 
&

Re: [Fwd: HTTP2 script problem]

2013-06-22 Thread Ryan Freeman
On Sat, Jun 22, 2013 at 07:00:09PM +0200, Max Power wrote:
 Hi guys!
 
 OpenBSD 5.3/amd64:
 
 pkg_add apache-httpd [ok.]
 
 next step
 /etc/rc.d/httpd2 start
 returns:
 httpd2(failed)
 
 Instead
 /usr/local/sbin/apachectl2 start
 It works and load Apache2.
 
 Why?

Because you keep wasting time emailing a technical list for
improvements and patches, VERY SPECIFICALLY NOTED on the page where
this address resides.

If you spent any time at all reading manual pages, you would have all
the questions you have asked answered.  STOP POSTING THESE QUESTIONS
TO THIS LIST.  m...@openbsd.org is the ONLY list you should be posting
to, based on all the questions I have seen from you so far.

-ryan

 
 Thanks, Max Power.
 
 
 
 
 



Re: vga diff for testing

2013-03-03 Thread Ryan Freeman
On Sun, Mar 03, 2013 at 10:39:46PM +0100, Mark Kettenis wrote:
 In order to be able to support a framebuffer console on i386/amd64 I'd
 like to reorder some code such that wsdisaplay(4) attaches to vga(4)
 *after* drm(4).  Since I don't have any hardware with radeondrm(4) I'd
 appreciate it if people with access to such hardware would test the
 diff below.  Just check that your vga text glass console and X still
 work.
 

Hey Mark,

Seems all good here on an i386 with radeondrm(4):

vga1 at pci1 dev 0 function 0 ATI Radeon Mobility X1400 rev 0x00
radeondrm0 at vga1: apic 1 int 16
drm0 at radeondrm0
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)

Both text console and X seem as fine as ever, killed X a couple
times and restarted, plus switched back and forth between X and
console a few times to make sure everything seemed ok.

Cheers,

-ryan

 Thanks,
 
 Mark
 
 
 Index: vga_pci.c
 ===
 RCS file: /cvs/src/sys/dev/pci/vga_pci.c,v
 retrieving revision 1.69
 diff -u -p -r1.69 vga_pci.c
 --- vga_pci.c 8 Oct 2012 21:47:50 -   1.69
 +++ vga_pci.c 3 Mar 2013 21:34:59 -
 @@ -249,8 +249,6 @@ vga_pci_attach(struct device *parent, st
   }
  #endif
   printf(\n);
 - sc-sc_vc = vga_common_attach(self, pa-pa_iot, pa-pa_memt,
 - WSDISPLAY_TYPE_PCIVGA);
  
   vga_pci_bar_init(sc, pa);
  
 @@ -294,6 +292,9 @@ vga_pci_attach(struct device *parent, st
  #if NDRM  0
   config_found_sm(self, aux, NULL, drmsubmatch);
  #endif
 +
 + sc-sc_vc = vga_common_attach(self, pa-pa_iot, pa-pa_memt,
 + WSDISPLAY_TYPE_PCIVGA);
  }
  
  int
 



Re: Security and ignorance from the major ISPs

2013-02-14 Thread Ryan Freeman
On Thu, Feb 14, 2013 at 04:20:30PM -0700, Daniel Bertrand wrote:
 Hello,
 
 Thanks for providing such great software. It really is much appreciated.
 
 I was wondering what your stance is about the constant hack attempts on 
 machines on our ISP networks..
 
 I see CONSTANT scanning for ports from all over the world, mostly from Italy, 
 Russia, and China.

yeah i see this daily.  doesn't matter, they never get anywhere.

 Every firewall/router product that I have purchased has been compromised so 
 far.
 
 Is there really a secure, trustworthy adaptive filtering firewall 
 configuration for each OS configuration out there?
 

learning the pf ruleset and configuring to your needs seems to work
pretty well.

 Most people who are on the net are completely oblivious and helpless when it 
 comes to this constant trolling for access, they have no idea what to do to 
 secure their machines.
 
 Shaw has neglected me and left me for dead when I ask for better control and 
 protection from malicious attackers.

you want the isp selectively blocking traffic for you?  i don't.

 What do I do to make sure I don't spend money on new hardware but get a PF 
 configuration that I can trust besides block in all?
 
 Are there published rulesets for Mac/Windows etc. that we can just drop into 
 our pf.conf and /etc/pf.anchors/ directory?

it sounds like you just want a magic working result from no real effort.
maybe thats why your purchased firewalls didn't work out, you bought them,
drop them in and expect it to just take care of issues regardless of
user activity?  shrug, sounds like a case of i don't want to do the work
but i'm sure someone else does it for me, not really gonna get anywhere.

 
 Regards,
 
 Dan
 



Re: For the moment resending

2013-02-09 Thread Ryan Freeman
On Fri, Feb 08, 2013 at 12:03:42PM -0500, Vladimir Támara Patiño wrote:
 Thanks to Stefan and Martin for encouragment, I will find time to apply
 in current following your suggestions, but I cannot so soon.   Sorry
 for mangling of previous, if someone wants to try before, I'm
 sending again but everything in a compressed file (had problems with
 cvsdo).

What is this for?  Nothing in this mail nor the attachment name lend a
clue as to what this is, easier for people to test when it says something
relevant in the subject and message body.

Cheers,

-ryan


 
 -- 
 Dios, gracias por tu amor infinito.
 --   Vladimir Támara Patiño.  http://vtamara.pasosdeJesus.org/
  http://www.pasosdejesus.org/dominio_publico_colombia.html
 




Re: Add PCI id for D-Link DGE-530T C1 to re(4)

2012-09-19 Thread Ryan Freeman
On Fri, Aug 10, 2012 at 04:37:43AM -0400, Brad Smith wrote:
 Add support to re(4) for the D-Link DGE-530T C1 adapter.

I swore I already searched the archives for this, yet
here it is in my own damn inbox.

I submitted a similar patch recently, presently going
through some multicast tests. 

There are some additional lines you added though, so
I may be smart to yield to your diff when everything
looks okay?

cheers,

-ryan

 Index: sys/dev/pci/if_re_pci.c
 ===
 RCS file: /home/cvs/src/sys/dev/pci/if_re_pci.c,v
 retrieving revision 1.34
 diff -u -p -r1.34 if_re_pci.c
 --- sys/dev/pci/if_re_pci.c   9 Jun 2011 19:34:42 -   1.34
 +++ sys/dev/pci/if_re_pci.c   26 Sep 2011 23:26:58 -
 @@ -66,14 +66,15 @@ struct re_pci_softc {
  };
  
  const struct pci_matchid re_pci_devices[] = {
 + { PCI_VENDOR_COREGA, PCI_PRODUCT_COREGA_CGLAPCIGT },
 + { PCI_VENDOR_DLINK, PCI_PRODUCT_DLINK_DGE528T },
 + { PCI_VENDOR_DLINK, PCI_PRODUCT_DLINK_DGE530T_C1 },
   { PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8101E },
   { PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8168 },
   { PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8169 },
   { PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8169SC },
 - { PCI_VENDOR_COREGA, PCI_PRODUCT_COREGA_CGLAPCIGT },
 - { PCI_VENDOR_DLINK, PCI_PRODUCT_DLINK_DGE528T },
 - { PCI_VENDOR_USR2, PCI_PRODUCT_USR2_USR997902 },
 - { PCI_VENDOR_TTTECH, PCI_PRODUCT_TTTECH_MC322 }
 + { PCI_VENDOR_TTTECH, PCI_PRODUCT_TTTECH_MC322 },
 + { PCI_VENDOR_USR2, PCI_PRODUCT_USR2_USR997902 }
  };
  
  #define RE_LINKSYS_EG1032_SUBID 0x00241737
 Index: share/man/man4/re.4
 ===
 RCS file: /home/cvs/src/share/man/man4/re.4,v
 retrieving revision 1.47
 diff -u -p -r1.47 re.4
 --- share/man/man4/re.4   13 Mar 2011 21:32:29 -  1.47
 +++ share/man/man4/re.4   26 Sep 2011 23:24:28 -
 @@ -63,6 +63,8 @@ Corega CG-LAPCIGT (8169S)
  .It
  D-Link DGE-528T (8169S)
  .It
 +D-Link DGE-530T C1 (8169)
 +.It
  D-Link DGE-660TD (8169/8110SB)
  .It
  Gigabyte 7N400 Pro2 Integrated Gigabit Ethernet (8110S)
 
 -- 
 This message has been scanned for viruses and
 dangerous content by MailScanner, and is
 believed to be clean.



Support for D-Link DGE-530T C1

2012-09-13 Thread Ryan Freeman
Hey tech@,

I think I found some low-hanging fruit, the following diff works
for my friend that recently purchased the DGE-530T at my recommendation
only to find out its no-longer supported by the sk driver as of the C1
revision, they changed the chip entirely to realtek 8169.

I found the relevant info already existing in pcidevs.h and
pcidevs_data.h.  The following diff adds the card to re(4).

Note that I used 5.1's release to do this as its what he was
running the diff below is for -current (though it pretty much
looks like nothing has changed there between 5.1 and now)

any tips or hints are welcome

ifconfig output and dmesg from friends machine in question showing
a now-working card attached :)


Index: sys/dev/pci/if_re_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_re_pci.c,v
retrieving revision 1.34
diff -u -p -u -p -r1.34 if_re_pci.c
--- sys/dev/pci/if_re_pci.c 9 Jun 2011 19:34:42 -   1.34
+++ sys/dev/pci/if_re_pci.c 13 Sep 2012 18:14:12 -
@@ -72,6 +72,7 @@ const struct pci_matchid re_pci_devices[
{ PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8169SC },
{ PCI_VENDOR_COREGA, PCI_PRODUCT_COREGA_CGLAPCIGT },
{ PCI_VENDOR_DLINK, PCI_PRODUCT_DLINK_DGE528T },
+   { PCI_VENDOR_DLINK, PCI_PRODUCT_DLINK_DGE530T_C1 },
{ PCI_VENDOR_USR2, PCI_PRODUCT_USR2_USR997902 },
{ PCI_VENDOR_TTTECH, PCI_PRODUCT_TTTECH_MC322 }
 };
IFCONFIG

lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33196
priority: 0
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet 127.0.0.1 netmask 0xff00
fxp0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
lladdr 00:03:47:d2:47:a8
priority: 0
media: Ethernet autoselect (none)
status: no carrier
sk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:24:01:00:2d:f5
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet6 fe80::224:1ff:fe00:2df5%sk0 prefixlen 64 scopeid 0x2
inet 192.168.0.14 netmask 0xff00 broadcast 192.168.0.255
re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 28:10:7b:c9:5d:b1
priority: 0
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 10.0.0.1 netmask 0xff00 broadcast 10.255.255.255
inet6 fe80::2a10:7bff:fec9:5db1%re0 prefixlen 64 scopeid 0x3
enc0: flags=0
priority: 0
groups: enc
status: active
pflog0: flags=141UP,RUNNING,PROMISC mtu 33196
priority: 0
groups: pflog


DMESG before:

OpenBSD 5.1 (GENERIC.MP) #188: Sun Feb 12 09:55:11 MST 2012
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz (GenuineIntel 686-class) 1.40 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID,xTPR
real mem  = 2146758656 (2047MB)
avail mem = 2101518336 (2004MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/31/01, BIOS32 rev. 0 @ 0xfda74, SMBIOS 
rev. 2.3 @ 0xf0fd0 (57 entries)
bios0: vendor Intel Corp. version PT84510A.15A.0003.P01.0110311619 date 
10/31/2001
bios0: Gateway E-3600
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC SSDT
acpi0: wakeup devices PBTN(S4) PCI1(S4) UAR1(S4) USB_(S3) USB2(S3) AC9_(S4) 
SMB_(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Pentium(R) 4 CPU 2.80GHz (GenuineIntel 686-class) 1.40 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID,xTPR
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PCI1)
acpicpu0 at acpi0
acpicpu1 at acpi0
acpipwrres0 at acpi0: FDDP
acpipwrres1 at acpi0: URP1
acpipwrres2 at acpi0: URP2
acpipwrres3 at acpi0: LPTP
acpibtn0 at acpi0: PBTN
bios0: ROM list: 0xc/0xa800 0xca800/0x1000 0xcb800/0x1000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82845 Host rev 0x04
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xf800, size 0x400
ppb0 at pci0 dev 1 function 0 Intel 82845 AGP rev 0x04
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 NVIDIA GeForce2 MX 100 rev 0xb2
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb1 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0x05
pci2 at ppb1 bus 2
fxp0 at pci2 dev 8 function 0 Intel 82562 rev 

Re: Support for D-Link DGE-530T C1

2012-09-13 Thread Ryan Freeman
On Thu, Sep 13, 2012 at 11:53:01AM -0700, Ryan Freeman wrote:
 Hey tech@,
 
 I think I found some low-hanging fruit, the following diff works
 for my friend that recently purchased the DGE-530T at my recommendation
 only to find out its no-longer supported by the sk driver as of the C1
 revision, they changed the chip entirely to realtek 8169.
 
 I found the relevant info already existing in pcidevs.h and
 pcidevs_data.h.  The following diff adds the card to re(4).
 
 Note that I used 5.1's release to do this as its what he was
 running the diff below is for -current (though it pretty much
 looks like nothing has changed there between 5.1 and now)
 
 any tips or hints are welcome
 
 ifconfig output and dmesg from friends machine in question showing
 a now-working card attached :)

I have updated the diff to include a man-page update as well.

Also, per sthen@, I have requested a multicast test with his
instructions.  I will post the results as soon as I have them.

-ryan


Index: sys/dev/pci/if_re_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_re_pci.c,v
retrieving revision 1.34
diff -u -p -u -p -r1.34 if_re_pci.c
--- sys/dev/pci/if_re_pci.c 9 Jun 2011 19:34:42 -   1.34
+++ sys/dev/pci/if_re_pci.c 13 Sep 2012 23:20:29 -
@@ -72,6 +72,7 @@ const struct pci_matchid re_pci_devices[
{ PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8169SC },
{ PCI_VENDOR_COREGA, PCI_PRODUCT_COREGA_CGLAPCIGT },
{ PCI_VENDOR_DLINK, PCI_PRODUCT_DLINK_DGE528T },
+   { PCI_VENDOR_DLINK, PCI_PRODUCT_DLINK_DGE530T_C1 },
{ PCI_VENDOR_USR2, PCI_PRODUCT_USR2_USR997902 },
{ PCI_VENDOR_TTTECH, PCI_PRODUCT_TTTECH_MC322 }
 };
Index: share/man/man4/re.4
===
RCS file: /cvs/src/share/man/man4/re.4,v
retrieving revision 1.47
diff -u -p -u -p -r1.47 re.4
--- share/man/man4/re.4 13 Mar 2011 21:32:29 -  1.47
+++ share/man/man4/re.4 13 Sep 2012 23:20:29 -
@@ -63,6 +63,8 @@ Corega CG-LAPCIGT (8169S)
 .It
 D-Link DGE-528T (8169S)
 .It
+D-Link DGE-530T C1 (8169/8110SB)
+.It
 D-Link DGE-660TD (8169/8110SB)
 .It
 Gigabyte 7N400 Pro2 Integrated Gigabit Ethernet (8110S)



Re: vmmap replacement -- please test

2012-03-01 Thread Ryan Freeman
On Sat, Feb 18, 2012 at 05:09:02PM +0100, Ariane van der Steldt wrote:
 Hi,
 
 Just to prove my point that vmmap testing is still relevant: today a bug
 got found and fixed, where grepping a 1.7GB file on i386 tripped an
 assertion (I love assertions).
 
 This brings the latest versions to:
 http://www.stack.nl/~ariane/vmmap_sys.diff.65
   (apply against /usr/src/sys)
 http://www.stack.nl/~ariane/vmmap_userland.diff.30
   (apply against /usr/src)
 
 Testing is still welcome. :)

applied these to my i386-current checkout of today, system very
responsive.

so far very good!

-ryan