Re: A page fault in subr_turnstile.c:propogate_priority()

[Brian F. Feldman]

Igor Sysoev <[EMAIL PROTECTED]> wrote:
> I'd cvsup'ed 5.1-CURRENT from 2003.11.04.02.02.00 up to
> 2003.11.28.00.00.00 with the turnstile support and it can still
> causes sometimes a page fault in propogate_priority().
> I have core dump and can send debug output.

Go ahead and load up kernel.debug and the core dump in gdb -k, and show us 
the backtrace.  Also, do you have any idea about more specific circumstances 
that will cause this problem?  Thanks!

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\


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

Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)

[Brian F. Feldman]

Bernd Walter <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 21, 2003 at 12:35:50PM -0500, Brian F. Feldman wrote:
> > Doug White <[EMAIL PROTECTED]> wrote:
> > > The OHCI driver is largely synced with NetBSD so you might see if they
> > > have the same bug.
> > 
> > I'll look around for a bootable NetBSD CD.
> 
> NetBSD is different in that point.
> 
> > > This might be the underlying wierdness we were seeing in gtetlow's
> > > microdrive with transfers over 8k.  The one-page-crossing ohci limitation
> > > is really annoying.
> > 
> > Is there a way to add a quirk for max 8k transfers or anything?  Even though 
> > that would be patently lame, I'd like to get some sort of workaround here.  
> > I don't even know what is supposed to be the problem here -- the fact that 
> > it's an ohci controller, an ohci+ehci controller, or that it's some specific 
> > controller issue...
> 
> We never did any page crossing on ohci/ehci bevor the newbus change
> took place.

Found it!!!  Definitely a problem created then...

--- ohci.c  12 Nov 2003 01:40:11 -  1.138
+++ ohci.c  22 Nov 2003 03:28:42 -
@@ -569,7 +569,7 @@
cur->td.td_cbp = htole32(dataphys);
cur->nexttd = next;
cur->td.td_nexttd = htole32(next->physaddr);
-   cur->td.td_be = htole32(DMAADDR(dma, curlen - 1));
+   cur->td.td_be = htole32(DMAADDR(dma, offset + curlen - 1));
cur->len = curlen;
cur->flags = OHCI_ADD_LEN;
cur->xfer = xfer;

I'm a lot happier now :-)  Let's start trying to get this stuff merged in!

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\


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

Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)

[Brian F. Feldman]

Bernd Walter <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 21, 2003 at 12:35:50PM -0500, Brian F. Feldman wrote:
> > Doug White <[EMAIL PROTECTED]> wrote:
> > > The OHCI driver is largely synced with NetBSD so you might see if they
> > > have the same bug.
> > 
> > I'll look around for a bootable NetBSD CD.
> 
> NetBSD is different in that point.
> 
> > > This might be the underlying wierdness we were seeing in gtetlow's
> > > microdrive with transfers over 8k.  The one-page-crossing ohci limitation
> > > is really annoying.
> > 
> > Is there a way to add a quirk for max 8k transfers or anything?  Even though 
> > that would be patently lame, I'd like to get some sort of workaround here.  
> > I don't even know what is supposed to be the problem here -- the fact that 
> > it's an ohci controller, an ohci+ehci controller, or that it's some specific 
> > controller issue...
> 
> We never did any page crossing on ohci/ehci bevor the newbus change
> took place.

Are you hinting that I need to find some way to "defragment" the DMA buffers 
I'm getting back?

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\


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

Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)

[Brian F. Feldman]

Doug White <[EMAIL PROTECTED]> wrote:
> The OHCI driver is largely synced with NetBSD so you might see if they
> have the same bug.

I'll look around for a bootable NetBSD CD.

> This might be the underlying wierdness we were seeing in gtetlow's
> microdrive with transfers over 8k.  The one-page-crossing ohci limitation
> is really annoying.

Is there a way to add a quirk for max 8k transfers or anything?  Even though 
that would be patently lame, I'd like to get some sort of workaround here.  
I don't even know what is supposed to be the problem here -- the fact that 
it's an ohci controller, an ohci+ehci controller, or that it's some specific 
controller issue...

> On Thu, 20 Nov 2003, Brian F. Feldman wrote:
> 
> > Thanks for the patches to try!  They unfortunately didn't fix the crash I
> > have, but I found out why it's occurring.
> >
> > See ohci.c:1389:
> > if (std->td.td_cbp != 0)
> > len -= le32toh(std->td.td_be) -
> >le32toh(std->td.td_cbp) + 1;
> >
> > In one of my transfers (look in my log for the 2560 byte one) that statement
> > actually adds 8192 to len, which is utterly bogus because you can see it
> > only allocates 2560 -- hence when it tries to finish the transfer it
> > memcpy()'s way too much memory and my kernel segfaults.  If I #if 0 this out,
> > I'm left only with "umass0: BBB reset failed, STALLED" messages... which is
> > a lot better than before!  I don't know under what situations that bit of
> > code makes sense, but it definitely needs more reviewing!
> 
> Stalls usually come from the device receiving bad data.  Rather than
> return errors, usb generally just hangs the endpoint.

Hmm :-/  I wonder if anyone could interpret the debugging info enough to 
have an idea what it's disliking for certain.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\


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

Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)

[Brian F. Feldman]

"Brian F. Feldman" <[EMAIL PROTECTED]> wrote:
> Thanks for the patches to try!  They unfortunately didn't fix the crash I 
> have, but I found out why it's occurring.
> 
> See ohci.c:1389:
> if (std->td.td_cbp != 0)
> len -= le32toh(std->td.td_be) -
>le32toh(std->td.td_cbp) + 1;
> 
> In one of my transfers (look in my log for the 2560 byte one) that statement 
> actually adds 8192 to len, which is utterly bogus because you can see it 
> only allocates 2560 -- hence when it tries to finish the transfer it 
> memcpy()'s way too much memory and my kernel segfaults.  If I #if 0 this out,
> I'm left only with "umass0: BBB reset failed, STALLED" messages... which is 
> a lot better than before!  I don't know under what situations that bit of 
> code makes sense, but it definitely needs more reviewing!
> 
> Please check out my debugging messages and tell me if you see any hints as 
> to why the transfers are getting stalled.  I should have looked at the 
> debugging messages long ago, I guess.   Thanks!
> 
> http://green.homeunix.org/~green/ohci-debugging.txt.gz

BTW, replying to myself -- it seems to be something missing from the 
multi-allocation transfers (>8KB), because I can do up to 8KB transfers 
perfectly fine now, but 10KB ones, for example, like mdir(8) does are the 
ones that give me BBB stalls.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\


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

Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)

[Brian F. Feldman]

Thanks for the patches to try!  They unfortunately didn't fix the crash I 
have, but I found out why it's occurring.

See ohci.c:1389:
if (std->td.td_cbp != 0)
len -= le32toh(std->td.td_be) -
   le32toh(std->td.td_cbp) + 1;

In one of my transfers (look in my log for the 2560 byte one) that statement 
actually adds 8192 to len, which is utterly bogus because you can see it 
only allocates 2560 -- hence when it tries to finish the transfer it 
memcpy()'s way too much memory and my kernel segfaults.  If I #if 0 this out,
I'm left only with "umass0: BBB reset failed, STALLED" messages... which is 
a lot better than before!  I don't know under what situations that bit of 
code makes sense, but it definitely needs more reviewing!

Please check out my debugging messages and tell me if you see any hints as 
to why the transfers are getting stalled.  I should have looked at the 
debugging messages long ago, I guess.   Thanks!

http://green.homeunix.org/~green/ohci-debugging.txt.gz

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\


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

Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)

[Brian F. Feldman]

Josef Karthauser <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 17, 2002 at 01:18:00PM -0500, Brian F. Feldman wrote:
> > 
> > > ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe)
> > > ohci_device_bulk_start+0x0d
> > > ohci_device_bulk_transfer+0x27
> > > usbd_transfer+0xc0
> > > umass_setup_transfer+0x4f
> > > umass_bbb_state
> > > usb_transfer_complete
> > > ohci_softintr
> > > 
> > > Can anyone confirm if this is normal or I have an exceptional system?  I 
> > > have two completely unrelated OHCI-based controllers in my system and 
> > > neither works.
> > 
> > Anyone?  I kinda want to use my CF reader.
> > 
> 
> There are rumours that OHCI is borked in NetBSD too and this is a bug
> that we've inherited.  Me, I've not got an OHCI system to test just
> UHCI.
> 
> Did it used to work, and got broken, or has it never worked?

Jeez, it's been broken a year and it's almost 5.2-RELEASE now.  Does anyone 
have ANY leads on these problems?  I know precisely nothing about how my USB 
hardware is supposed to work, but this OHCI+EHCI stuff definitely doesn't, 
and it's really not uncommon at all.  Is it unbroken in NetBSD currently?

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\


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

Re: Kernel Panic

[Brian F. Feldman]

