Re: CVS commit: src/sys/dev/scsipi
Hi,
Today, I found my environment panic while rebooting. As bisecting, it
seems the cause is below commit.
On 2017/06/18 7:35, Michael van Elst wrote:
> Module Name: src
> Committed By: mlelstv
> Date: Sat Jun 17 22:35:50 UTC 2017
>
> Modified Files:
> src/sys/dev/scsipi: atapiconf.c cd.c scsi_base.c scsiconf.c
> scsipi_base.c sd.c ss.c st.c
>
> Log Message:
> The atapibus detach path did hold the channel mutex while calling into
> autoconf,
> which would trigger a panic when unplugging a USB ATAPI CDROM.
>
> Align detach code for scsibus and atapibus to fix this.
>
> Also avoid races when detaching devices by replacing callout_stop with
> callout_halt.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.90 -r1.91 src/sys/dev/scsipi/atapiconf.c
> cvs rdiff -u -r1.340 -r1.341 src/sys/dev/scsipi/cd.c
> cvs rdiff -u -r1.91 -r1.92 src/sys/dev/scsipi/scsi_base.c
> cvs rdiff -u -r1.279 -r1.280 src/sys/dev/scsipi/scsiconf.c
> cvs rdiff -u -r1.175 -r1.176 src/sys/dev/scsipi/scsipi_base.c
> cvs rdiff -u -r1.324 -r1.325 src/sys/dev/scsipi/sd.c
> cvs rdiff -u -r1.88 -r1.89 src/sys/dev/scsipi/ss.c
> cvs rdiff -u -r1.230 -r1.231 src/sys/dev/scsipi/st.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
The panic message is here.
// snip
Jun 19 22:48:28 syncing disks... done
config_detach: detached device scsibus0 has children sd0
Skipping crash dump on recursive panic
panic: config_detach
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 0x802249f5 cs 0x8 rflags 0x246 cr2
0x70c8884aa38f ilevel 0 rsp 0xe4011099cc80
curlwp 0xe4027de12140 pid 632.1 lowest kstack 0xe401109992c0
Stopped in pid 632.1 (reboot) atnetbsd:breakpoint+0x5: leave
db{2}> bt
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x140
snprintf() at netbsd:snprintf
config_detach() at netbsd:config_detach+0x218
config_detach_all() at netbsd:config_detach_all+0x97
cpu_reboot() at netbsd:cpu_reboot+0x173
sys_reboot() at netbsd:sys_reboot+0x75
syscall() at netbsd:syscall+0x1d8
--- syscall (number 208) ---
70c88843e5ba:
The addr2line of config_detach()+0x218 is here.
https://nxr.netbsd.org/xref/src/sys/kern/subr_autoconf.c#1728
My environment is amd64 which use sd0(USB Flash) as root filesystem.
Could someone have any solution?
Thanks,
--
//
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit
Kengo NAKAHARA
Re: CVS commit: src/usr.bin/make
On Sun, Jun 18, 2017 at 02:21:42PM -0400, Christos Zoulas wrote: > 1. What needs the intermediate representation, and how it can be used? For debuging makefiles. Martin
Re: CVS commit: src/usr.bin/make
On Jun 18, 7:01pm, jo...@bec.de (Joerg Sonnenberger) wrote:
-- Subject: Re: CVS commit: src/usr.bin/make
| On Sat, Jun 17, 2017 at 10:40:25PM -0400, Christos Zoulas wrote:
| > On Jun 18, 12:36am, jo...@bec.de (Joerg Sonnenberger) wrote:
| > -- Subject: Re: CVS commit: src/usr.bin/make
| >
| > | Please do not unilaterally change behavior. Especially if it has been
| > | discussed in the past. This is rude at best and not everyone shares your
| > | opinion.
| >
| > Please explain the use case (aside for looking at the internal
representation
| > of a variable). For example, if .OBJDIR, LIB, etc. ended up unexpanded, many
| > things would break. I just don't think it is useful to be the default, and
| > using -V '${var}' to get it to expand is counter-intuitive. Why should it
| > behave differently in the first place?
|
| They haven't been expanded for years, if ever. You have broken any user
| of the unexpanded variables already. ${var} is a pretty intuitive
| semantics for "show me this expression". It even works for complex
| expressions involving modifiers. Your change has increased the
| complexity of the argument format without providing any new value. It
| has broken compatibility. It was not discussed. I think those are more
| than enough reasons to ask for a revert.
This is not what I asked; I asked for a use case. The reason we have not
made this change sooner is because the majority of the variables produce
already expanded values. I don't think that it is reasonable for someone
in a Makefile to have to write:
foo!=${MAKE} -V '$${var}'
which is the common use case to get the expanded value. Again, what
is the use case? I don't buy the argument that this will break
compatibility since the majority of the variables produce the same
results. The users also expect the expanded value, not an intermediate
representation (which is again non portable since it can change
anytime; so we can't depend on its form to parse it). Bottom line:
please explain the use case (aside from debugging). I.e.
1. What needs the intermediate representation, and how it can be used?
2. When is the intermediate representation preferable?
christos
