Re: Freebsd 8.1 + xorg + radeonhd hang

2010-09-14 Thread Warren Block

On Wed, 15 Sep 2010, Oliver Pinter wrote:



it's an old problem:
http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009372.html


Please don't top-post, it makes responding more difficult.


And still exist... with or without dri/3d, it's a bug between freebsd
agp and xorg-server.

When you use vesa, than this problem is elliminated. With radeon or
radeon-hd driver, the problem come back, and the machine locked up.
When you killed the xserver, end kldunloaded the radeon modul, then
presented a small memory leak, and the radeon kernek modul is not
reloadable.
The DRI/DRM/3D is completly independent from this bug. The bug is in
libpciaccess or xorg-server. The old xserver (<=1.4.X) is bugfree


Was OP unloading the radeon kernel module?  I can verify that once the 
radeon module is unloaded, it doesn't work after reloading.  But for me, 
X just complains about no screens found, it doesn't lock up.  If the 
radeon module stays loaded, X starts and restarts fine.  Tested ten 
restarts without problems.

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


Re: Freebsd 8.1 + xorg + radeonhd hang

2010-09-14 Thread Oliver Pinter
Hi all!

it's an old problem:
http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009372.html

And still exist... with or without dri/3d, it's a bug between freebsd
agp and xorg-server.

When you use vesa, than this problem is elliminated. With radeon or
radeon-hd driver, the problem come back, and the machine locked up.
When you killed the xserver, end kldunloaded the radeon modul, then
presented a small memory leak, and the radeon kernek modul is not
reloadable.
The DRI/DRM/3D is completly independent from this bug. The bug is in
libpciaccess or xorg-server. The old xserver (<=1.4.X) is bugfree