Steve Ames <[EMAIL PROTECTED]> wrote:
> 
> For the past few weeks my -CURRENT system has been locking up. With a
> recent kernel (from 11/2) the following appears:
> 
> Fault trap 12:  page fault while in kernel mode
> fault virtual address = 0x24
> fault code  = supervisor read, page not present
> instruction pointer  = 0x8:0xc049d0db
> stack pointer  = 0x10:0xe009cc88
> frame pointer  = 0x10:0xe009cc9c
> code segment  = base 0x0, limit 0xf, type 0x1b
>= DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process  = 23 (irq10: dc0)
> trap number  = 12
> panic: page fault
> syncing disks, buffers remaining... 6800 6800
> 
> That bit about the current process and 'dc0' kind of makes me believe
> it was a dc driver issue? I may replace that card (with an ethernet
> card that doesn't use dc) and see if the problem goes away.
> 
> Am I correct in believing this is a dc issue? If so, hope the above
> helps in diagnosing the problem. Otherwise... any other pointers?
instruction pointer  = 0x8:0xc049d0db
That will tell you exactly where the problem is...

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\


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

Re: cvs commit: src/sys/kern vfs_bio.c

[Brian F. Feldman]

Kirk McKusick <[EMAIL PROTECTED]> wrote:
> mckusick2003/11/03 22:30:01 PST
> 
>   FreeBSD src repository
> 
>   Modified files:
> sys/kern vfs_bio.c 
>   Log:
>   Allow the bufdaemon and update daemon processes to skip the
>   waitrunningbufspace() calls so that they are always able to
>   proceed and clean up buffer space.

This will fix at least some of any deadlocks you may be seeing with md(4) or 
similar devices, totally unrelated to hardware.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\


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

Re: runningbufspace related lock-ups with md(4)/UFS/SU (PATCH ?)

[Brian F. Feldman]

"Brian F. Feldman" <[EMAIL PROTECTED]> wrote:
> Kirk McKusick <[EMAIL PROTECTED]> wrote:
> > I have been able to reproduce your hang on my system and your suggested
> > fix does prevent it. I am going to run some more buffer starvation-type
> > tests on it this week and if they do not cause other problems, I will
> > put in your suggested fix.
> 
> Thanks, Kirk; seems everyone who's been able to reproduce it can't do so 
> anymore when the synchers are disallowed from waiting on runningbufspace 
> (a couple extra people testing it that haven't spoken up on the list).

Replying to myself -- anyone with any further thoughts, objections, desire 
to fix this one way or another?


-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\


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

Re: runningbufspace related lock-ups with md(4)/UFS/SU (PATCH ?)

[Brian F. Feldman]

Kirk McKusick <[EMAIL PROTECTED]> wrote:
> I have been able to reproduce your hang on my system and your suggested
> fix does prevent it. I am going to run some more buffer starvation-type
> tests on it this week and if they do not cause other problems, I will
> put in your suggested fix.

Thanks, Kirk; seems everyone who's been able to reproduce it can't do so 
anymore when the synchers are disallowed from waiting on runningbufspace 
(a couple extra people testing it that haven't spoken up on the list).

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\


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

Re: dsp "device busy" (me too) vchans weirdness

[Brian F. Feldman]

John Hay <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 12, 2003 at 08:31:11PM +0200, John Hay wrote:
> > Just switching vchans off on the Dell made the sound work again.
> > 
> 
> Looks like I have to take that back. I just tried a brand new -CURRENT
> kernel and vchans are now working. I have only tried it by setting
> hw.snd.maxautovchans. It does produce a lot of "could sleep with"
> messages though:

Yeah. I found and fixed that a few days ago.  It's been around for at least 
a month, but for some reason I'm getting a lot of ENODEV errors in dsp_reset()
which is what made it known.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: Patch #3 Re: UMA panic under load

[Brian F. Feldman]

Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Whoop.  Ok, here's a new patch.  I think this covers all the cases.
> I've done some testing and it appears to do the right thing, please
> look it over (the last patch had type-o's and didn't cover the correct
> cases).

I haven't tested, since I haven't provoked that specific panic on my 
machines, but that does appear that it would indeed fix both issues.  Kris, 
can you confirm that it makes the machines work properly?

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: UMA panic under load

[Brian F. Feldman]

Matthew Dillon <[EMAIL PROTECTED]> wrote:
> What about something like this.  If the vm_refcnt is still being
> decremented too early, could it be moved to just before the thread_exit()
> call?

The problem that had to be fixed by removing this race was that two 
processes with the same vmspace can exit at the same time, and the 
vm_refcnt could be 2 the entire time, so neither would perform the current
if (--vm->vm_refcnt == 0) { block.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: UMA panic under load

[Brian F. Feldman]

Jake Burkholder <[EMAIL PROTECTED]> wrote:
> Apparently, On Sat, Dec 14, 2002 at 07:37:31PM -0500,
>       Brian F. Feldman said words to the effect of;
> 
> > John Baldwin <[EMAIL PROTECTED]> wrote:
> > > 
> > > On 12-Dec-2002 Kris Kennaway wrote:
> > > > I got this on an alpha tonight.  It was under heavy load at the time
> > > > (18 simultaneous package builds had just been spawned on the machine).
> > > > Any ideas?
> > > > 
> > > > Slab at 0xfc00042d3fb8, freei 2 = 0.
> > > > panic: Duplicate free of item 0xfc00042d22e0 from zone 
>0xfc0007d31800(VMSPACE)
> > > > 
> > > > db_print_backtrace() at db_print_backtrace+0x18
> > > > panic() at panic+0x104
> > > > uma_dbg_free() at uma_dbg_free+0x170
> > > > uma_zfree_arg() at uma_zfree_arg+0x150
> > > > vmspace_free() at vmspace_free+0xe4
> > > > swapout_procs() at swapout_procs+0x428
> > > > vm_daemon() at vm_daemon+0x74
> > > > fork_exit() at fork_exit+0xe0
> > > > exception_return() at exception_return
> > > > --- root of call graph ---
> > > > panic
> > > > Stopped at  Debugger+0x34:  zapnot  v0,#0xf,v0  
> > > > db>
> > > 
> > > I have seen this on a couple of different arch's I think.  A vmspace
> > > shouldn't be free'd here, it's refcount should not be that low.
> > > I wonder if something is free'ing the vmspace w/o dropping the refcount?
> > 
> > The problem appears to be that swapout_procs() is swapping out a process 
> > that is in the process of exiting (in exit1()) and having already 
> > relinquished its vmspace, but has not set PRS_ZOMBIE yet (which would be 
> > preventing the swapout).  It's clearly not correct for a process in exit1() 
> > to be swapped out, and the vmspace _needs_ to be decremented in the correct 
> > place or resources are NEVER freed when the race is lost.
> 
> P_WEXIT is set, so the process won't get swapped out.  The problem is that
> the vmspace refcnt is 0 when swapout_procs is called, since it was
> decremented in exit1.  The refcnt is incremented before p_flag is tested
> for P_WEXIT, the swapout is skipped because its found to be set, and then
> vmspace_free is called which decrements the refcnt to 0 and prematurely
> frees the vmspace.  Decrementing the refcnt in exit1 breaks the normal
> refernce count semantics because the vmspace is not being freed then.

There are no normal reference count semantics; exit1() attempts to free 
parts of the vmspace.  Sounds to me like a simple solution is to check for 
P_WEXIT both before and after incrementing the vmspace refcount.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: UMA panic under load

[Brian F. Feldman]

John Baldwin <[EMAIL PROTECTED]> wrote:
> 
> On 12-Dec-2002 Kris Kennaway wrote:
> > I got this on an alpha tonight.  It was under heavy load at the time
> > (18 simultaneous package builds had just been spawned on the machine).
> > Any ideas?
> > 
> > Slab at 0xfc00042d3fb8, freei 2 = 0.
> > panic: Duplicate free of item 0xfc00042d22e0 from zone 
>0xfc0007d31800(VMSPACE)
> > 
> > db_print_backtrace() at db_print_backtrace+0x18
> > panic() at panic+0x104
> > uma_dbg_free() at uma_dbg_free+0x170
> > uma_zfree_arg() at uma_zfree_arg+0x150
> > vmspace_free() at vmspace_free+0xe4
> > swapout_procs() at swapout_procs+0x428
> > vm_daemon() at vm_daemon+0x74
> > fork_exit() at fork_exit+0xe0
> > exception_return() at exception_return
> > --- root of call graph ---
> > panic
> > Stopped at  Debugger+0x34:  zapnot  v0,#0xf,v0  
> > db>
> 
> I have seen this on a couple of different arch's I think.  A vmspace
> shouldn't be free'd here, it's refcount should not be that low.
> I wonder if something is free'ing the vmspace w/o dropping the refcount?

The problem appears to be that swapout_procs() is swapping out a process 
that is in the process of exiting (in exit1()) and having already 
relinquished its vmspace, but has not set PRS_ZOMBIE yet (which would be 
preventing the swapout).  It's clearly not correct for a process in exit1() 
to be swapped out, and the vmspace _needs_ to be decremented in the correct 
place or resources are NEVER freed when the race is lost.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: OHCI patch - please test [was Re: USB issues with Apollo KT133A mobo]

[Brian F. Feldman]

Josef Karthauser <[EMAIL PROTECTED]> wrote:
> Hi all,
> 
> If you're an ohci user can you please test this patch out for inclusion
> in 5.0.  I need to know that it doesn't break anything - the reports are
> that it fixes broken ohci :).

For what it's worth, it doesn't fix the umass(4) crashing issue. Anyone
wanna trade their uhci-based PCI USB adapter for an ohci based USB 2.0
adapter?

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

Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)

[Brian F. Feldman]

Brian Fundakowski Feldman <[EMAIL PROTECTED]> wrote:
> I can't get more info because crash dumps don't work when this happens, but 
> for what it's worth, here's a traceback which shows what happens when I 
> attempt to use my da0:  Removable Direct Access
> SCSI-2 device on an OHCI-based controller.  This was working just a few days 
> ago with a UHCI controller, so ...
> 
> The crash is from an invalid read at 0xbff3e000, which is PTmap plus some
> offset. The trace as far as I can get it, from a kernel with USB but no
> "options" 
> enabled, would be:
> 
> ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe)
> ohci_device_bulk_start+0x0d
> ohci_device_bulk_transfer+0x27
> usbd_transfer+0xc0
> umass_setup_transfer+0x4f
> umass_bbb_state
> usb_transfer_complete
> ohci_softintr
> 
> Can anyone confirm if this is normal or I have an exceptional system?  I 
> have two completely unrelated OHCI-based controllers in my system and 
> neither works.

Anyone?  I kinda want to use my CF reader.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: 5.0-RUSH: -current install testers wanted!

[Brian F. Feldman]

For what it's worth; I'm also using a dual-Athlon that gets spontaneous 
reboots once in a while and seems like it could possibly have to do with 
ACPI activating while the system is trying to cool itself down.  Do you have 
any more hints here on where the problem may lie so I can attempt to track 
it down?

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)

[Brian F. Feldman]

Josef Karthauser <[EMAIL PROTECTED]> wrote:
> Does this happen on a current with this patch applied too?

I'm certain I tried this already :(

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: SSE

[Brian F. Feldman]

German Tischler <[EMAIL PROTECTED]> wrote:
> Hi.
> 
> I can panic my current system compiled from sources of yesterday
> by just starting mozilla or ogg123  if I don't include
> options   CPU_DISABLE_SSE
> in my kernel configuration file. Is anyone else seeing any
> SSE code related problems ? (P III based SMP system here)

Yes; I seem to have this problem on my system whether or not SSE is enabled, 
though.  I've got a:

CPU: AMD Athlon(TM) XP 2000+ (1666.65-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x662  Stepping = 2
  
Features=0x383fbff
  AMD Features=0xc040

I'm trying to track it down, though.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: SSE

[Brian F. Feldman]

German Tischler <[EMAIL PROTECTED]> wrote:
> Hi.
> 
> I can panic my current system compiled from sources of yesterday
> by just starting mozilla or ogg123  if I don't include
> options   CPU_DISABLE_SSE
> in my kernel configuration file. Is anyone else seeing any
> SSE code related problems ? (P III based SMP system here)

Yes, I see the same problems with npxrestore() in sigreturn(), but on my 
Athlon it seems to occur with or without SSE.  I'm trying to track it down...

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: GEOM problems?

[Brian F. Feldman]

walt <[EMAIL PROTECTED]> wrote:
> Just finished making world and kernel at about 01:00 GMT Oct 6.
> 
> dmesg includes this printout:
> 
> Initializing GEOMetry subsystem
> ad0: 76319MB  [155061/16/63] at ata0-master UDMA100
> ad2: 42934MB  [87233/16/63] at ata1-master UDMA66
> acd0: CD-RW  at ata1-slave PIO4
> Mounting root from ufs:/dev/ad2s2a
>    00 01 c1 ff 83 fe ff ff 3f 00 00 00 06 5b 5f 00  |?[_.|
> [0] f:00 typ:131 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:6249222
>    00 00 c1 ff 05 fe ff ff 45 5b 5f 00 b3 f1 5a 00  |E[_...Z.|
> [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:6249285 l:5960115
>    00 01 c1 ff 07 fe ff ff 3f 00 00 00 74 f1 5a 00  |?...t.Z.|
> [0] f:00 typ:7 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:5960052
>    00 00 c1 ff 05 fe ff ff f8 4c ba 00 e2 05 18 00  |.L..|
> [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:12209400 l:1574370
> 
> 
> Is this normal output now?

Sounds like debugging prints that should probably not be enabled by 
default...

> And there's this:
> 
> #disklabel  ad0
> disklabel: ioctl DIOCGDINFO: Operation not supported by device
> 
> #disklabel -r  ad0
> disklabel: bad pack magic number (label is damaged, or pack is unlabeled)
> 
> Same errors with ad2.
> 
> All the partitions do mount and seem to work OK, so I'm not sure how
> much of this is expected behavior.

Are you using "dangerously-dedicated" disks?  That is, no fdisk-style 
partition table? If so, disklabel on ad0 or ad2 itself would be valid.  It 
doesn't appear you are, in which case a disklabel operation should be 
performed on the slice, e.g. disklabel ad2s2.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: SSE

[Brian F. Feldman]

"Brian F. Feldman" <[EMAIL PROTECTED]> wrote:
> German Tischler <[EMAIL PROTECTED]> wrote:
> > Hi.
> > 
> > I can panic my current system compiled from sources of yesterday
> > by just starting mozilla or ogg123  if I don't include
> > options CPU_DISABLE_SSE
> > in my kernel configuration file. Is anyone else seeing any
> > SSE code related problems ? (P III based SMP system here)
> 
> I seem to have the same problem on my currently-UP Athlon system, whether or 
> not SSE is enabled; I'm trying to track it down...

On further reflection, this DEFINITELY has to do with the work done on 
npx(4)/signals/etc. in the past week.  I _must_ be getting a GPF because the 
fpu state that it's attempting to restore is corrupt (i.e.: the control word 
is incorrect), so something is not being initialized somewhere that it used 
to be, or is being initialized incorrectly.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: panic from _mutex_assert in kern_lock.c

[Brian F. Feldman]

"Steven G. Kargl" <[EMAIL PROTECTED]> wrote:
> Brian F. Feldman said:
> > "Steven G. Kargl" <[EMAIL PROTECTED]> wrote:
> > > The source tree was retrieved by cvsup
> > > at 21:47 (PST) on Oct 4.
> > > 
> > > This is a non-GEOM and non-acpi kernel.
> > > 
> > > I have the core and kernel.debug, so any
> > > further postmortem is possible.
> > 
> > I think the problem is that in src/sys/ufs/ffs/
> > ffs_snapshot.c:ffs_snapshot(),
> > as the mnt vnode list is traversed none of the vnodes ("xvp") would actually GET
> > VI_LOCK()ed in the first place, and so the LK_INTERLOCK is bogus in the
> > vn_lock() call.  Kirk would know for sure what to do about this...
> > 
> 
> I came to the same conclusion after I sent the original email.
> 
> What I don't understand is how I ended up in ffs_snapshot(),
> because I don't have a snapshot of /var.  I tried snapshots
> when Kirk first introduced the feature, but I removed all
> of the snapshots a long time ago.  Is there a flag in the
> superblock that I need to clear?
> 
> One other point, the machine was doing a background fsck
> on /var.  Does a background fsck go through ffs_snapshot()?

Exactly: background fsck takes a snapshot to work on.  I think 
background_fsck="NO" is a good workaround at the moment for this.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: panic from _mutex_assert in kern_lock.c

[Brian F. Feldman]

"Steven G. Kargl" <[EMAIL PROTECTED]> wrote:
> The source tree was retrieved by cvsup
> at 21:47 (PST) on Oct 4.
> 
> This is a non-GEOM and non-acpi kernel.
> 
> I have the core and kernel.debug, so any
> further postmortem is possible.

I think the problem is that in src/sys/ufs/ffs/
ffs_snapshot.c:ffs_snapshot(),
as the mnt vnode list is traversed none of the vnodes ("xvp") would actually GET
VI_LOCK()ed in the first place, and so the LK_INTERLOCK is bogus in the
vn_lock() call.  Kirk would know for sure what to do about this...

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: SSE

[Brian F. Feldman]

German Tischler <[EMAIL PROTECTED]> wrote:
> Hi.
> 
> I can panic my current system compiled from sources of yesterday
> by just starting mozilla or ogg123  if I don't include
> options   CPU_DISABLE_SSE
> in my kernel configuration file. Is anyone else seeing any
> SSE code related problems ? (P III based SMP system here)

I seem to have the same problem on my currently-UP Athlon system, whether or 
not SSE is enabled; I'm trying to track it down...

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: Automagic Reboots

[Brian F. Feldman]

Sid Carter <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> This is so cool ;)
> 
> I just got rebooted again, :D
> 
> The "messages" show this.
> 
> ---
> Jun 25 18:06:30 calvin kernel: /usr/src/sys/vm/uma_core.c:1331: could
> sleep with "process lock" locked from /usr/src/sys/kern/kern_exec.c:321
> Jun 25 18:21:19 calvin syslogd: kernel boot file is /boot/kernel/kernel
> Jun 25 18:21:19 calvin kernel: Memory modified after free 0xc2cb9800(252)
> Jun 25 18:21:19 calvin kernel: panic: Most recently used by kqueue

I've actually seen this, too; not been able to track it down at all, though. 
At the moment, I've checked everywhere obviously M_KQUEUE memory is alloced 
and dealloced and have no good leads.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: Problems with Dell Inspiron 2500/NEWCARD/Xircom CBEM56G

[Brian F. Feldman]

"Scott Penno" <[EMAIL PROTECTED]> wrote:
> I removed apm from the kernel which appeared to be playing having with acpi
> and things are now working a treat.  The card works fine, however I do
> receive the following message, 'cardbus0:  (vendor=0x115d,
> dev=0x0103) at 0.1 irq 5'.  I've had a look through various lists and
> couldn't find a resolution.  Is this a real drama and if so, how do I
> correct it?

I believe that's the "modem" device on the card.  I don't believe that it is 
in fact a normal serial port in any case, so it's worth just ignoring in my 
opinion.  (Witness the address 0.1, where the Ethernet was probably found at 
0.0).  Sound about right?

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: cvs commit: src/sys/kern kern_mtxpool.c src/sys/sys kernel.h src/sys/vm vm_fault.c vm_glue.c vm_map.c vm_map.h vm_pageout.c vm_zone.c

[Brian F. Feldman]

Matthew Dillon <[EMAIL PROTECTED]> wrote:
> 
> :
> :Hi,
> :
> :Sorry to unwantedly butt in, but the patch supplied by Seigo actually
> :solved the vm_map.c locking problems which used to come up on my system.
> :Just some info. :)
> :
> :Regards,
> :
> :  -- Hiten Pandya
> :  -- <[EMAIL PROTECTED]>
> 
> It fixed some things, it broke some things.  Pretty much standard
> fare for anyone who has ever done work on the vm_map lock, including
> yours truely.  John Dyson couldn't get it right, David Greenman couldn't
> get it right, I couldn't get it completely right... getting it to do 
> the right thing even under -stable is difficult, which is why I am
> suggesting that it simply be made into an exclusive lock in -current.

In addition to the fact it doesn't actually serialize the general 
modification of the vm_map {} structure itself, just certain kinds of 
changes, so is easily a primary reason that the VM system as it stands now 
is inherently single-threaded.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: lomac

[Brian F. Feldman]

"Logan weaponx" <[EMAIL PROTECTED]> wrote:
> Is there a reason lomac_enable isn't in /etc/defaults/rc.conf? I've only had 
> a brief look so excuse this email if i'm in error and the answer is 
> glaringly obvious.

It's mostly that it still needs several features of the kernel which aren't 
currently there to be fully-functionalI don't think there would be any harm 
in adding it, though, and saying as much in /etc/defaults/rc.conf :)

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: USB detach crashes possibly fixed

