FreeBSD 8.1 regression in x86bios.c

[Craig Boston]

Hi all,

My laptop (Toshiba Portege R100) stopped working with an early boot hang 
at some point between 8.0 and 8.1. After it broke last year I had ended 
up just reverting to an earlier kernel, but finally found the time to do 
a binary search and narrow it down.


The offending commit is:
http://svn.freebsd.org/viewvc/base?view=revision&revision=205647 



Fix stupid typos.  Some VESA BIOSes directly call BIOS interrupt handlers
within the VBE interrupt handler.  Unfortunately it was causing real mode
page faults because we were fetching instructions from bogus addresses.
Pass me the pointyhat, please.

PR: kern/144654
MFC after:  3 days

With this commit in place, the system hangs almost immediately on boot, 
right after probing kdbmux. With debug.x86bios.{call,int} enabled from 
the loader, the final lines before the hang are:


avail memory = 1299705856 (1239 MB)
kbd1 at kbdmux0
Calling int 0x10 (ax=0x4f00 bx=0x cx=0x dx=0x es=0x9e00 
di=0x)
Exiting int 0x10 (ax=0x004f bx=0x cx=0x dx=0x es=0x9e00 
di=0x)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0144 dx=0x es=0x0200 
di=0x)


Then a hard hang. With the 2 lines in x86bios.c reverted, the system 
boots fine (even on a fresh 8.2 build with just that commit backed out). 
The debug output from a successful boot looks like this:


kbd1 at kbdmux0
Calling int 0x10 (ax=0x4f00 bx=0x cx=0x dx=0x es=0x9e00 
di=0x)
Exiting int 0x10 (ax=0x004f bx=0x cx=0x dx=0x es=0x9e00 
di=0x)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0144 dx=0x es=0x0200 
di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x2065 cx=0x9e32 dx=0x1023 es=0x0200 
di=0x0028)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0143 dx=0x es=0x9c00 
di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x1065 cx=0x9e32 dx=0x1023 es=0x9c00 
di=0x0028)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0141 dx=0x es=0x0200 
di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x0865 cx=0x9e32 dx=0x1023 es=0x0200 
di=0x0028)

(many more lines)

In any event, I'm not sure if this is a true bug, or just a broken BIOS, 
but either way I thought you might want to know about it.


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

Re: Sysinstall replacement

[Craig Boston]

On Mon, Jun 04, 2007 at 12:36:15AM +0200, Ivan Voras wrote:
> See http://wiki.freebsd.org/finstall .

Somewhat tangental, the only thing that really jumps out at me is this:

> I propose the UFS+gjournal be the default FS type (even for
> root+boot?)

I think this is not such a good idea.  While I like gjournal, and use it
quite a bit, I don't think it's suitable as a default.

For one thing, with default settings, it carves out a full GB of usable
space from each filesystem that it's used on.  This would prove highly
surprising to new users, especially on smaller filesystems such as /var,
and may well cause them to think FreeBSD uses a highly inefficient
filesystem.

Also, gjournal journals *everything*, not just metadata.  When the data
and journal are on the same physical device, as they would be in most
setups that take the defaults, all write operations are effectively done
twice (modulo any write-combining).  Again, this probably wouldn't be
expected for a default and would lead to perceived slowness.

Both of these are quite acceptable tradeoffs for what gjournal does, but
the user should be aware of them before choosing to employ it.  I think
it would be wonderful to have in the installer, just not as the default.

I also don't think that ext2 should be offered in the installer, as
there have been periodic stability problems with it, and new users
accustomed to Linux may pick it out of habit and get bitten.

Craig

P.S. I pretty much never use sysinstall anymore, preferring to set up
things as gjournal and geli using Fixit mode, then just extract the
tarballs into the new filesystems.  Having a good standalone
partitioning tool would be nice though, as doing all the math by hand
can be tedious.  Any chance that the module that handles that could be
set up so it's possible to use it independently?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Quation about HZ kernel option

[Craig Boston]

On Thu, Oct 04, 2007 at 02:32:39PM +0200, Oliver Fromme wrote:
> In that case, I would recommend not to override the
> default at all (which is 1000).

ISTM that it would be better to use kern.hz=100 in this case.

My reasoning is that a web server shouldn't be terribly sensitive to
latency, so it's better to have longer quantums to get more work done
without context switching overhead.  If you're not using polling, you'll
be getting interrupts for network traffic anyway.

With polling on however, a high HZ value makes sense.

> Basically, the kernel cannot handle time slices smaller
> than 1/HZ seconds, for any purpose.

It should still be able to schedule a new process for the remainder of
the slice should the current one block or yield though, right?

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

Re: em device hangs on ifconfig alias ...

[Craig Boston]

On Mon, Jul 10, 2006 at 02:56:27PM -0700, Brooks Davis wrote:
> On Mon, Jul 10, 2006 at 05:55:23PM -0300, User Freebsd wrote:
> > >On Mon, Jul 10, 2006 at 12:11:36AM -0400, Mike Tancsa wrote:
> > >Of course, any reasonable administrator would configure
> > >
> > >   interface FastEthernet0/1
> > >spanning-tree portfast

> It tells the switch that this port will never be anything but a leaf in
> the tree so STP does not need to re run before allowing packets to flow.
> If you do this and then create a loop with it, bad things happen, but
> cisco recommends it in general.

Note that STP still runs, it just doesn't start out blocking the port.
Any "bad things" will only happen until the switch figures out that
there is a loop, which usually happens fairly quickly.

Worst case scenario: you may have a packet storm for a second or two.
All the switches I've tried it on detect the loop very quickly (after
only a few packets), so I usually just enable portfast across the board.

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

Re: gjournal and Softupdates

[Craig Boston]

On Tue, Sep 12, 2006 at 09:47:50PM +0200, Teufel wrote:
> Well, thats why i actually don't find journaling filesystems very sexy. 
> So the question is, if it is still safe to use fsck on a gjournal 
> enabled FS ?

Well, if you just want to check, you can take a snapshot and run fsck -n
on it.  That will at least tell you if there's any problems that need to
be dealt with.

Running fsck on a journal-enabled UFS should be safe modulo the usual
requirements (not mounted, which probably means single-user mode).

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

Re: em0: watchdog timeout -- resetting (6.1-STABLE)

[Craig Boston]

On Thu, Sep 14, 2006 at 02:27:29AM +0200, Ronald Klop wrote:
> Them manual page em(4) mentions trying another cable when the watchdog  
> timeout happens, so I tried that. But it didn't help.
> Is there anything I can test to (help) debug this?
> It happens a lot when my machine is under load. (100% CPU)
> Is it possible that it happens since I upgraded the memory from 1GB to 2  
> GB?

I don't think it's the cable.  I started getting these recently as well
(starting about a week ago).  Always when there's a lot of CPU and disk
I/O load.

Also sometimes my USB keyboard would become unresponsive at about the
same time (under high load).  Sometimes it would stutter and act like
the key was being held down for a second or two.

I built a new kernel (6.2-PRE now) on 9/12.  The keyboard problem seems
to be gone but I still get the em watchdog timeouts occasionally.

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

Re: iSCSI HBAs

[Craig Boston]

On Sat, Sep 16, 2006 at 03:35:52PM +0300, Danny Braniss wrote:
> being involved with the iSCSI initiator for FreeBSD, I can't see where
> this can help for a diskless host, or in other words, what's
> wrong with NFS?

Well, for one thing since iSCSI is designed for SAN use, the filesystem
can safely assume that nothing else is accessing it concurrently and do
a lot more aggressive caching.  NFS has to play it safe and check with
the server every time a file is accessed to make sure it hasn't changed.

It sounds to me like the OP is thinking about servers in a large data
center booting off an iSCSI SAN.  Makes migrating off of dead hardware
to a new machine (or even a VM) a snap.

> also, the TOE cards are not that cheep either :-) my 2c, danny

They're usually cheaper than fibre channel HBAs though ;-)

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

Re: CALL FOR TESTERS! [Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2]

[Craig Boston]

I've been experiencing this problem too, along with my USB keyboard
acting 'wonky' (stuttering from time to time).  For me at least it seems
to be tied to CPU usage, meaning it's probably related to the taskqueue
or maybe even the scheduler.  I can also reproduce the problem on a much
bigger scale than I've seen mentioned anywhere else (up to 30 seconds!).

One sure-fire way to trigger it for me is to boot the Ubuntu 6.06.1 CD
inside of qemu.  I don't have kqemu or anything loaded -- it can be
provoked by an ordinary process running as an ordinary user.

While it's sitting at the GRUB screen (30 second countdown), my USB keyboard
becomes inoperable, and em0 goes totally dead.  It feels like no interrupts
getting through -- if a key was pressed it will repeat until the 30 seconds are
up or I kill the process.

I initially suspected something holding GIANT for a long time, so I
tried the giantless USB patches but that didn't help.

Interestingly, I have another em interface in this machine but it
continues to work.

