Mozilla problem

2005-03-07 Thread Warren
Each time i start Mozilla Firefox it starts from scratch and asks if i want to 
import my previous bookmarks etc .. why is this occurying and how do i fix 
it ?
-- 
Yours Sincerely
Shinjii
http://www.shinji.nq.nu
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Mozilla problem

2005-03-07 Thread Warren
On Mon, 7 Mar 2005 9:08 pm, Mark Sergeant wrote:
 On 07/03/2005, at 21:04, Warren wrote:
  Each time i start Mozilla Firefox it starts from scratch and asks if
  i want to
  import my previous bookmarks etc .. why is this occurying and how do
  i fix
  it ?

 What are the permissions on your ~/.mozilla directory ?


drwxr-xr-x   8 shinjii  shinjii  512 Mar  7 20:59 .mozilla
-- 
Yours Sincerely
Shinjii
http://www.shinji.nq.nu
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


RELENG_5, snapshots and disk lock time

2005-03-07 Thread Dmitry Morozovsky
Dear colleagues,

dumping the snapshot of 140G ufs2 fyle system under contemporary RELENG_5 I 
found that during mksnap_ffs file system is unresponsible even for reading for 
more than 3 minutes (it's on modern SATA disk with 50+ MBps linear transfer). 
Is it normal?

Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]

*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


ipmon not logging on freebsd sparc64

2005-03-07 Thread Jacco Ligthart
Hi all,
my brand new FreeBSD 5.3 on a sparc64 does not log packages marked with 
log in ipfilter. I've found that this is probably the same issue 
described here:

http://mail-index.netbsd.org/port-sparc64/2002/06/28/0002.html
(the second isue)
when i apply this patch and rebuild my kernel, ipmon starts logging happily.
I hope this can be included in cvs.
greetings,
Jacco Ligthart
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: Dell pe1550 (smp) on RELENG_5 ?

2005-03-07 Thread Robin P. Blanchard


 -Original Message-
 From: Doug White [mailto:[EMAIL PROTECTED] 
 Sent: Saturday, March 05, 2005 2:46 AM
 To: Robin P. Blanchard
 Cc: [EMAIL PROTECTED]
 Subject: Re: Dell pe1550 (smp) on RELENG_5 ?
 
 On Thu, 3 Mar 2005, Robin P. Blanchard wrote:
 
  Anyone succesfully accomplished this ?
  Seems I have to disable apic to get the box to sucessfully boot 
  (otherwise will hang), thereby disabling smp.
 
 I have -CURRENT running on a PE1750 without issues. I have a 
 PE1650 that I'm waiting on rails for and a PE1550 I can 
 temporarily ursurp. Does it also hang under 5.3-R?
 
 I had some odd problems with a PE2450 that turned out to be a 
 screwed up fxp pci card. Taking the card out got the machine 
 booting again. Do you have any cards in this system?

It seems that disabling NO_MIXED_MODE allows the 1550s to succesfully operate
in smp mode.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: RELENG_5, snapshots and disk lock time

2005-03-07 Thread Dmitry Morozovsky
On Mon, 7 Mar 2005, Xin LI wrote:

XL  dumping the snapshot of 140G ufs2 fyle system under contemporary RELENG_5 
I 
XL  found that during mksnap_ffs file system is unresponsible even for 
reading for 
XL  more than 3 minutes (it's on modern SATA disk with 50+ MBps linear 
transfer). 
XL  Is it normal?
XL 
XL mksnap_ffs is expected to suspend your write access, but I think 3
XL minutes is too long for a 140G file system.  Would you please send the
XL dumpfs output of the said file system?

Well, as I said, it was even for read access. I checked this with the simple 
shell script

#!/bin/sh

while true; do
sleep 5
date
ls /lh/.snap
done

when dump -L executes mksnap_ffs for /lh, there is 3:20 pause between dates.

dumpfs output is available at http://woozle.hole.ru/misc/dumpfs-lh.gz (83k)

Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]

*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


UPDATE 5.3-STABLE was Re: Possible problems with Broadcom BCM5704C 10/100/1000 on TyanThunder K8S pro S2882 twin Operteron

2005-03-07 Thread Alan Jay
Hi,

Well after upgrading to the latest -STABLE via cvsup and makeworld makekernel
etc we have been doing some more tests over the weekend.

One of our databases ran fine all weekend so we took the plunge on Sunday to
try our big heavily accessed database.

It ran fine until 7.45 Monday morning - when I checked at 7.30am it was using
around 6 of the 8Gb of RAM the server then logged:

Mar  7 07:42:47 flappy kernel: bge1: discard frame w/o leading ethernet header
(len 4294967292 pkt len 4294967292)

Followed by:

