Re: /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefinedsymbol "__stdoutp"

[M. Warner Losh]

: Warner, could you please add "__stdoutp" to the 20010919 entry, and
: a hint to put COMPAT4X=true to /etc/make.conf to the 20010924 entry?

Done.

Warner

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

Re: /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefinedsymbol "__stdoutp"

[M. Warner Losh]

> Warner, could you please add "__stdoutp" to the 20010919 entry, and
> a hint to put COMPAT4X=true to /etc/make.conf to the 20010924 entry?

Actually, you only need the first one.  You don't need COMPAT4X=true
all the time, so I'm a little reluctant to include that.  Lemme know
how I can improve what I just committed.

Warner

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

Re: Dropping bsd.man.mk support from bsd.kmod.mk

[M. Warner Losh]

> I'd like to drop bsd.man.mk support from bsd.kmod.mk,
> because I was told by someone (peter?) that this is
> the right direction.  :-)

We use it slightly at Timing Solutions, but it is more of a pain than
a blessing.  More of our module Makefiles have NOMAN than don't, by a
wide margin.

Warner

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

Re: Dropping bsd.man.mk support from bsd.kmod.mk

[M. Warner Losh]

: And now I recall.  Peter told me that at some
: point there will be no sys/modules at all.

I'm not objecting.  We don't use sys/modules, but do use bsd.kmod.mk
to build our drivers outside of the sys tree.  Any successor to
sys/modules must allow this (ideally with the same makefiles we have
now, or very similar).

Warner

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

Re: PC Card hang

[M. Warner Losh]

From: Jim Bloom <[EMAIL PROTECTED]>
Subject: PC Card hang
Date: Tue, 27 Nov 2001 19:26:04 -0500

: My laptop is hanging when I boot it after this commit.  The system hangs
: when pccardd is started.  If no cards are installed, the boot proceeds
: without a problem and the system hangs when the first card is inserted.
...

:   Modified files:
: sys/pccard   i82365.h pcic.c pcic_isa.c pcic_pci.c 
:   Log:
:   o Try to do 3.3V support better for the 6722 and 6729/30.
:   o Bite the bullet and create controller types for the 6729 and also
...
:   Revision  ChangesPath
:   1.23  +18 -5 src/sys/pccard/i82365.h
:   1.169 +32 -14src/sys/pccard/pcic.c
:   1.23  +3 -3  src/sys/pccard/pcic_isa.c
:   1.106 +5 -5  src/sys/pccard/pcic_pci.c

Did this get resolved?

Warner

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

Re: PC Card hang

[M. Warner Losh]

: I haven't built a new kernel since I had got it working (by fetching
: the version before the commit).  I haven't noticed any commits that
: might have been related to fixing this but I'm a couple weeks behind
: on reading cvs-all.

OK.  I'll keep that in mind.  I'm in a bit if a time crunch until
after the first of the year.  I can't seem to find where you told me
which bridge chipset you were using.  Presumably it is a 6729/6730?

Warner

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

Re: PC Card hang

[M. Warner Losh]

: The chipset is reported as a 6722 by the newer kernels that do not
: work. I will forward the earlier e-mails to you.

OK.  Thanks Jim.  I'll see what I can do.

Warner

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

Re: SMP system hangs on current, not stable

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Oliver Fromme <[EMAIL PROTECTED]> writes:
: This can also be done
: with PCI slots, if that board doesn't have an ISA slot
: anymore, but I don't know which pins (it's _not_ the first
: two pins), and it's a lot more difficult because the PCI
: pins are much smaller.

I don't think it is that simple.  The PCI bus has timing issues that
mean that shorting just two pins likely isn't going to work.  MS has a
design for generating SERR when you press a button, but it does a lot
of stuff to make sure that the signal is asserted at the right time.

I know that my simple experiments with doing this have ended in
failure...

Warner

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

Re: Why does bus_alloc_resource fail for sound and PCIC?

[M. Warner Losh]

You might want to try and enable PCI_ENABLE_IO_MODES in your kernel.

Warner

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

Re: Why does bus_alloc_resource fail for sound and PCIC?

[M. Warner Losh]

In message: <20020105232557.S706-10@nihil>
Michael Reifenberger <[EMAIL PROTECTED]> writes:
: But why?
: Where is PCI_ENABLE_IO_MODES different from:
: 
: pci_enable_busmaster(dev);
: pci_enable_io(dev, SYS_RES_IOPORT);
: pci_enable_io(dev, SYS_RES_MEMORY);
: 
: or
: 
: data = pci_read_config(dev, PCIR_COMMAND, 2);
: data |= (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN | PCIM_CMD_BUSMASTEREN);
: pci_write_config(dev, PCIR_COMMAND, data, 2);
: 
: which allready existed in snd_ich ?!?

I think it has to do with the caching of these values in the pci
layer.  The option turns them on and updates the values in the cache,
while the other options do not appear to do so.

: BTW: In the case of the PCIC I still get:
: pcib2:  at device 30.0 on pci0
: pci2:  on pcib2
: pccbb0:  mem 0x5000-0x5fff irq 11 at device
: 0.0 on pci2
: pcib2: device pccbb0 requested unsupported memory range 0x5000-0x5fff
: (decoding 0xc020-0xcfff, 0xe800-0xefff)
: pccbb0: Could not map register memory
: device_probe_and_attach: pccbb0 attach returned 12
: pccbb0:  mem 0x5010-0x50100fff irq 11 at device
: 0.1 on pci2
: pcib2: device pccbb0 requested unsupported memory range 0x5010-0x50100fff
: (decoding 0xc020-0xcfff, 0xe800-0xefff)
: pccbb0: Could not map register memory
: device_probe_and_attach: pccbb0 attach returned 12

Maybe you need some patches to the pci bridge code to map the range
requested, or to just allow it (since it just works anyway).  There's
another kludge option: PCI_ALLOW_UNSUPPORTED_IO_RANGE.

Warner

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

Re: installkernel broken - if.wi.ko

[M. Warner Losh]

In message: <001601c19bf8$04c1f7e0$ae60dacb@joannaraman>
"Raman Ng" <[EMAIL PROTECTED]> writes:
: I have cvsup the source (current) yesterday that is about 14 hours ago.
: Buildworld and buildkernel without any problem.  However, when I tried to
: installkernel the following error is found.
: kldxref /boot/kernel
: *** Error code 1 (ignored)

Don't worry about it.  you build and installed -current on a -stable
machine.

Warner

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

sudo busted after recent upgrade to -current

[M. Warner Losh]

OK.  I did a make buildworld/installworld.  I did a mergemaster and
made sure that /etc/pam.d was there.  I also rebuilt sudo 1.6.4 via
the ports system (I changed the version number there from the old one
to this).  However, now when I type sudo it says, after getting my
password:
sudo: pam_setcred: Permission denied.
It also whines on the console if I remove /etc/pam.conf.

Ideas?  This is from Saturday's current at about 4am MST.

Warner


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

Re: sudo busted after recent upgrade to -current

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
John Baldwin <[EMAIL PROTECTED]> writes:
: 
: On 14-Jan-02 M. Warner Losh wrote:
: > OK.  I did a make buildworld/installworld.  I did a mergemaster and
: > made sure that /etc/pam.d was there.  I also rebuilt sudo 1.6.4 via
: > the ports system (I changed the version number there from the old one
: > to this).  However, now when I type sudo it says, after getting my
: > password:
: >   sudo: pam_setcred: Permission denied.
: > It also whines on the console if I remove /etc/pam.conf.
: > 
: > Ideas?  This is from Saturday's current at about 4am MST.
: 
: Do you have a /etc/pam.d/other?

YES.

Warner

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

Re: sudo busted after recent upgrade to -current

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
John Baldwin <[EMAIL PROTECTED]> writes:
: Sheesh, ok. :)  I had a problem with sudo a while back due to pam not falling
: back to other in pam.conf properly when the pam.d dir existed.  Have you tried
: copying /etc/pam.d/other to /etc/pam.d/sudo?

No.  I haven't   but it doesn't matter.  Same thing.

Warner

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

sudo redu

[M. Warner Losh]

OK.  This looks like a problem in 1.6.4p1 of sudo.  It isn't a problem
with 1.6.3p7_2.  1.6.4 works on -stable, but not -current.  It
apparently added a call to pam_setcred:

453) Now call pam_setcreds() to setup creds for the target user when
 PAM is in use.  On Linux this often sets resource limits.

Warner

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

Re: Melco LPC4-CLX-CB support in 5.0-Current NEWCARD

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Shizuka Kudo <[EMAIL PROTECTED]> writes:
: kernel: found->vendor=0x10ec, dev=0x8138, revid=0x10
...
: kernel: cardbus0:  (vendor=0x10ec, dev=0x8138) at 0.0 irq 11.

Try adding this ID to the dc driver?

Warner

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

Re: Melco LPC4-CLX-CB support in 5.0-Current NEWCARD

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
        "M. Warner Losh" <[EMAIL PROTECTED]> writes:
: In message: <[EMAIL PROTECTED]>
: Shizuka Kudo <[EMAIL PROTECTED]> writes:
: : kernel: found->vendor=0x10ec, dev=0x8138, revid=0x10
: ...
: : kernel: cardbus0:  (vendor=0x10ec, dev=0x8138) at 0.0 irq 11.
: 
: Try adding this ID to the dc driver?

Obviously I wasn't paying attention to the rest of the thread.  Please
ignore this.

Warner

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

Re: __stderrp error

[M. Warner Losh]

Some -current binaries can have this, but recompiling usually fixes
it.  Also, I have some older 3.x binaries that I had to install
COMPAT3 to get working.

Warner

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

Re: NEWCARD and Xircom (RBEM56G-100)

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Tom Fischer <[EMAIL PROTECTED]> writes:
: Warner, do you have any clues on how to get the modem half of this
: card working again?

You'd have to a) fix the pci attachment or b) wait until the puc
driver hits the tree.  Chances are fixing the pci attachment in the
short run would be easy enough.

Warner

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

Re: __stderrp error

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Julian Elischer <[EMAIL PROTECTED]> writes:
: this machine has never been 3.x.
: the binaries worked fine up until about 5 months ago.

All bets are off if it ran -current.  You need to rebuild everything.

Warner

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

Re: __stderrp error

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
"David W. Chapman Jr." <[EMAIL PROTECTED]> writes:
: On Mon, Jan 21, 2002 at 12:54:38PM -0700, M. Warner Losh wrote:
: > In message: <[EMAIL PROTECTED]>
: > Julian Elischer <[EMAIL PROTECTED]> writes:
: > : this machine has never been 3.x.
: > : the binaries worked fine up until about 5 months ago.
: > 
: > All bets are off if it ran -current.  You need to rebuild everything.
: > 
: 
: Ah yes, I remember this problem with -current.  Something changed and 
: I had to rebuild everything including ports or install the 4.x compat 
: libs.

If you are using 4.x compat libraries they needed to be reinstalled.
If you are using libc from -current, you must rebuild all binaries
that use them.  Those are the breaks.

Warner

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

Re: __stderrp error

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Julian Elischer <[EMAIL PROTECTED]> writes:
: I reinstalled the 4.x compat libs but it didn't make any difference.:-(

Then you must have -current binaries that are too old.  You will have
to rebuild them.

Warner

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

Re: telnetd broken in -CURRENT

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Vincent Poy <[EMAIL PROTECTED]> writes:
: > You should:
: > ln -sf aj /etc/malloc.conf (As ROOT)
: 
:   Hmmm, what does that do exactly?  I don't have a file name aj
: (what directory should it be in?) and I don't have a /etc/malloc.conf file
: either which I assume is a symlink to aj.

You don't need to have the target of the symlink.  malloc does a
readlink to get its options to save disk accesses...

Warner

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

Re: *_enable="YES" behavior is bogus

[M. Warner Losh]

In message: 
Garance A Drosihn <[EMAIL PROTECTED]> writes:
: In this discussion, there have been two suggestions as to how
: 'firewall_enable=no' should behave.
: 1) if the firewall is compiled in the kernel, then "=no"
:means that the firewall is blocking all packets, no
:matter what other rules might be lying around.  The
:machine is completely locked down from network access
:(ie, the present behavior).
: or 2) no matter how the kernel is compiled, "=no" means the
:machine acts as if there is no firewall installed.  Ie,
:it accepts all packets.  No packets are blocked.  The
:machine is wide open.
: 
: If the user *expects* 1, but we actually implement 2, then the
: machine is wide-open when they did not expect that.  My position
: is that we can *easily* do something to help that person
: immediately realize that they did not get what they expected.
: 
: If the user *expects* 2, but we implemented 1, then the machine
: is locked down.  If the user is not sitting at the console of
: the machine, then there is absolutely nothing which can be done
: (from a coding perspective) to help that person out.  They must
: have a keyboard and monitor on that machine, and they must go
: to the machine and login via that console.

The rational for #1 being implemented now is that all security
features, when specially enabled (which you had to do to compile the
kernel with ipfw in it) must fail "safely."  Safely is defined as
being more restrictive than less.  #2 is less.   That's the whole
reason we do this.

