Re: REQUEST FOR TESTERS: `devel/mingw32-gcc'

[Coleman Kane]

On Sat, 2009-03-28 at 20:37 -0500, Stephen Montgomery-Smith wrote:
> Coleman Kane wrote:
> 
> > I haven't seen any activity on the above email, and I am curious if:
> >  1) It was missed (and this really does affect people)
> >  2) Nobody cross-compiles using the mingw32-* ports (it is really very 
> > handy!)
> >  3) Nobody really cares that mingw32-gcc will move from 3.4.5 --> 4.2.0
> > 
> > Please, if this affects you test out the above port tarball! Otherwise, 
> > this will end up going in and not take into account any problems that 
> > might arise in your environment.
> > 
> > -- 
> > Coleman Kane
> 
> 
> I just saw that this message is about two years old, and that the commit 
> must have been made years ago.
> 
> Sorry for the noise.

Thanks. It was handled off-line and we did the upgrade.

-- 
Coleman Kane


signature.asc
Description: This is a digitally signed message part

Re: Overlap in PCI memory ranges (fixed)

[Coleman Kane]

Andrey V. Elsukov wrote:
> Coleman Kane wrote:
>> Also, the mem resources of the SATA controller are used for AHCI
>> (however, PATA compatibility mode is supported using the port ranges,
>> which is what the controller is forced to do). In addition, the device
>> name string on the SATA controller is only there because I've been
>> fooling with ata-chipset.c (to unsuccessfully attempt to get AHCI
>> working). Reading the MMIO registers in AHCI mode seems to produce
>
> Do you have some patches for ata(4)? I don't see in the clean
> sources where driver can allocate a memory resources for the ATI.
> As i see from your dmesg driver doesn't use AHCI.
The PCI code doesn't care if the ata driver uses the mem ranges or not.
If the PCI device registers that it owns those mem ranges, then the PCI
code will automatically reserve them (and assign them to the driver anyway).

The card is an AHCI-compliant card, however the traditional IDE port
ranges are still functional, allowing the device to pretend to
incompatible OSes that it's just a dumb old PCI IDE Controller.
>
>> situation (a single port SATA controller on a laptop). This is supposed
>> to read a bitmap of the enabled ports on the SATA controller.
>
> Please, show your `pciconf -l`. And if you have some patches, show
> their.
>
I have fixed this problem finally. It is a cheap and dirty hack, but it
works. The link is here:
http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_hp_compaq_6715b_working

Scroll down to the "HDA Audio Controller" and the "Serial ATA
Controller" sections for clarification of what was causing the problem
and what I had to do to solve it. Maybe there is a better way to do this
on FreeBSD but I have not found it.

--
Coleman Kane


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Overlap in PCI memory ranges

[Coleman Kane]

Andrey V. Elsukov wrote:
> Coleman Kane wrote:
>> My apologies. The lines *should* read (mem ranges overlap):
>>
>> atapci0:  port
>> 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f
>> mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0
>> .
>> pcm0:  mem
>> 0xd0608000-0xd060bfff irq 16 at device 20.2 on pci0
>
> Why you want to do it? Your SATA controoler doesn't works?
> Can you show a bit more log messages related to the atapci0?
> Also can you show `pciconf -l | grep ^atapci`?
>
pcm0: hdac_mem_alloc: Unable to allocate memory resource  (and then
attach fails)

Also, the mem resources of the SATA controller are used for AHCI
(however, PATA compatibility mode is supported using the port ranges,
which is what the controller is forced to do). In addition, the device
name string on the SATA controller is only there because I've been
fooling with ata-chipset.c (to unsuccessfully attempt to get AHCI
working). Reading the MMIO registers in AHCI mode seems to produce
spurious instances of reading garbage data, followed by reading the data
that I want.

For instance, in ata-chipset.c line 771 ata_ahci_reset():
if (!(ATA_INL(ctlr->r_res2, ATA_AHCI_PI) & (1 << ch->unit))) {
device_printf(dev, "port not implemented\n");
return;
}

Produces "port not implemented" whenever it is executed (it ends up
reading 0x00020070 or a similar unexpected value. However, if I put
another ATA_INL(ctlr->r_res2, ATA_AHCI_PI) just above the if()
statement, it will read 0x0001, which is the expected value for my
situation (a single port SATA controller on a laptop). This is supposed
to read a bitmap of the enabled ports on the SATA controller.

Attaching dmesg:

You'll notice the "fpudna in kernel mode!" and "ndis0: bssid_list
failed" messages. These are related to an NDIS 5.1 wifi driver and don't
apply to my problem.

--
Coleman Kane

Copyright (c) 1992-2007 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-CURRENT #0: Wed Nov 28 17:16:00 EST 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ERWIN
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-64 (2194.59-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x60f81  Stepping = 1
  
Features=0x178bfbff
  Features2=0x2001
  AMD Features=0xea500800
  AMD Features2=0x11f
  Cores per package: 2
usable memory = 2001375232 (1908 MB)
avail memory  = 1931157504 (1841 MB)
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ACPI Error (tbfadt-0516): 32/64X address mismatch in "Pm2ControlBlock": [
8800] [   08100], using 64X [20070320]
ioapic0: Changing APIC ID to 2
ioapic0  irqs 0-23 on motherboard
kbd1 at kbdmux0
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
unknown: I/O range not supported
acpi0: reservation of 0, 800 (3) failed
acpi0: reservation of 10, fff0 (3) failed
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0
acpi_ec0:  port 0x62,0x66 on acpi0
cpu0:  on acpi0
acpi_throttle0:  on cpu0
powernow0:  on cpu0
cpu1:  on acpi0
acpi_throttle1:  on cpu1
acpi_throttle1: failed to attach P_CNT
device_attach: acpi_throttle1 attach returned 6
powernow1:  on cpu1
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
vgapci0:  port 0x4000-0x40ff mem 
0xc000-0xc7ff,0xd040-0xd040,0xd050-0xd05f irq 19 at 
device 5.0 on pci1
pcib2:  at device 4.0 on pci0
pci16:  on pcib2
pci0:16:0:0: failed to read VPD data.
bge0:  mem 0xd000-0xd000 
irq 16 at device 0.0 on pci16
miibus0:  on bge0
brgphy0:  PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
bge0: Ethernet address: 00:1a:4b:74:39:96
bge0: [ITHREAD]
pcib3:  at device 5.0 on pci0
pci32:  on pcib3
pcib4:  at device 6.0 on pci0
pci48:  on pcib4
ndis0:  mem 
0xc810-0xc8103fff,0xc800-0xc80f irq 18 at device 0.0 on pci48
ndis0: [ITHREAD]
ndis0: NDIS API version: 5.1
fpudna in kernel mode!
ndis0: using obsoleted if_watchdog interface
ndis0: Ethernet address: 00:1a:73:86:02:df
atapci0:  port 
0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 
0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0
atapci0: [ITHREAD]
ata2:  on atapci0
ata2: [ITHREAD]
ata3:  on atapci0
ata3: [ITHREAD]
ohci0:  mem 0xd0601000-0xd0601fff irq 23 at 
device 19.0 on pci0
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 

Re: Overlap in PCI memory ranges

[Coleman Kane]

Gary Corcoran wrote:
> Coleman Kane wrote:
>> Hello all,
>>
>> I've got a problem with overlapping PCI memory ranges between my SATA
>> controller and my High-Def Audio controller:
>>
>> atapci1:  port
>> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1
>> on pci0
>> pcm0:  mem
>> 0xd0608000-0xd060bfff irq 16 at device 20.2 on pci0
>
> Sorry, I couldn't help you even if I saw the problem, but I can't see any
> overlap in the above.  I see a bunch of relatively low addresses, and one
> high memory address range.  Where's the conflict ??
>
> Gary
>
>> I am curious if anybody knows of any way to overwrite the boot-up memory
>> range in the PCI configuration. I have tried:
>> pciconf -w pci0:0:20:2 16 0xd0614004
>>
>> after inpecting that the above PCI reg's value before this is
>> 0xd0608004. It seems that if I try writing the config register to
>> anything between d0608000 and d0614000, the register gets reverted back
>> to 0xd0608004. If I go higher than 0xd0614004, then it gets reverted to
>> that number.
>>
>> I am not very familiar with PCI configuration (or other facilities
>> FreeBSD uses to assign resources to PCI devices), so I'd like to know if
>> anybody can help me sort this problem out which is preventing AHCI and
>> HDA-Audio from working...
>>
>> -- 
>> Coleman Kane
>
My apologies. The lines *should* read (mem ranges overlap):

atapci0:  port
0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f
mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0
.
pcm0:  mem
0xd0608000-0xd060bfff irq 16 at device 20.2 on pci0


--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Overlap in PCI memory ranges

[Coleman Kane]

Aryeh M. Friedman wrote:
> Coleman Kane wrote:
>   
>> Hello all,
>>
>> I've got a problem with overlapping PCI memory ranges between my SATA
>> controller and my High-Def Audio controller:
>>   
>> 
>
> Are you using AMD64 or i386?
>
>   
AMD64, FreeBSD 8.0-CURRENT

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Overlap in PCI memory ranges

[Coleman Kane]

Hello all,

I've got a problem with overlapping PCI memory ranges between my SATA
controller and my High-Def Audio controller:

atapci1:  port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1
on pci0
pcm0:  mem
0xd0608000-0xd060bfff irq 16 at device 20.2 on pci0

I am curious if anybody knows of any way to overwrite the boot-up memory
range in the PCI configuration. I have tried:
pciconf -w pci0:0:20:2 16 0xd0614004

after inpecting that the above PCI reg's value before this is
0xd0608004. It seems that if I try writing the config register to
anything between d0608000 and d0614000, the register gets reverted back
to 0xd0608004. If I go higher than 0xd0614004, then it gets reverted to
that number.

I am not very familiar with PCI configuration (or other facilities
FreeBSD uses to assign resources to PCI devices), so I'd like to know if
anybody can help me sort this problem out which is preventing AHCI and
HDA-Audio from working...

--
Coleman Kane

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: REQUEST FOR TESTERS: `devel/mingw32-gcc'

[Coleman Kane]

Coleman Kane wrote:

Lev Serebryakov wrote:

Hello ports,

  Latest versions of `mingw32-binutils' and `mingw32-bin-msvcrt' were 
committed.

  `mingw32-gcc' is on pipeline.
  But it is BIG update: new version is 4.2.0
  I ask you to test this `almost new' port before commit.

  http://lev.serebryakov.spb.ru/download/port-mingw32-gcc-4.2.0.tar.gz

  Many thanks to Coleman Kane <[EMAIL PROTECTED]>, who helps me to 
prepare this update.

I'd like to know what everyone else's experience with these new 
mingw32- ports are. So far I have been building Win32 applications 
from my FreeBSD box with these versions quite successfully. I think 
that the binutils and GCC are actually newer than the ones currently 
shipping with the MinGW32 binary distribution too.


--
Coleman Kane


I haven't seen any activity on the above email, and I am curious if:
 1) It was missed (and this really does affect people)
 2) Nobody cross-compiles using the mingw32-* ports (it is really very 
handy!)

 3) Nobody really cares that mingw32-gcc will move from 3.4.5 --> 4.2.0

Please, if this affects you test out the above port tarball! Otherwise, 
this will end up going in and not take into account any problems that 
might arise in your environment.


--
Coleman Kane

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Mac OS underlying FreeBSD - does it run Linux emulation?

[Coleman Kane]

On 4/4/07, Robert Watson <[EMAIL PROTECTED]> wrote:



On Wed, 4 Apr 2007, Mike Meyer wrote:

> In <[EMAIL PROTECTED]>, Christoph P. Kukulies <
[EMAIL PROTECTED]> typed:
>> does  anyone know whether one can run Linux applications under the
underlying
>> FreeBSD of the MAC OS (on an Intel Core Duo mini Mac)?
>
> No, you can't. The "underlying" FreeBSD is userland code; not kernel
code.
> The OSX kernel is based on Mach.

While it's true you can't run Linux binaries on Mac OS X, it's not for the
reason you're suggesting, and your statement regarding FreeBSD kernel code
in
Mac OS X is simply incorrect.  The Mac OS X kernel, XNU, contains
significant
quantities of FreeBSD kernel source code, including a FreeBSD-derived VFS
and
network stack.  Other parts of the kernel, such as the scheduler and VM
system, are derived from Mach.  While the FreeBSD-derived code has been
significantly modified since it was originally forked, a lot of code moves
backward and forward between the platforms: the FreeBSD audit subsystem is
derived from the Mac OS X audit subsystem, and Mac OS X's smbfs and MAC
Framework support are derived from FreeBSD.

Robert N M Watson
Computer Laboratory
University of Cambridge



In addition to this, there have been examples of  the Linux kernel hosted by
Mach in the past (such as MkLinux). From my understanding, the only thing
that prevents this from being realized is that nobody has sat down to
actually write/port the code to do it.

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Any recent news on Xen support for FreeBSD?

[Coleman Kane]

I have actually switched to using the ModularXorg ports tree which
is a slightly delayed tree that merges the modular X.org 7.2 parts
into it. I have been using that on a regular basis for my workstation
and it has been great.

If you're interested in X.org 7.2, check out:
http://wiki.freebsd.org/ModularXorg

--
Coleman

On Tue, Apr 03, 2007 at 11:54:56AM -0500, Sam Fourman Jr. wrote, and it was 
proclaimed:
> For what it is worth I check the lists on a weekly basis for Xen
> Support in FreeBSD as well as xorg 7.2 actually hitting the ports
> tree.
> 
> both Xen and Xorg 7.2 are very highly anticipated in my opinion
> 
> Sam Fourman Jr.
> 
> On 4/3/07, Coleman Kane <[EMAIL PROTECTED]> wrote:
> >On 4/2/07, Kip Macy <[EMAIL PROTECTED]> wrote:
> >>
> >> Rink has made some progress. I'm cc'ing him.
> >>
> >>   -Kip
> >>
> >> On 4/2/07, Jaye Mathisen <[EMAIL PROTECTED]> wrote:
> >> >
> >> >
> >> > The fsmware page is significantly dated, and I just am
> >> > not sure what's going on.
> >> >
> >> > I was just curious if there was a better or updated status
> >> > available.
> >> >
> >> > Thanks for your time.
> >> > ___
> >> > freebsd-hackers@freebsd.org mailing list
> >> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >> > To unsubscribe, send any mail to "
> >> [EMAIL PROTECTED]"
> >> >
> >
> >
> >Try to keep this on -hackers... I am interested in the follow-ups to this
> >thread as well, and I am sure that it would be helpful to others.
> >___
> >freebsd-hackers@freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> >
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Any recent news on Xen support for FreeBSD?

[Coleman Kane]

On 4/2/07, Kip Macy <[EMAIL PROTECTED]> wrote:


Rink has made some progress. I'm cc'ing him.

  -Kip

On 4/2/07, Jaye Mathisen <[EMAIL PROTECTED]> wrote:
>
>
> The fsmware page is significantly dated, and I just am
> not sure what's going on.
>
> I was just curious if there was a better or updated status
> available.
>
> Thanks for your time.
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "
[EMAIL PROTECTED]"
>



Try to keep this on -hackers... I am interested in the follow-ups to this
thread as well, and I am sure that it would be helpful to others.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Floating-point in kernel space

[Coleman Kane]

On 3/9/07, Oliver Fromme <[EMAIL PROTECTED]> wrote:


Maslan <[EMAIL PROTECTED]> wrote:
> I think i've seen somewhere but i don't remember that floating point
> arithmetic is not allowed in kernel space, if that's right, can anyone
> please tell why ???

Because the overhead of swapping the contents of the FPU
registers on every context switch within the kernel.
So far there has been no compelling reason for having FP
support in kernel code that would justify to pay that
price.

> and why not not emulate the floating point in kernel space ???

First, FPU emulation is rather slow, and second, someone
would have to write the code.  In the past, the FreeBSD
kernel had two FPU emulation libraries (for emulation
of FPU instructions in userland).  One was BSD-licensed,
but incomplete and not 100% compatible, and the second
was GPL, so it couldn't be enabled by default.  As far as
I know, both of them were removed because hardware without
an FPU was considered obsolete, and nobody was willing to
improve and maintain the code.

Let me ask you, why would you want to have floating point
support in the kernel?  Most of such typical uses can
easily be replaced by simple fixed-point arithmetic with
integer instructions.  There are several examples of such
code, e.g. in ALTQ, DUMMYNET and in the NTP support code.

Best regards
   Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"I have stopped reading Stephen King novels.
Now I just read C code instead."
-- Richard A. O'Keefe



It would be helpful to know why you need this support as well. For many
projects that I've done, the kernel code is used for transferring the
"binary" data from the computer system (hardware or kernel) to a userland
daemon that would do the FP processing (which is likely significantly time
consuming) and then this daemon would provide a listening socket that other
software could use to retrieve said data.

I would imagine that if you are needing FP processing in the kernel, then
you'll be doing a serious amount of work and may not want to be hogging up a
lot of kernel time doing it. However, there are Real-Time applications for
such an implementation. Perhaps posting about the problem would be more
helpful.

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: portupgrade O(n^m)?

[Coleman Kane]

hink of better solutions (more people
> can help in thinking out of the box, the larger the group).
>
> Thanks,
> -Garrett
>
> PS Please reply on the @hackers list, if possible.
>
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "
[EMAIL PROTECTED]"
Honestly I'd be more interested in a package building system. Maybe be a
little bit more liberal in the default building of ports. It doesn't
need to build a package of every port just common ones. That way its
easier to get up and running with things. Things like xorg, gnome and
KDE take ages to build and would be awesome if there was a decent
package fetching system. Something like apt-get where you could add some
kind of repository. and you could just pull down a list of packages and
choose what you want. This can be emulated in a way using portupgrade -P
and changing the pkgtools.conf to have some more mirrors to fetch from a
pointyhat macro is there but probably shouldn't be abused as its there
to look for problems not build us consumers packages it just a side
effect or at least this is how it was explained to me. A neat thing
might be a distributed package building project. Where packages are
picked apart and pieces are built all over the place get enough places
to donate CPU and package building might be a thing of the past, but
those are just pipe dreams right now.

The slowness affects me after a mass upgrade, after that I'm fine. Maybe
someone can look into profiling portupgrade and seeing if its with
portupgrade or the pkg_* tools.



One of FreeBSD's strengths, from my POV, is the power it affords you from
the ports system. One of my biggest beefs w/ Linux has always been the
prebuilt-binary-centric package systems. In addition to performance, this
was one other thing that drove me to The Beastie. With the newer, faster
processors, my personal bottleneck (and I think this is true for many others
in this thread) has moved from the compilation stage of ports into the
meta-data management. It can be disheartening for a geek to see that the
process of "registering package", or updating the "information repository to
get/build packages" seems to take significantly longer than the process of
actually building and installing the software.

I have worked on other projects where "splitting up" the work has been
meritorious. I am looking at the pkgdb/portsdb BDB files on my system right
now, and I see the following:
 usr/ports/INDEX-7.db: 36658176 bytes (~35MB)
 var/db/pkg/pkgdb.db: 34974720 (~33.3MB)

What if we were to divide up the pkgdb.db and the INDEX-7.db files into
multiple .db files (perhaps one file for each category directory in ports),
and then force the package names to be
"{category}/{packagename}-{versioninfo}" everywhere they are referenced? I
do not know if currently packages record the category name for their
dependencies, but it seems that if they did we could reduce the search space
down to only the ports in the same category as the port in question.

While we're at it, adding some more meta-information to package .tbz files
would be nice. I don't know if any of this is packaged up, but it would be
useful for FreeBSD binary package distributors to have some of the make
environment variables ($CFLAGS, $CC, $CXX, $CPP, etc...) embedded in the
package metadata as well as any defined WITH_* option variables or other
port-knobs. If it can/has be(en) done, then a package system could take
these things into account and perhaps offer the user a screen similar to
"make config" for which toggles to get with the desired port-package.

