Re: invlpg produces strange sig11 on PentiumPro box

[John Baldwin]

On 01-Jul-00 Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Mike Smith writes:
>>> In message <[EMAIL PROTECTED]>, KATO Takenori writ
>>> es:
>>> >The invlpg instruction causes strange signal 11 problem on some
>>> >PentiumPro box.  This problem seems to hapen when (1) mother board is
>>> >very old and (2) BIOS update is not available and (3) cpuid < 0x619.
  
> Please Mike, just because you see my name you shouldn't take a contrary
> positition until you have actually looked into matters.
> 
> Look at the first paragraph:  This is for Pentium Pro cpus running
> in motherboards where the BIOS does not contain the needed microcode
> updates.

*ahem*  You might want to read the first paragraph as well.  It is
for situations where one _can't_ update one's BIOS.  I don't see why
making it a tweakable kernel compile time know that is off by
default would be so incredibly bad.  We have precedents already for
this type of thing.  And yes, in this case, the CPU is not performing
as advertised.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: "Sticky" Keys ?

[Guy Harris]

> You want accessx for X-windows.  Solaris, Compaq/Digital, and SGI
> provide it, but I didn't see anything at www.xfree86.org
> Searching around the web found a version for Linux
> http://slappy.cs.uiuc.edu/fall98/Linux/download.html

AccessX appears to have been developed, at least in part, by the Trace
Research and Development Center at the University of Wisconsin-Madison.

The page at

http://trace.wisc.edu/docs/x_win_access/x_access.htm

says, in the audience question section:

Audience: Will AccessX be in X11R6? 

Will:

AccessX was developed by Digital, Trace, and SUN and we did it
for X11R5.  Digital and SUN will be releasing it with the next
version of their operating systems which include the X11R5
server.  DACX has worked closely with Silicon Graphics, who are
working to develop the XKB extension for X11R6.  It is a much
larger extension that deals with the keyboard and is a logical
place to put the AccessX code.  So for X11R6, AccessX will be a
part of a larger extension called XKB.  The answer is yes it
will be there but it will be a different name.

Earl:

One additional item.  The fact that the underlying is changing,
AccessX to XKB, the user interface will still be the same, so to
use the R5 version on a SUN or DEC and when you transition to R6
version of the window server, the user interface will look the
same, the interaction will be the same.  So you won't have to
change how you interact with the systems.

XKB is part of X11R6.1 and later, so I infer that the low-level X server
support for sticky keys is built into recent versions of XFree86.

I don't know whether the UI stuff to control it is part of X11R6.x, or
of XFree86, though.

The Linux AccessX page you cite has a tarball of "the pristine source"
for their package, which appears to contain a Tcl script which may be
their control application, plus some C and C++ source; that page seems
to imply that there are features over and above the XKB-based features
of the Digital/Trace/Sun AccessX project, e.g.:

o Video Mode Changing lets users change their video screen mode
  on demand. 
o Control Panel allows the user to apply the settings before
  saving, save the user's settings, tab through the panel (for
  those who cannot use a mouse), give the user the option to
  restore the to the default settings, and more.
o Soon, the AccessX package will also include screen
  magnification. 

(I don't know whether the Video Mode Changing lets you change resolution
on the fly without changing your desktop - in which case it'd probably
be of interest even to people *without* limited vision - or not; it may
just be an interface to the video-mode changing extensions of XFree86).


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: style(9)

[Sergey Babkin]

Chris Costello wrote:
> 
> On Friday, June 30, 2000, Neil Blakey-Milner wrote:
> > No.  Anyway, you can set your tab size to whatever you want.  So long as
> > it is a _tab_, and not 2 or 4 or 8 spaces.  If you're heading into the
> > margin constantly, you should simplify your code, or break it up into
> > (preferably reusable) functions that perform one task.
> 
>Setting a tab width to something other than 8 would tend to
> break formatting for people with normal editors.  Just try
> viewing bsd.port.mk in vi with default settings and not seeing
> clutter.

Troubles start when people start using spaces at the beginning
of the lines. As long as _only_ tabs occur at the begining of the
lines everything is fine with any tab width (and I personally
prefer to set the tab width equal to 4). The worst thing that
can happen is the lines over 80 characters and that's no big deal.
On the other hand using tabs inside the lines tends to break
into ugly things.

