Re: Light humour

[Matthew Jacob]

This actually gives me hope that computers won't ruin humanity.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Any objections/comments on axing out old ATA stack?

[Matthew Jacob]

On 3/28/2013 8:27 AM, Scott Long wrote:

On Mar 27, 2013, at 4:13 PM, Matthew Jacob  wrote:


On 3/27/2013 2:22 PM, Alexander Motin wrote:

Hi.

Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, 
using only some controller drivers of old ata(4) by having `options ATA_CAM` 
enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) 
code, unused since that time from the head branch to allow further ATA code 
cleanup.

Does any one here still uses legacy ATA stack (kernel explicitly built without 
`options ATA_CAM`) for some reason, for example as workaround for some 
regression? Does anybody have good ideas why we should not drop it now?


Some people have expressed performance concerns about ATA_CAM. I have not 
validated those concerns. Does anyone know of any?

The albatross of "CAM is slow" comes up over and over, but I never see any data 
to support the claims.  So here's an anecdote of my own.

Yes, I understand that. Like I said, they didn't give me details about 
it, but it did seem like some data they were throwing around showed a 
falloff that was significant. However, they have a number of other 
differences which, for whatever reason, may not have played well. I'm 
waiting for more info on it.


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

Re: Any objections/comments on axing out old ATA stack?

[Matthew Jacob]

On 3/27/2013 2:22 PM, Alexander Motin wrote:

Hi.

Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA 
stack, using only some controller drivers of old ata(4) by having 
`options ATA_CAM` enabled in all kernels by default. I have a wish to 
drop non-ATA_CAM ata(4) code, unused since that time from the head 
branch to allow further ATA code cleanup.


Does any one here still uses legacy ATA stack (kernel explicitly built 
without `options ATA_CAM`) for some reason, for example as workaround 
for some regression? Does anybody have good ideas why we should not 
drop it now?


Some people have expressed performance concerns about ATA_CAM. I have 
not validated those concerns. Does anyone know of any?

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

Re: FreeBSD Testing Facility

[Matthew Jacob]

On 2/21/2013 7:32 AM, Alexander Yerenkow wrote:

There just need to be a person dedicated to this, which is lacking now.


That is correct insofar as it goes. That's why we're not all terribly 
interested in suggestions about what *could* be done- just what somebody 
is doing.

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

Re: FreeBSD Testing Facility

[Matthew Jacob]

On 2/21/2013 5:04 AM, Mehmet Erol Sanliturk wrote:

Dear All ,

During development of FreeBSD , testing is very vital .
...


This in general is a good suggestion. Most companies do such automated 
testing as a matter of course.


Note however that this is a volunteer effort. Were you volunteering to 
set up such an automated, possibly testzilla driven, facility? It would 
certainly help the quality, although as others have noted snapshots are 
often likely to be broken.

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

Re: Call for testers, users with scsi cards

[Matthew Jacob]

On 12/4/2012 1:36 PM, Jeff Roberson wrote:

http://people.freebsd.org/~jeff/loadccb.diff

looks ok for isp. This doesn't do diddly for target mode- do you know 
off the top of your head if it will break anything there?


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

Re: November 5th is Clang-Day

[Matthew Jacob]

On 11/2/2012 8:30 AM, Roman Divacky wrote:

Nice :)

Does this deserve mentioning in UPDATING and/or version bump?

I would think so.

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

Re: RFC: removal of share/doc/{papers,psd,smm,usd} in 2 months

[Matthew Jacob]

On 10/19/2012 7:45 AM, Mark Blackman wrote:

On 19 Oct 2012, at 15:36, Ulrich Spörlein  wrote:


Hi all,

those roff sources have been very naughty and will be removed from the
tree by the end of the year. Most of those papers are severely out of
date and provide no more use to the system. They can probably also be
found online using a search engine of your choice.

Should people feel strongly about them, we might be able to move them
over to the doc repository.

I have looked at them every once in a while and I would move them to
the doc repository under 'legacy' or 'archived'.




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

Re: BUFSIZ = 1024, still ?

[Matthew Jacob]

On 8/20/2012 6:59 PM, Scott Long wrote:

On Aug 18, 2012, at 3:43 PM, Matthew Jacob  wrote:


On 8/18/2012 2:36 PM, Poul-Henning Kamp wrote:

In message <50300540.9060...@feral.com>, Matthew Jacob writes:


[...] that there might be a measurable
difference for having to copy 4K (unaligned) than 1K (unaligned) to
kernel space for disposition.

Actually, as far as I'm aware, the 4K would be page-aligned by
default due to our malloc(3) implementation.


Wasn't there just a recent discussion about running 1.x binaries?

1.x binaries wouldn't notice and wouldn't be able to tell
if BUFSIZ is different in 10.x

I wasn't concerned about those specifically- I was just using this as an 
example of leaving stuff alone.


If you're going to talk about making a change to defaults, the default
MAXPHYS and DLFTPHYS have been undersized for years now.

Indeed, but as I understand it, those require device driver changes ?

Ah, well 10.X would be an ideal time to find out!


This gets brought up from time to time, and I honestly thought that I swept 
most of the problems up a few years ago.  The mistake that I made in the mlx 
driver that was recently corrected was evidence of a previous sweep.

If anyone wants to do another sweep, the thing to grep for is any drivers that 
use MAXPHYS to size their i/o's.  For the drivers that do that, you then have 
to see if they can actually handle an arbitrary number of scatter-gather 
elements.  If they can't then they need to stop using MAXPHYS and start using a 
constant that applies to the driver.  My quick scan shows the following would 
need to be investigated:

sys/dev/ata (legacy ata)
/sys/dev/isp
/sys/dev/mmcsd
/sys/dev/mvs

The only other problem is that struct but contains an element sized on MAXPHYS 
for doing swapper I/O.  Increasing MAXPHYS will increase this, and at one point 
I think that Alan Cox might have wanted to find a better way to hold swap info. 
 Otherwise, increasing MAXPHYS causes no problems and is something that has run 
in production for quite some time at places like Yahoo and Netflix.




I think I merely asked whether we were going to increase the defaults. 
Are you suggesting we eliminate MAXPHYS for drivers entirely and just 
base upon the drivers' native limits? The isp driver very specifically 
uses MAXPHYS right now because it's a manifest constant. If we're 
eliminating it, that's fine by my. What mechanism will be used to break 
up transfers then?


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

Re: BUFSIZ = 1024, still ?

[Matthew Jacob]

On 8/20/2012 5:24 AM, John Baldwin wrote:

On Saturday, August 18, 2012 5:05:11 pm Poul-Henning Kamp wrote:

In message <5030033b.4060...@feral.com>, Matthew Jacob writes:

On 8/18/2012 1:32 PM, Poul-Henning Kamp wrote:

Shouldn't we at least increase it to pagesize ?


What data suggests to you it would be better at pagesize?

The number of system calls to fwrite() a big file ?

Have you looked at an actual ktrace? :)  stdio doesn't use BUFSIZ for
regular files:

head/lib/libc/stdio/makebuf.c:
/*
  * Internal routine to determine `proper' buffering for a file.
  */
int
__swhatbuf(fp, bufsize, couldbetty)
 FILE *fp;
 size_t *bufsize;
 int *couldbetty;
{
 struct stat st;

 if (fp->_file < 0 || _fstat(fp->_file, &st) < 0) {
...
 *bufsize = BUFSIZ;
 return (__SNPT);
 }

 ...
 if (st.st_blksize <= 0) {
 *bufsize = BUFSIZ;
 return (__SNPT);
 }

 *bufsize = st.st_blksize;
 ...
}

For a regular file stdio will use the filesystem's block size, not BUFSIZ.

Test program:

#include 
#include 

int
main(int ac, char **av)
{
 char junk;
 FILE *fp;
 int i;

 fp = fopen("/tmp/junk", "w");
 if (fp == NULL)
 err(1, "fopen");
 for (i = 0; i < 1024 * 1024; i++)
 if (fwrite(&junk, sizeof(junk), 1, fp) != 1)
 errx(1, "fwrite failed");
 return (0);
}

ktrace excerpt:

  42599 a.outCALL  write(0x3,0x800a04000,0x4000)
  42599 a.outRET   write 16384/0x4000
  42599 a.outCALL  write(0x3,0x800a04000,0x4000)
  42599 a.outRET   write 16384/0x4000
  42599 a.outCALL  write(0x3,0x800a04000,0x4000)
  42599 a.outRET   write 16384/0x4000
  42599 a.outCALL  write(0x3,0x800a04000,0x4000)
  42599 a.outRET   write 16384/0x4000
  42599 a.outCALL  write(0x3,0x800a04000,0x4000)
  42599 a.outRET   write 16384/0x4000
  42599 a.outCALL  write(0x3,0x800a04000,0x4000)
  42599 a.outRET   write 16384/0x4000

This hint also works for pipes (they set st_blksize to PAGE_SIZE).  Given
that, I think BUFSIZ should just be left alone.


Perfect. Data.

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

Re: BUFSIZ = 1024, still ?

[Matthew Jacob]

On 8/18/2012 2:36 PM, Poul-Henning Kamp wrote:

In message <50300540.9060...@feral.com>, Matthew Jacob writes:


[...] that there might be a measurable
difference for having to copy 4K (unaligned) than 1K (unaligned) to
kernel space for disposition.

Actually, as far as I'm aware, the 4K would be page-aligned by
default due to our malloc(3) implementation.


Wasn't there just a recent discussion about running 1.x binaries?

1.x binaries wouldn't notice and wouldn't be able to tell
if BUFSIZ is different in 10.x
I wasn't concerned about those specifically- I was just using this as an 
example of leaving stuff alone.



If you're going to talk about making a change to defaults, the default
MAXPHYS and DLFTPHYS have been undersized for years now.

Indeed, but as I understand it, those require device driver changes ?

Ah, well 10.X would be an ideal time to find out!

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

Re: BUFSIZ = 1024, still ?

[Matthew Jacob]

On 8/18/2012 2:05 PM, Poul-Henning Kamp wrote:

In message <5030033b.4060...@feral.com>, Matthew Jacob writes:

On 8/18/2012 1:32 PM, Poul-Henning Kamp wrote:

Shouldn't we at least increase it to pagesize ?


What data suggests to you it would be better at pagesize?

The number of system calls to fwrite() a big file ?

What evidence would there be that it would hurt ?

I am normally not this conservative, but I see this as "why make a 
change"? If you're concerned about performance, you won't be using 
fwrite, you'll use O_DIRECT and do your own alignment. But I see your point.


One could vaguely argue that a 4K BUFSIZ will put at risk more data on 
crashes needlessly. One could also vaguely say that the write syscall 
isn't expensive in and of itself, and that there might be a measurable 
difference for having to copy 4K (unaligned) than 1K (unaligned) to 
kernel space for disposition.


Wasn't there just a recent discussion about running 1.x binaries? One 
reason we can do things like that is basic constants don't change very 
often. I believe the last time I saw BUFSIZ change was from BSD 2.9 to 
BSD 4.0, but I probably misremember that.


