> 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 t
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
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
> 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 "ENO
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 wi
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 UFS
> * 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_
* 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\
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 0xc02dd413
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: at device 31.3 (no driver attached)
pci0: at device
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, INVA
>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])
h
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
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 ACP
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 panic
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 -curr
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 i
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
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
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
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
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 ou
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 U
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 @@
>>
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
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 b
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
It seems [EMAIL PROTECTED] wrote:
> On 15-Mar-2003 Soeren Schmidt wrote:
> >> atapci0: 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 [159560/16/
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?
> >>
> >>
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-
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)
>
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 disab
32 matches
Mail list logo
