OpenBSD fails to boot while enabling MSI on older ServerWorks chipsets

2012-01-31 Thread Kevin Bowling 
Hi,

OpenBSD 5.0 fails to boot on older servers (generally Pentium III and
under) with the ServerWorks chipset.  MSI should not try to be used on
these.

I created the following patch.  The chipsets identified are educated
guesses based on Google search and sequence number, but there's not a
great way to cross reference and make sure all are included and the
PCI names don't match up to the marketing name.  Anyway, this is a
good enough start and should make people happy as their systems will
boot again.

Regards,
Kevin Bowling

*** pci_machdep.c-orig  2012-01-31 03:01:18.814973578 -0700
--- pci_machdep.c   2012-01-31 03:22:54.766124176 -0700
***
*** 303,308 
--- 303,327 
break;
}
break;
+   case PCI_VENDOR_RCC:
+   /*
+* Older ServerWorks chipsets don't support MSI
+* TODO: x-reference and confirm all older chipsets listed
+*/
+   switch (PCI_PRODUCT(id)) {
+   case PCI_PRODUCT_RCC_CMIC_LE:
+   case PCI_PRODUCT_RCC_CNB20_LE:
+   case PCI_PRODUCT_RCC_CNB20HE_1:
+   case PCI_PRODUCT_RCC_CNB20_LE_2:
+   case PCI_PRODUCT_RCC_CNB20HE_2:
+   case PCI_PRODUCT_RCC_CNB20LE:
+   case PCI_PRODUCT_RCC_CIOB30:
+   break;
+   default:
+   pba-pba_flags |= PCI_FLAGS_MSI_ENABLED;
+   break;
+   }
+   break;
}

/*

Re: [PATCH][BUG] ksh / sh segfault

2012-01-31 Thread Otto Moerbeek 
On Mon, Jan 30, 2012 at 03:18:04PM +0100, Michael Niedermayer wrote:

 Hi
 
 Our automated tests for FFmpeg (http://fate.ffmpeg.org/) have yesterday
 found a segfault in openbsds /bin/sh.
 
 Analysis revealed that it was triggered by too many variables
 That is something like
 
 #!/bin/sh
 
 i=0
 while true ; do
 eval X${i}=yes
 i=$(($i+1))
 test $i -gt 17000  break
 done
 
 will segfault.
 
 The following patch fixes it: (which we are currently using on our
 openbsd fate client)
 
 Index: table.h
 ===
 RCS file: /cvs/src/bin/ksh/table.h,v
 retrieving revision 1.7
 diff -u -r1.7 table.h
 --- table.h 11 Dec 2005 20:31:21 -  1.7
 +++ table.h 30 Jan 2012 14:13:30 -
 @@ -8,7 +8,7 @@
 
  struct table {
 Area   *areap;  /* area to allocate entries */
 -   short   size, nfree;/* hash size (always 2^^n), free entries */
 +   int size, nfree;/* hash size (always 2^^n), free entries */
 struct  tbl **tbls; /* hashed table items */
  };
 
 

Thanks for the report.

I could reproduce the bug, but I'm not 100% happy with your fix since
it just pushes the failure to a bigger number of vars.

It's better to check for the case like below,

-Otto

Index: table.c
===
RCS file: /cvs/src/bin/ksh/table.c,v
retrieving revision 1.13
diff -u -p -r1.13 table.c
--- table.c 17 Jan 2009 22:06:44 -  1.13
+++ table.c 31 Jan 2012 12:07:20 -
@@ -108,7 +108,10 @@ ktenter(struct table *tp, const char *n,
}
 
if (tp-nfree = 0) {   /* too full */
-   texpand(tp, 2*tp-size);
+   if (tp-size = SHRT_MAX/2)
+   texpand(tp, 2*tp-size);
+   else
+   internal_errorf(1, too many vars);
goto Search;
}

tcpdump packets get duplicated on interface gem0

2012-01-31 Thread pjp 
Synopsis:  tcpdump packets get duplicated on interface gem0
Category:  powerpc
Environment:
System  : OpenBSD 5.0
Details : OpenBSD 5.0 (GENERIC) #69: Wed Aug 17 10:17:02 MDT 2011
 
dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC

