Re: Composite PCI devices in FreeBSD (mfd in Linux)
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
Re: Composite PCI devices in FreeBSD (mfd in Linux)
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.
-- Ian
> > 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
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"
Re: Composite PCI devices in FreeBSD (mfd in Linux)
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. 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. 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. Hopefully that gives you a starting point? -- John Baldwin ___ 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: Suppose a user on a pilgrimage to /usr/src, modified UPDATING
miltonott wrote: > O great and powerful FreeBSD biome. May I redirect from here to a paste > site > service, a rearrangement of development directory head file /usr/src/UPDATING. sorry, but left & right justified text is horrible, especially with a monospaced font! ___ 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"
SDHCI: serious issues with USB SD Card reader/writer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Using the USB attached SD card reader/writer of my Dell screen, since 13-CURRENT is out recently I have serious trouble with the assortment of SD cards I use. While 12-PRE seems to not have any problems, 13-CURRENT (FreeBSD 13.0-CURRENT #912 r341770: Sun Dec 9 23:02:16 CET 2018 amd64) has. The phenomenon looks like when written successfully an image to a 16 or 32 GB SD card and put in a Samsung 32GB SD card (a Samsung EVO, or the one that comes with the Raspberry Pi 3B+ these days, I have two of them and the problem is on both the same), I receive the console message after trying to "dd" some images onto /dev/da0: sudo dd if=2018-11-13-raspbian-stretch-full.img of=/dev/da0 bs=1m dd: /dev/da0: Operation not permitted This happens even as root. The console shows: [...] ugen0.4: at usbus0 umass0 on uhub6 umass0: on usbus0 da0 at umass-sim0 bus 0 scbus10 target 0 lun 0 da0: Removable Direct Access SCSI device da0: Serial Number 00264001 da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da0: quirks=0x2 [...] (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 00 00 00 00 10 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error) (da0:umass-sim0:0:0:0): Error 5, Unretryable error [...] GEOM_PART: integrity check failed (da0, MBR) GEOM_PART: da0 was automatically resized. Use `gpart commit da0` to save changes or `gpart undo da0` to revert them. GEOM_PART: da0 was automatically resized. Use `gpart commit da0` to save changes or `gpart undo da0` to revert them. GEOM_PART: da0 was automatically resized. Use `gpart commit da0` to save changes or `gpart undo da0` to revert them. GEOM_PART: da0 was automatically resized. Use `gpart commit da0` to save changes or `gpart undo da0` to revert them. g_access(958): provider diskid/DISK-00264001 has error 6 set g_access(958): provider diskid/DISK-00264001 has error 6 set g_access(958): provider diskid/DISK-00264001 has error 6 set g_access(958): provider diskid/DISK-00264001 has error 6 set g_access(958): provider diskid/DISK-00264001 has error 6 set g_access(958): provider diskid/DISK-00264001 has error 6 set g_access(958): provider diskid/DISK-00264001 has error 6 set g_access(958): provider diskid/DISK-00264001 has error 6 set g_access(958): provider diskid/DISK-00264001 has error 6 set [...] The CAM error above occurs on a lot of SD cards which worked earlier. In some cases, the problem disappears after a reboot, but it seems to be persistent with some types of the SD cards. Since I've written all of them in the past with 12-CURRENT and the very same SD card reader, I suspect some serious bug in recent updates either to the SCSI subsystem or SDHCI. I just ordered an alternative USB SD card reader/writer just in case the error indicates a hardware failure. Kind regards, O. Hartmann - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCXA5TqgAKCRDS528fyFhY lJ7eAf98BJ7zbDfEd3JqQRykn4iEvLsHPBofzsb+uj9ZS1uJsnk70kMwyIPitdtd CuHue4UGps2Ozt+KEtaRnAqxuMk4AgCA/K/3Y5lsYu0o6e2p4oKXu323fe8akco1 PxTGVTEsr/0BJEbTrSbOnRqIXY4lF86GspSzSZtnoKM9Av+5EbuO =/a+G -END PGP SIGNATURE- ___ 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: Suppose a user on a pilgrimage to /usr/src, modified UPDATING
On Mon, Dec 10, 2018 at 09:49:13AM +, miltonott wrote: > O great and powerful FreeBSD biome. May I redirect from here to a paste > site > service, a rearrangement of development directory head file /usr/src/UPDATING. > > UPDATING.ORIG -> http://dpaste.com/1WRWG26.txt > - > UPDATING -> http://dpaste.com/1Z4E3H1.txt > - > UPDATING.DIFF -> http://dpaste.com/0HF44M9.txt > I'm not sure what you're trying to accomplish by doing that, but UPDATING isn't used in the process of building FreeBSD from sources, except by the human directing the process. It's for human consumption. Peace, david -- David H. Wolfskill da...@catwhisker.org If POTUS nominates one who's "dumb as a rock" for Cabinet, who's at fault? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Suppose a user on a pilgrimage to /usr/src, modified UPDATING
O great and powerful FreeBSD biome. May I redirect from here to a paste site service, a rearrangement of development directory head file /usr/src/UPDATING. UPDATING.ORIG -> http://dpaste.com/1WRWG26.txt - UPDATING -> http://dpaste.com/1Z4E3H1.txt - UPDATING.DIFF -> http://dpaste.com/0HF44M9.txt ___ 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"
Ports build fails on 13-CURRENT r341690
Hello, yasu@rolling-vm-freebsd1[2018]% uname -a FreeBSD rolling-vm-freebsd1.home.utahime.org 13.0-CURRENT FreeBSD 13.0-CURRENT r341690 GENERIC amd64 yasu@rolling-vm-freebsd1[2019]% LANG=C svn info /usr/src Path: /usr/src Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 341690 Node Kind: directory Schedule: normal Last Changed Author: kib Last Changed Rev: 341690 Last Changed Date: 2018-12-08 00:19:00 +0900 (Sat, 08 Dec 2018) yasu@rolling-vm-freebsd1[2020]% LANG=C svn info /usr/ports Path: /usr/ports Working Copy Root Path: /usr/ports URL: https://svn.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 487116 Node Kind: directory Schedule: normal Last Changed Author: yuri Last Changed Rev: 487116 Last Changed Date: 2018-12-10 10:06:34 +0900 (Mon, 10 Dec 2018) Build of ports-mgmt/pkg fails as following. -- > Compressing man pages (compress-man) === === ===> Building package for pkg-1.10.5_5 install -l rs /.npkg/All/pkg-1.10.5_5.txz /.npkg/Latest/pkg.txz install: /.npkg/All/pkg-1.10.5_5.txz: realpath: No such file or directory *** Error code 71 Stop. make[1]: stopped in /usr/ports/ports-mgmt/pkg *** Error code 1 Stop. make: stopped in /usr/ports/ports-mgmt/pkg =>> Cleaning up wrkdir ===> Cleaning for pkg-1.10.5_5 build of ports-mgmt/pkg | pkg-1.10.5_5 ended at Mon Dec 10 16:49:35 JST 2018 build time: 00:03:50 !!! build failure encountered !!! -- Full build log: https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/curamd64-local/2018-12-10_16h45m20s/logs/errors/pkg-1.10.5_5.log And this prevent any other ports from building. Does anyone else experience it? Best Regards. --- Yasuhiro KIMURA ___ 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"
