s even if mount shouldn't? Or am I missing
a neater solution?
Rgds
Anthony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
>
> In other words the latter behaviour looks like a bug in the automounter,
> and the former is a feature which could be added but isn't needed for
> your application.
Okay! Well, the following I think fixes everything for me, as a
small tweak to autofs-4.0.0pre9.
Thanks
Anthony
to confuse a lot more
> users than it would clarify.
I'll bring you a nice bottle of scotch at the next KVM Forum if you can
find me one user that can accurately describe what steal time is.
The semantics are so incredibly subtle that I have a hard time believing
anyone actually understand
due to overcommit (with the reminder being unallocated
> time). The guest could then present it any way it wanted to.
What I had previously suggested what splitting entitlement loss out of
steal time and reporting it as a separate metric (but not reporting a
fixed notion of entitlement).
You'
;t matter when it doesn't agree
with all of the existing implementations.
Users use implementations, not specifications. The specification really
ought to be changed here.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
proposing.
In this case, we should simply say that with the feature bit, the vnet
header can be in the same element as the data but not allow the header
to be spread across multiple elements.
Regards,
Anthony Liguori
>
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kc
Rusty Russell writes:
> Anthony Liguori writes:
>> Rusty Russell writes:
>>
>>> "Michael S. Tsirkin" writes:
>>>
>>>> Thinking about Sasha's patches, we can reduce ring usage
>>>> for virtio net small packets dramatically
This maps really nicely to non-PCI transports too. But extending the
PCI config space (especially dealing with capability allocation) is
pretty gnarly and there isn't an obvious equivalent outside of PCI.
There are very devices that we emulate today that make use of extended
PCI device
tex as well.
It is obvious that no one other than myself tried it with a real device.
I did, but only for the purposes of an experiment and demonstration.
But even if this situation will never ever happen with a real device, it
is a bug and therefore should be fixed.
Signed-off-by: Anthony Ol
New API regmap_multi_write() to support a single I2C transfer consisting
of writes to multiple non-sequential registers for those I2C clients that
implement the alternative non-standard MULTIWRITE block write mode.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
This patch is
Greg KH writes:
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
My checklist against stable_kernel_rules.txt is below.
I could only find two reasons why you are saying thi
From: Anthony Foiani
Having recently received a formletter rejection on a stable patch, I
found it difficult to determine exactly which guideline I had missed.
Numbering the guidelines will allow the stable maintainer to quickly
and easily indicate which guidelines have not been followed.
The
Greg --
Thanks for the very quick response.
Greg KH writes:
> This is an obvious one, it needs to be upstream first.
>
> Or if not, a whole lot of explaination saying that you know it
> isn't, and why it isn't, and why it isn't applicable there,
I thought that I did provide exactly this inform
Greg KH writes:
> Is this really needed? For the large majority of the stable
> patches, specifically enumerating this isn't a big deal, it's a tiny
> patch, and if you think I'll remember to tell you which specific
> clause you didn't follow, then you think I have more spare time than
> I reall
eplacement to see if it has the same issue.
Signed-Off-By: Anthony Foiani
---
drivers/mtd/mtdcore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index c510aff..ac624df 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcor
If an
address family for virtualization is on the table, we should reconsider
AF_VMCHANNEL.
I'd be thrilled to get rid of virtio-serial...
Regards,
Anthony Liguori
cheers,
Gerd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
nt drivers have been adhered to, but if I have missed
something please let me know.
Many thanks,
Anthony Olech, Dialog Semiconductor Ltd.
Tony Olech (at Home) (7):
drivers/mfd: DA9058 MFD core driver
drivers/iio/adc: DA9058 ADC driver
drivers/input/misc: DA9058 ONKEY driver
drivers/rtc:
tagged linux-next - previously relative to mainline
drivers/regulator/da9058-regulator.c
- use generic regulator_set_voltage_time_sel for triggered BUCKs
- print erroneous ret value in dev_err
- changed all names with uV to uv just to confuse and upset all physicists
Signed-off-by: Anthony Olech
suggest name 'input' instead of 'value'
- changed first temp attribute to temp1
- fixed expression error to boolean and from bitwise and
- removed redundant return statement
- removed race condition by initializing before create sysfs
- corected alignments on broken long lines
Si
documented
in the driver source.
Changes relative to V4 of this patch:
- rebased to latest tagged linux-next - previously relative to mainline
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/gpio/Kconfig | 12 ++
drivers/gpio/Makefile |1 +
drivers/gpio/gpio
linux-next - previously relative to mainline
- changed seq_printf to seq_puts where there are no format effectors
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/rtc/Kconfig | 10 +
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-da9058.c | 458
tagged linux-next - previously relative to mainline
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/input/misc/Kconfig| 10 +++
drivers/input/misc/Makefile |1 +
drivers/input/misc/da9058_onkey.c | 177 +
3 files
da9058_adc_channels as static const
- changed to prefered style of nested struct instantiation
- change to .info_mask_separate in struct instantiation
- remove scan_mask
- removed clearing of platform_set_drvdata
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/iio/adc/Kconfig | 12
en adhered to, but if I have missed
something please let me know.
In a clean check out of next-20130419 in linux-next, each patch has been
applied individually and the final result has been built successfully.
Many thanks,
Anthony Olech, Dialog Semiconductor Ltd.
Tony Olech (at Home) (7):
d
no common code
is to be executed.
- embedded a regulator_init_data in the platform data
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/regulator/Kconfig| 11 ++
drivers/regulator/Makefile |1 +
drivers/regulator/da9058-regulator.c | 199
ultiple exit points in functions when no common code
is to be executed.
- aligned continuation lines to preceeding '(' or indent + 2 tabs
- removed redundant mutex hwmon_lock
- merged 6 duplicate lines from 2 branches of if statement
Signed-off-by: Anthony Olech
Signed-off-by: David Da
en adhered to, but if I have missed
something please let me know.
In a clean check out of next-20130419 in linux-next, each patch has been
applied individually and the final result has been built successfully.
Many thanks,
Anthony Olech, Dialog Semiconductor Ltd.
Tony Olech (at Home) (7):
d
been documented
in the driver source.
Changes relative to V5 of this patch:
- rebased to next-20130419 in
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
- removed redundant #include
- corrected dates on copyright statements
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun
no common code
is to be executed.
- embedded a regulator_init_data in the platform data
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/regulator/Kconfig| 11 ++
drivers/regulator/Makefile |1 +
drivers/regulator/da9058-regulator.c | 199
-20130419 in
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
- removed redundant #include
- changed to using devm_request_threaded_irq()
- replaced the very descriptive error exit labels by err1 and err1
- corrected dates on copyright statements
Signed-off-by: Anthony Olech
ultiple exit points in functions when no common code
is to be executed.
- aligned continuation lines to preceeding '(' or indent + 2 tabs
- removed redundant mutex hwmon_lock
- merged 6 duplicate lines from 2 branches of if statement
Signed-off-by: Anthony Olech
Signed-off-by: David Da
next-20130419 in
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
- removed redundant #include
- changed to using devm_request_threaded_irq()
- replaced the very descriptive error exit labels by err1 and err1
- corrected dates on copyright statements
Signed-off-by: Anthony Olech
-next.git
- removed redundant #include
- changed to using devm_request_threaded_irq()
- corrected dates on copyright statements
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/iio/adc/Kconfig | 12 ++
drivers/iio/adc/Makefile |1 +
drivers/iio/adc/da9058
The pci-me.c code contains 2 dev_err() calls which are apparently left
over from debugging; they do not represent actual error conditions.
They do produce messages in a "quiet" kernel, and add ERROR entries to
the logger.
Signed-off-by: "charles anthony"
Linux 3.10-rc6
="$arch" CROSS_COMPILE="$TARGET_TUPLE"- \
oldconfig || exit $?
(
cd tools/perf
make O="$build" ARCH="$arch" CROSS_COMPILE="$TARGET_TUPLE"- V=1 \
EXTRA_CFLAGS="-I $PLATFORM_STAGE/include -I
$PLATFORM_ST
ory. That way, I could configure perf to
use that location without pulling in the sanitized headers.
Sorry if anyone wasted their time chasing down my carelessness.
(Although, to be fair, 'perf' is the only package out of about 20 that
fails when I explicitly point the build at the target&#
Greg Kroah-Hartman writes:
> + * sysfs_create_groups - given a directory kobject, create a bunch of
> attribute groups
> + * @kobj:The kobject to create the group on
> + * @groups: The attribute groups to create, NULL terminated
> + *
> + * This function creates a bunch of attribute groups.
ummo; Jean Delvare; Dmitry Torokhov; Richard Purdie; Anthony Olech
> Subject: Re: [RFC PATCH 2/8] regulator: Add Dialog DA906x voltage regulators
> support.
>
> (trimmed the CC a bit)
>
> Hi Krystian
>
> On Fri, 31 Aug 2012, Krystian Garbaciak wrote:
>
> > > On Wed
s the
first place to try.
Do you mean the da7210 (audio CODEC)? I don't offhand recognise the da9210 part
number.
Best regards,
Tony Olech
> -Original Message-
> From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
> Sent: 09 May 2013 15:29
> To: Anthony Olech
&g
This is the HWMON component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the CORE and ADC component drivers of the DA9058 MFD.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
Documentation/hwmon/da9058
names such as min_uV are in CamelCase,
when it is obvious that they are not in CamelCase I have ignored them.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/regulator/Kconfig| 11 ++
drivers/regulator/Makefile |1 +
drivers/regulator/da9058
: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/gpio/Kconfig | 12 ++
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-da9058.c | 377
3 files changed, 390 insertions(+)
create mode 100644 drivers/gpio/gpio-da9058.c
diff --git a
GPIO and a 3-wire I2C connection.
All the components can be builtin to the kernel or compiled as modules.
As far as I can tell, all the latest APIs both for the core driver and
all the component drivers have been adhered to, but if I have missed
something please let me know.
Many thanks,
Ant
This is the RTC component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the CORE component driver of the DA9058 MFD.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/rtc/Kconfig | 10 +
drivers
This is the ONKEY component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the CORE component driver of the DA9058 MFD.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/input/misc/Kconfig| 10
from
the DA9058 CORE driver, whose settings may be overridden from
the platform data supplied from the machine driver.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/iio/adc/Kconfig | 14 ++
drivers/iio/adc/Makefile |1 +
drivers/iio/adc/da9058-adc.c
+ .owner = THIS_MODULE,
+ },
+};
+
+/*
+ * This driver potentially needs to be started early
+ */
+static int __init da9058_regulator_init(void)
+{
+ return platform_driver_register(&da9058_regulator_driver);
+}
+
+subsys_initcall(da9058_regulator_init);
+
+static void __exit da
form_set_drvdata(pdev, NULL);
+exit:
+ return ret;
+}
+
+static int __devexit da9058_rtc_remove(struct platform_device *pdev)
+{
+ struct da9058_rtc *rtc = platform_get_drvdata(pdev);
+ struct da9058 *da9058 = rtc->da9058;
+
+ free_irq(da9058_to_virt_irq_num(da9058, rtc->al
ed_work_sync(&onkey->work);
+ input_unregister_device(onkey->input);
+
+ return 0;
+}
+
+static struct platform_driver da9058_onkey_driver = {
+ .probe = da9058_onkey_probe,
+ .remove = __devexit_p(da9058_onkey_remove),
+ .driver = {
+ .name = &q
ata(pdev);
+ int ret;
+
+ ret = gpiochip_remove(&gpio->gp);
+ if (ret == 0)
+ kfree(gpio);
+
+ return ret;
+}
+
+static struct platform_driver da9058_gpio_driver = {
+ .probe = da9058_gpio_probe,
+ .remove = __devexit_p(da9058_gpio_remove),
i2c_remove,
+ .id_table = da9058_i2c_id,
+};
+
+/*
+ * This driver is potentially initialised very early during bootup
+ */
+static int __init da9058_i2c_init(void)
+{
+ return i2c_add_driver(&da9058_i2c_driver);
+}
+
+subsys_initcall(da9058_i2c_init);
+
+static void __exit da9058_i2c_exit(
_remove_group(&pdev->dev.kobj, &da9058_attr_group);
+err1:
+exit:
+ return ret;
+}
+
+static int __devexit da9058_hwmon_remove(struct platform_device *pdev)
+{
+ struct da9058_hwmon *hwmon = platform_get_drvdata(pdev);
+
+ hwmon_device_unregister(hwmon->class_device);
wer = platform_get_drvdata(pdev);
+
+ power_supply_unregister(&power->battery);
+ return 0;
+}
+
+static struct platform_driver da9058_power_driver = {
+ .probe = da9058_power_probe,
+ .remove = __devexit_p(da9058_power_remove),
+ .driver = {
+ .name =
connection.
All the components can be builtin to the kernel or compiled as modules.
As far as I can tell, all the latest APIs both for the core driver and
all the component drivers have been adhered to, but if I have missed
something please let me know.
Many thanks,
Anthony Olech, Dialog Semicon
connection.
All the components can be builtin to the kernel or compiled as modules.
As far as I can tell, all the latest APIs both for the core driver and
all the component drivers have been adhered to, but if I have missed
something please let me know.
Many thanks,
Anthony Olech, Dialog Semicon
This is the REGULATOR component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the core DA9058 MFD driver.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/regulator/Kconfig| 11
This is the HWMON component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the core DA9058 MFD driver.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/hwmon/Kconfig| 10 +
drivers/hwmon
This is the GPIO component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the core DA9058 MFD driver.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/gpio/Kconfig | 12 ++
drivers/gpio/Makefile
This is the RTC component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the core DA9058 MFD driver.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/rtc/Kconfig | 10 +
drivers/rtc/Makefile
This is the POWER component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the core DA9058 MFD driver.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/power/Kconfig| 10 +
drivers/power
This is the ONKEY component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the core DA9058 MFD driver.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/input/misc/Kconfig| 10 ++
drivers/input
essential to provide any real platform data at
all.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/mfd/Kconfig | 18 ++
drivers/mfd/Makefile |3 +
drivers/mfd/da9058-core.c| 268 +++
drivers/mfd/da9058
a "panic-device" should cover other OSes is also
> something to consider. Even for Linux, is "panic" the only case which
> should be reported via the mechanism? What about oopses without panic?
>
> Is the mechanism general enough for supporting new events, etc.
Hi,
I
Marcelo Tosatti writes:
> On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
>> Marcelo Tosatti writes:
>>
>> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
>> >>
>> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wro
Marcelo Tosatti writes:
> On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
>> Marcelo Tosatti writes:
>>
>> > On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
>> >> Marcelo Tosatti writes:
>> >>
>> >>
This is the ONKEY component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the CORE component driver of the DA9058 MFD.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/input/misc/Kconfig| 10
platform data from
the DA9058 CORE driver, whose settings may be overridden from
the platform data supplied from the machine driver, but that
config data has the nature of overides from sensible default
values. Thus it is not essential to provide any real platform
data at all.
Signed-off-by: Anthony
now.
Many thanks,
Anthony Olech, Dialog Semiconductor Ltd.
Tony Olech (at Home) (8):
DA9058 MFD core driver
DA9058 ADC driver
DA9058 ONKEY driver
DA9058 POWER driver
DA9058 RTC driver
DA9058 GPIO driver
DA9058 HWMON driver
DA9058 REGULATOR driver
Documentation/hwmon/da9058
: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/gpio/Kconfig | 12 ++
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-da9058.c | 367
3 files changed, 380 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/gpio-da9058
This is the POWER component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the CORE and ADC component drivers of the DA9058 MFD.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/power/Kconfig
This is the RTC component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the CORE component driver of the DA9058 MFD.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/rtc/Kconfig | 10 +
drivers
This is the HWMON component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the CORE and ADC component drivers of the DA9058 MFD.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
Documentation/hwmon/da9058
This is the REGULATOR component driver of the Dialog DA9058 PMIC.
This driver is just one component of the whole DA9058 PMIC driver.
It depends on the CORE component driver of the DA9058 MFD.
Signed-off-by: Anthony Olech
Signed-off-by: David Dajun Chen
---
drivers/regulator/Kconfig
ional. What is the guest and how does it crash?
I've been using the same image for most of KVM's development life cycle
without having issues.
Regards,
Anthony Liguori
This is reproducible on Intel (64bit) kernel. Was this intentional?
i
y likely to be a QEMU issue (that may have already
been fixed).
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To
"Michael S. Tsirkin" writes:
> On Thu, Jul 19, 2012 at 08:05:42AM -0500, Anthony Liguori wrote:
>> Of course, the million dollar question is why would using AIO in the
>> kernel be faster than using AIO in userspace?
>
> Actually for me a more important questio
o drivers/watchdog/, and gain a more complete solution to
> detecting hangs inside the guest.
The purpose of virtio is not to reinvent every possible type of device.
There are plenty of hardware watchdogs that are very suitable to be used
for this purpose. QEMU implements quite a few already.
king port 0x0505 is safe for something like this (as long as
you check to make sure that you really are under KVM).
Regards,
Anthony Liguori
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More ma
Sasha Levin writes:
> On 07/22/2012 09:22 PM, Anthony Liguori wrote:
>> Sasha Levin writes:
>>
>>> On 07/21/2012 09:12 AM, Wen Congyang wrote:
>>>> +#define KVM_PV_PORT (0x505UL)
>>>> +
>>>> #ifdef __KERNEL__
>>
Sasha Levin writes:
> On 07/22/2012 10:19 PM, Sasha Levin wrote:
>> On 07/22/2012 09:22 PM, Anthony Liguori wrote:
>>> Sasha Levin writes:
>>>
>>>> On 07/21/2012 09:12 AM, Wen Congyang wrote:
>>>>> +#define KVM_PV_PORT (0x5
Sasha Levin writes:
> On 07/22/2012 09:14 PM, Anthony Liguori wrote:
>> Sasha Levin writes:
>>
>>> On 07/21/2012 10:44 AM, Wen Congyang wrote:
>>>> We can know the guest is panicked when the guest runs on xen.
>>>> But we do not have such f
ding on what
feature bits are exposed to the guest. So my guess is that the odd
combination of CPUID bits that are exposed to the guest is confusing the
kernel.
Can you post dmesg from the host kernel? Perhaps there's instruction
emulation failing in the host KVM? That would manifest in strange
behavior in the guest.
Regards,
Anthony Liguori
>
> Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ad64/pwrite64).
That all happened without QEMU being in the kernel.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.ht
s in the
-ac series and let bugs go unreported? How will the -ac series improve, and
ultimately, how will the official Linux kernel improve?
Granted, in this case, Alan already knew the problem. :-)
Cheers,
Anthony
--
Anthony Fok Tung-LingCivil and Environmental Engineering
One of these days,
when I have time, I'll post the Oops or the Bug.
Meanwhile, 2.4.x is rock solid on my Cyrix machine. :-)
Thanks,
Anthony
--
Anthony Fok Tung-LingCivil and Environmental Engineering
[EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada
Debi
1.0 for NET4.0
Mar 2 03:43:54 jubilee kernel: IP Protocols: ICMP, UDP, TCP, IGMP
I have attached my .config in this message. I have CONFIG_PSMOUSE
turned on, so I guess I didn't misconfigure it? Dunno. :-)
Thanks,
Anthony
--
Anthony Fok Tung-LingCivil and Environ
I just checked an up-to-date linux-kernel archive, and it appears that
the problem is already known and a patch has been posted too, so you
can ignore my earlier posting about my PS/2 mouse problems in
2.4.2-ac8. Thanks again! :-)
Anthony
--
Anthony Fok Tung-LingCivil and
that helps.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
= Gentlemen! You can't fight in here, this is the War Room! =
= Joseph Anthony [EMAIL PROTECTED] http://www.wastelandranger.org =
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
To u
J decompression error
>
> Joseph Anthony wrote:
>
> > Ok, I just upgraded to 2.4.0 from 2.2.17 and I get a slew of these "PPP:
> > VJ decompression error" messages in my kern.log. I have searched all over
> > the place for a patch or an answer, but find nothing. Thes
m_alloc: Bad slab magic
(corrupt) (name=buffer_head)
> Hi Anthony,
>
> Back in May of this year you responded to a "Bad slab magic" problem
> with Linux. Did you ever come to a resolution as to what was causing
> the error? I am getting this error with RedHat 7.0
On Mon, Nov 20, 2000 at 08:33:25PM +0100, Frank van Maarseveen wrote:
> [...]
> > [root@merrimac linux-2.2.17]# cd scripts
> > [root@merrimac scripts]# gcc -o mkdep.o mkdep.c
> > collect2: ld terminated with signal 11 [Segmentation fault], core dumped
> > [root@merrimac scripts]# gcc -c -o mkdep.
ucpia->sbuf[0].urb = NULL;
+ }
+
+ if (ucpia->sbuf[0].data) {
+ kfree(ucpia->sbuf[0].data);
+ ucpia->sbuf[0].data = NULL;
}
}
HTH.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj
Speaking of Nvidia, I have a Nvidia GeForce2, and had problems loading
the NV kernel module with a patched test10 kernel (i was running test9
before). I took a look at the test10 patch, and noticed the following 2
lines were taken out of /include/linux/wrapper.h:
#define mem_map_inc_count(p)
Hi,
I am unable to compile the latest kernel. I have attached my kernel
configuration and a copy of the output of where the compile fails. I am
looking into what is causing the compile failure, but have not been able to
figure it out yet. Still looking though.
begin 666 make-zImage-err
Thanks. I missed that this time when I modified the Makefile. I didn't pay
close attention to the new script code in there to check for the kernel
compiler.
- Original Message -
From: "Peter Samuelson" <[EMAIL PROTECTED]>
To: "Anthony Barbachan" &l
symlinks, but I know I might be missing
some reason why I shouldn't be attempting this.
Anthony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi all,
I'm looking into upgrading my binutils to the latest stable release. I
do kernel work so I'm guessing from previous experience that I have to get
the Linux specific one. I tracked the linux specific versions down to
ftp.kernel.org but am not certain as to which one is the latest sta
: yes
fpu_exception : no
cpuid level : -1
wp : yes
flags : cyrix_arr
bogomips: 133.12
I'm running Debian 2.2r2 plus some updated packages on this machine.
Thanks for your help.
Anthony
--
Anthony Fok Tung-LingCivil and Environmental Engineer
Glenn Maynard wrote:
I've heard the claim, several times, that that creating a derivative
work requires creative input, that linking stuff together with "ld" is
completely uncreative, therefore no derivative work is created. (I'm
not sure if you're making (here or elsewhere) that claim, but it see
m stuck.
Has anyone else come across this? If so, how were you
able to debug it? I'd appreciate any tips or tricks
you might be able to give.
Thank you in advance for any help you might be able to
offer.
Cheers,
Anthony
-
To unsubscribe from this list: send the line "unsubscribe lin
1 - 100 of 561 matches
Mail list logo