[Brian F. Feldman]

Paul van der Zwan <[EMAIL PROTECTED]> wrote:
> > On 14-Feb-2002 (08:29:50/GMT) Brian Fundakowski Feldman wrote:
> > 
> > > Please try this change (already committed to -CURRENT) and let me
> > > know if crashes due to detaching USB devices specifically have been
> > > eliminated.
> > 
> > I cvsupped on Feb 14, 20:21 CET (GMT+1, Italian time), recompiled
> > both world & kernel (yes, runned mergemaster also :-) and messages
> > show that device attach and detach (before I got only attach)
> > 
> > ...kernel: uscanner0: EPSON Perfection1240, rev 1.00/1.14, addr 2
> > 
> > ...kernel: uscanner0: at uhub0 port 1 (addr 2) disconnected
> > ...kernel: uscanner0: detached
> > 
> > _BUT_
> > 
> > I lost /dev/speaker.  I don't know if this is related to patch but
> > with my previous installed build (a bit old, of December 11, 2001)
> > I have those lines on /etc/usbd.conf:
> > 
> > attach  "/bin/chmod 666 /dev/${DEVNAME} && echo L16cce > /dev/speaker"
> > detach  "echo L16eec > /dev/speaker"
> > 
> > and I got a small tune on attach but nothing on detach.
> > Now I am unable to play notes on /dev/speaker.  Any hint?

As Terry notes, shouldn't possibly be related.

> I have no crashes but the detach action is never executed when I switch off
> my Sony camera ( it has never worked as far as I know)
> Attach actions are executed fine..

Have you tried compiling in all available USB debugging support or seeing if 
anyone else is using one like yours?

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

Re: CD-ROM installation of -CURRENT broken?

[Brian F. Feldman]

Bruce Evans <[EMAIL PROTECTED]> wrote:
> On Wed, 19 Dec 2001, Brian Fundakowski Feldman wrote:
> 
> > Does anyone know when installation of -CURRENT from CD-ROM got broken or a
> > solution thereof?  We end up having two problems: the fixit shell doesn't
> > work, but before that an actual installation doesn't work because
> > sysinstall's attempt to mount /dev/acd0c on /dist returns ENOENT.  I havne't
> > determined yet why this could be; anyone have clues?
> 
> The 'c' partition of acd0 devices was broken for the non-DEVFS case in
> rev.104 of atapi-cd.c.  (The errno for this is ENXIO.)  DEVFS is not
> in GENERIC and "make release" doesn't seem to add it.

Well, really, all we should care about is the devfs case since anything else 
is meant to be deprecated; I'd rather fix this at the source...  DEVFS is no 
longer optional, so it is in GENERIC for certain.

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Motion for removal of xargs(1) from base system

[Brian F. Feldman]

"Brandon D. Valentine" <[EMAIL PROTECTED]> wrote:
> On Mon, 10 Dec 2001, Alfred Perlstein wrote:
> 
> >* Jackie 'business-first' Cook <[EMAIL PROTECTED]> [011210 16:19] wrote:
> >>
> >> As a replacement for the 'functionality' present in xargs(1), I propose
> >> implementing arbitrary length argument list passing right in the operating
> >> system.
> >
> >Nice proposal, where's the diff?
> 
> I'd like to preempt the ensuing bikeshed by voting for green.

I'd like to accept your nomination.  People, I know you won't regret 
choosing the right person for the job!

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: can't write CD-Rs with or without new DAO mode

[Brian F. Feldman]

Søren Schmidt <[EMAIL PROTECTED]> wrote:
> It seems Brian F. Feldman wrote:
> > > OK, try this patch (kernel & burncd need both to be remade)
> > 
> > I don't know... I got a page fault during an attempt to burncd and it seems 
> > there are no messages in dmesg but acd0's softc was freed.  I can't test any 
> > more because my CD-RW doesn't probe on boot (or let me eject, etc...)
> 
> Hmm, was that with the patch ?
> There is no reason why the device shouldn't probe anymore, but it could
> be in a state where are powercycle is needed to bring it back to
> sanity..

Yeah, that was with the patch.  Since it didn't actually change any logic 
related to freeing the softc, I don't know why it happened...

It's most likely not the drivers fault I'm certain.  Power cycles, reboots, 
leaving the machine off for a few minutes, etc. do not help.  My CD-RW seems 
to randomly go catatonic nowadays.

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: can't write CD-Rs with or without new DAO mode

[Brian F. Feldman]

Søren Schmidt <[EMAIL PROTECTED]> wrote:
> It seems Brian F. Feldman wrote:
> > Søren Schmidt <[EMAIL PROTECTED]> wrote:
> > > It seems Brian Fundakowski Feldman wrote:
> > > > After updating my system I can't burn CD-Rs successfully.  Can anyone else?  
> > > > What happens is pretty simple:
> > > > 
> > > > {"/home/green/toxicity"}$ burncd -s 8 -d audio /dev/null $(ls | trackclassify >
> > > > burncd: ioctl(CDRIOCINITWRITER): Input/output error
> > > > acd0: MODE_SELECT_BIG - ILLEGAL REQUEST asc=0x26 ascq=0x00 error=0x00
> > > 
> > > Are you absolutely sure your kernel & userland are in sync ?
> > recompiling burncd to the exact same effect.
> 
> OK, try this patch (kernel & burncd need both to be remade)

I don't know... I got a page fault during an attempt to burncd and it seems 
there are no messages in dmesg but acd0's softc was freed.  I can't test any 
more because my CD-RW doesn't probe on boot (or let me eject, etc...)

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: can't write CD-Rs with or without new DAO mode

[Brian F. Feldman]

Søren Schmidt <[EMAIL PROTECTED]> wrote:
> It seems Brian Fundakowski Feldman wrote:
> > After updating my system I can't burn CD-Rs successfully.  Can anyone else?  
> > What happens is pretty simple:
> > 
> > {"/home/green/toxicity"}$ burncd -s 8 -d audio /dev/null $(ls | trackclassify >
> > burncd: ioctl(CDRIOCINITWRITER): Input/output error
> > acd0: MODE_SELECT_BIG - ILLEGAL REQUEST asc=0x26 ascq=0x00 error=0x00
> 
> Are you absolutely sure your kernel & userland are in sync ?

Yes, I am.  I just built a new kernel, did a make includes, and tried 
recompiling burncd to the exact same effect.

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: symlink(2) [Was: Re: tcsh.cat]

[Brian F. Feldman]

Bruce Evans <[EMAIL PROTECTED]> wrote:
> On Fri, 31 Aug 2001, Brian F. Feldman wrote:
> 
> > Bruce Evans <[EMAIL PROTECTED]> wrote:
> > > Here's an example of a standard utility being clueless about symlinks to
> > > nothing:
> > >
> > > $ ln -s '' foo
> > > $ cp foo bar
> > > cp: foo is a directory (not copied)
> > >
> > > foo is certainly not a directory.  The bug seems to be in fts.
> >
> > No, "foo" certainly _is_ a directory.  It is precisely the same thing as
> > ".".
> 
> No, the empty pathname has been invalid and not an alias for "." since at
> least the first version of POSIX.

I didn't read the rest of the thread til later ;)  The fact remains that 
FreeBSD interprets it as such in namei(), and is it not an undefined 
behavior according to POSIX?

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: symlink(2) [Was: Re: tcsh.cat]

[Brian F. Feldman]

Bruce Evans <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Jun 2001, Steve O'Hara-Smith wrote:
> 
> > On Fri, 15 Jun 2001 06:31:12 -0700 (PDT)
> > David Wolfskill <[EMAIL PROTECTED]> wrote:
> > 
> > DW> Indeed: it is my understanding that the "path name" interpretation is
> > DW> an issue at the time of reference, not (necessarily) the time of
> > DW> creation.  It has, to the best of my knowledge, been valid to create a
> > DW> symlink prior to a point when its target exists.
> > 
> > It has been on evey platform I have ever used ln -s on.
> > 
> > DW> One may well argue that this is "broken" in some way(s).  Still, changing
> > DW> it at this point could well be considered  a POLA violation, at best.
> > 
> > I would argue loud and long that changing that *would* be broken. There
> > is never a guarantee (or even an implication) that a symlink points to a
> > valid directory entry (think unmounted filesystems, NFS ...). I find it hard
> > to imagine why creation time should be special in that regard.
> 
> We are (or at least I am) talking about changing it to prevent links to a
> string that can _never_ be a valid pathname.  Fortunately, in POSIX there
> is only one such string (the empty string).
> 
> Here's an example of a standard utility being clueless about symlinks to
> nothing:
> 
> $ ln -s '' foo
> $ cp foo bar
> cp: foo is a directory (not copied)
> 
> foo is certainly not a directory.  The bug seems to be in fts.

No, "foo" certainly _is_ a directory.  It is precisely the same thing as 
".".

> cp is also broken for symlinks to valid pathnames for nonexistent files;
> 
> $ rm -f foo
> $ ln -s /nonesuch foo
> $ cp foo bar
> 
> This duplicates foo as a symlink, but should just fail.
> 
> Bruce

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Can we please remove "green@FreeBSD.org" from the version string?

[Brian F. Feldman]

Wilko Bulte <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 08, 2001 at 09:01:36AM -0700, David O'Brien wrote:
> > On Wed, Aug 08, 2001 at 04:51:55PM +0200, Alexander Langer wrote:
> > > Thus spake David O'Brien ([EMAIL PROTECTED]):
> > > 
> > > Looking at the first two lines, shouldn't it be
> > > 
> > > >  #define SSH_VERSION(ssh_version_get())
> > > >  #define SSH_VERSION_BASE   "OpenSSH_2.9"
> > > > -#defineSSH_VERSION_ADDENDUM"[EMAIL PROTECTED] 20010608"
> > > > +#define SSH_VERSION_ADDENDUM   "FreeBSD 20010608"
> > > 
> > > anyways? :-)
> > 
> > *sigh*  Can we please comment on the content?
> 
> Sounds like a good idea to change this.

Seeing as it's directed people to the right maintainer because of it, so 
far...  It's not "portable" OpenSSH, and it's not "OpenSSH running on 
FreeBSD", so either we need to have a completely new name for it (FreeBSDSSH 
or something), or something that is otherwise descriptive to differentiate 
it.  It's far removed from being "plain" OpenSSH or "portable" OpenSSH.

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: quick informal survey: OpenSSH broken?

