»¥ÁªÍøʱ´ú,ÄúÓÿͻ§¹Øϵ¹ÜÀíϵͳÁËÂð?

»¥ÁªÍøʱ´ú,ÄúÓÿͻ§¹Øϵ¹ÜÀíϵͳÁËÂð?

[0x3ohg4YJZwMMw]

±¾ÈËÖ£ÖØÍƼöÕâÌ׿ͻ§¹Øϵ¹ÜÀíϵͳ(StartCRM),B/S½á¹¹,¹¦ÄÜÇ¿´ó
,½çÃæ¼ò½à,ʹÓ÷½±ã

Ëüͨ¹ýÏîÄ¿¹ÜÀí£¬Îĵµ¿â¹ÜÀí£¬ÏúÊÛ±¨¸æ£¬¾ºÕù¶ÔÊÖ¹ÜÀí£¬ÈÕÀú¹ÜÀí£¬
²úÆ·¹ÜÀí£¬ÏúÊÛÔ¤ÆÚ¹ÜÀíÆß´ó¹¦ÄÜÄ£¿é£¬Îª»¥ÁªÍøʱ´úµÄÏúÊÛ¹ÜÀíÌá
¹©ÁËȫеÄÆóÒµ£­¿Í»§½â¾ö·½°¸¡£Í¨¹ýËü¿ÉÒԲ鿴ºÍ¸üÐÂÒÔÏÂÐÅÏ¢£º

¿Í»§£º ºÏ×÷»ï°éµÄÏêϸÐÅÏ¢
ÁªÏµÈË£ºÓë¿Í»§ÓйØϵµÄÌض¨È˵ÄÁªÏµÐÅÏ¢
ÏßË÷£º DZÔÚ¿Í»§µÄÏêϸÐÅÏ¢
»ú»á£º Óëij¿Í»§ÕýÔÚ½øÐеÄÌض¨ÏúÊÛÐÅÏ¢
ÏúÊÛÔ¤²â£ºÃ¿²Æ¼¾µÄ¼Æ»®ÏúÊÛÄ¿±ê
ÏúÊÛ±¨±í£ºµ¥¸öÏúÊÛÈËÔ±»òÕû¸öÏúÊÛ»ú¹¹µÄÏúÊÛ½á¹û

ÁíÍ⣬ÄúÒ²¿ÉÒÔ²Ù×÷ÈçÏÂÐÅÏ¢£º

»î¶¯£¬ÈÎÎñºÍÆäËûÄúÐèÒª²é¿´µÄÈÕÀúʼþ
¾ºÕù¶ÔÊֺͺÏ×÷»ï°éÐÅÏ¢
ÁªÏµÈË£¬»ú»á£¬¿Í»§µÄÐÅÏ¢

StartCRM¿Í»§¹Øϵ¹ÜÀíϵͳʹÄúµÄ¹«Ë¾¿ÉÒÔÇáËɵض©ÖƸ÷ÖÖ¸öÐÔ»¯µÄ½çÃ棬
±»Ö¸¶¨µÄϵͳ¹ÜÀíÔ±¿ÉÒÔΪ¸÷¸ö×éÉèÖò»Í¬µÄȨÏÞ¡£

¸ü¶à×ÊÁÏÐÅÏ¢,Çë·ÃÎÊ http://starterp.oicp.net/crm/help/help.asp?title=ϵͳ¼ò½é

²âÊÔ,Çë·ÃÎÊ  http://starterp.oicp.net/crm/default.asp

ÕʺÅ:admin ÃÜÂë:admin ѯ¼ÛÇëÖµç 086-755-61325311 ²ÜÏÈÉú

[PATCH v3 2/5] w1_therm: adding sysfs entry to check device power

[Akira Shimahara]

Patch for enhacement of w1_therm module.
Adding ext_power sysfs entry (RO). Return the power status of the device:
 - 0: device parasite powered
 - 1: device externally powered
 - xx: xx is kernel error

Creating Documentation/ABI/testing/sysfs-driver-w1_therm for the old 
driver sysfs and this new entry.

Signed-off-by: Akira Shimahara <akira215corp@gmail.com>
---
 .../ABI/testing/sysfs-driver-w1_therm         | 29 ++++++
 drivers/w1/slaves/w1_therm.c                  | 93 ++++++++++++++++++-
 drivers/w1/slaves/w1_therm.h                  | 44 ++++++++-
 3 files changed, 163 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-w1_therm

diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm
new file mode 100644
index 0000000..9aaf625
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-w1_therm
@@ -0,0 +1,29 @@
+What:		/sys/bus/w1/devices/.../ext_power
+Date:		Apr 2020
+Contact:	Akira Shimahara <akira215corp@gmail.com>
+Description:
+		(RO) return the power status by asking the device
+			* `0`: device parasite powered
+			* `1`: device externally powered
+			* `-xx`: xx is kernel error when reading power status
+Users:		any user space application which wants to communicate with
+		w1_term device
+
+
+What:		/sys/bus/w1/devices/.../w1_slave
+Date:		Apr 2020
+Contact:	Akira Shimahara <akira215corp@gmail.com>
+Description:
+		(RW) return the temperature in 1/1000 degC.
+		*read*: return 2 lines with the hexa output data sent on the
+		bus, return the CRC check and temperature in 1/1000 degC
+		*write* :
+			* `0` : save the 2 or 3 bytes to the device EEPROM
+			(i.e. TH, TL and config register)
+			* `9..12` : set the device resolution in RAM
+			(if supported)
+			* Anything else: do nothing
+		refer to Documentation/w1/slaves/w1_therm.rst for detailed
+		information.
+Users:		any user space application which wants to communicate with
+		w1_term device
\ No newline at end of file
diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
index 6245950..a530853 100644
--- a/drivers/w1/slaves/w1_therm.c
+++ b/drivers/w1/slaves/w1_therm.c
@@ -39,12 +39,14 @@ module_param_named(strong_pullup, w1_strong_pullup, int, 0);
 
 static struct attribute *w1_therm_attrs[] = {
 	&dev_attr_w1_slave.attr,
+	&dev_attr_ext_power.attr,
 	NULL,
 };
 
 static struct attribute *w1_ds28ea00_attrs[] = {
 	&dev_attr_w1_slave.attr,
 	&dev_attr_w1_seq.attr,
+	&dev_attr_ext_power.attr,
 	NULL,
 };
 
@@ -294,6 +296,26 @@ static inline int w1_DS18S20_convert_temp(u8 rom[9])
 	return t;
 }
 
+/*------------------------ Helpers Functions----------------------------*/
+
+static inline bool bus_mutex_lock(struct mutex *lock)
+{
+	int max_trying = W1_THERM_MAX_TRY;
+	/* try to acquire the mutex, if not, sleep retry_delay before retry) */
+	while (mutex_lock_interruptible(lock) != 0 && max_trying > 0) {
+		unsigned long sleep_rem;
+
+		sleep_rem = msleep_interruptible(W1_THERM_RETRY_DELAY);
+		if (!sleep_rem)
+			max_trying--;
+	}
+
+	if (!max_trying)
+		return false;	/* Didn't acquire the bus mutex */
+
+	return true;
+}
+
 /*-------------------------Interface Functions------------------------------*/
 static int w1_therm_add_slave(struct w1_slave *sl)
 {
@@ -302,6 +324,16 @@ static int w1_therm_add_slave(struct w1_slave *sl)
 	if (!sl->family_data)
 		return -ENOMEM;
 	atomic_set(THERM_REFCNT(sl->family_data), 1);
+
+	/* Getting the power mode of the device {external, parasite}*/
+	SLAVE_POWERMODE(sl) = read_powermode(sl);
+
+	if (SLAVE_POWERMODE(sl) < 0) {
+		/* no error returned as device has been added */
+		dev_warn(&sl->dev,
+			"%s: Device has been added, but power_mode may be corrupted. err=%d\n",
+			 __func__, SLAVE_POWERMODE(sl));
+	}
 	return 0;
 }
 
@@ -512,6 +544,43 @@ error:
 	return ret;
 }
 
+static int read_powermode(struct w1_slave *sl)
+{
+	struct w1_master *dev_master = sl->master;
+	int max_trying = W1_THERM_MAX_TRY;
+	int  ret = -ENODEV;
+
+	if (!sl->family_data)
+		goto error;
+
+	/* prevent the slave from going away in sleep */
+	atomic_inc(THERM_REFCNT(sl->family_data));
+
+	if (!bus_mutex_lock(&dev_master->bus_mutex)) {
+		ret = -EAGAIN;	// Didn't acquire the mutex
+		goto dec_refcnt;
+	}
+
+	while ((max_trying--) && (ret < 0)) {
+		/* safe version to select slave */
+		if (!reset_select_slave(sl)) {
+			w1_write_8(dev_master, W1_READ_PSUPPLY);
+			/* Read only one bit,
+			 * 1 is externally powered,
+			 * 0 is parasite powered
+			 */
+			ret = w1_touch_bit(dev_master, 1);
+			/* ret should be either 1 either 0 */
+		}
+	}
+	mutex_unlock(&dev_master->bus_mutex);
+
+dec_refcnt:
+	atomic_dec(THERM_REFCNT(sl->family_data));
+error:
+	return ret;
+}
+
 /*------------------------Interface sysfs--------------------------*/
 
 static ssize_t w1_slave_show(struct device *device,
@@ -565,13 +634,35 @@ static ssize_t w1_slave_store(struct device *device,
 				ret = w1_therm_families[i].eeprom(device);
 			else
 				ret = w1_therm_families[i].precision(device,
-								val);
+									val);
 			break;
 		}
 	}
 	return ret ? : size;
 }
 
+static ssize_t ext_power_show(struct device *device,
+	struct device_attribute *attr, char *buf)
+{
+	struct w1_slave *sl = dev_to_w1_slave(device);
+
+	if (!sl->family_data) {
+		dev_info(device,
+			"%s: Device not supported by the driver\n", __func__);
+		return 0;  /* No device family */
+	}
+
+	/* Getting the power mode of the device {external, parasite}*/
+	SLAVE_POWERMODE(sl) = read_powermode(sl);
+
+	if (SLAVE_POWERMODE(sl) < 0) {
+		dev_dbg(device,
+			"%s: Power_mode may be corrupted. err=%d\n",
+			__func__, SLAVE_POWERMODE(sl));
+	}
+	return sprintf(buf, "%d\n", SLAVE_POWERMODE(sl));
+}
+
 #if IS_REACHABLE(CONFIG_HWMON)
 static int w1_read_temp(struct device *device, u32 attr, int channel,
 			long *val)
diff --git a/drivers/w1/slaves/w1_therm.h b/drivers/w1/slaves/w1_therm.h
index b73af0b..2f975a4 100644
--- a/drivers/w1/slaves/w1_therm.h
+++ b/drivers/w1/slaves/w1_therm.h
@@ -25,6 +25,12 @@
 #include <linux/mutex.h>
 #include <linux/w1.h>
 
+/*----------------------------------Defines---------------------------------*/
+/* Nb of try for an operation */
+#define W1_THERM_MAX_TRY		5
+
+/* ms delay to retry bus mutex */
+#define W1_THERM_RETRY_DELAY		20
 /*----------------------------------Structs---------------------------------*/
 
 /**
@@ -47,10 +53,15 @@ struct w1_therm_family_converter {
  * struct w1_therm_family_data
  * @param rom data
  * @param refcnt ref count
+ * @param external_powered
+ *		1 device powered externally,
+ *		0 device parasite powered,
+ *		-x error or undefined
  */
 struct w1_therm_family_data {
 	uint8_t rom[9];
 	atomic_t refcnt;
+	int external_powered;
 };
 
 /**
@@ -80,11 +91,24 @@ static inline int w1_DS18B20_convert_temp(u8 rom[9]);
 static inline int w1_DS18S20_convert_temp(u8 rom[9]);
 
 /*-------------------------------Macros--------------------------------------*/
+/* return the power mode of the sl slave : 1-ext, 0-parasite, <0 unknown
+ * always test family data existence before
+ */
+#define SLAVE_POWERMODE(sl) \
+	(((struct w1_therm_family_data *)(sl->family_data))->external_powered)
 
 /* return the address of the refcnt in the family data */
 #define THERM_REFCNT(family_data) \
 	(&((struct w1_therm_family_data *)family_data)->refcnt)
 
+/*-------------------------- Helpers Functions------------------------------*/
+
+/** bus_mutex_lock() get the mutex & retry
+ *  @param lock w1 bus mutex to get
+ *  @return value true is mutex is acquired and lock, false otherwise
+ */
+static inline bool bus_mutex_lock(struct mutex *lock);
+
 /*---------------------------Hardware Functions-----------------------------*/
 
 /**
@@ -107,7 +131,14 @@ static int reset_select_slave(struct w1_slave *sl);
  */
 static ssize_t read_therm(struct device *device,
 			struct w1_slave *sl, struct therm_info *info);
-
+/** read_powermode()
+ * @brief ask the device to get its power mode {external, parasite}
+ * @param sl slave to be interrogated
+ * @return	0 parasite powered device
+ *			1 externally powered device
+ *			<0 kernel error code
+ */
+static int read_powermode(struct w1_slave *sl);
 /*----------------------------Interface sysfs-------------------------------*/
 
 /** @brief A callback function to output the temperature Old way
@@ -127,11 +158,20 @@ static ssize_t w1_slave_store(struct device *device,
 
 static ssize_t w1_seq_show(struct device *device,
 	struct device_attribute *attr, char *buf);
-
+/** @brief A callback function to output the power mode of the device
+ *	Once done, it is stored in the sl->family_data to avoid doing the test
+ *	during data read
+ *  @return	0 : device parasite powered
+ *			1 : device externally powered
+ *			-xx : xx is kernel error code
+ */
+static ssize_t ext_power_show(struct device *device,
+	struct device_attribute *attr, char *buf);
 /*-----------------------------Attributes declarations----------------------*/
 
 static DEVICE_ATTR_RW(w1_slave);
 static DEVICE_ATTR_RO(w1_seq);
+static DEVICE_ATTR_RO(ext_power);
 
 /*--------------------------Interface Functions-----------------------------*/
 
-- 
2.25.4

Re: [PATCH v3 2/5] w1_therm: adding sysfs entry to check device power

[Greg KH]

On Wed, Apr 29, 2020 at 03:32:04PM +0200, Akira Shimahara wrote:
> Patch for enhacement of w1_therm module.
> Adding ext_power sysfs entry (RO). Return the power status of the device:
>  - 0: device parasite powered
>  - 1: device externally powered
>  - xx: xx is kernel error
> 
> Creating Documentation/ABI/testing/sysfs-driver-w1_therm for the old 
> driver sysfs and this new entry.
> 
> Signed-off-by: Akira Shimahara <akira215corp@gmail.com>
> ---
>  .../ABI/testing/sysfs-driver-w1_therm         | 29 ++++++
>  drivers/w1/slaves/w1_therm.c                  | 93 ++++++++++++++++++-
>  drivers/w1/slaves/w1_therm.h                  | 44 ++++++++-
>  3 files changed, 163 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-driver-w1_therm
> 
> diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm
> new file mode 100644
> index 0000000..9aaf625
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm
> @@ -0,0 +1,29 @@
> +What:		/sys/bus/w1/devices/.../ext_power
> +Date:		Apr 2020
> +Contact:	Akira Shimahara <akira215corp@gmail.com>
> +Description:
> +		(RO) return the power status by asking the device
> +			* `0`: device parasite powered
> +			* `1`: device externally powered
> +			* `-xx`: xx is kernel error when reading power status
> +Users:		any user space application which wants to communicate with
> +		w1_term device
> +
> +
> +What:		/sys/bus/w1/devices/.../w1_slave
> +Date:		Apr 2020
> +Contact:	Akira Shimahara <akira215corp@gmail.com>
> +Description:
> +		(RW) return the temperature in 1/1000 degC.
> +		*read*: return 2 lines with the hexa output data sent on the
> +		bus, return the CRC check and temperature in 1/1000 degC

the w1_slave file returns a temperature???

And sysfs is 1 value-per-file, not multiple lines.

And as this is a temperature, what's wrong with the iio interface that
handles temperature already?  Don't go making up new userspace apis when
we already have good ones today :)

> +		*write* :
> +			* `0` : save the 2 or 3 bytes to the device EEPROM
> +			(i.e. TH, TL and config register)
> +			* `9..12` : set the device resolution in RAM
> +			(if supported)

I don't understand these write values, how do they match up to a
temperature readin?

> +			* Anything else: do nothing
> +		refer to Documentation/w1/slaves/w1_therm.rst for detailed
> +		information.
> +Users:		any user space application which wants to communicate with
> +		w1_term device
> \ No newline at end of file
> diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
> index 6245950..a530853 100644
> --- a/drivers/w1/slaves/w1_therm.c
> +++ b/drivers/w1/slaves/w1_therm.c
> @@ -39,12 +39,14 @@ module_param_named(strong_pullup, w1_strong_pullup, int, 0);
>  
>  static struct attribute *w1_therm_attrs[] = {
>  	&dev_attr_w1_slave.attr,
> +	&dev_attr_ext_power.attr,
>  	NULL,
>  };
>  
>  static struct attribute *w1_ds28ea00_attrs[] = {
>  	&dev_attr_w1_slave.attr,
>  	&dev_attr_w1_seq.attr,
> +	&dev_attr_ext_power.attr,
>  	NULL,
>  };
>  
> @@ -294,6 +296,26 @@ static inline int w1_DS18S20_convert_temp(u8 rom[9])
>  	return t;
>  }
>  
> +/*------------------------ Helpers Functions----------------------------*/
> +
> +static inline bool bus_mutex_lock(struct mutex *lock)
> +{
> +	int max_trying = W1_THERM_MAX_TRY;
> +	/* try to acquire the mutex, if not, sleep retry_delay before retry) */

Please use scripts/checkpatch.pl on your patches, it should have asked
you to put an empty line after the int definition.



> +	while (mutex_lock_interruptible(lock) != 0 && max_trying > 0) {
> +		unsigned long sleep_rem;
> +
> +		sleep_rem = msleep_interruptible(W1_THERM_RETRY_DELAY);
> +		if (!sleep_rem)
> +			max_trying--;
> +	}
> +
> +	if (!max_trying)
> +		return false;	/* Didn't acquire the bus mutex */
> +
> +	return true;
> +}
> +
>  /*-------------------------Interface Functions------------------------------*/
>  static int w1_therm_add_slave(struct w1_slave *sl)
>  {
> @@ -302,6 +324,16 @@ static int w1_therm_add_slave(struct w1_slave *sl)
>  	if (!sl->family_data)
>  		return -ENOMEM;
>  	atomic_set(THERM_REFCNT(sl->family_data), 1);
> +
> +	/* Getting the power mode of the device {external, parasite}*/
> +	SLAVE_POWERMODE(sl) = read_powermode(sl);
> +
> +	if (SLAVE_POWERMODE(sl) < 0) {
> +		/* no error returned as device has been added */
> +		dev_warn(&sl->dev,
> +			"%s: Device has been added, but power_mode may be corrupted. err=%d\n",
> +			 __func__, SLAVE_POWERMODE(sl));
> +	}
>  	return 0;
>  }
>  
> @@ -512,6 +544,43 @@ error:
>  	return ret;
>  }
>  
> +static int read_powermode(struct w1_slave *sl)
> +{
> +	struct w1_master *dev_master = sl->master;
> +	int max_trying = W1_THERM_MAX_TRY;
> +	int  ret = -ENODEV;
> +
> +	if (!sl->family_data)
> +		goto error;
> +
> +	/* prevent the slave from going away in sleep */
> +	atomic_inc(THERM_REFCNT(sl->family_data));
> +
> +	if (!bus_mutex_lock(&dev_master->bus_mutex)) {
> +		ret = -EAGAIN;	// Didn't acquire the mutex
> +		goto dec_refcnt;
> +	}
> +
> +	while ((max_trying--) && (ret < 0)) {
> +		/* safe version to select slave */
> +		if (!reset_select_slave(sl)) {
> +			w1_write_8(dev_master, W1_READ_PSUPPLY);
> +			/* Read only one bit,
> +			 * 1 is externally powered,
> +			 * 0 is parasite powered
> +			 */
> +			ret = w1_touch_bit(dev_master, 1);
> +			/* ret should be either 1 either 0 */
> +		}
> +	}
> +	mutex_unlock(&dev_master->bus_mutex);
> +
> +dec_refcnt:
> +	atomic_dec(THERM_REFCNT(sl->family_data));
> +error:
> +	return ret;
> +}
> +
>  /*------------------------Interface sysfs--------------------------*/
>  
>  static ssize_t w1_slave_show(struct device *device,
> @@ -565,13 +634,35 @@ static ssize_t w1_slave_store(struct device *device,
>  				ret = w1_therm_families[i].eeprom(device);
>  			else
>  				ret = w1_therm_families[i].precision(device,
> -								val);
> +									val);
>  			break;
>  		}
>  	}
>  	return ret ? : size;
>  }
>  
> +static ssize_t ext_power_show(struct device *device,
> +	struct device_attribute *attr, char *buf)
> +{
> +	struct w1_slave *sl = dev_to_w1_slave(device);
> +
> +	if (!sl->family_data) {
> +		dev_info(device,
> +			"%s: Device not supported by the driver\n", __func__);
> +		return 0;  /* No device family */
> +	}
> +
> +	/* Getting the power mode of the device {external, parasite}*/
> +	SLAVE_POWERMODE(sl) = read_powermode(sl);
> +
> +	if (SLAVE_POWERMODE(sl) < 0) {
> +		dev_dbg(device,
> +			"%s: Power_mode may be corrupted. err=%d\n",
> +			__func__, SLAVE_POWERMODE(sl));
> +	}
> +	return sprintf(buf, "%d\n", SLAVE_POWERMODE(sl));
> +}
> +
>  #if IS_REACHABLE(CONFIG_HWMON)
>  static int w1_read_temp(struct device *device, u32 attr, int channel,
>  			long *val)
> diff --git a/drivers/w1/slaves/w1_therm.h b/drivers/w1/slaves/w1_therm.h
> index b73af0b..2f975a4 100644
> --- a/drivers/w1/slaves/w1_therm.h
> +++ b/drivers/w1/slaves/w1_therm.h
> @@ -25,6 +25,12 @@
>  #include <linux/mutex.h>
>  #include <linux/w1.h>
>  
> +/*----------------------------------Defines---------------------------------*/

