Re: Profiling code execution on amd64?

[Steve Kargl]

On Thu, Jan 13, 2011 at 10:08:30PM -0500, Ryan Stone wrote:
> I would suggest using hwpmc for profiling:
> 
> # kldload hwpmc
> # pmcstat -S unhalted-cycles -O /tmp/samples.out ../penetration
> # pmcstat -R /tmp/samples.out -G /tmp/penetration.txt
> 
> 
> You can also get pmcstat to generate gprof-compatible output with -g,
> but I never use the mode so I'm really not sure what it gives you.  I
> think that you have to run gprof on the output or something, but don't
> hold me to that.


Thanks.  I'll give it a try, but my initial attempt seems to
indicate that one needs to be root to use hwpmc.  

laptop:kargl[210] pmcstat -S unhalted-cycles -O /tmp/samples.out ../penetration
pmcstat: ERROR: Cannot allocate system-mode pmc with specification
"unhalted-cycles": Operation not permitted

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

Re: Profiling code execution on amd64?

[Ryan Stone]

I would suggest using hwpmc for profiling:

# kldload hwpmc
# pmcstat -S unhalted-cycles -O /tmp/samples.out ../penetration
# pmcstat -R /tmp/samples.out -G /tmp/penetration.txt


You can also get pmcstat to generate gprof-compatible output with -g,
but I never use the mode so I'm really not sure what it gives you.  I
think that you have to run gprof on the output or something, but don't
hold me to that.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: R: Recent mouse freeze problem with X, different window managers, any browser and flash.

[Jung-uk Kim]

On Thursday 13 January 2011 06:20 pm, Ariff Abdullah wrote:
> On Thu, 13 Jan 2011 15:24:52 -0500
>
> Jung-uk Kim  wrote:
> > On Thursday 13 January 2011 01:14 pm, Jung-uk Kim wrote:
> > > On Wednesday 12 January 2011 10:22 pm, Ariff Abdullah wrote:
> > > > On Wed, 12 Jan 2011 09:53:03 -0600
> > > >
> > > > eculp  wrote:
> > > > > Quoting Ariff Abdullah :
> > > > > > On Wed, 12 Jan 2011 22:51:29 +0800
> > > > > > Ariff Abdullah  wrote:
> > > > > >
> > > > > > []
> > > > > >
> > > > > >> Try disabling mtrr, machdep.disable_mtrrs=0 through
> > > > > >> boot prompt or /boot/loader.conf.
> > > > > >
> > > > > > Grr.. should be machdep.disable_mtrrs=1
> > > > >
> > > > > Caught it, changed it en loader.conf, rebooted and have had
> > > > > youtube
> > > > >
> > > > > running more that 10 minutes with no ill affects.
> > > >
> > > > Keep in mind that disabling mtrr is a temporary measure.
> > > >
> > > > > Want to clarify that this in with current i386.
> > > > >
> > > > > 9.0-CURRENT FreeBSD 9.0-CURRENT #161: Wed Jan 12 04:38:15
> > > > > CST 2011
> > > > >
> > > > > r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO 
> > > > > i386
> > > > >
> > > > > Thanks again,
> > > > >
> > > > > ed
> > > > >
> > > > > Thanks so much for your help.
> > > > >
> > > > > ed
> > > > >
> > > > > >> If that is the case, you probably want this:
> > > > > >>
> > > > > >> http://people.freebsd.org/~ariff/misc/mtrr.diff
> > > >
> > > > This breakage was due to r215415 commit. Jung-uk Kim, any
> > > > idea ?
> >
> > Can you please try the attached patch *without* ariff's
> > workaround?
>
> X Display corruption and erratic mouse behaviour still occured.
>
> Hardware is Thinkpad x100e using single-core Athlon Neo running
> r217079 / amd64 .
>
> CPU: AMD Athlon(tm) Neo Processor MV-40 (1596.12-MHz K8-class CPU)
>   Origin = "AuthenticAMD"  Id = 0x70ff2  Family = f  Model = 7f
> Stepping = 2
> Features =
> 0x78bfbff PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
> Features2=0x2001
> AMD Features =
> 0xea500800
> AMD Features2=
> 0x11d

