MAKEDEV: 609: sysntax error
Hello I cann't install FreeBSD in a box with main board Mega Trends and Pentium II. I have tried installing FreeBSD 4.0, but it has an error when it is finishing the instalation. sysinstall showed: MAKEDEV returned non-zero status. The comit operation completed with errors no updating /etc files. On console: 8386 blocks DEBUG: kget mib1 has length of 0. MAKEDEV: 609: sysntax error: ";;" unexpected (expecting "done") The computer has a 6Gb IDE disk Samsung SV0644A.it has a 1 GB Win98 primary disk partion and 2Gb extend disk partion for Win 98 too. I want install FreeBSD on remainder ot the disk. Thanks. Yonny Cardenas [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Staticaly allocated buffers in library. Is it correct?
So, if I send problem report with my patches, I should inherit usage of staticaly allocated buffers. Am I right? milunovic [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... -BEGIN PGP SIGNED MESSAGE- On Fri, 16 Feb 2001, Andrey Simonenko wrote: I patched some library files and noted that some functions, which parse some configuration files, use staticaly allocated buffers. Sizes of such staticaly allocated buffers are 8k, 10k and so on. These buffers are used to hold one line from parsed file. Usually it is enough for one line, but really this is error (I think). Well since config files can be only changed by root,I don't think that root will use too long lines to case heap overflow.So this isn't big problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
isa/pnp modem not in sio.c
Hello,
A friend of mine has internal modem which is not detected autmagically by
sio.c. It is V.34 ISA modem which behaves like a serial port.
It is a 4.x system.
Pnpinfo returns:
Vendor ID GVC1601 (0x0116c31e), Serial Number 0x0001
Device Description: Rockwell V.34 Plug Play Modem
I found a device list in sio.c and adding {0x0116c31e, NULL} to this list
solves the problem (the device is detected and the modem is working just
fine).
The question is: do we need to do this every time after cvsup or there is an
easier way to detect the modem at boot time (something in /boot)?
--
Players win and Winners play
Have a lucky day
PGP signature
Re: isa/pnp modem not in sio.c
Victor Ivanov wrote:
Hello,
A friend of mine has internal modem which is not detected autmagically by
sio.c. It is V.34 ISA modem which behaves like a serial port.
It is a 4.x system.
Pnpinfo returns:
Vendor ID GVC1601 (0x0116c31e), Serial Number 0x0001
Device Description: Rockwell V.34 Plug Play Modem
I found a device list in sio.c and adding {0x0116c31e, NULL} to this list
solves the problem (the device is detected and the modem is working just
fine).
The question is: do we need to do this every time after cvsup or there is an
easier way to detect the modem at boot time (something in /boot)?
Submit a PR with a patch (diff -c sio.c.orig sio.c) so someone can commit
it to the source. Then send me the PR number and I'll go commit it for
you. ;^)
--
"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
Bug in creating ICMP error messages in FreeBSD4.2
Hi, I encountered the following problem in the 4.2 version. In ip_forward, the following lines intend to save the mbuf in case we want to send ICMP error later: mcopy = m_copy(m, 0, imin((int)ip-ip_len, 64)); if (mcopy (mcopy-m_flags M_EXT)) m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); Later on, before sending the ICMP packet we do: if (mcopy-m_flags M_EXT) m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); The problem as I understand it is that the m_copydata and m_copyback, actually do nothing (It just copies from mcopy to itself). When bombing the kernel with lots (enough to make it issue an ICMP error) of ip packets with length 256 (which is 1 if reversing the byte order), the icmp_error function causes mbuf memory corruption, and later a kernel panic. I believe this caused the problem reported by Andrew Alston in this mailing list on 12.6.2000. I suggest adding a variable: struct ip save_ip_head; Replacing the m_copydata line with: m_copydata(mcopy, 0, sizeof(struct ip), save_ip_head); And the same with the m_copyback line. Ido Barnea _ Get Your Free Virus Protection Tool at http://www.VCatch.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: isa/pnp modem not in sio.c
Wes Peters wrote:
Victor Ivanov wrote:
Hello,
A friend of mine has internal modem which is not detected autmagically by
sio.c. It is V.34 ISA modem which behaves like a serial port.
It is a 4.x system.
Pnpinfo returns:
Vendor ID GVC1601 (0x0116c31e), Serial Number 0x0001
Device Description: Rockwell V.34 Plug Play Modem
I found a device list in sio.c and adding {0x0116c31e, NULL} to this list
solves the problem (the device is detected and the modem is working just
fine).
The question is: do we need to do this every time after cvsup or there is a
n
easier way to detect the modem at boot time (something in /boot)?
Submit a PR with a patch (diff -c sio.c.orig sio.c) so someone can commit
it to the source. Then send me the PR number and I'll go commit it for
you. ;^)
Actually, we want the device logical id, not the card vendor id. There
can be more than one logical device per card.
I constantly wonder why on earth the !#%$!^%!# modem vendors dont use the
'compatid' field to say 'this is compatable with a COM port' - and
everything would work nicely.
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
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Staticaly allocated buffers in library. Is it correct?
: :So, if I send problem report with my patches, I should inherit usage of :staticaly allocated buffers. :Am I right? : :milunovic [EMAIL PROTECTED] wrote in message :[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... : -BEGIN PGP SIGNED MESSAGE- : : On Fri, 16 Feb 2001, Andrey Simonenko wrote: : : I patched some library files and noted that some functions, which parse :some : configuration files, use staticaly allocated buffers. Sizes of such : staticaly allocated buffers are 8k, 10k and so on. These buffers are :used to : hold one line from parsed file. Usually it is enough for one line, but :... Yes. System libraries traditionally use statically allocated buffers because, even now, there is no dynamic equivalent for fgets(). The closest you can get is to mmap() the file and extract the lines that way. But as long as the buffer sizes are reasonable and the library uses fgets() with the proper length limitation, using a statically allocated buffer is not a big deal. Most configuration files couldn't have long lines and still be legal anyway. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Build timings - FreeBSD 4.2 vs. Linux
We just got a couple of Compaq 8500 quad Xeon PIII 700 boxes as daily build servers for the XFree86 tree. I loaded SuSE Linux 7.0 on one box and FreeBSD 4.2-RELEASE on the other. I was surprised to see the large difference in build times. The Linux box compiled in 1 hour and 4 minutes. The FreeBSD box built in 2 hours and 50 minutes. I did stock builds with no parallelization turned on for either. Any ideas as to why it would take almost three times longer to build on FreeBSD? I'm sure that there are several things that can be done to make this faster (like do parallel builds) but I wanted to get the stock behaviour close before doing the parallel work. Thanks, Robin -- Robin Cutshaw internet: [EMAIL PROTECTED] Internet Labs, Inc. BellNet: 404-713-4000 XFree86 coreteam/board member "Time is just one damn thing after another" -- PBS/Nova -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Build timings - FreeBSD 4.2 vs. Linux
Robin Cutshaw [EMAIL PROTECTED] writes: Any ideas as to why it would take almost three times longer to build on FreeBSD? Yup: 4.x sucks at SMP. Try the comparison again with uniprocessor kernels - I expect you'll see a much smaller difference. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Build timings - FreeBSD 4.2 vs. Linux
HAve you turned on soft updates on your object and target file systems? Synchronous file system events can have a large impact on complex compiles; using -pipe can mitigate the effect fairly significantly. If you want to compare Linux and FreeBSD with more similar file system semantics, remount your file systems on FreeBSD using the async flag, and compare the results. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Mon, 19 Feb 2001, Robin Cutshaw wrote: We just got a couple of Compaq 8500 quad Xeon PIII 700 boxes as daily build servers for the XFree86 tree. I loaded SuSE Linux 7.0 on one box and FreeBSD 4.2-RELEASE on the other. I was surprised to see the large difference in build times. The Linux box compiled in 1 hour and 4 minutes. The FreeBSD box built in 2 hours and 50 minutes. I did stock builds with no parallelization turned on for either. Any ideas as to why it would take almost three times longer to build on FreeBSD? I'm sure that there are several things that can be done to make this faster (like do parallel builds) but I wanted to get the stock behaviour close before doing the parallel work. Thanks, Robin -- Robin Cutshaw internet: [EMAIL PROTECTED] Internet Labs, Inc. BellNet: 404-713-4000 XFree86 coreteam/board member "Time is just one damn thing after another" -- PBS/Nova -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Staticaly allocated buffers in library. Is it correct?
In local.freebsd.hackers you write: : :So, if I send problem report with my patches, I should inherit usage of :staticaly allocated buffers. :Am I right? : :milunovic [EMAIL PROTECTED] wrote in message :[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... : -BEGIN PGP SIGNED MESSAGE- : : On Fri, 16 Feb 2001, Andrey Simonenko wrote: : : I patched some library files and noted that some functions, which parse :some : configuration files, use staticaly allocated buffers. Sizes of such : staticaly allocated buffers are 8k, 10k and so on. These buffers are :used to : hold one line from parsed file. Usually it is enough for one line, but :... Yes. System libraries traditionally use statically allocated buffers because, even now, there is no dynamic equivalent for fgets(). The closest you can get is to mmap() the file and extract the lines that way. How about fgetln(3)? /Mikko -- Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Staticaly allocated buffers in library. Is it correct?
Hi Matt,
At 09:23 19/02/01 -0800, Matt Dillon wrote:
Yes. System libraries traditionally use statically allocated buffers
because, even now, there is no dynamic equivalent for fgets(). The
closest you can get is to mmap() the file and extract the lines that
way.
But as long as the buffer sizes are reasonable and the library uses
fgets() with the proper length limitation, using a statically allocated
buffer is not a big deal. Most configuration files couldn't have long
lines and still be legal anyway.
Note that the classical loop
while (fgets(buf, n, fp) != NULL) {
tokenize(buf, args...);
...
}
may have problems if the line is too long, so one needs to detect it by
looking for the '\n'. if none is found, then one can either abort on error
or ignore the line. In the latter case, you need to read the remaining chars
so that the next fgets won't get them.
regards,
mouss
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Bug in creating ICMP error messages in FreeBSD4.2
At 14:25 19/02/01 +0200, [EMAIL PROTECTED] wrote: Hi, I encountered the following problem in the 4.2 version. In ip_forward, the following lines intend to save the mbuf in case we want to send ICMP error later: mcopy = m_copy(m, 0, imin((int)ip-ip_len, 64)); if (mcopy (mcopy-m_flags M_EXT)) m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); Later on, before sending the ICMP packet we do: if (mcopy-m_flags M_EXT) m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); The problem as I understand it is that the m_copydata and m_copyback, actually do nothing (It just copies from mcopy to itself). I'm speaking from memory, so don't take this for more than it is:) As far as I understand: m_copym copies the mbuf, but if there is external storage, only pointers are copied. so you get two mbuf chains with a common external storage. m_copydata will copy the external storage. that's why there are both m_copym and m_copydata. so while m_copydata(mcopy, (mcopy...)) is surprising, it's not nothing. it copies the data pointed to in mcopy. cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IrDA and FreeBSD
On Fri, 16 Feb 2001, Panagiotis Astithas wrote: I have also finished porting the findchip utility. You can find it attached. It works fine(*) on my -stable machine, but I would like someone to try it out on a -current box, just to be sure. It runs on current: Found SMC FDC37N958FR Controller at 0x3f0, DevID=0x01, Rev. 1 SIR Base 0x3e8, FIR Base 0x290 IRQ = 4, DMA = 3 Enabled: yes, Suspended: no UART compatible: yes Half duplex delay = 3 us This is a Dell Latitude CPi D266XT. If there is any more code to be tested please let me know. rvdp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Build timings - FreeBSD 4.2 vs. Linux
Robin Cutshaw wrote: We just got a couple of Compaq 8500 quad Xeon PIII 700 boxes as daily build servers for the XFree86 tree. I loaded SuSE Linux 7.0 on one box and FreeBSD 4.2-RELEASE on the other. I was surprised to see the large difference in build times. The Linux box compiled in 1 hour and 4 minutes. The FreeBSD box built in 2 hours and 50 minutes. I did stock builds with no parallelization turned on for either. Any ideas as to why it would take almost three times longer to build on FreeBSD? This is probably a silly question, but you did recompile the kernel for SMP, right? Have you tuned the FreeBSD kernel? It still ships with a worst-case configuration so that it runs optimally on i386 cpus. :-( Copy GENERIC to something else and remove all but 'cpu i686', rebuild and install. Also, get rid of 'sl', and 'ppp' from the kernel config as that messes up certain things (interrupt masks). Ideally, do a proper cleanup and configure it for your specific hardware (ie: remove all the other ethernet drivers, etc). I'm sure that there are several things that can be done to make this faster (like do parallel builds) but I wanted to get the stock behaviour close before doing the parallel work. A couple of possibilities.. If you want to compare the two side by side, try mounting the freebsd filesystems in async mode, just like linux does by default. In particular, make sure you get /tmp, /var/tmp and wherever your build is. However, I'd recommend softupdates instead of async for longer term stability. It may not be quite as fast, but it should be pretty close to async mode. Thanks, Robin 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Staticaly allocated buffers in library. Is it correct?
:: hold one line from parsed file. Usually it is enough for one line, but ::... : :Yes. System libraries traditionally use statically allocated buffers :because, even now, there is no dynamic equivalent for fgets(). The :closest you can get is to mmap() the file and extract the lines that :way. : :How about fgetln(3)? : :/Mikko :-- : Mikko Työläjä[EMAIL PROTECTED] Sure, if all you want to do is compile your program on a *BSD box. But fgetln() is a stupid function... it doesn't return a nul-terminated string, for example. It's a bad hack. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Staticaly allocated buffers in library. Is it correct?
: fgets() with the proper length limitation, using a statically allocated
: buffer is not a big deal. Most configuration files couldn't have long
: lines and still be legal anyway.
:
:Note that the classical loop
:while (fgets(buf, n, fp) != NULL) {
: tokenize(buf, args...);
: ...
: }
:may have problems if the line is too long, so one needs to detect it by
:looking for the '\n'. if none is found, then one can either abort on error
:or ignore the line. In the latter case, you need to read the remaining chars
:so that the next fgets won't get them.
:
:regards,
:mouss
Yes, but we are talking about simple stupid config files here. Programs
which actually tokenize an input stream typically do not use fgets().
Tokenizers either use [f]lex, [f]getc(), read() (and handle the buffering
themselves), or mmap().
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Build timings - FreeBSD 4.2 vs. Linux
Yup: 4.x sucks at SMP. Try the comparison again with uniprocessor kernels - I expect you'll see a much smaller difference. I rather doubt that SMP has anything whatsoever to do with this. 4.x's SMP implementation may be far from optimal, but I've done a lot of my own uniprocessor vs 2 vs 4 CPU configurations and I've never seen anything as bad as what Robin is describing here. I'm more suspicious of differences in the filesystem mount options. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
Warner Losh writes: | In message [EMAIL PROTECTED] Luigi Rizzo writes: | : We'd also be able to load the kernel out of ROM :-) | : | : the whole issue is the size of the ROM isn't it ? | | Yes. I saw a few datasheets for embedded systems that have 2M or 4M | of flash. Some of that is for the BIOS, but part of it can be used | for a system image. That's a very common thin on other platforms as | well. Is this bits or bytes. The Intel firmware hub can have 4 or 8 Mbits that comes with any Intel 8XX system so with gzip you could fit a bunch of stuff in a standard off the shelf motherboard. Also CMOS memory is increasing and that could be used for some configuration info to be used as non-flash persistant storage such as IP address and such. Also having a small BIOS image like General Software would help save space. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
In message [EMAIL PROTECTED] Doug Ambrisko writes: : Is this bits or bytes. The Intel firmware hub can have 4 or 8 Mbits that : comes with any Intel 8XX system so with gzip you could fit a bunch of : stuff in a standard off the shelf motherboard. Also CMOS memory is : increasing and that could be used for some configuration info to be : used as non-flash persistant storage such as IP address and such. Also : having a small BIOS image like General Software would help save space. Hmmm. I had assumed that it was bytes, but it may have been bits. It was an intel 8xx based design... Still, 2MBytes is enough for at least a kernel and the bare minimum to make a router... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IrDA and FreeBSD
On Mon, Feb 19, 2001 at 08:42:21PM +0100, [EMAIL PROTECTED] wrote: On Fri, 16 Feb 2001, Panagiotis Astithas wrote: I have also finished porting the findchip utility. You can find it attached. It works fine(*) on my -stable machine, but I would like someone to try it out on a -current box, just to be sure. It runs on current: Found SMC FDC37N958FR Controller at 0x3f0, DevID=0x01, Rev. 1 SIR Base 0x3e8, FIR Base 0x290 IRQ = 4, DMA = 3 Enabled: yes, Suspended: no UART compatible: yes Half duplex delay = 3 us This is a Dell Latitude CPi D266XT. If there is any more code to be tested please let me know. rvdp Well, as far as the linux irda-utils port is concerned, I think we have a dead end: the rest of the utilities assume kernel support for IrDA (ioctls, special address families for sockets, etc.). When we have the first layers of the netgraph implementation I will rewrite the necessary utilities. -past To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
COPTFLAGS without -O in /etc/make.conf breaks kernel make
Here's a weirdness in 4.2-RELEASE kernel generation: - Compiling a GENERIC kernel _Without -O optimiser causes a broken make ! - Compiling a GENERIC kernel _With_ -O optimiser compiles OK. Seems weird - perhaps indicative of a problem elsewhere in FreeBSD ? (Optimisers occasionaly break things, but don't normaly _fix_ things !) Can anyone confirm the observation / comment / explain please ? If you wonder why you haven't seen this so far: - Default 4.2 systems compile kernel with -O - I noticed it while experimentaly adding "-pipe" to make variables. How to test: Breaks:echo "COPTFLAGS= -DHalloFromMakeDotConf" /etc/make.conf Breaks:echo "COPTFLAGS=" /etc/make.conf OK:echo "COPTFLAGS= -DHalloFromMakeDotConf -O" /etc/make.conf OK:echo "COPTFLAGS=-O" /etc/make.conf OK:grep -v COPTFLAGS /etc/make.conf /tmp/co;cp /tmp/co /etc/make.conf Followed By: cd /sys/i386/conf;config -r GENERIC cd /sys/compile/GENERIC;make depend;make atomic.o # atomic.o for faster test Breakage: cc -c -DHalloFromMakeDotConf -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -I/usr/include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 -fomit-frame-pointer ../../i386/i386/atomic.c In file included from ../../i386/i386/atomic.c:47: machine/atomic.h: In function `atomic_set_char': machine/atomic.h:106: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_char': machine/atomic.h:107: inconsistent operand constraints in an `asm' - Julian Stacey Unix Consultant - Munich Germany http://bim.bsn.com/~jhs/ Like Linux ?Then also look at FreeBSD with its 4200 packages ! Ihr Rauchen = mein allergischer Kopfschmerz ! Kau/Schnupftabak probieren ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
auth c0e7d351 unsubscribe freebsd-hackers [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
qmail IO--qmail vs postfix competition
I would like to set up this challenge early next week. NOw that I have taken out the IO issue with the mail servers ...already proved postfix did better on I/O so now i want to eliminate that factor to 2 exactly the same machines. I running qmail ...1 running postfix to see which MTA has better sending speed on freebsd. What I have not decided on is benchmark program to use. test will be how many outgoing it can send a sec for each. I welcome benchmark proggies anyone can offer as a solution for this. Much appreciated. Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED]| | make installworld| | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Kernel debugging woes (was Re: Quotas crashing, 4.2-RELEASE, incomplete backtrace ...)
Hi,
First, apologies if this is not the appropriate place to post this. I'm
trying to hack around the kernel, but I'm running in to roadblocks with
gdb. Also, I'm not on this mailing list, so please Cc: me on any replies.
I was having a problem with a 4.2-RELEASE box's quotas. I compiled up a
debugging kernel, rebooted, and did the file copying (see included
freebsd-questions post) until I got it to crash again. Unfortunately,
the core dump didn't leave any useful information for me. Do you guys
know what I need to do to get the parameter info for:
#6 0xc01af64a in dqget ()
#7 0xc01aea6e in getinoquota ()
#8 0xc01b0785 in ufs_chown ()
#9 0xc01b03bb in ufs_setattr ()
#10 0xc01b29e9 in ufs_vnoperate ()
#11 0xc0178f4b in setfown ()
#12 0xc0178fe4 in chown ()
I have the arguments to the syscall2 and trap calls before and after it.
What am I missing? I'm running 'gdb -k kernel.1 vmcore.1' in /var/adm/crash,
I've verified that kernel.1 is a debugging kernel (so I didn't have to load
the symbols from another kernel). I am able to get it to crash, but not
through any one specific command (ie I just have to try to untar files onto
this box until it happens). Any ideas?
- dpk
Hi,
I'm not a list member, so please Cc: me on any responses. Thanks.
Unfortunately I am not able to give too much information here, but I'll
give you what I've got. First, the scenario. I'm copying a bunch of files
(4GB total, no file larger than say 200k though) from a 3.2 box to a
4.2-RELEASE box that has quotas enabled. This had caused the system to crash
a few times so I put in a debugging kernel.
The uname -a:
FreeBSD xxx.xxx.xx.net 4.2-RELEASE FreeBSD 4.2-RELEASE #1: Wed Feb 14 16:23:31
PST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/XX i386
Here's the kgdb backtrace. Note the lack of any information about 'dqget'
or 'getinoquota'. In fact, there was no information in any of the calls
until I entered 'symbol-file kernel.debug'. Anyways, I hope someone here
could point me in the right direction for getting information out of gdb
regarding the dqget/getinoquota calls (this would be MUCH appreciated) -
they're clearly where the problem is:
#0 dumpsys () at ../../kern/kern_shutdown.c:469
#1 0xc0149b53 in boot (howto=256) at ../../kern/kern_shutdown.c:309
#2 0xc0149ee9 in panic (fmt=0xc020bacf "page fault")
at ../../kern/kern_shutdown.c:556
#3 0xc01e205e in trap_fatal (frame=0xea4dccf8, eva=0)
at ../../i386/i386/trap.c:951
#4 0xc01e1d11 in trap_pfault (frame=0xea4dccf8, usermode=0, eva=0)
at ../../i386/i386/trap.c:844
#5 0xc01e18b3 in trap (frame={tf_fs = -364052464, tf_es = -364052464,
tf_ds = -1071972336, tf_edi = -366369856, tf_esi = -948627884,
tf_ebp = -363999864, tf_isp = -36364, tf_ebx = -923190656,
tf_edx = 0, tf_ecx = -364380800, tf_eax = 0, tf_trapno = 12, tf_err = 2,
tf_eip = -1071974838, tf_cs = 8, tf_eflags = 66118, tf_esp = -915035136,
tf_ss = -339913792}) at ../../i386/i386/trap.c:443
#6 0xc01af64a in dqget ()
#7 0xc01aea6e in getinoquota ()
#8 0xc01b0785 in ufs_chown ()
#9 0xc01b03bb in ufs_setattr ()
#10 0xc01b29e9 in ufs_vnoperate ()
#11 0xc0178f4b in setfown ()
#12 0xc0178fe4 in chown ()
#13 0xc01e2286 in syscall2 (frame={tf_fs = 134807599, tf_es = 47,
tf_ds = -1078001617, tf_edi = 134828032, tf_esi = 115,
tf_ebp = -1077937388, tf_isp = -363999276, tf_ebx = 0, tf_edx = 3,
tf_ecx = 0, tf_eax = 16, tf_trapno = 7, tf_err = 2, tf_eip = 134605024,
tf_cs = 31, tf_eflags = 514, tf_esp = -1077937752, tf_ss = 47})
at ../../i386/i386/trap.c:1150
#14 0xc01d6f75 in Xint0x80_syscall ()
#15 0x8050a1d in ?? ()
#16 0x8052c7e in ?? ()
#17 0x8048135 in ?? ()
For now I'm disabling quotas on the box, but this is a less than optimal
solution. Any thoughts?
- dpk
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Creating BSD bootable CD
Greetings... I certainly hope I'm posting this to the right list -- if not, please redirect me accordingly. Thanks. :) I'm interested in taking FreeBSD and putting it on a bootable CD for use in a so-called "appliance". Can anyone recommend a place to start? Specifically, I'm unsure how to create a bootable anything -- so it might be good to start with instructions on how to create a bootable floppy. What files will I need in /dev? Is there a HOWTO anywhere? Thanks. Diz To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Creating BSD bootable CD
At 17:10 19/02/2001 -0700, you wrote: I'm interested in taking FreeBSD and putting it on a bootable CD for use in a so-called "appliance". Can anyone recommend a place to start? I started in the handbook, the section on backups and creating a bootable floppy was invaluable. It's also worth trawling the archives of freebsd-small, in particular look for "tinybsd" which (IIRC) is a configurable script for making a small installation of FreeBSD without going to the lengths that pico goes to, crunchgen etc. This is an eminently doable problem, you have a good half dozen valid approaches that can be taken. Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Creating BSD bootable CD
On Tue, Feb 20, 2001 at 01:16:17PM +1300, David Preece wrote: I started in the handbook, the section on backups and creating a bootable floppy was invaluable. It's also worth trawling the archives of freebsd-small, in particular look for "tinybsd" which (IIRC) is a configurable script for making a small installation of FreeBSD without going to the lengths that pico goes to, crunchgen etc. Thanks. I'm already investigating this stuff. One more question -- is there a list of all valid /dev nodes? Thanks again. :) Diz To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Cvsup and ports
Dear all I recently did a CVSUP on my ports because i wanted to install enlightenment did a make install and recieved the following error. Error: your port uses an old layout. Please update it to match this bsd.port.mk. If you have updated your ports collection via cvsup and are still getting this error, see Q12 and Q13 in the cvsup FAQ ob http://www.polstra.com for further information. Now i have done everything it has said, still get the same error thank you Nigel Taylor
Switching from buildkernel to config seems to recompile the entire kernel
I cvsup'ed my 4.2-stable box and did the usual make buildworld make buildkernel KERNCONF=KNAME where KNAME is the name of theconfig file make installkernel KERNCONF=KNAME make installworld and then rebooted the box. A short while I modified my kernel config to remove sl and ppp. I then did a /usr/sbin/config KNAME This seems to recompile all the modules and the entire kernel even though I expected only a few things to be recompiled and the kernel relinked Or did I do something wrong Regards, Yusuf -- Yusuf Goolamabbas [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: COPTFLAGS without -O in /etc/make.conf breaks kernel make
"Julian Stacey" [EMAIL PROTECTED] writes:
Here's a weirdness in 4.2-RELEASE kernel generation:
- Compiling a GENERIC kernel _Without -O optimiser causes a broken make !
- Compiling a GENERIC kernel _With_ -O optimiser compiles OK.
this question is cyclic. and yes, the kernel *have* to be compiled
w/ -O turned on. sorry, I don't remember why.
if you want yo put something to COPTFLAGS, try something like this :
# the only way I've found to see if I'm in the kernel tree or no !
IS_SYS?=${.CURDIR:M*/sys*}
# make sure COPTFLAGS contains -O for kernel builds.
.if !empty(IS_SYS)
COPTFLAGS= -O
.endif
# add your stuffs...
COPTFLAGS+= -fomit-frame-pointer -fno-builtin
Cyrille.
--
home: mailto:[EMAIL PROTECTED] UNIX is user-friendly; it's just particular
work: mailto:[EMAIL PROTECTED] about who it chooses to be friends with.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Cvsup and ports
-On [20010220 02:30], Nigel Taylor ([EMAIL PROTECTED]) wrote: I recently did a CVSUP on my ports because i wanted to install enlightenment did a make install and recieved the following error. Error: your port uses an old layout. Please update it to match this bsd.port.mk. If you have updated your ports collection via cvsup and are still getting this error, see Q12 and Q13 in the cvsup FAQ ob http://www.polstra.com for further information. Please ask questions like this on the freebsd-questions mailinglist. Now i have done everything it has said, still get the same error You obviously missed to do something. :) Either: 1) make world 2) cd /usr/src/share/mk [after updating it]; make install And that should fix things. -- Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 I'm a child of the air, I'm a witch of the wind... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bug in creating ICMP error messages in FreeBSD4.2
On Mon, Feb 19, 2001 at 08:26:56PM +0100, mouss wrote: At 14:25 19/02/01 +0200, [EMAIL PROTECTED] wrote: Hi, I encountered the following problem in the 4.2 version. In ip_forward, the following lines intend to save the mbuf in case we want to send ICMP error later: mcopy = m_copy(m, 0, imin((int)ip-ip_len, 64)); if (mcopy (mcopy-m_flags M_EXT)) m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); Later on, before sending the ICMP packet we do: if (mcopy-m_flags M_EXT) m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); The problem as I understand it is that the m_copydata and m_copyback, actually do nothing (It just copies from mcopy to itself). I'm speaking from memory, so don't take this for more than it is:) As far as I understand: m_copym copies the mbuf, but if there is external storage, only pointers are copied. so you get two mbuf chains with a common external storage. m_copydata will copy the external storage. that's why there are both m_copym and m_copydata. so while m_copydata(mcopy, (mcopy...)) is surprising, it's not nothing. it copies the data pointed to in mcopy. I wrote this code, and the above said is right. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cvsup and ports
On Tue, Feb 20, 2001 at 06:44:30AM +0100, Jeroen Ruigrok/Asmodai wrote: -On [20010220 02:30], Nigel Taylor ([EMAIL PROTECTED]) wrote: I recently did a CVSUP on my ports because i wanted to install enlightenment did a make install and recieved the following error. Error: your port uses an old layout. Please update it to match this bsd.port.mk. If you have updated your ports collection via cvsup and are still getting this error, see Q12 and Q13 in the cvsup FAQ ob http://www.polstra.com for further information. Please ask questions like this on the freebsd-questions mailinglist. Now i have done everything it has said, still get the same error You obviously missed to do something. :) Either: 1) make world 2) cd /usr/src/share/mk [after updating it]; make install And that should fix things. Bad advice - the ports mk files aren't even in that location any more. The submitter needs to follow the directions in the error message and learn why his cvsup didn't delete some files, and how to fix it. Kris PGP signature