em0 is sharing irq19 with uhci1 (which the keyboard is attached to).
em1 is on irq18.  So whatever it is somehow stops irq19 from getting
through, but the other IRQ lines seem unaffected.  Sounding more and
more like an APIC problem to me.  Or possibly the ithread getting stuck.

This machine *DID* work fine until sometime between 6.1 release and now.
Unfortunately I can't seem to reproduce the problem on any of my test
machines, only on the one that I need for day to day work :)

I'm about halfway through reading the thread, but will be happy to test
any patches do whatever I can to help.

Craig

[EMAIL PROTECTED]:10:0:  class=0x02 card=0x002e8086 chip=0x100e8086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
device   = '82540EM Gigabit Ethernet Controller'
class= network
subclass = ethernet
[EMAIL PROTECTED]:12:0:  class=0x02 card=0x002e1028 chip=0x100e8086 
rev=0x02 hdr=0x00
vendor   = 'Intel Corporation'
device   = '82540EM Gigabit Ethernet Controller'
class= network
subclass = ethernet

On Thu, Sep 28, 2006 at 08:13:51AM -0600, Scott Long wrote:
> All,
> 
> Attached is my first cut at addressing the problems described in this 
> thread.  As I discussed earlier, the VM syncer thread is likely starving
> the USB interrupt thread.  This causes the shared usb+network interrupt 
> to remain masked, preventing network interrupts from being delivered,
> and thus triggering watchdog timeouts.
> 
> This patch only addresses the USB driver.  If your network card is 
> sharing an interrupt with something other than (or additional to) USB,
> this might not work for you.  Also, this patch is just a very rough
> proof-of-concept and is not meant for production use.  But I'd like to
> get feedback now before I spend more time on this.  If this works then
> I'll clean it up and make it suitable for the release, and I'll look at
> some of the other drivers like ichsmb.
> 
> If this is to be fixed for 6.2, I need lots of feedback ASAP.  So please
> do not be shy =-)  The patch is at:
> 
> http://people.freebsd.org/~scottl/usb_fastintr.diff
> 
> Scott
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2

[Craig Boston]

Doesn't seem to have any effect for me (other than high sys% times).
qemu is really good at provoking my em0 to timeout.

On Fri, Sep 29, 2006 at 12:27:41AM -0700, David G Lawrence wrote:
>Attached is a simple user program that will immediately cause pretty much
> all of the network drivers (at least the ones I own) to stop working and
> get watchdog timeouts.
> 
> WARNING: This program will kill the network on your 6.x server. Do not run 
> this on a production machine unless you are on the console and can ctrl-C
> it!
> 
> -DG
> 
> David G. Lawrence
> President
> Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500
> The FreeBSD Project - http://www.freebsd.org
> Pave the road of life with opportunities.

> #include 
> 
> main()
> {
>   struct pollfd pfd;
> 
>   pfd.fd = 1;
>   pfd.events = POLLOUT;
>   pfd.revents = 0;
> 
>   while (1) {
>   if (poll(&pfd, 1 /* stdout */, -1) < 0)
>   break;
>   }
> }

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

Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2

[Craig Boston]

On Fri, Sep 29, 2006 at 05:37:40PM -0400, Kris Kennaway wrote:
> What might be useful for someone who can provoke this, is to configure
> your kernel with MUTEX_PROFILING, then do the following:
>
> 
>
> This will help to show whether something is causing Giant starvation.

I'm currently building a kernel with Scott's patch -- if it still
happens I'll build one with MUTEX_PROFILING and get the results.

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

Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2

[Craig Boston]

On Fri, Sep 29, 2006 at 05:37:40PM -0400, Kris Kennaway wrote:
> and provide access to that file.
> 
> This will help to show whether something is causing Giant starvation.

http://www.gank.org/freebsd/stats.out

That's after about 25 seconds of the em0 interface being unable to
receive because of an apparent lack of interrupt processing (it can
still transmit though!  I had a half-open ssh session that continued to
receive data for a while).

Interesting data point #1: After a fresh boot, I'm unable to reproduce
the problem until I use the kernel linker.  After kldloading a module
(any module) and then immediately unloading it, my test case works 100%
until I reboot again.

Interesting data point #2: After a reboot, the problem moved from em0 on
irq19 to em1 on irq18.  I'm remote from the machine right now so I can't
test the usb controller that's sharing that interrupt, though I suspect
it experienced the same lack of response.

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

Re: CALL FOR TESTERS! [Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2]

[Craig Boston]

On Thu, Sep 28, 2006 at 01:48:42PM -0600, Scott Long wrote:
> http://people.freebsd.org/~scottl/usb_fastintr_RELENG_6.diff

At first glance it appeared to work, but I'm about to do some more
testing since I just discovered that I have to kldload something
(anything) first in order to reproduce the problem.  Weird.

One thing this patch definitely did do though, is break the nvidia
driver pretty badly.  Couldn't keep the X server running for more than a
minute before it froze solid.  Lots of Xid: blah blah blah messages.
Yes I remembered to rebuild the kernel module ;)

Oh, and if anyone is curious, I am able to reproduce the problem after
booting without nvidia.ko loaded, using qemu in -nographic mode.  Just
wanted to rule that out since its code that's out of our control and
would be a prime target to blame if I didn't.

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

Re: CALL FOR TESTERS! [Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2]

[Craig Boston]

On Fri, Sep 29, 2006 at 08:19:04PM -0500, Craig Boston wrote:
> On Thu, Sep 28, 2006 at 01:48:42PM -0600, Scott Long wrote:
> > http://people.freebsd.org/~scottl/usb_fastintr_RELENG_6.diff
> 
> At first glance it appeared to work, but I'm about to do some more
> testing since I just discovered that I have to kldload something
> (anything) first in order to reproduce the problem.  Weird.

I can confirm that despite the other side effect I already mentioned,
this patch does fix or at least mask the problem I'm seing with em (and
probably usb).

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

Re: CALL FOR TESTERS! [Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2]

[Craig Boston]

On Sat, Sep 30, 2006 at 12:14:17AM -0600, Scott Long wrote:
> >One thing this patch definitely did do though, is break the nvidia
> >driver pretty badly.  Couldn't keep the X server running for more than a
> >minute before it froze solid.  Lots of Xid: blah blah blah messages.
> >Yes I remembered to rebuild the kernel module ;)
> 
> My patch shouldn't have a single effect on nvidia.  It just gets the USB 
> out of the way of other drivers.  Weird.  But what does 'blah blah' 
> translate into?

It didn't make any sense to me either after looking at the patch...  I'm
100% sure that was the only change between boots, and it started working
again after I reverted the sys/dev/usb directory and rebuilt. (svk is
great for juggling patch sets around)

That's one of the reasons I briefly suspected the nvidia driver causing
problems somewhere, so I removed that from the mix just to be sure.

'blah blah' translates into numbers that mean nothing to me, but they
may be useful to someone:

Sep 29 16:57:09 kernel: NVRM: Xid (0001:00): 16, Head  Count 0ae5
Sep 29 16:57:09 kernel: NVRM: Xid (0001:00): 16, Head 0001 Count 0ae4
Sep 29 16:57:11 kernel: NVRM: Xid (0001:00): 8, Channel 
Sep 29 16:57:17 kernel: NVRM: Xid (0001:00): 16, Head  Count 0ae6
Sep 29 16:57:17 kernel: NVRM: Xid (0001:00): 16, Head 0001 Count 0ae5
Sep 29 16:57:19 kernel: NVRM: Xid (0001:00): 8, Channel 001e
Sep 29 16:57:25 kernel: NVRM: Xid (0001:00): 16, Head  Count 0ae7
Sep 29 16:57:25 kernel: NVRM: Xid (0001:00): 16, Head 0001 Count 0ae6
Sep 29 16:57:27 kernel: NVRM: Xid (0001:00): 8, Channel 001e
Sep 29 16:57:33 kernel: NVRM: Xid (0001:00): 16, Head  Count 0ae8
Sep 29 16:57:33 kernel: NVRM: Xid (0001:00): 16, Head 0001 Count 0ae7
Sep 29 16:57:35 kernel: NVRM: Xid (0001:00): 8, Channel 001e
Sep 29 16:57:41 kernel: NVRM: Xid (0001:00): 16, Head  Count 0ae9
Sep 29 16:57:41 kernel: NVRM: Xid (0001:00): 16, Head 0001 Count 0ae8
Sep 29 16:57:43 kernel: NVRM: Xid (0001:00): 8, Channel 001e
Sep 29 16:57:49 kernel: NVRM: Xid (0001:00): 16, Head  Count 0aea
Sep 29 16:58:19 kernel: NVRM: Xid (0001:00): 8, Channel 
Sep 29 16:58:27 kernel: NVRM: Xid (0001:00): 8, Channel 001e
Sep 29 16:58:51 last message repeated 3 times
Sep 29 16:58:51 kernel: NVRM: Xid (0001:00): 7, Ch 0001 M D 
bfef0007 intr 0001

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