But I think this is going to be one of those threads that lasts
forever and then nothing happens because they end in deadlock.

Warner


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

firewall_enable

[M. Warner Losh]

Actually, there's a simple way around this that is failsafe.

firewall_enable=YESWhat it deos now
=NOWide open
=FAILSAFE  Defaults to wired down.

/etc/defaults/rc.conf

firewall_enable=FAILSAFE

That way, people that say firewall_enable=NO get what they want, those
that say firewall_enable=YES aren't impacted, and those that do
nothing get the default firewall behavior that is compiled into the
kernel.  The default behavior is controlled by kernel options, but
genearlly is closed rather than open.

A few extra comments in LINT, where people likely cut and paste their
ipfw and/or ipfilter lines from anyway, should allow those paying
attention to realize the consequences of their actions:

# IPFIREWALL enables support for IP firewall construction, in
# conjunction with the `ipfw' program.  IPFIREWALL_VERBOSE sends
# logged packets to the system logger.  IPFIREWALL_VERBOSE_LIMIT
# limits the number of times a matching entry can be logged.
# 
# WARNING: IPFIREWALL defaults to a policy of "deny ip from any to
# any" and if you do not add other rules during startup to allow
# access, YOU WILL LOCK YOURSELF OUT.  If you do not setup firewall
# rules in /etc/rc.conf (with firewall_enable=YES and
# firewall_type=xxx), you must go to the machine and fix it from the
# console.
# 
# When setting up a machine for the first time, especially a remote
# machine, with a firewall, you are strongly urged to add
# IPFIREWALL_DEFAULT_TO_ACCEPT to your kernel and are sure that you're
# firewall is properly setup in /etc/rc.conf before removing that
# option.  Remote machines can be hard to fix remotely if you do not
# do this and fail to configure the firewall.
#
# IPFIREWALL_DEFAULT_TO_ACCEPT causes the default rule (at boot) to
# allow everything.  Use with care, if a cracker can crash your
# firewall machine, they can get to your protected machines.  However,
# if you are using it as an as-needed filter for specific problems as
# they arise, then this may be for you.  Changing the default to 'allow'
# means that you won't get stuck if the kernel and /sbin/ipfw binary get
# out of sync.
#
options IPFIREWALL  #firewall SEE WARNINGS ABOVE
options IPFIREWALL_VERBOSE  #enable logging to syslogd(8)
options IPFIREWALL_FORWARD  #enable transparent proxy support
options IPFIREWALL_VERBOSE_LIMIT=100#limit verbosity
options IPFIREWALL_DEFAULT_TO_ACCEPT#allow everything by default

Warner


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

PAM and current

[M. Warner Losh]

I just upgraded my laptop to -current to start working on some
lingering newcard + acpi problems (like the panic on boot due to
interrupt issues).  So I notice a new message on my console when I log
in via xdm:

Feb  3 16:18:44 hammer : PAM unable to dlopen(/usr/lib/pam_opie.so)
Feb  3 16:18:44 hammer : PAM [dlerror: /usr/lib/libopie.so.2: Undefined symbol 
"__xuname"]
Feb  3 16:18:44 hammer : PAM adding faulty module: /usr/lib/pam_opie.so
Feb  3 16:18:44 hammer : PAM unable to dlopen(/usr/lib/pam_opieaccess.so)
Feb  3 16:18:44 hammer : PAM [dlerror: /usr/lib/libopie.so.2: Undefined symbol 
"__xuname"]
Feb  3 16:18:44 hammer : PAM adding faulty module: /usr/lib/pam_opieaccess.so

Ideas?  This is post mergemaster.

Warner

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

Re: buildword break on STABLE

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
"Vladimir B. " Grebenschikov <[EMAIL PROTECTED]> writes:
: I am trying to build -CURRENT world on 4.4-RELEASE machine:
...
: Any suggestions ?

I can tell you that 4.5-release will work.

Warner

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

Re: pam_ssh world breakage

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Kris Kennaway <[EMAIL PROTECTED]> writes:
: On Tue, Feb 05, 2002 at 07:20:46AM -0800, David O'Brien wrote:
: > On Mon, Feb 04, 2002 at 07:06:54PM -0800, Kris Kennaway wrote:
: > > If you use the argument that one shouldn't set WARNS because a new
: > > compiler will cause the tree to break, then there's no point having it
: > > at all since that condition will always be true.
: > 
: > The difference is _impending_.
: 
: EPARSE.

I think that David is trying to say that "Look guys, I'm this >< close
to importing gcc3.  It does warnings differently.  Cranking up the
WARNS level now will get in the way of my work and will lead to
unnecessary build breakage on some platforms that I don't compile for
all the time.  Please go ahead and fix the warnings at the higher
levels, but don't put WARNS=x into the Makefile* until I'm done
importing things."

Warner

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

Re: Performance of -current vs -stable

[M. Warner Losh]

In message: 
Garance A Drosihn <[EMAIL PROTECTED]> writes:
: Could it be due to the DDB, INVARIANTS & WITNESS options in the
: kernel?  If it is that's fine with me, I'm just wondering where
: that magnitude of a slowdown would be coming from.

No way for DDB, Maybe for Invariants, almost certainly for witness.
WITNESS is slow and tends to exagerate lock contention stalls (or so
it seems).

Warner

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

Re: Not committing WARNS settings...

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
"David O'Brien" <[EMAIL PROTECTED]> writes:
: I am starting to think all WARNS cleanup patches should be posted to
: audit and have an "Approved by: audit" or any of our accepted very
: knowledgeable C standards people.

I think this is a good idea since a number of the warnings are subtle.

Look at the recent 8 -> 8U change causing so much problems.

Warner

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

Re: ThinkPad X22 PC-Card slot problem

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
: From: Takanori Watanabe <[EMAIL PROTECTED]>
: Date: Wed, 06 Feb 2002 23:16:21 +0900
: > >I recently installed -current to ThinkPad X22. Though it seems that
: > >X22's PC-Card slots work fine with -stable, in -current when probing
: > >PCICs I got following message,
:   :
: > How about disabling ACPI? If this works, it is because ACPI PCI interrupt 
: > routing problem.
: 
: No, disabling ACPI does not change the situation.

