48 core server...

2013-09-17 Thread Michael Chen

I'm considering bidding on this 48-core box:

http://www.ebay.com/itm/Supermicro-A-Server-1042G-TF-1U-H8QG6-4-CPUS-48-cores-2-2Ghz-128GB-RAM-/151119828428?pt=COMP_EN_Servers&hash=item232f7195cc

Does anyone have experience with it and can I use all the cores?

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: Davicom DM9000C driver

2012-09-20 Thread Michael Chen
Dear Arnd and Linux Expert,

First of all, appreciate you all for your efforts on our DM9000C driver. 

Davicom Semiconductor Inc. is a fabless IC design house, located in Taiwan.
DM9000C is 10/100Mbps Ethernet IC with ISA-like interface.

Meanwhile, to facilitate the coming works with you efficiently, the key
members at Davicom side will be:
Mr. Allen Huang, PM
Mr. Russell Liu, Sr. FAE
Mr. Joseph Chang, Sr. Software Manager

Look forward to your guidance to make our product driver conform Linux.

Thanks.

BR,
Michael Chen
Director
Davicom Semiconductor Inc.
www.davicom.com.tw

-Original Message-
From: Arnd Bergmann [mailto:a...@arndb.de] 
Sent: Thursday, September 20, 2012 7:03 PM
To: Jonathan Corbet
Cc: Allen Huang ("黃偉格"); linux-kernel@vger.kernel.org; 'Michael Chen';
'Charles'; 'Joseph Chang'
Subject: Re: Davicom DM9000C driver

On Thursday 20 September 2012, Arnd Bergmann wrote:
> On Wednesday 19 September 2012, Jonathan Corbet wrote:
> > On Wed, 19 Sep 2012 13:58:08 +0800
> > Allen Huang (黃偉格)   wrote:
> > 
> > > I'm Allen Huang from Davicom. We are hereby opensourcing the linux
> > > driver for our DM9000C. 
> > 
> > That is great, but please read the development process documentation on
> > how best to submit something like this.  We would much rather see a
patch
> > (inline, not as an attachment) to facilitate the review.
> 
> More importantly, the patch should be against the version that is
> already present in the kernel as drivers/net/ethernet/davicom/dm9000.c,
> which appears to be mostly the same as the version that is submitted
> here.
> 
> So while all the comments on the driver are valuable, they also apply
> to the code we already have since 2005.

For fun, I've also tracked down the version that the new submission is
branched from, it's 2.6.29 with a small number of bug fixes that
are in later version. Here is the diff against the 2.6.29 version
of the driver. There are a few changes to the PHY handling that
are not also upstream in 3.6. It's probably worth submitting them
separately with a good explanation why they are required.

Arnd

diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index 254ec62..2cd4f0b 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -17,6 +17,13 @@
  * Additional updates, Copyright:
  * Ben Dooks 
  * Sascha Hauer 
+ *  
+ * 2010.07.20 V_R1 1.Write PHY Reg27 = 0xE100
+ *  2.Just
enable PHY once after GPIO setting in dm9000_init_dm9000()
+ *  3.Remove
power down PHY in dm9000_shutdown()
+ * 2010.07.20 V_R2 1.Delay 20ms after PHY power on
+ *  2.Reset PHY
after PHY power on in dm9000_init_dm9000()
+ * 2012.06.05 KT2.6.31_R2 1. Add the solution to fix the power-on FIFO data
bytes shift issue! (Wr NCR 0x03)
  */
 
 #include 
@@ -25,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -45,7 +53,7 @@
 #define DM9000_PHY 0x40/* PHY address 0x01 */
 
 #define CARDNAME   "dm9000"
-#define DRV_VERSION"1.31"
+#define DRV_VERSION"2.6.31"
 
 /*
  * Transmit timeout, default 5 seconds.
@@ -126,6 +134,10 @@ typedef struct board_info {
u32 msg_enable;
 } board_info_t;
 
+static void
+dm9000_phy_write(struct net_device *dev,
+int phyaddr_unused, int reg, int value);
+
 /* debug code */
 
 #define dm9000_dbg(db, lev, msg...) do {   \
@@ -556,6 +568,18 @@ static void dm9000_show_carrier(board_info_t *db,
dev_info(db->dev, "%s: link down\n", ndev->name);
 }
 
