Implement pcim_iounmap_regions() - the opposite of
pcim_iomap_regions().
Signed-off-by: Tejun heo <[EMAIL PROTECTED]>
---
This one is used by libata's new init model and generally useful for
driver midlayers. Please push it through libata-dev#upstream.
Thanks.
include/linux/pci.h |1 +
Tejun Heo wrote:
> Some platform devices are driven without driver attached, so managed
> resources can be acquired without driver attached. Make sure such
> resources are released by calling devres_release_all() in
> device_del().
>
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
> ---
> This
Paul Rolland wrote:
> Hell Tejun,
>
> I've boot-tested this yesterday, with no real luck...
>
> 1 - Tested on top of 2.6.21-rc2 (hope it's fine for you),
> 2 - Collected a full dmesg before and after
>
> Extract is :
> ata7: PATA max UDMA/100 cmd 0x00019c00 ctl 0x00019882 bmdma
Philipp Matthias Hahn wrote:
> Hello Tejun!
>
> On Tue, Mar 06, 2007 at 12:46:07AM +0900, Tejun Heo wrote:
>> Philipp Matthias Hahn wrote:
>>> On Mon, Mar 05, 2007 at 01:10:10PM +0900, Tejun Heo wrote:
* Does applying the attached patch over unpatched 2.6.20.1 fix the problem?
>>> Yes, it
Robert Hancock wrote:
Commit 721449bf0d51213fe3abf0ac3e3561ef9ea7827a added support for using the
ADMA notifier bits to determine which commands to check for completion.
However there have been reports that this causes command timeouts in
certain
cases. This is still being investigated. In
Tejun Heo wrote:
Some platform devices are driven without driver attached, so managed
resources can be acquired without driver attached. Make sure such
resources are released by calling devres_release_all() in
device_del().
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
This one fixes oops
Alan Cox wrote:
Add suspend/resume support
Write 0x5B to 0 not 0x5C
The former is important as we must kill the FIFO on a resume
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
applied
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Tejun Heo wrote:
Implement pcim_iounmap_regions() - the opposite of
pcim_iomap_regions().
Signed-off-by: Tejun heo <[EMAIL PROTECTED]>
---
This one is used by libata's new init model and generally useful for
driver midlayers. Please push it through libata-dev#upstream.
Thanks.
Jeff Garzik wrote:
[EMAIL PROTECTED] wrote:
From: Robert Hancock <[EMAIL PROTECTED]>
Reading from the ATA shadow registers while we are in ADMA mode may cause
undefined behavior. Don't read the ATA status register when completing
commands for this reason, it shouldn't be needed as the
On Friday 09 March 2007 14:27, you wrote:
> Jeff Garzik wrote:
> > [EMAIL PROTECTED] wrote:
> >> From: Robert Hancock <[EMAIL PROTECTED]>
> >>
> >> Reading from the ATA shadow registers while we are in ADMA mode may
> >> cause undefined behavior. Don't read the ATA status register when
> >>
Discussed for 2.6.21, but pushed back because the current SATA code
had enough fun stuff to debug already. Thus, just queued the following
for 2.6.22 in libata-dev.git#upstream.
The nasty request_resource hack is finally gone.
In practical terms, this usually means that some combined mode
Jeff Garzik wrote:
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 066689c..0a19466 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -779,40 +779,16 @@ int ata_pci_init_one (struct pci_dev *pdev, struct
ata_port_info **port_info,
/*
> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
and you can remove even more code as pci_request_resources() will now
just do the right thing for all cases.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c| 11 +++
drivers/ata/libata-core.c | 19 ---
drivers/ata/sata_nv.c |8
Alan Cox wrote:
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
and you can remove even more code as pci_request_resources() will now
just do the right thing for all cases.
pci_request_regions() you mean?
Jeff
-
To unsubscribe from this
On Friday, March 9, 2007 8:01 am Jeff Garzik wrote:
> Discussed for 2.6.21, but pushed back because the current SATA code
> had enough fun stuff to debug already. Thus, just queued the
> following for 2.6.22 in libata-dev.git#upstream.
>
> The nasty request_resource hack is finally gone.
>
>
On Friday 09 March 2007, Jeff Garzik wrote:
>
> Discussed for 2.6.21, but pushed back because the current SATA code
> had enough fun stuff to debug already. Thus, just queued the following
> for 2.6.22 in libata-dev.git#upstream.
>
> The nasty request_resource hack is finally gone.
>
> In
Hi.
This update gives a new warning:
libata version 2.20 loaded.
ata_piix :00:1f.1: version 2.10ac1
ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x000118c0 irq 14
ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x000118c8 irq 15
scsi0 : ata_piix
ata1.00: ATA-6:
Fabio Comolli wrote:
Hi.
This update gives a new warning:
libata version 2.20 loaded.
ata_piix :00:1f.1: version 2.10ac1
ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x000118c0
irq 14
ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x000118c8
irq 15
scsi0 :
Hi,
On Friday 09 March 2007, Uwe Bugla wrote:
> Hello Bart, hello everybody,
>
> As requested I applied the following patch with parameter -R against 2.6.20:
> http://kernel.org/pub/linux/kernel/people/bart/ide-2.6.20.patch
>
> Result: incompilable kernel! Reason is the following hunk:
>
>
> scsi1 : ata_piix
> ata2: port disabled. ignoring.
> ata2: reset failed, giving up<--- THIS IS NEW.
>
> However, I think it's just bogus as there is ata2 is disabled on this laptop.
This is expected behaviour and it is what every controller except the
PIIX has done for some time. I'm not
Alistair John Strachan wrote:
I lean towards "yes", since it is a needed-by-hardware fix, but I also
am interested in testing feedback since it is so late in the 2.6.21-rc
game.
I would lean toward that as well, but it would be good to get some
testing from some sata_nv ADMA users to make sure
VMI is broken under COMPAT_VDSO, as Xen and other non hardware assisted
hypervisors will be. I have been working on a fix for this which works
for older glibcs that panic when the new relocatable VDSO is used.
However, I believe at this time that the fix is going to be too radical
to
Zachary Amsden wrote:
VMI is broken under COMPAT_VDSO, as Xen and other non hardware
assisted hypervisors will be. I have been working on a fix for this
which works for older glibcs that panic when the new relocatable VDSO
is used. However, I believe at this time that the fix is going to be
Hello,
Randy Dunlap wrote:
>> Erm, before I do that, could somebody explain what
>>
>> #define HAVE_PCI_REQ_REGIONS 2
>>
>> accompanying their declaration is for? I have't found any references to it
>> in
>> the source. Should I duplicate it for CONFIG_PCI=n case (I guess not)?
>
> I
* Kok, Auke <[EMAIL PROTECTED]> 2007-02-08 16:09
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 455d589..42b635c 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1477,6 +1477,49 @@ gso:
> skb->tc_verd = SET_TC_AT(skb->tc_verd,AT_EGRESS);
> #endif
> if (q->enqueue) {
* Kok, Auke <[EMAIL PROTECTED]> 2007-02-08 16:09
>
> From: Peter Waskiewicz Jr. <[EMAIL PROTECTED]>
>
> Several newer e1000 chipsets support multiple RX and TX queues. Most
> commonly, 82571's and ESB2LAN support 2 rx and 2 rx queues.
>
> Signed-off-by: Peter Waskiewicz Jr. <[EMAIL PROTECTED]>
Probably should copy me and [EMAIL PROTECTED] Other than
that, this looks fine to me. I'll queue it up shortly.
John
On Fri, Mar 09, 2007 at 01:11:46PM +1100, Tony Breeds wrote:
> On Wed, Mar 07, 2007 at 03:00:57PM -0800, Andrew Morton wrote:
> > On Wed, 7 Mar 2007 23:41:16 +0100
> > Adrian
Auke Kok wrote:
From: Auke Kok <[EMAIL PROTECTED]>
DEBUG_SHIRQ code exposed that e1000 was not ready for incoming interrupts
after having called pci_request_irq. This obviously requires us to finish
our software setup which assigns the irq handler before we request the
irq.
Signed-off-by: Auke
Josh Triplett wrote:
pktgen currently only works on network devices with type ARPHRD_ETHER. Add
support for the loopback device, type ARPHRD_LOOPBACK.
I've tested this on my system, using a modified pktgen.conf-1-1 with
s/eth1/lo/g, and it works fine; the network device statistics confirm
Jeff Garzik wrote:
Auke Kok wrote:
From: Auke Kok <[EMAIL PROTECTED]>
DEBUG_SHIRQ code exposed that e1000 was not ready for incoming interrupts
after having called pci_request_irq. This obviously requires us to finish
our software setup which assigns the irq handler before we request the
irq.
On Fri, 9 Mar 2007 09:19:07 -0500 John W. Linville wrote:
> Probably should copy me and [EMAIL PROTECTED] Other than
> that, this looks fine to me. I'll queue it up shortly.
>
> John
>
> On Fri, Mar 09, 2007 at 01:11:46PM +1100, Tony Breeds wrote:
> > On Wed, Mar 07, 2007 at 03:00:57PM -0800,
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/3c59x.c | 28 -
drivers/net/mv643xx_eth.c | 10 --
Kok, Auke wrote:
Personally, I think this is really really needed. I'm surprised that you
already didn't push this considering Andrew pulled this into -mm
immediately.
Since it affects a fragile area of e1000 for all [e1000] users, I much
prefer to err on the side of caution. I have a
> -Original Message-
> From: Thomas Graf [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 09, 2007 5:41 AM
> To: Kok, Auke-jan H
> Cc: David Miller; Garzik, Jeff; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; Waskiewicz Jr, Peter P;
> Brandeburg, Jesse; Kok, Auke; Ronciak, John
When I unplug the cable the system just stops responding to anything,
at all. No message is printed to the console when the cable is plugged
back in.
[0.00] Linux version 2.6.21-rc3 ([EMAIL PROTECTED]) (gcc version 3.4.6
(Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)) #3 SMP Fri Mar 9
Simon Arlott <[EMAIL PROTECTED]> :
> When I unplug the cable the system just stops responding to anything,
> at all. No message is printed to the console when the cable is plugged
> back in.
rtl8139_interrupt (spin_lock(>lock))
-> rtl8139_weird_interrupt
-> rtl_check_media
->
* Waskiewicz Jr, Peter P <[EMAIL PROTECTED]> 2007-03-09 11:25
> > > + }
> > > + } else {
> > > + /* We're not a multi-queue device. */
> > > + spin_lock(>queue_lock);
> > > + q = dev->qdisc;
> > > + if
> * Waskiewicz Jr, Peter P <[EMAIL PROTECTED]>
> 2007-03-09 11:25
> > > > + }
> > > > + } else {
> > > > + /* We're not a multi-queue device. */
> > > > + spin_lock(>queue_lock);
> > > > + q =
On 09/03/07 20:42, Francois Romieu wrote:
Simon Arlott <[EMAIL PROTECTED]> :
When I unplug the cable the system just stops responding to anything,
at all. No message is printed to the console when the cable is plugged
back in.
rtl8139_interrupt (spin_lock(>lock))
-> rtl8139_weird_interrupt
* Waskiewicz Jr, Peter P <[EMAIL PROTECTED]> 2007-03-09 15:27
> That's the entire point of this extra locking. enqueue() is going to
> put an skb into a band somewhere that maps to some queue, and there is
> no way to guarantee the skb I retrieve from dequeue() is headed for the
> same queue.
Jeff Garzik a écrit :
> Adrian Bunk wrote:
>> Subject: NCQ problem with ahci and Hitachi drive
>> References : http://lkml.org/lkml/2007/3/4/178
>> Submitter : Mathieu Bérard <[EMAIL PROTECTED]>
>> Status : unknown
>
> according to the last message in that thread, it sounds like ACPI and
On Sat, 2007-03-10 at 02:09 +0100, Mathieu Bérard wrote:
> Jeff Garzik a écrit :
> > Adrian Bunk wrote:
> >> Subject: NCQ problem with ahci and Hitachi drive
> >> References : http://lkml.org/lkml/2007/3/4/178
> >> Submitter : Mathieu Bérard <[EMAIL PROTECTED]>
> >> Status : unknown
> >
>
On Sat, 10 Mar 2007, Sergio Monteiro Basto wrote:
>
> With this quirk I got this oops on hibernate (but computer still
> working)
Well, strictly speaking it's a warning, not an oops per se.
What happens is that the quirk wants to do an "ioremap_nocache()", which
allocates memory, and that
Hi Rusty,
DVB code uses symbol_get/symbol_put functions at module.c to allow
dynamically add frontend modules (responsible for tuning and
demodulating the digital signal). The problem is that symbol_get doesn't
properly mark the module that requested it.
Trent worked on a fix for this, by using
Hi!
> > You're better off using the VGA console, and lettign X re-initialize the
> > graphics device. That generally at least has a reasonably good chance of
> > working.
> >
> > Re-initializing graphics modes really is very hard. You can try with the
> > BIOS video hack (I forget the kernel
1001 - 1046 of 1046 matches
Mail list logo