[Brian F. Feldman]

"David O'Brien" <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 29, 2001 at 09:53:09PM -0400, Brian Fundakowski Feldman wrote:
> > I need to know, if OpenSSH is ever going to get MFC'ed, are there any people 
> > currently running OpenSSH 2.9 from -CURRENT's base and getting major 
> > problems with it?  Or even minor ones that actually make things more 
> 
> You've never responded to requests from people asking what it would take
> to make things fall back to v1 gracefully.  We all know it is a "feature"
> that with a default configuration, it will try ssh2 first and if it is
> not able to authenticate (say you have no .ssh/authorized_keys2 file) the
> connection can fail.

I don't mean to disappoint, but I don't think it will be possible to fall 
back without creating modifications on both sides (both renogotiation of 
connection on the server side and client side, because the protocols are 
inherently different).

For what it's worth, I tend to simply set "Protocol 1,2" in my .ssh/config 
and for the default case, it works fine (just like it used to).  I don't 
want to make that policy decision, though, because we will be better off 
when everyone moves to the protocol version 2, so it's reasonable for the 
default to make things "difficult" to encourage the switch.  I support the 
OpenSSH developers' plan here.

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: cvs commit: src UPDATING

[Brian F. Feldman]

Brian Somers <[EMAIL PROTECTED]> wrote:
> > In message  Michael Reifenberger 
>writes:
> > : Have you tried to start aviplay ( coming from ports/graphics/avifile ) or using
> > : whine?
> > 
> > Nope.
> 
> vmware does the job too, and I believe star-office.

I've noticed it, and after backing out locally the commits recently made to 
"lock" LDT access, things work (at least, as well as they used to).  I 
didn't do this hastily;  I spent hours looking at what could possibly be 
wrong with the new locking added, and couldn't find anything :(  I know that 
sched_lock is being held too long, which means (I think) that either somehow 
the code is sleeping with it held or just not releasing it at all.


-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

evil ATA

[Brian F. Feldman]

Welp, this is the n-dozenth time that the ATA driver has wedged large parts 
of my entire system because it feels it needs to reset my CD-R when I'm 
trying to start burning a CD.  I get the good old

acd0: WRITE_BIG command timeout - resetting
ata3: resetting devices .. 

and then, like always, tons of random applications lock up thereafter, 
including the burncd (stuck in physstr and cannot be killed, at all), Window 
Maker, my panel, etc. etc. etc.  Oh, and the sleep(2)-related system calls 
don't sleep for the right time anymore; they just freeze.  All sorts of 
stuff like this.

Is there _any_ hope for not having such horrible behavior?  Am I at the very 
least not the only person to have seen it?  This is the _only_ problem I've 
had with -current lockups this entire year.

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: PROCTREE_LOCK() vs. gdb hang

[Brian F. Feldman]

User Sja <[EMAIL PROTECTED]> wrote:
> I don't really know my way around the kernel so I'm just guessing here:
> 
> Is there a proctree lock release operation missing in kern_sig.c,
> function issignal()?  There seems to be one lock operation more
> than there are release operations.  I tried putting one in and
> now gdb doesn't hang the whole machine (at least as easily as
> before.)

I think you've really found the problem!  Your analysis and fix seems to be 
correct, and it wouldn't affect "normal" operations, only those when a 
process is being traced.  I'll test it out right now to make sure it works, 
and Paul can commit it if he also thinks it is correct.

> #kern (sja@tilli) 112> cvs diff -u kern_sig.c
> Index: kern_sig.c
> ===
> RCS file: /usr/cvs/src/sys/kern/kern_sig.c,v
> retrieving revision 1.98
> diff -u -r1.98 kern_sig.c
> --- kern_sig.c  2000/12/23 19:43:09 1.98
> +++ kern_sig.c  2000/12/31 16:01:45
> @@ -1311,6 +1311,7 @@
> PROCTREE_LOCK(PT_SHARED);
> } while (!trace_req(p)
>  && p->p_flag & P_TRACED);
> +   PROCTREE_LOCK(PT_RELEASE);
>  
> /*
>  * If the traced bit got turned off, go back up
> 
> 
> ++sja



-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'




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

Re: write(2) returns error saying read only filesystem when trying to write to a partition

[Brian F. Feldman]

Bruce Evans <[EMAIL PROTECTED]> wrote:
> On Fri, 8 Dec 2000, Matthew Thyer wrote:
> 
> > Mike Smith wrote:
> > > > The program works on Compaq True64 UNIX v 4.0d
> > > > It also works on Solaris 7 (only tested sparc).
> > > >
> > > > So it seems FreeBSD is broken here.
> > > 
> > > FreeBSD just behaves differently.  If you want to write to the whole
> > > disk, open the whole-disk device, not the 'c' partition.
> > 
> > Thanks Mike, /dev/da18 works fine for me although I notice that
> > /dev/da18s1 does not.  There seems to be some inconcistencies
> > in this area.
> > 
> > Please tell me (and for the benefit of the list) as to why
> > I cant use /dev/da18s1c ?
> 
> Because metadata (i.e,. label) write protection actually works on
> /dev/da18s1c.
> 
> It is supposed to be possible to turn off write protection using the
> DIOCWLABEL ioctl, but IIRC this only works if the data written over
> the label area is a valid label (if there is already a label there,
> as there must be for /dev/da18s1c to exist), so labels can't be
> cleared by writing zeros to them (zeros don't give a valid label).
> 
> Labels can be cleared by zeroing them using the whole-disk device.
> All subdevices of the device should be closed before starting, and none
> except the whole-disk device should be opened before finishing, to
> ensure that the old in-core copy of the label isn't used.
> 
> Someone broke dd(1) to always turn off write protection of labels, to
> hack around a bug in the alpha disklabel code (someone broke the label
> for the whole-disk device by making it a real label to hack around a
> non-understood bug that is said to break sysinstall; real labels are
> write protected, so the whole-disk device can't be used to bypass the
> write protection).  Since overwriting labels doesn't work quite right
> even when write protection is turned off, I'm not sure how the breakage
> helps.

O'Brien said that it was totally necessary to be able to do it.  If it's the 
hack that the alpha users need, it's not really my place to try to analyze 
the how and why of alpha breakage to determine whether it's proper or not if 
I have no alpha systems.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'




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

OpenSSH 2.3.0 pre-upgrade

[Brian F. Feldman]

(Please direct followups to [EMAIL PROTECTED] and remove all
extraneous addresses.  I'm cross-posting in hopes of reaching the
right audiences that won't necessarily overlap.)

It's time again for an upgrade to our FreeBSD OpenSSH.  Version 2.3.0 was 
released a few weeks back, and working off that I've produced a set of diffs 
from either what's in the tree now or the original OpenBSD, 2.3.0 sources.

What's new in this release?  Mostly the adding of the AES (Rijndael) to the 
SSH2 algorithms.  Is anything now broken?  Well, nothing new broken that I 
know of; there was an issue of the canonical host name not being used, which 
I could have sworn it was before: in either case, it is used now.  The auth 
loops previously did not take NULL struct passwd * arguments, but now they 
do (to inform them to fake authorization).  This deprecated our fake auth 
loop, but gave me a lot of work to correct the logic in the code that 
expects non-NULL pw's.  I think I did it all, but wouldn't be surprised if 
there's still a mistake, so I'd really appreciate others looking at it.

There's some weird issue where for the Diffie-Hellman exchange, OpenSSH 
wants primes but doesn't seem to want to generate them... it expects an
/etc/ssh/primes (which should become /var/run/ssh_primes, if anything) and I 
have no clue where the program is that supposedly generates them.  So, for 
SSH2, the authentication stage generates a large warning and uses a 
hardcoded prime.  This should not actually have an affect on security, 
though, according to my understanding of the Diffie-Hellman protocol.

I probably fixed a ton of smaller bugs on the way I've all but forgotten 
about now.  I'd appreciate anyone who can either test this out to see if it 
works for them (I upgraded all my OpenSSH stuff to 2.3.0, and it is working 
great) or review the changes.  If I've made some mistakes in the code I've 
changed, it could easily be a huge security issue, so it would be really 
nice to have others back me up on the changes made.

The patch to apply on a -CURRENT/-STABLE FreeBSD system's src tree to update 
to this version can be found at:
http://green.bikeshed.org/OpenSSH-2.3.0.patch.gz

Similarly, the diffs from plain OpenBSD OpenSSH 2.3.0 to ours are at:
http://green.bikeshed.org/OpenSSH_to_FreeBSD-2.3.0.patch.gz

Thanks!

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'




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

Re: Problem with dlopen()/dlsym() after recent crt* changes

[Brian F. Feldman]

John Polstra <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, Alexander N. Kabaev
> <[EMAIL PROTECTED]> wrote:
> 
> >   Why FreeBSD does not link libgcc into shared libraries by
> > default? Everyone else is doing that. Linking shared libraries
> > with libgcc seems to be the ultimate work-around. Are there any
> > compatibility problems which are keeping FreeBSD from doing that?
> 
> None that I'm aware of.  I agree we should do it.  I'll talk to
> David O'Brien and find out whether he has any objections.

Do it, do it!  The jdk 1.2.2 (FreeBSD) port broke in the predictable way (no 
exception-handling functions) until I had the libraries linked with 
-lgcc_pic.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'




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

weird crash with a corrupt lock (?)

[Brian F. Feldman]

With nothing special going on (I think maybe a tar xfvz of the jdk 1.2.2 
source), my system crashed inexplicably.  I have no idea why a lock would 
look like this does, no clue whether I should be replacing my hardware or 
the system is just getting more and more unstable.


(kgdb) p *lkp
$1 = {
  lk_interlock = {
lock_data = 0x0
  }, 
  lk_flags = 0x, 
  lk_sharecount = 0x10001, 
  lk_waitcount = 0x, 
  lk_exclusivecount = 0x, 
  lk_prio = 0x, 
  lk_wmesg = 0x10001 , 
  lk_timo = 0x, 
  lk_lockholder = 0x0
}
(kgdb) bt
#0  dumpsys () at ../../kern/kern_shutdown.c:461
#1  0xc016873f in boot (howto=0x100) at ../../kern/kern_shutdown.c:302
#2  0xc0168ae1 in panic (fmt=0xc02696c0 "lockmgr: pid %d, not %s %d unlocking") at 
../../kern/kern_shutdown.c:550
#3  0xc0163280 in lockmgr (lkp=0xc0f12000, flags=0x6, interlkp=0xd048fdec, 
p=0xd05f7ac0) at ../../kern/kern_lock.c:382
#4  0xc0198cef in vop_stdunlock (ap=0xd0606b40) at ../../kern/vfs_default.c:250
#5  0xc02149c9 in ufs_vnoperate (ap=0xd0606b40) at ../../ufs/ufs/ufs_vnops.c:2263
#6  0xc019bfbe in vclean (vp=0xd048fd80, flags=0x8, p=0xd05f7ac0) at vnode_if.h:865
#7  0xc019c153 in vgonel (vp=0xd048fd80, p=0xd05f7ac0) at ../../kern/vfs_subr.c:1864
#8  0xc019a8e1 in getnewvnode (tag=VT_UFS, mp=0xc0d1c200, vops=0xc0cbc700, 
vpp=0xd0606be8) at ../../kern/vfs_subr.c:510
#9  0xc020ccff in ffs_vget (mp=0xc0d1c200, ino=0x49f56, vpp=0xd0606c34) at 
../../ufs/ffs/ffs_vfsops.c:1049
#10 0xc01ff5bb in ffs_valloc (pvp=0xd03ccd40, mode=0x8124, cred=0xc15eea80, 
vpp=0xd0606c34)
at ../../ufs/ffs/ffs_alloc.c:604
#11 0xc021480f in ufs_makeinode (mode=0x8124, dvp=0xd03ccd40, vpp=0xd0606e80, 
cnp=0xd0606e94)
at ../../ufs/ufs/ufs_vnops.c:2057
#12 0xc021222c in ufs_create (ap=0xd0606d94) at ../../ufs/ufs/ufs_vnops.c:186
#13 0xc02149c9 in ufs_vnoperate (ap=0xd0606d94) at ../../ufs/ufs/ufs_vnops.c:2263
#14 0xc01a29bb in vn_open (ndp=0xd0606e6c, flagp=0xd0606e38, cmode=0x124) at 
vnode_if.h:106
#15 0xc019e5c1 in open (p=0xd05f7ac0, uap=0xd0606f80) at ../../kern/vfs_syscalls.c:1037
#16 0xc024f1dd in syscall2 (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 
0x80b4f3f, tf_esi = 0x1d, 
  tf_ebp = 0xbfbff858, tf_isp = 0xd0606fd4, tf_ebx = 0x60d, tf_edx = 0x1d, tf_ecx 
= 0xffe0, tf_eax = 0x5, 
  tf_trapno = 0x7, tf_err = 0x2, tf_eip = 0x808099c, tf_cs = 0x1f, tf_eflags = 
0x202, tf_esp = 0xbfbff6ec, 
  tf_ss = 0x2f}) at ../../i386/i386/trap.c:1150
#17 0xc0243185 in Xint0x80_syscall ()
#18 0x80509f9 in ?? ()
#19 0x8052c5a in ?? ()
#20 0x8048139 in ?? ()


--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'




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

Re: very high CPU time demand from process #10 ('idle')

[Brian F. Feldman]

attila! <[EMAIL PROTECTED]> wrote:

>   What is process 10? Is this literally a representation of
>   the CPU idle time accumulation for the 85 hours since
>   boot?

Yes.

>   Despite the enormous time burn on 'idle' it does not show
>   on 'top'.

That's probably because top(1) hides stuff from you by default.   Try using 
top -S.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'




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

Re: Today -current broken on build

[Brian F. Feldman]

Mike Smith <[EMAIL PROTECTED]> wrote:
> > > I hate to spoil the moment ... but does anyone have an idea what the
> > > fix is?  Nothing in the amd directory seems to have changed in the
> > > past couple of weeks, so it must be somewhere else, and I'm not bright
> > > enough to figure out where.
> > 
> > Yeah, somebody forgot that typedefs and structure names can't
> > conflict. :)  I've just committed the fix.
> 
> Er, this is probably the wrong fix.  It sounds like the kernel 'callout' 
> structure is ending up visible in userland, which it shouldn't.

Thing is, I for one can't figure out what just changed.  I've been manually 
following all the ways sys/callout.h would be included, and none seem to 
apply here.  For example, sys/systm.h isn't included in any way I can tell 
by this amd file, and sys/callout.h isn't explicitly either.  This is really 
annoying.

So, sys/callout.h should be in #ifdef _KERNEL #endif /* _KERNEL */, but I 
just can't find out what broke it in the first place so I didn't want to fix 
anything.  It would be nice to have the system Mozilla uses for this where 
we can pinpoint automatically what commit broke things.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'




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

