Re: swap space issues

[Greg 'groggy' Lehey]

On Thursday, 25 June 2020 at 19:31:34 -0700, Donald Wilde wrote:
> On 6/25/20, Greg 'groggy' Lehey  wrote:
>> On Wednesday, 24 June 2020 at 23:27:27 -0700, Kevin Oberman wrote,
>> without trimming:
>>
>>> On Wed, Jun 24, 2020 at 10:30 PM Greg 'groggy' Lehey 
>>> wrote:
>>
>>> gpart(8) works just fine on MBR drives and partitions/slices and
>>> has a much friendlier user interface. "gpart resize" is the
>>> command you want.
>>
>> Thanks.  I try to offer suggestions that I've tried, and offer an
>> example.  I haven't tried 'gpart resize', but it looks much easier.
>
> 'gpart resize' did work well,

Yes, I saw that from the gpart output you posted.

> although the man page for gpart assumes way too much. I was able to
> successfully work my way through and create ('gpart add') and mount
> not just one but two 32G swap partitions.

Yes, I saw that too.  Not quite what I was suggesting: I suspected
some overflow issue, so the partitions should really have been a
little shy of 32 GB.  And at least for the start you should only mount
one of them.  In the unlikely event that it should threaten to fill
up, you can still mount the other one without rebooting (swapon(1)).

How are things looking now?

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

Re: swap space issues

[Greg 'groggy' Lehey]

On Wednesday, 24 June 2020 at 23:27:27 -0700, Kevin Oberman wrote,
without trimming:

> On Wed, Jun 24, 2020 at 10:30 PM Greg 'groggy' Lehey 
> wrote:
>
>> On Wednesday, 24 June 2020 at 20:34:24 -0700, Donald Wilde wrote:
>>> On 6/24/20, Greg 'groggy' Lehey  wrote:
>>>> On Wednesday, 24 June 2020 at 18:51:04 -0700, Donald Wilde wrote:
>>>>> On 6/24/20, Greg 'groggy' Lehey  wrote:
>>>>>> On Wednesday, 24 June 2020 at  9:36:23 -0700, Donald Wilde wrote:
>>>>>>> All,
...

This would be much more readable if you trimmed unrelated content.
>> That's really puzzling.  It seems that it gave you much more than you
>> asked for.
>>
>> Try this in single user mode: modify the size of the swap partition to
>> 30 GB.  I haven't used MBR partitions for years now, but I believe
>> that 'bsdlabel -e' will do the trick.  Just shorten the length of the
>> b partition.  You may need to 'mount -u /'.  If you do it right
>> (check!), this won't harm any of the other partitions: it'll just
>> leave 26 GB free between the swap partition and the next partition.
>>
> gpart(8) works just fine on MBR drives and partitions/slices and has a much
> friendlier user interface. "gpart resize"  is the command you want.

Thanks.  I try to offer suggestions that I've tried, and offer an
example.  I haven't tried 'gpart resize', but it looks much easier.

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

Re: swap space issues

[Greg 'groggy' Lehey]

On Friday, 26 June 2020 at  1:55:29 +0700, Eugene Grosbein wrote:
> 26.06.2020 1:30, Donald Wilde wrote:
>
>> Here's 'pstat -s' on the i3 (which registers as cpu HAMMER):
>>
>> Device  1K-blocks UsedAvail Capacity
>> /dev/ada0s1b 335544320 33554432 0%
>> /dev/ada0s1d 335544320 33554432 0%
>> Total671088640 67108864 0%
>
> "pstat -s" may also be invoked as "swapinfo"

That's no shorter.

> or better "swapinfo -h".

"Better" is in the eye of the beholder.  I find -h extremely
irritating.

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

Re: swap space issues

[Greg 'groggy' Lehey]

On Wednesday, 24 June 2020 at 20:34:24 -0700, Donald Wilde wrote:
> On 6/24/20, Greg 'groggy' Lehey  wrote:
>> On Wednesday, 24 June 2020 at 18:51:04 -0700, Donald Wilde wrote:
>>> On 6/24/20, Greg 'groggy' Lehey  wrote:
>>>> On Wednesday, 24 June 2020 at  9:36:23 -0700, Donald Wilde wrote:
>>>>> All,
>>>>>
>>>>> I recently upgraded my 12-STABLE system to the latest, and now my
>>>>> swap subsystems aren't working. I deliberately set up a 40GB
>>>>> partition for swap, and when I do 'top -t' I am only seeing 7906M
>>>>> total.
>>>>
>>>> That looks suspiciously like the difference from 32 GB.  Could it be
>>>> numeric overflow?  And if so, where?  What does pstat -s say?
>>>
>>> Well, hi Greg! LTNT2!
>>
>> Indeed.
>>
>>> pstat -shm:
>>>
>>> /dev/ada0s1b  65536 (1M blocks), Used: 1.5G, Avail: 63G, Capacity: 2%
>>
>> Now that's really puzzling.  Why does it say 64 G when you said 40 G,
>> and the error from top tends to confirm it?  How big is the partition
>> (gpart output)?
>
> Attached 'gpart list' output

FWIW, gpart show would have done the job.  But what I see there is Yet
Another swap partition size, 66 GB.   So so far we have various parts
reporting 8 GB, 40 GB, 64 GB and 66 GB.

> Reduced kern.maxswzone to 999. Is it decimal or unlabeled hex?

It'll be decimal, but it refers to the number of swblk structures
assigned in memory, and after reading the code I'm still not 100% in
the clear how this relates to the size of swap, if at all.

> 'top' now shows 4597M total swap.

... and 4.6 GB.  5 different sizes.

You really shouldn't be relying on top for swap info.  It's a third
party program that demonstrably shows incorrect results (though I
believe that the maintainer would be very interested to know why and
to fix it).  But pstat -s (without any further options) should show
what the kernel thinks.

>>> What else can I share to help diagnose this?
>>
>> Background, maybe?  You say that you upgraded your system.  Did you
>> change the swap size when you did?  What were swap and RAM sizes
>> before and after?
>
> Meant that I upgraded from 12.1-RELEASE to 12-STABLE. When I
> configured the -RELEASE install, I manually messed with the MBR disk
> partitions. This is nominally a half-TB HDD which showed up as a total
> of 446 G available (IIRC, gpart should show it's actual size). I did
> auto partitioning, looked at the sizes, and manually set my partitions
> to give me 40G of swap instead of the auto-generated size of 4G.

That's really puzzling.  It seems that it gave you much more than you
asked for.

Try this in single user mode: modify the size of the swap partition to
30 GB.  I haven't used MBR partitions for years now, but I believe
that 'bsdlabel -e' will do the trick.  Just shorten the length of the
b partition.  You may need to 'mount -u /'.  If you do it right
(check!), this won't harm any of the other partitions: it'll just
leave 26 GB free between the swap partition and the next partition.

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

Re: swap space issues

[Greg 'groggy' Lehey]

On Wednesday, 24 June 2020 at 18:51:04 -0700, Donald Wilde wrote:
> On 6/24/20, Greg 'groggy' Lehey  wrote:
>> On Wednesday, 24 June 2020 at  9:36:23 -0700, Donald Wilde wrote:
>>> All,
>>>
>>> I recently upgraded my 12-STABLE system to the latest, and now my
>>> swap subsystems aren't working. I deliberately set up a 40GB
>>> partition for swap, and when I do 'top -t' I am only seeing 7906M
>>> total.
>>
>> That looks suspiciously like the difference from 32 GB.  Could it be
>> numeric overflow?  And if so, where?  What does pstat -s say?
>
> Well, hi Greg! LTNT2!

Indeed.

> pstat -shm:
>
> /dev/ada0s1b  65536 (1M blocks), Used: 1.5G, Avail: 63G, Capacity: 2%

Now that's really puzzling.  Why does it say 64 G when you said 40 G,
and the error from top tends to confirm it?  How big is the partition
(gpart output)?

>>> When using synth, it shows swap usage of < 2%, but then it gives the
>>> 'out of swap' complaint and tosses all my users out into neverland.
>>
>> Unless this also causes kernel messages to that effect, this, too,
>> could be an issue with synth.
>
> I believe the messages about 'out of swap' were from the kernel as
> it died, not synth. As I say, it killed all my active users, both
> root and non-root.

Hmm.

> Why does _top_ show the 7906M number? I suspect that it's deeper
> than just synth.

If top counts swap in a form that overflows at 32 GB, 40 GB could show
up as 8 GB.

> What else can I share to help diagnose this?

Background, maybe?  You say that you upgraded your system.  Did you
change the swap size when you did?  What were swap and RAM sizes
before and after?

FWIW, I've had a very large number of issues with -STABLE in recent
months, though not this one.  I should send a separate message.

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

Re: swap space issues

[Greg 'groggy' Lehey]

On Wednesday, 24 June 2020 at  9:36:23 -0700, Donald Wilde wrote:
> All,
>
> I recently upgraded my 12-STABLE system to the latest, and now my
> swap subsystems aren't working. I deliberately set up a 40GB
> partition for swap, and when I do 'top -t' I am only seeing 7906M
> total.

That looks suspiciously like the difference from 32 GB.  Could it be
numeric overflow?  And if so, where?  What does pstat -s say?

> When using synth, it shows swap usage of < 2%, but then it gives the
> 'out of swap' complaint and tosses all my users out into neverland.

Unless this also causes kernel messages to that effect, this, too,
could be an issue with synth.

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

Re: New Xorg - different key-codes

[Greg 'groggy' Lehey]

On Wednesday, 11 March 2020 at  0:20:03 +, Poul-Henning Kamp wrote:
[originally sent to current@]
> I just updated my laptop from source, and somewhere along the way
> the key-codes Xorg sees changed.

Indeed.  This doesn't just affect -CURRENT: it happened to me on
-STABLE last week, so I'm copying that list too.  See
http://www.lemis.com/grog/diary-mar2020.php?topics=c=Daily%20teevee%20update=D-20200306-002910#D-20200306-002910
, not the first entry on the subject.

> I have the right Alt key mapped to "Multi_key", which is now
> keycode 108 instead of 113, which is now arrow left instead.

Interesting.  Mine wandered from 117 to 147, with PageDown ("Next") as
collateral damage.  It seems that there are a lot of strange new key
bindings (partial output of xmodmap -pk):

117 0xff56 (Next)   0x (NoSymbol)   0xff56 (Next)
130 0xff31 (Hangul) 0x (NoSymbol)   0xff31 (Hangul)
131 0xff34 (Hangul_Hanja)   0x (NoSymbol)   0xff34 
(Hangul_Hanja)
135 0xff67 (Menu)   0x (NoSymbol)   0xff67 (Menu)
147 0x1008ff65 (XF86MenuKB) 0x (NoSymbol)   0x1008ff65 
(XF86MenuKB)

Some of these may reflect other remappings that I have done.

> I hope this email saves somebody else from the frustrating
> morning I had...

Sorry.  I should have thought of reporting it.  For me, with a number
of other issues, it was a frustrating week,some of which are still not
resolved.

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd)

[Greg 'groggy' Lehey]

[line lengths recovered]

On Sunday,  1 May 2016 at 20:16:38 -0700, Jordan Hubbard wrote:
>
>> On May 1, 2016, at 5:49 PM, Warren Block  wrote:
>>
>>   The first quarter of 2016 showed that FreeBSD retains a strong sense of
>>   ipseity. Improvements were pervasive, lending credence to the concept
>>   of meliorism. [ ??? ]
>
>
> I, for one, learned at least 4 new words in that announcement, 3 of
> which were actually real.

And the other is int?  OK, I'll bite.  Which one is unreal?

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

Re: can we resurrect linux-firefox-1.5 ?

[Greg 'groggy' Lehey]

On Wednesday, 17 January 2007 at  9:56:51 +1000, Greg Black wrote:
 On 2007-01-16, Luigi Rizzo wrote:

 The 1.5.x version _is_ working for me. It is 2.0.x that
 exhibits severe problems.

 I was surprised and annoyed when I found that the reasonably reliable
 1.5.x version had been replaced by 2.0, partly because I expected it to
 be less reliable and partly because some of the extensions I used no
 longer worked and partly because the user interface had some changes I
 didn't like.

Same here.

 However, it has been my experience in the 6+ weeks I've been using
 it that 2.0 is better in every way than 1.5 and it is certainly more
 stable and works better with the flash plugin (something I hate but
 just have to use).

I can't agree.  It has hijacked some keys used by Wikipedia (alt-S,
alt-P), and so far I've found it impossible to disable tabs, something
that was barely possible under 1.5.  Tell me how to fix that and I'll
be marginally happy; presumably they'll gradually fix the stability
problems.

Greg
--
See complete headers for address and phone numbers.


pgpidbjw7wL6p.pgp
Description: PGP signature

Re: can we resurrect linux-firefox-1.5 ?

[Greg 'groggy' Lehey]

On Wednesday, 17 January 2007 at  3:16:44 +0100, Roland Smith wrote:
 On Wed, Jan 17, 2007 at 11:37:53AM +1030, Greg 'groggy' Lehey wrote:

 I can't agree.  It has hijacked some keys used by Wikipedia (alt-S,
 alt-P), and so far I've found it impossible to disable tabs, something
 that was barely possible under 1.5.  Tell me how to fix that and I'll
 be marginally happy; presumably they'll gradually fix the stability
 problems.

 You could set browser.tabs.forceHide to true in about:config. That
 should get rid of the tabbar. Set browser.link.open_external and
 browser.link.open_newwindow to 2 to open new pages in a new window.

Thank you!  I had done some of these changes, but not all.  Now it
works.

 Personally I like tabbed browsing a lot, but different strokes for
 different folks.

It probably depends on your window manager.  Tabs are a reasonable
workaround for window managers that make it difficult to manage many
windows.

Greg
--
See complete headers for address and phone numbers.


pgp9AEtAX9etx.pgp
Description: PGP signature

Re: vinum to gvinum help

[Greg 'groggy' Lehey]