Re: CALL FOR TESTERS! [Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2]

[Craig Boston]

On Sat, Sep 30, 2006 at 02:39:06PM -0400, Kris Kennaway wrote:
> > > Which is odd since the hypothesis Scott was working on should have
> > > shown up clearly in the mutex trace, but did not.
> > 
> > But it is consistent with there being a beat-frequency problem with 
> > respect to the scheduler.  I think the number you really need is not
> > how long giant was held but how long was spent waiting for it.
> 
> It also seemed to show that nothing was really waiting for it (the
> cnt_* entries).

I can set up a serial console an poke around in DDB during my test case
if anyone thinks some useful information can be found.

Unfortunately I'm remote from the machine right now so I won't be able
to do that until Monday :/

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

Re: Patch available for shared em interrupts (Re: em, bge, network problems survey.)

[Craig Boston]

On Thu, Oct 05, 2006 at 10:34:25PM -0400, Kris Kennaway wrote:
> Please let Scott and I know whether or not this patch works for you
> (in addition to the information previously requested, if you have not
> already sent it).  Unfortunately it is only a workaround, but it
> points to an underlying problem with fast interrupt handlers on a
> shared irq that can be studied separately.

I'm a bit behind in mailing list traffic (700 unread in -stable,
yikes!).  I can confirm that this works around the problem for me.  It
also seems to prevent the USB controller the irq is shared with from
locking up as well.

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

New em driver breaks jumbo frames

[Craig Boston]

Don't have much time right now, but wanted to report that the new em
driver in -STABLE breaks jumbo frame support for me.  With it in the
kernel and this card:

em1:  port 0xe8c0-0xe8ff 
mem 0xfe18-0xfe19 irq 18 at device 12.0 on pci2

I'm unable to send an ethernet frame bigger than 2034 bytes, no matter
what the mtu is set to.  No errors, no kernel messages, it just doesn't
go out.  tcpdump on both local and remote side show nothing at all.

Reverting to the previous driver fixed it.

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

Re: New em driver breaks jumbo frames

[Craig Boston]

On Thu, Nov 02, 2006 at 09:27:14PM -0600, Mark Linimon wrote:
> On Thu, Nov 02, 2006 at 02:09:29PM -0800, Jack Vogel wrote:
> > Yes, this is the second report I've had, other came to me personally.
> 
> There is already a PR about it.

Ah, thanks, guess I should have searched there first...

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

Re: ggate still broken on 6.2-RC1 for amd64.

[Craig Boston]

On Mon, Dec 11, 2006 at 02:47:41AM -0500, David Gilbert wrote:
> That doesn't square with my experience.  Although bigger buffers could
> be involved in a performance problem, what we're dealing with here is
> a _zero_ traffic situation.  It seems that it works enough for tasting
> to be successful, but any significant load wedges it hard.

The problem I observed was also a zero traffic situation.  A quick way
to test is to do something like this (assuming you don't care about the
contents of the device!)

dd if=/dev/zero of=/dev/ggateX bs=1m

and watch the network traffic to see what happens.  When I ran into it,
small block sizes worked fine, but anything bigger than the send buffer
size would cause the entire ggate device to wedge with zero traffic.
The ggatec logs in my mail archive say 128k, which itself is a little
odd because I thought GEOM broke big transfers into 64k chunks.

In any case, ggatec got stuck in a loop getting EAGAIN from send(), so
the packets never made it out to the wire.

However checking my mail archive also indicates that was a year ago so
chances are this is a different problem.  The symptoms just sounded a
little familiar.

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

Stuttering I/O on DPT RAID

[Craig Boston]

Almost sent this to -current, I'm not used to 5.3 being stable yet...

I recently installed an old DPT RAID controller in a test machine (5.3-REL, 
SMP) and saw some odd I/O behavior.  The controller is:

dpt0:  port 0xef80-0xef9f irq 17 at device 
16.0 on pci0
dpt0: DPT PM3334UW FW Rev. 07H1, 1 channel, 64 CCBs
dpt0: [GIANT-LOCKED]

da0 at dpt0 bus 0 target 0 lun 0
da0:  Fixed Direct Access SCSI-2 device
da0: 17365MB (35564544 512 byte sectors: 255H 63S/T 2213C)

It's running RAID-5 and has an on-board cache (64MB worth of 72-pin SIMMs, 
heh).  The drives I think are Seagate Barracuda ultrawide, but I'm not 
physically there to verify at the moment -- they're in a locked enclosure.

The odd behavior surfaced when I went to zero out the array using dd with a 
1MB block size.  According to both gstat and iostat, the array is busy for 5 
seconds or so, then everything drops to 0 for about 2 seconds.

iostat -d -w 1 looks like this:

da0
 KB/t tps  MB/s
128.00  14  1.73
128.00  20  2.48
128.00  20  2.48
128.00  19  2.35
128.00  19  2.35
 0.00   0  0.00
128.00   6  0.74
128.00  20  2.48
128.00  20  2.48
128.00  19  2.35
128.00  19  2.35
128.00   5  0.62
128.00   1  0.12

I know sequential writes aren't a very good way to measure performance, 
especially with RAID-5, but it just seemed a little... odd.  Is this to be 
expected?

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

Re: Was: Re: Making a data DVD with 4.10 and dvd+rw-format

[Craig Boston]

On Friday 03 December 2004 7:20 am, Stein M. Sandbech wrote:
> Yes, I tried that (if my memory doesn't fail me). It seemed to fail on
> something
> related to the ATAPI device /dev/acd0.

If there's nothing else important on the same ATA channel, sometimes an 
atacontrol detach / attach of the entire channel will kick frozen drives 
loose.

Just make sure you don't have a disk with mounted filesystems on there too...

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

Re: Will there be a 5.3.1?

[Craig Boston]

On Wed, Dec 22, 2004 at 05:59:14AM +1100, Peter Jeremy wrote:
> One problem is that Unix first became popular (outside academia) with
> the advent of the 32-bit workstations and then took off with the rise
> of Linux on 32-bit i386.  Lots of Unix code has never seen an environment
> were sizeof(int) == sizeof(long) == sizeof(void *) isn't true.

It's not just int, long, and pointers that cause problems.  There is a
lot of code out there that tends to play fast and loose with the other
types (POSIX?) that IIRC are supposed to be "atomic" -- size_t, time_t,
off_t, etc.

A while back for kicks I tried to build a 32-bit ILP system that used
64-bit time_t values, just in case it managed to make it to 2038 ;)  The
base system was actually in really good shape to deal with it, no doubt
due to the efforts on alpha and sparc64, and ISTR an effort to use
64-bit longs on i386.  Ports on the other hand were a different matter
entirely...

time_t was bad enough. I suspect size_t and ssize_t are in even worse
shape among third-party software.  Though if you just change the size of
"long" you probably won't run into all that.

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

Re: fsck: broken file system with background check remains broken after bootup

[Craig Boston]

On Wed, Jan 05, 2005 at 01:59:01PM +1030, Wilkinson, Alex wrote:
> This inspires me to ask this question:
> 
> Is it possible to set up FreeBSD to do a clean shutdown upon a pressing
> the power button ? i.e. in the same fashion as Solaris does out of the
> box.  Is this an ATX feature or a kernel feature in the PC world ?

Yes, in FreeBSD 5.3 if ACPI is enabled and working properly, pressing
the power button will initiate a graceful shutdown (similar to shutdown
-p).  This feature is enabled by default if it is available, so you
don't have to do anything special to get it.

The usual "if you have weird hardware there are no guarantees"
disclaimer applies, but I've never had a problem with the software
controlled power button on any fairly recent hardware.

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

Re: fsck: broken file system with background check remains broken after bootup

[Craig Boston]

On Tuesday 04 January 2005 9:57 pm, Wilkinson, Alex wrote:
> How can I confirm that ACPI has been setup to do this ?

Hmm, well, the easiest thing to check is to run

sysctl hw.acpi.power_button_state

and see if that sysctl exists and if so, what it's set to (mine is S5, which 
IIRC is complete power-off).  Also, check dmesg and see if you see a line 
similar to

acpi_button0:  on acpi0

If both of those show up, chances are that your ASL has a power button entry 
and it should do the right thing.  Other than that, you could always wait 
until the system is idle and just try hitting the button to see what 
happens ;)

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

Re: Vinum Raid5 Init question

[Craig Boston]

On Tue, Jan 18, 2005 at 12:21:59PM +0100, David Elsing wrote:
> Quote from the manual of the 4th example of the chapter "HOW TO SET UP VINUM":
> "In addition, the volume specification includes the keyword
> setupstate, which ensures that all plexes are up after creation."
> 
> But a couple of weeks later I read the following in the manual:
> 
> "Note that you must use the init command with RAID-5 plexes: otherwise
> extreme data corruption will result if one subdisk fails."

