Andrew Morton <[EMAIL PROTECTED]> disait derniÃrement que :
> Helge Hafting <[EMAIL PROTECTED]> wrote:
>>
>> This kernel came up, but my boot script complained about no /dev/hdb3
>> when trying to mount /var.
>> (I have two IDE disks on the same cable, and an IDE cdrom on another.)
>> They are
On Wednesday 23 February 2005 18:12, Ed Tomlinson wrote:
> On Wednesday 23 February 2005 17:38, J.A. Magallon wrote:
> >
> > On 02.23, Andrew Morton wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/
> > >
> > >
> > > - Various fixes and
Vijayalakshmi Hadimani wrote:
Hi,
I am inserting a module(device driver) using insmod.
I want to send a message from this module to an user process.
For this I used msgsnd with buffer in the call as a local
variable. I am getting an error "EFAULT" for this call.
However this did not happen
Dominik Brodowski a écrit :
+pcmcia-bridge-resource-management-fix.patch
is responsible for this "no resource available" message, because the other
ones relate to other areas.
This line from dmesg-2.6.11-rc4 is no longer present in -rc4-mm1:
PCI: Transparent bridge - :00:1e.0
This is probably
On Wed, Feb 23, 2005 at 06:42:32PM +, Telemaque Ndizihiwe wrote:
> This Patch replaces "(2 * HZ)" with "DATA_TIMEOUT" which is defined as
> #define DATA_TIMEOUT (2 * HZ)
> in /drivers/usb/atm/speedtch.c in kernel 2.6.10.
>
> Signed-off-by: Telemaque Ndizihiwe <[EMAIL PROTECTED]>
This has
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
>
> >It's not quite inexplicable. It means that task has hit its limit for
> >pending signals ;-) But I agree, this should be fixed. I think I had
> >tested this with broken test cases, thanks for catching.
> >
> It's
Hugh Dickins wrote:
I'm off to bed, but since your appetite for looking at patches
is greater than mine, I'll throw what I'm currently testing over
the wall to you now. Against 2.6.11-rc4-bk9, but my starting point
was obviously your patches. Not yet split up, but clearly should be.
Yeah you've
Mark Lord wrote:
Minor patch for new 2.6.xx sata_qstor driver attached,
as per Alexey's fine-toothed comb! :)
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
Cool, I'll throw this into libata-2.6 soonish.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Alan Kilian wrote:
Maybe that's it.
I ask the card which interrupt line it was given at boot-time:
pci_read_config_byte(dev, PCI_INTERRUPT_LINE,
>interrupt_line);
Then I request an IRQ:
request_irq(softp->interrupt_line, sseintr,
On Wed, Feb 23, 2005 at 11:36:50PM +0100, Laurent Riffard wrote:
> hey, what's this /dev/hds ? digging into /sys/block...
>
> ~$ ls -l /sys/block/hds/device
> lrwxrwxrwx 1 root root 0 f?v 23 22:45 /sys/block/hds/device ->
> ../../devices/pci:00/:00:04.1/ide1/1.1/
>
> /dev/hdq should be
Steven Cole <[EMAIL PROTECTED]> wrote:
>
> > Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be
> > missing.
Looking at the IDE update in rc4-mm1:
+void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
+{
+ ide_hwif_t *hwif = drive->hwif;
+ unsigned int unit
On Thu, 24 Feb 2005 10:52:23 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> So I'd be pretty happy for you to queue this up with Andrew for
> 2.6.12. Anyone else?
No objections from me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
> gdb attach the vmware, then force it to call routine you preloaded...
>
> Or look at subterfugue.
> Pavel
Brilliant Pavel. Thank you. gdb works great.
Dan
-
To unsubscribe from this list: send the line "unsubscribe
Olof Johansson wrote:
> How's this? I went with get_val_no_fault(), since it isn't really a
> get_user.*() any more (ptr being passed in), and no_paging is a little
> misleading (not all faults are due to paging).
How ironic: I deliberately didn't choose "no_fault" because that
function *does*
On Thu, Feb 24, 2005 at 12:32:59AM +0100, Mathieu Segaud wrote:
> Andrew Morton <[EMAIL PROTECTED]> disait derni??rement que :
>
> > Helge Hafting <[EMAIL PROTECTED]> wrote:
> >>
> >> This kernel came up, but my boot script complained about no /dev/hdb3
> >> when trying to mount /var.
> >> (I
Hi Burn
Could you try the attached patch
It solved the same problem for me, it is NOT SMP safe due
to cli() calls, though will run fine on your system. I have been
running a console box for about 1mth non-stop with these applied.
The patch does two things it allows the driver to be built-in and
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Could someone try this?
Let's turn that into a real patch.
--- 25/drivers/ide/ide-probe.c~ide_init_disk-fixWed Feb 23 16:24:44 2005
+++ 25-akpm/drivers/ide/ide-probe.c Wed Feb 23 16:24:55 2005
@@ -1269,7 +1269,7 @@
Dmitry Torokhov a ecrit le 24.02.2005 00:40:
On Wednesday 23 February 2005 18:12, Ed Tomlinson wrote:
On Wednesday 23 February 2005 17:38, J.A. Magallon wrote:
On 02.23, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/
- Various fixes
On Wednesday 23 February 2005 18:40, Dmitry Torokhov wrote:
> On Wednesday 23 February 2005 18:12, Ed Tomlinson wrote:
> > On Wednesday 23 February 2005 17:38, J.A. Magallon wrote:
> > >
> > > On 02.23, Andrew Morton wrote:
> > > >
> > > >
Erm, this updated patch.
J
If we're sending a signal relating to a faulting instruction, then
always generate siginfo for that signal.
If the user has some unrelated process which has managed to consume
the user's entire allocation of siginfo, then signals will start being
delivered
Any chance to convince the alien who took control of Jeff's libata queue to
push:
r8169: synchronization and balancing when the device is closed
(1.1982.1.58 ?)
Test case on current 2.6.11-rc4:
- ifconfig ethX 10.0.0.1 up
- ifconfig ethX down
- ifconfig ethX 10.0.0.1 up
-> Rx does not work any
Alan> I ask the card which interrupt line it was given at
Alan> boot-time:
Alan> pci_read_config_byte(dev, PCI_INTERRUPT_LINE,
>interrupt_line);
Alan> Then I request an IRQ:
Alan> request_irq(softp->interrupt_line, sseintr, SA_INTERRUPT,
"sse", softp);
Don't
On Wed, Feb 23, 2005 at 04:16:53PM -0800, Andrew Morton wrote:
> Steven Cole <[EMAIL PROTECTED]> wrote:
> >
> > > Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be
> > > missing.
>
> Looking at the IDE update in rc4-mm1:
>
> +void ide_init_disk(struct gendisk *disk,
Ingo,
We've had a PPC port of your RT work underway with
a focus on trace instrumentation. This is based upon
realtime-preempt-2.6.11-rc2-V0.7.37-02. A diff is
attached.
To the extent possible the tracing facilities are the
same as your x86 work. In the process a few PPC/gcc
issues needed
Steven Cole <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > Steven Cole <[EMAIL PROTECTED]> wrote:
>
> >> I am having trouble getting recent -mm kernels to boot on my test box.
> >> For 2.6.11-rc3-mm2 and 2.6.11-rc4-mm1 I get the following:
> >>
> >> VFS: Cannot open root device "301" or
On Wed, 23 Feb 2005, Mickey Stein wrote:
From: Mickey Stein
Versions: linux-2.6.11-rc4-bk11, gcc4 (GCC) 4.0.0 20050217 (latest fc
rawhide from 19Feb DL)
gcc 4.0.x cvs seems to dislike "include/linux/i2c.h file" and others due to a
current gcc 4.0.x change having to do with
array declarations.
On Wed, Feb 23, 2005 at 03:10:38PM -0700, Steven Cole wrote:
> Andrew Morton wrote:
> >Steven Cole <[EMAIL PROTECTED]> wrote:
>
> >>I am having trouble getting recent -mm kernels to boot on my test box.
> >>For 2.6.11-rc3-mm2 and 2.6.11-rc4-mm1 I get the following:
> >>
> >>VFS: Cannot open root
Chris Wright wrote:
>>/proc/N/status will tell you that a process has
>>a signal pending, but it won't tell you how many are pending).
>>
>>
>
>Suggestion for good place to display that info?
>
>
I guess another line in /proc/N/status:
SigQue: 0 0 0 0 0 0 0 123 0 0 1238 0 0 0 0 0 ... 0
Horst von Brand <[EMAIL PROTECTED]> wrote:
>
> Machine is sparc64, bk of today, gcc-3.4.2-6.fc3 (Aurora Corona). First 2.6
> I try to build here, so it might be something known.
>
> Build fails due to -Werror with:
>
> include/asm/uaccess.h: In function `load_elf_binary':
>
Jeff Garzik <[EMAIL PROTECTED]> :
[...]
> Agree it needs fixing, but I actually think the rx-offset stuff is more
> urgent than this. For the future, it would be useful for both of us to
> have separate r8169-fixes and r8169-cleanups queues.
Do you have a synonym/pointer for the rx-offset
Hi Amon,
On Mon, Feb 21, 2005 at 11:19:16AM +0100, Amon Ott wrote:
> > -> 5. Posix Capabilities Without Stacking Support
> >
> > I don't get the point of these claims.
> > The LSM framework currently has full support for dynamic and
> > logic-changeable POSIX.1e capabilities, using the capable()
On Thu, 2005-02-24 at 10:27 +1100, Nick Piggin wrote:
> Hugh Dickins wrote:
> > On Wed, 23 Feb 2005, Lee Revell wrote:
> >
> Thanks, your patch fixes the copy_pte_range latency.
> >>
> >>clear_page_range is also problematic.
> >
> >
> > Yes, I saw that from your other traces too. I know
On Wed, 2005-02-23 at 15:46 -0800, Roland Dreier wrote:
> Alan> pci_read_config_byte(dev, PCI_INTERRUPT_LINE,
> >interrupt_line);
> Alan> request_irq(softp->interrupt_line, sseintr, SA_INTERRUPT,
> "sse", softp);
>
> Don't do that. The kernel may need you to use a different
> So, I think such a fork/execve/exit hooks is harmless now.
I don't recall seeing any microbenchmarking of the impact on fork/exit
of such hooks. You might find such a benchmark in lmbench, or at
http://bulk.fefe.de/scalability/.
--
I won't rest till it's the best ...
Lee Revell wrote:
On Thu, 2005-02-24 at 10:27 +1100, Nick Piggin wrote:
If you are using i386 with 2-level page tables (no highmem), then
the behaviour should be more or less identical. Odd.
IIRC last time I really tested this a few months ago, the worst case
latency on that machine was about
I run installed and updated sarge. I downloaded 2.6.10 from kernel.org.
When I use apt-get under 2.4.27 everything is OK
When I use apt-get under 2.6.10, I get a segfault
I run the same combination (allthough a different configuration on a Pentium III (Coppermine) and
on a Intel(R) Pentium(R) M
Indeed, I think your patch does not go far enough. I can read POSIX to say
that the siginfo_t data must be available when `kill' was used, as well.
This patch makes it allocate the siginfo_t, even when that exceeds
{RLIMIT_SIGPENDING}, for any non-RT signal (< SIGRTMIN) not sent by
sigqueue
Hi Paul,
I think the microbenchmarking your link provides is irrelevant.
Your link provides benchmarking of doing a fork.
However, we are talking about inserting a callback routine
in a fork and/or an exit. The overhead is a function
call and time spent in the routine. The callback routine
can be
I see this problem with the sata_sil.c driver and
SII3112 card. Others have reported seeing a similar
problem: http://lkml.org/lkml/2005/2/6/41
There seems to be a pending interrupt from the drive,
but the code has already set the NIEN bit, so the
ATA_IRQ_TRAP macro doesn't help (the
Retry... that patch got screwed up in the last
email...
-Brian
__
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail--- libata-core.c.orig 2005-02-23 17:41:03.831836464 -0800
+++
On Wed, 23 Feb 2005 16:41:59 -0800, Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 23, 2005 at 04:16:53PM -0800, Andrew Morton wrote:
> > Steven Cole <[EMAIL PROTECTED]> wrote:
> > >
> > > > Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be
> > > > missing.
> >
> >
On Wed, 23 Feb 2005, linux-os wrote:
> On Wed, 23 Feb 2005, Bodo Eggert wrote:
> > linux-os <[EMAIL PROTECTED]> wrote:
> >> You don't seem to understand. A process that's stuck in 'D' state
> >> shows a SEVERE error, usually with a hardware driver.
> >
> > Or a network filesystem mount to a no
> -Memory: 255872k available (1788k kernel code, 976k data, 144k init, 0k
> highmem)
> +Memory: 255872k available (1776k kernel code, 0k data, 144k init, 0k highmem)
That is weird... (0k data)
> AGP special page: 0xc000
> Calibrating delay loop... 830.66 BogoMIPS (lpj=4153344)
>
Jeremy mentioned the aggravation of not being able to tell when your
processes are using up signal queue entries and hitting the
RLIMIT_SIGPENDING limit. This patch adds a line to /proc/PID/status
showing how many queue items are in use, and allowed, for your uid.
I can certainly see the appeal
Jay wrote:
> I think the microbenchmarking your link provides is irrelevant.
In the cases such as you describe where it's just some sort of empty
function call, then yes, I am willing to accept a wave of the hands and
a simple explanation of how it's not significant. I've done the same
myself
On Thu, Feb 24, 2005 at 03:03:33AM +0100, Benoit Boissinot wrote:
> On Wed, 23 Feb 2005 16:41:59 -0800, Matt Mackall <[EMAIL PROTECTED]> wrote:
> > On Wed, Feb 23, 2005 at 04:16:53PM -0800, Andrew Morton wrote:
> > > Steven Cole <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Yes, that worked.
On Tuesday 22 February 2005 04:57 am, Martin MOKREJŠ wrote:
> The 3GB labeled file corresponds to fast case, 4GB is ugly slow.
> What can you gather from those files?
I did take a look and didn't analyze it further since Andi Mentioned it is a
known BIOS bug.
Sorry about the trouble - didn't
While looking into the issues Jeremy had with the RLIMIT_SIGPENDING limit,
it occurred to me that the normal setting of this limit is bizarrely low.
The initial hard limit setting (MAX_SIGPENDING) was taken from the old
max_queued_signals parameter, which was for the entire system in aggregate.
On Thu, 2005-02-24 at 12:29 +1100, Nick Piggin wrote:
> Lee Revell wrote:
> >
> > IIRC last time I really tested this a few months ago, the worst case
> > latency on that machine was about 150us. Currently its 422us from the
> > same clear_page_range code path.
> >
> Well it should be pretty
* Roland McGrath ([EMAIL PROTECTED]) wrote:
> Indeed, I think your patch does not go far enough. I can read POSIX to say
> that the siginfo_t data must be available when `kill' was used, as well.
How? I only see reference to filling in SI_USER for rt signals?
Just curious...(I've only got SuSv3
* Roland McGrath ([EMAIL PROTECTED]) wrote:
> Jeremy mentioned the aggravation of not being able to tell when your
> processes are using up signal queue entries and hitting the
> RLIMIT_SIGPENDING limit. This patch adds a line to /proc/PID/status
> showing how many queue items are in use, and
Does this patch do anything useful?
Jeff
= drivers/scsi/sata_sil.c 1.44 vs edited =
--- 1.44/drivers/scsi/sata_sil.c2005-02-17 19:43:51 -05:00
+++ edited/drivers/scsi/sata_sil.c 2005-02-23 21:27:18 -05:00
@@ -65,6 +65,7 @@
static u32 sil_scr_read (struct ata_port
"Chad N. Tindel" <[EMAIL PROTECTED]> wrote:
>
> We have hit a defect where an exiting xterm process will hang. This is
> running
> on a 2-cpu IA-64 box. We have a multithreaded application, where one thread
> is SCHED_FIFO and is running with priority 98, and the other thread is just
> a
BTW, please CC your replies to linux-ide@vger.kernel.org as well.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Lee Revell wrote:
On Thu, 2005-02-24 at 12:29 +1100, Nick Piggin wrote:
Lee Revell wrote:
IIRC last time I really tested this a few months ago, the worst case
latency on that machine was about 150us. Currently its 422us from the
same clear_page_range code path.
Well it should be pretty trivial to
> * Roland McGrath ([EMAIL PROTECTED]) wrote:
> > Indeed, I think your patch does not go far enough. I can read POSIX to say
> > that the siginfo_t data must be available when `kill' was used, as well.
>
> How? I only see reference to filling in SI_USER for rt signals?
> Just curious...(I've
> Two questions: 1) This changes the interface for consumers of
> /proc/[pid]/status data, do we care? Adding new line like this should be
> safe enough.
As far as I can tell, noone fretted about the addition of Threads:,
ShdPnd:, etc., which were not always there.
> 2) Perhaps we should do
> Does this patch do anything useful?
>
> Jeff
>
Not really. It doesn't print the nobody cared
message, but still hangs at boot. I'd give you a
backtrace but my MAGIC_SYSRQ doesn't seem to be
working right now.
-Brian
Linux version 2.6.11-rc4 ([EMAIL PROTECTED])
(gcc version 3.3.2)
On Wed, 23 Feb 2005 14:31:20 -0500, Bill Davidsen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Hello
> >
> > I have read a post in lkml.org that states that the problem experienced in
> > rc3 has gone (1). That is not the case for me.
> >
> > My audio device is
> >
> > :00:1f.5
On Thu, 2005-02-24 at 13:41 +1100, Nick Piggin wrote:
> Lee Revell wrote:
> >
> > Agreed, it would be much better to optimize this away than just add a
> > scheduling point. It seems like we could do this lazily.
> >
>
> Oh? What do you mean by lazy? IMO it is sort of implemented lazily now.
>
* Roland McGrath ([EMAIL PROTECTED]) wrote:
> > Two questions: 1) This changes the interface for consumers of
> > /proc/[pid]/status data, do we care? Adding new line like this should be
> > safe enough.
>
> As far as I can tell, noone fretted about the addition of Threads:,
> ShdPnd:, etc.,
Dmitry Torokhov wrote:
Yes, It usually happens either under high load, when mouse interrupts are
significantly delayed. Or sometimes it happen when applications poll
battey status and on some boxes it takes pretty long time. And because
it is usually the same chip that serves keyboard/mouse it
* Roland McGrath ([EMAIL PROTECTED]) wrote:
> While looking into the issues Jeremy had with the RLIMIT_SIGPENDING limit,
> it occurred to me that the normal setting of this limit is bizarrely low.
> The initial hard limit setting (MAX_SIGPENDING) was taken from the old
> max_queued_signals
I would like to better understand ext2/3's performance characteristics.
I'm specifically interested in how ext2/3 will handle a /var/spool/mail
directory w/ ~6000 mbox format inboxes, handling approx 1GB delivered as
75,000 messages daily. Virtually all access is via imap, w/ approx
~1000 imapd
* Roland McGrath ([EMAIL PROTECTED]) wrote:
> > * Roland McGrath ([EMAIL PROTECTED]) wrote:
> > > Indeed, I think your patch does not go far enough. I can read POSIX to
> > > say
> > > that the siginfo_t data must be available when `kill' was used, as well.
> >
> > How? I only see reference to
On Wednesday 23 February 2005 22:05, Anthony DiSante wrote:
> Dmitry Torokhov wrote:
> > Yes, It usually happens either under high load, when mouse interrupts are
> > significantly delayed. Or sometimes it happen when applications poll
> > battey status and on some boxes it takes pretty long time.
On Wed, 23 Feb 2005, Ron Peterson wrote:
I would like to better understand ext2/3's performance characteristics.
I'm specifically interested in how ext2/3 will handle a /var/spool/mail
directory w/ ~6000 mbox format inboxes, handling approx 1GB delivered as
75,000 messages daily. Virtually all
Jeff, please apply:
Here's a big stack of patches that make a significant step forward on
the long overdue orinoco driver merge. Still quite a long way to go,
but it's something. This patch stack is againt Linus' vanilla +
Viro's big iomap cleanup patch, as requested.
The first 9 patches make
Removes the orinoco driver's custom and dodgy "connected" variable
used to track whether or not we're associated with an AP. Replaces it
instead with netif_carrier_ok() settings.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco.c
Use mdelay() or ssleep() instead of various silly more complicated
ways of delaying in the orinoco driver.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco_pci.c
===
---
Introduce a free_orinocodev() function into the orinoco driver, used
by the hardware type/initialization modules to free the device
structure in preference to directly calling free_netdev(). At the
moment free_orinocodev() just calls free_netdev(). Future merges will
make it clean up internal
Remove has_ibss_any flag and never set the CREATEIBSS RID when the
ESSID is empty. Too many firmware break if we do.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco.c
===
---
Make the is_ethersnap() function take a void * rather than a pointer
to the internal header structure. This makes more logical sense and
reduces dependencies between different parts of the code.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco.c
Previous patches have brought the in-kernel orinoco driver roughly to
parity with version 0.14alpha2 from out-of-tree. Update the version
number and changelog accordingly.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco.c
Update the initialization code in the various PCI incarnations of the
orinoco driver. This applies similar initialization and shutdown
cleanups to the orinoco_pci, orinoco_plx and orinoco_tmd drivers. It
also adds COR reset support to the orinoco_plx and orinoco_tmd
drivers, improves PCI power
Update firmware detection code. This will now reliably detect
Intersil firmwares past verison 1.x, a serious flaw in the previous
code. It cleans up the code, and reduces the size of the private
structure by using single bits for the various firmware feature flags.
Signed-off-by: David Gibson
Delay netif_wake_queue() until the packet has actually been
transmitted, rather than just when the firmware has copied it into its
internal buffers. This seems to prevent problems on some Intersil
firmware versions (I suspect the problems were caused by the
firmware's buffers filling up).
john cooper wrote:
Ingo,
We've had a PPC port of your RT work underway with
a focus on trace instrumentation. This is based upon
realtime-preempt-2.6.11-rc2-V0.7.37-02. A diff is
attached.
To the extent possible the tracing facilities are the
same as your x86 work. In the process a few
Updates to the WEP configuration code. This adds support for shared
key authentication on Agere firmwares. It also adds support (in some
cases) for changing the WEP keys without disabling the MAC port (thus
triggering a reassociation by the firmware). This is needed by 802.1x
implementations,
On Wed, 2005-02-23 at 22:11 -0500, Ron Peterson wrote:
> I would like to better understand ext2/3's performance characteristics.
>
> I'm specifically interested in how ext2/3 will handle a /var/spool/mail
> directory w/ ~6000 mbox format inboxes, handling approx 1GB delivered as
> 75,000 messages
Cleanup the various bits of initialization code for PCMCIA / PC-Card
orinoco devices. This includes one important bugfix where we could
fail to take the lock in some circumstances.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco_cs.c
FYI, pci_set_drvdata() needs to be one of the last functions called
during PCI ->probe().
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Gibson wrote:
Add descrptions to module parameters in the orinoco driver, and also
add permissions to allow them to be exported in sysfs.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco.c
Hey, I hoped -rc4 was the last one, but we had some laptop resource
conflicts, various ppc TLB flush issues, some possible stack overflows in
networking and a number of other details warranting a quick -rc5 before
the final 2.6.11.
This time it's really supposed to be a quickie, so people who
Ron Peterson <[EMAIL PROTECTED]> wrote:
>
> I would like to better understand ext2/3's performance characteristics.
>
> I'm specifically interested in how ext2/3 will handle a /var/spool/mail
> directory w/ ~6000 mbox format inboxes, handling approx 1GB delivered as
> 75,000 messages daily.
applied patches 1-14 to netdev-2.6. We'll let it sit there for a bit,
for testing and such. (netdev-2.6 gets auto-propagated to -mm)
Thanks for your patience and perserverance.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Apply some cleanups to the low-level orinoco handling code in
hermes.[ch]. This cleans up some error handling code, corrects an
error code to something more accurate, and also increases a timeout
value. This last can (when the hardware plays up) cause long delays
with spinlocks held, which is
Add descrptions to module parameters in the orinoco driver, and also
add permissions to allow them to be exported in sysfs.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco.c
===
---
Reformats printk()s, comments, labels and other cosmetic strings in
the orinoco driver. Also moves, removes, and adds ratelimiting in
some places. Behavioural changes are trivial/cosmetic only. This
reduces the cosmetic/trivial differences between the current kernel
version, and the CVS version
On Wed, 23 Feb 2005, Lee Revell wrote:
> On Wed, 2005-02-23 at 20:53 +, Hugh Dickins wrote:
> > On Wed, 23 Feb 2005, Hugh Dickins wrote:
> > > Please replace by new patch below, which I'm now running through lmbench.
> >
> > That second patch seems fine, and I see no lmbench regression from
Dear all
I am new to this place, Please correct me if i am wrong.
Before console_init, printk is just filling up the printk buffer.
After console_init, will the message print out immediately?
best regard
Mike,Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Hi,
Can you please let me know, what all files does the OS look into to
load modules?
I see the following messages during boot rather installation:
==
Finished bus probing
modules to insert tg3 aic79xx
==
which files does the OS look into to load tg3 and aic79xx after
finishing bus
Mark Lord wrote:
Minor patch for new 2.6.xx sata_qstor driver attached,
as per Alexey's fine-toothed comb! :)
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
I had to apply this manually, since your mailer "corrupts" the patch by
encoding text/plain as base64. Please fix your mailer...
The ideal
> `xterm' is waiting for the other CPU to schedule a kernel thread (which is
> bound to that CPU). Once that kernel thread has done a little bit of work,
> `xterm' can terminate.
>
> But kernel threads don't run with realtime policy, so your userspace app
> has permanently starved that kernel
> But the other side of the coin is that a SCHED_FIFO userspace task
> presumably has extreme latency requirements, so it doesn't *want* to be
> preempted by some routine kernel operation. People would get irritated if
> we were to do that.
Just to follow up a bit. People writing apps that run
On Wed, 23 Feb 2005, Ammar T. Al-Sayegh wrote:
> - Original Message - From: "Hugh Dickins" <[EMAIL PROTECTED]>
> > though quite possibly you cannot afford
> > such experiments on this server, and will revert to 2.4 for now.
>
> The problem is that my server is already in production
>
On Thu, 24 Feb 2005, Nick Piggin wrote:
> Hugh Dickins wrote:
>
> > I'm inlining pmd and pud levels, but not pte and pgd levels.
>
> OK - that's probably sufficient for debugging. There is only so
> much that can go wrong in the middle levels...
Yes, that was my thinking.
> how does it look
>
On Thu, 2005-02-24 at 05:12 +, Hugh Dickins wrote:
> On Thu, 24 Feb 2005, Nick Piggin wrote:
> > OK after sleeping on it, I'm warming to your way.
> >
> > I don't think it makes something like David's modifications any
> > easier, but mine didn't go a long way to that end either. And
> >
1. Rationale
Currently the Linux kernel implements a hierachical page table utilizing 4
layers. Architectures that have less layers may cause the kernel to not
generate code for certain layers. However, there are other means for mmu
to describe page tables to the system. For example
Hi,
here are some changes that freshen I8K driver (Dell Inspiron/Latitude
platform driver). The patches have been tested on Inspiron 8100.
i8k-lindent.patch
- pass the driver through Lindent to comply with CondingStyle requirements
(4 spaces vs. TAB indentation)
i8k-use-dmi.patch
- use
501 - 600 of 634 matches
Mail list logo
