Re: Serial console problems with stable/8

[Oliver Fromme]

Jeremy Chadwick wrote:
 > Is there a PS/2 keyboard hooked up to this machine when you're
 > attempting to get serial console output?

Kind of.  It's connected to a local KVM switch.

 > If so, I'm not too surprised it doesn't work (re: -P flag).

If -P is not supposed to activate the serial console, then
the boot.config(5) manpage is in urgent need of a fix.
Quote:

 >  The command:
 >
 >   # echo "-P" > /boot.config
 >
 >  will activate the serial console of FreeBSD.

Also, with that flag it has worked fine for ages, until
I updated to 8.1-stable.  There must be a regression
somewhere.

 > Can you try the following?
 > 
 > 1) Removing kernel_options and console from loader.conf
 > 2) Place "-P" in /boot.config instead
 > 
 > If this doesn't change the behaviour, please replace -P and with -D -h
 > and see if there's any improvement.

I already have tried all kinds of different combinations
when I sat in front of the box yesterday.  I'm not sure
if I have tried the exact combination that you suggest,
though.  I also don't understand why those changes should
improve anything.

Anyway, I will try next time I'm near the machine (it's 
a three hours ride) which will probably be on Friday.
If it won't work then I'll downgrade it to 7.1 the same
day.

BTW, the interesting thing is that all processes that try
to access the console hang in "ttydcd".  I'm not familiar
with the tty code ...  Does anyone have an idea what this
means?

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

With Perl you can manipulate text, interact with programs, talk over
networks, drive Web pages, perform arbitrary precision arithmetic,
and write programs that look like Snoopy swearing.
___
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: Serial console problems with stable/8

[Jeremy Chadwick]

On Mon, Sep 13, 2010 at 09:21:21AM +0200, Oliver Fromme wrote:
> Jeremy Chadwick wrote:
>  > Is there a PS/2 keyboard hooked up to this machine when you're
>  > attempting to get serial console output?
> 
> Kind of.  It's connected to a local KVM switch.

Does the KVM switch provide power to a PS/2 port which isn't currently
selected?  (E.g. on an A/B/C/D KVM switch, if the FreeBSD box is wired
to port A, and the KVM switch has port C selected, does port A still get
power?)  Some KVMs do this, others do not.

>  > If so, I'm not too surprised it doesn't work (re: -P flag).
> 
> If -P is not supposed to activate the serial console, then
> the boot.config(5) manpage is in urgent need of a fix.
> Quote:
> 
>  >  The command:
>  >
>  >   # echo "-P" > /boot.config
>  >
>  >  will activate the serial console of FreeBSD.

That's a highly misleading description, and should probably be removed.
It's better to read boot(8).

-P does not activate serial console.  -P probes for a PS/2 keyboard.  If
one is attached, the system behaves like it would with a VGA console
attached.  Otherwise, if there is no PS/2 keyboard attached, it behaves
identically to the -D -h flags being set.

I do not know how -P internally works.  I imagine it speaks to the PIC
internal to the keyboard, or through a BIOS interrupt (0x10).  This is
why I asked what I did about the KVM switch above.

The -D and -h flags are somewhat confusing, so see the "table" in the
handbook for what does what (note the handbook which still references
sio(4) flags/bits, but those also apply to uart(4)):

http://www.freebsd.org/doc/handbook/serialconsole-setup.html

You'll find that FreeBSD does not offer a "true" dual console setup.
DragonflyBSD does offer this.

> Also, with that flag it has worked fine for ages, until
> I updated to 8.1-stable.  There must be a regression
> somewhere.

I don't know if the regression is with PS/2 keyboard probing or with the
introduction of uart(4) as the default serial port driver.  I'm CC'ing
ed@ since he's worked heavily on uart(4) and can assist here.

>  > Can you try the following?
>  > 
>  > 1) Removing kernel_options and console from loader.conf
>  > 2) Place "-P" in /boot.config instead
>  > 
>  > If this doesn't change the behaviour, please replace -P and with -D -h
>  > and see if there's any improvement.

> I already have tried all kinds of different combinations when I sat in
> front of the box yesterday.  I'm not sure if I have tried the exact
> combination that you suggest, though.  I also don't understand why
> those changes should improve anything.

Hopefully the reason why I'm asking you to try this makes more sense
with my above explanation of what -P actually does.

> BTW, the interesting thing is that all processes that try to access
> the console hang in "ttydcd".  I'm not familiar with the tty code ...
> Does anyone have an idea what this means?

I imagine it means the tty driver (thus uart(4)) is waiting for the DCD
line on the serial port to either go low or high (not sure which), but I
could be completely wrong.

One more thing to try: can you replace "std.9600" in your /etc/ttys
with "3wire.9600" and then do "init q" and see if things improve?  This
should remove carrier detection (DCD) from the mix.

If using 3wire.9600 works, can you provide a description of the wiring
of your serial console setup?  Specifically what DB9 pin is connected to
what on the remote end, and what the remote end actually is (Xyplex
unit, another PC, etc.)?

Thanks!

-- 
| 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: Policy for removing working code

[Oliver Fromme]

per...@pluto.rain.com wrote:
 > [...]
 > Beyond that, I suspect
 > that dropping an HBA or three would have been far less burdensome
 > on users of the hardware in question than dropping ISDN is on its
 > users.  One can always replace a no-longer-supported HBA with a
 > supported one, or (worst case) replace the whole box.  In contrast,
 > someone located beyond DSL range may have no other viable option
 > than ISDN.

It is a common misconception that ISDN is only used by
people who can't get DSL or other connectivity.  I can
only guess that ISDN is very uncommon in the USA, but
it isn't in other parts of the world.

In Germany (and possible other countries), ISDN is still
very popular.  I have ISDN at home (in addition to DSL
at 18 Mbps); it costs almost the same as a "normal"
telephone line while providing many useful features.

Many (most?) companies here do have ISDN, including the
one I work for.  We use FreeBSD's I4B stack to implement
an answering machine and fax services.  This is the reason
why we still have to run FreeBSD 6.x on one machine, but
when 6.x runs EOL we will have to make a decision (which
might end up putting a different OS on that machine,
depending on the choices at that time).

At home I used ISDN as a fall-back when the DSL line didn't
work for some reason.  I lost that feature about two years
ago when I updated beyond 6.x.  Fortunately DSL outages are
very rare at my provider, so the decision wasn't difficult
in this particular case.

Don't get me wrong -- I understand very well why the I4B
code had to be removed from FreeBSD.  It was an unfortunate,
but necessary decision.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when was the
last time you needed one?"
-- Tom Cargil, C++ Journal
___
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: Serial console problems with stable/8

[Stefan Bethke]

Am 12.09.2010 um 17:26 schrieb Oliver Fromme:

> I cannot even su(1) to root because it tries to print
> a message to the console, so it hangs, too.  For the same
> reason I can't use shutdown(8) either.  :-(
> 
> This is what a hanging su(1) command looks like in ps -alxww:
>  UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT   TIME COMMAND
>0  1533  1532   0  76  0  3392  3180 ttydcd I+ 00:00.05 su (zsh)
> 
> Interestingly, the KDB sequences CR ~ ^B/^P/^R/ do work,
> which use the "low-level" console.  So only the "high-level"
> console is frozen.

Looking at the WCHAN, I'd speculate that it's waiting for DCD to become active. 
Are you using a proper cable with handshaking, or a three-wire cable?

See what stty thinks the port is set to.  It probably has clocal set, but 
shouldn't. See if you can unwedge it by setting -clocal with stty, then pick a 
proper cable or gettytab entry.