Yes, this particular gotcha bit me a while back and I lost quite a bit
of data (my fault for not having good backups) due to it.  IMO, I still
consider it a documentation bug though.  That particular bit is buried
in a command reference section rather than being in bold in the "HOW TO"
guide.

> I read this to my horror after I filled the volume with data. You'll
> probably noticed I didn't init my volume. The disks are in good
> condition. The volume is almost filled to the maximum capacity. So a
> backup is a bit difficult due to the size of it. Are there any other
> options? If one disks fails, do I still get corrupted data?

Yes, if one disk fails for any reason, every third sector will be
garbage and it's unlikely you'll be able to recover anything useful from
it.

I would highly recommend backing up whatever is critically important to
you asap.  If you like living dangerously and all the drives are in good
health, the parity data can be (theoretically) repaired with the "vinum
rebuildparity" command, but do so at your own risk...  That did allow me
to recover a couple of my partitions that hadn't been trashed yet.

Also, if a good disk gets marked as "down" somehow before you can
correct this, whatever you do, do NOT issue a "vinum start" command on
it.  In the current state of the array, that would be destructive and
irreversible.  That's what happened to me: ATA timeout caused one of the
drives to temporarily detach, corrupt filesystems caused a panic.  If
this happens, you're better off using setstate to force it to up, as
wrong as that would normally be.

I've also noticed that sometimes the parity gets out of sync on its own,
but I don't know the cause.  I used to have a cron job that ran vinum
checkparity once a month in the background and occasionally it would
find sectors that needed to be rebuilt.  Unfortunately this doesn't seem
to be implemented with gvinum (5.3) yet.

> ...know if any manual maintainer is reading this, but is it possible
> to add this warning to the RAID5 example at the end of vinum(8)?

I'll second this idea, at least for 4.x.  I'm not sure how gvinum
handles things as I haven't built any RAID5 volumes from scratch using
it.

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

Re: Vinum Raid5 Init question

[Craig Boston]

On Wed, Jan 19, 2005 at 09:55:25AM +1030, Greg 'groggy' Lehey wrote:
> Yes, it could be clearer.  Put in a PR.

I'm more than willing to submit a patch if it will help, but will it do
any good this late in the release cycle?  Especially if there will be no
4.12 release.

> > Also, if a good disk gets marked as "down" somehow before you can
> > correct this, whatever you do, do NOT issue a "vinum start" command
> > on it.  In the current state of the array, that would be destructive
> > and irreversible.
> 
> No, that's the correct way to do it.

Normally it would be, yes.  However in this case (at least it was for
me), all of the normal blocks are fine, but the parity blocks are random
garbage since init was never run.  If a drive goes into the "down" state
for some reason but is physically fine, starting the subdisk will begin
"reconstructing" the data from the bogus parity, wiping out any hope of
recovering the good data.

If a drive does get detached somehow, it's likely that the system won't
stay up very long -- from its point of view at least one filesystem has
suddenly become very corrupt.  The setstate is dangerous and will
probably result in a somewhat inconsistent filesystem, but it's still
preferable to a total loss...

> I can't recall seeing a problem report.

There wasn't one.  I had encountered the problem on several machines in
a short timespan (fortunately only one had anything important) so I
asked you about in in private mail.  I didn't think the problem was with
FreeBSD or vinum itself -- it was more of a "what am I doing wrong?"
question.  After a couple rounds you determined that it was likely I
hadn't run vinum init, and sure enough that's what it was.

Sorry, I can't provide a time reference.  At the time of the exchange
my mail archive was down (that's what was on the doomed filesystem :).

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

Re: lirc serial FreeBSD

[Craig Boston]

It depends on what type of receiver you have.

comms/lirc in ports works adequately for me with a serial IRman.

Craig

On Tue, Jan 16, 2007 at 08:18:49PM +0530, krishnamurthy holla wrote:
> Dear All,
> i have a serial IR receiver and i am looking for lirc support for serial ir
> device in freebsd
>  is there solutions already made ? or any other alternatives?
> 
> 
> Thanks & Regards
> Krishna
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

umass media size off-by-one?

[Craig Boston]

Hi all, I ran into this while trying to use geli to encrypt an external
usb-2 hard drive.  It appears that sometimes the media size reported by
umass is one sector too big.  For example:

umass0: Prolific Technology Inc. Mass Storage Device, rev 2.00/1.00, addr 2
da0 at umass-sim0 bus 0 target 0 lun 0
da0:  Fixed Direct Access SCSI-0 device 
da0: 40.000MB/s transfers
da0: 171705MB (351651889 512 byte sectors: 255H 63S/T 21889C)

# dd if=/dev/zero of=/dev/da0 oseek=351651888 count=1
dd: /dev/da0: Input/output error
1+0 records in
0+0 records out
0 bytes transferred in 0.002951 secs (0 bytes/sec)

# dd if=/dev/zero of=/dev/da0 oseek=351651887 count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.000982 secs (521360 bytes/sec)

This is with a "high speed, power 100 mA, config 1, Mass Storage
Device(0x3507), Prolific Technology Inc.(0x067b), rev 1.00" enclosure.
I tested with two USB flash memory devices and those seem to report the
correct size.

I'm currently rebuilding a kernel with USB_DEBUG to see if it's specific
to a certain protocol and try to figure out if it's a bug in one of them
or if the enclosure is lying.  Has anyone run into this before?

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

Re: umass media size off-by-one?

[Craig Boston]

On Mon, Mar 05, 2007 at 09:37:33PM -0700, Scott Long wrote:
> Fixed in 7-CURRENT.  Contact Warner Losh to make sure that your device
> is quirked appropriately.

Ah, thanks!  I see the commit now.  Looks like it should be simple to
backport to RELENG_6.

Fortunately all 3 of the machines I intend to use this drive with have
their own local svk branches of the src tree ;)

I'll mail Warner with the vendor and product IDs for my enclosure.

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

Re: pam_group question/proposal

[Craig Boston]

On Fri, Mar 30, 2007 at 01:16:13AM +0400, Taras Savchuk wrote:
> I tried to use pam_group to allow accessing imap(dovecot) only for users 
> in certain group (users/groups stored in AD and checked out via 
> LDAP/Kerberos), but pam_group is checking applicant's group membership. 
> I'm sure, that in many cases is more useful to check group membership of 
> target (authenticating) user, but not applicant. May be it's a good to 
> add such functionality to pam_group (i.e. ability to chose 
> target/applicat membership check) or create separate module?

I had a similar need a while back -- for FreeBSD servers running winbind
as members of an AD domain.  I wanted to allow ssh access for AD users,
but only those in a certain group.  I was unable to find a PAM module
that did exactly what I wanted, so I quickly wrote something to do what
I needed.  You can grab it here if you like:

http://www.gank.org/pam_admins-0.1.tar.gz

It's pretty rudimentary -- it looks for a file with a hardcoded path of
/etc/admins.conf containing a list of groups separated by newlines(1).  If
the target user is in any of the listed groups, the module returns
success.  If not, it returns failure.

There is also an optional minuid parameter that can be passed.  If it is
set, it takes a numeric UID.  If the target user's UID is below minuid,
the module returns PAM_IGNORE.  The idea was that since I have winbind
mapping AD users in the 1-2 range, I can specify minuid=1
so that local users will still be able to log in.  I have this line in
my /etc/pam.d/sshd

account requisite   pam_admins.so   minuid=1

It may not be exactly what you're looking for, but hopefully it can at
least be of some help.

Craig

1. To be of any real use this should probably be changed to take the
filename as a parameter.  Otherwise only one set of required groups is
possible per system.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Changing Console Resolution - Vidcontrol

[Craig Boston]

On Thu, Apr 05, 2007 at 09:25:46AM +0200, Oliver Fromme wrote:
> FWIW, most of the time machines boot without _anyone_
> watching anyway.  If you need to see the boot messages,
> you ssh into the box and type "dmesg -a" or look at the
> file /var/run/dmesg.boot (and /var/log/console.log
> which can be enabled via /etc/syslog.conf).

Yes, and usually if I'm standing in front of a server watching it boot
it's because there's something wrong, so I _WANT_ to see the boot
messages in order to diagnose it :)

bootsplash is kind of fun for desktops, but not really necessary and it
wastes kernel memory that you never get back.

That being said, I can see a place for SC_PIXEL_MODE, especially on
laptops that don't stretch to native resolution so your console ends up
being a tiny box in the middle of the screen.

I only wish 1024x768x4 worked right as (on most cheap video hardware
anyway) pushing all the data for 16-bit modes though VESA is quite slow.
As it's mostly an IO bandwidth issue, the planar modes should be faster.
I can get 800x600x8 working and it's definitely quicker than 800x600x16.

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

Re: Changing Console Resolution - Vidcontrol

[Craig Boston]

On Thu, Apr 05, 2007 at 04:27:46PM +0200, Oliver Fromme wrote:
> I think 800x600x4 would be even quicker, because no VESA
> calls are required at all for screen output.