Re: sendmail related changes

[Brian F. Feldman]

Gregory Neil Shapiro <[EMAIL PROTECTED]> wrote:
> There are some sendmail related changes I would like to make in the next
> few days.  Some may be controversial so I am sending out this mail first.
> I would appreciate feedback on any of these items.  If I don't hear any
> major objections, I'll go ahead with the changes.
> []

Without reservation, I'd say each one of these is a great idea!  Just 
registering my support, especially for installing the cf tree.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'




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

Re: breakage in libgcc?

[Brian F. Feldman]

On Sat, 9 Oct 1999, Mike Smith wrote:

> > just cvsupped
> 
> Your system; I just finished a world not five minutes ago.  Suspect the
> usual.
> 

Suspect that you need a newer kernel before you can build the world.

> > *** Signal 12
> > 
> > Stop in /usr/src/gnu/lib/libgcc.
> > *** Error code 1
> > 

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: maxphys = 0??

[Brian F. Feldman]

On Sat, 9 Oct 1999, Poul-Henning Kamp wrote:

> Well, there are two options, either your sources are not up to date,
> or your config is very special in some way...

I am absolutely certain that my sources are up-to-date.  I'll attach my
kernel config in case you can find something special there.

> 
> --
> Poul-Henning Kamp FreeBSD coreteam member
> [EMAIL PROTECTED]   "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!
> 

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'


#
# GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks
#
# For more information read the handbook part System Administration -> 
# Configuring the FreeBSD Kernel -> The Configuration File. 
# The handbook is available in /usr/share/doc/handbook or online as
# latest version from the FreeBSD World Wide Web server 
# http://www.FreeBSD.ORG/>
#
# An exhaustive list of options and more detailed explanations of the 
# device lines is present in the ./LINT configuration file. If you are 
# in doubt as to the purpose or necessity of a line, check first in LINT.
#
#   $Id: GENERIC,v 1.102 1998/01/11 02:16:38 jkh Exp $

machine i386
cpu I586_CPU
ident   GREEN   
maxusers64
makeoptions DEBUG="-g"

#optionsMATH_EMULATE  #Support for x87 emulation
options INET#InterNETworking
options IPX
options NETATALK
options FFS #Berkeley Fast Filesystem
options FFS_ROOT
options CD9660  #ISO 9660 Filesystem
options COMPAT_43   #Compatible with BSD 4.3 [KEEP THIS!]
options UCONSOLE#Allow users to grab the console
options USERCONFIG  #boot -c editor
options VISUAL_USERCONFIG   #visual boot -c editor
options NO_F00F_HACK
options IPFIREWALL
options IPFIREWALL_FORWARD  #enable xparent proxy support
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100
options IPDIVERT
options IPSTEALTH
#optionsIPFILTER
options DUMMYNET
options DDB
options DDB_UNATTENDED
options SOFTUPDATES
options PQ_HUGECACHE   # color for 1024k cache
options ICMP_BANDLIM  
options MSGBUF_SIZE=16384
options INVARIANTS
options INVARIANT_SUPPORT
options CLK_USE_TSC_CALIBRATION

#optionsICMP_BANDLIM_SILENT
options CPU_WT_ALLOC
options NO_MEMORY_HOLE
options MAXFILES=65536

controller  pci0at nexus?
controller  isa0at nexus?
controller  pnp0

# Luigi's snd code.
# You may also wish to enable the pnp controller with this, for pnp
# sound cards.
#
#device pcm0 at isa? port 0x220 irq 5 drq 1 #flags 0x16

controller  snd0
device sb0  at isa? port 0x220 irq 5 drq 1
device sbxvi0   at isa? drq 6 
device sbmidi0  at isa? port 0x330
device opl0 at isa? port 0x388
device  joy0at isa? port IO_GAME

#controller fdc0at isa? port IO_FD1 irq 6 drq 2
#disk   fd0 at fdc0 drive 0
#disk   fd1 at fdc0 drive 1

# for a PCI only system (most modern machines)
controller  ata0
device  atadisk0# ATA disks
device  atapicd0# ATAPI CDROM's
device  atapist0# ATAPI tapes
device  atapifd0

controller  ncr0
controller  scbus0  #base SCSI code
device  ch0 #SCSI media changers
device  da0 #SCSI direct access devices (aka disks)
device  sa0 #SCSI tapes
device  cd0 #SCSI CD-ROMs
device  pass0   #CAM passthrough driver
device pt0 at scbus?# SCSI processor type
options SCSI_DELAY=5000 # Be pessimistic about Joe SCSI device

# The keyboard controller; it controlls the keyboard and the PS/2 mouse.
controller  atkbdc0 at isa? port IO_KBD

# The AT keyboard
device  atkbd0  at atkbdc? irq 1

# PS/2 mouse
device  psm0at atkbdc? irq 12

# The video card driver.
device  vga0at isa? port ? conflicts

# The syscons console driver (sco color console compatible).
device  sc0 at isa?

device  npx0at nexus? port IO_NPX irq 13

#
# Laptop support (see LINT for more options)
#
#device apm0at nexus? conflicts # Advanced Power Management

# System Management Bus!

controller smbus0
controller alpm0
device smb0 at smbus?

device  sio0at isa? port IO_COM1 flags 0x10 irq 4
device  sio1at isa? port IO_COM2 irq 3
device  sio2at isa? disable port IO_COM3 irq 5
device  sio3at isa? disable port IO_COM4 irq 3

controller  ppbus0
device  lpt0   at ppbus?
device 

Re: maxphys = 0??

[Brian F. Feldman]

On Tue, 5 Oct 1999, Daniel C. Sobral wrote:

> Poul-Henning Kamp wrote:
> > 
> > You need to move your sources further forward.
> 
> Alas, it didn't help. What versions of what files I should have? The
> warnings are still appearing, at fsck time.
> 

Alas, similarly I get:
changing root device to wd0s1a
WARNING: #ad/0x20007 maxphys = 0 ??WARNING: #ad/0x20006 maxphys = 0 ??WARNING: 
#ad/0x20004 maxphys = 0 ??WARNING: #ad/0x20005 maxphys = 0 ??WARNING: #ad/2 maxphys = 
0 ??

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Testers please!

[Brian F. Feldman]

On Tue, 21 Sep 1999, Luoqi Chen wrote:

> This reminds me about the usage of TSC counter on SMP. First even though
> we don't use TSC for time keeping on SMP, the TSC frequency from calibration
> is still valid (at least for BSP), and we can show it in the cpu identification
> message. Second, the listed reason for not using TSC on SMP is the inability
> to synchronize TSCs on all cpus. My question is, is it really necessary?
> TSC is initialized to 0 at hardware reset, which should happen to all CPUs
> at the same time (invalid assumption?), in another words, all TSCs should be
> automatically synchronized.

ISTRT something I did long ago was kill the TSC reset FreeBSD did, so
there should be no reason that they won't be all at the same place.  I
am willing to bet half my farm that the biggest problem was that we
did that, and barring that we could have always done SMP using the TSC.

One question comes to mind: is there a way that the TSCs could become
desynchronized somehow?  Even though all CPUs run at the same frequency,
isn't there a strong possibility for slight frequency deviation since
we use crystal oscillation instead of a more accurate atomic breakdown
for regulation, or am I just smoking crack?

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

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: make buildworld failed...

[Brian F. Feldman]

On Fri, 27 Aug 1999, Adam Wight wrote:

> > > dd if=/dev/zero of=boot2.ldr bs=512 count=1 2>/dev/null
> > > *** Error code 1
> 
> > Probably it consequences of recent dd changes...

Sorry about that! Instead of relying on the kernel being newer than the world
and haveing the new ioctl FIODTYPE, dd now only warns if the ioctl doesn't
work.

> 
> So I'm not entirely alone, then.  I actually kernel panic quite reliably every
> time I try to dd onto a floppy.  I can dd from one file to another without
> a problem, and floppy access in general works as always.
> 
> What debugging information would be relevant?

That sounds like it could have just been fixed by phk. If it's not that and
is the writing past the end of a block device issue, use the character
device instead.

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

-- 
 Brian Fundakowski Feldman   /  "Any sufficiently advanced bug is\
 [EMAIL PROTECTED]   |   indistinguishable from a feature."  |
 FreeBSD: The Power to Serve!\-- Rich Kulawiec   /



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

Re: Softupdates reliability?

[Brian F. Feldman]

On Tue, 24 Aug 1999, Richard Tobin wrote:

> > >   Origin = "AuthenticAMD"  Id = 0x580  Stepping=0
> 
> > You have one of the first K6-2s off the line. There were definite problems
> > with these, and as such, they were specially distinguished by having 66
> > printed on top.
> 
> I have a 0x580 which has had no problems at all.  I'm pretty certain
> it doesn't have 66 stamped on it.  Are they all supposed to have this,
> or were they tested and the dodgy ones stamped 66?

It must be the latter. My 0x580 had the 66, so it must be that the dodgy
ones got labelled 66 and not all the 0x580s were defective.

> 
> -- Richard
> 

-- 
 Brian Fundakowski Feldman   /  "Any sufficiently advanced bug is\
 [EMAIL PROTECTED]   |   indistinguishable from a feature."  |
 FreeBSD: The Power to Serve!\-- Rich Kulawiec   /



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

Re: Softupdates reliability?

[Brian F. Feldman]

On Tue, 24 Aug 1999, Stephen McKay wrote:

> 
> Oh, and Brian wanted to know the processor revision.  I don't know of any
> problems with K6-2/300s, but here's the info:
> 
> CPU: AMD-K6(tm) 3D processor (300.68-MHz 586-class CPU)
>   Origin = "AuthenticAMD"  Id = 0x580  Stepping=0
>   Features=0x8001bf

You have one of the first K6-2s off the line. There were definite problems
with these, and as such, they were specially distinguished by having 66
printed on top.

