ggate still broken on 6.2-RC1 for amd64.

[David Gilbert]

GGate is still broken on 6.2-RC1 for amd64.

I have verified that the patch in kern/104829 has been applied (it's
in the tree).

I have also added the patch in amd64/91799 --- without it, ggated
doesn't work at all.  This should definately make it into 6.2

But the ggated/ggatec in 6.2-RC1 connects now (and is happy about
that).  In fact, the tasting on the ggatec side that happens due to
new disks showing up works, too.  However, any attempt to pass
significant traffic causes ggatec to seeminly lock up.

In my configuration, I have a gmirror running with a local disk
(already) and I want to "gmirror insert" the ggate disk.  When I do
so, I get 50 write requests queued (I upped the gmirror buffer count
to 50 to make syncronization happen faster) and things never move from
there.

The machines in question are connected by private gigabit ethernet
with a 9k MTU.

Dave.

-- 

|David Gilbert, Independent Contractor.   | Two things can be  |
|Mail:   [EMAIL PROTECTED]|  equal if and only if they |
|http://daveg.ca  |   are precisely opposite.  |
=GLO
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: grep: memory exhausted

[Jeremy Chadwick]

On Wed, Nov 29, 2006 at 11:41:23PM -0500, Kris Kennaway wrote:
> Try increasing this.  I think grep mmaps the file, so the large file
> could be exceeding your limit.

According to the manpage, grep uses read(2) unless you specify --mmap
which then (obviously) uses mmap(2).

-- 
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networkinghttp://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, USA |
| Making life hard for others since 1977.   PGP: 4BD6C0CB |

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

Re: grep: memory exhausted

[Kris Kennaway]

On Wed, Nov 29, 2006 at 03:10:33PM -0500, van Osnabrugge, Sean wrote:
> Hi there,
> 
>  
> 
> I am running a fresh install of FreeBSD-6.1-Stable as a guest OS in
> VMWare 1.0.1 with 1 GB of RAM.
> 
>  
> 
> Whenever I try to grep a large text file (400 MB+), grep terminates with
> "grep: memory exhausted"
> 
>  
> 
> I have tried piping grep (cat "file" | grep "search term")
> 
> I have tried it with -line-buffered
> 
>  
> 
> ulimit -a show:
> 
> core file size(blocks, -c) unlimited
> 
> data seg size (kbytes, -d) 524288

Try increasing this.  I think grep mmaps the file, so the large file
could be exceeding your limit.

Kris

pgpz2dv2RpLAs.pgp
Description: PGP signature

Re: vr speed issues

[Mark Kirkwood]

Charles Sprickman wrote:

I also did a little more digging and noticed that once I start pinging 
from one of these hosts using large packet sizes, I get about 50-60% 
packet loss (ie: ping -s 1500 other.vr0.host).  If I ping something with 
a decent card, I get about 30-50% packet loss.  There's no packet loss 
with the default packet size.


Anyone else with some vr cards feel like checking this out?



I've got a VIA Rhine III card that I can dig out and put in if the data 
would be of any use/interest etc - FWIW I seem to recall being able to 
get reasonably close to wire speed when I was using it.


Cheers

Mark

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

Re: vr speed issues

[Pyun YongHyeon]

On Tue, Nov 28, 2006 at 10:50:17PM -0500, Charles Sprickman wrote:
 > Hi all,
 > 
 > I spent some time trying to track down slow tcp performance on a small 
 > office switched 100 LAN.  We just put in a number of whitebox PCs running 
 > FreeBSD 6.1-p2/PC-BSD 1.2 that all have onboard Via Rhine 10/100 ethernet 
 > controllers.  Performace with scp was around 200KB/s, ftp wavered between 
 > 300-500KB/s.  This did not appear to be a duplex mismatch - unmanaged 
 > switch showed them all at 100/Full, put some other hosts on the same 
 > ports/cabling and got near wire speed.  I took the cabling out of the 
 > equation, the switch, no improvement.  The only thing that got me decent 
 > performance was putting two hosts back to back with an xover cable.
 > 
 > I eventually realized that the only hosts with any speed issues in the 
 > office were these boxes with the Via ethernet.  Putting an equally cheap 
 > DLink (RealTek/rl) in one of them gave me much better performance.
 > 
 > At another site, I was dealing with a new intranet server running FreeBSD 
 > 6.2-PRE (11/16) on a decent Asus board.  This also has an onboard Via 
 > Rhine ethernet controller.  While pulling some files over from the box it 
 > was replacing, I noticed that I was getting only a few hundred KB/s on 
 > this box.  Before putting it into production, I grabbed a cheap Intel 
 > 10/100 card and put that in.  Problem solved.
 > 
 > So it seems to me like perhaps there's an issue with the vr driver.  I 
 > noticed it does have some quirks mentioned in the manpage, and I don't see 
 > too many changes to the driver in the last year or so.
 > 
 > Is there any information I can supply to help debug this?  I've got a 
 > bunch of these machines around.  I can get a tcpdump from both ends during 
 > an ftp transfer, and the boxes are mine to toy with after hours.
 > 
 > I've posted a dmesg from both boxes (PC-BSD and 6.2-PRE):
 > 
 > http://www.bway.net/~spork/6.1p2-dmesg.txt
 > http://www.bway.net/~spork/6.2-dmesg.txt
 > 

