On Wed, Feb 19, 2003 at 10:20:12AM +1100, Bruce Evans wrote:
> On Tue, 18 Feb 2003, Ruslan Ermilov wrote:
>
> > On Fri, Feb 14, 2003 at 05:10:40AM -0800, Alfred Perlstein wrote:
> > > alfred 2003/02/14 05:10:40 PST
> > >
> > > Modified files:
> > > sys/kern kern_intr.c
> > >
In message <[EMAIL PROTECTED]>, Warner Losh write
s:
>imp 2003/02/18 21:47:47 PST
>
> Modified files:
>[... everything ...]
> uma_core.c vm_map.c vm_object.c
> Log:
> Back out M_* changes, per decision of the TRB.
>
> Approved by: trb
The attached patch w
../../../kern/kern_lock.c:239: could sleep with "buf queue lock" locked from
../../../kern/vfs_bio.c:2143
Debugger("witness_sleep")
Stopped at 0xc0409aae = Debugger+0x7e: xchgl %ebx,0xc05b37e0 = in_Debugger.0
db> trace
Debugger(c04530c8,c0469eb9,ef,c046e636,c0470d54) at 0xc0409aae = De
OK, I can 100% let SMP kernel crash here.
Turn on cpu hlt sysctl,
%sysctl -w machdep.cpu_idle_hlt=1
then copy a large file to my home directory
%cp /boot/kernel .
Press ctl+alt+del immediately after copy.
When in reboot state, kernel crashed when trying to
shutdown bufdaemon.
backtrace shows the
Hi,
I've got a Sitecom cardbus USB controller here, probes as:
found-> vendor=0x1033, dev=0x0035, revid=0x41
class=0c-03-10, hdrtype=0x00, mfdev=1
cmdreg=0x, statreg=0x0210, cachelnsz=8 (dwords)
lattimer=0xa8 (5040 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns)
David Schultz <[EMAIL PROTECTED]> wrote:
> IIRC, Kirk was trying to reproduce this a little while ago in
> response to similar reports. He would probably be interested
> in any new information.
I don't have any useful information, but I do have a data point:
My 5.0-RELEASE system r
Can you post your kernel config please, along with with, if any,
CPUTYPE you have set in make.conf and a description of your machine
(mem size in particular)?
I'm unable to reproduce the boot panic with a GENERIC as of
today. (rest of machine is from Nov 1st). Rebuilding without
CPUTYPE now..
I ran into an interesting problem last night ... that was very
frustrating. I was recycling SCSI drives from some NetBSD machines
(that were client boxes) to add to a RAID server running
FreeBSD-5.0-RELEASE.
It's simply impossible to format NetBSD drives under current.
Let me expand on that. /d
[EMAIL PROTECTED] wrote:
> The attached patch will print a backtrace if any calls to malloc
> fail to have either M_WAITOK or M_NOWAIT.
Please do not commit this as-is.. There is a DoS here if a user figures
out how to provoke this. This is exactly the situation that Alfred was
worried about.
4.x and -current use the same mechanism, except 4.x uses MFS and
-current uses MD.
Ignore the handbook. Try 'man diskless'.
kenv is only used in current's rc.diskless scripts, and it
resides in /bin on -current. kenv is not used in 4.x's
diskless scripts.
Basically
I'm not sure what is occuring here but it sounds like
cockpit trouble somewhere. Make sure your NFS server is
exporting to your subnet and that it is running the
necessary services, (portmap, mountd, nfsd -t -u -n 4).
If you have another box that you can boot normally
(not
Matthew Dillon <[EMAIL PROTECTED]> writes:
> 4.x and -current use the same mechanism, except 4.x uses MFS and
> -current uses MD.
4.x uses /etc/diskless[12] while 5.x (by default) uses
/etc/rc.d/(init)?diskless. The latter is works very differently than
the former.
> Ignore the han
Paolo Pisati schrieb:
[root@southcross root]# fsck /dev/ad0s1e
** /dev/ad0s1e (NO WRITE)
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
MISSING '.' I=667872 OWNER=root MODE=40755
SIZE=512 MTIME=Feb 10 16:54 2003
DIR=/ports/cad/gwave
UNEXPECTED SOFT UPDA
In message <[EMAIL PROTECTED]>, Peter Wemm writes:
>[EMAIL PROTECTED] wrote:
>
>> The attached patch will print a backtrace if any calls to malloc
>> fail to have either M_WAITOK or M_NOWAIT.
>
>Please do not commit this as-is.. There is a DoS here if a user figures
>out how to provoke this. This
:Matthew Dillon <[EMAIL PROTECTED]> writes:
:
:> 4.x and -current use the same mechanism, except 4.x uses MFS and
:> -current uses MD.
:
:4.x uses /etc/diskless[12] while 5.x (by default) uses
:/etc/rc.d/(init)?diskless. The latter is works very differently than
:the former.
4.x uses
Matthew Dillon <[EMAIL PROTECTED]> writes:
> Make sure your NFS server is exporting to your subnet and that
> it is running the necessary services, (portmap, mountd, nfsd -t
> -u -n 4).
My boot server is 5.0, so that's the kernel my diskless box gets. My
other boxes are 4.x boxes bu
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x34
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc018fd20
stack pointer = 0x10:0xc5fd27a4
frame pointer = 0x10:0xc5fd27c0
code segment= base 0x0,
Matthew Dillon <[EMAIL PROTECTED]> writes:
> Are you sure you have done a recent buildworld/installworld? It
> sounds like you haven't. In -current kenv is in /bin (i.e.
> the source is in /usr/src/bin/kenv on -current) as of the 15th of
> this month.
Well, I'll be danged. I in
:OK, I'll change this to "tag=." and recvsup, try again. A big "doh!"
:
:Many thanks.
Yup, the 5.0 release tag was messing up your cvsup.
Keep at it! Once you get the diskless stuff working with the more recent
sources it will become a whole lot easier to maintain it. For one thing
At 9:15 AM -0800 2003/02/19, Darryl Okahata wrote:
* The UFS1 filesystem in question (and I assume that it was UFS1, as I
did not specify a filesystem type to newfs) is located on a RAID5
vinum volume, consisting of five 80GB disks.
* Softupdates is enabled.
You know, vinum & softupda
Poul-Henning Kamp wrote:
Fatal trap 12: page fault while in kernel mode
FWIW, Craig Boston and me see the same panics (threads on -current:
"panic starting gnome" and "VFS panic (possibly NFS-locking related?)").
fault virtual address = 0x34
fault code = supervisor read, page no
On Wed, 2003-02-19 at 15:12, Lars Eggert wrote:
> Poul-Henning Kamp wrote:
> > Fatal trap 12: page fault while in kernel mode
>
> FWIW, Craig Boston and me see the same panics (threads on -current:
> "panic starting gnome" and "VFS panic (possibly NFS-locking related?)").
When I get home tonight
On 2003-02-19 09:14, [EMAIL PROTECTED] wrote:
> The attached patch will print a backtrace if any calls to malloc
> fail to have either M_WAITOK or M_NOWAIT. [...]
> --- kern/kern_malloc.c19 Feb 2003 05:47:25 - 1.116
> +++ kern/kern_malloc.c19 Feb 2003 07:55:19 -
> @@ -
I am seeing a reproducible panic with
FreeBSD talisker 5.0-RELEASE FreeBSD 5.0-RELEASE #5: Wed Jan 29 10:49:32 CET 2003
root@talisker:/usr/src/sys/i386/compile/TALISKER i386
What I've done is:
- kldload uvisor.ko
- running »/usr/sbin/usbd -d -v«
- running »jpilot-sync -d -l -p /dev/ucom0«
- hitti
Terry Lambert wrote:
Debug:
>
[excellent kernel-debugging recipe snipped]
Here's a backtrace of a crashdump that should be more helpful:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x34
fault code = supervisor read, page n
Brad Knowles <[EMAIL PROTECTED]> wrote:
> You know, vinum & softupdates have had bad interactions with each
> other for as long as I can remember. Has this truly been a
> consistent thing (as I seem to recall), or has this been an
> on-again/off-again situation?
Ah, yaaah. Hmm ...
Hi Folks,
I've just put together a 1.7TB filesystem and was looking for some
regression tests to run against it. Looking through the mailing lists
doesn't turn up anything, nor does a websearch (at least for the keywords
I tried).
So, does anyone have any comments/ideas on a good way to tes
During boot, i get the following:
rl0: port 0x6100-0x61ff mem
0xe1001000-0xe10010ff ir
q 10 at device 14.0 on pci0
rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode
rl0: Ethernet address: 00:00:21:f2:a5:47
miibus0: on rl0
rlphy0: on miibus0
rlphy0: 10baseT, 10baseT-
At 7:17 PM -0500 2003/02/19, John De Boskey wrote:
So, does anyone have any comments/ideas on a good way to test the
new system?
You could always set it up as a full-feed USENET news server.
Should be able to fill that sucker up in two or three days. ;-)
Perhaps a freenet or other p2p
> Date: Mon, 17 Feb 2003 23:22:28 +0100 (MET)
> From: [EMAIL PROTECTED] (Joerg Wunsch)
> Sender: [EMAIL PROTECTED]
>
> "Matthew N. Dodd" <[EMAIL PROTECTED]> wrote:
>
> > My only outstanding issue is that I can't suspend if an application
> > is holding /dev/dsp or /dev/audio open.
>
> Can you su
On Wed, 19 Feb 2003, John De Boskey wrote:
> Hi Folks,
>
>I've just put together a 1.7TB filesystem and was looking for some
> regression tests to run against it. Looking through the mailing lists
> doesn't turn up anything, nor does a websearch (at least for the keywords
> I tried).
>
>So
At 7:58 PM -0500 2003/02/19, Wesley Morgan wrote:
How about getting some tarballs full of tons of files, extracting them,
deleting and randomly powering down forcing an fsck... :p
Better yet, get that sample 1.7KB zip file that extracts out to
hundreds of GB, and really thrash the system by
- Brad Knowles's Original Message -
> Yeah, especially if it's UFS2, you're doing softupdates with
> background fsck, and you've used vinum to build the large logical
> volume. ;-)
Actually, I didn't say how the volume was put together :-) It
is currently a Raid50 consisting o
John De Boskey <[EMAIL PROTECTED]> writes:
> Hi Folks,
>
>I've just put together a 1.7TB filesystem and was looking for some
> regression tests to run against it. Looking through the mailing lists
> doesn't turn up anything, nor does a websearch (at least for the keywords
> I tried).
>
>S
[... snip ...]
PP> UNEXPECTED SOFT UPDATE INCONSISTENCY
PP> CANNOT FIX, FIRST ENTRY IN DIRECTORY CONTAINS files
[... snip ...]
PP> any on how to fix it?
I got the same bug. Machine got grozen without panic (it didn't restarted itself :-(
). Of course, there was no crash dump.
To Unsubscribe: sen
Hi,
Since I went to -current by way of 5.0-Rel, I was unable to
do a clean shutdown or reboot. No matter how I tried it,
2-8 buffers always remain there during sync'ing.
It goes like this:
Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
Waiting (max 60 seconds) for syst
Poul-Henning Kamp wrote:
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x34
This is the same problem that the other people were complaining
about the other day. It's interesting to note the third argument
to namei() is not zero in your case.
> _mtx_lock_flags(34,0
Lars Eggert wrote:
> Poul-Henning Kamp wrote:
> > Fatal trap 12: page fault while in kernel mode
>
> FWIW, Craig Boston and me see the same panics (threads on -current:
> "panic starting gnome" and "VFS panic (possibly NFS-locking related?)").
Have you "gdb -k" list'ed the namei code in question
On Wed, 2003-02-19 at 16:44, Lars Eggert wrote:
> #11 0xc0302ff8 in calltrap () at {standard input}:97
> #12 0xc02098a4 in namei (ndp=0x9e) at /usr/src/sys/kern/vfs_lookup.c:158
> #13 0xc021bcfc in vn_open_cred (ndp=0xeb3b1a44, flagp=0xeb3b1a0c, cmode=0,
> cred=0xc2195e80) at /usr/src/sys/kern
Lars Eggert wrote:
> Terry Lambert wrote:
> > Debug:
> >
> [excellent kernel-debugging recipe snipped]
>
> Here's a backtrace of a crashdump that should be more helpful:
[ ... ]
> (kgdb) up 12
> #12 0xc02098a4 in namei (ndp=0x9e) at /usr/src/sys/kern/vfs_lookup.c:158
> 158 FILEDESC_
On Wed, 2003-02-19 at 21:48, Terry Lambert wrote:
> Lars Eggert wrote:
> > Poul-Henning Kamp wrote:
> > > Fatal trap 12: page fault while in kernel mode
> >
> > FWIW, Craig Boston and me see the same panics (threads on -current:
> > "panic starting gnome" and "VFS panic (possibly NFS-locking relat
Guys, this problem has already been identified. I posted a
patch last night to cvs-all@ that fixes this, although it's
still not totally correct so I haven't committed it yet.
Scott
Craig Boston wrote:
On Wed, 2003-02-19 at 21:48, Terry Lambert wrote:
Lars Eggert wrote:
Poul-Henning Kamp wr
+---[ Martin Minkus ]--
| During boot, i get the following:
|
[snip]
| I really want to start upgrading to 5.0 (There are no other issues, and
| some people i know have been running 5.0-CURRENT ever since work on 5.0
| began).
I found that if I tried to specify any media
Craig Boston wrote:
> Well, I haven't had much luck tracking down the exact cause. For some
> reason I haven't been able to figure out, all of my crash dumps jump
> directly from vn_open_cred (line 185 of vfs_vnops.c) to calltrap(). The
> namei call doesn't show up in the stack at all, almost lik
Craig Boston wrote:
>
> On Wed, 2003-02-19 at 21:48, Terry Lambert wrote:
> > Lars Eggert wrote:
> > > Poul-Henning Kamp wrote:
> > > > Fatal trap 12: page fault while in kernel mode
> > >
> > > FWIW, Craig Boston and me see the same panics (threads on -current:
> > > "panic starting gnome" and "V
Scott Long wrote:
> Guys, this problem has already been identified. I posted a
> patch last night to cvs-all@ that fixes this, although it's
> still not totally correct so I haven't committed it yet.
This one, I imagine. Thanks!
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1225336+0+current/cvs
On 2/19/2003 8:23 PM, Scott Long wrote:
Guys, this problem has already been identified. I posted a
patch last night to cvs-all@ that fixes this, although it's
still not totally correct so I haven't committed it yet.
Great, thanks!
Though it might have been a good idea to CC current@ - I'd have
îÅÚÁÂÙ×ÁÅÍÙÅ ÔÕÒÙ × úÁÐÏÌÑÒØÅ - http://koresh.ru/terra/tour.shtml
éÚ×ÉÎÑÅÍÓÑ ÚÁ ×ÏÚÍÏÖÎÙÅ ÐÒÅÄÏÓÔÁ×ÌÅÎÎÙÅ ÎÅÕÄÏÂÓÔ×Á.
åÓÌÉ ÷Ù ÈÏÔÉÔÅ ÉÓËÌÀÞÉÔØ Ó×ÏÊ e-mail ÁÄÒÅÓ ÉÚ ÒÁÓÓÙÌËÉ, ÐÏÖÁÌÕÊÓÔÁ, ÕÄÁÌÉÔÅ ÅÇÏ ÚÄÅÓØ:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current"
Well, um, if you look for messages from me last June and then again
several times recently you'll find we are a club of three, at least.
I can't actually manually ifconfig it either, it comes up the
first time fine, but I can wedge my machine with a few large
transfers.
I got a couple of hints v
In message: <[EMAIL PROTECTED]>
Bob Bishop <[EMAIL PROTECTED]> writes:
: Would someone like to give me a clue how to plumb this thing in? TIA
Index: ohci_pci.c
===
RCS file: /cache/ncvs/src/sys/dev/usb/ohci_pci.c,v
retriev
In message <[EMAIL PROTECTED]>, Patric Mrawek writes:
>I am seeing a reproducible panic with
>
>FreeBSD talisker 5.0-RELEASE FreeBSD 5.0-RELEASE #5: Wed Jan 29 10:49:32 CET 2003
>root@talisker:/usr/src/sys/i386/compile/TALISKER i386
>
>What I've done is:
>- kldload uvisor.ko
>- running »/usr/sbin/u
On Wed, Feb 19, 2003 at 08:42:40PM +0100, Dag-Erling Smorgrav wrote:
> 3) a fresh kernel without pcm boots but exhibits the same symptoms
> kris reported, i.e. programs segfaulting for no apparent reason;
> if / when they produce a core file, it is corrupted and useless
> for debuggin
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: strange dump/restore behaviour
From: Dag-Erling Smorgrav <[EMAIL PROTECTED]>
Date: Thu, 09 Jan 2003 16:41:10 +0100
This happened while copying data over to a new disk (mounted on /mnt
and /
Andrew Gallatin <[EMAIL PROTECTED]> writes:
> Can you post your kernel config please, along with with, if any,
> CPUTYPE you have set in make.conf and a description of your machine
> (mem size in particular)?
Digital Personal WorkStation 600au, 598MHz
8192 byte page size, 1 processor.
CPU: EV56
Dag-Erling Smorgrav writes:
> #options CD9660 #kld
Do you preload any/all of the things you've marked as klds?
I've tried to duplicate your crash on my xp1000. I've used your
kernel config file. I've reduced my memory size to 254MB.
I've got rough
In message <[EMAIL PROTECTED]>, David Gilbert writes:
>I ran into an interesting problem last night ... that was very
>frustrating. I was recycling SCSI drives from some NetBSD machines
>(that were client boxes) to add to a RAID server running
>FreeBSD-5.0-RELEASE.
>
>It's simply impossible to for
> "phk" == phk <[EMAIL PROTECTED]> writes:
phk> /dev/da2 is always writable unless you have any of the partitions
phk> open.
The error was that /dev/da2 didn't exist. I was confused too.
fdisk da2 # worked, displyed one slice (3) that was NetBSD
fdisk -I da2 # error, /dev/
Hey There..
I would guess you're using SCHED_ULE in your Kernel config? It seems to
cause shutdown problems that haven't been addressed yet..
Tony
-Original Message-
From: David Kleiner [mailto:[EMAIL PROTECTED]]
Sent: 20 February 2003 05:45
To: [EMAIL PROTECTED]
Subject: Unable to do
Hi
Several seconds into background fsck, this happens. It's easily
repeatable by enabling background fsck and booting after an unclean
shutdown.
Kernel is 2003-02-19 from source checked out on that day (SMP).
The filesystems are UFS1 with softupdates.
panic: vm_fault: fault on nofault entry, ad
Hi
I got this yesterday on my SMP system current as of yesterday:
pcn0: port 0xe800-0xe81f mem 0xea001000-0xea00101f irq 16
at device 9.0 on pci0
../../../vm/uma_core.c:1330: could sleep with "pcn0" locked from
../../../pci/if_pcn.c:524
../../../vm/uma_core.c:1330: could sleep with "pcn0" lock
In article <[EMAIL PROTECTED]>
"M. Warner Losh" <[EMAIL PROTECTED]> writes:
> Cbus is to ISA as CardBus is to PCI in many ways. Cbus is very much
> like ISA in all but a few details. CardBus is pci with a few twists
> and turns that differ. If you look at how we've implemented cardbus,
> you'll
My searches for information on webcam have not found much, except for some
sites which say FreeBSD does not support USB web cameras.
Is anyone currently working on support for this? Does anyone have any
ideas about where one could go to get information about where to start
if one was to start wri
62 matches
Mail list logo
