have softraid crypto call crypto_dispatch appropriately instead of crypto_invoke

[David Gwynne]

the distinct impression i get is crypto_invoke is an internal
abstraction to src/sys/crypto/crypto.c. it isnt documented in
crypto(9), and is only used outside crypto by softraid. softraid
should be calling crypto_dispatch with CRYPTO_F_NOQUEUE set if it
wants/needs those semantics.

can a softraid crypto user test this for me?

Index: softraid_crypto.c
===
RCS file: /cvs/src/sys/dev/softraid_crypto.c,v
retrieving revision 1.112
diff -u -p -r1.112 softraid_crypto.c
--- softraid_crypto.c   14 Sep 2014 14:17:24 -  1.112
+++ softraid_crypto.c   20 Oct 2014 01:25:12 -
@@ -1118,7 +1118,8 @@ sr_crypto_rw(struct sr_workunit *wu)
if (wu->swu_xs->flags & SCSI_DATA_OUT) {
crwu = sr_crypto_prepare(wu, 1);
crwu->cr_crp->crp_callback = sr_crypto_write;
-   rv = crypto_invoke(crwu->cr_crp);
+   crwu->cr_crp->crp_flags = CRYPTO_F_NOQUEUE;
+   rv = crypto_dispatch(crwu->cr_crp);
if (rv == 0)
rv = crwu->cr_crp->crp_etype;
} else
@@ -1195,9 +1196,10 @@ sr_crypto_done(struct sr_workunit *wu)
if (ISSET(xs->flags, SCSI_DATA_IN) && xs->error == XS_NOERROR) {
crwu = sr_crypto_prepare(wu, 0);
crwu->cr_crp->crp_callback = sr_crypto_read;
-   DNPRINTF(SR_D_INTR, "%s: sr_crypto_done: crypto_invoke %p\n",
+   crwu->cr_crp->crp_flags = CRYPTO_F_NOQUEUE;
+   DNPRINTF(SR_D_INTR, "%s: sr_crypto_done: crypto_dispatch %p\n",
DEVNAME(wu->swu_dis->sd_sc), crwu->cr_crp);
-   crypto_invoke(crwu->cr_crp);
+   crypto_dispatch(crwu->cr_crp);
return;
}
 

let crypto.c pools protect themselves

[David Gwynne]

pools lock themselves, we just gotta tell them how hard.

can someone test this with ipsec or softraid crypto? or ok it?

Index: crypto.c
===
RCS file: /cvs/src/sys/crypto/crypto.c,v
retrieving revision 1.68
diff -u -p -r1.68 crypto.c
--- crypto.c20 Oct 2014 00:40:33 -  1.68
+++ crypto.c20 Oct 2014 00:46:44 -
@@ -453,20 +453,16 @@ void
 crypto_freereq(struct cryptop *crp)
 {
struct cryptodesc *crd;
-   int s;
 
if (crp == NULL)
return;
 
-   s = splvm();
-
while ((crd = crp->crp_desc) != NULL) {
crp->crp_desc = crd->crd_next;
pool_put(&cryptodesc_pool, crd);
}
 
pool_put(&cryptop_pool, crp);
-   splx(s);
 }
 
 /*
@@ -477,20 +473,14 @@ crypto_getreq(int num)
 {
struct cryptodesc *crd;
struct cryptop *crp;
-   int s;

-   s = splvm();
-
crp = pool_get(&cryptop_pool, PR_NOWAIT | PR_ZERO);
-   if (crp == NULL) {
-   splx(s);
+   if (crp == NULL)
return NULL;
-   }
 
while (num--) {
crd = pool_get(&cryptodesc_pool, PR_NOWAIT | PR_ZERO);
if (crd == NULL) {
-   splx(s);
crypto_freereq(crp);
return NULL;
}
@@ -499,7 +489,6 @@ crypto_getreq(int num)
crp->crp_desc = crd;
}
 
-   splx(s);
return crp;
 }
 
@@ -510,8 +499,10 @@ crypto_init(void)
 
pool_init(&cryptop_pool, sizeof(struct cryptop), 0, 0,
0, "cryptop", NULL);
+   pool_setipl(&cryptop_pool, IPL_VM);
pool_init(&cryptodesc_pool, sizeof(struct cryptodesc), 0, 0,
0, "cryptodesc", NULL);
+   pool_setipl(&cryptodesc_pool, IPL_VM);
 }
 
 /*

use M_ZERO and PR_ZERO in crypto.c instead of bzero after allocation

[David Gwynne]

ok?

Index: crypto.c
===
RCS file: /cvs/src/sys/crypto/crypto.c,v
retrieving revision 1.67
diff -u -p -r1.67 crypto.c
--- crypto.c14 Sep 2014 14:17:23 -  1.67
+++ crypto.c20 Oct 2014 00:26:56 -
@@ -220,15 +220,12 @@ crypto_get_driverid(u_int8_t flags)
if (crypto_drivers_num == 0) {
crypto_drivers_num = CRYPTO_DRIVERS_INITIAL;
crypto_drivers = mallocarray(crypto_drivers_num,
-   sizeof(struct cryptocap), M_CRYPTO_DATA, M_NOWAIT);
+   sizeof(struct cryptocap), M_CRYPTO_DATA, M_NOWAIT | M_ZERO);
if (crypto_drivers == NULL) {
crypto_drivers_num = 0;
splx(s);
return -1;
}
-
-   bzero(crypto_drivers, crypto_drivers_num *
-   sizeof(struct cryptocap));
}
 
for (i = 0; i < crypto_drivers_num; i++) {
@@ -484,22 +481,20 @@ crypto_getreq(int num)

s = splvm();
 
-   crp = pool_get(&cryptop_pool, PR_NOWAIT);
+   crp = pool_get(&cryptop_pool, PR_NOWAIT | PR_ZERO);
if (crp == NULL) {
splx(s);
return NULL;
}
-   bzero(crp, sizeof(struct cryptop));
 
while (num--) {
-   crd = pool_get(&cryptodesc_pool, PR_NOWAIT);
+   crd = pool_get(&cryptodesc_pool, PR_NOWAIT | PR_ZERO);
if (crd == NULL) {
splx(s);
crypto_freereq(crp);
return NULL;
}
 
-   bzero(crd, sizeof(struct cryptodesc));
crd->crd_next = crp->crp_desc;
crp->crp_desc = crd;
}

make IPL levels consistent in src/sys/crypto/crypto.c

[David Gwynne]

everything else in crypto is protected at IPL_VM (via splvm), i
cant see a reason for the taskq to be different. ive read all the
users of the crypto api and theyre all at or below IPL_VM.

can someone test this with ipsec or softraid crypto?

cheers,
dlg

Index: crypto.c
===
RCS file: /cvs/src/sys/crypto/crypto.c,v
retrieving revision 1.67
diff -u -p -r1.67 crypto.c
--- crypto.c14 Sep 2014 14:17:23 -  1.67
+++ crypto.c17 Oct 2014 04:14:17 -
@@ -511,7 +511,7 @@ crypto_getreq(int num)
 void
 crypto_init(void)
 {
-   crypto_taskq = taskq_create("crypto", 1, IPL_HIGH);
+   crypto_taskq = taskq_create("crypto", 1, IPL_VM);
 
pool_init(&cryptop_pool, sizeof(struct cryptop), 0, 0,
0, "cryptop", NULL);

OpenSSL errata Oct 20

[Ted Unangst]

Patches are now available to fix two remotely triggerable memory leaks
in the OpenSSL libssl library. This issue affects 5.4 and 5.5. These
issues were originally fixed in forthcoming 5.6 release (it's not
affected).

The patch for 5.5 follows.

untrusted comment: signature from openbsd 5.5 base secret key
RWRGy8gxk9N93z0uERun06gnUvsfcC1KpQB7tmX6DIhpmLZG9J7BRtekstcTAujL+VXaTpreU58UMTDACvJT4LRjREzVnZWcoA0=

OpenBSD 5.5 errata 12, Oct 20, 2014

Two remotely triggerable memory leaks in OpenSSL can lead to a denial of
service in server applications.

Apply patch using:

signify -Vep /etc/signify/openbsd-55-base.pub -x 012_openssl.patch.sig \
-m - | (cd /usr/src && patch -p0)

Then build and install libssl

cd /usr/src/lib/libssl/ssl
make obj
make
make install


Index: lib/libssl/src/ssl/d1_srtp.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/d1_srtp.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 d1_srtp.c
--- lib/libssl/src/ssl/d1_srtp.c13 Oct 2012 21:23:49 -  1.1.1.1
+++ lib/libssl/src/ssl/d1_srtp.c17 Oct 2014 19:57:51 -
@@ -213,6 +213,7 @@ static int ssl_ctx_make_profiles(const c
else
{

SSLerr(SSL_F_SSL_CTX_MAKE_PROFILES,SSL_R_SRTP_UNKNOWN_PROTECTION_PROFILE);
+   sk_SRTP_PROTECTION_PROFILE_free(profiles);
return 1;
}
 
Index: lib/libssl/src/ssl/t1_lib.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/t1_lib.c,v
retrieving revision 1.12.8.2
diff -u -p -r1.12.8.2 t1_lib.c
--- lib/libssl/src/ssl/t1_lib.c 9 Aug 2014 16:54:58 -   1.12.8.2
+++ lib/libssl/src/ssl/t1_lib.c 17 Oct 2014 19:56:17 -
@@ -2188,8 +2188,10 @@ static int tls_decrypt_ticket(SSL *s, co
HMAC_Update(&hctx, etick, eticklen);
HMAC_Final(&hctx, tick_hmac, NULL);
HMAC_CTX_cleanup(&hctx);
-   if (timingsafe_bcmp(tick_hmac, etick + eticklen, mlen))
+   if (timingsafe_bcmp(tick_hmac, etick + eticklen, mlen)) {
+   EVP_CIPHER_CTX_cleanup(&ctx);
return 2;
+   }
/* Attempt to decrypt session data */
/* Move p after IV to start of encrypted ticket, update length */
p = etick + 16 + EVP_CIPHER_CTX_iv_length(&ctx);

Re: em(4) fix for Intel I218 chip

[Kaspars Bankovskis]

spotted a small typo in a comment. 1Gpbs -> 1Gbps

On Sun, Oct 12, 2014 at 09:53:28PM +0200, Claudio Jeker wrote:
> This seems to be enough to help em(4) in modern laptops like the X240 to
> no longer generate watchdog timeouts on high throughput.
> This should only affect I218 but tests on different em(4) devices would
> not hurt.
> 
> -- 
> :wq Claudio
> 
> 
> Index: if_em_hw.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
> retrieving revision 1.80
> diff -u -p -r1.80 if_em_hw.c
> --- if_em_hw.c22 Jul 2014 13:12:11 -  1.80
> +++ if_em_hw.c28 Sep 2014 12:24:45 -
> @@ -163,6 +163,7 @@ int32_t   em_lv_phy_workarounds_ich8lan(s
>  int32_t  em_link_stall_workaround_hv(struct em_hw *);
>  int32_t  em_k1_gig_workaround_hv(struct em_hw *, boolean_t);
>  int32_t  em_k1_workaround_lv(struct em_hw *);
> +int32_t  em_k1_workaround_lpt_lp(struct em_hw *, boolean_t);
>  int32_t  em_configure_k1_ich8lan(struct em_hw *, boolean_t);
>  void em_gate_hw_phy_config_ich8lan(struct em_hw *, boolean_t);
>  int32_t  em_access_phy_wakeup_reg_bm(struct em_hw *, uint32_t,
> @@ -3709,6 +3710,16 @@ em_check_for_link(struct em_hw *hw)
>   if (ret_val)
>   return ret_val;
>   }
> + /* Work-around I218 hang issue */
> + if ((hw->device_id == E1000_DEV_ID_PCH_LPTLP_I218_LM) ||
> + (hw->device_id == E1000_DEV_ID_PCH_LPTLP_I218_V) ||
> + (hw->device_id == E1000_DEV_ID_PCH_I218_LM3) ||
> + (hw->device_id == E1000_DEV_ID_PCH_I218_V3)) {
> + ret_val = em_k1_workaround_lpt_lp(hw,
> + hw->icp__is_link_up);
> + if (ret_val)
> + return ret_val;
> + }
>  
>   /*
>* Check if there was DownShift, must be checked
> @@ -5104,7 +5115,6 @@ em_kumeran_lock_loss_workaround(struct e
>* Attempting this while link is negotiating fouled up link stability
>*/
>   ret_val = em_read_phy_reg(hw, PHY_STATUS, &phy_data);
> - ret_val = em_read_phy_reg(hw, PHY_STATUS, &phy_data);
>  
>   if (phy_data & MII_SR_LINK_STATUS) {
>   for (cnt = 0; cnt < 10; cnt++) {
> @@ -10185,6 +10195,84 @@ em_k1_workaround_lv(struct em_hw *hw)
>   
>   return E1000_SUCCESS;
>  }
> +
> +/**
> + *  em_k1_workaround_lpt_lp - K1 workaround on Lynxpoint-LP
> + *
> + *  When K1 is enabled for 1Gbps, the MAC can miss 2 DMA completion 
> indications
> + *  preventing further DMA write requests.  Workaround the issue by disabling
> + *  the de-assertion of the clock request when in 1Gpbs mode.
> + *  Also, set appropriate Tx re-transmission timeouts for 10 and 100Half link
> + *  speeds in order to avoid Tx hangs.
> + **/
> +int32_t
> +em_k1_workaround_lpt_lp(struct em_hw *hw, boolean_t link)
> +{
> + uint32_t fextnvm6 = E1000_READ_REG(hw, FEXTNVM6);
> + uint32_t status = E1000_READ_REG(hw, STATUS);
> + int32_t ret_val = E1000_SUCCESS;
> + uint16_t reg;
> +
> + if (link && (status & E1000_STATUS_SPEED_1000)) {
> + ret_val = em_read_kmrn_reg(hw, E1000_KMRNCTRLSTA_K1_CONFIG,
> + ®);
> + if (ret_val)
> + return ret_val;
> +
> + ret_val = em_write_kmrn_reg(hw, E1000_KMRNCTRLSTA_K1_CONFIG,
> + reg & ~E1000_KMRNCTRLSTA_K1_ENABLE);
> + if (ret_val)
> + return ret_val;
> +
> + usec_delay(10);
> +
> + E1000_WRITE_REG(hw, FEXTNVM6,
> + fextnvm6 | E1000_FEXTNVM6_REQ_PLL_CLK);
> +
> + ret_val = em_write_kmrn_reg(hw, E1000_KMRNCTRLSTA_K1_CONFIG,
> + reg);
> + } else {
> + /* clear FEXTNVM6 bit 8 on link down or 10/100 */
> + fextnvm6 &= ~E1000_FEXTNVM6_REQ_PLL_CLK;
> +
> + if (!link || ((status & E1000_STATUS_SPEED_100) &&
> +   (status & E1000_STATUS_FD)))
> + goto update_fextnvm6;
> +
> + ret_val = em_read_phy_reg(hw, I217_INBAND_CTRL, ®);
> + if (ret_val)
> + return ret_val;
> +
> + /* Clear link status transmit timeout */
> + reg &= ~I217_INBAND_CTRL_LINK_STAT_TX_TIMEOUT_MASK;
> +
> + if (status & E1000_STATUS_SPEED_100) {
> + /* Set inband Tx timeout to 5x10us for 100Half */
> + reg |= 5 << I217_INBAND_CTRL_LINK_STAT_TX_TIMEOUT_SHIFT;
> +
> + /* Do not extend the K1 entry latency for 100Half */
> + fextnvm6 &= ~E1000_FEXTNVM6_ENABLE_K1_

kernexec errata Oct 20

[Ted Unangst]

Patches are now available to fix a localhost kernel crash reported by
Alejandro Hernandez. This issue affects 5.4, 5.5, and the forthcoming
5.6 release.

The patch for 5.5 follows.

untrusted comment: signature from openbsd 5.5 base secret key
RWRGy8gxk9N93+CyZ3HPzmlkYc+DX80XHguS4MVaRRRK53ZyfwuOFKvvKgrM6UO3yUJVfSkHRh7X6SaD17yDUck9m+kWScQy7Q0=

OpenBSD 5.5 errata 13, Oct 20, 2014:

Executable headers with an unaligned address will trigger a kernel panic.

Apply patch using:

signify -Vep /etc/signify/openbsd-55-base.pub -x 013_kernexec.patch.sig \
-m - | (cd /usr/src && patch -p0)

Then build and install a new kernel.

Index: sys/kern/kern_exec.c
===
RCS file: /cvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.137
diff -u -p -r1.137 kern_exec.c
--- sys/kern/kern_exec.c21 Jan 2014 01:48:44 -  1.137
+++ sys/kern/kern_exec.c19 Oct 2014 16:58:19 -
@@ -428,10 +428,12 @@ sys_execve(struct proc *p, void *v, regi
 
vm = p->p_vmspace;
/* Now map address space */
-   vm->vm_taddr = (char *)pack.ep_taddr;
-   vm->vm_tsize = atop(round_page(pack.ep_tsize));
-   vm->vm_daddr = (char *)pack.ep_daddr;
-   vm->vm_dsize = atop(round_page(pack.ep_dsize));
+   vm->vm_taddr = (char *)trunc_page(pack.ep_taddr);
+   vm->vm_tsize = atop(round_page(pack.ep_taddr + pack.ep_tsize) -
+   trunc_page(pack.ep_taddr));
+   vm->vm_daddr = (char *)trunc_page(pack.ep_daddr);
+   vm->vm_dsize = atop(round_page(pack.ep_daddr + pack.ep_dsize) -
+   trunc_page(pack.ep_daddr));
vm->vm_dused = 0;
vm->vm_ssize = atop(round_page(pack.ep_ssize));
vm->vm_maxsaddr = (char *)pack.ep_maxsaddr;

amd64/i386 bus_space uvm_km_valloc -> km_alloc

[Mark Kettenis]

ok?

Index: i386/i386/machdep.c
===
RCS file: /home/cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.555
diff -u -p -r1.555 machdep.c
--- i386/i386/machdep.c 17 Oct 2014 20:37:57 -  1.555
+++ i386/i386/machdep.c 19 Oct 2014 19:37:38 -
@@ -3726,7 +3726,7 @@ bus_mem_add_mapping(bus_addr_t bpa, bus_
 
map_size = endpa - pa;
 
-   va = uvm_km_valloc(kernel_map, map_size);
+   va = (vaddr_t)km_alloc(map_size, &kv_any, &kp_none, &kd_nowait);
if (va == 0)
return (ENOMEM);
 
@@ -3782,7 +3782,7 @@ bus_space_unmap(bus_space_tag_t t, bus_s
/*
 * Free the kernel virtual mapping.
 */
-   uvm_km_free(kernel_map, va, endva - va);
+   km_free((void *)va, endva - va, &kv_any, &kp_none);
} else
panic("bus_space_unmap: bad bus space tag");
 
@@ -3829,7 +3829,7 @@ _bus_space_unmap(bus_space_tag_t t, bus_
/*
 * Free the kernel virtual mapping.
 */
-   uvm_km_free(kernel_map, va, endva - va);
+   km_free((void *)va, endva - va, &kv_any, &kp_none);
} else
panic("bus_space_unmap: bad bus space tag");
 
Index: amd64/amd64/bus_space.c
===
RCS file: /home/cvs/src/sys/arch/amd64/amd64/bus_space.c,v
retrieving revision 1.23
diff -u -p -r1.23 bus_space.c
--- amd64/amd64/bus_space.c 29 Mar 2014 18:09:28 -  1.23
+++ amd64/amd64/bus_space.c 19 Oct 2014 19:32:07 -
@@ -495,7 +495,7 @@ x86_mem_add_mapping(bus_addr_t bpa, bus_
 
map_size = endpa - pa;
 
-   va = uvm_km_valloc(kernel_map, map_size);
+   va = (vaddr_t)km_alloc(map_size, &kv_any, &kp_none, &kd_nowait);
if (va == 0)
return (ENOMEM);
 
@@ -559,7 +559,7 @@ _bus_space_unmap(bus_space_tag_t t, bus_
/*
 * Free the kernel virtual mapping.
 */
-   uvm_km_free(kernel_map, va, endva - va);
+   km_free((void *)va, endva - va, &kv_any, &kp_none);
} else
panic("bus_space_unmap: bad bus space tag");
 
@@ -604,7 +604,7 @@ bus_space_unmap(bus_space_tag_t t, bus_s
/*
 * Free the kernel virtual mapping.
 */
-   uvm_km_free(kernel_map, va, endva - va);
+   km_free((void *)va, endva - va, &kv_any, &kp_none);
} else
panic("bus_space_unmap: bad bus space tag");
 

info for htc hermes 300

[Francesco Il Parente]

Hallo everyone, i want install OpenBSD into pocket pc phone htc tytn 
hermes 300, but i don´t find the good information for unlock the 
bootloader and info for firmware free fot this hardware.


http://microcontrollershop.com/product_info.php?products_id=3945 this is 
the mainboard

the cpu is S3C2440 (ARM920T) and this a full details
http://pdadb.net/index.php?m=specs&id=462&view=1&c=t-mobile_mda_vario_ii_htc_hermes_300

i read some information for the solution to install the free os into the 
pocket pc, maybe is possible, but i must find the way unlock, anyone 
takes me one solution ?


i send the email on section arm but my email receveid delivery 
notification , i don´t know why.


cheers friend

--
Francesco Cardi alias Il Parente
Free Software activist
Volunteer at Red Cross
CEO/President GNU CODICE LIBERO - Free as in Freedom

Diaspora*: https://joindiaspora.com/u/ilparente
Twitter: https://twitter.com/cardifrancesco
Jabber: ilpare...@jabber.org

fix ulpt(4) firmware loading error path

[Stefan Sperling]

After submitting a print job and then turning on my USB printer I got:

ulpt0 at uhub0 port 1 configuration 1 interface 0 "Hewlett-Packard HP LaserJet 
1020" rev 2.00/1.00 addr 2
ulpt0: using bi-directional mode
ulpt0: ucode upload error=IOERROR!
ulpt0: could not load firmware 'ulpt-hp1020'
uvm_fault(0xf388ac04, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at  usbd_transfer+0x13: movl0x4(%edi),%eax
ddb> trace
usbd_transfer(d56362a0,0,0,f39ef000,d) at usbd_transfer+0x13
ulpt_do_write(d150e600,f39e7e9c,1,d03ff869,f39e7d2c) at ulpt_do_write+0xd6
ulptwrite(4000,f39e7e9c,1,d04f2dbb,f37d7b7c) at ulptwrite+0x5d
spec_write(f39e7dc8,f38b71bc,f39e7ddc,d03ff869,f39e7dcc) at spec_write+0xad
VOP_WRITE(f37d6838,f39e7e9c,1,f3909664,f388ac08) at VOP_WRITE+0x42
vn_write(d561b834,d561b850,f39e7e9c,f3909664,4faf4658) at vn_write+0x92
dofilewritev(d5488b98,5,d561b834,f39e7f04,1) at dofilewritev+0x194
sys_write(d5488b98,f39e7f60,f39e7f80,d056d895,d5488b98) at sys_write+0xa5
syscall() at syscall+0x24d
--- syscall (number -809625138) ---
0x2:
ddb> 

With the following diff firmware load errors (which I triggered on
purpose both by pulling the USB cable at the right time, and also
by renaming the firmware file) are handled more gracefully:

$ lpq
waiting for lp to become ready (offline ?)
Rank   Owner  Job  Files Total Size
1ststsp   143  (standard input)  3 bytes
$ tail /var/log/messages  
Oct 19 16:02:13 dougal /bsd: ulpt0: failed loadfirmware of file ulpt-hp1020 
(error 2)
Oct 19 16:02:13 dougal /bsd: ulpt0: could not load firmware 'ulpt-hp1020'
Oct 19 16:02:29 dougal /bsd: ulpt0: failed loadfirmware of file ulpt-hp1020 
(error 2)
Oct 19 16:02:29 dougal /bsd: ulpt0: could not load firmware 'ulpt-hp1020'
Oct 19 16:03:01 dougal /bsd: ulpt0: failed loadfirmware of file ulpt-hp1020 
(error 2)
Oct 19 16:03:01 dougal /bsd: ulpt0: could not load firmware 'ulpt-hp1020'
Oct 19 16:03:33 dougal /bsd: ulpt0: failed loadfirmware of file ulpt-hp1020 
(error 2)
Oct 19 16:03:33 dougal /bsd: ulpt0: could not load firmware 'ulpt-hp1020'
Oct 19 16:04:06 dougal /bsd: ulpt0: failed loadfirmware of file ulpt-hp1020 
(error 2)
Oct 19 16:04:06 dougal /bsd: ulpt0: could not load firmware 'ulpt-hp1020'

In my testing the printer recovers automatically once the firmware
file is put in place. There is no need to re-plug it.

ok?

Index: ulpt.c
===
RCS file: /cvs/src/sys/dev/usb/ulpt.c,v
retrieving revision 1.47
diff -u -p -r1.47 ulpt.c
--- ulpt.c  12 Jul 2014 20:26:33 -  1.47
+++ ulpt.c  19 Oct 2014 13:41:00 -
@@ -100,6 +100,7 @@ struct ulpt_softc {
 #defineULPT_INIT   0x04/* waiting to initialize for open */
u_char sc_flags;
 #defineULPT_NOPRIME0x40/* don't prime on open */
+#defineULPT_EFIRMWARE  0x80/* error loading firmware */
u_char sc_laststatus;
 
int sc_refcnt;
@@ -193,9 +194,12 @@ ulpt_load_firmware(void *arg)
usbd_status err;
 
err = (sc->sc_fwdev->ucode_loader)(sc);
-   if (err != USBD_NORMAL_COMPLETION)
+   if (err != USBD_NORMAL_COMPLETION) {
+   sc->sc_flags |= ULPT_EFIRMWARE;
printf("%s: could not load firmware '%s'\n",
sc->sc_dev.dv_xname, sc->sc_fwdev->ucode_name);
+   } else
+   sc->sc_flags &= ~ULPT_EFIRMWARE;
 }
 
 #define ulpt_lookup(v, p) \
@@ -469,6 +473,13 @@ ulptopen(dev_t dev, int flag, int mode, 
if (sc->sc_state)
return (EBUSY);
 
+   /* If a previous attempt to load firmware failed, retry. */
+   if (sc->sc_flags & ULPT_EFIRMWARE) {
+   ulpt_load_firmware(sc);
+   if (sc->sc_flags & ULPT_EFIRMWARE)
+   return (EIO);
+   }
+
sc->sc_state = ULPT_INIT;
sc->sc_flags = flags;
DPRINTF(("ulptopen: flags=0x%x\n", (unsigned)flags));
@@ -640,7 +651,7 @@ ulptwrite(dev_t dev, struct uio *uio, in
 
sc = ulpt_cd.cd_devs[ULPTUNIT(dev)];
 
-   if (usbd_is_dying(sc->sc_udev))
+   if (usbd_is_dying(sc->sc_udev) || (sc->sc_flags & ULPT_EFIRMWARE))
return (EIO);
 
sc->sc_refcnt++;

Re: getent(1) hosts enumeration defunc

[Ingo Schwarze]

Hi Theo,

Theo de Raadt wrote on Sun, Oct 19, 2014 at 07:35:06AM -0600:
> Florian Obser wrote:

>> You can get rid of sethostent(3)/endhostent(3) at the same time.

> Those have to remain stubs for a while longer, because there are
> ports which poke at them.

Oh the joys of terseness.  Florian meant deleting the calls from
the getent(1) source code, not deleting the interface from libc.

Yours,
  Ingo

Re: getent(1) hosts enumeration defunc

[Theo de Raadt]

>You can get rid of sethostent(3)/endhostent(3) at the same time.

Those have to remain stubs for a while longer, because there are
ports which poke at them.

Re: uuidgen port from FreeBSD for inclusion in OpenBSD base

[Marc Espie]

On Sat, Oct 18, 2014 at 10:01:17PM +0200, Jérémie Courrèges-Anglas wrote:
> 
> Why do you post publicly a private mail without asking first?
> 
> Looks like my first impression about you was right.

Don't feed the troll

Re: Conditional include in make(1)

[Mark Kettenis]

> Date: Sun, 19 Oct 2014 09:25:51 +0200
> From: Matthieu Herrb 
> 
> On Thu, Oct 16, 2014 at 08:14:16PM +0200, Mark Kettenis wrote:
> > Hi Marc,
> > 
> > Is there a reason why conditional includes (sinclude/-include) aren't
> > enabled in OpenBSD?
> > 
> > I'm asking because the Xorg people now use it in one of the xserver
> > Makefile.  We could of course try to convince them to revert the
> > change they made.  But it is a somewhat useful feature.
> 
> So, now that espie@ has committed the bit, ok to remove the local
> change that made the inclusion unconditionnal (and slightly broke make
> clean in xserver) ?

That's exactly why I wanted it.

ok kettenis@

> Index: Makefile.am
> ===
> RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/Makefile.am,v
> retrieving revision 1.9
> diff -u -r1.9 Makefile.am
> --- Makefile.am   27 Sep 2014 17:53:01 -  1.9
> +++ Makefile.am   19 Oct 2014 07:23:22 -
> @@ -138,7 +138,7 @@
>   $(AM_V_GEN)CPP='$(CPP)' AWK='$(AWK)' $(SHELL) $(srcdir)/sdksyms.sh 
> $(top_srcdir) $(CFLAGS) $(AM_CFLAGS) $(AM_CPPFLAGS)
>  
>  SDKSYMS_DEP = sdksyms.dep
> -include $(SDKSYMS_DEP)
> +-include $(SDKSYMS_DEP)
>  
>  i2c/libi2c.la:
>   $(AM_V_at)cd i2c && $(MAKE) libi2c.la
> Index: Makefile.in
> ===
> RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/Makefile.in,v
> retrieving revision 1.29
> diff -u -r1.29 Makefile.in
> --- Makefile.in   27 Sep 2014 17:53:01 -  1.29
> +++ Makefile.in   19 Oct 2014 07:23:22 -
> @@ -1116,7 +1116,7 @@
>  
>  sdksyms.dep sdksyms.c: sdksyms.sh
>   $(AM_V_GEN)CPP='$(CPP)' AWK='$(AWK)' $(SHELL) $(srcdir)/sdksyms.sh 
> $(top_srcdir) $(CFLAGS) $(AM_CFLAGS) $(AM_CPPFLAGS)
> -include $(SDKSYMS_DEP)
> +-include $(SDKSYMS_DEP)
>  
>  i2c/libi2c.la:
>   $(AM_V_at)cd i2c && $(MAKE) libi2c.la
> 
> -- 
> Matthieu Herrb
> 

Re: getent(1) hosts enumeration defunc

[Florian Obser]

Hi Ingo,

On Sun, Oct 19, 2014 at 02:24:27AM +0200, Ingo Schwarze wrote:
> Hi Philip,
> 
> Philip Guenther wrote on Sat, Oct 18, 2014 at 04:38:09PM -0700:
> 
> > Maybe we just fix getent(1) to return an error like it does for ethers?
> 
> Whatever we do with gethostent(3) - maybe it's really expendable,
> maybe tons of ports depend on it, who knows - i'm fine with
> removing hosts enumeration support from getent(1).
> 
> Almost the same can be accomplished with
> 
>   cat /etc/hosts
> 
> and with more clarity as to what it does and what the shortcomings are.

thanks for looking into it, this has been on my not-todo pile for quite some 
time. :)

> 
> That would be the following patch:

You can get rid of sethostent(3)/endhostent(3) at the same time. They
are stups in asr and even if they weren't they serve no purpose with
gethostent(3) gone, tweaked patch at the end.

witht that OK florian@

> 
> Yours,
>   Ingo
> 

diff --git getent.c getent.c
index d991d0c..f479d67 100644
--- getent.c
+++ getent.c
@@ -268,10 +268,10 @@ hosts(int argc, char *argv[])
int i, rv = RV_OK;
struct hostent  *he;
 
-   sethostent(1);
if (argc == 2) {
-   while ((he = gethostent()) != NULL)
-   hostsprint(he);
+   fprintf(stderr, "%s: Enumeration not supported on hosts\n",
+   __progname);
+   rv = RV_NOENUM;
} else {
for (i = 2; i < argc; i++) {
he = NULL;
@@ -285,7 +285,6 @@ hosts(int argc, char *argv[])
break;
}
}
-   endhostent();
return rv;
 }
 


-- 
I'm not entirely sure you are real.

Re: Conditional include in make(1)

[Marc Espie]

On Sun, Oct 19, 2014 at 09:25:51AM +0200, Matthieu Herrb wrote:
> On Thu, Oct 16, 2014 at 08:14:16PM +0200, Mark Kettenis wrote:
> > Hi Marc,
> > 
> > Is there a reason why conditional includes (sinclude/-include) aren't
> > enabled in OpenBSD?
> > 
> > I'm asking because the Xorg people now use it in one of the xserver
> > Makefile.  We could of course try to convince them to revert the
> > change they made.  But it is a somewhat useful feature.
> 
> So, now that espie@ has committed the bit, ok to remove the local
> change that made the inclusion unconditionnal (and slightly broke make
> clean in xserver) ?
> 
> Index: Makefile.am
> ===
> RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/Makefile.am,v
> retrieving revision 1.9
> diff -u -r1.9 Makefile.am
> --- Makefile.am   27 Sep 2014 17:53:01 -  1.9
> +++ Makefile.am   19 Oct 2014 07:23:22 -
> @@ -138,7 +138,7 @@
>   $(AM_V_GEN)CPP='$(CPP)' AWK='$(AWK)' $(SHELL) $(srcdir)/sdksyms.sh 
> $(top_srcdir) $(CFLAGS) $(AM_CFLAGS) $(AM_CPPFLAGS)
>  
>  SDKSYMS_DEP = sdksyms.dep
> -include $(SDKSYMS_DEP)
> +-include $(SDKSYMS_DEP)
>  
>  i2c/libi2c.la:
>   $(AM_V_at)cd i2c && $(MAKE) libi2c.la
> Index: Makefile.in
> ===
> RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/Makefile.in,v
> retrieving revision 1.29
> diff -u -r1.29 Makefile.in
> --- Makefile.in   27 Sep 2014 17:53:01 -  1.29
> +++ Makefile.in   19 Oct 2014 07:23:22 -
> @@ -1116,7 +1116,7 @@
>  
>  sdksyms.dep sdksyms.c: sdksyms.sh
>   $(AM_V_GEN)CPP='$(CPP)' AWK='$(AWK)' $(SHELL) $(srcdir)/sdksyms.sh 
> $(top_srcdir) $(CFLAGS) $(AM_CFLAGS) $(AM_CPPFLAGS)
> -include $(SDKSYMS_DEP)
> +-include $(SDKSYMS_DEP)
>  
>  i2c/libi2c.la:
>   $(AM_V_at)cd i2c && $(MAKE) libi2c.la
> 
> -- 
Wait for a bit until new snaps have the new make, then sure.

Re: Conditional include in make(1)

[Matthieu Herrb]

On Thu, Oct 16, 2014 at 08:14:16PM +0200, Mark Kettenis wrote:
> Hi Marc,
> 
> Is there a reason why conditional includes (sinclude/-include) aren't
> enabled in OpenBSD?
> 
> I'm asking because the Xorg people now use it in one of the xserver
> Makefile.  We could of course try to convince them to revert the
> change they made.  But it is a somewhat useful feature.

So, now that espie@ has committed the bit, ok to remove the local
change that made the inclusion unconditionnal (and slightly broke make
clean in xserver) ?

Index: Makefile.am
===
RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/Makefile.am,v
retrieving revision 1.9
diff -u -r1.9 Makefile.am
--- Makefile.am 27 Sep 2014 17:53:01 -  1.9
+++ Makefile.am 19 Oct 2014 07:23:22 -
@@ -138,7 +138,7 @@
$(AM_V_GEN)CPP='$(CPP)' AWK='$(AWK)' $(SHELL) $(srcdir)/sdksyms.sh 
$(top_srcdir) $(CFLAGS) $(AM_CFLAGS) $(AM_CPPFLAGS)
 
 SDKSYMS_DEP = sdksyms.dep
-include $(SDKSYMS_DEP)
+-include $(SDKSYMS_DEP)
 
 i2c/libi2c.la:
$(AM_V_at)cd i2c && $(MAKE) libi2c.la
Index: Makefile.in
===
RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/Makefile.in,v
retrieving revision 1.29
diff -u -r1.29 Makefile.in
--- Makefile.in 27 Sep 2014 17:53:01 -  1.29
+++ Makefile.in 19 Oct 2014 07:23:22 -
@@ -1116,7 +1116,7 @@
 
 sdksyms.dep sdksyms.c: sdksyms.sh
$(AM_V_GEN)CPP='$(CPP)' AWK='$(AWK)' $(SHELL) $(srcdir)/sdksyms.sh 
$(top_srcdir) $(CFLAGS) $(AM_CFLAGS) $(AM_CPPFLAGS)
-include $(SDKSYMS_DEP)
+-include $(SDKSYMS_DEP)
 
 i2c/libi2c.la:
$(AM_V_at)cd i2c && $(MAKE) libi2c.la

-- 
Matthieu Herrb