On 9/15/10, Warren Block  wrote:
> On Tue, 14 Sep 2010, Eivind E wrote:
>>
>
> First, the intermittent nature of the problem sounds like it might be
> hardware failure.  The only easy way to test that would be to swap in
> another video board, but people rarely have extras.
>
> You also mentioned upgrading from 7.x to 8.1.  It's worth running
> pkg_libchk from sysutils/bsdadminscripts to make sure nothing was
> missed.
>
> Back to the xorg.conf...
>
> Adding Option "Log" "Sync" to ServerLayout may help preserve the
> Xorg.0.log file.  Untested by me so far, but shouldn't hurt.
>
>> I'll repost the xorg.conf here
>>
>> Section "ServerLayout"
>>  Identifier "Layout0"
>>  Screen  0  "Screen0" 0 0
>>  InputDevice"Tastatur" "CoreKeyboard"
>>  InputDevice"Mus" "CorePointer"
>>  Option  "AllowEmptyInput" "off"
>> EndSection
>
> AllowEmptyInput (and fire) bad!  Use AutoAddDevices Off instead.
> (http://www.wonkity.com/~wblock/docs/html/aei.html)
>
>> Section "Files"
>> EndSection
>
> Looks wrong, but works here.  I'd suggest leaving out the section
> entirely rather than leaving it empty, though.
>
>> Section "Module"
>>  # Load "freetype"
>>  # Load "xtt"
>>  Load  "extmod"
>>  Load  "glx"
>>  Load  "dri"
>>  Load  "dbe"
>>  Load  "record"
>>  Load  "xtrap"
>>  Load  "type1"
>>  Load  "speedo"
>> EndSection
>
> All but the commented first two and last three are default.  Worth
> commenting out the last three and testing, too.
>
>> Section "Monitor"
>>  Identifier   "Skjerm"
>>  HorizSync31.5 - 48.5
>>  VertRefresh  50.0 - 70.0
>> EndSection
>>
>> Section "Device"
>>  Identifier  "Grafikkort"
>>  Driver  "radeonhd"
>>  Option  "HPD" "off"
>> EndSection
>
> My success rate with the radeonhd driver is pretty much nonexistent.
>
>> Section "Screen"
>>  Identifier "Screen0"
>>  Device "Grafikkort"
>>  Monitor"Skjerm"
>>  DefaultDepth 16
>>  SubSection "Display"
>>  Depth 16
>>  Modes"1280x1024" "1280x960" "1152x864" "1024x768" "800x600"
>> "640x480"
>>  EndSubSection
>> EndSection
>
> 16-bit?  That may actually be slower than 24, depending on how the card
> is built.  Should still work, though it's worth commenting out in both
> places for testing.
>
>> Section "DRI"
>>  Mode 0666
>> EndSection
>
> Should not cause a problem, although I use 0660.
>
> My full xorg.conf for the X1650 is here:
> http://wonkity.com/~wblock/radeon/x1650/xorg.conf
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Freebsd 8.1 + xorg + radeonhd hang

2010-09-14 Thread Warren Block

On Tue, 14 Sep 2010, Eivind E wrote:




First, the intermittent nature of the problem sounds like it might be 
hardware failure.  The only easy way to test that would be to swap in 
another video board, but people rarely have extras.


You also mentioned upgrading from 7.x to 8.1.  It's worth running 
pkg_libchk from sysutils/bsdadminscripts to make sure nothing was 
missed.


Back to the xorg.conf...

Adding Option "Log" "Sync" to ServerLayout may help preserve the 
Xorg.0.log file.  Untested by me so far, but shouldn't hurt.



I'll repost the xorg.conf here

Section "ServerLayout"
Identifier "Layout0"
Screen  0  "Screen0" 0 0
InputDevice"Tastatur" "CoreKeyboard"
InputDevice"Mus" "CorePointer"
Option  "AllowEmptyInput" "off"
EndSection


AllowEmptyInput (and fire) bad!  Use AutoAddDevices Off instead.
(http://www.wonkity.com/~wblock/docs/html/aei.html)


Section "Files"
EndSection


Looks wrong, but works here.  I'd suggest leaving out the section 
entirely rather than leaving it empty, though.



Section "Module"
# Load "freetype"
# Load "xtt"
Load  "extmod"
Load  "glx"
Load  "dri"
Load  "dbe"
Load  "record"
Load  "xtrap"
Load  "type1"
Load  "speedo"
EndSection


All but the commented first two and last three are default.  Worth 
commenting out the last three and testing, too.



Section "Monitor"
Identifier   "Skjerm"
HorizSync31.5 - 48.5
VertRefresh  50.0 - 70.0
EndSection

Section "Device"
Identifier  "Grafikkort"
Driver  "radeonhd"
Option  "HPD" "off"
EndSection


My success rate with the radeonhd driver is pretty much nonexistent.


Section "Screen"
Identifier "Screen0"
Device "Grafikkort"
Monitor"Skjerm"
DefaultDepth 16
SubSection "Display"
Depth 16
Modes"1280x1024" "1280x960" "1152x864" "1024x768" "800x600" 
"640x480"
EndSubSection
EndSection


16-bit?  That may actually be slower than 24, depending on how the card 
is built.  Should still work, though it's worth commenting out in both 
places for testing.



Section "DRI"
Mode 0666
EndSection


Should not cause a problem, although I use 0660.

My full xorg.conf for the X1650 is here:
http://wonkity.com/~wblock/radeon/x1650/xorg.conf
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Freebsd 8.1 + xorg + radeonhd hang

2010-09-14 Thread Eivind E

On Tue, 14 Sep 2010, Pavel Gorshkov wrote:


On Mon, Sep 13, 2010 at 11:47:18PM +0200, Eivind E wrote:

Yeah, still hangs hard. Trying the normal radeon driver together
with Option "DRI" "False" as suggested to me in another mail
did let X start up once, but set the screen to much darker
colours (which also continued when exiting). Starting X
another time again made the machine hang again.


You might want to try putting the following line into the
appropriate "Device" section:

   Option  "AccelMethod"   "EXA"


I just tried it, still hangs.



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


Re: Freebsd 8.1 + xorg + radeonhd hang

2010-09-14 Thread Eivind E

On Tue, 14 Sep 2010, Warren Block wrote:


On Mon, 13 Sep 2010, Eivind E wrote:


On Mon, 13 Sep 2010, Oliver Fromme wrote:


> The machine is now running FreeBSD 8.1, but after rebuilding all
> packages via ports, the problem with the radeonhd driver is back,
> showing exactly the same behaviour as before.

Did you try the normal radeon driver (not radeonhd)?
It supports the RV515 chip used by the X1550, too.


Yeah, still hangs hard. Trying the normal radeon driver together
with Option "DRI" "False" as suggested to me in another mail
did let X start up once, but set the screen to much darker
colours (which also continued when exiting). Starting X
another time again made the machine hang again.


Could you post pointers to your xorg.conf and Xorg.0.log?  I wouldn't think 
the X1550 is very different from my X1650, which is AFAICT problem-free.


The xorg.conf was in my initial mail on the subject. The problem with
Xorg.0.log is that it seems that the file is not written (or still
in some buffer, not on disk) when the machine hangs. I'm
thinking about nullmodem or an old line printer and redirecting
output from X, problem is that my parallel and serialports which is on
a card needing the puc driver hasn't worked since upgrading
to 8.1... Don't know if it would be possible to get the file
if I mounted /var/log from nfs.

I'll repost the xorg.conf here

Section "ServerLayout"
Identifier "Layout0"
Screen  0  "Screen0" 0 0
InputDevice"Tastatur" "CoreKeyboard"
InputDevice"Mus" "CorePointer"
Option  "AllowEmptyInput" "off"
EndSection

Section "Files"
EndSection

Section "Module"
# Load "freetype"
# Load "xtt"
Load  "extmod"
Load  "glx"
Load  "dri"
Load  "dbe"
Load  "record"
Load  "xtrap"
Load  "type1"
Load  "speedo"
EndSection

Section "InputDevice"
Identifier  "Mus"
Driver  "mouse"
Option  "Protocol" "Auto"
Option  "Device" "/dev/sysmouse"
Option  "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
Identifier  "Tastatur"
Driver  "keyboard"
Option  "XkbModel" "pc101"
#   Option  "XkbModel" "pc105"
Option  "XkbLayout" "no"
Option  "XkbOptions" "ctrl:swapcaps"
EndSection

Section "Monitor"
Identifier   "Skjerm"
HorizSync31.5 - 48.5
VertRefresh  50.0 - 70.0
EndSection

Section "Device"
Identifier  "Grafikkort"
Driver  "radeonhd"
Option  "HPD" "off"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Grafikkort"
Monitor"Skjerm"
DefaultDepth 16
SubSection "Display"
Depth 16
Modes"1280x1024" "1280x960" "1152x864" "1024x768"
"800x600" "640x480"
EndSubSection
EndSection

Section "DRI"
Mode 0666
EndSection


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


Re: Freebsd 8.1 + xorg + radeonhd hang

2010-09-14 Thread Warren Block

On Mon, 13 Sep 2010, Eivind E wrote:


On Mon, 13 Sep 2010, Oliver Fromme wrote:


> The machine is now running FreeBSD 8.1, but after rebuilding all
> packages via ports, the problem with the radeonhd driver is back,
> showing exactly the same behaviour as before.

Did you try the normal radeon driver (not radeonhd)?
It supports the RV515 chip used by the X1550, too.


Yeah, still hangs hard. Trying the normal radeon driver together
with Option "DRI" "False" as suggested to me in another mail
did let X start up once, but set the screen to much darker
colours (which also continued when exiting). Starting X
another time again made the machine hang again.


Could you post pointers to your xorg.conf and Xorg.0.log?  I wouldn't 
think the X1550 is very different from my X1650, which is AFAICT 
problem-free.


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


Re: Freebsd 8.1 + xorg + radeonhd hang

2010-09-14 Thread Eivind E

On Tue, 14 Sep 2010, Roland Smith wrote:


On Tue, Sep 14, 2010 at 12:04:16AM +0200, Eivind E wrote:

On Mon, 13 Sep 2010, Roland Smith wrote:



Did you try the normal radeon driver (not radeonhd)?
It supports the RV515 chip used by the X1550, too.


Keep in mind that normal radeon driver is called x11-drivers/xf86-video-ati
now.

If you load the drm.ko and radeon.ko (and maybe agp.ko) kernel models with
this driver, you'll have accellerated 3D as well as 2D (both XAA and the newer
EXA). Works like a charm on my Radeon X 1650 Pro, and should work with your
card as well.


Tried to substitute the driver with ati and loading radeon.ko (which
automatically loaded drm.ko) and had the same results as the plain
radeon driver. X starts up once in a while, but the screen goes
to about half of normal brightness and the view is moved down and to the
right.


Do you have a modeline in your xorg.conf? If so, try taking it out. Or try
running 'X -configure' from the console to generate a new basic
xorg.conf. Some monitors come with a button or control to automatically tune
them to the video source. If you have that it might help as well. If not, try
x11/xvidtune.


No, there are no modelines, just the basic configuration I posted
in the first mail.

I also tried X -configure again (after loading radeon.ko and drm.ko
manually). It produced a configfile just fine, but running X
with that file locked the machine up again.

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


Re: RELENG_7 em problems (and RELENG_8)

2010-09-14 Thread Mike Tancsa

Hi Jack,
Any plans to commit the patch below ? I have been running it 
on a number of boxes and it works as expected with no side effects.


---Mike


At 04:00 PM 8/17/2010, Pyun YongHyeon wrote:

On Tue, Aug 17, 2010 at 03:55:12PM -0400, Mike Tancsa wrote:
> At 02:52 PM 8/17/2010, Pyun YongHyeon wrote:
>
> >Here is updated patch for HEAD and stable/8.
> >http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch
> >
> >It seems to work as expected under my limited environments. If
>
> Thanks! The patch applies cleanly and all works as expected now! I am
> no longer able to trigger the bug. I just use the stock unmodified
> driver normally, so no multi queues
>

Glad to hear that. Thanks for testing!

> # vmstat -i
> interrupt  total   rate
> irq256: em0  149  0
> irq257: em13  0
> irq259: em3  971  2
> irq260: ahci0   1520  3
>
>
>
> em3: flags=8843 metric 0 mtu 1500
> 
options=219b

> ether 00:15:17:xx:xx:xx
> inet6 fe80::215:17ff:fexx:%em3 prefixlen 64 scopeid 0x4
> inet 192.168.xx.xx netmask 0xff00 broadcast 192.168.xx.xx
> nd6 options=3
> media: Ethernet autoselect (100baseTX )
> status: active
>
>
> e...@pci0:3:0:0: class=0x02 card=0x34ec8086 chip=0x10d38086
> rev=0x00 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
> class  = network
> subclass   = ethernet
> cap 01[c8] = powerspec 2  supports D0 D3  current D0
> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
> cap 11[a0] = MSI-X supports 5 messages in map 0x1c
>
>
>
> patch < em.csum_tso.20100817.patch
> Hmm...  Looks like a unified diff to me...
> The text leading up to this was:
> --
> |Index: sys/dev/e1000/if_em.c
> |===
> |--- sys/dev/e1000/if_em.c  (revision 211398)
> |+++ sys/dev/e1000/if_em.c  (working copy)
> --
> Patching file sys/dev/e1000/if_em.c using Plan A...
> Hunk #1 succeeded at 237.
> Hunk #2 succeeded at 1730.
> Hunk #3 succeeded at 1759.
> Hunk #4 succeeded at 1930.
> Hunk #5 succeeded at 3148.
> Hunk #6 succeeded at 3351.
> Hunk #7 succeeded at 3533.
> Hunk #8 succeeded at 3590.
> Hunk #9 succeeded at 3603.
> Hmm...  The next patch looks like a unified diff to me...
> The text leading up to this was:
> --
> |Index: sys/dev/e1000/if_em.h
> |===
> |--- sys/dev/e1000/if_em.h  (revision 211398)
> |+++ sys/dev/e1000/if_em.h  (working copy)
> --
> Patching file sys/dev/e1000/if_em.h using Plan A...
> Hunk #1 succeeded at 284.
> done
>
> ---Mike
>
>
> >you're using multiple Tx queues with em(4) it would be better to
> >disable Tx checksum offloading as driver always have to create a
> >new checksum context for each frame. This will effectively disable
> >pipelined Tx data DMA which in turn greatly slows down Tx
> >performance for small sized frames. The reason driver have to
> >create a new checksum context when it uses multiple Tx queues comes
> >from hardware limitation. The controller tracks only for the last
> >context descriptor that was written such that driver does not know
> >the state of checksum context configured in other Tx queue.
> >Hope this helps.
> >
> >>
> >>
> >> ---Mike
> >>
> >>
> >> At 03:36 PM 7/2/2010, Pyun YongHyeon wrote:
> >> >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote:
> >> >> Hi Jack,
> >> >> Just a followup to the email below. I now saw what appears
> >> >> to be the same problem on RELENG_8, but on a different nic and with
> >> >> VLANs.  So not sure if this is a general em problem, a problem
> >> >> specific to some em NICs, or a TSO problem in general.  The issue
> >> >> seemed to be triggered when I added a new vlan based on
> >> >>
> >> >> e...@pci0:14:0:0:class=0x02 card=0x109a15d9
> >> >> chip=0x109a8086 rev=0x00 hdr=0x00
> >> >> vendor = 'Intel Corporation'
> >> >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)'
> >> >> class  = network
> >> >> subclass   = ethernet
> >> >> cap 01[c8] = powerspec 2  supports D0 D3  current D0
> >> >> cap 05[d0] = MSI supports 1 message, 64 bit enabled 
with 1 message