Hmmm.  This looks ugly. :-(  I can't boot with acpi enabled on my Dell
Inspiron 8000.  I can boot with apm enabled.  There are issues with
routing interrupts accross PCI PCI bridges at the moment when the
slots on the other side of the bridge are in the PIR table.

Warner


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

Re: gcc3.x issues

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Terry Lambert <[EMAIL PROTECTED]> writes:
: How many MB does your flash card where you're installing
: FreeBSD have on it?

I've installed a subsetted FreeBSD onto a 8MB CF card.  For normal
FreeBSD (as oppsoed to pico), the smallest amount of space you need is
about 6.9M, and that can be stripped down to about 5M with compression
and custom rc files with network stuff.

However, to do a standard install, the minimal installation takes
about a 128M 196M part (but I haven't tried it lately).

Warner

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

Re: ThinkPad X22 PC-Card slot problem

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
: From: "M. Warner Losh" <[EMAIL PROTECTED]>
: Date: Wed, 06 Feb 2002 19:33:32 -0700 (MST)
: > Hmmm.  This looks ugly. :-(  I can't boot with acpi enabled on my Dell
: > Inspiron 8000.  I can boot with apm enabled.  There are issues with
: > routing interrupts accross PCI PCI bridges at the moment when the
: > slots on the other side of the bridge are in the PIR table.
: 
: It turned out that this was not a intterupt routing problem. By
: disabling the memory/port range checks in sys/dev/pci/pci_pci.c solved 
: the problem (below is the patch). pci_pci.c claims that both the
: memory adderss for pcic and the PC-Cards are not supported but I could
: use the addresses. 

Yes.  This is the ISA problem.  The checks are there to make sure we
don't assign addresses that aren't decoded by the bridge.  However,
the bridge does decode ISA addresses.  I need to check into which ISA
stuff a little better before making a fix.

Warner

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

Re: ThinkPad X22 PC-Card slot problem

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
: From: "M. Warner Losh" <[EMAIL PROTECTED]>
: Date: Wed, 06 Feb 2002 19:33:32 -0700 (MST)
: > Hmmm.  This looks ugly. :-(  I can't boot with acpi enabled on my Dell
: > Inspiron 8000.  I can boot with apm enabled.  There are issues with
: > routing interrupts accross PCI PCI bridges at the moment when the
: > slots on the other side of the bridge are in the PIR table.
: 
: It turned out that this was not a intterupt routing problem. By
: disabling the memory/port range checks in sys/dev/pci/pci_pci.c solved 
: the problem (below is the patch). pci_pci.c claims that both the
: memory adderss for pcic and the PC-Cards are not supported but I could
: use the addresses. 

Yes.  This is the ISA problem.  The checks are there to make sure we
don't assign addresses that aren't decoded by the bridge.  However,
the bridge does decode ISA addresses.  I need to check into which ISA
stuff a little better before making a fix.

Warner

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

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

Re: Where to find docs on newbus vs. cardbus vs. newcard

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Miguel Mendez <[EMAIL PROTECTED]> writes:
: So, in your opinion, how hard would it be to MFC from a recent -CURRENT
: to 4.5-RELEASE? More or less importing the stuff and little fixing or is
: a major rewrite of some part needed? Because as it seems that no one is
: going to do it any time soon I've put it in my TODO list, along with
: other stuff and was just wondering if it's relativitely easy or too much
: for a junior kernel hacker.

It isn't a huge effort conceptutally, but there is a lot of
infrastructure that CardBus depends on that isn't in -stable or only
partially MFC'd.  If someone wanted to start cranking on it, they
could get it done in a few weeks worth of work.

Warner

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

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

Re: Where to find docs on newbus vs. cardbus vs. newcard

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
j mckitrick <[EMAIL PROTECTED]> writes:
: | CardBus:
: | PCMCIA standard for PCI cards in the PC Card form factor.
: 
: I was pretty close on this as well.  These are specifically 32-bit
: cards, correct?

Yes.

: | dev/{pccard,pcic,exca,cardbus,pccbb}/*.  I'm in the process of fixing
: | bugs in this code base as well as removing redundant code and
: | expanding support for more bridges and client devieces.  This is what
: | I've been calling NEWCARD.
: 
: Ah, this was the part I got mixed up.  I thought Newcard was already up
: and running with the last iteration of changes you made (remember me and
: ToPIC on Toshiba?  ;-)  I thought this was already in -stable.

NEWCARD is up and running, but has issues for some cards, bridges and
lacks some useful features.

Warner

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

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

Re: ThinkPad X22 PC-Card slot problem

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
: From: Takanori Watanabe <[EMAIL PROTECTED]>
: Date: Wed, 06 Feb 2002 23:16:21 +0900
: > >I recently installed -current to ThinkPad X22. Though it seems that
: > >X22's PC-Card slots work fine with -stable, in -current when probing
: > >PCICs I got following message,
:   :
: > How about disabling ACPI? If this works, it is because ACPI PCI interrupt 
: > routing problem.
: 
: No, disabling ACPI does not change the situation.

Hmmm.  This looks ugly. :-(  I can't boot with acpi enabled on my Dell
Inspiron 8000.  I can boot with apm enabled.  There are issues with
routing interrupts accross PCI PCI bridges at the moment when the
slots on the other side of the bridge are in the PIR table.

Warner


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

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

Re: Where to find docs on newbus vs. cardbus vs. newcard

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
j mckitrick <[EMAIL PROTECTED]> writes:
: On Mon, Feb 11, 2002 at 03:56:00PM -0700, M. Warner Losh wrote:
: | NEWCARD is up and running, but has issues for some cards, bridges and
: | lacks some useful features.
: 
: That reminds me, there was something I noticed on my system you might
: want to be aware of.  :-)
: 
: First, everything works fine, or actually, outstandingly.  Very good
: job.
: 
: When my laptop is booting (Toshiba with ToPIC97, NoteWorthy modem,
: LinkSys modem card) something odd happens:
: 
: IP packet filtering initialized, divert disabled, rule-based forwarding
: disabled
: , default to accept, unlimited logging
: pccard: card inserted, slot 0
: pccard: card inserted, slot 1
: pccard: card removed, slot 1
: pccard: card inserted, slot 0
: pccard: card inserted, slot 1

That's odd.

: You can see slot 1 acts like it was removed and reinserted.  To make it
: even more interesting...

You are right.

: Mounting root from ufs:/dev/ad0s1a
: sio1 at port 0x2f8-0x2ff irq 11 flags 0x4 slot 0 on pccard0
: sio1: type 16550A
: sio1: unable to activate interrupt in fast mode - using normal mode
: ed1 at port 0x240-0x25f iomem 0xd4000-0xd7fff irq 11 slot 1 on pccard1
: ed1: address e2:0c:0f:05:6d:54, type NE2000 (16 bit)
: 
: You can see the NIC comes up as ed1.  This used to be ed0 around 4.3,
: IIRC.  Is this related to the problems with slot 1 under ToPIC97?
: I could be wrong, but I believe my modem used to be sio0 as well.  I
: remember having to change it in my ppp script after a build world some
: time ago.

Maybe hints consume ed0 and sio0 likely.

Warner

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

Re: Where to find docs on newbus vs. cardbus vs. newcard

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
j mckitrick <[EMAIL PROTECTED]> writes:
: | Maybe hints consume ed0 and sio0 likely.
: 
: So, the game is afoot!  Is there anything I can do to help track this
: down?

In -current look at /boot/device.hints.  In stable this is still in
the kernel config file.

Warner

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

Re: Where to find docs on newbus vs. cardbus vs. newcard

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
j mckitrick <[EMAIL PROTECTED]> writes:
: 
: | In -current look at /boot/device.hints.  In stable this is still in
: | the kernel config file.
: 
: Is the hints file going to become standard, or is it just a tool to
: help developers writing drivers for -current?

It is standard in current, so in 5.0-release and newer people will
have to cope.

Warner

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

Re: Where to find docs on newbus vs. cardbus vs. newcard

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
j mckitrick <[EMAIL PROTECTED]> writes:
: So the idea is that drivers will be modules dynamically loaded based on
: the hints file?

Not currently.  But someone could come in and do that project.

Warner

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

Re: "/bin/sh: Argument list too long" when compiling LINT ...

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Luigi Rizzo <[EMAIL PROTECTED]> writes:
: Any idea on how to fix this ?

Use a smaller path.  Or dig up bde's fixes to config from the
archives.

Warner

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

Re: latest pccard/cardbus megacommit broke on-boot detection

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Michal Mertl <[EMAIL PROTECTED]> writes:
: I have Xircom CBEM-56G (on card printed RBEM-56G-100) which used to be
: detected on boot without problem on -CURRENT. After todays cvsup and
: buildworld the card is no longer detected. It works when I unplug it and
: put it back.
: 
: Is it expected behaviour? It seems to me it can be and the commit is work
: in progress to make it behave more like OLDCARD ?

I broke this on boot.  I've managed to recreate the problem on my
laptop and will commit a fix shortly.

Warner

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

Re: Patch sets to date and timing tests with Giant out of userret.

[M. Warner Losh]

In message: <00cd01c1b926$82d35bb0$ef01a8c0@davidwnt>
"David Xu" <[EMAIL PROTECTED]> writes:
: Sorry for a bit OT, is Perforce a free software? if it is not, why
: do we need to use this property software?

Because it is useful.  And all the other alternative suck too bad to
even try at this time.  Bitkeeper enforces the linux devleopment model
to a large extent, subversion and arch look promsing, but have growing
pains and second system syndrome to battle.  Perforce is available
today for free for free software development.  You can't get source,
but it doesn't cost anything for the use to which we're putting it.

Warner

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

Re: Patch to improve mutex collision performance

[M. Warner Losh]

I'd love to see subversion beefed up.  It looks like the most
promising of the replacements for cvs on the horizon.

One thing that it doesn't appear to have, that would be useful to the
BSD community, is the ability to cons up a tree from multiple repos
easily.  If we had that, then we wouldn't need 5 different versions of
cat for {Free,Net,Open}BSD, Darwin and BSD/os. :-)

That reminds me, I gotta go fix FreeBSD's patch to grok patches
properly ...

Warner

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

Re: bind fails with sig11 on start / pthread failure on ARM?

[M. Warner Losh]

In message: <20100216123646.fc741643.s...@freebsd.org>
Stanislav Sedov  writes:
: On Tue, 16 Feb 2010 19:39:51 +0100
: Bernd Walter  mentioned:
: 
: > 
: > Do we have a general threading problem on ARM?
: > 
: 
: I don't think so.  I used a lot of threaded applications on arm, and they
: worked fine.  However, this might be some obscure bug.

I know that 6.x ARM worked with threads no problem.  We had dozens of
threads in our control programs.

The one caveat is that I've found bugs in the atomic routines in the
past, and have had people submit fixes as well.  All of those should
be in the tree, but since some arrived when I was crazy busy for
Cisco, they might have fallen on the floor.

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

Re: lang/perl5.10 broken

[M. Warner Losh]

In message: <20100217152557.gw43...@cicely7.cicely.de>
Bernd Walter  writes:
: Not sure if this is ARM related or not.

...
: *** Signal 11

Silly question: do you have enough swap space enabled?

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

Re: bind fails with sig11 on start / pthread failure on ARM?

[M. Warner Losh]

In message: <20100219031200.gy43...@cicely7.cicely.de>
Bernd Walter  writes:
: On Thu, Feb 18, 2010 at 03:10:10PM +0200, Kostik Belousov wrote:
: > On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote:
: > > On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote:
: > > > On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote:
: > > > [55]Please.tell.me.who.am.I# gdb /usr/sbin/named named.core 
: > > > GNU gdb 6.1.1 [FreeBSD]
: > > > Copyright 2004 Free Software Foundation, Inc.
: > > > GDB is free software, covered by the GNU General Public License, and 
you are
: > > > welcome to change it and/or distribute copies of it under certain 
conditions.
: > > > Type "show copying" to see the conditions.
: > > > There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
: > > > This GDB was configured as "arm-marcel-freebsd"...(no debugging symbols 
found)...
: > > > Core was generated by `named'.
: > > > Program terminated with signal 5, Trace/breakpoint trap.
: > > > Reading symbols from /lib/libcrypto.so.6...(no debugging symbols 
found)...done.
: > > > Loaded symbols for /lib/libcrypto.so.6
: > > > Reading symbols from /lib/libthr.so.3...(no debugging symbols 
found)...done.
: > > > Loaded symbols for /lib/libthr.so.3
: > > > Reading symbols from /lib/libc.so.7...(no debugging symbols 
found)...done.
: > > > Loaded symbols for /lib/libc.so.7
: > > > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols 
found)...done.
: > > > Loaded symbols for /libexec/ld-elf.so.1
: > > > #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
: > > > [New Thread 20804280 (LWP 100062)]
: > > > [New Thread 20804140 (LWP 100052)]
: > > > (gdb) bt
: > > > #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
: > > > #1  0x203572b8 in _thread_bp_death () from /lib/libthr.so.3
: > > > #2  0x20349da4 in pthread_create () from /lib/libthr.so.3
: > > > #3  0x00164cb8 in ?? ()
: > > > (gdb) 
: > > > 
: > > > Do we have a general threading problem on ARM?
: > > 
: > > I see two different type a crashes.
: > > Both have in common that one or more threads are in _umtx_op.
: > > Unfortunately I don't know enough details about those things to isolate
: > > any more.
: > > 
: > > the one from above:
: > > #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
: > > [New Thread 20804280 (LWP 100062)]
: > > [New Thread 20804140 (LWP 100052)]
: > > (gdb) bt
: > > #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
: > > #1  0x203572b8 in _thread_bp_death () from /lib/libthr.so.3
: > > #2  0x20349da4 in pthread_create () from /lib/libthr.so.3
: > > #3  0x00164cb8 in ?? ()
: > > (gdb) thread 1
: > > [Switching to thread 1 (Thread 20804280 (LWP 100062))]#0  0x203ab6f0 in 
_umtx_op () from /lib/libc.so.7
: > > (gdb) bt
: > > #0  0x203ab6f0 in _umtx_op () from /lib/libc.so.7
: > > #1  0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3
: > > #2  0x20357cc0 in pthread_cleanup_push () from /lib/libthr.so.3
: > > #3  0x20349540 in pthread_getprio () from /lib/libthr.so.3
: > > #4  0x203499a0 in pthread_create () from /lib/libthr.so.3
: > > #5  0x00164cb8 in ?? ()
: > > 
: > > And another, which is what I get most of the time:
: > > (gdb) thread 1
: > > [Switching to thread 1 (Thread 20804500 (LWP 100100))]#0  0x20435f28 in 
kevent () from /lib/libc.so.7
: > > (gdb) bt
: > > #0  0x20435f28 in kevent () from /lib/libc.so.7
: > > #1  0x0014f2dc in ?? ()
: > > (gdb) thread 2
: > > [Switching to thread 2 (Thread 208043c0 (LWP 100099))]#0  0x203ab6f4 in 
_umtx_op () from /lib/libc.so.7
: > > (gdb) bt
: > > #0  0x203ab6f4 in _umtx_op () from /lib/libc.so.7
: > > #1  0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3
: > > #2  0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3
: > > #3  0x20355580 in pthread_cond_signal () from /lib/libthr.so.3
: > > #4  0x in ?? ()
: > > (gdb) thread 3
: > > [Switching to thread 3 (Thread 20804280 (LWP 100098))]#0  0x203ab6f4 in 
_umtx_op () from /lib/libc.so.7
: > > (gdb) bt
: > > #0  0x203ab6f4 in _umtx_op () from /lib/libc.so.7
: > > #1  0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3
: > > #2  0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3
: > > #3  0x20355580 in pthread_cond_signal () from /lib/libthr.so.3
: > > #4  0x2092d008 in ?? ()
: > > (gdb) thread 4
: > > [Switching to thread 4 (Thread 20804140 (LWP 100043))]#0  0x0015755c in 
?? ()
: > > (gdb) bt
: > > #0  0x0015755c in ?? ()
: > 
: > Compile and install ld-elf.so, libc and libthr with debugging symbols:
: > (cd libexec/rtld-elf && make all install DEBUG_FLAGS=-g)
: > (cd lib/libc && make all install DEBUG_FLAGS=-g)
: > (cd lib/libthr && make all install DEBUG_FLAGS=-g)
: > 
: > Then repeat the crash and try to see where in code does it happen.
: 
: Currently I can only get this type.
: I've started the unstripped named to get all the function names.
: 
: (gdb) thread 1
: [Switching to thread 1 (Thread 20804500 (LWP

Re: bind fails with sig11 on start / pthread failure on ARM?

[M. Warner Losh]

In message: <20100219033000.gz43...@cicely7.cicely.de>
Bernd Walter  writes:
: On Fri, Feb 19, 2010 at 04:12:00AM +0100, Bernd Walter wrote:
: > On Thu, Feb 18, 2010 at 03:10:10PM +0200, Kostik Belousov wrote:
: > > On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote:
: > > > On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote:
: > > > > On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote:
: > [Switching to thread 4 (Thread 20804140 (LWP 100053))]#0  0x0015755c in 
isc_atomic_cmpxchg ()
: > (gdb) bt
: > #0  0x0015755c in isc_atomic_cmpxchg ()
: > #1  0x00157dac in isc_rwlock_lock ()
: > #2  0x000f9790 in dns_db_register ()
: > #3  0x0004d590 in dns_sdb_register ()
: > #4  0xc974 in ns_builtin_init ()
: > #5  0x0001aa90 in $a ()
: > #6  0x0001aa90 in $a ()
: > 
: > isc_atomic_cmpxchg really sounds quite interesting though.
: > It is not only the crashing function it is also a type of function which
: > sounds error prune.
: 
: For me it looks like a bug in bind itself.
: It is in contrib/bind9/lib/isc/arm/include/isc/atomic.h.
: My assumption is that either the assembly is broken or it gets an
: invalid pointer.
: I'm not very expirienced with ARM assembly.
: Warner - it names you in the copyright, so very likely you know this code.
: I will build a debug version of bind, but as usual it will take some
: time...

Damn.  It wasn't me.

Oh, wait, maybe it was...

I'll try to look at it tomorrow...

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

Re: bind fails with sig11 on start / pthread failure on ARM?

[M. Warner Losh]

In message: <20100219033000.gz43...@cicely7.cicely.de>
Bernd Walter  writes:
: Warner - it names you in the copyright, so very likely you know this code.
: I will build a debug version of bind, but as usual it will take some
: time...

Make sure that the code matches our current atomics code...

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

Re: ATA_CAM-ed mvsata(4) on OpenRD-client

[M. Warner Losh]

In message: <4b7ef63c.7030...@freebsd.org>
Alexander Motin  writes:
: Hi.
: 
: Norikatsu Shigemura wrote:
: > I got a OpenRD-client (Marvell 88F6281 SoC), and I'm tring to
: > make mvsata(4) ATA_CAM, like following:
: > 
: > But I got following panic, my I help you?
: > In this time, I attached no devices to SATA/eSATA port.
: > - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - -
: > sata0:  at mem 0xf108-0xf1085fff 
irq 21 on mbus0
: > sata0: [MPSAFE]
: > sata0: [ITHREAD]
: > ata0:  on sata0
: > ata0: [MPSAFE]
: > ata0: [ITHREAD]
: > ata1:  on sata0
: > ata1: [MPSAFE]
: > ata1: [ITHREAD]
: > spin lock 0xc3766680 (fvH) held by 0xc3613b48 (tid -1061308344) too long
: > panic: spin lock held too long
: > KDB: enter: panic
: > [ thread pid 0 tid 10 ]
: > Stopped at  0xc09dcb50 = kdb_enter+0x48:ldrbr15, [r15, r15, ror 
r15]!
: > db> 
: 
: A bit unexpected.
: 
: > - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - -
: > 
: > So I tried to get following information:
: > - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - -
: > _mtx_lock_sleep() at 0xc09a6a24 = _mtx_lock_sleep+0x10
: > scp=0xc09a6a24 rlv=0xc09a6c0c (0xc09a6c0c = _mtx_lock_flags+0x7c)
: > rsp=0xc0d62d14 rfp=0xc0d62d3c
: > r10=0xc0d62d70 r9=0xc09039a8
: > r8=0x r7=0x0851 r6=0xc0b47100 r5=0x
: > r4=0xc35dd974
: > _mtx_lock_flags() at 0xc09a6ba0 = _mtx_lock_flags+0x10
: > scp=0xc09a6ba0 rlv=0xc0903fac (0xc0903fac = xpt_sim_opened+0x17c)
: > rsp=0xc0d62d40 rfp=0xc0d62d68
: > r8=0xc0bde8f0 r7=0xc090d4a4
: > r6=0xc3765e00 r5=0xc0b47100 r4=0xc3766240
: > xpt_sim_opened() at 0xc0903f3c = xpt_sim_opened+0x10c
: > scp=0xc0903f3c rlv=0xc0904068 (0xc0904068 = xpt_sim_opened+0x238)
: > rsp=0xc0d62d6c rfp=0xc0d62d88
: > r10=0xc0bde904 r9=0xc0b47100
: > r8=0x r7=0xc090d4a4 r6=0x0080 r5=0x
: > r4=0x0001
: > xpt_sim_opened() at 0xc0904048 = xpt_sim_opened+0x218
: > scp=0xc0904048 rlv=0xc0905940 (0xc0905940 = xpt_register_async+0xd0)
: > rsp=0xc0d62d8c rfp=0xc0d62e34
: > xpt_register_async() at 0xc0905880 = xpt_register_async+0x10
: > scp=0xc0905880 rlv=0xc090d484 (0xc090d484 = ata_get_xport+0x2198)
: > rsp=0xc0d62e38 rfp=0xc0d62e44
: > r10=0x r9=0x
: > r8=0x005fffcc r7=0xc35593c0 r6=0xc0b62170 r5=0xc0be74d0
: > r4=0x001c
: 
: Even more unexpected. I've searched all sources for xpt_sim_opened()
: call and found only one place - in atapi-cam.c, which shouldn't be used
: in your case. You are using different sources, or there is a garbage in
: stack?

IIRC, I got better stack traces when I used the kernel.tramp kernel...

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

Re: [head tinderbox] failure on mips/mips

[M. Warner Losh]

Maybe a forgotten svn add for mipsfbsd-nat.c?

Warner

In message: <201002210405.o1l45ggx008...@freebsd-current.sentex.ca>
FreeBSD Tinderbox  writes:
: TB --- 2010-02-21 03:38:18 - tinderbox 2.6 running on 
freebsd-current.sentex.ca
: TB --- 2010-02-21 03:38:18 - starting HEAD tinderbox run for mips/mips
: TB --- 2010-02-21 03:38:18 - cleaning the object tree
: TB --- 2010-02-21 03:38:26 - cvsupping the source tree
: TB --- 2010-02-21 03:38:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/mips/mips/supfile
: TB --- 2010-02-21 03:38:53 - building world
: TB --- 2010-02-21 03:38:53 - MAKEOBJDIRPREFIX=/obj
: TB --- 2010-02-21 03:38:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
: TB --- 2010-02-21 03:38:53 - TARGET=mips
: TB --- 2010-02-21 03:38:53 - TARGET_ARCH=mips
: TB --- 2010-02-21 03:38:53 - TZ=UTC
: TB --- 2010-02-21 03:38:53 - __MAKE_CONF=/dev/null
: TB --- 2010-02-21 03:38:53 - cd /src
: TB --- 2010-02-21 03:38:53 - /usr/bin/make -B buildworld
: >>> World build started on Sun Feb 21 03:38:54 UTC 2010
: >>> Rebuilding the temporary build tree
: >>> stage 1.1: legacy release compatibility shims
: >>> stage 1.2: bootstrap tools
: >>> stage 2.1: cleaning up the object tree
: >>> stage 2.2: rebuilding the object tree
: >>> stage 2.3: build tools
: >>> stage 3: cross tools
: >>> stage 4.1: building includes
: >>> stage 4.2: building libraries
: >>> stage 4.3: make dependencies
: [...]
: Hunk #2 succeeded at 51.
: done
: yacc -d -o jv-exp.c 
/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/jv-exp.y
: yacc -d -o m2-exp.c 
/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/m2-exp.y
: yacc -d -o objc-exp.c 
/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/objc-exp.y
: yacc: 5 shift/reduce conflicts
: yacc -d -o p-exp.c 
/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/p-exp.y
: make: don't know how to make mipsfbsd-nat.c. Stop
: *** Error code 2
: 
: Stop in /src/gnu/usr.bin/gdb.
: *** Error code 1
: 
: Stop in /src/gnu/usr.bin.
: *** Error code 1
: 
: Stop in /src/gnu.
: *** Error code 1
: 
: Stop in /src.
: *** Error code 1
: 
: Stop in /src.
: *** Error code 1
: 
: Stop in /src.
: TB --- 2010-02-21 04:05:42 - WARNING: /usr/bin/make returned exit code  1 
: TB --- 2010-02-21 04:05:42 - ERROR: failed to build world
: TB --- 2010-02-21 04:05:42 - 1108.92 user 295.22 system 1643.80 real
: 
: 
: http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full
: ___
: freebsd-m...@freebsd.org mailing list
: http://lists.freebsd.org/mailman/listinfo/freebsd-mips
: To unsubscribe, send any mail to "freebsd-mips-unsubscr...@freebsd.org"
: 
: 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: newfs failure on -current

[M. Warner Losh]

In message: <98a59be81003040504x6e97fbaeqeb10f8ea7bedb...@mail.gmail.com>
"C. Jayachandran"  writes:
: I'm testing this on the mips platform, but I think there is an issue
: with change that made sectorsize int64_t, because the ioctl
: DIOCGSECTORSIZE  used to read sector size seems to take u_int. This
: quick change fixes it for me (sample patch - may be whitespace
: damaged).
: 
: Index: sbin/newfs/newfs.c
: ===
: --- sbin/newfs/newfs.c  (revision 204687)
: +++ sbin/newfs/newfs.c  (working copy)
: @@ -327,9 +327,11 @@
: mediasize = st.st_size;
: /* set fssize from the partition */
: } else {
: +   u_int tsize;
: if (sectorsize == 0)
: -   if (ioctl(disk.d_fd, DIOCGSECTORSIZE, §orsize) == -1)
: +   if (ioctl(disk.d_fd, DIOCGSECTORSIZE, &tsize) == -1)
: sectorsize = 0; /* back out on error for safety */
: +   sectorsize = tsize;
: if (sectorsize && ioctl(disk.d_fd, DIOCGMEDIASIZE,
: &mediasize) != -1)
: getfssize(&fssize, special, mediasize / sectorsize, reserved);
: }
: 

Maybe the right change is to back out the DIOCGSECTORSIZE change due
to silent breakage like this?

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

Re: propose: all arch move into a separate dir

[M. Warner Losh]

In message: <401095.35021...@web59107.mail.re1.yahoo.com>
paradox  writes:
: iam propose all the architecture move in a separate directory
: as is done in openbsd and netbsd
: 
: ie 
: #mkdir /usr/src/sys/arch
: #mv -R 
/usr/src/sys/{amd64,arm,i386,ia64,mips,pc98,powerpc,sparc64,sun4v,xen,x86) 
/usr/src/sys/arch/
: 
: Would it ever done in freebsd?

No.  That ship sailed in 1995.

Besides, it would be the mother of all bikesheds.  Do we want to have
a sys/cpu/{mips,x86,arm,etc} for CPU support and a sys/arch/$MACHINE
for support for machines that use that, how does that interact with
source doe that assumes certain things in machine/foo.h.  Or do we
want to have better organized sub-ports.  Do we want to reorg config
while we're at it, and what about modules.  And sys/dev is too
crowded, let's fix that too while we're at it.

The end result: gridlock and nothing will happen.

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

Re: propose: all arch move into a separate dir

[M. Warner Losh]

In message: <20100307052949.gb70...@dragon.nuxi.org>
"David O'Brien"  writes:
: On Sat, Mar 06, 2010 at 01:28:24AM -0800, Garrett Cooper wrote:
: > FWIW, NetBSD's charter has been to run their OS on a number of
: > architectures, not just a primary set of architectures; OpenBSD's
: > charter differs -- if we all were NetBSD or OpenBSD, then we'd all be
: > using the same thing.  But we aren't and that's probably not going to
: > change anytime soon [at least not without community backing and a
: 
: We aren't?  At this point it seems any architecture an be brought into
: FreeBSD without regard to critical mass or ability to support it to the
: standards of our past.  I do believe FreeBSD's character does not include
: chasing every embedded platform where there is energy and talent for the
: initial port.

FreeBSD's charter includes whatever people have the time and energy to
support.  This means a lot more embedded platforms that I ever thought
possible because FreeBSD is getting easier to move to new embedded
platforms.  This is a good thing, as it brings more people and energy
to the project and makes the base support for those platforms better.

We don't have quite as many problems as the NetBSD/OpenBSD crowd in
this respect.  They tend to define a new MACHIINE more often then we
have (or will).  The need for sys/arch is less severe here than there
because we don't have 40 different MACHINEs.

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

Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver

[M. Warner Losh]

In message: <261c29701003040928h7aa70b3fm37611f974e0b9...@mail.gmail.com>
Miki  writes:
: Rising FIRMWARE_MAX from 30 to 60 did the trick ! thanks !
: Are there any reasons to have such a "low" default value ?

I thought I'd committed this  change already :)

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

Re: propose: all arch move into a separate dir

[M. Warner Losh]

In message: <20100307054423.ge70...@dragon.nuxi.org>
"David O'Brien"  writes:
: On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote:
: > On Fri, 5 Mar 2010, Poul-Henning Kamp wrote:
: >> In message , Robert 
: >> Watso n writes:
: >>> Doing that kind of rearrangement [...] would be a nightmare for anyone 
: >>> with large [...] patches, so I'd say we could pretty much rule that out 
: >>> outright.
: >> 
: >> I would say that we should do it occasionally, to encourage these FreeBSD 
: >> users to contribute as many of their local changes back to the project, as 
: >> possible :-)
: > 
: > Absolutely -- and rearranging a tree is a good way to invalidate all those 
: > patches as well :-).
: 
: No, not it isn't.  Provide a script to convert path's in the diff.
: This is what $LARGE_FREEBSD_USER did when it rearranged it source tree.

You are joking, right?  This would be a nightmare for people that
integrate early and often.

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

Re: propose: all arch move into a separate dir

[M. Warner Losh]

In message: <20100308000203.ga70...@dragon.nuxi.org>
"David O'Brien"  writes:
: On Sun, Mar 07, 2010 at 02:49:04PM -0700, M. Warner Losh wrote:
: > In message: <20100307054423.ge70...@dragon.nuxi.org>
: > "David O'Brien"  writes:
: > : On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote:
: > : > On Fri, 5 Mar 2010, Poul-Henning Kamp wrote:
: > : >> In message , 
Robert 
: > : >> Watso n writes:
: > : >>> Doing that kind of rearrangement [...] would be a nightmare for 
anyone 
: > : >>> with large [...] patches, so I'd say we could pretty much rule that 
out 
: > : >>> outright.
: > : >> 
: > : >> I would say that we should do it occasionally, to encourage these
: > : >> FreeBSD users to contribute as many of their local changes back to
: > : >> the project, as possible :-)
: > : > 
: > : > Absolutely -- and rearranging a tree is a good way to invalidate
: > : > all those patches as well :-).
: > : 
: > : No, not it isn't.  Provide a script to convert path's in the diff.
: > : This is what $LARGE_FREEBSD_USER did when it rearranged it source tree.
: > 
: > You are joking, right?  This would be a nightmare for people that
: > integrate early and often.
: 
: 
: No I am not joking.  I was responding to the point that a large patch
: (that is a the output of running '$SCM diff') can be easily modified to
: match a new directory layout.  Thus patches in GNATS aren't "useless".