Stefan

-- 
Stefan BethkeFon +49 151 14070811

___
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"

SOLVED: Re: VBox 3.2.8 & SATA virtual disks & FreeBSD 8.1-STABLE 20100912 -- (virtual) harddisks are not found on boot...

[Lev Serebryakov]

Hello, Freebsd-stable.
You wrote 13 сентября 2010 г., 00:14:31:

>   I have VirtualBox-based FreeBSD 8.1 installation (32 bit, VirtualBox
> 3.2.8, WinXP/x64 host, but I thinks that host config is irrelevant).
  Sorry  for  noise,  it  seems  to  be  VirtualBox  instability: I've
  re-createddisksconfiguration(with   exactly   the   same
  parameters!) and everything works now.

-- 
// Black Lion AKA Lev Serebryakov 

___
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: Serial console problems with stable/8

[David Evans]

 I can confirm there is much weirdness with the uart on 8-STABLE.

I'm using FBSD in several virtual machines on Parallels Desktop.

It is possible to set the serial port on the VM to output to a file on the host 
OS

I try something like   'cat file > /dev/cuad0  on FBSD 7 and 8. This works
on 7 but hangs after the first few kB on 8.

Next I try a login on the guest OS.  I set one VM to be a server and the other
a client. I connect the two VM's serial ports together via a socket on the
host OS. I also start a login on the server VM's serial port.

With both VMs running 7, I can login using kermit on the client. No amount
of trying gets flow control of any type to work, but at least it does not hang.
The lack of flow control means that much output is lost.

With both VMs running 8, I can login, just about, but attempting to edit
a file or do a long ls listing results in a hang. Flow control does not work
in either the RTS/CTS or XON/XOFF modes.

Next, I try kernel debugging using kgdb via serial link between two
VMs running 8. I'm surprised to find that it works quite well with
no hangs.  Presumably this is because the kgdb protocol only sends
small amounts of data at a time or perhaps it runs at a low level, as
mentioned earlier in this thread.  I have not tried this with 7.




___
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: Serial console problems with stable/8

[Stefan Bethke]

Am 13.09.2010 um 13:04 schrieb David Evans:

> I can confirm there is much weirdness with the uart on 8-STABLE.

OTOH, I have real hardware where things are working just fine:

$ grep uart /var/run/dmesg.boot 
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: [FILTER]
uart0: console (115200,n,8,1)
$ grep ttyu0 /etc/ttys 
ttyu0   "/usr/libexec/getty std.115200" vt100   on  secure

This is -stable from July 15th.  The other end of the serial line is an uftdi 
USB adapter:
uftdi0:  on usbus0


Stefan

-- 
Stefan BethkeFon +49 151 14070811

___
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: Serial console problems with stable/8

[Oliver Fromme]

Jeremy Chadwick wrote:
 > On Mon, Sep 13, 2010 at 09:21:21AM +0200, Oliver Fromme wrote:
 > > Jeremy Chadwick wrote:
 > > > Is there a PS/2 keyboard hooked up to this machine when you're
 > > > attempting to get serial console output?
 > > 
 > > Kind of.  It's connected to a local KVM switch.
 > 
 > Does the KVM switch provide power to a PS/2 port which isn't currently
 > selected?  (E.g. on an A/B/C/D KVM switch, if the FreeBSD box is wired
 > to port A, and the KVM switch has port C selected, does port A still get
 > power?)  Some KVMs do this, others do not.

Yes, it does.

Now I get your point ...  Yes, -P does probe the keyboard
first.  That's probably why I see the boot0/boot2 on the
VGA console, not on the serial port.  As far as I know,
/boot.config is read by the boot0/boot2 stage, not by
loader(8).

Anyway, I don't care too much for boot0/boot2; I've never
had to interact with them on that machine.  The important
thing for me is that loader(8) and the kernel use the
serial port for the console, and that I can login on it
(i.e. there must be a getty running).  All of that seemed
to be accomplished with the console="comconsole" entry in
/boot/loader.conf ...  At least it worked when I first
installed that machine in September 2000 (yeah, exactly 10
years ago) with FreeBSD 4.1, then updated it roughly every
two years ...  And it stopped working in 8.x.

I will try your suggestion of replacing -P with -Dh,
next time I'm at the site (probably Friday).  It's too
risky to try that remotely, given that I had to press
the hard reset button several times yesterday during my
attempts of getting the serial console to work as it
should.  Fortunately the machine has a small disk, so
fsck finishes in only two or three minutes ...

However, I fear that it won't improve things.  I don't see
how it could change the symptoms I'm seeing.  The serial
console _is_ activated (through the loader.conf entry),
but it just doesn't work correctly.

 > > the boot.config(5) manpage is in urgent need of a fix.
 > > Quote:
 > > 
 > > >  The command:
 > > > 
 > > >   # echo "-P" > /boot.config
 > > > 
 > > >  will activate the serial console of FreeBSD.
 > 
 > That's a highly misleading description, and should probably be removed.
 > It's better to read boot(8).

Agreed.

 > http://www.freebsd.org/doc/handbook/serialconsole-setup.html

I did have exactly the settings listed in section 26.6.2:
console="comconsole" in loader.conf and the getty turned
on in /etc/ttys.

And specifically, section 26.6.6.1 states:

  |  You can easily specify the boot loader and the kernel
  |  to use the serial console by writing just one line in
  |  /boot/loader.conf:
  |
  |  set console="comconsole"
  |  This will take effect regardless of the settings in the
  |  boot block discussed in the previous section.

So, it's pretty much irrelevant whether I have -P or -Dh or
anything else (or nothing at all) in /boot.config.

 > You'll find that FreeBSD does not offer a "true" dual console setup.
 > DragonflyBSD does offer this.

True.  I'm aware of that.  I don't need dual console.

 > > Also, with that flag it has worked fine for ages, until
 > > I updated to 8.1-stable.  There must be a regression
 > > somewhere.
 > 
 > I don't know if the regression is with PS/2 keyboard probing or with the
 > introduction of uart(4) as the default serial port driver.  I'm CC'ing
 > ed@ since he's worked heavily on uart(4) and can assist here.

I'm guessing it is uart's fault, but I haven't dug deeply
enough to be certain.

 > > BTW, the interesting thing is that all processes that try to access
 > > the console hang in "ttydcd".  I'm not familiar with the tty code ...
 > > Does anyone have an idea what this means?
 > 
 > I imagine it means the tty driver (thus uart(4)) is waiting for the DCD
 > line on the serial port to either go low or high (not sure which), but I
 > could be completely wrong.
 > 
 > One more thing to try: can you replace "std.9600" in your /etc/ttys
 > with "3wire.9600" and then do "init q" and see if things improve?  This
 > should remove carrier detection (DCD) from the mix.

That sounds like a very good suggestion!  Will try that.

 > If using 3wire.9600 works, can you provide a description of the wiring
 > of your serial console setup?  Specifically what DB9 pin is connected to
 > what on the remote end, and what the remote end actually is (Xyplex
 > unit, another PC, etc.)?

The remote end is another PC running FreeBSD (still 7.x).
I use tip(1) running inside a screen(1) session on that
remote PC to connect to my serial console.

The cable is a standard nullmodem cable, not selfmade.
It's a DB9-to-DB9 cable labelled "nullmodem", so I guess
it's correctly wired including carrier / handshake, i.e.
not just a 3-wire cable.  (And it did work fine from
FreeBSD 4.x to 7.x ...  sorry for repeating myself.)

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Mu

Re: AoE driver for FBSD8 or later?