Oops, I was mistaken.  800x600x4 (MODE_258) is what I'm using.
800x600x8 returns "Operation not supported" when trying to switch to it,
as do both 4 and 8 bit 1024x768 modes.  16-bit and 32-bit modes work at
the higher resolution but they're slow as molasses so I don't use
them(1).

I'd rather use 4-bit anyway as IMO there's very few reasons to have more
than 16 colors in console mode.  elinks is the only program I know of
that claims to be able to use more and syscons may not even support the
control codes it's using.

> (All x4 modes use a planar layout.  If such a bitplane is
> larger than 64K, so-called bank switching is required to
> access all of the video memory, because the VGA address
> space allows only a 64K window for access at once.  VESA
> calls are required to perform the bank switching.

As yes, I'm having flashbacks to the "good ol' days" right now :)  I
mostly stuck to tweaking the VGA registers at the lower resolution modes
as VESA support was pretty spotty on most hardware at the time.  I do
remember using bank switching on occasion though.

> I think FreeBSD's syscons supports it via "flags 0x80"
> for the sc device in the kernel config file.  See the
> section "Driver Flags" in the sc(4) manual page.

Thanks for the tip, but this doesn't work for me.  Setting that flag in
device.hints results in a blank screen and only a single virtual
terminal (ALT+F? just beep).  I _am_ able to log in blind and issue
commands however.  Checking dmesg over ssh didn't show any errors or
clues.

In any case, allscreens_flags works acceptably for my needs.  Strange
that it works but the 0x80 flag doesn't.

(1) Interesting data point, syscons apparently doesn't use VESA very
efficiently.  1024x768x16 mode is very slow -- I can see the screen
redrawing line by line in something like top.

However, I'm currently using the VESA driver for X at the moment as the
trident driver has some problems with the chip in this laptop.
1024x768x16 mode using VESA is fast in X, almost as fast as the
accelerated driver.  So I know the hardware is capable of it.

Unfortunately X has some other issues on this machine, like a weird
kkeybooardd ssstutteringg problem when Xkb is enabled, so I tend to use
the console a lot.

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

Re: Changing Console Resolution - Vidcontrol

[Craig Boston]

On Sat, Apr 07, 2007 at 03:31:40PM +, John Walthall wrote:
> No Matter what I try, I get "cannot open raster device, inapropriate ioctl 
> for this device". I have made sure that I have VESA loaded, etc.

This sounds like your kernel is not compiled with "options
SC_PIXEL_MODE".

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

Portsnap with (broken) transparent proxy on 6.2

[Craig Boston]

Colin,

Normally I would contact you directly (off-list) with this report,
however I had tried searching Google for these symptoms and found no
resolutions, so I'm copying -stable for archival purposes in case
someone runs into a similar problem.

I recently decided to try out portsnap on a few machines.  So far so
good, except for a few.  There are several systems that I maintain which
are behind a transparent proxy (that I don't control and don't even
really know what it is).  It seems this proxy doesn't correctly support
HTTP pipelining, and so the metadata updates fail.

It looks like this:

Fetching 2 metadata files... /usr/sbin/portsnap: cannot open
26700e16d411367c92b53d1aa48ab460fc64c4796b7aa15915e5de39eedab1cc.gz: No
such file or directory
metadata is corrupt.

The debug output doesn't add much to it other than

phttpget: Connection failure

It looks like it does successfully get the first file each time, but
loses the connection afterward.  It would take a lot of invocations of
portsnap to get them all :)

I looked through the portsnap / phttpget source and didn't see an easy
way to disable pipelining.  Perhaps some sort of override could be
added in the future to work around broken proxies?  In the meantime, I
have replaced /usr/libexec/phttpget with the following shell script and
now everything is working fine:

---
#!/bin/sh

SERVER=$1
shift
for x in "$@"; do
  fetch "http://${SERVER}/${x}";
done
---

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

Re: FreeBSD vs Region Code DVDs

[Craig Boston]

On Fri, May 04, 2007 at 11:03:12AM +0200, Ulrich Spoerlein wrote:
> I don't know the code, but it looks like this Plextor and cd(4) don't
> get along when DVD copy protection is involved. I also read in the
> OpenBSD 4.1 release notes, that they made changes to their cd(4) to
> work better with region protected DVDs. I didn't know that the OS was
> involved in this, I thought this was a thing left to the drive
> firmware or the DVD player software.

This is a new drive, correct?  It's possible that the firmware has never
been told what region it's in, and is refusing to read any protected
discs from outside its region (which would be all of them).

Unfortunately I don't know a way other than booting proprietary
operating systems to see what region a drive is set to and/or change it.
Not to say there isn't one, just that I don't know what it is.

Note that most drives these days have a limited number of times they
will set the region before the firmware refuses to change it anymore.

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

Re: FreeBSD vs Region Code DVDs

[Craig Boston]

On Fri, May 04, 2007 at 08:37:30AM -0500, Craig Boston wrote:
> Unfortunately I don't know a way other than booting proprietary
> operating systems to see what region a drive is set to and/or change it.
> Not to say there isn't one, just that I don't know what it is.

As I read further down the thread I see that Tijl Coosemans posted a
couple small programs that look like they should do exactly that.  Might
be worth checking the output of at least the regionget one to see what
the firmware is set to.

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

Re: fast rate of major FreeBSD releases to STABLE

[Craig Boston]

On Thu, May 17, 2007 at 10:24:15AM -0700, Kevin Oberman wrote:
> > The recent ports freeze has also concerned me, this is the longest
> > ports freeze I have witnessed since I started using FreeBSD years ago
> > and its for a desktop element of the os, does it matter if servers
> > running FreeBSD have to remain on vulnerable versions of ports as a
> > result of this?
> 
> Now this is totally bogus. The freeze before the 6.0 release was VERY
> long and several have been longer than this one has been so far.

I think the complaint may be more a result of this being a deeper freeze
than normal.  When ports is frozen before a release, it is often still
possible to get things like security fixes and minor updates approved
and committed.  The only time it's completely frozen is during
branching, which typically doesn't take very long.

I don't know if portmgr@ has approved any commits during the xorg freeze
or not.  Even if so I suspect the "critical" bar may be higher this time
due to the need to manually merge changes into the git repository.

That said, it's a major undertaking and there are valid arguments on
both sides.  Hopefully it will be done soon (keep in mind this is still
a volunteer project!)

> ??? I should leave this to others, but in the past FreeBSD has received
> heavy criticism for taking too long between releases. I guess you just
> can't win. Yes, V5 development is pretty well at an end (though V5 was
> not one of FreeBSD's better releases and I never used it on production
> systems), but V6 support will continue for quite a while.

One thing to keep in mind is that with shorter releases, it's a lot
easier to move from one release to the next.  It was a Very Big Deal to
upgrade from 4.x to 5.x and required lots of pain and planning, mostly
because so much had changed.

Going from 5.x to 6.x was much easier -- for those upgrading from source
it wasn't much different than point releases on the 5.x line.

I recently upgraded a 6.x server to 7-CURRENT to test out zfs and again
it was just like cvsupping and building stable.  There's some library
version issues, but those should be resolved before the 7.0 release
happens.  It's still nowhere near the massive undertaking from 4 to 5.

> I am VERY sure that RE and the developers NEVER want to go through that
> again.

Nor the users ;)

> No one who has any experience is going to drop 7.0 on any critical
> system. I run it on one desktop and my laptop. I am NOT going to
> install 7.0 on my DNS servers or any other critical system.

I'm running -current on my home file server, which is fairly critical to
me, but then again I'm obsessive about backups, which helps :)

I don't think I'd be brave enough to try it on business-critical systems
though, which I suspect is your meaning.

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

Re: dhclient in 6.0

[Craig Boston]

On Sat, Feb 04, 2006 at 10:04:16PM -0800, Kevin Oberman wrote:
> The problem is that the integration of the modern wlan (802.11) code has
> never been done in the if_wi code and it does not report state back to
> wlan adequately to make the OpenBSD client function correctly.

Well, that's not quite accurate.  The wi driver does support net80211 as
much as it can at least.  Sam went to a lot of trouble to support as
much of net80211 as possible given the design of the driver.  Part of
the problem is that full net80211 needs support for hardware operations
that we don't know how to provide for wi.  It's not just a simple matter
of someone going in and adding some function calls...

> I know Sam L. has posted that he had a personal promise from someone to
> update if_wi, but it never happened. (Sam has declined to state who that
> was.)

I'm partly guilty on that -- I told him a while back that I would try to
net80211ify it if I had time, and have yet to come up with anything that
works.  However, he told me the same thing (someone had promised to fix
it and backed out) before I started.  I don't know who the original
person is, but we should respect Sam's wish to not identify him/her.
It's not nearly as simple as it sounds, and I certainly can't blame Sam
for being skeptical of any claims to fix it.

