pts in USB.
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-dbg.c | 5 -
drivers/usb/host/xhci.c | 10 ++
drivers/usb/host/xhci.h | 1 +
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 5f3a7c
.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/xhci-dbg.c | 5 -
drivers/usb/host/xhci.c | 10 ++
drivers/usb/host/xhci.h | 1 +
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index
pts in USB.
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-dbg.c | 5 -
drivers/usb/host/xhci.c | 10 ++
drivers/usb/host/xhci.h | 1 +
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 5f3a7c
.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/xhci-dbg.c | 5 -
drivers/usb/host/xhci.c | 10 ++
drivers/usb/host/xhci.h | 1 +
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index
in
every driver.
In case a driver had a weird failure mode in which it leaves the
original channel but only makes it halfway to the new channel, it
could still set phy->current_* and return an error. So there's no
loss of functionality with your change.
- Werner
--
To unsubscribe from thi
driver.
In case a driver had a weird failure mode in which it leaves the
original channel but only makes it halfway to the new channel, it
could still set phy-current_* and return an error. So there's no
loss of functionality with your change.
- Werner
--
To unsubscribe from this list: send the line
h
the XHCI specification. Let's change this to display the endpoint number
and direction, which are much more commonly used concepts in USB (and
map to XHCI DCIs 1-to-1).
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-dbg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/d
specification. Let's change this to display the endpoint number
and direction, which are much more commonly used concepts in USB (and
map to XHCI DCIs 1-to-1).
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/xhci-dbg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
her
USB-based WPAN driver would be more or less in the same boat.
Of course, one could reinvent that wheel as well and make a
usbwpan, but ... :)
(*) Sneak preview, still with a number of issues, not only style:
https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/net/ieee802154
ssions on the air but some form of congestion in
the driver or a problem with the device. But I don't think
that's a valid reason for retrying the transmission at that
level.
- Werner
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...
on the air but some form of congestion in
the driver or a problem with the device. But I don't think
that's a valid reason for retrying the transmission at that
level.
- Werner
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
would be more or less in the same boat.
Of course, one could reinvent that wheel as well and make a
usbwpan, but ... :)
(*) Sneak preview, still with a number of issues, not only style:
https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/net/ieee802154/atusb.c
- Werner
> Yes, okay, that's true. If a new USB device is plugged in while the
> lid is shut, and then the lid is opened very briefly, it's possible
> that the system could suspend again before the new device's "persist"
> attribute is updated. Does that case really matter? The device isn't
> likely to
Yes, okay, that's true. If a new USB device is plugged in while the
lid is shut, and then the lid is opened very briefly, it's possible
that the system could suspend again before the new device's persist
attribute is updated. Does that case really matter? The device isn't
likely to be in
> What drivers/devices don't work with persist? We need to know that now,
> otherwise all other distros and users have problems, right?
We have seen a problem with the LTE modem in the Chromebook Pixel
using the usb/serial/option.c driver, but we are not quite sure of the
root cause yet. It
> Why can't you just revert this in userspace? Isn't that easier than
> doing a kernel patch and providing an option that we need to now
> maintain for pretty much forever?
I could solve it in userspace, but that really feels like a hacky
workaround and not a long term solution. It would mean
Why can't you just revert this in userspace? Isn't that easier than
doing a kernel patch and providing an option that we need to now
maintain for pretty much forever?
I could solve it in userspace, but that really feels like a hacky
workaround and not a long term solution. It would mean that
What drivers/devices don't work with persist? We need to know that now,
otherwise all other distros and users have problems, right?
We have seen a problem with the LTE modem in the Chromebook Pixel
using the usb/serial/option.c driver, but we are not quite sure of the
root cause yet. It
devices before it unfreezes userspace.
This patch introduces a new config option CONFIG_USB_DEFAULT_PERSIST,
which allows distributions to make this decision on their own without
the need to carry a custom patch or revert the kernel's setting in
userspace.
Signed-off-by: Julius Werner
---
drivers
devices before it unfreezes userspace.
This patch introduces a new config option CONFIG_USB_DEFAULT_PERSIST,
which allows distributions to make this decision on their own without
the need to carry a custom patch or revert the kernel's setting in
userspace.
Signed-off-by: Julius Werner jwer
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x2a64a): Section mismatch in
reference from the function apply_microcode_early() to the
function .cpuinit.text:print_ucode()
The function apply_microcode_early() references
the function __cpuinit print_ucode().
This is often because
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x2a64a): Section mismatch in
reference from the function apply_microcode_early() to the
function .cpuinit.text:print_ucode()
The function apply_microcode_early() references
the function __cpuinit print_ucode().
This is often because
That should be corrected, even if it's a problem of the CC
version / libries, or not, compilation can't depend on
this, code can't be so non-standard that it depends on the
compiler version.
wl
=
The problem continues with 3.8-rc
This is grave, no
That should be corrected, even if it's a problem of the CC
version / libries, or not, compilation can't depend on
this, code can't be so non-standard that it depends on the
compiler version.
wl
=
The problem continues with 3.8-rc
This is grave, no
>> Rafael, is possible to apply the patch [1/2] I previously sent ?
>>
>> https://patchwork.kernel.org/patch/1878691/
>
> I need to talk about this with Len. That should happen tomorrow if everything
> goes well.
Hi Rafael,
Have you made a decision on picking up Daniel's first change yet? I
Rafael, is possible to apply the patch [1/2] I previously sent ?
https://patchwork.kernel.org/patch/1878691/
I need to talk about this with Len. That should happen tomorrow if everything
goes well.
Hi Rafael,
Have you made a decision on picking up Daniel's first change yet? I
think it
in any other subroutine was changed
something of global variables in any other subroutine,
what is now incompatible with subroutine perf_event_p6
W.Landgraf
=
On Wed, 16 Jan 2013 17:26:33 -0800
Randy Dunlap wrote:
On 01/15/13 06:50, werner wrote
/13 06:50, werner wrote:
We are now on -rc3 and someone should correct this,
finally
This is a regression, it was not before, on 3.6
This messes up any compilation of the whole kernel, it
results in don't be produced vmlinuz
arch/x86/kernel/cpu/perf_event_p6.o depends on so much
things
*Ping!*
Happy New Year everyone. Is there any update on this? I think Francesco already
pointed out how to solve the last remaining issue with this, so I hope we can
now resubmit these patches and finally get them merged. Daniel?--
To unsubscribe from this list: send the line "unsubscribe
*Ping!*
Happy New Year everyone. Is there any update on this? I think Francesco already
pointed out how to solve the last remaining issue with this, so I hope we can
now resubmit these patches and finally get them merged. Daniel?--
To unsubscribe from this list: send the line unsubscribe
The problem continues with 3.8-rc
This is grave, no vmlinuz is produced.
wl
CC arch/x86/kernel/cpu/perf_event.o
CC arch/x86/kernel/cpu/perf_event_amd.o
CC arch/x86/kernel/cpu/perf_event_p6.o
arch/x86/kernel/cpu/perf_event_p6.c:22: error:
p6_hw_cache_event_ids causes a
The problem continues with 3.8-rc
This is grave, no vmlinuz is produced.
wl
CC arch/x86/kernel/cpu/perf_event.o
CC arch/x86/kernel/cpu/perf_event_amd.o
CC arch/x86/kernel/cpu/perf_event_p6.o
arch/x86/kernel/cpu/perf_event_p6.c:22: error:
p6_hw_cache_event_ids causes a
Thanks again for making this happen, Daniel. I like this version,
except for the small nitpick that I still think it would make sense to
also turn the loop in menu.c around. How about something like this:
for (i = drv->state_count - 1; i >= CPUIDLE_DRIVER_STATE_START; i++) {
Thanks again for making this happen, Daniel. I like this version,
except for the small nitpick that I still think it would make sense to
also turn the loop in menu.c around. How about something like this:
for (i = drv-state_count - 1; i = CPUIDLE_DRIVER_STATE_START; i++) {
handling.
I understand that not everyone here agrees on what the best solution
is, but I think both of them are far better than the inconsistent and
potentially hard-disk-filling way that the current kernel does it.
On Wed, 2012-11-07 at 11:33 -0800, Julius Werner wrote:
> tcp_recvmsg contains a san
Hi,
What is the current status of this? Daniel, do you think you have got
enough feedback to submit a definitive patch for this? Rafael, would
you approve of such a change?
The bug with dynamically added C-states that is tied to this still
hurts the battery life for some users across all distros
Hi,
What is the current status of this? Daniel, do you think you have got
enough feedback to submit a definitive patch for this? Rafael, would
you approve of such a change?
The bug with dynamically added C-states that is tied to this still
hurts the battery life for some users across all distros
handling.
I understand that not everyone here agrees on what the best solution
is, but I think both of them are far better than the inconsistent and
potentially hard-disk-filling way that the current kernel does it.
On Wed, 2012-11-07 at 11:33 -0800, Julius Werner wrote:
tcp_recvmsg contains a sanity
not appear anymore.
Signed-off-by: Julius Werner
---
arch/powerpc/platforms/pseries/processor_idle.c |4 +-
drivers/acpi/processor_idle.c | 57 +-
drivers/cpuidle/cpuidle.c |3 +-
drivers/idle/intel_idle.c
> Maybe you can remove all these computations and set the flag
> en_core_tk_irqen for the driver ? That will be handled by the cpuidle
> framework, no ?
>
> Same comment for the intel_idle driver.
Yeah, I thought about that, too. I was a little too afraid of touching
the
Maybe you can remove all these computations and set the flag
en_core_tk_irqen for the driver ? That will be handled by the cpuidle
framework, no ?
Same comment for the intel_idle driver.
Yeah, I thought about that, too. I was a little too afraid of touching
the
not appear anymore.
Signed-off-by: Julius Werner jwer...@chromium.org
---
arch/powerpc/platforms/pseries/processor_idle.c |4 +-
drivers/acpi/processor_idle.c | 57 +-
drivers/cpuidle/cpuidle.c |3 +-
drivers/idle/intel_idle.c
-off-by: Julius Werner
---
arch/powerpc/platforms/pseries/processor_idle.c |4 ++--
drivers/acpi/processor_idle.c | 12 ++--
drivers/cpuidle/cpuidle.c |3 +--
drivers/idle/intel_idle.c | 13 -
4 files
-off-by: Julius Werner jwer...@chromium.org
---
arch/powerpc/platforms/pseries/processor_idle.c |4 ++--
drivers/acpi/processor_idle.c | 12 ++--
drivers/cpuidle/cpuidle.c |3 +--
drivers/idle/intel_idle.c | 13
Thanks for moving this along, Daniel. I think this is the right
approach... the cpuidle driver shouldn't be more complex than
necessary.
Note that you are starting your loop too high in cpuidle_play_dead...
states[state_count] is not an actual state anymore, it should start at
state_count - 1.
Thanks for moving this along, Daniel. I think this is the right
approach... the cpuidle driver shouldn't be more complex than
necessary.
Note that you are starting your loop too high in cpuidle_play_dead...
states[state_count] is not an actual state anymore, it should start at
state_count - 1.
> So you probably are fighting a bug we already fixed in upstream kernel.
>
> (commit c8628155ece363 "tcp: reduce out_of_order memory use" did not
> played well with cloned skbs.)
>
> This issue was already discussed on netdev in the past.
Thanks for the hint. Unfortunately, we have not pulled
> What I find very sad in all this is that you didnt mention the driver
> that was triggering this bug.
Sorry, I was just trying to keep this thread focussed on one patch.
The bug report that led me to this is publicly accessible at
http://crosbug.com/35827. We have encountered the problem only
to userspace (which seems most appropriate to me at this
point). As the underlying bug condition is "impossible" and therefore by
definition unrecoverable, this is the only sensible action other than a
full panic.
Signed-off-by: Julius Werner
---
net/ipv4/tcp.c |7 ++-
1 files changed, 6
I tend to agree with Dave that it's not in the user's best interest to
have a full-on BUG() here, and that we can get our reports just as
well by fishing them from the log through abrt or something similar. I
will just submit my alternative patch too and let you decide which one
you prefer.
This
I tend to agree with Dave that it's not in the user's best interest to
have a full-on BUG() here, and that we can get our reports just as
well by fishing them from the log through abrt or something similar. I
will just submit my alternative patch too and let you decide which one
you prefer.
This
to userspace (which seems most appropriate to me at this
point). As the underlying bug condition is impossible and therefore by
definition unrecoverable, this is the only sensible action other than a
full panic.
Signed-off-by: Julius Werner jwer...@chromium.org
---
net/ipv4/tcp.c |7 ++-
1 files
What I find very sad in all this is that you didnt mention the driver
that was triggering this bug.
Sorry, I was just trying to keep this thread focussed on one patch.
The bug report that led me to this is publicly accessible at
http://crosbug.com/35827. We have encountered the problem only
So you probably are fighting a bug we already fixed in upstream kernel.
(commit c8628155ece363 tcp: reduce out_of_order memory use did not
played well with cloned skbs.)
This issue was already discussed on netdev in the past.
Thanks for the hint. Unfortunately, we have not pulled c8628 into
> We've had reports of this WARN against the Fedora kernel for a while.
> Had this been immediately followed by a BUG(), we'd have never seen those
> traces at all,
> and just got "my machine just locked up" reports instead.
>
> The proper fix here is to find out why we're getting into this
of the error can be identified right away and the
system's hard drive is not unnecessarily strained.
Signed-off-by: Julius Werner
---
net/ipv4/tcp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 197c000..fcb0927 100644
--- a/net/ipv4
of the error can be identified right away and the
system's hard drive is not unnecessarily strained.
Signed-off-by: Julius Werner jwer...@chromium.org
---
net/ipv4/tcp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 197c000..fcb0927
We've had reports of this WARN against the Fedora kernel for a while.
Had this been immediately followed by a BUG(), we'd have never seen those
traces at all,
and just got my machine just locked up reports instead.
The proper fix here is to find out why we're getting into this state.
Are
>> Is it just
>> for (prev = *first; prev; prev = prev->next)
>>xhci_segment_free(xhci, prev);
>>
>> ?
>
> Yeah, that seems cleaner.
>
> Sarah Sharp
I can submit it that way if you want, but I would advise against it. This way
you access the prev pointer after it has been freed already…
, this would lead to a use after free.
This patch fixes those issues by having xhci_alloc_segments_for_ring()
destroy its half-built, non-circular list manually and destroying the
invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
Signed-off-by: Julius Werner
---
drivers/usb/host
, this would lead to a use after free.
This patch fixes those issues by having xhci_alloc_segments_for_ring()
destroy its half-built, non-circular list manually and destroying the
invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
Signed-off-by: Julius Werner jwer...@chromium.org
Is it just
for (prev = *first; prev; prev = prev-next)
xhci_segment_free(xhci, prev);
?
Yeah, that seems cleaner.
Sarah Sharp
I can submit it that way if you want, but I would advise against it. This way
you access the prev pointer after it has been freed already… that's probably
>I have noticed that the patch description has DOS line endings as well.
Sorry about those, Gmail adds them automatically. According to RFC
2046 (section 4.1.1), text/plain content must use CRLFs to encode line
breaks, so I guess this is the right thing. Your MUA should be
responsible for
, this would lead to a use after free.
This patch fixes those issues by having xhci_alloc_segments_for_ring()
destroy its half-built, non-circular list manually and destroying the
invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
Signed-off-by: Julius Werner
---
drivers/usb/host
, this would lead to a use after free.
This patch fixes those issues by having xhci_alloc_segments_for_ring()
destroy its half-built, non-circular list manually and destroying the
invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
Signed-off-by: Julius Werner jwer...@chromium.org
I have noticed that the patch description has DOS line endings as well.
Sorry about those, Gmail adds them automatically. According to RFC
2046 (section 4.1.1), text/plain content must use CRLFs to encode line
breaks, so I guess this is the right thing. Your MUA should be
responsible for
> Could we just say this is always true because state[i+1] consumes less
> than state[i] ?
>
> And then just remove the 'set_power_state' function, and the field
> 'driver->power_specified' ?
>
> That will cleanup the code and fix this problem, no ?
I totally agree with your analysis. Even if a
Could we just say this is always true because state[i+1] consumes less
than state[i] ?
And then just remove the 'set_power_state' function, and the field
'driver-power_specified' ?
That will cleanup the code and fix this problem, no ?
I totally agree with your analysis. Even if a driver
to enter them.
This patch ensures that the ACPI cpuidle driver sets those dummy power
values itself whenever it (re-)initializes its idle states.
Tested and verified on an Acer AC700 Chromebook, which supports the C3
state only when it switches from AC to battery power.
Signed-off-by: Julius Werner
to enter them.
This patch ensures that the ACPI cpuidle driver sets those dummy power
values itself whenever it (re-)initializes its idle states.
Tested and verified on an Acer AC700 Chromebook, which supports the C3
state only when it switches from AC to battery power.
Signed-off-by: Julius Werner
> This is specific to the acpi and should be handled in the
> processor_idle.c file instead of the cpuidle core code.
>
> Could be the function 'acpi_processor_cst_has_changed' the right place
> to set a dummy power value for the power in the new C-state ?
Thanks for your feedback. I think it
This is specific to the acpi and should be handled in the
processor_idle.c file instead of the cpuidle core code.
Could be the function 'acpi_processor_cst_has_changed' the right place
to set a dummy power value for the power in the new C-state ?
Thanks for your feedback. I think it wouldn't
it switches from AC to battery power.
Signed-off-by: Julius Werner
---
drivers/cpuidle/cpuidle.c | 24
drivers/cpuidle/driver.c | 25 -
2 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle
it switches from AC to battery power.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/cpuidle/cpuidle.c | 24
drivers/cpuidle/driver.c | 25 -
2 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/drivers/cpuidle
CC init/version.o
LD init/built-in.o
drivers/built-in.o: In function `gmux_probe':
apple-gmux.c:(.devinit.text+0x6daa8): undefined reference
to `apple_bl_unregister'
drivers/built-in.o: In function `gmux_remove':
apple-gmux.c:(.devexit.text+0x8f80): undefined reference
to
CC init/version.o
LD init/built-in.o
drivers/built-in.o: In function `gmux_probe':
apple-gmux.c:(.devinit.text+0x6daa8): undefined reference
to `apple_bl_unregister'
drivers/built-in.o: In function `gmux_remove':
apple-gmux.c:(.devexit.text+0x8f80): undefined reference
to
CC drivers/power/twl4030_charger.o
drivers/power/twl4030_charger.c:248:12: error: invalid
suffix "b1100" on integer constant
drivers/power/twl4030_charger.c:250:12: error: invalid
suffix "b1000" on integer constant
drivers/power/twl4030_charger.c:252:12: error: invalid
suffix "b0100" on
CC drivers/power/twl4030_charger.o
drivers/power/twl4030_charger.c:248:12: error: invalid
suffix b1100 on integer constant
drivers/power/twl4030_charger.c:250:12: error: invalid
suffix b1000 on integer constant
drivers/power/twl4030_charger.c:252:12: error: invalid
suffix b0100 on
On an Acer Aspire 5349 I get several error messages during
booting, with 3.5-rc7 . Pls inspect the added syslog.
wl
Jul 16 00:39:53 localhost kernel: WARNING: at
drivers/pci/hotplug/ibmphp_ebda.c:282
ibmphp_access_ebda+0x104/0x517()
Jul 16 00:39:53 localhost kernel: Hardware name: Aspire
On an Acer Aspire 5349 I get several error messages during
booting, with 3.5-rc7 . Pls inspect the added syslog.
wl
Jul 16 00:39:53 localhost kernel: WARNING: at
drivers/pci/hotplug/ibmphp_ebda.c:282
ibmphp_access_ebda+0x104/0x517()
Jul 16 00:39:53 localhost kernel: Hardware name: Aspire
On a computer of someone else, on which today I tried to
install 3.5-rc6 (what on my computer and on an HP pavillon
laptop runs without problem - on the laptop however needs
ircpoll otherwhise don't find the harddisk), few seconds
after start booting it sticks and don't continue longer
On a computer of someone else, on which today I tried to
install 3.5-rc6 (what on my computer and on an HP pavillon
laptop runs without problem - on the laptop however needs
ircpoll otherwhise don't find the harddisk), few seconds
after start booting it sticks and don't continue longer
There is a big problem since 3.5-rc1 which potentially
mess the installations
rdev don't give longer back the root device like
/dev/sda1 , but in the bios form like 0x80010300
rdev is essential for the installation programs and for
the installation f.ex. of lilo . It's not conveniente
There is a big problem since 3.5-rc1 which potentially
mess the installations
rdev don't give longer back the root device like
/dev/sda1 , but in the bios form like 0x80010300
rdev is essential for the installation programs and for
the installation f.ex. of lilo . It's not conveniente
I reported a regression, that when a usb-key is connected, #lilo produces a
bootloader which don't work, on 2.6.24-rc6-git2, diferently to kernels before.
Yesterday I compiled 2.6.24-rc6-git8 with exactly the same kernel parameters,
with this, the problem didnt occure again, on the same 2
I reported a regression, that when a usb-key is connected, #lilo produces a
bootloader which don't work, on 2.6.24-rc6-git2, diferently to kernels before.
Yesterday I compiled 2.6.24-rc6-git8 with exactly the same kernel parameters,
with this, the problem didnt occure again, on the same 2
There seems to have two regressions between the kernels from yesterday and
before-yesterday
On the kernel -git7 what didnt happened on -git6
1) My hard disk is /dev/hda, but when I have an usb key sticked in /dev/sba,
and run lilo then, then it dont boot but give L99 99 99 99 ... error. When I
There seems to have two regressions between the kernels from yesterday and
before-yesterday
On the kernel -git7 what didnt happened on -git6
1) My hard disk is /dev/hda, but when I have an usb key sticked in /dev/sba,
and run lilo then, then it dont boot but give L99 99 99 99 ... error. When I
On 7/Nov/2007 20:10 werner wrote ..
> With 2.6.23-rc2 is the same problem: it crashed at the beginning: EIP 060
> c03fdea4
> EFLAGS 00010212 EIP is at xor_sse_2+0x34/0x200
> Again during the compilation was reclaimed that
> /arch/x86/Makefile.o
> cannot be found and were ce
On 7/Nov/2007 20:10 werner wrote ..
With 2.6.23-rc2 is the same problem: it crashed at the beginning: EIP 060
c03fdea4
EFLAGS 00010212 EIP is at xor_sse_2+0x34/0x200
Again during the compilation was reclaimed that
source-dir/arch/x86/Makefile.o
cannot be found and were certain
Kernel Crash -- Details see below
globc 2.7 glib2 2.14.2
W.Landgraf
www.copaya.yi.org
=
2.6.24-rc1-git10
EIP 0600: EFLAGS 00010212 CPU 0
EIUP is at xor_sse_2+0x34/0x200
EAX: 10 EBX
Kernel Crash -- Details see below
globc 2.7 glib2 2.14.2
W.Landgraf
www.copaya.yi.org
=
2.6.24-rc1-git10
EIP 0600: c0407284 EFLAGS 00010212 CPU 0
EIUP is at xor_sse_2+0x34/0x200
EAX: 10 EBX
hope you can find and repair this before the 2.6.23 release
Below is the beginning of dmesg for the two kernels what I quoted above.
Werner Landgraf
www.copaya.yi.org
== dmesg 2.6.23-rc9-git2 (drm no working longer ...)
===
Linux version 2.6.23-rc9
hope you can find and repair this before the 2.6.23 release
Below is the beginning of dmesg for the two kernels what I quoted above.
Werner Landgraf
www.copaya.yi.org
== dmesg 2.6.23-rc9-git2 (drm no working longer ...)
===
Linux version 2.6.23-rc9
Am Freitag, 21. September 2007 18:18 schrieb Greg KH:
Hello,
> On Fri, Sep 21, 2007 at 10:15:11AM +0200, Werner Cornelius wrote:
> > Hello,
> >
> > attached you will find the patch against the 2.6.23-rc6-mm1
> >
> > Changed fetaures:
> >
> >
Hello,
attached you will find the patch against the 2.6.23-rc6-mm1
Changed fetaures:
1. All baudrates possible (dynamic baudfactor calculation)
2. Added support of modem control and status lines.
Still missing (due to lack of an usb sniffer):
1. Break control
2. Parity
Werner
--- linux
Hello,
attached you will find the patch against the 2.6.23-rc6-mm1
Changed fetaures:
1. All baudrates possible (dynamic baudfactor calculation)
2. Added support of modem control and status lines.
Still missing (due to lack of an usb sniffer):
1. Break control
2. Parity
Werner
--- linux
Hello,
attached you will find the patch against the 2.6.23-rc6-mm1
Changed fetaures:
1. All baudrates possible (dynamic baudfactor calculation)
2. Added support of modem control and status lines.
Still missing (due to lack of an usb sniffer):
1. Break control
2. Parity
Werner
--- linux
Hello,
attached you will find the patch against the 2.6.23-rc6-mm1
Changed fetaures:
1. All baudrates possible (dynamic baudfactor calculation)
2. Added support of modem control and status lines.
Still missing (due to lack of an usb sniffer):
1. Break control
2. Parity
Werner
--- linux
Am Freitag, 21. September 2007 18:18 schrieb Greg KH:
Hello,
On Fri, Sep 21, 2007 at 10:15:11AM +0200, Werner Cornelius wrote:
Hello,
attached you will find the patch against the 2.6.23-rc6-mm1
Changed fetaures:
1. All baudrates possible (dynamic baudfactor calculation)
2. Added
701 - 800 of 1003 matches
Mail list logo