+
+static unsigned char dm9000_type_to_char(enum dm9000_type type)
+{
+   switch (type) {
+   case TYPE_DM9000E: return 'e';
+   case TYPE_DM9000A: return 'a';
+   case TYPE_DM9000B: return 'b';
+   }
+
+   return '?';
+}
+
 static void
 dm9000_poll_work(struct work_struct *w)
 {
@@ -563,8 +587,11 @@ dm9000_poll_work(struct work_struct *w)
board_info_t *db = container_of(dw, board_info_t, phy_poll);
struct net_device *ndev = db->ndev;
 
-   if (db->flags & DM9000_PLATF_SIMPLE_PHY &&
-   !(db->flags & DM9000_PLATF_EXT_PHY)) {
+//JJ2
+// if (db->flags & DM9000_PLATF_SIMPLE_PHY &&
+// !(db->flags & DM9000_PLATF_EXT_PHY)) {
+//  =
+   if(1){  
unsigned nsr = dm9000_read_locked(db, DM9000_NSR);
unsigned old_carrier = netif_carrier_ok(ndev) ? 1 : 0;
unsigned new_carrier;
@@ -572,6 +599,12 @@ dm9000_poll_work(struct work_struct *w)
n

just a test

2001-02-22 Thread michael chen



-- 
Best regards,
 michael  mailto:[EMAIL PROTECTED]


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



About Celeron processor memory barrier problem

2000-12-23 Thread michael chen

Hi,
I found that when I compiled the 2.4 kernel with the option
of Pentium III or Pentium 4 on a Celeron's PC, it could cause  the
system hang at very beginning boot stage, and I found the problem
is cause by the fact that Intel Celeron doesn't have a real memory
barrier,but when you choose the Pentium III option, the kernel
assume the processor has a real memory barrier.
Here is a patch to fix it:

Merry Christmas :)
    Michael Chen

diff -Nur linux/include/asm-i386/system.h linux.new/include/asm-i386/system.h
--- linux/include/asm-i386/system.h Mon Dec 11 19:26:39 2000
+++ linux.new/include/asm-i386/system.h Sat Dec 23 16:06:01 2000
@@ -274,7 +274,14 @@
 #ifndef CONFIG_X86_XMM
 #define mb()   __asm__ __volatile__ ("lock; addl $0,0(%%esp)": : :"memory")
 #else
-#define mb()   __asm__ __volatile__ ("sfence": : :"memory")
+#define mb()  do { \
+   if ( cpu_has_xmm ) { \
+   asm volatile("sfence": : :"memory"); \
+   } \
+   else { \
+   asm volatile("lock; addl $0,0(%%esp)": : :"memory"); \
+   } \
+} while (0)
 #endif
 #define rmb()  mb()
 #define wmb()  __asm__ __volatile__ ("": : :"memory")
diff -Nur linux/include/linux/tqueue.h linux.new/include/linux/tqueue.h
--- linux/include/linux/tqueue.hSat Dec 23 16:16:44 2000
+++ linux.new/include/linux/tqueue.hSat Dec 23 16:06:01 2000
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * New proposed "bottom half" handlers:
diff -Nur linux/include/asm-i386/system.h linux.new/include/asm-i386/system.h
--- linux/include/asm-i386/system.h Mon Dec 11 19:26:39 2000
+++ linux.new/include/asm-i386/system.h Sat Dec 23 16:06:01 2000
@@ -274,7 +274,14 @@
 #ifndef CONFIG_X86_XMM
 #define mb()   __asm__ __volatile__ ("lock; addl $0,0(%%esp)": : :"memory")
 #else
-#define mb()   __asm__ __volatile__ ("sfence": : :"memory")
+#define mb()  do { \
+   if ( cpu_has_xmm ) { \
+   asm volatile("sfence": : :"memory"); \
+   } \
+   else { \
+   asm volatile("lock; addl $0,0(%%esp)": : :"memory"); \
+   } \
+} while (0)
 #endif
 #define rmb()  mb()
 #define wmb()  __asm__ __volatile__ ("": : :"memory")
diff -Nur linux/include/linux/tqueue.h linux.new/include/linux/tqueue.h
--- linux/include/linux/tqueue.hSat Dec 23 16:16:44 2000
+++ linux.new/include/linux/tqueue.hSat Dec 23 16:06:01 2000
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * New proposed "bottom half" handlers:


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/