Re: Intel Haswell support - Any updates?

2015-09-17 Thread Adam McDougall 
On Thu, Sep 17, 2015 at 12:43:59PM +0100, David Chisnall wrote:

  On 17 Sep 2015, at 11:31, Lundberg, Johannes 
 wrote:
  > 
  > Anyway, I wish the foundation would support the graphics team by sponsoring 
this development…
  
  The Foundation did fund a lot of this work, and likely will again.  The 
problem is not 
  willingness of the Foundation to fund it, nor availability of funds.

I was not aware of this and am happy to hear it!
  
  Long term, the real solution is to convince GPU vendors to put as much effort 
into 
  funding FreeBSD driver development as they do into funding Linux and Windows 
driver 
  development.  The Foundation has been reaching out in this direction,

Glad to hear this too.  It is more comforting to hear.

  but it’s far more compelling if people can document cases where lack of 
FreeBSD support 
  has cost a vendor sales.  If you’ve bought a system with an nVidia or AMD GPU 
(or, 
  ideally, if your company has bought a few thousand) because of lack of 
FreeBSD support
  from Intel, then let Intel know.
  
  David

In all seriousness, do you have a suggested contact for us?  I can't offer bulk 
sales 
avoidance but on a personal level I am clinging to a 4.5 year old laptop and 
would 
replace it tomorrow with another higher end model if I had any practical 
choices for 
FreeBSD graphics support.  Even nVidia is not a checkbox solution on laptops 
because as 
far as I understand it you still have to deal with Optimus which cannot simply 
be 
disabled as in the past.  I also have considerable stability problems with the 
nVidia 
driver on my desktops and I will be reporting it very soon after some 
debugging.  Thanks.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Broadwell Support FreeBSD 10.1

2015-03-23 Thread Adam McDougall 
On 03/22/2015 19:49, Glen Barber wrote:
 On Sun, Mar 22, 2015 at 04:32:06PM -0700, Marek Novotny wrote:
 New to this group, and new to FreeBSD via PC-BSD. Really like it so far.
 Sorry if this has been asked to death already. Levono has their new T450
 with the 5th gen intel Broadwell i5 processor. I bought it with the hopes of
 running PC-BSD latest version on it. It uses intel 5500 graphics as well.
 Any potential issues using this??

 
 You won't be able to use accelerated graphics.
 
 I have the T540p which has the i7-4800MQ, and am quite happy with
 running FreeBSD CURRENT on it.  I don't care about accelerated graphics
 too much, though.
 
 One nit with the laptop is I needed to use an external USB flash drive
 to store /boot on an MBR partition, because my hard drives are
 GPT-partitioned using ZFS on '/' on GELI-encrypted providers.
 Otherwise, I have noticed that using the /boot on the GPT disk enforces
 low resolution graphics (640x480 IIRC).
 
 By using a USB flash drive for /boot, I can get 1920x1080 resolution
 (one of the many reasons for choosing this laptop).
 
 (I've been meaning to put this into the FreeBSD Wiki, but EBUSY.)
 
 Glen
 

Glen, in the past I briefly tested the uefi bootloader on a Lenovo T440s
including with scfb and I believe the default resolution would raise to
native if I also disabled CSM mode in the bios.  This affected the
console mode as well as scfb which both inherit the framebuffer from the
uefi GOP as I understand it.  Have you tried that?
You should be able to demonstrate it while booted from a uefi boot
stick, no permanent system changes necessary.

I've also been looking forward to see if this trick works with uefi
since xf86-video-scfb performance was perfectly usable on a uefi booted
mac but not the lenovo:
https://forums.freebsd.org/threads/xorg-vesa-driver-massive-speedup-using-mtrr-write-combine.46723/
___
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

Re: default pager (csh)

2015-02-18 Thread Adam McDougall 
The PAGER was less for about half a year and reverted.  Please see:

https://svnweb.freebsd.org/base?view=revisionrevision=242643
___
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

Re: How do I get someone to look at / comment on

2014-11-13 Thread Adam McDougall 
On 11/13/2014 21:07, Larry Rosenman wrote:
 this bug?
 
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194770
 
 It's to stop a constant stream of noise on my 11-CURRENT box.
 
 
 

Doesn't r273962 take care of this?
___
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

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

2014-10-23 Thread Adam McDougall 
On 10/23/2014 15:03, Konstantin Belousov wrote:
 Use https://www.kib.kiev.ua/kib/drm/i915.6.patch.  I already have one
 private report of the patch worked from person who got the same panic
 in iicbb.

Yes, this one works (does not panic) and X works!  I kldloaded it after
boot as I usually do.  For the 3 minutes my computer has been up so far,
it seems the same as 10-stable.  Thanks.

___
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

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

2014-10-22 Thread Adam McDougall 
On 10/22/2014 08:26, Konstantin Belousov wrote:
 On Wed, Oct 08, 2014 at 03:12:08PM -0400, Adam McDougall wrote:
 On 10/08/2014 13:05, Konstantin Belousov wrote:
 There are more occurences of the bug I fixed once in patch version 2.
 Also, since pmap changes were committed in modified form, please try
 the updated patch at https://www.kib.kiev.ua/kib/drm/i915.3.patch .


 No apparent change:
 http://www.egr.msu.edu/~mcdouga9/i915-patch3-1.txt
 cite (kgdb) p *(struct drm_i915_private *)(dev_private)
 cite No symbol dev_private in current context.
 
 This is p *(struct drm_i915_private *)(dev-dev_private)

http://www.egr.msu.edu/~mcdouga9/dev_private.txt

 
 I regenerated patch after recent merges and changes in KPI on HEAD.
 https://www.kib.kiev.ua/kib/drm/i915.4.patch
 
 Please apply it, I think the issue should be there still.  Then apply
 the following debugging patch, and set
   kenv drm.debug=0x3
 before loading i915kms.ko.  I want to see the same debugging information,
 and dmesg from the moment of loading the driver.


 In fact, try
 https://www.kib.kiev.ua/kib/drm/i915.5.patch

http://www.egr.msu.edu/~mcdouga9/dconschat.txt
___
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

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

2014-10-08 Thread Adam McDougall 
On 10/08/2014 13:05, Konstantin Belousov wrote:
 On Tue, Oct 07, 2014 at 04:04:54PM -0400, Adam McDougall wrote:
 On 10/07/2014 14:01, Konstantin Belousov wrote:
 On Tue, Oct 07, 2014 at 07:44:19PM +0300, Konstantin Belousov wrote:
 From the same frame, please do
 p *(struct drm_i915_private *)(dev-private)
 p *(struct drm_i915_private *)(dev-dev_private)
 

 I probably figured out what is wrong, but it is still interesting to
 see this piece of data.

 For everybody who has the issue with blank screen or panic after
 the patch:
 1. please try the updated patch,
 https://www.kib.kiev.ua/kib/drm/i915.2.patch
 2. if you use kldload i915kms to test the patch and get the blank
screen, verify do you get panic or just a black screen.  It is
expected for sc, not so for vt.  For vt, if you do get blank screen
and not a panic, do not load i915kms manually and run the X server.
I am interested if running X server does show proper output.


 Backtrace seems the same, I repeated the prior commands:
 http://www.egr.msu.edu/~mcdouga9/i915-patch2-1.txt
 
 There are more occurences of the bug I fixed once in patch version 2.
 Also, since pmap changes were committed in modified form, please try
 the updated patch at https://www.kib.kiev.ua/kib/drm/i915.3.patch .
 

No apparent change:
http://www.egr.msu.edu/~mcdouga9/i915-patch3-1.txt

I made a log of the source operations and compile to be certain I was
using the right patch properly:
http://www.egr.msu.edu/~mcdouga9/20141008-compile.txt

Are any of these an issue in the patch?  Seem unrelated but hopefully
harmless:
diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c
diff --git a/sys/fs/tmpfs/tmpfs_subr.c b/sys/fs/tmpfs/tmpfs_subr.c
diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c
diff --git a/sys/kern/uipc_shm.c b/sys/kern/uipc_shm.c
diff --git a/sys/kern/uipc_syscalls.c b/sys/kern/uipc_syscalls.c
diff --git a/sys/vm/default_pager.c b/sys/vm/default_pager.c
diff --git a/sys/vm/device_pager.c b/sys/vm/device_pager.c
diff --git a/sys/vm/phys_pager.c b/sys/vm/phys_pager.c
diff --git a/sys/vm/sg_pager.c b/sys/vm/sg_pager.c
diff --git a/sys/vm/swap_pager.c b/sys/vm/swap_pager.c
diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c
diff --git a/sys/vm/vm_glue.c b/sys/vm/vm_glue.c
diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c
diff --git a/sys/vm/vm_pager.c b/sys/vm/vm_pager.c
diff --git a/sys/vm/vm_pager.h b/sys/vm/vm_pager.h
diff --git a/sys/vm/vnode_pager.c b/sys/vm/vnode_pager.c

Thanks.
___
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

Re: i915 driver update testing

2014-10-07 Thread Adam McDougall 


On 10/7/2014 12:20 AM, Konstantin Belousov wrote:

On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote:

On 10/05/2014 13:00, Konstantin Belousov wrote:

On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote:

(kgdb) #0  doadump (textdump=1) at pcpu.h:219
#1  0x80661efd in kern_reboot (howto=260)
 at /usr/src/sys/kern/kern_shutdown.c:447
#2  0x80662450 in panic (fmt=value optimized out)
 at /usr/src/sys/kern/kern_shutdown.c:746
#3  0x808fe52f in trap_fatal (frame=value optimized out,
 eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866
#4  0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0,
 usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677
#5  0x808fde9e in trap (frame=0xfe01fe0b21b0)
 at /usr/src/sys/amd64/amd64/trap.c:426
#6  0x808e00a2 in calltrap ()
 at /usr/src/sys/amd64/amd64/exception.S:231
#7  0x8166808e in i915_write32 (dev_priv=0xf800031f1c00,
 reg=20736, val=0)
 at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992