Okay.  I just wanted to make sure there's no strangeness with intial 
value from BIOS.  Although I think I know why it happens, I am not 
sure how to fix it properly.  If I cannot come up with a better idea 
soon, I can commit your patch and restore the previous behaviour.

Thanks,

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

ale(4) causes panic after r217323

[Aryeh Friedman]

I have already told jhb about this and he provided a patch that
failed maybe someone else has a solution.

Problem: As soon as ale(4) switches from DOWN to UP kernel panics due
to lock state switch
How to repeat: ifconfig ale0 192.168.2.2
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: R: Recent mouse freeze problem with X, different window managers, any browser and flash.

[Ariff Abdullah]

On Thu, 13 Jan 2011 15:24:52 -0500
Jung-uk Kim  wrote:
> On Thursday 13 January 2011 01:14 pm, Jung-uk Kim wrote:
> > On Wednesday 12 January 2011 10:22 pm, Ariff Abdullah wrote:
> > > On Wed, 12 Jan 2011 09:53:03 -0600
> > >
> > > eculp  wrote:
> > > > Quoting Ariff Abdullah :
> > > > > On Wed, 12 Jan 2011 22:51:29 +0800
> > > > > Ariff Abdullah  wrote:
> > > > >
> > > > > []
> > > > >
> > > > >> Try disabling mtrr, machdep.disable_mtrrs=0 through
> > > > >> boot prompt or /boot/loader.conf.
> > > > >
> > > > > Grr.. should be machdep.disable_mtrrs=1
> > > >
> > > > Caught it, changed it en loader.conf, rebooted and have had
> > > > youtube
> > > >
> > > > running more that 10 minutes with no ill affects.
> > >
> > > Keep in mind that disabling mtrr is a temporary measure.
> > >
> > > > Want to clarify that this in with current i386.
> > > >
> > > > 9.0-CURRENT FreeBSD 9.0-CURRENT #161: Wed Jan 12 04:38:15 CST
> > > > 2011
> > > >
> > > > r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO  i386
> > > >
> > > > Thanks again,
> > > >
> > > > ed
> > > >
> > > > Thanks so much for your help.
> > > >
> > > > ed
> > > >
> > > > >> If that is the case, you probably want this:
> > > > >>
> > > > >> http://people.freebsd.org/~ariff/misc/mtrr.diff
> > >
> > > This breakage was due to r215415 commit. Jung-uk Kim, any idea ?
> 
> Can you please try the attached patch *without* ariff's workaround?
> 

X Display corruption and erratic mouse behaviour still occured.

Hardware is Thinkpad x100e using single-core Athlon Neo running
r217079 / amd64 .

