On Mon 2019-11-25 (18:35), Miroslav Lachman wrote:
> It is possible you have some non printable (invisible) character in the
> filename. It can be trailing space, newline or something else so in fact
Wow I'm an idiot, thought I'd spotted a bug, yes there was a trailing space,
many thanks.
___
Hi all, I deleted a file (rm filter) by mistake instead of its backup 'filter~',
however it seems a remnant of a much older version of the file (given by its
date and content) is half hanging around?
$ ls -l filter
ls: filter: No such file or directory
$ ls -l filter*
-rw-r--r-- 1 lordcow lord
On Mon 2019-10-28 (14:24), Christoph Moench-Tegeder wrote:
> My analysis: screen dumps core on terminals with TERM=xterm* or
> TERM=rxvt* if they don't advertise Km ("key_mouse") capability
Ah great, many thanks and for the commit, and yes I had my TERM
set differently on the host.
___
Hi all, I upgraded from 11-STABLE r344000 to r353939 and now screen
(sysutils/screen)
crashes inside both my jails:
$ screen
[screen caught signal 11. (core dumped)]
(there's no core dump).
kernel log:
pid 56569 (screen), jid 2, uid 1001: exited on signal 6
This happens as a user or root,
On Tue 2012-09-18 (23:31), Gareth de Vaux wrote:
> Looking at /usr/src/share/mk/bsd.prog.mk and /usr/src/share/mk/bsd.lib.mk -
> bins and libs get installed with schg if PRECIOUSPROG and PRECIOUSLIB are
> set respectively in their makefiles, both of which can be overridden by
> sett
On Wed 2012-08-15 (08:58), Erich Dollansky wrote:
> On Tue, 14 Aug 2012 18:34:37 +0200
> > idVendor 0x1058 Western Digital Technologies, Inc.
> > idProduct 0x1042
>
> could it be that the kernel does not know this product?
>
> You can check the sources (usbdevs should be t
Hi all, I bought a Western Digital external drive a few months ago
but it gets kicked out 20 seconds after I plug it in. I've updated to
the latest 8.3-STABLE:
$ uname -a
FreeBSD file 8.3-STABLE FreeBSD 8.3-STABLE #0: Sun Aug 12 12:45:04 SAST 2012
root@file:/usr/obj/usr/src/sys/COWNEL amd64
On Thu 2012-01-05 (09:56), Matthew Seaman wrote:
> drive is actually generating errors.) Also try a few passes of
> memtest86 to try and spot problems with RAM.
Yes that was the problem, have gotten rid of a faulty DIMM and
everything is looking a lot saner, thanx :>
_
Hi all, I've noticed that the md5 hashes of a couple of files on
a gmirror change when I recalculate the hashes. The output usually
cycles between 2 hashes per file.
I'm guessing this is because each calculation reads the file
randomly from 1 of 2 component drives, and the files in question
had a
On Mon 2010-12-06 (13:07), Gareth de Vaux wrote:
> 'zpool replace' also only works if you physically swap out a disk
> at the same port, or replace disk1 with disk2 online. 'zpool remove'
> and 'zpool detach' don't remove devices from a raidz.
>
>
On Sat 2010-11-27 (15:22), Gareth de Vaux wrote:
> Hi all, I'm trying to simulate a disk fail and replacement in
> a raidz array and failing myself. What'm I doing wrong? Here's
Ok I did some science, it looks like the array doesn't like me
throwing zeros at the disk
On Thu 2010-12-02 (00:05), jhell wrote:
> Try that with a ( make includes ) in that same directory and if it works
> then the advisory will have to be revised.
Ah awesome, that works thanx.
(I don't see why though, since it was only half complaining about
a missing definition, even when I manuall
On Mon 2010-11-29 (21:19), FreeBSD Security Advisories wrote:
> # cd /usr/src
> # patch < /path/to/patch
> # cd /usr/src/secure/lib/libssl
> # make obj && make depend && make && make install
Hi all, I'm following the instructions with:
# cvsup /etc/cvsup-src.conf
# rm -rf /usr/obj
# cd /usr/sr
On Sat 2010-11-27 (07:30), Jeremy Chadwick wrote:
> uname -a please -- it matters greatly.
$ uname -a
FreeBSD file 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Wed Nov 24 07:56:04 SAST
2010 r...@file:/usr/obj/usr/src/sys/COWNEL amd64
___
freebsd-stabl
Hi all, I'm trying to simulate a disk fail and replacement in
a raidz array and failing myself. What'm I doing wrong? Here's
a transcript with interspersed commentary:
r...@file:~# zpool status
pool: raid
state: ONLINE
scrub: scrub completed after 0h0m with 0 errors on Sat Nov 27 13:20:06 2010
On Tue 2010-09-21 (11:31), Gareth de Vaux wrote:
> I assume I can't do this safely if my /usr/src tree has been updated
> since my last make world?
Well, doesn't look like it's an issue for me in this instance.
___
freebsd-stabl
Hi all, in for example
http://security.freebsd.org/advisories/FreeBSD-SA-10:08.bzip2.asc :
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/lib/libbz2
# make obj && make depend && make && make install
I assume I can't do this safely if my /usr/src tree has been updated
since my last make worl
On Tue 2010-09-14 (13:54), Gareth de Vaux wrote:
> On Tue 2010-09-14 (04:30), Jeremy Chadwick wrote:
> > Regarding net.inet.tcp.finwait2_timeout=15000 -- you don't see any
> > improvement at all? That's a bit strange. There's probably something
>
> If there
On Tue 2010-09-14 (04:30), Jeremy Chadwick wrote:
> Regarding net.inet.tcp.finwait2_timeout=15000 -- you don't see any
> improvement at all? That's a bit strange. There's probably something
If there was an improvement it was subtle (I was doing sporadic
measurements), just that in the end my fir
On Tue 2010-09-14 (04:03), Jeremy Chadwick wrote:
> You're absolutely certain these are all in FIN_WAIT_2 state and not
> TIME_WAIT?
Yup,
$ netstat -an | grep FIN_WAIT_1 | wc -l
57
$ netstat -an | grep FIN_WAIT_2 | wc -l
431
$ netstat -an | grep TIME_WAIT | wc -l
17
_
On Fri 2010-09-10 (13:49), Gareth de Vaux wrote:
> > Thirdly, if you feel FIN_WAIT2 is the cause of your problem, then you
> > should consider adjusting the following sysctl:
> >
> > net.inet.tcp.finwait2_timeout
> >
> > Try something like 15000 (15 se
On Fri 2010-09-10 (10:43), Jack Vogel wrote:
> No, not the add-on adapter, i have no trouble finding those, what I want to
> know about is the details about the system that has em0 LOM, only
> way to check on that is to have the whole enchilada :)
Ah right. These are snippets from dmidecode, is t
On Thu 2010-09-09 (17:00), Gareth de Vaux wrote:
> On Thu 2010-09-09 (16:54), Kurt Jaeger wrote:
> > -c asks for pci device capabilities, which are read in
> >
> > /usr/src/usr.sbin/pciconf/pciconf.c:177 with O_RDWR
>
> Ah. I'll have to schedule a reboot the
On Fri 2010-09-10 (10:41), Gareth de Vaux wrote:
> > Gareth, set hw.pci.honor_msi_blacklist=0, you'll have to do that at boot
> > btw.
>
> Ok, I'll have to get back to you in a day or 2 when I reboot.
Done:
$ sysctl -a | grep msi
hw.bce.msi_enable: 1
h
On Fri 2010-09-10 (03:18), Ian Smith wrote:
> Try using 'limit' rather than the unlimited 'keep-state' for inbound
> dynamic connections to your server/s. eg, derived from ipfw(8):
These are mostly legitimate connections though, they just aren't being
closed properly. So if limit were to have an
On Thu 2010-09-09 (09:20), Jeremy Chadwick wrote:
> Secondly, I'm fairly certain HTTP KeepAlive (re: KeepAliveTimeout) are
> unrelated to TCP keepalives[1]. I mention this because you're focusing
> on netstat, which will give you indication of TCP session state, not
> HTTP protocol statefulness.
On Fri 2010-09-10 (10:41), Gareth de Vaux wrote:
> http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058748.html
Just to reiterate - those are the specs of the PCI card that doesn't
work. The PCI card doesn't come up with MSIX failures. The onboard
has the MSIX
On Thu 2010-09-09 (13:48), Jack Vogel wrote:
> Gareth's email bouncing for anybody else or is it just me?
Yes sorry I disabled this alias after picking up years of spam on the
mailman archives. I assumed people would primarily reply to the list.
I've re-enabled it for now.
> Gareth, set hw.pci.h
Hi again, I use some keep-state rules in ipfw, but get the following
kernel message:
kernel: ipfw: install_state: Too many dynamic rules
when presumably my state table reaches its limit (and I effectively
get DoS'd).
netstat shows tons of connections in FIN_WAIT_2 state, mostly to
my webserver.
On Thu 2010-09-09 (16:54), Kurt Jaeger wrote:
> -c asks for pci device capabilities, which are read in
>
> /usr/src/usr.sbin/pciconf/pciconf.c:177 with O_RDWR
Ah. I'll have to schedule a reboot then ..
___
freebsd-stable@freebsd.org mailing list
http://
On Thu 2010-09-09 (07:24), Jeremy Chadwick wrote:
> Is this within a jail or something else along those lines? I can't
> reproduce the problem otherwise. Frustrating! Someone else on the list
> might have ideas as to what could cause this.
Nope, this's a normal host. I've got securelevel on 1,
On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote:
> You need to be root to use the -c flag. Despite your prompt, I don't
> think you're root. Reproduction:
That was as root,
# id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
# pciconf -lc
pciconf: /dev/pci: Operation not permitted
__
On Thu 2010-09-09 (06:13), Jeremy Chadwick wrote:
> Can you add the "-c" flag to your pciconf command? Thanks.
Forbidden?
# pciconf -lvc
pciconf: /dev/pci: Operation not permitted
# pciconf -lc
pciconf: /dev/pci: Operation not permitted
# ls -l /dev/pci
crw-r--r-- 1 root wheel0, 9 Sep
On Wed 2010-09-08 (09:41), Jack Vogel wrote:
> This is what'd I'd expect, the onboard is PCH chipset, support was not in
> 8.0, but as I said, in 8.1 (and hence stable/8) it is supported, and it should
> work.
I've just paid the machine a visit and yes, MSIX fails on the onboard but
the device sti
On Tue 2010-09-07 (13:25), Jack Vogel wrote:
> I've looked at the code, this message was misleading, what really happens
> is that the driver fails to be able to setup either MSIX OR MSI, when this
> happens it will fall back and use a Legacy interrupt, so its non-fatal and
> the device should work
On Tue 2010-09-07 (10:00), Jack Vogel wrote:
> First off, this device was not supported in 8.0 REL, what were you running
> that last worked?
Hey, I was running 8.0 REL and it worked. I installed the system from the
8.0 .iso, but the onboard card didn't work. I added the PCI card and it
worked.
>
Hi all, I moved from 8.0-RELEASE to last week's -STABLE:
$ uname -v
FreeBSD 8.1-STABLE #0: Thu Sep 2 16:38:02 SAST 2010
r...@x:/usr/obj/usr/src/sys/GENERIC
and all seems well except my network card is unusable. On boot up:
em0: port 0x3040-0x305f mem
0xe320-0xe321,0xe322-0xe3
37 matches
Mail list logo
