headers
Tobias Nygren | 1 Apr 2007 15:37
Picon

review/help wanted on envctrl driver

Hi,

I've done some cleanup on my envctrl(sparc64) driver and would like
someone to review it. One thing I'm not happy with right now is how
pcfiic attaches to envctrl.

( Sources at http://netilium.org/~tnn/netbsd-envctrl/ )

1) Should pcf8584.c be moved from dev/i2c to dev/ic or it is fine
   the way I implemented it?
2) In case of (1), should pcfiic attach through autoconf?
3) In case of (2), how should it attach?
 "pcfiic at ebus" doesn't make sense to me as the i2c bus should be
 internal to the envctrl driver. Another option would be
 "pcfiic at envctrl" but I'm not sure how to accomplish this.

Another thing I'm pondering is if fan regulation should be
disabled by default, and whether or not it should be a compile-time
option or a sysctl knob.
Please comment on any bad code and KNF deviations as well.
I'm still investigating how to hook up the interrupts, but this
is not a critical issue.

-Tobias
Permalink | Reply | 2 comments |
headers
Michael Lorenz | 1 Apr 2007 18:43
Picon

Re: review/help wanted on envctrl driver


Hello,

On Apr 1, 2007, at 09:37, Tobias Nygren wrote:

> I've done some cleanup on my envctrl(sparc64) driver and would like
> someone to review it. One thing I'm not happy with right now is how
> pcfiic attaches to envctrl.
>
> ( Sources at http://netilium.org/~tnn/netbsd-envctrl/ )
>
> 1) Should pcf8584.c be moved from dev/i2c to dev/ic or it is fine
>   the way I implemented it?
> 2) In case of (1), should pcfiic attach through autoconf?
> 3) In case of (2), how should it attach?
> "pcfiic at ebus" doesn't make sense to me as the i2c bus should be
> internal to the envctrl driver. Another option would be
> "pcfiic at envctrl" but I'm not sure how to accomplish this.

Why keep the i2c bus private? Is there any chance that other devices 
may be present? Or that the same monitoring chips are used elsewhere? 
In my opinion i2c devices should be machine independent and live in 
dev/i2c.

> Another thing I'm pondering is if fan regulation should be
> disabled by default, and whether or not it should be a compile-time
> option or a sysctl knob.

I'm not sure wether my drivers are good examples ( probably not ) but - 
what would you win by not exposing it? I think until we have something
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jachym Holecek | 2 Apr 2007 01:34
Favicon

Re: review/help wanted on envctrl driver

Hello,

# Tobias Nygren 2007-04-01:
> I've done some cleanup on my envctrl(sparc64) driver and would like
> someone to review it. One thing I'm not happy with right now is how
> pcfiic attaches to envctrl.
> 
> ( Sources at http://netilium.org/~tnn/netbsd-envctrl/ )
> 
> 1) Should pcf8584.c be moved from dev/i2c to dev/ic or it is fine
>   the way I implemented it?

PCF8584 is an I2C controller (not device), so it would belong to dev/ic
or a sparc64-specific place -- depends if it's a commonly used chip or
not.

The PCF8574 and TDA8444 are fairly generic parts (AD/DA converters), so
I'd say they should live under dev/i2c and provide a kernel-only API to
set/get values on the AD/DA channels.

> 2) In case of (1), should pcfiic attach through autoconf?
> 3) In case of (2), how should it attach?
> "pcfiic at ebus" doesn't make sense to me as the i2c bus should be
> internal to the envctrl driver. Another option would be
> "pcfiic at envctrl" but I'm not sure how to accomplish this.

Hmm, hook envctrl (this name seems too generic, BTW) at ebus and use
dev/ic/pc8584.c to give you i2c handle in exchange for bus_space
tag & handle. Then, use the i2c handle to access the AD/DA parts
with dev/i2c/pcf8574.c and dev/i2c/tda8444.c -- still from envctrl
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dennis den Brok | 2 Apr 2007 12:42
Picon

Re: New RTL8168 revision(?)

