Le Thursday 26 April 2007 22:44:59 Jay Vosburgh, vous avez écrit :
> Chris Snook <[EMAIL PROTECTED]> wrote:
> >Vincent ETIENNE wrote:
> >> Hi,
> >>
> >> Summary :
> >>Got this trace when one network interface come down or up in a 2
> >>interfaces bonding. So far, system seems to surviv
Le Sunday 29 April 2007 13:18:31 Jiri Kosina, vous avez écrit :
>
> Hi Vincent,
Hi Jiri,
>
> yes, the device is messed up, but it shouldn't have any consequences for
> you - the HID driver is able to correctly handle that, so as soon as we
> don't need to add any extra quirks for such dev
On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
> > No, it isn't a problem in the USB core. The device itself is messed up;
> > it really does report idVendor and idProduct both equal to 0.
> So is it just a scary trace but without consequence that i could ignored
> ? May i ask you what is the devic
Le Saturday 28 April 2007 00:32:37 Andrew Morton, vous avez écrit :
> On Fri, 27 Apr 2007 22:05:28 +0200
>
> because we thought we'd fixed the rtnl_lock() problems in 2.6.21-rc7-mm2.
> Are you sure that log is from 2.6.21-rc7-mm2?
Yes. I have retested it another time ( for adding the small usb d
Le Saturday 28 April 2007 21:50:30 Alan Stern, vous avez écrit :
> No, it isn't a problem in the USB core. The device itself is messed up;
> it really does report idVendor and idProduct both equal to 0.
>
> Jiri, don't worry about all those other devices in the listing that also
> have idVendor an
On Sat, 28 Apr 2007, Jiri Kosina wrote:
> On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
>
> > > I now don't immediately see how this could happen - the vendor ID
> > > seems to be propagated properly from hid_probe() (nothing has been
> > > changed in this codepath), so this would mean that hid_p
On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
> > I now don't immediately see how this could happen - the vendor ID
> > seems to be propagated properly from hid_probe() (nothing has been
> > changed in this codepath), so this would mean that hid_probe() has
> > been passed usb_interface for which
On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
With your patch it seems like idVendor passed is 0. You could see it there ;
http://mail1.vetienne.net/linux/dmesg.2.6.21-rc7-mm2+patch-usbhid
I could confirm that the keyboard is working ( yesterday i was just behind the
box due to test on the netwo
Le Saturday 28 April 2007 00:42:45 Jiri Kosina, vous avez écrit :
> On Fri, 27 Apr 2007, Greg KH wrote:
> > > BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()
>
> [ .. stacktraces stripped .. ]
>
> > Jiri, any thoughts about this? This looks like it comes from your tree
> > as 2
Hi Jiri,
On Sat, 28 Apr 2007, Jiri Kosina wrote:
Paul, do you have any idea? In fact, what was your reason for putting this
WARN_ON() there?
The static quirk list uses idVendor == 0 to mark the end of
hid_blacklist[], so we don't expect any device to have idVendor == 0. If
a device is corr
On Sat, 28 Apr 2007, Jiri Kosina wrote:
> This BUG (it's in fact a warning) is this one:
>WARN_ON(idVendor == 0);
> I now don't immediately see how this could happen - the vendor ID seems
> to be propagated properly from hid_probe() (nothing has been changed in
> this codepath), so this
-
> > > the machine tends to hang after some minutes work in X. That hang is
> > > unusual in that moving the mouse still move the X cursor, but everything
> > > else stops and sysrq fails me. But that is another story.
> > [...]
> > > The (first
On Fri, 27 Apr 2007, Greg KH wrote:
> > BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()
[ .. stacktraces stripped .. ]
> Jiri, any thoughts about this? This looks like it comes from your tree
> as 2.6.21 doesn't have the drivers/hid/usbhid/ directory...
Paul (author of the co
On Fri, Apr 27, 2007 at 11:25:46AM +0200, VE (HOME) wrote:
> Andrew Morton wrote:
> > On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <[EMAIL PROTECTED]>
> > wrote:
> >
> >
> > This was due to locking bustage in the net tree. It should be fixed
> > in 2.6.21-rc7-mm2.
>
> I have tried this ve
in that moving the mouse still move the X cursor, but everything
> > else stops and sysrq fails me. But that is another story.
> [...]
> > The (first) "hanging" patch in 2.6.21-rc6-mm1 is: git-acpi.patch
>
> Hi Helge,
>
> thanks for the effort. If you take stock
hat separately.
>
> And also a strange problem : dhcp server and dns server was started before
> bond0 was completly up ( eth0 and eth1 was declared down at this time and
> up a few times later : was not the case with later 2.6.21-rc6-mm1 )
>
-
To unsubscribe from this list: send
d0 was completly up ( eth0 and eth1 was declared down at this time and
up a few times later : was not the case with later 2.6.21-rc6-mm1 )
Vincent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordo
On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <[EMAIL PROTECTED]> wrote:
> Apr 26 11:09:34 jupiter2 RTNL: assertion failed at
> net/ipv4/devinet.c
> (1055) Apr 26 11:09:34 jupiter2
> Apr 26 11:09:34 jupiter2 Call Trace:
> Apr 26 11:09:3
is
> > unusual in that moving the mouse still move the X cursor, but everything
> > else stops and sysrq fails me. But that is another story.
> [...]
> > The (first) "hanging" patch in 2.6.21-rc6-mm1 is: git-acpi.patch
linux-acpi: we have a problem.
> Hi Helge,
srq fails me. But that is another story.
[...]
> The (first) "hanging" patch in 2.6.21-rc6-mm1 is: git-acpi.patch
Hi Helge,
thanks for the effort. If you take stock rc6-mm1 and revert just
git-acpi.patch, doesn the machine behave correctly?
--
Jiri Kosina
-
To unsubscribe from
nyway, so
calling every hanging kernel "bad" will at least find the first broken
patch.
7: boots up ok!
8,9,10: hangs at the aboce mentioned ACPI message
The (first) "hanging" patch in 2.6.21-rc6-mm1 is: git-acpi.patch
Helge Hafting
-
To unsubscribe from this list: se
Le Thursday 26 April 2007 22:44:59 Jay Vosburgh, vous avez écrit :
> Chris Snook <[EMAIL PROTECTED]> wrote:
> >Vincent ETIENNE wrote:
> >> Hi,
> >>
> >> Summary :
> >>Got this trace when one network interface come down or up in a 2
> >>interfaces bonding. So far, system seems to surviv
Chris Snook <[EMAIL PROTECTED]> wrote:
>Vincent ETIENNE wrote:
>> Hi,
>>
>> Summary :
>> Got this trace when one network interface come down or up in a 2
>> interfaces bonding. So far, system seems to survive to this problem
>> and works fine.
>
>I'm investigating a similar/p
roblem catch my
attention )
Keywords ; network, bonding
Version : Linux version 2.6.21-rc6-mm1 ([EMAIL PROTECTED]) (gcc version 4.1.1
(Gentoo 4.1.1-r3)) #3 SMP Thu Apr 26 08:45:06 CEST 2007
Output of /var/log/messages
Apr 26 11:09:34 jupiter2 e1000: eth0: e1000_watchdog
try a 2.6.20 and 2.6.19 vanilla kernel ( identical problem
but in
onecase the system doesn't survive : that the reason the problem catch
my
attention )
Keywords; network, bonding
Version : Linux version 2.6.21-rc6-mm1 ([EMAIL PROTECTED]) (gcc vers
I recompiled 2.6.21-rc6-mm1 from fresh sources.
It still hangs initializing USBm but this time your
patch applied.
I rebooted with your patch, and got:
Detailed lists of all the USB devices found
(printer,mouse,...)
Then usbcore registered various drivers, such as
usblp, usb-storage, libusual
On Wed, 25 Apr 2007 23:39:54 +0200, "J.A. Magallón" <[EMAIL PROTECTED]> wrote:
> On Wed, 25 Apr 2007 22:50:39 +0200, "J.A. Magallón" <[EMAIL PROTECTED]> wrote:
...
>
> But I think I found the problem.
> In short, in /dev/pts is mounted before /dev. I remounted it and ssh worked
> fine again.
> I'
> >
> > > > > On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.
> > > On Tue, 24 Apr 2007 10:10:41 +0200 "J.A. Magallón" <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > >
Jiri Kosina wrote:
On Wed, 25 Apr 2007, Helge Hafting wrote:
Anyway, based on information you have provided in your later messages,
it seems that it is probably not necessairly related neither to USB
nor HID, as you are getting hangs at different stages of boot,
depending on your local con
On Wed, 25 Apr 2007, Helge Hafting wrote:
> > Anyway, based on information you have provided in your later messages,
> > it seems that it is probably not necessairly related neither to USB
> > nor HID, as you are getting hangs at different stages of boot,
> > depending on your local configurati
Jiri Kosina wrote:
[...]
So I guess you are operating on some broken version of 2.6.21-rc6-mm1
codebase if you are getting rejects on this trivial patch.
Didn't think of that - the codebase might be wrong.
Anyway, based on information you have provided in your later messages, it
> wrote:
> >
> > > On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
> > > >
&g
> >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
> > >
> > >
> > > - Lots of x86 updates
> > >
> >
> > Has somthing related with PTY's changed in this kernel ?
>
>
On Tue, 24 Apr 2007 10:10:41 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> wrote:
> On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-
On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
>
>
> - Lots of x86 updates
>
Has somthing related with PTY's changed in this kernel ?
I have
> "John" == John Stoffel <[EMAIL PROTECTED]> writes:
> "John" == John Stoffel <[EMAIL PROTECTED]> writes:
> Ok, so do I need to do anything special with the next -mm release and
> the next version?
Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-
> "John" == John Stoffel <[EMAIL PROTECTED]> writes:
>>> > Ok, so do I need to do anything special with the next -mm release and
>>> > the next version?
>>>
>>> Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).
Alan> Try drivers/ide/pci/hpt366 - if that works grab a d
On Wed, 2007-04-18 at 19:00 -0400, Joshua Wise wrote:
> On Tue, 17 Apr 2007, Shaohua Li wrote:
> > Looks there is init order issue of sysfs files. The new refreshed patch
> > should fix your bug.
>
> Yes, that did fix the hang on resume from STR -- that now works fine.
>
> However:
> [EMAIL PROTE
On Tue, 17 Apr 2007, Shaohua Li wrote:
Looks there is init order issue of sysfs files. The new refreshed patch
should fix your bug.
Yes, that did fix the hang on resume from STR -- that now works fine.
However:
[EMAIL PROTECTED]:/sys/devices/system/cpu/cpuidle$ cat available_drivers
current_d
Sergei Shtylyov wrote:
HPT chips are surely not a good example of how to do things, more like
an example how *not* to do. :-)
That explains a lot! :)
(guess who's first ATA work was on the Highpoint driver..
.. no need to post the answer here, though)
Cheers
-
To unsubscribe from this li
Hello.
John Stoffel wrote:
Ok, so do I need to do anything special with the next -mm release and
the next version?
Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).
Alan> Try drivers/ide/pci/hpt366 - if that works grab a dmesg and let
Alan> me know. It means that
>> > Ok, so do I need to do anything special with the next -mm release and
>> > the next version?
>>
>> Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).
Alan> Try drivers/ide/pci/hpt366 - if that works grab a dmesg and let
Alan> me know. It means that Sergei's DPLL sync
> > Ok, so do I need to do anything special with the next -mm release and
> > the next version?
>
>Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).
Try drivers/ide/pci/hpt366 - if that works grab a dmesg and let me know.
It means that Sergei's DPLL sync code seems to
John Stoffel wrote:
I was just testing out 2.6.21-rc6-mm1 to test some Cyclades patches
and I noticed that my HPT302 (rev1) controller with a pair of 120gb WD
disks are not longer detected and I get the following in the dmesg
logs:
[ 148.121490] hpt37x: DPLL did not stabilize.
Where
>>>>> "Sergei" == Sergei Shtylyov <[EMAIL PROTECTED]> writes:
Sergei> Hello.
Sergei> John Stoffel wrote:
>> I was just testing out 2.6.21-rc6-mm1 to test some Cyclades patches
>> and I noticed that my HPT302 (rev1) controller with a pair of 120gb
Hello.
John Stoffel wrote:
I was just testing out 2.6.21-rc6-mm1 to test some Cyclades patches
and I noticed that my HPT302 (rev1) controller with a pair of 120gb WD
disks are not longer detected and I get the following in the dmesg
logs:
[ 148.121490] hpt37x: DPLL did not stabilize
On Mon, 2007-04-16 at 22:50 -0400, Joshua Wise wrote:
> On Mon, 16 Apr 2007, Shaohua Li wrote:
> > On Sat, 2007-04-14 at 01:45 +0200, Mattia Dongili wrote:
> >> ...
> > please check if the patch at
> > http://marc.info/?l=linux-acpi&m=117523651630038&w=2 fixed the issue
>
> I have the same system
On Mon, 16 Apr 2007, Shaohua Li wrote:
On Sat, 2007-04-14 at 01:45 +0200, Mattia Dongili wrote:
...
please check if the patch at
http://marc.info/?l=linux-acpi&m=117523651630038&w=2 fixed the issue
I have the same system as Mattia, and when I applied this patch and turned
CPU_IDLE back on, I
On Mon, 2007-04-16 at 22:50 -0400, Joshua Wise wrote:
> On Mon, 16 Apr 2007, Shaohua Li wrote:
> > On Sat, 2007-04-14 at 01:45 +0200, Mattia Dongili wrote:
> >> ...
> > please check if the patch at
> > http://marc.info/?l=linux-acpi&m=117523651630038&w=2 fixed the issue
>
> I have the same system
Hi Jeff and crew,
I was just testing out 2.6.21-rc6-mm1 to test some Cyclades patches
and I noticed that my HPT302 (rev1) controller with a pair of 120gb WD
disks are not longer detected and I get the following in the dmesg
logs:
[ 148.121490] hpt37x: DPLL did not stabilize.
Where before
On Sat, 2007-04-14 at 01:45 +0200, Mattia Dongili wrote:
> On Sun, Apr 08, 2007 at 02:35:59PM -0700, Andrew Morton wrote:
> ...
> > git-acpi.patch
>
> after bisecting I can finally say what breaks resume from STR here:
>
> tada: CPU_IDLE.
> I first spotted the git-acpi.patch then reapplied i
On Sun, Apr 08, 2007 at 02:35:59PM -0700, Andrew Morton wrote:
...
> git-acpi.patch
after bisecting I can finally say what breaks resume from STR here:
tada: CPU_IDLE.
I first spotted the git-acpi.patch then reapplied it and disabled
CPU_IDLE, now my laptop resumes.
Any useful information I
n apply to
2.6.21-rc6-mm1. Please consider it for expedited inclusion.
Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>
---
Sincerely -- Mark Salyzyn
> -Original Message-
> From: Steve Fox [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 10, 2007 6:21 PM
> To: Andrew M
On Thu, 12 Apr 2007, Helge Hafting wrote:
> Are you sure this is the correct patch - against 2.6.21-rc6-mm1 ?
> Hunk 1 out of 1 failed . . .
Well I am pretty sure:
box:~/scratch # wget
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/2.6.21-rc6-m
Jiri Kosina wrote:
On Thu, 12 Apr 2007, Jiri Kosina wrote:
CONFIG_IPMI_SI=y
hangs upon boot on the already mentioned printk from ipmi_si. With
CONFIG_IPMI_SI=m
the boot succeeds. When manually trying to modprobe ipmi_si after that,
the modprobe itself hangs, but the machine remains usable o
m curious to know whether it hangs somewhere inside usb_register(), or
> elsewhere.
>
> Thanks.
>
Are you sure this is the correct patch - against 2.6.21-rc6-mm1 ?
Hunk 1 out of 1 failed . . .
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> in
On Thu, Apr 12, 2007 at 05:31:52PM +0200, Jiri Kosina wrote:
> On Thu, 12 Apr 2007, Jiri Kosina wrote:
>
> > > - try booting without any HID devices plugged in (i.e. usb mice, usb
> > > keyboards) if the problem persists?
> > > - recompile 2.6.21-rc6-mm1 with
wel,low)->IRQ 17
And then it hung. Rebooting into rc5mm4, I got this as the next msgs:
gameport: Trident 4DWave is pci:00:06.0/gameport0, speed 1966kHz
ALSA device list:
#0: Trident TRID4DWAVENX PCI Audio at 0x9400, irq 17
oprofile: using NMI interrupt.
Netfilter messages via NETLINK v0.30.
I
d you please
> > >> - try booting without any HID devices plugged in (i.e. usb mice, usb
> > >> keyboards) if the problem persists?
> > >> - recompile 2.6.21-rc6-mm1 with git-hid.patch reverted to see if it
> > >> helps?
> > >>
On Thu, 12 Apr 2007, Helge Hafting wrote:
> The last messages (handwritten, somewhat shortened)
> calling hid_init+0x0/0x10()
> returned 0
> ran for 0 msec
> calling hid_init+0x0/0x50()
> usbcore registered new interface driver hiddev
> and then it hangs completely.
OK, so it hangs somewhere near
On Thu, 12 Apr 2007, Jiri Kosina wrote:
> CONFIG_IPMI_SI=y
> hangs upon boot on the already mentioned printk from ipmi_si. With
> CONFIG_IPMI_SI=m
> the boot succeeds. When manually trying to modprobe ipmi_si after that,
> the modprobe itself hangs, but the machine remains usable otherwise.
Actu
On Thu, Apr 12, 2007 at 07:49:02PM +0200, Jiri Kosina wrote:
> On Thu, 12 Apr 2007, Andrew Morton wrote:
>
> > Was that with ipmi linked into vmlinux? (Please send the output of grep
> > IPMI .config) I thought we fixed that.
>
> Confirmed. 2.6.21-rc6-mm1 with
>
&g
On Thu, 12 Apr 2007, Andrew Morton wrote:
> Was that with ipmi linked into vmlinux? (Please send the output of grep
> IPMI .config) I thought we fixed that.
Confirmed. 2.6.21-rc6-mm1 with
CONFIG_IPMI_SI=y
hangs upon boot on the already mentioned printk from ipmi_si. With
CONFIG_IPM
i.e. usb mice, usb
> > > > keyboards) if the problem persists?
> > > > - recompile 2.6.21-rc6-mm1 with git-hid.patch reverted to see if it
> > > > helps?
> > > Do you compile with CONFIG_HIDRAW?
> >
> > Helge,
> >
> > wi
On Thu, 12 Apr 2007 17:31:52 +0200 (CEST) Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Thu, 12 Apr 2007, Jiri Kosina wrote:
>
> > > - try booting without any HID devices plugged in (i.e. usb mice, usb
> > > keyboards) if the problem persists?
> > > - reco
sb
> >> keyboards) if the problem persists?
> >> - recompile 2.6.21-rc6-mm1 with git-hid.patch reverted to see if it helps?
> >>
> >
> > Do you compile with CONFIG_HIDRAW?
> >
> No, that one is not set.
>
> I did use the new SLUB thing - c
Jiri, can you send me the output of "lspci -x" ?
-corey
Jiri Kosina wrote:
On Thu, 12 Apr 2007, Jiri Kosina wrote:
- try booting without any HID devices plugged in (i.e. usb mice, usb
keyboards) if the problem persists?
- recompile 2.6.21-rc6-mm1 with git-hid.patch reverted
On Thu, 12 Apr 2007, Jiri Kosina wrote:
> > - try booting without any HID devices plugged in (i.e. usb mice, usb
> > keyboards) if the problem persists?
> > - recompile 2.6.21-rc6-mm1 with git-hid.patch reverted to see if it helps?
> Do you compile with CONFIG_HIDRA
Jiri Kosina wrote:
On Thu, 12 Apr 2007, Jiri Kosina wrote:
Could you please
- try booting without any HID devices plugged in (i.e. usb mice, usb
keyboards) if the problem persists?
- recompile 2.6.21-rc6-mm1 with git-hid.patch reverted to see if it helps?
Do you compile with
On Thu, 12 Apr 2007, Jiri Kosina wrote:
> Could you please
> - try booting without any HID devices plugged in (i.e. usb mice, usb
> keyboards) if the problem persists?
> - recompile 2.6.21-rc6-mm1 with git-hid.patch reverted to see if it helps?
Do you compile with CONFIG_HIDRA
c
> calling hid_init+0x0/0x50()
> usbcore registered new interface driver hiddev
> and then it hangs completely.
Hi Helge,
2.6.21-rc6 (without any -mm patches) works fine?
Could you please
- try booting without any HID devices plugged in (i.e. usb mice, usb
keyboards) if the problem persist
On Thu, 12 Apr 2007 01:07:00 +0200
Helge Hafting <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 11, 2007 at 01:43:46PM -0700, Andrew Morton wrote:
> >
> > OK. If you add initcall_debug to the kernel boot command line, what's the
> > last thing we call?
>
> The last messages (handwritten, somewhat sho
On Wed, Apr 11, 2007 at 01:43:46PM -0700, Andrew Morton wrote:
>
> OK. If you add initcall_debug to the kernel boot command line, what's the
> last thing we call?
The last messages (handwritten, somewhat shortened)
calling hid_init+0x0/0x10()
returned 0
ran for 0 msec
calling hid_init+0x0/0x50()
On Wed, 11 Apr 2007 21:42:27 +0200
Helge Hafting <[EMAIL PROTECTED]> wrote:
> 2.6.21-rc6-mm1 locks up during boot.
> The last message is:
> usbcore: registered new interface driver hiddev
>
> Then it hangs so hard that not even sysrq+B have any effect.
>
> With 2.6.18
On Wed, 11 Apr 2007 09:55:18 -0400
Joseph Fannin <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-04-10 at 15:00 -0400, Reiner Sailer wrote:
> > Joseph,
> >
> > we cannot reproduce the BUG you report. We have identified a potential
> > source (spinlock around mutex_init). I have attached a small patch
2.6.21-rc6-mm1 locks up during boot.
The last message is:
usbcore: registered new interface driver hiddev
Then it hangs so hard that not even sysrq+B have any effect.
With 2.6.18-rc5-mm1, the next messages I normally get are:
usbcore: registered new interface driver usbhid
drivers/usb/input/hid
Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
> > > >Sent: Monday, April 09, 2007 9:08 AM
> > > >To: Andrew Morton
> > > >Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
> > > >[EMAIL PROTECTED]; Pallipadi, Venkatesh
> > > >Subject: Re: 2.6.21-rc6
On Wed, 11 Apr 2007 12:39:05 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> > The next kernel patch for Perfmon will not make use of the idle notification
> > anymore on any platform.
>
> What do you use instead?
>
> I've been actually thinking to add idle notifier support to oprofile to
> corr
On Tue, 2007-04-10 at 15:00 -0400, Reiner Sailer wrote:
> Joseph,
>
> we cannot reproduce the BUG you report. We have identified a potential
> source (spinlock around mutex_init). I have attached a small patch that
> removes this lock from the initialization of the hash table. I have
> tested t
>
> So my point is that you cannot use the PMU to account for wall-clock time
> when you
> go in halted state. Yet, you could use the idle notifier to compensate for it
> by
> recording let's say TSC prior to entry and computing delta on exit. But then
> I am
> not sure what you would do with
Andi,
On Wed, Apr 11, 2007 at 12:39:05PM +0200, Andi Kleen wrote:
>
> > The next kernel patch for Perfmon will not make use of the idle notification
> > anymore on any platform.
>
> What do you use instead?
>
Nothing. I was using the idle notifier as a way to stop monitoring on entry and
resta
> The next kernel patch for Perfmon will not make use of the idle notification
> anymore on any platform.
What do you use instead?
I've been actually thinking to add idle notifier support to oprofile to correct
for the "perfctr doesn't tick in idle" issue which makes numbers not add up to
100%
From: "Martin Schwidefsky" <[EMAIL PROTECTED]>
Date: Wed, 11 Apr 2007 10:15:42 +0200
> On 4/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Tue, 10 Apr 2007 22:11:01 -0700 (PDT) David Miller <[EMAIL PROTECTED]>
> > wrote:
> > I think this means that if CONFIG_32BIT=y, s390 networking gets
On 4/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Tue, 10 Apr 2007 22:11:01 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
I think this means that if CONFIG_32BIT=y, s390 networking gets the whizzy
assembly version and if CONFIG_32BIT=n, it gets to use the generic version.
Possibly th
On Tue, 10 Apr 2007 22:11:01 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
> diff --git a/arch/s390/lib/Makefile b/arch/s390/lib/Makefile
> index 7a44fed..59aea65 100644
> --- a/arch/s390/lib/Makefile
> +++ b/arch/s390/lib/Makefile
> @@ -5,6 +5,6 @@
> EXTRA_AFLAGS := -traditional
>
> lib
Venki,
On Tue, Apr 10, 2007 at 05:15:14PM -0700, Venki Pallipadi wrote:
> > > x86-64 expects all idle handlers to enable interrupts before returning
> > > from
> > > idle handler. This is due to enter_idle(), exit_idle() races. Make
> > > cpuidle_idle_call() confirm to this when there is no pm_id
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 10 Apr 2007 18:47:38 -0700
> attribute(weak) would give a nicer result?
>
> We'd also need to remove s390's EXPORT_SYMBOL(__div64_32), so s390 ends up
> using lib/div64.c's EXPORT_SYMBOL().
Ok, here is the version of the fix I'll use for now:
c
Mathieu Desnoyers wrote:
> Hi Andrew,
>
> I get the following error when compiling 2.6.21-rc6-mm1 for MIPS :
>
>
>
> /opt/crosstool/gcc-3.4.5-glibc-2.3.6/mips-unknown-linux-gnu/bin/mips-unknown-linux-gnu-gcc
> -Wp,-MD,arch/mips/sgi-ip22/.ip22-time.o.d -nostdinc -i
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Wed, 11 Apr 2007 11:15:39 +0900 Fernando Luis Vázquez Cao <[EMAIL
> PROTECTED]> wrote:
>
> > The problem is that to use hard_smp_processor_id in UP kernels just
> > including linux/smp.h does not suffice anymore. Now
> > hard_smp_processor_id is arc
On Wed, 11 Apr 2007 11:15:39 +0900 Fernando Luis Vázquez Cao <[EMAIL
PROTECTED]> wrote:
> The problem is that to use hard_smp_processor_id in UP kernels just
> including linux/smp.h does not suffice anymore. Now
> hard_smp_processor_id is architecture specific code and consequently
> asm/smp.h sh
On Tue, 2007-04-10 at 18:18 -0700, Andrew Morton wrote:
> On Tue, 10 Apr 2007 20:48:38 -0400
> Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
>
> > I get the following build error when building 2.6.21-rc6-mm1 for
> > sparc64:
> >
> >
> > /opt/cr
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 10 Apr 2007 18:47:38 -0700
> On Tue, 10 Apr 2007 18:36:29 -0700 (PDT)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > From: Andrew Morton <[EMAIL PROTECTED]>
> > Date: Tue, 10 Apr 2007 18:29:37 -0700
> >
> > > git-net.patch implements generic li
> From: Andrew Morton [mailto:[EMAIL PROTECTED]
> On Tue, 10 Apr 2007 20:54:20 -0400
> Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
>
> > I get the following build error when compiling 2.6.21-rc6-mm1 for
arm
> > "footbridge" :
> >
> > ...
>
On Tue, 10 Apr 2007 18:36:29 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Tue, 10 Apr 2007 18:29:37 -0700
>
> > git-net.patch implements generic lib/div64.c, but s390 also has a
> > private one. Presumably the appropriate fix is to remove
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 10 Apr 2007 18:29:37 -0700
> git-net.patch implements generic lib/div64.c, but s390 also has a
> private one. Presumably the appropriate fix is to remove s390's
> private implementation within davem's tree.
The s390 version seems to be optimized
On Tue, 10 Apr 2007 20:56:16 -0400
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> The last for today : link error of 2.6.21-rc6-mm1 for s390 :
>
>
>
> /opt/crosstool/gcc-4.1.1-glibc-2.3.6/s390-unknown-linux-gnu/bin/s390-unknown-linux-gnu-ld
> -m elf_s390 -e start
On Tue, 10 Apr 2007 20:54:20 -0400
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> I get the following build error when compiling 2.6.21-rc6-mm1 for arm
> "footbridge" :
>
> ...
>
> make -f /home/compudj/git/linux-2.6-lttng/scripts/Makefile.build obj=init
>
On Tue, 10 Apr 2007 20:48:38 -0400
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> I get the following build error when building 2.6.21-rc6-mm1 for
> sparc64:
>
>
> /opt/crosstool/gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/bin/sparc64-unknown-linux-gnu-gcc
> -Wp
On Tue, 10 Apr 2007 20:50:42 -0400
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> I get the following build error when building 2.6.21-rc6-mm1 for ppc
> 405:
>
>
> /home/compudj/git/linux-2.6-lttng/arch/ppc/syslib/ppc4xx_sgdma.c: In function
>
1 - 100 of 132 matches
Mail list logo
