5.3: iostat does not know anything about acd

I've just upgraded to 5.3-RELEASE-p5 and noticed that neither iostat nor systat -vmstat show statistics about acd devices, although I can use them perfectly well. If I enable atapicam then I can see statistic for cd and pass devices, but still nothing for acd. In 4.X I've never had a problem with

Re: need ISO-image for a new machine install

Emanuel Strobl wrote: Unfortunately there is no mini-inst anymore since install and fixit CD is combined now. You have to download the whole 780MB. Why 780MB? It doesn't fit on normal 700MB CD. ___ freebsd-stable@freebsd.org mailing list http://lists.fr

RE: PPP routing failure

Check out the install guide at http://www.unixguide.net/freebsd/fbsd_installguide/index.php it has the best step by step instructions for using userppp. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter C. Lai Sent: Thursday, March 17, 2005 8:37 PM To: f

Building snapshot CDs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When I tried to build a local snapshot from a fresh cvsup today, it failed with "touch not found", so I patched /usr/src/Makefile.inc1 as follows: *** Makefile.inc1~ Wed Mar 2 08:22:57 2005 - --- Makefile.inc1 Fri Mar 18 12:11:15 2005 **

Re: Building snapshot CDs

On Friday 18 March 2005 10:02 am, Michael Butler wrote: > When I tried to build a local snapshot from a fresh cvsup today, it > failed with "touch not found", so I patched /usr/src/Makefile.inc1 as > follows: > > *** Makefile.inc1~ Wed Mar 2 08:22:57 2005 > --- Makefile.inc1 Fri Mar 18

page fault in sched_add_internal on RELENG_5 with ULE + PREEMPTION

quad-cpu amd64 package machine running RELENG_5 with ULE and PREEMPTION, panicked with: Mar 17 19:51:58 fbsd-amd64 kernel: pid 8261 (try), uid 0: exited on signal 10 (core dumped) kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault

USB disk hang - 5.4PRE - gstripe

I just upgraded a box to 5.4PRE and started experiencing regular system hangs at exactly 1AM - I traced it to BackupPC which was starting it's run at that time backing up to a gstripe set made from two 300GB USB disks. The first thing I assumed was that something in Samba or perl didn't like the

Re: PPP routing failure [fixed]

Yes it was a sleep issue (and not the sleep(2) kind haha). *facepalm* Apparently the POP uses a 2 stage authentication process. First, you use unix/slip style authentication after which the POP then initiates CHAP. I had specified the inccorect password for CHAP but after the initial autentication