Based on this output from your gdb session it looks like the code in
boot() did run and potentially alter this buffer.
panic: bwrite: buffer is not busy???
panic messages:
---
panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id =
Stack backtrace:
boot() called on cpu#1
Can you
In message [EMAIL PROTECTED], Bryan Liesner writes:
Revision 1.20 / (download) - annotate - [select for diffs], Mon Mar 10 23:41:41
2003 UTC (5 days, 5 hours ago) by phk
Branch: MAIN
CVS Tags: HEAD
Changes since 1.19: +5 -0 lines
Diff to previous 1.19 (colored)
If we run out of
On Sun, 16 Mar 2003, Poul-Henning Kamp wrote:
I think Poul-Henning will have enough information to go with now...
You guys _way_ overestimate my abilities here.
Right now I have a hard time imagining what geom's eventhandling
for withering geoms can possibly have to do with any non-geom
On Sun, Mar 16, 2003 at 09:20:10AM +1030, Greg 'groggy' Lehey
[EMAIL PROTECTED] wrote:
Will it suffice to switch off power for one disk to simulate more
real-world disk failure? Are there any hidden pitfalls for failing
and restoring operation of non-hotswap disks?
I don't think so. It
It seems [EMAIL PROTECTED] wrote:
On 15-Mar-2003 Soeren Schmidt wrote:
atapci0: SiS 961 UDMA100 controller port 0xff00-0xff0f at device 2.5 on
pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
ad0: DMA limited to UDMA33, non-ATA66 cable or device
ad0: 78533MB
On Sun, 16 Mar 2003, Poul-Henning Kamp wrote:
One thing I'd like you to try is to remove any trace of USB from your
systems. USB does some ugly VOP_REVOKES which I am not happy about, and
I would like to exclude them from the list of suspects.
You can remove USB from your list, I tried
From: Soeren Schmidt [EMAIL PROTECTED]
Subject: Re: SiS5591(?) ATA
Date: Sun, 16 Mar 2003 11:50:30 +0100 (CET)
Message-ID: [EMAIL PROTECTED]
Could I have you both try this patch and mail me the entire output og
dmesg with it applied ? (patch against a clean -current)
ata-chipset.c can't be
Bryan Liesner wrote:
On Sun, 16 Mar 2003, Poul-Henning Kamp wrote:
One thing I'd like you to try is to remove any trace of USB from your
systems. USB does some ugly VOP_REVOKES which I am not happy about, and
I would like to exclude them from the list of suspects.
You can remove USB from your
On 16-Mar-2003 FUJITA Kazutoshi wrote:
Could I have you both try this patch and mail me the entire output og
dmesg with it applied ? (patch against a clean -current)
ata-chipset.c can't be compiled which applied your patch ;-)
Index: ata-chipset.c
@@ -1576,6 +1577,7 @@
}
walt wrote:
Bryan Liesner wrote:
On Sun, 16 Mar 2003, Poul-Henning Kamp wrote:
One thing I'd like you to try is to remove any trace of USB from your
systems. USB does some ugly VOP_REVOKES which I am not happy about, and
I would like to exclude them from the list of suspects.
You can remove
On Sun, Mar 16, 2003 at 09:29:15AM +0100, Poul-Henning Kamp wrote:
I don't think I'll stand a chance on this one until I can reproduce it
on one of my machines :-(
I'm not sure if that helps, but on my machine it it enough to take
GENERIC kernconf file, add all GEOM_ options and comment out
From: Scott Long [EMAIL PROTECTED]
Subject: Re: UDF: bad file descriptor
Date: Sat, 15 Mar 2003 21:29:16 -0700
Message-ID: [EMAIL PROTECTED]
Sorry for neglecting UDF for so long. Regarding this problem, what
program was used to generate the UDF filesystem on the disk? If the
disk doesn't
In message [EMAIL PROTECTED], Krzysztof Parz
yszek writes:
On Sun, Mar 16, 2003 at 09:29:15AM +0100, Poul-Henning Kamp wrote:
I don't think I'll stand a chance on this one until I can reproduce it
on one of my machines :-(
I'm not sure if that helps, but on my machine it it enough to take
From: Tim Robbins [EMAIL PROTECTED]
Subject: Re: UDF: bad file descriptor
Date: Sun, 16 Mar 2003 16:58:57 +1100
Message-ID: [EMAIL PROTECTED]
The Linux driver doesn't seem to issue the special read and write commands
that the quote from the UDF spec. mentions, so I'm not sure whether
it will
If inclusion of INVARIANTS serves to disguise bugs in
the kernel, I wonder if kernel committers should be
using this option routinely?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Hello Takahiko,
[...]
OK, I checked my copy of 2003-03-05. It only has sys. I'd download latest
2003-03-05 on your directory. I've rebuild environment.
good
[...]
ugen0: Broadcom product 0x2033, rev 1.01/0.a0, addr 2
I just mistake device name, it not BW-BH02U. true name is
Everything in kern_condvar.c uses a special form of sleeping which
doesn't change the priority to one specified by the caller like for
ordinary tsleep(). This affects at least select() and poll(). Processes
sleeping in select() do it at priority PSOCK in RELENG_4 and at the
user priority in
Hi,
I have just recently installed -CURRENT on my desktop as I've been using it
succesfully on a server for months now. However this desktop has much more
advanced hardware. Whilst it does work perfectly and I have device support for
everything I get a lot of ACPI errors on bootup and also a
At 06:04 PM 3/16/2003, Matt wrote:
Hi,
I have just recently installed -CURRENT on my desktop as I've been using it
succesfully on a server for months now. However this desktop has much more
advanced hardware. Whilst it does work perfectly and I have device support for
everything I get a lot of
Petri Helenius wrote:
Terry Lambert wrote:
Ah. You are receiver livelocked. Try enabling polling; it will
help up to the first stall barrier (NETISR not getting a chance
to run protocol processing to completion because of interrupt
overhead); there are two other stall barriers after that,
It seems like the fix right now is to disable it.
Put this line:
hint.acpi.0.disabled=1
in /boot/device.hints
Thankyou, this has given me a nice clean bootup now and I can reboot without
it panicing.
I'm still curious to learn what all that stuff ment though!
---
Matt ([EMAIL PROTECTED])
I am attempting this with the latest snapshot that I could get. I am doing
this off the kern and mfsroot floppies. This is (again) on a Dell Inspiron
2650 laptop. I boot the two floppies, and I get this:
...regular kernel boot messages...
pci0: serial bus, SMBus at device 31.3 (no driver
um..
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc027719a in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc0277403 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc0227ac2 in wi_start (ifp=0xc1985000) at /usr/src/sys/dev/wi/if_wi.c:845
#4
* Alfred Perlstein [EMAIL PROTECTED] [030316 21:19] wrote:
um..
...
840 _FLAGS_OUTRANGE) {
841 WI_UNLOCK(sc);
842 return;
843 }
844 KASSERT((ifp-if_flags IFF_OACTIVE) == 0,
845 (wi_start: if_flags %x\n,
* Alfred Perlstein [EMAIL PROTECTED] [030316 21:19] wrote:
um..
...
840 _FLAGS_OUTRANGE) {
841 WI_UNLOCK(sc);
842 return;
843 }
844 KASSERT((ifp-if_flags IFF_OACTIVE) == 0,
845 (wi_start: if_flags
Date: Thu, 6 Mar 2003 17:21:00 +0300 (MSK)
From: Maxim Konovalov [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: 4.8-RC / 5-CURRENT UFS1 interoperability problem
Hello,
In short, there is a problem using the same UFS1
On Sat, Mar 15, 2003 at 01:33:11AM -0600, Dan Nelson wrote:
Oops. You appended a decoded dump again. I should have told you how
to generate a raw tcpdump log. Add -s 1500 -w file.pcap to the
tcpdump commandline. You won't get any output to the screen, but the
raw packet contents will get
Poul-Henning wrote:
Make sure you have rev 1.9 of src/sys/geom/bde/g_bde_crypt.c
I hadn't done my math and before that rev gbde would request
very large lumps of ram from malloc(9).
For a few hours, I thought that rev 1.9 may have fixed the problem, but
I just received another ENOMEM
In message [EMAIL PROTECTED], Lucky Green writes:
Poul-Henning wrote:
Make sure you have rev 1.9 of src/sys/geom/bde/g_bde_crypt.c
I hadn't done my math and before that rev gbde would request
very large lumps of ram from malloc(9).
For a few hours, I thought that rev 1.9 may have fixed
In message [EMAIL PROTECTED], walt writes:
If inclusion of INVARIANTS serves to disguise bugs in
the kernel, I wonder if kernel committers should be
using this option routinely?
Please check into our current reality :-)
Suggest you check what INVARIANTS actually do.
--
Poul-Henning Kamp
You can get to this same point in -CURRENT, if you are using up to
date sources, by enabling direct dispatch, which disables NETISR.
This will help somewhat more than polling, since it will remove the
normal timer latency between receipt of a packet, and processing of
the packet through the
walt [EMAIL PROTECTED] writes:
If inclusion of INVARIANTS serves to disguise bugs in
the kernel, I wonder if kernel committers should be
using this option routinely?
It doesn't serve to disguise bugs; quite to the contrary, it serves
to expose bugs and reveal their causes. However, INVARIANTS
32 matches
Mail list logo
