r338446: network access freezing on em/igb NICs

[Hartmann, O.]

Running CURRENT (FreeBSD 12.0-ALPHA4 #19 r338446: Mon Sep  3 21:07:45
CEST 2018 amd64) on a PCengine APU2C4 (NIC is 3x Intel i210:
[...]
igb0@pci0:2:0:0:class=0x02 card=0x8086 chip=0x157b8086
rev=0x03 hdr=0x00 vendor = 'Intel Corporation'
device = 'I210 Gigabit Network Connection'
class  = network
subclass   = ethernet
bar   [10] = type Memory, range 32, base 0xfe50, size 131072,
enabled bar   [18] = type I/O Port, range 32, base 0x1000, size 32,
disabled bar   [1c] = type Memory, range 32, base 0xfe52, size
16384, enabled
[...] )

When connecting to the as router acting APU from inside my SoHo network
from any machine or via serial console, there is no obvious problem so
far detectable. Using top(1), which is my indicator for the problem, is
sending normal output. The router has igb0 as tun0 and is spanning the
network via vlans via igb1. Connecting to a host inside my network and
havinf heavy net I/O doesn't reveal any problems so far. Direct access
to the APU from outside is prohobited.

When loggin into a host inside my private net from my department and
then from there toward the router (APU) as a wheel-grouped user also
doesn't reveal problems using top - but I have users restricted to see
only there own ID and also there groups are limited via some
bsd_see_others... sysctls. It gets funny when sudo su -'ing to root on
the APU and then using top. Immediately the net traffic freezes forever!

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

Re: Boot freezing after kernel load - root on zfs

[Ben Woods]

On 23 June 2018 at 22:56, Joe Maloney  wrote:

> Ben,
> do you by chance have multicons enabled with comconsole, vidconsole?  This
> looks exactly like a race we encountered where the remaining output was
> actually being redirected to serial on some systems when multicons was
> being used.  It appeared to be a lockup when it wasn’t because keyboard
> input would also break.
>

Hi Joe,

Indeed, you are right - I have now fixed the problem! Thanks very much for
your help!

I was previously using a serial console to boot the machine, whereas now I
have an IP KVM.

The lines I commented out in my /boot/loader.conf to fix this were:
boot_multicons="YES"
boot_serial="YES"
comconsole_speed="115200"
console="comconsole,vidconsole"

I would have thought that the boot should still complete regardless of
whether the serial console is connected or not?

Regards,
Ben

--
From: Benjamin Woods
woods...@gmail.com
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot freezing after kernel load - root on zfs

[Ben Woods]

On 23 June 2018 at 12:37, Warner Losh  wrote:

> There were some issues with legacy geely booting recently. What version?
> UEFI or legacy BIOS booting?
>
> Warner
>


Hi Warner,

This was occurring with both my old and new beadm boot environments -
r330554 and r334554.

I am booting with legacy BIOS.

Regards,
Ben

--
From: Benjamin Woods
woods...@gmail.com
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot freezing after kernel load - root on zfs

[Joe Maloney]

Ben,
do you by chance have multicons enabled with comconsole, vidconsole?  This 
looks exactly like a race we encountered where the remaining output was 
actually being redirected to serial on some systems when multicons was being 
used.  It appeared to be a lockup when it wasn’t because keyboard input would 
also break.

> On Jun 23, 2018, at 10:40 AM, Allan Jude  wrote:
> 
>> On 2018-06-23 00:37, Warner Losh wrote:
>> There were some issues with legacy geely booting recently. What version?
>> UEFI or legacy BIOS booting?
>> 
>> Warner 
>> 
>> On Fri, Jun 22, 2018, 10:26 PM Ben Woods > > wrote:
>> 
>>On 23 June 2018 at 12:08, Allan Jude >> wrote:
>> 
>>> If you just press shift a bunch of times, does it print the Mount root
>>> prompt?
>>> --
>>> Allan Jude
>>> 
>> 
>> 
>>No, unfortunately not. But please keep any troubleshooting suggestions
>>coming!
>> 
>>I have tried booting with the KVM monitor and USB disconnected, with the
>>same result.
>> 
>>It is also worth noting I can successfully boot from a USB stick running
>>the latest 12-current snapshot
>>FreeBSD-12.0-CURRENT-amd64-20180618-r335317-memstick.img. From there
>>I can
>>import both of my zpools (zroot and zstore), and then export them again
>>before rebooting - still can't boot from disk.
>> 
>>--
>>From: Benjamin Woods
>>woods...@gmail.com 
>>___
>>freebsd-current@freebsd.org 
>>mailing list
>>https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>To unsubscribe, send any mail to
>>"freebsd-current-unsubscr...@freebsd.org
>>"
>> 
> 
> Warner: it is not that in this case, the screenshots show it getting
> just past mountroot, so it is well into the kernel when it is stopping.
> 
> -- 
> Allan Jude
> 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot freezing after kernel load - root on zfs

[Allan Jude]

On 2018-06-23 00:37, Warner Losh wrote:
> There were some issues with legacy geely booting recently. What version?
> UEFI or legacy BIOS booting?
> 
> Warner 
> 
> On Fri, Jun 22, 2018, 10:26 PM Ben Woods  > wrote:
> 
> On 23 June 2018 at 12:08, Allan Jude  > wrote:
> 
> > If you just press shift a bunch of times, does it print the Mount root
> > prompt?
> > --
> > Allan Jude
> >
> 
> 
> No, unfortunately not. But please keep any troubleshooting suggestions
> coming!
> 
> I have tried booting with the KVM monitor and USB disconnected, with the
> same result.
> 
> It is also worth noting I can successfully boot from a USB stick running
> the latest 12-current snapshot
> FreeBSD-12.0-CURRENT-amd64-20180618-r335317-memstick.img. From there
> I can
> import both of my zpools (zroot and zstore), and then export them again
> before rebooting - still can't boot from disk.
> 
> --
> From: Benjamin Woods
> woods...@gmail.com 
> ___
> freebsd-current@freebsd.org 
> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org
> "
> 

Warner: it is not that in this case, the screenshots show it getting
just past mountroot, so it is well into the kernel when it is stopping.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: Boot freezing after kernel load - root on zfs

[Warner Losh]

There were some issues with legacy geely booting recently. What version?
UEFI or legacy BIOS booting?

Warner

On Fri, Jun 22, 2018, 10:26 PM Ben Woods  wrote:

> On 23 June 2018 at 12:08, Allan Jude  wrote:
>
> > If you just press shift a bunch of times, does it print the Mount root
> > prompt?
> > --
> > Allan Jude
> >
>
>
> No, unfortunately not. But please keep any troubleshooting suggestions
> coming!
>
> I have tried booting with the KVM monitor and USB disconnected, with the
> same result.
>
> It is also worth noting I can successfully boot from a USB stick running
> the latest 12-current snapshot
> FreeBSD-12.0-CURRENT-amd64-20180618-r335317-memstick.img. From there I can
> import both of my zpools (zroot and zstore), and then export them again
> before rebooting - still can't boot from disk.
>
> --
> From: Benjamin Woods
> woods...@gmail.com
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot freezing after kernel load - root on zfs

[Ben Woods]

On 23 June 2018 at 12:08, Allan Jude  wrote:

> If you just press shift a bunch of times, does it print the Mount root
> prompt?
> --
> Allan Jude
>


No, unfortunately not. But please keep any troubleshooting suggestions
coming!

I have tried booting with the KVM monitor and USB disconnected, with the
same result.

It is also worth noting I can successfully boot from a USB stick running
the latest 12-current snapshot
FreeBSD-12.0-CURRENT-amd64-20180618-r335317-memstick.img. From there I can
import both of my zpools (zroot and zstore), and then export them again
before rebooting - still can't boot from disk.

--
From: Benjamin Woods
woods...@gmail.com
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot freezing after kernel load - root on zfs

[Allan Jude]

On June 22, 2018 10:13:31 PM EDT, Ben Woods  wrote:
>Hi everyone,
>
>After shutting down to connect a new IP KVM switch (VGA and USB), my
>FreeNAS mini hardware is no longer booting FreeBSD with root in zfs (no
>encryption) - it is getting stuck after the kernel finishes loading and
>it
>tries to mount root and start_init. It just stops printing any more
>output
>to the screen, but I know the keyboard is working as ctrl+alt+delete
>works.
>
>I wonder if this could be due to hard drives names being re-ordered
>(e.g.
>what was ada0 is now ada1). I have 2 SATA3 SSDs in a zfs mirror for
>root
>(showing as ada4 and ada5 during boot), and 4 SATA3 HDDs in a raidz2
>with
>geli for further storage (showing as ada0-3, but these are only mounted
>during rc init - after the point the boot process is getting stuck). I
>have
>no USB storage, although the IP KVM may present a virtual disk for
>loading
>media remotely.
>
>I am running 12-CURRENT, but know the recent upgrade is not the issue
>because I can’t load from the previous boot environment either.
>
>Is anyone able to recommend a fix or a way to troubleshoot further?
>Please
>see below a link with screenshots at the end of the boot where it gets
>stuck.
>
>https://imgur.com/gallery/vhn7ScC
>
>Thanks in advance for any help!
>
>Regards,
>Ben
>
>--
>From: Benjamin Woods
>woods...@gmail.com
>___
>freebsd-current@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to
>"freebsd-current-unsubscr...@freebsd.org"

If you just press shift a bunch of times, does it print the Mount root prompt?
-- 
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Boot freezing after kernel load - root on zfs

[Ben Woods]

Hi everyone,

After shutting down to connect a new IP KVM switch (VGA and USB), my
FreeNAS mini hardware is no longer booting FreeBSD with root in zfs (no
encryption) - it is getting stuck after the kernel finishes loading and it
tries to mount root and start_init. It just stops printing any more output
to the screen, but I know the keyboard is working as ctrl+alt+delete works.

I wonder if this could be due to hard drives names being re-ordered (e.g.
what was ada0 is now ada1). I have 2 SATA3 SSDs in a zfs mirror for root
(showing as ada4 and ada5 during boot), and 4 SATA3 HDDs in a raidz2 with
geli for further storage (showing as ada0-3, but these are only mounted
during rc init - after the point the boot process is getting stuck). I have
no USB storage, although the IP KVM may present a virtual disk for loading
media remotely.

I am running 12-CURRENT, but know the recent upgrade is not the issue
because I can’t load from the previous boot environment either.

Is anyone able to recommend a fix or a way to troubleshoot further? Please
see below a link with screenshots at the end of the boot where it gets
stuck.

https://imgur.com/gallery/vhn7ScC

Thanks in advance for any help!

Regards,
Ben

--
From: Benjamin Woods
woods...@gmail.com
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: VirtualBox: Eating up 100% CPU, freezing Windows 7

[Doug Barton]

On 08/04/2012 17:56, Kevin Oberman wrote:
 On Sat, Aug 4, 2012 at 2:30 PM, Doug Barton do...@freebsd.org wrote:
 On 08/04/2012 14:26, Garrett Cooper wrote:
 On Sat, Aug 4, 2012 at 1:26 PM, Doug Barton do...@freebsd.org wrote:

 On 08/04/2012 00:40, O. Hartmann wrote:
 No, also in my case. I build world and the VBox software with each
 kernel - usually.

 You can ensure that by putting this in src.conf:

 PORTS_MODULES=  emulators/virtualbox-ose-kmod

 You can place other modules in that list as well. I use vbox so you can
 be pretty confident that this is going to keep working. :)

 That doesn't work

 I assure you that it does. I have put a non-zero amount of work into
 fixing it, I use this method, and the resulting kernel module works just
 fine.

 If you actually try it and find something is not as it should be, then
 yes; please do file a PR and feel free to cc me.

 Doug
 
 I am only aware of this because of your posts. No reference to it at
 all in src.conf(5). It would be nice to see it there.

It's in make.conf(5) for historical reasons, along with a lot of other
options that should be moved.

 It is mentioned in build(7), but only as a MAKE option and a lot of
 people are not going to realize it can be placed in src.conf.

It can also go in make.conf, so that's not a total loss I suppose.

 Also,
 for those not fairly conversant in make, it is not clear whether
 multiple ports should be space, comma, colon, or otherwise delimited
 
 This is a very nice option as it is very easy to overlook rebuilding
 kernel modules in ports when building the kernel. Thanks or working on
 it.

My pleasure ... it was one of those things on the list and I finally
got around to it.

Doug

-- 

I am only one, but I am one.  I cannot do everything, but I can do
something.  And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: VirtualBox: Eating up 100% CPU, freezing Windows 7

[O. Hartmann]

Am 08/04/12 22:26, schrieb Doug Barton:
 On 08/04/2012 00:40, O. Hartmann wrote:
 No, also in my case. I build world and the VBox software with each
 kernel - usually.
 
 You can ensure that by putting this in src.conf:
 
 PORTS_MODULES=  emulators/virtualbox-ose-kmod
 
 You can place other modules in that list as well. I use vbox so you can
 be pretty confident that this is going to keep working. :)
 
 Doug
 

Hello Doug.

This is exactly how I build the kernel modules for nvidia and VBox ;-)
So I guess this makes it unlikely - in my case - that the problems occur
due to unsynchronized kernel/modules.

Oliver



signature.asc
Description: OpenPGP digital signature

Re: VirtualBox: Eating up 100% CPU, freezing Windows 7

[O. Hartmann]

