Re: removing external usb hdd without unmounting causes reboot?
On 19/07/07, M. Warner Losh [EMAIL PROTECTED] wrote: [...] The best one can do without massive buffer cache work is what firewire does: it has one attachment to handle all umass devices. When the device goes away, it pauses all operations to that device. If the device comes back, it resumes the I/O . If the device never comes back, then the I/O never finishes. Is this safe? I don't know where locking occurs in this case, but if locking occurs on a very low level it's potentially dangerous. If a device is removed (either on purpose or by accident) the kernel can't determine the state of the filesystem anymore. So the user could plug the device into another machine, start some write operations on the device, and put it back into the FreeBSD machine. This wouldn't know anything about the changes done, and just flush its buffer, probably using blocks that have been filled previously. It's a pity that FreeBSD can't handle these situations. Since no one here on this list has enough money to get development on the road, maybe we could try collecting money? Everyone interested in seeing this issue fixed offers the amount of money he/she likes to spend... I guess for a Summer of Code project this issue would be to big to fix, wouldn't it? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firefox crashing after portupgrade 13 July
On Thu, 19 Jul 2007 21:27:25 -0500
Bruce Burden [EMAIL PROTECTED] wrote:
Problem: Firefox segmentation faults when using link encryption. This
happens on AMD64 and i386 versions (Opteron and P4 processors)
as well as Firefox 1.5, 2.0.0.3 and 2.0.0.4
Hi Bruce,
that's strange, ffox has been working fine here ...since 1.x . Have you
completely uninstalled all Mozilla related packages before installing ffox?
are you using a clean profile? You can create a new profile with firefox
-ProfileManager .
Alternatively, if you attach ktrace the the firefox-bin before you click on the
https link you may get something useful in the kdump.out file.
B
_
{Beto|Norberto|Numard} Meijome
Too bad ignorance isn't painful.
Don Lindsay
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firefox crashing after portupgrade 13 July
On 20/07/07, Bruce Burden [EMAIL PROTECTED] wrote: Hi folks, Problem: Firefox segmentation faults when using link encryption. This happens on AMD64 and i386 versions (Opteron and P4 processors) as well as Firefox 1.5, 2.0.0.3 and 2.0.0.4. [...] Mozilla 1.7.13 IS working, so what would be the basic differences on how they handle link encryption? Do you use any extensions? I've seen it a couple of times that Firefox becomes unstable after an upgrade. In this case I start by moving ~/.mozilla/firefox to another location and start from scratch. I don't know if this is the same as Norberto suggests (creating a new profile). HTH Christian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd just sits there and does nothing
Hi, [LoN]Kamikaze wrote: Doug Hardie wrote: On Jul 19, 2007, at 10:08, [LoN]Kamikaze wrote: As the subject says, on my 6-stable systems ntpd just sits there and does nothing. The logs only mention when the daemon gets started or shut down. It complains when servers are not reachable, but does nothing when they are available. The drift file always contains 0.00. ntpdate and openntpd both successfully manage to set the time, so I suppose it's a problem with ntpd. Are you on a static IP address? If not, ntpd obtains its IP address when it starts up and uses it forever. If your IP address changes then it will not be able to communicate with the upstream ntp servers. It has to be restarted everytime your IP address changes. I have a static address. The trouble is it seems to operate fine, only it forgets to change the time when it differs from the time servers too much. Sometimes my clock goes wrong more than 1 second within a day. ntpd will not change time if the difference is too big - I think it should be less then 1000s. ntpdate will :) Also if you have increased your kernel secure level 2+ : In addition, kernel time changes are restricted to less than or equal to one second. Attempts to change the time by more than this will log the message ``Time adjustment clamped to +1 second''. So grep for ntpd in /var/log/messages and I'm sure you will find the problem. Other problem that I see is if you are behind NAT/firewall. Because ntpd make a request and wait for response on different port, so check your firewall configuration and blocked packets. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd just sits there and does nothing
Stefan Lambrev wrote: Hi, [LoN]Kamikaze wrote: Doug Hardie wrote: On Jul 19, 2007, at 10:08, [LoN]Kamikaze wrote: As the subject says, on my 6-stable systems ntpd just sits there and does nothing. The logs only mention when the daemon gets started or shut down. It complains when servers are not reachable, but does nothing when they are available. The drift file always contains 0.00. ntpdate and openntpd both successfully manage to set the time, so I suppose it's a problem with ntpd. Are you on a static IP address? If not, ntpd obtains its IP address when it starts up and uses it forever. If your IP address changes then it will not be able to communicate with the upstream ntp servers. It has to be restarted everytime your IP address changes. I have a static address. The trouble is it seems to operate fine, only it forgets to change the time when it differs from the time servers too much. Sometimes my clock goes wrong more than 1 second within a day. ntpd will not change time if the difference is too big - I think it should be less then 1000s. ntpdate will :) Also if you have increased your kernel secure level 2+ : In addition, kernel time changes are restricted to less than or equal to one second. Attempts to change the time by more than this will log the message ``Time adjustment clamped to +1 second''. So grep for ntpd in /var/log/messages and I'm sure you will find the problem. Other problem that I see is if you are behind NAT/firewall. Because ntpd make a request and wait for response on different port, so check your firewall configuration and blocked packets. My securelevel is -1, even starting with an accurate clock ntpd just slowly lets it drift away. I'm behind a 2 NATs, one of which I have no access to. However openntpd and ntpdate don't seem to be troubled by this. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Possible devd bug
Hi all,
I have been playing with OpenOspf lately, and I came to a place, when I needed
to ensure that an ethernet interface should always go into DOWN state when it
loses its link (physically, for example the switch becames turned off). I have
tried to hire the devd daemon to do the job with such small definitions:
notify 100 {
match system IFNET;
match typeLINK_DOWN;
media-type ethernet;
action /sbin/ifconfig $subsystem down;
};
notify 200 {
match system IFNET;
match typeLINK_UP;
media-type ethernet;
action /sbin/ifconfig $subsystem up;
};
And what is happening? Well, basically, when the interface detects that eth
cable has been detached, devd triggers and makes it DOWN, which is ok. But,
when the card got the cable attached once again (and interface detects the
media type and gets ACTIVE state) devd never triggers the second rule, which
should get the interface UP again.
I have tried that with replacing action statements with ones with proper
logging actions, and when interface is UP devd gets the proper state changes
information.
Now the question is: why devd doesent receive any information from interfaces
in DOWN state? Is that proper behaviour, or a bug? Thanks for any reply, and
for your attention.
P.S. I am resending this message to freebsd-stable list, as I am not sure if
freebsd-questions was a proper choice.
--
Bartłomiej Rutkowski [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd just sits there and does nothing
Can you send the output of ntp.conf? [LoN]Kamikaze wrote: Stefan Lambrev wrote: Hi, [LoN]Kamikaze wrote: Doug Hardie wrote: On Jul 19, 2007, at 10:08, [LoN]Kamikaze wrote: As the subject says, on my 6-stable systems ntpd just sits there and does nothing. The logs only mention when the daemon gets started or shut down. It complains when servers are not reachable, but does nothing when they are available. The drift file always contains 0.00. ntpdate and openntpd both successfully manage to set the time, so I suppose it's a problem with ntpd. Are you on a static IP address? If not, ntpd obtains its IP address when it starts up and uses it forever. If your IP address changes then it will not be able to communicate with the upstream ntp servers. It has to be restarted everytime your IP address changes. I have a static address. The trouble is it seems to operate fine, only it forgets to change the time when it differs from the time servers too much. Sometimes my clock goes wrong more than 1 second within a day. ntpd will not change time if the difference is too big - I think it should be less then 1000s. ntpdate will :) Also if you have increased your kernel secure level 2+ : In addition, kernel time changes are restricted to less than or equal to one second. Attempts to change the time by more than this will log the message ``Time adjustment clamped to +1 second''. So grep for ntpd in /var/log/messages and I'm sure you will find the problem. Other problem that I see is if you are behind NAT/firewall. Because ntpd make a request and wait for response on different port, so check your firewall configuration and blocked packets. My securelevel is -1, even starting with an accurate clock ntpd just slowly lets it drift away. I'm behind a 2 NATs, one of which I have no access to. However openntpd and ntpdate don't seem to be troubled by this. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firefox crashing after portupgrade 13 July
On Fri, 20 Jul 2007 09:07:10 +0200
Christian Walther [EMAIL PROTECTED] wrote:
Do you use any extensions? I've seen it a couple of times that Firefox
becomes unstable after an upgrade. In this case I start by moving
~/.mozilla/firefox to another location and start from scratch.
yeah,this is a bit more radical than creating a new profile, but outcome is the
same
I don't know if this is the same as Norberto suggests (creating a new
profile).
with a new profile u can still access the old info. I have my firefox always
start with the profile manager, and have 3 profiles available - one with
no extensions / skins at all, one with just the web page profiler extension,
and then my workhorse with lots of goodies.
i thought i had a way to start them all in parallel.. but i cant figure it out
now..oh well :)
_
{Beto|Norberto|Numard} Meijome
There are no stupid questions, but there are a LOT of inquisitive idiots.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible devd bug
On Fri, 20 Jul 2007 21:24:15 +
Maxim Vetrov [EMAIL PROTECTED] wrote:
Bart?omiej Rutkowski wrote:
Hi all,
I have been playing with OpenOspf lately, and I came to a place, when I
needed to ensure that an ethernet interface should always go into DOWN
state when it loses its link (physically, for example the switch becames
turned off). I have tried to hire the devd daemon to do the job with such
small definitions:
notify 100 {
match system IFNET;
match typeLINK_DOWN;
media-type ethernet;
action /sbin/ifconfig $subsystem down;
};
notify 200 {
match system IFNET;
match typeLINK_UP;
media-type ethernet;
action /sbin/ifconfig $subsystem up;
};
And what is happening? Well, basically, when the interface detects that eth
cable has been detached, devd triggers and makes it DOWN, which is ok. But,
when the card got the cable attached once again (and interface detects the
media type and gets ACTIVE state) devd never triggers the second rule,
which should get the interface UP again.
I have tried that with replacing action statements with ones with proper
logging actions, and when interface is UP devd gets the proper state
changes information.
Now the question is: why devd doesent receive any information from
interfaces in DOWN state? Is that proper behaviour, or a bug? Thanks for
any reply, and for your attention.
P.S. I am resending this message to freebsd-stable list, as I am not sure
if freebsd-questions was a proper choice.
Probably, there is another notify which action is executed before yours
:-) Devd stops scanning sections on the _first_ matched one. Run devd in
debug mode and watch
Regards,
Muxas
I did my tests with debugging and logger in action directives and now I can
confirm that
devd does not trigger, when you put eth interface into DOWN state by #ifconfig
ifnameX down.
Now, is that intentional behaviour or a bug? This makes those LINK_UP devd
triggers
totally unusable.
You can test this behaviour with such example ruleset:
http://rafb.net/p/gTm9CW93.html
--
Bartłomiej Rutkowski [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd just sits there and does nothing
On Fri, Jul 20, 2007 at 10:37:14AM +0300, Stefan Lambrev wrote: ... ntpd will not change time if the difference is too big - I think it should be less then 1000s. ntpdate will :) ... Please try to be a little more careful: the above is incorrect. From ntpd(8): -g Normally, ntpd exits with a message to the system log if the off- set exceeds the panic threshold, which is 1000 s by default. This option allows thetime to be set to any value without restriction; however, this can happen only once. If the thresh- old is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options. See the tinker command for other options. From ntpdate(8): DESCRIPTION Note: The functionality of this program is now available in the ntpd(8) program. See the -q command line option in the ntpd(8) page. After a suitable period of mourning, the ntpdate utility is to be retired from this distribution. Peace, david -- David H. Wolfskill [EMAIL PROTECTED] Anything and everything is a (potential) cat toy. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpMOPhEdpBMb.pgp Description: PGP signature
Re: Possible devd bug
Bartłomiej Rutkowski wrote:
On Fri, 20 Jul 2007 21:24:15 +
Maxim Vetrov [EMAIL PROTECTED] wrote:
Bart?omiej Rutkowski wrote:
Hi all,
I have been playing with OpenOspf lately, and I came to a place, when I needed
to ensure that an ethernet interface should always go into DOWN state when it
loses its link (physically, for example the switch becames turned off). I have
tried to hire the devd daemon to do the job with such small definitions:
notify 100 {
match system IFNET;
match typeLINK_DOWN;
media-type ethernet;
action /sbin/ifconfig $subsystem down;
};
notify 200 {
match system IFNET;
match typeLINK_UP;
media-type ethernet;
action /sbin/ifconfig $subsystem up;
};
And what is happening? Well, basically, when the interface detects that eth cable has been detached, devd triggers and makes it DOWN, which is ok. But, when the card got the cable attached once again (and interface detects the media type and gets ACTIVE state) devd never triggers the second rule, which should get the interface UP again.
I have tried that with replacing action statements with ones with proper logging actions, and when interface is UP devd gets the proper state changes information.
Now the question is: why devd doesent receive any information from interfaces
in DOWN state? Is that proper behaviour, or a bug? Thanks for any reply, and
for your attention.
P.S. I am resending this message to freebsd-stable list, as I am not sure if
freebsd-questions was a proper choice.
Probably, there is another notify which action is executed before yours
:-) Devd stops scanning sections on the _first_ matched one. Run devd in
debug mode and watch
Regards,
Muxas
I did my tests with debugging and logger in action directives and now I can
confirm that
devd does not trigger, when you put eth interface into DOWN state by #ifconfig
ifnameX down.
Now, is that intentional behaviour or a bug? This makes those LINK_UP devd triggers
totally unusable.
You can test this behaviour with such example ruleset: http://rafb.net/p/gTm9CW93.html
First of all, I can confirm that plugging and unplugging lan cable fires
corresponding devd trigger actions. I checked this by plugging and
unplugging cable :-) Look at /etc/devd.conf; this section is responsible
for bringing link up:
# Try to start dhclient on Ethernet like interfaces when the link comes
# up. Only devices that are configured to support DHCP will actually
# run it. No link down rule exists because dhclient automaticly exits
# when the link goes down.
#
notify 0 {
match system IFNET;
match typeLINK_UP;
media-type ethernet;
action /etc/rc.d/dhclient start $subsystem;
};
And, IMHO, second, because ...devctl hooks in at such a low level of
FreeBSD's NEWBUS system... [exerpt from devd - A device confguration
daemon by W. Losh] it does not react to soft actions. In other
words, I think, ifconfig commands do not generate hardware events. The
article is acessible via
http://www.usenix.org/publications/library/proceedings/bsdcon03/tech/losh.html.
And about http://rafb.net/p/gTm9CW93.html.
1. There is no system mentioned
2. Read the above article about section weights
Regards,
Muxas
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firefox crashing after portupgrade 13 July
On Fri, Jul 20, 2007 at 04:46:52PM +1000, Norberto Meijome wrote: On Thu, 19 Jul 2007 21:27:25 -0500 Bruce Burden [EMAIL PROTECTED] wrote: Problem: Firefox segmentation faults when using link encryption. This happens on AMD64 and i386 versions (Opteron and P4 processors) as well as Firefox 1.5, 2.0.0.3 and 2.0.0.4 that's strange, ffox has been working fine here ...since 1.x . Have you completely uninstalled all Mozilla related packages before installing ffox? I had not been using gnash, since it destabilized things too much, and ff handles the absense of a flash player much better than moz does. That leaves java, which is pretty necessary... :-) I have been wondering if the latest JDK were the cause, but ff works fine at work on a P4 w/6.2 and the same patch level of JDK15. OO is different, however, but I can't see that being an issue here. Alternatively, if you attach ktrace the the firefox-bin before you click on the https link you may get something useful in the kdump.out file. Thanks for the suggestion. I'll start with my laptop, which has the ports backdated to 17 June, and see what that does, then work forward. Bruce -- I like bad! Bruce BurdenAustin, TX. - Thuganlitha The Power and the Prophet Robert Don Hughes ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible devd bug
Bart?omiej Rutkowski wrote:
Hi all,
I have been playing with OpenOspf lately, and I came to a place, when I needed
to ensure that an ethernet interface should always go into DOWN state when it
loses its link (physically, for example the switch becames turned off). I have
tried to hire the devd daemon to do the job with such small definitions:
notify 100 {
match system IFNET;
match typeLINK_DOWN;
media-type ethernet;
action /sbin/ifconfig $subsystem down;
};
notify 200 {
match system IFNET;
match typeLINK_UP;
media-type ethernet;
action /sbin/ifconfig $subsystem up;
};
And what is happening? Well, basically, when the interface detects that eth cable has been detached, devd triggers and makes it DOWN, which is ok. But, when the card got the cable attached once again (and interface detects the media type and gets ACTIVE state) devd never triggers the second rule, which should get the interface UP again.
I have tried that with replacing action statements with ones with proper logging actions, and when interface is UP devd gets the proper state changes information.
Now the question is: why devd doesent receive any information from interfaces
in DOWN state? Is that proper behaviour, or a bug? Thanks for any reply, and
for your attention.
P.S. I am resending this message to freebsd-stable list, as I am not sure if
freebsd-questions was a proper choice.
Probably, there is another notify which action is executed before yours
:-) Devd stops scanning sections on the _first_ matched one. Run devd in
debug mode and watch
Regards,
Muxas
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd just sits there and does nothing
On Jul 20, 2007, at 3:37 AM, Stefan Lambrev wrote: Other problem that I see is if you are behind NAT/firewall. Because ntpd make a request and wait for response on different port, so check your firewall configuration and blocked packets. we have zero problems with ntpd behind a NAT firewall. The firewall has no special rules for ntp, but does 1:1 map the NTP server. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fatal trap 12: page fault while in kernel mode
Kai Storbeck wrote:
Hi all,
Somewhere our IMAP software triggers this panic, and after some
searching on my part I've found this report: kern/113823
(http://www.freebsd.org/cgi/query-pr.cgi?pr=113823cat=kern)
The software I am running is Dovecot serving IMAP to endusers and
webmail clients.
Perhaps one of the mutex hackers can dive into this problem, I can
help with more details if needed.
Kind regards,
Kai
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 06
fault virtual address = 0x104E
fault code = supervisor read, page not presentx
instruction pointer = 0x20:0xc0668f3dp
stack pointer = 0x28:0xe8916c70e
frame pointer = 0x28:0xe8916c7cn
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0s
current process = 9 (thread taskq)i
trap number = 12v
panic: page faulte
cpuid = 2
timeout(9) function: 0xc071a560(0) 0.028705867 s
Uptime: 2d20h58m42s
Dumping 3327 MB (2 chunks)
chunk 0: 1MB (154 pages) ... ok
chunk 1: 3327MB (851568 pages) 3311 3295 3279 3263 3247 3231 3215
3199 3183 3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991
2975 2959 2943 2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767
2751 2735 2719 2703 2687 2671 2655 2639 2623 2607 2591 2575 2559 2543
2527 2511 2495 2479 2463 2447 2431 2415 2399 2383 2367 2351 2335 2319
2303 2287 2271 2255 2239 2223 2207 2191 2175 2159 2143 2127 2111 2095
2079 2063 2047 2031 2015 1999 1983 1967 1951 1935 1919 1903 1887 1871
1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647
1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423
1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199
1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975
959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703
687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431
415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159
143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc0670918 in boot (howto=260) at ../../../kern/kern_shutdown.c:409
#2 0xc0670bfa in panic (fmt=0xc08d0a0d %s)
at ../../../kern/kern_shutdown.c:565
#3 0xc087819c in trap_fatal (frame=0xe8916c30, eva=260)
at ../../../i386/i386/trap.c:837
#4 0xc087794a in trap (frame=
{tf_fs = -393150456, tf_es = -1064959960, tf_ds = -393150424,
tf_edi = -935090688, tf_esi = -900488032, tf_ebp = -393122692, tf_isp
= -393122724, tf_ebx = 4, tf_edx = 6, tf_ecx = 2, tf_eax = 1,
tf_trapno = 12, tf_err = 0, tf_eip = -1067020483, tf_cs = 32,
tf_eflags = 65538, tf_esp = 1714, tf_ss = -1064340051})
at ../../../i386/i386/trap.c:270
#5 0xc08649ea in calltrap () at ../../../i386/i386/exception.s:139
#6 0xc0668f3d in _mtx_lock_sleep (m=0xca53a4a0, tid=3359876608, opts=0,
file=0xc08f75ad ../../../kern/uipc_usrreq.c, line=1714)
at ../../../kern/kern_mutex.c:546
#7 0xc0668b93 in _mtx_lock_flags (m=0x2, opts=0,
file=0xc08f75ad ../../../kern/uipc_usrreq.c, line=1714)
at ../../../kern/kern_mutex.c:288
#8 0xc06b204b in unp_gc (arg=0x0, pending=1)
at ../../../kern/uipc_usrreq.c:1714
#9 0xc068f7c0 in taskqueue_run (queue=0xc843ca80)
at ../../../kern/subr_taskqueue.c:257
#10 0xc068fb3e in taskqueue_thread_loop (arg=0x1)
at ../../../kern/subr_taskqueue.c:376
#11 0xc065d184 in fork_exit (callout=0xc068faf4 taskqueue_thread_loop,
arg=0xc09df4e8, frame=0xe8916d38) at ../../../kern/kern_fork.c:821
#12 0xc0864a4c in fork_trampoline () at
../../../i386/i386/exception.s:208
(kgdb)
I was getting this exact panic pretty much every week, I had 6.2-RELEASE
installed on about 10 machines. The one machine which was getting the
panic most often I upgraded to 6.2-STABLE on 'Mon Apr 2 13:53:14 PDT
2007' and it's been up for 108 days now without any issues. I've
submited this time and time again to the mailing lists and never found a
real answer, finally I just resorted to trying this 6.2-STABLE, now
since last month I updated the other 9 machines and haven't had this
panic at all.
Here is one of the original threads I started regarding this issue:
http://monkey.org/freebsd/archive/freebsd-hackers/200703/msg00127.html
Cheers,
Scott Oertel
Re: Dell PERC5/i SAS5/5IR - RAID monitoring
Tom Judge wrote: As for performance issues with the SAS5/i, there is a problem in the controller. A work arround was created by Scott Long which created a sysctl that could be set to cause the controller to turn on the on drive write cache's. These changes where commited to RELENG_6 on 2007-06-05 21:32:57 UTC. ... Here is the original commit log: scottl 2007-06-03 23:13:05 UTC FreeBSD src repository Modified files: sys/dev/mpt mpt.c mpt.h mpt_cam.c Log: mpt.c: mpt.h: Add support for reading extended configuration pages. mpt_cam.c: Do a top level topology scan on the SAS controller. If any SATA device are discovered in this scan, send a passthrough FIS to set the write cache. This is controllable through the following tunable at boot: hw.mpt.enable_sata_wc: -1 = Do not configure, use the controller default 0 = Disable the write cache 1 = Enable the write cache The default is -1. This tunable is just a hack and may be deprecated in the future. I set mpt.enable_sata_wc to 1, as hw.mpt.enable_sata_wc is, AFAIK not tunable in mpt_cam.c. This did not take any effect to the performance. Is there anything else to change ? -- Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PERC5/i SAS5/5IR - RAID monitoring
Michael Worobcuk wrote: Tom Judge wrote: As for performance issues with the SAS5/i, there is a problem in the controller. A work arround was created by Scott Long which created a sysctl that could be set to cause the controller to turn on the on drive write cache's. These changes where commited to RELENG_6 on 2007-06-05 21:32:57 UTC. ... Here is the original commit log: scottl 2007-06-03 23:13:05 UTC FreeBSD src repository Modified files: sys/dev/mpt mpt.c mpt.h mpt_cam.c Log: mpt.c: mpt.h: Add support for reading extended configuration pages. mpt_cam.c: Do a top level topology scan on the SAS controller. If any SATA device are discovered in this scan, send a passthrough FIS to set the write cache. This is controllable through the following tunable at boot: hw.mpt.enable_sata_wc: -1 = Do not configure, use the controller default 0 = Disable the write cache 1 = Enable the write cache The default is -1. This tunable is just a hack and may be deprecated in the future. I set mpt.enable_sata_wc to 1, as hw.mpt.enable_sata_wc is, AFAIK not tunable in mpt_cam.c. This did not take any effect to the performance. Is there anything else to change ? Not that I know of, do you have SAS or SATA disks attached to the controller? Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PERC5/i SAS5/5IR - RAID monitoring
Am 21.07.2007 um 00:18 schrieb Tom Judge: Michael Worobcuk wrote: Tom Judge wrote: As for performance issues with the SAS5/i, there is a problem in the controller. A work arround was created by Scott Long which created a sysctl that could be set to cause the controller to turn on the on drive write cache's. These changes where commited to RELENG_6 on 2007-06-05 21:32:57 UTC. ... Here is the original commit log: scottl 2007-06-03 23:13:05 UTC FreeBSD src repository Modified files: sys/dev/mpt mpt.c mpt.h mpt_cam.c Log: mpt.c: mpt.h: Add support for reading extended configuration pages. mpt_cam.c: Do a top level topology scan on the SAS controller. If any SATA device are discovered in this scan, send a passthrough FIS to set the write cache. This is controllable through the following tunable at boot: hw.mpt.enable_sata_wc: -1 = Do not configure, use the controller default 0 = Disable the write cache 1 = Enable the write cache The default is -1. This tunable is just a hack and may be deprecated in the future. I set mpt.enable_sata_wc to 1, as hw.mpt.enable_sata_wc is, AFAIK not tunable in mpt_cam.c. This did not take any effect to the performance. Is there anything else to change ? Not that I know of, do you have SAS or SATA disks attached to the controller? yes, SAS. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCSI error during boot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeremy Chadwick wrote:
On Wed, Jul 18, 2007 at 11:26:33PM +0200, Uffe R. B. Andersen wrote:
When I boot my FreeBSD 6.2-RELEASE-p6, I get the following error:
(pass0:ahc0:0:0:0): Vendor Specific Command. CDB: 85 8 e 0 0 0 1 0 0 0 0 0 0
0 e c 0
(pass0:ahc0:0:0:0): CAM Status: SCSI Status Error
(pass0:ahc0:0:0:0): SCSI Status: Check Condition
(pass0:ahc0:0:0:0): ILLEGAL REQUEST asc:20,0
(pass0:ahc0:0:0:0): Invalid command operation code: Command byte 0 is invalid
{snip}
pass0: QUANTUM ATLAS_V_18_WLS 0230 Fixed Direct Access SCSI-3 device
Your drive is a Quantum/Maxtor/Seagate Atlas V (presumably 10Krpm).
Correct, it's about 8 years old, Quantum on the label.
snip
The bottom line here is that your drive doesn't support a specific SCSI
command that's being submit to it. In this case, it looks to be harmless.
That's nice to know, though I didn't expect it to be critical, as the
disk has worked well for all 8 years, running with Windows 2000 and XP.
smartctl shows no errors on the disk, but this error occur:
(pass0:ahc0:0:0:0): MODE SENSE(06). CDB: 1a 0 19 0 40 0
(pass0:ahc0:0:0:0): CAM Status: SCSI Status Error
(pass0:ahc0:0:0:0): SCSI Status: Check Condition
(pass0:ahc0:0:0:0): ILLEGAL REQUEST asc:24,0
(pass0:ahc0:0:0:0): Invalid field in CDB: Command byte 2 is invalid
That should only occur when you run smartctl. SCSI operation
snip
ASC 0x24 0x00 for this drive means Invalid Field in CDB. Possibly
this is a drive firmware bug or simply an implementation difference;
I've seen similar reports from Seagate drives on Solaris when using
smartctl -a /dev/rdsk/whatever. The SMART results are shown, but it
throws an invalid CDB error on the console.
Exactly what I experience.
I tried booting the server on a Fedora 7 Live cd, ran smartctl and got
no error, so I assume the error is in the FreeBSD drivers.
How do I proceed, to get a fix for this problem?
It's not a problem, but admittedly it should be fixed somehow. The
So, who do I approach to get it fixed? I poked through the scsi quirks
page, but didn't find anything obvious...
SCSI errors you get when using smartctl are something to discuss with
Bruce Allen (author of smartmontools):
http://smartmontools.sourceforge.net/
Eventhough it does not appear when running smartctl from a Linux Live
cd, nor back when it was still running XP? It appears more like a
FreeBSD related issue to me, but I must admit that most of your
technical explanations are well above my level and I might have missed
some things.
Thanks for your answer anyway :)
- --
Med venlig hilsen - Sincerely
Uffe R. B. Andersen - mailto:[EMAIL PROTECTED]
http://www.twe.net/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (MingW32)
iD8DBQFGoSyHxC95nUQcrpgRAoFQAKD0VdIwzZqWBkcUH+3v+ncjm28W5QCgj8gU
rRGRQB8aQCJ5oCTzzqlydpQ=
=2m9u
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PERC5/i SAS5/5IR - RAID monitoring
Michael Worobcuk wrote: Am 21.07.2007 um 00:18 schrieb Tom Judge: Michael Worobcuk wrote: Tom Judge wrote: As for performance issues with the SAS5/i, there is a problem in the controller. A work arround was created by Scott Long which created a sysctl that could be set to cause the controller to turn on the on drive write cache's. These changes where commited to RELENG_6 on 2007-06-05 21:32:57 UTC. ... Here is the original commit log: scottl 2007-06-03 23:13:05 UTC FreeBSD src repository Modified files: sys/dev/mpt mpt.c mpt.h mpt_cam.c Log: mpt.c: mpt.h: Add support for reading extended configuration pages. mpt_cam.c: Do a top level topology scan on the SAS controller. If any SATA device are discovered in this scan, send a passthrough FIS to set the write cache. This is controllable through the following tunable at boot: hw.mpt.enable_sata_wc: -1 = Do not configure, use the controller default 0 = Disable the write cache 1 = Enable the write cache The default is -1. This tunable is just a hack and may be deprecated in the future. I set mpt.enable_sata_wc to 1, as hw.mpt.enable_sata_wc is, AFAIK not tunable in mpt_cam.c. This did not take any effect to the performance. Is there anything else to change ? Not that I know of, do you have SAS or SATA disks attached to the controller? yes, SAS. In that case the above sysctl is not going to work for you as as the name suggests it is only for sata devices. For someone with a bit more SCSI experience than me: Could this be solved by setting the WCE (Write cache enable) bit in the modepage (8) on sas devices if it is not already set? The driver could make this change on SAS devices during the topology scan in similar way to the way it does for SATA devices? Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: removing external usb hdd without unmounting causes reboot?
It won't fix it. The problem is dangling pointers to devices that no longer exist. And like all dangling references after 'free' you get bad thing happening. Believe me, if it were easy, it would have been fixed. If it was moderate to fix, it would have been fixed. It is a hard problem that people have put lots of hours into to try to resolve. To imply otherwise is really insulting to all those people (myself include) that have tried to fix this. There is a simple but ugly way to fix it, similar to what the FireWire layer does. The idea is for the USB layer to create a device that never goes away when it first sees the stick and pass that device that never goes away to the other layers. Even if the storage device is removed, the device still does not go away. The virtual device can generate errors if the physical device is missing. The virtual device can be cleaned up when the device is unmounted. This will ensure that the 'umount -f' process generates errors (which it will ignore) rather than crashes (which are somewhat harder to ignore). DS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Am 20.07.2007 um 08:16 schrieb Christian Walther: [...] It's a pity that FreeBSD can't handle these situations. Since no one here on this list has enough money to get development on the road, maybe we could try collecting money? Everyone interested in seeing this issue fixed offers the amount of money he/she likes to spend... I guess for a Summer of Code project this issue would be to big to fix, wouldn't it? Especially if I think about software RAID it's really a show-stopper. I remember a stress-test of *vinum* (without the g) years ago when I pulled the plug on one of the disks of a RAID5-plex... Obviously there's no change at all concerning this problem. - -- Ciao/BSD - Matthias Matthias Schuendehuettemsch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFGoTatf1BNcN37Cl8RAmTRAJ99PXwWaHxUq4I8P++hcMhpL5PSlwCgg5/R 9gy1Gj2+JYTRB5OvGOWFDF4= =XVsv -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On Thu, 19 Jul 2007 17:38:14 +0200
[LoN]Kamikaze [EMAIL PROTECTED] wrote:
As I mentioned earlier I remember it working during the 5.3 era on Stable, at
some point it worked. I even remember removing my CD-Rom drive from my
Thinkpad
without running atacontrol detach. The system just took it and the drive just
continued working after I put it back in.
on 6.2-STABLE (of a few days ago), i have this happening a couple of times with
no adverse effect at all.
Burn DVD/Cd, when finished, hald detects the disk, mounts it, /dev/cd0 in
/media/whatever.
i can eject the disk just fine (which in itself is weird, i think) the
device is still there...
umount /dev/cd0
works fine and off it goes. other than that, no, i havent tried to access the
device in question
_
{Beto|Norberto|Numard} Meijome
The people have always some champion whom they set over them and nurse into
greatness...
This and no other is the root from which a tyrant springs; when he first
appears he is a protector.
Plato
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On Thu, 19 Jul 2007 09:02:50 -0600 (MDT)
M. Warner Losh [EMAIL PROTECTED] wrote:
In message: [EMAIL PROTECTED]
Momchil Ivanov [EMAIL PROTECTED] writes:
: What is then the reason for the kernel not being able to unmount a
: filesystem whose provider is no longer present?
The problem is that the device driver has wound down, deallocated
memory, etc. Now the kernel comes along with stale references to the
device and panic ensues. It is really just that simple. There's no
replacement of the now-dead device with dead calls.
And even if you fixed that, most of the file systems in the tree today
do not tolerate errors on writes at all and that also leads to
panics. This is why firewire freezes the I/Os rather than failing
them (and why umount -f on a firewire drive hangs).
Please point me to the correct RTFM, because I feel this worth it :)
Is there a reason why the kernel cannot check 'upwards' if a device is being
used, ie mounted ? and prevent the unloading of the device driver ?
thanks for your time illuminating this ignoramus :)
_
{Beto|Norberto|Numard} Meijome
Egotism is the anesthetic that dulls the pain of stupidity.
Frank Leahy
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCSI error during boot
On Fri, 20 Jul 2007 23:43:35 +0200 Uffe R. B. Andersen [EMAIL PROTECTED] wrote: That's nice to know, though I didn't expect it to be critical, as the disk has worked well for all 8 years, running with Windows 2000 and XP. IMHO, you should never use working on win... as a statement to say that some hardware is a) working b) compliant with a standard Just my two cents (having seen too much of broken hw and standards on win through the years). -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