Let me know how all of this sounds, if I am on the right track or just
blowing smoke. Of course, I have no time, just like everybody else...

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Progress on scaling of FreeBSD on 8 CPU systems

[Coleman Kane]

On 2/28/07, Sten Daniel Soersdal <[EMAIL PROTECTED]> wrote:


Jim C. Nasby wrote:
> On Tue, Feb 27, 2007 at 03:59:52PM -0500, Kris Kennaway wrote:
>> On Tue, Feb 27, 2007 at 12:25:11PM -0600, Jim C. Nasby wrote:
>>> On Sat, Feb 24, 2007 at 04:31:11PM -0500, Kris Kennaway wrote:
 Now that the goals of the SMPng project are complete, for the past
 year or more several of us have been working hard on profiling
FreeBSD
 in various multiprocessor workloads, and looking for performance
 bottlenecks to be optimized.

 We have recently made significant progress on optimizing for MySQL
 running on an 8-core amd64 system. The graph of results may be found
 here:
>>> I do *not* want to start a database war here, but I'm wondering if any
>>> testing has been done with PostgreSQL? The reason I'm asking is that
>>> there are some benchmarks that show MySQL falling off drastically with
>>> increased concurrency:
>>>
>>>
http://www.mysqlperformanceblog.com/2006/11/30/interesting-mysql-and-postgresql-benchmarks/
>>>
>>> It would be interesting to see how the changes you've made stack up
>>> using PostgreSQL as the benchmark.
>> I've mentioned this a couple of times, but postgresql didn't scale
>> well [on freebsd at least] when I tried it last year.  I hope to
>> revisit when I get time.
>
> Let me know if you need help when you get to that point. Keep in mind
> that PostgreSQL's out-of-the-box configuration is pretty conservative,
> so you won't get good numbers that way.

Just a me 2 for postgresql tests:

I would be interrested in postgresql numbers too as i have servers with
2 x dual core (xeon, dell 2850ies) currently running 6.1. I'm basically
looking for something like a benchmark which would justify upgrading (or
even experiment with 7.x) to my boss. I am aware that it's not your job
to spend your valuable time doing obscure tests for us, so consider this
rant as another "vote" for postgresql performance benchmarks.

--
Sten Daniel Soersdal



I wouldn't recommend upgrading your production servers to FreeBSD 7.x yet,
no matter what the results say.

--
Coleman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Wireless card not being detected

[Coleman Kane]

On 2/24/07, DAK GHATIKACHALAM <[EMAIL PROTECTED]> wrote:


I wonder  why these fraudulent scam artists/spammers abusing  our freebsd
lists.

They are in wrong place with wrong people.

I am not buying  your  idea anyway. dude, you chose a wrong person.

Thanks
Dak

-- Forwarded message --
From: wale qazim <[EMAIL PROTECTED]>
Date: Feb 24, 2007 2:48 PM
Subject: Re: Wireless card not being detected
To: DAK GHATIKACHALAM <[EMAIL PROTECTED]>

Hello,



I want to know if you can sent a Message by Bank Coded Fax or MT Series
Swift. I am desperate in need of it as soon as possible, you can as well
link me with someone who can do it..



In case you can, please send me mail through [EMAIL PROTECTED]



Thank you



Regards,



Julio Munento


- Original Message 
From: DAK GHATIKACHALAM <[EMAIL PROTECTED]>
To: freebsd-hackers@freebsd.org
Sent: Monday, 19 February, 2007 3:56:56 AM
Subject: Wireless card not being detected

Hi Freebsd


I have an issue with new card I need to make it work with freebsd,


on /var/log/messages I get


Feb 18 20:51:55 DAK kernel: pccard0:  (manufacturer=0x0192,
produc
t=0x0710, function_type=6) at function 0
Feb 18 20:51:55 DAK kernel: pccard0:CIS info: Sierra Wireless, AC860,
3G
Net
work Adapter, R1


For some reason  I dont understand why I get unknown card error

Does any one has idea


Thanks
Dak
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


--
*Yahoo! Photos*<
http://us.rd.yahoo.com/mail/uk/taglines/gmail_com/photos/*http://uk.photos.yahoo.com/
>–
NEW, now offering a quality print
service<
http://us.rd.yahoo.com/mail/uk/taglines/gmail_com/photos/*http://uk.photos.yahoo.com/
>from
just 8p a photo.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"



I think that I've exhausted my expertise in the area. You may wish to try a
more specific list, like
freebsd-mobile,
freebsd-hardware,
or freebsd-driversfor
more specific help. There are likely a number of people on those lists
who don't subscribe to -hackers, and they may have more experience in the
problem.

--
Coleman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Progress on scaling of FreeBSD on 8 CPU systems

[Coleman Kane]

On 2/24/07, Kris Kennaway <[EMAIL PROTECTED]> wrote:


On Sun, Feb 25, 2007 at 05:47:55AM +, Coleman Kane wrote:
> On Sun, Feb 25, 2007 at 12:41:20AM -0500, Kris Kennaway wrote, and it
was proclaimed:
> > On Sat, Feb 24, 2007 at 10:00:35PM -0700, Coleman Kane wrote:
> >
> > > What does the performance curve look like for the in-CVS 7-CURRENT
tree with
> > > 4BSD or ULE ? How do those stand up against the Linux SMP scheduler
for
> > > scalability. It would be nice to see the comparison displayed to see
what
> > > the performance improvements of the aforementioned patch were
realized to.
> > > This would likely be a nice graphics for the SMPng project page,
BTW...
> >
> > There are graphs of this on Jeff's blog, referenced in that URL.
> > Fixing filedesc locking makes a HUGE difference.
> >
> > Kris
>
> Thanks. I saw that shortly after I sent the email... /me stupid.
>
> How stable is ULE now since the recent swath of rewrites in the past
months?

I think what is in CVS for 7.x is pretty stable.  One of the difficult
things with schedulers is making sure that all workloads perform well,
so testing in different environments is always helpful.

Kris

P.S. ULE in 6.x is still not recommended, but hopefully the fixes can
be merged at some point.



I primarily use  7-CURRENT on my laptop. At some point I had ULE enabled
just to share my experiences with development. What is the status with ULE
on UP systems? Is it expected to be on-par or better than 4BSD, or is it now
only recommended for MP?

--
coleman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Progress on scaling of FreeBSD on 8 CPU systems

[Coleman Kane]

On Sun, Feb 25, 2007 at 12:41:20AM -0500, Kris Kennaway wrote, and it was 
proclaimed:
> On Sat, Feb 24, 2007 at 10:00:35PM -0700, Coleman Kane wrote:
> 
> > What does the performance curve look like for the in-CVS 7-CURRENT tree with
> > 4BSD or ULE ? How do those stand up against the Linux SMP scheduler for
> > scalability. It would be nice to see the comparison displayed to see what
> > the performance improvements of the aforementioned patch were realized to.
> > This would likely be a nice graphics for the SMPng project page, BTW...
> 
> There are graphs of this on Jeff's blog, referenced in that URL.
> Fixing filedesc locking makes a HUGE difference.
> 
> Kris

Thanks. I saw that shortly after I sent the email... /me stupid.

How stable is ULE now since the recent swath of rewrites in the past months?

--
coleman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Progress on scaling of FreeBSD on 8 CPU systems

[Coleman Kane]

On 2/24/07, Kris Kennaway <[EMAIL PROTECTED]> wrote:


Now that the goals of the SMPng project are complete, for the past
year or more several of us have been working hard on profiling FreeBSD
in various multiprocessor workloads, and looking for performance
bottlenecks to be optimized.

We have recently made significant progress on optimizing for MySQL
running on an 8-core amd64 system. The graph of results may be found
here:

  http://www.freebsd.org/~kris/scaling/scaling.png

This shows the graph of MySQL transactions/second performed by a
multi-threaded client workload against a local MySQL database with
varying numbers of client threads, with identically configured FreeBSD
and Linux systems on the same machine.

The test was run on FreeBSD 7.0, with the latest version of the ULE
2.0 scheduler, the libthr threading library, and an uncommitted patch
from Jeff Roberson [1] that addresses poor scalability of file
descriptor locking (using a new sleepable mutex primitive); this patch
is responsible for almost all of the performance and scaling
improvements measured.  It also includes some other patches (collected
in my kris-contention p4 branch) that have been shown to help
contention in MySQL workloads in the past (including a UNIX domain
socket locking pushdown patch from Robert Watson), but these were
shown to only give small individual contributions, with a cumulative
effect on the order of 5-10%.

With this configuration we are able to achieve performance that is
consistent with Linux at peak (the graph shows Linux 2% faster, but
this is commensurate with the margin of error coming from variance
between runs, so more data is needed to distinguish them), with 8
client threads (=1 thread/CPU core), and significantly outperforms
Linux at higher than peak loads, when running on the same hardware.

Specifically, beyond 8 client threads FreeBSD has only minor
performance degradation (an 8% drop from peak throughput at 8 clients
to 20 clients), but Linux collapses immediately above 8 threads, and
above 14 threads asymptotes to essentially single-threaded levels.  At
20 clients FreeBSD outperforms Linux by a factor of 4.

We see this result as part of the payoff we are seeing from the hard
work of many developers over the past 7 years.  In particular it is a
significant validation of the SMP and locking strategies chosen for
the FreeBSD kernel in the post-FreeBSD 4.x world.

More configuration details and discussion about the benchmark may be
found here:

  http://people.freebsd.org/~kris/scaling/mysql.html

Kris



What does the performance curve look like for the in-CVS 7-CURRENT tree with
4BSD or ULE ? How do those stand up against the Linux SMP scheduler for
scalability. It would be nice to see the comparison displayed to see what
the performance improvements of the aforementioned patch were realized to.
This would likely be a nice graphics for the SMPng project page, BTW...

--
Coleman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Wireless card not being detected

[Coleman Kane]

On 2/22/07, DAK GHATIKACHALAM <[EMAIL PROTECTED]> wrote:


On 2/21/07, Coleman Kane <[EMAIL PROTECTED]> wrote:
>
> On 2/18/07, DAK GHATIKACHALAM <[EMAIL PROTECTED]> wrote:
>
> > Hi Freebsd
> >
> >
> > I have an issue with new card I need to make it work with freebsd,
> >
> >
> > on /var/log/messages I get
> >
> >
> > Feb 18 20:51:55 DAK kernel: pccard0: 
> > (manufacturer=0x0192,
> > produc
> > t=0x0710, function_type=6) at function 0
> > Feb 18 20:51:55 DAK kernel: pccard0:CIS info: Sierra Wireless,
> > AC860, 3G
> > Net
> > work Adapter, R1
> >
> >
> > For some reason  I dont understand why I get unknown card error
> >
> > Does any one has idea
> >
> >
> > Thanks
> > Dak
>
>
>
> This is a 3G wireless card (not Wi-Fi)... apparently it is supposed to
be
> supported by the uart or sio drivers. You should try searching google
for:
> freebsd "sierra wireless" AC860
>
> There are apparently some sort of changes to the kernel that need to be
> made.
>

Thanks a lot for your input.

Yes I have made changes to /usr/src/sys/dev/pccard/pccard_quirks.c  file
added a static struct

static struct pccard_function pccard_sierra_860_func0 = {
6,  /* function number */
PCCARD_FUNCTION_SERIAL,
0x0006, /* last cfe number */
0x00,   /* ccr_base */
0x07,   /* ccr_mask */
};

static struct pccard_config_entry pccard_sierra_860_func0_cfe0 = {
0x0006, /* cfe number */
PCCARD_CFE_IO8 | PCCARD_CFE_IRQLEVEL,
PCCARD_IFTYPE_IO,
1,  /* num_iospace */
3,  /* iomask */
{ { 0x3e8 , 0x3ee } },  /* iospace */
0x3fbc, /* irqmask */
0,  /* num_memspace */
{ },/* memspace */
0,  /* maxtwins */
};

and as well /usr/src/sys/dev/pccard/pccarddevs file

vendor SIERRA   0x0192  Sierra Wireless
/* Sierra Wireless */
product SIERRA WIRELESS 0x0710 Sierra Wireless Card

I added these  the pccard device driver detects my card but

on the detection of the card while booting the laptop  on tI get he
console
I get

Feb 22 22:51:12 DAK kernel: pccard0: Allocation failed for cfe 6
Feb 22 22:51:12 DAK kernel: pccard0: No config entry could be allocated.

errors
Do you have idea why  I am getting there errors


Thanks
Dak


--
> Coleman
>
>
>



It's been awhile for me and debugging cardbus/pcmcia devices. Maybe try
changing the CFE number is the second struct to any of 0,1,2,3,4,5 ?

--coleman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Examples on using RTC

[Coleman Kane]

On 2/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


On Fri, 16 Feb 2007, Mike Silbersack wrote:

>
> On Fri, 16 Feb 2007 [EMAIL PROTECTED] wrote:
>
>>> /usr/ports/emulators/rtc
>>>
>>> regards,
>>>
>>> usleep
>>
>> Already using / looked at that. I'm looking for something more
in-depth.
>> -Garrett
>
> The rtc port's sole purpose is to make the vmware port happier.  As you
> probably saw, it just fakes the functions of the linux rtc device.
>
> What other rtc functions do you need?  Almost everything the linux rtc
> device does can be accomplished by raising your system hz and using
> usleep/select.
>
> Mike "Silby" Silbersack

Hmmm.. well, I can't seem to find equivalent definitions for the Linux
kernel macro RTC_PIE_OFF for instance and the emulators/rtc port isn't
sufficiently documented for me to determine how the original author found
out what signals RTC_PIE_ON and RTC_IRQP_* (whatever macro is also defined
in /usr/local/include/linux/rtc.h).

-Garrett

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"



Found the following patch for MPlayer on google... don't know if it will
help...
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2005-January/032291.html

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Wireless card not being detected

[Coleman Kane]

On 2/18/07, DAK GHATIKACHALAM <[EMAIL PROTECTED]> wrote:


Hi Freebsd


I have an issue with new card I need to make it work with freebsd,


on /var/log/messages I get


Feb 18 20:51:55 DAK kernel: pccard0:  (manufacturer=0x0192,
produc
t=0x0710, function_type=6) at function 0
Feb 18 20:51:55 DAK kernel: pccard0:CIS info: Sierra Wireless, AC860,
3G
Net
work Adapter, R1


For some reason  I dont understand why I get unknown card error

Does any one has idea


Thanks
Dak




This is a 3G wireless card (not Wi-Fi)... apparently it is supposed to be
supported by the uart or sio drivers. You should try searching google for:
freebsd "sierra wireless" AC860

There are apparently some sort of changes to the kernel that need to be
made.

--
Coleman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: portupgrade O(n^m)?

[Coleman Kane]

On Thu, Feb 15, 2007 at 05:33:59PM +0100, Niclas Zeising wrote, and it was 
proclaimed:
> On 2/15/07, Coleman Kane <[EMAIL PROTECTED]> wrote:
> >On 2/15/07, Alexander Leidinger <[EMAIL PROTECTED]> wrote:
> >>
> >> Quoting Olivier Warin <[EMAIL PROTECTED]> (from Wed, 14 Feb 2007
> >> 19:54:09 +0100):
> >>
> >> > This issue is not only related to portupgrade, pkg_add a new port takes
> >> > far too long now... and make index each time I upgrade my ports is
> >> > awfull too.
> >>
> >> Regarding "make index": try "make fetchindex" right after the cvsup.
> >> IT may not be up to the point with the cvsupped stuff, but not far off.
> >>
> >> Bye,
> >> Alexander.
> >
> >
> >
> >I don't think we who use the modular X.org tree can do this since a number
> >of the ports won't be properly registered in the file (or am I off-base
> >here?).
> >--
> >Coleman
> 
> We who use the modular xorg tree cant do make fetchindex, we have to
> do make index... I've never had any problem with portupgrade taking
> forever to run if i've done a make index and a portsdb -u before
> running. But then again, I only have somewhere around 350 ports at the
> moment.
> 
> //Niclas

I have over 1000 ports installed and it can be annoyingly slow. I don't
completely know if the "portupgrade" script is the 100% culprit though,
as it calls a number of other programs during execution.

--
coleman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: portupgrade O(n^m)?

[Coleman Kane]

On 2/15/07, Alexander Leidinger <[EMAIL PROTECTED]> wrote:


Quoting Olivier Warin <[EMAIL PROTECTED]> (from Wed, 14 Feb 2007
19:54:09 +0100):

> This issue is not only related to portupgrade, pkg_add a new port takes
> far too long now... and make index each time I upgrade my ports is
> awfull too.

Regarding "make index": try "make fetchindex" right after the cvsup.
IT may not be up to the point with the cvsupped stuff, but not far off.

Bye,
Alexander.




I don't think we who use the modular X.org tree can do this since a number
of the ports won't be properly registered in the file (or am I off-base
here?).
--
Coleman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: portupgrade O(n^m)?

[Coleman Kane]

On 2/14/07, John Nielsen <[EMAIL PROTECTED]> wrote:


On Wednesday 14 February 2007 12:41, David Gilbert wrote:
> I have 734 ports installed on my laptop right now.  I'm pretty sure,
> at times, I've had over 1000 ports on my laptop.
>
> On machine with moderate numbers of ports (most servers seem to have
> 50 to 200 ports), portupgrade takes a moderate amount of time to start
> work.  On machines like my laptop, portupgrade seems to take much more
> time to run.  I assume it's solving the dependency graph before it
> decides what to upgrade first, but is this truly a O(n^2) problem?  It
> seems like the implemented algorithm is O(n^2).

Just a "me too". I noticed a huge increase in time for portupgrade when I
started using the modular Xorg ports tree and upgraded to X.org 7.2RC. The
number of installed ports on my machine went from just over 300 to well
over
600 as a result of the upgrade. Specifying small numbers of ports (without
globbing) to portupgrade doesn't seem to take much more time,
but "portupgrade -a" or anything similar takes forever now. If there is an
optimization to be made there it would be good to do it before modular
xorg
hits the official tree.

JN



I've also had this problem. I have found that if I perform a "portsdb -U &&
pkgdb -F" every time following a cvsup that portupgrade doesn't try to go
through the full ports indexing steps again.

It is still slow, and any improvement that can be made should be. It is
already a significant enough pain that most ports build in a shorter amount
of time than it takes portupgrade to update its database.

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: top delay value

[Coleman Kane]

On 1/31/07, Mike Meyer <[EMAIL PROTECTED]> wrote:


In <[EMAIL PROTECTED]>, Dr. Markus Waldeck <[EMAIL PROTECTED]>
typed:
> >  > > typing "while :; do :; done".  There are a thousand ways
>
> > No.  What I write above is not a "fork bomb", it's a single
> > process which is wasting CPU in a busy loop.  It's exactly
> > equivalent to top(1) with zero delay, except that top
> > produces some output, while a busy loop does nothing useful
> > at all.
>
> I tested different shells and I found out that an exlicit sub shell
> is required to let the shell fork:
>
> while :; do (:); done

That's still not a fork bomb. While it creates a process every time
through the loop, the process exits before the loop continues, so
you've still got just a few processes. Basicaly, it's still a busy
loop.

A true fork bomb creates an ever-increasing number of processes,
typically by forking copies of itself (which led to them being called
"rabbit jobs" when I first ran into one).


http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.



Don't forget that a real fork bomb would fork forking forkers thereby
growing the process overhead and time exponentially!

e.g:
perl -e 'while(1) { fork; };'

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/89528: [jail] impossible to kill a jail

[Coleman Kane]

On 1/4/07, Ed Schouten <[EMAIL PROTECTED]> wrote:


* Ed Schouten <[EMAIL PROTECTED]> wrote:
> As long as pty's have been allocated that have been created by threads
> in a jail, the prison structure has more references, causing the zombie
> jails to exist.

We could change the make_dev_credv() routine to crcopy() everything
except the prison when we're creating a node in a jail. The following
patch fixes the zombie jail bug on my machine:

--- src/sys/kern/kern_conf.cFri Oct 20 09:59:50 2006
+++ src/sys/kern/kern_conf.cThu Jan  4 21:36:44 2007
@@ -42,6 +42,7 @@
#include 
#include 
#include 
+#include 
#include 