Am 08/04/12 00:36, schrieb Kevin Oberman:
 On Fri, Aug 3, 2012 at 6:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
 On Fri, Aug 03, 2012 at 07:44:27AM +0200, Bernhard Fr?hlich wrote:
 On Fr.,??  3. Aug. 2012 06:18:33 CEST, Kevin Oberman kob6...@gmail.com 
 wrote:

 On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O.
 ohart...@zedat.fu-berlin.de wrote:
 I discover that when running Windows 7 in a VirtualBox On FreeBSD 10
 (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the
 ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7
 for more than a minute. For a minute or so, I can work, then, the
 freeze occurs again.

 I can't see this behaviour with a Ubuntu Guest on the same box. Is
 there Windows 7 specifica to be aware of?

 I am seeing the same thing. Also Win7 guest with Windows showing idle
 process at 99%, but my system is showing VB at 100%. The VM is only
 running a single CPU, so FreeBSD is still running OK, but the Win7
 system seems to freeze up periodically.

 9.1-PRERELEASE on amd64 updated yesterday (though it has been this way
 since VB was updated to 4.1.18. Guest additions for 4.1.18
 installed.All ports current. I'm thinking of backing off to 4.1.16.

 Can someone confirm that this is a regression in 4.1.18? Then I could talk 
 to upstream and see if I can get that adressed.

 Could it be a case of kernel and virtualbox modules out of sync ?
 I do see occasional crashes with virtualbox in both the host and guest,
 but a reinstall of in-sync kernel and modules usually fixes them.
 
 Nope. To be really, really sure I just re-built the module and
 rebooted. VB still eats 100% CPU (out of 400%) continually.
 
 Thanks for the suggestion, though.
 

No, also in my case. I build world and the VBox software with each
kernel - usually.

Regards,
Oliver



signature.asc
Description: OpenPGP digital signature

Re: VirtualBox: Eating up 100% CPU, freezing Windows 7

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/04/2012 00:40, O. Hartmann wrote:
 No, also in my case. I build world and the VBox software with each
 kernel - usually.

You can ensure that by putting this in src.conf:

PORTS_MODULES=  emulators/virtualbox-ose-kmod

You can place other modules in that list as well. I use vbox so you can
be pretty confident that this is going to keep working. :)

Doug

- -- 

I am only one, but I am one.  I cannot do everything, but I can do
something.  And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)

iQEcBAEBCAAGBQJQHYWJAAoJEFzGhvEaGryEyLUIALgi1n65I8oBaFYJEcIkDB6P
W3f5PMZa72DN4r2lI3A3XXdPUJsNRmNy/X0HYyrrIwvfD3Z3m8bReYCd7DHAKOX4
pBsLA/73cwns9c3+zsUe4i9TZOsJM8fNVsRp/BSvdtBgv61ZZUurvt43H+Ek0E0B
h5ttGaIanxLqrkwP2FC/q30t0pmauJYu3jDTGiugOh98o/3oNT+25etyJBNgvg4c
VxBs/5aCSc5VHAcLXRN6Y0BGGbeimpPqEFlq3FEFGLkC7LGjqoSBUaJVz1cgDP+t
RIK9g0V+XIfyirgZ2VMeK3tfQ0Q17zfyl0+Iyzl2IxZptU67OBV/9LMqyhRaBOc=
=KbES
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: VirtualBox: Eating up 100% CPU, freezing Windows 7

[Garrett Cooper]

On Sat, Aug 4, 2012 at 1:26 PM, Doug Barton do...@freebsd.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 08/04/2012 00:40, O. Hartmann wrote:
 No, also in my case. I build world and the VBox software with each
 kernel - usually.

 You can ensure that by putting this in src.conf:

 PORTS_MODULES=  emulators/virtualbox-ose-kmod

 You can place other modules in that list as well. I use vbox so you can
 be pretty confident that this is going to keep working. :)

That doesn't work because what variables are defined in the kernel
compile that get passed through to the port's autoconf. I've seen it
for a while but I need to figure out what to pass through exactly to
make things work. That or I'll just file a PR and get back to it
later.
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: VirtualBox: Eating up 100% CPU, freezing Windows 7

[Doug Barton]

On 08/04/2012 14:26, Garrett Cooper wrote:
 On Sat, Aug 4, 2012 at 1:26 PM, Doug Barton do...@freebsd.org wrote:

 On 08/04/2012 00:40, O. Hartmann wrote:
 No, also in my case. I build world and the VBox software with each
 kernel - usually.

 You can ensure that by putting this in src.conf:

 PORTS_MODULES=  emulators/virtualbox-ose-kmod

 You can place other modules in that list as well. I use vbox so you can
 be pretty confident that this is going to keep working. :)
 
 That doesn't work

I assure you that it does. I have put a non-zero amount of work into
fixing it, I use this method, and the resulting kernel module works just
fine.

If you actually try it and find something is not as it should be, then
yes; please do file a PR and feel free to cc me.

Doug

-- 

I am only one, but I am one.  I cannot do everything, but I can do
something.  And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: VirtualBox: Eating up 100% CPU, freezing Windows 7

[Kevin Oberman]

On Sat, Aug 4, 2012 at 2:30 PM, Doug Barton do...@freebsd.org wrote:
 On 08/04/2012 14:26, Garrett Cooper wrote:
 On Sat, Aug 4, 2012 at 1:26 PM, Doug Barton do...@freebsd.org wrote:

 On 08/04/2012 00:40, O. Hartmann wrote:
 No, also in my case. I build world and the VBox software with each
 kernel - usually.

 You can ensure that by putting this in src.conf:

 PORTS_MODULES=  emulators/virtualbox-ose-kmod

 You can place other modules in that list as well. I use vbox so you can
 be pretty confident that this is going to keep working. :)

 That doesn't work

 I assure you that it does. I have put a non-zero amount of work into
 fixing it, I use this method, and the resulting kernel module works just
 fine.

 If you actually try it and find something is not as it should be, then
 yes; please do file a PR and feel free to cc me.

 Doug

I am only aware of this because of your posts. No reference to it at
all in src.conf(5). It would be nice to see it there.

It is mentioned in build(7), but only as a MAKE option and a lot of
people are not going to realize it can be placed in src.conf. Also,
for those not fairly conversant in make, it is not clear whether
multiple ports should be space, comma, colon, or otherwise delimited

This is a very nice option as it is very easy to overlook rebuilding
kernel modules in ports when building the kernel. Thanks or working on
it.
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: VirtualBox: Eating up 100% CPU, freezing Windows 7

[Bernhard Fröhlich]