VIA Rhine has severe hardware limitations and you can't expect good
performance from the NIC. On Tx side the NIC need 4 bytes aligned mbuf
so the driver defragments the mbuf chains with m_defrag(9).
On Rx side it strips off CRC with m_devget(9) as the NIC has no way
to remove the CRC from the received frame. These m_defrag(9)/
m_devget(9) results in bcopy operation and they nullyfies the
advantage of DMA which in trun waste significant CPU cycles.

If you are in bad need of getting full 100Mbps speed you could buy
a cheap PCI gigabit NIC that is supported by re(4)/sk(4)/stge(4)
etc.  

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

Re: vr speed issues

[Charles Sprickman]

On Wed, 29 Nov 2006, Philipp Ost wrote:


Charles Sprickman wrote:
[snipped]
Performace with scp was around 200KB/s, ftp wavered between 300-500KB/s. 
This did not appear to be a duplex mismatch - unmanaged switch showed them 
all at 100/Full, put some other hosts on the same ports/cabling and got 
near wire speed. 


I just checked with the boxes I have here. One is an Athon XP on a Asus board 
with a VIA Rhine II on board; the other is a `old' Celeron 500 on a MSI board 
with a Intel ``Pro 100/S Desktop Adapter''.
I transfered a 538MiB file (some old CURRENT snapshot) via sftp. My result: 
from box one to box two (vr to fxp) I get 2.3MB/s; from box two to box one 
(fxp to vr) I get 3.1MB/s.


I also did a little more digging and noticed that once I start pinging 
from one of these hosts using large packet sizes, I get about 50-60% 
packet loss (ie: ping -s 1500 other.vr0.host).  If I ping something with a 
decent card, I get about 30-50% packet loss.  There's no packet loss with 
the default packet size.


Anyone else with some vr cards feel like checking this out?

Thanks,

Charles

The first box is running 6.2-PRERELEASE from 11/18, the Intel box is running 
7.0-CURRENT from 11/24.


Output of

$ dmesg | grep vr
vr0:  port 0x8000-0x80ff mem 
0xd600-0xd6ff at device 18.0 on pci0

miibus0:  on vr0

and

$ dmesg | grep fxp
fxp0:  port 0xc000-0xc03f mem 
0xdd02-0xdd020fff,0xdd00-0xdd01 irq 11 at device 1.0 on pci1

miibus0:  on fxp0
[...]
fxp0: Microcode loaded, int_delay: 1000 usec  bundle_max: 6
fxp0: Microcode loaded, int_delay: 1000 usec  bundle_max: 6

If needed I can provide a full dmesg of both boxes.


HTH,
Philipp

--
www.familie-ost.info/~pj


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

Re: re(4) needs promisc to work properly

[Bill Paul]

> On Tue, Nov 28, 2006 at 08:46:00PM +0100, Ed Schouten wrote:
>  > Hello,
>  > 
>  > I'm running FreeBSD 6.2-PRERELEASE on my new desktop. It has the
>  > following hardware:
>  > 
>  > - Intel Core 2 Duo 6400
>  > - Asus P5B motherboard
>  > - On-board Realtek NIC (8168B/8111B)
>  > 
>  > For some reason, it drops all incoming IPv6 packets. I can only SSH to
>  > the machine using IPv6 when I run the following command:
>  > 
>  > $ ifconfig re0 promisc
>  > 
>  > Is this a known issue about these NICs?
> 
> No, I'm not aware of the issue.
> 
> The issue can happen on a NIC with incorrectly programmed ethernet
> address. Would you show me dmesg/tcpdump output of your system?
> Make sure to add -e option to tcpdump(1).

It's more likely a problem with the multicast filter programming.
IPv6 is all about the multicasting (neighbord discovery depends on it
to work correctly). I can't explain why it's not working though.
I've tested the sample 8168B/8111B cards that RealTek sent me, and I
didn't have any multicast problems with them.

-Bill
 
>  > 
>  > Yours,
>  > -- 
>  >  Ed Schouten <[EMAIL PROTECTED]>
>  >  WWW: http://g-rave.nl/
> -- 
> Regards,
> Pyun YongHyeon
> 

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

problems using bge on hp bl460c blade

[Claus Guttesen]

Hi.

I have just installed 6.2 RC1 on my new blade. The (optional)
mezzanine-card NC326m is seen as bge. My problem is that there is no
link. I installed ubuntu 6.10 which gets link and ping works so the
hardware setup itself is ok. Ubuntu sees the nic as as 5714 chip rev.
9003 ( Tigon3 [partno(011276-001) rev 9003 PHY(5714)] ).

During FreeBSD's boot the nic is seen as a BCM5714 unknown. Rev. 9003
is not in if_bgereg.h so I added

#define BGE_CHIPID_BCM5714_B4   0x9003

and recompiled the kernel but it did not give me my missing link.
Partial pciconf -lv shows chip=0x167914e4 which is

#define BCOM_DEVICEID_BCM5715S  0x1679

in if_bgereg.h.

I only have one mezzanine-card atm. and I need to get the blade up and
running in a few days so I will probably throw ubuntu on it. I will
get more mezzanine-cards and can continue testing the bge-driver in
the coming days.

I won't mind digging into the bge-driver myself but will need some
hand-holding and some pointers/examples to get started.

According to HP's website the mezzanine-card has a 5715 chip but
FreeBSD (and ubuntu) sees it as 5714. Are these two chips closely
related?

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

Broadcom BCE interface and polling (Dell 2950)

[Kirk Davis]

> Hi,
>   We have just upgraded to a Dell 2950 for our main BGP router.
> With the constant rise in traffic through the box, I have started to
> notice some dropped packets so I figured I would take a look at
> putting the interfaces into polling more to squeeze a little more
> packets through them.
> 
>   I have added the DEVICE_POLLING and HZ=1000 to the kernel.  I
> turned on polling for the bce interfaces and they pass traffic at low
> volumes (like ping tests).  If I put my fluke traffic generators on
> either side of the box and try to ramp it up to even 100Mb (they are
> Gig links) then the interfaces will stop responding.  Turning off
> polling will get them to respond again.
> 
>   I know that the bce support in still quite new.  Has anyone else
> testing with polling and the bce interfaces?  Is there any more
> information that I can get for the developers to help track this down.
> The system is not in production right now so I can use it for testing.
> 
>   As another note... I added some Intel (em) cards into the box
> and tested with them.  Polling worked great on them but I was only
> able to get about 200k packets per second before it starts dropping
> packets.  Is this about what I should expect?
> 
> [root@ ~]# uname -a
> FreeBSD  6.2-RC1 FreeBSD 6.2-RC1 #2: Tue Nov 28 18:10:56 MST 2006
> root@:/usr/obj/usr/src/sys/INET-GW  i386
> 
>  Kirk
> 
> 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

grep: memory exhausted

[van Osnabrugge, Sean]

Hi there,

 

I am running a fresh install of FreeBSD-6.1-Stable as a guest OS in
VMWare 1.0.1 with 1 GB of RAM.

 

Whenever I try to grep a large text file (400 MB+), grep terminates with
"grep: memory exhausted"

 

I have tried piping grep (cat "file" | grep "search term")

I have tried it with -line-buffered

 

ulimit -a show:

core file size(blocks, -c) unlimited

data seg size (kbytes, -d) 524288

file size (blocks, -f) unlimited

max locked memory (kbytes, -l) unlimited

max memory size   (kbytes, -m) unlimited

open files(-n) 11095

pipe size  (512 bytes, -p) 1

stack size(kbytes, -s) 65536

cpu time (seconds, -t) unlimited

max user processes(-u) 5547

virtual memory(kbytes, -v) unlimited

 

Any help?

 

Thanks,

 

Sean



***

This e-mail message is privileged, confidential and subject to copyright.
Any unauthorized use or disclosure is prohibited.

Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a
des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer
sans autorisation.

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

grep: memory exhauted

[van Osnabrugge, Sean]

Hi there,

 

I am running a fresh install of FreeBSD-6.1-Stable as a guest OS in VMWare 
1.0.1 with 1 GB of RAM.

 

Whenever I try to grep a large text file (400 MB+), grep terminates with “grep: 
memory exhausted”

 

I have tried piping grep (cat “file” | grep “search term”)

I have tried it with –line-buffered

 

ulimit –a show:

core file size(blocks, -c) unlimited

data seg size (kbytes, -d) 524288

file size (blocks, -f) unlimited

max locked memory (kbytes, -l) unlimited

max memory size   (kbytes, -m) unlimited

open files(-n) 11095

pipe size  (512 bytes, -p) 1

stack size(kbytes, -s) 65536

cpu time (seconds, -t) unlimited

max user processes(-u) 5547

virtual memory(kbytes, -v) unlimited

 

Any help?

 

Thanks,

Sean van Osnabrugge 
Email/Exchange Administrator 
Networking Services 
* Email: [EMAIL PROTECTED]  
( Office: 416-646-3123 
¹ Hours: Monday - Friday, 9:00AM - 5:00PM EST 

 



***

This e-mail message is privileged, confidential and subject to
copyright. Any unauthorized use or disclosure is prohibited.

Le contenu du présent courriel est privilégié, confidentiel et
soumis à des droits d'auteur. Il est interdit de l'utiliser ou
de le divulguer sans autorisation.

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

Re: weird permitions

[M.Hirsch]

Hello,

Can someone explain to me why next can happened on freebsd:
1. add 2 users in same group - user test and test-ro in group test
2. as user test: cd /home/test ; mkdir test; chmod 775 test; echo 
"asdasd" > ~/test/del.me
3. su - test-ro ; cd /home/test; vim del.me - make changes; force save 
(:x!)


ls -l
total 2
-rw-r--r--  1 test-ro  test  10 Nov 29 18:19 del.me (how is that 
possible ?)


back "su - test" and try to edit this file - impossible!

I do not know what the RFC says about it, but it is ultra weird for me
that such ownership takeover is possible.

6.2-PRERELEASE FreeBSD Fri Oct 27 19:53:30 amd64



Correct me if I'm wrong... but you obviously were editing two completely 
distinct files.

~test/del.me (logged in as "test-ro")
and
~test/test/del.me (logged in as "test")

I fail to see anything odd here.
You seem to have enabled group writable home directories though.

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

Re: ath0 issue

[Lamont Granquist]

On Wed, 29 Nov 2006, Sam Leffler wrote:

Is there some reason you are not just sniffing the air?  Assuming
packets are being deferred because the medium is busy you might see a
reason.  Otherwise it appears (though it's impossible to tell from what
you've shown so far) that the packets are handed to the h/w in a timely
fashion.


I'm not sniffing the air because I don't have a third machine with a 
wireless card in it to use.


The packets are getting buffered somewhere between the IP stack and the 
medium, and I'd like to track down the queue they're sitting in and then 
track down why...

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

Re: Problems unmounting/fssyncking extern UFS filesystem

[Erik Trulsson]

On Wed, Nov 29, 2006 at 05:07:01PM +0100, Oliver Fromme wrote:
> Christopher Sean Hilton wrote:
>  > Kevin Oberman wrote:
>  > [ ... ]
>  > > The magic phrase is "buffer cache has been flushed". In the real world
>  > > of discs with cache there is no way to be certain when the data is
>  > > REALLY on the disc. That is why things get clobbered if the power is
>  > > cycled to the disc too soon after syncing and why a sleep (or typing
>  > > sync three times) is still a good idea and probably always will be.
>  > 
>  > Please understand that this is an honest question but isn't that true
>  > only of IDE heritage drives. E.g. If a SCSI drive with Tagged Queuing
>  > says that the the bits have been written doesn't it mean that the bits
>  > have really been written?
> 
> Right, unless the SCSI drive has a label saying "Quantum".

In other words: Yes, assuming the SCSI drive works as it should.  Not
all SCSI drives work as they should.  (I am not familiar with the Quantum
disks in particular, but I would be very surprised if there were no SCSI
disks that were broken in this regard.)

> 
> Best regards
>Oliver
> 
> PS:  Quantum is today owned by maxtor, isn't it?  I've lost
> track of HD manufacturers when Seagate bought Conner ...

Quantum and Maxtor merged and became Maxtor.  Maxtor was recently
bought by Seagate, so it is Seagate that owns Quantum these days.


-- 

Erik Trulsson
[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: Dell PE 1950 bce NICs revisited

[Josh Paetzel]

On Wednesday 29 November 2006 10:43, Scott Long wrote:
> Josh Paetzel wrote:
> > I've been using 6.1-R on a PE1950 for some time now.  The stock
> > bce driver doesn't work at all.  I dug up a driver off the web
> > (0.9.6) that worked fine with my workload (basically all TCP) but
> > in talking to Scott I discovered that UDP traffic was a problem
> > for this driver. Some time ago I upgraded to the driver in
> > -STABLE.  This driver also appears to work fine, but about once a
> > day I get the following:
> >
> > Nov 29 01:16:47 server2 kernel:
> > bce1: /usr/src/sys/dev/bce/if_bce.c(5000): Watch
> > dog timeout occurred, resetting!
> > Nov 29 01:16:47 server2 kernel: bce1: link state changed to DOWN
> > Nov 29 01:16:48 server2 kernel: bce1: link state changed to UP
> >
> > Pretty minor complaint, as it doesn't really affect the operation
> > of the box, but I suppose it's a sign that there's still some
> > work to be done.
> >
> > $FreeBSD: src/sys/dev/bce/if_bce.c,v 1.2.2.6 2006/10/24
> >
> > As I write this I see there has been some further work on the
> > driver, so I think I'll upgrade it and see what happens.
>
> It's possible that rev 1.2.2.6 will fix what you're seeing.  If
> not, then it might be the general issue with the watchdog framework
> being unreliable that we addressed with the em driver.  If so, then
> it's mostly harmless.
>
> Scott
>

The string I pasted is what I was using.  Rebuilt using:
/repoman/r/ncvs/src/sys/dev/bce/if_bce.c,v 1.2.2.6.2.1
this morning.  I'll give it a few days and see how it's working.  I 
think either way it's harmless.  It happens about once a day, and 
strangely enough it's almost always in periods of very low load.

-- 
Thanks,

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

Re: weird permitions

[Oliver Fromme]

Stefan Lambrev wrote:
 > Can someone explain to me why next can happened on freebsd:
 > 1. add 2 users in same group - user test and test-ro in group test
 > 2. as user test: cd /home/test ; mkdir test; chmod 775 test; echo 
 > "asdasd" > ~/test/del.me

What was your umask?  I assume 022, i.e. the file was
created with mdoe 644.

 > 3. su - test-ro ; cd /home/test; vim del.me - make changes; force save (:x!)

I suspect that vim -- upon force save -- deleted the
original file, which is perfectly possible because the
test-ro user had write permission to the directory.

Then vim created a new file with the same name, which
is again perfectly possible because of the writability
of the directory.  The new file belongs to the test-ro
user, of course.

So ...

 > ls -l
 > total 2
 > -rw-r--r--  1 test-ro  test  10 Nov 29 18:19 del.me (how is that possible ?)
 > 
 > back "su - test" and try to edit this file - impossible!

.. That's to be expected.

 > I do not know what the RFC says about it, but it is ultra weird for me
 > that such ownership takeover is possible.

It is standard and perfectly correct behaviour.

There was no "ownership takeover".  One file was deleted,
and a new file was created, all allowed by the given
permissions.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"If Java had true garbage collection, most programs
would delete themselves upon execution."
-- Robert Sewell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ath0 issue

[Sam Leffler]

Lamont Granquist wrote:
> 
> and ath_intr() is getting called all the time but status & HAL_INT_TX
> isn't true so the task isn't getting enqueued.  this is a 5 second stutter:
> 
> Nov 28 21:39:48 warez kernel: ath_tx_proc_q0123: 1
> Nov 28 21:39:48 warez kernel: ath_intr: status 0x101
> Nov 28 21:39:48 warez kernel: ath_intr: status 0x109
> Nov 28 21:39:48 warez kernel: ath_intr: status 0x101
> Nov 28 21:39:48 warez kernel: ath_intr: status 0x109
> Nov 28 21:39:48 warez kernel: ath_intr: status 0x101

<...stuff truncated...>

Using timestamps from syslog isn't going to give you any useful
information since the data may be delayed getting to syslogd.

Is there some reason you are not just sniffing the air?  Assuming
packets are being deferred because the medium is busy you might see a
reason.  Otherwise it appears (though it's impossible to tell from what
you've shown so far) that the packets are handed to the h/w in a timely
fashion.

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

Re: ath0 issue

[Sam Leffler]

Lamont Granquist wrote:
> 
> 
> On Wed, 15 Nov 2006, Sam Leffler wrote:
>> Snapshots are rarely useful; try running athstats 1 and correlate what
>> you see with pauses.  Another possible reason for deferred operation is
>> something else in the system blocking the taskq threads; that's a bit
>> trickier to diagnose.
> 
> I threw in some printf()'s in the beginning of ath_start() and
> ath_tx_proc_q0123() and see this:
> 
> Nov 28 20:27:41 warez kernel: ath_tx_proc_q0123: 1
> Nov 28 20:27:41 warez kernel: ath_start
> Nov 28 20:27:41 warez kernel: ath_start
> Nov 28 20:27:41 warez kernel: ath_tx_proc_q0123: 1
> Nov 28 20:27:41 warez kernel: ath_start
> Nov 28 20:27:45 warez last message repeated 13 times
> Nov 28 20:27:45 warez kernel: ath_tx_proc_q0123: 1
> Nov 28 20:27:45 warez kernel: ath_start
> Nov 28 20:27:45 warez kernel: ath_tx_proc_q0123: 1
> Nov 28 20:27:45 warez kernel: ath_start
> Nov 28 20:27:45 warez kernel: ath_start
> 
> this was during a time where i was pinging across this interface so that
> every second it should have been transmitting at least one packet.  the
> 4 second stutter there where ath_tx_proc_q0123 wasn't being called
> correllates with actual stutters in packet transmission.
> 
> if i understand this, that's the taskq associated with transmission?
> 
> TASK_INIT(&sc->sc_txtask, 0, ath_tx_proc_q0123, sc);
> 
> 
No, that's the task q that reaps completed tx descriptors.  You can't
infer anything about when packets were transmitted from this.

Sam

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

Re: Dell PE 1950 bce NICs revisited

[Scott Long]

Josh Paetzel wrote:
I've been using 6.1-R on a PE1950 for some time now.  The stock bce 
driver doesn't work at all.  I dug up a driver off the web (0.9.6) 
that worked fine with my workload (basically all TCP) but in talking 
to Scott I discovered that UDP traffic was a problem for this driver.  
Some time ago I upgraded to the driver in -STABLE.  This driver also 
appears to work fine, but about once a day I get the following:


Nov 29 01:16:47 server2 kernel: 
bce1: /usr/src/sys/dev/bce/if_bce.c(5000): Watch

dog timeout occurred, resetting!
Nov 29 01:16:47 server2 kernel: bce1: link state changed to DOWN
Nov 29 01:16:48 server2 kernel: bce1: link state changed to UP

Pretty minor complaint, as it doesn't really affect the operation of 
the box, but I suppose it's a sign that there's still some work to be 
done.


$FreeBSD: src/sys/dev/bce/if_bce.c,v 1.2.2.6 2006/10/24

As I write this I see there has been some further work on the driver, 
so I think I'll upgrade it and see what happens.




It's possible that rev 1.2.2.6 will fix what you're seeing.  If not,
then it might be the general issue with the watchdog framework being
unreliable that we addressed with the em driver.  If so, then it's
mostly harmless.

Scott

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

weird permitions

[Stefan Lambrev]

Hello,

Can someone explain to me why next can happened on freebsd:
1. add 2 users in same group - user test and test-ro in group test
2. as user test: cd /home/test ; mkdir test; chmod 775 test; echo 
"asdasd" > ~/test/del.me

3. su - test-ro ; cd /home/test; vim del.me - make changes; force save (:x!)

ls -l
total 2
-rw-r--r--  1 test-ro  test  10 Nov 29 18:19 del.me (how is that possible ?)

back "su - test" and try to edit this file - impossible!

I do not know what the RFC says about it, but it is ultra weird for me
that such ownership takeover is possible.

6.2-PRERELEASE FreeBSD Fri Oct 27 19:53:30 amd64

--
Best Wishes,
Stefan Lambrev
ICQ# 24134177

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

Re: Panic in "thread taskq" on RELENG_6

[Rong-en Fan]

On 11/29/06, Kevin Oberman <[EMAIL PROTECTED]> wrote:

> From: "=?iso-8859-1?Q?Markus_Oestreicher?=" <[EMAIL PROTECTED]>
> Date: Tue, 28 Nov 2006 20:01:06 +0100
> Sender: [EMAIL PROTECTED]
>
> Good Day,
>
> I get a panic on latest RELENG_6 every 6-12 hours. The server is a
> Dual Xeon FSB800 with 2 GB RAM and aac(4)-disks running postfix and
> amavisd-new for SPAM scanning.
>
>
> kernel trap 12 with interrupts disabled
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 3; apic id = 07
> fault virtual address = 0x104
> fault code= supervisor read, page not present
> instruction pointer   = 0x20:0xc06774e1
> stack pointer = 0x28:0xe4f93c90
> frame pointer = 0x28:0xe4f93c9c
> code segment  = base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, def32 1, gran 1
> processor eglags  = resume, IOPL = 0
> current process   = 5 (thread taskq)
>
> The panic always in process "thread taskq".
>
> db>trace
> _mit_lock_sleep(cb031e5c,c63f7180) at _mtx_lock_sleep+0x9d
> unp_gc(0,1) at uno_gc+0x222
> taskqueue_run(c6439d80) at taskqueue_run+0x13f
> taskqueue_thread_loop(c09f8988,e4f93d38) at taskqueue_thread_loop+0x> 92
> fork_exit(c06a1bc0,c09f8988,e4f93d38) at fork_exit+0x71
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0x1, eip = 0, esp=0xe4f93d6c, ebp = 0
>
> FreeBSD mx.local 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1:
>  Tue Nov 28 02:12:58 CET 2006
>  [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP  i386
>
>
> Does that look like a hardware problem or a software issue?
> I will try to swap RAM in the next few days.

You are the third person to report this panic. (I am one of the other
two.


I reported unp_gc() panic recently. See
"Re: LOR (intr table and sio) and instability" on [EMAIL PROTECTED]
jhb@ told me that he also saw this and there is currently no
fix yet.

Regards,
Rong-En Fan



I am guessing from the name of your kernel that this is an SMP
system. So are the other two.

Are you running gnome-2.16 with hald? This is about all we found
in common on the first two systems.

Robert Watson would like some added data. Can you build a kernel with
the following options and connect something to the serial port to record
output?
options WITNESS
options INVARIANT_SUPPORT
options DDB
options KDB
options INVARIANTS

At the debugger prompt:
> show pcpu
> trace
> show allpcpu
> traceall
> show alllocks

At least my system has been totally uncooperative in crashing when I am
anywhere near it, so I have not yet collected any information other than
dumps.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751




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

Re: Problems unmounting/fssyncking extern UFS filesystem

[Oliver Fromme]

Christopher Sean Hilton wrote:
 > Kevin Oberman wrote:
 > [ ... ]
 > > The magic phrase is "buffer cache has been flushed". In the real world
 > > of discs with cache there is no way to be certain when the data is
 > > REALLY on the disc. That is why things get clobbered if the power is
 > > cycled to the disc too soon after syncing and why a sleep (or typing
 > > sync three times) is still a good idea and probably always will be.
 > 
 > Please understand that this is an honest question but isn't that true
 > only of IDE heritage drives. E.g. If a SCSI drive with Tagged Queuing
 > says that the the bits have been written doesn't it mean that the bits
 > have really been written?

Right, unless the SCSI drive has a label saying "Quantum".

Best regards
   Oliver

PS:  Quantum is today owned by maxtor, isn't it?  I've lost
track of HD manufacturers when Seagate bought Conner ...

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"[...]  one observation we can make here is that Python makes
an excellent pseudocoding language, with the wonderful attribute
that it can actually be executed."  --  Bruce Eckel
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: When will new changes in BCE driver for vlans be included in stable?

[Daniel Martin-Fabiani]

Now everything working fine, thank you very much.

Daniel.

--- Scott Long <[EMAIL PROTECTED]> escribió:

> I just merged the fixes into RELENG_6 and
> RELENG_6_2.  Thanks for
> the reminder.
> 
> Scott
> 
> 
> Daniel Martin-Fabiani wrote:
> > Hello,
> > 
> > I've noticed some recent changes (16 Nov) in bce
> > driver because vlan tagging doesn't work properly.
> > 
> > I've got a Dell PE2950 with two Broadcom NetXtreme
> II
> > interfaces with the very last RELENG_6 installed,
> and
> > seems like vlan tagging/stripping is not working
> > properly on them.
> > 
> > I wonder when this fix will be available in
> RELENG_6,
> > because just patching if_bce* files and sys/mbuf.h
> > does not compile at all.
> > 
> > Or maybe there's a workaround for this to get it
> > working...
> > 
> > Thanks in advance.
> > 
> > Daniel
> > 
> > 
> > 
> > __ 
> > LLama Gratis a cualquier PC del Mundo. 
> > Llamadas a fijos y móviles desde 1 céntimo por
> minuto. 
> > http://es.voice.yahoo.com
> > ___
> > 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]"
> 




__ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: vr speed issues

[Philipp Ost]

Charles Sprickman wrote:
[snipped]
Performace with scp was around 200KB/s, ftp 
wavered between 300-500KB/s.  This did not appear to be a duplex 
mismatch - unmanaged switch showed them all at 100/Full, put some other 
hosts on the same ports/cabling and got near wire speed.  


I just checked with the boxes I have here. One is an Athon XP on a Asus 
board with a VIA Rhine II on board; the other is a `old' Celeron 500 on 
a MSI board with a Intel ``Pro 100/S Desktop Adapter''.
I transfered a 538MiB file (some old CURRENT snapshot) via sftp. My 
result: from box one to box two (vr to fxp) I get 2.3MB/s; from box two 
to box one (fxp to vr) I get 3.1MB/s.


