RE: 8.0-RC USB/FS problem
Freshly installed 8.0-RELEASE on two differnt machines, and USB stick work well so far, but the USB hard drive still has crash on this SMP (4-core AMD phenom 9600) during the dump/restore. I will try it on the single CPU machine tomorrow. Re-tested dump/restore with FreeBSD 6.3/6.4 on this SMP machine and they are working well. Also the another strange thing ocurred during the mount a partition on /tmp, which ended with two /tmp, and the last one mounted is on the top (the first should be hidden): : df Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s1a756750 165484 53072624%/ devfs 110 100%/dev /dev/ad0s2e 43194318 27833648 1190512670%/data /dev/ad0s2d 9135182 5870390 253397870%/home /dev/ad0s1e50763034882 432138 7%/tmp /dev/ad0s1f 13246730 1424522 1076247012%/usr /dev/ad0s1d 507703812700 4658176 0%/var /dev/da0s2 661176 487660 12062280%/mnt /dev/da1s3d 91351824 8404364 0%/dist /dev/da1s3e 749389484 68943830 0%/tmp : df /tmp Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/da1s3e 749389484 68943830 0%/tmp -Original Message- From: Guojun Jin Sent: Sun 11/22/2009 7:59 PM To: Hans Petter Selasky; freebsd-...@freebsd.org Cc: b...@freebsd.org; freebsd-stable@freebsd.org Subject: RE: 8.0-RC USB/FS problem From more intensive diagnose, it looks like more related USB layer. repeated a few time on following process and ithe crash happened at different USB access phase at each time. dd if=/dev/zero of=/dev/da0 count=1000 bs=4k sysinstall partition slice 1 (da0s1) 18GB ID=12 slice 2 (da0s2) 10-15GB Id=165 slice 3 (da0s3) rest ID=165 W --- OK label da0s3d 9GB /mnt da0s3e rest/dist W --- da0s3e device is not configured. w# ll /dev/da0* # after sysinstall did partition + W at 1st time crw-r- 1 root operator0, 97 Nov 22 11:23 /dev/da0 crw-r- 1 root operator0, 98 Nov 22 11:23 /dev/da0s1 crw-r- 1 root operator0, 99 Nov 22 11:23 /dev/da0s2 crw-r- 1 root operator0, 100 Nov 22 11:23 /dev/da0s3 # ll /dev/da0* # after sysinstall start at 2nd time crw-r- 1 root operator0, 97 Nov 22 11:27 /dev/da0 System crashed The crash log is available at http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 (All logs are based on hw.usb.umass.debug=-1) After system reboot, and repeated above processes, the da0s3e was mounted on /dist, but da0s3d cannot. It tunred out that newfs fail inside labeling process in sysinstall. Manually did newfs on da0s3d, and it cannot be mounted on /mnt, but access to it caused crash. The crash log is available at http:/www.daemonfun.com/archives/pub/USB/newfs Tried entire process again, this time, both partitons are formatted (newfs) inside labaling process (sysinstall) but crahsed system during dump/restore on da0s3e (/dist). The crash log is available at http:/www.daemonfun.com/archives/pub/USB/usb-log.crash2.bz2, which is huge one. It contains two parts, one dump/restore IDE to da0s3d (passed), and the rest is dump/restore to da0s3e (crashed). I am going to reinstall the system with the new ISO from Nov 21 8.0-RELEASE to see if anything will improve. -Original Message- From: Hans Petter Selasky [mailto:hsela...@c2i.net] Sent: Sun 11/22/2009 1:47 AM To: freebsd-...@freebsd.org Cc: Guojun Jin; b...@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Sunday 22 November 2009 05:38:13 Guojun Jin wrote: Tried on the USB hard drive: Deleted slice 3 and recreated slice 3 with two partitions s3d and s3e. Was happy because successfully did dump/restore on s3d, and thought it just partition format issue; but system crashed during dump/restore on s3e, and partition lost the file system type. wolf# mount /dev/da0s3e /mnt WARNING: /mnt was not properly dismounted /mnt: mount pending error: blocks 35968 files 0 wolf# fsck da0s3e fsck: Could not determine filesystem type wolf# bsdlabel da0s3 # /dev/da0s3: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 1757350350unused0 0 # raw part, don't edi t d: 1887436804.2BSD0 0 0 e: 156860667 188743684.2BSD0 0 0 Therefore, tried directly use fsck_ufs on both USB hard drive and USB stick to get file system clean up. All data got back now. The machine has run with FreeBSD 6.1 all the way to 7.2 without such problem. How can we determine what could go wrong in 8.0? FS or USB. Hi, Error 5 means IO error, so probably the transport layer, USB or lower, is to blame. Some things to check: 1) Make sure the connection for your memory stick is Ok. 2) Make sure there is enough power for
Re: 8.0-RC USB/FS problem
On Tuesday 24 November 2009 09:12:45 Guojun Jin wrote: http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 I'm not able to fetch this file. Could you extract the panic backtrace? --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
gjournal + gmirror
Hi all, I've configured a new disk with two journaled partitions (/var and /usr). All works fine until this point. Next I add a new disk and I set up a gmirror as I've done always without problems. But when I reboot the system, I always get a nasty 'mountroot' message. I've cheched the gmirror creation process (module in /boot/loader.conf, the modified fstab... all) and all is correct. I suspect some gjournal+gmirror especial issues maybe ¿Any clue? FreeBSD 7.2 AMD64 -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
Hi,
I have problems with compiling our application under 8.0.
It fails due to these definitions in pthread.h that look like a typo or
incorrectly applied patch:
170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg)
\
171 {
\
172 struct _pthread_cleanup_info __cleanup_info__;
\
173 __pthread_cleanup_push_imp(cleanup_routine,
cleanup_arg,\
174 __cleanup_info__);
\
175 {
176
177 #define pthread_cleanup_pop(execute)
\
178 }
\
179 __pthread_cleanup_pop_imp(execute);
\
180 }
This patch fixes the problem for me:
--- pthread.h.orig2009-11-24 16:44:13.0 +0200
+++ pthread.h 2009-11-24 16:44:45.0 +0200
@@ -172,10 +172,10 @@
struct _pthread_cleanup_info __cleanup_info__;
\
__pthread_cleanup_push_imp(cleanup_routine,
cleanup_arg,\
__cleanup_info__);
\
- {
+ }
#definepthread_cleanup_pop(execute)
\
- }
\
+ { \
__pthread_cleanup_pop_imp(execute);
\
}
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
2009/11/24 Mikolaj Golub to.my.troc...@gmail.com:
Hi,
I have problems with compiling our application under 8.0.
It fails due to these definitions in pthread.h that look like a typo or
incorrectly applied patch:
170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg)
\
171 {
\
172 struct _pthread_cleanup_info __cleanup_info__;
\
173 __pthread_cleanup_push_imp(cleanup_routine,
cleanup_arg,\
174 __cleanup_info__);
\
175 {
176
177 #define pthread_cleanup_pop(execute)
\
178 }
\
179 __pthread_cleanup_pop_imp(execute);
\
180 }
Hi.
No, this is made intentionally.
P.S. I don't understand the reason in the second brackets pair though
(lines 175,178),
maybe these are because of comment to v1.43..
--
wbr,
pluknet
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
On Tue, 24 Nov 2009 16:53:35 +0200 Mikolaj Golub wrote:
Hi,
I have problems with compiling our application under 8.0.
It fails due to these definitions in pthread.h that look like a typo or
incorrectly applied patch:
170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg)
\
171 {
\
172 struct _pthread_cleanup_info
__cleanup_info__; \
173 __pthread_cleanup_push_imp(cleanup_routine,
cleanup_arg,\
174 __cleanup_info__);
\
175 {
176
177 #define pthread_cleanup_pop(execute)
\
178 }
\
179 __pthread_cleanup_pop_imp(execute);
\
180 }
This patch fixes the problem for me:
I was hurry when said that the patch fixed the problem. The application
compiled but later it crashed in pthread_cleanup_pop:
(gdb) bt
#0 0xbf4f9ee0 in ?? ()
#1 0x287d18c9 in __pthread_cleanup_pop_imp () from /lib/libthr.so.3
#2 0x287d18ed in pthread_cleanup_pop () from /lib/libthr.so.3
#3 0x287d123c in pthread_exit () from /lib/libthr.so.3
#4 0x287c7757 in pthread_getprio () from /lib/libthr.so.3
#5 0x in ?? ()
So, I don't know what these macros actually were supposed to be. They were
introduced in r179662:
Revision 1.43: download - view: text, markup, annotated - select for diffs
Mon Jun 9 01:14:10 2008 UTC (17 months, 2 weeks ago) by davidxu
Branches: MAIN
Diff to: previous 1.42: preferred, colored
Changes since revision 1.42: +21 -2 lines
SVN rev 179662 on 2008-06-09 01:14:10Z by davidxu
Make pthread_cleanup_push() and pthread_cleanup_pop() as a pair of macros,
use stack space to keep cleanup information, this eliminates overhead of
calling malloc() and free() in thread library.
Discussed on: thread@
--- pthread.h.orig2009-11-24 16:44:13.0 +0200
+++ pthread.h 2009-11-24 16:44:45.0 +0200
@@ -172,10 +172,10 @@
struct _pthread_cleanup_info __cleanup_info__;
\
__pthread_cleanup_push_imp(cleanup_routine,
cleanup_arg,\
__cleanup_info__);
\
- {
+ }
#definepthread_cleanup_pop(execute)
\
- }
\
+ { \
__pthread_cleanup_pop_imp(execute);
\
}
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
On Tue, Nov 24, 2009 at 3:18 PM, Mikolaj Golub to.my.troc...@gmail.comwrote: snip So, I don't know what these macros actually were supposed to be. They were introduced in r179662: Revision 1.43: download - view: text, markup, annotated - select for diffs Mon Jun 9 01:14:10 2008 UTC (17 months, 2 weeks ago) by davidxu Branches: MAIN Diff to: previous 1.42: preferred, colored Changes since revision 1.42: +21 -2 lines SVN rev 179662 on 2008-06-09 01:14:10Z by davidxu Make pthread_cleanup_push() and pthread_cleanup_pop() as a pair of macros, use stack space to keep cleanup information, this eliminates overhead of calling malloc() and free() in thread library. Discussed on: thread@ http://lists.freebsd.org/pipermail/freebsd-threads/2008-May/004299.html Cheers Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
On Tue, Nov 24, 2009 at 05:18:29PM +0200, Mikolaj Golub wrote:
On Tue, 24 Nov 2009 16:53:35 +0200 Mikolaj Golub wrote:
Hi,
I have problems with compiling our application under 8.0.
It fails due to these definitions in pthread.h that look like a typo or
incorrectly applied patch:
170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg)
\
171 {
\
172 struct _pthread_cleanup_info
__cleanup_info__; \
173 __pthread_cleanup_push_imp(cleanup_routine,
cleanup_arg,\
174 __cleanup_info__);
\
175 {
176
177 #define pthread_cleanup_pop(execute)
\
178 }
\
179 __pthread_cleanup_pop_imp(execute);
\
180 }
This patch fixes the problem for me:
I was hurry when said that the patch fixed the problem. The application
compiled but later it crashed in pthread_cleanup_pop:
(gdb) bt
#0 0xbf4f9ee0 in ?? ()
#1 0x287d18c9 in __pthread_cleanup_pop_imp () from /lib/libthr.so.3
#2 0x287d18ed in pthread_cleanup_pop () from /lib/libthr.so.3
#3 0x287d123c in pthread_exit () from /lib/libthr.so.3
#4 0x287c7757 in pthread_getprio () from /lib/libthr.so.3
#5 0x in ?? ()
So, I don't know what these macros actually were supposed to be. They were
introduced in r179662:
Revision 1.43: download - view: text, markup, annotated - select for diffs
Mon Jun 9 01:14:10 2008 UTC (17 months, 2 weeks ago) by davidxu
Branches: MAIN
Diff to: previous 1.42: preferred, colored
Changes since revision 1.42: +21 -2 lines
SVN rev 179662 on 2008-06-09 01:14:10Z by davidxu
Make pthread_cleanup_push() and pthread_cleanup_pop() as a pair of macros,
use stack space to keep cleanup information, this eliminates overhead of
calling malloc() and free() in thread library.
Discussed on: thread@
--- pthread.h.orig2009-11-24 16:44:13.0 +0200
+++ pthread.h 2009-11-24 16:44:45.0 +0200
@@ -172,10 +172,10 @@
struct _pthread_cleanup_info __cleanup_info__;
\
__pthread_cleanup_push_imp(cleanup_routine,
cleanup_arg,\
__cleanup_info__);
\
- {
+ }
#definepthread_cleanup_pop(execute)
\
- }
\
+ { \
__pthread_cleanup_pop_imp(execute);
\
}
pthread_cleanup_push/pop are supposed to be used from the common
lexical scope. Citation from SUSv4:
These functions may be implemented as macros. The application shall
ensure that they appear as statements, and in pairs within the same
lexical scope (that is, the pthread_cleanup_push() macro may be
thought to expand to a token list whose first token is '{' with
pthread_cleanup_pop() expanding to a token list whose last token is the
corresponding '}' ).
Your change is wrong.
Basically, the code should do
pthread_cleanup_push(some_func, arh);
something ...
pthread_cleanup_pop(1);
(1 denotes that some_func should be called).
pgp7FToQ1ca9J.pgp
Description: PGP signature
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
Hi,
On Tue, 24 Nov 2009 17:18:29 +0200
Mikolaj Golub to.my.troc...@gmail.com said:
to.my.trociny I was hurry when said that the patch fixed the problem. The
application
to.my.trociny compiled but later it crashed in pthread_cleanup_pop:
to.my.trociny (gdb) bt
to.my.trociny #0 0xbf4f9ee0 in ?? ()
to.my.trociny #1 0x287d18c9 in __pthread_cleanup_pop_imp () from
/lib/libthr.so.3
to.my.trociny #2 0x287d18ed in pthread_cleanup_pop () from /lib/libthr.so.3
to.my.trociny #3 0x287d123c in pthread_exit () from /lib/libthr.so.3
to.my.trociny #4 0x287c7757 in pthread_getprio () from /lib/libthr.so.3
to.my.trociny #5 0x in ?? ()
to.my.trociny So, I don't know what these macros actually were supposed to be.
They were
to.my.trociny introduced in r179662:
Your modification to pthread.h is wrong. You need to write your code
something like following:
pthread_cleanup_push();
. . .
do something
. . .
pthread_cleanup_pop();
This is not FreeBSD alone. pthread_cleanup_push() and
pthread_cleanup_pop() are macro on Linux as well.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org u...@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
On Tue, 24 Nov 2009 17:34:22 +0200 Kostik Belousov wrote:
pthread_cleanup_push/pop are supposed to be used from the common
lexical scope. Citation from SUSv4:
These functions may be implemented as macros. The application shall
ensure that they appear as statements, and in pairs within the same
lexical scope (that is, the pthread_cleanup_push() macro may be
thought to expand to a token list whose first token is '{' with
pthread_cleanup_pop() expanding to a token list whose last token is the
corresponding '}' ).
Your change is wrong.
Basically, the code should do
pthread_cleanup_push(some_func, arh);
something ...
pthread_cleanup_pop(1);
(1 denotes that some_func should be called).
I see. Thank you. So it really looks like a bug in our application as
pthread_cleanup_pop(1) is missed. I will tell our developers :-)
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: 8.0-RC USB/FS problem
Sorry for the typo -- it is public not pub in the middle. The others should be all public. http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 -Original Message- From: Hans Petter Selasky [mailto:hsela...@c2i.net] Sent: Tue 11/24/2009 12:33 AM To: Guojun Jin Cc: freebsd-...@freebsd.org; b...@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Tuesday 24 November 2009 09:12:45 Guojun Jin wrote: http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 I'm not able to fetch this file. Could you extract the panic backtrace? --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-RC USB/FS problem
On Tuesday 24 November 2009 17:58:47 Guojun Jin wrote: Sorry for the typo -- it is public not pub in the middle. The others should be all public. http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 %fetch http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 fetch: http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2: No address record --HPS -Original Message- From: Hans Petter Selasky [mailto:hsela...@c2i.net] Sent: Tue 11/24/2009 12:33 AM To: Guojun Jin Cc: freebsd-...@freebsd.org; b...@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Tuesday 24 November 2009 09:12:45 Guojun Jin wrote: http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 I'm not able to fetch this file. Could you extract the panic backtrace? --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Panic possibly related to glabel/geom and siis(4)
I have a system running 8.0-PRERELEASE with multiple drives and SATA port multipliers (siis controllers and PMPs). All of the attached drives are labeled via glabel(8) and then included into a ZFS pool. During some testing to determine how the system would react to a dead drive (simulated by physically removing a drive during operation), I was able to produce a panic. Now, I know that the SATA PMP and siis(4) code to handle and recover from device errors is incomplete, but I believe the crash may be particular to using glabel'd drives. Basically, after removing a drive while the zpool is in use and issues 'camcontrol reset' and 'rescan' on the appropriate bus, the physical device associated with the drive disappears. In this case: (pass5:siisch7:0:15:0): lost device (pass5:siisch7:0:15:0): removing device entry (ada2:siisch7:0:0:0): lost device and /dev/ada2 disappears. However, the associated glabel /dev/label/bigdisk07 remains. Since my ZFS pool is created based on the drive glabels, I believe this is why ZFS never notices the drives disappear either. Do glabels typically go away after a physical device is lost? Should this not be the case? After some runtime with the physical device missing, a kernel panic is produced: ada2:siisch7:0:0:0): Synchronize cache failed (ada2:siisch7:0:0:0): removing device entry Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 14 fault virtual address = 0x48 fault code = supervisor write data, page not present instruction pointer = 0x20:0x8035f375 stack pointer = 0x28:0xff86db60 frame pointer = 0x28:0xff86db70 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 = 2 (g_event) [thread pid 2 tid 100014 ] Stopped at _mtx_lock_flags+0x15: lock cmpxchgq %rsi,0x18(%rdi) db bt Tracing pid 2 tid 100014 td 0xff00014d4ab0 _mtx_lock_flags() at _mtx_lock_flags+0x15 vdev_geom_release() at vdev_geom_release+0x33 vdev_geom_orphan() at vdev_geom_orphan+0x15c g_run_events() at g_run_events+0x104 g_event_procbody() at g_event_procbody+0x55 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff86dd30, rbp = 0 --- I'm open to try patches and other suggestions. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-RC USB/FS problem
On Tue, Nov 24, 2009 at 06:13:21PM +0100, Hans Petter Selasky wrote: On Tuesday 24 November 2009 17:58:47 Guojun Jin wrote: Sorry for the typo -- it is public not pub in the middle. The others should be all public. http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 %fetch http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 fetch: http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2: No address record --HPS -Original Message- From: Hans Petter Selasky [mailto:hsela...@c2i.net] Sent: Tue 11/24/2009 12:33 AM To: Guojun Jin Cc: freebsd-...@freebsd.org; b...@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Tuesday 24 November 2009 09:12:45 Guojun Jin wrote: http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 I'm not able to fetch this file. Could you extract the panic backtrace? --HPS The above issue is unrelated to the USB/FS problem. It looks like fetch(1) has a parser bug. Note the text portion between the URI and URL is colon-slash not colon-slash-slash like it should be. Reproduction: $ host www.daemonfun.com www.daemonfun.com is an alias for daemonfun.com. daemonfun.com has address 76.202.192.211 daemonfun.com mail is handled by 10 mh1.daemonfun.com. daemonfun.com mail is handled by 20 mh2.daemonfun.com. $ fetch http:/www.daemonfun.com/ fetch: http:/www.daemonfun.com/: No address record I haven't examined the code, but my guess is fetch is trying to do a lookup on the FQDN http:/www.daemonfun.com/. Who wants to file a PR? :-) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-RC USB/FS problem
In the last episode (Nov 24), Jeremy Chadwick said: On Tue, Nov 24, 2009 at 06:13:21PM +0100, Hans Petter Selasky wrote: On Tuesday 24 November 2009 17:58:47 Guojun Jin wrote: Sorry for the typo -- it is public not pub in the middle. The others should be all public. http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 %fetch http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 fetch: http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2: No address record The above issue is unrelated to the USB/FS problem. It looks like fetch(1) has a parser bug. Note the text portion between the URI and URL is colon-slash not colon-slash-slash like it should be. That's a typo in the URL, not a bug in fetch :) -- Dan Nelson dnel...@allantgroup.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-RC USB/FS problem
On Tue, Nov 24, 2009 at 12:16:54PM -0600, Dan Nelson wrote:
In the last episode (Nov 24), Jeremy Chadwick said:
On Tue, Nov 24, 2009 at 06:13:21PM +0100, Hans Petter Selasky wrote:
On Tuesday 24 November 2009 17:58:47 Guojun Jin wrote:
Sorry for the typo -- it is public not pub in the middle. The others
should
be all public.
http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2
%fetch http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2
fetch: http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2: No
address record
The above issue is unrelated to the USB/FS problem. It looks like
fetch(1) has a parser bug. Note the text portion between the URI and URL
is colon-slash not colon-slash-slash like it should be.
That's a typo in the URL, not a bug in fetch :)
It's a bug in libfetch, specifically the fetchParseURL(3) function.
Relevant code from src/usr.bin/fetch/fetch.c:
312 static int
313 fetch(char *URL, const char *path)
314 {
315 struct url *url;
...
342 /* parse URL */
343 if ((url = fetchParseURL(URL)) == NULL) {
344 warnx(%s: parse error, URL);
345 goto failure;
346 }
The man page for fetchParseURL(3) claims:
fetchParseURL() takes a URL in the form of a null-terminated string and
splits it into its components function according to the Common Internet
Scheme Syntax detailed in RFC1738. A regular expression which produces
this syntax is:
scheme:(//(user(:pwd)?@)?host(:port)?)?/(document)?
If the URL does not seem to begin with a scheme name, the following syn-
tax is assumed:
((user(:pwd)?@)?host(:port)?)?/(document)?
.
fetchParseURL() returns a pointer to a struct url containing the individ-
ual components of the URL. If it is unable to allocate memory, or the
URL is syntactically incorrect, fetchParseURL() returns a NULL pointer.
If we add some debugging code *before* the scheme assumption portion
of fetch.c (which actually looks at the hostname portion and if it
starts with ftp assumes the scheme is FTP, http = HTTP, etc.):
348 printf(fetchParseURL() successful. struct details:\n);
349 printf(url-scheme = %s\n, url-scheme);
350 printf(url-user = %s\n, url-user);
351 printf(url-pwd= %s\n, url-pwd);
352 printf(url-host = %s\n, url-host);
353 printf(url-port = %d\n, url-port);
354 printf(url-doc= %s\n, url-doc);
...we end up with this:
$ ./fetch http:/www.daemonfun.com/
fetchParseURL() successful. struct details:
url-scheme = http
url-user =
url-pwd=
url-host =
url-port = 0
url-doc= /www.daemonfun.com/
fetch: http:/www.daemonfun.com/: No address record
Here we can see the libfetch code properly works out the scheme (URI) on
its own (which means the assumption part of the man page should not
play a role here) -- but incorrectly parses the remaining portion of the
URL.
In this situation, fetchParseURL(3) should return NULL.
The code in fetch.c continues on to call fetchXGet(3) with the above
struct data (some of it gets modified, but that's besides the point),
and the result is fetchXGet(3) returning NULL (indicating the fetch
failed in some way), which gets us here:
463 f = fetchXGet(url, us, flags);
...
468 if (f == NULL) {
469 warnx(%s: %s, URL, fetchLastErrString);
470 if (i_flag strcmp(url-scheme, SCHEME_HTTP) == 0
471 fetchLastErrCode == FETCH_OK
472 strcmp(fetchLastErrString, Not Modified) == 0) {
473 /* HTTP Not Modified Response, return OK. */
474 r = 0;
475 goto done;
476 } else
477 goto failure;
478 }
We modify some code to add some debugging to validate that warnx() is
what's returning the error message:
469 warnx(fetchXGet() returned NULL: %s: %s, URL,
fetchLastErrString);
...and we end up with:
fetch: fetchXGet() returned NULL: http:/www.daemonfun.com/: No address record
I guess I'll be the one to file the PR.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
Report it using send-pr. That way the problem will make its way into the
bug tracking system.
In message 86aayc7z4g@zhuzha.ua1, Mikolaj Golub writes:
Hi,
I have problems with compiling our application under 8.0.
It fails due to these definitions in pthread.h that look like a typo or
incorrectly applied patch:
170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg)
\
171 {
\
172 struct _pthread_cleanup_info
__cleanup_info__;
\
173 __pthread_cleanup_push_imp(cleanup_routine,
clean
up_arg,\
174 __cleanup_info__);
\
175 {
176
177 #define pthread_cleanup_pop(execute)
\
178 }
\
179 __pthread_cleanup_pop_imp(execute);
\
180 }
This patch fixes the problem for me:
--- pthread.h.orig2009-11-24 16:44:13.0 +0200
+++ pthread.h 2009-11-24 16:44:45.0 +0200
@@ -172,10 +172,10 @@
struct _pthread_cleanup_info __cleanup_info__;
\
__pthread_cleanup_push_imp(cleanup_routine,
cleanup_arg,\
__cleanup_info__);
\
- {
+ }
#definepthread_cleanup_pop(execute)
\
- }
\
+ { \
__pthread_cleanup_pop_imp(execute);
\
}
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
On Wed, 25 Nov 2009, Mark Andrews wrote:
Report it using send-pr. That way the problem will make its way into the
bug tracking system.
In message 86aayc7z4g@zhuzha.ua1, Mikolaj Golub writes:
Hi,
I have problems with compiling our application under 8.0.
It fails due to these definitions in pthread.h that look like a typo or
incorrectly applied patch:
Did someone already reply to this?
I think the problem is in your application. You cannot
have push and pop at different nesting levels. The
start brace in the push is ended by the end brace in
pop on purpose. It is to enforce nesting levels.
170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg)
\
171 {
\
172 struct _pthread_cleanup_info __cleanup_info__;
\
173 __pthread_cleanup_push_imp(cleanup_routine,
clean
up_arg,\
174 __cleanup_info__);
\
175 {
176
177 #define pthread_cleanup_pop(execute)
\
178 }
\
179 __pthread_cleanup_pop_imp(execute);
\
180 }
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
In message 20091124153422.gt2...@deviant.kiev.zoral.com.ua, Kostik Belousov
write
s:
--i616tqyc3hrkKsk2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Nov 24, 2009 at 05:18:29PM +0200, Mikolaj Golub wrote:
On Tue, 24 Nov 2009 16:53:35 +0200 Mikolaj Golub wrote:
=20
Hi,
I have problems with compiling our application under 8.0.
It fails due to these definitions in pthread.h that look like a typo or
incorrectly applied patch:
170 #define pthread_cleanup_push(cleanup_routine, cleanup_a=
rg) \
171 { =
\
172 struct _pthread_cleanup_info __cleanup_=
info__; \
173 __pthread_cleanup_push_imp(cleanup_rout=
ine, cleanup_arg,\
174 __cleanup_info__);=
\
175 {
176=20
177 #define pthread_cleanup_pop(execute) =
\
178 } =
\
179 __pthread_cleanup_pop_imp(execute);=
\
180 }
This patch fixes the problem for me:
=20
I was hurry when said that the patch fixed the problem. The application
compiled but later it crashed in pthread_cleanup_pop:
=20
(gdb) bt
#0 0xbf4f9ee0 in ?? ()
#1 0x287d18c9 in __pthread_cleanup_pop_imp () from /lib/libthr.so.3
#2 0x287d18ed in pthread_cleanup_pop () from /lib/libthr.so.3
#3 0x287d123c in pthread_exit () from /lib/libthr.so.3
#4 0x287c7757 in pthread_getprio () from /lib/libthr.so.3
#5 0x in ?? ()
=20
So, I don't know what these macros actually were supposed to be. They were
introduced in r179662:
=20
Revision 1.43: download - view: text, markup, annotated - select for diffs
Mon Jun 9 01:14:10 2008 UTC (17 months, 2 weeks ago) by davidxu
Branches: MAIN
Diff to: previous 1.42: preferred, colored
Changes since revision 1.42: +21 -2 lines
=20
SVN rev 179662 on 2008-06-09 01:14:10Z by davidxu
=20
Make pthread_cleanup_push() and pthread_cleanup_pop() as a pair of macros,
use stack space to keep cleanup information, this eliminates overhead of
calling malloc() and free() in thread library.
=20
Discussed on: thread@
=20
--- pthread.h.orig2009-11-24 16:44:13.0 +0200
+++ pthread.h 2009-11-24 16:44:45.0 +0200
@@ -172,10 +172,10 @@
struct _pthread_cleanup_info __cleanup_info__; =
\
__pthread_cleanup_push_imp(cleanup_routine, cle=
anup_arg,\
__cleanup_info__);=
\
- {
+ } =20
=20
#definepthread_cleanup_pop(execute) =
\
- } =
\
+ { =
\
__pthread_cleanup_pop_imp(execute);=
\
}
pthread_cleanup_push/pop are supposed to be used from the common
lexical scope. Citation from SUSv4:
These functions may be implemented as macros. The application shall
ensure that they appear as statements, and in pairs within the same
lexical scope (that is, the pthread_cleanup_push() macro may be
thought to expand to a token list whose first token is '{' with
pthread_cleanup_pop() expanding to a token list whose last token is the
corresponding '}' ).
Your change is wrong.
Basically, the code should do
pthread_cleanup_push(some_func, arh);
something ...
pthread_cleanup_pop(1);
(1 denotes that some_func should be called).
The problem is that that expands to C code that can only be used
with newer C compilers. This expansion should be usable with all
C compilers.
#define pthread_cleanup_push(cleanup_routine, cleanup_arg) \
{ \
struct _pthread_cleanup_info __cleanup_info__; \
__pthread_cleanup_push_imp(cleanup_routine, cleanup
_arg,\
__cleanup_info__)
#define pthread_cleanup_pop(execute) \
__pthread_cleanup_pop_imp(execute);\
} ((void)0)
--i616tqyc3hrkKsk2
Content-Type: application/pgp-signature
Content-Disposition: inline
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (FreeBSD)
Re: [geom] page fault in g_mbr_config()
2009/7/24 pluknet pluk...@gmail.com: 2009/7/24 pluknet pluk...@gmail.com: Hi. I got a panic while performing a repetitive 'fdisk -BI aacd0', where aacd0 is a disk on aac0: IBM ServeRAID-8k. This means that the command was issued after filesystems were already created on aacd (after the first fdisk -BI aacd0 iteration), and are in umount'ed state. This is on 7.2-R, amd64. Config is a GENERIC plus ddb, carp, ipfw, quota. Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0x20 fault code = supervisor read data, page not present instruction pointer = 0x8:0x804cc554 stack pointer = 0x10:0xfffe80079b80 frame pointer = 0x10:0xfffe80079bd0 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 = 2 (g_event) [thread pid 2 tid 100013 ] Stopped at g_mbr_config+0x64: movq 0x20(%rax),%r15 db bt Tracing pid 2 tid 100013 td 0xff000144da50 g_mbr_config() at g_mbr_config+0x64 g_run_events() at g_run_events+0x1b8 g_event_procbody() at g_event_procbody+0x57 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffe80079d30, rbp = 0 --- And, of course... db show proc 818 Process 818 (fdisk) at 0xff0004ed1000: state: NORMAL uid: 0 gids: 0, 0, 5 parent: pid 814 at 0xff00045c0478 ABI: FreeBSD ELF64 arguments: fdisk threads: 1 100169 D g_waitfo 0xff0004ec9100 fdisk db bt 818 Tracing pid 818 tid 100169 td 0xff0004fbf6e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x354 g_waitfor_event() at g_waitfor_event+0x9a g_ctl_ioctl() at g_ctl_ioctl+0x2df giant_ioctl() at giant_ioctl+0x7d devfs_ioctl_f() at devfs_ioctl_f+0x77 kern_ioctl() at kern_ioctl+0xa2 ioctl() at ioctl+0xf9 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x8008200ec, rsp = 0x7fffe1d8, rbp = 0x4 --- This makes me tied to GEOM_* - GEOM_PART_* scheme (which is in 8+ in DEFAULTS now). After this replacement in DEFAULTS I see no more panics in 'fdisk -BI aacd0'. -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.x hang-on-boot on Dell 1950
On Sun, Nov 22, 2009 at 11:47 PM, Zaphod Beeblebrox zbee...@gmail.comwrote: On Sun, Nov 22, 2009 at 9:09 PM, Zaphod Beeblebrox zbee...@gmail.comwrote: On Fri, Nov 13, 2009 at 9:44 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: This 1950 may predate that a bit, but I'm not sure how to nail it down exactly, other than by it's hardware components. Anyways, 7.0 does the same thing --- still wedged. I haven't seen anyone recommend this as a test method yet -- disabling fdc prior to the kernel booting via the loader prompt: - Press 6 at the menu, - At the loader prompt, type: set hint.fdc.0.disabled=1 boot -v (or without -v; your choice) You shouldn't need to set hint.fd.0.disabled=1, since fd0 would normally bind to fdc0; disable the latter and you disable the lesser. The intention here is to rule out the device attachment failures from fdc as the source of the deadlock. Entertainingly, it does not. Aparently that hint doesn't stop the code from trying to attach fdc0 when acpi says so. I suppose I need to know the console command to disable acpi and fdc. but it still wedges at device_attach: fdc0 attach returned 6 with the above. OK. With both floppy and acpi disabled, it dies calling start_init several times, the last being /stand/sysinstal (which should work). I don't see it starting the other CPUs. It hangs hard... no keyboard working (ie: no caps lock). OK... I finally figured out what makes this Dell boot. The system as I got it has 2 dual core (Xeon) processors. If I remove one processor (so now it has one dual-core processor), Then the system boots !?! ... so there's something wrong with how FreeBSD is going multiprocessor (works with RedHat, it would appear) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
On Wed, 25 Nov 2009, Mark Andrews wrote:
In message 20091124153422.gt2...@deviant.kiev.zoral.com.ua, Kostik Belousov
write
s:
--i616tqyc3hrkKsk2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Nov 24, 2009 at 05:18:29PM +0200, Mikolaj Golub wrote:
pthread_cleanup_push/pop are supposed to be used from the common
lexical scope. Citation from SUSv4:
These functions may be implemented as macros. The application shall
ensure that they appear as statements, and in pairs within the same
lexical scope (that is, the pthread_cleanup_push() macro may be
thought to expand to a token list whose first token is '{' with
pthread_cleanup_pop() expanding to a token list whose last token is the
corresponding '}' ).
Your change is wrong.
Basically, the code should do
pthread_cleanup_push(some_func, arh);
something ...
pthread_cleanup_pop(1);
(1 denotes that some_func should be called).
The problem is that that expands to C code that can only be used
with newer C compilers. This expansion should be usable with all
C compilers.
#define pthread_cleanup_push(cleanup_routine, cleanup_arg) \
{ \
struct _pthread_cleanup_info __cleanup_info__; \
__pthread_cleanup_push_imp(cleanup_routine, cleanup
_arg,\
__cleanup_info__)
#define pthread_cleanup_pop(execute) \
__pthread_cleanup_pop_imp(execute);\
} ((void)0)
Hmm, agreed. But note that Solaris 10 does it this way:
#define pthread_cleanup_push(routine, args) { \
_cleanup_t _cleanup_info; \
__pthread_cleanup_push((_Voidfp)(routine), (void *)(args), \
(caddr_t)_getfp(), _cleanup_info);
#define pthread_cleanup_pop(ex) \
__pthread_cleanup_pop(ex, _cleanup_info); \
}
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
In message pine.gso.4.64.0911241718490.5...@sea.ntplx.net, Daniel Eischen wri
tes:
On Wed, 25 Nov 2009, Mark Andrews wrote:
In message 20091124153422.gt2...@deviant.kiev.zoral.com.ua, Kostik Belous
ov write
s:
--i616tqyc3hrkKsk2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Nov 24, 2009 at 05:18:29PM +0200, Mikolaj Golub wrote:
pthread_cleanup_push/pop are supposed to be used from the common
lexical scope. Citation from SUSv4:
These functions may be implemented as macros. The application shall
ensure that they appear as statements, and in pairs within the same
lexical scope (that is, the pthread_cleanup_push() macro may be
thought to expand to a token list whose first token is '{' with
pthread_cleanup_pop() expanding to a token list whose last token is the
corresponding '}' ).
Your change is wrong.
Basically, the code should do
pthread_cleanup_push(some_func, arh);
something ...
pthread_cleanup_pop(1);
(1 denotes that some_func should be called).
The problem is that that expands to C code that can only be used
with newer C compilers. This expansion should be usable with all
C compilers.
#define pthread_cleanup_push(cleanup_routine, cleanup_arg)
\
{ \
struct _pthread_cleanup_info __cleanup_info__; \
__pthread_cleanup_push_imp(cleanup_routine, cleanup
_arg,\
__cleanup_info__)
#define pthread_cleanup_pop(execute)
\
__pthread_cleanup_pop_imp(execute);\
} ((void)0)
Hmm, agreed. But note that Solaris 10 does it this way:
#define pthread_cleanup_push(routine, args) { \
_cleanup_t _cleanup_info; \
__pthread_cleanup_push((_Voidfp)(routine), (void *)(args), \
(caddr_t)_getfp(), _cleanup_info);
#define pthread_cleanup_pop(ex) \
__pthread_cleanup_pop(ex, _cleanup_info); \
}
Writing portable macros that don't generate compiler warnings is fun. :-)
Tricks like do { body } while (0) and { body } ((void)0) absorb
the pesky semi-colon.
--
DE
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: 8.0-RC USB/FS problem
Interesting now by some incident :-) The single CPU machine (Intel P4) with 8.0 works fine on the USB drives and the USB stick. So, installed 8.0 on another AMD Turion64 HP Pavilion dv5210us Laptop, it comes the same problem -- accessing the USB hard drive causes system panic and reboot: Took the previously dump/restored USB drive and mount it on this Laptop, tried to remove the data before dump/restore, it crashed the system after hit ^C and unplugged USB hard drive when the LED on USB hard drive becomes solid red and spiting out numbers of lines Operation not permitted (the user is root, so this means accessing hard drive is not possible): rm: bin/... : Operation not permitted .. A second try causes the system locks up After ^C. So, try to re-partitioning the USB hard drive on AMD laptop and dump/restore, partitioning passed, but dump/restore crashed. Since hw.usb.umass.debug=-1 does not tell a USB problem beside the RESET, What other debug shall we turn on to analyze this problem. -Original Message- From: Guojun Jin Sent: Tuesday, November 24, 2009 12:13 AM To: Guojun Jin; Hans Petter Selasky; freebsd-...@freebsd.org Cc: b...@freebsd.org; freebsd-stable@freebsd.org Subject: RE: 8.0-RC USB/FS problem Freshly installed 8.0-RELEASE on two differnt machines, and USB stick work well so far, but the USB hard drive still has crash on this SMP (4-core AMD phenom 9600) during the dump/restore. I will try it on the single CPU machine tomorrow. Re-tested dump/restore with FreeBSD 6.3/6.4 on this SMP machine and they are working well. Also the another strange thing ocurred during the mount a partition on /tmp, which ended with two /tmp, and the last one mounted is on the top (the first should be hidden): : df Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s1a756750 165484 53072624%/ devfs 110 100%/dev /dev/ad0s2e 43194318 27833648 1190512670%/data /dev/ad0s2d 9135182 5870390 253397870%/home /dev/ad0s1e50763034882 432138 7%/tmp /dev/ad0s1f 13246730 1424522 1076247012%/usr /dev/ad0s1d 507703812700 4658176 0%/var /dev/da0s2 661176 487660 12062280%/mnt /dev/da1s3d 91351824 8404364 0%/dist /dev/da1s3e 749389484 68943830 0%/tmp : df /tmp Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/da1s3e 749389484 68943830 0%/tmp -Original Message- From: Guojun Jin Sent: Sun 11/22/2009 7:59 PM To: Hans Petter Selasky; freebsd-...@freebsd.org Cc: b...@freebsd.org; freebsd-stable@freebsd.org Subject: RE: 8.0-RC USB/FS problem From more intensive diagnose, it looks like more related USB layer. repeated a few time on following process and ithe crash happened at different USB access phase at each time. dd if=/dev/zero of=/dev/da0 count=1000 bs=4k sysinstall partition slice 1 (da0s1) 18GB ID=12 slice 2 (da0s2) 10-15GB Id=165 slice 3 (da0s3) rest ID=165 W --- OK label da0s3d 9GB /mnt da0s3e rest/dist W --- da0s3e device is not configured. w# ll /dev/da0* # after sysinstall did partition + W at 1st time crw-r- 1 root operator0, 97 Nov 22 11:23 /dev/da0 crw-r- 1 root operator0, 98 Nov 22 11:23 /dev/da0s1 crw-r- 1 root operator0, 99 Nov 22 11:23 /dev/da0s2 crw-r- 1 root operator0, 100 Nov 22 11:23 /dev/da0s3 # ll /dev/da0* # after sysinstall start at 2nd time crw-r- 1 root operator0, 97 Nov 22 11:27 /dev/da0 System crashed The crash log is available at http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 (All logs are based on hw.usb.umass.debug=-1) After system reboot, and repeated above processes, the da0s3e was mounted on /dist, but da0s3d cannot. It tunred out that newfs fail inside labeling process in sysinstall. Manually did newfs on da0s3d, and it cannot be mounted on /mnt, but access to it caused crash. The crash log is available at http:/www.daemonfun.com/archives/pub/USB/newfs Tried entire process again, this time, both partitons are formatted (newfs) inside labaling process (sysinstall) but crahsed system during dump/restore on da0s3e (/dist). The crash log is available at http:/www.daemonfun.com/archives/pub/USB/usb-log.crash2.bz2, which is huge one. It contains two parts, one dump/restore IDE to da0s3d (passed), and the rest is dump/restore to da0s3e (crashed). I am going to reinstall the system with the new ISO from Nov 21 8.0-RELEASE to see if anything will improve. -Original Message- From: Hans Petter Selasky [mailto:hsela...@c2i.net] Sent: Sun 11/22/2009 1:47 AM To: freebsd-...@freebsd.org Cc: Guojun Jin; b...@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Sunday 22 November 2009 05:38:13 Guojun Jin wrote: Tried on the USB hard drive:
sackcloth and ashes time
Dear FreeBSD friends; I recently added my gmail contacts to Linked-In, Inviting only those who were already on Linked-In, and discovered -- thanks to Bruce Cran -- that it came to STABLE. Looking in Linked-In at his profile, Mr Rotaev's public e-mail address address is clearly noted as being freebsd-sta...@freebsd.org. I have requested that Linked-In customer service address the matter, as I cannot contact him without causing more of the same spam in your mailboxes. He does not appear to be an active Linked-In user. Thank you all in advance for your understanding! :D -- -- Don Wilde Convince by Example http://www.EngineeringJobFuture.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
Daniel Eischen wrote:
Hmm, agreed. But note that Solaris 10 does it this way:
#definepthread_cleanup_push(routine, args) { \
_cleanup_t _cleanup_info; \
__pthread_cleanup_push((_Voidfp)(routine), (void *)(args), \
(caddr_t)_getfp(), _cleanup_info);
#definepthread_cleanup_pop(ex) \
__pthread_cleanup_pop(ex, _cleanup_info); \
}
Hmm, I considered using this style, but if there is a C++ object within
the lexical scope, its destructor will execute after
pthread_cleanup_pop(), this may not be correct, so I used extra pair of
'{}'.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