After hacking on wi some trying to get it working I can say that it's
not likely to happen.  Full net80211 layer support requires us to be
able to control the roaming / association behavior of the card.  The
current wi driver only knows how to put the card into "automatic" mode,
where the firmware handles all the details of associating and we never
see any of the 802.11 management frames.  This is likely due to the fact
that there are no publicly available specs for the card or firmware
interface -- so everything we know has been reverse engineered or
gleaned from other sources.

It's been a while, so I don't remember 100% how link state events work
when in "device" roaming mode, but I suspect that's what dhclient
doesn't like.

Also, the wi driver supports two different firmware types with different
interfaces (actually three but nobody's seen the third in ages)... and
the Intersil firmware changes so much between revisions it's like
supporting 20 different firmware types.  Even minor changes have a
tendency to break somebody's card, somewhere.

Case in point, I was able to modify wi enough to get wpa_supplicant and
dhclient to work (mostly) correctly for the card that I have, but when I
sent the diffs to Sam and he tried it, his card wouldn't work at all --
even in manual mode.

> I greatly prefer having dhclient run per interface and, if it understood
> what the wi card was doing, it would be great. But that's not the way it
> is and, with the declining popularity of Prism2 based cards, it may
> never get updated unless someone gets sufficiently annoyed to do the
> work themselves.

It might be possible for someone who has a _LOT_ of free time, and a
_LOT_ of spare hardware to test with, but so far nobody (including me)
has needed it enough to dedicate the time and resources to it.  Perhaps
it would be best to just remove those cards from the supported list if
they haven't been already.

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

Re: Fresh install on gmirror'ed disks?

[Craig Boston]

On Fri, Mar 03, 2006 at 03:36:17PM -0500, Mike Jakubik wrote:
> What are you talking about? I think its time to brush up on your english 
> reading and writing skills. It takes much more work, time, and 
> complexity to 1) boot cd and install os 2) reboot to os and follow a 
> complex procedure to setup geom based raid than it does to 1) boot cd, 
> make gmirror with installer, install os.

Well, honestly, someone who is knowledgeable enough to set up a complex
_bootable_ geom based raid on an existing install would probably find it
easier to do what I usually do:

1) Boot install CD and go to fixit mode
2) Set up RAID the way I want
3) Do a manual install by extracting the packages onto the new
filesystem

That avoids the intermediate install and the hassle of migrating
partitions around.

That said, I think it might be a good idea to have a few simple RAID
configurations in the installer -- say a full-disk mirror or something
relatively fool-resistant.  I'm sure patches would be welcome if anyone
wants to step up :)

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

gmirror on existing filesystem (was Fresh install on gmirror'ed disks?)

[Craig Boston]

On Tue, Mar 07, 2006 at 09:04:02AM -0800, Freddie Cash wrote:
> There's no need to copy files around.  gmirror handles it all for you
> behind the scenes.  Just create the gmirror labels using the existing
> disks/slices/partitions, then insert the second set of
> disks/slices/parittions.  gmirror will handle synchonising the data
> across the mirror.

AFAIK, gmirror causes whatever provider it's mirroring to "lose" the
last block to metadata.  I've always avoided mirroring an existing
filesystem for fear that shrinking a UFS filesystem's underlying device
might cause problems down the road.

Can someone with knowledge of the UFS internals please confirm one way
or the other if this is dangerous or not?

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

Re: [HACKERS] semaphore usage "port based"?

[Craig Boston]

On Tue, Apr 04, 2006 at 10:17:18AM -0400, Vivek Khera wrote:
> Perhaps you can hack into the postgresql master a flag that alters  
> the "1000" parameter, or starts at a port * 1000 + N, then hard-code  
> that flag into your startup script per jail.

A quick and dirty hack to fudge with the requested semid (and shared
memroy identifier) is attached.  Replace XXX with an arbitrary number.

It would be better if this was configurable, but doing it that way works
well enough for what I need, and may at least give an idea where to
start on a better workaround.

Craig
--- src/backend/storage/ipc/ipci.c.orig Tue Feb 28 10:09:23 2006
+++ src/backend/storage/ipc/ipci.c  Tue Feb 28 10:09:38 2006
@@ -102,14 +102,14 @@
/*
 * Create the shmem segment
 */
-   seghdr = PGSharedMemoryCreate(size, makePrivate, port);
+   seghdr = PGSharedMemoryCreate(size, makePrivate, port + XXX);
 
/*
 * Create semaphores
 */
numSemas = ProcGlobalSemas();
numSemas += SpinlockSemas();
-   PGReserveSemaphores(numSemas, port);
+   PGReserveSemaphores(numSemas, port + XXX);
}
else
{
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: splash

[Craig Boston]

On Thu, Apr 06, 2006 at 04:53:46AM -0700, Chris wrote:
> No kidding? These are the same brands I'm using. The ATI's are PCI 
> (onboard ATI - TYAN SMP motherboards) and the nVidia's are AGP. They're
> "higher end" models as well. Must be the way I build the kernel
> regarding boot/ console. Oh well, no complaints. Just interesting to
> hear.

If you don't have VESA support in your kernel (it's not by default), try
adding

vesa_load="YES"

to your loader.conf and see if that helps with higher-resolution splash
images.

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

Re: devfs weirdness with kqemu

[Craig Boston]

On Sun, Apr 09, 2006 at 07:09:17PM +0200, Juergen Lock wrote:
>  Is this something the kld is doing wrong (/usr/ports/emulators/kqemu-kmod)
> or is it a devfs problem?  The report I got was for 6.0, but it also
> happens for me on RELENG_5.  This is nothing serious (kqemu works), but
> it certainly can be confusing for users...

Admittedly the cloning behavior for kqemu is a bit of a hack, but the
module should be working.  Quirky behavior with 'ls' is better than
limiting it to a single process IMO.

IIRC there's still some Linux-ish assumptions made by kqemu about how
devices are opened multiple times that need to be correctly fixed rather
than just worked around.  Been a while since i've looked at it though.

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

Re: 6.0 RELEASE and Volume Managers

[Craig Boston]

On Sun, May 07, 2006 at 03:06:00PM +0300, Yousef Raffah wrote:
> Why should I define it from the card's BIOS? Is it done through the
> system's startup (F9)?

IIRC for most of the Compaq RAID controllers you'll need the Smartstart
CD that came with the server.  A couple of the models I think can be
configured in the BIOS, _IF_ everything in the setup partition is there,
but that partition is usually on the array itself...

That's if it's a compaq server -- unfortunately the Compaq controllers
are real finnicky and don't like to work in non-compaq systems.  I've
had to resort to using a minimal NT4 install to configure one before.

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

Re: [PATCH] securelevel and make installworld

[Craig Boston]

On Wed, Apr 20, 2005 at 05:47:08PM -0500, Jon Noack wrote:
> The attached diff is against -CURRENT but applies cleanly to 5.4-RC3. 
> It adds a check to the installworld target in src/Makefile.inc1 to 
> ensure we are not in secure mode.

What about cases where installing in secure mode is both valid and will
not fail?

For example, consider using installworld to create a jail environment.
If the target directory is empty, no schg files need to be overwritten
and the install will succeed even with securelevel 3.

Some users may also have their system configured so that schg is not set
on system files (INSTALLFLAGS_EDIT=:N-fschg, among other methods).
Arguably this is not very secure, but perhaps they are using securelevel
for something else.  Perhaps protecting firewall rules or sensitive
files?

IMHO, it's not the system's place to second guess what it is told to do.

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

Re: gmirror oddities

[Craig Boston]

On Tue, May 03, 2005 at 11:34:06AM -0700, George Hartzell wrote:
> The fix is described in the fourth comment block of Ralf's doc, either
> make the slice a sector smaller than the disk device or hardcode the
> provider name.  I've been using the hardcoding approach, and it seems
> to work for me.

I'm sorry that I don't remember who said it (I'll do some googling and
follow up if I can find the reference), but one time this came up
someone posted a very good idea which IMHO is a good enough solution to
make the default.  That is, instead of hardcoding the provider name, put
the provider *size* into the metadata.

In theory, that would give the geom classes enough information to deduce
which provider to attach to in all normal cases.  The only catch is if
the size changes somehow after it's been labeled, but that is usually
the sign of something else wrong that will eventually bite you.  It
could simply revert back to the current behavior in that case.

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

Re: gmirror oddities

[Craig Boston]

On Tue, May 03, 2005 at 02:38:08PM -0500, Craig Boston wrote:
> I'm sorry that I don't remember who said it (I'll do some googling and
> follow up if I can find the reference), but one time this came up
> someone posted a very good idea which IMHO is a good enough solution to
> make the default.  That is, instead of hardcoding the provider name, put
> the provider *size* into the metadata.

Aha, it was in fact PJD:

http://lists.freebsd.org/pipermail/freebsd-geom/2005-February/000528.html
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: apm in 5.4

[Craig Boston]