#include 
@@ -563,7 +564,15 @@

dev->si_flags |= SI_NAMED;
if (cr != NULL)
-   dev->si_cred = crhold(cr);
+   if (cr->cr_prison == NULL) {
+   dev->si_cred = crhold(cr);
+   } else {
+   /* Don't let the node depend on a prison */
+   dev->si_cred = crget();
+   crcopy(dev->si_cred, cr);
+   prison_free(dev->si_cred->cr_prison);
+   dev->si_cred->cr_prison = NULL;
+   }
else
dev->si_cred = NULL;
dev->si_uid = uid;

Could other people experiencing this problem as well give this patch a
try? Thanks a lot!

Yours,
--
Ed Schouten <[EMAIL PROTECTED]>
WWW: http://g-rave.nl/




Does this behavior still occur if you set sysctl kern.pts.enable=1 ?

Is this at all related to why I have been experiencing zombies left behind
for any process that alloc's its own tty (such as gnome-terminal [actually
gnome-pty-helper])? If I CTRL-D to end a gnome-terminal session, it will
hang all of the gnome-terminals I have open and I typically have to reboot
to clear out the zombies that remain. I can't open any more apps that use
gnome-pty-helper to allocate ttys unless I attempt to kill it and start it
anew (and I am not even completely sure if that works).

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Doubts with scheduler code

[Coleman Kane]

On 1/2/07, Anand H. Krishnan <[EMAIL PROTECTED]> wrote:


Hi,

I had a couple of doubts when I was going through 6.1 freebsd code.

* First one is in the  wakeup() code. After a series of calls wakeup()
lands in maybe_preempt() and if preemption is enabled maybe_preempt()
switches to a new thread (if a high priority thread has been made
runnable).
That means that an interrupt handler which calls wakeup() will not return
immediately. (I'm looking @ ULE scheduler).

So is there a problem when wakeup() is called from high priority (fast
interr
upt) handlers ?

* Second one is in spinlock code. Can anyone say why critical_enter is
called from spinlock_enter() ? The only thing that critical_enter seems to
be doing is to increment td_critnest which probably helps in finding out
whether a thread can be pre-empted or not. But spinlock_enter() disables
interrupts and I fail to understand how can any thread become runnable
and get scheduled in between.

I've one more..

* msleep() allows a thread to change it's priority when it gets woken up
and
in many places they gets woken up with very high priority indeed. Is there
any convincing reason as to why it should be ?

Thanks,
Anand



Anand,

If I remember correctly a significant amount of the ULE scheduler code from
6.1 (and 7-CUR at that time) has been overhauled. In fact, the scheduler was
taken off the list of "working" due to a bunch of problems. You may want to
review the versions of the scheduler code from the latest -CURRENT or
6.2-RELEASE and then re-ask...

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Linking static libraries with '-l'

[Coleman Kane]

On 12/20/06, Dan Nelson <[EMAIL PROTECTED]> wrote:


In the last episode (Dec 20), mal content said:
> So, if I want to link to the shared library /usr/local/libxyz.so, I
> simply add '-lxyz' to my program link commands. But what if I want to
> link to the equivalent static library?

One method is to pass -Bstatic and -Bdynamic to the linker at
appropriate places:

  ${CC} ${CFLAGS} ${LDFLAGS} -o myprogram myprogram.o -Wl,-Bstatic -lxyz
-Wl,-Bdynamic

That line will pull in libxyz.a while trying to use shared libraries
for everything else.  The drawbacks are: 1) if for some reason you want
to link that binary statically, you can't just add a LDFLAGS+=-static
to the Makefile; you have to remove all instances of -Wl,-Bdynamic;
2) it's not a standard option (-Wl and -B are supported by Solaris and
GNU cc and ld, but not AIX), so it's no more portable than determining
the static library's filename and linking to it directly.

> I've not tried it, but I think this might work:
>
>  /usr/local/lib/libxyz.so
>  /usr/local/lib-static/libxyz.a
>
> That way, a program should be able to specify:
>
>  cc -o myprog myprog.o -L/usr/local/lib -lxyz.so -L/usr/local/lib-static
-labc
>
> ...and get the dynamic 'libxyz.so' and the static 'libabc.a'.

-L adds paths to the end of the search list, so if there's a
/usr/local/lib/libabc.so, the linker will use that.

--
Dan Nelson
[EMAIL PROTECTED]



I believe you can also specify ar archives (what static libs really are is
ar(1) archives of .o files with ranlib(1) run across it).

For example the following code will be linked to libm.so normally:
#include 
#include 

int
main(int argc, char **argv) {
 double aoi = 12.0;

 printf("%f\n", fabs(aoi));
}

If I would like to link it against shared libm (/usr/lib/libm.so):
cc -o mathprog mathprog.c -lm
 or simply
cc -o mathprog mathprog.c (since FreeBSD automatically does the -lm in this
case)

If I would like to use the static libm (located at /usr/lib/libm.a):
cc -o mathprog mathprog.c /usr/lib/libm.a

Its not quite as nice as the auto-search behavior, but it allows you to
literally specify a static library on the commandline. I believe there might
be one caveat in the case where another dynamic library dynamically links in
libm.so... mainly an ambiguity of which fabs() is actually called... I am
not familiar with how this would be resolved in this case.

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: if exists statement

[Coleman Kane]

On 12/18/06, Beech Rintoul <[EMAIL PROTECTED]> wrote:


I'm trying to write an if exists for a port makefile.

I tried:

.if exists= ${PREFIX}/etc/rc.d
exit
else
${MKDIR} ${PREFIX}/etc/rc.d
.endif

but it doesn't work.

Can someone give me the right syntax?

TIA

Beech
--



I think you want something like:
.if exists($(PREFIX)/etc/rc.d)

...


--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [call for comments] l2sched

[Coleman Kane]

On 11/2/06, Maxim A. Zhuravlev <[EMAIL PROTECTED]> wrote:


>Optionally, you could post a
> blog entry of it and allow for comments...
>


http://mzhuravlev.blogspot.com/

--
JID: [EMAIL PROTECTED]

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"



Thanks, you rock!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [call for comments] l2sched

[Coleman Kane]

On 11/2/06, Maxim A. Zhuravlev <[EMAIL PROTECTED]> wrote:


> Did you forget to post a link to the patches or code?  Or
> include an attachment?


Well, working on them currently. I'd like to get some comments on the
design.

--
JID: [EMAIL PROTECTED]

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"



It sounds interesting. If you have access to publish HTML or PDF somewhere,
that would be appealing. Perhaps you could post a better formatted version
of the previous email up as a wepage somewhere. Optionally, you could post a
blog entry of it and allow for comments...

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC

[Coleman Kane]

On Wed, May 24, 2006 at 12:29:28PM -0500, Eric Anderson wrote, and it was 
proclaimed:
> Eric Anderson wrote:
> >Coleman Kane wrote:
> >>On Mon, May 01, 2006 at 12:29:20PM -0700, Brooks Davis wrote:
> >>>On Mon, May 01, 2006 at 02:16:04PM -0500, Eric Anderson wrote:
> >>>>Brooks Davis wrote:
> >>>>>On Mon, May 01, 2006 at 02:13:22PM -0500, Eric Anderson wrote:
> >>>>>>Brooks Davis wrote:
> >>>>>>>On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote:
> >>>>>>>>Coleman Kane wrote:
> >>>>>>>>>On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote:
> >>>>>>>>>>Eric Anderson wrote:
> >>>>>>>>>>
> >>>>>>>>>>Actually, some other things got changed somewhere in the 
> >>>>>>>>>>history, that broke some things and assumptions I was making.  
> >>>>>>>>>>This patch has them fixed, and I've tested it with all the 
> >>>>>>>>>>different options:
> >>>>>>>>>>
> >>>>>>>>>>http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9
> >>>>>>>>>>
> >>>>>>>>>>It's missing the defaults/rc.conf diffs, but you should 
> >>>>>>>>>>already know those.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>Eric
> >>>>>>>>>>
> >>>>>>>>>I have a new patch (to 7-CURRENT) of the "fancy_rc" updates.
> >>>>>>>>>
> >>>>>>>>>This allows the use of:
> >>>>>>>>>rc_fancy="YES"--->  Turns on fancy reporting (w/o color)
> >>>>>>>>>rc_fancy_color="YES"  --->  Turns on fancy reporting (w/ 
> >>>>>>>>>color), needs
> >>>>>>>>> rc_fancy="YES"
> >>>>>>>>>rc_fancy_colour="YES" --->  Same as above for you on the other 
> >>>>>>>>>side of
> >>>>>>>>> the pond.
> >>>>>>>>>rc_fancy_verbose="YES" -->  Turn on more verbose activity 
> >>>>>>>>>messages.
> >>>>>>>>> This will cause what appear to be "false
> >>>>>>>>>positives", where an unused service is
> >>>>>>>>>"OK" instead of "SKIP".
> >>>>>>>>>
> >>>>>>>>>You can also customize the colors, the widths of the message
> >>>>>>>>>brackets (e.g. [   OK   ] vs. [ OK ]), the screen width, and
> >>>>>>>>>the contents of the message (OK versus GOOD versus BUENO).
> >>>>>>>>>
> >>>>>>>>>Also, we have the following message combinations:
> >>>>>>>>>OK   --->  Universal good message
> >>>>>>>>>SKIP,SKIPPED ---> Two methods for conveying the same idea?
> >>>>>>>>>ERROR,FAILED ---> Ditto above, for failure cases
> >>>>>>>>>
> >>>>>>>>>Should we just have 3 different messages, rather than 5 messages
> >>>>>>>>>in 3 categories?
> >>>>>>>>Yes, that's something that started with my first patch, and 
> >>>>>>>>never got ironed out.  I think it should be:
> >>>>>>>>OK
> >>>>>>>>SKIPPED
> >>>>>>>>FAILED
> >>>>>>>>and possibly also:
> >>>>>>>>ERROR
> >>>>>>>>
> >>>>>>>>The difference between FAILED and ERROR would be that FAILED 
> >>>>>>>>means the service did not start at all, and ERROR means it 
> >>>>>>>>started but had some kind of error response.
> >>>>>>>FAILED vs ERROR seems confusing.  I'd be inclined toward WARNING vs
> >>>>>>>FAILED or ERROR.
> >>>>>>True, however I s

Re: [PATCH] Fancy rc startup style RFC - v6

[Coleman Kane]

Hey all,

My webserver went down earlier this week, and I have moved
my mail. I am in the arduous process of getting a new 
replacement. I apologize for the delay however, on the 
rc.subr colorization project, and hope to have the newest
updates available again soon.

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC

[Coleman Kane]

On Mon, May 01, 2006 at 12:29:20PM -0700, Brooks Davis wrote:
> On Mon, May 01, 2006 at 02:16:04PM -0500, Eric Anderson wrote:
> > Brooks Davis wrote:
> > >On Mon, May 01, 2006 at 02:13:22PM -0500, Eric Anderson wrote:
> > >>Brooks Davis wrote:
> > >>>On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote:
> > >>>>Coleman Kane wrote:
> > >>>>>On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote:
> > >>>>>>Eric Anderson wrote:
> > >>>>>>
> > >>>>>>Actually, some other things got changed somewhere in the history, 
> > >>>>>>that broke some things and assumptions I was making.  This patch has 
> > >>>>>>them fixed, and I've tested it with all the different options:
> > >>>>>>
> > >>>>>>http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9
> > >>>>>>
> > >>>>>>It's missing the defaults/rc.conf diffs, but you should already know 
> > >>>>>>those.
> > >>>>>>
> > >>>>>>
> > >>>>>>Eric
> > >>>>>>
> > >>>>>I have a new patch (to 7-CURRENT) of the "fancy_rc" updates.
> > >>>>>
> > >>>>>This allows the use of:
> > >>>>>rc_fancy="YES"--->  Turns on fancy reporting (w/o color)
> > >>>>>rc_fancy_color="YES"  --->  Turns on fancy reporting (w/ color), needs
> > >>>>>  rc_fancy="YES"
> > >>>>>rc_fancy_colour="YES" --->  Same as above for you on the other side of
> > >>>>>  the pond.
> > >>>>>rc_fancy_verbose="YES" -->  Turn on more verbose activity messages.
> > >>>>>  This will cause what appear to be "false
> > >>>>>   positives", where an unused service is
> > >>>>>   "OK" instead of "SKIP".
> > >>>>>
> > >>>>>You can also customize the colors, the widths of the message
> > >>>>>brackets (e.g. [   OK   ] vs. [ OK ]), the screen width, and
> > >>>>>the contents of the message (OK versus GOOD versus BUENO).
> > >>>>>
> > >>>>>Also, we have the following message combinations:
> > >>>>>OK   --->  Universal good message
> > >>>>>SKIP,SKIPPED ---> Two methods for conveying the same idea?
> > >>>>>ERROR,FAILED ---> Ditto above, for failure cases
> > >>>>>
> > >>>>>Should we just have 3 different messages, rather than 5 messages
> > >>>>>in 3 categories?
> > >>>>Yes, that's something that started with my first patch, and never got 
> > >>>>ironed out.  I think it should be:
> > >>>>OK
> > >>>>SKIPPED
> > >>>>FAILED
> > >>>>and possibly also:
> > >>>>ERROR
> > >>>>
> > >>>>The difference between FAILED and ERROR would be that FAILED means the 
> > >>>>service did not start at all, and ERROR means it started but had some 
> > >>>>kind of error response.
> > >>>FAILED vs ERROR seems confusing.  I'd be inclined toward WARNING vs
> > >>>FAILED or ERROR.
> > >>True, however I still see a difference between FAILED and WARNING. For 
> > >>instance, as an example: a FAILED RAID is different than a RAID with a 
> > >>WARNING.
> > >
> > >For that level of detail, the ability to provide additional output seems
> > >like the appropriate solution.
> > 
> > Yes, true, but you'd still want to show something (I would think) in the 
> >  [ ]'s to keep it consistent.
> 
> My feeling is that anything short of complete success should report
> WARNING and a message unless it actually totally failed in which case
> FAILED or ERROR (I slightly perfer ERROR) should be used.
> 
> -- Brooks

What situations are we determining get flagged as ERROR versus FAILED?
Is FAILED considered to be 'I was able to run the command, but it
returned an error code', versus ERROR being 'I could not even run the
command!' like bad path, file not found, etc...

This point still kind of confuses me (and needs to be well defined). I
am an advocate of having three distinct messages: OK, SKIPPED, ERROR.
And not even bothering with the different types of ERROR/FAILED other
than having extra reporting output.

Of course, I am still willing to implement what the consensus is.

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC

[Coleman Kane]

On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote:
> Eric Anderson wrote:
>
> Actually, some other things got changed somewhere in the history, that 
> broke some things and assumptions I was making.  This patch has them 
> fixed, and I've tested it with all the different options:
> 
> http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9
> 
> It's missing the defaults/rc.conf diffs, but you should already know those.
> 
> 
> Eric
> 

I have a new patch (to 7-CURRENT) of the "fancy_rc" updates.

This allows the use of:
rc_fancy="YES"--->  Turns on fancy reporting (w/o color)
rc_fancy_color="YES"  --->  Turns on fancy reporting (w/ color), needs
rc_fancy="YES"
rc_fancy_colour="YES" --->  Same as above for you on the other side of
the pond.
rc_fancy_verbose="YES" -->  Turn on more verbose activity messages.
This will cause what appear to be "false
positives", where an unused service is
"OK" instead of "SKIP".

You can also customize the colors, the widths of the message
brackets (e.g. [   OK   ] vs. [ OK ]), the screen width, and
the contents of the message (OK versus GOOD versus BUENO).

Also, we have the following message combinations:
OK   --->  Universal good message
SKIP,SKIPPED ---> Two methods for conveying the same idea?
ERROR,FAILED ---> Ditto above, for failure cases

Should we just have 3 different messages, rather than 5 messages
in 3 categories?

TODO: One thing I am trying to figure out is how to get the
  terminal to report its width, in columns (which is something
  that VT100+ supports). I just don't know how to do it from a
  script.