> >> >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
> >> >>
> >> >> pci14:  on pcib5
> >> >> em3:  port 0x6000-0x601f
> >> >> mem 0xe830-0xe831 irq 17 at device 0.0 on pci14
> >> >> em3: Using MSI interrupt
> >> >> em3: [FILTER]
> >> >> em3: Ethernet address: 00:30:48:9f:eb:81
> >> >>
> >> >> em3: flags=8943
> >> >> metric 0

Re: AoE driver for FBSD8 or later?

2010-09-14 Thread George Mamalakis

 On 14/9/2010 4:35 ??, Max Khon wrote:

George,

On Tue, Sep 14, 2010 at 5:01 PM, George Mamalakis > wrote:


On Mon, Sep 13, 2010 at 7:53 PM, Max Khon mailto:f...@samodelkin.net> >> wrote:

   Have you tried to contact coraid on this matter?

Can you try this port version?

http://people.freebsd.org/~fjoe/aoe-2.tar.gz




Max,

thank you very much for your help. The driver works fine; I am
able to see all 13T.
In case something goes wrong I will inform you. For the time
being, everything is OK.


I committed the port to the FreeBSD ports tree: ports/net/aoe.

I also committed ports/net/vblade (user-space AoE target) -- I used it 
for testing. I am not sure that it can be used in production due to 
possible performance problems.