If you're going to talk about making a change to defaults, the default 
MAXPHYS and DLFTPHYS have been undersized for years now.



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

Re: BUFSIZ = 1024, still ?

[Matthew Jacob]

On 8/18/2012 1:32 PM, Poul-Henning Kamp wrote:

Shouldn't we at least increase it to pagesize ?


What data suggests to you it would be better at pagesize?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: post SVN r238886 no boot?

[Matthew Jacob]

On 7/29/2012 10:40 AM, Michael Butler wrote:

Is anyone else having troubles getting -current after SVN r238886 to
boot? In my case, I have an unstoppable stream of pager_something
console messages :-(

imb


me2

If I stop at single user and then continue, then all seems okay.

I'm guessing (just a SWAG) that it might be related to the disk resize 
CAM stuff just added.


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

Re: isp Tape Drive no longer detected

[Matthew Jacob]

Actually, can you try this patch please? I won't be able to get to my 
lab and get a working 1040 card into a system until tomorrow.




diff -r 5aba1b04ddd5 isp.c
--- a/isp.c Sun Jun 24 10:22:10 2012 -0700
+++ b/isp.c Sun Jun 24 19:36:06 2012 -0700
@@ -710,8 +710,11 @@
0x, 0x6677, 0x1122, 0x33ff,
0x, 0x0001, 0x1000, 0x1010,
};
+   int nmbox = ISP_NMBOX(isp);
+   if (IS_SCSI(isp))
+   nmbox = 6;
MBSINIT(&mbs, MBOX_MAILBOX_REG_TEST, MBLOGALL, 0);
-   for (i = 1; i < ISP_NMBOX(isp); i++) {
+   for (i = 1; i < nmbox; i++) {
mbs.param[i] = patterns[i];
}
isp_mboxcmd(isp, &mbs);
@@ -719,7 +722,7 @@
ISP_RESET0(isp);
return;
}
-   for (i = 1; i < ISP_NMBOX(isp); i++) {
+   for (i = 1; i < nmbox; i++) {
if (mbs.param[i] != patterns[i]) {
ISP_RESET0(isp);
isp_prt(isp, ISP_LOGERR, "Register Test Failed 
at Register %d: should have 0x%04x but got 0x%04x", i, patterns[i], 
mbs.param[i]);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: isp Tape Drive no longer detected

[Matthew Jacob]

On 6/24/2012 7:18 PM, Manfred Antar wrote:

As of today my tape drive is no longer detected. I think the isp driver does 
not load

What? Somebody is using a tape drive still? And parallel SCSI?
*gasp*

Yes, sorry, my bad. Looks like my extending register tests for the 2400 
has killed things for the 1040. Expect a change tonite sometime- apologies.


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

Re: FreeBSD 10 prognostication...

[Matthew Jacob]

On 5/12/2012 6:25 AM, Vance Siemens wrote:

Can you share a brief overview of what's wrong with it? I guess I'm
not as knowledgeable as I thought. The story was quite enticing to me.


Very few of the historical facts are actually correct.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: "trim/discard" success story

[Matthew Jacob]

My experience at Alacritech was that Trim was so expensive timewise that 
it could not be used in that application space. Instead, SECURITY ERASE 
on the relatively infrequent reboots cleaned things up pretty well.


This should be with a grain of salt because I expect trim timings are 
not only vendor dependent but firmware release dependent.

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

Re: Announcing Emulex 10G Ethernet NIC driver availability

[Matthew Jacob]

Any plans for iscsi, fcoe?


Hi All,



Please find the 10Gb Ethernet NIC driver for Emulex OneConnect
(BladeEngine) and Lancer family of network adapters at

http://info.iet.unipi.it/~luigi/20120207-emulex-nic.tgz
.



Luigi Rizzo  has already reviewed the driver and has agreed to do
commit-to-the-tree (thanks a lot Luigi).

Please review and send us any comments you may have.



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


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

Re: bus dma: a flag/quirk for page zero

[Matthew Jacob]

At the very least, require bounce buffers.


Not sure if I got this suggestion in this terse form.
Could you please explain?


Physical address zero can be DMA'd, but via bounce buffers.
bcopy from address zero up through a pagesize to a bounce buffer, do the 
dma from there (read case), write case the opposite order

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

Re: bus dma: a flag/quirk for page zero

[Matthew Jacob]

I think it would be just simpler to disallow page zero usage period. Can 
you think of any case where physical page 0 is ever a valid DMA address?

At the very least, require bounce buffers.


On Tue, 10 Jan 2012, Andriy Gapon wrote:




Some hardware interfaces may reserve a special meaning for a (physical) memory
address value of zero.  One example is the OHCI specification where a zero value
in CurrentBufferPointer doesn't mean a physical address, but has a reserved
meaning.  To be honest I don't have another example :) but don't preclude its
existence.

To deal with this peculiarity we could use a special flag/quirk that would
instruct the bus dma code to never use the page zero for communication with the
hardware.
Here's a proof of concept patch that implements the idea:
http://people.freebsd.org/~avg/usb-dma-pagezero.diff

Some concerns:
- not sure if BUS_DMA_NO_PAGEZERO is the best name for the flag
- the patch implements the flag only for x86 at the moment
- usb code uses the flag regardless of the actual controller type

What do you think?

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


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

Re: can a wrong alignment cause a decrease in a hdd's life expectancy?

[Matthew Jacob]

On 12/19/2011 2:22 PM, Poul-Henning Kamp wrote:

In message<20111219221617.ga70...@freebsd.org>, Alexander Best writes:


ps: the hdd only gets mounted read-only!

There is no known wear-effects in flash storage as long as you
only read.


No, sorry, that's not really true.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: can a wrong alignment cause a decrease in a hdd's life expectancy?

[Matthew Jacob]

Putting it better: http://en.wikipedia.org/wiki/Flash_memory#Read_disturb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gmultipath: act/act, path checking?

[Matthew Jacob]

On 10/28/2011 12:37 PM, Alexander Motin wrote:

On 26.10.2011 12:09, Dennis Koegel wrote:

are there any plans to have gmultipath support for active/active?

Few days ago I've started from fixing some issues in gmultipath and
already rewritten half of it while trying to make it usable. I expect to
have something to present in a week or two. It will also include
active/active mode support there, as at my present point required
changes are minimal.


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

Re: Adding disk firmware programming capability to camcontrol

[Matthew Jacob]

This is a good idea, except that it makes me really really nervous. I do 
not believe that fw downloads are generic enough to encapsulate. I've 
used camcontrol recently to tunnel an ATA command through mpt2 that does 
an ATA DOWNLOAD FW (mode 7), but that is only because it is a specific 
drive that I've validated works correctly.


The linux hdparm program is so paranoid about this that you have to use 
extra arguments like "--yes-really-destroy-my-disk-drive" to do this.


I'm very very nervous about putting it into camcontrol.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: isp(4) WWNs / ISP2532

[Matthew Jacob]

Cheers,

we have a "Qlogic ISP 2532 PCI FC-AL Adapter" here, on 9.0-RC1, which
seems to work fine with isp(4).

But: We had some trouble finding the WWNs -- per man page, there should
be sysctl entries like dev.isp.N.{wwnn,wwpn}, but they ain't here. dmesg
didn't show them either.

Booting verbose does print them.

Is the man page outdated, or a strange behaviour because this chip
isn't explicitly supported?


This question would be better answered on freebsd-scsi.

It's a bug, and it's easy to fix, but because of the impending 9.0 
release I haven't done it.
There's an ioctl you can use to do the same thing and some tools in 
http://people.freebsd.org/~mjacob/isp_tools.tgz that can solve what you 
need.

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

Re: gmultipath: act/act, path checking?

[Matthew Jacob]

On 10/26/2011 2:09 AM, Dennis Koegel wrote:

Cheers,

are there any plans to have gmultipath support for active/active?


I was given patches but have lacked motivation to do it.



Also, is there any way to check available paths periodically? As far as
I unterstand, once gmultipath kicks a certain path due to failure, it
will never come back automatically. (And it won't ever be used if it
isn't working at boot time)


That is something that should have been fixed. I might be confused with 
the changes I did for Panasas that didn't make it back here, but I 
certainly had a rolling test where I ran for several days periodically 
failing one path and then then the other.




I've found some discussion about this from 2008, but nothing since...

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


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

Re: Recommended methods to upgrade firmware on HBAs

[Matthew Jacob]

The current firmware(9) mechanism might work for you. The QLogic FC/SCSI 
cards in FreeBSD use that for loading firmware images to download to the 
cards, albeit to just load and reset, to update flash.


"not to update flash" (locations in flash where to put firmware are not 
documented by Qlogic)


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

Re: Recommended methods to upgrade firmware on HBAs

[Matthew Jacob]

The current firmware(9) mechanism might work for you. The QLogic FC/SCSI 
cards in FreeBSD use that for loading firmware images to download to the 
cards, albeit to just load and reset, to update flash. This allows the 
drivers themselves to request updates.


Note that the root filesystem has to be mounted for this mechanism to 
work.


Other mechanisms include ioctl mechanisms as per what the LSI cards do via 
the mpiutil and mfiutil programs.



On Thu, 22 Sep 2011, David Somayajulu wrote:


Hi All,

1.   What is the current recommended method for upgrading firmware for HBAs?

2.   Is there a mechanism wherein the firmware binary can be provided as a 
separate file, which is then made accessible to the  corresponding device 
driver during device initialization?

3.   Is there a restriction on the size of driver.ko file? If not, is it 
acceptable to provide the firmware as fw_file.c which is then compiled into the 
driver.
Thanks
david S.



This message and any attached documents contain information from QLogic 
Corporation or its wholly-owned subsidiaries that may be confidential. If you 
are not the intended recipient, you may not read, copy, distribute, or use this 
information. If you have received this transmission in error, please notify the 
sender immediately by reply e-mail and then delete this message.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



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

Re: RELENG_8 / mpt / zpool Errors

[Matthew Jacob]

On 9/6/2011 4:04 PM, Tim Gustafson wrote:

Hi all,

I'm running RELENG_8:

--
...

So, is this an OS/driver issue?  Is it a bad controller?  Bad cables?  Bad 
disks?

As always, any help is greatly appreciated.  Thanks!




Likely some problem in the external  box. Note that you get a 'POR' 
check condition- something reset out there. Possibly cables. Remotely 
possible firmware.


Very unlikely to be an OS or driver issue.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

amusing reboot message with -current

[Matthew Jacob]

db> reboot
cpu_reset: Restarting BSP
cpu_reset: Restarting BSP
cpu_reset_proxy: Stopped CPU 2
cpu_reset_proxy: Stopped CPU 2


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

Re: isp(4) timeout

[Matthew Jacob]

On Tue, 5 Jul 2011, Anton Shterenlikht wrote:


I somehow missed ispfw(4).
Now added

device  ispfw

to the kernel.

Is this sufficient?



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

Re: isp(4) timeout

[Matthew Jacob]

On 7/5/2011 1:39 AM, Anton Shterenlikht wrote:

 ...
dmesg:

http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2620/ZEEV/dmesg.boot

Many thanks
Anton




isp0: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.90


Add the line

isp_2400_load="YES"

to /boot/loader.conf.


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

Re: isp(4) timeout

[Matthew Jacob]

On 6/30/2011 3:25 AM, Anton Shterenlikht wrote:

I see in my logs:

isp0: Polled Mailbox Command (0x54) Timeout (50us) (started @ 
isp_plogx:2122)
isp0: Mailbox Command 'EXECUTE IOCB A64' failed (TIMEOUT)
isp0: Chan 0 PLOGI 0x010500 failed
isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ 
isp_getpdb:2307)
isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT)


More details please.

These errors indicate failures to execute commands that try and figure 
out what's on a fabric and then log into devices on the fabric. Knowing 
what hardware you have (QLogic card version), what FreeBSD release you 
are running, would help. A verbose dmesg would be useful.

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

Re: Thoughts on TMPFS no longer being considered "highly experimental"

[Matthew Jacob]

I may have missed something, but I'm not aware of any serious PRs on
TMPFS either.


There was some issues with sendfile(2) and mmap(2) causing kernel hangs
in some cases. vim triggers such hangs for me. However, those problems
were fixed and MFCed (afair).


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

Re: Thoughts on TMPFS no longer being considered "highly experimental"

[Matthew Jacob]

I gave up on using it after a brief try earlier this year. I can't 
remember the details, but it did lock up my amd64 system.


On Thu, 23 Jun 2011, David O'Brien wrote:


Does anyone object to this patch?

David Wolfskill and I have run TMPFS on a number of machines for two
years with no problems.

I may have missed something, but I'm not aware of any serious PRs on
TMPFS either.


Index: tmpfs_vfsops.c
===
--- tmpfs_vfsops.c  (revision 221113)
+++ tmpfs_vfsops.c  (working copy)
@@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
return EOPNOTSUPP;
}

-   printf("WARNING: TMPFS is considered to be a highly experimental "
-   "feature in FreeBSD.\n");
-
vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
VOP_UNLOCK(mp->mnt_vnodecovered, 0);

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


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

Re: Switch from legacy ata(4) to CAM-based ATA

[Matthew Jacob]

now that I've worked with it a bit, I really like it. Doing this by default
in 9.0 would be a really useful step forward, and would allow greater
innovation down the road.

Is there a handy tutorial somewhere for making this change in FreeBSD? Or is
it even possible to do in a rational way?


glabel create  /dev/
sed -i 's,/dev/,/dev/labels/,g' /etc/fstab



or, dumpfs /dev/ad0a (or whatever it is) to get the UFS id, and do that, 
as in:



/dev/ufsid/4cbfaf39a70e852e /   ufs rw  1 1



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

Re: Switch from legacy ata(4) to CAM-based ATA

[Matthew Jacob]

On Wed, 20 Apr 2011, Scott Long wrote:

...

I agree with what Alexander is saying, but I'd like to take it a step 
further.  We should all be using either mount-by-label, or be working to 
introduce generic device names to GEOM.  Right now, device names are an 
implementation detail that have no functional use other than to 
complicate the fstab.  Disks exposed through the block layer are simply 
direct-access block-array devices, nothing more.  There's no functional 
difference to the kernel or userland between ad, ar, da, aacd, mfid, 
amrd, etc when it comes to reading and writing sectors off of them. 
But yet we give them unique names and pretend that those names mean 
something.  We could give them all the name of "disk" and the system 
would still function exactly that same.  The name attributes are 
interesting when it comes to doing out-of-band management, but it's also 
trivial to create a human-readable map and a programatic API between the 
generic name and the attribute name.  Same goes for volumes labels, and 
I'd almost argue that they're more powerful than generic device names.


In other words, "ada" isn't the problem here, it's that we all still 
think in terms of the 1980's when systems didn't autoconfigure and 
device names were important hints to system functionality.  That time 
has thankfully passed, and it's time for us to catch up.




Still, keep in mind that conservative leanings have to be appeased. Back 
in SparcStation1 development (1989) we kept on calling the root device 
"Fred" as in "Let's boot fred now".


That said, you would not *believe* the flack I took for having the root 
filesystem on sd3 instead of sd0 in SS1, even though there was no reason 
it couldn't have just been called "fred".

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

Re: Switch from legacy ata(4) to CAM-based ATA

[Matthew Jacob]

Yes, I believe that now is the time to do this.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: `panic: run_interrupt_driven_config_hooks: waited too long' on HP DV8

[Matthew Jacob]

On 3/13/2011 5:03 PM, Yuri Pankov wrote:

On Sun, Mar 13, 2011 at 04:41:58PM -0700, Matthew Jacob wrote:

Yes they are. The full messages from the failed boot would be helpful.
Looks like we have ATA in CAM now, so it's possible that the disk reset
failed, etc...

What are my options for saving the output from failed boot other than
handtyping it (no serial ports, no serial USB adapters)?

None that I can think of :-(
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: `panic: run_interrupt_driven_config_hooks: waited too long' on HP DV8

[Matthew Jacob]

Yes they are. The full messages from the failed boot would be helpful. 
Looks like we have ATA in CAM now, so it's possible that the disk reset 
failed, etc...

Not sure if these are useful:
http://darklight.org.ru/misc/dv8.dmesg.boot
http://darklight.org.ru/misc/dv8.pciconf


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


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

Re: `panic: run_interrupt_driven_config_hooks: waited too long' on HP DV8

[Matthew Jacob]

This usually has to do with a hung SCSI command. That this is a notebook 
indicates to me that it's possibly a USB device. A boot -v with 
8.2RELEASE and then a boot -v with this snapshot might tell us what's up.

Hi,

I'm getting the following panic trying to boot March 5 snapshot on
HP Pavilion DV8 notebook (8.2-RELEASE GENERIC kernel seems to boot on
the same hardware just fine):

run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config
panic: run_interrupt_driven_config_hooks: waited too long
cpuid = 0
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at  kdb_enter+03xb: movq$0,0x800ab2(%rip)
db>  bt
Tracing pid 0 tid 10 td 0x80ee83e30
kdb_enter() at kdb_enter+0x3b
panic() at panic+0x180
boot_run_interrupt_driven_config_hooks() at 
boot_run_interrupt_driven_config_hooks+0xb3
mi_startup() at mi_startup+0x77
btext() at btext+0x2c

Any hints or additional information I should provide to troubleshoot
this?


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


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

Re: $PATH and buildworld not getting along

[Matthew Jacob]

I generally don't have problems with make in FreeBSD environments, but 
often have tons of problems in others, like OpenSolaris, 
buildroot/busybox, and so on.  To solve this, I clean my environment by 
using this shell script (called cleanenv):


#!/bin/sh
env -i PATH=/usr/bin:/bin TERM=${TERM} P4CONFIG=P4ENV $*
exit $?

or variants on this to run make (as in 'cleanenv make'). This tends to 
try and limit the chaos from environment assumptions.


I don't think it is make's job, or the build tree's job, to enforce this 
cleanliness- mostly because it's really hard to do. It's just a lot 
easier to be a canonical simple 'user' when building.


On 2/18/2011 9:24 AM, Dimitry Andric wrote:

On 2011-02-18 17:36, Alexander Best wrote:
...
i'd say no. imo nothing from /usr/local/* should ever be invoked when 
compiling
a target in /usr/src. everything that's needed is in /usr/* 
(excluding local).


so $PATH should unconditionally be set to sth. like:

PATH=/sbin:/bin:/usr/sbin:/usr/bin;

to be sure no tools, libs or whatever from any foreign place such as
/usr/local/* get sucked into a build.


I'm not sure if you modified anything in your source tree, but my
/usr/src/Makefile has this line very close to the start of the file:

PATH=   /sbin:/bin:/usr/sbin:/usr/bin

so what is the problem, exactly? :)

If you are building stuff by hand, you are outside regular territory
anyway, and you should simply pay attention to your PATH yourself.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 
"freebsd-current-unsubscr...@freebsd.org"

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

Re: groff build failure (me too, but i386)

[Matthew Jacob]

Update your tree. This was broken in fixed within the last week or so


Hi!

Since nobody seems to get the error it may be my fault. Please, help
if you can. Thanks!

Here are some details:
-
[~]b...@bb% uname -a
FreeBSD bb.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r214737: Wed Nov  3 
18:48:54 MSK 2010 r...@bb.ipt.ru:/usr/obj/usr/src/sys/GENERIC  i386
[~]b...@bb% svn info /usr/src
Path: /usr/src
URL: svn://svn.freebsd.org/base/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 215798
Node Kind: directory
Schedule: normal
Last Changed Author: kib
Last Changed Rev: 215798
Last Changed Date: 2010-11-24 15:34:25 +0300 (ср, 24 ноя 2010)

[~]b...@bb% svn status /usr/src
[~]b...@bb% make -C /usr/src buildworld
...
c++ -O2 -pipe 
-I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn
 -I. -DHAVE_CONFIG_H 
-I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include
 -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include 
-fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp
y.tab.c: In function 'int yygrowstack()':
y.tab.c:703: error: invalid conversion from 'void*' to 'short int*'
y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*'
*** Error code 1

Stop in /usr/src/gnu/usr.bin/groff/src/preproc/eqn.
...
-



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

Re: 256G Ram Panic

[Matthew Jacob]

Any way to restrict the mem available with hints to find out where the 
cutoff point is?


On 11/21/2010 9:03 AM, Sean Bruno wrote:

http://people.freebsd.org/~sbruno/256G_SMAP.png
http://people.freebsd.org/~sbruno/256G_panic1.png
http://people.freebsd.org/~sbruno/256G_panic2.png


Trying to get the HP DL980 online today and I see the following panic on
startup from the installer CD that I created from -CURRENT.

Sean

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

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

Re: groff build failure

[Matthew Jacob]

recent change to yacc by someone who will probably back it out in the 
morning

very current amd64

===>  gnu/usr.bin/groff/src/preproc/eqn (all)
c++ -O2 -pipe 
-I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn
 -I. -DHAVE_CONFIG_H 
-I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include
 -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include 
-fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp
y.tab.c: In function 'int yygrowstack()':
y.tab.c:703: error: invalid conversion from 'void*' to 'short int*'
y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*'
*** Error code 1
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


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

Re: HEADS UP: device name checking on device registration

[Matthew Jacob]

 I am antisocial.

Okay, changed it so my replies are above the quotes. Seems to have 
attributes here. And I usually hit 'reply list' since multiple copies 
burns bandwidth.


On 10/12/2010 1:57 PM, Andriy Gapon wrote:


P.S. Matthew, it seems like you have a really unhelpful mail client program:
first, it top-posts :-)
second, it doesn't always attribute quoted text.

It also doesn't cc in replies the addresses that were in to or cc of original
message, which may or may not be a good thing.



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

Re: HEADS UP: device name checking on device registration

[Matthew Jacob]

 Good workaround, still a nasty surprising bug.


On 2010-10-11, barbara wrote:

The panic is caused by:
g_dev_taste(): make_dev_p() failed (gp->name=ext2fs//, error=22)
as I have a linux partition (I swear, it's for my mom!) on the same machine.
As I don't care about that partition (being ext4 I can't even mount
it), is there any solution other then applying the patch after every
csup?

If you don't need ext2fs labels you can put the following line to
/boot/loader.conf as a workaround:

kern.geom.label.ext2fs.enable=0



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

Re: letting glabel recognise a media change

[Matthew Jacob]

Oh? Why?


I am not sure about this.
Because, e.g. I don't see an easy way to know that media is changed in scsi_cd
driver.  That is, without polling.  I don't consider polling to be an easy way 
for
a number of reasons.



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

Re: letting glabel recognise a media change

[Matthew Jacob]

 We already have a 'retaste' command for gmultipath at Panasas.


What announcement API would you like to add?

If something like that was in place, I assure you that things would
start to use it very quickly.


It doesn't have to be a heavy "announcement API". Basically, something 
would have to re-trigger GEOM tasting on existing devices, probably by 
marking them "spoiled" first.


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


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

Re: letting glabel recognise a media change

[Matthew Jacob]

 On 9/29/2010 2:45 PM, Andriy Gapon wrote:

on 30/09/2010 00:12 Alexander Best said the following:

hi there,

i wanted to ask if it would be possible to asjust glabel so that e.g. inserting
a new media into a dvd-drive gets recognised and glabel displays the lablel
right away.

Yes, of course, as soon as we have in kernel a programmatic way to know that
media as changed.
We don't have one right now...



What announcement API would you like to add?

If something like that was in place, I assure you that things would 
start to use it very quickly.

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

Re: DHCP server in base

[Matthew Jacob]

 I think not. You are given the opportunity to install prebuilt 
packages at install time, and with a modest amount of effort can install 
prebuilt packages afterwards.


IMO, such as it is, there should be *less* in the base system than there 
currently is and more in ports.

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

Re: ZFS v28 is ready for wider testing.

[Matthew Jacob]

Infiniband is currently being worked on, sponsored by Panasas, Isilon 
and someone else. It's coming along pretty well.


http://www.h-online.com/open/news/item/ZFS-as-a-Linux-kernel-module-1069056.html 



Too bad FreeBSD still lacks Infiniband support. Currently we use ZFS 
on FreeBSD and Infiniband on Linux. If Linux supports both, we will 
(be forced to) switch.


Cheers,
vt


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

Re: Call for Review: Suport for BIO_ORDERED bios

[Matthew Jacob]

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

igb issues

[Matthew Jacob]

Updated my kernel in the last day or so, and now get:

igb0: Watchdog timeout -- resetting
igb0: Queue(0) tdh = 342, hw tdt = 342
igb0: TX(0) desc avail = 1022,Next TX to Clean = 340
igb0: Link is Down
igb0: Link is up 1000 Mbps Full Duplex
igb0: Watchdog timeout -- resetting
igb0: Queue(6) tdh = 0, hw tdt = 0
igb0: TX(6) desc avail = 1022,Next TX to Clean = 0
igb0: Link is Down
igb0: Link is up 1000 Mbps Full Duplex
igb0: Watchdog timeout -- resetting
igb0: Queue(0) tdh = 2, hw tdt = 2
igb0: TX(0) desc avail = 1023,Next TX to Clean = 1
igb0: Link is Down
igb0: Link is up 1000 Mbps Full Duplex
igb0: Watchdog timeout -- resetting
igb0: Queue(6) tdh = 0, hw tdt = 0
igb0: TX(6) desc avail = 1020,Next TX to Clean = 0
igb0: Link is Down
igb0: Link is up 1000 Mbps Full Duplex
igb0: Watchdog timeout -- resetting
igb0: Queue(6) tdh = 0, hw tdt = 0
igb0: TX(6) desc avail = 1020,Next TX to Clean = 0
igb0: Link is Down
igb0: Link is up 1000 Mbps Full Duplex
igb0: Watchdog timeout -- resetting
igb0: Queue(0) tdh = 6, hw tdt = 6
igb0: TX(0) desc avail = 1022,Next TX to Clean = 4
igb0: Link is Down
igb0: Link is up 1000 Mbps Full Duplex

Anyone else seen this?


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

Re: lock recursion panic in cam_xpt.c

[Matthew Jacob]

On 6/28/2010 11:13 PM, Giorgos Keramidas wrote:

A recent CURRENT build from /head @ 209581 panics when I run
"cdrecord -scanbus" with the attached backtrace.  The culprit
seems to be the extra call fo xpt_lock_buses() added in head rev
208752, but I'm not sure if this is the real cause yet.

   


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

Re: lock recursion panic in cam_xpt.c

[Matthew Jacob]

On 6/28/2010 11:13 PM, Giorgos Keramidas wrote:

A recent CURRENT build from /head @ 209581 panics when I run
"cdrecord -scanbus" with the attached backtrace.  The culprit
seems to be the extra call fo xpt_lock_buses() added in head rev
208752, but I'm not sure if this is the real cause yet.

   


Thanks I'm already on it and working it.


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

Re: Deadlock with kgmon -p

[Matthew Jacob]

Yes. Using it as we speak.


"config -p" *seems* to be ok at the moment on 7 and -Current

Sean

   


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

Re: Deadlock with kgmon -p

[Matthew Jacob]

On 6/23/2010 10:53 AM, Sean Bruno wrote:

Trying to track down a nasty with regard to Xen stuff and am now
experiencing deadlocks on -current with a kernel configured with -g
-ppp.

The lockup will happen when I attempt to get the profiling data via
kgmon -p.

Not sure when this broke, but it's definitely broken in stable-7 as well
as -current.  Ideas?

   


Dunno about anyone else's experience, but I can't get amd64 stable-7 
kernels on forward to even finish booting if built with config -pp.


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

Re: kernel make noise with clang suppression

[Matthew Jacob]

On 6/10/2010 12:29 PM, Anonymous wrote:

Matthew Jacob  writes:

   

Comments? (yes, I know -fformat-extensions have just been added...)



diff -r ea5e09d013e7 sys/conf/kern.mk
--- a/sys/conf/kern.mk  Thu Jun 10 07:40:51 2010 -0700
+++ b/sys/conf/kern.mk  Thu Jun 10 11:35:50 2010 -0700
@@ -63,9 +67,15 @@
  # reserved for user applications.
  #
  .if ${MACHINE_ARCH} == "amd64"
+.if ${CC} == "clang"
+CFLAGS+=   -mcmodel=kernel -mno-red-zone \
+   -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
 

Shouldn't be there all supported -msse* by clang? I for one have ssse3
and sse4.1 that are not supported by basegcc.
   


SSE instructions are disabled in the kernel.

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

kernel make noise with clang suppression

[Matthew Jacob]

Comments? (yes, I know -fformat-extensions have just been added...)


diff -r ea5e09d013e7 sys/conf/kern.mk
--- a/sys/conf/kern.mk  Thu Jun 10 07:40:51 2010 -0700
+++ b/sys/conf/kern.mk  Thu Jun 10 11:35:50 2010 -0700
@@ -9,6 +9,10 @@
 .if ${CC} == "icc"
 #CWARNFLAGS=   -w2 # use this if you are terribly bored
 CWARNFLAGS=
+.elif ${CC} == "clang"
+CWARNFLAGS?=   -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
+   -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
+   -Wundef -Wno-pointer-sign
 .else
 CWARNFLAGS?=   -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
@@ -63,9 +67,15 @@
 # reserved for user applications.
 #
 .if ${MACHINE_ARCH} == "amd64"
+.if ${CC} == "clang"
+CFLAGS+=   -mcmodel=kernel -mno-red-zone \
+   -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
+   -msoft-float -fno-asynchronous-unwind-tables
+.else
 CFLAGS+=   -mcmodel=kernel -mno-red-zone \
-mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
-msoft-float -fno-asynchronous-unwind-tables
+.endif
 INLINE_LIMIT?= 8000
 .endif
 
diff -r ea5e09d013e7 sys/conf/kern.pre.mk
--- a/sys/conf/kern.pre.mk  Thu Jun 10 07:40:51 2010 -0700
+++ b/sys/conf/kern.pre.mk  Thu Jun 10 11:35:50 2010 -0700
@@ -30,7 +30,11 @@
 _MINUS_O=  -O2
 . endif
 . if ${MACHINE_ARCH} == "amd64"
+. if ${CC} == "clang"
+COPTFLAGS?=-O2 -pipe
+. else
 COPTFLAGS?=-O2 -frename-registers -pipe
+. endif
 . else
 COPTFLAGS?=${_MINUS_O} -pipe
 . endif
@@ -89,7 +93,7 @@
 
 CFLAGS=${COPTFLAGS} ${C_DIALECT} ${DEBUG} ${CWARNFLAGS}
 CFLAGS+= ${INCLUDES} -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h
-.if ${CC} != "icc"
+.if ${CC} != "icc" && ${CC} != "clang"
 CFLAGS+= -fno-common -finline-limit=${INLINE_LIMIT}
 CFLAGS+= --param inline-unit-growth=100
 CFLAGS+= --param large-function-growth=1000
diff -r ea5e09d013e7 sys/conf/kmod.mk
--- a/sys/conf/kmod.mk  Thu Jun 10 07:40:51 2010 -0700
+++ b/sys/conf/kmod.mk  Thu Jun 10 11:35:50 2010 -0700
@@ -111,7 +111,7 @@
 # for example.
 CFLAGS+=   -I@/contrib/altq
 
-.if ${CC} != "icc"
+.if ${CC} != "icc" && ${CC} != "clang"
 CFLAGS+=   -finline-limit=${INLINE_LIMIT}
 CFLAGS+= --param inline-unit-growth=100
 CFLAGS+= --param large-function-growth=1000
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ata panic: "mtx_lock of destroyed mutex"

[Matthew Jacob]

On 6/3/2010 12:43 AM, Alexander Motin wrote:

Matthew Jacob wrote:
   

Hmm. I just fixed that at Panasas, and I'm pretty sure that I gave the
patch to Alexander Motin to put in.
 

Do you mean one committed at r207221 or something else?

   


yes

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

Re: ata panic: "mtx_lock of destroyed mutex"

[Matthew Jacob]

Hmm. I just fixed that at Panasas, and I'm pretty sure that I gave the 
patch to Alexander Motin to put in.



I've been setting up an amd64 VirtualBox machine with the latest
9-CURRENT and got the following panic when booting it (another machine
updated and booting at the same time didn't panic):

ata1: WARNING - READ_TOC read data overrun 18>12
panic: mtx_lock of destroyed mutex @ /usr/src/sys/kern/kern_sema.c:79
cpuid = 0

with the following stack trace:

kdb_enter
panic
_mtx_lock_flags
_sema_post
ata_completed
taskqueue_run
intr_event_execute_handlers
ithread_loop
fork_exit
fork_trampoline

   


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

Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD

[Matthew Jacob]

FWIW, I support the import.

I don't think GCC is as bad as other people think it is, but I also have 
been gravely concerned of the the reduction of toolchains down close to 
one in our business. That in and of itself warrants supporting any 
viable alternative.

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

Re: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write

[Matthew Jacob]

   Matthew Fleming wrote:

  As an aside, this is a quad-core in one package CPU (an X3363). On both
this box and a similar one with an X5470, console messages continue to
print out after "the system has been halted - press any key to reboot" -
in particular, the shutdown makes a bunch of the "behind the scenes" man-
agement stuff like the virtual keyboard and monitor appear. Plugging or
unplugging USB devices will go through the whole deal of detecting and
making their service available.


Oops, youre right that other CPUs are running.

The stop_cpus() call is only made if kdb is entered.  doadump() is called out o
f boot() which comes later.  At Isilon weve been running with a patch that does
 stop_cpus() pretty close to the front of panic(9).

As an design decision it seems reasonable to call stop_cpus() early in panic(9)
 simply because most causes for panic means something unexpected, and the soone
r the other CPUs arent running the more likely it is that they dont do more dam
age, leaving the system in a more useful state for dump or {g,d}db analysis.  T
his should be done before dump or entering kdb.

Im ccing -current@ since I would like a small discussion of moving the stop_cpu
s() to earlier in panic.  If this change is agreeable I can roll up a patch and
 test it on CURRENT.  Im not sure yet how much of the other panic-related chang
es we have made at Isilon would be required.
  

   Work along this lines has been done at Panasas. We were planning on
   put it back to the community. There turns out to be lots of edge cases
   by changing this that we're still sorting thru.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: mpt(4) MPI_EVENT_IR_RESYNC_UPDATE

[Matthew Jacob]

pluknet wrote:
Seems good to me- why not trhow it freebsd-scsi? if nobody says no, I'll 
put it in



--- RELENG_7_3/src/sys/dev/mpt/mpt_cam.c2010-03-02
15:38:13.0 +0300
+++ RELENG_7_3.ours/src/sys/dev/mpt/mpt_cam.c   2010-04-21
19:31:00.0 +0400
@@ -2564,6 +2564,12 @@ mpt_cam_event(struct mpt_softc *mpt, req
CAMLOCK_2_MPTLOCK(mpt);
break;
}
+   case MPI_EVENT_IR_RESYNC_UPDATE:
+   {
+   uint8_t resync = (data0 >> 16) & 0xff;
+   mpt_prt(mpt, "IR resync update %d completed\n", resync);
+   break;
+   }
case MPI_EVENT_EVENT_CHANGE:
case MPI_EVENT_INTEGRATED_RAID:
case MPI_EVENT_SAS_DEVICE_STATUS_CHANGE:

Another way - just hide such event since mptutil displays rebuild progress.

  


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

Re: HEADS UP: SUJ Going in to head today

[Matthew Jacob]

Jeff Roberson wrote:

On Sun, 25 Apr 2010, Alex Keda wrote:


try in single user mode:

tunefs -j enable /
tunefs: Insuffient free space for the journal
tunefs: soft updates journaling can not be enabled

tunefs -j enable /dev/ad0s2a
tunefs: Insuffient free space for the journal
tunefs: soft updates journaling can not be enabled
tunefs: /dev/ad0s2a: failed to write superblock


There is a bug that prevents enabling journaling on a mounted 
filesystem. So for now you can't enable it on /.  I see that you have 
a large / volume but in general I would also suggest people not enable 
suj on / anyway as it's typically not very large.  I only run it on my 
/usr and /home filesystems.


I will send a mail out when I figure out why tunefs can't enable suj 
on / while it is mounted read-only.


Thanks,
Jeff


One of the attractions for suj would be for appliancized FreeBSD which 
now has to set 'fsck -y' for power fail/resets- and this means root as well.




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

Re: Switchover to CAM ATA?

[Matthew Jacob]

Short opinion from me: Yes, for HEAD. Not MFC'able. It's too major a 
change for that.

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

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

[Matthew Jacob]

On 04/20/2010 03:44 PM, Maxim Sobolev wrote:

Maxim Sobolev wrote:

Maybe try adding

hint.atkbdc.0.disabled="1"
hint.atkbd.0.disabled="1"

to /boot/device.hints?  That has reportedly removed minute-long boot 
delays on some Nehalem machines.


No, that have not helped at all. I measured the delay - it's about 6
minutes from boot command to the first "smap" message. Do you or 
anybody else have other ideas?


Actually it helped, thank you very much! The problem was that I have 
had my hints compiled into the kernel itself.


Me too!

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

Re: panic: deadlkres: possible deadlock detected

[Matthew Jacob]

On 04/19/2010 08:03 AM, Attilio Rao wrote:

2010/4/19 Erik Cederstrand:
   

Hi

I'm testing ClangBSD in a VirtualBox client and ran into a panic on the client, 
but I don't think it's clang-related. I haven't tried kernel debugging before. 
I tried getting a backtrace as described in 
http://old.nabble.com/Re%3A-ia64--%3E-panic%3A-deadlkres%3A-possible-deadlock-detected-for-0xe0001187d880%2C-blocked-for-1801437-ticks-p28123802.html
 and this i the result:

http://tinypic.com/r/2llegza/5

Any pointers on ho to debug this further?
 

I think we have to bless getblk. However your system may have got
buffers shortage due to bufdaemon deficiencies.

Are you using 8.0 or current?

Attilio


   

I've seen this in -current as of yesterday

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

Re: Sleeping on "isp_mboxwaiting" with the followingnon-sleepablelocks held:

[Matthew Jacob]

So you're theory here is that that all code that may be necessary to
start I/O but could take a while should be done out of band. That's a
reasonable response. The only problem is that you sometimes cannot
easily tell if things like timeout driven recovery/restart can be used.

The basic difference here I would guess might be that if I needed to do,
say, FC loop bringup or chip reprogramming after a reset in the isp
driver, I should try and do it off of the worker thread so I neither
slept nor polled from isp_start and always returned right away. I'll
start thinking about that.

-matt


On Thu, 23 Oct 2003, Poul-Henning Kamp wrote:

> In message <[EMAIL PROTECTED]>, Matthew Jacob writes:
>
> >[1]: by 'sleep', I mean if I do *my* locking right, I should be able to
> >yield the processor and wait for an event (an interrupt in this case).
>
> Not so when your device driver is entered through the devsw->strategy()
> function, since that [cw]ould deadlock the entire disk-I/O system until
> you return back up.
>
> Ideally, devsw->strategy() should just queue the request and return
> immediately.  In a world where context switches were free, scheduling
> a task_queue to run foostart() (if necessary) would be the way to
> do things.
>
> Most drivers call their own foostart() from strategy(), and as long
> as foostart() does not go on long-term vacation, this is also OK,
> poking a few registers, doing a bit of BUSDMA work is acceptable.
>
> But sleeping is not OK, mostly because a lot of sleeps may not
> properly terminate in case of a memory shortage, and the way we
> clear up a memory shortage is to page something out, and to page
> something out we need to issue disk I/O, but somebody is holding
> that hostage by sleeping in a driver...
>
> I will conceede that there are a certain small class of legitimate
> sleeps that could be performed, unfortunately we can not automatically
> tell an OK sleep from a not OK sleep, and therefore the decision
> was to ban all sleeps, until such time as we had a case of something
> that could not be (sensibly) done without the ability to sleep.
>
> I realize that in this case, you're sitting below CAM and scsi_??.c
> and have very little say in what happens between devsw->strategy()
> and your driver.
>
> As I read the original report, this is a case of error-handling.
> Considering how long time error handling often takes and how
> imperfect results one gets a lot of the time, error handling
> should never strategy() sleep or take a long time, since that
> will eliminates the chances that the system can flush dirty data
> to other devices as part of a shutdown or panic.
>
> At some point soon, I plan to start measuring how much time
> drivers spend in their strategy() routine and any offenders
> will be put on notice because this is a brilliant way to hose
> our overall system performance.  I'm not going to set any
> specific performance goal at this time, but I think we can
> agree that more than one millisecond is way over the line.
>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Sleeping on "isp_mboxwaiting" with the followingnon-sleepablelocks held:

[Matthew Jacob]

It isn't the "cannot sleep from geometry calls" that is twitting me a
bit, it's the "I cannot tell at my call depth in the stack whether some
dork above can't tolerate a sleep[1]". If I've missed some usage point
with the SMP stuff that I *can* tell this with ease, enlighten me.

-matt


[1]: by 'sleep', I mean if I do *my* locking right, I should be able to
yield the processor and wait for an event (an interrupt in this case). A
yield might not actually do anything but call idle- if that's what is
appropriate. There are several things meant by "cannot sleep"- one is
deadlock avoidance and the other is thread of execution ordering. A
blanket "cannot sleep" sometimes can mean just plain poor design. I
don't really mean to be inflammatory here but I kinda *am* raising my
eyebrows here with a polite query of "are you sure you really want to do
this this way?".

I mean, this particular instance isn't a big deal. Instead of waiting
for a mailbox event to clear I'll poll it, doing nothing useful
otherwise. It's a rare event, but it makes the system sluggish. There
are alternative designs that I could take at this level that would do
neither, but add greatly to code complexity at this level. No big deal,
but still...




On Wed, 22 Oct 2003, Poul-Henning Kamp wrote:

> In message <[EMAIL PROTECTED]>, "Matthew Jacob" writes:
>
> >Well, I don't agree with the design here, but it is what it is. I'll
> >make the change that you've added a requirement for.
>
> This is nothing new, but it is new that we can and do enforce it.
>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Sleeping on "isp_mboxwaiting" with the followingnon-sleepablelocks held:

[Matthew Jacob]

> On Tue, Oct 21, 2003 at 02:30:21PM -0700, Matthew Jacob wrote:
> > So? How about some details and context?
>
> Um, what more "details and context" do you need?  I provided the log
> of the system activity (specifically, media errors and swap read
> failure) leading up to the panic, and the ddb backtrace.

I, and all device driver writers, typically need to know:

a) software version- it seemed to be post 5.0, but a window of date
is always helpful?

b) alpha, but what attached hardware?

c) system state. It *appears* that you were booting from the messages,
but stating so would be helpful.

> > I thought was told that being able to use locks in HBAs is fine. I had
> > them on for a while, and then had them off. I turned them on again over
> > a month ago. I'm somewhat surprised to see that a problem shows up now.
>
> This was apparently triggered by the disk failure, which is not a
> commonly exercised code path.

Yes. After a bit more thought I now see why. A check condition will
force a renegotiation. Too bad this will now be a polled operation.

> > *I* do the right thing with locks, IMO. I hold them in my module when I
> > enter and release them if/when I leave. Seeing a lock held by some
> > random caller causing me to blow up to me seems to be a hole in the
> > architecture, but I'd be the first to admit that I hardly am up to date
> > on what the rules of the road are now so such an opinion is
> > ill-informed.
> >
> > Comment out ISP_SMPLOCK in isp_freebsd.h. If the problem goes away,
> > we'll make the change back again.
>
> I'll do what I can.
>

That's okay. PHK pointed out why he's now forced the issue, so I've
accommodated it.


> > -matt
> >
> > p.s.: you have *way* more issues here than locking- you've a bad disk.
>
> I know, but the system shouldn't blow up with a lock assertion in this
> failure mode.
>
> > Anyway, isn't alpha desupported?
>
> No.
>

Hmm- I thought the tenor of a recent thread was this.

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

RE: Sleeping on "isp_mboxwaiting" with the following non-sleepablelocks held:

[Matthew Jacob]

Well, I don't agree with the design here, but it is what it is. I'll
make the change that you've added a requirement for. 

-Original Message-
From: Poul-Henning Kamp [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 21, 2003 2:46 PM
To: [EMAIL PROTECTED]
Cc: 'Kris Kennaway'; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Sleeping on "isp_mboxwaiting" with the following
non-sleepablelocks held: 


In message <[EMAIL PROTECTED]>, "Matthew Jacob"
writes:
>So? How about some details and context?
>
>I thought was told that being able to use locks in HBAs is fine. I had 
>them on for a while, and then had them off. I turned them on again over

>a month ago. I'm somewhat surprised to see that a problem shows up now.
>
>*I* do the right thing with locks, IMO. I hold them in my module when I

>enter and release them if/when I leave. Seeing a lock held by some 
>random caller causing me to blow up to me seems to be a hole in the 
>architecture, but I'd be the first to admit that I hardly am up to date

>on what the rules of the road are now so such an opinion is 
>ill-informed.

The lock held in this case, is not "some random caller", that is a mutex
held specifically to expose device drivers which try to sleep in their
->strategy() function.

You cannot sleep in the strategy() function because that would hold op
I/O, and therefore likely lead to deadlock.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by
incompetence.

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

RE: Sleeping on "isp_mboxwaiting" with the following non-sleepablelocks held:

[Matthew Jacob]

So? How about some details and context?

I thought was told that being able to use locks in HBAs is fine. I had
them on for a while, and then had them off. I turned them on again over
a month ago. I'm somewhat surprised to see that a problem shows up now.

*I* do the right thing with locks, IMO. I hold them in my module when I
enter and release them if/when I leave. Seeing a lock held by some
random caller causing me to blow up to me seems to be a hole in the
architecture, but I'd be the first to admit that I hardly am up to date
on what the rules of the road are now so such an opinion is
ill-informed.

Comment out ISP_SMPLOCK in isp_freebsd.h. If the problem goes away,
we'll make the change back again.

-matt

p.s.: you have *way* more issues here than locking- you've a bad disk.
Anyway, isn't alpha desupported?

-Original Message-
From: Kris Kennaway [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 21, 2003 9:06 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Sleeping on "isp_mboxwaiting" with the following
non-sleepablelocks held:


This happened to me just now on alpha:

(da0:isp0:0:0:0): Retrying Command (per Sense Data)
(da0:isp0:0:0:0): READ(06). CDB: 8 5 f 30 10 0
(da0:isp0:0:0:0): CAM Status: SCSI Status Error
(da0:isp0:0:0:0): SCSI Status: Check Condition
(da0:isp0:0:0:0): MEDIUM ERROR info:50f30 asc:11,0
(da0:isp0:0:0:0): Unrecovered read error field replaceable unit: e4
actual retry count: 257
(da0:isp0:0:0:0): Retrying Command (per Sense Data)
swap_pager: indefinite wait buffer: device: da0b, blkno: 331568, size:
8192
(da0:isp0:0:0:0): READ(06). CDB: 8 5 f 30 10 0
(da0:isp0:0:0:0): CAM Status: SCSI Status Error
(da0:isp0:0:0:0): SCSI Status: Check Condition
(da0:isp0:0:0:0): MEDIUM ERROR info:50f30 asc:11,0
(da0:isp0:0:0:0): Unrecovered read error field replaceable unit: e4
actual retry count: 257
(da0:isp0:0:0:0): Retries Exhausted
swap_pager: I/O error - pagein failed; blkno 331568,size 8192, error 5
vm_fault: pager read error, pid 90537 (aspell)
Sleeping on "isp_mboxwaiting" with the following non-sleepablelocks
held: exclusive sleep mutex g_xdown r = 0 (0xfe0006bfdc78) locked @
/a/asami/portbuild/alpha/src-client/sys/geom/geom_io.c:345
witness_warn
Stopped at  Debugger+0x38:  zapnot  v0,#0xf,v0  
db> trace
Debugger() at Debugger+0x38
witness_warn() at witness_warn+0x284
msleep() at msleep+0xa8
isp_mbox_wait_complete() at isp_mbox_wait_complete+0x94
isp_mboxcmd() at isp_mboxcmd+0x258
isp_update_bus() at isp_update_bus+0x2f0
isp_update() at isp_update+0x54
isp_start() at isp_start+0x208
isp_action() at isp_action+0x1bc
xpt_run_dev_sendq() at xpt_run_dev_sendq+0x23c
xpt_action() at xpt_action+0x2a0
dastart() at dastart+0x220
xpt_run_dev_allocq() at xpt_run_dev_allocq+0xf0
xpt_schedule() at xpt_schedule+0xc0
dastrategy() at dastrategy+0x70
g_disk_start() at g_disk_start+0x1ec
g_io_schedule_down() at g_io_schedule_down+0x234
g_down_procbody() at g_down_procbody+0x5c
fork_exit() at fork_exit+0x100
exception_return() at exception_return
--- root of call graph ---

Kris

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

Re: alpha tinderbox failure

[Matthew Jacob]

I already know this- I just hadn't checked it in a change because I was
trying to get one of my alphas current. Sam Leffler brought it to my
attention the other day.

This is for LINT, btw.

Also- is casting to 'long' for bus_addr_t and bus_size_t the best idea?
Shouldn't it be cast to the maximum width integer (long long)?

-matt



On Wed, 1 Jan 2003, Mike Barcroft wrote:

> Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> > ===> vinum
> > "Makefile", line 4453: warning: duplicate script for target "geom_bsd.o" ignored
> > cc1: warnings being treated as errors
> > /h/des/src/sys/dev/isp/isp_pci.c: In function `tdma_mkfc':
> > /h/des/src/sys/dev/isp/isp_pci.c:1543: warning: unsigned int format, different 
>type arg (arg 5)
> > /h/des/src/sys/dev/isp/isp_pci.c:1543: warning: int format, different type arg 
>(arg 6)
> > /h/des/src/sys/dev/isp/isp_pci.c:1572: warning: unsigned int format, different 
>type arg (arg 6)
> > /h/des/src/sys/dev/isp/isp_pci.c:1572: warning: unsigned int format, different 
>type arg (arg 7)
> > *** Error code 1
>
> Proposed fix:
>
> %%%
> Index: isp_pci.c
> ===
> RCS file: /work/repo/src/sys/dev/isp/isp_pci.c,v
> retrieving revision 1.89
> diff -u -r1.89 isp_pci.c
> --- isp_pci.c 11 Oct 2002 17:28:01 -  1.89
> +++ isp_pci.c 1 Jan 2003 14:56:25 -
> @@ -1538,9 +1538,10 @@
>   cto->rsp.m0.ct_dataseg[cto->ct_seg_count].ds_count =
>   dm_segs[segcnt].ds_len;
>   cto->rsp.m0.ct_xfrlen += dm_segs[segcnt].ds_len;
> - isp_prt(isp, ISP_LOGTDEBUG1, "isp_send_ctio2: ent0[%d]0x%x:%d",
> - cto->ct_seg_count, dm_segs[segcnt].ds_addr,
> - dm_segs[segcnt].ds_len);
> + isp_prt(isp, ISP_LOGTDEBUG1,
> + "isp_send_ctio2: ent0[%d]0x%lx:%lu",
> + cto->ct_seg_count, (unsigned long)dm_segs[segcnt].ds_addr,
> + (unsigned long)dm_segs[segcnt].ds_len);
>   }
>
>   while (segcnt < nseg) {
> @@ -1567,9 +1568,10 @@
>   crq->req_dataseg[seg].ds_base = dm_segs[segcnt].ds_addr;
>   crq->req_dataseg[seg].ds_count = dm_segs[segcnt].ds_len;
>   isp_prt(isp, ISP_LOGTDEBUG1,
> - "isp_send_ctio2: ent%d[%d]%x:%u",
> + "isp_send_ctio2: ent%d[%d]%lx:%lu",
>   cto->ct_header.rqs_entry_count-1, seg,
> - dm_segs[segcnt].ds_addr, dm_segs[segcnt].ds_len);
> + (unsigned long)dm_segs[segcnt].ds_addr,
> + (unsigned long)dm_segs[segcnt].ds_len);
>   cto->rsp.m0.ct_xfrlen += dm_segs[segcnt].ds_len;
>   cto->ct_seg_count++;
>   }
> %%%
>
> Best regards,
> Mike Barcroft
>


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