[George Mamalakis]

 On 13/09/2010 08:41, Max Khon wrote:

George,

On Sat, Sep 11, 2010 at 12:12 AM, George Mamalakis 
mailto:mama...@eng.auth.gr>> wrote:


 On 10/09/2010 19:05, pluknet wrote:

On 10 September 2010 17:32, George
Mamalakismailto:mama...@eng.auth.gr>>
 wrote:

 Hi everybody,

we have a coraid device with 15x1GB disks on it, and would
like to use it
with fbsd8 (zfs, etc). The
http://support.coraid.com/support/freebsd/ is
really outdated, and the port that creates the kernel
module does not
compile on FBSD8 (obviously!). Is there any effort on
migrating the driver
onto fbsd8 or should I plug the coraid on a linux system
and use it from
there?

This change below looks obvious to me.
Not sure if this is enough to make it work though.
There are also might be issues with those interfaces which
announce
itself as IFT_ETHER, but have NULL if_input.

# cat files/patch-dev-aoe-aoenet.c
--- aoenet.c.orig   2006-05-25 16:10:11.0 +
+++ aoenet.c2010-09-10 15:03:01.0 +
@@ -77,8 +77,11 @@
 #define NECODES (sizeof(aoe_errlist) /  sizeof(char *) - 1)
 #if (__FreeBSD_version<  60)
 #define IFPADDR(ifp) (((struct arpcom *) (ifp))->ac_enaddr)
+#elif (__FreeBSD_version<  70)
+#define IFPADDR(ifp) IFP2ENADDR(ifp)
 #else
-#define IFPADDR(ifp) IFP2ENADDR(ifp)
+#include
+#define IFPADDR(ifp) IF_LLADDR(ifp)
 #endif
 #define IFLISTSZ 1024

@@ -223,7 +226,11 @@

m1->m_ext.ref_cnt = NULL;
MEXTADD(m1, f->f_data, len, nilfn,
+#if (__FreeBSD_version<  80)
NULL, 0, EXT_NET_DRV);
+#else
+   f->f_data, NULL, 0, EXT_NET_DRV);
+#endif
m1->m_len = len;
m1->m_next = NULL;
 }



Hi, and thanx for your quick reply.

I patched my workdir on /usr/ports/net/aoe/work/dev/aoe but got
the following output, which probably suggests that we may be
talking about a different version you and me:


[root]# patch -p0 < patch-dev-aoe-aoenet.c
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--

|--- aoenet.c.orig   2006-05-25 16:10:11.0 +
|+++ aoenet.c2010-09-10 15:03:01.0 +
--
Patching file aoenet.c using Plan A...
Hunk #1 failed at 77.
Hunk #2 failed at 226.
2 out of 2 hunks failed--saving rejects to aoenet.c.rej
Hmm...  Ignoring the trailing garbage.
done


After cd'ing into /usr/ports/net/aoe and giving make I got:

[root]# make
===>  Configuring for aoe-1.2.0_1
===>  Building for aoe-1.2.0_1
.
.
aoenet.c:226:24: error: macro "MEXTADD" requires 8 arguments, but
only 7 given
aoenet.c: In function 'frame_mbufinit':
aoenet.c:225: error: 'MEXTADD' undeclared (first use in this function)
aoenet.c:225: error: (Each undeclared identifier is reported only once
aoenet.c:225: error: for each function it appears in.)
cc1: warnings being treated as errors
aoenet.c: In function 'aoenet_xmitbcast':
aoenet.c:278: warning: implicit declaration of function 'IFP2ENADDR'
aoenet.c:278: warning: nested extern declaration of 'IFP2ENADDR'
aoenet.c:278: warning: passing argument 2 of 'memcpy' makes
pointer from integer without a cast
aoenet.c: In function 'aoenet_enaddr':
aoenet.c:294: warning: return makes pointer from integer without a
cast
*** Error code 1

Stop in /usr/ports/net/aoe/work/dev/aoe.
*** Error code 1

Stop in /usr/ports/net/aoe.


Which was pretty obvious, since not much had been patched...

I didn't include the whole output; the missing part is correct
compilation parts.

Thanx again for your help, and if you could point me into the
right source code (or port, whatsoever), I could try your patch
and see whether the driver would be built.


You need to put that patch to ports/net/aoe/files. You can try to use 
this version of the port (unpack it to /usr/ports/net):
http://people.freebsd.org/~fjoe/aoe.tar.gz 



Max

Your patch worked fine, the driver compiled seamlessly, but I am unable 
to see more than 2T on my coraid device, even though it's size is 13T. I 
don't know whether this is a driver issue or fbsd issue.

uname -a on my machine:
[r...@~]# uname -a
FreeBSD lala 8.1-STABLE FreeBSD 8.1-STABLE #0: Tue Aug 31 13:54:36 EEST 
2010 r...@lala:/usr/obj/usr/src/sys/CUSTOM  i386


Thanx again for your help, and since the driver seems to be working,

[releng_8_0 tinderbox] failure on ia64/ia64

[FreeBSD Tinderbox]

TB --- 2010-09-13 12:31:52 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-13 12:31:52 - starting RELENG_8_0 tinderbox run for ia64/ia64
TB --- 2010-09-13 12:31:52 - cleaning the object tree
TB --- 2010-09-13 12:32:38 - cvsupping the source tree
TB --- 2010-09-13 12:32:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/RELENG_8_0/ia64/ia64/supfile
TB --- 2010-09-13 13:11:08 - WARNING: /usr/bin/csup returned exit code  1 
TB --- 2010-09-13 13:11:08 - ERROR: unable to cvsup the source tree
TB --- 2010-09-13 13:11:08 - 1.05 user 33.34 system 2355.49 real


http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-ia64-ia64.full
___
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: MSIX failure

[Gareth de Vaux]

On Fri 2010-09-10 (10:43), Jack Vogel wrote:
> No, not the add-on adapter, i have no trouble finding those,  what I want to
> know about is the details about the system that has em0 LOM, only
> way to check on that is to have the whole enchilada :)

Ah right. These are snippets from dmidecode, is this enough?

Handle 0x, DMI type 4, 35 bytes 
Processor Information
Socket Designation: LGA 1156
Type: Central Processor
Family: Other
Manufacturer: Intel(R) Corporation 
ID: E5 06 01 00 FF FB EB BF
Version: Intel(R) Core(TM) i5 CPU 750  @ 2.67GHz
Voltage: 1.1 V
External Clock: 133 MHz
Max Speed: 4000 MHz
Current Speed: 2668 MHz   
Status: Populated, Enabled
Upgrade: Other
L1 Cache Handle: 0x0004
L2 Cache Handle: 0x0003
L3 Cache Handle: 0x0001
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified

Handle 0x0007, DMI type 2, 20 bytes
Base Board Information
Manufacturer: Intel Corporation
Product Name: DP55WB   
Version: AAE64798-206  
Serial Number: AZWB005003A3
Asset Tag: Base Board Asset Tag
Features:
Board is a hosting board 
Board is replaceable
Location In Chassis: Base Board Chassis Location
Chassis Handle: 0x0008
Type: Unknown 
Contained Object Handles: 0 

Handle 0x0010, DMI type 10, 6 bytes
On Board Device Information
Type: Ethernet
Status: Enabled
Description: Intel(R) 82578DC Gigabit Network Connection
___
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"

[releng_8_1 tinderbox] failure on arm/arm

[FreeBSD Tinderbox]

