headers
Greg Steuck | 3 Jan 2010 09:16

kernel/6246 in a different guise

Looks like this diagnostic assertion in ehci_device_clear_toggle can
be triggered in many different scenarios. E.g.

umass1: Invalid CSW: tag 4430 should be 4431
umass1: Invalid CSW: tag 4430 should be 4432
umass1: Invalid CSW: tag 4431 should be 4433
umass1: Invalid CSW: tag 4433 should be 4434
panic: ehci_device_clear_toggle: queue active
...
ddb> tr
panic() at panic+0x122
ehci_device_clear_toggle() at ehci_device_clear_toggle+0x25
usbd_clear_endpoint_toggle() at usbd_clear_endpoint_toggle+0xb
umass_clear_endpoint_stall() at umass_clear_endpoint_stall+0x3e
usb_transfer_complete() at usb_transfer_complete+0x1e5
ehci_softintr() at ehci_softintr+0x2f
softintr_dispatch() at softintr_dispatch+0x73
Xsoftnet() at Xsoftnet+0xb1
--- interrupt ---
(null)() at 0x8
end of kernel
end trace frame: 0x123a, count: -10

My particular one is triggered by running dd if=/dev/sdXi of=/dev/null
for two different sd4 & sd5 devices attached to the same umass1. The
system is otherwise booted -s so nothing is running. The active
process is idle0 (pid 2).

I'll happily test any patches people may have but am unlikely to do
any code reading myself...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Estudio Concept | 3 Jan 2010 17:19
Picon

Promociones en Diseño Web


Si no puedes ver la imagen click en este link
Permalink | Reply | 0 comments |
headers
Greg Steuck | 3 Jan 2010 20:55

Re: kernel/6246 in a different guise

Hi Kenneth,

I noticed you hacked in umass land lately, so maybe you happen to know
the answer. I am trying to find the exclusion mechanism which prevents
umass_bbb_transfer in umass.c from being called twice in a row by
umass_scsi.c (through wire_xfer pointer) without an intervening
umass_bbb_state dequeueing the CSW. This could be the reason for those
pesky errors:

umass1: Invalid CSW: tag 4430 should be 4431

Another thing is, how does umass code avoid violating this requirement
in the spec?
http://www.usb.org/developers/devclass_docs/usbmassbulk_10.pdf

3.4 Command Queuing
The host shall not transfer a CBW to the device until the host has
received the CSW for any outstanding CBW.
If the host issues two consecutive CBWs without an intervening CSW or
reset, the device response to the second
CBW is indeterminate.

Thanks
Greg

On Sun, Jan 3, 2010 at 12:16 AM, Greg Steuck <greg <at> nest.cx> wrote:
> Looks like this diagnostic assertion in ehci_device_clear_toggle can
> be triggered in many different scenarios. E.g.
>
> umass1: Invalid CSW: tag 4430 should be 4431
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthieu Herrb | 1 Jan 2010 14:21
Picon
Picon
Favicon

fix ssh-askpass in multihead configs

Hi and best wishes for 2010,

When running on a mutliheaded display, either with Xinerama or with
XRandr, there's no warranty that the Xinerama pseudo screen 0 will be
in (0,0). It can be at any offset. Currently ssh-askpass assumes that
screen 0 is always at (0,0). 

If all your monitors have the same pixel size, the only effect of this
is that ssh-askpass will always appear on the leftmost one. I have a
smaller monitor on the left, and whithout the attached patch,
ssh-askpass appears at a strange position on it.

This patch makes ssh-askpass appear at the expected position on the
pseudo screen 0. 

There's still a problem with the resolution computation in the case of
XRandR. it will have to be fixed by making ssh-askpass XRandR aware. 

ok?

