Re: mbuf LOR
On Wed, 2 Apr 2003, Bosko Milekic wrote: BM For what concerns DONTWAIT, you should theoretically be allowed to BM hold a driver lock. But again, there may be a problem. Specifically, BM I see that UMA code has some explicit Giant acquires/frees in certain BM places. When the UMA code gets called from the malloc() code while BM the bucket is being internally allocated in mb_alloc, you may be BM hitting one of those paths. In fact, unless you have a specific Giant BM acquire in the fxp_* routines you list in your trace below, that is BM undoubtedly what is happening because there are no explicit Giant BM acquires in the code path from m_getcl() to malloc(), so they must be BM happening higher up in the call stack. Well, that's interesting. A month ago or so I sent a patch to smp@ with an update to the malloc page documenting the locking requirements. I got only one response. I wonder, how people are expected to correctly use an API, when that API is poorly documented (malloc(9) in this case, but mbuf(9) does not mention 'lock' either). I would ask people knowing the topic to comment on this. As soon as this EC proposal nightmare is over, I may try to write a corresponding section for mbuf(9). Regards, harti Index: malloc.9 === RCS file: /home/ncvs/src/share/man/man9/malloc.9,v retrieving revision 1.30 diff -u -r1.30 malloc.9 --- malloc.924 Feb 2003 05:53:27 - 1.30 +++ malloc.917 Mar 2003 15:06:14 - @@ -147,44 +147,22 @@ to return .Dv NULL if the request cannot be immediately fulfilled due to resource shortage. -Otherwise, the current process may be put to sleep to wait for -resources to be released by other processes. -If this flag is set, -.Fn malloc -will return -.Dv NULL -rather than block. Note that .Dv M_NOWAIT -is defined to be 0, meaning that blocking operation is the default. -Also note that -.Dv M_NOWAIT is required when running in an interrupt context. -.Pp -Programmers should be careful not to confuse -.Dv M_NOWAIT , -the -.Fn malloc -flag, with -.Dv M_DONTWAIT , -an -.Xr mbuf 9 -allocation flag, which is not a valid argument to -.Fn malloc . .It Dv M_WAITOK -Indicates that it is Ok to wait for resources. It is unconveniently -defined as 0 so care should be taken never to compare against this value -directly or try to AND it as a flag. The default operation is to block -until the memory allocation succeeds. +Indicates that it is ok to wait for resources. +If the request cannot be immediately fulfilled the current process is put +to sleep to wait for resources to be released by other processes. The .Fn malloc , .Fn realloc , and .Fn reallocf -functions can only return +functions cannot return .Dv NULL if -.Dv M_NOWAIT +.Dv M_WAITOK is specified. .It Dv M_USE_RESERVE Indicates that the system can dig into its reserve in order to obtain the @@ -194,6 +172,12 @@ programming. .El .Pp +Exactly one of either +.Dv M_WAITOK +or +.Dv M_NOWAIT +must be specified. +.Pp The .Fa type argument is used to perform statistics on memory usage, and for @@ -244,11 +228,37 @@ While it should not be relied upon, this information may be useful for optimizing the efficiency of memory use. .Pp -Malloc flags documented above should -.Em NOT -be used with +Programmers should be careful not to confuse the malloc flags +.Dv M_NOWAIT +and +.Dv M_WAITOK +with the .Xr mbuf 9 -routines as it will cause undesired results. +flags +.Dv M_DONTWAIT +and +.Dv M_TRYWAIT . +.Sh LOCKING CONSIDERATIONS +.Fn malloc , +.Fn realloc +and +.Fn reallocf +may not be called from fast interrupts handlers. +When called from threaded interrupts +.Ar flag +must contain +.Dv M_NOWAIT . +.Pp +.Fn malloc , +.Fn realloc +and +.Fn reallocf +must not be called with +.Dv M_WAITOK +while a mutex other than Giant is held. +Giant may or may not be held when +.Fn free +is called. .Pp Any calls to .Fn malloc -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
resource limits Giant patch
The following patches at http://people.freebsd.org/~mtm remove process resource limits out from under Giant. I have been bouncing them off jhb for a while now, and I think they are ready. I would appreciate a review/testing There are 4 incremental patches for your reviewing pleasure :-) infrastructure.diff - The necessary infrastructure to do the locking users.diff - Modify consumers of resource limits to use the locks giant.diff - actually remove Giant from (most of) those areas regen.diff - Regenerated files, if you don't care to regenerate your own The basic implementation: Each plimit now has an associated mutex. To read an individual limit it is sufficient that the proc lock is held. To modify a limit or in situations where you need a consitent view of a particular limit(s) both the proc lock and the plimit locks are held. Three new functions can be use to get limits: lim_cur(), lim_max(), and lim_rlimit(), that can be used to obtain the current limit, the hard limit, and the entire rlimit structure, respectively. A limit_lock has been defined to protect the following three globals: maxfiles, maxfilesperproc, and maxprocperuid They each now have their own sysctl proc that grabs the limit_lock in order to write them. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resource limits Giant patch
err http://people.freebsd.org/~mtm/limits ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice behavior fixed.
On Thu, Apr 03, 2003 at 02:31:01AM -0500, Jeff Roberson [EMAIL PROTECTED] wrote: Interactivity is still worse under ULE. It's quite noticeable and I tested it on two SMP boxes by running two simple loops in kind of: for ((;;)); do let $((4+4)); done # this is bash specific The loops ran under nice +20. Typing in the xterm is jerky, characters will not show up immediately, but in small bursts. I mean that about three characters typed in will show up immediately, then small pause happens and a burst of characters (which queued up in the pause) will show up. This is annoying. Starting up xterm takes more time as well, but I can live with that. This is strange, I am not seeing any of this behavior. What is the version of your sched_ule.c? I made more changes very recently. /usr/src/sys/kern/sched_ule.c: $FreeBSD: src/sys/kern/sched_ule.c,v 1.19 2003/04/02 08:22:33 jeff Exp $ I see it's up to version 1.20 now, will it matter? ULE seems faster to me than 4BSD when the loops aren't running or only one loop is running. Anyway, you are definitely making progress in huge steps, it's much-much better than it was when you first committed it. Thank you. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
release and floppies
How to fix problem with floppies 1457664 bytes? P.S. please, CC me ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic - never had one before, what do I do?
I just got a panic. As I have never had one before, I don't know what to do. It's on another system so I don't have to reboot immediately (that would solve the problem temporarily, wouldn't it?) if someone would give me some advice, I could try to help debug it; however, as I'm not a coder (not a real one anyway), I don't know how much help I would be. me to I've got a nasty one booting with today's current. Think I vaguely recall seeing it before, so sorry if this is known. I'm gathering this data using the pen 'n paper approach, so if its not exactly right, you knwo why: ad4 READ Command timeout tag=0 serv=0 -resetting ata2: resetting devices Fatal trap 12: page fault while in kernel mode fault virtual address: 0x0 fault code: supervisor read, page not present instr pointer: 0x8:0xC0160441[note this is a custom kernel] stack pointer: 0x10:0xd1d6fc84 frame pointer: 0x10:0xd1d6fc8c code segment: base 0x0 limit 0xf type 0x1b DPL 0, pres 1, defy2 1, gron 1 processor effage: interrupt enabled, rswen, IOPC=0 current process = 12 (swi7: tty:sio check) kernel: type 12 trap, code = 0 stopped at reinit_bus+0xb: movl[something i can't read] 0(%esi), %eaf db trace[i saw someone else do this] reinit_bus(0,2,c11f0c00, d1d6fcbc, c0146462) at reinit_bus+0x0 atapicam_reinit_bus(c11f0c00, 1, c338da80, c3470800, c015732c) at atapi_cam_reinit_bus+0x13 ata_reinit(c11f0c00, 7, c338da0, d1d6fcf0, c024c071) at ata_reinit+[something - possibly 0x34c] [more stuff - losing the will to live at this stage] Hope that helps somebody, shame i can't read my own writing. Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: release and floppies
+ Anton Yudin [EMAIL PROTECTED]: | How to fix problem with floppies 1457664 bytes? By not downloading a new release before it's announced. Just wait, a corrected version of 4.8-RELEASE without this problem will appear. Wait a little longer, for the official announcement. Then get it. OK? - Harald ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: release and floppies
+ Anton Yudin [EMAIL PROTECTED]: | How to fix problem with floppies 1457664 bytes? By not downloading a new release before it's announced. Just wait, a corrected version of 4.8-RELEASE without this problem will appear. Wait a little longer, for the official announcement. Then get it. OK? but i'm building 5.0-CURRENT, not STABLE ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Apache2 in per-child mode (was Re: libthr and 1:1 threading)
Hi all, Just a note. Apache2 in per-child mode now works with freebsd, while it deadlocked in the old libc_r on STABLE and CURRENT. Thank you very much ! Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
DVD burning under 5.0
I'm looking at creating a machine for backing up/archiving other FreeBSD servers. One of the requirements will be burning DVDs (as some archives are 2-3g directories - difficult to break up) So the question I'm asking is: Is anyone actually using DVD burning under FreeBSD 5? If so, what make/model burner? Also, how compatible are the resultant DVDs? (i.e. can I toss one in a Windows XP machine DVD reader and browse the files?) Any problems or gotchas? Looking for success stories and real-world information. I know the release notes claim compatibiltiy, but I'm curious as to folks experiences. Also, I'm aware of the status of 5 as -CURRENT still, and I'm posting a second email asking for opinions on stability. Thanks in advance for any information. -Bill ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Overall feel for the stability of FreeBSD 5
I'm considering setting up a FreeBSD 5 machine as a dedicated backup/archive computer on a network I administer. I'm curious to hear some opinions on how wise this is. I know that 5 is still in a -CURRENT status and I've seen (and repeated) the warnings that it's not really production quality yet. So I'm curious as to a number of facets of its capibilities: 1) With the current developmet effort ... does it seem like 5.1 will be -STABLE ... or do folks feel that a -STABLE brand is further off (5.2?) 2) For a dedicated backup server, that can tolerate the performance problems that folks have been reporting, and won't upset the entire office if it panics on occasion, is 5 good enough at this point? I know this is inviting a lot of opinion and conjecture ... but I need some idea of where I can go with this. These folks need a solution soon, and I don't want to pass on something that's not ready yet. On the flip side, the nature of the beast means that it doesn't NEED to be a reliable as I normally expect a FreeBSD server to be, so there's a little more tolerance than usual. Any input is greatly appreciated. -Bill ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overall feel for the stability of FreeBSD 5
From: Matthew Emmerton [EMAIL PROTECTED] From: Bill Moran [EMAIL PROTECTED] I'm considering setting up a FreeBSD 5 machine as a dedicated backup/archive computer on a network I administer. I'm curious to hear some opinions on how wise this is. I know that 5 is still in a -CURRENT status and I've seen (and repeated) the warnings that it's not really production quality yet. So I'm curious as to a number of facets of its capibilities: 1) With the current developmet effort ... does it seem like 5.1 will be -STABLE ... or do folks feel that a -STABLE brand is further off (5.2?) 2) For a dedicated backup server, that can tolerate the performance problems that folks have been reporting, and won't upset the entire office if it panics on occasion, is 5 good enough at this point? I know this is inviting a lot of opinion and conjecture ... but I need some idea of where I can go with this. These folks need a solution soon, and I don't want to pass on something that's not ready yet. On the flip side, the nature of the beast means that it doesn't NEED to be a reliable as I normally expect a FreeBSD server to be, so there's a little more tolerance than usual. Any input is greatly appreciated. What's wrong with 4.8-RELEASE? Doesn't support DVD burning. Sorry ... forgot to specify my reasons ;) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbuf LOR
Nate Lawson writes:
I was testing some changes to make fxp MPSAFE and got a LOR in allocating
the mbuf cluster and then finally a panic when trying to dereference the
cluster header. Is the mbuf system MPSAFE? Is it ok to call m_getcl
with a device lock held (but not Giant)?
The lock reversal was: 1. fxp softc lock, 2. Giant.
Traceback:
zalloc...
malloc()
mb_pop_cont()
mb_alloc()
m_getcl()
fxp_add_rfabuf()
fxp_intr_body()
fxp_intr() -- locks fxp softc
-Nate
I think the only place it can be coming from is slab_zalloc().
Does the appended (untested) patch help?
BTW, I don't think that there is any need to get Giant for the zone
allocators in the M_NOWAIT case, but I'm not really familar with the
code, and I don't know if the sparc64 uma_small_alloc needs Giant.
BTW, my MPSAFE driver never sees this, but then again, I never
allocate clusters. I use jumbo frames, and carve out my own recv
buffers, so I'm only allocating mbufs, not clusters.
Drew
Index: uma_core.c
===
RCS file: /home/ncvs/src/sys/vm/uma_core.c,v
retrieving revision 1.51
diff -u -r1.51 uma_core.c
--- uma_core.c 26 Mar 2003 18:44:53 - 1.51
+++ uma_core.c 3 Apr 2003 18:22:14 -
@@ -703,10 +703,14 @@
wait = ~M_ZERO;
if (booted || (zone-uz_flags UMA_ZFLAG_PRIVALLOC)) {
- mtx_lock(Giant);
- mem = zone-uz_allocf(zone,
- zone-uz_ppera * UMA_SLAB_SIZE, flags, wait);
- mtx_unlock(Giant);
+ if ((wait M_NOWAIT) == 0) {
+ mtx_lock(Giant);
+ mem = zone-uz_allocf(zone,
+ zone-uz_ppera * UMA_SLAB_SIZE, flags, wait);
+ mtx_unlock(Giant);
+ } else {
+ mem = NULL;
+ }
if (mem == NULL) {
ZONE_LOCK(zone);
return (NULL);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overall feel for the stability of FreeBSD 5
- Original Message - From: Bill Moran [EMAIL PROTECTED] To: Matthew Emmerton [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, April 03, 2003 1:26 PM Subject: Re: Overall feel for the stability of FreeBSD 5 From: Matthew Emmerton [EMAIL PROTECTED] From: Bill Moran [EMAIL PROTECTED] I'm considering setting up a FreeBSD 5 machine as a dedicated backup/archive computer on a network I administer. I'm curious to hear some opinions on how wise this is. I know that 5 is still in a -CURRENT status and I've seen (and repeated) the warnings that it's not really production quality yet. So I'm curious as to a number of facets of its capibilities: 1) With the current developmet effort ... does it seem like 5.1 will be -STABLE ... or do folks feel that a -STABLE brand is further off (5.2?) 2) For a dedicated backup server, that can tolerate the performance problems that folks have been reporting, and won't upset the entire office if it panics on occasion, is 5 good enough at this point? I know this is inviting a lot of opinion and conjecture ... but I need some idea of where I can go with this. These folks need a solution soon, and I don't want to pass on something that's not ready yet. On the flip side, the nature of the beast means that it doesn't NEED to be a reliable as I normally expect a FreeBSD server to be, so there's a little more tolerance than usual. Any input is greatly appreciated. What's wrong with 4.8-RELEASE? Doesn't support DVD burning. Sorry ... forgot to specify my reasons ;) What is the piece you're missing -- UDF filesystem support or ata driver support? I've seen patches to 4-STABLE to add UDF filesystem support. Perhaps that's all you need. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overall feel for the stability of FreeBSD 5
From: Matthew Emmerton [EMAIL PROTECTED] From: Bill Moran [EMAIL PROTECTED] From: Matthew Emmerton [EMAIL PROTECTED] From: Bill Moran [EMAIL PROTECTED] I'm considering setting up a FreeBSD 5 machine as a dedicated backup/archive computer on a network I administer. I'm curious to hear some opinions on how wise this is. I know that 5 is still in a -CURRENT status and I've seen (and repeated) the warnings that it's not really production quality yet. So I'm curious as to a number of facets of its capibilities: 1) With the current developmet effort ... does it seem like 5.1 will be -STABLE ... or do folks feel that a -STABLE brand is further off (5.2?) 2) For a dedicated backup server, that can tolerate the performance problems that folks have been reporting, and won't upset the entire office if it panics on occasion, is 5 good enough at this point? I know this is inviting a lot of opinion and conjecture ... but I need some idea of where I can go with this. These folks need a solution soon, and I don't want to pass on something that's not ready yet. On the flip side, the nature of the beast means that it doesn't NEED to be a reliable as I normally expect a FreeBSD server to be, so there's a little more tolerance than usual. Any input is greatly appreciated. What's wrong with 4.8-RELEASE? Doesn't support DVD burning. Sorry ... forgot to specify my reasons ;) What is the piece you're missing -- UDF filesystem support or ata driver support? I don't know ... hence my posting. I'm still in the planning stages of this project. Budget doesn't allow me to purchase the required hardware until I'm fairly certain that I have a method to make it work (obviously, there's always some chance of unexpected problems, but I'm trying to gather enough information to minimize that) I've seen patches to 4-STABLE to add UDF filesystem support. Perhaps that's all you need. I'll google a bit ... but links would be welcome ;) Thanks for the help so far, Matt. -Bill ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: linux-emu ioctl not implemented w/ quake3
I'd say this is a video card driver issue, because with my geforce3 and
the nvidia drivers I could run q3 for as long as I wanted without any
issues.
Ken
On Thu, 3 Apr 2003, Matthias Buelow wrote:
Hi folks,
I'm running 5.0-RELEASE-p7 on i386 and investigated how quake3 (linux)
would be doing at the moment. I had some relative success on 4.7
(quake3 ran ok, in 3d acceleration, but only for about 30 seconds, at
which point the whole machine froze solid) so I hoped it might just
work out. This time at least it didn't freeze but I don't even get so
far. When I run quake3.x86, I get the following:
quake3 spits:
Using XFree86-VidModeExtension Version 2.2
XFree86-VidModeExtension Activated at 640x480
libGL error: failed to open DRM: Operation not permitted
...
(at which point it offers me to use Mesa software rendering
as a fallback which, of course, works...)
and the kernel says:
Apr 3 04:59:23 reiher kernel: linux: 'ioctl' fd=13, cmd=0x6401 ('d',1) not
implemented
Does anybody know what ioctl that would be? I didn't get that on 4.7,
is linux-emu divergent between -stable and -current?
The relevant ktrace excerpt follows:
...
1713 quake3.x86 RET old.setrlimit 12/0xc
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86 NAMI /dev/dri
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card0
1713 quake3.x86 NAMI /dev/dri/card0
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL open(0xbfbfeb00,0x2,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card0
1713 quake3.x86 NAMI /dev/dri/card0
1713 quake3.x86 RET open 13/0xd
1713 quake3.x86 CALL ioctl(0xd,0xc0086401 ,0xbfbfec00)
1713 quake3.x86 RET ioctl -1 errno -22 Unknown error: -22
1713 quake3.x86 CALL close(0xd)
1713 quake3.x86 RET close 0
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86 NAMI /dev/dri
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card1
1713 quake3.x86 NAMI /dev/dri/card1
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86 NAMI /dev/dri
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card2
1713 quake3.x86 NAMI /dev/dri/card2
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86 NAMI /dev/dri
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card3
1713 quake3.x86 NAMI /dev/dri/card3
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86 NAMI /dev/dri
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card4
1713 quake3.x86 NAMI /dev/dri/card4
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86 NAMI /dev/dri
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card5
1713 quake3.x86 NAMI /dev/dri/card5
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86 NAMI /dev/dri
1713 quake3.x86 RET setrlimit 0
1713 quake3.x86 CALL setrlimit(0xbfbfeb00,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri/card6
1713 quake3.x86 NAMI /dev/dri/card6
1713 quake3.x86 RET setrlimit JUSTRETURN
1713 quake3.x86 CALL ftruncate
1713 quake3.x86 RET ftruncate 1000/0x3e8
1713 quake3.x86 CALL setrlimit(0x2cea6c30,0xbfbfea00,0)
1713 quake3.x86 NAMI /compat/linux/dev/dri
1713 quake3.x86
Re: sendmail: no local mailer
On Wed, Apr 02, 2003 at 03:18:18PM -0700, Nate Williams wrote:
evantd Sendmail has not been working on my system for some time now. I
evantd can't say exactly how long, but my guess is that it broke when I
evantd upgraded to RELENG_5_0. This is how sendmail is invoked (by
evantd default) and it's output.
evantd # sendmail -L sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost
evantd 451 4.0.0 No local mailer defined: Bad address
evantd 554 5.0.0 QueueDirectory (Q) option must be set
/etc/mail/sendmail.cf is a bogus (empty?) file. One way to fix this is:
cd /etc/mail
mv sendmail.cf sendmail.cf~bogus
make
make restart
This happened on one of my -stable boxes lately when doing a upgrade
using buildworld. For some (unknown) reason m4 bombed out and created
an empty .cf file.
I fixed it by doing something similar to what was done above, although
why m4 failed is a mystery
Some patch:
--- /usr/src/etc/sendmail/Makefile.orig Wed Apr 2 23:51:19 2003
+++ /usr/src/etc/sendmail/Makefile Wed Apr 2 23:51:50 2003
-1,7 +1,7
# (#)Makefile 8.19 (Berkeley) 1/14/97
# $FreeBSD: src/etc/sendmail/Makefile,v 1.21 2002/07/29 09:40:06 ru Exp $
-M4= m4
+M4= /usr/bin/m4
CHMOD= chmod
ROMODE=444
RM= rm -f
This shouldn't be necessary, since m4 is in the path in buildworld, is
installworld, you meant?
it not? Otherwise, we wouldn't be able to run make, cc, or any other
tools.
ok...
this was under slightly patched /usr/src/etc/sendmail/Makefile:
--- /usr/src/etc/sendmail/Makefile.orig Thu Apr 3 19:47:54 2003
+++ /usr/src/etc/sendmail/Makefile Thu Apr 3 21:18:23 2003
-18,6 +18,7
.mc.cf:${M4FILES}
${RM} ${.TARGET}
(cd ${.CURDIR} \
+ set | /usr/bin/grep PATH /tmp/installworld.path 21 ; \
${M4} -D_CF_DIR_=${CFDIR}/ ${SENDMAIL_M4_FLAGS} \
${CFDIR}/m4/cf.m4 ${:R}.mc) ${.TARGET}
${CHMOD} ${ROMODE} ${.TARGET}
So, after some installworld's activity:
rm -f /etc/mail/vega.cf
(cd /usr/src/etc/sendmail set | /usr/bin/grep PATH /tmp/installworld.path 21 ;
m4 -D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/sendmail/cf/
/usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 /etc/mail/vega.mc)
/etc/mail/vega.cf
m4: not found
^
*** Error code 127
Stop in /usr/src/etc/sendmail.
*** Error code 1
Stop in /usr/src/etc.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
# more /tmp/installworld.path
GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font
PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/s
rc/i386/usr/games:/tmp/install.84736
GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac
GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin
OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec
#sh
# export PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr
/obj/usr/src/i386/usr/games:/tmp/install.84736
# /usr/bin/which m4
#
^D
# which m4
/usr/bin/m4
# ls -al /etc/mail/*.cf
-rw-r--r-- 1 root wheel 57079 Apr 3 20:45 /etc/mail/sendmail.cf
-rw-r--r-- 1 root wheel 0 Apr 3 21:33 /etc/mail/vega.cf
# uname -a
FreeBSD vega.reis.zp.ua 4.8-RC FreeBSD 4.8-RC #1: Sun Mar 30 12:52:49 EEST 2003
[EMAIL PROTECTED]:/usr/src/sys/compile/Vega i386
Yes, this was attempt to 'make installworld' from NFS-mounted /usr/src and
/usr/obj. So, /usr/src/etc/sendmail/Makefile definitely should define
M4 as /usr/bin/m4.
Nate
--
NO37-RIPE
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overall feel for the stability of FreeBSD 5
- Original Message - From: Bill Moran [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 03, 2003 10:30 AM Subject: Overall feel for the stability of FreeBSD 5 I'm considering setting up a FreeBSD 5 machine as a dedicated backup/archive computer on a network I administer. I'm curious to hear some opinions on how wise this is. I know that 5 is still in a -CURRENT status and I've seen (and repeated) the warnings that it's not really production quality yet. So I'm curious as to a number of facets of its capibilities: 1) With the current developmet effort ... does it seem like 5.1 will be -STABLE ... or do folks feel that a -STABLE brand is further off (5.2?) 2) For a dedicated backup server, that can tolerate the performance problems that folks have been reporting, and won't upset the entire office if it panics on occasion, is 5 good enough at this point? I know this is inviting a lot of opinion and conjecture ... but I need some idea of where I can go with this. These folks need a solution soon, and I don't want to pass on something that's not ready yet. On the flip side, the nature of the beast means that it doesn't NEED to be a reliable as I normally expect a FreeBSD server to be, so there's a little more tolerance than usual. Any input is greatly appreciated. What's wrong with 4.8-RELEASE? -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overall feel for the stability of FreeBSD 5
Matthew Emmerton wrote: - Original Message - From: Bill Moran [EMAIL PROTECTED] To: Matthew Emmerton [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, April 03, 2003 1:26 PM Subject: Re: Overall feel for the stability of FreeBSD 5 From: Matthew Emmerton [EMAIL PROTECTED] From: Bill Moran [EMAIL PROTECTED] I'm considering setting up a FreeBSD 5 machine as a dedicated backup/archive computer on a network I administer. I'm curious to hear some opinions on how wise this is. I know that 5 is still in a -CURRENT status and I've seen (and repeated) the warnings that it's not really production quality yet. So I'm curious as to a number of facets of its capibilities: 1) With the current developmet effort ... does it seem like 5.1 will be -STABLE ... or do folks feel that a -STABLE brand is further off (5.2?) 2) For a dedicated backup server, that can tolerate the performance problems that folks have been reporting, and won't upset the entire office if it panics on occasion, is 5 good enough at this point? I know this is inviting a lot of opinion and conjecture ... but I need some idea of where I can go with this. These folks need a solution soon, and I don't want to pass on something that's not ready yet. On the flip side, the nature of the beast means that it doesn't NEED to be a reliable as I normally expect a FreeBSD server to be, so there's a little more tolerance than usual. Any input is greatly appreciated. What's wrong with 4.8-RELEASE? Doesn't support DVD burning. Sorry ... forgot to specify my reasons ;) What is the piece you're missing -- UDF filesystem support or ata driver support? The UDF support in 5.x is for reading only. DVD data disks do not require the UDF filesystem and can in fact work just fine with cd9660 or even UFS. DVD video disks usually require UDF as dvd players don't understand anything else, but editing and mastering a dvd video disk is well beyond the scope of this and I would highly recommend using a Mac. Burning some of the DVD formats requires special support, while others can be burned just like a CD. I thought that 4.x and 5.x were at the same level for this support, but Soeren would have the definitive answer. I've seen patches to 4-STABLE to add UDF filesystem support. Perhaps that's all you need. Really? I thought that the backporting effort had died out. Can you provide a link? Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: linux-emu ioctl not implemented w/ quake3
I wrote: Using XFree86-VidModeExtension Version 2.2 XFree86-VidModeExtension Activated at 640x480 libGL error: failed to open DRM: Operation not permitted Ok, I hadn't seen so far the instructions for 5.0 on Eric Anholts website... in fact, I needed to include a few lines into the kernel config and rebuild; in my case: device mgadrm options COMPAT_LINUX options DRM_LINUX did the trick. Now quake seems to work stable, although it seems to be much slower than on Windoze, the cinematics don't work and I get a good amount of garbage (flickering etc.) between frames but it's playable, and above all, doesn't crash the machine. --mkb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
FXP breakage
This may be just my infamous vaio acting up again, but since the recent commit to fxp driver (Monday?) I get a panic on device probe (page fault in kernel mode). That and the way the pccbb act up (always return 0 for event and status register reads, and don't reset pending interrupt on event reg write) make me think that something is awry with the way acpi/pci allocate memory for the device windows. I know there is something funny with the aml/asl since almost everything ends up on irq 9 also... I also sometimes see the lock order problem with pcm but mostly just missing interrupts (choppy sound that comes out slow but in the right order). PCM is responding to display interrupts... -- Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPv6 MTU bug?
[ moved to net@; current@ bcc'ed ]
Hi Craig,
I think I saw the same behaviour while developing a path-mtu discovery
tool. As I'm quite busy right now I didn't really dig into it, but I will
at some point.
I took the liberty to reply to freebsd-net@, because this is not only a
-CURRENT problem.
Mark
On Wed, Apr 02, 2003 at 11:31:02AM -0600, Craig Boston wrote:
I was trying some network diagnostics yesterday and needed to generate a
continuous stream of small packets going across a few routers. So I
used ifconfig to set my MTU to some very low values (100, 300, 500, and
a few others). I know there's probably a better way to accomplish that,
but couldn't think of any at the time so that's what I did :)
Anyway, when I was done, I reset the MTU on my ethernet interface back
to 1500. IPv4 is working fine, but IPv6 is still acting like I have a
low MTU set. All IPv6 TCP connections are limiting the MSS to around 28
bytes of data per packet, and ping6 complains with ping sizes more than
around 50.
I think I've tracked down the problem to this code in nd6.c,
specifically in nd6_setmtu(ifp).
Note that at this point ndi-maxmtu has just been set to
MIN([user-requested MTU], [biggest MTU possible for this interface
type]). ndi-linkmtu hasn't been touched yet and is still set to
whatever the previous linkmtu was.
if (ndi-linkmtu == 0 ||
ndi-maxmtu ndi-linkmtu) {
ndi-linkmtu = ndi-maxmtu;
/* also adjust in6_maxmtu if necessary. */
if (oldlinkmtu == 0) {
/*
* XXX: the case analysis is grotty, but
* it is not efficient to call in6_setmaxmtu()
* here when we are during the initialization
* procedure.
*/
if (in6_maxmtu ndi-linkmtu)
in6_maxmtu = ndi-linkmtu;
} else
in6_setmaxmtu();
}
It looks to me that in the case of raising an interface's MTU,
ndi-maxmtu will be = ndi-linkmtu, causing linkmtu to never get
reset. I may be missing something, but I can't quite figure out the
logical reason for that test.
Luckily I had a kernel.debug lying around so I used gdb to peek into the
kernel memory. In the nd_ifinfo for that interface, linkmtu=100 and
maxmtu=1500. Once I manually reset linkmtu to 1500, IPv6 started
working properly again, without having to sacrifice my uptime :)
Anyway, the behavior looks like a bug, but the code makes it look like
this may be an intentional effect. Any kernel networking gurus care to
comment?
Thanks,
Craig
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Mark SantcroosRIPE Network Coordination Centre
http://www.ripe.net/home/mark/New Projects Group/TTM
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overall feel for the stability of FreeBSD 5
Bill Moran writes: 2) For a dedicated backup server, that can tolerate the performance problems that folks have been reporting, and won't upset the entire office if it panics on occasion, is 5 good enough at this point? If the system isn't really too critical, I'd go for it. I'm running 5.0 in workstation use and had some problems with agp and X11 up until 5.0-RELEASE-p7, on which I haven't had a crash or freeze yet and all seems to be stable. I'm using scsi and ide on that machine. Apart from the agp/graphics/X11 problem and one (I think) related kernel panic I've experienced with -p7, I've not seen any problems. IMHO it's stable enough for use in a relaxed production environment. The more people who engage in testing it, the more problems (also cutting edges in the userland) get ironed out, and the faster that will happen. --mkb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic on fxp
It seems recent current doesn't like my fxp. A current from some 10 hours ago keeps complaining about device timeout and dma timeout. I don't *know* it's fxp fault (for one thing, because it says unknown), but... So, two hours ago, I cvsupped and tried a new world. This one panics on boot, while doing something with fxp (attaching, I think), and doesn't even get me a core dump. I'll try a new world tomorrow. People tweaking fxp, do please try to get it fixed? -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Experience is something you don't get until just after you need it. -- Olivier ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic on fxp
Daniel C. Sobral wrote: It seems recent current doesn't like my fxp. A current from some 10 hours ago keeps complaining about device timeout and dma timeout. I don't *know* it's fxp fault (for one thing, because it says unknown), but... So, two hours ago, I cvsupped and tried a new world. This one panics on boot, while doing something with fxp (attaching, I think), and doesn't even get me a core dump. I'll try a new world tomorrow. People tweaking fxp, do please try to get it fixed? Some details would be useful. Pencil and paper perhaps? Serial cable to another machine and boot -h? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic on fxp
Peter Wemm wrote: Daniel C. Sobral wrote: It seems recent current doesn't like my fxp. A current from some 10 hours ago keeps complaining about device timeout and dma timeout. I don't *know* it's fxp fault (for one thing, because it says unknown), but... So, two hours ago, I cvsupped and tried a new world. This one panics on boot, while doing something with fxp (attaching, I think), and doesn't even get me a core dump. I'll try a new world tomorrow. People tweaking fxp, do please try to get it fixed? Some details would be useful. Pencil and paper perhaps? Serial cable to another machine and boot -h? I'll have to see if I can manage a serial cable here. It shouldn't be difficult, I just have never done it before, let alone on this computer, so I don't know what traps I might fall into. If not that, I'll get at least the functions and the offset of the first few. But not today. Tomorrow, after a new cvsup and a new world. I see there were at least two commits to fxp since my last cvsup. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] No wonder you're tired! You understood so much today. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic on fxp
Daniel C. Sobral wrote: Peter Wemm wrote: Daniel C. Sobral wrote: It seems recent current doesn't like my fxp. A current from some 10 hours ago keeps complaining about device timeout and dma timeout. I don't *know* it's fxp fault (for one thing, because it says unknown), but... So, two hours ago, I cvsupped and tried a new world. This one panics on boot, while doing something with fxp (attaching, I think), and doesn't even get me a core dump. I'll try a new world tomorrow. People tweaking fxp, do please try to get it fixed? Some details would be useful. Pencil and paper perhaps? Serial cable to another machine and boot -h? I'll have to see if I can manage a serial cable here. It shouldn't be difficult, I just have never done it before, let alone on this computer, so I don't know what traps I might fall into. If not that, I'll get at least the functions and the offset of the first few. But not today. Tomorrow, after a new cvsup and a new world. I see there were at least two commits to fxp since my last cvsup. This should be fixed in revision 1.30 of if_fxpreg.h that I committed recently. Sorry for that guys. Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Panic on fxp
I'm seeing the same thing. A kernel from first thing this morning paniced the kernel whilst attempting to probe the device. I saw a commit go in shortly after 15.00 and rebuilt the kernel. Kernel built on that commit allows the box to boot, but the device simply doesn't pass (or see) any traffic...Reverted back to a working kernel from 10March. # ls -ltr /usr/src/sys/dev/fxp/ total 116 -rw-r--r-- 1 root wheel 21318 Oct 25 2001 rcvbundl.h -rw-r--r-- 1 root wheel 8190 Apr 2 13:00 if_fxpvar.h -rw-r--r-- 1 root wheel 73326 Apr 3 11:46 if_fxp.c -rw-r--r-- 1 root wheel 12975 Apr 3 15:14 if_fxpreg.h Peter Wemm wrote: Daniel C. Sobral wrote: It seems recent current doesn't like my fxp. A current from some 10 hours ago keeps complaining about device timeout and dma timeout. I don't *know* it's fxp fault (for one thing, because it says unknown), but... So, two hours ago, I cvsupped and tried a new world. This one panics on boot, while doing something with fxp (attaching, I think), and doesn't even get me a core dump. I'll try a new world tomorrow. People tweaking fxp, do please try to get it fixed? Some details would be useful. Pencil and paper perhaps? Serial cable to another machine and boot -h? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FXP breakage
Pete Carah wrote: This may be just my infamous vaio acting up again, but since the recent commit to fxp driver (Monday?) I get a panic on device probe (page fault in kernel mode). This should be fixed in revision 1.30 of if_fxpreg.h that I committed some time ago. Sorry for the inconvenience. Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FXP breakage
--- Pete Carah [EMAIL PROTECTED] wrote: This may be just my infamous vaio acting up again, but since the recent commit to fxp driver (Monday?) I get a panic on device probe (page fault in kernel mode). That and the way the pccbb act up (always return 0 for event and status register reads, and don't reset pending interrupt on event reg write) make me think that something is awry with the way acpi/pci allocate memory for the device windows. I know there is something funny with the aml/asl since almost everything ends up on irq 9 also... I also sometimes see the lock order problem with pcm but mostly just missing interrupts (choppy sound that comes out slow but in the right order). PCM is responding to display interrupts... -- Pete I wondered what that crash was on boot-up. Sometimes it does boot though! Anyway... I also have almost everything on IRQ9. I'm not sure its FreeBSD - I think its the Vaio :( Just checked Windows 2000 and it lists USB, video, network, firewire, audio _ALL_ on IRQ9. Perhaps your pcm problems come from the interrupt not being delivered at all - try moving a USB mouse while your audio is playing. I have a hacky-hack to make my vaio's audio play normally. I noticed that since the audio and usb share an interrupt, moving a USB mouse gets the pcm interrupt handler called - which results in normal sound. Sorry, I don't have my own web page address handy - I never go there ;) I'll send it privately. Chuck McCrobie [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Fxp breakage
Ok. Hopefully some useful information hereUsing a kernel built against the below fxp sources, the interface simply does not pass or see any traffic. Reverting back to kernel from 01 April permits the intrace to function properly. fxp0: flags=18843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 10.10.10.201 netmask 0x broadcast 10.10.255.255 ether 00:90:27:66:62:1a media: Ethernet autoselect (100baseTX full-duplex) status: active fxp0: Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet port 0xe000-0xe03f mem 0xf900-0xf90f,0xf9101000-0xf9101fff irq 10 at device 11.0 on pci0 fxp0: Ethernet address 00:90:27:66:62:1a [EMAIL PROTECTED]:11:0: class=0x02 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82557/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class= network subclass = ethernet * $FreeBSD: src/sys/dev/fxp/if_fxpreg.h,v 1.30 2003/04/03 18:39:48 mux Exp $ # ls -ltr /usr/src/sys/dev/fxp/ total 116 -rw-r--r-- 1 root wheel 21318 Oct 25 2001 rcvbundl.h -rw-r--r-- 1 root wheel 8190 Apr 2 13:00 if_fxpvar.h -rw-r--r-- 1 root wheel 73326 Apr 3 11:46 if_fxp.c -rw-r--r-- 1 root wheel 12975 Apr 3 15:14 if_fxpreg.h Robin P. Blanchard Systems Integration Specialist Georgia Center for Continuing Education fon: 706.542.2404 | fax: 706.542.6546 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Removing Sendmail
On 03-Apr-2003 Dr Daniel Flickinger wrote: Secondly, I add the following to /etc/rc.conf: mta_start_script= # 2917: block their startup stealth attack sendmail_enable=NO sendmail_outbound_enable=NO sendmail_msp_queue_enable=NO sendmail_submit_enable=NO sendmail_enable=NONE should be all you need for rc.conf. Note NONE rather than NO. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic on fxp
On Thu, Apr 03, 2003 at 04:10:04PM -0500, Robin P. Blanchard wrote: # ls -ltr /usr/src/sys/dev/fxp/ total 116 -rw-r--r-- 1 root wheel 21318 Oct 25 2001 rcvbundl.h -rw-r--r-- 1 root wheel 8190 Apr 2 13:00 if_fxpvar.h -rw-r--r-- 1 root wheel 73326 Apr 3 11:46 if_fxp.c -rw-r--r-- 1 root wheel 12975 Apr 3 15:14 if_fxpreg.h fgrep '$FreeBSD' *fxp* would be more useful. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
core dump with libthr
I got a userland core dump while using privoxy linked against libthr.
I don't know if this is libthr specific, but I thought I would report
it anyway. This might also explain why kde apps always crash on exit
(possibly, not really sure).
-gordon
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
(no debugging symbols found)...
Core was generated by `privoxy'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libthr.so.1...done.
Loaded symbols for /usr/lib/libthr.so.1
Reading symbols from /usr/lib/libc.so.5...done.
Loaded symbols for /usr/lib/libc.so.5
Reading symbols from /usr/libexec/ld-elf.so.1...done.
Loaded symbols for /usr/libexec/ld-elf.so.1
#0 0x28156824 in flockfile () from /usr/lib/libc.so.5
(gdb) bt
#0 0x28156824 in flockfile () from /usr/lib/libc.so.5
#1 0x2813c33a in fgets () from /usr/lib/libc.so.5
#2 0x28136b60 in gethostent () from /usr/lib/libc.so.5
#3 0x28136d87 in _ht_gethostbyname () from /usr/lib/libc.so.5
#4 0x28136663 in nsdispatch () from /usr/lib/libc.so.5
#5 0x28135eac in gethostbyname2 () from /usr/lib/libc.so.5
#6 0x28135e35 in gethostbyname () from /usr/lib/libc.so.5
#7 0x0805a923 in getsockname ()
#8 0x0805a3f6 in getsockname ()
#9 0x0805a090 in getsockname ()
#10 0x0805b0f7 in getsockname ()
#11 0x0805bd14 in getsockname ()
#12 0x2809c0f1 in _thread_start (thread=0x809df40)
at /local/usr.src/lib/libthr/thread/thr_create.c:216
#13 0x28140f33 in _ctx_start () from /usr/lib/libc.so.5
(gdb) frame 12
#12 0x2809c0f1 in _thread_start (thread=0x809df40)
at /local/usr.src/lib/libthr/thread/thr_create.c:216
216 pthread_exit(thread-start_routine(thread-arg));
(gdb) list
211 _thread_start(pthread_t thread)
212 {
213 thread-arch_id = _set_curthread(thread);
214
215 /* Run the current thread's start routine with argument: */
216 pthread_exit(thread-start_routine(thread-arg));
217
218 /* This point should never be reached. */
219 PANIC(Thread has resumed after exit);
220 }
pgp0.pgp
Description: PGP signature
Re: core dump with libthr
I forgot to mention, this is on a dual Athlon MP 1900+. Here's the appropriate part of the dmesg: CPU: AMD Athlon(TM) MP 1900+ (1600.07-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! real memory = 1073659904 (1023 MB) avail memory = 1035481088 (987 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 -gordon pgp0.pgp Description: PGP signature
Re: Removing Sendmail
On Thu, 03 Apr 2003 17:08:46 -0500 (EST) John Baldwin [EMAIL PROTECTED] wrote: On 03-Apr-2003 Dr Daniel Flickinger wrote: Secondly, I add the following to /etc/rc.conf: mta_start_script= # 2917: block their startup stealth attack sendmail_enable=NO sendmail_outbound_enable=NO sendmail_msp_queue_enable=NO sendmail_submit_enable=NO sendmail_enable=NONE should be all you need for rc.conf. Note NONE rather than NO. This is deprecated. It's a non-standard option that complicates rc.conf handling. Cheers -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Yet another libthr crash
I'm just hitting all the fun bugs today. No core dump from this one. Privoxy seems to be a good app to test multiple io threads and is simple enough to be debug. Here's what I got this time: $ /usr/local/sbin/privoxy --no-daemon /usr/local/etc/privoxy/config Apr 03 15:50:49 Privoxy(134709248) Info: loading configuration file '/usr/local/etc/privoxy/config': ... Apr 03 15:51:09 Privoxy(134922240) Request: www.dilbert.com/images/ff_dot.gif Apr 03 15:51:09 Privoxy(134922240) Error: could not resolve hostname www.dilbert.com Apr 03 15:51:09 Privoxy(134925312) Request: www.dilbert.com/comics/dilbert/images/dilbertawards_250x50.gif Apr 03 15:51:09 Privoxy(134992896) Request: www.dilbert.com/comics/dilbert/images/current_features_bullet.gif gif Apr 03 15:51:09 Privoxy(134992896) Request: www.dilbert.com/comics/dilbert/images/current_features_bullApr 03 15:51:09 Privoxy(134929408) Request: www.dilbert.com/comics/dilbert/images/current_features_border_righFatal error 'Illegal call from signal handler' at line 1542 in file /local/usr.src/lib/libthr/thread/thr_mutex.c (errno = 2) $ Kind of odd how the requests are interleaved. And then it seems to have died somewhere in thr_mutex.c::mutex_queue_enq(). -gordon pgp0.pgp Description: PGP signature
Re: Yet another libthr crash
Gordon Tetlow wrote: No core dump from this one. Privoxy seems to be a good app to test multiple io threads and is simple enough to be debug. The source is also pretty Linux-centric, so some issues you finds may be related to that. (But I am all for fixing privoxy on -current, so I can start using it instead of guidescope, which fails to reap its kids due to some linux emulator change - see zombies from linux binaries thread on -current, circa 10/01/02.) Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: sendmail: no local mailer
On 2003-04-03 22:05, Oleg V. Nauman [EMAIL PROTECTED] wrote: On Wed, Apr 02, 2003 at 03:18:18PM -0700, Nate Williams wrote: This happened on one of my -stable boxes lately when doing a upgrade using buildworld. For some (unknown) reason m4 bombed out and created an empty .cf file. I fixed it by doing something similar to what was done above, although why m4 failed is a mystery Some patch: --- /usr/src/etc/sendmail/Makefile.orig Wed Apr 2 23:51:19 2003 +++ /usr/src/etc/sendmail/Makefile Wed Apr 2 23:51:50 2003 @@ -1,7 +1,7 @@ # @(#)Makefile 8.19 (Berkeley) 1/14/97 # $FreeBSD: src/etc/sendmail/Makefile,v 1.21 2002/07/29 09:40:06 ru Exp $ -M4= m4 +M4= /usr/bin/m4 CHMOD= chmod ROMODE=444 RM= rm -f This shouldn't be necessary, since m4 is in the path in buildworld, is installworld, you meant? Actually no. One of the last things done during buildworld is (wrapped to fit under 80 columns): : === etc/sendmail : rm -f freebsd.cf : (cd /usr/src/etc/sendmail \ : m4 -D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/sendmail/cf/ \ : /usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 freebsd.mc) \ :freebsd.cf : chmod 444 freebsd.cf : rm -f /etc/mail/gothmog.cf : (cd /usr/src/etc/sendmail \ : m4 -D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/sendmail/cf/ \ : /usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 \ : /etc/mail/gothmog.mc) /etc/mail/gothmog.cf : chmod 444 /etc/mail/gothmog.cf : rm -f /etc/mail/gothmog.submit.cf : (cd /usr/src/etc/sendmail \ : m4 -D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/sendmail/cf/ \ : /usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 \ : /etc/mail/gothmog.submit.mc) /etc/mail/gothmog.submit.cf : chmod 444 /etc/mail/gothmog.submit.cf ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
MPSAFE fxp m_pkthdr not valid
I have gotten fxp running with MPSAFE and did a large scp transfer. It
ran for a few minutes and then paniced. It was trap 12 (page fault) at
address 0x24. Here is where it crashed:
fxp_start+0xcc
0xc0194a4c is in fxp_start (../../../dev/fxp/if_fxp.c:1263).
1258 * been computed and stored in the checksum field
1259 * in the TCP header. The stack should have
1260 * already done this for us.
1261 */
1262
1263if (mb_head-m_pkthdr.csum_flags) {
1264if (mb_head-m_pkthdr.csum_flags CSUM_DELAY_DATA) {
1265txp-tx_cb-ipcb_ip_activation_high =
1266 FXP_IPCB_HARDWAREPARSING_ENABLE;
1267txp-tx_cb-ipcb_ip_schedule =
The deref of mb_head-m_pkthdr is invalid. Note that my fxp_intr function
acquires the fxp lock right away so this shouldn't be a race in fxp.
There is still the slab_zalloc LOR which I will describe further in another
email.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
