Re: drivers/pci/probe.c patch in 2.6.20.4 causes 'cannot adjust BAR0 (not I/O)' on NVidia MCP51
Adrian Bunk wrote: > It also adds PCI_BASE_ADDRESS_SPACE_IO to the flags which it didn't > without the patch. As an experiment I modified 2.6.20.4 to _only_ remove that value from the combined value for the flags and it did not help in any noticeable way. I can reliably boot and operate the machine with the original patch reversed, though. - 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/
Re: drivers/pci/probe.c patch in 2.6.20.4 causes 'cannot adjust BAR0 (not I/O)' on NVidia MCP51
Greg KH wrote: > Kevin, does 2.6.21-rc4 work properly for you? No, it seems to exhibit the same behavior. However, I should note that this laptop is not 100% stable under any kernel release anyway... in text console mode it frequently locks up tight (although not with the NVidia closed-source driver running and X started ). I tried booting 2.6.21-rc4 five times and only once did it get pass these messages during PCI probing, but it hung during the forcedeth driver initialization. I also forgot to note in my initial problem report that the PCI device being referred to in the messages is the MCP51 IDE interface (although that could have been assumed from what the patch is supposed to do). - 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/
drivers/pci/probe.c patch in 2.6.20.4 causes 'cannot adjust BAR0 (not I/O)' on NVidia MCP51
I just upgraded from 2.6.20.2 to 2.6.20.4 on my Compaq V6000 laptop, which has an NVidia core chipset. It has the MCP51 and uses it for PATA and SATA. Booting the 2.6.20.4 kernel causes two messages (and a kernel lockup) like this: :00:0d.0: cannot adjust BAR0 (not I/O) :00:0d.0: cannot adjust BAR1 (not I/O) Booting without ACPI, without APIC, without LAPIC makes no usable difference (although sometimes I will also receive a message about BAR2). This patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ed8ccee0918ad063a4741c0656fda783e02df627;hp=9e5755bce00bb563739aeb0f09932a1907521167 is the cause... backing it out results in a working 2.6.20.4 kernel on my laptop. I'll be happy to provide any assistance I can debugging this problem. Thanks. - 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/
drivers/pci/probe.c patch in 2.6.20.4 causes 'cannot adjust BAR0 (not I/O)' on NVidia MCP51
I just upgraded from 2.6.20.2 to 2.6.20.4 on my Compaq V6000 laptop, which has an NVidia core chipset. It has the MCP51 and uses it for PATA and SATA. Booting the 2.6.20.4 kernel causes two messages (and a kernel lockup) like this: :00:0d.0: cannot adjust BAR0 (not I/O) :00:0d.0: cannot adjust BAR1 (not I/O) Booting without ACPI, without APIC, without LAPIC makes no usable difference (although sometimes I will also receive a message about BAR2). This patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ed8ccee0918ad063a4741c0656fda783e02df627;hp=9e5755bce00bb563739aeb0f09932a1907521167 is the cause... backing it out results in a working 2.6.20.4 kernel on my laptop. I'll be happy to provide any assistance I can debugging this problem. Thanks. - 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/
Re: drivers/pci/probe.c patch in 2.6.20.4 causes 'cannot adjust BAR0 (not I/O)' on NVidia MCP51
Greg KH wrote: Kevin, does 2.6.21-rc4 work properly for you? No, it seems to exhibit the same behavior. However, I should note that this laptop is not 100% stable under any kernel release anyway... in text console mode it frequently locks up tight (although not with the NVidia closed-source driver running and X started G). I tried booting 2.6.21-rc4 five times and only once did it get pass these messages during PCI probing, but it hung during the forcedeth driver initialization. I also forgot to note in my initial problem report that the PCI device being referred to in the messages is the MCP51 IDE interface (although that could have been assumed from what the patch is supposed to do). - 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/
Re: drivers/pci/probe.c patch in 2.6.20.4 causes 'cannot adjust BAR0 (not I/O)' on NVidia MCP51
Adrian Bunk wrote: It also adds PCI_BASE_ADDRESS_SPACE_IO to the flags which it didn't without the patch. As an experiment I modified 2.6.20.4 to _only_ remove that value from the combined value for the flags and it did not help in any noticeable way. I can reliably boot and operate the machine with the original patch reversed, though. - 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/
Re: [request for inclusion] Filesystem in Userspace
Andrew Morton wrote: - cachefs is a bit stuck because it's a ton of complex code and afs is the only user of it. Wiring it up to NFS would help. Yes, please! I have an application for CacheFS between an NFS client and server (all Linux) very soon :-) - 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/
Re: [request for inclusion] Filesystem in Userspace
Andrew Morton wrote: - cachefs is a bit stuck because it's a ton of complex code and afs is the only user of it. Wiring it up to NFS would help. Yes, please! I have an application for CacheFS between an NFS client and server (all Linux) very soon :-) - 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/
Re: [BK] upgrade will be needed
Dmitry Torokhov wrote: It's not too bad as you just hardlink most of the trees to their parent. Yes, and disk space is cheap. I think there is a setting to have them checked out for editing automatically. Yes there is, plus most decent editors are SCCS-aware and will prompt for a checkout when you try edit a locked file anyway (emacs certainly does, without any add-on modules). - 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/
Re: [BK] upgrade will be needed
Dmitry Torokhov wrote: It's not too bad as you just hardlink most of the trees to their parent. Yes, and disk space is cheap. I think there is a setting to have them checked out for editing automatically. Yes there is, plus most decent editors are SCCS-aware and will prompt for a checkout when you try edit a locked file anyway (emacs certainly does, without any add-on modules). - 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/
2.4.7-pre7 natsemi network driver random pauses
I upgraded two machines here from 2.4.7-pre6 to 2.4.7-pre7 yesterday afternoon. The first machine I upgraded, my workstation, is a 1GHz Athlon on a VIA KT133 (not A) motherboard using a NetGear FA312TX network card. This machine has always run Linux just fine. After this upgrade, telnetting to my other Linux machine (not yet upgraded) and doing long directory listings (or tar tzvf linux-2.4.0.tar) exhibits random (and long) pauses in the output. Switching back to 2.4.7-pre6 makes the problem disappear. Note that at this time only the _client_ end of this connection had been upgraded to -pre7. I then upgraded my server as well, which is a 700 MHz Coppermine Celeron on an SIS 630 motherboard, also using a NetGear FA312TX network card. Now this machine exhibits the same symptoms, even when the telnet client is on a Windows machine. So, it appears that one of two things happened: a) the natsemi driver had changes merged between -pre6 and -pre7 (not listed in the changelogs) that had negative effects on my systems b) something else in the kernel caused irq/softirq/whatever random latency to appear Any ideas where I should start looking? - 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/
2.4.7-pre7 natsemi network driver random pauses
I upgraded two machines here from 2.4.7-pre6 to 2.4.7-pre7 yesterday afternoon. The first machine I upgraded, my workstation, is a 1GHz Athlon on a VIA KT133 (not A) motherboard using a NetGear FA312TX network card. This machine has always run Linux just fine. After this upgrade, telnetting to my other Linux machine (not yet upgraded) and doing long directory listings (or tar tzvf linux-2.4.0.tar) exhibits random (and long) pauses in the output. Switching back to 2.4.7-pre6 makes the problem disappear. Note that at this time only the _client_ end of this connection had been upgraded to -pre7. I then upgraded my server as well, which is a 700 MHz Coppermine Celeron on an SIS 630 motherboard, also using a NetGear FA312TX network card. Now this machine exhibits the same symptoms, even when the telnet client is on a Windows machine. So, it appears that one of two things happened: a) the natsemi driver had changes merged between -pre6 and -pre7 (not listed in the changelogs) that had negative effects on my systems b) something else in the kernel caused irq/softirq/whatever random latency to appear Any ideas where I should start looking? - 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/
Re: [BUG?] vtund broken by tun driver changes in 2.4.6
Recompile your VTUND daemon with the new kernel headers (and also updated to 2.5 vtund, it has some small patches) and you will be fine. - Original Message - From: "Ryan Mack" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, July 07, 2001 1:02 AM Subject: [BUG?] vtund broken by tun driver changes in 2.4.6 > I recently upgraded a server running vtund 2.4 (4/18/01) to stock 2.4.6 > kernel. It seems the changes to the tun driver have broken vtund. Now my > syslog gets filled with the following messages when a client attempts to > connect: > > Jul 5 10:15:53 mackman vtund[4011]: Session > mackman-vpn[64.169.117.25:2359] opened > Jul 5 10:15:53 mackman vtund[4011]: Can't allocate tun device. File > descriptor in bad state(77) > Jul 5 10:15:53 mackman vtund[4011]: Session mackman-vpn closed > Jul 5 10:16:04 mackman vtund[4014]: Session > mackman-vpn[64.169.117.25:2360] opened > Jul 5 10:16:04 mackman vtund[4014]: Can't allocate tun device. File > descriptor in bad state(77) > Jul 5 10:16:04 mackman vtund[4014]: Session mackman-vpn closed > > Eventually the client gives up. Do you have any suggestions or know of > any fixes? > > Thanks, Ryan Mack > > - > 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/ > > > - 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/
Re: [BUG?] vtund broken by tun driver changes in 2.4.6
Recompile your VTUND daemon with the new kernel headers (and also updated to 2.5 vtund, it has some small patches) and you will be fine. - Original Message - From: Ryan Mack [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, July 07, 2001 1:02 AM Subject: [BUG?] vtund broken by tun driver changes in 2.4.6 I recently upgraded a server running vtund 2.4 (4/18/01) to stock 2.4.6 kernel. It seems the changes to the tun driver have broken vtund. Now my syslog gets filled with the following messages when a client attempts to connect: Jul 5 10:15:53 mackman vtund[4011]: Session mackman-vpn[64.169.117.25:2359] opened Jul 5 10:15:53 mackman vtund[4011]: Can't allocate tun device. File descriptor in bad state(77) Jul 5 10:15:53 mackman vtund[4011]: Session mackman-vpn closed Jul 5 10:16:04 mackman vtund[4014]: Session mackman-vpn[64.169.117.25:2360] opened Jul 5 10:16:04 mackman vtund[4014]: Can't allocate tun device. File descriptor in bad state(77) Jul 5 10:16:04 mackman vtund[4014]: Session mackman-vpn closed Eventually the client gives up. Do you have any suggestions or know of any fixes? Thanks, Ryan Mack - 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/ - 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/
2.4.5(-ac*] still broken NFS/Reiserfs
I've got two machines here running 2.4.5-ac6 with Chris Mason's posted 2.4.5 Reiserfs/knfsd patch, plus the small 2.4.5 NFS client patch posted last week as well. Even with all of this, I still have NFS weirdness. >From the client, I can mount and read pretty much anything I like from the server. I can create files in existing directories on the server. I can create new directories on the server. I _cannot_, however, create anything in a directory I created from the client (I get "file/directory does not exist" errors). I have also seen one case where the client's directory listing for a directory at the root of an export point did not match the server's listing until I unmounted and remounted the NFS mount. Most of the time, this problem does not occur. It's very intermittent. I can boot up my client, and it will work fine for 24 hours, or it will fail in five minutes. Once it fails, an unmount/remount seems to cure it. There is still major weirdness going on here, and I'm hesitant to try unfsd unless someone can say that it works reliably... I do need to find a solution to this though, and am willing to help in whatever way I can. - 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/
2.4.5(-ac*] still broken NFS/Reiserfs
I've got two machines here running 2.4.5-ac6 with Chris Mason's posted 2.4.5 Reiserfs/knfsd patch, plus the small 2.4.5 NFS client patch posted last week as well. Even with all of this, I still have NFS weirdness. From the client, I can mount and read pretty much anything I like from the server. I can create files in existing directories on the server. I can create new directories on the server. I _cannot_, however, create anything in a directory I created from the client (I get file/directory does not exist errors). I have also seen one case where the client's directory listing for a directory at the root of an export point did not match the server's listing until I unmounted and remounted the NFS mount. Most of the time, this problem does not occur. It's very intermittent. I can boot up my client, and it will work fine for 24 hours, or it will fail in five minutes. Once it fails, an unmount/remount seems to cure it. There is still major weirdness going on here, and I'm hesitant to try unfsd unless someone can say that it works reliably... I do need to find a solution to this though, and am willing to help in whatever way I can. - 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/
ATA/ATAPI driver development
I'm getting ready to make some changes to the ide-floppy driver (to support dynamic media change notification), and after spending a few days reviewing most of the IDE driver code (ide, ide-disk, ide-cd, ide-floppy and ide-probe), I think I've got a good handle on what needs to be done. However, since what I need to do involves sending some ATA (not ATAPI) commands to the drive, that will add some complexity to the ide-floppy driver. I'm not opposed to that, but it appears that many of the other drivers (ide, ide-disk and ide-cd) already have code to send an ATA command (writing to the registers), and interrupt handlers to handle sending or receiving the buffer(s) of data that the command wants to transfer. Is this the way it is intended to be, with this code duplicated in multiple subdrivers? The sheer complexity of the DMA interface would make me think it would be far better for this "infrastructure" stuff to all be in ide.c, and just be used by the subdrivers. I can certainly make yet another copy of the code for the few commands that ide-floppy will need to be able to issue, but before I went about that I thought I'd see if there was a better plan... Thanks for your attention. - 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/
ATA/ATAPI driver development
I'm getting ready to make some changes to the ide-floppy driver (to support dynamic media change notification), and after spending a few days reviewing most of the IDE driver code (ide, ide-disk, ide-cd, ide-floppy and ide-probe), I think I've got a good handle on what needs to be done. However, since what I need to do involves sending some ATA (not ATAPI) commands to the drive, that will add some complexity to the ide-floppy driver. I'm not opposed to that, but it appears that many of the other drivers (ide, ide-disk and ide-cd) already have code to send an ATA command (writing to the registers), and interrupt handlers to handle sending or receiving the buffer(s) of data that the command wants to transfer. Is this the way it is intended to be, with this code duplicated in multiple subdrivers? The sheer complexity of the DMA interface would make me think it would be far better for this infrastructure stuff to all be in ide.c, and just be used by the subdrivers. I can certainly make yet another copy of the code for the few commands that ide-floppy will need to be able to issue, but before I went about that I thought I'd see if there was a better plan... Thanks for your attention. - 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/