It seems like it would be a nightmare for anybody tracking the system
on a regular basis.

: I'm not sure what operation you are specifically speaking to . But, if
: FreeBSD were to move the CPU directories under 'arch/', at $WORK we would
: do:
: 
: cd sys
: mkdir arch
: svn add arch
: svn mv {list of dirs} arch
: svn ci
: 
: and be done with it.  Branches would merge that change - get a trivial
: tree conflict, resolve it - and move on with life.

And everybody who was tracking FreeBSD with their own changes would
have to scramble.  It wouldn't be trivial by any stretch of the
imagination.  The project is much larger than svn, and svn doesn't
lend itself well to having external agents track it.

: I would expect folks working in project branches to do the same.
: 
: For merging changes from FreeBSD HEAD to FreeBSD stable - that is
: trivial:
: 
: cd sys
: svn merge -c $GRN ^/head/sys/arch/amd64 amd64
: svn ci
: 
: Subversion makes this a lot easier than CVS did.

Just because the task is doable with svn, where it was impossible with
CVS doesn't mean there wouldn't be a significant amount of pain to the
folks using FreeBSD.  It is cool that Juniper kinda has it worked out,
but even there I'm skeptical about your claims.  Especially since
Juniper imports source rarely, where as other firms do it more often,
and there'd be more pain for them.

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

Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32