In kgdb, from this frame, please do
p *dev_priv
p *(dev_priv-dev)
p *(dev_priv-info)

http://www.egr.msu.edu/~mcdouga9/i915-1b.txt

Sorry for the delay.  I duplicated this on a spare computer of the same
model so I can test easier.

Great, thank you.  Please also do, from the frame 12,
p *dev


http://www.egr.msu.edu/~mcdouga9/i915-2.txt
___
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

Re: i915 driver update testing

2014-10-07 Thread Adam McDougall 
On 10/07/2014 12:44, Konstantin Belousov wrote:
 On Tue, Oct 07, 2014 at 09:00:56AM -0400, Adam McDougall wrote:

 On 10/7/2014 12:20 AM, Konstantin Belousov wrote:
 On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote:
 On 10/05/2014 13:00, Konstantin Belousov wrote:
 On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote:
 (kgdb) #0  doadump (textdump=1) at pcpu.h:219
 #1  0x80661efd in kern_reboot (howto=260)
  at /usr/src/sys/kern/kern_shutdown.c:447
 #2  0x80662450 in panic (fmt=value optimized out)
  at /usr/src/sys/kern/kern_shutdown.c:746
 #3  0x808fe52f in trap_fatal (frame=value optimized out,
  eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866
 #4  0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0,
  usermode=value optimized out) at 
 /usr/src/sys/amd64/amd64/trap.c:677
 #5  0x808fde9e in trap (frame=0xfe01fe0b21b0)
  at /usr/src/sys/amd64/amd64/trap.c:426
 #6  0x808e00a2 in calltrap ()
  at /usr/src/sys/amd64/amd64/exception.S:231
 #7  0x8166808e in i915_write32 (dev_priv=0xf800031f1c00,
  reg=20736, val=0)
  at
 /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992
 In kgdb, from this frame, please do
 p *dev_priv
 p *(dev_priv-dev)
 p *(dev_priv-info)
 http://www.egr.msu.edu/~mcdouga9/i915-1b.txt

 Sorry for the delay.  I duplicated this on a spare computer of the same
 model so I can test easier.
 Great, thank you.  Please also do, from the frame 12,
 p *dev

 http://www.egr.msu.edu/~mcdouga9/i915-2.txt
 
 From the same frame, please do
 p *(struct drm_i915_private *)(dev-private)
 

(kgdb) f 12
#12 0x81681bd7 in intel_modeset_init (dev=0xf80003bd9000)
at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:6603
6603found = intel_sdvo_init(dev, PCH_SDVOB, true);
Current language:  auto; currently minimal
(kgdb) p *(struct drm_i915_private *)(dev-private)
There is no member named private.

___
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

Re: i915 driver update testing

2014-10-07 Thread Adam McDougall 
On 10/07/2014 14:24, Konstantin Belousov wrote:
 On Tue, Oct 07, 2014 at 02:08:06PM -0400, Adam McDougall wrote:
 On 10/07/2014 12:44, Konstantin Belousov wrote:
 On Tue, Oct 07, 2014 at 09:00:56AM -0400, Adam McDougall wrote:

 On 10/7/2014 12:20 AM, Konstantin Belousov wrote:
 On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote:
 On 10/05/2014 13:00, Konstantin Belousov wrote:
 On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote:
 (kgdb) #0  doadump (textdump=1) at pcpu.h:219
 #1  0x80661efd in kern_reboot (howto=260)
  at /usr/src/sys/kern/kern_shutdown.c:447
 #2  0x80662450 in panic (fmt=value optimized out)
  at /usr/src/sys/kern/kern_shutdown.c:746
 #3  0x808fe52f in trap_fatal (frame=value optimized out,
  eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866
 #4  0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0,
  usermode=value optimized out) at 
 /usr/src/sys/amd64/amd64/trap.c:677
 #5  0x808fde9e in trap (frame=0xfe01fe0b21b0)
  at /usr/src/sys/amd64/amd64/trap.c:426
 #6  0x808e00a2 in calltrap ()
  at /usr/src/sys/amd64/amd64/exception.S:231
 #7  0x8166808e in i915_write32 (dev_priv=0xf800031f1c00,
  reg=20736, val=0)
  at
 /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992
 In kgdb, from this frame, please do
 p *dev_priv
 p *(dev_priv-dev)
 p *(dev_priv-info)
 http://www.egr.msu.edu/~mcdouga9/i915-1b.txt

 Sorry for the delay.  I duplicated this on a spare computer of the same
 model so I can test easier.
 Great, thank you.  Please also do, from the frame 12,
 p *dev

 http://www.egr.msu.edu/~mcdouga9/i915-2.txt

 From the same frame, please do
 p *(struct drm_i915_private *)(dev-private)


 (kgdb) f 12
 #12 0x81681bd7 in intel_modeset_init (dev=0xf80003bd9000)
 at
 /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:6603
 6603 found = intel_sdvo_init(dev, PCH_SDVOB, true);
 Current language:  auto; currently minimal
 (kgdb) p *(struct drm_i915_private *)(dev-private)
 There is no member named private.
 It is dev_private, typo.
 
I actually took a guess at that too, but this didn't look helpful:
(kgdb) p *(struct drm_i915_private *)(dev_private)
No symbol dev_private in current context.

___
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

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

2014-10-07 Thread Adam McDougall 
On 10/07/2014 14:01, Konstantin Belousov wrote:
 On Tue, Oct 07, 2014 at 07:44:19PM +0300, Konstantin Belousov wrote:
 From the same frame, please do
 p *(struct drm_i915_private *)(dev-private)
 
 I probably figured out what is wrong, but it is still interesting to
 see this piece of data.
 
 For everybody who has the issue with blank screen or panic after
 the patch:
 1. please try the updated patch,
   https://www.kib.kiev.ua/kib/drm/i915.2.patch
 2. if you use kldload i915kms to test the patch and get the blank
screen, verify do you get panic or just a black screen.  It is
expected for sc, not so for vt.  For vt, if you do get blank screen
and not a panic, do not load i915kms manually and run the X server.
I am interested if running X server does show proper output.
 