On Fr.,   3. Aug. 2012 06:18:33 CEST, Kevin Oberman kob6...@gmail.com wrote:

 On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O.
 ohart...@zedat.fu-berlin.de wrote:
  I discover that when running Windows 7 in a VirtualBox On FreeBSD 10
  (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the
  ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7
  for more than a minute. For a minute or so, I can work, then, the
  freeze occurs again.
  
  I can't see this behaviour with a Ubuntu Guest on the same box. Is
  there Windows 7 specifica to be aware of?
 
 I am seeing the same thing. Also Win7 guest with Windows showing idle
 process at 99%, but my system is showing VB at 100%. The VM is only
 running a single CPU, so FreeBSD is still running OK, but the Win7
 system seems to freeze up periodically.
 
 9.1-PRERELEASE on amd64 updated yesterday (though it has been this way
 since VB was updated to 4.1.18. Guest additions for 4.1.18
 installed.All ports current. I'm thinking of backing off to 4.1.16.

Can someone confirm that this is a regression in 4.1.18? Then I could talk to 
upstream and see if I can get that adressed.

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

Re: VirtualBox: Eating up 100% CPU, freezing Windows 7

[Luigi Rizzo]

On Fri, Aug 03, 2012 at 07:44:27AM +0200, Bernhard Fr?hlich wrote:
 On Fr.,??  3. Aug. 2012 06:18:33 CEST, Kevin Oberman kob6...@gmail.com 
 wrote:
 
  On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O.
  ohart...@zedat.fu-berlin.de wrote:
   I discover that when running Windows 7 in a VirtualBox On FreeBSD 10
   (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the
   ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7
   for more than a minute. For a minute or so, I can work, then, the
   freeze occurs again.
   
   I can't see this behaviour with a Ubuntu Guest on the same box. Is
   there Windows 7 specifica to be aware of?
  
  I am seeing the same thing. Also Win7 guest with Windows showing idle
  process at 99%, but my system is showing VB at 100%. The VM is only
  running a single CPU, so FreeBSD is still running OK, but the Win7
  system seems to freeze up periodically.
  
  9.1-PRERELEASE on amd64 updated yesterday (though it has been this way
  since VB was updated to 4.1.18. Guest additions for 4.1.18
  installed.All ports current. I'm thinking of backing off to 4.1.16.
 
 Can someone confirm that this is a regression in 4.1.18? Then I could talk to 
 upstream and see if I can get that adressed.

Could it be a case of kernel and virtualbox modules out of sync ?
I do see occasional crashes with virtualbox in both the host and guest,
but a reinstall of in-sync kernel and modules usually fixes them.

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

Re: VirtualBox: Eating up 100% CPU, freezing Windows 7

[Kevin Oberman]

On Fri, Aug 3, 2012 at 6:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
 On Fri, Aug 03, 2012 at 07:44:27AM +0200, Bernhard Fr?hlich wrote:
 On Fr.,??  3. Aug. 2012 06:18:33 CEST, Kevin Oberman kob6...@gmail.com 
 wrote:

  On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O.
  ohart...@zedat.fu-berlin.de wrote:
   I discover that when running Windows 7 in a VirtualBox On FreeBSD 10
   (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the
   ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7
   for more than a minute. For a minute or so, I can work, then, the
   freeze occurs again.
  
   I can't see this behaviour with a Ubuntu Guest on the same box. Is
   there Windows 7 specifica to be aware of?
 
  I am seeing the same thing. Also Win7 guest with Windows showing idle
  process at 99%, but my system is showing VB at 100%. The VM is only
  running a single CPU, so FreeBSD is still running OK, but the Win7
  system seems to freeze up periodically.
 
  9.1-PRERELEASE on amd64 updated yesterday (though it has been this way
  since VB was updated to 4.1.18. Guest additions for 4.1.18
  installed.All ports current. I'm thinking of backing off to 4.1.16.

 Can someone confirm that this is a regression in 4.1.18? Then I could talk 
 to upstream and see if I can get that adressed.

 Could it be a case of kernel and virtualbox modules out of sync ?
 I do see occasional crashes with virtualbox in both the host and guest,
 but a reinstall of in-sync kernel and modules usually fixes them.

Nope. To be really, really sure I just re-built the module and
rebooted. VB still eats 100% CPU (out of 400%) continually.

Thanks for the suggestion, though.
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

VirtualBox: Eating up 100% CPU, freezing Windows 7

[Hartmann, O.]

I discover that when running Windows 7 in a VirtualBox On FreeBSD 10
(r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the
ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7
for more than a minute. For a minute or so, I can work, then, the freeze
occurs again.

I can't see this behaviour with a Ubuntu Guest on the same box. Is there
Windows 7 specifica to be aware of?

Regards,

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

Re: VirtualBox: Eating up 100% CPU, freezing Windows 7

[Kevin Oberman]

On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O.
ohart...@zedat.fu-berlin.de wrote:
 I discover that when running Windows 7 in a VirtualBox On FreeBSD 10
 (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the
 ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7
 for more than a minute. For a minute or so, I can work, then, the freeze
 occurs again.

 I can't see this behaviour with a Ubuntu Guest on the same box. Is there
 Windows 7 specifica to be aware of?

I am seeing the same thing. Also Win7 guest with Windows showing idle
process at 99%, but my system is showing VB at 100%. The VM is only
running a single CPU, so FreeBSD is still running OK, but the Win7
system seems to freeze up periodically.

9.1-PRERELEASE on amd64 updated yesterday (though it has been this way
since VB was updated to 4.1.18. Guest additions for 4.1.18
installed.All ports current. I'm thinking of backing off to 4.1.16.
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: VirtualBox: Eating up 100% CPU, freezing Windows 7

[Garrett Cooper]

On Thu, Aug 2, 2012 at 9:18 PM, Kevin Oberman kob6...@gmail.com wrote:
 On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O.
 ohart...@zedat.fu-berlin.de wrote:
 I discover that when running Windows 7 in a VirtualBox On FreeBSD 10
 (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the
 ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7
 for more than a minute. For a minute or so, I can work, then, the freeze
 occurs again.

 I can't see this behaviour with a Ubuntu Guest on the same box. Is there
 Windows 7 specifica to be aware of?

 I am seeing the same thing. Also Win7 guest with Windows showing idle
 process at 99%, but my system is showing VB at 100%. The VM is only
 running a single CPU, so FreeBSD is still running OK, but the Win7
 system seems to freeze up periodically.

 9.1-PRERELEASE on amd64 updated yesterday (though it has been this way
 since VB was updated to 4.1.18. Guest additions for 4.1.18
 installed.All ports current. I'm thinking of backing off to 4.1.16.

I've been seeing consistent hangs with VBox 4.1.18, but mostly
with shared folders and the like under Windows 7 with certain paths
using Cygwin (probably an application issue, but I haven't dug into
why things are that way). I'm not sure what the exact revision is for
9.1-BETA1, but there are a handful of threading and amd64-specific
signal, etc related changes that may or may not affect things.
Thanks!
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Freezing PC with start of X with ATI Rage

[Tom Vijlbrief]

On Sunday 19 December 2010 09:49:21 Vladislav Movchan wrote:
 On Sat, Dec 18, 2010 at 10:34 PM, Vladislav Movchan

 vladislav.movc...@gmail.com wrote:
  On Sat, Dec 18, 2010 at 11:14 AM, Christian Gusenbauer c...@gmx.at
wrote:
  Hi!
 
  With commit r216333 to pmap.c my PC (i386 32 bit) freezes within a few
  seconds when X (with nvidia-driver 256.53) starts. I already recompiled
  and reinstalled the nvidia driver, but this didn't change anything. I
  also tried the latest nvidia-driver 260.19.29 but without luck, too
  :-(.
 
  By chance I saw a panic message vm_page_unwire: page 0x... wire count
  is zero, but no crash dump was generated.
 
  Any clues?
 
  Thanks,
  Christian.
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to
  freebsd-current-unsubscr...@freebsd.org
 
  I can only add me too - I am experiencing the same problem with two
  i386 machines. Both PCs work fine on revision 216332 and hanging on
  revision 216333 or later.
  I've tried to use different nvidia-driver versions (195.36.24, 256.53
  and 260.19.29), tried disabling glx/dri xorg extensions but nothing
  changed. Freeze happening before the moment when nvidia logo
  appears.
  Unfortunately I was never able to see panic message or obtain crash dump.
 
  If anybody have ideas I can help with testing.
 
  First machine:
  pciconf:
  vgap...@pci0:1:0:0: class=0x03 card=0x04421028 chip=0x0a2910de
  rev=0xa2 hdr=0x00
 vendor = 'NVIDIA Corporation'
 class  = display
 subclass   = VGA
 
  Xorg log:
  (--) PCI:*(0:1:0:0) 10de:0a29:1028:0442 nVidia Corporation GT216
  [GeForce GT 330M] rev 162, Mem @ 0xfa00/16777216,
  0xc000/268435456, 0xd000/33554432, I/O @ 0xe000/128, BIOS
  @ 0x/65536
 
  Second one:
  pciconf:
  vgap...@pci0:1:0:0: class=0x03 card=0x34681458 chip=0x061110de
  rev=0xa2 hdr=0x00
 vendor = 'NVIDIA Corporation'
 device = 'NVIDIA GeForce 8800 GT (G92)'
 class  = display
 subclass   = VGA
 
  Xorg log:
  (--) PCI:*(0:1:0:0) 10de:0611:1458:3468 nVidia Corporation G92
  [GeForce 8800 GT] rev 162, Mem @ 0xf600/16777216,
  0xe000/268435456, 0xf400/33554432, I/O @ 0xb000/128, BIOS
  @ 0x/65536
 
  --
  Have a nice(1) day,
  Vladislav Movchan

 Update to r216555 fixed this problem for me.

I have similar problems on my old Pentium-II with an ATI Rage, but the
actual current still freezes. Stable is fine.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

current freezing with sendmail-msp sumitting to ipv6 ::1.25

[Michael Weiser]

Hi,

yesterday I tried to make the system's sendmail-msp submit to ::1.25
instead of 127.0.0.1:25 on an up-to-date FreeBSD-current installation .  
When injecting a lot of messages via bsmtp (rsmtp command) the system
freezes solid after putting about 10 to 20 into the mail queue and doesn't
even get as far as delivering them into the user's mailbox.  There are no
messages on the console or in the log files, the console doesn't respond
any more and only way to revive the system is a hard reboot. Reverting to
the old setting makes everything work fine again. Am I just doing it the
wrong way round[tm] or is there some instability with IPv6 in
FreeBSD-current?
-- 
bye, Micha
I hate forms!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: CURRENT kernel freezing or rebooting

[Bosko Milekic]

Do you have the debugging options enabled?

makeoptions DEBUG=-g
options DDB

at the VERY least.  Try also compiling with INVARIANTS and
INVARIANT_SUPPORT...

On Sat, Feb 22, 2003 at 05:10:15PM +, Daniel Flickinger wrote:
 kernels built from cvsup date tags:
 
   1200 GMT 21 Feb 2003
   1200 GMT 22 Feb 2003
 
 either hang hard or freeze and fall out to reboot. No
 error messages logged. Both were full make world, etc.
 followed by mergemaster. apache 1.3.27, X, Mozilla, etc
 running.
 
 Previous build from cvsup date tag 1200 GMT 14 Feb 2003 ran
 the week with zero problems. Will try again tomorrow morning
 (1200 GMT) if there are interesting kernel commits.
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 

-- 
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]


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

Re: CURRENT kernel freezing or rebooting

[Marcin Dalecki]

Daniel Flickinger wrote:
kernels built from cvsup date tags:

1200 GMT 21 Feb 2003
1200 GMT 22 Feb 2003
either hang hard or freeze and fall out to reboot. No
error messages logged. Both were full make world, etc.
followed by mergemaster. apache 1.3.27, X, Mozilla, etc
running.
Previous build from cvsup date tag 1200 GMT 14 Feb 2003 ran
the week with zero problems. Will try again tomorrow morning
(1200 GMT) if there are interesting kernel commits.
And you managed to build it at all?

I get the following on a cvsup from about few ours ago.

dd if=/dev/zero of=boot2.ldr bs=276 count=1 2/dev/null
nm -t d boot1.out | awk '/([0-9])+ T xread/  { x = $1 - ORG1;  printf(#define XREADORG 
%#x\n, REL1 +
 x) }'  ORG1=`printf %d 0x7c00`  REL1=`printf %d 0x700`  boot2.h
cc -elf -ffreestanding -Os -fno-builtin  -fno-guess-branch-probability 
-fomit-frame-pointer -mno-align
-long-strings  -mrtd  -DUFS1_AND_UFS2  -I/usr/src/sys/boot/i386/boot2/../../common  
-I/usr/src/sys/boo
t/i386/boot2/../btx/lib -I.  -Wall -Waggregate-return -Wbad-function-cast -Wcast-align 
 -Wmissing-decl
arations -Wmissing-prototypes -Wnested-externs  -Wpointer-arith -Wshadow 
-Wstrict-prototypes -Wwrite-s
trings -ffreestanding -mpreferred-stack-boundary=2-S -o boot2.s.tmp 
/usr/src/sys/boot/i386/boot2/b
oot2.c
sed -e '/align/d' -e '/nop/d'  boot2.s.tmp  boot2.s
rm -f boot2.s.tmp
as  -o boot2.o boot2.s
as  --defsym SIOPRT=0x3f8  --defsym SIOFMT=0x3  --defsym SIOSPD=9600  
/usr/src/sys/boot/i386/boot2/sio.s -o sio.o
ld -nostdlib -static -N --gc-sections -Ttext 0x2000 -o boot2.out  
/usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o
objcopy -S -O binary boot2.out boot2.bin
btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l 
boot2.ldr  -o boot2.ld -P 1 boot2.bin
kernel: ver=1.01 size=780 load=9000 entry=9010 map=16M pgctl=1:1
client: fmt=bin size=1691 text=0 data=0 bss=0 entry=0
output: fmt=bin size=1f25 text=114 data=1e11 org=0 entry=0
-293 bytes available
*** Error code 1
Stop in /usr/src/sys/boot/i386/boot2.
*** Error code 1
Stop in /usr/src/sys/boot/i386.
*** Error code 1
Stop in /usr/src/sys/boot.
*** Error code 1
Stop in /usr/src/sys.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.

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

5.0-R freezing on kernel probe with Toshiba laptop?

[Darren Pilgrim]

I have a Toshiba Satellite 1805-S207 laptop.  When I boot the generic 5.0-R 
kernel from a fresh install (fresh as in initial reboot), it will show the 
device lines for agp0 then hang indefinitely, requiring that I turn off the 
machine via the power button.  This is a repeating event, and occurs with 
the generic kernel from the miniinst ISO as well as that from the 5.0-R 
install I built on a 4_7 machine.  Using a conservative make.conf didn't help.

The specs on the laptop say it has the ALi CyberALADDiN-T M1535 chipset, 
if that helps any.  The complete specsheet is findable on Toshiba's website, 
though they use JSP, so the closest URL I can provide is going to be 
http://www.csd.toshiba.com/cgi-bin/tais/su/su_sc_modSel.jsp.


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

Re: Xfree86, GNOME, KDE freezing over

[Alexander Leidinger]

On Tue, 15 Oct 2002 11:39:22 -0700 (PDT)
Saurabh Gupta [EMAIL PROTECTED] wrote:

 Any help will be very much appreciated.

When it freezes again, wait some minutes (~10). If it unfreezes then, it
is a known problem. And if you see some aborts (signal 6) of XFree86,
then it is a known problem too.

Bye,
Alexander.

-- 
Secret hacker rule #11: hackers read manuals.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

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

Xfree86, GNOME, KDE freezing over

[Saurabh Gupta]

Hi,
I am running a current from 22nd of september.
I compiled gnome2 using the ports method. after some
help from people in this list i finally installed it.
Now as soon as I startup gnome in X the computer freezes.
So I compiled and installed kde3 and the same thing
happens.
Simple X with just twm seemed to run fine(xterm and a whole
bunch of X utilities and all), untill I
displayed a remote netscape on this display, which is when
this froze over again.
Other things that freeze the computer are
mozilla running under twm within 10 seconds of startup
even just the sawfish window manager freezes as soon as
I resize any window.
I have no idea how to get more info or catch this bug It
just gives no error nothing, even in a generic Kernel with
all the debugging features turned on!
ANY CLUES, SUGGESTIONS
Any one running these applications on current successfully?
Anyways here is what I did further. It seems as if the problem
is in some package that is used by all these applications.
So I gathered a list of dependency packages for all these and
started looking for common members. There are tons no surprise
there. among all however the common members seem to be
Dependency: libiconv-1.8_1
Dependency: lcms-1.08
Dependency: freetype2-2.1.2
of these lcms and libiconv seem to be ruled out in XFree-*
dependency list. So the most/(only?) common package in all these
software seems to be
freetype2-2.1.2
Another thing i noticed is that kde starts up fine : displays
a couple of windows and then right around then while displaying
one of the windows it freezes half way through. Sort of leaving
a feeling that it froze over while rendering some graphics or
doing font manipulation calculation..
is freetype the real culprit, I do not know!
ofcourse all this could very well be no more than a hunch.
Any help will be very much appreciated.
thanks and best regards,

Saurabh Gupta



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

Re: 'moused' (on /dev/ums0) freezing system

[Alexander Leidinger]

On 31 Mär, Ollivier Robert wrote:

 I encountered a problem when using 'moused' on /dev/ums0: On shutdown 
 or if 'moused' gets killed manually, the system freezes completely and 
 silently, no further shutdown is possible, only the resetbutton 
 operates...
 
 I think it is more of an USB problem than just moused. If I have loaded the
 usb module (which create a usb0 kernel thread) when I do a suspend, on resume
 the machine hangs.

Just a data point:
With a mar 12 kernel I didn't see this behavior, with a mar 27 kernel my
system hangs too.

Bye,
Alexander.

-- 
  The best things in life are free, but the
expensive ones are still worth a look.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7


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

Re: 'moused' freezing system

[Ollivier Robert]

According to Matthias Schuendehuette:
 I encountered a problem when using 'moused' on /dev/ums0: On shutdown 
 or if 'moused' gets killed manually, the system freezes completely and 
 silently, no further shutdown is possible, only the resetbutton 
 operates...

I think it is more of an USB problem than just moused. If I have loaded the
usb module (which create a usb0 kernel thread) when I do a suspend, on resume
the machine hangs.

Around BSDcon in February, I was getting a panic() now that I've temporarely
removed DDB, it just hangs.

This is on a Sony VAIO Z600TEK with APM (not ACPI, it doesn't resume at all
with ACPI).
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun  4 22:44:19 CEST 2000

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

'moused' freezing system

[Matthias Schuendehuette]

Hello,

I encountered a problem when using 'moused' on /dev/ums0: On shutdown 
or if 'moused' gets killed manually, the system freezes completely and 
silently, no further shutdown is possible, only the resetbutton 
operates...

This does not happen if I'm using /dev/psm0.

At least, I can enjoy background-fsck on every startup... ;-)

I have a VIA 83C572 USB controller.
-- 
Ciao/BSD - Matthias

Matthias Schuendehuette [EMAIL PROTECTED], Berlin (Germany)
Powered by FreeBSD 4.5-STABLE

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

known problem with certain programs freezing in state poll?

[Kelvin Farmer]

Just wondering if the following is a known problem, or if I can provide any
more useful info?
After updating from a pre-Feb 10 current, i'm now seeing Licq freezing on
exit, with top showing it to be in state "poll". (and has to be kill'ed to
exit it)
Xmms is worse, after playing an mp3 for a short while, FreeBSD freezes
solid, (no panic) top running in another window shows it to be in state
"poll" when this happens.

Cheers
Kelvin.

[EMAIL PROTECTED]



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

Re: missing interrupts (was Re: CURRENT is freezing again ...)

[Bruce Evans]

On Mon, 27 Nov 2000, Andrew Gallatin wrote:

 
 Bruce Evans writes:
   Possible causes of the problem:
   1) isa_handle_intr() claims to send specific EOIs (0x30 | irq) but
  actually sends non-specific ones (0x20 | garbage).  Since interrupts
 
 I think that sending non-specific EOIs is the problem.  Sending
 specific EOIs seem to eliminate my nic timeouts and the need to
 manually feed an eoi to recover from a missing interrupt.
 
 My question is: how does one send a specific EOI correctly?  I don't
 have decent documentation for this.  Above, you seem to imply that
 0x30 is a specific EOI.  That does not seem to work for me (machine
 locks at boot).
 
 Linux uses 0xe0.  According to some Tru64 docs I have,
 that means "Rotate Priority on specific EOI".  According
 to that same documentation, 0x60 is a specific EOI.  Both of these

Oops, I misread the data sheet.  0x60 is correct, 0x30 is wrong.  The
irq number is in the lowest 3 bits.

 appear to work just fine.   What should the alpha port use?

I think it should use non-specific EOIs and send them early (when
there is no ambiguity about which interrupt is being handled), as in
the i386 port.  Sending them late mainly gives the ICU's braindamaged
interrupt priority scheme for longer than necessary.

Bruce



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

Re: missing interrupts (was Re: CURRENT is freezing again ...)

[Robert Drehmel]

In [EMAIL PROTECTED],
Andrew Gallatin wrote:
 Bruce Evans writes:
   Possible causes of the problem:
   1) isa_handle_intr() claims to send specific EOIs (0x30 | irq) but
  actually sends non-specific ones (0x20 | garbage).  Since interrupts
  may be handled in non-LIFO order, this results in EOIs being sent
  for the wrong interrupts.  I think this just randomizes the
  brokenness caused by delaying sending of EOIs.  I can't see how it
  would result in an EOI being lost -- the right number of EOIs will
  have been sent after all handlers have returned.
 
 
 I think that sending non-specific EOIs is the problem.  Sending
 specific EOIs seem to eliminate my nic timeouts and the need to
 manually feed an eoi to recover from a missing interrupt.
 
 My question is: how does one send a specific EOI correctly?  I don't
 have decent documentation for this.  Above, you seem to imply that
 0x30 is a specific EOI.  That does not seem to work for me (machine
 locks at boot).
 
 Linux uses 0xe0.  According to some Tru64 docs I have,
 that means "Rotate Priority on specific EOI".  According
 to that same documentation, 0x60 is a specific EOI.  Both of these
 appear to work just fine.   What should the alpha port use?

My notes say:

Non-specific EOI : 0x20
Specific EOI : 0x60 | IRQn
EOI + rotate priority: 0xa0
EOI + select lowest priority : 0xe0 | IRQn

-- 
Robert S. F. Drehmel [EMAIL PROTECTED]


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

Re: missing interrupts (was Re: CURRENT is freezing again ...)

[Andrew Gallatin]

Bruce Evans writes:
  Possible causes of the problem:
  1) isa_handle_intr() claims to send specific EOIs (0x30 | irq) but
 actually sends non-specific ones (0x20 | garbage).  Since interrupts
 may be handled in non-LIFO order, this results in EOIs being sent
 for the wrong interrupts.  I think this just randomizes the
 brokenness caused by delaying sending of EOIs.  I can't see how it
 would result in an EOI being lost -- the right number of EOIs will
 have been sent after all handlers have returned.


I think that sending non-specific EOIs is the problem.  Sending
specific EOIs seem to eliminate my nic timeouts and the need to
manually feed an eoi to recover from a missing interrupt.

My question is: how does one send a specific EOI correctly?  I don't
have decent documentation for this.  Above, you seem to imply that
0x30 is a specific EOI.  That does not seem to work for me (machine
locks at boot).

Linux uses 0xe0.  According to some Tru64 docs I have,
that means "Rotate Priority on specific EOI".  According
to that same documentation, 0x60 is a specific EOI.  Both of these
appear to work just fine.   What should the alpha port use?

Thanks,

Drew





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

Re: CURRENT is freezing again ...

[Kris Kennaway]

On Fri, Nov 17, 2000 at 05:58:30PM -0800, Kris Kennaway wrote:
 On Fri, Nov 17, 2000 at 12:55:28PM +0100, Soren Schmidt wrote:
 
   I thought I was the only one, since my question on the freebsd-current
   mailing list went unanswered.
  
  You are _not_ alone, there has been numerous complains about this
  on the list, but so far they have not been taken seriously :|
 
 One of my non-SMP machines reliably wedges whenever I do heavy disk
 I/O. I can't break to debugger.
 
 Nov  4 15:46:41 mollari /boot/kernel/kernel: atapci0: Intel PIIX3 ATA controller 
port 0xffa0-0xffaf at device 7.1 on pci0
 Nov  4 15:46:41 mollari /boot/kernel/kernel: ata0: at 0x1f0 irq 14 on atapci0
 Nov  4 15:46:41 mollari /boot/kernel/kernel: ahc0: Adaptec 2940 Ultra SCSI adapter 
port 0xfc00-0xfcff mem 0xffbeb000-0xffbebfff irq 15 at device 11.0 on pci0
 Nov  4 15:46:41 mollari /boot/kernel/kernel: aic7880: Wide Channel A, SCSI Id=7, 
16/255 SCBs

Well, adding INVARIANTS, INVARIANTS_SUPPORT, MUTEX_DEBUG and WITNESS
didn't give me anything to go off.

Interestingly though - I thrashed the disks for about 15 minutes to no
avail before kldloading random.ko and firing up ssh, at which point it
froze within a few minutes while typing. Obviously one data point
isn't much to go off, but it might be somewhere to start looking.

Kris

 PGP signature

Re: CURRENT is freezing again ...

[Mark Murray]

 Interestingly though - I thrashed the disks for about 15 minutes to no
 avail before kldloading random.ko and firing up ssh, at which point it
 froze within a few minutes while typing. Obviously one data point
 isn't much to go off, but it might be somewhere to start looking.

Now that I've (almost) cleared get_cyclecounter(9) out of my TODO,
I can use it, and then go about getting rid of most malloc(9)s and
all TAILQs in random.ko.

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


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

Re: CURRENT is freezing again ...

[Mark Huizer]

On Thu, Nov 16, 2000 at 12:20:49PM -0500, Steven E. Ames wrote:
 It seems to only do it SMP... the same machine built with a non-SMP
 kernel (same source code) runs just fine for extended periods.

I have a non-SMP machine that is running a 15-nov current kernel, which
freezes a few times a day. This morning I found it might coincide with
the times that cvsup is running. Disabled that, I'll see if that's where
the problem might show up.
Freeze means: no keyboard activity possible, machine just does nothing.
 
   On Thu, 16 Nov 2000, Soren Schmidt wrote:
  
 After last cvsup my machine (Dual PIII, SMP kernel) is freezing
 again in
 10 min after boot...
   
You mean "is still freezing" right ?
   
Current has been like this for longer than I care to think about,
 it
seems those in charge doesn't take these problems seriously
 (enough)...
  
   I think info about where/how it freezing would be more helpful.
 
  No idea, the system just freezes, no drob to DDB no remote gdb no
  nothing, so its really hard to tell where...
  As to how, just boot current on a fairly fast machine, make a kernel
  and it'll hang in minutes if not less, or just leave it alone and
  it will hang in 10-30 mins...
 
  -Søren
 
 
  To Unsubscribe: send mail to [EMAIL PROTECTED]
  with "unsubscribe freebsd-current" in the body of the message
 
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message

-- 
Nice testing in little China...


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

Re: CURRENT is freezing again ...

[Michael Harnois]

On Fri, 17 Nov 2000 10:30:02 -0800 (PST), John Baldwin [EMAIL PROTECTED] said:

 what the WITNESS code does is perform extra checks on mutex
 enter's and exit's to ensure that we aren't handling mutexes in
 such a way that a deadlock is possible. Thus, it verifies that
 you don't grab mutexes out of order, or that you don't grab
 sleep mutexes with interrupts disabled, etc.

Is this code meaningful on UP machines? Having been a victim of these
seemingly random freezes since SMPng started, as others have noted, I
decided to compile it in earlier this week. Twice now I've been dumped
into the debugger with this output:

lock order reversal
1st dc0 last acquired @ ../../pci/if_dc.c:2717
2nd 0xc0acdb3c dc1 @ ../../pci/if_dc.c: 2717
3rd 0xc0acab3c dc0 @ ../../pci/if_dc.c: 2929

Debugger ("witness_enter")
Stopped at Debugger+0x39: movb $0, in.Debugger.639

-- 
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
[EMAIL PROTECTED]  [EMAIL PROTECTED] 
 The atheist staring from the attic window is often nearer to God than the
 believer caught up in his own false image of God. -- Martin Buber


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

Re: CURRENT is freezing again ...

[Jonathan Lemon]

In article local.mail.freebsd-current/[EMAIL PROTECTED] you 
write:
On Fri, 17 Nov 2000 10:30:02 -0800 (PST), John Baldwin [EMAIL PROTECTED] said:

 what the WITNESS code does is perform extra checks on mutex
 enter's and exit's to ensure that we aren't handling mutexes in
 such a way that a deadlock is possible. Thus, it verifies that
 you don't grab mutexes out of order, or that you don't grab
 sleep mutexes with interrupts disabled, etc.

Is this code meaningful on UP machines? Having been a victim of these
seemingly random freezes since SMPng started, as others have noted, I
decided to compile it in earlier this week. Twice now I've been dumped
into the debugger with this output:

lock order reversal
1st dc0 last acquired @ ../../pci/if_dc.c:2717
2nd 0xc0acdb3c dc1 @ ../../pci/if_dc.c: 2717
3rd 0xc0acab3c dc0 @ ../../pci/if_dc.c: 2929

This is on a UP machine?  This looks like you're taking an interrupt
on dc1 and then trying to call the dc0 start routine, which shouldn't
be possible.  (Unless I'm misunderstanding the witness code)

What version of if_dc.c are you using?  line 2929 doesn't correspond
to an instance of "DC_LOCK" in my copy.
--
Jonathan

this should be released before anything else 



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

Re: CURRENT is freezing again ...

[Michael Harnois]

On Sat, 18 Nov 2000 11:40:34 -0600 (CST), Jonathan Lemon [EMAIL PROTECTED] said:

 What version of if_dc.c

1.38

-- 
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
[EMAIL PROTECTED]  [EMAIL PROTECTED] 
 "It's not what we don't know that hurts us, 
 it's what we know for certain that just ain't so." -- Mark Twain


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

Re: CURRENT is freezing again ...

[Sheldon Hearn]

On Thu, 16 Nov 2000 10:42:51 PST, Alfred Perlstein wrote:

 I would try a new kernel, and perhaps some collabaration with John
 to debug these problems rather than just complaining about the
 situation.  I see at least two experianced developers in the CC
 list, there's no reason for these poor bug reports.

The problem with a hard lock-up out of which you can't escape into the
debugger is that it makes meaningful bug reports impossible.  My non-SMP
workstation has exhibited apparently arbitrary lock-ups since the advent
of SMPng.

I thought I was the only one, since my question on the freebsd-current
mailing list went unanswered.

From my understanding, John's WITNESS code allows us to break into the
debugger from within interrupt context.  If the lock-ups are happening
in there, then this may help us provide better bug reports.

Oh, and a couple of deep breaths are probably in order. :-)

Ciao,
Sheldon.


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

Re: CURRENT is freezing again ...

[Soren Schmidt]

It seems Sheldon Hearn wrote:
  I would try a new kernel, and perhaps some collabaration with John
  to debug these problems rather than just complaining about the
  situation.  I see at least two experianced developers in the CC
  list, there's no reason for these poor bug reports.
 
 The problem with a hard lock-up out of which you can't escape into the
 debugger is that it makes meaningful bug reports impossible.  My non-SMP
 workstation has exhibited apparently arbitrary lock-ups since the advent
 of SMPng.
 
 I thought I was the only one, since my question on the freebsd-current
 mailing list went unanswered.

You are _not_ alone, there has been numerous complains about this
on the list, but so far they have not been taken seriously :|

 From my understanding, John's WITNESS code allows us to break into the
 debugger from within interrupt context.  If the lock-ups are happening
 in there, then this may help us provide better bug reports.

It doesn't help here at least, the machine(s) just lock up solid
only reset or a powercycle can bring them back...

 Oh, and a couple of deep breaths are probably in order. :-)

Yeah like *sigh* 

-Søren


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

Re: CURRENT is freezing again ...

[Michael Harnois]

On Fri, 17 Nov 2000 12:55:28 +0100 (CET), Soren Schmidt [EMAIL PROTECTED] said:

 It doesn't help here at least, the machine(s) just lock up solid
 only reset or a powercycle can bring them back...

Same here ... as others noted, started with SMPng ...

-- 
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
[EMAIL PROTECTED]  [EMAIL PROTECTED] 
 There are things that are so serious 
 that you can only joke about them. -- Werner Heisenberg


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

Re: CURRENT is freezing again ...

[Warner Losh]

In message [EMAIL PROTECTED] Sheldon Hearn writes:
: The problem with a hard lock-up out of which you can't escape into the
: debugger is that it makes meaningful bug reports impossible.  My non-SMP
: workstation has exhibited apparently arbitrary lock-ups since the advent
: of SMPng.

You can also short IOCHK to ground to get an NMI which kicks you into
the debugger, even in an interrupt context.  I have a card I built
from an old multi-function card to do this.  I think it is A1 and A2,
but I don't have my ISA bus spec handy.

Warner


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

Re: CURRENT is freezing again ...

[John Baldwin]

On 17-Nov-00 Sheldon Hearn wrote:
 
 
 On Thu, 16 Nov 2000 10:42:51 PST, Alfred Perlstein wrote:
 
 I would try a new kernel, and perhaps some collabaration with John
 to debug these problems rather than just complaining about the
 situation.  I see at least two experianced developers in the CC
 list, there's no reason for these poor bug reports.
 
 The problem with a hard lock-up out of which you can't escape into the
 debugger is that it makes meaningful bug reports impossible.  My non-SMP
 workstation has exhibited apparently arbitrary lock-ups since the advent
 of SMPng.

When I get a hard lock like this I usually try to see if I can reproduce it in
single user mode.  If I can, then I compile KTR into my kernel with the
following options:  KTR, KTR_EXTEND, KTR_COMPILE="0x3fff",
KTR_MASK="(KTR_INTR|KTR_PROC)".  Then I boot into single user (so I don't dirty
filesystems), mount any needed fs's as read only if possible, and run the
following command:

# sysctl -w debug.ktr_verbose=1 ; command_that_makes_my_machine_go_boom

And then stare at the tracing output on teh screen to see what the machine
was doing when it hung.  I.e., to see if it is still getting interrupts, and to
see what process it died in, etc.

 From my understanding, John's WITNESS code allows us to break into the
 debugger from within interrupt context.  If the lock-ups are happening
 in there, then this may help us provide better bug reports.

Err, not quite.  It's BSD/OS's WITNESS code, and what the WITNESS code does is
perform extra checks on mutex enter's and exit's to ensure that we aren't
handling mutexes in such a way that a deadlock is possible.  Thus, it verifies
that you don't grab mutexes out of order, or that you don't grab sleep mutexes
with interrupts disabled, etc.

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


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

Re: CURRENT is freezing again ...

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Warner Losh writes:
In message [EMAIL PROTECTED] Sheldon Hearn writes:
: The problem with a hard lock-up out of which you can't escape into the
: debugger is that it makes meaningful bug reports impossible.  My non-SMP
: workstation has exhibited apparently arbitrary lock-ups since the advent
: of SMPng.

You can also short IOCHK to ground to get an NMI which kicks you into
the debugger, even in an interrupt context.

Bad news for you warner:  On a too large sample of my newer
motherboards this doesn't work anymore :-(

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


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

Re: CURRENT is freezing again ...

[Warner Losh]

In message 25636.974487067@critter Poul-Henning Kamp writes:
: In message [EMAIL PROTECTED], Warner Losh writes:
: In message [EMAIL PROTECTED] Sheldon Hearn writes:
: : The problem with a hard lock-up out of which you can't escape into the
: : debugger is that it makes meaningful bug reports impossible.  My non-SMP
: : workstation has exhibited apparently arbitrary lock-ups since the advent
: : of SMPng.
: 
: You can also short IOCHK to ground to get an NMI which kicks you into
: the debugger, even in an interrupt context.
: 
: Bad news for you warner:  On a too large sample of my newer
: motherboards this doesn't work anymore :-(

There's also a pci signal that you can either pull up or pull down
that's supposed to give you the same results.  I've never really
needed to know it.

Warner



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

Re: CURRENT is freezing again ...

[Kris Kennaway]

On Fri, Nov 17, 2000 at 12:55:28PM +0100, Soren Schmidt wrote:

  I thought I was the only one, since my question on the freebsd-current
  mailing list went unanswered.
 
 You are _not_ alone, there has been numerous complains about this
 on the list, but so far they have not been taken seriously :|

One of my non-SMP machines reliably wedges whenever I do heavy disk
I/O. I can't break to debugger.

Nov  4 15:46:41 mollari /boot/kernel/kernel: atapci0: Intel PIIX3 ATA controller 
port 0xffa0-0xffaf at device 7.1 on pci0
Nov  4 15:46:41 mollari /boot/kernel/kernel: ata0: at 0x1f0 irq 14 on atapci0
Nov  4 15:46:41 mollari /boot/kernel/kernel: ahc0: Adaptec 2940 Ultra SCSI adapter 
port 0xfc00-0xfcff mem 0xffbeb000-0xffbebfff irq 15 at device 11.0 on pci0
Nov  4 15:46:41 mollari /boot/kernel/kernel: aic7880: Wide Channel A, SCSI Id=7, 
16/255 SCBs

Kris
 PGP signature

Re: CURRENT is freezing again ...

[Mike Smith]

 : You can also short IOCHK to ground to get an NMI which kicks you into
 : the debugger, even in an interrupt context.
 : 
 : Bad news for you warner:  On a too large sample of my newer
 : motherboards this doesn't work anymore :-(
 
 There's also a pci signal that you can either pull up or pull down
 that's supposed to give you the same results.  I've never really
 needed to know it.

SERR behaviour is programmable and there is no standard for it. 8(

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




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

Re: CURRENT is freezing again ...

[Boris Popov]

On Thu, 16 Nov 2000, Soren Schmidt wrote:

  After last cvsup my machine (Dual PIII, SMP kernel) is freezing again in
  10 min after boot...
 
 You mean "is still freezing" right ?
 
 Current has been like this for longer than I care to think about, it
 seems those in charge doesn't take these problems seriously (enough)...

I think info about where/how it freezing would be more helpful.

 I've started doing development on -stable instead, it goes nowhere
 on -current

shurg - works fine for me even with my new evil hacks :)

--
Boris Popov
http://www.butya.kz/~bp/



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

Re: CURRENT is freezing again ...

[Steven E. Ames]

It seems to only do it SMP... the same machine built with a non-SMP
kernel (same source code) runs just fine for extended periods.

-Steve

- Original Message -
From: "Soren Schmidt" [EMAIL PROTECTED]
To: "Boris Popov" [EMAIL PROTECTED]
Cc: "Valentin Chopov" [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, November 16, 2000 12:17 PM
Subject: Re: CURRENT is freezing again ...


 It seems Boris Popov wrote:
  On Thu, 16 Nov 2000, Soren Schmidt wrote:
 
After last cvsup my machine (Dual PIII, SMP kernel) is freezing
again in
10 min after boot...
  
   You mean "is still freezing" right ?
  
   Current has been like this for longer than I care to think about,
it
   seems those in charge doesn't take these problems seriously
(enough)...
 
  I think info about where/how it freezing would be more helpful.

 No idea, the system just freezes, no drob to DDB no remote gdb no
 nothing, so its really hard to tell where...
 As to how, just boot current on a fairly fast machine, make a kernel
 and it'll hang in minutes if not less, or just leave it alone and
 it will hang in 10-30 mins...

 -Søren


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




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

Re: CURRENT is freezing again ...

[Gianmarco Giovannelli]

 It seems Boris Popov wrote:
  On Thu, 16 Nov 2000, Soren Schmidt wrote:
  
After last cvsup my machine (Dual PIII, SMP kernel) is freezing 
again in
10 min after boot...
   
   You mean "is still freezing" right ?
   
   Current has been like this for longer than I care to think about, 
it
   seems those in charge doesn't take these problems seriously 
(enough)...
  
  I think info about where/how it freezing would be more helpful.
 
 No idea, the system just freezes, no drob to DDB no remote gdb no
 nothing, so its really hard to tell where...
 As to how, just boot current on a fairly fast machine, make a kernel
 and it'll hang in minutes if not less, or just leave it alone and 
 it will hang in 10-30 mins...

I have the same problem on a dual PII 400mhz.
I haven't tried to remove the SMP support, but I have not too much time
to cvsup and to make anything else.

I'll try to boot the GENERIC (damn !%! , I always repeat to myself 
that is a good habits to compile the GENERIC too after updates... 
but I never do... :-( )




-- 
Regards...

Gianmarco
"Unix expert since yesterday"

http://www.giovannelli.it


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

Re: CURRENT is freezing again ...

[Alfred Perlstein]

* Steven E. Ames [EMAIL PROTECTED] [001116 09:27] wrote:
 It seems to only do it SMP... the same machine built with a non-SMP
 kernel (same source code) runs just fine for extended periods.

John just checked in some code last night that may address your
problems.

I would try a new kernel, and perhaps some collabaration with John
to debug these problems rather than just complaining about the
situation.  I see at least two experianced developers in the CC
list, there's no reason for these poor bug reports.

-Alfred



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

RE: CURRENT is freezing again ...

[John Baldwin]

On 16-Nov-00 Valentin Chopov wrote:
 Hi,
 
 After last cvsup my machine (Dual PIII, SMP kernel) is freezing again in
 10 min after boot...
 
 Thanks, 
 
 Val

Two questions:

1) What revision of sys/kern/kern_synch.c do you have?  I fixed several things
yesterday, and the latest version is 1.108.
2) If you do have the latest version, have you compiled a kernel with WITNESS,
INVARIANTS, and INVARIANT_SUPPORT to see how it runs?

Also, I have noticed that occasionally on my SMP boxes the console seems to
lose itself.  By lose itself, I mean that all output stops, and it doesn't
process any input.  If I hit Ctrl-Alt-Backspace to break into the debugger, it
suddenly catches up and processes all pending events before dropping into teh
debugger, but hangs again when I continue from ddb.  However, the rest of hte
machine works fine during this time.  I can ssh in, build kernels, reboot, etc.
without any problem.

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


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

Re: CURRENT is freezing again ...

[Soren Schmidt]

It seems John Baldwin wrote:
 
 1) What revision of sys/kern/kern_synch.c do you have?  I fixed several things
 yesterday, and the latest version is 1.108.

1.108

 2) If you do have the latest version, have you compiled a kernel with WITNESS,
 INVARIANTS, and INVARIANT_SUPPORT to see how it runs?