The first box is running 6.2-PRERELEASE from 11/18, the Intel box is 
running 7.0-CURRENT from 11/24.


Output of

$ dmesg | grep vr
vr0:  port 0x8000-0x80ff mem 
0xd600-0xd6ff at device 18.0 on pci0

miibus0:  on vr0

and

$ dmesg | grep fxp
fxp0:  port 0xc000-0xc03f mem 
0xdd02-0xdd020fff,0xdd00-0xdd01 irq 11 at device 1.0 on pci1

miibus0:  on fxp0
[...]
fxp0: Microcode loaded, int_delay: 1000 usec  bundle_max: 6
fxp0: Microcode loaded, int_delay: 1000 usec  bundle_max: 6

If needed I can provide a full dmesg of both boxes.


HTH,
Philipp

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

Re: Is there conflicts between gmirror and a quota enabled filesystem?

[Kostik Belousov]

On Wed, Nov 29, 2006 at 05:54:40AM -0800, Jason Vance wrote:
> Posted Monday Nov 27th.
> 
> Is there a known conflict between gmirror and a quota enabled filesystem?
> 
> 
> 
> I have a FreeBSD 5.5-STABLE box that is setup with a gmirror RAID 1 using
> two identical harddrives.
> 
> I installed quotas on the filesystem by enabling it 'options QUOTA' and
> rebuilding the kernel. I added userquota to the /etc/fstab for the /usr
> partition and I added 'enable_quotas=YES' and 'check_quotas=NO' to the
> /etc/rc.conf file thinking i can get it to build the quota table on the fly
> instead of it doing that at boot time.
> 
> The system boots up but as soon as I do any disk access ie 'repquota -a' or
> write a file to the harddrive, the system hangs. I can still connect to the
> various services via telnet to their port, but none of them respond.
> 
> Now that I've disabled quotas I am able to use the system however fsck has
> reported many various file corruptions and destroyed some of my important
> system files.
> 
> Is there a known conflict between gmirror and a quota enabled filesystem?
> How can I properly set these up?