-SB


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Why do we always create a malloc disk for md?

[John Baldwin]

I'm attempting to resolve why sysinstall keeps dying in -current
at the moment.  It seems that the problem is that md_drvinit()
always creates a malloc disk during initialization:

static void
md_drvinit(void *unused)
{
   ...
   [ load preloaded disks such as mfsroot.tgz from install floppy ]
   printf("md%d: Malloc disk\n", mdunits);
   mdcreate_malloc();
}

This results in having two md devices during boot:

md0: Preloaded image  mumble bytes at 0xmumble
md1: Malloc disk

This ends up registering md1 with disk_create, and thus md1
is returned as a disk through kern.disks into the list returned
by Disk_Names(), and sysinstall blows up when it tries to open
it.  I think the reason it blows up is because /dev/md1 isn't
around, although I think I may be able to fix that by adding
'md' as a disk device in the table in sysinstall/devices.c.\
However, I'm curious if md1 should be created in this case?

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Intel Pro/100+ Dual Port Server Adapter and Fault Tolerance

[Nick Evans]

Title: Intel Pro/100+ Dual Port Server Adapter and Fault Tolerance





Does anyone know if the FXP driver in 4.0-STABLE supports the AFT Fault Tolerance features of this network card? I know the fault tolerance is set in the driver under WindowsNT but I'm not quite sure whether or not it is supported, or will be supported, on FreeBSD.

UDF (DVD fs)

[Coleman Kane]

Hello, is anyone currently working on code to implement the UDF
filesystem? For those not familiar with it, it is the filesystem that
DVDs use. I'd like to look into getting the support under FreeBSD, since
the players already seem to work. If no one is working on this, then I
could probably use some help in writing the code to support this fs.

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu

 PGP signature

Re: XFree86 4.0 - What are people using for dual-head video?

[Coleman Kane]

I have been using a Matrox MGA G200 and a matrox Mystique 220. The
mystique card has a shot bios chip, so it only works as a secondary
video board. Besides, the G200 is far better to put on my 19" KDS VS-195e. My
Mystique is connected to an older NEC SVGA monitor, 14" at 1024x768@60Hz.


Matthew Reimer had the audacity to say:
> 
> Thomas Stromberg wrote:
> > 
> > This discussion comes up every once in a while on the lists, and I guess
> > it's time for an update. I havent seen anything since the 3.9.17 beta, so
> > here we go..
> > 
> > What dual head video combinations are people using with XFree86 4.0 and
> > FreeBSD? I've got a -CURRENT box right now with an AGP Riva TNT 2, and
> > really want to setup dual-head with it for programming (after first seeing
> > it on IRIX several years ago, I got hooked). Are people mixing different
> > vendors (Riva & Matrox?) and or AGP and PCI?
> > 
> > It's my understanding that there still isn't support for the dual-head
> > cards from Matrox, unless you go with a commercial X server. If anyone
> > could point me to a dual-head compatibility list, that'd help too.
> 
> I've had success with an AGP TNT2 Ultra with a Matrox Millenium.
> 
> Matt
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

-- 
Coleman Kane
President, 
UC Free O.S. Users Group - http://pohl.ececs.uc.edu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

ECU files and MLB BIOS

[gouders]

Hi,

I am having understanding/translation problems, again.

Can anyone help me with the terms "ECU files" and "MLB BIOS" (Hackers
section of the FAQ)?

Thanks,

Dirk


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: stray interrupts in 4.0

[Doug White]

On Sat, 1 Jul 2000, Dennis wrote:

> We're seeing lots of "stray" interrupts in 4.0 while running 3.4 on the
> same hardware reports nothing. The interrupt its complaining about is IRQ7
> even though parallel port is disabled and no other device. It happens on
> more than 1 MB.

This is in the archives and the FAQ at www.freebsd.org.  This is normal.

Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED] |  www.FreeBSD.org



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: style(9)

[Warner Losh]

