Re: EBDA Question
"H. Peter Anvin" wrote: > Followup to: <[EMAIL PROTECTED]> > By author:"Moore, Eric Dean" <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > EBDA - Extended Bios Data Area > > > > Does Linux and various boot loaders(lilo/grub/etc) > > having any restrictions on where and how big > > memory allocated in EBDA is? Is this > > handled for 2.4/2.6 Kernels? > > > > Reason I ask is we are considering having > > BIOS(for a SCSI HBA Controller) allocating > > memory in EBDA for Firmware use. > > We are concerned whether Linux would be writing > > over this region of memory during the handoff > > of BIOS to scsi lower layer driver loading. > > > > In general, dropping the EBDA below 0x9a000 is probably a > bad idea. Recent Linux kernels and boot loaders should handle it, > though. Keep in mind that you might find yourself in serious trouble > if you then have, for example, a PXE stack layered on top of your SCSI > BIOS. There are test software used in manufacturing line that needs this DOS memory. > > > -hpa > > - > 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: EBDA Question
H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Moore, Eric Dean [EMAIL PROTECTED] In newsgroup: linux.dev.kernel EBDA - Extended Bios Data Area Does Linux and various boot loaders(lilo/grub/etc) having any restrictions on where and how big memory allocated in EBDA is? Is this handled for 2.4/2.6 Kernels? Reason I ask is we are considering having BIOS(for a SCSI HBA Controller) allocating memory in EBDA for Firmware use. We are concerned whether Linux would be writing over this region of memory during the handoff of BIOS to scsi lower layer driver loading. In general, dropping the EBDA below 0x9a000 is probably a bad idea. Recent Linux kernels and boot loaders should handle it, though. Keep in mind that you might find yourself in serious trouble if you then have, for example, a PXE stack layered on top of your SCSI BIOS. There are test software used in manufacturing line that needs this DOS memory. -hpa - 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: [PATCH] Update to IPMI driver to support old DMI spec
Corey Minyard wrote:
> BTW, I'm also working with the person who had the trouble with the I2C
> non-blocking driver updates, but we haven't figured it out yet.
> Hopefully soon. (Though that has nothing to do with this patch.)
>
> Thanks,
>
> -Corey
>
>
> ---
> The 1999 version of the DMI spec had a different configuration
> than the newer versions for the IPMI configuration information.
Are you referring to the System Management BIOS Reference Specification
version 2.3.1 16 March 1999?
>
> This patch handles the differences between the two.
>
> Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
>
> Index: linux-2.6.11-rc3/drivers/char/ipmi/ipmi_si_intf.c
> ===
> --- linux-2.6.11-rc3.orig/drivers/char/ipmi/ipmi_si_intf.c
> +++ linux-2.6.11-rc3/drivers/char/ipmi/ipmi_si_intf.c
> @@ -1578,46 +1578,53 @@
> u8 *data = (u8 *)dm;
> unsigned long base_addr;
> u8 reg_spacing;
> + u8 len = dm->length;
> dmi_ipmi_data_t *ipmi_data = dmi_data+intf_num;
>
> ipmi_data->type = data[4];
>
> memcpy(_addr, data+8, sizeof(unsigned long));
> - if (base_addr & 1) {
> - /* I/O */
> - base_addr &= 0xFFFE;
> + if (len >= 0x11) {
> + if (base_addr & 1) {
> + /* I/O */
> + base_addr &= 0xFFFE;
> + ipmi_data->addr_space = IPMI_IO_ADDR_SPACE;
> + }
> + else {
> + /* Memory */
> + ipmi_data->addr_space = IPMI_MEM_ADDR_SPACE;
> + }
> + /* If bit 4 of byte 0x10 is set, then the lsb for the address
> + is odd. */
> + ipmi_data->base_addr = base_addr | ((data[0x10] & 0x10) >> 4);
> +
> + ipmi_data->irq = data[0x11];
> +
> + /* The top two bits of byte 0x10 hold the register spacing. */
> + reg_spacing = (data[0x10] & 0xC0) >> 6;
> + switch(reg_spacing){
> + case 0x00: /* Byte boundaries */
> + ipmi_data->offset = 1;
> + break;
> + case 0x01: /* 32-bit boundaries */
> + ipmi_data->offset = 4;
> + break;
> + case 0x02: /* 16-byte boundaries */
> + ipmi_data->offset = 16;
> + break;
> + default:
> + /* Some other interface, just ignore it. */
> + return -EIO;
> + }
> + } else {
> + /* Old DMI spec. */
> + ipmi_data->base_addr = base_addr;
> ipmi_data->addr_space = IPMI_IO_ADDR_SPACE;
> - }
> - else {
> - /* Memory */
> - ipmi_data->addr_space = IPMI_MEM_ADDR_SPACE;
> - }
> -
> - /* The top two bits of byte 0x10 hold the register spacing. */
> - reg_spacing = (data[0x10] & 0xC0) >> 6;
> - switch(reg_spacing){
> - case 0x00: /* Byte boundaries */
> ipmi_data->offset = 1;
> - break;
> - case 0x01: /* 32-bit boundaries */
> - ipmi_data->offset = 4;
> - break;
> - case 0x02: /* 16-byte boundaries */
> - ipmi_data->offset = 16;
> - break;
> - default:
> - /* Some other interface, just ignore it. */
> - return -EIO;
> }
>
> ipmi_data->slave_addr = data[6];
>
> - /* If bit 4 of byte 0x10 is set, then the lsb for the address
> - is odd. */
> - ipmi_data->base_addr = base_addr | ((data[0x10] & 0x10) >> 4);
> -
> - ipmi_data->irq = data[0x11];
> -
> if (is_new_interface(-1, ipmi_data->addr_space,ipmi_data->base_addr))
> {
> dmi_data_entries++;
> return 0;
-
To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH] Update to IPMI driver to support old DMI spec
Corey Minyard wrote:
BTW, I'm also working with the person who had the trouble with the I2C
non-blocking driver updates, but we haven't figured it out yet.
Hopefully soon. (Though that has nothing to do with this patch.)
Thanks,
-Corey
---
The 1999 version of the DMI spec had a different configuration
than the newer versions for the IPMI configuration information.
Are you referring to the System Management BIOS Reference Specification
version 2.3.1 16 March 1999?
This patch handles the differences between the two.
Signed-off-by: Corey Minyard [EMAIL PROTECTED]
Index: linux-2.6.11-rc3/drivers/char/ipmi/ipmi_si_intf.c
===
--- linux-2.6.11-rc3.orig/drivers/char/ipmi/ipmi_si_intf.c
+++ linux-2.6.11-rc3/drivers/char/ipmi/ipmi_si_intf.c
@@ -1578,46 +1578,53 @@
u8 *data = (u8 *)dm;
unsigned long base_addr;
u8 reg_spacing;
+ u8 len = dm-length;
dmi_ipmi_data_t *ipmi_data = dmi_data+intf_num;
ipmi_data-type = data[4];
memcpy(base_addr, data+8, sizeof(unsigned long));
- if (base_addr 1) {
- /* I/O */
- base_addr = 0xFFFE;
+ if (len = 0x11) {
+ if (base_addr 1) {
+ /* I/O */
+ base_addr = 0xFFFE;
+ ipmi_data-addr_space = IPMI_IO_ADDR_SPACE;
+ }
+ else {
+ /* Memory */
+ ipmi_data-addr_space = IPMI_MEM_ADDR_SPACE;
+ }
+ /* If bit 4 of byte 0x10 is set, then the lsb for the address
+ is odd. */
+ ipmi_data-base_addr = base_addr | ((data[0x10] 0x10) 4);
+
+ ipmi_data-irq = data[0x11];
+
+ /* The top two bits of byte 0x10 hold the register spacing. */
+ reg_spacing = (data[0x10] 0xC0) 6;
+ switch(reg_spacing){
+ case 0x00: /* Byte boundaries */
+ ipmi_data-offset = 1;
+ break;
+ case 0x01: /* 32-bit boundaries */
+ ipmi_data-offset = 4;
+ break;
+ case 0x02: /* 16-byte boundaries */
+ ipmi_data-offset = 16;
+ break;
+ default:
+ /* Some other interface, just ignore it. */
+ return -EIO;
+ }
+ } else {
+ /* Old DMI spec. */
+ ipmi_data-base_addr = base_addr;
ipmi_data-addr_space = IPMI_IO_ADDR_SPACE;
- }
- else {
- /* Memory */
- ipmi_data-addr_space = IPMI_MEM_ADDR_SPACE;
- }
-
- /* The top two bits of byte 0x10 hold the register spacing. */
- reg_spacing = (data[0x10] 0xC0) 6;
- switch(reg_spacing){
- case 0x00: /* Byte boundaries */
ipmi_data-offset = 1;
- break;
- case 0x01: /* 32-bit boundaries */
- ipmi_data-offset = 4;
- break;
- case 0x02: /* 16-byte boundaries */
- ipmi_data-offset = 16;
- break;
- default:
- /* Some other interface, just ignore it. */
- return -EIO;
}
ipmi_data-slave_addr = data[6];
- /* If bit 4 of byte 0x10 is set, then the lsb for the address
- is odd. */
- ipmi_data-base_addr = base_addr | ((data[0x10] 0x10) 4);
-
- ipmi_data-irq = data[0x11];
-
if (is_new_interface(-1, ipmi_data-addr_space,ipmi_data-base_addr))
{
dmi_data_entries++;
return 0;
-
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
Re: Question regarding e1000 driver and dropped packets (2.6.5 / 2.6.10)?
Bukie Mabayoje wrote: > Can you do a simple test? > Connect the two box to the same switch. ( No other box should be on the > physical bus) > 1. Send packets from BoxA ---> BoxB ( Record the stats) > > 2. Send packets from BoxB ---> BoxA(Record the stats) > > 3. Send packets simultaneously from BoxB->BoxA and BoxA -> BoxB > (Record the stats) > > if you can find a third box > > 4. Send packets [BoxA and BoxC] -> BoxB and BoxB -> BoxA > (Record the stats) > > 5. Send packets [BoxB and BoxC] -> BoxA and BoxA --> BoxB (Record > the stats) > > I don't understand why you received more packet on BoxB. A controlled test > will help clarify any ambiguity. > [BoxA] RX packets:196787934 errors:4 dropped:0 overruns:0 frame:2 > TX packets:101356779 errors:0 dropped:0 overruns:0 > carrier:0 > > [BoxB]RX packets:446380046 errors:1276833 dropped:1276833 > overruns:1276833 frame:0 > TX packets:572550636 errors:0 dropped:0 overruns:0 > carrier:0 > > Justin Piszcz wrote: > > > I have two identical machines [mobo/hardware wise]: > > > > Each machine is a Dell GX1p (500MHZ). > > > > I have two Intel Gigabit NICs, one in each box, hooked up to a GigE > > switch. > > > > Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller > > Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller > > > > I doubt its the kernel version; does anyone have any suggestions/ideas why > > one machine has virtually NO overruns/errors/drops and the other has tons? > > > > Also, (I doubt this to be the case but I'll ask anyway) - Is the way the > > NIC's are setup in the box next to other cards / alter their PCI/IRQ > > routing which would effect error/drop rates? > > > > IE: > > > > PCI1 - promise card / pata > > PCI2 - promise card / pata > > PCI3 - promise card / sata > > PCI4 - e1000 nic > > PCI5 - 4 port nic > > What matters is which INT# [A,B,C,D] line and/or combination the PCI slot 1, > 2, 3, 4 is using. > You can find out by running lspci -vv > If they are routed to the same system interrupt and lastly, the interrupt > priority issues. > > > > > > > Would it make sense to order them in a different direction? > > May not help in identifying the problem. > > > > > > > Also, is there a correlation between errors on the NIC and ERR > > in /proc/interrupts? > > Maybe.. > > > > > > > Secondly, could loading lm-sensors/temperature modules be causing these > > problems? > > You don't have any overrun on this box. My Error. It may be related. Try without loading ln-sensor/temp modules. I don't think your mother board supports the i2c stuff you are loading. You have the Intel 440BX AGP chipset and there is not i2c interface on it. > > > > > > > > dmesg from box2 below: > > > > e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex > > eth1: Setting full-duplex based on MII#1 link partner capability of 45e1. > > eth2: Setting full-duplex based on MII#1 link partner capability of 45e1. > > nfs warning: mount version older than kernel > > nfs warning: mount version older than kernel > > nfs warning: mount version older than kernel > > nfs warning: mount version older than kernel > > i2c /dev entries driver > > piix4_smbus :00:07.3: Found :00:07.3 device > > piix4_smbus :00:07.3: WARNING: SMBus interface has been FORCEFULLY > > ENABLED! > > mtrr: no MTRR for fd00,80 found > > spurious 8259A interrupt: IRQ7. > > spurious 8259A interrupt: IRQ15. > > > > I am currently out of ideas, if anyone can suggest anything, I'd be most > > greatful, thanks! > > > > On the first box, there are hardly any problems receiving packets: > > > > Note the errors & dropped on the receiving end: > > > > BOX1: (2.6.5) > > > > eth0 Link encap:Ethernet HWaddr 00:0E:0C:00:CD:B1 > >inet addr:10.0.2.254 Bcast:10.0.2.255 Mask:255.255.255.0 > >inet6 addr: fe80::20e:cff:fe00:cdb1/64 Scope:Link > >UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > >RX packets:196787934 errors:4 dropped:0 overruns:0 frame:2 > >TX packets:101356779 errors:0 dropped:0 overruns:0 carrier:0 > >collisions:0 txqueuelen:1000 > >RX bytes:2602045376 (2481.5 Mb) TX bytes:4051930608 (3864.2 Mb) > >Base address:0xcc80 Memor
Re: Question regarding e1000 driver and dropped packets (2.6.5 / 2.6.10)?
Can you do a simple test? Connect the two box to the same switch. ( No other box should be on the physical bus) 1. Send packets from BoxA ---> BoxB ( Record the stats) 2. Send packets from BoxB ---> BoxA(Record the stats) 3. Send packets simultaneously from BoxB->BoxA and BoxA -> BoxB (Record the stats) if you can find a third box 4. Send packets [BoxA and BoxC] -> BoxB and BoxB -> BoxA (Record the stats) 5. Send packets [BoxB and BoxC] -> BoxA and BoxA --> BoxB (Record the stats) I don't understand why you received more packet on BoxB. A controlled test will help clarify any ambiguity. [BoxA] RX packets:196787934 errors:4 dropped:0 overruns:0 frame:2 TX packets:101356779 errors:0 dropped:0 overruns:0 carrier:0 [BoxB]RX packets:446380046 errors:1276833 dropped:1276833 overruns:1276833 frame:0 TX packets:572550636 errors:0 dropped:0 overruns:0 carrier:0 Justin Piszcz wrote: > I have two identical machines [mobo/hardware wise]: > > Each machine is a Dell GX1p (500MHZ). > > I have two Intel Gigabit NICs, one in each box, hooked up to a GigE > switch. > > Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller > Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller > > I doubt its the kernel version; does anyone have any suggestions/ideas why > one machine has virtually NO overruns/errors/drops and the other has tons? > > Also, (I doubt this to be the case but I'll ask anyway) - Is the way the > NIC's are setup in the box next to other cards / alter their PCI/IRQ > routing which would effect error/drop rates? > > IE: > > PCI1 - promise card / pata > PCI2 - promise card / pata > PCI3 - promise card / sata > PCI4 - e1000 nic > PCI5 - 4 port nic What matters is which INT# [A,B,C,D] line and/or combination the PCI slot 1, 2, 3, 4 is using. You can find out by running lspci -vv If they are routed to the same system interrupt and lastly, the interrupt priority issues. > > > Would it make sense to order them in a different direction? May not help in identifying the problem. > > > Also, is there a correlation between errors on the NIC and ERR > in /proc/interrupts? Maybe.. > > > Secondly, could loading lm-sensors/temperature modules be causing these > problems? You don't have any overrun on this box. > > > dmesg from box2 below: > > e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex > eth1: Setting full-duplex based on MII#1 link partner capability of 45e1. > eth2: Setting full-duplex based on MII#1 link partner capability of 45e1. > nfs warning: mount version older than kernel > nfs warning: mount version older than kernel > nfs warning: mount version older than kernel > nfs warning: mount version older than kernel > i2c /dev entries driver > piix4_smbus :00:07.3: Found :00:07.3 device > piix4_smbus :00:07.3: WARNING: SMBus interface has been FORCEFULLY > ENABLED! > mtrr: no MTRR for fd00,80 found > spurious 8259A interrupt: IRQ7. > spurious 8259A interrupt: IRQ15. > > I am currently out of ideas, if anyone can suggest anything, I'd be most > greatful, thanks! > > On the first box, there are hardly any problems receiving packets: > > Note the errors & dropped on the receiving end: > > BOX1: (2.6.5) > > eth0 Link encap:Ethernet HWaddr 00:0E:0C:00:CD:B1 >inet addr:10.0.2.254 Bcast:10.0.2.255 Mask:255.255.255.0 >inet6 addr: fe80::20e:cff:fe00:cdb1/64 Scope:Link >UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >RX packets:196787934 errors:4 dropped:0 overruns:0 frame:2 >TX packets:101356779 errors:0 dropped:0 overruns:0 carrier:0 >collisions:0 txqueuelen:1000 >RX bytes:2602045376 (2481.5 Mb) TX bytes:4051930608 (3864.2 Mb) >Base address:0xcc80 Memory:ff02-ff04 > > BOX1 MODULES: > > $ lsmod > Module Size Used by > ip_nat_ftp 4016 0 > ip_conntrack_ftp 71088 1 ip_nat_ftp > > BOX2: (2.6.10) > > On another box (same physical HW) I get this: > > eth0 Link encap:Ethernet HWaddr 00:0E:0C:00:D2:06 >inet addr:10.0.2.253 Bcast:10.0.2.255 Mask:255.255.255.0 >UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > --> RX packets:446380046 errors:1276833 dropped:1276833 > overruns:1276833 frame:0 >TX packets:572550636 errors:0 dropped:0 overruns:0 carrier:0 >collisions:0 txqueuelen:1000 >RX bytes:2351750726 (2.1 GiB) TX bytes:3659840330 (3.4 GiB) >Base address:0xd8c0 Memory:f8fa-f8fc > > BOX2 MODULES: > > $ lsmod > Module Size Used by > ip_nat_irc 3408 0 > ip_conntrack_irc 70480 1 ip_nat_irc > ip_nat_ftp 4112 0 > ip_conntrack_ftp 71344 1 ip_nat_ftp > adm102111060 0 > i2c_piix4 6000 0 >
Re: Question regarding e1000 driver and dropped packets (2.6.5 / 2.6.10)?
Can you do a simple test? Connect the two box to the same switch. ( No other box should be on the physical bus) 1. Send packets from BoxA --- BoxB ( Record the stats) 2. Send packets from BoxB --- BoxA(Record the stats) 3. Send packets simultaneously from BoxB-BoxA and BoxA - BoxB (Record the stats) if you can find a third box 4. Send packets [BoxA and BoxC] - BoxB and BoxB - BoxA (Record the stats) 5. Send packets [BoxB and BoxC] - BoxA and BoxA -- BoxB (Record the stats) I don't understand why you received more packet on BoxB. A controlled test will help clarify any ambiguity. [BoxA] RX packets:196787934 errors:4 dropped:0 overruns:0 frame:2 TX packets:101356779 errors:0 dropped:0 overruns:0 carrier:0 [BoxB]RX packets:446380046 errors:1276833 dropped:1276833 overruns:1276833 frame:0 TX packets:572550636 errors:0 dropped:0 overruns:0 carrier:0 Justin Piszcz wrote: I have two identical machines [mobo/hardware wise]: Each machine is a Dell GX1p (500MHZ). I have two Intel Gigabit NICs, one in each box, hooked up to a GigE switch. Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller I doubt its the kernel version; does anyone have any suggestions/ideas why one machine has virtually NO overruns/errors/drops and the other has tons? Also, (I doubt this to be the case but I'll ask anyway) - Is the way the NIC's are setup in the box next to other cards / alter their PCI/IRQ routing which would effect error/drop rates? IE: PCI1 - promise card / pata PCI2 - promise card / pata PCI3 - promise card / sata PCI4 - e1000 nic PCI5 - 4 port nic What matters is which INT# [A,B,C,D] line and/or combination the PCI slot 1, 2, 3, 4 is using. You can find out by running lspci -vv If they are routed to the same system interrupt and lastly, the interrupt priority issues. Would it make sense to order them in a different direction? May not help in identifying the problem. Also, is there a correlation between errors on the NIC and ERR in /proc/interrupts? Maybe.. Secondly, could loading lm-sensors/temperature modules be causing these problems? You don't have any overrun on this box. dmesg from box2 below: e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex eth1: Setting full-duplex based on MII#1 link partner capability of 45e1. eth2: Setting full-duplex based on MII#1 link partner capability of 45e1. nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel i2c /dev entries driver piix4_smbus :00:07.3: Found :00:07.3 device piix4_smbus :00:07.3: WARNING: SMBus interface has been FORCEFULLY ENABLED! mtrr: no MTRR for fd00,80 found spurious 8259A interrupt: IRQ7. spurious 8259A interrupt: IRQ15. I am currently out of ideas, if anyone can suggest anything, I'd be most greatful, thanks! On the first box, there are hardly any problems receiving packets: Note the errors dropped on the receiving end: BOX1: (2.6.5) eth0 Link encap:Ethernet HWaddr 00:0E:0C:00:CD:B1 inet addr:10.0.2.254 Bcast:10.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::20e:cff:fe00:cdb1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:196787934 errors:4 dropped:0 overruns:0 frame:2 TX packets:101356779 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2602045376 (2481.5 Mb) TX bytes:4051930608 (3864.2 Mb) Base address:0xcc80 Memory:ff02-ff04 BOX1 MODULES: $ lsmod Module Size Used by ip_nat_ftp 4016 0 ip_conntrack_ftp 71088 1 ip_nat_ftp BOX2: (2.6.10) On another box (same physical HW) I get this: eth0 Link encap:Ethernet HWaddr 00:0E:0C:00:D2:06 inet addr:10.0.2.253 Bcast:10.0.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 -- RX packets:446380046 errors:1276833 dropped:1276833 overruns:1276833 frame:0 TX packets:572550636 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2351750726 (2.1 GiB) TX bytes:3659840330 (3.4 GiB) Base address:0xd8c0 Memory:f8fa-f8fc BOX2 MODULES: $ lsmod Module Size Used by ip_nat_irc 3408 0 ip_conntrack_irc 70480 1 ip_nat_irc ip_nat_ftp 4112 0 ip_conntrack_ftp 71344 1 ip_nat_ftp adm102111060 0 i2c_piix4 6000 0 i2c_sensor 2784 1 adm1021 i2c_dev 7680 0 i2c_core 18224 4
Re: Question regarding e1000 driver and dropped packets (2.6.5 / 2.6.10)?
Bukie Mabayoje wrote: Can you do a simple test? Connect the two box to the same switch. ( No other box should be on the physical bus) 1. Send packets from BoxA --- BoxB ( Record the stats) 2. Send packets from BoxB --- BoxA(Record the stats) 3. Send packets simultaneously from BoxB-BoxA and BoxA - BoxB (Record the stats) if you can find a third box 4. Send packets [BoxA and BoxC] - BoxB and BoxB - BoxA (Record the stats) 5. Send packets [BoxB and BoxC] - BoxA and BoxA -- BoxB (Record the stats) I don't understand why you received more packet on BoxB. A controlled test will help clarify any ambiguity. [BoxA] RX packets:196787934 errors:4 dropped:0 overruns:0 frame:2 TX packets:101356779 errors:0 dropped:0 overruns:0 carrier:0 [BoxB]RX packets:446380046 errors:1276833 dropped:1276833 overruns:1276833 frame:0 TX packets:572550636 errors:0 dropped:0 overruns:0 carrier:0 Justin Piszcz wrote: I have two identical machines [mobo/hardware wise]: Each machine is a Dell GX1p (500MHZ). I have two Intel Gigabit NICs, one in each box, hooked up to a GigE switch. Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller I doubt its the kernel version; does anyone have any suggestions/ideas why one machine has virtually NO overruns/errors/drops and the other has tons? Also, (I doubt this to be the case but I'll ask anyway) - Is the way the NIC's are setup in the box next to other cards / alter their PCI/IRQ routing which would effect error/drop rates? IE: PCI1 - promise card / pata PCI2 - promise card / pata PCI3 - promise card / sata PCI4 - e1000 nic PCI5 - 4 port nic What matters is which INT# [A,B,C,D] line and/or combination the PCI slot 1, 2, 3, 4 is using. You can find out by running lspci -vv If they are routed to the same system interrupt and lastly, the interrupt priority issues. Would it make sense to order them in a different direction? May not help in identifying the problem. Also, is there a correlation between errors on the NIC and ERR in /proc/interrupts? Maybe.. Secondly, could loading lm-sensors/temperature modules be causing these problems? You don't have any overrun on this box. My Error. It may be related. Try without loading ln-sensor/temp modules. I don't think your mother board supports the i2c stuff you are loading. You have the Intel 440BX AGP chipset and there is not i2c interface on it. dmesg from box2 below: e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex eth1: Setting full-duplex based on MII#1 link partner capability of 45e1. eth2: Setting full-duplex based on MII#1 link partner capability of 45e1. nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel nfs warning: mount version older than kernel i2c /dev entries driver piix4_smbus :00:07.3: Found :00:07.3 device piix4_smbus :00:07.3: WARNING: SMBus interface has been FORCEFULLY ENABLED! mtrr: no MTRR for fd00,80 found spurious 8259A interrupt: IRQ7. spurious 8259A interrupt: IRQ15. I am currently out of ideas, if anyone can suggest anything, I'd be most greatful, thanks! On the first box, there are hardly any problems receiving packets: Note the errors dropped on the receiving end: BOX1: (2.6.5) eth0 Link encap:Ethernet HWaddr 00:0E:0C:00:CD:B1 inet addr:10.0.2.254 Bcast:10.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::20e:cff:fe00:cdb1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:196787934 errors:4 dropped:0 overruns:0 frame:2 TX packets:101356779 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2602045376 (2481.5 Mb) TX bytes:4051930608 (3864.2 Mb) Base address:0xcc80 Memory:ff02-ff04 BOX1 MODULES: $ lsmod Module Size Used by ip_nat_ftp 4016 0 ip_conntrack_ftp 71088 1 ip_nat_ftp BOX2: (2.6.10) On another box (same physical HW) I get this: eth0 Link encap:Ethernet HWaddr 00:0E:0C:00:D2:06 inet addr:10.0.2.253 Bcast:10.0.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 -- RX packets:446380046 errors:1276833 dropped:1276833 overruns:1276833 frame:0 TX packets:572550636 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2351750726 (2.1 GiB) TX bytes:3659840330 (3.4 GiB) Base address:0xd8c0 Memory:f8fa-f8fc BOX2 MODULES: $ lsmod
Re: i8042 access timings
Linus Torvalds wrote: > On Fri, 28 Jan 2005, Jaco Kroon wrote: > > >> > > >>ok, how would I try this? Where can I find an example to code it from? > > >> Sorry, I should probably be grepping ... > > > If the udelay() didn't work, then this one isn't worth worryign about > > > either. Back to the drawing board. > > Yea. But for interrests sake, what do you mean with a serializing IO > > instruction? > > If you use "outb_p()" instead of an "outb()", the regular IO instruction > will be followed by another out to another port on the motherboard: that > will not only cause a delay, it should also force at least the host bridge > to have no outstanding posted writes (the host bridge shouldn't post IO > port writes anyway, but hey, it won't hurt to try to make even more sure > of that). > > > I also tried increasing the total timeout value to about 5 seconds > > (versus the default half second), still no success, so the device is > > simply not sending back the requested values. > > If it was the other way around (that it works with ACPI _on_), I'd assume > that ACPI just disables some broken BIOS SMM emulation code. But I just > don't see ACPI _enabling_ SMM emulation. That would be just too strange, > and against the whole point of the legacy keyboard emulation stuff - you > want to do legacy keyboard emulation if the OS is old, not if it's new. > > It may be that ACPI ends up enabling some silly power control SMM sequence > that wakes up on keyboard accesses, and screws up the emulation. That > sounds pretty strange too, I have to say - even if SMM/ACPI would like to > trap keyboard command sequences, I'd have expected it to just pass them > through after looking at them. > > One option may be that SMM/ACPI traps the _received_ characters, and > incorrectly eats the reply, because it thinks it's some special key > sequence (and should cause SMM/ACPI to make the screen brighter or > something silly like that). > > Does anybody know/remember what the keycode 0xA5 means? So far , the only place I can find a 0xA5 is under the PS/2 Keyboard numbers and scan codes. KeyNumber Set 1 Make/Break Set 2 Make/Break Set 3 Make/Break Base Case Uppercase 38 25/A542/F0 42 42/F0 42 k K I am not familiar with how PS/2 uses it scan code. Unlike the AT it only have one Scan code to a Key Number. > > > > I still stand with the theory that it is sending back the value we want > > for the first request on the second one (managed to get this one by > > explicitly turning i8042_debug on and off in the code): > > > > i8042_init() > > ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1 > > ACPI: PS/2 Mouse Controller [MSE0] at irq 12 > > i8042_controller_init() > > i8042_flush() > > drivers/input/serio/i8042.c: 20 -> i8042 (command) [4] > > drivers/input/serio/i8042.c: 47 <- i8042 (return) [4] > > drivers/input/serio/i8042.c: 60 -> i8042 (command) [5] > > drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [5] > > i8042_check_aux() > > drivers/input/serio/i8042.c: Interrupt 12, without any data [9] > > i8042_flush() > > drivers/input/serio/i8042.c: d3 -> i8042 (command) [13] > > drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [13] > > drivers/input/serio/i8042.c: -- i8042 (timeout) [875] > > i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1 > > drivers/input/serio/i8042.c: a9 -> i8042 (command) [879] > > drivers/input/serio/i8042.c: a5 <- i8042 (return) [879] > > i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0 > > > > I've rebooted a couple of times and that interrupt is in exactly the > > same place every time. And int 12 is indeed the AUX device, could this > > be a clue? > > Does it change if you change the initial value of "param" (0x5a) to > something else? > > Linus > - > 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: i8042 access timings
Linus Torvalds wrote: On Fri, 28 Jan 2005, Jaco Kroon wrote: ok, how would I try this? Where can I find an example to code it from? Sorry, I should probably be grepping ... If the udelay() didn't work, then this one isn't worth worryign about either. Back to the drawing board. Yea. But for interrests sake, what do you mean with a serializing IO instruction? If you use outb_p() instead of an outb(), the regular IO instruction will be followed by another out to another port on the motherboard: that will not only cause a delay, it should also force at least the host bridge to have no outstanding posted writes (the host bridge shouldn't post IO port writes anyway, but hey, it won't hurt to try to make even more sure of that). I also tried increasing the total timeout value to about 5 seconds (versus the default half second), still no success, so the device is simply not sending back the requested values. If it was the other way around (that it works with ACPI _on_), I'd assume that ACPI just disables some broken BIOS SMM emulation code. But I just don't see ACPI _enabling_ SMM emulation. That would be just too strange, and against the whole point of the legacy keyboard emulation stuff - you want to do legacy keyboard emulation if the OS is old, not if it's new. It may be that ACPI ends up enabling some silly power control SMM sequence that wakes up on keyboard accesses, and screws up the emulation. That sounds pretty strange too, I have to say - even if SMM/ACPI would like to trap keyboard command sequences, I'd have expected it to just pass them through after looking at them. One option may be that SMM/ACPI traps the _received_ characters, and incorrectly eats the reply, because it thinks it's some special key sequence (and should cause SMM/ACPI to make the screen brighter or something silly like that). Does anybody know/remember what the keycode 0xA5 means? So far , the only place I can find a 0xA5 is under the PS/2 Keyboard numbers and scan codes. KeyNumber Set 1 Make/Break Set 2 Make/Break Set 3 Make/Break Base Case Uppercase 38 25/A542/F0 42 42/F0 42 k K I am not familiar with how PS/2 uses it scan code. Unlike the AT it only have one Scan code to a Key Number. I still stand with the theory that it is sending back the value we want for the first request on the second one (managed to get this one by explicitly turning i8042_debug on and off in the code): i8042_init() ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1 ACPI: PS/2 Mouse Controller [MSE0] at irq 12 i8042_controller_init() i8042_flush() drivers/input/serio/i8042.c: 20 - i8042 (command) [4] drivers/input/serio/i8042.c: 47 - i8042 (return) [4] drivers/input/serio/i8042.c: 60 - i8042 (command) [5] drivers/input/serio/i8042.c: 56 - i8042 (parameter) [5] i8042_check_aux() drivers/input/serio/i8042.c: Interrupt 12, without any data [9] i8042_flush() drivers/input/serio/i8042.c: d3 - i8042 (command) [13] drivers/input/serio/i8042.c: 5a - i8042 (parameter) [13] drivers/input/serio/i8042.c: -- i8042 (timeout) [875] i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a = -1 drivers/input/serio/i8042.c: a9 - i8042 (command) [879] drivers/input/serio/i8042.c: a5 - i8042 (return) [879] i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 = 0 I've rebooted a couple of times and that interrupt is in exactly the same place every time. And int 12 is indeed the AUX device, could this be a clue? Does it change if you change the initial value of param (0x5a) to something else? Linus - 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: 2.4.29, e100 and a WOL packet causes keventd going mad
Marcelo Tosatti wrote: > On Sun, Jan 30, 2005 at 08:23:47PM -0800, Bukie Mabayoje wrote: > > > > Scott Feldman wrote: > > > > > On Sun, 2005-01-30 at 09:18, David Härdeman wrote: > > > > I experience the same problems as reported by Michael Gernoth when > > > > sending a WOL-packet to computer with a e100 NIC which is already > > > > powered on. > > > > > > I didn't look at the 2.4 case, but for 2.6, it seems e100 was enabling > > > PME wakeup during probe. PME shouldn't be enabled while the system is > > > up. I suspect the assertion of PME while the system is up is what's > > > causing problems. This patch moves PME wakeup enabling to either > > > suspend or shutdown. > > > > > > David, would you give this patch a try? Make sure the system still > > > wakes from a magic packet if suspended or shut down, and doesn't cause > > > kacpid to go crazy if system is running. If it helps for 2.6, perhaps > > > someone can look into 2.4 to see if there is something similar going on > > > > This issue was reported on 2.4. > > Can any of you guys test v2.6, please? I will be glad to test it now but I can't, I am currently doing some work on 2.4. If no one has tested it in the next few days I will validate it then. By the way, do anyone have an idea how to get this functionality into 2.4 eepro100. The problem is that eepro100 code works on a non WOL cards. > > > - > 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: 2.4.29, e100 and a WOL packet causes keventd going mad
The issue is not the PME interrupt, the issue is that the device is going into
a state that is not valid. A live system should never ASSERT PME# line. As long
as this functionality is enable on the chip the PME will be asserted.
To avoid this unwanted condition the driver should disable PME on the chip on a
live system. And enable it back when it is going to any of the PWR STATE that
require a wake up by the LAN.
"Brandeburg, Jesse" wrote:
> >+static void e100_shutdown(struct device *dev)
> >+{
> >+ struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
> >+ struct net_device *netdev = pci_get_drvdata(pdev);
> >+ struct nic *nic = netdev_priv(netdev);
> >+
> >+ pci_enable_wake(pdev, PCI_D0, nic->flags & (wol_magic |
> >e100_asf(nic)));
> >+}
> >+
>
> Separately, does anyone think that the OS should be handling the PME event on
> the bus (as it comes from the PIC as an interrupt, and can be masked at the
> PIC) with a default handler? The machines having the problem seem to be
> killed by an interrupt storm generated by the PME interrupt, just a guess.
>
> Jesse
> -
> 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: 2.4.29, e100 and a WOL packet causes keventd going mad
The issue is not the PME interrupt, the issue is that the device is going into
a state that is not valid. A live system should never ASSERT PME# line. As long
as this functionality is enable on the chip the PME will be asserted.
To avoid this unwanted condition the driver should disable PME on the chip on a
live system. And enable it back when it is going to any of the PWR STATE that
require a wake up by the LAN.
Brandeburg, Jesse wrote:
+static void e100_shutdown(struct device *dev)
+{
+ struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct nic *nic = netdev_priv(netdev);
+
+ pci_enable_wake(pdev, PCI_D0, nic-flags (wol_magic |
e100_asf(nic)));
+}
+
Separately, does anyone think that the OS should be handling the PME event on
the bus (as it comes from the PIC as an interrupt, and can be masked at the
PIC) with a default handler? The machines having the problem seem to be
killed by an interrupt storm generated by the PME interrupt, just a guess.
Jesse
-
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: 2.4.29, e100 and a WOL packet causes keventd going mad
Marcelo Tosatti wrote: On Sun, Jan 30, 2005 at 08:23:47PM -0800, Bukie Mabayoje wrote: Scott Feldman wrote: On Sun, 2005-01-30 at 09:18, David Härdeman wrote: I experience the same problems as reported by Michael Gernoth when sending a WOL-packet to computer with a e100 NIC which is already powered on. I didn't look at the 2.4 case, but for 2.6, it seems e100 was enabling PME wakeup during probe. PME shouldn't be enabled while the system is up. I suspect the assertion of PME while the system is up is what's causing problems. This patch moves PME wakeup enabling to either suspend or shutdown. David, would you give this patch a try? Make sure the system still wakes from a magic packet if suspended or shut down, and doesn't cause kacpid to go crazy if system is running. If it helps for 2.6, perhaps someone can look into 2.4 to see if there is something similar going on This issue was reported on 2.4. Can any of you guys test v2.6, please? I will be glad to test it now but I can't, I am currently doing some work on 2.4. If no one has tested it in the next few days I will validate it then. By the way, do anyone have an idea how to get this functionality into 2.4 eepro100. The problem is that eepro100 code works on a non WOL cards. - 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: 2.4.29, e100 and a WOL packet causes keventd going mad
Scott Feldman wrote:
> On Sun, 2005-01-30 at 09:18, David Härdeman wrote:
> > I experience the same problems as reported by Michael Gernoth when
> > sending a WOL-packet to computer with a e100 NIC which is already
> > powered on.
>
> I didn't look at the 2.4 case, but for 2.6, it seems e100 was enabling
> PME wakeup during probe. PME shouldn't be enabled while the system is
> up. I suspect the assertion of PME while the system is up is what's
> causing problems. This patch moves PME wakeup enabling to either
> suspend or shutdown.
>
> David, would you give this patch a try? Make sure the system still
> wakes from a magic packet if suspended or shut down, and doesn't cause
> kacpid to go crazy if system is running. If it helps for 2.6, perhaps
> someone can look into 2.4 to see if there is something similar going on
This issue was reported on 2.4.
>
> there.
>
> -scott
>
> --- linux-2.6.11-rc2/drivers/net/e100.c.orig2005-01-30 19:13:56.850497376
> -0800
> +++ linux-2.6.11-rc2/drivers/net/e100.c 2005-01-30 19:26:41.154305536 -0800
> @@ -1868,7 +1868,6 @@ static int e100_set_wol(struct net_devic
> else
> nic->flags &= ~wol_magic;
>
> - pci_enable_wake(nic->pdev, 0, nic->flags & (wol_magic |
> e100_asf(nic)));
> e100_exec_cb(nic, NULL, e100_configure);
>
> return 0;
> @@ -2262,8 +2261,6 @@ static int __devinit e100_probe(struct p
>(nic->eeprom[eeprom_id] & eeprom_id_wol))
> nic->flags |= wol_magic;
>
> - pci_enable_wake(pdev, 0, nic->flags & (wol_magic | e100_asf(nic)));
> -
> strcpy(netdev->name, "eth%d");
> if((err = register_netdev(netdev))) {
> DPRINTK(PROBE, ERR, "Cannot register net device,
> aborting.\n");
> @@ -2344,6 +2341,15 @@ static int e100_resume(struct pci_dev *p
> }
> #endif
>
> +static void e100_shutdown(struct device *dev)
> +{
> + struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
> + struct net_device *netdev = pci_get_drvdata(pdev);
> + struct nic *nic = netdev_priv(netdev);
> +
> + pci_enable_wake(pdev, 0, nic->flags & (wol_magic | e100_asf(nic)));
> +}
> +
> static struct pci_driver e100_driver = {
> .name = DRV_NAME,
> .id_table = e100_id_table,
> @@ -2353,6 +2359,9 @@ static struct pci_driver e100_driver = {
> .suspend = e100_suspend,
> .resume = e100_resume,
> #endif
> + .driver = {
> + .shutdown = e100_shutdown,
> + }
> };
>
> static int __init e100_init_module(void)
>
> -
> 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: IPMI smbus and Intel 6300ESB Watchdog drivers
David Härdeman wrote: > Hi, > > (third question to LKML today =) > > I've recently bought an Intel SE7210TP1-E mainboard (specs here: > http://www.intel.com/design/servers/boards/SE7210TP1-E/index.htm) and I > now have most things working. > > There are however, two questionmarks left. > > 1) On the mainboard is a 6300ESB Watchdog Timer (pci id 8086:25ab), but > there seems to be no driver available for it. 6300ESB is not a Watchdog Timer. It is an I/O Controller hub that includes a watch dog timer. > Does anyone know if there > is any such driver in progress or if I've misunderstood the situation? If you tell me why you are interested in the WDT, then maybe I will be able answer your question. > > > 2) IPMI, Documentation/IPMI.txt mentions a ipmi_smb driver, but I could > find no such driver in the 2.6.10 tree. Am I missing something? Do you get the ISM package that shipped with the board? The ISM software stack in not part of the kernel. The IPMI stuff is part of Server Management. > > > Thanks in advance for any enlightenment. > > Regards, > David Härdeman > > Not subscribed...please CC me on any replies... > - > 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: 2.4.29, e100 and a WOL packet causes keventd going mad
Scott Feldman wrote:
On Sun, 2005-01-30 at 09:18, David Härdeman wrote:
I experience the same problems as reported by Michael Gernoth when
sending a WOL-packet to computer with a e100 NIC which is already
powered on.
I didn't look at the 2.4 case, but for 2.6, it seems e100 was enabling
PME wakeup during probe. PME shouldn't be enabled while the system is
up. I suspect the assertion of PME while the system is up is what's
causing problems. This patch moves PME wakeup enabling to either
suspend or shutdown.
David, would you give this patch a try? Make sure the system still
wakes from a magic packet if suspended or shut down, and doesn't cause
kacpid to go crazy if system is running. If it helps for 2.6, perhaps
someone can look into 2.4 to see if there is something similar going on
This issue was reported on 2.4.
there.
-scott
--- linux-2.6.11-rc2/drivers/net/e100.c.orig2005-01-30 19:13:56.850497376
-0800
+++ linux-2.6.11-rc2/drivers/net/e100.c 2005-01-30 19:26:41.154305536 -0800
@@ -1868,7 +1868,6 @@ static int e100_set_wol(struct net_devic
else
nic-flags = ~wol_magic;
- pci_enable_wake(nic-pdev, 0, nic-flags (wol_magic |
e100_asf(nic)));
e100_exec_cb(nic, NULL, e100_configure);
return 0;
@@ -2262,8 +2261,6 @@ static int __devinit e100_probe(struct p
(nic-eeprom[eeprom_id] eeprom_id_wol))
nic-flags |= wol_magic;
- pci_enable_wake(pdev, 0, nic-flags (wol_magic | e100_asf(nic)));
-
strcpy(netdev-name, eth%d);
if((err = register_netdev(netdev))) {
DPRINTK(PROBE, ERR, Cannot register net device,
aborting.\n);
@@ -2344,6 +2341,15 @@ static int e100_resume(struct pci_dev *p
}
#endif
+static void e100_shutdown(struct device *dev)
+{
+ struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct nic *nic = netdev_priv(netdev);
+
+ pci_enable_wake(pdev, 0, nic-flags (wol_magic | e100_asf(nic)));
+}
+
static struct pci_driver e100_driver = {
.name = DRV_NAME,
.id_table = e100_id_table,
@@ -2353,6 +2359,9 @@ static struct pci_driver e100_driver = {
.suspend = e100_suspend,
.resume = e100_resume,
#endif
+ .driver = {
+ .shutdown = e100_shutdown,
+ }
};
static int __init e100_init_module(void)
-
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: 2.4.29, e100 and a WOL packet causes keventd going mad
Michael Gernoth wrote: > On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote: > > Do you know the official NIC product name e.g Pro/100B. I need to identify > > the LAN Controller. There are differences between 557 (not sure if 557 can > > do WOL), 558 and 559 how they ASSERT the PME# signal. Even the same chip > > have > > differences between steppings. > > The chip is integrated on the motherboard. Its PCI ID is 8086:1039. > lspci says: Intel Corp. 82801BD PRO/100 VE (LOM) Ethernet Controller (rev 81) > If you want I can open up one of these machines tomorrow to look on the chip > directly. > > Regards, > Michael > - > 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/ I can't find the datasheet for 82801BD. 82801 are typically I/O Controller Hub. I need to see how it drives the PCI Interface Signals. I will try an reproduce it on a different set of chipset. Basically send a WOL packet to a live linux system. And see if keventd consumes excessive CPU time. - 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: 2.4.29, e100 and a WOL packet causes keventd going mad
Michael Gernoth wrote: On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote: Do you know the official NIC product name e.g Pro/100B. I need to identify the LAN Controller. There are differences between 557 (not sure if 557 can do WOL), 558 and 559 how they ASSERT the PME# signal. Even the same chip have differences between steppings. The chip is integrated on the motherboard. Its PCI ID is 8086:1039. lspci says: Intel Corp. 82801BD PRO/100 VE (LOM) Ethernet Controller (rev 81) If you want I can open up one of these machines tomorrow to look on the chip directly. Regards, Michael - 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/ I can't find the datasheet for 82801BD. 82801 are typically I/O Controller Hub. I need to see how it drives the PCI Interface Signals. I will try an reproduce it on a different set of chipset. Basically send a WOL packet to a live linux system. And see if keventd consumes excessive CPU time. - 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: 2.4.29, e100 and a WOL packet causes keventd going mad
Michael Gernoth wrote: > On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote: > > Do you know the official NIC product name e.g Pro/100B. I need to identify > > the LAN Controller. There are differences between 557 (not sure if 557 can > > do WOL), 558 and 559 how they ASSERT the PME# signal. Even the same chip > > have > > differences between steppings. > > The chip is integrated on the motherboard. Its PCI ID is 8086:1039. > lspci says: Intel Corp. 82801BD PRO/100 VE (LOM) Ethernet Controller (rev 81) > If you want I can open up one of these machines tomorrow to look on the chip > directly. > > Regards, > Michael Thanks got enough information - 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: 2.4.29, e100 and a WOL packet causes keventd going mad
Michael Gernoth wrote: > Hi, > > we have about 70 P4 uniprocessor machines (some with Hyperthreading > capable CPUs) running linux 2.4.29, which are woken up on the weekdays > by sending a WOL packet to them. The machines all have a E100 nic with > WOL enabled in the bios. The E100 driver is compiled into the kernel > and not loaded as a module. > > If the machine which should be woken up is already running (because > someone switched it on by hand), the WOL packet causes keventd to go > mad and "use" 100% CPU: > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 2 root 15 0 000 R 99.9 0.0 140:50.94 keventd > > This can be reproduced on any of the 70 machines by simply sending a WOL > packet to it, when it's already running... No entry is made in the > kernel log. > > The dmesg of an affected machine can be found at: > http://wwwcip.informatik.uni-erlangen.de/~simigern/cip-dmesg > Our kernel-config is at: > http://wwwcip.informatik.uni-erlangen.de/~simigern/cip-generic-config > lspci -vvv is at: > http://wwwcip.informatik.uni-erlangen.de/~simigern/cip-lspci > > We are using a kernel.org linux 2.4.29 kernel patched with the current > autofs patch and ACL support. > > Regards, > Michael > - > 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/ Do you know the official NIC product name e.g Pro/100B. I need to identify the LAN Controller. There are differences between 557 (not sure if 557 can do WOL), 558 and 559 how they ASSERT the PME# signal. Even the same chip have differences between steppings. I suspect that PME# is not being DEASSERT after the Wake-up packet is received - 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: 2.4.29, e100 and a WOL packet causes keventd going mad
Michael Gernoth wrote: Hi, we have about 70 P4 uniprocessor machines (some with Hyperthreading capable CPUs) running linux 2.4.29, which are woken up on the weekdays by sending a WOL packet to them. The machines all have a E100 nic with WOL enabled in the bios. The E100 driver is compiled into the kernel and not loaded as a module. If the machine which should be woken up is already running (because someone switched it on by hand), the WOL packet causes keventd to go mad and use 100% CPU: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2 root 15 0 000 R 99.9 0.0 140:50.94 keventd This can be reproduced on any of the 70 machines by simply sending a WOL packet to it, when it's already running... No entry is made in the kernel log. The dmesg of an affected machine can be found at: http://wwwcip.informatik.uni-erlangen.de/~simigern/cip-dmesg Our kernel-config is at: http://wwwcip.informatik.uni-erlangen.de/~simigern/cip-generic-config lspci -vvv is at: http://wwwcip.informatik.uni-erlangen.de/~simigern/cip-lspci We are using a kernel.org linux 2.4.29 kernel patched with the current autofs patch and ACL support. Regards, Michael - 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/ Do you know the official NIC product name e.g Pro/100B. I need to identify the LAN Controller. There are differences between 557 (not sure if 557 can do WOL), 558 and 559 how they ASSERT the PME# signal. Even the same chip have differences between steppings. I suspect that PME# is not being DEASSERT after the Wake-up packet is received - 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: 2.4.29, e100 and a WOL packet causes keventd going mad
Michael Gernoth wrote: On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote: Do you know the official NIC product name e.g Pro/100B. I need to identify the LAN Controller. There are differences between 557 (not sure if 557 can do WOL), 558 and 559 how they ASSERT the PME# signal. Even the same chip have differences between steppings. The chip is integrated on the motherboard. Its PCI ID is 8086:1039. lspci says: Intel Corp. 82801BD PRO/100 VE (LOM) Ethernet Controller (rev 81) If you want I can open up one of these machines tomorrow to look on the chip directly. Regards, Michael Thanks got enough information - 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: Adding an async I2C interface
> I will be glad to work with on this, I have some exposure to the BMC. See > text below in blue. > > bukie > > Corey Minyard wrote: > >> Mark Studebaker wrote: >> >> > is there a way to do this solely in i2c-core without having to >> > add support to all the drivers? >> >> Yes and no. In order to support this async operation, the driver cannot >> block and do things like msleep() or schedule(). > > The Interface driver must be a user space driver. > >> It has to start the >> operation, return, and either let polling or an interrupt drive the >> continued operation. Thus for async operations the driver has to be >> modified. However, if async operation is not required, the driver can >> stay as is. >> >> I've been working on this and will probably have a patch tomorrow. I've >> modified the piix4 and the i801 drivers, I probably won't do any more >> myself unless the need arises, since I can't test any others. Note that >> this still supports the old driver interface, so no drivers need to be >> rewritten. That way, they only need to be modified if something needs >> the async interface. So drivers that have an RTC on them or that >> support IPMI BMCs could be rewritten, but nothing else needs to be done. >> >> I've also noticed a somewhat cavalier attitude in this code with respect >> to return values. I've cleaned some of that up so return values are not >> just -1 on error, but are proper errno values. However, I've only fixed >> the core code and the drivers I've worked on. >> >> Thanks, >> >> -Corey >> >> > >> > Corey Minyard wrote: >> > >> >> I have an IPMI interface driver that sits on top of the I2C code. I'd >> >> like to get it into the mainstream kernel, but I have a few problems >> >> to solve first before I can do that. The I2C code is synchronous and >> >> must run from a task context. > > I am not sure what you mean that the I2C code is synchronous. I2C bus is > Asynchronous which means that the data clock is not included in the data. The > Sender and Receiver agrees on the timing parameters prior to the bus > transaction. > >> The IPMI driver has certain >> >> operations that occur at panic time, including: >> >> >> >> * Storing panic information in IPMI's system event log >> >> * Extending the watchdog timer so it doesn't go off during panic >> >> operations (like kernel coredumps). >> >> * Powering the system off >> >> > > Is this driver compliant with the IPMI spec? Because the above should be a > sensor that must be enable or disable. A driver should not make sure a > decision by itself. > >> >> >> I can't really put the IPMI SMB interface into the kernel until I can >> >> do those operations. Also, I understand that some vendors put RTC >> >> chips onto the I2C bus and this must be accessed outside task context, >> >> too. > > What the vendor put on the board doesn't matter with respect to IPMI. What > matter is that you have access to the Master where the slave you talking to > is connect on the I2C bus. > >> I would really like add asynchronous interface to the I2C bus >> >> drivers. > > Do you mean a blocking and non blocking I/O? > >> I propose: >> >> >> >> * Adding an async send interface to the busses that does a callback >> >> when the operation is complete. > > Okay, you are doing a non-blocking I/O. So what happens when another process > tries to access the I2C bus before the bus transaction is completed. Some > thing (mainly the app) needs to tell the driver not to share the resource > while a transaction is in progress. > >> >> >> * Adding a poll interface to the busses. The I2C core code could >> >> call this if a synchronous call is made from task context (much >> >> like all the current drivers do right now). For asyncronous >> >> operation, the I2C core code would call it from a timer >> >> interrupt. If the driver supported interrupts, polling from the >> >> timer interrupt would not be necessary. > > I think this should be done in the Interface code because the Interface code > will be running in the user space and have access to the operating system > facility. > >> >> >> * Add async operations for the user to call, including access to the >> >> polling code. > > The driver can make itself blocking and non blocking > >> >> >> * If the driver didn't support an async send, it would work as it >> >> does today and the async calls would return ENOSYS. > > Not needed, it will be addressed by the blocking and non-block implementation > of the driver. > >> >> >> >> >> This way, the bus drivers on I2C could be converted on a >> >> driver-by-driver basis. The IPMI code could query to see if the >> >> driver supported async operations. And the RTC code could use it, >> >> too. >> >> >> >> Is this ok with the I2C community? I would do the base work and >> >> convert over a few drivers. >> >> >> >> Thanks, >> >> >> >> -Corey >> >> >> >> >> >> - >> To unsubscribe from this list: send the line
Re: Adding an async I2C interface
I will be glad to work with on this, I have some exposure to the BMC. See text below in blue. bukie Corey Minyard wrote: Mark Studebaker wrote: is there a way to do this solely in i2c-core without having to add support to all the drivers? Yes and no. In order to support this async operation, the driver cannot block and do things like msleep() or schedule(). The Interface driver must be a user space driver. It has to start the operation, return, and either let polling or an interrupt drive the continued operation. Thus for async operations the driver has to be modified. However, if async operation is not required, the driver can stay as is. I've been working on this and will probably have a patch tomorrow. I've modified the piix4 and the i801 drivers, I probably won't do any more myself unless the need arises, since I can't test any others. Note that this still supports the old driver interface, so no drivers need to be rewritten. That way, they only need to be modified if something needs the async interface. So drivers that have an RTC on them or that support IPMI BMCs could be rewritten, but nothing else needs to be done. I've also noticed a somewhat cavalier attitude in this code with respect to return values. I've cleaned some of that up so return values are not just -1 on error, but are proper errno values. However, I've only fixed the core code and the drivers I've worked on. Thanks, -Corey Corey Minyard wrote: I have an IPMI interface driver that sits on top of the I2C code. I'd like to get it into the mainstream kernel, but I have a few problems to solve first before I can do that. The I2C code is synchronous and must run from a task context. I am not sure what you mean that the I2C code is synchronous. I2C bus is Asynchronous which means that the data clock is not included in the data. The Sender and Receiver agrees on the timing parameters prior to the bus transaction. The IPMI driver has certain operations that occur at panic time, including: * Storing panic information in IPMI's system event log * Extending the watchdog timer so it doesn't go off during panic operations (like kernel coredumps). * Powering the system off Is this driver compliant with the IPMI spec? Because the above should be a sensor that must be enable or disable. A driver should not make sure a decision by itself. I can't really put the IPMI SMB interface into the kernel until I can do those operations. Also, I understand that some vendors put RTC chips onto the I2C bus and this must be accessed outside task context, too. What the vendor put on the board doesn't matter with respect to IPMI. What matter is that you have access to the Master where the slave you talking to is connect on the I2C bus. I would really like add asynchronous interface to the I2C bus drivers. Do you mean a blocking and non blocking I/O? I propose: * Adding an async send interface to the busses that does a callback when the operation is complete. Okay, you are doing a non-blocking I/O. So what happens when another process tries to access the I2C bus before the bus transaction is completed. Some thing (mainly the app) needs to tell the driver not to share the resource while a transaction is in progress. * Adding a poll interface to the busses. The I2C core code could call this if a synchronous call is made from task context (much like all the current drivers do right now). For asyncronous operation, the I2C core code would call it from a timer interrupt. If the driver supported interrupts, polling from the timer interrupt would not be necessary. I think this should be done in the Interface code because the Interface code will be running in the user space and have access to the operating system facility. * Add async operations for the user to call, including access to the polling code. The driver can make itself blocking and non blocking * If the driver didn't support an async send, it would work as it does today and the async calls would return ENOSYS. Not needed, it will be addressed by the blocking and non-block implementation of the driver. This way, the bus drivers on I2C could be converted on a driver-by-driver basis. The IPMI code could query to see if the driver supported async operations. And the RTC code could use it, too. Is this ok with the I2C community? I would do the base work and convert over a few drivers. Thanks, -Corey - 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