Have those in too...

It still cant compile a kernel, it hangs itself in ~30 secs, no messages,
no hints, no nothing, the machine just locks up solid as usual..

Mind you the same machines run 4.2 and PRE_SMPNG without a hitch...

 Also, I have noticed that occasionally on my SMP boxes the console seems to
 lose itself.  By lose itself, I mean that all output stops, and it doesn't
 process any input.  If I hit Ctrl-Alt-Backspace to break into the debugger, it
 suddenly catches up and processes all pending events before dropping into teh
 debugger, but hangs again when I continue from ddb.  However, the rest of hte
 machine works fine during this time.  I can ssh in, build kernels, reboot, etc.
 without any problem.

It has been like this almost since the SMPNG stuff vent in, at least on all my
-current machines...

-Søren


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

Re: CURRENT is freezing again ...

[Michael C . Wu]

On Thu, Nov 16, 2000 at 10:27:39PM +0100, Soren Schmidt scribbled:
| It seems John Baldwin wrote:
| 
|  1) What revision of sys/kern/kern_synch.c do you have?  I fixed several things
|  yesterday, and the latest version is 1.108.
|
| 1.108
|
|  2) If you do have the latest version, have you compiled a kernel with WITNESS,
|  INVARIANTS, and INVARIANT_SUPPORT to see how it runs?
|
| Have those in too...
|
| It still cant compile a kernel, it hangs itself in ~30 secs, no messages,
| no hints, no nothing, the machine just locks up solid as usual..
|
| Mind you the same machines run 4.2 and PRE_SMPNG without a hitch...
|
|  Also, I have noticed that occasionally on my SMP boxes the console seems to
|  lose itself.  By lose itself, I mean that all output stops, and it doesn't
|  process any input.  If I hit Ctrl-Alt-Backspace to break into the debugger, it
|  suddenly catches up and processes all pending events before dropping into teh
|  debugger, but hangs again when I continue from ddb.  However, the rest of hte
|  machine works fine during this time.  I can ssh in, build kernels, reboot, etc.
|  without any problem.
|
| It has been like this almost since the SMPNG stuff vent in, at least on all my
| -current machines...