TODO: Get better reporting from the rc.d/* scripts (and whatever
  other services we track). Right now, if verbose is on, many
  services respond with OK when they aren't initialized, and
  some respond with SKIP/SKIPPED/FAILED. E.g.: pcvt will show
  "SKIP", but geli2 will show "OK". Neither of these two are
  enabled for me though.

You may get it from here:
http://www.cokane.org/files/rc_fancy-cokane5.patch


Further:

I am very open to suggestions regarding the rc.d/* system and its
reporting mechanisms. I am even thinking that it might be a good 
idea to offer an overhauled set of scripts that forces functionality
into the following framework:
rc job offers result code (from which the OK,SKIP,ERROR, etc... are
picked)
rc job offers short (< 20 char) status message. This could be printed
in a nice fashion just after the "Running start XXX", "Running stop
YYY", which we currently display.
rc job (or rc itself) offers name of job (geli2, moused, etc...).

Thus, the lines are nice, consistent, and fluid. The "short status
message" above would most likely be truncated to 20 chars (or so.).

Hopefully, some of this can then start to be put into an rc-reporter
such that I could run a command that could give me a nice report of
rc/init:
moused  FAILED"short message"

Gentoo has a nice script named rc-status that does similar. Though
I am not too fond of its output format (job name at left, status at 
right edge, hard to find out what failed in a multiline report).

Try this latest version, and drop a line back with your thoughts,
criticisms, etc

--
Coleman Kane
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC - v6

[Coleman Kane]

On 4/23/06, Sean Winn <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote:
> > On Thu, Apr 20, 2006 at 10:32:33PM -0500, Eric Anderson wrote:
> >> Other than that, do we have general consensus that these do what they
> >> claim?  Any outstanding issues that haven't been addressed?
> >
> > One request:
> >
> > Please remove the two seperate rc.conf lines, and replace with just
> >   one: rc_fancy= YES | NO | COL[O|OU]R
> >
> > So that it works line the sendmail_enable option (YES/NO/NONE)
> > Then include any other tunables in rc_fancy_flags
>
> Definitely not a good idea to use that as a model:
>
> man rc.sendmail
>
> ..
>  sendmail_enable
>  (str) If set to ``YES'', run the sendmail(8) daemon at
> system
>  boot time.  If set to ``NO'', do not run a sendmail(8)
> daemon to
>  listen for incoming network mail.  This does not preclude a
>  sendmail(8) daemon listening on the SMTP port of the
> loopback
>  interface.  The ``NONE'' option is deprecated and should
> not be
>  used.  It will be removed in a future release.
> ..
>
> Yes/no options should just be yes/no.


Correct, I concur. This is especially true since the 'configuration check'
function is checkyesno and looks for YES or NO values. In fact, I think that
sendmail was the only one two use this convention. This was brought in to
appease those who use qmail (or other mailservers) with an easy method of
turning off sendmail's local 'spool' service, to instead use qmail (or
whatever else you like...). I remember the convention not being very
pleasant for those involved.

--
coleman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC - v6

[Coleman Kane]

On 4/21/06, David Barbero <[EMAIL PROTECTED]> wrote:
>
>
> Eric Anderson escribió:
> >> After to apply the patch, so that it works is necessary to put in
> >> rc.conf
> >> rc_fancy="YES ", when put this single entry, the system gives errors
> >> saying that correctly this entry in rc.conf is not correctly defined,
> >> adding single rc_fancy_color="YES" gives the same error.
> >> If the two entry meetings are added it don't show the error.
> >> I believe that serious advisable that these two entry did not depend
> the
> >> one on the other and worked separately.
> >
> > Well, obviously the _color option depends on the rc_fancy option being
> > enabled, otherwise it doesn't make sense, however you can of course have
> > rc_fancy enabled with rc_fancy_color disabled.
>
> yes, this is obvious, but i say rc_fancy depends on the rc_fancy_color,
> disabled or no, in rc.conf, if you don't put a entry for rc_fancy_color in
> rc.conf, the boot menssage show error.
>
> > Yep, that's a bug.  I think it's fixed in v7, available here:
> >
> > http://www.googlebit.com/freebsd/patches/rc_fancy.patch-7
> >
> > along with a few other suggestions from others.
>
> Ok, i will probe this patch in a few days and tell you for this. Probably
> Sunday can say something, right now I am of business trip and I do not
> have my PC of tests here...
>
> >> Another one of the failures that I have seen is that with this patch
> >> they
> >> show all the services, they are or not formed to start, I believe that
> >> single they would have to appear the services that are formed to start
> >> and
> >> not all those that can start.
> >
> > If the service is run on bootup, it shows it.  It was still being run
> > before, there was just no output previously.  It would be pretty easy to
> > have an option to not print these, maybe an rc_fancy_verbose option.  Is
> > this desirable to most?
>
> I think a _verbose option don't for now, but can will be interesting.
>
> In any case I talked about that if you don't start a service (Ex:
> geli_enable="NO" in rc.conf) at boot time, in your patch this service it's
> show, and IMHO, if the service don't start at bootup, then don't show
> startup.
>
> >> In addition  the services that are not formed to start appear like [ OK
> >> ],
> >> in the case of appearing these, I believe that they would have to leave
> >> with another denomination that is not [ OK ].
> >
> >
> > I'm not sure what you mean here.  Can you give me an example?
>
> Sorry for my English :)
>
> Yes, of course.
>
> in rc.conf:
> geli_enable="NO"
> inetd_enable="NO"
>
> And when yo reboot, the bootup menssage show:
>
> geli service   [OK]
> inetd service  [OK]
>
> And I believe that this menssage don't show on startup, or in the case of
> show the messange, this don't show the [OK], in that case, show [SKIP],
> for example.
>
> >> Another failure that I have seen is that when leaving the message
> >> syslogd
> >> this sample failure, but this service starts without problems, but
> shows
> >> it as if it gave failure...
> >
> > My syslogd looks clean, and doesn't give a false failure.  I'm not sure
> > how to look into this - can you confirm that it truly is passing, but
> > giving the wrong message, or is it that the rc subsystem thinks it's
> > failing but appears to work ok?
>
> My syslogd work properly whitout any error, but give a false positive, I
> will be probe the last patch and I will try to see if I locate the
> failure, but will have Sunday...
>
> I see other fail in show the fancy_* when I have activated vidcontrol to
> 1024x764, but this is but so that it is pretty that an operation failure,
> IMHO is not important...
>
> > Thanks for all the feedback and testing!
>
> :)
>
> > Eric
>
> Regards


There was a small defect in the recent version of this script that caused
the line width to be too big on the syscons console. I modified it and
posted it at:
http://www.cokane.org/files/rc_fancy-cokane3.patch

--coleman kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC - v6

[Coleman Kane]

On Thu, Apr 20, 2006 at 10:32:33PM -0500, Eric Anderson wrote:
> 
> 
> This looks good. I only wonder about two things now:
> 
> - Should we also have a line for the actual colors used too?  Or is that 
> going too crazy?
> 
> - Does it meet style(9)?  I'm wondering about line lengths now.
> 
> Other than that, do we have general consensus that these do what they 
> claim?  Any outstanding issues that haven't been addressed?
> 
> 
> Eric
> 
> 
> 

It looks like freebsd.org (actually SpamCop) might finally be blocking 
gmail now :(...

I sent the following and it got bounced:

There was a small defect in the recent version of this script that
caused the line width to be too big on the syscons console. I modified
it and posted it at:
http://www.cokane.org/files/rc_fancy-cokane3.patch

--
coleman kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC - v6

[Coleman Kane]

On 4/20/06, Eric Anderson <[EMAIL PROTECTED]> wrote:
>
> David Barbero wrote:
> >
>  --- snip ---
>
Yep, that's a bug.  I think it's fixed in v7, available here:
>
> http://www.googlebit.com/freebsd/patches/rc_fancy.patch-7
>
> along with a few other suggestions from others.
>
>
> > Another one of the failures that I have seen is that with this patch
> they
> > show all the services, they are or not formed to start, I believe that
> > single they would have to appear the services that are formed to start
> and
> > not all those that can start.
>
> If the service is run on bootup, it shows it.  It was still being run
> before, there was just no output previously.  It would be pretty easy to
> have an option to not print these, maybe an rc_fancy_verbose option.  Is
> this desirable to most?
>
> > In addition  the services that are not formed to start appear like [ OK
> ],
> > in the case of appearing these, I believe that they would have to leave
> > with another denomination that is not [ OK ].
>
>
> I'm not sure what you mean here.  Can you give me an example?
>
>
> > Another failure that I have seen is that when leaving the message
> syslogd
> > this sample failure, but this service starts without problems, but shows
> > it as if it gave failure...
>
> My syslogd looks clean, and doesn't give a false failure.  I'm not sure
> how to look into this - can you confirm that it truly is passing, but
> giving the wrong message, or is it that the rc subsystem thinks it's
> failing but appears to work ok?
>
>
> > In principle this is what I have seen at first sight on the patch.
>
>
> Thanks for all the feedback and testing!
>
>
> Eric


I have modified the patch as follows:

Made a bunch of the settings tunable by the user (message text and field
widths).

It is availalbe at http://www.cokane.org/files/rc_fancy-cokane2.patch

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC - v6

[Coleman Kane]

On 4/20/06, Eric Anderson <[EMAIL PROTECTED]> wrote:
>
> Coleman Kane wrote:
> >
> > I have modified the patch as follows:
> >
> > Made a bunch of the settings tunable by the user (message text and field
> > widths).
> >
> > It is availalbe at http://www.cokane.org/files/rc_fancy-cokane2.patch
>
>
> This looks good. I only wonder about two things now:
>
> - Should we also have a line for the actual colors used too?  Or is that
> going too crazy?


Definately... I think having the ability to specify colorsets as profiles
will be a must-have. Read the LSCOLORS description in ls(1).

- Does it meet style(9)?  I'm wondering about line lengths now.


One unfortunate thing about /bin/sh: [from the sh(1) manpage]

 Only one of the -e and -n options may be specified.

This means that we may not be able to use the -n to chain multiple echos on
one line...

Other than that, do we have general consensus that these do what they
> claim?  Any outstanding issues that haven't been addressed?
>
>
> Eric


--coleman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC

[Coleman Kane]

On 4/19/06, Mike Meyer <[EMAIL PROTECTED]> wrote:
>
> In <[EMAIL PROTECTED]>, Coleman
> Kane <[EMAIL PROTECTED]> typed:
> > On 4/19/06, Mike Meyer <[EMAIL PROTECTED]>
> wrote:
> > How about we all discuss good choices for "default" colors?
>
> Depends on the goal: do you want the default to work for everyone, or
> do you want the default to be prettier and/or better for most people
> but absolutely suck for a few?


I was thinking perhaps of having a predefined set of templates (with the
option and documentation to add your own). Perhaps implement one that
creates the "traffic-light" style that seems to make intuitive sense to many
americans (Bold Red: error, Bold Green: Success, Bold Yellow:
warning/notice), and also have another perdefined one that uses a different
color set.

BTW, I know that blue and red are "bad" colors. How to the "emphasized" or
"emboldened" versions of these colors match up?

I like the former. Which means the defaults need to be black and
> white. Given a sufficiently flexible system for picking colors, we can
> use bold/underline/reversed as "colors". That might work well under
> that constraint.


I am merely talking about predefined color choices... of course if
rc_fancy_color="NO" then fancyiness will be B+W. I'd like to know if there
are better choices than Red/Green/Yellow. To me Red/Green/Yellow make sense
to a lot of people because of their relation to our driving system here in
the states. Maybe something like Error=Yellow, Good=Blue, Warn/Notice=Green
is a better choice across the board.

 --
> Mike Meyer <[EMAIL PROTECTED]>
> http://www.mired.org/consulting.html
> Independent Network/Unix/Perforce consultant, email for more information.
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC

[Coleman Kane]

On 4/19/06, Mike Meyer <[EMAIL PROTECTED]> wrote:
>
> In <[EMAIL PROTECTED]>, Coleman
> Kane <[EMAIL PROTECTED]> typed:
> > On 4/19/06, Eric Anderson <[EMAIL PROTECTED]> wrote:
> > > >>> Please do not use colors in rc. Escape-sequenced colors make
> > > >>> unacceptable assumptions about the user and syslogd strips
> > > >>> escape sequences anyway, so it would be of no use to logged
> > > >>> consoles. Serial consoles introduce other problems with buggy
> > > >>> escape handling in third-party terminal programs. A good text
> > > >>> layout and descriptive status messages do far more for clarity
> > > >>> and readability than any use of color ever can.
> > This point can be debated...
>
> Only the last point, and only because it involves a quantity that's
> very difficult to measure.
>
> > read some literature from Edward Tufte...
>
> I've read Tufte. I've gotten him to sign my copy of some of his books
> at his seminars. I wish (vehemently!) that more web authors would read
> Tufte.
>
> > colors are a good way to cram more "information" into a space without
> > actually compromising the capacity of that space.
>
> True, but that's not his point. His point is that the colors aren't
> always visible (another thing I wish more web authors were aware
> of). The text layout and status messages should work well in
> environments where the colors aren't visible, because there are times
> when that's the kind of environment they'll be in.
>
> That said, colors can make checking for exceptions much easier - if
> you can see them. So I don't have any problem with adding
> colors. However, they should be off by default (at least initially),
> and the messages and layout should be tested that way until they work
> well without colors.


I want to make a nicely configurable console message system that includes
colors and formatting settable by the user (with a few sane defaults). I am
familiar with the trouble of using red for errors (if you've ever seen red
on a B+W TV you'll know too).

How about we all discuss good choices for "default" colors?

And, I think I am going to assemble some sort of "framework" sh script for
this after all. Either it gets ammended to rc.subr, or it sits alone as its
own dedicated module (that can be sourced by rc.*).

 --
> Mike Meyer <[EMAIL PROTECTED]>
> http://www.mired.org/consulting.html
> Independent Network/Unix/Perforce consultant, email for more information.
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC

[Coleman Kane]

On 4/19/06, Eric Anderson <[EMAIL PROTECTED]> wrote:
>
> Eric Anderson wrote:
> > Bill Vermillion wrote:
> >> Somewhere around Wed, Apr 19, 2006 at 04:07 , the world stopped
> >> and listened as [EMAIL PROTECTED] graced us with
> >> this profound tidbit of wisdom that would fulfill the enjoyment of
> >> future generations:
> >>
> >>> Message: 20
> >>> Date: Tue, 18 Apr 2006 15:07:31 -0700
> >>> From: Darren Pilgrim <[EMAIL PROTECTED]>
> >>
> >>> Eric Anderson wrote:
> >>
> >>>  > If I could figure out how to make sh do colors, I'd do it. :)
> >>
> >>> Please do not use colors in rc. Escape-sequenced colors make
> >>> unacceptable assumptions about the user and syslogd strips
> >>> escape sequences anyway, so it would be of no use to logged
> >>> consoles. Serial consoles introduce other problems with buggy
> >>> escape handling in third-party terminal programs. A good text
> >>> layout and descriptive status messages do far more for clarity
> >>> and readability than any use of color ever can.


This point can be debated... read some literature from Edward Tufte...
colors are a good way to cram more "information" into a space without
actually compromising the capacity of that space.

>>
> >> Let me add to that.  About 10% of the male population has some
> >> color vision problem.  Mine is a bit more than others.   Everytime
> >> I get called to work on a Linux system, I have to go in and disable
> >> the colors as the reds and other colors become very hard to see
> >> against a dark background.   The problem is the luminance value of
> >> colors such a red is quite low compared to others.  That's one of
> >> the reasons why fire-trucks in this area are lime-green, as red
> >> trucks disappear into the blackness at night.
> >>
> >> If you add color make sure it is a user selectable option
> >> and not turned on by default.   IMO everything you need to admin a
> >> system needs to be able to run on something as lowly as a pure
> >> serial terminal as the above poster notes.
> >
> >
> > Ok. So I've received mass amounts of mail regarding this, and most of it
> > has been positively in favor of having the option to enable the
> > rc_fancy, and then an additional option to turn on coloring, with the
> > default to be non-colored but still rc_fancy="YES" which should work ok
> > on serial and other terminals (it did for me).
> >
> >
> > I completely agree about all the coloring comments, and terminal issues.
> >  I personally think it should be an available option, easily enabled or
> > disabled at will.
> >
> > I've put up an updated version, with many changes.  This version
> > includes optional coloring (with rc_fancy_color="YES" in rc.conf),
> > better checking, cleaner coding, and no loops.  This version is *much*
> > more refined than the others - thanks for all the hints everyone!
> >
> >
> > http://www.googlebit.com/freebsd/patches/rc_fancy.patch-5
>
> Looks like this version does something strange - from an xterm, the
> spacing is correct, but from console, it doesn't do anything with the
> \033[71G in the echo.  I've played with term types, but can't seem to
> make it act the same under console as it does in an xterm.
>
> Anyone know the issue?
>
>
> Eric


Try:

\033[71C



Hmm... I see 71 spaces how about we just stick to the padding... I would
like to not go overboard by using a lot of other escape sequences that have
less experience out in the wild (and thus, less testing and are more likely
to fail). Colors and attributes seem to be the overwhelming majority of
reasons using the escape codes. Cursor control and other macros are probably
less common.

You can change the \033 ---> \e if you like, or leave it. We should settle
ourselves on a standard for this however... maybe make a /etc/rc.fancy that
has macros for all of this stuff.


Also, I second the comment regarding making this tunable. Of course the
console will default to 7-bit ASCII text, printable characters only (or
whatever charset you have chosen). One of the big reasons for Linux's
"prettification" of its console, and support for fb console, is that there
are a good number of Linux installations out there where the primary
application is desktop and workstation.

As for me, I primarily run FreeBSD as a desktop/workstation and therefore
enjoy the opportunity to make the console more "readable". We discuss the
"bare necessities for servers" and "what's necessary for administering a
server", I think that my (and others') workstation needs and desires are
important to the development of FreeBSD too. We should be embracing the
adoption of the platform for workstation and desktop use as well, and
actually take the advice of those users to heart. I would hope that if this
featureset can get into the base system, then tunables get into the Console
section of sysinstall (allowing this to be turned on at install time) and
that the screenshots generated from that entice people who like things like
"colorful error messages" to gain more intere

Re: [PATCH] Fancy rc startup style RFC

[Coleman Kane]

On 4/18/06, Doug Barton <[EMAIL PROTECTED]> wrote:
>
> While I personally am not necessarily opposed to this kind of patch, you
> should be aware that this idea has been proposed in the past, and roundly
> rejected. The consensus has been that we don't necessarily want FreeBSD to
> look like other OSes that do this.


I remember a time back when the idea of an /etc/rc.d/ was taboo to bring
up hopefully times are better now!

That said, when you have something that you're ready for a wider review on,
> please submit it first to freebsd-rc@, then [EMAIL PROTECTED]
>
> 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]"
>

You want colors?!?

You can have them! (attached)

---
Coleman Kane
--- rc.subr.orig	Tue Apr 18 18:06:20 2006
+++ rc.subr	Tue Apr 18 18:09:24 2006
@@ -313,12 +313,16 @@
 			break
 		fi
 		_list=$_nlist
-		echo -n ${_prefix:-"Waiting for PIDS: "}$_list
+		if ! checkyesno rc_fancy; then
+			echo -n ${_prefix:-"Waiting for PIDS: "}$_list
+		fi
 		_prefix=", "
 		sleep 2
 	done
 	if [ -n "$_prefix" ]; then
-		echo "."
+		if ! checkyesno rc_fancy; then
+			echo "."
+		fi
 	fi
 }
 
@@ -564,12 +568,14 @@
 	# if the precmd failed and force
 	# isn't set, exit
 	#
+			rcargsize=`echo $rc_arg`
+			rcargsize=${#rcargsize}
 			if [ -n "$_precmd" ]; then
 debug "run_rc_command: evaluating ${_precmd}()."
 eval $_precmd $rc_extra_args
 _return=$?
 [ $_return -ne 0 ] && [ -z "$rc_force" ] &&
-return 1
+(echo_fancy "FAILED" `expr 10 + $rcargsize - 1`) && return 1
 			fi
 
 			if [ -n "$_cmd" ]; then
@@ -577,7 +583,7 @@
 eval $_cmd $rc_extra_args
 _return=$?
 [ $_return -ne 0 ] && [ -z "$rc_force" ] &&
-return 1
+(echo_fancy "FAILED" `expr 10 + $rcargsize - 1`) && return 1
 			fi
 
 			if [ -n "$_postcmd" ]; then
@@ -585,6 +591,7 @@
  eval $_postcmd $rc_extra_args
 _return=$?
 			fi
+			echo_fancy "  OK  " 0
 			return $_return
 		fi
 
@@ -600,13 +607,16 @@
 			;;
 
 		start)
+ 			echo -n "Starting ${name}"
 			if [ -z "$rc_fast" -a -n "$rc_pid" ]; then
+ echo_fancy " SKIP " 9
 echo 1>&2 "${name} already running? (pid=$rc_pid)."
 return 1
 			fi
 
 			if [ ! -x ${_chroot}${command} ]; then
 info "run_rc_command: cannot run ($command)."
+ echo_fancy "ERROR " 9
 return 1
 			fi
 
@@ -617,6 +627,7 @@
 if ! checkyesno $_f; then
 	warn "\$${_f} is not enabled."
 	if [ -z "$rc_force" ]; then
+		echo_fancy "ERROR " 9
 		return 1
 	fi
 fi
@@ -625,6 +636,7 @@
 if [ ! -d "${_f}/." ]; then
 	warn "${_f} is not a directory."
 	if [ -z "$rc_force" ]; then
+		echo_fancy "ERROR " 9
 		return 1
 	fi
 fi
@@ -633,6 +645,7 @@
 if [ ! -r "${_f}" ]; then
 	warn "${_f} is not readable."
 	if [ -z "$rc_force" ]; then
+		echo_fancy "ERROR " 9
 		return 1
 	fi
 fi
@@ -646,12 +659,11 @@
 eval $_precmd
 _return=$?
 [ $_return -ne 0 ] && [ -z "$rc_force" ] &&
-return 1
+(echo_fancy "ERROR " 9) && return 1
 			fi
 
 	# setup the command to run, and run it
 	#
-			echo "Starting ${name}."
 			if [ -n "$_chroot" ]; then
 _doit="\
 ${_nice:+nice -n $_nice }\
@@ -673,7 +685,7 @@
 			debug "run_rc_command: _doit: $_doit"
 			eval $_doit
 			_return=$?
-			[ $_return -ne 0 ] && [ -z "$rc_force" ] && return 1
+			[ $_return -ne 0 ] && [ -z "$rc_force" ] && (echo_fancy "FAILED" 9) && return 1
 
 	# finally, run postcmd
 	#
@@ -681,15 +693,19 @@
 debug "run_rc_command: evaluating ${_postcmd}()."
 eval $_postcmd
 			fi
+ 			echo_fancy "  OK  " 9
 			;;
 
 		stop)
+ 			echo -n "Stopping ${name}"
 			if [ -z "$rc_pid" ]; then
 [ -n "$rc_fast" ] && return 0
 if [ -n "$pidfile" ]; then
+ 	echo_fancy " SKIP " 9
 	echo 1>&2 \
 "${name} not running? (check $pidfile)."
 else
+ 	echo_fancy " SKIP " 9
 	echo 1>&2 "${name} not running?"
 fi
 return 1
@@ -702,12 +718,11 @@
 eval $_precmd
 _return=$?
 [ $_return -ne 0 

Re: [PATCH] Fancy rc startup style RFC

[Coleman Kane]

On 4/18/06, Darren Pilgrim <[EMAIL PROTECTED]> wrote:
>
> Eric Anderson wrote:
> >
> > If I could figure out how to make sh do colors, I'd do it. :)
>
> Please do not use colors in rc.  Escape-sequenced colors make unacceptable
> assumptions about the user and syslogd strips escape sequences anyway, so
> it
> would be of no use to logged consoles.  Serial consoles introduce other
> problems with buggy escape handling in third-party terminal programs.  A
> good text layout and descriptive status messages do far more for clarity
> and
> readability than any use of color ever can.


I understand your concerns regarding the "pollution" of rc messages with
excess baggage such as ANSI-color sequences and attributes. The patches have
been set up in such a way as to provide the "fancy" capability only on
demand, and the "fancy w/ color" only as another toggle. I think that having
a more defined status interface would be very beneficial (and using colors
and other attributes supported by advanced terminal types seems to be what
people would like).

For instance, right now we just have the name of the service printed if it
is started, otherwise an ugly (in my eyes) dump of its stderr is displayed
on-screen. If we instead defined an API that defined a "Service Name"
"Service Description" "Service Status" and "Error Code" then we could have a
more manageable service structure (IMHO). I think this work toward making
the service status messages prettier CAN ONLY BE GOOD. Even if "pretty
colors" are deemed "too fancy" by the freebsd gods in the end.

As for your "buggy escape handling" of third-party terminals: 1) Don't
enable the feature and it won't be a problem, or 2) Don't use crappy
third-party terminal software that will die when it recieves ^[[0;31;40m
rather than setting the attributes to NormalText-Red-on-Black. In fact, I
haven't heard of one for some time.

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC

[Coleman Kane]

On 4/18/06, Coleman Kane <[EMAIL PROTECTED]> wrote:
>
> On 4/18/06, M. Warner Losh <[EMAIL PROTECTED]> wrote:
>
> > In message: <[EMAIL PROTECTED]>
> > Eric Anderson <[EMAIL PROTECTED]> writes:
> > : Gordon Bergling wrote:
> > : > Hi,
> > : >
> > : > * Thus spake Eric Anderson ([EMAIL PROTECTED]):
> > : >> I've made a patch to /etc/rc.subr that makes the startup/shutdown
> > rc
> > : >> scripting look similar to other OS's (many different linux distros,
> >
> > : >> HP-UX, etc), but without color.
> > : >>
> > : >> The patch shouldn't break anything, and is only enabled if you have
> > this
> > : >> in your /etc/rc.conf:
> > : >>
> > : >> rc_fancy="YES"
> > : >>
> > : >> Several of the /etc/rc.d/* scripts send output to stdout, so that
> > could
> > : >> be cleaned up a bit if needed, but for now I tried to keep the
> > patch as
> > : >> minimal as possible.
> > : >>
> > : >> This is still a first pass, so please give feedback.
> > : >
> > : > A short try on my notebook shows some errors.
> > : > I don't want to let this email getting too big, so I put the "dmesg
> > -a"
> > : > output online. http://generic.0xfce3.net/dmesg-fancy.txt
> > : >
> > : > BTW, the patch applied cleanly.
> > :
> > :
> > : Thanks for the feedback!  Looks like I made an erroneous assumption
> > that
> > : the wc, expr, and printf tools found in /usr/bin and /bin would be
> > : available through boot, but that isn't the case on systems with those
> > : file systems separate from /.  I'm not sure how to resolve some of
> > these
> > : issues, since I don't know of a way to do those functions in csh
> > without
> > : them.  I'm open to suggestions here from anyone.
>
>
Also, /bin/sh is used to execute rc NOT /bin/csh. So you are writing in
Bourne shell and not C-Shell.

--
> coleman kane
>
>
>
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC

[Coleman Kane]

On 4/18/06, Coleman Kane <[EMAIL PROTECTED]> wrote:
>
> On 4/18/06, M. Warner Losh <[EMAIL PROTECTED]> wrote:
>
> > In message: <[EMAIL PROTECTED]>
> > Eric Anderson <[EMAIL PROTECTED]> writes:
> > :
> > : Thanks for the feedback!  Looks like I made an erroneous assumption
> > that
> > : the wc, expr, and printf tools found in /usr/bin and /bin would be
> > : available through boot, but that isn't the case on systems with those
> > : file systems separate from /.  I'm not sure how to resolve some of
> > these
> > : issues, since I don't know of a way to do those functions in csh
> > without
> > : them.  I'm open to suggestions here from anyone.
> >
> > /bin and /sbin are available through the entire boot.  Only things in
> > /usr are suspect because /usr gets mounted early in the boot process,
> > but not as early as /.
> >
> > Warner
>
>
> Nice work!
>
> I too noticed the dependence upon wc, printf, expr. I went ahead and
> rewrote these into equivalents in native sh. (attaching new diff).
>
> This diff is against the latest 7-CURRENT rc.subr. I had to manually merge
> 3 hunks due to some differences.
>
> --
> coleman kane
>

I did some ugly-looking loops to build the space-padding expansion. Does
anybody know of a better, more elegant way to accomplish the same thing with
sh (and/or stuff in /bin,/sbin)?


--
coleman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC

[Coleman Kane]

On 4/18/06, M. Warner Losh <[EMAIL PROTECTED]> wrote:
>
> In message: <[EMAIL PROTECTED]>
> Eric Anderson <[EMAIL PROTECTED]> writes:
> : Gordon Bergling wrote:
> : > Hi,
> : >
> : > * Thus spake Eric Anderson ([EMAIL PROTECTED]):
> : >> I've made a patch to /etc/rc.subr that makes the startup/shutdown rc
> : >> scripting look similar to other OS's (many different linux distros,
> : >> HP-UX, etc), but without color.
> : >>
> : >> The patch shouldn't break anything, and is only enabled if you have
> this
> : >> in your /etc/rc.conf:
> : >>
> : >> rc_fancy="YES"
> : >>
> : >> Several of the /etc/rc.d/* scripts send output to stdout, so that
> could
> : >> be cleaned up a bit if needed, but for now I tried to keep the patch
> as
> : >> minimal as possible.
> : >>
> : >> This is still a first pass, so please give feedback.
> : >
> : > A short try on my notebook shows some errors.
> : > I don't want to let this email getting too big, so I put the "dmesg
> -a"
> : > output online. http://generic.0xfce3.net/dmesg-fancy.txt
> : >
> : > BTW, the patch applied cleanly.
> :
> :
> : Thanks for the feedback!  Looks like I made an erroneous assumption that
> : the wc, expr, and printf tools found in /usr/bin and /bin would be
> : available through boot, but that isn't the case on systems with those
> : file systems separate from /.  I'm not sure how to resolve some of these
> : issues, since I don't know of a way to do those functions in csh without
> : them.  I'm open to suggestions here from anyone.
>
> /bin and /sbin are available through the entire boot.  Only things in
> /usr are suspect because /usr gets mounted early in the boot process,
> but not as early as /.
>
> Warner


Nice work!

I too noticed the dependence upon wc, printf, expr. I went ahead and rewrote
these into equivalents in native sh. (attaching new diff).

This diff is against the latest 7-CURRENT rc.subr. I had to manually merge 3
hunks due to some differences.

--
coleman kane
--- rc.subr.orig	Tue Apr 18 13:58:14 2006
+++ rc.subr	Tue Apr 18 13:57:36 2006
@@ -313,12 +313,16 @@
 			break
 		fi
 		_list=$_nlist
-		echo -n ${_prefix:-"Waiting for PIDS: "}$_list
+		if ! checkyesno rc_fancy; then
+			echo -n ${_prefix:-"Waiting for PIDS: "}$_list
+		fi
 		_prefix=", "
 		sleep 2
 	done
 	if [ -n "$_prefix" ]; then
-		echo "."
+		if ! checkyesno rc_fancy; then
+			echo "."
+		fi
 	fi
 }
 
@@ -564,12 +568,14 @@
 	# if the precmd failed and force
 	# isn't set, exit
 	#
+			rcargsize=`echo $rc_arg`
+			rcargsize=${#rcargsize}
 			if [ -n "$_precmd" ]; then
 debug "run_rc_command: evaluating ${_precmd}()."
 eval $_precmd $rc_extra_args
 _return=$?
 [ $_return -ne 0 ] && [ -z "$rc_force" ] &&
-return 1
+(echo_fancy "FAILED" `expr 10 + $rcargsize - 1`) && return 1
 			fi
 
 			if [ -n "$_cmd" ]; then
@@ -577,7 +583,7 @@
 eval $_cmd $rc_extra_args
 _return=$?
 [ $_return -ne 0 ] && [ -z "$rc_force" ] &&
-return 1
+(echo_fancy "FAILED" `expr 10 + $rcargsize - 1`) && return 1
 			fi
 
 			if [ -n "$_postcmd" ]; then
@@ -585,6 +591,7 @@
  eval $_postcmd $rc_extra_args
 _return=$?
 			fi
+			echo_fancy "  OK  " 0
 			return $_return
 		fi
 
@@ -600,13 +607,16 @@
 			;;
 
 		start)
+ 			echo -n "Starting ${name}"
 			if [ -z "$rc_fast" -a -n "$rc_pid" ]; then
+ echo_fancy " SKIP " 9
 echo 1>&2 "${name} already running? (pid=$rc_pid)."
 return 1
 			fi
 
 			if [ ! -x ${_chroot}${command} ]; then
 info "run_rc_command: cannot run ($command)."
+ echo_fancy "ERROR " 9
 return 1
 			fi
 
@@ -617,6 +627,7 @@
 if ! checkyesno $_f; then
 	warn "\$${_f} is not enabled."
 	if [ -z "$rc_force" ]; then
+		echo_fancy "ERROR " 9
 		return 1
 	fi
 fi
@@ -625,6 +636,7 @@
 if [ ! -d "${_f}/." ]; then
 	warn "${_f} is not a directory."
 	if [ -z "$rc_force" ]; then
+		echo_fancy "ERROR " 9
 		return 1
 	fi
 fi
@@ -633,6 +645,7 @@
 if [ ! -r "${_f}" ]; then
 	warn "${_f} is not readable."
 	if [ -z "$rc_force" ]; then
+		echo_fancy "ERROR " 9
 		return 1
 	fi
 fi
@@ -646,12 +659,11 @@
 eval $_precmd
 _return=$?
 [ $_return -ne 0 ] && [ -z "$rc_force" ] &

Re: Fw: Priority Increasing

[Coleman Kane]

On Sun, 27 Feb 2005 20:56:03 -0800, Ashwin Chandra <[EMAIL PROTECTED]> wrote:
> The forkbomb program I wrote is just one parent that forks 750 or so
>  children that each malloc around 40 MB's of memory and do a mem traversal
>  through it. The children do not fork. I see the overhead of forking could
> be
>  causing this, but shouldn't there be some difference in the load of the
>  system when each forkbomb process is set to the lowest priority? To fork
> 750
>  processes would incur overhead until those processes are created (Which
>  shouldnt take much of real time) and once they are running, if they other
>  processes that have already been created are running "nicely", I don't see
>  why there is so much overhead too.
> 

You are talking about malloc'ing almost 30GB of memory and having 750
readers paw through it to search for something. That is a lot of
swap-backed memory. You are probably experiencing swap thrashing from
all of this memory access/usage. Might I ask why this needs to be done
750 times in parallel? If you are trying to be efficient, try only
forking off readers for each CPU, and waiting until they finish before
you start anew. You also won't be swapping so much information to
disk, which will make your program run alot faster than the method you
are using.

That is, of course, unless you actually do have > 30GB RAM. In that
case, I am way off, but you may want to reduce the number of procs
anyhow.

>  Do you recommend anotoher way to solve this forkbomb problem and keep the
>  system DoS free for others?
>  Ash
> 

Also, this isn't really a forkbomb, as you seem to have a limit
instituted on the number of forks. In a traditional fork-bomb, the
forkers fork themselves, and so on, and so on, 

--
coleman kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Priority Increasing

[Coleman Kane]

Well, since the program is running a forkbomb, it is gonna stress out
the kernel. The kernel is constantly creating new process spaces, as
well as filling in the queue.

Are we talking a O(2^n) forkbomb here (where the forks also fork)?
Remember, there is overhead associated with forking off new processes,
and if your program is doing it continuously, nicing them is not going
to fix the problem. I suggest you fix the program so that it doesn't
forkbomb.

You can also rlimit it, and force the number of processes to a
specific ceiling. This will result in crashing the program everytime
you hit that limit, however. Try looking into djb's daemontools if you
want to duct-tape it (ports/sysutils/daemontools)

--
coleman

On Sun, 27 Feb 2005 18:11:57 -0800, Ashwin Chandra <[EMAIL PROTECTED]> wrote:
> Hi all,
> Ive been trying to counter the malicious effects of a forkbomb by setting the 
> forkbomb parent and children to a PRI_MAX priority, although this is not 
> having any effect on the system load.
> 
> Basically in my code when I know which process is acting maliciously 
> (forkbomb), I run the following simple code:
> 
>   FOREACH_KSEGRP_IN_PROC(p, kg)
> {
>   printf("old prio:%d", kg->kg_user_pri);
>   kg->kg_user_pri = PRI_MAX;
>   printf(" new prio:%d", kg->kg_user_pri);
> }
> 
> When it prints out, the old prio was 180 and the new gets set to 255 although 
> there is help to the system...the system is still under stress. Do you guys 
> know any good ways of hacking the scheduler to make a process that is bad run 
> MUCH MUCH less as to not overload the system?
> 
> Ash
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: pthreads & dynamic memory in fbsd vs. the same in linux

[Coleman Kane]

Could you post the code too, perchance?


On Thu, 10 Feb 2005 10:55:04 +0200, Andriy Tkachuk <[EMAIL PROTECTED]> wrote:
> Hi folks.
> 
> I noticed the strange stick of pthreads (amount ~ 500)
> when allocating dynamic memory by malloc or new
> in my system:
> 
> > uname -a
> FreeBSD ant.emict.com 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed Feb  9 17:30:11 
> EET 2005 [EMAIL PROTECTED]:/lin/fbsd_obj/usr/src/sys/ANT  i386
> 
> It's interesting that the same program behaves differently
> when it is compiled in linux and run on my fbsd machine in
> linux_base-7.1_7 .
> 
> > ldd test2-linux
> test2-linux:
> libpthread.so.0 => /lib/libpthread.so.0 (0x28065000)
> libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 
> (0x2807c000)
> libm.so.6 => /lib/libm.so.6 (0x280bf000)
> libc.so.6 => /lib/libc.so.6 (0x280e1000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2804c000)
> > ldd a.out
> a.out:
> libpthread.so.1 => /usr/lib/libpthread.so.1 (0x28075000)
> libstdc++.so.4 => /usr/lib/libstdc++.so.4 (0x28099000)
> libm.so.3 => /lib/libm.so.3 (0x2816b000)
> libc.so.5 => /lib/libc.so.5 (0x28184000)
> 
> Each thread allocates the amount of memory by 10 bytes in loop.
> The number of iterations is specified in cmdline arg. The program
> prints the time each thread is spent allocating memory in loop.
> Let's look on results.
> 
> > ./a.out n 1000  # 1000 iterations of new operator. Every new allocates 
> > 10bytes.
> thread 0 created
> thread 1 created
> thread 2 created
> thread 3 created
> thread 4 created
> ...
> thread 497 created
> thread 498 created
> thread 499 created
> 0.001114
> 0.001022
> 0.001021
> 0.001011
> 0.001014
> 0.001010
> 0.001013
> 0.001050
> 0.001035
> 0.001011
> 0.001013
> 0.001010
> 0.001013
> 0.001010
> 0.001029
> 0.001075
> 0.001053
> 0.001011
> 0.001014
> 0.001011
> 0.001030
> 0.001010
> 0.001015
> 0.001042
> 0.001019
> 0.001011
> 0.001014
> 0.001012
> 0.001013
> 0.001010
> 0.001014
> 0.361604
> 3.225090
> 3.225458
> 3.225696
> 3.225925
> 3.226152
> 3.226380
> 3.226608
> 3.226833
> 3.227062
> 3.227290
> 3.227517
> 3.227744
> 3.227972
> 3.228202
> 3.228451
> 3.228681
> 3.228912
> 3.229140
> 3.229367
> 
> The same, but in linux_base-7.1_7 :
> 
> > ./test2-linux n 1000
> thread 0 created
> thread 1 created
> ...
> thread 498 created
> thread 499 created
> 0.000467
> 0.000403
> 0.000402
> ...
> 0.000391
> 0.000391
> 0.000395
> ...
> 0.000395
> 0.010564
> 0.000398
> 0.000394
> 
> The program source is attached.
> 
> In linux program is compiled by
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)
> 
> in fbsd:
> > gcc -v
> Using built-in specs.
> Configured with: FreeBSD/i386 system compiler
> Thread model: posix
> gcc version 3.4.2 [FreeBSD] 20040728
> 
> 
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 
> 
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: OpenBSD's netcat in base or ports?

[Coleman Kane]

I agree. I think even tcpdump, libpcap, and ssl stuff should be in
ports. Currently these are in the src/contrib tree. I know they
currently have utility there for the base system. We moved the base
away from perl dependence, I think these dependencies should be worked
out as well. I really dislike -stable and -release
having out-of-date versions of these packages.

This is only my personal opinion. I think the WITH__OVERWITE_BASE
make options help substantiate it, however.


On Tue, 25 Jan 2005 09:38:52 -0800, Avleen Vig
<[EMAIL PROTECTED]> wrote:
> On Tue, Jan 25, 2005 at 09:24:57PM +0800, Kang Liu wrote:
> > Delphij,
> >   I think the base should be as *clean* as possible, it might be
> > better if we put nc into ports. :P
> 
> I agree. base should be minimal, everythign optional (eg 'perl' :P)
> should be in ports. There people can choose the versions (eg 5.6 or
> 5.8), where to install them, etc etc.
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: pthread_mutex_trylock and glib-2

[Coleman Kane]

Yeah, I had the same problem. Fixed it by not building with debug
code, but I noticed there was chatter about it.


On Wed, 8 Sep 2004 18:57:09 -0400, Brian Fundakowski Feldman
<[EMAIL PROTECTED]> wrote:
> 
> 
> On Tue, Sep 07, 2004 at 06:27:14PM -0700, Pascal Hofstee wrote:
> > On Mon, 6 Sep 2004 15:12:08 -0700, Pascal Hofstee <[EMAIL PROTECTED]> wrote:
> > > After a few hours of digging through both the glib-2 as well as the
> > > beep-media-player sources i finally managed to figure out why
> > > beep-media-player apprently crashes on startup when using libpthread,
> > > but not when using libc_r.
> > >
> > > i filed a bugreport against this problem on bugzilla.gnome.org ... in
> > > the hope to get some feedback from glib-developers ...
> > >
> > > http://bugzilla.gnome.org/show_bug.cgi?id=152009
> > >
> > > The problem is with the actual return value of pthread_mutex_trylock
> > > returning EDEADLK instead of EBUSY.
> > >
> > > from what i have been able to glance from this previous discussion
> > > regarding this particular subject
> > > (http://lists.freebsd.org/pipermail/freebsd-threads/2004-January/001539.html)
> > >
> > > pthread_mutex_trylock should behave identical to pthread_mutex_lock
> > > except return immediately in case of a blocking mutex, which would
> > > suggest EDEADLK as a possible return value.
> > >
> > > This Seems to be the current implementation of both libpthread as well
> > > as libthr ... with libc_r being the sole exception.
> > >
> > > The pthread_mutex_trylock manpage however does not reflect this actual
> > > implementation and only mentions EBUSY and EINVAL.
> > >
> > > I was wondering assuming the implementation is actually correct if
> > > this could be rectified in the pthread_mutex_trylock manpage ... and
> > > if my assumption is wrong if the implementation could be changed to
> > > reflect the manpage.
> > >
> > > In the former case i will have to bug the glib-devs to change the
> > > implementation of their pthread_mutex_trylock wrapper ... to also
> > > check for EDEADLK.
> >
> > I am hereby including an updated
> > /usr/ports/devel/glib20/files/patch-gthread_gthread-posix.c
> >
> > that includes the additional check for EDEADLK besides EBUSY in glib's
> > g_mutex_trylock_posix_impl function.
> >
> > With this fix applied to my installation of glib beep-media-player now
> > works as expected with libpthread, and this is very likely to resolve
> > similar behaviour with other ports that try to use glib's threading
> > functions.
> >
> > I CC-ed glib20 port-maintainer ([EMAIL PROTECTED]) in the hope this
> > (or appropriate alternative) fix makes it in time for 5.3-RELEASE.
> 
> FWIW, I had to fix a similar problem in mozilla/NSPR's codebase to make
> the build with debugging code turned on work.  Well, I guess it was really
> the same problem.
> 
> --
> Brian Fundakowski Feldman   \'[ FreeBSD ]''\
>   <> [EMAIL PROTECTED]   \  The Power to Serve! \
>  Opinions expressed are my own.   \,,\
> 
> 
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Network interface RUNNING and UP flags

[Coleman Kane]

That patch seems to have fixed it. It seemed strange that setting an
inet address to the interface set it running, however setting the inet6
does not do this. It is possible this behavior affacts other interface
types as well?

On Fri, 2004-08-06 at 18:07, Maksim Yevmenkin wrote:
> > 2) Is there a way to set this interface flag without assigning an IPv4
> > address (or any address for that matter) first?
> > 
> > Mainly for number two, I would like to be able to run interfaces
> > bridged together without having to also give all of them addresses.
> 
> please try the attached (untested!) patch. it should set iff_running 
> flag on the interface as soon as the control device is opened.
> 
> max
> 
> __
> --- if_tap.c.orig Fri Aug  6 15:02:06 2004
> +++ if_tap.c  Fri Aug  6 15:04:14 2004
> @@ -336,15 +336,15 @@
>  tapopen(dev, flag, mode, td)
>   struct cdev *dev;
>   int  flag;
>   int  mode;
>   struct thread   *td;
>  {
>   struct tap_softc*tp = NULL;
> - int  error;
> + int  error, s;
>  
>   if ((error = suser(td)) != 0)
>   return (error);
>  
>   if ((dev2unit(dev) & CLONE_UNITMASK) > TAPMAXUNIT)
>   return (ENXIO);
>  
> @@ -365,14 +365,19 @@
>   return (EBUSY);
>   }
>  
>   bcopy(tp->arpcom.ac_enaddr, tp->ether_addr, sizeof(tp->ether_addr));
>   tp->tap_pid = td->td_proc->p_pid;
>   tp->tap_flags |= TAP_OPEN;
>   mtx_unlock(&tp->tap_mtx);
> +
> + s = splimp();
> + tp->tap_if.if_flags |= IFF_RUNNING;
> + tp->tap_if.if_flags &= ~IFF_OACTIVE;
> + splx(s);
>  
>   TAPDEBUG("%s is open. minor = %#x\n", 
>   tp->tap_if.if_xname, minor(dev));
>  
>   return (0);
>  } /* tapopen */
>  

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Network interface RUNNING and UP flags