I think this has nothing to do with gmirror. It's the situation
described in PR kern/30958.

The actual problem is the following call sequence: some process (it may
be even a syncer) tries to write the quota (for instance, syncer called
ffs_sync, that calls qsync(), that calls dqsync()). dqsync() issues
VOP_WRITE() on the quota file, while locked the corresponding dquot.
Since file needs to be extended, ffs_balloc_* is entered. There, call
to ffs_alloc checks for quota of the owner of the quota file, entering
chkdq. This leads to deadlock, since chkdq waits while dqout becomes
unlocked.

I believe that this scenario is fixed in my mp-safe quota patch. See
http://people.freebsd.org/~kib/quotagiant for the patch against CURRENT.

As workaround, use quotacheck before enabling quota.


pgpuL02EIPQ9e.pgp
Description: PGP signature

Is there conflicts between gmirror and a quota enabled filesystem?

[Jason Vance]

Posted Monday Nov 27th.

Is there a known conflict between gmirror and a quota enabled filesystem?



I have a FreeBSD 5.5-STABLE box that is setup with a gmirror RAID 1 using
two identical harddrives.

I installed quotas on the filesystem by enabling it 'options QUOTA' and
rebuilding the kernel. I added userquota to the /etc/fstab for the /usr
partition and I added 'enable_quotas=YES' and 'check_quotas=NO' to the
/etc/rc.conf file thinking i can get it to build the quota table on the fly
instead of it doing that at boot time.