No real need for this, we can see defines just fine :)

thanks,

greg k-h

_

[Akira shimahara]

Le mercredi 29 avril 2020 à 15:46 +0200, Greg KH a écrit :
> On Wed, Apr 29, 2020 at 03:32:04PM +0200, Akira Shimahara wrote:
> > Patch for enhacement of w1_therm module.
> > Adding ext_power sysfs entry (RO). Return the power status of the
> > device:
> >  - 0: device parasite powered
> >  - 1: device externally powered
> >  - xx: xx is kernel error
> > 
> > Creating Documentation/ABI/testing/sysfs-driver-w1_therm for the
> > old 
> > driver sysfs and this new entry.
> > 
> > Signed-off-by: Akira Shimahara <akira215corp@gmail.com>
> > ---
> >  .../ABI/testing/sysfs-driver-w1_therm         | 29 ++++++
> >  drivers/w1/slaves/w1_therm.c                  | 93
> > ++++++++++++++++++-
> >  drivers/w1/slaves/w1_therm.h                  | 44 ++++++++-
> >  3 files changed, 163 insertions(+), 3 deletions(-)
> >  create mode 100644 Documentation/ABI/testing/sysfs-driver-w1_therm
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm
> > b/Documentation/ABI/testing/sysfs-driver-w1_therm
> > new file mode 100644
> > index 0000000..9aaf625
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm
> > @@ -0,0 +1,29 @@
> > +What:		/sys/bus/w1/devices/.../ext_power
> > +Date:		Apr 2020
> > +Contact:	Akira Shimahara <akira215corp@gmail.com>
> > +Description:
> > +		(RO) return the power status by asking the device
> > +			* `0`: device parasite powered
> > +			* `1`: device externally powered
> > +			* `-xx`: xx is kernel error when reading power
> > status
> > +Users:		any user space application which wants to
> > communicate with
> > +		w1_term device
> > +
> > +
> > +What:		/sys/bus/w1/devices/.../w1_slave
> > +Date:		Apr 2020
> > +Contact:	Akira Shimahara <akira215corp@gmail.com>
> > +Description:
> > +		(RW) return the temperature in 1/1000 degC.
> > +		*read*: return 2 lines with the hexa output data sent
> > on the
> > +		bus, return the CRC check and temperature in 1/1000
> > degC
> 
> the w1_slave file returns a temperature???
> 
> And sysfs is 1 value-per-file, not multiple lines.
> 
> And as this is a temperature, what's wrong with the iio interface
> that
> handles temperature already?  Don't go making up new userspace apis
> when
> we already have good ones today :)

Yes the existing syfs w1_slave return 2 lines, user application 
catch normally only the temperature. We keep it as many userspace
application are already based on this output, but to ease user
to catch the only purpose of these devices (temperature sensors),
we added on entry which return only the temperature (avoiding
string parsing ,... on both side i.e. driver and user app).

> 
> > +		*write* :
> > +			* `0` : save the 2 or 3 bytes to the device
> > EEPROM
> > +			(i.e. TH, TL and config register)
> > +			* `9..12` : set the device resolution in RAM
> > +			(if supported)
> 
> I don't understand these write values, how do they match up to a
> temperature readin?

This is the previous implementation, and yes, it was not very clear.
These value are not connected to temperature reading. The sysfs 
entry was used to enter user value to device RAM, in 2 registers:
if 0 it trigger a save to the device EEPROM, if the value is between
9 and 12, it stores in the resolution register of the device.
In the next patches, we add more sysfs entries to separate things.

> 
> > +			* Anything else: do nothing
> > +		refer to Documentation/w1/slaves/w1_therm.rst for
> > detailed
> > +		information.
> > +Users:		any user space application which wants to
> > communicate with
> > +		w1_term device
> > \ No newline at end of file
> > diff --git a/drivers/w1/slaves/w1_therm.c
> > b/drivers/w1/slaves/w1_therm.c
> > index 6245950..a530853 100644
> > --- a/drivers/w1/slaves/w1_therm.c
> > +++ b/drivers/w1/slaves/w1_therm.c
> > @@ -39,12 +39,14 @@ module_param_named(strong_pullup,
> > w1_strong_pullup, int, 0);
> >  
> >  static struct attribute *w1_therm_attrs[] = {
> >  	&dev_attr_w1_slave.attr,
> > +	&dev_attr_ext_power.attr,
> >  	NULL,
> >  };
> >  
> >  static struct attribute *w1_ds28ea00_attrs[] = {
> >  	&dev_attr_w1_slave.attr,
> >  	&dev_attr_w1_seq.attr,
> > +	&dev_attr_ext_power.attr,
> >  	NULL,
> >  };
> >  
> > @@ -294,6 +296,26 @@ static inline int w1_DS18S20_convert_temp(u8
> > rom[9])
> >  	return t;
> >  }
> >  
> > +/*------------------------ Helpers Functions--------------------
> > --------*/
> > +
> > +static inline bool bus_mutex_lock(struct mutex *lock)
> > +{
> > +	int max_trying = W1_THERM_MAX_TRY;
> > +	/* try to acquire the mutex, if not, sleep retry_delay before
> > retry) */
> 
> Please use scripts/checkpatch.pl on your patches, it should have
> asked
> you to put an empty line after the int definition.
> 
I used it, no warning on this line but I will add
> 
> 
> > +	while (mutex_lock_interruptible(lock) != 0 && max_trying > 0) {
> > +		unsigned long sleep_rem;
> > +
> > +		sleep_rem = msleep_interruptible(W1_THERM_RETRY_DELAY);
> > +		if (!sleep_rem)
> > +			max_trying--;
> > +	}
> > +
> > +	if (!max_trying)
> > +		return false;	/* Didn't acquire the bus mutex */
> > +
> > +	return true;
> > +}
> > +
> >  /*-------------------------Interface Functions------------------
> > ------------*/
> >  static int w1_therm_add_slave(struct w1_slave *sl)
> >  {
> > @@ -302,6 +324,16 @@ static int w1_therm_add_slave(struct w1_slave
> > *sl)
> >  	if (!sl->family_data)
> >  		return -ENOMEM;
> >  	atomic_set(THERM_REFCNT(sl->family_data), 1);
> > +
> > +	/* Getting the power mode of the device {external, parasite}*/
> > +	SLAVE_POWERMODE(sl) = read_powermode(sl);
> > +
> > +	if (SLAVE_POWERMODE(sl) < 0) {
> > +		/* no error returned as device has been added */
> > +		dev_warn(&sl->dev,
> > +			"%s: Device has been added, but power_mode may
> > be corrupted. err=%d\n",
> > +			 __func__, SLAVE_POWERMODE(sl));
> > +	}
> >  	return 0;
> >  }
> >  
> > @@ -512,6 +544,43 @@ error:
> >  	return ret;
> >  }
> >  
> > +static int read_powermode(struct w1_slave *sl)
> > +{
> > +	struct w1_master *dev_master = sl->master;
> > +	int max_trying = W1_THERM_MAX_TRY;
> > +	int  ret = -ENODEV;
> > +
> > +	if (!sl->family_data)
> > +		goto error;
> > +
> > +	/* prevent the slave from going away in sleep */
> > +	atomic_inc(THERM_REFCNT(sl->family_data));
> > +
> > +	if (!bus_mutex_lock(&dev_master->bus_mutex)) {
> > +		ret = -EAGAIN;	// Didn't acquire the mutex
> > +		goto dec_refcnt;
> > +	}
> > +
> > +	while ((max_trying--) && (ret < 0)) {
> > +		/* safe version to select slave */
> > +		if (!reset_select_slave(sl)) {
> > +			w1_write_8(dev_master, W1_READ_PSUPPLY);
> > +			/* Read only one bit,
> > +			 * 1 is externally powered,
> > +			 * 0 is parasite powered
> > +			 */
> > +			ret = w1_touch_bit(dev_master, 1);
> > +			/* ret should be either 1 either 0 */
> > +		}
> > +	}
> > +	mutex_unlock(&dev_master->bus_mutex);
> > +
> > +dec_refcnt:
> > +	atomic_dec(THERM_REFCNT(sl->family_data));
> > +error:
> > +	return ret;
> > +}
> > +
> >  /*------------------------Interface sysfs-------------------------
> > -*/
> >  
> >  static ssize_t w1_slave_show(struct device *device,
> > @@ -565,13 +634,35 @@ static ssize_t w1_slave_store(struct device
> > *device,
> >  				ret =
> > w1_therm_families[i].eeprom(device);
> >  			else
> >  				ret =
> > w1_therm_families[i].precision(device,
> > -								val);
> > +									
> > val);
> >  			break;
> >  		}
> >  	}
> >  	return ret ? : size;
> >  }
> >  
> > +static ssize_t ext_power_show(struct device *device,
> > +	struct device_attribute *attr, char *buf)
> > +{
> > +	struct w1_slave *sl = dev_to_w1_slave(device);
> > +
> > +	if (!sl->family_data) {
> > +		dev_info(device,
> > +			"%s: Device not supported by the driver\n",
> > __func__);
> > +		return 0;  /* No device family */
> > +	}
> > +
> > +	/* Getting the power mode of the device {external, parasite}*/
> > +	SLAVE_POWERMODE(sl) = read_powermode(sl);
> > +
> > +	if (SLAVE_POWERMODE(sl) < 0) {
> > +		dev_dbg(device,
> > +			"%s: Power_mode may be corrupted. err=%d\n",
> > +			__func__, SLAVE_POWERMODE(sl));
> > +	}
> > +	return sprintf(buf, "%d\n", SLAVE_POWERMODE(sl));
> > +}
> > +
> >  #if IS_REACHABLE(CONFIG_HWMON)
> >  static int w1_read_temp(struct device *device, u32 attr, int
> > channel,
> >  			long *val)
> > diff --git a/drivers/w1/slaves/w1_therm.h
> > b/drivers/w1/slaves/w1_therm.h
> > index b73af0b..2f975a4 100644
> > --- a/drivers/w1/slaves/w1_therm.h
> > +++ b/drivers/w1/slaves/w1_therm.h
> > @@ -25,6 +25,12 @@
> >  #include <linux/mutex.h>
> >  #include <linux/w1.h>
> >  
> > +/*----------------------------------Defines-----------------------
> > ----------*/
> 
> No real need for this, we can see defines just fine :)
> 
Well noted
> thanks,
> 
> greg k-h

[PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump

[Chen Zhou]

I am busy with other things, so it was a long time before this version was
released.

This patch series enable reserving crashkernel above 4G in arm64.

There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
when there is no enough low memory.
2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
will boot failure because there is no low memory available for allocation.

To solve these issues, introduce crashkernel=X,low to reserve specified
size low memory.
Crashkernel=X tries to reserve memory for the crash dump kernel under
4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
size low memory for crash kdump kernel devices firstly and then reserve
memory above 4G.

When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
is specified simultaneously, kernel should reserve specified size low memory
for crash dump kernel devices. So there may be two crash kernel regions, one
is below 4G, the other is above 4G.
In order to distinct from the high region and make no effect to the use of
kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
"linux,low-memory-range" to crash dump kernel's dtb to pass the low region.

Besides, we need to modify kexec-tools:
arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])

The previous changes and discussions can be retrieved from:

Changes since [v5]
- Move reserve_crashkernel_low() into kernel/crash_core.c.
- Delete crashkernel=X,high.
- Modify crashkernel=X,low.
If crashkernel=X,low is specified simultaneously, reserve spcified size low
memory for crash kdump kernel devices firstly and then reserve memory above 4G.
In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
pass to crash dump kernel by DT property "linux,low-memory-range".
- Update Documentation/admin-guide/kdump/kdump.rst.

Changes since [v4]
- Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.

Changes since [v3]
- Add memblock_cap_memory_ranges back for multiple ranges.
- Fix some compiling warnings.

Changes since [v2]
- Split patch "arm64: kdump: support reserving crashkernel above 4G" as
two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
patch.

Changes since [v1]:
- Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
- Remove memblock_cap_memory_ranges() i added in v1 and implement that
in fdt_enforce_memory_region().
There are at most two crash kernel regions, for two crash kernel regions
case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
and then remove the memory range in the middle.

[1]: http://lists.infradead.org/pipermail/kexec/2019-August/023569.html
[v1]: https://lkml.org/lkml/2019/4/2/1174
[v2]: https://lkml.org/lkml/2019/4/9/86
[v3]: https://lkml.org/lkml/2019/4/9/306
[v4]: https://lkml.org/lkml/2019/4/15/273
[v5]: https://lkml.org/lkml/2019/5/6/1360

Chen Zhou (4):
  x86: kdump: move reserve_crashkernel_low() into crash_core.c
  arm64: kdump: reserve crashkenel above 4G for crash dump kernel
  arm64: kdump: add memory for devices by DT property, low-memory-range
  kdump: update Documentation about crashkernel on arm64

 Documentation/admin-guide/kdump/kdump.rst       | 13 ++++-
 Documentation/admin-guide/kernel-parameters.txt | 12 ++++-
 arch/arm64/include/asm/kexec.h                  |  3 ++
 arch/arm64/kernel/setup.c                       |  8 ++-
 arch/arm64/mm/init.c                            | 61 +++++++++++++++++++++--
 arch/x86/include/asm/kexec.h                    |  3 ++
 arch/x86/kernel/setup.c                         | 65 +++----------------------
 include/linux/crash_core.h                      |  4 ++
 include/linux/kexec.h                           |  1 -
 kernel/crash_core.c                             | 65 +++++++++++++++++++++++++
 10 files changed, 168 insertions(+), 67 deletions(-)

-- 
2.7.4