I had those problems too a while ago on a UP p3-650 laptop.  Finally I just
newfs'ed the machine and installed the 20001028 snapshot, then cvsupp'ed
to 20001122.  The laptop now works well.  What I saw was processes
forking and forking again until the machine runs out of memory and
swap.  I think it may be some old libraries left over from
upgrades and make world.

--
+--+
| [EMAIL PROTECTED] | [EMAIL PROTECTED] |
| http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. |
+--+


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

Re: freezing and rebooting with vidcontrol -m on

[Adam]

Okay, answering my own question for the sake of the archive,  I believe it
was an on combination of some of the options   SC_something  that
vidcontrol -m on and my mouse and kernel didnt like.  I was using some to
save on kernel size and memory used but then decided to start using the
computer on the console again so I just commented all those SC feature
disabling out and all seems well. 


Adam wrote:
 
 Hi, I don't really know where to go with this issue on my own anymore so
 im tossing it to the list for suggestions.
 
 I had a celeron running in a Abit BX6-2 system running -current approx a
 month or 1.5 old. Today I moved the disks to a Abit BP6 Motherboard and
 recompiled the kernel for smp and the other hardware changes I intended to
 make.  Well, when I boot it up it would get down to approx "starting i386
 whatever" and the boot would stop, the keyboard wouldnt type (although
 numlock would work for x amount of time) and you couldnt drop into
 ddb.  Sometimes it would stick in this braindead mode, sometimes if you
 tried typing things to get it unstuck it would just reboot after a brief
 total keyboard lockup.  No panic, just a reboot.  I booted singleuser and
 cleaned up my rc.conf, disabling some noncritical things, and got the
 system booting fine.  I have a usb logitech mouse by the way.  Later I
 noticed no mouse cursor on my consoles even though I had moused running,
 so I ran vidcontrol -m on.  WHAM.  I had found the culprit.  Okay so I
 know what caused it and what not to run ;0 I took the opportunity to cvsup
 and upgrade the whole system to -current as of today, and to my dismay it
 still does the same thing.  I really wish I could drop into ddb when it
 happens but it wont let me.  If serial might be a better option I could
 probably dig out a null modem cable... Suggestions Please!
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message




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

Re: freezing and rebooting with vidcontrol -m on

[Kazutaka YOKOTA]

Okay, answering my own question for the sake of the archive,  I believe it
was an on combination of some of the options   SC_something  that
vidcontrol -m on and my mouse and kernel didnt like.  I was using some to
save on kernel size and memory used but then decided to start using the
computer on the console again so I just commented all those SC feature
disabling out and all seems well. 

Thank you for reporting.  Would you tell me which SC_XXX options
you used to have in your kernel configuration file?

Kazu


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

Re: freezing and rebooting with vidcontrol -m on

[Adam]