In message <[EMAIL PROTECTED]> Jeroen Ruigrok/Asmodai 
writes:
: Often the 80 column boundary reminds me not to use
: functions_which_have_crazy_long_names_with_underscores(), but be a
: little more brief, but not too. ;)

IKnowPeopleThatLikeToHaveParagraphFunctionNamesToo();
DrivesMeNutsBecauseTheirCodeIsHardToReadAndModify();
TooMuchVerbosityIsSoMuchWorseThanTooLittleAndRepeitionCanBeBadToo();

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[Warner Losh]

In message <[EMAIL PROTECTED]> Wilko Bulte writes:
: Maybe make it conditional via an option in the kernel config file?
: Off by default of course. Looking at LINT/NOTES I see very obscure things
: for Cyrix and Bluelightning CPUs already.

I was going to make that same argument.  There's a need to have these
centrally located.  It should be conditional, however...

Then again, on the hardware we have for Timing Solutions, we have to
turn off the FOOF hack because it gets in the way of intercepting
NMI traps...

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Invalidating PACK!!!

[Joey Miller]

had the same problems.  make sure you are using LVD ribbon cables.

On Sat, Jul 01, 2000 at 11:11:47AM +0200, Mustafa Deeb wrote:
 // hi all,
 // 
 // we build our own servers, we've always used the intel N440BX and the
 // Barracuda disks.. and we liked it so much,
 // this time we bought intel's L440GX+ and the chettah disks from seagate
 // (Ultra2 DIsks)
 // and I'm getting these errors,
 // ofcourse the server goes nuts when an error like this happens..
 // after looking into the mailling lists, nobody gave a direct reason for this
 // problem or even a solution, anyways, I want to replace the Hard Drives,
 // 
 // is there someone who've used the L440GX+ motherboard with 18G disks and he
 // is happy with it
 // 
 // Best Regards...
 // Mustafa N. Deeb
 // 
 // 
 // 
 // da0 at ahc0 bus 0 target 1 lun 0
 // da0:  Fixed Direct Access SCSI-3 device
 // da0: 20.000MB/s transfers (10.000MHz, offset 63, 16bit), Tagged Queueing
 // Enabled
 // da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)
 // da2 at ahc0 bus 0 target 4 lun 0
 // da2:  Fixed Direct Access SCSI-3 device
 // da2: 20.000MB/s transfers (10.000MHz, offset 63, 16bit), Tagged Queueing
 // Enabled
 // da2: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)
 // da1 at ahc0 bus 0 target 2 lun 0
 // da1:  Fixed Direct Access SCSI-3 device
 // da1: 20.000MB/s transfers (10.000MHz, offset 63, 16bit), Tagged Queueing
 // Enabled
 // da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)
 // 
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): SCB 0x62 - timed out while idle, SEQADDR == 0xb
 // (da2:ahc0:0:4:0): Queuing a BDR SCB
 // (da2:ahc0:0:4:0): no longer in timeout, status = 34a
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): Invalidating pack
 // (da2:ahc0:0:4:0): SCB 0xc - timed out while idle, SEQADDR == 0x9
 // (da2:ahc0:0:4:0): Queuing a BDR SCB
 // (da2:ahc0:0:4:0): no longer in timeout, status = 34a
 // (da2:ahc0:0:4:0): Invalidating pack
 // 
 // 
 // 
 // To Unsubscribe: send mail to [EMAIL PROTECTED]
 // with "unsubscribe freebsd-isp" in the body of the message

-- 
Joey Miller
Sr. Systems Engineer
iBIZ Technology Corp.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Invalidating PACK!!!

[Mustafa N. Deeb]

hi,

well I think I've eliminated most of these things, I've the disks out of the
server and made the cooler point the air to it..
and It does not look like bad cables...
about the BAD hd, I've the problem on 5/5 new drives that I bought..
I'll try upgrading the firmeware and BIOS..
and see..

cheers

Jeroen Ruigrok/Asmodai wrote:

> -On [2701 11:18], Mustafa Deeb ([EMAIL PROTECTED]) wrote:
> >(da2:ahc0:0:4:0): Invalidating pack
> >(da2:ahc0:0:4:0): Invalidating pack
> >(da2:ahc0:0:4:0): Invalidating pack
> >(da2:ahc0:0:4:0): SCB 0x62 - timed out while idle, SEQADDR == 0xb
> >(da2:ahc0:0:4:0): Queuing a BDR SCB
> >(da2:ahc0:0:4:0): no longer in timeout, status = 34a
>
> Last times it happened to me it was either:
>
> - bad cabling
>
> - faulty HD/firmware
>
> - system ran way too hot
>
> I haven't really had a chance to blame the SCSI subsystem present in
> FreeBSD and trust me, I have had my share of these messages.
>
> Hope this helps,
>
> --
> Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
> Documentation nutter/C-rated Coder BSD: Technical excellence at its best
> The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
> And the price of a Memory is the Memory of the Sorrow it brings...
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-isp" in the body of the message



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Invalidating PACK!!!

[Jon Parise]

On Sat, Jul 01, 2000 at 11:11:47AM +0200, Mustafa Deeb wrote:

> is there someone who've used the L440GX+ motherboard with 18G disks
> and he is happy with it

No problems here with assorted 18G and 9G IBM Ultrastars and some 9G
Cheetahs.

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: style(9)

[Jeroen Ruigrok/Asmodai]

-On [2701 09:25], Wes Peters ([EMAIL PROTECTED]) wrote:
>
>Or simply get a wider editor.  Seriously.  Writing code in 80 columns is
>an anachronism.

Tastes do differ for that.

Often the 80 column boundary reminds me not to use
functions_which_have_crazy_long_names_with_underscores(), but be a
little more brief, but not too. ;)

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Here's a mirror, there's a screen, on both ways you can get in...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: style(9)

[Jeroen Ruigrok/Asmodai]

-On [2630 19:34], Warner Losh ([EMAIL PROTECTED]) wrote:
>
>I personally like 4 myself, but let's not get into a stupid tab width
>war were people argue about values from 2 to 6 that ends in the
>resolution that 8 might not be right, but reformatting everything
>would suck too bad to change it and introducing new code that isn't
>formatted at 8 would be confusing.  OK?  We've done that before.

For more wisdom on that read NetBSD-kernel and NetBSD-misc archives of
this year, february IIRC.

They just went through the whole debate.

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
An expert is one who knows more and more about less and less...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Invalidating PACK!!!

[Jeroen Ruigrok/Asmodai]

-On [2701 11:18], Mustafa Deeb ([EMAIL PROTECTED]) wrote:
>(da2:ahc0:0:4:0): Invalidating pack
>(da2:ahc0:0:4:0): Invalidating pack
>(da2:ahc0:0:4:0): Invalidating pack
>(da2:ahc0:0:4:0): SCB 0x62 - timed out while idle, SEQADDR == 0xb
>(da2:ahc0:0:4:0): Queuing a BDR SCB
>(da2:ahc0:0:4:0): no longer in timeout, status = 34a

Last times it happened to me it was either:

- bad cabling

- faulty HD/firmware

- system ran way too hot

I haven't really had a chance to blame the SCSI subsystem present in
FreeBSD and trust me, I have had my share of these messages.

Hope this helps,

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
And the price of a Memory is the Memory of the Sorrow it brings...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

stray interrupts in 4.0

[Dennis]

We're seeing lots of "stray" interrupts in 4.0 while running 3.4 on the
same hardware reports nothing. The interrupt its complaining about is IRQ7
even though parallel port is disabled and no other device. It happens on
more than 1 MB.

dennis


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, KATO Takenori writ
es:
>Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
>
>> Look at the first paragraph:  This is for Pentium Pro cpus running
>> in motherboards where the BIOS does not contain the needed microcode
>> updates.
>
>I have one question.  Does microcode update modify a CPU permanently?

No, it needs to be loaded at every reboot.

>I used a CPU on the M/B with correct microcode update and then moved
>the CPU to the M/B which has signal 11 problem.  Signal 11 didn't
>disappear.

This must have other reasons.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[KATO Takenori]

Mike Smith <[EMAIL PROTECTED]> wrote:

> If it's something that can be done as eg. a KLD 
> we might want to do that instead, or through some other mechanism for 
> handling these sort of CPU quirks.

