Re: svn commit: r259016 - in head/sys: conf dev/drm2 dev/drm2/i915 dev/drm2/radeon dev/fb dev/vt kern modules/drm2/i915kms modules/drm2/radeonkms sparc64/sparc64 sys teken
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). But it have no impact on sc (syscons). Is there something we can check at build time or runtime to determine which of syscons or newcons is used, and consequently, avoid this error message? Because we'll probably have many reports of that in the future. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: svn commit: r259016 - in head/sys: conf dev/drm2 dev/drm2/i915 dev/drm2/radeon dev/fb dev/vt kern modules/drm2/i915kms modules/drm2/radeonkms sparc64/sparc64 sys teken
Jean-Sébastien Pédron jean-sebastien.ped...@dumbbell.fr написав(ла): 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). But it have no impact on sc (syscons). Is there something we can check at build time or runtime to determine which of syscons or newcons is used, and consequently, avoid this error message? Because we'll probably have many reports of that in the future. Yep, committed in r259179. Thanks! WBW -- Aleksandr Rybalko r...@ddteam.net ___ 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
boot failure after upgrade to HEAD from svn: zfs i/o error - all block copies unavailable invalid format
*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 stop at *mountfrom: *My FreeBSD version is -current.* *Before upgrade, svn version is r25906.* *After upgrade , svn version maybe r**259156.* *ZFS is root fs.* *How to fix it?* ___ 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: Intel Centrino Wireless-N 1000 can't connect to AP
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, 乔楚 honestq...@gmail.com 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: Dec 7 08:02:00 x201i kernel: iwn0: Intel Centrino Wireless-N 1000 mem 0xf240-0xf2401fff irq 16 at device 0.0 on pci2 Dec 7 08:02:00 x201i kernel: iwn0: attempting to allocate 1 MSI vectors (1 supported) Dec 7 08:02:00 x201i kernel: msi: routing MSI IRQ 266 to local APIC 0 vector 62 Dec 7 08:02:00 x201i kernel: iwn0: using IRQ 266 for MSI Dec 7 08:02:00 x201i kernel: iwn0: MIMO 1T2R, BGS, address 8c:a9:82:5a:41:58 Dec 7 08:02:00 x201i kernel: iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps Dec 7 08:02:00 x201i kernel: iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps Dec 7 08:02:00 x201i kernel: iwn0: 1T2R Dec 7 08:02:00 x201i kernel: iwn0: 11ng MCS 20MHz Dec 7 08:02:00 x201i kernel: iwn0: MCS 0-7: 6.5Mbps - 65Mbps Dec 7 08:02:00 x201i kernel: iwn0: 11ng MCS 20MHz SGI Dec 7 08:02:00 x201i kernel: iwn0: MCS 0-7: 7Mbps - 72Mbps Dec 7 08:02:00 x201i kernel: iwn0: 11ng MCS 40MHz: Dec 7 08:02:00 x201i kernel: iwn0: MCS 0-7: 13.5Mbps - 135Mbps Dec 7 08:02:00 x201i kernel: iwn0: 11ng MCS 40MHz SGI: Dec 7 08:02:00 x201i kernel: iwn0: MCS 0-7: 15Mbps - 150Mbps .. Dec 7 08:02:00 x201i kernel: wlan0: Ethernet address: f0:de:f1:52:cf:16 Dec 7 08:02:00 x201i kernel: iwn0: iwn_intr: fatal firmware error Dec 7 08:02:00 x201i kernel: firmware error log: Dec 7 08:02:00 x201i kernel: error type = SYSASSERT (0x0005) Dec 7 08:02:00 x201i kernel: program counter = 0x00018DBC Dec 7 08:02:00 x201i kernel: source line = 0x0032 Dec 7 08:02:00 x201i kernel: error data = 0x0001 Dec 7 08:02:00 x201i kernel: branch link = 0x00018D6E00018D6E Dec 7 08:02:00 x201i kernel: interrupt link = 0x0826 Dec 7 08:02:00 x201i kernel: time= 1538064582 Dec 7 08:02:00 x201i kernel: driver status: Dec 7 08:02:00 x201i kernel: tx ring 0: qid=0 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 1: qid=1 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 2: qid=2 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 3: qid=3 cur=2 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 4: qid=4 cur=57 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 5: qid=5 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 6: qid=6 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 7: qid=7 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 8: qid=8 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 9: qid=9 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 10: qid=10 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 11: qid=11 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 12: qid=12 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 13: qid=13 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 14: qid=14 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 15: qid=15 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 16: qid=16 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 17: qid=17 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 18: qid=18 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 19: qid=19 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: rx ring: cur=29 .. Dec 7 08:02:01 x201i wpa_supplicant[667]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Device not configured Dec 7 08:02:01 x201i wpa_supplicant[667]: wlan0: Failed to initiate AP scan I do not know where the problem is? If necessary, I can tie debugging. ___ 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: newcons + device.hints
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 woc...@hotbox.ru: 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 :/ usr/obj/usr/home/wocson/devel/src.newcons/sys/W20131213 amd64 This is my Toshiba laptop on CPU AMD E -450 : # Sysctl-a | egrep-i 'hw.machine | hw.model | hw.ncpu' hw.machine: amd64 hw.model: AMD E- 450 APU with Radeon (tm) HD Graphics hw.ncpu: 2 hw.machine_arch: amd64 Radeon HD 6320 This kernel was launched in FreeBSD 10 Beta 4 (build 10 PCBSD -Stable http://iso.cdn.pcbsd.org/10-STABLE/amd64/) Everything is working fine . I have one question : Is it possible to install the OS at startup console mode 1366x768px ? For sc was done editing device.hints. hint.sc.0.at = isa hint.sc.0.flags = 0x180 hint.sc.0.vesa_mode = 0x11b If you need any more information I will inform you . Thank you. -- *Vladimir A. Noskov* ___ 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
[CAM] Widening lun_id_t to 64-bits
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 except that peripheral with very long LUNs that didn't work before will start working. Binary compatibility with old code is also kept. There is, however, a chance that some 3rd party software might be unhappy about the type widening, so I'd appreciate any testing results. Barring any issues, I will commit this on Friday. -Nathan ___ 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 with -CURRENT @Boot [r259130]
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 l...@lerctr.org wrote:
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 259130
Node Kind: directory
Schedule: normal
Last Changed Author: ray
Last Changed Rev: 259130
Last Changed Date: 2013-12-09 09:28:34 -0600 (Mon, 09 Dec 2013)
[[cut]]
Can you please share core and kernel with modules.
I'm not sure, but looks like it is related to vt (newcons).
So I have to investigate.
Thanks!
WBW
I've passed ray@ credentials to get at the core/kernel/etc on the system
that generated it.
I have a +2, the same panic as Larry plus another one on my Thinkpads.
The second panic looks like this:
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x807b8147
stack pointer = 0x28:0xfe00dd97f8e0
frame pointer = 0x28:0x333231302f2e2d2c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1132 (vidcontrol)
I 'fixed' this with the attached patch. I have to test tomorrow if the
first panic (the one Larry sees) on my Dell also goes away with this 'fix'.
I compared with syscons.c and there the ival/data assigment is always
done inside the case label and not at the end.
maybe I'm papering over ... but at least a starting point to investigate.
Andreas
Index: dev/vt/vt_core.c
===
--- dev/vt/vt_core.c(revision 259154)
+++ dev/vt/vt_core.c(working copy)
@@ -1294,37 +1295,55 @@
switch (cmd) {
case _IO('v', 4):
cmd = VT_RELDISP;
+ ival = IOCPARM_IVAL(data);
+ data = (caddr_t)ival;
break;
case _IO('v', 5):
cmd = VT_ACTIVATE;
+ ival = IOCPARM_IVAL(data);
+ data = (caddr_t)ival;
break;
case _IO('v', 6):
cmd = VT_WAITACTIVE;
+ ival = IOCPARM_IVAL(data);
+ data = (caddr_t)ival;
break;
case _IO('K', 20):
cmd = KDSKBSTATE;
+ ival = IOCPARM_IVAL(data);
+ data = (caddr_t)ival;
break;
case _IO('K', 67):
cmd = KDSETRAD;
+ ival = IOCPARM_IVAL(data);
+ data = (caddr_t)ival;
break;
case _IO('K', 7):
cmd = KDSKBMODE;
+ ival = IOCPARM_IVAL(data);
+ data = (caddr_t)ival;
break;
case _IO('K', 8):
cmd = KDMKTONE;
+ ival = IOCPARM_IVAL(data);
+ data = (caddr_t)ival;
break;
case _IO('K', 63):
cmd = KIOCSOUND;
+ ival = IOCPARM_IVAL(data);
+ data = (caddr_t)ival;
break;
case _IO('K', 66):
cmd = KDSETLED;
+ ival = IOCPARM_IVAL(data);
+ data = (caddr_t)ival;
break;
case _IO('c', 110):
cmd = CONS_SETKBD;
+ ival = IOCPARM_IVAL(data);
+ data = (caddr_t)ival;
break;
}
- ival = IOCPARM_IVAL(data);
- data = (caddr_t)ival;
#endif
switch (cmd) {
___
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: [CAM] Widening lun_id_t to 64-bits
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 these to drivers that are marked as supporting extended LUNs. No behavior is changed except that peripheral with very long LUNs that didn't work before will start working. Binary compatibility with old code is also kept. There is, however, a chance that some 3rd party software might be unhappy about the type widening, so I'd appreciate any testing results. Barring any issues, I will commit this on Friday. Interesting, Hannes Reinecke is trying to do something very similar in the Linux SCSI subsystem. His patch set today will be the third attempt in a year (by my count) and he might just get over the top this time. There is some support in my sg3_utils package for the way Linux is implementing 64 bit LUNs. The sg3_utils package also supports FreeBSD so I'm interested in what your mapping will be. Now, as you are no doubt aware, SCSI (www.t10.org and specifically sam5r15.pdf) does not have 64 bit LUNs, it has 8 byte LUNs in SCSI order (i.e. big endian). Given that major architectures like i386 and x86_64 are little endian, the mapping between a 64 bit integer in native form and an 8 byte SCSI LUN is a bit of a puzzle. That becomes a little harder when you try for low numbered integers representing the T10 3 bit LUNs (showing my age), 8 bit LUNs and 16 bit LUNs. Down to brass tacks: what exactly will a SCSI REPORT LUNS WELL KNOWN LOGICAL UNIT number [T10 (in hex): c1 01 00 00 00 00 00 00] be in one of your 64 bits LUNs? Will that be the same in little endian and big endian architectures? There is also the representation of that LUN in logs; for example lun=13907397124296802304 is not very intuitive. More examples would be great, perhaps from the 4, 6 and 8 byte extended logical unit addressing format. We're following the path-of-least-resistance from Solaris. I've momentarily forgotten how this works in the Linux patches, but the approach is as follows (this has actually been in HEAD for a couple months now). Extended LUNs are stored in host byte order with swizzled 16-bit word order so that, for devices implementing LUN addressing (like SCSI-2), the numerical representation of the LUN is identical before and after the change. Thus this keeps most behavior, and user-facing LUN IDs, unchanged. A macro (CAM_EXTLUN_BYTE_SWIZZLE) is provided to transform a lun_id_t into a uint64_t ordered for the wire. Most of the kernel prints these in hex as per SAM5. camcontrol prints them out in various ways if it knows the addressing component to which they correspond and otherwise prints them in hex. This seemed like by far the least painful approach: it has a (fairly) simple direct mapping onto the wire format, nothing changes for users, and almost nothing changes for code. Robert Elliott who has been a T10 technical editor has written a paper on this subject but google fails me, perhaps someone else can supply the url. His advice was too late for Linux and perhaps it is already too late for FreeBSD. Hopefully this corresponds to that advice, whatever it was :) Any suggestions for changes would be appreciated if you have them. -Nathan Doug Gilbert P.S. I know Linux has stupid typedefs in its kernel and was hoping FreeBSD would be better. That was until I saw u_int64_t rather than the standard (and shorter) uint64_t CAM is old still, so I've tried to keep the existing style. Updates are probably a good idea. -Nathan ___ 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
svn merge to stable/10 has lotsa mergeinfo
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: sys
___
Added: svn:mergeinfo
Merged /head/sys:r256280,256291,256293-256294,256299,256302,256304,256308,256
321-256323,256325,256327-256328,256330-256331,256333-256335,256338,256341,256343
,256345,256347-256348,256350,256362,256365,256385,256389,256391,256423,256425,25
6440,256446,256450,256459,256467,256470,256477,256489,256498,256500-256502,25650
4,256533,256537,256540-256541,256544,256546,256548-256549,256551-256553,256555-2
56557,256570,256645-256646,256670,256682,256687,256689,256694,256709,256711,2567
13-256714,256716,256743-256744,256746,256750,256752-256753,256767,256769-256771,
256773,256775-256779,256788,256813,256827-256828,256832-256833,256835,256842,256
847-256848,256861,256865,256889,256911-256912,256915,256920,256925-256926,256931
,256934-256936,256951,256963,256968,256971-256972,256977-256978,257005,257007,25
7017,257038,257051,257057,257061,257065,257069-257072,257078-257079,257084,25709
2,257109,257138-257139,257142,257145-257151,257158-257159,257164,257168,257193,2
57206,257214,257216,257221,257234,257268,257272,257274,257287-257288,257304-2573
07,257329,257344-257345,257350,257359,257361,257364,257369,257377-257380,257382,
257388,257400,257402-257403,257421,257440,257490,257505,257534,257539,257542,257
555,257574,257583,257598,257633,257641,257654,257667-257668,257680,257694-257695
,257749,257754-257757,257769,257772,257780-257785,257787-257793,257795,257800-25
7801,257803-257804,257817,257819,257841-257845,257856,257858-257859,257862-25786
4,257869-257870,257872,257874,257876,257888,257915,257937-257939,257945,257996,2
58001,258016,258021,258029,258041-258043,258069,258086,258101,258122,258128,2581
35,258148-258150,258152-258156,258176,258178,258181,258187,258221,258224,258227-
258228,258235,258254,258262-258267,258276,258283,258294,258305,258307-258310,258
314,258317-258320,258345,258347-258348,258350,258353,258387-258388,258399,258425
,258432-258433,258441,258492,258495,258537,258549,258553,258570,258574,258588,25
8591,258660-258661,258664,258669,258689,258698,258714,258737,258758,258765,25878
6,258790,258796-258797,258830,258847,258853,258879,258914,258924,258941,259048,2
59053,259079,259083,259094,259103
Index: sys/fs/nfs/nfs_commonkrpc.c
===
--- sys/fs/nfs/nfs_commonkrpc.c (revision 259205)
+++ sys/fs/nfs/nfs_commonkrpc.c (working copy)
@@ -336,24 +336,25 @@
mtx_lock(nrp-nr_mtx);
if (nrp-nr_client != NULL) {
+ mtx_unlock(nrp-nr_mtx);
/*
* Someone else already connected.
*/
CLNT_RELEASE(client);
} else {
nrp-nr_client = client;
+ /*
+* Protocols that do not require connections may be optionally
+* left unconnected for servers that reply from a port other
+* than NFS_PORT.
+*/
+ if (nmp == NULL || (nmp-nm_flag NFSMNT_NOCONN) == 0) {
+ mtx_unlock(nrp-nr_mtx);
+ CLNT_CONTROL(client, CLSET_CONNECT, one);
+ } else
+ mtx_unlock(nrp-nr_mtx);
}
- /*
-* Protocols that do not require connections may be optionally left
-* unconnected for servers that reply from a port other than NFS_PORT.
-*/
- if (nmp == NULL || (nmp-nm_flag NFSMNT_NOCONN) == 0) {
- mtx_unlock(nrp-nr_mtx);
- CLNT_CONTROL(client, CLSET_CONNECT, one);
- } else {
- mtx_unlock(nrp-nr_mtx);
- }
/* Restore current thread's credentials. */
td-td_ucred = origcred;
___
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: svn merge to stable/10 has lotsa mergeinfo
On Tue, Dec 10, 2013 at 7:04 PM, Rick Macklem rmack...@uoguelph.ca 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 helpful to provide the exact commands you used. -- Eitan Adler ___ 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: svn merge to stable/10 has lotsa mergeinfo
Eitan Adler wrote: On Tue, Dec 10, 2013 at 7:04 PM, Rick Macklem rmack...@uoguelph.ca 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 helpful to provide the exact commands you used. Ok, thanks, rick -- Eitan Adler ___ 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: [CAM] Widening lun_id_t to 64-bits
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 supporting extended LUNs. No behavior is changed except that peripheral with very long LUNs that didn't work before will start working. Binary compatibility with old code is also kept. There is, however, a chance that some 3rd party software might be unhappy about the type widening, so I'd appreciate any testing results. Barring any issues, I will commit this on Friday. Interesting, Hannes Reinecke is trying to do something very similar in the Linux SCSI subsystem. His patch set today will be the third attempt in a year (by my count) and he might just get over the top this time. There is some support in my sg3_utils package for the way Linux is implementing 64 bit LUNs. The sg3_utils package also supports FreeBSD so I'm interested in what your mapping will be. Now, as you are no doubt aware, SCSI (www.t10.org and specifically sam5r15.pdf) does not have 64 bit LUNs, it has 8 byte LUNs in SCSI order (i.e. big endian). Given that major architectures like i386 and x86_64 are little endian, the mapping between a 64 bit integer in native form and an 8 byte SCSI LUN is a bit of a puzzle. That becomes a little harder when you try for low numbered integers representing the T10 3 bit LUNs (showing my age), 8 bit LUNs and 16 bit LUNs. Down to brass tacks: what exactly will a SCSI REPORT LUNS WELL KNOWN LOGICAL UNIT number [T10 (in hex): c1 01 00 00 00 00 00 00] be in one of your 64 bits LUNs? Will that be the same in little endian and big endian architectures? There is also the representation of that LUN in logs; for example lun=13907397124296802304 is not very intuitive. More examples would be great, perhaps from the 4, 6 and 8 byte extended logical unit addressing format. Robert Elliott who has been a T10 technical editor has written a paper on this subject but google fails me, perhaps someone else can supply the url. His advice was too late for Linux and perhaps it is already too late for FreeBSD. Doug Gilbert P.S. I know Linux has stupid typedefs in its kernel and was hoping FreeBSD would be better. That was until I saw u_int64_t rather than the standard (and shorter) uint64_t ___ 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: boot failure after upgrade to HEAD from svn: zfs i/o error - all block copies unavailable invalid format
Plugin the disk as usb disk to other freebsd11(vm) , dmesg info: ugen1.2: vendor 0x05e3 at usbus1 umass0: vendor 0x05e3 USB Storage, class 0/0, rev 2.00/0.09, addr 2 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: External SATA Storage 0009 Fixed Direct Access SCSI-0 device da1: Serial Number 0033 da1: 40.000MB/s transfers da1: 305245MB (625142444 512 byte sectors: 255H 63S/T 38913C) da1: quirks=0x2NO_6_BYTE GEOM_PART: integrity check failed (da1, GPT) GEOM_PART: integrity check failed (diskid/DISK-0033, GPT) 2013/12/11 乔楚 honestq...@gmail.com *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 stop at *mountfrom: *My FreeBSD version is -current.* *Before upgrade, svn version is r25906.* *After upgrade , svn version maybe r**259156.* *ZFS is root fs.* *How to fix it?* ___ 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