[Coleman Kane]

Hi, I have been having some trouble working with getting tapN network
interfaces into the 'RUNNING' state. I have been trying to figure out
how to set the RUNNING flag on an interface, which is needed before
the kernel will actually begin sending packets from said network
interface. So far, the only way I have been able to figure out how to
do this is to assign an IPv4 address to the interface, I am guessing
that an un-addressed network interface is supposed to remain not
RUNNING even if it is UP by design. The problem is that only an IPv4
address assignment will bring it up and running. If I attempt to
assign an IPv6 address to the interface, it will go UP, but not
RUNNING. I have determined that I can assign an IPv4 address (such as
10.0.0.1) to it, and then subsequently remove it (via -alias) and this
will leave the interface in the running state.

My questions are:

1) Why doesn't assigning an IPv6 address produce the same side effects
and
2) Is there a way to set this interface flag without assigning an IPv4
address (or any address for that matter) first?

Mainly for number two, I would like to be able to run interfaces
bridged together without having to also give all of them addresses.

--
thanks,
coleman kane
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Proper code style regarding hexadecimal case

[Coleman Kane]

Typically, I have used the lowercase formatting. Much of the code I
work with has gone for the lowercase format as well. Typically setting
something to 0x reads like yelling and stands out in the
source, since keywords are all lowercase and most var/function names
are as well. As an aside, the #define macros usually stand out as all
of them are all-caps. I would suggest using the lowercase format.

