Re: GSoC: EFI on intel

[Doug Ambrisko]

Eric McCorkle writes:
| On 04/03/12 13:22, Doug Ambrisko wrote:
| > EFI is a good task.  For generic PC's we need an X64 format.  The current
| > version in FreeBSD is IA32 format.  The X64 can boot i386/amd64.
| > Qemu can be used to test both IA32 and X64 formats.  I added some
| > notes about this on the wiki at:
| > 
http://wiki.freebsd.org/IdeasPage#EFI_support_for_FreeBSD.2BAC8-i386_and_FreeBSD.2BAC8-amd64_.28GSoC.29
| >
| > Qemu is nice since it can runs an UEFI BIOS via the OVMF project
| > and emulate a DOS file system by pointing qemu to a directory. So
| > then it is easy to build something, toss it into a directory, start
| > qemu and test.
| 
| I'm drafting an application right now.  I emailed the listed contacts
| (Rui Paulo and Andrey Elsukov) a moment ago.
|
| I've done background research on this already, as part of getting
| FreeBSD to work on Mac hardware.  QEMU caught my attention as a
| testbed.  Also, I found out Apple EFI implementations are non-standard. 
| They specifically look for an HFS+ partition and load a specific file. 
| The workaround is pretty simple, of course: just wrap the boot loader in
| an HFS+ image and write it to a partition reserved for that purpose.
| 
| Anyway, if I'm going to propose this, I need to list possible mentors. 
| Skill-wise, I'm well equipped to take it on.  I anticipate needing
| someone who's a committer, preferably with good knowledge of the kernel
| sources.

Both Rui and Andrey should be able to to fit your need for mentors.
I can help with some stuff.  It seems you've looked at the Mac side
a fair amount.  It might be good to look at X64 and IA64.  Don't know
how much can be shared.  There is an efi loader in the tree for IA64.
I've only played around with generic PC's (Dell, AMI based systems
and qemu).  I built grub and had grub boot via efi.

Doug A.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: GSoC: EFI on intel

[Doug Ambrisko]

Eric McCorkle writes:
| I'm assessing possible summer of code projects, and the EFI work caught
| my attention.  I've been running FreeBSD on a macbook for a little under
| a year now, and booting on EFI is definitely an interest to me.  Does
| anyone know if this is still a viable project proposal?  I certainly
| have the skills to undertake it, I just want to make sure that it stands
| a chance of actually being selected.

EFI is a good task.  For generic PC's we need an X64 format.  The current
version in FreeBSD is IA32 format.  The X64 can boot i386/amd64.
Qemu can be used to test both IA32 and X64 formats.  I added some
notes about this on the wiki at:

http://wiki.freebsd.org/IdeasPage#EFI_support_for_FreeBSD.2BAC8-i386_and_FreeBSD.2BAC8-amd64_.28GSoC.29

Qemu is nice since it can runs an UEFI BIOS via the OVMF project
and emulate a DOS file system by pointing qemu to a directory. So
then it is easy to build something, toss it into a directory, start
qemu and test.

Thanks,

Doug A.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [patch] Disable bios probe if acpi is enabled

[Doug Ambrisko]

Sean Bruno writes:
| I'm noting that newer machines are completely hosed if we attempt to
| probe for bios values.  I'm proposing this change.
| 
| -bash-4.2$ p4 diff -du //depot/yahoo/ybsd_7/src/sys/i386/i386/bios.c
| --- //depot/yahoo/ybsd_7/src/sys/i386/i386/bios.c   2011-09-16
| 22:47:30.0 
| +++ /home/seanbru/ybsd_7/src/sys/i386/i386/bios.c   2011-09-16
| 22:47:30.0 
| @@ -84,6 +84,12 @@
|  char   *p;
|  
|  /*
| + * Don't do bios probing if acpi is enabled, its
| + * pointless and breaks on newer systems
| + */
| +if (!resource_disabled("acpi", 0))
| +   return;
| +/*
|   * BIOS32 Service Directory, PCI BIOS
|   */
| 

That seems reasonable to me.

Doug A.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: mfi (Dell H700) + hot swapping doesn't appear to work with RC1

[Doug Ambrisko]

Andrew Boyer writes:
[snip]
| Has anyone managed to get the real JBOD mode working on this controller?
| It advertises support in the firmware but doesn't seem to do anything.  
| The documentation only lists JBOD mode as a feature of the lower-end 
| controllers.
[snip]

The current mfi driver doesn't have support for JBOD support.  The new
one that is being working does have true JBOD support.  Some people have
been doing something like this via the cam passthough hack.  With
JBOD inserting the disk and removing a disk as hot swap is working.
There are some rough edges on the new driver that are being worked out
by a few people.  It supports all current LSI MegaRAID cards.

So things should get better in the near future.

Thanks,

Doug A.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: NFS mount inside jail fails

[Doug Ambrisko]

Alexander Leidinger writes:
| Quoting Doug Ambrisko  (from Thu, 19 May 2011  
| 14:38:40 -0700 (PDT)):
| 
| > Alexander Leidinger writes:
| > | On Thu, 19 May 2011 10:24:59 -0700 (PDT) Doug Ambrisko
| > |  wrote:
| > |
| > | > doesn't have access to it anymore either.  Running an X server in a
| > | > vimage has some issues.  Most are pretty easy to over-come.
| > |
| > | Are you using my patch
| > | (http://www.leidinger.net/FreeBSD/current-patches/0_jail.diff) + a
| > | custom devfs.rules to get the 2D part (the last time I tried the DRI
| > | part of my patch, it paniced the machine) of the X server working in a
| > | jail, or did you come up with something yourself? If it is the later, I
| > | would be interested how you did it.
| >
| > Nope, didn't know about it when I played with it.  I should try it.
| > I added
| > case PRIV_IO:
| > return (0);
| >
| > to kern_jail.c to get X to work.  This was with the Intel graphics.
| > The main problem I have now is on resume the X server dies and restarts.
| > I use xdm.  Without jail with vimage then it works okay.
| 
| I use it without vimage in a jail. This is with a radeon card  
| (corresponding kernel module loaded at boot to get 2D acceleration, as  
| the X server obviously can not load modules in a jail).
| 
| > My laptop can use either Intel or ATI graphics.  I just switched it to
| > ATI to see what happens.  I should try some more tests.  It seems
| > my BIOS likes to reset this setting and enable both :-(
| >
| > I don't seem to have panics.  This is with a month or so old -current.
| 
| You do not allow access to the dri device, so I do not expect a panic.  
| If you give access to the dri device (which can be enabled separately  
| in my patch), I would not be surprised to see a panic (the last time I  
| tried it is a year or two ago, I didn't take the time to investigate  
| why it panics).

Okay, I have an update.  With Intel graphics and using dri things
work better and I don't get panics.  I load drm.ko & i915.ko before
starting the vimage jail.  X sees it and uses it.  This solves the
suspend/resume issue I had.  The dri issue also prevented suspend and
resume fail to work in a chroot. 

I have not tried switching to using the ATI option.  On a plus side
my laptop is running cooler and faster now.

Doug A.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: NFS mount inside jail fails

[Doug Ambrisko]

Alexander Leidinger writes:
| On Thu, 19 May 2011 10:24:59 -0700 (PDT) Doug Ambrisko
|  wrote:
| 
| > doesn't have access to it anymore either.  Running an X server in a
| > vimage has some issues.  Most are pretty easy to over-come.
| 
| Are you using my patch
| (http://www.leidinger.net/FreeBSD/current-patches/0_jail.diff) + a
| custom devfs.rules to get the 2D part (the last time I tried the DRI
| part of my patch, it paniced the machine) of the X server working in a
| jail, or did you come up with something yourself? If it is the later, I
| would be interested how you did it.

Nope, didn't know about it when I played with it.  I should try it.
I added
case PRIV_IO:
return (0);

to kern_jail.c to get X to work.  This was with the Intel graphics.
The main problem I have now is on resume the X server dies and restarts.
I use xdm.  Without jail with vimage then it works okay.

My laptop can use either Intel or ATI graphics.  I just switched it to
ATI to see what happens.  I should try some more tests.  It seems
my BIOS likes to reset this setting and enable both :-(

I don't seem to have panics.  This is with a month or so old -current.

Doug A.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: NFS mount inside jail fails

[Doug Ambrisko]

Arnaud Lacombe writes:
| Hi,
| 
| On Wed, May 18, 2011 at 10:03 AM, Pawel Jakub Dawidek  
wrote:
| > On Tue, May 17, 2011 at 10:17:12PM +0200, Alexander Leidinger wrote:
| >> On Tue, 17 May 2011 12:56:40 -0700 Sean Bruno 
| >> wrote:
| >>
| >> > Silly thing I ran into today. ?User wanted to NFS mount a dir inside a
| >> > jail. ?After I groaned about the security implication of this, I noted
| >> > that there is a sysctl that looks like it should allow this. ?Namely,
| >> > security.jail.mount_allowed. ?I noted that setting this follows a path
| >> > that *should* have allowed this silly thing to happen, except that the
| >> > credentials in the nfsclient were not setup correctly.
| >>
| >> As you noticed, this is supposed to allow to mount inside a jail, IF
| >> the FS you want to mount is marked as secure/safe to do so. Nearly no
| >> FS is marked as such, as nobody wants to guarantee that it is safe
| >> (root in a jail should not be able to panic a system by trying to
| >> mount a corrupt/malicious FS-image) and secure (not possible to get
| >> elevated access/privileges).
| >>
| >> For NFS there is theoretically the problem that the outgoing address on
| >> requests could be the one of the physical host instead of the IP of the
| >> jail. If this is true in practice, I do not know. This could be
| >> the reason why NFS is not marked with VFCF_JAIL.
| >
| > It is not marked with VFCF_JAIL, because I just had no time to audit
| > that it is safe. It might be safe in theory.
| >
| > There are some file systems types that can't be securely mounted within
| > a jail no matter what, like UFS, MSDOFS, EXTFS, XFS, REISERFS, NTFS,
| > etc. ?because the user mounting it has access to raw storage and can
| > corrupt it in a way that it will panic entire system.
| 
| This should at least be configurable somehow for people who are using
| jails for separation and do not care about security. I'd expect that
| security decision whether or not to allow something is user relevant,
| not developer relevant.

Yes, we need to look at having sysctl's to enable more permissive options
when jails/vimage are not used to isolate users from systems but other
uses.  I'm now starting to use vimage in 8.2 and -current to make my
"host" trivial but do all of the "smarts" in a vimage.  This lets me spin
up a new image quickly and migrate.  One challenge is wireless.  You can't 
run wpa_supplicant in a vimage.  I can understand whey the ioctls are blocked 
since you could have a wireless instance in one jail and another instance in 
another jail.  However, to manage that instance can require the ioctls and 
the host doesn't have access to it anymore either.  Running an X server in a 
vimage has some issues.  Most are pretty easy to over-come.

Maybe it might be good to have a sysctl to not do any checks at all so it
acts like a chroot like security.jail.param.allow.all?

Doug A.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Set default pxeboot vfs.root.mountfrom to nfs?

[Doug Ambrisko]

Garrett Cooper writes:
| Hi Hackers,
| I realize this is a trivial patch, but it's a minor item that I
| found kind of fascinating (and not thoroughly documented elsewhere
| because many examples are booting mfsroots instead of directly booting
| off nfs roots), but I'm proposing that pxeboot default to
| vfs.root.mountfrom="nfs" to reduce the need for special case
| loader.conf files just for pxe booting (and thus, enable
| out-of-the-box netbooting ^o^!!!).
| Thoughts?
| 
| Index: boot/i386/libi386/pxe.c
| ===
| --- boot/i386/libi386/pxe.c   (revision 209563)
| +++ boot/i386/libi386/pxe.c   (working copy)
| @@ -308,6 +308,7 @@
|   }
|   setenv("boot.nfsroot.server", inet_ntoa(rootip), 1);
|   setenv("boot.nfsroot.path", rootpath, 1);
| + setenv("vfs.root.mountfrom", "nfs", 0);
|   setenv("dhcp.host-name", hostname, 1);
|   }
|  }

Interesting, are you looking at my patch from work or came up with
the same thing?  We had this patch here for years.

I haven't checked it in due to tracking done why it wasn't done in
the first place so I didn't break any assumptions.  FWIW, I have seen
no issues with patch in either NFS boots or MFS roots.

Doug A.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Reading acpi memory from a driver attached to hostb

[Doug Ambrisko]

John Baldwin writes:
| On Thursday 23 July 2009 2:08:35 am Andre Albsmeier wrote:
| > On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote:
| > > Andre Albsmeier writes:
| > > | On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote:
| > > | > On 18 Jul 2009, at 09:10, Andre Albsmeier wrote:
| > > | > 
| > > | > > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote:
| > > | > >> Andre Albsmeier wrote:
| > > | > >>> [CC'ing this to Rui Paulo since he tried to help me a while ago]
| > > | > >>>
| > > | > >>> Since my driver is a child of hostb0, I have no idea of how to  
| > > | > >>> access
| > > | > >>> acpi0's memory area. Here is a devinfo -r to make things clear:
| > > | > >>>
| > > | > >> ...
| > > | > >>>
| > > | > >>> Earlier, I was given the hint to attach as a child of acpi (see 
| the
| > > | > >>> old mail attached below) but in this case I didn't have access to 
 
| > > | > >>> the
| > > | > >>> hostb registers which I need as well.
| > > | > >>>
| > > | > >>> The only thing I see is: Attach two drivers -- one as child of 
| acpi
| > > | > >>> and another as child of hostb and let them communicate somehow (no
| > > | > >>> idea how to do this).
| > > | > >>>
| > > | > >>> I have also done crazy things like searching for acpi0 and trying
| > > | > >>> to bus_alloc_resource() the memory I am interested in but this 
| also
| > > | > >>> failed.
| > > | > >>>
| > > | > >>> Or is it possible to free(!) somehow the address space from acpi0
| > > | > >>> and pass it to hostb0 so I can bus_alloc_resource() it?
| > > | > >>>
| > > | > >>
| > > | > >> You can probably make two drivers in one which cooperate to
| > > | > >> allow access to both sets of resources.
| > > | > >
| > > | > > Hmm, that's what I meant by: Attach two drivers -- one as child of  
| > > | > > acpi
| > > | > > and another as child of hostb...
| > > | > >
| > > | > > And that's similar to Rui Paulo's suggestion a while ago:
| > > | > >
| > > | > >> You'll probably need to create a fake ACPI child driver to access 
| it.
| > > | > >>
| > > | > >> Create your identify routine with something like:
| > > | > >>
| > > | > >> static void mydriver_identify(driver_t *driver, device_t parent)
| > > | > >> {
| > > | > >>if (device_find_child(parent, "mydriver", -1) == NULL &&
| > > | > >>mydriver_match(parent))
| > > | > >>device_add_child(parent, "mydriver", -1);
| > > | > >> }
| > > | > >>
| > > | > >> mydriver_match() should check if you were given the acpi0 device.
| > > | > >
| > > | > > But in order to attach to acpi0, I need to say
| > > | > >
| > > | > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass,  NULL, 
 
| > > | > > NULL );
| > > | > >
| > > | > > instead of
| > > | > >
| > > | > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass,  
NULL,  
| > > | > > NULL );
| > > | > >
| > > | > > This way I could attach to acpi but not to hostb anymore
| > > | > >
| > > | > > I have searched the net for solutions, I have read newbus-draft.txt
| > > | > > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all
| > > | > > of these my driver is working on other mainboards where it doesn't
| > > | > > have to access foreign memory) but didn't find anything.
| > > | > 
| > > | > I'm out of ideas.
| > > | > John, do you know if this is a newbus limitation or if it can be  
| > > | > worked around ?
| > > | 
| > > | I assume it is possible somehow, I am just too stupid (it is the first
| > > | driver I wrote). John, for easy reference, here is my initial message:
| > > | 
| > > | http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html
| > > | 
| > > | Please remember all, that I need the access to the acpi0 memory location
| > > | only for a few reads during probing/attaching, not later.
| >

Re: watchdog: hw+sw?

[Doug Ambrisko]

Alexander Leidinger writes:
| Quoting Doug Ambrisko  (from Thu, 2 Apr 2009  
| 16:16:34 -0700 (PDT)):
| 
| > This worked well for us so I think it is a good idea.  Also some HW
| > watchdogs can be told to generate an NMI which can also produce a kernel
| > dump/ddb prompt.  I've also implemented some rough code to put an
| > simplified back-trace into the IPMI event log in-case a disk or disk
| > I/O sub-system died.
| 
| Somewhat related... I have 2 32bit systems with zfs which lock up  
| after a while. The lockup is strictly related to the disks. I can  
| still ping the system just fine, and the HW watchdog seems to still  
| work as intended (or it does not work at all anymore, as there's not  
| automatic reset), but as soon as I want to do something which involves  
| disks (access a webpage located on the zfs disks), I'm lost. The only  
| way to get some useful work done again is to reset manually. Your  
| paragraph above implies that the WD notices that there's a problem  
| with disks.

Yep, isn't that fun :-(
 
| While I know how to teach our watchdogd how to detect this (-e  
| option), we do not have support for this in the basesystem yet. Do you  
| have a patch for /etc/rc.d/watchdogd which allows to specify commands  
| to run via rc.conf or some patch which tells watchdogd to check a file?

We start watchdogd manually with our own rc.d script mainly since
I noticed Dell pe2650's do false triggers :-(  Also I wanted to check 
that our app. is functioning so we'd need to start after that.  It 
would be good to add flags option to the stock start-up scripts. 
Just having watchdogd running without checking on anything real tends
to be useless since it is usually swapped in and can run just fine
without depending on much of the system.

Doug A.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: watchdog: hw+sw?

[Doug Ambrisko]

Andriy Gapon writes:
| I have some vague thoughts on using SW_WATCHDOG and a hardware watchdog 
| together.
| I think this could be useful but I am not sure how to implement this.
| The idea is this: timeout for SW_WATCHDOG is smaller than timeout for hw 
| wd; when some freeze happens sw wd logic kicks in first, stops hw wd and 
| produces either panic or ddb prompt; if the freeze is so severe that sw 
| wd can't run (e.g. hardware is messed up badly) then hw wd performs its 
| duty. I am mostly interested in having this in unattended mode where kernel 
| dump could be useful for later analysis but the system should recover in 
| reasonable time.
| 
| Suggestions, opinions?

At prior company I implemented a watchdog before watchdog(4) that did
this.  I used the HW watchdog to register with the SW watchdog.  Then
our SW watchdog was ticked via a syctl count down.  This way we could
implement a fairly arbitrary range of time-outs since most HW is very
limited in the time duration and then we didn't really have to worry
about it.  If the SW watchdog didn't tick in a 10 seconds or so then the
machine is probably dead.  So we used the HW watchdog to enforce the 
SW watchdog.  It's really nice getting the panic and dump.

This worked well for us so I think it is a good idea.  Also some HW 
watchdogs can be told to generate an NMI which can also produce a kernel 
dump/ddb prompt.  I've also implemented some rough code to put an 
simplified back-trace into the IPMI event log in-case a disk or disk 
I/O sub-system died.

Doug A.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [patch] enhance powerd(8) to handle max temperature

[Doug Ambrisko]