Architecture: OpenBSD.macppc
Machine : macppc
Description:
While debugging alignment issues with a software of mine on macppc I
noticed that packets on tcpdump on macppc get duplicated.  I checked the
interface on the router (also OpenBSD) and it shows no duplicated packet in
tcpdump (outgoing).
How-To-Repeat:
The macppc host is called mars, the router before it is called uranus
and I did a dns query from mars to uranus while tcpdumping on both, this is
what I did:

# dig -6 @uranus.centroid.eu centroid.eu soa 

And this is what the packet dump on mars looks like:

19:39:09.487056 172.16.2.2.43667  XXX.XX.XX.XX.53: [udp sum ok] 37641+ ? 
uranus.centroid.eu. (36) (ttl 64, id 62934, len 64)
--- duplicate #1 ---
19:39:09.494491 XXX.XX.XX.XX.53  172.16.2.2.43667: 37641 2/3/1 
uranus.centroid.eu.  2001:a60:f000:99::2, uranus.centroid.eu. (181) (ttl 
60, id 56925, len 209)
19:39:09.494510 XXX.XXX.XXX.XXX.53  172.16.2.2.43667: 37641 2/3/1 
uranus.centroid.eu.  2001:a60:f000:99::2, uranus.centroid.eu. (181) (ttl 
60, id 56925, len 209)
-
19:39:09.499766 2001:a60:f074:5::2.2745  2001:a60:f000:99::2.53: [udp sum ok] 
49849+ SOA? centroid.eu. (29) (len 37, hlim 64)
--- duplicate #2 ---
19:39:09.500350 2001:a60:f000:99::2.53  2001:a60:f074:5::2.2745: 49849*- 1/0/0 
centroid.eu. SOA[|domain] (len 84, hlim 64)
19:39:09.500364 2001:a60:f000:99::2.53  2001:a60:f074:5::2.2745: 49849*- 1/0/0 
centroid.eu. SOA[|domain] (len 84, hlim 64)
-

And this is what the tcpdump on uranus looked like:

19:39:09.469020 172.16.2.2.43667  XXX.XXX.XX.XXX.53: [udp sum ok] 37641+ ? 
uranus.centroid.eu. (36) (ttl 64, id 62934, len 64)
19:39:09.476323 XXX.XXX.XXX.XXX.53  172.16.2.2.43667: 37641 2/3/1 
uranus.centroid.eu.  2001:a60:f000:99::2, uranus.centroid.eu. (181) (ttl 
60, id 56925, len 209)
19:39:09.481761 2001:a60:f074:5::2.2745  2001:a60:f000:99::2.53: [udp sum ok] 
49849+ SOA? centroid.eu. (29) (len 37, hlim 64)
19:39:09.482190 2001:a60:f000:99::2.53  2001:a60:f074:5::2.2745: 49849*- 1/0/0 
centroid.eu. SOA[|domain] (len 84, hlim 64)

I have XXX'ed out the IPv4 address of my default nameserver to protect 
innocent me.  As you can see there is duplication.
Fix:
none provided.