Mar  7 07:42:47 flappy kernel: Fatal trap 12: pag
Mar  7 07:42:47 flappy kernel: e f
Mar  7 07:42:47 flappy kernel: ault
Mar  7 07:42:47 flappy kernel: wh
Mar  7 07:42:47 flappy kernel: ile in
Mar  7 07:42:47 flappy kernel: k
Mar  7 07:42:47 flappy kernel: er
Mar  7 07:42:47 flappy kernel: ne
Mar  7 07:42:47 flappy kernel: l mode
Mar  7 07:42:47 flappy kernel:
Mar  7 07:42:47 flappy kernel: cp
Mar  7 07:42:47 flappy kernel: ui
Mar  7 07:42:47 flappy kernel: d
Mar  7 07:42:47 flappy kernel: =
Mar  7 07:42:47 flappy kernel: 1;
Mar  7 07:42:47 flappy kernel: a
Mar  7 07:42:47 flappy kernel: pi
Mar  7 07:42:47 flappy kernel: c
Mar  7 07:42:47 flappy kernel: i
Mar  7 07:42:47 flappy kernel: d
Mar  7 07:42:47 flappy kernel: =
Mar  7 07:42:47 flappy kernel: 01
Mar  7 07:42:47 flappy kernel:
Mar  7 07:42:47 flappy kernel: fa
Mar  7 07:42:47 flappy kernel: ul
Mar  7 07:42:47 flappy kernel: t
Mar  7 07:42:47 flappy kernel: vi

Subsequently to that it has crashed a number of times and on a couple of
occasions has reported:

kernel: fxp0: can't map mbuf (error 12)

To my uninitiated eye it looks like this might have something to do with the
Network Performance Project which seems to be tinkering in this area but I
would appreciate any thoughts anyone might have regarding this.

By the way over the weekend the latest -STABLE which is marked 5.4-PRERELEASE
2 seemed much better than 5.3 had and the initial problems took much longer to
appear.  Though once the problems started to appear, they repeated themselves
rebooting every 1-2hrs until we removed the tests data.

Thanks for the guidance,
ALan

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: RELENG_5, snapshots and disk lock time

2005-03-07 Thread Dmitry Morozovsky
Following up to myself

DM XL  dumping the snapshot of 140G ufs2 fyle system under contemporary 
RELENG_5 I 
DM XL  found that during mksnap_ffs file system is unresponsible even for 
reading for 
DM XL  more than 3 minutes (it's on modern SATA disk with 50+ MBps linear 
transfer). 
DM XL  Is it normal?
DM XL 
DM XL mksnap_ffs is expected to suspend your write access, but I think 3
DM XL minutes is too long for a 140G file system.  Would you please send the
DM XL dumpfs output of the said file system?
DM 
DM Well, as I said, it was even for read access. I checked this with the 
simple 
DM shell script
DM 
DM #!/bin/sh
DM 
DM while true; do
DM sleep 5
DM date
DM ls /lh/.snap
DM done

It seems accessing snapshot directory is blocked for much more time than to 
other fs parts. Changing ls line to ``ls /lh'' leads to 

Mon Mar  7 18:02:58 MSK 2005
backup  homelocal   pgsql   ports   src
Mon Mar  7 18:03:41 MSK 2005

so file system has been locked for approx 45 seconds. This seems more 
reasonable, but still seems a bit too long for me.


Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]

*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: if_bfe/uhci: storm interrupt Fatal trap 12

2005-03-07 Thread pcasidy
On  4 Mar, Doug White wrote:

 
 Hm ... dunno. You might try one of the RELENG_5 snapshots that will be
 coming out shortly as we get into the 5.4-R release cycle. There is some
 improvements to interrupt routing in there.
 

In fact I have try the CURRENT SNAP (2005 february snap) because I can
get a call stack.

Here is the steps I perform to get to the call stack.

1- I boot with the snapshot miniinst
2- Selecting keymap (french accent)
3- Fixit mode
4- Emergency shell
5- using Alt-F4 to go to the terminal
6- typing: ifconfig bfe0 192.168.1.1 = the shell freeze
7- using Alt-F1 to go back to the 1st terminal where there is a panic
   message:
handwritten typescript
cpuid = 0
KDB: enter: panic
[thread pid 29 tid 100030 ]
Stopped at  kdb_enter+0x2b: nop
db where  -- command entered
Tracing pid 29 tid 100030 td 0xc2ff1000
kdb_enter(c0823108) at kdb_enter+0x2b
panic(c083ca28,deadc000,c07c9462,0,8000) at panic+0x127
vm_fault(c1459000,deadc000,1,0,c2ff1000) at vm_fault+0x1e1
trap_pfault(e5e61c50,0,deadc0ee) at trap_pfault+0x13b
trap(c0830018,10,10,c3105000,c3102400) at trap+0x335
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc07a810, esp = 0xe5e61c90, ebp = 0xe5e61c98 ---
_bus_dmamap_unload(c3102400,c3104540) at _bus_dmamap_unload+0x16
bfe_rx_ring_free(c3105000,c3105000,c3105000,e5e61cd8,c04dd0a3) at
   bfe_rx_ring_free+0x50
