* !
@ 2015-08-01 12:29 Rita
0 siblings, 0 replies; 47+ messages in thread
From: Rita @ 2015-08-01 12:29 UTC (permalink / raw)
When and What time can i Call you? Respond ASAP
^ permalink raw reply [flat|nested] 47+ messages in thread
* [PATCH v3 2/5] w1_therm: adding sysfs entry to check device power
@ 2020-04-29 13:32 Akira Shimahara
2020-04-29 13:46 ` Greg KH
0 siblings, 1 reply; 47+ messages in thread
From: Akira Shimahara @ 2020-04-29 13:32 UTC (permalink / raw)
To: greg; +Cc: zbr, linux-kernel, 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
^ permalink raw reply related [flat|nested] 47+ messages in thread
* Re: [PATCH v3 2/5] w1_therm: adding sysfs entry to check device power
2020-04-29 13:32 [PATCH v3 2/5] w1_therm: adding sysfs entry to check device power Akira Shimahara
@ 2020-04-29 13:46 ` Greg KH
2020-04-29 13:57 ` _ Akira shimahara
0 siblings, 1 reply; 47+ messages in thread
From: Greg KH @ 2020-04-29 13:46 UTC (permalink / raw)
To: Akira Shimahara; +Cc: zbr, linux-kernel
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* _
2020-04-29 13:46 ` Greg KH
@ 2020-04-29 13:57 ` Akira shimahara
0 siblings, 0 replies; 47+ messages in thread
From: Akira shimahara @ 2020-04-29 13:57 UTC (permalink / raw)
To: Greg KH; +Cc: zbr, linux-kernel
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* [PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump
@ 2019-08-30 7:11 Chen Zhou
2019-12-18 2:07 ` Chen Zhou
0 siblings, 1 reply; 47+ messages in thread
From: Chen Zhou @ 2019-08-30 7:11 UTC (permalink / raw)
To: tglx, mingo, catalin.marinas, will, james.morse, dyoung, bhsharma
Cc: horms, guohanjun, linux-arm-kernel, linux-kernel, kexec, 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump
2019-08-30 7:11 [PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump Chen Zhou
@ 2019-12-18 2:07 ` Chen Zhou
2019-12-18 17:18 ` John Donnelly
0 siblings, 1 reply; 47+ messages in thread
From: Chen Zhou @ 2019-12-18 2:07 UTC (permalink / raw)
To: tglx, mingo, catalin.marinas, will, james.morse, dyoung, bhsharma
Cc: horms, guohanjun, linux-arm-kernel, linux-kernel, kexec
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(-)
>
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump
2019-12-18 2:07 ` Chen Zhou
@ 2019-12-18 17:18 ` John Donnelly
2019-12-19 2:56 ` Chen Zhou
0 siblings, 1 reply; 47+ messages in thread
From: John Donnelly @ 2019-12-18 17:18 UTC (permalink / raw)
To: Chen Zhou
Cc: tglx, mingo, catalin.marinas, will, james.morse, dyoung,
bhsharma, horms, kexec, linux-kernel, linux-arm-kernel,
guohanjun
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=
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump
2019-12-18 17:18 ` John Donnelly
@ 2019-12-19 2:56 ` Chen Zhou
2019-12-19 18:33 ` ` John Donnelly
0 siblings, 1 reply; 47+ messages in thread
From: Chen Zhou @ 2019-12-19 2:56 UTC (permalink / raw)
To: John Donnelly
Cc: tglx, mingo, catalin.marinas, will, james.morse, dyoung,
bhsharma, horms, kexec, linux-kernel, linux-arm-kernel,
guohanjun
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=
>
>
> .
>
^ permalink raw reply [flat|nested] 47+ messages in thread
* `
2019-12-19 2:56 ` Chen Zhou
@ 2019-12-19 18:33 ` John Donnelly
2019-12-20 1:44 ` ` Chen Zhou
0 siblings, 1 reply; 47+ messages in thread
From: John Donnelly @ 2019-12-19 18:33 UTC (permalink / raw)
To: Chen Zhou
Cc: tglx, mingo, catalin.marinas, will, james.morse, dyoung,
bhsharma, horms, kexec, linux-kernel, linux-arm-kernel,
guohanjun
> 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=
>>
>>
>> .
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: `
2019-12-19 18:33 ` ` John Donnelly
@ 2019-12-20 1:44 ` Chen Zhou
0 siblings, 0 replies; 47+ messages in thread
From: Chen Zhou @ 2019-12-20 1:44 UTC (permalink / raw)
To: John Donnelly
Cc: tglx, mingo, catalin.marinas, will, james.morse, dyoung,
bhsharma, horms, kexec, linux-kernel, linux-arm-kernel,
guohanjun
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=
>>>
>>>
>>> .
>
>
> .
>
^ permalink raw reply [flat|nested] 47+ messages in thread
* (no subject)
@ 2016-11-15 20:29 Christoph Lameter
2016-11-15 21:58 ` ??? Steven Rostedt
0 siblings, 1 reply; 47+ messages in thread
From: Christoph Lameter @ 2016-11-15 20:29 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Daniel Vacek, Daniel Bristot de Oliveira, Tommaso Cucinotta,
LKML, linux-rt-users, Steven Rostedt, Ingo Molnar
> > 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ???
2016-11-15 20:29 Christoph Lameter
@ 2016-11-15 21:58 ` Steven Rostedt
0 siblings, 0 replies; 47+ messages in thread
From: Steven Rostedt @ 2016-11-15 21:58 UTC (permalink / raw)
To: Christoph Lameter
Cc: Peter Zijlstra, Daniel Vacek, Daniel Bristot de Oliveira,
Tommaso Cucinotta, LKML, linux-rt-users, Ingo Molnar
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* (no subject)
@ 2016-11-11 3:38 Chunyan Zhang
2016-11-11 16:01 ` ?? Steven Rostedt
0 siblings, 1 reply; 47+ messages in thread
From: Chunyan Zhang @ 2016-11-11 3:38 UTC (permalink / raw)
To: Steven Rostedt
Cc: Mathieu Poirier, Alexander Shishkin, mingo, Mike Leach,
Tor Jeremiassen, philippe.langlais, Nicolas GUION, Felipe Balbi,
Lyra Zhang, linux-kernel, linux-arm-kernel
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
>>
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ??
2016-11-11 3:38 Chunyan Zhang
@ 2016-11-11 16:01 ` Steven Rostedt
0 siblings, 0 replies; 47+ messages in thread
From: Steven Rostedt @ 2016-11-11 16:01 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Mathieu Poirier, Alexander Shishkin, mingo, Mike Leach,
Tor Jeremiassen, philippe.langlais, Nicolas GUION, Felipe Balbi,
Lyra Zhang, linux-kernel, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 47+ messages in thread
[parent not found: <CAHjEeniVr6YmfLojEJutcEqk1pX0jTOvFvtJs4WvxQC2bJ4C3g@mail.gmail.com>]
[parent not found: <CAP9ngMJVJuqWMsfRNTaVQk_2690m1Vic60SRXOb8dzg9i=KEMA@mail.gmail.com>]
* !
@ 2015-09-29 15:58 Kathrine
0 siblings, 0 replies; 47+ messages in thread
From: Kathrine @ 2015-09-29 15:58 UTC (permalink / raw)
Did you get my previous mail? When and what time can i call?
^ permalink raw reply [flat|nested] 47+ messages in thread
* !
@ 2015-08-01 8:50 Rita
0 siblings, 0 replies; 47+ messages in thread
From: Rita @ 2015-08-01 8:50 UTC (permalink / raw)
When and What time can i Call you? Respond ASAP
^ permalink raw reply [flat|nested] 47+ messages in thread
* !
@ 2013-10-19 7:26 Ana Flavia Maria
0 siblings, 0 replies; 47+ messages in thread
From: Ana Flavia Maria @ 2013-10-19 7:26 UTC (permalink / raw)
--
Loan at 3% interest rate Loan offer.. AreYou Interested>?
^ permalink raw reply [flat|nested] 47+ messages in thread
* $
@ 2013-09-25 12:01 FBI
0 siblings, 0 replies; 47+ messages in thread
From: FBI @ 2013-09-25 12:01 UTC (permalink / raw)
This goes out to you who had lost your money to scammers,email back to us for your lost money now....
^ permalink raw reply [flat|nested] 47+ messages in thread
* !
@ 2012-01-01 12:45 FBI
0 siblings, 0 replies; 47+ messages in thread
From: FBI @ 2012-01-01 12:45 UTC (permalink / raw)
I am here to see that you get all your money that you lost to scammers,reply back!
^ permalink raw reply [flat|nested] 47+ messages in thread
* $
@ 2011-01-03 13:45 Sgt Moore Paul
0 siblings, 0 replies; 47+ messages in thread
From: Sgt Moore Paul @ 2011-01-03 13:45 UTC (permalink / raw)
I have a monetary deal for you.reply using sgtp_moore@tranphu.com,Sgt Paul.
^ permalink raw reply [flat|nested] 47+ messages in thread
* ,
@ 2010-11-16 13:59 Ming-Yang Lee
0 siblings, 0 replies; 47+ messages in thread
From: Ming-Yang Lee @ 2010-11-16 13:59 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* ,
@ 2010-07-27 7:46 john erchart
0 siblings, 0 replies; 47+ messages in thread
From: john erchart @ 2010-07-27 7:46 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* ,
@ 2010-07-24 7:48 Mr.COOK ADAMS
0 siblings, 0 replies; 47+ messages in thread
From: Mr.COOK ADAMS @ 2010-07-24 7:48 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* ,
@ 2010-06-27 18:43 Mr.COOK ADAMS
0 siblings, 0 replies; 47+ messages in thread
From: Mr.COOK ADAMS @ 2010-06-27 18:43 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* ,
@ 2010-06-27 18:01 Mr.COOK ADAMS
0 siblings, 0 replies; 47+ messages in thread
From: Mr.COOK ADAMS @ 2010-06-27 18:01 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* ,
@ 2010-06-27 11:02 DHL UNIT
0 siblings, 0 replies; 47+ messages in thread
From: DHL UNIT @ 2010-06-27 11:02 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* ,
@ 2010-06-16 20:30 SBECKFORD Financial Loan Company
0 siblings, 0 replies; 47+ messages in thread
From: SBECKFORD Financial Loan Company @ 2010-06-16 20:30 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* ,
@ 2010-06-16 18:57 SBECKFORD Financial Loan Company
0 siblings, 0 replies; 47+ messages in thread
From: SBECKFORD Financial Loan Company @ 2010-06-16 18:57 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* ,
@ 2010-06-12 9:59 Mr.COOK ADAMS
0 siblings, 0 replies; 47+ messages in thread
From: Mr.COOK ADAMS @ 2010-06-12 9:59 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* ,
@ 2010-02-22 20:25 JOSE LOANS
0 siblings, 0 replies; 47+ messages in thread
From: JOSE LOANS @ 2010-02-22 20:25 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* ,
@ 2010-02-22 18:39 JOSE LOANS
0 siblings, 0 replies; 47+ messages in thread
From: JOSE LOANS @ 2010-02-22 18:39 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* ,
@ 2010-02-22 18:17 JOSE LOANS
0 siblings, 0 replies; 47+ messages in thread
From: JOSE LOANS @ 2010-02-22 18:17 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* ,
@ 2010-02-22 17:53 JOSE LOANS
0 siblings, 0 replies; 47+ messages in thread
From: JOSE LOANS @ 2010-02-22 17:53 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [PATCH] Move memory controller allocations to their own slabs
@ 2008-03-11 4:31 Balbir Singh
2008-03-11 5:00 ` + KOSAKI Motohiro
0 siblings, 1 reply; 47+ messages in thread
From: Balbir Singh @ 2008-03-11 4:31 UTC (permalink / raw)
To: Paul Menage, Andrew Morton, Pavel Emelianov
Cc: Hugh Dickins, Sudhir Kumar, YAMAMOTO Takashi, lizf, linux-kernel,
taka, linux-mm, David Rientjes, Balbir Singh, KAMEZAWA Hiroyuki
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* +
2008-03-11 4:31 [PATCH] Move memory controller allocations to their own slabs Balbir Singh
@ 2008-03-11 5:00 ` KOSAKI Motohiro
2008-03-11 5:07 ` + Balbir Singh
0 siblings, 1 reply; 47+ messages in thread
From: KOSAKI Motohiro @ 2008-03-11 5:00 UTC (permalink / raw)
To: Balbir Singh
Cc: kosaki.motohiro, Paul Menage, Andrew Morton, Pavel Emelianov,
Hugh Dickins, Sudhir Kumar, YAMAMOTO Takashi, lizf, linux-kernel,
taka, linux-mm, David Rientjes, KAMEZAWA Hiroyuki
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(-)
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: +
2008-03-11 5:00 ` + KOSAKI Motohiro
@ 2008-03-11 5:07 ` Balbir Singh
0 siblings, 0 replies; 47+ messages in thread
From: Balbir Singh @ 2008-03-11 5:07 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Paul Menage, Andrew Morton, Pavel Emelianov, Hugh Dickins,
Sudhir Kumar, YAMAMOTO Takashi, lizf, linux-kernel, taka,
linux-mm, David Rientjes, KAMEZAWA Hiroyuki
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* ???
@ 2004-09-30 2:19 Charlie LaMothe
0 siblings, 0 replies; 47+ messages in thread
From: Charlie LaMothe @ 2004-09-30 2:19 UTC (permalink / raw)
To: linux-kernel
How do I burn a CD on linux?
Also, how do I set the root WWW directory on apache?
Thanks
^ permalink raw reply [flat|nested] 47+ messages in thread
* :(((((((
@ 2003-04-25 15:48 Balram Adlakha
2003-04-25 15:59 ` :((((((( CaT
2003-04-25 16:08 ` :((((((( Valdis.Kletnieks
0 siblings, 2 replies; 47+ messages in thread
From: Balram Adlakha @ 2003-04-25 15:48 UTC (permalink / raw)
To: linux-kernel
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?
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: :(((((((
2003-04-25 15:48 :((((((( Balram Adlakha
@ 2003-04-25 15:59 ` CaT
2003-04-25 16:08 ` :((((((( Valdis.Kletnieks
1 sibling, 0 replies; 47+ messages in thread
From: CaT @ 2003-04-25 15:59 UTC (permalink / raw)
To: Balram Adlakha; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: :(((((((
2003-04-25 15:48 :((((((( Balram Adlakha
2003-04-25 15:59 ` :((((((( CaT
@ 2003-04-25 16:08 ` Valdis.Kletnieks
2003-04-25 18:07 ` :((((((( Benjamin Herrenschmidt
1 sibling, 1 reply; 47+ messages in thread
From: Valdis.Kletnieks @ 2003-04-25 16:08 UTC (permalink / raw)
To: Balram Adlakha; +Cc: linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: :(((((((
2003-04-25 16:08 ` :((((((( Valdis.Kletnieks
@ 2003-04-25 18:07 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 47+ messages in thread
From: Benjamin Herrenschmidt @ 2003-04-25 18:07 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Balram Adlakha, linux-kernel mailing list
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* \
@ 2002-02-17 2:11 Timothy Robinson
0 siblings, 0 replies; 47+ messages in thread
From: Timothy Robinson @ 2002-02-17 2:11 UTC (permalink / raw)
To: linux-kernel
unsubscribe linux-kernel tdrobinson@home.com
^ permalink raw reply [flat|nested] 47+ messages in thread
* äÌÑÇÌÁ×ÎÏÇÏÂÕÈÇÁÌÔÅÒÁ
@ 2002-02-05 23:48 au_ru
2002-02-06 21:21 ` ????????????????????? Brian
0 siblings, 1 reply; 47+ messages in thread
From: au_ru @ 2002-02-05 23:48 UTC (permalink / raw)
Для главного бухгалтера.
Приказ о налоговой и учетной политике на 2002 год (в редакции от 1 февраля 2002 года),
Постатейный комментарий к 25 главе Налогового кодекса РФ Налог на прибыль организаций (в редакции от 28 января 2002 года),
Новый типовой устав акционерного общества.
Вы имеете возможность получить данные документы бесплатно на электронных носителях, в срок до 15 февраля 2002 года. Комментарий разработан группой методологов крупной аудиторской фирмы.
Заявку направлять E-mail: nal10ru@yahoo.com
Форма заявки: наименование организации, почтовый адрес, фамилия имя отчество и телефон главного бухгалтера полностью, E-mail, перечень необходимых мне документов.
Заявки с вложенными (прикрепленными) файлами не рассматриваются!!!
Направление документов произойдет в срок с 10 до 15 февраля 2002 года.
(ВНИМАНИЕ: Если Вас не заинтересовало наше предложение приносим свои извинения за предоставленные неудобства.)
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ?????????????????????
2002-02-05 23:48 äÌÑÇÌÁ×ÎÏÇÏÂÕÈÇÁÌÔÅÒÁ au_ru
@ 2002-02-06 21:21 ` Brian
2002-02-06 22:31 ` ????????????????????? Alex Bligh - linux-kernel
` (2 more replies)
0 siblings, 3 replies; 47+ messages in thread
From: Brian @ 2002-02-06 21:21 UTC (permalink / raw)
To: linux-kernel
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
>
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ?????????????????????
2002-02-06 21:21 ` ????????????????????? Brian
@ 2002-02-06 22:31 ` Alex Bligh - linux-kernel
2002-02-06 22:46 ` ????????????????????? Roland Dreier
` (2 more replies)
2002-02-06 23:42 ` ????????????????????? Brian
2002-02-07 12:47 ` ????????????????????? Oliver M . Bolzer
2 siblings, 3 replies; 47+ messages in thread
From: Alex Bligh - linux-kernel @ 2002-02-06 22:31 UTC (permalink / raw)
To: Brian, linux-kernel; +Cc: 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ?????????????????????
2002-02-06 22:31 ` ????????????????????? Alex Bligh - linux-kernel
@ 2002-02-06 22:46 ` Roland Dreier
2002-02-07 11:12 ` ????????????????????? Bruce Harada
2002-02-07 19:59 ` ????????????????????? Pavel Machek
2 siblings, 0 replies; 47+ messages in thread
From: Roland Dreier @ 2002-02-06 22:46 UTC (permalink / raw)
To: Alex Bligh - linux-kernel; +Cc: linux-kernel
>>>>> "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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ?????????????????????
2002-02-06 22:31 ` ????????????????????? Alex Bligh - linux-kernel
2002-02-06 22:46 ` ????????????????????? Roland Dreier
@ 2002-02-07 11:12 ` Bruce Harada
2002-02-07 19:59 ` ????????????????????? Pavel Machek
2 siblings, 0 replies; 47+ messages in thread
From: Bruce Harada @ 2002-02-07 11:12 UTC (permalink / raw)
To: Brian; +Cc: linux-kernel
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.)
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ?????????????????????
2002-02-06 22:31 ` ????????????????????? Alex Bligh - linux-kernel
2002-02-06 22:46 ` ????????????????????? Roland Dreier
2002-02-07 11:12 ` ????????????????????? Bruce Harada
@ 2002-02-07 19:59 ` Pavel Machek
2 siblings, 0 replies; 47+ messages in thread
From: Pavel Machek @ 2002-02-07 19:59 UTC (permalink / raw)
To: Alex Bligh - linux-kernel; +Cc: Brian, linux-kernel
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ?????????????????????
2002-02-06 21:21 ` ????????????????????? Brian
2002-02-06 22:31 ` ????????????????????? Alex Bligh - linux-kernel
@ 2002-02-06 23:42 ` Brian
2002-02-07 11:44 ` ????????????????????? David S. Miller
` (2 more replies)
2002-02-07 12:47 ` ????????????????????? Oliver M . Bolzer
2 siblings, 3 replies; 47+ messages in thread
From: Brian @ 2002-02-06 23:42 UTC (permalink / raw)
To: Alex Bligh - linux-kernel, linux-kernel
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
>
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ?????????????????????
2002-02-06 23:42 ` ????????????????????? Brian
@ 2002-02-07 11:44 ` David S. Miller
2002-02-07 20:01 ` ????????????????????? Jesse Pollard
2002-02-08 9:57 ` ????????????????????? Horst von Brand
2002-02-07 12:12 ` ????????????????????? Pete Cervasio
2002-02-08 12:40 ` ????????????????????? Martin Dalecki
2 siblings, 2 replies; 47+ messages in thread
From: David S. Miller @ 2002-02-07 11:44 UTC (permalink / raw)
To: bruce; +Cc: hiryuu, linux-kernel
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?
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ?????????????????????
2002-02-07 11:44 ` ????????????????????? David S. Miller
@ 2002-02-07 20:01 ` Jesse Pollard
2002-02-08 9:57 ` ????????????????????? Horst von Brand
1 sibling, 0 replies; 47+ messages in thread
From: Jesse Pollard @ 2002-02-07 20:01 UTC (permalink / raw)
To: davem, bruce; +Cc: hiryuu, linux-kernel
--------- 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ?????????????????????
2002-02-07 11:44 ` ????????????????????? David S. Miller
2002-02-07 20:01 ` ????????????????????? Jesse Pollard
@ 2002-02-08 9:57 ` Horst von Brand
1 sibling, 0 replies; 47+ messages in thread
From: Horst von Brand @ 2002-02-08 9:57 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel
"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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ?????????????????????
2002-02-06 23:42 ` ????????????????????? Brian
2002-02-07 11:44 ` ????????????????????? David S. Miller
@ 2002-02-07 12:12 ` Pete Cervasio
2002-02-08 12:40 ` ????????????????????? Martin Dalecki
2 siblings, 0 replies; 47+ messages in thread
From: Pete Cervasio @ 2002-02-07 12:12 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel
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)
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ?????????????????????
2002-02-06 23:42 ` ????????????????????? Brian
2002-02-07 11:44 ` ????????????????????? David S. Miller
2002-02-07 12:12 ` ????????????????????? Pete Cervasio
@ 2002-02-08 12:40 ` Martin Dalecki
2 siblings, 0 replies; 47+ messages in thread
From: Martin Dalecki @ 2002-02-08 12:40 UTC (permalink / raw)
To: Brian; +Cc: Alex Bligh - linux-kernel, linux-kernel
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ?????????????????????
2002-02-06 21:21 ` ????????????????????? Brian
2002-02-06 22:31 ` ????????????????????? Alex Bligh - linux-kernel
2002-02-06 23:42 ` ????????????????????? Brian
@ 2002-02-07 12:47 ` Oliver M . Bolzer
2 siblings, 0 replies; 47+ messages in thread
From: Oliver M . Bolzer @ 2002-02-07 12:47 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2020-04-29 13:57 UTC | newest]
Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-01 12:29 ! Rita
-- strict thread matches above, loose matches on Subject: below --
2020-04-29 13:32 [PATCH v3 2/5] w1_therm: adding sysfs entry to check device power Akira Shimahara
2020-04-29 13:46 ` Greg KH
2020-04-29 13:57 ` _ Akira shimahara
2019-08-30 7:11 [PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump Chen Zhou
2019-12-18 2:07 ` Chen Zhou
2019-12-18 17:18 ` John Donnelly
2019-12-19 2:56 ` Chen Zhou
2019-12-19 18:33 ` ` John Donnelly
2019-12-20 1:44 ` ` Chen Zhou
2016-11-15 20:29 Christoph Lameter
2016-11-15 21:58 ` ??? Steven Rostedt
2016-11-11 3:38 Chunyan Zhang
2016-11-11 16:01 ` ?? Steven Rostedt
[not found] <CAHjEeniVr6YmfLojEJutcEqk1pX0jTOvFvtJs4WvxQC2bJ4C3g@mail.gmail.com>
2016-06-01 1:13 ` ###$$$@# iutititbpigi
[not found] <CAP9ngMJVJuqWMsfRNTaVQk_2690m1Vic60SRXOb8dzg9i=KEMA@mail.gmail.com>
2015-10-27 20:39 ` ? Amall
2015-09-29 15:58 ! Kathrine
2015-08-01 8:50 ! Rita
2013-10-19 7:26 ! Ana Flavia Maria
2013-09-25 12:01 $ FBI
2012-01-01 12:45 ! FBI
2011-01-03 13:45 $ Sgt Moore Paul
2010-11-16 13:59 , Ming-Yang Lee
2010-07-27 7:46 , john erchart
2010-07-24 7:48 , Mr.COOK ADAMS
2010-06-27 18:43 , Mr.COOK ADAMS
2010-06-27 18:01 , Mr.COOK ADAMS
2010-06-27 11:02 , DHL UNIT
2010-06-16 20:30 , SBECKFORD Financial Loan Company
2010-06-16 18:57 , SBECKFORD Financial Loan Company
2010-06-12 9:59 , Mr.COOK ADAMS
2010-02-22 20:25 , JOSE LOANS
2010-02-22 18:39 , JOSE LOANS
2010-02-22 18:17 , JOSE LOANS
2010-02-22 17:53 , JOSE LOANS
2008-03-11 4:31 [PATCH] Move memory controller allocations to their own slabs Balbir Singh
2008-03-11 5:00 ` + KOSAKI Motohiro
2008-03-11 5:07 ` + Balbir Singh
2004-09-30 2:19 ??? Charlie LaMothe
2003-04-25 15:48 :((((((( Balram Adlakha
2003-04-25 15:59 ` :((((((( CaT
2003-04-25 16:08 ` :((((((( Valdis.Kletnieks
2003-04-25 18:07 ` :((((((( Benjamin Herrenschmidt
2002-02-17 2:11 \ Timothy Robinson
2002-02-05 23:48 äÌÑÇÌÁ×ÎÏÇÏÂÕÈÇÁÌÔÅÒÁ au_ru
2002-02-06 21:21 ` ????????????????????? Brian
2002-02-06 22:31 ` ????????????????????? Alex Bligh - linux-kernel
2002-02-06 22:46 ` ????????????????????? Roland Dreier
2002-02-07 11:12 ` ????????????????????? Bruce Harada
2002-02-07 19:59 ` ????????????????????? Pavel Machek
2002-02-06 23:42 ` ????????????????????? Brian
2002-02-07 11:44 ` ????????????????????? David S. Miller
2002-02-07 20:01 ` ????????????????????? Jesse Pollard
2002-02-08 9:57 ` ????????????????????? Horst von Brand
2002-02-07 12:12 ` ????????????????????? Pete Cervasio
2002-02-08 12:40 ` ????????????????????? Martin Dalecki
2002-02-07 12:47 ` ????????????????????? Oliver M . Bolzer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).