The system boots up but as soon as I do any disk access ie 'repquota -a' or
write a file to the harddrive, the system hangs. I can still connect to the
various services via telnet to their port, but none of them respond.

Now that I've disabled quotas I am able to use the system however fsck has
reported many various file corruptions and destroyed some of my important
system files.

Is there a known conflict between gmirror and a quota enabled filesystem?
How can I properly set these up?

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

Re: sshd. "UseDNS no" ignored?

[Dmitry Pryanishnikov]

Hello!

On Tue, 21 Nov 2006, Stephen Montgomery-Smith wrote:
I remember a discussion about this maybe a few years ago.  I recall that it 
is basically impossible to stop ssh from looking up DNS addresses. The


  I'm still wondering why OpenSSH is _so_ inferior to SSH.COM's ssh2
(which is also open-source)? In the later product the following line in 
/usr/local/etc/ssh2/sshd2_config:


ResolveClientHostName no

_actually_ prevents DNS reverse lookups by the sshd2 (just checked it,
my test machine has ssh2-nox11-3.2.9.1_5 installed from ports). It's not
the only option which present in ssh2 while absent in OpenSSH, second
very useful one is:

AuthInteractiveFailureTimeout   10

which make SSH-password-guessing robots to give up after the first attempt ;)


Sincerely, Dmitry
--
Atlantis ISP, System Administrator
e-mail:  [EMAIL PROTECTED]
nic-hdl: LYNX-RIPE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Dell PE 1950 bce NICs revisited