[M. Warner Losh]

In message: <7d6fde3d1003111720g7dccf93w1f51db88758a5...@mail.gmail.com>
Garrett Cooper  writes:
: On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel  wrote:
: > On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik
: >  wrote:
: >> On 3/11/2010 9:50 AM, Nathan Whitehorn wrote:
: >>>
: >>> As a result of importing 32-bit compatibility support for non-x86 64-bit
: >>> platforms, the kernel options COMPAT_IA32 has been renamed 
COMPAT_FREEBSD32
: >>> in revision 205014, so all kernel configurations including this option 
must
: >>> be modified accordingly.
: >>>
: >>
: >> That sounds a bit confusing, compatibility with FreeBSD 3.2?
: >>
: > I agree that the name COMPAT_FREEBSD32 is confusing, does it mean
: > compatiblity with FreeBSD 3.2, FreeBSD 32 or 32-bit ARCH's.
: >
: > A better name would have been COMPAT_ARCH32 or COMPAT_32BIT_ARCH.
: 
: Agreed. Is it possible to change the name again because it really
: hasn't gotten much traction yet?

What does the name matter, really?

This will be documented, and mirrors the kernel source
compat/freebsd32.

Put another way: if everybody that's going to comment on the name
would instead fix one bug from the PR database with the time they
spend commenting on it, would FreeBSD be better or worse off than
spending dozens of hours arguing over COMPAT_X32 vs COMPAT_Y32 vs
COMPAT_FLYING_MONKEYS?

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

Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32

[M. Warner Losh]

In message: <20100312171758.gb31...@dragon.nuxi.org>
"David O'Brien"  writes:
: On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote:
: > In message: <7d6fde3d1003111720g7dccf93w1f51db88758a5...@mail.gmail.com>
: > Garrett Cooper  writes:
: > : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel  wrote:
: > : > On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik
: > : >  wrote:
: > : >> On 3/11/2010 9:50 AM, Nathan Whitehorn wrote:
: > : >>> As a result of importing 32-bit compatibility support for non-x86
: > : >>> 64-bit platforms, the kernel options COMPAT_IA32 has been renamed
: > : >>> COMPAT_FREEBSD32 in revision 205014, so all kernel configurations
: > : >>> including this option must be modified accordingly.
: > : >>
: > : >> That sounds a bit confusing, compatibility with FreeBSD 3.2?
: > : >>
: > : > I agree that the name COMPAT_FREEBSD32 is confusing, does it mean
: > : > compatiblity with FreeBSD 3.2, FreeBSD 32 or 32-bit ARCH's.
: > : >
: > : > A better name would have been COMPAT_ARCH32 or COMPAT_32BIT_ARCH.
: > : 
: > : Agreed. Is it possible to change the name again because it really
: > : hasn't gotten much traction yet?
: > 
: > What does the name matter, really?
: 
: Yes names matter.  Otherwise we would have made it "DEF8931".  #define
: names are chosen to be self-documenting.

I'd maintain that this name is self-documenting as well.  Obviously
you can take the what does the name matter to an extreme.  However,
for names that meet a minimum threshold of conformity, there reaches a
point where arguing over them is counter productive.  I believe that
this name meets those minimum requirements.

