Plugin the disk as usb disk to other freebsd11(vm) , dmesg info:
ugen1.2: at usbus1
umass0: on
usbus1
umass0: SCSI over Bulk-Only; quirks = 0x4100
umass0:3:0: Attached to scbus3
da1 at umass-sim0 bus 0 scbus3 target 0 lun 0
da1: Fixed Direct Access SCSI-0 device
da1: Serial Number 0033
On 13-12-10 10:09 PM, Nathan Whitehorn wrote:
Modern SCSI hardware often uses 64-bit logical units (LUNs). The patch found at
http://people.freebsd.org/~nwhitehorn/lun64.diff widens the type of lun_id_t to
64 bits, bumps CAM_VERSION, and begins exposing these to drivers that are marked
as support
Eitan Adler wrote:
> On Tue, Dec 10, 2013 at 7:04 PM, Rick Macklem
> wrote:
> > Hi,
> >
> > I just tried to MFC into stable/10 and it worked, but with
> > a lot of mergeinfo. I know diddly about svn, so is this ok?
>
> Starting with stable/10 and later you must merge into the *root*, not
> into s
On Tue, Dec 10, 2013 at 7:04 PM, Rick Macklem wrote:
> Hi,
>
> I just tried to MFC into stable/10 and it worked, but with
> a lot of mergeinfo. I know diddly about svn, so is this ok?
Starting with stable/10 and later you must merge into the *root*, not into sys/.
P.S., with svn, it can be very
Hi,
I just tried to MFC into stable/10 and it worked, but with
a lot of mergeinfo. I know diddly about svn, so is this ok?
Here's the "svn diff":
Index: sys
===
--- sys (revision 259205)
+++ sys (working copy)
Property changes on: s
On 12/10/13 17:41, Douglas Gilbert wrote:
On 13-12-10 10:09 PM, Nathan Whitehorn wrote:
Modern SCSI hardware often uses 64-bit logical units (LUNs). The
patch found at
http://people.freebsd.org/~nwhitehorn/lun64.diff widens the type of
lun_id_t to
64 bits, bumps CAM_VERSION, and begins exposing
On 10.12.13 03:52, Larry Rosenman wrote:
> On 2013-12-09 16:04, Aleksandr Rybalko wrote:
>> On Mon, 9 Dec 2013 10:36:34 -0600
>> Larry Rosenman wrote:
>>
>>>
>>> Path: .
>>> Working Copy Root Path: /usr/src
>>> URL: svn://svn.freebsd.org/base/head
>>> Relative URL: ^/head
>>> Repository Root: svn:
Modern SCSI hardware often uses 64-bit logical units (LUNs). The patch
found at http://people.freebsd.org/~nwhitehorn/lun64.diff widens the
type of lun_id_t to 64 bits, bumps CAM_VERSION, and begins exposing
these to drivers that are marked as supporting extended LUNs. No
behavior is changed ex
Hey Vladimir,
You'd better ask this question on the lists. I've added current@ and
ray@to the cc.
Thanks,
Ed
Am 11.12.2013 03:09 schrieb "Vladimir A. Noskov" :
> Hello, Ed!
>
> I compiled FreeBSD nbw001 11.0-CURRENT FreeBSD 11.0-CURRENT # 0 r259137:
> Tue Dec 10 02:57:07 MSK 2013 root @ nbw001
OK, I'll see if my centrino 1xx / 1xxx units match yours and are problematic.
Please file a PR!
-a
On 7 December 2013 05:34, 乔楚 wrote:
> Today ,I upgrade my freebsd from 10-beta4 to current.
> Now, my freebsd can't connect to wireless AP. Wireless LAN strike.
>
> iwn0 in /var/log/message:
> De
*Today, after **upgrade to HEAD from svn, My FreeBSD can't boot.*
*Error message:*
*ZFS: i/o error all block copies unavailable
**Invalid format*
*If boot from **FreeBSD-11.0-CURRENT-amd64-20131205-r258961-bootonly.iso
or FreeBSD-11.0-CURRENT-amd64-20131205-r258961-disc1.iso, boot loader
will s
"Jean-Sébastien Pédron" написав(ла):
>On 10.12.2013 00:49, Aleksandr Rybalko wrote:
>> It is not fatal in syscons case. We decide to mark this message as
>> error, to get more attention when run with newcons. For newcons it
>> indicate that vt will not be able to draw into framebuffer(memory
>> re
On 10.12.2013 00:49, Aleksandr Rybalko wrote:
> It is not fatal in syscons case. We decide to mark this message as
> error, to get more attention when run with newcons. For newcons it
> indicate that vt will not be able to draw into framebuffer(memory
> region which contain image you see on display
13 matches
Mail list logo
