[9fans] SOEKRIS

[Frederic Bonfanti]

Hi,
Does anybody know what is drivers status regarding latest n/w chipsets on 
Soekris boards?

Is VT6105M for the NET5501 now fully supported?

I am asking this because I have a bunch of them (recent boxes) but could not 
initialize n/w properly under Inferno Native.

So my question is this: if any is relevant, which /ether.c has to be 
ported to Inferno in order to make it happen again?

Thanks

On Monday, February 25, 2008 2:15:11 AM UTC+5:30, (unknown) wrote:

We have used at least 3 of the 4 Ethernet ports concurrently.  The
four Ethernet interfaces are 10/100Mb/s `VIA Technology VT6105M Rhine
III Management Adapters' (PCI vendor id 1106 and device id 3053).
They work fine with the current ethervt6102.c except that it doesn't
seem to initialise them perfectly correctly, and once in a while at
boot time they stop talking; power cycling the machine usually
corrects the problem.

Re: [9fans] SOEKRIS

[David du Colombier]

> Does anybody know what is drivers status regarding latest n/w
> chipsets on Soekris boards?
> 
> Is VT6105M for the NET5501 now fully supported?

I have a Soekris net5501 with eight VT6105M interfaces
and it works fine.

> I am asking this because I have a bunch of them (recent boxes) but
> could not initialize n/w properly under Inferno Native.

I haven't tried Inferno, but they are properly supported on Plan 9.

> So my question is this: if any is relevant, which /ether.c
> has to be ported to Inferno in order to make it happen again?

/sys/src/9/pc/ethervt6105m.c

-- 
David du Colombier

[9fans] The cons file and consolefs

[Andy Elvey]

Hi all -
 I've just been looking at the docs for cons and consolefs. I am just 
**blown away** by how cleanly and elegantly keyboard input is handled in 
Plan 9!  There seems to be *none* of the - um - "less than optimal", to 
put it mildly - approach of Linux, with its termios and friends.

There doesn't even seem to be the need for "readline",as far as I can tell.

I assume it would be extremely difficult (if not impossible) to 
implement this approach to keyboard-handling on Linux - would I be 
correct in saying that? It's a pity, if that's the case.


Anyway, just a bit of praise there for the Plan 9 devs.  :)
- Andy

Re: [9fans] dns

[Kenji Arisawa]

Hello cinap,

I got a one. I hope this a helpful.


ar% cat broken/1345779846.41356
name=dns
/proc/41356/text:386 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/386
acid: abort()+0x0 /sys/src/libc/9sys/abort.c:6
ppanic(p=0x3975c,fmt=0x394ec)+0x146 /sys/src/libc/port/malloc.c:166
pv=0x3e820
msg=0x3f804
v=0xdfffc800
n=0x2c
D2B(p=0x3975c,v=0x497f8)+0x5a /sys/src/libc/port/pool.c:968
a=0x497f0
poolfreel(v=0x497f8,p=0x3975c)+0x20 /sys/src/libc/port/pool.c:1192
ab=0x3e820
poolfree(p=0x3975c,v=0x497f8)+0x41 /sys/src/libc/port/pool.c:1327
free(v=0x49800)+0x23 /sys/src/libc/port/malloc.c:250
mydnsquery(qp=0x88cf0,udppkt=0xc76f0,len=0x2a,medium=0x1)+0x185 
/sys/src/cmd/ndb/dnresolve.c:1032
rv=0xc
domain=0x49800
net=0x74656e2f
conndir=0x74656e2f
nci=0x52b59
belen=0x6e2f000f
xmitquery(qp=0x88cf0,depth=0x1,medium=0x1,inns=0x1,obuf=0xc76f0,len=0x2a)+0x227 
/sys/src/cmd/ndb/dnresolve.c:1114
p=0xc7950
j=0x1
n=0x0
buf=0x1b59c4c3
tcpquery(qp=0x88cf0,waitms=0x63f,obuf=0xc76f0,ibuf=0xa7530,depth=0x1,inns=0x1,len=0x2a,req=0x1d85,mp=0xdfffc9b4)+0xea
 /sys/src/cmd/ndb/dnresolve.c:1353
rv=0x0
endms=0x56ba1ef1
queryns(qp=0x88cf0,obuf=0xc76f0,depth=0x1,inns=0x1,waitms=0x63f,ibuf=0xa7530)+0x4d3
 /sys/src/cmd/ndb/dnresolve.c:1428
req=0xa9961d85
len=0x2a
dest=0xc7950
p=0xc7c30
ndest=0x1
endms=0x56ba1dcc
replywaits=0x0
buf=0x9dfa996
m=0x1d85
srcip=0xdfffca18
rv=0x9dfa996
udpquery(mntpt=0x3f0e0,qp=0x88cf0,patient=0x0,depth=0x1,inns=0x1)+0x1b7 
/sys/src/cmd/ndb/dnresolve.c:1578
ibuf=0xa7530
obuf=0xc76f0
fd=0xb
msg=0x6faa
pcntprob=0x3c
reqtm=0x1f40
wait=0x63f
rv=0x87710
netquery(depth=0x1,qp=0x88cf0)+0x2b5 /sys/src/cmd/ndb/dnresolve.c:1660
rv=0x0
dp=0x6d460
qlp=0x6d4fc
lock=0x1
buf=0x3975c
triedin=0x0
inname=0x1
netqueryns(qp=0x88cf0,nsrp=0x876b0,depth=0x1)+0x1e 
/sys/src/cmd/ndb/dnresolve.c:338
rv=0x88ce8
issuequery(class=0x1,qp=0x88cf0,depth=0x0,name=0xdfffce13,recurse=0x0)+0x50 
/sys/src/cmd/ndb/dnresolve.c:359
nsrp=0x876b0
cp=0x88cf0
dbnsrp=0x8558
rp=0x0
dnresolve1(name=0xdfffce13,type=0xf,class=0x1,req=0xdfffcdd8,depth=0x0,recurse=0x0)+0x25c
 /sys/src/cmd/ndb/dnresolve.c:505
dp=0x6d460
rp=0x0
qp=0x88cf0
dnresolve(status=0xdfffcce0,depth=0x0,rooted=0x0,name=0xdfffce13,class=0x1,type=0xf,req=0xdfffcdd8,cn=0x0,recurse=0x0)+0xa8
 /sys/src/cmd/ndb/dnresolve.c:198
procname=0x9cb50
rp=0x0
drp=0x71a98
nrp=0x9cb40
nname=0x48
dp=0xdfffcca8
loops=0x9cb90
lookupqueryold(p=0xdfffce13,mf=0xbac50,req=0xdfffcdd8,rooted=0x0,job=0xba810,errbuf=0xdfffcd0c,wantsav=0x0)+0x70
 /sys/src/cmd/ndb/dns.c:864
status=0x0
rp=0x9cb48
rwrite(job=0xba810,mf=0xbac50,req=0xdfffcdd8)+0x2be /sys/src/cmd/ndb/dns.c:838
err=0x0
cnt=0x1b
send=0x0
errbuf=0x0
atype=0xdfffce2c
io()+0x39e /sys/src/cmd/ndb/dns.c:532
req=0x1
mdata=0x32
n=0x32
job=0xba810
mf=0xbac50
main(argv=0xdfffefb0,argc=0x0)+0x32c /sys/src/cmd/ndb/dns.c:267
ext=0x0
_argc=0x72
_args=0xdfffefc7
servefile=0x642f7323
dir=0x0
kid=0x0
_main+0x31 /sys/src/libc/386/main9.s:16
acid: 
echo kill > /proc/41356/ctl
ar% 

Kenji Arisawa

On 2012/08/21, at 20:27, cinap_len...@gmx.de wrote:

> nothing wrong with diffing the changes and see if theres a clue, but
> to solve this one really needs to find the underlying cause no matter
> what. changes can just hide bugs or make them more or less likely to
> appear. can anyone provide at least a stacktrace or process snapshot
> of the crashed dns processes? from that you try to build a theory of
> what might be going wrong by thinking really really hard... (the
> thinking should be directly proportional to the time it takes to
> reproduce the bug) and then you work on how to prove that theory.
> just changing stuff without knowing what exactly was the problem with
> the old code is sometimes tempting, but wrong and dangerous.
> 
> --
> cinap
>