:   $ grep COMPAT_FREEBSD conf/*
:   conf/NOTES:# Note that as a general rule, COMPAT_FREEBSD depends on
:   conf/NOTES:# COMPAT_FREEBSD, COMPAT_FREEBSD, etc.
:   conf/NOTES:options  COMPAT_FREEBSD4
:   conf/NOTES:options  COMPAT_FREEBSD5
:   conf/NOTES:options  COMPAT_FREEBSD6
:   conf/NOTES:options  COMPAT_FREEBSD7
:   conf/options:COMPAT_FREEBSD4opt_compat.h
:   conf/options:COMPAT_FREEBSD5opt_compat.h
:   conf/options:COMPAT_FREEBSD6opt_compat.h
:   conf/options:COMPAT_FREEBSD7opt_compat.h
: 
: COMPAT_FREEBSD32 is not the same as any of the other well established
: "COMPAT_FREEBSD" macros.  So I do see where this could lead to confusion
: to users.

This is where we disagree.  Any confusion can be solved by
documentation.

See for example these other compat options:

COMPAT_LINUX  brings in the files in sys/compat/linux
COMPAT_SVR4   brings in the files in sys/compat/svr4

and

COMPAT_LINUX32  compiles the 32-bit linux support on 64-bit
hosts.

So the issue isn't as cut and dried as you might think.  There's
multiple different conventions used here in addition to your simple
example.  Users of 64-bit systems that will be using COMPAT_FREEBSD32
are likely to find this a natural extension of the COMPAT_LINUX32 that
they are likely already using.

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

Re: [PATCH] newvers.sh

[M. Warner Losh]

In message: <20100312171206.ga31...@dragon.nuxi.org>
"David O'Brien"  writes:
: * Simplify SRCDIR calculation by directly finding the kernel sources
:   based directly on one of them.
: 
: Reviewed by: dhw
: 
:   This change does not increase the kernel build time.  It also continues
:   to restrict the revision to just the kernel sources, and not the whole
:   tree.
: 
: Timing tests by: dhw



David,

I have a better simplification, I think, that works for me for each of
the tests that I've done (both traditional and buildkernel builds).

The Makefile already knows where the kernel src is located.  Let's use
that knowledge to make things a little simpler.  This also uses the
Makefile variable SYSDIR.  It should also work with non-standard sys
directories.

There's one divergence between svn and git tagging: svn does src/sys,
while git does src.  This is how the previous code was before, and I
don't think I've changed that.

Can you confirm this works for you and also comment on the change
itself?  It is a bigger change, but results in a simpler (I think)
newvers.sh.

Comments?

Warner

Index: conf/kern.post.mk
===
--- conf/kern.post.mk   (revision 204938)
+++ conf/kern.post.mk   (working copy)
@@ -244,7 +244,7 @@
${NORMAL_LINT}
 
 vers.c: $S/conf/newvers.sh $S/sys/param.h ${SYSTEM_DEP}
-   MAKE=${MAKE} sh $S/conf/newvers.sh ${KERN_IDENT}
+   MAKE=${MAKE} SYSDIR=$S sh $S/conf/newvers.sh ${KERN_IDENT}
 
 vnode_if.c: $S/tools/vnode_if.awk $S/kern/vnode_if.src
${AWK} -f $S/tools/vnode_if.awk $S/kern/vnode_if.src -c
Index: conf/newvers.sh
===
--- conf/newvers.sh (revision 204938)
+++ conf/newvers.sh (working copy)
@@ -44,7 +44,7 @@
${PARAMFILE})
 else
RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \
-   $(dirname $0)/../sys/param.h)
+   ${SYSDIR}/sys/param.h)
 fi
 
 
@@ -84,54 +84,46 @@
 fi
 
 touch version
-v=`cat version` u=${USER:-root} d=`pwd` h=${HOSTNAME:-`hostname`} t=`date`
+v=`cat version` u=${USER:-root} h=${HOSTNAME:-`hostname`} t=`date`
 i=`${MAKE:-make} -V KERN_IDENT`
 
-case "$d" in
-*/sys/*)
-   SRCDIR=${d##*obj}
-   if [ -n "$MACHINE" ]; then
-   SRCDIR=${SRCDIR##/$MACHINE}
+for dir in /bin /usr/bin /usr/local/bin; do
+   if [ -d "${SYSDIR}/.svn" -a -x "${dir}/svnversion" ] ; then
+   svnversion=${dir}/svnversion
+   break
fi
-   SRCDIR=${SRCDIR%%/sys/*}
+   if [ -d "${SYSDIR}/../.git" -a -x "${dir}/git" ] ; then
+   git_cmd="${dir}/git --git-dir=${SYSDIR}/../.git"
+   break
+   fi
+done
 
-   for dir in /bin /usr/bin /usr/local/bin; do
-   if [ -d "${SRCDIR}/sys/.svn" -a -x "${dir}/svnversion" ] ; then
-   svnversion=${dir}/svnversion
-   break
-   fi
-   if [ -d "${SRCDIR}/.git" -a -x "${dir}/git" ] ; then
-   git_cmd="${dir}/git --git-dir=${SRCDIR}/.git"
-   break
-   fi
-   done
+if [ -n "$svnversion" ] ; then
+echo "$svnversion"
+   svn=" r`cd ${SYSDIR} && $svnversion`"
+fi
 
-   if [ -n "$svnversion" ] ; then
-   svn=" r`cd ${SRCDIR}/sys && $svnversion`"
-   fi
-   if [ -n "$git_cmd" ] ; then
-   git=`$git_cmd rev-parse --verify --short HEAD 2>/dev/null`
-   svn=`$git_cmd svn find-rev $git 2>/dev/null`
-   if [ -n "$svn" ] ; then
+if [ -n "$git_cmd" ] ; then
+   git=`$git_cmd rev-parse --verify --short HEAD 2>/dev/null`
+   svn=`$git_cmd svn find-rev $git 2>/dev/null`
+   if [ -n "$svn" ] ; then
+   svn=" r${svn}"
+   git="=${git}"
+   else
+   svn=`$git_cmd log | fgrep 'git-svn-id:' | head -1 | \
+sed -n 's/^...@\([0-9][0-9]*\).*$/\1/p'`
+   if [ -n $svn ] ; then
svn=" r${svn}"
-   git="=${git}"
+   git="+${git}"
else
-   svn=`$git_cmd log | fgrep 'git-svn-id:' | head -1 | \
-sed -n 's/^...@\([0-9][0-9]*\).*$/\1/p'`
-   if [ -n $svn ] ; then
-   svn=" r${svn}"
-   git="+${git}"
-   else
-   git=" ${git}"
-   fi
+   git=" ${git}"
fi
-   if $git_cmd --work-tree=${SRCDIR} diff-index \
-   --name-only HEAD | read dummy; then
-   git="${git}-dirty"
-   fi
fi
-   ;;
-esac
+   if $git_cmd --work-tree=${SYSDIR}/.. diff-index \
+   --name-only HEAD | read dummy; then
+   git="${git}-dirty

Re: [PATCH] newvers.sh

[M. Warner Losh]

In message: <20100315142806.ga5...@dragon.nuxi.org>
"David O'Brien"  writes:
: On Sat, Mar 13, 2010 at 09:13:03PM -0700, M. Warner Losh wrote:
: > In message: <20100312171206.ga31...@dragon.nuxi.org>
: > "David O'Brien"  writes:
: > : * Simplify SRCDIR calculation by directly finding the kernel sources
: > :   based directly on one of them.
: > : Reviewed by: dhw
: > :   This change does not increase the kernel build time.  It also continues
: > :   to restrict the revision to just the kernel sources, and not the whole
: > :   tree.
: > : Timing tests by: dhw
: > 
: > 
: > 
: > I have a better simplification, I think, that works for me for each of
: > the tests that I've done (both traditional and buildkernel builds).
: 
: I also have other simplifications.  But want to do this in stages,
: least there be some corner case or misunderstanding by someone.

Normally this is a sensible process.  However, my patches change how
we guess where sys is, and as such, I think we should go directly
there and work out the corner cases and such there.

: > Can you confirm this works for you and also comment on the change
: > itself?  It is a bigger change, but results in a simpler (I think)
: > newvers.sh.
: > Comments?
: 
: I would prefer to do this in stages so things aren't misunderstood.
: This patch is one of the key parts that shows I am not making the
: 'svnversion' run take longer, and that it does not cover more of
: the tree than before.

That's exactly what my patch does by passing in SYSDIR directly.  Why
guess and then replace it with a different guess.  Why not go directly
to the best guess immediately?  We know it is always right, because we
know it is what the kernel is using to build itself.  And we know
that's the directory we want to use for the svn command.

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

Re: [PATCH] newvers.sh

[M. Warner Losh]

In message: <20100316002939.ga36...@dragon.nuxi.org>
"David O'Brien"  writes:
: On Mon, Mar 15, 2010 at 08:44:26AM -0600, M. Warner Losh wrote:
: > In message: <20100315142806.ga5...@dragon.nuxi.org>
: > "David O'Brien"  writes:
: > : On Sat, Mar 13, 2010 at 09:13:03PM -0700, M. Warner Losh wrote:
: > : > In message: <20100312171206.ga31...@dragon.nuxi.org>
: > : > "David O'Brien"  writes:
: > : > : * Simplify SRCDIR calculation by directly finding the kernel sources
: > : > :   based directly on one of them.
: > : > : Reviewed by: dhw
: > : > :   This change does not increase the kernel build time.  It also 
continues
: > : > :   to restrict the revision to just the kernel sources, and not the 
whole
: > : > :   tree.
: > : > : Timing tests by: dhw
: > : > 
: > : > 
: > : > 
: > : > I have a better simplification, I think, that works for me for each of
: > : > the tests that I've done (both traditional and buildkernel builds).
: > : 
: > : I also have other simplifications.  But want to do this in stages,
: > : least there be some corner case or misunderstanding by someone.
: > 
: > Normally this is a sensible process.  However, my patches change how
: > we guess where sys is, and as such, I think we should go directly
: > there and work out the corner cases and such there.
: 
: Well that's what I was trying to do with the patch I sent you in
: Message-ID: <20100308010125.ga6...@dragon.nuxi.org> on 7-March-2010.
: There you didn't care for that approach and would not give details
: as to the claims you made.

I saw your patch and thought this one would be better and simplify
newvers.sh.  I saw nothing wrong, per se, with the patch.  Instead, I
saw an opportunity to refine it and make the resulting newvers.sh
simpler by using values already computed by the build system.

: I will reply in another email the issues with your patch.

I welcome constructive criticism of the patch.

: > : I would prefer to do this in stages so things aren't misunderstood.
: > : This patch is one of the key parts that shows I am not making the
: > : 'svnversion' run take longer, and that it does not cover more of
: > : the tree than before.
: > 
: > That's exactly what my patch does by passing in SYSDIR directly.  Why
: > guess and then replace it with a different guess.
: 
: Guess???  'newvers.sh' is not going to be within the kernel sources
: tree??  Are you allowing for the person that did a 'mv sys/conf/newvers.sh'
: to elsewhere?  Considering you have "sh $S/conf/newvers.sh", I don't see
: where you are.  Is "$0" confusing you?

The kernel source tree is inferred from $0, yes.  My method passes it
in directly, and makes newvers.sh shell variable usage more uniform
with the rest of the kernel.  It also eliminated a number of lines
from newvers.sh by using the value the kernel build process already
had cached.  The elimination of duplicated computation is why I think
this is a better approach.

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

Re: [PATCH] newvers.sh

[M. Warner Losh]

David

In message: <20100316004117.gb36...@dragon.nuxi.org>
"David O'Brien"  writes:
: On Sat, Mar 13, 2010 at 09:13:03PM -0700, M. Warner Losh wrote:
: > The Makefile already knows where the kernel src is located.  Let's use
: > that knowledge to make things a little simpler.  This also uses the
: > Makefile variable SYSDIR.  It should also work with non-standard sys
: > directories.
: ..
: > Index: conf/kern.post.mk
: >  vers.c: $S/conf/newvers.sh $S/sys/param.h ${SYSTEM_DEP}
: > -   MAKE=${MAKE} sh $S/conf/newvers.sh ${KERN_IDENT}
: > +   MAKE=${MAKE} SYSDIR=$S sh $S/conf/newvers.sh ${KERN_IDENT}
: 
: I'd rather not introduce yet more special things that have to be done
: before invoking newvers.sh.   ("MAKE=${MAKE} sh" is not an issue as the
: script works if MAKE is not passed in given it has "${MAKE:-make}").
: 
: The script can be more self contained than this, and I think that is
: technically better.

OK.  I think that passing the info in isn't that big a deal and makes
the dependency more explicit.

: > Index: conf/newvers.sh
: > ===
: > --- conf/newvers.sh (revision 204938)
: > +++ conf/newvers.sh (working copy)
: > @@ -44,7 +44,7 @@
: > ${PARAMFILE})
: >  else
: > RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \
: > -   $(dirname $0)/../sys/param.h)
: > +   ${SYSDIR}/sys/param.h)
: 
: I don't think we should depend on having SYSDIR defined before invoking
: newvers.sh.  Its worse than requiring that as a parameter.  We don't set
: KERN_IDENT=$KERN_IDENT before invoking newvers.sh.
: 
: Either
: MAKE=${MAKE} sh $S/conf/newvers.sh ${KERN_IDENT} $S
: or
: MAKE=${MAKE} SYSDIR=$S KERN_IDENT=$KERN_IDENT sh $S/conf/newvers.sh
: 
: for regularity.  But I really feel we can trust 'newvers.sh' to be within
: the kernel sources directory - thus "$(dirname $0)/.." is a
: self-contained method to determining what the kernel directory is.
: No guessing.  This can be optimized to "${0%/*}/..".

You are trading one dependency for another here.  Either you pass it
in by typing the path to newvers.sh, or you pass it in directly from
the kernel build.  But it would be cleaner if it were passed in as the
first parameter.

: > -v=`cat version` u=${USER:-root} d=`pwd` h=${HOSTNAME:-`hostname`} t=`date`
: > +v=`cat version` u=${USER:-root} h=${HOSTNAME:-`hostname`} t=`date`
: 
: Unfortunately, [snipped] [[ ${d} is used later, and silent succeeds
: with the wrong results with your patch ]]

$d is used later.  Gotcha.  I missed that.

: > -case "$d" in
: > -*/sys/*)
: ..
: > +for dir in /bin /usr/bin /usr/local/bin; do
: > +   if [ -d "${SYSDIR}/.svn" -a -x "${dir}/svnversion" ] ; then
: > +   svnversion=${dir}/svnversion
: ..
: > -   for dir in /bin /usr/bin /usr/local/bin; do
: > -   if [ -d "${SRCDIR}/sys/.svn" -a -x "${dir}/svnversion" ] ; then
: 
: Are you implicitly depending on there not being a '.svn/' in the root
: directory?

Assuming that you violated the precondition of passing SYSDIR in, then
yes.  However, I don't think that's a big deal.

: The invocation of 'newvers.sh' elsewhere in the tree will not
: have 'SYSDIR' (of your patch) set, so the test will be (last iteration):
: 
: if [ -d "/.svn" -a -x "$/usr/local/bin/svnversion" ] ; then
: 
: I'd rather not limit the user to not having '/.svn' that is used to
: track configuration files, etc...
:
: This patch is the end version I was working to (thru a series of
: changes):
: 
: * Simplify SRCDIR calculation by directly finding the kernel sources
:   based directly on one of them.
: * Rename SRCDIR to KERN_TOPDIR to be more clear which sources these are,
:   and at what level
: * git isn't in the base system and being GPL'ed, likely never will.
: * Revisit r196435 - rather than guess if 'newvers.sh' is being
:   invoked as part of the kernel build or not based on a path (proven
:   to be fragile), key off of having a KERN_IDENT.

Comments below...

: Index: newvers.sh
: ===
: --- newvers.sh(revision 204939)
: +++ newvers.sh(working copy)
: @@ -39,12 +39,13 @@ fi
:  RELEASE="${REVISION}-${BRANCH}"
:  VERSION="${TYPE} ${RELEASE}"
:  
: +KERN_TOPDIR=${0%/*}/..

I'd have selected SYSDIR, which is used elsewhere in the build system
to indicate the top of the kernel tree.

:  if [ "X${PARAMFILE}" != "X" ]; then
:   RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \
:   ${PARAMFILE})
:  else
:   RELDA

Re: [PATCH] newvers.sh

[M. Warner Losh]

In message: <4b9edb05.4020...@freebsd.org>
Doug Barton  writes:
: On 03/15/10 17:41, David O'Brien wrote:
: > I'd rather not introduce yet more special things that have to be done
: > before invoking newvers.sh.  
: 
: David,
: 
: Trying to understand what you're getting at here. What's your use case
: for invoking newvers.sh from the command line? AFAIK it's only every
: used as part of the build process. Once by the kernel build and once for
: library related stuff (IIRC).

It is used in the kernel build (in a couple of different places) and
in include/Makefile to generate osreldate.h.  I believe the latter can
be simplified to not require it.

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

Re: [PATCH] newvers.sh

[M. Warner Losh]

In message: <4b9ee1ad.9080...@freebsd.org>
Doug Barton  writes:
: > I believe the latter can be simplified to not require it.
: 
: When I last looked at it I vaguely recall thinking that not needing
: newvers.sh for that purpose was a good goal, but ENOTIME.

Right now it is required to set COPYRIGHT and RELDATE.  The former
isn't necessary (I don't believe this file could be copyrighted) and
the latter could be replaced with a simple grep.

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

Re: Increasing MAXPHYS

[M. Warner Losh]

In message: 
Scott Long  writes:
: I'd like to go in the opposite direction.  The queue-dispatch-queue
: model of GEOM is elegant and easy to extend, but very wasteful for
: the simple case, where the simple case is one or two simple
: partition transforms (mbr, bsdlabel) and/or a simple stripe/mirror
: transform.  None of these need a dedicated dispatch context in order
: to operate.  What I'd like to explore is compiling the GEOM stack at
: creation time into a linear array of operations that happen without
: a g_down/g_up context switch.  As providers and consumers taste each
: other and build a stack, that stack gets compiled into a graph, and
: that graph gets executed directly from the calling context, both
: from the dev_strategy() side on the top and the bio_done() on the
: bottom.  GEOM classes that need a detached context can mark
: themselves as such, doing so will prevent a graph from being
: created, and the current dispatch model will be retained.

I have a few things to say on this.

First, I've done similar things at past companies for systems that are
similar to geom's queueing environment.  It is possible to convert the
queueing nodes in the graph to filtering nodes in the graph.  Another
way to look at this is to say you're implementing direct dispatch into
geom's stack.  This can be both good and bad, but should reduce
latency a lot.

One problem that I see is that you are calling into the driver from a
different set of contexts.  The queueing stuff was there to protect
the driver from LoRs due to its routines being called from many
different contexts, sometimes with other locks held (fact of life
often in the kernel).

So this certainly is something worth exploring, especially if we have
optimized paths for up/down for certain geom classes while still
allowing the current robust, but slow, paths for the more complicated
nodes in the tree.  It remains to be see if there's going to be issues
around locking order, but we've hit that with both geom and ifnet in
the past, so caution (eg, running with WITNESS turned on early and
often) is advised.

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

Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32

[M. Warner Losh]

In message: <20100322185331.ga88...@dragon.nuxi.org>
"David O'Brien"  writes:
: On Fri, Mar 12, 2010 at 12:50:32PM -0700, M. Warner Losh wrote:
: > : On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote:
: > So the issue isn't as cut and dried as you might think.  There's
: > multiple different conventions used here in addition to your simple
: > example.
: 
: I guess we'd have to take a poll to find out.  Seems pretty cut and dried
: to me.  COMPAT_FREEBSDn has an established context that does not match
: this new usage.  That is - same bit'ness, compatibility with an older
: FreeBSD API for the same architecture.  All the other COMPAT_* are for
: foreign ABI compatibility.  COMPAT_LINUX32 possibly should have been
: "COMPAT_LINUX_X86_64".  (or is it MI and is usable as-is for PowerPC
: and MIPS?  I haven't looked that deeply at the code.)

no, COMPAT_LINUX32 is the right name.  While we don't have PowerPC or
MIPS linux emulation bits in the kernel, the code if for dealing with
running 32-bit binaries on 64-bit machines.  There may be a little
leakage of x86 specific goo here, but not a lot.

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

Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32

[M. Warner Losh]

P.S.  I think that there's much traction to the idea of moving from
COMPAT_FREEBSDx to some other variable called, for example,
COMPAT_FREEBSD_BACK_TO=x, which will give compatibility for binaries
as old as FreeBSD x.0, and have all the other magic handled behind the
scenes.  This would render the inconsistency with COMPAT_FREEBSDx part
of the debate completely moot.

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

Re: Switchover to CAM ATA?

[M. Warner Losh]

I've read most of this thread.  I think this is cool technology.
However, before we move forward with this, we need to have a plan for
the various issues that have come up.  The plan needs to be specific,
have owners for key items, warnings about ownerless == obsoleted, and
target dates.

I think this is one of the cases where we should record the plan of
record on a wiki.  It worked well for other times we've had big,
disruptive changes.

My opinion for the path forward:
(1) Send a big heads up about the future of ataraid(5).  It will be
shot in the head soon, to be replaced be a bunch of geom classes
for each different container format.  At least that seems to be
the rough consensus I've seen so far.  We need worker bees to do
many of these classes, although much can be mined from the ataraid
code today.
(2) Send another big heads up strongly recommending people go to
glabel based fstabs.  Maybe the right option here is to provide a
simple script walk people through the conversion.  This will
render the carnage of ad -> ada (or da) a mostly non-event, and
also protect people from 'oops' of rebooting with that thumb drive
in the system.
(3) Create a wiki to record all the new geom classes needed.  Find
people to own each one, or note it is unowned, and support will be
dropped if no owner can be found.
(4) sysinstall should default to creating label systems, if it doesn't
already.
(5) Issues with glabel and ataraid(5) need an owner, and need to be
resolved, since the device names here are likely to change.
(6) Someone needs to write-up a detailed description of how to do this
for UPDATING.  Maybe we can reuse text from #2.
(7) We need a target time line for these things to happen.  We can't
just break ataraid(5) by default with little or no warning.
Realistically, this will be for 9.0 and later systems, so we have
some time before the branch to give warning, as well as pull the
switch and have adequate testing time.
(8) Fill in all the parts that I've missed :)

Comments?

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

Re: Switchover to CAM ATA?

[M. Warner Losh]

In message: <20100426181209.gb3...@garage.freebsd.pl>
Pawel Jakub Dawidek  writes:
: On Mon, Apr 26, 2010 at 10:33:27AM -0600, M. Warner Losh wrote:
: > I've read most of this thread.  I think this is cool technology.
: > However, before we move forward with this, we need to have a plan for
: > the various issues that have come up.  The plan needs to be specific,
: > have owners for key items, warnings about ownerless == obsoleted, and
: > target dates.
: > 
: > I think this is one of the cases where we should record the plan of
: > record on a wiki.  It worked well for other times we've had big,
: > disruptive changes.
: > 
: > My opinion for the path forward:
: > (1) Send a big heads up about the future of ataraid(5).  It will be
: > shot in the head soon, to be replaced be a bunch of geom classes
: > for each different container format.  At least that seems to be
: > the rough consensus I've seen so far.  We need worker bees to do
: > many of these classes, although much can be mined from the ataraid
: > code today.
: 
: This shouldn't be a bunch of GEOM classes. This should one class which
: recognize multiple formats, just like the LABEL class.
: I don't think it is feasible to reuse gmirror for that, it wasn't
: designed in something like this in mind.

OK.  Maybe I got the consensus wrong...  My key point is that we need
a plan moving forward, we need to identify what's actively being
worked on vs "somebody else[tm] should do tihs" and when it needs to
be done "or else".

: > (2) Send another big heads up strongly recommending people go to
: > glabel based fstabs.  Maybe the right option here is to provide a
: > simple script walk people through the conversion.  This will
: > render the carnage of ad -> ada (or da) a mostly non-event, and
: > also protect people from 'oops' of rebooting with that thumb drive
: > in the system.
: > (3) Create a wiki to record all the new geom classes needed.  Find
: > people to own each one, or note it is unowned, and support will be
: > dropped if no owner can be found.
: > (4) sysinstall should default to creating label systems, if it doesn't
: > already.
: > (5) Issues with glabel and ataraid(5) need an owner, and need to be
: > resolved, since the device names here are likely to change.
: 
: What are the issues?

ataraid doesn't remove the underlying ad* devices, so glabel often
picks those up instead of the ataraid device, and you only get 1
disk's worth of raid device...  So no mirroring or only 1/2 a striped
volume.

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

Re: config(8) dumps core

[M. Warner Losh]

In message: <20100429224938.gi90...@darkthrone.kvedulv.de>
Michael Moll  writes:
: Hi,
: 
: On Thu, Apr 29, 2010 at 11:30:06PM +0100, Bruce Cran wrote:
: > /boot/kernel/kernel".  It looks like it thinks there's more data available 
: > than there is.
: > 
: > config/main.c gets the size of the configuration by running elfdump:
: > 
: > > elfdump -c /boot/kernel/kernel | grep -A 5 kern_conf | tail -2 | cut -d ' 
' 
: > -f 2 | paste - - -
: > 
: > 100533682656
: > 
: > The first column is the offset, and the second is the number of bytes, but 
the 
: > embedded configuration only has 2649 bytes.
: 
: OK, that explains that with all the related commits backup out
: (207265-206664) the resulting config-binary still fails. I don't have
: time today to build the kernel with the different revisions to hunt the
: problem down to one commit...
: 
: imp@: The last commits to usr.sbin/config/* might have raised this
: problem, could you have a look at it?

Do you have a small, reproducible sequence of events that will
recreate this problem?  I've seen no problems at all in my testing.
I assume this is in -current?

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

Re: config(8) dumps core

[M. Warner Losh]

In message: <2010043016.ga90...@darkthrone.kvedulv.de>
Michael Moll  writes:
: On Thu, Apr 29, 2010 at 05:07:00PM -0600, M. Warner Losh wrote:
: > Do you have a small, reproducible sequence of events that will
: > recreate this problem?  I've seen no problems at all in my testing.
: > I assume this is in -current?
: 
: Yes, -CURRENT. Compile a kernel on sparc64 (didn't try this yet on other
: archs) and run config -x on the resulting file.

Can you please enclose the exact config file that you are using?
Thanks.

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

Re: NEWCARD, devd, sio and PCCARD_FUNCTION_SERIAL cards

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Maksim Yevmenkin <[EMAIL PROTECTED]> writes:
: Dear Warner and Hackers,
: 
: Is there any way (on -current with NEWCARD) "devd" can
: prevent "sio" driver from attaching to *ANY* pc-card
: that has PCCARD_FUNCTION_SERIAL?

Sure.  Just have sio_pccard_match return -100.  I've just committed
the change to do this.  No need to do anything else, I think.

Warner

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

Re: RC2 "install" report, three problems

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Martin Blapp <[EMAIL PROTECTED]> writes:
: 3.) Unable to install from a Realtec pcmcia card (Realtek RTL8139)
: 
: The card is properly detected, but it seems that it doesn't get
: power turned on. Looks like Warner needs to fix something here. All
: we get here are "rl0: watchdog timeout".

dmesg output here?  Looks like there's no interrupts for the card.

One other thing to try is to wait until after you've booted to insert
the card (and after if_rl.ko is loaded).  There's currently a minor
problem with doing a kldload if_.ko for a cardbus card that's
inserted into the unit and has failed to activate at least once.

Warner

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

Re: NEWCARD, devd, sio and PCCARD_FUNCTION_SERIAL cards

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Maksim Yevmenkin <[EMAIL PROTECTED]> writes:
: Dear Warner and Hackers,
: 
: --- "M. Warner Losh" <[EMAIL PROTECTED]> wrote:
: > In message: <[EMAIL PROTECTED]>
: > Maksim Yevmenkin <[EMAIL PROTECTED]> writes:
: > : Dear Warner and Hackers,
: > : 
: > : Is there any way (on -current with NEWCARD) "devd" can
: > : prevent "sio" driver from attaching to *ANY* pc-card
: > : that has PCCARD_FUNCTION_SERIAL?
: > 
: > Sure.  Just have sio_pccard_match return -100.  I've just committed
: > the change to do this.  No need to do anything else, I think.
: 
: Nope :( It does not work. I applied patch to /sys/dev/sio/sio_pccard.c
: and recompile my kernel with NEWCARD. It seems devd pays no attention
: when i plug or unplug the 3COM card. I have attached dmesg output and
: my devd.conf file. I was trying to get devd to kldload ng_bt3c module,
: but it did not work. Am i missing something obvious here?

Yes.  You need to have ng_bt3c loaded before you insert the card.
That's because of three reasons:

1) We don't detach a device when it 'won' the bidding on the device
   with a bid < 0 when a new driver is loaded.
2) There device is known, so devctl doesn't report anything to devd
   because it is known (it will report the sio attach).
3) devd ignores all unknown devices at the current time.

I'm working on most of these issues, but not the 'rescan' issue.

Warner

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

Re: NEWCARD, devd, sio and PCCARD_FUNCTION_SERIAL cards

[M. Warner Losh]

Yes, devd is kinda hardwired at the moment.  I have some changes in my
tree that I need to finish up before the release.

Warner

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

Re: UPDATING error

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Andy Farkas <[EMAIL PROTECTED]> writes:
: 
: $FreeBSD: src/UPDATING,v 1.228 2002/10/30 20:11:07 imp Exp $
: 
: "To upgrade from 4.x-stable to current" suggests:
: 
:  cd src/sys/boot ; make install [6]
: 
: This does not work. You need to:
: 
:  cd src/sys/boot ; make all install [6]

make all isn't needed here because it was already built as part of the
buildworld.

Warner

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

Re: My wi(4) ate itself (or Fun with no memory).

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Juli Mallett <[EMAIL PROTECTED]> writes:
: I ran some stuff overnight which exhausted my system's memory fairly well,
: and was also thrashing around on my network, and I woke up to find that my
: wi(4) blew up more or less:
: 
: wi0: watchdog timeout
: wi0: timeout in wi_cmd 0x0002; event status 0x8000
: wi0: timeout in wi_cmd 0x; event status 0x8000
: wi0: wi_cmd: busy bit won't clear.

The firmware on your card hung hard.  The wi driver doesn't deal with
that at all well (although one could rightly argue it should).  Why
the firmware hung hard, I cannot say.

Warner

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

Re: My wi(4) ate itself (or Fun with no memory).

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Juli Mallett <[EMAIL PROTECTED]> writes:
: /var/log/messages:Dec 30 17:11:35 luna kernel: wi0: failed to allocate 1594 bytes on 
:NIC
: 
: Like those?

Those are usually an indication of no interrupts.  Memory is allocated
when packets are sent and deallocated in the ISR.  No ISR, no
deallocation.

Warner

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

Re: My wi(4) ate itself (or Fun with no memory).

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Michael Ranner <[EMAIL PROTECTED]> writes:
: Am Montag, 30. Dezember 2002 23:10 schrieb Lee Damon:
: > I have the same problems on an IBM T30 with integrated wi running
: > 4.7-STABLE. In fact, I've had this problem since 4.5 (which is where I
: > started on this system.)
: 
: I think the "wi0: timeout in wi_cmd 0x; event status 0x8000"
: messages started around 4.4, 4.5 or so. With my old FreeBSD 4 I had no 
: "visible" problems, but after upgrading to 4.7 I have tons of wi_timeout's
: 
: I fixed it with:
: 
: 1359c1359
: <   DELAY(WI_DELAY);
: ---
: >   /*DELAY(WI_DELAY);*/