bfe_stop(c3105000,400,c3105000,e5e61cf4,c04dcae7) at bfe_stop+0x45
bfe_init_locked(c3105000) at bfe_init_locked+0x33
bfe_intr(c3105000) at bfe_intr+0x9f
ithread_loop(c2fe9500,e5e61d48,c2fe9500,c0601a54,0) at
   ithread_loop+0x120
fork_exit(c0601a54,c2fe9500,e5e61d48) at fork_exit+0xa4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe5e61d7c, ebp = 0 ---
db 


I hope there is not a lot of mistakes by copying the trace by hand.



Phil.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: RELENG_5, snapshots and disk lock time

2005-03-07 Thread Xin LI
 2005-03-07 18:00 +0300Dmitry Morozovsky
 On Mon, 7 Mar 2005, Xin LI wrote:
 
 Well, as I said, it was even for read access. I checked this with the simple 
 shell script
 
 #!/bin/sh
 
 while true; do
   sleep 5
   date
   ls /lh/.snap
 done
 
 when dump -L executes mksnap_ffs for /lh, there is 3:20 pause between dates.
 
 dumpfs output is available at http://woozle.hole.ru/misc/dumpfs-lh.gz (83k)

The dumpfs output seems quite normal.  I'll try to figure out what was
happening tomorrow with some large volume equipment.

Cheers,
-- 
Xin LI delphij delphij net  http://www.delphij.net/


signature.asc
Description: 	=?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?=	=?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8?= =?UTF-8?Q?=E5=88=86?=


FreeBSD 5.3 freezes under heavy hdd load

2005-03-07 Thread cyb
Hello,

 from time to time my FreeBSD freezes under heavy hdd load and only a
hard reset will bring it back to life with fsck complaining about
'Softupdate Inconsistencies'.

I had this behaviour on 5.3-RELEASE, 5.3-RELEASE-p5 and now i have it on
5.4-PRERELEASE. I am using a custom kernel with SMP enabled on a P4
3.2GHz for hyperthreading. One hdd is a SATA drive and it acts fine. The
other hdd however is an ATA133 drive and i suspect it to be the problem,
since freezes only occur when it is busy (eg. copying much data from a
DVD/HDD to it or compiling a port). Whenever the system freezes there is
no warning or log entry at all.

I used 'smartmontools' to check the drive, but there was not found
anything and the hdd appeared to be fully operational.

Could the freezes come from a faulty IDE hdd (which would mean that I
better get rid of it), or are there other possiblities.

Thank you,
Andreas Rudisch

-- 
GnuPG key  : 0xD25FCC81  |  http://cyb.websimplex.de/pubkey.asc
Fingerprint: D182 6F22 7EEC DD4C 0F6E  564C 691B 0372 D25F CC81



signature.asc
Description: This is a digitally signed message part


Re: FreeBSD 5.3 freezes under heavy hdd load

2005-03-07 Thread John Nielsen
On Monday 07 March 2005 09:38 am, cyb wrote:
  from time to time my FreeBSD freezes under heavy hdd load and only a
 hard reset will bring it back to life with fsck complaining about
 'Softupdate Inconsistencies'.

I had similar issues on an Athlon machine under 5.3.  In my case it turned 
out that the CPU was running extremely hot.  It would frequently freeze 
while portupgrade was backing up old versions of a port.  I initially 
suspected a disk problem as well, but I haven't yet had any problems since 
cleaning my CPU and chipset fans.  On reflection, my freezes were probably 
due to the CPU running hotter than usual when running bzip2 (which I 
believe is how portupgrade stores its backups, and is very CPU-intensive).

It is possible that your drive is the culprit, but you would probably get 
console messages about I/O failures rather than just a hard freeze.

Flaky memory or power supply are also possibilities.

JN
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: RELENG_5, snapshots and disk lock time