dmesg:
OpenBSD 5.0 (GENERIC) #69: Wed Aug 17 10:17:02 MDT 2011
dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC
real mem = 805306368 (768MB)
avail mem = 768524288 (732MB)
mainbus0 at root: model PowerMac5,1
cpu0 at mainbus0: 7400 (Revision 0x209): 450 MHz: 1MB backside cache
mem0 at mainbus0
spdmem0 at mem0: 256MB SDRAM non-parity PC133CL2
spdmem1 at mem0: 256MB SDRAM non-parity PC133CL2
spdmem2 at mem0: 256MB SDRAM non-parity PC133CL2
memc0 at mainbus0: uni-n
kiic0 at memc0 offset 0xf8001000
iic0 at kiic0
mpcpcibr0 at mainbus0 pci: uni-north, Revision 0xff
pci0 at mpcpcibr0 bus 0
pchb0 at pci0 dev 11 function 0 Apple Uni-N AGP rev 0x00
vgafb0 at pci0 dev 16 function 0 ATI Rage Fury rev 0x00, mmio
wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation)
mpcpcibr1 at mainbus0 pci: uni-north, Revision 0x16
pci1 at mpcpcibr1 bus 0
pchb1 at pci1 dev 11 function 0 Apple Uni-N rev 0x00
macobio0 at pci1 dev 23 function 0 Apple Keylargo rev 0x03
openpic0 at macobio0 offset 0x4: version 0x4614 little endian
macgpio0 at macobio0 offset 0x50
macgpio1 at macgpio0 irq 47
pgs0 at macgpio0: irq 55
i2s at macobio0 offset 0x1 not configured
escc-legacy at macobio0 offset 0x12000 not configured
zsc0 at macobio0 offset 0x13000: irq 22,50
zstty0 at zsc0 channel 0
zstty1 at zsc0 channel 1
timer at macobio0 offset 0x15000 not configured
adb0 at macobio0 offset 0x16000 irq 25: via-pmu, 0 targets
apm0 at adb0: battery flags 0x9, 0% charged
kiic1 at macobio0 offset 0x18000
iic1 at kiic1
wdc0 at macobio0 offset 0x1f000 irq 19: DMA
wd0 at wdc0 channel 0 drive 0: KINGSTON SVP100S264G
wd0: 16-sector PIO, LBA48, 61057MB, 125045424 sectors
atapiscsi0 at wdc0 channel 0 drive 1
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: MATSHITA, DVD-ROM SR-8186, F213 ATAPI 5/cdrom 
removable
wd0(wdc0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 2
cd0(wdc0:0:1): using PIO mode 4, DMA mode 2, Ultra-DMA mode 2
wdc1 at macobio0 offset 0x2 irq 20: DMA
wdc2 at macobio0 offset 0x21000 irq 21: DMA
ohci0 at pci1 dev 24 function 0 Apple USB rev 0x00: irq 27, version 1.0
ohci1 at pci1 dev 25 function 0 Apple USB rev 0x00: irq 28, version 1.0
TI TSB12LV26 FireWire rev 0x00 at pci1 dev 26 function 0 not configured
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 Apple OHCI root hub rev 1.00/1.00 addr 1
usb1 at ohci1: USB revision 1.0
uhub1 at usb1 Apple OHCI root hub

Re: [PATCH][BUG] ksh / sh segfault

2012-01-31 Thread Michael Niedermayer 
On Tue, Jan 31, 2012 at 01:10:28PM +0100, Otto Moerbeek wrote:
 On Mon, Jan 30, 2012 at 03:18:04PM +0100, Michael Niedermayer wrote:

  Hi
 
  Our automated tests for FFmpeg (http://fate.ffmpeg.org/) have yesterday
  found a segfault in openbsds /bin/sh.
 
  Analysis revealed that it was triggered by too many variables
  That is something like
 
  #!/bin/sh
 
  i=0
  while true ; do
  eval X${i}=yes
  i=$(($i+1))
  test $i -gt 17000  break
  done
 
  will segfault.
 
  The following patch fixes it: (which we are currently using on our
  openbsd fate client)
 
  Index: table.h
  ===
  RCS file: /cvs/src/bin/ksh/table.h,v
  retrieving revision 1.7
  diff -u -r1.7 table.h
  --- table.h 11 Dec 2005 20:31:21 -  1.7
  +++ table.h 30 Jan 2012 14:13:30 -
  @@ -8,7 +8,7 @@
 
   struct table {
  Area   *areap;  /* area to allocate entries */
  -   short   size, nfree;/* hash size (always 2^^n), free entries
*/
  +   int size, nfree;/* hash size (always 2^^n), free entries
*/
  struct  tbl **tbls; /* hashed table items */
   };
 
 

 Thanks for the report.

 I could reproduce the bug, but I'm not 100% happy with your fix since
 it just pushes the failure to a bigger number of vars.

 It's better to check for the case like below,

yes, absolutely a check is needed.
doing the check at SHORT_MAX/2 though would likely just lead ffmpegs
configure to fail with too many vars
Some further investigation shows that code like:
i=0
while true ; do
eval X=\$X${i}

i=$(($i+1))
test $i -gt 17000  break
done

also fails, iam not sure why ksh generates entries in the table for
this

another (minor) issue ive noticed is that the hashes used are
strongly biased toward the last chars due to
h = 2*h + *n++;
in hash()
which shifts the first chars to the MSBs and then out while only the
LSB are used as index

as many of our variables look like
bar_decoder_deps
foobar_decoder_deps
bar_decoder_checked
foobar_decoder_checked
...
the 15 LSB of the hash() tend to fall only in few buckets making
the hash table somewhat slow

i suspect using (bernsteins hash)
h = 33*h + *n++;
would work alot better for almost all cases
but ive not investigated or tested this much and there are many hash
functions that have better random distributions but are alot slower
i just picked bernsteins as its closest to what is used currently
and should be pretty much always better IMHO.


[...]

--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Re: tcpdump packets get duplicated on interface gem0

2012-01-31 Thread Peter J. Philipp 
On Fri, Jan 27, 2012 at 07:51:48PM +0100, p...@centroid.eu wrote:
 Synopsis:tcpdump packets get duplicated on interface gem0
 Category:powerpc
 Environment:
   System  : OpenBSD 5.0
   Details : OpenBSD 5.0 (GENERIC) #69: Wed Aug 17 10:17:02 MDT 2011

 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC


Hmmm.  I can't reproduce this issue after having compiled GEM_DEBUG into 
the kernel and doing a debug printf in bpf_mtap().  I did swap the ethernet
cross over cable though, which is connected between uranus and mars.
Perhaps that did it.  In which case I'm really sorry for causing noise and
misleading people, I should have checked the cable before.

Good night,

-peter

Re: [PATCH][BUG] ksh / sh segfault

2012-01-31 Thread Otto Moerbeek 
On Tue, Jan 31, 2012 at 09:10:25PM +0100, Michael Niedermayer wrote:

 On Tue, Jan 31, 2012 at 01:10:28PM +0100, Otto Moerbeek wrote:
  On Mon, Jan 30, 2012 at 03:18:04PM +0100, Michael Niedermayer wrote:
  
   Hi
   
   Our automated tests for FFmpeg (http://fate.ffmpeg.org/) have yesterday
   found a segfault in openbsds /bin/sh.
   
   Analysis revealed that it was triggered by too many variables
   That is something like
   
   #!/bin/sh
   
   i=0
   while true ; do
   eval X${i}=yes
   i=$(($i+1))
   test $i -gt 17000  break
   done
   
   will segfault.
   
   The following patch fixes it: (which we are currently using on our
   openbsd fate client)
   
   Index: table.h
   ===
   RCS file: /cvs/src/bin/ksh/table.h,v
   retrieving revision 1.7
   diff -u -r1.7 table.h
   --- table.h 11 Dec 2005 20:31:21 -  1.7
   +++ table.h 30 Jan 2012 14:13:30 -
   @@ -8,7 +8,7 @@
   
struct table {
   Area   *areap;  /* area to allocate entries */
   -   short   size, nfree;/* hash size (always 2^^n), free entries 
   */
   +   int size, nfree;/* hash size (always 2^^n), free entries 
   */
   struct  tbl **tbls; /* hashed table items */
};
   
   
  
  Thanks for the report.
  
  I could reproduce the bug, but I'm not 100% happy with your fix since
  it just pushes the failure to a bigger number of vars.
  
  It's better to check for the case like below,
 
 yes, absolutely a check is needed.
 doing the check at SHORT_MAX/2 though would likely just lead ffmpegs
 configure to fail with too many vars

But what does the test actually tries to find out? Is this just a test
creating many vars for no real reason or is this something real and not
contrived?

 Some further investigation shows that code like:
 i=0
 while true ; do
 eval X=\$X${i}
 
 i=$(($i+1))
 test $i -gt 17000  break
 done
 
 also fails, iam not sure why ksh generates entries in the table for
 this

Will look into this.

 
 another (minor) issue ive noticed is that the hashes used are
 strongly biased toward the last chars due to
 h = 2*h + *n++;
 in hash()
 which shifts the first chars to the MSBs and then out while only the
 LSB are used as index
 
 as many of our variables look like
 bar_decoder_deps
 foobar_decoder_deps
 bar_decoder_checked
 foobar_decoder_checked
 ...
 the 15 LSB of the hash() tend to fall only in few buckets making
 the hash table somewhat slow
 
 i suspect using (bernsteins hash)
 h = 33*h + *n++;
 would work alot better for almost all cases
 but ive not investigated or tested this much and there are many hash
 functions that have better random distributions but are alot slower
 i just picked bernsteins as its closest to what is used currently
 and should be pretty much always better IMHO.

Yeah, well, that is not something for now (we're close to lock before
5.1 release).

-Otto

Re: [PATCH][BUG] ksh / sh segfault

2012-01-31 Thread Michael Niedermayer 
On Tue, Jan 31, 2012 at 10:36:15PM +0100, Otto Moerbeek wrote:
 On Tue, Jan 31, 2012 at 09:10:25PM +0100, Michael Niedermayer wrote:

  On Tue, Jan 31, 2012 at 01:10:28PM +0100, Otto Moerbeek wrote:
   On Mon, Jan 30, 2012 at 03:18:04PM +0100, Michael Niedermayer wrote:
  
Hi
   
Our automated tests for FFmpeg (http://fate.ffmpeg.org/) have
yesterday
found a segfault in openbsds /bin/sh.
   
Analysis revealed that it was triggered by too many variables
That is something like
   
#!/bin/sh
   
i=0
while true ; do
eval X${i}=yes
i=$(($i+1))
test $i -gt 17000  break
done
   
will segfault.
   
The following patch fixes it: (which we are currently using on our
openbsd fate client)
   
Index: table.h
===
RCS file: /cvs/src/bin/ksh/table.h,v
retrieving revision 1.7
diff -u -r1.7 table.h
--- table.h 11 Dec 2005 20:31:21 -  1.7
+++ table.h 30 Jan 2012 14:13:30 -
@@ -8,7 +8,7 @@
   
 struct table {
Area   *areap;  /* area to allocate entries */
-   short   size, nfree;/* hash size (always 2^^n), free
entries */
+   int size, nfree;/* hash size (always 2^^n), free
entries */
struct  tbl **tbls; /* hashed table items */
 };
   
   
  
   Thanks for the report.
  
   I could reproduce the bug, but I'm not 100% happy with your fix since
   it just pushes the failure to a bigger number of vars.
  
   It's better to check for the case like below,
 
  yes, absolutely a check is needed.
  doing the check at SHORT_MAX/2 though would likely just lead ffmpegs
  configure to fail with too many vars

 But what does the test actually tries to find out? Is this just a test
 creating many vars for no real reason or is this something real and not
 contrived?

its not contrived, the segfault actually happened with ffmpegs
configure:
http://fate.ffmpeg.org/log.cgi?time=20120129184603log=configureslot=x86_64-
openbsd4.8-gcc3.3
and went away once i changed the vars from short to int in /bin/sh
it also went away by using bash
Ive also done a quick test with 5.0 to make sure this hasnt been fixed
by some other means

The number of actually created variables in our configure is around
3500 (counted by using set | grep '=' | wc at the end of it)

by dumping the entries of the hash table at the time of it hitting
the SHORT_MAX/2 limit i found that there was alot more in there then
what i naively had expected from the set output.
These are created by:
eval dep_all=\$${cfg}_deps
eval dep_any=\$${cfg}_deps_any
eval dep_sel=\$${cfg}_select
eval dep_sgs=\$${cfg}_suggest
eval dep_ifa=\$${cfg}_if
eval dep_ifn=\$${cfg}_if_any
of our check_deps() function
see: http://source.ffmpeg.org/?p=ffmpeg.git;a=blob_plain;f=configure;hb=HEAD



  Some further investigation shows that code like:
  i=0
  while true ; do
  eval X=\$X${i}
 
  i=$(($i+1))
  test $i -gt 17000  break
  done
 
  also fails, iam not sure why ksh generates entries in the table for
  this

 Will look into this.

thanks

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

info@infointerbanca

2012-01-31 Thread n...@infointerbanca.com 
Novit` Finanziamenti.
assistenza-aziende-in-crisi
fidjussioni-e-cauzioni
fondo-garanzia-mutuo-prima-casa
sospensione-rate-mutuo
 prestito-antiusura
prevenzione-insoluti



Per non ricevere ulteriori aggiornamenti clicchi qui.