RE: [RFC] Direct Sockets Support??
> But in the case of an application which fits in main memory, and > has been running for a while (so all pages are present and > dirty), all you'd really have to do is verify the page tables are > in the proper state and skip the TLB flush, right? We really cannot assume this. There are two cases a. when a user app wants to receive some data, it allocates memory(using malloc) and waits for the hw to do zero-copy read. The kernel does not allocate physical page frames for the entire memory region allocated. We need to lock the memory (and locking is expensive due to costly TLB flushes) to do this b. when a user app wants to send data, he fills the buffer and waits for the hw to transmit data, but under heavy physical memory pressure, the swapper might swap the pages we want to transmit. So we need to lock the memory to be 100% sure. - 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: [RFC] Direct Sockets Support??
But in the case of an application which fits in main memory, and has been running for a while (so all pages are present and dirty), all you'd really have to do is verify the page tables are in the proper state and skip the TLB flush, right? We really cannot assume this. There are two cases a. when a user app wants to receive some data, it allocates memory(using malloc) and waits for the hw to do zero-copy read. The kernel does not allocate physical page frames for the entire memory region allocated. We need to lock the memory (and locking is expensive due to costly TLB flushes) to do this b. when a user app wants to send data, he fills the buffer and waits for the hw to transmit data, but under heavy physical memory pressure, the swapper might swap the pages we want to transmit. So we need to lock the memory to be 100% sure. - 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: [Question] Explanation of zero-copy networking
> Then there's the interrupt problem, which someone will have to solve > before they start shipping 10gigE NICs that use 1500-byte frames, 85 > interrupts/s without mitigation. Wh In this situations polling helps rather than interrupt driven IO. When there is heavy IO(read more interrupts per sec), we should automatically switch to polling mode, once the IO drops we can go to Interrupt driven. But how do we decide when to switch modes? Just my 2 cents . - 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: [Question] Explanation of zero-copy networking
Then there's the interrupt problem, which someone will have to solve before they start shipping 10gigE NICs that use 1500-byte frames, 85 interrupts/s without mitigation. Wh In this situations polling helps rather than interrupt driven IO. When there is heavy IO(read more interrupts per sec), we should automatically switch to polling mode, once the IO drops we can go to Interrupt driven. But how do we decide when to switch modes? Just my 2 cents . - 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: [RFC] Direct Sockets Support??
>> technology is Infiniband . In Infiniband, the hardware supports IPv6 . For >> this type of devices there is no need for software TCP/IP. But for >> networking application, which mostly uses sockets, there is a performance >> penalty with using software TCP/IP over this hardware. > IPv6 is only the bottom layer of the stack. TCP does a lot lot more. Sorry to have confused you. IB supports the notion of connection over IPv6, not exactly TCP. I just interchanged TCP and notion of connection provided by infiniband. Infiniband is a cluster of technologies like VI, IP, etc. So i felt that we can take advantage of this to do networking. Because the speed of IB ranges from 2.5Gbps to 30Gbps, even a slight overhead in software will affect performance very badly. - 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: [RFC] Direct Sockets Support??
> For the case where the routing will be external. Thats conveniently > something > you can deduce in advance. In theory nothing stops you implementing this. > Conventionally you would do that with BSD sockets by implementing a new > socket family PF_INFINIBAND. You might then choose to make the selection > of that either done by the application or under it by C library overrides. > Thats exactly my point, we need to define a new protocol family to support it. This means that all applications using PF_INET needs to be changed and recompiled. My basic argument goes like this if hardware can support the notion of connection, the sockets layer should be aware of this and send all request to the hw. I can assign an IPv4 address(for sake of backward compatiblity) and get away w/o software TCP/IP.i get the performance benefit of hardware TCP/IP (notion of connection). The windoze 2000 DDK has an interesting section about WinSock direct(r) that lets the SAN hardware (like IB) to still use traditional PF_INET for it. Also one interesting whitepaper http://servernet.himalaya.compaq.com/snet2/whitepapers/WSD_Perf_White_Paper_ 3-21-01.doc - 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: [RFC] Direct Sockets Support??
> Doesn't this bypass all of the network security controls? Granted - it is > completely reasonable in a dedicated environment, but I would think the > security loss would prevent it from being used for most usage. Direct Sockets makes sense only in clustering (server farms) to reduce intra-farm communication. It is *not* supposed to be used for regular internet. Direct Sockets over subnets is also tough to implement it across different topology subnets. Fabrics like Infiniband provide security on hardware, so there is no need to worry about it. The simple point is that hw supports TCP/IP, then why do we need a software TCP/IP over it? - 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: [RFC] Direct Sockets Support??
> Define 'direct sockets' firstly. Direct Sockets is the ablity by which the application(using sockets) can use the hardwares features to provide connection, flow control, etc.,instead of the TCP and IP software module. A typical hardware technology is Infiniband . In Infiniband, the hardware supports IPv6 . For this type of devices there is no need for software TCP/IP. But for networking application, which mostly uses sockets, there is a performance penalty with using software TCP/IP over this hardware. > I have seen several lines of attack on very high bandwidth devices. > Firstly > the linux projects a while ago doing usermode message passing directly > over > network cards for ultra low latency. Secondly there was a VI based project > that was mostly driven from userspace. > The application needs to rewritten to use VIPL, but if we could provide a sockets over VI (or Sockets over IB), then the existing applications can run with a known environment. > One thing that remains unresolved is the question as to whether the very > low > cost Linux syscalls and zero copy are enough to achieve this using a > conventional socket API and the kernel space, or whether a hybrid direct > access setup is actually needed. > My point is that if the hardware is capable of doing TCP/IP , we should let the sockets layer talk directly to it (direct sockets). Thereby the application which uses the sockets will get better performance. - 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: Solution - AMI megaraid driver doesn't work with Linux 2.4.x kernels
Can you provide the dmesg output of your system after loading the driver either successfully or unsucessfully. - Original Message - From: "Rafael Martinez" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 03, 2001 11:37 AM Subject: Solution - AMI megaraid driver doesn't work with Linux 2.4.x kernels > Hei > > The Ami megatrends driver (at least for 471, 475, and 493) does not work > with 2.4.x kernels. > > The solution we got from Ami is to update the firmware of these cards to > version FW G158. This update will fix all the problems with ami > raid-devices in 2.4.x kernel without changing the driver. > > We don't know when AMI will release a fixed firmware (hope soon) but we got it by > e-mail. If there is anybody with the same problem I can sent the > firmware-update by mail. > > Sincerely > Rafael Martinez > > > - > 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: Solution - AMI megaraid driver doesn't work with Linux 2.4.x kernels
Can you provide the dmesg output of your system after loading the driver either successfully or unsucessfully. - Original Message - From: Rafael Martinez [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 03, 2001 11:37 AM Subject: Solution - AMI megaraid driver doesn't work with Linux 2.4.x kernels Hei The Ami megatrends driver (at least for 471, 475, and 493) does not work with 2.4.x kernels. The solution we got from Ami is to update the firmware of these cards to version FW G158. This update will fix all the problems with ami raid-devices in 2.4.x kernel without changing the driver. We don't know when AMI will release a fixed firmware (hope soon) but we got it by e-mail. If there is anybody with the same problem I can sent the firmware-update by mail. Sincerely Rafael Martinez - 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: [RFC] Direct Sockets Support??
Define 'direct sockets' firstly. Direct Sockets is the ablity by which the application(using sockets) can use the hardwares features to provide connection, flow control, etc.,instead of the TCP and IP software module. A typical hardware technology is Infiniband . In Infiniband, the hardware supports IPv6 . For this type of devices there is no need for software TCP/IP. But for networking application, which mostly uses sockets, there is a performance penalty with using software TCP/IP over this hardware. I have seen several lines of attack on very high bandwidth devices. Firstly the linux projects a while ago doing usermode message passing directly over network cards for ultra low latency. Secondly there was a VI based project that was mostly driven from userspace. The application needs to rewritten to use VIPL, but if we could provide a sockets over VI (or Sockets over IB), then the existing applications can run with a known environment. One thing that remains unresolved is the question as to whether the very low cost Linux syscalls and zero copy are enough to achieve this using a conventional socket API and the kernel space, or whether a hybrid direct access setup is actually needed. My point is that if the hardware is capable of doing TCP/IP , we should let the sockets layer talk directly to it (direct sockets). Thereby the application which uses the sockets will get better performance. - 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: [RFC] Direct Sockets Support??
Doesn't this bypass all of the network security controls? Granted - it is completely reasonable in a dedicated environment, but I would think the security loss would prevent it from being used for most usage. Direct Sockets makes sense only in clustering (server farms) to reduce intra-farm communication. It is *not* supposed to be used for regular internet. Direct Sockets over subnets is also tough to implement it across different topology subnets. Fabrics like Infiniband provide security on hardware, so there is no need to worry about it. The simple point is that hw supports TCP/IP, then why do we need a software TCP/IP over it? - 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: [RFC] Direct Sockets Support??
For the case where the routing will be external. Thats conveniently something you can deduce in advance. In theory nothing stops you implementing this. Conventionally you would do that with BSD sockets by implementing a new socket family PF_INFINIBAND. You might then choose to make the selection of that either done by the application or under it by C library overrides. Thats exactly my point, we need to define a new protocol family to support it. This means that all applications using PF_INET needs to be changed and recompiled. My basic argument goes like this if hardware can support the notion of connection, the sockets layer should be aware of this and send all request to the hw. I can assign an IPv4 address(for sake of backward compatiblity) and get away w/o software TCP/IP.i get the performance benefit of hardware TCP/IP (notion of connection). The windoze 2000 DDK has an interesting section about WinSock direct(r) that lets the SAN hardware (like IB) to still use traditional PF_INET for it. Also one interesting whitepaper http://servernet.himalaya.compaq.com/snet2/whitepapers/WSD_Perf_White_Paper_ 3-21-01.doc - 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: [RFC] Direct Sockets Support??
technology is Infiniband . In Infiniband, the hardware supports IPv6 . For this type of devices there is no need for software TCP/IP. But for networking application, which mostly uses sockets, there is a performance penalty with using software TCP/IP over this hardware. IPv6 is only the bottom layer of the stack. TCP does a lot lot more. Sorry to have confused you. IB supports the notion of connection over IPv6, not exactly TCP. I just interchanged TCP and notion of connection provided by infiniband. Infiniband is a cluster of technologies like VI, IP, etc. So i felt that we can take advantage of this to do networking. Because the speed of IB ranges from 2.5Gbps to 30Gbps, even a slight overhead in software will affect performance very badly. - 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: RFC: pageable kernel-segments
> > VMS does this. It at least used to have a great tendency to crash > > itself, because it swapped out something that was called from a driver > > that was called by the swapper -- resulting in deadlock. You need > > iron discipline for this to work right in all circumstances. > > Actually, VMS doesn't do this, precisely because it is so hard to get > right. VMS has both paged and non-paged pools for dynamically > allocated kernel memory, but the kernel code itself is non-pageable. [Venkat] This [pageable drivers] has been a nightware for NT (derived from VMS) driver programmers. It almost divides the set of kernel API into two halves, one which can be called at any IRQL and the other only at elevated irql. The benefits of having pageable kernel pages is very minimal when compared to the complexity that gets added to the kernel. We can keep the kernel simpler(and faster) without having parts of drivers pageable. But one more issue is having the page tables pageable... - 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: RFC: pageable kernel-segments
VMS does this. It at least used to have a great tendency to crash itself, because it swapped out something that was called from a driver that was called by the swapper -- resulting in deadlock. You need iron discipline for this to work right in all circumstances. Actually, VMS doesn't do this, precisely because it is so hard to get right. VMS has both paged and non-paged pools for dynamically allocated kernel memory, but the kernel code itself is non-pageable. [Venkat] This [pageable drivers] has been a nightware for NT (derived from VMS) driver programmers. It almost divides the set of kernel API into two halves, one which can be called at any IRQL and the other only at elevated irql. The benefits of having pageable kernel pages is very minimal when compared to the complexity that gets added to the kernel. We can keep the kernel simpler(and faster) without having parts of drivers pageable. But one more issue is having the page tables pageable... - 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: Proposal for a new PCI function call
> It seems to me that not doing #ifdef CONFIG_HIGHMEM right now is a > bug... I think it's the megaraid driver that wants to set dma_addr_t to > a 64-bit mask. MegaRAID driver: Only if the flag __LP64__ is defined, a 64 bit mask is set , otherwise only a 32 bit mask is used instead. However check for CONFIG_HIGHMEM needs to be done. - 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: Proposal for a new PCI function call
It seems to me that not doing #ifdef CONFIG_HIGHMEM right now is a bug... I think it's the megaraid driver that wants to set dma_addr_t to a 64-bit mask. MegaRAID driver: Only if the flag __LP64__ is defined, a 64 bit mask is set , otherwise only a 32 bit mask is used instead. However check for CONFIG_HIGHMEM needs to be done. - 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/
Linux driver for 3com ADSL PCI card?
Hi, I am interested in using linux driver for 3com ADSL PCI Modem Card. 3Com does not have the linux driver for it(according to thier websites and as far as i have searched). I wish to write the driver for it (ofcourse under GPL). Any pointers where i could find tech specification for it? Thanks & Cheers, Venkatesh - 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/
Linux driver for 3com ADSL PCI card?
Hi, I am interested in using linux driver for 3com ADSL PCI Modem Card. 3Com does not have the linux driver for it(according to thier websites and as far as i have searched). I wish to write the driver for it (ofcourse under GPL). Any pointers where i could find tech specification for it? Thanks Cheers, Venkatesh - 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: Microsoft begining to open source Windows 2000?
Enterprise customers are beginning to see the value of having source available, and MS is doing this as a half-baked solution to give decition makers one less reason for switching to Open Source. Microsoft such attempts can be viewed as either 1. Trying to make it sources open(in the long run) or 2. As you said a "half - baked solution" But the article mentioned about the "earlier success with the pilot program" , which made me feel that they may have more plans than making the sources open for a few customers. - 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: Microsoft begining to open source Windows 2000?
My initial thought after seeing this article was that microsoft was testing its waters on open sourcing. If i have 1500 licenses then i would get the source. If i find any bug in thier source , i would report to microsoft or send a patch and they would put it in thier next version. Is this not the same way Linux Kernel is developed?. Only thing microsoft does not want to immediately go full open sourcing and get embarrased at the hands of linux people. > -Original Message- > From: Alan Cox [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, March 08, 2001 11:06 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Microsoft begining to open source Windows 2000? > > > Please check out this article. Looks like microsoft know open source is > the > > thing of the future. I would consider that it is a begining step for > full > > blown GPL > > Oh sure > > Maybe 1200 people > > "Users are prohibited from amending" > > Sorry but Linus had > 1200 people able to modify his code in 1992 - 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/
Microsoft begining to open source Windows 2000?
Please check out this article. Looks like microsoft know open source is the thing of the future. I would consider that it is a begining step for full blown GPL http://www.zdnet.com/enterprise/stories/main/0,10228,2692987,00.html - 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/
Microsoft begining to open source Windows 2000?
Please check out this article. Looks like microsoft know open source is the thing of the future. I would consider that it is a begining step for full blown GPL http://www.zdnet.com/enterprise/stories/main/0,10228,2692987,00.html - 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: Microsoft begining to open source Windows 2000?
My initial thought after seeing this article was that microsoft was testing its waters on open sourcing. If i have 1500 licenses then i would get the source. If i find any bug in thier source , i would report to microsoft or send a patch and they would put it in thier next version. Is this not the same way Linux Kernel is developed?. Only thing microsoft does not want to immediately go full open sourcing and get embarrased at the hands of linux people. -Original Message- From: Alan Cox [SMTP:[EMAIL PROTECTED]] Sent: Thursday, March 08, 2001 11:06 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Microsoft begining to open source Windows 2000? Please check out this article. Looks like microsoft know open source is the thing of the future. I would consider that it is a begining step for full blown GPL Oh sure Maybe 1200 people "Users are prohibited from amending" Sorry but Linus had 1200 people able to modify his code in 1992 - 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: Microsoft begining to open source Windows 2000?
Enterprise customers are beginning to see the value of having source available, and MS is doing this as a half-baked solution to give decition makers one less reason for switching to Open Source. Microsoft such attempts can be viewed as either 1. Trying to make it sources open(in the long run) or 2. As you said a "half - baked solution" But the article mentioned about the "earlier success with the pilot program" , which made me feel that they may have more plans than making the sources open for a few customers. - 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:[PATCH] megaraid port from 2.2.19pre14 to 2.4.2
Hi, I have submitted the latest 1.14g driver patch for both 2.4.1pre and 2.2.19pre series. Hopefully waiting for Linus and Alan to integrate into the standard tree. Thanks Venkatesh - 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:[PATCH] megaraid port from 2.2.19pre14 to 2.4.2
Hi, I have submitted the latest 1.14g driver patch for both 2.4.1pre and 2.2.19pre series. Hopefully waiting for Linus and Alan to integrate into the standard tree. Thanks Venkatesh - 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 in AMI Raid controller, Linux 2.4
This is because the 2.2.XX contains the a later version of the
driver when compared to 2.4.1 kernel. I have submitted to Linus and Alan the
1.14g version of the driver which works for 2.2.XX and contains special code
for 2.4.XX kernels.
As the file is too large for me post to LKML i have submitted the
patch to Linus and Alan which i guess will be in the next incremental
release of both 2.2.19 and 2.4.1-pre?
Thanks,
Venkatesh
> -Original Message-
> From: Mark Grosberg [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, February 10, 2001 8:39 PM
> To: [EMAIL PROTECTED]
> Subject: Bug in AMI Raid controller, Linux 2.4
>
>
>
> Hello all, forgive me if this has already been discovered...
>
> I think I have found a bug in the AMI Megatrends RAID controller driver,
> scsi/megaraid.c.
>
> If I look in the old, 2.2.x code, in the routine mega_findCard, I find:
>
> if (flag != BOARD_QUARTZ) {
> /* Request our IO Range */
> if (check_region (megaBase, 16)) {
> printk (KERN_WARNING "megaraid: Couldn't register I/O range!" ...
> scsi_unregister (host);
> continue;
> }
> request_region (megaBase, 16, "megaraid");
>
> And in the 2.4.1 code, same routine, I find:
>
> if (flag != BOARD_QUARTZ) {
> /* Request our IO Range */
> if (request_region (megaBase, 16, "megaraid")) {
> printk (KERN_WARNING "megaraid: Couldn't register I/O range!" ...
> scsi_unregister (host);
> continue;
> }
> }
>
> I think the code is missing a "!" in front of request_region(). It seems
> that the 2.4.1 kernel does not recognize my RAID controller where as
> 2.2.x does.
>
> L8r,
> Mark G.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> 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://vger.kernel.org/lkml/
RE: Bug in AMI Raid controller, Linux 2.4
This is because the 2.2.XX contains the a later version of the
driver when compared to 2.4.1 kernel. I have submitted to Linus and Alan the
1.14g version of the driver which works for 2.2.XX and contains special code
for 2.4.XX kernels.
As the file is too large for me post to LKML i have submitted the
patch to Linus and Alan which i guess will be in the next incremental
release of both 2.2.19 and 2.4.1-pre?
Thanks,
Venkatesh
-Original Message-
From: Mark Grosberg [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 10, 2001 8:39 PM
To: [EMAIL PROTECTED]
Subject: Bug in AMI Raid controller, Linux 2.4
Hello all, forgive me if this has already been discovered...
I think I have found a bug in the AMI Megatrends RAID controller driver,
scsi/megaraid.c.
If I look in the old, 2.2.x code, in the routine mega_findCard, I find:
if (flag != BOARD_QUARTZ) {
/* Request our IO Range */
if (check_region (megaBase, 16)) {
printk (KERN_WARNING "megaraid: Couldn't register I/O range!" ...
scsi_unregister (host);
continue;
}
request_region (megaBase, 16, "megaraid");
And in the 2.4.1 code, same routine, I find:
if (flag != BOARD_QUARTZ) {
/* Request our IO Range */
if (request_region (megaBase, 16, "megaraid")) {
printk (KERN_WARNING "megaraid: Couldn't register I/O range!" ...
scsi_unregister (host);
continue;
}
}
I think the code is missing a "!" in front of request_region(). It seems
that the 2.4.1 kernel does not recognize my RAID controller where as
2.2.x does.
L8r,
Mark G.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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://vger.kernel.org/lkml/
Re: A query regarding kernel programming, very small
driver development is a part of kernel development. Kernel is a bigger entity which contains scheduler, io subsystem, memory subsystem etc Drivers comes under the IO subsystem. - Original Message - From: "Shyam Iyengar" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 31, 2001 2:54 PM Subject: A query regarding kernel programming, very small > hi, > i would like to know what exactly is meant by > kernel development. Is it only about making drivers. >I am in a big fix and i am searching the net > for the last 5 hours without a hint. > Do send me the reply as fast as possible. > Thanking you > > > > Do You Yahoo!? > Get your free @yahoo.co.in address at http://mail.yahoo.co.in > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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] Please read the FAQ at http://www.tux.org/lkml/
Re: A query regarding kernel programming, very small
driver development is a part of kernel development. Kernel is a bigger entity which contains scheduler, io subsystem, memory subsystem etc Drivers comes under the IO subsystem. - Original Message - From: "Shyam Iyengar" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 31, 2001 2:54 PM Subject: A query regarding kernel programming, very small hi, i would like to know what exactly is meant by kernel development. Is it only about making drivers. I am in a big fix and i am searching the net for the last 5 hours without a hint. Do send me the reply as fast as possible. Thanking you Do You Yahoo!? Get your free @yahoo.co.in address at http://mail.yahoo.co.in - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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] Please read the FAQ at http://www.tux.org/lkml/
Linux MegaRAID Driver Version 1.14b Release
This driver replaces version 1.07b present in the standard 2.4.0 kernel. The driver features are 1. Supports more than 4 GB Addressing (full 64 bit addressing) 2. IA32 / IA64 platform support 3. Supports 2.2.XX & 2.4.XX kernels <> m114b.tar.gz
Linux MegaRAID Driver Version 1.14b Release
This driver replaces version 1.07b present in the standard 2.4.0 kernel. The driver features are 1. Supports more than 4 GB Addressing (full 64 bit addressing) 2. IA32 / IA64 platform support 3. Supports 2.2.XX 2.4.XX kernels m114b.tar.gz m114b.tar.gz
RE: Linux not adhering to BIOS Drive boot order?
> You seem to be full of things that "we" can implement. So I just have > to wonder: do you by any chance have some prototype code somewhere to > figure out, reliably, which SCSI cards have BIOS extensions enabled, > and the order they hook in? > [Venkat] It would be a very bad idea for the linux kernel to look into the card to see whether the BIOS for that card has been enabled to make it determine the scsi drive order. If you had followed the earlier threads, the correct way to proceed would be to use labels to make things node independent. I think Andreas is working on patch for 2.2.18 and 2.4.0 kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> Of course that would be better. The only complaint I have with such a > system is that of backwards compatibility...as long as the legacy device > names are still supported i would have no problem with it at all. > > however, this brings up an interesting question: what happens if two disks > (presumably from two different machines) have the same disk label? what > happens then? for instance, i have several linux machines both at my > workplace and my home. if for some reason one of these machines dies due > to hardware failure and i want to get stuff off the drives, i put the disk > containing the /home partition on the failed machine into a working > machine and reboot. What /home gets mounted then? the original /home or > the new one from the dead machine? (and don't say end users wouldn't > possibly do that... if they are adding hardware into their systems this is > by no means beyond their capabilities) > > at least with physical device nodes i can say 'computer, you will mount > this partition on this mountpoint!' and be done with it. [Venkatesh Ramamurthy] You are getting my point exactly. This was my argument from the first, we should have a efficient mechanism to mount partitions > so tell me then, how would one discern between two partitions with the > same label? [Venkatesh Ramamurthy] If the OS detects two partitions of the same name , either dont mount both , but display an error (or) mount the first one it finds ( this is not a good idea but) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> you're forgetting that in /etc/lilo.conf there is a directive called > 'append='... all the user has to do is merely add > 'append="scsihosts=whatever,whatever"' into their config file and rerun > lilo. problem solved > > besides, how many 'end-users' do you know of that will have multiple scsi > adapters in one system? how many end-users -period- will have even a > *single* scsi adapter in their systems? do we need to bloat the kernel > with automatic things like this? no... i think it is handled fine the way > it is. if the user wants to add more than one scsi adapter into his > system, let him read some documentation on how to do so. (is this even a > documented feature? if not, i think it should be added to the docs...) [Venkatesh Ramamurthy] Dont you think that mounting and booting based on disk label names is better, then relying on device nodes which can change when a new card is added?. The existing patch for 2.2.xx is quite small and it does not bloat the kernel too much either. I think we can port it for 2.4.XX with ease.In my words it is worth the effort - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> From a layering point of view, it makes a lot more sense to
> me for the label (or signature or whatever) for this purpose
> to be in the partition table than inside the filesystem. The
> parts of the system that assign devices their identities already
> know about that part of the disk.
[Venkatesh Ramamurthy] The LILO boot loader and the LILO command
line utility should be changed for this. There are some issues when we have
different set of labels names for file system and partition table. The LILO
command line utility should make use of the disk labels of the file system
and use this for creating the partition disk label name. This is something
like assigning a label for kernel in lilo.conf. Is anybody doing this?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> Why is this a SCSI ML problem? The problem is that the OS can't figure > out > where to mount root from. Sounds like an OS problem. > I think the file system label is the leading candidate to solve this. One > > really does not care if the root disk is called /dev/sda or /dev/fred. > All > one cares is that you can boot your system and the right disks are > mounted. > What I have seen so far with the fs label this either does solve this > today or > it can solve this. I notice today on some systems the entries in > /etc/fstab > already are "deviceless" in that it does not have the disk/partition but > simply the disk label. > > Can lilo use a label for the root disk also? I have not looked into that > yet. > If it does not can it? When I noticed the use of the label in /etc/fstab > my > first thought was "alright, someone is solving this problem." I have not > taken the time - not a burning issue with me right now - to see if this is > all > done yet though. > > Keep in mind that the example where /dev/sda is where root lies is that > "easy" > case. The hard case is what happens if someone installs on /dev/sdg. Now > > they boot up with a disk array turned off. Is the mid-layer going to > figure > out that what is now /dev/sda suppose to be /dev/sdg? Or they install to > /dev/sdb and /dev/sda goes bad so they pull it out? [Venkatesh Ramamurthy] If we can truly go for label based mouting and lilo'ing this would solve the problem. Anybody doing this? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> The scsi host numbers will be allocated to the HBAs in
> the order shown starting at 0. This method does not
> distinguish between the two advansys controllers, luckily
> swapping their positions on the PCI bus does.
[Venkatesh Ramamurthy] Just think an end-user fuguring out this
Asking him to change PCI slots and trying it out. My point is the end user
should not worry about all this. All he does is plugs a new different/ same
type of card, and gets it going. Why should the linux kernel force the user
to change the PCI slots. Will this not make it more user - unfriendly
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> > Is someone handling this already?
>
> "mount by uuid"?
>
> Amiga's Rigid Disk Block?
[Venkatesh Ramamurthy] Something like this is better. The problem
is where do we store this info. Last sector is one of the options. Does
anyone know where NT stores this info?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> This is due to the fixed ordering of the scsi drivers. You can change the > order of the scsi hosts with the "scsihosts" kernel parameter. See > linux/drivers/scsi/scsi.c [Venkatesh Ramamurthy] I think it would be a nice idea if we can make this process automatic , with out user typing in the order and remembering it. The fact that a kernel developer is not using the machines daily to get his work done should be in our minds. If we do this Linux would become more user friendly > Yours, > Dominik > -- > http://petition.eurolinux.org/index_html - No Software Patents In Europe! > http://petition.lugs.ch/ (in Switzerland) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> When the cards are of different make the order is solely dependent on
> the order that the drivers are initialized in the kernel. If you have
> modules enabled, only build the driver for your root device into the
> kernel image and have the other modular. This lets you control the
> initialization order to your liking.
[Venkatesh Ramamurthy] I think there should be a better way to
handle this , compiling is one of the options, but an end-user should not
think of compiling. The end user needs to put an another card and connect
drives and get his system up and running. He should not think of compiling
the drivers, if it is already part of the kernel / initrd to get his system
running.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> In article <1355693A51C0D211B55A00105ACCFE64E9518C@ATL_MS1> you wrote: > > > we need some kind of signature being written in the drive, which the > kernel > > will use for determining the boot drive and later re-order drives, if > > required. > > Like the ext2 labels? (man e2label) [Venkatesh Ramamurthy] This re-ordering of the scsi drives should be done by SCSI ML , so is incorporating ext2 fs data structure knowledge on the SCSI ML a good idea?. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> It should be possible to read the BIOS setting for this option and
> behave accordingly. Please give full details of how to read and interpret
> the information stored in the CMOS for all versions of AMI BIOS, and I'll
> take a look at this.
[Venkatesh Ramamurthy] When i meant BIOS setting option i meant the
SCSI BIOS settings not system BIOS option. The two SCSI controllers are of
different make. This situation is made worse when the system has many cards
of different makes and one of the controller somewhere in the middle of all
the slots is made the boot controller.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Linux not adhering to BIOS Drive boot order?
Hi, I have one issue which requires fix from the linux kernel. Initially i put a SCSI controller and install the OS on the drive connected to it. After installing the OS (on sda), the customer puts another SCSI controller. The BIOS for the first controller has BIOS enabled and for the second controller does not have the BIOS enabled. The linux loads the driver for the second controller first and assigns sda to it first , and the actual boot drive gets some sdX device node. >From the lilo prompt we can override it with root=/dev/sdX to boot to the correct drive and controller, but for a end -user using these cards, this is no fun. Can the linux kernel be changed in such a way that kernel will look for the actual boot drive and re-order the drives so that mounting can go on in the right order. we need some kind of signature being written in the drive, which the kernel will use for determining the boot drive and later re-order drives, if required. Is someone handling this already? TIA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
From a layering point of view, it makes a lot more sense to me for the label (or signature or whatever) for this purpose to be in the partition table than inside the filesystem. The parts of the system that assign devices their identities already know about that part of the disk. [Venkatesh Ramamurthy] The LILO boot loader and the LILO command line utility should be changed for this. There are some issues when we have different set of labels names for file system and partition table. The LILO command line utility should make use of the disk labels of the file system and use this for creating the partition disk label name. This is something like assigning a label for kernel in lilo.conf. Is anybody doing this? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
You seem to be full of things that "we" can implement. So I just have to wonder: do you by any chance have some prototype code somewhere to figure out, reliably, which SCSI cards have BIOS extensions enabled, and the order they hook in? [Venkat] It would be a very bad idea for the linux kernel to look into the card to see whether the BIOS for that card has been enabled to make it determine the scsi drive order. If you had followed the earlier threads, the correct way to proceed would be to use labels to make things node independent. I think Andreas is working on patch for 2.2.18 and 2.4.0 kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
Why is this a SCSI ML problem? The problem is that the OS can't figure out where to mount root from. Sounds like an OS problem. I think the file system label is the leading candidate to solve this. One really does not care if the root disk is called /dev/sda or /dev/fred. All one cares is that you can boot your system and the right disks are mounted. What I have seen so far with the fs label this either does solve this today or it can solve this. I notice today on some systems the entries in /etc/fstab already are "deviceless" in that it does not have the disk/partition but simply the disk label. Can lilo use a label for the root disk also? I have not looked into that yet. If it does not can it? When I noticed the use of the label in /etc/fstab my first thought was "alright, someone is solving this problem." I have not taken the time - not a burning issue with me right now - to see if this is all done yet though. Keep in mind that the example where /dev/sda is where root lies is that "easy" case. The hard case is what happens if someone installs on /dev/sdg. Now they boot up with a disk array turned off. Is the mid-layer going to figure out that what is now /dev/sda suppose to be /dev/sdg? Or they install to /dev/sdb and /dev/sda goes bad so they pull it out? [Venkatesh Ramamurthy] If we can truly go for label based mouting and lilo'ing this would solve the problem. Anybody doing this? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
Of course that would be better. The only complaint I have with such a system is that of backwards compatibility...as long as the legacy device names are still supported i would have no problem with it at all. however, this brings up an interesting question: what happens if two disks (presumably from two different machines) have the same disk label? what happens then? for instance, i have several linux machines both at my workplace and my home. if for some reason one of these machines dies due to hardware failure and i want to get stuff off the drives, i put the disk containing the /home partition on the failed machine into a working machine and reboot. What /home gets mounted then? the original /home or the new one from the dead machine? (and don't say end users wouldn't possibly do that... if they are adding hardware into their systems this is by no means beyond their capabilities) at least with physical device nodes i can say 'computer, you will mount this partition on this mountpoint!' and be done with it. [Venkatesh Ramamurthy] You are getting my point exactly. This was my argument from the first, we should have a efficient mechanism to mount partitions so tell me then, how would one discern between two partitions with the same label? [Venkatesh Ramamurthy] If the OS detects two partitions of the same name , either dont mount both , but display an error (or) mount the first one it finds ( this is not a good idea but) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
It should be possible to read the BIOS setting for this option and behave accordingly. Please give full details of how to read and interpret the information stored in the CMOS for all versions of AMI BIOS, and I'll take a look at this. [Venkatesh Ramamurthy] When i meant BIOS setting option i meant the SCSI BIOS settings not system BIOS option. The two SCSI controllers are of different make. This situation is made worse when the system has many cards of different makes and one of the controller somewhere in the middle of all the slots is made the boot controller. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Linux not adhering to BIOS Drive boot order?
Hi, I have one issue which requires fix from the linux kernel. Initially i put a SCSI controller and install the OS on the drive connected to it. After installing the OS (on sda), the customer puts another SCSI controller. The BIOS for the first controller has BIOS enabled and for the second controller does not have the BIOS enabled. The linux loads the driver for the second controller first and assigns sda to it first , and the actual boot drive gets some sdX device node. From the lilo prompt we can override it with root=/dev/sdX to boot to the correct drive and controller, but for a end -user using these cards, this is no fun. Can the linux kernel be changed in such a way that kernel will look for the actual boot drive and re-order the drives so that mounting can go on in the right order. we need some kind of signature being written in the drive, which the kernel will use for determining the boot drive and later re-order drives, if required. Is someone handling this already? TIA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
In article 1355693A51C0D211B55A00105ACCFE64E9518C@ATL_MS1 you wrote: we need some kind of signature being written in the drive, which the kernel will use for determining the boot drive and later re-order drives, if required. Like the ext2 labels? (man e2label) [Venkatesh Ramamurthy] This re-ordering of the scsi drives should be done by SCSI ML , so is incorporating ext2 fs data structure knowledge on the SCSI ML a good idea?. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
When the cards are of different make the order is solely dependent on the order that the drivers are initialized in the kernel. If you have modules enabled, only build the driver for your root device into the kernel image and have the other modular. This lets you control the initialization order to your liking. [Venkatesh Ramamurthy] I think there should be a better way to handle this , compiling is one of the options, but an end-user should not think of compiling. The end user needs to put an another card and connect drives and get his system up and running. He should not think of compiling the drivers, if it is already part of the kernel / initrd to get his system running. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
you're forgetting that in /etc/lilo.conf there is a directive called 'append='... all the user has to do is merely add 'append="scsihosts=whatever,whatever"' into their config file and rerun lilo. problem solved besides, how many 'end-users' do you know of that will have multiple scsi adapters in one system? how many end-users -period- will have even a *single* scsi adapter in their systems? do we need to bloat the kernel with automatic things like this? no... i think it is handled fine the way it is. if the user wants to add more than one scsi adapter into his system, let him read some documentation on how to do so. (is this even a documented feature? if not, i think it should be added to the docs...) [Venkatesh Ramamurthy] Dont you think that mounting and booting based on disk label names is better, then relying on device nodes which can change when a new card is added?. The existing patch for 2.2.xx is quite small and it does not bloat the kernel too much either. I think we can port it for 2.4.XX with ease.In my words it is worth the effort - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
Is someone handling this already? "mount by uuid"? Amiga's Rigid Disk Block? [Venkatesh Ramamurthy] Something like this is better. The problem is where do we store this info. Last sector is one of the options. Does anyone know where NT stores this info? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
This is due to the fixed ordering of the scsi drivers. You can change the order of the scsi hosts with the "scsihosts" kernel parameter. See linux/drivers/scsi/scsi.c [Venkatesh Ramamurthy] I think it would be a nice idea if we can make this process automatic , with out user typing in the order and remembering it. The fact that a kernel developer is not using the machines daily to get his work done should be in our minds. If we do this Linux would become more user friendly Yours, Dominik -- http://petition.eurolinux.org/index_html - No Software Patents In Europe! http://petition.lugs.ch/ (in Switzerland) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
The scsi host numbers will be allocated to the HBAs in the order shown starting at 0. This method does not distinguish between the two advansys controllers, luckily swapping their positions on the PCI bus does. [Venkatesh Ramamurthy] Just think an end-user fuguring out this Asking him to change PCI slots and trying it out. My point is the end user should not worry about all this. All he does is plugs a new different/ same type of card, and gets it going. Why should the linux kernel force the user to change the PCI slots. Will this not make it more user - unfriendly - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
FW: Beta Release of MegaRAID 1.13s driver
I had sent a beta release few hours back to kernel and scsi list, but never made it? Is there any latency time in sending an attachment. Can the list administrator look into this ? Thanks > -Original Message- > From: Venkatesh Ramamurthy > Sent: Wednesday, January 10, 2001 4:37 PM > To: '[EMAIL PROTECTED]' > Subject: Beta Release of MegaRAID 1.13s driver > > Hi, > Lot of people have shown interest in getting their MegaRAID driver running > for linux-2.4.0 kernel. This version of the driver i s a beta release , so > dont use it directly for mission critical application without beta testing > it. > > Features > * Supports IA32 / IA64 platforms > * More than 4GB RAM Support (Should have the correct firmware) > * Supports 2.2.XX and 2.4.XX kernels > > Your feedback is welcome - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
FW: Beta Release of MegaRAID 1.13s driver
I had sent a beta release few hours back to kernel and scsi list, but never made it? Is there any latency time in sending an attachment. Can the list administrator look into this ? Thanks -Original Message- From: Venkatesh Ramamurthy Sent: Wednesday, January 10, 2001 4:37 PM To: '[EMAIL PROTECTED]' Subject: Beta Release of MegaRAID 1.13s driver Hi, Lot of people have shown interest in getting their MegaRAID driver running for linux-2.4.0 kernel. This version of the driver i s a beta release , so dont use it directly for mission critical application without beta testing it. Features * Supports IA32 / IA64 platforms * More than 4GB RAM Support (Should have the correct firmware) * Supports 2.2.XX and 2.4.XX kernels Your feedback is welcome megaraid.c megaraid.h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
megaraid.c is broken
Hi, I am the linux developer for this card. This is the problem we have fixed long back and the version of linux driver that comes with 2.4.0 is way too old. A new driver will be released in a weeks time. Thanks Venkat - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Confirmation request about new 2.4.x. kernel limits
> On Tue, Jan 09, 2001 at 08:27:49AM -0800, Tim Wright wrote: > > you are correct in saying that ia32 systems don't have IOMMU hardware, > but > > it's unfortunate that we don't support 64-bit PCI bus master cards, > since > > they're inexpensive and fairly common now. For instance, the Qlogic ISP > SCSI > > cards can do 64-bit addressing, as can many others. Has anybody taken a > look > > at enabling this ? [Venkatesh Ramamurthy] Our AMI RAID controller and MegaRAID driver ( part of kernel) supports full blown 64 bit and we have successfully tested with more than 4 GB RAM under IA32 (uses bounce buffer) and IA64 systems. We are seeing a dramatic performance drop on IA32 with 8GB ram as it has to do bounce buffering. I think we need this support to give our dear old linux a lead compared to other OS'es. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Confirmation request about new 2.4.x. kernel limits
> Problem is that it needs a driver interface change and cooperation from > the > drivers. [Venkatesh Ramamurthy] Atleast the spec for this new interface, that the driver has to support be prepared? Once this is done we can port driver by driver to this new standard. > -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Confirmation request about new 2.4.x. kernel limits
> Any memory over 1GB is bounce-buffered, but we don't use that memory
> for anything other than process data pages or file cache, so only
> swapping and disk IO to regular files gets the extra copy. In
> particular, things like network buffers are still all kept in the low
> 1GB so never need to be buffered.
[Venkatesh Ramamurthy] If anything over 1GB is bounce buffered than
what is the purpose of setting the pci_dev->dma_mask field. On a IA32
system we set it to 32 1's and IA64 to 64 1's - Venkat
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Confirmation request about new 2.4.x. kernel limits
Problem is that it needs a driver interface change and cooperation from the drivers. [Venkatesh Ramamurthy] Atleast the spec for this new interface, that the driver has to support be prepared? Once this is done we can port driver by driver to this new standard. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Confirmation request about new 2.4.x. kernel limits
On Tue, Jan 09, 2001 at 08:27:49AM -0800, Tim Wright wrote: you are correct in saying that ia32 systems don't have IOMMU hardware, but it's unfortunate that we don't support 64-bit PCI bus master cards, since they're inexpensive and fairly common now. For instance, the Qlogic ISP SCSI cards can do 64-bit addressing, as can many others. Has anybody taken a look at enabling this ? [Venkatesh Ramamurthy] Our AMI RAID controller and MegaRAID driver ( part of kernel) supports full blown 64 bit and we have successfully tested with more than 4 GB RAM under IA32 (uses bounce buffer) and IA64 systems. We are seeing a dramatic performance drop on IA32 with 8GB ram as it has to do bounce buffering. I think we need this support to give our dear old linux a lead compared to other OS'es. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
megaraid.c is broken
Hi, I am the linux developer for this card. This is the problem we have fixed long back and the version of linux driver that comes with 2.4.0 is way too old. A new driver will be released in a weeks time. Thanks Venkat - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Confirmation request about new 2.4.x. kernel limits
> Max. RAM size:64 GB (any slowness accessing RAM over 4 GB * with 32 bit machines ?) Imore than 4GB in RAM is bounce buffered, so there is performance penalty as the data have to be copied into the 4GB RAM area - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Confirmation request about new 2.4.x. kernel limits
Max. RAM size:64 GB (any slowness accessing RAM over 4 GB * with 32 bit machines ?) Imore than 4GB in RAM is bounce buffered, so there is performance penalty as the data have to be copied into the 4GB RAM area - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