Max


Max,

good job! I will benchmark both drivers (fbsd and linux) to compare 
results.


Thank you once more for your immediate actions and answers! Your have 
been profoundly quick and well targeted on your answers, no matter how 
easy it may have been for you to alter the existing code.

Thumbs up to the fbsd community!

great job man!

mamalos

--
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379

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


Re: AoE driver for FBSD8 or later?

2010-09-14 Thread Ivan Voras

On 09/14/10 12:01, George Mamalakis wrote:


thank you very much for your help. The driver works fine; I am able to
see all 13T.
In case something goes wrong I will inform you. For the time being,
everything is OK.


As it is a relatively uncommon protocol, can you run some tests and 
describe your experiences with AoE? Both good and bad experiences :)


(if you need advice on which tests, try bonnie++, blogbench and 
randomio, all are under ports/benchmarks)



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


Re: AoE driver for FBSD8 or later?

2010-09-14 Thread Ivan Voras

On 09/14/10 15:35, Max Khon wrote:

On Tue, Sep 14, 2010 at 5:01 PM, George Mamalakiswrote:



thank you very much for your help. The driver works fine; I am able to see
all 13T.
In case something goes wrong I will inform you. For the time being,
everything is OK.


I committed the port to the FreeBSD ports tree: ports/net/aoe.


