On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote:
> On Thursday 12 October 2017 12:13:11 Karel Zak wrote:
> > On Thu, Oct 12, 2017 at 11:21:13AM +0200, Pali Rohár wrote:
> > > > The best for me is to keep blkid output backwardly compatible as much
> > > > as possible :-)
> > >
> > >
On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote:
> On Thursday 12 October 2017 12:13:11 Karel Zak wrote:
> > On Thu, Oct 12, 2017 at 11:21:13AM +0200, Pali Rohár wrote:
> > > > The best for me is to keep blkid output backwardly compatible as much
> > > > as possible :-)
> > >
> > >
On Mon, Oct 16, 2017 at 12:04:50AM +0200, Pali Rohár wrote:
> On Sunday 15 October 2017 08:59:01 Pavel Machek wrote:
> > Hi!
> >
> > > Based on results I would propose following unification:
> > >
> > ...
> > > 4. Prefer label from the root directory. If there is none entry (means
> > >there
On Mon, Oct 16, 2017 at 12:04:50AM +0200, Pali Rohár wrote:
> On Sunday 15 October 2017 08:59:01 Pavel Machek wrote:
> > Hi!
> >
> > > Based on results I would propose following unification:
> > >
> > ...
> > > 4. Prefer label from the root directory. If there is none entry (means
> > >there
On Thu, Jul 17, 2014 at 10:31:37AM +0200, Jan Kara wrote:
> On Wed 16-07-14 23:34:08, Andreas Bombe wrote:
> > On Mon, Jul 14, 2014 at 10:35:27AM +0200, Jan Kara wrote:
> > > On Sun 29-06-14 00:50:50, Andreas Bombe wrote:
> > > > None of the post 3.15 kernel boot for
On Thu, Jul 17, 2014 at 10:31:37AM +0200, Jan Kara wrote:
On Wed 16-07-14 23:34:08, Andreas Bombe wrote:
On Mon, Jul 14, 2014 at 10:35:27AM +0200, Jan Kara wrote:
On Sun 29-06-14 00:50:50, Andreas Bombe wrote:
None of the post 3.15 kernel boot for me. They all hang at the GRUB
screen
On Mon, Jul 14, 2014 at 10:35:27AM +0200, Jan Kara wrote:
> On Sun 29-06-14 00:50:50, Andreas Bombe wrote:
> > None of the post 3.15 kernel boot for me. They all hang at the GRUB
> > screen telling me it loaded and started the kernel, but the kernel
> > itself stops befo
On Mon, Jul 14, 2014 at 10:35:27AM +0200, Jan Kara wrote:
On Sun 29-06-14 00:50:50, Andreas Bombe wrote:
None of the post 3.15 kernel boot for me. They all hang at the GRUB
screen telling me it loaded and started the kernel, but the kernel
itself stops before it prints anything (or even
On Mon, Jun 30, 2014 at 01:20:30PM -0700, Andrew Morton wrote:
> On Sun, 29 Jun 2014 00:50:50 +0200 Andreas Bombe wrote:
>
> > None of the post 3.15 kernel boot for me. They all hang at the GRUB
> > screen telling me it loaded and started the kernel, but the kernel
>
On Mon, Jun 30, 2014 at 01:20:30PM -0700, Andrew Morton wrote:
On Sun, 29 Jun 2014 00:50:50 +0200 Andreas Bombe a...@debian.org wrote:
None of the post 3.15 kernel boot for me. They all hang at the GRUB
screen telling me it loaded and started the kernel, but the kernel
itself stops before
The named commit (6402c796d3) causes a process to hang indefinitely in
usb_kill_urb(). Reverting it fixes the problem. The bug also prevents
suspend/shutdown/reboot from completing, presumably due to the hanging
process.
(Cc'ing Stephen Warren because I only found his report after I bisected
it
The named commit (6402c796d3) causes a process to hang indefinitely in
usb_kill_urb(). Reverting it fixes the problem. The bug also prevents
suspend/shutdown/reboot from completing, presumably due to the hanging
process.
(Cc'ing Stephen Warren because I only found his report after I bisected
it
On Sun, Jan 13, 2013 at 02:38:20PM +0300, Sergey Senozhatsky wrote:
> On (01/12/13 20:27), Dave Jones wrote:
> > BUG: sleeping function called from invalid context at mm/slub.c:925
> > in_atomic(): 1, irqs_disabled(): 0, pid: 566, name: Xorg
> > INFO: lockdep is turned off.
> > Pid: 566, comm:
On Sun, Jan 13, 2013 at 02:38:20PM +0300, Sergey Senozhatsky wrote:
On (01/12/13 20:27), Dave Jones wrote:
BUG: sleeping function called from invalid context at mm/slub.c:925
in_atomic(): 1, irqs_disabled(): 0, pid: 566, name: Xorg
INFO: lockdep is turned off.
Pid: 566, comm: Xorg Not
sd_suspend() to return an
error.
Signed-off-by: Andreas Bombe
---
Ok, this patch makes the problem go away, but I'm not sure whether this
is right solution. I also don't know whether SATA RDX docks are sort of
a special case in this regard.
I can think of two other solutions:
1. Also skip
sd_suspend() to return an
error.
Signed-off-by: Andreas Bombe a...@debian.org
---
Ok, this patch makes the problem go away, but I'm not sure whether this
is right solution. I also don't know whether SATA RDX docks are sort of
a special case in this regard.
I can think of two other solutions:
1
On Fri, Aug 31, 2012 at 10:43:42AM -0700, John Stultz wrote:
> On 08/30/2012 09:05 PM, Andreas Bombe wrote:
> >With that somewhat easy test I bisected it down to 4e8b14526 "time:
> >Improve sanity checking of timekeeping inputs". The latest Linus git
> >(155e36d40
On Thu, Aug 30, 2012 at 09:25:52PM -0700, Linus Torvalds wrote:
> On Thu, Aug 30, 2012 at 9:05 PM, Andreas Bombe wrote:
> >
> > With that somewhat easy test I bisected it down to 4e8b14526 "time:
> > Improve sanity checking of timekeeping inputs". The
On Thu, Aug 30, 2012 at 09:25:52PM -0700, Linus Torvalds wrote:
On Thu, Aug 30, 2012 at 9:05 PM, Andreas Bombe a...@debian.org wrote:
With that somewhat easy test I bisected it down to 4e8b14526 time:
Improve sanity checking of timekeeping inputs. The latest Linus git
(155e36d40
On Fri, Aug 31, 2012 at 10:43:42AM -0700, John Stultz wrote:
On 08/30/2012 09:05 PM, Andreas Bombe wrote:
With that somewhat easy test I bisected it down to 4e8b14526 time:
Improve sanity checking of timekeeping inputs. The latest Linus git
(155e36d40) with a revert of the bisected commit does
ore: 2:1.12.3.902-1,
xserver-xorg-video-radeon: 1:6.14.4-5, libdrm: 2.4.33-3).
--
Andreas Bombe
--
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
-xorg-video-radeon: 1:6.14.4-5, libdrm: 2.4.33-3).
--
Andreas Bombe
--
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
On Sun, Jun 24, 2001 at 01:33:51PM -0400, Horst von Brand wrote:
> What gcc objects to is stuff like:
>
>"This is a nice long string
> that just goes on
> and on\n"
>
> which is illegal in C AFAIU. It does not object to:
>
>"This long string"
>"spans several lines, "
>
On Thu, Jun 21, 2001 at 02:21:18PM -0400, Rob Landley wrote:
> Name one thing Microsoft actually invented. Other than Microsoft Bob.
I remember there being a web page where all of Microsoft's "innovations"
were listed and where they bought or stole it from. The only things
that were really
On Thu, Jun 21, 2001 at 02:21:18PM -0400, Rob Landley wrote:
Name one thing Microsoft actually invented. Other than Microsoft Bob.
I remember there being a web page where all of Microsoft's innovations
were listed and where they bought or stole it from. The only things
that were really
On Sun, Jun 24, 2001 at 01:33:51PM -0400, Horst von Brand wrote:
What gcc objects to is stuff like:
This is a nice long string
that just goes on
and on\n
which is illegal in C AFAIU. It does not object to:
This long string
spans several lines,
but legally.\n
On Sun, Jun 17, 2001 at 02:37:03PM +0200, Ronald Bultje wrote:
> system = p-II 400 MHz, 128 MB swap, 440BX (abit p6b) mainboard
> memory is (133 MHz) SDRAM memory (running at 100 MHz)
The question is, does it configure your SDRAMs correctly? I assume it's
on auto config, then the BIOS has to
On Sun, Jun 17, 2001 at 02:37:03PM +0200, Ronald Bultje wrote:
system = p-II 400 MHz, 128 MB swap, 440BX (abit p6b) mainboard
memory is (133 MHz) SDRAM memory (running at 100 MHz)
The question is, does it configure your SDRAMs correctly? I assume it's
on auto config, then the BIOS has to
On Mon, Jun 11, 2001 at 10:08:39AM +0100, Paulo E. Abreu wrote:
> Greetings,
>
> I have this laptop and I am having trouble with pcmcia in every 2.4.x
> kernel.
> Someone suggested that this could be a BIOS bug ...
> Below there is the information, that I think is relevant to this problem. If
>
On Mon, Jun 11, 2001 at 10:08:39AM +0100, Paulo E. Abreu wrote:
Greetings,
I have this laptop and I am having trouble with pcmcia in every 2.4.x
kernel.
Someone suggested that this could be a BIOS bug ...
Below there is the information, that I think is relevant to this problem. If
more
On Sun, Apr 01, 2001 at 03:28:05PM -0500, Tim Hockin wrote:
> > Without syncing, Linux writes whenever it thinks it's appropriate, e.g.
> > when pages have to be freed (I think also when the bdflush writes back
> > data, i.e. every 30 seconds by default).
>
> what about mmap() on non-filesystem
On Thu, Mar 29, 2001 at 02:14:51PM -0800, Jerry Hong wrote:
> Hi,
> mmap() creates a mmaped memory associated with a
> physical file. If a process updates the mmaped memory,
> Linux will updates the file "automatically". If this
> is the case, why do we need msync()?
For the same reason you
On Thu, Mar 29, 2001 at 02:14:51PM -0800, Jerry Hong wrote:
Hi,
mmap() creates a mmaped memory associated with a
physical file. If a process updates the mmaped memory,
Linux will updates the file "automatically". If this
is the case, why do we need msync()?
For the same reason you might
On Sun, Apr 01, 2001 at 03:28:05PM -0500, Tim Hockin wrote:
Without syncing, Linux writes whenever it thinks it's appropriate, e.g.
when pages have to be freed (I think also when the bdflush writes back
data, i.e. every 30 seconds by default).
what about mmap() on non-filesystem files
Something that was itching me for a while (and I had a bad conscience
for not reporting a bug for so long):
I have an IBM Thinkpad i1200 (1161-267, Celeron 550, see lspci below).
The PCI code in 2.4 always complains about an IRQ routing conflict wrt
the CardBus controller. That used to make it
Something that was itching me for a while (and I had a bad conscience
for not reporting a bug for so long):
I have an IBM Thinkpad i1200 (1161-267, Celeron 550, see lspci below).
The PCI code in 2.4 always complains about an IRQ routing conflict wrt
the CardBus controller. That used to make it
Due to a brain malfunction spinlocks were used in pcilynx.c before they
were initialized, causing SMP systems to deadlock. The patch fixes this
and removes one second/redundant initialization of another lock.
diff -ruN linux-2.4.linus/drivers/ieee1394/pcilynx.c
Due to a brain malfunction spinlocks were used in pcilynx.c before they
were initialized, causing SMP systems to deadlock. The patch fixes this
and removes one second/redundant initialization of another lock.
diff -ruN linux-2.4.linus/drivers/ieee1394/pcilynx.c
On Sun, Mar 11, 2001 at 10:18:18PM -0500, Jeff Garzik wrote:
> Andreas Bombe wrote:
> >
> > I couldn't trace that down to be 100% sure and it's better to conform to
> > design than implementation, so I'll ask:
> >
> > Do the probe and remove functions of a pci_d
On Sun, Mar 11, 2001 at 10:18:18PM -0500, Jeff Garzik wrote:
Andreas Bombe wrote:
I couldn't trace that down to be 100% sure and it's better to conform to
design than implementation, so I'll ask:
Do the probe and remove functions of a pci_driver have to be able to
work in interrupt
I couldn't trace that down to be 100% sure and it's better to conform to
design than implementation, so I'll ask:
Do the probe and remove functions of a pci_driver have to be able to
work in interrupt context? (i.e. GFP_ATOMIC and stuff)
I expect so, since CardBus handling doesn't start a
I couldn't trace that down to be 100% sure and it's better to conform to
design than implementation, so I'll ask:
Do the probe and remove functions of a pci_driver have to be able to
work in interrupt context? (i.e. GFP_ATOMIC and stuff)
I expect so, since CardBus handling doesn't start a
On Tue, Feb 20, 2001 at 10:09:55AM +0100, Xavier Bestel wrote:
> Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a écrit :
> > On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
> > > Peter Samuelson <[EMAIL PROTECTED]> writes:
> > > > It also soun
On Tue, Feb 20, 2001 at 10:09:55AM +0100, Xavier Bestel wrote:
Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a crit :
On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
Peter Samuelson [EMAIL PROTECTED] writes:
It also sounds like you will be
breaking the extremely
On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
> Peter Samuelson <[EMAIL PROTECTED]> writes:
> > It also sounds like you will be
> > breaking the extremely useful C postulate that, at the ABI level at
> > least, arrays and pointers are equivalent. I can't see *how* you plan
>
On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
Peter Samuelson [EMAIL PROTECTED] writes:
It also sounds like you will be
breaking the extremely useful C postulate that, at the ABI level at
least, arrays and pointers are equivalent. I can't see *how* you plan
to work
I have sent the following patch three times to you during 2.4.1 prepatch
time and you seem to have missed all of them (Jan 15, 19 and 25). I
hope we can manage that for 2.4.2 and get the known bugs with fixes out
of the ieee1394 subsystem. Finally.
Please, either show some sign of life by
I have sent the following patch three times to you during 2.4.1 prepatch
time and you seem to have missed all of them (Jan 15, 19 and 25). I
hope we can manage that for 2.4.2 and get the known bugs with fixes out
of the ieee1394 subsystem. Finally.
Please, either show some sign of life by
This patch does the missing conversions for the new task queue code, one
of which fixes an oops (the others are there for cleanliness). I use
some internal macros for easy compatibility to Linux 2.2.
The other change incorporated fixes some issues in the PCILynx driver
with bus resets being
This patch does the missing conversions for the new task queue code, one
of which fixes an oops (the others are there for cleanliness). I use
some internal macros for easy compatibility to Linux 2.2.
The other change incorporated fixes some issues in the PCILynx driver
with bus resets being
On Wed, Jan 10, 2001 at 04:48:42AM +0100, Wolfgang Spraul wrote:
> Incompatibility with "Sarotech FHD-352F/U Rev 1.0"
>
> Using an external IDE drive in the Sarotech FireWire enclosure fails, even
> though the Sarotech unit works with Win2K and other SBP2 drives work for me
> (with Linux).
>
>
On Wed, Jan 10, 2001 at 04:48:42AM +0100, Wolfgang Spraul wrote:
Incompatibility with "Sarotech FHD-352F/U Rev 1.0"
Using an external IDE drive in the Sarotech FireWire enclosure fails, even
though the Sarotech unit works with Win2K and other SBP2 drives work for me
(with Linux).
I'm
On Tue, Jan 02, 2001 at 03:56:54PM +0200, Elmer Joandi wrote:
>
> compiling everything builtin, (exept RCPCI, which does not compile)
>
> linking errors:
> drivers/ieee1394/ieee1394.a is not made, quick hack to use .o to see other
> errors.
You're then using the ieee1394.o module object which
On Tue, Jan 02, 2001 at 06:43:57AM +0100, Andreas Bombe wrote:
> Now that I've had the time to understand the new kernel makefile
> structure the patch Kai Germaschewski posted is indeed the correct fix
> (move include line up). Furthermore it builds an .o object in the
> static c
On Tue, Jan 02, 2001 at 03:56:54PM +0200, Elmer Joandi wrote:
compiling everything builtin, (exept RCPCI, which does not compile)
linking errors:
drivers/ieee1394/ieee1394.a is not made, quick hack to use .o to see other
errors.
You're then using the ieee1394.o module object which
Attached is a ksymoops processed oops which kacpid creates as part of
its initialization (i.e. at boot time). It was connected to AC power
with a full battery, if that is significant.
Kernel is 2.4.0-prerelease. The machine is a IBM Thinkpad i1200 series
(to be more specific model 1161-267),
Now that I've had the time to understand the new kernel makefile
structure the patch Kai Germaschewski posted is indeed the correct fix
(move include line up). Furthermore it builds an .o object in the
static compiled case now. I don't see any reason to choose the .a
format and most other
Attached is a ksymoops processed oops which kacpid creates as part of
its initialization (i.e. at boot time). It was connected to AC power
with a full battery, if that is significant.
Kernel is 2.4.0-prerelease. The machine is a IBM Thinkpad i1200 series
(to be more specific model 1161-267),
Now that I've had the time to understand the new kernel makefile
structure the patch Kai Germaschewski posted is indeed the correct fix
(move include line up). Furthermore it builds an .o object in the
static compiled case now. I don't see any reason to choose the .a
format and most other
On Tue, Dec 26, 2000 at 07:24:39AM -0500, [EMAIL PROTECTED] wrote:
>
> Hello,
>
> I have a Sager NP9820 laptop with an ALI chipset and a TI PCI1251BGFN
> PCMCIA chipset. For some reason, when I use the yenta module under 2.4.0,
> it gets an incorrect IRQ assignment. It uses IRQ11, which is
On Tue, Dec 26, 2000 at 07:24:39AM -0500, [EMAIL PROTECTED] wrote:
Hello,
I have a Sager NP9820 laptop with an ALI chipset and a TI PCI1251BGFN
PCMCIA chipset. For some reason, when I use the yenta module under 2.4.0,
it gets an incorrect IRQ assignment. It uses IRQ11, which is also
On Tue, Dec 12, 2000 at 09:34:30AM -0500, Mohammad A. Haque wrote:
> Someone gave me a really awesome idea about possibly using a palm pilot
> to capture the oops. Anyone know if it will be a problem using
> /dev/ttyUSB0 as the serial port?
The driver itself has to provide support for serial
On Tue, Dec 12, 2000 at 09:34:30AM -0500, Mohammad A. Haque wrote:
Someone gave me a really awesome idea about possibly using a palm pilot
to capture the oops. Anyone know if it will be a problem using
/dev/ttyUSB0 as the serial port?
The driver itself has to provide support for serial
On Thu, Nov 30, 2000 at 11:00:07PM -0700, Dax Kelson wrote:
> Linus Torvalds said once upon a time (Tue, 28 Nov 2000):
>
> > - pre3:
> > - Andreas Bombe: ieee1394 cleanups and fixes
>
> Linus, Andreas,
>
> I've been using this same config since FireWire was m
On Thu, Nov 30, 2000 at 11:00:07PM -0700, Dax Kelson wrote:
Linus Torvalds said once upon a time (Tue, 28 Nov 2000):
- pre3:
- Andreas Bombe: ieee1394 cleanups and fixes
Linus, Andreas,
I've been using this same config since FireWire was merged, just tried out
test12-pre3
On Thu, Nov 23, 2000 at 10:04:18PM +0100, Bjorn Wesen wrote:
> On Thu, 23 Nov 2000, Andreas Bombe wrote:
> > > I may be wrong on this, but I thought that copy_{to,from}_user are
> > > only necessary if the address range you are accessing might cause a
> > > fault
On Thu, Nov 23, 2000 at 10:04:18PM +0100, Bjorn Wesen wrote:
On Thu, 23 Nov 2000, Andreas Bombe wrote:
I may be wrong on this, but I thought that copy_{to,from}_user are
only necessary if the address range you are accessing might cause a
fault which Linux cannot handle (ie. one which
On Wed, Nov 22, 2000 at 09:39:51PM +, Keir Fraser wrote:
> > The reason that everyone else uses copy_{to,from}_user is that there
> > is no way to guarantee that the userspace pointer is valid. That
> > memory may have been swapped out. The copy macros are prepared to
> > fault the memory in.
On Wed, Nov 22, 2000 at 09:39:51PM +, Keir Fraser wrote:
The reason that everyone else uses copy_{to,from}_user is that there
is no way to guarantee that the userspace pointer is valid. That
memory may have been swapped out. The copy macros are prepared to
fault the memory in. The
On Sun, Sep 17, 2000 at 06:42:38PM +0530, [EMAIL PROTECTED] wrote:
> hi everyone,
>
> suppose i allocate some kernel memory in a module by calling kmalloc,
> can that memory be swapped out, for example in AIX even the kernel memory
> which is allocated by rmalloc is swappable!!
No, it isn't
On Sun, Sep 17, 2000 at 06:42:38PM +0530, [EMAIL PROTECTED] wrote:
hi everyone,
suppose i allocate some kernel memory in a module by calling kmalloc,
can that memory be swapped out, for example in AIX even the kernel memory
which is allocated by rmalloc is swappable!!
No, it isn't
On Wed, Sep 13, 2000 at 05:31:17PM -0400, Richard B. Johnson wrote:
> On 13 Sep 2000, Ralf Gerbig wrote:
>
> > * Chip Salzenberg writes:
> >
> > Hi Chip,
> >
> > > According to Ralf Gerbig:
> > >> but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels.
> >
> > > You've just made
On Wed, Sep 13, 2000 at 05:31:17PM -0400, Richard B. Johnson wrote:
On 13 Sep 2000, Ralf Gerbig wrote:
* Chip Salzenberg writes:
Hi Chip,
According to Ralf Gerbig:
but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels.
You've just made L-K's understatement of
On Wed, Sep 13, 2000 at 09:33:02AM +0800, Pan Renzi wrote:
> This is a multi-part message in MIME format.
No, it isn't. It just pretends to be.
This is your second post to this list, which is about the Linux kernel
and not about Bind. We can't answer your question, ask the appropriate
people
On Wed, Sep 13, 2000 at 09:33:02AM +0800, Pan Renzi wrote:
This is a multi-part message in MIME format.
No, it isn't. It just pretends to be.
This is your second post to this list, which is about the Linux kernel
and not about Bind. We can't answer your question, ask the appropriate
people
75 matches
Mail list logo