Index: x11-ssh-askpass.c
===================================================================
RCS file: /cvs/OpenBSD/xenocara/app/ssh-askpass/x11-ssh-askpass.c,v
retrieving revision 1.4
diff -u -p -u -r1.4 x11-ssh-askpass.c
--- x11-ssh-askpass.c	14 Jun 2008 01:05:04 -0000	1.4
+++ x11-ssh-askpass.c	1 Jan 2010 13:11:39 -0000
 <at>  <at>  -698,8 +698,8  <at>  <at>  void createDialog(AppInfo *app)
    calcButtonLabelPosition(&(d->okButton));
    calcButtonLabelPosition(&(d->cancelButton));
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fiesta del Barco | 5 Jan 2010 03:34
Picon

Viernes 8/01 Fiesta del Barco

VIERNES 8/01

B 

FIESTA DEL BARCO

Arranquemos el 2010 en el rC-o!!!!

Apertura de la FIESTA EN BARCO 23:50 hs., 

con tiempo de llegada hasta la 0:45 hs., 
momento en que zarpamos (desde el Puerto de Olivos), 

navegando por el RC-o de la Plata con una exclusiva 

panorC!mica de la ciudad de Bs. As., llegando hasta TIGRE y 

anclando frente al Parque de la Costa. Regreso a puerto 5:00 hs. 

Valor de la Entrada: $50.- 

cupo limitado, entradas C:nicamente anticipadas- 

Los esperamos para compartir juntos una noche mC s con la mejor mC:sica, 

barra y el calorcito!!!!

PUERTO DE OLIVOS, CORRIENTES Y EL RC
O
(Continue reading)

Permalink | Reply | 0 comments |
headers
sn_ | 5 Jan 2010 22:18
Picon

[PATCH] Fix typo in icmp6_error comment

The patch fixes a small typo in the icmp6_error comment. It's called 'Packet Too Big'

Index: icmp6.c
===================================================================
RCS file: /cvs/src/sys/netinet6/icmp6.c,v
retrieving revision 1.108
diff -u -r1.108 icmp6.c
--- icmp6.c     20 Nov 2009 09:02:21 -0000      1.108
+++ icmp6.c     5 Jan 2010 21:16:40 -0000
 <at>  <at>  -301,7 +301,7  <at>  <at> 
         * we should basically suppress sending an error (RFC 2463, Section
         * 2.4).
         * We have two exceptions (the item e.2 in that section):
-        * - the Pakcet Too Big message can be sent for path MTU discovery.
+        * - the Packet Too Big message can be sent for path MTU discovery.
         * - the Parameter Problem Message that can be allowed an icmp6 error
         *   in the option type field.  This check has been done in
         *   ip6_unknown_opt(), so we can just check the type and code.

--

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
Permalink | Reply | 0 comments |
headers
Verónica Bruzzese | 5 Jan 2010 21:18
Picon

Promos inigualables - Ademas pagas 3 meses y usas 4

Si Ud. no desea seguir recibiendo correos de este remitente, haga clic
aqum para remover su cuenta

[IMAGE]

[demime 1.01d removed an attachment of type image/jpeg which had a name of enero2_01.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of enero2_02.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of enero2_03.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of enero2_04.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of enero2_05.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of fondo.jpg]
Permalink | Reply | 0 comments |
headers
Pawlowski Marcin Piotr | 6 Jan 2010 21:43
Picon

acpidump assertion failed

Hi,
I've:
OpenBSD 4.6-current (GENERIC.MP) #39: Sat Dec 26 21:12:23 MST 2009
     deraadt <at> amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2004357120 (1911MB)
