How to use "offset" parameter in mmap() system call
Hi, I wrote a device driver, it supports mmap(), but I met some problems recently, it seems relate to the "offset" parameter in mmap() system call, what I want to get help are: How to use the offset parameter of mmap() correctly? Can it be used freely? My driver is a char device driver, when it is loaded, it allocates 64 MB contiguous physical memory using contigmalloc(), and I wrote my own memory management function to allocate memory blocks from this 64 MB memory. My driver can be used by several processes concurrently, each process allocates one block from the 64 MB memory, then mmap this block to user space. Each process is assigned a sequence number when it opens the device. For example, assume process X gets the sequence number 0, and allocates memory block 0-2MB, and process Y gets the sequence number 1, and allocates memory block 4-6MB, we use offset 0, size 2MB in process X on calling mmap() system call, and use offset 64MB, size 2MB in process Y on calling mmap() system call. In driver's _mmap() function, we check offset, when it is < 64MB, we know process X do the mmap, then we return physical address of memory block 0-2MB, when the offset is between 64MB and 128MB, we know process Y do the mmap, then we return physical address of memory block 4-6MB. In other word, the "offset" parameter in mmap() system call is just a indicator, we use it to compute the real offset in the 64MB memory to map the memory block the process allocated. My driver can support maximum 16 processes, so the "offset" parameter in mmap() system call can be set to near 16*64MB = 1GB. I wrote a test program, it does very simple thing: 1. open char device; 2. mmap driver's memory; 3. write to mmapped memory; 4. unmap driver's memory. It works fine when I run it manually many times, but after I put it in a while loop in a shell script, and run several scripts concurrently, I found sometimes the mapped user space address don't point to the correct memory block the process allocated in driver. We checked the physical address returned by my driver's _mmap() function, it is correct, but when I sent the mapped user space address back to kernel and use pmap_extract() to get the physical address, it is wrong, it may be another block in the 64MB memory. For example, process X allocate 0-2MB, the mapped user space address is pX, process Y allocate 4-6MB, the mapped user space address is pY, but when pX and pY is sent back to kernel, pmap_extract(pX) is 4-6MB, pmap_extract(pY) is 0-2MB, this is very strange. Below is the simple shell script which shows the error: #!/bin/sh while true do ./my_test_program done I checked some driver codes in the kernel which support mmap(), it seems in many driver, "offset" is used as indicator too, they use "offset" to find the correct memory block and return it's physical address too. But in my driver, the "offset" parameter the user process used in the mmap() system call can be very large, even the mapped memory block is always in the 64 MB contiguous physical memory. But we can compute the real offset correctly. I am not familiar with FreeBSD kernel, but I find "offset" is used by kernel too, so, I am not sure if offset can be set to the very large value as my driver do. Any help is welcomed, thanks! _ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re:
In message: <[EMAIL PROTECTED]>
rashmi ns <[EMAIL PROTECTED]> writes:
: Hello All ,
: I was trying to add a new ioctl cnd like
: #define HDLCMODE _IOR('6',0xF,int)
: when i try to uprintf the data which was sent from the user-space in the
: device-driver-ioctl-routine i'll get a different value than which is passed.
: Can anybody please tell me why this is happening . I pass the address of
: integer from the user space as third arg to the ioctl call .
: thanks and regards,
Remember that there's a level of indirection here. For the userland
call, you'll have something like:
int i = 10;
ioctl (fd, HDLCMODE, &i);
in the kernel, this translates into a call to the driver's ioctl
routine:
int
fooioctl(struct cdev *tp, u_long cmd, void *data, int flag, struct thread *t)
{
switch (cmd)
{
case HDLCMODE:
printf("this should be 10: %d\n", *(int *)data);
break;
}
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: journaling fs and large mailbox format
Alin-Adrian Anton wrote: Dear Hackers, First of all thank you for your time and attention. I am in the position to implement a large-scale mail server and I will never go for anything else but FreeBSD (fixation?). It should be able to handle graceously 4000 e-mail accounts where a minimum of 50 Mb/mailbox would be a requirement. In the begining, it is desirable that users could use as much free space as available, so this implies some gigabytes/mailbox. I don't know if the mbox format can handle this, and I know Maildir cannot handle this on UFS2 standard install, no matter of soft-updates. (because it exhaustes the free nodes) So I currently have no solution for this stuff. I'm not sure how you came to this conclusion, or what the history is, but I see no reason why UFS2 would have any adverse affects on maildir format mail system. You can set the number of inodes to be created to a higher number when using newfs on the filesystem, so if you believe that is an issue, you should be able to tweak it to your needs. mbox starts to break down on large mailboxes with many messages. 50mb may or may not be in that range, but maildir is much better for performance. I was wondering what is the status of Journaling File Systems on FreeBSD? Any which is usable and mature, with write access? XFS would fit amazingly well with Maildir, but.. I doubt it's anything else but readonly. Not sure how journaling would help you much here, except for meta-data consistancy, which soft-updates gives you, and fsck times. So any suggestion would really help a lot. Thank's in advance. A quick note - run the mail area on a RAID array, preferrably a RAID0+1 (or 10 depending on who you ask). Disks are nearly always a bottleneck, so if you can keep your random read/writes fast, the whole system will feel snappy. You might try posting this to freebsd-isp@, since many people there have much larger installations running than this, and can probably provide some good hints. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
journaling fs and large mailbox format
Dear Hackers, First of all thank you for your time and attention. I am in the position to implement a large-scale mail server and I will never go for anything else but FreeBSD (fixation?). It should be able to handle graceously 4000 e-mail accounts where a minimum of 50 Mb/mailbox would be a requirement. In the begining, it is desirable that users could use as much free space as available, so this implies some gigabytes/mailbox. I don't know if the mbox format can handle this, and I know Maildir cannot handle this on UFS2 standard install, no matter of soft-updates. (because it exhaustes the free nodes) So I currently have no solution for this stuff. I was wondering what is the status of Journaling File Systems on FreeBSD? Any which is usable and mature, with write access? XFS would fit amazingly well with Maildir, but.. I doubt it's anything else but readonly. So any suggestion would really help a lot. Thank's in advance. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.4 AMD64 & MPD
On Thursday 29 September 2005 04:30, Daniel Dias Gonçalves wrote: > I installed MPD and it doesn't start, NETGRAPH is enable on kernel. > > # mpd > Multi-link PPP for FreeBSD, by Archie L. Cobbs. > Based on iij-ppp, by Toshiharu OHNO. > mpd: pid 34373563800, version (null) > mpd: caught fatal signal @ ^- funky! :) > mpd: fatal error, exiting > mpd: process 6126 terminated > # > > Last lines in ktrace: Can you run it in GDB and get a backtrace? You may need to rebuild it with debugging symbols enabled to get anything useful out of it. -- 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 pgpWgK3Hbaj5y.pgp Description: PGP signature
System hang / extreme slowdown under MySQL
We are using MySQL on a FreeBSD box for one of our systems and recently after doing a number of application code changes to support a new client the system experiecned what seemed to be a total hang. It didnt crash per se, no log messages were caught it just went mostly unresponsive. The data base is accessed via a set of TCL, C and web apps. The symptoms are no response to any of the programs, yet things like switching virtual consoles etc work ok. But it is not possible to login... one can type 'root', see the characters echoed, press enter and get nothing.. If there is an open ssh session or open console session, one could issue a single command, like 'ls', get the response, then say issue a 'ps' and only get the header line. On one of the occasions as we fly in to reboot the box, one of the users said that it _was working_ just V E R Y S L O W L Y like 3 web pages in 30 minutes. We did find some unclosed database queries in the TCL code that have been fixed, but based on a sysctl that 'seems to be significant' we may not yet have found all our problems. The sysctl that we have picked is the one printed below and in particular the crosspoint PV ENTRY: / USED value. this is slowly but consistently increasing on this box, yet remains stable on all other FreeBSD boxes. THE QUESTIONs are: Is this the correct sysctl to be monitoring? Is there a good description of the sysctl identified re relevance of the numbers to the actual system condition? Does anyone have any other ideas of things to look for that may causing the hangs? The system is FreeBSD svmysql1.dand07.au.bytecraft.au.com 4.10-RELEASE-p7 FreeBSD 4.10-RELEASE-p7 #3: Thu Apr 14 15:34:37 EST 2005 Both the old system (Mysql 3.23) and the current one (mysql Ver 12.22 Distrib 4.0.22, for portbld-freebsd4.10 (i386)) are doing this. Tcl version is 8.4 vm.zone: ITEMSIZE LIMITUSEDFREE REQUESTS PIPE:160,0, 13, 89, 2208898 SWAPMETA:160, 233016, 0, 0,0 unpcb: 160,0, 13, 62,18543 ripcb: 192,12328, 0, 42,5 syncache:160,15359, 0, 51, 1342401 tcpcb: 576,12328,539, 3059, 1341005 udpcb: 192,12328, 3, 39, 9904 socket: 224,12328,556, 3064, 1369458 DIRHASH:1024,0,652, 4, 767 KNOTE:64,0, 1,127, 7589 VNODE: 192,0, 33713,101,33713 NAMEI: 1024,0, 0, 16, 11767321 VMSPACE: 192,0, 39, 89, 585870 PROC:416,0, 72, 75, 585929 DP fakepg:64,0, 0, 0,0 PV ENTRY: 28, 2281256, 78652, 445576, 435851412 MAP ENTRY:48,0, 1084,829, 40997106 KMAP ENTRY: 48,57423,265,119, 2234109 MAP: 108,0, 7, 3,7 VM OBJECT:92,0, 26533,211, 15431058 -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? Murray Taylor Bytecraft Systems P: +61 3 8710 2555 F: +61 3 8710 2599 D: +61 3 9238 4275 E: [EMAIL PROTECTED] --- The information transmitted in this e-mail is for the exclusive use of the intended addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. E-mails may not be secure, may contain computer viruses and may be corrupted in transmission. Please carefully check this e-mail (and any attachment) accordingly. No warranties are given and no liability is accepted for any loss or damage caused by such matters. --- ***This Email has been scanned for Viruses by MailMarshal.*** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 5.4 AMD64 & MPD
I installed MPD and it doesn't start, NETGRAPH is enable on kernel. # mpd Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 34373563800, version (null) mpd: caught fatal signal @ mpd: fatal error, exiting mpd: process 6126 terminated # Last lines in ktrace: 7108 mpd RET read 721/0x2d1 7108 mpd CALL close(0x3) 7108 mpd RET close 0 7108 mpd CALL socket(0x1,0x2,0) 7108 mpd RET socket 3 7108 mpd CALL fcntl(0x3,0x2,0x1) 7108 mpd RET fcntl 0 7108 mpd CALL connect(0x3,0x7fffda70,0x6a) 7108 mpd NAMI "/var/run/logpriv" 7108 mpd RET connect 0 7108 mpd CALL sendto(0x3,0x7fffdfd0,0x68,0,0,0) 7108 mpd GIO fd 3 wrote 104 bytes "<30>Sep 27 15:27:54 mpd: mpd: pid 7108, version 3.18 ([EMAIL PROTECTED] 15:16 27-Sep-2005)" 7108 mpd RET sendto 104/0x68 7108 mpd PSIG SIGSEGV SIG_DFL 7108 mpd NAMI "mpd.core" # Ifconfig: ng0: flags=8890 mtu 1500 Any idea ? -- Daniel Dias Gonçalves DGNET Network Solutions [EMAIL PROTECTED] (37) 99824809 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FATAL: erealloc(): Unable to allocate 577925121 bytes
Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-09-27 05:39:10 -0400: when trying to d/l the following file 1 www www 551M Sep 16 13:23 20050818002.zip via apache1.3.33/php 4.3.11, i get that in the logs i thought it was because i dont have enough swap so i did [...] See ulimit(1), search for "ulimit" in sh(1), and please, ask this kind of questions on, well, [EMAIL PROTECTED] Or, alternatively, in /boot/loader.conf, set: kern.maxdsiz="something bigger" You could do your memory size plus a portion of your swap to total up to the size you need. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [EMAIL PROTECTED]: invalid geometry for >1TB]
Bogdan Taru wrote: On Wed, Sep 28, 2005 at 12:34:47PM -0500, Eric Anderson wrote: Bogdan Taru wrote: Hi hackers, tryin' to install 4.11 or 5.x on a Dell box with a Perc 3/Di Raid controller (with 5x 300GB scsis). I get 'invalid geometry' when running sysinstall/fdisk on the 'disk', the geometry presented being: 145815 cyl / 255 heads / 63 sectors I tried to press 'A' for allocate the whole disk, and after several more warnings it did that, but now the 'free' space in the list has a big minus value as 'Offset'. Is that a problem? What should I do in order to get fbsd on this box? Change geometry? Any other hacks/workarounds? Have you tried using gpt to partition it? Hm. What's gpt? gpt stand for 'great and powerful tool'. Just kidding. From gpt(8): gpt -- GUID partition table maintenance utility check out the man page for details.. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [EMAIL PROTECTED]: invalid geometry for >1TB]
On Wed, Sep 28, 2005 at 12:34:47PM -0500, Eric Anderson wrote: > Bogdan Taru wrote: > > Hi hackers, > > > > tryin' to install 4.11 or 5.x on a Dell box with a Perc 3/Di Raid > >controller (with 5x 300GB scsis). I get 'invalid geometry' when running > >sysinstall/fdisk on the 'disk', the geometry presented being: > > > > 145815 cyl / 255 heads / 63 sectors > > > > I tried to press 'A' for allocate the whole disk, and after several more > >warnings it did that, but now the 'free' space in the list has a big minus > >value as 'Offset'. Is that a problem? > > > > What should I do in order to get fbsd on this box? Change geometry? Any > >other hacks/workarounds? > > Have you tried using gpt to partition it? Hm. What's gpt? bogdan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [EMAIL PROTECTED]: invalid geometry for >1TB]
Bogdan Taru wrote: Hi hackers, tryin' to install 4.11 or 5.x on a Dell box with a Perc 3/Di Raid controller (with 5x 300GB scsis). I get 'invalid geometry' when running sysinstall/fdisk on the 'disk', the geometry presented being: 145815 cyl / 255 heads / 63 sectors I tried to press 'A' for allocate the whole disk, and after several more warnings it did that, but now the 'free' space in the list has a big minus value as 'Offset'. Is that a problem? What should I do in order to get fbsd on this box? Change geometry? Any other hacks/workarounds? Have you tried using gpt to partition it? Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[EMAIL PROTECTED]: invalid geometry for >1TB]
Hi hackers, tryin' to install 4.11 or 5.x on a Dell box with a Perc 3/Di Raid controller (with 5x 300GB scsis). I get 'invalid geometry' when running sysinstall/fdisk on the 'disk', the geometry presented being: 145815 cyl / 255 heads / 63 sectors I tried to press 'A' for allocate the whole disk, and after several more warnings it did that, but now the 'free' space in the list has a big minus value as 'Offset'. Is that a problem? What should I do in order to get fbsd on this box? Change geometry? Any other hacks/workarounds? Thanks, bogdan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-5.4-stable panics
On Sun, 25 Sep 2005, Robert Watson wrote: > > On Fri, 23 Sep 2005, Jason Carroll wrote: > 5B > > There seem to be 2 types of crashes we see with pretty different stack > > traces. What I'll call a type 1 crash, I believe, is often caused by > > one of the triggers I mention above. A type 2 crash appears to happen > > spontaneously after the machine has been running for a while. > > > > I poked around using kgdb in a core file from a type 2 crash, and it > > appeared the system hung closing sockets (specifically cleaning up > > multicast state i think) while cleaning up one of our multicast > > applications (note the trace through sys_exit). There's no reason this > > application should have been exiting unless it encountered some kind of > > error. > > Sounds nasty. It's possible the two panics are related, especially if > they involve a race in the multicast code, which could result in treading > on other kernel memory, potentially leading to the thread related panic. > My leaning would be that they are unrelated, but since we may be able to > eliminate the multicast one (see below), that would be a good starting > point. > > There are some other known stability nits in 6.x which are being worked > on, but in general the network stack stability is higher in 6.x than 5.x > when it comes to multicast due to the work I reference above. If you run > into any stability problems relating to the file system, set > debug.mpsafevfs=0 in loader.conf -- there are a few bug fixes relating to > running out of disk space or hitting quota limits that are fixed in HEAD, > but not yet backported to 6.x. Robert, Thanks for your quick response and suggestions. We have now experienced an additional type of crash. Type 3 is from 6.0-BETA5, it did not enter the debugger at all and we could not generate a core. Unfortunately the 6-BETA crash was completely different from everything we've seen so far. The panic was related to a page fault and 'top' was the active process. We are trying again to run our tests on 6.0, but if we keep encountering other bugs, then those other bugs may prevent us from determining if multicast is the problem. We also ran our applications in 5-STABLE without reading from or writing to disk (ie we ran the multicast data streams on a remote machine, and we told our listener/rebroadcaster apps not to write to disk). In this configuration we were able to run for 4 days without crashing. A few hours before the crash we had introduced disk activity (bonnie in a constant loop with 1G test file size). This crash was a type 1, and we were not able to save a core. The longest we had gone before without a crash was 6 hours, so it is possible that either load, or disk activity help trigger the bugs we have seen. files attached: kernel-conf.txt (6.0 kernel) type3-core.txt (copy of panic output to console) We will update you with more info from our 6.0 tests when we have it. We are in a bind right now. All modern hardware (ie emt64/amd64) only seems to work with versions of freebsd that aren't stable when running our applications. Many vendors do not even sell server hardware that is purely i386. We never encountered these types of problems on freebsd 4.x, and many of our 120+ i386 class machines that are running 4.x are showing their age and need to be replaced. Assuming that the problems we are experiencing are purely related to ths OS, we now don't have an OS to run on the newer hardware we've been buying. We really need to find a way to patch these problems or find a version of freebsd that supports our platform and is stable. Obviously we appreciate the hard work that all of you on the freebsd team do, and we are happy to do whatever we can to help squash these bugs. - Rob Watt# # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.421.2.11.2.1 2005/04/09 17:28:37 kensmith Exp $ machine amd64 cpu HAMMER ident CUSTOM # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g options KDB options DDB options BREAK_TO_DEBUGGER options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_S
Re: freebsd-5.4-stable panics
On 9/27/05, Robert Watson <[EMAIL PROTECTED]> wrote: > > On Tue, 27 Sep 2005, Rob Watt wrote: > > > Is this an SMP box? If so, could you try compiling options KDB_STOP_NMI > into your kernel -- you'll also need to set debug.kdb.stop_cpus_with_nmi=1 > in either loader.conf or at runtime with sysctls. This is a dual-core dual 275 processor box. I have compiled the nmi options into the kernel and we are now using that to test. > > The trap information you've provided indicates that it is likely a data > NULL pointer dereference in the kernel (faulting address is a small > increment above NULL). The instruction pointer looks valid -- if you have > a debugging copy of the kernel, could you load it into gdb and show me > what line number / piece of code it's in? you can use "l > *803b88ca" to generate that, even without a live debugger session > this is the piece of code that was referenced by the ip: (gdb) l *0x803b88ca 0x803b88ca is in nfsrv_lookup (/usr/src/sys/nfsserver/nfs_serv.c:670). 665 NFSD_UNLOCK(); 666 mtx_lock(&Giant); /* VFS */ 667 if (dirp) 668 vrele(dirp); 669 NDFREE(&nd, NDF_ONLY_PNBUF); 670 if (ndp->ni_startdir) 671 vrele(ndp->ni_startdir); 672 if (ndp->ni_vp) 673 vput(ndp->ni_vp); 674 mtx_unlock(&Giant); /* VFS */ we are not running nfsd (although we do use nfs and nfsiod), and none of our processes should have been accessing nfs. Our processes are run from an nfs mount but do not access any nfs mounted files. > > Do you have a testbed or set of test hosts set up so you can > non-disruptively test change sets, btw? > yes we have 3 dual dual-core machines and 1 dual single-core machine that we can use to test with. Thanks! - Rob Watt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FATAL: erealloc(): Unable to allocate 577925121 bytes
# [EMAIL PROTECTED] / 2005-09-27 05:39:10 -0400: > when trying to d/l the following file > > 1 www www 551M Sep 16 13:23 20050818002.zip > > via apache1.3.33/php 4.3.11, i get that in the logs > i thought it was because i dont have enough swap so i did [...] See ulimit(1), search for "ulimit" in sh(1), and please, ask this kind of questions on, well, [EMAIL PROTECTED] -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IOCTL :Facing problems while acccessing data from kernel space
rashmi ns wrote:
#define HDLCMODE _IOR('6',0xF,int)
when i trying to uprintf the data which was sent from the user-space in
the device-driver-ioctl-routine i'll get a different value than which was
passed. Can anybody please tell me why this is happening . I pass the
address of an integer where data is stored from the user space as third arg
to the ioctl call .
maybe you should show how you do it in kernel. I suspect you try to
access it as an int* as well, which is wrong. The kernel already does
take care of this for you. Just write the integer you want to pass into
the data area and you're done.
cheers
simon
--
Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\
Work - Mac +++ space for low $$$ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IOCTL :Facing problems while acccessing data from kernel space
> Hello All ,
Sorry for resending the message many times !!!.
I was trying to add a new ioctl command like
> #define HDLCMODE _IOR('6',0xF,int)
> when i trying to uprintf the data which was sent from the user-space in
> the device-driver-ioctl-routine i'll get a different value than which was
> passed. Can anybody please tell me why this is happening . I pass the
> address of an integer where data is stored from the user space as third arg
> to the ioctl call .
> Thanks and regards,
> Rashmi.N.S
>
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re:
Hello All ,
I was trying to add a new ioctl cnd like
#define HDLCMODE _IOR('6',0xF,int)
when i try to uprintf the data which was sent from the user-space in the
device-driver-ioctl-routine i'll get a different value than which is passed.
Can anybody please tell me why this is happening . I pass the address of
integer from the user space as third arg to the ioctl call .
thanks and regards,
Rashmi.N.S
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
(no subject)
Hello All ,
I was trying to add a new ioctl cnd like
#define HDLCMODE _IOR('6',0xF,int)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nonprivileged access to ipfw
Hi All!
I want a nonprivileged access to ipfw (without sudo, suid and etc..).
But RAW sockets restrict this. I have an one idea - a pseudo device
/dev/ipfw. I think that realisation of this feature is not
difficult task. Now i have some questions.
1. I think correctly about following?
* adding cdevsw declaration with ipfw_ioctl implementation;
* adding make_dev into ipfw initialization function (on MOD_LOAD event);
* adding destroy_dev (on MOD_UNLOAD);
* adding needed functionaly into /sbin/ipfw.
2. About ipfw_ioctl implemetation:
I can pack an ioctl params into sockopt structure and directly call
ipfw_ctl function. It's ok?
3. About ioctl requests - What symbol I should place into definition of
ioctl request? On what it depends? For example:
#define DIOCCLRSTATES _IOWR('D', 18, struct pfioc_state_kill)
>>-^
4. I can define only two ioctl requests, for example:
IPFWIOCSCMD _IOW('x', 0, struct sockopt_like_struct)
IPFWIOCGCMD _IOR('x', 1, struct sockopt_like_struct)
and pass IP_FW_XXX sockoption's into sockopt_like_struct member,
or I should define two definition (set/get) for each IP_FW_XXX option?
Thanks and sorry for my english :(
--
WBR, Andrey V. Elsukov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