On Monday, 26 June 2006 at 19:15:36 +0200, Roland Smith wrote:
 On Mon, Jun 26, 2006 at 12:22:07PM -0400, Sven Willenberger wrote:
 I have an i386 system currently running 5.2.1-RELEASE with a vinum
 mirror array (2 drives comprising /usr ). I want to upgrade this to
 5.5-RELEASE which, if I understand correctly, no longer supports vinum
 arrays. Would simply chaning /boot/loader.conf to read gvinum_load
 instead of vinum_load work or would the geom layer prevent this from
 working properly? If not, is there a recommended way of upgrading a
 vinum array to a gvinum or gmirror array?

 Lost of things have changed between 5.2.1 and 5.5. I think it would be
 best to make a backup and do a clean reinstall.

To the best of my knowledge, the Vinum on-disk layout has not changed,
so you shouldn't need to reinstall the data.  A backup is always an
excellent idea, of course :-)

Greg
--
See complete headers for address and phone numbers.


pgp0XOpSrsJNR.pgp
Description: PGP signature

Re: cpu-timer rate

[Greg 'groggy' Lehey]

On Friday,  2 December 2005 at 14:32:58 +0100, kama wrote:

 Hi,

 I am just wondering why the cpu-timer is doubled from what I set in
 kern.hz?

 # vmstat -i
 ...
 cpu0: timer 14314031   1999

 # sysctl -a | grep hz
 kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }

Interesting question.  So far I haven't seen an answer that comes
close to explaining it.  My guess is that it's because of the specific
timer you're using; which is it?  Is there anything else of interest
in your setup?

FWIW, I get (without ACPI) on two different machines essentially the
same:

  $ vmstat -i
  interrupt  total   rate
  irq0: clk   55250411   1000
  irq1: atkbd0   47365  0
  irq5: ohci197516  1
  irq8: rtc7069645127
  irq10: ehci0   1  0
  irq11: nve0 xl0+ 1022991 18
  irq14: ata0   425652  7
  irq15: ata1 4777  0
  Total   63918358   1157
  $ sysctl -a | grep hz
  kern.clockrate: { hz = 1000, tick = 1000, profhz = 1024, stathz = 128 }
  debug.psm.hz: 20

Greg
--
See complete headers for address and phone numbers.


pgpYkTQ7P7I12.pgp
Description: PGP signature

Re: Laptop choices

[Greg 'groggy' Lehey]

On Thursday, 24 November 2005 at 11:17:41 -0500, [EMAIL PROTECTED] wrote:

 On the [Dell] warrenty... I'm hard on equipment and I depend on my
 equipment.  I've been impressed that if I put my foot down and say
 that I believe something needs replacing, then without much fuss,
 they do it.  The next day onsite service is cool.

You obviously have better experience than I do.  My Inspiron 6000 was
apparently used: it arrived without the usual plastic coating on the
lid, with scratches which couldn't have come from transport instead.
Also the ejector for the PC Card fell apart shortly after I got it.
It took them over 3 weeks to get a replacement lid to me, by which
time I had left for Europe.  By the time I get home I will have had
the machine for 6 weeks, too long to return it, and only then will I
be able to fight the Dell service department about the ejector.  Only
some time after then will they be able to replace the lid.

Greg
--
See complete headers for address and phone numbers
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ACPI problems with Dell laptops

[Greg 'groggy' Lehey]

On Sunday, 27 November 2005 at 23:10:01 +, Chris Howells wrote:
 On Sunday 27 November 2005 11:50, Greg 'groggy' Lehey wrote:
 Since then I've also discovered that the builtin wireless card doesn't
 work either.  It's:

   iwi0: Intel(R) PRO/Wireless 2915ABG mem 0xdfcfd000-0xdfcfdfff irq 10 at
 device 3.0 on pci3 iwi0: Ethernet address: 00:13:ce:46:28:49

 snip

   DHCPDISCOVER on iwi0 to 255.255.255.255 port 67 interval 6
   DHCPDISCOVER on iwi0 to 255.255.255.255 port 67 interval 15
   send_packet: Network is down

 On the console I get the detailed error message:

   iwi0: fatal error

 iwi(4) is unfortunately pretty unstable so I'm not sure if it's directly
 related to the ACPI problems.

Yes, as I said: since then.  It doesn't work with or without ACPI, so
I see this as unrelated to ACPI.  It does seem relevant to the
original Subject: line (Laptop choices), though.

Even more information about iwi0: I googled and found some information
about iwi and Dell laptops, and after issuing the command

  # ifconfig iwi0 mode b

I got an association and was able to use the card.  Then I tried

  # ifconfig iwi0 mode g

which caused a panic

  #9  0xc0648ff7 in panic (fmt=0xc087130c mutex %s recursed at %s:%d) at 
/usr/src/sys/kern/kern_shutdown.c:539
  #10 0xc064180b in _mtx_assert (m=0xc4d1cb6c, what=0xc1033000, file=0xc08726bd 
/usr/src/sys/kern/kern_synch.c,
line=0xbc) at /usr/src/sys/kern/kern_mutex.c:748
  #11 0xc064ee6a in msleep (ident=0xc4d1c000, mtx=0xc4d1cb6c, priority=0x0, 
wmesg=0xc0aadbd3 iwiinit, timo=0x3e8)
at /usr/src/sys/kern/kern_synch.c:188

Unfortunately, the stack beyond this point was corrupt.  Since then I
haven't been able to reproduce getting the card to associate or
(obviously) the panic.  So I'd agree that iwi is still a bit flaky.

Greg
--
See complete headers for address and phone numbers
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ACPI problems with Dell laptops

[Greg 'groggy' Lehey]

On Saturday, 26 November 2005 at 20:25:58 -0600, Eric Anderson wrote:
 Greg 'groggy' Lehey wrote:
 I've had both Dell and ThinkPad (no longer IBM).  I prefer Dell,
 despite their attempts to convince me otherwise.

 However, we currently seem to have significant ACPI problems with Dell
 laptops.  I'm writing this on an Inspiron 6000 running 7-CURRENT, but
 the same problems occur with 6.0: if I enable ACPI, timing goes to
 hell, and some things just time out.  There was a similar message a
 couple of days ago from an owner of (I think) the latest Latitude
 machine, which sounded even worse.  My requests for feedback about how
 to solve the problem have so far not been resolved.  If you're
 otherwise tending towards Dell, I'd suggest you watch this space until
 there's some indication that the problems will be resolved.

 Which scheduler are you using?

The standard (ULE).  I don't think the problem's related to the
scheduler: it shows all the signs of being an interrupt space problem.

 Also, have you tried disabling apic?

I think you mean ACPI.  This machine doesn't have an APIC.

To answer the presumed question: Yes, as I said above, the problems
only occur when I enable ACPI.

Since then I've also discovered that the builtin wireless card doesn't
work either.  It's:

  iwi0: Intel(R) PRO/Wireless 2915ABG mem 0xdfcfd000-0xdfcfdfff irq 10 at 
device 3.0 on pci3
  iwi0: Ethernet address: 00:13:ce:46:28:49

After downloading the firmware, I can set IP addresses and such, but
I always get no carrier:

  iwi0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
ether 00:13:ce:46:28:49
media: IEEE 802.11 Wireless Ethernet autoselect
status: no carrier
ssid  channel 1 (2412)
authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF
powersavesleep 100 txpowmax 100 txpower 100 rtsthreshold 2346
fragthreshold 2346 -pureg protmode CTS -wme roaming AUTO bintval 0

When I run dhclient on the interface, I get:

  DHCPDISCOVER on iwi0 to 255.255.255.255 port 67 interval 6
  DHCPDISCOVER on iwi0 to 255.255.255.255 port 67 interval 15
  send_packet: Network is down

On the console I get the detailed error message:

  iwi0: fatal error

This machine also has Linux on it, and the card works fine with Linux,
so it's obviously a FreeBSD-related problem.

Greg
--
See complete headers for address and phone numbers
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

ACPI problems with Dell laptops (was: Laptop choices)

[Greg 'groggy' Lehey]

On Tuesday, 22 November 2005 at 17:12:46 -0800, Graham North wrote:
 Am currently trying to choose between a couple of laptops, the luck
 winner of which will have Freebsd loaded alongside WinXP.

 Dell Latitude d600 with Radeon 9000? video, intel pro wireless
 or
 IBM R51 - Intel Extreme2, intel pro wireless.
 The main differences will likely be the video and maybe bios, acpi...?
 Can someone suggest to me whether these are both safe choices?
 Am I better off installing 5.4 or 6.0?

I've had both Dell and ThinkPad (no longer IBM).  I prefer Dell,
despite their attempts to convince me otherwise.

However, we currently seem to have significant ACPI problems with Dell
laptops.  I'm writing this on an Inspiron 6000 running 7-CURRENT, but
the same problems occur with 6.0: if I enable ACPI, timing goes to
hell, and some things just time out.  There was a similar message a
couple of days ago from an owner of (I think) the latest Latitude
machine, which sounded even worse.  My requests for feedback about how
to solve the problem have so far not been resolved.  If you're
otherwise tending towards Dell, I'd suggest you watch this space until
there's some indication that the problems will be resolved.

Nothing of this says that ThinkPads will do better, of course.  I
don't know what the situation is there.

Greg
--
See complete headers for address and phone numbers
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Laptop choices

[Greg 'groggy' Lehey]

On Wednesday, 23 November 2005 at 11:42:17 -0800, Gary Kline wrote:
 On Wed, Nov 23, 2005 at 08:19:07PM +0100, Bartosz Fabianowski wrote:
 Or, can the touch pads be disabled in the bios?

 I have a Dell Inspiron 8600C, which only has a touch pad. ...

 Of course, this is not a Thinkpad clone, but it is a very good laptop
 nonetheless (especially the awesome 15.4 1920x1200 screen).

   That is *outsanding* resolution!!!  I'm looking at some real
   good deals on ebay ...  think I'll check the Thinkpads.  See
   if they've come down.  Like to find another one without XBill's
   stuff.

This is one of the reasons I use Dell (the other is that I prefer them
to ThinkPads, the only other machines that support this resolution).
My machine has the 1920x1200 screen.  It's so much better than the
standard 1024x768 that you have to see it to understand.

Greg
--
See complete headers for address and phone numbers
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ACPI problems with Dell laptops? (was: Jerky keyboard and mouse)

[Greg 'groggy' Lehey]

On Sunday, 20 November 2005 at 23:01:41 -0600, Doug Poland wrote:

 On Sun, November 20, 2005 01:59, Greg 'groggy' Lehey wrote:
 On Saturday, 19 November 2005 at 21:37:03 -0600, Stephen
 Montgomery-Smith wrote:
 I recently upgraded from stable-6 of Nov 4 to stable-6 of today on
 my Dell Latitude D800 Laptop, and suddenly the response of the
 touchpad mouse and keyboard was bery bad.

 Heh.  I saw the subject line and thought I wonder if this is a Dell
 laptop.

 Well, I'm glad I'm not the only one :)

 In particular, when I type about 1 in 10 key presses simply do not
 register.

 Same here, it's basically unusable if you're a fast touch typist.

Indeed.  After all, you're quoting yourself :-)  I said:

 This, however, is a order of magnitude worse than what I have
 experienced with my Inspiron 6100.

