FreeBSD vs Linux framebuffer
Hi Kazutaka, hackers, As adviced by the GGI community, I will first try to port libGGI to the FreeBSD framebuffer. Before I look deeper into the sources, what are the main differencies between Linux and FreeBSD designs? Are the interfaces similar? Regards, Nicholas -- Nicolas Souchu Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Any actual shipping ATM cards supported by FreeBSD 4.x and higher?
Fore systems web site dumps you into Marconi's site, and a search there doesn't find the word ATM. Efficient Networks page doesnt list the card on the products page any more. So barring those 2, which are the only 2 listed in the release notes, where can I get ATM cards that will work? Optimally, with SM fiber interfaces. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
dlopen()
Greetings. Is it safe to remove the *.so file after it is loaded into the process space and addresses to its functions are gotten? I've tested this and have no problems so far. I need this to implement the "hot swap" of the dynamic loading libraries. Thanks, Dmitry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen()
Dmitry Sychov wrote: Greetings. Is it safe to remove the *.so file after it is loaded into the process space and addresses to its functions are gotten? It's safe to remove it as soon as it's been opened. The file will still exist in the filesystem, only there won't be any references to it from any directories, so you won't be able to open it by its name. The file will be really removed from the file system when you close your file descriptor. I've tested this and have no problems so far. I need this to implement the "hot swap" of the dynamic loading libraries. Thanks, Dmitry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- * *Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW:http://www.dante.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen()
On Thu, Nov 23, 2000 at 01:40:34PM +, Konstantin Chuguev wrote: Dmitry Sychov wrote: Greetings. Is it safe to remove the *.so file after it is loaded into the process space and addresses to its functions are gotten? It's safe to remove it as soon as it's been opened. The file will still exist in the filesystem, only there won't be any references to it from any directories, so you won't be able to open it by its name. The file will be really removed from the file system when you close your file descriptor. So the original poster's question is better translated as 'does the dynamic loader ever close and reopen a file after the initial loading, so it could accidentally open the new version of the library and use the old addresses'? I'd guess the answer is 'no' - the dynamic loader most probably opens the file once, and mmap()'s the needed functions; I might very well be wrong though. G'luck, Peter -- This sentence is false. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen()
hi, there! On Wed, 22 Nov 2000, Dmitry Sychov wrote: Is it safe to remove the *.so file after it is loaded into the process space and addresses to its functions are gotten? yes /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen()
Peter Pentchev wrote: Is it safe to remove the *.so file after it is loaded into the process space and addresses to its functions are gotten? It's safe to remove it as soon as it's been opened. The file will still exist in the filesystem, only there won't be any references to it from any directories, so you won't be able to open it by its name. The file will be really removed from the file system when you close your file descriptor. So the original poster's question is better translated as 'does the dynamic loader ever close and reopen a file after the initial loading, so it could accidentally open the new version of the library and use the old addresses'? I'd guess the answer is 'no' - the dynamic loader most probably opens the file once, and mmap()'s the needed functions; I might very well be wrong though. This is how I think it works (don't have any FreeBSD box nearby): For all dynamically loaded modules: dlopen() opens the file (gets a file descriptor) and mmaps it (possibly excluding the debug and some other sections). dlclose() unmaps and closes it. For shared libraries: __init() code of the binary executable dlopen()'s all the libraries, then goes through the table of external symbols, lookups them with dlsym(RTLD_NOW) in the libraries and replaces stub function pointers with the pointers to real functions. The latter may be optimised somehow. __fini() code dlclose()'s all the libraries. But the best way is to look at the source code, of course ;-) -- * *Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW:http://www.dante.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
page coloring
Hi. Isn't the page coloring algoritm in _vm_page_list_find totally bogus? It skips queue pq[index PQ_L2_MASK]. If it doesn't find page with desired color, it allocates page with nearest color - as a result there are two pages with same color mapped at two adjacent virtual adresses - this is the exact opposite of what page coloring should do! It should be changed to something like: for (i = PQ_L2_SIZE * PQ_PRIME1; i 0; i -= PQ_PRIME1) if ((m = TAILQ_FIRST(pq[(index + i) PQ_L2_MASK].pl)) != NULL) break; Mikulas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
subscribe
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Any actual shipping ATM cards supported by FreeBSD 4.x andhigher?
On Thu, 23 Nov 2000, Jaye Mathisen wrote: Fore systems web site dumps you into Marconi's site, and a search there doesn't find the word ATM. Yeah, it was a pretty sad day when the Fore site changed from ATM products to ... actually, I don't know *what* they are selling now. I hope otherwise, but my gut tells me they are preparing to quietly abandon ATM. Efficient Networks page doesnt list the card on the products page any more. I saw the Adaptec 2940 on pricewatch. It uses the Efficient Midway SAR and should probably be a simple or trivial modification to the hea code. The natm (man 4 en) driver handles both Efficient and Adaptec cards, so any differences should be noted there. So barring those 2, which are the only 2 listed in the release notes, where can I get ATM cards that will work? Optimally, with SM fiber interfaces. Shopper.com is pretty slow (search for "forerunner"). It just showed that buy.com has the Fore PCA200E/OC3 for $620. They also list the SMF version for $1730. Personally, I would rather get out my soldering iron and a junk (cheap) part with an SMF module and replace the MMF with the SMF. (Come to think of it, I *DID* do this kind of exchange in the past - works great.) If you don't mind using a driver outside the FreeBSD distribution, you can use the Fore LE155 or IDT Nicstar cards. Mark Tinguely has a driver that works with HARP (http://www.cs.ndsu.nodak.edu/~tinguely) These cards are right now priced from $140 (UTP) to $450 (MMF). If you have no luck at all finding what you want, let me know and I'll get you hooked up with something :-) All the best, -Richard --- Richard Hodges | Matriplex, inc. title | 769 Basque Way [EMAIL PROTECTED] | Carson City, NV 89706 775-886-6477| www.matriplex.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 2 pci , 1 isa, same type NIC makes freebsd seems to be confused
Motomichi Matsuzaki wrote: These separated devclass leads to confusable situation. Drivers which have same name (such like 'ed') should share one devclass, or multiple 'ed0' appear on the host. Sadly, this type of mistakes are widely spreaded on the tree. That's probably because it's widely spread on the tree. There ought to be a note on this on Julian's example driver (though I'm glad to see it already _does_ the right thing), and possibly elsewhere. As well as an effort to fix it in the three. There, I added a note on devclass(9). Someone fix the tree. :-) The fix is trivial, and not even particularly tiring. This is the proverbial junior kernel hacker task, though one doesn't even need to be a junior kernel hacker to do it. :-) The downside is that it's not particularly interesting to do either, and there is nothing to be learned from the experience. /me sighs -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "All right, Lieutenant, let's see what you do know. Whatever it is, it's not enough, but at least you haven't done anything stupid yet." "I've hardly had time, sir." "There's a naive statement." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD's random.c dicey on the Alpha
Anyone want to have a look at this? It's from the GNU awk maintainer. Without knowing which random.c it was, it's hard to judge :-) Also not knowing what the intended use is, it's hard to recommend something. I'd guess src/lib/libc/stdlib/random.c I'll bury it in my TODO. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: porting a Linux app
"Daniel C. Sobral" wrote: Andrew Otwell wrote: gcc -static -I /pathto/new/include -L /pathto/new/lib sourcefile.c -nostdlib -nostdinc and don't forget to compile the libries on freeBSD..you can't just use the Linux ones -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "All right, Lieutenant, let's see what you do know. Whatever it is, it's not enough, but at least you haven't done anything stupid yet." "I've hardly had time, sir." "There's a naive statement." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Ethernet de driver problem on 3.5 stable
I have run into an issue with the de driver and Dlink quad cards under 3.5 stable. Despite the messages from the driver, claiming to be in full duplex, (see trimmed dmesg output below) it's not. I removed a working Intel fxp card from a system and installed the Dlink quad card. Same cable, same switch port (HP 4000M locked at 100 Full Duplex). After booting the machine, slogin session felt like duplex was mismatched (after enough times, one recognizes the symptoms). The switch was seeing CRC errors about once a minute and netstat -in showed lots of collisions (which can not occur in FD Mode) and 1-2 Oerrs per minute. Locking the HP port to 100 Half-Duplex has reduced the Oerrs to four in 24 hours, along with about 1500 collisions (which are expected in HD). slogin sessions no longer feel like the duplex is mismatched. ifconfig claims the card is still in full duplex mode. As we did not see this problem with the Intel, I am not suspecting the cable or the switch port. Is there a known problem with the Dlinks or is this a possible issue in the driver? /\/\ \/\/ FreeBSD 3.5-STABLE #6: Wed Nov 8 18:28:20 EST 2000 Probing for devices on PCI bus 2: de0: Digital 21143 Fast Ethernet rev 0x41 int a irq 11 on pci2.4.0 de0: 21143 [10-100Mb/s] pass 4.1 de0: address 00:80:c8:c9:8c:60 de1: Digital 21143 Fast Ethernet rev 0x41 int a irq 9 on pci2.5.0 de1: 21143 [10-100Mb/s] pass 4.1 de1: address 00:80:c8:c9:8c:61 de2: Digital 21143 Fast Ethernet rev 0x41 int a irq 5 on pci2.6.0 de2: 21143 [10-100Mb/s] pass 4.1 de2: address 00:80:c8:c9:8c:62 de3: Digital 21143 Fast Ethernet rev 0x41 int a irq 10 on pci2.7.0 de3: 21143 [10-100Mb/s] pass 4.1 de3: address 00:80:c8:c9:8c:63 de1: enabling 100baseTX port de0: enabling 100baseTX port de0: enabling Full Duplex 100baseTX port de1: enabling 100baseTX port de1: enabling Full Duplex 100baseTX port To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: page coloring
On Thu, Nov 23, 2000 at 12:48:09PM -0800, Mike Smith wrote: Isn't the page coloring algoritm in _vm_page_list_find totally bogus? No, it's not. The comment is, however, misplaced. It describes the behavior of an inline function in vm_page.h, and not the function it precedes. Hrm. My comment was based on John Dyson's own observations on its behaviour, and other discussions which concluded that the code wasn't flexible enough (hardcoded assumptions on cache organisation, size etc.) Yes, it would be nice if it was "auto-configuring", because many people who use it misconfigure it. They configure the number of colors based upon the size of their cache rather than cache size/degree of associativity. (Having too many colors makes it less likely that you'll get a page of the right color when you ask for one because that queue will be empty.) Overall, it's my experience that people have absurb expectations of page coloring. They think of it as an optimization. It's not. It's better thought of as a necessary evil: Suppose you're writing a numerical application and either you or your compiler goes to a lot of trouble to "block" the algorithm for the L2 cache size. If the underlying OS doesn't do page coloring, it's likely that your program will still experience conflict misses despite your efforts to avoid them. Furthermore, you'll see a different number of conflict misses each time you run the program (assuming the typical random page allocation strategies). So, the execution time will vary. In short, page coloring simply provides a machine whose performance is more deterministic/predictable. Alan P.S. I noticed that I mistakenly cc'ed my previous message to -current rather than -hackers. I've changed it back to -hackers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ethernet de driver problem on 3.5 stable
I have run into an issue with the de driver and Dlink quad cards under 3.5 stable. Despite the messages from the driver, claiming to be in full duplex, [...] Is there a known problem with the Dlinks or is this a possible issue in the driver? [...] Probing for devices on PCI bus 2: de0: Digital 21143 Fast Ethernet rev 0x41 int a irq 11 on pci2.4.0 [...] It's a driver bug, although it's partly Intel's fault for screwing up the 21143 design. To enable full duplex mode, you're supposed to set the full duplex bit in in CSR6. In the 21140A, that's all this bit does; it's not affected by anything else. But in the 21143 design, this bit performs two functions, depending on the setting of the autoneg enable bit in CSR14. If the autoneg enable bit is off, then the full duplex bit works as expected. But if the autoneg enable bit is turned on, the full duplex bit controls whether or not the 21143 will advertise 10Mbps/full-duplex during an NWAY exchange. Unfortunately, after a software reset, the autoneg enable bit in CSR14 is turned on by default, and the de driver never bothers to clear it. The stupid thing is that there are plenty of unused bits in other registers that Intel could have used rather than overloading the full duplex bit in CSR6 to perform two functions. Anyway. The dc driver in FreeBSD 4.0 and later should get this right. If you want to try and fix it in the de driver, you need to add a line somewhere that says: TULIP_CSR_WRITE(sc, csr_14, 0); It should probably at the end of tulip_init(), or possibly near the end of tulip_reset(), the point being to do it immediately after invoking a software reset in order to clear the autoneg enable flag. Either that, or upgrade to FreeBSD 4.2. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 missing syscall
"Walter C. Pelissero" wrote: I'm trying to run a SCO SVR4 executable on FreeBSD but I get a SIGSYS (invalid system call) at the very beginning. Here is the kdump: 39525 ktrace RET ktrace 0 39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x3,0x28061010,0) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x3,0x28061010,0) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x3,0x28061010,0) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL execve(0xbfbff9a3,0xbfbff880,0xbfbff88c) 39525 ktrace NAMI "./scobin" 39525 ktrace NAMI "/compat/svr4/usr/lib/libc.so.1" 39525 scobin RET execve 0 39525 scobin CALL getuid 39525 scobin RET getuid 1001/0x3e9 39525 scobin CALL getuid 39525 scobin RET getuid 1001/0x3e9 39525 scobin CALL getgid 39525 scobin RET getgid 0 39525 scobin CALL getgid 39525 scobin RET getgid 0 39525 scobin CALL setlogin(0x72,0x805056c) 39525 scobin RET setlogin 0 39525 scobin CALL setlogin(0x28,0x280a9764) 39525 scobin RET setlogin 0 39525 scobin CALL break(0x8051580) 39525 scobin RET break 0 39525 scobin CALL setlogin(0x68,0x8049830) 39525 scobin RET setlogin 0 39525 scobin CALL getpid 39525 scobin RET getpid 39525/0x9a65 39525 scobin CALL old.lstat 39525 scobin PSIG SIGSYS SIG_DFL 39525 scobin NAMI "scobin.core" Which call is it about? I see an "old.lstat" but I couldn't find any I believe old.ldstat is the name of BSD syscall with the same number. The other syscall names are also not SVR4 but BSD, kdump has the same problem with Linux binaries too. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen()
In article [EMAIL PROTECTED], Konstantin Chuguev [EMAIL PROTECTED] wrote: Peter Pentchev wrote: So the original poster's question is better translated as 'does the dynamic loader ever close and reopen a file after the initial loading, so it could accidentally open the new version of the library and use the old addresses'? I'd guess the answer is 'no' - the dynamic loader most probably opens the file once, and mmap()'s the needed functions; I might very well be wrong though. This is how I think it works (don't have any FreeBSD box nearby): For all dynamically loaded modules: dlopen() opens the file (gets a file descriptor) and mmaps it (possibly excluding the debug and some other sections). dlclose() unmaps and closes it. Not quite. The dynamic linker opens the file, mmaps it, and closes it immediately. A mapping created by mmap endures even after you close the underlying file. I assume (but have not tested) that it is OK to remove the file after the dlopen call. The file is still mmapped, so I don't think the underlying storage will go away. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
crash on 4.2-stable (sendto() system call)
Hi, got a crash on 4.2-stable. the machine was running 4.1.1-stable and had no problem at all. 10 hours after upgrade to 4.2-stable I got a vmcore. Here it's the trace and could someone take a look, it looks like it was the sendto() call triggered the crash but I don't know how to reproduce it. Thanks --- initial pcb at 24c320 panicstr: page fault panic messages: --- dmesg: kvm_read: --- #0 0xc013336e in dumpsys () (kgdb) bt #0 0xc013336e in dumpsys () #1 0xc013318f in boot () #2 0xc013350c in poweroff_wait () #3 0xc0200461 in trap_fatal () #4 0xc0200139 in trap_pfault () #5 0xc01ffd1f in trap () #6 0xc01882dd in fr_makefrip () #7 0xc018e20c in fr_checkicmpmatchingstate () #8 0xc018e44d in fr_checkstate () #9 0xc0188ecc in fr_check () #10 0xc017d124 in ip_output () #11 0xc017b416 in icmp_send () #12 0xc017b397 in icmp_reflect () #13 0xc017acbd in icmp_error () #14 0xc0185be4 in udp_input () #15 0xc017bdcb in ip_input () #16 0xc017be2b in ipintr () #17 0xc01f69d5 in swi_net_next () #18 0xc0153881 in sendit () #19 0xc0153975 in sendto () #20 0xc020070d in syscall2 () #21 0xc01f5575 in Xint0x80_syscall () Cannot access memory at address 0xbfbffc8c. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: crash on 4.2-stable (sendto() system call)
Hello, Can you please also get the instruction at which the page fault occured? You can try "where" from gdb or you can get the instruction pointer from the original page fault message and then you can probably "disassemble fr_makefrip" and get us the contents around the instruction generating the fault. On Thu, 23 Nov 2000, FengYue wrote: Hi, got a crash on 4.2-stable. the machine was running 4.1.1-stable and had no problem at all. 10 hours after upgrade to 4.2-stable I got a vmcore. Here it's the trace and could someone take a look, it looks like it was the sendto() call triggered the crash but I don't know how to reproduce it. Thanks --- initial pcb at 24c320 panicstr: page fault panic messages: --- dmesg: kvm_read: --- #0 0xc013336e in dumpsys () (kgdb) bt #0 0xc013336e in dumpsys () #1 0xc013318f in boot () #2 0xc013350c in poweroff_wait () #3 0xc0200461 in trap_fatal () #4 0xc0200139 in trap_pfault () #5 0xc01ffd1f in trap () #6 0xc01882dd in fr_makefrip () #7 0xc018e20c in fr_checkicmpmatchingstate () #8 0xc018e44d in fr_checkstate () #9 0xc0188ecc in fr_check () #10 0xc017d124 in ip_output () #11 0xc017b416 in icmp_send () #12 0xc017b397 in icmp_reflect () #13 0xc017acbd in icmp_error () #14 0xc0185be4 in udp_input () #15 0xc017bdcb in ip_input () #16 0xc017be2b in ipintr () #17 0xc01f69d5 in swi_net_next () #18 0xc0153881 in sendit () #19 0xc0153975 in sendto () #20 0xc020070d in syscall2 () #21 0xc01f5575 in Xint0x80_syscall () Cannot access memory at address 0xbfbffc8c. Regards, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: crash on 4.2-stable (sendto() system call)
* Bosko Milekic [EMAIL PROTECTED] [001123 14:51] wrote: Hello, Can you please also get the instruction at which the page fault occured? You can try "where" from gdb or you can get the instruction pointer from the original page fault message and then you can probably "disassemble fr_makefrip" and get us the contents around the instruction generating the fault. It would be better if he could add '-g' to his makeoptions and get a crashdump with debug symbols. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: crash on 4.2-stable (sendto() system call)
On Thu, 23 Nov 2000, Alfred Perlstein wrote:
-* Bosko Milekic [EMAIL PROTECTED] [001123 14:51] wrote:
-
- Hello,
-
- Can you please also get the instruction at which the page fault
- occured? You can try "where" from gdb or you can get the instruction
- pointer from the original page fault message and then you can probably
- "disassemble fr_makefrip" and get us the contents around the instruction
- generating the fault.
-
-It would be better if he could add '-g' to his makeoptions and
-get a crashdump with debug symbols.
-
--Alfred
-
Ah, yes, I actually have -g option turned on. Forgot to do a gdb -k on
the kernel.debug instead. Ok, here comes the new trace:
--
shell# gdb -k kernel.debug /var/crash/vmcore.1
GNU gdb 4.18
Copyright 1998 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-unknown-freebsd"...
IdlePTD 2883584
initial pcb at 24c320
panicstr: page fault
panic messages:
---
dmesg: kvm_read:
---
#0 dumpsys () at ../../kern/kern_shutdown.c:469
469 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:469
#1 0xc013318f in boot (howto=256) at ../../kern/kern_shutdown.c:309
#2 0xc013350c in poweroff_wait (junk=0xc022952f, howto=-662374720)
at ../../kern/kern_shutdown.c:556
#3 0xc0200461 in trap_fatal (frame=0xd892fa68, eva=3232010240)
at ../../i386/i386/trap.c:951
#4 0xc0200139 in trap_pfault (frame=0xd892fa68, usermode=0,
eva=3232010240)
at ../../i386/i386/trap.c:844
#5 0xc01ffd1f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1062957084, tf_esi = 0, tf_ebp = -661456160,
tf_isp = -661456236, tf_ebx = 0, tf_edx = -661456112,
tf_ecx = -661456116, tf_eax = 11008, tf_trapno = 12, tf_err = 0,
tf_eip = -1072135459, tf_cs = 8, tf_eflags = 66118, tf_esp = 16128,
tf_ss = 638}) at ../../i386/i386/trap.c:443
#6 0xc01882dd in fr_makefrip (hlen=20, ip=0xc0a48fe4, fin=0xd892fb0c)
at ../../netinet/fil.c:258
#7 0xc018e20c in fr_checkicmpmatchingstate (ip=0xc0a48fc8,
fin=0xd892fc1c)
at ../../netinet/ip_state.c:1081
#8 0xc018e44d in fr_checkstate (ip=0xc0a48fc8, fin=0xd892fc1c)
at ../../netinet/ip_state.c:1194
#9 0xc0188ecc in fr_check (ip=0xc0a48fc8, hlen=20, ifp=0xc02634e0, out=1,
mp=0xd892fcd4) at ../../netinet/fil.c:887
#10 0xc017d124 in ip_output (m0=0xc0a48f00, opt=0x0, ro=0xd892fd14,
flags=0,
---Type return to continue, or q return to quit---
imo=0x0) at ../../netinet/ip_output.c:437
#11 0xc017b416 in icmp_send (m=0xc0a48f00, opts=0x0)
at ../../netinet/ip_icmp.c:753
#12 0xc017b397 in icmp_reflect (m=0xc0a48f00) at
../../netinet/ip_icmp.c:715
#13 0xc017acbd in icmp_error (n=0xc099e900, type=3, code=3, dest=0,
destifp=0x0) at ../../netinet/ip_icmp.c:225
#14 0xc0185be4 in udp_input (m=0xc099e900, off=20, proto=17)
at ../../netinet/udp_usrreq.c:364
#15 0xc017bdcb in ip_input (m=0xc099e900) at ../../netinet/ip_input.c:731
#16 0xc017be2b in ipintr () at ../../netinet/ip_input.c:759
#17 0xc01f69d5 in swi_net_next ()
#18 0xc0153881 in sendit (p=0xd884f6c0, s=4, mp=0xd892ff10, flags=0)
at ../../kern/uipc_syscalls.c:520
#19 0xc0153975 in sendto (p=0xd884f6c0, uap=0xd892ff80)
at ../../kern/uipc_syscalls.c:572
#20 0xc020070d in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134594596, tf_esi = 4, tf_ebp = -1077937012,
tf_isp = -661454892, tf_ebx = 134569988, tf_edx = 134594560,
tf_ecx = -37, tf_eax = 133, tf_trapno = 12, tf_err = 2,
tf_eip = 671903036, tf_cs = 31, tf_eflags = 514, tf_esp =
-1077937104,
tf_ss = 47}) at ../../i386/i386/trap.c:1150
#21 0xc01f5575 in Xint0x80_syscall ()
Cannot access memory at address 0xbfbffc8c.
(kgdb) disassemble fr_makefrip
Dump of assembler code for function fr_makefrip:
0xc0188174 fr_makefrip: push %ebp
0xc0188175 fr_makefrip+1: mov%esp,%ebp
0xc0188177 fr_makefrip+3: sub$0x2c,%esp
0xc018817a fr_makefrip+6: push %edi
0xc018817b fr_makefrip+7: push %esi
0xc018817c fr_makefrip+8: push %ebx
0xc018817d fr_makefrip+9: mov0xc(%ebp),%edi
0xc0188180 fr_makefrip+12:mov0x10(%ebp),%ecx
0xc0188183 fr_makefrip+15:movw $0x0,0xfffe(%ebp)
0xc0188189 fr_makefrip+21:movw $0x0,0xfffc(%ebp)
0xc018818f fr_makefrip+27:movw $0x0,0xfff8(%ebp)
0xc0188195 fr_makefrip+33:lea0x4(%ecx),%eax
0xc0188198 fr_makefrip+36:mov%eax,0xffec(%ebp)
0xc018819b fr_makefrip+39:movb $0x0,0x35(%ecx)
0xc018819f fr_makefrip+43:movl $0x0,0x40(%ecx)
0xc01881a6 fr_makefrip+50:movb $0x0,0x38(%ecx)
0xc01881aa fr_makefrip+54:movw $0x0,0x30(%ecx)
0xc01881b0
Re: fclose vs ferror (from libc/getcap)
Matt Dillon wrote: [...] In today's world the standard is: When you free() something, that's it.. it's gone. When you fclose() something or otherwise terminate a structure, it's gone. Anything else is illegal. *internally* our libc assumes that ferror() is legal after an fclose() because, well, it's true... but only for internal library functions. Nobody outside the library can legally make that assumption and it could also be argued that even within the library those types of assumptions should not be made unless absolutely necessary. There isn't much we can do about the issue except fix the instances of mis-programming as they show up. An excellent summary of what is and what should be. If we wanted to be anally retentive, we could bzero the FILE after completing the close() operation, just to "help" poorly written programs core... -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
DMA to user process address space!!!
AFAMUG, all user processes are allocated from the virtual memory. so DMA to that doesn't make sense. but is there some way, i can let the kernel know i am DMAing to an address location and hence keep it in main memory until some x seconds?? here is why we need this. we are writing software for a multi-port switch. it can be used in both managed and unmanaged modes. in managed mode, switch is connected to host through PCI interface. all packets that can't be switched are sent to host. with cach such packet, switch passes information like the source port of the packet, it's priority level, whether the packet is tagged or not etc. in normal operation, driver discards this information and sends the packet to ether_input(). for testing purpose, we would like to have user-level process, which receives packets bypassing the ip stack(it isn't freeBSD way of doing things, but this is only for testing) and verifies the information. if the above thing can't be done, then we will have to move the user-process functionality to driver. Thanks, mohan __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
