Re: i915drm

[dawnshade]

On Friday 23 December 2005 08:11, Gianmarco Giovannelli wrote:
> At 08.10 22/12/2005, dawnshade wrote:
>  >On Thursday 22 December 2005 04:22, Gianmarco Giovannelli wrote:
>  >> It seems to me that also Oliver has the same bug (0M) on his 915GM
>  >>  Any other with with centrino based 915 card can confirm this ?
>  >
>  >for me works fine:
>  >
>  >dmesg |grep -E 'drm|agp'
>  >agp0:  port 0xe000-0xe007 mem
>  >0xd000-0xd007,0xa000-0xafff,0xd008-0xd00b irq 5
>  > at device 2.0 on pci0
>  >agp0: detected 7932k stolen memory
>  >agp0: aperture size is 256M
>  >drmsub0: : (child of agp_i810.c) on agp0
>  >info: [drm] AGP at 0xd000 0MB
>  >info: [drm] Initialized i915 1.2.0 20041217
>
> Uhm... you have the same 0M of me :-)
> Have you tried glxgears ?
> What are your results ?

glxinfo:

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read,
GLX_SGIS_multisample, GLX_SGIX_fbconfig
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control,
GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample,
GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 915GM 20050225
OpenGL version string: 1.3 Mesa 6.3
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_imaging,
GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_point_parameters,
GL_ARB_shadow, GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3,
GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle,
GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object,
GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra,
GL_EXT_blend_color, GL_EXT_blend_equation_separate,
GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
GL_EXT_clip_volume_hint, GL_EXT_cull_vertex, GL_EXT_compiled_vertex_array,
GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements,
GL_EXT_fog_coord, GL_EXT_histogram, GL_EXT_multi_draw_arrays,
GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset,
GL_EXT_rescale_normal, GL_EXT_secondary_color,
GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap,
GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D,
GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array,
GL_3DFX_texture_compression_FXT1, GL_APPLE_client_storage,
GL_APPLE_packed_pixels, GL_ATI_blend_equation_separate,
GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat,
GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture,
GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent,
GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program,
GL_NV_vertex_program1_1, GL_OES_read_format, GL_SGI_color_matrix,
GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp,
GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture,
GL_SUN_multi_draw_arrays
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
--
0x23 24 tc  0 32  0 r  y  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0x24 24 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0x25 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x26 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x27 24 tc  0 32  0 r  y  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0x28 24 tc  0 32  0 r  .  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0x29 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x2a 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 

Re: em bad performance

[Danny Braniss]

> On 12/22/05, Gleb Smirnoff <[EMAIL PROTECTED]> wrote:
> > On Thu, Dec 22, 2005 at 12:37:53PM +0200, Danny Braniss wrote:
> > D> > On Thu, Dec 22, 2005 at 12:24:42PM +0200, Danny Braniss wrote:
> > D> > D> 
> > D> > D> Server listening on TCP port 5001
> > D> > D> TCP window size: 64.0 KByte (default)
> > D> > D> 
> > D> > D> [  4] local 132.65.16.100 port 5001 connected with [6.0/SE7501WV2] 
> > port 58122
> > D> > D> (intel westvill)
> > D> > D> [ ID] Interval   Transfer Bandwidth
> > D> > D> [  4]  0.0-10.0 sec  1.01 GBytes   867 Mbits/sec
> > D> > D> [  4] local 132.65.16.100 port 5001 connected with [5.4/SE7501WV2] 
> > port 55269
> > D> > D> (intel westvill)
> > D> > D> [ ID] Interval   Transfer Bandwidth
> > D> > D> [  4]  0.0-10.0 sec   967 MBytes   811 Mbits/sec
> > D> > D> [  5] local 132.65.16.100 port 5001 connected with [6.0/SR1435VP2 
> > port 58363
> > D> > D> (intel dual xeon/emt64)
> > D> > D> [ ID] Interval   Transfer Bandwidth
> > D> > D> [  5]  0.0-10.0 sec   578 MBytes   485 Mbits/sec
> > D> > D>
> > D> > D> i've run this several times, and the results are very similar.
> > D> > D> i also tried i386, and the same bad results.
> > D> > D> all hosts are connected at 1gb to the same switch.
> > D> >
> > D> > So we see a strong drawback between SE7501WV2 and SR1435VP2. Let's 
> > compare the NIC
> > D> > hardware. Can you plese show pciconf -lv | grep -A3 ^em on both 
> > motherboards?
> > D>
> > D> on a SE7501WV2:
> > D> [EMAIL PROTECTED]:7:0:   class=0x02 card=0x341a8086 chip=0x10108086 
> > rev=0x01
> > D> hdr=0x00
> > D> vendor   = 'Intel Corporation'
> > D> device   = '82546EB Dual Port Gigabit Ethernet Controller (Copper)'
> > D> class= network
> > D>
> > D> on a SR1435VP2:
> > D> [EMAIL PROTECTED]:3:0:   class=0x02 card=0x34668086 chip=0x10768086 
> > rev=0x05
> > D> hdr=0x00
> > D> vendor   = 'Intel Corporation'
> > D> device   = '82547EI Gigabit Ethernet Controller'
> > D> class= network
> >
> > The first one 82546EB is attached to fast PCI-X bus, and the 82547EI is
> > on CSA bus. The CSA bus is twice faster than old PCI bus, CSA can handle
> > 266 Mbps. I'm not sure but may be it has same ~50% overhead as old PCI bus.
> >
> > Probably our em(4) driver is not optimized enough and does too many accesses
> > to the PCI bus, thus utilizing more bandwidth than needed to handle traffic.
> > In this case we see that NIC on slower bus (but enough to handle Gigabit) is
> > must slower than NIC on faster bus. (This paragraph is my own theory, it
> > can be complete bullshit.)
> 
> CSA bus? I've never heard of it.
> 
> To get the best gig performance you really want to see it on PCI Express.
> I see 930ish Mb/s. I'm not really familiar with this motherboard/lom.
> 
> You say you run iperf -s on the server side, but what are you using as
> parameters on the client end of the test?
> 
iperf -c host

i'm begining to believe that the problem is elsewhere, i just put in
an ethernet nic in a PCI-X/Express slot, and the performance is similar, bad.

danny

> Jack


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

Re: indefinite wait buffer: Does this indicate hardware issue?

[Xin LI]

Hi,

On 19 Dec 2005 14:32:31 -0600, Douglas K. Rand <[EMAIL PROTECTED]> wrote:
[...]
> Tracing command swapper pid 0 tid 0 td 0xc0698e20
> sched_switch(c0698e20,0,1) at sched_switch+0x14b
> mi_switch(1,0) at mi_switch+0x1ba
> scheduler(0,81ec00,81e000,0,c042f5d5) at scheduler+0x262
> mi_startup() at mi_startup+0x96
> begin() at begin+0x2c

Which scheduler are you using?

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

Re: i915drm

[Gianmarco Giovannelli]

At 13.00 20/12/2005, dawnshade wrote:
>On Tuesday 20 December 2005 11:37, Gianmarco Giovannelli wrote:
>> hp:/home/gmarco> glxgears
>> ERROR: line 125, Function intelInitDriver, File intel_screen.c
>> libGL warning: 3D driver returned no fbconfigs.
>> libGL error: InitDriver failed
>> libGL error: reverting to (slow) indirect rendering
>> 1024 frames in 5.0 seconds = 204.800 FPS
>> 1260 frames in 5.0 seconds = 252.000 FPS
>> 1267 frames in 5.0 seconds = 253.400 FPS
>>
>> (before patch it used to be about 600)
>
>try to upgrade port dri to dri-devel
>I have the same situation - glxinfo shows that dri disabled, after 
portupgrade

>-f -o graphics/dri-devel dri glxgears shown 1128.200 FPS (was ~300 and ~600
>w/o dri)

Oops I don't remember about this.
Can you please told me which versions (dri-devel, xorg) do you have 
(because I am running dri-devel !!! :-) ?



Best Regards,
Gianmarco Giovannelli ,  "Unix expert since yesterday"
http://utenti.gufi.org/~gmarco/

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

Re: i915drm

[Gianmarco Giovannelli]

At 08.10 22/12/2005, dawnshade wrote:
>On Thursday 22 December 2005 04:22, Gianmarco Giovannelli wrote:
>> It seems to me that also Oliver has the same bug (0M) on his 915GM
>>  Any other with with centrino based 915 card can confirm this ?
>
>for me works fine:
>
>dmesg |grep -E 'drm|agp'
>agp0:  port 0xe000-0xe007 mem
>0xd000-0xd007,0xa000-0xafff,0xd008-0xd00b irq 5 at
>device 2.0 on pci0
>agp0: detected 7932k stolen memory
>agp0: aperture size is 256M
>drmsub0: : (child of agp_i810.c) on agp0
>info: [drm] AGP at 0xd000 0MB
>info: [drm] Initialized i915 1.2.0 20041217

Uhm... you have the same 0M of me :-)
Have you tried glxgears ?
What are your results ?


Best Regards,
Gianmarco Giovannelli ,  "Unix expert since yesterday"
http://utenti.gufi.org/~gmarco/

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

Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]

[Peter Jeremy]

On Thu, 2005-Dec-22 13:17:30 -0800, Jo Rhett wrote:
>But FreeBSD Update suffers from all of the same limitations that I've been
>describing because of lack of integration with the Core OS.
>
>1. modified kernels are foobar
>  ..yet are practically mandatory on production systems
>
>2. modified sources are foobar
>  ..yet many common production situations require source compilation options

So you want to be able to make arbitrary changes you your source code
and compilation options and then expect the FreeBSD project to provide
a tool that will apply binary fixes to the resultant executables?

I don't know that modified kernels are mandatory.  A lot of work has
been going on to reduce the need to re-compile the kernel for common
situations.  Likewise, I don't know that "many common" and "require"
go together - IMHO, 'desire' or 'would be nice' are more appropriate
descriptions.  Would you care to provide some details of what you
believe can be done to reduce your need to re-compile the OS.

I'm not sure that FreeBSD Update is totally unusable for you.  If you
have the situation where you have a modified FreeBSD that you need to
roll out to a large number of hosts, you just need to have your own
FreeBSD Update server - you test the changes in your environment and
then roll them out as you require.

AFAIK, Colin hasn't fully productised FreeBSD Update to date but has
not rejected the idea of doing so.

>3. FreeBSD Update can't handle updates of jails and other situations that
>package systems deal with just fine.

I don't run jails so I'm not familiar with the problems here.  Maybe you'd
like to explain the problems you run into.

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

Re: HEADS UP: Release schedule for 2006

[Peter Jeremy]

On Thu, 2005-Dec-22 13:10:19 -0800, Jo Rhett wrote:
>I and many others have offered to work on this.  The core team has
>repeatedly stated that they won't integrate the efforts, which makes
>os-upgrade capability minimal and easily broken. (see current efforts)

On Thu, 2005-Dec-22 14:05:32 -0800, Jo Rhett wrote:
>On Thu, Dec 22, 2005 at 01:30:41PM -0800, Brooks Davis wrote:
>> This statement makes no sense.  The core team wouldn't have much to
>> do with this other than possibly being involved in making any service
>> official.  Also, approval is never given to include a non-existent
>> feature.  Easy, binary updates sound like a great idea, but without
>> seeing actual code thats all anyone can say other than offering advice.
>> If volunteering is conditional on acceptance of the work, that's a
>> chicken-egg problem and is not resolvable.  We simply can't maintain
>> quality if we accept non-existent code just because the idea sounds
>> good.
> 
>What are you talking about?  These issues have been repeatedly brought up
>in the mailing lists, and what it would require to make it possible to
>handle appropriately (namely, core os packages or a similar versioning
>mechanism) and the arguements have often been given.

I agree with Brooks.  I don't recall ever seeing a message from -core
(or anyone else talking on behalf of the Project) stating that code to
make binary updates possible would not be integrated.  For that matter,
I don't recall ever seeing code offered to implement such a feature.

Core OS packages have been discussed but I don't recall the idea ever
being vetoed.  Some work have been done in breaking bits of the base OS
out into packages (perl, games and UUCP come to mind) but packaging the
entire system is a major undertaking.  In any case, I don't see how
packaging the system would help you.  Taking Solaris as an example of
an OS which is broken up into lots of packages, patches don't replace
whole packages, they replace individual files.

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

Re: gmirror SCSI+IDE

[Matthew D. Fuller]

On Thu, Dec 22, 2005 at 05:23:48PM -0500 I heard the voice of
Martin Cracauer, and lo! it spake thus:
> Ivan Voras wrote on Fri, Dec 16, 2005 at 06:39:18PM +0100: 
> 
> > For example, AFAIK SCSI devices are under Giant and IDE are not 
> 
> In 6.x and 7.x both are finer-graded.