Re: should this get an UPDATING entry?

[Matthew Jacob]

Sure- just asking/checking. Things sort surprised/astonished me. 

On Mon, 14 Oct 2002, M. Warner Losh wrote:

> In message: <Pine.BSF.4.21.0210142003480.79278-10@beppo>
>     Matthew Jacob <[EMAIL PROTECTED]> writes:
> : ld: target elf32-i386-freebsd not found
> : And these are with i386 systems that are installworld'd within the last
> : couple weeks.
> 
> This is a consequence of updating the build tools.  Likely it should
> have an UPDATING entry, but I have no lock on UPDATING, so someobedy
> else will have to do it (I'm ENOTIME).
> 
> Warner
> 


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

Re: should this get an UPDATING entry?

[Matthew Jacob]

No, buildkernel is sort of fine- doesn't work for partial trees.

I just missed the UPDATING about a toolchain upgrade. I also figured out
how to get myself out of the partial tree mess I was in by dropping back
on the ldscript so I could ensure a new kernel prior to building world.


> On Mon, Oct 14, 2002 at 08:04:47PM -0700, Matthew Jacob wrote:
> > 
> > Attempts to build kernels today fail for me with:
> > 
> > h ../../../conf/newvers.sh MJCURRENT
> > cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs
> > -Wstric
> > t-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
> > -fforma
> > t-extensions -ansi -g -nostdinc -I-  -I. -I../../.. -I../../../dev
> > -I../../../co
> > ntrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include
> > opt_global.h -fn
> > o-common  -mpreferred-stack-boundary=2 -ffreestanding -Werror  vers.c
> > linking kernel.debug
> > ld: target elf32-i386-freebsd not found
> > 
> > 
> > 
> > And these are with i386 systems that are installworld'd within the last
> > couple weeks.
> 
> Well, this is what the 'buildkernel' target was invented for (kernel
> builds after toolchain upgrades), and why it's the documented standard
> way to build kernels after a source upgrade.  Do you have this problem
> when you use buildkernel?
> 
> Kris
> 


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

should this get an UPDATING entry?

[Matthew Jacob]

Attempts to build kernels today fail for me with:

h ../../../conf/newvers.sh MJCURRENT
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs
-Wstric
t-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-fforma
t-extensions -ansi -g -nostdinc -I-  -I. -I../../.. -I../../../dev
-I../../../co
ntrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include
opt_global.h -fn
o-common  -mpreferred-stack-boundary=2 -ffreestanding -Werror  vers.c
linking kernel.debug
ld: target elf32-i386-freebsd not found



And these are with i386 systems that are installworld'd within the last
couple weeks.




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

Re: Any problems with increaseing the dump(8) block size?

[Matthew Jacob]

No. Don't change this- people are very well attuned to using an argument
to change it and all your change will do is catch the unwary and
possibly break binary compat on apps that define records based off of
NTREC.


On Wed, 11 Sep 2002, David O'Brien wrote:

> I'd like to make this commit to get better performance on today's
> streaming tape drives.  It seems my DLT drive doesn't stream well with
> the default block size of '10'.
> 
> 
> Index: include/protocols/dumprestore.h
> ===
> RCS file: /home/ncvs/src/include/protocols/dumprestore.h,v
> retrieving revision 1.10
> diff -u -r1.10 dumprestore.h
> --- include/protocols/dumprestore.h   17 Jul 2002 02:03:19 -  1.10
> +++ include/protocols/dumprestore.h   19 Jul 2002 05:30:39 -
> @@ -56,7 +56,7 @@
>   * or TS_ADDR record. Note that it must be a power of two.
>   */
>  #define TP_BSIZE 1024
> -#define NTREC10
> +#define NTREC64
>  #define HIGHDENSITYTREC  32
>  #define TP_NINDIR(TP_BSIZE/2)
>  #define LBLSIZE  16
> 


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

Re: HEADS UP: GCC 3.2 in progress

[Matthew Jacob]

Thank you.

Let's move on.


On Sun, 1 Sep 2002, Scott Long wrote:

> On Sun, Sep 01, 2002 at 05:12:43PM -0700, Matthew Jacob wrote:
> > 
> > 
> > [...]
> > 
> > 
> > Of course. And being accused of 'trolling' is also a learning
> > experience.
> 
> Ok, I apologize for calling you a 'troll'.  I certainly didn't mean
> it in the context of what's going on in other mailing lists, and it
> probably wasn't appropriate in any context.  Please note, hovever,
> that many of the concerns that you've brought up in this thread
> have been *heavily* discussed in the public mailing list over the
> past month.  Just two weeks ago there was a heated discussion over
> whether to import gcc 3.2, or leapfrog it and wait for 3.3.  There
> have been many more discussions like it.
> 
> Scott
> 


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

Re: HEADS UP: GCC 3.2 in progress

[Matthew Jacob]

> Matthew Jacob wrote:
> > 
> > > > Yes, as best as I can.
> > > >
> > > > But I didn't see a GCC 3.2 import on anyone's bullet list.
> > >
> > > To quote Robert Watson:
> > >
> > > > My list basically consists of:
> > > > General
> > > >   - GEOM as default storage management on all platforms, related
> > > > dependencies
> > > >   - Switch in sysinstall to easily turn on ufs2
> > > >   - Final resolution of any perl removal related problems
> > > >   - rcNG as the default boot mechanism
> > > >   - New gcc?
> > 
> > Small bullet item.
> 
> Alexander is new at working within our operation so we should give him some
> room to get fully up to speed.  I'm glad that somebody other than me is
> dealing with this. :-)
> 
> We really did need this to be done before 5.0-R as the gcc prerelease was a
> bit of a showstopper when it cannot compile a whole bunch of 'must have'
> packages.  (eg: KDE etc)
> 
> Lets say that developer awareness of the pending import should have been
> dealt with better and chalk it up as a learning experience.




