Re: thousands of callout_cpu0
Christos Zoulas wrote: >>There must be more than a thousand of callout_cpu0 entries with a ticks >>value that looks like a pointer (4529516 == 0x451d6c), after only a few >>seconds of booting into single user. >> [...] > >I changed the ddb callout code so that it is usable from crash(8). >Is that the change that broke it? Can you revert kern_timeout.c and >see if that fixes it? Yes, confirmed. That's the problem! Going back to 1.48 fixes it! Regards, -- Frank Wille
thousands of callout_cpu0
Hi! While debugging a different problem I checked the callout list with ddb(4) on my Amiga and saw this: db> callout hardclock_ticks now: 825 ticks wheel arg func -26 -1/-256 0 pffasttimo 4529516 -1/-256 4520a0 callout_cpu0 4529521 -1/-256 4520a8 callout_cpu0 4529526 -1/-256 4520b0 callout_cpu0 4529531 -1/-256 4520b8 callout_cpu0 4529536 -1/-256 4520c0 callout_cpu0 4529541 -1/-256 4520c8 callout_cpu0 4529546 -1/-256 4520d0 callout_cpu0 4529551 -1/-256 4520d8 callout_cpu0 4529556 -1/-256 4520e0 callout_cpu0 4529561 -1/-256 4520e8 callout_cpu0 4529566 -1/-256 4520f0 callout_cpu0 4529571 -1/-256 4520f8 callout_cpu0 4529577 -1/-256 452100 callout_cpu0 4529582 -1/-256 452108 callout_cpu0 4529587 -1/-256 452110 callout_cpu0 ... 4534507 -1/-256 454088 callout_cpu0 791670873 -1/-256 454090 callout_cpu0 2002868682 -1/-256 2f30 ? There must be more than a thousand of callout_cpu0 entries with a ticks value that looks like a pointer (4529516 == 0x451d6c), after only a few seconds of booting into single user. The problem exists since at least 7.99.4 (7.0 is ok). I saw it on several architectures, like i386, ppc and m68k. Any idea what happened here? -- Frank Wille
Re: Removing ARCNET stuffs
On Thu, 28 May 2015 11:57:11 +0900 Ryota Ozaki wrote: > > As far as I can see Arcnet is only used by the Amiga bah(4) driver. > > Isn't it possible to keep it somehow, as an MP-safe network stack would > > be irrelevant for the Amiga platform? > > We could keep it with some pain, but we cannot keep it working if there is > really no user. (I'm not sure if it works or not even now.) Is it still > worthwhile? I will not insist in keeping it when there is pain to do so. And you may be right that there is no user, but this is valid for a lot of platforms and drivers. > Anyway I don't proceed this attempt ignoring your request. > I wish there were actual users though... Maybe we can wait for a few days to give more potential users the chance to read these messages on the port-amiga list? In the meantime I will talk with other Amiga users if anybody owns such a board. Probably is@ still got one, as he was working on the driver many years ago. When nothing happens and nobody is able to test it, we can remove the code. -- Frank Wille
Re: Removing ARCNET stuffs
On Wed, 27 May 2015 18:18:06 +0900 Ryota Ozaki wrote: > > What are the reasons behind removing working parts from the source tree > > anyway? Aren't there more important things to do? > > We're working on making the network stack MP-safe and runnable in > parallel. That requires an overhaul of the entire source tree. Ok. That might be important enough to sacrifice it, when there really is no other option. As far as I can see Arcnet is only used by the Amiga bah(4) driver. Isn't it possible to keep it somehow, as an MP-safe network stack would be irrelevant for the Amiga platform? -- Frank Wille
Re: Removing ARCNET stuffs
On Tue, 26 May 2015 16:20:09 +0900 Ryota Ozaki wrote: > The next sacrifice is ARCNET. It seems it hasn't been > used for long years (7 years or more): > http://mail-index.netbsd.org/source-changes/2015/05/22/msg066175.html > > So I'm trying to remove them but the target files are > much more than I had expected (see the bellow diffstat). > > Please stop me if you want to keep the files. I don't have an Arcnet board and I don't know anybody using it, but on the Amiga there are not many options for network cards. If somebody happens to own an Arcnet board he would be happy to use it. What are the reasons behind removing working parts from the source tree anyway? Aren't there more important things to do? -- Frank Wille
Re: re(4) MAC address
On Fri, 28 Dec 2012 23:33:01 +0900 Izumi Tsutsui wrote: > The attached patch make re(4) always use IDR register values > for its MAC address. > > We no longer have to link rtl81x9.c for eeprom read functions > and I'm not sure if we should make the old behavoir optional > or remove completely. I cannot imagine any case where it is needed. When an EEPROM is present, the IDR registers should be initialized with its MAC. Maybe somebody who owns an re(4) NIC with an EEPROM should confirm that. > But for now I think it's almost harmless so please commit > if it works on re(4) on your NAS boxes. Unfortunately, there is still a dependency with rtl81x9.c: rtl8169.o: In function `re_ioctl': rtl8169.c:(.text+0x680): undefined reference to `rtk_setmulti' rtl8169.o: In function `re_init': rtl8169.c:(.text+0x1bc4): undefined reference to `rtk_setmulti' As this is the only function needed from rtl81x9.c it probably makes sense to add rtk_setmulti() and the rtk_calchash macro to rtl8169.c. I tried that and it works fine with my NAS! New patch for rtl8169.c, including re_setmulti(), is attached. -- Frank Wille rtl8169.c.diff Description: Binary data
Re: re(4) MAC address
On Sun, 2 Dec 2012 07:41:56 +0900 Izumi Tsutsui wrote: > IIRC RTL8139 doc says the chip reads the values from EEPROM automatically. > We should follow what 8169 doc specifies, but I don't have 8169 docs. I checked the 8169 doc. In the EEPROM section there is the following description for EEPROM address 0xe - 0x13: "Ethernet ID: After auto-load command or hardware reset, the RTL8169 loads Ethernet ID to IDR0-IDR5 of the RTL8169's I/O registers." As that happens automatically after reset, I would suggest that re(4) should trust IDR0-IDR5 for the correct address, and not try to access the EEPROM itself - which might be missing. > Probably all NASes has the same values in EEPROM? > (i.e. no re's EEPROM write operations during manufacture) Your are right. The address read from EEPROM is the same on two different machines. Probably because it uses default values when the EEPROM is missing. -- Frank Wille
Re: re(4) MAC address
Izumi Tsutsui wrote: On 02.12.12 00:40:44 you wrote: >> I found out that NetBSD's re(4) driver is reading the MAC from EEPROM >> while PPCBoot and Linux are reading it from the chip's ID-registers >> (RTK_IDRn). >> >> What is correct? This is a Realtek 8169S: > > Probably it's defined by hardware vendors, not chip. > > The old RTL8139 (RTL8169 has compat mode) seems to read MAC address > from EEPROM and those values are stored into RTK_IDRn registers. Who writes it into the IDRn registers? The firmware? The driver? Or the chip itself? When the chip does that automatically, then re(4) should depend on RTK_IDRn and not on the EEPROM. > I guess some NAS vendors overwrite RTK_IDn registers by firmware > to avoid extra EEPROM configurations during production. You may be right. I found a modification in the PPCBoot source, which reads the environment variable "ethaddr" and copies it to RTK_IDRn. But the EEPROM seems to have a valid contents (only the last three bytes differ) and I wonder why it is not used. > We can change values per hardware by adding device properties > (prop_dictionary(3)) calls (like sys/dev/pci/if_wm.c etc). Yes. I added a mac-address property to sk(4) myself, some time ago. But re(4) doesn't support it yet. -- Frank Wille
re(4) MAC address
Hi, I was testing a NH-230/231 NAS (running sandpoint) and wondered why the PPCBoot firmware and the previously installed Linux used a different MAC address than NetBSD does. I found out that NetBSD's re(4) driver is reading the MAC from EEPROM while PPCBoot and Linux are reading it from the chip's ID-registers (RTK_IDRn). What is correct? This is a Realtek 8169S: # pcictl pci0 dump -d 15 PCI configuration registers: Common header: 0x00: 0x816910ec 0x02b00107 0x0210 0x8008 Vendor Name: Realtek Semiconductor (0x10ec) Device Name: 8169/8110 10/100/1000 Ethernet (0x8169) [...] Sorry for cross-posting, but I couldn't decide whether this belongs to tech-kern or tech-net. -- Frank Wille
Re: kmem change related trouble
Matt Thomas wrote: On 02.02.12 14:36:02 you wrote: >> kernel DSI read trap @ 0xa00011c8 by pool_cache_get_paddr+0x4c: >> srr1=0x9032 r1=0xa22b9aa0 cr=0x28284084 xer=0x02000 ctr=0x1642c >> dsisr=0x4000 > >> The backtrace: >> copyright >> kmem_intr_alloc >> exec_elf32_makecmds >> check_exec >> execve1 >> start_init, >> setfunc_trampoline > > is that with the latest exec_elf.c? I'd like to see if the location > changes with the latest one. That together with your latest patch (www.netbsd.org/~matt/uvm_km.txt) helps! I need some more testing, but most kernel functions seem normal again. Thanks. -- Frank Wille
Re: kmem change related trouble
On Thu, 2 Feb 2012 14:36:02 -0800 Matt Thomas wrote: > > kernel DSI read trap @ 0xa00011c8 by pool_cache_get_paddr+0x4c: > > srr1=0x9032 r1=0xa22b9aa0 cr=0x28284084 xer=0x02000 ctr=0x1642c > > dsisr=0x4000 > > > > The backtrace: > > copyright > > kmem_intr_alloc > > exec_elf32_makecmds > > check_exec > > execve1 > > start_init, > > setfunc_trampoline > > is that with the latest exec_elf.c? No. It was still 1.33. > I'd like to see if the location changes with the latest one. Ok. I will test an updated kernel this evening. -- Frank Wille
Re: kmem change related trouble
Lars Heidieker wrote: > I've just posted a patch ( http://www.netbsd.org/~para/fix.patch ) > - It moves uareas and buffer cache back to the kernel_map restoring > the previous behavior. Sizing the kmem_arena is changed accordingly > (Something I stepped on while checking evbmips on gxemul). > - Code to drain pools if the kmem_arena runs out of space. I tried your patch on sandpoint and ofppc. Unfortunately it doesn't change anything. Here are the last lines before the crash on ofppc (note that the warning "no /dev/console" is wrong): [...] boot device: wd0 root on wd0a dumps on wd0b root file system type: ffs warning: no /dev/console trap: kernel read DSI trap @ 0xa00011c8 by 0x3d6324 (DSISR 0x4000, err=14), lr 0x3d6310 Press a key to panic. panic: trap Entering ddb shows the crash happened in pool_cache_get_paddr(): kernel DSI read trap @ 0xa00011c8 by pool_cache_get_paddr+0x4c: srr1=0x9032 r1=0xa22b9aa0 cr=0x28284084 xer=0x02000 ctr=0x1642c dsisr=0x4000 The backtrace: copyright kmem_intr_alloc exec_elf32_makecmds check_exec execve1 start_init, setfunc_trampoline -- Frank Wille
Re: VT6410 IDE and WDC_NO_IDS
On Tue, 3 Jan 2012 13:12:36 +0100 Manuel Bouyer wrote: > > Now I would like to turn this option into a device property, so it > > can be enabled on demand. > > [...] > > I'm not sure a device property would work, unless you can force it > with a config option: I found the JMH330 connected to a CS5536 in > the fuloong, but you can connect a JMH330 to any PATA controller > (and there's no way to detect this at run time). Ok, I understand. I won't change that. I decided to take a different workaround for the VT6410 on sandpoint. Establishing an edge-triggered PCI interrupt seems to solve the problem for me. If anybody can test a VT6410 on a different platform, I would be interested in the results. -- Frank Wille
Re: VT6410 IDE and WDC_NO_IDS
On Tue, 27 Dec 2011 13:26:23 +1100 matthew green wrote: > > Now I would like to turn this option into a device property, so it > > can be enabled on demand. > > this sounds like a good idea to me. in general, we're wanting > to move away from compile-time to run-time decisions like this. We should probably consider to add a new flag for atac_cap in atac_softc instead of defining WDC_NO_IDS. This flag could then either be set depending on the controller type or requested by a device property. But, for my specific problem I have refrained from doing this modification now, because I found a better solution: on the MPC8241 I can configure the VT6410 PCI interrupt as edge-triggered. That cures the problem completely. It needs to be checked if other architectures have the same problem with the VT6410. -- Frank Wille
VT6410 IDE and WDC_NO_IDS
In my effort to add Iomega Storcenter G2 support to sandpoint I experimented with Takahiro Kambe's patch for the VIA VT6410 IDE RAID controller (not using the RAID part here): http://mail-index.netbsd.org/port-i386/2007/03/30/.html The VT6410 freezes the kernel with an interrupt storm during wdcprobe(). But after some time I found out that defining the option WDC_NO_IDS fixes that. As far as I understand the problem, we cannot enable interrupts during drive probing, because there is something wrong (with the chip or with our driver?). But I am not an IDE expert. I found no such hack in the Linux and FreeBSD sources, and not even in the Storcenter GPL patches, which Iomega released, so I see no other solution. Unfortunately there are (as usual) no datasheets for the VT6410 available either. So I tend to accept WDC_NO_IDS as a solution, but I don't like it as a config file option. In the GENERIC sandpoint config it would also enable this hack for all the other (innocent) IDE chips. Now I would like to turn this option into a device property, so it can be enabled on demand. AFAICS WDC_NO_IDS was introduced for evbmips/LOONGSON (workaround CS5536+JMH330), which I would have to change too. Would that be ok for everybody? Or is there a better solution? -- Frank Wille
Re: pci_mapreg_map() with disabled device
On Thu, 1 Dec 2011 13:06:33 + "Jonathan A. Kollasch" wrote: > On Thu, Dec 01, 2011 at 10:12:44AM +0100, Frank Wille wrote: > > Is there a reason why pci_mapreg_map() calls bus_space_map() for a > > memory or i/o space, even when all spaces have been disabled on the > > device? > > Not necessarily, on x86 it's not uncommon for the I/O or Memory enable > bit to be set wrong by the firmware, even sometimes when the firmware > has allocated resources to the BARs. Hmm.. that's bad. Maybe we could check additionally whether the BAR is 0? > > Wouldn't it be better to check whether a space is enabled in the > > device, before trying to map it? > > You mean we don't anymore? I thought that didn't change. There is no such check in pci_mapreg_map(). -- Frank Wille
pci_mapreg_map() with disabled device
Hi! Is there a reason why pci_mapreg_map() calls bus_space_map() for a memory or i/o space, even when all spaces have been disabled on the device? Yesterday I had a case where an ohci(4) device had no PCI_COMMAND_IO_ENABLE and no PCI_COMMAND_MEM_ENABLE bit set in the PCI_COMMAND_STATUS_REG. Nevertheless pci_mapreg_map() tried to map an illegal address space, which resulted in a panic, when running a kernel with DEBUG option: ohci0 at pci1 dev 25 function 0: Apple Computer Intrepid USB Controller (rev. 0x00) extent_alloc_region: extent 'uninorth mem-space' (0x8000 - 0xf3ff) extent_alloc_region: start 0x0, end 0xfff panic: extent_alloc_region: region lies outside extent Wouldn't it be better to check whether a space is enabled in the device, before trying to map it? -- Frank Wille
Re: 32-bit partition offset/size in disklabel
On Wed, 30 Nov 2011 11:56:26 +0100 Martin Husemann wrote: > On Wed, Nov 30, 2011 at 11:49:46AM +0100, Frank Wille wrote: > > Hmm... that means I would have to make a small boot/root partition, > > which uses dkctl(8) to make the rest of the disk available? > > Depends on what your firmware can boot. All new x86 machines can boot > from GPT. I'm thinking about my PowerMacs and Amigas. ;) > > And what about other partition formats, like Apple Partition Maps, > > Amiga RDB, SGI, Sparc...? Is it planned to add support for them? > > You mean as on-disk representations for the wedge autocnfiguration > code? There is an on-disk representation of the wedge? I just had a look into sys/dev/dkwedge and was under the impression that a dk(4) device is constructed on the fly from the information read from GPT (or MBR) partitions. > I'm not sure that makes sense for all of those formats, but > where it does, it should be done. I agree. It doesn't seem so difficult to add new formats. -- Frank Wille
Re: 32-bit partition offset/size in disklabel
On Wed, 30 Nov 2011 11:12:26 +0100 Martin Husemann wrote: > Not with disklabels, but with wedges. While disklabel mixed the > runtime and on-disk represantation in a single structure, wedges > separate this. You can create "run-time only" wedges on the fly with > dkctl(8), Hmm... that means I would have to make a small boot/root partition, which uses dkctl(8) to make the rest of the disk available? > and one example of a working on-disk format is GPT. >From the dk(4) man page also MBR and BSD-labels can be converted automatically into disk-wedges. Is it supported by sysinst? And what about other partition formats, like Apple Partition Maps, Amiga RDB, SGI, Sparc...? Is it planned to add support for them? -- Frank Wille
32-bit partition offset/size in disklabel
While looking at struct disklabel in src/sys/sys/disklabel.h I wonder
about the partition offset and size being 32-bit values:
struct partition { /* the partition table */
uint32_t p_size;/* number of sectors in partition */
uint32_t p_offset; /* starting sector */
[...]
I don't understand how NetBSD supports partitions larger than 2TB or
starting beyond the 2TB boundary (assuming a sector size of 512 bytes)...
--
Frank Wille
Re: kernel bitreverse function
On Sun, 3 Apr 2011 19:17:28 +0300 Jukka Ruohonen wrote: > While I have no real opinion for or against, I can certainly imagine > finding use for a well-defined "bit function" like this also in user > space. Sure, I agree. We can still add such functions in for userland programs, but for the kernel it makes no sense to use them, because: 1. They are inline functions, which do not save any space. 2. They cannot easily be replaced by MD instructions. -- Frank Wille
Re: kernel bitreverse function
Jukka Ruohonen wrote: > Just a footnote: wouldn't be a better place logically? I'm not sure. This is a user header file which contains inline functions. Don't know about others, but my goal was to eliminate double code from the kernel. The use of the new functions should also be restricted to the kernel. -- Frank Wille
Re: kernel bitreverse function
David Laight wrote:
> Works for me, I replaced the 2nd multiply by a shift (of the 1st product).
Your're right. I got a compiler bug. It works with gcc.
> I more modern gcc, compiling for a more modern cpu type, might
> generate code that will run faster on a modern cpu.
I guess the function is mostly used in mii or i2c drivers, which are
not so time critical. So I would put a bigger weight on the code size,
which is fine here.
Did somebody already try to implement it? If not, I would suggest the
following code for src/sys/lib/libkern:
New files:
bitrev8.c:
/* $NetBSD: $ */
#include
uint8_t bitrev8(uint8_t b)
{
return ((b * 0x0802u & 0x22110u) | (b * 0x8020u & 0x88440u))
* 0x10101u >> 16;
}
bitrev16.c:
/* $NetBSD: $ */
#include
uint16_t bitrev16(uint16_t b)
{
return (bitrev8(b & 0xff) << 8) | bitrev8(b >> 8);
}
bitrev32.c:
/* $NetBSD: $ */
#include
uint32_t bitrev32(uint32_t b)
{
return (bitrev16(b & 0x) << 16) | bitrev16(b >> 16);
}
Diffs:
Index: Makefile.libkern
===
RCS file: /cvsroot/src/sys/lib/libkern/Makefile.libkern,v
retrieving revision 1.13
diff -u -r1.13 Makefile.libkern
--- Makefile.libkern24 Mar 2011 17:05:44 - 1.13
+++ Makefile.libkern3 Apr 2011 15:02:50 -
@@ -61,6 +61,7 @@
.if empty(SRCS:Mbyte_swap_8.*)
SRCS+= bswap64.c
.endif
+SRCS+= bitrev8.c bitrev16.c bitrev32.c
SRCS+= md4c.c md5c.c rmd160.c sha1.c sha2.c
SRCS+= pmatch.c arc4random.c bcd.c mcount.c mertwist.c crc32.c
Index: libkern.h
===
RCS file: /cvsroot/src/sys/lib/libkern/libkern.h,v
retrieving revision 1.97
diff -u -r1.97 libkern.h
--- libkern.h 19 Feb 2011 02:02:14 - 1.97
+++ libkern.h 3 Apr 2011 15:02:50 -
@@ -348,4 +348,7 @@
unsigned int popcountll(unsigned long long) __constfunc;
unsigned int popcount32(uint32_t) __constfunc;
unsigned int popcount64(uint64_t) __constfunc;
+uint8_t bitrev8(uint8_t);
+uint16_t bitrev16(uint16_t);
+uint32_t bitrev32(uint32_t);
#endif /* !_LIB_LIBKERN_LIBKERN_H_ */
I'm not sure about the license, though. Is it sufficient to mention
Sean Anderson as the author of the original algorithm, but use the
standard NetBSD header?
Any comments? Then please speak now. :)
--
Frank Wille
Re: kernel bitreverse function
David Laight wrote: > Indeed, either: > ((b * 0x80200802ull) & 0x0884422110ull) * 0x0101010101ull >> 32 > or > ((b * 0x0802u & 0x22110u) | (b * 0x8020u & 0x88440u)) * 0x10101u >> 16 > are probably best - probably the 2nd since it avoids a 64x64 multiply. A nice solution. I like it. Unfortunately the second method doesn't work for me. It reverses both nibbles of a byte seperately instead of the whole byte. E.g. from 0x01 it makes 0x08. Once it works it should probably be in libkern. > It is also worth allowing for cpus that can have a hardware instruction > (and then do it in 1 clock!) Indeed some CPUs can do that. I know that the ColdFire has a bitrev instruction. Such code can go into libkern/arch. -- Frank Wille
kernel bitreverse function
Hi, is there already a global function to reverse the bits in a byte? If not, wouldn't it be useful to put an optimized function (e.g. with a 256-byte lookup-table, or 16-byte for the two nibbles to save space) into the kernel, or into libkern? Some drivers already implement their own reverse functions. And I ask, because I need one too, for a new I2C driver. -- Frank Wille
Re: _KMEMUSER and __HAVE_CPU_DATA_FIRST
christos wrote: > If you can and have defined __HAVE_CPU_DATA_FIRST you should not > need to expose anything in . It is probably better > to revert all changes that exposed struct cpu_info in the first > place because it is not needed. I just tried to revert it. But compiling vmstat for PPC still doesn't work, although __HAVE_CPU_DATA_FIRST is defined in powerpc/include/types.h. # compile vmstat/vmstat.o /home/frank/netbsd/current/src/obj/tooldir.NetBSD-5.1-i386/bin/powerpc--netbsd-gcc -O2 -fstack-protector -Wstack-protector --param ssp-buffer-size=1 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wsign-compare -std=gnu99 -Werror -D_KMEMUSER -I/home/frank/netbsd/current/src/sys -nostdinc -isystem /home/frank/netbsd/current/src/obj/destdir.macppc/usr/include -D_FORTIFY_SOURCE=2 -c /home/frank/netbsd/current/src/usr.bin/vmstat/vmstat.c /home/frank/netbsd/current/src/usr.bin/vmstat/vmstat.c: In function 'cpucounters': /home/frank/netbsd/current/src/usr.bin/vmstat/vmstat.c:979: error: dereferencing pointer to incomplete type /home/frank/netbsd/current/src/usr.bin/vmstat/vmstat.c:980: error: storage size of 'tci' isn't known cc1: warnings being treated as errors /home/frank/netbsd/current/src/usr.bin/vmstat/vmstat.c:980: warning: unused variable 'tci' *** Failed target: vmstat.o -- Frank Wille
Re: _KMEMUSER and __HAVE_CPU_DATA_FIRST
matt wrote:
>> A few days ago I learned from Christos that the MI part of cpu_info, i.e.
>> ci_data, should be exposed when _KMEMUSER is defined, to make vmstat
>> compile again.
>
> PowerPC is nasty since it needs three different cpu_infos. I think I'm
> going to move each variants stuff into its own structure and then add them
> via a union. Not pretty but a bit better than what's there now.
Sounds good. Feel free to undo my temporary solution then. For the moment
I'm just exposing "struct cpu_data ci_info" to avoid problems.
> has never exposed things to userland before. Now that kmem
> grovelers need to do it, we are finding issues.
Yes, I also found lots of issues in the m68k ports, where machine/cpu.h is
usually more complex than a single #include . I just
successfully compiled a port-amiga release with the following
modifications:
m68k/include/cpu.h:
--- cpu.h 22 Dec 2010 02:42:28 - 1.12
+++ cpu.h 24 Dec 2010 14:52:09 -
@@ -197,9 +197,10 @@
#defineCACHE60_ON (CACHE40_ON|IC60_CABC|IC60_EBC|DC60_ESB)
#defineCACHE60_OFF (CACHE40_OFF|IC60_CABC)
-#include
#if defined(_KERNEL) || defined(_KMEMUSER)
+#include
+
struct cpu_info {
struct cpu_data ci_data;/* MI per-cpu data */
cpuid_t ci_cpuid;
amiga/include/cpu.h:
--- cpu.h 22 Dec 2010 02:42:27 - 1.76
+++ cpu.h 24 Dec 2010 14:50:54 -
@@ -78,12 +78,6 @@
#ifndef _MACHINE_CPU_H_
#define _MACHINE_CPU_H_
-#if defined(_KERNEL)
-
-/*
- * Exported definitions unique to amiga/68k cpu support.
- */
-
#if defined(_KERNEL_OPT)
#include "opt_lockdebug.h"
#endif
@@ -92,6 +86,11 @@
* Get common m68k CPU definitions.
*/
#include
+
+#if defined(_KERNEL)
+/*
+ * Exported definitions unique to amiga/68k cpu support.
+ */
#defineM68K_MMU_MOTOROLA
extern volatile unsigned int interrupt_depth;
Should I commit that and fix other m68k-ports accordingly, or should I wait
for a better solution?
--
Frank Wille
_KMEMUSER and __HAVE_CPU_DATA_FIRST
Hi! A few days ago I learned from Christos that the MI part of cpu_info, i.e. ci_data, should be exposed when _KMEMUSER is defined, to make vmstat compile again. An alternative would have been when "struct cpu_data ci_info" was the first entry in all cpu_info structures. Then I saw Matt's last changes, which defined __HAVE_CPU_DATA_FIRST for nearly any port, which seems to be like this is exactly what was needed? Now I ask myself: could we use __HAVE_CPU_DATA_FIRST somehow as an alternative for _KMEMUSER? Or do we want to change each /include/cpu.h to expose cpu_info when _KMEMUSER is defined? I already tried to fix powerpc/include/cpu.h, but it seems that all ports are affected...? Probably I'm just confused and missing some information? ;) -- Frank Wille
Re: New apple keymap variant or keymap in /usr/share/wscons/keymaps?
Frank Wille wrote: > I have a few additional command keys for USB keyboards used internally > in Apple notebooks, which are valid for all national layouts: > > KC(209), KS_Cmd,KS_Cmd_BrightnessDown, > KC(210), KS_Cmd,KS_Cmd_BrightnessUp, > KC(211), KS_Cmd_VolumeToggle, > KC(212), KS_Cmd_VolumeDown, > KC(213), KS_Cmd_VolumeUp, > KC(214),KS_Num_Lock > > Those commands will be generated for FN-f1..f6. > In the future we could all more commands, e.g. for keyboard > illumination. > > Now the question is: would it be prefered to add another keymap-variant > (called "apple") to ukbdmap.c, or just make a new keymap file in > /usr/share/wscons/keymaps, which can be used wscons.cfg? I came to the conclusion that it might be easier and less intrusive to create a new keymap file (e.g. called "ukbd.apple.powerbook") for those function keys. So they can easily be added to any national keyboard layout. But I realized that wsconsctl is unable to process a mapping-line with just one Cmd_*, or a Cmd followed by Cmd_Function in it. When there is no good reason that those are rejected I will fix it in the wsconsctl-parser now. -- Frank Wille
chopped hid protocols in interrupts
Hi, I'm currently debugging an USB touchpad driver which used to work in 5.0. On every interrupt it expects to receive a sensor and mouse button protocol with a length of 81 bytes. But with the current source it receives three separate interrupts, with 32, 32 and 17 bytes. Is there anything I can do about it? It has probably something to do with USBD_SHORT_XFER_OK? -- Frank Wille
New apple keymap variant or keymap in /usr/share/wscons/keymaps?
Hi, I have a few additional command keys for USB keyboards used internally in Apple notebooks, which are valid for all national layouts: KC(209), KS_Cmd,KS_Cmd_BrightnessDown, KC(210), KS_Cmd,KS_Cmd_BrightnessUp, KC(211), KS_Cmd_VolumeToggle, KC(212), KS_Cmd_VolumeDown, KC(213), KS_Cmd_VolumeUp, KC(214),KS_Num_Lock Those commands will be generated for FN-f1..f6. In the future we could all more commands, e.g. for keyboard illumination. Now the question is: would it be prefered to add another keymap-variant (called "apple") to ukbdmap.c, or just make a new keymap file in /usr/share/wscons/keymaps, which can be used wscons.cfg? -- Frank Wille
Re: Enhancing ukbd for Apple notebooks
Michael wrote: >> How about Fn-Alt as a replacement for AltGr? I would do this >> modification in >> ukbd.c, just for Apple-keyboards with a special Fn-key. > > That would work. Ok, done. There is just a minor problem with this solution: When you type FN-Alt-ß on a german keyboard, to produce a \, you have to release FN before typing ß, because this key is also part of the keypad, which is activated by FN. But it's better than nothing, and everybody can change wscons.cfg to use his favourite key for AltGr... -- Frank Wille
Re: Enhancing ukbd for Apple notebooks
On Sat, 27 Nov 2010 19:32:22 +0100 Piotr Adamus wrote: > what about Fn-Esc as Delete key? Fn-Esc? Fn-Backspace is translated into a Delete key. > And FN-Down-Up as PgUp PgDn? Is it going it work? Yes. All that will work with my patch. -- Frank Wille
Re: Enhancing ukbd for Apple notebooks
Frank Wille wrote: > Still we have no AltGr on Apple notebooks with just a left Alt. > Should ukbd.c, or even wskbd.c be hacked to treat Ctrl-Alt as AltGr? Hmm... Ctrl-Alt is nonsense, of course. Because it is already used as a command modifier in wscons (switch screens with functions keys, or enter debugger with Esc). How about Fn-Alt as a replacement for AltGr? I would do this modification in ukbd.c, just for Apple-keyboards with a special Fn-key. -- Frank Wille
Re: Enhancing ukbd for Apple notebooks
Michael wrote: > To recap, my opinion is this: > - - keys should do what the label says, no shifting things around to > match PC layouts Ok. > - - we need AltGr, most people will expect it to be the right Alt key, > so that should be the (hopefully only ) exception Already works that way, because the right Alt key has the same keycode as AltGr on USB keyboards. > - - left/right Command key should become left/right Meta Already works that way, because the USB keycodes match. Still we have no AltGr on Apple notebooks with just a left Alt. Should ukbd.c, or even wskbd.c be hacked to treat Ctrl-Alt as AltGr? Although I wouldn't like it to press three keys at once, just for a \ or [. -- Frank Wille
Re: Enhancing ukbd for Apple notebooks
Michael wrote:
>> I completely agree that it is not nice, and I already thought about
>> turning the Alt/Option key into AltGr. But then we would miss Alt
>> under
>> NetBSD (which is used in various X11-based GUIs). The Apple/Command
>> keys,
>> on the other hand, are not needed.
>
> In my opinion the keys should do what the label says, option should be
> alt and the right option key should behave like the right alt key on
> every other keyboard on the planet,
The label for the right alt key shows "Alt", not "AltGr". This means the
current wscons behaviour is wrong for Apple keyboards, as it turns the
right alt key into AltGr? I just verified that on my Apple Pro keyboard.
> The Command keys should probably become Meta.
Ok. So we don't swap any keys or change their meaning. Agreed.
But then the problem on Apple notebook keyboards, where you only have the
left Alt key, remains: Where is the AltGr key?
Without that key all users of non-US keymaps won't be able to type important
characters like |, \, @, [, {, ~.
A solution must be found.
--
Frank Wille
Re: Enhancing ukbd for Apple notebooks
On Fri, 26 Nov 2010 22:44:58 +0100 Hauke Fath wrote: > > and turn the right Apple/Command key into AltGr. > > Ick. > > >This part is already working fine here. Are there any objections before I > >commit the code, or even better ideas? > > Assuming that most Apple notebooks will continue to run MacOS (X) to some > extent, I think it violates POLA to shoehorn the Apple into a pc keyboard > layout on the NetBSD side. I completely agree that it is not nice, and I already thought about turning the Alt/Option key into AltGr. But then we would miss Alt under NetBSD (which is used in various X11-based GUIs). The Apple/Command keys, on the other hand, are not needed. > As an option, maybe, for those who bought the > machine for the hardware. But not as a default. Hmm... I'm unsure what to do. Maybe there is a third or fourth opinion? -- Frank Wille
Enhancing ukbd for Apple notebooks
Hi! I'm trying to improve support for Apple's notebook USB keyboards, which have a few quirks: 1. The FN key is not handled internally, but has to be evaluated by ukbd. It can be found in the report descriptor by page=0xff, usage=3. 2. From the hardware point of view there are three different keyboard types: ANSI, ISO and JIS. The ISO keyboard has the keycodes 0x35 and 0x64 swapped (that's right of shift and left of '1'), and the key left of return generates code 0x31 instead of 0x32. 3. There is no AltGr, which is a real problem with non-US keymaps. My current solution is to add Apple ISO keyboards with the new quirk-flag UQ_APPLE_ISO to usb_quirks.c. ukbd.c will then fix the keycodes when it sees this flag. It will also automatically detect an Apple FN-key and translate all keycodes to keypad-keycodes, when it is pressed. Additionally I would like to add a new keymap-variant, called "apple" to wsksymdef.h and ukbdmap.c. Theoretically it could be extended to have the same keymap as under OSX, but for the moment it will at least generate a NumLock event for FN-F6 and turn the right Apple/Command key into AltGr. This part is already working fine here. Are there any objections before I commit the code, or even better ideas? The diff with all changes can be downloaded from ftp://ftp.netbsd.org/pub/NetBSD/misc/phx/apple_ukbd.diff Next I would like to add some support for the other function keys, when pressed together with FN. They are used to control display brightness, volume and keyboard illumination. But as I understand it cannot easily be done, as a wscons Cmd_xxx code always requires CTRL+ALT to be pressed, and not FN... -- Frank Wille
Re: kthread with kpause or callout
Andrew Doran wrote: >> I'm just unsure about using mutexes during the callout. I have an >> IPL_NONE-kmutex which locks register access (my chip supports several >> register banks, so I need to make sure they are not switched). May I >> acquire this mutex during a callout (which is a softint, as I >> understand)? Will the softint sleep or busy-wait? > > Yes, you can take an IPL_NONE (adaptive) mutex from a softint / > callout. Whether it sleeps or spins is a decision that the kernel makes > at runtime. It tries to spin. If that would deadlock the system, it > sleeps. This is the only time a callout/softint can sleep - for a > mutex/rwlock. Thanks. Good to know. In the meantime I had to upgrade to an IPL_VM mutex, because the chip registers will have to be accessed from a VM-level interrupt too. I already discussed that with Martin in private and I guess it will have the effect that a process or softint holding the mutex will lock out any IPL_VM interrupt during this time? -- Frank Wille
Re: kthread with kpause or callout
On Mon, 8 Feb 2010 15:12:10 +0100 Martin Husemann wrote: > On Mon, Feb 08, 2010 at 03:09:55PM +0100, Martin Husemann wrote: > > The wording is not explicit, but a softint is not allowed to block > > on > > s/softint/callout/ of course, sorry for the confusion. *Now* you confused me! :) A callout is executed as a softint, isn't it? -- Frank Wille
Re: kthread with kpause or callout
On Mon, 8 Feb 2010 15:09:55 +0100 Martin Husemann wrote: > On Mon, Feb 08, 2010 at 03:04:07PM +0100, Frank Wille wrote: > > [...] May I acquire this mutex during a callout (which is a > > softint, as I understand)? Will the softint sleep or busy-wait? > > Depends on the mutex type, from mutex(9): > [...] > Adaptive mutexes cannot be acquired from a hardware > interrupt handler. > [...] > The wording is not explicit, but a softint is not allowed to block on > an adaptive mutex, Yes, this is what I thought as well, but the man page only mentions hardware interrupts. Are you sure about it? Hmmm... from softint(9): [...] Unlike hardware interrupts, software interrupts do have thread context. They may block on synchro- nization objects, sleep, and resume execution at a later time. [...] IMHO that would allow my callout to sleep on acquiring the mutex? -- Frank Wille
Re: kthread with kpause or callout
On Mon, 8 Feb 2010 11:29:51 +0100 Martin Husemann wrote: > On Mon, Feb 08, 2010 at 11:11:04AM +0100, Frank Wille wrote: > > - Running a kthread and calling kpause() between the polls. > > - Using a callout which reschedules itself after the poll. > > The thread is quite a bit more heavyweight, but you have full freedom > to do what you want. The callout is pretty lightweight but you are > still subject of "interrupt context" rules. Ok, thanks. Then the callout should be fine for me. I'm just unsure about using mutexes during the callout. I have an IPL_NONE-kmutex which locks register access (my chip supports several register banks, so I need to make sure they are not switched). May I acquire this mutex during a callout (which is a softint, as I understand)? Will the softint sleep or busy-wait? -- Frank Wille
kthread with kpause or callout
Hi, I'm writing a keyboard driver which doesn't support interrupts in some revisions, so I have to poll its status from time to time. What would be better suited for that task: - Running a kthread and calling kpause() between the polls. - Using a callout which reschedules itself after the poll. Or is there something even better suited, which I'm missing? -- Frank Wille
Re: Catweasel driver
On Sat, 6 Feb 2010 18:46:56 + David Brownlee wrote: > firmload can currently load from a set of directories. Has anyone > considered extending firmload to optionally load from memory as well - > possibly an included ramdisk image? That would allow the choice of > building in firmware images which could be loaded at boot and then the > memory released. Plus it keeps a single consistent API. > > Just a thought :) Sounds like a great idea to me. All the space for firmwares in the kernel, would no longer be wasted. -- Frank Wille
Re: Catweasel driver
Masao Uebayashi wrote: > Probably we can think of a nice way to apply modules(9) to load a > firmware image, upload it to the device, then unload. When firmload(9) > was invented, we didn't have a nice kernel module support yet. As I understand this would also need a filesystem to load from? Back to /dev/joy again. When I want the device to be used from another file as well, could I change the entry in the majors.xxx file into: device-majorjoy char 26 joy | myname ? -- Frank Wille
Re: Catweasel driver
Joerg Sonnenberger wrote: > Can't you use the approach e.g. of the wpi(4) driver and load the > firmware image from the filesystem? No, firmload(9) would not really be an option, because I want to detect connected devices, like a keyboard and floppy disk drives during boot. Without the firmware this would be impossible. -- Frank Wille
Catweasel driver
Hi, yesterday I started to write an MI driver for the Catweasel MK3 and MK4 PCI boards (http://www.icomp.de/indexe.htm). The card is recognized, the io space is mapped and the hardware is initialized (firmware uploaded into the card's FPGA). ATM I have two questions: 1. The firmware is large, with about 60k. Does anybody have experience with using a compressed firmware image in the driver, which is uncompressed on the fly, while uploading it to the chip? How would I do that? (This would probably make sense for most firmware, so a common interface in the kernel could be quite useful.) 2. The card also supports two (Amiga/Atari-style) digital joysticks. It would be nice to make them appear as joy(4). Is it possible to use the same device major number as /dev/joy* but with a another driver than src/dev/ic/joy.c? -- Frank Wille
Re: ddb write and io memory
matthew green wrote: > another alternative would be to add a flag to write, eg "write/n". True. But you would also need the size, e.g. "write/nb". I think about it... -- Frank Wille
Re: ddb write and io memory
matthew green wrote:
>On Sat, Jan 30, 2010 at 08:45:48PM +0100, Frank Wille wrote:
>> Therefore I would like to change ddb/db_write_cmd.c as in the
>>following ch:
>> [...]
>>
>> Any objections? Do we absolutely need to print the old value here?
>
>I think it's somewhat desirable to. Wouldn't it be better anyway to
>create a second command ("iowrite" or "regwrite" or something) that
>both does this and also does anything else that might be necessary
>to write to I/O registers safely, like flushing caches?
>
> yeah - please invent a new commamd
Ok. I make a new command. iowrite sounds nice.
> (maybe even "mach" command) to
> do this, instead of changing how write works.
I doubt that a machine command makes much sense, because I see no machine
dependency in not reading memory before writing it.
Flushing caches should be done anyway in the MD backend of db_memwr.c.
--
Frank Wille
ddb write and io memory
Hi,
I just ran into a problem with ddb when using the "write" command on
write-only IO registers.
Unfortunately it reads the memory location before writing it, to be able to
display the previous value. That's fatal with registers which don't care
about the R/W line but take any access to a specific address as a write
access. In most cases this will write all 1-bits before writing the desired
value, which could trigger unwanted effects.
Therefore I would like to change ddb/db_write_cmd.c as in the following
patch:
--- db_write_cmd.c 7 Mar 2009 22:02:17 - 1.23
+++ db_write_cmd.c 30 Jan 2010 19:43:24 -
@@ -46,7 +46,6 @@
db_expr_t count, const char *modif)
{
db_addr_t addr;
- db_expr_t old_value;
db_expr_t new_value;
int size;
boolwrote_one = false;
@@ -71,10 +70,8 @@
}
while (db_expression(&new_value)) {
- old_value = db_get_value(addr, size, false);
db_printsym(addr, DB_STGY_ANY, db_printf);
- db_printf("\t\t%s = ", db_num_to_str(old_value));
- db_printf("%s\n", db_num_to_str(new_value));
+ db_printf("\t\t= %s\n", db_num_to_str(new_value));
db_put_value(addr, size, new_value);
addr += size;
Any objections? Do we absolutely need to print the old value here?
--
Frank Wille