I wish somebody would inform my SCSI controllers about that...


-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

[Matthew D. Fuller]

On Thu, Dec 22, 2005 at 01:09:04PM -0800 I heard the voice of
Jo Rhett, and lo! it spake thus:
>  
> No, you're missing the point.  More core OS upgrades means less
> incremental patches (which are easier to apply than a full update).

Right.  I don't understand how B follows A here.

These patches come from where?  Security advisories, mailing list
discussions, and eating too much beef right before bed and waking up
at 2am with brilliant ideas?  Why would there be less of them, just
because RELENG_X_Y_RELEASE tags are laid down more often?


> Huh?  That's backwards.  If we can't schedule the downtime for a
> full operating system upgrade (which takes far longer than it
> should) then the system won't get upgraded.

Having done full OS upgrades a number of times, I can't remember the
last time it took more than 5 or 10 minutes (during most of which the
system can keep running its normal services, just a little more
crunched on CPU or I/O).  Well, OK, I can; it was when I moved servers
from 2.2.x to 4.x.  But that's a rather exceptional case, and next
time THAT happens, I'm darn well using it as an excuse to strongarm
new hardware out of somebody and replace the server at the same
time...


> Not to be rude, but I think your definition of analogy is wrong.

No, you're right.  "Hyperbole" was probably a better word, but even
that doesn't quite fit.  My ability to find the right word is flaky at
times.  I don't understand the basis of your assertion that more
common tagging means suddenly you can't apply individual patches.


> Back to the point, the comments aren't "bad".  Your idea that binary
> operating system upgrades from ISO are "easier" demonstrates that
> you're talking about home computers, not production servers.

Oh, no.  Heck, I find that upgrades from SOURCE are "easier".  In
fact, just last month I bought my first CD burner, so it wasn't until
a few weeks ago that I even burned my first ISO (and that, just to
test the burner and figure out how to do it), and I've never booted or
installed off one.  For small groups of servers, I NFS mount
installworlds, and for larger groups, I rdist out binaries.  But it
always comes from source.


-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )

[Daniel O'Connor]

On Fri, 23 Dec 2005 08:42, Jo Rhett wrote:
> > Using a build server as a testbed and to generate new packages or even a
> > new kernel + world will reduce the amount of work required, but FreeBSD
> > does require some level of administration and maintenance.
>
> We already have that.  But again, I'm not sure what you are trying to say
> here.  The centralized server makes patching and port upgrades easier.  It
> does _NOTHING_ for core OS upgrades because there is no supported mechanism
> for doing binary upgrades except from the ISO.  Thus, we are finally back
> on topic.

Uhh..
On your central PC..
buildworld once.
builkernel once for each of the different kernels you are using.

On each 'client' PC..
NFS mount /usr/src and /usr/obj
installkernel
reboot
installworld

Sure there are no tools to automagically do this, but I don't believe core 
would say "no, we will never support this".

> I have made suggestions.  Everyone has made suggestions.  Most of us have
> produced code to work around the problem, but the core OS team has always
> refused to support or acknowledge these efforts.

You are putting words in the mouth of core@ - I find it very hard to believe 
that core would suggest someone NOT implement a good framework for doing full 
binary upgrades via the network.

Unless you mean "core@ said they would not support packaging the base" which 
is different.

> For binary upgrades without booting from CD-ROM to be possible, we need
> versioning of some sort at the OS level.  Core OS packages are the most

This is not true - I don't see it as being mandatory to be able to apply 
binary updates. (Case in point - freebsd-update works fine without it)

> popular suggestion, but not the only path.  Every year this topic comes up
> and gets struck down again.

Yes, because a) it isn't necessary, b) it may not solve the problem, c) there 
are no patches to evaluate.

I think the people suggesting it see it as a panacea to fix their problems but 
haven't fully evaluated it.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


pgpGhZEDHKKBL.pgp
Description: PGP signature

Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]

[Daniel O'Connor]

On Fri, 23 Dec 2005 07:47, Jo Rhett wrote:
> On Sat, Dec 17, 2005 at 06:19:25PM -0700, Scott Long wrote:
> > FreeBSD Update was written by, and is continuously maintained by the
> > actual FreeBSD Security Officer.  It's as official as it gets.  If
> > the only barrier to acceptance is that it's not distributed from the
> > FreeBSD.org domain, then a) that's a silly argument, and b) it's easily
> > solvable so long as Colin agrees.
>
> But FreeBSD Update suffers from all of the same limitations that I've been
> describing because of lack of integration with the Core OS.
>
> 1. modified kernels are foobar
>   ..yet are practically mandatory on production systems
>
> 2. modified sources are foobar
>   ..yet many common production situations require source compilation
> options

How do you expect these two to be handled in a binary upgrade?
I can't see how it's possible..

I don't think integrating it with the core OS (whatever that means) will 
magically fix this.

> 3. FreeBSD Update can't handle updates of jails and other situations that
> package systems deal with just fine.

Not having run jails I am not very qualified to comment, however, I don't see 
why you can't just run freebsd update inside your jail(s). If you mean that 
it would be good if you could automatically upgrade a large number of jails 
and rebuild link farms etc etc.. well sure that isn't supported, but it is a 
very difficult problem to solve (I believe).

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


pgpSfJi3tgpAm.pgp
Description: PGP signature

Re: gmirror SCSI+IDE

[Martin Cracauer]

Ivan Voras wrote on Fri, Dec 16, 2005 at 06:39:18PM +0100: 
> For some funny reasons, I'll probably have to setup a gmirror between a 
> SCSI disk device and a IDE one, and won't have much time for testing. So 
> I'm wondering did anyone do such a thing and are there any caveats.

It is just operating on block devices.  You can plug in anything from
your mp3 player to your google mailbox.

> For 
> example, AFAIK SCSI devices are under Giant and IDE are not 

In 6.x and 7.x both are finer-graded.

> - is there any 
> reason this would make problems?

If you have different speeds on the disks in a raid-1 you should mess
with the raid software to tell it that one disk is likely to be
faster.

Martin
-- 
%%%
Martin Cracauerhttp://www.cons.org/cracauer/
FreeBSD - where you want to go, today.  http://www.freebsd.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

[Jo Rhett]

On Thu, Dec 22, 2005 at 04:45:09PM -0500, Chuck Swiger wrote:
> FreeBSD releases new .ISO images several times a year, but you've got the 
> tools to make .ISO images of patch releases yourself, if you want to.  I 
> don't think that the FreeBSD project can shorten the release cycle below a 
> month or so, which means that patch releases are always going to be on the 
> (b)leading edge...
 
I'm not sure you're paying attention to what I'm saying.  This was your
reply to my message about systems without CDs, with only flash drives, etc.
ISOs won't help.

> >And taking systems offline for a .1
> >update gets annoying fast.  Dealing with all the file comparisons which are
> >exactly the same except for the CVS tag takes hours for no good reason.
> >Multiple many hours by hundreds of systems, and you could easily have a
> >full time person just doing FreeBSD upgrades.
> 
> Using a build server as a testbed and to generate new packages or even a 
> new kernel + world will reduce the amount of work required, but FreeBSD 
> does require some level of administration and maintenance.
 
We already have that.  But again, I'm not sure what you are trying to say
here.  The centralized server makes patching and port upgrades easier.  It
does _NOTHING_ for core OS upgrades because there is no supported mechanism
for doing binary upgrades except from the ISO.  Thus, we are finally back
on topic.

> >I don't care about ports, just the base OS.  Ports we've built the
> 
> I've got firewalls with a single-digit number of ports installed, but 
> anything else seems to acquire 100-200 or so.
 
Again, I don't care about ports.  The largest number of ports installed on
any production system we have is 18.  And having a centralized server where
we can build and export the packages works just fine.  The portaudit tools
are very useful in this regard, when pointed at internal servers.

There is no similar mechanism for OS upgrades, which is what we're talking
about here.  Ports is not a problem.

> I'm with you on this, but suggesting solutions is more useful than just 
> noting the existence of problems.

I have made suggestions.  Everyone has made suggestions.  Most of us have
produced code to work around the problem, but the core OS team has always
refused to support or acknowledge these efforts.

For binary upgrades without booting from CD-ROM to be possible, we need
versioning of some sort at the OS level.  Core OS packages are the most
popular suggestion, but not the only path.  Every year this topic comes up
and gets struck down again.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: Release schedule for 2006

[Jo Rhett]

On Thu, Dec 22, 2005 at 01:30:41PM -0800, Brooks Davis wrote:
> This statement makes no sense.  The core team wouldn't have much to
> do with this other than possibly being involved in making any service
> official.  Also, approval is never given to include a non-existent
> feature.  Easy, binary updates sound like a great idea, but without
> seeing actual code thats all anyone can say other than offering advice.
> If volunteering is conditional on acceptance of the work, that's a
> chicken-egg problem and is not resolvable.  We simply can't maintain
> quality if we accept non-existent code just because the idea sounds
> good.
 
What are you talking about?  These issues have been repeatedly brought up
in the mailing lists, and what it would require to make it possible to
handle appropriately (namely, core os packages or a similar versioning
mechanism) and the arguements have often been given.

And many people _ARE_ already trying to handle binary updates without core
OS support.  We are all struggling with the same limitations.  Talk to the
security officer about this if you don't believe me.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: cdboot troubles; 6.0 kernel hanging

[Juergen Lock]

On Wed, Dec 21, 2005 at 11:15:30PM +0100, Juergen Lock wrote:
> I have this box that apparently no longer likes FreeBSD's cdboot,
> it prints something about BOOT/LOADER and then just reboots.
> Any ideas how to debug something like that?  The box already has
> FreeBSD installed (5.3 with some patches), and i tried copying the
> 6.0 kernel from disc1 and loading it manually at the loader prompt.
> It hangs after printing (boot -v):
>   GEOM: new disk ad0
>   GEOM: new disk ad4
> 
> ad0 is on oboard pata (the board is a via kt400), ad4 is a single disk
> on a Promise Fasttrack tx2200 sata controller.  I guess i could try
> to build a 6.0 kernel with ddb, but what would i be looking for then
> to find out why its hanging?  [...]