Of course. And being accused of 'trolling' is also a learning
experience.
> 


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

Re: HEADS UP: GCC 3.2 in progress

[Matthew Jacob]

> > Yes, as best as I can.
> >
> > But I didn't see a GCC 3.2 import on anyone's bullet list.
>
> To quote Robert Watson:
>
> > My list basically consists of:
> > General
> >   - GEOM as default storage management on all platforms, related
> > dependencies
> >   - Switch in sysinstall to easily turn on ufs2
> >   - Final resolution of any perl removal related problems
> >   - rcNG as the default boot mechanism
> >   - New gcc?

Small bullet item.


> Matt, please stop trolling.

That is an offensive assumption. It wasn't trolling- nor was it
intended as such. Argh. Why do I bother? Screw it.



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

Re: HEADS UP: GCC 3.2 in progress

[Matthew Jacob]

>
> Umm. Are you reading your -developers mail?

Yes, as best as I can.

But I didn't see a GCC 3.2 import on anyone's bullet list.


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

Re: HEADS UP: GCC 3.2 in progress

[Matthew Jacob]

These arguments are all quite familiar- I'm not really moved one way or
the other.

The point here is that major changes need to be very visible on a
product's schedule. You can argue that it isn't a major change- but I'd
assert that any toolchain change *is* a major change.