CPU: AMD Athlon(tm) Neo Processor MV-40 (1596.12-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x70ff2  Family = f  Model = 7f 
Stepping = 2 
Features = 0x78bfbff 
Features2=0x2001
AMD Features =
0xea500800
AMD Features2=
0x11d


--
Ariff Abdullah
FreeBSD

... Recording in stereo is obviously too advanced
and confusing for us idiot * users :P 

... Going with the standard and orthodox
is the death of intellect ..


pgptKtpzjugiK.pgp
Description: PGP signature

Re: My ZFS v28 Testing Experience

[Pawel Jakub Dawidek]

On Wed, Jan 12, 2011 at 11:03:19PM -0400, Chris Forgeron wrote:
> I've been testing out the v28 patch code for a month now, and I've yet to 
> report any real issues other than what is mentioned below. 
> 
> I'll detail some of the things I've tested, hopefully the stability of v28 in 
> FreeBSD will convince others to give it a try so the final release of v28 
> will be as solid as possible.
> 
> I've been using FreeBSD 9.0-CURRENT as of Dec 12th, and 8.2PRE as of Dec 16th
> 
> What's worked well:
> 
> - I've made and destroyed small raidz's (3-5 disks), large 26 disk raid-10's, 
> and a large 20 disk raid-50.
> - I've upgraded from v15, zfs 4, no issues on the different arrays noted above
> - I've confirmed that a v15 or v28 pool will import into Solaris 11 Express, 
> and vice versa, with the exception about dual log or cache devices noted 
> below. 
> - I've run many TB of data through the ZFS storage via benchmarks from my 
> VM's connected via NFS, to simple copies inside the same pool, or copies from 
> one pool to another. 
> - I've tested pretty much every compression level, and changing them as I 
> tweak my setup and try to find the best blend.
> - I've added and subtracted many a log and cache device, some in failed 
> states from hot-removals, and the pools always stayed intact.

Thank you very much for all your testing, that's really a valuable
contribution. I'll be happy to work with you on tracking down the
bottleneck in ZFSv28.

> Issues:
> 
> - Import of pools with multiple cache or log devices. (May be a very minor 
> point)
> 
> A v28 pool created in Solaris 11 Express with 2 or more log devices, or 2 or 
> more cache devices won't import in FreeBSD 9. This also applies to a pool 
> that is created in FreeBSD, is imported in Solaris to have the 2 log devices 
> added there, then exported and attempted to be imported back in FreeBSD. No 
> errors, zpool import just hangs forever. If I reboot into Solaris, import the 
> pool, remove the dual devices, then reboot into FreeBSD, I can then import 
> the pool without issue. A single cache, or log device will import just fine. 
> Unfortunately I deleted my witness-enabled FreeBSD-9 drive, so I can't easily 
> fire it back up to give more debug info. I'm hoping some kind soul will 
> attempt this type of transaction and report more detail to the list.
> 
> Note - I just decided to try adding 2 cache devices to a raidz pool in 
> FreeBSD, export, and then importing, all without rebooting. That seems to 
> work. BUT - As soon as you try to reboot FreeBSD with this pool staying 
> active, it hangs on boot. Booting into Solaris, removing the 2 cache devices, 
> then booting back into FreeBSD then works. Something is kept in memory 
> between exporting then importing that allows this to work.  

Unfortunately I'm unable to reproduce this. It works for me with 2 cache
and 2 log vdevs. I tried to reboot, etc. My test exactly looks like
this:

# zpool create tank raidz ada0 ada1
# zpool add tank cache ada0 ada1
# zpool export tank
# kldunload zfs
# zpool import tank

# reboot


> - Speed. (More of an issue, but what do we do?)
> 
> Wow, it's much slower than Solaris 11 Express for transactions. I do 
> understand that Solaris will have a slight advantage over any port of ZFS. 
> All of my speed tests are made with a kernel without debug, and yes, these 
> are -CURRENT and -PRE releases, but the speed difference is very large.

Before we go any further could you please confirm that you commented out
this line in sys/modules/zfs/Makefile:

CFLAGS+=-DDEBUG=1

This turns all kind of ZFS debugging and slows it down a lot, but for
the correctness testing is invaluable. This will be turned off once we
import ZFS into FreeBSD-CURRENT.

BTW. In my testing Solaris 11 Express is much, much slower than
FreeBSD/ZFSv28. And by much I mean two or more times in some tests.
I was wondering if they have some debug turned on in Express.

> At first, I thought it may be more of an issue with the ix0/Intel X520DA2 
> 10Gbe drivers that I'm using, since the bulk of my tests are over NFS (I'm 
> going to use this as a SAN via NFS, so I test in that environment). 
> 
> But - I did a raw cp command from one pool to another of several TB. I 
> executed the same command under FreeBSD as I did under Solaris 11 Express. 
> When executed in FreeBSD, the copy took 36 hours. With a fresh destination 
> pool of the same settings/compression/etc under Solaris, the copy took 7.5 
> hours. 

When you turn off compression (because it turns all-zero blocks into
holes) you can test it by simply:

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

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!


pgprFLLYTe9F4.pgp
Description: PGP signature

Re: why panic(9) ?

[Daniel Nebdal]

On Wed, Jan 12, 2011 at 1:43 PM, Nils Holland  wrote:
> C. P. Ghost wrote:
>
>> As far as I know, Windows NT is a microkernel arch, and
>> faulty drivers, often provided by external vendors would not
>> bring that system (as much as we hate or despise its
>> Windows OS personality that runs on top of it) to a complete halt.
>
> I don't know ... when Windows crashes (I'm no fan of it either, but anyway)
> and you ask Microsoft about it, then it's most of the time an external
> driver that is responsible. Graphics card driver seem to be the cause most
> often, but other stuff as well.

(...)
> Greetings,
> Nils

