Re: problem with re(4) interface
On 11/22/21 12:55 PM, Warner Losh wrote:
On Mon, Nov 22, 2021 at 10:51 AM Chuck Tuffli wrote:
On Mon, Nov 22, 2021 at 9:34 AM Chris wrote:
On 2021-11-22 08:47, Chuck Tuffli wrote:
Running on a recent-ish -current
# uname -a
FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT
main-81b22a9892 GENERIC amd64
I'm having trouble using the second NIC interface in a bridge to
provide
network connectivity to bhyve VMs and need some help figuring out what
is
wrong.
...
Because there's subtle differences between them; are you using the re
driver
from base, or from ports?
The driver is from base. Didn't realize there was one in ports.
The ports driver is tricky... It's an older, buggier version of the base
driver... *BUT*
a number of issues that aren't fixed in base are fixed in it (mostly
dealing better with
errata)... Ideally, we'd pull in the actual fixes from this driver, but
it's a huge patch-set
where it's unclear which bits are for what thing fixed, so nobody (that I
know of) has
gone through and even come up with an ugly patch for -current.
Warner
I use the Realtek BSD driver; it supports one of their newer 2.5GbE
Ethernet chips on my motherboard.
Aug 22 19:37:29 vickie kernel: re1: Controller> port 0xc000-0xc0ff mem
0xfc20-0xfc20,0xfc21-0xfc213fff at device 0.0 on pci7
Aug 22 19:37:29 vickie kernel: re1: Using Memory Mapping!
Aug 22 19:37:29 vickie kernel: re1: attempting to allocate 1 MSI-X
vectors (32 supported)
Aug 22 19:37:29 vickie kernel: msi: routing MSI-X IRQ 84 to local APIC 2
vector 51
Aug 22 19:37:29 vickie kernel: re1: using IRQ 84 for MSI-X
Aug 22 19:37:29 vickie kernel: re1: Using 1 MSI-X message
Aug 22 19:37:29 vickie kernel: re1: version:1.96.04
Aug 22 19:37:29 vickie kernel: re1: Ethernet address: 2c:f0:5d:**:**:**
Aug 22 19:37:29 vickie kernel:
Aug 22 19:37:29 vickie kernel: This product is covered by one or more of
the following patents:
Aug 22 19:37:29 vickie kernel: US6,570,884, US6,115,776, and US6,327,625.
Aug 22 19:37:29 vickie kernel: re1: bpf attached
Aug 22 19:37:29 vickie kernel: re1: Ethernet address: 2c:f0:5d:**:**:**
The stock re(4) driver doesn't detect it.
The Realtek driver sources are here
https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-pci-express-software
but they're for FreeBSD 7.x and 8.0; I had to patch the driver for my
14.0-CURRENT box (panic on an mtx_lock(9) call; adding flag MTX_RECURSE
to the mtx_init(9) call "fixes" it).
diff --git a/if_rereg.h b/if_rereg.h
index 18592a7..4885063 100755
--- a/if_rereg.h
+++ b/if_rereg.h
@@ -1016,7 +1016,7 @@ enum bits {
#define RE_LOCK(_sc) mtx_lock(&(_sc)->mtx)
#define RE_UNLOCK(_sc) mtx_unlock(&(_sc)->mtx)
-#define RE_LOCK_INIT(_sc,_name)
mtx_init(&(_sc)->mtx,_name,MTX_NETWORK_LOCK,MTX_DEF)
+#define RE_LOCK_INIT(_sc,_name)
mtx_init(&(_sc)->mtx,_name,MTX_NETWORK_LOCK,MTX_DEF | MTX_RECURSE)
#define RE_LOCK_DESTROY(_sc) mtx_destroy(&(_sc)->mtx)
#define RE_LOCK_ASSERT(_sc) mtx_assert(&(_sc)->mtx,MA_OWNED)
Maybe I can try making this into a port - oh great, someone beat me to it!
https://www.freshports.org/net/realtek-re-kmod
Looks like they "properly" fix the locking isue -
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=225980=diff
Anthony
Re: Working ath10k device?
On 8/2/19 6:19 PM, Steve Kargl wrote: I have a Dell XPS 13 that reports the wifi chip is a Qualcomm Atheros 6147. I've found Adrain's WIP driver, and built it. I'm seeing the panic reported at https://lists.freebsd.org/pipermail/freebsd-current/2019-February/072769.html Does anyone have a /dev/if_athp.ko and firmware? I pushed a simple fix to my github repo - https://github.com/ScoobiFreeBSD/athp/pull/1 Anthony ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Using loader.conf(5) 'exec' directive to set video mode
On 2019-05-21 07:06, Vladimir Kondratyev wrote: On 20.05.2019 16:23, Anthony Jenkins wrote: I'm running (a somewhat dated) FreeBSD 13.0-CURRENT (git commit 68c8581f7, Tue. Feb 12 13:01:55 2019) on a UEFI laptop with an Intel UHD display, booting a ZFS root filesystem (gptzfsboot(8)). I'm trying to get the console into a lower resolution than the native UHD when the kernel is booted. It is possible to increase size of font compiled into kernel. See the attached patch. AFAIR I made it through conversion of x11-fonts/terminus-font to C-source file with one of /usr/src/tools/tools/vt/ tools Excellent... I think that will do just nicely! Thanks! I can manually do this by breaking into the loader prompt at boot and entering 'mode 1', then 'boot'. loader.conf(5) says I can run this command automatically with the 'exec' directive, but the video mode doesn't change. $ sudo cat /boot/loader.conf Password: autoboot_delay="3" #boot_single="YES" boot_verbose="YES" kern.timecounter.hardware="HPET" hw.psm.synaptics_support="1" kern.vty="vt" hw.vga.textmode="1" efi_max_resolution="1920x1080" exec="mode 1" I've also tried using directive 'efi_max_resolution' - same result. Does 'exec' work on my configuration (UEFI boot, ZFS root), or am I not using it right? I've tried putting other loader commands in 'exec' with no effect. Same question for efi_max_resolution. exec="mode N" works at least for me (UEFI boot, ZFS root, NVidia GTS 250, no KMS) Bah... trying to avoid debugging it on my end, but looks like I'll have to if I'm the only one experiencing it. Anthony ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Using loader.conf(5) 'exec' directive to set video mode
On 5/20/19 9:46 AM, Markus Graf wrote: Hello Anthony, I know I am not technically answering your question. Just in case you don't really care about the resolution but want bigger fonts. You can get nice big letters by setting: fontb32=terminus-b32.fnt font8x16=terminus-b32.fnt font8x8=terminus-b32.fnt in rc.conf Thanks Markus, That solution will work for when init(8) runs the RC scripts, but doesn't get me bigger text when the loader and kernel are spewing messages. But that is better than nothing, and will at least allow me to use vt(4) again without a magnifying glass. Best regards Markus Anthony Jenkins via freebsd-x11 writes: I'm running (a somewhat dated) FreeBSD 13.0-CURRENT (git commit 68c8581f7, Tue. Feb 12 13:01:55 2019) on a UEFI laptop with an Intel UHD display, booting a ZFS root filesystem (gptzfsboot(8)). CORRECTION: I installed (merged) /boot/boot1.efifat in the existing EFI system partition; I didn't install /boot/gptzfsboot into a freebsd-boot partition. Reference: https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot#Manually_Installing_FreeBSD_on_ZFS I'm trying to get the console into a lower resolution than the native UHD when the kernel is booted. I can manually do this by breaking into the loader prompt at boot and entering 'mode 1', then 'boot'. loader.conf(5) says I can run this command automatically with the 'exec' directive, but the video mode doesn't change. $ sudo cat /boot/loader.conf Password: autoboot_delay="3" #boot_single="YES" boot_verbose="YES" kern.timecounter.hardware="HPET" hw.psm.synaptics_support="1" kern.vty="vt" hw.vga.textmode="1" efi_max_resolution="1920x1080" exec="mode 1" I've also tried using directive 'efi_max_resolution' - same result. Does 'exec' work on my configuration (UEFI boot, ZFS root), or am I not using it right? I've tried putting other loader commands in 'exec' with no effect. Same question for efi_max_resolution. A separate question (possibly for graphics@ or x11@) is when the i915(4) kernel module from the graphics/drm-current-kmod port is loaded by rc.conf(4)'s 'kld_list' variable. When I do manually set the console resolution using 'mode 1', it is reset to maximum resolution when i915(4) is loaded. Thanks in advance, Anthony Jenkins ___ freebsd-...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Using loader.conf(5) 'exec' directive to set video mode
I'm running (a somewhat dated) FreeBSD 13.0-CURRENT (git commit 68c8581f7, Tue. Feb 12 13:01:55 2019) on a UEFI laptop with an Intel UHD display, booting a ZFS root filesystem (gptzfsboot(8)). I'm trying to get the console into a lower resolution than the native UHD when the kernel is booted. I can manually do this by breaking into the loader prompt at boot and entering 'mode 1', then 'boot'. loader.conf(5) says I can run this command automatically with the 'exec' directive, but the video mode doesn't change. $ sudo cat /boot/loader.conf Password: autoboot_delay="3" #boot_single="YES" boot_verbose="YES" kern.timecounter.hardware="HPET" hw.psm.synaptics_support="1" kern.vty="vt" hw.vga.textmode="1" efi_max_resolution="1920x1080" exec="mode 1" I've also tried using directive 'efi_max_resolution' - same result. Does 'exec' work on my configuration (UEFI boot, ZFS root), or am I not using it right? I've tried putting other loader commands in 'exec' with no effect. Same question for efi_max_resolution. A separate question (possibly for graphics@ or x11@) is when the i915(4) kernel module from the graphics/drm-current-kmod port is loaded by rc.conf(4)'s 'kld_list' variable. When I do manually set the console resolution using 'mode 1', it is reset to maximum resolution when i915(4) is loaded. Thanks in advance, Anthony Jenkins ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ath10k driver status?
th10k_core_register_work () from /boot/modules/if_athp.ko #22 0x807ca6ac in taskqueue_run_locked (queue=0xf80002ced800) at /usr/src/sys/kern/subr_taskqueue.c:467 #23 0x807cb628 in taskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_taskqueue.c:773 #24 0x80730354 in fork_exit (callout=0x807cb5a0 , arg=0xfe00b6c8c078, frame=0xfe00aa8279c0) at /usr/src/sys/kern/kern_fork.c:1053 --Type for more, q to quit, c to continue without paging-- #25 Thanks, Anthony Jenkins ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Composite PCI devices in FreeBSD (mfd in Linux)
On 12/19/18 10:41 AM, Anthony Jenkins wrote:
[snip]
I'm not feeling too confident about the condition of the FreeBSD ig4
driver; the PCI attach code was calling pci_alloc_msi() wrong, passing
a pointer to the rid (0) instead of a pointer to a count variable, and
not passing bus_alloc_resource_any() an IRQ rid > 0 if it has an MSI.
I'd be happy(er) if ig4 created a /dev/iic0 node - I figured iicbus(4)
took care of all that...
https://github.com/ScoobiFreeBSD/freebsd-intel-lpss
Found it! I didn't declare ig4_iic to include the ig4_lpss as a
sub-device. Now it at least /looks/ like I'm getting I2C devices found
on both my DesignWare I2C busses.
diff --git a/sys/dev/ichiic/ig4_iic.c b/sys/dev/ichiic/ig4_iic.c
index 6bbe417..34c1adb 100644
--- a/sys/dev/ichiic/ig4_iic.c
+++ b/sys/dev/ichiic/ig4_iic.c
@@ -802,3 +802,4 @@ ig4iic_dump(ig4iic_softc_t *sc)
DRIVER_MODULE(iicbus, ig4iic_acpi, iicbus_driver, iicbus_devclass,
NULL, NULL);
DRIVER_MODULE(iicbus, ig4iic_pci, iicbus_driver, iicbus_devclass,
NULL, NULL);
+DRIVER_MODULE(iicbus, ig4iic_lpss, iicbus_driver, iicbus_devclass,
NULL, NULL);
ajenkins@ajenkins-delllaptop ~/Projects/freebsd-intel-lpss (master)
$ ls /dev/ii*
/dev/iic0 /dev/iic1
ajenkins@ajenkins-delllaptop ~/Projects/freebsd-intel-lpss (master)
$ for i2cbus in iic0 iic1; do sudo i2c -s -f "/dev/${i2cbus}"; done
Hardware may not support START/STOP scanning; trying less-reliable read
method.
Scanning I2C devices on /dev/iic0: 0a
Hardware may not support START/STOP scanning; trying less-reliable read
method.
Scanning I2C devices on /dev/iic1: 2c
Anthony
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Composite PCI devices in FreeBSD (mfd in Linux)
On 12/10/18 3:57 PM, John Baldwin wrote:
On 12/10/18 12:19 PM, Ian Lepore wrote:
On Mon, 2018-12-10 at 14:42 -0500, Anthony Jenkins wrote:
On 12/10/18 1:26 PM, John Baldwin wrote:
On 12/10/18 9:00 AM, Anthony Jenkins wrote:
Hi all,
I'm trying to port an Intel PCI I2C controller from Linux to
FreeBSD.
Linux represents this device as an MFD (multi-function device),
meaning
it has these "sub-devices" that can be handed off to other
drivers to
actually attach devices to the system. The Linux "super" PCI
device is
the intel-lpss-pci.c, and the "sub" device is i2c-designware-
platdrv.c,
which represents the DesignWare driver's "platform" attachment to
the
Linux system. FreeBSD also has a DesignWare I2C controller
driver,
ig4(4), but it only has PCI and ACPI bus attachment
implementations.
I have a port of the Linux intel-lpss driver to FreeBSD, but now
I'm
trying to figure out the best way to give FreeBSD's ig4(4) driver
access
to my lpss(4) device. I'm thinking I could add an ig4_lpss.c
describing
the "attachment" of an ig4(4) to an lpss(4). Its probe() method
would
scan the "lpss" devclass for devices, and its attach() method
would
attach itself as a child to the lpss device and "grab" the
portion of
PCI memory and the IRQ that the lpss PCI device got.
Is this the "FreeBSD Way (TM)" of handling this type of device?
If not,
can you recommend an existing FreeBSD driver I can model my code
after?
If my approach is acceptable, how do I fully describe the ig4(4)
device's attachment to the system? Is simply making it a child
of
lpss(4) sufficient? It's "kind of" a PCI device (it is
controlled via
access to a PCI memory region and an IRQ), but it's a sub-device
of an
actual PCI device (lpss(4)) attached to PCI.
How would my ig4_lpss attachment get information from the lpss(4)
driver
about what it probed?
There are some existing PCI drivers that act as "virtual" busses
that attach
child devices. For example, vga_pci.c can have drm, agp, and
acpi_video
child devices. There are also some SMBus drivers that are also
PCI-ISA
bridges and thus create separate child devices.
Yeah I was hoping to avoid using video PCI devices as a model, as
complex as they've gotten recently. I'll check out its bus glue
logic.
For a virtual bus like this, you need to figure out how your child
devices
will be enumerated. A simple way is to let child devices use an
identify
routine that looks at each parent device and decides if a child
device
for that driver makes sense. It can then add a child device in the
identify routine.
Really an lpss parent PCI parent device can only have the following:
* one of {I2C, UART, SPI} controller
* optionally an IDMA64 controller
so I was thinking a child ig4(4) device would attach to lpss iff
* the lpss device detected an I2C controller
* no other ig4 device is already attached
I haven't fiddled with identify() yet, will look at that tonight.
If this is just another "bus" an ig4 instance can attach to, I'd think
the recipe would be to add another DRIVER_MODULE() to ig4_iic.c naming
ig4_lpss as the parent. Then add a new ig4_lpss.c modeled after the
existing pci and acpi attachment code, its DRIVER_MODULE() would name
lpss as parent, and its probe routine would return BUS_PROBE_NOWILDCARD
(attach only if specifically added by the parent).
Then there would be a new lpss driver that does the resource managment
stuff mentioned above, and if it detects configuration for I2C it would
do a device_add_child(lpssdev, "ig4_lpss", -1) followed by
bus_generic_attach(). There'd be no need for identify() in the child in
that case, I think.
But take jhb's word over mine on any of this stuff, he's been around
since the days when these mechanisms were all invented, whereas I tend
to cut and paste that bus and driver attachment stuff in semi-ignorance
when I'm working on drivers.
Doing the device_add_child in the parent driver's attach routine is also
fine instead of using an identify routine. It's mostly a matter of which
driver should be in charge of adding the child device (e.g. would you want
lpss self-contained or should the parent driver know about it explicitly).
If you have an existing ig4 driver you are going to reuse, then you will
need to ensure you fake up the resource stuff so that the existing code
works perhaps, though that depends on where the bus_alloc_resource calls
occur. If they are in shared code you have to fake more. If they are in
the bus-specific attach routines, then you can just put lpss specific
logic in the lpss-specific attach routine.
To handle things like resources, you want to have
bus_*_resource methods that let your child device use the normal
bus_*
functions to allocate resources. At the simplest end you don't
need to
permit any sharing of BARs among multiple children so you can just
proxy
the requests in the &quo
Re: Composite PCI devices in FreeBSD (mfd in Linux)
On 12/11/18 9:02 AM, Emiel Kollof wrote: Anthony Jenkins schreef op 2018-12-10 18:00: Hi all, I'm trying to port an Intel PCI I2C controller from Linux to FreeBSD. Linux represents this device as an MFD (multi-function device), meaning it has these "sub-devices" that can be handed off to other drivers to actually attach devices to the system. The Linux "super" PCI device is the intel-lpss-pci.c, and the "sub" device is i2c-designware-platdrv.c, which represents the DesignWare driver's "platform" attachment to the Linux system. FreeBSD also has a DesignWare I2C controller driver, ig4(4), but it only has PCI and ACPI bus attachment implementations. Might this also be relevant for i2c-hid devices, like some touchpads (Elantech for example)? Theoretically, yes. Once this I2C controller is added, then the parallel effort to add support for I2C HID devices should add support for Elantech I2C touchpads. The bit I'm doing (support for an Intel MFD I2C controller) is based on an old thread on mobile@. I just recently obtained a laptop that has a couple such I2C controllers (touchpad works, but touchscreen doesn't). Original Elantech touchpad support thread - https://lists.freebsd.org/pipermail/freebsd-mobile/2017-August/013617.html FreeBSD i2c-hid support - https://reviews.freebsd.org/D16698 Anthony Cheers, Emiel ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Composite PCI devices in FreeBSD (mfd in Linux)
On 12/10/18 1:26 PM, John Baldwin wrote:
On 12/10/18 9:00 AM, Anthony Jenkins wrote:
Hi all,
I'm trying to port an Intel PCI I2C controller from Linux to FreeBSD.
Linux represents this device as an MFD (multi-function device), meaning
it has these "sub-devices" that can be handed off to other drivers to
actually attach devices to the system. The Linux "super" PCI device is
the intel-lpss-pci.c, and the "sub" device is i2c-designware-platdrv.c,
which represents the DesignWare driver's "platform" attachment to the
Linux system. FreeBSD also has a DesignWare I2C controller driver,
ig4(4), but it only has PCI and ACPI bus attachment implementations.
I have a port of the Linux intel-lpss driver to FreeBSD, but now I'm
trying to figure out the best way to give FreeBSD's ig4(4) driver access
to my lpss(4) device. I'm thinking I could add an ig4_lpss.c describing
the "attachment" of an ig4(4) to an lpss(4). Its probe() method would
scan the "lpss" devclass for devices, and its attach() method would
attach itself as a child to the lpss device and "grab" the portion of
PCI memory and the IRQ that the lpss PCI device got.
Is this the "FreeBSD Way (TM)" of handling this type of device? If not,
can you recommend an existing FreeBSD driver I can model my code after?
If my approach is acceptable, how do I fully describe the ig4(4)
device's attachment to the system? Is simply making it a child of
lpss(4) sufficient? It's "kind of" a PCI device (it is controlled via
access to a PCI memory region and an IRQ), but it's a sub-device of an
actual PCI device (lpss(4)) attached to PCI.
How would my ig4_lpss attachment get information from the lpss(4) driver
about what it probed?
There are some existing PCI drivers that act as "virtual" busses that attach
child devices. For example, vga_pci.c can have drm, agp, and acpi_video
child devices. There are also some SMBus drivers that are also PCI-ISA
bridges and thus create separate child devices.
Yeah I was hoping to avoid using video PCI devices as a model, as
complex as they've gotten recently. I'll check out its bus glue logic.
For a virtual bus like this, you need to figure out how your child devices
will be enumerated. A simple way is to let child devices use an identify
routine that looks at each parent device and decides if a child device
for that driver makes sense. It can then add a child device in the
identify routine.
Really an lpss parent PCI parent device can only have the following:
* one of {I2C, UART, SPI} controller
* optionally an IDMA64 controller
so I was thinking a child ig4(4) device would attach to lpss iff
* the lpss device detected an I2C controller
* no other ig4 device is already attached
I haven't fiddled with identify() yet, will look at that tonight.
To handle things like resources, you want to have
bus_*_resource methods that let your child device use the normal bus_*
functions to allocate resources. At the simplest end you don't need to
permit any sharing of BARs among multiple children so you can just proxy
the requests in the "real" PCI driver. (vga_pci.c does this) If you need
the BARs to be shared you have a couple of options such as just using a
refcount on the BAR resource but letting multiple devices allocate the same
BAR. If you want to enforce exclusivity (once a device allocates part of
a BAR then other children shouldn't be permitted to do so), then you will
need a more complicated solution.
Another homework assignment for me - bus_*_resource methods.
There are 2 or 3 mutually-exclusive sub-regions in the single memory BAR:
* 0x000 - 0x200 : I2C sub-device registers
* 0x200 - 0x300 : lpss and I2C sub-device registers
* 0x800 - 0x1000 : IDMA sub-device registers (optional)
The only child (ig4(4)) of a given parent lpss device would at most need
to share access to the middle region, if at all.
Hopefully that gives you a starting point?
Oh definitely, thanks! If successful, and the effort to support I2C HID
devices also comes in, it should enable a bunch of laptops to use more
stuff like touchscreens and touchpads that are currently broken in
FreeBSD (I'm pretty sure one of my laptop's 2 lpss devices is a
touchscreen I2C device).
Anthony
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Composite PCI devices in FreeBSD (mfd in Linux)
Hi all, I'm trying to port an Intel PCI I2C controller from Linux to FreeBSD. Linux represents this device as an MFD (multi-function device), meaning it has these "sub-devices" that can be handed off to other drivers to actually attach devices to the system. The Linux "super" PCI device is the intel-lpss-pci.c, and the "sub" device is i2c-designware-platdrv.c, which represents the DesignWare driver's "platform" attachment to the Linux system. FreeBSD also has a DesignWare I2C controller driver, ig4(4), but it only has PCI and ACPI bus attachment implementations. I have a port of the Linux intel-lpss driver to FreeBSD, but now I'm trying to figure out the best way to give FreeBSD's ig4(4) driver access to my lpss(4) device. I'm thinking I could add an ig4_lpss.c describing the "attachment" of an ig4(4) to an lpss(4). Its probe() method would scan the "lpss" devclass for devices, and its attach() method would attach itself as a child to the lpss device and "grab" the portion of PCI memory and the IRQ that the lpss PCI device got. Is this the "FreeBSD Way (TM)" of handling this type of device? If not, can you recommend an existing FreeBSD driver I can model my code after? If my approach is acceptable, how do I fully describe the ig4(4) device's attachment to the system? Is simply making it a child of lpss(4) sufficient? It's "kind of" a PCI device (it is controlled via access to a PCI memory region and an IRQ), but it's a sub-device of an actual PCI device (lpss(4)) attached to PCI. How would my ig4_lpss attachment get information from the lpss(4) driver about what it probed? Thanks, Anthony Jenkins References: - intel-lpss.c - https://github.com/torvalds/linux/blob/master/drivers/mfd/intel-lpss.c - intel-lpss-pci.c - https://github.com/torvalds/linux/blob/master/drivers/mfd/intel-lpss-pci.c - i2c-designware-platdrv.c - https://github.com/torvalds/linux/blob/master/drivers/i2c/busses/i2c-designware-platdrv.c - "mfd: introduce a driver for LPSS devices on SPT" - https://lwn.net/Articles/645819/ - FreeBSD port - https://github.com/ScoobiFreeBSD/freebsd-intel-lpss ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: EVDEV support in psm(4) driver
I'm seeing flakiness in X11 (KDE) with evdev enabled - a couple keys are reporting multiple (wrong) events and some aren't emitting any events (or they are, but they're NoSymbol): - Down arrow: emits KeyPress for keycode 116 (Super_R), KeyRelease for keycode 116, KeyRelease for keycode 104 (Down) - Left arrow: emits KeyPress for keycode 113 (Alt_R), KeyPress for keycode 100 (Left), KeyRelease for keycode 113, KeyRelease for keycode 100 - Volume up: emits KeyPress 123 (NoSymbol), KeyPress 176 (NoSymbol), KeyRelease for same - Volume down: emits KeyPress 122 (NoSymbol), KeyPress 174 (NoSymbol), KeyRelease for same - Volume mute toggle: emits KeyPress 121 (NoSymbol), KeyRelease 121 (NoSymbol), KeyRelease 140 (NoSymbol) - Keypad end: emits KeyPress 115 (Super_L), KeyPress 103 (End), KeyRelease for same I'll attach the output of 'evdev -event keyboard' for everything but the Keypad end key which I recently found. /usr/local/etc/X11/xorg.conf.d/evdev1.conf: Section "InputDevice" Identifier "Keyboard0" Driver "evdev" Option "Device" "/dev/input/event1" EndSection dmesg | grep kbd: [ajenkins@ajenkins-hplaptop ~]$ dmesg | grep kbd kbd: new array size 4 kbd1 at kbdmux0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d atkbd0: [GIANT-LOCKED] random: harvesting attach, 8 bytes (4 bits) from atkbd0 random: harvesting attach, 8 bytes (4 bits) from atkbdc0 kbdc: TEST_AUX_PORT status: kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID: kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID: psm0: irq 12 on atkbdc0 atkbdc: atkbdc0 already exists; skipping it /var/log/Xorg.0.log stuff: [24.763] (**) Option "config_info" "udev:/dev/input/event1" [24.763] (II) XINPUT: Adding extended input device "System keyboard multiplexer" (type: KEYBOARD, id 7) [24.763] (**) Option "xkb_rules" "evdev" [24.839] (II) config/udev: Adding input device AT keyboard (/dev/input/event2) [24.839] (**) AT keyboard: Applying InputClass "evdev keyboard catchall" [24.839] (II) Using input driver 'evdev' for 'AT keyboard' [24.839]Option "_source" "server/udev" [24.839]Option "name" "AT keyboard" [24.839]Option "path" "/dev/input/event2" [24.839]Option "device" "/dev/input/event2" [24.839]Option "major" "0" [24.839]Option "minor" "45" [24.839]Option "driver" "evdev" [24.839]Option "config_info" "udev:/dev/input/event2" [24.839] (**) AT keyboard: always reports core events [24.839] (**) evdev: AT keyboard: Device: "/dev/input/event2" [24.839] (--) evdev: AT keyboard: Vendor 0x1 Product 0x1 [24.839] (--) evdev: AT keyboard: Found keys [24.839] (II) evdev: AT keyboard: Configuring as keyboard [24.839] (**) Option "config_info" "udev:/dev/input/event2" [24.840] (II) XINPUT: Adding extended input device "AT keyboard" (type: KEYBOARD, id 8) [24.840] (**) Option "xkb_rules" "evdev" [24.840] (II) XKB: Reusing cached keymap [24.840] (II) config/udev: Adding input device Synaptics Touchpad (/dev/input/event3) [24.841] (**) Synaptics Touchpad: Applying InputClass "evdev pointer catchall" [24.841] (**) Synaptics Touchpad: Applying InputClass "evdev touchpad catchall" [24.841] (**) Synaptics Touchpad: Applying InputClass "touchpad catchall" [24.841] (**) Synaptics Touchpad: Applying InputClass "Default clickpad buttons" [24.841] (II) LoadModule: "synaptics" [24.841] (II) Loading /usr/local/lib/xorg/modules/input/synaptics_drv.so [24.842] (II) Module synaptics: vendor="X.Org Foundation" [24.842]compiled for 1.19.3, module version = 1.9.0 [24.842]Module class: X.Org XInput Driver [24.843]ABI class: X.Org XInput driver, version 24.1 [24.843] (II) Using input driver 'synaptics' for 'Synaptics Touchpad' [24.843]Option "_source" "server/udev" [24.843]Option "name" "Synaptics Touchpad" [24.843]Option "path" "/dev/input/event3" [24.843]Option "device" "/dev/input/event3" [24.843]Option "major" "0" [24.843]Option "minor" "50" [24.843]Option "driver" "synaptics" Not sure what else to
Re: loader and load: path?
set module_path /boot/kernel # ? I don't think module_path is set to its default "/boot/kernel;/boot/modules" when booting to loader(8) prompt... Anthony Jenkins From: Steven Hartland <kill...@multiplay.co.uk> To: freebsd-current@freebsd.org Sent: Monday, March 7, 2016 9:18 AM Subject: Re: loader and load: path? So your saying "kldload zfs" fails because it can't find opensolaris or are you giving it absolute paths? If so try without absolute paths. Regards Steve On 07/03/2016 14:09, Larry Rosenman wrote: > If I type load /boot/kernel/kernel, and then load /boot/kernel/zfs.ko, > the loader > (loader.efi in this case) says it can't find opensolaris. Same for > dtraceall, where > it can't find it's dependent modules. Just hitting enter does the > right thing. > > What variable(s) am I missing? > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI boot issues on HP laptop
On 03/03/2016 09:39 AM, Jakob Alvermark wrote:
> Hi,
>
> On Thu, March 3, 2016 14:46, Anthony Jenkins wrote:
>
>> The other issue is just me being jealous of EFI Linux showing up in a
>> toplevel BIOS boot menu:
>>
>> Selecting "F9 - Boot Device Options" goes to the "Boot Manager" screen:
>>
>>
>> Boot Option Menu
>>
>>
>> - OS boot Manager
>> - ubuntu (MKNSSDRE1TB)
>> - Boot From EFI File
>> - Notebook Hard Drive
>>
>>
>>
>> How did Ubuntu get in there? Some attribute of its EFI boot file that
>> tells the BIOS (or boot manager EFI app) to add an entry for it? How do I
>> get FreeBSD in there?
> You can modify the this from Windows, using the command line tool 'bcdedit'.
> That's what I did on my Thinkpad.
>
> From administrator command prompt, 'bcedit /enum all' will show you
> something like this at the top:
>
> Firmware Boot Manager
> -
> identifier {fwbootmgr}
> displayorder{5d090d98-8e36-11e5-827b-806e6f6e6963}
> {f43a1eb3-82e3-11e5-8252-94659c6abc55}
> {bootmgr}
> {4a919591-82e1-11e5-a7d6-806e6f6e6963}
> {4a919592-82e1-11e5-a7d6-806e6f6e6963}
> {4a919593-82e1-11e5-a7d6-806e6f6e6963}
> {4a919594-82e1-11e5-a7d6-806e6f6e6963}
> {4a919595-82e1-11e5-a7d6-806e6f6e6963}
> {4a919596-82e1-11e5-a7d6-806e6f6e6963}
> {4a919590-82e1-11e5-a7d6-806e6f6e6963}
> timeout 0
>
> Windows Boot Manager
>
> identifier {bootmgr}
> device partition=\Device\HarddiskVolume2
> path\EFI\Microsoft\Boot\bootmgfw.efi
> description Windows Boot Manager
> locale en-US
> inherit {globalsettings}
> integrityservices Enable
> default {current}
> resumeobject{f43a1eac-82e3-11e5-8252-94659c6abc55}
> displayorder{current}
> toolsdisplayorder {memdiag}
> timeout 30
>
> You can add new entries to the displayorder, and they should show up in
> your boot options.
>
> I have added theese two:
> Firmware Application (101f)
> ---
> identifier {5d090d98-8e36-11e5-827b-806e6f6e6963}
> device partition=\Device\HarddiskVolume2
> path\EFI\BSD\freebsd.efi
> description FreeBSD
>
> Firmware Application (101f)
> ---
> identifier {f43a1eb3-82e3-11e5-8252-94659c6abc55}
> device partition=\Device\HarddiskVolume2
> path \EFI\BSD\openbsd.efi
> description OpenBSD
>
> So I have FreeBSD booting by default, and I can boot OpenBSD and Windows
> as second and third choices, respectively.
>
> Hope to get you in the right direction with this.
>
> Jakob
Wow, awesome! Will try this today, thanks!
--
Anthony Jenkins
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
UEFI boot issues on HP laptop
First of all, thanks to everyone who got FreeBSD's UEFI + ZFS boot working, I'm now triple-booting FreeBSD, Kubuntu Linux and my HP laptop's native Windows 10 (all 3 spread among about 13 GPT partitions including an EFI partition). I have a couple issues - an EFI configuration disables some devices and FreeBSD's EFI boot file not showing up in boot menu. Until recently I booted FreeBSD by bringing up the BIOS boot menu, selecting "F9 - Boot Device Options" -> "Boot From EFI File" and navigating to \EFI\FreeBSD\boot1.efi on the EFI partition. Yesterday I decided to replace the default EFI boot file (apparently \EFI\Microsoft\Boot\bootmgfw.efi) with FreeBSD's EFI boot file, which works... /sorta/. If I allow the machine to boot, FreeBSD comes up with no need for me to interact with the BIOS, but several devices no longer work - my Intel 3160 PCIe wireless card and my eGalax USB touchscreen are non-responsive. They're both /detected/ on their respective busses and their drivers are loaded, but touching the screen no longer moves the cursor in KDE4 and I cannot connect to an access point. I can 'cat /dev/input/event0' and see data when I touch the screen, and I can 'ifconfig wlan0 list scan' to see broadcasting APs, which is weird. Anyone know what's going on? I'm assuming HP Support won't help me out with this sort of issue. To be accurate, I copied the FreeBSD EFI boot file to two places \EFI\Boot\bootx64.efi (I thought BIOSes booted this file by default) and \EFI\Microsoft\Boot\bootmgfw.efi. The other issue is just me being jealous of EFI Linux showing up in a toplevel BIOS boot menu: Selecting "F9 - Boot Device Options" goes to the "Boot Manager" screen: Boot Option Menu - OS boot Manager - ubuntu (MKNSSDRE1TB) - Boot From EFI File - Notebook Hard Drive How did Ubuntu get in there? Some attribute of its EFI boot file that tells the BIOS (or boot manager EFI app) to add an entry for it? How do I get FreeBSD in there? Thanks! -- Anthony Jenkins ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Touchscreen support (was Re: new computer, strange usb messages at boot)
On 02/22/2016 11:51 AM, Hans Petter Selasky wrote: > On 02/22/16 17:39, Anthony Jenkins wrote: >> >> >> On 02/22/2016 02:11 AM, Hans Petter Selasky wrote: >>> On 02/22/16 03:16, Anthony Jenkins wrote: >>>> Yes. I have an eGalax touchscreen and it's doing the same thing. The >>>> number of items it's reporting is 256 (according to my preliminary >>>> debugging), causing the warning. I think these things are a special >>>> subclass of HID for multitouch touchscreens which we don't support >>>> (yet). >>> >>> /usr/ports/multimedia/webcamd will most likely attach if invoked >>> manually, to this device and provide an event device for you! >>> >>> --HPS >> >> Okay that's /amazing/, and not at all intuitive! I mean I'd expect >> multimedia/webcamd to only attach to "video" devices, but lo and behold >> I get a /dev/input/event0 device which spits out gibberish when >> cat(1)'ed and I touch the screen! >> >> My intentions were to port Linux's hid-multitouch device in whole to >> FreeBSD (it's what attaches to my eGalax device and probably to OP's >> touchscreen device) and add support for the device to moused(8), but >> it's not very high on my priority list... >> > > Hi, > > If you apply these patches, will work with your X-org :-) > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678 > > --HPS Well that's one of the higher priority items - Xorg doesn't work with my AMD Radeon video device and FreeBSD's drm2/radeonkms... I'm going to try the vesa driver today. -- Anthony Jenkins ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Touchscreen support (was Re: new computer, strange usb messages at boot)
On 02/22/2016 02:11 AM, Hans Petter Selasky wrote: > On 02/22/16 03:16, Anthony Jenkins wrote: >> Yes. I have an eGalax touchscreen and it's doing the same thing. The >> number of items it's reporting is 256 (according to my preliminary >> debugging), causing the warning. I think these things are a special >> subclass of HID for multitouch touchscreens which we don't support >> (yet). > > /usr/ports/multimedia/webcamd will most likely attach if invoked > manually, to this device and provide an event device for you! > > --HPS Okay that's /amazing/, and not at all intuitive! I mean I'd expect multimedia/webcamd to only attach to "video" devices, but lo and behold I get a /dev/input/event0 device which spits out gibberish when cat(1)'ed and I touch the screen! My intentions were to port Linux's hid-multitouch device in whole to FreeBSD (it's what attaches to my eGalax device and probably to OP's touchscreen device) and add support for the device to moused(8), but it's not very high on my priority list... -- Anthony Jenkins ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: new computer, strange usb messages at boot
Yes. I have an eGalax touchscreen and it's doing the same thing. The number of items it's reporting is 256 (according to my preliminary debugging), causing the warning. I think these things are a special subclass of HID for multitouch touchscreens which we don't support (yet). Anthony Jenkins On 02/21/2016 11:28 AM, Larry Rosenman wrote: On 2016-02-20 06:24, Larry Rosenman wrote: uhid0: on usbus0 hid_get_item: Number of items truncated to 255 uhid1: on usbus0 hid_get_item: Number of items truncated to 255 hid_get_item: Number of items truncated to 255 hid_get_item: Number of items truncated to 255 Does this mean that the touch screen is hitting a limit in FreeBSD's driver? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpi suspend debugging techniques?
My Radeon card comes back from resume, but the backlight doesn't (it
stays off). Think this patch might help with that? I was gonna start a
separate thread to ask for help debugging my backlight issue...
Thanks,
Anthony
On 09/03/15 16:06, Adrian Chadd wrote:
> oioo, would you please put that radeon patch into a review?
>
> I have an older machine with a radeon card in it that doesn't yet
> suspend/resume; I can now test it out!
>
>
> -a
>
>
> On 3 September 2015 at 10:50, Andriy Gapon <a...@freebsd.org> wrote:
>> On 31/08/2015 11:53, Adrian Chadd wrote:
>>> Try disabling hardware one at a time. Ie, unload usb; unload wifi;
>>> leave kms loaded for mostly obvious reasons.
>> Adrian, Garrett,
>>
>> thank you very much for your tips.
>> Turned out that it was radeonkms that was causing the problem :-)
>>
>> BTW, here is another tool for the toolkit: on sufficiently recent system
>> devctl
>> suspend and devctl resume can be used to test individual drivers.
>>
>> So, I noticed that I could suspend/resume drmn0 device just fine but with
>> vgapci0 I had a trouble suspending. One thing led to another and here is a
>> patch that seems to fix the problem for me:
>> ---
>> commit fecb5e8a90631f06600d87165cc8b6de3e035dfc
>> Author: Andriy Gapon <a...@icyb.net.ua>
>> Date: Thu Sep 3 17:24:23 2015 +0300
>>
>> radeon_suspend_kms: don't mess with pci state that's managed by the bus
>>
>> The pci bus driver handles the power state and configuration state saving
>> and restoring for its child devices.
>>
>> diff --git a/sys/dev/drm2/radeon/radeon_device.c
>> b/sys/dev/drm2/radeon/radeon_device.c
>> index e5c676b11ed47..73b2f4c51ada2 100644
>> --- a/sys/dev/drm2/radeon/radeon_device.c
>> +++ b/sys/dev/drm2/radeon/radeon_device.c
>> @@ -1342,14 +1342,10 @@ int radeon_suspend_kms(struct drm_device *dev)
>>
>> radeon_agp_suspend(rdev);
>>
>> - pci_save_state(device_get_parent(dev->dev));
>> #ifdef FREEBSD_WIP
>> if (state.event == PM_EVENT_SUSPEND) {
>> /* Shut down the device */
>> pci_disable_device(dev->pdev);
>> -#endif /* FREEBSD_WIP */
>> - pci_set_powerstate(dev->dev, PCI_POWERSTATE_D3);
>> -#ifdef FREEBSD_WIP
>> }
>> console_lock();
>> #endif /* FREEBSD_WIP */
>> @@ -1380,10 +1376,6 @@ int radeon_resume_kms(struct drm_device *dev)
>>
>> #ifdef FREEBSD_WIP
>> console_lock();
>> -#endif /* FREEBSD_WIP */
>> - pci_set_powerstate(device_get_parent(dev->dev), PCI_POWERSTATE_D0);
>> - pci_restore_state(device_get_parent(dev->dev));
>> -#ifdef FREEBSD_WIP
>> if (pci_enable_device(dev->pdev)) {
>> console_unlock();
>> return -1;
>> ---
>>
>> However, I am not sure about an exact mechanism of the hard system hang that
>> I
>> experienced without the patch.
>>
>> BTW, I noticed that only very few drivers make explicit calls to
>> pci_set_powerstate and pci_save_state/pci_restore_state.
>> sys/dev/usb/controller/ohci_pci.c looks like a good use of
>> pci_set_powerstate.
>> sys/dev/ixgbe/if_ix.c looks like an incorrect / redundant use of the
>> functions.
>>
>> --
>> Andriy Gapon
> ___
> freebsd-a...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
--
Anthony Jenkins
Software Engineer
VTilt Digital, LLC
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Here's my most recent crash..
Alex Zepeda wrote: [ kdbg output removed] The most applicable dmesg output I could find was: Memory modified after free 0xc215d000(8188) panic: Most recently used by none I've gotten this same panic with a kernel+world cvsup'd from Sun Jul 21 23:43 EDT, just got one a few minutes ago. I'm in the kernel debugger since I haven't been able to get a dump to work since - well ever I guess :-/ so I'll echo Alex's offer to entertain any debugger requests. Interesting thing is the apparent page fault I got when I tried 'ps' at the db prompt: lock order reversal 1st 0xc4758160 process lock (process lock) @ /usr/src/sys/kern/kern_exec.c:335 2nd 0xc0314880 filelist lock (filelist lock) @ /usr/src/sys/kern/kern_descrip.c: /usr/src/sys/vm/uma_core.c:1332: could sleep with process lock locked from /usr/src/sys/kern/kern_exec.c:335 J/usr/src/sys/vm/uma_core.c:1332: could sleep with process lock locked from /usr/src/sys/kern/kern_exec.c:335 /usr/src/sys/vm/uma_core.c:1332: could sleep with process lock locked from /usr/src/sys/kern/kern_exec.c:335 Memory modified after free 0xc50e3d00(252) panic: Most recently used by kqueue cpuid = 0; lapic.id = 0100 Debugger(panic) Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 db ps pid proc addruid ppid pgrp flag stat wmesg wchan cmd 80562 c4883558 de3fd0000 80533 0 0006002 New Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = 0100 fault virtual address = 0x48 fault code = supervisor read, page not present instruction pointer = 0x8:0xc014111b stack pointer = 0x10:0xde26fa18 frame pointer = 0x10:0xde26fa28 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 80561 (sh) kernel: type 12 trap, code=0 Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 db show locks exclusive sleep mutex Giant r = 0 (0xc03179e0) locked @ /usr/src/sys/kern/kern_fork.c:119 db bt No such command db trace Debugger(c02e10fa) at Debugger+0x46 panic(c02f7408,c02ddda0,c02f73e0,c50e3d00,fc) at panic+0xde mtrash_ctor(c50e3d00,100,0) at mtrash_ctor+0x4c uma_zalloc_arg(c082dc00,0,0) at uma_zalloc_arg+0xff malloc(dc,c0314580,0,c50ffe00,1) at malloc+0x68 fdcopy(c467de40,c50ffe34,0,c02de191,1c9) at fdcopy+0x61 fork1(c467de40,14,de26fce0,c03179e0,0) at fork1+0x6c7 fork(c467de40,de26fd14,0,0,202) at fork+0x2a syscall(2f,2f,2f,80f23ac,80f23ac) at syscall+0x23c syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (2, FreeBSD ELF32, fork), eip = 0x8076bb3, esp = 0xbfbff30c, ebp = 0xbfbff328 --- db I'm anxious to get something working, at least the dump+gdb/gdb52 facility, so I can do some type of debugging; it's either that or kill the 150 day uptime FreeBSD-4.4 400MHz box and swap the two, but I was hoping to debug some SMP on the new box /whine. -- Anthony Jenkins http://www.mindspring.com/~abjenkins/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Here's my most recent crash..
Craig Dooley wrote: I have the same problem. heres my debug dump. It seems to happen to me always when sound is playing. I also get pages of warnings about pcm and could sleep with lock. /usr/src/sys/vm/uma_core.c:1332: could sleep with pcm0:play:0 locked from /usr/src/sys/dev/sound/pcm/dsp.c:690 /usr/src/sys/vm/uma_core.c:1332: could sleep with pcm0:play:0 locked from /usr/src/sys/dev/sound/pcm/dsp.c:713 /usr/src/sys/vm/uma_core.c:1332: could sleep with pcm0:play:0 locked from /usr/src/sys/dev/sound/pcm/sound.c:191 and so on. actually it's flooded dmesg enough that I cant get to any useful information without going back a couple message.x's. buildworld and kernel built from yesterdays sources. I've been looking into trying to fix the pcm code and it seems to be riddled with places where locks are held while sleepable memory allocations (the umacore.c:1332) are attempted. I mostly run without sound for now until I can get a grasp on where I can get away with not locking. Some locks are created and immediately locked, which to me only makes sense if the struct in which the lock exists is entered into a list where it's processed by some other KSE (I hope I'm not mangling these terms, I've only done Linux kernel work to-date). Is the pcm code maintainer looking into this also? -- Anthony Jenkins http://www.mindspring.com/~abjenkins/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic + lock order reversal (SMP Athlon)
System was cvsup'd yesterday afternoon: FreeBSD 5.0-CURRENT #4: Sun Jul 21 23:43:59 EDT 2002 ajenkins@foo:/usr/obj/usr/src/sys/MYKERNEL-5.0 Background fsck was started and I waited a decent amount of time after the login: prompt showed up before logging into root. Root (bash) prompt displayed after /etc/motd and immediately after the serial console gets the panic: Starting background filesystem checks Mon Jul 22 18:57:46 EDT 2002 lock order reversal 1st 0xc034aee0 sysctl sysctllock (sysctl sysctllock) @ /usr/src/sys/kern/kern_sysctl.c:1181 2nd 0xc03179e0 Giant (Giant) @ /usr/src/sys/dev/isp/isp_freebsd.c:2065 dev = da0s1g, block = 6657576, fs = /usr panic: ffs_blkfree: freeing free block cpuid = 1; lapic.id = Debugger(panic) Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 db trace Debugger(c02e10fa) at Debugger+0x46 panic(c02f0e00,c02f0de0,c41ca44c,659628,0) at panic+0xde ffs_blkfree(c41d0800,c41fa000,659628,0,4000) at ffs_blkfree+0x418 indir_trunc(c41a1a00,1966180,0,0,f600c,0,d6a3dc40) at indir_trunc+0x290 indir_trunc(c41a1a00,1964740,0,1,100c,0,d6a3dc40) at indir_trunc+0x26b handle_workitem_freeblocks(c41a1a00,0) at handle_workitem_freeblocks+0x1d0 process_worklist_item(0,0) at process_worklist_item+0x170 softdep_process_worklist(0) at softdep_process_worklist+0xb4 sched_sync(0,d6a3dd48,c1585c00,c01f69f4,0) at sched_sync+0x17e fork_exit(c01f69f4,0,d6a3dd48) at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x1a db locks No such command db show locks exclusive sleep mutex Giant r = 0 (0xc03179e0) locked @ /usr/src/sys/dev/isp/isp_freebsd.c:2065 db I just got my 2nd Athlon MP chip today, hopefully this is similar to the last time I crashed while in background fsck Let me know if any more info is needed, I'll play with the coredump a bit. -- Anthony Jenkins http://www.mindspring.com/~abjenkins/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Current (DP1) on Toshiba 5005
Rob Hughes wrote: All, I have a Toshiba 5005-S504 laptop (a wonderful legacy-free box that's I've cussed to no end) that I'm trying to get DP1 to boot on so I can cvsup and take a look (and hopefully contribute something). I was able to install, but after installation the system soft hangs after displaying a message about CPU power states (sorry, going off memory for now). I'm able to break to the debugger, so what information from dbg would be helpful at this point? Also, I'm pretty sure it's acpi that's causing the problem, so would someone point me to the syntax for disabling a module preload? Thanks, Rob I was tracking down a similar hang and had to disable acpi (turns out I'm an idiot and the apparent hang at boot was because I forgot console was redirected to the serial port of the machine next to it), but I had to jump through hoops to do it it seems. I believe all you have to do is 'unset acpi_load' at the boot loader prompt. I had tried 'set acpi_load=NO', and finally 'unset module_path' to keep the kernel from finding /boot/kernel/acpi.ko. Hope this helps, Anthony Jenkins To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE M-III status junior hacker project.
On Monday 2002-July-08 19:47, Don Lewis wrote: On 8 Jul, Anthony Jenkins wrote: I've been looking at the pcm code and I can see where it locks, then allocates memory with the M_WAITOK flag thing. I'm wondering if there's a standard procedure for fixing these... would I just nail down the malloc to a non-sleepable one? Only if the the code can cope with malloc() failing and returning NULL if the memory isn't immediately available. In most cases a better solution is to allocate the memory before grabbing the lock. Thanks... I'll take a look at this tonight after work. -- Anthony Jenkins To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE M-III status junior hacker project.
On Monday 2002-July-08 14:08, Josef Karthauser wrote: On a new kernel I appear to be getting dumps now (along with the crashes ;). Actually it's pretty stable, but there are random crashes occuring, usually I come back to the machine when I've not used it for a new hours and find it in rebooted and in the kernel debugging due to those pcm may sleep locked type things. I've been looking at the pcm code and I can see where it locks, then allocates memory with the M_WAITOK flag thing. I'm wondering if there's a standard procedure for fixing these... would I just nail down the malloc to a non-sleepable one? Also the lock could be freed before it's unlocked... is this okay? I'm guessing it is... mtx_assert(mtx, MA_OWNED); mtx_destroy(mtx); Every time I load my sound driver, top(1) shows the irq10 entry to be locked in *Giant state, and if I unload it and do a kldstat it's instant panic. I finally shelled out Radio Shack's ridiculous amount for a null modem cable and can do remote debugging now, but I can't remember the URL for that recent series of articles on getting started with CURRENT debugging...anyone? TIA, Anthony Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic at boot in ffs_valloc
I cvsup'd and built world+kernel a few hours ago and was happy to see KDE working again, but I got a spontaneous reboot while trying to track down a segfault in a mozilla build component. I boot -v'ed and as soon as the login prompt came up I hit a panic. I'm guessing the backgorund fsck had something to do with it. I'll hand-copy the trace here; any debugging info needed while my box is stuck at the debugger, lemme know: -- Anthony Jenkins Additional TCP options:. Starting background filesystem checks Wed Jul 3 13:24:09 EDT 2002 FreeBSD/i386 (foo) (ttyv0) login: mode = 041777, inum = 12871, fs = /usr panic: ffs_valloc: dup alloc cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 db trace Debugger(c02d9eda) at Debugger+0x46 panic(c02e9a21,c02e9a00,43ff,3247,c41c58d4) at panic+0xd6 ffs_valloc(c4284100,8100,c159a180,d6afd6f0) at ffs_valloc+0x141 ufs_makeinode(8100,c4284100,d6afda20,d6afda34) at ufs_makeinode+0x58 ufs_create(d6afd94c,d6afda68,c0248a68,d6afd94c,c0346b78) at ufs_create+0x26 ufs_vnoperate(d6afd94c) at ufs_vnoperate+0x13 ffs_snapshot(c41b7600,80b2ba0,d6afda94,c41db700,c0346bf0) at ffs_snapshot+0x2a0 ffs_mount(c41b7600,c4421200,bfbffcc0,d6afdbf8,c159f300) at ffs_mount+0x48 vfs_mount(c159f300,c41b2eb0,c4421200,1211000,bfbffcc0) at ffs_mount+0x6dc mount(c159f300,d6afdd14,4,1,202) at mount+0x6a syscall(2f,2f,2f,0,bfbffde0) at syscall+0x23c syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (21, FreeBSD ELF, mount), eip = 0x80549d7, esp = 0xbfbffbdc, ebp = 0xbfbffd48 --- db -- Anthony Jenkins http://www.mindspring.com/~abjenkins/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: memory/swapping problem
Wm Brian McCane wrote: I am having a problem with a new server that I am setting up to host my UseNet news and email. Machine: 1.26GHz 512MB/L1 Cache 768MB PC133 Memory 4x60GB UDMA100 IDE Drives 4x36GB 160MBit SCSI Drives OS:5.0-CURRENT (yes I know, but I have been CURRENT since 386bsd 0.1) Software: INN 2.3.3 Sendmail w/amavisd milter ipop3d This machine has been running for about 2 months on CURRENT with no problems, but I recently upgraded the CPU from an 866 to the new one. At that time, I also planned to replace the motherboard with a new Intel SAI2 dual processor board, add a 2nd processor and drop in 3x512MB ECC Registered DIMMs. So I built and installed a more current CURRENT and added SMP to the config for my kernel. The motherboard was defective, so I put back in the original board and memory chips, while I wait for the replacement board. The 2nd night after the build was done, I started having memory/swap/wired problems. I rebuilt the kernel for UP operation, but the problems have not gone away. Machine averages about 95% idle all day except during news expiration. For the first day, it averages around 45M wired. 'inn' process is about 137MB RSS. During expiration there is an understandable spike in CPU and Swap activity. 'expire' process is about 259MB RSS. When the expiration completes there is about 254MB still wired. The second night it goes to 500+MB wired and the system never finishes expiration before I get a call that email is down. I have actually gone out and killed every process running on the machine that I can (including inetd, syslogd, cron, sshd, sendmail and inn). The wired memory is never released until I reboot the machine. The only issue that I've had that remotely resembles that involes CPU usage, not memory. Assuming your statistics are from top(1), can you try 'top -S' to display what system process resources are also? I'm betting it's some system task, since your killing user processes has had no effect. (btw my issue is the irq10: task seemingly locked in *Giant state and sucking 50% the CPU/WCPU measure.) -- Anthony Jenkins To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Still having problems with snd_emu10k1/ohci irq10 + cpu usage
0xea002000-0xea002fff usb1: OHCI version 1.0, legacy support usb1: OPTi 82C861 (FireLink) USB controller on ohci1 usb1: USB revision 1.0 uhub1: OPTi OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered su-2.05a# kldstat Id Refs AddressSize Name 16 0xc010 2e448c kernel 41 0xc0407000 39a88acpi.ko 51 0xde2d7000 7000 ipfw.ko 61 0xde282000 2000 green_saver.ko 101 0xe0e1a000 1a000usb.ko su-2.05a# kldunload -i 10 kldunload: can't unload file: Device not configured I'm fairly decent at C programming and Linux kernel development, and trying to become more adept at FreeBSD kernel work, so any debugging suggestions or requests for more info would be greatly appreciated. TIA, Anthony Jenkins To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: High interrupt usage in system (ohci and/or pcm?)
Compiled the USB out of the kernel and have *much* better
responsiveness. I have a 4-port PCI USB OHCI controller card installed.
With both the USB and pcm modules unloaded the irq10 handler seems to
fall to 0% usage, but if I load snd_emu10k1.ko it pops right back up to
60% in top(1), regardless of whether I'm using the device or not.
Luckily this mouse has a USB-to-PS/2 adapter. Guess I don't need sound
or USB
Anthony
Anthony Jenkins wrote:
Hi,
Ever since cvsup'ing/building a new kernel a couple weeks ago I've had
ridiculously high interrupt state percentages shown in top(1), from
70%-98%. My system (1 Athlon MP 1800+, Tyan 2466 dual board, 512MB,
SMP kernel) is running at about 20% of its previous responsiveness.
Running single-user mode offers no change to the high interrupt state
measure. I cvsup'd yesterday and installed world+kernel, but no luck.
I'll post my kernel config below, with most comment/blank lines
removed for space, as well as my dmesg output.
Okay, looking at 'ps axlww' shows the ochi1 and pcm drivers with '263'
in the CPU column... setiathome is a measly 119:
026 0 263 -64 0 03 - RL?? 157:51.30
(irq10: ohci1 pcm0)
I load pcm through the loader(8) mechanism using a pcm_load=YES line
in /boot/loader.conf, but it had always been sane before; ohci is in
kernel config. My USB devices are a MS Intellimouse and an IBM webcam
(this is a dual-boot box now). Any other tools I can use to determine
where my cycles are going?
Okay, I killed X and unloaded the pcm driver and usage is around
64-67% in interrupt state, and a bit more responsive, but the ohci
listing in ps(1) still seems to be the culprit:
026 0 242 -64 0 03 Giant ML?? 164:54.23
(irq10: ohci1)
It seems that 8 out of 9 times I get Giant ML in the listing...
probably related to the several warnings I get on console? Here's
some output from dmesg(8):
/usr/src/sys/vm/uma_core.c:1330: could sleep with pcm0:play:0 locked
from /usr/src/sys/dev/sound/pcm/sound.c:191
/usr/src/sys/vm/uma_core.c:1330: could sleep with pcm0:record:0
locked from /usr/src/sys/dev/sound/pcm/sound.c:191
/usr/src/sys/vm/uma_core.c:1330: could sleep with pcm0:play:0 locked
from /usr/src/sys/dev/sound/pcm/sound.c:191
/usr/src/sys/vm/uma_core.c:1330: could sleep with pcm0:record:0
locked from /usr/src/sys/dev/sound/pcm/sound.c:191
...
lock order reversal
1st 0xdf5fab34 process lock (process lock) @
/usr/src/sys/kern/kern_exec.c:319
2nd 0xc0318d80 filelist lock (filelist lock) @
/usr/src/sys/kern/kern_descrip.c:1112
/usr/src/sys/vm/uma_core.c:1330: could sleep with process lock
locked from /usr/src/sys/kern/kern_exec.c:319
/usr/src/sys/vm/uma_core.c:1330: could sleep with process lock
locked from /usr/src/sys/kern/kern_exec.c:319
...
/usr/src/sys/vm/uma_core.c:1330: could sleep with xl0 locked from
/usr/src/sys/pci/if_xl.c:415
pcm0: unregister: channel pcm0:play:0 busy (pid 13129)
IP firewall unloaded
IP packet filtering initialized, divert disabled, rule-based
forwarding disabled, default to deny, logging disabled
pid 13008 (cupsd), uid 0: exited on signal 10 (core dumped)
/usr/src/sys/vm/uma_core.c:1330: could sleep with process lock
locked from /usr/src/sys/kern/kern_prot.c:511
/usr/src/sys/vm/uma_core.c:1330: could sleep with process lock
locked from /usr/src/sys/kern/kern_prot.c:511
pcm0: warning: memblock list not empty
pcm0: detached
emujoy0: detached
/usr/src/sys/vm/uma_core.c:1330: could sleep with process lock
locked from /usr/src/sys/kern/kern_prot.c:511
/usr/src/sys/vm/uma_core.c:1330: could sleep with process lock
locked from /usr/src/sys/kern/kern_prot.c:511
[/usr/home/ajenkins]{41}: /usr/src/sys/vm/uma_core.c:1330: could sleep
with process lock locked from /usr/src/sys/kern/kern_exec.c:319
/usr/src/sys/vm/uma_core.c:1330:: Too many arguments.
/usr/src/sys/vm/uma_core.c:1330: could sleep with process lock
locked from /usr/src/sys/kern/kern_exec.c:319
[/usr/home/ajenkins]{42}: /usr/src/sys/vm/uma_core.c:1330: could sleep
with process lock locked from /usr/src/sys/kern/kern_exec.c:319
/usr/src/sys/vm/uma_core.c:1330:: Too many arguments.
Kernel config:
machine i386
#cpuI386_CPU cpu I486_CPU
cpu I586_CPU
cpu I686_CPU
ident MYKERNEL-5.0
options CPU_ATHLON_SSE_HACK
maxusers0
#hints GENERIC.hints #Default places to look for
devices.
makeoptions DEBUG=-g#Build kernel with gdb(1)
debug symbols
options INET#InterNETworking
#optionsINET6 #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
options SOFTUPDATES #Enable FFS soft updates support
options UFS_DIRHASH #Improve performance on big