On Sat, 31 Jul 2004 10:43:45 -0700, Vlad902 <[EMAIL PROTECTED]> wrote:
> What is the proper code style regarding hexadecimal case (ie. 0xabc v.
> 0xABC)? I have found code to be a mix of mostly lower and upper case,
> and style(9) didn't say anything on the subject.
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Minor weirdness in pci/agp_amd.c.

[Coleman Kane]

-STABLE has been (as of late last week) brought up to speed as far as this 
fix goes. The earlier driver (shipped with 4.5) had this little oddity in 
it, but it was removed when the driver got re-written. It has been fixed, 
so there really is no problem.

--
coleman

On Mon, Apr 15, 2002 at 10:48:05AM -0400, Joe O wrote:
> 
> This is probably the agp_amd.c driver from stable.  It never got patched
> up with the irongate fix that went into current.
> 
> Look ether into agp_amd.c in current or look through PR database on the
> the main freebsd website.
> 
> 
> On Mon, 15 Apr 2002, Coleman Kane wrote:
> 
> > Is this in the -STABLE or -CURRENT version? I've been working on getting this
> > driver working, mostly from outside patches.
> >
> > --
> > coleman
> >
> > On Sun, Apr 14, 2002 at 04:57:17PM -0700, Frank Mayhar wrote:
> > > I'm working on writing a driver for the ServerWorks AGP support from the
> > > Linux driver (sans documentation, SIGH :-().  I've been using the various
> > > other drivers as models, particularly the AMD driver, since it seems to be
> > > closest in many ways to the ServerWorks architecture.
> > >
> > > Anyway, I've run into a minor oddity in agp_amd_alloc_gatt(), in pci/agp_amd.c.
> > > At lines 120-121:
> > > gatt->ag_pdir = vtophys((vm_offset_t) gatt->ag_vdir);
> > > gatt->ag_pdir = vtophys(gatt->ag_virtual);
> > >
> > > Looks like one or the other is redundant?  Probably the first, I would guess,
> > > if the code actually works as it is.
> > > --
> > > Frank Mayhar [EMAIL PROTECTED]   http://www.exit.com/
> > > Exit Consulting http://www.gpsclock.com/
> > >
> > > 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
> >
> 
> 
> 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: Minor weirdness in pci/agp_amd.c.

[Coleman Kane]

This was the case in older revisions, it has been fixed in RELENG_4 and
-CURRENT. The driver shipped with 4.5-RELEASE was broken.

--
coleman

On Sun, Apr 14, 2002 at 04:57:17PM -0700, Frank Mayhar wrote:
> I'm working on writing a driver for the ServerWorks AGP support from the
> Linux driver (sans documentation, SIGH :-().  I've been using the various
> other drivers as models, particularly the AMD driver, since it seems to be
> closest in many ways to the ServerWorks architecture.
> 
> Anyway, I've run into a minor oddity in agp_amd_alloc_gatt(), in pci/agp_amd.c.
> At lines 120-121:
> gatt->ag_pdir = vtophys((vm_offset_t) gatt->ag_vdir);
> gatt->ag_pdir = vtophys(gatt->ag_virtual);
> 
> Looks like one or the other is redundant?  Probably the first, I would guess,
> if the code actually works as it is.
> -- 
> Frank Mayhar [EMAIL PROTECTED]   http://www.exit.com/
> Exit Consulting http://www.gpsclock.com/
> 
> 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: Minor weirdness in pci/agp_amd.c.

[Coleman Kane]

Is this in the -STABLE or -CURRENT version? I've been working on getting this
driver working, mostly from outside patches.

--
coleman

On Sun, Apr 14, 2002 at 04:57:17PM -0700, Frank Mayhar wrote:
> I'm working on writing a driver for the ServerWorks AGP support from the
> Linux driver (sans documentation, SIGH :-().  I've been using the various
> other drivers as models, particularly the AMD driver, since it seems to be
> closest in many ways to the ServerWorks architecture.
> 
> Anyway, I've run into a minor oddity in agp_amd_alloc_gatt(), in pci/agp_amd.c.
> At lines 120-121:
> gatt->ag_pdir = vtophys((vm_offset_t) gatt->ag_vdir);
> gatt->ag_pdir = vtophys(gatt->ag_virtual);
> 
> Looks like one or the other is redundant?  Probably the first, I would guess,
> if the code actually works as it is.
> -- 
> Frank Mayhar [EMAIL PROTECTED]   http://www.exit.com/
> Exit Consulting http://www.gpsclock.com/
> 
> 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: FreeBSD Advanced tuning advice

[Coleman Kane]

The CPUTYPE variable in make.conf handles this, look at 
src/share/mk/bsd.cpu.mk.

--
coleman

On Thu, Apr 11, 2002 at 11:05:38AM -0400, Michael Lucas wrote:
> On Thu, Apr 11, 2002 at 05:04:23PM +0300, Peter Pentchev wrote:
> > 
> > Erm.. gcc has quite a lot more flags than the -On optimizations :)
> > There are things like -march, -mcpu, -fomit-frame-pointer, -funroll-loops
> > and others.. unfortunately, I am not the best person to ask about those :)
> > 
> 
> Yes, but every time I've seen those brought up, the high-level hackers
> here say "Don't do that."  :)
> 
> If we could get a definitive answer on acceptable flags, I'll put it
> in the FAQ.
> 
> 
> 
> 
> -- 
> Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED]
> http://www.oreillynet.com/pub/q/Big_Scary_Daemons
> 
>Absolute BSD:   http://www.nostarch.com/abs_bsd.htm
> 
> 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: Junior Kernel Task: syscons screensavers

[Coleman Kane]

Or maybe make it only come out of screensaver if there is a console
message (i.e.: kernel messages, etc...), but stay there during tty
activity.

--
coleman

On Fri, Apr 05, 2002 at 12:18:28AM -0800, Alfred Perlstein wrote:
> Can someone (for the love of god) make it an option for the
> syscons screen savers to turn on when there's no keyboard
> activity but there is actual output on the screen?
> 
> Basically, I'd like to be able to run top(1) but still have
> my screen blank if i don't touch any keys after 5 minutes.
> 
> thanks,
> -- 
> -Alfred Perlstein [[EMAIL PROTECTED]]
> 'Instead of asking why a piece of software is using "1970s technology,"
>  start asking why software is ignoring 30 years of accumulated wisdom.'
> Tax deductible donations for FreeBSD: http://www.freebsdfoundation.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: Status of agpgart device

[Coleman Kane]

For the i440BX, it should be fully operational and work just exactly like
the linux counterpart. You shouldn't need the agpgart tarball, it sohuld 
work (but only in XFree86 3.3.6). XFree86 4.x uses DRI exclusively. If
you want to use that, you should visit dri.sourceforge.net.

