[PATCH] GOP_ALLOC and fallocate for PUFFS

[Emmanuel Dreyfus]

Emmanuel Dreyfus  wrote:

> When a PUFFS filesystem uses the page cache, data enters the
> cache with no guarantee it will be flushed. If it cannot be flushed
> (bcause PUFFS write requests get EDQUOT or ENOSPC), then the
> kernel will loop forever trying to flush data from the cache,
> and the filesystem cannot be unmounted without -f (and data loss).

After some thoughs about the problem, I am not sure how it can be
solved. 

For a given write, PUFFS does not knows if the backed storage is
allocated or not. Of course there is the obvious case of writing beyond
EOF, but in the general case we do not know if we write to a hole or to
an already written area.

If we want to ensure backend allocation is done, we must do a
write-first to the filesystem before filling the cache. But when writing
before EOF, we must first read data from file (possibly getting zeroes
from unallocated area, or real data), then write. And since we have no
way of tracking where we already did a write, we are going to do it for
any write, even for a single byte. 

This seems to completely defeats the purpose of the page cache. 

Of course things are different if we have fallocate, but it seems not
acehivable in the near future for FFS.
 
-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org

Re: Help: USB 3.0 xHCI driver does not support non-root hub

[Takahiro HAYASHI]

hi,

On 09/15/14 23:46, Ryo ONODERA wrote:

Hi,

Our xHCI USB 3.0 driver with Intel Lynx Point/Lynx Point-LP, Renesas uPD70202
and Fresco Logic 0x1b73/0x1100 xHCI chips does not support non-root hub
as following.
I believe our xHCI driver have no non-root hub support.

I have tested some USB 1.1/2.0/3.0 hubs, and gotten same results.
Address Device Command TRB execution just after Enable Slot Command TRB
execution fails with USB Transaction Error.


I got PARAMETER error when i connected usb 2.0 thumb drive to
my uPD720200 xhci via 2.0 hub.