Backtrace seems the same, I repeated the prior commands:
http://www.egr.msu.edu/~mcdouga9/i915-patch2-1.txt
___
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

Re: i915 driver update testing

2014-10-06 Thread Adam McDougall 
On 10/05/2014 13:00, Konstantin Belousov wrote:
 On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote:
 (kgdb) #0  doadump (textdump=1) at pcpu.h:219
 #1  0x80661efd in kern_reboot (howto=260)
 at /usr/src/sys/kern/kern_shutdown.c:447
 #2  0x80662450 in panic (fmt=value optimized out)
 at /usr/src/sys/kern/kern_shutdown.c:746
 #3  0x808fe52f in trap_fatal (frame=value optimized out,
 eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866
 #4  0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0,
 usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677
 #5  0x808fde9e in trap (frame=0xfe01fe0b21b0)
 at /usr/src/sys/amd64/amd64/trap.c:426
 #6  0x808e00a2 in calltrap ()
 at /usr/src/sys/amd64/amd64/exception.S:231
 #7  0x8166808e in i915_write32 (dev_priv=0xf800031f1c00,
 reg=20736, val=0)
 at
 /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992
 In kgdb, from this frame, please do
 p *dev_priv
 p *(dev_priv-dev)
 p *(dev_priv-info)

http://www.egr.msu.edu/~mcdouga9/i915-1b.txt

Sorry for the delay.  I duplicated this on a spare computer of the same
model so I can test easier.
___
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

Re: i915 driver update testing

2014-10-05 Thread Adam McDougall 
On 10/03/2014 13:02, Konstantin Belousov wrote:
 Please find at the
 https://kib.kiev.ua/kib/drm/i915.1.patch
 a patch which provides some updates to the i915 driver. At large, this
 is import of the batch of Linux commits, and as such, it is interesting
 mostly as attempt to restart the race to get us more up to date Linux code
 imported. It might provide some bug fixes, most likely for IvyBridge.
 Interesting from the development PoV is the update of the GEM i/o ioctl
 code path to mimic Linux code structure.
 
 I am asking _only_ for reports of regressions with the patch applied,
 comparing with the code which is currently in HEAD. I will not debug
 any existing bugs, my goal right now is to commit this update, which is
 needed for further work. I.e., only when you get an issue with the patch
 applied, but cannot reproduce the problem without the patch, please
 prepare a bug report.
 
 FYI, the driver will attach to haswell gfx, but I am not interested in
 reports about this (see above paragraph). On my test box, which is Core
 i7 4770S, the mode-setting and front-buffer rendering works, but Mesa
 immediately cause renderer to bug out.
 
 Work was sponsored by The FreeBSD Foundation, both by time and hardware,
 and Intel provided access to the documentation.

I receive a Fatal trap 12: page fault while in kernel mode.

I was previously loading i915kms in rc.conf on 10-stable where the
screen would blank out for a short time then switch to native
resolution.  Last night I compiled a fresh kernel from -head so I could
test recent ZFS code (userland still from 10).  It behaved like 10.
After applying i915.1.patch, the screen blanks in the same place then
invisibly panics with a page fault.  I hastily replaced the broken
kernel so I didn't accidentally boot it, but I would be happy to compile
a new one (FYI since info below may not match a new compile).  Please
tell me if or how you would like me to help.  Thanks.

FreeBSD colfax 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r272549M: Sun Oct  5
10:32:28 EDT 2014 mcdouga9@colfax:/usr/obj/usr/src/sys/AMD64-11  amd64

panic: page fault

CPU: Intel(R) Core(TM) i5 CPU 660  @ 3.33GHz (3325.07-MHz
K8-class CPU)

[11] Loading kernel modules:
[11] info: [drm] Initialized drm 1.1.0 20060810
[11] drmn0: Intel IronLake on vgapci0
[11] info: [drm] MSI enabled 1 message(s)
[11] info: [drm] AGP at 0xd000 256MB
[11] iicbus0: Philips I2C bus on iicbb0 addr 0xff
[11] iic0: I2C generic I/O on iicbus0
[11] iic1: I2C generic I/O on iicbus1
[11] iicbus2: Philips I2C bus on iicbb1 addr 0x0
[11] iic2: I2C generic I/O on iicbus2
[11] iic3: I2C generic I/O on iicbus3
[11] iicbus4: Philips I2C bus on iicbb2 addr 0x0
[11] iic4: I2C generic I/O on iicbus4
[11] iic5: I2C generic I/O on iicbus5
[11] iicbus6: Philips I2C bus on iicbb3 addr 0x0
[11] iic6: I2C generic I/O on iicbus6
[11] iic7: I2C generic I/O on iicbus7
[11] iicbus8: Philips I2C bus on iicbb4 addr 0x0
[11] iic8: I2C generic I/O on iicbus8
[11] iic9: I2C generic I/O on iicbus9
[11] iicbus10: Philips I2C bus on iicbb5 addr 0x0
[11] iic10: I2C generic I/O on iicbus10
[11] iic11: I2C generic I/O on iicbus11
[11] info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[11] info: [drm] Driver supports precise vblank timestamp query.
[11]
[11]
[11] Fatal trap 12: page fault while in kernel mode
[11] cpuid = 0; apic id = 00
[11] fault virtual address  = 0x0
[11] fault code = supervisor read data, page not present
[11] instruction pointer= 0x20:0x8166808e
[11] stack pointer  = 0x28:0xfe01fe0b2260
[11] frame pointer  = 0x28:0xfe01fe0b22a0
[11] code segment   = base 0x0, limit 0xf, type 0x1b
[11]= DPL 0, pres 1, long 1, def32 0, gran 1
[11] processor eflags   = interrupt enabled, resume, IOPL = 0
[11] current process= 124 (kldload)
[11] trap number= 12
[11] panic: page fault
[11] cpuid = 0
[11] Uptime: 11s
[11] Dumping 252 out of 3874
MB:..7%..13%..26%..32%..45%..51%..64%..76%..83%..95%

Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
Loaded symbols for /boot/kernel/linprocfs.ko.symbols
Reading symbols from /boot/kernel/linux.ko.symbols...done.
Loaded symbols for /boot/kernel/linux.ko.symbols
Reading symbols from /boot/kernel/i915kms.ko.symbols...done.
Loaded symbols for /boot/kernel/i915kms.ko.symbols
Reading symbols from /boot/kernel/drm2.ko.symbols...done.
Loaded symbols for /boot/kernel/drm2.ko.symbols
Reading symbols from /boot/kernel/iicbus.ko.symbols...done.
Loaded symbols for /boot/kernel/iicbus.ko.symbols
Reading symbols from /boot/kernel/iic.ko.symbols...done.
Loaded symbols for /boot/kernel/iic.ko.symbols
Reading symbols from

Re: UEFI display frozen on Retina MacBook Pro

2014-09-10 Thread Adam McDougall 
On 09/10/2014 02:08, Rui Paulo wrote:
 On Sep 8, 2014, at 06:21, Anders Bolt Evensen andersb...@icloud.com wrote:

 To see the FreeBSD (U)EFI boot loader on the Mac, you need to install an EFI 
 shell like rEFIt on either your hard drive or a HFS formatted memory stick:
 
 I think this is just a problem with our EFI implementation, though.  We 
 should be able to switch to text mode like rEFIt does.
 
 --
 Rui Paulo
 
 
 
 ___
 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
 

Please see
http://www.mail-archive.com/freebsd-current@freebsd.org/msg155044.html
for a patch.
___
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

Re: UEFI display frozen on Retina MacBook Pro

2014-09-10 Thread Adam McDougall 
On 09/10/2014 11:09, John Baldwin wrote:
 On Wednesday, September 10, 2014 08:03:47 AM Adrian Chadd wrote:
 Would you or someone else please file a PR with that patch? That way
 it doesn't get lost.

 https://bugs.freebsd.org/submit/

 Thanks!
 
 Please assign it to emaste@ as he had volunteered to commit the patch 
 previously.
 
 Also, Ed, regarding the earlier thread about this, I think instead of hacking 
 up the EFI headers, we should use the stock headers and adjust our code to 
 use 
 whatever naming contentions (CamelCase, etc.) those use.  This is what we do 
 with ACPICA for example.
 

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193524
___
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

