Re: freebsd problem: Cannot detect Hard Disk (SATA) RELENG_4
Julian Elischer writes: | Doug, could you comit your patchsets to RELENG_4? I could but have not been given an okay from RE. What I've proposed to do before is commit the base HW support without my RAID and other enhancements. This is essentially taking the stuff from 5-current HW only bits to 4.X. That would let people use the HW. Then fix some ATA/FreeBSD bugs so machines don't hang and panic. I don't plan to bring in my RAID enhancements since then if people upgrade to 5.X/6.X they will lose functionality. Very little of the core ata code in 4.X has to change since I have compatibility macros to make it transparent. The bug fixes tweak some of the ata core code. My employer would give me time to do this. | Doug Ambrisko wrote: | | Dmitry Morozovsky writes: | | On Sat, 22 Jan 2005, Dmitry Morozovsky wrote: | | | | DM DA There is: | | DM DAhttp://www.ambrisko.com/doug/ata/ata_stable_sata_7.patch | | DM DA for 4.10. That deals with Intel and Promise SATA stuff and | | DM DA ata-raid fixes/enhancements. It deals with legacy and enhanced mod es | | DM DA for Intel SATA. | | DM DA | | DM DA A bunch of people have installed it and are using this. A bunch of | | DM DA our customers use it via our appliance. | | DM | | DM Wow, thanks! BTW, it seems some sio patches are slipped in by accident? | | | | BTW2: here is small patch to support Promise SATA PDC20376 controller found on | | our Albatron MB | | [ Attachment, skipping... ] | | Thanks for the patch. It will go in the next patch set. I should make | a new one fairly soon since I initially prevented the Promise stuff from | using PIO but found out we need PIO for crash dumps. I need to test | the PIO change. It was pretty trivial since there is already stuff | to deal with this. Actually it looks like I did test it a while back so it should be ready to go if someone is interested in testing it to make sure the PCI ID's are right (Dmitry?). It's at: http://www.ambrisko.com/doug/ata/ata_stable_sata_8.patch Thanks, Doug A. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in calcru() in kernel: integer overflow computing user time
Chris Landauer writes:
|
| hihi, all -
|
| well, i have an almost fix for the problem - read on, ...
| (this is for discussin before send-pr submission)
|
| description
|
| in FreeBSD 5.3-RELEASE (and 5.2.1R, and 5.1R),
| in file /usr/src/sys/kern/kern_resource.c,
| lines 657-750 define a function calcru(),
| and there is a bug in that function -
|
| line 713 in that file is
|
|uu = (tu * ut) / tt,
|
| which is trying to compute a proportion (since ut=tt) - the problem
| is that for my application, the values of tt and ut are very large and
| the value of the intermediate product overflows, leading to incorrect
| values (i reported the symptoms to freebsd-hackers and a very helpful
| description and localization of the problem to calcru() was provided
| by peter jeremy, who also wrote that it is a very old, but only partly
| known, problem)
|
| repetition
|
| use time in csh or /usr/bin/time or getrusage() to time any program
| that takes more than a week to run
|
| fix (almost)
|
| it turns out that this problem can be (partly) fixed by replacing that
| one line above with the following lines:
|
| /* we know 0 = ut = tt and 1 = tt */
| if (tu = tt)
| {
| **whatever type they need to be** q, r;
| q = tu / tt;
| r = tu % tt;
| uu = (q * ut) + (r * ut) / tt;
| }
| elseuu = (tu * ut) / tt
|
| this change does not solve all the arithmetic problems (especially
| when ut is very large), and a similar change is needed for system
| time, computing su in line 714 of the file, but it suffices for me -
|
| analysis (yup, proof that it should work 8-)) -
|
| i expect that all of these counters are increasing throughout the life
| of the process -
| tu is total time in microseconds
| ut is user 128hz ticks
| tt is total 128hz ticks
| i assume therefore that
| tu ~ tt * 10^6/128
| strictly because of the clock rates
| (machines with other kinds of clock rate ratios will need a different
| analysis, but the same idea should work there, too) -
|
| in my case ut ~ tt, so we see overflow in the old computation when
| tu * ut = 2^64
| tt^2 * 10^6/128 = 2^64
| tt * 10^3/8*sqrt(2) = 2^32 ~ 4 * 10^9
| tt = 32*sqrt(2)*10^6,
| which is about
| sqrt(2)*10^6 / 4 ~ 3.54*10^5 seconds,
| or
| ~ 98 hours
| (this is the phenomenon i observed)
|
| in the new computation offered above, since we know that
| ut = tt,
| we also know that
| uu = tu,
| and
| (q * ut) = uu,
| so there can be no overflow in the (q * ut) term -
| therefore, this changed code will overflow only when r is large
| r ~ tt,
| and then only when
| r * ut = 2^64
| tt^2 = 2^64
| tt = 2^32,
| which is about
| ~ 2^25 seconds
| ~ 9300 hours
| ~ 388 days
| (i can live with that for now)
|
| for everyone else, it adds the one test in the if statement to every
| call to calcru() (or two, if system time is similarly fixed) -
| philosophy instrumentation is costly, and correct instrumentation is
| even more costly, but it's worth it, every time, to get the right
| answer /philosophy
|
| i'm about to try it out this week - i will report the results when i
| get some data (which will be a few weeks)
|
| i'm thinking about how to solve the problem correctly for really
| long-running programs, but it's all pretty special case ugly so far
This is my fix:
Index: kern_resource.c
===
RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/kern_resource.c,v
retrieving revision 1.55.2.5
diff -u -p -r1.55.2.5 kern_resource.c
--- kern_resource.c 3 Nov 2001 01:41:08 - 1.55.2.5
+++ kern_resource.c 26 Jan 2005 19:03:27 -
@@ -552,10 +552,10 @@ calcru(p, up, sp, ip)
tu = ptu;
}
- /* Subdivide tu. */
- uu = (tu * ut) / tt;
- su = (tu * st) / tt;
- iu = tu - uu - su;
+ /* Subdivide tu. try to becareful of overflow */
+ su = tu * (st * 1024 / tt) / 1024;
+ iu = tu * (it * 1024 / tt) / 1024;
+ uu = tu - (su + iu);
/* Enforce monotonicity. */
if (uu p-p_uu || su p-p_su || iu p-p_iu) {
If people like it I can commit it. It works for us. We had problems with
this as well. It's pretty simple fix. I used 1k since usage of this
tends to be % so rounding should effect that much.
Doug
Re: bug in calcru()
Chris Landauer writes: | thanx for the suggestion - the notion of computing ut just with subtraction is | really good, since it is likely to be the largest of the three values in most | applications, but i'm a little worried that the 1024 multiplications aren't | large enough when tt gets really large - i'll do the math on it and report its | (provable) range of applicability and accuracy in a few days I understand it wouldn't be exact but it will be better then the 100% typical use ie. (10% system, 20% interrupt and 70% user). With the stuff to ensure it is monitonically increasing you can get wacky results so IMHO it will never be right but good enough Atleast that is what I recall when I tested this stuff out a long time ago. The assumption with this calculation is that st it tend to be small compared to tt so the 1024 X shouldn't overflow much. | Doug Ambrisko [EMAIL PROTECTED] wrote | ... | /* Subdivide tu. try to becareful of overflow */ | su = tu * (st * 1024 / tt) / 1024; | iu = tu * (it * 1024 / tt) / 1024; | uu = tu - (su + iu); | ... Doug A. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
NO_TCSH leaves crud in /usr/src
This issue has been around a long time, but I keep forgetting to post it. When I enable NO_TCSH in /etc/make.conf, after a build/installworld I get this in /usr/src: ? bin/csh/gethost ? bin/csh/sh.err.h ? bin/csh/tc.const.h They don't seem to hurt anything, but it would be nice to get this fixed. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EFI network boot loader for ia32?
On 27 Apr 2005, at 20:10, Fred Clift wrote: This might better belong on -questions, this isn't the most technical question, but it is obscure... I've recently been loaned an eval server indirectly from intel. It is an SR-2400. We've been using SR-2300s for a while now and have been doing custom network installs via PXE. I note that these new servers have ia32 EFI support and that the only net-booting they support is via EFI. I can DHCP boot the box via the EFI boot manager menu that comes up, I get an address and it tftp's a file from the right server but of course the pxeboot bootfile doesn't work. I downloaded the indel EFI SDK and it has some sample EFI binaries (a test binary, one that draws some cute little boxes on the screen etc) and I can boot and run those just fine... I understand that EFI netbooting works fine on (was designed to work on?) ia64 boxes - is there support for netbooting via EFI on ia32? I see /usr/src/sys/boot/EFI - can I somehow build a loader.efi that would work via netboot for ia32? Thanks in advance for any help... The EFI boot loader does not support ia32 in its current state. It would be possible to port it to an ia32 EFI environment with some effort. It would be quite an advanced level project though. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A question about /sys/kern/link_elf.c
On Monday 02 May 2005 13:35, [EMAIL PROTECTED] wrote: There is a #ifdef SPARSE_MAPPING at line 701,and again a #ifdef SPARSE_MAPPING at line 713.I just can't understand the second one.Does it have any special mean ? thanks . It's just conditional compiling construct...however as you can see in the tag For whatever reason, SPARSE_MAPPING is not even a config option, so this is dead code. It dates back to a tools problem that I had on the alpha where the linker would round up the size of the text segment to the next megabyte boundary. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Starting natd
On Thu, 26 Jul 2001, Daniel C. Sobral wrote: It seems that rc.network requires an interface to be specified for natd for it to be started. Alas, I do not and cannot specify an interface for natd, using alias_address instead (and disliking even that, since what I really want is static nat). You can specify an IP and rc.network autodetects to use -n or -a. natd_interface=a.b.c.d is ok (at least on 4.2) Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: how to share include files between kernel and userland?
Marco Molteni writes: | I am writing a program to parse frames dumped to bpf by an, the | aironet driver. | | I am using the latest patches by Doug Ambrisko, that allow the driver | to dump not only the 802.11 frame but also the special Aironet header | that the device prepends to the 802.11 frame, ie: | | aironet header | 802.11 frame | | Now, to my question with include files. The struct that describes the | aironet header, an_rxframe, is in an/if_anreg.h, so I included | if_anreg.h in my program. Among other things, if_anreg.h needs the | definition of struct arpcom, which is in net/if_arp.h. Good, I | included also net/if_arp.h, but the compiler still complained. It | turns out that the definition of struct arpcom is guarded by | #ifdef _KERNEL. | | So, what should I do? Define _KERNEL in my program, or copy the | definition of struct an_rxframe directly in my C file? I hoped to find | a third, more elegant solution. Don't include that file only include if_aironet_ieee.h. Really we should install this file in the standard /usr/include tree so you don't need the /sys tree around to build it and ancontrol. I'll move the an_rxframe struct to if_aironet_ieee.h. Note that I'm not to sure how pcap is going to like my made up type. If you send my some sample code on dump the Aironet header I can test it for you to make sure it works since I haven't got around to it. There were some people interested in the Aironet header so I put something together but never tried doing anything usefull with it. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Collecting System Statistics Programatically
On Fri, 27 Jul 2001, Tabor Kelly wrote: I have found how to collect limited system statistics with sysctlbyname(), but I need to know how to do more. In specific I need to know how much memory is being used, and what percentage of processor cycles are being used. You can get memory utilization stats from sysctl; look in the 'vm' group. CPU usage still has to come from kmem I think. Check the vmstat / top code. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Newbus
On Wed, 8 Aug 2001 [EMAIL PROTECTED] wrote: I would very much like to know, exaclty which files comprise the code for NEWBUS, excluding the drivers themselves.Can anyone help The external API is in sys/bus.h. The internal implementation is in sys/bus_private.h and kern/subr_bus.c. Interface definitions are scattered around the tree - the core interfaces DEVICE and BUS are in kern/device_if.m and kern/bus_if.m respectively. The 5.x version of newbus is based on the kobj system with api in sys/kobj.h and implementation in kern/subr_kobj.c. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Does boot1 still have a 1023 cyl limit?
[EMAIL PROTECTED] writes:
| Kent Stewart wrote:
|
| Mike Smith wrote:
|
|So.. if I read you right, booting correctly for 1024 cylinders works
|if boot0 knows about it. Isn't boot0 the one in the MBR, not in the fbsd
|slice? Does this mean that boot1 and boot2 should work just fine if they
|are loaded by another kind of MBR loader (say, Grub), and they find out
|that they are placed beyond the 1023th cylinder?
|
| This should work, yes.
|
| I tried this with a boot1 from FreeBSD 4.4-rc and get a BTX error. I
| had to go back to the boot1 from 4.3 before I could boot.
|
| That could be serious. Can you post a brief description of your
| hardware, together with the BTX register dump if possible? boot1 was
| changed to address some problems with certain hardware, so it is
| important to know if other incompatibilities have been introduced.
... in 4.3:
warp% nm boot1.o | grep flags
0199 t flags
warp%
in -current
a21p% !nm
nm boot1.o | grep flags
01ba t flags
a21p%
Is someone writing into boot1 flags? Then there is a problem since this
has moved. We did some work to avoid this linking type problem for xread
in boot2.c to prevent this type of error. Do we have to do it for flags?
I see in libdisk:
static void
Cfg_Boot_Mgr(u_char *mbr, int edd)
{
if (mbr[0x1b0] == 0x66 mbr[0x1b1] == 0xbb) {
if (edd)
mbr[0x1bb] |= 0x80; /* Packet mode on */
else
mbr[0x1bb] = 0x7f; /* Packet mode off */
}
}
The mbr code it is modifying is in boot0 or mbr since I see in
boot0 that:
a21p% nm boot0.o | grep flags
01bb t flags
a21p%
but I'm not seeing how it gets over to boot1 for this test?
read.7: testb $FL_PACKET,%cs:MEM_REL+flags-start # LBA support e
Doug A.
PS. dhw ... could you try to set packet mode on some machines there
and test it.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Does boot1 still have a 1023 cyl limit?
John Baldwin writes: | This is for boot0. Nothing should be touching boot1 flags. | My guess is that someone has somehow mixed an old boot2 with the new boot1 | which is jumping to the wrong place to call xread. The code at cs:eip looks | a lot like the BPB in boot1 now. Okay that basically how I read the code. Just wanted to make sure I wasn't missing something. Your theory sounds quite possible. Thanks, Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: if_sf bug
On Wed, 3 Oct 2001 [EMAIL PROTECTED] wrote: The if_sf driver doesnt seem to initialize itself until an address is set, which makes things like tcpdump, bridging and other promiscuous things not work. All the interfaces do that. If you want to make an invisible interface, configure it with IP 0.0.0.0. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 64bit Ethernet Card (if_sf driver)
[EMAIL PROTECTED] writes: | I've been testing the adaptec 64044 card (if_sf driver) which is a 64bit | 66Mhz 4 port ethernet. I can have come to one of two conclusions: | | 1) the card sucks | 2) the driver sucks | | or both. A 32bit Dlink 4 port card outperforms it by a wide margin, as do | 32bit eepro100s. wide margin being defined as about 40%. | | Given that bus resources are not easily measureable..Im quoting cpu usage for | handling the same number of pps. But its pretty difficult to justify using a | 64bit slot and rather expensive card with such lousy performance. I cant even | justify the bus-bandwidth saving with a card that cant route more than | 250Mb/s. | | I guess my question has to do with whether the board is just a dog or the | driver needs substantial optimization. The folks at adaptec aren't dopes | generally, so I cant imagine that they chose a chipset that was so inferior | to the one on their 32bit adapter (which uses the same as the Dlink). | | Anyone with experience or ideas? I can just confirm your observations. I found that having it in a 64bit slot or 32bit made no difference. I hope it is a driver problem since Adaptec was selling a DEC based 4 port card that they got when they bought Cogent. I find it hard to believe that they would replace that with a poorer performance card that probably cost them more to make. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Tim, Your license with SBS for the DDK would prevent you from posting your code. If you read through it, you'll find that it prohibits the release of any of their DDK code under any circumstances. You could release everything EXCEPT the API for the card that SBS provides and offer the rest in object-only format. Doug On Thu, 18 Oct 2001, Tim Wiess wrote: If anyone has an interest in adding support for the SBS WAN cards to FreeBSD, feel free to contact me. I'll be glad to help. I'm actually working on a driver for the SBS WANic 600 and 800 cards. There is still a lot of work and testing to be done, but (assuming there are no problems with the powers that be over here, and there are no conflicts with our agreements with SBS) I do eventually plan on posting the code (under a BSD license). I'll keep y'all posted. tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: more on Re: Please review: bugfix for vinvalbuf()
Unfortunately, the recent patch to vinvalbuf() hasn't solved all of
our problems. We had another, different panic today. The process that
caused it was a 'tail' of a growing logfile over NFS.
I have actually had this problem before, with FreeBSD 3.4, and reported
it then. I believed this PR to be relevant at the time, however, I do
not believe this client was writing to the file.
[1998/06/23] kern/7028 http://www.freebsd.org/cgi/query-pr.cgi?pr=7028
panic in vinvalbuf when appending/looking at tail of NFS file
The system is running 4.4-RELEASE with the vinvalbuf() patch. Debugging
information is below. If I can provide any additional information,
let me know.
Thanks for any help,
Doug
-- panic message --
SMP 2 cpus
IdlePTD 3555328
initial pcb at 2cf300
panicstr: vinvalbuf: flush failed
panic messages:
---
panic: vinvalbuf: flush failed
mp_lock = 0101; cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... 8
done
Uptime: 19d20h13m23s
-- gdb session --
(kgdb) back
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:473
#1 0xc016cf8f in boot (howto=0x100) at /usr/src/sys/kern/kern_shutdown.c:313
#2 0xc016d3a9 in panic (fmt=0xc028745a vinvalbuf: flush failed)
at /usr/src/sys/kern/kern_shutdown.c:581
#3 0xc019a719 in vinvalbuf (vp=0xd7dde8c0, flags=0x1, cred=0xc2c60780,
p=0xd79a0680, slpflag=0x100, slptimeo=0x0)
at /usr/src/sys/kern/vfs_subr.c:753
#4 0xc01d0b30 in nfs_vinvalbuf (vp=0xd7dde8c0, flags=0x1, cred=0xc2c60780,
p=0xd79a0680, intrflg=0x1) at /usr/src/sys/nfs/nfs_bio.c:1190
#5 0xc01cf668 in nfs_bioread (vp=0xd7dde8c0, uio=0xd7a42ed4,
ioflag=0x7f, cred=0xc2c60780) at /usr/src/sys/nfs/nfs_bio.c:401
#6 0xc01f68d2 in nfs_read (ap=0xd7a42e64)
at /usr/src/sys/nfs/nfs_vnops.c:1008
#7 0xc01a235c in vn_read (fp=0xc254cd40, uio=0xd7a42ed4, cred=0xc2c60780,
flags=0x0, p=0xd79a0680) at vnode_if.h:334
#8 0xc017b690 in dofileread (p=0xd79a0680, fp=0xc254cd40, fd=0x3,
buf=0x804d000, nbyte=0x200, offset=0x, flags=0x0)
at /usr/src/sys/sys/file.h:146
#9 0xc017b556 in read (p=0xd79a0680, uap=0xd7a42f80)
at /usr/src/sys/kern/sys_generic.c:117
#10 0xc025d7b5 in syscall2 (frame={tf_fs = 0x2f, tf_es = 0x2f,
tf_ds = 0xbfbf002f, tf_edi = 0x4, tf_esi = 0x280fc3a0,
tf_ebp = 0xbfbff8c0, tf_isp = 0xd7a42fd4, tf_ebx = 0x280ea424,
tf_edx = 0x37, tf_ecx = 0x37, tf_eax = 0x3, tf_trapno = 0x7,
tf_err = 0x2, tf_eip = 0x280defcc, tf_cs = 0x1f, tf_eflags = 0x293,
tf_esp = 0xbfbff894, tf_ss = 0x2f})
at /usr/src/sys/i386/i386/trap.c:1155
#11 0xc024a62b in Xint0x80_syscall ()
cannot read proc at 0
(kgdb) up
#1 0xc016cf8f in boot (howto=0x100) at /usr/src/sys/kern/kern_shutdown.c:313
313 dumpsys();
(kgdb) up
#2 0xc016d3a9 in panic (fmt=0xc028745a vinvalbuf: flush failed)
at /usr/src/sys/kern/kern_shutdown.c:581
581 boot(bootopt);
(kgdb) up
#3 0xc019a719 in vinvalbuf (vp=0xd7dde8c0, flags=0x1, cred=0xc2c60780,
p=0xd79a0680, slpflag=0x100, slptimeo=0x0)
at /usr/src/sys/kern/vfs_subr.c:753
753 panic(vinvalbuf: flush failed);
(kgdb) print vp-v_dirtyblkhd
$1 = {tqh_first = 0x0, tqh_last = 0xd7dde8f4}
(kgdb) print vp-v_cleanblkhd
$2 = {tqh_first = 0xcc5fa5ec, tqh_last = 0xcc5fa5f4}
(kgdb) print *(vp-v_cleanblkhd-tqh_first)
$3 = {b_hash = {le_next = 0xcc607e80, le_prev = 0xcc666e9c}, b_vnbufs = {
tqe_next = 0x0, tqe_prev = 0xd7dde8ec}, b_freelist = {
tqe_next = 0xcc5f8bfc, tqe_prev = 0xcc6060bc}, b_act = {tqe_next = 0x0,
tqe_prev = 0xc2001d90}, b_flags = 537919520, b_qindex = 2,
b_xflags = 2 '\002', b_lock = {lk_interlock = {lock_data = 0},
lk_flags = 0, lk_sharecount = 0, lk_waitcount = 0,
lk_exclusivecount = 0, lk_prio = 20, lk_wmesg = 0xc02860b0 bufwait,
lk_timo = 0, lk_lockholder = -1}, b_error = 0, b_bufsize = 3584,
b_runningbufspace = 0, b_bcount = 3147, b_resid = 0, b_dev = 0x,
b_data = 0xceeec000 ...,
b_kvabase = 0xceeec000 ...,
b_kvasize = 16384, b_lblkno = 6949, b_blkno = 84, b_offset = 56926208,
b_iodone = 0, b_iodone_chain = 0x0, b_vp = 0xd7dde8c0, b_dirtyoff = 0,
b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, b_pblkno = 1771566,
b_saveaddr = 0x0, b_driver1 = 0x0, b_driver2 = 0x0, b_caller1 = 0x0,
b_caller2 = 0x0, b_pager = {pg_spc = 0x0, pg_reqpage = 0}, b_cluster = {
cluster_head = {tqh_first = 0xcc5c66a0, tqh_last = 0xcc640720},
cluster_entry = {tqe_next = 0xcc5c66a0, tqe_prev = 0xcc640720}},
b_pages = {0xc0afb4ac, 0x0 repeats 31 times}, b_npages = 1, b_dep = {
lh_first = 0x0}, b_chain = {parent = 0x0, count = 0}}
(kgdb) up
#4 0xc01d0b30 in nfs_vinvalbuf (vp=0xd7dde8c0, flags=0x1, cred=0xc2c60780,
p=0xd79a0680, intrflg=0x1) at /usr/src/sys/nfs/nfs_bio.c:1190
1190error = vinvalbuf(vp, flags, cred, p, 0, slptimeo);
(kgdb) print p-p_pid
$4 = 0x14594
(kgdb) btp 83348
frame 0 at 0xd7a42cb4: ebp d7a42cd8, eip 0xc016cf8f boot
Re: more on Re: Please review: bugfix for vinvalbuf()
On Fri, Oct 19, 2001 at 09:51:10PM -0700, Matthew Dillon wrote: : :Unfortunately, the recent patch to vinvalbuf() hasn't solved all of :our problems. We had another, different panic today. The process that :caused it was a 'tail' of a growing logfile over NFS. : :I have actually had this problem before, with FreeBSD 3.4, and reported :it then. I believed this PR to be relevant at the time, however, I do :not believe this client was writing to the file. : : [1998/06/23] kern/7028 http://www.freebsd.org/cgi/query-pr.cgi?pr=7028 : panic in vinvalbuf when appending/looking at tail of NFS file : :The system is running 4.4-RELEASE with the vinvalbuf() patch. Debugging :information is below. If I can provide any additional information, :let me know. : :Thanks for any help, :Doug How easily can you reproduce this? How often does it occur if you leave a tail running? -Matt I'm not able to reproduce this at will at the moment. The PR I mention has a program which it claims can cause the crash, which I will try running. I'll also try tailing various logfiles, including the one which caused this crash, which is being written to on the machine that is the NFS server. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Read only file FSTAB after error config???
For future reference, this belongs on freebsd-questions. Soweb_Ahfei wrote: Dear Sir, We have installed the Freebsd4.32 in our server.But we can not reboot the system after we made an error configuration in the file FSTAB.Now,we can not delete or rename the error file Fstab and the system shown the file is read only. This is covered in the documentation at http://www.freebsd.org/ I believe in the FAQ, if not there, it's in the handbook. Good luck, Doug -- We will not tire, we will not falter, and we will not fail. - George W. Bush, President of the United States September 20, 2001 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
On 18 Oct 2001, Dag-Erling Smorgrav wrote: John Baldwin [EMAIL PROTECTED] writes: Huh? Int on alpha is 32, and pointer is 64. I thought we were ILP64 on 64-bit archs, but you're right. And I ought to know better... Fortunately (?) it doesn't matter in this case. Function arguments which are passed in registers are all promoted to 64bits. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Duping a hard disk
On Tue, 23 Oct 2001, PSI, Mike Smith wrote: I am running a lab with 43 FreeBDS machines and will be adding about 20 more in the near future. ALL these machines are absolutely identical except for IP address and machine name. To speed up the adding of new machines, I envision making a duplication station, where I would add a new disk as a slave and then dup the master disk to the slave disk. Then I would only have to change IP and machine name. If your machines have netboot or floppy-boot capability, you might look at the PicoBSD install set. It's a bit dated, but I've used the same system with PXE netbooting to install tons of machines. It can NFS mount just about anything, so you can rig your own autoconfig scheme so you don't need to set the machine name IP manually :) Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ACPI CA updated
On Tue, 30 Oct 2001, Mike Smith wrote: I've just updated the ACPI CA subsystem to the Intel 20011018 snapshot. This primarily fixes a couple of bugs in the ACPI interpreter; see the changelog at http://developer.intel.com/technology/iapc/acpi/downloads/CHANGES.txt for full details. This doesn't appear to fix the 64bit alignment problems which we had while trying to use the code on ia64. Any news on when/whether Intel will accept our 64bit patches? -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: ACPI CA updated
On Wed, 31 Oct 2001, Grover, Andrew wrote: From: Doug Rabson [mailto:[EMAIL PROTECTED]] This doesn't appear to fix the 64bit alignment problems which we had while trying to use the code on ia64. Any news on when/whether Intel will accept our 64bit patches? Our next release will include a fix for this. Good news, thanks! -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tracking down BTX halted
On Fri, 16 Nov 2001, Sandeep Joshi wrote: I changed the disklabels on a few SCSI disks and now I keep getting these BTX halted messages every time I reboot. Lemme guess, you're running them in 'dangerously dedicated' mode. There is a bug in Adaptec BIOSen that they will not tolerate DD disks. Put proper partition tables on them and they should behave. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tracking down BTX halted
On Fri, 16 Nov 2001, Matthew Emmerton wrote: There is a bug in Adaptec BIOSen that they will not tolerate DD disks. Which controllers have this bug? I've got a whole bunch of 7880 and 79xx controllers with disks running in DD mode and never have had this problem. Happens to me on L440GX+ boards. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: stange probelm with vmstat
On Tue, 20 Nov 2001, Matthew wrote: I got strnage problem with vmstat in 4.1 stable. I got : undefined symbols: _kememstatistics, _bucket, _zlist error mesg. I checked the kernel with nm: it says: 0 b symbol. All three are in there. I checked the device file in /dev and the sgid on vmstat. Everything right. Can any one tell what i did thtat messed up my 4.1? This generally happens if you don't boot your kernel with loader(8). Make sure you're booting your kernel the right way ... delete /boot.config, particularly if it mentions your kernel in it. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Bugmeister discussion list
On 22 Nov 2001, Dag-Erling Smorgrav wrote: [apologies to those who receive multiple copies of this message] I've set up a [EMAIL PROTECTED] mailing list Any reason this can't/shouldn't be a freebsd.org mailing list? -- We will not tire, we will not falter, and we will not fail. - George W. Bush, President of the United States September 20, 2001 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Mirrored / redundant disks.
I've got some experience with this. One of the solutions I have used in the past is as follows: 1. Configure the two disks with a root partition, swap partition, and a vinum partition covering the rest of the disk. If you make your root partition 128M, you can just barely fit a base system in there. Finagle a bit with disklabel -e so both disks have their partitions configured as: a: root filesystem b: swap space c: (entire disk) e: vinum Also, disklabel -B the second disk to make it bootable. 2. Set up vinum mirror volumes for /usr and /var. 3. Move the data from /usr and /var to their vinum equivalents in single user mode, and set up your fstab to mount the vinum volumes (for example, /dev/vinum/varvol). Make sure you add start_vinum=YES to your rc.conf. 5. Set up the remainder of your system. cvsup sources and ports and so forth as necessary to configure it. 6. Mount the second disk's 'a' partition somewhere and use dump/restore to copy the primary disk's root partition to the secondary's. Optionally set up a cron job to keep the two in sync. With this configuration, if your primary disk fails, you can pull it and boot off the secondary disk. If your secondary disk fails, you'll still have the primary and can replace the secondary at your leisure. The only problem is if the primary disk fails completely, is not bootable, and is at a location where the box cannot have the drive removed. The only solution I know of in this case would be a hardware or pseudo-hardware RAID of some sort (I say pseudo- hardware because I'm not sure how much the various IDE RAID systems that are available depend on software to do their job). Other possibilities I am aware of are the various IDE flash-based drives. They have no moving parts and modern flash supports many write cycles (I would still suggest using them only as a boot drive with minimal writes and using a fully mirrored pair of standard hard drives for /usr, /var, /tmp, and so forth). You might also consider compiling your / into the kernel and having it mounted as a MD at runtime. You would not be able to make permanent changes without re-compiling your kernel, but then the unmirrored root partition would never be accessed after boot time, and you would ideally have duplicate copies on each disk to boot from. Doug On Fri, Sep 28, 2001 at 07:45:26PM -0400, Leo Bicknell wrote: I need to configure a server that can deal with a disk failure. I've been looking at CCD and Vinum, but both seem to have issues that make automatic recovery in the face of one dead disk (in a mirror) less than optimal. So, if you know how to make it so a disk can die and the box keeps running, and more importantly _can be rebooted_ and keep running either via careful configuration or some crufty scripts if you could contact me that would be welcome. No need to keep on-list unless you think there's something of great value to hackers. -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org 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: BPF - Packet Reception
On Mon, 26 Nov 2001, Rajesh P Jain wrote: We are trying to use BPF (Packet Filter) pseduo device to send and receive the packets. Even if there is a slight delay (Some processing has to be done on the read packet) between the issuing of 'read' call, so many packets are getting dropped. BPF isn't a high-performance interface. If you need something faster, you should add your code to the kernel network stack. Then you will get a call to your code for every packet input of the type you're looking for. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Debbuging hard lockups...
Mike Meyer wrote: I can generate hard lockups on my SMP box pretty easily. When locked, it fails to respond to anything - I can't even get into the kernel debugger to fire up. The lockups don't happen on UP machines under the same conditions, so I can't even see if console debugging would work, because I don't have a second SMP machine to run the kernel on. I'm running 4.4-stable, and I'm looking for suggestions on how to deal with this, other than don't do that. Debugging kernel options, maybe? How much ram do you have, and how long are you waiting? I find that it sometimes takes several minutes to dump 256M. HTH, Doug -- We will not tire, we will not falter, and we will not fail. - George W. Bush, President of the United States September 20, 2001 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
I'm providing this to the people whose addresses appear in the original messages. My apologies if this gets cross-posted or sent multiple times to the same place. As I mention below, the WANic 400 series cards and all of the RISCom/N2 series cards are now End Of Life, and only available in special quantity builds. If anyone reading this message needs further information, please contact me directly and I can go into further depth about the EOL cards mentioned below and their replacements in the SBS line. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 On Fri, 12 Oct 2001, Doug Hass wrote: The WANic 400 series is definitely EOL. The cards are available in quantities of 100+ only by special order. The RISCom/N2 series cards are also EOL. This is a recent decision--it went into effect as of September 21st. Closeout quantities have already been sold to other companies, so the cards are only available by special order. The WANic 521/522 have replaced these cards, and should be used instead. There are no drivers for FreeBSD, however. Doug On Sat, 13 Oct 2001, Alfred Shippen wrote: This guy is local to you and is under the misapprehension that the Risc/400 series is not a discontinued item. I dont know if you want to follow them up or not. My customer (Bytecraft) is fine by this and has passed on the comments to me. Cheers - Original Message - From: Ted Mittelstaedt [EMAIL PROTECTED] To: MurrayTaylor [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 12, 2001 3:07 PM Subject: RE: Imagestream WanIC-520 interface cards The WANic 5xx's use an incompatible chipset and the driver will not work with them. I thnk your supplier is feeding you a line of bullshit. SBS Communications has posted no plans whatsover to discontinue or change the WANic line. They are fully aware that the 405's have open source drivers and are furthermore used in embedded systems too. The WANic 5xx series of cards sell for more money and so naturally your supplier is most interested in maximizing his margin and would prefer to push you into a more expensive card. With the increase in CPU power all of the go-fast hardware on the higher-level cards is less important. Consider that the Hitachi controller chip used on the WANic 405 is the SAME chip that Cisco uses in it's 25xx series of routers, and the Cisco 2501 is the most used router in the world and has the most installed units. SBS Communications is STILL selling the RISCom series of cards which is the predecessor to the WANic, uses the same controller, these are ISA cards that have a design that's over 10 years old. You tell your supplier that since the 405 is being phased out that he should sell you a bunch of them at closeout prices. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of MurrayTaylor Sent: Thursday, October 11, 2001 4:49 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Imagestream WanIC-520 interface cards As the WanIC-405 is being phased out (according to my supplier down under here in OZ), has any development / testing been done on the apparent replacement, the WanIC-521 (522, 524 ... ) range I am especially interested in its compatibility with its predecessor which I am using very successfully for frame relay under Netgraph. I'm trying to get compatability info from the supplier here, but we are a long way down the food chain ;-( Tia Murray Taylor Bytecraft Systems Pty Ltd [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4-port T1 PCI card with integrated csu/dsu
The virtues or foibles of individual personalities are outside the scope of this list. Anyone interested in further information is welcome to search the archives of just about any of the FreeBSD lists. Meanwhile, let's get back to our regularly scheduled bikesheds. Thanks, Doug -- We will not tire, we will not falter, and we will not fail. - George W. Bush, President of the United States September 20, 2001 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
Ted, We're SBS' worldwide distributor. Others who resell them buy them from us or from one of our distributors. In any case, I can ASSURE you without a doubt that the WANic 400 series and the entire RISCom/N2 series are end of life as of the end of September. If you have questions, feel free to contact me at your convenience. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 On Sun, 14 Oct 2001, Ted Mittelstaedt wrote: There are other vendors that sell the WanIC than Imagestream. I realize that you see yourself as the only supplier but this isn't true. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass Sent: Friday, October 12, 2001 3:11 PM To: [EMAIL PROTECTED]; Ted Mittelstaedt; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Alfred Shippen Subject: Re: FYI I'm providing this to the people whose addresses appear in the original messages. My apologies if this gets cross-posted or sent multiple times to the same place. As I mention below, the WANic 400 series cards and all of the RISCom/N2 series cards are now End Of Life, and only available in special quantity builds. If anyone reading this message needs further information, please contact me directly and I can go into further depth about the EOL cards mentioned below and their replacements in the SBS line. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 On Fri, 12 Oct 2001, Doug Hass wrote: The WANic 400 series is definitely EOL. The cards are available in quantities of 100+ only by special order. The RISCom/N2 series cards are also EOL. This is a recent decision--it went into effect as of September 21st. Closeout quantities have already been sold to other companies, so the cards are only available by special order. The WANic 521/522 have replaced these cards, and should be used instead. There are no drivers for FreeBSD, however. Doug On Sat, 13 Oct 2001, Alfred Shippen wrote: This guy is local to you and is under the misapprehension that the Risc/400 series is not a discontinued item. I dont know if you want to follow them up or not. My customer (Bytecraft) is fine by this and has passed on the comments to me. Cheers - Original Message - From: Ted Mittelstaedt [EMAIL PROTECTED] To: MurrayTaylor [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 12, 2001 3:07 PM Subject: RE: Imagestream WanIC-520 interface cards The WANic 5xx's use an incompatible chipset and the driver will not work with them. I thnk your supplier is feeding you a line of bullshit. SBS Communications has posted no plans whatsover to discontinue or change the WANic line. They are fully aware that the 405's have open source drivers and are furthermore used in embedded systems too. The WANic 5xx series of cards sell for more money and so naturally your supplier is most interested in maximizing his margin and would prefer to push you into a more expensive card. With the increase in CPU power all of the go-fast hardware on the higher-level cards is less important. Consider that the Hitachi controller chip used on the WANic 405 is the SAME chip that Cisco uses in it's 25xx series of routers, and the Cisco 2501 is the most used router in the world and has the most installed units. SBS Communications is STILL selling the RISCom series of cards which is the predecessor to the WANic, uses the same controller, these are ISA cards that have a design that's over 10 years old. You tell your supplier that since the 405 is being phased out that he should sell you a bunch of them at closeout prices. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of MurrayTaylor Sent: Thursday, October 11, 2001 4:49 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Imagestream WanIC-520 interface cards As the WanIC-405 is being phased out (according to my supplier down under here in OZ), has any development / testing been done on the apparent replacement, the WanIC-521 (522, 524 ... ) range
Re: FYI
No offense taken--if I was in a position to need the 400 series cards, I'd be snapping up all the used and auction lots I could. Nortel just auctioned off about 1000 of them, so I'd expect that there will be a glut on the used market. If money is the only concern, those cards should be available on the secondary market for next-to-nothing for a long time. If performance, features and form factor are more important, there are better chipsets available on current cards. Both approaches have their merits. Doug On Sun, 14 Oct 2001, Jim Bryant wrote: No offense to you or your sales partners, but the way I see it, this means that tons of these will be available for a song on eBay soon, and will be in the hands of a lot of FreeBSD and Linux people [not all of which can afford top-of-the-line all of the time]. Doug Hass wrote: Ted, We're SBS' worldwide distributor. Others who resell them buy them from us or from one of our distributors. In any case, I can ASSURE you without a doubt that the WANic 400 series and the entire RISCom/N2 series are end of life as of the end of September. If you have questions, feel free to contact me at your convenience. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - Religious fundamentalism is the biggest threat to international security that exists today. United Nations Secretary General B.B.Ghali _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Also--understand that the replacement for the 400 and 405 is a multi-interface card (supports all of the wiring specs instead of just 1), and costs virtually the same (or less as a reseller or in volume) than the 400/405 did. Doug On Sun, 14 Oct 2001, Jim Bryant wrote: No offense to you or your sales partners, but the way I see it, this means that tons of these will be available for a song on eBay soon, and will be in the hands of a lot of FreeBSD and Linux people [not all of which can afford top-of-the-line all of the time]. Doug Hass wrote: Ted, We're SBS' worldwide distributor. Others who resell them buy them from us or from one of our distributors. In any case, I can ASSURE you without a doubt that the WANic 400 series and the entire RISCom/N2 series are end of life as of the end of September. If you have questions, feel free to contact me at your convenience. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - Religious fundamentalism is the biggest threat to international security that exists today. United Nations Secretary General B.B.Ghali _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
And if you want to sell these to FreeBSD users then make your Linux driver source (not the SAND stuff) available so that we can mod it into our own driver. Many other companies do this and as a matter of fact, we (meaning FreeBSD) have even found bugs in crummy Linux drivers that have been reported back to Linux and helped those manufacturers better their products. I'm not going to get dragged into an OS war. Both Linux and FreeBSD have their share of crummy drivers and features. That discussion is honestly beyond the scope of a discussion of ImageStream's SAND architecture and the WANic 400 series. We are bound by third party agreements and are not allowed to release any more free code (legally) than we already have. If we were not restricted by SBS, Trillium, and Rockwell (among others), we would release all of the code under GPL or lGPL. These agreements do NOT prevent us from working with developers to support other platforms, though. It only prevents the free release of portions of the code. That being said, we're always interested in supporting a wide variety of platforms. Without the SAND architecture, though, there really is little hope of having FreeBSD support for the WANic 520 series cards (or other cards, for that matter). If there are developers in the community interested in porting SAND and the various hardware modules (for the 520 series and other cards) to FreeBSD, we'll be happy to work with them and support that effort. It is in ALL of our interests to have the widest support for standards-based technologies as possible. No offense, but once Imagestream stopped selling WANic400's you ceased being an entity of interest to FreeBSD, as you no longer sell any products that run under it. I'll reiterate what I've said to you privately: ImageStream DID NOT make the decision to discontinue the 400 series or the RISCom/N2 series. This decision rested solely with SBS. However, FreeBSD users are NOT without options: 1) FreeBSD users can still get the WANic 400 and RISCom cards from the second hand market, as another person mentioned. 2) WANic 400 series cards are still available in quantity. If the market for FreeBSD is as large as you claim, then you or someone else in the community should have no problem snapping up a quantity of these cards and reselling them to interested parties. I'll go one step further: If anyone contacts me about the WANic 400 series, mentions that they are for FreeBSD, I promise to give an extra 15% discount over and above our normal volume discounts just to illustrate my desire to support the FreeBSD community. 3) Virtually ALL of our customers, save for OEMs making their own products, purchase complete routers. Going this route would eliminate the need to have FreeBSD support, as any user would have a standalone router. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Would your agreements allow you to provide resources to a small number of developers (under NDA and all that of course) to produce drivers that you would then release in binary form (eg a kernel module) under a free license? It sure would. If you cannot release the source code to your drivers, can you release hardware programming specifications (again, perhaps under NDA) that allowed someone to develop an independant free licensed driver? Unfortunately, the API to the cards (the driver development kit, hardware programming specifications or whatever you want to call them) are licensed from several third parties and we are bound by agreement not to make them public. The 400 series cards (and, for that matter, the RISCom/N2 series cards) did not require an API, which is how BSDI and FreeBSD drivers came about in the first place. As I mentioned above, we CAN license the driver code and the DDK for development. This means that you could produce FreeBSD drivers which we could then distribute in a binary form under a free end-user license. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
In a private e-mail, Leo writes: You offered a discount on these boards on the list. If you think there is a real opportunity to sell these to the *BSD crowd, I recomend you take that 15% (or some part of it) and offer to partially fund a driver developer. There are many freelance programmers working on the project who for $1000-$5000 (depending on complexity) could make your driver a reality. A good developer could probably also make them work under OpenBSD and NetBSD in one fell swoop. I'd be happy to pledge the 15% to a driver developer. That's a great idea! It will accomplish two objectives: 1) There will be at least 100 WANic 400 series cards available for purchase to support existing installations (assuming someone out there places the order). 2) ImageStream will pledge 15% of the purchase price of any lots of these 400 series cards toward porting of our SAND architecture to FreeBSD. That's a MINIMUM of $8,100 that ImageStream is willing to pay a developer or group of developers to port the drivers for the rest of the cards. Ted--you've indicated that there is a significant market for the 400 series cards in the community. Why don't you contact me privately and we'll get you an order of the cards so that we can accomplish the above. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
1) FreeBSD users can still get the WANic 400 and RISCom cards from the second hand market, as another person mentioned. What is wrong with THIS picture? You're telling people to purchase used hardware, instead of purchasing components from your company? *shakes his head* Perhaps you missed the earlier post. Someone posted about purchasing used gear or auction gear to go it on the cheap so to speak. Personally, I think wasting money on used, out-of-warranty, unsupported gear is akin to playing Russian Roulette with your money. I'd buy new every time. 2) WANic 400 series cards are still available in quantity. If the market for FreeBSD is as large as you claim, then you or someone else in the community should have no problem snapping up a quantity of these cards and reselling them to interested parties. I'll go one step further: If anyone contacts me about the WANic 400 series, mentions that they are for FreeBSD, I promise to give an extra 15% discount over and above our normal volume discounts just to illustrate my desire to support the FreeBSD community. Perhaps a better idea, if I may be so bold, would be to offer samples of the newer cards (520 series, I believe they are) to FreeBSD developers interested in producing drivers, software and utilities for these cards. After all, you are saying that the 400 is EOL. Wouldn't the idea of engineering samples be more beneficial to all involved? Those have ALWAYS been available. My phone rings all day. I pick it up, and it's never a BSD developer wanting to order cards and port drivers. :-) All you have to do is ask. Driver source, demo cards, and development tools have been available to the BSD community since 1995. To date, only BSDI took up the effort, and only briefly. Where are all the FreeBSD developers and why aren't they beating down my door for these samples and code? I'll get back to this in a minute. 3) Virtually ALL of our customers, save for OEMs making their own products, purchase complete routers. Going this route would eliminate the need to have FreeBSD support, as any user would have a standalone router. This sounds quite argumentative to me. Simply because everyone else is buying a router, there's a refusal to support FreeBSD, since people with true routers would have no need for using FreeBSD as a router engine. Nope--it's just a matter of laying out the options. There are 4--buy used, buy new in quantity, and buy routers. You can also develop drivers for the new cards (they aren't new--they've been out for 3 years). It's a vicious cycle that I believe we're seeing here... chicken and the egg, or rather, the driver and the market. Without a proper driver, there won't be a market for this card to be used with FreeBSD. However, without the manufacturer seeing visability in this market, there won't be a driver as it would be a waste of their developers time. It's not a vicious cycle at all. Ted has said repeatedly in earlier e-mails that there is a large market for the 400/405 and that discontinuing them was foolish. I've actually proposed a solution that solves both problems. I'll recap for those who missed my earlier message: 1) If the *BSD community has the 400 series cards in such high demand, someone should step up and order them in quantity. This solves the issue with the cards not being available in one and two unit quantities. You'll have a ready supply from someone in the community, and you'll be supporting the community when you buy the cards from them. 2) If someone from the FreeBSD community orders the cards, ImageStream will put up a minimum of $8,100 for a developer or developer group to port drivers for the rest of the cards. Actually, it's 15% of the purchase price of any 400 series cards. The more in demand the current cards are, the more money we'll pledge to make sure that FreeBSd drivers exist for ALL of the cards. My phone number is below. If these cards and the future of the drivers are as important as everyone who has posted says they are, let's move quickly toward a solution. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
The hardware API or the actual register interface code, is a binary-only module that is snapped in to SAND. SAND is GPL and is similar to the FreeBSD Netgraph module - it provides all the higher-level protocol stuff, like Frame Relay, PPP, HDLC, and such. SAND goes between the OS TCP/IP stack and that binary only module. That's rather simplified, since SAND also does alot of other things, but you have the basics. The reason that Imagestream went this road is that like Doug said, all those hardware vendors like Rockwell think that there's something valuable in a pure register interface spec publication for their products. So, this way Imagestream can sign their souls away to get access to that interface spec - but they isolate all that contaminated code in this binary snap-in module. It's a hack of a solution but unfortunately is getting more and more common under UNIX because the Linux people have caved in and are busily screwing their own principles of GPL, by soliciting ever greater amounts of closed-source, Linux code. Imagestream isn't the only one out there doing this. Well, not exactly. The SAND architecture was written long before we ever licensed one line of code from ANYONE. The idea behind the hardware modules was very similar to what Netgraph provides. You can snap in new hardware, software or pre- and post-processing modules without having to make accomodations in the other code. Now, you can make all the technical arguments you want about how a modularized development environment like this allows code reuse and this is quite true - but you must keep in mind that SAND's modularized development has a primary goal of being able to keep the contaminated code in the driver snap-in modules, code reuse is secondary. Again, this is incorrect. Code reuse and shorter devlopment cycles were the reason for SAND. The hardware module code is NOT all licensed code. With the exception of the ATM cards, there's more free code than licensed code in the hardware modules. It's incorrect because it's perfectly possible to write a monolithic driver under FreeBSD that's only available as an object module and instead links in to the FreeBSD answer to SAND - which is Netgraph. This is exactly how the WANic 400 driver is now. (except of course the WANic 4xx driver is source available) It is possible to have a monolithic driver set, but it doesn't accomplish the objective that we have (and you noted): to have ONE code tree for ALL platforms (save Windows, which is a different animal altogether). We don't want to see a return to the monolithic drivers of old under ANY platform. I'm not saying that monolithic drivers aren't possible, just that they aren't going to happen again. But you see that in this area SAND is no more standard than Netgraph is. SAND provides Linux users that run WANic cards a lot of stuff - but it is GPL which makes it difficult to use in many commercial FreeBSD projects. I don't think the use of GPL or LGPL prevents anyone from using it in a commercial project with FreeBSD, Linux or any OS. ImageStream, and other companies, are successfully using GPL and LGPL code in commercial projects. It's been discussed to death in this forum before but the worst possible thing that Imagestream could have done was to put SAND under GPL. If you had simply put it under BSD license then BOTH the BSD and Linux people could have used it, in fact Netgraph may have never been written, and a lot of other commercial UNIX's might have used it too (like Apple's MacOS X) I'll disagree, but the discussion is digressing here from where we started. I'm as disinterested in a license war as I was in an OS war. I believe you, I believe you. But, did the decision makers at SBS even know that the BSD community currently can't use the 500 series and above? And that discontinuting it would cut out that section of their market? Did you guys know that? They knew it. We knew it. It was such a small portion of the total market that they didn't care. We care, which is why I'm taking the time to have this discussion with all of you. During that time I've seen WANic or RISCom cards come up for bid exactly SIX times. And, THREE of the times I was the sole bidder and bought them. The other three times, well one was a 56K card, another the seller wanted $500 (hah) and the other the seller wanted another rediculous amount. During that time I've also kept tabs on what the commercial networking resale vendors that I also buy from have been doing and I've not seen anything at all marked RISCom, WANic, or Imagestream. So it's a limited option. I'd never buy commodity hardware used when you could buy it new for next to nothing (compared to even most USED Cisco gear). 1) The cards are almost impossible to identify if they are just loose with no documentation. Some vendors slap their moniker in unmistakable letters across all their cards, SDL/SBS and you
RE: FYI
There is depending on the price. I'll freely admit however that I have not priced the competitive serial sync cards that are currently supported under FreeBSD, so I don't know how the WANic 400 or 500 stacks up against them. For all I know right now there's someone just bringing a T1 interface card to the market with integrated CSU that sells for $30 per card which would make this entire discussion moot. $30 per card? Do tell, do tell. I'll buy 10,000 of them right now, and pay you $60 a card to buy them for me. What company would be foolish enough to offer a $30 T1 card? I have my credit card ready! Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
As someone else pointed out in this forum, the Hitachi chipset is an older design. I'm sure that it's probably possible today to design a sync controller chip that sells for a lot less than the Hitachi part, perhaps even under the $30 level. Certainly, async chips sell at that level in volume. It's too bad that IBM didn't decide to put a sync serial port on the original XT. :-) The conjecture and wishful thinking is nice. Unfortunately, the available chipsets today aren't running at or anywhere near the $30 range, which is why you don't see $75 T1 cards with CSUs (you see $750-$1200 ones). Let's dispense with all the talk about $75 T1 cards that don't exist (and won't for some time), whose licensing scheme is better, what driver architecture was developed for what reason and let's get back to the original issues: 1) Availability of the 400 series cards. If the FreeBSD market has the 400 series cards in such demand, then someone should be calling me with an order. I'll cut 20% off list for you if you tell me its for FreeBSD, and I'll still pledge 15% of your purchase price on top of that toward driver development. I'll give up my volume margin as a clear indication of my willingness to work with the community. The drivers BSDI developed and gave to the community for the 400 series are seriously out of date, by the way. Last I knew, they still referred to the cards as the n2pci and used some outdated code that has since been much improved. I'd be interested in working with a developer or developers to get some updated drivers out there for FreeBSD. This brings me to... 2) Driver development for FreeBSD We'll pledge 15% of the purchase of the aforementioned 400 series cards toward supporting a developer or developers to bring drivers to the FreeBSD market. The 400 series drivers need to be updated. There are a full line of cards available now that also need drivers. Even if no one in the community is willing to pledge money (through a card purchase or directly to a developer), I'm assuming that someone out there would be interested in developing the drivers. Again, if the FreeBSD market has WAN cards in such a high demand, we need to get developers on the driver development immediately. Now that you know we are interested, the code is available, and that we've pledged money toward it, I'd like to see someone in the community start working toward a solution, instead of complaining about how there isn't one. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
Better than a published interface and white paper, we also provide the direct code itself. You could certainly make a netgraph/SAND interface module. Doug On Tue, 16 Oct 2001, Julian Elischer wrote: On Tue, 16 Oct 2001, Doug Hass wrote: The hardware API or the actual register interface code, is a binary-only module that is snapped in to SAND. SAND is GPL and is similar to the FreeBSD Netgraph module - it provides all the higher-level protocol stuff, like Frame Relay, PPP, HDLC, and such. SAND goes between the OS TCP/IP stack and that binary only module. That's rather simplified, since SAND also does alot of other things, but you have the basics. If there's a published interface, we could make a netgraph/SAND interface module To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
Is there any way to get some of this - NOT under GPL and NOT under NDA? There's at least one person during this thread who was looking for a DS-3 card like a WANic 8xx You _did_ mention that some of the card modules in SAND are not under NDA? All of the code is licensed under either the LGPL or is available only under NDA. Neither of these should present a problem for developers who want to write FreeBSD drivers (whether they are based on the LGPL'ed SAND or are monolithic). We might be easier getting 10 buyers for DS3 cards than 100 buyers for WANic 4xx cards, if you get my drift. Well, if people don't mind buying cards with no drivers...The reason for offering the 400 series at a discount was to solve the supply issue that you raised originally. Doug, as a FYI, I believe that I can fill in a bit on the state of the sr driver. They don't actually refer to the cards as the n2pci (now, at least) They have had work done to them already by John Hay and Julian. I'm glad to hear that the name was corrected. If someone is interested, there is a newer development kit (actually several newer ones) that would improve that driver significantly, especially in high load situations. I'm certain that those improvements are not in the driver, since the development kit containing them is only available under license. This support does NOT appear in the FreeBSD driver. It's not possible to use port1 (the one with the CSU port) in a FreeBSD system at this time. It may be that John Hay chopped out this support but more likely he was working with an older version of the driver. There's no reason that you can't use the N2csu port in a FreeBSD system. The code to do this has been freely available for nearly 6 years. We released a version of the n2 code to open source as well. The second bug only appears on WANic 405's and is triggered by high volume rates on both interfaces simultaneously. Rod has been unable to isolate the problem but he and I confirmed that it only appears with dual-port cards. The bug causes about 10% packet loss to be noted on a Pentium 200. I believe that it is possible to minimize the effects of this bug by using the cards in a much faster CPU. Actually, it will happen with the one-port cards, too. As you increase the CPU or the clock rate, the problem gets worse. We've fixed this (among other things), which is why I recommended getting ahold of the newer DDK. Other than that the FreeBSD sr driver is stable, has not caused a crash or other problem on the hardware I've used it on over the last year and a half, on a busy Internet router that runs BGP. Great! That's what I like to hear. The hardware is quite reliable and well-proven, and I'm glad your drivers are working well. Well, we _had_ a solution - the 400/405 that worked well, and has a Netgraph-enabled driver for it. I guess that nobody let you guys know at Imagestream that developers in the FreeBSD community were maintaining the old BSDI driver. Sigh. We knew that the driver had undergone some maintainence. It still has bugs, and doesn't take advantage of the later code advances in the development kit, but if it works well enough for you, then that's not an issue. If you don't want to improve the driver beyond where it is now, that's definitely up to you. You know that improvements and bug fixes exist if you ever decide they are affect your use of the card enough to put them in place. What we don't have is a solution for the 5xx and later cards. But I think that there would be even more interest on a DS3 card like the WANic 8xx Development tools for the later cards have been freely available (under NDA) for 5 years now. No one is holding anyone in the FreeBSD community back. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
Doug, in the entire history of the FreeBSD project, when given a choice between a better driver or code that is closed source, and a worse driver that has open source, the FreeBSD community has never chosen the driver or code with closed source. In fact I can only remember ONCE that the Project has recommended against freely available BSD code - and they did so in favor of GPL code, not closed source code - and this was for the coprocessor emulator (used for 386 and 486SX chips only) The only time that FreeBSD gets involved in closed-source code is when there is simply NO other alternative - like in this case where the register interface specs are being withheld. We certainly support the right for companies to protect their intellectual property in whatever way they see fit, even if the FreeBSD community does not. The lack of flexibility in accepting various requirements illustrates the difference between an OS WITH legs in the market and one WITHOUT legs. Much to my chagrin, FreeBSD continues to fall more and more into the latter category. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
We certainly support the right for companies to protect their intellectual property in whatever way they see fit, even if the FreeBSD community does not. Doug; I would recommend against falling for Ted's flamebait here, since that's really all it is. His characterisation of the FreeBSD Project's attitude towards proprietary drivers fails to mention many of the other factors that get weighed into these decisions, and I think he's missing a lot of history. I'm glad someone else is speaking up--all I've heard is Ted's point of view (from him, and from others who have said the same thing: FreeBSD only accepts BSD licensed code, period.) The lack of flexibility in accepting various requirements illustrates the difference between an OS WITH legs in the market and one WITHOUT legs. And you probably shouldn't try to respond with generalisations that are meant to be personal attacks. Think about who you're trying to endear yourself to, eh? Much to my chagrin, FreeBSD continues to fall more and more into the latter category. If we're legless, it's probably because we're drunk on our own success. 8) It's not a generalization at all. Honestly, compared to the market traction that Linux, VxWorks, Solaris and others have, FreeBSD is definitely without legs. The WAN card and RAS card markets are good examples of where the attitude toward BSD-licensed code or bust has resulted in FreeBSD being largely left out of the party. Three of the largest manufacturers in these segments (SBS, Cyclades, and Ariel) all support Linux and NT, but do not have BSD support. I've been frusturated repeatedly over the past few years as I try to continue to use FreeBSD myself for different applications. It's too bad we can't find a way to include more companies and solutions instead of continuing to find ways to EXCLUDE them... Seriously though; if you don't want to release sources for a driver for whatever reason, that's fine. But bear in mind that if you don't support your binary-only driver in a realistic and attentive fashion, you're going to make people unhappy, and they will turn to solutions that they can maintain themselves, or that they can badger other people into maintaining. Agreed. Maintaining code has never been a problem for us. We're talking about someone else in the FreeBSD community maintaining these drivers, though, not ImageStream. Their attentiveness to bugs would directly impact that. This will be my last message on this topic. I feel as if this discussion is going round and round and has no real end or purpose at this point. I'll quit wasting bandwidth. :-) If anyone has an interest in adding support for the SBS WAN cards to FreeBSD, feel free to contact me. I'll be glad to help. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Problems with booting of CD-ROM (fwd)
Thomas Dixon writes: | | | On Tue, 16 Oct 2001, John Baldwin wrote: | | | On 16-Oct-01 Thomas Dixon wrote: | I'm trying to make a bootable CD using the cdboot program that come with | freeBSD in /sys/i386/boot/cdboot. The computer I'm trying to do this on | definately boots other CDs as it has booted several other CDs. However | using a CD I've made using mkisofs and cdboot it gives the error; | | Your BIOS int 0x13 extensions seem to be disabled. | It's impossible to boot a CD-ROM without them. | (BIOS int 0x13 fn 0x4b01 yielded error 1) | | I'm using an Asus P5A motherboard, there appears to be no way to enable | the int 0x13 extensions in the BIOS and there is nothing in the manual | that refers to these. | | Any ideas why this error is coming up or how to fix it? | | Don't use cdboot or cdldr, they don't qutie work yet. :( | | Instead, make a floppy image and use that to boot. | | I've tried this and I couldn't figure out the syntax for loader.rc to load | the file system from the cd-rom, any ideas? I'd skip the MFS step and just put the kernel on the boot floppy with loader and friends. Then in /boot/loader.rc add: boot -C So it looks something like: \ Loader.rc \ $FreeBSD: src/sys/boot/forth/loader.rc,v 1.2 1999/11/24 17:59:37 dcs Exp $ \ \ Includes additional commands include /boot/loader.4th \ Reads and processes loader.rc start \ Tests for password -- executes autoboot first if a password was defined check-password \ Unless set otherwise, autoboot is automatic at this point boot -C Atleast this works for me even on IBM machine as of 4.4-Release! If you run out of room for your kernel (even if you gzip it) you can kldload modules off the CD during startup. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
If anyone has an interest in adding support for the SBS WAN cards to FreeBSD, feel free to contact me. I'll be glad to help. Just package your driver with your cards, or stick it on your support site. The whole point being that you don't *have* to get your code into the tree; you can maintain it successfully without either a) introducing overhead for us handling your module, or b) introducing latency for you trying to push a new version through our release process. I get the impression you haven't quite gotten the idea here yet; you don't *need* to be in the base distribution, and in many cases it's better not to be simply because it involves less work for everyone. O.k.--one more message. :-) We don't want to be in the base distribution. Never have wanted to be, nor have I indicated in my messages that we wanted to be. All we would like to see drivers for FreeBSD available in the market. Period. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
If you didn't say it, then you weren't the one I was talking about, was I? :-) I got several other private mails saying that BSD licensed code was the one and only way, and 2 or 3 mails (from Ben, among others) saying that BSD-licensed was preferred. Either approach is as flawed as someone who claims GPL only or GPL preferred. The license terms of add-on drivers and products should be set according to the needs of the authoring person or company, in my opinion. Doug On Wed, 17 Oct 2001, void wrote: On Wed, Oct 17, 2001 at 12:19:34PM -0500, Doug Hass wrote: I'm glad someone else is speaking up--all I've heard is Ted's point of view (from him, and from others who have said the same thing: FreeBSD only accepts BSD licensed code, period.) I said to you in private mail that where there's a BSD-licensed solution and a non-BSD-licensed solution, all else being roughly equal, FreeBSD tends towards the BSD-licensed solution. Not the same thing at all. -- Ben An art scene of delight I created this to be ...-- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Linus Torvalds and urgent message about your future!
On Wed, 5 Dec 2001, Miss Cleo wrote: [top_urgent.gif] Linus Torvalds, you must have friends in high places. I've been authorized to issue you a Special Tarot Reading! You can learn about important events concerning your future. It is vital that you call immediately! So, make this FREE CALL to 1-800-311-1736 ROFLMAO. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Creative Labs Nomad via usb ?
On Thu, 20 Dec 2001, Ulf Zimmermann wrote: Hello, Frys has currently the Creative Labs Nomad with 6gb disk for $150, so I thought to get me one. Out of curiosity I plugged it into a FreeBSD system. It shows up as: Dec 20 12:41:20 ulfbsd /kernel: ugen0: Philips product 0x0222, rev 1.00/1.00, addr 3 Has anyone looked at this to see if you could send files to it from FreeBSD ? Try adding the vendor/product ID to usbdevs then rebuild umass. I suspect it requires a bit more than that :) Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Looking for a sysctl logger
On Fri, 21 Dec 2001, Robert Sexton wrote: I'm looking for a program that can interrogate the sysctl mechanism and dump the data out for use by rrd or some other thing. I have something that does this now for acpi battery info (I feed the data into rrd for analysis), but I was hoping for something more general purpose. And no, I don't want to write it in perl : -) I'm trying to make it low impact, hence c. mrtg? :-) You're just calling sysctl and returning the result; it could be done in a very short shell script. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Does FreeBSD have a problem with some AMD processors?
On Fri, 28 Dec 2001 11:57:44 +0100, Nils Holland wrote: Now, I have found a lot of similar stories on the web. I guess some mainboard manufacturer's (and even VIA as a chipset manufacturer) seem to care very little about quality assurance. That's actually sad: AMD's best processors aren't worth a dime if the components they depend on are cheap crap. As a side note: I have bought numeros board from Epox and never had a single problem with them, so in my opionion, Epox (together with ASUS) is probably one of the companies I would recommend people to buy boards from, but Chaintech and other cheapies should probably be avoided... abit has been extremely good to me. even windows 98 doesn't crash on it i have the abit kt7a with a 1gHz socket a athlon. I don't like Soyo, FICS, and a bunch of others i cant think of --- doug reynolds | the maverick | [EMAIL PROTECTED] PGP Public Key Fingerprint: 6E7B 9993 B503 6D45 E33A 2019 26E5 C1DB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Does FreeBSD have a problem with some AMD processors?
On Fri, 28 Dec 2001 22:47:58 +0100, Nils Holland wrote: On Fri, Dec 28, 2001 at 02:46:12PM -0600, Glenn Johnson stood up and spoke: As far as I can tell though if I set the memory clock to 100MHz the problem goes away completely, or at least I have not observed it happen yet. So it's PC133 RAM but only works properly at 100 Mhz? Well, I guess I have seen the same problem: I once had a system with a front side bus of 100 Mhz, and I could set the RAM clock to either host clock or host click + 33 Mhz. Now, I choose the second method, because according to my calculation, a host clock of 100 Mhz plus an additional 33 Mhz are 133 Mhz, and thus just what my PC133 RAM wants. However, the system would run less than reliable with this setting, so I later set the RAM clock to host clock, so 100 Mhz. I no longer own that system - I had these problems back in June... Anyway, for most memory problems, I have found the tool memtest86 (http://www.memtest86.com) to be a good test. While, as far as I have heard, this utility does not detect *all* possible errors, it has often been able to give me good insight of the stability of my RAM and overall system. I know back in the days when PC100 was new and the prices came down a little bit, but still really expensive, a few manufactures pirated a lot of PC66 and made some changes to have it work like PC100. but it wasn't stable. maybe people are doing that with pc133.. it wouldnt surprise me. --- doug reynolds | the maverick | [EMAIL PROTECTED] PGP Public Key Fingerprint: 6E7B 9993 B503 6D45 E33A 2019 26E5 C1DB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Patch for SIS630ET embedded NIC
I would appreciate if people that have SIS Ethernet controllers to test
out this patch. I added support for the 630ET based on the changes
in the Linux driver. It seems to work fine.
I'd like to get some yes it doesn't break anything or heh, now my
SIS Ethernet controller works now comments before commiting this change.
The patch is based on -stable right now. It applies to -current cleanly.
BTW I tested this on a Asus TUSI motherboard.
Thanks,
Doug A.
Index: if_sis.c
===
RCS file: /cvs/src/sys/pci/if_sis.c,v
retrieving revision 1.13.4.16
diff -c -r1.13.4.16 if_sis.c
*** if_sis.c18 Dec 2001 02:33:27 - 1.13.4.16
--- if_sis.c2 Jan 2002 20:54:06 -
***
*** 147,152
--- 147,153
#ifdef __i386__
static void sis_read_cmos __P((struct sis_softc *, device_t, caddr_t,
int, int));
+ static void sis_read_mac __P((struct sis_softc *, device_t, caddr_t));
static device_t sis_find_bridge __P((device_t));
#endif
***
*** 439,444
--- 440,473
pci_write_config(bridge, 0x48, reg ~0x40, 1);
return;
}
+
+ static void sis_read_mac(sc, dev, dest)
+ struct sis_softc*sc;
+ device_tdev;
+ caddr_t dest;
+ {
+ u_int32_t save;
+ u_int32_t save2;
+
+ save = CSR_READ_4(sc, SIS_RXFILT_CTL);
+ save2 = CSR_READ_4(sc, SIS_CSR);
+
+ CSR_WRITE_4(sc, SIS_CSR, SIS_CSR_RELOAD | save);
+ CSR_WRITE_4(sc, SIS_CSR, 0);
+
+ CSR_WRITE_4(sc, SIS_RXFILT_CTL, save ~SIS_RXFILTCTL_ENABLE);
+
+ CSR_WRITE_4(sc, SIS_RXFILT_CTL, SIS_FILTADDR_PAR0);
+ ((u_int16_t *)dest)[0] = CSR_READ_4(sc, SIS_RXFILT_DATA);
+ CSR_WRITE_4(sc, SIS_RXFILT_CTL,SIS_FILTADDR_PAR1);
+ ((u_int16_t *)dest)[1] = CSR_READ_4(sc, SIS_RXFILT_DATA);
+ CSR_WRITE_4(sc, SIS_RXFILT_CTL, SIS_FILTADDR_PAR2);
+ ((u_int16_t *)dest)[2] = CSR_READ_4(sc, SIS_RXFILT_DATA);
+
+ CSR_WRITE_4(sc, SIS_RXFILT_CTL, save);
+ CSR_WRITE_4(sc, SIS_CSR, save2);
+ return;
+ }
#endif
static int sis_miibus_readreg(dev, phy, reg)
***
*** 889,896
command = pci_read_config(dev, PCIR_REVID, 1);
if (command == SIS_REV_630S ||
command == SIS_REV_630E ||
! command == SIS_REV_630EA1)
sis_read_cmos(sc, dev, (caddr_t)eaddr, 0x9, 6);
else
#endif
sis_read_eeprom(sc, (caddr_t)eaddr,
--- 918,929
command = pci_read_config(dev, PCIR_REVID, 1);
if (command == SIS_REV_630S ||
command == SIS_REV_630E ||
! command == SIS_REV_630EA1 ||
! command == SIS_REV_630ET)
sis_read_cmos(sc, dev, (caddr_t)eaddr, 0x9, 6);
+
+ else if ((command 0x81) (command = 0x90))
+ sis_read_mac(sc, dev, (caddr_t)eaddr);
else
#endif
sis_read_eeprom(sc, (caddr_t)eaddr,
***
*** 903,908
--- 936,948
*/
printf(sis%d: Ethernet address: %6D\n, unit, eaddr, :);
+ /*
+* From the Linux driver:
+* 630ET : set the mii access mode as software-mode
+*/
+ if (command == SIS_REV_630ET)
+ SIS_SETBIT(sc, SIS_CSR, SIS_CSR_ACCESS_MODE);
+
sc-sis_unit = unit;
callout_handle_init(sc-sis_stat_ch);
bcopy(eaddr, (char *)sc-arpcom.ac_enaddr, ETHER_ADDR_LEN);
Index: if_sisreg.h
===
RCS file: /cvs/src/sys/pci/if_sisreg.h,v
retrieving revision 1.1.4.6
diff -c -r1.1.4.6 if_sisreg.h
*** if_sisreg.h 8 Dec 2001 00:04:15 - 1.1.4.6
--- if_sisreg.h 2 Jan 2002 20:54:06 -
***
*** 105,110
--- 105,112
#define SIS_CSR_RX_RESET 0x0020
#define SIS_CSR_SOFTINTR 0x0080
#define SIS_CSR_RESET 0x0100
+ #define SIS_CSR_ACCESS_MODE 0x0200
+ #define SIS_CSR_RELOAD0x0400
#define SIS_CFG_BIGENDIAN 0x0001
#define SIS_CFG_PERR_DETECT 0x0008
***
*** 367,372
--- 369,375
#define SIS_REV_630E 0x0081
#define SIS_REV_630S 0x0082
#define SIS_REV_630EA10x0083
+ #define SIS_REV_630ET 0x0083
/*
* NatSemi vendor ID
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: what slice did I boot from?
On Fri, 4 Jan 2002, Louis A. Mamakos wrote: I've got one of the litle soekris net4501 boards that I use as a router/firewall/NAT box, and it works really good. I have a stripped down FreeBSD system that I run in a 16MB partition on an 32MB Compact Flash card plugged into the net4501. Actually, I have two 16MB slices, and my goal is to be running from one, and installing the next version into the second slice. That way, if the new one distribution screws up, I can back-out to the older on on the other partition. I've actually been monkeying with this and ran into a bigger problem .. boot2 only knows how to handle one FreeBSD slice. You have to play loader(8) tricks to boot the second slice. Specifically... . abort the kernel load . 'set currdev=disk1s2a:' . 'load /boot/kernel/kernel' (and so forth) Particularly if you are running -CURRENT you must compile in your device hints, otherwise everything gets confused. For picking the appropriate slice, you are up a creek all right. Assumably at some point you have to select a slice anyway, and you can use that to rewrite fstab. Depending on the old compatibilty slice will certainly get you in hot water. I've been thinking about hacking up some forth to handle this switching programatically, so you get a nice menu to pick which FreeBSD slice to boot from if you enable the feature. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sessionlimit
On Sat, 5 Jan 2002, Thomas Wahyudi wrote: Hi all, if I want to change behavior of sessionlimit behavior in login.conf, where I should look first since I can't find it in /usr/src/libutil thx before. In a lot of cases, the capabilities have been defined but not actually implemented anywhere. sessionlimit may be one such option. I'd suggest checking login(8) since that's what generally enforces the limits (libutil just reads them). Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: what slice did I boot from?
On Sat, 5 Jan 2002, Louis A. Mamakos wrote: Hmm.. I'm running a 4.4-STABLE based system on the hardware, and don't seem to have any problem booting off the other slice. Right now, it's runnong on the second slice of ATA Compact Flash disk: # kenv LINES=24 console=vidconsole currdev=disk0s2a: interpret=ok kernel=/kernel kernel_options= kernelname=/kernel loaddev=disk0s2a: root_disk_unit=0 vfs.root.mountfrom=ufs:/dev/ad0s2a # You're playing the same trick I am, just in more words :) Which slice is loader.conf on? It would be just fine to have the boot0 boot manager be the mechanism to do all this. That's an easy toggle between the two alternatives, though harder to do an automatic fallback, perhaps. You try boot0 ... that's where my problem showed up. One would boot but the other says Invalid partition. This is a heavily hacked install though (since sysinstall won't let you put a second / into a second slice when a first FreeBSD slice already exists). Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: what slice did I boot from?
On Sat, 5 Jan 2002, Louis A. Mamakos wrote: Sorry, I wasn't clear. I don't have any explicit configuration in my loader.conf; this is just the environment that the loader cooked up all by itself. Each slice has it's own own loader along with a complete root file system. Oops I didn't notice the kenv :) It would be just fine to have the boot0 boot manager be the mechanism to do all this. That's an easy toggle between the two alternatives, though harder to do an automatic fallback, perhaps. You try boot0 ... that's where my problem showed up. One would boot but the other says Invalid partition. This is a heavily hacked install though (since sysinstall won't let you put a second / into a second slice when a first FreeBSD slice already exists). What you might try is making sure that the other partition starts on a cylinder boundary. I've noticed that the BIOS on some machines have real heartburn when the slice starts at some random location not coincident with a cylinder boundary. I don't know why, and I'm pretty sure I don't want to know :=) That's a distinct possibility. I made it with sysinstall but I made the previous slice a wierd size (not a power of 2). sysinstall probably didn't quite justify it to the BIOS's want. I'll have to check the boot0 code though... Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Oh my god, Google has a USENET archive going back to 1981!
On Mon, 7 Jan 2002, Matthew Dillon wrote: Oh my god. I don't even *remember* writing this one! This was when I was 18. Google's archive isn't complete but they've done an incredible job getting as much as they have. Pet, C64, DMail, Shell (for the amiga), backup/restore utilities, dme, dterm, AmigaUUCP, DICE, etc. It's all there in bits and pieces, complete with my trademark spelling errors. That brings back memories. We wrote our own firmware for the 1541 since the commodore DOS was so slow. I forget what transfer rate we managed but it was much better than the standard code. Bit of a sod to debug though. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: left over shells/processes
On Fri, 30 May 2003, jason fiddian wrote: i feel i'm missing something simple here. we have a freebsd 4.6 server that approx 20 users telnet into to access a retail application. if a user closes their telnet session without logging out correctly it leaves behind the shell and any processes attached to it. how can we kill these leftover shells processes if this occurs? Is your app handling SIGHUP? If not, the app will stay running, as well as its parents. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ramdisk??
On Mon, 9 Jun 2003 [EMAIL PROTECTED] wrote: (sorry about cross-posting this question. not sure which list is better) I want to to know how to create a ram file system for /var and /tmp so that i can boot from flash memory and mount those two file systems on ramfs. I've looked for howto's online but haven't found anything. any suggestions Did you find rc.diskless2, which sets all this up for you? This is a good description of how to use it (and set up other stuff for diskless/readonly media systems): http://neon1.net/misc/minibsd.html -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_4 buildworld fails in colldef with NO_BIND
Should have poked at this a bit more before posting, sorry. I was experimenting with having NO_BIND in make.conf, along with deleting all the includes that are part of BIND. That combination is what caused the failure. To add insult to injury, the early colldef build is looking for arpa/inet.h in /usr/include, not in /usr/obj. I'll have to go back and take another look at the NO_BIND stuff as it relates to includes... Doug On Wed, 2 Jul 2003, Doug Barton wrote: Very shortly after starting the buildworld, it fails in colldef: === usr.bin/colldef /usr/obj/home/src/i386/home/src/usr.bin/colldef created for /home/src/usr.bin/colldef yacc -d /home/src/usr.bin/colldef/parse.y cp y.tab.c parse.c lex -t -8 -i /home/src/usr.bin/colldef/scan.l scan.c rm -f .depend mkdep -f .depend -a-I. -I/home/src/usr.bin/colldef -I/home/src/usr.bin/colldef/../../lib/libc/locale -DCOLLATE_DEBUG -DYY_NO_UNPUT -D__FBSDID=__RCSID parse.c scan.c /home/src/usr.bin/colldef/parse.y:32: arpa/inet.h: No such file or directory mkdep: compile failed *** Error code 1 I looked in /usr/obj/home/src/i386/usr/include/arpa/ and indeed, inet.h is not there, but I can't figure out why. This is starting with a clean obj directory, and nothing fancier than 'make -DNOCLEAN buildworld'. Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Console serial speed
Russell Cattelan writes: | How does one set the serial speed of the console. | I changed the boot loader speed to 57600 in make.conf | but the kernel seems to chose random speeds each time | it's booted. | Sometimes it's 9600 sometimes it 115200 other times | it's 38400. | | Note this is on 5.x current You might want to check sys/isa/sio.c in function siocngetspeed. I comment out the return (rclk / (16UL * divisor)); on some of my stable boxes. I've seen a few motherboards that result in a messed up console if I don't do it (ie. wrong speed). Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Console serial speed
Russell Cattelan writes: | On Wed, 2003-07-30 at 21:58, Doug Ambrisko wrote: | Russell Cattelan writes: | | How does one set the serial speed of the console. | | I changed the boot loader speed to 57600 in make.conf | | but the kernel seems to chose random speeds each time | | it's booted. | | Sometimes it's 9600 sometimes it 115200 other times | | it's 38400. | | | | Note this is on 5.x current | | You might want to check sys/isa/sio.c in function siocngetspeed. | I comment out the return (rclk / (16UL * divisor)); on some of my | stable boxes. I've seen a few motherboards that result in a messed | up console if I don't do it (ie. wrong speed). | | I changed the return val to be CONSPEED. | The machine now boots with the console speed correctly set | to 57600 | | Thanks... suppose a proper fix would be good :-) I'm not sure what a proper fix would be. We try to read the speed out of the UART and it fails to get what it was set to. This could be broken hardware etc. Personally I haven't had the motivation to figure out why some machines fail and I just wacked the code to make it work so I can actually fix the real problem I was working on! Maybe some #define that could over-ride everything and just set might be a fix for broken HW. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: specifying RAM size at boot?
Daniel Ellard writes: | I thought this was configurable by setting a variable in | /boot/loader.conf and rebooting, but I haven't been able to find the | right variable(s). (someone suggested MAXMEM, but this doesn' | seem to do anything at all.) I think it is hw.physmem=size I used it at a prior company. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for thread testers
On Wed, 27 Aug 2003, Scott Long wrote: All, This is kind of an unconventional call for help. As we approach the release of 5.2, we'd really like to show off the performance and stability of our new threading packages. So, I'm looking for people to volunteer to go out and put some of the thread-capable enterprise and desktop packages to the test. Packages that I would most like to see are: BIND 9 9.2.2 probably not a good test case, I'd suggest trying ftp://ftp.isc.org/isc/bind9/9.2.3rc1/bind-9.2.3rc1.tar.gz instead. Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: refreshing AGP Card Memory??
On Sat, 30 Aug 2003, Stone Gecko wrote: I have a GF4 MX440 Video card in 5.1_Release running KDE3.1.3 that keeps either locking up or putting vertical red/blue lines on the screen. Are you by any chance running the binary drivers provided by nvidia with this card? I have exactly the same card, using those drivers, and haven't had any problems like you describe. Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible change for 4.9 rc file?
I oppose this going in prior to 4.9 just on general principles. The concept looks sound on a very light review though. If you'd like more in depth review, please forward your patch to [EMAIL PROTECTED] Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Important changes to the .org tld today. (fwd)
FYI, Doug -- Forwarded message -- Date: Fri, 05 Sep 2003 06:03:15 -0700 From: Rodney Joffe [EMAIL PROTECTED] Organization: UltraDNS Corp Subject: Important changes to the .org tld today. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 During the root zone (.) update later today, specifically with root zone serial number 2003090501, the entries for .org will me modified. The current zone entry contains the following authoritative nameservers for the .org tld: org.2D IN NSA7.NSTLD.COM. org.2D IN NSL7.NSTLD.COM. org.2D IN NSG7.NSTLD.COM. org.2D IN NSF7.NSTLD.COM. org.2D IN NSM5.NSTLD.COM. org.2D IN NSTLD1.ULTRADNS.NET. org.2D IN NSTLD2.ULTRADNS.NET. org.2D IN NSJ5.NSTLD.COM. org.2D IN NSI5.NSTLD.COM. org.2D IN NSC5.NSTLD.COM. org.2D IN NSE5.NSTLD.COM. Effective with the 2003090501 load, the entry will reflect the removal of the Verisign NSTLD.COM nameservers. The zone entry will therefore contain the following only: org.2D IN NSTLD1.ULTRADNS.NET. org.2D IN NSTLD2.ULTRADNS.NET. If you have the 9 ??.NSTLD.COM nameservers cached or hard coded in any way, you may wish to flush your cache or modify your nameservers in the near future to avoid any inconsistent or stale data, and you may want to make your system administrators, NOCs and customer support groups aware of the changes. The .org zone file will continue to be pushed to the Verisign nameservers for a short period of time. However due to the fact that the UltraDNS nameservers publish and propagate zone changes globally within 5 minutes, rather than the twice daily update schedule of the Verisign nameservers, answers from the NSTLD.COM nameservers may be out of date and inconsistent with the actual SOA for up to 24 hours after a change is accepted by the Public Interest Registry (PIR.org). Any questions or concerns regarding this change should be directed to the PIR (http://www.pir.org). Sincerely, Rodney Joffe CTO and Chairman UltraDNS Corp. http://www.ultradns.com -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBP1iJJEa3pZtqJ3OwEQJvwACdHkKdAW3TqDSpOJVoguhFAx0YebwAnAw9 c6fW3PeXcgvjwhvLIPaxRVEW =+m9c -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenBFS (was Re: C++ code in a kernel module?)
On Mon, 8 Sep 2003, Pedro F. Giffuni wrote: Hi; Attached is a good reasons why someone my want to use C++ in the kernel. Sorry, I don't see anything here except this is all we know how to do. But, I'm a curmudgeon. :) Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: flush on close
Remove -fs. Don't crosspost, please. On Wed, 10 Sep 2003, Eno Thereska wrote: In FreeBSD 4.4, I am noticing a huge number of calls to ffs_fsync() (in /sys/ufs/ffs/ffs_vnops.c) when running a benchmark like Postmark. Were you using softupdates, or the sync or async mount options? I believe this is correct (and safe) behavior for the default case. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A new sort utility
On Mon, 15 Sep 2003, Richard Coleman wrote: Garance A Drosihn wrote: At 8:53 PM +1000 9/15/03, Tim Robbins wrote: Comments/patches are welcome. As the History suggestion of the manual page suggests, my plan is to get this in to FreeBSD 6, along with replacements for some other GNU tools. Might we put this in freebsd-current (5.x), but under some other name? sortbsd, or something? Why would you want to do that? Unless the performance difference is huge, I don't see the problem. Since the number of people that really that extra 10% (or whatever) of speed (for sort) is small, I would suggest the reverse. Replace the current sort with the BSD licensed version, and move the current one to a port gnu-sort, or whatever. This was exactly what I was thinking. Tim, can you mail -arch with this proposal? Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
On Tue, 16 Sep 2003, M. Warner Losh wrote: I think we should put a filter for this nonsense into the base system. ISC is in the process of releasing patched versions of BIND, which I plan to take advantage of. :) Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I need help fixing the agp_nvidia.c driver
On Tue, 2 Dec 2003, jason wrote: Hello everyone, I have a problem loading agp. Every time I do load it at boot from rc.conf and do a startx the machine hard locks. One definition of sanity is doing the same thing over and over, and expecting a different result. :) You should load it in /boot/loader.conf[.local]: agp_load=YES Actually, I do better with nvidia's driver without agp loaded, FWIW. Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, 2004-01-07 at 20:19, Robert Watson wrote: On Wed, 7 Jan 2004, Roman Neuhauser wrote: [1] has core@ considered subversion (devel/subversion)? Everyone has their eyes wide open looking for a revision control alternative, but last time it was discussed in detail (a few months ago?) it seemed there still wasn't a viable alternative. On the src tree side, FreeBSD committers are making extensive use of a Perforce repository (which supports lightweight branching, etc, etc), but there's a strong desire to maintain the base system on a purely open source revision control system, and migrating your data is no lightweight proposition. Likewise, you really want to trust your data only to tried and true solutions, I think -- we want to build an OS, not a version control system, if at all possible :-). Subversion seems to be the current favorite to keep an eye on, but the public release seemed not to have realized the promise of the design (i.e., no three-way merges, etc). You can peruse the FreeBSD Perforce repository via the web using http://perforce.FreeBSD.org/ -- it contains a lot of personal and small project sandboxes that might be of interest. For example, we do all the primary TrustedBSD development in Perforce before merging it to the main CVS repository. I've been re-evaluating the current subversion over the last couple of weeks and its holding up pretty well so far. It still misses the repeated merge thing that p4 does so well but in practice, merging does seem to be a lot easier than with CVS due to the repository-wide revision numbering system - that makes it easy to remember when your last merge happened so that you don't merge a change twice. The three main showstoppers for moving FreeBSD to subversion would be: 1. A replacement for cvsup. Probably quite doable using svnadmin dump and load. 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. 3. Converting the repository. This is a tricky one - I tried the current version of the migration scripts and they barfed and died pretty quickly. Still, I'm pretty sure that the svn developers are planning to fix most of those problems. From mailing-list archives, it appears that they are using our cvs tree as test material for the migration scripts. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Thu, 2004-01-08 at 18:05, Munish Chopra wrote: On 2004-01-08 17:29 +, Doug Rabson wrote: [...] The three main showstoppers for moving FreeBSD to subversion would be: 1. A replacement for cvsup. Probably quite doable using svnadmin dump and load. 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. 3. Converting the repository. This is a tricky one - I tried the current version of the migration scripts and they barfed and died pretty quickly. Still, I'm pretty sure that the svn developers are planning to fix most of those problems. From mailing-list archives, it appears that they are using our cvs tree as test material for the migration scripts. Perfection (or as close as possible) of cvs2svn.py is scheduled for 1.0. They've entered beta now, but without scanning the lists I suppose that's sometime 2004. I've noticed some other projects having problems with repository conversion, but at least things seem to be getting better. There seems to be a reasonably common problem where a single branch point ends up with more than one branch name. This certainly happens in the FreeBSD cvs. If you ignore that error, it gets about 1000 commits into the conversion but then dies with an error in the branch handling code (probably caused by the first problem). There are outstanding problems with vendor branches which it looks like they will fix before 1.0. I've been using the scripts to convert another large repository and they are not quick - my current test has been going for 2.5 days now and it still has about six months worth of repository to convert (the cvs history goes back about seven years in total). I estimate that the complete conversion will take about 3 days and will contain about 15000 commits... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
On Sun, 2004-01-11 at 00:05, Peter Jeremy wrote: On Sat, Jan 10, 2004 at 05:01:13PM -0500, Garance A Drosihn wrote: At 9:35 PM + 1/10/04, Andrew Boothman wrote: Peter Schuller wrote: Most of the noteworthy features of subversion are listed on the project front page: http://subversion.tigris.org/ A significant one of which is the fact that it's available under a BSD-style license. Meaning that the project wouldn't have to rely on more GPLed code. I wonder if our SCM would be brought into the base system or whether it would just be left in ports? We haven't even started to *test* subversion yet, so I think it's a bit early to worry about this question! I disagree. Andrew raised two issues (type of license and port vs base location). The type of license is an input to the decision as to which SCM to choose - BSD would be preferable but GPL is probably acceptable (given two potential SCMs with similar features, the BSD licensed one would be selected in preference to the GPL one). Subversion has a friendly BSD-ish license but it depends heavily on Sleepycat DB which doesn't. I imagine that if we do end up using it one day, it would be best managed as a port rather than part of the base system. I just don't see many people agreeing on importing subversion+db-4.2+apache2 into src/contrib... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.9 kernel panics on a poweredge 2650
Bogdan TARU writes: | | Hi Hackers, | | Ok, now some more infos about my problem: | | We have 3 identical webservers (as hw configuration), and the same | kernel and applications running on all three. They get mostly the same | traffic (dns round-robined). They all run 4.9-RELEASE. I have | experienced repetable crashes on all three, so there is no problem | with the hardware (or the possibility of such a thing is too small). | | I have come to think that the problem is with the kernel memory | space, which is too low. I have compiled the kernel from Generic, by | performing the following modifications: | | - maxusers set to 128 | - activated SMP (the cpus are HTT-compatible) | - kva_pages set 256 (each box has 2GB of ram and 2Gb of swap) | - PMAP_SHPGPERPROC=401 (for apache) | - ACCEPT_FILTER_DATA and ACCEPT_FILTER_HTTP | - removed unnecessary drivers from the kernel | | /etc/sysctl.conf looks like: | | | net.inet.tcp.msl=100 | net.inet.tcp.blackhole=1 | # Hyperthreading | machdep.cpu_idle_hlt=1 | | kern.ipc.somaxconn=4096 | kern.maxfiles=65535 | vfs.vmiodirenable=1 | kern.ipc.shm_use_phys=1 | net.inet.tcp.sendspace=16384 | | | The boxes run w/o a problem for about 2-3 days, after which they | panic with 'page not present' in different processes (sshd, httpd, | etc). I guess the real reason for this is the low value for kvm_free: | | | (web1)[~] sysctl -a | grep vm.kvm | vm.kvm_size: 1069543424 | vm.kvm_free: 4190208 This isn't good you have about 4M of kernel memory left resulting in your panic. A quick fix to try is to bump up kva_pages to 384. Just recompile the kernel with that and install. There are some undocumented/ poorly sysctl that can free up some memory. I should put something together but I'm working on some other issues right now. For some hints look at vmstat -z and look at how much memory you use. Note that the limit can be read as allocated and gone from the system to be used only by this zone. Trim down some things that are huge but not used much. Now the tuneable to do that via loader.conf can be a challenge to derive. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-RC2 freezing - ATA related?
On Wed, 18 May 2005, Jamie Heckford wrote: Hi Peter, On Thu, May 19, 2005 at 05:53:12AM +1000, Peter Jeremy wrote: On Wed, 2005-May-18 16:03:16 +0100, Jamie Heckford wrote: Managed to get a dump on our system for a similar prob we are getting: That traceback looks like a panic, not a deadlock. What was the panic message? Only have remote access to the box im afraid, is there anyway I can obtain the panic message? print msgbuf should do it #2 0xc0513474 in panic (fmt=0xc06c3da5 %s) at /usr/src/sys/kern/kern_shutdown.c:566 ... #7 0xc0510018 in crcopy () at /usr/src/sys/kern/kern_prot.c:1810 #8 0xc0598c77 in in_pcbdetach (inp=0xc0743a40) at /usr/src/sys/netinet/in_pcb.c:720 #9 0xc05b21a6 in tcp_close (tp=0x0) at /usr/src/sys/netinet/tcp_subr.c:783 There's something wrong here: If tcp_close() is passed NULL it will panic at this point when it tries to dereference tp. Starting to stretch my knowledge a bit now ;) If I can provide you with further debug output would you be able to give me some pointers? Thanks for your help -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD-* files in non-HEAD branches
Howdy, I'm wondering what the utility of files like FREEBSD-Upgrade and FREEBSD-Xlist which describe how to import stuff in src/contrib in branches other than HEAD. It makes sense to me to remove these files in other brakes, opinions? Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD-* files in non-HEAD branches
Ruslan Ermilov wrote: Hi, On Fri, Aug 05, 2005 at 10:53:12PM -0700, Doug Barton wrote: I'm wondering what the utility of files like FREEBSD-Upgrade and FREEBSD-Xlist which describe how to import stuff in src/contrib in branches other than HEAD. It makes sense to me to remove these files in other brakes, opinions? At least is makes it easy to view diffs between branches. I'd prefer it if you don't remove them from src/contrib/groff/ and src/contrib/texinfo/ at least that I maintain. Sorry I wasn't clear, I am only considering removing them from src/contrib/bind9. I wouldn't remove them in other people's areas. Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Checking sysctl values from within the kernel.
John Baldwin writes: | On Friday 05 August 2005 10:50 am, Dan Nelson wrote: | In the last episode (Aug 05), Thordur I. Bjornsson said: | If I want to check a sysctl value from within the kernel (e.g. an | KLD), should I use the system calls described in sysctl(3) ? | | If not, what is the propper way to do so ? | | Since most sysctls are direct mappings onto integer variables in the | kernel, just check the variable directly. | | There's also a kernel_sysctl() function available in the kernel for in-kernel | access to sysctls. You might have to lookup the OID for a given name | yourself though. Actually, there's a kernel_sysctlbyname() as well. This could be a fragile interface though. I used this scheme to do soft-linking between modules that could be kldloaded into the kernel or static. We called it several times every few seconds. Over time the system would wedge on a setjmp or something like that. We changed it to a function call since in a static kernel then the problem went away. Doug A. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Parking disk drive heads
Julian Elischer writes: | just placing an unmounted drive down on a hard table, even when | not running, can ruin it. We lost hundreds that way at Whistle until | we did a failure analysis. Just placing a rubber mat on the table. | fixed it and instructing the staff to always put the drives on | a soft surface made the problem go right away. Not quite. Burn-in helped more. A few were head slaps but more was just media that needed exercising. It's the lands minds that bite you more when it has swap or other critical data on it. A little historical correction. Flash is nice but it has some issues. Atleast dropping it isn't one! Doug A. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] caching daemon release and nsswitch patches
Michael Bushkov wrote: Hi! I'm working on nsswitch improvement (during the Google Summer of Code program. First off, let me say that this is very exciting stuff! I'm particularly excited about caching for the services stuff, as it will finally allow us to bring in a more complete version of the services file. I do have some comments for you, and I hope that you understand that they are in no way critical of your work, just suggestions for improvements, and ways that you can better fit into the FreeBSD code base. I'm not sure what guidelines were given to you when you started the project, but in reviewing your work the first thing I noticed was that you are not following the guidelines in the style(9) man page. You should read that page, and spend an afternoon reformatting your code to fit what is described there. The most common error you've made is not following the 80 column rule, which hopefully should be easily fixed. While one could argue with the specific items in that page, and quite possibly be right, the idea of having a style guideline is more to have a common format that we can all work towards than to have a perfect format that we can all agree on. By reformatting your code to fit this guideline you will greatly increase the chances that it will be welcomed into the tree with open arms. The other style area that you should look at is your man pages. If you look in /usr/share/examples/mdoc you will find the FreeBSD style guidelines for man pages. The line wrapping issue comes into play here as well. We generally don't go past column 60 in man pages, since that reduces CVS repo churn for corrections down the road. Also, any time you have a full stop (period) at the end of a sentence, you should start a new line. I think that you are also using some macros that I'm not familiar with, although I'm not an mdoc expert. The other area that I'm interested in is how you plan to have cached interact with DNS lookups, /etc/hosts, named, etc. If there was a project plan posted somewhere on this already and I missed it, please accept my apologies, and send along a reference. If not, I'm very interested to hear what your plans are. Regards, Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ip6.int deprecated
[ -hackers and -arch cc'ed to try and get a wide audience for this. Please pick the one list that is most appropriate for any topics you want to follow up on. Thanks. ] Howdy, RFC 4159 was published today, which officially deprecates ip6.int. You can find the full text at http://www.rfc-editor.org/rfc/rfc4159.txt. Here is a relevant excerpt: In August 2001 the IETF published [RFC3152], which advised that the use of ip6.int as the domain for reverse-mapping of IPv6 addresses to DNS names was deprecated. The document noted that the use of ip6.int would be phased out in an orderly fashion. As of 1 September 2005, the IETF advises the community that the DNS domain ip6.int should no longer be used to perform reverse mapping of IPv6 addresses to domain names, and that the domain ip6.arpa should be used henceforth, in accordance with the IANA Considerations described in [RFC3596]. The domain ip6.int is deprecated, and its use in IPv6 implementations that conform to the IPv6 Internet Standards is discontinued. The one step I'm going to take directly to support this deprecation is to remove the ip6.int example from the sample named.conf file in the base. I'm sending this message to provide notice of that, and notice to the community generally that we should start moving in the direction of deprecating ip6.int wherever it might be found. For those not aware of the history, ip6.int was the first stab at creating a reverse DNS zone for IP version 6. Eventually, the issues surrounding this topic were sorted out, and it was agreed to do reverse DNS in IPv6 in .arpa instead. Unfortunately, that left a lot of early adopters in a difficult position, and so the various players in the game (ICANN, the Regional Internet Registries, etc.) have been supporting both zones since 2001. In order to reduce the workload associated with this issue, and in order to encourage complete migration to ip6.arpa before wide deployment of IPv6 (and I'm sure for a lot of other reasons), the decision was made to officially deprecate ip6.int from the IETF perspective. Other than some old references in src/contrib/bind9, the only place I see a reference to ip6.int in our base is in the named.conf file that I mentioned above. I hope that this note is useful however as a more general source of information, and of course if there is anything I've missed, I welcome others to take appropriate action. Regards, Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Fixing an error condition for 'rm -P'
I have rm aliased to '/bin/rm -P', mostly for fun, but I like the idea. There is an oddity however when you use the -P flag, and the file is not writable. The check() function in rm.c specifically ignores this condition, and lets the thing fail later in the program. I think this is bad on an objective level, but it definitely leads to annoying problems for the user when you hit this condition. I therefore propose the attached patch. Doug -- This .signature sanitized for your protection Index: rm.c === RCS file: /usr/local/ncvs/src/bin/rm/rm.c,v retrieving revision 1.52 diff -u -r1.52 rm.c --- rm.c13 Nov 2004 04:07:01 - 1.52 +++ rm.c23 Sep 2005 08:29:38 - @@ -452,11 +452,8 @@ * talking to a terminal, ask. Symbolic links are excluded * because their permissions are meaningless. Check stdin_ok * first because we may not have stat'ed the file. -* Also skip this check if the -P option was specified because -* we will not be able to overwrite file contents and will -* barf later. */ - if (!stdin_ok || S_ISLNK(sp-st_mode) || Pflag || + if (!stdin_ok || S_ISLNK(sp-st_mode) || (!access(name, W_OK) !(sp-st_flags (SF_APPEND|SF_IMMUTABLE)) (!(sp-st_flags (UF_APPEND|UF_IMMUTABLE)) || !uid))) @@ -464,6 +461,9 @@ strmode(sp-st_mode, modep); if ((flagsp = fflagstostr(sp-st_flags)) == NULL) err(1, fflagstostr); + if (Pflag) + errx(1, + -P was specified, but %s is not writable, path); (void)fprintf(stderr, override %s%s%s/%s %s%sfor %s? , modep + 1, modep[9] == ' ' ? : , user_from_uid(sp-st_uid, 0), signature.asc Description: OpenPGP digital signature
Fixing an error condition for 'rm -P'
I have rm aliased to '/bin/rm -P', mostly for fun, but I like the idea. There is an oddity however when you use the -P flag, and the file is not writable. The check() function in rm.c specifically ignores this condition, and lets the thing fail later in the program. I think this is bad on an objective level, but it definitely leads to annoying problems for the user when you hit this condition. I therefore propose the attached patch. Doug -- This .signature sanitized for your protection Index: rm.c === RCS file: /usr/local/ncvs/src/bin/rm/rm.c,v retrieving revision 1.52 diff -u -r1.52 rm.c --- rm.c13 Nov 2004 04:07:01 - 1.52 +++ rm.c23 Sep 2005 08:29:38 - @@ -452,11 +452,8 @@ * talking to a terminal, ask. Symbolic links are excluded * because their permissions are meaningless. Check stdin_ok * first because we may not have stat'ed the file. -* Also skip this check if the -P option was specified because -* we will not be able to overwrite file contents and will -* barf later. */ - if (!stdin_ok || S_ISLNK(sp-st_mode) || Pflag || + if (!stdin_ok || S_ISLNK(sp-st_mode) || (!access(name, W_OK) !(sp-st_flags (SF_APPEND|SF_IMMUTABLE)) (!(sp-st_flags (UF_APPEND|UF_IMMUTABLE)) || !uid))) @@ -464,6 +461,9 @@ strmode(sp-st_mode, modep); if ((flagsp = fflagstostr(sp-st_flags)) == NULL) err(1, fflagstostr); + if (Pflag) + errx(1, + -P was specified, but %s is not writable, path); (void)fprintf(stderr, override %s%s%s/%s %s%sfor %s? , modep + 1, modep[9] == ' ' ? : , user_from_uid(sp-st_uid, 0), ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: anyone using security/dropbear?
Brian Reichert wrote: On Thu, Sep 29, 2005 at 02:14:13PM -0400, Kris Kennaway wrote: Check the source.. is it using /dev/urandom (which never blocks), or /dev/random (which I still don't think blocks, but may return short reads). Either way, it sounds like some level of application bug...it probably should be using the former source, but even if it's not, it shouldn't be blocking. ktrace shows /dev/random, and indeed, very short reads. Let me try another maunal build, pushing it to /dev/urandom. Depending on why that program needs random bits, that could be a very bad idea. Take a look at the following page and see if it helps: http://people.freebsd.org/~dougb/randomness.html -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: journaling fs and large mailbox format
Mike Meyer wrote: The solution isn't to avoid Maildir/mh - the solution is to tune the file system for the expected usage. FreeBSD (and Unix in general) gives you lots of knobs to deal with things like this. Learn to use them. The default block and frag size are relatively large - 2K and 16K appear to be the defaults on 5.x. A quick look at my mail for 2005 shows 32,267 messages ranging from 280 bytes to 6+ meg, with a mean size of less than 8K. I'd go with 4k blocks and a 512 byte frag size - because that will give you four times as many inodes as the default parameters. 8K/1K is also tempting, but you'll probably want to specify -i 2048 to get the same number of inodes as you get with a 4K/512b file system. I agree generally with your thinking here, and wanted to add a little more analysis based on my experience. When I was facing a similar problem with a large authoritative name server installation, I got the advice to find the median file size, and tune the file system so that the block size was 2x the median file size (with the fragment size being 1/8th the block size of course). The reasoning behind this was that because the files I was working with could grow, it made sense to make sure that even if it grew the file could stay within one block. This is slightly wasteful of space (very slightly), but resulted in a much more efficient operation. In this situation, since any given file in a maildir directory is very unlikely to grow, it seems to me to make sense that the right way to tune the fs would be to find the median file size and make the block size large enough to handle files of that size. That should give you the right tradeoff between speed and efficiency. hth, Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: journaling fs and large mailbox format
Mike Meyer wrote: This seems very reasonable. The trick is figuring out what the median file size is. I grabbed my mail archive, but that's unlikely to be representative of most users. You either need to guess right, or make arrangements to reformat the file system using current dasa at regular intervals. Sorry if I wasn't explicit enough. I was suggesting that the user who submitted the original message actually measure this, and then yes, a newfs'ing of the file system will be necessary. Or you could of course create a new data disk, formatted to fit your specs, then copy the data over, etc. Taking Doug's suggestion into account, and using the data I had, the correct answer would be an 8K/1K file system, possibly with -i 2048 to double the number of inodes. I'm not convinced that increasing the number of inodes in this way would be the right way to go. The default is 4*frag-size, which is usually pretty reasonable. I imagine (although it's impossible to state conclusively without seeing the files), that the inode problem is a symptom, and that tuning the block size will fix the real problem. However, I did see an interesting possibility. What do you do if the median file size is, for example, 4.1K? You make the block size 8k. A 4K block won't hold your median file. But an 8K block wastes a lot of space. You might get a file with 0 blocks and 3 frags, assuming that UFS2 will do that, which doesn't seem good. If UFS2 won't do that, you get a lot of half-empty blocks, which likewise isn't good. The other option is a 4K block size, which means you get a lot of 1 block + 1 frag files. That seems optimal in this case. That's a logical analysis, but you're missing one important premise. UFS doesn't do more than one file per frag until the file system gets close to filling up, and the optimization switches from time to space. Therefore, in your example you're actually wasting more space than you would with 8k blocks, and as a side effect making the fs less efficient in at least 2 ways. hth, Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: journaling fs and large mailbox format
Alin-Adrian Anton wrote: XFS fits incredibly well with Maildir, however this I did not test practically I am curious as to what the defaults are for frag, inode, and block sizes on XFS, and whether that is one of the factors that make it work well with maildir. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A smarter mergemaster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yar, First let me say that you've obviously put a lot of work into this, and you have some very interesting ideas here that are worthy of further discussion. Please don't let any of my comments here be understood as criticism, or an attempt to discourage you. Second, I'd like to point out that it's generally a bad idea to cross post to more than one list. I've set a reply-to for hackers@, if you'd rather have the discussion on current@ that's fine too, but please pick one. Finally, please be aware that in src/MAINTAINERS I have requested pre-commit approval on changes to mergemaster. I hope that you'll respect that. I have some more specific comments below. Yar Tikhiy wrote: | Folks, | | I've got tired of dumb default choices mergemaster(8) offers and modified | it to be a bit smarter. While I can appreciate your frustration, the way you've phrased this departs from the project's tradition of respect for fellow developers and their work. A better way for you to deal with your frustration here would have been to send me, or alternatively, one of the mailing lists, a post which stated your frustrations and asked for an explanation of the reasons for the defaults. I am sure that you meant no actual insult here, so I'll not say anything more about this topic. | Upgrading /etc often, as when following CURRENT, is much less pain to me | now. One of the design decisions that you need to be aware of for this project since day one was to try and balance intelligent behavior and configuration options that would be useful for the very small percentage of the FreeBSD user community that constitutes our developers, versus the needs of the vast majority of regular users who need to be able to use the tool without becoming experts in either our build system, or the tool itself. That is why every single default for mergemaster is to do nothing. It was a purposeful decision to require the user to examine change requests, and make an affirmative choice to approve them. I find your idea of an expert mode for mm to be an interesting one, and I think that enough time has gone by so that it will be safe to add this. However I'd like to add a big, hairy warning message that says that users who enable this option do so at their own risk, etc. I need to think more about this. | The fruitiest features are as follows: | | - mergemaster no longer teases you with pauses in -v mode. Use -N (novice | mode) if you still want the pauses. I'm inclined to alter this to hide the pauses behind an expert mode flag, but I need to study your patch more before I give a more firm opinion on this. Do you have another strong reason for adding this mode? | - Stale rc.d files can be rm'ed or kept on individual basis. I think this is a good compromise for those who insist on polluting /etc/rc.d with non-system stuff. :) If you're so inclined, could you add a knob to specify a list of files to exclude from consideration? If not, I'll take a look at it. It should also be noted that I have a plan (and a POC) that will allow us to migrate to full rcorder treatment for both /etc/rc.d/ and /usr/local/etc/rc.d/ scripts, but I'm waiting for 6.0-RELEASE to get out the door before starting that bikeshed. | - There is expert mode, -E. In this mode, | mergemaster offers more dangerous defaults, mostly [install] or [delete] | depending on the question. So you can just keep hitting Enter most of | the time if your /etc is just slightly modified. In addition, you get | the 's' choice when in a subdirectory: auto-install all files from this | subdirectory -- much useful to deal with sweeping changes to rc.d or | periodic. Hrrrm ... this is partially in violation of one of my other design goals, which is to have admins actually SEE the changes to the things that they're installing, but this is also one of the least popular aspects of the thing, so I'm inclined to lean into the wind on this one. I would like to consider /etc/defaults/ exempt from this treatment however. I still feel strongly that admins should see what is being changed there since those changes are much more likely to introduce a problem than any other directory. | Feedback is welcome. And please please don't skip making a backup of | your /etc before running mergemaster! I can't be responsible for its | loss due to bugs in my code or whatever. While on the one hand I certainly appreciate and agree with this sentiment, not introducing changes that violate POLA, or are very dangerous to unsophisticated users, is one of the reason I request pre-commit approval. Thanks again for your work on this, Doug - -- ~This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDPN41yIakK9Wy8PsRAoA4AKC2X04Xnok/nj+nIdEpN7r8Z2/b/wCgtoQE Wov5z1ozZ9tLGFY+VwTTMdQ= =JMsn -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list
Re: A smarter mergemaster
Kevin Oberman wrote: Date: Thu, 29 Sep 2005 23:41:57 -0700 From: Doug Barton [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] One of the design decisions that you need to be aware of for this project since day one was to try and balance intelligent behavior and configuration options that would be useful for the very small percentage of the FreeBSD user community that constitutes our developers, versus the needs of the vast majority of regular users who need to be able to use the tool without becoming experts in either our build system, or the tool itself. That is why every single default for mergemaster is to do nothing. It was a purposeful decision to require the user to examine change requests, and make an affirmative choice to approve them. Doug, You just hit on one of my pet peeves with mergemaster! Contrary to what you say: every single default for mergemaster is to do nothing, when a file is found in /etc/rc.d that is not in /usr/src/etc/rc.d, the default is to delete the file in etc. I think that this is a bad thing(tm). Agreed, The only thing I can think of as a reason for the anomaly is that at the time I wrote that code, the problems being reported with stale rc files were pretty numerous, and perhaps I was being overzealous. I've already said that I like Yar's idea of offering options to delete files or not, so I'll look at bringing at least that code in ASAP with the change that you requested, and possibly seek an MFC before 6 release. By the way, having run FreeBSD before mergemaster, it's a huge improvement on those ugly days. Thanks for the kind words, they are always appreciated. :) I should also take this opportunity to say that I appreciate all the interesting ideas on this thread, and I am paying attention to what's said even if I don't comment on it. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcp services (ssh,ftp) does not work
For future reference, you should not cross post to FreeBSD lists. If you are unsure what the best list will be, start with freebsd-questions. Good luck, Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: copy directory structure
Ashok Shrestha wrote: Do you know how to copy just a directory structure (not the files inside it)? This is better suited for freebsd-questions@, but I'll give you a hint, the answer should probably involve find. :) Good luck, Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Preserve date when cp over smbfs
Gilbert Cao wrote: Hi, the list. I have recently notice a problem when I copy a file to a SMB mount directory : Thanks for the good detective work. Can you send-pr this so that it does not get lost? Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Preserve date when cp over smbfs
Gilbert Cao wrote: Hi, the list. I have recently notice a problem when I copy a file to a SMB mount directory : Good detective work! Please send-pr this so it does not get lost. Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Small patch to sh.1
Does the attached patch look reasonable?
Doug
--
This .signature sanitized for your protection
Index: sh.1
===
RCS file: /usr/local/ncvs/src/bin/sh/sh.1,v
retrieving revision 1.118
diff -u -r1.118 sh.1
--- sh.11 Jan 2006 16:02:12 - 1.118
+++ sh.17 Jan 2006 01:25:57 -
@@ -1140,6 +1140,10 @@
.Pp
In addition, a parameter expansion can be modified by using one of the
following formats.
+For each of the formats below,
+if the colon is ommitted the expansion will only be modified
+if the parameter is unset.
+It will not be modified if the parameter is null.
.Bl -tag -width indent
.It Li ${parameter:-word}
Use Default Values.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small patch to sh.1
Sam Lawrance wrote: It's already mentioned at the end of the list of formats. Hrrm, so it is. Arguably it should be mentioned at the start, since it's easy to miss where it is (I certainly missed it, as did others). Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tuning to run large (1000+) numbers of null_mounts
Ensel Sharon wrote: hmmm...the cut and paste of that loud warning was from a 6.0-RELEASE man page ... if I need to be CURRENT to get the updated man page, do I also need to be CURRENT to get the safe null_mount code itself ? Or is 6.0-RELEASE safe ? (re: null_mount) It probably wouldn't hurt to try upgrading to 6-stable. -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