It sounds good.  If binary-format quriks is supported, we can supply
update modules for new CPU and newly found errata like the update
module for AMD K6-2 CPU of Windows 95.

---+--+
KATO Takenori <[EMAIL PROTECTED]>  |FreeBSD   |
Dept. Earth Planet. Sci, Nagoya Univ.  |The power to serve!   |
Nagoya, 464-8602, Japan|  http://www.FreeBSD.org/ |
 FreeBSD(98) 4.0R-Rev. 01 available!   |http://www.jp.FreeBSD.org/|
 FreeBSD(98) 3.4R-Rev. 01 available!   +==+


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

vmstats for pages that go inactive->active

[Paul Herman]

Hi,

vmmeter->cnt.v_reactivated counts the number of cache pages that get
promoted to either active or inactive queues.  My read (and I could be
wrong) from vm/vm_page.c is, there is no statistic to count the
inactive pages that get "reclaimed" into the active queue.  I would
think this would be interessant/useful/enlightening/tasty for Joe
Sysadmin.

Any takers?  It should be a very simple patch (he says.)  Just thought
I'd ask before I go merily a-hackin.

Actually, I'm just looking for a way to _completely_ fill up the
'systat -v' screen.  :)

-Paul.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[KATO Takenori]

Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:

> Look at the first paragraph:  This is for Pentium Pro cpus running
> in motherboards where the BIOS does not contain the needed microcode
> updates.

I have one question.  Does microcode update modify a CPU permanently?
I used a CPU on the M/B with correct microcode update and then moved
the CPU to the M/B which has signal 11 problem.  Signal 11 didn't
disappear.

---+--+
KATO Takenori <[EMAIL PROTECTED]>  |FreeBSD   |
Dept. Earth Planet. Sci, Nagoya Univ.  |The power to serve!   |
Nagoya, 464-8602, Japan|  http://www.FreeBSD.org/ |
 FreeBSD(98) 4.0R-Rev. 01 available!   |http://www.jp.FreeBSD.org/|
 FreeBSD(98) 3.4R-Rev. 01 available!   +==+


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[KATO Takenori]

> Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> 
> > If we are talking about errata #34 the correct solution is to not use
> > 4MB pages.
> 
> Is FreeBSD #29-safe?

variable MTTRs are set as follows:
MSR (200): 0006
MSR (201): 000ffc000800
MSR (202): 0406
MSR (203): 000fff000800
MSR (204): 00f0
MSR (205): 00000800 *
MSR (206): 
MSR (207): 
MSR (208): 
MSR (209): 
MSR (20a): 
MSR (20b): 
MSR (20c): 
MSR (20d): 
MSR (20e): 
MSR (20f): 

One variable MTTR (marked *) has non-4MB aligned mask and errata #29
affects this system.

---+--+
KATO Takenori <[EMAIL PROTECTED]>  |FreeBSD   |
Dept. Earth Planet. Sci, Nagoya Univ.  |The power to serve!   |
Nagoya, 464-8602, Japan|  http://www.FreeBSD.org/ |
 FreeBSD(98) 4.0R-Rev. 01 available!   |http://www.jp.FreeBSD.org/|
 FreeBSD(98) 3.4R-Rev. 01 available!   +==+


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[KATO Takenori]

> in stepping sB0 (cpuid = 0x619).  I have both sA0 (cpuid = 0x617) and
> sB0 steppings and the signal 11 problem occurs only with the sA0
> stepping.

Oops, sA0 -> sA1 and sB0 -> sB1.

---+--+
KATO Takenori <[EMAIL PROTECTED]>  |FreeBSD   |
Dept. Earth Planet. Sci, Nagoya Univ.  |The power to serve!   |
Nagoya, 464-8602, Japan|  http://www.FreeBSD.org/ |
 FreeBSD(98) 4.0R-Rev. 01 available!   |http://www.jp.FreeBSD.org/|
 FreeBSD(98) 3.4R-Rev. 01 available!   +==+


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[KATO Takenori]

Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:

> If we are talking about errata #34 the correct solution is to not use
> 4MB pages.

Is FreeBSD #29-safe?