Re: nscd not caching

2014-08-17 Thread Adam McDougall 
On 08/17/2014 09:09, Eggert, Lars wrote:
 Nobody using nscd? Really?
 

I would test for you, but we retired our NIS infrastructure at least a
year ago.  I did have it working on a test client at some point, but I
didn't push it into production because I found a couple issues (below).

We were using +: type entries in the local password and group
tables and I believe we used an unmodified /etc/nsswitch.conf (excluding
cache lines while testing nscd):

group: compat
group_compat: nis
hosts: files dns
networks: files
passwd: compat
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files

The two main problems I recall were nscd making java crash, and nscd
holding on to negative cache lookups too long, causing failures while
installing ports that depend on adding users/groups for a following file
permission change.  I can't remember if the latter issue was fixed at
some point.  I also can't remember if I was receiving perfectly accurate
results from the cache either.

At our site, we never had enough load to outright require nscd on
FreeBSD, although there were some areas where caching had a usability
benefit.  top was slow to open since it would load the whole passwd
table first, but top -u was a workaround.  Our Samba servers allowed
users to connect a few seconds quicker if it didn't have to pull down
the entire group table to check group membership of the connecting user.
 As a workaround until we retired NIS, I wrote a hack of a script to
merge NIS groups into my local /etc/group files periodically from cron.
 Aside from bugs in my script, that worked well.

I dabbled with nscd a bit after we switched from NIS to LDAP.  I think I
recall lookups being slightly slower WITH the cache, plus I would get
some duplicated group entries returned on all but the first getent
group.  The short version is we in no way seem to benefit or require a
cache of LDAP with our site size, so I'm just not using nscd.  I didn't
make bug reports for these issues, I had to prioritize towards more
pressing issues.  I'm trying to do better about reporting bugs.


___
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

Re: uefi boot on Apple Mac

2014-07-12 Thread Adam McDougall 
I could boot from USB but the console stops after printing the
resolution.  I tried on a macbookpro of unknown age (not brand new, not
very old) and a newer Air.  I could tell by the way my USB key blinked
that it actually finished booting and went to the installer, and would
shut down properly when I hit the power button.  I modified my USB key
to enable a vt100 serial console on /dev/cuaU0 in /etc/ttys and used a
USB serial console where I could login and run bsdinstall if I wanted.
I was able to finish a bootable uefi install to a second USB key but
the console on all of these installs stops after printing the
resolution.  It was not clear to me if it that means it just doesn't
support the screen or what.  X claimed it could not find a console.

