rapid file creation on snapshotted filesystems panics lockmgr
(the below refers exclusively to 5.2.1-RELEASE) Rapid file creation on filesystems with as few as one snapshot on them will panic lockmgr: panic: lockmgr: locking against myself cpuid = 0; syncing disks, buffers remaining... panic: ffs_copyonwrite: recursive call cpuid = 0; uptime: 5m10s Shutting down ACPI (crash) - I have repeated this problem on both a laptop and a server, with both IDE and SCSI disks, and with both a GENERIC and a pared down kernel (no additions, simply subtractions). Further, disabling ACPI by adding hint.acpi.0.disabled="1" to the file /boot/loader.conf did not help in any way. All tested systems were single processor Pentium-3 systems. Here is how you can quickly recreate this problem: mksnap_ffs /mnt/mount1 /mnt/mount1/snapshot_1 cd /mnt/mount1 tar cvf /mnt/mount1/devel.tar /usr/ports/devel tar xvf devel.tar You will panic the system and (possibly) receive the above output within seconds. - If you do not immediately panic the system, the tar process will be blocked: procs memory pagedisks r b w avmfre flt re pi po fr sr da0 fd0 0 1 0 37816 291603 0 0 0 33 25 0 0 and will be in state "snaplk" : PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 598 root -40 1660K 1088K snaplk 1:00 0.00% 0.00% tar It will be impossible to kill the tar process. Further, any additional tar processes will immediately block (the counter will increment to 2 in `vmstat` output). Any attempt to `sync` will also result in a blocked `sync` process in state "snaplk". You will not be able to successfully reboot, as the system will lock when it the shutdown process attempts to sync. - To reproduce this error, it is necessary to create small files rapidly, as I did above by tarring and untarring the /usr/ports/devel directory. If you dd several very large files and tar them up, and then untar them in the filesystem that has been snapshotted, this panic will not occur - even though the total amount of data is much larger than what is contained in a tarball of /usr/ports/devel. I have submitted this as PR misc/68757. - John Kozubik - [EMAIL PROTECTED] - http://www.kozubik.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Article on Sun's DTrace
Hi Nicolas, Nicolas Be'rard Nault wrote: >>> Dtrace is (seems, at least) to be a very powerful tool. Eventual coders >>> could/should get their inspiration out of the work of Sun engineers. >>> But >>> remember, the volunteers of the FreeBSD project aren't paid to do what >>> they do. 2 years and 3 full-time engineers were needed to accomplish >>> Dtrace so I think seeing a similar utility in the near future for >>> FreeBSD >>> is very hopeless. >>> >>> >> So what? >> > > Don't you think this is a candidate for funding from the FreeBSD > foundation ? > > > Do you think it is worth for that? BTW, don't you know my previous post which was not received to this list but you quoted. -- *** Eitarou Kamo Tel. +81 75 7035997 Fax +81 75 7035997 VoIP 050 10585997(domestic only) e‐mail [EMAIL PROTECTED] For business: Feel free to mail me(above), please. Donation http://www.PayPal.Com GPG FingerPrint: 032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
make installworld for non-root user
Hi all, is there an easy way for a non-root user to test the installworld target? I came up with make SHAREOWN=harti SHAREGRP=harti LIBOWN=harti LIBGRP=harti \ NOFSCHG=yes INFOMODE=644 INFOOWN=harti INFOGRP=harti MANOWN=harti \ MANGRP=harti BINOWN=harti BINGRP=harti DESTDIR=/t/scratch/harti/root/ \ installworld but that one breaks in libexec/pt_chown (which has a hard-coded BINOWN=root). Perhaps I can't see the obvious solution? harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make installworld for non-root user
On Wed, Jul 07, 2004 at 09:57:52AM +0200, Harti Brandt wrote: > > Hi all, > > is there an easy way for a non-root user to test the installworld target? > I came up with > > make SHAREOWN=harti SHAREGRP=harti LIBOWN=harti LIBGRP=harti \ > NOFSCHG=yes INFOMODE=644 INFOOWN=harti INFOGRP=harti MANOWN=harti \ > MANGRP=harti BINOWN=harti BINGRP=harti DESTDIR=/t/scratch/harti/root/ \ > installworld > > but that one breaks in libexec/pt_chown (which has a hard-coded > BINOWN=root). > > Perhaps I can't see the obvious solution? > Many bits hardcode owners/groups/modes/flags, but it's still possible to install as non-root. In fact, buildworld already does this for you -- it uses src/tools/install.sh as INSTALL to do it (see the BMAKEENV setting in Makefile.inc1). Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpCsKkhv5F4s.pgp Description: PGP signature
Re: make installworld for non-root user
On Wed, 7 Jul 2004, Ruslan Ermilov wrote: RE>On Wed, Jul 07, 2004 at 09:57:52AM +0200, Harti Brandt wrote: RE>> RE>> Hi all, RE>> RE>> is there an easy way for a non-root user to test the installworld target? RE>> I came up with RE>> RE>> make SHAREOWN=harti SHAREGRP=harti LIBOWN=harti LIBGRP=harti \ RE>> NOFSCHG=yes INFOMODE=644 INFOOWN=harti INFOGRP=harti MANOWN=harti \ RE>> MANGRP=harti BINOWN=harti BINGRP=harti DESTDIR=/t/scratch/harti/root/ \ RE>> installworld RE>> RE>> but that one breaks in libexec/pt_chown (which has a hard-coded RE>> BINOWN=root). RE>> RE>> Perhaps I can't see the obvious solution? RE>> RE>Many bits hardcode owners/groups/modes/flags, but it's still RE>possible to install as non-root. In fact, buildworld already RE>does this for you -- it uses src/tools/install.sh as INSTALL RE>to do it (see the BMAKEENV setting in Makefile.inc1). So it seems that: make SHAREOWN=harti SHAREGRP=harti INSTALL="sh `pwd`/release/install.sh" \ DESTDIR="/somewhere" installworld almost works. Almost, because bsd.lib.mk contains SHLINSTALLFLAGS += -fschg That case is not handled in install.sh and should probably read SHLINSTALLFLAGS += -f schg Additionally I had to add -fschg) shift;; to install.sh, because it seems that the installworld target uses the currently installed mk files not those from src/share/mk. The SHAREOWN SHAREGRP is needed because share/zoneinfo/Makefile passes these directly to zic. This could probably be fixed by calling zic during buildworld and just install the compiled files during installworld. Thanks for your help, harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make installworld for non-root user
On Wed, Jul 07, 2004 at 11:17:00AM +0200, Harti Brandt wrote:
> On Wed, 7 Jul 2004, Ruslan Ermilov wrote:
>
> RE>On Wed, Jul 07, 2004 at 09:57:52AM +0200, Harti Brandt wrote:
> RE>>
> RE>> Hi all,
> RE>>
> RE>> is there an easy way for a non-root user to test the installworld target?
> RE>> I came up with
> RE>>
> RE>> make SHAREOWN=harti SHAREGRP=harti LIBOWN=harti LIBGRP=harti \
> RE>> NOFSCHG=yes INFOMODE=644 INFOOWN=harti INFOGRP=harti MANOWN=harti \
> RE>> MANGRP=harti BINOWN=harti BINGRP=harti DESTDIR=/t/scratch/harti/root/ \
> RE>> installworld
> RE>>
> RE>> but that one breaks in libexec/pt_chown (which has a hard-coded
> RE>> BINOWN=root).
> RE>>
> RE>> Perhaps I can't see the obvious solution?
> RE>>
> RE>Many bits hardcode owners/groups/modes/flags, but it's still
> RE>possible to install as non-root. In fact, buildworld already
> RE>does this for you -- it uses src/tools/install.sh as INSTALL
> RE>to do it (see the BMAKEENV setting in Makefile.inc1).
>
> So it seems that:
>
> make SHAREOWN=harti SHAREGRP=harti INSTALL="sh `pwd`/release/install.sh" \
> DESTDIR="/somewhere" installworld
>
> almost works. Almost, because bsd.lib.mk contains
>
> SHLINSTALLFLAGS += -fschg
>
> That case is not handled in install.sh and should probably read
>
> SHLINSTALLFLAGS += -f schg
>
Rather I've fixed install.sh (committed):
%%%
Index: install.sh
===
RCS file: /home/ncvs/src/tools/install.sh,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- install.sh 6 Feb 2004 11:00:13 - 1.6
+++ install.sh 7 Jul 2004 09:38:14 - 1.7
@@ -33,6 +33,7 @@
case $1 in
-[bCcMpSs]) shift;;
-[Bfgmo]) shift; shift;;
+-[Bfgmo]*) shift;;
*) break;
esac
done
%%%
> Additionally I had to add
>
> -fschg) shift;;
>
> to install.sh, because it seems that the installworld target uses the
> currently installed mk files not those from src/share/mk.
>
Not until you call installworld with "make -fMakefile.inc1 ...".
Normally, src/Makefile is used and it calls installworld with
-m${.CURDIR}/share/mk. You can verify with ``make -n installworld''.
> The SHAREOWN SHAREGRP is needed because share/zoneinfo/Makefile passes
> these directly to zic. This could probably be fixed by calling zic
> during buildworld and just install the compiled files during installworld.
>
Yes, I've been thinking of doing this for some years now. I will see if
I can fix it easily, now that I have a good reason for it. ;)
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpvD3HWRjNKh.pgp
Description: PGP signature
Re: make installworld for non-root user
On Wed, 7 Jul 2004, Ruslan Ermilov wrote:
RE>On Wed, Jul 07, 2004 at 11:17:00AM +0200, Harti Brandt wrote:
RE>> to install.sh, because it seems that the installworld target uses the
RE>> currently installed mk files not those from src/share/mk.
RE>>
RE>Not until you call installworld with "make -fMakefile.inc1 ...".
RE>Normally, src/Makefile is used and it calls installworld with
RE>-m${.CURDIR}/share/mk. You can verify with ``make -n installworld''.
So that was probably just a pilot error from me.
RE>> The SHAREOWN SHAREGRP is needed because share/zoneinfo/Makefile passes
RE>> these directly to zic. This could probably be fixed by calling zic
RE>> during buildworld and just install the compiled files during installworld.
RE>>
RE>Yes, I've been thinking of doing this for some years now. I will see if
RE>I can fix it easily, now that I have a good reason for it. ;)
Would be nice.. I'm currently stuck to use panther to test my patches for sparc
(my sparcs are still in Berlin) and I want to make sure that I don't break
installworld at least.
Thanks,
harti
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Controlling the Serial port
I'm working to develop a communications program to control a piece of
vendor supplied hardware. (They only provide a control program for
Windows.) I think I'm close. The device uses a RS-232 -> RS-485 convert
which I belive is powered by either the RTS or DTR line of the serial
port. How can I force these two lines to say powered in FreeBSD inside a
C program thus providing power to the converter? I only need to
write to the device.
Here is what I have so far. This is my first serial port programming task,
so I probably have a few mistakes.
Thanks,
Greg.
if ((device = open("/dev/cuaa0", O_RDWR | O_NOCTTY |O_NDELAY)) == -1)
{
printf("Error opening port");
exit(1);
}
tcgetattr(device, &term); /* get current port settings */
cfsetspeed(&term, B19200);
term.c_iflag |= IGNPAR; /* ignore incoming parity */
term.c_iflag &= ~(IXON|IXOFF); /* turn OFF Xon/Xoff */
term.c_cflag &= ~CSIZE; /* clear previous character size */
term.c_cflag |= CS8; /* 8 data bits */
term.c_cflag &= ~(CSTOPB|PARENB|CLOCAL);
/* 1 stop bit, no output parity, enable modem ctrl */
term.c_cflag |= CRTSCTS|CRTS_IFLOW; /* RTS/CTS ctrl on */
term.c_cc[VMIN]=0; /* no min characters/read */
term.c_cc[VTIME]=0; /* no read timeout */
term.c_lflag &= ~ICANON; /* noncanonical mode */
tcsetattr(device, TCSANOW, &term);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZEROCOPY between kernel and userland
On Tue, Jul 06, 2004 at 02:22:54PM -0700, Brooks Davis wrote:
> [Please don't top-post, it tends to lose context.]
>
> On Tue, Jul 06, 2004 at 03:36:40PM +0200, thefly wrote:
> > could you point me pls to some code of that? To me read-only access is
> > ok, userspace doesn't need to write anything on it, kernelspace does.
> > But what about locking issues between userspace read access and
> > kernelspace write access?
>
> First, be aware that mmap is not necessicairly faster then copyout on
> modern CPUs. The cycles required to copy a few K of bytes aren't worth
> much of anything on a modern CPU compared to a page-fault. Second, if
> you still want to do things this way, take a look at the geom statistics
> mechanism. IIRC, it works by using a generation number at the top and
> bottom of the stats structure. The user copies the entire struct and
> then verified that the copies of the generation number at the top and
> bottom of the struct are the same. If so, it uses the copy it got. If
> not, it tries again.
>
> -- Brooks
the array dimension is about 1MB, on a p4, i also considered the cost of
a pagefaults and context switches... but i still can't give a real value
to both the approaches. Anyway i'm planning to implement the mmap,
passing it the array at map time, after the read he unmaps it. When he
wants the new snapshot he remaps it, and has the new map. In this way at
mmap time i can give the process the latest snapshot of my array. I've
looked inside kern/subr_devstat.c for the mmap implementation, but still
can't understand how it works. the code is:
static int
devstat_mmap(dev_t dev, vm_offset_t offset, vm_paddr_t *paddr, int nprot)
{
struct statspage *spp;
if (nprot != VM_PROT_READ)
return (-1);
TAILQ_FOREACH(spp, &pagelist, list) {
if (offset == 0) {
*paddr = vtophys(spp->stat);
return (0);
}
offset -= PAGE_SIZE;
}
return (-1);
}
Why does it get from end back for the offset? isn't it an offset from
the head? And anyway there's no munmap() implementation...
He just gets back the phys addr of the memory area, where's the the
reference count of the sh memory? Isn't it reference counted? I guess
it's done by the page faults handler...
In my case i'm using contigmem(), so i got the va... is it right in my
mmap() implementation just to return the va given me by contigmem() or
the va + offset (but i'm not planning to mmap at a specific offset).
About ng_ippact... is there any doc which says what it does NOT in
russian? :)
thanks everybody for the answers, and thanks in advance for the next.
--
Claudio "thefly" Martella
[EMAIL PROTECTED]
GNU/PG keyid: 0x8EA95625
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: APM Patches
Niki Denev writes:
M. Warner Losh writes:
In message: <[EMAIL PROTECTED]>
"Liam J. Foy" <[EMAIL PROTECTED]> writes:
: Hey guys,
:
: Since it was decided (http://lists.freebsd.org/pipermail/freebsd-acpi/2004-June/000352.html)
: we are going to stick with apm -l producing -1 and not 255 which is stated in the handbook would one
: of you guys please commit:
:
: --- /usr/src/usr.sbin/apm/apm.8 Thu Jun 24 17:32:55 2004
: +++ /liamfoy/apm.8 Thu Jun 24 17:32:27 2004
: @@ -106,7 +106,7 @@
: state respectively.
: .It Fl t
: Display the estimated remaining battery lifetime in seconds. If
: -it is unknown, 255 is displayed.
: +it is unknown, -1 is displayed.
: .It Fl Z
: Transition the system into standby mode. This mode uses less power than
: full power mode, but more than suspend mode. Some laptops support
:
:
:
: Another patch I would like you guys to review is this. Currently apm -t will output
: 0 when it cannot find a valid rate or the full battery time(as the comment mentions).
: I think it should return -1 (unknown) to reflect an error, which is stated in the man page.
: It should not return 0 since we do not have 0 seconds left, we have an unknown value
: remaining. Either that or the man page it edited. I believe the following patch should
: be commited really.
:
: The patch is:
:
: --- /usr/src/sys/dev/acpica/acpi_cmbat.c Sun Jul 4 20:41:43 2004
: +++ /home/liamfoy/acpi_cmbat.c Sun Jul 4 20:39:14 2004
: @@ -536,7 +536,7 @@
: bat[i]->min = (bat[i]->full_charge_time * bat[i]->cap) / 100;
: } else {
: /* Couldn't find valid rate and full battery time */
: - bat[i]->min = 0;
: + bat[i]->min = -1;
: }
: total_min += bat[i]->min;
: total_cap += bat[i]->cap;
I don't like this patch, since we use ->min later for math...
Warner
What about this ?
--- sys/dev/acpica/acpi_cmbat.c.orig Mon Jul 5 15:15:28 2004
+++ sys/dev/acpica/acpi_cmbat.c Mon Jul 5 16:37:02 2004
@@ -655,7 +655,7 @@
battinfo->state = ACPI_BATT_STAT_NOT_PRESENT;
} else {
battinfo->cap = sc->cap;
- battinfo->min = sc->min;
+ battinfo->min = sc->min ? sc->min : -1;
battinfo->state = sc->bst.state;
}
--
Regards,
Niki
So, is this Ok or not? :)
I'm running with this for a few days... no probs...
But also the only time that this is used probably is in apm(8) ?
It seems to not affect the math with ->min, by maybe it is not the cleanest
solution to this cosmetic problem?
:)
--
Cheers,
Niki
pgpQHn2YgaccA.pgp
Description: PGP signature
Re: APM Patches
On Wed, 07 Jul 2004 19:42:35 +0300
Niki Denev <[EMAIL PROTECTED]> wrote:
> Niki Denev writes:
>
> > M. Warner Losh writes:
> >
> >> In message: <[EMAIL PROTECTED]>
> >> "Liam J. Foy" <[EMAIL PROTECTED]> writes:
> >> : Hey guys,
> >> :
> >> : Since it was decided
> >> (http://lists.freebsd.org/pipermail/freebsd-acpi/2004-June/000352.html)
> >> : we are going to stick with apm -l producing -1 and not 255 which is stated in
> >> the handbook would one
> >> : of you guys please commit:
> >> :
> >> : --- /usr/src/usr.sbin/apm/apm.8 Thu Jun 24 17:32:55 2004
> >> : +++ /liamfoy/apm.8 Thu Jun 24 17:32:27 2004
> >> : @@ -106,7 +106,7 @@
> >> : state respectively.
> >> : .It Fl t
> >> : Display the estimated remaining battery lifetime in seconds. If
> >> : -it is unknown, 255 is displayed.
> >> : +it is unknown, -1 is displayed.
> >> : .It Fl Z
> >> : Transition the system into standby mode. This mode uses less power than
> >> : full power mode, but more than suspend mode. Some laptops support
> >> :
> >> :
> >> :
> >> : Another patch I would like you guys to review is this. Currently apm -t will
> >> output
> >> : 0 when it cannot find a valid rate or the full battery time(as the comment
> >> mentions).
> >> : I think it should return -1 (unknown) to reflect an error, which is stated in
> >> the man page.
> >> : It should not return 0 since we do not have 0 seconds left, we have an unknown
> >> value
> >> : remaining. Either that or the man page it edited. I believe the following patch
> >> should
> >> : be commited really.
> >> :
> >> : The patch is:
> >> :
> >> : --- /usr/src/sys/dev/acpica/acpi_cmbat.c Sun Jul 4 20:41:43 2004
> >> : +++ /home/liamfoy/acpi_cmbat.c Sun Jul 4 20:39:14 2004
> >> : @@ -536,7 +536,7 @@
> >> : bat[i]->min = (bat[i]->full_charge_time * bat[i]->cap) / 100;
> >> : } else {
> >> : /* Couldn't find valid rate and full battery time */
> >> : -bat[i]->min = 0;
> >> : +bat[i]->min = -1;
> >> : }
> >> : total_min += bat[i]->min;
> >> : total_cap += bat[i]->cap;
> >>
> >> I don't like this patch, since we use ->min later for math...
> >>
> >> Warner
> >
> > What about this ?
> >
> > --- sys/dev/acpica/acpi_cmbat.c.origMon Jul 5 15:15:28 2004
> > +++ sys/dev/acpica/acpi_cmbat.c Mon Jul 5 16:37:02 2004
> > @@ -655,7 +655,7 @@
> > battinfo->state = ACPI_BATT_STAT_NOT_PRESENT;
> > } else {
> > battinfo->cap = sc->cap;
> > - battinfo->min = sc->min;
> > + battinfo->min = sc->min ? sc->min : -1;
> > battinfo->state = sc->bst.state;
> > }
> >
> >
> >
> > --
> > Regards,
> > Niki
>
>
> So, is this Ok or not? :)
> I'm running with this for a few days... no probs...
> But also the only time that this is used probably is in apm(8) ?
> It seems to not affect the math with ->min, by maybe it is not the cleanest
> solution to this cosmetic problem?
I personally like this patch. It does not effect the math and is much
better than returning 0 which would indicate to the user he/she has not
battery life left. I believe this should be changed.
Depends on what the other guys think.
> :)
>
> --
> Cheers,
> Niki
>
>
--
-Liam J. Foy
http://liamfoy.kerneled.org
"Love is like maths -- the idea is simple but can be quite complicated."
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Controlling the Serial port
On Tue, Jul 06, 2004 at 10:53:23PM -0400, Greg Hormann wrote:
>
> I'm working to develop a communications program to control a piece of
> vendor supplied hardware. (They only provide a control program for
> Windows.) I think I'm close. The device uses a RS-232 -> RS-485 convert
> which I belive is powered by either the RTS or DTR line of the serial
> port. How can I force these two lines to say powered in FreeBSD inside a
> C program thus providing power to the converter? I only need to
> write to the device.
So you are doing half duplex rs485 and need to control the transmitter.
Be aware that the code uses variables in a way which is generally a
bad idea - I was into uC programming when I did this...
static int fd;
static int tciotmp;
inline void
txon() {
ioctl(fd, TIOCMGET, &tciotmp);
tciotmp &= ~TIOCM_RTS;
ioctl(fd, TIOCMSET, &tciotmp);
tciotmp |= TIOCM_RTS;
}
inline void
txoff() {
tcdrain(fd); // wait until all data is send
ioctl(fd, TIOCMSET, &tciotmp);
}
The problem is timing as we need to have the transmitter disabled
bevor the connected device responds to our request.
There is no garanty that this is allways fast enough from userland.
It can also be a good idea to clear the receive buffer after enabling
the transmitter and bevor sending anything to wast stall data.
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
unable to copy data from the kernel to the user space
hi hackers,
i am new to kernel hacking , i am just trying to play with the networking code.
i wrote a system call that will copy the mbuf address from the kernel to user space..
the sys call look like this
355 STD BSD { int sn_rqueue(struct mbuf *m);}
and the code in the sn_rqueue syscall look like
struct mbuf *x;
copyout(x,uap->m;sizeof(x));
and the code in the user program look like
struct mbuf *m=NULL;
syscall(355,m);
and when i tryed to read the ' m ' value it still stays as NULL,
may be this question is trivial for u guys..but i was struck at this point...
i will be very thankful if somebody can help in this...
-prady
-
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: unable to copy data from the kernel to the user space
hmmm
On Wed, 7 Jul 2004, pradeep reddy punnam wrote:
> hi hackers,
>
> i am new to kernel hacking , i am just trying to play with the networking code.
> i wrote a system call that will copy the mbuf address from the kernel to user space..
> the sys call look like this
>
> 355 STD BSD { int sn_rqueue(struct mbuf *m);}
>
> and the code in the sn_rqueue syscall look like
> struct mbuf *x;
> copyout(x,uap->m;sizeof(x));
sizeof(*x)
>
> and the code in the user program look like
> struct mbuf *m=NULL;
> syscall(355,m);
you are calling the syscall with a NULL pointer..
of course the copyout will fail
but you are not looking at teh error result..
I think you want:
if you want the address of the mbuf to be sent to user space. (Why on
earth?) then you need.
355 STD BSD { int sn_rqueue(struct mbuf **m);}
copyout(&x, uap->m, sizeof(x))
struct mbuf *m=NULL;
syscall(355,&m);
>
> and when i tryed to read the ' m ' value it still stays as NULL,
> may be this question is trivial for u guys..but i was struck at this point...
> i will be very thankful if somebody can help in this...
>
I'm guessing you want to look at the mbuf directly using /dev/kmem?
there has to be a better way :-)
>
> -prady
>
>
>
>
>
> -
> Do you Yahoo!?
> Yahoo! Mail - 50x more storage than other providers!
> ___
> [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]"
Re: Controlling the Serial port
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 8 Jul 2004 08:20, Bernd Walter wrote: > The problem is timing as we need to have the transmitter disabled > bevor the connected device responds to our request. > There is no garanty that this is allways fast enough from userland. > It can also be a good idea to clear the receive buffer after enabling > the transmitter and bevor sending anything to wast stall data. One way of doing this would be to write a loadable line discipline.. I have been meaning to do this but haven't got around to it yet :) - -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA7Lqx5ZPcIHs/zowRAuAZAJsGADco8jIA2oYt2txMeXKRlSy68ACgj7il QgWyTk/z8SKHHvALHpfXlhc= =fJ4U -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Article on Sun's DTrace
On Wed, Jul 07, 2004, Eitarou Kamo wrote: > FreeBSD has good features such as jail, chroot e.t.c. which can controll Solaris 10 has these features, too, but I'm not sure what that has to do with DTrace. > process or resources in parallel. So you need not port DTrace entirely. > You can implement DTrace like one from scratch. Using legacy system > sometimes makes new system feature. I would rather expect new one than > porting. DTrace is one of example, I think. You may be able to fork new > debug > process in parallel in the future. If I dare name it, It's "B(SD)Trace"? > But it's up to > your effort. DTrace is a pioneer work. And for the people like me who > bothers > to put the debug lines in kernel this must be powerful tool. The page referenced earlier in this thread pointed out that 6 staff-years went into DTrace. That's accurate, and we're not talking about part-time employees or people who don't know what they're doing. The D compiler aside, this is not a small matter of programming that can just be ported to a new OS or machine architecture in a few months. That said, there is prior work in this area, such as: http://oss.software.ibm.com/developer/opensource/linux/projects/dprobes/ But these other efforts don't come close to DTrace. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Article on Sun's DTrace
Hi David, David Schultz wrote: On Wed, Jul 07, 2004, Eitarou Kamo wrote: FreeBSD has good features such as jail, chroot e.t.c. which can controll Solaris 10 has these features, too, but I'm not sure what that has to do with DTrace. If You use the feature with DTrace like tool, You can operate it in parallel. This is just a idea. I know Sol10 has chroot or zfs which behave like jail. What I'd like to say is that you need not insist on just DTrace you can develop original one. The page referenced earlier in this thread pointed out that 6 staff-years went into DTrace. That's accurate, and we're not talking about part-time employees or people who don't know what they're doing. The D compiler aside, this is not a small matter of programming that can just be ported to a new OS or machine architecture in a few months. I think so. If you develop the DTrace like tool, you need the resources at least equivalent with DTrace team, I guess. If you do, your develop team will make any action to get a resources. That said, there is prior work in this area, such as: http://oss.software.ibm.com/developer/opensource/linux/projects/dprobes/ But these other efforts don't come close to DTrace. -- *** Eitarou Kamo Tel. +81 75 7035997 Fax +81 75 7035997 VoIP 050 10585997(domestic only) e-mail [EMAIL PROTECTED] For business: Feel free to mail me(above), please. Donation http://www.PayPal.Com GPG FingerPrint: 032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Article on Sun's DTrace
In the last episode (Jul 07), David Schultz said: > The page referenced earlier in this thread pointed out that 6 > staff-years went into DTrace. That's accurate, and we're not talking > about part-time employees or people who don't know what they're > doing. The D compiler aside, this is not a small matter of > programming that can just be ported to a new OS or machine > architecture in a few months. Pawel Jakub Dawidek has already written a C-like language for his Cerber project that looks like it could be used for a FreeBSD DTrace. It doesn't support associative arrays for stat collecting like D does, but it's got just about everything else. If you just wanted to track syscalls, you could almost use Cerber as-is. http://cerber.sourceforge.net/ -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Article on Sun's DTrace
Hi Dan N, Dan Nelson wrote: In the last episode (Jul 07), David Schultz said: Pawel Jakub Dawidek has already written a C-like language for his Cerber project that looks like it could be used for a FreeBSD DTrace. It doesn't support associative arrays for stat collecting like D does, but it's got just about everything else. If you just wanted to track syscalls, you could almost use Cerber as-is. http://cerber.sourceforge.net/ Indeed, he have already made a action. Eitarou -- *** Eitarou Kamo Tel. +81 75 7035997 Fax +81 75 7035997 VoIP 050 10585997(domestic only) e-mail [EMAIL PROTECTED] For business: Feel free to mail me(above), please. Donation http://www.PayPal.Com GPG FingerPrint: 032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
