all of the snapshots since the 24th have exhibited this same or
very similar behavior.
when booting from the kern mfsroot floppies i get:
.
.
.
unknown: PNP0e03 can't assign resources
unknown: PNP0700 can't assign resources
unknown: PNP0501 can't assign resources
unknown: PNP0401 can't assign
John Baldwin wrote:
On 04-Mar-01 Tom Uffner wrote:
all of the snapshots since the 24th have exhibited this same or
very similar behavior.
Does it happen for snapshots before the 24th?
no, it does not, at least not for the 5.0-20010210-CURRENT snap.
it boots from the floppies and once
John Baldwin wrote:
On 05-Mar-01 Tom Uffner wrote:
John Baldwin wrote:
On 04-Mar-01 Tom Uffner wrote:
all of the snapshots since the 24th have exhibited this same or
very similar behavior.
Does it happen for snapshots before the 24th?
no, it does not, at least not for the 5.0
not quite the same issue, but i tried to update a system with gmirror from
FreeBSD eris.uffner.com 10.0-CURRENT FreeBSD 10.0-CURRENT #210: Thu Mar 15
16:41:18 EDT 2012 t...@eris.uffner.com:/usr/obj/usr/src/sys/ERIS i386
to -current from Aug 4th, and booting now fails into mountroot with
Alexander Motin wrote:
I think the right answer would be to remove stale Promise format RAID metadata
from the disk. You should be able to do it by booting from any source and
doing `graid list -a` to see all RAID GEOMs (even broken) and then remove them
with `graid remove Promise ad4`.
I have a fairly recent Current system running on an ASUS K8V SE Deluxe MB.
It was a dual boot amd64/x86 system (until a few days ago when the drive
w/ the amd64 partitions unexpectedly failed after only a week of use)
When running it as x86, USB 1.1 devices are not recognized by FreeBSD.
They
John Baldwin wrote:
pci0:serial bus, USB at device 16.0 (no driver attached)
pci0:serial bus, USB at device 16.1 (no driver attached)
pci0:serial bus, USB at device 16.2 (no driver attached)
pci0:serial bus, USB at device 16.3 (no driver attached)
Can you get pciconf -lv output for these
John Baldwin wrote:
On Friday, December 10, 2010 8:13:01 pm Tom Uffner wrote:
no...@pci0:0:16:0: class=0x0c0300 card=0x80ed1043 chip=0x30381106
rev=0x81 hdr=0x00
vendor = 'VIA Technologies, Inc.'
device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets
according to kldstat -v, both uhci/usbus pci/uhci were present in
my kernel but one or both of them was silently failing.
apparently something in my sources was corrupt because deleting all of
the USB related code from my CVS root, re-csuping it, and building a
fresh kernel solved the problem.
Michael Butler wrote:
This breaks most (if not all) of the QT4-dependent ports for the lack of
a definition of off64_t.
it also breaks multimedia/mplayer, graphics/ImageMagick, and
print/ghostscript8 everything that depends on it.
___
Xin LI wrote:
On Wed, Mar 31, 2010 at 6:56 PM, Tom Uffnert...@uffner.com wrote:
Michael Butler wrote:
This breaks most (if not all) of the QT4-dependent ports for the lack of
a definition of off64_t.
it also breaks multimedia/mplayer, graphics/ImageMagick, and
print/ghostscript8
Attilio Rao wrote:
I have another problem where the bwn is fully recognized and wlan0 is
created but the interface doesn't scan at all:
# netstat -nil
Name Mtu Network Address Ipkts Ierrs Idrop
Opkts Oerrs Coll
bwn0 2290 Link#1 00:26:5e:64:be:750 0
Weongyo Jeong wrote:
OK. The patch is ready to test. Could you please test it with attached
patch?
your patch got rid of the bwn0: unsupported rate 0 messages on my Dell
Inspiron 1150. But it still gives me repeated:
bwn0: RX decryption attempted (old 0 keyidx 0x1)
and a few of the
Commit r289932 causes pf rules with broadcast destinations (and some but not
all rules after them in pf.conf) to be silently ignored. This is bad.
this broke access to my samba shares, and every "pass in ..." rule occurring
after the samba rule in my pf.conf.
for example, the host in question
Tom Uffner wrote:
Commit r289932 causes pf rules with broadcast destinations (and some but not
all rules after them in pf.conf) to be silently ignored. This is bad.
I do not understand the pf code well enough to see why this change caused
the breakage, but I suspect that it might expose some
Kristof Provost wrote:
Can you give this a quick test:
diff --git a/sys/netpfil/pf/pf.c b/sys/netpfil/pf/pf.c
index 1dfc37d..762b82e 100644
--- a/sys/netpfil/pf/pf.c
+++ b/sys/netpfil/pf/pf.c
@@ -1973,9 +1973,9 @@ pf_addr_wrap_neq(struct pf_addr_wrap *aw1, struct
pf_addr_wrap *aw2)
Kristof Provost wrote:
On 2015-11-04 20:31:35 (-0500), Tom Uffner <t...@uffner.com> wrote:
Commit r289932 causes pf rules with broadcast destinations (and some but not
all rules after them in pf.conf) to be silently ignored. This is bad.
What version did you test exactly?
There was an
Since updating my -current box to 12 several months ago, I have been trying to
pin down several elusive and probably related panics.
they always manifest a a trap out of rw_wlock_hard()
i am fairly certain that r302409 was stable, revs up through r306792 may be
stable, or perhaps I just didn't
Andrey V. Elsukov wrote:
On 26.04.2017 04:03, Tom Uffner wrote:
I think the most of these panics should be fixed in r315956.
thanks. I'll give it a try and report back as soon as I have a result.
___
freebsd-current@freebsd.org mailing list
https
Tom Uffner wrote:
Andrey V. Elsukov wrote:
I think the most of these panics should be fixed in r315956.
thanks. I'll give it a try and report back as soon as I have a result.
r315956 panicked about 22 min after boot. failed to dump a core
Andrey V. Elsukov wrote:
On 27.04.2017 08:42, Tom Uffner wrote:
r315956 panicked about 22 min after boot. failed to dump a core.
Why not update to the latest revision?
I did several times a while ago, but didn't get a panic free system. I was
hoping to bisect the point the point where
Andrey V. Elsukov wrote:
On 27.04.2017 08:42, Tom Uffner wrote:
Tom Uffner wrote:
Andrey V. Elsukov wrote:
I think the most of these panics should be fixed in r315956.
thanks. I'll give it a try and report back as soon as I have a result.
r315956 panicked about 22 min after boot. failed
Hamza Sheikh wrote:
I may have encountered something similar on an EdgeRouter Lite running
r317256. It's serving as network gateway at home. After some time the
WAN connection goes dead. It starts working with either (a)
reconnecting the network cable or (b) pinging any IP on the internet
from
23 matches
Mail list logo