TB --- 2010-09-13 14:21:57 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-13 14:21:57 - starting RELENG_8_1 tinderbox run for arm/arm
TB --- 2010-09-13 14:21:57 - cleaning the object tree
TB --- 2010-09-13 14:22:19 - cvsupping the source tree
TB --- 2010-09-13 14:22:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/RELENG_8_1/arm/arm/supfile
TB --- 2010-09-13 15:01:07 - WARNING: /usr/bin/csup returned exit code  1 
TB --- 2010-09-13 15:01:07 - ERROR: unable to cvsup the source tree
TB --- 2010-09-13 15:01:07 - 0.73 user 18.38 system 2349.92 real


http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-arm-arm.full
___
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: Why is NFSv4 so slow?

[Oliver Fromme]

Rick Macklem wrote:
 > Btw, if anyone who didn't see the posting on freebsd-fs and would
 > like to run a quick test, it would be appreciated.
 > Bascially do both kinds of mount using a FreeBSD8.1 or later client
 > and then read a greater than 100Mbyte file with dd.
 > 
 > # mount -t nfs -o nfsv3 :/path /
 > - cd anywhere in mount that has > 100Mbyte file
 > # dd if= of=/dev/null bs=1m
 > # umount /
 > 
 > Then repeat with
 > # mount -t newnfs -o nfsv3 :/path /
 > 
 > and post the results along with the client machine's info
 > (machine arch/# of cores/memory/net interface used for NFS traffic).
 > 
 > Thanks in advance to anyone who runs the test, rick

Ok ...

NFS server:
 - FreeBSD 8.1-PRERELEASE-20100620 i386
 - intel Atom 330 (1.6 GHz dual-core with HT --> 4-way SMP)
 - 4 GB RAM
 - re0: 

NFS client:
 - FreeBSD 8.1-STABLE-20100908 i386
 - AMD Phenom II X6 1055T (2.8 GHz + "Turbo Core", six-core)
 - 4 GB RAM
 - re0: 

The machines are connected through a Netgear GS108T
gigabit ethernet switch.

I umounted and re-mounted the NFS path after every single
dd(1) command, so the data actually comes from the server
instead of from the local cache.  I also made sure that
the file was in the cache on the server, so the server's
disk speed is irrelevant.

Testing with "mount -t nfs":

183649990 bytes transferred in 2.596677 secs (70725002 bytes/sec)
183649990 bytes transferred in 2.578746 secs (71216779 bytes/sec)
183649990 bytes transferred in 2.561857 secs (71686277 bytes/sec)
183649990 bytes transferred in 2.629028 secs (69854708 bytes/sec)
183649990 bytes transferred in 2.535422 secs (72433702 bytes/sec)

Testing with "mount -t newnfs":

183649990 bytes transferred in 5.361544 secs (34253192 bytes/sec)
183649990 bytes transferred in 5.401471 secs (3396 bytes/sec)
183649990 bytes transferred in 5.052138 secs (36350946 bytes/sec)
183649990 bytes transferred in 5.311821 secs (34573829 bytes/sec)
183649990 bytes transferred in 5.537337 secs (33165760 bytes/sec)

So, nfs is roughly twice as fast as newnfs, indeed.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"A language that doesn't have everything is actually easier
to program in than some that do."
-- Dennis M. Ritchie
___
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: Serial console problems with stable/8

[John Baldwin]

On Monday, September 13, 2010 8:49:48 am Oliver Fromme wrote:
> Jeremy Chadwick wrote:
>  > On Mon, Sep 13, 2010 at 09:21:21AM +0200, Oliver Fromme wrote:
>  > > Jeremy Chadwick wrote:
>  > > > Is there a PS/2 keyboard hooked up to this machine when you're
>  > > > attempting to get serial console output?
>  > > 
>  > > Kind of.  It's connected to a local KVM switch.
>  > 
>  > Does the KVM switch provide power to a PS/2 port which isn't currently
>  > selected?  (E.g. on an A/B/C/D KVM switch, if the FreeBSD box is wired
>  > to port A, and the KVM switch has port C selected, does port A still get
>  > power?)  Some KVMs do this, others do not.
> 
> Yes, it does.
> 
> Now I get your point ...  Yes, -P does probe the keyboard
> first.  That's probably why I see the boot0/boot2 on the
> VGA console, not on the serial port.  As far as I know,
> /boot.config is read by the boot0/boot2 stage, not by
> loader(8).

But loader inherits the settings from boot2, so if you set it in /boot.config 
you do not need to set anything in loader.conf.  Also, having boot2 use serial 
is good in that you can boot loader.old if you ever get a broken /boot/loader.  
Using '-Dh' in /boot.config is what I do on all the boxes where I use a serial 
console.

> Anyway, I don't care too much for boot0/boot2; I've never
> had to interact with them on that machine.  The important
> thing for me is that loader(8) and the kernel use the
> serial port for the console, and that I can login on it
> (i.e. there must be a getty running).  All of that seemed
> to be accomplished with the console="comconsole" entry in
> /boot/loader.conf ...  At least it worked when I first
> installed that machine in September 2000 (yeah, exactly 10
> years ago) with FreeBSD 4.1, then updated it roughly every
> two years ...  And it stopped working in 8.x.

Did you update your hints to rename the 'sio' hints to 'uart'?

-- 
John Baldwin
___
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: Why is NFSv4 so slow?

[Rick Macklem]

> 
> Ok ...
> 
> NFS server:
> - FreeBSD 8.1-PRERELEASE-20100620 i386
> - intel Atom 330 (1.6 GHz dual-core with HT --> 4-way SMP)
> - 4 GB RAM
> - re0: 
> 
> NFS client:
> - FreeBSD 8.1-STABLE-20100908 i386
> - AMD Phenom II X6 1055T (2.8 GHz + "Turbo Core", six-core)
> - 4 GB RAM
> - re0: 
> 
> The machines are connected through a Netgear GS108T
> gigabit ethernet switch.
> 
> I umounted and re-mounted the NFS path after every single
> dd(1) command, so the data actually comes from the server
> instead of from the local cache. I also made sure that
> the file was in the cache on the server, so the server's
> disk speed is irrelevant.
> 
> Testing with "mount -t nfs":
> 
> 183649990 bytes transferred in 2.596677 secs (70725002 bytes/sec)
> 183649990 bytes transferred in 2.578746 secs (71216779 bytes/sec)
> 183649990 bytes transferred in 2.561857 secs (71686277 bytes/sec)
> 183649990 bytes transferred in 2.629028 secs (69854708 bytes/sec)
> 183649990 bytes transferred in 2.535422 secs (72433702 bytes/sec)
> 
> Testing with "mount -t newnfs":
> 
> 183649990 bytes transferred in 5.361544 secs (34253192 bytes/sec)
> 183649990 bytes transferred in 5.401471 secs (3396 bytes/sec)
> 183649990 bytes transferred in 5.052138 secs (36350946 bytes/sec)
> 183649990 bytes transferred in 5.311821 secs (34573829 bytes/sec)
> 183649990 bytes transferred in 5.537337 secs (33165760 bytes/sec)
> 
> So, nfs is roughly twice as fast as newnfs, indeed.
> 
> Best regards
> Oliver
> 
Thanks for doing the test. I think I can find out what causes the
factor of 2 someday. What is really weird is that some people see
several orders of magnitude slower (a few Mbytes/sec).

Your case was also useful, because you are using the same net
interface/driver as the original report of a few Mbytes/sec, so it
doesn't appear to be an re problem.

Have a good week, rick

___
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: Why is NFSv4 so slow?

[Rick C. Petty]

On Mon, Sep 13, 2010 at 11:15:34AM -0400, Rick Macklem wrote:
> > 
> > instead of from the local cache. I also made sure that
> > the file was in the cache on the server, so the server's
> > disk speed is irrelevant.
> > 



> > So, nfs is roughly twice as fast as newnfs, indeed.

Hmm, I have the same network switch as Oliver, and I wasn't caching the
file on the server before.  When I cache the file on the server, I get
about 1 MiB/s faster throughput, so that doesn't seem to make the
difference to me (but with higher throughputs, I would imagine it would).

> Thanks for doing the test. I think I can find out what causes the
> factor of 2 someday. What is really weird is that some people see
> several orders of magnitude slower (a few Mbytes/sec).
> 
> Your case was also useful, because you are using the same net
> interface/driver as the original report of a few Mbytes/sec, so it
> doesn't appear to be an re problem.

I believe I said something to that effect.  :-P

The problem I have is that the magnitude of throughput varies randomly.
Sometimes I can repeat the test and see 3-4 MB/s.  Then my server's
motherboard failed last week so I swapped things around and now I have 9-10
MB/s on the same client (but using 100Mbit interface instead of gigabit, so
those speeds make sense).

One thing I noticed is the lag seems to have disappeared after the reboots.
Another thing I had to change was that I was using an NFSv3 mount for /home
(with the v3 client, not the experimental v3/v4 client) and now I'm using
NFSv4 mounts exclusively.  Too much hardware changed because of that board
failing (AHCI was randomly dropping disks, and it got to the point that it
wouldn't pick up drives after a cold start and then the board failed to
POST 11 of 12 times), so I haven't been able to reliably reproduce any
problems.  I also had to reboot the "bad" client because of the broken
NFSv3 mountpoints, and the server was auto-upgraded to a newer 8.1-stable
(I often run "make buildworld kernel" regularly, so any reboots will
automatically have a newer kernel).

There's definite evidence that the newnfs mounts are slower than plain nfs,
and sometimes orders of magnitude slower (as others have shown).  But the
old nfs is so broken in other ways that I'd prefer slower yet more stable.
Thanks again for all your help, Rick!

-- Rick C. Petty
___
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: Serial console problems with stable/8

[Oliver Fromme]

John Baldwin wrote:
 > On Monday, September 13, 2010 8:49:48 am Oliver Fromme wrote:
 > > Now I get your point ...  Yes, -P does probe the keyboard
 > > first.  That's probably why I see the boot0/boot2 on the
 > > VGA console, not on the serial port.  As far as I know,
 > > /boot.config is read by the boot0/boot2 stage, not by
 > > loader(8).
 > 
 > But loader inherits the settings from boot2, so if you set it in
 > /boot.config you do not need to set anything in loader.conf.  Also,
 > having boot2 use serial is good in that you can boot loader.old if
 > you ever get a broken /boot/loader.  Using '-Dh' in /boot.config is
 > what I do on all the boxes where I use a serial console.

Makes sense.  I'll change -P to -Dh.

But having console="comconsole" in loader.conf should also
enable the serial console, except that it happens a little
later (in loader instead of boot2), right?

I think the boot.config stuff might be a red herring.
The console breaks (i.e. freezes) as soon as I try to run
a getty process on it -- That seems to indicate that getty
does *something* to the console device which causes the
problem.  The wchan "ttydcd" seems to indicate is has
something to do with carrier detection or flow control.
This points to the uart driver as the culprit which
replaced sio.

 > > Anyway, I don't care too much for boot0/boot2; I've never
 > > had to interact with them on that machine.  The important
 > > thing for me is that loader(8) and the kernel use the
 > > serial port for the console, and that I can login on it
 > > (i.e. there must be a getty running).  All of that seemed
 > > to be accomplished with the console="comconsole" entry in
 > > /boot/loader.conf ...  At least it worked when I first
 > > installed that machine in September 2000 (yeah, exactly 10
 > > years ago) with FreeBSD 4.1, then updated it roughly every
 > > two years ...  And it stopped working in 8.x.
 > 
 > Did you update your hints to rename the 'sio' hints to 'uart'?

Yes, mergemaster did that for me.  I double-checked it.

hint.uart.0.at="isa"
hint.uart.0.port="0x3F8"
hint.uart.0.flags="0x10"
hint.uart.0.irq="4"

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"C is quirky, flawed, and an enormous success."
-- Dennis M. Ritchie.
___
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: Serial console problems with stable/8

[John Baldwin]

On Monday, September 13, 2010 11:55:27 am Oliver Fromme wrote:
> John Baldwin wrote:
>  > On Monday, September 13, 2010 8:49:48 am Oliver Fromme wrote:
>  > > Now I get your point ...  Yes, -P does probe the keyboard
>  > > first.  That's probably why I see the boot0/boot2 on the
>  > > VGA console, not on the serial port.  As far as I know,
>  > > /boot.config is read by the boot0/boot2 stage, not by
>  > > loader(8).
>  > 
>  > But loader inherits the settings from boot2, so if you set it in
>  > /boot.config you do not need to set anything in loader.conf.  Also,
>  > having boot2 use serial is good in that you can boot loader.old if
>  > you ever get a broken /boot/loader.  Using '-Dh' in /boot.config is
>  > what I do on all the boxes where I use a serial console.
> 
> Makes sense.  I'll change -P to -Dh.
> 
> But having console="comconsole" in loader.conf should also
> enable the serial console, except that it happens a little
> later (in loader instead of boot2), right?

Correct.

> I think the boot.config stuff might be a red herring.
> The console breaks (i.e. freezes) as soon as I try to run
> a getty process on it -- That seems to indicate that getty
> does *something* to the console device which causes the
> problem.  The wchan "ttydcd" seems to indicate is has
> something to do with carrier detection or flow control.
> This points to the uart driver as the culprit which
> replaced sio.

Well, /dev/ttyXX have always waited for carrier detect, whereas /dev/cuaXX 
(the call-out devices) have not.  That was so that you could hook a modem up 
to a serial port and getty would not return from open(2) and print a login 
banner until someone dialed the modem and connected.  I think Jeremy has 
already given you some good things to try (such as 3wire.9600) to debug this 
instead.

>  > > Anyway, I don't care too much for boot0/boot2; I've never
>  > > had to interact with them on that machine.  The important
>  > > thing for me is that loader(8) and the kernel use the
>  > > serial port for the console, and that I can login on it
>  > > (i.e. there must be a getty running).  All of that seemed
>  > > to be accomplished with the console="comconsole" entry in
>  > > /boot/loader.conf ...  At least it worked when I first
>  > > installed that machine in September 2000 (yeah, exactly 10
>  > > years ago) with FreeBSD 4.1, then updated it roughly every
>  > > two years ...  And it stopped working in 8.x.
>  > 
>  > Did you update your hints to rename the 'sio' hints to 'uart'?
> 
> Yes, mergemaster did that for me.  I double-checked it.
> 
> hint.uart.0.at="isa"
> hint.uart.0.port="0x3F8"
> hint.uart.0.flags="0x10"
> hint.uart.0.irq="4"

Ok.  I know that for machines I have at work that run 7, if I boot a 8.x
kernel have to explicitly unset the sio hints and set the uart hints for
the serial console to work in 8.

-- 
John Baldwin
___
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: Why is NFSv4 so slow?

[Goran Lowkrantz]

--On September 12, 2010 11:44:40 -0400 Rick Macklem  
wrote:

On Wed, Sep 01, 2010 at 11:46:30AM -0400, Rick Macklem wrote:



My results seems to confirm a factor of two (or 1.5) but it's stable:
new nfs nfsv4
369792 bytes transferred in 71.932692 secs (55607119 bytes/sec)
369792 bytes transferred in 66.806218 secs (59874214 bytes/sec)
369792 bytes transferred in 65.127972 secs (61417079 bytes/sec)
369792 bytes transferred in 64.493585 secs (62021204 bytes/sec)

old nfs nfsv3
369792 bytes transferred in 42.290365 secs (94583478 bytes/sec)
369792 bytes transferred in 42.135682 secs (94930700 bytes/sec)
369792 bytes transferred in 41.404841 secs (96606332 bytes/sec)
369792 bytes transferred in 41.461210 secs (96474989 bytes/sec)

new nfs nfsv3
369792 bytes transferred in 63.172592 secs (63318121 bytes/sec)
369792 bytes transferred in 64.149324 secs (62354044 bytes/sec)
369792 bytes transferred in 62.447537 secs (64053284 bytes/sec)
369792 bytes transferred in 57.203868 secs (69924813 bytes/sec)

Client:
FreeBSD 8.1-STABLE #200: Sun Sep 12 12:03:25 CEST 2010
   r...@skade.glz.hidden-powers.com:/usr/obj/usr/src/sys/GENERIC amd64
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (2600.26-MHz K8-class 
CPU)
 Origin = "AuthenticAMD"  Id = 0x60fb2  Family = f  Model = 6b  Stepping = 
2


em0: flags=8843 metric 0 mtu 1500
options=19b
ether 00:1b:21:2e:7d:3c
inet 10.255.253.3 netmask 0xff00 broadcast 10.255.253.255
media: Ethernet autoselect (1000baseT )
status: active

Server:
FreeBSD 8.1-STABLE #74: Sun Sep  5 18:47:12 CEST 2010
   r...@midgard.glz.hidden-powers.com:/usr/obj/usr/src/sys/SERVER amd64
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Phenom(tm) 9550 Quad-Core Processor (2210.08-MHz K8-class CPU)
 Origin = "AuthenticAMD"  Id = 0x100f23  Family = 10  Model = 2  Stepping 
= 3


re0: flags=8943 metric 0 
mtu 1500


options=3898
ether 00:1f:d0:59:d8:e2
inet 10.255.253.1 netmask 0xff00 broadcast 10.255.253.255
media: Ethernet autoselect (1000baseT )
status: active

Network:
Systems connected via two Netgear GS108T, one system to each switch, the 
switches connected via TP cable.


Patchar:
stable-8-v15.patch
zfs_metaslab_v2.patch
zfs_abe_stat_rrwlock.patch
arc.c.9.patch
r211970.patch

Cheers,
Göran

---
"There is hopeful symbolism in the fact that flags do not wave in a vacuum."
   -- Arthur C. Clarke
___
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: Serial console problems with stable/8

[Oliver Fromme]

John Baldwin wrote:
 > On Monday, September 13, 2010 11:55:27 am Oliver Fromme wrote:
 > > I think the boot.config stuff might be a red herring.
 > > The console breaks (i.e. freezes) as soon as I try to run
 > > a getty process on it -- That seems to indicate that getty
 > > does *something* to the console device which causes the
 > > problem.  The wchan "ttydcd" seems to indicate is has
 > > something to do with carrier detection or flow control.
 > > This points to the uart driver as the culprit which
 > > replaced sio.
 > 
 > Well, /dev/ttyXX have always waited for carrier detect, whereas
 > /dev/cuaXX (the call-out devices) have not.

Well, before the update I had ttyd0 in /etc/ttys (this is
the default in FreeBSD 7.x), so it should have waited for
carrier detect, too.

 > That was so that you could hook a modem up to a serial port and getty
 > would not return from open(2) and print a login banner until someone
 > dialed the modem and connected.  I think Jeremy has already given you
 > some good things to try (such as 3wire.9600) to debug this instead.

Yes, I will try that ...  But with the 3wire entry I won't
have any flow control at all, so output can be lost, right?
Doesn't sound like a good solution.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Documentation is like sex; when it's good, it's very, very good,
and when it's bad, it's better than nothing."
-- Dick Brandon
___
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: Serial console problems with stable/8

[Jeremy Chadwick]

On Mon, Sep 13, 2010 at 06:59:58PM +0200, Oliver Fromme wrote:
> 
> John Baldwin wrote:
>  > On Monday, September 13, 2010 11:55:27 am Oliver Fromme wrote:
>  > > I think the boot.config stuff might be a red herring.
>  > > The console breaks (i.e. freezes) as soon as I try to run
>  > > a getty process on it -- That seems to indicate that getty
>  > > does *something* to the console device which causes the
>  > > problem.  The wchan "ttydcd" seems to indicate is has
>  > > something to do with carrier detection or flow control.
>  > > This points to the uart driver as the culprit which
>  > > replaced sio.
>  > 
>  > Well, /dev/ttyXX have always waited for carrier detect, whereas
>  > /dev/cuaXX (the call-out devices) have not.
> 
> Well, before the update I had ttyd0 in /etc/ttys (this is
> the default in FreeBSD 7.x), so it should have waited for
> carrier detect, too.

Re-adding ed@ to the CC list.  I hope he can shed some light on this.

I believe FreeBSD expects DCD to be raised on both sio(4) and uart(4)
when /dev/ttyuX devices are used -- however, see item 3 below.  We've
upgraded numerous servers of ours from RELENG_6 and RELENG_7, to
RELENG_8, with no serial console issues (we still have some RELENG_6 and
RELENG_7 boxes in use as well, using sio(4), so we can provide details
from those too if need be).  Our cabling/hardware differs from yours
though.

>  > That was so that you could hook a modem up to a serial port and getty
>  > would not return from open(2) and print a login banner until someone
>  > dialed the modem and connected.  I think Jeremy has already given you
>  > some good things to try (such as 3wire.9600) to debug this instead.
> 
> Yes, I will try that ...  But with the 3wire entry I won't
> have any flow control at all, so output can be lost, right?
> Doesn't sound like a good solution.

1) gettytab(5) mentions the "mb" capability, which tells it to do flow
control based on DCD, I believe.  This defaults to off, and isn't
defined for the std.XXX nor 3wire.XXX entries.