I dont recall exactly :( SC_NO_FONT_LOADING was one of them, I may have
commented one of the others in the old conf trying to fix it.  I have a
spare comp with a freebsd install I could play around with it on and see
if I can recreate it instead of goofing around with my server that had the
problem, fsck'ing 78 gigs is not pretty ;} (Yes I eventually stopped
mounting the big drives while testing but I still dont like torturing /
and /usr hehe)

On Sat, 10 Jun 2000, Kazutaka YOKOTA wrote:


Okay, answering my own question for the sake of the archive,  I believe it
was an on combination of some of the options   SC_something  that
vidcontrol -m on and my mouse and kernel didnt like.  I was using some to
save on kernel size and memory used but then decided to start using the
computer on the console again so I just commented all those SC feature
disabling out and all seems well. 

Thank you for reporting.  Would you tell me which SC_XXX options
you used to have in your kernel configuration file?

Kazu




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

Re: freezing and rebooting with vidcontrol -m on

[Adam]

On Sat, 10 Jun 2000, Matthew Thyer wrote:

Are you using power management (presumably so you can poweroff your
ATX system) ?

You must not use APM with an SMP kernel currently.

Remove the lines in your /etc/rc.conf that read:

apm_enable="YES"
apmd_enable="YES"

(Or change them to ="NO").

Or you can update your sources because this problem has just been fixed
(but there are suspend/resume problems with SMP still).

Been there, did that, suspend even works.  Waiting on lusers to logout so
I can reboot and try a new kernel, I think i might have been using some
console options it didnt like.  


Adam wrote:
 
 Hi, I don't really know where to go with this issue on my own anymore so
 im tossing it to the list for suggestions.
 
 I had a celeron running in a Abit BX6-2 system running -current approx a
 month or 1.5 old. Today I moved the disks to a Abit BP6 Motherboard and
 recompiled the kernel for smp and the other hardware changes I intended to
 make.  Well, when I boot it up it would get down to approx "starting i386
 whatever" and the boot would stop, the keyboard wouldnt type (although
 numlock would work for x amount of time) and you couldnt drop into
 ddb.  Sometimes it would stick in this braindead mode, sometimes if you
 tried typing things to get it unstuck it would just reboot after a brief
 total keyboard lockup.  No panic, just a reboot.  I booted singleuser and
 cleaned up my rc.conf, disabling some noncritical things, and got the
 system booting fine.  I have a usb logitech mouse by the way.  Later I
 noticed no mouse cursor on my consoles even though I had moused running,
 so I ran vidcontrol -m on.  WHAM.  I had found the culprit.  Okay so I
 know what caused it and what not to run ;0 I took the opportunity to cvsup
 and upgrade the whole system to -current as of today, and to my dismay it
 still does the same thing.  I really wish I could drop into ddb when it
 happens but it wont let me.  If serial might be a better option I could
 probably dig out a null modem cable... Suggestions Please!
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message




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

freezing and rebooting with vidcontrol -m on

[Adam]

Hi, I don't really know where to go with this issue on my own anymore so
im tossing it to the list for suggestions.

I had a celeron running in a Abit BX6-2 system running -current approx a
month or 1.5 old. Today I moved the disks to a Abit BP6 Motherboard and
recompiled the kernel for smp and the other hardware changes I intended to
make.  Well, when I boot it up it would get down to approx "starting i386
whatever" and the boot would stop, the keyboard wouldnt type (although
numlock would work for x amount of time) and you couldnt drop into
ddb.  Sometimes it would stick in this braindead mode, sometimes if you
tried typing things to get it unstuck it would just reboot after a brief
total keyboard lockup.  No panic, just a reboot.  I booted singleuser and
cleaned up my rc.conf, disabling some noncritical things, and got the
system booting fine.  I have a usb logitech mouse by the way.  Later I
noticed no mouse cursor on my consoles even though I had moused running,
so I ran vidcontrol -m on.  WHAM.  I had found the culprit.  Okay so I
know what caused it and what not to run ;0 I took the opportunity to cvsup
and upgrade the whole system to -current as of today, and to my dismay it
still does the same thing.  I really wish I could drop into ddb when it
happens but it wont let me.  If serial might be a better option I could
probably dig out a null modem cable... Suggestions Please! 



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

Re: freezing

[Brian Beattie]

On Fri, 18 Feb 2000, Adam wrote:

 I do not mean to throw blame on freebsd at all (unless tons of people also
 see this) but I had a freeze earlier today.  I had several windows open,
 netscape, and was compiling qt2 with not much disk activity at all when it
 just froze hard as a rock in all ways I can think of.  If it happens again
 I'll look into ddc and serial console or perhaps recreating on normal
 console.  I dont suspect hardware fault but I wouldn't dismiss it.
 
 On Thu, 17 Feb 2000, Joao Pedras wrote:
 
 Hello all
 
 While making -j 4 buildworld and moving a netscape window, everything frozen.
 Happens often if do other things while cpu and disk are very active.
 
 Happens quite often.
 
 Anyone else has noticed this ?
 

I have had a number of freezes, during a rm -rf  and a find at the same
time, during a cvs checkout, during a fsck on reboot.  The fsck caused a
message about an "SCB Timeout" I think.  I have returned to slightly
older 4.0-Current kernel and was going to build a new kernel.

I can try to get more information this evening, if anybody is interested.
For me the trigger seems to be heavy disk activity.

configuration summary:
K6-2 333, 80MB, aha2940(I think, adaptec PCI ultra), 4 2GB segate SCSI
drives.

Brian Beattie| The only problem with
[EMAIL PROTECTED]  | winning the rat race ...
www.aracnet.com/~beattie | in the end you're still a rat



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

Re: freezing

[Joao Pedras]

eheh

I mean dead frozen, like if I was watching at a screeshot of a X session ]:)

Alfred Perlstein wrote:
 
 Do you mean dead frozen, as in needs a reboot? or frozen for a second or
 so?
 
 The first one I haven't seen recently, the second I have noticed.
 
 -Alfred


  ^\   /^
O O
o00-(_)-00o--

Common sense is the collection of prejudices acquired by age eighteen.
-- Albert Einstein

-
PGP key available upon request or may be cut at 
http://pedras.webvolution.net/pgpkey.html



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

Re: freezing

[Alfred Perlstein]

* Joao Pedras [EMAIL PROTECTED] [000216 17:50] wrote:
 Hello all
 
 While making -j 4 buildworld and moving a netscape window, everything frozen.
 Happens often if do other things while cpu and disk are very active.
 
 Happens quite often.
 
 Anyone else has noticed this ?

Do you mean dead frozen, as in needs a reboot? or frozen for a second or
so?

The first one I haven't seen recently, the second I have noticed.

-Alfred


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

Re: freezing

[Alfred Perlstein]

* Joao Pedras [EMAIL PROTECTED] [000216 18:07] wrote:
 eheh
 
 I mean dead frozen, like if I was watching at a screeshot of a X session ]:)
 
 Alfred Perlstein wrote:
  
  Do you mean dead frozen, as in needs a reboot? or frozen for a second or
  so?
  
  The first one I haven't seen recently, the second I have noticed.
  
  -Alfred

oy!  well i guess you need to grab a serial console and see if you can
get a crashdump/traceback.  let us know if you find out, also check your
machine's cooling devices to make sure they are functioning normally.

good luck,
-Alfred


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

Re: freezing

[Oliver Brandmueller]

Hi,

On 17 Feb, Joao Pedras wrote:
 While making -j 4 buildworld and moving a netscape window, everything frozen.
 Happens often if do other things while cpu and disk are very active.
 
 Happens quite often.
 
 Anyone else has noticed this ?

I had that problem three times:

Once, when I tried using a K6-3 on my Gigabyte GA5-AX Motherboard. They
just weren't working together, when I changed back to a K6-2 (both
tried at 350 MHz) the problems disappeared. The K6-3 works fine now in
another machine (MSI Mainboard or something like that).

Another time something like that happened, when my cooler failed.

On one of my old Suns I had a similar problem, when one of the SIMMs
was damaged.


So, get on and check 'ya hardware.


Bye, Oliver



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

freezing

[Joao Pedras]

Hello all

While making -j 4 buildworld and moving a netscape window, everything frozen.
Happens often if do other things while cpu and disk are very active.

Happens quite often.

Anyone else has noticed this ?

Joao

  ^\   /^
O O
o00-(_)-00o--

Shaw's Principle:
Build a system that even a fool can use, and only a fool will
want to use it.

-
PGP key available upon request or may be cut at 
http://pedras.webvolution.net/pgpkey.html



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

Re: Very slow disk transfers (was: freezing)

[Alfred Perlstein]

* Greg Lehey [EMAIL PROTECTED] [000216 19:14] wrote:
 On Wednesday, 16 February 2000 at 17:52:42 -0800, Alfred Perlstein wrote:
  * Joao Pedras [EMAIL PROTECTED] [000216 17:50] wrote:
  Hello all
 
  While making -j 4 buildworld and moving a netscape window, everything frozen.
  Happens often if do other things while cpu and disk are very active.
 
  Happens quite often.
 
  Anyone else has noticed this ?
 
  Do you mean dead frozen, as in needs a reboot? or frozen for a second or
  so?
 
  The first one I haven't seen recently, the second I have noticed.
 
 I'm seeing the second situation.  I've been following it up and find
 that I have a number of requests which take an inordinate amount of
 time in the driver strategy routine:
 
 Feb 17 12:50:00 freebie /kernel: Request took 10.373469 seconds, dev 3.31, block 
5468256, length 16384
 
 The time here is between entering adstrategy (in this case) and
 biodone.  It happens on SCSI drives too, so it doesn't appear to be a
 problem with a specific driver.  If anybody has a suggestion what I
 should look for next, I'd be grateful.

Could you put up a patchset against -current up someplace that
includes these diagnostics?  I'd like to see if that's what's
nailing me.

thanks,
-Alfred


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

Re: freezing

[Chuck Robey]

On Thu, 17 Feb 2000, Joao Pedras wrote:

 eheh
 
 I mean dead frozen, like if I was watching at a screeshot of a X session ]:)

I used to get this on a game, which was trying somehow to load a font that
wasn't correct.  I found it wasn't really frozen, though, because you
*could* telnet in (very slow).  Are you *really* sure it's frozen?  Do you
have a network connection you can test telnet or ping with, or maybe a
serial terminal you could hook to it?

 
 Alfred Perlstein wrote:
  
  Do you mean dead frozen, as in needs a reboot? or frozen for a second or
  so?
  
  The first one I haven't seen recently, the second I have noticed.
  
  -Alfred
 
 
   ^\   /^
 O O
 o00-(_)-00o--
 
 Common sense is the collection of prejudices acquired by age eighteen.
 -- Albert Einstein
 
 -
 PGP key available upon request or may be cut at 
 http://pedras.webvolution.net/pgpkey.html
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message
 


Chuck Robey| Interests include C  Java programming, FreeBSD,
[EMAIL PROTECTED]  | electronics, communications, and signal processing.

New Year's Resolution:  I will not sphroxify gullible people into looking up
fictitious words in the dictionary.




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

Re: freezing...

[Pascal Hofstee]

On Mon, Jan 10, 2000 at 02:21:56PM -0800, Alfred Perlstein wrote:
 * Matthew Dillon [EMAIL PROTECTED] [000110 12:11] wrote:
  I've reproduced the softupdates ftruncate panic and have a core dump
  to play with.
 
 I don't have a panic, but rather many processes start to get stuck
 in "getblk", unfortunatly they all don't stem from a common codepath,
 although the first process that wedged appears to have come through
 indir_trunc:

I just experienced the same thing here on my CURRENT system with Kirk's
latest SoftUpdates patches included. i have right now a buildworld stuck in
"getblk" on rm ... and a "getblk" hang for Mozilla Tinderbox Build on gcc.

The Mozilla Tinderbox build "hang" however seems to be reproducible. 
I have had two consecutive "hangs" at the same spot:

checking for gtk-config... /usr/X11R6/bin/gtk-config

which results in a stuck gcc process.
I will try to build a kernel with kdb support as soon as my buildworld
finishes (if it will finish) and see if I can provide a proper backtrace.

-- 

  Pascal Hofstee - [EMAIL PROTECTED]

-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS d- s+: a-- C++ UB P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP--
t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+
--END GEEK CODE BLOCK--


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

Re: freezing...

[Robert C. Noland III]

FWIW, a couple weeks ago, I saw the same problem over NFS when autoconf
tried to test for gtk-config...  It would pretty consistantly hang...

robert.

Pascal Hofstee writes:
On Mon, Jan 10, 2000 at 02:21:56PM -0800, Alfred Perlstein wrote:
 * Matthew Dillon [EMAIL PROTECTED] [000110 12:11] wrote:
  I've reproduced the softupdates ftruncate panic and have a core dump
  to play with.
 
 I don't have a panic, but rather many processes start to get stuck
 in "getblk", unfortunatly they all don't stem from a common codepath,
 although the first process that wedged appears to have come through
 indir_trunc:

I just experienced the same thing here on my CURRENT system with Kirk's
latest SoftUpdates patches included. i have right now a buildworld stuck in
"getblk" on rm ... and a "getblk" hang for Mozilla Tinderbox Build on gcc.

The Mozilla Tinderbox build "hang" however seems to be reproducible. 
I have had two consecutive "hangs" at the same spot:

   checking for gtk-config... /usr/X11R6/bin/gtk-config

which results in a stuck gcc process.
I will try to build a kernel with kdb support as soon as my buildworld
finishes (if it will finish) and see if I can provide a proper backtrace.

-- 

  Pascal Hofstee - [EMAIL PROTECTED]

-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS d- s+: a-- C++ UB P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP--
t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+
--END GEEK CODE BLOCK--


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


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

Re: freezing...

[Doug Russell]

