remote:/usr/obj
over the local /usr/obj before doing the make installworld. (This was my
first foray into updating binaries on machine A from a build done on machine
B. The instructions in the makefile left room for imagination.)
I know this isn't a complete answer to your question, just a cl
t overclocking, then bad ram would make a good second suspect, I
had a failing DIMM a couple years ago first manifest as signal 10 and 11
errors in cc1.
-- Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
peruse the list archives in the future to ignore Terry Lambert.
-- Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
e command line) so this time it has the
info from NFS filesystems, but it doesn't recalculate the field widths. The
following patch should fix it without breaking other behaviors, I belive.
-- Ian
--- df.c.origFri May 17 11:30:55 2002
+++ df.cFri May 17 11:31:39 2002
@@ -203,
On 05/17/02 14:09, Terry Lambert wrote:
> Ian wrote:
>> On 05/17/02 10:27, Riccardo Torrini wrote:
>>> I manually mount nfs fs after a reboot (current -> stable) and
>>> if I do a "df" I got two different output. First time it get
>>> garbled, al
On 05/18/02 17:41, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Terry Lambert writes:
>> I think the reason for the "if" is to keep the df from hanging
>> indefinitely, particularly when you give it an explicit list.
>
> No, I believe the "if (
een. Only way to use X at all is to disable sync and not to
>use keyboard and mouse at the same time.
Do you have a monitor switch? If so, I bet it is a cybex one. Look
in the manual for the 'reset mice' control sequence -- that seems to
do the trick for me.
Best;
Ian.
--
x pretends to be an Intellimouse even when you
don't have one [or this is what seems to happen in my case], and so
FreeBSD detects that you have an Intellimouse. However, then it all
goes wrong, and I don't really know why!
Best;
I.
--
Ian Whalley, .sig under construction.
Email:
On Tue, Jan 04, 2000 at 09:06:14AM +, Alex wrote:
> Today's -current:
>
> Copyright (c) 1992-2000 The FreeBSD Project.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California. All rights
> reserved.
> FreeBSD 4.0-CURRENT #21: Tue Jan 4 08:00:34 GMT
On Sun, Jan 09, 2000 at 06:16:30AM -0500, Donn Miller wrote:
> It looks like the ESS 1868 is working OK now with the DSP_BUFFSIZE set
> to 8192. Before, it wouldn't work unless I set this value to (65536 -
> 256), which was the original value, I believe. So, why does the ESS
> work OK now with a
On Tue, Jan 25, 2000 at 09:40:11AM +0100, Anders Andersson wrote:
> I have the same problem:
>
> [anders@enterprise:anders] $ dmesg | grep ata
> ata-pci0: port 0xffa0-0xffaf at device 7.1
> on pci0
> ata0 at 0x01f0 irq 14 on ata-pci0
> ata-isa0: already registered as ata0
> ata0-slave: ata_comma
ng
always corresponds within a few minutes to the filesystem becoming full
(/var/log/messages will have a flurry of 'file system full' messages
just before the reboot).
An example trace is below. Let me know if any further information would
be useful.
Ian
#0 boot (howto=256) at ../../k
it should back out the changes on failure.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In message <[EMAIL PROTECTED]>, Ian Dowse writes:
>
>The fix should be relatively straightforward - either the code should
>avoid linking new indirection blocks until all allocations succeed,
>or it should back out the changes on failure.
Here's one patch that seems to
HPUX} through a major revision without access
to the console...), but in an effort to save several hour drive,
I figured I'd ask if anyone had had any success doing an upgrade
remotely...
So... anyone done it?
Best;
inw
--
Ian Whalley
@ . org
To Unsubscribe: send mail to [EMAIL PROTECTE
ords, UPDATING can't comment on vaporware.
Heh. That's fair enough -- I will wait until 4.0 is -STABLE.
Cheers;
inw
--
Ian Whalley
@ . org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.26 running under perl 5.00503.
-
[Please enter your report here]
Running following program causes "Floating point exception" on
FreeBSD 3.2
More on that!
Lads here took this to heart and put the debugger over the code.
Apparently, Linux uses glibc which sets the flags in FPU to ignore
the cmp-NaN fault. Then, I guess, Perl picks it up and turns it into
NaN. OTOH, FreeBSD libraries don't do that, and the FPU causes
the cmp-NaN faul
XINT_THRESH.
Assuming an even balance of transmitted and received packets, this should
reduce the total number of interrupts by nearly 50%. I don't know if
drivers for other cards do (or even can) use this approach.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
y,
mid-evening EDT. This is the first -current build I've
done since if_xl was converted to miibus.
My card is identified as <3Com 3c905B-TX Fast Etherlink XL>.
Best;
inw
--
Ian Whalley
@ . org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
previously used mars_nwe on Linux to accomplish precisely
the same thing, and it worked great. Now my home server is
FreeBSD, and I want to do the same thing again.
Any advice?
Best;
inw
--
Ian Whalley
@ . org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-cur
out that it's only nearest
server discovery that doesn't want to work (in spite of mars_nwe
being configured to respond to nearest server broadcasts).
If I specify the preferred server for the DOS clients, it all
works.
Normal service is resumed.
Best;
inw
--
Ian Whalley
@ . or
d never
used SiS cards before so I assumed they weren't properly supported by
the XFree people.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
command line. This
will typically happen if you have a dangling symbolic link somewhere
in /usr/include. The error message indicating exactly which files
h2ph couldn't open will be somewhere among all the 'XX.h -> XX.ph'
messages.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RT/LOCK_LOG/WITNESS bits.
A simple workaround that seems to stop the panics is below.
Ian
Index: mutex.h
===
RCS file: /dump/FreeBSD-CVS/src/sys/sys/mutex.h,v
retrieving revision 1.41
diff -u -r1.41 mutex.h
--- mutex.h
es mdmfs accept "mount_mfs"
or "mfs" to trigger compatibility mode instead of mount_*.
Ian
Index: mdmfs.8
===
RCS file: /dump/FreeBSD-CVS/src/sbin/mdmfs/mdmfs.8,v
retrieving revision 1.8
diff -u -r1.8 mdmfs.8
--- mdm
ults anyway, so they should probably be used in all
cases except those that are necessary for compatibility with
mount_mfs.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Apologies for this - I missed out a file in a commit earlier. Fixed
now. Any other (non-module) complaints about opt_ed.h can be cured
by rerunning config.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
o 0, so it needs to be done explicitly. Server
op functions must return 0 in order for a reply to be sent to the
client.
Ian
Index: nfs_serv.c
===
RCS file: /home/iedowse/CVS/src/sys/nfsserver/nfs_serv.c,v
retrieving revision 1.107
diff
onfigure ethernet0." I added some printf's to
>linux_ioctl.c, and it seems the linux_ioctl_socket() gets a device
>name which is "", i.e. the empty string.
There was a discussion about this and workaround patches for RELENG_4
on -emulation. I'll try to organise with
n" (/usr/ports/devel/linux_kdump) and look for
any ioctls that it does immediately before giving that error message.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
;t. Try updating your sources again; revision 1.76 is des's
patch with a few problems fixed.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
issing frame. The
name Xresumefast is chosen because it involves no ddb or gdb changes
(they just check for a name beginning with "Xresume").
Any comments?
Ian
Index: sys/i386/isa/icu_vector.s
===
RCS file: /dump/FreeBS
aster nfsd receives
a SIGCHLD. This behaviour is probably reasonable enough, but the
way it happens is a bit odd.
Thomas, I'll probably commit this within the next few days if you
have no objections, and if you don't get there before me. The
exiting behaviour can be res
Obviously, it
should also somehow not install a partition table unless boot1 is
being used as the MBR, and the fdisk -I method should be preferred.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
I never got around to
fixing it. There's one spelling type s/mentionned/mentioned/ and
maybe "type stable" should be hyphenated.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
s the need to assume that all xxx_args
have the export_args in the same place by storing the offsets in a
table. I am aware that there is work ongoing in the area of mount(2),
so maybe the patch is overkill at this time. Any comments?
Ian
Index
manner, even if exports are still managed
per-filesystem in the kernel.
However for this bug (ext2fs and hpfs filesystems cannot be un-exported
once they have been exported) I am just looking for a quick solution
for now, but I have already put some thought into improving the
mountd-kernel in
at was added to
the kernel build flags recently.
This compiles for me, but I haven't checked that it actually works.
Ian
Index: ddp_input.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/netatalk/ddp_input.c,v
retrieving revision
e guarantee
that single transfers don't cross a 64k boundary, which is important
for floppies :-( I'll fix this shortly. Thanks for pointing out the
problem!
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
http://www.maths.tcd.ie/~iedowse/FreeBSD/kern.flp
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
l commit the change in a
few hours after I have tested that it works.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
from the parameters actually
set on the disk.
If the kernel was to panic half-way through a growfs operation, or
if growfs died, say because the kernel failed to fault in some
pages from the growfs executable, you could end up with a very
confused filesystem!
Ian
To Unsubscribe: send ma
er of big apps running,
it can take around 20 seconds for all the paging to die down after
the SIGTERMs are sent.
I know the choice of sysctl to monitor is slightly arbitrary, but
it seems to have the right overall effect. Does anyone have any
objections to my committing this?
Ian
Index: reb
The last set of changes to fsck_ffs moved the initialisation of
dev_bsize to sblock_init(), but this is not called by fsdb(8) so
fsdb dies almost immediately with a floating exception. I'm just
going to commit the obvious fix, which is to have fsdb call
sblock_init() also.
Ian
To Unsubs
cking if the new superblock fields are zero, so if an old fsck
zeros them out between a read-oly mount and a read-write remount,
then we get a division by zero or something later.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In message <[EMAIL PROTECTED]>, John Baldwin writes:
>
>
>Fair enough, I guess ffs_reload() should just sanity check the values. Any
>takers?
You could try this (untested). I have to run now, but I can test it
later as it's easy enough to reproduce.
I
In message <[EMAIL PROTECTED]>, Ian Dowse writes:
>You could try this (untested). I have to run now, but I can test it
>later as it's easy enough to reproduce.
Almost, but I missed the fs_contigdirs field, which was the real
culprit. An updated patch is below; this seems to st
lt preserves the last-modified time of a file when
gzipping, so these times are actually the times at which the wtmp
file was previously modified before being rotated.
Try "ls -lc", which will show up the rotation time.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "un
er over the next few
days; for now maybe try cleaning out mountdtab manually?
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
structure from the fs-specific mountstructure
to struct mount.
...
Doing a MNT_DELEXPORT mount used to be a no-op if there were no
exports, but now it returns EINVAL. Maybe that should be changed
to ENOENT or something, so that mountd can detect it as a 'normal'
error?
In message <[EMAIL PROTECTED]>, Ian Dowse writes:
>error? (untested patch below).
I braino'd that patch (error vs. errno), but I have just committed
a working version that should stop the mountd warnings.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
In message <[EMAIL PROTECTED]>, Ian Dowse writes:
>iedowse 2001/05/29 13:45:09 PDT
>
> Modified files:
>sbin/fsck_ffssetup.c
> Log:
> Ignore the new superblock fields fs_pendingblocks and fs_pendinginodes
> when comparing with the alternate superb
s that using an alternate superblock will undo
any changes made by tunefs, unless the '-A' flag had been used with
tunefs originally. Typically this will result in soft-updates
getting disabled.
RELENG_4's fsck could probably be updated to deal with this a bit
better, but I don't think
system from before the rename that took
place last month.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
oad average behaviour when loadav() is called at different times,
this case needs to be removed.
- The load average calculation now has really nothing to do with
the VM system, so it could be moved elsewhere. I've just left
it in vm_meter.c because that's where it's always bee
count=10
>...
>disklabel -Brw da5 auto
>disklabel: No space left on device
I think this can happen when there is an existing label on the
disk, but I forget the exact conditions. Try dd'ing a few k of
zeros on to the disk and run the disklabel again?
Ian
To Unsubscribe: send mail
In message <[EMAIL PROTECTED]>, Ian Dowse writes:
>In message <Pine.BSF.4.21.0107122138260.61694-10@beppo>, Matthew Jacob wri
>t
>es:
>>dd if=/dev/zero of=/dev/da5 bs=1024k count=10
>>...
>>disklabel -Brw da5 auto
>>disklabel: No space left on de
nto
kern_synch.c, so it would certainly make sense to initialise it
from sched_setup() then. This seems like a good idea to me; does
that sound OK?
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In message <[EMAIL PROTECTED]>, Bruce Ev
ans writes:
>On Tue, 17 Jul 2001, Ian Dowse wrote:
>> effect in the load calculation, but even for the shorter 5-minute
>> timescale, this will average out to typically no more than a few
>> percent (i.e the "5 minutes"
;t think it could solve the hangs,
but it should improve the chance of interruptible mounts accepting
^C while waiting, and (just added the other day) umount -f should
work while the server is down even if processes are hung.
Ian
Index: nfs.h
===
In message <[EMAIL PROTECTED]>, Matt Dillon writes:
> Ian, please don't do this. The whole point of having an uninterruptable
> mount is so the client can survive a server reboot or network failure.
> Doing this destroys uninterruptable semantics.
Firstly, I
/ -fstype ufs -type d -print0 | xargs ./dircheck.pl
That should show up any directories that would fail that dirhash
sanity check - there will probably just be one or two that resulted
from some old filesystem corruption.
Ian
#!/usr/local/bin/perl
while (defined($dir = shift)) {
unless (open
is
will check if there is still a problem.
However, I'd like to know if this is something that fsck should
detect and correct automatically. It is an odd case, because the
ffs filesystem code never creates directory entries like this, but
I think it will not object to them if it finds them. This
changes from RELENG_4 shortly
until the issue is resolved. The change was non-essential and quite
contained, so it's probably better than waiting for a fix.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ck yesterday, so if you have revision
1.3 of ufs_dirhash.c you won't see that panic again. I didn't
realise that fsck actually causes these directory entries, but just
the fact that it leaves them intact meant that the sanity check
was bad.
Ian
To Unsubscribe: send mail to [EMAIL PRO
ng down such bugs :-). The rpcbind client code in libc
keeps a cache of DNS lookups, but it is missing a strdup() when it
copies a string from the cache.
Investigating this has shown up a few bugs I introduced to rpc.umtall
in my last set of changes, so I'll fix those too.
Ian
To Unsubscr
code for 4 years. This was the only
remaining mention of it apart from its definition.
Reviewed by: jhb
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
m into a state that cannot be produced
by any combination of kernel filesystem operations. That introduces
quite some potential for obscure bugs that only occur after an fsck
run...
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
patch below should fix both these issues, and it makes it clearer
that DIRSIZ() is not used when d_ino == 0.
Any comments welcome. The patch is a bit larger than it needs to
be, but that directory compression code is so hard to understand
that I think
s for the bug report - see my other mail to -current for
further details, but the quick answer is that dirhash has a bug
that is triggered by the odd directory entries that fsck sometimes
leaves behind. This short patch should fix it:
Ian
Index: ufs_lookup.c
===
*. Something
>else is rather messed up here I'm afraid.
Note that the return address into kthread_suspend is kthread_suspend+0x0.
Since the call to exit1() in kthread_exit is the very last operation
in kthread_exit, you'd expect the return address on the stack to be
at the start of the next
00 Heap
Does anyone have any ideas?
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
; If that does not help please create a backtrace from the vbox coredump and
> send the vbox.log.
There is no coredump.
Answers to other questions:
The system is an intel atom N270.
Even though the processor does not support VT-x/AMD-V, nor was VB
compiled with that support, the virtual machine cl
they increase massively by several thousand, but only on 2
interfaces. The 1 minute average rate on those interfaces is 266/s
and 123/s.
Does anyone think this is related to the packet loss or are these
counters just a red herring? Is there anything that can be done
to reduce this count?
Ian
-
Pyun YongHyeon wrote:
> On Fri, Mar 05, 2010 at 01:20:57PM +0200, Ian FREISLICH wrote:
> > Hi
> >
> > I have a system that is experiencing mild to severe packet loss.
> > The interfaces are configured as follows:
> >
> > lagg0: bce0, bce1, bce2, bce3 lagpr
rst read, 8 split
transactions
cap 01[48] = powerspec 2 supports D0 D3 current D0
cap 03[50] = VPD
cap 05[58] = MSI supports 1 message, 64 bit enabled with 1 message
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://
ce is worse
on that chip than the bce(4) interface. It's also riddled with
vlan and other hardware offload bugs. I had good success in the
past with em(4), but it looks like igb is the PCI-e version.
Ian
--
Ian Freislich
___
freebsd-current@freebsd
Pyun YongHyeon wrote:
> On Fri, Mar 05, 2010 at 11:16:41PM +0200, Ian FREISLICH wrote:
> > Pyun YongHyeon wrote:
> > > Thanks for the info. Frankly, I have no idea how to explain the
> > > issue given that you have no heavy load.
> >
> > How many cores wo
642
dev.bce.1.com_no_buffers: 497
dev.bce.2.com_no_buffers: 6260612
dev.bce.3.com_no_buffers: 4871338
Interupt rate is down now, at about 3500 per second per interface.
Interestingly setting net.inet.ip.fastforwarding=0 reduces CPU
consumption from 25% to 9% a
Pyun YongHyeon wrote:
> On Mon, Mar 08, 2010 at 04:45:20PM +0200, Ian FREISLICH wrote:
> > Pyun YongHyeon wrote:
> > > On Fri, Mar 05, 2010 at 11:16:41PM +0200, Ian FREISLICH wrote:
> > > > Pyun YongHyeon wrote:
> > > > > Thanks for the inf
Pyun YongHyeon wrote:
> On Tue, Mar 09, 2010 at 03:31:55PM +0200, Ian FREISLICH wrote:
> > Can you explain the tunables please - I'm guessing it's these:
I think I asked the wrong question. What is a "Quick BD Chain"?
What relation should this number have to traffic
Pyun YongHyeon wrote:
> On Tue, Mar 09, 2010 at 11:55:30PM +0200, Ian FREISLICH wrote:
> > I set the RX as high as 512 in 64 quanta but it made little difference
> > to the interrupt rate. At times where we experience the packet
> > loss and com_no_buffers increases, the inte
estion on the switches we
use when UDP packets smaller than 400 bytes arrive within 40us of
eachother. But that still doesn't explain the counter increases
and high interrupt CPU usage, unless the switch was producing garbage
output in response.
Ian
--
Ian Freislich
ailable and
interested.
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
The hardware can support a
> > maximum of 64K BD's but that would be an unnecessarily large
> > amount of mbufs for an infrequent problem.
I think that depends on how you define infrequent. Our use case
is a largish core router. It's highly likely that we'll see this
again an
27;t the
cure for this particular situation, but may improve performance in
general.
It does sound like reworking the buffer will solve the problem.
Perhaps having a 2 recieve rings so that once one ring is available
for processing, the other ready filled and clear ring can be used
for recie
EBSD7 #Compatible with FreeBSD7
options COMPAT_FREEBSD32
Thanks for the advance notice that FreeBSD will be EoL before RELENG_32.
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-cu
ar the DNSSEC stuff is coming along, however ponderously.
KUTGW, Ian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
siba_bwn.ko
101 0xcb118000 2c000bwn_v4_lp_ucode.ko
112 0xcb144000 3000 firmware.ko
131 0xcb2e 32000if_bwn.ko
This NIC works great. You made my day. It even obeys the wireless
on-off switch on the front of my netbook.
I
't work first time on reboot. I need
to either '/etc/rc.d/netif restart' and if that panics the machine,
destroy wlan0 and then restart netif.
Then wlan0/bwn0 associates correctly with this device.
Ian
--
Ian Freislich
___
freebsd-curr
Ian FREISLICH wrote:
> > >Has anyone managed to make Virtualbox work on 9-Current? Since
> > >installing 3.1.2-OSE VMs, all brand new, abort on startup.
> > >
> > >The last part of the log seems pertinent:
> > >
> > >00:00:15.481 !!Assertion
tp", "/etc", 0 };
int i, sign, lat_flg, long_flg, ht_flg, mode, mask;
double f1, f2, f3;
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsu
Ollivier Robert wrote:
> According to Ian FREISLICH:
> > The oncore ntp driver worked fine in my Athlon64 machine running
> > FreeBSD-amd64. I've tried it on a VIA-C7 and a Pentium-M based
> > board with an onboard serial port.
>
> Can you open a bug on bugs.ntp
status: associated
ssid quasar channel 1 (2412 MHz 11g) bssid 00:30:4f:58:bf:94
country US authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit
txpower 30 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250
roam:rssi 7 roam:rate 5 protmode CTS wme
d be more general than the VI_DOINGINACT flag.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
subscribe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
# ATAPI floppy drives
device atapist # ATAPI tape drives
options ATA_STATIC_ID #Static device numbering
Generic Kernel seems to buildkernel fine.
Thanks in advance for any help.
--
Ian Watkinson
Systems Administrator
EHS Brann
To Unsubscr
# ATAPI floppy drives
device atapist # ATAPI tape drives
options ATA_STATIC_ID #Static device numbering
Generic Kernel seems to buildkernel fine.
Thanks in advance for any help.
--
Ian Watkinson
Systems Administrator
EHS Brann
To Unsubscr
On Tue, 2003-01-14 at 17:26, Ian Watkinson wrote:
> Have the config of the kernel files changed?
>
>
> If so is there a pointer as to what where, and how to convert old to
> new?
>
> Getting an error with a previously working one.
Bad form to follow my own posts, b
1 - 100 of 860 matches
Mail list logo