What is your FSB running at? These chips (the very early 300s) can not
handle >66MHz, and I've had a K6-2 0x580 go _completely_ bad easily.
For peace of mind, even if it's not the problem (which it very well could
be), I'd upgrade to a later revision. You can get one of these relatively
cheap:

CPU: AMD-K6(tm) 3D processor (350.81-MHz 586-class CPU)
  Origin = "AuthenticAMD"  Id = 0x58c  Stepping = 12
  Features=0x8021bf
  AMD Features=0x8800


> 
> Stephen
> 

-- 
 Brian Fundakowski Feldman   /  "Any sufficiently advanced bug is\
 [EMAIL PROTECTED]   |   indistinguishable from a feature."  |
 FreeBSD: The Power to Serve!\-- Rich Kulawiec   /



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

Re: Softupdates reliability?

[Brian F. Feldman]

What revision of the K6-2 did this happen on?

-- 
 Brian Fundakowski Feldman   /  "Any sufficiently advanced bug is\
 [EMAIL PROTECTED]   |   indistinguishable from a feature."  |
 FreeBSD: The Power to Serve!\-- Rich Kulawiec   /



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

Re: Q: Extending the sysctl MIB for Linuxulator variables

[Brian F. Feldman]

On Mon, 16 Aug 1999, Jordan K. Hubbard wrote:

> I kinda like the idea of a top-level compat category; it will keep the
> top level uncluttered when sysv and iBCS compatibility start requiring
> their own knobs, and if you put linux at the top level this will later
> be used as justification for putting all the other "compat" stuff up
> there too.  I think it's a slippery slope.
> 
> - Jordan
> 

This is the most convincing argument so far. It's got my vote. One
caveat: let's _please_ not use capitalization in the MIB tree as
much as possible. Just like the ports, it makes things easier on
everyone if we use lower-case (compat.linux, compat.ibcs2,
compat.svr4.)

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: cd writer recommendation?

[Brian F. Feldman]

On Mon, 16 Aug 1999, Jordan K. Hubbard wrote:

> > Wormcontrol uses WORM ioctls, handled by both of the ATAPI drivers.
> 
> Utterly irrelevant, not that you seem to let it stop you.

You bringing up worm(4) was entirely irrelevant. You implied that wormcontrol
does not work because the worm old-SCSI driver is gone. Wormcontrol is
simply a utility that allows you to issue WORM ioctls to a device. See
/usr/src/share/examples/atapi (yes, in -CURRENT too) for exactly how
wrong you are about wormcontrol "not working."

> 
> > But ATA and wcd are both not CAM. dd works just fine. You can solve data
> 
> See above.  dd's unsuitableness for writing CDs has nothing whatsoever
> to do with CAM.

Yes, why would it? I simply used your paragraph style: make one statement,
then another that is completely unrelated. Oh wait, you mean your writing
style utilizing the exact same strategy was _correct_? Give me a break.
Your holier-than-thou attitude is getting old, especially when you use
things that are entirely unrelated to try to back up the point your never
even had.

> 
> > Your points are arguments to a different set of statements ;)
> 
> Nope.  As usual, you're simply trying to argue your way out of being
> wrong.  Sorry, but being right just isn't the same as being forceful.
> Perhaps you'll learn that for yourself, given enough time. :)

You didn't even reply anything close to what he wanted, and now you're
accusing me of the same? What crawled up your pants and died, leaving
you chafed and miserable? You see, when you answer someone, try to
answer what they asked and they'll appreciate it.

> 
> - Jordan
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: cd writer recommendation?

[Brian F. Feldman]

On Mon, 16 Aug 1999, Jordan K. Hubbard wrote:

> > Mkisofs is good for creating an ISO 9660 file systems. Wormcontrol and
> > dd are a good combination for writing them.
> 
> This would be true if the worm driver wasn't actually dead.  You
> should at least check on these things before publically recommending
> obsolete mechanisms. :)

Wormcontrol uses WORM ioctls, handled by both of the ATAPI drivers.

> 
> In the world of CAM these days, cdrecord from the ports collection is
> the way to go.  "dd" was also never a good way of writing CDs since the
> faster models may suffer from data starvation when you use dd, you
> want to use cdrecord and/or team from the ports collection to do this.

But ATA and wcd are both not CAM. dd works just fine. You can solve data
starvation by using a pipe of two (one to do all the reading, another to
do all the writing with the small buffer size.) cdrecord is probably
more obvious to most people.

> 
> And yes, I've burned probably thousands of CDs under FreeBSD at this
> point and do know what I'm talking about, should Brian wish to
> vigorously defend the indefensible again on these points. :-)

Your points are arguments to a different set of statements ;)

> 
> - Jordan
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: cd writer recommendation?

[Brian F. Feldman]

On Mon, 16 Aug 1999, Amancio Hasty wrote:

> 
> Sorry about that . The emphasis is more on the hardware and second is the 
> software -- I usually get around problems with the software.
> 

Mkisofs is good for creating an ISO 9660 file systems. Wormcontrol and
dd are a good combination for writing them.

> Is there any support for IDE CD writers or are they not worth bothering with 
> on FreeBSD.
> 

Yes, there is support for them :)

>   Tnks!
> 
> > On Sun, 15 Aug 1999, Amancio Hasty wrote:
> > 
> > > 
> > > Any one care to recommend a CD writer for FreeBSD-current since thats
> > > typically what I run over here.
> > 
> > Are you asking for recommendation about hardware or software? It's not
> > evident from your wording.
> > 
> > > 
> > >   Tnks
> > > -- 
> > > 
> > >  Amancio Hasty
> > >  [EMAIL PROTECTED]
> > 
> >  Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
> >  [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
> >  FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
> >http://www.FreeBSD.org/  _ |___/___/___/ 
> > 
> 
> -- 
> 
>  Amancio Hasty
>  [EMAIL PROTECTED]
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: cd writer recommendation?

[Brian F. Feldman]

On Sun, 15 Aug 1999, Amancio Hasty wrote:

> 
> Any one care to recommend a CD writer for FreeBSD-current since thats
> typically what I run over here.

Are you asking for recommendation about hardware or software? It's not
evident from your wording.

> 
>   Tnks
> -- 
> 
>  Amancio Hasty
>  [EMAIL PROTECTED]

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Q: Extending the sysctl MIB for Linuxulator variables

[Brian F. Feldman]

On Sun, 15 Aug 1999, Warner Losh wrote:

> In message <[EMAIL PROTECTED]> "Brian F. 
>Feldman" writes:
> : I suppose, but wouldn't the proper place be under machdep? I agree that
> : a linux top-level MIB would be easiest to remember.
> 
> Linux isn't machdep.  It is MI since we could have Linux/Alpha or
> Linux/MIPS emulators...

Well then, we need to move it a directory level and take out machine
dependencies, and make it machine independent.

> 
> Warner
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: pex5 and xie load errors

[Brian F. Feldman]

On Sun, 15 Aug 1999, Narvi wrote:

> 
> On Sat, 14 Aug 1999, Randy Bush wrote:
> 
> > during X startup i get load errors for these.  but i can see nothing unappy
> > with X.  do i
> >   delete them from /etc/XF86Config
> > or
> >   rebuild X
> > or
> >   what?
> > 
> 
> Rebuilding X won't help last I tried. They have been broken for quite some
> time now. Seems there aren't enough people who care enough.

Well, by "they" I hope you don't intend to mean modules in general. I am
happily using my Riva TNT with XFree86 3.3.3.1, which is a module (the GLX):

Section "Module"
 Load "glx.so"
EndSection

(**) stands for supplied, (--) stands for probed/default values
(--) no ModulePath specified using default: /usr/X11R6/lib/modules
GLX extension module for XFree86 3.3.3.1 -- Mesa version 3.0
GLX package version 0.9, GLX protocol version 1.2.
(**) module glx.so successfully loaded from /usr/X11R6/lib/modules

So what are the specific errors you get?

> > randy
> > 
> 
>   Sander
> 
>   There is no love, no good, no happiness and no future -
>   all these are just illusions.

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Q: Extending the sysctl MIB for Linuxulator variables

[Brian F. Feldman]

On Sun, 15 Aug 1999, Poul-Henning Kamp wrote:

> >The question is simply were in the MIB to put them?
>...
> >3) under "linux"
> 
> I vote for 3.

I suppose, but wouldn't the proper place be under machdep? I agree that
a linux top-level MIB would be easiest to remember.

> 
> --
> Poul-Henning Kamp FreeBSD coreteam member
> [EMAIL PROTECTED]   "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: it's time...

[Brian F. Feldman]

On Wed, 11 Aug 1999, Warner Losh wrote:

> 
> No!  At some point they should use a facility similar to solaris/sysv
> where they don't display, but do make it into the dmesg buffer...
> 
> Warner
> 

What in the world would be the point of doing this? What would be so great
about not seeing the system boot up?

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: it's time...

[Brian F. Feldman]

On Tue, 10 Aug 1999, Daniel O'Connor wrote:

> 
> On 10-Aug-99 Brian F. Feldman wrote:
> > > Sure.. but you still have window of time where the audio is at its default
> > > level before the rc stuff is run..
> >  Why... would audio be playing from rc? Bear in mind, it would be set
> >  even before rc.local...
> 
> I have a radio connected to line in on my sound card.

Then that would be playing during the entire bootup, wouldn't it? What,
does it play only after the card has been detected?

> 
> ---
> Daniel O'Connor software and network engineer
> for Genesis Software - http://www.gsoft.com.au
> "The nice thing about standards is that there
> are so many of them to choose from."
>   -- Andrew Tanenbaum
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: it's time...

[Brian F. Feldman]

On Mon, 9 Aug 1999, Alex Zepeda wrote:

> One could stuff it into rc.conf, but this means it's harder to
> automagically save the state upon shutdown/reboot.  But something like:

Not really. You could do it with grep, awk, sed, or whatever you want,
easily. The only possible problem would be... Getting it actually run
at shutdown.

> 
> deviceX_mixerdevice_vol = yy
> 
> might work, and allow for multiple sound card.

It's at http://janus.syracuse.net/~green/rc.audio.patch, not vapor :)

> 
> - alex
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: it's time...

[Brian F. Feldman]

On Tue, 10 Aug 1999, Daniel O'Connor wrote:

> 
> On 09-Aug-99 Brian F. Feldman wrote:
> >  You guys don't see the point. The point is a single, simple place to put
> >  default mixer values for any number of devices, and fitting in with the
> >  current configuration file scenario. rc is the natural place for this,
> >  because _it_ gets run at startup. I just need to find somewhere to put
> >  this instead of rc.audio, because jkh vetoes it on that account...
> 
> Sure.. but you still have window of time where the audio is at its default
> level before the rc stuff is run..

Why... would audio be playing from rc? Bear in mind, it would be set
even before rc.local...

> 
> ---
> Daniel O'Connor software and network engineer
> for Genesis Software - http://www.gsoft.com.au
> "The nice thing about standards is that there
> are so many of them to choose from."
>   -- Andrew Tanenbaum
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: it's time...

[Brian F. Feldman]

You guys don't see the point. The point is a single, simple place to put
default mixer values for any number of devices, and fitting in with the
current configuration file scenario. rc is the natural place for this,
because _it_ gets run at startup. I just need to find somewhere to put
this instead of rc.audio, because jkh vetoes it on that account...

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: it's time...

[Brian F. Feldman]

On Sun, 8 Aug 1999, Kenneth Wayne Culver wrote:

> It works ok for me, but one nice feature of the sound system would be if
> upon shutdown (I don't leave my machine on all the time right now) OS
> somehow looked at a config file (call it /etc/soundvol.conf) for mixer
> volumes, and set them to that as a default... Just an idea.

Don't you mean upon startup? If so, see my recent rc proposition for mixer
settings.

> 
> KEnneth Culver
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Assembler capable of supporting 3dnow!

[Brian F. Feldman]

On Sun, 1 Aug 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:

> I'm messing around with the latest mesa and have discovered (suprise)that our 
> assembler doesn't support 3dnow instructions. Are there any plans to update to 
> a version of binutils that does? Linux's stuff appears to support it.
> 

According to dfr, no, since the releases are in "beta" now or something.
I think it's worth updating. And no, it would be too hard to get 3DNow!
wihtouut updating gas. However: you can use the linux_devutils gcc/as/ld
etc. to build the parts of whatever you need with 3dnow instructions.

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

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: MTRR stuff

[Brian F. Feldman]

On Fri, 30 Jul 1999, Mike Smith wrote:

> > For some video cards (to wit, the voodoo stuff), the MTRRs should be set up as 
> > follows
> > 
> >write-combining
> >  +--+ 
> >  +---+
> >   uncacheable
> > 
> > i.e. the two regions have the same starting area, but the small chunk for the 
> > registers should be uncacheable. When I try to do this using memconf on my 
> > K6-2, it spits the dummy. Is there a work around for this?
> 
> The i686 MTRR implementation, at least, doesn't allow UC to overlap WC; 
> only Write-back and uncached are allowed to overlap.  I don't know what 
> the K6's limitations are; you should talk to Brian Feldman about that.

As long as a range isn't exactly the same (base, len being the same), it
allows the change. The question is how does it fail? I let the hardware
decide what to actually do with the registers, but I write them, so...
I need to know where the problem is.

> 
> -- 
> \\  The mind's the standard   \\  Mike Smith
> \\  of the man.   \\  [EMAIL PROTECTED]
> \\-- Joseph Merrick   \\  [EMAIL PROTECTED]
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: readdirplus client side fix (was Re: IRIX 6.5.4 NFS v3 TCP client+ FreeBSD server = bewm)

[Brian F. Feldman]

Is there any good documentation on the vnode system? I'd like to know, for
instance, what the deal is with v{hold,drop}.

Originally, I was most interested in doing things with networking. VFS
seems so interesting now... Perhaps I should wait before experimenting
with it until the rewrite of lots of it later this year?

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: readdirplus client side fix (was Re: IRIX 6.5.4 NFS v3 TCP client+ FreeBSD server = bewm)

[Brian F. Feldman]

On Thu, 29 Jul 1999, Bill Paul wrote:

> > Ok, I was able to reproduce the above bug and fix it.  The problem on
> > the FreeBSD client is in nfs_readdirplusrpc() in nfs/nfs_vnops.c.  It 
> > can obtain the vnode being used to populate the additional directory 
> > info in one of two ways.  When it gets the vnode via nfs_nget(), the
> > returned vnode is locked.  When it gets it via a hit against NFS_CMPFH()
> > (which I presume is for '.'), it simply VREF()'s the vnode.
> > 
> > In the one case the vnode is returned locked, in the other it is not.
> > 
> > However, the internal loop vrele()'s the vnode rather then vput()'s it,
> > so the vnodes in the directory scan are never unlocked.  This leads to
> > the lockup.
> 
> Uh, yeah.
> 
> One of these days I'll be able to understand everything that you just
> said. But not today.

It's not hard. vput() VOP_UNLOCK()s a vnode and then vrele() (opposite of
vref())'s it (decreases v_usecount, I believe.) So when a file system
is mounted, with these bugs, the locked vnodes are never unlocked. 
The unmount call will end up sleeping with the state "vnlock" waiting for
the operation that has the vnode in question vref()d to vrele() and
let go of it.

At least, that's how it looks to me, but I never really looked at vnode
code until today.

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Extra characters?y

[Brian F. Feldman]

On Wed, 28 Jul 1999, Scott Michel wrote:

> At line 71 in i386/isa/clock.c, there is the following:
> 
> #include 
> #include 
> XXX
> #ifdef APIC_IO
> #include 
> #endif
> 
> 
> I'd say, and this is only a SWAG mind you, that the 'XXX' is
> extraneous. Right?

It just appeared in version 1.141 (msmith) when APM was completely
removed from clock.c. I'm guessing it was an accident, because
it probably broke your build, didn't it?

I committed a fix.

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

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: MAKEDEV (or sh?) broken

[Brian F. Feldman]

Actually, all recursive executions of it need to be -x too. The easiest
way (if there's no environment variable for it, I don't recall), is to
put "set -x" at the top of MAKEDEV.

This will help, and then I'll understand much more. Thanks. I have
a feeling it might be improper optimization breaking expr...

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: MAKEDEV (or sh?) broken

[Brian F. Feldman]

Isolate a specific case of MAKEDEV (not just all) that will demonstrate this,
sh -x it, and send it to me. Failing that, set -x and do ./MAKEDEV all, and
send me this output. That's where we need to go next to try to find out what
is wrong.

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: MAKEDEV (or sh?) broken

[Brian F. Feldman]

On Tue, 27 Jul 1999, Maxim Sobolev wrote:

> On my CURRENT system cvsup'ed and builded yesterday when I'm trying to
> do "cd /dev; sh MAKEDEV all" I see following errors:

Did you somehow replace Bourne with BASH? Check.

> 
> Script started on Tue Jul 27 13:14:47 1999
> sh-2.03# cd /dev ; sh MAKEDEV all
> ...
> Script done on Tue Jul 27 13:16:57 1999
> 
> -Maxim
> --
> "We believe in the Power and the Might!"
> (Manowar, 1996)
> 
> Maxim V. Sobolev, Financial Analyst,
> Vega International Capital
> Phone: +380-(44)-246-6396
> Fax: +380-(44)-220-8715
> E-mail: [EMAIL PROTECTED]
> ICQ: #42290709
> 
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Still kernel compilation failures

[Brian F. Feldman]

On Fri, 23 Jul 1999, Bruce Evans wrote:

> >> > Put -O back in the COPTFLAGS.
> >> 
> >> It works now. Is there any explaination why -O is required? :)
> >
> >Noone compiles without -O, so(/and) it's not supported. My take is
> 
> It is supported, but someone broke it.

Since when? Every so often someone comes along (from a pool of maybe 5
people who _don't_ use -O) and complains about it being broken. If
anyone developing it actually used it, it wouldn't be broken. As it
stands, there's no good reason not to have -O.

> 
> >that EGCS says "Hey, I am in optimization level foobar! I can optimize
> >for unused code. Hmm... that's unused, so...". Either that or its
> >debugging support is really uNFed up.
> 
> -O works because optimisation removes an unused reference to a nonexistent
> variable.  The variable once existed and was used.  It still exists under
> a different name.

So I was right (in my way that totally denies any type of actual understanding
;)?  You're the one to have delved deep into GCC :)

> 
> Bruce
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Still kernel compilation failures

[Brian F. Feldman]

On Fri, 23 Jul 1999, Thomas Schuerger wrote:

> > > ...
> > > vfs_init.o: In function `vfs_register':
> > > vfs_init.o(.text+0x8a1): undefined reference to `sysctl(void, float, short)'
> > > *** Error code 1
> > > 1 error
> > > Exit 2
> > > 
> > > 
> > > What am I doing wrong? Any help is greatly appreciated.
> > > 
> > 
> > Put -O back in the COPTFLAGS.
> 
> It works now. Is there any explaination why -O is required? :)

Noone compiles without -O, so(/and) it's not supported. My take is
that EGCS says "Hey, I am in optimization level foobar! I can optimize
for unused code. Hmm... that's unused, so...". Either that or its
debugging support is really uNFed up.

> 
> 
> Ciao,
> Thomas.
> 
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Still kernel compilation failures

[Brian F. Feldman]

On Thu, 22 Jul 1999, Thomas Schuerger wrote:

> Hi!
> 
> I updated the source tree, built and installed the world today
> and tried to make a new kernel. Compilation stops when it
> comes to linking:
> 
> ...
> vfs_init.o: In function `vfs_register':
> vfs_init.o(.text+0x8a1): undefined reference to `sysctl(void, float, short)'
> *** Error code 1
> 1 error
> Exit 2
> 
> 
> What am I doing wrong? Any help is greatly appreciated.
> 

Put -O back in the COPTFLAGS.

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

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Panics on my SMP system

[Brian F. Feldman]

On Tue, 20 Jul 1999, Matthew Dillon wrote:

> 
> How old is your -CURRENT source tree ?Fixes to the pipe code
> have been made, though they are not 100% complete.
> 
> If your -CURRENT source tree is more then a few days old I recommend
> updating it.  A number of significant reliability fixes have gone in,
> including fixes to the pipe code and fixes to certain atomic operations 
> that weren't atomic. 

What's happing with regard to your pipe write locking fixes? I still
apply those to my kernels...

> 
>   -Matt

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: is dumpon/savecore broken?

[Brian F. Feldman]

On Tue, 20 Jul 1999, Poul-Henning Kamp wrote:

> >Should I commit a similar workaround for the swap code too? Quite
> >simple to do...
> 
> Please so, but I would appreciate if you would do me the favour of
> hiding the guts of this monstrosity in kern/kern_conf.c in a function
> called dev2budev() ?

I did so. I'm working out why this did not fix pstat now...

> 
> --
> Poul-Henning Kamp FreeBSD coreteam member
> [EMAIL PROTECTED]   "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: is dumpon/savecore broken?

[Brian F. Feldman]

On Tue, 20 Jul 1999, Poul-Henning Kamp wrote:

> In message <[EMAIL PROTECTED]>, "Bria
> n F. Feldman" writes:
> 
> >>/ddname = find_dev/s/BLK/CHR/
> >
> >No, that's wrong. You cannot do buffered-type IO on a cdev. I committed
> >a workaround, and now it works. There's no easy way around this, except
> >possibly making kern.dumpdev a string (makes quite a bit of sense there...)
> 
> Indeed.  a dev_t should never be exported as such from the kernel
> anymore, in particular not for bdevs.  dumps and swap are the two
> offenders left.

Should I commit a similar workaround for the swap code too? Quite
simple to do...


> 
> --
> Poul-Henning Kamp FreeBSD coreteam member
> [EMAIL PROTECTED]   "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: is dumpon/savecore broken?

[Brian F. Feldman]

On Tue, 20 Jul 1999, Poul-Henning Kamp wrote:

> In message <[EMAIL PROTECTED]>, "Steven G. Kar
> gl" writes:
> >
> >During the boot process I see
> 
> >   dumpon: crash dumps to /dev/da0s1b (4, 131073)
> >   checking for core dump...savecore: can't find device 13/131073
> 
> >It seems that the the major device number is reset from 4 to 13.
> 
> >troutmask:kargl[225] swapinfo
> >Device  1K-blocks UsedAvail Capacity  Type
> >/dev/#B13:0x200015118720   511872 0%Interleaved
> 
> Yes, all dev_t's which make it out of the kernel have cmajor
> numbers now.
> 
> Try this change to savecore:
> 
>   /ddname = find_dev/s/BLK/CHR/

No, that's wrong. You cannot do buffered-type IO on a cdev. I committed
a workaround, and now it works. There's no easy way around this, except
possibly making kern.dumpdev a string (makes quite a bit of sense there...)

> 
> 
> --
> Poul-Henning Kamp FreeBSD coreteam member
> [EMAIL PROTECTED]   "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Question about MTRR boot message

[Brian F. Feldman]

On Mon, 19 Jul 1999, Mike Smith wrote:

> > I wrote the K6-2 MTRR support, but I really don't know how to use it.
> > You see, my X server reports:
> > (--) SVGA: PCI: NVidia Riva TNT rev 4, Memory @ 0xef00, 0xcc00
> > But which do I make uncacheable?
> 
> You don't; let the X server do it.

You didn't teach XFree86 to do our MTRR stuff yet, IIRC, did you?

> 
> -- 
> \\  The mind's the standard   \\  Mike Smith
> \\  of the man.   \\  [EMAIL PROTECTED]
> \\-- Joseph Merrick   \\  [EMAIL PROTECTED]
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Question about MTRR boot message

[Brian F. Feldman]

On Mon, 19 Jul 1999, Jason wrote:

> Before you go any further worrying about this "just in case", there is
> nothing for you to worry about. Part of what the MTRR "stuff" does is it
> stops the L2 cache from cacheing that range of memory. This is typicaly used
> for video cards, as you have been told, because well, you really never read
> back from the video card's memory frame buffer, and if you did, for some
> strange reason, it would only result in a cache miss and would then have to
> be fetched from main memory. Since your L2 cache isn't wasting space on this
> area of memory, it can cache something more usefull, and thus give you a
> speed *increase*.
> 

I wrote the K6-2 MTRR support, but I really don't know how to use it.
You see, my X server reports:
(--) SVGA: PCI: NVidia Riva TNT rev 4, Memory @ 0xef00, 0xcc00
But which do I make uncacheable?

> 
> Thus, MTRR is GOOD.
> 
> - Jason
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: panic: zone: entry in free

[Brian F. Feldman]

On Thu, 15 Jul 1999, Luoqi Chen wrote:

> > I realise that will stop the panic from looking at the source code, but
> > surely it's just covering up the problem and waiting for it to happen
> > later?
> >
> I'm pretty it's caused by the INVARIANTS option, similar incidents have been
> reported many times before. The problem with INVARIANTS is that 1. it alters
> data structures, 2. kernel modules don't know about this option, so you
> have inconsistent kernel and modules. There're three solutions,
> 
> 1, make INVARIANTS less intrusive. So far only vm_zone code is causing
> problems, I suggest we rename the option to INVARIANTS_ZONE in this part
> of code (the code should be pretty much bug free by now).
> 
> 2, compile modules with the option. The easiest way is probably add
> -DINVARIANTS in your /etc/make.conf, you have to remember to take it
> out when you remove the option from your config file.

I apply the following to freshly checked-out sources:
--- src/sys/modules/Makefile.inc.orig   Fri Oct 16 00:31:35 1998
+++ src/sys/modules/Makefile.incSun Mar 14 23:03:02 1999
@@ -1,3 +1,8 @@
 # $Id: Makefile.inc,v 1.1 1998/10/16 04:31:35 peter Exp $
 
 KLDMOD=true
+CFLAGS+= -DINVARIANTS
+NTUN=4
+PPP_FILTER=1
+VM86=1
+CFLAGS+= -g