a) NT isn't really a microkernel; most drivers run in kernelspace and
can happily mess things up if they fail.
b) Graphics drivers are actually one of the things they've fixed
(well, re-fixed; this was also the case in 3.51) - from Vista and
onwards they mostly live in userspace. (I've had the graphics driver
crash on me a few times - it's restarted automatically, and all that
happens is that the screen goes black for some seconds. It's kind of
impressive.)

More on topic, I can only agree with the majority - failing fast is a
feature, both to mess things up as little as possible, and to make
diagnostics and later fixing easier.

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

Re: R: Recent mouse freeze problem with X, different window managers, any browser and flash.

[Jung-uk Kim]

On Thursday 13 January 2011 01:14 pm, Jung-uk Kim wrote:
> On Wednesday 12 January 2011 10:22 pm, Ariff Abdullah wrote:
> > On Wed, 12 Jan 2011 09:53:03 -0600
> >
> > eculp  wrote:
> > > Quoting Ariff Abdullah :
> > > > On Wed, 12 Jan 2011 22:51:29 +0800
> > > > Ariff Abdullah  wrote:
> > > >
> > > > []
> > > >
> > > >> Try disabling mtrr, machdep.disable_mtrrs=0 through
> > > >> boot prompt or /boot/loader.conf.
> > > >
> > > > Grr.. should be machdep.disable_mtrrs=1
> > >
> > > Caught it, changed it en loader.conf, rebooted and have had
> > > youtube
> > >
> > > running more that 10 minutes with no ill affects.
> >
> > Keep in mind that disabling mtrr is a temporary measure.
> >
> > > Want to clarify that this in with current i386.
> > >
> > > 9.0-CURRENT FreeBSD 9.0-CURRENT #161: Wed Jan 12 04:38:15 CST
> > > 2011
> > >
> > > r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO  i386
> > >
> > > Thanks again,
> > >
> > > ed
> > >
> > > Thanks so much for your help.
> > >
> > > ed
> > >
> > > >> If that is the case, you probably want this:
> > > >>
> > > >> http://people.freebsd.org/~ariff/misc/mtrr.diff
> >
> > This breakage was due to r215415 commit. Jung-uk Kim, any idea ?

Can you please try the attached patch *without* ariff's workaround?

Thanks,

Jung-uk Kim
Index: sys/amd64/amd64/initcpu.c
===
--- sys/amd64/amd64/initcpu.c   (revision 217356)
+++ sys/amd64/amd64/initcpu.c   (working copy)
@@ -169,6 +169,9 @@ void
 initializecpucache()
 {
 
+   /* Turn on normal cache mode. */
+   load_cr0(rcr0() & ~(CR0_CD | CR0_NW));
+
/*
 * CPUID with %eax = 1, %ebx returns
 * Bits 15-8: CLFLUSH line size
Index: sys/i386/i386/initcpu.c
===
--- sys/i386/i386/initcpu.c (revision 217356)
+++ sys/i386/i386/initcpu.c (working copy)
@@ -532,7 +532,6 @@ init_mendocino(void)
wrmsr(MSR_BBL_CR_CTL3, bbl_cr_ctl3);
}
 
-   load_cr0(rcr0() & ~(CR0_CD | CR0_NW));
intr_restore(saveintr);
 #endif /* CPU_PPRO2CELERON */
 }
@@ -701,6 +700,8 @@ initializecpu(void)
pg_nx = PG_NX;
}
 #endif
+   /* Turn on normal cache mode. */
+   load_cr0(rcr0() & ~(CR0_CD | CR0_NW));
break;
 #endif
default:
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: R: Recent mouse freeze problem with X, different window managers, any browser and flash.

[Jung-uk Kim]

On Wednesday 12 January 2011 10:22 pm, Ariff Abdullah wrote:
> On Wed, 12 Jan 2011 09:53:03 -0600
>
> eculp  wrote:
> > Quoting Ariff Abdullah :
> > > On Wed, 12 Jan 2011 22:51:29 +0800
> > > Ariff Abdullah  wrote:
> > >
> > > []
> > >
> > >> Try disabling mtrr, machdep.disable_mtrrs=0 through
> > >> boot prompt or /boot/loader.conf.
> > >
> > > Grr.. should be machdep.disable_mtrrs=1
> >
> > Caught it, changed it en loader.conf, rebooted and have had
> > youtube
> >
> > running more that 10 minutes with no ill affects.
>
> Keep in mind that disabling mtrr is a temporary measure.
>
> > Want to clarify that this in with current i386.
> >
> > 9.0-CURRENT FreeBSD 9.0-CURRENT #161: Wed Jan 12 04:38:15 CST
> > 2011
> >
> > r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO  i386
> >
> > Thanks again,
> >
> > ed
> >
> > Thanks so much for your help.
> >
> > ed
> >
> > >> If that is the case, you probably want this:
> > >>
> > >> http://people.freebsd.org/~ariff/misc/mtrr.diff
>
> This breakage was due to r215415 commit. Jung-uk Kim, any idea ?