ATA over Ethernet seems interesting enough as a concept - any ideas why 
this code isn't integrated into base?



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


Re: AoE driver for FBSD8 or later?

2010-09-14 Thread pluknet
On 14 September 2010 17:35, Max Khon  wrote:
> George,
>
> On Tue, Sep 14, 2010 at 5:01 PM, George Mamalakis wrote:
>
>
>> On Mon, Sep 13, 2010 at 7:53 PM, Max Khon > f...@samodelkin.net>> wrote:
>>
>
>
>>    Have you tried to contact coraid on this matter?
>>>
>>> Can you try this port version?
>>>
>>> http://people.freebsd.org/~fjoe/aoe-2.tar.gz<
>>> http://people.freebsd.org/%7Efjoe/aoe-2.tar.gz>
>>>
>>
>> Max,
>>
>> thank you very much for your help. The driver works fine; I am able to see
>> all 13T.
>> In case something goes wrong I will inform you. For the time being,
>> everything is OK.
>>
>
> I committed the port to the FreeBSD ports tree: ports/net/aoe.
>
> I also committed ports/net/vblade (user-space AoE target) -- I used it for
> testing. I am not sure that it can be used in production due to possible
> performance problems.
>

Thanks, Max.
I wonder the port has not yet been in the Collection until now.

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