On 07/12/2014 10:24, Huang Wen Hui wrote:
 As loader.efi and kernel not change at all from USB to CD, I am confuse why
 you can boot from CD.
 Anyway, I try to boot from CD as you suggest, but I got the same result as
 before:(
 
 
 2014-07-12 18:09 GMT+08:00 Anders Bolt-Evensen andersb...@icloud.com:
 
 I also got a message like that when I booted from a USB stick on a
 MacBookPro8,3 (17 inch, late 2011).

 I fixed it by creating a custom ISO image and burned that onto a DVD using
 an external DVD drive.
 The UEFI installer boots fine from this external DVD drive.

 Here is how I did it:

 Genereste an ISO with the FreeBSD-CURRENT kernel, mount the ISO and copy
 all files from the root directory in the ISO and unmount
  cd /usr/src/release
  sh ./generate-release.sh # You may have to run “make buildworld” and
 be connected to the internet to install required ports.
  mount -t cd9660 /scratch/R/release/FreeBSD-something-disc1.iso /mnt
  mkdir freebsd_generic_installer
 #Files copied to the directory in the next command will be copied to a
 new ISO in step 3
  cp -R /mnt/ freebsd_generic_installer/
  umount /mnt
 2. Create a FAT filesystem image and place the loader in it in the default
 path that UEFI will look for (the following steps are copied from
 https://wiki.freebsd.org/UEFI#CD.2FDVD_Boot_under_UEFI):
  dd if=/dev/zero of=efiboot.img bs=4k count=100
  mdconfig -a -t vnode -f efiboot.img
  newfs_msdos -F 12 -m 0xf8 /dev/md0
  mount -t msdosfs /dev/md0 /mnt
  mkdir -p /mnt/efi/boot
  cp loader.efi /mnt/efi/boot/bootx64.efi
  umount /mnt
  mdconfig -d -u 0

 3. Create the custom ISO image. Please make sure that the entry in
 freebsd_generic_installer/etc/fstab matches the label you choose in the
 command below.
  makefs -t cd9660 -o bootimage='i386;efiboot.img' -o no-emul-boot -o
 rockridge -o label=“FREEBSD_UEFI_INSTALL -o publisher=test uefi-test.iso
 freebsd_generic_installer/

 To get the example in the command above to work, please make sure that the
 entry in freebsd_generic_installer/etc/fstab reads
 /dev/iso9660/FREEBSD_UEFI_INSTALL/cd9660ro0 0

 4. Burn the image to DVD, reboot your system and choose “EFI Boot”. Note
 that unless you are using a EFI console like rEFIt or rEFInd, you may have
 to kind of wait a couple of minutes while the kernel is loading before
 anything appears on the screen.



 On 04/07/14 16:34, Huang Wen Hui wrote:

 Hi,
 On my MacbookPro11,3, I got this error message:

 http://sw.gddsn.org.cn/freebsd/uefi.jpg

 cheers,

 Huang WenHui

 2014-07-04 22:13 GMT+08:00 Ed Maste ema...@freebsd.org:

  On 24 May 2014 19:39, Rafael Espíndola rafael.espind...@gmail.com
 wrote:

 Yes, I got that in the mac laptops I tried, it worked on a Mac Pro. It
 might be the frame buffer corruption that Ed Maste was mentioning.

 I purchased a new MacBook Air yesterday (model identifier
 MacBookAir6,2).  UEFI boot and vt(4) worked correctly.  (My image
 included Rafael's patch; I haven't tried a boot without.)

 I also committed a change to display the framebuffer parameters
 (address, dimensions, etc.) on boot, in order to help identify the
 source of this issue.  If you have a moment can you build a new USB
 stick image and give it a try?

 -Ed

  ___
 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
 



 ___
 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
 

___
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

Re: diskid documentation

2014-06-01 Thread Adam McDougall 
On 06/01/2014 10:17, Sean Bruno wrote:
 On Sun, 2014-06-01 at 09:41 -0400, Michael W. Lucas wrote:
 Hi,

 I'm trying to track down the documentation for the /dev/diskid/blah
 device nodes. Is there a man page?

 It appears that this is a current-only thing, so I'm asking here? (At
 least, none of my 9.x or 10.x machines have /dev/diskid.)

 Thanks,
 ==ml



 
 
 I'm afraid not.  In this case sys/geom/label/g_label_disk_ident.c *is*
 the documentation.
 
 sean
 
 bcc current@
 cc  geom@
 

Also, I believe it is only in 10.0-RELEASE and higher.  Even if your
kernel supports it, /dev/diskid will not exist if no hardware is found
with supported strings (tested in a VM just now).
___
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

Should we make WITHOUT_LIB32=yes the default for 11-RELEASE?

2014-05-05 Thread Adam McDougall 
On most amd64 systems I run, I usually set WITHOUT_LIB32=yes in /etc/src.conf
because I don't need them.  This weekend I did a stock install on an older
AMD64 Core 2 Duo minipc and a buildworld of 10-STABLE took almost two hours 
with LIB32 and CLANG since much of it gets compiled twice.

Is it time to deprecate LIB32 in -current for 11-RELEASE?  I realize some
ports may need it, but I hope that need is waning and we are just spending
a lot of compile time by default for little gain.  We could save a lot of
compile time for a lot of users, and they could still opt-in if needed.
Putting it up for discussion, not insisting it should be done.  Thanks.
___
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

Re: What on earth is all this %20 crap at the end of the GUID? (newfs?)

2014-04-29 Thread Adam McDougall 
On 04/29/2014 19:51, Sean Bruno wrote:
 Created a simple partition:
 
  root@:~ # gpart create -s gpt da11
 da11 created
 root@:~ # gpart add -t freebsd-ufs da11
 da11p1 added
 root@:~ # gpart show da11
 =40  7814037088  da11  GPT  (3.6T)
   40  7814037088 1  freebsd-ufs  (3.6T)
 
 root@:~ # 
 
 Then run a newfs and reboot the system.  Upon reboot this is what I get?
 
 =40  7814037088  da11  GPT  (3.6T)
   40  7814037088 1  freebsd-ufs  (3.6T)
 =40  7814037088  diskid/DISK-Z1Z0DQ73%20%20%20%20%20%20%20%20%
 20%20%20%20  GPT  (3.6T)
   40  7814037088
 1  freebsd-ufs  (3.6T)
 
 
 What is going on here?
 
 sean
 

I'm guessing it is picking up spaces from a physical ID on your disk
from /sys/geom/label/g_label_disk_ident.c

kern.geom.label.disk_ident.enable=0 in /boot/loader.conf will ignore
that class.  It was added in 10 and only shows up with certain devices.
___
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

Re: Buying recommendation for silent router/fileserver

2013-10-07 Thread Adam McDougall 

Finally got around to it, kern/182818. Thanks for the encouragement.

On 10/12/12 11:14, Adam McDougall wrote:

I did not, but I put it on my list to try to accomplish.

On 10/11/12 13:41, Adrian Chadd wrote:

Did you ever file a PR for the slow SATA behaviour?



Adrian


On 11 October 2012 09:52, Adam McDougall mcdou...@egr.msu.edu wrote:


Be wary of the Soekris net6501, I bought three of the 1.6Ghz net6501-70
model which has an Atom E-680 cpu (E series) and it compiles more 
than twice
as slow as a 1.6Ghz Atom N270 in an older netbook.  Someone else 
running

Linux reported similar CPU slowness.  As far as practical network
throughput, I could only get 100Mbit/sec with a simple HTTP download 
of a

file full of zeros, and OpenVPN could only push about 25Mbit/sec.  As a
practical example of the CPU slowness, it takes about 1.5 minutes to 
compile
pkg on the N270 netbook and 5 minutes on the 6501 (around 4.5 if I 
use -j2).

A kernel compile took an hour. Unfortunately I had no idea this CPU
(possibly implementation?) was so slow before I purchased it, and I 
could
scarcely find evidence of it on google after hours of searching when 
I had

already discovered the issue.  I was hoping to find some comparative
benchmarks between various Atom series but manufacturers generally 
don't do

that.

Additionally, the total AHCI SATA write speed on the net6501 (in BSD 
only?)
has a strange 20MB/sec limitation but reads can go over 100MB/sec.  
If I

write to one disk I get 20MB/sec, if I write to both SATA disks I get
10MB/sec each.  Write is equally slow on a SSD.  Both someone running
OpenBSD and I running FreeBSD reported the same symptoms to the 
soekris-tech
mailing list and received no useful replies towards getting that 
problem
solved.  I tested the write speed briefly with Linux and it did not 
appear
to have the 20MB/sec limitation.  I did confirm it was using 
MSI(-X?) with
boot -v.  I think this hardware would need to fall into Alexander 
Motin's
hands to get anywhere with debugging the SATA speed issue. Since it 
seems
fine in Linux, maybe some day it can be fixed in BSD but I have no 
clue how
that limitation could happen.  The disks I tested with are fine in 
normal

computers.

___
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




___
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

Re: Panic on head (r255759) [_callout_stop_safe()- panic: Lock lle not exclusively locked @ /usr/src/sys/kern/kern_rwlock.c:140]

2013-09-21 Thread Adam McDougall 

On 09/21/13 09:41, Davide Italiano wrote:

On Sat, Sep 21, 2013 at 2:51 PM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:

On Sat, 21 Sep 2013 07:08:25 -0500
Bryan Drewery bdrew...@freebsd.org wrote:


On 9/21/2013 7:06 AM, Bjoern A. Zeeb wrote:

On Sat, 21 Sep 2013, Bryan Drewery wrote:


Unread portion of the kernel message buffer:
panic: Lock lle not exclusively locked @
/usr/src/sys/kern/kern_rwlock.c:140

cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe118aeef820
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe118aeef8d0
vpanic() at vpanic+0x126/frame 0xfe118aeef910
panic() at panic+0x43/frame 0xfe118aeef970
__rw_assert() at __rw_assert+0xa3/frame 0xfe118aeef980
_callout_stop_safe() at _callout_stop_safe+0x54/frame
0xfe118aeef9f0 arptimer() at arptimer+0x14e/frame
0xfe118aeefa30 softclock_call_cc() at
softclock_call_cc+0x188/frame 0xfe118aeefb10 softclock() at
softclock+0x47/frame 0xfe118aeefb30
intr_event_execute_handlers() at
intr_event_execute_handlers+0x93/frame 0xfe118aeefb70
ithread_loop() at ithread_loop+0xa6/frame 0xfe118aeefbb0
fork_exit() at fork_exit+0x84/frame 0xfe118aeefbf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe118aeefbf0
--- trap 0, rip = 0, rsp = 0xfe118aeefcb0, rbp = 0 ---


+1 from me;  I  guess introduced somwhere between 255569 and 255758,
as these are my edges of kernel.old and kernel.


r255726 was stable for me. r255759 is not.

r255755 converted ipfilter to callout, but I am unsure if that is the
problem.


r255729 is also stable for me - I'm with r255729 again, since r255757
crashed.

Let me know if this fixes the problem for you:
http://people.freebsd.org/~davide/review/lc_calloutfix.diff

Thanks,


Worked for me so far. I generally couldn't stay up more than 30 minutes
before the patch and now my uptime is 90 minutes. Thanks!
___
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

Re: Panic on head (r255759) [_callout_stop_safe()- panic: Lock lle not exclusively locked @ /usr/src/sys/kern/kern_rwlock.c:140]

2013-09-21 Thread Adam McDougall 

On 09/21/13 12:34, Davide Italiano wrote:

On Sat, Sep 21, 2013 at 9:31 AM, Bryan Drewery bdrew...@freebsd.org wrote:

On 9/21/2013 11:18 AM, Adam McDougall wrote:

On 09/21/13 09:41, Davide Italiano wrote:

On Sat, Sep 21, 2013 at 2:51 PM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:

On Sat, 21 Sep 2013 07:08:25 -0500
Bryan Drewery bdrew...@freebsd.org wrote:


On 9/21/2013 7:06 AM, Bjoern A. Zeeb wrote:

On Sat, 21 Sep 2013, Bryan Drewery wrote:


Unread portion of the kernel message buffer:
panic: Lock lle not exclusively locked @
/usr/src/sys/kern/kern_rwlock.c:140

cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe118aeef820
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe118aeef8d0
vpanic() at vpanic+0x126/frame 0xfe118aeef910
panic() at panic+0x43/frame 0xfe118aeef970
__rw_assert() at __rw_assert+0xa3/frame 0xfe118aeef980
_callout_stop_safe() at _callout_stop_safe+0x54/frame
0xfe118aeef9f0 arptimer() at arptimer+0x14e/frame
0xfe118aeefa30 softclock_call_cc() at
softclock_call_cc+0x188/frame 0xfe118aeefb10 softclock() at
softclock+0x47/frame 0xfe118aeefb30
intr_event_execute_handlers() at
intr_event_execute_handlers+0x93/frame 0xfe118aeefb70
ithread_loop() at ithread_loop+0xa6/frame 0xfe118aeefbb0
fork_exit() at fork_exit+0x84/frame 0xfe118aeefbf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe118aeefbf0
--- trap 0, rip = 0, rsp = 0xfe118aeefcb0, rbp = 0 ---

+1 from me;  I  guess introduced somwhere between 255569 and 255758,
as these are my edges of kernel.old and kernel.


r255726 was stable for me. r255759 is not.

r255755 converted ipfilter to callout, but I am unsure if that is the
problem.


r255729 is also stable for me - I'm with r255729 again, since r255757
crashed.

Let me know if this fixes the problem for you:
http://people.freebsd.org/~davide/review/lc_calloutfix.diff

Thanks,


Worked for me so far. I generally couldn't stay up more than 30 minutes
before the patch and now my uptime is 90 minutes. Thanks!

Same here.


--
Regards,
Bryan Drewery


I would wait another couple of hours before the commit, but still I'm
confident this fixed the problem.


 7:05PM  up  8:18, 1 user, load averages: 0.08, 0.18, 0.21

___
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

Re: kmem_map auto-sizing and size dependencies

2013-01-22 Thread Adam McDougall 

On 1/22/2013 6:22 PM, Artem Belevich wrote:

On Mon, Jan 21, 2013 at 1:06 PM, Pawel Jakub Dawidek p...@freebsd.org wrote:

On Fri, Jan 18, 2013 at 08:26:04AM -0800, m...@freebsd.org wrote:

  Should it be set to a larger initial value based on min(physical,KVM) space
  available?

It needs to be smaller than the physical space, [...]

Or larger, as the address space can get fragmented and you might not be
able to allocate memory even if you have physical pages available.

+1 for relaxing upper limit.

I routinely patch all my systems that use ZFS to allow kmem_map size
to be larger than physical memory. Otherwise on a system where most of
RAM goes towards ZFS ARC I used to eventually run into dreaded
kmem_map too small panic.

--Artem
___

Ever since related code has been patched to properly permit kmem=2x physmem
out of the box, I've been using that guideline for my systems and
I've not had an out of kmem panic in years.  I've previously ran into weird
temporary deadlocks with strong IO if I set the kmem too high, as if the ARC
caused something important to be overwritten; that is just my theory.  I 
agree

with the fragmentation principle here.  YMMV regarding the kmem size.
___
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

Re: after upgrade, can't restart apache via cron

2012-11-22 Thread Adam McDougall 

On 11/22/2012 10:17 PM, Michael W. Lucas wrote:


FreeBSD bewilderbeast.blackhelicopters.org 10.0-CURRENT FreeBSD 10.0-CURRENT 
#15: Thu Nov  8 14:02:45 EST 2012 
mwlu...@bewilderbeast.blackhelicopters.org:/usr/obj/usr/src/sys/GENERIC  amd64

I can manually restart apache22 with the following /etc/rc.conf entries:

apache22_enable=YES
apache22_fib=0

I have a cron entry that restarts apache regularly, to compensate for
some mysql daftness.

13  *  * * * /usr/local/etc/rc.d/apache22 restart

When this job runs, I get the following email:

Performing sanity check on apache22 configuration:
Syntax OK
Stopping apache22.
Waiting for PIDS: 59501.
Performing sanity check on apache22 configuration:
Syntax OK
Starting apache22.
eval: setfib: not found
/usr/local/etc/rc.d/apache22: WARNING: failed to start apache22

If I run /usr/local/etc/rc.d/apache22 restart from the command line, I
can restart httpd without trouble.

Any thoughts?

==ml


Make sure the path to setfib is in PATH in the crontab?

PATH=/blah/blah/blah:/usr/sbin
* *   *   *   *   blah

___
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

Re: Buying recommendation for silent router/fileserver

2012-10-12 Thread Adam McDougall 

I did not, but I put it on my list to try to accomplish.

On 10/11/12 13:41, Adrian Chadd wrote:

Did you ever file a PR for the slow SATA behaviour?



Adrian


On 11 October 2012 09:52, Adam McDougall mcdou...@egr.msu.edu wrote:

On 10/11/12 12:05, Gary Palmer wrote:


On Thu, Oct 11, 2012 at 04:54:53PM +0200, Ulrich Sp??rlein wrote:


Hey guys,

I need to replace an aging Pentium IV system that has been serving as my
router, access point, file- and mediaserver for quite some time now. The
replacement should have:

- amd64 CPU (for ZFS, obviously)
- 2x GigE (igress, egress interfaces)
- some form of wlan interface (I currently use an Atheros based PCI card)
- eSATA for attaching a backup disk where I stream ZFS snapshots to
- serial port is always nice, for when I mess up an upgrade
- fan-less if possible

So far, this here seems to fit the bill perfectly
http://www.fit-pc.com/web/fit-pc/intensepc/
but pricing seems to defy any reality.

It does not state directly which chipsets are used for Wifi and
Ethernet, the block diagram claims Ethernet chips to be Intel 82579 and
RTL8111D, but I don't trust that fully.

For Wifi I can always fall back to sticking in a supported USB stick,
although that's kinda hacky.

So how well is networking going to be supported by FreeBSD? Should I
just bite the bullet and find out?



I'd recommend the Soekris net6501, but it's even more expensive than the
intensepc (I suspect due to low hardware volumes but thats just a guess)

http://soekris.com/products/net6501.html

You also don't specify what kind of storage you need, which is obviously
an important factor for a file/media server.

Gary
___
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



Be wary of the Soekris net6501, I bought three of the 1.6Ghz net6501-70
model which has an Atom E-680 cpu (E series) and it compiles more than twice
as slow as a 1.6Ghz Atom N270 in an older netbook.  Someone else running
Linux reported similar CPU slowness.  As far as practical network
throughput, I could only get 100Mbit/sec with a simple HTTP download of a
file full of zeros, and OpenVPN could only push about 25Mbit/sec.  As a
practical example of the CPU slowness, it takes about 1.5 minutes to compile
pkg on the N270 netbook and 5 minutes on the 6501 (around 4.5 if I use -j2).
A kernel compile took an hour. Unfortunately I had no idea this CPU
(possibly implementation?) was so slow before I purchased it, and I could
scarcely find evidence of it on google after hours of searching when I had
already discovered the issue.  I was hoping to find some comparative
benchmarks between various Atom series but manufacturers generally don't do
that.

Additionally, the total AHCI SATA write speed on the net6501 (in BSD only?)
has a strange 20MB/sec limitation but reads can go over 100MB/sec.  If I
write to one disk I get 20MB/sec, if I write to both SATA disks I get
10MB/sec each.  Write is equally slow on a SSD.  Both someone running
OpenBSD and I running FreeBSD reported the same symptoms to the soekris-tech
mailing list and received no useful replies towards getting that problem
solved.  I tested the write speed briefly with Linux and it did not appear
to have the 20MB/sec limitation.  I did confirm it was using MSI(-X?) with
boot -v.  I think this hardware would need to fall into Alexander Motin's
hands to get anywhere with debugging the SATA speed issue.  Since it seems
fine in Linux, maybe some day it can be fixed in BSD but I have no clue how
that limitation could happen.  The disks I tested with are fine in normal
computers.

___
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


___
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

Re: Buying recommendation for silent router/fileserver

2012-10-11 Thread Adam McDougall 

On 10/11/12 12:05, Gary Palmer wrote:

On Thu, Oct 11, 2012 at 04:54:53PM +0200, Ulrich Sp??rlein wrote:

Hey guys,

I need to replace an aging Pentium IV system that has been serving as my
router, access point, file- and mediaserver for quite some time now. The
replacement should have:

- amd64 CPU (for ZFS, obviously)
- 2x GigE (igress, egress interfaces)
- some form of wlan interface (I currently use an Atheros based PCI card)
- eSATA for attaching a backup disk where I stream ZFS snapshots to
- serial port is always nice, for when I mess up an upgrade
- fan-less if possible

So far, this here seems to fit the bill perfectly
http://www.fit-pc.com/web/fit-pc/intensepc/
but pricing seems to defy any reality.

It does not state directly which chipsets are used for Wifi and
Ethernet, the block diagram claims Ethernet chips to be Intel 82579 and
RTL8111D, but I don't trust that fully.

For Wifi I can always fall back to sticking in a supported USB stick,
although that's kinda hacky.

So how well is networking going to be supported by FreeBSD? Should I
just bite the bullet and find out?


I'd recommend the Soekris net6501, but it's even more expensive than the
intensepc (I suspect due to low hardware volumes but thats just a guess)

http://soekris.com/products/net6501.html

You also don't specify what kind of storage you need, which is obviously
an important factor for a file/media server.

Gary
___
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



Be wary of the Soekris net6501, I bought three of the 1.6Ghz net6501-70 
model which has an Atom E-680 cpu (E series) and it compiles more than 
twice as slow as a 1.6Ghz Atom N270 in an older netbook.  Someone else 
running Linux reported similar CPU slowness.  As far as practical 
network throughput, I could only get 100Mbit/sec with a simple HTTP 
download of a file full of zeros, and OpenVPN could only push about 
25Mbit/sec.  As a practical example of the CPU slowness, it takes about 
1.5 minutes to compile pkg on the N270 netbook and 5 minutes on the 6501 
(around 4.5 if I use -j2).  A kernel compile took an hour. 
Unfortunately I had no idea this CPU (possibly implementation?) was so 
slow before I purchased it, and I could scarcely find evidence of it on 
google after hours of searching when I had already discovered the issue. 
 I was hoping to find some comparative benchmarks between various Atom 
series but manufacturers generally don't do that.


Additionally, the total AHCI SATA write speed on the net6501 (in BSD 
only?) has a strange 20MB/sec limitation but reads can go over 
100MB/sec.  If I write to one disk I get 20MB/sec, if I write to both 
SATA disks I get 10MB/sec each.  Write is equally slow on a SSD.  Both 
someone running OpenBSD and I running FreeBSD reported the same symptoms 
to the soekris-tech mailing list and received no useful replies towards 
getting that problem solved.  I tested the write speed briefly with 
Linux and it did not appear to have the 20MB/sec limitation.  I did 
confirm it was using MSI(-X?) with boot -v.  I think this hardware would 
need to fall into Alexander Motin's hands to get anywhere with debugging 
the SATA speed issue.  Since it seems fine in Linux, maybe some day it 
can be fixed in BSD but I have no clue how that limitation could happen. 
 The disks I tested with are fine in normal computers.

___
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

Re: OpenLDAP/SASL2 problem in FreeBSD 10.0-CURRENT WAS: Re: HELP! core dumps: install, mtree, et cetera all of the sudden after portmaster security/cyrus-sasl2

2012-08-18 Thread Adam McDougall 

On 8/18/2012 4:07 AM, O. Hartmann wrote:

My setups on all boxes using OpenLDAP, the port
net/opendldap24-client/server has security/cyrus-sasl2 enabled.
I use nsswitch and nascd.

The problem:
I can not anymore install or reinstall (using portmaster, patched for
pkgng) the ports

security/cyrus-sasl2
net/openldap24-client

When performing an update (no matter which one), The installation
process dies when installing the packages (see error for openldap-cleint
below, it is proxy for cyrus-sasl2 also).

After a failed installation, close to all binaries I touch start to
coredump in a mustang way. ls(1) works, but ls -la dumps core (resolving
the ownership-issue?).

The only way to save the box is to copy missing libldap_r-2.4.so.8 or
libsasl2.so.2 to /usr/local/lib/ from another, compatible box or from a
backup.

It is impossible to me to update/reinstall either net/openldap24-client
or security/cyrus-sasl2.

===  Installing for openldap-sasl-client-2.4.32_1
===   Generating temporary packing list
Segmentation fault (core dumped)
*** [install-mtree] Error code 139


What happens if you disable both LDAP and cache support from NSS before
upgrading either of those two packages?  Installing files certainly must
invoke functions that need to translate owners/groups to uid/gid so perhaps
something related to that suddenly fails during an attempt to replace
the library.  It sounds like if your LDAP support becomes corrupt, then
it leaves a gaping hole in the NSS critical path that many parts of the
system must be using.  When you run into this situation and can resolve
it easily by replacing the old ldap library, is the old one corrupt?
Missing?  Can you save a copy for evaluation?  Does your system break in
a similar manner simply by renaming the LDAP library, or does it behave
worse only if there is a faulty LDAP library being used by nss_ldap?

___
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

Re: Trouble getting serial support for Live CD in 9 installer

2011-12-05 Thread Adam McDougall 

On 11/23/11 15:03, Garrett Cooper wrote:

On Wed, Nov 23, 2011 at 11:12 AM, Adam McDougallmcdou...@egr.msu.edu  wrote:

I often use the serial console on my servers through ILOM remote console
access to install FreeBSD because it lets me cut and paste commands into a
live shell from install media.  Back with FreeBSD 8.x and previous, the
console worked as a dual console between the redirected VGA/keyboard console
and serial, all I had to do was drop to the loader prompt at the boot loader
menu to enter:

set console=comconsole
set boot_serial=yes
boot

 From then on, the VGA console was ignored until I rebooted.  But in 9.x
(currently trying 9.0-RC2 from the usb image), I have to interrupt an
earlier loader to use -h or -D to enable serial(dual) console support at
all.  I then enter the two variables above as I usually do, then specify my
terminal type (xterm), then choose Live CD which prints:
Updating motd: /etc/motd is not writable, update failed.
Configuring syscons: blanktime.
Starting cron.
Starting background file system checks in 60 seconds.

Wed Nov 23 19:03:02 UTC 2011

but then it prints the FreeBSD banner and spawns the login: prompt on the
VGA console instead.

Is there something else I can set during the boot process to make this work?
  I could try modifying the configuration on the usb image to suit my site
but this is more modification than I required in the past and surprisingly
different.  Please let me know if I can provide more information or help in
some way.  Thanks.

If I don't hear back in a few days or so, I'll make a PR.


You'll need to change your device.hints and /etc/ttys.
-Garrett
___
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


Thanks.  This lead me to an even easier solution with no editing that 
should work with booting from CD and with previous versions:


1. Boot completely normally
2. Use the installer to drop to Live CD shell
3. execute: /usr/libexec/getty std.9600 ttyu0

This spawns a login prompt on the serial port ttyu0 which is essentially 
all I need.  I didn't seem to need to alter the device hints at all for 
my situation, and on a USB key I can mount -u -o rw / to edit one or 
more of /etc/ttys, /boot/loader.conf, /boot.config if I want to make it 
permanent for next time.

___
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

Trouble getting serial support for Live CD in 9 installer

2011-11-23 Thread Adam McDougall 
I often use the serial console on my servers through ILOM remote console 
access to install FreeBSD because it lets me cut and paste commands into 
a live shell from install media.  Back with FreeBSD 8.x and previous, 
the console worked as a dual console between the redirected VGA/keyboard 
console and serial, all I had to do was drop to the loader prompt at the 
boot loader menu to enter:


set console=comconsole
set boot_serial=yes
boot

From then on, the VGA console was ignored until I rebooted.  But in 9.x 
(currently trying 9.0-RC2 from the usb image), I have to interrupt an 
earlier loader to use -h or -D to enable serial(dual) console support at 
all.  I then enter the two variables above as I usually do, then specify 
my terminal type (xterm), then choose Live CD which prints:

Updating motd: /etc/motd is not writable, update failed.
Configuring syscons: blanktime.
Starting cron.
Starting background file system checks in 60 seconds.

Wed Nov 23 19:03:02 UTC 2011

but then it prints the FreeBSD banner and spawns the login: prompt on 
the VGA console instead.


Is there something else I can set during the boot process to make this 
work?  I could try modifying the configuration on the usb image to suit 
my site but this is more modification than I required in the past and 
surprisingly different.  Please let me know if I can provide more 
information or help in some way.  Thanks.


If I don't hear back in a few days or so, I'll make a PR.
___
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

Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm

1999-10-19 Thread Adam McDougall 

:Okay. I committed the fix to the length calculation to -current and
:-stable (I just love one-line patches that stop panics). I just got 
:done patching my NFS server machines and they all seem to get along
:nicely with the SGI now. Now I can upgrade the other SGIs without
:worrying about them clobbering my FreeBSD machines.
:
:Hm. I wonder what would happen if the FreeBSD host was the client
:and the SGI was the server.

Have you ever tried this since?  I caught whiff of a hardcore debain user
unsure about linux's nfs client connecting to IRIX nfs servers and I'm
looking to provide a datapoint for FreeBSD.

:
:-Bill
:=
:-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm

1999-10-19 Thread Adam McDougall 

Ah crap nevermind; I haven't had my coffee today.

On Tue, 19 Oct 1999, Adam McDougall wrote:

 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

sb16 not found with newpcm

1999-09-08 Thread Adam McDougall 

I thought I'd try kicking sb0 out of my kernel and try pcm for a change,
but I cannot get it to work with simply "device pcm0". My sb16 is not pnp,
and adding controller pnp0 did not help.  With just device pcm0, the
kernel mentions nothing of pcm at all.  sb0 worked fine with:

controller  snd0
device sb0  at isa? port 0x220 irq 5 drq 1
device sbxvi0   at isa? drq 5 port 0x0
device sbmidi0  at isa? port 0x330
device opl0 at isa? port 0x388

AND pcm does work with:
device  pcm0 at isa? port 0x220 irq 5 drq 1 flags 0x15
as someone else suggested on the list.

pcm0: SoundBlaster 16 4.11 at port 0x220-0x22f irq 5 drq 1 flags 0x15 on
isa0

If dmesg from sb0 would help I could get it..  Anything else I could help
with in making "device pcm0" work without params? or is that pnp only?
Thanks




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

reproducable panic?

1999-03-20 Thread Adam McDougall 
I seem to be able to reproduce a panic on my 4.0 machine (updated
yesterday, kernel and world, also could crash with a somewhat older
build)

I have pseudo-device vn  and nfs  in my kernel, not as a module.

When I vnconfig -c /dev/vn0c /nfsmountpoint/somefile,  the system panics
reliably.

If there is more useful info I could give, or shell accounts, etc,
please let me know.

IdlePTD 3133440
initial pcb at 2701d8
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xff68
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01af522
stack pointer   = 0x10:0xc0252770
frame pointer   = 0x10:0xc0252770
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask  = 
trap number = 12
panic: page fault

syncing disks... 

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x30
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01d99b0
stack pointer   = 0x10:0xc02524cc
frame pointer   = 0x10:0xc02524d0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask  = bio 
trap number = 12
panic: page fault

dumping to dev 20401, offset 393216
dump 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43
42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19
18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 
---
#0  boot (howto=260) at ../../kern/kern_shutdown.c:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0  boot (howto=260) at ../../kern/kern_shutdown.c:287
#1  0xc01486ed in panic (fmt=0xc024aad7 page fault)
at ../../kern/kern_shutdown.c:448
#2  0xc0210016 in trap_fatal (frame=0xc0252490, eva=48)
at ../../i386/i386/trap.c:943
#3  0xc020fccf in trap_pfault (frame=0xc0252490, usermode=0, eva=48)
at ../../i386/i386/trap.c:836
#4  0xc020f902 in trap (frame={tf_es = -1071316976, tf_ds = -1071710192, 
  tf_edi = -1062680960, tf_esi = 0, tf_ebp = -1071307568, 
  tf_isp = -1071307592, tf_ebx = -1071245808, tf_edx = -1073217472, 
  tf_ecx = 0, tf_eax = 0, tf_trapno = 12, tf_err = 0, 
  tf_eip = -1071801936, tf_cs = 8, tf_eflags = 66178, 
  tf_esp = -1036656256, tf_ss = -1071307536}) at
