Re: nightly snapshot for CURRENT ?
> On Tue, 9 Jun 2020 19:56:30 +
> Glen Barber wrote:
>
> > On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot wrote:
> > >
> > > Hello all,
> > >
> > > I've just hit again something that I've hit (and probably others too)
> > > often.
> > > If a change in base break some ports and it's snapshoted in the txz
> > > available at download.freebsd.org, you need to wait a week for the next
> > > tarball to be available.
> > > Since poudriere uses the tarball when you setup a jail it means that
> > > the only solution you have is to recreate your jail by building it, and
> > > since building world nowdays is very expensive that delay your work too
> > > much.
> > > Would it be possible to generate the tarballs every day instead of
> > > every week ? At least for tier-1 arches.
> > >
> >
> > Let's revisit this sometime next week after 11.4 is out.
> >
> > Glen
> >
>
> Sure, works for me.
>
> Thanks,
Its not quite a snapshot, but it is the bits one needs to quickly
contruct one, and that is in the jenkins artifacts. I even
modified my diskless boot environment creater so I can give it
a rX that exists in Jenkins and it builds me a diskless boot
tree all set up ready for testing/recovery.
http://artifacts.ci.freebsd.org/snapshot/head/${SVNREV}/${ARCH}/${ARCH}/base.txz
> --
> Emmanuel Vadot
--
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nightly snapshot for CURRENT ?
On Tue, Jun 9, 2020 at 7:17 PM Clay Daniels wrote: > > On Tue, Jun 9, 2020 at 2:48 PM Emmanuel Vadot wrote: > > > > > Hello all, > > > > I've just hit again something that I've hit (and probably others too) > > often. > > If a change in base break some ports and it's snapshoted in the txz > > available at download.freebsd.org, you need to wait a week for the next > > tarball to be available. > > Since poudriere uses the tarball when you setup a jail it means that > > the only solution you have is to recreate your jail by building it, and > > since building world nowdays is very expensive that delay your work too > > much. > > Would it be possible to generate the tarballs every day instead of > > every week ? At least for tier-1 arches. > > > > Cheers, > > > > -- > > Emmanuel Vadot > > ___ > > > > At first I thought you were referring to the weekly snapshots packaged as > install images: > https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/ > > But I think you are talking about the snapshots of each part, like base, > kernel, ports. src, etc to use as a roll your own install like: > https://download.freebsd.org/ftp/snapshots/arm64/13.0-CURRENT/ > Yes, these are the parts he's talking about. My initial impression is that it'd be nice if we could (somehow) leverage Jenkins artifacts [0] to get even more frequent updates if we really needed to without significantly impacting re@ -- that's a little more difficult, though, because build breakage makes it hard to predict what the latest snapshot you can actually grab is, if any. Perhaps a script that creates a symlink to the 'last known functional across the board' revision periodically... [0] http://artifacts.ci.freebsd.org/snapshot/head/r361934/amd64/amd64/ > From my selfish perspective as a weekly installer of the regular Thursday > image or iso of 13.0 Current, I would hate to lose the pre-rolled > installer, and I think there are probably others like me. As long as you > keep the weekly install snapshots, it will not affect folks like me. I must > say that what you want to do is how NetBSD does their daily cent > snapshots, and they do not even offer pre-rolled install images. > > But you are a real developer and I'm just a retired guy playing with his > hobby, so go ahead and do what you think is best for you. > This was brought up in a public forum, you should probably feel free to make non-obstructive comments like this to make sure a fairly common need is represented. The (light-hearted?) self-deprecation near the end of this makes me a bit uneasy- I certainly hope you didn't feel like it was mandatory to acknowledge that he's a developer and you're a hobbyist, because there's most assuredly more hobbyists (such as myself) lurking with similar needs/desires. =-) Thanks, Kyle Evans ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nightly snapshot for CURRENT ?
On Tue, Jun 09, 2020 at 07:16:47PM -0500, Clay Daniels wrote: > On Tue, Jun 9, 2020 at 2:48 PM Emmanuel Vadot wrote: > > > > > Hello all, > > > > I've just hit again something that I've hit (and probably others too) > > often. > > If a change in base break some ports and it's snapshoted in the txz > > available at download.freebsd.org, you need to wait a week for the next > > tarball to be available. > > Since poudriere uses the tarball when you setup a jail it means that > > the only solution you have is to recreate your jail by building it, and > > since building world nowdays is very expensive that delay your work too > > much. > > Would it be possible to generate the tarballs every day instead of > > every week ? At least for tier-1 arches. > > > > At first I thought you were referring to the weekly snapshots packaged as > install images: > https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/ > > But I think you are talking about the snapshots of each part, like base, > kernel, ports. src, etc to use as a roll your own install like: > https://download.freebsd.org/ftp/snapshots/arm64/13.0-CURRENT/ > > From my selfish perspective as a weekly installer of the regular Thursday > image or iso of 13.0 Current, I would hate to lose the pre-rolled > installer, and I think there are probably others like me. As long as you > keep the weekly install snapshots, it will not affect folks like me. I must > say that what you want to do is how NetBSD does their daily current > snapshots, and they do not even offer pre-rolled install images. > > But you are a real developer and I'm just a retired guy playing with his > hobby, so go ahead and do what you think is best for you. > I agree with exactly with your point here, which is why I would like to back-burner this topic until next week. Just FWIW. Glen signature.asc Description: PGP signature
Re: nightly snapshot for CURRENT ?
On Tue, Jun 9, 2020 at 2:48 PM Emmanuel Vadot wrote: > > Hello all, > > I've just hit again something that I've hit (and probably others too) > often. > If a change in base break some ports and it's snapshoted in the txz > available at download.freebsd.org, you need to wait a week for the next > tarball to be available. > Since poudriere uses the tarball when you setup a jail it means that > the only solution you have is to recreate your jail by building it, and > since building world nowdays is very expensive that delay your work too > much. > Would it be possible to generate the tarballs every day instead of > every week ? At least for tier-1 arches. > > Cheers, > > -- > Emmanuel Vadot > ___ > At first I thought you were referring to the weekly snapshots packaged as install images: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/ But I think you are talking about the snapshots of each part, like base, kernel, ports. src, etc to use as a roll your own install like: https://download.freebsd.org/ftp/snapshots/arm64/13.0-CURRENT/ >From my selfish perspective as a weekly installer of the regular Thursday image or iso of 13.0 Current, I would hate to lose the pre-rolled installer, and I think there are probably others like me. As long as you keep the weekly install snapshots, it will not affect folks like me. I must say that what you want to do is how NetBSD does their daily current snapshots, and they do not even offer pre-rolled install images. But you are a real developer and I'm just a retired guy playing with his hobby, so go ahead and do what you think is best for you. Clay ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc
Hope you don't mind the top post, but since this is now an update and somewhat different, I don't think it makes sense to imbed this in the message below. r358098 will hang fairly easily, in 1-3 cycles of the kernel build over NFS. I thought this was the culprit, since I did 6 cycles of r358097 without a hang. However, I just got a hang with r358097, but it looks rather different. The r358097 hang did not have any processes sleeping on btalloc. They appeared to be waiting on two different locks in the buffer cache. As such, I think it might be a different problem. (I'll admit I should have made notes about this one before rebooting, but I was flustrated that it happened and rebooted before looking at it mush detail.) Jeff, to fill you in, I have been getting intermittent hangs on a Pentium 4 (single core i386) with 1.25Gbytes ram when doing kernel builds using head kernels from this winter. (I also saw one when doing a kernel build on UFS, so they aren't NFS specific, although easier to reproduce that way.) After a typical hang, there will be a bunch of processes sleeping on "btalloc" and several processes holding the following lock: exclusive sx lock @ vm/vm_map.c:4761 - I have seen hangs where that is the only lock held by any process except the interrupt thread. - I have also seen processes waiting on the following locks: kern/subr_vmem.c:1343 kern/subr_vmem.c:633 I can't be absolutely sure r358098 is the culprit, but it seems to make the problem more reproducible. If anyone has a patch suggestion, I can test it. Otherwise, I will continue to test r358097 and earlier, to try and see what hangs occur. (I've done 8 cycles of testing of r356776 without difficulties, but that doesn't guarantee it isn't broken.) There is a bunch more of the stuff I got for Kostik and Ryan below. I can do "db" when it is hung, but it is a screen console, so I need to transcribe the output to email by hand. (ie. If you need something specific I can do that, but trying to do everything Kostik and Ryan asked for isn't easy.) rick Konstantin Belousov wrote: >On Fri, May 22, 2020 at 11:46:26PM +, Rick Macklem wrote: >> Konstantin Belousov wrote: >> >On Wed, May 20, 2020 at 11:58:50PM -0700, Ryan Libby wrote: >> >> On Wed, May 20, 2020 at 6:04 PM Rick Macklem wrote: >> >> > >> >> > Hi, >> >> > >> >> > Since I hadn't upgraded a kernel through the winter, it took me a while >> >> > to bisect this, but r358252 seems to be the culprit. No longer true. I succeeded in reproducing the hang to-day running a r358251 kernel. I haven't had much luck sofar, but see below for what I have learned. >> >> > >> >> > If I do a kernel build over NFS using my not so big Pentium 4 (single >> >> > core, >> >> > 1.25Gbytes RAM, i386), about every second attempt will hang. >> >> > When I do a "ps" in the debugger, I see processes sleeping on btalloc. >> >> > If I revert to r358251, I cannot reproduce this. As above, this is no longer true. >> >> > >> >> > Any ideas? >> >> > >> >> > I can easily test any change you might suggest to see if it fixes the >> >> > problem. >> >> > >> >> > If you want more debug info, let me know, since I can easily >> >> > reproduce it. >> >> > >> >> > Thanks, rick >> >> >> >> Nothing obvious to me. I can maybe try a repro on a VM... >> >> >> >> ddb ps, acttrace, alltrace, show all vmem, show page would be welcome. >> >> >> >> "btalloc" is "We're either out of address space or lost a fill race." >From what I see, I think it is "out of address space". For one of the hangs, when I did "show alllocks", everything except the intr thread, was waiting for the exclusive sx lock @ vm/vm_map.c:4761 >> > >> >Yes, I would be not surprised to be out of something on 1G i386 machine. >> >Please also add 'show alllocks'. >> Ok, I used an up to date head kernel and it took longer to reproduce a hang. Go down to Kostik's comment about kern.maxvnodes for the rest of what I've learned. (The time it takes to reproduce one of these varies greatly, but I usually get one within 3 cycles of a full kernel build over NFS. I have had it happen once when doing a kernel build over UFS.) >> This time, none of the processes are stuck on "btalloc". > I'll try and give you most of the above, but since I have to type it in by > hand > from the screen, I might not get it all. (I'm no real typist;-) > > show alllocks > exclusive lockmgr ufs (ufs) r = 0 locked @ kern/vfs_subr.c: 3259 > exclusive lockmgr nfs (nfs) r = 0 locked @ kern/vfs_lookup.c:737 > exclusive sleep mutex kernel area domain (kernel arena domain) r = 0 locked @ > kern/subr_vmem.c:1343 > exclusive lockmgr bufwait (bufwait) r = 0 locked @ kern/vfs_bio.c:1663 > exclusive lockmgr ufs (ufs) r = 0 locked @ kern/vfs_subr.c:2930 > exclusive lockmgr syncer (syncer) r = 0 locked @ kern/vfs_subr.c:2474 > Process 12 (intr) thread 0x.. (108) > exclusive sleep mutex Giant (Giant) r = 0 locked @ kern/kern_intr.c:1152 > > > ps > - Not going to list them all, but here are the ones t
Re: MRSAS Panic during Install.
Hi there, apologies for the delayed response.
Regarding the lock reversal, I can try to capture the screen showing the
message.
The "Wil check go it goes" it was my brain trying to multitask,
obviously not in a successful way. What I meant to say was "I will check
how it goes. without the RAID".
Sure, I will test with the patch and let you know asap. hopefully by
tomorrow night(BST).
Cheers
Santi
On 2020-06-09 19:20, Kashyap Desai wrote:
-Original Message-
From: Santiago Martinez [mailto:s...@codenetworks.net]
Sent: Tuesday, June 9, 2020 11:27 PM
To: Kashyap Desai ; Don Lewis
; Andriy Gapon
Cc: FreeBSD Current ; Kashyap D. Desai
; Kenneth D. Merry ; Sumit Saxena
; Chandrakanth Patil
Subject: Re: MRSAS Panic during Install.
Hi! so it works but i got a lock order reversal warning, but it continue.
OK. So what is a warning ?
Wil check go it goes
Could not get your point. Can you elaborate ?
Also can you try Raid - 1 VD with below patch ?
diff --git a/mrsas.c b/mrsas.c
index 3d33073..60f4b4d 100755
--- a/mrsas.c
+++ b/mrsas.c
@@ -1744,11 +1744,14 @@ mrsas_complete_cmd(struct mrsas_softc *sc, u_int32_t
MSIxIndex)
data_length =
r1_cmd->io_request->DataLength;
sense =
r1_cmd->sense;
}
+
+ mtx_lock(&sc->sim_lock);
r1_cmd->ccb_ptr = NULL;
if (r1_cmd->callout_owner) {
callout_stop(&r1_cmd->cm_callout);
r1_cmd->callout_owner
= false;
}
+ mtx_unlock(&sc->sim_lock);
mrsas_release_mpt_cmd(r1_cmd);
mrsas_map_mpt_cmd_status(cmd_mpt,
cmd_mpt->ccb_ptr, status,
extStatus,
data_length, sense);
Santi
On 2020-06-09 11:13, Santiago Martinez wrote:
Trying right now, will let you know.
On 2020-06-09 11:07, Kashyap Desai wrote:
Hi Santi - Please try without Raid-1 VD. Most likely you will not
observe issue, but you can confirm from your end.
Kashyap
-Original Message-
From: Santiago Martinez [mailto:s...@codenetworks.net]
Sent: Tuesday, June 9, 2020 2:08 PM
To: Don Lewis ; Andriy Gapon
Cc: FreeBSD Current ; Kashyap D. Desai
; Kenneth D. Merry
Subject: Re: MRSAS Panic during Install.
Hi Kashayp, that's correct, the servers has two raids. A raid 1 VD0
with 2xSSD on it and a RAID5 VD0.
Do you want me to break the raid and see i it does not trigger the
bug?
cheers
Santi
On 2020-06-09 07:51, Don Lewis wrote:
On 9 Jun, Andriy Gapon wrote:
On 09/06/2020 03:42, Santiago Martinez wrote:
Hi Everyone, today I tested with 12.1 and it works without any
issues (at least for now).
I will sync against current and see if it fails.
Santiago
On 2020-06-08 17:41, Santiago Martinez wrote:
Hi there, tried again and now i got it with UFS also.. that make
sense..
right...
On 2020-06-08 15:20, Santiago Martinez wrote:
Hi Everyone,
I'm installing FreeBSD current(361567) snapshot on a Lenovo
SR655
server.
After selecting ZFS, and the installer tries to make the
partitions, etc I get the following panic.
I tried selecting UFS and its works.
I uploaded a screenshot as I only have KVM access to it:
https://0bin.net/paste/4yn33GkSKiYto6m4#h78yCE6h80-
3DsApbXa1XLW9+b
hoKhOr3MVS+NRgA5A
The server is a ThinkSystem SR655, with the following
controller, RAID 930-8i 2GB Flash PCIe 12Gb Adapter
Lousy OCR of the picture:
...
nic: nutex mrsas_sin_lock not ouned at
/usr/src/sys/kern/kern_nutex.c:284
...
b_trace_self_urapper () at db_trace_self_urapper+8x2b/frane
BxfeB33c44a918
anic() at vpanic+Bx182/frane BxfeA33c44ad68
nic() at panic+Bx43/frame BxfeB33c44adcd
_mtx_assert() at __mtx_assert+@xb@/frane Bxfed33c44a9dd
callout_stop_safe() at _callout_stop_safe+Bx82/frane
Bxfe33c44aac
rsas_conplete_cnd() at mrsas_complete_cnd+8x1b8/frane
BxfeB33c4daaed
ithread_loop() at ithread_loop+@x279/frame BxfeB33c44ah78
This looks like a fallout from r342064.
cm_callout is initialized like this:
callout_init_mtx(&cmd->cm_callout, &sc->sim_lock, 0); but in
mrsas_complete_cmd() it's stopped without holding the lock.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-
unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
___
Re: nightly snapshot for CURRENT ?
On Tue, 9 Jun 2020 19:56:30 + Glen Barber wrote: > On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot wrote: > > > > Hello all, > > > > I've just hit again something that I've hit (and probably others too) > > often. > > If a change in base break some ports and it's snapshoted in the txz > > available at download.freebsd.org, you need to wait a week for the next > > tarball to be available. > > Since poudriere uses the tarball when you setup a jail it means that > > the only solution you have is to recreate your jail by building it, and > > since building world nowdays is very expensive that delay your work too > > much. > > Would it be possible to generate the tarballs every day instead of > > every week ? At least for tier-1 arches. > > > > Let's revisit this sometime next week after 11.4 is out. > > Glen > Sure, works for me. Thanks, -- Emmanuel Vadot ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nightly snapshot for CURRENT ?
On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot wrote: > > Hello all, > > I've just hit again something that I've hit (and probably others too) > often. > If a change in base break some ports and it's snapshoted in the txz > available at download.freebsd.org, you need to wait a week for the next > tarball to be available. > Since poudriere uses the tarball when you setup a jail it means that > the only solution you have is to recreate your jail by building it, and > since building world nowdays is very expensive that delay your work too > much. > Would it be possible to generate the tarballs every day instead of > every week ? At least for tier-1 arches. > Let's revisit this sometime next week after 11.4 is out. Glen signature.asc Description: PGP signature
nightly snapshot for CURRENT ?
Hello all, I've just hit again something that I've hit (and probably others too) often. If a change in base break some ports and it's snapshoted in the txz available at download.freebsd.org, you need to wait a week for the next tarball to be available. Since poudriere uses the tarball when you setup a jail it means that the only solution you have is to recreate your jail by building it, and since building world nowdays is very expensive that delay your work too much. Would it be possible to generate the tarballs every day instead of every week ? At least for tier-1 arches. Cheers, -- Emmanuel Vadot ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: MRSAS Panic during Install.
Hi! so it works but i got a lock order reversal warning, but it continue. Wil check go it goes Santi On 2020-06-09 11:13, Santiago Martinez wrote: Trying right now, will let you know. On 2020-06-09 11:07, Kashyap Desai wrote: Hi Santi - Please try without Raid-1 VD. Most likely you will not observe issue, but you can confirm from your end. Kashyap -Original Message- From: Santiago Martinez [mailto:s...@codenetworks.net] Sent: Tuesday, June 9, 2020 2:08 PM To: Don Lewis ; Andriy Gapon Cc: FreeBSD Current ; Kashyap D. Desai ; Kenneth D. Merry Subject: Re: MRSAS Panic during Install. Hi Kashayp, that's correct, the servers has two raids. A raid 1 VD0 with 2xSSD on it and a RAID5 VD0. Do you want me to break the raid and see i it does not trigger the bug? cheers Santi On 2020-06-09 07:51, Don Lewis wrote: On 9 Jun, Andriy Gapon wrote: On 09/06/2020 03:42, Santiago Martinez wrote: Hi Everyone, today I tested with 12.1 and it works without any issues (at least for now). I will sync against current and see if it fails. Santiago On 2020-06-08 17:41, Santiago Martinez wrote: Hi there, tried again and now i got it with UFS also.. that make sense.. right... On 2020-06-08 15:20, Santiago Martinez wrote: Hi Everyone, I'm installing FreeBSD current(361567) snapshot on a Lenovo SR655 server. After selecting ZFS, and the installer tries to make the partitions, etc I get the following panic. I tried selecting UFS and its works. I uploaded a screenshot as I only have KVM access to it: https://0bin.net/paste/4yn33GkSKiYto6m4#h78yCE6h80- 3DsApbXa1XLW9+b hoKhOr3MVS+NRgA5A The server is a ThinkSystem SR655, with the following controller, RAID 930-8i 2GB Flash PCIe 12Gb Adapter Lousy OCR of the picture: ... nic: nutex mrsas_sin_lock not ouned at /usr/src/sys/kern/kern_nutex.c:284 ... b_trace_self_urapper () at db_trace_self_urapper+8x2b/frane BxfeB33c44a918 anic() at vpanic+Bx182/frane BxfeA33c44ad68 nic() at panic+Bx43/frame BxfeB33c44adcd _mtx_assert() at __mtx_assert+@xb@/frane Bxfed33c44a9dd callout_stop_safe() at _callout_stop_safe+Bx82/frane Bxfe33c44aac rsas_conplete_cnd() at mrsas_complete_cnd+8x1b8/frane BxfeB33c4daaed ithread_loop() at ithread_loop+@x279/frame BxfeB33c44ah78 This looks like a fallout from r342064. cm_callout is initialized like this: callout_init_mtx(&cmd->cm_callout, &sc->sim_lock, 0); but in mrsas_complete_cmd() it's stopped without holding the lock. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current- unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: MRSAS Panic during Install.
Trying right now, will let you know. On 2020-06-09 11:07, Kashyap Desai wrote: Hi Santi - Please try without Raid-1 VD. Most likely you will not observe issue, but you can confirm from your end. Kashyap -Original Message- From: Santiago Martinez [mailto:s...@codenetworks.net] Sent: Tuesday, June 9, 2020 2:08 PM To: Don Lewis ; Andriy Gapon Cc: FreeBSD Current ; Kashyap D. Desai ; Kenneth D. Merry Subject: Re: MRSAS Panic during Install. Hi Kashayp, that's correct, the servers has two raids. A raid 1 VD0 with 2xSSD on it and a RAID5 VD0. Do you want me to break the raid and see i it does not trigger the bug? cheers Santi On 2020-06-09 07:51, Don Lewis wrote: On 9 Jun, Andriy Gapon wrote: On 09/06/2020 03:42, Santiago Martinez wrote: Hi Everyone, today I tested with 12.1 and it works without any issues (at least for now). I will sync against current and see if it fails. Santiago On 2020-06-08 17:41, Santiago Martinez wrote: Hi there, tried again and now i got it with UFS also.. that make sense.. right... On 2020-06-08 15:20, Santiago Martinez wrote: Hi Everyone, I'm installing FreeBSD current(361567) snapshot on a Lenovo SR655 server. After selecting ZFS, and the installer tries to make the partitions, etc I get the following panic. I tried selecting UFS and its works. I uploaded a screenshot as I only have KVM access to it: https://0bin.net/paste/4yn33GkSKiYto6m4#h78yCE6h80- 3DsApbXa1XLW9+b hoKhOr3MVS+NRgA5A The server is a ThinkSystem SR655, with the following controller, RAID 930-8i 2GB Flash PCIe 12Gb Adapter Lousy OCR of the picture: ... nic: nutex mrsas_sin_lock not ouned at /usr/src/sys/kern/kern_nutex.c:284 ... b_trace_self_urapper () at db_trace_self_urapper+8x2b/frane BxfeB33c44a918 anic() at vpanic+Bx182/frane BxfeA33c44ad68 nic() at panic+Bx43/frame BxfeB33c44adcd _mtx_assert() at __mtx_assert+@xb@/frane Bxfed33c44a9dd callout_stop_safe() at _callout_stop_safe+Bx82/frane Bxfe33c44aac rsas_conplete_cnd() at mrsas_complete_cnd+8x1b8/frane BxfeB33c4daaed ithread_loop() at ithread_loop+@x279/frame BxfeB33c44ah78 This looks like a fallout from r342064. cm_callout is initialized like this: callout_init_mtx(&cmd->cm_callout, &sc->sim_lock, 0); but in mrsas_complete_cmd() it's stopped without holding the lock. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current- unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: MRSAS Panic during Install.
Hi Kashayp, that's correct, the servers has two raids. A raid 1 VD0 with 2xSSD on it and a RAID5 VD0. Do you want me to break the raid and see i it does not trigger the bug? cheers Santi On 2020-06-09 07:51, Don Lewis wrote: On 9 Jun, Andriy Gapon wrote: On 09/06/2020 03:42, Santiago Martinez wrote: Hi Everyone, today I tested with 12.1 and it works without any issues (at least for now). I will sync against current and see if it fails. Santiago On 2020-06-08 17:41, Santiago Martinez wrote: Hi there, tried again and now i got it with UFS also.. that make sense.. right... On 2020-06-08 15:20, Santiago Martinez wrote: Hi Everyone, I'm installing FreeBSD current(361567) snapshot on a Lenovo SR655 server. After selecting ZFS, and the installer tries to make the partitions, etc I get the following panic. I tried selecting UFS and its works. I uploaded a screenshot as I only have KVM access to it: https://0bin.net/paste/4yn33GkSKiYto6m4#h78yCE6h80-3DsApbXa1XLW9+bhoKhOr3MVS+NRgA5A The server is a ThinkSystem SR655, with the following controller, RAID 930-8i 2GB Flash PCIe 12Gb Adapter Lousy OCR of the picture: ... nic: nutex mrsas_sin_lock not ouned at /usr/src/sys/kern/kern_nutex.c:284 ... b_trace_self_urapper () at db_trace_self_urapper+8x2b/frane BxfeB33c44a918 anic() at vpanic+Bx182/frane BxfeA33c44ad68 nic() at panic+Bx43/frame BxfeB33c44adcd _mtx_assert() at __mtx_assert+@xb@/frane Bxfed33c44a9dd callout_stop_safe() at _callout_stop_safe+Bx82/frane Bxfe33c44aac rsas_conplete_cnd() at mrsas_complete_cnd+8x1b8/frane BxfeB33c4daaed ithread_loop() at ithread_loop+@x279/frame BxfeB33c44ah78 This looks like a fallout from r342064. cm_callout is initialized like this: callout_init_mtx(&cmd->cm_callout, &sc->sim_lock, 0); but in mrsas_complete_cmd() it's stopped without holding the lock. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