---+--+
KATO Takenori <[EMAIL PROTECTED]>  |FreeBSD   |
Dept. Earth Planet. Sci, Nagoya Univ.  |The power to serve!   |
Nagoya, 464-8602, Japan|  http://www.FreeBSD.org/ |
 FreeBSD(98) 4.0R-Rev. 01 available!   |http://www.jp.FreeBSD.org/|
 FreeBSD(98) 3.4R-Rev. 01 available!   +==+


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, KATO Takenori writ
es:
>Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
>
>> I'm against this patch.  This is so specific and marginal to a
>> out-of-spec hardware configuration, that it should not be put in
>> the FreeBSD tree.
>
>I'm not 100% sure but I think the signal 11 problem is result from the
>CPU errata.  There is the invlpg related errata and it has been fixed
>in stepping sB0 (cpuid = 0x619).  I have both sA0 (cpuid = 0x617) and
>sB0 steppings and the signal 11 problem occurs only with the sA0
>stepping.

If we are talking about errata #34 the correct solution is to not use
4MB pages.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[KATO Takenori]

Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:

> I'm against this patch.  This is so specific and marginal to a
> out-of-spec hardware configuration, that it should not be put in
> the FreeBSD tree.

I'm not 100% sure but I think the signal 11 problem is result from the
CPU errata.  There is the invlpg related errata and it has been fixed
in stepping sB0 (cpuid = 0x619).  I have both sA0 (cpuid = 0x617) and
sB0 steppings and the signal 11 problem occurs only with the sA0
stepping.

So, I think it is same as the 0xf00f hacking.

---+--+
KATO Takenori <[EMAIL PROTECTED]>  |FreeBSD   |
Dept. Earth Planet. Sci, Nagoya Univ.  |The power to serve!   |
Nagoya, 464-8602, Japan|  http://www.FreeBSD.org/ |
 FreeBSD(98) 4.0R-Rev. 01 available!   |http://www.jp.FreeBSD.org/|
 FreeBSD(98) 3.4R-Rev. 01 available!   +==+


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Wilko Bulte writes:

>> >Maybe make it conditional via an option in the kernel config file?
>> >Off by default of course. Looking at LINT/NOTES I see very obscure things
>> >for Cyrix and Bluelightning CPUs already.
>> 
>> But Wilko,
>> 
>> Those hacks are because the silicon, when used as directed, has flaws.
>
>OK, I understand that. But it appears to me that this patch allows the use
>of Si that should have had it's problems correct by the BIOS but in fact has
>not (because a corrected BIOS is not available). I'm one of those people
>who prefer a built-in, docuemted, switchable patch/hack over one that needs 
>to be hunted down on the Net and applied. Heck, if I wanted to do that I
>would have chosen Linux ;-)

I'm sorry, but I still don't think this patch belongs in FreeBSD.

What guarantee do you have that this is enough to make those CPUs run
reliably anyway ?  As far as I know Intel never released the errata
which the microcode updates fixes anyway.

I'm still against.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[Wilko Bulte]

On Sat, Jul 01, 2000 at 11:27:37AM +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Wilko Bulte writes:
> 
> >> Look at the first paragraph:  This is for Pentium Pro cpus running
> >> in motherboards where the BIOS does not contain the needed microcode
> >> updates.
> >> 
> >> The patch disables invlpg on all cpuid's < 0x619, despite the fact
> >> that they work just fine if your motherboards BIOS have the right
> >> microcode update for your cpu stepping.
> >> 
> >> This hack should be maintained by the person who need it, it should
> >> not be lobotomizing FreeBSD in general.
> >
> >Maybe make it conditional via an option in the kernel config file?
> >Off by default of course. Looking at LINT/NOTES I see very obscure things
> >for Cyrix and Bluelightning CPUs already.
> 
> But Wilko,
> 
> Those hacks are because the silicon, when used as directed, has flaws.

OK, I understand that. But it appears to me that this patch allows the use
of Si that should have had it's problems correct by the BIOS but in fact has
not (because a corrected BIOS is not available). I'm one of those people
who prefer a built-in, docuemted, switchable patch/hack over one that needs 
to be hunted down on the Net and applied. Heck, if I wanted to do that I
would have chosen Linux ;-)

