This patch adds pci_add_bus() for PCI bus registration. It also moves
pci_remove_bus() from remove.c to bus/bus.c for consistency.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/bus.c 2005-07-12 00:59:58.0 -0400
+++ b/drivers/pci/bus/bus.c 2005-07-12
This patch moves all device registration related functions to
bus/device.c.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/device.c 1969-12-31 19:00:00.0 -0500
+++ b/drivers/pci/bus/device.c 2005-07-12 01:32:41.0 -0400
@@ -0,0 +1,187 @@
+/*
+ * de
This patch adds a basic PCI<->PCI bridge driver that utilizes the new
PCI bus class API.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/pci-bridge.c 1969-12-31 19:00:00.0 -0500
+++ b/drivers/pci/bus/pci-bridge.c 2005-07-08 02:18:43.0 -
This patch prevents the root bridge drivers from using the legacy API.
It also updates the PCI<->PCI bridge driver to better coexist with the
legacy code.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/pci-bridge.c 2005-07-14 02:17:04.735566464 -0400
+++ b
to the PCI bus class driver and PCI device
detection in general.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/Makefile 2005-07-08 17:06:19.0 -0400
+++ b/drivers/pci/Makefile 2005-07-10 22:32:53.0 -0400
@@ -2,9 +2,9 @@
# Makefile for the PCI bus
The PCI bridge driver now checks if changing bridge_ctrl is necessary.
It also restores the original bridge_ctl settings when finished scanning
for devices. Finally, a pci_bus setup fix is included.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/pci-bridge.c 2005
This patch prevents the PCI<->PCI bridge driver from binding to PCI
express devices. This is needed to coexist with the PCI express root
port driver. Eventually we may want to rework and better integrate
linux PCI express link support, but for now this should work.
Signed-off-by: Adam
On Thu, 2005-07-14 at 12:33 -0700, Greg KH wrote:
> On Thu, Jul 14, 2005 at 04:55:12AM -0400, Adam Belay wrote:
> > +EXPORT_SYMBOL(pci_add_bus);
>
> This doens't need to be exported, right? No module uses it. But if
> they do, I suggest EXPORT_SYMBOL_GPL() instead,
On Thu, 2005-07-14 at 12:30 -0700, Greg KH wrote:
> On Thu, Jul 14, 2005 at 07:10:14PM +0200, Francois Romieu wrote:
> > Adam Belay <[EMAIL PROTECTED]> :
> > [...]
> >
> > Some nits + a suspect error branch. It seems nice otherwise.
>
> If I'm
On Fri, 2005-07-15 at 09:58 +0100, Russell King wrote:
> On Thu, Jul 14, 2005 at 04:55:19AM -0400, Adam Belay wrote:
> > This patch adds a basic PCI<->PCI bridge driver that utilizes the new
> > PCI bus class API.
>
> Thanks. I think this breaks Cardbus.
>
>
hugetlb_pte_fault().
Diffed against 2.6.13-rc4-git4
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
fs/hugetlbfs/inode.c|5 -
include/linux/hugetlb.h |2
mm/hugetlb.c| 140 +++-
mm/memory.c |7 --
4 files c
On Fri, 2005-08-05 at 10:53, Andi Kleen wrote:
> On Fri, Aug 05, 2005 at 10:21:38AM -0500, Adam Litke wrote:
> > Below is a patch to implement demand faulting for huge pages. The main
> > motivation for changing from prefaulting to demand faulting is so that
> > huge page a
On Fri, 2005-08-05 at 11:47, Andi Kleen wrote:
> On Fri, Aug 05, 2005 at 11:37:27AM -0500, Adam Litke wrote:
> > On Fri, 2005-08-05 at 10:53, Andi Kleen wrote:
> > > On Fri, Aug 05, 2005 at 10:21:38AM -0500, Adam Litke wrote:
> > > > Below is a patch to implement
On Fri, 2005-08-05 at 17:05, Chen, Kenneth W wrote:
> Adam Litke wrote on Friday, August 05, 2005 8:22 AM
> > Below is a patch to implement demand faulting for huge pages. The main
> > motivation for changing from prefaulting to demand faulting is so that
> > huge page alloc
hat Pat's no longer the driver core maintainer? :)
>
> Anyway, Russell and Adam, any objections to this patch?
I'm not sure if I agree with this patch. "struct resource" is used primarily
for
I/O resource assignment. Although I agree we may need to add new IORESOURC
}
}
Thanks
AGL
--
Adam Langley [EMAIL PROTECTED]
http://www.imperialviolet.org (+44) (0)7906 332512
PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60
-
To unsubscribe from this list: send the line "unsubscribe li
On 8/12/05, Adam Langley <[EMAIL PROTECTED]> wrote:
> Waiting for edge triggered events (with EPOLLET) on pseudo terminal
> devices appears to act as if it were level triggered; when data is
> ready the fd is always returned by epoll_wait.
This occurs because writing to the term
ctures if we reach a consensus.
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
pgtable.h | 51 ++-
1 files changed, 34 insertions(+), 17 deletions(-)
diff -upN reference/include/asm-i386/pgtable.h
current/include/asm-i386/pgtable.h
--- reference/
ritable mmap, to see if that
> >> works ok or triggers a deadlock ?
> >
> >
> > I can, but lets finish addressing one issue at a time. Last time,
> > I changed too many things at the same time and got no where :(
>
> Adam is working that one, but not over iSC
ell and hence my
> > original posts about this in the NCQ thread.
>
> Have you (or has anybody else) also seen the wrong behavior of the
> activity LED?
Yes, Dell Precision 380, ICH7R AHCI controller, SATA non-NCQ Western
Digital drive.
Adam
signature.asc
Description: This is a digitally signed message part
On Thu, 2005-08-18 at 22:49 +0200, Pavel Machek wrote:
> Please make it "echo 1 > frozen", then userspace can do "echo 0 > frozen"
> after five seconds.
What if the code to do "echo 0 > frozen" is swapped out to disk? ;)
Thanks,
Adam
signatur
objection to making HIDIOCSREPORT
synchronous as well.
--Adam
-
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 http://www.tux.org/lkml/
Hi Andrew. The following 3 patches update the i386 and x86_64 hugetlb
arch code to bring it closer to the other architectures. The first
patch adds a pte_huge() macro. The second patch moves the "stale pte"
check into huge_pte_alloc() which seems more appropriate to me. The
third patch checks f
ainst 2.6.13-rc6-git7
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
asm-i386/pgtable.h |4 +++-
asm-x86_64/pgtable.h |3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff -upN reference/include/asm-i386/pgtable.h
current/include/asm-i386/pgtable.h
--- reference/inclu
Initial Post (Wed, 17 Aug 2005)
For demand faulting, we cannot assume that the page tables will be populated.
Do what the rest of the architectures do and test p?d_present() while walking
down the page table.
Diffed against 2.6.13-rc6
Signed-off-by: Adam Litke <[EMAIL PROTEC
g huge pages
later in the series.
Diffed against 2.6.13-rc6
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
arch/i386/mm/hugetlbpage.c | 13 +++--
mm/hugetlb.c |2 --
2 files changed, 11 insertions(+), 4 deletions(-)
diff -upN reference/arch/i386/mm/hugetlbpage
Initial Post (Wed, 17 Aug 2005)
For demand faulting, we cannot assume that the page tables will be populated.
Do what the rest of the architectures do and test p?d_present() while walking
down the page table.
Diffed against 2.6.13-rc6
Signed-off-by: Adam Litke <[EMAIL PROTEC
g huge pages
later in the series.
Diffed against 2.6.13-rc6
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
arch/i386/mm/hugetlbpage.c | 13 +++--
mm/hugetlb.c |2 --
2 files changed, 11 insertions(+), 4 deletions(-)
diff -upN reference/arch/i386/mm/hugetlbpage
ainst 2.6.13-rc6-git7
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
asm-i386/pgtable.h |4 +++-
asm-x86_64/pgtable.h |3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff -upN reference/include/asm-i386/pgtable.h
current/include/asm-i386/pgtable.h
--- reference/inclu
t; - return -EIO;
> + extern void nbd_request_wrong_size(void);
> + nbd_request_wrong_size();
BUILD_BUG_ON(sizeof(struct nbd_request) != 28);
...perhaps?
--Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
I get the following:
LD .tmp_vmlinux1
mm/built-in.o: In function `zone_watermark_ok':
mm/page_alloc.c:763: undefined reference to `delay_prefetch'
mm/built-in.o: In function `swap_setup':
mm/swap.c:485: undefined reference to `prepare_prefetch'
make: *** [.tmp_vmlinux1] Error 1
--
Adam Petaccia <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Oops, forgot the config file...
On Tue, 2005-09-06 at 14:25 -0400, Adam Petaccia wrote:
> On Mon, 2005-09-05 at 23:44 +1000, Con Kolivas wrote:
> > These are patches designed to improve system responsiveness and
> > interactivity.
> > It is configurable to any workload but
I am sending out the latest set of patches for hugetlb demand faulting.
I've incorporated all the feedback I've received from previous
discussions and I think this is ready for some more widespread testing.
Is anyone opposed to spinning this in -mm as it stands?
The three patches:
1) Remove a get
ml.org/lkml/2004/4/13/176 , which contains more opinions about the
correctness of this approach.
Diffed against 2.6.13-git6
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
memory.c |5 -
1 files changed, 5 deletions(-)
diff -upN reference/mm/memory.c current/mm/memory.c
--- refer
s underway and builds on
what this patch starts.
Huge page shared memory segments are simpler and still maintain their commit on
shmget semantics.
Diffed against 2.6.13-git6
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
inode.c | 47 +++
1 f
fault handler. The bulk of the patch just moves the logic from
hugelb_prefault() to hugetlb_pte_fault().
Diffed against 2.6.13-git6
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
fs/hugetlbfs/inode.c|6 --
include/linux/hugetlb.h |2
mm/hugetlb.c
On Wed, 2005-09-07 at 10:33 +0800, Zhang, Yanmin wrote:
> >>-Original Message-
> >>From: [EMAIL PROTECTED]
> >>[mailto:[EMAIL PROTECTED] On Behalf Of Adam Litke
> >>Sent: Wednesday, September 07, 2005 5:59 AM
> >>To: linux-kernel@vger.kernel.org
On Wed, 2005-09-07 at 20:41 +1000, Con Kolivas wrote:
> On Wed, 7 Sep 2005 04:25, Adam Petaccia wrote:
> > I think this patch is missing an IFDEF or something (I'm not really a
> > programmer, I just like to pretend). Anyway, I've tried building -ck2
> > without swa
that is no longer valid for
demand faulting
2) Move fault logic from hugetlb_prefault() to hugetlb_pte_fault()
3) Apply a simple overcommit check so demand fault accounting behaves
in a manner in line with how prefault worked
Diffed against 2.6.13-git6
--
Adam Litke - (agl at us.ibm.com)
IBM
ml.org/lkml/2004/4/13/176 , which contains more opinions about the
correctness of this approach.
Diffed against 2.6.13-git6
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
memory.c |5 -
1 files changed, 5 deletions(-)
diff -upN reference/mm/memory.c current/mm/memory.c
--- refer
s underway and builds on
what this patch starts.
Huge page shared memory segments are simpler and still maintain their commit on
shmget semantics.
Diffed against 2.6.13-git6
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
inode.c | 47 +++
1 f
es the logic from
hugelb_prefault() to hugetlb_pte_fault().
Diffed against 2.6.13-git6
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
fs/hugetlbfs/inode.c|6 -
include/linux/hugetlb.h |2
mm/hugetlb.c| 154 +---
x27;m not subscribed to the list.
Mathias Adam
--- linux-2.6.13-org/drivers/serial/8250.c 2005-08-29 01:41:01.0
+0200
+++ linux-2.6.13/drivers/serial/8250.c 2005-09-09 02:16:49.0 +0200
@@ -1665,7 +1665,7 @@
struct uart_8250_port *up = (struct uart_8250_port *
Stefan Smietanowski wrote:
> Mathias Adam wrote:
> > Currently serial8250_set_termios() refuses to program a baud rate larger
> > than uartclk/16. However the 16C950 supports baud rates up to uartclk/4.
> > This worked already with Linux 2.4 so the biggest part of this patch
Russell King wrote:
> On Fri, Sep 09, 2005 at 04:49:27AM +0200, Mathias Adam wrote:
> > + if (up->port.type == PORT_16C950) {
> > + unsigned int baud_base = port->uartclk/16;
>
> baud_base appears unused.
you're right, it's not necessary anymore.
make the pte writable, it notes the presence of the pte
and continues.
This simple one-liner makes sure we also fault on the pte for this case.
Please apply.
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
Acked-by: Dave Kleikamp <[EMAIL PROTECTED]>
---
mm/hugetlb.c |2 +-
1 file
an official request for big endian support for the 3w- driver or
are you looking for anybody who has a packed 'wait_queue_head_t' and
submitting a patch to fix it?
-Adam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
in my latest dynamic pool resizing
patchset which I will send out soon.
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
mm/hugetlb.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 84c795e..7af3908 100644
--- a/mm/hugetl
e_huge_pages)
> count = free_huge_pages;
> try_to_free_nr_huge_pages(count);
>
> I feel a bit sketchy about the "resv_huge_pages + nr_huge_pages -
> free_huge_pages" logic. Could you elaborate a bit there on what the
> rules are?
The key i
his is a standalone fix suitable for
mainline. It is also now corrected in my latest dynamic pool resizing
patchset which I will send out soon.
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
Acked-by: Ken Chen <[EMAIL PROTECTED]>
---
mm/hugetlb.c |8 +++-
1 files changed,
These types define the size of data read from /dev/apm_bios. They
should not be hidden behind #ifdef __KERNEL__.
---
include/linux/apm_bios.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/apm_bios.h b/include/linux/apm_bios.h
index 9754baa..01a6244 10
On Wed, 2007-12-12 at 02:47 -0800, Andrew Morton wrote:
> On Fri, 30 Nov 2007 15:02:43 -0500 Adam Jackson <[EMAIL PROTECTED]> wrote:
> > These types define the size of data read from /dev/apm_bios. They
> > should not be hidden behind #ifdef __KERNEL__.
>
>
4WS2, max UDMA/33
ata1.00: configured for UDMA/33
ata2: port disabled. ignoring.
scsi 1:0:0:0: CD-ROMMemorex 52MAXX 3252AJ1 4WS2 PQ: 0 ANSI: 5
if this works then it really needs to move and be renamed. I am compiling with
DEV_SR set.
Just my $0.02 but may be worth more or
> From: [EMAIL PROTECTED]
>>if this works then it really needs to move and be renamed. I am compiling
>> with DEV_SR set.
>>
> That fixed me right up, Adam, & k3b is once again as happy as a clam.
Fixed it for me too. I just realized the default config in 2.6.2
On Mon, 2005-03-21 at 19:32, Andrew Morton wrote:
> Adam Belay <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 2005-03-11 at 17:35 -0800, Andrew Morton wrote:
> > > Felix von Leitner <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Finally Centrino
On Mon, 7 Feb 2005, Carl-Daniel Hailfinger wrote:
And how many competing implementations of video helpers/emulation code
do we have now?
- scitechsoft emu
- linuxbios emu
- etc. (I surely forgot some)
just a minor nit-pick. "linuxbios" is not an "emulator" but drop-in
replacement for commerical bi
&drv->link) < 0))
+ return count;
+
spin_lock(&pnp_lock);
list_add_tail(&drv->global_list, &pnp_card_drivers);
spin_unlock(&pnp_lock);
- pnp_register_driver(&drv->link);
list_for_each_safe(pos,temp,&pnp_cards){
w static configuration values
before probing the device. Currently "driver_data" fills this role.
Perhaps we need a new mechanism that would be more useable with sysfs?
The current code is limiting because the configuration options in
"driver_data" are not well defined. Any ideas
On Thu, 2005-02-10 at 00:41 -0800, Greg KH wrote:
> On Fri, Jan 28, 2005 at 05:30:04PM -0500, Adam Belay wrote:
> > Hi,
> >
> > This patch adds initial support for driver matching priorities to the
> > driver model. It is needed for my work on converting the pci bridg
On Thu, 2005-02-10 at 10:12 -0800, Greg KH wrote:
> On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > On Thu, 2005-02-10 at 00:41 -0800, Greg KH wrote:
> > > On Fri, Jan 28, 2005 at 05:30:04PM -0500, Adam Belay wrote:
> > > > Hi,
> > > >
&
On Thu, 2005-02-10 at 13:46 -0500, Dmitry Torokhov wrote:
> On Thu, 10 Feb 2005 10:33:38 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > >
> > > The second "*match" function in "struct d
On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
> On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > > I think the issue that Al raises about drivers grabbing devices, and
> > > then trying to unbind them might be a real problem.
> >
> > I
On Fri, 21 Jan 2005, Catalin(ux aka Dino) BOIE wrote:
I really suggest to push this limit to 4k. My reason is that under UML I need
to put a lot of stuff in command line and uml crash if I not extend this
limit. Can we make it depend on arhitecture?
another nice feature would be the kernel ignori
On Sun, 13 Feb 2005, Matthew Jacob wrote:
I'm curious why you'd have a non-compete for 1 year for just using BK.
Larry likes to participate in flamewars on LKML ? :-)
That would make BK more or less unique amongst packages, no?
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
Mac OS X has a similar thing, with a pretty simple description of how
they do it:
http://developer.apple.com/technotes/tn/tn1150.html#HotFile
Adam
On Tue, 2005-02-15 at 13:56 -0600, Linas Vepstas wrote:
> On Tue, Feb 15, 2005 at 12:43:29AM +0100, Diego Calleja was heard to rem
On Wed, 26 Jan 2005, Robert W. Fuller wrote:
Has anybody ported Linux to a virtual machine? Does anybody have any
pointers aside from the lkml's abbreviated FAQ entry concering porting
to a new processor? What would be the best way of going about this?
Is there a supported architecture that is
all in kernel drivers first, and then begin
matching them to hardware. Do you agree? If so, I'd be happy to make a
patch for that too.
Thanks,
Adam
--- a/drivers/base/bus.c2005-01-20 17:37:46.0 -0500
+++ b/drivers/base/bus.c2005-01-28 16:59:00.0 -0500
@@ -286,6 +
very difficult to determine
without firmware assistance.
At the moment the pnp bus is only showing a logical bus relationship. If we
were to use ACPI to aid in the generation of the physical device tree, we
could put these devices in the correct physical location.
Thanks,
Adam
On Thu, Jan 27, 20
On Fri, 2005-01-28 at 18:23 -0500, Dmitry Torokhov wrote:
> On Friday 28 January 2005 17:30, Adam Belay wrote:
> > Of course this patch is not going to be effective alone. We also need
> > to change the init order. If a driver is registered early but isn't the
> >
ry, it also might explode) enumerate all of the cardbus devices.
If then later, it is discovered that there is a better driver for the
bridge, all of the bridge's children will have to be torn down. Thier
drivers will be released, and the devices removed. This might increase
the odds of som
ey do not
always have the desired effect?
Adam
--
Adam [EMAIL PROTECTED]
Lackorzynski http://os.inf.tu-dresden.de/~adam/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
On Fri, Feb 04, 2005 at 09:00:54PM +0100, matthieu castet wrote:
> Hi,
>
> this patch is based on http://bugzilla.kernel.org/show_bug.cgi?id=2962
> patch from adam belay.
>
> It solve a oops when pnp_register_driver(&ns558_pnp_driver) failed.
>
> Please apply
ould conflict with legacy
probing?
Thanks,
Adam
> So would this be the appropriate fix?
>
> --- 25/drivers/input/gameport/ns558.c~ns558-oops-fix 2005-02-04
> 19:03:11.065813120 -0800
> +++ 25-akpm/drivers/input/gameport/ns558.c2005-02-04 19:05:52.607255088
> -0800
>
On Fri, Feb 04, 2005 at 07:21:15PM -0800, Andrew Morton wrote:
> [EMAIL PROTECTED] (Adam Belay) wrote:
> >
> > It looks ok. My only concern is what would happen if the isa probe
> > succeded
> > but the pnp_register_driver failed? "pnp_register_driver" re
e Acer
> belongs to some of my users but they are not familiar with the kernel so
> I'm trying to fix this for them.
>
> Rgds
> Pierre
So the device is not listed in the DSDT, or _SRS doesn't work? Does _STA
succeed? Finally have you checked if PnPBIOS detects the device?
he values
in "struct device_driver" directly, go for it.
Thanks,
Adam
-
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 http://www.tux.org/lkml/
hi all,
I would like point to work done by Li-Ta Lo.
It allows you to completely initalize the VGA BIOS w/out using
PC BIOS at all.
http://www.clustermatic.org/pipermail/linuxbios/2005-January/010236.html
unforunatelly the information the web is somewhat spar
e compatible with the new code
9.) testing on various architectures
10.) Write "*suspend" and "*resume" routines for PCI bridges. Any ideas
on what needs to be done?
11.) fix "PCI_LEGACY" (I may have broke it, but it should be trivial)
I look forward t
On Thu, 2005-02-24 at 01:45 -0500, Jon Smirl wrote:
> On Thu, 24 Feb 2005 01:22:01 -0500, Adam Belay <[EMAIL PROTECTED]> wrote:
> > For the past couple weeks I have been reorganizing the PCI subsystem to
> > better utilize the driver model. Specifically, the bus detection co
On Thu, 2005-02-24 at 15:02 -0800, Jesse Barnes wrote:
> On Wednesday, February 23, 2005 11:03 pm, Adam Belay wrote:
>
> > > Jesse can comment on the specific support needed for multiple legacy IO
> > > spaces.
> >
> > That would be great. Most of my ex
ributes this way how
> can I remove them?
It would be possible, but probably not a clean solution. Ideally we
want one driver to bind to the graphics controller and remain bound. It
will then create class devices for each graphics subsystem, such as
framebuffer. Much work remains to be done
On Thu, 2005-02-24 at 10:03 +, Russell King wrote:
> On Thu, Feb 24, 2005 at 01:22:01AM -0500, Adam Belay wrote:
> > 5.) write a bridge driver for Cardbus hardware
>
> We have this already - it's called "yenta".
Yes, I'm aware. It should read:
5.) adapt
On Fri, 2005-02-25 at 15:38 -0800, Greg KH wrote:
> On Thu, Feb 24, 2005 at 01:22:01AM -0500, Adam Belay wrote:
> > I look forward to any comments or suggestions.
>
> I like it all :)
>
> If you want to submit patches now that rearrange the code to make it
> easier
On Fri, 2005-02-25 at 15:41 -0800, Greg KH wrote:
> On Thu, Feb 10, 2005 at 04:37:03PM -0500, Adam Belay wrote:
> > On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
> > > On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > > > > I think the i
On Mon, 2005-02-28 at 15:38 -0800, Jesse Barnes wrote:
> On Monday, February 28, 2005 3:27 pm, Adam Belay wrote:
> > How can we specify which bus to target?
>
> Maybe we could have a list of legacy (ISA?) devices for drivers like vgacon
> to
> attach to? The bus info coul
96
Swap: 1048784 52176 996608
(azz:~) vmstat
procs memoryswap io system cpu
r b w swpd free buff cache si sobibo incs us sy id
1 0 0 52184 1588 30348 224876 0 25362 153 400 68 10 22
.config
like C rather than in raw assembly.
30 years ago we didn't have C compilers that produce better code than
you can write by hand. ;)
--
Adam Sampson <[EMAIL PROTECTED]> http://azz.us-lot.org/>
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
ntk would actually
print to the screen, and module startup messages would use a
predefined prefix). Might be handy for debugging.
--
Adam Sampson <[EMAIL PROTECTED]> http://azz.us-lot.org/>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Kurt Maxwell Weber <[EMAIL PROTECTED]>:
> I'm going to take a break from lurking to point out that I am not
> dissatisfied with Windows. It has its uses, as do Linux (and NetBSD, and
> Solaris, and the other operating systems I have installed at home).
Frankly,
> I don't have a problem wit
Hua Zhong wrote:
>-> From Kurt Maxwell Weber <[EMAIL PROTECTED]> :
>
>>You can choose to work somewhere else, or choose to enter a different field.
>>
>
>There are a lot of people who don't know how to use Linux/Unix. Windows is
>much easier for them and has more applications. They practically
Paul Mundt wrote:
>On Sun, Jul 01, 2001 at 01:35:24PM -0400, Adam Schrotenboer wrote:
>
>>So as a user you are free to not use M$ products.
>>What if you are IT. Then you do not have a choice.
>>
>You always have a choice, work elsewhere. If you're in a positi
Perhaps I should say again that my current IT job is working w/ small
businesses and personal/home installations. In these cases, as well as
with others, it is not so much the OS that I have a problem w/. It is
the insistence of an all Macroshaft solution. Windows isn't totally bad.
I would ne
there was a burst of activity until the "Activating swap
partition" step, at which point the machine stopped responding. The
swap partition is /dev/hde5.
Just compiled 2.4.5-ac22 for comparison and that works fine.
Adam
-
To unsubscribe from this list: send the line "unsubscribe
Jim Roland wrote:
>[snip]
>
>>>Get real, look at all the moronic things that various linux distributions
>>>
>do.
>
>>>Is this a reason to hate linux and demand the head of Linus as
>>>
>compensation
>
>>>for your troubles?
>>>
>>>This kind of attitude, and you wonder why MS attacks linux.
>>>
>>
46 chipset is.
* That's a pretty old drive, so I wouldn't rule out hardware problems.
Strange that it only fails when not configured in the BIOS, though.
Regards,
Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
Jens,
Remember several weeks ago when I mentioned a problem w/ ridicyulous
mod-use counts w/ loop.o???
Well, it's back again 2.4.5-ac19 (IIRC) worked fine.
Basically, the result of attempting sudo losetup -d /dev/loop0 is the
following
ioctl LOOP_CLR_FD Device or resource busy
strace shows E
Greg KH <[EMAIL PROTECTED]> writes:
> - It must fix a problem that causes a build error (but not for things
>marked CONFIG_BROKEN), an oops, a hang, or a real security issue.
So a trivial patch that fixed a data corruption issue wouldn't be
accepted?
--
Adam Sampson
his and the "it must fix a problem" are basically saying the same
> thing.
No. There's an important distinction and the key word is "contain". This
rule specifically forbids patches that do fix a real problem but _also_
contain unrelated trivial changes. See "setup_
> (yes I tested it), kgdb is unresponsive -- the system hangs hard at that
> point, as far as I can determine.
>
> Kernel: tested with various 2.6.1? plus -rc* and/or -mm*, no change.
Is this still an issue with recent kernels?
Where in the PCI configuration space is it reading? In other
t legacy hardware will be less common in this architecture.
Adam
-
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 http://www.tux.org/lkml/
201 - 300 of 2101 matches
Mail list logo