> 
> 3, do not use INVARIANTS if you don't need it. :)
> 
> -lq
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: LOCK overheads (was Re: "objtrm" problem probably found)

[Brian F. Feldman]

On Tue, 13 Jul 1999, Matthew Dillon wrote:

> 
> :Here's another data point:
> :{"/home/green"}$ cc -O2 locktests.c -o locktests
> :{"/home/green"}$ ./locktests
> :mode 0   10.92 ns/loop nproc=1 lcks=EMPTY
> :mode 1   17.99 ns/loop nproc=1 lcks=no
> :mode 2   17.97 ns/loop nproc=2 lcks=no
> :mode 3  166.33 ns/loop nproc=1 lcks=yes
> :mode 4  167.91 ns/loop nproc=2 lcks=yes
> :mode 5   42.16 ns/loop nproc=1 lcks=no
> :mode 6   41.60 ns/loop nproc=2 lcks=no
> :mode 7  188.86 ns/loop nproc=1 lcks=yes
> :mode 8  191.56 ns/loop nproc=2 lcks=yes
> :
> :This is a K6-2 350. Locks are pretty expensive on them.
> :
> : Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
> 
> Wow, now that *is* expensive!  The K6 must be implementing it in
> microcode for it to be that bad.

Sometimes you wonder what they're doing with that RISC86 translation.
I have a feeling it's overhead for the OpenPIC implementation, really.

> 
>   -Matt
>   Matthew Dillon 
>   <[EMAIL PROTECTED]>
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: LOCK overheads (was Re: "objtrm" problem probably found)

[Brian F. Feldman]

Here's another data point:
{"/home/green"}$ cc -O2 locktests.c -o locktests
{"/home/green"}$ ./locktests
mode 0   10.92 ns/loop nproc=1 lcks=EMPTY
mode 1   17.99 ns/loop nproc=1 lcks=no
mode 2   17.97 ns/loop nproc=2 lcks=no
mode 3  166.33 ns/loop nproc=1 lcks=yes
mode 4  167.91 ns/loop nproc=2 lcks=yes
mode 5   42.16 ns/loop nproc=1 lcks=no
mode 6   41.60 ns/loop nproc=2 lcks=no
mode 7  188.86 ns/loop nproc=1 lcks=yes
mode 8  191.56 ns/loop nproc=2 lcks=yes

This is a K6-2 350. Locks are pretty expensive on them.

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Using float emulator on a system with FPU?

[Brian F. Feldman]

On Tue, 13 Jul 1999, Peter Jeremy wrote:

> Doug Rabson <[EMAIL PROTECTED]> wrote:
> >You might consider looking at the fp emulator which I wrote for the alpha.
> >It should be accurate (I tested against the fpu on an x86) and contains
> >test harness code which can be used to play with it on both x86 and alpha.
> 
> Anyone interested in working on FP emulation (or checking the
> shortcuts DEC made when then designed the Alpha) might like to
> check out :

fetch: ucbtest.tar.gz: www.netlib.org: HTTP server returned error code 404
Where's it really at?

> 
>  UCBTEST is a suite of programs for testing certain difficult cases of
> IEEE 754 floating-point arithmetic.  Some of the difficult test cases are
> obtained from number-theoretic algorithms developed by Turing Award winner
> Prof. W. Kahan, Department of Electrical Engineering and Computer Science,
> University of California, Berkeley, as part of ongoing research into test
> methods for computer arithmetic.
> 
> Peter
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: MTRR stuff

[Brian F. Feldman]

On Mon, 12 Jul 1999, Mike Smith wrote:

> >  
> > > What exactly are the ranges? You haven't given me enough info yet. I wrote the
> > > K6-* MTRR driver, so I'd like to help.
> > > 
> > OK, the Linux 3dfx driver attempts to set up a write combining range starting 
> > at the card's base address and 0x40 bytes long. After doing this it then 
> > sets up a range marked as uncacheable starting at the card's base address of 
> > length  0x1000.
> 
> The current i686 MTRR driver doesn't allow overlapping ranges at all; 
> this is a defect in its implementation that will be rectified when I 
> get to work on it next (hopefully in the next week or so).

The current K6 MTRR driver does, but I need more information on exactly
what's wrong. If it's returning EINVAL, what EXACTLY did he pass it?
Stephen, you're not giving enough information.

> 
> -- 
> \\  The mind's the standard   \\  Mike Smith
> \\  of the man.   \\  [EMAIL PROTECTED]
> \\-- Joseph Merrick   \\  [EMAIL PROTECTED]
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Using float emulator on a system with FPU?

[Brian F. Feldman]

On Mon, 12 Jul 1999, Alex Zepeda wrote:

> On Mon, 12 Jul 1999, Brian F. Feldman wrote:
> 
> > Why shouldn't we? Noone uses machines without FPUs anymore. What
> > non-ancient CPU doesn't have an FPU? And we're talking about the i386
> > family here...
> 
> I've noticed recently, more and more, Linux is moving into the embedded
> market quite nicely, and being used on smaller and smaller systems.
> FreeBSD OTOH has been focusing (albeit not too successfully) on the higher
> end market.
> 
> With my recent addition of an 040 powered Mac that I plan to put NetBSD
> on, this really irks me.  I'd love to put some (read: a significant)
> amount of time getting FreeBSD up and running on this, but there seems to
> be a lot of resistance to using FreeBSD on smaller/older machines. It
> almost seems like the requirement is Pentium III, Alpha or bust.
> 
> And yes, this machine does have an FPU, but there are plenty of *newer*
> systems without FPUs For instance, doesn't the StrongArm lack an FPU? What
> about embedded systems?  A 486SX would draw a whole lot less power than a
> Pentium.  And it's certainly not like emulating an FPU is an impossible
> task like say on some LC040s...

Compare the 486SX to a 486DX, not a pentium.

> 
> - alex
> 
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Using float emulator on a system with FPU?

[Brian F. Feldman]

On Mon, 12 Jul 1999, Garrett Wollman wrote:

> < said:
> 
> > I'm going to work on FreeBSD's floating point support, but I need to
> > test my changes on systems using the FPU emulators (non-GPL and GPL). 
> 
> I suggested about half a year ago that we should officially desupport
> non-FPU configurations in 4.0.  Unfortunately, my resolution was
> soundly defeated.

Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient
CPU doesn't have an FPU? And we're talking about the i386 family here...

> 
> -GAWollman
> 
> --
> Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
> [EMAIL PROTECTED]  | O Siem / The fires of freedom 
> Opinions not those of| Dance in the burning flame
> MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: MTRR stuff

[Brian F. Feldman]

On Fri, 9 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:

> 
> > 
> > Spits the dummy? And do you mean memcontrol?
> 
> It (memcontrol, I was typing the name from memory at work) complains. I was 
> trying to set up the MTRRs like the Linux voodoo device driver does. I hadn't 
> thought of doing it the way you suggest, as the documentation says that the 
> size has to be a power of 2.

What exactly are the ranges? You haven't given me enough info yet. I wrote the
K6-* MTRR driver, so I'd like to help.

> 
> > I have no idea what you mean by that. However, the natural thing to do would
> > be this:
> > +---+ write-combine uncacheable
> >  +--+ uncacheable
> > 
> 
> -- 
>   The views expressed above are not those of PGS Tensor.
> 
> "We've heard that a million monkeys at a million keyboards could produce
>  the Complete Works of Shakespeare; now, thanks to the Internet, we know
>  this is not true."Robert Wilensky, University of California
> 
> 
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: MTRR stuff

[Brian F. Feldman]

On Fri, 9 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:

> For some video cards (to wit, the voodoo stuff), the MTRRs should be set up as 
> follows
> 
>write-combining
>  +--+ 
>  +---+
>   uncacheable
> 
> i.e. the two regions have the same starting area, but the small chunk for the 
> registers should be uncacheable. When I try to do this using memconf on my 
> K6-2, it spits the dummy. Is there a work around for this?

Spits the dummy? And do you mean memcontrol?
I have no idea what you mean by that. However, the natural thing to do would
be this:
+---+ write-combine uncacheable
 +--+ uncacheable

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

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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

Re: Stuck in "objtrm"

[Brian F. Feldman]

On Tue, 6 Jul 1999, Andrew Gallatin wrote:

> 
> 
> I've occasionally seen systems wedged in a similar state.  I reported
> my sighting of this on May 24th.  Haven't seen it since.
> 
> The one bit of useful info I've learned since my report was that from
> a talk with the program's author, I suspect the object in question may
> have been created with mmap(MAP_ANON,...).  I'm not sure if cc1 also
> does this, but that may be some common ground..

For what it's worth, our RTLD and malloc() both use mmap(,,,MAP_ANON,,);.

> 
> 
> Stephen McKay writes:
>  > 
>  > The high points:
>  > ref_count=0
>  > shadow_count=0
>  > type=1 (OBJT_SWAP)
>  > paging_in_progress=1
>  > resident_page_count=9
>  > flags=0x21c8 (onemapping, mightbedirty, writeable, pipwnt, dead)
>  > 
> 
> <...>
> 
> Similar to mine:
> 
> $5 = {
>   object_list = {
> tqe_next = 0xca234244, 
> tqe_prev = 0xca2ee488
>   }, 
>   shadow_head = {
> tqh_first = 0x0, 
> tqh_last = 0xca1e7a00
>   }, 
>   shadow_list = {
> tqe_next = 0x0, 
> tqe_prev = 0xca29c24c
>   }, 
>   memq = {
> tqh_first = 0xc04ff370, 
> tqh_last = 0xc04e65fc
>   }, 
>   generation = 26962387, 
>   type = OBJT_SWAP, 
>   size = 165, 
>   ref_count = 0, 
>   shadow_count = 0, 
>   pg_color = 60, 
>   hash_rand = -71709939, 
>   flags = 8652, 
>   paging_in_progress = 1, 
>   behavior = 0, 
>   resident_page_count = 51, 
>   cache_count = 0, 
>   wire_count = 0, 
>   backing_object = 0x0, 
>   backing_object_offset = 0, 
>   last_read = 63, 
>   pager_object_list = {
> tqe_next = 0xca234244, 
> tqe_prev = 0xca175970
>   }, 
>   handle = 0x0, 
>   un_pager = {
> vnp = {
>   vnp_size = 5
> }, 
> devp = {
>   devp_pglist = {
> tqh_first = 0x5, 
> tqh_last = 0x0
>   }
> }, 
> swp = {
>   swp_bcount = 5
> }
>   }
> }
> 
> 
>  > 
>  > Who was watching what code changed recently?  Remember I had this problem
>  > on a kernel from 1999/06/16 too.  So it's an "old" problem.
>  > 
>  > Off to research the next installment...
>  > 
>  > Stephen.
>  > 
>  > PS  I haven't worked out yet how to find the stack of the errant process.
>  > Any hints?  The stack trace should be helpful.
> 
> Yes.  say 'proc pidhashtbl[PID & pidhash]->lh_first' in kgdb.
> I suspect that it will be in exit() also..
> 
> 
> (kgdb) proc pidhashtbl[22207 & pidhash]->lh_first
> (kgdb) bt
> #0  mi_switch () at ../../kern/kern_synch.c:827
> #1  0xc0152cd9 in tsleep (ident=0xca1e79f8, priority=4, 
> wmesg=0xc024bbca "objtrm", timo=0) at ../../kern/kern_synch.c:443
> #2  0xc01f6249 in vm_object_terminate (object=0xca1e79f8)
> at ../../vm/vm_object.h:235
> #3  0xc01f61f9 in vm_object_deallocate (object=0xca1e79f8)
> at ../../vm/vm_object.c:384
> #4  0xc01f3ae7 in vm_map_entry_delete (map=0xca1c0380, entry=0xca2b65f0)
> at ../../vm/vm_map.c:1887
> #5  0xc01f3ca5 in vm_map_delete (map=0xca1c0380, start=0, end=3217022976)
> at ../../vm/vm_map.c:1990
> #6  0xc01f3d29 in vm_map_remove (map=0xca1c0380, start=0, end=3217022976)
> at ../../vm/vm_map.c:2015
> #7  0xc014a615 in exit1 (p=0xca2465a0, rv=0) at ../../kern/kern_exit.c:223
> #8  0xc014a434 in exit1 (p=0xca2465a0, rv=-904133760)
> at ../../kern/kern_exit.c:106
> #9  0xc0210dd6 in syscall (frame={tf_fs = 135004207, tf_es = 1209466927, 
>   tf_ds = -1078001617, tf_edi = 0, tf_esi = -1, tf_ebp = -1077947172, 
>   tf_isp = -903335964, tf_ebx = 1209464980, tf_edx = 0, tf_ecx = 0, 
>   tf_eax = 1, tf_trapno = 7, tf_err = 2, tf_eip = 1209204908, tf_cs = 31, 
>   tf_eflags = 582, tf_esp = -1077947196, tf_ss = 47})
> at ../../i386/i386/trap.c:1069
> #10 0xc0206aa0 in Xint0x80_syscall ()
> 
> 
> Drew
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



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