Bill Moran writes:
| In response to "Dag-Erling Sm?rgrav" <[EMAIL PROTECTED]>:
| > Hajimu UMEMOTO <[EMAIL PROTECTED]> writes:
| > > I cannot see _TC1, _TC2 nor _TSP in your `acpidump -dt' output.
| > > Further, there is no _PSV definition in anywhere, in the first place.
| > > It seems to me that your ACPI BIOS doesn't support passive cooling at
| > > all.
| > 
| > Going off on a tangent, I too have several motherboards (965P-based)
| > which do not define any ACPI thermal zones, which leads me to wonder:
| > what is the preferred way to access thermal data these days?  IPMI?  Do
| > we have IPMI support in base or ports?
| 
| Not sure about the base, but we've been using ipmitool from ports for
| a while with success, and we're investigating FreeIPMI.

Both ipmitool and freeipmi in ports can use the ipmi(4) which lives in 
the base system on 6.X & above.  I recommend to use ipmi(4) versus
direct HW access from user-land so things are a bit more orderely.
So it is a mix of base and ports.  I like ipmitool & freeipmi in ports
as they have a bunch of people working on IPMI things and adding
features.  Personally, I went with ipmitool since some Dell people
are contributors to it.

Not all systems have IPMI but it tends to be nice when they do.  There
are several things that have IPMI as a subset.  Things that might have
it could have ASF(AMD) or AMT (Intel) capable machines.  Some times
it an add-in daughter card on server type motherboard.  With AMT it
seems Intel is pushing it more into the Desktop space :-)

Now with regards to CPU temperature.  Newer Intel CPU's do not report
their temperature.   I have read that they report how many degrees
away until there is a problem but I think that might have been a joke.

Systems that have IPMI version 2 are nice since that means they are 
supposed to support Serial Over Lan (SOL) via the standard :-)

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

Re: 32/64bit KSE issues?

[Doug Ambrisko]

Daniel Eischen writes:
| On Sat, 31 Mar 2007, John Baldwin wrote:
| > On Saturday 31 March 2007 03:16, Andriy Gapon wrote:
| >> on 31/03/2007 05:23 Daniel Eischen said the following:
| >>> On Fri, 30 Mar 2007, David E. Cross wrote:
| >>>
|  I recently ran into a problem where the 32bit JVM won't run on a 64bit 
host.
|  I, and at least one other person in -java thinks it has to do with 32 
bit KSE
|  on a 64bit kernel (I have a vague memory on this somewheres WAY back).  
Is
|  this still the issue?  Could someone point me in the general direction 
of the
|  specifics of the problem (if they exist, if not, I may try to create a
|  simpler test case then java)?
| 
|  I tried a few searches, but nothing matching what I remembered came up.
| >>>
| >>> No, you can't run 32-bit libpthread on 64-bit kernel.  There
| >>> are no compatiblity hooks in the kernel to handle 32-bit kse
| >>> interfaces.  It is really too messy to provide it.
| 
| [ ... ]
| 
| > I plan on making sure full 32-bit compat exists for both libthr and
| > libpthread and backporting it to 6.x for work.  Very few things are
| > too hard to wrap with a 32-bit shim.
| 
| Not according to peter@ ;-)  But if you can do it, that'd be
| great.

I MFC'ed David Xu's libthr to 6.X at work and it's working.  libkse
will be a lot harder IMHO.  David's stuff in -current just works.  
I routinely run 32bit thread stuff on 64bit hosts using the 
libmap32.conf trick to switch from kse to libthr.

Thanks to David for making it work in -current.

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

Re: FW: IPMI kernel module errors on 6.x

[Doug Ambrisko]

Raymond Sundland writes:
| I purchased a new Supermicro Superserver SS6015B-T (motherboard is X7DBR-E)
| about 3 weeks ago with the IPMI module (part called SIMSO) and have had a
| hard time getting the IPMI functionality to work in RELENG_6.
| 
| Particularly, when I attempt to 'kldload ipmi' I get the following output in
| dmesg:
| 
| ipmi0:  on isa0
| ipmi0: KCS mode found at mem 0xca2 alignment 0x4 on isa
| ipmi0: KCS: Failed to start write
| ipmi0: KCS Error retry exhausted
| ipmi0: KCS: Failed to start write
| ipmi0: KCS Error retry exhausted
| ipmi0: KCS: Failed to start write
| ipmi0: KCS Error retry exhausted
| ipmi0: Timed out waiting for GET_DEVICE_ID
| 
| >From the dmesg, it appears it's finding the IPMI device, but unable to
| interact with it.  Meanwhile, no device shows up in /dev so ipmitool does
| not work, either.
| 
| For reference, here is my uname:
| 
| FreeBSD exodus 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #9: Fri Nov 10 10:56:39
| PST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EXODUS  amd64
| 
| This is a RELENG_6 build with a CVSUP done just before the compile date of
| the kernel.
| 
| The SIMSO IPMI card itself works, I can access it via the web management
| console, I just can not get the kernel driver to work with it.  Any help
| and/or references would be greatly appreciated.

Could you try it static in the kernel and then with and without ACPI
enabled?

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

Re: get DMI information in kernel

[Doug Ambrisko]

[EMAIL PROTECTED] writes:
| Hello,
| how do i get DMI Informations (stuff displayed by dmidecode)  in a kernel 
module?
| 
| I need some "System Information" like Vendor,Model and OEM String identifying 
hardware on a Thinkpad.
| 
| Can anybody give me a hint on that?

You can look at the ipmi(4) driver.  It gets the IPMI HW info via SMBIOS.
There is also and smbios driver as well.

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

Re: NVIDIA FreeBSD kernel feature requests

[Doug Ambrisko]

Kip Macy writes:
| WOW THATS GREAT DOUG! \0/ - it didn't work for me.

This was with the last patched driver for vmware 2.  I'm not sure if
it every made it into the port. 

http://www.mindspring.com/~vsilyaev/vmware/files/changes
  28 Jan 01 Version 0.99-1-0.22
Support for multiple vmware sessions
Thnx to  Luigi Rizzo
Support for bridged and host-only networking
Some fixes for -STABLE and -CURRENT

Looking at the port I don't see that it's been update to 99 yet.

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

Re: NVIDIA FreeBSD kernel feature requests

[Doug Ambrisko]

Kip Macy writes:
| IIRC lack of per instance cdevs also limits Freebsd to one vmware instance.

Really?  Don't tell my vmware multiple instances!  I used to run 10 on
one FreeBSD host.

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

Re: Comtrol Rocketport UNIVERSAL PCI 32-port

[Doug Ambrisko]

Vitaliy Skakun writes:
| thanks, but I see this patch is against recent HEAD
| 
| I've got the yesterdays RELENG_6 sources and can't simply update to HEAD (
| it is a server )

Give this a shot against RELENG_6:

Index: rp.c
===
RCS file: /home/ncvs/src/sys/dev/rp/rp.c,v
retrieving revision 1.67.2.1
diff -u -p -r1.67.2.1 rp.c
--- rp.c8 Nov 2005 15:35:27 -   1.67.2.1
+++ rp.c27 Jan 2006 15:13:37 -
@@ -34,18 +34,21 @@
 #include 
 __FBSDID("$FreeBSD: src/sys/dev/rp/rp.c,v 1.67.2.1 2005/11/08 15:35:27 jhb Exp 
$");
 
-/* 
+/*
  * rp.c - for RocketPort FreeBSD
  */
+#include 
 
 #include "opt_compat.h"
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -57,7 +60,7 @@ __FBSDID("$FreeBSD: src/sys/dev/rp/rp.c,
 #include 
 #include 
 
-static const char RocketPortVersion[] = "3.02";
+static const char RocketPortVersion[] = "1.0";
 
 static Byte_t RData[RDATASIZE] =
 {
@@ -116,6 +119,8 @@ Byte_t rp_sBitMapSetTbl[8] =
0x01,0x02,0x04,0x08,0x10,0x20,0x40,0x80
 };
 
+int next_unit_number = 0;
+int num_devices_found = 0;
 /***
 Function: sReadAiopID
 Purpose:  Read the AIOP idenfication number directly from an AIOP.
@@ -587,6 +592,9 @@ static void rp_do_receive(struct rp_port
unsignedint CharNStat;
int ToRecv, wRecv, ch, ttynocopy;
 
+   if (tp->t_state & TS_TBLOCK)
+   return;
+
ToRecv = sGetRxCnt(cp);
if(ToRecv == 0)
return;
@@ -615,7 +623,7 @@ static void rp_do_receive(struct rp_port
CharNStat = rp_readch2(cp,sGetTxRxDataIO(cp));
ch = CharNStat & 0xff;
 
-   if((CharNStat & STMBREAK) || (CharNStat & STMFRAMEH))
+   if((CharNStat & STMBREAKH) || (CharNStat & STMFRAMEH))
ch |= TTY_FE;
else if (CharNStat & STMPARITYH)
ch |= TTY_PE;
@@ -645,6 +653,12 @@ static void rp_do_receive(struct rp_port
if ( ToRecv > RXFIFO_SIZE ) {
ToRecv = RXFIFO_SIZE;
}
+   if ((tp->t_rawq.c_cc + ToRecv > tp->t_ihiwat) &&
+   ((tp->t_cflag & CRTS_IFLOW) ||
+(tp->t_iflag & IXOFF)) &&
+   !(tp->t_state & TS_TBLOCK))
+   ttyblock(tp);
+
wRecv = ToRecv >> 1;
if ( wRecv ) {

rp_readmultich2(cp,sGetTxRxDataIO(cp),(u_int16_t *)rp->RxBuf,wRecv);
@@ -686,6 +700,7 @@ static void rp_handle_port(struct rp_por
IntMask = sGetChanIntID(cp);
IntMask = IntMask & rp->rp_intmask;
ChanStatus = sGetChanStatus(cp);
+
if(IntMask & RXF_TRIG)
if(!(tp->t_state & TS_TBLOCK) && (tp->t_state & TS_CARR_ON) && 
(tp->t_state & TS_ISOPEN)) {
rp_do_receive(rp, tp, cp, ChanStatus);
@@ -752,7 +767,7 @@ static void rp_do_poll(void *not_used)
}
}
if(rp_num_ports_open)
-   rp_callout_handle = timeout(rp_do_poll, 
+   rp_callout_handle = timeout(rp_do_poll,
(void *)NULL, POLL_INTERVAL);
 }
 
@@ -769,22 +784,23 @@ rp_attachcommon(CONTROLLER_T *ctlp, int 
 
unit = device_get_unit(ctlp->dev);
 
-   printf("RocketPort%d (Version %s) %d ports.\n", unit,
-   RocketPortVersion, num_ports);
+   printf("RocketPort%d = %d ports.\n", unit, num_ports);
rp_num_ports[unit] = num_ports;
callout_handle_init(&rp_callout_handle);
 
ctlp->rp = rp = (struct rp_port *)
-   malloc(sizeof(struct rp_port) * num_ports, M_TTYS, M_NOWAIT | 
M_ZERO);
+   malloc(sizeof(struct rp_port) * (num_ports+1), M_TTYS, M_NOWAIT 
| M_ZERO);
if (rp == NULL) {
device_printf(ctlp->dev, "rp_attachcommon: Could not malloc 
rp_ports structures.\n");
retval = ENOMEM;
goto nogo;
}
-
+/* else {
+   device_printf(ctlp->dev, "malloc'd rp_ports 
structures=%08x.\n", rp);
+   }*/
count = unit * 32;  /* board times max ports per card SG */
 
-   bzero(rp, sizeof(struct rp_port) * num_ports);
+   bzero(rp, sizeof(struct rp_port) * (num_ports+1));
oldspl = spltty();
rp_addr(unit) = rp;
splx(oldspl);
@@ -927,7 +943,7 @@ rpopen(struct tty *tp, struct cdev *dev)
ChanStatus = sGetChanStatus(&rp->rp_channel);
 
if(rp_num_ports_open == 1)
-   rp_callout_handle = timeout(rp_do_poll, 
+   rp_callout_handle = timeout(rp_do_poll,
(void *)

Re: CPU/case/disk temperature sensors for Dell PowerEdge 2850

[Doug Ambrisko]

Surer Dink writes:
| (I was told this was /one/ of the appropriate forums for this message -
| however I did not want to cross-post - if this is not the correct place,
| please let me know and I will try the other suggestions [acpi- and ports-].)

ipmitool will work fine over lan in ports.  It will not work to locally
read the values.  I have an OpenIPMI compatible driver that we use
here locally with a patched ipmitool (to fix the wrong IOCTL defines
since we care about read/write semantics).

We use it at work to read IPMI stuff on PE2850/PE850 and update the
BMC firmware via a binary tool on a PE2850.  It should work with
any IPMI device that is defined in SMBIOS.  I have not done ACPI
attachment.  I implemented the IPMI watchdog to tie into FreeBSD's
watchdog code.  I like ipmitool since Dell supplies them with
patches etc.

I probably should check it into -current.  It's not all done but
good enough to do a bunch of stuff and Tom Rhodes started a man
page for it.  I work on it as I get time or have new needs for it.

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

Re: Comtrol Rocketport UNIVERSAL PCI 32-port

[Doug Ambrisko]

Vitaliy Skakun writes:
| Hi everybody!
| 
| One problem arised:
| 
| when doing in the shell
| echo "~WS" > /dev/cuaR00
| 
| for several times as quick as I can, I get panic with the following message:
| panic: device_unbusy: called for non-busy device rp0
| 
| same thing when trying to send data to /dev/cuaR00 via JDK File streams ...
| :(((
| 
| (Some kind of barcode printers are attached to this multiport card)
| 
| Any help will be kindly accepted.

If you want you can try:

Index: rp.c
===
RCS file: /home/ncvs/src/sys/dev/rp/rp.c,v
retrieving revision 1.71
diff -u -p -r1.71 rp.c
--- rp.c4 Dec 2005 10:06:04 -   1.71
+++ rp.c26 Jan 2006 23:33:19 -
@@ -32,20 +32,23 @@
  */
 
 #include 
-__FBSDID("$FreeBSD: src/sys/dev/rp/rp.c,v 1.71 2005/12/04 10:06:04 ru Exp $");
+__FBSDID("$FreeBSD: src/sys/dev/rp/rp.c,v 1.69 2005/10/16 20:35:05 phk Exp $");
 
-/* 
+/*
  * rp.c - for RocketPort FreeBSD
  */
+#include 
 
 #include "opt_compat.h"
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -57,7 +60,7 @@ __FBSDID("$FreeBSD: src/sys/dev/rp/rp.c,
 #include 
 #include 
 
-static const char RocketPortVersion[] = "3.02";
+static const char RocketPortVersion[] = "1.0";
 
 static Byte_t RData[RDATASIZE] =
 {
@@ -116,6 +119,8 @@ Byte_t rp_sBitMapSetTbl[8] =
0x01,0x02,0x04,0x08,0x10,0x20,0x40,0x80
 };
 
+int next_unit_number = 0;
+int num_devices_found = 0;
 /***
 Function: sReadAiopID
 Purpose:  Read the AIOP idenfication number directly from an AIOP.
@@ -587,6 +592,9 @@ static void rp_do_receive(struct rp_port
unsignedint CharNStat;
int ToRecv, wRecv, ch, ttynocopy;
 
+   if (tp->t_state & TS_TBLOCK)
+   return;
+
ToRecv = sGetRxCnt(cp);
if(ToRecv == 0)
return;
@@ -615,7 +623,7 @@ static void rp_do_receive(struct rp_port
CharNStat = rp_readch2(cp,sGetTxRxDataIO(cp));
ch = CharNStat & 0xff;
 
-   if((CharNStat & STMBREAK) || (CharNStat & STMFRAMEH))
+   if((CharNStat & STMBREAKH) || (CharNStat & STMFRAMEH))
ch |= TTY_FE;
else if (CharNStat & STMPARITYH)
ch |= TTY_PE;
@@ -645,6 +653,12 @@ static void rp_do_receive(struct rp_port
if ( ToRecv > RXFIFO_SIZE ) {
ToRecv = RXFIFO_SIZE;
}
+   if ((tp->t_rawq.c_cc + ToRecv > tp->t_ihiwat) &&
+   ((tp->t_cflag & CRTS_IFLOW) ||
+(tp->t_iflag & IXOFF)) &&
+   !(tp->t_state & TS_TBLOCK))
+   ttyblock(tp);
+
wRecv = ToRecv >> 1;
if ( wRecv ) {

rp_readmultich2(cp,sGetTxRxDataIO(cp),(u_int16_t *)rp->RxBuf,wRecv);
@@ -686,6 +700,7 @@ static void rp_handle_port(struct rp_por
IntMask = sGetChanIntID(cp);
IntMask = IntMask & rp->rp_intmask;
ChanStatus = sGetChanStatus(cp);
+
if(IntMask & RXF_TRIG)
if(!(tp->t_state & TS_TBLOCK) && (tp->t_state & TS_CARR_ON) && 
(tp->t_state & TS_ISOPEN)) {
rp_do_receive(rp, tp, cp, ChanStatus);
@@ -752,7 +767,7 @@ static void rp_do_poll(void *not_used)
}
}
if(rp_num_ports_open)
-   rp_callout_handle = timeout(rp_do_poll, 
+   rp_callout_handle = timeout(rp_do_poll,
(void *)NULL, POLL_INTERVAL);
 }
 
@@ -769,22 +784,23 @@ rp_attachcommon(CONTROLLER_T *ctlp, int 
 
unit = device_get_unit(ctlp->dev);
 
-   printf("RocketPort%d (Version %s) %d ports.\n", unit,
-   RocketPortVersion, num_ports);
+   printf("RocketPort%d = %d ports.\n", unit, num_ports);
rp_num_ports[unit] = num_ports;
callout_handle_init(&rp_callout_handle);
 
ctlp->rp = rp = (struct rp_port *)
-   malloc(sizeof(struct rp_port) * num_ports, M_TTYS, M_NOWAIT | 
M_ZERO);
+   malloc(sizeof(struct rp_port) * (num_ports+1), M_TTYS, M_NOWAIT 
| M_ZERO);
if (rp == NULL) {
device_printf(ctlp->dev, "rp_attachcommon: Could not malloc 
rp_ports structures.\n");
retval = ENOMEM;
goto nogo;
}
-
+/* else {
+   device_printf(ctlp->dev, "malloc'd rp_ports 
structures=%08x.\n", rp);
+   }*/
count = unit * 32;  /* board times max ports per card SG */
 
-   bzero(rp, sizeof(struct rp_port) * num_ports);
+   bzero(rp, sizeof(struct rp_port) * (num_ports+1));
oldspl = spltty();
rp_addr(unit) = rp

Re: Parking disk drive heads

[Doug Ambrisko]

Julian Elischer writes:
| just placing an unmounted drive down on a hard table, even when
| not running, can ruin it. We lost hundreds that way at Whistle until
| we did a failure analysis. Just placing a rubber mat on the table.
| fixed it and instructing the staff to always put the drives on
| a soft surface made the problem go right away.

Not quite.  Burn-in helped more.  A few were head slaps but more was
just media that needed exercising.  It's the "lands minds" that bite you
more when it has swap or other critical data on it.  

A little historical correction.

Flash is nice but it has some issues.  Atleast dropping it isn't one!

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

Re: Checking sysctl values from within the kernel.

[Doug Ambrisko]

John Baldwin writes:
| On Friday 05 August 2005 10:50 am, Dan Nelson wrote:
| > In the last episode (Aug 05), Thordur I. Bjornsson said:
| > > If I want to check a sysctl value from within the kernel (e.g. an
| > > KLD), should I use the system calls described in sysctl(3) ?
| > >
| > > If not, what is the propper way to do so ?
| >
| > Since most sysctls are direct mappings onto integer variables in the
| > kernel, just check the variable directly.
| 
| There's also a kernel_sysctl() function available in the kernel for in-kernel 
| access to sysctls.  You might have to lookup the OID for a given name 
| yourself though.  Actually, there's a kernel_sysctlbyname() as well.

This could be a fragile interface though.  I used this scheme to do 
"soft-linking" between modules that could be kldloaded into the kernel
or static.  We called it several times every few seconds.  Over time
the system would wedge on a setjmp or something like that.  We changed
it to a function call since in a static kernel then the problem went away.

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

Re: bug in calcru()

[Doug Ambrisko]

Chris Landauer writes:
| thanx for the suggestion - the notion of computing ut just with subtraction is
| really good, since it is likely to be the largest of the three values in most
| applications, but i'm a little worried that the 1024 multiplications aren't
| large enough when tt gets really large - i'll do the math on it and report its
| (provable) range of applicability and accuracy in a few days

I understand it wouldn't be exact but it will be better then the 100%
typical use ie. (10% system, 20% interrupt and 70% user).  With the
stuff to ensure it is monitonically increasing you can get "wacky"
results so IMHO it will never be right but "good enough"  Atleast that
is what I recall when I tested this stuff out a long time ago.
The assumption with this calculation is that st & it tend to be
small compared to tt so the 1024 X shouldn't overflow much.
 
| > Doug Ambrisko <[EMAIL PROTECTED]> wrote
| > ...
| > /* Subdivide tu. try to becareful of overflow */
| > su = tu * (st * 1024 / tt) / 1024;
| > iu = tu * (it * 1024 / tt) / 1024;
| > uu = tu - (su + iu);
| > ...

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

Re: bug in calcru() in kernel: integer overflow computing user time

[Doug Ambrisko]

Chris Landauer writes:
| 
| hihi, all -
| 
| well, i have an "almost" fix for the problem - read on, ...
| (this is for discussin before send-pr submission)
| 
| description
| 
|   in FreeBSD 5.3-RELEASE (and 5.2.1R, and 5.1R),
|   in file /usr/src/sys/kern/kern_resource.c,
|   lines 657-750 define a function calcru(),
|   and there is a bug in that function -
| 
|   line 713 in that file is
| 
|uu = (tu * ut) / tt,
| 
|   which is trying to compute a proportion (since ut<=tt) - the problem
|   is that for my application, the values of tt and ut are very large and
|   the value of the intermediate product overflows, leading to incorrect
|   values (i reported the symptoms to freebsd-hackers and a very helpful
|   description and localization of the problem to calcru() was provided
|   by peter jeremy, who also wrote that it is a very old, but only partly
|   known, problem)
| 
| repetition
| 
|   use time in csh or /usr/bin/time or getrusage() to time any program
|   that takes more than a week to run
| 
| fix (almost)
| 
|   it turns out that this problem can be (partly) fixed by replacing that
|   one line above with the following lines:
| 
|   /* we know 0 <= ut <= tt and 1 <= tt */
|   if (tu >= tt)
|   {
|   **whatever type they need to be** q, r;
|   q = tu / tt;
|   r = tu % tt;
|   uu = (q * ut) + (r * ut) / tt;
|   }
|   elseuu = (tu * ut) / tt
| 
|   this change does not solve all the arithmetic problems (especially
|   when ut is very large), and a similar change is needed for system
|   time, computing su in line 714 of the file, but it suffices for me -
| 
|   analysis (yup, proof that it should work 8-)) -
| 
|   i expect that all of these counters are increasing throughout the life
|   of the process -
|   tu is total time in microseconds
|   ut is user 128hz ticks
|   tt is total 128hz ticks
|   i assume therefore that
|   tu ~ tt * 10^6/128
|   strictly because of the clock rates
|   (machines with other kinds of clock rate ratios will need a different
|   analysis, but the same idea should work there, too) -
| 
|   in my case ut ~ tt, so we see overflow in the old computation when
|   tu * ut >= 2^64
|   tt^2 * 10^6/128 >= 2^64
|   tt * 10^3/8*sqrt(2) >= 2^32 ~ 4 * 10^9
|   tt >= 32*sqrt(2)*10^6,
|   which is about
|   sqrt(2)*10^6 / 4 ~ 3.54*10^5 seconds,
|   or
|   ~ 98 hours
|   (this is the phenomenon i observed)
| 
|   in the new computation offered above, since we know that
|   ut <= tt,
|   we also know that
|   uu <= tu,
|   and
|   (q * ut) <= uu,
|   so there can be no overflow in the (q * ut) term -
|   therefore, this changed code will overflow only when r is large
|   r ~ tt,
|   and then only when
|   r * ut >= 2^64
|   tt^2 >= 2^64
|   tt >= 2^32,
|   which is about
|   ~ 2^25 seconds
|   ~ 9300 hours
|   ~ 388 days
|   (i can live with that for now)
| 
|   for everyone else, it adds the one test in the if statement to every
|   call to calcru() (or two, if system time is similarly fixed) -
|instrumentation is costly, and correct instrumentation is
|   even more costly, but it's worth it, every time, to get the right
|   answer 
| 
|   i'm about to try it out this week - i will report the results when i
|   get some data (which will be a few weeks)
| 
|   i'm thinking about how to solve the problem correctly for really
|   long-running programs, but it's all pretty special case ugly so far

This is my fix:

Index: kern_resource.c
===
RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/kern_resource.c,v
retrieving revision 1.55.2.5
diff -u -p -r1.55.2.5 kern_resource.c
--- kern_resource.c 3 Nov 2001 01:41:08 -   1.55.2.5
+++ kern_resource.c 26 Jan 2005 19:03:27 -
@@ -552,10 +552,10 @@ calcru(p, up, sp, ip)
tu = ptu;
}
 
-   /* Subdivide tu. */
-   uu = (tu * ut) / tt;
-   su = (tu * st) / tt;
-   iu = tu - uu - su;
+   /* Subdivide tu. try to becareful of overflow */
+   su = tu * (st * 1024 / tt) / 1024;
+   iu = tu * (it * 1024 / tt) / 1024;
+   uu = tu - (su + iu);
 
/* Enforce monotonicity. */
if (uu < p->p_uu || su < p->p_su || iu < p->p_iu) {

If people like it I can commit it.  It works for us.  We had problems with
this as well.  It's pretty simple fix.  I used 1k since usage of this
tends to be % so rounding should effect that much.

Doug A.

Re: freebsd problem: Cannot detect Hard Disk (SATA) RELENG_4

[Doug Ambrisko]

Julian Elischer writes:
| Doug, could you comit your patchsets to RELENG_4?

I could but have not been given an okay from RE.  What I've proposed
to do before is commit the base HW support without my RAID and other
enhancements.  This is essentially taking the stuff from 5-current
HW only bits to 4.X.  That would let people use the HW.  Then
fix some ATA/FreeBSD bugs so machines don't hang and panic.  I don't 
plan to bring in my RAID enhancements since then if people upgrade
to 5.X/6.X they will lose functionality.

Very little of the core ata code in 4.X has to change since I have
compatibility macros to make it transparent.  The bug fixes tweak some
of the ata core code.

My employer would give me time to do this.

| Doug Ambrisko wrote:
|
| >Dmitry Morozovsky writes:
| >| On Sat, 22 Jan 2005, Dmitry Morozovsky wrote:
| >|
| >| DM> DA> There is:
| >| DM> DA>http://www.ambrisko.com/doug/ata/ata_stable_sata_7.patch
| >| DM> DA> for 4.10.  That deals with Intel and Promise SATA stuff and
| >| DM> DA> ata-raid fixes/enhancements.  It deals with legacy and enhanced mod
es
| >| DM> DA> for Intel SATA.
| >| DM> DA>
| >| DM> DA> A bunch of people have installed it and are using this.  A bunch of

| >| DM> DA> our customers use it via our appliance.
| >| DM>
| >| DM> Wow, thanks! BTW, it seems some sio patches are slipped in by accident?
| >|
| >| BTW2: here is small patch to support Promise SATA PDC20376 controller found
 on
| >| our Albatron MB
| >
| >[ Attachment, skipping... ]
| >
| >Thanks for the patch.  It will go in the next patch set.  I should make
| >a new one fairly soon since I initially prevented the Promise stuff from
| >using PIO but found out we need PIO for crash dumps.  I need to test
| >the PIO change.  It was pretty trivial since there is already stuff
| >to deal with this.

Actually it looks like I did test it a while back so it should be ready
to go if someone is interested in testing it to make sure the PCI ID's
are right (Dmitry?).

It's at:
http://www.ambrisko.com/doug/ata/ata_stable_sata_8.patch

Thanks,

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

Re: Two keyboards

[Doug Ambrisko]

Julian Elischer writes:
| David Scheidt wrote:
| > Julian Elischer wrote:
| >> Bram Van Steenlandt wrote:
| >>> For a pos system I am working on I need support for two keyboards
| >>> (actually one keyboard(ps/2) and one scanner(usb)).
| >>
| >> you can already do this..
| >> what makes you call the scanner a keyboard?
| >
| > Proabably, because it acts like one?  I don't know about the USB ones,
| > but PS/2 scanners generated keysym data, just like a real keyboard. The
| > idea of the hardware people is "They've already got a keyboard, they
| > take input from it, so let's make the scanner a keyboard!"  It makes it
| > easy to use a barcode reader with an application that doesn't know
| > anything about barcodes, barcode scanners or the like.
|
| the barcode scanners we use just produce a 9600 baud serial stream.

The PS/2 and USB versions I've used appear as a keyboard and just "key in"
the data like a keyboard.  To get data from the USB I just did a
"cat /dev/ukbd0" for scans.  They've had built-in wdges.  Makes it
really easy to integrate into systems.

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

Re: freebsd problem: Cannot detect Hard Disk (SATA)

[Doug Ambrisko]

Dmitry Morozovsky writes:
| On Sat, 22 Jan 2005, Dmitry Morozovsky wrote:
| 
| DM> DA> There is:
| DM> DA>   http://www.ambrisko.com/doug/ata/ata_stable_sata_7.patch
| DM> DA> for 4.10.  That deals with Intel and Promise SATA stuff and 
| DM> DA> ata-raid fixes/enhancements.  It deals with legacy and enhanced modes
| DM> DA> for Intel SATA.
| DM> DA> 
| DM> DA> A bunch of people have installed it and are using this.  A bunch of 
| DM> DA> our customers use it via our appliance.
| DM> 
| DM> Wow, thanks! BTW, it seems some sio patches are slipped in by accident?
| 
| BTW2: here is small patch to support Promise SATA PDC20376 controller found 
on 
| our Albatron MB

[ Attachment, skipping... ]

Thanks for the patch.  It will go in the next patch set.  I should make
a new one fairly soon since I initially prevented the Promise stuff from
using PIO but found out we need PIO for crash dumps.  I need to test
the PIO change.  It was pretty trivial since there is already stuff
to deal with this.

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

Re: freebsd problem: Cannot detect Hard Disk (SATA)

[Doug Ambrisko]

Scott Long writes:
| On Thu, 20 Jan 2005, yoke an wrote:
| > My motherboard is using an ICH5 southbridge and your suggestion is works.
| > As you said, my sata disks appear to be normal IDE drives but it is not
| > running on Raid mode. Currently I'm having 2 HDD, if I do this option,
| > it cannot syn with another HDD. Any better suggestion?
| 
| This is the best that you can get under FreeBSD 4.x.  If you need access
| to both IDE channels and SATA at the same time, you'll have to use FreeBSD
| 5.x.

There is:
http://www.ambrisko.com/doug/ata/ata_stable_sata_7.patch
for 4.10.  That deals with Intel and Promise SATA stuff and 
ata-raid fixes/enhancements.  It deals with legacy and enhanced modes
for Intel SATA.

A bunch of people have installed it and are using this.  A bunch of 
our customers use it via our appliance.

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

Re: Sudden Reboots

[Doug Ambrisko]

Jim Durham writes:
[ Charset ISO-8859-1 unsupported, converting... ]
| On Friday 01 October 2004 12:36 pm, Doug Ambrisko wrote:
| > Jim Durham writes:
| > | I have had this problem now with at least 3 FreeBSD servers over a period
| > | of about 2 years. I had put it down to some hardware problem but it seems
| > | to be too much of a coincidence with 3 different machines doing the same
| > | thing.
|
| > How much memory are in these system?. 
| The Dell is a Dual Xeon 2650 with 2gb or Ram. The ISP's box has only 256 megs 
| or ram and the business customer's box has 512.

That shouldn't be much of an issue then
 
| > If you have 3G or more you end 
| > up with very little left for the kernel in the 2G space
| 
| Can you elaborate on why this is?

I did somewhat here:

| > If you only have a few meg. left it doesn't take many processes to
| > fork etc. then you machine blows up.  The bge driver for example takes
| > 4M each for the jumbo packet handling.  You can recover some of this
| > memory via loader.conf tunables or bump KVA_PAGES in your kernel
| > config file.  Still once this memory is put into the zone allocator
| > (vmstat -z) in -stable it is gone from the system even if that bucket
| > isn't fully used or needed :-(

Most of these zones scale based on total memory which.

| What would you expect to see in the logs on such a scenario? I'm surprised to 
| see nothing.

Unless you have kernel dumps and savecore settup you will miss the panic.
When a system panics it can't right our to /var/log/*

| > Ironically the more memory you put in a system the less you can do with
| > the system!
| >
| > A lot of people are starting to run into this problem since large memory
| > machines are cheap.
| 
| Well, I don't think 2gb is large by your standards?

No it isn't.  3-4G machines start to hit this.  Also if you bump up things 
like mbufs and cluster you start to hit this limit.

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

Re: Sudden Reboots

[Doug Ambrisko]

Jim Durham writes:
| I have had this problem now with at least 3 FreeBSD servers over a period of 
| about 2 years. I had put it down to some hardware problem but it seems to be 
| too much of a coincidence with 3 different machines doing the same thing.
| 
| The first time was when I put 4.5-RELEASE on a brand new Dell Poweredge 2650. 
| I ran it on the bench for a week or so, then decided all was well and put it 
| in the server rack and started doing the company's email service on it. After 
| a few weeks, it suddenly would 'reboot' for no apparent reason. No log 
| entries, nothing at all except the usual stuff in /var/log/messages about '/ 
| was not unmounted correctly', etc. Just like you had pulled the power plug.

How much memory are in these system?.  If you have 3G or more you end
up with very little left for the kernel in the 2G space.  You can
monitor how much space you have left by compile a debug kernel then
as root:
gdb -k kernel.debug /dev/mem
print ((unsigned int)virtual_end)-((unsigned int)kernel_vm_end)
This should probably be made into a sysctl so it can be montored 
better.

If you only have a few meg. left it doesn't take many processes to
fork etc. then you machine blows up.  The bge driver for example takes
4M each for the jumbo packet handling.  You can recover some of this
memory via loader.conf tunables or bump KVA_PAGES in your kernel
config file.  Still once this memory is put into the zone allocator
(vmstat -z) in -stable it is gone from the system even if that bucket 
isn't fully used or needed :-(

Ironically the more memory you put in a system the less you can do with
the system!

A lot of people are starting to run into this problem since large memory
machines are cheap.

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

Re: Intel i8xx watchdog driver

[Doug Ambrisko]

Don Bowman writes:
| The Intel ICH3 (and probably all) has the feature it can
| issue an SMI on first count-down to 0, then a hard reset
| on 2nd. What we did was implement an SMM handler (in bios)
| that, when called due to watchdog, issued an NMI and did
| a return from smm.
| In FreeBSD, an NMI handler caught this (sometimes :),
| poke around to send a bit of data out to serial, moved the
| timer to the maximum value without reseting it, and then
| called panic [after mucking with cpl etc to pretend to
| own all locks :]
| If the NMI handler didn't get run, the hardware counted
| to 0 again and reset.
| If the NMI handler did get run, and then wedged somehow
| in the panic or whatever, the hardware counted to 0,
| and the system reset.
| If all worked well, you got a core, but at a minimum
| the system reset, and usually you got at least the
| serial output of some of the 'why'.
| 
| The SMI is non-maskable (and higher priority than NMI).

That sounds pretty cool.  There was some bits in the ICH that
prevented an NMI to get to the CPU unless set a certain way.
I was generating an NMI via the PCI but.  BTW you can do the
paper clip trick on PCI.  The ICH seemed to be only one shot so
it de-bounced it.  I could get multiple on a CPU NMI pin. 

How hard is to setup and trap SMI via a FreeBSD only solution?

I haven't really looked much at that area but sounds useful.

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

Re: Intel i8xx watchdog driver

[Doug Ambrisko]

Scott Long writes:
| In reading the code, it appears that it is indeed an ICHx service and
| not limited to just i8xx chipsets.  I have a few issues with how the
| probe and attach are done, and I'm addressing these in a private mail
| right now.  It's funny that I was reading the Intel ICH5 docs last night
| and didn't come across this feature at all.

I haven't looked at the code but have worked with this feature.
 
| I'm not sure if I like the idea of auto-reboot on second expire, unless
| it is configurable (i.e. you can turn that feature off depending on the
| situation).  I understand it's purpose though.

Note sure what you mean by that.  The second expire means you didn't
catch a hang so you must be dead.  If the system is dead then you want
it to reboot.  You do need a way to cancel this and I think PHK API
allowed that.  I used his early Soekris WD a while back.  The real 
purpose of the TCO timer & SIS timer is that a BIOS can set aggressive 
timings and back off if the systems fails to boot.  This way a user doesn't
have to tune the BIOS.  A lot of chipsets have it and I've seen it
in some Winbond Super I/O chips.  However, we can use it for free for
our purposes :-)
 
| > A nice concept would be to have a SW watchdog based on the clock tickle
| > the HW watchdog.  If the SW watchdog goes off you get a panic.
| > 
| > Interesting caveats are having the watchdogs going off while in kgdb/ddb.
| 
| Talking with PHK about this now.  There seems to be a growing need for a
| mechanism that can inform registered listeners that DDB is about to be
| entered.  It's just a random thought in my brain right now, need more
| time to flesh it out.

Perfect.

consmute is another.  What's the point of entering DDB is the console
is muted :-(  I have code so if DDB or panic is entered then consmute
is disabled for that period.  Basically I just switched consmute into
a function that can be called from the DDB/panic routines.  Now there
are reasons to really mute the console no matter what. 

It would be cool if we could layer all this.  One reason I did a HW
watchdog to enforce a SW watchdog is that various HW watchdogs have
different time ranges.  The SW watchdog can easily run within that
range.  Then a user-land app can set a long SW watchdog and not
have to worry about if it get starved for a while triggering a false
reboot.  For example who cares if the watchdog is set for 15 minutes.
That is better then having to drive to a co-lo. etc. on a Sunday morning :-(
Your chance for a false trigger is greatly reduced.

| > I have code for the SIS 630 chipset that I can give to anyone interested.
| 
| More support it wonderful!  I don't have any hardware to test it on, though.

I don't have direct access to HW anymore but have working code.  I've been
watching the HW watchdog stuff and can add it once some of these issues
have been resolved.

All of my current code is quick hacks to get around immediate issues but
it is in production.

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

Re: Intel i8xx watchdog driver

[Doug Ambrisko]

Scott Long writes:
| Wm. Daryl Hawkins wrote:
| > I've written a driver for the Intel i8xx TCO watchdog timer for both 
| > FreeBSD-CURRENT and FreeBSD-STABLE.  
|
| This is wonderful.  I'd be happy to test it and shepherd it in.  Does it
| support the intel 750x chips also?

All ICH chips that I've touched support this with the device ID updated
as needed.  FYI there is a new watchdog device in the 6300ESB.  Not
sure if it is in prior ICH chips.  It is interesting in that during the
first expire it will generate and interrupt then it will reboot on the
next expire.  So if you have an ICH then you can use it.

A nice concept would be to have a SW watchdog based on the clock tickle
the HW watchdog.  If the SW watchdog goes off you get a panic.

Interesting caveats are having the watchdogs going off while in kgdb/ddb.

Caveat to the ICH TCO timer is that if the speaker output out of the ICH 
has a pull up resistor on it then the TCO reset is disabled and will not
reset the system.  I ran into this on a motherboard at a prior company.
You cannot via SW disable this feature :-(

I have code for the SIS 630 chipset that I can give to anyone interested.

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

Re: 4.9 kernel panics on a poweredge 2650

[Doug Ambrisko]

Bogdan TARU writes:
| 
|   Hi Hackers,
| 
|  Ok, now some more infos about my problem:
| 
| We have 3 identical webservers (as hw configuration), and the same
| kernel and applications running on all three. They get mostly the same
| traffic (dns round-robined). They all run 4.9-RELEASE. I have
| experienced repetable crashes on all three, so there is no problem
| with the hardware (or the possibility of such a thing is too small). 
| 
|  I have come to think that the problem is with the kernel memory
| space, which is too low. I have compiled the kernel from Generic, by
| performing the following modifications:
| 
| - maxusers set to 128
| - activated SMP (the cpus are HTT-compatible)
| - kva_pages set 256 (each box has 2GB of ram and 2Gb of swap)
| - PMAP_SHPGPERPROC=401 (for apache)
| - ACCEPT_FILTER_DATA and ACCEPT_FILTER_HTTP
| - removed unnecessary drivers from the kernel
| 
|  /etc/sysctl.conf looks like:
| 
| 
| net.inet.tcp.msl=100
| net.inet.tcp.blackhole=1
| # Hyperthreading
| machdep.cpu_idle_hlt=1
| 
| kern.ipc.somaxconn=4096
| kern.maxfiles=65535
| vfs.vmiodirenable=1
| kern.ipc.shm_use_phys=1
| net.inet.tcp.sendspace=16384
| 
| 
|  The boxes run w/o a problem for about 2-3 days, after which they
| panic with 'page not present' in different processes (sshd, httpd,
| etc). I guess the real reason for this is the low value for kvm_free:
| 
| 
| (web1)[~] sysctl -a | grep vm.kvm
| vm.kvm_size: 1069543424
| vm.kvm_free: 4190208

This isn't good you have about 4M of kernel memory left resulting in
your panic.  A quick fix to try is to bump up kva_pages to 384.  Just
recompile the kernel with that and install.  There are some undocumented/
poorly sysctl that can free up some memory.  I should put something together
but I'm working on some other issues right now.  For some hints
look at vmstat -z and look at how much memory you use.  Note that
the limit can be read as "allocated and gone from the system to be used only
by this zone".  Trim down some things that are huge but not used much.
Now the tuneable to do that via loader.conf can be a challenge to derive.

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

Re: specifying RAM size at boot?

[Doug Ambrisko]

Daniel Ellard writes:
| I thought this was configurable by setting a variable in
| /boot/loader.conf and rebooting, but I haven't been able to find the
| right variable(s).  (someone suggested MAXMEM, but this doesn'
| seem to do anything at all.)

I think it is
hw.physmem=

I used it at a prior company.

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

Re: Console serial speed

[Doug Ambrisko]

Russell Cattelan writes:
| On Wed, 2003-07-30 at 21:58, Doug Ambrisko wrote:
| > Russell Cattelan writes:
| > | How does one set the serial speed of the console.
| > | I changed the boot loader speed to 57600 in make.conf
| > | but the kernel seems to chose random speeds each time 
| > | it's booted.
| > | Sometimes it's 9600 sometimes it 115200 other times 
| > | it's 38400.
| > | 
| > | Note this is on 5.x current
| > 
| > You might want to check sys/isa/sio.c in function siocngetspeed.
| > I comment out the "return (rclk / (16UL * divisor));" on some of my
| > stable boxes.  I've seen a few motherboards that result in a messed
| > up console if I don't do it (ie. wrong speed).
|
| I changed the return val to be CONSPEED.
| The machine now boots with the console speed correctly set
| to 57600
| 
| Thanks... suppose a proper fix would be good :-)

I'm not sure what a proper fix would be.  We try to read the speed out
of the UART and it fails to get what it was set to.  This could be
broken hardware etc.  Personally I haven't had the motivation to figure
out why some machines fail and I just wacked the code to make it work
so I can actually fix the real problem I was working on!

Maybe some #define that could over-ride everything and just set might
be a fix for broken HW.

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

Re: Console serial speed

[Doug Ambrisko]

Russell Cattelan writes:
| How does one set the serial speed of the console.
| I changed the boot loader speed to 57600 in make.conf
| but the kernel seems to chose random speeds each time 
| it's booted.
| Sometimes it's 9600 sometimes it 115200 other times 
| it's 38400.
| 
| Note this is on 5.x current

You might want to check sys/isa/sio.c in function siocngetspeed.
I comment out the "return (rclk / (16UL * divisor));" on some of my
stable boxes.  I've seen a few motherboards that result in a messed
up console if I don't do it (ie. wrong speed).

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

Re: Interview in Byte with Chris Sontag/SCO and FUD relating toBSDsettlement agreement

[Doug Ambrisko]

Josef Grosch writes:
| On Wed, Jun 18, 2003 at 12:01:38PM +0930, Greg 'groggy' Lehey wrote:
| > On Tuesday, 17 June 2003 at  6:08:06 -0600, M. Warner Losh wrote:
| > > In message: <[EMAIL PROTECTED]>
| > > Martin Heller <[EMAIL PROTECTED]> writes:
| > >> Will the FreeBSD project issue an offical statement relating to these
| > >> allegations?
| > >> What will happen to FreeBSD if SCO aims at the BSD projects. Could SCO
| > >> revoke the Settlement Agreement and pursue a court ruling?
| > >
| > > This is not an official statement from the project.
| > >
| > > There is not now, nor has there *EVER* been *ANY* System V code in
| > > BSD.  *EVER*.  NEVER.  NEVER.  NEVER.
| > 
| > Agreed.  The fact that Sontag even mentions this detracts further from
| > an already very stupid interview.  I've put an analysis at
| > http://.lemis.com/grog/sco-sontag-16jun2003.html.
| 
| Your site seems not to be responding. Do you need a mirror?

Nope he needs one less "w" as in:
http://www.lemis.com/grog/sco-sontag-16jun2003.html

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

Re: Realtek

[Doug Ambrisko]

[EMAIL PROTECTED] writes:
[ Charset ISO-8859-1 unsupported, converting... ]
| >   5000 packets transmitted, 94 packets received, 98% packet loss
| >   round-trip min/avg/max/stddev = 0.156/0.337/0.605/0.159 ms
| > So I'm not see much difference.
| 
| are you sure it's not because of this:
| 'ping: sendto: No buffer space available'?

No such messages appeared.

Doug A.

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

Re: redirect everything to socks5

[Doug Ambrisko]

Keith Pitcher writes:
| Living in rural slow connection land, I've been playing around with
| satellite Internet. The problem is the company only has Win
| drivers. (Linux driver is in the works, but no plans to open source it, will be
| released as a binary - the bastards)
| 
| Anyhow, to get the download speed of the satellite it uses a http proxy and
| a socks5 proxy. This works fine for things that allow proxies or socks. But
| there are a lot of things that don't support it.
| 
| Is there a way to "socksify" everything my freebsd box does, so no
| matter what I do, I can just point it to the socks machine and it works?

"runsocks" works for most apps as long as they use a shared libc and
don't link to libc_r.  If they use libc_r you need to make a libc_r shim
for that.  Also a libc shim for Linux would be needed for Linux apps
that use a shared libc.

Now I did find that Netscape and runsocks/socks gateway had trouble with
https type transfers.  Doing a packet capture it would do an unencrupted
request, fail and then reture with an encrypted request.  This confused
the state of the proxied connection.
 
| Would also be handy to have a way to "socksify" the box when it acts as a
| network gateway, so I'd only have one really strangely configured machine and
| the rest would be normal.

You might be able to do a nat like thing to a socks proxy via divert.

Another work-around is to run a "gateway/router" thing on a Windows box
and then point your machine to that gateway and it would socksify the
transfer to the other network.  This actually works well except for 
depending on a Windows box.

Not knowing enough about these things but slightly interested in DirectWay
for our trailer I've read about interfaces that go to Ethernet or 802.11b.
I wonder if these can automatically do that since I don't use Windows I
would need that type of solution.

Doug A.

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

Re: Realtek

[Doug Ambrisko]

Wes Peters writes:
| Or you can cheat and use a SmartBits-2000 like I did.  It can send exactly 
| 148,800 packets per second, with very precise timing of the inter-packet 

Soon we should be getting an Ixia.

| So it seems to keep up reasonably well, but this is misleading.  Use -l to 
| force the packets out as quickly as the card can generate them:
| 
| -bash-2.05b$ sudo ping -i 0.01 -c 5000 -l 5000 204.68.178.2
| ...
| 64 bytes from 204.68.178.2: icmp_seq=92 ttl=128 time=14.855 ms
| 64 bytes from 204.68.178.2: icmp_seq=93 ttl=128 time=14.880 ms
| 64 bytes from 204.68.178.2: icmp_seq=4424 ttl=128 time=17.308 ms
| 
| --- 204.68.178.2 ping statistics ---
| 5000 packets transmitted, 95 packets received, 98% packet loss
| round-trip min/avg/max/stddev = 11.929/14.520/17.308/0.682 ms
| 
| Wow.  The receiving side handled the first 93 packets and then rolled 
| over, recovering for only the last packet.  (Look at the icmp_seq 
| numbers.)  FreeBSD behaves similarly, but try the test on your own.  ;^)

I don't see any difference between the rl and fxp tests using the same
originating machine and dest machine.  The dest machine has both rl and fxp

the rl0 results (ping -i 0.01 -c 5000 -l 5000 ):
  PING 192.168.99.2 (192.168.99.2): 56 data bytes
  64 bytes from 192.168.99.2: icmp_seq=0 ttl=64 time=0.499 ms
  64 bytes from 192.168.99.2: icmp_seq=1 ttl=64 time=0.467 ms
  64 bytes from 192.168.99.2: icmp_seq=2 ttl=64 time=0.461 ms
  64 bytes from 192.168.99.2: icmp_seq=3 ttl=64 time=0.458 ms
  64 bytes from 192.168.99.2: icmp_seq=4 ttl=64 time=0.484 ms
  64 bytes from 192.168.99.2: icmp_seq=5 ttl=64 time=0.502 ms
  64 bytes from 192.168.99.2: icmp_seq=6 ttl=64 time=0.500 ms
  64 bytes from 192.168.99.2: icmp_seq=7 ttl=64 time=0.498 ms
  64 bytes from 192.168.99.2: icmp_seq=8 ttl=64 time=0.514 ms
  64 bytes from 192.168.99.2: icmp_seq=9 ttl=64 time=0.508 ms
  64 bytes from 192.168.99.2: icmp_seq=10 ttl=64 time=0.503 ms
  64 bytes from 192.168.99.2: icmp_seq=11 ttl=64 time=0.519 ms
  64 bytes from 192.168.99.2: icmp_seq=12 ttl=64 time=0.514 ms
  64 bytes from 192.168.99.2: icmp_seq=13 ttl=64 time=0.512 ms
  64 bytes from 192.168.99.2: icmp_seq=14 ttl=64 time=0.523 ms
  64 bytes from 192.168.99.2: icmp_seq=15 ttl=64 time=0.520 ms
  64 bytes from 192.168.99.2: icmp_seq=16 ttl=64 time=0.516 ms
  64 bytes from 192.168.99.2: icmp_seq=17 ttl=64 time=0.525 ms
  64 bytes from 192.168.99.2: icmp_seq=18 ttl=64 time=0.522 ms
  64 bytes from 192.168.99.2: icmp_seq=19 ttl=64 time=0.519 ms
  64 bytes from 192.168.99.2: icmp_seq=20 ttl=64 time=0.532 ms
  64 bytes from 192.168.99.2: icmp_seq=21 ttl=64 time=0.527 ms
  64 bytes from 192.168.99.2: icmp_seq=22 ttl=64 time=0.523 ms
  64 bytes from 192.168.99.2: icmp_seq=23 ttl=64 time=0.535 ms
  64 bytes from 192.168.99.2: icmp_seq=24 ttl=64 time=0.531 ms
  64 bytes from 192.168.99.2: icmp_seq=25 ttl=64 time=0.529 ms
  64 bytes from 192.168.99.2: icmp_seq=26 ttl=64 time=0.540 ms
  64 bytes from 192.168.99.2: icmp_seq=27 ttl=64 time=0.535 ms
  64 bytes from 192.168.99.2: icmp_seq=28 ttl=64 time=0.532 ms
  64 bytes from 192.168.99.2: icmp_seq=29 ttl=64 time=0.541 ms
  64 bytes from 192.168.99.2: icmp_seq=30 ttl=64 time=0.538 ms
  64 bytes from 192.168.99.2: icmp_seq=31 ttl=64 time=0.533 ms
  64 bytes from 192.168.99.2: icmp_seq=32 ttl=64 time=0.540 ms
  64 bytes from 192.168.99.2: icmp_seq=33 ttl=64 time=0.553 ms
  64 bytes from 192.168.99.2: icmp_seq=34 ttl=64 time=0.548 ms
  64 bytes from 192.168.99.2: icmp_seq=35 ttl=64 time=0.544 ms
  64 bytes from 192.168.99.2: icmp_seq=36 ttl=64 time=0.180 ms
  64 bytes from 192.168.99.2: icmp_seq=37 ttl=64 time=0.175 ms
  64 bytes from 192.168.99.2: icmp_seq=38 ttl=64 time=0.185 ms
  64 bytes from 192.168.99.2: icmp_seq=39 ttl=64 time=0.180 ms
  64 bytes from 192.168.99.2: icmp_seq=40 ttl=64 time=0.206 ms
  64 bytes from 192.168.99.2: icmp_seq=41 ttl=64 time=0.204 ms
  64 bytes from 192.168.99.2: icmp_seq=42 ttl=64 time=0.214 ms
  64 bytes from 192.168.99.2: icmp_seq=43 ttl=64 time=0.208 ms
  64 bytes from 192.168.99.2: icmp_seq=44 ttl=64 time=0.221 ms
  64 bytes from 192.168.99.2: icmp_seq=45 ttl=64 time=0.218 ms
  64 bytes from 192.168.99.2: icmp_seq=46 ttl=64 time=0.228 ms
  64 bytes from 192.168.99.2: icmp_seq=47 ttl=64 time=0.225 ms
  64 bytes from 192.168.99.2: icmp_seq=48 ttl=64 time=0.236 ms
  64 bytes from 192.168.99.2: icmp_seq=49 ttl=64 time=0.233 ms
  64 bytes from 192.168.99.2: icmp_seq=50 ttl=64 time=0.242 ms
  64 bytes from 192.168.99.2: icmp_seq=51 ttl=64 time=0.160 ms
  64 bytes from 192.168.99.2: icmp_seq=52 ttl=64 time=0.156 ms
  64 bytes from 192.168.99.2: icmp_seq=53 ttl=64 time=0.166 ms
  64 bytes from 192.168.99.2: icmp_seq=54 ttl=64 time=0.161 ms
  64 bytes from 192.168.99.2: icmp_seq=55 ttl=64 time=0.185 ms
  64 bytes from 192.168.99.2: icmp_seq=56 ttl=64 time=0.199 ms
  64 bytes from 192.168.99.2: icmp_seq=57 ttl=64 time=0.196 ms
  64 bytes from 192.168.99.2: icmp_seq=58 ttl=64 time=0.193 ms
  64 bytes from 192.168

Re: Realtek

[Doug Ambrisko]

Wes Peters writes:
| On Monday 10 March 2003 08:47, Doug Ambrisko wrote:
| > Hmm, I thought I had said "benchmark in your environment".  We have a
| > closed box that is sort-of a router and a bridge.  So your only inputs
| > is really network traffic.  That is what we tune the box for.  So it
| > would be interesting to see you kill it in 1s.  Again our issue is PCI
| > bus.
| 
| Flood it with wire speed 64-byte packets and drive it into receive 
| interrupt livelock.  Yup, the PCI bus is (most of) the problem here too.

Can't reproduce it.  Maybe they fixed it in the 8100L rev.?

I tried a ping -f -s 22 to hit it with 64 byte packets.  I also had
traffic going to the onboard gig and it wasn't impacted (granted the
source was a 100bit link tied to the gig link).

I'm running variants of -stable (FreeBSD 4.7 and later) on this hardware.

Doug A.

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

Re: Realtek

[Doug Ambrisko]

Wes Peters writes:
| On Friday 07 March 2003 09:16, Doug Ambrisko wrote:
| You did something truly bizarre.  I've tested similar cards on many 
| machines ranging from K6-2 400MHz to P4 2.4GHz and the RealTek 
| performance has always been at or near the bottom of the heap.  On the 
| slower processors, the overhead of aligning packets shows heavily, but it 
| can be noticed on any system.

Depends on what your systems is doing.  We are PCI bus limited.
 
| A number of the chips folded into the dc(4) driver are horrible and 
| perform right down there with the RealTek, but a few are fairly good.

Agreed.  We've tested the common 21143 and some clones.  We also ran
the tests a few times to the the dc(4) chip to get the TX delays 
right adjusted so they don't have FIFO under-runs since that adjustment
kill performance.
 
| The 3com 3c905s are generally quite good using the xl(4) driver, as are 
| the Intel EEPro's using fxp.  I've read of others struggling with both 
| but never encountered this myself.  I tend to be quite conservative about 
| throwing random versions of FreeBSD at systems, though, and many of those 
| complaints come from people at various points on -stable, rather than a 
| known release point.

We've had good success with the fxp(4) chips except for a strange bug
on an onboard motherboard version.  There seems to be a bug in the
eeprom setting for it that I patch in the fxp(4) driver.  Unfortunately
I'm guess at the correction since we haven't been able to get the 
definition of that register.  Since Intel sets to that value and makes
our bug go away we just do it.  Makes me nervous though.

| > So I'd say given a sufficiently fast CPU and memory the Realteks work
| > pretty darn good. 
| 
| For a sufficient engine RPM, that escort will do 85 MPH in first gear, 
| too.  ;^)

Yep, and if you never have to turn a corner and the engine can handle
it then it is okay.  Our '87 Porsche 911 can't turn in a "normal" sense 
very fast due to cronic understeer.  However, with a rear-weight bias
it spins very fast.  So to turn fast you just spin the car into the 
direction you need, gas it to stop the spin and off you go.  Side 
benefit it that you don't need to brake as much going into a corner
since when you are going side ways you are braking so you just factor that
in.

Is a Porsche 911 a performance car?  In the right hands it is otherwise
it's going backwards out of a corner which can be an interesting feeling!
Sounds like a Corvair.
 
| > To date we haven't had any trouble with them and we've shipped a bunch.
| 
| Give me 1 second and I can easily bring any of your systems to their 
| knees, regardless of which cards you have installed.  Everything is 
| relative.  Were you watching the system load while performing your 
| testing?  Was the cpu doing anything but routing?  Is it required to for 
| your application?  These and many others are all important questions, and 
| tend to have different answers for every application.  For a desktop 
| workstation with undemanding network application requirements (email, web 
| browsing, occasional software updates) RealTek or any other card that 
| successfully attach to the network and correctly autonegotiate with your 
| hub (shudder) or switch is fine.  Even a RealTek.  ;^)

Hmm, I thought I had said "benchmark in your environment".  We have a closed
box that is sort-of a router and a bridge.  So your only inputs is really
network traffic.  That is what we tune the box for.  So it would be interesting
to see you kill it in 1s.  Again our issue is PCI bus.  Now that the P4 
Serverworks chipset is out we finally have a machine that holds the current 
gig with crypto records by a lot (faster then a couple of P4 Xeon machines
we have).  With a 32bit/33Mhz we are pegged at the PCI chipset limits.  
One of the challenges of testing crypto (IPsec) stuff is having clients 
that can keep up.

I'be been told there is a paper in the works for HW crypto performance
based on this and other HW.  So results of this should be published.

Doug A.

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

Re: Realtek

[Doug Ambrisko]

Terry Lambert writes:
| No, the best thing about all GigE is that you don't need a twisty
| cable, It Just Works.  They should do the same thing for the 100Mbit,
| IMO.  8-).

They have started that.  Via has atleast one auto-mdi/mdi-x nic chip.
We'd like it if more companies start doing it but I wouldn't hold my
breath.

Caveat is that a Netgear auto mdi/mdi-x switch won't allways sync with 
the fxp0 in my laptop :-(  So looks like we are in for another round of
auto negotiation that doesn't always work.

I do like the Intel gig cards, since you can get dual fiber and copper 
version.

Doug A.

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

Re: Realtek

[Doug Ambrisko]

Thierry Herbelot writes:
| Le Friday 07 March 2003 18:16, Doug Ambrisko a ?crit :
| > everything at once.  This illustrated the HW issue with the new D-Link 4
| > port card since none of their "supported" drivers and OSes could get over
| > 20Mbs.  We had 100FDX links to each client and a Gig link to the server.
| > FreeBSD could peak to 40Mbs if I recall right and we were told FreeBSD
| > must be broken even though it was faster then their supported OSes
| > (Windows < 1Mbs)!  To be honest I did fix a bunch of bugs in the FreeBSD
| > driver.
| >
| [re-SNIP]
| >
| > Our bigger issue is bus performance on a 32bit/33Mhz bus with 3, 4-port
| > cards.
| 
| and the avid reader asks : so, now, what NIC are you really using ? (I too 
| have used with great pleasure quite a bunch of DLink-DFE-570), and I was 
| leaning towards using the newer DFE-580 4-port on another project ...)

The DFE-580 is EOL.  That is their solution to their less then optimal 
card with no replacement coming according to our rep.  We are using our 
own custom board with the Realtek 8100L parts.
 
| any suggestions (with benchmark results ?) heartily welcome !

I need to find them however, you need to benchmark in your environment
since CPU load etc can effect things.

PHK found a 4 port fxp card that was priced pretty good.  I don't know
how successful he has with them.

Doug A.

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

Re: Realtek

[Doug Ambrisko]

Wes Peters writes:
| On Thursday 06 March 2003 15:02, Paulo Roberto wrote:
| > --- Bram Van Dam <[EMAIL PROTECTED]> wrote:
| > > cheap they are they do their job fairly well. If performance isn't
| > > an issue then go for it.
| >
| > I couldn't agree more. If you are just staying in 55 mph, you don't
| > need a Ferrari.
| 
| It's not a ford vs. ferrari problem, it's that the ford only has first 
| gear, so you're doing 45 mph at redline and in grave danger of blowing 
| the heads off continuously.
| 
| The problem with the RealTek chipset is that the packets have to be 
| aligned on some completely stupid boundary in memory (32 bytes if memory 
| serves).  The driver code ends up copying the packet data to a tempory 
| buffer before sending it for almost every outgoing packet, which is just 
| totally stupid.

[snip]

| JUST SAY NO.

Actually, test and the pick the fastest tends to be better.

Since D-Link dropped their good 4-port card for a broken one which they
discontinued we had to scramble for a solution.  Our test bed was a
basically a "server" machine tied to a "router/bridge" like thing with
4 clients.  We'd run tests all to the server, all to the clients and 
everything at once.  This illustrated the HW issue with the new D-Link 4 
port card since none of their "supported" drivers and OSes could get over 
20Mbs.  We had 100FDX links to each client and a Gig link to the server.  
FreeBSD could peak to 40Mbs if I recall right and we were told FreeBSD 
must be broken even though it was faster then their supported OSes 
(Windows < 1Mbs)!  To be honest I did fix a bunch of bugs in the FreeBSD
driver.

Using this framework we had a bridge riser card that we could plug
4 various PCI ethernet cards.  We tested the dc(4), fxp(4), rl(4), sis(4)
cards of various types and with our motherboard and CPU the rl(4) 8139C
chips where the fastest via netperf with a significant margin.  I went
into the test biased against Realtek but couldn't justify not using them
after testing.  Now we are using the 8100L chip so we have a pretty simple
design.

So I'd say given a sufficiently fast CPU and memory the Realteks work
pretty darn good.  The speed win could be do to a slightly better 
bus interface.  That was the problem with the newer D-Link 4 port card
in that during RX the chip would take over the PCI bus for a lng time.

A sufficiently fast CPU in our case is 700Mhz Celeron which is a lot 
different then pushing 100Mbs with a P5 133Mhz.

Our bigger issue is bus performance on a 32bit/33Mhz bus with 3, 4-port cards.

To date we haven't had any trouble with them and we've shipped a bunch.

Doug A.

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

Re: Another EPIA M 9000 update (was Re: More compartive power/performanceresults (was Re: Lower power SMP boxes?))

[Doug Ambrisko]

Julian Elischer writes:
| On Mon, 10 Feb 2003, Matthew Dillon wrote:
| > :I can't find any online specs to tell me if the graphics part of the
| > :Northbridge has understands the VESA stuff.  Does the XFree86 "vesa"
| > :driver work?
| > :
| > :Also found this forum discussion...
| > :
| > :http://forums.viaarena.com/messageview.cfm?catid=28&threadid=30617
| > 
| > M 9000 X11 update:
| > 
| > The "vga" driver works in low resolution modes.  The "vesa" driver
| > does not work.  Via has a linux driver on their CD for X, called "via",
| > which linux people seem to be using successfully, but I can't find
| > sources anywhere.  I don't understand why these companies don't just
| > include sources for their X drivers, it would make life so much easier.
| 
| Try use the linux binary...
| believe it or not the latest XFree86 release has a loadable driver
| interface that is completely cross-OS compatible. I.e the drivers
| can not call any external calls only those provided by teh OS-specific
| framework into which they are loaded.
|  
| Something that they have done very right..
| I've seen several manufacturer supplied drivers for "Linux" work under
| FreeBSD.

... and for a I while I was supplying Linux folks with a working XFree server
module for an IBM 770Z ThinkPad built on FreeBSD of course!

Doug A.

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

Re: Supporting HW_WDOG?

[Doug Ambrisko]

Bruce M Simpson writes:
| Mainly interested in exploring this with a view to implementing capabilities
| a bit like the LOM chip found in Sun Netras on an i386 box.
| 
| What I'd like to do is modify a Soekris net4501 for this. The Sun LOM
| chip handles things like serial console capabilities, environmentals, 
| and provides a means of executing memory tests, etc; it's able to issue
| notifications to the OS running on the machine, I believe using traps or
| an NMI mechanism.
| 
| Come to think of it, has anybody seen anything like this in the Intel
| IPMI specification? Just a thought.

We have implemented a SW & HW watchdog here.  The HW support is based on
the reboot timers in the Intel ICH and SIS 630 chips.  Our scheme is to
implement a SW watchdog in hard clock that is controlled via a sysctl.
Then we enforce the SW watchdog via the HW watchdog (ie if the SW watch
dog doesn't reset the HW watchdog then the machine reboots).  This gives
us more flexibility then the HW watchdog does since they have a limited
and non-standard amount of time they can wait for.  This way only 
sysctl's are used an no /dev entries are needed.  I did add a kernel
sysctl function so that I could call another sysctl easily.  This let
me "dynamically" link in the HW watchdog if a kldload was loaded that
implemented the HW watchdog sysctl.  I kldunload would disable the 
HW watchdog and unlink it from the SW one.  We also added code that if the 
machine panic'ed or dropped into the debugger with DDB not set as unattended
then the watchdogs would get turned off (also we disable consmute at the 
same time).  We have this working on generic PC motherboards with no 
custom hardware.

The user-land tickler just does a syctl to set the ticks that SW watchdog 
should wait for before it calls panic and gives you a kernel core.

Unfortunately the ICH reboot timer cannot generate an NMI.  That would have
been better so we could get a core.

Note at a prior company we needed the tickler since the HW watchdog could
not be deactivated until it went off :-(  Smarter watchdogs can be turned
off and then ticklers are not needed.

If anyone it interested with playing with the code and getting it into
shape to put into -current I can send it to you.  It needs to be cleaned
up.  The kernel sysctl function needs to be added properly to the 
sysctl file etc.  I can help with testing, reviews and questions.  I just
don't have time for polishing right now.

Doug A.

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

Re: bge problems (was: gigabit NIC of choice?)

[Doug Ambrisko]

John Polstra writes:
| If you want a gigabit interface that is likely to keep working in
| FreeBSD, your only option is to use the Intel chips and the "em"
| driver.  It's our only gigabit driver that's maintained by somebody
| who has unrestricted access to the documentation and errata.

Atleast one potential exception to this it that so far National seems
to keep their programming on line without needed an NDA.  I used that
and peeked at the Netgear Linux driver on how to enable the fiber port.
So now the driver supports copper and fiber cards.

Doug A.

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

Re: NS DP83820 gigabit MAC

[Doug Ambrisko]

Bruce M Simpson writes:
| On Tue, Sep 03, 2002 at 09:30:43PM +0200, Robert Fenech wrote:
| > I've been desperately looking for some help regarding the DP83820.  Is 
| > anyone willing to help me pls?
| 
| NetBSD would seem to have a driver for this.
| http://www.tac.eu.org/cgi-bin/man-cgi?gsip+4
| 
| AUTHORS
|  The gsip driver was written by Jason R. Thorpe <[EMAIL PROTECTED]>.

Why not use nge(4) which now supports fiber versions:

  NAME
 nge - National Semiconductor PCI gigabit ethernet adapter driver

  SYNOPSIS
 device miibus
 device nge

  DESCRIPTION
 The nge driver provides support for various NICs based on the National
 Semiconductor DP83820 and DP83821 gigabit ethernet controller chips,
 including the following:

Doug A.

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

Re: Motherboard temperature sensing

[Doug Ambrisko]

Dan Nelson writes:
| In the last episode (Jul 09), Julian Elischer said:
| > I haven't been following this so now naturally
| > it becomes important..
| > 
| > anyone have good pointers?
| 
| healthd, mbmon, or lmmon, in ports.  Healthd and lmmon don't get all my
| variables, mbmon does (Asus cuv4vd motherboard).  All are easily
| scriptable for graphing purposes, healthd can be configured to run
| scripts based on trigger settings.

mbmon seems pretty good knowing about more chips.  One thing that is 
annoying about this stuff is that different chips tend to layout the
registers in various ways and potentially different access schemes.
I find the best best is to look at the super I/O chip and then get the
data sheet for it and code away.  That unfortunately seems to be the 
best bet.

Doug A.

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

Re: PCI4800

[Doug Ambrisko]

Dmitry A. Bondareff writes:
| Last 3 days I was trying to connect an Aironet card PCI4800 with Cisco 
| Aironet series 340.
| No success!
| 
| Does anybody do it ??

I have a PCI Cisco version that talks to various other cards without problem.
Some more info would be helpfull like if your are using WEP etc.  The old
the older Aironet 4800A cards could only do WEP up to 2mbs.

You might also upgade the firmware on the card via "airoflash" in ports.

Doug A.

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

Re: vlan traffic over ipsec tunnel

[Doug Ambrisko]

Archie Cobbs writes:
| Terry Lambert writes:
| > Bridging doesn't work with the vlanX interface currently in FreeBSD.
| 
| Why not?
| 
| I believe you, I've just never used vlans and always assumed
| that they acted like normal Ethernet interfaces.

Same here:
  a21p#  ngctl list
  There are 5 total nodes:
Name: ngctl53375  Type: socket  ID: 0006   Num hooks: 0
Name: an0 Type: ether   ID: 0005   Num hooks: 0
Name: vmnet1  Type: ether   ID: 0004   Num hooks: 0
Name: vlan0   Type: ether   ID: 0003   Num hooks: 0
Name: fxp0Type: ether   ID: 0002   Num hooks: 0
  a21p# ifconfig vlan0
  vlan0: flags=8843 mtu 1500
  inet 192.168.33.1 netmask 0xff00 broadcast 192.168.33.255
  ether 00:10:a4:91:2e:ce 
  vlan: 34 parent interface: fxp0
  a21p# 

Would imply it should just work to bridge vlan's via netgraph bridging.
As Archie said I have not tested this to prove how it does or does not
work since I haven't had a need to try it.

Doug A.

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

How stable is the ste(4) DLink DFE-550TX driver?

[Doug Ambrisko]

I'm seeing some stalls on RXing packets which takes performance
down to ~50mbs on a 100BaseTX link.  TX runs at 92mbs with no stalls.
This is on -stable.

I don't see this with the OpenBSD driver.  -current is really slow on
RX.

What have others experienced?  I'm starting to look at the differences
to ste(4) the Sundance ST201 driver.

Thanks,

Doug A.

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

Re: Kernel debugger and X11.

[Doug Ambrisko]

Josef Karthauser writes:
| > > Does anyone have any working practices around this problem?  I'm sure
| > > that I'm not the only one of us with it.
| > 
| > I would recommend just enabling crash dumps; then it doesn't matter if
| > you're in X when the machine panics, and you can get a stack trace and look
| > at things once the machine reboots.
| > 
| I suppose.  Is it possible to switch the debugger off via a sysctl,
| without compiling it out?

You could switch it to ddb_unattended via:
sysctl -w debug.debugger_on_panic=0
when you start and flip when you exit.  Then just leave everything
compiled in your kernel.

Doug A.

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

Re: Mini-PCI <-> PCI boards

[Doug Ambrisko]

M. Warner Losh writes:
| I have had placed into my hand a few Mini-pci cards from time to
| time.  Since I'm using my laptop with mini-pci as a main terminal, I'd
| like to put some of them in my desktop machine.  I'm looking for a
| mini-pci <--> pci card board.  It would also be good if the standard
| cable things were included with this so I could test the network/modem
| parts of the card, but that's not 100% required since the mini-pci
| cards I typically get are wireless.
| 
| Any recommendations?

I assume you want to go from PCI -> Mini-PCI.
http://www.adexelec.com/pci32.htm#PCI2MPCI-02
they have them with and with out the connectors for modems/Ethernet.
I've haven't use the connectors, but the board works fine with
a HW crypto card.  I think they are ~$50.

A Mini-PCI -> PCI might be interesting.

Doug A.

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

Re: read-only CD-ROM boot partition for vinum webfarm?

[Doug Ambrisko]

Terry Lambert writes:
| Doug Ambrisko wrote:
| > | The issue is that the MTBF for IDE CDROM drives is very
| > | low, comparatively, when they are forced to a continuous
| > | duty cycle.  This was discuseed two years ago, and I don't
| > | think the situation has improved any.  8-(.
| > 
| > Actually 2 years ago it got much better to be a non-issue.  4 years
| > ago with IDE CD-ROMs it was sketchy.  ... but what do I know being
| > responsible for manufacturing systems based on FreeBSD mounting root
| > via a CD-ROM in a dirty and hostile environment?
| 
| Hey, Doug!
| 
| I was basing my statement on the inability to use CDROMs
| for InterJets, which would have resolved the late-binding
| install issue for us.  8-).

That was not an issue.  Certain projects were exploring
this possibility as per my patches to boot FreeBSD CD-ROMs 
on IBM hardware.
 
| What's the MTBF for a CDROM being used as a swap backing
| store for program files and a root FS these days?

Enough, not to be an issue and probably on par to a typical hard
drive in practicle use.  I replaced 2 CD-ROMs and our manufacturer 
replaced atleast 2 IDE drives that I knew directly off.  Since 
they had a supply of hard drives I just had them deal with that.  
CPU fans and CPUs were more of an issue due to caked on dust in 
the machines.  Have to wonder how the dust effected the CD-ROM drives.
Fortunately at the time we used P5-133 that didn't need much 
cooling compared to todays CPUs so it was a while before they
failed.

Our manufacturing process definitely weeded out marginal drives
especially when we ran the "verify cd" command.  We used the 
hard disk only as a cache for the download images and /var all
binaries were run from the CD mounted as root which made login
in take long time.  You could hear the CD spin up and down
and seek all around.  The last time I had to be careful about
selecting a CD-ROM was when T-Zone was still in business!

Personally I don't care about MTBF, I care about how many times
I have to service something.  Since I tend to be lazy I try to 
use stuff that just works.  If the CD-ROMs weren't reliable
I don't think our entire manufacturing process would have 
depended on it.  BTW near the "end" we started running into a 
slew of hard drives that had a stiction problem and needed some 
help to get spinning again.  It was interesting to watch the
drives seeking with the drive apart, with me push starting the 
plater and asking people not to sneeze or cough on it while we
duplicated the disk to another drive.

Also we never had to worry about bad sectors or head slap before
hard disks were installed in system with a root mounted CD-ROM.  
This doesn't seem to appear in MTBF numbers.  Power outages
where not an issue or operators that power-cycled machines
as matter of process and we know that power outages can cause
bad sectors.

Now a cool thing would be to make a FreeBSD live CD that booted
up to multi-user for a quick demo.  With jhb's work this should
be a lot simpler to do now.  It would be the ultimate "fix-it" disk.

Doug A.

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

Re: read-only CD-ROM boot partition for vinum webfarm?

[Doug Ambrisko]

Terry Lambert writes:
| "Clark C . Evans" wrote:
| > Hello.  I was wondering if it is possible to make a read-only
| > boot partition (core kernel, static configuration, and /usr)
| > for a web-farm application.   I've posted this question to the
| > freebsd-small list as well and will try to solicit comments
| > there as it seems that is the most appropriate list.  Thus
| > far these are some of the challenges outlined on the freebsd-users@uk
| > list...
| 
| It's possible to do; you probably want to limit it to
| a "test drive" CDROM, rather than putting it into a
| production setting.
| 
| The issue is that the MTBF for IDE CDROM drives is very
| low, comparatively, when they are forced to a continuous
| duty cycle.  This was discuseed two years ago, and I don't
| think the situation has improved any.  8-(.

Actually 2 years ago it got much better to be a non-issue.  4 years
ago with IDE CD-ROMs it was sketchy.  ... but what do I know being
responsible for manufacturing systems based on FreeBSD mounting root
via a CD-ROM in a dirty and hostile environment?

Doug eh?

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

Re: Multicast problem with sis interface?

[Doug Ambrisko]

Bob Bishop writes:
| Hi,
| 
| At 21:01 -0800 18/2/02, Doug Ambrisko wrote:
| >Bob Bishop writes:
| >| Seems there might be some problem with multicast on sis interfaces.
| >| Specifically, netatalk doesn't work right on this box through the sis
| >| interface but it's fine through the RealTek.
| >| This is the onboard interface on a K7S5A m/b, dmesg follows. Ideas,
| >anyone? TIA
| >|
| >| Copyright (c) 1992-2002 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 4.5-RELEASE #1: Sun Feb 17 16:18:51 GMT 2002
| >
| >Try -stable.  I found a bug in which on receiving a frame from the
| >chip the chksum was included.  This messed up things since the returned
| >packet was to big.  Luigi, commited the code to fix this.
| 
| No dice with last night's -STABLE. And it's definitely the interface, I've
| tried a variety and netatalk works with everything (including the dreaded
| Via Rhine) except for the onboard sis0.
| 
| I suppose it's time for some comparative tcpdumping...

Pity that would have been an easy fix.  Doing tcpdump should help.  
I like Ethereal so I can drill down a little easier.

Doug A.

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

Re: Multicast problem with sis interface?

[Doug Ambrisko]

Bob Bishop writes:
| Seems there might be some problem with multicast on sis interfaces.
| Specifically, netatalk doesn't work right on this box through the sis
| interface but it's fine through the RealTek.
| This is the onboard interface on a K7S5A m/b, dmesg follows. Ideas, anyone? TIA
| 
| Copyright (c) 1992-2002 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 4.5-RELEASE #1: Sun Feb 17 16:18:51 GMT 2002

Try -stable.  I found a bug in which on receiving a frame from the
chip the chksum was included.  This messed up things since the returned
packet was to big.  Luigi, commited the code to fix this.

Doug A.

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

Patch for SIS630ET embedded NIC

[Doug Ambrisko]

I would appreciate if people that have SIS Ethernet controllers to test
out this patch.  I added support for the 630ET based on the changes
in the Linux driver.  It seems to work fine.

I'd like to get some "yes it doesn't break anything" or "heh, now my
SIS Ethernet controller works now" comments before commiting this change.
The patch is based on -stable right now.  It applies to -current cleanly.
BTW I tested this on a Asus TUSI motherboard.

Thanks,

Doug A.

Index: if_sis.c
===
RCS file: /cvs/src/sys/pci/if_sis.c,v
retrieving revision 1.13.4.16
diff -c -r1.13.4.16 if_sis.c
*** if_sis.c18 Dec 2001 02:33:27 -  1.13.4.16
--- if_sis.c2 Jan 2002 20:54:06 -
***
*** 147,152 
--- 147,153 
  #ifdef __i386__
  static void sis_read_cmos __P((struct sis_softc *, device_t, caddr_t,
int, int));
+ static void sis_read_mac  __P((struct sis_softc *, device_t, caddr_t));
  static device_t sis_find_bridge   __P((device_t));
  #endif
  
***
*** 439,444 
--- 440,473 
pci_write_config(bridge, 0x48, reg & ~0x40, 1);
return;
  }
+ 
+ static void sis_read_mac(sc, dev, dest)
+   struct sis_softc*sc;
+   device_tdev;
+   caddr_t dest;
+ {
+   u_int32_t   save;
+   u_int32_t   save2;
+ 
+   save = CSR_READ_4(sc, SIS_RXFILT_CTL);
+   save2 = CSR_READ_4(sc, SIS_CSR);
+ 
+   CSR_WRITE_4(sc, SIS_CSR, SIS_CSR_RELOAD | save);
+   CSR_WRITE_4(sc, SIS_CSR, 0);
+   
+   CSR_WRITE_4(sc, SIS_RXFILT_CTL, save & ~SIS_RXFILTCTL_ENABLE);
+ 
+   CSR_WRITE_4(sc, SIS_RXFILT_CTL, SIS_FILTADDR_PAR0);
+   ((u_int16_t *)dest)[0] = CSR_READ_4(sc, SIS_RXFILT_DATA);
+   CSR_WRITE_4(sc, SIS_RXFILT_CTL,SIS_FILTADDR_PAR1);
+   ((u_int16_t *)dest)[1] = CSR_READ_4(sc, SIS_RXFILT_DATA);
+   CSR_WRITE_4(sc, SIS_RXFILT_CTL, SIS_FILTADDR_PAR2);
+   ((u_int16_t *)dest)[2] = CSR_READ_4(sc, SIS_RXFILT_DATA);
+ 
+   CSR_WRITE_4(sc, SIS_RXFILT_CTL, save);
+   CSR_WRITE_4(sc, SIS_CSR, save2);
+   return;
+ }
  #endif
  
  static int sis_miibus_readreg(dev, phy, reg)
***
*** 889,896 
command = pci_read_config(dev, PCIR_REVID, 1);
if (command == SIS_REV_630S ||
command == SIS_REV_630E ||
!   command == SIS_REV_630EA1)
sis_read_cmos(sc, dev, (caddr_t)&eaddr, 0x9, 6);
else
  #endif
sis_read_eeprom(sc, (caddr_t)&eaddr,
--- 918,929 
command = pci_read_config(dev, PCIR_REVID, 1);
if (command == SIS_REV_630S ||
command == SIS_REV_630E ||
!   command == SIS_REV_630EA1 ||
!   command == SIS_REV_630ET)
sis_read_cmos(sc, dev, (caddr_t)&eaddr, 0x9, 6);
+ 
+   else if ((command > 0x81) && (command <= 0x90))
+   sis_read_mac(sc, dev, (caddr_t)&eaddr);
else
  #endif
sis_read_eeprom(sc, (caddr_t)&eaddr,
***
*** 903,908 
--- 936,948 
 */
printf("sis%d: Ethernet address: %6D\n", unit, eaddr, ":");
  
+   /*
+* From the Linux driver:
+* 630ET : set the mii access mode as software-mode
+*/
+   if (command == SIS_REV_630ET)
+   SIS_SETBIT(sc, SIS_CSR, SIS_CSR_ACCESS_MODE);
+   
sc->sis_unit = unit;
callout_handle_init(&sc->sis_stat_ch);
bcopy(eaddr, (char *)&sc->arpcom.ac_enaddr, ETHER_ADDR_LEN);
Index: if_sisreg.h
===
RCS file: /cvs/src/sys/pci/if_sisreg.h,v
retrieving revision 1.1.4.6
diff -c -r1.1.4.6 if_sisreg.h
*** if_sisreg.h 8 Dec 2001 00:04:15 -   1.1.4.6
--- if_sisreg.h 2 Jan 2002 20:54:06 -
***
*** 105,110 
--- 105,112 
  #define SIS_CSR_RX_RESET  0x0020
  #define SIS_CSR_SOFTINTR  0x0080
  #define SIS_CSR_RESET 0x0100
+ #define SIS_CSR_ACCESS_MODE   0x0200
+ #define SIS_CSR_RELOAD0x0400
  
  #define SIS_CFG_BIGENDIAN 0x0001
  #define SIS_CFG_PERR_DETECT   0x0008
***
*** 367,372 
--- 369,375 
  #define SIS_REV_630E  0x0081
  #define SIS_REV_630S  0x0082
  #define SIS_REV_630EA10x0083
+ #define SIS_REV_630ET 0x0083
  
  /*
   * NatSemi vendor ID

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

Re: Problems with booting of CD-ROM (fwd)

[Doug Ambrisko]

Thomas Dixon writes:
| 
| 
| On Tue, 16 Oct 2001, John Baldwin wrote:
| 
| > 
| > On 16-Oct-01 Thomas Dixon wrote:
| > > I'm trying to make a bootable CD using the cdboot program that come with
| > > freeBSD in /sys/i386/boot/cdboot.  The computer I'm trying to do this on
| > > definately boots other CDs as it has booted several other CDs.  However
| > > using a CD I've made using mkisofs and cdboot it gives the error;
| > >  
| > >   Your BIOS int 0x13 extensions seem to be disabled.
| > >   It's impossible to boot a CD-ROM without them.
| > >   (BIOS int 0x13 fn 0x4b01 yielded error 1)
| > >  
| > > I'm using an Asus P5A motherboard, there appears to be no way to enable
| > > the int 0x13 extensions in the BIOS and there is nothing in the manual
| > > that refers to these.
| > > 
| > > Any ideas why this error is coming up or how to fix it?
| > 
| > Don't use cdboot or cdldr, they don't qutie work yet. :(
| > 
| > Instead, make a floppy image and use that to boot.
| > 
| I've tried this and I couldn't figure out the syntax for loader.rc to load
| the file system from the cd-rom, any ideas?

I'd skip the MFS step and just put the kernel on the boot floppy with
loader and friends.  Then in 
/boot/loader.rc 
add:
boot -C
So it looks something like:
  \ Loader.rc
  \ $FreeBSD: src/sys/boot/forth/loader.rc,v 1.2 1999/11/24 17:59:37 dcs Exp $
  \
  \ Includes additional commands
  include /boot/loader.4th
  
  \ Reads and processes loader.rc
  start

  \ Tests for password -- executes autoboot first if a password was defined
  check-password

  \ Unless set otherwise, autoboot is automatic at this point

  boot -C

Atleast this works for me even on IBM machine as of 4.4-Release!  If
you run out of room for your kernel (even if you gzip it) you can kldload
modules off the CD during startup.

Doug A.

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

Re: 64bit Ethernet Card (if_sf driver)

[Doug Ambrisko]

[EMAIL PROTECTED] writes:
| I've been testing the adaptec 64044 card (if_sf driver) which is a 64bit 
| 66Mhz 4 port ethernet. I can have come to one of two conclusions:
| 
| 1) the card sucks
| 2) the driver sucks
| 
| or both. A 32bit Dlink 4 port card outperforms it by a wide margin, as do 
| 32bit eepro100s. "wide margin" being defined as about 40%.
| 
| Given that bus resources are not easily measureable..Im quoting cpu usage for 
| handling the same number of pps. But its pretty difficult to justify using a 
| 64bit slot and rather expensive card with such lousy performance. I cant even 
| justify the bus-bandwidth saving with a card that cant route more than 
| 250Mb/s.
| 
| I guess my question has to do with whether the board is just a dog or the 
| driver needs substantial optimization. The folks at adaptec aren't dopes 
| generally, so I cant imagine that they chose a chipset that was so inferior 
| to the one on their 32bit adapter (which uses the same as the Dlink).
| 
| Anyone with experience or ideas?

I can just confirm your observations.  I found that having it in a 64bit
slot or 32bit made no difference.  I hope it is a driver problem since
Adaptec was selling a DEC based 4 port card that they got when they 
bought Cogent.  I find it hard to believe that they would replace that
with a poorer performance card that probably cost them more to make.

Doug A.

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

Re: Does boot1 still have a > 1023 cyl limit?

[Doug Ambrisko]

John Baldwin writes:
| This is for boot0.  Nothing should be touching boot1 flags.
| My guess is that someone has somehow mixed an old boot2 with the new boot1
| which is jumping to the wrong place to call xread.  The "code" at cs:eip looks
| a lot like the BPB in boot1 now.

Okay that basically how I read the code.  Just wanted to make sure I
wasn't missing something.  Your theory sounds quite possible.

Thanks,

Doug A.

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

Re: Does boot1 still have a > 1023 cyl limit?

[Doug Ambrisko]

[EMAIL PROTECTED] writes:
| Kent Stewart wrote:
| 
| > Mike Smith wrote:
| > > 
| > > > So.. if I read you right, booting correctly for > 1024 cylinders works
| > > > if boot0 knows about it.  Isn't boot0 the one in the MBR, not in the fbsd
| > > > slice?  Does this mean that boot1 and boot2 should work just fine if they
| > > > are loaded by another kind of MBR loader (say, Grub), and they find out
| > > > that they are placed beyond the 1023th cylinder?
| > > 
| > > This should work, yes.
| > 
| > I tried this with a boot1 from FreeBSD 4.4-rc and get a BTX error. I
| > had to go back to the boot1 from 4.3 before I could boot.
|  
| That could be serious.  Can you post a brief description of your
| hardware, together with the BTX register dump if possible?  boot1 was
| changed to address some problems with certain hardware, so it is
| important to know if other incompatibilities have been introduced.

... in 4.3:
warp% nm boot1.o | grep flags
0199 t flags
warp% 

in -current
a21p% !nm
nm boot1.o | grep flags
01ba t flags
a21p% 

Is someone writing into boot1 "flags"?  Then there is a problem since this
has moved.  We did some work to avoid this "linking type" problem for xread 
in boot2.c to prevent this type of error.  Do we have to do it for "flags"?

I see in libdisk:
  static void
  Cfg_Boot_Mgr(u_char *mbr, int edd)
  {
if (mbr[0x1b0] == 0x66 && mbr[0x1b1] == 0xbb) {
if (edd)  
mbr[0x1bb] |= 0x80; /* Packet mode on */
else
mbr[0x1bb] &= 0x7f; /* Packet mode off */
}
  }

The mbr code it is modifying is in boot0 or mbr since I see in
boot0 that:
a21p% nm boot0.o | grep flags
01bb t flags
a21p% 
but I'm not seeing how it gets over to boot1 for this test?
read.7: testb $FL_PACKET,%cs:MEM_REL+flags-start # LBA support e

Doug A.

PS. dhw ... could you try to set packet mode on some machines there
and test it.

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

Re: how to share include files between kernel and userland?

[Doug Ambrisko]

Marco Molteni writes:
| I am writing a program to parse frames dumped to bpf by an, the
| aironet driver.
| 
| I am using the latest patches by Doug Ambrisko, that allow the driver
| to dump not only the 802.11 frame but also the special Aironet header
| that the device prepends to the 802.11 frame, ie:
| 
| aironet header | 802.11 frame
| 
| Now, to my question with include files. The struct that describes the
| aironet header, an_rxframe, is in an/if_anreg.h, so I included
| if_anreg.h in my program. Among other things, if_anreg.h needs the
| definition of struct arpcom, which is in net/if_arp.h. Good, I
| included also net/if_arp.h, but the compiler still complained. It
| turns out that the definition of struct arpcom is guarded by
| #ifdef _KERNEL.
| 
| So, what should I do? Define _KERNEL in my program, or copy the
| definition of struct an_rxframe directly in my C file? I hoped to find
| a third, more elegant solution.

Don't include that file only include if_aironet_ieee.h.  Really we should
install this file in the standard /usr/include tree so you don't need
the /sys tree around to build it and ancontrol.

I'll move the an_rxframe struct to if_aironet_ieee.h.  Note that
I'm not to sure how pcap is going to like my made up type.  If you send
my some sample code on dump the Aironet header I can test it for you
to make sure it works since I haven't got around to it.

There were some people interested in the Aironet header so I put something
together but never tried doing anything usefull with it.

Doug A.

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

Updated Aironet Sniffing patches for -stable

[Doug Ambrisko]

I have new patches for the Aironet sniffing and some major code clean-up of
duplicated structures and defines it requires the latest -stable.
http://www.ambrisko.com/doug/an/an.patch.cisco.rfmon2+ifconfig5
Applies to /usr/src if you don't have the linux ioctl patch from:
http://www.ambrisko.com/doug/an/
installed then undef LINUX_COMPAT.

Please test and then I will send-pr the patches in.

Note this patch touches tcpdump & libpcap to add 802.11 support so a make
world & kernel is recommended.  This won't be needed when our 
tcpdump & libpcap is updated.

Doug A.

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

Re: bridging with pcmcia cards

[Doug Ambrisko]

Joesh Juphland writes:
|
| Great.
|
| Can I already bridge with an*  ?  And does this mean that bridging in
| general with pc cards is a-ok ?

This has been reported to work with the "an" driver with netgraph
bridging.

Doug A.

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

Re: NFS swap?

[Doug Ambrisko]

David Gilbert writes:
| I used to include 'option option-128 "/path/to/swap"' in my dhcpd.conf 
| file to get nfs swap mounted properly.  I'm now using a 4.3 kernel and 
| dhcpd 3.0rc4 from ISC.  It won't allow me to put in option-128.  Is
| there any other way to specify nfs based swap?

Try this first define the option near the top:
option swap-path code 128 = string;
then use it as:
option swap-path "/path/to/swap";

It's actually kind of nice to bad it doesn't totally work for dhclient
when you want to request and option that is not standard.

Doug A.

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

802.11 sniffing with Cisco/Aironet card

[Doug Ambrisko]

In my latest set of patches for -stable the Aironet driver with a few
patches to FreeBSD's bpf & libpcap to support 802.11 packets permits
sniffing of raw 802.11 packets.

The patches are at:
http://www.ambrisko.com/doug/an/
The latest version is
an.patch.cisco.rfmon2+ifconfig3

Several bug fixes have been applied and some of the ifconfig patches that 
Brooks did since if_an.c depends on some of the 802.11 headers that he
did.  Some of the 802.11 monitor code is from Javier work on the Aironet
driver for Linux.  This patch also includes the Cisco driver emulation
(that needs my Linux emulator patch).  I also unified the .h files in
/sys/dev/an so that there are only one definition for things except in
the case where I'm trying to keep the Linux definitions for things
so we can just compile Linux apps. such as the firmware upgrade utility.
There is a sysctl to support tracing and dumping RIDs.

To sniff packets you seem to need version 17a of Ethereal or relatively
recent version from the Ethereal CVS server.  I have a version of
17a Ethereal on my web site in the "an" directory.

Thanks to the people that helped my test this out on -stable.

Doug A.

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

Re: cdr and cdrw with 4.3 release

[Doug Ambrisko]

Terry Lambert writes:
| Tom wrote:
| > 
| > Does anyone know if it is possible to use a cdr/cdrw
| > with 4.3 release? I want to use it with my sony vaio
| > f580 (notebook). I have the option of usb or pcmcia.
| > Can you tell me which models are known to work? Thanks
| > for your help. Please mail all responses to
| > [EMAIL PROTECTED] Thanks again..  Tom
| 
| I use the internal CDRW with my Vaio PCG-XG29.  I believe
| that it is the same model which is used in the F580 and
| similar F-series notebooks.
| 
| I don't use an external CDRW off a USB or PCMCIA dongle.
| 
| A person I used to work with has a PCG-XG28; they use a
| PCMCIA based CDRW with success, but the card has to be
| there, and the drive on, at boot time.

That is strange.  I definitely don't see such problems.   I do such
thing several times.  I try to avoid booting my laptop and just suspend 
and resume it.  So I have several cards come and go over one boot cycle.  
Any generic PCMCIA IDE based thing should work.  I might stop using an 
external CDRW things once combo DVD & CDRW become more available/cheaper.  
Also internal bits are harder to share.

Doug A.

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

Re: vmware on freebsd for fast booting for devel.

[Doug Ambrisko]

Andrew Gallatin writes:
| 
| Doug Ambrisko writes:
|  > | 
|  > | Grub doesn't support FreeBSD very well (eg, it can't set the root
|  > | device, set hints, etc).  I think he was hacking grub to add those
|  > | features, but I don't know how far he got...BTW, grub has no spinner.
|  > 
|  > Why not just use EtherBoot?
| 
| Simple ignorance.
| 
| I'll pass that pointer along to the person here who was hacking with
| VMware.

If they have any questions send me a note.

Doug A.

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

Re: vmware on freebsd for fast booting for devel.

[Doug Ambrisko]

Andrew Gallatin writes:
| 
| Alfred Perlstein writes:
|  > So I've got this really elite machinery here to test on, problem is that
|  > booting takes about 2 minutes each time I make a bad kernel, s...
| 
| Do you mean that vmware boots so slowly that the extra reboot cycle
| required to install the next test kernel is painfully slow?  
| 
| One thing to try to speedup vmware boots would be getting rid of the
| spinner in libstand -- vwware's dos-mode console i/o is painfully
| slow.
| 
| The best way to cut the reboot wait time down is to network boot.
| Unfortunately, VMware's AMD PCInet card doesn't support PXE.  Somebody
| here has been using something called "grub"
| (http://www.gnu.org/software/grub/) 
| 
| Grub doesn't support FreeBSD very well (eg, it can't set the root
| device, set hints, etc).  I think he was hacking grub to add those
| features, but I don't know how far he got...BTW, grub has no spinner.

Why not just use EtherBoot?
/usr/ports/net/etherboot
It's supports the AMD chip and works with vmware.  Use Julian 
nullmodem driver and connect up a serial console & kgdb session 
and you are all set.  Blow kernel chunks and just reset vmware and 
away you go.  I NFS mount the root filesystem.

Actually what I do since sometimes I work on drivers is netboot a 
slow lunch box machine of my laptop and if it dies just press 
reset and netboot it again.  I build the kernels on the laptop.

Another feature of Etherboot is the built in menu capability so you 
can select from a list of kernels.

BTW grub uses parts of Etherboot for their netbooting.  Ironically 
Etherboot started from FreeBSD's netboot to boot Linux and then 
I added FreeBSD back in.

If you want to try an Etherboot floppy image try 
http://rom-o-matic.net/
Just remember to go into Configure and enable 
IMAGE_FREEBSD & ELF_IMAGE
You can select serial, vga or both consoles.  Then point vmware at the
floppy image and boot.

Doug A.

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

Netboot FreeBSD on Apple Airport (port format)

[Doug Ambrisko]

I put together a port version of the code to boot FreeBSD on an Airport
base station.  I haven't polished it but it produces a functional
image.  Some code should be converted from nasm to gas but I just
haven't had time to mess with that hopefully some else might.

There is code to netboot over a Wavelan card but I haven't integrated that
or included it in the port.  Instead it is in raw.tgz.

Till Straumann ([EMAIL PROTECTED]) did most of the work and I 
made is support FreeBSD.

The code is at:
http://www.ambrisko.com/doug/airport/

Please grab it and polish it.

Thanks,

Doug A.

Hello, this is TillLoad, Copyright <[EMAIL PROTECTED]>, 2001 (GPL) (Basemem: 
0x027F00)
run therboot or irport? >E

ROM segment 0x8000 length 0x40EA reloc 0x9800
Boot from (N)etwork or from (L)ocal? N
Etherboot/32 version 4.6.12 (GPL) for [NE2100]
Probing...[NE2100]
PCnet/ISA+ 79C961A base 0x0300, DMA 5, addr 00:30:65:3A:59:5F
Searching for server (DHCP)...
Me: 192.168.2.194, Server: 192.168.2.254, Gateway 192.168.2.254
Loading /tftpboot/kernel.bsd (ELF/FreeBSD)0680-

Copyright (c) 1992-2001 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 4.3-BETA #9: Wed Mar 21 15:41:11 PST 2001
[EMAIL PROTECTED]:/usr/src/sys/compile/AIRPORT
Timecounter "i8254"  frequency 1193182 Hz
CPU: AMD Unknown (486-class CPU)
Origin = "AuthenticAMD"  Id = 0x4a4  Stepping = 4
Features=0x0
real memory  = 4194304 (4096K bytes)
avail memory = 1998848 (1952K bytes)
Preloaded elf kernel "kernel" at 0xc025bb00.
npx0:  on motherboard
npx0: 387 emulator
isa0:  on motherboard
pcic0:  at port 0x3e0 iomem 0xd on isa0
pcic0: Polling mode
pccard0:  on pcic0
pccard1:  on pcic0
sio0 at port 0x3f8-0x3ff irq 4 flags 0x30 on isa0
sio0: type 16550A, console
lnc0 at port 0x300-0x317 iomem 0xd-0xd irq 10 on isa0
lnc0: PCnet-ISA II address 00:30:65:3a:59:5f
lnc0: driver is using old-style compatability shims
RTC BIOS diagnostic error e4
pccard: card inserted, slot 0
Sending DHCP Discover packet from interface lnc0 (00:30:65:3a:59:5f)
Received DHCP Offer packet on lnc0 from 192.168.2.254 (accepted) (no root path)
Sending DHCP Request packet from interface lnc0 (00:30:65:3a:59:5f)
Received DHCP Ack packet on lnc0 from 192.168.2.254 (accepted) (got root path)
lnc0 at 192.168.2.194 server 192.168.2.254 boot file /tftpboot/kernel.bsd
router 192.168.2.254 rootfs 192.168.2.254:/usr/home/ambrisko/netboot swapfs 
192.168.2.254:/usr/work/netboot 
Adjusted interface lnc0
md_lookup_swap: Swap size is 262144 KB
Mounting root from nfs:
NFS ROOT: 192.168.2.254:/usr/home/ambrisko/netboot
NFS SWAP: 192.168.2.254:/usr/work/ij3/netboot
wi0:  at port 0x240-0x27f irq 5 slot 0 on pccard0
wi0: Ethernet address: 00:02:2d:09:4b:f2
pccardd[40]: Assigning I/O window 0, start 0x240, size 0x40 flags 0x5 
pccardd[40]: Assign wi0, io 0x240-0x27f, mem 0x0, 0 bytes, irq 5, flags 0 
pccardd[40]: wi0: Lucent Technologies (WaveLAN/IEEE) inserted.
dhclient: New IP Address(wi0): 207.76.207.134
dhclient: New Subnet Mask (wi0): 255.255.255.0
dhclient: New Broadcast Address(wi0): 207.76.207.255
dhclient: New Routers: 207.76.207.254
pccardd[40]: pccardd started
login: ROOT LOGIN (root) ON ttyp0 FROM crab
login: ROOT LOGIN (root) ON ttyp1 FROM 207.76.207.135

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

Any ideas for add driver info to linprocfs?

[Doug Ambrisko]

I've been working on getting things cleaned up for the Aironet driver to
emulate the Cisco Linux ioctls so that the binary only utilities for 
configurating and flashing Aironet cards just work.  I send-pr'ed the 
minor changes to add some DEVPRIVATE ioctls to the emulation layer
and support that maps ethX into a FreeBSD ethernet device.  However
the Cisco binaries want to open "/proc/aironet", well under emulation
it also tries "/compat/linux/proc/aironet" first.  It does it to detect if the
Linux Aironet driver is installed.

I can make it work if I unmount "/compat/linux/proc" so that I don't
use the linprocfs emulation stuff and then create the directory
"/compat/linux/proc/aironet".  Is there a way I could detect 
linprocfs is active and then tell it to create this entry
when I attach the Aironet driver (if_an.c)?  

So it seems I would need a mechanism to:
1)  Detect if linprocfs is loaded
2)  Tell it to create an "aironet" entry in the root of the proc
tree.
I don't really have any ideas right now on how to do this.

Thanks,

Doug A.

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

Re: problem with Aironet driver

[Doug Ambrisko]

Andria Thomas writes:
| Recently, we've seen messages like the following spewed to the consoles
| of each machine:
| 
| Mar 26 14:25:57 gw /kernel: an0: id mismatch: expected 178, got 224
| Mar 26 14:25:57 gw /kernel: an0: id mismatch: expected 17e, got 178
| 
| When these messages begin, our network connection grinds to a near-halt
| (ping times of 1000-2000ms).  The only way we've found to stop the
| messages is to disconnect the Aironet connection,  and bring the network
| interface down and back up again.  When it comes back up, everything is
| mysteriously back to normal.
| 
| I've tried looking through the source code, but confess to not
| understanding what it is that prompts these messages to begin.  Any help
| 
| would be greatly appreciated.  I've tried poring through mailing list
| archives, but no one else seems to have reported a similar problem.

Actually a few people have.  I had a fix in my sets of patches but
it seems that was omited so even though the problem was solved it
it still broken.

Hopefully we won't miss the fix again.  Please try this patch.  You will 
have to apply it by hand to /sys/dev/an/if_an.c since I did an X cut-n-paste.

Let me know if it helps.

Thanks,

Doug A.

***
*** 483,494 
} else
ifp->if_opackets++;

!   if (id != sc->an_rdata.an_tx_ring[sc->an_rdata.an_tx_cons])
!   printf("an%d: id mismatch: expected %x, got %x\n",
!   sc->an_unit,
!   sc->an_rdata.an_tx_ring[sc->an_rdata.an_tx_cons], id);

-   sc->an_rdata.an_tx_ring[sc->an_rdata.an_tx_cons] = 0;
AN_INC(sc->an_rdata.an_tx_cons, AN_TX_RING_CNT);

return;
--- 484,496 
} else
ifp->if_opackets++;

!   for (i = 0; i < AN_TX_RING_CNT; i++ ) {
!   if (id == sc->an_rdata.an_tx_ring[i]) {
!   sc->an_rdata.an_tx_ring[i] = 0;
!   break;
!   }
!   }

AN_INC(sc->an_rdata.an_tx_cons, AN_TX_RING_CNT);
 
return;


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

Re: Fix for CDROM boot for IBM PC desktops

[Doug Ambrisko]

Matthew N. Dodd writes:
| On Fri, 6 Apr 2001, Doug Ambrisko wrote:
| > I have confirmed that this works.  So now we should be able to boot a
| > FreeBSD CD on all IBM hardware that I can find around here.  I will
| > revise the PR.
| 
| I wonder if this solves the PS/2 booting problem...
| 
| Guess I should check.

If you have access to a CDROM burner I can give you the recipe to patch
it.  It will take a fair amount of disk space but it fairly easy.

Doug A.

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

Re: Fix for CDROM boot for IBM PC desktops

[Doug Ambrisko]

John Baldwin writes:
| Well, think of boot1 as a really small device driver and xread as a syscall.
| The offset is a magic number.

I'd prefer not to, but whatever.
 
| The maintainer for this stuff is Robert Nordier (rnordier@) and he'll need to
| sign off on it.  Any chance you could figuratively kick the head of whoever at
| IBM did this up around their ears for assuming all the world is DOS? :)

I'll send a note to him.  I haven't heard anything from him for a long time.

Like right, we can't get info out of "ourselves".  However I have some
insight into the IBM desktop BIOS not that I can change it though.  It
looks like if we just do the first 25 bytes or so then we are safe.
All I can do is make FreeBSD work nicely on IBM machines since there
is an incentive to make that happen here.  Also we can't change the 
X number of machines that are out there.

Doug A.

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

Re: Fix for CDROM boot for IBM PC desktops

[Doug Ambrisko]

ambrisko writes:
| I also have an update to the patch to make it work on IBM ThinkPads so
| that we can boot a FreeBSD CD on a ThinkPad.  The problem on the ThinkPad
| is that it reads the values from the defined MSDOS boot sector and
| uses them to figure out how to do the emulation.  Which in our cause
| is random code values.  Since the BIOS didn't see the media type defined 
| as a floppy it made it a IDE device somewhere (such as ad11).  This 
| confused the 3rd stage loader.

I have confirmed that this works.  So now we should be able to boot a FreeBSD
CD on all IBM hardware that I can find around here.  I will revise the PR.

Doug A.
 
| Here is the updated structure in boot1.s:
|   /*  From OpenBSD biosboot.S with tuned values from Doug Ambrisko so 
|   ThinkPads can boot from CDROM.  I think the critical part
|   is setting the media type.
|   */
|   .org 0x03, 0x00
|   .asciz  "FreeBSD"
|   /* BPB */
|   .org 0x0b, 0x00
|   bpb:.word   512 /* sector size */
|   .byte   1   /* sectors/cluster */
|   .word   1   /* reserved sectors */
|   .byte   2   /* # of FAT */
|   .word   224 /* root entries */
|   .word   2880/* small sectors */
|   .byte   0xf0/* media type (fd) */
|   .word   144 /* sectors/fat */
|   .word   18  /* sectors per track */
|   .word   2   /* # of heads */
|   
|   /* EBPB */
|   .org 0x1c, 0x00
|   ebpb:   .long   16  /* hidden sectors */
|   .long   0   /* large sectors */
| 

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

Re: Fix for CDROM boot for IBM PC desktops

[Doug Ambrisko]

John Baldwin writes:
| On 06-Apr-01 Doug Ambrisko wrote:
| > On on IBM PC desktops a FreeBSD bootable CDROM won't boot and it hangs.  
| > This has been reported in several places.
| > 
| > The problem is that some BIOSes namely IBM's writes to the boot sector
| > of the floppy to potentially update the parameters for the emulated
| > floppy used for the El Torrito boot.  Since we do not allocate space
| > for a typical MSDOS "Boot Sector" when the BIOS updates this area
| > it then ends up modifying the boot code which is not a good thing.
| > The boot code then fails in random ways.  I also did a work-around
| > for linking the address of "xread" into boot2.c.
| > 
| > The fix is in PR i386/26382:
| >   http://www.freebsd.org/cgi/query-pr.cgi?pr=26382
| > This would be great to get into 4.3 but probably won't make it.
| 
| E, gross. :)  Bad BIOS, no cookie.  I don't think the perl script is
| needed, simple a one time adjustment of the xread offset in boot2.c should be
| enough.  These programs change very rarely

I also have an update to the patch to make it work on IBM ThinkPads so
that we can boot a FreeBSD CD on a ThinkPad.  The problem on the ThinkPad
is that it reads the values from the defined MSDOS boot sector and
uses them to figure out how to do the emulation.  Which in our cause
is random code values.  Since the BIOS didn't see the media type defined 
as a floppy it made it a IDE device somewhere (such as ad11).  This 
confused the 3rd stage loader.

Here is the updated structure in boot1.s:
  /*  From OpenBSD biosboot.S with tuned values from Doug Ambrisko so 
  ThinkPads can boot from CDROM.  I think the critical part
  is setting the media type.
  */
  .org 0x03, 0x00
  .asciz  "FreeBSD"
  /* BPB */
  .org 0x0b, 0x00
  bpb:.word   512 /* sector size */
  .byte   1   /* sectors/cluster */
  .word   1   /* reserved sectors */
  .byte   2   /* # of FAT */
  .word   224 /* root entries */
  .word   2880/* small sectors */
  .byte   0xf0/* media type (fd) */
  .word   144 /* sectors/fat */
  .word   18  /* sectors per track */
  .word   2   /* # of heads */
  
  /* EBPB */
  .org 0x1c, 0x00
  ebpb:   .long   16  /* hidden sectors */
  .long   0   /* large sectors */

Mark, wanted me to clarify the the BIOS is only changing stuff in
the emulated image and not the media itself.

I think something needs to be done for the linking because it is
really frustrating when stuff changes and there are no warnings
or hints why things just all of a sudden break when a simple change
is made.  Either that or huge warnings saying:

/* "xread" is a hardcoded value in boot2.c, if you change 
   the layout in boot1.s figure out what the new value is
   and then update it in boot2.c */

I like computers to think for me so I don't have to.  I tend to 
make more mistakes then they do!

Thanks for looking at it, any idea on what needs to be done to get this
commited?  I'm currently testing my final patch for ThinkPads but
it takes a while to burn a FreeBSD release CD on a slow 2X burner.

Obviously it would make our lives easier if we can just load things
on the IBM hardware we have around here and reduce traffic on -questions!

Doug A.

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

Fix for CDROM boot for IBM PC desktops

[Doug Ambrisko]

On on IBM PC desktops a FreeBSD bootable CDROM won't boot and it hangs.  
This has been reported in several places.

The problem is that some BIOSes namely IBM's writes to the boot sector
of the floppy to potentially update the parameters for the emulated
floppy used for the El Torrito boot.  Since we do not allocate space
for a typical MSDOS "Boot Sector" when the BIOS updates this area
it then ends up modifying the boot code which is not a good thing.
The boot code then fails in random ways.  I also did a work-around
for linking the address of "xread" into boot2.c.

The fix is in PR i386/26382:
http://www.freebsd.org/cgi/query-pr.cgi?pr=26382
This would be great to get into 4.3 but probably won't make it.

Thanks, 

Doug A.

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

Re: FreeBSD on S/390?

[Doug Ambrisko]

Robert Watson writes:
| On Wed, 28 Feb 2001, Ken Bolingbroke wrote:
| > Long shot, probably, but I've got a bunch of virtual machines on an IBM
| > S/390 mainframe, and while we're running SuSE Linux on most of them, on
| > a whim I tossed out the idea of running FreeBSD on one of them, and to
| > my surprise, it was taken seriously. 
| > 
| > So, has anyone done any work with getting FreeBSD running on a S/390? 
| > What can I do to make it happen if there's interest? 
| 
| fairly serious gap, and would like to remedy this.  However, IBM hasn't
| been dropping S/390 machines and documentation in anyone's laps (at least,
| not mine, and no one else has mentioned it), so the primary facilitators
| would be, as with any new hardware port:
| 
| 1) Access to necessary technical documentation and expertise
| 2) Access to hardware

I would suggest people look at 
http://www.conmicro.cx/hercules/
It is "an open source software implementation of the mainframe System/370 
and ESA/390".  So the first step would be to port that to FreeBSD and
then you sort of have the hardware.  It is supposed to run the Linux 390 
port.  I would think this would be a good starting point and
since the emulator is open source it should be easier to figure out
how the machine works.

Doug A.
Standard disclaimer applies

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

Re: boot1 changes and etherboot support

[Doug Ambrisko]

Warner Losh writes:
| In message <[EMAIL PROTECTED]> Luigi Rizzo writes:
| : > We'd also be able to load the kernel out of ROM :-)
| : 
| : the whole issue is the size of the ROM isn't it ?
| 
| Yes.  I saw a few datasheets for embedded systems that have 2M or 4M
| of flash.  Some of that is for the BIOS, but part of it can be used
| for a system image.  That's a very common thin on other platforms as
| well.

Is this bits or bytes.  The Intel firmware hub can have 4 or 8 Mbits that
comes with any Intel 8XX system so with gzip you could fit a bunch of 
stuff in a standard off the shelf motherboard.  Also CMOS memory is 
increasing and that could be used for some configuration info to be 
used as non-flash persistant storage such as IP address and such.  Also
having a small BIOS image like General Software would help save space.

Doug A.


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

Re: SCTP implementation and pccard.conf change for Cisco 802.11B 340series cards

[Doug Ambrisko]

Jonathan \"Taz\" Mischo writes:
| I am currently at IETF 49, where I have moved from my old wi card to the
| 
| new Cisco 342, which is an an card, since Cisco acquired them.  The 342
| does 128-bit or less encryption at 11 meg, thus it was a worthy
| investment.  However, pccard.conf does not have an entry for the card,
| since it was JUST released.  The appropriate entry is:
| 
| #Cisco 340 series 802.11B wireless NICs
| card "Cisco Systems" "340 Series Wireless LAN Adapter"
| config  0x5 "an" ?
| insert  /etc/pccard_ether $device
| remove  /sbin/ifconfig $device delete

It's in -stable and maybe 4.2
 
| This allows the Cisco 34x  cards to work, including the 342.  One
| caveat, however...I haven't looked at the source, yet, but it is pretty
| safe to assume that 128-bit at 11meg support is not in the driver.  I

Well you are sort-of right ... look at -current and it's there.
Patches for stable are at http://www.ambrisko.com/doug/an.patch.wep3
for the latest greatest stuff.

Several people have this code in use for a while.  I've been collecting
patches and posting diff's at my website and sending announces to mobile.
With the latest diff's I haven't heard of any new wishes or problems.

Archie just commited the patches to -current and should MFC fairly soon.

BTW I just remembered a bug in that you can't do the ancontrol stuff
unless you ifconfig the interface.  I need to look at this.  I forgot 
about it a long time ago when I just worked around it so it doesn't
bite me .. except when I just setup a machine.

Doug A.


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

Re: VMware hanging -- Memory deadlock?

[Doug Ambrisko]

Barry Lustig writes:
|   I have a vaio z505le with 192MB running 4.2-STABLE (cvsupped today).  I've  
| been trying to get vmware running properly on it.  I first configured vmware  
| on the vaio, created a win2k type virtual disk, set ram in the VM to 80M,  
| and copied a happily working win2k virtual disk from another system over the  
| skeleton one that the config wizard created.  I'm running the latest port of  
| XFree86 4.0.1.
| 
|   Each time I start vmware the system gets part of the way through the VM  
| boot process and then hangs.  The only thing that still responds is the  
| mouse.  A top process running in an xterm locks up, as does the getty on the  
| serial console.  I can break into ddb from the serial console.  I've found  
| that dropping the memory size for the VM down to 64MB works (68MB doesn't).   
| When running the 64MB VM top shows:
| 
|   70M Active, 34M Inactive, 75M Wired, ~9M Cache, 29M Buf, ~6M Free
| 
| Does anyone have any suggestions on how to debug this?

No, but going back to 4.2 RELEASE kernel fixed it for me.  Start from
there and move forward until you find out which commit broke it.

Doug A.


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

Re: dhcp boot was: Re: diskless workstation

[Doug Ambrisko]

John Hay writes:
| > | > You don't, it is done via the bootp or dhcp record option 128 for example
| > | >   option option-128 "192.168.2.254:/usr/work/netboot";
| > | > You then have to make the swap file in that directory of format
| > | >   swap.
| > | > Use dd to create the file by copying /dev/zero for the size you want.
| > | > 
| > | > Note during boot up the kernel will tell you what it is using for 
| > | > swap via this request.
| > | 
| > | The option-128 confuse the pxeboot program. If I put
| > | 
| > | option root-path "/export/diskless";
| > | option option-128 "10.1.2.3:/export/shark";
| > | 
| > | in the dhcpd.conf file, pxeboot tries to mount /export/sharkM-^[^B-i?
| > | as the root filesystem. Removing the option-128 line at least get me to
| > | boot albeit without swap.
| > 
| > Root path should have the IP address of the server such as:
| >option root-path "192.168.2.254:/usr/home/ambrisko/netboot";
| > 
| > Then in boot messages you should see:
| > rootfs is 192.168.2.254:/usr/home/ambrisko/netboot
| > swapfs is 192.168.2.254:/usr/work/netboot
| > 
| 
| Yes, you are right. Putting the ip number in the root-path cures the
| pxeboot failure. But is still only configure the NFS ROOT according
| to the kernel's output. I had a look at the pxe code in
| /sys/boot/i386/libi386/pxe.c where pxeboot is built from and in
| /sys/i386/i386/autoconf.c which is the kernel side and it looks like
| they don't do anything about swap. There is a /* XXX set up swap? */
| placeholder though. :-)

Yep looks like you're right, I just tried it on 4.2-BETA it worked in 
4.1.1.  Swap is now broken ... sigh this is going to be a problem.  I 
guess the only thing you might be able to do in the interim is to do a 
vnconfig of a file and then mount that as swap.  I think the vnconfig 
man pages describes this.  Hopefully it works over NFS.

Doug A.


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

Re: dhcp boot was: Re: diskless workstation

[Doug Ambrisko]

John Hay writes:
| > You don't, it is done via the bootp or dhcp record option 128 for example
| >   option option-128 "192.168.2.254:/usr/work/netboot";
| > You then have to make the swap file in that directory of format
| >   swap.
| > Use dd to create the file by copying /dev/zero for the size you want.
| > 
| > Note during boot up the kernel will tell you what it is using for 
| > swap via this request.
| 
| The option-128 confuse the pxeboot program. If I put
| 
| option root-path "/export/diskless";
| option option-128 "10.1.2.3:/export/shark";
| 
| in the dhcpd.conf file, pxeboot tries to mount /export/sharkM-^[^B-i?
| as the root filesystem. Removing the option-128 line at least get me to
| boot albeit without swap.

Root path should have the IP address of the server such as:
   option root-path "192.168.2.254:/usr/home/ambrisko/netboot";

Then in boot messages you should see:
rootfs is 192.168.2.254:/usr/home/ambrisko/netboot
swapfs is 192.168.2.254:/usr/work/netboot

Doug A.


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

Re: dhcp boot was: Re: diskless workstation

[Doug Ambrisko]

John Hay writes:
| > > the dhcp.xxx stuff is easy, the problem is that the DHCP options are not
| > > enough, so im trying to look into defining a FBSDclass ala PXEClient, and
| > > supplying stuff like usr-ip/usr-path swap-ip/swap-path or whatever.
| > 
| > You don't need those; you can get them out of /etc/fstab.  In particular, 
| > the whole idea of passing the NFS swap details in at this stage is just 
| > *totally* bogus.
| 
| How do you specify nfs swap in the fstab file? I have been trying the

You don't, it is done via the bootp or dhcp record option 128 for example
  option option-128 "192.168.2.254:/usr/work/netboot";
You then have to make the swap file in that directory of format
swap.
Use dd to create the file by copying /dev/zero for the size you want.

Note during boot up the kernel will tell you what it is using for 
swap via this request.

Doug A.


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

Re: WEP keys for an driver

[Doug Ambrisko]

Brooks Davis writes:
| On Mon, Oct 09, 2000 at 11:42:32AM -0700, Dave Cornejo wrote:
| > Some comments on your code:
| > - WEP keysare variable length from 5-13 bytes, you should just check for
| > >=5 & <=13 (it seems odd, but I have seen networks that use the odd
| > sizes).
| 
| Since all the windows drivers I've looked at only allow 0, 5, and 13
| byte keys, I'd suggest only allowing those values.  That's what
| wicontrol does.

That's what I recall from Windows and I allow 0, 5 or 13 characters as
0   -> erase key
0xDD-> set 40 bit
0xDD-> set 128 bit
I also verified it did the right thing by booting back into Windows and
then running the WEP utility to see if it made the right change.  Also
did it as hex since that is what the WEP utility did.  The code would
probably work with ASCII strings but how do you encode 0-255 as a character
in an ASCII string?  BTW my test string was 0x001122334455 (for 40 bit).
Originally I wasn't doing a 40 bit or 128 and things didn't work.  Once
I started doing 40 bit or 128 bit keys then things worked fine.  Since
the programming doc didn't say anything about that I burned a few days on 
that :-(
 
| > I didn't provide patches to ancontrol as you did, but I find ancontrol
| > is getting way too nasty with its switches.  Your patches look fine
| > to me except that I'd really like to see a better way to specify
| > volatile vs. persistent keys.  
| 
| You need to add ancontrol support or the patch is basicaly useless.  I'm
| looking forward to some sort of working crypto support for the aironet
| cards.

Well if you just download mine for now again at 
www.ambrisko.com/doug/an.patch.wep
That will get you going.  Some people other then myself are using it with
success.  It looks like it will get some more features since it looks
like he has gleaned some more knowledge then I was told.

Give it a try and let me know if you run into a problem.

Doug A.


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

Re: WEP keys for an driver

[Doug Ambrisko]

Dave Cornejo writes:
| It doesn't matter to me which version gets used - I just need the
| capability to set the WEP keys.
| 
| Some comments on your code:
| - WEP keysare variable length from 5-13 bytes, you should just check for
| >=5 & <=13 (it seems odd, but I have seen networks that use the odd
| sizes).

Really ... I need to check the WEP configurator again on Windows.  I thought
when I tried it it only let me do 40 or 128 not in between.  Also it also
it only excepted a hex string (the base code from wicontrol accepted an
ASCII string as well).
 
| - In an_setkeys() you allow 28 characters, the error message says 18,
| but really only 13 are significant.

Right 28 = max of "0x" + 2 * byte (5 or 13).  So 2 + 2 * 13 = 28.

That 18 sounds like a bug (stale cut'n'paste).

| - The AN_RXMODE_LAN_MONITOR_CURBSS was a good catch - I never tested
| that one.

Running tcpdump kept bitting me.  Hey why did ping stop :-( 
 
| - The authentication handling in ancontrol is in error: there is no
| AN_AUTH_TYPE_EXCLUDE_UNENCRYPTED bit.  I should have added constants
| for the correct values for the authentication type.
| 
|   0x000x - no encryption
|   0x010x - full encryption
|   0x030x - mixed cell (allow unencrypted)

In my manual on page 7-51 in the table for General Configuration Parameters:
+0x003E AuthenticationType
0x01Open
0x02Shared-Key
0x04Exclude Unencrypted
So this is were I got it.  I have DOC 710-004247, Rev B1.

I'm not sure what you are reading or maybe talking about.  It almost sounds 
that you are talking binary instead of hex.  BTW I didn't ever get
"Exclude Unencrypted" to do anything usefull if I recall.  So maybe
my documentation is wrong.  If you have a newer one could you send it
to me?  I'm on my second version of the manual.

| despite what's in the driver, bit 2 (0x0004) is not used.  The bits as
| defined by Aironet engineering:
| 
| #define AN_AUTHTYPE_PRIVACY_IN_USE 0x0100
| #define AN_AUTHTYPE_ALLOW_UNENCRYPTED 0x0200

AN_AUTHTYPE_ALLOW_UNENCRYPTED seems to be a new one.  Actually the are
both not listed in my manual.  I derived it from the posting by an
Aironet engineer on the Linux driver mailing list.  Where did you 
find out about 0x100 & 0x200?
 
| I would like to see my structure changes checked in - there are an
| error or two and some interesting new elements in there.  In some more
| recent radio firmware, they provide normalized RSSI, and the IP
| address of the base station.  There are also a few other things hinted
| at in there that some may find interesting.  I should however add in
| some more constants.

I don't have any problem with that.  I was just worked on getting WEP going.

| I didn't provide patches to ancontrol as you did, but I find ancontrol
| is getting way too nasty with its switches.  Your patches look fine
| to me except that I'd really like to see a better way to specify
| volatile vs. persistent keys.  

Agreed.  It did not fit in with the "primative" model that the WaveLan
cards use.  I tried to make it as clean as possible with the 3 flags:
  - set any key
  - set mode
  - turn WEP on/off (looks like this needs to be expanded to 
 allow unencrypted traffic)
Unfortanetly I has to do some stuff in ancontrol to virtualize the 
different register for the last 2 since they are munge into on but
should but are treated separetly in the Windows UI.  Linux just
sets them for and doesn't give you this flexibility so you may not
be able to interoperate in a valid windows network.

However, without the ancontrol changes it becomes difficult to set these 
things from a user perspective.

Thanks for the review.

Doug A.


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

Re: WEP keys for an driver

[Doug Ambrisko]

Dave Cornejo writes:
| my apologies if i am not following the correct procedures here...
| 
| I have submitted a patch in PR kern/21843 which adds WEP key support
| to the an driver.  This is my first attempt at messing with driver
| code so any constructive criticism is appreciated.
| 
| I have tested the patch with the hardware available to me and it seems
| to work well (I've used Aironet firmware 3.98 & an as yet unreleased
| version).

Looking at the code I don't see this as a complete solution.  Maybe that
is what you mean by: 
The ioctl interface used to configure the card does not include 
a way to set WEP keys

If you look at http://www.ambrisko.com/doug/an.patch.wep.  It includes
the changes to both sides to enable WEP in the various modes and the
various keys.

I've been to busy to submit this, but I finally did today.  Some people
have been using this code with success.

Doug A.


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

Re: freebsd port of netboot?..

[Doug Ambrisko]

Peter Wemm writes:
| Warner Losh wrote:
| > In message  Christopher Stein
|  writes:
| > : .. does anyone know if this exists? It would
| > : speed up the panic-edit-compile-boot-copy-boot kernel hacking 
| > : cycle by transforming it to panic-edit-compile-netboot.
| > 
| > I usually mount everything readonly when I try a new module just
| > before loading it.  It saves a tone of time.  All I gotta fsck on the
| > way back up is /var since it won't mount ro after syslog starts, which 
| > makes sense if you think about it.
| > 
| > mount -ur /
| > mount -ur /usr
| > moutn -ur /junk
| > 
| > is what I have in a script.  After it succeeds, I do a mount -uwa
| > which updates all the mounts.
| > 
| > You can also netboot via a ROM on your ethernet card or via floppy,
| > but I've not done that.  The above works well enough for me.
| 
| Also, if you have a PXE-aware network card or bios, netbooting
| with a small ramdisk is very convenient for crash-and-burn testing.

Since vmware doesn't do PXE, etherboot works nicely with it.  This way
you can neboot your vmware session and with Julians psuedo serial port 
thing you have a nice environment.

Doug A.


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

Re: PXE (pxeboot) and serial consoles - force it!

[Doug Ambrisko]

Paul Saab writes:
| Doug Ambrisko ([EMAIL PROTECTED]) wrote:
| > Paul Saab writes:
| > | set console="comconsole" is what you want in /boot/loader.rc
| > 
| > Yep, except that it doesn't initialize the com port, it just starts
| > using it so you end up with junk out the port.  However, if you have a
| > BIOS that setups the baud rate etc. of the serial port then you would
| > be okay.  Current FreeBSD does this in the boot blocks and not the loader.
| 
| Umm.. That isn't the case at all.  I use it all the time and it surely
| does init the com port.

Yep, you're right I just tried it and it worked.  I tried a similar thing
once before with the loader and it failed for some reason to setup the serial
port.  Thanks for the enlightenment, it will be usefull.

Doug A.


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

Re: PXE (pxeboot) and serial consoles - force it!

[Doug Ambrisko]

Paul Saab writes:
| set console="comconsole" is what you want in /boot/loader.rc

Yep, except that it doesn't initialize the com port, it just starts
using it so you end up with junk out the port.  However, if you have a
BIOS that setups the baud rate etc. of the serial port then you would
be okay.  Current FreeBSD does this in the boot blocks and not the loader.

Doug A.


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

Re: PXE (pxeboot) and serial consoles - force it!

[Doug Ambrisko]

Alan Edmonds writes:
| 
| I'm playing with PXE and pxeboot.   I have a question about
| setting the serial console option.  The PC BIOS reports 
| 'No Keyboard Present', but when PXE boots, BTX reports
| console as internal keyboard/video.  So, I'm looking at
| hard coding a serial console into BTX.  Normally, you
| put the -h option into /boot.conf, but PXE doesn't
| read that.  I tried putting console=comconsole into
| /boot/loader.rc, but it didn't work quite right.
| I modified src/sys/boot/i386/common/conf.c and
| removed the vidconsole option and that worked.
| I could set the flags in the kernel to 0x20 to
| force serial and that worked.

I think the issue is that the loader (ie pxeboot in this case) does not
initialize the COM port.  So in the case in which you don't have the 
boot block initialize the COM port (ie the -h option) then you get
garbage out the serial port at best.  I ran into the same problem.

So it works fine from the boot blocks but is broken otherwise.  To fix
this the loader need to initialize the COM port.  However, this means
it needs to know the baud rate etc.  So you would have to set it 
in the boot block and in the loader or am I missing something.
I assume the loader didn't set this so people changing the baud rate
wouldn't have to do it all over the place.

If someone provides more insight then I should be able to make the
required changes and submit them.

Doug A.


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

Re: Removing interfaces

[Doug Ambrisko]

Nick Hibma writes:
| 
| if_kue, if_aue or ask Doug Ambrisko for a copy of the udbp (USB double
| bulk pipe) driver that should have that as well.

The udbp doesn't do it since it just creates a netgraph node.  Then you
tie that netgraph node to an interface.  At that point netgraph makes
an interface called ngX.  When you remove the USB widget then a new
netgraph node is created (the old one destroyed) and then you connect this
netgraph node to an interface which is ng(X+1)).  This is what Archie
is trying to avoid.  So no udbp is not a example until Archie fixes
netgraph.  However, he could look at if_kue, if_aue, or the various
pccard ethernet adapters in -current since they all seem to work.

Archie you should upgrade your laptop to -current.  Then you could
go wireless with it and see the anX interface come an go.  Also you
could play with USB ethernet widgets and USB modem floating around
here (BTW Nick it almost works with your umodem.c driver on your 
web page.  The only problem I see is that it doesn't see loss of
CD).

Doug A.

| On Wed, 2 Feb 2000, Archie Cobbs wrote:
| 
| > With all the PCMCIA card stuff going on, is it now possible to
| > remove a networking interface in FreeBSD (from within the kernel)?
| > 
| > If so could someone show me an example how. I'd like to implement
| > this in the ng_iface(8) netgraph node type.


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

Re: Possible solution for USB Ethernet problem

[Doug Ambrisko]

Bill Paul writes:
| Previously I mentioned that I was having trouble sending full sized
| ethernet frames (1500 bytes) over USB using my ADMtek AN986 Pegasus
| eval board. The problem turned out to be in the uhci driver, however
| I'm not certain exactly how to incorporate my fix.
| 
| The problem I was seeing was that large frames would trigger babble
| errors, which would cause an endpoint halt and wedge the RX or TX pipe.
| Julian brought up another driver written by Doug Ambrisko which appeared
| to be able to transfer 1500-byte frames without any trouble. However,
| neither he nor Doug bothered to mention if their test machines had UHCI
| or OHCI hubs. Given what I've learned, I suspect they were OHCI.

We used both OHCI to itself for initial debugging then an OHCI machine to
UHCI and a UHCI to UHCI.  So it didn't seem that saying what stack we used
was important since they both worked for us.  This was -current as of a
week or so ago.

We did run into an issue with OHCI, in that if we plugged in any USB device
after the machine was booted we would get the td_??? panic.  So we had
to have the device plugged in when we booted the machine.  After the
machine was up we could unplug it and plug it back in.

For testing we did ping's and ftp's of /kernel and it worked okay.
I also ran netperf and got 3.4Mbits/sec with MTU's of 900 & 1500.

So we are not saying the USB stack is perfect, but it worked for us.

Doug A.


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

Re: USB ethernet hacking

[Doug Ambrisko]

Julian Elischer writes:
| 
| 
| On Sun, 19 Dec 1999, Bill Paul wrote:
| > > 
| > >  We just copied the data from the mbuf into a dedicated
| > > buffer and freed the mbuff immediatly.
| > 
| > Did you just allocate a buffer with malloc() (or contigmalloc()), or
| > did you use usbd_alloc_buffer()?
| 
| ummm I don't have the driver with me here.
| 
| Doug Ambrisko has is so we'll send it to you as soon as he reads this I
| guess.

Technical note, device only has an internal 15*64 (960) byte buffer.  1500
MTU's work fine and no performance hit over a 900 byte MTU.  We just let
the USB stack do what it has to do, we only talk to it in complete 
ethernet packets.

http://www.ambrisko.com/doug/udbp.tgz

>From the README:

Apply the patch relative /usr/src

Add udbp to kernel or do kld thing.

Once the device is up use ngctl (netgraph control) to connect it to an
interface (this could be done via usbd.conf).

ngctl connect udbp0: ng0: data inet 
|| ngctl mkpeer udbp0: iface data inet
ifconfig ng0 192.168.1.1 192.168.1.2

Works with Anchor EzLink and with minor change should support NetChip
devices.  You will have to add the device & vendor id info.

Nick gave us the raw USB code, Julian supplied the netgraph code
and I helped bug fix and bridge the gaps.

Doug A.


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

Re: pccard disruptions : how did it go?

[Doug Ambrisko]

Warner Losh writes:
| In message <[EMAIL PROTECTED]> Michael Kennett writes:
| : I've just scoured the archives, and found a thread from late October 1999
| : titled:
| : Massive pccard disruptions to continue
| : 
| : So, have these disruptions continued? And what is the current status with
| : pccard support in the kernel?
| 
| The new pccard code is still being worked on.
| 
| However, the old pccard code mostly works again, modulo a couple of
| if_detach issues that I'm trying to work through.
| 
| : I've noticed that a few files still contain the PCCARD_MODULE macro
| : - in particular, the dev/pccard/if_xe.c Xircom driver.  I'm
| : interested in getting the if_xe.c driver to work under -current
| : (12-Dec sources).  I'd be interested in any ideas on how to convert
| : the old if_xe.c driver to the 'newbus' code.  (I'm not familiar with
| : either the old PCCARD_MODULE, or the newbus code.)
| 
| The if_xe and if_fe drivers no longer work for pccard.  You may wish
| to investigate how the ep and ed drivers were converted.  There is one
| issue with the if_xe driver, namely it needs to access the CIS of the
| card to determine which kind of card it is and that will need some
| work in -current to get working again...

I will try to take a look at the Xircom driver and try to newbus it after
I finish some work on the Arionet driver (It's annoying have to deal with
non robust dongles and then I don't have to carry a modem & 2 ethernet
adapters).  However, Linksys has an interesting card .. unfortunately 
you can't stick 2 of them in at the same time.

Doug A.


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

Re: netbooting on fxp0?

[Doug Ambrisko]

David Gilbert writes:
| The current batch of IBM etherjets (probe as fxp0) have dhcp-enabled
| boot ROMs built into them.  What is required to support these, or has
| someone worked on this already.   100Mb cards could make a decent
| diskless workstation/server.

Look at ports/net/etherboot.  It supports fxp0 and booting FreeBSD ELF
kernels as well as Linux and DOS.

Doug A.


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