This delay is needed on far too many cards to just delete it.

: 1363,1364c1363,1364
: <   device_printf(sc->dev, "timeout in wi_seek to %x/%x; last 
: status %x\n",
: <   id, off, status);
: ---
: >   /*device_printf(sc->dev, "timeout in wi_seek to %x/%x; last 
: status %x\n",
: >   id, off, status);*/

this isn't a fix.

: The big problem was the "DELAY", because this call freezes the system and that
: was not acceptable for a router, but I also increased the value of the 
: surrounding loop.

The big problem is that we have a horrible reset policy in the wi
driver.  When it gets into this state, we're screwing the system into
the ground in the driver.

Warner

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

Re: if_dc.c locking patch

[M. Warner Losh]

Wouldn't it be better if you didn't do the bogus locking in the attach
routine?  It would be better to not lock at all and not initialize the
ISR until last.  That's what I did with if_rl.  Let's not work around
the bogus locking, but insteal eliminate it.  There's no way that the
driver can interrupt itself until an interrupt happens.  If there's no
way to interrupt, no locking is needed :-)

Also, most of the driver locking that's in the tree is likely bogus
anyway, since the network stack still uses giant to a large extent.

Warner

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

Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Robert Watson <[EMAIL PROTECTED]> writes:
: assuming it's something about poor signal handling in libc_r, actually.

I've seen signal problems in devd after it forks a child.  Before it
forks a child ^C works, but after it does a system(3) to run a
command, ^C no longer works.  There's something really odd going on
that I've not had time to figure it out.

Warner

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

Re: Proper -current if_attach locking?

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Nate Lawson <[EMAIL PROTECTED]> writes:
: I was looking into some "could sleep messages" and found some bogus
: locking in the attach routine of many drivers.  Several init a mtx in
: their softc and then lock/unlock it in their attach routine.  This, of
: course, does nothing to provide exclusive access to a device.  I assume
: there is going to be a global IF_LOCK or something to be used in attach
: routines.  Can someone fill me in on the intended design?

The locking in the attach routines is generally bogus.  Locking is
only needed when you have more than one thread of execution.  You
don't have more than one thread of execution until after you establish
the ISR and turn on interrupts.  We should likely not be enabling
interrupts until very late in the attach routine so that we don't need
any locking in them.

Warner

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

Re: Proper -current if_attach locking?

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Terry Lambert <[EMAIL PROTECTED]> writes:
: "M. Warner Losh" wrote:
: > In message: <[EMAIL PROTECTED]>
: > Nate Lawson <[EMAIL PROTECTED]> writes:
: > : I was looking into some "could sleep messages" and found some bogus
: > : locking in the attach routine of many drivers.  Several init a mtx in
: > : their softc and then lock/unlock it in their attach routine.  This, of
: > : course, does nothing to provide exclusive access to a device.  I assume
: > : there is going to be a global IF_LOCK or something to be used in attach
: > : routines.  Can someone fill me in on the intended design?
: > 
: > The locking in the attach routines is generally bogus.  Locking is
: > only needed when you have more than one thread of execution.  You
: > don't have more than one thread of execution until after you establish
: > the ISR and turn on interrupts.  We should likely not be enabling
: > interrupts until very late in the attach routine so that we don't need
: > any locking in them.
: 
: I looked at this.  It seems to me that it's not quite that
: simple (sorry).  I think that there are issues with locking
: because you don't know if this is a driver that's getting
: loaded well after the system has booted, or if this is a
: PCCARD or other "hot plug" device that has just arrived in
: the system.