In particular, I didn't get any dropped characters.  And I note that
I've misquoted the model number; it's an Inspiron 6000, not 6100 (I
don't think the latter exists).

 What happens when you ping another system?  I found that the ping
 time was normal (in the order of 1 µs), but it repeated only every
 3 seconds.  When I unloaded ACPI, things worked normally.

 Not loading ACPI fixed my issues too.  I'd be more than happy to
 help any testing that may develop.

I would have been interested to hear the results of the ping.  But
yes, it would be nice to get the machine to work nicely with ACPI.

Greg
--
See complete headers for address and phone numbers
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

ACPI problems with Dell laptops? (was: Jerky keyboard and mouse)

[Greg 'groggy' Lehey]

On Saturday, 19 November 2005 at 21:37:03 -0600, Stephen Montgomery-Smith wrote:
 I recently upgraded from stable-6 of Nov 4 to stable-6 of today on
 my Dell Latitude D800 Laptop, and suddenly the response of the
 touchpad mouse and keyboard was bery bad.

Heh.  I saw the subject line and thought I wonder if this is a Dell
laptop.

 In particular, when I type about 1 in 10 key presses simply do not
 register.

This, however, is a order of magnitude worse than what I have
experienced with my Inspiron 6100.

 I ended up going back to the Nov 4 stable-6, which fixed the
 problem.

Well, it worked around it.

 Any ideas?  I am happy to provide any details you may need.

I'd guess that this is another ACPI issue like the one I reported a
couple of weeks back.  In my case, it was slow, but I didn't lose any
keystrokes.

What happens when you ping another system?  I found that the ping time
was normal (in the order of 1 µs), but it repeated only every 3
seconds.  When I unloaded ACPI, things worked normally.

I'm following this up to the ACPI list with a reminder that my message
has been there for 2 weeks.  How do I localize the problem?

Greg
--
See complete headers for address and phone numbers
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: MySQL 4.1, GCC 3.x, FreeBSD 4.x

[Greg 'groggy' Lehey]

On Wednesday, 21 September 2005 at 14:39:55 -0400, Kris Kennaway wrote:
 On Wed, Sep 21, 2005 at 02:31:18PM -0400, John Nielsen wrote:
 Should it be possible to compile and run MySQL 4.1 with GCC 3.4 on a FreeBSD
 4.11 machine?

 I have a server which, for the time being at least, cannot be updated to
 FreeBSD 5.  I'm currently running the stock MySQL 4.1.14 compiled from the
 port with no make flags.

 I would like to experiment with different build options/flags in the hopes
 of boosting performance.  Specifically, I'd like to build it with
 linuxthreads and optimized C flags, but I am wary of using -O3 with gcc
 2.9.  Am I just being paranoid?

 When I try this from databases/mysql41-server:
 make WITH_LINUXTHREADS=yes BUILD_OPTIMIZED=yes USE_GCC=3.4

 USE_GCC is wrong, it's not a user-controllable variable. Set CC
 instead.

 This might be OK as long as there is no C++ code involved, which
 cannot be linked to C++ code from gcc 2.95.

There's lots of C++ code in MySQL.

Greg
--
See complete headers for address and phone numbers.


pgpLI7rqcFgCt.pgp
Description: PGP signature

Re: Vinum volume manager

[Greg 'groggy' Lehey]

On Tuesday,  6 September 2005 at 14:05:03 +0100, Tomas Palfi wrote:
 To all,

 i've got a server with two identical disks which I would like to set
 up as a one way mirror with Vinum volume manager. How do I go about
 configuring the entire disk making it bootable mirror of the first
 one?

This is described in the documentation
(http://www.vinumvm.org/cfbsd/vinum.pdf).  Does that not work for you?

Greg
--
See complete headers for address and phone numbers.


pgp56P83ZLrK9.pgp
Description: PGP signature

Re: Panic: don't do that ... while unloading snd_ich.ko

[Greg 'groggy' Lehey]

On Wednesday,  6 July 2005 at  2:31:37 +0200, Michael Nottebrock wrote:
 Readily reproducable, 5.4-STABLE as of last week.

 Kernel messages prior to panic (from memory):

 pcm0: unregister: mixer busy
 WARNING: Driver mistake: destroy_dev on 30/3

This is a phkism.  It's supposed to tell the developer to fix his
code.  You'll have to look at the code and work out what's wrong.  I
don't understand how this could get into STABLE, though.

Greg
--
The virus contained in this message was detected by LEMIS anti-virus.

Finger [EMAIL PROTECTED] for PGP public key.
See complete headers for address and phone numbers.


pgpzFC5XvAOgs.pgp
Description: PGP signature

Re: FreeBSD MySQL still WAY slower than Linux

[Greg 'groggy' Lehey]

On Friday, 10 June 2005 at 18:05:37 +0100, Steve Roome wrote:
 We're using mostly:

   5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005

 This is on a Dell PowerEdge 2850. (2 * 2.8 GHz Xeons, 4GB ram, disks),
 we've been keeping up with stable because supposedly all these new
 fixes to threading will help us out here.

What's the current malloc config for 5.4?  Last time I saw this kind
of comparison, it proved to be due to malloc debugging.  That was on
-CURRENT, though.  See http://www.lemis.com/grog/diary-dec2004.html#14
for more details.

Greg
--
The virus contained in this message was not detected.

Finger [EMAIL PROTECTED] for PGP public key.
See complete headers for address and phone numbers.


pgpoodi3zh8lJ.pgp
Description: PGP signature

Re: State of gvinum RELENG_5 or RELENG_5_4 ?!

[Greg 'groggy' Lehey]

On Thursday, 12 May 2005 at 17:16:59 +0200, Matthias Buelow wrote:
 Peter Orlowski wrote:

 At this point, I'm thinking that as far as S/W RAID goes in FreeBSD, the
 R is pretty meaningless

 Well, R does not mean redundant but realtime backup ;-(.

 BTW., what is the status of RaidFrame on FreeBSD?  I remember some time
 ago people were working on integrating it into 5.x or so?  I have good
 experience with Raidframe on NetBSD, and less good with vinum on FreeBSD
 so I'd be delighted if Raidframe could make it into FreeBSD (and work
 equally well, of course).

RAIDFrame was introduced to FreeBSD some years ago, but died during to
lack of love.

Greg
--
See complete headers for address and phone numbers
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Problems with AMD64 and 8 GB RAM? (solved)

[Greg 'groggy' Lehey]

On Friday,  8 April 2005 at 13:04:18 -0700, David O'Brien wrote:
 On Tue, Apr 05, 2005 at 10:09:11AM +0930, Greg 'groggy' Lehey wrote:
 The moral of the story is, I suppose, don't buy the MSI K8T
 Master2-FAR.  I was warned about the motherboard before I bought it,

 WHY??  There is nothing wrong with that motherboard -- I have three of
 them.  You are at fault for trying to treat a consumer desktop 2P mobo as
 a high-end server one.

You are at fault for trying to used a mobo in an advertised
configuration.

Sorry, David.  If a board doesn't perform as advertised, it's
inferior.  If you can find a way to work around, fine.  I can too, and
I have done.  But the ability to find a workaround for a deficiency is
no reason to say There is nothing wrong with that motherboard.

 People do not run 2GB DIMM's in an MSI K8T Master2-FAR.

Indeed.  You can't.

 The MSI K8T Master2-FAR works fine with 1GB DIMM's.  Where on MSI's
 website did they state 2GB double-stacked DIMM's were supported?

I can't be bothered to search their web site.  It's on page 2-8 of the
instructions supplied with the motherboard (document G52-S9130X3,
version 1.2).

Greg
--
See complete headers for address and phone numbers.


pgpOjAHZUNWP1.pgp
Description: PGP signature

Re: Problems with AMD64 and 8 GB RAM? (solved)

[Greg 'groggy' Lehey]

On Thursday, 31 March 2005 at 10:59:02 -0800, David O'Brien wrote:
 On Thu, Mar 31, 2005 at 11:24:29AM +0930, Greg 'groggy' Lehey wrote:
 On Thursday, 31 March 2005 at 10:32:33 +0930, Daniel O'Connor wrote:
 On Thu, 31 Mar 2005 08:14, Greg 'groggy' Lehey wrote:
 Have you run sysutils/memtest86 with the 8 GB?

 Heh.  Difficult when the system doesn't run.

 You could try http://www.memtest86.com although that doesn't do 4Gb
 :(

 I'm pretty sure it's not the memory.  I've tried each pair
 individually, and it's only when they're both in there together that
 it's a problem.  And yes, I've tried them in each pair of slots.

 You have a dual-channel memory controller.  If you insert one DIMM you
 perform 64-bit data accesses.  If you install DIMM's in pairs (making
 sure you're using the right paired sockets), you perform 128-bit data
 accesses.  Thus your access pattern is different between these two
 situations.  I'm highly suspious that you can us 4x2GB DIMM's with out
 knowing the exact part number.  Don't forget 2GB DIMM's are
 double-stacked and thus look like double the electrical bus loads.  The
 same is true for older 1GB DIMM's.

This looks like it's the issue.

 Install all the memory you would like to use into your motherboard,
 download memtest86+ version 1.40 from http://www.memtest.org, dd to
 floppy or burn the ISO, and report back your findings from running
 it.

Done that.  It was quite revealing.  This particular motherboard and
BIOS supply either ECC off or ECC in chip kill mode.  Mine was
off, and I got many errors.  With 4 GB (any two chips) and chip kill
mode enabled, I ran memtest86+ for about 18 hours and got about 1 ECC
error per second.  With 8 GB, with or without chip kill, neither
FreeBSD, memtest86+ nor Linux run reliably: memtest86+ spontaneously
reboots every 5 minutes or so.

I borrowed this memory to test the motherboard, and it's going back
this week anyway.  I now have my own memory :-(all 1 GB of it), and it
tests perfectly.  The memory I had the trouble with works perfectly in
the machine for which it was purchased, so it does indeed look like an
electrical loading problem.

The moral of the story is, I suppose, don't buy the MSI K8T
Master2-FAR.  I was warned about the motherboard before I bought it,
but at the time it was the only game in town.  Now I know of other
places with (hopefully) better boards.

Greg
--
See complete headers for address and phone numbers.


pgpTvRjcpU4Il.pgp
Description: PGP signature

Re: 5.4-prerelease - hanging under load

[Greg 'groggy' Lehey]

On Sunday,  3 April 2005 at 14:45:40 -0700, Nate Lawson wrote:
 Christian Brueffer wrote:
 On Sun, Apr 03, 2005 at 12:07:14PM -0400, Pierre-Luc Drouin wrote:
 Christian Brueffer wrote:
 On Sat, Apr 02, 2005 at 09:16:48PM -0500, Pierre-Luc Drouin wrote:

 Since I upgraded from 5.3-stable to 5.4-prerelease, I've noticed that
 my computer is hanging badly under load. I've a P4 2.53 GHz without
 hyperthreading (no SMP). I use the same kernel configurations than
 before. Now when I compile a port for example, the mouse pointer hangs
 in Fluxbox and Mozilla takes forever (meaning ~5 sec) to refresh the
 screen. Even vi hangs. I do not see any warning/error message. Is it a
 known problem with 5.4?

 I have experienced something similar, putting the following into rc.conf
 worked for me:

 performance_cpu_freq=HIGH

 Yes, this seams to fix it. I didn't know that I had a laptop? :)

 Good to hear.

 Nate, this regression was introduced during the cpufreq and friends MFC.
 Is switching the performance_cpu_freq default to HIGH the way to go for
 5.4-RELEASE?

 As you can see from etc/defaults/rc.conf on both -current and RELENG_5,
 we don't currently change the frequency at all:

 performance_cpu_freq=NONE # Online CPU frequency
 economy_cpu_freq=NONE # Offline CPU frequency

 However, it sounds like his system's BIOS is booting up with a low
 acpi_throttle setting (probably the lowest one, 12.5% on many systems)
 and so he is seeing very slow performance.  (Only the acpi_throttle
 cpufreq driver has been MFCd for the 5.4 release and the others will
 follow the release.)  Initially, I thought it was safest not to even
 touch the frequency but it looks like it is necessary for some systems
 to always force it high by default.

I'm experiencing similar issues.  How can I confirm that this is the
case without rebooting the machine (which would be inconvenient)?  Is
there some sysctl that tells me?  I've taken a look, but I don't see
anything obvious.

Greg
--
See complete headers for address and phone numbers.


pgpuWiaFyppGe.pgp
Description: PGP signature

Re: 5.4-prerelease - hanging under load

[Greg 'groggy' Lehey]

On Sunday,  3 April 2005 at 21:43:57 -0700, Nate Lawson wrote:
 Greg 'groggy' Lehey wrote:

 I'm experiencing similar issues.  How can I confirm that this is the
 case without rebooting the machine (which would be inconvenient)?  Is
 there some sysctl that tells me?  I've taken a look, but I don't see
 anything obvious.

 sysctl dev.cpu and look at the current frequency setting.

There's nothing there that reaches out and grabs me:

  dev.cpu.0.%desc: ACPI CPU
  dev.cpu.0.%driver: cpu
  dev.cpu.0.%location: handle=\_PR_.CPU0
  dev.cpu.0.%pnpinfo: _HID=none _UID=0
  dev.cpu.0.%parent: acpi0

 If low, then your system is affected and will be fixed soon when I
 mfc.  If not, perhaps you have an interrupt storm (vmstat -i)

No, nothing there:

  interrupt  total   rate
  irq0: clk  184217768100
  irq1: atkbd0 554  0
  irq4: sio0  31529039 17
  irq7: ppc047  0
  irq8: rtc  235761929128
  irq11: xl0 ohci1   555868535301
  irq14: ata0 19980318 10
  irq15: ata1169418181 91
  Total 1196776371649

Greg
--
See complete headers for address and phone numbers.


pgprFQ8xDFNpy.pgp
Description: PGP signature

Re: 5.4-prerelease - hanging under load

[Greg 'groggy' Lehey]

On Sunday,  3 April 2005 at 21:59:45 -0700, Nate Lawson wrote:
 Greg 'groggy' Lehey wrote:
 On Sunday,  3 April 2005 at 21:43:57 -0700, Nate Lawson wrote:
 Greg 'groggy' Lehey wrote:
 I'm experiencing similar issues.  How can I confirm that this is the
 case without rebooting the machine (which would be inconvenient)?  Is
 there some sysctl that tells me?  I've taken a look, but I don't see
 anything obvious.

 sysctl dev.cpu and look at the current frequency setting.

 There's nothing there that reaches out and grabs me:

  dev.cpu.0.%desc: ACPI CPU
  dev.cpu.0.%driver: cpu
  dev.cpu.0.%location: handle=\_PR_.CPU0
  dev.cpu.0.%pnpinfo: _HID=none _UID=0
  dev.cpu.0.%parent: acpi0

 Not it.  You have no acpi_throttle support, thus cpufreq is a no-op on
 your system.

OK, so it's a different issue that I have?  Or does the lack of
acpi_throttle support automatically cause a problem?

Greg
--
See complete headers for address and phone numbers.


pgp1hrnznJaWQ.pgp
Description: PGP signature

Problems with AMD64 and 8 GB RAM?

[Greg 'groggy' Lehey]

I've recently acquired an AMD64 box (dual Opteron 242, SiS [EMAIL PROTECTED]
motherboard
(http://www.msi.com.tw/program/products/server/svr/pro_svr_detail.php?UID=484).
See below for more details).  I find it very unstable running with 8
GB memory, though 4 GB are not a problem.  At first I thought it was
the onboard peripherals, but after disabling them it still persisted.

What's unstable?  I only once got it through the boot process.
Running a 5.3-RELEASE i386 kernel it panics, though I haven't
investigated the panic (yet), since I'm not interested in the i386
kernel.  The amd64 5.4-PRERELEASE kernel just hangs/freezes.  When the
peripherals are enabled, it's after probing the onboard NIC (bge) and
before probing SATA (no drives present).  I've done a verbose boot, of
course, but no additional information is present.  The NIC is
recognized, and that's all.

Without the peripherals, but with a 3Com 3c905 PCI NIC, it continues
beyond this point, but doesn't enable the NIC.  I don't have dmesg
output for these attempts, so I can't produce the exact message, and I
suspect it's not important.  It continues until trying to mount NFS
file systems, where it hangs for obvious reasons.  Pressing ^C causes
the system to either panic (and be unable to dump because I don't have
that much swap) or just hang.

None of these problems occur when I use 4 GB memory.  About the only
strangeness, which seems to come from the BIOS, is that it recognizes
only 3.5 GB.  If I put all DIMMS in, it recognizes the full 8 GB
memory.

I realize that this isn't enough to diagnose the problem.  The reason
for this message now is to ask:

1.  Has anybody else seen this problem?
2.  Has anybody else used this hardware configuration and *not* seen
this problem?
3.  Where should I look next?

I'm attaching the (non-verbose) dmesg from a successful boot.

Greg
--
See complete headers for address and phone numbers.

Mar 30 14:17:16 obelix kernel: FreeBSD 5.4-PRERELEASE #0: Tue Mar 22 04:02:17 
UTC 2005
Mar 30 14:17:16 obelix kernel: [EMAIL 
PROTECTED]:/usr/obj/src/FreeBSD/OBELIX/src/sys/OBELIX
Mar 30 14:17:16 obelix kernel: Timecounter i8254 frequency 1193182 Hz quality 0
Mar 30 14:17:16 obelix kernel: CPU: AMD Opteron(tm) Processor 242 (1603.65-MHz 
K8-class CPU)
Mar 30 14:17:16 obelix kernel: Origin = AuthenticAMD  Id = 0xf5a  Stepping = 
10
Mar 30 14:17:16 obelix kernel: 
Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
6,CLFLUSH,MMX,FXSR,SSE,SSE2
Mar 30 14:17:16 obelix kernel: AMD 
Features=0xe0500800SYSCALL,NX,MMX+,LM,3DNow+,3DNow
Mar 30 14:17:16 obelix kernel: real memory  = 3756916736 (3582 MB)
Mar 30 14:17:16 obelix kernel: avail memory = 3623907328 (3456 MB)
Mar 30 14:17:16 obelix kernel: ACPI APIC Table: VIAK8  AWRDACPI
Mar 30 14:17:16 obelix kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 
CPUs
Mar 30 14:17:16 obelix kernel: cpu0 (BSP): APIC ID:  0
Mar 30 14:17:16 obelix kernel: cpu1 (AP): APIC ID:  1
Mar 30 14:17:16 obelix kernel: ioapic0: Changing APIC ID to 2
Mar 30 14:17:16 obelix kernel: ioapic0 Version 0.3 irqs 0-23 on motherboard
Mar 30 14:17:16 obelix kernel: acpi0: VIAK8 AWRDACPI on motherboard
Mar 30 14:17:16 obelix kernel: acpi0: Power Button (fixed)
Mar 30 14:17:16 obelix kernel: Timecounter ACPI-fast frequency 3579545 Hz 
quality 1000
Mar 30 14:17:16 obelix kernel: acpi_timer0: 24-bit timer at 3.579545MHz port 
0x4008-0x400b on acpi0
Mar 30 14:17:16 obelix kernel: cpu0: ACPI CPU on acpi0
Mar 30 14:17:16 obelix kernel: cpu1: ACPI CPU on acpi0
Mar 30 14:17:16 obelix kernel: acpi_button0: Power Button on acpi0
Mar 30 14:17:16 obelix kernel: pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff 
on acpi0
Mar 30 14:17:16 obelix kernel: pci0: ACPI PCI bus on pcib0
Mar 30 14:17:16 obelix kernel: pcib1: PCI-PCI bridge at device 1.0 on pci0
Mar 30 14:17:16 obelix kernel: pci1: PCI bus on pcib1
Mar 30 14:17:16 obelix kernel: pci1: display, VGA at device 0.0 (no driver 
attached)
Mar 30 14:17:16 obelix kernel: xl0: 3Com 3c905C-TX Fast Etherlink XL port 
0xd000-0xd07f mem 0xfb00-0xfb7f irq 
18 at device 7.0 on pci0
Mar 30 14:17:16 obelix kernel: miibus0: MII bus on xl0
Mar 30 14:17:16 obelix kernel: xlphy0: 3c905C 10/100 internal PHY on miibus0
Mar 30 14:17:16 obelix kernel: xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 
100baseTX-FDX, auto
Mar 30 14:17:16 obelix kernel: xl0: Ethernet address: 00:50:da:cf:17:d3
Mar 30 14:17:16 obelix kernel: atapci0: VIA 8237 UDMA133 controller port 
0xd400-0xd40f,0x376,0x170-0x177,0x3f6,0x1f0-0
x1f7 at device 15.0 on pci0
Mar 30 14:17:16 obelix kernel: ata0: channel #0 on atapci0
Mar 30 14:17:16 obelix kernel: ata1: channel #1 on atapci0
Mar 30 14:17:16 obelix kernel: uhci0: VIA 83C572 USB controller port 
0xd800-0xd81f irq 21 at device 16.0 on pci0
Mar 30 14:17:16 obelix kernel: usb0: VIA 83C572 USB controller on uhci0
Mar 30 14:17:16 obelix kernel: usb0: USB revision 1.0
Mar 30 14:17:16 obelix kernel: uhub0: VIA UHCI root hub, class 9/0, rev 

Re: Problems with AMD64 and 8 GB RAM?

[Greg 'groggy' Lehey]

On Wednesday, 30 March 2005 at 15:30:37 -0700, Scott Long wrote:
 Greg 'groggy' Lehey wrote:
 I've recently acquired an AMD64 box ...

 What's unstable?  ... The amd64 5.4-PRERELEASE kernel just
 hangs/freezes.

 5.3-RELEASE has a lot of problems with 4GB due to busdma issues.
 Those should no longer be an issue in RELENG_5, including 5.4-PRE.

They appear to be.

 I realize that this isn't enough to diagnose the problem.  The reason
 for this message now is to ask:

 3.  Where should I look next?

 You'll need to dig in and provide some more details, I guess.

Yes, my guess too.

 I have an HDAMA dual Opteron system that behaves fine now with 8GB
 of RAM, so your problem might lie with particular hardware and/or
 drivers.

As I described, it doesn't appear to be the drivers.

Greg
--
See complete headers for address and phone numbers.


pgpuBz6NIFzNC.pgp
Description: PGP signature

Re: Problems with AMD64 and 8 GB RAM?

[Greg 'groggy' Lehey]

On Wednesday, 30 March 2005 at 14:35:46 -0800, Steve Kargl wrote:
 On Thu, Mar 31, 2005 at 07:54:39AM +0930, Greg 'groggy' Lehey wrote:
 None of these problems occur when I use 4 GB memory.  About the only
 strangeness, which seems to come from the BIOS, is that it recognizes
 only 3.5 GB.  If I put all DIMMS in, it recognizes the full 8 GB
 memory.

 I realize that this isn't enough to diagnose the problem.  The reason
 for this message now is to ask:

 1.  Has anybody else seen this problem?
 2.  Has anybody else used this hardware configuration and *not* seen
 this problem?
 3.  Where should I look next?

 Have you run sysutils/memtest86 with the 8 GB?

Heh.  Difficult when the system doesn't run.

 I had 4 bad out of 12 tested where the DIMMs were Crucial PC2700 2GB
 Reg. ECC DIMMs.

OK, this makes sense.  It might also explain why the 4 GB
configuration only recognizes 3.5 GB.

Greg
--
See complete headers for address and phone numbers.


pgpHUROsJz6Ax.pgp
Description: PGP signature

Re: Problems with AMD64 and 8 GB RAM?

[Greg 'groggy' Lehey]

On Thursday, 31 March 2005 at 10:32:33 +0930, Daniel O'Connor wrote:
 On Thu, 31 Mar 2005 08:14, Greg 'groggy' Lehey wrote:
 Have you run sysutils/memtest86 with the 8 GB?

 Heh.  Difficult when the system doesn't run.

 You could try http://www.memtest86.com although that doesn't do 4Gb
:(

I'm pretty sure it's not the memory.  I've tried each pair
individually, and it's only when they're both in there together that
it's a problem.  And yes, I've tried them in each pair of slots.

I now have dmesg output for verbose boots with both 4 GB and 8 GB
memory.  The complete dmesg output is at
http://www.lemis.com/grog/Images/20050331/dmesg.4GB and
http://www.lemis.com/grog/Images/20050331/dmesg.8GB.  The diffs are at
http://www.lemis.com/grog/Images/20050331/dmesg.diff.  Here's a
truncated summary:

 --- dmesg.4GB   Thu Mar 31 10:47:16 2005
 +++ dmesg.8GB   Thu Mar 31 10:52:32 2005
 @@ -64,6 +10,7 @@
  SMAP type=01 base=0010 len=dfde
  SMAP type=03 base=dfee3000 len=d000
  SMAP type=04 base=dfee len=3000
 +SMAP type=01 base=0001 len=0001
  Copyright (c) 1992-2005 The FreeBSD Project.
 @@ -75,7 +22,7 @@
  Calibrating clock(s) ... i8254 clock: 1193283 Hz
  CLK_USE_I8254_CALIBRATION not specified - using default frequency
  Timecounter i8254 frequency 1193182 Hz quality 0
 -Calibrating TSC clock ... TSC clock: 1603647337 Hz
 +Calibrating TSC clock ... TSC clock: 1603647241 Hz
  CPU: AMD Opteron(tm) Processor 242 (1603.65-MHz K8-class CPU)
Origin = AuthenticAMD  Id = 0xf5a  Stepping = 10

 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2
 @@ -90,11 +37,12 @@
  L2 4KB data TLB: 512 entries, 4-way associative
  L2 4KB instruction TLB: 512 entries, 4-way associative
  L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative
 -real memory  = 3756916736 (3582 MB)
 +real memory  = 8589934592 (8192 MB)

This is interesting in that it has gained 4.5 GB.

  Physical memory chunk(s):
  0x1000 - 0x0009bfff, 634880 bytes (155 pages)
 -0x00a05000 - 0xd95b7fff, 3636146176 bytes (887731 pages)
 -avail memory = 3623817216 (3455 MB)
 +0x00a09000 - 0xdfed, 3746394112 bytes (914647 pages)
 +0x0001 - 0x0001f0fc, 4043112448 bytes (987088 pages)
 +avail memory = 177600 (7416 MB)
  ACPI APIC Table: VIAK8  AWRDACPI
  APIC ID: physical 0, logical 0:0
  APIC ID: physical 1, logical 0:1
 @@ -138,41 +86,12 @@
  ioapic0: intpin 9 trigger: level
  ioapic0: intpin 9 polarity: low
  lapic0: Routing NMI - LINT1
 -A IRQ 3 (edge, high)
 -ioapic0: intpin 4 - ISA IRQ 4 (edge, high)
 -ioapic0: intpin 5 - ISA IRQ 5 (edge, high)
 -ioapic0: intpin 6 - ISA IRQ 6 (edge, high)
 -ioapic0: intpin 7 - ISA IRQ 7 (edge, high)
 -ioapic0: intpin 8 - ISA IRQ 8 (edge, high)
 -ioapic0: intpin 9 - ISA IRQ 9 (edge, high)
 -ioapic0: intpin 10 - ISA IRQ 10 (edge, high)
 -ioapic0: intpin 11 - ISA IRQ 11 (edge, high)
 -ioapic0: intpin 12 - ISA IRQ 12 (edge, high)
 -ioapic0: intpin 13 - ISA IRQ 13 (edge, high)
 -ioapic0: intpin 14 - ISA IRQ 14 (edge, high)
 -ioapic0: intpin 15 - ISA IRQ 15 (edge, high)
 -ioapic0: intpin 16 - PCI IRQ 16 (level, low)
 -ioapic0: intpin 17 - PCI IRQ 17 (level, low)
 -ioapic0: intpin 18 - PCI IRQ 18 (level, low)
 -ioapic0: intpin 19 - PCI IRQ 19 (level, low)
 -ioapic0: intpin 20 - PCI IRQ 20 (level, low)
 -ioapic0: intpin 21 - PCI IRQ 21 (level, low)
 -ioapic0: intpin 22 - PCI IRQ 22 (level, low)
 -ioapic0: intpin 23 - PCI IRQ 23 (level, low)
 -MADT: Interrupt override: source 0, irq 2
 -ioapic0: Routing IRQ 0 - intpin 2
 -ioapic0: intpin 2 trigger: edge
 -ioapic0: intpin 2 polarity: high
 -MADT: Interrupt override: source 9, irq 9
 -ioapic0: intpin 9 trigger: level
 -ioapic0: intpin 9 polarity: low
 -lapic0: Routing NMI - LINT1

This stuff is puzzling.  I suppose it could be related.  Does anybody
have any ideas?

  lapic0: LINT1 trigger: edge
  lapic0: LINT1 polarity: high
  lapic1: Routing NMI - LINT1
  lapic1: LINT1 trigger: edge
  lapic1: LINT1 polarity: high
 -ioapic0 Version 0.3 irqs 0-23 on motherboard
 +ioapic0 Version 0.0 irqs 0-23 on motherboard
  cpu0 BSP:
   ID: 0x   VER: 0x00040010 LDR: 0x0100 DFR: 0x0fff
lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff

The last lines in the 8 GB dmesg are:

 bge0: Broadcom BCM5705 Gigabit Ethernet, ASIC rev. 0x3003 mem 
 0xfa00-0xfa00 irq 16 at device 11.0 on pci0
 bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0xfa00

They're identical in each probe.

Greg
--
See complete headers for address and phone numbers.


pgpZU27XHUxhn.pgp
Description: PGP signature

Re: Problems with AMD64 and 8 GB RAM?

[Greg 'groggy' Lehey]

On Thursday, 31 March 2005 at  5:54:17 +0200, Matthias Buelow wrote:
 Greg 'groggy' Lehey wrote:

 I'm pretty sure it's not the memory.  I've tried each pair
 individually, and it's only when they're both in there together that
 it's a problem.  And yes, I've tried them in each pair of slots.

 I'm sure you have checked this aswell but just for completeness,
 they aren't different pairs?  Like one pair is single-sided and the
 other double-sided (had some nasty and obscure problems with such
 a combination myself)?

No, they're all the same.

Greg
--
See complete headers for address and phone numbers.


pgpB6Tf3lyzwW.pgp
Description: PGP signature

Re: Problems with AMD64 and 8 GB RAM?

[Greg 'groggy' Lehey]

On Wednesday, 30 March 2005 at 23:01:03 -0500, John Baldwin wrote:

 On Mar 30, 2005, at 8:54 PM, Greg 'groggy' Lehey wrote:
 lapic0: LINT1 trigger: edge
 lapic0: LINT1 polarity: high
 lapic1: Routing NMI - LINT1
 lapic1: LINT1 trigger: edge
 lapic1: LINT1 polarity: high
 -ioapic0 Version 0.3 irqs 0-23 on motherboard
 +ioapic0 Version 0.0 irqs 0-23 on motherboard
 cpu0 BSP:
  ID: 0x   VER: 0x00040010 LDR: 0x0100 DFR: 0x0fff
   lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff

 This shows that in the - case the APIC is broken somehow (0.0 isn't a
 valid I/O APIC version). 

You mean the + case, I suppose.  Yes, that's what I suspected.

 It would seem that the system has mapped RAM over top of the I/O
 APIC perhaps?

That's what I suspected too, but imp doesn't think so.

 It would be interesting to see the contents of your MADT to see if
 it's trying to use a 64-bit PA for your APIC.

Any suggestions about how to do so?

Greg
--
See complete headers for address and phone numbers.


pgpswZz69jMbN.pgp
Description: PGP signature

Re: Problems with AMD64 and 8 GB RAM?

[Greg 'groggy' Lehey]

[gratuitous empty lines removed]

On Wednesday, 30 March 2005 at 21:28:36 -0700, Scott Long wrote:
 Greg 'groggy' Lehey wrote:
 On Wednesday, 30 March 2005 at 23:01:03 -0500, John Baldwin wrote:

 On Mar 30, 2005, at 8:54 PM, Greg 'groggy' Lehey wrote:

 lapic0: LINT1 trigger: edge
 lapic0: LINT1 polarity: high
 lapic1: Routing NMI - LINT1
 lapic1: LINT1 trigger: edge
 lapic1: LINT1 polarity: high
 -ioapic0 Version 0.3 irqs 0-23 on motherboard
 +ioapic0 Version 0.0 irqs 0-23 on motherboard
 cpu0 BSP:
ID: 0x   VER: 0x00040010 LDR: 0x0100 DFR: 0x0fff
 lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff

 This shows that in the - case the APIC is broken somehow (0.0 isn't a
 valid I/O APIC version).

 You mean the + case, I suppose.  Yes, that's what I suspected.

 It would seem that the system has mapped RAM over top of the I/O
 APIC perhaps?

 That's what I suspected too, but imp doesn't think so.

 I'd be more inclined to believe that there is an erroneous mapping
 by the OS, not that things are fundamentally broken in hardware.

Agreed.  This has been my favourite hypothesis all along.  But isn't
that what jhb is saying?

 Your SMAP table shows everything correctly.  It's becoming hard to
 break through your pre-concieved notions here and explain how things
 actually work.

No, there's nothing to break through.  I think you're just having
problems

1.  expressing yourself, and
2.  understanding what I'm saying.

I have no preconceived notions.  All I can see here is an antagonistic
attitude on your part.  What's the problem?  You'll recall from my
first message that I asked for suggestions about how to approach the
issue.  jhb provided some; you haven't so far.  From what you've
written, it's unclear whether you disagree with jhb or not.  If you
do, why?  If you don't, what's your point here?

 It would be interesting to see the contents of your MADT to see if
 it's trying to use a 64-bit PA for your APIC.

 Any suggestions about how to do so?

 man acpidump

How do you run that on a system that won't boot?

Greg
--
See complete headers for address and phone numbers.


pgppI6HefiCEz.pgp
Description: PGP signature

Re: Problems with AMD64 and 8 GB RAM?

[Greg 'groggy' Lehey]

On Wednesday, 30 March 2005 at 22:27:43 -0700, Scott Long wrote:
 Jon Noack wrote:
 On 03/30/05 23:14, Greg 'groggy' Lehey wrote:
 On Wednesday, 30 March 2005 at 21:28:36 -0700, Scott Long wrote:
 Greg 'groggy' Lehey wrote:
 On Wednesday, 30 March 2005 at 23:01:03 -0500, John Baldwin wrote:
 It would be interesting to see the contents of your MADT to see if
 it's trying to use a 64-bit PA for your APIC.

 Any suggestions about how to do so?

 man acpidump

 How do you run that on a system that won't boot?

 You said the system worked with 4 GB (albeit detecting only 3.5
 GB).

Yes, this is correct.  A number of people have explained why it only
detected 3.5 GB in this configuration.

 My perception of this whole ACPI thing is that it is fixed in your
 BIOS (although it can be overridden by the OS).  As such, the
 amount of RAM you have in the machine shouldn't change acpidump
 results.  Is that not correct?

 This is absolutely correct.

Ah, so you meant to say that the output from the system running with 4
GB memory is useful?  That wasn't in the man page you pointed to.
What it does say is:

 When invoked with the -t flag, the acpidump utility dumps contents of
 the following tables:

 ...   MADT

This may be the case, but between man page and output some terminology
must have changed.  I can't see any reference to anything like an MADT
there.  Does that mean that there isn't one, or that ACPI can't find
it, or does the section APIC refer to/dump the MADT?  Here's the
complete output of acpidump -t, anyway:

/*
  RSD PTR: OEM=VIAK8, ACPI_Rev=1.0x (0)
RSDT=0xdfee3000, cksum=97
 */
/*
  RSDT: Length=44, Revision=1, Checksum=4,
OEMID=VIAK8, OEM Table ID=AWRDACPI, OEM Revision=0x42302e31,
Creator ID=AWRD, Creator Revision=0x0
Entries={ 0xdfee3040, 0xdfee7b40 }
 */
/*
  FACP: Length=116, Revision=1, Checksum=255,
OEMID=VIAK8, OEM Table ID=AWRDACPI, OEM Revision=0x42302e31,
Creator ID=AWRD, Creator Revision=0x0
FACS=0xdfee, DSDT=0xdfee30c0
INT_MODEL=PIC
Preferred_PM_Profile=Unspecified (0)
SCI_INT=9
SMI_CMD=0x402f, ACPI_ENABLE=0xa1, ACPI_DISABLE=0xa0, S4BIOS_REQ=0x0
PSTATE_CNT=0x0
PM1a_EVT_BLK=0x4000-0x4003
PM1a_CNT_BLK=0x4004-0x4005
PM_TMR_BLK=0x4008-0x400b
GPE0_BLK=0x4020-0x4023
P_LVL2_LAT=101 us, P_LVL3_LAT=1001 us
FLUSH_SIZE=0, FLUSH_STRIDE=0
DUTY_OFFSET=0, DUTY_WIDTH=1
DAY_ALRM=125, MON_ALRM=126, CENTURY=50
IAPC_BOOT_ARCH=
Flags={WBINVD,PROC_C1,SLP_BUTTON,RTC_S4,RESET_REG}
RESET_REG=0x:0[0] (Memory), RESET_VALUE=0x44
 */
/*
  FACS: Length=64, HwSig=0x, Firm_Wake_Vec=0x
Global_Lock=
Flags=
Version=0
 */
/*
  DSDT: Length=19020, Revision=1, Checksum=28,
OEMID=VIAK8, OEM Table ID=AWRDACPI, OEM Revision=0x1000,
Creator ID=MSFT, Creator Revision=0x10e
 */
/*
  APIC: Length=104, Revision=1, Checksum=145,
OEMID=VIAK8, OEM Table ID=AWRDACPI, OEM Revision=0x42302e31,
Creator ID=AWRD, Creator Revision=0x0
Local APIC ADDR=0xfee0
Flags={PC-AT}

Type=Local APIC
ACPI CPU=0
Flags={ENABLED}
APIC ID=0

Type=Local APIC
ACPI CPU=1
Flags={ENABLED}
APIC ID=1

Type=IO APIC
APIC ID=2
INT BASE=0
ADDR=0xfec0

Type=INT Override
BUS=0
IRQ=0
INTR=2
Flags={Polarity=conforming, Trigger=conforming}

Type=INT Override
BUS=0
IRQ=9
INTR=9
Flags={Polarity=active-lo, Trigger=level}

Type=Local NMI
ACPI CPU=0
LINT Pin=1
Flags={Polarity=active-hi, Trigger=edge}

Type=Local NMI
ACPI CPU=1
LINT Pin=1
Flags={Polarity=active-hi, Trigger=edge}
 */

Since I don't know anything about ACPI, this doesn't say too much to
me.  Suggestions welcome.  If the APIC section is the MADT, it looks
as if we should update the docco.

Greg
-- 
See complete headers for address and phone numbers.


pgpd4k8dxjan9.pgp
Description: PGP signature

Re: Problems with AMD64 and 8 GB RAM?

[Greg 'groggy' Lehey]

On Thursday, 31 March 2005 at  0:00:22 -0600, Jon Noack wrote:
 On 03/30/05 23:49, Greg 'groggy' Lehey wrote:
 Here's the complete output of acpidump -t, anyway:

 snip acpidump output

 Since I don't know anything about ACPI, this doesn't say too much to
 me.  Suggestions welcome.  If the APIC section is the MADT, it looks
 as if we should update the docco.

 My limited research (as in, Google) shows that the MADT was defined as
 part of ACPI 2.0:
 http://www.microsoft.com/whdc/system/platform/64bit/IA64_ACPI.mspx

Thanks for the link.

 According to your previous link the motherboard specs, it supports
 both ACPI 1.0A and 2.0.  Perhaps there is a BIOS knob to toggle
 between the two?

I've taken a look, but I can't find anything.

Greg
--
See complete headers for address and phone numbers.


pgpF5N94haxLL.pgp
Description: PGP signature

Re: Problems with AMD64 and 8 GB RAM?

[Greg 'groggy' Lehey]

On Wednesday, 30 March 2005 at 16:04:44 -0700, Scott Long wrote:
 Greg 'groggy' Lehey wrote:
 On Wednesday, 30 March 2005 at 15:30:37 -0700, Scott Long wrote:

 Greg 'groggy' Lehey wrote:

 I've recently acquired an AMD64 box ...

 What's unstable?  ... The amd64 5.4-PRERELEASE kernel just
 hangs/freezes.

 5.3-RELEASE has a lot of problems with 4GB due to busdma issues.
 Those should no longer be an issue in RELENG_5, including 5.4-PRE.

 They appear to be.

 I don't understand what you mean here.

As I said above (and trimmed for convenience), this problem occurs on
5.4-PRERELEASE as of yesterday morning.  The dmesg shows that too.

 As I described, it doesn't appear to be the drivers.

 I don't see how you proved or disproved this.

Shall I resend the original message?  It seems independent of any
particular driver.  That's not proof, of course, but I didn't claim it
was.

Greg
--
See complete headers for address and phone numbers.


pgppvFZmjt3W8.pgp
Description: PGP signature

Re: Problems with AMD64 and 8 GB RAM?

[Greg 'groggy' Lehey]

On Wednesday, 30 March 2005 at 16:01:14 -0700, Scott Long wrote:
 Greg 'groggy' Lehey wrote:
 On Wednesday, 30 March 2005 at 14:35:46 -0800, Steve Kargl wrote:

 On Thu, Mar 31, 2005 at 07:54:39AM +0930, Greg 'groggy' Lehey wrote:

 None of these problems occur when I use 4 GB memory.  About the only
 strangeness, which seems to come from the BIOS, is that it recognizes
 only 3.5 GB.  If I put all DIMMS in, it recognizes the full 8 GB
 memory.

 I had 4 bad out of 12 tested where the DIMMs were Crucial PC2700 2GB
 Reg. ECC DIMMs.

 OK, this makes sense.  It might also explain why the 4 GB
 configuration only recognizes 3.5 GB.

 No, and I'm going to make this an FAQ and post it in a very obvious
 place, since 4+ GB is so easy to get and people don't seem to understand
 the PC architecture very well.

That's not easy to understand when it's barely documented.  Thanks for
the info: it helps a lot.

This may still be a hint, though: that memory hole doesn't show up
during a boot with 8 GB RAM.  How come?  Is the system trying to map
RAM over the PCI hole?

It looks as if I should get a verbose boot listing with 8 GB.  It'll
be a couple of hours before I find time to reboot this machine.  In
the meantime, there's a verbose boot with 4 GB at
http://www.lemis.com/grog/Images/20050331/obelix-dmesg.  I'm told it
shows a number of strange things, including incorrect reporting of
on-chip cache sizes.

Greg
--
See complete headers for address and phone numbers.


pgpqVG3rp0uyU.pgp
Description: PGP signature

Re: Problems with AMD64 and 8 GB RAM?

[Greg 'groggy' Lehey]

On Wednesday, 30 March 2005 at 14:57:15 -0800, Steve Kargl wrote:
 On Thu, Mar 31, 2005 at 08:14:45AM +0930, Greg 'groggy' Lehey wrote:
 On Wednesday, 30 March 2005 at 14:35:46 -0800, Steve Kargl wrote:
 On Thu, Mar 31, 2005 at 07:54:39AM +0930, Greg 'groggy' Lehey wrote:
 None of these problems occur when I use 4 GB memory.  About the only
 strangeness, which seems to come from the BIOS, is that it recognizes
 only 3.5 GB.  If I put all DIMMS in, it recognizes the full 8 GB
 memory.

 I realize that this isn't enough to diagnose the problem.  The reason
 for this message now is to ask:

 3.  Where should I look next?

 Have you run sysutils/memtest86 with the 8 GB?

 Heh.  Difficult when the system doesn't run.

 That's what happens when 1 of 8 (1 of 4?) DIMM is bad :-)

I've booted with the other 2 DIMMs now (I have 4 2 GB DIMMs, all the
MB will hold).  No problems.  See my last reply to Scott: I'm
wondering if the system is ignoring the PCI hole.

Greg
--
See complete headers for address and phone numbers.


pgpoGoHsF272S.pgp
Description: PGP signature

Re: Problems with AMD64 and 8 GB RAM?

[Greg 'groggy' Lehey]

[Format recovered--see http://www.lemis.com/email/email-format.html]

[gratuitous empty lines removed]

On Wednesday, 30 March 2005 at 16:23:34 -0700, Scott Long wrote:
 Greg 'groggy' Lehey wrote:
 On Wednesday, 30 March 2005 at 16:04:44 -0700, Scott Long wrote:
 Greg 'groggy' Lehey wrote:
 On Wednesday, 30 March 2005 at 15:30:37 -0700, Scott Long wrote:
 Greg 'groggy' Lehey wrote:
 I've recently acquired an AMD64 box ...

 What's unstable?  ... The amd64 5.4-PRERELEASE kernel just
 hangs/freezes.

 5.3-RELEASE has a lot of problems with 4GB due to busdma issues.
 Those should no longer be an issue in RELENG_5, including 5.4-PRE.

 They appear to be.

 I don't understand what you mean here.

 As I said above (and trimmed for convenience), this problem occurs on
 5.4-PRERELEASE as of yesterday morning.  The dmesg shows that too.

 And you're certain that it's due to the same busdma issues that I
 was describing?

No.

 I must have missed the evidence that you use to support this.

I didn't give any.  It appears that I misunderstood what you were
saying.

 As I described, it doesn't appear to be the drivers.

 I don't see how you proved or disproved this.

 Shall I resend the original message?  It seems independent of any
 particular driver.  That's not proof, of course, but I didn't claim it
 was.

 Again, I must have missed the part where you investigated the drivers
 that apply to your particular system.

The description is still there.

 I highly doubt that they apply to every 8GB Opteron system available
 on the market.

I never suggested that they did.  There's every reason to believe that
it's something to do with this particular motherboard, but that
doesn't mean that FreeBSD is blameless.

Greg
--
When replying to this message, please take care not to mutilate the
original text.  
For more information, see http://www.lemis.com/email.html
See complete headers for address and phone numbers.


pgp0VFy61yFYS.pgp
Description: PGP signature

Re: Problems with AMD64 and 8 GB RAM?

[Greg 'groggy' Lehey]

On Wednesday, 30 March 2005 at 15:25:37 -0800, Peter Wemm wrote:
 On Wednesday 30 March 2005 03:09 pm, Greg 'groggy' Lehey wrote:
 On Wednesday, 30 March 2005 at 16:04:44 -0700, Scott Long wrote:
 Greg 'groggy' Lehey wrote:
 As I described, it doesn't appear to be the drivers.

 I don't see how you proved or disproved this.

 Shall I resend the original message?  It seems independent of any
 particular driver.  That's not proof, of course, but I didn't claim
 it was.

 Greg:  The busdma problems from 5.3-RELEASE are fixed.  That doesn't
 mean that there are no *other* problems.  Scott is saying the old
 busdma bug shouldn't be affecting 5.4-PRE, and he's correct.

Yes, now I understand.

 Most likely, something else is happening, eg: you're running out of KVM
 or something silly like that.  I know we're right on the brink at 8GB.
 The layout of the devices may be just enough to tip it over the edge.

Yes, this seems reasonable.  Where should I look next?  I'm currently
rebuilding world and will attempt a verbose boot via serial console
when it's done.  Anything else I should try?

Greg
--
See complete headers for address and phone numbers.


pgpV3oeVrvAB0.pgp
Description: PGP signature

Re: Creating a striped set of mirrors using gvinum

[Greg 'groggy' Lehey]

On Saturday, 19 March 2005 at 17:58:06 -0500, Sven Willenberger wrote:
 I am hoping someone has found a way to create this type of raid set
 using [g]vinum. I see that it is a trivial matter to create a mirror of
 2 striped sets but I have not seen a way to create a stripe set out of
 multiple mirrored sets (e.g. stripe across 3 sets of mirrors). Has
 anyone managed to implement this and, if so, what does your
 configuration file look like?

No, it doesn't work that way.

 If not, could this be added as a feature request for gvinum?

To do this you should enter a PR.  It would help if you could explain
why it's preferable to mirrored plexes.

Greg
--
See complete headers for address and phone numbers.


pgprB1LH41PgL.pgp
Description: PGP signature

Re: vinum.autostart problem

[Greg 'groggy' Lehey]

On Tuesday,  1 February 2005 at 16:36:26 +0900, FUJITA Kazutoshi wrote:
 Hi,

 I'm using recent 5-STABLE,
 and try to mirror root partition with vinum.

 my /boot/loader.conf is below

 vinum_load=YES
 vinum.autostart=YES

 But I got following message when boot

 ...
 vinum: loaded
 vinum: no drives found
 Mounting root from ufs:/dev/vinum/root
 setrootbyname failed
 ffs_mountroot: can't find rootvp
 Root mount failed: 6
 ...

 I think vinum is not auto-started.

 Any suggestion?

http://www.vinumvm.org/vinum/how-to-debug.html

Greg
--
See complete headers for address and phone numbers.


pgpQqFNKUGozS.pgp
Description: PGP signature

Re: Vinum causes server to crash/reboot ...

[Greg 'groggy' Lehey]

On Sunday, 30 January 2005 at 14:28:47 -0400, Marc G. Fournier wrote:

 Just got burnt on one of my machines, where I was looking to reconfigure
 my RAID drive ... right now, its down :(

 I cleared everything off the drive, unmount'd it and then did a 'vinum
 resetconfig' ... that all worked great, but as soon as I did a 'vinum
 create file' to recreate it, the server crashed/rebooted ...

Where's the dump?

Based on the information supplied, there's little anybody can do.  I'd
guess it won't show up again either.  If it does, please supply the
information requested in the man page or at
http://www.vinumvm.org/vinum/how-to-debug.html.

Greg
--
See complete headers for address and phone numbers.


pgpKz1aPKwJfM.pgp
Description: PGP signature

Re: Vinum Raid5 Init question

[Greg 'groggy' Lehey]

On Tuesday, 18 January 2005 at  8:33:03 -0600, Craig Boston wrote:
 On Tue, Jan 18, 2005 at 12:21:59PM +0100, David Elsing wrote:
 Quote from the manual of the 4th example of the chapter HOW TO SET UP 
 VINUM:
 In addition, the volume specification includes the keyword
 setupstate, which ensures that all plexes are up after creation.

Where does it tell you to do that?  From the man page:

 setstate state [volume | plex | subdisk | drive]
 setstate sets the state of the specified objects to the specified
 state.  This bypasses the usual consistency mechanism of vinum
 and should be used only for recovery purposes.  It is possible to
 crash the system by incorrect use of this command.

 But a couple of weeks later I read the following in the manual:

 Note that you must use the init command with RAID-5 plexes: otherwise
 extreme data corruption will result if one subdisk fails.

 Yes, this particular gotcha bit me a while back and I lost quite a bit
 of data (my fault for not having good backups) due to it.  IMO, I still
 consider it a documentation bug though.  That particular bit is buried
 in a command reference section rather than being in bold in the HOW TO
 guide.

Yes, it could be clearer.  Put in a PR.

 I read this to my horror after I filled the volume with data. You'll
 probably noticed I didn't init my volume. The disks are in good
 condition. The volume is almost filled to the maximum capacity. So a
 backup is a bit difficult due to the size of it. Are there any other
 options? If one disks fails, do I still get corrupted data?

 Yes, if one disk fails for any reason, every third sector will be
 garbage and it's unlikely you'll be able to recover anything useful from
 it.

 I would highly recommend backing up whatever is critically important to
 you asap.  If you like living dangerously and all the drives are in good
 health, the parity data can be (theoretically) repaired with the vinum
 rebuildparity command, but do so at your own risk...  That did allow me
 to recover a couple of my partitions that hadn't been trashed yet.

This should work.  Make sure the volume is not be mounted when you do so.

 Also, if a good disk gets marked as down somehow before you can
 correct this, whatever you do, do NOT issue a vinum start command
 on it.  In the current state of the array, that would be destructive
 and irreversible.

No, that's the correct way to do it.

 That's what happened to me: ATA timeout caused one of the drives to
 temporarily detach, corrupt filesystems caused a panic.  If this
 happens, you're better off using setstate to force it to up, as
 wrong as that would normally be.

I can't recall seeing a problem report.

Greg
--
See complete headers for address and phone numbers.


pgpwjAvca7PjY.pgp
Description: PGP signature

Re: FreeBSD 5.3 and vinum upgrade #2

[Greg 'groggy' Lehey]

On Tuesday, 21 December 2004 at 13:42:40 -0500, Paul Mather wrote:
 On Tue, 2004-12-21 at 19:00 +0100, Nikolaj Hansen wrote:

 I also do not think it belongs in the stable branch just yet :-D Any hope
 of you fixing the old vinum in the 5.3 branch or is it a wait for the 5.4?

 AFAIK, the old vinum will *never* be fixed in the 5.3 branch or any
 subsequent branch, so don't hold your breath for 5.4.  The fact that it
 wasn't being fully GEOM-ified (and hence was dying from neglect in 5.x)
 was the whole reason for Lukas to embark on geom_vinum.

Well, actually the original intention was that Lukas would geomify
Vinum.  I think it was a mistake to start again.  We now have an old,
out of date version of Vinum, and a new, incomplete version gvinum.

Greg
--
See complete headers for address and phone numbers.


pgpksSM1opPRx.pgp
Description: PGP signature

Re: SOLVVED vinum crashes the Box... WRONG POSTING

[Greg 'groggy' Lehey]

On Thursday,  9 December 2004 at 14:52:14 +0100, Michael Schuh wrote:
 Hello,

 sorry for my wrong posting, it was late at night and i have *not*
 doublechecked my configuration.

If you get a panic, it's not your fault.  You shouldn't be able to
panic the machine with an invalid configuration.  It's still worth
finding out what happened.

Greg
--
See complete headers for address and phone numbers.


pgpfOdFRYobfU.pgp
Description: PGP signature

Re: crashdumps not working

[Greg 'groggy' Lehey]

On Wednesday,  8 December 2004 at 11:20:34 +, Robert Watson wrote:

 On Tue, 7 Dec 2004, Michael Nottebrock wrote:

 I recently enabled SW_WATCHDOG in my kernel, but when watchdog triggers
 a panic, no crashdump is taken although dumps are enabled. What could be
 causing this?

 If you drop to the debugger by using the debug.kdb.enter sysctl, and
 do call doadump, followed by a reset, does a dump get generated
 successfully?  I.e., are they completely broken on your system, or
 is this somehow a property of the particular hang you're seeing.
 (Do the above with caution and in a situation where you don't mind
 fscking, needless to say).

FWIW, I've found that the only way to dump a -CURRENT system in the
last six months or so has been to 'call doadump'.  There are a number
of other problems, including getting gdb over firewire to work at all,
but I won't find time to look at them for the next few weeks.

Greg
--
See complete headers for address and phone numbers.


pgp7cj9GtXUHg.pgp
Description: PGP signature

Re: vinum / 5.3

[Greg 'groggy' Lehey]

On Tuesday, 16 November 2004 at 12:50:33 -0500, Sam wrote:
 Hello all,

 I'm trying to create a stripe over 10 disks and am hitting
 a 32-bit wall in the volume size.  The plex properly sees
 the full 3726 GB, but the volume shaves off the 32nd bit
 and only sees 1678 GB.

 Usual for vinum?

No.  Could be some of the breakage introduced by changes to the kernel
interfaces.

Greg
--
See complete headers for address and phone numbers.


pgpRA5Bw1H1iq.pgp
Description: PGP signature

Re: freebsd 5.3 have any problem with vinum ?

[Greg 'groggy' Lehey]

On Monday,  1 November 2004 at 10:05:16 +1100, Carl Makin wrote:
 Greg 'groggy' Lehey wrote:

 On Monday, 25 October 2004 at 14:21:33 -0600, secmgr wrote:



 It's beginning to look like that's a bad idea.  Lukas is
 (understandably) working only on gvinum, and since I know it's nearly
 there, I'm not going to do any further work on Vinum in FreeBSD 5.
 Given the problems, I'd suggest that we yank it.

 Do you want to yank it in 5 or 6-CURRENT?

Well, it's been yanked in -CURRENT.  My understanding was that it
should also be yanked in 5.x: a number of changes have been made that
effectively break old Vinum,

 There are a *lot* of people using vinum and yanking it in 5-STABLE
 would force us all to use the 5.3 security branch until gvinum
 caught up.

Yes, I'm afraid so.  I can think of better ways that this could have
been managed, but I haven't had much influence.

Greg
--
See complete headers for address and phone numbers.


pgpaGayfYyURY.pgp
Description: PGP signature

Re: freebsd 5.3 have any problem with vinum ?

[Greg 'groggy' Lehey]

On Friday, 29 October 2004 at 14:20:40 -0600, secmgr wrote:
 Greg 'groggy' Lehey wrote:

 A bit of background: we know that 'gvinum' will replace Vinum; the
 original intention had been to do it seamlessly, but for various
 reasons that did happen.  Then we decided that we should leave them
 both in the tree until gvinum had the full functionality of Vinum.
 It's beginning to look like that's a bad idea.  Lukas is
 (understandably) working only on gvinum, and since I know it's nearly
 there, I'm not going to do any further work on Vinum in FreeBSD 5.
 Given the problems, I'd suggest that we yank it.  I'm copying the
 release engineering team.  Re, what do you think?

 Not that I've got a lot of say in the matter, but I would vote for this
 too. (along with migration info in the release notes).

I've spoken to Scott Long on the subject, and it looks likely that
we'll do something like this; but re haven't made a final decision.

 There are also some minor changes needed to the docs on vinumvm.org
 for gvinum/newfs (5.3) to correct new paths and switches.

So far, vinumvm.org has no information about gvinum at all.  Hopefully
that will change at some time.

Greg
--
See complete headers for address and phone numbers
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: freebsd 5.3 have any problem with vinum ?

[Greg 'groggy' Lehey]

On Monday, 25 October 2004 at 14:21:33 -0600, secmgr wrote:
 Andrew Konstantinov wrote:

 On Mon, 2004-10-25 at 05:55, Oliver Torres Delgado wrote:


 I have freebsd 5.3 rc1 installed perfectly, i configure vinum with the
 handbook and all work perfect
 but when try run vinum with rc.conf there display the error:

 panic: unmount: dangling vnode
 ...

 Just like me, you should have checked the mailing list archive first.
 Here is a nice solution:
 http://lists.freebsd.org/pipermail/freebsd-current/2004-August/035547.html

 thanks, I appreciate the pointer.  That being said, if this is a KNOWN
 problem (as far back as August) how come no mention in either the
 release notes OR errata.

Good question.

 I like and use FreeBSD for it's stability, but at this point in
 time, I've got broken vinum-classic (with workarounds) raid5 in 4.10
 and raid 1 in 5.3-stable.  Both of these installed per current
 documentation. I haven't logged bug reports becasue it seems like
 everything is moving to gvinum, and they'd probably just end up
 closed out as FINV

A bit of background: we know that 'gvinum' will replace Vinum; the
original intention had been to do it seamlessly, but for various
reasons that did happen.  Then we decided that we should leave them
both in the tree until gvinum had the full functionality of Vinum.
It's beginning to look like that's a bad idea.  Lukas is
(understandably) working only on gvinum, and since I know it's nearly
there, I'm not going to do any further work on Vinum in FreeBSD 5.
Given the problems, I'd suggest that we yank it.  I'm copying the
release engineering team.  Re, what do you think?

Greg
--
See complete headers for address and phone numbers
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Serious bug in vinum?

[Greg 'groggy' Lehey]

On Tuesday, 30 March 2004 at 14:37:00 +0200, Lukas Ertl wrote:
 On Fri, 26 Mar 2004, Joao Carlos Mendes Luis wrote:

 I think this should be like:

 if (plex-state  plex_corrupt) {  /* something accessible, 
 */

 Or, in other words, volume state is up only if plex state is degraded
 or better.

 You are right, this is a bug,

No, see my reply.

 The correct solution, of course, is to check if the data is valid
 before changing the volume state, but turn might turn out to be a
 very complex check.

Well, the minimum correct solution is to return an error if somebody
tries to access the inaccessible part of the volume.  That should
happen, and I'm confused that it doesn't appear to be doing so in this
case.

On Tuesday, 30 March 2004 at 11:07:55 -0300, Joo Carlos Mendes Lus wrote:
 Greg 'groggy' Lehey wrote:
 On Tuesday, 30 March 2004 at  0:32:38 -0300, Joo Carlos Mendes Lus wrote:

 Basically, this is a feature and not a bug.  A plex that is corrupt is
 still partially accessible, so we should allow access to it.  If you
 have two striped plexes both striped between two disks, with the same
 stripe size, and one plex starts on the first drive, and the other on
 the second, and one drive dies, then each plex will lose half of its
 data, every second stripe.  But the volume will be completely
 accessible.

 A good idea if you have both stripe and mirror, to avoid discarding the
 whole disk.  But, IMHO, if some part of the disk is inacessible, the volume
 should go down, and IFF the operator wants to try recovery, should use the
 setstate command.  This is the safe state.

setstate is not safe.  It bypasses a lot of consistency checking.

One possibility would be: 

1.  Based on the plex states, check if all of the volume is still
accessible.
2.  If not, take the volume into a flaky state.  
3.  *Somehow* ensure that the volume can't be accessed again as a file
system until it has been remounted.
4.  Refuse to remount the file system without the -f option.

The last two are outside the scope of Vinum, of course.

Discussion?
--
Note: I discard all HTML mail unseen.
Finger [EMAIL PROTECTED] for PGP public key.
See complete headers for address and phone numbers.


pgp0.pgp
Description: PGP signature

Re: mismatching vinum configurations

[Greg 'groggy' Lehey]

On Sunday, 20 July 2003 at 20:27:00 +0200, Joan Picanyol i Puig wrote:
 Hi,

 I had a power failure, and the on-disk configuration for vinum went
 bizarre. The logs read from disks are at http://biaix.org/pk/debug/
 (log.$DEVICE files). 

They're not much help, and a lot of the files are inaccessible.  The
output of 'vinum dumpconfig' would be easier.

 The logs in da0 (barracuda) are the ones obviously wrong, I'm pretty
 sure the others are ok. Is this a 'virtually' dead drive?

It's not a hardware problem, if that's what you mean.

 Can I force vinum to use the other's drive configuration?

Yes.

 What's the less traumatic way to recover the data?

I've never tried this, but a thing you could do is:

 vinum - setdaemon 4(turn off config updates)
 vinum - read /dev/ad0s1d   (or another drive with valid config)
 vinum - start

This could bring back your entire configuration.  If anything goes
wrong, it's not serious, because the config updates are turned off.

Why do you have two drives on each SCSI disk?

 Most of the data is mirrored over da0  da1, but I can't start any of
 the mirrored volumes (I get 'Drive is down') What should I do to access
 the mirrored volumes?

If 'start' above doesn't work, you can try running a Vinum config file
like:

  drive barracuda device /dev/da0s1f

Let me know how it works out.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Re: vinum performance

[Greg 'groggy' Lehey]

On Sunday, 30 March 2003 at 14:08:24 +0200, Dag-Erling Smrgrav wrote:
 Lukas Ertl [EMAIL PROTECTED] writes:
 Anyone has an idea what's going wrong here? (Apart from me doing bullsh*t
 benchmarking :-) .)

 Just out of curiosity, try again with prime stripe sizes (31, 61, 127,
 257, 509) or at least odd ones (31, 63, 127, 255, 511).

If you're going to do this kind of test, make sure it's a multiple of
the UFS block size, but not a power of 2.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Re: vinum performance

[Greg 'groggy' Lehey]

On Sunday, 30 March 2003 at 16:30:17 +0200, Dag-Erling Smrgrav wrote:
 Anti [EMAIL PROTECTED] writes:
 try benchmarking ccd as well to see how it compares? and try some big stripe
 sizes (4093, 8191, 12281)?

 I believe Greg showed in his USENIX paper on Vinum that large stripe
 sizes aren't preferable to small ones.  I may misremember though.

You misremember.  I said that large stripe sizes *are* preferable.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Re: vinum performance

[Greg 'groggy' Lehey]

On Sunday, 30 March 2003 at 18:10:07 +0200, Dag-Erling Smrgrav wrote:
 Lukas Ertl [EMAIL PROTECTED] writes:
 I'm currently testing with prime stripe sizes, but it doesn't seem to
 help. I additionally added options AHC_ALLOW_MEMIO to the kernel, and it
 has raised write performance in the single-disk case (although I'm not
 happy with that one either; I expected a disk on a U160 controller to pump
 out more than ~65MB/s).

 Does the data sheet for your disk indicate that it can in fact write
 much faster than that?  The speed at which data is actually written
 to the media is much lower than the bus speed - the bus speed *has*
 to be higher to accomodate multiple devices.

You're touching on one of the real issues here.  For optimum
transfers, a plex needs large stripes.  If you're only doing one
transfer at a time (like bonnie does), you'll just pick on individual
disks alternately, so the performance can't be much better than a
single disk.  Do a large number of simultaneous transfers and it will
be a different story.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Re: Sony Cybershot should be in hardware notes (supported by umass)

[Greg 'groggy' Lehey]

On Tuesday, 11 March 2003 at  0:36:58 +0100, Joan Picanyol i Puig wrote:
 * Doug Barton [EMAIL PROTECTED] [20030311 00:14]:
 I think it's already covered by the statement Owing to the generic
 nature of most USB devices, with some exceptions any device of a given
 class will be supported, even if not explicitly listed here.
 I can't sync my Palm m500 through USB even though the release notes say
 it's supported :(and yeah, it's detected, but of no use :()
 I'm sorry to say I don't have a solution for you, but I'm curious. What
 are you syncing it to, and what software are you using? I have a palm, and
 the only useful sync stuff I've found is all windows based.

 Ideally, I'd sync it against Evolution through pilot-link, but it
 doesn't work. Searching the pilot-link archives will show you that the
 people there think it's FreeBSD's fault...

There's a bug somewhere which stops pilot-link working with USB.  I've
been talking to the author about it, and he's not very motivated to
fix it, particularly because we can't exclude the possibility that
the bug is in the USB stack.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Re: bootvinum and multiple pc-partitions

[Greg 'groggy' Lehey]

On Thursday, 19 December 2002 at 21:33:50 -0600, Hari Bhaskaran wrote:
 Hi,

 I am having a problem using the bootvinum script. It seems to
 consider only the first slice (PC-partition) of the root
 spindle. I have put all vinum related files
 here http://65.189.239.65/vinum_files/

 I have two (1 when you consider vinum) 120G dsks that need to be
 split onto more than 12 fs's. I created two PC-partitions 60G
 each to get over the a to h partition limit.

I must confess to being a bit baffled.  You seem to be confused on a
number of points.  Certainly there's never any reason to put more than
one Vinum volume on a physical disk.

I've taken a look at http://65.189.239.65/vinum_files/bootvinum/ (what
happened to your DNS?), and find:

bootvinum

  I've never seen this before.  I don't do perl, but it doesn't seem
  like it does anything useful.

create.ThruBank

  drive ThruBank device /dev/ad1s2h

It's not clear what use this is by itself.

create.YouCrazy

  drive YouCrazy device /dev/ad0s1h
  volume fs3
plex name fs3.p0 org concat volume fs3
  sd name fs3.p0.s0 drive YouCrazy plex fs3.p0 len 88066257s driveoffset 16777481s
  volume var
plex name var.p0 org concat volume var
  sd name var.p0.s0 drive YouCrazy plex var.p0 len 6291456s driveoffset 265s
  volume var/tmp
plex name var/tmp.p0 org concat volume var/tmp
  sd name var/tmp.p0.s0 drive YouCrazy plex var/tmp.p0 len 2097152s driveoffset 
6291721s
  volume var/log
plex name var/log.p0 org concat volume var/log
  sd name var/log.p0.s0 drive YouCrazy plex var/log.p0 len 2097152s driveoffset 
8388873s
  volume tmp
plex name tmp.p0 org concat volume tmp
  sd name tmp.p0.s0 drive YouCrazy plex tmp.p0 len 6291456s driveoffset 10486025s

You shouldn't be specifying explicit drive offsets.  It's also not a
good idea to specify names for pleses or subdisks.  In addition,
you've detected a bug in the Vinum parser: you can't have / characters
in object names.

create.UpWindow

  drive UpWindow device /dev/ad1s1h
plex name fs3.p1 org concat volume fs3
  sd name fs3.p1.s0 drive UpWindow plex fs3.p1 len 88066257s driveoffset 16777481s
plex name var.p1 org concat volume var
  sd name var.p1.s0 drive UpWindow plex var.p1 len 6291456s driveoffset 265s
plex name var/tmp.p1 org concat volume var/tmp
  sd name var/tmp.p1.s0 drive UpWindow plex var/tmp.p1 len 2097152s driveoffset 
6291721s
plex name var/log.p1 org concat volume var/log
  sd name var/log.p1.s0 drive UpWindow plex var/log.p1 len 2097152s driveoffset 
8388873s
plex name tmp.p1 org concat volume tmp
  sd name tmp.p1.s0 drive UpWindow plex tmp.p1 len 6291456s driveoffset 10486025s

You're creating a lot of unattached plexes here.  Why?

disklabel.ad0s1
disklabel.ad0s1.b4vinum
disklabel.ad1s1
disklabel.ad1s1.b4vinum
disklabel.ad1s2
disklabel.ad1s2.b4vinum

These look like normal enough volume labels, though it's not clear why
you have ad1s2.

 I also have a different kind of problem. I was trying to find out
 how to modify bootvinum script to skip certain partitions when it
 processes /etc/fstab to create /etc/fstab.vinum I have two disks,
 and I want certain critical partitions mirrored on both, but I
 want each disk to have its own partitions made out of remaining
 space in each.

 I realise this may a little too much for the bootvinum perl script,
 but I just wanted to find out before I modify anything or try the
 manual approach.

I don't know why you're going to so much trouble when it's *much*
easier to do it manually.  I can't help you with bootvinum, beyond to
suggest not to use it.

Greg
--
See complete headers for address and phone numbers

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

Re: bootvinum and multiple pc-partitions

[Greg 'groggy' Lehey]

On Thursday, 19 December 2002 at 22:34:57 -0600, Hari Bhaskaran wrote:
 On Fri, Dec 20, 2002 at 02:26:34PM +1030, Greg 'groggy' Lehey wrote:

 I must confess to being a bit baffled.  You seem to be confused on a
 number of points.  Certainly there's never any reason to put more than
 one Vinum volume on a physical disk.

 Are you asking where the second hard-drive is attached to the same
 cable?

No.

 Yes, one is the master, other is slave. I guess this could be
 problem if the master is dead. But they are still two separate
 harddisks.

/dev/ad1s1 and /dev/ad1s2 are both the same disk.

 I was following the article
 http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vinum/index.html

 After a search, I found some other articles
 http://org.netbase.org/vinum-mirrored.html. May be I will try to
 follow this one.

 Here is a summary of what I was trying to do:-

 I began a normal FreeBSD install with a single 120G disk. I needed the
 following partitions

 /   1G
 swap6G  (may be a bit too much!)
 /var3G
 /var/log  1G
 /var/tmp  1G
 /tmp3G
 /usr3G
 /usr/home 3G
 /fs12G
 /fs220G
 /fs340G
 /fs431G

 Since I don't seem to be able to create more than 7 or so FreeBSD
 fs partitions per PC-partition, I split the PC-partition into two.
 That's why I have ad0s1  ad0s2.

You don't need more than one partition.

 Now I need the whole disk mirrored on the second 120G disk.  I may
 not want to mirror /fs4, that's all.

 create.ThruBank
 create.YouCrazy

 There are default files (I didn't care to change the default names)
 generated by bootvinum.

 You shouldn't be specifying explicit drive offsets.  It's also not a
 good idea to specify names for pleses or subdisks.  In addition,
 you've detected a bug in the Vinum parser: you can't have / characters
 in object names.
 [snip]

 You're creating a lot of unattached plexes here.  Why?

 I just ran the script. So please ignore these.

 I don't know why you're going to so much trouble when it's *much*
 easier to do it manually.  I can't help you with bootvinum, beyond
 to suggest not to use it.

I can only repeat that.

Greg
--
See complete headers for address and phone numbers

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

Re: Recreating vinum device ...

[Greg 'groggy' Lehey]

On Thursday, 28 November 2002 at 16:26:09 -0400, Marc G. Fournier wrote:
 On Thu, 28 Nov 2002, Marc G. Fournier wrote:


 Okay, I need to confirm this before I run it, cause if it doesn't work,
 I'm royally screwed ...

 The old server, the drives on the controller I couldn't bring up had a
 vinum RAID5 device on it ... I have the original config file that I used
 to create that ...

 If I run 'vinum create -f config file' and don't run newfs, will I still
 end up toasting the RAID5 array, or is this safe?  What happens if I
 inadvertently reversed the drives?  Is there some way that I need to be
 doing this that I'm not seein gin the vinum man page?

 Got it *wipe brow* Kudos to he who developed vinum, brow is still a
 wee damp, but the man page is great and figured out that create is
 not the way to go :)

JOOI, what happened, and how did you fix it?

Greg
--
See complete headers for address and phone numbers

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

Re: vinum + 4.7 release = page fault

[Greg 'groggy' Lehey]

On Thursday, 24 October 2002 at 11:12:11 +0400, Eugene Mitrofanov wrote:
 On 23-Oct-2002 Coleman Kane wrote:
 I recently installed 4.7-R on a machine that runs vinum and have had no
 trouble with my system. I also have run vinum start multiple times and
 all it seems to do is creade another md device (md?: malloc disk).
 I have not experienced the page fault or kernel crash issue you are
 describing. I am using a vinum mirror over two 4-GB drives.

 I have this problem on two machines with 4.7-R. One of them has two 17Gb
 SCSI disks and four RAID-1 vinum mirrors and another has one IDE drive
 with one RAID-1 mirror. I use this machine to reproduce the 'vinum start'
 problem. Both system are using the GENERIC 4.7-R kernel.

It depends on the geometries you use.  That's why I had such
difficulties in reproducing the problem.

Greg
--
See complete headers for address and phone numbers

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

Re: Brazil time zone file sets DST incorrectly

[Greg 'groggy' Lehey]

On Thursday, 17 October 2002 at  9:35:40 +1000, Christopher Vance wrote:
 On Wed, Oct 16, 2002 at 04:31:57PM -0300, Vitor de Matos Carvalho wrote:
 Detected the DST problem, because the Security Team did not notify? It will
 be that this error for being of did not enteresse of administrators of
 servers who twirl in the E.U.A do not deserve that he is notified? It did
 not want that it made mention to my name, nor that patch was used mine, only
 that was communicated to all of the occurrence. The correction already was
 made in default branch, now goes to wait for more how much time it goes for
 RELENG_4

 The timezone code, and more particularly the tables used to drive it,
 comes from somewhere else.  You were told who and where to send your
 correction.  Did you do this?

Yes, he did, several times.  The issue here is that we don't maintain
our own time zone files (time for non-FreeBSD users should be the same
as time for FreeBSD users).  Instead, we import the time zone files
from an external source.  This was done yesterday:

--- southamerica4 Apr 2002 18:16:19 -   1.19
+++ southamerica16 Oct 2002 01:55:48 -  1.20
@@ -1,4 +1,4 @@
-# @(#)southamerica 7.43
+# @(#)southamerica 7.45
 
 # This data is by no means authoritative; if you think you know better,
 # go ahead and edit the file (and please send any changes to
@@ -174,7 +174,7 @@
 # Shanks also makes the following claims, which we haven't verified:
 # - Formosa switched to -3:00 on 1991-01-07.
 # - La Rioja and San Juan switched to -4:00 on 1991-03-01
-#   and then to 03:00 on 1991-05-07.
+#   and then to -3:00 on 1991-05-07.
 # - Misiones switched to -3:00 on 1990-12-29.
 # - Chaco switched to -3:00 on 1991-01-04.
 # - San Luis switched to -4:00 on 1990-03-14, then to -3:00 on 1990-10-15,
@@ -292,11 +292,28 @@
 # http://pcdsh01.on.br/Fusbr.htm
 # http://pcdsh01.on.br/Fusbrhv.htm
 
-# From Paul Eggert (2000-10-02):
-# The official decrees referenced below are taken from
+# From Celso Doria via David Madeo (2002-10-09):
+# The reason for the delay this year has to do with elections in Brazil.
+#
+# Unlike in the United States, elections in Brazil are 100% computerized and
+# the results are known almost immediately.  Yesterday, it was the first
+# round of the elections when 115 million Brazilians voted for President,
+# Governor, Senators, Federal Deputies, and State Deputies.  Nobody is
+# counting (or re-counting) votes anymore and we know there will be a second
+# round for the Presidency and also for some Governors.  The 2nd round will
+# take place on October 27th.
+#
+# The reason why the DST will only begin November 3rd is that the thousands
+# of electoral machines used cannot have their time changed, and since the
+# Constitution says the elections must begin at 8:00 AM and end at 5:00 PM,
+# the Government decided to postpone DST, instead of changing the Constitution
+# (maybe, for the next elections, it will be possible to change the clock)...
+
+# From Paul Eggert (2002-10-10):
+# The official decrees referenced below are mostly taken from
 # a href=http://pcdsh01.on.br/DecHV.html;
 # Decretos sobre o Horario de Verao no Brasil
-# /a (1999-10-04, in Portuguese).
+# /a (2001-09-20, in Portuguese).
 # The official site for all decrees, including those not related to time, is
 # a href=http://www.presidencia.gov.br/CCIVIL/decreto/principal_ano.htm;
 # Presidencia da Republica, Subchefia para Assuntos Juridicos, Decretos
@@ -421,15 +438,18 @@
 # repeals DST in SE, AL, PB, RN, CE, PI and MA, effective 2000-10-22 00:00.
 # Decree a href=http://pcdsh01.on.br/figuras/HV3916.gif;3,916/a
 # (2001-09-13) reestablishes DST in AL, CE, MA, PB, PE, PI, RN, SE.
+Rule   Brazil  20002001-   Oct Sun=8   0:00   1:00S
+Rule   Brazil  2001max -   Feb Sun=15  0:00   0   -
+# Decree 4,399 (2002-10-01) repeals DST in AL, CE, MA, PB, PE, PI, RN, SE.
+# a href=http://www.presidencia.gov.br/CCIVIL/decreto/2002/D4399.htm;/a
+Rule   Brazil  2002only-   Nov  3   0:00   1:00S
 #
+Rule   Brazil  2003max -   Oct Sun=8   0:00   1:00S
 # The latest decree listed above says that the following states observe DST:
-# AL, BA, CE, DF, ES, GO, MA, MG, MS, MT,
-# PB, PE, PI, PR, RJ, RN, RS, SC, SE, SP, TO.
+# BA, DF, ES, GO, MG, MS, MT, PR, RJ, RS, SC, SP, TO.

Note that these changes are not the same as Vitor's, and they contain
reasoning we haven't seen before.  About the only thing that hasn't
happened is closing the PR.  I'll see about getting that done.

Greg
--
See complete headers for address and phone numbers

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

Re: Compiling a New Kernel

[Greg 'groggy' Lehey]

On Saturday, 12 October 2002 at 10:32:09 +0930, Phil Kernick wrote:
 Aragon Gouveia wrote:
 Ideally you should build, install, and boot your new kernel before
 installing your new world. If your new kernel fails to boot for whatever
 reason, you can easily boot the old kernel and have a fully functional
 system again. If you installworld before verifying your new kernel, you
 could run into worse problems if your new kernel doesn't load and you
 have to boot the old kernel with your new world.

 The only problem that I have with this approach, is that I keep all of my
 source on a vinum raid-5 volume.  If I reboot before doing a make
 installworld, then there is always the possibility that with the new kernel
 and the old world I may not be able to mount the volume.  So I always
 shutdown but *not* reboot before doing the installworld.

I don't anticipate any problems with Vinum after an upgrade.  The
on-disk format has never changed, and though it's possible in the
future, I'd hope it would do so in a compatible manner.

Greg
--
See complete headers for address and phone numbers

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

Re: SMP Problems

[Greg 'groggy' Lehey]

On Sunday, 18 August 2002 at 13:51:54 -0700, Chern Lee wrote:
 I'm not sure where along the line I lost my second CPU, but I'm sure I had
 it 4.5.  Now, the second CPU is never detected.

 Dual Pentium III 600
 Intel L440GX motherboard w/ 440GX+ chipset

 This is a VA Linux machine.  Any ideas why I may have 'lost' my second
 CPU?

Did you build a kernel with SMP support?

Greg
--
See complete headers for address and phone numbers

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

Re: Hardware RAID vs vinum

[Greg 'groggy' Lehey]

On Wednesday, 29 May 2002 at  8:11:41 -0600, Scott Long wrote:
 On Wed, May 29, 2002 at 01:42:11PM +0930, Greg 'groggy' Lehey wrote:

 I'm sure that there are good reasons for small stripe sizes.  I don't
 believe that efficiency is one of them.  I think your problem is that
 you're looking at single-request latency.  That's usually not an
 issue, though it may impact copy performance.  As I said, though,
 that's not usually where you would use RAID-5.  The real issue is not
 so much latency as throughput.  I hope I've been able to make it more
 understandable.

 Greg,

 It is obvious that I have tread onto religious territory here, 

Not for me.  I've given you some very detailed arguments.  I also have
measurements which back them up.

 and as such there is probably little I can say to convince you of my
 points.

Well, you could start by trying.

 I think that we must then agree to disagree =-)

I'd much rather see some technical arguments from you.

Greg
--
See complete headers for address and phone numbers

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

Re: Hardware RAID vs vinum

[Greg 'groggy' Lehey]

On Wednesday, 29 May 2002 at 17:16:36 -0700, Matthew Dillon wrote:
 I am not going to take a stand on performance other then to say to
 both parties:  prove your points. 

Well, I thought I had done just that.  If you have any issues with my
claims, you're welcome to raise them.

 I personally believe that features and management
 characteristics are better comparison points between software
 and hardware RAID systems.  Performance is and always will be a
 moving target.

What I'm talking about is how to configure a system which gives you
the choice of stripe sizes.  That's orthogonal to the other issues.

Greg
--
See complete headers for address and phone numbers

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

Re: gdb doesn't work over NFS ?

[Greg 'groggy' Lehey]

On Thursday, 25 April 2002 at 23:18:34 +1000, Darren Reed wrote:

 Can someone explain why when I use gdb under FreeBSD 4.5, I cannot open
 files on an NFS partition that I can outside of gdb ?

 ie. i can do:

 $ wc Makefile

 but I cannot do:

 $ gdb `which wc`
 (gdb) run Makefile

 and if I do, I get:
 wc: Makefile: open: No such file or directory

No, I can't explain this, but I'd guess that you're looking in the
wrong place.  It works fine here:

  $ df .
  Filesystem1048576-blocks UsedAvail Capacity  Mounted on
  wantadilla:/home9722 6477 246772%/wantadilla/home
  $ wc Makefile
  10264858   38315 Makefile
  $ gdb `which wc`
  GNU gdb 4.18
  Copyright 1998 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain conditions.
  Type show copying to see the conditions.
  There is absolutely no warranty for GDB.  Type show warranty for details.
  This GDB was configured as i386-unknown-freebsd...(no debugging symbols found)...
  (gdb) run Makefile
  Starting program: /usr/bin/wc Makefile
  10264858   38315 Makefile
  (no debugging symbols found)...(no debugging symbols found)...
   Program exited normally.

Greg
--
See complete headers for address and phone numbers

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

Re: vinum raid0 == system crash

[Greg 'groggy' Lehey]

On Thursday, 11 April 2002 at 10:43:46 +0400, Eugene Mitrofanov wrote:
 Hi

 I have 2 raid0 volumes on my server. Some time ago one hard disk died
 and I removed it from the server. Now the system reboots suddenly every
 1..5 days. I recompiled kernel with debuging info and located the place of
 the error:

 #5  0xc025efc7 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = -1023868912,
   tf_edi = 1, tf_esi = -1019600896, tf_ebp = -588665332,
   tf_isp = -588665372, tf_ebx = -1018645472, tf_edx = -1, tf_ecx = 153,
   tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip =-1072268915, tf_cs=8,
   tf_eflags = 66182, tf_esp = -1023729664, tf_ss = -1023727616})
 at ../../i386/i386/trap.c:448
 #6  0xc016798d in launch_requests (rq=0xc4868f40, reviveok=0)
 at ../../dev/vinum/vinumrequest.c:396
 #7  0xc01677a2 in vinumstart (bp=0xcf732be4, reviveok=0)
 at ../../dev/vinum/vinumrequest.c:291

 What shall I do now? Can you help me?