2) However, I imagine some null modem adapters or cables might wire RTS
and CTS to DCD.  Check out Table 26-2 for DB9 to DB9 null modem cable
wiring, and be sure to check out the paragraph *after* "Note:" in Table
26-3.

http://www.freebsd.org/doc/handbook/serial.html#SERIAL-CABLES-PORTS

3) But here's the fun part!  The adapters I use in our co-location (DB9
serial ports on PCs wired to a MRV unit), pin 1 (DCD) on the DB9 serial
port *is not* wired -- it literally hangs loose.  The adapters use
hardware flow control (CTS/RTS), and all equipment is configured to use
it as well.  We use the following line in /etc/ttys reliably (without
any character loss[1]):

ttyu0   "/usr/libexec/getty std.115200" xterm   on  secure

The exact pinout is below:

 RJ45  DB9
   Female  Female
  ===  ===
  (CTS) 1  <>  7 (RTS)
  (DTR) 2  <>  6 (DSR)
  (TxD) 3  <>  2 (RxD)
  (TxD GND) 4  <>  5 (GND)
  (RxD GND) 5  <>  5 (GND)
  (RxD) 6  <>  3 (TxD)
  (DSR/DCD) 7  <>  4 (DTR)
  (RTS) 8  <>  8 (CTS)