-- 
Wilko Bulte http://www.freebsd.org  "Do, or do not. There is no try"
[EMAIL PROTECTED]   http://www.nlfug.nl Yoda - The Empire Strikes Back


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Wilko Bulte writes:

>> Look at the first paragraph:  This is for Pentium Pro cpus running
>> in motherboards where the BIOS does not contain the needed microcode
>> updates.
>> 
>> The patch disables invlpg on all cpuid's < 0x619, despite the fact
>> that they work just fine if your motherboards BIOS have the right
>> microcode update for your cpu stepping.
>> 
>> This hack should be maintained by the person who need it, it should
>> not be lobotomizing FreeBSD in general.
>
>Maybe make it conditional via an option in the kernel config file?
>Off by default of course. Looking at LINT/NOTES I see very obscure things
>for Cyrix and Bluelightning CPUs already.

But Wilko,

Those hacks are because the silicon, when used as directed, has flaws.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[Wilko Bulte]

On Sat, Jul 01, 2000 at 09:55:03AM +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Mike Smith writes:
> >> In message <[EMAIL PROTECTED]>, KATO Takenori writ
> >> es:
> >> >The invlpg instruction causes strange signal 11 problem on some
> >> >PentiumPro box.  This problem seems to hapen when (1) mother board is
> >> >very old and (2) BIOS update is not available and (3) cpuid < 0x619.
> >> >
> >> >Following patch automatically disables invlpg when PentiumPro with
> >> >cpuid < 0x619 is found.
> >> >
> >> >Please comment to this patch.
> >> 
> >> I'm against this patch.  This is so specific and marginal to a
> >> out-of-spec hardware configuration, that it should not be put in
> >> the FreeBSD tree.
> >
> >I'd disagree with that.  This is just the same as the 0xf00f workaround, 
> >saving only in degree.  If it's something that can be done as eg. a KLD 
> >we might want to do that instead, or through some other mechanism for 
> >handling these sort of CPU quirks.
> 
> Please Mike, just because you see my name you shouldn't take a contrary
> positition until you have actually looked into matters.
> 
> Look at the first paragraph:  This is for Pentium Pro cpus running
> in motherboards where the BIOS does not contain the needed microcode
> updates.
> 
> The patch disables invlpg on all cpuid's < 0x619, despite the fact
> that they work just fine if your motherboards BIOS have the right
> microcode update for your cpu stepping.
> 
> This hack should be maintained by the person who need it, it should
> not be lobotomizing FreeBSD in general.

Maybe make it conditional via an option in the kernel config file?
Off by default of course. Looking at LINT/NOTES I see very obscure things
for Cyrix and Bluelightning CPUs already.

-- 
Wilko Bulte http://www.freebsd.org  "Do, or do not. There is no try"
[EMAIL PROTECTED]   http://www.nlfug.nl Yoda - The Empire Strikes Back


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Invalidating PACK!!!

[Mustafa Deeb]

hi all,

we build our own servers, we've always used the intel N440BX and the
Barracuda disks.. and we liked it so much,
this time we bought intel's L440GX+ and the chettah disks from seagate
(Ultra2 DIsks)
and I'm getting these errors,
ofcourse the server goes nuts when an error like this happens..
after looking into the mailling lists, nobody gave a direct reason for this
problem or even a solution, anyways, I want to replace the Hard Drives,

is there someone who've used the L440GX+ motherboard with 18G disks and he
is happy with it

Best Regards...
Mustafa N. Deeb



da0 at ahc0 bus 0 target 1 lun 0
da0:  Fixed Direct Access SCSI-3 device
da0: 20.000MB/s transfers (10.000MHz, offset 63, 16bit), Tagged Queueing
Enabled
da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)
da2 at ahc0 bus 0 target 4 lun 0
da2:  Fixed Direct Access SCSI-3 device
da2: 20.000MB/s transfers (10.000MHz, offset 63, 16bit), Tagged Queueing
Enabled
da2: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)
da1 at ahc0 bus 0 target 2 lun 0
da1:  Fixed Direct Access SCSI-3 device
da1: 20.000MB/s transfers (10.000MHz, offset 63, 16bit), Tagged Queueing
Enabled
da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)