I have spent some weeks, but I cannot find why Address Device Command fails.
(If your want to use Intel Lynx Point/Lynx Point-LP xHC, please
apply a patch in http://gnats.netbsd.org/49076.)


I think that's because incorrect route string (always 0x0) and
incorrect root hub port is set in slot context.


Anyone have a clue for xHCI's non-root hub support?
I really need any clue for non-root hub support.


Can you try this patch?

This patch tries to add route string support for hubs.
Caveats:
- SS hub is currently not supported.
  SS hub will work as HS hub.
  I'm not sure both of SS and HS hub in SS hub can be
  attached on one roothub port.
- Detaching hub may cause panic.
  xhci may try to transfer on unplugged port.
- HUB,MTT,TTT and TT* fields in slot context is not set.


--- src/sys/dev/usb/xhci.c.orig 2014-10-03 21:18:24.0 +0900
+++ src/sys/dev/usb/xhci.c  2014-10-04 08:59:16.0 +0900
@@ -615,8 +760,12 @@ xhci_init(struct xhci_softc *sc)
 
 	XHCIHIST_FUNC(); XHCIHIST_CALLED();
 
+#if 0

+   sc->sc_bus.usbrev = USBREV_3_0;
+#else
/* XXX Low/Full/High speeds for now */
sc->sc_bus.usbrev = USBREV_2_0;
+#endif
 
 	cap = xhci_read_4(sc, XHCI_CAPLENGTH);

caplength = XHCI_CAP_CAPLENGTH(cap);
@@ -1139,8 +1449,7 @@ xhci_open(usbd_pipe_handle pipe)
return USBD_IOERROR;
 
 	/* Root Hub */

-   if (dev->depth == 0 && dev->powersrc->portno == 0 &&
-   dev->speed != USB_SPEED_SUPER) {
+   if (dev->depth == 0 && dev->powersrc->portno == 0) {
switch (ed->bEndpointAddress) {
case USB_CONTROL_ENDPOINT:
pipe->methods = &xhci_root_ctrl_methods;
@@ -1194,13 +1631,24 @@ xhci_rhpsc(struct xhci_softc * const sc,
if (xfer == NULL)
return;
 
-	if (!(port >= sc->sc_hs_port_start &&

-   port < sc->sc_hs_port_start + sc->sc_hs_port_count))
-   return;
+   xfer->pipe->device->speed =
+   XHCI_PS_SPEED_GET(xhci_op_read_4(sc, XHCI_PORTSC(port)));
 
-	port -= sc->sc_hs_port_start;

-   port += 1;
-   DPRINTFN(4, "hs port %u status change", port, 0, 0, 0);
+   if (port >= sc->sc_hs_port_start &&
+   port < sc->sc_hs_port_start + sc->sc_hs_port_count) {
+   port -= sc->sc_hs_port_start;
+   port += 1;
+   DPRINTFN(4, "hs port %u status change", port, 0, 0, 0);
+   } else if (port >= sc->sc_ss_port_start &&
+   port < sc->sc_ss_port_start + sc->sc_ss_port_count) {
+   port -= sc->sc_ss_port_start;
+   port += 1;
+   DPRINTFN(4, "ss port %u status change", port, 0, 0, 0);
+   } else {
+   /* cannot happen */
+   DPRINTFN(0, "port %u out of range", port, 0, 0, 0);
+   return;
+   }
 
 	p = KERNADDR(&xfer->dmabuf, 0);

memset(p, 0, xfer->length);
@@ -1468,7 +1974,7 @@ xhci_new_device(device_t parent, usbd_bu
usbd_status err;
usb_device_descriptor_t *dd;
struct usbd_device *hub;
-   struct usbd_device *adev;
+   uint32_t route = 0;
int rhport = 0;
struct xhci_slot *xs;
uint32_t *cp;
@@ -1515,28 +2017,32 @@ xhci_new_device(device_t parent, usbd_bu
up->device = dev;
 
 	/* Locate root hub port */

-   for (adev = dev, hub = dev;
-   hub != NULL;
-   adev = hub, hub = hub->myhub) {
-   DPRINTFN(4, "hub %p", hub, 0, 0, 0);
-   }
-   DPRINTFN(4, "hub %p", hub, 0, 0, 0);
-
-   if (hub != NULL) {
-   for (int p = 0; p < hub->hub->hubdesc.bNbrPorts; p++) {
-   if (hub->hub->ports[p].device == adev) {
-   rhport = p;
-   }
-   }
-   } else {
-   rhport = port;
+   for (hub = dev; hub != NULL; hub = hub->myhub) {
+   uint32_t dep;
+
+   DPRINTFN(4, "hub %p depth %d upport %p upportno %d",
+   hub, hub->depth, hub->powersrc,
+   hub->powersrc ? hub->powersrc->portno : 0);
+
+   if (hub->powersrc == NULL)
+   continue;
+   dep = hub->depth;
+   if (dep == 0)
+   continue;
+
+   route |= hub->powersrc->portno << ((dep - 1) * 4);
}
+   DPRINTFN(4, "hub %p route %05x", hub, route, 0, 0);
+
if (s

CTLTYPE_UINT?

[Justin Cormack]

Back in the sysctl discussion a while back, core group said:

http://mail-index.netbsd.org/tech-kern/2014/03/26/msg016779.html

a) What types are needed?  Currently, CTLTYPE_INT is a signed
   32-bit type, and CTLTYPE_QUAD is an unsigned 64-bit type.
   Perhaps all four possible combinations of signed/unsigned and
   32 bits/64 bits should be supported.

I noticed today that there are some cases where a CTLTYPE_INT is being
fed a uint32_t, for example in sys/netinet6/ip6_input.c this is the
case for ip6_temp_preferred_lifetime and similar values that are
uint32_t.

It seems to make sense to add a CTLTYPE_UINT for these types, although
there are other options. FreeBSD introduced them way back. We could
continue to ignore the signedness differences though...

Thoughts?

Justin