On Tue, 11 Jan 2000, Pascal Hofstee wrote:

 I just experienced the same thing here on my CURRENT system with Kirk's
 latest SoftUpdates patches included. i have right now a buildworld stuck in
 "getblk" on rm ... and a "getblk" hang for Mozilla Tinderbox Build on gcc.
 
 The Mozilla Tinderbox build "hang" however seems to be reproducible. 
 I have had two consecutive "hangs" at the same spot:
 
   checking for gtk-config... /usr/X11R6/bin/gtk-config
 
 which results in a stuck gcc process.
 I will try to build a kernel with kdb support as soon as my buildworld
 finishes (if it will finish) and see if I can provide a proper backtrace.

I think this goes away if you manually specify the path to gtk-config.  I
remember I had this problem some weeks ago while trying to build M12 on
-CURRENT.  I'm not saying you should need to do this, and it is likely a
compiler issue that is causing it, but I did get it to work without
modifying code.

Later.. Doug




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

Re: freezing...

[Joao Pedras]

Hello again

No, my problem is not ahc related. This single processor
system doesn't have any scsi

It's a :
PPro200/64MbRAM/8.4QuantumIDE/IntelVS440FX/Pioneer12x(which
is not detected after upgraded to -CURRENT)/Digital
21240 (de0)/S3 Virge

What I have in common with Christian is that it hangs
during high usage, as I mentioned in my first post (e.g.
compiling something, buildworld).

I performed a buildworld this night with yesterday's
code (in a common console) and it worked ok.
I ONLY noticed this when having high CPU usage (e.g.
compiling mysql port) when in using X.

I am not saying this is X related. Common point here
seems to be a busy system

Joao

Quoting "Dave J. Boers"
[EMAIL PROTECTED]:

 On Mon, Jan 10, 2000 at 04:10:37AM +0100, Christian
Carstensen wrote:
  this runs stable for 3 hours now...
  try a current kernel (checked out 4 hours ago),
using a version of the
  file /usr/src/sys/pci/ahc_pci.c from 2000/01/06. ok,
maybe it's not by
 any
  means stable, but works better than everything else
within the last 24
  hours.
 
 Actually, I've booted a kernel from just before
newyear (28 december) which
 works _reasonably_ fine (although it's the same kernel
that gave me the
 lockup earlier) with a userland of today. 
 
 Problem is that the lockups (I think) are ahc-related
and my SCSI hard
 drive did refuse to come online on one or two
occasions while booting the
 system cold... I therefore concluded that it might be
a problem with the
 hardware. Now (with the new kernel) I find the scsi
system unstable and I
 have doubts again. 
 
 One piece of information might also be useful in this
context. After the
 system lockup I sort of benchmarked the scsi
performance by doing "dd
 if=/dev/zero of=./testfile bs=100 count=128"
(actually I varied the
 blocksize) and got a _very poor_ performance of only 4
Mb/sec (which is
 usually around 10 to 12 Mb/sec). I isolated my drive
to be the only scsi
 device and I even clocked the SCSI bus down from 20
Mhz to 8 Mhz, but to no
 avail. 
 
 In the mean time, I disconnected my scsi hard drive
and I am running from
 my IDE disk.


---
Powered by Webvolution Networks


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

Re: freezing...

[Christian Carstensen]

On Mon, 10 Jan 2000, Joao Pedras wrote:

 What I have in common with Christian is that it hangs
 during high usage, as I mentioned in my first post (e.g.
 compiling something, buildworld).

this is funny:
the system operates well, even when on heavy load (especially disk load),
until i want a little more 8). to become more precisely, a cvs checkout or
make world is no problem, if - and that's really interesting - nothing
else requests the system's attention. i've had some successfully reproducable
crashes when generating much i/o usage (cvs, buildworld), which in fact
caused no problem, and then simply starting pine. at the moment, pine
opened the mail folder, all my noisy hard disks stopped and it was
perfectly quiet apart from cpu fans.


--
 Christian



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

Re: freezing...

[Dave J. Boers]

On Mon, Jan 10, 2000 at 03:35:47PM +0100, Christian Carstensen wrote:
 this is funny:
 the system operates well, even when on heavy load (especially disk load),
 until i want a little more 8). to become more precisely, a cvs checkout or
 make world is no problem, if - and that's really interesting - nothing
 else requests the system's attention. i've had some successfully reproducable
 crashes when generating much i/o usage (cvs, buildworld), which in fact
 caused no problem, and then simply starting pine. at the moment, pine
 opened the mail folder, all my noisy hard disks stopped and it was
 perfectly quiet apart from cpu fans.

That sounds exactly like the very dead state I found my system in when it
hang (I only have one occurence, so far, but my system isn't under very
heavy load lately). Make -j 9 buildworld completes fine. The hang seems to
have occured during a simple 20 Mb transfer of email data from my ide to my
scsi disk (which is a very short but i/o intensive operation). There might
have been an incoming email at the same time. 

I will try an idiotic buildworld -j 30 this evening just to see wether I
can hang the system reproducibly. Have to go now, however. 

Regards, 

Dave Boers. 

-- 
 Fatal error: replace user and try again.


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

Re: freezing...

[Poul-Henning Kamp]

In message [EMAIL PROTECTED]
, Christian Carstensen writes:
On Mon, 10 Jan 2000, Joao Pedras wrote:

 What I have in common with Christian is that it hangs
 during high usage, as I mentioned in my first post (e.g.
 compiling something, buildworld).

this is funny:
the system operates well, even when on heavy load (especially disk load),
until i want a little more 8).

I have a make world hanging here:

0 19914 19902 169  -2  0  1276  932 getblk D+p10:00.09 yacc -d -o 
c-parse.c c-parse.y


--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: freezing...

[Matthew Dillon]

I've reproduced the softupdates ftruncate panic and have a core dump
to play with.

-Matt



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

Re: freezing... update to 1.45 of ffs_softdep.c

[Matthew Dillon]

:I've reproduced the softupdates ftruncate panic and have a core dump
:to play with.
:
:   -Matt

Ok, Kirk fixed the softupdates ftruncate panic last night.  Make sure
you have version 1.45 of sys/contrib/softupdates/ffs_softdep.c

I would like to know if the person reporting the getblk lockup (I think
it was Poul) sees that problem solved with the vinum fix that Alfred
posted in regards to or whether we still have an open issue.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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

Re: freezing...

[Alfred Perlstein]

* Matthew Dillon [EMAIL PROTECTED] [000110 12:11] wrote:
 I've reproduced the softupdates ftruncate panic and have a core dump
 to play with.

I don't have a panic, but rather many processes start to get stuck
in "getblk", unfortunatly they all don't stem from a common codepath,
although the first process that wedged appears to have come through
indir_trunc:

 1442 d8ed2700 d93a 1001  1422  1422  004006  3  ranlib   getblk cc50a85(kgdb) 
proc 0xd8ed2700
(kgdb) bt
#0  mi_switch () at machine/globals.h:117
#1  0xc015d869 in tsleep (ident=0xcc50a850, priority=0x14, wmesg=0xc0292de1 "getblk", 
timo=0x0)
at ../../kern/kern_synch.c:437
#2  0xc0155b06 in acquire (lkp=0xcc50a850, extflags=0x20, wanted=0x600) at 
../../kern/kern_lock.c:147
#3  0xc0155dbc in lockmgr (lkp=0xcc50a850, flags=0x10022, interlkp=0xc030ba74, 
p=0xd8ed2700)
at ../../kern/kern_lock.c:362
#4  0xc017e73e in getblk (vp=0xd66dab20, blkno=0xe565a0, size=0x2000, slpflag=0x0, 
slptimeo=0x0) at ../../sys/buf.h:294
#5  0xc017c72a in bread (vp=0xd66dab20, blkno=0xe565a0, size=0x2000, cred=0x0, 
bpp=0xd93a1bb8)
at ../../kern/vfs_bio.c:498
#6  0xc02015af in indir_trunc (ip=0xd93a1bfc, dbn=0xe565a0, level=0x0, lbn=0xc, 
countp=0xd93a1bec)
at ../../ufs/ffs/ffs_softdep.c:2040
#7  0xc02013f5 in handle_workitem_freeblocks (freeblks=0xc2315300) at 
../../ufs/ffs/ffs_softdep.c:1961
#8  0xc0200e40 in softdep_setup_freeblocks (ip=0xc23ca200, length=0x0) at 
../../ufs/ffs/ffs_softdep.c:1668
#9  0xc01fead6 in ffs_truncate (vp=0xd9072860, length=0x0, flags=0x0, cred=0x0, 
p=0xd8ed2700)
at ../../ufs/ffs/ffs_inode.c:195
#10 0xc0209276 in ufs_inactive (ap=0xd93a1eb8) at ../../ufs/ufs/ufs_inode.c:84
#11 0xc020e3bd in ufs_vnoperate (ap=0xd93a1eb8) at ../../ufs/ufs/ufs_vnops.c:2283
#12 0xc0185145 in vput (vp=0xd9072860) at vnode_if.h:794
#13 0xc0188739 in unlink (p=0xd8ed2700, uap=0xd93a1f80) at 
../../kern/vfs_syscalls.c:1421
#14 0xc026f7ba in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 
0x808b300, tf_esi = 0x8076170, 
  tf_ebp = 0xbfbffa04, tf_isp = 0xd93a1fd4, tf_ebx = 0x8076160, tf_edx = 
0x8074060, tf_ecx = 0x0, tf_eax = 0xa, 
  tf_trapno = 0x7, tf_err = 0x2, tf_eip = 0x180c41cc, tf_cs = 0x1f, tf_eflags = 
0x293, tf_esp = 0xbfbff9c8, 
  tf_ss = 0x2f}) at ../../i386/i386/trap.c:1057

after that it starts spreading:

 1478 d8ed3480 d8f32000 1001  1477  1478  004006  3  zsh  getblk cc50b148
 1477 d8ed3a80 d8f24000 1001   369  1477  004106  3  rxvt getblk cc50b148
 1473 d8ed2a00 d8fbf000 1001  1466  1473  004006  3  cvs  getblk cc4a39e8

with varied tracebacks:
(kgdb) proc 0xd8ed3480
(kgdb) bt
#0  mi_switch () at machine/globals.h:117
#1  0xc015d869 in tsleep (ident=0xcc50b148, priority=0x14, wmesg=0xc0292de1 "getblk", 
timo=0x0)
at ../../kern/kern_synch.c:437
#2  0xc0155b06 in acquire (lkp=0xcc50b148, extflags=0x20, wanted=0x600) at 
../../kern/kern_lock.c:147
#3  0xc0155dbc in lockmgr (lkp=0xcc50b148, flags=0x10022, interlkp=0xc030ba74, 
p=0xd8ed3480)
at ../../kern/kern_lock.c:362
#4  0xc017e73e in getblk (vp=0xd66dcf60, blkno=0x20090, size=0x2000, slpflag=0x0, 
slptimeo=0x0) at ../../sys/buf.h:294
#5  0xc017c72a in bread (vp=0xd66dcf60, blkno=0x20090, size=0x2000, cred=0x0, 
bpp=0xd8f33dec)
at ../../kern/vfs_bio.c:498
#6  0xc01fe869 in ffs_update (vp=0xd8e880e0, waitfor=0x0) at 
../../ufs/ffs/ffs_inode.c:98
#7  0xc02092ca in ufs_inactive (ap=0xd8f33e40) at ../../ufs/ufs/ufs_inode.c:92
#8  0xc020e3bd in ufs_vnoperate (ap=0xd8f33e40) at ../../ufs/ufs/ufs_vnops.c:2283
#9  0xc018507d in vrele (vp=0xd8e880e0) at vnode_if.h:794
#10 0xc018bbb3 in vn_close (vp=0xd8e880e0, flags=0x1, cred=0xc2243c80, p=0xd8ed3480) 
at ../../kern/vfs_vnops.c:232
#11 0xc018c414 in vn_closefile (fp=0xc1fb6000, p=0xd8ed3480) at 
../../kern/vfs_vnops.c:630
#12 0xc01526fd in fdrop (fp=0xc1fb6000, p=0xd8ed3480) at ../../sys/file.h:211
#13 0xc015263b in closef (fp=0xc1fb6000, p=0xd8ed3480) at 
../../kern/kern_descrip.c:1003
#14 0xc0151d98 in close (p=0xd8ed3480, uap=0xd8f33f80) at ../../kern/kern_descrip.c:507
#15 0xc026f7ba in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 
0x80a9000, tf_esi = 0x1, 
  tf_ebp = 0xbfbff9c8, tf_isp = 0xd8f33fd4, tf_ebx = 0x1816d3c4, tf_edx = 
0x80a9138, tf_ecx = 0x2, tf_eax = 0x6, 
  tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x1812a22c, tf_cs = 0x1f, tf_eflags = 
0x283, tf_esp = 0xbfbff98c, 
  tf_ss = 0x2f}) at ../../i386/i386/trap.c:1057


(kgdb) proc 0xd8ed3a80
(kgdb) bt
#0  mi_switch () at machine/globals.h:117
#1  0xc015d869 in tsleep (ident=0xcc50b148, priority=0x14, wmesg=0xc0292de1 "getblk", 
timo=0x0)
at ../../kern/kern_synch.c:437
#2  0xc0155b06 in acquire (lkp=0xcc50b148, extflags=0x20, wanted=0x600) at 
../../kern/kern_lock.c:147
#3  0xc0155dbc in lockmgr (lkp=0xcc50b148, flags=0x10022, interlkp=0xc030ba74, 
p=0xd8ed3a80)
at ../../kern/kern_lock.c:362
#4  0xc017e73e in getblk (vp=0xd66dcf60, blkno=0x20090, 

