Re: smbfs crashes since approx. 10.1-RELEASE
Christian Kratzer wrote: > Hi Rick, > > On Sun, 18 Oct 2015, Rick Macklem wrote: > > > Christian Kratzer wrote: > >> Hi Rick, > >> > >> looks like your latest patch nailed the issue. The box has been up for 3 > >> days: > >> > >> ck@noc3:~ % uptime > >> 12:22PM up 3 days, 4:11, 1 user, load averages: 0.07, 0.10, 0.08 > >> ck@noc3:~ % > >> > >> If it does not crash over the weekend this seems to be it: > >> > > When I took a closer look, it appears that PR 172942 was a different crash > > and > > it appears that one was fixed via r264600. > > > > Your problem does not appear to be in the bugs database. (I will commit the > > patch in mid-November anyhow, but creating a PR for this might be useful > > for > > others.) > > > > Btw, I think the attached patch (which includes this change) also fixes a > > problem that caused a crash during mounting, reported via PR 201912. > > (If you`d like to test this one that would be appreciated. It should be > > applied to code not already patched with the one below, since the below > > patch is included in it.) > > > > Thanks for your help with this, rick > > > I'll put your patch on the VM in question. Btw. it has been up for 6 days now > without a crash. > > Before I do that I would like to see that it really addresses PR 201912. > > Do you have any idea how I could provoke that one ? > Not really, I'm afraid. The patch deals with the failure cases in smb_vc_create(), which I think was what caused the crash, given the backtrace in the PR. You can look at smb_vc_create() and see there is a bunch of "goto fail;" cases, but I don't know how to specifically tickle any of these? You could "fake it" by putting a "goto fail;" at line#428, just after the "error = ENOMEM;". This will break smb_vc_create() big time, but I think it will generate the same crash as PR 201912. > Ideally I would like to do the stuff that forces the panic, then apply > the patch and see that the system stays stable despite me doing the > silly moves again. > That would be nice, but so long as I know that the patch doesn't cause a regression, I am comfortable committing it. (This refers to the other 2 changes in the patch. It seems clear that the fix in smbiod2.patch is ok to commit.) Thanks for all your help with this, rick > Greetings > Christian > > -- > Christian Kratzer CK Software GmbH > Email: c...@cksoft.de Wildberger Weg 24/2 > Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden > Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart > Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer > Web: http://www.cksoft.de/ > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smbfs crashes since approx. 10.1-RELEASE
Hi Rick, On Sun, 18 Oct 2015, Rick Macklem wrote: Christian Kratzer wrote: Hi Rick, looks like your latest patch nailed the issue. The box has been up for 3 days: ck@noc3:~ % uptime 12:22PM up 3 days, 4:11, 1 user, load averages: 0.07, 0.10, 0.08 ck@noc3:~ % If it does not crash over the weekend this seems to be it: When I took a closer look, it appears that PR 172942 was a different crash and it appears that one was fixed via r264600. Your problem does not appear to be in the bugs database. (I will commit the patch in mid-November anyhow, but creating a PR for this might be useful for others.) Btw, I think the attached patch (which includes this change) also fixes a problem that caused a crash during mounting, reported via PR 201912. (If you`d like to test this one that would be appreciated. It should be applied to code not already patched with the one below, since the below patch is included in it.) Thanks for your help with this, rick I'll put your patch on the VM in question. Btw. it has been up for 6 days now without a crash. Before I do that I would like to see that it really addresses PR 201912. Do you have any idea how I could provoke that one ? Ideally I would like to do the stuff that forces the panic, then apply the patch and see that the system stays stable despite me doing the silly moves again. Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smbfs crashes since approx. 10.1-RELEASE
Christian Kratzer wrote: > Hi Rick, > > looks like your latest patch nailed the issue. The box has been up for 3 > days: > > ck@noc3:~ % uptime > 12:22PM up 3 days, 4:11, 1 user, load averages: 0.07, 0.10, 0.08 > ck@noc3:~ % > > If it does not crash over the weekend this seems to be it: > When I took a closer look, it appears that PR 172942 was a different crash and it appears that one was fixed via r264600. Your problem does not appear to be in the bugs database. (I will commit the patch in mid-November anyhow, but creating a PR for this might be useful for others.) Btw, I think the attached patch (which includes this change) also fixes a problem that caused a crash during mounting, reported via PR 201912. (If you`d like to test this one that would be appreciated. It should be applied to code not already patched with the one below, since the below patch is included in it.) Thanks for your help with this, rick > > ck@noc3:/usr/src % svn diff sys/netsmb/smb_iod.c > Index: sys/netsmb/smb_iod.c > === > --- sys/netsmb/smb_iod.c(revision 289211) > +++ sys/netsmb/smb_iod.c(working copy) > @@ -659,6 +659,11 @@ > break; > tsleep(&iod->iod_flags, PWAIT, "90idle", > iod->iod_sleeptimo); > } > + > + /* We can now safely destroy the mutexes and free the iod structure. > */ > + smb_sl_destroy(&iod->iod_rqlock); > + smb_sl_destroy(&iod->iod_evlock); > + free(iod, M_SMBIOD); > mtx_unlock(&Giant); > kproc_exit(0); > } > @@ -695,9 +700,6 @@ > smb_iod_destroy(struct smbiod *iod) > { > smb_iod_request(iod, SMBIOD_EV_SHUTDOWN | SMBIOD_EV_SYNC, NULL); > - smb_sl_destroy(&iod->iod_rqlock); > - smb_sl_destroy(&iod->iod_evlock); > - free(iod, M_SMBIOD); > return 0; > } > > ck@noc3:/usr/src % > > > Can you get this committed into current and later stable ? > > Greetings > Christian > > > > On Mon, 12 Oct 2015, Rick Macklem wrote: > > > Christian Kratzer wrote: > >> Hi Rick, > >> > >> On Mon, 12 Oct 2015, Rick Macklem wrote: > >> > >>> Christian Kratzer wrote: > Hi Rick, > > there was also a second more recent crash in /var/crash > > Mon Oct 12 03:01:16 CEST 2015 > > FreeBSD noc3.cksoft.de 10.2-STABLE FreeBSD 10.2-STABLE #2 r288980M: > Sun > Oct 11 08:37:40 CEST 2015 > c...@noc3.cksoft.de:/usr/obj/usr/src/sys/NOC amd64 > > panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955 > > >>> Oops, I screwed up. I should have looked at this panic assertion when you > >>> reported > >>> it before. Ok, so if I understand the assertion correctly, it means that > >>> another > >>> thread has the mutex locked. If this is correct, I'll have to take > >>> another > >>> look at > >>> the code and figure out how to wait for these other threads to finish > >>> with > >>> the mutexes. > >>> > >>> I do think the patch fixes the race I saw, but there must be other races > >>> in > >>> the code. > >>> > >>> I'll take another look, but if anyone else is conversant with netsmb, > >>> feel > >>> free to > >>> jump in, because it is all new to me. > >>> > >>> Unfortunately, I won't have any way to do testing for the next month or > >>> so, > >>> so any > >>> patches I do come up with will be "try this untested..". > >> > >> thats no problem. > >> > >> Just keep the patches coming when you have time and tell me when to reset > >> back to stable, > >> current or whatever so we don't lose sync of the status. > >> > > Well, you can try the attached one instead of the previous ones (ie. > > against stable). > > It just delays destroying the mutexes until the iod thread is exiting. > > > > I can't quite see why the previous patches wouldn't fix it, but this one > > leaves > > smb_iod_main() unchanged, so it is a simpler patch and doesn't affect > > semantics > > except for a slight delay in destroying the mutexes. > > > >> As it looks like that the race happens on unmount I could try putting a > >> sleep > >> 60 into the > >> script that does the "mount && rsycn && umount" magic just before the > >> umount. > >> That would > >> allow anything that it slow to go away to perhaps release the mutexes > >> before > >> the umount. > >> > > If it still crashes with this patch, it might be worth a try. > > > > Or, if this patch still crashes, you could just delete the 3 lines that the > > patch moves, so the mutexes are never destroyed. This would result in a > > leak, > > but it would tell us if destroying these mutexes is the problem. > > > > Thanks for your willingness to test these, rick > > > >> Not a real fix of course but might help to verify what's going on. > >> > >> Greetings > >> Christian > >> > >> > >> -- > >> Christian Kratzer CK Software GmbH >
Re: smbfs crashes since approx. 10.1-RELEASE
Christian Kratzer wrote: > Hi Rick, > > looks like your latest patch nailed the issue. The box has been up for 3 > days: > > ck@noc3:~ % uptime > 12:22PM up 3 days, 4:11, 1 user, load averages: 0.07, 0.10, 0.08 > ck@noc3:~ % > > If it does not crash over the weekend this seems to be it: > Sounds good. Although I wouldn't have thought it could happen in practice, I did spot how a race could still occur with the last patch. Since smb_iod_request() did the msleep() with PDROP, it could return any time after the wakeup(evp) and destroy the mutexes before the iod thread was done with them. Anyhow, if it fixes the problem, I guess we're happy. Btw, I think PR#172942 and 201912 may both be caused by the same problem. I've asked the people that reported these to test the patch. > > ck@noc3:/usr/src % svn diff sys/netsmb/smb_iod.c > Index: sys/netsmb/smb_iod.c > === > --- sys/netsmb/smb_iod.c(revision 289211) > +++ sys/netsmb/smb_iod.c(working copy) > @@ -659,6 +659,11 @@ > break; > tsleep(&iod->iod_flags, PWAIT, "90idle", > iod->iod_sleeptimo); > } > + > + /* We can now safely destroy the mutexes and free the iod structure. > */ > + smb_sl_destroy(&iod->iod_rqlock); > + smb_sl_destroy(&iod->iod_evlock); > + free(iod, M_SMBIOD); > mtx_unlock(&Giant); > kproc_exit(0); > } > @@ -695,9 +700,6 @@ > smb_iod_destroy(struct smbiod *iod) > { > smb_iod_request(iod, SMBIOD_EV_SHUTDOWN | SMBIOD_EV_SYNC, NULL); > - smb_sl_destroy(&iod->iod_rqlock); > - smb_sl_destroy(&iod->iod_evlock); > - free(iod, M_SMBIOD); > return 0; > } > > ck@noc3:/usr/src % > > > Can you get this committed into current and later stable ? > I should be able to do this, although not until mid-Nov. I'd also like to hear from the folk that reported the PRs. John, maybe you could review this? Thanks for your help testing this, rick > Greetings > Christian > > > > On Mon, 12 Oct 2015, Rick Macklem wrote: > > > Christian Kratzer wrote: > >> Hi Rick, > >> > >> On Mon, 12 Oct 2015, Rick Macklem wrote: > >> > >>> Christian Kratzer wrote: > Hi Rick, > > there was also a second more recent crash in /var/crash > > Mon Oct 12 03:01:16 CEST 2015 > > FreeBSD noc3.cksoft.de 10.2-STABLE FreeBSD 10.2-STABLE #2 r288980M: > Sun > Oct 11 08:37:40 CEST 2015 > c...@noc3.cksoft.de:/usr/obj/usr/src/sys/NOC amd64 > > panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955 > > >>> Oops, I screwed up. I should have looked at this panic assertion when you > >>> reported > >>> it before. Ok, so if I understand the assertion correctly, it means that > >>> another > >>> thread has the mutex locked. If this is correct, I'll have to take > >>> another > >>> look at > >>> the code and figure out how to wait for these other threads to finish > >>> with > >>> the mutexes. > >>> > >>> I do think the patch fixes the race I saw, but there must be other races > >>> in > >>> the code. > >>> > >>> I'll take another look, but if anyone else is conversant with netsmb, > >>> feel > >>> free to > >>> jump in, because it is all new to me. > >>> > >>> Unfortunately, I won't have any way to do testing for the next month or > >>> so, > >>> so any > >>> patches I do come up with will be "try this untested..". > >> > >> thats no problem. > >> > >> Just keep the patches coming when you have time and tell me when to reset > >> back to stable, > >> current or whatever so we don't lose sync of the status. > >> > > Well, you can try the attached one instead of the previous ones (ie. > > against stable). > > It just delays destroying the mutexes until the iod thread is exiting. > > > > I can't quite see why the previous patches wouldn't fix it, but this one > > leaves > > smb_iod_main() unchanged, so it is a simpler patch and doesn't affect > > semantics > > except for a slight delay in destroying the mutexes. > > > >> As it looks like that the race happens on unmount I could try putting a > >> sleep > >> 60 into the > >> script that does the "mount && rsycn && umount" magic just before the > >> umount. > >> That would > >> allow anything that it slow to go away to perhaps release the mutexes > >> before > >> the umount. > >> > > If it still crashes with this patch, it might be worth a try. > > > > Or, if this patch still crashes, you could just delete the 3 lines that the > > patch moves, so the mutexes are never destroyed. This would result in a > > leak, > > but it would tell us if destroying these mutexes is the problem. > > > > Thanks for your willingness to test these, rick > > > >> Not a real fix of course but might help to verify what's going on. > >> > >> Greetings > >> Christian > >> > >> > >> -- > >> Christ
Re: smbfs crashes since approx. 10.1-RELEASE
Hi Rick, looks like your latest patch nailed the issue. The box has been up for 3 days: ck@noc3:~ % uptime 12:22PM up 3 days, 4:11, 1 user, load averages: 0.07, 0.10, 0.08 ck@noc3:~ % If it does not crash over the weekend this seems to be it: ck@noc3:/usr/src % svn diff sys/netsmb/smb_iod.c Index: sys/netsmb/smb_iod.c === --- sys/netsmb/smb_iod.c(revision 289211) +++ sys/netsmb/smb_iod.c(working copy) @@ -659,6 +659,11 @@ break; tsleep(&iod->iod_flags, PWAIT, "90idle", iod->iod_sleeptimo); } + + /* We can now safely destroy the mutexes and free the iod structure. */ + smb_sl_destroy(&iod->iod_rqlock); + smb_sl_destroy(&iod->iod_evlock); + free(iod, M_SMBIOD); mtx_unlock(&Giant); kproc_exit(0); } @@ -695,9 +700,6 @@ smb_iod_destroy(struct smbiod *iod) { smb_iod_request(iod, SMBIOD_EV_SHUTDOWN | SMBIOD_EV_SYNC, NULL); - smb_sl_destroy(&iod->iod_rqlock); - smb_sl_destroy(&iod->iod_evlock); - free(iod, M_SMBIOD); return 0; } ck@noc3:/usr/src % Can you get this committed into current and later stable ? Greetings Christian On Mon, 12 Oct 2015, Rick Macklem wrote: Christian Kratzer wrote: Hi Rick, On Mon, 12 Oct 2015, Rick Macklem wrote: Christian Kratzer wrote: Hi Rick, there was also a second more recent crash in /var/crash Mon Oct 12 03:01:16 CEST 2015 FreeBSD noc3.cksoft.de 10.2-STABLE FreeBSD 10.2-STABLE #2 r288980M: Sun Oct 11 08:37:40 CEST 2015 c...@noc3.cksoft.de:/usr/obj/usr/src/sys/NOC amd64 panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955 Oops, I screwed up. I should have looked at this panic assertion when you reported it before. Ok, so if I understand the assertion correctly, it means that another thread has the mutex locked. If this is correct, I'll have to take another look at the code and figure out how to wait for these other threads to finish with the mutexes. I do think the patch fixes the race I saw, but there must be other races in the code. I'll take another look, but if anyone else is conversant with netsmb, feel free to jump in, because it is all new to me. Unfortunately, I won't have any way to do testing for the next month or so, so any patches I do come up with will be "try this untested..". thats no problem. Just keep the patches coming when you have time and tell me when to reset back to stable, current or whatever so we don't lose sync of the status. Well, you can try the attached one instead of the previous ones (ie. against stable). It just delays destroying the mutexes until the iod thread is exiting. I can't quite see why the previous patches wouldn't fix it, but this one leaves smb_iod_main() unchanged, so it is a simpler patch and doesn't affect semantics except for a slight delay in destroying the mutexes. As it looks like that the race happens on unmount I could try putting a sleep 60 into the script that does the "mount && rsycn && umount" magic just before the umount. That would allow anything that it slow to go away to perhaps release the mutexes before the umount. If it still crashes with this patch, it might be worth a try. Or, if this patch still crashes, you could just delete the 3 lines that the patch moves, so the mutexes are never destroyed. This would result in a leak, but it would tell us if destroying these mutexes is the problem. Thanks for your willingness to test these, rick Not a real fix of course but might help to verify what's going on. Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smbfs crashes since approx. 10.1-RELEASE
Hi Rick, On Mon, 12 Oct 2015, Rick Macklem wrote: Well, you can try the attached one instead of the previous ones (ie. against stable). It just delays destroying the mutexes until the iod thread is exiting. I can't quite see why the previous patches wouldn't fix it, but this one leaves smb_iod_main() unchanged, so it is a simpler patch and doesn't affect semantics except for a slight delay in destroying the mutexes. patch applied this morning against plain 10-stable with wittness enabled ... As it looks like that the race happens on unmount I could try putting a sleep 60 into the script that does the "mount && rsycn && umount" magic just before the umount. That would allow anything that it slow to go away to perhaps release the mutexes before the umount. If it still crashes with this patch, it might be worth a try. I had a sleep 60 before the umount over night and it did not crash. Could have been to short a wait though. I have removed the sleep 60 in order to give your patch a good testing Or, if this patch still crashes, you could just delete the 3 lines that the patch moves, so the mutexes are never destroyed. This would result in a leak, but it would tell us if destroying these mutexes is the problem. Good point. Thanks for your willingness to test these, rick No problem. Thanks to you for wrapping your head around this. Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smbfs crashes since approx. 10.1-RELEASE
Christian Kratzer wrote: > Hi Rick, > > On Mon, 12 Oct 2015, Rick Macklem wrote: > > > Christian Kratzer wrote: > >> Hi Rick, > >> > >> there was also a second more recent crash in /var/crash > >> > >> Mon Oct 12 03:01:16 CEST 2015 > >> > >> FreeBSD noc3.cksoft.de 10.2-STABLE FreeBSD 10.2-STABLE #2 r288980M: > >> Sun > >> Oct 11 08:37:40 CEST 2015 > >> c...@noc3.cksoft.de:/usr/obj/usr/src/sys/NOC amd64 > >> > >> panic: Assertion mtx_unowned(m) failed at > >> /usr/src/sys/kern/kern_mutex.c:955 > >> > > Oops, I screwed up. I should have looked at this panic assertion when you > > reported > > it before. Ok, so if I understand the assertion correctly, it means that > > another > > thread has the mutex locked. If this is correct, I'll have to take another > > look at > > the code and figure out how to wait for these other threads to finish with > > the mutexes. > > > > I do think the patch fixes the race I saw, but there must be other races in > > the code. > > > > I'll take another look, but if anyone else is conversant with netsmb, feel > > free to > > jump in, because it is all new to me. > > > > Unfortunately, I won't have any way to do testing for the next month or so, > > so any > > patches I do come up with will be "try this untested..". > > thats no problem. > > Just keep the patches coming when you have time and tell me when to reset > back to stable, > current or whatever so we don't lose sync of the status. > Well, you can try the attached one instead of the previous ones (ie. against stable). It just delays destroying the mutexes until the iod thread is exiting. I can't quite see why the previous patches wouldn't fix it, but this one leaves smb_iod_main() unchanged, so it is a simpler patch and doesn't affect semantics except for a slight delay in destroying the mutexes. > As it looks like that the race happens on unmount I could try putting a sleep > 60 into the > script that does the "mount && rsycn && umount" magic just before the umount. > That would > allow anything that it slow to go away to perhaps release the mutexes before > the umount. > If it still crashes with this patch, it might be worth a try. Or, if this patch still crashes, you could just delete the 3 lines that the patch moves, so the mutexes are never destroyed. This would result in a leak, but it would tell us if destroying these mutexes is the problem. Thanks for your willingness to test these, rick > Not a real fix of course but might help to verify what's going on. > > Greetings > Christian > > > -- > Christian Kratzer CK Software GmbH > Email: c...@cksoft.de Wildberger Weg 24/2 > Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden > Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart > Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer > Web: http://www.cksoft.de/ > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > --- smb_iod.c.orig 2015-10-10 18:53:34.0 -0400 +++ smb_iod.c 2015-10-12 20:30:00.0 -0400 @@ -659,6 +659,11 @@ smb_iod_thread(void *arg) break; tsleep(&iod->iod_flags, PWAIT, "90idle", iod->iod_sleeptimo); } + + /* We can now safely destroy the mutexes and free the iod structure. */ + smb_sl_destroy(&iod->iod_rqlock); + smb_sl_destroy(&iod->iod_evlock); + free(iod, M_SMBIOD); mtx_unlock(&Giant); kproc_exit(0); } @@ -695,9 +700,6 @@ int smb_iod_destroy(struct smbiod *iod) { smb_iod_request(iod, SMBIOD_EV_SHUTDOWN | SMBIOD_EV_SYNC, NULL); - smb_sl_destroy(&iod->iod_rqlock); - smb_sl_destroy(&iod->iod_evlock); - free(iod, M_SMBIOD); return 0; } ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smbfs crashes since approx. 10.1-RELEASE
Hi Rick, On Mon, 12 Oct 2015, Rick Macklem wrote: Christian Kratzer wrote: Hi Rick, there was also a second more recent crash in /var/crash Mon Oct 12 03:01:16 CEST 2015 FreeBSD noc3.cksoft.de 10.2-STABLE FreeBSD 10.2-STABLE #2 r288980M: Sun Oct 11 08:37:40 CEST 2015 c...@noc3.cksoft.de:/usr/obj/usr/src/sys/NOC amd64 panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955 Oops, I screwed up. I should have looked at this panic assertion when you reported it before. Ok, so if I understand the assertion correctly, it means that another thread has the mutex locked. If this is correct, I'll have to take another look at the code and figure out how to wait for these other threads to finish with the mutexes. I do think the patch fixes the race I saw, but there must be other races in the code. I'll take another look, but if anyone else is conversant with netsmb, feel free to jump in, because it is all new to me. Unfortunately, I won't have any way to do testing for the next month or so, so any patches I do come up with will be "try this untested..". thats no problem. Just keep the patches coming when you have time and tell me when to reset back to stable, current or whatever so we don't lose sync of the status. As it looks like that the race happens on unmount I could try putting a sleep 60 into the script that does the "mount && rsycn && umount" magic just before the umount. That would allow anything that it slow to go away to perhaps release the mutexes before the umount. Not a real fix of course but might help to verify what's going on. Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smbfs crashes since approx. 10.1-RELEASE
Christian Kratzer wrote: > Hi Rick, > > there was also a second more recent crash in /var/crash > > Mon Oct 12 03:01:16 CEST 2015 > > FreeBSD noc3.cksoft.de 10.2-STABLE FreeBSD 10.2-STABLE #2 r288980M: Sun > Oct 11 08:37:40 CEST 2015 > c...@noc3.cksoft.de:/usr/obj/usr/src/sys/NOC amd64 > > panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955 > Oops, I screwed up. I should have looked at this panic assertion when you reported it before. Ok, so if I understand the assertion correctly, it means that another thread has the mutex locked. If this is correct, I'll have to take another look at the code and figure out how to wait for these other threads to finish with the mutexes. I do think the patch fixes the race I saw, but there must be other races in the code. I'll take another look, but if anyone else is conversant with netsmb, feel free to jump in, because it is all new to me. Unfortunately, I won't have any way to do testing for the next month or so, so any patches I do come up with will be "try this untested..". rick > 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: > panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955 > cpuid = 3 > KDB: stack backtrace: > #0 0x80975bb0 at kdb_backtrace+0x60 > #1 0x8093baa6 at vpanic+0x126 > #2 0x8093b979 at kassert_panic+0x139 > #3 0x80921c47 at _mtx_destroy+0x77 > #4 0x81a1c174 at smb_iod_destroy+0xc4 > #5 0x81a12eea at smb_vc_free+0x1a > #6 0x81a13e24 at sdp_trydestroy+0xb4 > #7 0x81a1cb96 at smbfs_unmount+0xd6 > #8 0x809d9e84 at dounmount+0x524 > #9 0x809d9936 at sys_unmount+0x3c6 > #10 0x80d42235 at amd64_syscall+0x265 > #11 0x80d25cfb at Xfast_syscall+0xfb > Uptime: 8h44m10s > Dumping 102 out of 999 MB:..16%..32%..47%..63%..78%..94% > > Reading symbols from /boot/kernel/smbfs.ko.symbols...done. > Loaded symbols for /boot/kernel/smbfs.ko.symbols > Reading symbols from /boot/kernel/libiconv.ko.symbols...done. > Loaded symbols for /boot/kernel/libiconv.ko.symbols > Reading symbols from /boot/kernel/libmchain.ko.symbols...done. > Loaded symbols for /boot/kernel/libmchain.ko.symbols > #0 doadump (textdump=) at pcpu.h:219 > 219 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:219 > #1 0x8093b5f2 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:451 > #2 0x8093bae5 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:758 > #3 0x8093b979 in kassert_panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:646 > #4 0x80921c47 in _mtx_destroy (c=0xf80002db5490) > at /usr/src/sys/kern/kern_mutex.c:955 > #5 0x81a1c174 in smb_iod_destroy (iod=0xf80002db5400) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:733 > #6 0x81a12eea in smb_vc_free (cp=0xf80002933000) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:499 > #7 0x81a13e24 in sdp_trydestroy (sdp=0xf80002904140) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_dev.c:166 > #8 0x81a1cb96 in smbfs_unmount (mp=0xf80015226000, > mntflags=) > at /usr/src/sys/modules/smbfs/../../fs/smbfs/smbfs_vfsops.c:297 > #9 0x809d9e84 in dounmount (mp=0xf80015226000, > flags=134217728, > td=0xf800151b0940) at /usr/src/sys/kern/vfs_mount.c:1313 > #10 0x809d9936 in sys_unmount (td=0xf800151b0940, > uap=0xfe003d643b80) at /usr/src/sys/kern/vfs_mount.c:1205 > #11 0x80d42235 in amd64_syscall (td=0xf800151b0940, > traced=0) > at subr_syscall.c:134 > #12 0x80d25cfb in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:396 > #13 0x00080089190a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > > Greetings > Christian > > > > > > > > > > > On Mon, 12 Oct 2015, Christian Kratzer wrote: > > > Hi Rick, > > > > On Sat, 10 Oct 2015, Rick Macklem wrote: > > > >> Hi again, > >> > >> Attached is a semantically equivalent patch to the one I posted a few > >> minutes ago, but I think this
Re: smbfs crashes since approx. 10.1-RELEASE
Hi Rick, there was also a second more recent crash in /var/crash Mon Oct 12 03:01:16 CEST 2015 FreeBSD noc3.cksoft.de 10.2-STABLE FreeBSD 10.2-STABLE #2 r288980M: Sun Oct 11 08:37:40 CEST 2015 c...@noc3.cksoft.de:/usr/obj/usr/src/sys/NOC amd64 panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955 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: panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955 cpuid = 3 KDB: stack backtrace: #0 0x80975bb0 at kdb_backtrace+0x60 #1 0x8093baa6 at vpanic+0x126 #2 0x8093b979 at kassert_panic+0x139 #3 0x80921c47 at _mtx_destroy+0x77 #4 0x81a1c174 at smb_iod_destroy+0xc4 #5 0x81a12eea at smb_vc_free+0x1a #6 0x81a13e24 at sdp_trydestroy+0xb4 #7 0x81a1cb96 at smbfs_unmount+0xd6 #8 0x809d9e84 at dounmount+0x524 #9 0x809d9936 at sys_unmount+0x3c6 #10 0x80d42235 at amd64_syscall+0x265 #11 0x80d25cfb at Xfast_syscall+0xfb Uptime: 8h44m10s Dumping 102 out of 999 MB:..16%..32%..47%..63%..78%..94% Reading symbols from /boot/kernel/smbfs.ko.symbols...done. Loaded symbols for /boot/kernel/smbfs.ko.symbols Reading symbols from /boot/kernel/libiconv.ko.symbols...done. Loaded symbols for /boot/kernel/libiconv.ko.symbols Reading symbols from /boot/kernel/libmchain.ko.symbols...done. Loaded symbols for /boot/kernel/libmchain.ko.symbols #0 doadump (textdump=) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:219 #1 0x8093b5f2 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0x8093bae5 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0x8093b979 in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:646 #4 0x80921c47 in _mtx_destroy (c=0xf80002db5490) at /usr/src/sys/kern/kern_mutex.c:955 #5 0x81a1c174 in smb_iod_destroy (iod=0xf80002db5400) at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:733 #6 0x81a12eea in smb_vc_free (cp=0xf80002933000) at /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:499 #7 0x81a13e24 in sdp_trydestroy (sdp=0xf80002904140) at /usr/src/sys/modules/smbfs/../../netsmb/smb_dev.c:166 #8 0x81a1cb96 in smbfs_unmount (mp=0xf80015226000, mntflags=) at /usr/src/sys/modules/smbfs/../../fs/smbfs/smbfs_vfsops.c:297 #9 0x809d9e84 in dounmount (mp=0xf80015226000, flags=134217728, td=0xf800151b0940) at /usr/src/sys/kern/vfs_mount.c:1313 #10 0x809d9936 in sys_unmount (td=0xf800151b0940, uap=0xfe003d643b80) at /usr/src/sys/kern/vfs_mount.c:1205 #11 0x80d42235 in amd64_syscall (td=0xf800151b0940, traced=0) at subr_syscall.c:134 #12 0x80d25cfb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 #13 0x00080089190a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) Greetings Christian On Mon, 12 Oct 2015, Christian Kratzer wrote: Hi Rick, On Sat, 10 Oct 2015, Rick Macklem wrote: Hi again, Attached is a semantically equivalent patch to the one I posted a few minutes ago, but I think this one is more readable. Please let me know if you get it tested, rick the box crashed again tonight with your patch applied. Here's the new crashinfo: panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955 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: panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955 cpuid = 2 KDB: stack backtrace: #0 0x80975bb0 at kdb_backtrace+0x60 #1 0x8093baa6 at vpanic+0x126 #2 0x8093b979 at kassert_panic+0x139 #3 0x80921c47 at _mtx_destroy+0x77 #4 0x
Re: smbfs crashes since approx. 10.1-RELEASE
Hi Rick, On Sat, 10 Oct 2015, Rick Macklem wrote: Hi again, Attached is a semantically equivalent patch to the one I posted a few minutes ago, but I think this one is more readable. Please let me know if you get it tested, rick the box crashed again tonight with your patch applied. Here's the new crashinfo: panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955 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: panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955 cpuid = 2 KDB: stack backtrace: #0 0x80975bb0 at kdb_backtrace+0x60 #1 0x8093baa6 at vpanic+0x126 #2 0x8093b979 at kassert_panic+0x139 #3 0x80921c47 at _mtx_destroy+0x77 #4 0x81a1c114 at smb_iod_destroy+0xc4 #5 0x81a12eea at smb_vc_free+0x1a #6 0x81a13e24 at sdp_trydestroy+0xb4 #7 0x81a1cb36 at smbfs_unmount+0xd6 #8 0x809d9e84 at dounmount+0x524 #9 0x809d9936 at sys_unmount+0x3c6 #10 0x80d42235 at amd64_syscall+0x265 #11 0x80d25cfb at Xfast_syscall+0xfb Uptime: 1d21h59m0s Dumping 191 out of 999 MB:..9%..17%..26%..34%..42%..51%..67%..76%..84%..92% Here are the stackframes with line numbers: (kgdb) frame 0 #0 __curthread () at ./machine/pcpu.h:219 219 __asm("movq %%gs:%1,%0" : "=r" (td) (kgdb) frame 1 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:263 263 dumptid = curthread->td_tid; (kgdb) frame 2 #2 0x8093b5f2 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 451 doadump(TRUE); (kgdb) frame 3 #3 0x8093bae5 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:758 758 kern_reboot(bootopt); (kgdb) frame 4 #4 0x8093b979 in kassert_panic (fmt=0x80e931ef "Assertion %s failed at %s:%d") at /usr/src/sys/kern/kern_shutdown.c:646 646 vpanic(fmt, ap); (kgdb) frame 5 #5 0x80921c47 in _mtx_destroy (c=0xf80002db5490) at /usr/src/sys/kern/kern_mutex.c:955 955 MPASS(mtx_unowned(m)); (kgdb) frame 6 #6 0x81a1c174 in smb_iod_destroy (iod=0xf80002db5400) at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:733 733 smb_sl_destroy(&iod->iod_evlock); (kgdb) frame 7 #7 0x81a12eea in smb_vc_free (cp=0xf80002933000) at /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:499 499 smb_iod_destroy(vcp->vc_iod); (kgdb) frame 8 #8 0x81a13e24 in sdp_trydestroy (sdp=0xf80002904140) at /usr/src/sys/modules/smbfs/../../netsmb/smb_dev.c:166 166 smb_vc_rele(vcp, scred); (kgdb) frame 9 #9 0x81a1cb96 in smbfs_unmount (mp=0xf80015226000, mntflags=) at /usr/src/sys/modules/smbfs/../../fs/smbfs/smbfs_vfsops.c:297 297 sdp_trydestroy(dev); (kgdb) frame 10 #10 0x809d9e84 in dounmount (mp=0xf80015226000, flags=134217728, td=0xf800151b0940) at /usr/src/sys/kern/vfs_mount.c:1313 1313error = VFS_UNMOUNT(mp, flags); (kgdb) Let me know if you need anything else from the stackframes. Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smbfs crashes since approx. 10.1-RELEASE
Hi Rick, On Sat, 10 Oct 2015, Rick Macklem wrote: Hi again, Attached is a semantically equivalent patch to the one I posted a few minutes ago, but I think this one is more readable. Please let me know if you get it tested, rick I have patched the 10-stable kernel on the box. Judging from the previous crash frequency the issue should be fixed if the box stays up 2-3 days. Thanks a lot! Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smbfs crashes since approx. 10.1-RELEASE
Hi again, Attached is a semantically equivalent patch to the one I posted a few minutes ago, but I think this one is more readable. Please let me know if you get it tested, rick - Original Message - > Hi John, > > the box crashed again running a 10-stable kernel with following patch of > yours: > > On Wed, 7 Oct 2015, John Baldwin wrote: > > Index: smb_iod.c > > === > > --- smb_iod.c (revision 288952) > > +++ smb_iod.c (working copy) > > @@ -624,6 +624,13 @@ > >SMB_IOD_EVUNLOCK(iod); > >} else > >free(evp, M_SMBIOD); > > + if (iod->iod_flags & SMBIOD_SHUTDOWN) { > > + if (!STAILQ_EMPTY(&iod->iod_evlist)) > > + printf("%s: shutdown with pending > > events\n", > > + __func__); > > + } > > + return; > > + } > >} > > #if 0 > >if (iod->iod_state == SMBIOD_ST_VCACTIVE) { > > > > here is what I got on the kvm console: > > login: panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955^M > cpuid = 1^M > KDB: stack backtrace:^M > #0 0x80975bb0 at kdb_backtrace+0x60^M > #1 0x8093baa6 at vpanic+0x126^M > #2 0x8093b979 at kassert_panic+0x139^M > #3 0x80921c47 at _mtx_destroy+0x77^M > #4 0x81a1c114 at smb_iod_destroy+0xc4^M > #5 0x81a12eea at smb_vc_free+0x1a^M > #6 0x81a13e24 at sdp_trydestroy+0xb4^M > #7 0x81a1cb36 at smbfs_unmount+0xd6^M > #8 0x809d9e84 at dounmount+0x524^M > #9 0x809d9936 at sys_unmount+0x3c6^M > #10 0x80d42235 at amd64_syscall+0x265^M > #11 0x80d25cfb at Xfast_syscall+0xfb^M > Uptime: 19h48m28s^M > Dumping 179 out of 999 > MB:..9%..18%..27%..36%..45%..54%..63%..72%..81%..98%^M > Dump complete^M > Automatic reboot in 15 seconds - press a key on the console to abort^M > > heres the crashinfo: > > panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955 > > 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: > panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955 > cpuid = 1 > KDB: stack backtrace: > #0 0x80975bb0 at kdb_backtrace+0x60 > #1 0x8093baa6 at vpanic+0x126 > #2 0x8093b979 at kassert_panic+0x139 > #3 0x80921c47 at _mtx_destroy+0x77 > #4 0x81a1c114 at smb_iod_destroy+0xc4 > #5 0x81a12eea at smb_vc_free+0x1a > #6 0x81a13e24 at sdp_trydestroy+0xb4 > #7 0x81a1cb36 at smbfs_unmount+0xd6 > #8 0x809d9e84 at dounmount+0x524 > #9 0x809d9936 at sys_unmount+0x3c6 > #10 0x80d42235 at amd64_syscall+0x265 > #11 0x80d25cfb at Xfast_syscall+0xfb > Uptime: 19h48m28s > Dumping 179 out of 999 > MB:..9%..18%..27%..36%..45%..54%..63%..72%..81%..98% > > Reading symbols from /boot/kernel/smbfs.ko.symbols...done. > Loaded symbols for /boot/kernel/smbfs.ko.symbols > Reading symbols from /boot/kernel/libiconv.ko.symbols...done. > Loaded symbols for /boot/kernel/libiconv.ko.symbols > Reading symbols from /boot/kernel/libmchain.ko.symbols...done. > Loaded symbols for /boot/kernel/libmchain.ko.symbols > #0 doadump (textdump=) at pcpu.h:219 > 219 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:219 > #1 0x8093b5f2 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:451 > #2 0x8093bae5 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:758 > #3 0x8093b979 in kassert_panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:646 > #4 0x80921c47 in _mtx_destroy (c=0xf80009284690) > at /usr/src/sys/kern/kern_mutex.c:955 > #5 0x81a1c114 in smb_iod_destroy (iod=0xf80009284600) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:706 > #6 0x81a12eea in smb_vc_free (cp=0xf8003a602a00) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:499 > #7 0x81a13e24 in sdp_trydestroy (sdp=0xf8000a7cbc80) > at /usr/src/sys/mo
Re: smbfs crashes since approx. 10.1-RELEASE
Hi, Maybe you could try the attached patch instead of the one below? (Completely untested. I haven't even tried to compile it.) rick - Original Message - > Hi John, > > the box crashed again running a 10-stable kernel with following patch of > yours: > > On Wed, 7 Oct 2015, John Baldwin wrote: > > Index: smb_iod.c > > === > > --- smb_iod.c (revision 288952) > > +++ smb_iod.c (working copy) > > @@ -624,6 +624,13 @@ > >SMB_IOD_EVUNLOCK(iod); > >} else > >free(evp, M_SMBIOD); > > + if (iod->iod_flags & SMBIOD_SHUTDOWN) { > > + if (!STAILQ_EMPTY(&iod->iod_evlist)) > > + printf("%s: shutdown with pending > > events\n", > > + __func__); > > + } > > + return; > > + } > >} > > #if 0 > >if (iod->iod_state == SMBIOD_ST_VCACTIVE) { > > > > here is what I got on the kvm console: > > login: panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955^M > cpuid = 1^M > KDB: stack backtrace:^M > #0 0x80975bb0 at kdb_backtrace+0x60^M > #1 0x8093baa6 at vpanic+0x126^M > #2 0x8093b979 at kassert_panic+0x139^M > #3 0x80921c47 at _mtx_destroy+0x77^M > #4 0x81a1c114 at smb_iod_destroy+0xc4^M > #5 0x81a12eea at smb_vc_free+0x1a^M > #6 0x81a13e24 at sdp_trydestroy+0xb4^M > #7 0x81a1cb36 at smbfs_unmount+0xd6^M > #8 0x809d9e84 at dounmount+0x524^M > #9 0x809d9936 at sys_unmount+0x3c6^M > #10 0x80d42235 at amd64_syscall+0x265^M > #11 0x80d25cfb at Xfast_syscall+0xfb^M > Uptime: 19h48m28s^M > Dumping 179 out of 999 > MB:..9%..18%..27%..36%..45%..54%..63%..72%..81%..98%^M > Dump complete^M > Automatic reboot in 15 seconds - press a key on the console to abort^M > > heres the crashinfo: > > panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955 > > 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: > panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955 > cpuid = 1 > KDB: stack backtrace: > #0 0x80975bb0 at kdb_backtrace+0x60 > #1 0x8093baa6 at vpanic+0x126 > #2 0x8093b979 at kassert_panic+0x139 > #3 0x80921c47 at _mtx_destroy+0x77 > #4 0x81a1c114 at smb_iod_destroy+0xc4 > #5 0x81a12eea at smb_vc_free+0x1a > #6 0x81a13e24 at sdp_trydestroy+0xb4 > #7 0x81a1cb36 at smbfs_unmount+0xd6 > #8 0x809d9e84 at dounmount+0x524 > #9 0x809d9936 at sys_unmount+0x3c6 > #10 0x80d42235 at amd64_syscall+0x265 > #11 0x80d25cfb at Xfast_syscall+0xfb > Uptime: 19h48m28s > Dumping 179 out of 999 > MB:..9%..18%..27%..36%..45%..54%..63%..72%..81%..98% > > Reading symbols from /boot/kernel/smbfs.ko.symbols...done. > Loaded symbols for /boot/kernel/smbfs.ko.symbols > Reading symbols from /boot/kernel/libiconv.ko.symbols...done. > Loaded symbols for /boot/kernel/libiconv.ko.symbols > Reading symbols from /boot/kernel/libmchain.ko.symbols...done. > Loaded symbols for /boot/kernel/libmchain.ko.symbols > #0 doadump (textdump=) at pcpu.h:219 > 219 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:219 > #1 0x8093b5f2 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:451 > #2 0x8093bae5 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:758 > #3 0x8093b979 in kassert_panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:646 > #4 0x80921c47 in _mtx_destroy (c=0xf80009284690) > at /usr/src/sys/kern/kern_mutex.c:955 > #5 0x81a1c114 in smb_iod_destroy (iod=0xf80009284600) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:706 > #6 0x81a12eea in smb_vc_free (cp=0xf8003a602a00) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:499 > #7 0x81a13e24 in sdp_trydestroy (sdp=0xf8000a7cbc80) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_dev.c:166 >
Re: smbfs crashes since approx. 10.1-RELEASE
Christian Kratzer wrote: > Hi John, > > the box crashed again running a 10-stable kernel with following patch of > yours: > > On Wed, 7 Oct 2015, John Baldwin wrote: > > Index: smb_iod.c > > === > > --- smb_iod.c (revision 288952) > > +++ smb_iod.c (working copy) > > @@ -624,6 +624,13 @@ > >SMB_IOD_EVUNLOCK(iod); > >} else > >free(evp, M_SMBIOD); > > + if (iod->iod_flags & SMBIOD_SHUTDOWN) { > > + if (!STAILQ_EMPTY(&iod->iod_evlist)) > > + printf("%s: shutdown with pending > > events\n", > > + __func__); > > + } > > + return; > > + } > >} > > #if 0 > >if (iod->iod_state == SMBIOD_ST_VCACTIVE) { > > Ok, I think John has found the race. As soon as smb_iod_main() does the wakeup() just before the patch (line#623), smb_iod_destroy() can go ahead and destroy the mtuexes. I think the above patch failed because the smb_iod_sendall(iod) and smb_iod_recvall(iod) need to be done before smb_iod_main() returns. I'll email a patch for testing later to-day (I've gotta run and do something else now), rick > > here is what I got on the kvm console: > > login: panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955^M > cpuid = 1^M > KDB: stack backtrace:^M > #0 0x80975bb0 at kdb_backtrace+0x60^M > #1 0x8093baa6 at vpanic+0x126^M > #2 0x8093b979 at kassert_panic+0x139^M > #3 0x80921c47 at _mtx_destroy+0x77^M > #4 0x81a1c114 at smb_iod_destroy+0xc4^M > #5 0x81a12eea at smb_vc_free+0x1a^M > #6 0x81a13e24 at sdp_trydestroy+0xb4^M > #7 0x81a1cb36 at smbfs_unmount+0xd6^M > #8 0x809d9e84 at dounmount+0x524^M > #9 0x809d9936 at sys_unmount+0x3c6^M > #10 0x80d42235 at amd64_syscall+0x265^M > #11 0x80d25cfb at Xfast_syscall+0xfb^M > Uptime: 19h48m28s^M > Dumping 179 out of 999 > MB:..9%..18%..27%..36%..45%..54%..63%..72%..81%..98%^M > Dump complete^M > Automatic reboot in 15 seconds - press a key on the console to abort^M > > heres the crashinfo: > > panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955 > > 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: > panic: Assertion mtx_unowned(m) failed at > /usr/src/sys/kern/kern_mutex.c:955 > cpuid = 1 > KDB: stack backtrace: > #0 0x80975bb0 at kdb_backtrace+0x60 > #1 0x8093baa6 at vpanic+0x126 > #2 0x8093b979 at kassert_panic+0x139 > #3 0x80921c47 at _mtx_destroy+0x77 > #4 0x81a1c114 at smb_iod_destroy+0xc4 > #5 0x81a12eea at smb_vc_free+0x1a > #6 0x81a13e24 at sdp_trydestroy+0xb4 > #7 0x81a1cb36 at smbfs_unmount+0xd6 > #8 0x809d9e84 at dounmount+0x524 > #9 0x809d9936 at sys_unmount+0x3c6 > #10 0x80d42235 at amd64_syscall+0x265 > #11 0x80d25cfb at Xfast_syscall+0xfb > Uptime: 19h48m28s > Dumping 179 out of 999 > MB:..9%..18%..27%..36%..45%..54%..63%..72%..81%..98% > > Reading symbols from /boot/kernel/smbfs.ko.symbols...done. > Loaded symbols for /boot/kernel/smbfs.ko.symbols > Reading symbols from /boot/kernel/libiconv.ko.symbols...done. > Loaded symbols for /boot/kernel/libiconv.ko.symbols > Reading symbols from /boot/kernel/libmchain.ko.symbols...done. > Loaded symbols for /boot/kernel/libmchain.ko.symbols > #0 doadump (textdump=) at pcpu.h:219 > 219 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:219 > #1 0x8093b5f2 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:451 > #2 0x8093bae5 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:758 > #3 0x8093b979 in kassert_panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:646 > #4 0x80921c47 in _mtx_destroy (c=0xf80009284690) > at /usr/src/sys/kern/kern_mutex.c:955 > #5 0x81a1c114 in smb_iod_destroy (iod=0xf80009284600) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:706 > #6 0x
Re: smbfs crashes since approx. 10.1-RELEASE
Hi John, the box crashed again running a 10-stable kernel with following patch of yours: On Wed, 7 Oct 2015, John Baldwin wrote: Index: smb_iod.c === --- smb_iod.c (revision 288952) +++ smb_iod.c (working copy) @@ -624,6 +624,13 @@ SMB_IOD_EVUNLOCK(iod); } else free(evp, M_SMBIOD); + if (iod->iod_flags & SMBIOD_SHUTDOWN) { + if (!STAILQ_EMPTY(&iod->iod_evlist)) + printf("%s: shutdown with pending events\n", + __func__); + } + return; + } } #if 0 if (iod->iod_state == SMBIOD_ST_VCACTIVE) { here is what I got on the kvm console: login: panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955^M cpuid = 1^M KDB: stack backtrace:^M #0 0x80975bb0 at kdb_backtrace+0x60^M #1 0x8093baa6 at vpanic+0x126^M #2 0x8093b979 at kassert_panic+0x139^M #3 0x80921c47 at _mtx_destroy+0x77^M #4 0x81a1c114 at smb_iod_destroy+0xc4^M #5 0x81a12eea at smb_vc_free+0x1a^M #6 0x81a13e24 at sdp_trydestroy+0xb4^M #7 0x81a1cb36 at smbfs_unmount+0xd6^M #8 0x809d9e84 at dounmount+0x524^M #9 0x809d9936 at sys_unmount+0x3c6^M #10 0x80d42235 at amd64_syscall+0x265^M #11 0x80d25cfb at Xfast_syscall+0xfb^M Uptime: 19h48m28s^M Dumping 179 out of 999 MB:..9%..18%..27%..36%..45%..54%..63%..72%..81%..98%^M Dump complete^M Automatic reboot in 15 seconds - press a key on the console to abort^M heres the crashinfo: panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955 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: panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:955 cpuid = 1 KDB: stack backtrace: #0 0x80975bb0 at kdb_backtrace+0x60 #1 0x8093baa6 at vpanic+0x126 #2 0x8093b979 at kassert_panic+0x139 #3 0x80921c47 at _mtx_destroy+0x77 #4 0x81a1c114 at smb_iod_destroy+0xc4 #5 0x81a12eea at smb_vc_free+0x1a #6 0x81a13e24 at sdp_trydestroy+0xb4 #7 0x81a1cb36 at smbfs_unmount+0xd6 #8 0x809d9e84 at dounmount+0x524 #9 0x809d9936 at sys_unmount+0x3c6 #10 0x80d42235 at amd64_syscall+0x265 #11 0x80d25cfb at Xfast_syscall+0xfb Uptime: 19h48m28s Dumping 179 out of 999 MB:..9%..18%..27%..36%..45%..54%..63%..72%..81%..98% Reading symbols from /boot/kernel/smbfs.ko.symbols...done. Loaded symbols for /boot/kernel/smbfs.ko.symbols Reading symbols from /boot/kernel/libiconv.ko.symbols...done. Loaded symbols for /boot/kernel/libiconv.ko.symbols Reading symbols from /boot/kernel/libmchain.ko.symbols...done. Loaded symbols for /boot/kernel/libmchain.ko.symbols #0 doadump (textdump=) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:219 #1 0x8093b5f2 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0x8093bae5 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0x8093b979 in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:646 #4 0x80921c47 in _mtx_destroy (c=0xf80009284690) at /usr/src/sys/kern/kern_mutex.c:955 #5 0x81a1c114 in smb_iod_destroy (iod=0xf80009284600) at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:706 #6 0x81a12eea in smb_vc_free (cp=0xf8003a602a00) at /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:499 #7 0x81a13e24 in sdp_trydestroy (sdp=0xf8000a7cbc80) at /usr/src/sys/modules/smbfs/../../netsmb/smb_dev.c:166 #8 0x81a1cb36 in smbfs_unmount (mp=0xf80039f88330, mntflags=) at /usr/src/sys/modules/smbfs/../../fs/smbfs/smbfs_vfsops.c:297 #9 0x809d9e84 in dounmount (mp=0xf80039f88330, flags=134217728, td=0xf8000f2b) at /usr/src/sys/kern/vfs_mount.c:1313 #10 0x809d9936 in sys_unmount (td=0xf8000f2b, uap=0xfe003d67fb80) at /usr/src/sys/kern/vfs_mount.c:1205 #11 0x80d42235 in amd64_syscall (td=0xf8000f2b
Re: smbfs crashes since approx. 10.1-RELEASE
Hi John, On Wed, 7 Oct 2015, John Baldwin wrote: mtx_lock = 1444181401} Ok, so that is a destroyed mutex. This means it is probably not Giant, and it might be some mutex in smb_iod_main() that shows up in smb_iod_thread() due to inlining. Actually, we know this from your earlier mail: if (evp->ev_type & SMBIOD_EV_SYNC) { SMB_IOD_EVLOCK(iod); wakeup(evp); SMB_IOD_EVUNLOCK(iod); Line 624 is that SMB_IOD_EVUNLOCK(). Hmm, does 'p *evp' work at frame 10? If not, can you try building the devel/gdb port from a recent ports tree with the 'KGDB' option enabled and use 'kgdb710' instead of 'kgdb' to see if you can print out '*evp'? kgdb hangs when chaning to frame10. I will build the port later (svn ports checkout in progress) I have cloned the VM so that I have this isolated from my production network. (kgdb) --snipp-- I can build a GENERIC kernel with INVARIANTS enabled on the box to see if we get a better assertions next time this happens. That would be great, but please keep the existing core and kernel. We might be able to figure this out from that still. Also, go ahead and put this patch in and let me know if you ever see the printf logged. If you do, that could explain this panic (and we might need a more involved fix to avoid memory leaks). Index: smb_iod.c === --- smb_iod.c (revision 288952) +++ smb_iod.c (working copy) @@ -624,6 +624,13 @@ SMB_IOD_EVUNLOCK(iod); } else free(evp, M_SMBIOD); + if (iod->iod_flags & SMBIOD_SHUTDOWN) { + if (!STAILQ_EMPTY(&iod->iod_evlist)) + printf("%s: shutdown with pending events\n", + __func__); + } + return; + } } #if 0 if (iod->iod_state == SMBIOD_ST_VCACTIVE) { The vm is now runnning lates 10-stable kernel with above patch and invariants enabled. Give it about 2 days to produce the next crash. Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smbfs crashes since approx. 10.1-RELEASE
On Wednesday, October 07, 2015 08:52:30 AM Christian Kratzer wrote: > Hi, > > On Tue, 6 Oct 2015, John Baldwin wrote: > > >> This crash is occurring when doing an mtx_unlock(&Giant). Unfortunately, > >> I'm not > >> conversant w.r.t. this code. I've cc'd jhb@ in case he has some insight. > >> If you don't get any responses, I'd suggest reposting to freebsd-current@ > >> with > >> "crashes in mtx_unlock(&Giant)" in the subject line. > >> > >> Btw John, the code does tsleep() in a loop before the mtx_unlock(&Giant). > >> I do > >> remember that was once allowed, but am not sure if it still is (ie a > >> tsleep() call > >> while holding Giant)? > >> > >> Hopefully someone who knows what is special about Giant that might cause > >> this will > >> respond. > >> > >> Good luck with it, rick > > > > tsleep() with Giant is still allowed. However, this sort of panic usually > > means > > you unlocked a mutex you didn't hold (but without INVARIANTS enabled or > > you'd get > > an assertion failure earlier). > > > > I don't see anything obviously wrong in smb_iod_thread() however. > > > > If you have the crashdump, can you please run this in kgdb: > > > > frame 9 > > p (struct mtx *)c > > p *(struct mtx *)c > > yes I have. Here we go: > > --snipp-- > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x20 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80996c7c > stack pointer = 0x28:0xfe004e79bac0 > frame pointer = 0x28:0xfe004e79baf0 > 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 = 12235 (smbiod172) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > #0 0x80984e30 at kdb_backtrace+0x60 > #1 0x809489e6 at vpanic+0x126 > #2 0x809488b3 at panic+0x43 > #3 0x80d4aadb at trap_fatal+0x36b > #4 0x80d4addd at trap_pfault+0x2ed > #5 0x80d4a47a at trap+0x47a > #6 0x80d307f2 at calltrap+0x8 > #7 0x8092ebe0 at __mtx_unlock_sleep+0x60 > #8 0x8092eb69 at __mtx_unlock_flags+0x69 > #9 0x81a1b724 at smb_iod_thread+0xb4 > #10 0x8091244a at fork_exit+0x9a > #11 0x80d30d2e at fork_trampoline+0xe > Uptime: 1d18h34m4s > Dumping 161 out of 999 MB:..10%..20%..30%..40%..50%..60%..70%..80%..90%..100% > > Reading symbols from /boot/kernel/smbfs.ko.symbols...done. > Loaded symbols for /boot/kernel/smbfs.ko.symbols > Reading symbols from /boot/kernel/libiconv.ko.symbols...done. > Loaded symbols for /boot/kernel/libiconv.ko.symbols > Reading symbols from /boot/kernel/libmchain.ko.symbols...done. > Loaded symbols for /boot/kernel/libmchain.ko.symbols > #0 doadump (textdump=) at pcpu.h:219 > 219 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) frame 9 > #9 0x8092ebe0 in __mtx_unlock_sleep (c=0xf8002f531790, > opts=, > file=0x81a25801 "%s: Can't handle disordered parameters > %d:%d\n", line=1) at /usr/src/sys/kern/kern_mutex.c:791 > 791 /usr/src/sys/kern/kern_mutex.c: No such file or directory. > in /usr/src/sys/kern/kern_mutex.c > Current language: auto; currently minimal > (kgdb) p (struct mtx *)c > $1 = (struct mtx *) 0xf8002f531790 > (kgdb) p *(struct mtx *)c > $2 = {lock_object = {lo_name = 0x6 , lo_flags = 0, > lo_data = 0, lo_witness = 0xf8002f531798}, >mtx_lock = 1444181401} Ok, so that is a destroyed mutex. This means it is probably not Giant, and it might be some mutex in smb_iod_main() that shows up in smb_iod_thread() due to inlining. Actually, we know this from your earlier mail: if (evp->ev_type & SMBIOD_EV_SYNC) { SMB_IOD_EVLOCK(iod); wakeup(evp); SMB_IOD_EVUNLOCK(iod); Line 624 is that SMB_IOD_EVUNLOCK(). Hmm, does 'p *evp' work at frame 10? If not, can you try building the devel/gdb port from a recent ports tree with the 'KGDB' option enabled and use 'kgdb710' instead of 'kgdb' to see if you can print out '*evp'? > (kgdb) > --snipp-- > > I can build a GENERIC kernel with INVARIANTS enabled on the box to see if we > get a better assertions next time this happens. That would be great, but please keep the existing core and kernel. We might be able to figure this out from that still. Also, go ahead and put this patch in and let me know if you ever see the printf logged. If you do, that could explain this panic (and we might need a more involved fix to avoid memory leaks). Index: smb_iod.c === --- smb_iod.c (revision 288952) +++ smb_iod.c (working copy) @@ -624,6 +624,13 @@ SMB_IOD_EVUNLOCK(iod); } else
Re: smbfs crashes since approx. 10.1-RELEASE
Hi, On Tue, 6 Oct 2015, John Baldwin wrote: This crash is occurring when doing an mtx_unlock(&Giant). Unfortunately, I'm not conversant w.r.t. this code. I've cc'd jhb@ in case he has some insight. If you don't get any responses, I'd suggest reposting to freebsd-current@ with "crashes in mtx_unlock(&Giant)" in the subject line. Btw John, the code does tsleep() in a loop before the mtx_unlock(&Giant). I do remember that was once allowed, but am not sure if it still is (ie a tsleep() call while holding Giant)? Hopefully someone who knows what is special about Giant that might cause this will respond. Good luck with it, rick tsleep() with Giant is still allowed. However, this sort of panic usually means you unlocked a mutex you didn't hold (but without INVARIANTS enabled or you'd get an assertion failure earlier). I don't see anything obviously wrong in smb_iod_thread() however. If you have the crashdump, can you please run this in kgdb: frame 9 p (struct mtx *)c p *(struct mtx *)c yes I have. Here we go: --snipp-- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x20 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80996c7c stack pointer = 0x28:0xfe004e79bac0 frame pointer = 0x28:0xfe004e79baf0 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 = 12235 (smbiod172) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0x80984e30 at kdb_backtrace+0x60 #1 0x809489e6 at vpanic+0x126 #2 0x809488b3 at panic+0x43 #3 0x80d4aadb at trap_fatal+0x36b #4 0x80d4addd at trap_pfault+0x2ed #5 0x80d4a47a at trap+0x47a #6 0x80d307f2 at calltrap+0x8 #7 0x8092ebe0 at __mtx_unlock_sleep+0x60 #8 0x8092eb69 at __mtx_unlock_flags+0x69 #9 0x81a1b724 at smb_iod_thread+0xb4 #10 0x8091244a at fork_exit+0x9a #11 0x80d30d2e at fork_trampoline+0xe Uptime: 1d18h34m4s Dumping 161 out of 999 MB:..10%..20%..30%..40%..50%..60%..70%..80%..90%..100% Reading symbols from /boot/kernel/smbfs.ko.symbols...done. Loaded symbols for /boot/kernel/smbfs.ko.symbols Reading symbols from /boot/kernel/libiconv.ko.symbols...done. Loaded symbols for /boot/kernel/libiconv.ko.symbols Reading symbols from /boot/kernel/libmchain.ko.symbols...done. Loaded symbols for /boot/kernel/libmchain.ko.symbols #0 doadump (textdump=) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) frame 9 #9 0x8092ebe0 in __mtx_unlock_sleep (c=0xf8002f531790, opts=, file=0x81a25801 "%s: Can't handle disordered parameters %d:%d\n", line=1) at /usr/src/sys/kern/kern_mutex.c:791 791 /usr/src/sys/kern/kern_mutex.c: No such file or directory. in /usr/src/sys/kern/kern_mutex.c Current language: auto; currently minimal (kgdb) p (struct mtx *)c $1 = (struct mtx *) 0xf8002f531790 (kgdb) p *(struct mtx *)c $2 = {lock_object = {lo_name = 0x6 , lo_flags = 0, lo_data = 0, lo_witness = 0xf8002f531798}, mtx_lock = 1444181401} (kgdb) --snipp-- I can build a GENERIC kernel with INVARIANTS enabled on the box to see if we get a better assertions next time this happens. That is in case it happens at all with a debug build. Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smbfs crashes since approx. 10.1-RELEASE
On Monday, October 05, 2015 06:16:54 PM Rick Macklem wrote: > Christian Kratzer wrote: > > Hi, > > > > I run a regular rsync job that runs from cron and copies stuff that gets > > created on a Windows smbfs share. > > > > Starting about 10.1-RELEASE the VM has become unstable and started panicing. > > > > I have narrowed the issue down to the aforementioned rsync job. > > > > When I move the job to a different VM the the other VM starts crashing and > > the VM without the job becomes stable agin. > > > > I have panics and crashinfos stored in /var/crash if anybody is interested: > > > > root@noc2:/var/crash # uname -a > > FreeBSD noc2.cksoft.de 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r28: > > Wed > > Aug 12 15:26:37 UTC 2015 > > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > root@noc2:/var/crash # freebsd-version -u > > 10.2-RELEASE-p5 > > root@noc2:/var/crash # freebsd-version -k > > 10.2-RELEASE > > root@noc2:/var/crash # > > > > This is what I have in /var/crash/core.txt.0 > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x20 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0x80996c7c > > stack pointer = 0x28:0xfe003d6c0ac0 > > frame pointer = 0x28:0xfe003d6c0af0 > > 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 = 1349 (smbiod10) > > trap number = 12 > > panic: page fault > > cpuid = 0 > > KDB: stack backtrace: > > #0 0x80984e30 at kdb_backtrace+0x60 > > #1 0x809489e6 at vpanic+0x126 > > #2 0x809488b3 at panic+0x43 > > #3 0x80d4aadb at trap_fatal+0x36b > > #4 0x80d4addd at trap_pfault+0x2ed > > #5 0x80d4a47a at trap+0x47a > > #6 0x80d307f2 at calltrap+0x8 > > #7 0x8092ebe0 at __mtx_unlock_sleep+0x60 > > #8 0x8092eb69 at __mtx_unlock_flags+0x69 > > #9 0x81a1b724 at smb_iod_thread+0xb4 > > #10 0x8091244a at fork_exit+0x9a > > #11 0x80d30d2e at fork_trampoline+0xe > > Uptime: 2h43m55s > > Dumping 103 out of 999 MB: (CTRL-C to abort) > > ..16%..31%..47%..62%..78%..93% > > > This crash is occurring when doing an mtx_unlock(&Giant). Unfortunately, I'm > not > conversant w.r.t. this code. I've cc'd jhb@ in case he has some insight. > If you don't get any responses, I'd suggest reposting to freebsd-current@ with > "crashes in mtx_unlock(&Giant)" in the subject line. > > Btw John, the code does tsleep() in a loop before the mtx_unlock(&Giant). I do > remember that was once allowed, but am not sure if it still is (ie a tsleep() > call > while holding Giant)? > > Hopefully someone who knows what is special about Giant that might cause this > will > respond. > > Good luck with it, rick tsleep() with Giant is still allowed. However, this sort of panic usually means you unlocked a mutex you didn't hold (but without INVARIANTS enabled or you'd get an assertion failure earlier). I don't see anything obviously wrong in smb_iod_thread() however. If you have the crashdump, can you please run this in kgdb: frame 9 p (struct mtx *)c p *(struct mtx *)c -- John Baldwin ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smbfs crashes since approx. 10.1-RELEASE
Hi, On Mon, 5 Oct 2015, dweimer wrote: root@noc2:/var/crash # freebsd-version -u 10.2-RELEASE-p5 root@noc2:/var/crash # freebsd-version -k 10.2-RELEASE Shouldn't the kernel version also be 10.2-RELEASE-p5? Perhaps the user land being different than the kernel is causing an issue? root@freebsd:/home/dweimer # uname -a FreeBSD freebsd.dweimer.local 10.2-RELEASE-p5 FreeBSD 10.2-RELEASE-p5 #1 r288512: Fri Oct 2 13:54:14 CDT 2015 dweimer@freebsd.dweimer.local:/jails/devel/ROOT/usr/obj/jails/devel/ROOT/usr/src/sys/GENERIC amd64 root@freebsd:/home/dweimer # freebsd-version -u 10.2-RELEASE-p5 root@freebsd:/home/dweimer # freebsd-version -k 10.2-RELEASE-p5 as this system is maintained by freebsd-update and there have been no kernel changes from release to p5 the kernel is still showing 10.2-RELEASE. It is normal for systems updated by freebsd-update that the kernel version lags behind the userland. Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smbfs crashes since approx. 10.1-RELEASE
On Mon, Oct 5, 2015 at 5:00 PM, dweimer wrote: > On 2015-10-05 5:16 pm, Rick Macklem wrote: > >> Christian Kratzer wrote: >> >>> Hi, >>> >>> I run a regular rsync job that runs from cron and copies stuff that gets >>> created on a Windows smbfs share. >>> >>> Starting about 10.1-RELEASE the VM has become unstable and started >>> panicing. >>> >>> I have narrowed the issue down to the aforementioned rsync job. >>> >>> When I move the job to a different VM the the other VM starts crashing >>> and >>> the VM without the job becomes stable agin. >>> >>> I have panics and crashinfos stored in /var/crash if anybody is >>> interested: >>> >>> root@noc2:/var/crash # uname -a >>> FreeBSD noc2.cksoft.de 10.2-RELEASE FreeBSD 10.2-RELEASE #0 >>> r28: Wed >>> Aug 12 15:26:37 UTC 2015 >>> r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 >>> root@noc2:/var/crash # freebsd-version -u >>> 10.2-RELEASE-p5 >>> root@noc2:/var/crash # freebsd-version -k >>> 10.2-RELEASE >>> >> > Shouldn't the kernel version also be 10.2-RELEASE-p5? Perhaps the user > land being different than the kernel is causing an issue? > > root@freebsd:/home/dweimer # uname -a > FreeBSD freebsd.dweimer.local 10.2-RELEASE-p5 FreeBSD 10.2-RELEASE-p5 #1 > r288512: Fri Oct 2 13:54:14 CDT 2015 > dweimer@freebsd.dweimer.local:/jails/devel/ROOT/usr/obj/jails/devel/ROOT/usr/src/sys/GENERIC > amd64 > root@freebsd:/home/dweimer # freebsd-version -u > 10.2-RELEASE-p5 > root@freebsd:/home/dweimer # freebsd-version -k > 10.2-RELEASE-p5 > > -- > Thanks, >Dean E. Weimer >http://www.dweimer.net/ Probably not. If freebsd-update is used and the update does not change the kernel, the kernel is not touched and remains at the prior level. If built from sources, even though the kernel is identical, the kernel version is bumped. I just confirmed that none of the updates to 10.2-RELEASE appear to update the kernel. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smbfs crashes since approx. 10.1-RELEASE
On 2015-10-05 5:16 pm, Rick Macklem wrote: Christian Kratzer wrote: Hi, I run a regular rsync job that runs from cron and copies stuff that gets created on a Windows smbfs share. Starting about 10.1-RELEASE the VM has become unstable and started panicing. I have narrowed the issue down to the aforementioned rsync job. When I move the job to a different VM the the other VM starts crashing and the VM without the job becomes stable agin. I have panics and crashinfos stored in /var/crash if anybody is interested: root@noc2:/var/crash # uname -a FreeBSD noc2.cksoft.de 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r28: Wed Aug 12 15:26:37 UTC 2015 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 root@noc2:/var/crash # freebsd-version -u 10.2-RELEASE-p5 root@noc2:/var/crash # freebsd-version -k 10.2-RELEASE Shouldn't the kernel version also be 10.2-RELEASE-p5? Perhaps the user land being different than the kernel is causing an issue? root@freebsd:/home/dweimer # uname -a FreeBSD freebsd.dweimer.local 10.2-RELEASE-p5 FreeBSD 10.2-RELEASE-p5 #1 r288512: Fri Oct 2 13:54:14 CDT 2015 dweimer@freebsd.dweimer.local:/jails/devel/ROOT/usr/obj/jails/devel/ROOT/usr/src/sys/GENERIC amd64 root@freebsd:/home/dweimer # freebsd-version -u 10.2-RELEASE-p5 root@freebsd:/home/dweimer # freebsd-version -k 10.2-RELEASE-p5 -- Thanks, Dean E. Weimer http://www.dweimer.net/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smbfs crashes since approx. 10.1-RELEASE
Christian Kratzer wrote: > Hi, > > I run a regular rsync job that runs from cron and copies stuff that gets > created on a Windows smbfs share. > > Starting about 10.1-RELEASE the VM has become unstable and started panicing. > > I have narrowed the issue down to the aforementioned rsync job. > > When I move the job to a different VM the the other VM starts crashing and > the VM without the job becomes stable agin. > > I have panics and crashinfos stored in /var/crash if anybody is interested: > > root@noc2:/var/crash # uname -a > FreeBSD noc2.cksoft.de 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r28: Wed > Aug 12 15:26:37 UTC 2015 > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > root@noc2:/var/crash # freebsd-version -u > 10.2-RELEASE-p5 > root@noc2:/var/crash # freebsd-version -k > 10.2-RELEASE > root@noc2:/var/crash # > > This is what I have in /var/crash/core.txt.0 > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x20 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80996c7c > stack pointer = 0x28:0xfe003d6c0ac0 > frame pointer = 0x28:0xfe003d6c0af0 > 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 = 1349 (smbiod10) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > #0 0x80984e30 at kdb_backtrace+0x60 > #1 0x809489e6 at vpanic+0x126 > #2 0x809488b3 at panic+0x43 > #3 0x80d4aadb at trap_fatal+0x36b > #4 0x80d4addd at trap_pfault+0x2ed > #5 0x80d4a47a at trap+0x47a > #6 0x80d307f2 at calltrap+0x8 > #7 0x8092ebe0 at __mtx_unlock_sleep+0x60 > #8 0x8092eb69 at __mtx_unlock_flags+0x69 > #9 0x81a1b724 at smb_iod_thread+0xb4 > #10 0x8091244a at fork_exit+0x9a > #11 0x80d30d2e at fork_trampoline+0xe > Uptime: 2h43m55s > Dumping 103 out of 999 MB: (CTRL-C to abort) > ..16%..31%..47%..62%..78%..93% > This crash is occurring when doing an mtx_unlock(&Giant). Unfortunately, I'm not conversant w.r.t. this code. I've cc'd jhb@ in case he has some insight. If you don't get any responses, I'd suggest reposting to freebsd-current@ with "crashes in mtx_unlock(&Giant)" in the subject line. Btw John, the code does tsleep() in a loop before the mtx_unlock(&Giant). I do remember that was once allowed, but am not sure if it still is (ie a tsleep() call while holding Giant)? Hopefully someone who knows what is special about Giant that might cause this will respond. Good luck with it, rick > Reading symbols from /boot/kernel/smbfs.ko.symbols...done. > Loaded symbols for /boot/kernel/smbfs.ko.symbols > Reading symbols from /boot/kernel/libiconv.ko.symbols...done. > Loaded symbols for /boot/kernel/libiconv.ko.symbols > Reading symbols from /boot/kernel/libmchain.ko.symbols...done. > Loaded symbols for /boot/kernel/libmchain.ko.symbols > #0 doadump (textdump=) at pcpu.h:219 > 219 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:219 > #1 0x80948642 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:451 > #2 0x80948a25 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:758 > #3 0x809488b3 in panic (fmt=0x0) > at /usr/src/sys/kern/kern_shutdown.c:687 > #4 0x80d4aadb in trap_fatal (frame=, > eva=) at /usr/src/sys/amd64/amd64/trap.c:851 > #5 0x80d4addd in trap_pfault (frame=0xfe003d6c0a10, > usermode=) at /usr/src/sys/amd64/amd64/trap.c:674 > #6 0x80d4a47a in trap (frame=0xfe003d6c0a10) > at /usr/src/sys/amd64/amd64/trap.c:440 > #7 0x80d307f2 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:236 > #8 0x80996c7c in turnstile_broadcast (ts=0x0, queue=0) > at /usr/src/sys/kern/subr_turnstile.c:838 > #9 0x8092ebe0 in __mtx_unlock_sleep (c=0xf80002df0390, > opts=, > file=0x81a25801 "%s: Can't handle disordered parameters > %d:%d\n", > line=1) at /usr/src/sys/kern/kern_mutex.c:791 > #10 0x8092eb69 in __mtx_unlock_flags (c=, > opts=, > file=0x81a25801 "%s: Can't handle disordered parameters > %d:%d\n", > line=1) at /usr/src/sys/kern/kern_mutex.c:254 > #11 0x81a1b724 in smb_iod_thread (arg=0xf80002df0300) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:624 > #12 0x8091244a in fork_e
Re: smbfs panic when lost connection or unmount --force
hi! Have you any sequel in this error / bug? On 7/12/09, Oliver Pinter wrote: > On 7/12/09, Robert N. M. Watson wrote: >> >> On 10 Jul 2009, at 13:17, Oliver Pinter wrote: >> >>> I know, that the bt is useful, but ddb works with usb keyboard? >>> At nigth then I send the log. >> >> Unfortunately, a known issue with FreeBSD 8.0 is that the new USB >> stack, while a vast improvement over the previous USB stack in >> countless ways, does not support polled access from DDB. You will need >> to use a serial port, firewire port, ps/2, or AT keyboard in order to >> get interactive DDB support. >> > it worked with usb keyboard, the pictured and the last log is made > with usb keyboard.. > >> If that's not feasible, or if it's just easier, you may be able to use >> the DDB scripting facility + textdumps to run DDB commands >> automatically on panic to produce useful debugging output. Take a look >> at the textdump(4) man page for details. This can be combined with a >> traditional crashdump to capture both DDB output and normal dump data >> for use with kgdb. > jeah, I readed the man (ddb and textdump), and I used a small script.. > >> >> Robert >> > > thanks for the help >>> >>> //sorry for bad english >>> >>> ps.: attached the config >>> >>> On 7/10/09, Robert Watson wrote: On Fri, 10 Jul 2009, Oliver Pinter wrote: > It is a kernel panic, when force unmount the smbfs volume or lost > the > connection with the samba server. This is a NULL pointer dereference in the kernel. Per Attilio's e- mail, a stack trace should help us track it down. Thanks! Robert N M Watson Computer Laboratory University of Cambridge > > -- > Thes OS is: > > > kern.ostype: FreeBSD > kern.osrelease: 7.2-STABLE > kern.osrevision: 199506 > kern.version: FreeBSD 7.2-STABLE #4: Sat Jun 27 21:44:32 CEST 2009 > r...@oliverp:/usr/obj/usr/src/sys/stable > kern.osreldate: 702103 > > -- > make.conf: > > > CPUTYPE?=core2 > CFLAGS= -O2 -fno-strict-aliasing -pipe > MODULES_OVERRIDE=smbfs libiconv libmchain zfs opensolaris drm cd9660 > cd9660_iconv > > -- > panic message: > > Jul 10 01:58:39 oliverp syslogd: kernel boot file is /boot/kernel/ > kernel > Jul 10 01:58:39 oliverp kernel: kernel trap 12 with interrupts > disabled > Jul 10 01:58:39 oliverp kernel: > Jul 10 01:58:39 oliverp kernel: > Jul 10 01:58:39 oliverp kernel: Fatal trap 12: page fault while in > kernel > mode > Jul 10 01:58:39 oliverp kernel: cpuid = 2; apic id = 02 > Jul 10 01:58:39 oliverp kernel: fault virtual address = 0x30 > Jul 10 01:58:39 oliverp kernel: fault code= supervisor > read data, > page not present > Jul 10 01:58:39 oliverp kernel: instruction pointer = > 0x8:0x80327fd0 > Jul 10 01:58:39 oliverp kernel: stack pointer = > 0x10:0xff8078360940 > Jul 10 01:58:39 oliverp kernel: frame pointer = > 0x10:0xff0004c31390 > Jul 10 01:58:39 oliverp kernel: code segment = base 0x0, > limit > 0xf, type 0x1b > Jul 10 01:58:39 oliverp kernel: = DPL 0, pres 1, long 1, def32 0, > gran 1 > Jul 10 01:58:39 oliverp kernel: processor eflags = resume, IOPL = 0 > Jul 10 01:58:39 oliverp kernel: current process = 60406 > (smbiod0) > Jul 10 01:58:39 oliverp kernel: trap number = 12 > Jul 10 01:58:39 oliverp kernel: panic: page fault > Jul 10 01:58:39 oliverp kernel: cpuid = 2 > Jul 10 01:58:39 oliverp kernel: Uptime: 6h51m16s > Jul 10 01:58:39 oliverp kernel: Physical memory: 4087 MB > Jul 10 01:58:39 oliverp kernel: Dumping 2448 MB:Copyright (c) > 1992-2009 The FreeBSD Project. > ___ > 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 > > " > >>> >> >> > ___ 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: smbfs panic when lost connection or unmount --force
On 7/12/09, Robert N. M. Watson wrote: > > On 10 Jul 2009, at 13:17, Oliver Pinter wrote: > >> I know, that the bt is useful, but ddb works with usb keyboard? >> At nigth then I send the log. > > Unfortunately, a known issue with FreeBSD 8.0 is that the new USB > stack, while a vast improvement over the previous USB stack in > countless ways, does not support polled access from DDB. You will need > to use a serial port, firewire port, ps/2, or AT keyboard in order to > get interactive DDB support. > it worked with usb keyboard, the pictured and the last log is made with usb keyboard.. > If that's not feasible, or if it's just easier, you may be able to use > the DDB scripting facility + textdumps to run DDB commands > automatically on panic to produce useful debugging output. Take a look > at the textdump(4) man page for details. This can be combined with a > traditional crashdump to capture both DDB output and normal dump data > for use with kgdb. jeah, I readed the man (ddb and textdump), and I used a small script.. > > Robert > thanks for the help >> >> //sorry for bad english >> >> ps.: attached the config >> >> On 7/10/09, Robert Watson wrote: >>> >>> On Fri, 10 Jul 2009, Oliver Pinter wrote: >>> It is a kernel panic, when force unmount the smbfs volume or lost the connection with the samba server. >>> >>> This is a NULL pointer dereference in the kernel. Per Attilio's e- >>> mail, a >>> stack trace should help us track it down. Thanks! >>> >>> Robert N M Watson >>> Computer Laboratory >>> University of Cambridge >>> -- Thes OS is: kern.ostype: FreeBSD kern.osrelease: 7.2-STABLE kern.osrevision: 199506 kern.version: FreeBSD 7.2-STABLE #4: Sat Jun 27 21:44:32 CEST 2009 r...@oliverp:/usr/obj/usr/src/sys/stable kern.osreldate: 702103 -- make.conf: CPUTYPE?=core2 CFLAGS= -O2 -fno-strict-aliasing -pipe MODULES_OVERRIDE=smbfs libiconv libmchain zfs opensolaris drm cd9660 cd9660_iconv -- panic message: Jul 10 01:58:39 oliverp syslogd: kernel boot file is /boot/kernel/ kernel Jul 10 01:58:39 oliverp kernel: kernel trap 12 with interrupts disabled Jul 10 01:58:39 oliverp kernel: Jul 10 01:58:39 oliverp kernel: Jul 10 01:58:39 oliverp kernel: Fatal trap 12: page fault while in kernel mode Jul 10 01:58:39 oliverp kernel: cpuid = 2; apic id = 02 Jul 10 01:58:39 oliverp kernel: fault virtual address = 0x30 Jul 10 01:58:39 oliverp kernel: fault code = supervisor read data, page not present Jul 10 01:58:39 oliverp kernel: instruction pointer= 0x8:0x80327fd0 Jul 10 01:58:39 oliverp kernel: stack pointer = 0x10:0xff8078360940 Jul 10 01:58:39 oliverp kernel: frame pointer = 0x10:0xff0004c31390 Jul 10 01:58:39 oliverp kernel: code segment = base 0x0, limit 0xf, type 0x1b Jul 10 01:58:39 oliverp kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Jul 10 01:58:39 oliverp kernel: processor eflags = resume, IOPL = 0 Jul 10 01:58:39 oliverp kernel: current process= 60406 (smbiod0) Jul 10 01:58:39 oliverp kernel: trap number= 12 Jul 10 01:58:39 oliverp kernel: panic: page fault Jul 10 01:58:39 oliverp kernel: cpuid = 2 Jul 10 01:58:39 oliverp kernel: Uptime: 6h51m16s Jul 10 01:58:39 oliverp kernel: Physical memory: 4087 MB Jul 10 01:58:39 oliverp kernel: Dumping 2448 MB:Copyright (c) 1992-2009 The FreeBSD Project. ___ 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 " >>> >> > > ___ 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: smbfs panic when lost connection or unmount --force
On 10 Jul 2009, at 13:17, Oliver Pinter wrote: I know, that the bt is useful, but ddb works with usb keyboard? At nigth then I send the log. Unfortunately, a known issue with FreeBSD 8.0 is that the new USB stack, while a vast improvement over the previous USB stack in countless ways, does not support polled access from DDB. You will need to use a serial port, firewire port, ps/2, or AT keyboard in order to get interactive DDB support. If that's not feasible, or if it's just easier, you may be able to use the DDB scripting facility + textdumps to run DDB commands automatically on panic to produce useful debugging output. Take a look at the textdump(4) man page for details. This can be combined with a traditional crashdump to capture both DDB output and normal dump data for use with kgdb. Robert //sorry for bad english ps.: attached the config On 7/10/09, Robert Watson wrote: On Fri, 10 Jul 2009, Oliver Pinter wrote: It is a kernel panic, when force unmount the smbfs volume or lost the connection with the samba server. This is a NULL pointer dereference in the kernel. Per Attilio's e- mail, a stack trace should help us track it down. Thanks! Robert N M Watson Computer Laboratory University of Cambridge -- Thes OS is: kern.ostype: FreeBSD kern.osrelease: 7.2-STABLE kern.osrevision: 199506 kern.version: FreeBSD 7.2-STABLE #4: Sat Jun 27 21:44:32 CEST 2009 r...@oliverp:/usr/obj/usr/src/sys/stable kern.osreldate: 702103 -- make.conf: CPUTYPE?=core2 CFLAGS= -O2 -fno-strict-aliasing -pipe MODULES_OVERRIDE=smbfs libiconv libmchain zfs opensolaris drm cd9660 cd9660_iconv -- panic message: Jul 10 01:58:39 oliverp syslogd: kernel boot file is /boot/kernel/ kernel Jul 10 01:58:39 oliverp kernel: kernel trap 12 with interrupts disabled Jul 10 01:58:39 oliverp kernel: Jul 10 01:58:39 oliverp kernel: Jul 10 01:58:39 oliverp kernel: Fatal trap 12: page fault while in kernel mode Jul 10 01:58:39 oliverp kernel: cpuid = 2; apic id = 02 Jul 10 01:58:39 oliverp kernel: fault virtual address = 0x30 Jul 10 01:58:39 oliverp kernel: fault code = supervisor read data, page not present Jul 10 01:58:39 oliverp kernel: instruction pointer = 0x8:0x80327fd0 Jul 10 01:58:39 oliverp kernel: stack pointer = 0x10:0xff8078360940 Jul 10 01:58:39 oliverp kernel: frame pointer = 0x10:0xff0004c31390 Jul 10 01:58:39 oliverp kernel: code segment= base 0x0, limit 0xf, type 0x1b Jul 10 01:58:39 oliverp kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Jul 10 01:58:39 oliverp kernel: processor eflags= resume, IOPL = 0 Jul 10 01:58:39 oliverp kernel: current process = 60406 (smbiod0) Jul 10 01:58:39 oliverp kernel: trap number = 12 Jul 10 01:58:39 oliverp kernel: panic: page fault Jul 10 01:58:39 oliverp kernel: cpuid = 2 Jul 10 01:58:39 oliverp kernel: Uptime: 6h51m16s Jul 10 01:58:39 oliverp kernel: Physical memory: 4087 MB Jul 10 01:58:39 oliverp kernel: Dumping 2448 MB:Copyright (c) 1992-2009 The FreeBSD Project. ___ 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 " ___ 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: smbfs panic when lost connection or unmount --force
the good vnods On 7/11/09, Attilio Rao wrote: > 2009/7/11 Oliver Pinter : >> regs and vnodes: >> >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01854.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01855.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01856.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01857.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01858.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01859.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01860.JPG > > Sorry, maybe I wasn't clear, you should spell them 'lockedvnods'. > > Thanks, > Attilio > > > > -- > Peace can only be achieved by understanding - A. Einstein > ___ 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: smbfs panic when lost connection or unmount --force
2009/7/11 Oliver Pinter : > regs and vnodes: > > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01854.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01855.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01856.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01857.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01858.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01859.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01860.JPG Sorry, maybe I wasn't clear, you should spell them 'lockedvnods'. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: smbfs panic when lost connection or unmount --force
regs and vnodes: http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01854.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01855.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01856.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01857.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01858.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01859.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01860.JPG On 7/10/09, Attilio Rao wrote: > 2009/7/10 Oliver Pinter : >> Hello! >> >> Here is the bt: >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01845.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01846.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01847.JPG > > Could you please add in this informations registers state and locked > vnodes? > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > ___ 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: smbfs panic when lost connection or unmount --force
2009/7/10 Oliver Pinter : > Hello! > > Here is the bt: > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01845.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01846.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01847.JPG Could you please add in this informations registers state and locked vnodes? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: smbfs panic when lost connection or unmount --force
Hello! Here is the bt: http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01845.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01846.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01847.JPG steps to reproduce: 1) mount_smbfs -I server //b...@foo.bar.baz /media/biz 2) generate IO from smb (cp somewate ..) 3) under IO pull down the network cable 4) a) wait to panic b) umount -f /media/biz, and the system faster panics On 7/10/09, Robert Watson wrote: > > On Fri, 10 Jul 2009, Oliver Pinter wrote: > >> It is a kernel panic, when force unmount the smbfs volume or lost the >> connection with the samba server. > > This is a NULL pointer dereference in the kernel. Per Attilio's e-mail, a > stack trace should help us track it down. Thanks! > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> -- >> Thes OS is: >> >> >> kern.ostype: FreeBSD >> kern.osrelease: 7.2-STABLE >> kern.osrevision: 199506 >> kern.version: FreeBSD 7.2-STABLE #4: Sat Jun 27 21:44:32 CEST 2009 >>r...@oliverp:/usr/obj/usr/src/sys/stable >> kern.osreldate: 702103 >> >> -- >> make.conf: >> >> >> CPUTYPE?=core2 >> CFLAGS= -O2 -fno-strict-aliasing -pipe >> MODULES_OVERRIDE=smbfs libiconv libmchain zfs opensolaris drm cd9660 >> cd9660_iconv >> >> -- >> panic message: >> >> Jul 10 01:58:39 oliverp syslogd: kernel boot file is /boot/kernel/kernel >> Jul 10 01:58:39 oliverp kernel: kernel trap 12 with interrupts disabled >> Jul 10 01:58:39 oliverp kernel: >> Jul 10 01:58:39 oliverp kernel: >> Jul 10 01:58:39 oliverp kernel: Fatal trap 12: page fault while in kernel >> mode >> Jul 10 01:58:39 oliverp kernel: cpuid = 2; apic id = 02 >> Jul 10 01:58:39 oliverp kernel: fault virtual address= 0x30 >> Jul 10 01:58:39 oliverp kernel: fault code = supervisor read data, >> page not present >> Jul 10 01:58:39 oliverp kernel: instruction pointer = >> 0x8:0x80327fd0 >> Jul 10 01:58:39 oliverp kernel: stack pointer= >> 0x10:0xff8078360940 >> Jul 10 01:58:39 oliverp kernel: frame pointer= >> 0x10:0xff0004c31390 >> Jul 10 01:58:39 oliverp kernel: code segment = base 0x0, limit >> 0xf, type 0x1b >> Jul 10 01:58:39 oliverp kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >> Jul 10 01:58:39 oliverp kernel: processor eflags = resume, IOPL = 0 >> Jul 10 01:58:39 oliverp kernel: current process = 60406 >> (smbiod0) >> Jul 10 01:58:39 oliverp kernel: trap number = 12 >> Jul 10 01:58:39 oliverp kernel: panic: page fault >> Jul 10 01:58:39 oliverp kernel: cpuid = 2 >> Jul 10 01:58:39 oliverp kernel: Uptime: 6h51m16s >> Jul 10 01:58:39 oliverp kernel: Physical memory: 4087 MB >> Jul 10 01:58:39 oliverp kernel: Dumping 2448 MB:Copyright (c) >> 1992-2009 The FreeBSD Project. >> ___ >> 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" >> > ___ 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: smbfs panic when lost connection or unmount --force
Hello! I know, that the bt is useful, but ddb works with usb keyboard? At nigth then I send the log. //sorry for bad english ps.: attached the config On 7/10/09, Robert Watson wrote: > > On Fri, 10 Jul 2009, Oliver Pinter wrote: > >> It is a kernel panic, when force unmount the smbfs volume or lost the >> connection with the samba server. > > This is a NULL pointer dereference in the kernel. Per Attilio's e-mail, a > stack trace should help us track it down. Thanks! > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> -- >> Thes OS is: >> >> >> kern.ostype: FreeBSD >> kern.osrelease: 7.2-STABLE >> kern.osrevision: 199506 >> kern.version: FreeBSD 7.2-STABLE #4: Sat Jun 27 21:44:32 CEST 2009 >>r...@oliverp:/usr/obj/usr/src/sys/stable >> kern.osreldate: 702103 >> >> -- >> make.conf: >> >> >> CPUTYPE?=core2 >> CFLAGS= -O2 -fno-strict-aliasing -pipe >> MODULES_OVERRIDE=smbfs libiconv libmchain zfs opensolaris drm cd9660 >> cd9660_iconv >> >> -- >> panic message: >> >> Jul 10 01:58:39 oliverp syslogd: kernel boot file is /boot/kernel/kernel >> Jul 10 01:58:39 oliverp kernel: kernel trap 12 with interrupts disabled >> Jul 10 01:58:39 oliverp kernel: >> Jul 10 01:58:39 oliverp kernel: >> Jul 10 01:58:39 oliverp kernel: Fatal trap 12: page fault while in kernel >> mode >> Jul 10 01:58:39 oliverp kernel: cpuid = 2; apic id = 02 >> Jul 10 01:58:39 oliverp kernel: fault virtual address= 0x30 >> Jul 10 01:58:39 oliverp kernel: fault code = supervisor read data, >> page not present >> Jul 10 01:58:39 oliverp kernel: instruction pointer = >> 0x8:0x80327fd0 >> Jul 10 01:58:39 oliverp kernel: stack pointer= >> 0x10:0xff8078360940 >> Jul 10 01:58:39 oliverp kernel: frame pointer= >> 0x10:0xff0004c31390 >> Jul 10 01:58:39 oliverp kernel: code segment = base 0x0, limit >> 0xf, type 0x1b >> Jul 10 01:58:39 oliverp kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >> Jul 10 01:58:39 oliverp kernel: processor eflags = resume, IOPL = 0 >> Jul 10 01:58:39 oliverp kernel: current process = 60406 >> (smbiod0) >> Jul 10 01:58:39 oliverp kernel: trap number = 12 >> Jul 10 01:58:39 oliverp kernel: panic: page fault >> Jul 10 01:58:39 oliverp kernel: cpuid = 2 >> Jul 10 01:58:39 oliverp kernel: Uptime: 6h51m16s >> Jul 10 01:58:39 oliverp kernel: Physical memory: 4087 MB >> Jul 10 01:58:39 oliverp kernel: Dumping 2448 MB:Copyright (c) >> 1992-2009 The FreeBSD Project. >> ___ >> 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" >> > # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.484.2.14 2008/08/29 18:54:35 jhb Exp $ cpu HAMMER ident sTaBlE-debug # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal struct # ures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and # cycles # options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_EXTATTR options UFS_EXTATTR_AUTOSTART options UFS_ACL # Support for access control lists options UFS_
Re: smbfs panic when lost connection or unmount --force
On Fri, 10 Jul 2009, Oliver Pinter wrote: It is a kernel panic, when force unmount the smbfs volume or lost the connection with the samba server. This is a NULL pointer dereference in the kernel. Per Attilio's e-mail, a stack trace should help us track it down. Thanks! Robert N M Watson Computer Laboratory University of Cambridge -- Thes OS is: kern.ostype: FreeBSD kern.osrelease: 7.2-STABLE kern.osrevision: 199506 kern.version: FreeBSD 7.2-STABLE #4: Sat Jun 27 21:44:32 CEST 2009 r...@oliverp:/usr/obj/usr/src/sys/stable kern.osreldate: 702103 -- make.conf: CPUTYPE?=core2 CFLAGS= -O2 -fno-strict-aliasing -pipe MODULES_OVERRIDE=smbfs libiconv libmchain zfs opensolaris drm cd9660 cd9660_iconv -- panic message: Jul 10 01:58:39 oliverp syslogd: kernel boot file is /boot/kernel/kernel Jul 10 01:58:39 oliverp kernel: kernel trap 12 with interrupts disabled Jul 10 01:58:39 oliverp kernel: Jul 10 01:58:39 oliverp kernel: Jul 10 01:58:39 oliverp kernel: Fatal trap 12: page fault while in kernel mode Jul 10 01:58:39 oliverp kernel: cpuid = 2; apic id = 02 Jul 10 01:58:39 oliverp kernel: fault virtual address = 0x30 Jul 10 01:58:39 oliverp kernel: fault code = supervisor read data, page not present Jul 10 01:58:39 oliverp kernel: instruction pointer = 0x8:0x80327fd0 Jul 10 01:58:39 oliverp kernel: stack pointer = 0x10:0xff8078360940 Jul 10 01:58:39 oliverp kernel: frame pointer = 0x10:0xff0004c31390 Jul 10 01:58:39 oliverp kernel: code segment= base 0x0, limit 0xf, type 0x1b Jul 10 01:58:39 oliverp kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Jul 10 01:58:39 oliverp kernel: processor eflags= resume, IOPL = 0 Jul 10 01:58:39 oliverp kernel: current process = 60406 (smbiod0) Jul 10 01:58:39 oliverp kernel: trap number = 12 Jul 10 01:58:39 oliverp kernel: panic: page fault Jul 10 01:58:39 oliverp kernel: cpuid = 2 Jul 10 01:58:39 oliverp kernel: Uptime: 6h51m16s Jul 10 01:58:39 oliverp kernel: Physical memory: 4087 MB Jul 10 01:58:39 oliverp kernel: Dumping 2448 MB:Copyright (c) 1992-2009 The FreeBSD Project. ___ 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" ___ 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: smbfs panic when lost connection or unmount --force
2009/7/10 Oliver Pinter : > Hi all! > > It is a kernel panic, when force unmount the smbfs volume or lost the > connection with the samba server. > > -- > Thes OS is: > > > kern.ostype: FreeBSD > kern.osrelease: 7.2-STABLE > kern.osrevision: 199506 > kern.version: FreeBSD 7.2-STABLE #4: Sat Jun 27 21:44:32 CEST 2009 >r...@oliverp:/usr/obj/usr/src/sys/stable > kern.osreldate: 702103 > > -- > make.conf: > > > CPUTYPE?=core2 > CFLAGS= -O2 -fno-strict-aliasing -pipe > MODULES_OVERRIDE=smbfs libiconv libmchain zfs opensolaris drm cd9660 > cd9660_iconv > > -- > panic message: > > Jul 10 01:58:39 oliverp syslogd: kernel boot file is /boot/kernel/kernel > Jul 10 01:58:39 oliverp kernel: kernel trap 12 with interrupts disabled > Jul 10 01:58:39 oliverp kernel: > Jul 10 01:58:39 oliverp kernel: > Jul 10 01:58:39 oliverp kernel: Fatal trap 12: page fault while in kernel mode > Jul 10 01:58:39 oliverp kernel: cpuid = 2; apic id = 02 > Jul 10 01:58:39 oliverp kernel: fault virtual address = 0x30 > Jul 10 01:58:39 oliverp kernel: fault code = supervisor read > data, > page not present > Jul 10 01:58:39 oliverp kernel: instruction pointer = > 0x8:0x80327fd0 > Jul 10 01:58:39 oliverp kernel: stack pointer = > 0x10:0xff8078360940 > Jul 10 01:58:39 oliverp kernel: frame pointer = > 0x10:0xff0004c31390 > Jul 10 01:58:39 oliverp kernel: code segment= base 0x0, limit > 0xf, type 0x1b > Jul 10 01:58:39 oliverp kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 > Jul 10 01:58:39 oliverp kernel: processor eflags= resume, IOPL = 0 > Jul 10 01:58:39 oliverp kernel: current process = 60406 (smbiod0) > Jul 10 01:58:39 oliverp kernel: trap number = 12 > Jul 10 01:58:39 oliverp kernel: panic: page fault > Jul 10 01:58:39 oliverp kernel: cpuid = 2 > Jul 10 01:58:39 oliverp kernel: Uptime: 6h51m16s > Jul 10 01:58:39 oliverp kernel: Physical memory: 4087 MB > Jul 10 01:58:39 oliverp kernel: Dumping 2448 MB:Copyright (c) > 1992-2009 The FreeBSD Project. Can you at least produce a backtrace for that? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: smbfs
When this happened to me, I figured out I forgot my ~/.nsmbrc file. Your password should be stored in there [MACHINE:USER] password=secret Maxim Kizik wrote: On Wed, 29 Jun 2005 18:34:10 +0800, Jiawei Ye wrote After upgrading my system from FreeBSD 4.10 to FreeBSD 5.3, I found "mount_smbfs -N" broken. The error message is "mount_smbfs: unable to open connection: syserr = Authentication error". However, the keyboard interactive password works normally. The problem still persists in 5.4p2. Could you please try "/usr/sbin/mount_smbfs -N" and if that works, you need to remove the old mount_smbfs binary from your system. Thank you for the idea, but it does not work. I tried to use /etc/nsmb.conf... There's no success too. -- Maxim Kizik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: smbfs
On Wed, 29 Jun 2005 18:34:10 +0800, Jiawei Ye wrote > > After upgrading my system from FreeBSD 4.10 to FreeBSD 5.3, I found > > "mount_smbfs -N" broken. The error message is "mount_smbfs: unable to > > open connection: syserr = Authentication error". > > However, the keyboard interactive password works normally. > > > > The problem still persists in 5.4p2. > Could you please try "/usr/sbin/mount_smbfs -N" and if that works, > you need to remove the old mount_smbfs binary from your system. Thank you for the idea, but it does not work. I tried to use /etc/nsmb.conf... There's no success too. -- Maxim Kizik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: smbfs
On 6/29/05, Maxim Kizik <[EMAIL PROTECTED]> wrote: > Good Afternoon. > > > After upgrading my system from FreeBSD 4.10 to FreeBSD 5.3, I found > "mount_smbfs -N" broken. The error message is "mount_smbfs: unable to > open connection: syserr = Authentication error". > However, the keyboard interactive password works normally. > > The problem still persists in 5.4p2. > I need this feature strongly because of running automatic backup procedures. > Is there any solution? > > > > -- > Maxim Kizik Could you please try "/usr/sbin/mount_smbfs -N" and if that works, you need to remove the old mount_smbfs binary from your system. Cheers, Jiawei -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: smbfs
On Tue, Jun 28, 2005 at 10:35:09PM +0400, Maxim Kizik wrote: > Good Afternoon. > > > After upgrading my system from FreeBSD 4.10 to FreeBSD 5.3, I found > "mount_smbfs -N" broken. The error message is "mount_smbfs: unable to > open connection: syserr = Authentication error". > However, the keyboard interactive password works normally. > > The problem still persists in 5.4p2. > I need this feature strongly because of running automatic backup procedures. > Is there any solution? The most obvious guess is that it's a configuration error of some kind on your machine. Kris pgpxqwZLsewG4.pgp Description: PGP signature
RE: smbfs
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Maxim Kizik > Sent: 28. juni 2005 20:35 > To: [EMAIL PROTECTED] > Subject: smbfs > > Good Afternoon. > > > After upgrading my system from FreeBSD 4.10 to FreeBSD 5.3, I > found "mount_smbfs -N" broken. The error message is > "mount_smbfs: unable to open connection: syserr = > Authentication error". > However, the keyboard interactive password works normally. > > The problem still persists in 5.4p2. > I need this feature strongly because of running automatic > backup procedures. > Is there any solution? > > > > -- > Maxim Kizik > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > Don't have this problem, using mount_smbfs -N -I /XXX/YYY etc. On .4-RELEASE FreeBSD 5.4-RELEASE #4: Sun May 8 01:57:26 CEST 2005 - Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: smbfs breakage in 4.5-stable
On Sat, 2002-02-02 at 16:04, Peter C. Lai wrote: > OK. Here's what I did wrong (and after fixing this, it worked): > in /usr/src/sys/i386/conf/MACHNAME built from scratch, I had: > OPTIONS NETSMB > OPTIONS NETSMBCRYPTO > OPTIONS LIBMCHAIN > OPTIONS LIBICONV > however, in the filesystems section, i had omitted OPTIONS SMBFS > > apparently, if I explicitly add net[smb|crypto], libmchain, and libiconv, > I need to add in smbfs also. (I didn't realize this, since SMBFS is lumped > in with all the other filesystems, which don't depend on anything, and > can be safely modularized without being declared in the configuration file). > > Adding SMBFS back in to the kernel config fixed the smbfs problem. > > Now, can I remove net[smb|crypto], libmchain, libiconv, and smbfs, and > have everything working as modules? Implicit modularization still > confuses me (unlike in linux, where you explicitly state static,module,or >don't-compile). I have _nothing_ relating to smbfs in my kernel, and mount_smbfs works just using klds. The only place I've seen a problem with just using klds is on SMP machines. In those cases, I had to statically include the smbfs stuff in the kernel. Joe > > On Sat, Feb 02, 2002 at 01:29:58AM -0500, Joe Clarke wrote: > > On Sat, 2002-02-02 at 01:09, Peter C. Lai wrote: > > > After 4.5 was released, i cvsup'd a complete fresh set of sources > > > (e.g. deleting /usr/src/* and /usr/obj/*), > > > made world, installed world and a new kernel, and now mount_smbfs errors > > > out the first time with 'exec format' and if you try it again, > > > it says 'file exists'. kldstat shows the smbfs.ko not loaded the first time > > > it fails but it does load the second time, and remains loaded. There is no > > > error with the module loading. > > > > The smbfs kernel module was modified in the 4.5-PRERELEASE track so to > > depend on the libiconv and libmchain modules. Before that, doing a > > mount_smbfs resulted in an "exec format error" with a message in > > /var/log/messages indicated a symbol in smbfs.ko was undefined. You > > might want to verify that all of those modules are up-to-date. I just > > tried this on a recent 4.5-RC machine with no smbfs-related options in > > the kernel, and it worked like a champ. > > > > > > > > After perusing the mailing lists, I realized the problem could be caused by > > > the smbfs port which i didn't remove prior to make and install world. > > > I pkg_delete'd it, during which it noted that /sbin/mount_smbfs and > > > /modules/smbfs.ko had been modified. Thus, the installworld did overwrite > > > those two files into the 4.5 versions. > > > > Make sure that when you rebuild world, you build all the kernel modules > > as well. When you mount a smb share, you should have the following > > modules loaded: > > > > 51 0xc3417000 1a000smbfs.ko > > 61 0xc3432000 3000 libiconv.ko > > 71 0xc3436000 3000 libmchain.ko > > > > Joe > > > > > > > > on bootup, netsmb_dev loads fine. Another note: I installed the same world > > > onto another machine running a completely new install of 4.5-rc3 via samba > > > export, and now that machine's mount_smbfs is broken too. > > > > > > any help would be appreciated > > > Please cc responses to [EMAIL PROTECTED] since i don't subscribe to > > > either -questions or -stable > > > -- > > > Peter C. Lai > > > University of Connecticut > > > Dept. of Residential Life | Programmer > > > Dept. of Molecular and Cell Biology | Undergraduate Research Assistant > > > http://cowbert.2y.net/ > > > 860.427.4542 (Room) > > > 860.486.1899 (Lab) > > > 203.206.3784 (Cellphone) > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-stable" in the body of the message > > > > > > > > > -- > Peter C. Lai > University of Connecticut > Dept. of Residential Life | Programmer > Dept. of Molecular and Cell Biology | Undergraduate Research Assistant > http://cowbert.2y.net/ > 860.427.4542 (Room) > 860.486.1899 (Lab) > 203.206.3784 (Cellphone) > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: SMBFS panic: malloc: wrong bucket (was: 4.3-20010721-STABLE)
On Wed, 25 Jul 2001, Tim Zingelman wrote: > This is a known bug, but not fixed. I worked with the maintainer, Boris > Popov on it a little, but in my case it took some time between the mount > and the panic, and I was not able to give him login access to the > machines involved. As a result it remains unfixed. If you have a case > that panics immediately and can work with him, I think he would be > interested in getting this fixed. (I know I would :) Please try the attached patch. It fixes a nasty buffer overflow which may cause this panic. > > I'd recommend contacting the smbfs maintainer. It seems the kernel > > module for smbfs is now integrated into the main sources, but you > > still need to install a port. So I'm guessing it's now in some sort of > > transitional status (and thus quite unstable). Hear, hear :) All userland code for smbfs was planned to be included before 4.4 comes out. But, life is life - it has its own plans, and I hope to finish import after 4.4... -- Boris Popov http://www.butya.kz/~bp/ Index: smb.h === RCS file: /home/ncvs/src/sys/netsmb/smb.h,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 smb.h --- smb.h 2001/05/22 08:32:33 1.1.2.1 +++ smb.h 2001/08/03 13:32:25 @@ -68,7 +68,7 @@ */ #defineSMB_SIGNATURE "\xFFSMB" #defineSMB_SIGLEN 4 -#defineSMB_HDRMID(p) (*(u_short*)((u_char*)(p) + 30)) +#defineSMB_HDRMID(p) (letohs(*(u_short*)((u_char*)(p) + 30))) #defineSMB_HDRLEN 32 /* * bits in the smb_flags field Index: smb_crypt.c === RCS file: /home/ncvs/src/sys/netsmb/smb_crypt.c,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 smb_crypt.c --- smb_crypt.c 2001/05/22 08:32:33 1.1.2.1 +++ smb_crypt.c 2001/08/03 13:32:25 @@ -120,7 +120,7 @@ int len; len = strlen(apwd); - unipwd = malloc(len * sizeof(u_int16_t), M_SMBTEMP, M_WAITOK); + unipwd = malloc((len + 1) * sizeof(u_int16_t), M_SMBTEMP, M_WAITOK); /* * S21 = concat(MD4(U(apwd)), zeros(5)); */ Index: smb_rq.c === RCS file: /home/ncvs/src/sys/netsmb/smb_rq.c,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 smb_rq.c --- smb_rq.c2001/05/22 08:32:33 1.1.2.1 +++ smb_rq.c2001/08/03 13:32:25 @@ -238,7 +238,7 @@ bcnt = rqp->sr_rq.mb_count; if (bcnt > 0x) SMBERROR("byte count too large (%d)\n", bcnt); - *rqp->sr_bcount = bcnt; + *rqp->sr_bcount = htoles(bcnt); } int
Re: SMBFS on latest stable
> > > I found one bug, and that is that I can mount the same share twice > > at the same mountpoint... > > This is not actually a bug. When I've made such restriction in the > nwfs filesystem, many people complained about it :) You must be kidding, does it have any use? Besides make one confused. Ron. > > -- > Boris Popov > http://www.butya.kz/~bp/ > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: smbfs: disconnected servers
In local.freebsd-stable, you wrote: >However, the problems begin when somebody whose share I mounted >decides to switch off his computer: I (obviously) cannot read from the >mountpoint anymore, but there also is _no way_ of forcefully >unmounting the share anymore. Maybe smbfs should be ported to userland (portal) somehow? I'm not saying im volunteering, though ;) But I'd like to know if there are any limitations which might prevent this from working... I think I ran into the same troubles with sharity-light, because of the usual lock-ups when NFS become unavailable. -- Abstrakte Syntaxträume. Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: mount_mfs (Re: smbfs)
On Fri, 25 May 2001, Brooks Davis wrote: > On Fri, May 25, 2001 at 10:04:09PM +0700, Boris Popov wrote: > > There is no any technical problems in doing that. But I'm unsure > > if this should be done (code is not very small). On other hand, people > > expect it in the base system... Probably we should collect more votes on > > this topic. > > I'll definatly vote for inclusion. IMO, it makes no sense to have a > filesystem in the base you can't mount. If it really is so hugh that > people complain, there's always the ugly NO_MOUNT_SMBFS make.conf option > route. Those who really need small systems have to strip all sorts of > things out already anyway, one more won't hurt. Ok, now I've received about fifty votes for inclusion of userland part in the base tree and zero objections. Import process will be done in the -current first and then MFCed to -stable. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message