On Thu, May 12, 2005 at 05:16:47PM +0200, Ronald Klop wrote:
> On Thu, 12 May 2005 16:48:36 +0200, Matthias Buelow <[EMAIL PROTECTED]> wrote:
> >The machine is a Compaq Armada m700, kernel is GENERIC from fresh
> >installation; dmesg output is attached.
> 
> Yes, I have apm build into the kernel. Does your machine have apm?
> As somebody else mentioned first try if you have ACPI support on your  
> machine. It is a modern, more advanced version of apm. If ACPI works never  
> look at APM again.

Don't bother -- I've been fighting with ACPI on and off for the last
couple years on an m700.  I always end up giving up and going back to
APM.  No suspend, but at least the battery level can be read.

After MANY variations of ASL hacks it can be made to boot but is never
stable.  I would be surprised if ACPI worked right even in Windows on
these laptops.  There are a few others with the same model who have had
similar expeiences -- AFAIK nobody has ever managed to get it working
reliably.

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

Re: Recent 5.4-p1 upgrade issue (lib/libc.so.5)

[Craig Boston]

Sorry for coming late to the thread -- catching up on mailing list
traffic :)

On Mon, May 23, 2005 at 10:24:15AM -0700, Jon Passki wrote:
> I `chflags noschg /lib/libc.so.5` and then used tar to extract the
> exact file.  tar was able to unlink the file, and then choked. 
> After some unrelated errors, I was in single user mode using
> /rescue to save my rear end, which worked well enough.  Doing `ldd
> /sbin/tar` hinted why it probably choked, since tar is dynamically
> linked to /lib/libc.so.5.

You didn't mention it so I'll ask, did you give the -U flag to tar?  If
not, it didn't actually unlink libc.so.5, but instead started
overwriting it.  This likely caused tar to bomb (probably with a SIGSEGV
or other bad condition), as the shared library in memory is backed by
the pages on disk.

Executables are locked to prevent this from happening (ETXTBSY), however
shared libraries are not.  Overwriting one will almost certainly cause
running processes to die and other Bad Things to happen.

tar -U unlinks the file first and creates a new one, which seems to be
what you want.  Of course if you did specify that and just didn't
mention it, then the problem is something else entirely -- and shouldn't
have happened AFAIK :)

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

Re: atacontrol raid1 vs. gmirror

[Craig Boston]

On Mon, Jun 13, 2005 at 11:14:03AM -0700, Jon Simola wrote:
>   - if they do not probe correctly, check the BIOS settings above
>   - perform a minimal install of FreeBSD 5.3 (do not worry about
> network or anything)
>   - reboot from the installed OS and login as root
>   - Run the command "atacontrol create RAID1 ad4 ad6" to create the raid 
> set

Since the 5.4 CD is now also a live-CD, you could probably do this from
the fixit console rather than having to do an install...

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

Re: Machine Replication

[Craig Boston]

On Thu, Jul 21, 2005 at 12:20:34PM -0700, Eli K. Breen wrote:
> dd(Slow, not usefull if the hardware isn't identical?)

I use dd a lot for this type of thing and don't see how it could
possibly be slower than any other method that duplicates the entire raw
drive.  Make sure to give it a "bs=1m" option as reading/writing the
disk in 512 byte chunks is a lot slower than larger blocks.

If your disks have a lot of free space, copying the filesystem using
dump/restore can be faster, but it's not an *exact* bit-for-bit copy.
The resulting filesystem is functionally equivalent though, so it's
probably the best way for duplicating UFS(2) filesystems.  You do have
to partition manually, but you would probably want to do that if the new
drive was a different size anyway.

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

Re: Jail to jail network performance?

[Craig Boston]

On Mon, Sep 26, 2005 at 12:06:39PM -0700, Brandon Fosdick wrote:
> Ideally I would like a daemon like socat that can connect/merge two
> sockets into one, effectively creating a direct connection and
> eliminating a copy. But AFAICT that isn't possible with the current
> interface.

It depends how dirty you want your hands to get.  Such a thing can be
achieved.  Not so much the merging, but it is possible to pass a file
descriptor over a UNIX domain socket, so in theory a small daemon which
was able to access both file systems should be able to do a handoff.  It
would likely mean modifying the MySQL client library, however.

See the sendmsg(2) and recvmsg(2) functions, specifically the SOL_SOCKET
flag in the recvmsg man page.

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

Re: 5.x, 6.x and CPUTYPE

[Craig Boston]

On Mon, Nov 07, 2005 at 04:21:56PM +1000, Joel Hatton wrote:
> I've noticed that some CPU definitions have changed in /etc/make.conf
> between 5 and 6. For good or for bad, I have up until now been building
> 5.x for both p3 and p4 architectures with 'i686' but this particular
> definition's removal from 6.x has given me cause to rethink my strategy.
> I'd like to know:

Joel, thanks for pointing this out, I hadn't noticed this until I saw
your message.

I always build my production servers with CPUTYPE=i686 so they can be
transplanted to any machine with a PPro or better processor (or even
qemu if necessary).

Looking at bsd.cpu.mk, it appears that i686 *IS* still accepted (for 5.x
compat?) and is just aliased to CPUTYPE=pentiumpro.

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

Re: 5.x, 6.x and CPUTYPE

[Craig Boston]

On Tue, Nov 08, 2005 at 12:05:13PM +1000, Joel Hatton wrote:
> Thanks, Craig. I'm glad to hear that I'm not alone in pursuing this method.
> Do you know of any particular disadvantages of continuing with this
> less-than-optimised model - I guess I mean, is this something that is
> likely to break or become uneconomical at some point?

It won't break; after all the release binaries are targeted for 386 (or
maybe 486 now) in order to be able to run on anything.  You might need
to update make.conf with the "pentiumpro" name just in case they ever
drop the i686 alias, but that's about it.

You might not get quite as good performance as if you compiled for
exactly your CPU (keep in mind we're probably talking about 1-2% at most
unless you have a VERY specific workload that SSE could benefit), but
IMO it's more than worth it to be able to plug the hard drives into a
similar machine and have things Just Work.

Personally, I pick i686 (pentiumpro) as a good middle ground.  The
features optimized for by that are present in every modern
x86-architecture CPU: P2, P3, P4, Athlon, etc.  So it's unlikely you'll
run into something older than that.  Also, the ppro has most of the
features that really affect performance -- i.e. the gap between 386/486
and 686 is a lot bigger than the gap between 686 and P3/P4.

P3s/P-M and Athlons especially are fairly smart and will optimize a lot
of things at runtime.  P4s are probably where you'll see the biggest
performance hit -- that's where Intel tried to push a lot off it off on
the compiler.

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

Re: loader.conf setting ignored

[Craig Boston]

On Thu, Nov 10, 2005 at 03:57:56PM -0500, Ben Kelly wrote:
> So it turns out you can set kern.geom.debugflags from loader.conf.  The 
> gvinum mirror problem I was trying to debug was causing the problem. 
> Edits to loader.conf were only being written to the second disk, but the 
> loader was reading the first disk during boot.  After manually copying 
> /boot over it worked fine.  Just thought I would mention that for the 
> archives.

Just a tip that may help in circumstances like this.  Anything that can
be set from loader.conf (or device.hints for that matter) can also be
set from the loader prompt:

set kern.geom.debugflags=XXX

...of course in your case it looked like the values _were_ being set,
but it can be handy when loader.conf is difficult or impossible to edit.

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

Re: loader.conf setting ignored

[Craig Boston]

Oh, ignore me I just read the thread from beginning and saw that
you already thought of that and didn't have console access :-/

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

Toshiba Satellite L25 (how to run FreeBSD 6.0 on)

[Craig Boston]

Sorry for the cross post, but there doesn't seem to be much traffic on
-mobile so I don't know how many people are reading it.  Please respect
reply-to freebsd-mobile@ and keep any discussion there and off of stable.

I picked up one of these laptops early this morning at the Best Buy
black friday sale since they were ridiculously cheap.  Of course the
first thing I did was pop in the 6.0 install CD.  Here are my results in
the hope that they may help someone else who grabbed one of these.

First of all, ACPI is severiously broken on this machine.  It boots and
appears to be ok at first, but half the hardware doesn't work.  The
integrated NIC (realtek, yuck) starts getting watchdog timeouts as soon
as it's brought up.  So did the 3Com cardbus NIC I popped in.  An old
16-bit PCMCIA NIC just froze and didn't do anything.