Re: freezing... update to 1.45 of ffs_softdep.c

[Alfred Perlstein]

* Matthew Dillon [EMAIL PROTECTED] [000110 14:09] wrote:
 
 :I've reproduced the softupdates ftruncate panic and have a core dump
 :to play with.
 :
 : -Matt
 
 Ok, Kirk fixed the softupdates ftruncate panic last night.  Make sure
 you have version 1.45 of sys/contrib/softupdates/ffs_softdep.c
 
 I would like to know if the person reporting the getblk lockup (I think
 it was Poul) sees that problem solved with the vinum fix that Alfred
 posted in regards to or whether we still have an open issue.

still a problem, just got snagged a few moments ago, there's a traceback
already on the way. :)

-Alfred


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

Re: freezing... update to 1.45 of ffs_softdep.c

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Matthew Dillon writes:

I would like to know if the person reporting the getblk lockup (I think
it was Poul) sees that problem solved with the vinum fix that Alfred
posted in regards to or whether we still have an open issue.

I don't use vinum and -current as cvsup'ed right now has the problem.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: freezing... update to 1.45 of ffs_softdep.c

[Matthew Dillon]

: I would like to know if the person reporting the getblk lockup (I think
: it was Poul) sees that problem solved with the vinum fix that Alfred
: posted in regards to or whether we still have an open issue.
:
:still a problem, just got snagged a few moments ago, there's a traceback
:already on the way. :)
:
:-Alfred

Is this backed by the ata driver too?

If so, if either you or Poul could backoff to the wd driver and see
if the problem continues, I would appreciate it.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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

Re: freezing... update to 1.45 of ffs_softdep.c

[Matthew Dillon]

::still a problem, just got snagged a few moments ago, there's a traceback
::already on the way. :)
::
::-Alfred
:
:Is this backed by the ata driver too?
:
:If so, if either you or Poul could backoff to the wd driver and see
:if the problem continues, I would appreciate it.

I was able to reproduce it.  Never mind re: trying to use  
the 'wd' driver.  It occurs for me w/ SCSI.   It looks like
a softupdates problem for sure.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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

Re: freezing... update to 1.45 of ffs_softdep.c

[Alfred Perlstein]

* Matthew Dillon [EMAIL PROTECTED] [000110 15:13] wrote:
 ::still a problem, just got snagged a few moments ago, there's a traceback
 ::already on the way. :)
 ::
 ::-Alfred
 :
 :Is this backed by the ata driver too?
 :
 :If so, if either you or Poul could backoff to the wd driver and see
 :if the problem continues, I would appreciate it.
 
 I was able to reproduce it.  Never mind re: trying to use  
 the 'wd' driver.  It occurs for me w/ SCSI.   It looks like
 a softupdates problem for sure.

ugh, what fun this is, yes, i'm using vinum, softupdates, nfs and ata,
but da for the vinum backing.

I think i'm one of the bio bug posterboys.

Anyhow, it seems that the problem happens because somewhere softupdates
(or something else perhaps) LK_KERNPROCs the buffer and never lets go.

I've been trying to compile with DEBUG_LOCKS for nearly half an hour
but i'm having difficulty with vinum because i think it's intent on
giving me a hard time w/ matching itself and the kernel and the userland.

argh.. :)

-Alfred


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

Re: freezing... update to 1.45 of ffs_softdep.c

[Matthew Dillon]

The following patch should fix the problem temporarily until
Kirk can dig into it and figure out what went wrong.

-Matt

Index: sys/contrib//softupdates/ffs_softdep.c
===
RCS file: /FreeBSD/FreeBSD-CVS/src/sys/contrib/softupdates/ffs_softdep.c,v
retrieving revision 1.45
diff -u -r1.45 ffs_softdep.c
--- sys/contrib//softupdates/ffs_softdep.c  2000/01/10 08:39:03 1.45
+++ sys/contrib//softupdates/ffs_softdep.c  2000/01/11 00:20:55
@@ -1663,10 +1663,13 @@
 * still have a bitmap dependency, then the inode has never been
 * written to disk, so we can process the freeblks immediately.
 */
+#if 0
if ((inodedep-id_state  DEPCOMPLETE) == 0) {
FREE_LOCK(lk);
handle_workitem_freeblocks(freeblks);
-   } else {
+   } else 
+#endif
+   {
WORKLIST_INSERT(inodedep-id_bufwait, freeblks-fb_list);
FREE_LOCK(lk);
}


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

Re: freezing... update to 1.45 of ffs_softdep.c

[Alexander Litvin]

In article [EMAIL PROTECTED] you wrote:
 In message [EMAIL PROTECTED], Matthew Dillon writes:

I would like to know if the person reporting the getblk lockup (I think
it was Poul) sees that problem solved with the vinum fix that Alfred
posted in regards to or whether we still have an open issue.

 I don't use vinum and -current as cvsup'ed right now has the problem.

I just saw the same: two processes got frozen in getblk (tin and mutt).
No makeworld, no activity on the system at all -- just reading news and
mail. After a minute or so the whole system froze.

It's with version 1.46 of ffs_softdep.c 

 --
 Poul-Henning Kamp FreeBSD coreteam member
 [EMAIL PROTECTED]   "Real hackers run -current on their laptop."
 FreeBSD -- It will take a long time before progress goes too far!

--- 
"Nuclear war can ruin your whole compile."
-- Karl Lehenbauer


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

freezing...

[Joao Pedras]

Hello all!

Just wanted to ask if anyone else experiences hangs when just compiling
something, while using X ?

I know this is quite vague but I don't see any other pattern than this. I
tested with different window managers, compiling different stuff and sometimes
this misteriously happens.

This hardware has always been reliable (was?)

Joao

  ^\   /^
O O
o00-(_)-00o--

Computers are not intelligent.  They only think they are.

-
PGP key available upon request or may be cut at 
http://pedras.webvolution.net/pgpkey.html



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

Re: freezing...

[Joao Pedras]

mine's a single processor system

PPro200 on Intel VS440FX w/64Mb RAM

it just... freezes!

my smp system is running -stable, yet!

Christian Carstensen wrote:
 On Mon, 10 Jan 2000, Joao Pedras wrote:
 
 Just wanted to ask if anyone else experiences hangs when just compiling
 something, while using X ?
 
 I know this is quite vague but I don't see any other pattern than this. I
 tested with different window managers, compiling different stuff and
 sometimes
 this misteriously happens.
 
 This hardware has always been reliable (was?)
 
 same on my machine. my hardware has not been unstable, but since 3 or 4
 days ago, i see my system hanging without _any_ message, keyboard freezed,
 etc.pp. not only when running x11. seems to be some problem with the
 current kernel version.
 sorry, i probably can't do much debugging work in this case, as i don't
 see any error message. the kernel is not even dropping me to ddb.
 btw, this is a 2 processor pII and i haven't tried disabling SMP yet.
 
 --
  Christian


  ^\   /^
O O
o00-(_)-00o--

Excellent time to become a missing person.

-
PGP key available upon request or may be cut at 
http://pedras.webvolution.net/pgpkey.html



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

Re: freezing...

[Christian Carstensen]

ok, last mail before going to bed,

 it just... freezes!


maybe, that's not interesting at all, but every time the error occured on
my system, there was much disk usage (buildworld, cron scripts, ...
netscape ;)).

--
 Christian



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

Re: freezing...

[Dave J. Boers]

On Mon, Jan 10, 2000 at 12:43:49AM -, Joao Pedras wrote:
 it just... freezes!

Can any of you tell me wether you have SCSI in your system (the ahc
driver, perhaps)? I too had one of these strange lockups today (see earlier
post) and it seems SCSI related. The lockup occured during an I/O
operation. 

Now I cvsupped and I find the ahc driver panic-ing on boot time with a
parity error as well.

I was actually on the verge of concluding that it had to be a hardware
error, but doubts begin to raise again...

Regards, 

Dave Boers. 

-- 
  [EMAIL PROTECTED]


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

Re: freezing...

[Christian Carstensen]

On Mon, 10 Jan 2000, Dave J. Boers wrote:

 Can any of you tell me wether you have SCSI in your system (the ahc
 driver, perhaps)? I too had one of these strange lockups today (see earlier
 post) and it seems SCSI related. The lockup occured during an I/O
 operation. 
 
 Now I cvsupped and I find the ahc driver panic-ing on boot time with a
 parity error as well.

welcome to the club. world's getting more amazing with every checkout ;)

--
 Christian



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

Re: freezing...

[Christian Carstensen]

ok,

this runs stable for 3 hours now...
try a current kernel (checked out 4 hours ago), using a version of the
file /usr/src/sys/pci/ahc_pci.c from 2000/01/06. ok, maybe it's not by any
means stable, but works better than everything else within the last 24
hours.

--
 Christian




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

Re: freezing...

[Christian Carstensen]

  this runs stable for 3 hours now...
  try a current kernel (checked out 4 hours ago), using a version of the
  file /usr/src/sys/pci/ahc_pci.c from 2000/01/06. ok, maybe it's not by any
  means stable, but works better than everything else within the last 24
  hours.

grrr, after 10 mins fsck... i was wrong.

 Problem is that the lockups (I think) are ahc-related and my SCSI hard
 drive did refuse to come online on one or two occasions while booting the
 system cold... I therefore concluded that it might be a problem with the
 hardware. Now (with the new kernel) I find the scsi system unstable and I
 have doubts again. 

i'm using a ahc 7895 onboard on a tyan thunder 100. i've seen my cdrom
occasionally not coming up until power cycling. is this a known bug with
that controller?

 One piece of information might also be useful in this context. After the
 system lockup I sort of benchmarked the scsi performance by doing "dd
 if=/dev/zero of=./testfile bs=100 count=128" (actually I varied the
 blocksize) and got a _very poor_ performance of only 4 Mb/sec (which is
 usually around 10 to 12 Mb/sec). I isolated my drive to be the only scsi
 device and I even clocked the SCSI bus down from 20 Mhz to 8 Mhz, but to no
 avail. 

scsi performance is very bad on my system for a long time now. operating
on many small files, for example, my IBM DCAS-34330W is 100% busy with
only 1.2 MB/s.
i don't know why, but i suspect vinum in combination with some old scsi
devices to cause that. 


--
 Christian



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

Re: freezing...

[Dave J. Boers]

On Mon, Jan 10, 2000 at 04:10:37AM +0100, Christian Carstensen wrote:
 this runs stable for 3 hours now...
 try a current kernel (checked out 4 hours ago), using a version of the
 file /usr/src/sys/pci/ahc_pci.c from 2000/01/06. ok, maybe it's not by any
 means stable, but works better than everything else within the last 24
 hours.

Actually, I've booted a kernel from just before newyear (28 december) which
works _reasonably_ fine (although it's the same kernel that gave me the
lockup earlier) with a userland of today. 

Problem is that the lockups (I think) are ahc-related and my SCSI hard
drive did refuse to come online on one or two occasions while booting the
system cold... I therefore concluded that it might be a problem with the
hardware. Now (with the new kernel) I find the scsi system unstable and I
have doubts again. 

One piece of information might also be useful in this context. After the
system lockup I sort of benchmarked the scsi performance by doing "dd
if=/dev/zero of=./testfile bs=100 count=128" (actually I varied the
blocksize) and got a _very poor_ performance of only 4 Mb/sec (which is
usually around 10 to 12 Mb/sec). I isolated my drive to be the only scsi
device and I even clocked the SCSI bus down from 20 Mhz to 8 Mhz, but to no
avail. 

In the mean time, I disconnected my scsi hard drive and I am running from
my IDE disk.

Regards, 

Dave Boers. 

-- 
 [EMAIL PROTECTED]


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

Re: freezing...

[Dave J. Boers]

On Mon, Jan 10, 2000 at 04:48:08AM +0100, Christian Carstensen wrote:
 i'm using a ahc 7895 onboard on a tyan thunder 100. i've seen my cdrom
 occasionally not coming up until power cycling. is this a known bug with
 that controller?

Mine is an AIC 7860 (i.e. 2940UA). I see my hard disk failing to come up
occasionally, but only after I turn my power on after the system had been
turned completely off (which is not often).
 
 scsi performance is very bad on my system for a long time now. operating
 on many small files, for example, my IBM DCAS-34330W is 100% busy with
 only 1.2 MB/s.
 i don't know why, but i suspect vinum in combination with some old scsi
 devices to cause that. 

What I'm going to say here may be complete crap, but it has been on my mind
for some time now, so I may just as well speak up with my suspicions. 

I have read on several occasions that people find -current performing very
poorly lately. I recall someone comparing -current's network performance to
that of 3.4 and finding almost a factor 2 difference. 

I myself have found the following facts lately: 
1) scsi performance is down to 4 Mb/sec MAX, writing simply zero's (this
   used to be around 12 Mb/sec)
2) network performance (NIC = 3COM 3C905B-TX 100Mbit) is 5 Mb/sec MAX
   instead of the 8 Mb/sec I'm used to. 
3) IDE UDMA66 performance is down to 12 Mb/sec writing zero's (this used to
   be near 16 Mb/sec). 
4) buildworlds are at an all time slow. I haven't been able to compile a
   current in less than an hour for many weeks now. This used to be more 
   like 40 minutes or so (make buildworld -j 9 on my smp system). 

Add to this the strange lockups we've been having recently that somehow
seem i/o or load dependent. 

I'm no expert on this at all, but it seems legitimate to conclude that
something is seriously wrong somewhere. It seems to me that this should
_definitely_ get sorted out to the bottom before release time. 

Regards, 

Dave Boers. 

-- 
 [EMAIL PROTECTED]


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