anyone running the ofed code

[Vijay Singh]

Apologies for the cross post. Were trying out the ofed code and running
into some issues, so would love to discuss.

-vijay
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

vmspace_fork()

[Vijay Singh]

Hackers, what does hitting the following assert in vmspace_fork() imply?

 3101 
new_map = &vm2 ->vm_map
;
 3102 
locked  =
vm_map_trylock (new_map);
*/* trylock to silence WITNESS */*
 3103 
KASSERT (locked
, (*"vmspace_fork: lock
failed"*));

I am hitting the assert in line 3103 and it seems like the assumption
is that the trylock will

always get the lock?

-vijay
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

copyinstr()

[Vijay Singh]

Hi, I was looking for some help with copyinstr() on an amd64 platform.

My from address happens to be in the kernel (stack). I am getting an
EFAULT, and I am wondering how to fix that.

Would using memory from malloc() make a difference?

-vijay
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

KVERIFY for non-debug invariants?

[Vijay Singh]

All. KASSERT() is a really need way of expressing invariants when
INVARIANTS is defined. However for regular, non-INVARIANTS code folks
have the typical if() panic() combos, or private macros. Would a
KVERIFY() that does this in non-INVARIANTS code make sense?

-vijay
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

vm info from a hung system

[Vijay Singh]

Need some expert help. I have a system that is hung hard, and I was
able to get it into gdb. From show_vmstat I see:

(kgdb-amd64-7.4-95) show_vmstat
SYSTEM MEMORY INFORMATION:
mem_wire: 285970432 (272MB) Wired: disabled for paging out
mem_active:  +400105472 (381MB) Active: recently referenced
mem_inactive:+ 56840192 ( 54MB) Inactive: recently not referenced
mem_cache:   +0 (  0MB) Cached: almost avail. for allocation
mem_free:+0 (  0MB) Free: fully available for allocation
mem_gap_vm:  +   753664 (  0MB) Memory gap: vm
--  --- --
mem_all: =743669760 (709MB) Total real memory managed
mem_gap_sys: + 22765568 ( 21MB) Memory gap: system
--  ---
mem_phys:=766435328 (730MB) Total phys memory
--  ---

SYSTEM MEMORY SUMMARY:
mem_used: 709595136 (676MB)  Used memory
mem_avail:   + 56840192 ( 54MB) Available memory
--  --- --
mem_total:   =766435328 (730MB) Total memory

What is this telling me?

-vijay
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

USB issue on 8.2

[Vijay Singh]

Hi hackers. I am seeing an issue where the USB controller is
generating a large number of interrupts.

last pid:  6639;  load averages:  1.39,  1.48,  2.46  up 0+01:07:1412:35:05
2590 processes:9 running, 462 sleeping, 3 zombie, 2116 waiting
CPU:  0.2% user,  0.0% nice, 11.5% system, 10.6% interrupt, 77.7% idle
Mem: 277M Active, 425M Inact, 241M Wired, 2704K Cache, 7488K Buf, 1017M Free
Swap: 1024M Total, 1024M Free

  PID USERNAME PRI NICE   SIZERES STATE   C   TIME   WCPU COMMAND
   10 root 171 ki31 0K64K RUN 3  34:37 89.40% {idle: cpu3}
   10 root 171 ki31 0K64K CPU22  33:56 85.94% {idle: cpu2}
   10 root 171 ki31 0K64K CPU00  37:20 76.27% {idle: cpu0}
   10 root 171 ki31 0K64K RUN 1  25:09 55.27% {idle: cpu1}
   11 root -64- 0K   480K WAIT1  14:40 33.40% {irq16: ehci1}

interrupt  total   rate
irq16: ehci1   488177801 114166

Is this known? Any patches I can test?

-vijay
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Panic in 8.1 in softclock(): mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185

[Vijay Singh]

> Out of curiosity, where does your code comes from ? The same snippet
> from the  `release/8.1.0' branch does not refer to `Giant' at all, it
> only reads:
>
>               if (c_lock != NULL) {
>                       class->lc_lock(c_lock, sharedlock);

Arnaud, I added that code to track down the issue. I was originally
hitting the panic much later after the callout had been executed.

-vijay
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Panic in 8.1 in softclock(): mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185

[Vijay Singh]

Hi John,

>> (kgdb-amd64-6.8-71) f 5
>> #5  0x803b73e6 in softclock (arg=0x80c90f40) at
>> ../../../../sys/kern/kern_timeout.c:461
>> 461                                           class->lc_unlock(c_lock);
>> (kgdb-amd64-6.8-71) l
>> 456                                           lastfunc = c_func;
>> 457                                   }
>> 458   #endif
>> 459                                   CTR1(KTR_CALLOUT, "callout %p 
>> finished", c);
>> 460                                   if ((c_flags & CALLOUT_RETURNUNLOCKED) 
>> == 0)
>> 461                                           class->lc_unlock(c_lock);
>> 462                           skip:
>> 463                                   CC_LOCK(cc);
>> 464                                   /*
>> 465                                    * If the current callout is locally
>> (kgdb-amd64-6.8-71) i local
>> c_func = (void (*)(void *)) 0x8060d550 
>
> You'll need to see if there is a way that this routine can drop the lock.  If
> you can reproduce this panic easily, then perhaps try building with KTR and
> KTR_LOCK traces enabled and use 'show ktr' in ddb to see when this thread
> dropped Giant.

An update. I haven't been able to enable KTR in my environment.
However I found some interesting.

In the code below:
(kgdb-amd64-6.8-48) l
402 if (c_lock != NULL) {
403 if (c_lock == 
&Giant.lock_object) {
404 mtx_lock(&Giant);
405 mtx_assert(&Giant, 
MA_OWNED);
406 } else {
407 class->lc_lock(c_lock, 
sharedlock);
408 }

I hit the assert in line 405. So right after locking Giant, it is
found unlocked!!!

Everytime this hits, I see that kldload is running on the other CPU:

(kgdb-amd64-6.8-48) show_ps_running
CPU ticks pri thread  tid pid
state   VSZ   RSS cmd
  0 2  52 0xff000424c800   1611  TDS_RUNNING
 0K0K [intr]
  1 3  76 0xff0004618400   1000651481 TDS_RUNNING
3808K  760K kldload

Reporting it here to see if someone has seen this before.

-vijay
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Panic in 8.1 in softclock(): mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185

[Vijay Singh]

Hackers. I am hitting a panic on 8.1 in the softclock() code. Anyone seen this?

PANIC  : mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185

(kgdb-amd64-6.8-71) bt
#0  breakpoint () at ./machine/cpufunc.h:64
#1  0x803d8b82 in kdb_enter (why=0x806ca339 "panic",
msg=0x806ca339 "panic") at ../../../../sys/kern/subr_kdb.c:365
#2  0x8039adf0 in panic (fmt=0x806c82d3 "mutex %s not
owned at %s:%d") at ../../../../sys/kern/kern_shutdown.c:950
#3  0x80386b2e in _mtx_assert (m=0x80c8ed40, what=20,
file=0x806c7d18 "../../../../sys/kern/kern_mutex.c", line=185)
at ../../../../sys/kern/kern_mutex.c:827
#4  0x8038528e in unlock_mtx (lock=0x80c8ed40) at
../../../../sys/kern/kern_mutex.c:185
#5  0x803b73e6 in softclock (arg=0x80c90f40) at
../../../../sys/kern/kern_timeout.c:461
#6  0x8036436c in intr_event_execute_handlers
(p=0xff000413a000, ie=0xff000414ad00) at
../../../../sys/kern/kern_intr.c:1244
#7  0x80364443 in ithread_execute_handlers
(p=0xff000413a000, ie=0xff000414ad00) at
../../../../sys/kern/kern_intr.c:1257
#8  0x8036469f in ithread_loop (arg=0xff00021e92e0) at
../../../../sys/kern/kern_intr.c:1342
#9  0x80361d06 in fork_exit (callout=0x80364590
, arg=0xff00021e92e0, frame=0xff80001e7c80) at
../../../../sys/kern/kern_fork.c:892
#10 

(kgdb-amd64-6.8-71) f 5
#5  0x803b73e6 in softclock (arg=0x80c90f40) at
../../../../sys/kern/kern_timeout.c:461
461 class->lc_unlock(c_lock);
(kgdb-amd64-6.8-71) l
456 lastfunc = c_func;
457 }
458 #endif
459 CTR1(KTR_CALLOUT, "callout %p 
finished", c);
460 if ((c_flags & CALLOUT_RETURNUNLOCKED) 
== 0)
461 class->lc_unlock(c_lock);
462 skip:
463 CC_LOCK(cc);
464 /*
465  * If the current callout is locally
(kgdb-amd64-6.8-71) i local
c_func = (void (*)(void *)) 0x8060d550 
c_flags = 7
sharedlock = 1
c_arg = (void *) 0x80f50740
class = (struct lock_class *) 0x807543c0
c_lock = (struct lock_object *) 0x80c8ed40
cc = (struct callout_cpu *) 0x80c90f40
c = (struct callout *) 0xff800010ccc0
bucket = (struct callout_tailq *) 0xff800012f450
curticks = 8811
steps = 0
depth = 2
mpcalls = 1
lockcalls = 0
gcalls = 1
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

about freebsd boot1.S

[vijay singh]

hello all, i am trying to understand the freebsd boot code. i saw that the 
1st stage boot loader relocates itself from 7c00 to 700. why is this done? 
if the run time kernel were to switch to real-mode and transfer control to 
this location (0700) would the 1st stage boot program run again?

for the output below, i used the BIOS debugger and read the 1st sector into 
7c00, and unassebled the text.

:7C1D   cld
:7C1E   xor cx, cx	/* cx = 0 */
:7C20   mov es, cx	/* es = 0 */
:7C22   mov ds, cx	/* ds = 0 */
:7C24   mov ss, cx	/* ss = 0 */
:7C26   mov sp, 7C00	/* set SP to current location */
:7C29   mov si, sp
:7C2B   mov di, 0700	/* DS:SI pair denotes the source string and 
ES:DI pair the destination string 0:7C00 -> 0:700 */
:7C2E   inc ch	/* ch = 1, cx = 100*/
:7C30   repe		/* repeat the movsw instruction cx number of times */
:7C31   movsw	/* moves 200h = 512 bytes from 7C00 to 700*/

please cc me in your reply.
thanks
vijay
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

jump from kernel to loader

[vijay singh]

hello, i have some exposure to the freebsd code, but not extensive. i am 
reading the sys/boot code, and saw that the 3 stage boot process involves a 
jump from the loader to the kernel in the last phase. i was wondering if it 
is possible to engineer the kernel to jump back to the loader in some 
special cases?

kindly cc me as i am not on the list.
br
vijay
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

help with sendfile code

[vijay singh]

Hello hackers. What would be the FreeBSD 2.1
equivalent of the following sendfile code from
uipc_syscalls.c

for (off = uap->offset; ; off += xfsize, sbytes +=
xfsize) {
vm_pindex_t pindex;
vm_offset_t pgoff;

pindex = OFF_TO_IDX(off);
retry_lookup:
/*
 * Calculate the amount to transfer. Not to exceed a
page,
 * the EOF, or the passed in nbytes.
 */
xfsize = obj->un_pager.vnp.vnp_size - off;

I have:

for (off = uap->offset; ; off += xfsize,
sbytes += xfsize) {
vm_offset_t pindex;
vm_offset_t pgoff;
register vn_pager_t vnp = (vn_pager_t)
obj->pager->pg_data;

pindex = OFF_TO_IDX(off);
retry_lookup:
/*
 * Calculate the amount to transfer.
Not to exceed a page,
 * the EOF, or the passed in nbytes.
 */
xfsize = vnp->vnp_size - off;

with OFF_TO_IDX defined as:

#define OFF_TO_IDX(off)
((vm_pindex_t)(((int64_t)(off)) >> PAGE_SHIFT))


However this seems to result in xfsize = 0. Could
someome please point out what I'm doing wrong? Any
help will be greatly appreciated. Kindly CC me.

thanks
vijay

=
Everytime I scream, I'm killing pain.

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kqueue

[vijay singh]

Hi, this is in no way related to the kqueue question asked below but to
event notification mechanisms in general. I was wondering if there is
some paper or design that talks about how such a facility could be
provided in a Unix type kernel. Kqueue is fairly recent, and I dont know
what its requirements are but I'm thinking of providing this for an old
2.x FreeBSD system. Any ideas, pointers or suggestions are appreciated.

vijay

Michel Oosterhof wrote:
> 
> Hello.
> 
> Recently I started looking into kqueue(2), and to get to know the
> interface better I attempted to turn usr.sbin/moused into a kqueue
> program (replacing the main select() loop that reads the mouse
> device).
> 
> Now I thought I understood the interface, I requested a kqueue, but
> as soon as I add an event for monitoring I get an 'Operation not
> permitted' error.  Does anyone know if this is caused because
> kqueue() only supports FFS? The mouse device is on devfs (I'm running
> -CURRENT, btw).
> 
> I've got one more question, actually a fact that surprises me, it
> seems that tail(1) is the only place in the base system that actually
> uses kqueue. Is there a reason for this? I read in most places
> kqueue() is more efficient, scalable, etc. I'm sure code like ftpd
> or other services would benefit. (And i'm sure Apache could use it
> too).
>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message