Re: Suspicious warnings in -CURRENT
In message [EMAIL PROTECTED], "Alexander N. Kabaev" writes: After today's buildworld, I am seeing lots of warning messages from libc like: expr in free(): warning: modified (chunk-) pointer Does it happen to anyone else on this list? I see it in vi(1). Somebody enable the 'A' option of phkmalloc and examine the core. ln -sf A /etc/malloc.conf -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: burncd fixate error
On Fri, 7 Jul 2000, Trevor Johnson wrote: I'm running 4.0-STABLE and my CDR drive can't write the toc. I tried twice and each time I get the following error: fixating CD, please wait.. burncd: ioctl(CDRIOCCLOSEDISK): Input/output error Hi, Nate. I was getting that error too. Unlike you, I have an H-P 8100 like the ones in the messages you directed us to. I did some testing for Soren Schmidt and he got everything working to my satisfaction. Not everything he fixed was specific to the H-P drives. That was around 6 May and the changes did go into 4.0-STABLE. I need to do a make world but my system and kernel are only about 2 weeks old. I booted into NT on the same box and was able to close the disks using Easy CD creator and the same CDRW drive. Still, I'm interested in solving the "Input/output error" problem. Looking at the code in atapi-cd.c and atapi-all.c, it seems like the queued request is getting an EIO. Judging from the behavior when I tried to close a session that was already finished, I can only guess that what the ata driver is sending my drive is different than its expectation for a close disk command. Perhaps the track (ccb[5] = 0) in acd_close_disk() is incorrect for my drive? It may be non-standard; I'm not an ata expert by any means. It returns an error immediately without spinning up the disk so I assume it's a firmware error. If there are no further suggestions, I'll trace into it with ddb and ATAPI_DEBUG. Second, it seems that the "out of sequence" stuff is still in -current. Is that bound to be removed soon? It is perfectly acceptable to insert media with sessions written a previous time and close the disk without writing another session first. Thanks, -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: burncd fixate error
It seems Nate Lawson wrote: Looking at the code in atapi-cd.c and atapi-all.c, it seems like the queued request is getting an EIO. Judging from the behavior when I tried to close a session that was already finished, I can only guess that what the ata driver is sending my drive is different than its expectation for a close disk command. Perhaps the track (ccb[5] = 0) in acd_close_disk() is incorrect for my drive? It may be non-standard; I'm not an ata expert by any means. It returns an error immediately without spinning up the disk so I assume it's a firmware error. If there are no further suggestions, I'll trace into it with ddb and ATAPI_DEBUG. I dont have the spec handy, but it could be the ccb[5] = 0 which IIRC means close last open track, maybe some drives needs the real track number here... Second, it seems that the "out of sequence" stuff is still in -current. Is that bound to be removed soon? It is perfectly acceptable to insert media with sessions written a previous time and close the disk without writing another session first. I have removed all the sequence checks locally, it will go in with the next round of updates... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Suspicious warnings in -CURRENT
Hi, I've had the warnings, too, always after successful search operations in vi and mutt. cvs co -D '06 Jul 2000 12:00' src/lib/libc/regex/ and rebuild/reinstall of libc fixed it. It seems the bug was introduced in regcomp.c 1.20/1.121 and/or engine.c 1.8. /s/Udo (still trying to find out what broke ppp -auto) -- I'd like to meet the man who invented sex and see what he's working on now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Suspicious warnings in -CURRENT
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], "Alexander N. Kabaev" writes: After today's buildworld, I am seeing lots of warning messages from libc like: expr in free(): warning: modified (chunk-) pointer Does it happen to anyone else on this list? I see it in vi(1). Somebody enable the 'A' option of phkmalloc and examine the core. ln -sf A /etc/malloc.conf Ok, everyone, my fault. Fixed. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] jkh _DES: The Book of Bruce has only one sentence in it, and it says "the actual directives of my cult are left as an exercise for the reader. Good luck." EE jkh: does it really include the 'good luck' part? jkh EE: OK, I made that part up. jkh EE: I figured it should sound a bit more cheery than how Bruce initially dictated it to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
David O'Brien wrote:
Sounds good to me actually. Although, should it be ${MACHINE_ARCH}/compile
instead in keeping with the mentioned goal of keeping all MD stuff under
${MACHINE_ARCH}?
I would prefer /sys/compile/ARCH as it makes it easier to make a
symlink to another place. Unless of course we get /usr/obj working for
kernel compiles
Huh? All my kernels created with buildkernel are compiled in /usr/obj.
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
jkh _DES: The Book of Bruce has only one sentence in it, and it says
"the actual directives of my cult are left as an exercise for the
reader. Good luck."
EE jkh: does it really include the 'good luck' part?
jkh EE: OK, I made that part up.
jkh EE: I figured it should sound a bit more cheery than how Bruce
initially dictated it to me.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
This must pass through -arch before any implementation. Remember, not
every committer reads current.
John Baldwin wrote:
sys/
${MACHINE}/ - stay mostly the same, the directories under here
mirror the sys/ directories. E.g. MD bootstrap
code would go in the boot/ subdir
boot/ - formerly sys/boot/${MACHINE}
boot/ - just MI boot code now. Depending on portability
of ARC, possibly move boot/arc under
sys/alpha/boot
Don't touch boot. Nothing in the bootstrap is used by the kernel, and
there's just a few kernel files included by the bootstrap (wrongly,
IMHO). It's made by buildworld instead of buildkernel. Ideally, it
should be taken out of sys/ altogether.
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
jkh _DES: The Book of Bruce has only one sentence in it, and it says
"the actual directives of my cult are left as an exercise for the
reader. Good luck."
EE jkh: does it really include the 'good luck' part?
jkh EE: OK, I made that part up.
jkh EE: I figured it should sound a bit more cheery than how Bruce
initially dictated it to me.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On 08-Jul-00 Daniel C. Sobral wrote:
This must pass through -arch before any implementation. Remember, not
every committer reads current.
The kernel hackers do since they are running current. :)
John Baldwin wrote:
sys/
${MACHINE}/ - stay mostly the same, the directories under here
mirror the sys/ directories. E.g. MD bootstrap
code would go in the boot/ subdir
boot/ - formerly sys/boot/${MACHINE}
boot/ - just MI boot code now. Depending on portability
of ARC, possibly move boot/arc under
sys/alpha/boot
Don't touch boot. Nothing in the bootstrap is used by the kernel, and
there's just a few kernel files included by the bootstrap (wrongly,
IMHO). It's made by buildworld instead of buildkernel. Ideally, it
should be taken out of sys/ altogether.
I disagree. The bootstrap is not used from userland, but is what
loads the kernel. The kernel uses it to get started in other words.
You don't type /boot/loader after the system is loaded, for example.
--
Daniel C. Sobral (8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
SCSI Question
Damon Hammis wrote: The jumpers are set wrong on the card. I had the exact same problem with an aha-1542 and aha-1540 card recently. The docs on the jumpers that you can get on Adaptec's site are kind of cryptic, but the card will work once you get the jumpers placed correctly. Currently I have mine running at irq 9, drq 5 and my jumpers are setup like this: J5 pin 8 jumpered pin 9 the jumper is on one pin J9 pins 2, 6, and 9 are jumpered. I have that configuration running on two systems now working great. Let me know how it goes for ya. --Damon On Fri, 7 Jul 2000, Robert Small wrote: I installed an Adaptec AHA-1542 controller in my system tonight, and hooked up a Sony SDT-5000 tape drive. When I try to boot into FreeBSD (5.0-2511-CURRENT FreeBSD 5.0-2511-CURRENT #4: Thu Jul 6 20:31:41 CDT 2000) I receive: Waiting 15 seconds for SCSI devices to settle down (approximately 30-45 seconds later) (Probe0:aha0:0:0:0) CCB 0xc782c508 (Probe0:aha0:0:0:0) CCB 0xc782c508 aha0: aha_cmd: Timeout waiting for adapter idle ahainitmboxes: Initialization command failed aha0 no longer in timeout (Probe6:aha0:0:6:0) CCB 0xc782c508 (Probe6:aha0:0:6:0) CCB 0xc782c508 aha0: aha_cmd: Timeout waiting for adapter idle ahainitmboxes: Initialization command failed aha0 no longer in timeout And it keeps repeating. I had to remove the card to boot into FreeBSD. The card recognizes the tape drive. Any ideas? Robert Does killing time damage eternity? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message Ok after further investigation, I can get the system to recognize the card,aha0 at port-0x130-0x133 irq 9 drq 5 on isa0aha0: AHA-1542CF FW Rev. F.0 (ID=45) SCSI Host Adapter, SCSI ID 7, 16 CCBsbut when it does, I get all of these errorsWaiting 15 seconds for SCSI devices to settle down(approximately 30-45 seconds later)(Probe0:aha0:0:0:0) CCB 0xc782c508(Probe0:aha0:0:0:0) CCB 0xc782c508aha0: aha_cmd: Timeout waiting for adapter idleahainitmboxes: Initialization command failedaha0 no longer in timeout(Probe6:aha0:0:6:0) CCB 0xc782c508(Probe6:aha0:0:6:0) CCB 0xc782c508aha0: aha_cmd: Timeout waiting for adapter idleahainitmboxes: Initialization command failedaha0 no longer in timeoutand after 30-45 minutes the system will finally get finished probing and giveme a login prompt.So it's not an IRQ problem, in fact, the only way I can make the systemboot-up quickly is to make it share an IRQ. On boot-up, it recognizes andlists the tape drive, but when it comes to probing, it's no joy.Any ideas/suggestions/hints?
Antigen found WScript/Kak.worm virus
Antigen for Exchange found Unknown infected with WScript/Kak.worm virus. The file is currently Deleted. The message, "SCSI Question", was sent from Robert Small and was discovered in IMC Queues\Inbound located at TASC/TASC/NTREMA53. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Antigen found JS/Kak.Worm virus
Antigen for Exchange found Unknown infected with JS/Kak.Worm virus. The file is currently Deleted. The message, "SCSI Question", was sent from Robert Small and was discovered in IMC Queues\Inbound located at Chalmers/MOT/AMAIL. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
etc/rc.d things...
By all means, use start/stop args, but hard link the .sh files into seperate directories or something so that the order can be tweaked.. If all you want is to make sure that shutdown happens in the reverse order of startup, that can be done by reversing the list in rc.shutdown. But how about going a step further, and starting towards a user-friendly configuration process? Instead of being globbed at init time, etc/rc.d is a repository for things that take start/stop arguments. They are symlinked to /etc/init.d with numeric prefixes to control order at initialization time. Likewise, they can be symlinked to /etc/down.d (or shutdown.d) with numeric prefixes to control order at shutdown time. Note that the directories full of symlinks are in /etc, not in /usr/X11R6/etc, etc. The rc.d's in those are also treated as repositories, so you can symlink to files in those asd well. These should save a bit of time at boot; no need to fool with lists of directories, etc. - just one directory. The real work will be adding a one-line description near the start of the file: # Init: 300. Shutdown: -1. Description: Standard smtp (mail) daemon. (indicating that it should be installed as /etc/init.d/300sendmail.sh, and no shutdown installation is necessary). Later, we can add a tool that globs the etc/rc.d directories for files with those lines, and provides a nice visual "system process configuration" tool, allowing you to click on these things to move them back and forth. Some rules regarding the shutdown/startup priorites might be needed for ports. Given some prodding, I might even be talked into taking a crack at the tool (an X tool, maybe) before there's a commitment to supporting this structure. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
On Sat, 8 Jul 2000, Mike Meyer wrote: By all means, use start/stop args, but hard link the .sh files into seperate directories or something so that the order can be tweaked.. If all you want is to make sure that shutdown happens in the reverse order of startup, that can be done by reversing the list in rc.shutdown. But how about going a step further, and starting towards a user-friendly configuration process? Instead of being globbed at init time, etc/rc.d is a repository for things that take start/stop arguments. They are symlinked to /etc/init.d with numeric prefixes to control order at initialization time. Likewise, they can be symlinked to /etc/down.d (or shutdown.d) with numeric prefixes to control order at shutdown time. How about rather then separate directories, you prefix the symlink names with 'S' for startup scripts and 'K' (for "kill") for shutdown scripts. Then, you rename rc.d to rc3.d... Ducks and runs, Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: cvs commit: src/lib/libftpio Makefile (fwd)
On Thu, Jul 06, 2000 at 06:05:50PM -0700, Peter Wemm wrote: This is *not* the same as the a.out behavior which searched directories to find the largest number. ELF uses the symlinks and no searching, which is why ld and ld-elf.so is faster when locating directories and does not need ldconfig or the ld.so.cache. Correct me if I am wrong, ld-elf.so does still need ldconfig. And ld-elf.so does not use the symlink (if it did compat libs would not work). -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sat, 08 Jul 2000 23:32:27 +0900, "Daniel C. Sobral" [EMAIL PROTECTED] said: This must pass through -arch before any implementation. Remember, not every committer reads current. Also remember, not every committer reads arch. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Antigen found WScript/Kak.worm virus
Antigen for Exchange found Unknown infected with WScript/Kak.worm virus. The file is currently Deleted. The message, "Re: SCSI Question", was sent from Josh Paetzel and was discovered in IMC Queues\Inbound located at TASC/TASC/NTREMA53. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new zero copy sockets and NFS patches
[ -arch and -current BCC'ed for wider coverage, please direct followups to -net and/or me ] I have put a new copy of the zero copy sockets and NFS patches, against -current as of early July 8th, 2000, here: http://people.FreeBSD.ORG/~ken/zero_copy/ Feedback would be very welcome, we haven't gotten much response on this yet. Besides being generated against a newer version of -current, the following things have changed in the new patches posted above: - There was a potential panic caused by a bug in the driver side of the header splitting code. The bug only popped up with non-split packets that were long enough to fill up a mbuf. This generally meant IP fragments with a non-zero fragment offset, usually generated by NFS reads. Essentially the length of the initial receive buffer in the mbuf chain was overstated by two bytes, which caused the next mbuf pointer in the next contiguous mbuf to get partially overwritten. That could cause a panic in some situations. Thanks to Drew Gallatin for tracking this one down. - We now do header splitting on IP fragments with a fragment offset greater than 0. Thanks to Justin Gibbs for the idea. - The Tigon driver now loads and unloads cleanly. Thanks to Drew Gallatin for getting this working. - Outgoing IP fragments are now generated in page-multiple chunks if the outgoing interface's MTU is greater than a page in size. This helps receive-side bandwidth NFS significantly, since page flipping techniques can be used. Thanks to Drew Gallatin for this performance enhancement. Also, there are some new benchmark results in the benchmarks section of the web page -- Drew Gallatin has achieved 986Mbps TCP throughput with netperf, and 100MB/sec throughput over NFS. See the web page for a more detailed explanation of the hardware, conditions, etc. For those of you who missed the first message about this code (that went out to -net, -arch and -current), here's a quick list of what is included in the code: - Two sets of zero copy send code, written by Drew Gallatin [EMAIL PROTECTED] and Robert Picco [EMAIL PROTECTED]. - Zero copy receive code, written by Drew Gallatin. - Zero copy NFS code, written by Drew Gallatin. - Header splitting firmware for Alteon's Tigon II boards (written by me), based on version 12.4.11 of their firmware. This is used in combination with the zero copy receive code to guarantee that the payload of TCP or UDP packet is placed into a page-aligned buffer. - Alteon firmware debugging ioctls and supporting routines for the Tigon driver (also written by me). This will help anyone who is doing firmware development under FreeBSD for the Tigon boards. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