I'm *not* arguing against the change- I don't know nearly enough to have
an opinion. I *am* commenting on how major changes coming in with little
notice often add substantial delays. Furthermore, lack of putting such
changes up in such a fashion that a folks in distributed development
environment can then adequately plan/protect themselves so *their* stuff
is protected is also an issue.

Look- if Alexander hadn't said anything, I *probably* wouldn't have
noticed.  However, he felt that this was important enough to tease
people with a "10 minutes until the bombs start falling" mail message.
It's not unreasonable to raise this as an issue.

Or if you think it *is* unreasonable, we can go offline so I can discuss
it.

-matt


On Sun, 1 Sep 2002, Peter Wemm wrote:

> Matthew Jacob wrote:
>
> > This would have been a firing offense at several companies I've worked
> > at. It's not unreasonable to take a lesson from *why* these things are
> > firing offenses and start to raise queries. I've done so. Duty is done.
> > Go back to sleep.
>
> Would you rather that we ship with a known broken prerelease compiler?
>
> Would you rather that we changed from 3.1-prerelease to 3.1.1-release?
>
> gcc-3.2 *is* 'gcc-3.1.1 + ABI bugfix'.  They renamed the 3.1 branch to 3.2.
> All future 3.1.x releases will be called 3.2.x.
>
> Cheers,
> -Peter
> --
> Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> "All of this is for nothing if we don't go to the stars" - JMS/B5
>
>


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

