On Mon, 11 Feb 2008, Linus Torvalds wrote:
So we should probably make pcibus_to_node() be an inline function for that
case
Or, we could just do the ugliest patch ever, namely
-#define pcibus_to_node(node) (-1)
+#define pcibus_to_node(node) ((int)(long)(node),-1)
Wow
On Mon, 11 Feb 2008, Andi Kleen wrote:
Without this patch a Opteron test system here oopses at boot with currentg
git.
Calling to_pci_dev() on a NULL pointer gives a negative value so the
following NULL
pointer check never triggers and then an illegal address is referenced. Check
On Sat, 2 Feb 2008, Bartlomiej Zolnierkiewicz wrote:
* next part of IDE probing code re-organization saga
(that would be me)
This seems to cause very irritating and bogus messages for me:
Probing IDE interface ide0...
Probing IDE interface ide1...
ide2: I/O
On Mon, 10 Dec 2007, Marco Gatti wrote:
I didn't compile completly.
drivers/scsi/scsi_lib.c:1565:1: error: unterminated #else
Heh. That #else should be an #endif, of course.
It is a bit strange that it still tries to do IO to high memory. Either
the whole 64 bit capability thing in AHCI
On Tue, 4 Dec 2007, Maciej Rutecki wrote:
ata1: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 220
ata2: SATA max UDMA/133 abar [EMAIL PROTECTED] port 0xe8585180 irq 220
ata3: SATA max UDMA/133 abar [EMAIL PROTECTED] port 0xe8585200 irq 220
ata4: SATA max UDMA/133 abar
On Sun, 4 Nov 2007, Jeff Garzik wrote:
The end to CD-ROM polling... newer SATA ATAPI hardware will emit
'asynchronous notification' events when media is changed. This adds
support.
I *really* didn't want to pull this.
Not only is it after the -rc1 period, but I also think you pushed
On Tue, 30 Oct 2007, Jeff Garzik wrote:
Mikael Pettersson (2):
sata_promise: ASIC PRD table bug workaround, take 2
sata_promise: cleanups
You and Mikael need to sort out the way you send/accept patches.
Both of these commits had stuff like this:
Signed-off-by: Mikael
On Tue, 30 Oct 2007, Jeff Garzik wrote:
Can we change git-am to accept two dashes as well as three? :)
It seems pretty common, not just with Mikael but several others who send
patches to me.
Well, git-am actually used to be a lot less strict about the dashes, and
we've made it *more*
On Fri, 26 Oct 2007, Russell King wrote:
commit 8562043606430185cad26d085d46adcc7ad67fd1 is broken, causing:
CC drivers/ide/pci/cmd64x.o
CC drivers/ide/pci/hpt366.o
drivers/ide/pci/hpt366.c:1428: error: hpt366_chipsets causes a section type
conflict
and therefore should
On Wed, 29 Aug 2007, Michal Piotrowski wrote:
Clocks time
Subject : double hpet clocksource hard freeze
References : http://lkml.org/lkml/2007/8/23/257
Last known good : ?
Submitter : Paolo Ornati [EMAIL PROTECTED]
Caused-By : Tony Luck [EMAIL PROTECTED]
On Tue, 24 Jul 2007, Alan Cox wrote:
Just one version of Linux ago
The PLL code broke - oh no!
But set the right mode
And fix up the code
Makes the PLL timing sync go
Alan, I'm getting a bit worried about you.
Linus
-
To unsubscribe from
On Wed, 18 Jul 2007, Roland Dreier wrote:
BTW, I noticed one interesting thing while starting on this cleanup.
I wanted to make sure that the generated code didn't change with the
first step, and I actually discovered that the patch below seems to
make the generated code *better*, maybe
On Tue, 17 Jul 2007, Andrew Morton wrote:
(rofl, look at that mess: it was utterly impractical, unrealistic and
stupid for gcc to go and UTFify the compiler output. Sigh. LANG=C, guys).
Yeah, I absolutely *detest* how gcc does idiotic quoting just because you
happen to be in a UTF-8
On Tue, 17 Jul 2007, Roland Dreier wrote:
So setting a variable to something meaningless (guaranteeing that a
garbage value is used in case of a bug) just to shut up a warning makes
no sense -- it's no safer than leaving the code as is.
Wrong.
It's safer for two reasons:
- now
On Tue, 17 Jul 2007, Roland Dreier wrote:
I think this patch (on top of the previous one) actually makes the
code clearer
Quite frankly, calling this making the code clearer is a bit ridiculous.
That code still is absolute *crap* from a readability angle. It doesn't
follow any sane coding
On Tue, 17 Jul 2007, Roland Dreier wrote:
Anyway, here's a totally untested cleanup that compiles but probably
doesn't work, because I didn't check that I did the right thing with all
the pointer arithmetic (ie when I change wqe to a real structure pointer
instead of just a void
On Wed, 4 Jul 2007, David Woodhouse wrote:
Oh, and here's another one for you. My Bluetooth mouse just stopped
working and hidd is deadlocked...
Looks like it is stuck on hidp_session_sem.
Nothing after 2.6.21 seems to have even touched that semaphore usage, and
in fact there's not a
Looks input-related..
On Thu, 5 Jul 2007, David Woodhouse wrote:
Hm, it's not something new. It's an oops I saw occasionally in 2.6.21-rc
too, whenever we had CONFIG_SYSFS_DEPRECATED set.
Unable to handle kernel paging request for data at address 0x6b6b6b6b
Ok, that 0x6b is obviously
On Tue, 3 Jul 2007, Alan Cox wrote:
Chuck Ebbert (1):
pata_ali: fix UDMA settings
Could you please fix your git tree to have the proper credits for patches
you pull from bugzilla.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242472
I don't think it is Jeff who needs
On Wed, 27 Jun 2007, Jeff Garzik wrote:
Such would be a diagnostic that would trigger on valid SCSI commands, when the
user is doing nothing wrong and the system can indeed complete the command
just fine. Additionally, this is moving us in the direction of what the IDE
driver has
On Thu, 7 Jun 2007, Jeff Garzik wrote:
Ack'ing the sata_promise change was easy, but with this one it would
be nice to wait a bit before changing the core probe code that [now]
every ATA setup goes through, based on a single bug report.
So what's the resolution? Right now this is apparently
On Sun, 3 Jun 2007, Jeff Garzik wrote:
If we have another -rc, I would probably be OK with pushing it for 2.6.22,
otherwise I would prefer to wait for 2.6.23.
We'll definitely have another -rc. I'll push -rc4 tonight, and while I'm
hoping that we'll have resolved a number of the
On Fri, 1 Jun 2007, Jeff Garzik wrote:
I'm about to dive into some heads-down RHEL backporting (whee), so I cannot
look at the code in depth this weekend, but here are my basic thoughts:
* We knew there would be fallout from the new reset-sequence code, and this is
clearly in that
On Fri, 1 Jun 2007, Jeff Garzik wrote:
With these old PATA devices, device reset is six of one, half-dozen of the
other. Using SRST is the only way to kick some ATAPI devices into working:
http://suif.stanford.edu/~csapuntz/blackmagic.html#reset
Well, wouldn't it be a good thing to
1) if
On Fri, 1 Jun 2007, Dave Jones wrote:
There are no old drivers in F7 and beyond.
# CONFIG_IDE is not set
Ahh, that's certainly going to root out the issues. Now let's hope that
people install it..
(Fedora seems to make it hard on purpose to upgrade between major
revisions, but maybe
On Fri, 1 Jun 2007, Tejun Heo wrote:
Gregor's cdrom has broken SRST support which is extremely rare and
broken.
Well, the concept is neither rare nor arguably all that broken.
The paper standards floating around in the industry are so much toilet
paper. The only standard that seems to
On Tue, 29 May 2007, Tejun Heo wrote:
Aieee, so the drive doesn't like the new SRST sequence.
It would appear that the old code largely ignored the SRST error entirely,
no?
If we *used* to do (in ata_bus_post_reset()):
if (dev0)
ata_busy_sleep(ap,
On Sun, 27 May 2007, Gregor Jasny wrote:
2007/5/27, Jeff Garzik [EMAIL PROTECTED]:
Does the attached patch fix things?
No it doesn't. Note that I'm using ata_piix.
The commit message for that thing is badly worded. It definitely hits
ata_piix too, and it concerns a lot more than just
On Thu, 24 May 2007, Bartlomiej Zolnierkiewicz wrote:
diff --git a/drivers/ide/pci/serverworks.c b/drivers/ide/pci/serverworks.c
index 6234f80..47bcd91 100644
--- a/drivers/ide/pci/serverworks.c
+++ b/drivers/ide/pci/serverworks.c
@@ -173,7 +179,7 @@ dma_pio:
On Wed, 23 May 2007, Linus Torvalds wrote:
So please, please, please, realize that the compiler is _stupid_, and
fixing warnings without understanding the code is bad.
Btw, this is fundamental. If you don't need to understand the code, then
the compiler could have just fixed it for you
On Wed, 16 May 2007, Christoph Lameter wrote:
On Wed, 16 May 2007, Michal Piotrowski wrote:
Memory management
Subject: kernel BUG at include/linux/slub_def.h:88 kmalloc_index()
References : http://bugzilla.kernel.org/show_bug.cgi?id=8476
Submitter : Cherwin R. Nooitmeer
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
While I agree in principle with the patch, I'm a bit uncomfortable. The
sys device suspend / resume ordering is not guaranteed and relies on the
registering order.
Well, this is why we probably should try to get away from the system
device
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
Right, but clock - sources/events need to be extremly late suspended and
early resumed. How can we ensure this ?
Make them be at the top of the device tree by adding them early. That's
the whole point of the device tree after all - we have an
On Sat, 31 Mar 2007, Maxim Levitsky wrote:
So maybe I was right afrer all,
Maybe it is better to add a suspend/resume hook to each clock source and call
it from timekeeping_resume() ?
Umm.. WHy not make the device tree look like this:
-- clocksource -- +-- HPET
On Thu, 29 Mar 2007, Maxim wrote:
On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
(Or, better yet, shouldn't we set boot_hpet_disable when we decide not
to use the HPET, and set hpet_virt_address to NULL?)
This is done here
out_nohpet:
iounmap(hpet_virt_address
On Thu, 29 Mar 2007, Maxim Levitsky wrote:
Subject: Add suspend/resume for HPET
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky [EMAIL PROTECTED]
---
arch/i386/kernel/hpet.c | 68
+++
Btw, what about
On Thu, 29 Mar 2007, Maxim Levitsky wrote:
I agree, and as you said I did exactly that:
Gaah. I'm blind. Sorry. Your patch did indeed do exactly that, I somehow
overlooked it.
Linus
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a
On Wed, 28 Mar 2007, Jeff Garzik wrote:
Jeff Garzik wrote:
This disables libata ACPI, among other things.
If a -rc6 is possible, that would be quite nice...
Heh. I don't think -rc6 is possible - it's inevitable. We have too
much fallout from the timer changes still outstanding. It looks
On Wed, 28 Mar 2007, Maxim wrote:
Now I don't have a clue how to set those bits if only HPET is used as
clock source because now clocksources
don't have _any_ resume hook.
One thing that drives me wild about that clocksource resume thing is
that it seems to think that
On Wed, 28 Mar 2007, David Brownell wrote:
On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
It's a *device*, dammit. It should save and resume like one (probably as a
system device). The set_mode() etc stuff is at a completely different
(higher) conceptual level.
Agreed
On Thu, 29 Mar 2007, Maxim wrote:
I am sending here a patch that as was discussed here adds hpet to list
of system devices
and adds suspend/resume hooks this way.
I tested it and it works fine.
Ok, it certainly looks better, but it *also* looks like it just assumes
the
On Tue, 27 Mar 2007, Jeff Garzik wrote:
FWIW, I'm still leaning towards disabling libata ACPI support by default for
2.6.21.
Hey, I'm not going to argue against anything that says disable ACPI. Of
*course* it should be disabled if there aren't thousands of machines that
are in user hands
On Sat, 17 Mar 2007, Bartlomiej Zolnierkiewicz wrote:
to receive the following updates:
b/drivers/ide/Kconfig | 48 -
b/drivers/ide/Makefile |1
b/drivers/ide/arm/icside.c | 13
b/drivers/ide/ide-dma.c
On Sun, 11 Mar 2007, Paul Rolland wrote:
Nope... I tried several patches from Tejun, and also some that Jeff posted
to linux-ide, but no luck. The only way to have this DVD-RW working is to
use irqpoll on the command line...
So it has *never* worked? That's what I'm trying to see - you had
On Sun, 11 Mar 2007, Paul Rolland wrote:
My machine is having two problems : the one you are describing above,
which is due to a SIL controler being connected to one port of the ICH7
(at least, it seems to), and probing it goes timeout, but nothing is
connected on it.
Ok, so that's just a
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
On Thu, 1 Mar 2007, Alan wrote:
The patch switches the identify order so that we can do the drive side
detection correctly.
Secondly we add a -cable_detect() method called after the identify
sequence which allows a host to do host side detection at this point
should it wish, or to
On Thu, 15 Feb 2007, Jeff Garzik wrote:
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index db185f3..d51f0f1 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -22,6 +22,7 @@ config IA64
config 64BIT
bool
+ select ATA_NONSTANDARD if ATA
default y
Ok,
On Thu, 15 Feb 2007, Linus Torvalds wrote:
Ok, this is just _strange_.
Btw, I did pull, but I still think we shouldn't do those kinds of strange
Kconfig file games.
Linus
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL
On Mon, 29 Jan 2007, Mike Galbraith wrote:
The extremely unlikely winner is:
29b08d2bae854f66d3cfd5f57aaf2e7c2c7fce32 is first bad commit
Yeah, that's not going to be it. You probably had a bad kernel there
somewhere that you called good.
Git bisect is wonderful for figuring out
On Mon, 29 Jan 2007, Linus Torvalds wrote:
That said, I'm making progress with my bisection. 16 revisions left to
test after this, and three of those sixteen are
Remove unnecessary blk_queue_bounce in SG_IO
fix SG_IO bio leak
remove blk_queue_activity_fn
I've now
On Mon, 29 Jan 2007, Linus Torvalds wrote:
Two more reboots and I should know exactly which one broke nero.
This one.
However, the scary thing is that I think the patch really is correct, and
I wonder if nero has some strange work-around for an older bug.. Although
I don't see how you
Uwe, others, does this patch fix your problem?
It will have a few printk's that it spews out, but if it fixes your
problem, at least we know a bit more.
Linus
---
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 2528a0c..f0ff151 100644
--- a/block/scsi_ioctl.c
+++
On Mon, 29 Jan 2007, Mike Christie wrote:
rq-bio is NULL here, so no data is coped back to userspace and it seems
nero just stops trying to talk to the drive after this.
Well, except that's what we used to do in 2.6.19 too. So what changed?
Because nero just gives up, no more commands are
On Mon, 29 Jan 2007, Mike Christie wrote:
Ok. here is a fix with the overflow check sg.c has. Patch
was made against Linus's tree and tested with nero.
Userspace does not send us jiffies. Use msecs_to_jiffies
and check for overflow like sg.c
Signed-off-by: Mike Christie [EMAIL
[ Added Jeff, Jens and Mike Christie to Cc. I would _guess_ this is
associated with the larger block pc request stuff: Mike, Jens? James B
added for good luck.
It apparently started happening somewhere between 2.6.19 and 2.6.20-rc2,
and doing a
gitk v2.6.19..v2.6.20-rc2
On Mon, 29 Jan 2007, Mike Galbraith wrote:
Unfortunately, I'm git impaired. I am rummaging as we speak though.
Ok, I'm personally heading to bed, but it rally should be as simple as
- get the git tree in the first place
- do
git bisect good v2.6.19
git bisect bad
On Wed, 29 Nov 2006, Tejun Heo wrote:
You pushed your box really hard and the kernel can't get the memory it wants.
Not really relevant to SATA problem.
And it's not even really a bug - the caller is supposed to be ok with it.
It's a warning message that the kernel spits out just because
Jeff, what does this mean:
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: (BMDMA stat 0x21)
ata1.00: tag 0 cmd 0xca Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: port is slow to respond, please be patient (Status 0xd0)
ata1: port
[ You may or may not have gotten my previous email. The kernel stayed
working, but due to the IO errors the filesystem got re-mounted
read-only, and I'm not sure that the email I sent out in that state
actually ever made it out. I suspect it didn't. ]
Jeff,
I just had a scary thing on
On Tue, 28 Nov 2006, Alan wrote:
On Tue, 28 Nov 2006 09:31:51 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
I just had a scary thing on my nice new Intel i965 box (all Intel
chipsets apart from some strange Marvell IDE interface that I'm not using
and that no driver even
On Tue, 28 Nov 2006, Jeff Garzik wrote:
Does jgarzik/libata-dev.git#upstream (don't pull, just test) work for you?
Well, since I can't really test, I don't know. This problem has happened
just once in the couple of weeks I've used that machine, and I wasn't even
doing anything strange when
On Tue, 28 Nov 2006, Jonas Lundgren wrote:
Example of what I mean with crappy performance:
dd if=/dev/zero of=test232 bs=1M count=100; time sync
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.130424 s, 804 MB/s
real 0m21.104s
Ok, that's definitely not the same
On Tue, 28 Nov 2006, Jeff Garzik wrote:
I was sorta wondering in that direction too. If its in legacy mode (PATA and
SATA smushed together), that's a possibility. But native or AHCI modes, the
channels are pretty independent (which is the nature of SATA).
Well, what I was more wondering
On Tue, 28 Nov 2006, Jeff Garzik wrote:
ap-host (struct ata_host) already has a spinlock for precisely just that...
:)
Right, but do we actually take it? I'm not seing any spin_lock's in
ata_piix.c, but I don't know the SATA layers enough to say whether upper
layers take it or not..
On Thu, 7 Jul 2005, Christoph Lameter wrote:
Here is IMHO the right way to fix this. Test for the hwif != NULL and
test for pci_dev != NULL before determining the node number of the pci
bus that the device is connected to.
I think this is pretty unreadable.
If you make it use a trivial
On Tue, 5 Jul 2005, Jens Axboe wrote:
Looks interesting, 2.6 spends oodles of times copying to user space.
Lets check if raw reads perform ok, please try and time this app in 2.4
and 2.6 as well.
I think it's just that 2.4.x used to allow longer command queues. I think
MAX_NR_REQUESTS is
67 matches
Mail list logo