[Josh Paetzel]

I've been using 6.1-R on a PE1950 for some time now.  The stock bce 
driver doesn't work at all.  I dug up a driver off the web (0.9.6) 
that worked fine with my workload (basically all TCP) but in talking 
to Scott I discovered that UDP traffic was a problem for this driver.  
Some time ago I upgraded to the driver in -STABLE.  This driver also 
appears to work fine, but about once a day I get the following:

Nov 29 01:16:47 server2 kernel: 
bce1: /usr/src/sys/dev/bce/if_bce.c(5000): Watch
dog timeout occurred, resetting!
Nov 29 01:16:47 server2 kernel: bce1: link state changed to DOWN
Nov 29 01:16:48 server2 kernel: bce1: link state changed to UP

Pretty minor complaint, as it doesn't really affect the operation of 
the box, but I suppose it's a sign that there's still some work to be 
done.

$FreeBSD: src/sys/dev/bce/if_bce.c,v 1.2.2.6 2006/10/24

As I write this I see there has been some further work on the driver, 
so I think I'll upgrade it and see what happens.

-- 
Thanks,

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

RE: ufs_dirbad: bad dir panic (Was Areca Weirdness)

[Lawrence Farr]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Kris Kennaway
> Sent: 21 November 2006 21:07
> To: Lawrence Farr
> Cc: freebsd-stable@freebsd.org; 'Tom Samplonius'; 'Kris Kennaway'
> Subject: Re: ufs_dirbad: bad dir panic (Was Areca Weirdness)
> 
> On Tue, Nov 21, 2006 at 10:27:18AM -, Lawrence Farr wrote:
> >  
> > 
> > > -Original Message-
> > > From: Kris Kennaway [mailto:[EMAIL PROTECTED] 
> > > Sent: 21 November 2006 00:44
> > > To: Tom Samplonius
> > > Cc: Kris Kennaway; freebsd-stable@freebsd.org; Lawrence Farr
> > > Subject: Re: ufs_dirbad: bad dir panic (Was Areca Weirdness)
> > > 
> > > On Mon, Nov 20, 2006 at 04:29:17PM -0800, Tom Samplonius wrote:
> > > > 
> > > > - Kris Kennaway <[EMAIL PROTECTED]> wrote:
> > > > > > > > > >> If I newfs it, and copy data to it, I have 
> no problem
> > > > > > > initially.
> > > > > > I can repeat this 100% now, by copying data onto 
> the drive then
> > > > > unmounting
> > > > > > and remounting it. I have a core dump if anyone can 
> tell me what
> > > > > info to
> > > > > > get from it:
> > > > > > 
> > > > > >   Version String: FreeBSD 6.2-PRERELEASE #0: Wed Nov 15 
> > > 19:57:01 GMT
> > > > > 2006
> > > > > > 
> > > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/P6NOUSB
> > > > > >   Panic String: ufs_dirbad: bad dir
> > > > > 
> > > > > Run fsck -fy on the filesystem, this is a common symptom of a
> > > > > corrupted filesystem.
> > > > 
> > > >   I think the OP knows the filesystem is corrupted.  The 
> > > problem is why does the filesystem get corrupted?  The OP 
> > > says he can corrupt the filesystem on demand after a newfs.  
> > > So it could be the Areca driver, or even bad hardware.
> > > 
> > > My point is that this panic can happen when your 
> filesystem becomes
> > > corrupted, and the panic keeps happening during "normal" 
> filesystem
> > > operations until you forcibly fsck it, at which point the 
> panic goes
> > > away.
> > > 
> > > Kris
> > > 
> > 
> > I have been newfs'ing it and starting again, and it will 
> work once, but 
> > once unmounted and re-mounted it will panic with ufs_dirbad.
> 
> OK, that's a different matter then.  One thing you could try would be
> to write known data directly to the device and then read it back or
> verify the md5 sum and try to identify the failure mode.  I'd try to
> rule out hardware problems too.
> 
> Kris
> 

I made a volume that was under 2Tb and installed directly onto the
Areca rather than the ATA drive. This has now run without issue for 
a week. Strangely, I did the same test on the ATA drive prior to this
and it worked without issue for a week. Quite why it doesn't work with
the ATA as the boot device and the Areca as storage is beyond me.

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