Re: if_ethersubr.c: if_ierrors -> if_iqdrops?
On 2021/11/24 3:41, Christos Zoulas wrote:
In article <87b00947-9e9a-f2c1-7c79-d3ba6e41a...@execsw.org>,
SAITOH Masanobu wrote:
Hi.
On 2021/11/11 17:32, RVP wrote:
On Wed, 10 Nov 2021, Ryota Ozaki wrote:
Another option may be if_noproto.
ozaki-r
On Wed, 10 Nov 2021, Havard Eidnes wrote:
which further supports the suggestion to use if_noproto for the
stated condition.
I'll use `if_noproto'. Should've done that from the start--missed
the forest for the trees, me.
I'm still seeing a few error packets after hitting this test:
894 if (etype <= ETHERMTU + sizeof(struct
ether_header)) {
`etype' here (len by this point) is 8.
In my home's network, some machines send 802.2 LLC packet that the
etype = 6. A few machines also send LLDP packets.
I wrote a patch for better counting:
Better counting for ierrors, iqdrops and noproto in ether_input().
- Use if_noproto for unknown or unsupported protocols.
- Use if_ierror for wrong mbuf and oversized frame.
LGTM.
christos
Committed!
--
-------
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
Re: if_ethersubr.c: if_ierrors -> if_iqdrops?
e change acceptable? Don't know if it is the TP-Link WiFi extender I'm cabled to that is sending these short frames or what. The alc driver isn't reporting any received error counts at any rate. Thanks, -RVP -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
to check timer availability in shutdown sequence
Hi.
In many places, the "cold" global variable is used to check whether
timer can be used or not. cpu_reboot(9) says:
-
DESCRIPTION
The cpu_reboot() function handles final system shutdown, and either halts
or reboots the system. The exact action to be taken is determined by the
flags passed in howto and by whether or not the system has finished
autoconfiguration.
If the system has finished autoconfiguration, cpu_reboot() does the
following:
1. Sets the boothowto system variable (see boothowto(9)) from the
howto argument.
2. If this is the first invocation of cpu_reboot() and the
RB_NOSYNC flag is not set in howto, syncs and unmounts the
system disks by calling vfs_shutdown(9) and sets the time of
day clock by calling resettodr(9).
3. Disables interrupts.
4. If rebooting after a crash (i.e., if RB_DUMP is set in howto,
but RB_HALT is not), saves a system crash dump.
5. Runs any shutdown hooks by calling pmf_system_shutdown(9).
6. Prints a message indicating that the system is about to be
halted or rebooted.
7. If RB_HALT is set in howto, halts the system. Otherwise,
reboots the system.
---
After disabling interrupt (by splhigh()), devices are detached.
Some drivers uses "cold" to check the availability of timer.
One of example is:
---
/* Delay for a certain number of ms */
void
usb_delay_ms_locked(struct usbd_bus *bus, u_int ms, kmutex_t *lock)
{
/* Wait at least two clock ticks so we know the time has passed. */
if (bus->ub_usepolling || cold)
delay((ms+1) * 1000);
else
kpause("usbdly", false, (ms*hz+999)/1000 + 1, lock);
}
---
Does it work on shutdown? I've also noticed that some code also checks
shutting_down:
---
static inline int
iic_op_flags(int flags)
{
return flags | ((cold || shutting_down) ? I2C_F_POLL : 0);
}
---
The shutting_down variable is new and many drivers don't use it yet.
Should we replace
if (cold)
to
if (cold || shutting_down)
Or any other solutions? (e.g setting cold = 1 after splhigh()).
Thanks.
--
-------
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
Re: kpause()'s timeout value
On 2020/06/19 3:17, SAITOH Masanobu wrote:
Hi.
I'm now working to reduce ixgbe's busy loop using with kpause()[*1].
I wrote the following code:
#define usec_delay(x) ixgbe_delay(x)
#define msec_delay(x) ixgbe_delay((x) * 1000)
void
ixgbe_delay(unsigned int us)
{
if (__predict_false(cold))
delay(us);
else if ((us / 1000) >= hztoms(1))
kpause("ixgdly", false, mstohz(us / 1000), NULL);
else
delay(us);
}
Does kpause(x, y, 1, z) guarantee to wait at least 1 tick length
of time? Or, does it wakeup the next tick? Should I add extra 1 tick
to kpause()?
I wrote the following code to see the real delay:
void
ixgbe_delay(unsigned int us)
{
#if 0
if (__predict_false(cold))
delay(us);
else if ((us / 1000) >= hztoms(1))
kpause("ixgdly", false, mstohz(us / 1000), NULL);
else
delay(us);
#else
if (__predict_false(cold))
delay(us);
else if ((us / 1000) >= hztoms(1)) {
struct timeval t0, t1, res;
microtime(&t0);
kpause("ixgdly", false, mstohz(us / 1000), NULL);
microtime(&t1);
timersub(&t1, &t0, &res);
if (res.tv_usec < us)
printf("%d<%d\n", res.tv_usec, us);
} else
delay(us);
#endif
}
and the output was:
285<1
7664<1
7576<1
7593<1
7075<1
7071<1
7111<1
7622<1
7601<1
7597<1
7595<1
7601<1
7584<1
7596<1
7576<1
7077<1
7084<1
7099<1
7600<1
7616<1
7585<1
7566<1
8075<1
7118<1
7573<1
7547<1
7107<1
7052<1
7103<1
7585<1
7548<1
7616<1
7597<1
7566<1
7588<1
7621<1
7573<1
7066<1
7098<1
145432<15
195283<20
140772<15
47368<5
47407<5
46049<5
9712<1
9724<1
9742<1
And then I modified the code to add extra 1 tick:
-kpause("ixgdly", false, mstohz(us / 1000), NULL);
+kpause("ixgdly", false, mstohz(us / 1000) + 1, NULL);
The debug output disappeared. The result says the extra 1 tick is required.
There are some code that kpause() is used with mstohz(). It would be good
to check whether those code do correctly or not (If my analysis is correct...).
(The following list was made by just grepped with kpause and mstohz)
./arch/arm/omap/ti_iic.c: kpause("tiiic", false,
mstohz(50), NULL);
./arch/arm/sunxi/sunxi_hdmi.c: kpause("hdmiddc", false, mstohz(10),
&sc->sc_exec_lock);
./arch/arm/sunxi/sunxi_hdmi.c: kpause("hdmihotplug", false,
mstohz(1000), NULL);
./arch/arm/ti/ti_iic.c: kpause("tiiic", false, mstohz(50),
NULL);
./arch/macppc/dev/smu.c:kpause("fanctrl", true, mstohz(3),
NULL);
./arch/x86/x86/intr.c: (void)kpause("intrdist", false, mstohz(10), NULL);
./arch/x86/x86/pmap.c: kpause("gntmap", false, mstohz(1), NULL);
./arch/xen/xen/privcmd.c: if (kpause("xnoent", 1,
mstohz(100), NULL))
./dev/fdt/fdt_panel.c: kpause("panele", false, mstohz(200), NULL);
./dev/fdt/fdt_panel.c: kpause("panelp", false, mstohz(210), NULL);
./dev/i2c/fcu.c:kpause("fanctrl", true, mstohz(sc->sc_pwm ?
1000 : 5000), NULL);
./dev/i2c/tsl256x.c:(void) kpause("tslluxwait", false, mstohz(ms) +
1, NULL);
./dev/ic/dwc_mmc.c: kpause("dwcmmcrst", false, uimax(mstohz(1),
1), &sc->sc_lock);
./dev/onewire/owtemp.c: (void)kpause("owtemp", false, mstohz(750 + 10), NULL);
./dev/pci/cxdtv.c: kpause("cxdtvrst", false, MAX(1, mstohz(1)), NULL);
./dev/pci/pccbb.c: kpause("pccbb", false, mstohz(millis), NULL);
./dev/pci/pccbb.c: kpause(wmesg, false, uimax(mstohz(timo), 1), NULL);
./external/bsd/drm2/include/linux/delay.h:
(void)kpause("lnxmslep", false, mstohz(msec), NULL);
./external/bsd/dwc2/dwc2.h: (void)kpause("mdelay", false,
mstohz(msec), NULL);
./external/bsd/ena-com/ena_plat.h: return kpause("enaw", false,
mstohz(x), NULL);
./kern/kern_tc.c: (void)kpause("tcdetach", false, mstohz(10),
NULL);
./ufs/chfs/chfs_gc.c: kpause("chfsthjoin", false, mstohz(1000), NULL);
./ufs/chfs/chfs_gc.c: kpause("chvncrea", true, mstohz(50),
NULL);
./ufs/chfs/chfs_gc.c:
kpause()'s timeout value
Hi.
I'm now working to reduce ixgbe's busy loop using with kpause()[*1].
I wrote the following code:
#define usec_delay(x) ixgbe_delay(x)
#define msec_delay(x) ixgbe_delay((x) * 1000)
void
ixgbe_delay(unsigned int us)
{
if (__predict_false(cold))
delay(us);
else if ((us / 1000) >= hztoms(1))
kpause("ixgdly", false, mstohz(us / 1000), NULL);
else
delay(us);
}
Does kpause(x, y, 1, z) guarantee to wait at least 1 tick length
of time? Or, does it wakeup the next tick? Should I add extra 1 tick
to kpause()?
man 9 "tsleep" says:
timo If non-zero, the process will sleep for at most timo/hz
seconds. If this amount of time elapses and no wakeup(ident)
has occurred, and no signal (if PCATCH was set) was posted,
tsleep() will return EWOULDBLOCK.
it sleep "at most timeo/hz" seconds. So some code use it like:
tsleep(ident, priority, wmsg, 1 + 1);
to sleep AT LEAST 1 tick. Is this type of treatment required
on kpause()? man 9 kpause has no such note.
For example, usb_subr.c rev. 1.268's usb_delay_ms_locked() is as follows:
void
usb_delay_ms_locked(struct usbd_bus *bus, u_int ms, kmutex_t *lock)
{
/* Wait at least two clock ticks so we know the time has passed. */
if (bus->ub_usepolling || cold)
delay((ms+1) * 1000);
else
kpause("usbdly", false, (ms*hz+999)/1000 + 1, lock);
}
-
In the rev. 1.1. It was.
-
void
usbd_delay_ms(ms)
int ms;
{
/* Wait at least two clock ticks so we know the time has passed. */
if (usbd_use_polling)
delay((ms+1) * 1000);
else
tsleep(&ms, PRIBIO, "usbdly", (ms*hz+999)/1000 + 1);
}
-
If it's not required to add extra 1 tick on kpause(), usb_delay_ms_locked()
can be simplified.
[*1] http://www.netbsd.org/~msaitoh/ixgbe-sleep-20200618-0.dif
Thanks in advance.
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
Re: TSC improvement
Hi. On 2020/06/15 7:08, Andrew Doran wrote: On Thu, Jun 11, 2020 at 04:50:40AM +, Taylor R Campbell wrote: What's trickier is synchronizing per-CPU timecounters so that they all give a reasonably consistent view of absolute wall clock time -- and so it's not just one CPU that leads while the others play catchup every time they try to read the clock. (In other words, adding atomic catchup logic certainly does not obviate the need to synchronize per-CPU timecounters!) But neither synchronization nor global monotonicity is always necessary -- e.g., for rusage we really only need a local view of time since we're only measuring relative time durations spent on the current CPU anyway. This is what the timecounter(9) API per se expects of timecounters, and right now tsc (along with various other per-CPU cycle counters) fails to guarantee that. Howso, do you see a bug? I think it's okay. The TSC is only used for the timecounter where it's known that it's insensitive to core speed variations and is driven by PLL related to the bus clock. Fortunately that means most x86 systems, excepting a window of some years from roughly around the time of the Pentium 4 onwards. If tc_get_timecount goes backward by a little, e.g. because you queried it on cpu0 the first time and on cpu1 the second time, kern_tc.c will interpret that to mean that it has instead jumped forward by a lot -- nothing in the timecounter abstraction copes with a timecounter that goes backwards at all. I thought about it some more and I just don't think we have this problem on x86 anyway. The way I see it, with any counter if you make explicit comparisons on a global basis the counter could appear to go a tiny bit backwards due to timing differences in execution - unless you want to go to some lengths to work around that. I think all you can really expect is for the clock to not go backwards within a single thread of execution. By my understanding that's all the timecounter code expects and the TSC code on x86 makes sure of that. I changed tsc_get_timecount so it'll print a message out if it's ever observed. (There's also an issue where the `monotonic' clock goes backwards sometimes, as reported by sched_pstats. I'm not sure anyone has tracked down where that's coming from -- it seems unlikely to be related to cross-CPU tsc synchronization because lwp rtime should generally be computed from differences between samples on a single CPU at a time, but I don't know.) Hmm. There was a race condition with rusage and softints that I fixed about 6 months ago where proc0 had absurd times in ps/top but I have not seen the "clock has gone backwards" one in a long time. I wonder if it's related. Andrew I've committed my change now. Some notes: - sys/kern/kern_cctr.c was first based on x86's timecounter code. Some archs use the code. It might be possible to improve. - dtrace/amd64/dtrace_subr.c has it's own rdtsc code. I've not touched it. Please someone(TM) modify it if you want. Thanks. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
TSC improvement
Hi, all. I wrote a code to improve x86's TSC.x86/tsc.c rev. 1.67 reduced cache problem, but it still has room. I measured the effect of lfence, mfence, cpuid and rdtscp. The impact to TSC skew and/or drift is: AMD: mfence > rdtscp > cpuid > lfence-serialize > lfence = nomodify Intel: lfence > rdtscp > cpuid > nomodify So, mfence is the best on AMD and lfence is the best on Intel. If it has no SSE2, we can use cpuid. The logs of TSC calibration (from "dmesg -t |grep TSC") is at: http://www.netbsd.org/~msaitoh/tsc/tsc-20200605log.tgz Diff is at: http://www.netbsd.org/~msaitoh/tsc/tsc-20200609-0.dif In this diff, cpu_counter*(those functions are MI API) uses serializing. We can provide both cpu_counter() and cpu_counter_serializing(). I think almost all usecases requires serializing on x86. For RNG, serializing is not required but the overhead is trivial. I think users who use cpu_counter() use the function to get time difference precisely. The serializing is required to get precised value, so I think just adding it to x86's cpu_counter() is enough. If it's acceptable, I'd like to commit this change. Any comments/advice are welcomed. NOTE: - An AMD's document says DE_CFG_LFENCE_SERIALIZE bit can be used for serializing, but it's not so good. - On Intel i386(not amd64), it seems the improvement is very little. - rdtscp instruct can be used as serializing instruction + rdtsc, but it's not good as [lm]fence. Both Intel and AMD's document say that the latency of rdtscp is bigger than rdtsc, so I suspect the difference of the result comes from it. And, thanks ad@, knakahara@, nonaka@ and some other people to help this work. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: UEFI boot and PCI interrupt routing (amd64)
On 2020/06/04 8:23, Jaromír Doleček wrote:
Hi,
I'm working on a driver for some PCI device, I'm far enough to execute
operations which should trigger interrupt, but the interrupt handler
(registered via pci_intr_establish()) is not called. It looks like
there is some kind of interrupt routing problem, maybe.
Any hints on what could/should I check?
Unfortunately can't boot the machine in legacy mode, to check whether
it's due to mission initialisation by BIOS.
Is the device xHCI or not?
I have similar problem on my machine(s). Some of xHCI don't trigger
interrupt wheh MSI-X is used. If INTx is used, it works. I don't know
if the problem is caused from xHCI, ioapic or some others.
Jaromir
--
-------
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
Re: DVF_ATTACH_INPROGRESS
On 2018/11/29 17:36, Masanobu SAITOH wrote:
Hi.
While I've been working for suspend/resume, I've noticed that some devices
are reported "WARNING: power management not supported" in config_attach_loc()
even though the driver has pmf_device_register() in it. The reason is that
pmf_device_register is deferred by config_interrupts(). It's not a real bug,
but the above message is important for suspend/resume work. I wrote the
following patch:
Committed.
Thanks.
Index: sys/sys/device.h
===
RCS file: /cvsroot/src/sys/sys/device.h,v
retrieving revision 1.156
diff -u -p -r1.156 device.h
--- sys/sys/device.h 18 Sep 2018 01:25:09 - 1.156
+++ sys/sys/device.h 29 Nov 2018 08:33:29 -
@@ -202,6 +202,7 @@ struct device {
#define DVF_CLASS_SUSPENDED 0x0008 /* device class suspend was
called */
#define DVF_DRIVER_SUSPENDED 0x0010 /* device driver suspend was
called */
#define DVF_BUS_SUSPENDED 0x0020 /* device bus suspend was called */
+#define DVF_ATTACH_INPROGRESS 0x0040 /* device attach is in progress
*/
#define DVF_DETACH_SHUTDOWN 0x0080 /* device detaches safely at
shutdown */
#ifdef _KERNEL
Index: sys/kern/subr_autoconf.c
===
RCS file: /cvsroot/src/sys/kern/subr_autoconf.c,v
retrieving revision 1.263
diff -u -p -r1.263 subr_autoconf.c
--- sys/kern/subr_autoconf.c 18 Sep 2018 01:25:09 - 1.263
+++ sys/kern/subr_autoconf.c 29 Nov 2018 08:33:30 -
@@ -446,6 +446,10 @@ config_interrupts_thread(void *cookie)
while ((dc = TAILQ_FIRST(&interrupt_config_queue)) != NULL) {
TAILQ_REMOVE(&interrupt_config_queue, dc, dc_queue);
(*dc->dc_func)(dc->dc_dev);
+ dc->dc_dev->dv_flags &= ~DVF_ATTACH_INPROGRESS;
+ if (!device_pmf_is_registered(dc->dc_dev))
+ aprint_debug_dev(dc->dc_dev,
+ "WARNING: power management not supported\n");
config_pending_decr(dc->dc_dev);
kmem_free(dc, sizeof(*dc));
}
@@ -1597,9 +1601,10 @@ config_attach_loc(device_t parent, cfdat
(*dev->dv_cfattach->ca_attach)(parent, dev, aux);
- if (!device_pmf_is_registered(dev))
- aprint_debug_dev(dev, "WARNING: power management not "
- "supported\n");
+ if (((dev->dv_flags & DVF_ATTACH_INPROGRESS) == 0)
+ && !device_pmf_is_registered(dev))
+ aprint_debug_dev(dev,
+ "WARNING: power management not supported\n");
config_process_deferred(&deferred_config_queue, dev);
@@ -1996,6 +2001,7 @@ config_interrupts(device_t dev, void (*f
dc->dc_func = func;
TAILQ_INSERT_TAIL(&interrupt_config_queue, dc, dc_queue);
config_pending_incr(dev);
+ dev->dv_flags |= DVF_ATTACH_INPROGRESS;
}
/*
Index: sys/external/bsd/drm2/i915drm/intelfb.c
===
RCS file: /cvsroot/src/sys/external/bsd/drm2/i915drm/intelfb.c,v
retrieving revision 1.15
diff -u -p -r1.15 intelfb.c
--- sys/external/bsd/drm2/i915drm/intelfb.c 27 Aug 2018 15:09:35 -
1.15
+++ sys/external/bsd/drm2/i915drm/intelfb.c 29 Nov 2018 08:33:30 -
@@ -119,6 +119,7 @@ intelfb_attach(device_t parent, device_t
error);
goto fail1;
}
+ self->dv_flags |= DVF_ATTACH_INPROGRESS;
sc->sc_scheduled = true;
/* Success! */
@@ -177,6 +178,7 @@ intelfb_attach_task(struct i915drmkms_ta
};
int error;
+ sc->sc_dev->dv_flags &= ~DVF_ATTACH_INPROGRESS;
error = drmfb_attach(&sc->sc_drmfb, &da);
if (error) {
aprint_error_dev(sc->sc_dev, "failed to attach drmfb: %d\n",
(intelfb.c doesn't use config_interrupts)
OK?
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
EuroBSDCon 2015 DevSummit presentation material (IIJ)
Hi, all. I put my presentation material at: http://www.netbsd.org/~msaitoh/EuroBSDCon2015-devsummit-IIJ-20151002-0.pdf Advice, opinion and discussion are welcome. Thanks in advance. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: Tester(s) needed: ixv(4)
On 2015/08/13 22:21, Bert Kiers wrote: > On Thu, Aug 13, 2015 at 07:19:15PM +0900, Masanobu SAITOH wrote: > >> NetBSD's ixv(4) can be test with Linux KVM or VMware vSphere. >> Some people other than me must be familar with them :) > > Ah! We have Linux boxes running KVM with network hardware: > 02:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit > X540-AT2 (rev 01) > > But inside a VM the network shows as: > 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device It's vioif(4). > I doubt that will be ixv when I boot NetBSD. I guess there is some form > of bridging going on because there are a lot of vnet interfaces in the > host. I think I need a different method of networking for ixv. Will > have a look this weekend. To use ixv, 0) Add intel_iommu=on pci=assignbus to your kernel's boot argument 1) Use "max_vfs=n" (e.g. n=8) when probing ixgbe (e.g. add "options ixgbe max_vfs=8" into /etc/modprobe.d/ixgbe.conf) 2) modprobe -r ixgbe; modprove ixgbe 4) lspci. You will see some virtual functions. The number of virtual function is the same as the number of max_vfs > 01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) > 02:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 5) Add passthrough setting of a virtual function. (You might want to add "blacklist ixgbevf" in /etc/modprobe.d/blacklist.conf) 6) You might have to add some other variable settings to your kernel's boot argument. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: Tester(s) needed: ixv(4)
On 2015/08/13 21:14, Thor Lancelot Simon wrote: > On Thu, Aug 13, 2015 at 07:19:15PM +0900, Masanobu SAITOH wrote: >> >> It's required to use MSI/MSI-X function and SR-IOV. Currently, >> x86 except XEN support MSI/MSI-X function. And, to control SR-IOV, >> it's required to access the PCIe's extended configuration area. >> It's not supported in NetBSD yet (though nonaka@ is working on it). >> So, we can't use ixv(4) via NetBSD/xen DOM0 :-| >> Amazon EC2's C3 and C4 instance support ixv(ixgbevf in linux), but >> it can't be used because NetBSD/xen doesn't support MSI/MSI-X. >> >> NetBSD's ixv(4) can be test with Linux KVM or VMware vSphere. >> Some people other than me must be familar with them :) > > The most likely candidate platform would seem to be Google Cloud: > it's KVM based and last I heard Google was offering "dedicated" network > interfaces a.k.a. ixv. > > Unfortunately to run on Google Cloud we would need a working vioscsi > driver. I have a roughly half-complete port of the OpenBSD version > on my laptop but I've never found the time to finish it. > > Is it possible to use the virtual functions as multiple network > adapters under a single NetBSD kernel for testing? The physical port is shared with VFs. It's ok for testing. Accessing SR-IOV's extend capability is required to create VFs. It' not possible in -current now, but it will be possible when nonaka@'s patch is merged. > Thor > -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: if_wm between netbsd-6 and netbsd-7 issue
> pci1 at ppb0 bus 1 > pci1: i/o space, memory space enabled, rd/line, wr/inv ok > ppb1 at pci1 dev 0 function 0: vendor 111d product 8018 (rev. 0x0e) > ppb1: PCI Express capability version 1 > pci2 at ppb1 bus 2 > pci2: i/o space, memory space enabled, rd/line, wr/inv ok > ppb2 at pci2 dev 2 function 0: vendor 111d product 8018 (rev. 0x0e) > ppb2: PCI Express capability version 1 x4 @ > 2.5GT/s > pci3 at ppb2 bus 3 > pci3: i/o space, memory space enabled, rd/line, wr/inv ok > wm0 at pci3 dev 0 function 0: Intel PRO/1000 PT Quad Port Server Adapter > (rev. 0x06) > wm0: interrupting at ioapic0 pin 19 > wm0: PCI-Express bus > wm0: 4096 words (16 address bits) SPI EEPROM > wm0: Ethernet address 00:18:fe:2e:d6:85 > igphy0 at wm0 phy 1: Intel IGP01E1000 Gigabit PHY, rev. 0 > igphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > wm1 at pci3 dev 0 function 1: Intel PRO/1000 PT Quad Port Server Adapter > (rev. 0x06) > wm1: interrupting at ioapic0 pin 18 > wm1: PCI-Express bus > wm1: 4096 words (16 address bits) SPI EEPROM > wm1: Ethernet address 00:18:fe:2e:d6:84 > igphy1 at wm1 phy 1: Intel IGP01E1000 Gigabit PHY, rev. 0 > igphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > ppb3 at pci2 dev 4 function 0: vendor 111d product 8018 (rev. 0x0e) > ppb3: PCI Express capability version 1 x4 @ > 2.5GT/s > pci4 at ppb3 bus 4 > pci4: i/o space, memory space enabled, rd/line, wr/inv ok > wm2 at pci4 dev 0 function 0: Intel PRO/1000 PT Quad Port Server Adapter > (rev. 0x06) > wm2: interrupting at ioapic0 pin 17 > wm2: PCI-Express bus > wm2: 4096 words (16 address bits) SPI EEPROM > wm2: Ethernet address 00:18:fe:2e:d6:87 > igphy2 at wm2 phy 1: Intel IGP01E1000 Gigabit PHY, rev. 0 > igphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > wm3 at pci4 dev 0 function 1: Intel PRO/1000 PT Quad Port Server Adapter > (rev. 0x06) > wm3: interrupting at ioapic0 pin 16 > wm3: PCI-Express bus > wm3: 4096 words (16 address bits) SPI EEPROM > wm3: Ethernet address 00:18:fe:2e:d6:86 > igphy3 at wm3 phy 1: Intel IGP01E1000 Gigabit PHY, rev. 0 > igphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto wm(4) has some debug code: > #ifdef WM_DEBUG > #define WM_DEBUG_LINK 0x01 > #define WM_DEBUG_TX 0x02 > #define WM_DEBUG_RX 0x04 > #define WM_DEBUG_GMII 0x08 > #define WM_DEBUG_MANAGE 0x10 > #define WM_DEBUG_NVM0x20 > int wm_debug = WM_DEBUG_TX | WM_DEBUG_RX | WM_DEBUG_LINK | WM_DEBUG_GMII > | WM_DEBUG_MANAGE | WM_DEBUG_NVM; Could you define WM_DEBUG and set WM_DEBUG_NVM only in wm_debug, and then show me the full dmesg? Regards. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: 4byte aligned com(4) and PCI_MAPREG_TYPE_MEM
t. >> --- dev/pci/puccn.c 26 Jan 2014 10:54:24 - 1.13 >> +++ dev/pci/puccn.c 9 Feb 2014 17:43:24 - > : >> @@ -86,8 +87,9 @@ static bus_addr_t pucgdbbase; >> * resuming the search where it left off, never retrying the same adaptor. >> */ >> >> +#include > > I doubt we can pull this MD header in MI driver. Sorry. It was a part of test code with LED blink code using with inl(), outl() because it's reuired to debug serial console function on Intel Galileo (it has no VGA video). I'll remove it. >> +COM_INIT_REGS(sc->sc_regs, iot, ioh, iobase, sizeof(uint8_t)); > > I wonder which is better explicit "1" or sizeof(uint8_t) > if this means stride. When the first time I made that patch it was "1" and "4". And when I saw the code: COM_INIT_REGS(sc->sc_regs, iot, ioh, iobase, 1); I thought that someone should think "What is 1 mean? Number or flag?", so I rewrite to use sizeof() to make clear it's not a flag. I'd like to know other people's thought. > (you use "1" and "4" in com_puc.c) inconsistent. >> --- arch/hp300/dev/com_dio.c28 Apr 2008 20:23:19 - 1.8 >> +++ arch/hp300/dev/com_dio.c9 Feb 2014 17:43:21 - > > At least arch/hp300/dev/com_frodo.c was missed? Right. My falut. I'll add in the next patch. > --- > Izumi Tsutsui > -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org) * 英語 - 自動検出 * 英語 * 日本語 * 英語 * 日本語 <#>
Re: 4byte aligned com(4) and PCI_MAPREG_TYPE_MEM
Hi, Christos. (2014/02/10 5:26), Christos Zoulas wrote: > In article <52f7c96e.6000...@execsw.org>, > SAITOH Masanobu wrote: >> Hello, all. >> >> I'm now working to support Intel Quark X1000. >> This chip's internal com is MMIO(PCI_MAPREG_TYPE_MEM). >> Our com and puc don't support such type of device, yet. >> To solve the problem, I wrote a patch. >> >> Registers of Quark X1000's com are 4byte aligned. >> Some other machines have such type of device, so >> I modified COM_INIT_REGS() macro to support both >> byte aligned and 4byte aligned. This change reduce >> special modifications done in atheros, rmi and >> marvell drivers. >> >> One of problem is serial console on i386 and amd64. >> These archs calls consinit() three times. The function >> is called in the following order: >> >> 1) machdep.c::init386() or init_x86_64() >> 2) init_main.c::main() >> *) (call uvm_init()) >> *) (call extent_init()) >> 3) machdep.c::cpu_startup() >> >> When consinit() called in init386(), it calls >> >> comcnattach() >>->comcnattach1() >> ->comcninit() >>-> bus_space_map() with x86_bus_space_mem tag. >> ->bus_space_reservation_map() >>->x86_mem_add_mapping() >> ->uvm_km_alloc() >>panic in KASSERT(vm_map_pmap(map) == pmap_kernel()); >> >> What should I do? >> One of the solution is to check whether extent_init() was called >> or not. There is no easy way to know it, so I added a global >> variable "extent_initted". Is it acceptable? > > Looks great, can't you use "cold" instead, or is that too late? No, we can't. That's too late. The variable is set in configure2(). > christos > -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
puccn improvement
ber.c com_puc
file dev/pci/puccn.c com_puc
Index: sys/dev/pci/puccn.c
===
RCS file: /cvsroot/src/sys/dev/pci/puccn.c,v
retrieving revision 1.12
diff -u -r1.12 puccn.c
--- sys/dev/pci/puccn.c 23 Jan 2014 17:43:28 - 1.12
+++ sys/dev/pci/puccn.c 23 Jan 2014 18:56:23 -
@@ -75,6 +75,7 @@
static bus_addr_t puccnbase;
static bus_space_tag_t puctag;
+static int puccnflags;
#ifdef KGDB
static bus_addr_t pucgdbbase;
@@ -99,11 +100,10 @@
/* Fetch our tags */
#if defined(amd64) || defined(i386)
- if (cpu_comcnprobe(cn, &pa) != 0)
+ if (cpu_puc_cnprobe(cn, &pa) != 0)
#endif
return 0;
- puctag = pa.pa_iot;
pci_decompose_tag(pa.pa_pc, pa.pa_tag, &bus, &maxdev, NULL);
/* Scan through devices and find a communication class device. */
@@ -145,6 +145,8 @@
*/
if (!foundport)
return 0;
+
+ /* Clear foundport flag */
foundport = 0;
/* Check whether the device is in the puc device table or not */
@@ -166,12 +168,21 @@
{
if (desc->ports[i].type != PUC_PORT_TYPE_COM)
continue;
+ puccnflags = desc->ports[i].flags;
base = pci_conf_read(pa.pa_pc, pa.pa_tag, desc->ports[i].bar);
base += desc->ports[i].offset;
- if (PCI_MAPREG_TYPE(base) != PCI_MAPREG_TYPE_IO)
- continue;
- base = PCI_MAPREG_IO_ADDR(base);
+ if (PCI_MAPREG_TYPE(base) == PCI_MAPREG_TYPE_IO) {
+ puctag = pa.pa_iot;
+ base = PCI_MAPREG_IO_ADDR(base);
+ }
+#if 0 /* For MMIO device */
+ else {
+ puctag = pa.pa_memt;
+ base = PCI_MAPREG_MEM_ADDR(base);
+ }
+#endif
+
if (com_is_console(puctag, base, NULL))
continue;
foundport = 1;
@@ -183,8 +194,13 @@
goto resume_scan;
}
+#if 0
cn->cn_pri = CN_REMOTE;
- return PCI_MAPREG_IO_ADDR(base);
+#else
+ if (cn)
+ cn->cn_pri = CN_REMOTE;
+#endif
+ return base;
}
#ifdef KGDB
@@ -211,19 +227,21 @@
#endif
void
-comcnprobe(struct consdev *cn)
+puc_cnprobe(struct consdev *cn)
{
puccnbase = pucprobe_doit(cn);
}
-void
-comcninit(struct consdev *cn)
+int
+puc_cninit(struct consdev *cn)
{
+
if (puccnbase == 0)
- return;
+ return -1;
- comcnattach(puctag, puccnbase, CONSPEED, COM_FREQ, COM_TYPE_NORMAL,
+ return comcnattach(puctag, puccnbase, CONSPEED,
+ puccnflags & PUC_COM_CLOCKMASK, COM_TYPE_NORMAL,
CONMODE);
}
Index: sys/dev/pci/puccn.h
===
RCS file: /cvsroot/src/sys/dev/pci/puccn.h,v
retrieving revision 1.5
diff -u -r1.5 puccn.h
--- sys/dev/pci/puccn.h 22 Jul 2013 13:40:36 - 1.5
+++ sys/dev/pci/puccn.h 23 Jan 2014 18:56:23 -
@@ -35,6 +35,7 @@
*/
#include
+#include
/*
* Machine independent support for PCI serial console support.
@@ -44,4 +45,6 @@
* used before the normal PCI bus initialization.
*/
-int cpu_comcnprobe(struct consdev *, struct pci_attach_args *);
+void puc_cnprobe(struct consdev *);
+int puc_cninit(struct consdev *);
+int cpu_puc_cnprobe(struct consdev *, struct pci_attach_args *);
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
Re: broadcom 57766 and jumbo frames
(2013/07/03 21:23), Emmanuel Dreyfus wrote:
> On Wed, Jul 03, 2013 at 06:12:49PM +0900, Masanobu SAITOH wrote:
>> Could you try this patch? I'll check the entire code in bge.c again.
>
> It seems the card cannot transmit anything, whatever the MTU is.
>
mmm... Thanks.
It's time for me to buy iMac... ;-)
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
Re: Another MII PHY fix.
Hi. (2013/06/09 18:43), Mouse wrote: > I don't know this stuff in enough detail to vet the code more than > trivially. But I do notice one minor issue and one possible issue: > >>> /* >>> +* mii_tick == 0 means it's the first tick after changing the media or >>> +* the link became down since the last tick (see above), so return with >>> +* 0 to update the status. >>> +*/ >>> + if (sc->mii_ticks == 0) >>> + return (0); >>> + >>> + /* Now increment the tick */ >>> + sc->mii_ticks++; > > (a) The comment says mii_tick but the code says mii_ticks. I'll fix it. > (b) If mii_ticks is zero, it remains zero, so unless something else > changes it, it will stay stuck at zero. You're correct. The FreeBSD's original change was if (sc->mii_tick++ == 0) so I'll fix to be the same with FreeBSD. Thanks! > /~\ The ASCII Mouse > \ / Ribbon Campaign > X Against HTML mo...@rodents-montreal.org > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: Another MII PHY fix.
(2013/06/06 15:48), Masanobu SAITOH wrote:
>
> Hi, all.
>
> Without following patch. Some drivers which don't use link
> interrput check the link status only every sc->mii_anegticks.
> It's late. The patch is a part of FreeBSD's mii_physubr.c r158649:
>
>
> http://svnweb.freebsd.org/base/head/sys/dev/mii/mii_physubr.c?r1=150756&r2=158649
>
> Any objection to commit?
>
> Index: mii_physubr.c
> ===
> RCS file: /cvsroot/src/sys/dev/mii/mii_physubr.c,v
> retrieving revision 1.76
> diff -u -r1.76 mii_physubr.c
> --- mii_physubr.c 6 Jun 2013 03:10:48 - 1.76
> +++ mii_physubr.c 6 Jun 2013 06:07:47 -
> @@ -324,23 +324,43 @@
> /*
>* If we're not doing autonegotiation, we don't need to do
>* any extra work here. However, we need to check the link
> - * status so we can generate an announcement if the status
> - * changes.
> + * status so we can generate an announcement by returning
> + * with 0 if the status changes.
>*/
> if ((IFM_SUBTYPE(ife->ifm_media) != IFM_AUTO) &&
> - (IFM_SUBTYPE(ife->ifm_media) != IFM_1000_T))
> + (IFM_SUBTYPE(ife->ifm_media) != IFM_1000_T)) {
> + /*
> + * Reset autonegotiation timer to 0 to make sure
> + * the future autonegotiation start with 0.
> + */
> + sc->mii_tick = 0;
> return (0);
> + }
>
> /* Read the status register twice; BMSR_LINK is latch-low. */
> reg = PHY_READ(sc, MII_BMSR) | PHY_READ(sc, MII_BMSR);
> if (reg & BMSR_LINK) {
> /*
> - * See above.
> + * Reset autonegotiation timer to 0 in case the link is down
> + * in the next tick.
>*/
> + sc->mii_tick = 0;
> + /* See above. */
> return (0);
> }
>
> /*
> + * mii_tick == 0 means it's the first tick after changing the media or
> + * the link became down since the last tick (see above), so return with
> + * 0 to update the status.
> + */
> + if (sc->mii_ticks == 0)
> + return (0);
> +
> + /* Now increment the tick */
> + sc->mii_ticks++;
> +
> + /*
> * Only retry autonegotiation every N seconds.
>*/
> KASSERT(sc->mii_anegticks != 0);
Done.
Some MII PHY drivers have the same problem and have been fixed now.
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
Re: ETHERCAP_* & ioctl()
?
> ./dev/pci/if_ti.c: (sc->ethercom.ec_capenable & ETHERCAP_VLAN_MTU))
> ./dev/pci/if_ti.c: if (sc->ethercom.ec_capenable & ETHERCAP_VLAN_MTU)
> ./dev/pci/if_alc.c: if (sc->sc_ec.ec_capenable & ETHERCAP_VLAN_HWTAGGING)
> ./dev/pci/if_age.c: if (sc->sc_ec.ec_capenable & ETHERCAP_VLAN_HWTAGGING)
> ./dev/pci/if_ale.c: if (sc->sc_ec.ec_capenable & ETHERCAP_VLAN_HWTAGGING)
> ./dev/pci/ixgbe/ixgbe.c:ec->ec_capenable = ec->ec_capabilities;
> ./dev/pci/ixgbe/ixgbe.c:(ec->ec_capenable &
> ETHERCAP_VLAN_HWTAGGING) != 0 &&
> ./dev/pci/ixgbe/ixgbe.c:if (ec->ec_capenable &
> ETHERCAP_VLAN_HWFILTER) {
> ./dev/sbus/be.c:if (sc->sc_ethercom.ec_capenable & ETHERCAP_VLAN_MTU)
> ./net/agr/if_agr.c: ec_port->ec_capenable |= ETHERCAP_VLAN_MTU;
> ./net/agr/if_agr.c: ec_port->ec_capenable
> &=
> ./net/agr/if_agr.c: ec_port->ec_capenable &= ~ETHERCAP_VLAN_MTU;
> ./net/agr/if_agrether.c:ec_port->ec_capenable |=
> ETHERCAP_VLAN_MTU;
> ./net/agr/if_agrether.c:
> ec_port->ec_capenable &=
> ./net/agr/if_agrether.c:ec_port->ec_capenable &=
> ~ETHERCAP_VLAN_MTU;
> ./net/if_ethersubr.c: eccr->eccr_capenable = ec->ec_capenable;
> ./net/if_ether.h: int ec_capenable; /* tells
> hardware which
> ./net/if_vlan.c:ec->ec_capenable |= ETHERCAP_VLAN_MTU;
> ./net/if_vlan.c:
> ec->ec_capenable &=
> ./net/if_vlan.c:ec->ec_capenable |=
> ETHERCAP_VLAN_HWTAGGING;
> ./net/if_vlan.c:ec->ec_capenable &=
> ~ETHERCAP_VLAN_MTU;
Perhaps three (or more) types of people exist.
A) Both ec_capabilities and ec_capenable exist but we use ec_capabilities only.
The meaning of ec_capabilities is both the capabilities and the setting.
B) Only ec_capabililties exist.
C) Both ec_capabilities and ec_capenable exist and these are consistently used
like other
capability stuff.
I suspect the majority is A.
> I am curious whether these flags good for anything except diagnosing and
> working around driver bugs?
Currently, there is nothing other than diagnosing. There is no way to stop using
those functions because we have no SIOC*S*ETHERCAP.
> I ask because I don't think the operator
> can ordinarily make a better selection of hardware-capability flags than
> the OS can, except insofar as the OS has bugs and forces the user to
> work around them. BTW, I think that it is the same for the checksum
> offload / TSO flags as for the ethernet capability flags, but I guess
> that we're kind of stuck with the checksum/TSO flags by now.
>
> Dave
One of candidate to control ethernet function is (auto) MDI/MDIX, Some PHY have
bugs around the function. If a link partner has the bug, it's a good way to
control
it with ifconfig.
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
* 英語 - 自動検出
* 英語
* 日本語
* 英語
* 日本語
<#>
Re: Panic at init on arm (Seagate Dockstar) with -current
Hello, Andy. (2012/10/21 11:07), Andy Ruhl wrote: > On Sat, Oct 20, 2012 at 3:39 PM, Andy Ruhl wrote: >> uhub0 at usb0: Marvell EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 >> Fatal kernel mode prefetch abort at 0xfb44 >> trapframe: 0xc8a2bbf0, spsr=6073 >> r0 =, r1 =, r2 =c8a32f3f, r3 =60d3 >> r4 =c8a32f40, r5 =0020, r6 =00b1cf40, r7 =c04787f4 >> r8 =, r9 =c2347b0c, r10=0012, r11=c8a2bc6c >> r12=, ssp=c8a2bc44, slr=00114004, pc =fb44 >> >> Stopped in pid 0.5 (system) at fb44: address 0xfb44 is invalid >> andeq r0, r0, r10, lsr r0 >> db> bt >> netbsd:__aeabi_idiv+0x87768 >> scp=0xc03930d0 rlv=0x0006 (6) >> rsp=0xc0486474 rfp=0x > > I tried to reboot it and got some more output: > > db> reboot > syncing disks... Mutex error: mutex_vector_enter: locking against myself > > lock address : 0xc22cc090 type : spin > initialized : 0xc011bc90 > shared holds : 0 exclusive: 0 > shares wanted: 0 exclusive: 0 > current cpu : 0 last held: 0 > current lwp : 0xc2351540 last held: 00 > last locked : 0xc0130e68 unlocked*: 0xc0131098 > owner field : 0x00010600 wait/spin:0/1 > > panic: LOCKDEBUG > Stopped in pid 0.5 (system) at netbsd:cpu_Debugger+0x4:bx r14 > db> > > I'm going to try a few things in the kernel config and see what happens. > > Andy >> Hope this helps. Should I open a PR? >> >> Andy This problem was fixed by arm32/bus_space.c rev. 1.65 yesterday. And another bus_space.c's bug was fixed today by Nick. Could you try again? -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: Panic at init on arm (Seagate Dockstar) with -current
(2012/09/28 1:57), SAITOH Masanobu wrote: > Hi. > > (2012/09/27 2:59), Andy Ruhl wrote: >> Hello all, >> >> I posted this on port-arm a few weeks ago and I have someone helping >> me look at it, but I figured I would post again. >> >> My Seagate Dockstar has a panic with -current. The last time I built a >> good kernel was August 23rd. I noticed a lot of changes since then. >> >> Here is what I see: >> >> cprng sysctl: WARNING insufficient entropy at creation. >> boot device: >> root on sd0a dumps on sd0b >> WARNING: clock lost 4652 days >> WARNING: using filesystem time >> WARNING: CHECK AND RESET THE DATE! >> warning: no /dev/console >> init: copying out path `/sbin/init' 11 >> fixup: pm 0xc2f1d8a8, va 0xbfffe000, ftype 2 - nothing to do! >> fixup: l2 0xc22bcdc8, l2b 0xc22bce80, ptep 0xc22b8bf8, pl1pd 0xc04b2ffc >> fixup: pte 0x7790ffe, l1pd 0x7fc0831, last code 0x17 >> Stopped in pid 1.1 (init) atnetbsd:cpu_Debugger+0x4:bx r14 >> db> bt >> netbsd:pmap_fault_fixup+0x10 >> scp=0xc01b72f4 rlv=0xc006371c (netbsd:data_abort_handler+0x384) >> rsp=0xc8a3fde0 rfp=0xc8a3fe4c >> r10=0xbfffe000 r9=0x0002 >> r8=0x0017 r7=0xc8a3e000 r6=0x r5=0xc2f152c0 >> r4=0xc8a3fe50 >> netbsd:data_abort_handler+0x10 >> scp=0xc00633a8 rlv=0xc005532c (netbsd:address_exception_entry+0x50) >> rsp=0xc8a3fe50 rfp=0xc8a3ffac >> r10=0xc04c6e48 r9=0x >> r8=0x0001 r7=0x0013 r6=0x002f r5=0x >> r4=0xc03a2530 >> netbsd:start_init+0x10 >> scp=0xc00e5310 rlv=0xc0037254 (netbsd:lwp_trampoline+0x14) >> rsp=0xc8a3ffb0 rfp=0x >> r10=0xc04c6e48 r9=0x >> r8=0x0005 r7=0x0010 r6=0x r5=0xc2f152c0 >> r4=0xc00e5300 >> db> >> >> I can run some other commands if needed. I'm not very experienced with >> C or debuggers so I might need very basic instructions. >> >> Thanks. >> >> Andy > > I have the same problem. In my experience, just typing "c" continue > the processing since yesterday. The following commit is required to do > this: > >> Module Name: src >> Committed By:matt >> Date:Wed Sep 26 18:18:08 UTC 2012 >> >> Modified Files: >> src/sys/arch/arm/arm32: pmap.c >> >> Log Message: >> If we get a fault we shouldn't have, set pmap_needs_pte_sync and retry. >> >> >> To generate a diff of this commit: >> cvs rdiff -u -r1.237 -r1.238 src/sys/arch/arm/arm32/pmap.c >> >> Please note that diffs are not public domain; they are subject to the >> copyright notices on the relevant files. This problem was disappeard by arm/arm32/pmap.c rev. 1.240. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: Panic at init on arm (Seagate Dockstar) with -current
Hi. (2012/09/27 2:59), Andy Ruhl wrote: > Hello all, > > I posted this on port-arm a few weeks ago and I have someone helping > me look at it, but I figured I would post again. > > My Seagate Dockstar has a panic with -current. The last time I built a > good kernel was August 23rd. I noticed a lot of changes since then. > > Here is what I see: > > cprng sysctl: WARNING insufficient entropy at creation. > boot device: > root on sd0a dumps on sd0b > WARNING: clock lost 4652 days > WARNING: using filesystem time > WARNING: CHECK AND RESET THE DATE! > warning: no /dev/console > init: copying out path `/sbin/init' 11 > fixup: pm 0xc2f1d8a8, va 0xbfffe000, ftype 2 - nothing to do! > fixup: l2 0xc22bcdc8, l2b 0xc22bce80, ptep 0xc22b8bf8, pl1pd 0xc04b2ffc > fixup: pte 0x7790ffe, l1pd 0x7fc0831, last code 0x17 > Stopped in pid 1.1 (init) atnetbsd:cpu_Debugger+0x4:bx r14 > db> bt > netbsd:pmap_fault_fixup+0x10 > scp=0xc01b72f4 rlv=0xc006371c (netbsd:data_abort_handler+0x384) > rsp=0xc8a3fde0 rfp=0xc8a3fe4c > r10=0xbfffe000 r9=0x0002 > r8=0x0017 r7=0xc8a3e000 r6=0x r5=0xc2f152c0 > r4=0xc8a3fe50 > netbsd:data_abort_handler+0x10 > scp=0xc00633a8 rlv=0xc005532c (netbsd:address_exception_entry+0x50) > rsp=0xc8a3fe50 rfp=0xc8a3ffac > r10=0xc04c6e48 r9=0x > r8=0x0001 r7=0x0013 r6=0x002f r5=0x > r4=0xc03a2530 > netbsd:start_init+0x10 > scp=0xc00e5310 rlv=0xc0037254 (netbsd:lwp_trampoline+0x14) > rsp=0xc8a3ffb0 rfp=0x > r10=0xc04c6e48 r9=0x > r8=0x0005 r7=0x0010 r6=0x r5=0xc2f152c0 > r4=0xc00e5300 > db> > > I can run some other commands if needed. I'm not very experienced with > C or debuggers so I might need very basic instructions. > > Thanks. > > Andy I have the same problem. In my experience, just typing "c" continue the processing since yesterday. The following commit is required to do this: > Module Name: src > Committed By: matt > Date: Wed Sep 26 18:18:08 UTC 2012 > > Modified Files: > src/sys/arch/arm/arm32: pmap.c > > Log Message: > If we get a fault we shouldn't have, set pmap_needs_pte_sync and retry. > > > To generate a diff of this commit: > cvs rdiff -u -r1.237 -r1.238 src/sys/arch/arm/arm32/pmap.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