../../i386/i386/trap.c:438
#5  0xc01d99b0 in acquire_lock (lk=0xc0261610)
at ../../ufs/ffs/ffs_softdep.c:267
#6  0xc01dc827 in initiate_write_inodeblock (inodedep=0xc0a8c680, 
bp=0xc1e8f398) at ../../ufs/ffs/ffs_softdep.c:2827
#7  0xc01dc5cf in softdep_disk_io_initiation (bp=0xc1e8f398)
at ../../ufs/ffs/ffs_softdep.c:2686
#8  0xc017992a in spec_strategy (ap=0xc0252550)
at ../../miscfs/specfs/spec_vnops.c:555
#9  0xc01790bd in spec_vnoperate (ap=0xc0252550)
at ../../miscfs/specfs/spec_vnops.c:129
#10 0xc01e7af5 in ufs_vnoperatespec (ap=0xc0252550)
at ../../ufs/ufs/ufs_vnops.c:2327
#11 0xc0166a67 in bwrite (bp=0xc1e8f398) at vnode_if.h:891
#12 0xc016b1f6 in vop_stdbwrite (ap=0xc02525b8) at
../../kern/vfs_default.c:297
#13 0xc016b041 in vop_defaultop (ap=0xc02525b8) at
../../kern/vfs_default.c:131
#14 0xc01790bd in spec_vnoperate (ap=0xc02525b8)
at ../../miscfs/specfs/spec_vnops.c:129
#15 0xc01e7af5 in ufs_vnoperatespec (ap=0xc02525b8)
at ../../ufs/ufs/ufs_vnops.c:2327
#16 0xc01674c7 in vfs_bio_awrite (bp=0xc1e8f398) at vnode_if.h:1145
#17 0xc01e1b46 in ffs_fsync (ap=0xc0252640) at
../../ufs/ffs/ffs_vnops.c:205
#18 0xc01dffe7 in ffs_sync (mp=0xc0a04a00, waitfor=2, cred=0xc0a1ff00, 
p=0xc028c8e0) at vnode_if.h:499
#19 0xc016fc2b in sync (p=0xc028c8e0, uap=0x0) at
../../kern/vfs_syscalls.c:542
#20 0xc0148299 in boot (howto=256) at ../../kern/kern_shutdown.c:205
#21 0xc01486ed in panic (fmt=0xc024aad7 page fault)
at ../../kern/kern_shutdown.c:448
#22 0xc0210016 in trap_fatal (frame=0xc0252734, eva=4294967144)
at ../../i386/i386/trap.c:943
#23 0xc020fccf in trap_pfault (frame=0xc0252734, usermode=0,
eva=4294967144)
at ../../i386/i386/trap.c:836
#24 0xc020f902 in trap (frame={tf_es = -989003760, tf_ds = 528089104, 
  tf_edi = -1073741824, tf_esi = -982050144, tf_ebp = -1071306896, 
  tf_isp = -1071306916, tf_ebx = -1062665024, tf_edx = -152, 
  tf_ecx = -982050144, tf_eax = -2147483648, tf_trapno = 12, tf_err
= 0, 
  tf_eip = -1071975134, tf_cs = 8, tf_eflags = 66182, 
  tf_esp = -1071306860, tf_ss = -1071975907}) at
../../i386/i386/trap.c:438
#25 0xc01af522 in nfs_sigintr (nmp=0xc5771aa0, rep=0xc0a904c0,
p=0xc0133634)
at ../../nfs/nfs_socket.c:1479
#26 0xc01af21d in nfs_timer (arg=0x0) at ../../nfs/nfs_socket.c:1355
#27 0xc014cb8e in softclock

Re: ATAPI and ATAPI_STATIC with the new ATA* driver?

1999-03-02 Thread Adam McDougall 
Sheldon Hearn wrote:
 
 On Tue, 02 Mar 1999 10:49:17 +0100, Søren Schmidt wrote:
 
  Yes, they are not used by the new driver, it only needs the above lines
  in config, depending on how many subdrivers you want of cause.
 
 Excellent. :-)
 
 The only thing that bit me was that I used wd0 and wd2 with the older
 driver, whereas the newer driver automatically decided to use ad0 and
 ad1. This is expected behaviour, but it's something for other weenies
 to watch out for. :-)

Is/will there be a way to wire the devices down like you can with SCSI
devices?


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message