Re: AoE driver for FBSD8 or later?

2010-09-14 Thread Max Khon
George,

On Tue, Sep 14, 2010 at 5:01 PM, George Mamalakis wrote:


> On Mon, Sep 13, 2010 at 7:53 PM, Max Khon  f...@samodelkin.net>> wrote:
>


>Have you tried to contact coraid on this matter?
>>
>> Can you try this port version?
>>
>> http://people.freebsd.org/~fjoe/aoe-2.tar.gz<
>> http://people.freebsd.org/%7Efjoe/aoe-2.tar.gz>
>>
>
> Max,
>
> thank you very much for your help. The driver works fine; I am able to see
> all 13T.
> In case something goes wrong I will inform you. For the time being,
> everything is OK.
>

I committed the port to the FreeBSD ports tree: ports/net/aoe.

I also committed ports/net/vblade (user-space AoE target) -- I used it for
testing. I am not sure that it can be used in production due to possible
performance problems.

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


FreeBSD 8.1/amd64 SMP + X11 + radeon/radeonhd crash

2010-09-14 Thread O. Hartmann
Problem: FreeBSD 8.1-STABLE/amd64 crashes with radeon and radeonhd in 
different, weird ways.
I figured out when changing a box from a single-core hardware platform 
with FBSD 8.1-STABLE/amd64 UP kernel to a SMP kernel with a dul core CPU 
that a former 'stble' arragemnet of a AMD HD4830 and radeon/radeonhd 
driver became instable. Whenever I leave an X11 session returning to 
xdm's login screen, the box freezes and only reset can bring it back to 
life.


My lab's box is still as reported months ago of the same problemacy. The 
box runs also FreeBSD 8.1-STABLE/amd64 and has a SMP kernel running. The 
graphics adaptor was a HD4670, now a HD4770. Exiting a session and 
returning to the login screen is the same, the box freezes.


Also very strange is the behaviour when trying to use HAL and DBUS as 
introduced with the newer X11 port revision. With both radeon and 
radeonhd the box starts well, presents the login screen and is network 
accessible. But whenever I activate HAL and DBUS (with a copy of 
X11/xorg.conf of my private box and configuration which works which the 
same OS revision) the box dies immediately and freezes with a black 
screen when X11 tries to come up (the xdm in this case).


Even with identical configs and DRI/EXA turned off explicitely the box 
freezes if hal and dbus are enabled (config is, as I mentioned, adjusted 
to work with dbus and hal as it does on my private box).


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


Re: Freebsd 8.1 + xorg + radeonhd hang

2010-09-14 Thread Pavel Gorshkov
On Mon, Sep 13, 2010 at 11:47:18PM +0200, Eivind E wrote:
> Yeah, still hangs hard. Trying the normal radeon driver together
> with Option "DRI" "False" as suggested to me in another mail
> did let X start up once, but set the screen to much darker
> colours (which also continued when exiting). Starting X
> another time again made the machine hang again.

You might want to try putting the following line into the
appropriate "Device" section:

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


Re: ipfw: Too many dynamic rules

2010-09-14 Thread Jeremy Chadwick
On Tue, Sep 14, 2010 at 01:12:00PM +0200, Gareth de Vaux wrote:
> On Tue 2010-09-14 (04:03), Jeremy Chadwick wrote:
> > You're absolutely certain these are all in FIN_WAIT_2 state and not
> > TIME_WAIT?
> 
> Yup,
> 
> $ netstat -an | grep FIN_WAIT_1 | wc -l
>   57
> $ netstat -an | grep FIN_WAIT_2 | wc -l
>  431
> $ netstat -an | grep TIME_WAIT | wc -l
>   17

Regarding net.inet.tcp.finwait2_timeout=15000 -- you don't see any
improvement at all?  That's a bit strange.  There's probably something
about ipfw I'm not getting.  Adding luigi@ to the CC list, since I think
he's familiar with ipfw internals.

FWIW, I'd recommend keeping an appended log of output from something
like this script:

while true
do
  echo "`date` -- `netstat -n | grep -c FIN_WAIT_2`" >> /some/log
  sleep 5
done

Just make sure the sleep interval is lower than the FIN timeout.