Hmm...  Can you please tell me the exact CPU models?

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

Profiling code execution on amd64?

[Steve Kargl]

How does one profile one's code on freebsd-amd64?
It seems that gprof is broken.

troutmask:kargl[234] time ../penetration
CPU time: 7.327 min
Start time: 2011-01-13 08:59:18.419
 Stop time: 2011-01-13 09:06:39.082
  CPU time: 7.34 min
  440.68 real   440.25 user 0.11 sys

troutmask:kargl[235] gprof -b -l ../penetration penetration.gmon | more

granularity: each sample hit covers 4 byte(s) for 0.00% of 25.46 seconds

  %   cumulative   self  self total   
 time   seconds   secondscalls  ms/call  ms/call  name
 96.2  24.4824.48   282440 0.09 0.09  __mempoolm_MOD_memadd [4]
  1.4  24.84 0.350  100.00%   _mcount [5]
  0.7  25.03 0.191   188.65   188.82  __srfm_MOD_rms [6]
  0.5  25.14 0.12   608847 0.00 0.00  memcpy [11]

I cannot reconcile how 440.25 seconds is the same a 25.46.

Should src/usr.bin/gprof be disconnected from the build?

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

unknown mtx_assert at /usr/src/sys/x86/x86/io_apic.c:161

[Michael Jung]

Links to crash info below.

 

http://216.26.153.6/bounds

 

http://216.26.153.6/config.txt

 

http://216.26.153.6/ddb.txt

 

http://216.26.153.6/info.1

 

http://216.26.153.6/msgbuf.txt

 

http://216.26.153.6/panic.txt

 

http://216.26.153.6/ version.txt  

 

 


CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may contain 
information that is privileged, confidential, and exempt from 
disclosure under applicable law. If the reader of this message is 
not the intended recipient, you are hereby notified that any 
dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission 
in error, please notify us by telephone at (502) 212-4001 or 
notify us at PAI , Dept. 99, 11857 Commonwealth Drive, 
Louisville, KY  40299.  Thank you.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console freeze after "ifconfig wlan0 scan" with wi(4) pccard device

[Chris Brennan]

On Wed, Jan 12, 2011 at 7:56 PM, Anton Shterenlikht wrote:

>  but still can't connect to the gateway:
>
> PING 192.168.1.1 (192.168.1.1): 56 data bytes
> ping: sendto: No route to host
> ping: sendto: No route to host
> ping: sendto: No route to host
> ^C
> --- 192.168.1.1 ping statistics ---
> 3 packets transmitted, 0 packets received, 100.0% packet loss
>

After you get the IP, assign a default gw

route add default gw 192.168.1.1

that should do it

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

Intel 10GBase-LR Ethernet card detected as 10GBase-SR

[sthaug]

I have a server with an Intel X520-LR1 Ethernet card, which is a
10GBase-LR card:

  http://ark.intel.com/Product.aspx?id=41164

The card contains the Intel 82599ES controller:

  http://ark.intel.com/Product.aspx?id=41282

pciconf -lv shows:

ix0@pci0:28:0:0:class=0x02 card=0x00068086 chip=0x10fb8086 rev=0x01 
hdr=0x00
vendor = 'Intel Corporation'
class  = network
subclass   = ethernet

where /sys/dev/ixgbe/ixgbe_type.h has the PCI ID definition:

#define IXGBE_DEV_ID_82599_SFP  0x10FB

The problem is that this card is shown by ifconfig as a 10GBase-SR card:

% ifconfig ix0
ix0: flags=8843 metric 0 mtu 1500

options=1bb
ether 00:1b:21:7c:7b:94
media: Ethernet autoselect (10Gbase-SR )
status: active