I can provide stty -a -f /dev/ttyuX output on one of these machines if
folks would find it useful as a comparison model to what Oliver's
seeing.

Is it possible the null modem adapter, cables, or jacks been slightly
jostled or anything like that?  Hrm, actually I guess that's pointless
to ask since you can restore proper behaviour rolling back to RELENG_7.


[1]: Prior to logging in, there is no flow control -- this happens on
sio(4) as well as uart(4).  This problem dates back to at least the
FreeBSD 4.x days and is easily detectable by hitting enter repetitively
at the "login:" prompt on a serial console; occasionally the output will
get messed up.  Once you log in, however, flow control works fine.  When
I chatted with Marcel Moolenaar about this, he assured me this is
expected.  This isn't the problem you're seeing, but I thought I'd
mention it in passing anyway.

-- 
| 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"

Freebsd 8.1 + xorg + radeonhd hang

[Eivind E]

Hello, I'm hoping somebody can shed some light on this.

One of my machines has a Radeon X1550 graphics card. When first
installed (then as either 7.1 or 7.1 prerelease), the radeonhd driver
hung the machine hard, screen went blank, numlock and capslock
didn't work, no network (so no ssh) and I couldn't do much but
hard reset the machine. I had to use vesa for a while, then, after
upgrading, the radeonhd driver worked up until fairly recent upgrades.
Sadly I didn't try the driver very often so I don't know if upgrading
src or xorg+drivers helped the problem.

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.