I have now done that, here is a boot -v and ddb `ps' and `show thread'
log of the hanging RELENG_6_0 GENERIC with ddb, does that tell anyone
anything?  (i dunno if the `call boot' crash at the end is important,
probably not.)  I need help...

 Oh, would it help if i retried this with a -current kernel?
(I don't want to actually put -current on this box because it
is my router and i want it to be stable, i just wanted to upgrade
it to 6.0...)

snip-
OK boot -v -s
/boot/kernel/acpi.ko text=0x3fbfc data=0x1c04+0x112c 
syms=[0x4+0x72f0+0x4+0x97c7]
KDB: debugger backends: ddb
KDB: current backend: ddb
SMAP type=01 base= len=0009a000
SMAP type=02 base=000f len=0001
SMAP type=02 base=fec0 len=1000
SMAP type=02 base=fee0 len=1000
SMAP type=02 base= len=0001
SMAP type=02 base=0009a000 len=6000
SMAP type=01 base=0010 len=1fef
SMAP type=03 base=1fff3000 len=d000
SMAP type=04 base=1fff len=3000
Copyright (c) 1992-2005 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 6.0-RELEASE-p1 #1: Thu Dec 22 21:47:15 CET 2005
[EMAIL PROTECTED]:/usr/obj/usr/home/nox/src6/src/sys/GENERICDB
Preloaded elf kernel "/boot/kernel/kernel.60db" at 0xc0a98000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a9825c.
link_elf: symbol ioapic_enable_mixed_mode undefined
KLD file acpi.ko - could not finalize loading
MP Configuration Table version 1.1 found at 0xc00f1400
APIC: Using the MPTable enumerator.
MPTable: 
Calibrating clock(s) ... i8254 clock: 1193267 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254" frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 2075028490 Hz
CPU: AMD Athlon(tm) XP 2600+ (2075.03-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x681  Stepping = 1
  
Features=0x383fbff
  AMD Features=0xc0400800
Data TLB: 32 entries, fully associative
Instruction TLB: 16 entries, fully associative
L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative
real memory  = 536805376 (511 MB)
Physical memory chunk(s):
0x1000 - 0x00099fff, 626688 bytes (153 pages)
0x0010 - 0x003f, 3145728 bytes (768 pages)
0x00c25000 - 0x1f6b7fff, 514404352 bytes (125587 pages)
avail memory = 516055040 (492 MB)
bios32: Found BIOS32 Service Directory header at 0xc00faf00
bios32: Entry = 0xfb370 (c00fb370)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0xb3a0
pnpbios: Bad PnP BIOS data checksum
Other BIOS signatures found:
ioapic0: Assuming intbase of 0
ioapic0: Routing external 8259A's -> intpin 0
ioapic0: intpin 0 -> ExtINT (edge, high)
ioapic0: intpin 1 -> ISA IRQ 1 (edge, high)
ioapic0: intpin 2 -> ISA IRQ 2 (edge, high)
ioapic0: intpin 3 -> ISA IRQ 3 (edge, high)
ioapic0: intpin 4 -> ISA IRQ 4 (edge, high)
ioapic0: intpin 5 -> ISA IRQ 5 (edge, high)
ioapic0: intpin 6 -> ISA IRQ 6 (edge, high)
ioapic0: intpin 7 -> ISA IRQ 7 (edge, high)
ioapic0: intpin 8 -> ISA IRQ 8 (edge, high)
ioapic0: intpin 9 -> ISA IRQ 9 (edge, high)
ioapic0: intpin 10 -> ISA IRQ 10 (edge, high)
ioapic0: intpin 11 -> ISA IRQ 11 (edge, high)
ioapic0: intpin 12 -> ISA IRQ 12 (edge, high)
ioapic0: intpin 13 -> ISA IRQ 13 (edge, high)
ioapic0: intpin 14 -> ISA IRQ 14 (edge, high)
ioapic0: intpin 15 -> ISA IRQ 15 (edge, high)
ioapic0: intpin 16 -> PCI IRQ 16 (level, low)
ioapic0: intpin 17 -> PCI IRQ 17 (level, low)
ioapic0: intpin 18 -> PCI IRQ 18 (level, low)
ioapic0: intpin 19 -> PCI IRQ 19 (level, low)
ioapic0: intpin 20 -> PCI IRQ 20 (level, low)
ioapic0: intpin 21 -> PCI IRQ 21 (level, low)
ioapic0: intpin 22 -> PCI IRQ 22 (level, low)
ioapic0: intpin 23 -> PCI IRQ 23 (level, low)
ioapic0: intpin 16 bus ISA
ioapic0: Routing IRQ 10 -> intpin 16
ioapic0: intpin 10 disabled
ioapic0: intpin 16 trigger: level
ioapic0: 

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

[Chuck Swiger]

Jo Rhett wrote:

On Sat, Dec 17, 2005 at 06:55:03PM -0500, Chuck Swiger wrote:

YMMV.  I burned a 6.0 release from the ISO image, and did a binary upgrade on an
IBM ThinkPad (T.34? maybe), which worked perfectly.  All of the 5.x binaries,
including X11, KDE, printing, Mozilla, etc worked just fine.


There are no ISO for patch releases.


FreeBSD releases new .ISO images several times a year, but you've got the tools 
to make .ISO images of patch releases yourself, if you want to.  I don't think 
that the FreeBSD project can shorten the release cycle below a month or so, 
which means that patch releases are always going to be on the (b)leading edge...



And taking systems offline for a .1
update gets annoying fast.  Dealing with all the file comparisons which are
exactly the same except for the CVS tag takes hours for no good reason.
Multiple many hours by hundreds of systems, and you could easily have a
full time person just doing FreeBSD upgrades.


Using a build server as a testbed and to generate new packages or even a new 
kernel + world will reduce the amount of work required, but FreeBSD does require 
some level of administration and maintenance.



Upgrading the ports from there was somewhat annoying


I don't care about ports, just the base OS.  Ports we've built the
infrastructure to handle properly, and very few ports are installed on
production systems.


I've got firewalls with a single-digit number of ports installed, but anything 
else seems to acquire 100-200 or so.



Now, if you want to talk about upgrading to intermediate patch releases, you've
got a valid point there.  :-)
 
That is exactly the point.  Both .01 and .1 releases are annoying.


I'm with you on this, but suggesting solutions is more useful than just noting 
the existence of problems.


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

Re: HEADS UP: Release schedule for 2006

[Brooks Davis]

On Thu, Dec 22, 2005 at 01:10:19PM -0800, Jo Rhett wrote:
> On Sat, Dec 17, 2005 at 11:08:07PM +0100, Wilko Bulte wrote:
> > So, when will you fix it?  Or hire someone to fix it?  FreeBSD after
> > all is mostly a volunteer operation.
>  
> I and many others have offered to work on this.  The core team has
> repeatedly stated that they won't integrate the efforts, which makes
> os-upgrade capability minimal and easily broken. (see current efforts)

This statement makes no sense.  The core team wouldn't have much to
do with this other than possibly being involved in making any service
official.  Also, approval is never given to include a non-existent
feature.  Easy, binary updates sound like a great idea, but without
seeing actual code thats all anyone can say other than offering advice.
If volunteering is conditional on acceptance of the work, that's a
chicken-egg problem and is not resolvable.  We simply can't maintain
quality if we accept non-existent code just because the idea sounds
good.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


pgp9pQJsguI8u.pgp
Description: PGP signature

Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]

[Jo Rhett]

On Sat, Dec 17, 2005 at 06:19:25PM -0700, Scott Long wrote:
> FreeBSD Update was written by, and is continuously maintained by the
> actual FreeBSD Security Officer.  It's as official as it gets.  If
> the only barrier to acceptance is that it's not distributed from the
> FreeBSD.org domain, then a) that's a silly argument, and b) it's easily
> solvable so long as Colin agrees.
 
But FreeBSD Update suffers from all of the same limitations that I've been
describing because of lack of integration with the Core OS.

1. modified kernels are foobar
  ..yet are practically mandatory on production systems

2. modified sources are foobar
  ..yet many common production situations require source compilation options

3. FreeBSD Update can't handle updates of jails and other situations that
package systems deal with just fine.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: Release schedule for 2006

[Jo Rhett]

On Sat, Dec 17, 2005 at 11:35:34PM +0100, K?vesd?n G?bor wrote:
> I agree. And after all, tracking a security branch isn't too difficult, 
> but the most people think that they have to do a complete "make 
> buildworld" after a security advisory, but this isn't true. For example 
> there was that cvsbug issue in September:
..
> # make obj && make depend && make && make install
> 
> Is that difficult? I don't think so. No reboot required and it doesn't 
> take more than 5 minutes even on a slower machine.
 
This comment demonstrates that you are again talking about home computers,
while all of my comments indicated that I was talking about production
systems.  Ones that may not have sufficient memory to compile code, or 
local disks, or...

In any case, you are right.  This kind of patch is easy to apply.  You can
build it on a central server and synchronize it outwards to the others.
The existing binary update mechanisms can handle this situation fairly
well.

But more "core OS" upgrades means less of these patches and more
requirement for a full binary upgrade.  Which is NOT easy like this.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Anyone use any si(4) cards?

[John Baldwin]

Does anyone have any si(4) cards that they use?  I'm curious because 1) I'd 
like to know if the si(4) driver works on HEAD, and 2) there is updated 
firmware for the SIJET cards I'd like someone to test.

-- 
John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: Release schedule for 2006

[Jo Rhett]

On Sat, Dec 17, 2005 at 11:08:07PM +0100, Wilko Bulte wrote:
> So, when will you fix it?  Or hire someone to fix it?  FreeBSD after
> all is mostly a volunteer operation.
 
I and many others have offered to work on this.  The core team has
repeatedly stated that they won't integrate the efforts, which makes
os-upgrade capability minimal and easily broken. (see current efforts)

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

[Jo Rhett]

> On Sat, Dec 17, 2005 at 02:00:21PM -0800 I heard the voice of
> Joe Rhett, and lo! it spake thus:
> > 
> > Increasing the number of deployed systems out of date [...]
 
On Sat, Dec 17, 2005 at 08:37:25PM -0600, Matthew D. Fuller wrote:
> This doesn't make any sense.  If you install a 6.0 system, in 6 months
> (assuming you installed it right when 6.0 was cut, for simplicity), it
> will be 6 months out of date.  It's neither more nor less out of date
> if the current release is then 6.1, or 6.2, or 8.12; it's still 6
> months back.
 
No, you're missing the point.  More core OS upgrades means less incremental
patches (which are easier to apply than a full update).  That means that
more systems will fall out of date because of the time-consuming nature of
full operating system upgrades.

> A case could, in fact, be made that more common releases lead to far
> FEWER deployed systems out of date, since it makes it far easier for
> those who already use binary upgrades instead of source to get things
> faster.

Huh?  That's backwards.  If we can't schedule the downtime for a full
operating system upgrade (which takes far longer than it should) then the
system won't get upgraded.  Small incremental patches can be built on
central systems and rsynced outwards fairly easily in comparison.

> Now, this is not to say that easier incremental binary upgrades are a
> bad thing, but bad analogy doesn't help anybody...

Not to be rude, but I think your definition of analogy is wrong.  There was
no analogy in my comments - no parallelism at all.  I was focused on the
single topic, and not referring to anything else.

Back to the point, the comments aren't "bad".  Your idea that binary
operating system upgrades from ISO are "easier" demonstrates that you're
talking about home computers, not production servers.  I'm talking about
production environments, which I made very clear in my description.

...few have CDs
...many don't have local consoles, or local staff
...many don't have local disks at all (flash-based systems)

"Install new OS from ISO" is completely impractical in all of these
environments.  "Install from source" is impossible in most.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

[Jo Rhett]

> On Sun, Dec 18, 2005 at 09:55:33AM +, Matthew Seaman wrote:
> > Doesn't creating a binary updates system that's going to be practical to use
> > require implementation of that old and exceedingly bikesheddable subject: 
> > packaging
> > up the base system?

On Sun, Dec 18, 2005 at 12:13:09PM -0500, Kris Kennaway wrote:
> No, after all the *existing* binary update systems don't require
> packaging of the base system.
 
None of which work properly in production environments.  They work fine for
home computers running GENERIC, and who can sustain some downtime for
upgrade failures.  

And they are all completely un-auditable.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

[Jo Rhett]

On Sun, Dec 18, 2005 at 09:55:33AM +, Matthew Seaman wrote:
> Doesn't creating a binary updates system that's going to be practical to use
> require implementation of that old and exceedingly bikesheddable subject: 
> packaging up the base system?  

EXACTLY.  That's why we need core team support.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

[Jo Rhett]

> > On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote:
> > > There will be three FreeBSD 6 releases in 2006.

> On Sat, Dec 17, 2005 at 02:00:21PM -0800, Joe Rhett wrote:
> > While this is nice, may I suggest that it is time to put aside/delay one
> > release cycle and come up with a binary update mechanism supported well by
> > the OS?  Increasing the speed of releases is good.  Increasing the number
> > of deployed systems out of date because there are no easy binary upgrade
> > mechanisms is bad.
> > 
> > It has been bad, it's getting worse.
 
On Sat, Dec 17, 2005 at 06:46:27PM -0500, Kris Kennaway wrote:
> Suggestions are nice, but who do you think will work on solving this?
 
I and many others have proposed binary update mechanisms, and are all
willing to work on them.  The core freebsd team has not shown willingness
to work with such an effort.  Without that, we'd be patching the update
mechanism with every new release, which kind of defeats the point.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

[Jo Rhett]

On Sat, Dec 17, 2005 at 06:55:03PM -0500, Chuck Swiger wrote:
> YMMV.  I burned a 6.0 release from the ISO image, and did a binary upgrade on 
> an
> IBM ThinkPad (T.34? maybe), which worked perfectly.  All of the 5.x binaries,
> including X11, KDE, printing, Mozilla, etc worked just fine.

There are no ISO for patch releases.  And taking systems offline for a .1
update gets annoying fast.  Dealing with all the file comparisons which are
exactly the same except for the CVS tag takes hours for no good reason.
Multiple many hours by hundreds of systems, and you could easily have a
full time person just doing FreeBSD upgrades.

> Upgrading the ports from there was somewhat annoying

I don't care about ports, just the base OS.  Ports we've built the
infrastructure to handle properly, and very few ports are installed on
production systems.

> Now, if you want to talk about upgrading to intermediate patch releases, 
> you've
> got a valid point there.  :-)
 
That is exactly the point.  Both .01 and .1 releases are annoying.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: Please clean out your */etc/rc.d directories

[Doug Barton]

John-Mark Gurney wrote:


Also, how will this effect cups which installs a .sample file?  and
any other port that does this?


Brooks already answered the first part of your question, so I'll just add 
here that .sample is already being ignored, along with a few other 
extensions, but it's safer and better to get in the habit of not leaving 
stale stuff in the rc.d directories.


Doug


--

This .signature sanitized for your protection

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

Re: HEADS UP: Please clean out your */etc/rc.d directories

[Brooks Davis]

On Thu, Dec 22, 2005 at 10:45:06AM -0800, John-Mark Gurney wrote:
> Doug Barton wrote this message on Thu, Dec 22, 2005 at 01:50 -0800:
> > I should have said this in my last heads up message, sorry for forgetting 
> > about this important detail. The new code tries to run any script in a 
> > local_startup directory (by default /usr/local/etc/rc.d and 
> > /usr/X11R6/etc/rc.d) that has the execute bit set. So, if there is a script 
> > in one of those directories that you don't want run at all, the safest 
> > thing to do is to create a directory within rc.d, and move the script 
> > there. Parsing of these scripts is not a recursive operation. The second 
> > safest thing to do is to remove the execute bit from those scripts.
> 
> Does this mean that we will remove the .sh extension on port rc.d startup
> scripts?  Because a) it's been only running .sh scripts for quite a
> while, and b) it's really nice and easy to disable scripts by moving
> them to .old or another extension..

Yes.  You should be able to disable any correctly written rc.d script by
setting the variable listed by running "

Re: HEADS UP: Please clean out your */etc/rc.d directories

[John-Mark Gurney]

Doug Barton wrote this message on Thu, Dec 22, 2005 at 01:50 -0800:
> I should have said this in my last heads up message, sorry for forgetting 
> about this important detail. The new code tries to run any script in a 
> local_startup directory (by default /usr/local/etc/rc.d and 
> /usr/X11R6/etc/rc.d) that has the execute bit set. So, if there is a script 
> in one of those directories that you don't want run at all, the safest 
> thing to do is to create a directory within rc.d, and move the script 
> there. Parsing of these scripts is not a recursive operation. The second 
> safest thing to do is to remove the execute bit from those scripts.

Does this mean that we will remove the .sh extension on port rc.d startup
scripts?  Because a) it's been only running .sh scripts for quite a
while, and b) it's really nice and easy to disable scripts by moving
them to .old or another extension..

Also, how will this effect cups which installs a .sample file?  and
any other port that does this?

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: FreeBSD 6.0 as storage server with raid5?

[Daniel Eriksson]

Joseph Kerian wrote:

> Hmm... I have to ask if you (or anyone else) has actually done this. 
> I attempted to run two Highpoint cards in the same machine about a
> year ago, and the Highpoint driver became extremely confused. They
> were nowhere near the same card (one was IDE, the other was a 1640),
> but the driver seemed to be having difficulty seperating the drives.

I'm running two RocketRAID 454 cards (4 channel ATA = 8 disks each) in
one of my servers. There is however explicit support for doing this in
the BIOS/firmware on these cards.

> Only one of the setup screens would appear on boot.  I tried different
> combinations of PCI slot locations and specific instructions to the
> driver to no avail.  I ended up using g/vinum for the IDE drives.
> I don't exactly remember the other card's model, but the 454 
> looks likely.

The disappearance of the BIOS/firmware config for your card(s) is not a
FreeBSD problem unfortunately. It has to do with how resources are
allocated by the motherboard's BIOS. I have a Tyan Tiger 2466M mobo
myself (dual Athlon MP) that I have populated with a SCSI card, a dual
port Gbit NIC and two RocketRAID 454 cards. To get it to boot I had to
use a jumper to forcefully disable the onboard 100Mbit NIC. And I still
cannot boot off of a floppy without first disconnecting at least one of
the cards.

You could try to update the BIOS on your motherboard. Some motherboards
also allows you to disable BIOS/firmware loading for certain PCI slots.
This could help free up some resources for cards that you don't boot
from.

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

Re: em bad performance

[Jack Vogel]

On 12/22/05, Gleb Smirnoff <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 22, 2005 at 12:37:53PM +0200, Danny Braniss wrote:
> D> > On Thu, Dec 22, 2005 at 12:24:42PM +0200, Danny Braniss wrote:
> D> > D> 
> D> > D> Server listening on TCP port 5001
> D> > D> TCP window size: 64.0 KByte (default)
> D> > D> 
> D> > D> [  4] local 132.65.16.100 port 5001 connected with [6.0/SE7501WV2] 
> port 58122
> D> > D> (intel westvill)
> D> > D> [ ID] Interval   Transfer Bandwidth
> D> > D> [  4]  0.0-10.0 sec  1.01 GBytes   867 Mbits/sec
> D> > D> [  4] local 132.65.16.100 port 5001 connected with [5.4/SE7501WV2] 
> port 55269
> D> > D> (intel westvill)
> D> > D> [ ID] Interval   Transfer Bandwidth
> D> > D> [  4]  0.0-10.0 sec   967 MBytes   811 Mbits/sec
> D> > D> [  5] local 132.65.16.100 port 5001 connected with [6.0/SR1435VP2 
> port 58363
> D> > D> (intel dual xeon/emt64)
> D> > D> [ ID] Interval   Transfer Bandwidth
> D> > D> [  5]  0.0-10.0 sec   578 MBytes   485 Mbits/sec
> D> > D>
> D> > D> i've run this several times, and the results are very similar.
> D> > D> i also tried i386, and the same bad results.
> D> > D> all hosts are connected at 1gb to the same switch.
> D> >
> D> > So we see a strong drawback between SE7501WV2 and SR1435VP2. Let's 
> compare the NIC
> D> > hardware. Can you plese show pciconf -lv | grep -A3 ^em on both 
> motherboards?
> D>
> D> on a SE7501WV2:
> D> [EMAIL PROTECTED]:7:0:   class=0x02 card=0x341a8086 chip=0x10108086 
> rev=0x01
> D> hdr=0x00
> D> vendor   = 'Intel Corporation'
> D> device   = '82546EB Dual Port Gigabit Ethernet Controller (Copper)'
> D> class= network
> D>
> D> on a SR1435VP2:
> D> [EMAIL PROTECTED]:3:0:   class=0x02 card=0x34668086 chip=0x10768086 
> rev=0x05
> D> hdr=0x00
> D> vendor   = 'Intel Corporation'
> D> device   = '82547EI Gigabit Ethernet Controller'
> D> class= network
>
> The first one 82546EB is attached to fast PCI-X bus, and the 82547EI is
> on CSA bus. The CSA bus is twice faster than old PCI bus, CSA can handle
> 266 Mbps. I'm not sure but may be it has same ~50% overhead as old PCI bus.
>
> Probably our em(4) driver is not optimized enough and does too many accesses
> to the PCI bus, thus utilizing more bandwidth than needed to handle traffic.
> In this case we see that NIC on slower bus (but enough to handle Gigabit) is
> must slower than NIC on faster bus. (This paragraph is my own theory, it
> can be complete bullshit.)

CSA bus? I've never heard of it.

To get the best gig performance you really want to see it on PCI Express.
I see 930ish Mb/s. I'm not really familiar with this motherboard/lom.

You say you run iperf -s on the server side, but what are you using as
parameters on the client end of the test?

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

Re: panic with RELENG_6, 2005-11-09 source

[Sam Leffler]

Rory Arms wrote:

I'm not subscribed to the list, so include me in any replies.

Now the report...

I'm reporting a kernel panic with a 6.0-STABLE machine using RELENG_6  
source from 2006-11-09.
It was triggered when I ran the command "ifconfig ath0 pureg" as an  
attempt to switch the  D-Link G520 running in hostAP mode, into "g  
only" mode. I did this because I've been experiencing slow rates with  
Airport Express clients (PowerBook) where no matter what the settings  
on the AP are, it refuses to go above 1 Mbit/s.


Here's the pertinent debug info:

from /etc/rc.conf

# ath0 to be bridged with fxp0. See /etc/sysctl.conf
ifconfig_ath0="inet up ssid FOO mode 11g mediaopt hostap -wme wepmode  
on wepkey 1:hexkeyhere authmode shared deftxkey 1 pureg"


Notice the "pureg" directive in there.. I added that after doing the  
interactive test mentioned above, which crashed the system. It seems  to 
be ok if it's enabled at boot time.


Also, I'm using bridge(4), so here's the relevant sysctl(8) oid:

net.link.ether.bridge.config: fxp0,ath0

Titan> sudo kgdb /usr/obj/usr/src/sys/TITAN/kernel.debug vmcore.15
Password:
[GDB will not be able to debug user-mode threads: /usr/lib/ 
libthread_db.so: Undefined symbol "ps_pglobal_lookup"]

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.

This GDB was configured as "i386-marcel-freebsd".

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x10002
fault code  = supervisor read, page not present
instruction pointer = 0x20:0xc059d5aa
stack pointer   = 0x28:0xd43f6ba4
frame pointer   = 0x28:0xd43f6ba8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 39 (swi6: task queue)
trap number = 12
panic: page fault
Uptime: 4d23h24m31s
Dumping 510 MB (2 chunks)
  chunk 0: 1MB (160 pages) ... ok
  chunk 1: 510MB (130416 pages) 494 478 462 446 430 414 398 382 366  350 
334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78  62 46 
30 14


#0  doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:165
#1  0xc0505706 in boot (howto=260) at /usr/src/sys/kern/ 
kern_shutdown.c:399

#2  0xc0505a10 in panic (fmt=0xc0714375 "%s")
at /usr/src/sys/kern/kern_shutdown.c:555
#3  0xc06ecea0 in trap_fatal (frame=0xd43f6b64, eva=0)
at /usr/src/sys/i386/i386/trap.c:831
#4  0xc06ecbc5 in trap_pfault (frame=0xd43f6b64, usermode=0, eva=65538)
at /usr/src/sys/i386/i386/trap.c:742
#5  0xc06ec7af in trap (frame=
  {tf_fs = -1045430264, tf_es = -734068696, tf_ds = -1068564440,  
tf_edi = -1045884500, tf_esi = -1045427200, tf_ebp = -734041176,  tf_isp 
= -734041200, tf_ebx = -1045884500, tf_edx = -1064610944,  tf_ecx = 
65535, tf_eax = 65535, tf_trapno = 12, tf_err = 0, tf_eip =  
-1067854422, tf_cs = 32, tf_eflags = 590338, tf_esp = -1009879030,  
tf_ss = -734041136}) at /usr/src/sys/i386/i386/trap.c:432

#6  0xc06db2ca in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7  0xc059d5aa in ieee80211_chan2mode (ic=0xc1a911ac, chan=0x)
at /usr/src/sys/net80211/ieee80211.c:892
#8  0xc05a9e5e in ieee80211_tmp_node (ic=0xc1a911ac,  macaddr=0xc3ce780a 
"")

at /usr/src/sys/net80211/ieee80211_node.c:225
#9  0xc05a007b in ieee80211_send_error (ic=0xc1a911ac, ni=0xc1b01000,
mac=0x , subtype=65535,  arg=65535)
at /usr/src/sys/net80211/ieee80211_input.c:957
#10 0xc059f15d in ieee80211_input (ic=0xc1a911ac, m=0xc1aab100,  
ni=0xc1b01000,

---Type  to continue, or q  to quit---
rssi=19, rstamp=23891) at /usr/src/sys/net80211/ ieee80211_input.c:341
#11 0xc0889aa4 in ?? ()
#12 0xc1a911ac in ?? ()
#13 0xc1aab100 in ?? ()
#14 0xc1b01000 in ?? ()
#15 0x0013 in ?? ()
#16 0x5d53 in ?? ()
#17 0xc1989a80 in ?? ()
#18 0xc1aab100 in ?? ()
#19 0xc1a3ab44 in ?? ()
#20 0xc1a93000 in ?? ()
#21 0xc1a82000 in ?? ()
#22 0xc1a911ac in ?? ()
#23 0xc1a920a8 in ?? ()
#24 0xc1a43480 in ?? ()
#25 0x0004 in ?? ()
#26 0xd43f6cc0 in ?? ()
#27 0xc0528ffa in taskqueue_run (queue=0xc1a9689c)
at /usr/src/sys/kern/subr_taskqueue.c:217
Previous frame identical to this frame (corrupt stack?)
(kgdb) Titan> uname -a
FreeBSD Titan 6.0-STABLE FreeBSD 6.0-STABLE #0: Wed Nov  9 22:03:41  MST 
2005  [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TITAN  i386


<...snip...>

The fix for this has been in HEAD for a while.  The MFC is in my queue. 
 If you want to patch your system look at rev 1.67 of 
net80211/ieee80211_node.c.


Sam
___

Re: Bug[?] In new local_startup and postgresql

[Cristiano Deana]

2005/12/22, Gary Smith <[EMAIL PROTECTED]>:

> I have the same problem the error on startup is:

> pg_ctl: unrecognized operation mode "faststart"
> try "pg_ctl --help" for more information

Same for me. Look at doug's reply:
http://lists.freebsd.org/pipermail/freebsd-ports/2005-December/028298.html

--
Cris, member of G.U.F.I
Italian FreeBSD User Group
http://www.gufi.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD 6.0 as storage server with raid5?

[Joseph Kerian]

On 12/13/05, Oliver Fromme <[EMAIL PROTECTED]> wrote:
> Sorry for the late reply ...
>
> Torfinn Ingolfsen <[EMAIL PROTECTED]> wrote:
>  > Highpoint RocketRAID 1640(4 ports)
>  > Promise FastTrak S150 SX4(4 ports)
>  > Promise FastTrak S150 SX4-M(4 ports)
>  > Highpoint RocketRAID 1810A(4 ports)
>  > Highpoint RocketRAID 1820A(8 ports)
>  > Intel RAID Controller SRCS16(6 ports)
>  > [...]
>  > 1) can I install several 4-port RAID controllers in one machine?
>
> Yes.
> There's no reason why you shouldn't be able to do that.

Hmm... I have to ask if you (or anyone else) has actually done this. 
I attempted to run two Highpoint cards in the same machine about a
year ago, and the Highpoint driver became extremely confused. They
were nowhere near the same card (one was IDE, the other was a 1640),
but the driver seemed to be having difficulty seperating the drives.
Only one of the setup screens would appear on boot.  I tried different
combinations of PCI slot locations and specific instructions to the
driver to no avail.  I ended up using g/vinum for the IDE drives.
I don't exactly remember the other card's model, but the 454 looks likely.

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

Re: Bug[?] In new local_startup and postgresql

[Gary Smith]

 > After a today upgrade to 6-STABLE postgresql doesn't start at boot.
> Strange beavior, if I run `/usr/local/etc/rc.d/010.pgsql.sh start' it
> starts correctly.
> 010.pgsql.sh is the same of updated ports.
> 
> This is 010.pgsql.sh :
> http://www.deana.it/010.pgsql.sh
> 
> Doug, this is resuls of running `sh rc' whit your patch:
> http://www.deana.it/rc.late
> 
> # grep postgresql_enable /etc/rc.conf
> postgresql_enable="YES"
> 
> This is the only one script doesn't working 
I have the same problem the error on startup is:

pg_ctl: unrecognized operation mode "faststart"
try "pg_ctl --help" for more information

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

Re: lsof on 6.0

[Melvyn Sopacua]

On Thursday 22 December 2005 16:27, Danny Braniss wrote:

> > > > Do you have a mount which is a symlink?
> > >
> > > no, but many nfs.
> > > minbari> mount
> > > 132.65.16.100:/d/6 on / (nfs)

> Breakpoint 1 at 0x402779: file dmnt.c, line 159.
> (gdb) run
> Starting program:
> /home/pobj/r+d/ports/sysutils/lsof/work/lsof_4.77A.freebsd/ls of
> lsof: WARNING: access /root/.lsof_shuttle-3: No such file or directory
> lsof: WARNING: can't open /root/.lsof_shuttle-3: Read-only file system
>
> Breakpoint 1, dev2udev (c=0xe) at dmnt.c:159
> 159 if (ln != dn)
> (gdb)  print sr
> $1 = -1
> (gdb)  print ln
> $2 = 0x525140 "132.65.16.100:/d/8"
> (gdb) print dn
> $3 = 0x525140 "132.65.16.100:/d/8"

As I figured, statsafely (which wraps around stat(2)) returns -1 on your nfs 
mount, therefore ss never gets set. I've got no idea what the "user device 
random seed" is needed for, so I suggest you file a pr with the above info.

Additionally, you can try the following patch to see why exactly the stat(2) 
call fails:
--- dmnt.c.orig Mon Oct  3 15:22:52 2005
+++ dmnt.c  Thu Dec 22 16:51:23 2005
@@ -163,6 +163,9 @@
dn = (char *)NULL;
if (sr)
continue;
+   else
+   (void)fprintf(stderr, "%s: cannot stat %s: %s\n", Pn, ln, 
strerror(errno));
+
ss = 1;
s = (u_int)sb.st_ino ^ (u_int)sb.st_rdev;
break;

-- 
Melvyn Sopacua
[EMAIL PROTECTED]

FreeBSD 6.0-STABLE
Qt: 3.3.5
KDE: 3.4.3
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Fatal trap 9: general protection fault while in kernel mode

[Yuri Khotyaintsev]

I have updated kernel/world today on the system which was running without any 
problems since I installed it (old kernel is from November 28) and i got this 
panic 10 minutes after boot (dmesg is attached below). The system is running 
FreeBSD/amd64 6-STABLE, SMP.

[EMAIL PROTECTED]/usr/obj/usr/src/sys/DB]# kgdb kernel.debug /var/crash/vmcore.0
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: 
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd".

Unread portion of the kernel message buffer:
kernel trap 9 with interrupts disabled


Fatal trap 9: general protection fault while in kernel mode
cpuid = 3; apic id = 07
instruction pointer = 0x8:0x803b9754
stack pointer   = 0x10:0xb35e0ab0
frame pointer   = 0x10:0xff02b3c0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 40 (irq34: mpt0)
trap number = 9
panic: general protection fault
cpuid = 3
Uptime: 2h2m14s
Dumping 4095 MB (3 chunks)
  chunk 0: 1MB (156 pages) ... ok
  chunk 1: 3583MB (917184 pages) 3567 3551 3535 3519 3503 3487 3471 3455 3439 
3423 3407 3391 3375 3359 3343 3327 3311 3295 3279 3263 3247 3231 3215 3199 
3183 3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991 2975 2959 
2943 2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 2719 
2703 2687 2671 2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 2479 
2463 2447 2431 2415 2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 2239 
2223 2207 2191 2175 2159 2143 2127 2111 2095 2079 2063 2047 2031 2015 1999 
1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 
1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 
1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 
1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 
1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 
719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 
415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 
111 95 79 63 47 31 15 ... ok
  chunk 2: 512MB (131072 pages) 497 481 465 449 433 417 401 385 369 353 337 
321 305 289 273 257 241 225 209 193 177 161 145 129 113 97 81 65 49 33 17 1

#0  doadump () at pcpu.h:172
172 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) where
#0  doadump () at pcpu.h:172
#1  0x0004 in ?? ()
#2  0x8025f637 in boot (howto=260) 
at /usr/src/sys/kern/kern_shutdown.c:399
#3  0x8025fc95 in panic (fmt=0xff011f66f980 "@�\037\001")
at /usr/src/sys/kern/kern_shutdown.c:555
#4  0x803c918a in trap_fatal (frame=0xff011f66f980, 
eva=18446742979019789120)
at /usr/src/sys/amd64/amd64/trap.c:660
#5  0x803c960e in trap (frame=
  {tf_rdi = -1099511450688, tf_rsi = 0, tf_rdx = -2143527384, tf_rcx = 0, 
tf_r8 = -1099511451648, tf_r9 = 9223372036854775807, tf_rax = 18, tf_rbx = 
-1099498667008, tf_rbp = -1099511450688, tf_r10 = 0, tf_r11 = -1094689762496, 
tf_r12 = -1099511146240, tf_r13 = 18, tf_r14 = -1094689818240, tf_r15 = 
-1285682416, tf_trapno = 9, tf_addr = 0, tf_flags = -2145094526, tf_err = 0, 
tf_rip = -2143578284, tf_cs = 8, tf_rflags = 65606, tf_rsp = -1285682496, 
tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:469
#6  0x803b71bb in calltrap () 
at /usr/src/sys/amd64/amd64/exception.S:168
#7  0x803b9754 in intr_execute_handlers (isrc=0xff02b3c0,
iframe=0xb35e0b10) at /usr/src/sys/amd64/amd64/intr_machdep.c:213
#8  0x803bbdd1 in lapic_handle_intr (cookie=0xff02b3c0, frame=
  {if_rdi = -1094689818240, if_rsi = -1094689818240, if_rdx = 582, if_rcx 
= 0, if_r8 = -1285681904, if_r9 = 9223372036854775807, if_rax = 0, if_rbx = 
-1094689818240, if_rbp = 0, if_r10 = 0, if_r11 = -1094689762496, if_r12 = 
-1099511148288, if_r13 = -1094689818240, if_r14 = 0, if_r15 = -1094689762496, 
if_rip = -2143566227, if_cs = 8, if_rflags = 582, if_rsp = -1285682224, if_ss 
= 16}) at /usr/src/sys/amd64/amd64/local_apic.c:612
#9  0x803b76bd in Xapic_isr2 () at apic_vector.S:133
#10 0x803bc66d in spinlock_exit () at cpufunc.h:391
#11 0x80247952 in ithread_loop (arg=0xff075100)
at /usr/src/sys/kern/kern_intr.c:597
#12 0x802462d4 in fork_exit (callout=0x802475fe 
,
arg=0xff075100, frame=0xb35e0c50) 
at /usr/src/sys/kern/kern_fork.c:789
---Type  to cont

Re: lsof on 6.0

[Danny Braniss]

> On Thursday 22 December 2005 14:51, Danny Braniss wrote:
> > > On Thursday 22 December 2005 12:36, Danny Braniss wrote:
> > > > > On Thu, 22 Dec 2005 10:12:17 +0200
> > > > >
> > > > > Danny Braniss <[EMAIL PROTECTED]> wrote:
> > > > > > i keep getting:
> > > > > > lsof: can't determine user device random seed.
> > > > > > is it only me?
> > > > >
> > > > > both as a normal user and as root.
> > > > > I don't see the message you are referring to.
> > > >
> > > > either root, or just a mere mortal, just typing lsof, no arguments:
> > > >
> > > > shuttle-3> lsof
> > > > lsof: can't determine user device random seed.
> > >
> > > Do you have a mount which is a symlink?
> >
> > no, but many nfs.
> > minbari> mount
> > 132.65.16.100:/d/6 on / (nfs)
> 
> nfs mounted root. I think that's the problem. 
> If you can compile as follows:
> env CFLAGS='-g -pipe' STRIP= make install
> 
> then run:
> gdb /usr/local/sbin/lsof
> 
> At gdb:
> (gdb) break dmnt.c:159
> (gdb) run
> 
> When breaking:
> (gdb) print sr
> (gdb) print ln
> (gdb) print dn

and here it is:

shuttle-3# gdb ./lsof
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) break dmnt.c:159
Breakpoint 1 at 0x402779: file dmnt.c, line 159.
(gdb) run
Starting program: /home/pobj/r+d/ports/sysutils/lsof/work/lsof_4.77A.freebsd/ls
of
lsof: WARNING: access /root/.lsof_shuttle-3: No such file or directory
lsof: WARNING: can't open /root/.lsof_shuttle-3: Read-only file system

Breakpoint 1, dev2udev (c=0xe) at dmnt.c:159
159 if (ln != dn)
(gdb)  print sr
$1 = -1
(gdb)  print ln
$2 = 0x525140 "132.65.16.100:/d/8"
(gdb) print dn
$3 = 0x525140 "132.65.16.100:/d/8"



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

Re: gmirror SCSI+IDE

[Ivan Voras]

On Wed, 21 Dec 2005, Brian Fundakowski Feldman wrote:


On Fri, Dec 16, 2005 at 06:39:18PM +0100, Ivan Voras wrote:

For some funny reasons, I'll probably have to setup a gmirror between a
SCSI disk device and a IDE one, and won't have much time for testing. So


Might have bad performance, who knows.  Why the funny setup exactly?


Historical reasons, involving 5 year old SCSI RAID field, a system BIOS 
that's extremely fussy about devices it wants to boot from, a couple 
of IDE drives and general lack of funding.



--
Preserve wildlife -- pickle a squirrel today!

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

Re: lsof on 6.0

[Melvyn Sopacua]

On Thursday 22 December 2005 14:51, Danny Braniss wrote:
> > On Thursday 22 December 2005 12:36, Danny Braniss wrote:
> > > > On Thu, 22 Dec 2005 10:12:17 +0200
> > > >
> > > > Danny Braniss <[EMAIL PROTECTED]> wrote:
> > > > > i keep getting:
> > > > >   lsof: can't determine user device random seed.
> > > > > is it only me?
> > > >
> > > > both as a normal user and as root.
> > > > I don't see the message you are referring to.
> > >
> > > either root, or just a mere mortal, just typing lsof, no arguments:
> > >
> > > shuttle-3> lsof
> > > lsof: can't determine user device random seed.
> >
> > Do you have a mount which is a symlink?
>
> no, but many nfs.
> minbari> mount
> 132.65.16.100:/d/6 on / (nfs)

nfs mounted root. I think that's the problem. 
If you can compile as follows:
env CFLAGS='-g -pipe' STRIP= make install

then run:
gdb /usr/local/sbin/lsof

At gdb:
(gdb) break dmnt.c:159
(gdb) run

When breaking:
(gdb) print sr
(gdb) print ln
(gdb) print dn


-- 
Melvyn Sopacua
[EMAIL PROTECTED]

FreeBSD 6.0-STABLE
Qt: 3.3.5
KDE: 3.4.3
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: lsof on 6.0

[Danny Braniss]

> On Thursday 22 December 2005 12:36, Danny Braniss wrote:
> > > On Thu, 22 Dec 2005 10:12:17 +0200
> > >
> > > Danny Braniss <[EMAIL PROTECTED]> wrote:
> > > > i keep getting:
> > > > lsof: can't determine user device random seed.
> > > > is it only me?
> 
> > > both as a normal user and as root.
> > > I don't see the message you are referring to.
> >
> > either root, or just a mere mortal, just typing lsof, no arguments:
> >
> > shuttle-3> lsof
> > lsof: can't determine user device random seed.
> 
> Do you have a mount which is a symlink?

no, but many nfs.
minbari> mount
132.65.16.100:/d/6 on / (nfs)
devfs on /dev (devfs, local)
/dev/md0 on /.etc (ufs, local, soft-updates)
:/.etc on /etc (unionfs, noclusterw)
procfs on /proc (procfs, local)
/dev/md1 on /var (ufs, NFS exported, local)
/dev/md2 on /a (ufs, local, soft-updates)
[EMAIL PROTECTED]:/usr/local on /usr/local (nfs)
[EMAIL PROTECTED]:/Platform on /Platform (nfs)
[EMAIL PROTECTED]:/vol on /vol (nfs)
[EMAIL PROTECTED]:/net on /net (nfs)
[EMAIL PROTECTED]:/cs on /cs (nfs)
x-dev:/dist on /dist (nfs)
fs-01:/system on /a/fs-01/system (nfs)

> -- 
> Melvyn Sopacua
> [EMAIL PROTECTED]
> 
> FreeBSD 6.0-STABLE
> Qt: 3.3.5
> KDE: 3.4.3
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 


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

Re: lsof on 6.0

[Melvyn Sopacua]

On Thursday 22 December 2005 12:36, Danny Braniss wrote:
> > On Thu, 22 Dec 2005 10:12:17 +0200
> >
> > Danny Braniss <[EMAIL PROTECTED]> wrote:
> > > i keep getting:
> > >   lsof: can't determine user device random seed.
> > > is it only me?

> > both as a normal user and as root.
> > I don't see the message you are referring to.
>
> either root, or just a mere mortal, just typing lsof, no arguments:
>
> shuttle-3> lsof
> lsof: can't determine user device random seed.

Do you have a mount which is a symlink?
-- 
Melvyn Sopacua
[EMAIL PROTECTED]

FreeBSD 6.0-STABLE
Qt: 3.3.5
KDE: 3.4.3
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: gvinum: adding plex and subdisks to existing volume panic

[Ludo Koren]

>Unfortunately, that doesn't help me at all, since there's no debugging 
>info.  Have a look at 
>.

sorry I realized it late...

Here is the info:

Script started on Thu Dec 22 12:25:56 2005
501 gw|/var/crash>kgdb /usr/obj/usr/src/sys/INTIME/kernel.debug vmcore.17
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: 
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".

Unread portion of the kernel message buffer:
Copyright (c) 1992-2005 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.4-STABLE #0: Thu Dec 22 10:41:32 CET 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/INTIME
ACPI APIC Table: 
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) 4 CPU 1.60GHz (1599.96-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf12  Stepping = 2
  
Features=0x3febfbff
real memory  = 1071906816 (1022 MB)
avail memory = 1042771968 (994 MB)
ioapic0: Changing APIC ID to 1
ioapic0  irqs 0-23 on motherboard
netsmb_dev: loaded
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
cpu0:  on acpi0
acpi_throttle0:  on cpu0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
agp0:  mem 
0xffa8-0xffaf,0xf000-0xf7ff irq 16 at device 2.0 on pci0
agp0: detected 892k stolen memory
agp0: aperture size is 128M
uhci0:  port 0xe800-0xe81f irq 16 at 
device 29.0 on pci0
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1:  port 0xe880-0xe89f irq 19 at 
device 29.1 on pci0
usb1:  on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2:  port 0xec00-0xec1f irq 18 at 
device 29.2 on pci0
usb2:  on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
pci0:  at device 29.7 (no driver attached)
pcib1:  at device 30.0 on pci0
pci1:  on pcib1
ahd0:  port 0xde00-0xdeff,0xd000-0xd0ff 
mem 0xff8fc000-0xff8fdfff irq 22 at device 1.0 on pci1
aic7902: Ultra320 Wide Channel A, SCSI Id=15, PCI 33 or 66Mhz, 512 SCBs
ahd1:  port 0xd400-0xd4ff,0xd800-0xd8ff 
mem 0xff8fe000-0xff8f irq 21 at device 1.1 on pci1
aic7902: Ultra320 Wide Channel B, SCSI Id=15, PCI 33 or 66Mhz, 512 SCBs
fxp0:  port 0xdc00-0xdc3f mem 
0xff8fb000-0xff8fbfff irq 20 at device 8.0 on pci1
miibus0:  on fxp0
inphy0:  on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:03:47:ff:6e:9f
isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci0:  port 
0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0
ata0: channel #0 on atapci0
ata1: channel #1 on atapci0
pci0:  at device 31.3 (no driver attached)
pci0:  at device 31.5 (no driver attached)
acpi_button0:  on acpi0
fdc0:  port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 
irq 6 drq 2 on acpi0
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
ppc0:  port 0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
ppbus0:  on ppc0
plip0:  on ppbus0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
atkbdc0:  port 0x64,0x60 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
pmtimer0 on isa0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounter "TSC" frequency 1599956116 Hz quality 800
Timecounters tick every 10.000 msec
Waiting 5 seconds for SCSI devices to settle
sa0 at ahd0 bus 0 target 10 lun 0
sa0:  Removable Sequential Access SCSI-2 device 
sa0: 40.000MB/s transfers (20.000MHz, offset 32, 16bit)
da0 at ahd0 bus 0 target 3 lun 0
da0:  Fixed Direct Access SCSI-3 device 
da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing 
Enabled
da0: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C)
da1 at ahd0 bus 0 target 9 lun 0
da1:  Fixed Direct Access SCSI-3 device 
da1: 320.000MB/s transfers (160.000

Re: lsof on 6.0

[Torfinn Ingolfsen]

On Thu, 22 Dec 2005 13:36:40 +0200
Danny Braniss <[EMAIL PROTECTED]> wrote:

> shuttle-3> lsof -v lsof version information:

I forgot that one, here it is:
[EMAIL PROTECTED] lsof -v
lsof version information:
revision: 4.77
latest revision: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/
latest FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
latest man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man
constructed: Thu Dec 22 12:00:24 CET 2005
constructed by and on: [EMAIL PROTECTED]
compiler: cc
compiler flags: -pipe -DHASEFFNLINK=i_effnlink -DHASF_VNODE -DHASCPUMASK_T 
-DHASSBSTATE -DHAS_KVM_VNODE -DHAS_UFS1_2 -DHAS_NO_SI_UDEV -DHAS_SI_PRIV 
-DFREEBSDV=6000 -DHASFDESCFS=2 -DHASPSEUDOFS -DHASNULLFS -DHAS9660FS 
-DHAS_NO_ISO_DEV -DHASIPv6 -DLSOF_VSTR="6.0-STABLE" -I/usr/src/sys -O
loader flags: -L./lib -llsof -lkvm
system info: FreeBSD kg-quiet.kg4.no 6.0-STABLE FreeBSD 6.0-STABLE #1: Thu 
Dec 22 06:29:24 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/QUIET amd64
Only root can list all files.
/dev warnings are enabled.
Kernel ID check is enabled.
Device cache file read-only paths:
Named via -D: none
Named in environment variable LSOFDEVCACHE: none
Personal path format (HASPERSDC): "%h/%p.lsof_%L"
Modified personal path environment variable: LSOFPERSDCPATH
LSOFPERSDCPATH value: none
Personal path: /root/.lsof_kg-quiet
Device cache file write paths:
Named via -D: none
Named in environment variable LSOFDEVCACHE: none
Personal path format (HASPERSDC): "%h/%p.lsof_%L"
Modified personal path environment variable: LSOFPERSDCPATH
LSOFPERSDCPATH value: none
Personal path: /root/.lsof_kg-quiet

I don't have any more suggestions.
-- 
Regards,
Torfinn Ingolfsen,
Norway

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

Re: lsof on 6.0

[Danny Braniss]

> On Thu, 22 Dec 2005 10:12:17 +0200
> Danny Braniss <[EMAIL PROTECTED]> wrote:
> 
> > i keep getting:
> > lsof: can't determine user device random seed.
> > is it only me?
> 
> You'll have to be more specific: do you get that by doing only 'lsof' or
> are you using any parameters? _Do you run as a normal user, or as root?
> FWIW, plain 'lsof' works here, on
> 
> [EMAIL PROTECTED] uname -a
> FreeBSD kg-quiet.kg4.no 6.0-STABLE FreeBSD 6.0-STABLE #1: Thu Dec 22
> 06:29:24 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/QUIET 
> amd64
> 
> both as a normal user and as root.
> I don't see the message you are referring to.
either root, or just a mere mortal, just typing lsof, no arguments:

shuttle-3> lsof
lsof: can't determine user device random seed.
shuttle-3> uname -a
FreeBSD shuttle-3 6.0-STABLE FreeBSD 6.0-STABLE #23: Mon Dec 19 11:53:42 IST 
2005 [EMAIL PROTECTED]:/r+d/obj/x-dev/amd64/r+d/6.0/src/sys/HUJI  amd64
shuttle-3> lsof -v
lsof version information:
revision: 4.77
latest revision: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/
latest FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
latest man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man
constructed: Thu Dec 22 09:42:49 IST 2005
constructed by and on: [EMAIL PROTECTED]
compiler: cc
compiler flags: -fno-strict-aliasing -pipe -DHASEFFNLINK=i_effnlink 
-DHASF_VNODE -DHASCPUMASK_T -DHASSBSTATE -DHAS_KVM_VNODE -D
HAS_UFS1_2 -DHAS_NO_SI_UDEV -DHAS_SI_PRIV -DFREEBSDV=6000 -DHASFDESCFS=2 
-DHASPSEUDOFS -DHASNULLFS -DHAS9660FS -DHAS_NO_ISO_DEV -DH
ASIPv6 -DLSOF_VSTR="6.0-STABLE" -I/usr/src/sys -O2
loader flags: -L./lib -llsof -lkvm
system info: FreeBSD shuttle-3 6.0-STABLE FreeBSD 6.0-STABLE #23: Mon Dec 
19 11:53:42 IST 2005 [EMAIL PROTECTED]:/r+d/obj/x-dev/amd64
/r+d/6.0/src/sys/HUJI amd64
Only root can list all files.
/dev warnings are enabled.
Kernel ID check is enabled.
Device cache file read-only paths:
Named via -D: none
Named in environment variable LSOFDEVCACHE: none
Personal path format (HASPERSDC): "%h/%p.lsof_%L"
Modified personal path environment variable: LSOFPERSDCPATH
LSOFPERSDCPATH value: none
Personal path: /cs/system/danny/.lsof_shuttle-3
Device cache file write paths:
Named via -D: none
Named in environment variable LSOFDEVCACHE: none
Personal path format (HASPERSDC): "%h/%p.lsof_%L"
Modified personal path environment variable: LSOFPERSDCPATH
LSOFPERSDCPATH value: none
Personal path: /cs/system/danny/.lsof_shuttle-3


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

Re: em bad performance

[Danny Braniss]

> On Thu, Dec 22, 2005 at 12:37:53PM +0200, Danny Braniss wrote:
> D> > On Thu, Dec 22, 2005 at 12:24:42PM +0200, Danny Braniss wrote:
> D> > D> 
> D> > D> Server listening on TCP port 5001
> D> > D> TCP window size: 64.0 KByte (default)
> D> > D> 
> D> > D> [  4] local 132.65.16.100 port 5001 connected with [6.0/SE7501WV2] 
> port 58122 
> D> > D> (intel westvill)
> D> > D> [ ID] Interval   Transfer Bandwidth
> D> > D> [  4]  0.0-10.0 sec  1.01 GBytes   867 Mbits/sec
> D> > D> [  4] local 132.65.16.100 port 5001 connected with [5.4/SE7501WV2] 
> port 55269 
> D> > D> (intel westvill)
> D> > D> [ ID] Interval   Transfer Bandwidth
> D> > D> [  4]  0.0-10.0 sec   967 MBytes   811 Mbits/sec
> D> > D> [  5] local 132.65.16.100 port 5001 connected with [6.0/SR1435VP2 
> port 58363  
> D> > D> (intel dual xeon/emt64)
> D> > D> [ ID] Interval   Transfer Bandwidth
> D> > D> [  5]  0.0-10.0 sec   578 MBytes   485 Mbits/sec
> D> > D> 
> D> > D> i've run this several times, and the results are very similar.
> D> > D> i also tried i386, and the same bad results.
> D> > D> all hosts are connected at 1gb to the same switch.
> D> > 
> D> > So we see a strong drawback between SE7501WV2 and SR1435VP2. Let's 
> compare the NIC
> D> > hardware. Can you plese show pciconf -lv | grep -A3 ^em on both 
> motherboards?
> D> 
> D> on a SE7501WV2:
> D> [EMAIL PROTECTED]:7:0:   class=0x02 card=0x341a8086 chip=0x10108086 
> rev=0x01 
> D> hdr=0x00
> D> vendor   = 'Intel Corporation'
> D> device   = '82546EB Dual Port Gigabit Ethernet Controller (Copper)'
> D> class= network
> D> 
> D> on a SR1435VP2:
> D> [EMAIL PROTECTED]:3:0:   class=0x02 card=0x34668086 chip=0x10768086 
> rev=0x05 
> D> hdr=0x00
> D> vendor   = 'Intel Corporation'
> D> device   = '82547EI Gigabit Ethernet Controller'
> D> class= network
> 
> The first one 82546EB is attached to fast PCI-X bus, and the 82547EI is
> on CSA bus. The CSA bus is twice faster than old PCI bus, CSA can handle
> 266 Mbps. I'm not sure but may be it has same ~50% overhead as old PCI bus.
> 
> Probably our em(4) driver is not optimized enough and does too many accesses
> to the PCI bus, thus utilizing more bandwidth than needed to handle traffic.
> In this case we see that NIC on slower bus (but enough to handle Gigabit) is
> must slower than NIC on faster bus. (This paragraph is my own theory, it
> can be complete bullshit.)

humph, alway read the small letters:
from Intel Server Board SE7320VP2 TPC:

... The device interfaces with the 6300ESB ICH from the 32-bit
PCI 2.3 compliant bus running at 33MHz.

so now is back to waiting for Yukon driver from Marvell, which is
supposed to come out RSN.

thanks,
danny


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

Re: lsof on 6.0

[Torfinn Ingolfsen]

On Thu, 22 Dec 2005 10:12:17 +0200
Danny Braniss <[EMAIL PROTECTED]> wrote:

> i keep getting:
>   lsof: can't determine user device random seed.
> is it only me?

You'll have to be more specific: do you get that by doing only 'lsof' or
are you using any parameters? _Do you run as a normal user, or as root?
FWIW, plain 'lsof' works here, on

[EMAIL PROTECTED] uname -a
FreeBSD kg-quiet.kg4.no 6.0-STABLE FreeBSD 6.0-STABLE #1: Thu Dec 22
06:29:24 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/QUIET 
amd64

both as a normal user and as root.
I don't see the message you are referring to.
-- 
Regards,
Torfinn Ingolfsen,
Norway

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

Re: em bad performance

[Gleb Smirnoff]

On Thu, Dec 22, 2005 at 12:37:53PM +0200, Danny Braniss wrote:
D> > On Thu, Dec 22, 2005 at 12:24:42PM +0200, Danny Braniss wrote:
D> > D> 
D> > D> Server listening on TCP port 5001
D> > D> TCP window size: 64.0 KByte (default)
D> > D> 
D> > D> [  4] local 132.65.16.100 port 5001 connected with [6.0/SE7501WV2] port 
58122 
D> > D> (intel westvill)
D> > D> [ ID] Interval   Transfer Bandwidth
D> > D> [  4]  0.0-10.0 sec  1.01 GBytes   867 Mbits/sec
D> > D> [  4] local 132.65.16.100 port 5001 connected with [5.4/SE7501WV2] port 
55269 
D> > D> (intel westvill)
D> > D> [ ID] Interval   Transfer Bandwidth
D> > D> [  4]  0.0-10.0 sec   967 MBytes   811 Mbits/sec
D> > D> [  5] local 132.65.16.100 port 5001 connected with [6.0/SR1435VP2 port 
58363  
D> > D> (intel dual xeon/emt64)
D> > D> [ ID] Interval   Transfer Bandwidth
D> > D> [  5]  0.0-10.0 sec   578 MBytes   485 Mbits/sec
D> > D> 
D> > D> i've run this several times, and the results are very similar.
D> > D> i also tried i386, and the same bad results.
D> > D> all hosts are connected at 1gb to the same switch.
D> > 
D> > So we see a strong drawback between SE7501WV2 and SR1435VP2. Let's compare 
the NIC
D> > hardware. Can you plese show pciconf -lv | grep -A3 ^em on both 
motherboards?
D> 
D> on a SE7501WV2:
D> [EMAIL PROTECTED]:7:0:   class=0x02 card=0x341a8086 chip=0x10108086 
rev=0x01 
D> hdr=0x00
D> vendor   = 'Intel Corporation'
D> device   = '82546EB Dual Port Gigabit Ethernet Controller (Copper)'
D> class= network
D> 
D> on a SR1435VP2:
D> [EMAIL PROTECTED]:3:0:   class=0x02 card=0x34668086 chip=0x10768086 
rev=0x05 
D> hdr=0x00
D> vendor   = 'Intel Corporation'
D> device   = '82547EI Gigabit Ethernet Controller'
D> class= network

The first one 82546EB is attached to fast PCI-X bus, and the 82547EI is
on CSA bus. The CSA bus is twice faster than old PCI bus, CSA can handle
266 Mbps. I'm not sure but may be it has same ~50% overhead as old PCI bus.

Probably our em(4) driver is not optimized enough and does too many accesses
to the PCI bus, thus utilizing more bandwidth than needed to handle traffic.
In this case we see that NIC on slower bus (but enough to handle Gigabit) is
must slower than NIC on faster bus. (This paragraph is my own theory, it
can be complete bullshit.)

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: panic with RELENG_6, 2005-11-09 source

[Dave Horsfall]

On Thu, 22 Dec 2005, Rory Arms wrote:

> I'm not subscribed to the list, so include me in any replies.

So that explains the spam I get via this list...  It's a spam magnet.

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

Re: em bad performance

[Danny Braniss]

> On Thu, Dec 22, 2005 at 12:24:42PM +0200, Danny Braniss wrote:
> D> 
> D> Server listening on TCP port 5001
> D> TCP window size: 64.0 KByte (default)
> D> 
> D> [  4] local 132.65.16.100 port 5001 connected with [6.0/SE7501WV2] port 
> 58122 
> D> (intel westvill)
> D> [ ID] Interval   Transfer Bandwidth
> D> [  4]  0.0-10.0 sec  1.01 GBytes   867 Mbits/sec
> D> [  4] local 132.65.16.100 port 5001 connected with [5.4/SE7501WV2] port 
> 55269 
> D> (intel westvill)
> D> [ ID] Interval   Transfer Bandwidth
> D> [  4]  0.0-10.0 sec   967 MBytes   811 Mbits/sec
> D> [  5] local 132.65.16.100 port 5001 connected with [6.0/SR1435VP2 port 
> 58363  
> D> (intel dual xeon/emt64)
> D> [ ID] Interval   Transfer Bandwidth
> D> [  5]  0.0-10.0 sec   578 MBytes   485 Mbits/sec
> D> 
> D> i've run this several times, and the results are very similar.
> D> i also tried i386, and the same bad results.
> D> all hosts are connected at 1gb to the same switch.
> 
> So we see a strong drawback between SE7501WV2 and SR1435VP2. Let's compare 
> the NIC
> hardware. Can you plese show pciconf -lv | grep -A3 ^em on both motherboards?

on a SE7501WV2:
[EMAIL PROTECTED]:7:0:   class=0x02 card=0x341a8086 chip=0x10108086 
rev=0x01 
hdr=0x00
vendor   = 'Intel Corporation'
device   = '82546EB Dual Port Gigabit Ethernet Controller (Copper)'
class= network

on a SR1435VP2:
[EMAIL PROTECTED]:3:0:   class=0x02 card=0x34668086 chip=0x10768086 
rev=0x05 
hdr=0x00
vendor   = 'Intel Corporation'
device   = '82547EI Gigabit Ethernet Controller'
class= network

thanks,
danny


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

Re: em bad performance

[Gleb Smirnoff]

On Thu, Dec 22, 2005 at 12:24:42PM +0200, Danny Braniss wrote:
D> 
D> Server listening on TCP port 5001
D> TCP window size: 64.0 KByte (default)
D> 
D> [  4] local 132.65.16.100 port 5001 connected with [6.0/SE7501WV2] port 
58122 
D> (intel westvill)
D> [ ID] Interval   Transfer Bandwidth
D> [  4]  0.0-10.0 sec  1.01 GBytes   867 Mbits/sec
D> [  4] local 132.65.16.100 port 5001 connected with [5.4/SE7501WV2] port 
55269 
D> (intel westvill)
D> [ ID] Interval   Transfer Bandwidth
D> [  4]  0.0-10.0 sec   967 MBytes   811 Mbits/sec
D> [  5] local 132.65.16.100 port 5001 connected with [6.0/SR1435VP2 port 58363 
 
D> (intel dual xeon/emt64)
D> [ ID] Interval   Transfer Bandwidth
D> [  5]  0.0-10.0 sec   578 MBytes   485 Mbits/sec
D> 
D> i've run this several times, and the results are very similar.
D> i also tried i386, and the same bad results.
D> all hosts are connected at 1gb to the same switch.

So we see a strong drawback between SE7501WV2 and SR1435VP2. Let's compare the 
NIC
hardware. Can you plese show pciconf -lv | grep -A3 ^em on both motherboards?

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: em bad performance

[Danny Braniss]

> On Wed, Dec 21, 2005 at 06:55:29PM +0200, Danny Braniss wrote:
> D>this particular mb, intel sr1435vp2, has 2 ethernets,
> D> one is an Intel '82547EI Gigabit Ethernet Controller', the other is
> D> a Marvell (which seems that the driver is around the corner).
> D> 
> D> the em performance under 6.0-stable is half of any other box i have,
> D> and a similar mb running linux gives about 1GB, so
> D> 
> D>Q: any ideas what can be wrong?
> 
> Please be more informative. How do you measure performance: netperf,
> ftp, ... ?

iperf

iperf -s

Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)

[  4] local 132.65.16.100 port 5001 connected with [6.0/SE7501WV2] port 58122 
(intel westvill)
[ ID] Interval   Transfer Bandwidth
[  4]  0.0-10.0 sec  1.01 GBytes   867 Mbits/sec
[  4] local 132.65.16.100 port 5001 connected with [5.4/SE7501WV2] port 55269 
(intel westvill)
[ ID] Interval   Transfer Bandwidth
[  4]  0.0-10.0 sec   967 MBytes   811 Mbits/sec
[  5] local 132.65.16.100 port 5001 connected with [6.0/SR1435VP2 port 58363  
(intel dual xeon/emt64)
[ ID] Interval   Transfer Bandwidth
[  5]  0.0-10.0 sec   578 MBytes   485 Mbits/sec

i've run this several times, and the results are very similar.
i also tried i386, and the same bad results.
all hosts are connected at 1gb to the same switch.

> 
> What is the box doing: routing, bridging, running ftp server?
nothing :-(
i noticed the badness when trying to set it up as my new dev. machine
and tried a make buildworld, and after 4hs i realized that something
is bad.

danny



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

panic with RELENG_6, 2005-11-09 source

[Rory Arms]

I'm not subscribed to the list, so include me in any replies.

Now the report...

I'm reporting a kernel panic with a 6.0-STABLE machine using RELENG_6  
source from 2006-11-09.
It was triggered when I ran the command "ifconfig ath0 pureg" as an  
attempt to switch the  D-Link G520 running in hostAP mode, into "g  
only" mode. I did this because I've been experiencing slow rates with  
Airport Express clients (PowerBook) where no matter what the settings  
on the AP are, it refuses to go above 1 Mbit/s.


Here's the pertinent debug info:

from /etc/rc.conf

# ath0 to be bridged with fxp0. See /etc/sysctl.conf
ifconfig_ath0="inet up ssid FOO mode 11g mediaopt hostap -wme wepmode  
on wepkey 1:hexkeyhere authmode shared deftxkey 1 pureg"


Notice the "pureg" directive in there.. I added that after doing the  
interactive test mentioned above, which crashed the system. It seems  
to be ok if it's enabled at boot time.


Also, I'm using bridge(4), so here's the relevant sysctl(8) oid:

net.link.ether.bridge.config: fxp0,ath0

Titan> sudo kgdb /usr/obj/usr/src/sys/TITAN/kernel.debug vmcore.15
Password:
[GDB will not be able to debug user-mode threads: /usr/lib/ 
libthread_db.so: Undefined symbol "ps_pglobal_lookup"]

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.

This GDB was configured as "i386-marcel-freebsd".

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x10002
fault code  = supervisor read, page not present
instruction pointer = 0x20:0xc059d5aa
stack pointer   = 0x28:0xd43f6ba4
frame pointer   = 0x28:0xd43f6ba8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 39 (swi6: task queue)
trap number = 12
panic: page fault
Uptime: 4d23h24m31s
Dumping 510 MB (2 chunks)
  chunk 0: 1MB (160 pages) ... ok
  chunk 1: 510MB (130416 pages) 494 478 462 446 430 414 398 382 366  
350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78  
62 46 30 14


#0  doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:165
#1  0xc0505706 in boot (howto=260) at /usr/src/sys/kern/ 
kern_shutdown.c:399

#2  0xc0505a10 in panic (fmt=0xc0714375 "%s")
at /usr/src/sys/kern/kern_shutdown.c:555
#3  0xc06ecea0 in trap_fatal (frame=0xd43f6b64, eva=0)
at /usr/src/sys/i386/i386/trap.c:831
#4  0xc06ecbc5 in trap_pfault (frame=0xd43f6b64, usermode=0, eva=65538)
at /usr/src/sys/i386/i386/trap.c:742
#5  0xc06ec7af in trap (frame=
  {tf_fs = -1045430264, tf_es = -734068696, tf_ds = -1068564440,  
tf_edi = -1045884500, tf_esi = -1045427200, tf_ebp = -734041176,  
tf_isp = -734041200, tf_ebx = -1045884500, tf_edx = -1064610944,  
tf_ecx = 65535, tf_eax = 65535, tf_trapno = 12, tf_err = 0, tf_eip =  
-1067854422, tf_cs = 32, tf_eflags = 590338, tf_esp = -1009879030,  
tf_ss = -734041136}) at /usr/src/sys/i386/i386/trap.c:432

#6  0xc06db2ca in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7  0xc059d5aa in ieee80211_chan2mode (ic=0xc1a911ac, chan=0x)
at /usr/src/sys/net80211/ieee80211.c:892
#8  0xc05a9e5e in ieee80211_tmp_node (ic=0xc1a911ac,  
macaddr=0xc3ce780a "")

at /usr/src/sys/net80211/ieee80211_node.c:225
#9  0xc05a007b in ieee80211_send_error (ic=0xc1a911ac, ni=0xc1b01000,
mac=0x , subtype=65535,  
arg=65535)

at /usr/src/sys/net80211/ieee80211_input.c:957
#10 0xc059f15d in ieee80211_input (ic=0xc1a911ac, m=0xc1aab100,  
ni=0xc1b01000,

---Type  to continue, or q  to quit---
rssi=19, rstamp=23891) at /usr/src/sys/net80211/ 
ieee80211_input.c:341

#11 0xc0889aa4 in ?? ()
#12 0xc1a911ac in ?? ()
#13 0xc1aab100 in ?? ()
#14 0xc1b01000 in ?? ()
#15 0x0013 in ?? ()
#16 0x5d53 in ?? ()
#17 0xc1989a80 in ?? ()
#18 0xc1aab100 in ?? ()
#19 0xc1a3ab44 in ?? ()
#20 0xc1a93000 in ?? ()
#21 0xc1a82000 in ?? ()
#22 0xc1a911ac in ?? ()
#23 0xc1a920a8 in ?? ()
#24 0xc1a43480 in ?? ()
#25 0x0004 in ?? ()
#26 0xd43f6cc0 in ?? ()
#27 0xc0528ffa in taskqueue_run (queue=0xc1a9689c)
at /usr/src/sys/kern/subr_taskqueue.c:217
Previous frame identical to this frame (corrupt stack?)
(kgdb) Titan> uname -a
FreeBSD Titan 6.0-STABLE FreeBSD 6.0-STABLE #0: Wed Nov  9 22:03:41  
MST 2005  [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TITAN  i386


Titan> kldstat
Id Refs AddressSize Name
1   12 0xc040 442f64   kernel
21 0xc0843000 9150 bridge.ko
31 0xc084d000 32e28ipl.ko
41 0xc088 11dc0if_ath.ko
52 0xc0892000 26b60ath_hal

HEADS UP: Please clean out your */etc/rc.d directories

[Doug Barton]

I should have said this in my last heads up message, sorry for forgetting 
about this important detail. The new code tries to run any script in a 
local_startup directory (by default /usr/local/etc/rc.d and 
/usr/X11R6/etc/rc.d) that has the execute bit set. So, if there is a script 
in one of those directories that you don't want run at all, the safest thing 
to do is to create a directory within rc.d, and move the script there. 
Parsing of these scripts is not a recursive operation. The second safest 
thing to do is to remove the execute bit from those scripts.


hth,

Doug

--

This .signature sanitized for your protection

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

PANIC (g_vfs_done()) on RELENG_6

[Emanuel Strobl]

Hello,

the following error occured on my new RELENG_6 server from yesterday:

gune:/#34: cpdup -X .cvsjail -X INTERN -X PUBLIC /server/ /mnt/
ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=75285888
ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=75290368
ad4: detached
unknown: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=75294464
g_vfs_done():ad4[WRITE(offset=38550896640, length=131072)]error = 6
g_vfs_done():ad4[WRITE(offset=38551027712, length=131072)]error = 6
g_vfs_done():ad4[WRITE(offset=38551158784, length=131072)]error = 6
g_vfs_done():ad4[WRITE(offset=38551289856, length=131072)]error = 6
g_vfs_done():ad4[WRITE(offset=38551420928, length=131072)]error = 6
g_vfs_done():ad4[WRITE(offset=38551552000, length=131072)]error = 6
g_vfs_done():ad4[WRITE(offset=65536, length=2048)]error = 6
g_vfs_done():ad4[WRITE(offset=6144000, length=4096)]error = 6
g_vfs_done():ad4[WRITE(offset=35840851968, length=16384)]error = 6
.
.
.

Regrettably I don't have any HD inside besides the one which is my 
removable backup medium, so I don't have a dump but here's the panic 
message:

g_vfs_done():ad4[WRITE(offset=38551814144, length=131072)]error = 6
g_vfs_done():ad4[WRITE(offset=38551945216, length=131072)]error = 6
g_vfs_done():ad4[WRITE(offset=38552076288, length=131072)]er

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x48
fault code  = supervisor read, page not present
instruction pointer = 0x20:0xc05673c7
stack pointer   = 0x28:0xd5a38c60
frame pointer   = 0x28:0xd5a38c7c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 27 (swi4: clock sio)
trap number = 12
panic: page fault
Uptime: 49m49s
Cannot dump. No dump device defined.
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
interrupt   total
irq0: clk3004829
irq1: atkbd0   2
irq3: sio1 32757
irq5: em01039903
irq7: ppc0 1
irq8: rtc 384565
irq10: fxp0  194
irq11: atapci1   1376340
irq12: fwohci0++   1
irq13: npx02
irq14: ata0 3480
Total 5842074
panic: watchdog timeout
Uptime: 50m5s
Cannot dump. No dump device defined.

Tell me if I can help, very limited since it's a CF-Card based server

-Harry


pgpobbFsLmQeL.pgp
Description: PGP signature

Re: em bad performance

[Gleb Smirnoff]

On Wed, Dec 21, 2005 at 06:55:29PM +0200, Danny Braniss wrote:
D>  this particular mb, intel sr1435vp2, has 2 ethernets,
D> one is an Intel '82547EI Gigabit Ethernet Controller', the other is
D> a Marvell (which seems that the driver is around the corner).
D> 
D> the em performance under 6.0-stable is half of any other box i have,
D> and a similar mb running linux gives about 1GB, so
D> 
D>  Q: any ideas what can be wrong?

Please be more informative. How do you measure performance: netperf,
ftp, ... ?

What is the box doing: routing, bridging, running ftp server?

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: em bad performance

[Danny Braniss]

> On Wed, Dec 21, 2005 at 06:55:29PM +0200, Danny Braniss wrote:
> > hi,
> > this particular mb, intel sr1435vp2, has 2 ethernets,
> > one is an Intel '82547EI Gigabit Ethernet Controller', the other is
> > a Marvell (which seems that the driver is around the corner).
> > 
> > the em performance under 6.0-stable is half of any other box i have,
> > and a similar mb running linux gives about 1GB, so
> > 
> > Q: any ideas what can be wrong?
> 
> Performance of what?  Do you even have a correct MTU set?

wish it was that simple :-), everything is standard.
and it's not specific to one box, i have 3 of these with
the same slowness.

danny


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

Re: HEADS UP: Release schedule for 2006

[Spil Oss]

As a FreeBSD-n00b with some 'friends' that know FreeBSD better/well I
can only say

Please add this kind of information to the Handbook

Any addition to the handbook on tracking down problems and smarter
ways to fix things would be greatly appreciated. I found myself
recompiling my kernel to test changes to a device's driver, but now
you tell me I could have done that a lot smarter!
Whenever I get my 'knickers-in-a-twist' when using FreeBSD my first
point of reference is 'The Handbook'. Any additional information in
there would greatly be appreciated.

Learning-curve is very, very steep when you're used to lslpp and
windowsupdate to patch your system. I _do_ appreciate that most
developers and users are very experienced in using FreeBSD, but that
makes it increasingly difficult for the not-so-fortunate to come up to
speed with the use of FreeBSD.

Spil.

On 12/17/05, Kövesdán Gábor <[EMAIL PROTECTED]> wrote:
> Wilko Bulte wrote:
>
> >On Sat, Dec 17, 2005 at 01:54:34PM -0800, Joe Rhett wrote..
> >
> >
> >>On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote:
> >>
> >>
> >>>There will be three FreeBSD 6 releases in 2006.
> >>>
> >>>
> >>While this is nice, may I suggest that it is time to put aside/delay one
> >>release cycle and come up with a binary update mechanism supported well by
> >>the OS?  Increasing the speed of releases is good.  Increasing the number
> >>of deployed systems out of date because there are no easy binary upgrade
> >>mechanisms is bad.
> >>
> >>It has been bad, it's getting worse.
> >>
> >>
> >
> >So, when will you fix it?  Or hire someone to fix it?  FreeBSD after
> >all is mostly a volunteer operation.
> >
> >
> >
> I agree. And after all, tracking a security branch isn't too difficult,
> but the most people think that they have to do a complete "make
> buildworld" after a security advisory, but this isn't true. For example
> there was that cvsbug issue in September:
> ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:20.cvsbug.asc
> One can read here:
>
> b) Execute the following commands as root:
>
> # cd /usr/src
> # patch < /path/to/patch
> # cd /usr/src/gnu/usr.bin/cvs/cvsbug
> # make obj && make depend && make && make install
> # cd /usr/src/gnu/usr.bin/send-pr
> # make obj && make depend && make && make install
>
> Is that difficult? I don't think so. No reboot required and it doesn't
> take more than 5 minutes even on a slower machine. Only the
> vulnerabilities in the kernel are problematic for servers, since they
> require a reboot. I think I'll submit a PR with a patch to clarify this
> in Handbook. Do you consider this useful?
>
> Regards,
>
> Gabor Kovesdan
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: MFC of local_startup changes to rc.d complete

[Doug Barton]

Greg Rivers wrote:

On Wed, 21 Dec 2005, Doug Barton wrote:

As has been discussed for a couple weeks now, I have MFC'ed to 
RELENG_6 the changes in /etc/rc* that bring new-style boot scripts 
from the local_startup directories (by default /usr/local/etc/rc.d and 
/usr/X11R6/etc/rc.d) into the base rcorder...


This seems to have broken ppp-user for me.  Apparently the ppp arguments 
are being executed without the ppp command:


This is fixed now, thanks; and sorry for the hassle.

Doug

--

This .signature sanitized for your protection

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

lsof on 6.0

[Danny Braniss]

i keep getting:
lsof: can't determine user device random seed.
is it only me?

danny


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