On Fri, Jul 20, 2001 at 01:26:03AM -0700, Farooq Mela wrote, and it was proclaimed:
> Hi,
> 
> Right, I've already got that:
> 
> agp0:  mem
> 0xf800-0xfbff at device 0.0 on pci0
> 
> That still doesnt answer my question about the agpgart (AGP
> g-something address resolution table, or something similar - needed
> for high-performance memory transfers).
> 
> -- Coleman Kane wrote:
> > 
> > 4.3-RELEASE comes with an agp device. Simply add agp_load="YES" to your
> > /boot/loader.conf file, or device agp to your kernel config file. It
> > only supports certain AGP bridges though, look in /usr/src/sys/pci/agp*
> > for more info.
> > 
> > On Thu, Jul 19, 2001 at 04:48:00PM -0700, Farooq Mela wrote, and it was proclaimed:
> > > Hi hackers@,
> > >
> > > What is the status of the /dev/agpgart device? (I'm running 4.3-STABLE
> > > with a recent cvsup).  Is it working, perhaps using a compatible
> > > interface with the linux device the of the same name (I can dream
> > > can't I ;-) ?  I ask because I recently tried compiling Utah-GLX with
> > > AGP acceleration support, and it requires a /dev/agpgart device, but
> > > the testgart program errors out when it tries to ioctl the agpgart
> > > device.
> > >
> > > The Utah-GLX website all provides a tarball
> > > (http://utah-glx.sourceforge.net/gart/agpgart-freebsd-2619.tar.gz)
> > > which includes a FreeBSD agpgart driver (as a KLD), but it fails to
> > > compile.  I believe it was for the FreeBSD 3.x series, and has tons of
> > > compile errors.  The documentation for the driver also states the as
> > > part of the installation, a /dev/agpgart must be built, yet I already
> > > had a /dev/agpgart device.  This leads me to believe this driver is a
> > > bit antiquated.
> > >
> > > Any ideas?
> > >
> > > --
> > > farooq <[EMAIL PROTECTED]>
> > >
> > > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > > with "unsubscribe freebsd-hackers" in the body of the message
> > >
> > 
> >   --
> >Part 1.2Type: application/pgp-signature
> 
> farooq <[EMAIL PROTECTED]>
> 

 PGP signature

Re: Status of agpgart device

[Coleman Kane]

4.3-RELEASE comes with an agp device. Simply add agp_load="YES" to your
/boot/loader.conf file, or device agp to your kernel config file. It 
only supports certain AGP bridges though, look in /usr/src/sys/pci/agp*
for more info.

On Thu, Jul 19, 2001 at 04:48:00PM -0700, Farooq Mela wrote, and it was proclaimed:
> Hi hackers@,
> 
> What is the status of the /dev/agpgart device? (I'm running 4.3-STABLE
> with a recent cvsup).  Is it working, perhaps using a compatible
> interface with the linux device the of the same name (I can dream
> can't I ;-) ?  I ask because I recently tried compiling Utah-GLX with
> AGP acceleration support, and it requires a /dev/agpgart device, but
> the testgart program errors out when it tries to ioctl the agpgart
> device.
> 
> The Utah-GLX website all provides a tarball
> (http://utah-glx.sourceforge.net/gart/agpgart-freebsd-2619.tar.gz)
> which includes a FreeBSD agpgart driver (as a KLD), but it fails to
> compile.  I believe it was for the FreeBSD 3.x series, and has tons of
> compile errors.  The documentation for the driver also states the as
> part of the installation, a /dev/agpgart must be built, yet I already
> had a /dev/agpgart device.  This leads me to believe this driver is a
> bit antiquated.
> 
> Any ideas?
> 
> -- 
> farooq <[EMAIL PROTECTED]>
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 PGP signature

Re: ATAPI support

[Coleman Kane]

On Thu, Jul 12, 2001 at 11:25:22AM -0700, Mike Smith wrote, and it was proclaimed:
> > > We support ATAPI devices and has been for a long time (also CD burners)...
> > 
> > I believe I forgot to do a group reply on my previous reply
> > to Søren.
> > 
> > OK, it seems a misunderstanding of the term ATAPI.
> > The author of cdrecord, Joerg Schilling, told me - I will translate:
> > 
> > Citation:
> > 
> > "You havn't understood what ATAPI is!
> 
> Schilly has some funny ideas about what ATAPI is as well.
> 
> > ATAPI *is* SCSI over IDE transport. Thus a SCSI system has to have
> > a hostadapter driver for the IDE bus.
> 
> There's no "has to" about it.  And this isn't entirely correct either; 
> one needs to read the relevant SFF802x specifications, particularly the 
> parts where they state their intention to deviate further from SCSI in 
> the future.
> 

>From what I have gathered from reading tech docs, etc... ATAPI is the ATA
Packet Interface. SCSI is also a packet-based interface. The original 
creators of ATAPI created it by using common commands and software 
interfaces that SCSI used already, basically to simplify things. The ATAPI
specification was never a complete implementation of SCSI over ATA. It was
rather a seperate packet interface that had a few common features that SCSI
did. Basically, the SCSI<->ATA drivers simply create a "false" scsi bus that
takes its device channels as the number of ATAPI devices it connects to.

> > *All* OSs despite FreeBSD do that right. Under Linux unfortunately
> > it isn't the default."
> 
> He's entitled to his opinion; don't mistake it for fact.
> 

I used to be a supporter of the SCSI-over-ATA implementation until I did some
reading and realized that it would present problems. Hopefully, rather than
trying to create this false SCSI-bus, and using the CAM layer, these software
programs will start to use the devices and ioctls, or other interface libs to
write CDs.

> -- 
> ... every activity meets with opposition, everyone who acts has his
> rivals and unfortunately opponents also.  But not because people want
> to be opponents, rather because the tasks and relationships force
> people to take different points of view.  [Dr. Fritz Todt]
>V I C T O R Y   N O T   V E N G E A N C E
> 
> 
> 
> 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: Idea about modules build

[Coleman Kane]

It would also be nice to be able to update third-party modules (like those in
ports, x11, etc...) after a kernel recompile. Perhaps some way of setting these
up into /usr/local?

Peter Pentchev had the audacity to say:
> 
> On Sat, Apr 14, 2001 at 07:51:31PM +0400, Vladimir B. Grebenschikov wrote:
> > 
> > I have idea about modules build/install process:
> > 
> >   May be it need to create some makefile variable like KERNEL_MODULES,
> > that can be defined in /etc/make.conf to limit list of modules
> > to build/install, it is not very good idea to spend a lot of
> > CPU time building modules, that never be used ?
> 
> This was recently discussed on -arch, and was brought into -current
> by Warner Losch <[EMAIL PROTECTED]> in rev. 1.172 of src/sys/modules/Makefile
> from 2001/04/02 08:52:05; if there is a MODULES_OVERRIDE variable (defined
> either in /etc/make.conf or on the 'make' command line), it overrides
> the list of modules to build.  This variable can - and probably should ;) -
> contain second-level module names, too - e.g. sound/pcm or syscons/daemon.
> 
> G'luck,
> Peter
> 
> -- 
> This sentence would be seven words long if it were six words shorter.
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 PGP signature

Re: Writing to a file in the kernel

[Coleman Kane]

Yeah. And you can prefix the messages with DEBUG: or some shit and use
grep to parse them out.

Drew Eckhardt had the audacity to say:
> 
> In message <002d01c0b924$a07d2090$8d7d1f26@dhgfhcpps5nhe1>, [EMAIL PROTECTED] w
> rites:
> >The problem is that printf's scroll off the screen. How can I write to a
> >file?
> 
> syslogd(8)/syslog.conf(5).
> 
> Also note that by default, on must unices the stock /etc/syslog.conf sends 
> kernel messages to /var/log/messages (along with everything else).
> 
> YMMV.
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 PGP signature

Re: wd & ata

[Coleman Kane]

Oh. Sorry. I thought that applied across the ata driver, my bad.

Daniel O'Connor had the audacity to say:
> 
> On 30-Mar-2001 Coleman Kane wrote:
> >  There is an ENABLE_ATAPI_DMA or something to that effect in the kernel config
> >  you must set. Read /usr/src/sys/i386/conf/LINT for more info. You may also man
> >  ata.
> 
> That only affects ATAPI devices (ie not hard drives).
> 
> You can enable write caching and tagged queuing (see LINT) too.
> 
> ---
> Daniel O'Connor software and network engineer
> for Genesis Software - http://www.gsoft.com.au
> "The nice thing about standards is that there
> are so many of them to choose from."
>   -- Andrew Tanenbaum
> 

 PGP signature

Re: what's the number behind the driver?

[Coleman Kane]

Some are legacy drivers that need space configured in the kernel for them.
Others are newer PCI devices that can auto-attach. This stuff is being
phased-out in -current.

BSD Blood had the audacity to say:
> 
> Hello.
>While configuring my kernel configuration file, I notice that certain 
> entries have numbers after the driver and some don't. For example: -
> 
> device  psm0
> device  da
> 
> My questions are:-
> 1. What's the number behind the driver?
> 
> 2. Why for some entries there are no numbers?
> _
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 PGP signature

Re: wd & ata

[Coleman Kane]

There is an ENABLE_ATAPI_DMA or something to that effect in the kernel config
you must set. Read /usr/src/sys/i386/conf/LINT for more info. You may also man
ata.

BSD Blood had the audacity to say:
> 
> Hello.
>I'm using FreeBSD 4.1. My kernel contains the ata driver for the IDE 
> controllers. I understand that the ata driver has replaced the wd driver. My 
> question is:-
> 
> 1. Are there any / Do I need to use certain flags to enable LBA, DMA, etc. 
> features like for the wd driver? Or is this done automatically by the ata 
> driver?
> _
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 PGP signature

Re: Porting a Linux driver to FreeBSD with ioctl return values

[Coleman Kane]

Yeah, figured that one out too. bleh.

Dennis had the audacity to say:
> 
> oh, also, they MUST be negative. so you return (-ENODEV)...some bad upper 
> layer code they decided to never fix.
> 
> DB
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 PGP signature

Re: Porting a Linux driver to FreeBSD with ioctl return values

[Coleman Kane]

Yeah, that's the basic gist of things I got from talking with people
as well. I suppose the feeling is that if it works and doessn't seem
to cause any harm it should be a 'feature'. Personally, I never liked
the idea of having ioctl's return like that. Something about it seemed
unclean and dirty...

Devin Butterfield had the audacity to say:
> On Monday 26 March 2001 11:24, Alfred Perlstein wrote:
> > * Coleman Kane <[EMAIL PROTECTED]> [010326 22:40] wrote:
> > > Yeah, that's basically what I had to do in tdfx. You can take a look int
> > > src/sys/dev/tdfx/tdfx_pci.c under tdfx_ioctl(...) to get an idea of what
> > > needs to be done, if you need more info. Tdfx basically implements the
> > > API from device_3dfx in Linux.
> >
> > Is there anyone we can PLEAD with to explain that to the linnux people
> > that that's a broken way to implement ioctl()?
> 
> I did the original port of the linux telephony driver that Roger Hardiman has 
> been kind enough to volunteer taking up maintainership of, and I butted heads 
> with this problem (and the people who were perpetuating it) I can assure you. 
> The author of the linux driver agreed that it wasn't the right way to do it, 
> and I managed to convince him that it needed to be changed, but Alan Cox 
> refused to accept any changes to the linux telephony API (regardless of the 
> fact that it was "broken"). The fear was that it would break existing 
> applications which depended on this ioctl hack. And so the breakage is 
> perpetuated, on and on...
> --
> Regards, Devin.
> 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Porting a Linux driver to FreeBSD with ioctl return values

[Coleman Kane]

Yeah, that's basically what I had to do in tdfx. You can take a look int
src/sys/dev/tdfx/tdfx_pci.c under tdfx_ioctl(...) to get an idea of what
needs to be done, if you need more info. Tdfx basically implements the
API from device_3dfx in Linux.

Alfred Perlstein had the audacity to say:
> 
> * Roger Hardiman <[EMAIL PROTECTED]> [010326 05:37] wrote:
> > Hi,
> > I'm porting the some linux telephony API drivers over
> > to FreeBSD.
> > 
> > But the author of the linux driver used the 'hack' of
> > returning values from the ioctls as the error result.
> > 
> > egvolume = ioctl (fd, IXJ_GET_VOLUME)
> > 
> > instead of using
> >   error = ioctl (fd, IXJ_GET_VOLUME, &volume);
> > 
> > 
> > Naturally I want to keep the API the same on FreeBSD
> > so existing apps will compile without change.
> > But right now it looks like I cannot do this.
> > 
> > Is there anything I can do in the FreeBSD driver
> > or in existing source to help, without imposing
> > a new 'BSD' API.
> 
> I just woke up er, try this:
> 
> p->p_retval[0] = your_return_value;
> 
> in your ioctl code... or are you saying that the ioctl code
> spams over it?
> 
> -- 
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> Represent yourself, show up at BABUG http://www.babug.org/
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 PGP signature

Re: Machines are getting too damn fast

[Coleman Kane]

I believe DDR still has it bead (PC2100 that is), Rambus serailizes all writes
to 32 bit or 16 bit (an even 8 bit) depending on the modules. I haven't seen any
64bit RIMMs. Also, DDR scales higher (up to 333Mhz I think). Just wait for
that. I've pretty much given up on RamBus, I saw back in '96 when they talked
about how great it would be. I thought it was crap back then. The idea is that
it can queue 28 mem ops, where SDRAM can only do like 4. Typical environments
typically don't do the writes that it looks good on, jsut certain special cases.
That's where you get into the fact that RamBus sucks for use in PCs. Too
specialized. Too proprietary.

Matt Dillon had the audacity to say:
> 
> 
> :You should see what speed RamBus they were using, 600 or 800 Mhz. It is
> :pretty fast for large memory writes and reads. It'd be cool to see how
> :the different speeds stack up against one another. DDR comparisons would
> :be cool too. Yeah, for the frequency, you have to take into account that
> :these are different chips than your PIII or Athlons and the performance
> :difference is not simply a linear relation to the frequency rating
> :(i.e.: 1.3Ghz is not really over one-billion instructions per second,
> :just clocks per second). We installed Linux at a UC Free OS User Group
> :installfest here in cincinnati, it was pretty sweet. The machine was a
> :Dell and the case was freakin' huge. It also came with a 21" monitor and
> :stuff. The performace was really good, but not really any better than I
> :hads gleaned from the newer 1Ghz Athlons or PIII's.
> 
> It says 800 MHz (PC-800 RIMMs) on the side of the box.
> 
> The technical reviews basically say that bulk transfer rates for
> RamBus blow DDR away, but DDR wins for random reads and writes
> due to RamBus's higher startup latency.  I don't have any DDR
> systems to test but I can devise a test program.
> 
> Celeron 650 MHz (HP desktop) (DIMM)
>   16.16 MBytes/sec (copy)
> 
> Pentium III 550 MHz (Dell 2400) (DIMM)
>   25.90 MBytes/sec (copy)
> 
> Pentium 4 1.3 GHz / PC-800 RIMMs (Sony VAIO)
>   32.38 MBytes/sec (copy)
> 
> 
>   -Matt
> 
> Compile -O2, changing the two occurances of '512' to '4' will reproduce
> the original bulk-transfer rates.  By default this program tests 
> single-transfer (always cache miss).
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #define NLOOP 100
> 
> char Buf1[2 * 1024 * 1024];
> char Buf2[2 * 1024 * 1024];
> 
> int deltausecs(struct timeval *tv1, struct timeval *tv2);
> 
> int
> main(int ac, char **av)
> {
> int i;
> double dtime;
> struct timeval tv1;
> struct timeval tv2;
> 
> memset(Buf1, 1, sizeof(Buf1));
> for (i = 0; i < 10; ++i)
>   bcopy(Buf1, Buf2, sizeof(Buf1));
> 
> gettimeofday(&tv1, NULL);
> for (i = 0; i < NLOOP; ++i) {
>   int j;
>   int k;
>   for (k = sizeof(int); k <= 512; k += sizeof(int)) {
>   for (j = sizeof(Buf1) - k; j >= 0; j -= 512)
>   *(int *)(Buf2 + j) = *(int *)(Buf1 + j);
>   }
> }
> gettimeofday(&tv2, NULL);
> 
> dtime = (double)deltausecs(&tv1, &tv2);
> printf("%6.2f MBytes/sec (copy)\n", (double)sizeof(Buf1) * NLOOP / dtime);
> return(0);
> }
> 
> int
> deltausecs(struct timeval *tv1, struct timeval *tv2)
> {
> int usec;
> 
> usec = (tv2->tv_usec + 100 - tv1->tv_usec);
> usec += (tv2->tv_sec - tv1->tv_sec - 1) * 100;
> return(usec);
> }
> 

 PGP signature

Re: Machines are getting too damn fast

[Coleman Kane]

You should see what speed RamBus they were using, 600 or 800 Mhz. It is
pretty fast for large memory writes and reads. It'd be cool to see how
the different speeds stack up against one another. DDR comparisons would
be cool too. Yeah, for the frequency, you have to take into account that
these are different chips than your PIII or Athlons and the performance
difference is not simply a linear relation to the frequency rating
(i.e.: 1.3Ghz is not really over one-billion instructions per second,
just clocks per second). We installed Linux at a UC Free OS User Group
installfest here in cincinnati, it was pretty sweet. The machine was a
Dell and the case was freakin' huge. It also came with a 21" monitor and
stuff. The performace was really good, but not really any better than I
hads gleaned from the newer 1Ghz Athlons or PIII's.

Matt Dillon had the audacity to say:
> 
> I was browsing CompUSA today and noticed they were selling Sony
> VAIO 1.3 and 1.5 GHz desktops, amoung other things.  It's amazing
> how fast processors have gotten just in the last two years!  I just
> had to pick up one of these babies and give it a run through to see
> how fast the RamBus memory is.
> 
> I'm suitably impressed, at least when comparing it against other Intel
> cpu's.  Intel is finally getting some decent memory bandwidth.  I've
> included some memory copying tests below.  The actual memory bandwidth
> is 2x what the test reports since it's a copy test.
> 
> Sony 1.3 GHz Pentium 4 VAIO w/ 128MB RamBus memory (two 64MB RIMMs)
>   571.20 MBytes/sec (copy)
> 
> 650 MHz Celleron (HP desktop, DIMM)
>   114.65 MBytes/sec (copy)
> 
> 750 MHz P-III (2U VALINUX box, 2-cpu, 1024M ECC-DIMM)
>   162.20 MBytes/sec (copy)
> 
> 700 MHz Celeron(?) (1U VALINUX box, 1-cpu, 128MB DIMM)
>   93.56 MBytes/sec (copy) < yuch
> 
> 550 MHz P-III (4U Dell 2400, 1-cpu, 256MB DIMM)
>   225.92 MBytes/sec (copy)
> 
> 600 MHz P-III (2U Dell 2450, 2-cpus, 512MB DIMM))
>   228.91 MBytes/sec (copy)
> 
> I was somewhat disappointed with the VALINUX boxes, I expected them to
> be on par with the DELLs.  In anycase, the Sony VAIO workstation with
> the RamBus memory blew the field away.  The cpu is so fast that a
> buildworld I did was essentially I/O bound.  I'll have to go and buy some 
> more RamBus memory for the thing (it only came with 128MB), which is 
> kinda of annoying seeing as I have a gigabyte worth of DIMMs just sitting
> on my desk :-( that I can't use.
> 
> I'm tring to imagine 1.3 GHz.  That's over a billion instructions
> a second.  And in a few years with the new chip fab lithography
> standards it's going to be 10 GHz.
> 
> We need to find something more interesting then buildworlds to do on
> these machines.
> 
>   -Matt
> 
> 
> /*
>  * Attempt to test memory copy speeds.  Use a buffer large enough to
>  * defeat the on-cpu L1 and L2 caches.
>  */
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #define NLOOP 100
> 
> char Buf1[2 * 1024 * 1024];
> char Buf2[2 * 1024 * 1024];
> 
> int deltausecs(struct timeval *tv1, struct timeval *tv2);
> 
> int
> main(int ac, char **av)
> {
> int i;
> double dtime;
> struct timeval tv1;
> struct timeval tv2;
> 
> memset(Buf1, 1, sizeof(Buf1));
> for (i = 0; i < 10; ++i)
>   bcopy(Buf1, Buf2, sizeof(Buf1));
> 
> gettimeofday(&tv1, NULL);
> for (i = 0; i < NLOOP; ++i)
>   bcopy(Buf1, Buf2, sizeof(Buf1));
> gettimeofday(&tv2, NULL);
> 
> dtime = (double)deltausecs(&tv1, &tv2);
> printf("%6.2f MBytes/sec (copy)\n", (double)sizeof(Buf1) * NLOOP / dtime);
> return(0);
> }
> 
> int
> deltausecs(struct timeval *tv1, struct timeval *tv2)
> {
> int usec;
> 
> usec = (tv2->tv_usec + 100 - tv1->tv_usec);
> usec += (tv2->tv_sec - tv1->tv_sec - 1) * 100;
> return(usec);
> }
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 PGP signature

Voodoo Graphics

[Coleman Kane]

I would really like to verify whether or not my 3dfx driver works properly
with the older Voodoo Graphics cards. Would it be possible for someone with
-CURRENT to test this out for me, or anyone to loan me one of these cards for
testing. I'd just like to clase that up and make sure it works for -stable.

Thanks,
Coleman Kane

 PGP signature

Re: Glide2x on FreeBSD? Anyone? Anyone...

[Coleman Kane]

I tried working with this some time ago. I managed to eventually get a
glide2x.so that compiled, but all my newly compiled glide-based apps would crash
suddenly. There are some patches available (I am including what I have found),
that are supposed to fix this. Perhaps we should create a code branch of glide2x
to work on for FreeBSD until we get something stable? I have been working on and
off on these sorts of projects, as I am a full-time student at the Univ. of
Cincinnati as well. Anyway, try the patches and tell me what you come up with.

Rafael Barrero had the audacity to say:

> Has anyone here had any luck compiling Glide2x (from the SourceForge project pages - 
>http://www.sourceforge.net/project/?form_grp=369) under FreeBSD? Glide2x, not Glide3x.
> 
> Essentially I'm looking to build a native glide2x.so for testing under FreeBSD, but 
>I'm not having much luck with the (latest) CVS snapshot. It seems to me (I could be 
>utterly wrong here) that the makefiles and organization of the distribution are 
>mangled to some extent. The webpage does indicate FreeBSD, unfortunately I've had 
>little luck building this thing. I noticed there are some existing FreeBSD ports 
>available... but those only lead me to dead links.
> 
> If I could get someone to fix this or help me out, that would be fantastic.
> 
> Much appreciated,
> 
> Rafael Barrero
> Loki Software, Inc.
> 
> "You know ... you take the killing for granted. And then it's gone, and you're like, 
>'I wish I'd appreciated it more.' Stopped and smelled the corpses, you know?"
> -Spike (BtVS)
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 


diff -ur Glide-orig/cvg/glide/oem/oeminit.c Glide/cvg/glide/oem/oeminit.c
--- Glide-orig/cvg/glide/oem/oeminit.c  Mon Nov 29 19:37:43 1999
+++ Glide/cvg/glide/oem/oeminit.c   Tue Dec  7 14:45:03 1999
@@ -20,8 +20,9 @@
 */
 #include 
 #include 
+#include 
 
-#ifndef __linux__
+#if !defined(__linux__) && !defined(__FreeBSD__)
 #include 
 #endif
 
diff -ur Glide-orig/cvg/glide/src/fxgasm.c Glide/cvg/glide/src/fxgasm.c
--- Glide-orig/cvg/glide/src/fxgasm.c   Mon Nov 29 19:37:43 1999
+++ Glide/cvg/glide/src/fxgasm.cTue Dec  7 14:55:23 1999
@@ -37,7 +37,7 @@
  * macros for creating assembler offset files
  *--*/
 
-#ifndef __linux__
+#if !defined(__linux__) && !defined(__FreeBSD__)
 #define NEWLINE printf("\n")
 #define COMMENT 
printf(";--\n")
 
diff -ur Glide-orig/cvg/glide/src/g3df.c Glide/cvg/glide/src/g3df.c
--- Glide-orig/cvg/glide/src/g3df.c Mon Nov 29 19:37:43 1999
+++ Glide/cvg/glide/src/g3df.c  Tue Dec  7 14:55:37 1999
@@ -62,7 +62,7 @@
 #include 
 #include 
 #include "fxglide.h"
-#ifdef __linux__
+#if defined(__linux__) || defined(__FreeBSD__)
 #include 
 #endif
 
diff -ur Glide-orig/cvg/glide/src/gdraw.c Glide/cvg/glide/src/gdraw.c
--- Glide-orig/cvg/glide/src/gdraw.cMon Nov 29 19:37:43 1999
+++ Glide/cvg/glide/src/gdraw.c Tue Dec  7 14:54:40 1999
@@ -680,7 +680,7 @@
 }
   }
 #endif
-#if defined( __linux__ )
+#if defined(__GNUC__) && defined(__i386__)
 #if !defined(BIG_OPT)
   asm( "popl %%ebp" : /* no outputs*/ : /* no inputs */ : "ebp");
 #endif
diff -ur Glide-orig/cvg/glide/src/glidesys.h Glide/cvg/glide/src/glidesys.h
--- Glide-orig/cvg/glide/src/glidesys.h Mon Nov 29 19:37:43 1999
+++ Glide/cvg/glide/src/glidesys.h  Tue Dec  7 14:41:19 1999
@@ -88,7 +88,7 @@
 #endif
 
 /* Check for OS */
-#if defined(__IRIX__) || defined(__sparc__) || defined(__linux__)
+#if defined(__IRIX__) || defined(__sparc__) || defined(__linux__) || 
+defined(__FreeBSD__)
 #  define GLIDE_OSGLIDE_OS_UNIX
 #elif defined(__DOS__)
 #  define GLIDE_OSGLIDE_OS_DOS32
diff -ur Glide-orig/cvg/glide/src/gpci.c Glide/cvg/glide/src/gpci.c
--- Glide-orig/cvg/glide/src/gpci.c Mon Nov 29 19:37:43 1999
+++ Glide/cvg/glide/src/gpci.c  Tue Dec  7 14:55:56 1999
@@ -603,7 +603,7 @@
   const char* errStr = s;
   
   if (pciGetErrorCode() == PCI_ERR_NOERR) {
-#ifndef __linux__
+#if !defined(__linux__) && !defined(__FreeBSD__)
 sprintf(s, "%s: glide2x.dll expected %s, none detected\n",
 FN_NAME, GLIDE_DRIVER_NAME);
 #else
diff -ur Glide-orig/cvg/glide/tests/display.c Glide/cvg/glide/tests/display.c
--- Glide-orig/cvg/glide/tests/display.cMon Nov 29 19:38:10 1999
+++ Glide/cvg/glide/tests/display.c Tue Dec  7 14:46:40 1999
@@ -18,7 +18,7 @@
 
 #include 
 #include 
-#ifndef __linux__
+#if !defined(__linux__) && !defined(__FreeBSD__)
 #include 
 #endif
 #include 
diff -ur Glide-orig/cvg/glide/tests/h3dtst01.c Glide/cvg/glide/tests/h3dtst01.c
--- Glide-orig/cvg/glide/tests/h3dtst01.c   Mon Nov 29 19:38:11 1999
+++ Glide/cvg/glide/tests/h3dtst01.cTue Dec  7 15:30:20 1999
@@ -16,14 +16,14 @@
 **
 */
 
-#ifndef __linux__
+#if !define

Re: Realtek card support

[Coleman Kane]

I usually don't recommend the 8139/29 for anything that is expected to work
consistently. The cards work alright, but I prefer to stick to Digital or Intel
based NICs for important tasks.

Warner Losh had the audacity to say:
> 
> We've had horrible luck with the realtek 8139 with a few of our 10MBps 
> hubs.  We've had OK luck with cross over cables, but not good enough
> to run with that configuration in our deployed systems.
> 
> We've also found that this is due to autonegotiation is the cause of
> this and that if we explicitly choose 10BaseT it works well enough to
> deploy in our systems.
> 
> Warner
> 
> 
> 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: Does anyone know how to let fd0.1720 be bootable?

[Coleman Kane]

I had issues with this when I was doing some bootsector ASM coding. Basically,
you have to set up the disk header (first 32 bytes of sector 1?) to tell the
bios how many sectors your disk has. Many BIOSes will still only do 18 sectors
anyway, though. I can't remember the exact layout of the disk header, but it is
usually started with a JMP NEAR instruction past the info header (3 bytes),
followed by a short OS signature (8 bytes?) and then the disk info that is
typically passed in INT 13 calls.

Luigi Rizzo had the audacity to say:
> 
> > On Sat, Jan 20, 2001 at 01:19:17PM -0800, Luigi Rizzo wrote:
> > > > I think this is a BIOS issue.  I don't think any BIOS will let you
> > > > boot from arbitrarily-formatted floppies :)
> > > 
> > > the 1480 format works.
> > 
> > Have you got this working now - or was it the larger size that didn't
> > work?
> 
> 1480 always worked for me on the system i tried -- except on vmware.
> i it was the 1720k format where i had problems which i could not
> solve despite a number of different attempts at telling the
> bios that i was using 21 sectors/track.
> 
>   cheers
>   luigi
> --+-
>  Luigi RIZZO, [EMAIL PROTECTED]  . ACIRI/ICSI (on leave from Univ. di Pisa)
>  http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
>  Phone: (510) 666 2927
> --+-
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 PGP signature

Re: Linux NVIDIA drivers vs. default XFree86 drivers (WAS: RE: Video card support)

[Coleman Kane]

Trent Nelson had the audacity to say:
> Garrett Rooney wrote:
> > 
> > On Sun, 30 Jul 2000, Trent Nelson wrote:
> > 
> > >   So, given a working FreeBSD-specific kernel device driver - can the
> > > Linux OpenGL driver/libraries provided be handled via linux.ko?
> > 
> > i believe the general answer is a definative maybe.  but honestly, do you
> > really care enough to try?
> 
>   'Maybe' is good enough for me.
>

I would guess that if they have managed to abstract their NT source to the point
where a simple wrapper can turn it into a linux kmod, then it is quite possible
that it may be able to be ported to FreeBSD. The only other thing is whether
their X Server could be ported in such a way (is it a binary only X-Server as
well? or do they use the r128 driver supplied?). I suppose that one could always
run XFree86 in linux emulation...if possible.

> > that's less than the
> > programmer time to make the NVidia drivers work is worth, and you can
> > actually be sure you'll have some kind of success, where the NVidia stuff
> > is really up in the air.
> 
>   NVIDIA's stand on Open Source can only get better.  Unless they're
> *really* stupid.
>  

Well, so far they haven't shown this. Since their itroduction of open
source drivers they have retracted the openness of their drivers to the
point that they are simply a binary with the necessary source to link them to a
module.

> > -garrett
> 
>   Trent.
> 

FWIW: I have a roommate who has been having severe stability issues with
NVidia's binary drivers under Debian GNU/Linux 2.1. He has decided to
switch back to the XFree86 supplied drivers that have lower performance
to stop X from crashing so much. You can't even debug them because the
symbols have been stripped out. Too bad.

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: DEVFS

[Coleman Kane]

Excellent. I saw a large amount of traffic floating around, wanted to
see if there was a major coordinator keeping track. Saw a few of your
posts earlier, anyway I noted to jkh that I had an interest in helping
work on this. It seemed to be on hold for a little while, but listed
as unfinished. I'd like to help set a goal of getting it to a finished
product before 4.2 and hopefully, getting inclusion in 4.3-R...

Poul-Henning Kamp had the audacity to say:
> 
> I consider myself the coordinator for DEVFS, and I track the
> discussion and ideas that are floated.
> 
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD coreteam member | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: DEVFS

[Coleman Kane]

Just to make sure we all know what's going on:

Is someone currently tracking this thread and merging ideas into
a write-up of what features DEVFS should have, as well as its
implementation? I nice text would be fine to stick in the devfs tree to
outline this, it would help facilitate work on this project.

Chris Costello had the audacity to say:
> 
> On Saturday, July 15, 2000, Adrian Chadd wrote:
> > Ok, how about you, phk and julian throw up a list of what devfs should do?
> > I am forming some ideas on how to solve the namespace and device cloning
> > issues, we might make some forward work on this finally? :-)
> 
>I'm not Boris, phk or Julian, but I'd like to add that it
> should probably integrate the fdesc code.  Especially since I'm
> working on (and am soon going to hopefully commit) code to do
> more relatively major repairs to fdesc[1].
> 
> -- 
> |Chris Costello <[EMAIL PROTECTED]>
> |[1] Removing all references to DTYPE_* macros.
> `--
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: DEVFS

[Coleman Kane]

This is a great idea. We need a good, well drawn out description of
what DEVFS is supposed to accomplish and how we'd like it to work. I
will be glad to help out, and perhaps we can get some movement on this.
Personally, I'd like to see DEVFS completely replace the current system
of nodes in /dev.

One nice feature would also be to be able to define aliases of certain
devices, such as cdrom, modem, etc... I suppose these could get handled
in rc/rc.conf. Also, I really like the idea of being able to create a
'limited' devfs mount for a chroot'd environment.


Adrian Chadd had the audacity to say:
> 
> Ok, how about you, phk and julian throw up a list of what devfs should do?
> I am forming some ideas on how to solve the namespace and device cloning
> issues, we might make some forward work on this finally? :-)
> 
> 
> Adrian
> 
> -- 
> Adrian Chadd  Build a man a fire, and he's warm for the
> <[EMAIL PROTECTED]>  rest of the evening. Set a man on fire and
>       he's warm for the rest of his life.
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

DEVFS

[Coleman Kane]

Who is currently working on the DEVFS? I emailed the last person
to commit to the HOWTO and got no response. I'd like to look into
finisheing this, and may start hacking if no one tells me otherwise...

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Anyone tried StarOffice 5.2 yet?

[Coleman Kane]

Yeah, change the /usr/bin/test in soffice to /bin/test. BSD has test in /bin.

Wes Peters had the audacity to say:
> Coleman Kane wrote:
> > 
> > Naw, man. Ports are necessary.
> > 
> 
> They sure are:
> 
> wes@homer$ /usr/local/office52/program
> bash: /usr/local/office52/program: is a directory
> 
> wes@homer$ /usr/local/office52/program/soffice
> /usr/local/office52/program/soffice: /usr/bin/test: not found
> 
> Then it continues to run the binary.  Perhaps the port could fix this
> minor bobble?  And include a packing list so it can be deleted?
> 
> Other than that, it seems to work OK.  44 seconds to startup and shutdown;
> it still isn't exactly a speed daemon.
> 
> -- 
> "Where am I, and what am I doing in this handbasket?"
> 
> Wes Peters Softweyr LLC
> [EMAIL PROTECTED]   http://softweyr.com/
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Anyone tried StarOffice 5.2 yet?

[Coleman Kane]

You should be using the linux_base package. The linux_lib were removed after rh
5.2. I did this on 5.0-C. 

Ollivier Robert had the audacity to say:
> According to Coleman Kane:
> > I d/l'd from Sun and it installed without a hitch. It is a hell of a lot
> > faster than 5.1 and they've gotten rid of some of the crapisms.
> 
> On 5.0-CURRENT or 4-STABLE ? With which linux_lib port ? I tried on my
> 5.0-CURRENT with the latest linux_lib (from RedHate 6.1) and the setup dies
> before the end, leaving with a non runnable SO :-(
> -- 
> Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
> FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun  4 22:44:19 CEST 2000
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Anyone tried StarOffice 5.2 yet?

[Coleman Kane]

Naw, man. Ports are necessary.

Michael Lucas had the audacity to say:
> > I did not have time to work out what's failing, but it should be easy
> > to reproduce (start the installer with an option, hmmm, think it was
> > /net, can't check, since I'm away from that system ...)
> 
> Yep.  Run the installer as root with the /net option, and put it
> under, say, /usr/local/office52.
> 
> Then:
> 
> exit root
> 
> cd /usr/local/office52/program
> 
> run setup as a regular user.
> 
> No problem.
> 
> I'm not sure we should even bother with the port.  :)
> 
> ==ml
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Anyone tried StarOffice 5.2 yet?

[Coleman Kane]

I d/l'd from Sun and it installed without a hitch. It is a hell of a lot
faster than 5.1 and they've gotten rid of some of the crapisms.

Stephen Hocking had the audacity to say:
> 
> Hopefully some industrious soul will update the port...
> 
> 
>   Stephen
> -- 
>   The views expressed above are not those of PGS Tensor.
> 
> "We've heard that a million monkeys at a million keyboards could produce
>  the Complete Works of Shakespeare; now, thanks to the Internet, we know
>  this is not true."Robert Wilensky, University of California
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: UDF (DVD fs)

[Coleman Kane]

Soren Schmidt had the audacity to say:
> 
> Uhm, the real value of UDF is that it can be used as a "real" rw
> filesystem on CDRW/DVDRAM media, if this is not implemented the
> value of having UDF is very limited IMHO
>

Not necessarily, since the cd9660 backward compatibility is not a
requirement of the standard. I have Pulp Fiction here, and it doesn't
work, because it has no 9660 compatibility.

> > In the meanwhile you should be able to mount most modern DVDs using
> > the ISO9660 filesystem as they should be "bridge" format, (in which
> > there is metadata for both types of filesystems).
> 
> Endeed, makeing a ro UDF filesystem more or less useless :)
> 
> -Søren
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

UDF (DVD fs)

[Coleman Kane]

Hello, is anyone currently working on code to implement the UDF
filesystem? For those not familiar with it, it is the filesystem that
DVDs use. I'd like to look into getting the support under FreeBSD, since
the players already seem to work. If no one is working on this, then I
could probably use some help in writing the code to support this fs.

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu

 PGP signature

Re: XFree86 4.0 - What are people using for dual-head video?

[Coleman Kane]

I have been using a Matrox MGA G200 and a matrox Mystique 220. The
mystique card has a shot bios chip, so it only works as a secondary
video board. Besides, the G200 is far better to put on my 19" KDS VS-195e. My
Mystique is connected to an older NEC SVGA monitor, 14" at 1024x768@60Hz.


Matthew Reimer had the audacity to say:
> 
> Thomas Stromberg wrote:
> > 
> > This discussion comes up every once in a while on the lists, and I guess
> > it's time for an update. I havent seen anything since the 3.9.17 beta, so
> > here we go..
> > 
> > What dual head video combinations are people using with XFree86 4.0 and
> > FreeBSD? I've got a -CURRENT box right now with an AGP Riva TNT 2, and
> > really want to setup dual-head with it for programming (after first seeing
> > it on IRIX several years ago, I got hooked). Are people mixing different
> > vendors (Riva & Matrox?) and or AGP and PCI?
> > 
> > It's my understanding that there still isn't support for the dual-head
> > cards from Matrox, unless you go with a commercial X server. If anyone
> > could point me to a dual-head compatibility list, that'd help too.
> 
> I've had success with an AGP TNT2 Ultra with a Matrox Millenium.
> 
> Matt
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Linux ioctls

[Coleman Kane]

Who i currently working on the linux emu ioctl code? I need to add another ioctl
to it to support glide games under freebsd in linux emulation.

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: freebsd bios.

[Coleman Kane]

I never said it would be easy, I simply was stating that the reference
designs tend to stick to documented specifications, typically. Of
course, writing a BIOS is hard enough.

John Baldwin had the audacity to say:
> On 19-Jun-00 Coleman Kane wrote:
> > If you start out with a board based on a reference design, say the Intel
> > SE440BX, you already have access to all this info. Most chipset vendors have
> > info on this sort of thing up on their webpage, I know intel is really good
> > about this sort of thing (though I am not so sure about the 810/815/820/840
> > chipsets).
> 
> Not the chipset, all the hardware like the PIC's, the RTC, the CPU fan,
> the keyboard controller, etc. etc. ad nauseum.  Go back earlier in the
> thread and read some of the AML Mike posted that has to be done just to
> turn the CPU fan on.
> 
> > Mike Smith had the audacity to say:
> >> 
> >> > On Sat, 17 Jun 2000 07:35:51 +0900, "Daniel C. Sobral" wrote:
> >> > >
> >> > >Loader(8) runs using BIOS services, and loads the kernel from any drive
> >> > >that BIOS recognizes. It has also been enhanced with PXE knowledge, so
> >> > >he can load from that to.
> >> > 
> >> > My mistake, as Ron pointed out, since loader uses the BIOS services, it
> >> > can't run when there is no BIOS.  Now if someone writes a loader that
> >> > doesn't use a BIOS...
> >> 
> >> You could easily do this, just as soon as you find a motherboard vendor 
> >> that will tell you how to initialise all their hardware.
> 
> -- 
> 
> John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
> PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: freebsd bios.

[Coleman Kane]

If you start out with a board based on a reference design, say the Intel
SE440BX, you already have access to all this info. Most chipset vendors have
info on this sort of thing up on their webpage, I know intel is really good
about this sort of thing (though I am not so sure about the 810/815/820/840
chipsets).

Mike Smith had the audacity to say:
> 
> > On Sat, 17 Jun 2000 07:35:51 +0900, "Daniel C. Sobral" wrote:
> > >
> > >Loader(8) runs using BIOS services, and loads the kernel from any drive
> > >that BIOS recognizes. It has also been enhanced with PXE knowledge, so
> > >he can load from that to.
> > 
> > My mistake, as Ron pointed out, since loader uses the BIOS services, it
> > can't run when there is no BIOS.  Now if someone writes a loader that
> > doesn't use a BIOS...
> 
> You could easily do this, just as soon as you find a motherboard vendor 
> that will tell you how to initialise all their hardware.
> 
> -- 
> \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
> \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 3dfx driver for freebsd

[Coleman Kane]

I've used it in both. Also many other people have used it in -Stable and
-Current. I was shooting for compatibility between the two. Thanks for
asking though.

Essenz Consulting had the audacity to say:
> 
> Hmmm,
> 
> I guess this point was overlooked, but Has anyone tried this new code
> to see if it works well under FreeBSD 4.0?
> 
> -jve
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 3dfx driver for freebsd

[Coleman Kane]

Please, people, why is this such a big deal? So Jordan doesn't read
Daemonnew, and I only read the news there, I don't really ever have time
to browse the links. I already said I was in contact with the writer of
the voodoo driver, and he had pretty much given up awhile ago, his code
was written for an older version of freebsd anyway, so it would have
been holding on to the old freebsd driver interface. I really doubt that
proving that jordan hubbard has passed over daemon news once is a useful
priority, so stop it. If he says he hasn't been there, then he hasn't
been there.

Harold Gutch had the audacity to say:
> On Sat, Jun 17, 2000 at 11:07:24PM -0700, Jordan K. Hubbard wrote:
> > > Seeing as how it has been a link on Daemon News' front page for several
> > > months, I find that hard to believe.  :-P
> > 
> > Not all of us read daemon news, either.  As far as I'm concerned, if
> > it's not part of www.freebsd.org, it doesn't exist. :-)
> 
> Does a link from http://www.freebsd.org/projects/ count?
> 
> bye,
>   Harold
> 
> -- 
> Someone should do a study to find out how many human life spans have
> been lost waiting for NT to reboot.
>   Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 3dfx driver for freebsd

[Coleman Kane]

If this is the driver that has been up there for awhile, I was told
by the author it didn't work. I used some of his code, namely for the
ioctls. The author actually contacted me and wanted to know about this.
His driver was written for an older version of FreeBSD and wasn't
newbussified at all. He also hadn't been able to get the mmap stuff
working on account of 3dfx's mistake in writing glide. I fixed all of
these problems in my release, and it works great, so far as I have been
told.

Cyrille Lefevre had the audacity to say:
> Coleman Kane <[EMAIL PROTECTED]> writes:
> 
> > Here's the address of the 3dfx device driver I wrote for freebsd:
> > http://pohl.ececs.uc.edu/~cokane/
> > 
> > Please test it some more and give me feedback. Could someone please email me
> > with information on submitting this to the CVS commit team?
> 
> did you register it at the BSD Driver Database ?
> 
> http://www.posi.net/freebsd/drivers/ 
> 
> is it the same as http://www.posi.net/freebsd/drivers/driver-info.phtml?ID=2 ?
> 
> Cyrille.
> -- 
> home:mailto:[EMAIL PROTECTED] Supprimer "no-spam." pour me repondre.
> work:mailto:[EMAIL PROTECTED] Remove "no-spam." to answer me back.
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu

 PGP signature

3dfx driver for freebsd

[Coleman Kane]

Here's the address of the 3dfx device driver I wrote for freebsd:
http://pohl.ececs.uc.edu/~cokane/

Please test it some more and give me feedback. Could someone please email me
with information on submitting this to the CVS commit team?

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kerneld for FreeBSD

[Coleman Kane]

I personally, don't see the reason for having this sort of thing in embedded
devices, either, a lot of which have just exactly what they need to operate in
the kernel, leaving nothing to be loaded or unloaded. As far as the kerneld
stuff goes, the kernel obviously provides us with an interface with which to
load these drivers from whatever may use them, there probably isn't a need after
all for this sort of thing, so I'm done thinking about it, on to more pertinent
things...

Mike Smith had the audacity to say:
> Nobody in their right mind is going to produce a "really small ram" 
> embedded system that features the sort of nondeterminism that 
> "automatically" (read 'randomly') unloading modules would involve.
> 
> It's simple; a kernel-module-handling-daemon does not have anything to 
> offer us at this time.  We don't need one; the problems it might be 
> applied to solve have already been solved differently, and we are 
> (generally) happy with the results.
> 
> -- 
> \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
> \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Comments on Athlon [motherboards] sought..

[Coleman Kane]

I have heard of a few problems with the k7m... but I don't have any firsthand
experience with them. FIC on the other hand has made some pretty good
motherboards, and are probably the last company that needs to be bashed as far
as quality goes. ASUS and FIC are probably the two best mobo companies, to me
anyway, never had any trouble with either one at all. 

Soren Schmidt had the audacity to say:
> 
> What ? I have no probs whatsoever with my K7M doing that...
> 
> >  So far I like the FIC and Aopen boards.
> 
> Dont _ever_ buy FIC, there are no ends of trouble with them....
> 
> -Søren
> 
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: FreeBSD Support of Hot Swappable NICs

[Coleman Kane]

This is rather interesting, it probably would have to do with PCI BIOS support
as well, I suppose, but other than that, as long as you could safely unload and
reload the pci code without depending upon it... it may work, or maybe set up a
hook into the driver to rescan.

Dan Nelson had the audacity to say:
> In the last episode (Jun 07), Alfred Perlstein said:
> > Brech, Cary <[EMAIL PROTECTED]> [000607 10:33] wrote:
> > > Lucent recently introduced a product that uses FreeBSD as its OS. 
> > > We are currently contemplating adding the ability to "Hot Swap" the
> > > custom network interface cards we are developing for the next
> > > release.  The question we have is does FreeBSD support the ability
> > > to hot swap network interface cards?
> > > 
> > > Thanks in advance for your assistance!
> > 
> > We can do pcmcia hot swap, but it gets hairy if the interface is
> > in use, the interface should be 'downed' before removing afaik.
> 
> Or do you mean PCI hot-plug?  FreeBSD currently doesn't support
> powering off PCI slots or re-probing the PCI bus after bootup, both of
> which are required for hot-plug.  I don't know how hard it would be to
> add, either.  You'll probably have to ask -hackers about that (cc and
> reply-to reset there).
> 
> -- 
>   Dan Nelson
>   [EMAIL PROTECTED]
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kerneld for FreeBSD

[Coleman Kane]

Yeah, I actually wasn't aware of the net and fs stuff at first. It works great
though, I was just continuing from what someone else had mentioned, and then it
got turned into kerneld for freebsd. I originally simply wanted to see about
options sort of like kerneld. I mean, maybe a utility that can load modules and
all itself, or at the very least, a mechanism to manage the growing number of
modules in the kernel. Anyway, the questions we should ask are: What are the
shortcomings of the current kld 'module' system? What type of support would we
like to see?

Neil Blakey-Milner had the audacity to say:
> If you're suggesting more modularity, that's great.  You just confused
> me by mentioning "kerneld".  I'm all for more modules.
> 
> I still had problems with why you wanted a 'kerneld', but rwatson's
> suggestions about security, pccardd, usbd, do make sense.  I do like the
> way the auto-ifconfig and auto-mount stuff works, though.
> 
> At the very least, I'd like a probe-only way to find out what devices
> are available, given a bunch of device driver modules.
> 
> Neil
> -- 
> Neil Blakey-Milner
> Sunesi Clinical Systems
> [EMAIL PROTECTED]
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message