Re: problem with vnconfig -s labels ...
On Sat, 21 Aug 1999, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Bruce Evans writes:
Hmmm, I know this is your code, but are you sure? 8-). My understanding of
dkmodslice() and friends is that they manipulate dev_t entries, but don't
actually initialise them. Since the subr_diskslice code takes a dev_t
dkmodslice() once just manipulated bits in dev_t scalars. Now that dev_t
is a pointer, dkmodslice() has to create something for the pointer to
point to. That something needs to be fully initialised and not created
more than once. The initialisation is apparently incomplete. Multiple
creation is avoided by searching the list of previously created entries.
Now I understand why my memory is filling up with unused dev_t
entries :-). subr_diskslice churns through a not insignificant part
of the per-drive minor number space (32 slices * 8 partitions * {raw,
buffered}), using dkmodslice to create new dev_t's.
yes, this is the remaining sticky issue, and the only cure I know for
this and for the DEVFS issue is to relayer the slice/label processing
out of the device driver entirely. This is now almost possible to do.
Ehem... it was all working before it was ripped out...
that's EXACTLY what SLICE was.
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
Anyway, this module was meant more as a joke, but if you guys like it so much you could vote for putting it in the tree... It's extremely small, so why not? Got my vote. :-) Yes, you have my 7 votes as well (my department thinks it is cool as well. Or at least that is what I think they will think, so I vote for them :-). Cheers, Nick -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with NFSv3 on a CURRENT/SMP system
On Saturday, 21 August 1999 at 22:30:54 -0400, Luoqi Chen wrote: I'm generating a core dump. Please note that as tara is my test machine, I use "INVARIANT" "INVARIANT_SUPPORT". Should I remove them ? It seems that from my reading of the code, the panic would not had happened without INVARIANT. It is these options that caused the panic, you either remove them from the kernel proper, or compile the kld with them. In all likelihood, these options didn't "cause" the panic, they just made another bug more visible. That's what they're there for. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Sync(8) doesn't have any effect on softupdates-enabled filesystem
I do not know if it is bug or feature, but it seems that sync(8) command doesn't really flushing write buffers for softdep enabled f/s. IMHO this behavior is not very friendly for the notebooks and ATX owners because before putting computer into sleep mode OS preferably should try to write as many as possible unflushed buffers to disk (see /etc/rc.suspend). Following is simple showcase for above described (mis)behaviour: bash-2.03# mount ; df; dd if=/dev/zero of=bigfile bs=1m count=50 ; df ; rm bigfile; sync;sync;sync ; sleep 5; df /dev/wd0s2a on / (local, noatime, soft-updates, writes: sync 3 async 913) procfs on /proc (local) Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s2a908319 538529 29712564%/ procfs 440 100%/proc 50+0 records in 50+0 records out 52428800 bytes transferred in 10.366562 secs (5057492 bytes/sec) Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s2a908319 590217 24543771%/ procfs 440 100%/proc Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s2a908319 589769 24588571%/ procfs 440 100%/proc Any comments? Sincerely, Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
On Sat, 21 Aug 1999, Kevin Day wrote: A Anyway, this module was meant more as a joke, but if you guys like it so much you could vote for putting it in the tree... What do you mean "vote"? I was waiting for it to show up on my tree after a cvsup! I hate to keep bringing things like this up, or start a legal war, but this screensaver is more than likely a copyright and/or trademark violation, and bringing it into the source tree may not be a good idea. Yes, lots of people may be making things like this, but it would probably be best to distance FreeBSD itself from such a thing. You can trademark the title "The Matrix", but you can't trademark a common word "matrix". That's the only word I use for the name of the module. As Daniel mentioned, they even can't claim that it's their idea. So I think I can pretty safely import it. Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
On Sun, 22 Aug 1999, Andrzej Bialecki wrote: On Sat, 21 Aug 1999, Kevin Day wrote: I hate to keep bringing things like this up, or start a legal war, but this screensaver is more than likely a copyright and/or trademark violation, and bringing it into the source tree may not be a good idea. Yes, lots of people may be making things like this, but it would probably be best to distance FreeBSD itself from such a thing. You can trademark the title "The Matrix", but you can't trademark a common word "matrix". That's the only word I use for the name of the module. As Daniel mentioned, they even can't claim that it's their idea. So I think I can pretty safely import it. If we wanted to be legally paranoid we would call it the "letter" saver and add as the comment the words "Falling letters like in the movie with red bills" Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
On Sun, 22 Aug 1999, Andrzej Bialecki wrote: On Sat, 21 Aug 1999, Kevin Day wrote: I hate to keep bringing things like this up, or start a legal war, but this screensaver is more than likely a copyright and/or trademark violation, and bringing it into the source tree may not be a good idea. Yes, lots of people may be making things like this, but it would probably be best to distance FreeBSD itself from such a thing. You can trademark the title "The Matrix", but you can't trademark a common word "matrix". That's the only word I use for the name of the module. As Daniel mentioned, they even can't claim that it's their idea. So I think I can pretty safely import it. If we wanted to be legally paranoid we would call it the "letter" saver and add as the comment the words It's not just the name "Matrix" though. Make a screen saver of the Superman 'S' logo, and see how quickly a certain comic book company comes after you. :) Making a derivative work based on something that was in a movie probably is a copyright violation. Warner Brothers could easily say that you've copied an element from their movie (even if it's not the entire movie), and even go so far as to get a judge to get any CD-ROM distributors of FreeBSD to recall all unsold CD's, and destroy them. As for the trademark issue, it doesn't have to be a name to be trademarked. Logos, effects, and even sounds can be trademarked. I'm really not trying to be annoying about things like this, but I already had to fight for the ability to be able to use FreeBSD at work, after they discovered other copyright/trademark violations in the source tree.. (Trek, etc). "If they'll steal things here, how do we know the entire kernel isn't stolen from somewhere else?" Yes, it's silly logic, but they do sort of have a point. We're selling a product with FreeBSD embedded in it. Should some copyright/patent holder come up proving that the VM system is his, and FreeBSD stole it from him, they could legally force us to recall every machine we've sold, and replace it with non-infringing materials. Obviously we're not shipping 'trek' on our system, and wouldn't include the matrix saver anyway, but I (for completely selfish reasons) would like to keep FreeBSD distanced from anything that could possibly be infringing on anything, and let you download it from somewhere else if you want it. :) Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.hxdr_subs.h)
On Sat, 21 Aug 1999, Matthew Dillon wrote: : Well, the issue with converting many of the macros to inline functions : is with the embedded goto's and references to variables defined outside : the macros. Converting them to functions would basically require : rewriting a huge chunk of NFS code. : :My working kernel runs with a few strategic NFS macros being converted :to functions, and the size improvement is about 50K or so (maybe more!!!) : :John If you want to port some of it in that part of the source tree will be available in a month or two, depending on how quickly the other stuff in my queue gets committed. I've got two patch sets currently under test related to other NFS issues and a third one in the wings. Hey, speaking of NFS ... I'm working on optimizing the commit rpc and I noticed something interesting. The commit rpc includes an offset and a length field. Does anyone know why our NFS clients are sending a separate RPC for each 8K buffer? If the dirty space is contiguous across a number of buffers we should be able to send a *SINGLE* commit rpc to the server. That would greatly reduce system overhead on both the client and server when writing a large file over NFS. This would seem to be an almost free optimization that would mesh extremely well with the nfsrv_commit optimizations I'm making right now. At the moment I can saturate a 100BaseTX with NFS writes and get 10 MBytes/sec to the platter on the server, but the cpu required on both the client and server to do that is well over 60% of a Pentium III-450. I worked on reducing the number of commit rpcs a while ago. The best I could come up with was to use the B_CLUSTEROK flag to get vfs_bio.c to aggregate several buffers together to make a single large commit. Does that code still work? It made a big difference to the number of commit rpcs at the time. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: apm problems.
Mitsuru IWASAKI wrote:
Ah, If you want to reject the standby request from BIOS while the
system is active, then apmd would be useful. You can configure it like
this:
in /etc/apmd.conf:
apm_event PMEV_STANDBYREQ {
reject;
Thanks.
I guess your disks are still in a SLEEP after a resume or
I/O interrupts were lost during suspend/resume or something.
Anyone suggestions?
ata0: master: setting up WDMA2 mode on PIIX3/4 chip OK
ad0: QUANTUM FIREBALL_TM1280A/A6B.2D00 ATA-? disk at ata0 as master
ad0: 1222MB (2503872 sectors), 2484 cyls, 16 heads, 63 S/T, 512 B/S
ad0: piomode=4, dmamode=2, udmamode=-1
ad0: 16 secs/int, 0 depth queue, DMA mode
If your problem is related with disks, have you tried wd device driver
instead of ata?
wdc0 at port 0x1f0-0x1f7 irq 14 on isa0
wdc0: unit 0 (wd0): QUANTUM FIREBALL_TM1280A
wd0: 1222MB (2503872 sectors), 2484 cyls, 16 heads, 63 S/T, 512 B/S
wdc0: unit 1 (atapi): MATSHITA CR-583/AS10, removable, accel, dma,
iordis
wcd0: drive speed 1378KB/sec, 128KB cache
wcd0: supported read types: CD-R, CD-DA
wcd0: Audio: play, 256 volume levels
wcd0: Mechanism: ejectable tray
wcd0: Medium: no/blank disc inside, unlocked
wdc1 at port 0x170-0x177 irq 15 on isa0
wdc1: unit 0 (wd2): QUANTUM FIREBALL ST2.1A
wd2: 2014MB (4124736 sectors), 4092 cyls, 16 heads, 63 S/T, 512 B/S
now, after resuming from apm -z, theres a pause then the message:
wd2: interrupt timeout (status 58 rdy, seekdone, drq error1 no_dam)
wd2: timeout () DMA status 4
and things seem to work ok again.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
At 06:44 PM 8/22/99 +0200, Andrzej Bialecki wrote: On Sun, 22 Aug 1999, Kevin Day wrote: [trademark violation warning] Ok, maybe you have a point - I dont know, I'm not a lawyer. But with this line of reasoning they could claim that anything using falling letters effect on your screen partly violates they trademarked special effect, which is silly. What can we do, then? Why don't we ask them politely if it's ok? Andrzej Bialecki While I can't speak for how Warner Brothers' lawyers are, as a general rule.. "It's much easier to say No, than it is to say Yes, and regret it later." If you ask, you'll probably get a No. It's not that you made a falling letter effect, it's that you made a falling letter effect to copy the effect in the movie, and it does look very much like what's in the movie. That could be called willful infringement. While I doubt they'd stop a fan from making something like this, (I don't know this for a fact though, see what Paramount did with Trek sites before, or Mattel with Barbie) they may be more led to taking action against a product being sold that contains it. (FreeBSD being sold by Walnut Creek and others). If this is distributed as a fan based thing, the worst they'd likely do is say "Take it down.". If this is on thousands of FreeBSD cd's, it could become a financial problem if they want to take it far enough. This is just my opinion though, and not to be used as legal advice for anyone. I just don't want FreeBSD to become a ball of intellectual property infringements. :) Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
On Sun, 22 Aug 1999, Kevin Day wrote: On Sun, 22 Aug 1999, Andrzej Bialecki wrote: On Sat, 21 Aug 1999, Kevin Day wrote: I hate to keep bringing things like this up, or start a legal war, but this screensaver is more than likely a copyright and/or trademark violation, and bringing it into the source tree may not be a good idea. Yes, lots of people may be making things like this, but it would probably be best to distance FreeBSD itself from such a thing. You can trademark the title "The Matrix", but you can't trademark a common word "matrix". That's the only word I use for the name of the module. As Daniel mentioned, they even can't claim that it's their idea. So I think I can pretty safely import it. If we wanted to be legally paranoid we would call it the "letter" saver and add as the comment the words It's not just the name "Matrix" though. Make a screen saver of the Superman 'S' logo, and see how quickly a certain comic book company comes after you. The "S" logo? We are not dealing with the "S" logo, we are dealing with a screensaver that displays an ordinary rotation S on the screen. :) Making a derivative work based on something that was in a movie probably is a copyright violation. Warner Brothers could easily say that you've Is it derived from the movie? Says who? It rather reminds me of an old virus that made letters fall on the screen... copied an element from their movie (even if it's not the entire movie), and even go so far as to get a judge to get any CD-ROM distributors of FreeBSD to recall all unsold CD's, and destroy them. As for the trademark issue, it doesn't have to be a name to be trademarked. Logos, effects, and even sounds can be trademarked. Uhhh Depends on where. Sounds can't be trademarked everywhere. I'm really not trying to be annoying about things like this, but I already had to fight for the ability to be able to use FreeBSD at work, after they discovered other copyright/trademark violations in the source tree.. (Trek, etc). "If they'll steal things here, how do we know the entire kernel isn't They aren't violations until the judge says so. If it is not true in the legalsystem you are in, I suggest moving to another one. stolen from somewhere else?" Yes, it's silly logic, but they do sort of have a point. We're selling a product with FreeBSD embedded in it. Should some copyright/patent holder come up proving that the VM system is his, and FreeBSD stole it from him, they could legally force us to recall every machine we've sold, and replace it with non-infringing materials. Obviously we're not shipping 'trek' on our system, and wouldn't include the matrix saver anyway, but I (for completely selfish reasons) would like to keep FreeBSD distanced from anything that could possibly be infringing on anything, and let you download it from somewhere else if you want it. :) Kevin Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sync(8) doesn't have any effect on softupdates-enabled filesystem
:I do not know if it is bug or feature, but it seems that sync(8) command :doesn't really flushing write buffers for softdep enabled f/s. IMHO this :behavior is not very friendly for the notebooks and ATX owners because :before putting computer into sleep mode OS preferably should try to :write as many as possible unflushed buffers to disk (see :/etc/rc.suspend). Following is simple showcase for above described :(mis)behaviour: It's a bug, one that I've brought up with Kirk. The problem is that the structures used internally by softupdates are not condusive to doing a hard-sync. This creates other problems, too -- when the kernel bawrite()'s a buffer softupdates may write something different to the disk and then re-dirty the buffer, so performance will drop if the buffer cache becomes saturated and you are doing a lot of ops that require softupdates-related buffer rewriting. Kirk has been looking for a solution. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
gcc back?
I'm just wondering but I noticed when I cvsupped a few minutes ago that gcc is back in the source tree. I was wondering if there were plans to keep gcc in the source now. Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sync(8) doesn't have any effect on softupdates-enabled filesystem
In message [EMAIL PROTECTED], Matthew Dillon writes: It's a bug, one that I've brought up with Kirk. The problem is that the structures used internally by softupdates are not condusive to doing a hard-sync. I gues sync needs to set a flag which makes the sync'er go through all buckets with no delay and then wake the sync'ing process afterwards... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc back?
I'm just wondering but I noticed when I cvsupped a few minutes ago that gcc is back in the source tree. I was wondering if there were plans to keep gcc in the source now. If you are tracking -current, you should be reading the commit messages. egcs has become gcc. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sync(8) doesn't have any effect on softupdates-enabled filesystem
:structures used internally by softupdates are not condusive to doing a :hard-sync. : :I gues sync needs to set a flag which makes the sync'er go through all :buckets with no delay and then wake the sync'ing process afterwards... : :-- :Poul-Henning Kamp FreeBSD coreteam member It won't help. What needs to happen is for the VOP_FSYNC in ffs to figure out buffer-buffer dependancies - something which is not being recorded in the structures currently. Kirk indicated to me in our discussions a few weeks ago that it would be relatively easy to figure out *some* of the dependancies and write the buffers out in the correct order, but not all of them. There are dependancies which are much more complex and not simply a matter of writing buffers out in any particular order. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sync(8) doesn't have any effect on softupdates-enabled filesystem
: :But the buffer to buffer dependencies are already recorded in the :sequence on the "sync-wheel" which the syncer daemon runs through, :isn't it ? : :-- :Poul-Henning Kamp FreeBSD coreteam member :[EMAIL PROTECTED] "Real hackers run -current on their laptop." Only very roughly. The syncer wheel tries to order whole vnodes amoungst whole vnodes, making the distinction between vnode types VDIR, VBLK, and VREG. This helps reduce the amount of rewriting that softupdates must accomplish, but it only orders buffer dependancies in a very rough fashion. Within the dirtyblkhd list in each vnode, which lists the dirty buffers, we also do a rough ordering. If you look at reassignbuf() in vfs_subr.c you will see how this works. We attempt to sort blocks in the dirtyblkhd list and we place meta data (negative block numbers) at the end of the list instead of at the head. The idea here is to write out data blocks before writing out the meta-data. If the meta-data were to be written out first softupdates would step in and rearrange the meta-data being written to the physical media to take into account the fact that the data blocks have not yet been written. In otherwords, the metadata buffer would remain dirty. But both of these ordering cases are only rough approximations designed h to reduce the amount of work that softupdates must accomplish. Softupdates understands the concept of filesystem dependancies such as, for example, a directory entry depending on an inode. but softupdates does *NOT* directly understand 'macro' buffer-buffer dependancies so there is no 'chain of buffers' for the flushing code to follow to get things in the right order. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sync(8) doesn't have any effect on softupdates-enabled filesystem
So what do we do when we halt or reboot ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc back?
I'm just wondering but I noticed when I cvsupped a few minutes ago that gcc is back in the source tree. I was wondering if there were plans to keep gcc in the source now. If you are tracking -current, you should be reading the commit messages. egcs has become gcc. I must have accidentally missed that one. Especially since egcs is still in my source tree after cvsupping. Ken Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sync(8) doesn't have any effect on softupdates-enabled filesystem
yes and no. the sync wheel indicates buffers to wrrite in an order that will probably ensure that early dependencies are satisfied before later ones, however even after being written, a buffer might have remaining unsatisfied dependencies that required that teh on disk and in momory version sstill do not match. In this case it will have been rewritten back to the sync-wheel further in the future. What one can do is acellerate teh speed that teh daemon goes around the wheel, but you must never go faster than the disks can write, because if you queue a block that depends on something that hasn't got to disk yet, you will be queueing the old version. On Sun, 22 Aug 1999, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Matthew Dillon writes: :structures used internally by softupdates are not condusive to doing a :hard-sync. : :I gues sync needs to set a flag which makes the sync'er go through all :buckets with no delay and then wake the sync'ing process afterwards... : :-- :Poul-Henning Kamp FreeBSD coreteam member It won't help. What needs to happen is for the VOP_FSYNC in ffs to figure out buffer-buffer dependancies But the buffer to buffer dependencies are already recorded in the sequence on the "sync-wheel" which the syncer daemon runs through, isn't it ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sync(8) doesn't have any effect on softupdates-enabled filesystem
So what do we do when we halt or reboot ? We unmount the file system. dounmount() calls VFS_SYNC() with the MNT_WAIT flag, and then (for ffs) ffs_unmount() calls ffs_flushfiles() or softdep_flushfiles(). I'm not sure why the latter is necessary. I don't understand this problem. sync() intentionally calls VFS_SYNC() with the MNT_NOWAIT flag to stop it from waiting for i/o to complete. It's just an implementation quirk that i/o is more likely to have completed when sync() returns for the non- softdep case. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Docs blows up make release
[ cc'd to -current ]
On Sat, Aug 21, 1999 at 07:54:51PM -0400, jack wrote:
mode ugly monolingual American
Will support for building release docs in English only be
revived?
/mode
For the immediate future, it looks like it will -- it seems as though
we don't have the man power to make the necessary changes to sysinstall
to support "installing the docs as packages", so I'm going to fix up
src/release/Makefile as necessary to cope with the new directory structure.
I will find this much, much, much easier if someone could e-mail me a
directory listing of what the contents of ${RD}/trees looks like after
the src/release/Makefile:doc.1 target has been run. This saves me having
to scrounge together the necessary resources to actually be able to build
a release on my home system.
It would also help if someone who knows the release build stuff could
let me know whether or not this directory structure is simply splatted
on to the disk at install time and then left alone, or whether any other
parts of the install process rely on being able to find the files in
particular locations under /usr/share/doc.
Many thanks,
N
--
[intentional self-reference] can be easily accommodated using a blessed,
non-self-referential dummy head-node whose own object destructor severs
the links.
-- Tom Christiansen in [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc back?
Chris Piazza wrote: On Sun, Aug 22, 1999 at 03:07:44PM -0400, Kenneth Wayne Culver wrote: I'm just wondering but I noticed when I cvsupped a few minutes ago that gcc is back in the source tree. I was wondering if there were plans to keep gcc in the source now. If you are tracking -current, you should be reading the commit messages. egcs has become gcc. I must have accidentally missed that one. Especially since egcs is still in my source tree after cvsupping. There wasn't one. At least not here. I remember when egcs was imported it was the same thing. Don't sweat, it's just been "un-deleted". David will be doing the transition over the next week or so via several steps so we don't loose history. Give him a bit of room to move while doing it, it's quite fiddly. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sync(8) doesn't have any effect on softupdates-enabled filesystem
: :So what do we do when we halt or reboot ? : :We unmount the file system. dounmount() calls VFS_SYNC() with the :MNT_WAIT flag, and then (for ffs) ffs_unmount() calls ffs_flushfiles() :or softdep_flushfiles(). I'm not sure why the latter is necessary. : :I don't understand this problem. sync() intentionally calls :VFS_SYNC() with the MNT_NOWAIT flag to stop it from waiting for :i/o to complete. It's just an implementation quirk that i/o is :more likely to have completed when sync() returns for the non- :softdep case. : :Bruce In the non-softdep case, when you write out a buffer, the buffer is truely written out and becomes clean. In the softupdates case, when you write out a buffer softupdates may *redirty* it. The buffer may *NOT* become clean. Specifically, if the buffer contains dependancies softupdates will write the non-dependant version of the buffer rather then the actual contents of the buffer, and then re-dirty the buffer as an indication that the buffer still has dependancies and cannot be marked clean yet. When you sync() with MNT_NOWAIT, a single pass through the dirty buffers occurs. In a non-softupdates filesystem all the buffers will be clean after this pass. In a softupdates filesystem many of the buffers will remain dirty after this pass - mainly when you have done complex directory interactions with file creation and deletion. When you umount, the sync code cycles through the dirty buffer list at full speed and keeps cycling until there are no dirty buffers left. Depending on how complex the dependancy lists are, this can take a very short time or it can take a very long time. It can be very inefficient, in fact, and write the same buffer out many times before all the related dependancies are flushed out. In fact, we had to fix a number of infinite-loop cases with the VOP_FSYNC code for ffs on softupdates-mounted partitions. This is why the B_SCANNED flag had to be added to the scanning code in ffs_fsync(). Changes also had to be made to getnewbuf(), the syncer (Kirk's circle queue), and other places. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
problem with the ata driver
Hi there, hi Soren, First of all, the dump. Preloaded elf kernel "kernel" at 0xc0302000. Intel Pentium detected, installing workaround for F00F bug Probing for PnP devices: npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: found APM BIOS version 1.2 pcib0: PCI host bus adapter on motherboard pci0: PCI bus on pcib0 chip0: Intel 82437VX PCI cache memory controller at device 0.0 on pci0 isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0 ata-pci0: Intel PIIX3 IDE controller at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ahc0: Adaptec aic7880 Ultra SCSI adapter irq 3 at device 9.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs vga-pci0: S3 Trio graphics accelerator irq 11 at device 11.0 on pci0 fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 9 at device 12.0 on pci0 fxp0: Ethernet address 00:90:27:3d:36:f9 devclass_alloc_unit: npx0 already exists, using next available unit number isa0: ISA bus on motherboard fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive at fdc0 drive 0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: Generic ISA VGA on isa0 sc0: System console on isa0 sc0: VGA color 16 virtual consoles, flags=0x0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppb0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: Hewlett-Packard HP LaserJet 6L/0101.01 PRINTER HP ENHANCED PCL5,PJL plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 isic0 at port 0x268 irq 5 flags 0x7 on isa0 isic0: USRobotics Sportster ISDN TA intern isic0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) (Addr=0xc268) isic0: HSCX 82525 or 21525 Version 2.1 (AddrA=0x268, AddrB=0x4268) pca0 at port 0x40 on isa0 pca0: PC speaker audio driver ed0 at port 0x300-0x31f iomem 0xd8000-0xdbfff irq 10 on isa0 ed0: address 00:00:c0:37:f2:d0, type SMC8216/SMC8216C (16 bit) ep0: not probed (disabled) ata0: unwanted interrupt 1 status = ff i4b: ISDN call control device attached i4bisppp: 4 ISDN SyncPPP device(s) attached i4bctl: ISDN system control port attached i4bipr: 4 IP over raw HDLC ISDN device(s) attached (VJ header compression) i4btel: 2 ISDN telephony interface device(s) attached i4brbch: 4 raw B channel access device(s) attached i4btrc: 4 ISDN trace device(s) attached acd0: GCD-R520B/1.1 CDROM drive at ata0 as master acd0: drive speed 0KB/sec acd0: supported read types: acd0: Mechanism: caddy acd0: Medium: CD-ROM unknown medium Waiting 15 seconds for SCSI devices to settle changing root device to da0s1a da0 at ahc0 bus 0 target 1 lun 0 da0: IBM DCAS-32160W S65A Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit) da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da1 at ahc0 bus 0 target 2 lun 0 da1: HP 4.26GB F 80-1201 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4067MB (8330542 512 byte sectors: 255H 63S/T 518C) As you can see the drive is not properly detected. Note the "ata0: unwanted interrupt 1 status = ff" Any clue? The drive was running flawlessly with the old wdc driver and with various primary releases of the new ata driver (some, not all). Nicholas -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with NFSv3 on a CURRENT/SMP system
According to Greg Lehey: In all likelihood, these options didn't "cause" the panic, they just made another bug more visible. That's what they're there for. That's what I'm thinking but compiling NFS into the kernel "fixed" my panic. The weird part is that I'm still using INVARIANT. I don't see why the condition is not met when compiling all these together and is when using the kld. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
According to Narvi: "Falling letters like in the movie with red bills" Pill :) That very important... The screensaver triggered me to see the movie again. A. I love it. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
On Sun, 22 Aug 1999, Ollivier Robert wrote: According to Narvi: "Falling letters like in the movie with red bills" Pill :) That very important... The screensaver triggered me to see the movie again. A. I love it. Yeah, it's gotta be the perfect hacker's movie. Maybe we *should* go approach the producers? I have gone to that movie several times, and I keep on enjoying it, so this is GOOD PR for them. +--- Chuck Robey | Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Docs blows up make release
For the immediate future, it looks like it will -- it seems as though we don't have the man power to make the necessary changes to sysinstall to support "installing the docs as packages", so I'm going to fix up src/release/Makefile as necessary to cope with the new directory structure. I also should note that there's nothing to preclude supplying the docs as packages *also*, assuming that they appear in the INDEX and get built as part of Satoshi's ports build. Then the user could have at least the option of visiting the packages menu and selecting docsets, if not in english then at least all the other languages (we could leave english excluded for as long as it remains "part of the system" in the doc dist). - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
Maybe we *should* go approach the producers? I have gone to that movie several times, and I keep on enjoying it, so this is GOOD PR for them. Tell them there will be a reference to the movie web site or something. ;-) Or tell them that the URL to the website appears once in a while in the mishmash, sublimal advertisements. Just make sure you speak to the marketing drones at that point :-) Nick -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PicoBSD major update
Hello, I'm committing an update of the PicoBSD code tree that should allow it to build on -STABLE and take advantage of loader's new features. Luigi Rizzo did the majority of the work, I debugged. I have use of this code thus why I'm sponsoring this commit. Significant changes include: . Now builds on -STABLE (-CURRENT is broken due to bugs) . etc directory contents centrilized in /floppy.tree instead of each type directory (can exclude override as desired) . Removed extraneous language files (lang files for rc really necessary?) . dialog-based build tool . MFS image loads as a mfs_root module instead of compiled into kernel A MFC is pending. Please send commit-related complaints to me, and other queries either to the list or both of us. Luigi is heading for the US later this week and may be out of email range. Thanks! Doug White Internet: [EMAIL PROTECTED]| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
On Sun, Aug 22, 1999 at 11:46:14PM +0200, Nick Hibma wrote: Tell them there will be a reference to the movie web site or something. ;-) Or tell them that the URL to the website appears once in a while in the mishmash, sublimal advertisements. Just make sure you speak to the marketing drones at that point :-) and also ask them for a little donation? : bye -- Sebastian Soenksen ; [EMAIL PROTECTED] ; diz@IRCNet ; pgpkey available commercial use of emailadresse not allowed ; http://www.planlos.hanse.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patches available (was Re: NFS HEADS UP)
When copying over (FreeBSD client) the multipatch from a Linux (2.2.11)
box before the patch I got this garbage in the file, -current as of 4am
this morning. gzip'ed version has bad crc's. Went the other way and it
worked fine (Linux client), this is v2 via amd.
/etc/amd.conf:
**
/defaults fs:=${autodir}/${rhost}/root/${rfs};opts:=nosuid,nodev
* rhost:=${key};type:=host;rfs:=/
Update: after reboot with new kernel I get the same thing. It's
reproducible. It doesn't happen between linux boxen and doesn't happen
on loopback mounts.
-Rob
Index: nfs/nfs_serv.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_serv.c,v
retrieving revision 1.83
diff -u -r1.83 nfs_serv.c
--- nfs_serv.c 1999/07/29 21:42:57 1.83
+++ nfs_serv.c 1999/08/21 07:17:06
@@ -96,6 +96,7 @@
#include sys/stat.h
#include sys/kernel.h
#include sys/sysctl.h
+#include sys/buf.h
#include vm/vm.h
#include vm/vm_extern.h
@@ -115,6 +116,8 @@
#define nfsdbprintf(info)
#endif
+#define MAX_COMMIT_COUNT (1024 * 1024)
+
nfstype nfsv3_type[9] = { NFNON, NFREG, NFDIR, NFBLK, NFCHR, NFLNK,
NFSOCK,
NFFIFO, NFNON };
#ifndef NFS_NOSERVER
@@ -133,6 +136,10 @@
static int nfs_async;
SYSCTL_INT(_vfs_nfs, OID_AUTO, async, CTLFLAG_RW, nfs_async, 0, "");
+static int nfs_commit_blks;
+static int nfs_commit_miss;
+SYSCTL_INT(_vfs_nfs, OID_AUTO, commit_blks, CTLFLAG_RW,
nfs_commit_blks, 0, ""
);
+SYSCTL_INT(_vfs_nfs, OID_AUTO, commit_miss, CTLFLAG_RW,
nfs_commit_miss, 0, ""
);
static int nfsrv_access __P((struct vnode *,int,struct ucred *,int,
struct proc *, int));
@@ -3624,11 +3631,73 @@
goto nfsmout;
}
for_ret = VOP_GETATTR(vp, bfor, cred, procp);
- if (vp-v_object
- (vp-v_object-flags OBJ_MIGHTBEDIRTY)) {
+
+ if (cnt MAX_COMMIT_COUNT) {
+ /*
+* Give up and do the whole thing
+*/
+ if (vp-v_object
+ (vp-v_object-flags OBJ_MIGHTBEDIRTY)) {
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@requested range. Note: we are assuming that
Matthew Dillon wrote:
Ok, I have put up the current patch set -- for patching against CURRENT
only - on my web site.
http://www.backplane.com/FreeBSD4/
They contain a bit more then the NFS stuff, but it's all related to
performance. It would take me too long to try to separate them out
(this is what happens when things back-up, sorry!).
The patches have been tested only somewhat and the one that fixes
nfssrv_commit() is not 100% complete - it doesn't sync-out the file
metadata yet, only the specific data blocks being requested by the
commit rpc.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patches available (was Re: NFS HEADS UP)
:When copying over (FreeBSD client) the multipatch from a Linux (2.2.11)
:box before the patch I got this garbage in the file, -current as of 4am
:this morning. gzip'ed version has bad crc's. Went the other way and it
:worked fine (Linux client), this is v2 via amd.
:
:...
:Update: after reboot with new kernel I get the same thing. It's
:reproducible. It doesn't happen between linux boxen and doesn't happen
:on loopback mounts.
:
:-Rob
Same thing before and after the patch, so the patch itself is not the
problem? Then this is a preexisting bug of some sort.
Hmm. The question is how to focus on the bug. The FreeBSD 'cp' command
uses mmap(). On the linux box 'cp' the file to a different name and then
try using 'cat' on the freebsd client to read it, redirected to a
localfile. Then see if the local file is corrupted. Copy the file to
a different name on the linux box again, and this time use 'cp' on the
freebsd box to see if you get the corruption. ( the act of copying the
file on the linux box to a different name removes any possibility of
it being already-cached on the freebsd client when we run our test ).
linux cp multipatch-1.diff test1
fbsd cat remotelinuxbox/test1 local1
fbsd (check for corruption in local1)
linux cp multipatch-1.diff test2
fbsd cp remotelinuxbox/test2 local2
fbsd (check for corruption in local2)
If the corruption occurs with 'cp' but not 'cat' then we know it has
something to do with mmap. If it occurs with both commands then the
corruption may be a bug on the linux server.
If you can repeat the corruption using the above test the next step is
to try to determine whether the bug is in the linux server or the freebsd
client. I kinda suspect the linux box because there are no cache
interaction issues w/ the freebsd box if the client is simply reading the
file.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:+ if (vp-v_object
:+ (vp-v_object-flags OBJ_MIGHTBEDIRTY)) {
:
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@requested range. Note: we are assuming that
:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patches available (was Re: NFS HEADS UP)
: fbsd cat remotelinuxbox/test1 local1 Oops. I obviously meant to redirect the output for the cat's: fbsd cat remotelinuxbox/test1 local1 .. etc... -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
libalias or libnat. Vote ?
This topic was discussed last January - should libalias be renamed to libnat ? As of a few days ago, ppp(8) supports the -nat flag (as well as the -alias flag for backwards compatibility), however, it's not clear that we really want to go the whole hog and change the library name interface too. If it's changed, things will make more sense IMHO, however it'll make life difficult for applications that already use libalias (if the change is made, do we need a libalias library with stubs into libnat ?) Votes ? Silence == no change. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libalias or libnat. Vote ?
As of a few days ago, ppp(8) supports the -nat flag (as well as the -alias flag for backwards compatibility), however, it's not clear that we really want to go the whole hog and change the library name interface too. I've been on both sides of this issue, to be sure, but I have to say that looking at it now, I can't see any reason to change the actual name of the library right now unless we're also going to go whole-hog and change the API functions to PacketNATFoo() and such, something that would only really make sense (or be worth the effort, anyway) if we had a bunch of improvements to bring in at the same time, e.g. a significant rearchitecting effort. If we don't have anything like that planned, then simply changing the user visible flags and man pages to strongly encourage use of -nat style options rather than the deprecated -alias ones will probably be enough of a step in the right direction for now. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with NFSv3 on a CURRENT/SMP system
On Sun, Aug 22, 1999 at 10:24:33PM +0200, Ollivier Robert wrote: That's what I'm thinking but compiling NFS into the kernel "fixed" my panic. The weird part is that I'm still using INVARIANT. I don't see why the condition is not met when compiling all these together and is when using the kld. As I understand it, compiling the kernel with INVARIENTS makes it uncompatable with modules compiled without INVARIENTS. The reason is probably to do with inline functions and the like - I see some inline functions in vm_zone.h which set and check certain variables only when INVARIANTS is defined. The variables seem also to be set and checked in vm_zone.c. So I suppose if you use an inline function to initialise something without INVARIENTS in a module, and then it is checked by the kernel which did have INVARIENTS defined things go boom... David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patches available (was Re: NFS HEADS UP)
linux cp multipatch-1.diff test1
fbsd cat test1
cat: test1: RPC struct is bad
fbsd cp test1 /tmp
fbsd cat test1
SNIP
+ (vp-v_object-flags OBJ_MIGHTBEDIRTY)) {
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@requested range. Note: we are assuming that
SNIP
Doesn't happen between two linux boxen. (Both 2.2.11-NFSv3)
-Rob
Matthew Dillon wrote:
:When copying over (FreeBSD client) the multipatch from a Linux (2.2.11)
:box before the patch I got this garbage in the file, -current as of 4am
:this morning. gzip'ed version has bad crc's. Went the other way and it
:worked fine (Linux client), this is v2 via amd.
:
:...
:Update: after reboot with new kernel I get the same thing. It's
:reproducible. It doesn't happen between linux boxen and doesn't happen
:on loopback mounts.
:
:-Rob
Same thing before and after the patch, so the patch itself is not the
problem? Then this is a preexisting bug of some sort.
Hmm. The question is how to focus on the bug. The FreeBSD 'cp' command
uses mmap(). On the linux box 'cp' the file to a different name and then
try using 'cat' on the freebsd client to read it, redirected to a
localfile. Then see if the local file is corrupted. Copy the file to
a different name on the linux box again, and this time use 'cp' on the
freebsd box to see if you get the corruption. ( the act of copying the
file on the linux box to a different name removes any possibility of
it being already-cached on the freebsd client when we run our test ).
linux cp multipatch-1.diff test1
fbsd cat remotelinuxbox/test1 local1
fbsd (check for corruption in local1)
linux cp multipatch-1.diff test2
fbsd cp remotelinuxbox/test2 local2
fbsd (check for corruption in local2)
If the corruption occurs with 'cp' but not 'cat' then we know it has
something to do with mmap. If it occurs with both commands then the
corruption may be a bug on the linux server.
If you can repeat the corruption using the above test the next step is
to try to determine whether the bug is in the linux server or the freebsd
client. I kinda suspect the linux box because there are no cache
interaction issues w/ the freebsd box if the client is simply reading the
file.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:+ if (vp-v_object
:+ (vp-v_object-flags OBJ_MIGHTBEDIRTY)) {
:
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@requested range. Note: we are assuming that
:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: help
Tattr wrote: Hi i wonder if you can help me please? my friend has just bought a cam for his pc its a webstar and we are having a problem we have loaded the cd and the cam wont work cos it keeps saying video capture devise missing i have the same cam as he and instakked it the same way i went into my control panel to multiemedia and went to video and under it was ppc2 his does not have anything under his i think we need to download this driver (if thats what it is) can you please tell me where i get it or what to do? As you can tell neither of us know too much about computers. Thanks for any help you can give. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message aye!? Is this someones idea of a joke... im laughing.. honest HANNNG ON... -current mailing list.. windows problem.. H - what kinda mental tard would do that? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patches available (was Re: NFS HEADS UP)
:linux cp multipatch-1.diff test1
:fbsd cat test1
:cat: test1: RPC struct is bad
:fbsd cp test1 /tmp
:fbsd cat test1
:SNIP
:+ (vp-v_object-flags OBJ_MIGHTBEDIRTY)) {
:
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@requested range. Note: we are assuming that
:SNIP
:
:Doesn't happen between two linux boxen. (Both 2.2.11-NFSv3)
:
:-Rob
Yah, but that doesn't mean much. What we have here is some sort of
protocol confusion. Try an NFSv2 mount and see if that works.
If the problem is protocol confusion there's a good 70% chance that the
confusion is on the side of the linux server, since linux's NFSv3
implementation is *very* recent. It would take someone with a protocol
analyzer to track it down.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
On Sun, 22 Aug 1999, Ollivier Robert wrote: According to Narvi: "Falling letters like in the movie with red bills" Pill :) That very important... The screensaver triggered me to see the movie again. A. I love it. Yeah, it's gotta be the perfect hacker's movie. Maybe we *should* go approach the producers? I have gone to that movie several times, and I keep on enjoying it, so this is GOOD PR for them. Good idea, the approach for approval to distrubute this presented to the marketing department has a strong leverage on the legal department, in that they can't just take the easy road of saying ``no'' when the marketing department is going ``yes, yes.. this would be good for revenue''. -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gdb-4.17 in FreeBSD 4.0-CURRENT
Richard Cownie wrote: On Sat, 21 Aug 1999, David O'Brien wrote: Are you saying 4.17 is better than 4.18 for debugging C++? Or are you saying you didn't know FreeBSD comes with gdb: gdb-4.18 is badly broken on all platforms (at least for C++). You can't call methods from the gdb command line, and also it frequently freezes to the point where you have to kill the window. gdb-4.17 is much better for C++. There's a port for gdb-4.17 sitting on my ftp site at: ftp://ftp.pcnet.com/users/eischen/FreeBSD/gdb-4.17-port.tar.gz The port includes changes made to the gdb in our base system (then, Mar 1999, it was gdb-4.15 I believe). I haven't made any further updates to it since. You're welcome to play around with it. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
On Sun, 22 Aug 1999, Rodney W. Grimes wrote: On Sun, 22 Aug 1999, Ollivier Robert wrote: According to Narvi: "Falling letters like in the movie with red bills" Pill :) That very important... The screensaver triggered me to see the movie again. A. I love it. Yeah, it's gotta be the perfect hacker's movie. Maybe we *should* go approach the producers? I have gone to that movie several times, and I keep on enjoying it, so this is GOOD PR for them. Good idea, the approach for approval to distrubute this presented to the marketing department has a strong leverage on the legal department, in that they can't just take the easy road of saying ``no'' when the marketing department is going ``yes, yes.. this would be good for revenue''. OK, then, I'll do it "with unofficial but general approval of many FreeBSDers" (which is what I'll tell the folks). Too bad I don't live in LA anymore, I used to know the right folks to go to. +--- Chuck Robey | Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Downgrade ????
On Sun, Aug 22, 1999 at 02:49:49PM -0700, william woods wrote: OK, this is kinda a crazy questions, but..what the hell ...snip... How possible is it to cvsup stable ( I would blow away /uusr/src first) and then do a make world and have a 3.2-stable system or should I just re-install 3.2-stable? I think it would be better if you did a binary upgrade. That way you don't have to worry about build tools from CURRENT doing something funny to your 'make world'. In either case you will want to remove libraries from CURRENT not present in STABLE and any that may have had a version bump for CURRENT, ie. libfoo.so.1 in STABLE was libfoo.so.2 in CURRENT. Any ports that you compiled with c++ in CURRENT will have to be recompiled after you downgrade. Those are the types of issues I think you will run into. Doing the binary upgrade should preserve your /etc so your password database should be OK. It would of course be prudent to back up /etc anyway. Good luck. -- Glenn Johnson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: REQ: Test /etc/rc clean-up
On Fri, 20 Aug 1999 11:59:05 MST, Doug wrote: However I'd REALLY like to emphasize again that if we're going to do this the proper fix is to use case wherever possible. I have offered several times to do the work if it has a chance of being committed, that offer is still good. Hi Doug, The several times before, did folks come up with objections, or was it just a case of mass apathy? :-) I don't want to piss into the wind of wisdom from ages past, but I like the sound of what you're suggesting. I guess if there _are_ sensible objections, they'll crop up when you send a diff? Oh, and thanks for the offer. You no doubt understand that this is probably not something that'll get pumped straight into CURRENT without a goodly number of "works for me" messages in prviate mail from folks using lotsa weird setups. ;-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem with the ata driver
It seems Nicolas Souchu wrote: acd0: GCD-R520B/1.1 CDROM drive at ata0 as master acd0: drive speed 0KB/sec acd0: supported read types: acd0: Mechanism: caddy acd0: Medium: CD-ROM unknown medium Any clue? The drive was running flawlessly with the old wdc driver and with various primary releases of the new ata driver (some, not all). Hmm, looks like the timeout I've chosen for timing out on the probes *might* be too short for some devices.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
