Hi,
> How do I know what properties are going to be available in a driver?
> Is it part of an internal kernel<->kernel interface like device
> properties, or just whatever is passed through the OF/FDT or ACPI
> firmware?
I think that we need a standard form for each type of information. The
sour
Hi,
> If it's really the case that SANE works with these, then that seems ok.
> (I actually have a UMAX scsi scsanner but haven't powered it on in
> years.)
The scanners that we support are also on the SANE project lists [*],
although the driver is marked as unsupported.
> I wonder though if thi
Hi all,
Can we get rid of the SCSI scanner support as well? It only supports old
HP and Mustek scanners, and its functionality is superseded by SANE (which
sends the relevant SCSI commands from userland).
Regards,
Julian
Hi all,
When testing some iic changes, we saw this panic on shutdown (on a 4 CPU
system):
[ 356534.4468099] Skipping crash dump on recursive panic
[ 356534.5093055] panic: lock error: Mutex: mutex_vector_exit,747: assertion
failed: MUTEX_OWNER(mtx->mtx_owner) == curthread: lock 0x1037806c8 c
Hi all,
While testing changes to an envsys driver, I saw this crash on shutdown:
[ 1651.0108940] cpu0: data fault: pc=155ea68 rpc=101db8ca4 addr=0
[ 1651.0108940] kernel trap 30: data access exception
Stopped in pid 0.5 (system) at netbsd:mutex_oncpu.part.0+0x8: ldx
[%g1 + 0x18], %g2
Hi,
> > Might I suggest before we go to deep down the rabbit hole that you take a
> > look at the GPIO FDT bindings?
> >
> >
> > https://github.com/devicetree-org/devicetree-source/blob/master/Bindings/gpio/gpio.txt
Looking at the bindings, there are definitions of polarity, which I need
b
Hi,
> Sorry guys for chiming in a little late, but I have a keen interest in this
> area, and there are lots of ways this needs to be harmonized across the
> system, including the ability to have a generic way to specify that an
> interrupt source, for example, is tied to a GPIO pin (useful for
Hi,
> > The definitions of pins are coming from hardware-specific properties.
>
> That's what I missed. On a device you are dealing with, pin N is
> *always* wired to an LED because that's how it comes from the factory.
> My head was in maker-land where there is an LED because someone wired
> on
Hi,
Thanks for the comments!
> > #define GPIO_PIN_LED0x01
> > #define GPIO_PIN_SENSOR 0x02
> >
> > Does this seem reasonable, or is there a better way to do this?
> I don't really understand how this is different from in/out.
> Presumably this is coming from some request from userspace o
Hi all,
I'm adding a driver and hardware-specific properties for GPIO's (which pins
control LED's, which control sensors, etc). I need to be able to pass the
pin information from the arch-specific configuration to the MI driver. I'd
like to add a new dev/gpio/gpiotypes.h, so that I can share the
Hi all,
> I'd like to add a capability in sdmmcvar.h to show that the controller only
> supports v1.0. This is different from the other capabilities there which
> are supported (i.e. not unsupported) capabilities. The reason to do this
> is to avoid touching every other driver to add a v1.1+ cap
Hi all,
We have a driver for the Winbond W83l518D, which is an old SDMMC controller
that only supports SDMMC version 1.0. This means that it doesn't handle
newer opcodes. Unfortunately, instead of passing them through to the card,
it fails to handle them. Our current code (specifically sdmmc_me
Hi all,
> attach always 'succeeds' in the sense that after attach has been called,
> detach will always be called. The detach routine should tear down
> everything that needs tearing down and not do things that will fail.
> Perhaps the init could simply be done before the attach routine gets th
Hi,
I've been looking at some of the sensors using the envsys framework, and
adding the ability to get and set the hardware (sensor chip) limits. Two
aspects of envsys, related to initial values, seem strange to me:
1) we call setlimits immediately after getlimits
2) we call getlimits before
Hi,
> The above is not necessarily correct -- many of the chips supported by
> the lm(4) driver, on NetBSD, OpenBSD and DragonFly BSD, certainly do,
> in fact, implement a whole bunch of fan-controlling features; see
> http://sensors.cnst.su/fanctl/ for a sample BSD implementation of the
> fan con
Hi,
> Depends on whether you're on AMD's virtual degC scale they use for their CPU
> temps or it's real degC's.
I didn't realise that some CPU's don't report real values. So, it could be
the CPU temperature after all.
> Also, if we assume that the dbcool chip controls the CPU fan(s), it makes
Hi,
> In general, I personally don't think it ever makes sense to shutdown
> by default when the temperature is exceeded, since most of these
> sensors aren't really all that reliable (especially if you're getting
> them over i2c, with potential bus locking issues and race conditions
> with BIOS /
Hi,
> envstat -d dbcool0 says:
>Current CritMax WarnMax WarnMin CritMin Unit
> [...]
> r2_temp:53.250 54.000 45.000 degC
> [...]
> If I read that correctly, it means that at 54 degC, it's time for emergency
> shut-down, while only at 57 degC, fans have
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/Sa
> 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.
No
Hi,
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 wa
Hi,
> I'd like to add support for the keyboard on the Tadpole SPARCle laptops.
> This uses a PC (8042) keyboard controller with two main differences. The
> first is that the aux port does't probe until after an initial timeout.
> The second is that the keyboard does not do scan code translation,
Hi,
> OK. So the driver doesn't change -- nor the features available
> to the "device", itself. E.g., it doesn't *add* (or remove)
> any capabilities that aren't always present, regardless.
That's correct. The driver is often split up into the code to handle the
chip itself (src/sys/dev/ic/*)
Hi,
I'd like to add support for the keyboard on the Tadpole SPARCle laptops.
This uses a PC (8042) keyboard controller with two main differences. The
first is that the aux port does't probe until after an initial timeout.
The second is that the keyboard does not do scan code translation, so we
ha
Hi,
> so the attached patch increases the space for frequencies at the end of
> usb_audio_streaming_type1_descriptor (to AUFMT_MAX_FREQUENCIES), and sets
> auf->frequency_type to AUFMT_MAX_FREQUENCIES if the hardware reports more
> than we can handle.
Patch committed.
Thanks,
J
--
My other
Hi,
> So, it seems that we are overwriting
> the end of usb_audio_streaming_type1_descriptor for every descriptor where
> the number of rates is more than 2. The problem is that we only notice when
> we come to read. So, I think that we should set:
>
>
Hi,
I see kernel crashes when playing a sample via a USB audio device:
uaudio0 at uhub0 port 2 configuration 1 interface 0
uaudio0: Logitech Logitech USB Headset, rev 1.10/10.13, addr 3
uaudio0: ignored input endpoint of type adaptive
uaudio_identify_as: too much tSamFreq: 5
uaudio_iden
Hi,
After the change in revision 1.156 of src/sys/dev/scsipi/scsipi_base.c to
assert that the kernel lock is held in scsipi_lookup_periph(), my SBus-based
sparc64 crashed with:
panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file
"/usr/src/sys/dev/scsipi/scsipi_base.c", line 221
Hi,
> I tried booting a Sun E3500 (sparc64) with today's current, but it dies early
> with:
> panic: uvm_km_bootstrap: could not reserve kernel kmem
This turned out to be because the kernel map was not large enough for machines
with 8GB or more of main memory. I've restricted sparc64 NKMEMPAG
Hi,
I tried booting a Sun E3500 (sparc64) with today's current, but it dies early
with:
Loading netbsd: 8945656+559016+366344 [599208+399025]=0xdd6328
panic: uvm_km_bootstrap: could not reserve kernel kmem
This is the "uvm_map_findspace failed" ENOMEM return in uvm_map_prepare():
http://o
Hi,
> Yes, of course. But I haven't hardwired SCSI IDs to sd instances. So I didn't
> know whether the new SCSI Target 0 would become sd0.
It will attach with the same unit number as the one that was detached. The
autoconf code removes the entry when the disk is detached and the new disk
attach
Hi,
> > But with scsictl detach/scan, I suppose?
> > But with SCA, I'm unsure, whether, after detaching sd0 (and sd1 still
> > there), a newly scanned sd will become sd0 or sd2?
>
> I'm not sure either. My guess would be that it would be sd2, but that
> is just a guess.
When I have done this
Hi,
> This is approx. the maximum performance of the old hardware.
>
> When
> the computer starts, the LSI Firmware BIOS scans the disks and sets a
> meaningful initial setup for each of them.
> What then happens is very stupid. The
33 matches
Mail list logo
