Re: GEOM_RAID3: Device datos is broken, too few valid components
"José M. Fandiño" wrote: > > Pawel Jakub Dawidek wrote: > > +> Unfortunately, the metadata structure of my data partition (a geom raid3 > > +> array with tree components ) seems to be corrupted by this hard lock, > > +> the following message is scrolled constantly on the screen: > > +> > > +> GEOM_RAID3: Device datos created (id=3217021940). > > +> GEOM_RAID3: Device datos: provider ad6s2 detected. > > +> GEOM_RAID3: Device datos: provider ad5s2 detected. > > +> GEOM_RAID3: Device datos: provider ad4s2 detected. > > +> GEOM_RAID3: Component ad6s2 (device datos) broken, skipping. > > +> GEOM_RAID3: Component ad4s2 (device datos) broken, skipping. > > +> GEOM_RAID3: Device datos is broken, too few valid components. > > +> GEOM_RAID3: Device datos destroyed. > > +> > > +> Checking the search engine results it isn't a very usual problem, the > > advice > > +> in the returned hits is rerunning "graid label -h datos ad4s2 ad5s2 > > ad6s2", > > +> but before of erasing all my data I would like to ask to list members. > > +> > > +> How dangerous is running the mentioned command in this context? > > > > You should be safe as long as the order of slices you give here is the > > same as it was when device was initially labeled. > > I don't remember the exact order (my history file is only 2000 lines > long :) however I'm going to duplicate two disks, because they are > the minimum necessary to reconstruct the raid3, and I will do some tests > over them, so I can maintain intact the original disks. Pawel, there is a 'dump' parameter for graid3 (it isn't mentioned in the manual page but you can see it if you run graid3 in help mode) would it be sufficient follow the order indicated by the 'no' field? something like: graid3 label -h datos ad5s2 ad6s2 ad4s2 # graid3 dump ad4s2 Metadata on ad4s2: magic: GEOM::RAID3 version: 4 name: datos id: 3217021940 no: 2 all: 3 genid: 2 syncid: 24 mediasize: 311491352576 sectorsize: 1024 syncoffset: 0 mflags: ROUND-ROBIN dflags: NONE hcprovider: provsize: 155745676800 MD5 hash: 3592c58adc68a476ce5253d2629f5c77 # graid3 dump ad4s 5s2 Metadata on ad5s2: magic: GEOM::RAID3 version: 4 name: datos id: 3217021940 no: 0 all: 3 genid: 0 syncid: 24 mediasize: 311491352576 sectorsize: 1024 syncoffset: 0 mflags: ROUND-ROBIN dflags: NONE hcprovider: provsize: 155745676800 MD5 hash: 5dc9f22fb87c2d14c80cbd6b84dc4496 # graid3 dump ad6s2 Metadata on ad6s2: magic: GEOM::RAID3 version: 4 name: datos id: 3217021940 no: 1 all: 3 genid: 2 syncid: 24 mediasize: 311491352576 sectorsize: 1024 syncoffset: 0 mflags: ROUND-ROBIN dflags: DIRTY hcprovider: provsize: 155745676800 MD5 hash: 75f9c48df82fcbd75b1b5d6abc4c763c -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/IT d- s+:+() a32 C+++ UBL+++$ P+ L+++ E--- W++ N+ o++ K- w--- O+ M+ V- PS+ PE+ Y++ PGP+>+++ t+ 5 X+$ R- tv-- b+++ DI D++>+++ G++ e- h+(++) !r !z --END GEEK CODE BLOCK-- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror on existing filesystem (was Fresh install on gmirror'ed disks?)
On Thu, Apr 06, 2006 at 09:33:31AM -0400, Mike Jakubik wrote: +> Pawel Jakub Dawidek wrote: +> >One can still see how many sectors exactly has the partition he is going +> >to create file system on and add additional newfs(8) flag +> >'-s '. +> > +> +> "gmirror utility uses on-disk metadata (stored in the provider's last sector) to store all needed information." +> +> Would creating a freebsd partition thats slightly smaller than the disk resolve the issue (when mirroring the entire disk)? or does it still use the last sector of the +> label? I'm not sure what one means by "provider" in this case. "provider" in this case is what you use to create mirror on. If you do it by: # gmirror label foo ad0 ad2 Then disks ad0 and ad2 are providers where gmirror puts metadata in their last sector. In most cases, you create slices and then partitions. If you configure a mirror on partitions, eg. # gmirror label foo ad0s1a ad2s1a then you need to create file system one sector smaller with newfs(8) when you do it on adXs1a. When you configure a mirror on slices, eg. # gmirror label foo ad0s1 ad2s1 then your last partition created on adXs1 must end up before the slice end (its offset+size should be one sector smaller than the size of the slice). When you configure a mirror on disks, eg. # gmirror label foo ad0 ad2 then your last slice created on adXs1 have to end up before the disk end (just like in the previous case). In most cases, last slice ends before the disk end, leaving plenty of space at the end, so you should be safe here. In other cases the whole space is allocated (not sure if really used). In any case, system may complain if information about the original provider size is stored somewhere, ie. partitions were created on one sector bigger slice than gmirror provider, so 'c' partition will be one sector too large. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp9qa9rGnv2S.pgp Description: PGP signature
Re: Disappointed
>>> Who in their right mind would think that "stable" actually means >>> "stable"!!! >>> >> >> It does mean that the API is stable. >> /\ >> || >> > Then maybe it should be called api-stable!! You can't believe how disappointed I was. I thought I was going to get a pony in a stable. I'm never using FreeBSD again. It just doesn't live up to its name. I'm going back to alt.binaries.pictures.horses! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Disappointed-new
Hi all
I've sent a message two days ago with "Disappointed" subject.
Many of you answer me I don't have describe the bug.
Well, first my english is very bad, and second I don't blame anyone, never
the developper. Personnaly I'm very impresse by the work you doing.
Now a fine description of my problem.
Hardware :
HP Proliant ML 350 G4
2 x Xeon 3.2 Ghz (HT disable)
1 Go Ram
1 bge network interface on mothercard
1 dual 1000Mbits/s (em chipset)
1 dual 100Mbits/s (fxp chipset)
1 Internal 641 Smart Array with 2 Hotplug disk in raid 1
1 MSA1000 with 14 disk on fiber channel attachement
Situation :
On every network card we have different IP subnet
Every network card have he's owne IP address
All interface is connected on Foundry 1000 Mbits/s switch L2
Purpose :
It's central nfs server (NetApp for «small» budget...), the server
run a dhcpd server and that's all.
There are no user account on this server.
The server is not routed on Internet.
The nfs is bind on 3 of 5 IP number (the 2 other is just running
ssh for scp)
There are 13 nfs clients running Linux (different version of
kernel)
There are also 4 nfs clients running FreeBSD (different version but
all > 5.2 and < 5.5)
In the time :
The 6-stable is installed on the server on begin of February 2006
Problems :
First time :
Kernel : SMP+ipfw
In first time the «main» nfsd is bind on the bge0 interface
(main=90% nfs traffic)
After 10-15 days of perfect running, the bge0 don't work, but the
other interface working perfectly. The server is up and the other
nfs clients can acces without problem the nfs partition. I can
logon the console. And I've try many
ifconfig bge0 down
ifconfig bge up
ifconfig bge0 delete
etc...
nothing work
On the console the are repeatly message like
bge0 watchdog timeout problems
bge0 watchdog timeout problems
Only (for me) reboot can make the system re-work. And after reboot
everything work fine.
But after some days the problem is come again. And in this second case
all
interfaces don't work. But the I always can logon in the console.
But the reboot is not clean (I need to make a big fsck)
Second time :
Kernel : NO_SMP +ipfw
After some advice on this mailing-list I switch to mono-proc
version of the kernel.
This time after some days working fine the bge0 don't work again
(same condition of first time)
third time :
Kernel : NO_SMP + ipfw
I switch the main nfs(=90% of traffic) interface to em0 and put a
not running nfs (only scp) ip number on the bge0.
Again after some days the em0 interface don't work. And this
time the message on console is
em0 watchdog timeout problems
sometime I have fxpX watchdog timeout problem too
forth time :
Kernel : NO_SMP + polling + ipfw
Now I'm running all interface in polling mode. And...I hope it's
work...(running from 2 days).
Information :
I can't tell if it's during heavy nfs load, but I really don't
think. There are on crash during saturday (and we don't have many
users in this day).
I cannot reproduce this bug. I've try to make a big nfs access (on
4 linux clients I'm running in same time something like
find . -type f -exec md5sum {} \;
but he won't crash. In this partition there are 30 Go.
I forget to tell I'm running a very close configuration (a old ML350G3 with
same MSA1000 in same condition) with 4.x during 4 years without any crash
(with the same clients etc...)
In attachement the dmesg just after the server boot.
Next Monday I switch to DB kernel but now I just can reboot the server (600
users).
I hope that's can help you to make FreeBSD better than best OS ;-) .
Lots of thanks.
--
Albert SHIH
Universite de Paris 7 (Denis DIDEROT)
U.F.R. de Mathematiques.
Heure local/Local time:
Fri Apr 7 13:38:55 CEST 2006
Copyright (c) 1992-2006 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 6.1-PRERELEASE #1: Wed Apr 5 17:27:03 CEST 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/NFS3-mono
ACPI APIC Table:
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf41 Stepping = 1
Features=0xbfebfbff
Features2=0x641d>
AMD Features=0x2000
Hyperthreading: 2 logical CPUs
real memory = 1073688576 (1023 MB)
avail memory = 1041752064 (993 MB)
ioapic1
Re: Disappointed
ok! tell me, how can i help you to make "stable" - stable? please. don't answer me - GIVE US MONEY! i will not pay! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pros and Cons of amd64 (versus i386).
Sex, 2006-04-07 às 00:18 -0400, Tim Middleton escreveu: > Skipping all of your technical questions I'll tell you my experience. The > only regret i have is one that makes me sometimes wish I'd not upgraded my > desktop 64 bit... the dri drivers for xorg lock up my box (ATI card). This > has been a thorn in my side for over 6 months now, but I just haven't had > the time to try to debug and deal with it... My amd64 desktop works fine, also with ATI card. There are always problems. I have them with ehci, but the same problem with amd64 and i386. I suppose every hardware/os change must imply some compatibility testing. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Disappointed
Alexey Karagodov wrote: ok! tell me, how can i help you to make "stable" - stable? please. don't answer me - GIVE US MONEY! i will not pay! (1) install -STABLE on a variety of hardware and put load on it (2) carefully note any issues, collecting as much detail as possible (3) search the archives and the documentation to find out if the issue is already addressed by configuration elements or procedures that you can tune or try yourself (4) if you didn't fix the problem at step 3, take a few deep breaths, open your mind, and post a properly detailed question to the proper list. Ideally, do this without injecting lots of attitude or disappointment, since those will not help get the problem fixed and may in fact result in not getting help . Generally no one is expected to pay cash, but since we don't pay cash we should at least pay respect. (5) apply suggested patches, perform suggested tests, add requested details, then return to step number (2) as needed. (6) Repeat from step (1) as frequently as you have time to give. If you don't have the time or patience for all this work, choose: (a) pay someone to have the time and patience for you (b) stick to running -RELEASE Sorry, I know you said not to say "pay", but note that this is suggested in the context of you making a choice, it is not a demand you must submit to. -- Greg Barniskis, Computer Systems Integrator South Central Library System (SCLS) Library Interchange Network (LINK) , (608) 266-6348 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Disappointed
thanx :) it not everytime working (i've this exprerience), but i will try :) to ask help again if needed ... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sio+acpi woes on HP DL145
Greetz! I have an HP DL145 that I'm having problems with when connecting via serial console. I think it's acpi-related. This is on 6.1-BETA4/amd64 (5.X is the same also) Initially: [EMAIL PROTECTED]:~# vmstat -i interrupt total rate irq1: atkbd0 1 0 irq4: sio0 6 0 irq14: ata0 46 3 irq16: bge0 120 8 irq20: ohci0 5 0 irq21: ehci0 1 0 irq22: atapci1 704 46 cpu0: timer27375 1825 Total 28258 1883 Then I connected its serial to another FreeBSD boxen's serial and ran tip on the other box... then bada-bing!! The 145 seems dead. Doesnt respond to anything (well except for ICMP tho)... until I kill the other boxen's tip process. Then the box is alive again. One thing I've noticed, it sends the acpi interrupts thru the roof: [EMAIL PROTECTED]:~# vmstat -i interrupt total rate irq1: atkbd0 1 0 irq4: sio016 0 irq9: acpi0 363925284 irq14: ata0 46 0 irq16: bge0 589 0 irq20: ohci0 5 0 irq21: ehci0 1 0 irq22: atapci1 901 0 cpu0: timer 2559105 1997 Total2924589 2283 If i disable acpi by setting hint.acpi.0.disabled=1 in loader.conf I do not experience the problem above. Somebody else has experienced this and he's CC'd: http://lists.freebsd.org/pipermail/freebsd-stable/2005-November/019286.html Is this somewhat related to: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83671 ? Verbose dmesg is attached. Thanks ;-) cheers mars dmesg_145.boot Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Needs suggestion for redundant Storage
Hi everyone, i need suggestions and hints about an redundant storage-system. My requirements are: a Storage that is available via Network, flexible in scalation, and must be redundant, and cheap if possible My Own suggestion was this scenario: 2 boxes very cheap for ~300$ 2 or more SATA-II-Controller ~30$(SIL) 4 or more Disks with 200-250GB ~100$/piece the configuration that i think: the 2 boxes became 2 virtaul IP-Addresses for CARP to manage Master/Slave. the Extra SATA disks get configured wit geom as big volumes or any other configuration (not very important, but the 2 boxes should have the same configuration) the big-Volume created by geom/ccd/gvinum or any other should get mirrored over the Net to the other box.i think ggated/ggated get my best friends... Has anyone experiences or suggestion for those scenario? the only component that i has used today was gmirror.. thanks a lot for any Help. regards michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: resolver doesn't see resolv.conf changes
Hi, > On Wed, 5 Apr 2006 17:27:19 +0200 > Ulrich Spoerlein <[EMAIL PROTECTED]> said: spoerlein> Is the resolver supposed to periodically check for updates to the spoerlein> resolv.conf, or are the applications somehow caching the IP of the DNS spoerlein> server? Traditionally, the resolver doesn't reread resolv.conf. It is not useful for especially mobile environment. So, I wrote a patch to reread resolv.conf in past. Recently, I noticed that it could be implemented as a NSS plug-in, and made it just today. You can get it from: http://www.imasy.or.jp/FreeBSD/nss_resinit-20060408.tar.gz I don't write any documentation, yet. But, it should work by changing `hosts' entry in /etc/nsswitch.conf to the following line: hosts: resinit files dns It seems working on my 7-CURRENT box and 6-STABLE box. However, it should be tested more. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],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 "[EMAIL PROTECTED]"
Re: resolver doesn't see resolv.conf changes
Hi, > On Fri, 7 Apr 2006 12:15:54 -0400 > "Rong-En Fan" <[EMAIL PROTECTED]> said: grafan> The file is not there. I got 404. Oops, it should be: http://www.imasy.or.jp/~ume/FreeBSD/nss_resinit-20060408.tar.gz Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],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 "[EMAIL PROTECTED]"
Re: resolver doesn't see resolv.conf changes
> Hi, > >> On Wed, 5 Apr 2006 17:27:19 +0200 >> Ulrich Spoerlein <[EMAIL PROTECTED]> said: > > spoerlein> Is the resolver supposed to periodically check for updates to > the > spoerlein> resolv.conf, or are the applications somehow caching the IP of > the DNS > spoerlein> server? > > Traditionally, the resolver doesn't reread resolv.conf. It is not > useful for especially mobile environment. So, I wrote a patch to > reread resolv.conf in past. > Recently, I noticed that it could be implemented as a NSS plug-in, and > made it just today. You can get it from: > > http://www.imasy.or.jp/FreeBSD/nss_resinit-20060408.tar.gz > > I don't write any documentation, yet. But, it should work by changing > `hosts' entry in /etc/nsswitch.conf to the following line: > > hosts: resinit files dns > > It seems working on my 7-CURRENT box and 6-STABLE box. However, it > should be tested more. Alternatively, it is possible to use caching DSN server on local machine. In reslolv.conf you can write 'nameserver 127.0.0.1' and then reconfigure and restart bind than connecting to different networks. Applications still use 127.0.0.1 as nameserver. And no any patches. Works for me. May be not suitable for all situations. :) -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Needs suggestion for redundant Storage
Michael Schuh wrote: Hi everyone, i need suggestions and hints about an redundant storage-system. My requirements are: a Storage that is available via Network, flexible in scalation, and must be redundant, and cheap if possible My Own suggestion was this scenario: 2 boxes very cheap for ~300$ 2 or more SATA-II-Controller ~30$(SIL) 4 or more Disks with 200-250GB ~100$/piece You've obviously chosen to prioritize cheap above anything else with these recommendations. :-) You simply can't spend less than a grand and expect to get even one decent fileserver, much less a pair of machines. Do not get a Silicon Image SATA controller. If you want to value redundancy and the ability to scale, you ought to look at NAS or SAN systems, such as NetApp filers, or maybe even an Apple Xserve and a Fibre-channel switch. Even if you're not willing to pay that much, you should at least consider what those solutions offer for their pricepoints, and then decide what your data is worth to you and what your requirements should be. At the very least, get a multiport SATA RAID controller with a decent-sized RAM cache of its own and an internal battery to keep the drives going until that cache can be flushed. As well as an external UPS, right...? -- -Chuck ___ 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 / current process=12 (swi1: net)
in case someone is keep tracking this - I can confirm that the issue
seems to went away since about week old RELENG_6.
--
Vlad
On 3/17/06, Vlad <[EMAIL PROTECTED]> wrote:
> and here comes another fresh one
>
> # kgdb kernel.debug /var/crash/vmcore.1
> [GDB will not be able to debug user-mode threads:
> /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
> 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 "amd64-marcel-freebsd".
>
> Unread portion of the kernel message buffer:
> kernel trap 12 with interrupts disabled
>
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x48
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0x80263071
> stack pointer = 0x10:0xa52fe8d0
> frame pointer = 0x10:0xff002a2144c0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= resume, IOPL = 0
> current process = 12 (swi1: net)
> trap number = 12
> panic: page fault
> Uptime: 25m3s
> Dumping 1023 MB (2 chunks)
> chunk 0: 1MB (152 pages) ... ok
> chunk 1: 1023MB (261888 pages) 1008 992 976 960 944 928 912 896 880
> 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608
> 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336
> 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32
> 16
>
> #0 doadump () at pcpu.h:172
> 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
> (kgdb) list *0x80263071
> 0x80263071 is in propagate_priority
> (../../../kern/subr_turnstile.c:235).
>
> 230 /*
> 231 * Pick up the lock that td is blocked on.
> 232 */
> 233 ts = td->td_blocked;
> 234 MPASS(ts != NULL);
> 235 tc = TC_LOOKUP(ts->ts_lockobj);
> 236 mtx_lock_spin(&tc->tc_lock);
> 237
> 238 /* Resort td on the list if needed. */
> 239 if (!turnstile_adjust_thread(ts, td)) {
> (kgdb)
> 240 mtx_unlock_spin(&tc->tc_lock);
> 241 return;
> 242 }
> 243 mtx_unlock_spin(&tc->tc_lock);
> 244 }
> 245 }
> 246
> 247 /*
> 248 * Adjust the thread's position on a turnstile after its
> priority has been
> 249 * changed.
> (kgdb) backtrace
> #0 doadump () at pcpu.h:172
> #1 0x0004 in ?? ()
> #2 0x8023c133 in boot (howto=260) at
> ../../../kern/kern_shutdown.c:402
> #3 0x8023c736 in panic (fmt=0xff003dc19be0 "@\203(c)=")
> at ../../../kern/kern_shutdown.c:558
> #4 0x8037fa22 in trap_fatal (frame=0xff003dc19be0,
> eva=18446742975233884992)
> at ../../../amd64/amd64/trap.c:660
> #5 0x8037ff46 in trap (frame=
> {tf_rdi = -1098804804416, tf_rsi = 40, tf_rdx = 4294967294,
> tf_rcx = -1098475529184, tf_r8 = 1, tf_r9 = 0, tf_rax = 180, tf_rbx =
> -1098475529248, tf_rbp = -1098804804416, tf_r10 = -1098804804414,
> tf_r11 = 0, tf_r12 = -1098475529248, tf_r13 = -2143389918, tf_r14 = 0,
> tf_r15 = 40, tf_trapno = 12, tf_addr = 72, tf_flags = -2144456830,
> tf_err = 0, tf_rip = -2144980879, tf_cs = 8, tf_rflags = 65666, tf_rsp
> = -1523586848, tf_ss = 0}) at ../../../amd64/amd64/trap.c:238
> #6 0x8036e32b in calltrap () at ../../../amd64/amd64/exception.S:168
> #7 0x80263071 in propagate_priority (td=0xff002a2144c0)
> at ../../../kern/subr_turnstile.c:233
> #8 0x8026386f in turnstile_wait (lock=0x80554de0,
> owner=0x0) at ../../../kern/subr_turnstile.c:628
> #9 0x80232369 in _mtx_lock_sleep (m=0x80554de0,
> tid=18446742975234022368, opts=-2,
> file=0xff003dc19c20 "ю$h'", line=1) at ../../../kern/kern_mutex.c:565
> #10 0x80288d56 in sf_buf_mext (addr=0xff002a2144c0,
> args=0xff003ecf8260)
> at ../../../kern/uipc_syscalls.c:1710
> #11 0x8027cb39 in mb_free_ext (m=0xff003d910e00) at
> ../../../kern/uipc_mbuf.c:272
> #12 0x80283216 in sbdrop_locked (sb=0xff00089603c0, len=0)
> at mbuf.h:486
> #13 0x802e5576 in tcp_input (m=0xff002b27ac00,
> off0=27399968) at ../../../netinet/tcp_input.c:2136
> #14 0x802dc280 in ip_input (m=0xff002b27ac00) at
> ../../../netinet/ip_input.c:786
> #15 0x802c7c8b in netisr_processqueue (ni=0x8054ffd0)
> at ../../../net/netisr.c:236
> #16 0x802c7f2d in swi_net (dummy=0xff002a2
Re: [panic] ipw and kismet
On Thursday 06 April 2006 14:14, Ulrich Spoerlein wrote:
> Hello,
>
> I almost always get a panic when running kismet on my ipw-Interface
> under 6.1-PRERELEASE. This has been the case ever since ipw hit the
> tree. Sometimes kismet works, sometimes it doesn't. A sure way to
> trigger the panic is to switch between bss/ibss/monitor mode prior to
> running kismet. Perhaps there is a bug in the re-initialization when
> loading a different firmware?
>
> Is this panic known? Does the new firmware-framework address this?
The trace below seems unrelated to firmware loading, but there have been some
problems with firmware loading before and we hope to improve things with the
new firmware framework.
Could you try the attached patch, please? This is something I did for iwi and
just moved the general idea over without testing or close evaluation. So be
aware and let me know either way. Thanks.
> ipw0: mem 0xfaffc000-0xfaffcfff irq 9
> at device 3.0 on pci2 ...
> panic: mutex ipw0 recursed at /usr/src/sys/kern/kern_synch.c:177
> KDB: enter: panic
> [thread pid 1527 tid 100119 ]
> Stopped at kdb_enter+0x2b: nop
> db> tr
> Tracing pid 1527 tid 100119 td 0xc5cca300
> kdb_enter(c06d3e90) at kdb_enter+0x2b
> panic(c06d332c,c4c5d600,c06d4661,b1,0) at panic+0xbb
> _mtx_assert(c4d3cc74,9,c06d4661,b1,0) at _mtx_assert+0x83
> msleep(c4d3c000,c4d3cc74,0,c0912121,3e8) at msleep+0x16a
> ipw_init(c4d3c000,c4d3c000,2080,c4d3c904,c4c2dc00) at ipw_init+0xb63
> ipw_media_change(c4c2dc00,c4f6fd00,80,c4d36600,0) at ipw_media_change+0x8b
> ifmedia_ioctl(c4c2dc00,c4d9a360,c4d3c904,c0206937,0) at ifmedia_ioctl+0x93
> ieee80211_ioctl(c4d3c004,c0206937,c4d9a360,c4d3cc74,c4d3c000) at
> ieee80211_ioctl+0xc1
> ipw_ioctl(c4c2dc00,c0206937,c4d9a360,ef577c38,c051bbee) at ipw_ioctl+0x5c
> ifhwioctl(c0206937,c4c2dc00,c4d9a360,c5cca300,c074a4c0) at ifhwioctl+0x9ac
> ifioctl(c5a4f858,c0206937,c4d9a360,c5cca300,0) at ifioctl+0xc3
> soo_ioctl(c59c0750,c0206937,c4d9a360,c5a41a80,c5cca300) at soo_ioctl+0x2db
> ioctl(c5cca300,ef577d04,3,2,282) at ioctl+0x370
> syscall(3b,3b,3b,bfbf90a0,80dc400) at syscall+0x22f
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x482d468f, esp = 0xbfbf906c,
> ebp = 0xbfbf90e8 ---
>
>
> Ulrich Spoerlein
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: if_ipw.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/dev/ipw/if_ipw.c,v
retrieving revision 1.7.2.4
diff -u -r1.7.2.4 if_ipw.c
--- if_ipw.c 29 Jan 2006 15:13:01 - 1.7.2.4
+++ if_ipw.c 7 Apr 2006 22:27:33 -
@@ -220,7 +220,7 @@
sc->sc_dev = dev;
mtx_init(&sc->sc_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK,
- MTX_DEF | MTX_RECURSE);
+ MTX_DEF);
if (pci_get_powerstate(dev) != PCI_POWERSTATE_D0) {
device_printf(dev, "chip is in D%d power mode "
@@ -380,6 +380,7 @@
struct ipw_softc *sc = device_get_softc(dev);
struct ieee80211com *ic = &sc->sc_ic;
struct ifnet *ifp = ic->ic_ifp;
+ IPW_LOCK_DECL;
IPW_LOCK(sc);
@@ -722,6 +723,7 @@
{
struct ipw_softc *sc = device_get_softc(dev);
struct ifnet *ifp = sc->sc_ic.ic_ifp;
+ IPW_LOCK_DECL;
IPW_LOCK(sc);
@@ -743,6 +745,7 @@
{
struct ipw_softc *sc = ifp->if_softc;
int error;
+ IPW_LOCK_DECL;
IPW_LOCK(sc);
@@ -1222,6 +1225,7 @@
{
struct ipw_softc *sc = arg;
uint32_t r;
+ IPW_LOCK_DECL;
IPW_LOCK(sc);
@@ -1474,6 +1478,7 @@
struct mbuf *m0;
struct ether_header *eh;
struct ieee80211_node *ni;
+ IPW_LOCK_DECL;
IPW_LOCK(sc);
@@ -1557,6 +1562,7 @@
struct ieee80211com *ic = &sc->sc_ic;
struct ifreq *ifr;
int error = 0;
+ IPW_LOCK_DECL;
IPW_LOCK(sc);
@@ -1769,6 +1775,7 @@
struct ipw_firmware_hdr hdr;
u_char *p = data;
int error;
+ IPW_LOCK_DECL;
ipw_free_firmware(sc);
Index: if_ipwvar.h
===
RCS file: /usr/store/mlaier/fcvs/src/sys/dev/ipw/if_ipwvar.h,v
retrieving revision 1.3
diff -u -r1.3 if_ipwvar.h
--- if_ipwvar.h 10 Jun 2005 16:49:11 - 1.3
+++ if_ipwvar.h 7 Apr 2006 22:23:46 -
@@ -170,5 +170,12 @@
#define SIOCSLOADFW _IOW('i', 137, struct ifreq)
#define SIOCSKILLFW _IOW('i', 138, struct ifreq)
-#define IPW_LOCK(sc) mtx_lock(&(sc)->sc_mtx)
-#define IPW_UNLOCK(sc) mtx_unlock(&(sc)->sc_mtx)
+#define IPW_LOCK_DECL int __waslocked = 0
+#define IPW_LOCK(sc) do {\
+ if (!(__waslocked = mtx_owned(&(sc)->sc_mtx))) \
+ mtx_lock(&(sc)->sc_mtx); \
+} while (0)
+#define IPW_UNLOCK(sc) do { \
+ if (!__waslocked) \
+ mtx_unlock(&(sc)->sc_mtx); \
+} while (0)
pgpRDnZ1xjljg.pgp
Description: PGP signature
Re: resolver doesn't see resolv.conf changes
> when switching my laptop from LAN to a dialup connection, applications > started _before_ the switch will still try to send DNS queries to my > local DNS server. This isn't ideal, and the only workaround I've found > so far is to restart the application. > > Is the resolver supposed to periodically check for updates to the > resolv.conf, or are the applications somehow caching the IP of the DNS > server? If you're the author of the application you can periodically unset a RES_INIT bit mask option in _res.options. Next time your application will try to call res_send() it will call res_init() at first. This is according to a resolver(3) manual page. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Wrong CPU frequency after reboot
Often when I reboot my system it restarts with the wrong CPU frequency: Apr 7 22:24:53 xor kernel: FreeBSD 6.1-PRERELEASE #19: Tue Mar 28 15:15:20 EST 2006 Apr 7 22:24:53 xor kernel: ACPI APIC Table: Apr 7 22:24:53 xor kernel: CPU: AMD Athlon(tm) 64 Processor 2200+ (797.73-MHz 686-class CPU) Apr 7 22:24:53 xor kernel: Origin = "AuthenticAMD" Id = 0xf48 Stepping = 8 Apr 7 22:24:53 xor kernel: Features=0x78bfbff dev.cpu.0.freq: 799 dev.cpu.0.freq_levels: 799/-1 699/-1 599/-1 499/-1 399/-1 299/-1 199/-1 99/-1 (it's always 799) when it should be /var/log/messages.1.bz2:Mar 28 15:21:28 xor kernel: CPU: AMD Athlon(tm) 64 Processor 2200+ (2193.77-MHz 686-class CPU) A power cycle is needed to run at full speed. Can anyone suggest what is wrong? Kris pgpMRhgQ5JrW1.pgp Description: PGP signature
Re: rpc.lockd brokenness (2)
On 3/6/06, Jun Kuriyama <[EMAIL PROTECTED]> wrote: > > I'm not yet received enough information to track rpc.lockd problem. > > As Kris posted before, here is a patch to backout my suspected > commit. If someone can easily reproduce this problem, please try with > this patch on both of server/client side of rpc.lockd (I'm not sure > which of server/client side this affects). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/80389 > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84953 > > Any reports about this patch (OK or still problem) are welcome! Hi, Somehow I have problems with lockd after 3 boxes upgraded from Feb's RELENG_6 to Apr 6's. One of them has problems with lockd. For example, mutt and irssi will stuck in lockd (shown by top). I tried to back out changes in revision 1.18 for lock_proc.c, and do /etc/rc.d/nfslocking stop then a start. After backout it, mutt and irssi work well. If I put 1.18 back, mutt and irssi will stuck in lockd again. Last month, I played with the test program/script in those two PRs, found that revision 1.18 does not make any difference. I'm not 100% sure the problem I encountered now is related to rev 1.18. But it is a report that backout 1.18 really helps. For record, all my clients involved in this mail are running RELENG_6. Server is RELENG_5 as of March 9. Only IPv4 here, no IPv6. Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
usb support kernel changes
I have disabled all usb support in my kernel on todays cvs of -stable, and to my surprise i saw it load automatically as a kernel module; # kldstat Id Refs AddressSize Name 14 0xc040 2cac68 kernel 21 0xc06cb000 628f4acpi.ko 31 0xc318b000 1c000usb.ko This is new behavior indeed, how can i disable usb support as before? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpc.lockd brokenness (2)
On Sat, Apr 08, 2006 at 01:28:55AM -0400, Rong-En Fan wrote: > On 3/6/06, Jun Kuriyama <[EMAIL PROTECTED]> wrote: > > > > I'm not yet received enough information to track rpc.lockd problem. > > > > As Kris posted before, here is a patch to backout my suspected > > commit. If someone can easily reproduce this problem, please try with > > this patch on both of server/client side of rpc.lockd (I'm not sure > > which of server/client side this affects). > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/80389 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84953 > > > > Any reports about this patch (OK or still problem) are welcome! > > Hi, > > Somehow I have problems with lockd after 3 boxes upgraded from > Feb's RELENG_6 to Apr 6's. One of them has problems with lockd. > For example, mutt and irssi will stuck in lockd (shown by > top). I tried to back out changes in revision 1.18 for lock_proc.c, > and do /etc/rc.d/nfslocking stop then a start. After backout it, > mutt and irssi work well. If I put 1.18 back, mutt and irssi will stuck > in lockd again. > > Last month, I played with the test program/script in those two PRs, > found that revision 1.18 does not make any difference. I'm not 100% > sure the problem I encountered now is related to rev 1.18. But > it is a report that backout 1.18 really helps. > > For record, all my clients involved in this mail are running RELENG_6. > Server is RELENG_5 as of March 9. Only IPv4 here, no IPv6. 1.18 was merged 15 months ago, so it cannot be the cause if you updated from Feb 2006. Kris pgpasgULPtyAh.pgp Description: PGP signature
Re: usb support kernel changes
Mike Jakubik wrote this message on Sat, Apr 08, 2006 at 02:02 -0400: > I have disabled all usb support in my kernel on todays cvs of -stable, > and to my surprise i saw it load automatically as a kernel module; > > # kldstat > Id Refs AddressSize Name > 14 0xc040 2cac68 kernel > 21 0xc06cb000 628f4acpi.ko > 31 0xc318b000 1c000usb.ko > > This is new behavior indeed, how can i disable usb support as before? remove the: usbd_enabled="YES" line from your /etc/rc.conf file... and/or remove the various usb lines from your /boot/loader.conf file... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