oh, btw..

[Matthew Jacob]

I personally always get a bit more concerned about compiler upgrades. I
can and do protect myself from errant /usr/src/sys changes, but
everthing else is cvsup based for me, so buildworlds really do need to
work well for me.




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

Re: HEADS UP: GCC 3.2 in progress

[Matthew Jacob]

I should note that I'm raising more of a flag than normal.

This would have been a firing offense at several companies I've worked
at. It's not unreasonable to take a lesson from *why* these things are
firing offenses and start to raise queries. I've done so. Duty is done.
Go back to sleep.

On Mon, 2 Sep 2002, Martin Blapp wrote:

>
> Hi,
>
> > totally wrong, and this won't break things. I'm just a bit startled that
> > this appears out of nowhere (I sure don't recall it being discussed) and
> > just happens, with 10 minutes warning.
>
> The 2.95.3 -> 3.1 prerelease upgrade was a big step.
>
> 3.1 prerelease -> 3.2 is a little step which fixes bugs, make
> kde working (gif support) again, fixes X11 and mozilla ports.
>
> > I don't mean to be hypercritical here, but I feel that it's fair,
> > considering people are starting to really whine about how late 5.0
> > actually *is* at this point, to begin to ask not even the *hard*
> > questions, but medium firm questions about "gee, is this trip *really*
> > necessary?"
>
> I think yes. Gcc 3.1 prerelease had some nasty bugs.
>
> Martin
>
>


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

Re: HEADS UP: GCC 3.2 in progress

[Matthew Jacob]

On Sun, 1 Sep 2002, Alexander Kabaev wrote:

> On Sun, 1 Sep 2002 14:50:50 -0700 (PDT)
> Matthew Jacob <[EMAIL PROTECTED]> wrote:
>
> > From recent experience it is my estimation that a gcc upgrade sets 5.0
> > development back a month (that is, the last GCC upgrade kept *me* from
> > working productively for around a month due to various this thats and
> > the others). If that's what people want, that's fine.  I could also be
> > totally wrong, and this won't break things. I'm just a bit startled
> > that this appears out of nowhere (I sure don't recall it being
> > discussed) and just happens, with 10 minutes warning.
>
> Matt, the change was discussed several times on developers@, so this
> import is hardly 'out of nowhere'.

I sure didn't see anything on the recent 5.0 schedule about this.

Like I said- this is not meant to be hypercritical. Let's assume that
I'm not paying that close attention, like a *lot* of developers to the
flood of mail. There might have been a note about "new compiler import"
on the recent 5.X schedule changes that surely would catch the eye.

>
> > This is, IMO, why FreeBSD is not going to be very successful. You
> > cannot just make major toolchain changes w/o at least *some* belief
> > that this is going to be done well. Did you do a dryrun with the
> > import before checking things in?
>
> About five buildworlds on i386 and two on Alpha. Does that count as dry
> runs?

Surely they do. Did somebody in ia64 && sparc && ppc get a headsup?



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

Re: HEADS UP: GCC 3.2 in progress

[Matthew Jacob]

On Sun, 1 Sep 2002, David O'Brien wrote:

> On Sun, Sep 01, 2002 at 02:34:12PM -0700, Matthew Jacob wrote:
> > So, what is it about gcc 3.2 that's so important, considering that we
> > wanted to do a real 5.0 release within 2 months?
>
> This is really 3.1.1 -- so it is a minor point release.  3.2 fixes a bug
> that changes the API so it couldn't be fixed in 3.1.1.  Otherwise they
> are the same compilers.
>
> That said, we don't want to be stuck with a stale compiler for all of
> 5.x.  I highly recomend we use 3.3 in our 5.0-R.
>

All that's good, but is this on the roadmap of RE && core so that
adequate destabilization time is accounted for?



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

Re: HEADS UP: GCC 3.2 in progress

[Matthew Jacob]

Well, actually, I *wasn't* asking for an upgrade.

>From recent experience it is my estimation that a gcc upgrade sets 5.0
development back a month (that is, the last GCC upgrade kept *me* from
working productively for around a month due to various this thats and
the others). If that's what people want, that's fine.  I could also be
totally wrong, and this won't break things. I'm just a bit startled that
this appears out of nowhere (I sure don't recall it being discussed) and
just happens, with 10 minutes warning.

This is, IMO, why FreeBSD is not going to be very successful. You cannot
just make major toolchain changes w/o at least *some* belief that this
is going to be done well. Did you do a dryrun with the import before
checking things in?

I don't mean to be hypercritical here, but I feel that it's fair,
considering people are starting to really whine about how late 5.0
actually *is* at this point, to begin to ask not even the *hard*
questions, but medium firm questions about "gee, is this trip *really*
necessary?"

-matt


On Sun, 1 Sep 2002, Alexander Kabaev wrote:

> On Sun, 1 Sep 2002 14:34:12 -0700 (PDT)
> Matthew Jacob <[EMAIL PROTECTED]> wrote:
>
> > So, what is it about gcc 3.2 that's so important, considering that we
> > wanted to do a real 5.0 release within 2 months?
>
> Some well known problem present in our current GCC snapshot appear to be
> fixed in 3.2.
>
> GCC 3.2 is using vendor-independent C++ ABI. Assuming they got it right
> this time, this will allow us to upgrade to 3.3 more painlessly later.
>
> People who were asking for an upgrade got what they deserved :)
>
> --
> Alexander Kabaev
>


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

Re: HEADS UP: GCC 3.2 in progress

[Matthew Jacob]

So, what is it about gcc 3.2 that's so important, considering that we
wanted to do a real 5.0 release within 2 months?


On Sun, 1 Sep 2002, Alexander Kabaev wrote:

>   I will import GCC 3.2 snapshot from the top of FSF gcc-3_2-branch in
> about ten minutes. This task should not take long to complete, but since
> this is the first time I am doing it, there is good possibility of
> unexpected delays, so please be patient.
>
>   Please respond immediately if you feel that I need to hold the import
> for some reason.
>
> --
> Alexander Kabaev
>


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

for UPDATING

[Matthew Jacob]

to upgrade from FreeBSD-current previous to GCC3.1 (circa April, May) to the
current top of tree, a 'make -k world' may be necessary to skip over an
(apparently unnecessary) broken gperf build.

This has been confirmed twice for alpha and once for i386.



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

problem with new eventhandler.h (fwd)

[Matthew Jacob]

[ was on hackers, no reply ]

And this has also affected iconv.h.

I would suggest very strongly that this must be backed out.

-- Forwarded message --
Date: Thu, 23 May 2002 15:17:32 -0700 (PDT)
From: Matthew Jacob <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: problem with new eventhandler.h



I believe that the new eventhandler.h is depending on newer compiler
tools. This makes it somewhat difficult to bootstrap. Can you make it so it
*doesn't* require gcc3 installed?

cam/cam_xpt.c
In file included from ../../../sys/conf.h:48,
 from ../../../cam/cam_xpt.c:38:
../../../sys/eventhandler.h:95: badly punctuated parameter list in `#define'
../../../sys/eventhandler.h:137: badly punctuated parameter list in `#define'
*** Error code 1






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

fwiw: nfs loopback still broken in -current

[Matthew Jacob]

NFS loopback mounts still periodically gets hung with:

ypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -ansi -g -nostdinc -I-  -I. -I../../.. -I../../../dev
-I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I/usr/include
-D_KERNEL -ffreestanding -include opt_global.h -fno-common   -mno-fp-regs
-ffixed-8 -Wa,-mev56   vers.c
linking kernel.debug
nfs server yorp:/space/compiles: not responding 10 > 9
.


This has been the case for months and months.

-matt



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

Re: BUS_SPACE_MAXSIZE & isp driver.

[Matthew Jacob]

Now, Mike, play nice...


On Fri, 5 Apr 2002, Michael Smith wrote:

> > For ISA, this ends up being a 16M limit; I think the 2G limit
> > on Alpha is because the limit is 32 bits, but there is some
> > signed math that should be unsigned.
> 
> No, Terry, it has to do with the PCI bridge's translation mapping 
> hardware, and if we supported it (which we don't seem to) then the 
> problem would all just go away.
> 
> Please, give up with the guessing already. 8)
> 
> -- 
> To announce that there must be no criticism of the president,
> or that we are to stand by the president, right or wrong, is not
> only unpatriotic and servile, but is morally treasonable to 
> the American public.  - Theodore Roosevelt
> 
> 
> 


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

Re: BUS_SPACE_MAXSIZE & isp driver.

[Matthew Jacob]

On Thu, 4 Apr 2002, Justin T. Gibbs wrote:

> >> a single buffer.  I never realized that there was such controversy
> >> over this value... it was just put in so that I could have something
> >> for the non-GNUC case.
> >
> >Yeah, but, uh, it'll blow up in one's face.
> 
> If it gets compiled, I suppose so.
> 
> >The question I have is what *should* we be using? Should BUS_SPACE_MAXSIZE be
> >bumped up so that any dma allocation we attempt for a platform will fit within
> >it?
> 
> I think it should go away.  We should malloc space to hold the segments in
> the leaf dma tags and base that size on the information in the tag.  The
> segments would only be allocated on the first dma_map_create call on a
> tag so that intermediate (i.e. non-leaf) tags never have this stuff allocated.

But lacking that, what does it mean?

> 
> >I mean, it's used in a lot of places, so clearly it must mean something,
> >right? What are the semantics here?
> 
> Is it really used in a lot of places?

About 40 files. But everyone has copied them.

>  I've always used the "bit sized"
> versions of MAXSIZE in my driver code, never the ambiguous one. 8-)
> 
> --
> Justin
> 


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