Well, I'd suggest you answer my last (private) message.  It's unlikely
that anybody else will help you.

Greg
--
See complete headers for address and phone numbers

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

Re: attempted exploits

[Greg 'groggy' Lehey]

[Format recovered--see http://www.lemis.com/email/email-format.html]

Log output wrapped.

On Sunday, 24 March 2002 at 21:52:40 -0800, Jesse Geddis wrote:
 wow, this person is quite effective. they've been trying this since
 this morning 4mins after i got my web server up. been doing it every
 half hour for 7 hours lol. trying to execute arbitrary Windows code on
 a FreeBSD server!

 [Sun Mar 24 20:41:55 2002] [error] [client 63.198.148.139] File does not exist: 
/archive/www/cia/scripts/..Á../winnt/system32/cmd.exe
 [Sun Mar 24 20:42:05 2002] [error] [client 63.198.148.139] File does not exist: 
/archive/www/cia/scripts/..À¯../winnt/system32/cmd.exe
 [Sun Mar 24 20:42:10 2002] [error] [client 63.198.148.139] File does not exist: 
/archive/www/cia/scripts/..Á../winnt/system32/cmd.exe
 [Sun Mar 24 20:42:29 2002] [error] [client 63.198.148.139] File does not exist: 
/archive/www/cia/scripts/..%5c../winnt/system32/cmd.exe
 [Sun Mar 24 21:13:11 2002] [error] [client 63.198.148.139] File does not exist: 
/archive/www/cia/scripts/root.exe
 [Sun Mar 24 21:13:12 2002] [error] [client 63.198.148.139] File does not exist: 
/archive/www/cia/MSADC/root.exe
 [Sun Mar 24 21:13:13 2002] [error] [client 63.198.148.139] File does not exist: 
/archive/www/cia/c/winnt/system32/cmd.exe
 [Sun Mar 24 21:13:14 2002] [error] [client 63.198.148.139] File does not exist: 
/archive/www/cia/d/winnt/system32/cmd.exe
 [Sun Mar 24 21:13:15 2002] [error] [client 63.198.148.139] File does not exist: 
/archive/www/cia/scripts/..%5c../winnt/system32/cmd.exe
 [Sun Mar 24 21:13:17 2002] [error] [client 63.198.148.139] File does not exist: 
/archive/www/cia/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe
 [Sun Mar 24 21:13:19 2002] [error] [client 63.198.148.139] File does not exist: 
/archive/www/cia/_mem_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe
 [Sun Mar 24 21:13:20 2002] [error] [client 63.198.148.139] File does not exist: 
/archive/www/cia/msadc/..%5c../..%5c../..%5c/..Á../..Á../..Á../winnt/system32/cmd.exe

Nimda.  http://www.cert.org/advisories/CA-2001-26.html

Greg
--
When replying to this message, please take care not to mutilate the
original text.  
For more information, see http://www.lemis.com/email.html
See complete headers for address and phone numbers

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