This time, also the vesa driver gives problems, it seemingly works
good, until it messes up colours, usually after using mplayer.

Any pointers as to how to solve this? Details below.


I'm running FreeBSD 8.1 :

FreeBSD elg.hjerdalen.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Mon Sep 13 17:48:23
CEST 2010 r...@elg.hjerdalen.lan:/usr/obj/usr/src/sys/GENERIC  amd64

Graphics card :

vgap...@pci0:3:0:0: class=0x03 card=0x204e17af chip=0x71431002 rev=0x00$
vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
device = 'ATI RADEON X1550 Series (RV515)'
class  = display
subclass   = VGA
vgap...@pci0:3:0:1: class=0x038000 card=0x204f17af chip=0x71631002 rev=0x00$
vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
device = 'ATI RADEON X1550 Series Secondary (RV515)'
class  = display

Dmesg :

Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.1-STABLE #0: Mon Sep 13 17:48:23 CEST 2010
r...@elg.hjerdalen.lan:/usr/obj/usr/src/sys/GENERIC amd64
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 Duo CPU E6850  @ 3.00GHz (3005.68-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x6fb  Family = 6  Model = f  Stepping = 11
  
Features=0xbfebfbff
  Features2=0xe3fd
  AMD Features=0x2800
  AMD Features2=0x1
  TSC: P-state invariant
real memory  = 4294967296 (4096 MB)
avail memory = 4106117120 (3915 MB)
ACPI APIC Table: <090407 APIC1631>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0  irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: <090407 RSDT1631> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, cff0 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
cpu0:  on acpi0
ACPI Warning: Incorrect checksum in table [OEMB] - 0x84, should be 0x7B 
(20100331/tbutils-354)
cpu1:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  irq 16 at device 1.0 on pci0
pci1:  on pcib1
uhci0:  port 0xac00-0xac1f irq 16 at device 
26.0 on pci0
uhci0: [ITHREAD]
uhci0: LegSup = 0x2f00
usbus0:  on uhci0
uhci1:  port 0xa880-0xa89f irq 21 at device 
26.1 on pci0
uhci1: [ITHREAD]
uhci1: LegSup = 0x2f00
usbus1:  on uhci1
ehci0:  mem 0xfe7ffc00-0xfe7f irq 
18 at device 26.7 on pci0
ehci0: [ITHREAD]
usbus2: EHCI version 1.0
usbus2:  on ehci0
hdac0:  mem 
0xfe7f8000-0xfe7fbfff irq 22 at device 27.0 on pci0
hdac0: HDA Driver Revision: 20100226_0142
hdac0: [ITHREAD]
pcib2:  irq 17 at device 28.0 on pci0
pci2:  on pcib2
pcib3:  irq 18 at device 28.2 on pci0
pci3:  on pcib3
vgapci0:  port 0xb000-0xb0ff mem 
0xd000-0xdfff,0xfe8f-0xfe8f irq 18 at device 0.0 on pci3
vgapci1:  mem 0xfe8e-0xfe8e at device 0.1 on 
pci3
pcib4:  irq 17 at device 28.4 on pci0
pci4:  on pcib4
atapci0:  port 
0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc807,0xc480-0xc483,0xc400-0xc40f mem 
0xfe9ffc00-0xfe9f irq 16 at device 0.0 on pci4
atapci0: [ITHREAD]
atapci1:  on atapci0
atapci1: [ITHREAD]
atapci1: AHCI v1.00 controller with 3 3Gbps ports, PM supported
ata2:  on atapci1
ata2: [ITHREAD]
ata3:  on atapci1
ata3: [ITHREAD]
ata4:  on atapci0
ata4: [ITHREAD]
pcib5:  irq 16 at device 28.5 on pci0
pci5:  on pcib5
re0:  port 0xd800-0xd8ff 
mem 0xfeaff000-0xfeaf irq 17 at device 0.0 on pci5
re0: Using 1 MSI messages
re0: Chip rev. 0x3800
re0: MAC rev. 0x
miibus0:  on re0
rgephy0:  PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
re0: Ethernet address: 00:19:db:f3:30:3c
re0: [FILTER]
uhci2:  port 0xa800-0xa81f irq 23 at device 
29.0 on pci0
uhci2: [ITHREAD]
uhci2: LegSup = 0x2f00
usbus3:  on uhci2
uhci3:  port 0xa480-0xa49f irq 19 at device 
29.1 on pci0
uhci3: [ITHREAD]
uhci3: LegSup = 0x2f00
usbus4:  on uhci3
uhci4:  port 0xa400-0xa41f irq 18 at device

Re: Serial console problems with stable/8

[Ed Schouten]

Just replying to a random message in this thread.

Maybe we should just implement /dev/console in such a way that it can
never get stuck on dcd. I've seen this break too many times.

Below is an untested patch. Anyone willing to test it for me?

As Jeremy did point out, FreeBSD's TTY/serial/etc code really lacks a
true console device which multiplexes both input and output to all
serial devices.

%%%
Index: tty.c
===
--- tty.c   (revision 212549)
+++ tty.c   (working copy)
@@ -282,7 +282,8 @@
 
/* Wait for Carrier Detect. */
if (!TTY_CALLOUT(tp, dev) && (oflags & O_NONBLOCK) == 0 &&
-   (tp->t_termios.c_cflag & CLOCAL) == 0) {
+   (tp->t_termios.c_cflag & CLOCAL) == 0 &&
+   dev != dev_console) {
while ((ttydevsw_modem(tp, 0, 0) & SER_DCD) == 0) {
error = tty_wait(tp, &tp->t_dcdwait);
if (error != 0)
%%%

-- 
 Ed Schouten 
 WWW: http://80386.nl/


pgp5bVOCevFGN.pgp
Description: PGP signature

Re: Serial console problems with stable/8

[Oliver Fromme]

Ed Schouten wrote:
 > Just replying to a random message in this thread.
 > 
 > Maybe we should just implement /dev/console in such a way that it can
 > never get stuck on dcd. I've seen this break too many times.
 > 
 > Below is an untested patch. Anyone willing to test it for me?

Thank you!  I will gladly test it on Friday.  I'm sorry
I can't test it earlier, but I'm reluctant to test things
like this remotely.

@ Jeremy:  Thank you for the detailed response!  I will
make sure to bring a multimeter with me and check the
pin connections on my nullmodem cable.  I'm still curious
why this cable worked with 7.x with the same configuration.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"The scanf() function is a large and complex beast that often does
something almost but not quite entirely unlike what you desired."
-- Chris Torek
___
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: Serial console problems with stable/8

[Ed Schouten]

* Oliver Fromme  wrote:
> @ Jeremy:  Thank you for the detailed response!  I will
> make sure to bring a multimeter with me and check the
> pin connections on my nullmodem cable.  I'm still curious
> why this cable worked with 7.x with the same configuration.

I seem to remember some of the drivers enforced CLOCAL when the device
is used as a boot device. Maybe sio(4) does this, while uart(4) does
not? An advantage of the patch is that it makes this construct
superfluous.

-- 
 Ed Schouten 
 WWW: http://80386.nl/


pgpEAKnJjfUKU.pgp
Description: PGP signature

Re: Freebsd 8.1 + xorg + radeonhd hang

[Oliver Fromme]

Eivind E  wrote:
 > One of my machines has a Radeon X1550 graphics card. When first
 > installed (then as either 7.1 or 7.1 prerelease), the radeonhd driver
 > hung the machine hard, screen went blank, numlock and capslock
 > didn't work, no network (so no ssh) and I couldn't do much but
 > hard reset the machine. I had to use vesa for a while, then, after
 > upgrading, the radeonhd driver worked up until fairly recent upgrades.
 > Sadly I didn't try the driver very often so I don't know if upgrading
 > src or xorg+drivers helped the problem.
 > 
 > 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.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"The scanf() function is a large and complex beast that often does
something almost but not quite entirely unlike what you desired."
-- Chris Torek
___
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

[Roland Smith]

On Mon, Sep 13, 2010 at 10:16:48PM +0200, Oliver Fromme wrote:
> Eivind E  wrote:
>  > One of my machines has a Radeon X1550 graphics card. When first
>  > installed (then as either 7.1 or 7.1 prerelease), the radeonhd driver
>  > hung the machine hard, screen went blank, numlock and capslock
>  > didn't work, no network (so no ssh) and I couldn't do much but
>  > hard reset the machine. I had to use vesa for a while, then, after
>  > upgrading, the radeonhd driver worked up until fairly recent upgrades.
>  > Sadly I didn't try the driver very often so I don't know if upgrading
>  > src or xorg+drivers helped the problem.
>  > 
>  > 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.

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.

Roland
-- 
R.F.Smith   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)


pgpnmE0QnXCBF.pgp
Description: PGP signature

Re: Freebsd 8.1 + xorg + radeonhd hang

[Eivind E]

On Mon, 13 Sep 2010, Oliver Fromme wrote:


Eivind E  wrote:
> One of my machines has a Radeon X1550 graphics card. When first
> installed (then as either 7.1 or 7.1 prerelease), the radeonhd driver
> hung the machine hard, screen went blank, numlock and capslock
> didn't work, no network (so no ssh) and I couldn't do much but
> hard reset the machine. I had to use vesa for a while, then, after
> upgrading, the radeonhd driver worked up until fairly recent upgrades.
> Sadly I didn't try the driver very often so I don't know if upgrading
> src or xorg+drivers helped the problem.
>
> 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.

Thanks for the tip though.
--
_
_  //
\\//   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: MSIX failure

[Jack Vogel]

We don't deal with desktop systems that much in my group, it was pointed out
by a coworker that the BIOS has settings that could disable MSI, please
check
out how yours is set.

Jack


On Mon, Sep 13, 2010 at 7:42 AM, Gareth de Vaux  wrote:

> On Fri 2010-09-10 (10:43), Jack Vogel wrote:
> > No, not the add-on adapter, i have no trouble finding those,  what I want
> to
> > know about is the details about the system that has em0 LOM, only
> > way to check on that is to have the whole enchilada :)
>
> Ah right. These are snippets from dmidecode, is this enough?
>
> Handle 0x, DMI type 4, 35 bytes
> Processor Information
>Socket Designation: LGA 1156
>Type: Central Processor
>Family: Other
>Manufacturer: Intel(R) Corporation
>ID: E5 06 01 00 FF FB EB BF
>Version: Intel(R) Core(TM) i5 CPU 750  @ 2.67GHz
>Voltage: 1.1 V
>External Clock: 133 MHz
>Max Speed: 4000 MHz
>Current Speed: 2668 MHz
>Status: Populated, Enabled
>Upgrade: Other
>L1 Cache Handle: 0x0004
>L2 Cache Handle: 0x0003
>L3 Cache Handle: 0x0001
>Serial Number: Not Specified
>Asset Tag: Not Specified
>Part Number: Not Specified
>
> Handle 0x0007, DMI type 2, 20 bytes
> Base Board Information
>Manufacturer: Intel Corporation
>Product Name: DP55WB
>Version: AAE64798-206
>Serial Number: AZWB005003A3
>Asset Tag: Base Board Asset Tag
>Features:
>Board is a hosting board
>Board is replaceable
>Location In Chassis: Base Board Chassis Location
>Chassis Handle: 0x0008
>Type: Unknown
>Contained Object Handles: 0
>
> Handle 0x0010, DMI type 10, 6 bytes
> On Board Device Information
>Type: Ethernet
>Status: Enabled
>Description: Intel(R) 82578DC Gigabit Network Connection
> ___
> 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

[Eivind E]

On Mon, 13 Sep 2010, Roland Smith wrote:


On Mon, Sep 13, 2010 at 10:16:48PM +0200, Oliver Fromme wrote:

Eivind E  wrote:
> One of my machines has a Radeon X1550 graphics card. When first
> installed (then as either 7.1 or 7.1 prerelease), the radeonhd driver
> hung the machine hard, screen went blank, numlock and capslock
> didn't work, no network (so no ssh) and I couldn't do much but
> hard reset the machine. I had to use vesa for a while, then, after
> upgrading, the radeonhd driver worked up until fairly recent upgrades.
> Sadly I didn't try the driver very often so I don't know if upgrading
> src or xorg+drivers helped the problem.
>
> 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.


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.

--
_
_  //
\\//   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

[Lucas Holt]

On 09/13/10 18:04, Eivind E wrote:


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.



You could try experimenting with the AccelMethod option.  I've got a 
newer gpu, but this is what is working for me with a 4200 + freebsd 8.1 
at work.


...

Section "Module"
Load  "extmod"
Load  "dbe"
Load  "glx"
Load  "dri"
Load  "dri2"
EndSection

...

(for the card)

Driver  "radeon"
VendorName  "ATI Technologies Inc"
BoardName   "RS880 [Radeon HD 4200]"
BusID   "PCI:1:5:0"
Option  "AccelMethod" "exa"
Option  "DRI" "yes"

FreeBSD lholt-desktop.primemediaanalysis.com 8.1-RELEASE FreeBSD 
8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010 
r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64


___
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

[Roland Smith]

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.

Roland
-- 
R.F.Smith   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)


pgp09GyYzCMIr.pgp
Description: PGP signature

Re: Serial console problems with stable/8

[Jeremy Chadwick]

On Mon, Sep 13, 2010 at 08:44:02PM +0200, Ed Schouten wrote:
> Maybe we should just implement /dev/console in such a way that it can
> never get stuck on dcd. I've seen this break too many times.
> 
> Below is an untested patch. Anyone willing to test it for me?

I'll test this out on our RELENG_8 system tonight.

-- 
| 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"