Re: ale(4) cannot negotiate as GigE
On Tue, Mar 05, 2013 at 04:43:15PM +0900, YongHyeon PYUN wrote: Could you disable WOL before rebooting your box? # ifconfig ale0 -wol # reboot It came up as 100baseTX. :( You don't use any manual link configuration, right? Right, everything is auto (that is, the defaults). When you see the controller established a 100Mbps link, how about restarting auto-negotiation? Does that also result in 100Mbps link? # ifconfig ale0 media auto # ifconfig ale0 | egrep -v ether\|inet ale0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c319aTXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active Tried a few times, no difference. ./danfe ___ 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: access to hard drives is blocked by writes to a flash drive
On 5 Mar, Poul-Henning Kamp wrote: Content-Type: text/plain; charset=ISO-8859-1 In message 201303050519.r255jbau012...@gw.catspoiler.org, Don Lewis writes: That's been my opinion for a long time as well, though I think it would be better to have one thread per device to avoid syncer threads for multiple partitions on the same drive all contending for the same actuator. That would require that you move the syncer to the bottom of GEOM and initiate syncs by upcalls to the consumers above. But how does that work in the case of a mirrored drive ? ... or even worse, raid5. Doesn't sound like a good idea to me. I wasn't advocating anything like that, but something more like this example: When we first boot, we mount /dev/ada0s1a to /. We query geom to find the underlying device name for ada0s1a and find that it is ada0. We find that we don't have a syncer thread for ada0, so we start one and attach the syncer worklist for / to the thread. Next we mount /dev/ada0s1h to /home. We query geom to find the underlying device name and find that it is also ada0. Since there is already a syncer thread for ada0, we just attach the /home worklist to this thread. Next we mount /dev/ada1s1a to /somewhere. We query geom, find that there is no syncer thread for ada1, so we start one and attach the worklist for /somewhere to this thread. For composite devices such as mirrors, using the first underlying device is probably a reasonable choice. For more complicated cases, or to override the default, the syncer thread could be specified as a mount option. Each time it woke up, each syncer thread would walk through its list of worklists, and for each worklist it would fsync all the vnodes in the current bucket. Multiple threads would allow us to better exploit the parallelism provided by the hardware and prevent a slow drive from impacting the performance of the other drives in the system. It would also allow us to have different sync-intervals for different filesystems. Yup, you could override the system default intervals using mount options. ___ 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: access to hard drives is blocked by writes to a flash drive
In message 201303050840.r258egag012...@gw.catspoiler.org, Don Lewis writes: For composite devices such as mirrors, using the first underlying device is probably a reasonable choice. For more complicated cases, or to override the default, the syncer thread could be specified as a mount option. I doubt that will be any better than what we have today. I think it is a much better idea to have the syncer monitor bio write latency and adjust accordingly. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: serial console not accepting input?
On Mar 4, 2013, at 20:59, Doug Ambrisko ambri...@ambrisko.com wrote:
Try to do a {Ctrl}D to see if works. We've seen that the TX on reset
hangs but input works fine. I'm not sure if we ran into this with
uart(4) but had a problem with sio(4).
No change.
Lars
___
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: ale(4) cannot negotiate as GigE
On Tue, Mar 05, 2013 at 08:06:20AM +, Alexey Dokuchaev wrote: On Tue, Mar 05, 2013 at 04:43:15PM +0900, YongHyeon PYUN wrote: Could you disable WOL before rebooting your box? # ifconfig ale0 -wol # reboot It came up as 100baseTX. :( You don't use any manual link configuration, right? Right, everything is auto (that is, the defaults). When you see the controller established a 100Mbps link, how about restarting auto-negotiation? Does that also result in 100Mbps link? # ifconfig ale0 media auto # ifconfig ale0 | egrep -v ether\|inet ale0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c319aTXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active Tried a few times, no difference. Hmm, Does the switch support EEE feature? If yes, would you try disabling it? ./danfe ___ 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: ale(4) cannot negotiate as GigE
On Tue, Mar 05, 2013 at 05:57:03PM +0900, YongHyeon PYUN wrote: Hmm, Does the switch support EEE feature? If yes, would you try disabling it? I do not think it [1] does; plus I cannot do much about this switch, as I'm pretty far away from it right now. ./danfe [1] http://netgear.com/home/products/switches-and-access-points/unmanaged-switches/GS608.aspx (got it about 4 years ago) ___ 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
r247829: dbus fails to start. portmaster SIGNAL 13 when doing extraction
On FreeBSD 10.0-CURRENT #3 r247829: Tue Mar 5 08:12:19 CET 2013/amd64 I run into a mess and can not figure out what happens. Suddenly, after upgrading, buildworld etc., dbus fails to start so X11 is without mouse. Trying to rebuild the port dbus fails in a SIGNAL 13 while [do-extract]. This is weird. I can not extract and rebuild ports anymore, every port I try to rebuild with portmaster fails with the very same fault: = SHA256 Checksum OK for dbus-1.4.14.tar.gz. *** [do-extract] Signal 13 Stop in /usr/ports/devel/dbus. === make failed for devel/dbus === Aborting update What is going on? Why is that? -- ___ 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: access to hard drives is blocked by writes to a flash drive
On 5 Mar, Poul-Henning Kamp wrote: In message 201303050840.r258egag012...@gw.catspoiler.org, Don Lewis writes: For composite devices such as mirrors, using the first underlying device is probably a reasonable choice. For more complicated cases, or to override the default, the syncer thread could be specified as a mount option. I doubt that will be any better than what we have today. I'm thinking of the case where ada0s1a and ada1s1a are mirrored, ada0s2b and ada1s2b are mirrored, etc. Or ada0 and ada1 are mirrored and then the mirror is partitioned. We don't want two syncer threads simultaneously trying to fsync files on the outer tracks and the inner tracks. If we just create a syncer thread for ada0, it will fsync the files on the outer tracks first and then go on to the inner tracks, avoiding lots of long seeks. I think it is a much better idea to have the syncer monitor bio write latency and adjust accordingly. That's a good idea as well, but that's also something that is global to each device. ___ 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: r247829: dbus fails to start. portmaster SIGNAL 13 when doing extraction
On 2013-03-05 10:16, Hartmann, O. wrote: On FreeBSD 10.0-CURRENT #3 r247829: Tue Mar 5 08:12:19 CET 2013/amd64 I run into a mess and can not figure out what happens. Suddenly, after upgrading, buildworld etc., dbus fails to start so X11 is without mouse. Trying to rebuild the port dbus fails in a SIGNAL 13 while [do-extract]. This is weird. I can not extract and rebuild ports anymore, every port I try to rebuild with portmaster fails with the very same fault: = SHA256 Checksum OK for dbus-1.4.14.tar.gz. *** [do-extract] Signal 13 This is SIGPIPE, so maybe your tar is broken? What happens if you manually extract that tar.gz file? ___ 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: r247829: dbus fails to start. portmaster SIGNAL 13 when doing extraction
On 03/05/13 10:33, Dimitry Andric wrote: On 2013-03-05 10:16, Hartmann, O. wrote: On FreeBSD 10.0-CURRENT #3 r247829: Tue Mar 5 08:12:19 CET 2013/amd64 I run into a mess and can not figure out what happens. Suddenly, after upgrading, buildworld etc., dbus fails to start so X11 is without mouse. Trying to rebuild the port dbus fails in a SIGNAL 13 while [do-extract]. This is weird. I can not extract and rebuild ports anymore, every port I try to rebuild with portmaster fails with the very same fault: = SHA256 Checksum OK for dbus-1.4.14.tar.gz. *** [do-extract] Signal 13 This is SIGPIPE, so maybe your tar is broken? What happens if you manually extract that tar.gz file? I'm now with FreeBSD 10.0-CURRENT #0 r247832: Tue Mar 5 10:16:41 CET 2013/amd64. The buildworld is performed with CLANG - as it should be and for most ports, I use also CLANG. Just for the record. Now, after the buildworld and install, after the reboot the X11 server/xdm isn't even coming up again! Looking at /usr/src/UPDATING says I should recompile kernel modules or ports that provide such. With buildworld I have done so, all other rebuild is impossible due to a system failure as reported. I tried extract with tar (which tar provides /usr/bin/tar) the port devel/dbus - I can extract. I tried gtar (which gtar: /usr/local/bin/gtar). If tar is broken, then tar on CURRENT is broken. At the moment, I'm floating liek a dead man in the water. ___ 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: r247829: dbus fails to start. portmaster SIGNAL 13 when doing extraction
On 03/05/13 10:33, Dimitry Andric wrote: On 2013-03-05 10:16, Hartmann, O. wrote: On FreeBSD 10.0-CURRENT #3 r247829: Tue Mar 5 08:12:19 CET 2013/amd64 I run into a mess and can not figure out what happens. Suddenly, after upgrading, buildworld etc., dbus fails to start so X11 is without mouse. Trying to rebuild the port dbus fails in a SIGNAL 13 while [do-extract]. This is weird. I can not extract and rebuild ports anymore, every port I try to rebuild with portmaster fails with the very same fault: = SHA256 Checksum OK for dbus-1.4.14.tar.gz. *** [do-extract] Signal 13 This is SIGPIPE, so maybe your tar is broken? What happens if you manually extract that tar.gz file? well, since I can't do portmaster on EVERY FreeBSD 10.0-CURRENT I have around (three boxes, different types of hardware but the same revision of sources as from today - and buildworld/kernel of course) I guess this is a major damage. Is there a way how I can trace the make extract task in the port's directory? I can manually untar each tarball, but while doing make extract I always get this === dbus-1.4.14_4 depends on file: /usr/local/sbin/pkg - found === Extracting for dbus-1.4.14_4 = SHA256 Checksum OK for dbus-1.4.14.tar.gz. *** [do-extract] Signal 13 (devel/dbus is an example, it happens to ALL ports). Oliver ___ 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
r247835: drm2 code breaks buildkernel
On r247835 build kernel fails: cc -O2 -pipe -O3 -pipe -march=native -O3 -march=native -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GATE/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/GATE -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_ioctl.c /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_global.c:63:27: error: unused variable 'item' [-Werror,-Wunused-variable] struct drm_global_item *item = glob[i]; ^ 1 error generated. *** [drm_global.o] Error code 1 Just for the record, oh ___ 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: r247835: drm2 code breaks buildkernel
On 05.03.2013 11:20, Hartmann, O. wrote: On r247835 build kernel fails: (...) /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_global.c:63:27: error: unused variable 'item' [-Werror,-Wunused-variable] struct drm_global_item *item = glob[i]; Could you try the patch below? http://people.freebsd.org/~dumbbell/radeonkms/drm_global-unused-variable.a.patch -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r247835: drm2 code breaks buildkernel
On 03/05/13 11:46, Jean-Sébastien Pédron wrote: On 05.03.2013 11:20, Hartmann, O. wrote: On r247835 build kernel fails: (...) /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_global.c:63:27: error: unused variable 'item' [-Werror,-Wunused-variable] struct drm_global_item *item = glob[i]; Could you try the patch below? http://people.freebsd.org/~dumbbell/radeonkms/drm_global-unused-variable.a.patch Got new sources, I'm at FreeBSD 10.0-CURRENT #1 r247839: Tue Mar 5 12:28:12 CET 2013/amd64 and the kernel builds normal again. Thanks, Oliver ___ 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: r247835: drm2 code breaks buildkernel
On Tue, Mar 05, 2013 at 12:59:50PM +0100, Hartmann, O. wrote: Could you try the patch below? http://people.freebsd.org/~dumbbell/radeonkms/drm_global-unused-variable.a.patch Got new sources, I'm at FreeBSD 10.0-CURRENT #1 r247839: Tue Mar 5 12:28:12 CET 2013/amd64 and the kernel builds normal again. I still see kernel build failure with and without the above patch. Script started on Tue Mar 5 07:28:11 2013 root@nucleus:/usr/src # svnversion 247839 root@nucleus:/usr/src # time make -s -j4 KERNCONF=NUCLEUS buildkernel -- Kernel build for NUCLEUS started on Tue Mar 5 07:28:20 EST 2013 -- === NUCLEUS -- stage 1: configuring the kernel -- Kernel build directory is /usr/obj/usr/src/sys/NUCLEUS Don't forget to do ``make cleandepend make depend'' -- stage 2.1: cleaning up the object tree -- === drm2/drm2 (cleandir) === drm2/i915kms (cleandir) === opensolaris (cleandir) === zfs (cleandir) -- stage 2.2: rebuilding the object tree -- === drm2/drm2 (obj) === drm2/i915kms (obj) === opensolaris (obj) === zfs (obj) -- stage 2.3: build tools -- -- stage 3.1: making dependencies -- === drm2/drm2 (depend) === drm2/i915kms (depend) === opensolaris (depend) === zfs (depend) -- stage 3.2: building everything -- === drm2/drm2 (all) In file included from /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_lock.c:42: @/dev/drm2/ttm/ttm_lock.h:208: warning: redundant redeclaration of 'ttm_write_unlock' [-Wredundant-decls] @/dev/drm2/ttm/ttm_lock.h:134: warning: previous declaration of 'ttm_write_unlock' was here @/dev/drm2/ttm/ttm_lock.h:220: warning: redundant redeclaration of 'ttm_write_lock' [-Wredundant-decls] @/dev/drm2/ttm/ttm_lock.h:146: warning: previous declaration of 'ttm_write_lock' was here /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:122: warning: declaration does not declare anything /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:123: warning: declaration does not declare anything /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c: In function 'ttm_get_pool': /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:280: error: 'struct ttm_pool_manager' has no member named 'pools' /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c: In function 'ttm_pool_get_num_unused_pages': /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:391: error: 'struct ttm_pool_manager' has no member named 'pools' /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c: In function 'ttm_pool_mm_shrink': /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:413: error: 'struct ttm_pool_manager' has no member named 'pools' /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c: In function 'ttm_page_alloc_init': /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:786: error: 'struct ttm_pool_manager' has no member named 'wc_pool' /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:787: error: 'struct ttm_pool_manager' has no member named 'uc_pool' /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:788: error: 'struct ttm_pool_manager' has no member named 'wc_pool_dma32' /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:790: error: 'struct ttm_pool_manager' has no member named 'uc_pool_dma32' /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c: In function 'ttm_page_alloc_fini': /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:811: error: 'struct ttm_pool_manager' has no member named 'pools' *** [ttm_page_alloc.o] Error code 1 1 error *** [all] Error code 2 1 error *** [modules-all] Error code 2 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error 22.434u 9.092s 0:22.11 142.5% 6476+1023k 109+98423io 6pf+0w root@nucleus:/usr/src # ^D Script done on Tue Mar 5 07:28:47 2013 Glen pgpEW4aZZWVjx.pgp Description: PGP signature
Re: r247835: drm2 code breaks buildkernel
On 05.03.2013 13:30, Glen Barber wrote:
dev/drm2/ttm/ttm_lock.h:208: warning: redundant redeclaration of
'ttm_write_unlock' [-Wredundant-decls]
dev/drm2/ttm/ttm_lock.h:134: warning: previous declaration of
'ttm_write_unlock' was here
dev/drm2/ttm/ttm_lock.h:220: warning: redundant redeclaration of
'ttm_write_lock' [-Wredundant-decls]
dev/drm2/ttm/ttm_lock.h:146: warning: previous declaration of
'ttm_write_lock' was here
Those redundant declarations weren't spotted by clang.
Konstantin, would you like me to commit the fix for this? And we need to
upstream it too.
dev/drm2/ttm/ttm_page_alloc.c:122: warning: declaration does not declare
anything
dev/drm2/ttm/ttm_page_alloc.c:123: warning: declaration does not declare
anything
These errors and the following are caused by unnamed structs and unions
inside another struct:
struct ttm_pool_manager {
...
union {
struct ttm_page_poolpools[NUM_POOLS];
struct {
...
} ;
};
};
With default options, clang accepts this but apparently, not gcc.
I would like an opinion from the toolchain gurus, because I don't know
what's the proper way to fix this one.
J.R. Oldroyd CC'd, because he started to work on radeonkms backport to 9
and faced exactly those issues.
--
Jean-Sébastien Pédron
signature.asc
Description: OpenPGP digital signature
Re: r247835: drm2 code breaks buildkernel
On Tue, 05 Mar 2013 15:13:12 +0100 Jean-Sébastien Pédron dumbb...@freebsd.org
wrote:
On 05.03.2013 13:30, Glen Barber wrote:
dev/drm2/ttm/ttm_lock.h:208: warning: redundant redeclaration of
'ttm_write_unlock' [-Wredundant-decls]
dev/drm2/ttm/ttm_lock.h:134: warning: previous declaration of
'ttm_write_unlock' was here
dev/drm2/ttm/ttm_lock.h:220: warning: redundant redeclaration of
'ttm_write_lock' [-Wredundant-decls]
dev/drm2/ttm/ttm_lock.h:146: warning: previous declaration of
'ttm_write_lock' was here
Those redundant declarations weren't spotted by clang.
Konstantin, would you like me to commit the fix for this? And we need to
upstream it too.
A fix for these is in my big get it to compile patch that I emailed
you both the other day.
dev/drm2/ttm/ttm_page_alloc.c:122: warning: declaration does not declare
anything
dev/drm2/ttm/ttm_page_alloc.c:123: warning: declaration does not declare
anything
These errors and the following are caused by unnamed structs and unions
inside another struct:
struct ttm_pool_manager {
...
union {
struct ttm_page_poolpools[NUM_POOLS];
struct {
...
} ;
};
};
With default options, clang accepts this but apparently, not gcc.
Experimentation shows that this warning is triggered because we use
-std=iso9899:1999. It can be turned off again by adding --ms-extensions
too.
Alternatively, my big patch replaces all these anon unions with
named ones. There are lots of these in this code, though. Doing
this adds lots of patch bloat.
I would like an opinion from the toolchain gurus, because I don't know
what's the proper way to fix this one.
J.R. Oldroyd CC'd, because he started to work on radeonkms backport to 9
and faced exactly those issues.
There is a further problem not mentioned here. Three of the files
make use of a pointer to a volatile int but later cast this to a
(void *). Because we also have -Wcast-qual, this cast triggers
cast discards qualifier on pointer target type warnings and because
of -Werror, this then aborts. What's the best way to fix that?
-jr
signature.asc
Description: PGP signature
drm GPU hung, resume no longer working
Hi, I am running: FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #87 r247546: Fri Mar 1 13:15:42 EST 2013 root@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64 Sometime very recently, resume has stopped working. I can ssh to the machine when it resumes, and I do see my background image on resume, but once the screen goes into locked mode (xscreensaver), I cannot get back to a working state without reboot. syslog reports: Mar 5 09:21:33 nucleus kernel: error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 5 09:21:33 nucleus kernel: info: [drm] capturing error event; look for more information in sysctl hw.dri.0.info.i915_error_state dmesg says: uhub2: 2 ports with 2 removable, self powered ugen0.2: vendor 0x8087 at usbus0 uhub3: vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2 on usbus0 ugen2.2: vendor 0x8087 at usbus2 uhub4: vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2 on usbus2 uhub3: 6 ports with 6 removable, self powered uhub4: 6 ports with 6 removable, self powered ugen0.3: Azurewave at usbus0 error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung info: [drm] capturing error event; look for more information in sysctl hw.dri.0.info.i915_error_state hw.dri.0.info.i915_error_state output is at: http://people.freebsd.org/~gjb/i915.sysctl.txt Any thoughts on how to debug this further? Thanks. Glen pgpbCPnZr6QdJ.pgp Description: PGP signature
Re: r247835: drm2 code breaks buildkernel
On 05.03.2013 15:54, J.R. Oldroyd wrote: A fix for these is in my big get it to compile patch that I emailed you both the other day. Sorry, I didn't take the time to read it yet :-/ dev/drm2/ttm/ttm_page_alloc.c:122: warning: declaration does not declare anything dev/drm2/ttm/ttm_page_alloc.c:123: warning: declaration does not declare anything Experimentation shows that this warning is triggered because we use -std=iso9899:1999. It can be turned off again by adding --ms-extensions too. Alternatively, my big patch replaces all these anon unions with named ones. There are lots of these in this code, though. Doing this adds lots of patch bloat. Yes, the flag is preferable. I didn't have the time to test it earlier either, until now. I confirm that it works with both clang and gcc. There is a further problem not mentioned here. Three of the files make use of a pointer to a volatile int but later cast this to a (void *). Because we also have -Wcast-qual, this cast triggers cast discards qualifier on pointer target type warnings and because of -Werror, this then aborts. What's the best way to fix that? Those warnings are in the radeon driver, not ttm, aren't they? At least, the build finishes properly on my computer with gcc and clang with just -fms-extensions. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: drm GPU hung, resume no longer working
On 05.03.2013 16:07, Glen Barber wrote: error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung info: [drm] capturing error event; look for more information in sysctl hw.dri.0.info.i915_error_state hw.dri.0.info.i915_error_state output is at: http://people.freebsd.org/~gjb/i915.sysctl.txt It won't help much, but rpaulo@ posted a mail with a similar dmesg but different trigger on freebsd-x11@: http://lists.freebsd.org/pipermail/freebsd-x11/2013-March/012862.html -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r247835: drm2 code breaks buildkernel
On Tue, Mar 05, 2013 at 03:13:12PM +0100, Jean-S?bastien P?dron wrote:
On 05.03.2013 13:30, Glen Barber wrote:
dev/drm2/ttm/ttm_lock.h:208: warning: redundant redeclaration of
'ttm_write_unlock' [-Wredundant-decls]
dev/drm2/ttm/ttm_lock.h:134: warning: previous declaration of
'ttm_write_unlock' was here
dev/drm2/ttm/ttm_lock.h:220: warning: redundant redeclaration of
'ttm_write_lock' [-Wredundant-decls]
dev/drm2/ttm/ttm_lock.h:146: warning: previous declaration of
'ttm_write_lock' was here
Those redundant declarations weren't spotted by clang.
Konstantin, would you like me to commit the fix for this? And we need to
upstream it too.
I am somewhat sceptical about upstreaming. I reported a real bug in the
ttm_lock with the trivial fix when I read the code for porting. Bug was
confirmed by Linux people, but no action was taken.
dev/drm2/ttm/ttm_page_alloc.c:122: warning: declaration does not declare
anything
dev/drm2/ttm/ttm_page_alloc.c:123: warning: declaration does not declare
anything
These errors and the following are caused by unnamed structs and unions
inside another struct:
struct ttm_pool_manager {
...
union {
struct ttm_page_poolpools[NUM_POOLS];
struct {
...
} ;
};
};
With default options, clang accepts this but apparently, not gcc.
I would like an opinion from the toolchain gurus, because I don't know
what's the proper way to fix this one.
J.R. Oldroyd CC'd, because he started to work on radeonkms backport to 9
and faced exactly those issues.
The patch below is supposed to fix double declaration (it is pathetic that
clang silently accepts this, while issuing countless useless warnings).
Also there is a usual workaround for the anonimous union/struct issue.
Glen neglected to even mention that he used gcc (is it true ?), as well
as to show the command line invocation of the compiler. Hopefully the
patch helps.
diff --git a/sys/dev/drm2/ttm/ttm_lock.h b/sys/dev/drm2/ttm/ttm_lock.h
index ac8159e..6d45457 100644
--- a/sys/dev/drm2/ttm/ttm_lock.h
+++ b/sys/dev/drm2/ttm/ttm_lock.h
@@ -125,27 +125,6 @@ extern int ttm_read_lock(struct ttm_lock *lock, bool
interruptible);
extern int ttm_read_trylock(struct ttm_lock *lock, bool interruptible);
/**
- * ttm_write_unlock
- *
- * @lock: Pointer to a struct ttm_lock
- *
- * Releases a write lock.
- */
-extern void ttm_write_unlock(struct ttm_lock *lock);
-
-/**
- * ttm_write_lock
- *
- * @lock: Pointer to a struct ttm_lock
- * @interruptible: Interruptible sleeping while waiting for a lock.
- *
- * Takes the lock in write mode.
- * Returns:
- * -ERESTARTSYS If interrupted by a signal and interruptible is true.
- */
-extern int ttm_write_lock(struct ttm_lock *lock, bool interruptible);
-
-/**
* ttm_lock_downgrade
*
* @lock: Pointer to a struct ttm_lock
diff --git a/sys/dev/drm2/ttm/ttm_page_alloc.c
b/sys/dev/drm2/ttm/ttm_page_alloc.c
index ffc8483..9a30a46 100644
--- a/sys/dev/drm2/ttm/ttm_page_alloc.c
+++ b/sys/dev/drm2/ttm/ttm_page_alloc.c
@@ -113,16 +113,22 @@ struct ttm_pool_manager {
struct ttm_pool_optsoptions;
union {
- struct ttm_page_poolpools[NUM_POOLS];
- struct {
- struct ttm_page_poolwc_pool;
- struct ttm_page_pooluc_pool;
- struct ttm_page_poolwc_pool_dma32;
- struct ttm_page_pooluc_pool_dma32;
- } ;
- };
+ struct ttm_page_poolu_pools[NUM_POOLS];
+ struct _utag {
+ struct ttm_page_poolu_wc_pool;
+ struct ttm_page_poolu_uc_pool;
+ struct ttm_page_poolu_wc_pool_dma32;
+ struct ttm_page_poolu_uc_pool_dma32;
+ } _ut;
+ } _u;
};
+#definepools _u.u_pools
+#definewc_pool _u._ut.u_wc_pool
+#defineuc_pool _u._ut.u_uc_pool
+#definewc_pool_dma32 _u._ut.u_wc_pool_dma32
+#defineuc_pool_dma32 _u._ut.u_uc_pool_dma32
+
MALLOC_DEFINE(M_TTM_POOLMGR, ttm_poolmgr, TTM Pool Manager);
static void
pgpOksjQgbMmY.pgp
Description: PGP signature
Re: r247835: drm2 code breaks buildkernel
On Tue, Mar 05, 2013 at 05:37:36PM +0200, Konstantin Belousov wrote: Glen neglected to even mention that he used gcc (is it true ?), as well as to show the command line invocation of the compiler. Hopefully the patch helps. Yes, I am using gcc. I'll try your patch and report back. Glen pgpkzfwha0Hcr.pgp Description: PGP signature
Re: r247835: drm2 code breaks buildkernel
On Tue, Mar 05, 2013 at 10:48:31AM -0500, Glen Barber wrote: On Tue, Mar 05, 2013 at 05:37:36PM +0200, Konstantin Belousov wrote: Glen neglected to even mention that he used gcc (is it true ?), as well as to show the command line invocation of the compiler. Hopefully the patch helps. Yes, I am using gcc. I'll try your patch and report back. This patch does fix the build for me. Glen pgp_YQSt6ijvd.pgp Description: PGP signature
Re: access to hard drives is blocked by writes to a flash drive
On Mon, 2013-03-04 at 21:27 -0800, Don Lewis wrote: On 4 Mar, Ian Lepore wrote: On Sun, 2013-03-03 at 19:01 -0800, Don Lewis wrote: On 3 Mar, Poul-Henning Kamp wrote: For various reasons (see: Lemming-syncer) FreeBSD will block all I/O traffic to other disks too, when these pileups gets too bad. The Lemming-syncer problem should have mostly been fixed by 231160 in head (231952 in stable/9 and 231967 in stable/8) a little over a year ago. The exceptions are atime updates, mmaped files with dirty pages, and quotas. Under certain workloads I still notice periodic bursts of seek noise. After thinking about it for a bit, I suspect that it could be atime updates, but I haven't tried to confirm that. When using TCQ or NCQ, perhaps we should limit the number of outstanding writes per device to leave some slots open for reads. We should probably also prioritize reads over writes unless we are under memory pressure. Then either those changes didn't have the intended effect, or the problem we're seeing with lack of system responsiveness when there's a large backlog of writes to a slow device is not the lemming-syncer problem. It's also not a lack of TCQ/NCQ slots, given that no such thing exists with SD card IO. When this is going on, the process driving the massive output spends almost all its time in a wdrain wait, and if you try to launch an app that isn't already in cache, a siginfo generally shows it to be in a getblk wait. If your only drive is a single SD card, then you're pretty much hosed when I/O is blocked because the SD card is doing an erase. It can only handle one command at a time, and if a write blocks, there's nothing that we can do to get it to execute a read until it is done with the write command that it is hung up on. I'm not familiar with the lower layers, but things might be less bad if read ops can jump ahead and get sent to the drive before any queued writes. Yes, but an erase-block operation on a nand flash takes on the order of 500uS, not 8-10 seconds, which is the kind of interactive non-responsiveness you experience in these situations. The very nature of SD cards is one operation at a time, so no internal operation queueing is in play to explain the long (apparent) hangs. I've debated playing with the bio work loop in mmcsd to see if moving reads ahead of writes was helpful, but that seems like a dangerous path to go down without some mitigation strategy to ensure that writes go through eventually. That seems especially important when you consider that writes may be necessary to free up memory to un-wedge other things that are waiting. (Yeah, people don't often use sd cards as swap storage, but I've done so in a pinch.) All in all, I've never pursued it because it feels like the wrong layer to address the problem at. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r247835: drm2 code breaks buildkernel
On Tue, Mar 05, 2013 at 10:54:29AM -0500, Glen Barber wrote: On Tue, Mar 05, 2013 at 10:48:31AM -0500, Glen Barber wrote: On Tue, Mar 05, 2013 at 05:37:36PM +0200, Konstantin Belousov wrote: Glen neglected to even mention that he used gcc (is it true ?), as well as to show the command line invocation of the compiler. Hopefully the patch helps. Yes, I am using gcc. I'll try your patch and report back. This patch does fix the build for me. Thank you. pgpWHR3l_KlQF.pgp Description: PGP signature
Re: access to hard drives is blocked by writes to a flash drive
On Mon, 2013-03-04 at 21:33 -0800, Don Lewis wrote: On 4 Mar, Ian Lepore wrote: On Sun, 2013-03-03 at 20:28 +, Steven Hartland wrote: - Original Message - From: Ian Lepore i...@freebsd.org To: Poul-Henning Kamp p...@phk.freebsd.dk Cc: deeptech71 deeptec...@gmail.com; freebsd-current@FreeBSD.org; Peter Jeremy pe...@rulingia.com Sent: Sunday, March 03, 2013 1:54 PM Subject: Re: access to hard drives is blocked by writes to a flash drive On Sun, 2013-03-03 at 13:35 +, Poul-Henning Kamp wrote: Content-Type: text/plain; charset=ISO-8859-1 In message 1362317291.1195.216.ca...@revolution.hippie.lan, Ian Lepore writes : I run into this behavior all the time too, mostly on arm systems that have an sd card or usb thumb driver as their main/only drive. This is really a FAQ and I belive I have answered it N times already: There are, broadly speaking, two classes of flash-storage: Camera-grade and the real thing. Camera-grade have a very limited Flash adaptation layer which typically only can hold one flash-block open for writing at a time, and is typically found in CF and SD cards, USB sticks etc. Some of them gets further upset if the filesystem is not the FAT they expect, because they implement M-Systems (patented) trick with monitoring block deletes in FAT to simulate a TRIM facility. A number of products exist with such designs, typically a CF-style, is put behind a SATA-PATA bridge and sold as 2.5 SSD SATA devices. Transcend have done this for instance. If you use this class of devices for anything real, gstat will show you I/O write-times of several seconds in periodic pile-ups, even 100 seconds if you are doing something heavy. For various reasons (see: Lemming-syncer) FreeBSD will block all I/O traffic to other disks too, when these pileups gets too bad. Hmmm, so the problem has been known and unfixed for 10 years. That's not encouraging. One of the messages in the lemming-syncer mail thread might explain why I've been seeing this a lot lately in hobbyist work, but not so much at $work where we use sd cards heavily... we use very short syncer timeouts on SD and CF storage at $work: kern.metadelay: 3 kern.dirdelay: 4 kern.filedelay: 5 I might play with similar settings on some of my arm boards here. Interesting, are these relevant for all filesystems e.g. ZFS? Regards Steve I'm not sure, I know almost nothing about zfs. I do know we used those tunings for a specific reason and I sure wouldn't recommend them for general use. There's a comment block at the top of kern/vfs_subr.c with some information on those delay values and how they're used that you might find useful. I think in general such small numbers on a system doing lots of IO would be counter-productive. In our case we arrived at those tunings this way... We have embedded systems with CF and SD cards as their only mass storage, and we do a relatively small amount of writing to the cards (occasional config changes, low-volume routine logging via syslog, not much else). Occasionally when newsyslog kicks in there'll be a short burst of IO to compress and rotate, then back to a trickle again. Once upon a time we mounted the filesystem without softupdates and with the sync option. That was fairly robust against users pulling the plug right after making a config change, but very very slow during syslog rotation, sometimes to the point of peturbing our apps (the CF cards run in PIO mode, and a burst of PIO activity is hard on time-critical apps). So we switched using softupdates and turned off the sync option. That was nicer to our apps, but left a long window during which updates didn't get flushed to the card. So we lowered those 3 tuning values to the lowest numbers supported by the code (as I vaguely remember it, this was years ago), not to get any sort of change in performance, but to reduce the window during which data just sat around in memory waiting for potential further updates before being flushed. The further updates would never happen for us, so the long delays had no benefit. This tuning could potentially increase the amount of I/O that actually occurs. The only advantage would be that large files that are sequentially written would be flushed to disk more frequently but in smaller amounts. I don't think so, in our case. The mechanism that would trigger more IO would be the lack of opportunity to elide multiple rewrites of the same blocks that occur within the delay windows, and that situation just doesn't come up in any significant way in our products. We write to the card on the order of once every 10-180 seconds, usually 1 or 2 blocks updated, like appending a few lines to /var/log/messages or saving a 900 byte config file. About
Re: r247835: drm2 code breaks buildkernel
On 05.03.2013 16:37, Konstantin Belousov wrote: The patch below is supposed to fix double declaration (it is pathetic that clang silently accepts this, while issuing countless useless warnings). Also there is a usual workaround for the anonimous union/struct issue. What do you think about -fms-extensions? It avoids modifications to the code and works with both gcc and clang. There're several unnamed structs/unions in the radeon code too. I would like to keep the diff with Linux code as small as possible. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r247835: drm2 code breaks buildkernel
On Tue, Mar 05, 2013 at 05:40:34PM +0100, Jean-S?bastien P?dron wrote: On 05.03.2013 16:37, Konstantin Belousov wrote: The patch below is supposed to fix double declaration (it is pathetic that clang silently accepts this, while issuing countless useless warnings). Also there is a usual workaround for the anonimous union/struct issue. What do you think about -fms-extensions? It avoids modifications to the code and works with both gcc and clang. Since TTM code needs a lot of modifications anyway, I do not mind to make one more local change. I already did it, please see r247849. This is IMO better then getting more unhandled warnings. There're several unnamed structs/unions in the radeon code too. I would like to keep the diff with Linux code as small as possible. It is your call. I am only looking after the TTM right now. pgpx5sIWhpDus.pgp Description: PGP signature
r247839: broken pipe - for top, sudo and ports
On recent FreeBSD 10.0-CURRENT/amd64 (CLANG buildworld, serveral systems (3) the same symptoms)), many services drop a sporadic broken pipe This happesn to system's top (I have to type it several times to get finally a top), it happens to sudo su -, it happens to SSH (drops connection with broken pipe) and as I reported earlier, it seems to affect the entire port system, since I can not build any port, I receive *** [do-extract] Signal 13 This is dramatic for me, because several modules (rtc, linux_adobe ...) can not be recompiled as it is required by the last /usr/src/UPDATING entry 20130304. Since dbus fails to start and even the nVidia driver (which is a kernel module, it canot be built and therefore ... ). Dimitry, I put you into CC, just in case. It seems that the last commits (not only the new DRM2 mess) broke something. I hope that others using FreeBSD 10.0CURRENT with CLANG can confirm this. Regards, Oliver On 03/05/13 10:33, Dimitry Andric wrote: On 2013-03-05 10:16, Hartmann, O. wrote: On FreeBSD 10.0-CURRENT #3 r247829: Tue Mar 5 08:12:19 CET 2013/amd64 I run into a mess and can not figure out what happens. Suddenly, after upgrading, buildworld etc., dbus fails to start so X11 is without mouse. Trying to rebuild the port dbus fails in a SIGNAL 13 while [do-extract]. This is weird. I can not extract and rebuild ports anymore, every port I try to rebuild with portmaster fails with the very same fault: = SHA256 Checksum OK for dbus-1.4.14.tar.gz. *** [do-extract] Signal 13 This is SIGPIPE, so maybe your tar is broken? What happens if you manually extract that tar.gz file? ___ 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: r247839: broken pipe - for top, sudo and ports
On 03/05/13 20:35, Hartmann, O. wrote:
On recent FreeBSD 10.0-CURRENT/amd64 (CLANG buildworld, serveral systems
(3) the same symptoms)), many services drop a sporadic
broken pipe
This happesn to system's top (I have to type it several times to get
finally a top), it happens to sudo su -, it happens to SSH (drops
connection with broken pipe) and as I reported earlier, it seems to
affect the entire port system, since I can not build any port, I receive
*** [do-extract] Signal 13
This is dramatic for me, because several modules (rtc, linux_adobe ...)
can not be recompiled as it is required by the last /usr/src/UPDATING
entry 20130304.
Since dbus fails to start and even the nVidia driver (which is a kernel
module, it canot be built and therefore ... ).
Dimitry, I put you into CC, just in case. It seems that the last commits
(not only the new DRM2 mess) broke something.
I hope that others using FreeBSD 10.0CURRENT with CLANG can confirm this.
Regards,
Oliver
On 03/05/13 10:33, Dimitry Andric wrote:
On 2013-03-05 10:16, Hartmann, O. wrote:
On FreeBSD 10.0-CURRENT #3 r247829: Tue Mar 5 08:12:19 CET 2013/amd64 I
run into a mess and can not figure out what happens.
Suddenly, after upgrading, buildworld etc., dbus fails to start so X11
is without mouse.
Trying to rebuild the port dbus fails in a SIGNAL 13 while [do-extract].
This is weird. I can not extract and rebuild ports anymore, every port I
try to rebuild with portmaster fails with the very same fault:
= SHA256 Checksum OK for dbus-1.4.14.tar.gz.
*** [do-extract] Signal 13
This is SIGPIPE, so maybe your tar is broken? What happens if you
manually extract that tar.gz file?
A truss top reveals this, is this of help?
[...]
stat(/etc/nsswitch.conf,{ mode=-rw-r--r--
,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
stat(/etc/nsswitch.conf,{ mode=-rw-r--r--
,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
stat(/etc/nsswitch.conf,{ mode=-rw-r--r--
,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
stat(/etc/nsswitch.conf,{ mode=-rw-r--r--
,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
stat(/etc/nsswitch.conf,{ mode=-rw-r--r--
,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
socket(PF_LOCAL,SOCK_STREAM,0) = 4 (0x4)
connect(4,{ AF_UNIX /var/run/nscd },15)= 0 (0x0)
fcntl(4,F_SETFL,O_NONBLOCK) = 0 (0x0)
kqueue(0x80183b000,0x80122fc58,0x10,0x80062b308,0x80183b010,0x2) = 5 (0x5)
kevent(5,{0x4,EVFILT_WRITE,EV_ADD,0,0x0,0x0},1,0x0,0,0x0) = 0 (0x0)
kqueue(0x5,0x7fffd2e0,0x1,0x0,0x0,0x0) = 6 (0x6)
kevent(6,{0x4,EVFILT_READ,EV_ADD,0,0x0,0x0},1,0x0,0,0x0) = 0 (0x0)
kevent(5,{0x4,EVFILT_WRITE,EV_ADD,1,0x4,0x0},1,0x0,0,0x0) = 0 (0x0)
kevent(5,0x0,0,{0x4,EVFILT_WRITE,EV_EOF,0,0x2000,0x0},1,0x0) = 1 (0x1)
sendmsg(0x4,0x7fffd290,0x0,0x1,0x1,0x0) ERR#32 'Broken pipe'
SIGNAL 13 (SIGPIPE)
process exit, rval = 0
___
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: Airport card is not recognized on i386
You need to provide much more information than that. Like, starting with what kind of airport card it is, what the PCI ID is, etc. Adrian ___ 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
Kernel panic on FreeBSD 10.0-CURRENT amd64
I have recently installed 9.1 and attempted to upgrade to 10.0-CURRENT yesterday (largely in an effort to test the new radeon DRM code). Unfortunately, upon rebooting, I am left at kernel debugger prompt: cd0 at ata0 bus 0 scbus0 target 1 lun 0 cd0: TSSTcorp CD-ROM TS-H192C DE00 Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed panic: g_read_data(): invalid length 0 cpuid = 0 KDB: enter: panic [ thread pid 13 tid 100014 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why db bt Tracing pid 13 tid 100014 td 0xfe0002957490 kdb_enter() at kdb_enter+0x3e/frame 0xff800026a960 vpanic() at vpanic+0x147/frame 0xff800026a9a0 kassert_panic() at kassert_panic+0x136/frame 0xff800026aa10 g_read_data() at g_read_data+0x45/frame 0xff800026aa50 g_label_ntfs_taste() at g_label_ntfs_taste+0xde/frame 0xff800026aa90 g_label_taste() at g_label_taste+0x37b/frame 0xff800026ab60 g_new_provider_event() at g_new_provider_event+0xda/frame 0xff800026ab80 g_run_events() at g_run_events+0x167/frame 0xff800026abb0 fork_exit() at fork_exit+0x84/frame 0xff800026abf0 fork_trampoline() at fork_trampoline+0xe/frame 0xff800026abf0 --- trap 0, rip = 0, rsp = 0xff800026acb0, rbp = 0 --- I'm no expert, but it appears to be related to the NTFS partition I have on a separate hard drive. Any ideas what the problem might be or how to debug this further? Adam ___ 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: Kernel panic on FreeBSD 10.0-CURRENT amd64
On Tue, Mar 5, 2013 at 8:03 PM, Adam Kirchhoff adam.k.kirchh...@gmail.comwrote: I have recently installed 9.1 and attempted to upgrade to 10.0-CURRENT yesterday (largely in an effort to test the new radeon DRM code). Unfortunately, upon rebooting, I am left at kernel debugger prompt: cd0 at ata0 bus 0 scbus0 target 1 lun 0 cd0: TSSTcorp CD-ROM TS-H192C DE00 Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed panic: g_read_data(): invalid length 0 cpuid = 0 KDB: enter: panic [ thread pid 13 tid 100014 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why db bt Tracing pid 13 tid 100014 td 0xfe0002957490 kdb_enter() at kdb_enter+0x3e/frame 0xff800026a960 vpanic() at vpanic+0x147/frame 0xff800026a9a0 kassert_panic() at kassert_panic+0x136/frame 0xff800026aa10 g_read_data() at g_read_data+0x45/frame 0xff800026aa50 g_label_ntfs_taste() at g_label_ntfs_taste+0xde/frame 0xff800026aa90 g_label_taste() at g_label_taste+0x37b/frame 0xff800026ab60 g_new_provider_event() at g_new_provider_event+0xda/frame 0xff800026ab80 g_run_events() at g_run_events+0x167/frame 0xff800026abb0 fork_exit() at fork_exit+0x84/frame 0xff800026abf0 fork_trampoline() at fork_trampoline+0xe/frame 0xff800026abf0 --- trap 0, rip = 0, rsp = 0xff800026acb0, rbp = 0 --- I'm no expert, but it appears to be related to the NTFS partition I have on a separate hard drive. Any ideas what the problem might be or how to debug this further? Adam ___ 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 This sounds like something that was just fixed today. Do you have r247837? http://svnweb.freebsd.org/changeset/base/247837 ___ 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: access to hard drives is blocked by writes to a flash drive
On 5 Mar, Ian Lepore wrote: I've debated playing with the bio work loop in mmcsd to see if moving reads ahead of writes was helpful, but that seems like a dangerous path to go down without some mitigation strategy to ensure that writes go through eventually. That seems especially important when you consider that writes may be necessary to free up memory to un-wedge other things that are waiting. (Yeah, people don't often use sd cards as swap storage, but I've done so in a pinch.) All in all, I've never pursued it because it feels like the wrong layer to address the problem at. I was initially concerned about the memory starvation problem, but I don't think it's an issue. If memory is unavailable, then the upper layer won't be able to allocate the buffer memory for the read requests and will block before sending any more read commands down to the driver. I think that large numbers of reads causing write starvation are also unlikely. A single thread can generate a large backlog of writes (unless the filesystem is mounted in sync mode), but it generally can't queue up a lot of reads because the thread is likely to block every time it issues a read request until it gets the data back from the drive. If you are still worried about this, you could maintain separate read and write queues and alternate between them if both are nonempty. ___ 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: access to hard drives is blocked by writes to a flash drive
On 3/5/13 9:37 PM, Don Lewis wrote: On 5 Mar, Ian Lepore wrote: I've debated playing with the bio work loop in mmcsd to see if moving reads ahead of writes was helpful, but that seems like a dangerous path to go down without some mitigation strategy to ensure that writes go through eventually. That seems especially important when you consider that writes may be necessary to free up memory to un-wedge other things that are waiting. (Yeah, people don't often use sd cards as swap storage, but I've done so in a pinch.) All in all, I've never pursued it because it feels like the wrong layer to address the problem at. I was initially concerned about the memory starvation problem, but I don't think it's an issue. If memory is unavailable, then the upper layer won't be able to allocate the buffer memory for the read requests and will block before sending any more read commands down to the driver. I think that large numbers of reads causing write starvation are also unlikely. A single thread can generate a large backlog of writes (unless the filesystem is mounted in sync mode), but it generally can't queue up a lot of reads because the thread is likely to block every time it issues a read request until it gets the data back from the drive. If you are still worried about this, you could maintain separate read and write queues and alternate between them if both are nonempty. What if we ran reads and writes over the loopback via TCP to get some kind of windowing? :) I am only half kidding... it would make sense to look to TCP to allow for some kind of window of IO based on throughput to the device. -Alfred ___ 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: access to hard drives is blocked by writes to a flash drive
Content-Type: text/plain; charset=ISO-8859-1 In message 1362500313.1291.20.ca...@revolution.hippie.lan, Ian Lepore writes: I don't think so, in our case. Have you seriously considered using msdosfs ? The cards flash-adaption-layer may work a LOT better if you do... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