I believe this is due to the following code in /sys/dev/ixgbe/ixgbe.c
line 423, routine ixgbe_attach():

case IXGBE_DEV_ID_82599_SFP:
adapter->optics = IFM_10G_SR;

I'm looking at version 1.17.2.12.2.1, from 8.2-RC1, but I see this code
is the same in version 1.45, from HEAD:

  
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ixgbe/ixgbe.c?rev=1.45;content-type=text/plain

I made a 1-line patch to the 8.2-RC1 code, enclosed below, and now have
ifconfig showing the expected value:

y% ifconfig ix0
ix0: flags=8843 metric 0 mtu 1500

options=1bb
ether 00:1b:21:7c:7b:94
media: Ethernet autoselect (10Gbase-LR )
status: active

Steinar Haug, Nethelp consulting, sth...@nethelp.no
--
--- ixgbe.c.orig2010-12-21 18:09:25.0 +0100
+++ ixgbe.c 2011-01-13 14:31:14.0 +0100
@@ -421,7 +421,7 @@
adapter->optics = IFM_10G_LR;
break;
case IXGBE_DEV_ID_82599_SFP:
-   adapter->optics = IFM_10G_SR;
+   adapter->optics = IFM_10G_LR;
ixgbe_num_segs = IXGBE_82599_SCATTER;
break;
case IXGBE_DEV_ID_82598_DA_DUAL_PORT :
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Intel 10GBase-LR Ethernet card detected as 10GBase-SR

[sthaug]

> I have a server with an Intel X520-LR1 Ethernet card, which is a
> 10GBase-LR card:
...
> The problem is that this card is shown by ifconfig as a 10GBase-SR card:
...
> I made a 1-line patch to the 8.2-RC1 code, enclosed below, and now have
> ifconfig showing the expected value:

Problem report and patch now available as kern/153951.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: R: Recent mouse freeze problem with X, different window managers, any browser and flash.

[eculp]

Quoting Ariff Abdullah :


On Wed, 12 Jan 2011 09:53:03 -0600
eculp  wrote:

Quoting Ariff Abdullah :

> On Wed, 12 Jan 2011 22:51:29 +0800
> Ariff Abdullah  wrote:
>>
> []
>>
>> Try disabling mtrr, machdep.disable_mtrrs=0 through
>> boot prompt or /boot/loader.conf.
>>
>
> Grr.. should be machdep.disable_mtrrs=1

Caught it, changed it en loader.conf, rebooted and have had youtube

running more that 10 minutes with no ill affects.


Keep in mind that disabling mtrr is a temporary measure.


Hopefully this will be announced when the problem is fixed because I  
have NO idea what mtrr value is, haven't thought about it and at my  
age, I would prefer to keep it that way ;)


Thanks,

ed




Want to clarify that this in with current i386.

9.0-CURRENT FreeBSD 9.0-CURRENT #161: Wed Jan 12 04:38:15 CST 2011

r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO  i386

Thanks again,

ed

Thanks so much for your help.

ed

>
>> If that is the case, you probably want this:
>>
>> http://people.freebsd.org/~ariff/misc/mtrr.diff
>>
>


This breakage was due to r215415 commit. Jung-uk Kim, any idea ?


--
Ariff Abdullah
FreeBSD

... Recording in stereo is obviously too advanced
and confusing for us idiot * users :P 

... Going with the standard and orthodox
is the death of intellect ..



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

R: ahci timeout

[Barbara]