2005-03-07 Thread Paul Mather
On Mon, 2005-03-07 at 15:21 +0300, Dmitry Morozovsky wrote:
 Dear colleagues,
 
 dumping the snapshot of 140G ufs2 fyle system under contemporary RELENG_5 I 
 found that during mksnap_ffs file system is unresponsible even for reading 
 for 
 more than 3 minutes (it's on modern SATA disk with 50+ MBps linear transfer). 
 Is it normal?

Oddly enough, this happened to me last night on a RELENG_5 system.  In
my case, things were so bad that mksnap_ffs appeared to wedge
everything, meaning I'll have to make a trek in to where the machine is
located and press the ol' reset button to get things going again. :-(

The machine in question makes and mounts snapshots of all its
filesystems for backup each night via Tivoli TSM.  This has worked
flawlessly for many months.  Last night, I had many BitTorrent sessions
active on the filesystem that wedged.  I guess the activity broke the
snapshot mechanism. :-(  The odd thing is that it survived the night
before, when there were also BitTorrent sessions active.

I wonder how much activity mksnap_ffs can take?

Cheers,

Paul.

PS: The problematic file system was not low on space, which could be an
issue for snapshot creation.
-- 
e-mail: [EMAIL PROTECTED]

Without music to decorate it, time is just a bunch of boring production
 deadlines or dates by which bills must be paid.
--- Frank Vincent Zappa
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD 5.3 freezes under heavy hdd load

2005-03-07 Thread Oliver Brandmueller
Hi.

On Mon, Mar 07, 2005 at 05:38:29PM +0100, cyb wrote:
 Could the freezes come from a faulty IDE hdd (which would mean that I
 better get rid of it), or are there other possiblities.

How much RAM do you have? I also had a freezing problem on a machine 
with 4 GB of RAM. As soon as I reduced the RAM to 2 GB the machine 
became stable. I've played around with KVA_PAGES, vm.kmem_size_max and 
could only influence the time it took to crash the machine.

- Oliver

-- 
| Oliver Brandmueller | Offenbacher Str. 1  | Germany   D-14197 Berlin |
| Fon +49-172-3130856 | Fax +49-172-3145027 | WWW:   http://the.addict.de/ |
|   Ich bin das Internet. Sowahr ich Gott helfe.   |
| Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! |


pgplYbFp9s3hY.pgp
Description: PGP signature


Re: RELENG_5, snapshots and disk lock time

2005-03-07 Thread Kris Kennaway
On Mon, Mar 07, 2005 at 11:58:02AM -0500, Paul Mather wrote:
 On Mon, 2005-03-07 at 15:21 +0300, Dmitry Morozovsky wrote:
  Dear colleagues,
  
  dumping the snapshot of 140G ufs2 fyle system under contemporary RELENG_5 I 
  found that during mksnap_ffs file system is unresponsible even for reading 
  for 
  more than 3 minutes (it's on modern SATA disk with 50+ MBps linear 
  transfer). 
  Is it normal?
 
 Oddly enough, this happened to me last night on a RELENG_5 system.  In
 my case, things were so bad that mksnap_ffs appeared to wedge
 everything, meaning I'll have to make a trek in to where the machine is
 located and press the ol' reset button to get things going again. :-(

Yes, this is normal.  See the documentation about the snapshots
implementation (a README in the kernel source tree, I think, and paper
written by Kirk).

 The machine in question makes and mounts snapshots of all its
 filesystems for backup each night via Tivoli TSM.  This has worked
 flawlessly for many months.  Last night, I had many BitTorrent sessions
 active on the filesystem that wedged.  I guess the activity broke the
 snapshot mechanism. :-(  The odd thing is that it survived the night
 before, when there were also BitTorrent sessions active.

It's possible there are still deadlock conditions in the snapshot
code.  Some familiarity with DDB would help to diagnose this (see the
chapter on kernel debugging in the developers' handbook).  You'd need
to work with Kirk to debug these, if you're willing.

 I wonder how much activity mksnap_ffs can take?

I don't think this is the issue, directly.

Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD 5.3 freezes under heavy hdd load

2005-03-07 Thread Kris Kennaway
On Mon, Mar 07, 2005 at 06:10:09PM +0100, Oliver Brandmueller wrote:
 Hi.
 
 On Mon, Mar 07, 2005 at 05:38:29PM +0100, cyb wrote:
  Could the freezes come from a faulty IDE hdd (which would mean that I
  better get rid of it), or are there other possiblities.
 
 How much RAM do you have? I also had a freezing problem on a machine 
 with 4 GB of RAM. As soon as I reduced the RAM to 2 GB the machine 
 became stable. I've played around with KVA_PAGES, vm.kmem_size_max and 
 could only influence the time it took to crash the machine.

It is necessary to increase KSTACK_PAGES (e.g. to 4) on machines with
certain patterns of heavy disk write load to avoid double faults in
the softupdates code (softupdates has potentially unbounded call stack
and can overflow the default kernel stack size without too much
effort).  This would cause panics though, not freezes.

Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD 5.3 freezes under heavy hdd load

2005-03-07 Thread cyb
On Mon, 2005-03-07 at 09:54 -0700, John Nielsen wrote:
 Flaky memory or power supply are also possibilities.

On Mon, 2005-03-07 at 18:10 +0100, Oliver Brandmueller wrote:
 How much RAM do you have? I also had a freezing problem on a machine 
 with 4 GB of RAM. As soon as I reduced the RAM to 2 GB the machine 
 became stable. I've played around with KVA_PAGES, vm.kmem_size_max
 and 
 could only influence the time it took to crash the machine.

I have 1GB (2x512MB) PC3200 DDR memory, memtest86 hasn't found anything.

Andreas

-- 
GnuPG key  : 0xD25FCC81  |  http://cyb.websimplex.de/pubkey.asc
Fingerprint: D182 6F22 7EEC DD4C 0F6E  564C 691B 0372 D25F CC81



signature.asc
Description: This is a digitally signed message part


Floppy problems

2005-03-07 Thread pbowen
Sirs:

I'm having a problem doing newfs to a floppy on a new installation. I tried 
changing to a new floppy and get the same thing.

# fdformat -f 1440 /dev/fd0
Format 1440K floppy `/dev/fd0'? (y/n): y
Processing  done.
# bsdlabel -B -w /dev/fd0 fd1440
# newfs /dev/fd0
newfs: wtfs: 512 bytes at sector 2879: Input/output error
# newfs_msdos /dev/fd0
/dev/fd0: 2840 sectors in 355 FAT12 clusters (4096 bytes/cluster)
bps=512 spc=8 res=1 nft=2 rde=512 sec=2880 mid=0xf0 spf=2 spt=18 hds=2 hid=0
newfs_msdos: /dev/fd0: Input/output error
#

If I take a linux formatted floppy, mount it, then ls on the mount point, I 
can get the dir listing. Or if I less a file on the floppy I can read the 
contents. Any attempt to use vi or to write to the floppy fails with 
another Input/Output error.

# uname -a
FreeBSD  5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov  5 04:19:18 UTC 2004 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386
#

Can you help? TIA.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Typo in UPDATING for RELENG_5

2005-03-07 Thread Andre Guibert de Bruet
Hi
I spotted a typo in RELENG_5's 20050302 UPDATING entry. It reads:
...
This option has to be specified in addition to IPFIRWALL_FORWARD.
...
The option enumerated should be IPFIREWALL_FORWARD.
Regards,
Andy
| Andre Guibert de Bruet | Enterprise Software Consultant 
| Silicon Landmark, LLC. | http://siliconlandmark.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD 5.3 freezes under heavy hdd load

2005-03-07 Thread Brian Reichert
On Mon, Mar 07, 2005 at 05:12:44PM +, Kris Kennaway wrote:
 It is necessary to increase KSTACK_PAGES (e.g. to 4) on machines with
 certain patterns of heavy disk write load to avoid double faults in
 the softupdates code (softupdates has potentially unbounded call stack
 and can overflow the default kernel stack size without too much
 effort).

Can these 'certain patterns' be characterized?  I've got a system
that hangs on haavy rsync usage, where the file sizes can me measured
in a half-gig or more...

 This would cause panics though, not freezes.

I can't tell remotely if all of my hangs are panics, as it's a
remote box.  Once, on the console of a hung box, I found

  panic: worklist_remove: not on list

This box did not reboot of it's own accord, and has wedged again
under a similar workload...

 Kris
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to [EMAIL PROTECTED]

-- 
Brian Reichert  [EMAIL PROTECTED]
55 Crystal Ave. #286Daytime number: (603) 434-6842
Derry NH 03038-1725 USA BSD admin/developer at large
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: I can not surf on Flash powered sites.

2005-03-07 Thread Don Lewis
On  6 Mar, Don Lewis wrote:

 Flash 6 sometimes works for me, but sometimes it segfaults.

[ snip ]
 firefox-1.0.1_1,1
 linux-flashplugin-6.0r79_2
 linuxpluginwrapper-20050119_1
 linux_base-8-8.0_6

Here's another stack trace:

Program received signal SIGSEGV, Segmentation fault.
0x29fa64d2 in ?? () from /usr/local/lib/linux-flashplugin6/libflashplayer.so
(gdb) whre
Undefined command: whre.  Try help.
(gdb) where
#0  0x29fa64d2 in ?? ()
   from /usr/local/lib/linux-flashplugin6/libflashplayer.so
#1  0x29fa69e8 in ?? ()
   from /usr/local/lib/linux-flashplugin6/libflashplayer.so
#2  0x281a8c3b in nsCOMPtr_base::~nsCOMPtr_base ()
   from /usr/X11R6/lib/firefox/libxpcom.so
#3  0x293f6a18 in nsHTMLPluginObjElementSH::GetPluginJSObject ()
   from /usr/X11R6/lib/firefox/components/libgklayout.so
#4  0x293f5ed2 in nsHTMLExternalObjSH::PostCreate ()
   from /usr/X11R6/lib/firefox/components/libgklayout.so
#5  0x28bc2067 in XPCWrappedNative::GetNewOrUsed ()
   from /usr/X11R6/lib/firefox/components/libxpconnect.so
#6  0x28bb09fc in XPCConvert::NativeInterface2JSObject ()
   from /usr/X11R6/lib/firefox/components/libxpconnect.so
#7  0x28ba6f42 in nsXPConnect::WrapNative ()
   from /usr/X11R6/lib/firefox/components/libxpconnect.so
#8  0x293e7216 in nsDOMClassInfo::WrapNative ()
   from /usr/X11R6/lib/firefox/components/libgklayout.so
#9  0x293f2775 in nsNamedArraySH::GetProperty ()
   from /usr/X11R6/lib/firefox/components/libgklayout.so
#10 0x28bc9b79 in xpc_MarkForValidWrapper ()
   from /usr/X11R6/lib/firefox/components/libxpconnect.so
#11 0x280c9658 in js_GetProperty () from /usr/X11R6/lib/firefox/libmozjs.so
#12 0x280bdc25 in js_Interpret () from /usr/X11R6/lib/firefox/libmozjs.so
#13 0x280b7bcf in js_Execute () from /usr/X11R6/lib/firefox/libmozjs.so
#14 0x28097284 in JS_EvaluateUCScriptForPrincipals ()
   from /usr/X11R6/lib/firefox/libmozjs.so
#15 0x293c2cc6 in nsJSContext::EvaluateString ()
   from /usr/X11R6/lib/firefox/components/libgklayout.so
#16 0x293fe972 in nsJSThunk::EvaluateScript ()
   from /usr/X11R6/lib/firefox/components/libgklayout.so
#17 0x293ff3fb in nsJSChannel::InternalOpen ()
   from /usr/X11R6/lib/firefox/components/libgklayout.so
#18 0x293ff360 in nsJSChannel::AsyncOpen ()
   from /usr/X11R6/lib/firefox/components/libgklayout.so
#19 0x296c95f4 in nsPluginHostImpl::NewPluginURLStream ()
   from /usr/X11R6/lib/firefox/components/libgkplugin.so
#20 0x296c2082 in nsPluginHostImpl::GetURLWithHeaders ()
   from /usr/X11R6/lib/firefox/components/libgkplugin.so
#21 0x296c1d64 in nsPluginHostImpl::GetURL ()
   from /usr/X11R6/lib/firefox/components/libgkplugin.so
#22 0x296b6cfe in MakeNew4xStreamInternal ()
   from /usr/X11R6/lib/firefox/components/libgkplugin.so
#23 0x296b6dcf in MakeNew4xStreamInternal ()
   from /usr/X11R6/lib/firefox/components/libgkplugin.so
#24 0x29fab77d in ?? ()
   from /usr/local/lib/linux-flashplugin6/libflashplayer.so
#25 0x29faa4af in ?? ()
   from /usr/local/lib/linux-flashplugin6/libflashplayer.so
#26 0x29fa8d20 in ?? ()
   from /usr/local/lib/linux-flashplugin6/libflashplayer.so
#27 0x29f51c79 in ?? ()
   from /usr/local/lib/linux-flashplugin6/libflashplayer.so
#28 0x29f49fac in ?? ()
   from /usr/local/lib/linux-flashplugin6/libflashplayer.so
#29 0x29f4a873 in ?? ()
   from /usr/local/lib/linux-flashplugin6/libflashplayer.so
#30 0x29f74dd5 in ?? ()
   from /usr/local/lib/linux-flashplugin6/libflashplayer.so
#31 0x29fa9ad5 in ?? ()
   from /usr/local/lib/linux-flashplugin6/libflashplayer.so
#32 0x28a9fe8b in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6
#33 0x28a78b78 in _init () from /usr/X11R6/lib/firefox/libgtkxtbin.so
#34 0x28863b71 in g_timeout_dispatch (source=0x8df7480, 
callback=0x28a78b3c _init+1680, user_data=0x8aa3000) at gmain.c:3301
#35 0x288615cb in g_main_dispatch (context=0x8090c80) at gmain.c:1942
#36 0x28862408 in g_main_context_dispatch (context=0x8090c80) at gmain.c:2492
#37 0x28862802 in g_main_context_iterate (context=0x8090c80, block=1, 
dispatch=1, self=0x80bece0) at gmain.c:2573
#38 0x28862e3c in g_main_loop_run (loop=0x8203170) at gmain.c:2777
#39 0x283e1edf in gtk_main () from /usr/X11R6/lib/libgtk-x11-2.0.so.400
#40 0x28b02088 in nsAppShell::Run ()
   from /usr/X11R6/lib/firefox/components/libwidget_gtk2.so
#41 0x28a42082 in nsAppShellService::Run ()
   from /usr/X11R6/lib/firefox/components/libnsappshell.so
#42 0x80522ba in xre_main ()
#43 0x804d128 in main ()
#44 0x804d056 in _start ()

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD 5.3 freezes under heavy hdd load

2005-03-07 Thread Kris Kennaway
On Mon, Mar 07, 2005 at 04:05:39PM -0500, Brian Reichert wrote:
 On Mon, Mar 07, 2005 at 05:12:44PM +, Kris Kennaway wrote:
  It is necessary to increase KSTACK_PAGES (e.g. to 4) on machines with
  certain patterns of heavy disk write load to avoid double faults in
  the softupdates code (softupdates has potentially unbounded call stack
  and can overflow the default kernel stack size without too much
  effort).
 
 Can these 'certain patterns' be characterized?

Probably combinations of lots of writes and removes of directories.

 I've got a system
 that hangs on haavy rsync usage, where the file sizes can me measured
 in a half-gig or more...
 
  This would cause panics though, not freezes.
 
 I can't tell remotely if all of my hangs are panics, as it's a
 remote box.  Once, on the console of a hung box, I found
 
   panic: worklist_remove: not on list
 
 This box did not reboot of it's own accord, and has wedged again
 under a similar workload...

That's probably different - as I said, the problem I'm talking about
causes double faults.

Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


http://lach.flappie.nl

2005-03-07 Thread laura
Kijk eens, mn broertje heeft voor mij een site gemaakt.

http://lach.flappie.nl

kusjes Laura
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: Dell pe1550 (smp) on RELENG_5 ?

2005-03-07 Thread Doug White
On Mon, 7 Mar 2005, Robin P. Blanchard wrote:

 It seems that disabling NO_MIXED_MODE allows the 1550s to succesfully operate
 in smp mode.

Yes, a machine that old I would not expect to work with this option. Since
it isn't the default I'll chock this up to PEBKAC :)


-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Apparent interrupt routing problem in 5.4-PRERELEASE

2005-03-07 Thread Terry Kennedy
  I've communicated with a few people about this off-list, and it was sug-
gested I give the issue some wider exposure on this list in the hope of
having it addressed for 5.4-RELEASE. It may or not be related to the other
interrupt storm problems some people are seeing.

  I have a number of systems running the latest 5-STABLE (as of 4 PM today
or so). I've been seeing this issue for quite some time, though (5.3-RELEASE
at least, though I don't remember it happening in 5.2.1-RELEASE).

  The first symptom is that at boot time, I see these messages:

Interrupt storm detected on irq16: uhci0; throttling interrupt source
Interrupt storm detected on irq17: ichsmb0; throttling interrupt source

  Next, during the whole time the system is up, a systat -v shows that my
uhci0 and ichsmb0 devices have active interrupt counts (despite no activity
on them) which happen to *exactly* correspond with real interrupt activity
on other devices.

  The motherboards are Tyan S2721-533's. The rest should be apparent from the
dmesg output.

  I'm attaching two consecutive screen captures of the systat -v output as
well as the dmesg output.

  This happens on both SMP and UP (with a UP kernel) configs, and also with
or without ACPI enabled (by option at boot time).

  Let me know if anyone needs further information to help diagnose this. I
can also provide remote access to a test system if a developer needs it.

Terry Kennedy http://www.tmk.com
[EMAIL PROTECTED] New York, NY USA

3 usersLoad  0.00  0.00  0.00  Mar  7 21:57

Mem:KBREALVIRTUAL VN PAGER  SWAP PAGER
Tot   Share  TotShareFree in  out in  out
Act   19276336862804 4176 2873112 count 1
All 11083206276  3306404 8148 pages 1
  zfod   Interrupts
Proc:r  p  d  s  wCsw  Trp  Sys  Int  Sof  Fltcow7244 total
 35 159231 663810513  230  213256 wire1: atkb
12032 act 6: fdc0
 8.1%Sys   3.7%Intr  0.2%User  0.0%Nice 87.9%Idl   884388 inact   128 8: rtc
||||||||||cache   12: psm
++2873112 free13: npx
  daefr   15: ata
Namei Name-cacheDir-cache prcfr  3175 16: uhc
Calls hits% hits% react   332 17: ich
  pdwak   24: twa
  pdpgs  3175 48: em0
Disks   da0   da1   sa0 pass0 pass1 pass2 intrn   332 72: twa
KB/t   9.67   127  0.00  0.00  0.00  0.00  114464 buf 98: ahd
tps   2   167 0 0 0 0   9 dirty   99: ahd
MB/s   0.02 20.62  0.00  0.00  0.00  0.00  10 desir   100e0: clk
% busy071 0 0 0 0   64552 numvnodes
14155 freevnodes

3 usersLoad  0.07  0.02  0.00  Mar  7 21:57

Mem:KBREALVIRTUAL VN PAGER  SWAP PAGER
Tot   Share  TotShareFree in  out in  out
Act   19276336862804 4176 2552792 count
All 14286406276  3821844 8148 pages
  zfod   Interrupts
Proc:r  p  d  s  wCsw  Trp  Sys  Int  Sof  Fltcow7610 total
 35 166862 696811000  237  213324 wire1: atkb
12040 act 6: fdc0
 9.2%Sys   3.7%Intr  0.4%User  0.0%Nice 86.8%Idl  1204632 inact   128 8: rtc
||||||||||cache   12: psm
=+   2552792 free13: npx
  daefr   15: ata
Namei Name-cacheDir-cache prcfr  3344 16: uhc
Calls hits% hits% react   347 17: ich
  pdwak   24: twa
  pdpgs  3344 48: em0
Disks   da0   da1   sa0 pass0 pass1 pass2 intrn   347 72: twa
KB/t   0.00   127  0.00  0.00  0.00  0.00  114464 buf 98: ahd
tps   0   174 0 0 0 0   9 dirty   99: ahd
MB/s   0.00 21.69  0.00  0.00  0.00  0.00  10 desir   100e0: clk
% busy069 0 0 0 0   64552 numvnodes
14150 freevnodes

Copyright (c) 1992-2005 The FreeBSD Project.

Re: ueagle(4) driver merging

2005-03-07 Thread Doug White
On Mon, 7 Mar 2005, Simon Barner wrote:

 Doug White wrote:
 [...]
  You'll also need to find a committer willing to do the work to actually
  perform the integration and testing, review the licensing, etc.

 I think finding a committer should not be too difficult, because Damien
 Bergamini became a FreeBSD committer on March 3rd (damien@) :-)

Perfect!

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: if_bfe/uhci: storm interrupt Fatal trap 12

2005-03-07 Thread Doug White
On Mon, 7 Mar 2005 [EMAIL PROTECTED] wrote:

 On  4 Mar, Doug White wrote:

 
  Hm ... dunno. You might try one of the RELENG_5 snapshots that will be
  coming out shortly as we get into the 5.4-R release cycle. There is some
  improvements to interrupt routing in there.
 

 In fact I have try the CURRENT SNAP (2005 february snap) because I can
 get a call stack.

 Here is the steps I perform to get to the call stack.

 1- I boot with the snapshot miniinst
 2- Selecting keymap (french accent)
 3- Fixit mode
 4- Emergency shell
 5- using Alt-F4 to go to the terminal
 6- typing: ifconfig bfe0 192.168.1.1 = the shell freeze
 7- using Alt-F1 to go back to the 1st terminal where there is a panic
message:
 handwritten typescript
 cpuid = 0
 KDB: enter: panic
 [thread pid 29 tid 100030 ]
 Stopped at  kdb_enter+0x2b: nop
 db where  -- command entered
 Tracing pid 29 tid 100030 td 0xc2ff1000
 kdb_enter(c0823108) at kdb_enter+0x2b
 panic(c083ca28,deadc000,c07c9462,0,8000) at panic+0x127
 vm_fault(c1459000,deadc000,1,0,c2ff1000) at vm_fault+0x1e1
 trap_pfault(e5e61c50,0,deadc0ee) at trap_pfault+0x13b
 trap(c0830018,10,10,c3105000,c3102400) at trap+0x335
 calltrap() at calltrap+0x5
 --- trap 0xc, eip = 0xc07a810, esp = 0xe5e61c90, ebp = 0xe5e61c98 ---
 _bus_dmamap_unload(c3102400,c3104540) at _bus_dmamap_unload+0x16
 bfe_rx_ring_free(c3105000,c3105000,c3105000,e5e61cd8,c04dd0a3) at
bfe_rx_ring_free+0x50
 bfe_stop(c3105000,400,c3105000,e5e61cf4,c04dcae7) at bfe_stop+0x45
 bfe_init_locked(c3105000) at bfe_init_locked+0x33
 bfe_intr(c3105000) at bfe_intr+0x9f
 ithread_loop(c2fe9500,e5e61d48,c2fe9500,c0601a54,0) at
ithread_loop+0x120
 fork_exit(c0601a54,c2fe9500,e5e61d48) at fork_exit+0xa4
 fork_trampoline() at fork_trampoline+0x8
 --- trap 0x1, eip = 0, esp = 0xe5e61d7c, ebp = 0 ---
 db
 


Thanks for the detailed message. I didn't realize that we'd enabled DDB in
the snapshot kernel :)

Anyway this looks like a bug in the bfe driver.  It appears to be trying
to free a DMA map that is either unallocated or got spammed.  You may want
to repost this to freebsd-current@freebsd.org and use a subject like
Use-after-free in bfe since I think the interrupt storm message is
secondary.

A capture of boot -v might also be useful, or at minumum anything the bfe
driver output during boot ('dmesg | grep bfe' might work with the fixit
disc). A crashdump would be nice too, but you'd likely need to find a
different network adapter.

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 1000baseTX?

2005-03-07 Thread Doug White
On Sat, 5 Mar 2005 [EMAIL PROTECTED] wrote:

   In man pages, dmesg and ifconfig of FreeBSD5, GbE operation over
   twisted pair is mostly referred as '1000baseTX'.  I guess most of them
   should be replaced by '1000baseT'.  1000baseTX and 1000baseT are
   different standard and they are not compatible (TX needs CAT6 cable
   and uses pairs in different way).  Also 1000baseTX support is very
   rare yet.  I'm sorry I'm not sure if some devices really support TX.
 
  Do you have any documentation to back up this claim?

 1000baseTX was an attempt at producing less expensive hardware (NICs
 etc) that could be used with Cat6 cabling. It is basically dead, and
 was never blessed by the IEEE.

 The IEEE is quite clear on the fact that Gigabit Ethernet on Cat5 UTP
 is called 1000Base-T. See for instance Chapter 34, Introduction to
 1000 Mb/s baseband network, in IEEE 802.3-2002, available from

   http://standards.ieee.org/getieee802/802.3.html

 So using 1000baseTX as the name in FreeBSD is clearly wrong.

Thanks for doing the research on this. Its too bad that this is in a
user-visible knob, so changing it would break scripts.  We could create an
alias for it, but that'd log an already busy mediatypes list.

Considering that has been that way since 4.x and this is the first
complaint I've heard of, I'm tempted to let it slide, at least for 5.x.
6.x could probably get away with it if someone offered the megapatch to
fix all the drivers (or whatever code does the mediatype foo).

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]