Re: CAM disk I/O starvation
On Wed, Apr 4, 2012 at 8:22 PM, Alexander Leidinger alexan...@leidinger.net
wrote:
This looks fair if all your disks are working at the same time (e.g.
RAID only setup), but if you have a setup where you have multiple
disks and only one is doing something, you limit the amount of tags
which can be used. No idea what kind of performance impact this would
have.
I haven't seen any performance impact. da1, the one the used to stall
consistenly get over 600MB/s.
What about the case where you have more disks than tags?
This part of the patch takes care of that scenario:
@@ -998,6 +1003,24 @@ xpt_add_periph(struct cam_periph *periph
mtx_lock(xsoftc.xpt_topo_lock);
xsoftc.xpt_generation++;
+
+ if (device != NULL device-sim-dev_count 1
+(device-sim-max_dev_openings device-sim-dev_count)) {
otherwise, we don't split the tags and the original behavior remains.
I also noticed that you do a strncmp for da. What about
ada (available in 9 and 10), I would assume it suffers from the same
problem.
I am running FreeBSD 8.1, no ada. Me presenting a patch is just a way to
draw
attention on a problem and it improves things on my setup. There is
certainly a way to make it more general/inclusive.
Jerry
___
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: CAM disk I/O starvation
On 4/3/12, Gary Jennejohn gljennj...@googlemail.com wrote:
It would be interesting to see your patch. I always run HEAD but maybe
I could use it as a base for my own mods/tests.
Here is the patch
diff -rup cam/cam_sim.c cam/cam_sim.c
--- cam/cam_sim.c 2010-06-13 19:09:06.0 -0700
+++ cam/cam_sim.c 2012-03-19 13:05:10.0 -0700
@@ -87,6 +87,7 @@ cam_sim_alloc(sim_action_func sim_action
sim-refcount = 1;
sim-devq = queue;
sim-max_ccbs = 8; /* Reserve for management purposes. */
+ sim-dev_count = 0;
sim-mtx = mtx;
if (mtx == Giant) {
sim-flags |= 0;
diff -rup cam/cam_sim.h cam/cam_sim.h
--- cam/cam_sim.h 2010-06-13 19:09:06.0 -0700
+++ cam/cam_sim.h 2012-03-19 15:34:17.0 -0700
@@ -118,6 +118,8 @@ struct cam_sim {
u_int max_ccbs;
/* Current count of allocated ccbs */
u_int ccb_count;
+ /* Number of peripheral drivers mapped to this sim */
+ u_int dev_count;
};
diff -rup cam/cam_xpt.c cam/cam_xpt.c
--- cam/cam_xpt.c 2010-06-13 19:09:06.0 -0700
+++ cam/cam_xpt.c 2012-03-29 11:41:51.0 -0700
@@ -303,7 +303,7 @@ xpt_schedule_dev_allocq(struct cam_eb *b
int retval;
if ((dev-drvq.entries 0)
- (dev-ccbq.devq_openings 0)
+ (dev-runs_token dev-ccbq.queue.array_size)
(cam_ccbq_frozen(dev-ccbq, CAM_PRIORITY_TO_RL(
CAMQ_GET_PRIO(dev-drvq))) == 0)) {
/*
@@ -327,7 +327,7 @@ xpt_schedule_dev_sendq(struct cam_eb *bu
int retval;
if ((dev-ccbq.queue.entries 0)
- (dev-ccbq.dev_openings 0)
+ (dev-runs_token dev-ccbq.queue.array_size)
(cam_ccbq_frozen_top(dev-ccbq) == 0)) {
/*
* The priority of a device waiting for controller
@@ -973,6 +973,9 @@ xpt_add_periph(struct cam_periph *periph
struct cam_ed *device;
int32_t status;
struct periph_list *periph_head;
+ struct cam_eb *bus;
+ struct cam_et *target;
+ struct cam_ed *devptr;
mtx_assert(periph-sim-mtx, MA_OWNED);
@@ -991,6 +994,8 @@ xpt_add_periph(struct cam_periph *periph
status = camq_resize(device-drvq,
device-drvq.array_size + 1);
+ if (periph-periph_name != NULL
strncmp(periph-periph_name, da,2) ==0 )
+ device-sim-dev_count++;
device-generation++;
SLIST_INSERT_HEAD(periph_head, periph, periph_links);
@@ -998,6 +1003,24 @@ xpt_add_periph(struct cam_periph *periph
mtx_lock(xsoftc.xpt_topo_lock);
xsoftc.xpt_generation++;
+
+ if (device != NULL device-sim-dev_count 1
+(device-sim-max_dev_openings device-sim-dev_count)) {
+ TAILQ_FOREACH(bus, xsoftc.xpt_busses, links) {
+ if (bus-sim != device-sim)
+ continue;
+ TAILQ_FOREACH(target, bus-et_entries, links) {
+ TAILQ_FOREACH(devptr,
target-ed_entries, links) {
+ /*
+* The number of openings/tags
supported by the sim (i.e controller)
+* is evenly distributed between all
devices that share this sim.
+*/
+ cam_ccbq_resize(devptr-ccbq,
+
(devptr-sim-max_dev_openings/devptr-sim-dev_count));
+}
+}
+}
+}
mtx_unlock(xsoftc.xpt_topo_lock);
return (status);
@@ -3072,6 +3095,11 @@ xpt_run_dev_allocq(struct cam_eb *bus)
}
/* We may have more work. Attempt to reschedule. */
+ device-runs_token++;
+ if (device-runs_token = device-ccbq.queue.array_size) {
+ device-runs_token = 0;
+ break;
+ }
xpt_schedule_dev_allocq(bus, device);
}
devq-alloc_queue.qfrozen_cnt[0]--;
@@ -3139,7 +3167,6 @@ xpt_run_dev_sendq(struct cam_eb *bus)
devq-send_openings--;
devq-send_active++;
- xpt_schedule_dev_sendq(bus, device);
if (work_ccb (work_ccb-ccb_h.flags CAM_DEV_QFREEZE) != 0){
/*
@@ -3170,6 +3197,13 @@ xpt_run_dev_sendq(struct cam_eb *bus)
*/
sim = work_ccb-ccb_h.path-bus-sim;
(*(sim-sim_action))(sim, work_ccb);
+
+ device-runs_token++;
+ if (device-runs_token = device-ccbq.queue.array_size) {
+ device-runs_token = 0;
+ break;
+ }
+ xpt_schedule_dev_sendq(bus, device);
CAM disk I/O starvation
Hello list, I am convinced that there is a bug in the CAM code that leads to I/O starvation. I have already discussed this privately with some. I am now bringing this up to the general audience to get more feedback. My setup is that I have 1 RAID controller with 2 arrays connected to it, da0 and da1. The controller supports 252 tags. After boot up, camcontrol tags on da0 and da1 shows that both devices have 252 openings each. A process P0 writing on da0 is dormant most of the time, but would wake up with burst of I/Os, 5000-6000 ops as reported by gstat. A process P1 writing on da1 has a fixed data rate to da1 as reported by gstat. The issue: When P0 generates that burst of 5000-6000 ops, the write rate of P1 on da1 goes to 0 MB/sec for up to 8-9sec, vfs.hirunningspace starts climbing and we get into waithirunning() or getblk() sleep channel. BTW, raising hirunningspace has no effect on the 0 MB/s behavior. The first problem that I see here, is that if the sim's devq has 252 alloc_queue and send_queue, the struct cam_ed representing da0 and da1 should each have 126 openings and not 252. The second problem is that clearly, there is no I/O fairness in CAM as seen in gstat output and da0 exclusively takes a hold of the sim/controller until it has processed all it's I/Os (8-9 seconds). The code that does this is at cam/cam_xpt.c:3030 3030 (devq-alloc_openings 0) and cam/cam_xpt.c:3091 3091 (devq-send_openings 0) After you've split the openings to 126 each, the tests above will always be true I have a patch and it fixes those problems. I can share it to the list if requested to. da0 and da1 now both automatically get 126 openings and based on that, extra logic implements fairness in cam/cam_xpt.c. No more 0 MB/s on da1. This is on 8.1-RELEASE FreeBSD. Any comments welcome. Thanks, Jerry ___ 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: Giant free GEOM/CAM XPT
On Thu, Jul 22, 2010 at 10:47 PM, Alexander Motin m...@freebsd.org wrote: Giant locked there only if DISKFLAG_NEEDSGIANT flag is set, which da driver is not doing. Alexander, my mistake. I am working on 2 branches at the moment 6.3 and 8.0. I got them all mixed up while going through my trees. 8.0 scsi_da.c doesn't need giant. Jerry ___ 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
Giant free GEOM/CAM XPT
Hello List, while going through the xpt code (8.0 RELEASE), it seems to me that some gains can be had in src/sys/geom/geom_disk.c where dp-d_strategy(bp2) is surrounded by Giant lock. Especially in the case where one has 2+ controllers on the system with /dev/daXX attached to them during heavy I/O. I am currently trying to get rid of giant there, but it branches in sys/cam and sys/dev/twa. Definitely not a trivial exercise. The dependency on Giant seems to come from the XPT code. would be neat if I could just use the SIM lock, which is per controller. Question: do you think it's worth the effort? right now I always get a crash (race condition most likely) in xpt_run_dev_allocq-camq_remove Jerry ___ 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: disk I/O, VFS hirunningspace
On Wed, Jul 14, 2010 at 12:04 AM, Gary Jennejohn gljennj...@googlemail.comwrote: Rather than commenting out the code try setting the sysctl vfs.hirunningspace to various powers-of-two. Default seems to be 1MB. I just changed it on the command line as a test to 2MB. You can do this in /etc/sysctl.conf. thank you all, that did it. The settings that Matt recommended are giving the same numbers I had with the code commented out. I was concerned that the lock or msleep may be a problem. Jerry ___ 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
disk I/O, VFS hirunningspace
Hello List,
I am on 8.0 RELEASE amd64. My system has 2 RAID arrays connected to 2
separate
controllers.
My I/O throughput tests jumped by ~100MB/sec on both channels, when I
commented out the
following piece of code from kern/vfs_bio.c
void
waitrunningbufspace(void)
{
/*
mtx_lock(rbreqlock);
while (runningbufspace hirunningspace) {
++runningbufreq;
msleep(runningbufreq, rbreqlock, PVM, wdrain, 0);
}
mtx_unlock(rbreqlock);
*/
}
so far, I can't observe any side effects of not running it. Am I on a time
bomb?
Thank you,
Jerry
___
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
crash at in_pcb.c
Hello List,
I can realiably reproduce this crash. We have a deamon that accept several
connections
per sec. We use iperf and Microsoft Web application stress 1.0 to push
traffic to the FreeBSD box.
Without further delay, the crash dump is below. I've been troubleshooting,
but I am no longer sure
if this is a race condition or a stack corruption. The socket pointer
between frame 12 and 11 is different.
This is on 6.2, but the code for 7.0 is identical, so I think it still
applies.
Any hint, patching or troubleshooting this is appreciated.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x2aef0210
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0769098
stack pointer = 0x28:0xef781bc0
frame pointer = 0x28:0xef781bd0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1166 (ndaemon)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 8h32m25s
Dumping 3325 MB (3 chunks)
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) l *0xc0769098
0xc0769098 is in in_pcblookup_local (/usr/src/sys/netinet/in_pcb.c:923).
918 /usr/src/sys/netinet/in_pcb.c: No such file or directory.
in /usr/src/sys/netinet/in_pcb.c
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc06c2812 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:412
#2 0xc06c2bbd in panic (fmt=0xc0940872 %s) at
/usr/src/sys/kern/kern_shutdown.c:573
#3 0xc08f3e4e in trap_fatal (frame=0xef781b80, eva=720306704) at
/usr/src/sys/i386/i386/trap.c:838
#4 0xc08f3b57 in trap_pfault (frame=0xef781b80, usermode=0, eva=720306704)
at /usr/src/sys/i386/i386/trap.c:745
#5 0xc08f3745 in trap (frame=
{tf_fs = -277348344, tf_es = 40, tf_ds = -913309656, tf_edi = 6,
tf_esi = 0, tf_ebp = -277341232, tf_isp = -277341268, tf_ebx = -1062683820,
tf_edx = 720306704, tf_ecx = 14063, tf_eax = 720306704, tf_trapno = 12,
tf_err = 0, tf_eip = -1065971560, tf_cs = 32, tf_eflags = 66050, tf_esp = 0,
tf_ss = -1062683820}) at /usr/src/sys/i386/i386/trap.c:435
#6 0xc08dddba in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc0769098 in in_pcblookup_local (pcbinfo=0x2aef0210, laddr={s_addr =
0}, lport_arg=720306704, wild_okay=1)
at /usr/src/sys/netinet/in_pcb.c:923
#8 0xc0768452 in in_pcbbind_setup (inp=0xc97150b4, nam=0x36ef,
laddrp=0xc97150ec, lportp=0xc97150ce, cred=0xc8726780)
at /usr/src/sys/netinet/in_pcb.c:464
#9 0xc0767f56 in in_pcbbind (inp=0xc97150b4, nam=0x2aef0210,
cred=0xc8726780) at /usr/src/sys/netinet/in_pcb.c:240
#10 0xc077f272 in tcp_connect (tp=0xc9897000, nam=0xc98a1ba0, td=0xc990e180)
at /usr/src/sys/netinet/tcp_usrreq.c:864
#11 0xc077e141 in tcp_usr_connect (so=0xc9897000, nam=0xc98a1ba0,
td=0xc990e180)
at /usr/src/sys/netinet/tcp_usrreq.c:369
#12 0xc06fec4e in soconnect (so=0xc97b39bc, nam=0xc98a1ba0, td=0xc990e180)
at /usr/src/sys/kern/uipc_socket.c:558
#13 0xc07046a8 in kern_connect (td=0xc990e180, fd=89, sa=0xc98a1ba0) at
/usr/src/sys/kern/uipc_syscalls.c:536
#14 0xc070460f in connect (td=0xc990e180, uap=0xef781d04) at
/usr/src/sys/kern/uipc_syscalls.c:505
#15 0xc08f4193 in syscall (frame=
{tf_fs = 135725115, tf_es = 59, tf_ds = -1088487365, tf_edi =
135745024, tf_esi = -1089511444, tf_ebp = -1089514536, tf_isp = -277340828,
tf_ebx = 671753396, tf_edx = 0, tf_ecx = 135524256, tf_eax = 98, tf_trapno =
0, tf_err = 2, tf_eip = 674451435, tf_cs = 51, tf_eflags = 642, tf_esp =
-1089514580, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:984
#16 0xc08dde0f in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:200
#17 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) f 7
#7 0xc0769098 in in_pcblookup_local (pcbinfo=0x2aef0210, laddr={s_addr =
0}, lport_arg=720306704, wild_okay=1)
at /usr/src/sys/netinet/in_pcb.c:923
923 in /usr/src/sys/netinet/in_pcb.c
(kgdb) i loc
phd = (struct inpcbport *) 0x2aef0210
tmphd = (struct inpcbport *) 0x2aef0210
match = (struct inpcb *) 0x0
inp = (struct inpcb *) 0x2aef0210
tmpinp = (struct inpcb *) 0x2aef0210
matchwild = 6
wildcard = -1062683820
lport = 14063
(kgdb) p phd
$1 = (struct inpcbport *) 0x2aef0210
(kgdb) p phd-phd_port
Cannot access memory at address 0x2aef021c
(kgdb) f 12
#12 0xc06fec4e in soconnect (so=0xc97b39bc, nam=0xc98a1ba0, td=0xc990e180)
at /usr/src/sys/kern/uipc_socket.c:558
558 /usr/src/sys/kern/uipc_socket.c: No such file or directory.
in /usr/src/sys/kern/uipc_socket.c
(kgdb) p so
$2 = (struct socket *) 0xc97b39bc
(kgdb) p nam
$3 = (struct sockaddr *) 0xc98a1ba0
(kgdb) p td
$4 = (struct thread *) 0xc990e180
(kgdb) l
553 in /usr/src/sys/kern/uipc_socket.c
(kgdb) f 11
#11 0xc077e141 in tcp_usr_connect (so=0xc9897000, nam=0xc98a1ba0,
Re: crash at in_pcb.c
On Wed, Oct 29, 2008 at 2:37 PM, Kip Macy [EMAIL PROTECTED] wrote: The code in 7.0 is actually locked quite differently. Could you please try and reproduce on 7.0 and RELENG_7? ok. I'll keep you posted. Jerry ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
pkg_add on 64bits kernel w/ options MAC
Hi List, I am running into a weird issue. On a 6.2 stable, 32bits built with options MAC, I can run pkg_add of anything. But a 6.2 stable, 64bits built with MAC won't let me do pkg_add. If anybody has an input, please advise. Below is the output on the 64 bits machine: net3# pkg_add test.tbz +CONTENTS: Can't update time for +CONTENTS: Operation not permitted pkg_add: tar extract of /wr/home/webmgr/test.tbz failed! pkg_add: unable to extract table of contents file from '/wr/home/webmgr/test.tbz' - not a package? net3# net3# tar xvf test.tbz x +CONTENTS: Can't update time for +CONTENTS: Operation not permitted x +COMMENT: Can't update time for +COMMENT: Operation not permitted x +DESC: Can't update time for +DESC: Operation not permitted x +DISPLAY: Can't update time for +DISPLAY: Operation not permitted x usr/local/bin/sudo: Can't update time for usr/local/bin/sudo: Operation not permitted x usr/local/man/man8/sudo.8: Can't update time for usr/local/man/man8/sudo.8: Operation not permitted x usr/local/man/man8/visudo.8: Can't update time for usr/local/man/man8/visudo.8: Operation not permitted x usr/local/man/man5/sudoers.5 x usr/local/sbin/visudo: Can't update time for usr/local/sbin/visudo: Operation not permitted x usr/local/libexec/sudo_noexec.so: Can't update time for usr/local/libexec/sudo_noexec.so: Operation not permitted x usr/local/libexec/sudo_noexec.la: Can't update time for usr/local/libexec/ sudo_noexec.la: Operation not permitted x etc/sudoers: Can't update time for etc/sudoers: Operation not permitted net3# uname -a FreeBSD net3 6.2-STABLE FreeBSD 6.2-STABLE #1: Tue Aug 5 15:10:45 PDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYBD[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MPATH-nonsec amd64 thanks, Jerry ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg_add on 64bits kernel w/ options MAC
On Tue, Aug 19, 2008 at 1:26 PM, Robert Watson [EMAIL PROTECTED] wrote: Sounds like a bug of some sort. Could you send the output of sysctl security.mac? Also, if you could use ktrace to confirm which system calls are returning EACCES/EPERM leading to the warnings, that would also be helpful. I will file a PR later on. In the mean time here are the outputs you were looking for: security.mac.max_slots: 4 security.mac.enforce_network: 1 security.mac.enforce_pipe: 1 security.mac.enforce_posix_sem: 1 security.mac.enforce_suid: 1 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.enforce_vm: 1 security.mac.enforce_process: 1 security.mac.enforce_socket: 1 security.mac.enforce_system: 1 security.mac.enforce_kld: 1 security.mac.enforce_sysv_msg: 1 security.mac.enforce_sysv_sem: 1 security.mac.enforce_sysv_shm: 1 security.mac.enforce_fs: 1 bsd64-21# kdump -f ktrace.out 1045 ktrace RET ktrace 0 1045 ktrace CALL execve(0x7fffe720,0x7fffec80,0x7fffec98) 1045 ktrace RET execve -1 errno 2 No such file or directory 1045 ktrace CALL execve(0x7fffe720,0x7fffec80,0x7fffec98) 1045 ktrace RET execve -1 errno 2 No such file or directory 1045 ktrace CALL execve(0x7fffe720,0x7fffec80,0x7fffec98) 1045 pkg_add RET execve 0 1045 pkg_add CALL mmap(0,0x1e40,0x3,0x1000,0x,0,0) 1045 pkg_add RET mmap 5443584/0x800531000 1045 pkg_add CALL munmap(0x800531000,0x1e40) 1045 pkg_add RET munmap 0 1045 pkg_add CALL __sysctl(0x7fffe930,0x2,0x800639180,0x7fffe928,0,0) 1045 pkg_add RET __sysctl 0 1045 pkg_add CALL mmap(0,0x8000,0x3,0x1002,0x,0,0) 1045 pkg_add RET mmap 5443584/0x800531000 1045 pkg_add CALL issetugid 1045 pkg_add RET issetugid 0 1045 pkg_add CALL open(0x80052eff0,0,0x1b6) 1045 pkg_add RET open -1 errno 2 No such file or directory 1045 pkg_add CALL open(0x80052e1a8,0,0) 1045 pkg_add RET open 3 1045 pkg_add CALL read(0x3,0x7fffe8d0,0x80) 1045 pkg_add RET read 128/0x80 1045 pkg_add CALL lseek(0x3,0,0x80,0) 1045 pkg_add RET lseek 128/0x80 1045 pkg_add CALL read(0x3,0x800535000,0x3c) 1045 pkg_add RET read 60/0x3c 1045 pkg_add CALL close(0x3) 1045 pkg_add RET close 0 1045 pkg_add CALL access(0x800536000,0) 1045 pkg_add RET access -1 errno 2 No such file or directory 1045 pkg_add CALL access(0x800536000,0) 1045 pkg_add RET access 0 1045 pkg_add CALL open(0x8005320c0,0,0x800639060) 1045 pkg_add RET open 3 1045 pkg_add CALL fstat(0x3,0x7fffe8e0) 1045 pkg_add RET fstat 0 1045 pkg_add CALL read(0x3,0x800638040,0x1000) 1045 pkg_add RET read 4096/0x1000 1045 pkg_add CALL mmap(0,0x10e000,0x5,0x20002,0x3,0,0) 1045 pkg_add RET mmap 6541312/0x80063d000 1045 pkg_add CALL mprotect(0x800648000,0x1000,0x7) 1045 pkg_add RET mprotect 0 1045 pkg_add CALL mprotect(0x800648000,0x1000,0x5) 1045 pkg_add RET mprotect 0 1045 pkg_add CALL mmap(0x800749000,0x2000,0x3,0x12,0x3,0,0xc000) 1045 pkg_add RET mmap 7639040/0x800749000 1045 pkg_add CALL close(0x3) 1045 pkg_add RET close 0 1045 pkg_add CALL access(0x800536000,0) 1045 pkg_add RET access 0 1045 pkg_add CALL open(0x800532120,0,0x6c) 1045 pkg_add RET open 3 1045 pkg_add CALL fstat(0x3,0x7fffe8e0) 1045 pkg_add RET fstat 0 1045 pkg_add CALL read(0x3,0x800638040,0x1000) 1045 pkg_add RET read 4096/0x1000 1045 pkg_add CALL mmap(0,0x10c000,0x5,0x20002,0x3,0,0) 1045 pkg_add RET mmap 7647232/0x80074b000 1045 pkg_add CALL mprotect(0x800755000,0x1000,0x7) 1045 pkg_add RET mprotect 0 1045 pkg_add CALL mprotect(0x800755000,0x1000,0x5) 1045 pkg_add RET mprotect 0 1045 pkg_add CALL mmap(0x800856000,0x1000,0x3,0x12,0x3,0,0xb000) 1045 pkg_add RET mmap 8740864/0x800856000 1045 pkg_add CALL close(0x3) 1045 pkg_add RET close 0 1045 pkg_add CALL access(0x800536000,0) 1045 pkg_add RET access -1 errno 2 No such file or directory 1045 pkg_add CALL access(0x800536000,0) 1045 pkg_add RET access 0 1045 pkg_add CALL open(0x800532140,0,0x75) 1045 pkg_add RET open 3 1045 pkg_add CALL fstat(0x3,0x7fffe8e0) 1045 pkg_add RET fstat 0 1045 pkg_add CALL read(0x3,0x800638040,0x1000) 1045 pkg_add RET read 4096/0x1000 1045 pkg_add CALL mmap(0,0x138000,0x5,0x20002,0x3,0,0) 1045 pkg_add RET mmap 8744960/0x800857000 1045 pkg_add CALL mprotect(0x800886000,0x1000,0x7) 1045 pkg_add RET mprotect 0 1045 pkg_add CALL mprotect(0x800886000,0x1000,0x5) 1045 pkg_add RET mprotect 0 1045 pkg_add CALL mmap(0x800987000,0x8000,0x3,0x12,0x3,0,0x3) 1045 pkg_add RET mmap 9990144/0x800987000 1045 pkg_add CALL close(0x3) 1045 pkg_add RET close 0 1045 pkg_add CALL access(0x800536000,0) 1045 pkg_add RET access 0 1045 pkg_add CALL
options MAC vs. pkg_add
Hi List, I am running into a weird issue. On a 6.2 stable, 32bits built with options MAC, I can run pkg_add of anything. But a 6.2 stable, 64bits built with MAC won't let me do pkg_add. If anybody has an input, please advise. Below is the output on the 64 bits machine: net3# pkg_add test.tbz +CONTENTS: Can't update time for +CONTENTS: Operation not permitted pkg_add: tar extract of /wr/home/webmgr/test.tbz failed! pkg_add: unable to extract table of contents file from '/wr/home/webmgr/test.tbz' - not a package? net3# net3# tar xvf test.tbz x +CONTENTS: Can't update time for +CONTENTS: Operation not permitted x +COMMENT: Can't update time for +COMMENT: Operation not permitted x +DESC: Can't update time for +DESC: Operation not permitted x +DISPLAY: Can't update time for +DISPLAY: Operation not permitted x usr/local/bin/sudo: Can't update time for usr/local/bin/sudo: Operation not permitted x usr/local/man/man8/sudo.8: Can't update time for usr/local/man/man8/sudo.8: Operation not permitted x usr/local/man/man8/visudo.8: Can't update time for usr/local/man/man8/visudo.8: Operation not permitted x usr/local/man/man5/sudoers.5 x usr/local/sbin/visudo: Can't update time for usr/local/sbin/visudo: Operation not permitted x usr/local/libexec/sudo_noexec.so: Can't update time for usr/local/libexec/sudo_noexec.so: Operation not permitted x usr/local/libexec/sudo_noexec.la: Can't update time for usr/local/libexec/ sudo_noexec.la: Operation not permitted x etc/sudoers: Can't update time for etc/sudoers: Operation not permitted net3# uname -a FreeBSD net3 6.2-STABLE FreeBSD 6.2-STABLE #1: Tue Aug 5 15:10:45 PDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYBD[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MPATH-nonsec amd64 thanks, Jerry ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
encrypted executables
Good afternoon list, anybody knows of a tool to encrypt executables under FreeBSD? may be from the ports? I am not talking about simple file encryption. I found something called 'burneye' but it's for Linux. Thank you all, Jerry ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: encrypted executables
On Feb 18, 2008 5:39 PM, Dimitry Andric [EMAIL PROTECTED] wrote: On 2008-02-19 02:18, Jerry Toung wrote: anybody knows of a tool to encrypt executables under FreeBSD? may be from the ports? I am not talking about simple file encryption. Can you elaborate on what you *are* talking about then? Some security-by-obscurity scheme, perhaps? :) I need to encrypt elf binaries. I'd like to make it harder for the bad guy to reverse engineer my app. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: encrypted executables
On Feb 18, 2008 8:13 PM, Mike Meyer [EMAIL PROTECTED] wrote: Basically the DRM problem (only executing your property under conditions you specify, not under those the end user might want). A *lot* of money has been spent trying to do this, but nobody has done it yet. Some very smart people have concluded it can't be done. That said, you did say harder, not impossible. Making it harder is certainly possible, depending on the conditions. What are they conditions you want this to work under? FWIW, the only thing that in this area is to not let them run the critical parts of your app on their hardware. Put those on your service, exported via the network, and then give the end user a UI that talks to that. thank you all for the feedback. Yep, DRM issues, it doesn't hurt to try. Jerry mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a new syscalls table
Thank you DES. I am running 6.2 by the way. Jerry On 1/26/08, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Jerry Toung [EMAIL PROTECTED] writes: I am trying to create an environment where you can't run my binaries on your box and I can't run your binaries on my system (x86 platform). For that, I have modified the system calls table (i.e everything is offset by 5). This is basically the same as sidegrading from i386 to amd64 or vice versa. If you're using 7 or 8, the installworld target sets aside all the tools it needs to complete the installation, so it doesn't matter that the binaries you install can't run on your current kernel. Just make sure you run installkernel first. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a new syscalls table
Good point. I'll try it. On Jan 25, 2008 3:30 PM, Xin LI [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jerry Toung wrote: Hello list, I am trying to create an environment where you can't run my binaries on your box and I can't run your binaries on my system (x86 platform). For that, I have modified the system calls table (i.e everything is offset by 5). All the files that need to be re-generated, have been. I ran make buildworld then make kernel. I don't run make installworld because it will not complete (modified libc.so.6). So, just before I reboot, I cp my newly built libc.so.6 from /usr/obj/../lib to /lib/. then power off the box. When it comes back, it panics in kern/kern_exit.c with Going nowhere without my init! How can I make this work? Is my initial objective even possible? I think the correct approach would be to have a cpu that no else in the world has, any in between solution.? Maybe you can try make installworld DESTDIR=/another_rootdir and boot from that environment? Cheers, - -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHmnEKi+vbBBjt66ARAq8uAJ9d3yehidPQJI9YPgCyOV8XNHZ2DwCbBKGH AE7ydKQFaj3N/2j2h5XweBU= =SUPR -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
a new syscalls table
Hello list, I am trying to create an environment where you can't run my binaries on your box and I can't run your binaries on my system (x86 platform). For that, I have modified the system calls table (i.e everything is offset by 5). All the files that need to be re-generated, have been. I ran make buildworld then make kernel. I don't run make installworld because it will not complete (modified libc.so.6). So, just before I reboot, I cp my newly built libc.so.6 from /usr/obj/../lib to /lib/. then power off the box. When it comes back, it panics in kern/kern_exit.c with Going nowhere without my init! How can I make this work? Is my initial objective even possible? I think the correct approach would be to have a cpu that no else in the world has, any in between solution.? Thank you for reading, Jerry ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a new syscalls table
Thank you for the feedback Mike. Points well taken. I'll look into the NetBSD thing. Jerry On Jan 25, 2008 3:55 PM, Mike Meyer [EMAIL PROTECTED] wrote: On Fri, 25 Jan 2008 14:51:44 -0800 Jerry Toung [EMAIL PROTECTED] wrote: Hello list, I am trying to create an environment where you can't run my binaries on your box and I can't run your binaries on my system (x86 platform). For that, I have modified the system calls table (i.e everything is offset by 5). [...] When it comes back, it panics in kern/kern_exit.c with Going nowhere without my init! How can I make this work? Treat it like a cross-platform build, and install to a different partition on your disk, then boot that partition. Is my initial objective even possible? I think the correct approach would be to have a cpu that no else in the world has, any in between solution.? Depends on what you mean by correct approach. Basically, it's a security issue. So you almost certainly can't make it mathematically impossible, but you can raise the cost of people running your binaries on their box - and vice versa - pretty much as high as you want, providing you're willing to pay for it. I'm not sure how well fabbing custom silicon would work; it's certainly at the high end of the cost scale, but it can be reverse engineered, and then your custom CPU could be emulated in software for a lot less than it cost you to design the silicon. Of course, you could take that approach yourself to save money. On the other hand, once you realize that it's a security issue, you can start using security tools for this. For instance, the NetBSD executable verification feature does half the job - it won't run their executables on your system. By tweaking it a bit - encrypting as well as signing, for instance - you'd do both halves, with better performance than emulating a new CPU, and a lot less work. Personally, I think that'd also be more useful to the rest of the community than an offset syscall table as well. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: netgraph TTY
Hey Max,
all I can say is thank you. That's a very nice tutorial. I am sure other
people will benefit.
Take care my friend.
Jerry
On Wednesday 30 March 2005 05:22 pm, Maksim Yevmenkin wrote:
Jerry,
draw a picture :) it really helps :) for example
right2left left2right
\ /
[ksocket] --- [tee] [hole]
left right
# ngctl
+ mkpeer hole hook hook -- create ng_hole node
+ name hook hole -- name ng_hole node
+ mkpeer hole: tee right right -- create ng_tee node and connect to hole
+ name hole:right tee -- name ng_tee node
+ mkpeer tee: ksocket left local/stream/0 -- create ksocket node and
connect to tee
+ name tee:left ksocket -- name ksocket node
+ msg ksocket: bind local//tmp/foo -- bind ksocket
+ show tee:
Name: tee Type: tee ID: 0011 Num hooks: 2
Local hook Peer name Peer typePeer ID Peer
hook
-- - ----
-
leftksocket ksocket 0012
local/stream/0
right holehole 0010right
+ show ksocket:
Name: ksocket Type: ksocket ID: 0012 Num hooks: 1
Local hook Peer name Peer typePeer ID Peer
hook
-- - ----
-
local/stream/0 tee tee 0011left
+ show hole:
Name: holeType: holeID: 0010 Num hooks: 2
Local hook Peer name Peer typePeer ID Peer
hook
-- - ----
-
right tee tee 0011right
hookngctl8529 socket 000fhook
now connect nghook(8) to tee:left2right (or you could connect ng_tty
node there), then connect to the unix socket at /tmp/foo and send
something to the socket. you should see output. since we have ng_hole on
the right then right2left will never get any data. if you need to
capture traffic from from right2left then you will need to connect
one2many node to both right2left (to one2many:many0) and
right2left (to one2name:many1) and then connect your tty node to the
one2many:one hook
like so
+ mkpeer tee: one2many left2right many0
+ connect tee: tee:left2right right2left many1
+ show one2many:
Name: one2manyType: one2manyID: 0014 Num hooks: 2
Local hook Peer name Peer typePeer ID Peer
hook
-- - ----
-
many1 tee tee 0011
right2left
many0 tee tee 0011
left2right
+ show tee:
Name: tee Type: tee ID: 0011 Num hooks: 4
Local hook Peer name Peer typePeer ID Peer
hook
-- - ----
-
right2left one2manyone2many 0014many1
left2right one2manyone2many 0014many0
leftksocket ksocket 0012
local/stream/0
right holehole 0010right
hope this helps :)
max
Jerry Toung wrote:
Good afternoon list,
I am still trying to build a simple netgraph using ng_tty. Ultimately I
would like to go from inet-tee-ng_tty(/dev/cuaa0).
Please advise what I am doing wrong as I still see an error message (see
bottom of email). Excuse me for the slighty long thread.
Here is my very simple line discipline code:
int d;
int ldisc;
ldisc = NETGRAPHDISC;
if ((d = open(/dev/cuaa0, O_RDWR)) == -1) {
perror(open);
} else {
printf(descripto # %d\n, d);
if ((ioctl(d, TIOCSETD, ldisc)) == -1) {
perror(ioctl);
}
}
printf(Netgraph TTY node initialized successfully\nPress any key
to destroy it);
getc(stdin);
close(d);
exit;
mrcrab# gcc -g netgraph.c -o test
mrcrab# ./test
descripto # 3
Netgraph TTY node initialized successfully
Press any key to destroy it
+ list
There are 2 total nodes:
Name: ngctl27022 Type: socket ID: 000a Num hooks: 0
Name: tty1Type: tty ID: 0008 Num hooks: 0
+ mpeer . tee myhook right
ngctl: mpeer: unknown command
+ mkpeer . tee myhook right
+ name .:myhook mytee
+ mkpeer mytee: tty left hook
ngctl: send msg: Operation not permitted
+
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
[EMAIL PROTECTED
Re: netgraph TTY
only if you can answer this: Is there another Luke Skywalker? :-) On Wednesday 30 March 2005 07:21 pm, Maksim Yevmenkin wrote: Jerry Toung wrote: Hey Max, all I can say is thank you. That's a very nice tutorial. I am sure other people will benefit. so, did i get job at nasa? :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
netgraph TTY
Good afternoon list,
I am still trying to build a simple netgraph using ng_tty. Ultimately I would
like to go from inet-tee-ng_tty(/dev/cuaa0).
Please advise what I am doing wrong as I still see an error message (see
bottom of email). Excuse me for the slighty long thread.
Here is my very simple line discipline code:
int d;
int ldisc;
ldisc = NETGRAPHDISC;
if ((d = open(/dev/cuaa0, O_RDWR)) == -1) {
perror(open);
} else {
printf(descripto # %d\n, d);
if ((ioctl(d, TIOCSETD, ldisc)) == -1) {
perror(ioctl);
}
}
printf(Netgraph TTY node initialized successfully\nPress any key to
destroy it);
getc(stdin);
close(d);
exit;
mrcrab# gcc -g netgraph.c -o test
mrcrab# ./test
descripto # 3
Netgraph TTY node initialized successfully
Press any key to destroy it
+ list
There are 2 total nodes:
Name: ngctl27022 Type: socket ID: 000a Num hooks: 0
Name: tty1Type: tty ID: 0008 Num hooks: 0
+ mpeer . tee myhook right
ngctl: mpeer: unknown command
+ mkpeer . tee myhook right
+ name .:myhook mytee
+ mkpeer mytee: tty left hook
ngctl: send msg: Operation not permitted
+
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
ng_tty problem
Hello List, I want to monitor traffic on serial port /dev/cuaa0. I am trying to build the following netgraph. socket --- tee node --- tty node I run ngctl manually with the error message below: + mkpeer . tee hook1 left + name .:hook1 mytee + mkpeer mytee: tty right hook ngctl : send msg: Operation not permitted Why is this? Although kldstat -v shows ng_socket.ko, ng_tty.ko and ng_tee.ko + list command only shows socket and tee nodes. What is the righ way of using ng_tty? Thank you in advance. Jerry ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
send data to serial port from kernel code
Good afternoon list, I am looking for a way to write data to the serial interface (/dev/cuaa0) from a kernel module and also read /dev/ttyd0 still from that same kernel module. Any pointers to doing that will be great. I want on exchange IP traffic from FreeBSD to another host with different OS via serial cable (null modem). So instead of making a call the NIC driver, I want to use the serial port as may physical layer. Any other ideas for doing this is welcome as well. I know the basics of serial programming from a regular C application: #include termios.h fd = open(/dev/cuaa0, O_RDWR|O_NDELAY) tcsetattr and tcgetattr etc etc. but that's not what I am looking for. Thank you. Jerry ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: send data to serial port from kernel code
Because all my IP traffic is directed to kernel module I wrote. It appends some headers after the IP header and when it's done with the specific processing, the packet can now be sent. At that point I used to make a call to the ethernet output routine (*ifp-if_start)() and all is well. Today I have a new requirement. I need to send those packets to the first serial port from the kernel module. Still looking for inputs. Thank you On Tuesday 08 March 2005 02:26 pm, Stephan Uphoff wrote: On Tue, 2005-03-08 at 17:04, Jerry Toung wrote: Good afternoon list, I am looking for a way to write data to the serial interface (/dev/cuaa0) from a kernel module and also read /dev/ttyd0 still from that same kernel module. Any pointers to doing that will be great. I want on exchange IP traffic from FreeBSD to another host with different OS via serial cable (null modem). So instead of making a call the NIC driver, I want to use the serial port as may physical layer. Any other ideas for doing this is welcome as well. I know the basics of serial programming from a regular C application: #include termios.h fd = open(/dev/cuaa0, O_RDWR|O_NDELAY) tcsetattr and tcgetattr etc etc. but that's not what I am looking for. Thank you. Jerry What is wrong with just using PPP ? Stephan -- --- Jerry Toung Network Software Engineer, AMTI NASA Ames Research Center mail stop: 258-6 Moffett Field, CA 94035 tel: 650-604-1310 --- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
bay area hacker needed
Hello list, I have tried and done everything to have this remote debugging working, with no success. Any BSD hacker in the bay area that know how to do this, shoot me an email. I will come meet you with a monetary donation if you can make this work. Thank you, Jerry. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: remote debugging question
Hi Greg, thank you for all the feedback. The set remotebaud 1 thing in my previous email was a typo, I usually enter 9600. So you're saying that I may have a communication problem. I would like to point out that I can use cu -l cuaa0 -s 9600 on both side and all is well. What do you think could cause this communication issue? I will run another cvsup soon. May be a bug in 6.0current for kgdb. On Monday 27 September 2004 06:52 pm, Greg 'groggy' Lehey wrote: You'll need the sources as well, but that's the next problem, not the one you're experiencing. as for the sources that I am supposed to transfer to B (the remote), are you talking about /usr/src of A or /usr/obj of A or both? then mount_nfs? My next option will be firewire. thank you, Jerry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: add-symbol-file
Greg, I am not using remote debugging, that's why I made a call to kldsyms (local system) but it only loaded acpi.ko. May be I should try over a serial console. The system wasn't crashed or in db prompt though. As for the question regarding where I got the addresses from, I typed: asf -k -f -s -x modulepath .asf, this created the .asf file and its contain was add-symbol-file /usr/local/src/nren-6.0current/osr_src/if_osr.ko 0xc24b3184 -s .data 0xc24b6900 -s .bss 0xc24b6cc0 then I copied and past it to the kgdb prompt, all went ok. but when I want to list *0xc24b3184, it complained about No source code available or something like that. That's where I am puzzled. I will do what you suggested and over serial console and repost if any problems. Thank you, Jerry It looks like you're not doing it the way it was intended. As it says: Type 'getsyms' after connection to load kld symbols. This does the add-symbol-file for you. Take a look at gdb(4) for more details. If you're debugging a local system, you can use 'kldsyms' instead to load the kld symbols. That's a less obnoxious interface. doadump () at pcpu.h:159 (kgdb) add-symbol-file /usr/local/src/nren-6.0current/osr_src/if_osr.ko 0xc24b3184 -s .data 0xc24b6900 -s .bss 0xc24b6cc0 I'm assuming that this was broken by your MUA, and it's not the way you put it in, which must have been: (kgdb) add-symbol-file /usr/local/src/nren-6.0current/osr_src/if_osr.ko 0xc24b3184 -s .data 0xc24b6900 -s .bss 0xc24b6cc0 Where did you get these addresses from? They're all outside the bounds of the kld as shown below. In any case, I'm not sure that you need getsyms any more. It used to be needed to get round various gdb restrictions. What happens if you don't do anything? If that doesn't work, how about running getsyms, as suggested? Please let me know either way what happens. Greg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
add-symbol-file
Hello list, Could somebody tell me why I can't list the source code of this kld? I built the module with COPTS=-g, it is loaded in the kernel and I run kgdb in /usr/obj/./MYKERNEL. Everything seems to go well, except kgdb still doesn't like it. However if I run kldsyms, it only loads acpi.ko.debug and I can list it. Thank you in advance, Jerry PC203# kgdb kernel.debug /usr/home/guest/crash/vmcore.2 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. Ready to go. Enter 'tr' to connect to the remote target with /dev/cuaa0, 'tr /dev/cuaa1' to connect to a different port or 'trf portno' to connect to the remote target with the firewire interface. portno defaults to 5556. Type 'getsyms' after connection to load kld symbols. If you're debugging a local system, you can use 'kldsyms' instead to load the kld symbols. That's a less obnoxious interface. doadump () at pcpu.h:159 (kgdb) add-symbol-file /usr/local/src/nren-6.0current/osr_src/if_osr.ko 0xc24b3184 -s .data 0xc24b6900 -s .bss 0xc24b6cc0 add symbol table from file /usr/local/src/nren-6.0current/osr_src/if_osr.ko at .text_addr = 0xc24b3184 .data_addr = 0xc24b6900 .bss_addr = 0xc24b6cc0 (y or n) y Reading symbols from /usr/local/src/nren-6.0current/osr_src/if_osr.ko...done. (kgdb) list *0xc24b3184 No source file for address 0xc24b3184. (kgdb) kldstat During symbol reading, Incomplete CFI data; unspecified registers at 0xc05ff7d1. Id Refs AddressSize Name 14 0xc040 5d63e4 kernel 2 14 0xc09d7000 54784acpi.ko 31 0xc2326000 6000 if_osr.ko (kgdb) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2 ipintrq
Hello list,
I am trying to port some code that I wrote from 5.0 to 5.2. What is the
equivalent of the code below for 5.2.
5.0:
ifq = ipintrq;
s = splnet();
if (_IF_QFULL(ifq)) {
_IF_DROP(ifq);
m_freem(m);
} else {
IF_ENQUEUE(ifq,m);
}
splx(s);
5.2: ??
if (!netisr_queue(NETISR_IP, m)) {
printf(%s: queue full, __FUNCTION__)
return ENOBUFS;
}
Thank you,
Jerry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: locking against myself
Thanks a lot Andrey. On Thursday 19 February 2004 12:05 am, Andrey Simonenko wrote: On Wed, Feb 18, 2004 at 11:52:26AM -0800, Jerry Toung wrote: Hello hackers, I am constantly getting the following message when I run my KLD: panic: lockmgr: locking against myself Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db What could possibly cause this? It seem to say that I'm locking an already locked variable. Hello Jerry, According to kern/kern_lock.c:lockmgr() your proc/thread already has an exclusive lock and it tries to obtain a recursive exclusive lock and lock doesn't have LK_CANRECURSE flag (also you allow to sleep in lockmng()). This is documented in lock(9) manual page: LK_EXCLUSIVEAcquire an exclusive lock. If an exclusive lock is already held, and LK_CANRECURSE is not set, the system will panic(9). -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
locking against myself
Hello hackers, I am constantly getting the following message when I run my KLD: panic: lockmgr: locking against myself Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db What could possibly cause this? It seem to say that I'm locking an already locked variable. Thank you, Jerry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
sending messages, user process -- kernel module
Hello, I am trying to do asynchronous send/receive between a user process that I am writing and a kernel module that I am also writing. I thought about implementing something similar to unix routing socket, but I will have to define a new domain and protosw. Beside that idea, what else would you suggest? Thank you, Jerry. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sending messages, user process -- kernel module
Thank you very much for the inputs. On Friday 07 November 2003 01:53 pm, Robert Watson wrote: On Fri, 7 Nov 2003, Jerry Toung wrote: I am trying to do asynchronous send/receive between a user process that I am writing and a kernel module that I am also writing. I thought about implementing something similar to unix routing socket, but I will have to define a new domain and protosw. Beside that idea, what else would you suggest? This is actually somewhat of a FAQ, since it comes up with relative frequency. I should dig up my most recent answer and forward that to you, but the quicky answers off the top of my head are: (1) One frequent answer is a pseudo-device -- for example, /dev/log buffers kernel log output for syslogd to pick up asynchronously. Arla and Coda both use pseudo-devices as a channel for local procedure calls to/from userspace to support their respective file systems using userspace cache managers. (2) Have the kernel open a file system FIFO and have the process on that FIFO. The client-side NFS locking code uses /var/run/lock to ship locking events to a userspace rpc.lockd. However, responses from rpc.lockd are then delivered to the kernel using a system call synchronously from the user process, as opposed to via a FIFO. (3) The routing socket approach can work quite well, especially if you need multicast semantics for messages, not to mention well-defined APIs for managing buffer size, etc. Another instance of this approach is PF_KEY, used for IPsec key management. As you point out, it requires digging into other code and a fair amount of implementation overhead. (4) You can have kernel code create and listen on sockets in existing domains, including UNIX domain sockets and TCP/IP sockets. The NFS client and server code both make use of sockets directly in the kernel for RPCs. Some of the particularly nice benefits of (2) and (4) is that it's easy to implement userspace test code, since the fifo/socket is just used as a rendezvous and doesn't care if the other end is in kernel or not. Likewise, the blocking/buffering/... semantics are quite well defined, which means you won't be tracking down wakeups, select semantics, thread behavior and synchronization, etc, as you might do in (1). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ifconfig w/ if_gre
I am trying to figure out what is the ifconfig command to jump into case GRESADDRS: case GRESADDRD: in gre_ioctl. Thank you, Jerry. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
never mind, ifconfig w/ if_gre
I got lazy, I figured it out. On Monday 27 October 2003 12:35 pm, Jerry Toung wrote: I am trying to figure out what is the ifconfig command to jump into case GRESADDRS: case GRESADDRD: in gre_ioctl. Thank you, Jerry. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
pseudo-driver (*pr_input)
Good morning hackers,
I am writing a pseudo driver for a routing protocol that insert its header
after the ip header. I call it TTT. On the output after ip_output, for
packets destined to a particular subnet I go through the ttt0 virtual
interface calling ttt_output.
In ttt_input all I have is a printf statement to make sure that it is being
called. tcpdump on the physical interface shows those packets getting in as a
result of a ping from 243.10.1.1, but I don't see in the /var/log/messages
what should be printed by ttt_input. I use 2 machines connected back to back
with a crossover cable.
tcpdump: listening on fxp0
16:11:15.398205 243.10.1.1 243.10.1.2: ip-proto-110 91
16:11:16.408227 243.10.1.1 243.10.1.2: ip-proto-110 91
.
in if_ttt.c I have this to support calls to ttt_input
extern struct domain inetdomain;
static const struct protosw in_ttt_protosw =
{ SOCK_RAW, inetdomain, IPPROTO_TTT, PR_ATOMIC|PR_ADDR,
(pr_input_t*)ttt_input, (pr_output_t*)rip_output, rip_ctlinput,
rip_ctloutput, 0, 0, 0, 0, 0,
rip_usrreqs,
};
and in
static int ttt_clone_create(struct if_clone *ifc, int unit)
{
sc-encap_cookie = encap_attach_func(AF_INET, IPPROTO_TTT,
ttt_encapcheck, in_ttt_protosw, sc);
}
sorry for the long post, but if somebody can tell me what I am missing I'll
appreciate.
thank you,
Jerry.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbuf doubts
Giovani, you will find the answer to your question in tcp/ip illustrated, volume 2: the implementation in chapter 2. But to briefly answer your question, yes, there are 4 different types of mbufs, depending on the m_flags value. 1) m_flags = 0 and mbuf contains only data up to 108 bytes. 2) m_flags = M_PKTHDR to designate a packet header. 3)m_flags = M_EXT. In a situation where a user process write() in a buffer 256 bytes, the system allocates a cluster to hold that data. 4) m_flags = M_EXT|M_PKTHDR and yes when using clusters, the memory in the mbuf is unsed. hop that helped. Jerry On Tuesday 23 September 2003 07:12 pm, Giovanni P. Tirloni wrote: Hi, I have been reading the DI chapter about IPC, specially the mbuf section and *many* doubts were raised by my mind. I sending them here in the hope that someone can clarify some bits for me so I can proceed. Reading sys/param.h and sys/mbuf.h I came to the conclusion that there are four types of mbufs regarding it's allocation of memory for data. Is the listing below correct? struct mbuf *m; 1. Normal mbuf using m-M_databuf 2. Normal mbuf with external storage (cluster?) in m-m_hdr-mh_data 3. Header mbuf using m-m_pktdat; 4. Header mbuf with ext. storage (cluster?) in m-m_ext-ext_buf Other questions: 1. When using ext. storage is the space allocated by M_databuf wasted? 2. How the system decides 256 bytes for each mbuf isn't enough and it needs a mbuf cluster? Isn't chaining useful there? 3. How does changing MSIZE affects the whole thing? 4. What about MCLBYTES? Sorry to make so many questions at once but I find it very interesting and I'm really willing to learn how the building blocks of the network stack work. Perhaps my questions are out of reality.. it's risk. Thanks, -- Giovanni P. Tirloni gpt at tirloni.org Fingerprint: 8C3F BEC5 79BD 3E9B EDB8 72F4 16E8 BA5E D031 5C26 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_gre, ip_gre and the like (pseudo-interfaces)
BMS, please be patient. I guess I am still a little bit confuse as to how a packet goes from a real NIC (i.e xl0) to the gre pseudo-device. in if_gre.c, you define a new protocol switch in the inetdomain and gre_input as the input processing function. My understanding is that NIC receives a data, device driver unwraps it and places it in ipintrq. Then (*inetsw[ip_protox[ip-ip_p]].pr_input) in ip_input.c points to gre_input and that's how we land in the gre module. gre_output on the other hand prepends or insert headers and make a call to ip_output which I think will transmit the packet to the physical interface (i.e xl0). With all respect, I don't see any call to IF_HANDOFF in the gre code. only in if_gif that you also wrote. which fit the explaination you gave previously. As for /dev/gre, we can ignore that statement. Thanks lot, Jerry. On Tuesday 02 September 2003 12:12 pm, Bruce M Simpson wrote: On Sun, Aug 31, 2003 at 11:03:40PM -0700, Jerry Toung wrote: My understanding is that gre_input is called by IP everytime it receives a packet with a gre headers which after some processing performs IF_ENQUEUE(ifq,m) to put it back on the IPqueue so that higher protocol such TCP can do their thing. :-) Not quite correct. This is what my legacy GRE code does. The NetBSD-derived if_gre in the tree passes the mbuf to netisr_dispatch(), which in turn calls if_handoff(), which does something similar. I don't see how /dev/gre is ever used on receiving or sending, through if_clone_attach??. Somebody educate me on my missing link. I don't see /dev/gre on my system. If you're referring to the line 'device gre' in the kernel configuration, that is there purely to ensure that the gre driver is statically linked into the kernel. BMS -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
if_gre, ip_gre and the like (pseudo-interfaces)
Hello hackers, for another purpose, I am trying to understand the relationship between gre_input and the gre pseudo-device. My understanding is that gre_input is called by IP everytime it receives a packet with a gre headers which after some processing performs IF_ENQUEUE(ifq,m) to put it back on the IPqueue so that higher protocol such TCP can do their thing. :-) I don't see how /dev/gre is ever used on receiving or sending, through if_clone_attach??. Somebody educate me on my missing link. Thank you all, Jerry. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new routing protocol
Thank you all for the inputs, this should get me started faster. Jerry. On Wednesday 20 August 2003 05:07 am, Paolo Pisati wrote: On Tue, Aug 19, 2003 at 04:02:40PM -0700, Jerry Toung wrote: My problem is dealing with debuging and portability. With this raw approach I guess I will have to run builkernel and installkernel all the time. How can I avoid that? I thought about kernel modules, but I don't know what kind to use (SYSCALL_MODULE or DEV_MODULE,etc..) and how about netgraph.? does that make sense? i'm implementing a packet classification algorithm in FreeBSD using the Netgraph nodes, and i would reccomend you to do the same: writing a netgraph node is really simple (after you crash your os serveral times... =), and you can plug/unplug your code at any time without the need to reboot. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
new routing protocol
dear hackers, I am in the process of implementing a routing protocol under 5.0. This routing protocol is source route based and requires its own header after the ip header and before any other one such as udp,tcp. (ip)(new_rt_hdr)(udp)(paylaod) I am requesting your input as to the best way to approach this. I am thinking that the quick way would be to open netinet/ip_input.c and for every packet with ip-ip_p = NEW_RT_TYPE do my processing. I am not using routing tables, I have another mechanism for routing decisions. and for outgoing packets, before sending to the appropriate interface, in netinet/ip_output.c insert the new routing header then pass the packet to ifp-if_output. My problem is dealing with debuging and portability. With this raw approach I guess I will have to run builkernel and installkernel all the time. How can I avoid that? I thought about kernel modules, but I don't know what kind to use (SYSCALL_MODULE or DEV_MODULE,etc..) and how about netgraph.? does that make sense? somebody give a pointer and I'll figure out how to proceed. I am not that experienced in kernel programming. Thanks a lot, Jerry. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device driver dev. book
Some body just told me that williams Paul from Columbia University (Bill Paul @ Freebsd.org) has written that kind of book. But I can't get his exact email address at FreeBSD.org to ask him the reference. Alexander Langer wrote: Thus spake Jerry Toung ([EMAIL PROTECTED]): Does anyone of you know about a book that would deal specifically with FreeBSD device drivers dev.? If yes let me know. Not books, but there are some tutorials/manpages available. See: http://www.FreeBSD.org/tutorials/ and section 9 of the manual pages. Alex -- ~~~ Jerry ToungNASA Ames Research Center phone : (650) 604-1310 NASA Research Education Network Fax :(650) 604-3080 Mail Stop 233-21 Email : [EMAIL PROTECTED] Moffet Field, CA 94035-1000 ~~~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
device driver dev. book
Hi Readers, Does anyone of you know about a book that would deal specifically with FreeBSD device drivers dev.? If yes let me know. Most of the books in the field are written for Linux and so on. Thanks. Jerry. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
