Zau ... ca da :)
De exemplu ... de la 2.6.9 la 2.6.10+ ..s-a schimbat:
Changes the PM_SUSPEND_MEM (and PM_SUSPEND_DISK) enum values so that
they make sense as PCI device power states.
(a) Fixes bugs whereby PCI drivers are being given bogus values.
The should resolve OSDL bugid 2886 without changing the PCI
API (its PM calls still act as on 2.4 kernels).
(b) Doesn't change the awkward assumption in the 2.6 PMcore that
the /sys/bus/*/devices/power/state, /proc/acpi/sleep,
dev->power.power_state, and dev->detach_state files share
the same numeric codes ... even for busses very unlike PCI,
or systems with several "on" policies as well as STD and STR.
Really we need to move away from "u32" codes that are easily confused
with each other, towards typed values (probably struct pointers), but
this is the simplest comprehensive fix for the PCI problem.
........
si in principal:
extern void (*pm_power_off)(void);
enum {
- PM_SUSPEND_ON,
- PM_SUSPEND_STANDBY,
- PM_SUSPEND_MEM,
- PM_SUSPEND_DISK,
- PM_SUSPEND_MAX,
+ PM_SUSPEND_ON = 0,
+ PM_SUSPEND_STANDBY = 1,
+ /* NOTE: PM_SUSPEND_MEM == PCI_D3hot */
+ PM_SUSPEND_MEM = 3,
+ PM_SUSPEND_DISK = 4,
+ PM_SUSPEND_MAX = 5,
};
enum {
.........
Si asta se reflecta direct ...in ordinea in care se "asigneaza"
driverele ...etc ...in functie de optiunile de la compilarea kernelului
...etc.
De ex cu 2.6.11 ... n-am avut NICIODATA probleme cu inversarea placilor
de retea ...etc..
Si asta e doar un exemplu ...sunt multe alte locuri in:
.../kernel/power/main.c
.../include/linux/pm.h
.../kernel/power/swsusp.c
care influenteaza DIRECT ... ordinea de incarcare ...pt ca "PCI device
power states"
SAU (exempu e pt MSI):
+. Possible Resource Conflicts +
+Since all service drivers of a PCI-PCI Bridge Port device are +allowed
to run simultaneously, below lists a few of possible resource +conflicts
with proposed solutions. + +6.1 MSI Vector Resource + +The MSI
capability structure enables a device software driver to call
+pci_enable_msi to request MSI based interrupts. Once MSI interrupts
+are enabled on a device, it stays in this mode until a device driver
+calls pci_disable_msi to disable MSI interrupts and revert back to
+INTx emulation mode. Since service drivers of the same PCI-PCI Bridge
+port share the same physical device, if an individual service driver
+calls pci_enable_msi/pci_disable_msi it may result unpredictable
+behavior. For example, two service drivers run simultaneously on the
+same physical Root Port. Both service drivers call pci_enable_msi to
+request MSI based interrupts. A service driver may not know whether
+any other service drivers have run on this Root Port. If either one +of
them calls pci_disable_msi, it puts the other service driver +in a wrong
interrupt mode. + +To avoid this situation all service drivers are not
permitted to +switch interrupt mode on its device. The PCI Express Port
Bus driver +is responsible for determining the interrupt mode and this
should be +transparent to service drivers. Service drivers need to know
only +the vector IRQ assigned to the field irq of struct pci_device,
which +is passed in when the PCI Port Bus driver probes each service
+driver. Service drivers should use (struct pci_device*)dev->irq to
+call request_irq/free_irq. In addition, the interrupt mode is stored
+in the field interrupt_mode of struct pci_device. +
Adik ...sa concluzionez ...aproape la fiecare versiune de kernel ...au
modificat si cate ceva prin PCI ... chair si la aceeasi versiune ...in
functie de optiunile de la compilare se
poate schimba modul de comportare la incarcarea driverelor ...etc.
Asa ca cea mai buna solutie e nameif ... sau o placa Super Buna ..cu
implementare STANDARD si FULL de PCI-to-PCI bridge, BIOS bun, ...etc
Uf ... e mult de comentat ..daca vrei sa te convingi ...iti aduc un
"Tyan Thunder i7520 (S5360G2NR) " ... poti sa pui ORICE kernel vrei tu
pe ea ....nu se "brambureste" nimic :)
lonely wolf wrote:
>vlad wrote:
>
>
>>M-am pe cateva configuratii cu SuSe 9.3 si n-am avut nicodata probleme,
>>chiar si cu 3 sau 4 placi de retea ..
>>Problema e rezolvabila intradevar cu nameif dar nu e software ...si da,
>>e legata de:
>>
>>
>>
>>
>>>difera modul in care sint baleiate porturile I/O si/sau intreruperile.
>>>am patit si eu.
>>>foloseste cu incredere nameif
>>>
>>>
>>dar nu e "vina" kernelului
>>
>>
>nu zau? in conditiile in care _acelasi_ hardware este vazut diferit de diverse
>kernele ?
>
>
>
>---
>Detalii despre listele noastre de mail: http://www.lug.ro/
>
>
>
>
>
---
Detalii despre listele noastre de mail: http://www.lug.ro/