Another thing to try: setting net.inet.tcp.fast_finwait2_recycle=1 and
see if this makes a difference.  I'm not familiar with this setting
myself, but some Google results indicate some people do use it.  The
sysctl description is a bit vague too.

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://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 "freebsd-stable-unsubscr...@freebsd.org"


Re: ipfw: Too many dynamic rules

2010-09-14 Thread Gareth de Vaux
On Tue 2010-09-14 (04:30), Jeremy Chadwick wrote:
> Regarding net.inet.tcp.finwait2_timeout=15000 -- you don't see any
> improvement at all?  That's a bit strange.  There's probably something

If there was an improvement it was subtle (I was doing sporadic
measurements), just that in the end my firewall was getting overloaded
either way.

> FWIW, I'd recommend keeping an appended log of output from something
> like this script:

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


Re: ipfw: Too many dynamic rules

2010-09-14 Thread Gareth de Vaux
On Tue 2010-09-14 (04:03), Jeremy Chadwick wrote:
> You're absolutely certain these are all in FIN_WAIT_2 state and not
> TIME_WAIT?

Yup,

$ netstat -an | grep FIN_WAIT_1 | wc -l
  57
$ netstat -an | grep FIN_WAIT_2 | wc -l
 431
$ netstat -an | grep TIME_WAIT | wc -l
  17
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: ipfw: Too many dynamic rules

2010-09-14 Thread Jeremy Chadwick
On Tue, Sep 14, 2010 at 12:36:57PM +0200, Gareth de Vaux wrote:
> On Fri 2010-09-10 (13:49), Gareth de Vaux wrote:
> > > Thirdly, if you feel FIN_WAIT2 is the cause of your problem, then you
> > > should consider adjusting the following sysctl:
> > > 
> > > net.inet.tcp.finwait2_timeout
> > > 
> > > Try something like 15000 (15 seconds) instead of the default (6).
> > 
> > Ok that seems to be doing something. Will report back later.
> 
> Nope it's not helping. That and/or dropping net.inet.ip.fw.dyn_ack_lifetime.

You're absolutely certain these are all in FIN_WAIT_2 state and not
TIME_WAIT?

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://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 "freebsd-stable-unsubscr...@freebsd.org"


Re: ipfw: Too many dynamic rules

2010-09-14 Thread Gareth de Vaux
On Fri 2010-09-10 (13:49), Gareth de Vaux wrote:
> > Thirdly, if you feel FIN_WAIT2 is the cause of your problem, then you
> > should consider adjusting the following sysctl:
> > 
> > net.inet.tcp.finwait2_timeout
> > 
> > Try something like 15000 (15 seconds) instead of the default (6).
> 
> Ok that seems to be doing something. Will report back later.

Nope it's not helping. That and/or dropping net.inet.ip.fw.dyn_ack_lifetime.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: AoE driver for FBSD8 or later?

2010-09-14 Thread George Mamalakis

 On 13/09/2010 16:20, Max Khon wrote:

George,

On Mon, Sep 13, 2010 at 7:53 PM, Max Khon > wrote:


Have you tried to contact coraid on this matter?


Can you try this port version?

http://people.freebsd.org/~fjoe/aoe-2.tar.gz 



Max



Max,

thank you very much for your help. The driver works fine; I am able to 
see all 13T.
In case something goes wrong I will inform you. For the time being, 
everything is OK.


mamalos

--
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379

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


Re: Enabling MCA causes system hangs

2010-09-14 Thread Daniel O'Connor

On 10/09/2010, at 22:00, Andriy Gapon wrote:
>>> uname is.. FreeBSD midget.dons.net.au 8.0-STABLE FreeBSD 8.0-STABLE #6
>>> r202903M: Sun Jan 24 13:45:11 CST 2010
>>> dar...@midget.dons.net.au:/usr/obj/usr/src/sys/MIDGET  amd64
> 
> Oh, I should have payed attention to the version.
> I think that this is a known and resolved problem.
> There is a hardware bug in AMD 10h processors that is triggered by combination
> of enabled MCA and FreeBSD superpages.
> So, you either have to disable one of them or upgrade to a more recent 
> version.
> The version you need is r206183.  The latest stable/8 would do, obviously.

I'll try updating to stable/8 - I've been meaning to anyway.

Just to find the spare time to do 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






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