On Fri, Jul 12, 2019 at 12:21:05PM +0100, Dave Martin wrote:
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 89ade21..1902071 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -1307,6 +1307,13 @@ static bool
On Wed, Sep 26, 2018 at 07:10:55PM +0100, Alan Cox wrote:
> > And I think that's fine. The only way we can make any guarantees is
> > if we do what Alan suggested, which is to imply that a read on a dirty
> > page *block* until the the page is successfully written back. This
> > would destroy
On Wed, Sep 26, 2018 at 07:10:55PM +0100, Alan Cox wrote:
> > And I think that's fine. The only way we can make any guarantees is
> > if we do what Alan suggested, which is to imply that a read on a dirty
> > page *block* until the the page is successfully written back. This
> > would destroy
On Tue, Sep 25, 2018 at 11:46:27AM -0400, Theodore Y. Ts'o wrote:
> (Especially since you can get most of the functionality by
> using some naming convention for files that in the process of being
> written, and then teach some program that is regularly scanning the
> entire file system, such as
On Tue, Sep 25, 2018 at 11:46:27AM -0400, Theodore Y. Ts'o wrote:
> (Especially since you can get most of the functionality by
> using some naming convention for files that in the process of being
> written, and then teach some program that is regularly scanning the
> entire file system, such as
On Tue, Sep 18, 2018 at 02:13:15PM +0100, Phil Elwell wrote:
> I could add a limit on the number of iterations, but if the limit is ever hit,
> leading to an early exit, the port is basically dead because it will never
> receive another interrupt.
Especially if you print something like: ": Too
On Tue, Sep 18, 2018 at 02:13:15PM +0100, Phil Elwell wrote:
> I could add a limit on the number of iterations, but if the limit is ever hit,
> leading to an early exit, the port is basically dead because it will never
> receive another interrupt.
Especially if you print something like: ": Too
On Thu, Sep 06, 2018 at 12:57:09PM +1000, Dave Chinner wrote:
> On Wed, Sep 05, 2018 at 02:07:46PM +0200, Rogier Wolff wrote:
> > And this has worked for years because
> > the kernel caches stuff from inodes and data-blocks. If you suddenly
> > write stuff to harddisk
On Thu, Sep 06, 2018 at 12:57:09PM +1000, Dave Chinner wrote:
> On Wed, Sep 05, 2018 at 02:07:46PM +0200, Rogier Wolff wrote:
> > And this has worked for years because
> > the kernel caches stuff from inodes and data-blocks. If you suddenly
> > write stuff to harddisk
On Wed, Sep 05, 2018 at 08:07:25AM -0400, Austin S. Hemmelgarn wrote:
> On 2018-09-05 04:37, 焦晓冬 wrote:
> >At this point, the /bin/sh may be partially old and partially new. Execute
> >this corrupted bin is also dangerous though.
> But the system may still be usable in that state, while
On Wed, Sep 05, 2018 at 08:07:25AM -0400, Austin S. Hemmelgarn wrote:
> On 2018-09-05 04:37, 焦晓冬 wrote:
> >At this point, the /bin/sh may be partially old and partially new. Execute
> >this corrupted bin is also dangerous though.
> But the system may still be usable in that state, while
On Wed, Sep 05, 2018 at 06:55:15AM -0400, Jeff Layton wrote:
> There is no requirement for a filesystem to flush data on close().
And you can't start doing things like that. In some weird cases, you
might have an application open-write-close files at a much higher rate
than what a harddisk can
On Wed, Sep 05, 2018 at 06:55:15AM -0400, Jeff Layton wrote:
> There is no requirement for a filesystem to flush data on close().
And you can't start doing things like that. In some weird cases, you
might have an application open-write-close files at a much higher rate
than what a harddisk can
On Wed, Sep 05, 2018 at 09:39:58AM +0200, Martin Steigerwald wrote:
> Rogier Wolff - 05.09.18, 09:08:
> > So when a mail queuer puts mail the mailq files and the mail processor
> > can get them out of there intact, nobody is going to notice. (I know
> > mail queuers should
On Wed, Sep 05, 2018 at 09:39:58AM +0200, Martin Steigerwald wrote:
> Rogier Wolff - 05.09.18, 09:08:
> > So when a mail queuer puts mail the mailq files and the mail processor
> > can get them out of there intact, nobody is going to notice. (I know
> > mail queuers should
On Tue, Sep 04, 2018 at 11:44:20AM -0400, Jeff Layton wrote:
> On Tue, 2018-09-04 at 22:56 +0800, 焦晓冬 wrote:
> > On Tue, Sep 4, 2018 at 7:09 PM Jeff Layton wrote:
> > >
> > > On Tue, 2018-09-04 at 16:58 +0800, Trol wrote:
> > > > That is certainly not possible to be done. But at least, shall we
On Tue, Sep 04, 2018 at 11:44:20AM -0400, Jeff Layton wrote:
> On Tue, 2018-09-04 at 22:56 +0800, 焦晓冬 wrote:
> > On Tue, Sep 4, 2018 at 7:09 PM Jeff Layton wrote:
> > >
> > > On Tue, 2018-09-04 at 16:58 +0800, Trol wrote:
> > > > That is certainly not possible to be done. But at least, shall we
On Tue, Sep 04, 2018 at 12:12:03PM -0400, J. Bruce Fields wrote:
>
> Well, I think the point was that in the above examples you'd prefer that
> the read just fail--no need to keep the data. A bit marking the file
> (or even the entire filesystem) unreadable would satisfy posix, I guess.
>
On Tue, Sep 04, 2018 at 12:12:03PM -0400, J. Bruce Fields wrote:
>
> Well, I think the point was that in the above examples you'd prefer that
> the read just fail--no need to keep the data. A bit marking the file
> (or even the entire filesystem) unreadable would satisfy posix, I guess.
>
On Tue, Sep 04, 2018 at 04:58:59PM +0800, 焦晓冬 wrote:
> As for suggestion, maybe the error flag of inode/mapping, or the entire inode
> should not be evicted if there was an error. That hopefully won't take much
> memory. On extreme conditions, where too much error inode requires staying
> in
On Tue, Sep 04, 2018 at 04:58:59PM +0800, 焦晓冬 wrote:
> As for suggestion, maybe the error flag of inode/mapping, or the entire inode
> should not be evicted if there was an error. That hopefully won't take much
> memory. On extreme conditions, where too much error inode requires staying
> in
On Tue, Sep 04, 2018 at 02:32:28PM +0800, 焦晓冬 wrote:
> Hi,
>
> After reading several writeback error handling articles from LWN, I
> begin to be upset about writeback error handling.
>
> Jlayton's patch is simple but wonderful idea towards correct error
> reporting. It seems one crucial thing is
On Tue, Sep 04, 2018 at 02:32:28PM +0800, 焦晓冬 wrote:
> Hi,
>
> After reading several writeback error handling articles from LWN, I
> begin to be upset about writeback error handling.
>
> Jlayton's patch is simple but wonderful idea towards correct error
> reporting. It seems one crucial thing is
On Mon, Sep 03, 2018 at 07:09:03PM +0100, Alan Cox wrote:
> The IRQ number in the PCI configuration space is just a label really for
> legacy OS stuff. Nothing actually routes interrupts according to it (*).
> If it's coming up as 14 that looks more like the BIOS mislabelled it.
> Legacy PCI
On Mon, Sep 03, 2018 at 07:09:03PM +0100, Alan Cox wrote:
> The IRQ number in the PCI configuration space is just a label really for
> legacy OS stuff. Nothing actually routes interrupts according to it (*).
> If it's coming up as 14 that looks more like the BIOS mislabelled it.
> Legacy PCI
On Mon, Sep 03, 2018 at 07:09:03PM +0100, Alan Cox wrote:
> On Mon, 3 Sep 2018 19:16:39 +0200
> > irq 18: nobody cared (try booting with the "irqpoll" option)
> >
> > I've been writing device drivers in the past, but in the past
> > when the lspci listed "IRQ 14" then I'd have to request_irq
On Mon, Sep 03, 2018 at 07:09:03PM +0100, Alan Cox wrote:
> On Mon, 3 Sep 2018 19:16:39 +0200
> > irq 18: nobody cared (try booting with the "irqpoll" option)
> >
> > I've been writing device drivers in the past, but in the past
> > when the lspci listed "IRQ 14" then I'd have to request_irq
Hi,
I'm writing a kernel driver. It is not going to be widely used, so I'm
not motivated to make things nice enough for inclusion in the standard
kernel.
But lspci shows my device:
03:01.0 Serial bus controller [0c80]: Phoenix Contact GmbH & Co. Device 0002
(rev b7)
Flags: bus
Hi,
I'm writing a kernel driver. It is not going to be widely used, so I'm
not motivated to make things nice enough for inclusion in the standard
kernel.
But lspci shows my device:
03:01.0 Serial bus controller [0c80]: Phoenix Contact GmbH & Co. Device 0002
(rev b7)
Flags: bus
On Mon, Jun 12, 2017 at 05:19:03PM +0100, Marc Zyngier wrote:
> > Does Linux not notice when one calls generic_handle_irq with the number of
> > an
> > interrupt without a handler?
>
> It is not so much that the interrupt doesn't have a handler, but that
> the device (or one of the devices) is
On Mon, Jun 12, 2017 at 05:19:03PM +0100, Marc Zyngier wrote:
> > Does Linux not notice when one calls generic_handle_irq with the number of
> > an
> > interrupt without a handler?
>
> It is not so much that the interrupt doesn't have a handler, but that
> the device (or one of the devices) is
On Wed, Apr 15, 2015 at 08:53:07PM +0200, Noralf Trønnes wrote:
> A 16-bit register can't hold a value of 65536.
> Either the max value is 65535 or the register is 17-bits wide.
It is common for hardware registers to have the value "0" mean 65536
in case of a 16-bit register.
The hardware would
On Wed, Apr 15, 2015 at 08:53:07PM +0200, Noralf Trønnes wrote:
A 16-bit register can't hold a value of 65536.
Either the max value is 65535 or the register is 17-bits wide.
It is common for hardware registers to have the value 0 mean 65536
in case of a 16-bit register.
The hardware would
Hi Guys,
I have a file-server that has plenty of memory to cache most of the
things that I use. But after I've upgraded the machine it seems to
expire things from the cache even when there is zero memory pressure.
The case that irritates me most is my mailbox. Ok, I should clean it
out, but
Hi Guys,
I have a file-server that has plenty of memory to cache most of the
things that I use. But after I've upgraded the machine it seems to
expire things from the cache even when there is zero memory pressure.
The case that irritates me most is my mailbox. Ok, I should clean it
out, but
On Thu, Jan 17, 2008 at 04:16:47PM +0300, Anton Salikhmetov wrote:
> 2008/1/17, Miklos Szeredi <[EMAIL PROTECTED]>:
> > > > 4. Recording the time was the file data changed
> > > >
> > > > Finally, I noticed yet another issue with the previous version of my
> > > > patch.
> > > > Specifically, the
On Thu, Jan 17, 2008 at 01:45:43PM +0100, Miklos Szeredi wrote:
> > > 4. Recording the time was the file data changed
> > >
> > > Finally, I noticed yet another issue with the previous version of my
> > > patch.
> > > Specifically, the time stamps were set to the current time of the moment
> > >
On Thu, Jan 17, 2008 at 01:45:43PM +0100, Miklos Szeredi wrote:
4. Recording the time was the file data changed
Finally, I noticed yet another issue with the previous version of my
patch.
Specifically, the time stamps were set to the current time of the moment
when syncing but
On Thu, Jan 17, 2008 at 04:16:47PM +0300, Anton Salikhmetov wrote:
2008/1/17, Miklos Szeredi [EMAIL PROTECTED]:
4. Recording the time was the file data changed
Finally, I noticed yet another issue with the previous version of my
patch.
Specifically, the time stamps were set
On Wed, Jan 16, 2008 at 02:22:49PM +0300, Anton Salikhmetov wrote:
> Unfortunately, this issue has not been fully fixed yet.
>
> My last attempt (http://lkml.org/lkml/2008/1/15/202) to solve
> this problem has a couple of drawbacks:
>
> 1) calling a possibly sleeping function from atomic context
Hi,
I wrote a small app yesterday that updates a file by mmapping the
file (RW), changing the thing around, and then exiting.
This did not trigger a change in the mtime of the file. Thus rsync
didn't pick up that the file had changed.
I understand that tracking every change to a RW mmapped
Hi,
I wrote a small app yesterday that updates a file by mmapping the
file (RW), changing the thing around, and then exiting.
This did not trigger a change in the mtime of the file. Thus rsync
didn't pick up that the file had changed.
I understand that tracking every change to a RW mmapped
On Wed, Jan 16, 2008 at 02:22:49PM +0300, Anton Salikhmetov wrote:
Unfortunately, this issue has not been fully fixed yet.
My last attempt (http://lkml.org/lkml/2008/1/15/202) to solve
this problem has a couple of drawbacks:
1) calling a possibly sleeping function from atomic context -
On Fri, Oct 19, 2007 at 01:49:31AM -0500, Rob Landley wrote:
> On Thursday 18 October 2007 8:00:49 am Rogier Wolff wrote:
> > So... IMHO, it would be useful to implement something that pages out
> > chunks of memory larger than a single hardware page. This would reduce
> > t
On Fri, Oct 19, 2007 at 01:49:31AM -0500, Rob Landley wrote:
On Thursday 18 October 2007 8:00:49 am Rogier Wolff wrote:
So... IMHO, it would be useful to implement something that pages out
chunks of memory larger than a single hardware page. This would reduce
the size of the memory
On Tue, Oct 16, 2007 at 05:34:15PM +1000, Nick Piggin wrote:
> > It's a hard call. The I/O time for 1MB of contiguous disk data
> > is about the I/O time of 512 bytes of contiguous disk data.
>
> And if you're thrashing, then by definition you need to throw
> out 1MB of your working set in order
On Tue, Oct 16, 2007 at 05:34:15PM +1000, Nick Piggin wrote:
It's a hard call. The I/O time for 1MB of contiguous disk data
is about the I/O time of 512 bytes of contiguous disk data.
And if you're thrashing, then by definition you need to throw
out 1MB of your working set in order to
On Sat, Jul 14, 2007 at 07:32:38PM -0700, Mr. James W. Laferriere wrote:
> >So your disk throws a fit
>
> Actually it's brand new . Infant mortallity ? I at least have a
> cold spare available . So Yes I am replacing that puppy . I'll drop
> it
> into another system & give it
On Fri, Jul 13, 2007 at 05:00:18PM -0400, Mark Lord wrote:
> > Ah, that makes sense -- during PIO interrupts happen a lot more often.
> >20 secs still seem to be too much.
>
> I don't think so, even for modern drives.
> Figure 8-10 seconds max for spin-up,
> plus 6-9 seconds to do a sector
On Fri, Jul 13, 2007 at 05:00:18PM -0400, Mark Lord wrote:
Ah, that makes sense -- during PIO interrupts happen a lot more often.
20 secs still seem to be too much.
I don't think so, even for modern drives.
Figure 8-10 seconds max for spin-up,
plus 6-9 seconds to do a sector
Hi,
I have an application that creates some 228 thousand files,
spread over about 4000 directories. Total is not more than
1.3Gb. (I'm not sure, and I don't care if it's 10% or 90% of
that number)
Anyway, I've loaded all of the 1.3Gb into the cache (the machine
has 8Gb of RAM), so that only
Hi,
I have an application that creates some 228 thousand files,
spread over about 4000 directories. Total is not more than
1.3Gb. (I'm not sure, and I don't care if it's 10% or 90% of
that number)
Anyway, I've loaded all of the 1.3Gb into the cache (the machine
has 8Gb of RAM), so that only
Hi,
After turning on the debugging for allocations and locks, I
now get a kernel ooops.
[ 5628.608000] BUG: unable to handle kernel NULL pointer dereference at virtual
address
[ 5628.608000] printing eip:
[ 5628.608000] c0293210
[ 5628.608000] *pde =
[ 5628.608000] Oops:
Hi,
After turning on the debugging for allocations and locks, I
now get a kernel ooops.
[ 5628.608000] BUG: unable to handle kernel NULL pointer dereference at virtual
address
[ 5628.608000] printing eip:
[ 5628.608000] c0293210
[ 5628.608000] *pde =
[ 5628.608000] Oops:
On Wed, May 09, 2007 at 01:10:49PM +0200, Rogier Wolff wrote:
> On Tue, May 08, 2007 at 01:33:52PM -0700, Satyam Sharma wrote:
> > On 5/8/07, Rogier Wolff <[EMAIL PROTECTED]> wrote:
> > >
> > >Hi,
> > >
> > >The nbd client still reliably
On Tue, May 08, 2007 at 01:33:52PM -0700, Satyam Sharma wrote:
> On 5/8/07, Rogier Wolff <[EMAIL PROTECTED]> wrote:
> >
> >Hi,
> >
> >The nbd client still reliably hangs when I use it.
Someone suggested to use
http://git.kernel.org/?p=linux/kernel/git/ax
On Tue, May 08, 2007 at 01:33:52PM -0700, Satyam Sharma wrote:
On 5/8/07, Rogier Wolff [EMAIL PROTECTED] wrote:
Hi,
The nbd client still reliably hangs when I use it.
Someone suggested to use
http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=summary
and that fixed
On Wed, May 09, 2007 at 01:10:49PM +0200, Rogier Wolff wrote:
On Tue, May 08, 2007 at 01:33:52PM -0700, Satyam Sharma wrote:
On 5/8/07, Rogier Wolff [EMAIL PROTECTED] wrote:
Hi,
The nbd client still reliably hangs when I use it.
Someone suggested to use
http://git.kernel.org/?p
Hi,
The nbd client still reliably hangs when I use it.
While looking into this, I found:
446 req->errors = 0;
447 spin_unlock_irq(q->queue_lock);
448
449 mutex_lock(>tx_lock);
450 if
Hi,
The nbd client still reliably hangs when I use it.
While looking into this, I found:
446 req-errors = 0;
447 spin_unlock_irq(q-queue_lock);
448
449 mutex_lock(lo-tx_lock);
450 if
On Tue, Apr 17, 2007 at 10:37:38PM -0700, Andrew Morton wrote:
> Florin, can we please see /proc/meminfo as well?
>
> Also the result of `echo m > /proc/sysrq-trigger'
Hi,
It's been a while since this thread died out, but maybe I'm
having the same problem. Networking, large part of memory is
On Tue, Apr 17, 2007 at 10:37:38PM -0700, Andrew Morton wrote:
Florin, can we please see /proc/meminfo as well?
Also the result of `echo m /proc/sysrq-trigger'
Hi,
It's been a while since this thread died out, but maybe I'm
having the same problem. Networking, large part of memory is
Hi,
I've been doing some work with nbd-servers, but it seems they are
a bit unreliable right now. It seems to be the kernel side that
is locking up.
Doing things like
dd if=/dev/zero of=filesys bs=1k count=1 seek=1024000
nbd-server 1234 `pwd`/filesys
and then
nbd-client othersystem 1234
Hi,
I've been doing some work with nbd-servers, but it seems they are
a bit unreliable right now. It seems to be the kernel side that
is locking up.
Doing things like
dd if=/dev/zero of=filesys bs=1k count=1 seek=1024000
nbd-server 1234 `pwd`/filesys
and then
nbd-client othersystem 1234
On Tue, Aug 30, 2005 at 10:53:13AM +0200, Sven Ladegast wrote:
> >A trick to use would be to send an UDP packet at boot (after 1 minute
> >or so), and then randomly say "once a month" (i.e. about 1/30 chance of
> >sending a packet on the first day) The number of these random packets
> >recieved is
On Tue, Aug 30, 2005 at 10:01:21AM +0200, Sven Ladegast wrote:
> The idea isn't bad but lots of people could think that this is some kind
> of home-phoning or spy software. I guess lots of people would turn this
> feature off...and of course you can't enable it by default. But combined
> with
On Tue, Aug 30, 2005 at 10:01:21AM +0200, Sven Ladegast wrote:
The idea isn't bad but lots of people could think that this is some kind
of home-phoning or spy software. I guess lots of people would turn this
feature off...and of course you can't enable it by default. But combined
with an
On Tue, Aug 30, 2005 at 10:53:13AM +0200, Sven Ladegast wrote:
A trick to use would be to send an UDP packet at boot (after 1 minute
or so), and then randomly say once a month (i.e. about 1/30 chance of
sending a packet on the first day) The number of these random packets
recieved is a measure
On Thu, Jul 21, 2005 at 06:46:32PM +0100, Alan Cox wrote:
> int tty_prepare_flip_string(tty, strptr, len)
>
> Adjust the buffer to allow len characters to be added. Returns a buffer
> pointer in strptr and the length available. This allows for hardware
> that needs to use functions like insl or
On Thu, Jul 21, 2005 at 06:46:32PM +0100, Alan Cox wrote:
int tty_prepare_flip_string(tty, strptr, len)
Adjust the buffer to allow len characters to be added. Returns a buffer
pointer in strptr and the length available. This allows for hardware
that needs to use functions like insl or
On Tue, Jul 19, 2005 at 12:53:38PM +0200, Jiri Slaby wrote:
> Rogier Wolff napsal(a):
> I don't know, if you think it global, or if am I here with other
> fellows (no, I'm not). I don't know what kind of comment you have
> on your mind. Could you, please, specify it more. I only cha
On Tue, Jul 19, 2005 at 12:53:38PM +0200, Jiri Slaby wrote:
Rogier Wolff napsal(a):
I don't know, if you think it global, or if am I here with other
fellows (no, I'm not). I don't know what kind of comment you have
on your mind. Could you, please, specify it more. I only changed
names
On Tue, Jul 19, 2005 at 02:25:23AM +0200, Jiri Slaby wrote:
> The patch is for mixed files from all over the tree.
>
> Kernel version: 2.6.13-rc3-git4
>
> * This patch removes from kernel tree pci_find_device and changes
> it with pci_get_device. Next, it adds pci_dev_put, to decrease reference
On Tue, Jul 19, 2005 at 02:25:23AM +0200, Jiri Slaby wrote:
The patch is for mixed files from all over the tree.
Kernel version: 2.6.13-rc3-git4
* This patch removes from kernel tree pci_find_device and changes
it with pci_get_device. Next, it adds pci_dev_put, to decrease reference
count
On Sun, Jul 10, 2005 at 09:18:15PM -0700, Nish Aravamudan wrote:
> one for the SCSI subsystem. If those individual driver maintainers'
> files are being modified, should they be CC'ed, or is the big patch
> just sent to the SCSI maintainer (in this example)? I just want to
> make sure the correct
On Sun, Jul 10, 2005 at 09:18:15PM -0700, Nish Aravamudan wrote:
one for the SCSI subsystem. If those individual driver maintainers'
files are being modified, should they be CC'ed, or is the big patch
just sent to the SCSI maintainer (in this example)? I just want to
make sure the correct
On Tue, Mar 15, 2005 at 06:39:46PM +0100, Adrian Bunk wrote:
> > @@ -91,6 +91,4 @@ int gs_setserial(struct gs_port *port,
> > int gs_getserial(struct gs_port *port, struct serial_struct __user *sp);
> > void gs_got_break(struct gs_port *port);
> >
> > -extern int gs_debug;
> > -
> > #endif
On Tue, Mar 15, 2005 at 06:39:46PM +0100, Adrian Bunk wrote:
@@ -91,6 +91,4 @@ int gs_setserial(struct gs_port *port,
int gs_getserial(struct gs_port *port, struct serial_struct __user *sp);
void gs_got_break(struct gs_port *port);
-extern int gs_debug;
-
#endif
This patch
On Sun, Feb 27, 2005 at 12:40:53AM +0100, Andries Brouwer wrote:
> (Concerning the "size" version: it occurred to me that there is one
> very minor objection: For extended partitions so far the size did
> not normally play a role. Only the starting sector was significant.
> If, at some moment we
On Sun, Feb 27, 2005 at 12:40:53AM +0100, Andries Brouwer wrote:
(Concerning the size version: it occurred to me that there is one
very minor objection: For extended partitions so far the size did
not normally play a role. Only the starting sector was significant.
If, at some moment we decide
On Thu, Jan 20, 2005 at 07:08:58AM -0800, Greg KH wrote:
> On Thu, Jan 20, 2005 at 03:54:22PM +0100, Rogier Wolff wrote:
> > Hi,
> >
> > When using custom baud rates, the code does:
> >
> >
> >if ((new_serial.baud_base != priv->baud_base) ||
&g
The NBD driver seems to require CAP_SYSADMIN capabilities for
innocent things like asking what the capacity is.
Patch attached.
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have!
Hi,
When using custom baud rates, the code does:
if ((new_serial.baud_base != priv->baud_base) ||
(new_serial.baud_base < 9600))
return -EINVAL;
Which translates to english as:
If you changed the baud-base, OR the new one is
invalid, return
The NBD driver seems to require CAP_SYSADMIN capabilities for
innocent things like asking what the capacity is.
Patch attached.
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have!
Hi,
When using custom baud rates, the code does:
if ((new_serial.baud_base != priv-baud_base) ||
(new_serial.baud_base 9600))
return -EINVAL;
Which translates to english as:
If you changed the baud-base, OR the new one is
invalid, return
On Thu, Jan 20, 2005 at 07:08:58AM -0800, Greg KH wrote:
On Thu, Jan 20, 2005 at 03:54:22PM +0100, Rogier Wolff wrote:
Hi,
When using custom baud rates, the code does:
if ((new_serial.baud_base != priv-baud_base) ||
(new_serial.baud_base 9600
[EMAIL PROTECTED] wrote:
> From [EMAIL PROTECTED] Tue Jun 26 10:20:51 2001
>
> This patch fixes the problem. Please consider applying.
>
> --- linux-2.4.6-pre5/drivers/block/loop.cSat Jun 23 07:52:39 2001
> +++ linux/drivers/block/loop.cTue Jun 26 09:21:47 2001
> @@
[EMAIL PROTECTED] wrote:
From [EMAIL PROTECTED] Tue Jun 26 10:20:51 2001
This patch fixes the problem. Please consider applying.
--- linux-2.4.6-pre5/drivers/block/loop.cSat Jun 23 07:52:39 2001
+++ linux/drivers/block/loop.cTue Jun 26 09:21:47 2001
@@ -653,7
[EMAIL PROTECTED] wrote:
> From: Jari Ruusu <[EMAIL PROTECTED]>
>
> File backed loop device on 4k block size ext2 filesystem:
>
> # dd if=/dev/zero of=file1 bs=1024 count=10
> 10+0 records in
> 10+0 records out
> # losetup /dev/loop0 file1
> # dd if=/dev/zero
[EMAIL PROTECTED] wrote:
From: Jari Ruusu [EMAIL PROTECTED]
File backed loop device on 4k block size ext2 filesystem:
# dd if=/dev/zero of=file1 bs=1024 count=10
10+0 records in
10+0 records out
# losetup /dev/loop0 file1
# dd if=/dev/zero of=/dev/loop0
Alan Cox wrote:
> > Would it make sense to create some sort of 'make config' script that
> > determines what you want in your kernel and then downloads only those
> > components? After all, with the constant release of new hardware, isn't a
> > 50MB kernel release not too far away? 100MB?
>
>
Alan Cox wrote:
Would it make sense to create some sort of 'make config' script that
determines what you want in your kernel and then downloads only those
components? After all, with the constant release of new hardware, isn't a
50MB kernel release not too far away? 100MB?
This should
[EMAIL PROTECTED] wrote:
> My RTL8139 (Identified 8139 chip type 'RTL-8139A')
> was fine in 2.4.3 and doesnt work in 2.4.5.
> Copying the 2.4.3 version of 8139too.c makes things work again.
>
> Since lots of people complained about this, I have not tried to
> debug - maybe a fixed version
[EMAIL PROTECTED] wrote:
My RTL8139 (Identified 8139 chip type 'RTL-8139A')
was fine in 2.4.3 and doesnt work in 2.4.5.
Copying the 2.4.3 version of 8139too.c makes things work again.
Since lots of people complained about this, I have not tried to
debug - maybe a fixed version already
Richard Gooch wrote:
> Dave sent a message out a week or two ago saying he was going to do it
> soon. And back in January he said he'd be doing it in February. The
> kernel list FAQ has stated this right at the top, in big, bright red
> letters. Yesterday, after I saw Dave's announcement, I
Richard Gooch wrote:
Dave sent a message out a week or two ago saying he was going to do it
soon. And back in January he said he'd be doing it in February. The
kernel list FAQ has stated this right at the top, in big, bright red
letters. Yesterday, after I saw Dave's announcement, I updated
Linus Torvalds wrote:
> I'm really serious about doing "resume from disk". If you want a fast
> boot, I will bet you a dollar that you cannot do it faster than by loading
> a contiguous image of several megabytes contiguously into memory. There is
> NO overhead, you're pretty much guaranteed
Linus Torvalds wrote:
I'm really serious about doing resume from disk. If you want a fast
boot, I will bet you a dollar that you cannot do it faster than by loading
a contiguous image of several megabytes contiguously into memory. There is
NO overhead, you're pretty much guaranteed platter
Retry. This time with patch
Roger.
Rogier Wolff wrote:
>
> Hi Linus, Alan,
>
> The patch below implements breaks (correctly) for the RIO and SX
> cards.
>
> We started out trying to fix one thing, but found that the 2.4.4 rio
> driv
Hi Linus, Alan,
The patch below implements breaks (correctly) for the RIO and SX
cards.
We started out trying to fix one thing, but found that the 2.4.4 rio
driver was behind on several patches.
Roger Wolff.
Patrick van de Lageweg.
---
--
** [EMAIL PROTECTED] **
1 - 100 of 375 matches
Mail list logo