>
>>From : nde...@gmail.com
>>
>>On 27 Dec, 2010, at 21:20 , Barbara wrote:
>>
>>> 
>>> As my old PATA hard disk was failing, I had to replace it with a new SATA 
>>> drive where I moved my FreeBSDs installations, as PATA drives are not 
easy 
>to 
>>> find these days.
>>> So I had to move one of my data drive from a VIA8237A SATA controller to 
>the 
>>> last free SATA slot on a Marvell 88SX6121 to make room for the new hd.
>>> The hd I moved was working perfectly when connected to the VIA controller.
>>> Now, with the Marvell I'm getting messages like the following twos while 
>using 
>>> the disk:
>>>ahcich0: Timeout on slot 10
>>>ahcich0: is  cs 3800 ss 3c00 rs 3c00 tfd 50010040 
>serr 
>>> 
>>> 
>>>ahcich0: Timeout on slot 5
>>>ahcich0: is  cs 0180 ss 01e0 rs 01e0 tfd 50040040 
>serr 
>>> 
>>> 
>>> This doesn't happen regularly. For example downloading from a slow 
website 
>on 
>>> it, so few kb/s, is ok.
>>> But if I copy files from the disk attacked to the Marvell controller to 
>>> another another disk, or for example run md5 on some files, it's very 
>likely to 
>>> happen.
>>> The process accessing the disk can not be killed even with -9, ^C does 
>>> nothing, and umount doesn't exit.
>>> If I'm copying files on it from another disk it can't be unmounted too as 
>the 
>>> unkillable process has it in use.
>>> On shutdown many disk doesn't get unmounted, so there are a lot of fsck 
on 
>>> boot, and on CURRENT (last built yesterday), FreeBSD enter debugger as it 
>fail 
>>> flushing disk caches.
>>> 
>>> Relevant part from dmesg:
>>> 
>>> atapci0:  port 0xdc00-0xdc07,0xd880-
>>> 0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfbdffc00-
0xfbdf 
>irq 
>>> 28 at device 0.0 on pci6
>>> ahci0:  on atapci0
>>> ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported
>>> ahcich0:  at channel 0 on ahci0
>>> ahcich1:  at channel 1 on ahci0
>>> ata2:  on atapci0
>>> atapci1:  port 0xbc00-0xbc07,0xb880-0xb883,
>>> 0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f,0xb000-0xb0ff irq 21 at device 
>15.0 
>>> on pci0
>>> ata3:  on atapci1
>>> ata4:  on atapci1
>>> atapci2:  port 0x1f0-0x1f7,0x3f6,0x170-
0x177,
>>> 0x376,0xfc00-0xfc0f at device 15.1 on pci0
>>> ata0:  on atapci2
>>> ata1:  on atapci2
>>> 
>>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
>>> ada0:  ATA-8 SATA 2.x device
>>> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
>>> ada0: Command Queueing enabled
>>> ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
>>> ada1 at ata3 bus 0 scbus3 target 0 lun 0
>>> ada1:  ATA-7 SATA 2.x device
>>> ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
>>> ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C)
>>> ada2 at ata4 bus 0 scbus4 target 0 lun 0
>>> ada2:  ATA-8 SATA 1.x device
>>> ada2: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
>>> ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
>>> ada3 at ata0 bus 0 scbus5 target 0 lun 0
>>> ada3:  ATA-7 device
>>> ada3: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
>>> ada3: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C)
>>> 
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>
>>Just to add a "me too".
>>
>>I'm running -STABLE but have the same problems with Marvell 88SX6121 giving 
>"ahci timeout" messages.
>>
>>Regards,
>>Nikolay
>>
>
>Nikolay, thanks for the feedback, even if unfortunately it's negative...
>I see that in both 8-STABLE (8.2-PRERELEASE now) and 9.0-CURRENT, both 
rebuilt 
>no more than a week ago.
>I've also tried rebuilding the kernel with:
>   options CAMDEBUG
>   options CAM_DEBUG_BUS=0
>   options CAM_DEBUG_TARGET=0
>   options CAM_DEBUG_LUN=0
>   options CAM_DEBUG_FLAGS=CAM_DEBUG_TRACE
>(0 is the bus/target/lun of the marvell controller/attached hd)
>and run a test computing md5 for about 60GB of files.
>Obviously, as the debug options where active, it run successfully without 
any 
>problems :)
>Is there any other info I should provide or any other test that I can do?
>
>Thanks
>Barbara
>

Maybe the attached disk has some problems which aren't handled if it's 
attached to a 88SE6121 controller?
>From what I can see, connecting it to the other internal sata controller, 
which is a VIA 8237A, or to an external PCIe Sil3132 controller using the siis 
driver, those timeouts aren't happening.
Anyway I see something which I don't understand.
I tried reading some files (~1 gb) from the same slice (1st one, ~200gb) while 
looking at gstat.
Some files are being read at >100mb/s some others at about 4 mb/s. It seems 
that a "zone" of the disk is very slow.
The disk is a Seagate 7200.12 and neither smartmontools nor SeaTools (Seagate 
diagnostic) report problems with i