Re: Missingly recognized ADA_Q_NCQ_TRIM_BROKEN for Crucial M550 MU02
Hi.
As I already added comment to Bug 210686, the proposed patch worked
fine for me.
The essential point of the patch is NOT using "*" in the middle.
This causes, for example, M550 SSDs 1TB model and others must be
treated separately as the proposed patch does.
CT256M550SSD1 -> Crucial CT???M550*
CT1000M550SSD1 -> Crucial CTM550*
To re-integrate these, wildcard processing in kernel needs to be
rewritten, maybe causing slightly larger kernel.
Re-confirming original codes, below would cause all SSDs starting
with "Crucial CT" except M500 MU07 (appeares before this) to be
recognized as ADA_Q_NCQ_TRIM_BROKEN.
{
/*
* Crucial M500 SSDs all other firmware
* NCQ Trim doesn't work
*/
{ T_DIRECT, SIP_MEDIA_FIXED, "*", "Crucial CT*M500*", "*" },
/*quirks*/ADA_Q_NCQ_TRIM_BROKEN
},
On Wed, 17 Aug 2016 10:00:28 +0900
Tomoaki AOKI wrote:
> Hi.
>
> On Tue, 16 Aug 2016 13:48:40 -0600
> Warner Losh wrote:
>
> > What does camcontrol devlist say? I'm guessing firmware MU02, but I
> > want to make sure...
>
> % camcontrol devlist
> at scbus0 target 0 lun 0 (ada0,pass0)
> at scbus1 target 0 lun 0
> (ada1,pass1)at scbus4 target 0 lun
> 0 (ses0,pass2)
>
> Above includes another drive and ses0.
> Another drive is recongized properly.
>
> ada1 at ahcich1 bus 0 scbus1 target 0 lun 0
> ada1: ACS-2 ATA SATA 3.x device
> ada1: Serial Number ***
> ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
> ada1: Command Queueing enabled
> ada1: 238475MB (488397168 512 byte sectors)
> ada1: quirks=0x3<4K,NCQ_TRIM_BROKEN>
> Steering write from 0 kBps to 30 kBps
>
> Samsung consumer SSD should have 4k and NCQ_TRIM_BROKEN quirk, and
> recognized so.
>
>
> > It shouldn't match this one. The MU07 exception works for my M500's,
> > so I'm confused...
>
> Me too very confused. :-(
> This shouldn't happen with this code path.
>
>
> > Please file a bugzilla ticket.
>
> Found already filed PR for other model while attempting to file one.
>
> Bug 210686 - NCQ_TRIM_BROKEN quirk mismatch
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210686
>
> Please work on it. (So do I.)
>
> I've not yet tested the proposed patch (found just now), but will test
> later and add feedback to it.
>
> >
> > Warner
> >
> > On Tue, Aug 16, 2016 at 8:01 AM, Tomoaki AOKI
> > wrote:
> > > Hi.
> > >
> > > I noticed that my Crucial M550 SSD (firmware MU02) is missingly
> > > recognized as quirk ADA_Q_NCQ_TRIM_BROKEN.
> > > If I understand the source (introduced first at r298002, before
> > > stable/11 branched) correctly, only firmware MU01 should be recognized
> > > so for the SSD model, so I have no idea why. :-(
> > >
> > > Below are the related portion of dmesg. stable/11 at r304189, amd64.
> > > (Built with options CAM_IOSCHED_DYNAMIC.)
> > >
> > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
> > > ada0: ACS-2 ATA SATA 3.x device
> > > ada0: Serial Number
> > > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
> > > ada0: Command Queueing enabled
> > > ada0: 976762MB (2000409264 512 byte sectors)
> > > ada0: quirks=0x2
> > > Steering write from 0 kBps to 30 kBps
> > >
> > > One thing to note: The SSD was shipped with MU01 and updated to MU02
> > > using CD image obtained from Crucial Japan website.
> > >
> > > Need Bugzilla ticket although it's not a severe problem (goes safer
> > > side, and easy to workaround via loader.conf)?
> > >
> > > --
> > > Tomoaki AOKI
> > ___
> > 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"
> >
>
>
> --
> Tomoaki AOKI
> ___
> 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"
>
--
青木 知明 [Tomoaki AOKI]
___
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: gfx-next update: drm-4.8-rc2 tagged in drm-next
Hello I'd like to know what 'IFCed to HEAD' means. I'm quite new to FreeBSD. Thank you for your work. Looking forward to running FreeBSD on my laptop with graphics. Thanks in advance. Tomoya On Tue, Aug 16, 2016 at 12:12:44AM -0700, Matthew Macy wrote: > As of this moment sys/dev/drm in the drm-next tree is sync with > https://github.com/torvalds/linux drivers/gpu/drm (albeit only for the subset > of drivers that FreeBSD supports - i915, radeon, and amdgpu). I feel this is > a bit of a milestone as it means that it is possible that in the future > graphics support on FreeBSD could proceed in lockstep with Linux. > > In addition I have IFCed both drm-next-4.6 and drm-next to HEAD as of today. > > Once I'm done working on Kaby Lake support I intend to get radeon and amdgpu > to the point where they work as well as i915. Following that we'll need to > spend some time resolving general correctness issues. > > -M > > ___ > freebsd-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" ___ 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: Missingly recognized ADA_Q_NCQ_TRIM_BROKEN for Crucial M550 MU02
Hi. On Tue, 16 Aug 2016 13:48:40 -0600 Warner Losh wrote: > What does camcontrol devlist say? I'm guessing firmware MU02, but I > want to make sure... % camcontrol devlist at scbus0 target 0 lun 0 (ada0,pass0) at scbus1 target 0 lun 0 (ada1,pass1)at scbus4 target 0 lun 0 (ses0,pass2) Above includes another drive and ses0. Another drive is recongized properly. ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ACS-2 ATA SATA 3.x device ada1: Serial Number *** ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada1: Command Queueing enabled ada1: 238475MB (488397168 512 byte sectors) ada1: quirks=0x3<4K,NCQ_TRIM_BROKEN> Steering write from 0 kBps to 30 kBps Samsung consumer SSD should have 4k and NCQ_TRIM_BROKEN quirk, and recognized so. > It shouldn't match this one. The MU07 exception works for my M500's, > so I'm confused... Me too very confused. :-( This shouldn't happen with this code path. > Please file a bugzilla ticket. Found already filed PR for other model while attempting to file one. Bug 210686 - NCQ_TRIM_BROKEN quirk mismatch https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210686 Please work on it. (So do I.) I've not yet tested the proposed patch (found just now), but will test later and add feedback to it. > > Warner > > On Tue, Aug 16, 2016 at 8:01 AM, Tomoaki AOKI > wrote: > > Hi. > > > > I noticed that my Crucial M550 SSD (firmware MU02) is missingly > > recognized as quirk ADA_Q_NCQ_TRIM_BROKEN. > > If I understand the source (introduced first at r298002, before > > stable/11 branched) correctly, only firmware MU01 should be recognized > > so for the SSD model, so I have no idea why. :-( > > > > Below are the related portion of dmesg. stable/11 at r304189, amd64. > > (Built with options CAM_IOSCHED_DYNAMIC.) > > > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > ada0: ACS-2 ATA SATA 3.x device > > ada0: Serial Number > > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > > ada0: Command Queueing enabled > > ada0: 976762MB (2000409264 512 byte sectors) > > ada0: quirks=0x2 > > Steering write from 0 kBps to 30 kBps > > > > One thing to note: The SSD was shipped with MU01 and updated to MU02 > > using CD image obtained from Crucial Japan website. > > > > Need Bugzilla ticket although it's not a severe problem (goes safer > > side, and easy to workaround via loader.conf)? > > > > -- > > Tomoaki AOKI > ___ > 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" > -- Tomoaki AOKI ___ 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: gfx-next update: drm-4.8-rc2 tagged in drm-next
Wow. This is incredibly welcome news. And very impressive! And there's not the slightest bit of 'bit' in this milestone :) Thanks a *lot* for your hard work! Mathias Am 16. August 2016 09:12:44 GMT+02:00, schrieb Matthew Macy : >As of this moment sys/dev/drm in the drm-next tree is sync with >https://github.com/torvalds/linux drivers/gpu/drm (albeit only for the >subset of drivers that FreeBSD supports - i915, radeon, and amdgpu). I >feel this is a bit of a milestone as it means that it is possible that >in the future graphics support on FreeBSD could proceed in lockstep >with Linux. > >In addition I have IFCed both drm-next-4.6 and drm-next to HEAD as of >today. > >Once I'm done working on Kaby Lake support I intend to get radeon and >amdgpu to the point where they work as well as i915. Following that >we'll need to spend some time resolving general correctness issues. > >-M > >___ >freebsd-...@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-x11 >To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" ___ 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: /head/sys/kern/kern_timeout.c breaks build on current amd64
Fixed in r304245. Thanks!
On Tue, Aug 16, 2016 at 3:52 PM, Manfred Antar wrote:
> New commit to current breaks build amd64:
>
> /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I.
> -I../../.. -I../../../contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS
> -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
> -MD -MF.depend.kern_timeout.o -MTkern_timeout.o -mcmodel=kernel
> -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables
> -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls
> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Winline -Wcast-qual -Wundef -Wno-pointer-sign
> -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
> -fdiagnostics-show-option -Wno-unknown-pragmas
> -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function
> -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx
> -std=iso9899:1999 ../../../kern/kern_timeout.c
> ../../../kern/kern_timeout.c:1064:56: error: use of undeclared identifier
> 'dir'
> if (cc_exec_waiting(cc, direct) || cc_exec_drain(cc, dir)) {
> ^
> 1 error generated.
> *** Error code 1
>
> Stop.
> make: stopped in /usr/src/sys/amd64/compile/pozo
>
> here is the commit:
> OLD
> NEW
> 1064
>
> if (cc_exec_waiting(cc, direct)) {>
>if (cc_exec_waiting(cc, direct) || cc_exec_drain(cc, dir)) {
>
>
>^^^
>
> I think it is just a typo if you change the dir to direct it compiles and
> boots fine.
>
>
>
> ___
> 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"
___
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"
/head/sys/kern/kern_timeout.c breaks build on current amd64
New commit to current breaks build amd64:
/usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I.
-I../../.. -I../../../contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS
-include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD
-MF.depend.kern_timeout.o -MTkern_timeout.o -mcmodel=kernel -mno-red-zone
-mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding
-fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx
-std=iso9899:1999 ../../../kern/kern_timeout.c
../../../kern/kern_timeout.c:1064:56: error: use of undeclared identifier 'dir'
if (cc_exec_waiting(cc, direct) || cc_exec_drain(cc, dir)) {
^
1 error generated.
*** Error code 1
Stop.
make: stopped in /usr/src/sys/amd64/compile/pozo
here is the commit:
OLD
NEW
1064
if (cc_exec_waiting(cc, direct)) {>
if (cc_exec_waiting(cc, direct) || cc_exec_drain(cc, dir)) {
^^^
I think it is just a typo if you change the dir to direct it compiles and boots
fine.
___
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: Somethign missing in my environment?
On 16-8-2016 22:33, Peter Jeremy wrote:
> On 2016-Aug-16 20:31:57 +0200, Willem Jan Withagen wrote:
>> I'm trying to compile world, but I keep getting:
>>
>> /usr/obj/usr/srcs/head/src/tmp/usr/lib/libgcc_s.so: undefined reference
>> to `__gxx_personality_v0'
>> cc: error: linker command failed with exit code 1 (use -v to see invocation)
>> *** [h_raw.full] Error code 1
>>
>> Even after refetching the complete tree.
>
> We need more context:
> - What SVN revision of (presumably) -current is this?
> - What architecture are you compiling on/for?
> - What do you have in /etc/make.conf and /etc/src.conf
> - What is your current environment?
> - What is the output leading up to that error (what is being built?
This afternoons svn co: Revision: 304191.
amd64
# cat /etc/make.conf
KERNCONF=GENERIC-NODEBUG
LOADER_ZFS_SUPPORT=true
WITH_ZFS=true
DOC_LANG= en_US.ISO_8859-1
BATCH=yes
WITHOUT_X11=yes
WITH_PKGNG=yes
WITHOUT_LOCALES=yes
MALLOC_PRODUCTION=yes
# cat /etc/src.conf
DEBUG_FLAGS=-g -O0
env:
PATH=/root/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:.
TERM=xterm
MAIL=/var/mail/root
LOGNAME=root
USER=root
USERNAME=root
HOME=/root
SHELL=/bin/tcsh
SUDO_COMMAND=/bin/tcsh
SUDO_USER=wjw
SUDO_UID=1000
SUDO_GID=1200
HOSTTYPE=FreeBSD
VENDOR=amd
OSTYPE=FreeBSD
MACHTYPE=x86_64
SHLVL=1
PWD=/usr/srcs/head/src
GROUP=wheel
HOST=freetest.digiware.nl
REMOTEHOST=opteronv6
PRINTER=ps
PERLLIB=/home/wjw/bin:/home/wjw/etc
TEX=/usr/local/share/texmf
MIBS=ALL
TITLE=%{\033]0;%m %n:%~\007%}
MANPATH=/usr/share/man:
And I'm running:
make -j8 buildworld
So getting a good target that give the error is hard.
So I continued with make -DNOCLEAN -DNO_CLEAN buildworld.
That gave:
===> lib/libc/tests/ssp (all)
(cd /usr/srcs/head/src/lib/libc/tests/ssp && DEPENDFILE=.depend.h_fgets
NO_SUBDIR=1 /usr/obj/usr/srcs/head/src/make.amd64/bmake -f
/usr/srcs/head/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=t
PROG=h_fgets )
(cd /usr/srcs/head/src/lib/libc/tests/ssp && DEPENDFILE=.depend.h_gets
NO_SUBDIR=1 /usr/obj/usr/srcs/head/src/make.amd64/bmake -f
/usr/srcs/head/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=t
PROG=h_gets )
(cd /usr/srcs/head/src/lib/libc/tests/ssp &&
DEPENDFILE=.depend.h_getcwd NO_SUBDIR=1
/usr/obj/usr/srcs/head/src/make.amd64/bmake -f
/usr/srcs/head/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=t
PROG=h_getcwd )
(cd /usr/srcs/head/src/lib/libc/tests/ssp &&
DEPENDFILE=.depend.h_memcpy NO_SUBDIR=1
/usr/obj/usr/srcs/head/src/make.amd64/bmake -f
/usr/srcs/head/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=t
PROG=h_memcpy )
(cd /usr/srcs/head/src/lib/libc/tests/ssp &&
DEPENDFILE=.depend.h_memmove NO_SUBDIR=1
/usr/obj/usr/srcs/head/src/make.amd64/bmake -f
/usr/srcs/head/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=t
PROG=h_memmove )
(cd /usr/srcs/head/src/lib/libc/tests/ssp &&
DEPENDFILE=.depend.h_memset NO_SUBDIR=1
/usr/obj/usr/srcs/head/src/make.amd64/bmake -f
/usr/srcs/head/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=t
PROG=h_memset )
(cd /usr/srcs/head/src/lib/libc/tests/ssp && DEPENDFILE=.depend.h_raw
NO_SUBDIR=1 /usr/obj/usr/srcs/head/src/make.amd64/bmake -f
/usr/srcs/head/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=t
PROG=h_raw )
cc -O2 -pipe -fstack-protector-all -Wstack-protector -fsanitize=bounds
-g -O0 -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter
-Qunused-arguments -o h_raw.full h_raw.o
/usr/obj/usr/srcs/head/src/tmp/usr/lib/libgcc_s.so: undefined reference
to `__gxx_personality_v0'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1
Hope that sheds a bit more light on this...
--WjW
___
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: Somethign missing in my environment?
On 2016-Aug-16 20:31:57 +0200, Willem Jan Withagen wrote: >I'm trying to compile world, but I keep getting: > >/usr/obj/usr/srcs/head/src/tmp/usr/lib/libgcc_s.so: undefined reference >to `__gxx_personality_v0' >cc: error: linker command failed with exit code 1 (use -v to see invocation) >*** [h_raw.full] Error code 1 > >Even after refetching the complete tree. We need more context: - What SVN revision of (presumably) -current is this? - What architecture are you compiling on/for? - What do you have in /etc/make.conf and /etc/src.conf - What is your current environment? - What is the output leading up to that error (what is being built? -- Peter Jeremy signature.asc Description: PGP signature
Re: Missingly recognized ADA_Q_NCQ_TRIM_BROKEN for Crucial M550 MU02
What does camcontrol devlist say? I'm guessing firmware MU02, but I want to make sure... It shouldn't match this one. The MU07 exception works for my M500's, so I'm confused... Please file a bugzilla ticket. Warner On Tue, Aug 16, 2016 at 8:01 AM, Tomoaki AOKI wrote: > Hi. > > I noticed that my Crucial M550 SSD (firmware MU02) is missingly > recognized as quirk ADA_Q_NCQ_TRIM_BROKEN. > If I understand the source (introduced first at r298002, before > stable/11 branched) correctly, only firmware MU01 should be recognized > so for the SSD model, so I have no idea why. :-( > > Below are the related portion of dmesg. stable/11 at r304189, amd64. > (Built with options CAM_IOSCHED_DYNAMIC.) > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x device > ada0: Serial Number > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 976762MB (2000409264 512 byte sectors) > ada0: quirks=0x2 > Steering write from 0 kBps to 30 kBps > > One thing to note: The SSD was shipped with MU01 and updated to MU02 > using CD image obtained from Crucial Japan website. > > Need Bugzilla ticket although it's not a severe problem (goes safer > side, and easy to workaround via loader.conf)? > > -- > Tomoaki AOKI ___ 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"
Somethign missing in my environment?
I'm trying to compile world, but I keep getting: /usr/obj/usr/srcs/head/src/tmp/usr/lib/libgcc_s.so: undefined reference to `__gxx_personality_v0' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [h_raw.full] Error code 1 Even after refetching the complete tree. Thanx for any suggestions, --WjW ___ 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"
Missingly recognized ADA_Q_NCQ_TRIM_BROKEN for Crucial M550 MU02
Hi. I noticed that my Crucial M550 SSD (firmware MU02) is missingly recognized as quirk ADA_Q_NCQ_TRIM_BROKEN. If I understand the source (introduced first at r298002, before stable/11 branched) correctly, only firmware MU01 should be recognized so for the SSD model, so I have no idea why. :-( Below are the related portion of dmesg. stable/11 at r304189, amd64. (Built with options CAM_IOSCHED_DYNAMIC.) ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 976762MB (2000409264 512 byte sectors) ada0: quirks=0x2 Steering write from 0 kBps to 30 kBps One thing to note: The SSD was shipped with MU01 and updated to MU02 using CD image obtained from Crucial Japan website. Need Bugzilla ticket although it's not a severe problem (goes safer side, and easy to workaround via loader.conf)? -- Tomoaki AOKI ___ 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: gfx-next update: drm-4.8-rc2 tagged in drm-next
On 16/08/2016 5:12 PM, Matthew Macy wrote: > As of this moment sys/dev/drm in the drm-next tree is sync with > https://github.com/torvalds/linux drivers/gpu/drm (albeit only for the subset > of drivers that FreeBSD supports - i915, radeon, and amdgpu). I feel this is > a bit of a milestone as it means that it is possible that in the future > graphics support on FreeBSD could proceed in lockstep with Linux. > > In addition I have IFCed both drm-next-4.6 and drm-next to HEAD as of today. > > Once I'm done working on Kaby Lake support I intend to get radeon and amdgpu > to the point where they work as well as i915. Following that we'll need to > spend some time resolving general correctness issues. > > -M > All of this is and means a huge deal for our users and us as a project, thank you to everyone on Team Graphics™ and every one else who has been involved for their ongoing effort. ___ 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: gfx-next update: drm-4.8-rc2 tagged in drm-next
On Tuesday, 16 August 2016, Matthew Macy wrote: > As of this moment sys/dev/drm in the drm-next tree is sync with > https://github.com/torvalds/linux drivers/gpu/drm (albeit only for the > subset of drivers that FreeBSD supports - i915, radeon, and amdgpu). I > feel this is a bit of a milestone as it means that it is possible that in > the future graphics support on FreeBSD could proceed in lockstep with Linux. > > In addition I have IFCed both drm-next-4.6 and drm-next to HEAD as of > today. > > Once I'm done working on Kaby Lake support I intend to get radeon and > amdgpu to the point where they work as well as i915. Following that we'll > need to spend some time resolving general correctness issues. > > -M > May I just say, congratulations on the great milestone, and thank you very much for your efforts! I owe you beer. Thanks, Ben -- -- From: Benjamin Woods woods...@gmail.com ___ 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"
gfx-next update: drm-4.8-rc2 tagged in drm-next
As of this moment sys/dev/drm in the drm-next tree is sync with https://github.com/torvalds/linux drivers/gpu/drm (albeit only for the subset of drivers that FreeBSD supports - i915, radeon, and amdgpu). I feel this is a bit of a milestone as it means that it is possible that in the future graphics support on FreeBSD could proceed in lockstep with Linux. In addition I have IFCed both drm-next-4.6 and drm-next to HEAD as of today. Once I'm done working on Kaby Lake support I intend to get radeon and amdgpu to the point where they work as well as i915. Following that we'll need to spend some time resolving general correctness issues. -M ___ 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"