Another glitch: I've rather often have to reboot because re(4) says: "re0:  
watchdog timeout" to get networking work again. Sometimes it also says  
something about reset not having been completed fully. I'd be glad to test  
possible fixes or hear about a workaround which doesn't require rebooting,  
if anyone can come up with such. This is NetBSD 4.0_BETA2 with re(4) from  
-current (because 4.0 doesn't support RTL8168_SPIN3 as of now).

--

-- 
Dennis den Brok
Permalink | Reply | 501 comments |
headers
Nalin Gupta | 2 Apr 2007 15:45
Picon

UVM / UBC API Need help...

Hello,

I need to allocate buffers pool in kernel, which I can map or attach
to user space process virtual address.  I wish to achieve sort of
zero-copy and later if possible attach a chunk of it to mbuf or socket
buffer to send it across network. (developing sort of logging
mechanism)

I understand UVM / UBC related api may help me.

Am I right ?

Could someone provide me some skeleton code, on how to use those for
jump start ?

regards,
- nalin
Permalink | Reply | 0 comments |
headers
Anil Gopinath | 3 Apr 2007 08:41
Picon
Favicon

LFS ioflush & fdatasync() optimizations


Folks,

I was trying to figure out why, on LFS, ioflush and
fdatasync() are taking more time to complete than
expected and eating up more CPU. 

I was able to narrow down the highest hit operation to
this call in lfs_segment.c

int
lfs_writefile(struct lfs *fs, struct segment *sp,
struct vnode *vp)
{
<snip>
error = VOP_PUTPAGES(vp, 0, 0,
					 PGO_CLEANIT | PGO_ALLPAGES | PGO_LOCKED);
<snip>
}

During fdatasync() operation, the most time is spent
in this function when it is being called by: 

int
lfs_segwrite(struct mount *mp, int flags)
{
<snip>
error = lfs_writevnodes(fs, mp, sp, VN_DIROP);
<snip>
}
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Young | 4 Apr 2007 09:53
Picon
Favicon

kernel diagnostic assertion "p->p_refcnt > 0" failed

I just saw this panic on a NetBSD/evbmips (ADM5120) box, running -current
from just a few weeks ago.  I expect the "out of swap" messages, however,
I do not expect the panic:

UVM: pid 1169 (cron), uid 0 killed: out of swap
UVM: pid 12825 (cron), uid 0 killed: out of swap
UVM: pid 4495 (sh), uid 0 killed: out of swap
UVM: pid 4196 (sh), uid 0 killed: out of swap
UVM: pid 1745 (sh), uid 0 killed: out of swap
UVM: pid 7030 (sed), uid 0 killed: out of swap
UVM: pid 2452 (kill), uid 0 killed: out of swap
UVM: pid 8289 (date), uid 0 killed: out of swap
panic: kernel diagnostic assertion "p->p_refcnt > 0" failed: file
"/u3/dyoung/pristine-nbsd/src/sys/kern/kern_proc.c", line 1432

The box is still in the debugger.  Let me know if there is any information
I can extract to aid the diagnosis before I reboot.  I will reboot about
10 to 12 hours from now.

Dave

--

-- 
David Young             OJC Technologies
dyoung <at> ojctech.com      Urbana, IL * (217) 278-3933
Permalink | Reply | 1 comment |
headers
Matthias Drochner | 4 Apr 2007 17:28
Picon
Picon
Favicon

can't get system dump from DDB anymore


Hi -
just found that this got broken. Whenever I type
"sync" or "reboot 0x100" at the DDB prompt, I get
"panic: assert_sleepable: NULL curlwp".

The stacktrace is:
assert_sleepable
_fstrans_start
ffs_sync
sys_sync
vfs_shutdown
cpu_reboot
db_reboot_cmd

Would be nice if that ability could be restored again.

best regards
Matthias
Permalink | Reply | 17 comments |
headers
Juergen Hannken-Illjes | 4 Apr 2007 18:05
Picon
Picon
Favicon

Re: can't get system dump from DDB anymore

On Wed, Apr 04, 2007 at 05:28:09PM +0200, Matthias Drochner wrote:
> 
> Hi -
> just found that this got broken. Whenever I type
> "sync" or "reboot 0x100" at the DDB prompt, I get
> "panic: assert_sleepable: NULL curlwp".
> 
> The stacktrace is:
> assert_sleepable
> _fstrans_start
> ffs_sync
> sys_sync
> vfs_shutdown
> cpu_reboot
> db_reboot_cmd
> 
> Would be nice if that ability could be restored again.

We could add something like this (from sparc64/machdep.c) to db_reboot_cmd():

 	 */
 	db_recover = 0;
+	if (curlwp == NULL)
+		curlwp = &lwp0;
 	cpu_reboot((int)bootflags, NULL);
 }

--

-- 
Juergen Hannken-Illjes - hannken <at> eis.cs.tu-bs.de - TU Braunschweig (Germany)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matthias Drochner | 4 Apr 2007 18:55
Picon
Picon
Favicon

Re: can't get system dump from DDB anymore


hannken <at> eis.cs.tu-bs.de said:
> +	if (curlwp == NULL)
> +		curlwp = &lwp0; 

This gets a bit further. Now I'm getting:
panic: kernel diagnostic assertion "l->l_stat == LSONPROC" failed
in kern_sleepq.c line 220
Stacktrace is:
sleepq_enqueue
sleepq_block
ltsleep
wdc_exec_command
ata_get_params
wd_get_params
wdopen
wdsize
dumpsys

The code shouldn't even try to sleep...

best regards
Matthias
Permalink | Reply | 0 comments |

Gmane