avail mem = 1941401600 (1851MB)
RTC BIOS diagnostic error e3<clock_battery,ROM_cksum,config_unit>
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4  <at>  0x77ac4000 (21 entries)
bios0: vendor Hewlett-Packard version "68PSU Ver. F.0E" date 09/14/2009
bios0: Hewlett-Packard HP EliteBook 2530p (FU435EA#ABB)
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP HPET APIC MCFG TCPA SSDT SLIC DMAR ASF! SSDT 
SSDT SSDT
acpi0: wakeup devices LANC(S0) HDEF(S4) RP02(S5) WNIC(S5) RP03(S5) 
ECF0(S5) RP05(S5) ECF0(S5) RP06(S0) NIC_(S0) USB1(S0) USB2(S0) USB3(S0) 
USB4(S0) USB5(S0) USB6(S0) U6RM(S0) EHC1(S0) EHC2(S0) PCIB(S5) HST1(S5)

and I'm getting this assertion while trying to run acpidump:

assertion "dp == end" failed: file "asl_dump.c", line 707, function 
"asl_dump_defif"

Cheers,
pmp

acpidump output:

/*
RSD PTR: Checksum=83, OEMID=HPQOEM, RsdtAddress=0x77bfe0ac
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pawlowski Marcin Piotr | 6 Jan 2010 22:11
Picon

Re: acpidump assertion failed

Pawlowski Marcin Piotr wrote:
 > Hi,
 > I've:
 > OpenBSD 4.6-current (GENERIC.MP) #39: Sat Dec 26 21:12:23 MST 2009
 >     deraadt <at> amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 > real mem = 2004357120 (1911MB)
 > avail mem = 1941401600 (1851MB)
 > RTC BIOS diagnostic error e3<clock_battery,ROM_cksum,config_unit>
 > mainbus0 at root
 > bios0 at mainbus0: SMBIOS rev. 2.4  <at>  0x77ac4000 (21 entries)
 > bios0: vendor Hewlett-Packard version "68PSU Ver. F.0E" date 09/14/2009
 > bios0: Hewlett-Packard HP EliteBook 2530p (FU435EA#ABB)
 > acpi0 at bios0: rev 2
 > acpi0: tables DSDT FACP HPET APIC MCFG TCPA SSDT SLIC DMAR ASF! SSDT 
SSDT SSDT
 > acpi0: wakeup devices LANC(S0) HDEF(S4) RP02(S5) WNIC(S5) RP03(S5) 
ECF0(S5) RP05(S5) ECF0(S5) RP06(S0) NIC_(S0) USB1(S0) USB2(S0) USB3(S0) 
USB4(S0) USB5(S0) USB6(S0) U6RM(S0) EHC1(S0) EHC2(S0) PCIB(S5) HST1(S5)
 >
 > and I'm getting this assertion while trying to run acpidump:
 >
 > assertion "dp == end" failed: file "asl_dump.c", line 707, function 
"asl_dump_defif"
 >
 > Cheers,
 > pmp
 >
 > acpidump output:
 >
 > /*
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert | 6 Jan 2010 23:54

impact of unaligned partitions/slices on 4kB sector drives (wd10ears)

Hello,

i did some measurements on the impact that unaligned partitions/slices
have on the "new" harddrives that use ondisk 4kB sectors and export
them as 512B sectors. [1]
My tests were done on a Western Digital WD10EARS. [2]

CONCLUSION:
Having unaligned partition/slices on those disks leads to noticable
performance penalty under realworld workloads.

IMPLICATIONS:
1. The rounding of unit sizes to cylinder boundaries by disklabel has
   to be evaluated.
2. A FAQ entry for the "advanced format" disks is needed to tell people
   to set the XP jumper. (more on that later)
   If disklabel is not modified, that entry would also have to explain
   the alignement implications and "how to use a calculator".

TEST RESULTS:

- sequential write/read speeds ---

  dd bs     | aligned   | unaligned | wd10eads*
            |           |           |
   4k write |  97433116 |  86349673 |  80762241  (bytes/sec)
  64k w     | 101273894 |  85616298 |  81234814
   1m w     |  98291974 |  79201231 |  83113302
            |           |           |
   4k read  | 103706513 | 104434701 |  82723667
(Continue reading)

Permalink | Reply | 0 comments |

Gmane