Re: BUS_SPACE_MAXSIZE & isp driver.

[Matthew Jacob]

On Thu, 4 Apr 2002, Justin T. Gibbs wrote:

> >BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed
> >to do at one time'- which is wrong because MAXPHYS is larger.
> 
> If you look at the x86 implementation, BUS_SPACE_MAXSIZE is only
> used in the non-GNUC case and is not referenced (I don't think)
> by any driver code.  Even setting it to MAXPHYS is not truely
> correct since at some point we will have to start supporting
> transfer mappings that are larger than what can be mapped by
> a single buffer.  I never realized that there was such controversy
> over this value... it was just put in so that I could have something
> for the non-GNUC case.

Yeah, but, uh, it'll blow up in one's face.

The question I have is what *should* we be using? Should BUS_SPACE_MAXSIZE be
bumped up so that any dma allocation we attempt for a platform will fit within
it?

I mean, it's used in a lot of places, so clearly it must mean something,
right? What are the semantics here?

-matt



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

Re: BUS_SPACE_MAXSIZE & isp driver.

[Matthew Jacob]

On Thu, 4 Apr 2002, Terry Lambert wrote:

> Matthew Jacob wrote:
> > Neither is really applicable here. The actual limits for alpha depend on the
> > platforma and how you implement it. Typically, the bigger alphas have been
> > implemented with a 2GB direct mapped window, and then, if they have it, a S/G
> > map setup for the rest (if any) of memory, which also can include ISA mapping.
> 
> Thanks for the clarification.  I was confusing BUS_SPACE_MAXSIZE
> with BUS_SPACE_MAXSIZE_24BIT and BUS_SPACE_MAXSIZE_32BIT.
> 
> It's probably too late to rename BUS_SPACE_MAXSIZE to something
> like BUS_SPACE_MAXXFER.  8-(.

Yes. If we've understood it at all. There are no documents really describing
it.

> 
> 
> > The current Alpha 2.4.18 Linux implementation is quite happy to DMA to > 4GB
> > on quite a few alphas.
> 
> Ah.  Reference code.
> 
> 
> > BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed
> > to do at one time'- which is wrong because MAXPHYS is larger.
> 
> Yeah, I get that now.  No need to beat me up, I can take care
> of it myself.  8-) 8-).