Re: [PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump

[Chen Zhou]

Hi all,

Friendly ping...

On 2019/8/30 15:11, Chen Zhou wrote:
> I am busy with other things, so it was a long time before this version was
> released.
> 
> This patch series enable reserving crashkernel above 4G in arm64.
> 
> There are following issues in arm64 kdump:
> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
> when there is no enough low memory.
> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
> in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
> will boot failure because there is no low memory available for allocation.
> 
> To solve these issues, introduce crashkernel=X,low to reserve specified
> size low memory.
> Crashkernel=X tries to reserve memory for the crash dump kernel under
> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
> size low memory for crash kdump kernel devices firstly and then reserve
> memory above 4G.
> 
> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
> is specified simultaneously, kernel should reserve specified size low memory
> for crash dump kernel devices. So there may be two crash kernel regions, one
> is below 4G, the other is above 4G.
> In order to distinct from the high region and make no effect to the use of
> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
> 
> Besides, we need to modify kexec-tools:
> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
> 
> The previous changes and discussions can be retrieved from:
> 
> Changes since [v5]
> - Move reserve_crashkernel_low() into kernel/crash_core.c.
> - Delete crashkernel=X,high.
> - Modify crashkernel=X,low.
> If crashkernel=X,low is specified simultaneously, reserve spcified size low
> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
> pass to crash dump kernel by DT property "linux,low-memory-range".
> - Update Documentation/admin-guide/kdump/kdump.rst.
> 
> Changes since [v4]
> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
> 
> Changes since [v3]
> - Add memblock_cap_memory_ranges back for multiple ranges.
> - Fix some compiling warnings.
> 
> Changes since [v2]
> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
> patch.
> 
> Changes since [v1]:
> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
> in fdt_enforce_memory_region().
> There are at most two crash kernel regions, for two crash kernel regions
> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
> and then remove the memory range in the middle.
> 
> [1]: http://lists.infradead.org/pipermail/kexec/2019-August/023569.html
> [v1]: https://lkml.org/lkml/2019/4/2/1174
> [v2]: https://lkml.org/lkml/2019/4/9/86
> [v3]: https://lkml.org/lkml/2019/4/9/306
> [v4]: https://lkml.org/lkml/2019/4/15/273
> [v5]: https://lkml.org/lkml/2019/5/6/1360
> 
> Chen Zhou (4):
>   x86: kdump: move reserve_crashkernel_low() into crash_core.c
>   arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>   arm64: kdump: add memory for devices by DT property, low-memory-range
>   kdump: update Documentation about crashkernel on arm64
> 
>  Documentation/admin-guide/kdump/kdump.rst       | 13 ++++-
>  Documentation/admin-guide/kernel-parameters.txt | 12 ++++-
>  arch/arm64/include/asm/kexec.h                  |  3 ++
>  arch/arm64/kernel/setup.c                       |  8 ++-
>  arch/arm64/mm/init.c                            | 61 +++++++++++++++++++++--
>  arch/x86/include/asm/kexec.h                    |  3 ++
>  arch/x86/kernel/setup.c                         | 65 +++----------------------
>  include/linux/crash_core.h                      |  4 ++
>  include/linux/kexec.h                           |  1 -
>  kernel/crash_core.c                             | 65 +++++++++++++++++++++++++
>  10 files changed, 168 insertions(+), 67 deletions(-)
> 

Re: [PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump

[John Donnelly]

HI 

SEE INLINE ON A QUESTION :

> On Dec 17, 2019, at 8:07 PM, Chen Zhou <chenzhou10@huawei.com> wrote:
> 
> Hi all,
> 
> Friendly ping...
> 
> On 2019/8/30 15:11, Chen Zhou wrote:
>> I am busy with other things, so it was a long time before this version was
>> released.
>> 
>> This patch series enable reserving crashkernel above 4G in arm64.
>> 
>> There are following issues in arm64 kdump:
>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>> when there is no enough low memory.
>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>> in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
>> will boot failure because there is no low memory available for allocation.

  
      Can you elaborate when the boot failures may fail due to lacking  swiotlb or DMA buffers ? Are these related to certain adapters or specific  platforms  ? 

     I have not seen this when using   crashkernel=2024M@35GB . 


>> 
>> To solve these issues, introduce crashkernel=X,low to reserve specified
>> size low memory.
>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>> size low memory for crash kdump kernel devices firstly and then reserve
>> memory above 4G.
>> 
>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>> is specified simultaneously, kernel should reserve specified size low memory
>> for crash dump kernel devices. So there may be two crash kernel regions, one
>> is below 4G, the other is above 4G.
>> In order to distinct from the high region and make no effect to the use of
>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>> 
>> Besides, we need to modify kexec-tools:
>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>> 
>> The previous changes and discussions can be retrieved from:
>> 
>> Changes since [v5]
>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>> - Delete crashkernel=X,high.
>> - Modify crashkernel=X,low.
>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>> pass to crash dump kernel by DT property "linux,low-memory-range".
>> - Update Documentation/admin-guide/kdump/kdump.rst.
>> 
>> Changes since [v4]
>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>> 
>> Changes since [v3]
>> - Add memblock_cap_memory_ranges back for multiple ranges.
>> - Fix some compiling warnings.
>> 
>> Changes since [v2]
>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>> patch.
>> 
>> Changes since [v1]:
>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>> in fdt_enforce_memory_region().
>> There are at most two crash kernel regions, for two crash kernel regions
>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>> and then remove the memory range in the middle.
>> 
>> [1]: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DAugust_023569.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=9tn9kUBabiuYhVtXauANSDGaISnCnHLYcAUQgsPBFxs&e= 
>> [v1]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_2_1174&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=F-lM7II2cuMF_sK3b6-QhSbWM3X-pI_WZEs0sZitS7A&e= 
>> [v2]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_86&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=5Y-S6sqMTklHkOQsNtjTX3C7pV05BjKLGhJVfMHEvDs&e= 
>> [v3]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_306&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=cWn4zSRQupaZ3jjz4eDvD-pNkoLyL_hsZoRx4yJoD0c&e= 
>> [v4]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_15_273&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=Nslk4RJKIyIuT0IoQoolXNjupEDXplPhQQwnTSoXNWE&e= 
>> [v5]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_5_6_1360&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=HJVAM6sCxV2DnNg5d4pw8WPqtkmQnKvztEmkSIgtQ5M&e= 
>> 
>> Chen Zhou (4):
>>  x86: kdump: move reserve_crashkernel_low() into crash_core.c
>>  arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>>  arm64: kdump: add memory for devices by DT property, low-memory-range
>>  kdump: update Documentation about crashkernel on arm64
>> 
>> Documentation/admin-guide/kdump/kdump.rst       | 13 ++++-
>> Documentation/admin-guide/kernel-parameters.txt | 12 ++++-
>> arch/arm64/include/asm/kexec.h                  |  3 ++
>> arch/arm64/kernel/setup.c                       |  8 ++-
>> arch/arm64/mm/init.c                            | 61 +++++++++++++++++++++--
>> arch/x86/include/asm/kexec.h                    |  3 ++
>> arch/x86/kernel/setup.c                         | 65 +++----------------------
>> include/linux/crash_core.h                      |  4 ++
>> include/linux/kexec.h                           |  1 -
>> kernel/crash_core.c                             | 65 +++++++++++++++++++++++++
>> 10 files changed, 168 insertions(+), 67 deletions(-)
>> 
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=XMcFx61B_QPg-FUfG_-t88DKCnGm4grqu6zRguiHYrU&e= 

Re: [PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump

[Chen Zhou]

Hi John,

On 2019/12/19 1:18, John Donnelly wrote:
> HI 
> 
> SEE INLINE ON A QUESTION :
> 
>> On Dec 17, 2019, at 8:07 PM, Chen Zhou <chenzhou10@huawei.com> wrote:
>>
>> Hi all,
>>
>> Friendly ping...
>>
>> On 2019/8/30 15:11, Chen Zhou wrote:
>>> I am busy with other things, so it was a long time before this version was
>>> released.
>>>
>>> This patch series enable reserving crashkernel above 4G in arm64.
>>>
>>> There are following issues in arm64 kdump:
>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>>> when there is no enough low memory.
>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>>> in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
>>> will boot failure because there is no low memory available for allocation.
> 
>   
>       Can you elaborate when the boot failures may fail due to lacking  swiotlb or DMA buffers ? Are these related to certain adapters or specific  platforms  ? 
> 
>      I have not seen this when using   crashkernel=2024M@35GB . 
> 

For example, in my environment "Huawei TaiShan 2280",
we need to use mpt3sas driver in crash dump kernel for dumping vmcore.

mpt3sas driver needs to call dma_pool_alloc to allocate some pages,
if there is no DMA buffer, page allocation will fail, which leads to crash dump kernel boot failure,
like this:

[2019/12/19 9:12:41] [   12.403501] mpt3sas_cm0: diag reset: SUCCESS
[2019/12/19 9:12:41] [   12.456076] mpt3sas_cm0: reply_post_free pool: dma_pool_alloc failed
[2019/12/19 9:12:41] [   12.462515] pci 0004:48:00.0: can't derive routing for PCI INT A
[2019/12/19 9:12:41] [   12.468761] mpt3sas 0004:49:00.0: PCI INT A: no GSI
[2019/12/19 9:12:41] [   12.476348] mpt3sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:10626/_scsih_probe()!
[2019/12/19 9:14:38] [ TIME ] Timed out waiting for device dev-di…b3\x2d890a\x2d2ead7df26f48.device.
[2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root Device.
[2019/12/19 9:14:38] [DEPEND] Dependency failed for /sysroot.
[2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root File System.
[2019/12/19 9:14:38] [DEPEND] Dependency failed for Reload Configuration from the Real Root.
[2019/12/19 9:14:38] [DEPEND] Dependency failed for File System C…40bae-9eb8-46b3-890a-2ead7df26f48.

Thanks,
Chen Zhou

> 
>>>
>>> To solve these issues, introduce crashkernel=X,low to reserve specified
>>> size low memory.
>>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>>> size low memory for crash kdump kernel devices firstly and then reserve
>>> memory above 4G.
>>>
>>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>>> is specified simultaneously, kernel should reserve specified size low memory
>>> for crash dump kernel devices. So there may be two crash kernel regions, one
>>> is below 4G, the other is above 4G.
>>> In order to distinct from the high region and make no effect to the use of
>>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>>>
>>> Besides, we need to modify kexec-tools:
>>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>>>
>>> The previous changes and discussions can be retrieved from:
>>>
>>> Changes since [v5]
>>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>>> - Delete crashkernel=X,high.
>>> - Modify crashkernel=X,low.
>>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>>> pass to crash dump kernel by DT property "linux,low-memory-range".
>>> - Update Documentation/admin-guide/kdump/kdump.rst.
>>>
>>> Changes since [v4]
>>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>>>
>>> Changes since [v3]
>>> - Add memblock_cap_memory_ranges back for multiple ranges.
>>> - Fix some compiling warnings.
>>>
>>> Changes since [v2]
>>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>>> patch.
>>>
>>> Changes since [v1]:
>>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>>> in fdt_enforce_memory_region().
>>> There are at most two crash kernel regions, for two crash kernel regions
>>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>>> and then remove the memory range in the middle.
>>>
>>> [1]: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DAugust_023569.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=9tn9kUBabiuYhVtXauANSDGaISnCnHLYcAUQgsPBFxs&e= 
>>> [v1]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_2_1174&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=F-lM7II2cuMF_sK3b6-QhSbWM3X-pI_WZEs0sZitS7A&e= 
>>> [v2]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_86&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=5Y-S6sqMTklHkOQsNtjTX3C7pV05BjKLGhJVfMHEvDs&e= 
>>> [v3]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_306&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=cWn4zSRQupaZ3jjz4eDvD-pNkoLyL_hsZoRx4yJoD0c&e= 
>>> [v4]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_15_273&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=Nslk4RJKIyIuT0IoQoolXNjupEDXplPhQQwnTSoXNWE&e= 
>>> [v5]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_5_6_1360&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=HJVAM6sCxV2DnNg5d4pw8WPqtkmQnKvztEmkSIgtQ5M&e= 
>>>
>>> Chen Zhou (4):
>>>  x86: kdump: move reserve_crashkernel_low() into crash_core.c
>>>  arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>>>  arm64: kdump: add memory for devices by DT property, low-memory-range
>>>  kdump: update Documentation about crashkernel on arm64
>>>
>>> Documentation/admin-guide/kdump/kdump.rst       | 13 ++++-
>>> Documentation/admin-guide/kernel-parameters.txt | 12 ++++-
>>> arch/arm64/include/asm/kexec.h                  |  3 ++
>>> arch/arm64/kernel/setup.c                       |  8 ++-
>>> arch/arm64/mm/init.c                            | 61 +++++++++++++++++++++--
>>> arch/x86/include/asm/kexec.h                    |  3 ++
>>> arch/x86/kernel/setup.c                         | 65 +++----------------------
>>> include/linux/crash_core.h                      |  4 ++
>>> include/linux/kexec.h                           |  1 -
>>> kernel/crash_core.c                             | 65 +++++++++++++++++++++++++
>>> 10 files changed, 168 insertions(+), 67 deletions(-)
>>>
>>
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=XMcFx61B_QPg-FUfG_-t88DKCnGm4grqu6zRguiHYrU&e= 
> 
> 
> .
> 

`

[John Donnelly]

> On Dec 18, 2019, at 8:56 PM, Chen Zhou <chenzhou10@huawei.com> wrote:
> 
> Hi John,
> 
> On 2019/12/19 1:18, John Donnelly wrote:
>> HI 
>> 
>> SEE INLINE ON A QUESTION :
>> 
>>> On Dec 17, 2019, at 8:07 PM, Chen Zhou <chenzhou10@huawei.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> Friendly ping...
>>> 
>>> On 2019/8/30 15:11, Chen Zhou wrote:
>>>> I am busy with other things, so it was a long time before this version was
>>>> released.
>>>> 
>>>> This patch series enable reserving crashkernel above 4G in arm64.
>>>> 
>>>> There are following issues in arm64 kdump:
>>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>>>> when there is no enough low memory.
>>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>>>> in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
>>>> will boot failure because there is no low memory available for allocation.
>> 
>> 
>>      Can you elaborate when the boot failures may fail due to lacking  swiotlb or DMA buffers ? Are these related to certain adapters or specific  platforms  ? 
>> 
>>     I have not seen this when using   crashkernel=2024M@35GB . 
>> 
> 
> For example, in my environment "Huawei TaiShan 2280",
> we need to use mpt3sas driver in crash dump kernel for dumping vmcore.
> 
> mpt3sas driver needs to call dma_pool_alloc to allocate some pages,
> if there is no DMA buffer, page allocation will fail, which leads to crash dump kernel boot failure,
> like this:
> 
> [2019/12/19 9:12:41] [   12.403501] mpt3sas_cm0: diag reset: SUCCESS
> [2019/12/19 9:12:41] [   12.456076] mpt3sas_cm0: reply_post_free pool: dma_pool_alloc failed
> [2019/12/19 9:12:41] [   12.462515] pci 0004:48:00.0: can't derive routing for PCI INT A
> [2019/12/19 9:12:41] [   12.468761] mpt3sas 0004:49:00.0: PCI INT A: no GSI
> [2019/12/19 9:12:41] [   12.476348] mpt3sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:10626/_scsih_probe()!
> [2019/12/19 9:14:38] [ TIME ] Timed out waiting for device dev-di…b3\x2d890a\x2d2ead7df26f48.device.
> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root Device.
> [2019/12/19 9:14:38] [DEPEND] Dependency failed for /sysroot.
> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root File System.
> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Reload Configuration from the Real Root.
> [2019/12/19 9:14:38] [DEPEND] Dependency failed for File System C…40bae-9eb8-46b3-890a-2ead7df26f48.


 Thank you for sharing .  We are not seeing this issue on a 5.4.0.rc8 ;    Like I said in a previous email we can  take crash dumps using crashkernel=768M for a  “ standard “ small VMcore to local storage :

0004:01:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3316 [Intruder] (rev 01)
	Subsystem: Broadcom / LSI MegaRAID SAS 9361-16i
	Kernel driver in use: megaraid_sas 


What version of the kernel are you using ?


> 
> Thanks,
> Chen Zhou
> 
>> 
>>>> 
>>>> To solve these issues, introduce crashkernel=X,low to reserve specified
>>>> size low memory.
>>>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>>>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>>>> size low memory for crash kdump kernel devices firstly and then reserve
>>>> memory above 4G.
>>>> 
>>>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>>>> is specified simultaneously, kernel should reserve specified size low memory
>>>> for crash dump kernel devices. So there may be two crash kernel regions, one
>>>> is below 4G, the other is above 4G.
>>>> In order to distinct from the high region and make no effect to the use of
>>>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>>>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>>>> 
>>>> Besides, we need to modify kexec-tools:
>>>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>>>> 
>>>> The previous changes and discussions can be retrieved from:
>>>> 
>>>> Changes since [v5]
>>>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>>>> - Delete crashkernel=X,high.
>>>> - Modify crashkernel=X,low.
>>>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>>>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>>>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>>>> pass to crash dump kernel by DT property "linux,low-memory-range".
>>>> - Update Documentation/admin-guide/kdump/kdump.rst.
>>>> 
>>>> Changes since [v4]
>>>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>>>> 
>>>> Changes since [v3]
>>>> - Add memblock_cap_memory_ranges back for multiple ranges.
>>>> - Fix some compiling warnings.
>>>> 
>>>> Changes since [v2]
>>>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>>>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>>>> patch.
>>>> 
>>>> Changes since [v1]:
>>>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>>>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>>>> in fdt_enforce_memory_region().
>>>> There are at most two crash kernel regions, for two crash kernel regions
>>>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>>>> and then remove the memory range in the middle.
>>>> 
>>>> [1]: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DAugust_023569.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=9tn9kUBabiuYhVtXauANSDGaISnCnHLYcAUQgsPBFxs&e= 
>>>> [v1]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_2_1174&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=F-lM7II2cuMF_sK3b6-QhSbWM3X-pI_WZEs0sZitS7A&e= 
>>>> [v2]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_86&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=5Y-S6sqMTklHkOQsNtjTX3C7pV05BjKLGhJVfMHEvDs&e= 
>>>> [v3]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_306&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=cWn4zSRQupaZ3jjz4eDvD-pNkoLyL_hsZoRx4yJoD0c&e= 
>>>> [v4]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_15_273&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=Nslk4RJKIyIuT0IoQoolXNjupEDXplPhQQwnTSoXNWE&e= 
>>>> [v5]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_5_6_1360&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=HJVAM6sCxV2DnNg5d4pw8WPqtkmQnKvztEmkSIgtQ5M&e= 
>>>> 
>>>> Chen Zhou (4):
>>>> x86: kdump: move reserve_crashkernel_low() into crash_core.c
>>>> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>>>> arm64: kdump: add memory for devices by DT property, low-memory-range
>>>> kdump: update Documentation about crashkernel on arm64
>>>> 
>>>> Documentation/admin-guide/kdump/kdump.rst       | 13 ++++-
>>>> Documentation/admin-guide/kernel-parameters.txt | 12 ++++-
>>>> arch/arm64/include/asm/kexec.h                  |  3 ++
>>>> arch/arm64/kernel/setup.c                       |  8 ++-
>>>> arch/arm64/mm/init.c                            | 61 +++++++++++++++++++++--
>>>> arch/x86/include/asm/kexec.h                    |  3 ++
>>>> arch/x86/kernel/setup.c                         | 65 +++----------------------
>>>> include/linux/crash_core.h                      |  4 ++
>>>> include/linux/kexec.h                           |  1 -
>>>> kernel/crash_core.c                             | 65 +++++++++++++++++++++++++
>>>> 10 files changed, 168 insertions(+), 67 deletions(-)
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> kexec mailing list
>>> kexec@lists.infradead.org
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=XMcFx61B_QPg-FUfG_-t88DKCnGm4grqu6zRguiHYrU&e= 
>> 
>> 
>> .

Re: `

[Chen Zhou]

Hi John,

On 2019/12/20 2:33, John Donnelly wrote:
> 
> 
>> On Dec 18, 2019, at 8:56 PM, Chen Zhou <chenzhou10@huawei.com> wrote:
>>
>> Hi John,
>>
>> On 2019/12/19 1:18, John Donnelly wrote:
>>> HI 
>>>
>>> SEE INLINE ON A QUESTION :
>>>
>>>> On Dec 17, 2019, at 8:07 PM, Chen Zhou <chenzhou10@huawei.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Friendly ping...
>>>>
>>>> On 2019/8/30 15:11, Chen Zhou wrote:
>>>>> I am busy with other things, so it was a long time before this version was
>>>>> released.
>>>>>
>>>>> This patch series enable reserving crashkernel above 4G in arm64.
>>>>>
>>>>> There are following issues in arm64 kdump:
>>>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>>>>> when there is no enough low memory.
>>>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>>>>> in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
>>>>> will boot failure because there is no low memory available for allocation.
>>>
>>>
>>>      Can you elaborate when the boot failures may fail due to lacking  swiotlb or DMA buffers ? Are these related to certain adapters or specific  platforms  ? 
>>>
>>>     I have not seen this when using   crashkernel=2024M@35GB . 
>>>
>>
>> For example, in my environment "Huawei TaiShan 2280",
>> we need to use mpt3sas driver in crash dump kernel for dumping vmcore.
>>
>> mpt3sas driver needs to call dma_pool_alloc to allocate some pages,
>> if there is no DMA buffer, page allocation will fail, which leads to crash dump kernel boot failure,
>> like this:
>>
>> [2019/12/19 9:12:41] [   12.403501] mpt3sas_cm0: diag reset: SUCCESS
>> [2019/12/19 9:12:41] [   12.456076] mpt3sas_cm0: reply_post_free pool: dma_pool_alloc failed
>> [2019/12/19 9:12:41] [   12.462515] pci 0004:48:00.0: can't derive routing for PCI INT A
>> [2019/12/19 9:12:41] [   12.468761] mpt3sas 0004:49:00.0: PCI INT A: no GSI
>> [2019/12/19 9:12:41] [   12.476348] mpt3sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:10626/_scsih_probe()!
>> [2019/12/19 9:14:38] [ TIME ] Timed out waiting for device dev-di…b3\x2d890a\x2d2ead7df26f48.device.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root Device.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for /sysroot.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root File System.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Reload Configuration from the Real Root.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for File System C…40bae-9eb8-46b3-890a-2ead7df26f48.
> 
> 
>  Thank you for sharing .  We are not seeing this issue on a 5.4.0.rc8 ;    Like I said in a previous email we can  take crash dumps using crashkernel=768M for a  “ standard “ small VMcore to local storage :
> 
> 0004:01:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3316 [Intruder] (rev 01)
> 	Subsystem: Broadcom / LSI MegaRAID SAS 9361-16i
> 	Kernel driver in use: megaraid_sas 
> 
> 
> What version of the kernel are you using ?

5.5.0.rc1

As I said in the patch series cover-letter, this patch series address following cases/isssues.

There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
when there is no enough low memory.
2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
in this case, if swiotlb or DMA buffers are required, crash dump kernel
will boot failure because there is no low memory available for allocation.

From your description, you use crashkernel=768M.
There are enough crashkernel below 4G, so crashkernel will be
reserved successfully and kdump be ok. （This case has no DMA buffers issue.）

or you use crashkernel=2024M@35GB, and this case is ok?
If your driver doesn't need DMA buffers(I am not sure about it), kdump will also be ok.


If i understand your question and explain clearly?

Thanks,
Chen Zhou

> 
> 
>>
>> Thanks,
>> Chen Zhou
>>
>>>
>>>>>
>>>>> To solve these issues, introduce crashkernel=X,low to reserve specified
>>>>> size low memory.
>>>>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>>>>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>>>>> size low memory for crash kdump kernel devices firstly and then reserve
>>>>> memory above 4G.
>>>>>
>>>>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>>>>> is specified simultaneously, kernel should reserve specified size low memory
>>>>> for crash dump kernel devices. So there may be two crash kernel regions, one
>>>>> is below 4G, the other is above 4G.
>>>>> In order to distinct from the high region and make no effect to the use of
>>>>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>>>>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>>>>>
>>>>> Besides, we need to modify kexec-tools:
>>>>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>>>>>
>>>>> The previous changes and discussions can be retrieved from:
>>>>>
>>>>> Changes since [v5]
>>>>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>>>>> - Delete crashkernel=X,high.
>>>>> - Modify crashkernel=X,low.
>>>>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>>>>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>>>>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>>>>> pass to crash dump kernel by DT property "linux,low-memory-range".
>>>>> - Update Documentation/admin-guide/kdump/kdump.rst.
>>>>>
>>>>> Changes since [v4]
>>>>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>>>>>
>>>>> Changes since [v3]
>>>>> - Add memblock_cap_memory_ranges back for multiple ranges.
>>>>> - Fix some compiling warnings.
>>>>>
>>>>> Changes since [v2]
>>>>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>>>>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>>>>> patch.
>>>>>
>>>>> Changes since [v1]:
>>>>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>>>>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>>>>> in fdt_enforce_memory_region().
>>>>> There are at most two crash kernel regions, for two crash kernel regions
>>>>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>>>>> and then remove the memory range in the middle.
>>>>>
>>>>> [1]: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DAugust_023569.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=9tn9kUBabiuYhVtXauANSDGaISnCnHLYcAUQgsPBFxs&e= 
>>>>> [v1]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_2_1174&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=F-lM7II2cuMF_sK3b6-QhSbWM3X-pI_WZEs0sZitS7A&e= 
>>>>> [v2]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_86&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=5Y-S6sqMTklHkOQsNtjTX3C7pV05BjKLGhJVfMHEvDs&e= 
>>>>> [v3]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_306&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=cWn4zSRQupaZ3jjz4eDvD-pNkoLyL_hsZoRx4yJoD0c&e= 
>>>>> [v4]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_15_273&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=Nslk4RJKIyIuT0IoQoolXNjupEDXplPhQQwnTSoXNWE&e= 
>>>>> [v5]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_5_6_1360&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=HJVAM6sCxV2DnNg5d4pw8WPqtkmQnKvztEmkSIgtQ5M&e= 
>>>>>
>>>>> Chen Zhou (4):
>>>>> x86: kdump: move reserve_crashkernel_low() into crash_core.c
>>>>> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>>>>> arm64: kdump: add memory for devices by DT property, low-memory-range
>>>>> kdump: update Documentation about crashkernel on arm64
>>>>>
>>>>> Documentation/admin-guide/kdump/kdump.rst       | 13 ++++-
>>>>> Documentation/admin-guide/kernel-parameters.txt | 12 ++++-
>>>>> arch/arm64/include/asm/kexec.h                  |  3 ++
>>>>> arch/arm64/kernel/setup.c                       |  8 ++-
>>>>> arch/arm64/mm/init.c                            | 61 +++++++++++++++++++++--
>>>>> arch/x86/include/asm/kexec.h                    |  3 ++
>>>>> arch/x86/kernel/setup.c                         | 65 +++----------------------
>>>>> include/linux/crash_core.h                      |  4 ++
>>>>> include/linux/kexec.h                           |  1 -
>>>>> kernel/crash_core.c                             | 65 +++++++++++++++++++++++++
>>>>> 10 files changed, 168 insertions(+), 67 deletions(-)
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> kexec mailing list
>>>> kexec@lists.infradead.org
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=XMcFx61B_QPg-FUfG_-t88DKCnGm4grqu6zRguiHYrU&e= 
>>>
>>>
>>> .
> 
> 
> .
> 

(no subject)

[Christoph Lameter]

> > There is a deadlock, Peter!!!
>
> Describe please? Also, have you tried disabling RT_RUNTIME_SHARE ?
>


The description was given earlier in the the thread and the drawbacks of
using RT_RUNTIME_SHARE as well.

Re: ???

[Steven Rostedt]

What's with people sending out replies without subjects?

On Tue, 15 Nov 2016 14:29:16 -0600 (CST)
Christoph Lameter <cl@linux.com> wrote:

> > > There is a deadlock, Peter!!!  
> >
> > Describe please? Also, have you tried disabling RT_RUNTIME_SHARE ?
> >  
> 
> 
> The description was given earlier in the the thread and the drawbacks of
> using RT_RUNTIME_SHARE as well.

Peter is saying to disable that, because of the drawbacks. I think the
question is, do you still have a deadlock after disabling it? If not,
then that's your solution.

-- Steve

(no subject)

[Chunyan Zhang]

Hi Steven,

On 21 October 2016 at 20:13, Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> On 18 October 2016 at 23:44, Steven Rostedt <rostedt@goodmis.org> wrote:
>> On Tue, 18 Oct 2016 16:08:58 +0800
>> Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
>>
>>> Currently Function traces can be only exported to ring buffer, this
>>> patch added trace_export concept which can process traces and export
>>> them to a registered destination as an addition to the current only
>>> one output of Ftrace - i.e. ring buffer.
>>>
>>> In this way, if we want Function traces to be sent to other destination
>>> rather than ring buffer only, we just need to register a new trace_export
>>> and implement its own .write() function for writing traces to storage.
>>>
>>> With this patch, only Function trace (trace type is TRACE_FN)
>>> is supported.
>>
>> This is getting better, but I still have some nits.
>>
>
> Thanks.
>
>>>
>>> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
>>> ---
>>>  include/linux/trace.h |  28 +++++++++++
>>>  kernel/trace/trace.c  | 132 +++++++++++++++++++++++++++++++++++++++++++++++++-
>>>  2 files changed, 159 insertions(+), 1 deletion(-)
>>>  create mode 100644 include/linux/trace.h
>>>
>>> diff --git a/include/linux/trace.h b/include/linux/trace.h
>>> new file mode 100644
>>> index 0000000..eb1c5b8
>>> --- /dev/null
>>> +++ b/include/linux/trace.h
>>> @@ -0,0 +1,28 @@
>>> +#ifndef _LINUX_TRACE_H
>>> +#define _LINUX_TRACE_H
>>> +
>>> +#ifdef CONFIG_TRACING
>>> +/*
>>> + * The trace export - an export of Ftrace output. The trace_export
>>> + * can process traces and export them to a registered destination as
>>> + * an addition to the current only output of Ftrace - i.e. ring buffer.
>>> + *
>>> + * If you want traces to be sent to some other place rather than ring
>>> + * buffer only, just need to register a new trace_export and implement
>>> + * its own .write() function for writing traces to the storage.
>>> + *
>>> + * next              - pointer to the next trace_export
>>> + * write     - copy traces which have been delt with ->commit() to
>>> + *             the destination
>>> + */
>>> +struct trace_export {
>>> +     struct trace_export __rcu       *next;
>>> +     void (*write)(const char *, unsigned int);
>>
>> Why const char*? Why not const void *? This will never be a string.
>>
>
> Will revise this.
>
>>
>>> +};
>>> +
>>> +int register_ftrace_export(struct trace_export *export);
>>> +int unregister_ftrace_export(struct trace_export *export);
>>> +
>>> +#endif       /* CONFIG_TRACING */
>>> +
>>> +#endif       /* _LINUX_TRACE_H */
>>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>>> index 8696ce6..db94ec1 100644
>>> --- a/kernel/trace/trace.c
>>> +++ b/kernel/trace/trace.c
>>> @@ -40,6 +40,7 @@
>>>  #include <linux/poll.h>
>>>  #include <linux/nmi.h>
>>>  #include <linux/fs.h>
>>> +#include <linux/trace.h>
>>>  #include <linux/sched/rt.h>
>>>
>>>  #include "trace.h"
>>> @@ -2128,6 +2129,132 @@ void trace_buffer_unlock_commit_regs(struct trace_array *tr,
>>>       ftrace_trace_userstack(buffer, flags, pc);
>>>  }
>>>
>>> +static void
>>> +trace_process_export(struct trace_export *export,
>>> +            struct ring_buffer_event *event)
>>> +{
>>> +     struct trace_entry *entry;
>>> +     unsigned int size = 0;
>>> +
>>> +     entry = ring_buffer_event_data(event);
>>> +
>>> +     size = ring_buffer_event_length(event);
>>> +
>>> +     if (export->write)
>>> +             export->write((char *)entry, size);
>>
>> Is there ever going to be a time where export->write wont be set?
>
> There hasn't been since only one trace_export (i.e. stm_ftrace) was
> added in this patch-set , I just wanted to make sure the write() has
> been set before registering trace_export like what I added in 2/3 of
> this series.
>
>>
>> And if there is, this can be racy. As in
>>
>>
>>         CPU 0:                  CPU 1:
>>         ------                  ------
>>         if (export->write)
>>
>>                                 export->write = NULL;
>
> Is there going to be this kind of use case? Why some one needs to
> change export->write() rather than register a new trace_export?
>
> I probably haven't understood your point thoroughly, please correct me
> if my guess was wrong.
>

Any further comments? :)

Thanks,
Chunyan

>
> Thanks for the review,
> Chunyan
>
>>
>>         export->write(entry, size);
>>
>>         BOOM!
>>
>>
>> -- Steve
>>
>>> +}
>>> +
>>> +static DEFINE_MUTEX(ftrace_export_lock);
>>> +
>>> +static struct trace_export __rcu *ftrace_exports_list __read_mostly;
>>> +
>>> +static DEFINE_STATIC_KEY_FALSE(ftrace_exports_enabled);
>>> +
>>> +static inline void ftrace_exports_enable(void)
>>> +{
>>> +     static_branch_enable(&ftrace_exports_enabled);
>>> +}
>>> +
>>> +static inline void ftrace_exports_disable(void)
>>> +{
>>> +     static_branch_disable(&ftrace_exports_enabled);
>>> +}
>>> +
>>> +void ftrace_exports(struct ring_buffer_event *event)
>>> +{
>>> +     struct trace_export *export;
>>> +
>>> +     preempt_disable_notrace();
>>> +
>>> +     export = rcu_dereference_raw_notrace(ftrace_exports_list);
>>> +     while (export) {
>>> +             trace_process_export(export, event);
>>> +             export = rcu_dereference_raw_notrace(export->next);
>>> +     }
>>> +
>>> +     preempt_enable_notrace();
>>> +}
>>> +
>>> +static inline void
>>> +add_trace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> +     rcu_assign_pointer(export->next, *list);
>>> +     /*
>>> +      * We are entering export into the list but another
>>> +      * CPU might be walking that list. We need to make sure
>>> +      * the export->next pointer is valid before another CPU sees
>>> +      * the export pointer included into the list.
>>> +      */
>>> +     rcu_assign_pointer(*list, export);
>>> +}
>>> +
>>> +static inline int
>>> +rm_trace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> +     struct trace_export **p;
>>> +
>>> +     for (p = list; *p != NULL; p = &(*p)->next)
>>> +             if (*p == export)
>>> +                     break;
>>> +
>>> +     if (*p != export)
>>> +             return -1;
>>> +
>>> +     rcu_assign_pointer(*p, (*p)->next);
>>> +
>>> +     return 0;
>>> +}
>>> +
>>> +static inline void
>>> +add_ftrace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> +     if (*list == NULL)
>>> +             ftrace_exports_enable();
>>> +
>>> +     add_trace_export(list, export);
>>> +}
>>> +
>>> +static inline int
>>> +rm_ftrace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> +     int ret;
>>> +
>>> +     ret = rm_trace_export(list, export);
>>> +     if (*list == NULL)
>>> +             ftrace_exports_disable();
>>> +
>>> +     return ret;
>>> +}
>>> +
>>> +int register_ftrace_export(struct trace_export *export)
>>> +{
>>> +     if (WARN_ON_ONCE(!export->write))
>>> +             return -1;
>>> +
>>> +     mutex_lock(&ftrace_export_lock);
>>> +
>>> +     add_ftrace_export(&ftrace_exports_list, export);
>>> +
>>> +     mutex_unlock(&ftrace_export_lock);
>>> +
>>> +     return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(register_ftrace_export);
>>> +
>>> +int unregister_ftrace_export(struct trace_export *export)
>>> +{
>>> +     int ret;
>>> +
>>> +     mutex_lock(&ftrace_export_lock);
>>> +
>>> +     ret = rm_ftrace_export(&ftrace_exports_list, export);
>>> +
>>> +     mutex_unlock(&ftrace_export_lock);
>>> +
>>> +     return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(unregister_ftrace_export);
>>> +
>>>  void
>>>  trace_function(struct trace_array *tr,
>>>              unsigned long ip, unsigned long parent_ip, unsigned long flags,
>>> @@ -2146,8 +2273,11 @@ trace_function(struct trace_array *tr,
>>>       entry->ip                       = ip;
>>>       entry->parent_ip                = parent_ip;
>>>
>>> -     if (!call_filter_check_discard(call, entry, buffer, event))
>>> +     if (!call_filter_check_discard(call, entry, buffer, event)) {
>>> +             if (static_branch_unlikely(&ftrace_exports_enabled))
>>> +                     ftrace_exports(event);
>>>               __buffer_unlock_commit(buffer, event);
>>> +     }
>>>  }
>>>
>>>  #ifdef CONFIG_STACKTRACE
>>

Re: ??

[Steven Rostedt]

On Fri, 11 Nov 2016 11:38:45 +0800
Chunyan Zhang <zhang.chunyan@linaro.org> wrote:


What happened to the subject?

> >>> +static void
> >>> +trace_process_export(struct trace_export *export,
> >>> +            struct ring_buffer_event *event)
> >>> +{
> >>> +     struct trace_entry *entry;
> >>> +     unsigned int size = 0;
> >>> +
> >>> +     entry = ring_buffer_event_data(event);
> >>> +
> >>> +     size = ring_buffer_event_length(event);
> >>> +
> >>> +     if (export->write)
> >>> +             export->write((char *)entry, size);  
> >>
> >> Is there ever going to be a time where export->write wont be set?  
> >
> > There hasn't been since only one trace_export (i.e. stm_ftrace) was
> > added in this patch-set , I just wanted to make sure the write() has
> > been set before registering trace_export like what I added in 2/3 of
> > this series.
> >  
> >>
> >> And if there is, this can be racy. As in
> >>
> >>
> >>         CPU 0:                  CPU 1:
> >>         ------                  ------
> >>         if (export->write)
> >>
> >>                                 export->write = NULL;  
> >
> > Is there going to be this kind of use case? Why some one needs to
> > change export->write() rather than register a new trace_export?
> >
> > I probably haven't understood your point thoroughly, please correct me
> > if my guess was wrong.
> >  
> 
> Any further comments? :)

I don't remember which patch series this goes to, so right now, no.

-- Steve

Re: ###$$$@#

[iutititbpigi]

----- Original Message -----

Sent: Tue, 31 May 2016 21:02:28 -0400 (EDT)
Subject: ###$$$@#

BMW WINNING NOTIFICATION!!!

Re: ?

[Amall]

----- Original Message -----
From: 
Sent: Tue, 27 Oct 2015 16:25:44 -0400 (EDT)
Subject: 

i need your support

!

[Kathrine]

Did you get my previous mail? When and what time can i call?

!

[Rita]

When and What time can i Call you? Respond ASAP

!

[Rita]

When and What time can i Call you? Respond ASAP

!

[Ana Flavia Maria]

-- 
                                     Loan at 3% interest rate Loan offer.. AreYou Interested>?

$

[FBI]

This goes out to you  who had lost your money to scammers,email  back to us for your  lost money now....

!

[FBI]

I am here to see that you get all your money that you lost to scammers,reply back!

$

[Sgt Moore Paul]

I have a monetary deal for you.reply using sgtp_moore@tranphu.com,Sgt Paul.

,

[Ming-Yang Lee]

Do you need a loan to pay your bills or to start up a business or for Xmas?.
Kindly apply now for a low rate loan of 3%. for more information contact:
ming.yangfundsservice@qatar.io
We Await Your Response.
Mr Ming-Yang Lee

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[john erchart]

hello do you need a loan? if yes contact us
via:johnerchart_loanservice@hotmail.com with the amount needed and your full
name.....

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[Mr.COOK ADAMS]

I am Mr Cook Adams,I gives out loans at low interest rate of 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us via Email:mrcookadamsinvestment4@gmail.com
Below are the loan Applications:
*Applicant's Full Names:
*Applicant's Contact Address:.
*Phone No:
*Country:
*Age:
*Marital Status:
*Amount Required As Loan:
*Proposed Terms/Duration Of Loan:
*Annual Income:
*Occupation:

Mode of Payment:
* Payment by bank to bank transfer
* Payment by bank certified check(courier

Mr.COOK ADAMS
Managing Director.


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[Mr.COOK ADAMS]

I am Mr Cook Adams,I gives out loans at low interest rate of 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us via Email:mrcookadamsinvestment6@gmail.com
Below are the loan Applications:
*Applicant's Full Names:
*Applicant's Contact Address:.
*Phone No:
*Country:
*Age:
*Marital Status:
*Amount Required As Loan:
*Proposed Terms/Duration Of Loan:
*Annual Income:
*Occupation:

Mode of Payment:
* Payment by bank to bank transfer
* Payment by bank certified check(courier

Mr.COOK ADAMS
Managing Director.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[Mr.COOK ADAMS]

I am Mr Cook Adams,I gives out loans at low interest rate of 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us via Email:mrcookadamsinvestment6@gmail.com
Below are the loan Applications:
*Applicant's Full Names:
*Applicant's Contact Address:.
*Phone No:
*Country:
*Age:
*Marital Status:
*Amount Required As Loan:
*Proposed Terms/Duration Of Loan:
*Annual Income:
*Occupation:

Mode of Payment:
* Payment by bank to bank transfer
* Payment by bank certified check(courier

Mr.COOK ADAMS
Managing Director.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[DHL UNIT]

I am Mr Cook Adams,I gives out loans at low interest rate of 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us via Email:mrcookadamsinvestment6@gmail.com


Below are the loan Applications:


*Applicant's Full Names:
*Applicant's Contact Address:.
*Phone No:
*Country:
*Age:
*Marital Status:
*Amount Required As Loan:
*Proposed Terms/Duration Of Loan:
*Annual Income:
*Occupation:

Mode of Payment:
* Payment by bank to bank transfer
* Payment by bank certified check(courier

Mr.COOK ADAMS
Managing Director.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[SBECKFORD Financial Loan Company]

SBECKFORD Financial Loan Company
190 - 194 Main Street
Barrhead Glasgow G78 1SL
www.sbeckford.webs.com

Attn: Friend,

Are you looking for a cheap loan today?

We are Private Loan Lender and a Cooperate
Financial for real Estate and any kinds of
business financing.

We offer loans to individuals, firms and
cooperate bodies at 2.5% interest rate per
annual both secured and unsecured at 3%
interest rate monthly base, with no credit
check up, Loan terms and determinant, loan
amount between the sum of $3,000.00usd to
20,000,000.00usd.

For quick processing of your loan
request,kindly fill the loan application
form below.

THE LOAN APPLICATION FORM BELOW:

*Full Name:.............................
*Address:..............Age:.............
*Country:..............Sex:.............
*Contact Phone number:.................
*Occupation:............................
*Purpose of Loan:.......................
*Loan Amount Needed/Duration:...........
*E-mail: ...............................

Contact: Mr. Greg Rudolph
E-mail: Sbeckfordh@gmail.com
Tel:08136431741

Note: Everyone above 18 years of age are
qualified for this offer.
Await your swift reply.

My Best Regards,
Mr. Greg Rudolph
(Financial Manager).

ReplyReply All

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[SBECKFORD Financial Loan Company]

SBECKFORD Financial Loan Company
190 - 194 Main Street
Barrhead Glasgow G78 1SL
www.sbeckford.webs.com

Attn: Friend,

Are you looking for a cheap loan today?

We are Private Loan Lender and a Cooperate
Financial for real Estate and any kinds of
business financing.

We offer loans to individuals, firms and
cooperate bodies at 2.5% interest rate per
annual both secured and unsecured at 3%
interest rate monthly base, with no credit
check up, Loan terms and determinant, loan
amount between the sum of $3,000.00usd to
20,000,000.00usd.

For quick processing of your loan
request,kindly fill the loan application
form below.

THE LOAN APPLICATION FORM BELOW:

*Full Name:.............................
*Address:..............Age:.............
*Country:..............Sex:.............
*Contact Phone number:.................
*Occupation:............................
*Purpose of Loan:.......................
*Loan Amount Needed/Duration:...........
*E-mail: ...............................

Contact: Mr. Greg Rudolph
E-mail: Sbeckfordh@gmail.com
Tel:08136431741

Note: Everyone above 18 years of age are
qualified for this offer.
Await your swift reply.

My Best Regards,
Mr. Greg Rudolph
(Financial Manager).

ReplyReply All

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[Mr.COOK ADAMS]

I am Mr Cook Adams,I gives out loans at low interest rate of 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us via Email:mrcookadamsinvestment5@gmail.com


Below are the loan Applications:


*Applicant's Full Names:
*Applicant's Contact Address:.
*Phone No:
*Country:
*Age:
*Marital Status:
*Amount Required As Loan:
*Proposed Terms/Duration Of Loan:
*Annual Income:
*Occupation:

Mode of Payment:
* Payment by bank to bank transfer
* Payment by bank certified check(courier

Mr.COOK ADAMS
Managing Director.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[JOSE LOANS]

JOSE LOANS CO-OPERATION gives out loans at low interest rate 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us on :(:+234 705 167 9220)


First Name:_________________________ __
Gender:_______________________ ________
Marital status:_______________________
Contact Address:______________________
Country:______________________ ________
Amount Needed as Loan:________________
Loan Duration:_____________________ ___
Monthly Income/Yearly Income:_________
Occupation:___________________ ________
Purpose for Loan:_____________________
Phone:________________________ ________





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[JOSE LOANS]

JOSE LOANS CO-OPERATION gives out loans at low interest rate 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us on :(:+234 705 167 9220)


First Name:_________________________ __
Gender:_______________________ ________
Marital status:_______________________
Contact Address:______________________
Country:______________________ ________
Amount Needed as Loan:________________
Loan Duration:_____________________ ___
Monthly Income/Yearly Income:_________
Occupation:___________________ ________
Purpose for Loan:_____________________
Phone:________________________ ________





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[JOSE LOANS]

JOSE LOANS CO-OPERATION gives out loans at low interest rate 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us on :(:+234 705 167 9220)


First Name:_________________________ __
Gender:_______________________ ________
Marital status:_______________________
Contact Address:______________________
Country:______________________ ________
Amount Needed as Loan:________________
Loan Duration:_____________________ ___
Monthly Income/Yearly Income:_________
Occupation:___________________ ________
Purpose for Loan:_____________________
Phone:________________________ ________





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[JOSE LOANS]

JOSE LOANS CO-OPERATION gives out loans at low interest rate 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us on :(:+234 705 167 9220)


First Name:_________________________ __
Gender:_______________________ ________
Marital status:_______________________
Contact Address:______________________
Country:______________________ ________
Amount Needed as Loan:________________
Loan Duration:_____________________ ___
Monthly Income/Yearly Income:_________
Occupation:___________________ ________
Purpose for Loan:_____________________
Phone:________________________ ________





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[PATCH] Move memory controller allocations to their own slabs

[Balbir Singh]

Move the memory controller data structures page_cgroup and
mem_cgroup_per_zone to their own slab caches. It saves space on the system,
allocations are not necessarily pushed to order of 2 and should provide
performance benefits. Users who disable the memory controller can also double
check that the memory controller is not allocating page_cgroup's.

Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
---

 linux/memcontrol.h |    0 
 mm/memcontrol.c    |   21 ++++++++++++++-------
 2 files changed, 14 insertions(+), 7 deletions(-)

diff -puN mm/memcontrol.c~memory-controller-move-to-own-slab mm/memcontrol.c
--- linux-2.6.25-rc4/mm/memcontrol.c~memory-controller-move-to-own-slab	2008-03-10 23:22:34.000000000 +0530
+++ linux-2.6.25-rc4-balbir/mm/memcontrol.c	2008-03-10 23:34:42.000000000 +0530
@@ -26,6 +26,7 @@
 #include <linux/backing-dev.h>
 #include <linux/bit_spinlock.h>
 #include <linux/rcupdate.h>
+#include <linux/slab.h>
 #include <linux/swap.h>
 #include <linux/spinlock.h>
 #include <linux/fs.h>
@@ -35,6 +36,8 @@
 
 struct cgroup_subsys mem_cgroup_subsys;
 static const int MEM_CGROUP_RECLAIM_RETRIES = 5;
+static struct kmem_cache *page_cgroup_cache;
+static struct kmem_cache *mem_cgroup_per_zone_cache;
 
 /*
  * Statistics for memory cgroup.
@@ -560,7 +563,7 @@ retry:
 	}
 	unlock_page_cgroup(page);
 
-	pc = kzalloc(sizeof(struct page_cgroup), gfp_mask);
+	pc = kmem_cache_zalloc(page_cgroup_cache, gfp_mask);
 	if (pc == NULL)
 		goto err;
 
@@ -622,7 +625,7 @@ retry:
 		 */
 		res_counter_uncharge(&mem->res, PAGE_SIZE);
 		css_put(&mem->css);
-		kfree(pc);
+		kmem_cache_free(page_cgroup_cache, pc);
 		goto retry;
 	}
 	page_assign_page_cgroup(page, pc);
@@ -637,7 +640,7 @@ done:
 	return 0;
 out:
 	css_put(&mem->css);
-	kfree(pc);
+	kmem_cache_free(page_cgroup_cache, pc);
 err:
 	return -ENOMEM;
 }
@@ -695,7 +698,7 @@ void mem_cgroup_uncharge_page(struct pag
 		res_counter_uncharge(&mem->res, PAGE_SIZE);
 		css_put(&mem->css);
 
-		kfree(pc);
+		kmem_cache_free(page_cgroup_cache, pc);
 		return;
 	}
 
@@ -988,9 +991,10 @@ static int alloc_mem_cgroup_per_zone_inf
 	 *       function.
 	 */
 	if (node_state(node, N_HIGH_MEMORY))
-		pn = kmalloc_node(sizeof(*pn), GFP_KERNEL, node);
+		pn = kmem_cache_alloc_node(mem_cgroup_per_zone_cache,
+						GFP_KERNEL, node);
 	else
-		pn = kmalloc(sizeof(*pn), GFP_KERNEL);
+		pn = kmem_cache_alloc(mem_cgroup_per_zone_cache, GFP_KERNEL);
 	if (!pn)
 		return 1;
 
@@ -1008,7 +1012,7 @@ static int alloc_mem_cgroup_per_zone_inf
 
 static void free_mem_cgroup_per_zone_info(struct mem_cgroup *mem, int node)
 {
-	kfree(mem->info.nodeinfo[node]);
+	kmem_cache_free(mem_cgroup_per_zone_cache, mem->info.nodeinfo[node]);
 }
 
 static struct cgroup_subsys_state *
@@ -1020,6 +1024,9 @@ mem_cgroup_create(struct cgroup_subsys *
 	if (unlikely((cont->parent) == NULL)) {
 		mem = &init_mem_cgroup;
 		init_mm.mem_cgroup = mem;
+		page_cgroup_cache = KMEM_CACHE(page_cgroup, SLAB_PANIC);
+		mem_cgroup_per_zone_cache = KMEM_CACHE(mem_cgroup_per_zone,
+							SLAB_PANIC);
 	} else
 		mem = kzalloc(sizeof(struct mem_cgroup), GFP_KERNEL);
 
diff -puN include/linux/memcontrol.h~memory-controller-move-to-own-slab include/linux/memcontrol.h
_

-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

+

[KOSAKI Motohiro]

Hi

> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> ---
> 
>  linux/memcontrol.h |    0 

???
unnecessary hunk?
or diff comannd bug?

>  mm/memcontrol.c    |   21 ++++++++++++++-------
>  2 files changed, 14 insertions(+), 7 deletions(-)

Re: +

[Balbir Singh]

KOSAKI Motohiro wrote:
> Hi
> 
>> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
>> ---
>>
>>  linux/memcontrol.h |    0 
> 
> ???
> unnecessary hunk?
> or diff comannd bug?

I use Andrew Morton's patchutils and specified both include/linux/memcontrol.h
and mm/memcontrol.c

$ cat pc/memory-controller-move-to-own-slab.pc
mm/memcontrol.c
include/linux/memcontrol.h

But refpatch generates linux/memcontrol.h. I am using diffstat v1.41. I'll
reboot to FC8 and see if that makes any difference.


-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

ÄãÆóÒµ¹ÜÀíµÄÎÊÌâ,ÎÒÃÇͳͳ¿ÉÒÔ½â¾ö

[FCun6c3Y]

StartSoft( www.starterp.net) ÏÖÔÚÒѾ­ÓµÓÐÁËÆóÒµ¹ÜÀí
È«Ãæ½â¾ö·½°¸.

ÈκÎÆóÒµ¶¼¿ÉÒÔÑ¡Ôñµ½ËûÃÇÐèÒªµÄÆóÒµ¹ÜÀíÈí¼þ.ÎÞÂÛÊÇÆóÒµ
×ÊÔ´¹ÜÀíERP,»¹ÊÇÍøÂç°ì¹«(OA),ÆóÒµ¹©Ó¦Á´(SCM),¿Í»§¹Øϵ
¹ÜÀí(CRM),ÆóÒµ·ÖÏúϵͳ,¶¼ÓкܺõĽâ¾ö·½°¸.

ÿÌ×ϵͳ´ó¼Ò¿ÉÒÔÔÚÏß²âÊÔ,Èç¹û²»ÊÇb/s½á¹¹µÄ,Ò²ÓвâÊÔ°æ
±¾¿É¹©ÏÂÔØ.

ÒÔÉÏËùÓÐϵͳ½ÔÓÐÔ´ÂëÌṩ,¿ÉÒÔÐ޸ļ°¶þ´Î¿ª·¢.

ϵͳ¼Û¸ñÓÅ»Ý,»¶Ó­×Éѯ:0 7 5 5 - 6 1 3 2 5 3 1 1 ²ÜÏÈÉú
E-mail: caoshan@starterp.net

·¿µØ²úÓªÏú¹ÜÀíϵͳ×îÐÂÍƳö......

[s6tyReF]

ÔÚÏß²âÊÔµØÖ·:  http://ltsoft.88ip.cn/dc.htm

Ëæ׿ÆËã»ú¼¼ÊõµÄ·¢Õ¹ºÍÆäÔÚÉÌÒµÉϵĹ㷺ӦÓã¬ÀûÓü¼ÊõÊÖ¶ÎʵÏÖ·¿²úÆóÒµÓªÏúÒµÎñ¹ÜÀíµÄÐÅÏ¢»¯¡¢¹æ·¶»¯ºÍÏÖ´ú»¯ÒѾ­Öð½¥Îª¸÷·¢Õ¹ÉÌÈÏʶºÍÖØÊÓ.

Á¦ÌìÈí¼þƾ½èÆäÔÚ·¿µØ²úÐÐÒµ¶àÏî½â¾ö·½°¸µÄÌṩºÍʵʩ¾­Ñ飬Õë¶ÔÄ¿Ç°ÎÒ¹ú·¿µØ²úÐÐÒµÓªÏú¹ÜÀíµÄÏÖ×´£¬½áºÏ¸÷¸ö·¿µØ²ú¹«Ë¾ÏÖÓеÄÈíÓ²¼þͶ×Êˮƽ£¬¾­¹ýÓë¸÷´ó·¿µØ²úÒµÖªÃûµ¥Î»µÄÃÜÇкÏ×÷£¬ÔÚ¹úÄÚÂÊÏÈÍƳöÁËÍêÈ«»ùÓÚä¯ÀÀÆ÷µÄµÚÈý´úÊÛÂ¥¹ÜÀíÈí¼þ--Á¦Ìì·¿²úÓªÏú¹ÜÀíϵͳ£¬Ä¿Ç°¸ÃϵͳÒѾ­ÔÚÊ®Óà¸öÂ¥ÅÌÏîÄ¿µÄÏúÊÛ¹ÜÀíÖ®Öгɹ¦Ó¦Óò¢µÃµ½Á˹㷺ºÃÆÀ¡£ 

¸Ãϵͳ²ÉÓÃÁË¿çµØÓòµÄB/S£¨ä¯ÀÀÆ÷/·þÎñÆ÷£©½á¹¹Éè¼Æ£¬È«ÃæÖ§³ÖÒƶ¯°ì¹«¼°ÒìµØÔ¶³Ì°ì¹«£¬·ûºÏ·¿²ú¹«Ë¾×ܲ¿ÓëÊÛÂ¥´¦·ÖÀëµÄʵ¼ÊÇé¿ö¡£ÏµÍ³°üÀ¨ÏîÄ¿¹ÜÀí¡¢¾ö²ß¹ÜÀí¡¢ÏúÊÛ¹ÜÀí¡¢²ÆÎñ¹ÜÀí¡¢¿Í»§¹Øϵ¹ÜÀí¡¢¹ã¸æÓªÏú¹ÜÀí¡¢°ì¹«¹ÜÀí¡¢ÊÛºó·þÎñ¹ÜÀí¡¢Í³¼Æ±¨±íµÈ¾Å´ó¹¦ÄÜÄ£¿é£¬»ù±¾º­¸ÇÁË·¿²úÆóÒµµÄ¸÷¸öÖ°Äܲ¿ÃŵÄÖ÷Òª¹¤×÷¡£

¸ÃϵͳµÄÈ«ÃæÍƹãºÍʵʩ£¬±Ø½«Ê¹·¿²úÆóÒµµÄÓªÏú¹ÜÀíˮƽÌá¸ßµ½Ò»¸öȫеIJã´Î¡£


ÁªÏµ£º0 8 6 - 7 5 5 - 6 1 3 2 5 2 1 5   ÀîÏÈÉú litao@ltsoft.org   QQÔÚÏß:17133845

ÄúÉÏ¿Í»§¹Øϵ¹ÜÀíϵͳÁËÂð,ÎÒÏëÕâÀïÓÐÄã×îºÃµÄÑ¡Ôñ!

[nNbyh0xm7h0r]

  
    Super-CRM¿Í»§¹Øϵ¹ÜÀíϵͳ5.0,½öÊÛ 800 Ôª.
    
    ÓÐÁ˱¾ÏµÍ³,ÄúÔÙÒ²²»Óõ£ÐÄÄúµÄÓÅÖÊ¿Í»§ËæÒµÎñÈËÔ±µÄ±ä¶¯¶øÁ÷ʧ!!!
    
    ²âÊÔµØÖ·  http://litiansoft.oicp.net/supercrm.htm
  
    ½øÈë21ÊÀ¼Í£¬¿Í»§ÒѳÉΪÆóÒµµÄºËÐÄÕ½ÂÔ×ÊÔ´¡£¿Í»§µÄʶ±ð¡¢Ñ¡Ôñ¡¢ÕùÈ¡¡¢
·¢Õ¹ºÍ±£³Ö£¬¼´¿Í»§¹Øϵ¹ÜÀíCRM,ÒѳÉΪÆóҵȷÁ¢Êг¡¾ºÕùÓÅÊƵÄ×îÖØÒªÒ²ÊÇ
ΨһµÄ»ù´¡¡£»ùÓÚ´Ë£¬½ç·¶Î§ÄÚ»ñµÃÁ˹㷺µÄÓ¦Óú;޴óµÄ³É¹¦¡£È»¶ø£¬ÎÒ¹ú
´ó²¿·ÖÆóÒµ£¬ÌرðÊÇÖÐСÆóÒµÔÚCRMϵͳ½¨Éè·½ÃæÉд¦ÓڱȽÏÂä    ºóµÄ״̬£¬
Ãæ¶ÔWTOµÄÌôÕ½ºÍ¹úÄÚ¼¤ÁÒµÄÊг¡¾ºÕù£¬ÕâЩÆóÒµÃ÷ÏÔȱ·¦Ö    ʤµÄ¹Ø¼üÄÜÁ¦¡£ 

    »ùÓÚÉÏÊö˼·£¬ÉîÛÚÊÐÁ¦ÌìÈí¼þ¿ª·¢ÓÐÏÞ¹«Ë¾³ä·ÖÔËÓÃÁ½Äê¶àÀ´ÔÚÊг¡Óª
Ïú¹ÜÀíºÍ¿Í»§¹Øϵ¹ÜÀí·½Ãæ»ýÀ۵ķḻ֪ʶºÍ¾­Ñ飬ÔÚ´óÁ¿¿Í»§Ó¦Óü°·´À¡µÄ
»ù´¡ÉÏ£¬½«Á¦ÌìSuperCRM¿Í»§¹Øϵ¹ÜÀíϵͳ³É¹¦Éý¼¶µ½ÁË5.0°æ±¾£¬±ÈÒÔÇ°°æ±¾
¹¦ÄܸüÇ¿£¬Éè¼ÆÒ²¸ü¼ÓºÏÀí¡£ 

    ¸ÃÈí¼þÄܸ¨ÖúÆóÒµÀÎÀΰÑÎÕ¿Í»§×ÊÔ´£¬¶´²ì¿Í»§ÐèÇ󣬼ÓÇ¿¿Í»§ÍÚ¾ò¡¢¿Í
»§¸ú½ø¡¢¿Í»§·þÎñ¡¢¿Í»§¹Ø»³µÄÒµÎñ½ø³ÌµÄ¹ÜÀí£¬Ìá¸ß¿Í»§ÏìÓ¦Ëٶȼ°·ÖÎö¡¢
¾ö²ßµÄÄÜÁ¦£¬ÌáÉý¿Í»§ÂúÒâ¶È£¬ÔöÇ¿ÆóÒµÓ®ÀûÄÜÁ¦¡£¸ÃÈí¼þÏÖÒÑÔÚ»ª¹¤¿Æ¼¼¡¢
³þÌ켤¹âµÈÖªÃûÆóÒµ»ñµÃÓ¦Ó㬷¢Õ¹Ç°¾°¹ãÀ«¡£

   SupercrmÊÇÒÔ¿Í»§ÎªÖÐÐĵÄÐÅϢϵͳ£¬Ê¹ÆóÒµÍêÕûµØÈÏʶÕû¸ö¿Í»§ÉúÃüÖÜÆÚ
£¬ÌṩÓë¿Í»§¹µÍ¨µÄͳһ̨£¬Ìá¸ßÔ±¹¤Óë¿Í»§½Ó´¥µÄЧÂʺͿͻ§·´À¡ÂÊ, ͨ¹ý¹Ü
ÀíÓë¿Í»§¼äµÄ»¥¶¯£¬Å¬Á¦¼õÉÙÏúÊÛ»·½Ú£¬½µµÍÏúÊ۳ɱ¾£¬·¢ÏÖÐÂÊг¡ºÍÇþµÀ£¬Ìá
¸ß¿Í»§¼ÛÖµ¡¢¿Í»§ÂúÒâ¶È¡¢¿Í»§ÀûÈó¹±Ï׶ȣ¨profitability£©¡¢¿Í»§Öҳ϶ȣ¬
ʵÏÖ×îÖÕЧ¹ûµÄÌá¸ß. SumpercrmÖ¼ÔÚÍê³ÉÒÔÏÂÄ¿±ê£º 

    1:¶Ôÿ¸ö¿Í»§µÄÊý¾Ý½øÐÐÕûºÏ£¬Ìṩ¶Ôÿ¸ö¿Í»§µÄ×ܵĿ´·¨ 
    2:Ãé×¼ÀûÈó¹±Ï׶ȽϸߵĿͻ§£¬Ìá¸ßËü¶Ô±¾¹«Ë¾µÄÖÒ³Ï¶È 
    3:Ïò¿Í»§Ìṩ¸öÐÔ»¯µÄ²úÆ·ºÍ·þÎñ 
    4:Ìá¸ßÿ¸öÏúÊÛԱΪÆóÒµ´øÀ´µÄÊÕÈ룬ͬʱ¼õÉÙÏúÊÛ·ÑÓúÍÓªÏú·ÑÓÃ; 
    5:¸ü¿ì¸üºÃµØ·¢ÏÖÏúÊÛ»ú»á£¬¸ü¿ì¸üºÃµØ½øÏìÓ¦¿Í»§²éѯ
    6:Ïò¸ß²ã¹ÜÀíÈËÔ±Ìṩ¹ØÓÚÏúÊÛºÍÓªÏú»î¶¯×´¿öµÄÏêϸ±¨¸æ
    7:¶ÔÊг¡µÄ±ä»¯×ö³ö¼°Ê±µÄ·´Ó¦   
    
    Õý¹æ¹«Ë¾,Õý¹æ·¢Æ±,ÐÅÐı£Ö¤.    

    ÁªÏµÈË£ºÀîÌÎ

    µç »°£º0755-6 1 3 2 1 1 9 6      ´«Õ棺0755-26786121

    E-mail:  litao@ltsoft.org

·¿µØ²úÓªÏú¹ÜÀíϵͳ×îÐÂÍƳö......

[EZHBCVrmIO2lGS]

ÔÚÏß²âÊÔµØÖ·:  http://ltsoft.88ip.cn/dc.htm

Ëæ׿ÆËã»ú¼¼ÊõµÄ·¢Õ¹ºÍÆäÔÚÉÌÒµÉϵĹ㷺ӦÓã¬ÀûÓü¼ÊõÊÖ¶ÎʵÏÖ·¿²úÆóÒµÓªÏúÒµÎñ¹ÜÀíµÄÐÅÏ¢»¯¡¢¹æ·¶»¯ºÍÏÖ´ú»¯ÒѾ­Öð½¥Îª¸÷·¢Õ¹ÉÌÈÏʶºÍÖØÊÓ.

Á¦ÌìÈí¼þƾ½èÆäÔÚ·¿µØ²úÐÐÒµ¶àÏî½â¾ö·½°¸µÄÌṩºÍʵʩ¾­Ñ飬Õë¶ÔÄ¿Ç°ÎÒ¹ú·¿µØ²úÐÐÒµÓªÏú¹ÜÀíµÄÏÖ×´£¬½áºÏ¸÷¸ö·¿µØ²ú¹«Ë¾ÏÖÓеÄÈíÓ²¼þͶ×Êˮƽ£¬¾­¹ýÓë¸÷´ó·¿µØ²úÒµÖªÃûµ¥Î»µÄÃÜÇкÏ×÷£¬ÔÚ¹úÄÚÂÊÏÈÍƳöÁËÍêÈ«»ùÓÚä¯ÀÀÆ÷µÄµÚÈý´úÊÛÂ¥¹ÜÀíÈí¼þ--Á¦Ìì·¿²úÓªÏú¹ÜÀíϵͳ£¬Ä¿Ç°¸ÃϵͳÒѾ­ÔÚÊ®Óà¸öÂ¥ÅÌÏîÄ¿µÄÏúÊÛ¹ÜÀíÖ®Öгɹ¦Ó¦Óò¢µÃµ½Á˹㷺ºÃÆÀ¡£

¸Ãϵͳ²ÉÓÃÁË¿çµØÓòµÄB/S£¨ä¯ÀÀÆ÷/·þÎñÆ÷£©½á¹¹Éè¼Æ£¬È«ÃæÖ§³ÖÒƶ¯°ì¹«¼°ÒìµØÔ¶³Ì°ì¹«£¬·ûºÏ·¿²ú¹«Ë¾×ܲ¿ÓëÊÛÂ¥´¦·ÖÀëµÄʵ¼ÊÇé¿ö¡£ÏµÍ³°üÀ¨ÏîÄ¿¹ÜÀí¡¢¾ö²ß¹ÜÀí¡¢ÏúÊÛ¹ÜÀí¡¢²ÆÎñ¹ÜÀí¡¢¿Í»§¹Øϵ¹ÜÀí¡¢¹ã¸æÓªÏú¹ÜÀí¡¢°ì¹«¹ÜÀí¡¢ÊÛºó·þÎñ¹ÜÀí¡¢Í³¼Æ±¨±íµÈ¾Å´ó¹¦ÄÜÄ£¿é£¬»ù±¾º­¸ÇÁË·¿²úÆóÒµµÄ¸÷¸öÖ°Äܲ¿ÃŵÄÖ÷Òª¹¤×÷¡£

¸ÃϵͳµÄÈ«ÃæÍƹãºÍʵʩ£¬±Ø½«Ê¹·¿²úÆóÒµµÄÓªÏú¹ÜÀíˮƽÌá¸ßµ½Ò»¸öȫеIJã´Î¡£


ÁªÏµ£º0 8 6 - 7 5 5 - 6 1 3 2 5 2 1 5   ÀîÏÈÉú litao@ltsoft.org   QQÔÚÏß:17133845

ÔÚÏßÓÎÏ·ÓéÀÖ¿¨ÏúÊÛƽ̨,ÓÅ»ÝÏúÊÛ

[1JSfZzTbogVj]

ÔÚÏß²âÊÔµØÖ·¡¡http://ltsoft.88ip.cn/gamecard.htm
ÁªÏµÈË:ÀîÌÎ µç»°:086-755-61325215  QQ:17133845

Á¦ÌìÓÎÏ·µã¿¨ÏúÊÛ¹ºÎïƽ̨ÊÇÒ»Ì×¼¯ÍøÉÏÏúÊÛÓÎÏ·¡¢ÓéÀֵȸ÷ÖÖʵÎ￨µÄÏúÊÛ¹ÜÀíϵͳ¡£
¾­ÓªÕß½«¸÷ÖÖʵÎ￨ÐÅÏ¢ÊÂÏȼÈ뵽ϵͳ£¬ÒÔÔÚÏßÐéÄâ½»Ò׵ķ½Ê½£¬¿ìËÙÍê³ÉÓÎÏ·Íæ¼Ò
µÄ¹º¿¨¡¢³äÖµ¹ý³Ì¡£
¿ÉÒÔÃæÏò¸÷Íø°É»òÍæ¼ÒµÈÍê³ÉÏúÊÛ¼°¹ÜÀíµÄ¹¦ÄÜ¡£

¾­ÓªÍøÕ¾Õß¿ÉÒÔ´ÓÆäËû´¦Åú·¢¹ºÂòµã¿¨£¬È»ºó¼Èëµ½±¾ÏµÍ³ÖУ¬Íø°ÉµÈÆäËûÖ±ÏúÉÌ¿ÉÒÔ
Ãâ·Ñ×¢²á£¬²¢Ö§¸¶ÄúÒ»¶¨µÄÔ¤¸¶¿î£¬µ±ÓÎÏ·Íæ¼ÒÐèÒª¹ºÂòµã¿¨Ê±£¬Íø°ÉµÈÆäËûÖ±ÏúÕß×÷
ΪֱÏúÉÌ¿ÉÒÔÖ±½Óͨ¹ýÍøÕ¾´úΪÆ乺Âò£¬²¢´ÓÆäÔ¤¸¶¿îÖп۳ýÏàÓ¦µÄ½ð¶î¡£

ÕâÖÖÏúÊÛ·½Ê½¶ÔÓÚ´«Í³µÄÏúÊÛʵÎ￨ÊÇÒ»¸ö¾Þ´óµÄ³å»÷£¬Ò²·Ç³£ÊÊÓ¦ÓÎÏ·Íæ¼Ò¿ìËÙ¡¢±ã
½ÝµÄÓÎÏ·ÐèÇó£¬Ä¿Ç°Êг¡Ç±»ú¾Þ´ó£¬¶øÇÒ²Ù×÷ÆðÀ´¼òµ¥¡¢·½±ã£¬ÉîÊÜ´ó¼ÒµÄ»¶Ó­£¬ÓµÓÐ
Ò»Ì×ÔÚÏßÏúÊÛϵͳ£¬¿ÉÒÔÔÚ¼Ò×öÀϰ壡

¸ÃϵͳÓÐÒÔÏÂÖ÷Òª¹¦ÄÜ£º

1:Ö±ÏúÉÌ×¢²áµÇ¼ϵͳ£¬½¨Á¢ÍêÕûµÄÖ±ÏúÉÌ×ÊÁÏ¿â
2:ÉÌÆ··ÖÀà¡¢·Ö¼¶£¬¿ÉÒÔÏúÊÛ¸÷ÖÖÓÎÏ·¡¢ÓéÀÖ¿¨£¬ÉõÖÁµç»°¿¨µÈ
3:·½±ã¼ò½àµÄ¹º¿¨¡¢ÏÔʾ¿¨ºÅÁ÷³Ì
4:×Ô¶¯´ÓÔ¤¸¶¿îÖп۳ý½ð¶î£¬×Ô¶¯ÏÔʾ¿¨ºÅµÈ
5:ÕÊ»§Óà¶îÏÔʾ¡¢ÌáÐÑ
6:ÀúÊ·¶©µ¥¹ÜÀí¡¢ä¯ÀÀ
7:»áÔ±ÃÜÂë¼ÓÃÜ£¬ÔöǿϵͳµÄ°²È«ÐÔ
8:Ö±ÏúÉÌÃâ·Ñ×¢²á£¬ÊÕµ½Ô¤¸¶¿îºóÉóÅú¹¦ÄÜ
9:ÉÌÆ·¶©µ¥Ã÷ϸÇåÎú£¬Ó¦¸¶¿îÏîÇå³þ
10:ºǫ́´¦ÀíÌṩÉÌƷͳ¼Æ¡¢·ÖÎöÄÜÁ¦£¬°ïÖú¾ö²ß
11:ÉÌÆ·ÏÔʾ˳Ðò¿É×Ô¼ºÉ趨£¬Èç°´¼Û¸ñµ¹Ðò¡¢ÉýÐò£¬°´¹ºÂòÁ¿ÉýÐò¡¢µ¹ÐòµÈµÈ

Òæ´ï¸ã»î¶¯,ÇëͶÎÒÅ®¶ùһƱ,лл!

[SbvrFXRM0Wv7RI]

Òæ´ï½à°×,Ц³ö²ÊÉ«ÈËÉú¸ãÒ»¸ö»î¶¯,ÎÒ°ÑÎÒÅ®¶ùµÄÕÕƬ
Ò²´«ÉÏÈ¥ÁË.ÄúÈç¹ûÓпÕ,¾Í°ÝÍаïæͶÎÒÅ®¶ùһƱ,ÔÚ´Ë
ÏÈÐжàлÁË!

ÎÒÅ®¶ùµÄͼƬµØÖ·ÈçÏÂ:
http://www.extrawhite.com.cn/detail.asp?id=590EA968-0E98-40F4-ABB9-C1EDDA65B4D9

ÎÒ×ÔÈÏΪÎÒÅ®¶ùµÄЦÈÝÊÇÊÀ½çÉÏ×î²ÓÀÃ×îÃÀµÄ,ËýÊÇÈ«¼ÒµÄ
¿ªÐĹû°¡!

ÄúÖ»ÐèÔÚÏÂÃæµÄ "ÎÒҪͶһƱ" Á¬½ÓÖÐ "Ö±½Ó½øÈëͶƱ" ¾Í¿É
ÒÔÁË,²»ÐèҪע²áÌîд×ÊÁϵÄ.²»¹ýÈç¹ûÄã×¢²áÔÙͶƱ,Ò²¿ÉÄÜ
Öн±µÄ.

°ÝÍаÝÍÐ!

-------------------------------------------------------
Èç¹ûÄú²»Ï²»¶ÎÒÕâô×ö,Çë¼ûÁÂ!È«µ±Ò»Ð¦!лл!

ÆóÒµ¼¶Ò»±ßËÑË÷ÓÊÖ·Ò»±ß×Ô¶¯·¢ËÍÓʼþÈí¼þ

[software]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

站长，您好！帮帮忙发布下面的软件，谢谢！ 
    
    软件名称：搜易高速邮址搜寻家[EmailSearcher]
    软件版本：V 3.5
    软件语言：简体中文
    软件大小：846KB
    应用平台：Win9x/Me/NT/2000/XP
    免费下载：http://emlseek.2616.net
    免费下载：http://emlseek.snsun.com
    免费下载：http://emlseek.ywzc.net
    QQ联系：114075303  电话：(0519)8670323
    界面预览：http://EmlSearch.cnnb.net
   
    软件介绍： 

        最新一流多线程飞快搜索电邮软件！一边搜索一边发送！特色功能如下：
    1.域名电邮搜索，只需输入一个后缀如hotmail.com/sina.com/即可搜索电邮；
    2.高品质多线程模式，验证搜索速度最快可达每小时60000个真实有效电邮；
    3.自建桌面SMTP服务器，可单发或多发文本/网页信件到搜索后的有效邮址；
    4.语音操作唤醒提示/自动挂断网络，可于系统托盘处后台工作，省时省钱；
    5.手动/自动保存进程，可中断后继续搜索，可晚上无人值守，适宜包月上网；
    6.国内多家知名电子商务公司选用，是推广网站和开展网上营销的绝佳工具。
   
    ----------------------------------------
   
    极限邮件[群]发软件：

    免费下载：http://emlseek.snsun.com
    免费下载：http://emlseek.ywzc.net

   
     

???

[Charlie LaMothe]

How do I burn a CD on linux?

Also, how do I set the root WWW directory on apache?

Thanks

×Ô¶¯²¦´òµç»°ºÅÂë²¥·ÅÓïÒô֪ͨ¹ã¸æÈí¼þ

[software]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

站长，您好！帮帮忙发布下面的软件，谢谢！ 

  软件名称：新狐电话广播[TelSky]
  软件语言：简体中文 
  文件大小：795KB
  使用平台：Win9x/Me/NT/2000/XP  
  免费下载：http://yxsoft365.k900.com
  免费下载：http://yxsoft365.7871.com
  免费下载：http://yxsoft365.yeah.net
  免费下载：http://yxsoft365.cnnb.net
  电话联系：0 5 1 9 8 6 7 0 3 2 3
  QQ咨询：1 1 4 0 7 5 3 0 3
  软件简介：
　　  国产简体中文版通过Modem自动拨打成千上万的电话号码播放语音通知
  软件。只需一台电脑和一部电话，录制好你要播放的语音，生成你要拨打的
  成千上万的电话号码列表，软件自动连续拨打每个号码并播放语音通知，根
  据客户在电话机上的按键数字获取信息反馈，整个过程完全无需人工干预，
  广泛应用于企业开展电话营销广告、社会调查、费用催缴通知、叫早、灾害
  广播、生日祝贺点歌、用户回访跟踪、城管呼死你等应用场合，是一款推行
  欧美国家广泛流行的电话营销模式所不可缺少的广告工具。


  
 

   

¿ªÉè²»Ò»ÑùµÄÏúÊÛÉ̳Çϵͳ

[dalu5464]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312, Size: 1080 bytes --]

linux-kernel:ÄúºÃ

    EE990ÊÇÓÉ´ó·ÍøÂçͶ×ʽ¨Á¢µÄ¹úÄÚ´óÐ͵ç×ÓÉÌÎñƽ
̨£¬EE990µÄ½¨Á¢ÊÇÖÂÁ¦ÎªÉ̼ÒÌṩ´óÐÍ¡¢×¨Òµ¡¢¹¦ÄÜÇ¿
´ó¡¢¹ÜÀíÍêȫɵ¹ÏʽµÄ¶ÀÁ¢ÉÌÆ·ÍøÂç½»Ò×ƽ̨¡£

    ÏÖÔÚÁ¢¼´×¢²áEE990ƽ̨ÉÌ»§Á¢¼´»ñµÃÍêÈ«ÊôÓÚÄúµÄ
Ç¿´ó¹ºÎïÍøÕ¾£¬²¢Ãâ·ÑÓµÓйú¼Ê¶ÀÁ¢ÓòÃûÒ»¸ö¡£Á¢¼´×¢
²á¸¶¿îºóÊ®·ÖÖÓ¼´¿É¿ªÍ¨¡£Í¬Ê±ÄúµÄÍøÕ¾½«ÓµÓÐÇ¿´óµÄ
ÒøÐÐÔÚÏßÖ§¸¶Ìåϵ¡¢È¨ÍþµÄEE990³ÏÐÅÉÌ»§ÈÏÖ¤¡¢¶ÀÁ¢µÄ
ɵ¹Ïʽºǫ́¹ÜÀí£¬Ö»Ð輸·ÖÖӵļòµ¥ÉèÖÃÁ¢¼´¿ÉÒÔÓµÓÐ
¹¦ÄÜÇ¿´óÇÒ½çÃæÍêÃÀµÄÍøÂçÉ̳ÇÒ»×ù£¬ÊʺÏËùÓÐÉÌ
¼ÒÔÚÏß²úÆ·ÏúÊÛ¡£

4ÔÂ18ÈÕ-4ÔÂ28ÈÕÄÚ×¢²áEE990ÉÌ»§¿ÉÁ¢¼´Ãâ³ýÿÄêÈËÃñ
±Ò2000ÔªÉ̳ÇʹÓ÷ѣ¬Ö»ÐèÿÄê380ÔªÉÌ»§¹ÜÀí·Ñ
£¨Í¬Ê±Ãâ·Ñ¸½Ë͹ú¼Ê¶¥¼¶ÓòÃûÒ»¸ö£©

Á¢¼´·ÃÎÊÕ¾µã£ºhttp://www.ee990.com/ok/index.htm

24СʱÈÈÏß×Éѯֵ°à×Ü»ú£º025-52381747  ¿Í»§¹ºÂò×Éѯ ת 601¡¢602¡¢603¡¢604

24Сʱ¼¼ÊõÖ§³ÖÖµ°à×Ü»ú£º025-52207744-602¡¢603¡¢604¡¢605   52210862

¿Í»§·þÎñÖÐÐÄ£º025-57938094¡¢57938095¡¢57938096¡¢52381757

24Сʱ¿Í·þ QQ£º332954955  20265342

µç×ÓÓʼþ£ºwebmaster@ee990.com





ý:.žË›±Êâmçë¢kaŠÉb²ßìzwm…ébïîžË›±Êâmébžìÿ‘êçz_âžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣømšSåy«\x1e­æ¶\x17…\x01\x06­†ÛiÿÿðÃ\x0fí»\x1fè®\x0få’i\x7f

ðÒÁËÔÉÞÅÓËÉÊ ÍÁÒËÅÔÉÎÇ

[mnd41]

[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]

      Повышение конкурентоспособности Вашей компании напрямую зависит от 
расширения круга потребителей - приверженцев  ее продукции и услуг. Этого
можно  добиться только при четкой организации взаимодействия всех
структурных подразделений и, в первую очередь, отделов маркетинга и сбыта.

       Чтобы повысить конкурентоспособность Вашей компании, необходимо
внедрить четкие технологические процессы организации и проведения работ,
отведя функции маркетинга одну из ключевых ролей. Как это сделать, Вы
узнаете, посетив уникальный бизнес-семинар: 

                             ПРАКТИЧЕСКИЙ МАРКЕТИНГ
         (Внедрение Стандарта Предприятия (СТП) по маркетингу и сбыту).
                             22-23 мая 2003 года.

      На семинаре Вы получите: алгоритм выполнения работ в сфере
маркетинга, рекламы и сбыта и организации практического взаимодействия этих
служб с другими подразделениями предприятия.  А также конкретные ответы на 
вопросы: кто, что, где, когда делает, кому, в какой форме, в какие сроки и
каким образом передает отчетные и аналитические материалы, за что несет
персональную ответственность от автора,  разработавшего и внедрившего СТП по
маркетингу и сбыту на нескольких предприятиях. 

      Получить дополнительную информацию и забронировать место на тренинге Вы   
можете по телефону: (095) 258-51-84

В программе семинара: 

Маркетинг как ключевой бизнес процесс 
Место и задачи служб маркетинга: виды организационных структур.   
Порядок изучения спроса на продукцию 
Порядок анализа ассортимента продукции 
Установления размера отпускной цены
Порядок организации рекламной, директ-маркетинговой и PR кампаний
Порядок разработки плана маркетинга и анализа его выполнения
Критерии оценки эффективности работы службы маркетинга.
Структура и порядок внедрения СТп
Построение эффективной системы сбыта
Виды каналов товародвижения 
Создание прозрачной среды сбыта и CRM - системы управления взаимоотношений
с Потребителями. 
Эффективное взаимодействие с агентской, дилерской и дистрибьюторской 
сетями. 
Электронная подпись и новые возможности электронной коммерции 
Многокритериальный подход к расчету ФЗП сотрудников службы сбыта,
обеспечивающий достижение рыночных целей компании (предприятий)


Если Вы не можете посетить этот семинар в указанные даты, мы будем рады
провести его для сотрудников Вашей компании индивидуально.
По вопросам организации корпоративного семинара (тренинга) звоните по тел.:
(095) 258-51-84

С уважением, организаторы.

üÍÉÇÒÁÃÉÑ × å×ÒÏÐÕ ÄÌÑ ×ÓÅÈ!

[ryan_sparrow]

[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]

Вы русский или украинец, белорус или казах? Вы хотите жить в цивилизованной стране? 
Вы хотите иммигрировать, но не знаете как? Вы хотите обеспечить своё будущее и 
будущее своих детей? Тогда зайдите к нам на сайт 
http://www.gnmos.biz или http://64.46.116.29
 
Мы поможем Вам эмигрировать в Германию или Грецию а также получить вид на 
жительство в Чехии! Мы специализируемся на иммиграции граждан из России и стран 
СНГ вне зависимости от национальности или возраста! Мы проинформируем Вас о 
порядке, сроках и стоимости услуг по эмиграции. Немецкая фирма, представителями 
которой мы являемся на территории России, стран СНГ и Балтии, заключит с Вами 
договор, подготовит все необходимые документы и проинструктирует Вас о порядке 
сдачи и получения документов. Иммиграция в Европу - это Ваш шанс стать жителем 
развитой страны, страны, имеющей отличные условия для жизни, страны имеющей 
мощную экономику, многонациональное общество, лояльное по отношению к 
иммигрантам. На сайте Вы можете ознакомиться с условиями эмиграции, с культурой, 
политической и экономической жизнью Германии и Греции, а также подписаться на 
новости и обсудить интересующие Вас вопросы и получить большое количество 
дополнительной информации на форуме! Если Вас интересует информация по Чехии, 
звоните, и наши менеджеры ответят на дополнительные вопросы.
Звоните нам в Москве (095) 189-58-20 и в Германии 8-10-49 1798776653
 
Для отписки отправьте, пожалуйста, пустое письмо на 
следующий адрес unsub2003@front.ruN▀╖╡ФЛr╦⌡yЗХ ьb╡X╛╤г╖vь^√)ч╨{.nг+┴╥╔┼{╠▒ЙГzX╖╤\x17⌡║э╗}╘·╡ф═zз&j:+v┴╗╬\a╚▒ЙГzZ+─й+zfё╒╥h ┬╖~├╜├шiЪШЮz╧\x1e╝w╔╒╦?≥╗Х╜з&╒)ъ╒^[f■Ы^jг╚y╖m┘А@A╚a╤з\x7fЪ\f0╤Лh╝\x0fЕ▓i\x7f

:(((((((

[Balram Adlakha]

when will I see a native linux kernel module for Nvidia based cards? I'm sick 
of the nvidia.com one.
Is there a possibility of making one in the near future? Hasn't nvidia given 
out any documents for their cards?

Re: :(((((((

[CaT]

On Fri, Apr 25, 2003 at 09:18:34PM +0530, Balram Adlakha wrote:
> when will I see a native linux kernel module for Nvidia based cards? I'm sick 
> of the nvidia.com one.
> Is there a possibility of making one in the near future? Hasn't nvidia given 
> out any documents for their cards?

If they had I have a feeling that a billion and 1 coders would've
swarmed upon it and coded something up, or nvidia would've just released
the proper source code.

Unfortunately, I believe they're still sitting comfortably with a
geforce4 up their butts, keeping them nice and warm.

If you want you can send them a nice, polite letter (as angry/emotional
ones are likely to do more harm then good) explaining why you feel the
current state of affairs is wrong and why they should correct it (and
how).

-- 
Martin's distress was in contrast to the bitter satisfaction of some
of his fellow marines as they surveyed the scene. "The Iraqis are sick
people and we are the chemotherapy," said Corporal Ryan Dupre. "I am
starting to hate this country. Wait till I get hold of a friggin' Iraqi.
No, I won't get hold of one. I'll just kill him."
	- http://www.informationclearinghouse.info/article2479.htm

Re: :(((((((

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

On Fri, 25 Apr 2003 21:18:34 +0530, Balram Adlakha <b_adlakha@softhome.net>  said:
> when will I see a native linux kernel module for Nvidia based cards? I'm sick
 
> of the nvidia.com one.

Feel free to take the open-source 'nv' driver from the XFree86 4.3.0 tree
and figure out how to put it into the kernel.  Figuring out how to splice
the licenses is the tricky part. ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: :(((((((

[Benjamin Herrenschmidt]

On Fri, 2003-04-25 at 18:08, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 25 Apr 2003 21:18:34 +0530, Balram Adlakha <b_adlakha@softhome.net>  said:
> > when will I see a native linux kernel module for Nvidia based cards? I'm sick
>  
> > of the nvidia.com one.
> 
> Feel free to take the open-source 'nv' driver from the XFree86 4.3.0 tree
> and figure out how to put it into the kernel.  Figuring out how to splice
> the licenses is the tricky part. ;)

That's +/- what rivafb already is. I have a version in my tree that
has some more updates from XFree that I intend to submit after 2.4.21

Ben.

ðÒÅÄÌÁÇÁÅÍáÍÅÒÉËÁÎÓËÉÅ×ÏÄÉÔÅÌØÓËÉÅÕÄÏÓÔÏ×ÅÒÅÎÉÑ.

[littlemisskris]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]

Доброго времени суток ! 
Хочу представить новый ресурс по изготовлению всех видов документов 
на основе пластиковых карт. Теперь Вы всегда можете заказать и получить 
в кратчайшие сроки Международные Водительские права (IADC), Штатовские 
права, Йд карты, Студенческие удостоверения и много другое... 

Все подробности на сайте: www.get-id.com

Всем Удачи!

óÅÍÉÎÁÒÙÄÌÑÂÕÈÇÁÌÔÅÒÉÉ

[buzybee164]

[-- Attachment #1: Type: text/plain, Size: 3818 bytes --]

Приглашаем Вас посетить актуальные семинары:
7 апреля: Сложные вопросы налогообложения (налог на прибыль, НДС, оплата труда)
8 апреля: Нормативные документы по бухгалтерскому учету: нововведения и изменения.
Телефоны: 207-26-21, 772-92-46

Семинар: Сложные  вопросы налогообложения
(налог на прибыль, НДС, оплата труда)
7 апреля 2002 г.

На семинаре анализируются противоречия и сомнения в толковании Налогового 
кодекса РФ, регламентирующих исчисление  НДС и налога на прибыль организаций 
и налогов с физических лиц. В ряде случаев конкретные хозяйственные ситуации 
иллюстрируются примерами из судебно-арбитражной практики, на основании которых 
вырабатываются практические рекомендации налогоплательщикам. 

1. Налог на прибыль
1.1     Доходы в бухгалтерском и налоговом учете (выручка, внереализационный доход)
1.2.    Расходы  (схема признания расходов, группировка расходов, материальные 
расходы, амортизация и др.)

2. Налог на добавленную стоимость
2.1.   Чем следует руководствоваться при исчислении НДС
2.2    В каких случаях налогоплательщик не является плательщиком НДС, 
2.3.   Проблемы со ст. 145 НК РФ
2.4.   Схема исчисления НДС

3. Оплата труда: бухгалтерский и налоговый аспект.
3.1     Бухгалтерский и налоговый учет расходов по оплате труда.
3.2     Санкции за нарушение трудового и налогового законодательства в сфере оплаты 
труда.
3.3     Сложные вопросы и типичные ошибки в расчетах по оплате труда.
 
На семинаре выступают:

МЕДВЕДЕВ Александр Николаевич,  к.э.н, главный аудитор ЗАО "Аудит БТ", автора 
40 книг и свыше 200  журнальных статей  по вопросам бухгалтерского учета,  
налогообложения  и хозяйственного права.
КЛИМОВА Марина Аркадьевна, к.э.н., профессиональный бухгалтер, автор книг 
"Налог на доходы физических лиц",  "Как правильно оформить учетную политику 
организации", "Документооборот в бухгалтерском учете", "Трудовой Кодекс РФ: 
постатейный комментарий",  "Заработная плата: практическое руководство", 
"Упрощенная система налогообложения" и многих других.

Семинар: Нормативные документы по бухгалтерскому учету 2002-2003 гг.: 
нововведения и изменения
8 апреля 2002 г.

1. Общая концепция реформы российского бухгалтерского учета (переход к ведению 
учета по международным стандартам). Новая редакция Закона "О бухгалтерском учете".
2. Новые положения по бухгалтерскому учету:
"	ПБУ 15/01 "Учет займов и кредитов и затрат по их обслуживанию" (вступает в 
действие с 1 января 2002 г.),
"	ПБУ 16/02 "Информация по прекращаемой деятельности",
"	ПБУ 17/02 "Учет расходов на научно-исследовательские, опытно-конструкторские 
и технологические работы",
"	ПБУ 18/02 "Учет расчетов по налогу на прибыль",
"	ПБУ 19/02 "Учет финансовых вложений".
Комментарии к тексту ПБУ и рекомендации по их практическому применению.
3. Нормативные документы, изменения в которые официально приняты не были, но 
переставшие удовлетворять требованиям нормативных документов более высокого уровня.

     Программа разработана А.А.Ефремовой - автором ряда книг по методологии и 
	 практике бухгалтерского учета, в т.ч.: "Учетная политика: содержание и 
	 процесс формирования", "Учет собственного капитала", "Учет основных средств 
	 и учетная политика предприятия", а также многочисленных статей в 
	 специализированных периодических изданиях.

Организатор семинаров Международный центр обучения. 
Контактные телефоны 207-26-21, 772-92-46 

При участии одного человека стоимость любого семинара составляет 3 900 руб., 
с учетом НДС. При участии в двух семинарах (или двух человек в одном семинаре) 
предоставляется скидка 10%. При участии в трех семинарах (или трех человек), 
четвертый - в подарок. В стоимость семинара также входит раздаточный материал, 
кофе-пауза и обед в ресторане. Начала семинара в 10 часов, окончание в 17.00-17.30. 
Место проведения м. Академическая, 2 минуты от метро.

ïÐÌÁÔÁÔÒÕÄÁ:ÂÕÈÇÁÌÔÅÒÓËÉÊÉÎÁÌÏÇÏ×ÙÊÁÓÐÅËÔ.

[yakineta]

[-- Attachment #1: Type: text/plain, Size: 2143 bytes --]

По многочисленным просьбам повторяем семинар:

"ОПЛАТА ТРУДА: бухгалтерский и налоговый аспект" - 11 марта

1.  Правовые основы оплаты труда - что нового? (в свете положений ТК РФ 
    и с учетом последних изменений).
2.  Оплата за отработанное время:
-   минимальный размер оплаты труда,
-   заработная плата, тарификация работ,
-   доплаты и надбавки,
-   гарантии и компенсации.
3.  Оплата за неотработанное время:
-   оплата отпусков,
-   оплата льготных часов,
-   компенсация работникам, совмещающим работу с учебой,
-   оплата при выполнении государственных и общественных обязанностей.
4.  Другие выплаты работникам. 
5.  Расчеты при увольнении работника.
6.  Удержания из заработной платы:
-   налог на доходы физических лиц,
-   удержание в погашение задолженности работодателю,
-   удержание по исполнительным документам и др.
7.  Бухгалтерский и налоговый учет расчетов по оплате труда.
8.  Санкции за нарушение трудового и налогового законодательства в сфере 
    оплаты труда.
9.  Сложные вопросы и типичные ошибки в расчетах по оплате труда.
 
На семинаре выступает Климова Марина Аркадьевна, к.э.н., профессиональный 
бухгалтер, автор книг "Налог на доходы физических лиц",  "Как правильно 
оформить учетную политику организации", "Документооборот в бухгалтерском 
учете", "Трудовой Кодекс РФ: постатейный комментарий",  "Заработная плата: 
практическое руководство",  "Договоры гражданско-правового характера: 
заключение, учет и налогообложение"
Семинары проходят в Москве (м. Академическая, 2 минуты от метро пешком). 
Организатор семинаров Международный центр обучения.
Контактные телефоны (095) 207-26-21, 772-92-46. 
При участии одного человека стоимость  любого семинара составляет 3 900 руб., 
с учетом НДС. При участии в 2 семинарах (или 2 человек в одном семинаре) 
предоставляется 10% скидка, при участии в 3 семинарах (или 3 человек), 
четвертый - в подарок. При участии в 4 семинарах (четвертый бесплатно) 
профессиональным бухгалтерам выдается сертификат о прохождении программы 
ежегодной переподготовки ИПБ в объеме 40 часов. При регистрации сообщите 
номер членского билета ИПБ и дату уплаты членских взносов.

±±¾©×îµÍ¼ÛÖÆ¿¨£¡£¡

[È«¹ú4000ÍòEMAILµÍ¼ÛתÈã¡£¡]

一、金属镀金镀银卡价格表：

               普通印油卡(名片)     高精度腐蚀卡(名片)
               镀银卡    镀金卡     镀银卡     镀金卡
10000张以上    3.30元    3.60元     3.50元     3.90元
 5000张以上    4.00元    4.50元     4.50元     5.00元
 1000张以上    4.80元    5.50元     5.50元     6.00元
  500张以上    5.20元    6.00元     6.00元     6.50元
  300张以上    6.00元    6.50元     7.00元     7.80元
  100张以上    7.00元    7.50元     8.00元     8.80元

我公司代理制作的金卡银卡，内部采用日本进口名贵青铜、表层镀24K真金或镀银，再过油形成保护层，
共30多道工艺精制而成。表面均匀密实,质地坚实厚重,成色亮丽而不失典雅，古朴厚重且富有新意，具
有很高的品位。广泛应用于酒店饭店、美容院的贵宾卡、会员卡、储值卡等及个人高档名片领域。

特别推荐：镀金镀银高档名片、高精度镭射镀金护身佛像卡。


二、PVC卡价格表：

	        100张     300张      500张	1000张	  3000张    5000张
彩色丝印卡	2.60元	  1.80元     1.50元	1.00元	  0.80元    0.70元
彩色胶印卡	5.50元	  3.50元     2.60元	1.80元	  1.50元    1.20元
高清晰人像卡	10-50张8.00元	     50-100张7.00元	  1000张6.00元


三、高水准超低价设计印刷

标志设计   书封画册   海报招贴  
包装设计   宣传彩页   印刷喷绘

单页设计150元/页 
包装设计1500元/件 
标志设计1000元起



电话/传真：010-68223657           
手机：13301098519
E-mail:seasmood@263.net  
地址：北京市海淀区五棵松路81号


四、全国4000万伊妹儿任您挑！！

我公司自用全国EMAIL地址集，涉及71个行业，34个地区，近60个主要网站，共计6000多万个地址，现在与您分享。
您想坐在家中就把广告作到全国各地每一个用户身上，而且不花一分钱广告费吗，那就立刻拥有吧！
也许，您要找的顾客现在正在找您，让需要您服务的客户知道您，让更多的潜在客户知道您，那就立刻拥有吧！！
让您的企业在最短的时间内让最多的人知道，那就立刻拥有吧！！！
4000多万EMAIL，只需268元，同时奉送极星邮件群发1.73（最新版）、亿虎Email群发大师，超级搜址专家注册版，前两款软件能自动高
效发送您定制好的邮件，使您如虎添翼，真正坐享其成！！
商场就如战场，先发制人，就得抢占先机！立刻行动，立即拥有吧！！

全套只需268元，恕不议价。分地区、行业购买，每组50元，不送相关软件。谢谢合作！

汇款地址：
北京市海淀区五棵松路81号永金里小区办公楼325房  杨志海收
E-mail:seasmood@263.net  
联系电话：010-68223657
也可通个银行汇款：
招商银行一卡通号：0010  34753254  用户名：杨志海
款到当天即将地址光盘特快专递给您，北京地区当天快递到您手中。（请写清您的地址姓名，以防误投。）



〖全国省市数量分类表〗
北京/上 海/天 津/重庆/河北/山西/浙江/海南省/安徽/四川省/福建/贵州/江西/云南/山东/
内 蒙/河南/陕西/黑龙江/ 湖北省/甘肃/辽 宁/ 湖南/ 青海/吉 林/广东/宁夏/江 苏/广西/
新疆/台湾/香港/澳门。 

〖Email列表分类〗 
163.net;169.cc;21cn.com ;21cn.net;100yi.com ;1010.com;126.com163.com;

263.net.cn;263.net;2911.net;363.net;371.net;39.net ;51.com;5415.com;

777.net.cn;8848.net;9394.com;alibaba.com;baoscape.com;beayu.com;

ccidnet.comce.net.cn;cenpok.net;china.com ;china139.com;chinabyte.com ;

chinanew.com ;chinese.com;cmmail.com ;cn99.com ;cnuninet.com ;

col.com.cn ;eastday.com ;eazier.com ;eguo.com ;elong.com ;

email.com.cn ;etang.com ;fm365.com ;freemail.soim.com ;chinaice.com;

homeway.com.cn ;inetcall.com ;mail.china.com ;mweb.com.cn;

netbig.com;netease.com;ourchina.net;peoplemail.com.cn;private.21cn.com;

sina.com.cn;sina.com ;sinobnet.com;sohu.com;soim.com;tonghua.com.cn;

vip.sina.com;x263.net;xinhuanet.com ;yahoo.com.cn ;yeah.net ;yesky.com ;

zdl.net ;OTHERS
 
〖71种行业分类〗 
1办公设备（1944599）;2保安（398542）;3保险（193055）;4报社（815591）;5宾馆酒店（113096）;
6材料包装（1516292）;7宗教团体（400095）;;8电台电视台（740562）;9电子;10电子商务;
11房地产;12纺织服装;13妇联残联红十字会;14工会工商联共青团;15工业用品;16公证;17广告;
18航天航空;19会议展览;20机械设备;21计算机互联网;22家电;23家具;24建筑;25交通运输;26教育;
27勘探;28矿产冶金;29旅行社;30农林牧鱼;31企业管理;32汽车;33轻工手工;34清洁物业;35人才科研;
36日用品;37商场;38社会服务;39社会团体;40生物工程;41石油化工;42食品餐饮;42书店;43水电供热;
44塑料塑胶;45通信;46投资;47外贸进出口;48五金;49鞋帽;50信托;51学会;52学校;53烟酒;54医疗保健;
55医院;56仪器仪表;57音像音响;58银行;59饮料;60印刷;61娱乐;62园艺;63造纸;64证券;65制片;
66制造行业;67中介猎头;68资产评估;69出版;70出版社;71建材。 

µÂ¹úÎåÖÖ¹¤Òµ²úÆ·Ñ°ÕÒ¸÷µØ´úÀí

[×æÎÀ]

尊敬的用户，尤其是医院的用户您好！

我们是一家德国高科技企业，正在中国寻找我们产品的地区代理。如果我们的内容不符合您的经营范围，敬请删除为盼！
我司研制的五种产品都具有广泛的使用性和严格的质量保障。我们目前正在寻找各地的代理，与我们一起开发前景广阔的中国市场。这五种产品分别是：

一、	流动水净化工厂    （适用于所有用水单位，节约水资源，达到欧洲环保水平）

二、	柴油发动机节油器  （节油是所有企业降低成本的关键，特别是大型运输机构）

三、    电子防锈系统       （应用范围从家庭到工厂及电厂，甚至污水处理厂都可使用。适用于所有因晶体灰状及矿物淤渣而产生问题的管道。使用于啤酒厂，牛奶厂，食品生产厂，糖厂，造纸厂，工业冷却，各种电厂，污水处理厂等一切大企业。可以安装在聚乙稀管，钢管，铸铁管或铜管上。无需对管道进行改变。无保养及其它费用。运行费用非常低廉。）

四、	动式海水除盐机     （适用于海上作业、海军驻地、海上供给等部门）

五、	便携式风力发电机   （适用于部队野营、野外勘察、探矿、旅游、探险等）

联系电话：010-84857351 或 13910057785 （祖先生）
如果您对该产品没有兴趣，请原谅并删除此文件。
祝好！

±¾ÔÂÌØ»ÝÍƼöÖÇÇ¿ÐÍÖ÷»ú×âÓ㬹ºÍê¼´Ö¹£¡

[sanry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="US-ASCII"; format=flowed, Size: 546 bytes --]

±¾ÔÂÌØ»ÝÍƼöÖÇÇ¿ÐÍÖ÷»ú×âÓ㬹ºÍê¼´Ö¹£¡

Ö÷»ú´æ·ÅÓڹ㶫³¬¼¶Êý¾Ý¸Û£¬2XGE¹âÏËÖ±Á¬ChinaNET¹Ç¸ÉÍø£¬Îȶ¨¡¢
¸ßËÙ£¬ÆÀΪ¹ú¼Ò¼×¼¶»ú·¿£¡

ʱ´´ÍøÂçÊý¾ÝÖÐÐÄ£¨http://idc.001isp.com) ±¾ÔÂÌØ»ÝÍƳö2UÖ÷»ú
p4£¬2G£¬1024Äڴ棬³¬Ç¿¶¯Á¦£¡

ÒÔÏÂΪ·þÎñÆ÷µÄÅäÖÃÇé¿ö£º
P4 2.0A CPU
1024MB DDR
60GB EIDE Drive
DUAL 10/100Mbps BASE-T
2U  ÔÂ×â1890Ôª

±¾ÔÂÖ÷»ú×âÓþªÏ²ÓŻݼ۸ñ£¬¹ºÍê¼´Ö¹£¡
ÏêϸÇë¼ûhttp://idc.001isp.com £¬»¶Ó­×Éѯ¡¢Ñ¡¹º£¡

Ö麣ʱ´´ÍøÂç
QQÔÚÏß×Éѯ£º107929341 108786612
µç»°×Éѯ£º0756--2125563 2125523 2125583
´«Õ棺 0756--2229669
ÓʼþÖ§³Ö£ºsupport@todaynic.com

µÂ¹ú¹ÜµÀ·ÀÐâµç×ÓÒÇ

[×æÎÀ]

[-- Attachment #1: Type: text/plain, Size: 156 bytes --]

尊敬的用户您好！
我们在销售该产品的同时也寻找各地的代理商，如有兴趣请来电来函。
电话：010-84857351
如果您对该产品没有兴趣，请原谅并删除此文件。
祝好！
祖卫

[-- Attachment #2: ³ý¹¸ÒÇÖÐÎĽéÉÜ.doc --]
[-- Type: application/octet-stream, Size: 19456 bytes --]

ÎÒͶ×ÊÄú´´Òµ

[½ú²ý¿çÊ¡ÊÐרҵӪÏúÍø]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

Õæ³ÏºÏ×÷--¹¹½¨Öйú¾­ÏúÉÌͳһ²É¹ºÍø
ÄúºÃ£º
    ÎÒ¹«Ë¾ÒòÒµÎñÐèÒª£¬ÐèÔÚ¸÷µØÉèÁ¢ÒµÎñ°ìÊ´¦£¬ÒÔÌṩ×ʽðµÄ·½Ê½È«Á¦³ÏÕÐ
¸÷µØºÏ×÷»ï°é£¬Óɹ«Ë¾×ܲ¿Í¶×Ê£¬ÄúÀ´¾­Óª£¬¹²Í¬ºÏ×÷£¬Ê¹ÄúÎÞÈκηçÏÕ£¬Ò»Äê
¿ÉʹÄú³ÉΪ°ÙÍò¸»ÎÌ£¡
    ץסÕâÒ»¿Ì£¬ÄúÒ»ÉúµÄÐÒ¸£±ã´Ó´Ë¿ªÊ¼ÁË£¡»¶Ó­Äú½øÈëÎÒÃǵÄÍøÕ¾----Ò»¸ö
Ôì¾Í°ÙÍò¸»Î̵ÄרҵÍøÕ¾£¡ÍøַΪ£ºhttp://www.163btob.net»ò
http://www.163btob.com  ¾ßÌåºÏ×÷ÄÚÈÝÇë½øÈëÍøÕ¾ÖеĸöÈ˺Ï×÷Öв鿴£¡ 
    Èç¹ûÄúÏë´´Òµ£¬»òÕß׬Ǯ£¬ÕâÀï²»ÄÜ´í¹ý£¡Ò»ÉúµÄÐÒ¸£´ÓÕâÀ￪ʼ£¡



³ÏÅÎÄúµÄ»Øº¯£¡Á˽âÎÒÃÇÇë½øÈëÎÒ¹«Ë¾ÍøÕ¾£ºhttp://www.163btob.net    
   
ÊÕµ½ÓʼþºóÇ뼰ʱÁªÏµÎÒ£º
½ú²ý¿çÊ¡ÊÐרҵӪÏúÍø
ÁªÏµÈË£ºÀîÖ÷ÈÎ
µç×ÓÓÊÏ䣺aaaa88@aaaa88.com
          163btob@163btob.com
¹«Ë¾ÍøÖ·£ºhttp://www.163btob.com
          http://www.163btob.net
¡¡¡¡¡¡¡¡¡¡http://www.aaaa88.net 
µç»°£º0536-4212670
´«Õ棺0536-4228120
×£ÎÒÃǺÏ×÷³É¹¦£¡
 
 
˳ףÉÌì÷£¡
 
 
 
 
 
                                                                               
                                            ½ú²ý¿çÊ¡ÊÐרҵӪÏúÍøÒµÎñÈý²¿
                                                      ÀîÖ÷ÈÎ
                                                  2002Äê7ÔÂ17ÈÕ

±±¾©ÊÀ¼ÍÏè´ïÉÌó¹«Ë¾¾­ÓªÏîÄ¿

[www]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="GB2312_CHARSET", Size: 1841 bytes --]

±±¾©ÊÀ¼ÍÏè´ïÉÌó¹«Ë¾¾­ÓªÏîÄ¿
===============================================
×ÔÖú×°»ú£¨DIY£©
C900/128M/40G/17"¼ƒÆ½/32MÏÔ¿¨/52X/56K/µÍÒôÅÚ×éºÏ        4480
C1G/256M/40G/LG17"¼ƒÆ½/62MÏÔ¿¨/52X/56K/µÍÒôÅÚ×éºÏ     4700 
ÈüÑî900/128M/40G/52X/1.44/Éù¿¨ÏÔ¿¨¼¯³É/15"Êý¿Ø           3600 
¶¾Áú900/128M/40G/1.44/52X/Éù¿¨/Íø¿¨/ÏÔ´æ32M/17"/56K      4420
¶¾Áú1G/256M/40G/1.44/52X/Éù¿¨/ÏÔ´æ32M/¶úÂó/17"56K       4680 
P4 1.4G/128M/40G/1.44/52X/17''/32MÏÔ´æ/56K               5280
P41.6G/128M/40G/1.44/52X/17''/32MÏÔ´æ/56K                5480
P41.7G/1.8G/256M/40G/1.44/52X/32MÏÔ´æ/56K               5800/6100
°ì¹«ºÄ²Ä
1.´òÓ¡Ö½    ´òÓ¡Ö½241-1 48Ôª   ´òÓ¡Ö½381-1 68Ôª
2.´«ÕæÖ½   £¨Íõ×Ó£©210¡Á30 8Ôª/¾í ´«ÕæÖ½ 210¡Á30£¨×㣩 13Ôª/¾í 
¶þ¡¢Ä«ºÐÈý¡¢Ä«·Û¡¢Îø¹ÄÈý¡¢Ä«·Û¡¢Îø¹Ä ¡¡
°®ÆÕÉú: 20093 120Ôª 20108 125Ôª 20110 130Ôª 20187 120Ôª 
¸´Ó¡»úºÄ²Ä£º¼ÑÄÜ¡¢Àí¹â¡¢ÏÄÆÕ¡¢¶«Ö¥¡¢Ï£ÀÖµÈ Îø¹ÄÌ¿·Û
»ÝÆÕÄ«ºÐ: 51626A 230Ôª 51625A 230Ôª 51640A 225Ôª 51645A 235Ôª 
¼ÑÄÜÄ«ºÐ: BC-02 150Ôª BC-20 175Ôª BC-3 170Ôª
»ÝÆÕɹ¹Ä: 6L 440Ôª 6L 390Ôª                  
 ÐͺÅÆëÈ«°æÃæÓÐÏÞ²»ÄÜÏêÁÐ 
 Áí£ºÓи÷ÖÖÆ·ÅƵĴ«Õæ»úºÄ²Ä£ºÄ«ºÐ¡¢É«´ø¡¢Îø¹Ä Ë÷Äá3.5ÈíÅÌ¡¡
 Áí£ºÓи÷Öֿ̼Å̺Ð×°É¢×°ÆëÈ«¡£ 
 ÒÔÉϲúÆ·±£Ö¤ÊÇ°Ù·ÖÖ®Ò»°ÙÔ­×°ÕýÆ·£¬¼ÙÒ»·£Ê®Ãâ·ÑËÍ»õ¡£ 
 ÓÉÓÚ°æÃæÓÐÏÞ¸÷ÖֺIJIJ»ÄÜÏêÁУ¬
 Çë´òµç»°´¹Ñ¯»ò·ÃÎÊwww.zgc365.com    www@zgc365.com 
 www.fly-office.com E-Mail:office@fly-office.com
µØÖ·:±±¾©º£µíÇøÖйش山һ½Ö¿Æº£210
µç»°£º(010)62651260   (010)62520740  13611343671
---------------------------------------------------------------
   ±¾ÓʼþÓÉËÑÒ×Ê×´´¡°ÎÞÐèSMTPȺ·¢Æ÷¡±·¢ËÍ£¬ÄÚÈÝÓë±¾¹«Ë¾Î޹ء£

   ×î¼ÑȺ·¢ÖÊÁ¿£ºÆÕͨPCÖÕ¶Ë×Ô½¨SMTP£¬¶Ôÿ¸öÓÊÖ·ÌØ¿ìרµÝ·¢ËÍ¡£

   ×î¼ÑȺ·¢Ëٶȣº¶àÏß³Ìͬ²½¸ßËÙ·¢ËÍ£¬²»´æÔÚÓʼþ´«ÊäÑÓ³ÙÏÖÏó¡£

   ×î¼ÑȺ·¢Ð§¹û£ºÍ»ÆÆÒ»ÇзþÎñÆ÷¹ýÂË£¬²»ÔÙµ£ÐÄ·¢³öÓʼþ»á¶ªÊ§¡£

   Ò»Á÷ÉÌÎñÈí¼þÕ¾µã      http://www.seekeasysoft.net
---------------------------------------------------------------

ÓòÃû×¢²á

[88biz]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 835 bytes --]


×ð¾´µÄÐÂÀÏ¿Í»§£ºÄúºÃ! 
    
    ÏÃÃÅÊÐӯͨԶº½µç×ӿƼ¼ÓÐÏÞ¹«Ë¾http://www.88biz.comÌṩÓòÃû×¢²á£¬
Ö÷»ú×âÓã¬Ö÷»úÍйܵȷþÎñ¡£½üÆÚÄÚ¹«Ë¾²úÆ·´ó´ÙÏúÀñ°üÒ»(200M HTML¿Õ¼ä 
+ 1¸ö¹ú¼ÊÓòÃûÒ»ÄêÖ»Ðè150Ôª)¡£²É¹º¶à¶àÓŻݶà¶à¡£»¶Ó­´ó¼Ò¶©¹º»òÀ´µç
0592-8857840,  ¸ºÔðÈË: СÔø     ×Éѯ¡£

    ÒÔÉÏÖ»ÊÇÁãÊÛ¼Û¸ñ¡£»¶Ó­Ñ¡¹º£¬Ò²»¶Ó­Äú³ÉΪÎÒÃǵĴúÀíÉÌ!
    
    ÎÒÃÇ»¹Óиü¶àµÄÀñ°üºÍÓŻݼ۸ñ£¬ÏêÇéÇë½ø http://www.88biz.com

                                            webmaster@88biz.com

                               ÏÃÃÅÊÐӯͨԶº½µç×ӿƼ¼ÓÐÏÞ¹«Ë¾













































































































































---------------------------------------------------------------
·ÐµãȺ·¢Óʼþ,À´×ÔÈí¼þ¹¤³Ìר¼ÒÍø(http://www.21cmm.com)

½øCMMÍøУ(http://www.21cmm.com)£¬³ÉÏîÄ¿¹ÜÀíר¼Ò

çÄÅÉÓËÁÔØÐÏÄÒÕÇÕÉÌÉÄÒÕÇÁ

[Your friend]

Здравствуйте!

Где искать подругу или друга, мужа или жену, у нас или в США, Канаде и т.д.? Как познакомиться в Инете?

Недавно открылся новый и пока абсолютно бесплатный интернациональный сервер знакомств
http://www.cool-date.net/ . Направление - интернациональные знакомства. Хотя можно найти пару и в своем городе на Родине.
Для желающих найти мужа или жену из "развитых капиталистических" стран, это - настоящий подарок. 

А для желающих найти пару недалеко от дома - "Добро пожаловать на сайт знакомств "LoveCity.Ru"
Если Вам одиноко, скучно, а Вы хотите приятно провести время в хорошей компании, то этот сайт для Вас!
Анекдоты, куча пикантных фото, он-лайн игры, приколы и многое другое...   http://www.lovecity.ru/

Обращайтесь, мы с удовольствием ответим на все Ваши вопросы. 
E-mail: Date@toast.com

Удачи Вам и успехов!
 
Данная рассылка произведена в соответствии с частью 4 статьи 29 Конституции России. 
Ваш адрес был получен из открытых источников и используется для единичной доставки сообщения. В случае нежелания получать коммерческие предложения, ответьте на это письмо с пометкой в Теме "REMOVE". 
Ваш e-mail будет удален из базы.

\

[Timothy Robinson]

unsubscribe linux-kernel tdrobinson@home.com

äÌÑÇÌÁ×ÎÏÇÏÂÕÈÇÁÌÔÅÒÁ

[au_ru]

Для главного бухгалтера.

Приказ о налоговой и учетной политике на 2002 год (в редакции от 1 февраля 2002 года), 
Постатейный комментарий к 25 главе Налогового кодекса РФ Налог на прибыль организаций (в редакции от 28 января 2002 года), 
Новый типовой устав акционерного общества.

Вы имеете возможность получить данные документы бесплатно на электронных носителях, в срок до 15 февраля 2002 года. Комментарий разработан группой методологов крупной аудиторской фирмы.

Заявку направлять E-mail: nal10ru@yahoo.com 


Форма заявки: наименование организации, почтовый адрес, фамилия имя отчество и телефон главного бухгалтера полностью, E-mail, перечень необходимых мне документов.

Заявки с вложенными (прикрепленными) файлами не рассматриваются!!!

Направление документов произойдет в срок с 10 до 15 февраля 2002 года.

(ВНИМАНИЕ: Если Вас не заинтересовало наше предложение приносим свои извинения за предоставленные неудобства.)

Re: ?????????????????????

[Brian]

Can we get something like 
	/[\200-\377]{6}/   (6 upper ACSII characters in a row)
added to the taboo list?

	-- Brian

On Tuesday 05 February 2002 06:48 pm, au_ru@yahoo.com wrote:
> Для главного бухгалтера.
>
> Приказ о налоговой и учетной политике на 2002 год (в редакции от 1
>

Re: ?????????????????????

[Alex Bligh - linux-kernel]

like

Subject: [ANNOUNCE] blah blah?



--On Wednesday, 06 February, 2002 4:21 PM -0500 Brian 
<hiryuu@envisiongames.net> wrote:

> Can we get something like
> 	/[\200-\377]{6}/   (6 upper ACSII characters in a row)
> added to the taboo list?
>
> 	-- Brian
>
> On Tuesday 05 February 2002 06:48 pm, au_ru@yahoo.com wrote:
>> äÌÑ ÇÌÁ×ÎÏÇÏ ÂÕÈÇÁÌÔÅÒÁ.
>>
>> ðÒÉËÁÚ Ï ÎÁÌÏÇÏ×ÏÊ É ÕÞÅÔÎÏÊ ÐÏÌÉÔÉËÅ ÎÁ 2002 ÇÏÄ (× ÒÅÄÁËÃÉÉ ÏÔ 1
>>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



--
Alex Bligh

Re: ?????????????????????

[Roland Dreier]

>>>>> "Alex" == Alex Bligh <- linux-kernel <linux-kernel@alex.org.uk>> writes:

    Alex> like Subject: [ANNOUNCE] blah blah?

    Brian> Can we get something like /[\200-\377]{6}/ (6 upper ACSII
    Brian> characters in a row) added to the taboo list?

Brian's pattern doesn't match upper case letters.  It matches
characters with the most significant bit set.  'A' is 0101 octal,
'N' is 0116 octal, etc. so your example would not trigger the rule.
The idea of the rule is to filter out messages posted in non-Roman
character sets.

Roland

Re: ?????????????????????

[Bruce Harada]

On Wed, 06 Feb 2002 18:42:17 -0500
Brian <hiryuu@envisiongames.net> wrote:

> To my knowledge, there is no English word that would match that regex (or, 
> for that matter, any Romantic or Germanic language word).  It's the most 
> effective tool I've seen against Asian spam (like the one I replied to).


Just to set the record straight, that was RUSSIAN spam, not Asian spam...
(The regex should still be effective, of course.)

Re: ?????????????????????

[Pavel Machek]

Hi!

> like
> 
> Subject: [ANNOUNCE] blah blah?

He talked about characters >128.
							Pavel

> --On Wednesday, 06 February, 2002 4:21 PM -0500 Brian 
> <hiryuu@envisiongames.net> wrote:
> 
> >Can we get something like
> >	/[\200-\377]{6}/   (6 upper ACSII characters in a row)
> >added to the taboo list?
> >
> >	-- Brian
> >
> >On Tuesday 05 February 2002 06:48 pm, au_ru@yahoo.com wrote:
> >>ä?? Ç?Á×Î?Ç? Â??ÇÁ?Ô??Á.
> >>
> >>??ÉËÁÚ ? ÎÁ??Ç?×?? É ???ÔÎ?? ???ÉÔÉË? ÎÁ 2002 Ç?Ä (× ??ÄÁË?ÉÉ ?Ô 1

-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: ?????????????????????

[Brian]

On Wednesday 06 February 2002 05:31 pm, Alex Bligh - linux-kernel wrote:
> like
>
> Subject: [ANNOUNCE] blah blah?
>

That would be upperCASE ACSII.
I mean 6 bytes, each higher than 127, in a row.

To my knowledge, there is no English word that would match that regex (or, 
for that matter, any Romantic or Germanic language word).  It's the most 
effective tool I've seen against Asian spam (like the one I replied to).

> --On Wednesday, 06 February, 2002 4:21 PM -0500 Brian
>
> <hiryuu@envisiongames.net> wrote:
> > Can we get something like
> > 	/[\200-\377]{6}/   (6 upper ACSII characters in a row)
> > added to the taboo list?
> >
> > 	-- Brian
>

Re: ?????????????????????

[David S. Miller]

   From: Bruce Harada <bruce@ask.ne.jp>
   Date: Thu, 7 Feb 2002 20:12:43 +0900

   On Wed, 06 Feb 2002 18:42:17 -0500
   Brian <hiryuu@envisiongames.net> wrote:
   
   > To my knowledge, there is no English word that would match that regex (or, 
   > for that matter, any Romantic or Germanic language word).  It's the most 
   > effective tool I've seen against Asian spam (like the one I replied to).
   
   Just to set the record straight, that was RUSSIAN spam, not Asian spam...
   (The regex should still be effective, of course.)

Except that it would block out uuencoded patches in postings perhaps?
Or is it just supposed to be matched in the Subject field or other
parts of the headers?

Re: ?????????????????????

[Jesse Pollard]

---------  Received message begins Here  ---------

> 
>    From: Bruce Harada <bruce@ask.ne.jp>
>    Date: Thu, 7 Feb 2002 20:12:43 +0900
> 
>    On Wed, 06 Feb 2002 18:42:17 -0500
>    Brian <hiryuu@envisiongames.net> wrote:
>    
>    > To my knowledge, there is no English word that would match that regex (or, 
>    > for that matter, any Romantic or Germanic language word).  It's the most 
>    > effective tool I've seen against Asian spam (like the one I replied to).
>    
>    Just to set the record straight, that was RUSSIAN spam, not Asian spam...
>    (The regex should still be effective, of course.)
> 
> Except that it would block out uuencoded patches in postings perhaps?
> Or is it just supposed to be matched in the Subject field or other
> parts of the headers?

I thought uuencode format required 7bit print ascii output, which would
never match that pattern.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: ?????????????????????

[Horst von Brand]

"David S. Miller" <davem@redhat.com> said:

[...]

> Except that it would block out uuencoded patches in postings perhaps?

Since when does uuencoding generate high chars? It is supposed to give only
"safe" chars (i.e., in ASCII and EBCDIC).
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: ?????????????????????

[Pete Cervasio]

At 03:44 AM 2/7/2002 -0800, David S. Miller <davem@redhat.com> wrote:
>   From: Bruce Harada <bruce@ask.ne.jp>
>   Date: Thu, 7 Feb 2002 20:12:43 +0900
>
>   On Wed, 06 Feb 2002 18:42:17 -0500
>   Brian <hiryuu@envisiongames.net> wrote:
>   
>   > To my knowledge, there is no English word that would match that regex
(or, 
>   > for that matter, any Romantic or Germanic language word).  It's the
most 
>   > effective tool I've seen against Asian spam (like the one I replied to).
>   
>   Just to set the record straight, that was RUSSIAN spam, not Asian spam...
>   (The regex should still be effective, of course.)
>
>Except that it would block out uuencoded patches in postings perhaps?
>Or is it just supposed to be matched in the Subject field or other
>parts of the headers?

Um... no, it's just supposed to look at several characters in a row that
have the high bit set.  Have another cup of coffee and think about what
happens to attachments after they're uuencoded.  :)

Best regards,
Pete C.


=====================================================================
         $5                          $75
"this is your brain... this is your brain on ebay."
                                     (Pat McNeil on comp.sys.tandy)

Re: ?????????????????????

[Martin Dalecki]

Brian wrote:

>On Wednesday 06 February 2002 05:31 pm, Alex Bligh - linux-kernel wrote:
>
>>like
>>
>>Subject: [ANNOUNCE] blah blah?
>>
>
>That would be upperCASE ACSII.
>I mean 6 bytes, each higher than 127, in a row.
>
>To my knowledge, there is no English word that would match that regex (or, 
>for that matter, any Romantic or Germanic language word).  It's the most 
>effective tool I've seen against Asian spam (like the one I replied to).
>
Just for the record... the spam you replayed to was in russian.

Re: ?????????????????????

[Oliver M . Bolzer]

On Wed, Feb 06, 2002 at 04:21:50PM -0500, Brian <hiryuu@envisiongames.net> wrote...
> Can we get something like 
> 	/[\200-\377]{6}/   (6 upper ACSII characters in a row)
> added to the taboo list?

If you mean to match a header like Subject: , don't forget to
decode them first. Usually, headers containing these are MIME-encoded.

-- 
	Oliver M. Bolzer
	oliver@gol.com

GPG (PGP) Fingerprint = 621B 52F6 2AC1 36DB 8761  018F 8786 87AD EF50 D1FF

ÔÛÃǵļÒ

[webmaster]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

    茫茫的网络，如同广阔的大海。我们像一叶小舟在海面上漂泊不定，我们一直在寻找，寻找一个港湾，一个心灵停靠的地方。
    中华恋人网虚拟社区是一个可以让您心灵停靠的地方，欢迎您来这里，把您的心情，您的心事与我们一起分享，这里没有专家，只有真诚的朋友，大家一起来解决棘手的问题，我们充满爱，等待您的到来。
都是感情至上的动物，我们经常被感情所左右。这里是个感情交流的地方，在这里把您的心扉敞开，您会发现这里充满了感情，友情，爱请，亲情，还有人世间所有的情感。
    给我一点爱，我会站起来。

     欢迎访问中华恋人社区:  http://www.gujun.net/bbs



                        



---------------------------------------------------------------
该邮件由《金锋邮件群发 2.0》发送，邮件内容与软件作者无关 
---------------------------------------------------------------
金锋软件，值得信赖的软件 http://www.jinfengnet.com




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