Michal Piotrowski wrote:
> Subject: 2.6.22-rc1 suspend to RAM problem
> References :
> http://permalink.gmane.org/gmane.linux.power-management.general/5819
> Submitter : Marcus Better <[EMAIL PROTECTED]>
> Handled-By : Stefan Richter <[EMAIL PROTECTED]>
> Kristian Høgsberg <[EMAI
On Fri, May 25, 2007 at 10:50:38AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 25 May 2007, Andrew Morton wrote:
> >
> > > > There is an additional factor - dumps contain data which variously is -
> > > > copyright third parties, protected by privacy laws, just personally
> > > > private, security
On Fri, May 25, 2007 at 09:33:54AM -0700, Andrew Morton wrote:
> On Fri, 25 May 2007 14:34:56 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > * Chris Newport <[EMAIL PROTECTED]> wrote:
> >
> > > There is a fundamental problem in getting a decent log to debug a
> > > crashed kernel. Maybe we
Chris Newport wrote:
>
> Sorry, I did not make myself clear.
>
> Linus Torvalds wrote:
>
>> On Fri, 25 May 2007, Chris Newport wrote:
>>
>>
>>> Maybe we should take a hint from Solaris.
>>>
>>
>> No. Solaris is shit. They make their decisions based on "we control
>> the hardware" kind of s
From: Chris Newport <[EMAIL PROTECTED]>
Date: Fri, 25 May 2007 19:03:51 +0100
> Not really a Solaris feature. This is a feature of the Openboot PROM
> which is also used by several other vendors.
> The Openboot PROM knows how to write to disk. The same should
> apply on Apple hardware and others
Sorry, I did not make myself clear.
Linus Torvalds wrote:
On Fri, 25 May 2007, Chris Newport wrote:
Maybe we should take a hint from Solaris.
No. Solaris is shit. They make their decisions based on "we control the
hardware" kind of setup.
Not really a Solaris feature. This is a
On Fri, 25 May 2007, Andrew Morton wrote:
>
> > > There is an additional factor - dumps contain data which variously is -
> > > copyright third parties, protected by privacy laws, just personally
> > > private, security sensitive (eg browser history) and so on.
> >
> > Yes.
>
> We're uninteres
On Fri, May 25, 2007 at 10:37:14AM -0700, Andrew Morton wrote:
> Often we don't even get that: "I was in X and it didn't hit the logs".
Thats mostly solved by fixing the Oops and framebuffer code to co-operate
and is a different problem
Alan
-
To unsubscribe from this list: send the line "unsubs
On Fri, 25 May 2007 10:19:52 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]>
wrote:
>
>
> On Fri, 25 May 2007, Alan Cox wrote:
> >
> > There is an additional factor - dumps contain data which variously is -
> > copyright third parties, protected by privacy laws, just personally
> > private, sec
On Fri, 25 May 2007, Chuck Ebbert wrote:
>
> Windows can dump memory to the swap file on crash. Default is a "minidump"
> IIRC but you can set it to dump all memory (or none.)
And Linux can too.
And exactly as with Windows, nobody should ever use it. It's a *developer*
thing. It's not a user
On Fri, 25 May 2007, Alan Cox wrote:
>
> There is an additional factor - dumps contain data which variously is -
> copyright third parties, protected by privacy laws, just personally
> private, security sensitive (eg browser history) and so on.
Yes.
I'm sure we've had one or two crashdumps ov
On 05/25/2007 12:45 PM, Linus Torvalds wrote:
> Yes, in a controlled environment, dumping the whole memory image to disk
> may be the right thing to do. BUT: in a controlled environment, you'll
> never get the kind of usage that Linux gets. Why do you think Linux (and
> Windows, for that matter)
> Disk dumps etc are options at things like wall street. But look at the bug
> reports, and ask yourself how many of them happen at Wall Street, and how
> many of them would even be _relevant_ to somebody there?
There is an additional factor - dumps contain data which variously is -
copyright t
On Fri, 25 May 2007, Chris Newport wrote:
>
> Maybe we should take a hint from Solaris.
No. Solaris is shit. They make their decisions based on "we control the
hardware" kind of setup.
> If the kernel crashes Solaris dumps core to swap and sets a flag.
> At the next boot this image is copied t
On Fri, 25 May 2007, Andrew Morton wrote:
> the image". But we're not - kernel developers don't know how to turn the
> thing on in $RANDOM_DISTRO, testers have no experience with the feature
> and kernel developers don't have experience handling the crash images.
Well, we for instance have probl
On Fri, 25 May 2007 14:34:56 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Chris Newport <[EMAIL PROTECTED]> wrote:
>
> > There is a fundamental problem in getting a decent log to debug a
> > crashed kernel. Maybe we should take a hint from Solaris. If the
> > kernel crashes Solaris dumps c
On Fri, 25 May 2007, Stefan Richter wrote:
> Ingo Molnar wrote:
> > i was adding WARN_ON()s that werent true 'warnings' but 'bugs'.
>
> IME, the trace dump in the kernel log looks scary enough to be
> eventually reported, even if prefixed with "WARNING:".
Oh, absolutely. It will stand out like
Chris Newport wrote:
> There is a fundamental problem in getting a decent log to debug a
> crashed kernel.
If the test machine and a 2nd machine have FireWire ports, it's possible
to get the kernel log and more via FireWire, unless the machine rebooted
immediately or the PCI bus locked up. The
* Chris Newport <[EMAIL PROTECTED]> wrote:
> There is a fundamental problem in getting a decent log to debug a
> crashed kernel. Maybe we should take a hint from Solaris. If the
> kernel crashes Solaris dumps core to swap and sets a flag. At the next
> boot this image is copied to /var/adm/cr
Ingo Molnar wrote:
A BUG_ON() has a (much) lower likelyhood of being reported back - for
most users it is a "X just hung hard, there was nothing in the syslog, i
had to switch back to the older kernel" experience, and they do not have
a serial console to hook up (newer hardware often doesnt ev
Ingo Molnar wrote:
> i was adding WARN_ON()s that werent true 'warnings' but 'bugs'.
IME, the trace dump in the kernel log looks scary enough to be
eventually reported, even if prefixed with "WARNING:".
--
Stefan Richter
-=-=-=== -=-= ==--=
http://arcgraph.de/sr/
-
To unsubscribe from this li
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > i very much agree that this kmalloc_index() one shouldnt be called a
> > "BUG: ", but if you look at the majority of WARN_ON() instances they
> > are checks for clear, serious kernel bugs.
>
> I _still_ disagree.
>
> There's a huge difference be
Linus Torvalds wrote:
Doing it in the Makefile would make more sense, since I have to edit that
file anyway to change -rc5 to -rc6.
Tangent: you should also change NAME when you do so :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EM
On Thu, 2007-05-24 at 12:50 -0700, Linus Torvalds wrote:
> There's a huge difference between "You killed my father, prepare to
> die", and "Btw, I didn't like that, but I'll just continue".
There are three cases, not two:
1. Something slightly suboptimal happened. We didn't like it.
2. Something
On Thu, 24 May 2007, Ingo Molnar wrote:
>
> i very much agree that this kmalloc_index() one shouldnt be called a
> "BUG: ", but if you look at the majority of WARN_ON() instances they are
> checks for clear, serious kernel bugs.
I _still_ disagree.
There's a huge difference between "You kill
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > Looks like this is in DRM code:
> >
> > BUG: at include/linux/slub_def.h:88 kmalloc_index()
>
> I'm going to change that "BUG:" to "WARNING:".
>
> I know some people disagreed with it (ie Ingo), but I think that's
> total and utter bullshit.
>
On Thu, 24 May 2007, Andrew Morton wrote:
> On Thu, 24 May 2007 10:12:14 -0700 (PDT)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > > BUG: at include/linux/slub_def.h:88 kmalloc_index()
> >
> > I'm going to change that "BUG:" to "WARNING:".
>
> I think we should remove these kmalloc(0, ..
On Thu, 24 May 2007 10:12:14 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > BUG: at include/linux/slub_def.h:88 kmalloc_index()
>
> I'm going to change that "BUG:" to "WARNING:".
I think we should remove these kmalloc(0, ...) warnings prior to
the 2.6.22 release, put them back afterw
On Thu, 24 May 2007, Linus Torvalds wrote:
> I'm going to change that "BUG:" to "WARNING:".
Good. I wondered for a long time why a "WARN_xxx ... " does print BUG:
xxx.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More ma
On Thu, 24 May 2007, Christoph Lameter wrote:
>
> On Thu, 24 May 2007, Michal Piotrowski wrote:
>
> > Memory management
> >
> > Subject: kernel BUG at include/linux/slub_def.h:88 kmalloc_index()
> > References : http://bugzilla.kernel.org/show_bug.cgi?id=8476
> > Submitter : Cherwin R. Noo
On Thu, 24 May 2007, Michal Piotrowski wrote:
> Memory management
>
> Subject: kernel BUG at include/linux/slub_def.h:88 kmalloc_index()
> References : http://bugzilla.kernel.org/show_bug.cgi?id=8476
> Submitter : Cherwin R. Nooitmeer <[EMAIL PROTECTED]>
> Status : Unknown
Looks like t
On Thu, 24 May 2007, Michal Piotrowski wrote:
> Suspend
>
> Subject: STD fails with pci_device_suspend():
> usb_hcd_pci_suspend+0x0/0x160 [usbcore]() returns -16
> References : http://lkml.org/lkml/2007/5/19/66
> Submitter : Andrey Borzenkov <[EMAIL PROTECTED]>
> Status : Unknown
This
Hi all,
Here is a list of some known regressions in 2.6.22-rc2.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
Memory management
Subject: kernel BUG at include/linux/slub_def.h:88 kmalloc_index()
References : http://bugzilla.kernel.org/show_b
33 matches
Mail list logo