That doesn't mattar at all.  If it is a new device that's just
arrived, the attach still won't be interrupted *by other code in the
driver* until after it has setup its ISR and told the hardware to
start generating interrupts.  No device locking is needed in the
attach routine until after interrupts are enabled in the hardware.

: It also seems to me that the "reversal" problems that would
: result by simply inserting locking have to do with the fact
: that the code is relatively schitzophrenic on deciding whether
: it's locking data, or it's locking a critical path.

The reversal is because of the bogus locking.  The first time through
it locks the device then the interface.  However, after that it locks
the interface and then the device, which can be bad.  It does point to
a problem, however, in that sometimes we'll take out the locks in one
order and other times other orders depending on the code path if we
aren't careful.  I should go look at the new code more closely.

I worry that in the non interrupt case we get things in the IF, DEV
order (because the IF locks, then calls the callback routines, which
then call the DEV lock).  But in the interrupt case we get the DEV
lock first, then try to queue data and that somehow causes the IF
locks to be grabbed.

But you are right, I do need to go look at the code to see what,
exactly, is happening and how the new interface locking code is
interacting with the semi-bogus locking than many of the wpaul drivers
have in them now.

: I can't be the only one who finds FreeBSD 5.x to be in such a state
: of flux that it's almost impossible to know what a correct
: implementation is supposed to look like, for a given subsystem
: and/or device driver, list, etc..

There we agree.  It takes a lot to keep up, and even then I fall
behind when something new happens behind my back.

Warner

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

Re: Proper -current if_attach locking?

[M. Warner Losh]

I was right (and I think you are too).  We do have lock issues.

dc_attach does approximately:

DC_LOCK
ether_attach()  (which does a IFNET_WLOCK/UNLOCK pair)
DC_UNLOCK

(this sets the lock order to be DC_LOCK, IFNET_WLOCK).

However in if_slowtimo we have:

if_slowtimo(arg)
{
... IFNET_RLOCK();
... if (ifp->if_watchdog)
(*ifp->if_watchdog)(ifp);
... IFNET_RUNLOCK();
}

and dc_watchdog does a DC_LOCK/UNLOCK pair).  This is a Lock Order
Reversal, and not a LotR :-)

What's worse is that dc_intr does:

DC_LOCK
...dc_start (which calls IF_PREPEND which does the IFNET_LOCK/UNLOCK thing)
DC_UNLOCK

So even if we remove the one from attach, it looks like we have others
lurking in the code.

Either that, or it is too late for me to be looking at code like this
:-(

Warner

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

Re: Proper -current if_attach locking?

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Andrew Gallatin <[EMAIL PROTECTED]> writes:
: The IFNET_RLOCK() called in if_slowtimo() is a global lock for the
: list of ifnet structs to ensure that no devices are removed or added
: while something may be using it.  There is one ifnet list in the system.

So this means that only the locking in attach is bogus, and similar
locking in detach is also bogus because they produce lock order
reversals as the global lock is held to insert/remove if interfaces.

: The lock in IF_PREPEND() (and more commonly used in drivers,
: IF_DEQUE()) is per-ifq, to protect against multiple accesses 
: to a single  ifq.  There are many ifqs in the system.

I knew I must have been missing something really fundamental last
night.

Warner

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

Re: Proper -current if_attach locking?

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Andrew Gallatin <[EMAIL PROTECTED]> writes:
: 
: M. Warner Losh writes:
:  > In message: <[EMAIL PROTECTED]>
:  > Andrew Gallatin <[EMAIL PROTECTED]> writes:
:  > : The IFNET_RLOCK() called in if_slowtimo() is a global lock for the
:  > : list of ifnet structs to ensure that no devices are removed or added
:  > : while something may be using it.  There is one ifnet list in the system.
:  > 
:  > So this means that only the locking in attach is bogus, and similar
:  > locking in detach is also bogus because they produce lock order
:  > reversals as the global lock is held to insert/remove if interfaces.
: 
: Yes.  Though I haven't looked at if_dc myself, there may be other
: locking problems.  I've only been commenting on the ones that you
: brought up.
: 
: But back to an earlier point.  Somebody (you?) validly pointed out
: that the driver should not be callable and should not generate
: interrupts until its finished attaching.  The lock in its attach was
: probably a somewhat misguided attempt at that.  

Yes.  That was me.  There are some drivers that have separated
front/back ends that makes this harder, but most of them don't.

: The first point can be accomplished by doing the ether_ifattach()
: last, but the second may be harder.  I do that by poking a bit on my
: card which prevents it from generating interrupts while the device is
: being setup.  Not sure if a similar bit exists on tulip cards.

All PCI cards have to be able to turn off their interrupt sources,
otherwise interrupt storms result.  At least that's my understanding.

Warner

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

Re: Still problems with PCCARD NICs

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
"Greg 'groggy' Lehey" <[EMAIL PROTECTED]> writes:
: 2.  3Com 3c905.

this is a cardbus card?

: # ifconfig xl0 mediaopt 100baseTX
: ifconfig: SIOCSIFMEDIA: Device not configured

User error: You must specify media if you are going to specify media
opt.

Warner

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

Re: 5.0-RC2/if_awi.ko doesn't load

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Jun Kuriyama <[EMAIL PROTECTED]> writes:
: At Fri, 10 Jan 2003 00:33:47 + (UTC),
: Nicolas Christin wrote:
: > I just tried to give a shot to 5.0-RC2 on an old box of mine that can
: > only perform network installs (no CD drive). During the boot process, a
: > module failed to load.
: > 
: > DEBUG: Loading module if_awi.ko (BayStack 660 and others)
: > link_elf: symbol rc4_init undefined
: 
: I got same result on today's snapshot of HEAD (20030113-JPSNAP).  I'm
: using {kern,mfsroot}.flp and FTP installation.

I'm planning on integrating the awi driver from NetBSD now that Sam
has committed his work on the 802.11 port.

Warner

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

Re: No way to disable loading of agp.1 on boot?

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
David Spreen <[EMAIL PROTECTED]> writes:
: Heyho, 
: 
: "Coercitas Temet'Nosce" <[EMAIL PROTECTED]> writes:
: > hw.pci.enables_io_modes=0
: 
: This value doesn't seem to exist on the bootprompt. show 
: hw.pci.enables_io_modes is the correct name?
: 
: And isn't set name the command I have to type?
: 
: set hw.pci.enables_io_modes=0 doesn't help.
: 
: It's the same with your second variable.
: 
: >  hw.pci_allow_unsupported_io_range=1
: 
: Would be cool if you'd tell me what I got wrong.
: 
: thanks for your help,

You misunderstand what you can set from the boot loader.  You can set
any variable you like at the ok prompt, even if you can't show it
first:

ok show hw.pci_allow_unsupported_io_range

ok set hw.pci_allow_unsupported_io_range 1
ok show hw.pci_allow_unsupported_io_range
hw.pci_allow_unsupported_io_range=1
ok

Warner

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

Re: HEADS UP: new wi driver

[M. Warner Losh]

: dstumbler breaks; on startup it reports
: "unable to ioctl device socket: Input/output error".

As root or no?

Warner

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

Re: No way to disable loading of agp.1 on boot?

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
David Spreen <[EMAIL PROTECTED]> writes:
: Heyho, 
: 
: "M. Warner Losh" <[EMAIL PROTECTED]> writes:
: > You misunderstand what you can set from the boot loader.  You can set
: > any variable you like at the ok prompt, even if you can't show it
: > first:
: 
: Of course, but those variables don't work for me, so I want to know if
: I got something wrong. The kernel still hangs during that agp-pci-issue.
: 
: any further suggestions?

OK.  I misunderstood your message then.  They were added relatively
recently to 5.0 (sometime just before RC1 or RC2 IIRC), so either they
do you no good because your problem is solved in different ways, or
you need to upgrade (or both).

Warner

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

Re: new wi0 slowness

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
"Matt Haught" <[EMAIL PROTECTED]> writes:
: I can change the media through ifconfig to DS/11Mbps or whatever, but it
: does not seem to change anything other then ifconfig will show "media: IEEE
: 802.11 Wireless Ethernet DS/11Mbps  (DS/2Mbps )" rather then
: autoselect.  The same slowness is still there.  wicontrol shows it as having
: a TX rate (actual speed) of 2 no matter what.  I can set the (selection) to
: anything such as 11, and again no change in the throughput or anything.  I
: have also changed things with the old driver, and nothing changed with the
: throughput, and it also shows the (actual speed) as 2 but I get higher
: throughput.  It seems to kinda have a mind of its own.  Well if you need
: anymore info, just drop me a message.  I enabled debugging for wi0 as a
: earlier post showed, but I had no idea what I was looking at :).

This has nothing to do with your slowness.  The firmware in the card
always reports 2Mbps to the driver.  The slowdown comes from
elsewhere.

Warner

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

Re: alpha tinderbox failure

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Kris Kennaway <[EMAIL PROTECTED]> writes:
: On Fri, Jan 17, 2003 at 04:16:14PM -0800, Dag-Erling Smorgrav wrote:
: 
: > ===> vinum
: > "Makefile", line 4437: warning: duplicate script for target "geom_bsd.o"  [...]
: > /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver i [...]
: > /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
: > /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from [...]
: > /h/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver i [...]
: > /h/des/src/sys/pci/simos.c:30:2: warning: #warning "The simos driver is b [...]
: > cc1: warnings being treated as errors
: > /h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe':
: > /h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit  [...]
: > *** Error code 1
: 
: Am I the only one who thinks that the error message truncation makes
: it difficult to see the error?

Yes.  At the very least we should also truncate the /h/des/src from
the front which gives 10 more characters.  However, even that might
not be enough...

Warner

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

Re: How to build -current and install to empty slice?

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Ray Kohler <[EMAIL PROTECTED]> writes:
: > # cd /5/usr/src && MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make buildworld
: > # MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make kernel
: > # MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make installworld
: > # cd /5/usr/src/etc && DESTDIR=/5 make distribution
: 
: MAKEOBJDIRPREFIX is probably redundant here, but I don't know.

I don't think so.  I think you need it for all the commands that have
it.

Warner



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

Re: psm0 not found on a Sony Vaio w/ 5.0-RELEASE

[M. Warner Losh]

In message: 
Ben Hockenhull <[EMAIL PROTECTED]> writes:
: I recently installed 5.0-RELEASE on a Sony Vaio R505EC laptop and it's
: working pretty well, save for the fact that i can run X because my touchpad
: isn't found upon boot probe.
: 
: It used to be /dev/psm0 under 4.x-STABLE.  I understand I may need to edit
: sys/isa/psm.c and add my device, but I'm not sure what to put there.  Is
: there something analogous to pciconf that'll dump this device's
: descriptors?  Is there another way?

Is psm failing because it can't get irq 12?

Warner

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

Re: firewire hangs on Thinkpad

[M. Warner Losh]

This sounds like it might be an interrupt storm.  I'm not sure if the
fwohci driver is failing to clear an interrupt source, or if the
cardbus bridge is failing.  Have you connected a fw device to the
firewire card?

Warner

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

Re: Patch to teach config(8) about "platforms".

[M. Warner Losh]

Any reason why the NetBSD approach to this problem won't work?  IMHO,
the meta-port should drive the derived ports.  The static parts of the
system are radically different between the different mips platforms.

Using the endian.h stuff as an example:

src/sys/arch/arc/include/endian.h is just "#include "
src/sys/arch/arc/include/endian_machdep.h is

#define _BYTE_ORDER _LITTLE_ENDIAN
#include 

and src/sys/arch/mips/include/endian_machdep.h is a bunch of #defines
for assembler.

sys/endian.h looks like:

#define _LITTLE_ENDIAN  1234/* LSB first: i386, vax */
#define _BIG_ENDIAN 4321/* MSB first: 68000, ibm, net */
#define _PDP_ENDIAN 3412/* LSB first in word, MSW first in long */

#include 

...
#include 
#include 

typedef u_int32_t   in_addr_t;
typedef u_int16_t   in_port_t;

__BEGIN_DECLS
uint32_thtonl __P((uint32_t)) __attribute__((__const__));
uint16_thtons __P((uint16_t)) __attribute__((__const__));
uint32_tntohl __P((uint32_t)) __attribute__((__const__));
uint16_tntohs __P((uint16_t)) __attribute__((__const__));
__END_DECLS

... (more macros/functions)

In this case, there's very little duplication of effort.

Warner

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

Re: Patch to teach config(8) about "platforms".

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Marcel Moolenaar <[EMAIL PROTECTED]> writes:
: general theme. Thus (in this case), ARCH=mips and MACH=algor or
: MACH=sgimips...

Actually, NetBSD uses MACHINE_ARCH=mipsel for little endian machines
and MACHINE_ARCH=mips for big endian machines.  However, it has a
common set of mips include files/code, etc in src/sys/arch/mips
Forcing MACHINE_ARCH to be mips in both proved too problematic.

Warner


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