Hi,
I might be wrong but this:
free(mp->mnt_data, M_UNIONFSMNT); /* XXX */
mp->mnt_data = 0;
seems to me wrong and might cause crashes etc.
am I correct or wrong?
its from union_vfsops.c:384
thnx
Roman Divacky
___
[
Soeren Schmidt wrote:
> > which is named "FreeBSD")
> > And that's why FreeBSD panics until I delete the mirror relationship.
>
> Well Highpoints way of dealing with broken arrays and lost disks are less
> than optimal, I've tried to do my best in the ATA driver to fool the HPT
> system, but its no
Harald Schmalzbauer wrote:
Harald Schmalzbauer wrote:
Ok, like I thought, the disk was not defect. There seems to be a
bug in ata
regarding HPT372
First: Wiht BIOS version 2.342 the secondary master disk id is incorrectly
detected (something liek "X X X X X X X X X X X X X X X"
It seems Harald Schmalzbauer wrote:
>
> I also think the RAID configuration is stored on the disks since when I
> create a non-DOS compatible slice (starting at 0 not 63) the RAID
> configuration vanishes.
Yes the Highpoint BIOS uses sector 9 to hold the RAID config, so if you
use that for other
Harald Schmalzbauer wrote:
> Please forget that. It was because for convinience reasons I had turned the
> 80-pin ATA cables upside down. So the black was at the controller and the
> blue at the drive.
> I can't imagine that this makes any technical difference (as long as no
> slave drive is connec
Harald Schmalzbauer wrote:
> Ok, like I thought, the disk was not defect. There seems to be a
> bug in ata
> regarding HPT372
>
> First: Wiht BIOS version 2.342 the secondary master disk id is incorrectly
> detected (something liek "X X X X X X X X X X X X X X X" in
Andre Guibert de Bruet wrote:
> Harald,
>
> When in doubt, install freebsd 5.x on a different drive running off of a
> different controller, mount the slices from one of the disks in the RAID
> array and copy your data to a safe and trusted location.
Thanks for the hint, I did something like that.
Ok, like I thought, the disk was not defect. There seems to be a bug in ata
regarding HPT372
First: Wiht BIOS version 2.342 the secondary master disk id is incorrectly
detected (something liek "X X X X X X X X X X X X X X X" instead of
"IC25N030ATCS04-0"
I downgraded the BIO
Harald,
When in doubt, install freebsd 5.x on a different drive running off of a
different controller, mount the slices from one of the disks in the RAID
array and copy your data to a safe and trusted location.
Regards,
> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landma
r warns me that one drive is bad (which in fact is
> > definatley not) and allows me to select "continue boot"
>
> Did you try to replace that defective drive?
If it was defect I'd replace it. But I'm very absolutely sure it isn't
defective, it's a bug.
Doug White wrote:
> On Wed, 16 Jul 2003, Harald Schmalzbauer wrote:
>
> > I'm experimenting with 5.1-REL for some weeks and during that time I had
> > some mysterious hangs which I didn't take serious because I modified
> > /usr/src/sys/cam/scsi/scsi_da.c to support my CF-Card-Reader.
> > But now I
On Wed, 16 Jul 2003, Harald Schmalzbauer wrote:
> Now after resetting the machine which was hung by "sysinstall" it claims
> that ad4 (one of two mirrored 30GB 2.5" disks" was absent (see dmesg below)
> Now the controller warns me that one drive is bad (which in fact is
> definatley not) and allow
On Wed, 16 Jul 2003, Harald Schmalzbauer wrote:
> I'm experimenting with 5.1-REL for some weeks and during that time I had
> some mysterious hangs which I didn't take serious because I modified
> /usr/src/sys/cam/scsi/scsi_da.c to support my CF-Card-Reader.
> But now I saw exactly the same problem
Julian Elischer wrote:
> On Wed, 16 Jul 2003, Harald Schmalzbauer wrote:
>
> > Now after resetting the machine which was hung by "sysinstall" it claims
> > that ad4 (one of two mirrored 30GB 2.5" disks" was absent (see
> dmesg below)
>
> mirrored by what?
By ata. It is reognized as ar0 after setti
*snip*
> > Now the controller warns me that one drive is bad (which in fact is
> > definatley not) and allows me to select "continue boot"
>
> If the controler says it's bad, it may well be.
>
> > Now please give me a hint what to do. This is my brand new
> fileserver which
> > collected all im
On Wed, 16 Jul 2003, Harald Schmalzbauer wrote:
> Now after resetting the machine which was hung by "sysinstall" it claims
> that ad4 (one of two mirrored 30GB 2.5" disks" was absent (see dmesg below)
mirrored by what?
> Now the controller warns me that one drive is bad (which in fact is
> def
On Wed, Jul 16, 2003 at 03:47:25AM +0200, Harald Schmalzbauer wrote:
> Now after resetting the machine which was hung by "sysinstall" it claims
> that ad4 (one of two mirrored 30GB 2.5" disks" was absent (see dmesg below)
> Now the controller warns me that one drive is bad (which in fact is
> defin
my fileserver dies my workstation also died
> (home was nfs-mounted)
>
> I'm no developer, but if someone tells me what to do I'll help
> solving that
> BUG.
>
> Here is some info about my two machines (which are running 5.1-release and
> showed the same bug):
>
&
nfs-mounted)
I'm no developer, but if someone tells me what to do I'll help solving that
BUG.
Here is some info about my two machines (which are running 5.1-release and
showed the same bug):
VIA FIleserver
FreeBSD 5.1-RELEASE #2: Fri Jul 4 14:02:06 CEST 2003
I've found what looks like it might be a bug in devinfo - listing resources
by type, there are far too many 'open if_tun unit' resources: there are over
126,000 lines, repeating
0 (root0)
1-32767 (root0)
for about 500 lines, before there's another 'open if_tun units:
On Sun, Jul 13, 2003 at 03:40:21PM -0700, Andrew P. Lentvorski, Jr. wrote:
> I tried to file a bug for one of my -CURRENT machines using send-pr and
> got the following result back:
>
> > - The following addresses had permanent fatal errors -
> ><[EMAIL PROTECT
ry to send word about this to the postmaster of
freebsd.org.
Best,
-Jon
Andrew P. Lentvorski, Jr. wrote:
I tried to file a bug for one of my -CURRENT machines using send-pr and
got the following result back:
- The following addresses had permanent fatal errors -
<[EMAIL PROTECTED]>
I tried to file a bug for one of my -CURRENT machines using send-pr and
got the following result back:
> - The following addresses had permanent fatal errors -
><[EMAIL PROTECTED]>
>(reason: 450 : Helo command rejected: Host not found)
Presumably this means tha
On Fri, Jul 11, 2003 at 09:15:48PM -0700, Scott M. Likens wrote:
> Jul 11 16:45:20: ide0:0|NOT_IMPLEMENTED F(831):712
> Jul 11 16:45:20: ide0:0|AIO: ide0:0, Process 60017 panic.
> Jul 11 16:45:20: ide0:0|AIOSlave: Exit after panic.
> Jul 11 16:45:20: VMX|AIO: NOT_IMPLEMENTED F(831):712
> Jul 11 16:
h the underlying hardware than most Linux
> > emulated programs, the likelihood for such an operation to fail
> > increases. As far as I understand it, the solution involves more fully
> > implementing the Linux emulation.
>
> Actually it's during shutdown that this bu
On Sat, 2003-07-12 at 08:00, Daniel Eischen wrote:
> On 11 Jul 2003, Scott M. Likens wrote:
>
> > I've been using VMWare in 5.1-RELEASE for quite some time and such, and
> > have ALWAYS gotten this bug and haven't been able to figure out exactly
> > why it does
n to fail
> increases. As far as I understand it, the solution involves more fully
> implementing the Linux emulation.
Actually it's during shutdown that this bug occurs
It's quite annoying on top of the 'rtc.ko' wanting to dump and creating
a infinite loop panic at shutdown i
On 11 Jul 2003, Scott M. Likens wrote:
> I've been using VMWare in 5.1-RELEASE for quite some time and such, and
> have ALWAYS gotten this bug and haven't been able to figure out exactly
> why it does this, but it requires me to reboot.
>
> Anyhow here's the layout
Either this, or it could just be a plain bug in VMWare -- though I've
learned from experience that it's always best to blame oneself before
assuming others are at fault.
signature.asc
Description: This is a digitally signed message part
I've been using VMWare in 5.1-RELEASE for quite some time and such, and
have ALWAYS gotten this bug and haven't been able to figure out exactly
why it does this, but it requires me to reboot.
Anyhow here's the layout of the system.
P3 800Mhz with 512meg of SDRAM
AHA 2940U2W, D
On 28-Jun-2003 Marco Wertejuk wrote:
| I don't know since when this happens, but I've noticed,
| that the ETA time looks strange:
|
Doh, looks like I included the wrong patchset when I did the latest
import. I've just fixed this in CVS.
Thanks,
Mike
--
Mike Heffner <[EMAIL PROTECTED
I don't know since when this happens, but I've noticed,
that the ETA time looks strange:
While fetching this file:
lrwxr-xr-x 1 ftp ftp 36 Jun 27 15:43 live-current.iso ->
live-5.1-CURRENT-20030627-JPSNAP.iso
-rw-r--r-- 1 ftp ftp 238714880 Jun 27 15:42 live-5.1-CURRENT-20030627-JPSNA
Hi,
I have a i386 machine with Gigabyte 7ZXR mainboard here (Duron, VIA
KT133 chipset, AMI BIOS).
acpiconf -s1 and -s5 are apparently "working" ok, -s2 is refused (OK),
-s3 is refused (might be I didn't set the jumper correctly :o) and -s4
puts the machine to some sort of sleep (power LED blinks,
On Thu, 12 Jun 2003, Tim Robbins wrote:
> On Thu, Jun 12, 2003 at 06:29:44PM +1000, Tim Robbins wrote:
>
> > Here's a test program for the i386 alloca() bug. Compile with -std=gnu89 (or
> > no -std option) and it works fine. Compile with -std=c99 or -std=c89 and
< said:
> builtin alloca() until we figure out how to fix the one in libc.
It is fundamentally impossible to ``fix'' the alloca() implementation
in libc. alloca() CANNOT be implemented that way. If GCC's builtin
alloca() is disabled by requesting a strict Standard C environment
(which is not ap
On Thu, Jun 12, 2003 at 06:29:44PM +1000, Tim Robbins wrote:
> Here's a test program for the i386 alloca() bug. Compile with -std=gnu89 (or
> no -std option) and it works fine. Compile with -std=c99 or -std=c89 and it
> breaks like this:
>
> corruption: 05 should be 0xcc at o
Here's a test program for the i386 alloca() bug. Compile with -std=gnu89 (or
no -std option) and it works fine. Compile with -std=c99 or -std=c89 and it
breaks like this:
corruption: 05 should be 0xcc at offset 0
corruption: 00 should be 0xcc at offset 1
corruption: 00 should be 0xcc at off
It looks like we are calling the ahc_chip_init()
code in the ahc/aic7xxx driver on shutdown. Is that correct?
--
Pawel
boot() called on cpu#0
Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
Waiting (m
On Fri, 06 Jun 2003 10:26:01 -0700
Adam <[EMAIL PROTECTED]> wrote:
> I found a bug in the /ports/net/naios port. More correctly, I think it
> would be in /ports/net/nagios-plugins.
>
> I had Postgres 7.2 installed on my system. I did this manually from source.
> It seems
Adam wrote:
I found a bug in the /ports/net/naios port. More correctly, I think it
would be in /ports/net/nagios-plugins.
I had Postgres 7.2 installed on my system. I did this manually from
source. It seems that when you choose to have postgres support for
nagios, it doesn't check to s
I found a bug in the /ports/net/naios port. More correctly, I think it
would be in /ports/net/nagios-plugins.
I had Postgres 7.2 installed on my system. I did this manually from source.
It seems that when you choose to have postgres support for nagios, it
doesn't check to see if the li
On Wed, 4 Jun 2003, Jeremy Messenger wrote:
> Sweet, thanks! This is what I need, which it made easier to locate the
> library that use libc_r.. I have found two that need to be link to libc_r
> instead libthr so far..
>
> /usr/X11R6/lib/libgnomeui-2.so.300
> /usr/local/lib/libgthread-2.0.so.200 <-
On Wed, 4 Jun 2003 16:55:35 -0400 (EDT), Matthew N. Dodd <[EMAIL PROTECTED]>
wrote:
On Wed, 4 Jun 2003, Jeremy Messenger wrote:
Nevermind, I think you are right it does work. Because, I did the test
on mplayer by install it. It does link mplayer to libc_r correct, while
not ggv. Looks like I will
On Wed, 4 Jun 2003, Jeremy Messenger wrote:
> Nevermind, I think you are right it does work. Because, I did the test
> on mplayer by install it. It does link mplayer to libc_r correct, while
> not ggv. Looks like I will have to chase on ggv to find what ggv is
> depending on and get them link to li
On Wed, 04 Jun 2003 13:05:26 -0500, Jeremy Messenger <[EMAIL PROTECTED]> wrote:
On Wed, 4 Jun 2003 08:54:07 -0400 (EDT), Matthew N. Dodd
<[EMAIL PROTECTED]> wrote:
On Tue, 3 Jun 2003, Jeremy Messenger wrote:
# ./test-libmap /usr/X11R6/bin/ggv libc_r.so.5
Lookup o
On Wed, 4 Jun 2003 08:54:07 -0400 (EDT), Matthew N. Dodd <[EMAIL PROTECTED]>
wrote:
On Tue, 3 Jun 2003, Jeremy Messenger wrote:
# ./test-libmap /usr/X11R6/bin/ggv libc_r.so.5
Lookup of "libc_r.so.5" for "/usr/X11R6/bin/ggv" -> "libc_r.so.5"
===
On Tue, 3 Jun 2003, Jeremy Messenger wrote:
>
> # ./test-libmap /usr/X11R6/bin/ggv libc_r.so.5
> Lookup of "libc_r.so.5" for "/usr/X11R6/bin/ggv" -> "libc_r.so.5"
>
Looks like its working to me.
>
>
Zbynek Houska wrote:
Dear all,
when I tryied to mount an iso image over network (using samba) my computer
unexpectedly crashed.
I issued this command : mdconfig -a -t vnode -f
/path/to/my/file/mounted/on-local-machine
and since that kernel crashed, no ping response, nothing at all. I've been
On Tue, 3 Jun 2003 22:51:59 -0400 (EDT), Matthew N. Dodd <[EMAIL PROTECTED]>
wrote:
On Tue, 3 Jun 2003, Jeremy Messenger wrote:
It seems like the [/path/to/exec] and [exec] don't work?
ftp://ftp.jurai.net/users/winter/libmap-test.tar
Untar that in src/libexec/rtld-elf/
cd test/
make
./test-libma
On Tue, 3 Jun 2003, Jeremy Messenger wrote:
> It seems like the [/path/to/exec] and [exec] don't work?
ftp://ftp.jurai.net/users/winter/libmap-test.tar
Untar that in src/libexec/rtld-elf/
cd test/
make
./test-libmap /path/to/exec library-name
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo
bthr, but it
doesn't work as expect.. Maybe, I must have done something wrong?
Make sure that you have rev 1.6 of src/libexec/rtld-elf/libmap.c. It
fixes a bug in the libmap.conf parsing code.
I downgrade from 1.7 -> 1.6 and the problem is still there. I CVSup'ed
yesterday around 3
e sure that you have rev 1.6 of src/libexec/rtld-elf/libmap.c. It
fixes a bug in the libmap.conf parsing code.
I downgrade from 1.7 -> 1.6 and the problem is still there. I CVSup'ed
yesterday around 30 to 45 minutes before my 'uname -a' in the bottom.
Cheers,
Mezz
==
On Tue, Jun 03, 2003 at 03:50:00PM -0500, Jeremy Messenger wrote:
> I am trying to get ggv link against libc_r instead libthr, but it doesn't
> work as expect.. Maybe, I must have done something wrong?
Make sure that you have rev 1.6 of src/libexec/rtld-elf/libmap.c. It fixes
a
I am trying to get ggv link against libc_r instead libthr, but it doesn't
work as expect.. Maybe, I must have done something wrong?
# cat /etc/libmap.conf
libc_r.so.5 libthr.so.1
libc_r.so libthr.so
[/usr/X11R6/bin/ggv]
libc_r.so.5
On Wed, 28 May 2003, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Bruce Evans <[EMAIL PROTECTED]> wrote:
> > On Tue, 27 May 2003, Terry Lambert wrote:
> >
> > > BTW: signal stacks are irrelevent; technically, you are not
> > > allowed to do floating point in signal handlers anyway. 8-
In article <[EMAIL PROTECTED]>,
Bruce Evans <[EMAIL PROTECTED]> wrote:
> On Tue, 27 May 2003, Terry Lambert wrote:
>
> > BTW: signal stacks are irrelevent; technically, you are not
> > allowed to do floating point in signal handlers anyway. 8-).
>
> Not true. Signal handlers can do almost anyt
On Tue, 27 May 2003, Terry Lambert wrote:
> BTW: signal stacks are irrelevent; technically, you are not
> allowed to do floating point in signal handlers anyway. 8-).
Not true. Signal handlers can do almost anything with local variables.
The main relevant restrictions on them is that they must
Dear all,
when I tryied to mount an iso image over network (using samba) my computer
unexpectedly crashed.
I issued this command : mdconfig -a -t vnode -f
/path/to/my/file/mounted/on-local-machine
and since that kernel crashed, no ping response, nothing at all. I've been
connected to this ma
<---
Which output is:
% cc -o test test.c
% ./test
1.0
10.00
100.000
1000.
1.0
1.0
11.0
101.0
1001.0
10001.0
I suspect a bug in gdtoa since I get the correct output with
5.0-RELEASE. I cvsup'ed up src-all and now I'm running:
FreeBSD gluon.dyndns.org 5.0-CURRENT FreeBSD 5.0-CU
r that test.
>
> Luckily I had a kernel.debug lying around so I used gdb to peek into the
> kernel memory. In the nd_ifinfo for that interface, linkmtu=100 and
> maxmtu=1500. Once I manually reset linkmtu to 1500, IPv6 started
> working properly
al reason for that test.
Luckily I had a kernel.debug lying around so I used gdb to peek into the
kernel memory. In the nd_ifinfo for that interface, linkmtu=100 and
maxmtu=1500. Once I manually reset linkmtu to 1500, IPv6 started
working properly again, without having to sacrifice my uptime :)
An
Dag-Erling Smørgrav wrote:
walt <[EMAIL PROTECTED]> writes:
... Looking thru sys/geom I don't see any
such ifdefs in your code, so I still don't know why the
recent geom bug was hidden by INVARIANTS.
On the contrary, there is a lot on INVARIANTS-specific code in GEOM:
[EMAIL
ch ifdefs in your code, so I still don't know why the
> recent geom bug was hidden by INVARIANTS.
On the contrary, there is a lot on INVARIANTS-specific code in GEOM:
[EMAIL PROTECTED] /sys/geom% grep -r KASSERT . | wc -l
120
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
T
e wishes with an ifdef statement. That covers a
lot of territory. Looking thru sys/geom I don't see any
such ifdefs in your code, so I still don't know why the
recent geom bug was hidden by INVARIANTS.
Hope you're feeling better :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with &
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
reveal their causes. However, INVARIANTS is
slightly invasive; it adds code to the kernel, and in some cases
changes data structures a little, and these changes have subtle side
effects which may cause a bug to go into hiding. Such bugs are called
"heisenbugs" (because the presence of
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
> Running:
>
> #!/bin/sh
> set -ex
>
> for p in ad2 ad0 ad1
> do
> a0=`expr $p : '^ad\([0-9]\)$'`
> done
>
> I get:
>
> syv# sh _
> + expr ad2 : ^ad\([0-9]\)$
> + a0=2
> + expr ad0 : ^ad\([0-9]\)$
> + a0=0
> syv# ec
t;
> syv# sh _
> + expr ad2 : ^ad\([0-9]\)$
> + a0=2
> + expr ad0 : ^ad\([0-9]\)$
> + a0=0
> syv# echo $?
> 1
> syv#
>
> That looks like a bug to me...
Confusing but documented behaviour:
1. expr ad0 : ad\([0-9]\) => expr
On Tue, 2003-02-18 at 06:39, Poul-Henning Kamp wrote:
> + expr ad0 : ^ad\([0-9]\)$
> + a0=0
> syv# echo $?
> 1
> syv#
>
> That looks like a bug to me...
hilfy:202 Z$ /bin/expr ad0 : '^ad\([0-9]\)$'
0
zsh: exit 1 /bin/expr ad0 :
syv# echo $?
1
syv#
That looks like a bug to me...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To U
>to how I could track down the cause of this bug, and hopefully fix it?
I don't have any P5A boards, so I'm really at a loss with this one.
Basically, something about about ACPI timer does not match spec and
I have no idea what it is, or for that matter how to reliably detect
it.
The clock on my ASUS P5A still runs at double speed unless I have
debug.acpi.disable="timer" in loader.conf (as it has for as long as
we've had ACPI support). Do any ACPI wizards have any suggestions as
to how I could track down the cause of this bug, and hopefully fix it?
DES
* David Malone <[EMAIL PROTECTED]> [030209 10:04] wrote:
> On Sun, Feb 09, 2003 at 10:00:02AM -0800, Alfred Perlstein wrote:
> > Heh, the format string is passed through printf later, we don't want
> > to eat the extra % otherwise it will cause problems for us.
>
> I had exactly the same thought a
On Sun, Feb 09, 2003 at 10:00:02AM -0800, Alfred Perlstein wrote:
> Heh, the format string is passed through printf later, we don't want
> to eat the extra % otherwise it will cause problems for us.
I had exactly the same thought as Warner last night, but then
realised that we were about to call p
* M. Warner Losh <[EMAIL PROTECTED]> [030209 08:39] wrote:
> In message: <[EMAIL PROTECTED]>
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> : syslog(3) botches things if you pass it a string that has "%%m" in it.
> : this should fix it, any comments?
> :
>
> With the above fix, "fre
In message: <[EMAIL PROTECTED]>
Alfred Perlstein <[EMAIL PROTECTED]> writes:
: syslog(3) botches things if you pass it a string that has "%%m" in it.
: this should fix it, any comments?
:
: Index: syslog.c
: ===
: RCS file
syslog(3) botches things if you pass it a string that has "%%m" in it.
this should fix it, any comments?
Index: syslog.c
===
RCS file: /home/ncvs/src/lib/libc/gen/syslog.c,v
retrieving revision 1.28
diff -u -r1.28 syslog.c
--- syslog.
Thus spake Maxim Konovalov <[EMAIL PROTECTED]>:
> newfs(8) incorrectly claims that FS_OPTTIME is unavailable when
> minfree is less than MINFREE. MINFREE is defined in ufs/ffs/fs.h:
>
> #define MINFREE 8
>
> But relevant code in ufs/ffs/ffs_alloc.c uses hardcoded value:
>
> 288 if (fs->
On Thu, Jan 23, 2003 at 01:42:58PM +0300, Maxim Konovalov wrote:
> Any objections to a diff below?
We should be moving away from magic numbers to #defined constants, not
the otherway around.
> Index: newfs/newfs.c
> ===
> RCS file:
Hello,
newfs(8) incorrectly claims that FS_OPTTIME is unavailable when
minfree is less than MINFREE. MINFREE is defined in ufs/ffs/fs.h:
#define MINFREE 8
But relevant code in ufs/ffs/ffs_alloc.c uses hardcoded value:
288 if (fs->fs_minfree <= 5 ||
289 fs->fs_cstotal.cs_nffree >
2
Hi ...
I have recently been upgrading to 5.0 [now on RELEASE!] and
I have one patch I've been applying which solves a problem
introduced by a change in ffs_mountfs() where a read-only
mount request insists on opening the device in R/W mode.
This is fine for the reasons it was done, but it means
able-module agp (which worked, he said he wouldn't
load it anymore); load kernel;" an lsmod still shows agp.1.
Is this a bug or can't I disable agp-support on installation cdroms?
The machine doesn't detect agp-devices when booting with boot-floppies, so
I think that should be pos
Is there any chance of getting the fix suggested in PR-47024 in 5.0
before release? Looks like a similar script bug with natd start-up was
fixed in 4.x-STABLE back in Feb. of 2002 -- See the CVS logs for
/etc/rc.network, in particular, cjc's log entries for revision 1.124
(MAIN) and rev
On 19-Dec-2002 Matthew Dillon wrote:
> This is a real mess but I finally got it to work. (Note
> to John: both quirk entries are absolutely necessary,
> everything stalls and dies without them).
You might need to lie to umass and tell if to use the UFI or ATAPI
protocols instead of
Hello all,
I recently updated my world to a releng5 source tree from 12/27. I noticed
that almost all of the RCNG scripts work perfectly for diskless (PXE) booting.
There is one minor problem that can easily be fixed. Upon booting the rc
scripts immediately initiate fsck of file systems. Si
t(_tag) doesn't extract the correct bits from TAG,
so it drop packets that shouldn't be dropped. It's the bug fixed by my
patches. I tested it on 4.7. The patch for CURRENT isn't tested, but
it's simple to analyse that there are the same problem.
It's the sufficien
On Sun, Dec 22, 2002 at 12:06:02AM -0600, Geoffrey T. Falk wrote:
> To disable sendmail, one expects to set "sendmail_enable=NO" in
> /etc/rc.conf.
>
> /etc/rc.sendmail looks for sendmail_enable=[Nn][Oo][Nn][Ee]
> (should be [Nn][Oo] to conform with standard usage.)
>
> The consequence is that an
To disable sendmail, one expects to set "sendmail_enable=NO" in
/etc/rc.conf.
/etc/rc.sendmail looks for sendmail_enable=[Nn][Oo][Nn][Ee]
(should be [Nn][Oo] to conform with standard usage.)
The consequence is that an administrator may intend to disable
sendmail, but it will still be enabled.
g.
are nge, bge, txp, gx,
> em, ti (ti aren't affected by reported bug as it strips the priority
> bits at driver level).
Dan, I believe you submitted a PR about this [1], what does patch try to
solve, regarding VLAN hardware support?
[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern
In article <[EMAIL PROTECTED]>,
Daniel C. Sobral <[EMAIL PROTECTED]> wrote:
>
> Does fxp have hardware support for vlans? I use vlans extensively and
> never noticed a problem.
The 82550 and 82551 chips support hardware insertion/stripping of
VLAN tags. But our driver doesn't currently make use
At 02:45 AM 12/21/2002 +0100, Dan Lukes wrote:
> At 10:22 PM 20/12/2002 +0100, Dan Lukes wrote:
> If there somebody failing to configure vlans on a nic with
> vlan-hardware support - read the PR 46405 (patch attached).
> Mike Tancsa wrote, On 12/20/02 22:46:
>
> At 10:22 PM 20/12/2002 +0100, Dan Lukes wrote:
> If there somebody failing to configure vlans on a nic with
> vlan-hardware support - read the PR 46405 (patch attached).
> Mike Tancsa wrote, On 12/20/02 22:46:
> Does this bug show up in the trunk ports sta
ort for vlans? I use vlans extensively and
never noticed a problem.
IFAIK no. I tried it also during debug of my problem. But it doesn't
support 1000BaseTX, so it isn't decision for my purpose.
The only cards with HW vlan support on STABLE are nge, bge, txp, gx,
em, ti (ti aren&#x
Dan Lukes wrote:
>
> If there somebody failing to configure vlans on a nic with
> vlan-hardware support - read the PR 46405 (patch attached).
>
> It's apply to both current and stable.
Does fxp have hardware support for vlans? I use vlans extensively and
never noticed a problem.
Hi,
Does this bug show up in the trunk ports statistics as runt packets ?
---Mike
At 10:22 PM 20/12/2002 +0100, Dan Lukes wrote:
If there somebody failing to configure vlans on a nic with
vlan-hardware support - read the PR 46405 (patch attached).
It's
If there somebody failing to configure vlans on a nic with
vlan-hardware support - read the PR 46405 (patch attached).
It's apply to both current and stable.
Dan
--
Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206
root of FIONet, KolejNET, webmaster of www.freebsd.cz
AKA: [EM
:The NetBSD code is already different:
:1.48 (augustss 15-Sep-99): /* The OHCI hardware can handle at
:most one page crossing. */
:1.48 (augustss 15-Sep-99): if (OHCI_PAGE(dataphys) ==
:dataphysend ||
:1.48 (augustss 15-Sep-99):
On Thu, Dec 19, 2002 at 05:11:32PM -0800, Matthew Dillon wrote:
> I found another couple of bugs, this time in OHCI's DMA
> buffer chaining code.
Great.
> A patch for this with additional debugging code is
> included below (for current). There are two bugs.
> I do not know i
:First, the calculation of dataphysend is totally bogus.
:You can just take the physical address and add (len - 1)
:to it. You have to take the virtual address, add len - 1
:to it, and convert it to a physical address. I can
:crash my machine simply by doing a
God, my g
701 - 800 of 1463 matches
Mail list logo