There are also a lot of complaints about the \_SB_.BAT1._BST method
being busted (can't find [Z00D] in namespace), and as a result the
battery status cannot be read.

Attempting to boot with ACPI disabled results in a panic:

MPTable: <  RS400 Board>
ioapic0: Assuming intbase of 0
panic: Bogus interrupt flags

Okay, so it appears the APIC setup in the mptable is hosed as well.
Disabling both ACPI and APIC (hint.apic.0.disabled="1" in device.hints)
results in a working system, but alas without power management.

I lucked out and the wireless is an Atheros 5212.  With ACPI on it was
able to scan once before it just stopped working (my guess is interrupt
routing is screwed up somewhere), but with ACPI & APIC disabled it works
fine.  Just make sure to hit the button on the front to enable the radio
as it appears to be hardware controlled in this machine rather than
software.

Sound doesn't work.  It's an ATI IXP SB400 audio controller according
to pciids.sf.net, but it's an AC97 based one so it shouldn't be too hard
to hack together a driver for it.

The video is listed as a Radeon Xpress 200M.  I doubt there's any 3D
support for it, but I'll be installing Xorg in a bit to see if I can get
2D working.

Here's some technical info for any who want it:

http://www.gank.org/freebsd/l25/dmesg.txt
http://www.gank.org/freebsd/l25/pciconf.txt
http://www.gank.org/freebsd/l25/mptable.txt

I'll probably start hacking on the ASL to see if I can repair ACPI
support first, then work on a sound driver if I can't find one.  I'll
post any progress or new information on the -mobile list.

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

Re: HEADS UP: Release schedule for 2006

[Craig Boston]

On Fri, Dec 16, 2005 at 09:20:44PM +0100, Melvyn Sopacua wrote:
> +  Features2=0x180
> 
> Q: What are those extra features and are they useful? ;-)

Enhanced Speedstep and Thermal Management.  They're useful if you want
to use powerd to conserve power / reduce heat generation. (load the
cpufreq driver and look in sysctl dev.cpu)

> -cpu0:  on acpi0
> +cpu0:  on acpi0
> 
> Q: Guessing that's a formatting difference, rather then 6.x not recognizing 
> the states (sysctl hw.acpi.cpu.cx_supported confirms 4 states)

Not sure on this, but you're probably better off using EST anyway as I
think it gives you more control over the processor frequency.

> +uhci0: [GIANT-LOCKED]
> +uhci1: [GIANT-LOCKED]
> +uhci2: [GIANT-LOCKED]
> 
> Q: Again - is this formatting or are these (and the ones below) still under 
> Giant in 6.x but not in 5.x?

Just formatting.  USB (and a lot more) was under GIANT in 5.x as well,
but 5.x didn't tell you which drivers were running under GIANT.  6.x
does as a gentle reminder that those areas need to be worked on ;)

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

Re: Gmirror'd SWAP: no dump?

[Craig Boston]

On Thu, Jan 19, 2006 at 02:53:42PM +, Thomas Hurst wrote:
> > IIRC I had the problem that 'gmirror insert' without '-h' not always
> > inserted the slice specified by the entire block device (e.g.
> > /dev/ad4s1 vs. /dev/ad4). Apparently there is some auto detection
> > code and/or gmirror cannot differ correctly, but that's just a
> > guess. Specifing '-h' fixed it in my case.
> 
> As I understand it, gmirror writes its metadata on the last sector of
> the provider; when tasting devices it will look at the last sector of
> ad4, find the metadata and use that as the provider for your mirror; you
> can either hardcode the provider name there to override it, or make the
> slice 1 sector smaller so gmirror tastes ad4, finds nothing, then goes
> on to taste ad4s1 correctly.

This was fixed for most cases by adding the size of the provider to the
metadata.  ad4 should be a different size than ad4s1 as the partition
table has to go somewhere...

Looks like it was fixed in HEAD in Feb 2005, and MFC'd to 5.x in March.
Shouldn't have ever been a problem for 6.x release.

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/mirror/g_mirror.c#rev1.19.2.8

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

Re: status of ATA subsystem

[Craig Boston]

> This is true. However, stability is an issue AND I also want the newer
> things in -STABLE, like sendmail 8.12 (ducks), and even Soren's ATA
> based cdrecord so I can finally burn CDs on my arbitrary CDRW drive
> here.

You want stability *AND* bleeding edge features?  How about a potion of
immortaility while we're at it? (only joking, of course)

> So I believe the properly phrased questions are
>
> a) "What is the stability status of the current changes to the ATA
> subsystem in -STABLE?".

I think only prolonged testing well tell that.  After all, -STABLE is
technically a development branch.  Just many people (myself included) have
gotten spoiled since it's usually almost as solid as the releases.  Whether
or not a big change such as this was mature enough to be moved from -current
into -stable is another flame^H^H^H^H^Hdiscussion entirely, but remember
that it had to happen eventually.

> b) "We'd like to know the first date (past today) that someone sups
> -STABLE who runs ATA devices, and sees no problems."
>
> and
>
> c) "We'd like to know the last date (past today) that someone sups
> -STABLE who runs ATA devices, and sees problems."

Who is "someone"? :)  I'd be willing to bet there are a lot more people out
there who are having no problems with the new ATA drivers than those who
are.  Generally from what I've seen on the lists and through personal
experience, if you have good and/or common hardware you won't have any
problems.  It's working perfectly for me on a Promise RAID card and Intel
440BX integrated controllers (I forget exactly what ATA chipset they use).
However, I also have some super-discount IDE boards that worked with
release, but have some problems with the new driver.

I'd say to be absolutely sure, pick a machine that's generally reperensative
of the hardware you have (but not too terribly important), do a buildworld
and buildkernel, installkernel, reboot and see if it works.  Try some things
in single-user mode and stress-test the ATA subsystem.  Pretty much all the
problems I've heard about manifest themselves at boot or shortly thereafter,
so if it works at first you probably won't have any problems; and can do the
installworld and mergemaster.  If it doesn't, you can just copy the old
kernel and modules back and everything should fine.

And of course, report your findings so that any issues you encounter can be
fixed! :)

Craig


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

Re: XFree86 faster!?

[Craig Boston]

Oliver Fromme wrote:
> First of all -- yes, I noticed the sarcasm.
> 
> While the speed improvement that Johannes experienced is
> certainly desirable and should not be reversed, it _is_
> somewhat important to find out what caused it.  Because
> if the cause is unknown, then it could disappear one day
> (maybe at the next update), rendering the system slower
> again, and you wouldn't be able to do anything about it
> because you have no clue what it is.

Oh, I agree completely.  I certainly didn't mean to imply that it wasn't
important to find the cause ;)  My apologies, I thought it would be
slightly funnier without an explanation giving it away.

I haven't noticed anything personally on my -stable machines, but
perhaps if Johannes or someone else who's noticed it wants to be
adventurous, and has a fast enough machine to do several buildworlds
without too much pain, he could try a binary search with the CVS/CVSup
dates and find out when the change happened.

OFFTOPIC: Is anyone else experiencing odd delays with the mailing
lists?  For example, I got Ian's reply to Oliver, but have yet to
receive Oliver's original reply to me (both sent to stable@).  Both
messages are in the archive already.  I've seen many messages from both
stable@ and current@ arriving quite out of order (some by several
hours), so I suspect it will show up in my mailbox later.

I'm inclined to think that there's a problem with my local MTA/DNS/etc.,
but I don't see the problem on other lists such as Bugtraq or my
personal mail...

Craig



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

Re: Help needed debugging hard lock (SMP-related)

[Craig Boston]

On Thu, 2002-11-28 at 12:07, Craig Boston wrote:
> (kgdb) print pidhashtbl[73508 & pidhash].lh_first->p_pid
> $21 = 73508

Argh!  I must be losing my mind or something.  I swear there really WAS
text above this before I hit send :)  Anyway, it SHOULD have read
something like the following:

"Sorry for replying to myself.  I decided to try to determine where the
one process in the RUN state (PID 73508) might be stuck, if indeed this
process is what caused the freeze.  After learning the basics of kgdb, I
coaxed this out of my vmcore:"


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

Re: ipfilter / ipnat quandry

[Craig Boston]

On Tue, 2002-12-17 at 13:02, Clifton Royston wrote: 
>   ipf does have the ability to more correctly simulate a closed port. 
> I did a similar exercise on my personal OpenBSD firewall box earlier
> this year; I won't go through your whole ruleset, but basically for
> every TCP port you block, you need to add a return-rst, and for every
> UDP port you block, you need to add return-icmp(port-unr).  This
> provides a pretty good simulation of a host running no services, if
> that's what you want to look like.

Does ipfw or ipf have the ability to return a SYN/ACK packet for each
incoming SYN, and return an appropriate ACK any incoming ACK packets?
(mischievous grin)

Craig


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

Weird messages

[Craig Boston]

Okay, is there something wrong with the mailing list, my mail server, or
am I just going insane?

Seeming random messages (from completely different people) are showing
up as mutipart/mixed, with an empty application/pgp-signature part and
and a text/plain part containing only the following:

On Fri, 2003-03-28 at 09:39, Bruce A. Mah wrote:
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"

They seem to show up in the archive just fine, but then again all of my
other mail except for the freebsd lists is working fine as well.

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

Re: kern/55094: Intel USB 2.0 unrecognized (partial patch provided)

[Craig Boston]

Sorry for the self-reply -- I forgot to mention that though the original 
question was about stable, the patch is against 5.1 release.  I'm not sure if 
ehci has been backported to stable or not (it wasn't in 4.8-RELEASE at 
least).

Craig

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