(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): SCB 0x62 - timed out while idle, SEQADDR == 0xb
(da2:ahc0:0:4:0): Queuing a BDR SCB
(da2:ahc0:0:4:0): no longer in timeout, status = 34a
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): Invalidating pack
(da2:ahc0:0:4:0): SCB 0xc - timed out while idle, SEQADDR == 0x9
(da2:ahc0:0:4:0): Queuing a BDR SCB
(da2:ahc0:0:4:0): no longer in timeout, status = 34a
(da2:ahc0:0:4:0): Invalidating pack



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Mike Smith writes:
>> In message <[EMAIL PROTECTED]>, KATO Takenori writ
>> es:
>> >The invlpg instruction causes strange signal 11 problem on some
>> >PentiumPro box.  This problem seems to hapen when (1) mother board is
>> >very old and (2) BIOS update is not available and (3) cpuid < 0x619.
>> >
>> >Following patch automatically disables invlpg when PentiumPro with
>> >cpuid < 0x619 is found.
>> >
>> >Please comment to this patch.
>> 
>> I'm against this patch.  This is so specific and marginal to a
>> out-of-spec hardware configuration, that it should not be put in
>> the FreeBSD tree.
>
>I'd disagree with that.  This is just the same as the 0xf00f workaround, 
>saving only in degree.  If it's something that can be done as eg. a KLD 
>we might want to do that instead, or through some other mechanism for 
>handling these sort of CPU quirks.

Please Mike, just because you see my name you shouldn't take a contrary
positition until you have actually looked into matters.

Look at the first paragraph:  This is for Pentium Pro cpus running
in motherboards where the BIOS does not contain the needed microcode
updates.

The patch disables invlpg on all cpuid's < 0x619, despite the fact
that they work just fine if your motherboards BIOS have the right
microcode update for your cpu stepping.

This hack should be maintained by the person who need it, it should
not be lobotomizing FreeBSD in general.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: invlpg produces strange sig11 on PentiumPro box

[Mike Smith]

> In message <[EMAIL PROTECTED]>, KATO Takenori writ
> es:
> >The invlpg instruction causes strange signal 11 problem on some
> >PentiumPro box.  This problem seems to hapen when (1) mother board is
> >very old and (2) BIOS update is not available and (3) cpuid < 0x619.
> >
> >Following patch automatically disables invlpg when PentiumPro with
> >cpuid < 0x619 is found.
> >
> >Please comment to this patch.
> 
> I'm against this patch.  This is so specific and marginal to a
> out-of-spec hardware configuration, that it should not be put in
> the FreeBSD tree.

I'd disagree with that.  This is just the same as the 0xf00f workaround, 
saving only in degree.  If it's something that can be done as eg. a KLD 
we might want to do that instead, or through some other mechanism for 
handling these sort of CPU quirks.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Bridging problems.. (WaveLan related?)

[Mark Newton]

On Sat, Jul 01, 2000 at 01:56:51AM -0500, Chris Csanady wrote:

 > It never fails..  I always post stuff just minutes too soon.
 > Anyways, it seems that the problem is with the WaveLan network.
 > In ad-hoc, or infrastructure mode, the card can only send
 > frames with its own mac address as the source.  Apparrently,
 > the card needs to be set up as an access point (or something)
 > to do bridging.
 
You can make it run as an access point... if and only if you're prepared
to produce an 802.11 protocol suite to run in the FreeBSD kernel, because
you won't be able to use the one in the card's firmware.

Of course, if you want to do something as insane as that, I'm sure your
efforts will be welcommed with open legs^H^H^H^Harms.  Being able to 
replace an access point with a FreeBSD box which costs a third as much
would be tres cool.  This is particularly true in the case of the 
Aironet 802.11 gear, which has even worse restrictions wrt bridging
and even more expensive access points.

(FWIW:  With the Aironet kit, when you place the card into "monitor
mode" you can't transmit frames at all).

- mark

-- 
Mark Newton   Email:  [EMAIL PROTECTED] (W)
Network Engineer  Email:  [EMAIL PROTECTED]  (H)
Internode Systems Pty Ltd Desk:   +61-8-82232999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message