No, no at least you showed some interest :-)



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

Re: BUS_SPACE_MAXSIZE & isp driver.

[Matthew Jacob]

On Thu, 4 Apr 2002, Terry Lambert wrote:

> Andrew Gallatin wrote:
> > Me too.  I was about to just change it for alpha, but then I wondered
> > if there was a reason for having BUS_SPACE_MAXSIZE < MAXPHYS.
> 
> From what I understand, the Alpha is limited to doing transfers
> in the first 2G of memory.  I'm not sure if the ISA 16M memory
> limit is in there anywhere, either.
> 
> The problem is that a DMA initiated by a bus mastering device
> can only access as many bis of address space as are passed
> through the bus, end-to-end.
> 
> For ISA, this ends up being a 16M limit; I think the 2G limit
> on Alpha is because the limit is 32 bits, but there is some
> signed math that should be unsigned.

Neither is really applicable here. The actual limits for alpha depend on the
platforma and how you implement it. Typically, the bigger alphas have been
implemented with a 2GB direct mapped window, and then, if they have it, a S/G
map setup for the rest (if any) of memory, which also can include ISA mapping.

The current Alpha 2.4.18 Linux implementation is quite happy to DMA to > 4GB
on quite a few alphas.

BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed
to do at one time'- which is wrong because MAXPHYS is larger.




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

Re: BUS_SPACE_MAXSIZE & isp driver.

[Matthew Jacob]

Oops. That wasn't it. Taking this offline.


On Thu, 4 Apr 2002, Matthew Jacob wrote:

> 
> Actually, I suppose if you change:
> 
> 
>   #define ISP_NSEG((MAXPHYS/PAGE_SIZE) + 1)
> 
> to
> 
>   #define ISP_NSEG((BUS_SPACE_MAXSIZE/PAGE_SIZE) + 1)
> 
> this will probably be more correct. I think this is probably what I should be
> using anyway.
> 
> BTW- this was more of a 'hackers' or 'scsi' issue.
> 
> I *used* to, btw, put a massively large number for segments- basically the max
> *should* be the number of segments I can stick in a single Request Queue
> (2 or 3) command plus all the continuation entries possible (5 or 7 per
> continuation entries, for FreeBSD ~250 or so- MMV depending on current state)-
> that'd be on the order of ~1800 segments.
> 
> After getting burned by some surprises in the sparc64 implementation, I
> decided to restrict it to paramaters that were compile time invariants for
> each platform. I guess I picked the wrong parameter :-).
> 
> -matt
> 
> 
> On Thu, 4 Apr 2002, Andrew Gallatin wrote:
> 
> > 
> > I just booted a recent current (or rather attempted to) and saw this
> > when attempting to mount root from a qlogic card on my miata:
> > 
> > 
> > bus_dmamap_load: Too many segs! buf_len = 0x2000
> > spec_getpages:(da0a) I/O read failure: (error=22) bp
> > 0xfe0004087ae8 vp 0xfe000ae9
> >size: 98304, resid: 98304, a_count: 98304, valid: 0x0
> >nread: 0, reqpage: 7, pindex: 59, pcount: 12
> > vm_fault: pager read error, pid 1 (init)
> > 
> > <... more of same ...>
> > 
> > The only way I could get the system to boot was to increase
> > BUS_SPACE_MAXSIZE to 128K to match MAXPHYS.  I don't know why they
> > don't match in the first place (they don't match on x86 either, so the
> > driver will probably puke there too.)
> > 
> > #define BUS_SPACE_MAXSIZE(128 * 1024)
> > 
> > Does anybody know why BUS_SPACE_MAXSIZE != MAXPHYS on some platforms?
> > 
> > Thanks,
> > 
> > Drew
> > 
> 
> 


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