Re: machfb MMIO versus SPARCle OFW
Hello, On Mon, 21 Oct 2013 21:09:04 +0100 Julian Coleman j...@coris.org.uk wrote: I tracked down why my SPARCle (SPARC laptop) appears to lock up on halt. The cause is: http://mail-index.NetBSD.org/source-changes/2012/08/15/msg036624.html where we use the MMIO registers and alter the BUS_CNTL register. This is a problem because altering the BUS_CNTL register in this way [*] causes the OFW console to stop working when we halt. Eww. IIRC that's supposed to turn off the register block that lives in the upper 2KB of each half aperture, it didn't cause any problems with other other Sun or Apple mach64 OFW that I have here. Should really only be done when we have 8MB VRAM and the registers would overlap with it. ( Mach64 has a 16MB aperture that's split into one big and one little endian half, the register block exists in both so with 8MB there's overlap. Not-so-ancient models have the registers in an additional PIO BAR, the last few generations have them in yet another MMIO BAR. The plan is to use MMIO whenever possible and only fall back to the aperture if absolutely necessary so, for example, all VRAM van be mapped with things like prefetching and relaxed write ordering enabled. ) The solution seemed fairly easy - add a detach routine to machfb to restore the BUS_CNTL register (patch attached). However, this fails because wsdisplay0 attaches at machfb0, so we also need a detach routine for wsdisplay. As wsdisplay0 is the console, we have to force the detach, so it seemed reasonable to add an additional flag for that (wscons patch also attached). This works, and halt now returns to the OFW prompt. Does sparcle's mach64 have 8MB VRAM? I've got an 8MB PGX64 to play with. However, I have a question about the wscons patch - there is no wsdisplay_noemul_detach(), so is it sensible to call only wsdisplay_emul_detach() on detach, or is there configuration where wsdisplay* at machfb could be wsdisplay_noemul? Actually, we can probably leave the registers enabled anyway, and only turn them off if something tries to mmap that last bit of video RAM. IIRC machfb itself doesn't need VRAM access at all, and the whole song dance is mostly intended for X. have fun Michael
Re: machfb MMIO versus SPARCle OFW
Eww. IIRC that's supposed to turn off the register block that lives in the upper 2KB of each half aperture, it didn't cause any problems with other other Sun or Apple mach64 OFW that I have here. Should really only be done when we have 8MB VRAM and the registers would overlap with it. Not sure why it causes the problem on SPARCle then. It has a Rage L Mobility, which I don't think is in any other machine that we use mach64 on (I had to add it to the match routine). Also, it's possible that the firmware is slightly different from the standard Sun version. Does sparcle's mach64 have 8MB VRAM? I've got an 8MB PGX64 to play with. Yes. dmesg is: machfb0 at pci0 dev 19 function 0: ATI Technologies Rage L Mobility (PCI) (rev. 0x64) machfb0: using MMIO aperture machfb0: 16 MB aperture at 0x0300, 4 KB registers at 0xa000 machfb0: 128 KB ROM at 0x0002 machfb0: 8192 KB SDRAM 55.815 MHz, maximum RAMDAC clock 230 MHz machfb0: initial resolution 1400x1050 at 8 bpp machfb0: attached to /dev/fb0 Actually, we can probably leave the registers enabled anyway, and only turn them off if something tries to mmap that last bit of video RAM. IIRC machfb itself doesn't need VRAM access at all, and the whole song dance is mostly intended for X. Not altering the BUS_CNTL register would seem easier. However, detach does work if that's not possible. Thanks, J -- My other computer also runs NetBSD/Sailing at Newbiggin http://www.netbsd.org// http://www.newbigginsailingclub.org/
Re: machfb MMIO versus SPARCle OFW
On Tue, 22 Oct 2013 11:50:43 +0100 Julian Coleman j...@coris.org.uk wrote: Eww. IIRC that's supposed to turn off the register block that lives in the upper 2KB of each half aperture, it didn't cause any problems with other other Sun or Apple mach64 OFW that I have here. Should really only be done when we have 8MB VRAM and the registers would overlap with it. Not sure why it causes the problem on SPARCle then. It has a Rage L Mobility, which I don't think is in any other machine that we use mach64 on (I had to add it to the match routine). Also, it's possible that the firmware is slightly different from the standard Sun version. Maybe the sparcle firmware uses the blitter. Most Sun and Apple firmware for PCI graphics chips I've seen runs the hardware as dumb framebuffers ( unlike for example SBus and UPA hardware ) but nothing keeps them from using it. Does sparcle's mach64 have 8MB VRAM? I've got an 8MB PGX64 to play with. Yes. dmesg is: machfb0 at pci0 dev 19 function 0: ATI Technologies Rage L Mobility (PCI) (rev. 0x64) machfb0: using MMIO aperture machfb0: 16 MB aperture at 0x0300, 4 KB registers at 0xa000 machfb0: 128 KB ROM at 0x0002 machfb0: 8192 KB SDRAM 55.815 MHz, maximum RAMDAC clock 230 MHz machfb0: initial resolution 1400x1050 at 8 bpp machfb0: attached to /dev/fb0 Actually, we can probably leave the registers enabled anyway, and only turn them off if something tries to mmap that last bit of video RAM. IIRC machfb itself doesn't need VRAM access at all, and the whole song dance is mostly intended for X. Not altering the BUS_CNTL register would seem easier. However, detach does work if that's not possible. Guess it's better to leave it alone then - X should know how to deal with it if needed ( and if there are problems then they need to be fixed on that side ) I'll dig up my PGX64. have fun Michael
re: machfb MMIO versus SPARCle OFW
Not altering the BUS_CNTL register would seem easier. However, detach does work if that's not possible. well -- this doesn't help ddb or dropping to the prom directly does it? i think a solution that leaves it working without any special detach needed is the best idea here. .mrg.
Re: machfb MMIO versus SPARCle OFW
Hi, well -- this doesn't help ddb or dropping to the prom directly does it? Strangely, droppping to DDB or to the PROM from DDB works fine. It's just halt and reboot that don't work. Thanks, J PS. I didn't test a kernel witout DDB. -- My other computer also runs NetBSD/Sailing at Newbiggin http://www.netbsd.org// http://www.newbigginsailingclub.org/
Re: DIOCGDISCARDINFO and DIOCDISCARD
On Fri, 11 Oct 2013 10:31:39 -0400
Michael macal...@netbsd.org wrote:
Something related - how difficult would it be to support something
TRIM-ish on CompactFlash? Not that I have the faintest clue about ATA
in general, let alone the CF-specific extensions...
The CF part should be easy to do. To be useful in practice, it would
also be necessary to add calls to it from msdosfs. This code is
a mess. Also, common USB card readers don't support the commands
needed AFAIK.
While we are here... I've found some problems with CF cards
when I plugged them into a PCMCIA slot. First was that it was not
correctly identified by atactl. The other that the machine crashed
on shutdown if the card's filesystem was not mounted, so that
the slot was powered down.
If you have your CF cards connected in a similar way (i.e. not
translated into an sd SCSI device), could you try the appended
patch and see that it does no damage?
best regards
Matthias
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
# HG changeset patch
# Parent 24bbe2c07df0865de34a29b0279a2cbb52bbddc4
diff -r 24bbe2c07df0 distrib/utils/sysinst/disks.c
--- a/distrib/utils/sysinst/disks.c Tue Aug 13 12:24:16 2013 +0200
+++ b/distrib/utils/sysinst/disks.c Tue Aug 13 15:05:05 2013 +0200
@@ -259,7 +259,8 @@
* Mitsumi ATAPI devices
*/
- if (!((inqbuf-atap_config WDC_CFG_ATAPI_MASK) == WDC_CFG_ATAPI
+ if (!(inqbuf-atap_config != WDC_CFG_CFA_MAGIC
+ (inqbuf-atap_config WDC_CFG_ATAPI)
((inqbuf-atap_model[0] == 'N'
inqbuf-atap_model[1] == 'E') ||
(inqbuf-atap_model[0] == 'F'
diff -r 24bbe2c07df0 sbin/atactl/atactl.c
--- a/sbin/atactl/atactl.c Tue Aug 13 12:24:16 2013 +0200
+++ b/sbin/atactl/atactl.c Tue Aug 13 15:05:05 2013 +0200
@@ -947,7 +947,8 @@
* Mitsumi ATAPI devices
*/
- if (!((inqbuf-atap_config WDC_CFG_ATAPI_MASK) == WDC_CFG_ATAPI
+ if (!(inqbuf-atap_config != WDC_CFG_CFA_MAGIC
+ (inqbuf-atap_config WDC_CFG_ATAPI)
((inqbuf-atap_model[0] == 'N'
inqbuf-atap_model[1] == 'E') ||
(inqbuf-atap_model[0] == 'F'
@@ -980,9 +981,13 @@
((uint64_t)inqbuf-atap_wwn[2] 16) |
((uint64_t)inqbuf-atap_wwn[3] 0));
- printf(Device type: %s, %s\n, inqbuf-atap_config WDC_CFG_ATAPI ?
- ATAPI : ATA, inqbuf-atap_config ATA_CFG_FIXED ? fixed :
- removable);
+ printf(Device type: %s,
+ inqbuf-atap_config == WDC_CFG_CFA_MAGIC ? CF-ATA :
+(inqbuf-atap_config WDC_CFG_ATAPI ? ATAPI : ATA));
+ if (inqbuf-atap_config != WDC_CFG_CFA_MAGIC)
+ printf(, %s,
+inqbuf-atap_config ATA_CFG_FIXED ? fixed : removable);
+ printf(\n);
compute_capacity(inqbuf, capacity, sectors, secsize);
diff -r 24bbe2c07df0 sys/dev/ata/atareg.h
--- a/sys/dev/ata/atareg.h Tue Aug 13 12:24:16 2013 +0200
+++ b/sys/dev/ata/atareg.h Tue Aug 13 15:05:05 2013 +0200
@@ -284,7 +284,7 @@
struct ataparams {
/* drive info */
uint16_t atap_config;/* 0: general configuration */
-#define WDC_CFG_ATAPI_MASK 0xc000
+#define WDC_CFG_CFA_MAGIC 0x848a
#define WDC_CFG_ATAPI 0x8000
#defineATA_CFG_REMOVABLE 0x0080
#defineATA_CFG_FIXED 0x0040
diff -r 24bbe2c07df0 sys/dev/ata/wd.c
--- a/sys/dev/ata/wd.c Tue Aug 13 12:24:16 2013 +0200
+++ b/sys/dev/ata/wd.c Tue Aug 13 15:05:05 2013 +0200
@@ -408,8 +408,14 @@
{
struct wd_softc *sc = device_private(dv);
+ /* the adapter needs to be enabled */
+ if (sc-atabus-ata_addref(sc-drvp))
+ return true; /* no need to complain */
+
wd_flushcache(sc, AT_WAIT);
wd_standby(sc, AT_WAIT);
+
+ sc-atabus-ata_delref(sc-drvp);
return true;
}
diff -r 24bbe2c07df0 sys/dev/usb/umass_isdata.c
--- a/sys/dev/usb/umass_isdata.cTue Aug 13 12:24:16 2013 +0200
+++ b/sys/dev/usb/umass_isdata.cTue Aug 13 15:05:05 2013 +0200
@@ -546,8 +546,8 @@
* Shuffle string byte order.
* ATAPI Mitsumi and NEC drives don't need this.
*/
-
autoconf deferred processing
Can somebody explain how the deferred processing code in subr_autoconf.c is supposed to work ? Looking at config_create_interruptthreads() it creates 8 threads all of which seem to walk the same list and delete elements from it. I'm getting crashes in i386 at startup and am trying to track down what is causing it. The faulting PC is random so I'm looking for anything that calls through function pointers. Robert Swindells
Re: autoconf deferred processing
In article 20131022205705.c0dc812...@ren.fdy2.co.uk, Robert Swindells r...@fdy2.co.uk wrote: Can somebody explain how the deferred processing code in subr_autoconf.c is supposed to work ? Looking at config_create_interruptthreads() it creates 8 threads all of which seem to walk the same list and delete elements from it. I'm getting crashes in i386 at startup and am trying to track down what is causing it. The faulting PC is random so I'm looking for anything that calls through function pointers. Robert Swindells Edit subr_autoconf.c and set the number of threads to 1. int interrupt_config_threads = 8; int mountroot_config_threads = 2; Or you can patch them in ddb with boot -d Also you can add DEBUG_AUTOCONF in current, which prints the name of the deferred driver as well as the count ot the deferred mutex. For even better success, boot -1 christos
