IT8716F SPI driver submission?
Hi! I have written a rough code skeleton to be able to use the ITE IT8716F Super I/O chip as SPI host/master. The code works fine in userspace, but the Linux kernel SPI framework looks like it could save me from implementing full support for SPI flash clients/slaves. That's why I'd like to rewrite my code in a manner that's suitable for kernel inclusion. The IT8716F accepts commands byte-wise and does all of the lifting on the SPI bus as well. There are limitations, though: - It can send 1,2,4,5 bytes (including command byte) to the slave and read 0,1,2,3 bytes back. Other values are not possible. - Bus clock rate is either 33 MHz or 16.5 MHz. Is there any driver I can start from as reference? Regards, Carl-Daniel - 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/
IT8716F SPI driver submission?
Hi! I have written a rough code skeleton to be able to use the ITE IT8716F Super I/O chip as SPI host/master. The code works fine in userspace, but the Linux kernel SPI framework looks like it could save me from implementing full support for SPI flash clients/slaves. That's why I'd like to rewrite my code in a manner that's suitable for kernel inclusion. The IT8716F accepts commands byte-wise and does all of the lifting on the SPI bus as well. There are limitations, though: - It can send 1,2,4,5 bytes (including command byte) to the slave and read 0,1,2,3 bytes back. Other values are not possible. - Bus clock rate is either 33 MHz or 16.5 MHz. Is there any driver I can start from as reference? Regards, Carl-Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc7-git3: MTD cafe_nand warning
Hi, when compiling 2.6.23-rc7-git3 with a config which resembles allmodconfig, I get the following warning in modpost: WARNING: Can't handle masks in drivers/mtd/nand/cafe_nand:0 Regards, Carl-Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc7-git3: MTD cafe_nand warning
Hi, when compiling 2.6.23-rc7-git3 with a config which resembles allmodconfig, I get the following warning in modpost: WARNING: Can't handle masks in drivers/mtd/nand/cafe_nand:0 Regards, Carl-Daniel - 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: forcedeth ?
On 02.08.2007 13:33, Kay Sievers wrote:
> On 7/31/07, Kay Sievers <[EMAIL PROTECTED]> wrote:
>> On 7/31/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
>>> On 31.07.2007 00:17, Gabriel C wrote:
>>>> Sasa Ostrouska wrote:
>>>>
>>>>> Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
>>>>> to check that, thx for the tip.
>>>> Yes udev does this based on the MAC address but AFAIK forcedeth is
>>>> 'special' for some reason
>>>> ( which I can really remember now and gets on each boot a new MAC address
>>>> or alike )
>>> Ah yes, that's a workaround for certain buggy boards to make sure you're
>>> not left without networking even if the MAC address stored on the board
>>> is bogus.
>>>
>>> Basically, forcedeth checks if the MAC address supplied by your
>>> mainboard is bogus and autogenerates a random MAC address from a private
>>> range (prefix 00:00:6c) as workaround. However, it will complain loudly
>>> if it has to do that.
>>>
>>> Quoting from forcedeth.c:
>>>> if (!is_valid_ether_addr(dev->perm_addr)) {
>>>> /*
>>>>* Bad mac address. At least one bios sets the mac address
>>>>* to 01:23:45:67:89:ab
>>>>*/
>>>> printk(KERN_ERR "%s: Invalid Mac address detected:
>>>> %02x:%02x:%02x:%02x:%02x:%02x\n",
>>>> pci_name(pci_dev),
>>>> dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2],
>>>> dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]);
>>>> printk(KERN_ERR "Please complain to your hardware vendor. Switching
>>>> to a random MAC.\n");
>>>> dev->dev_addr[0] = 0x00;
>>>> dev->dev_addr[1] = 0x00;
>>>> dev->dev_addr[2] = 0x6c;
>>>> get_random_bytes(>dev_addr[3], 3);
>>>> }
>>> Sometimes it helps to update the BIOS and/or set the MAC address which
>>> is printed on the board as MAC address in the BIOS.
>> In any case, it would be nice if the network core could add something like:
>> MAC_ORIGIN=device
>> MAC_ORIGIN=user
>> MAC_ORIGIN=random
>> or whatever makes sense here, to the uevent environment. So userspace
>> can handle according to that, like falling back using the
>> bus-slot-number to lookup the persistent name, or whatever is
>> appropriate.
>
> Can't we use the "locally administered" bit in the MAC address? By
> checking for ENV{address}=="?[2367abef]:*", we would skip the
> persistent rule generation based on the MAC address?
Yes and no. Theoretically, that would work. However, there are two
problems with your rule specification:
- ENV{address}=="?[13579bdf]:*" are multicast addresses, so you wouldn't
want them tobe part of a network card MAC address at all.
- http://standards.ieee.org/regauth/oui/oui.txt tells us that the
following OIDs would be excluded by your rule:
02-07-01 (hex)RACAL-DATACOM
02-1C-7C (hex)PERQ SYSTEMS CORPORATION
02-60-86 (hex)LOGIC REPLACEMENT TECH. LTD.
02-60-8C (hex)3COM CORPORATION
02-70-01 (hex)RACAL-DATACOM
02-70-B0 (hex)M/A-COM INC. COMPANIES
02-70-B3 (hex)DATA RECALL LTD
02-9D-8E (hex)CARDIAC RECORDERS INC.
02-AA-3C (hex)OLIVETTI TELECOMM SPA (OLTECO)
02-BB-01 (hex)OCTOTHORPE CORP.
02-C0-8C (hex)3COM CORPORATION
02-CF-1C (hex)COMMUNICATION MACHINERY CORP.
02-E6-D3 (hex)NIXDORF COMPUTER CORPORATION
AA-00-00 (hex)DIGITAL EQUIPMENT CORPORATION
AA-00-01 (hex)DIGITAL EQUIPMENT CORPORATION
AA-00-02 (hex)DIGITAL EQUIPMENT CORPORATION
AA-00-03 (hex)DIGITAL EQUIPMENT CORPORATION
AA-00-04 (hex)DIGITAL EQUIPMENT CORPORATION
Since it seems that real OIDs conflict with the "locally adminstered"
bit of the MAC address, I don't see a way to use the MAC address as
indicator for persistent rule eligibility.
Regards,
Carl-Daniel
-
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: forcedeth ?
On 02.08.2007 13:33, Kay Sievers wrote:
On 7/31/07, Kay Sievers [EMAIL PROTECTED] wrote:
On 7/31/07, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote:
On 31.07.2007 00:17, Gabriel C wrote:
Sasa Ostrouska wrote:
Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
to check that, thx for the tip.
Yes udev does this based on the MAC address but AFAIK forcedeth is
'special' for some reason
( which I can really remember now and gets on each boot a new MAC address
or alike )
Ah yes, that's a workaround for certain buggy boards to make sure you're
not left without networking even if the MAC address stored on the board
is bogus.
Basically, forcedeth checks if the MAC address supplied by your
mainboard is bogus and autogenerates a random MAC address from a private
range (prefix 00:00:6c) as workaround. However, it will complain loudly
if it has to do that.
Quoting from forcedeth.c:
if (!is_valid_ether_addr(dev-perm_addr)) {
/*
* Bad mac address. At least one bios sets the mac address
* to 01:23:45:67:89:ab
*/
printk(KERN_ERR %s: Invalid Mac address detected:
%02x:%02x:%02x:%02x:%02x:%02x\n,
pci_name(pci_dev),
dev-dev_addr[0], dev-dev_addr[1], dev-dev_addr[2],
dev-dev_addr[3], dev-dev_addr[4], dev-dev_addr[5]);
printk(KERN_ERR Please complain to your hardware vendor. Switching
to a random MAC.\n);
dev-dev_addr[0] = 0x00;
dev-dev_addr[1] = 0x00;
dev-dev_addr[2] = 0x6c;
get_random_bytes(dev-dev_addr[3], 3);
}
Sometimes it helps to update the BIOS and/or set the MAC address which
is printed on the board as MAC address in the BIOS.
In any case, it would be nice if the network core could add something like:
MAC_ORIGIN=device
MAC_ORIGIN=user
MAC_ORIGIN=random
or whatever makes sense here, to the uevent environment. So userspace
can handle according to that, like falling back using the
bus-slot-number to lookup the persistent name, or whatever is
appropriate.
Can't we use the locally administered bit in the MAC address? By
checking for ENV{address}==?[2367abef]:*, we would skip the
persistent rule generation based on the MAC address?
Yes and no. Theoretically, that would work. However, there are two
problems with your rule specification:
- ENV{address}==?[13579bdf]:* are multicast addresses, so you wouldn't
want them tobe part of a network card MAC address at all.
- http://standards.ieee.org/regauth/oui/oui.txt tells us that the
following OIDs would be excluded by your rule:
02-07-01 (hex)RACAL-DATACOM
02-1C-7C (hex)PERQ SYSTEMS CORPORATION
02-60-86 (hex)LOGIC REPLACEMENT TECH. LTD.
02-60-8C (hex)3COM CORPORATION
02-70-01 (hex)RACAL-DATACOM
02-70-B0 (hex)M/A-COM INC. COMPANIES
02-70-B3 (hex)DATA RECALL LTD
02-9D-8E (hex)CARDIAC RECORDERS INC.
02-AA-3C (hex)OLIVETTI TELECOMM SPA (OLTECO)
02-BB-01 (hex)OCTOTHORPE CORP.
02-C0-8C (hex)3COM CORPORATION
02-CF-1C (hex)COMMUNICATION MACHINERY CORP.
02-E6-D3 (hex)NIXDORF COMPUTER CORPORATION
AA-00-00 (hex)DIGITAL EQUIPMENT CORPORATION
AA-00-01 (hex)DIGITAL EQUIPMENT CORPORATION
AA-00-02 (hex)DIGITAL EQUIPMENT CORPORATION
AA-00-03 (hex)DIGITAL EQUIPMENT CORPORATION
AA-00-04 (hex)DIGITAL EQUIPMENT CORPORATION
Since it seems that real OIDs conflict with the locally adminstered
bit of the MAC address, I don't see a way to use the MAC address as
indicator for persistent rule eligibility.
Regards,
Carl-Daniel
-
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: forcedeth ?
On 31.07.2007 00:17, Gabriel C wrote:
> Sasa Ostrouska wrote:
>
>> Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
>> to check that, thx for the tip.
>
> Yes udev does this based on the MAC address but AFAIK forcedeth is 'special'
> for some reason
> ( which I can really remember now and gets on each boot a new MAC address or
> alike )
Ah yes, that's a workaround for certain buggy boards to make sure you're
not left without networking even if the MAC address stored on the board
is bogus.
Basically, forcedeth checks if the MAC address supplied by your
mainboard is bogus and autogenerates a random MAC address from a private
range (prefix 00:00:6c) as workaround. However, it will complain loudly
if it has to do that.
Quoting from forcedeth.c:
> if (!is_valid_ether_addr(dev->perm_addr)) {
> /*
>* Bad mac address. At least one bios sets the mac address
>* to 01:23:45:67:89:ab
>*/
> printk(KERN_ERR "%s: Invalid Mac address detected:
> %02x:%02x:%02x:%02x:%02x:%02x\n",
> pci_name(pci_dev),
> dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2],
> dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]);
> printk(KERN_ERR "Please complain to your hardware vendor. Switching to
> a random MAC.\n");
> dev->dev_addr[0] = 0x00;
> dev->dev_addr[1] = 0x00;
> dev->dev_addr[2] = 0x6c;
> get_random_bytes(>dev_addr[3], 3);
> }
Sometimes it helps to update the BIOS and/or set the MAC address which
is printed on the board as MAC address in the BIOS.
Regards,
Carl-Daniel
-
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: forcedeth ?
On 31.07.2007 00:17, Gabriel C wrote:
Sasa Ostrouska wrote:
Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
to check that, thx for the tip.
Yes udev does this based on the MAC address but AFAIK forcedeth is 'special'
for some reason
( which I can really remember now and gets on each boot a new MAC address or
alike )
Ah yes, that's a workaround for certain buggy boards to make sure you're
not left without networking even if the MAC address stored on the board
is bogus.
Basically, forcedeth checks if the MAC address supplied by your
mainboard is bogus and autogenerates a random MAC address from a private
range (prefix 00:00:6c) as workaround. However, it will complain loudly
if it has to do that.
Quoting from forcedeth.c:
if (!is_valid_ether_addr(dev-perm_addr)) {
/*
* Bad mac address. At least one bios sets the mac address
* to 01:23:45:67:89:ab
*/
printk(KERN_ERR %s: Invalid Mac address detected:
%02x:%02x:%02x:%02x:%02x:%02x\n,
pci_name(pci_dev),
dev-dev_addr[0], dev-dev_addr[1], dev-dev_addr[2],
dev-dev_addr[3], dev-dev_addr[4], dev-dev_addr[5]);
printk(KERN_ERR Please complain to your hardware vendor. Switching to
a random MAC.\n);
dev-dev_addr[0] = 0x00;
dev-dev_addr[1] = 0x00;
dev-dev_addr[2] = 0x6c;
get_random_bytes(dev-dev_addr[3], 3);
}
Sometimes it helps to update the BIOS and/or set the MAC address which
is printed on the board as MAC address in the BIOS.
Regards,
Carl-Daniel
-
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: should RTS init in serial core be tied to CRTSCTS
Hi, On 08.03.2007 14:48, Russell King wrote: > As I've said already, having a console on the same port as your application > program is just asking for trouble. All bets are off - the kernel _will_ > corrupt your data stream in random places. > > Don't do it - it will _NEVER_ be reliable. > > Never, ever, mix kernel consoles with application serial ports. Unless you want two machines to monitor each other via serial console and each of them has only one serial port. It's not perfect, but it works well enough despite all claims to the contrary. Regards, Carl-Daniel - 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: should RTS init in serial core be tied to CRTSCTS
Hi, On 08.03.2007 14:48, Russell King wrote: As I've said already, having a console on the same port as your application program is just asking for trouble. All bets are off - the kernel _will_ corrupt your data stream in random places. Don't do it - it will _NEVER_ be reliable. Never, ever, mix kernel consoles with application serial ports. Unless you want two machines to monitor each other via serial console and each of them has only one serial port. It's not perfect, but it works well enough despite all claims to the contrary. Regards, Carl-Daniel - 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: -mm merge plans for 2.6.21
Andrew Morton wrote: > On Fri, 9 Feb 2007 19:37:53 + > Alan <[EMAIL PROTECTED]> wrote: > >> Please just push the EDAC K8 stuff. > > OK. > >> Andi will say "no" from now until the >> end of time, but end users want it, distributions want it, and Andi is >> not the EDAC maintainer so should consider himself overruled on what >> isn't a technical issue but a personal political viewpoint. > > I'll just tell him I sent it by accident. Could you please merge ACPI-DSDT-in-initrd for the same reasons? Regards, Carl-Daniel - 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: -mm merge plans for 2.6.21
Andrew Morton wrote: On Fri, 9 Feb 2007 19:37:53 + Alan [EMAIL PROTECTED] wrote: Please just push the EDAC K8 stuff. OK. Andi will say no from now until the end of time, but end users want it, distributions want it, and Andi is not the EDAC maintainer so should consider himself overruled on what isn't a technical issue but a personal political viewpoint. I'll just tell him I sent it by accident. Could you please merge ACPI-DSDT-in-initrd for the same reasons? Regards, Carl-Daniel - 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/
scsi error "sense key: No Sense" with usb flash drive
Hi, upon insertion of my new 2048 MB usb flash drive, the kernel (vanilla 2.6.13) spat out the following errors: usb 4-2: new high speed USB device using ehci_hcd and address 7 scsi1 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 7 usb-storage: waiting for device to settle before scanning Vendor: TinyDisk Model: 2005-08-04Rev: 0.00 Type: Direct-Access ANSI SCSI revision: 02 SCSI device sda: 4096000 512-byte hdwr sectors (2097 MB) sda: Write Protect is on sda: Mode Sense: 0b 00 80 00 sda: assuming drive cache: write through ioctl_internal_command: <1 0 0 0> return code = 802 : Current: sense key: No Sense Additional sense: No additional sense information SCSI device sda: 4096000 512-byte hdwr sectors (2097 MB) sda: Write Protect is on sda: Mode Sense: 0b 00 80 00 sda: assuming drive cache: write through sda: sda1 Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0 Attached scsi generic sg0 at scsi1, channel 0, id 0, lun 0, type 0 usb-storage: device scan complete ioctl_internal_command: <1 0 0 0> return code = 802 : Current: sense key: No Sense Additional sense: No additional sense information ioctl_internal_command: <1 0 0 0> return code = 802 : Current: sense key: No Sense Additional sense: No additional sense information ioctl_internal_command: <1 0 0 0> return code = 802 : Current: sense key: No Sense Additional sense: No additional sense information ioctl_internal_command: <1 0 0 0> return code = 802 : Current: sense key: No Sense Additional sense: No additional sense information This error only happens with this specific flash drive. p35:~ # lsusb -v Bus 004 Device 007: ID 0457:0151 Silicon Integrated Systems Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0457 Silicon Integrated Systems Corp. idProduct 0x0151 bcdDevice1.00 iManufacturer 0 iProduct2 USB Mass Storage Device iSerial 3 0F bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 MaxPower 98mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 bytes 512 once bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 bytes 512 once bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 bytes 64 once bInterval 8 Is this just a quirky usb flash drive or do the errors indicate a bigger problem? Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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/
scsi error sense key: No Sense with usb flash drive
Hi, upon insertion of my new 2048 MB usb flash drive, the kernel (vanilla 2.6.13) spat out the following errors: usb 4-2: new high speed USB device using ehci_hcd and address 7 scsi1 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 7 usb-storage: waiting for device to settle before scanning Vendor: TinyDisk Model: 2005-08-04Rev: 0.00 Type: Direct-Access ANSI SCSI revision: 02 SCSI device sda: 4096000 512-byte hdwr sectors (2097 MB) sda: Write Protect is on sda: Mode Sense: 0b 00 80 00 sda: assuming drive cache: write through ioctl_internal_command: 1 0 0 0 return code = 802 : Current: sense key: No Sense Additional sense: No additional sense information SCSI device sda: 4096000 512-byte hdwr sectors (2097 MB) sda: Write Protect is on sda: Mode Sense: 0b 00 80 00 sda: assuming drive cache: write through sda: sda1 Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0 Attached scsi generic sg0 at scsi1, channel 0, id 0, lun 0, type 0 usb-storage: device scan complete ioctl_internal_command: 1 0 0 0 return code = 802 : Current: sense key: No Sense Additional sense: No additional sense information ioctl_internal_command: 1 0 0 0 return code = 802 : Current: sense key: No Sense Additional sense: No additional sense information ioctl_internal_command: 1 0 0 0 return code = 802 : Current: sense key: No Sense Additional sense: No additional sense information ioctl_internal_command: 1 0 0 0 return code = 802 : Current: sense key: No Sense Additional sense: No additional sense information This error only happens with this specific flash drive. p35:~ # lsusb -v Bus 004 Device 007: ID 0457:0151 Silicon Integrated Systems Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0457 Silicon Integrated Systems Corp. idProduct 0x0151 bcdDevice1.00 iManufacturer 0 iProduct2 USB Mass Storage Device iSerial 3 0F bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 MaxPower 98mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 bytes 512 once bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 bytes 512 once bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 bytes 64 once bInterval 8 Is this just a quirky usb flash drive or do the errors indicate a bigger problem? Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [linux-usb-devel] PCI quirks not handled and config space differences on resume from S3
Alan Stern schrieb: > On Tue, 16 Aug 2005, Carl-Daniel Hailfinger wrote: > > >>Hi, >>[...] >>Besides that, a number of drivers do not restore the pci config >>space of their associated devices properly on resume from S3. >> >>These drivers (and associated devices) are: >>- uhci_hcd (USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) >>USB UHCI Controller) >>[...] >>Diff between "lspci -vvvxxx" before and after resume for all >>problematic devices on my machine is attached. >> >>Are there any patches I can try? > > > The uhci-hcd driver _does_ restore the config space for its devices > properly. > >> [lspci dump] > > > Just because the before and after values are different doesn't mean > anything is wrong. Those particular bits are set by the hardware in > response to various events. They are used only by the BIOS, to provide > USB keyboard and mouse services. They don't affect the device's function > or the Linux driver at all. Thanks for the information and sorry for bothering you. > Alan Stern Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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/
PCI quirks not handled and config space differences on resume from S3
Hi, it seems that PCI quirks are not handled on resume which results in all kinds of strange effects, like disappeared PCI devices. Below is a diff between "lspci -vvvxxx" before and after resume for my SMBus device which only gets enabled by PCI quirk handling. -:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03) - Subsystem: Samsung Electronics Co Ltd: Unknown device c00c - Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- - Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://www.hailfinger.org/ --- lspci_beforeS3 2005-08-16 13:23:31.0 +0200 +++ lspci_afterS3 2005-08-16 13:23:31.0 +0200 @@ -1,353 +1,349 @@ :00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 21) Subsystem: Samsung Electronics Co Ltd: Unknown device c00c Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00: 86 80 40 33 06 01 90 20 21 00 00 06 00 00 00 00 10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 4d 14 0c c0 30: 00 00 00 00 e4 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 02 00 00 00 00 00 00 00 00 00 00 00 27 00 00 60: 04 08 0c 10 00 00 00 00 00 00 00 00 00 00 00 00 70: 02 02 00 00 00 00 00 00 00 00 02 2d 71 32 40 30 80: 71 00 80 05 00 00 00 00 00 10 01 00 00 00 00 00 -90: 10 11 11 00 01 13 11 00 41 19 00 00 00 0a 3d 00 -a0: 02 00 20 00 17 02 00 1f 04 00 00 00 00 00 00 00 +90: 10 11 11 00 01 13 11 00 41 19 00 00 00 1a 3d 00 +a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 e0 1b 20 10 00 00 c0: 44 40 50 11 00 20 05 06 00 00 00 00 00 00 00 00 d0: 02 28 00 0e 0b 00 00 30 00 00 31 b5 00 00 02 00 e0: 00 00 00 00 09 a0 04 41 00 00 00 00 00 00 00 00 f0: 00 00 01 00 74 f8 20 80 38 0f 21 00 04 00 00 00 :00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 21) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- 00: 86 80 41 33 07 01 a0 00 21 00 04 06 00 60 01 00 -10: 00 00 00 00 00 00 00 00 00 01 01 40 30 30 a0 22 +10: 00 00 00 00 00 00 00 00 00 01 01 40 30 30 a0 02 20: 10 d0 10 d0 00 d8 f0 df 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -60: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 :00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) (prog-if 00 [UHCI]) Subsystem: Samsung Electronics Co Ltd: Unknown device c00c Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- 00: 86 80 48 24 07 01 80 80 83 00 04 06 00 00 01 00 -10: 00 00 00 00 00 00 00 00 00 02 0a 40 40 40 80 02 +10: 00 00 00 00 00 00 00 00 00 02 0a 40 40 40 80 22 20: 20 d0 20 d0 00 20 f0 23 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 40: 02 28 20 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 02 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -80: 00 00 23 00 00 00 00 00 00 00 00 00 00 00 00 00 +80: 00 00 21 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 10 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 01 00 02 00 00 00 c0 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 60 0f 00 00 00 00 30 48 :00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 03) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort-
intel_agp resume problems
Hello Dave, after suspend-to-ram and a subsequent resume the configuration of my AGP bridge/controller is different and X will refuse to start after resume if it wasn't running during suspend. I'm using radeonfb as console driver and kernel 2.6.13-rc6-git6. Diff between lspci -vvvxxx before and after suspend follows. --- lspci.radeonfb_beforeS3 2005-08-16 13:23:31.0 +0200 +++ lspci.radeonfb_afterS3 2005-08-16 13:23:31.0 +0200 @@ -1,353 +1,349 @@ :00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 21) Subsystem: Samsung Electronics Co Ltd: Unknown device c00c Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00: 86 80 40 33 06 01 90 20 21 00 00 06 00 00 00 00 10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 4d 14 0c c0 30: 00 00 00 00 e4 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 02 00 00 00 00 00 00 00 00 00 00 00 27 00 00 60: 04 08 0c 10 00 00 00 00 00 00 00 00 00 00 00 00 70: 02 02 00 00 00 00 00 00 00 00 02 2d 71 32 40 30 80: 71 00 80 05 00 00 00 00 00 10 01 00 00 00 00 00 -90: 10 11 11 00 01 13 11 00 41 19 00 00 00 0a 3d 00 -a0: 02 00 20 00 17 02 00 1f 04 00 00 00 00 00 00 00 +90: 10 11 11 00 01 13 11 00 41 19 00 00 00 1a 3d 00 +a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 e0 1b 20 10 00 00 c0: 44 40 50 11 00 20 05 06 00 00 00 00 00 00 00 00 d0: 02 28 00 0e 0b 00 00 30 00 00 31 b5 00 00 02 00 e0: 00 00 00 00 09 a0 04 41 00 00 00 00 00 00 00 00 f0: 00 00 01 00 74 f8 20 80 38 0f 21 00 04 00 00 00 :00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 21) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- 00: 86 80 41 33 07 01 a0 00 21 00 04 06 00 60 01 00 -10: 00 00 00 00 00 00 00 00 00 01 01 40 30 30 a0 22 +10: 00 00 00 00 00 00 00 00 00 01 01 40 30 30 a0 02 20: 10 d0 10 d0 00 d8 f0 df 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Do you have any hints how to solve the problem? Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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/
intel_agp resume problems
Hello Dave, after suspend-to-ram and a subsequent resume the configuration of my AGP bridge/controller is different and X will refuse to start after resume if it wasn't running during suspend. I'm using radeonfb as console driver and kernel 2.6.13-rc6-git6. Diff between lspci -vvvxxx before and after suspend follows. --- lspci.radeonfb_beforeS3 2005-08-16 13:23:31.0 +0200 +++ lspci.radeonfb_afterS3 2005-08-16 13:23:31.0 +0200 @@ -1,353 +1,349 @@ :00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 21) Subsystem: Samsung Electronics Co Ltd: Unknown device c00c Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Region 0: Memory at e000 (32-bit, prefetchable) Capabilities: [e4] #09 [4104] Capabilities: [a0] AGP version 2.0 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 - Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=x4 + Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=none 00: 86 80 40 33 06 01 90 20 21 00 00 06 00 00 00 00 10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 4d 14 0c c0 30: 00 00 00 00 e4 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 02 00 00 00 00 00 00 00 00 00 00 00 27 00 00 60: 04 08 0c 10 00 00 00 00 00 00 00 00 00 00 00 00 70: 02 02 00 00 00 00 00 00 00 00 02 2d 71 32 40 30 80: 71 00 80 05 00 00 00 00 00 10 01 00 00 00 00 00 -90: 10 11 11 00 01 13 11 00 41 19 00 00 00 0a 3d 00 -a0: 02 00 20 00 17 02 00 1f 04 00 00 00 00 00 00 00 +90: 10 11 11 00 01 13 11 00 41 19 00 00 00 1a 3d 00 +a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 e0 1b 20 10 00 00 c0: 44 40 50 11 00 20 05 06 00 00 00 00 00 00 00 00 d0: 02 28 00 0e 0b 00 00 30 00 00 31 b5 00 00 02 00 e0: 00 00 00 00 09 a0 04 41 00 00 00 00 00 00 00 00 f0: 00 00 01 00 74 f8 20 80 38 0f 21 00 04 00 00 00 :00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 21) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 96 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 3000-3fff Memory behind bridge: d010-d01f Prefetchable memory behind bridge: d800-dfff Expansion ROM at 3000 [disabled] [size=4K] BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- Reset- FastB2B- 00: 86 80 41 33 07 01 a0 00 21 00 04 06 00 60 01 00 -10: 00 00 00 00 00 00 00 00 00 01 01 40 30 30 a0 22 +10: 00 00 00 00 00 00 00 00 00 01 01 40 30 30 a0 02 20: 10 d0 10 d0 00 d8 f0 df 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Do you have any hints how to solve the problem? Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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/
PCI quirks not handled and config space differences on resume from S3
Hi, it seems that PCI quirks are not handled on resume which results in all kinds of strange effects, like disappeared PCI devices. Below is a diff between lspci -vvvxxx before and after resume for my SMBus device which only gets enabled by PCI quirk handling. -:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03) - Subsystem: Samsung Electronics Co Ltd: Unknown device c00c - Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- - Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- - Interrupt: pin B routed to IRQ 0 - Region 4: I/O ports at 1100 [size=32] -00: 86 80 c3 24 01 00 80 02 03 00 05 0c 00 00 00 00 -10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -20: 01 11 00 00 00 00 00 00 00 00 00 00 4d 14 0c c0 -30: 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 -40: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -f0: 00 00 00 00 00 00 00 00 60 0f 00 00 00 00 00 00 +:00:1f.3 Class : Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev ff) (prog-if ff) + !!! Unknown header type 7f +00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Besides that, a number of drivers do not restore the pci config space of their associated devices properly on resume from S3. These drivers (and associated devices) are: - intel_agp (Host bridge: Intel Corp. 82855PM Processor to I/O Controller) - ? (PCI bridge: Intel Corp. 82855PM Processor to AGP Controller) - uhci_hcd (USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller) - ? (PCI bridge: Intel Corp. 82801 PCI Bridge) - ? (ISA bridge: Intel Corp. 82801DBM LPC Interface Controller) - piix_ide (IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller) Diff between lspci -vvvxxx before and after resume for all problematic devices on my machine is attached. Are there any patches I can try? Regards, Carl-Daniel -- http://www.hailfinger.org/ --- lspci_beforeS3 2005-08-16 13:23:31.0 +0200 +++ lspci_afterS3 2005-08-16 13:23:31.0 +0200 @@ -1,353 +1,349 @@ :00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 21) Subsystem: Samsung Electronics Co Ltd: Unknown device c00c Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Region 0: Memory at e000 (32-bit, prefetchable) Capabilities: [e4] #09 [4104] Capabilities: [a0] AGP version 2.0 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 - Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=x4 + Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=none 00: 86 80 40 33 06 01 90 20 21 00 00 06 00 00 00 00 10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 4d 14 0c c0 30: 00 00 00 00 e4 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 02 00 00 00 00 00 00 00 00 00 00 00 27 00 00 60: 04 08 0c 10 00 00 00 00 00 00 00 00 00 00 00 00 70: 02 02 00 00 00 00 00 00 00 00 02 2d 71 32 40 30 80: 71 00 80 05 00 00 00 00 00 10 01 00 00 00 00 00 -90: 10 11 11 00 01 13 11 00 41 19 00 00 00 0a 3d 00 -a0: 02 00 20 00 17 02 00 1f 04 00 00 00 00 00 00 00 +90: 10 11 11 00 01 13 11 00 41 19 00 00 00 1a 3d 00 +a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00
Re: [linux-usb-devel] PCI quirks not handled and config space differences on resume from S3
Alan Stern schrieb: On Tue, 16 Aug 2005, Carl-Daniel Hailfinger wrote: Hi, [...] Besides that, a number of drivers do not restore the pci config space of their associated devices properly on resume from S3. These drivers (and associated devices) are: - uhci_hcd (USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller) [...] Diff between lspci -vvvxxx before and after resume for all problematic devices on my machine is attached. Are there any patches I can try? The uhci-hcd driver _does_ restore the config space for its devices properly. [lspci dump] Just because the before and after values are different doesn't mean anything is wrong. Those particular bits are set by the hardware in response to various events. They are used only by the BIOS, to provide USB keyboard and mouse services. They don't affect the device's function or the Linux driver at all. Thanks for the information and sorry for bothering you. Alan Stern Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Re: [PATCH] 2.6.13-rc3-git5: fix Bug #4416 (2/2)
Rafael J. Wysocki schrieb: > The following patch adds basic suspend/resume support to the sk98lin > network driver. [snipped] The current in-kernel sk98lin driver is years behind the version downloadable from Syskonnect. Maybe it would make sense to update it first before applying any new patches. http://www.syskonnect.com/support/driver/d0102_driver.html Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Re: [PATCH] 2.6.13-rc3-git5: fix Bug #4416 (2/2)
Rafael J. Wysocki schrieb: The following patch adds basic suspend/resume support to the sk98lin network driver. [snipped] The current in-kernel sk98lin driver is years behind the version downloadable from Syskonnect. Maybe it would make sense to update it first before applying any new patches. http://www.syskonnect.com/support/driver/d0102_driver.html Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: ATAPI+SATA support in 2.6.13-rc3
Bas Vermeulen schrieb: > On Fri, 2005-07-15 at 11:31 +0200, Carl-Daniel Hailfinger wrote: > >>Hi Jeff, >> >>I have a Intel ICH6M chipset and am using ata_piix as my >>default disk driver. With the SUSE patched 2.6.11.4 kernel >>(it has some libata patches) my DVD-RAM drive works, with >>2.6.13-rc3 it doesn't work. My .config is nearly identical >>for both kernels (except options introduced after 2.6.11). >> >>I have two suspects: the changed interrupt routing and >>libata version differences. Especially strange is the fact >>that both kernels seem to disagree with lspci about the >>interrupts assigned to the SATA controller. >> >>Please find dmesg, /proc/interrupts and lspci -v attached >>for both kernels. >> >>Regards, >>Carl-Daniel > > > You'll need to enable ATAPI support for ata_piix in > include/linux/libata.h > > Change: > #undef ATA_ENABLE_ATAPI > > into > #define ATA_ENABLE_ATAPI > > Suse has probably done that for you, it's disabled by default. Thanks, I'll try that. Are there any unmerged (in 2.6.13-rc3) libata patches and where can I find them? Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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/
ATAPI+SATA support in 2.6.13-rc3
Hi Jeff, I have a Intel ICH6M chipset and am using ata_piix as my default disk driver. With the SUSE patched 2.6.11.4 kernel (it has some libata patches) my DVD-RAM drive works, with 2.6.13-rc3 it doesn't work. My .config is nearly identical for both kernels (except options introduced after 2.6.11). I have two suspects: the changed interrupt routing and libata version differences. Especially strange is the fact that both kernels seem to disagree with lspci about the interrupts assigned to the SATA controller. Please find dmesg, /proc/interrupts and lspci -v attached for both kernels. Regards, Carl-Daniel -- http://www.hailfinger.org/ Linux version 2.6.11.4-21.7-default ([EMAIL PROTECTED]) (gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)) #1 Thu Jun 2 14:23:14 UTC 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 1f6e (usable) BIOS-e820: 1f6e - 1f6ea000 (ACPI data) BIOS-e820: 1f6ea000 - 1f70 (ACPI NVS) BIOS-e820: 1f70 - 2000 (reserved) BIOS-e820: e000 - f0006000 (reserved) BIOS-e820: f0008000 - f000c000 (reserved) BIOS-e820: fed2 - fed9 (reserved) BIOS-e820: ff00 - 0001 (reserved) 0MB HIGHMEM available. 502MB LOWMEM available. On node 0 totalpages: 128736 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 124640 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI present. ACPI: RSDP (v000 PTLTD ) @ 0x000f7810 ACPI: RSDT (v001 PTLTD Wistron 0x0604 LTP 0x) @ 0x1f6e4214 ACPI: FADT (v001 INTEL ALVISO 0x0604 LOHR 0x005f) @ 0x1f6e9e88 ACPI: MADT (v001 INTEL ALVISO 0x0604 LOHR 0x005f) @ 0x1f6e9efc ACPI: BOOT (v001 PTLTD $SBFTBL$ 0x0604 LTP 0x0001) @ 0x1f6e9fd8 ACPI: MCFG (v001 INTEL ALVISO 0x0604 LOHR 0x005f) @ 0x1f6e9f9c ACPI: SSDT (v001 SataRe SataPri 0x1000 INTL 0x20030224) @ 0x1f6e510c ACPI: SSDT (v001 SataRe SataSec 0x1000 INTL 0x20030224) @ 0x1f6e4a7a ACPI: SSDT (v001 PmRef Cpu0Ist 0x3000 INTL 0x20030224) @ 0x1f6e4635 ACPI: SSDT (v001 PmRef Cpu0Cst 0x3001 INTL 0x20030224) @ 0x1f6e4457 ACPI: SSDT (v001 PmRefCpuPm 0x3000 INTL 0x20030224) @ 0x1f6e425c ACPI: DSDT (v001 INTEL ALVISO 0x0604 MSFT 0x010e) @ 0x ACPI: PM-Timer IO Port: 0x1008 ACPI: local apic disabled Allocating PCI resources starting at 2000 (gap: 2000:c000) Built 1 zonelists Kernel command line: root=/dev/sda8 vga=0x317 selinux=0 splash=silent resume=/dev/sda9 single bootsplash: silent mode. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 1596.886 MHz processor. Using pmtmr for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 505268k/514944k available (1866k kernel code, 9088k reserved, 658k data, 204k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 3153.92 BogoMIPS (lpj=1576960) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: afe9fbff 0010 0180 CPU: After vendor identify, caps: afe9fbff 0010 0180 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 2048K CPU: After all inits, caps: afe9fbff 0010 0040 0180 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: Intel(R) Pentium(R) M processor 1.60GHz stepping 08 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. checking if image is initramfs... it is Freeing initrd memory: 1505k freed ACPI: Looking for DSDT in initrd... not found! not found! ACPI: setting ELCR to 0200 (from 0c00) NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfd79e, last bus=6 PCI: Using MMCONFIG mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050211 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI-0250: *** Warning: Handle is NULL and Pathname is relative ACPI-0250: *** Warning: Handle is NULL and Pathname is relative ACPI-0250: *** Warning: Handle is NULL and Pathname is relative ACPI-0250: *** Warning: Handle is NULL and Pathname is relative ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller :00:1f.2 PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Routing Table
ATAPI+SATA support in 2.6.13-rc3
Hi Jeff, I have a Intel ICH6M chipset and am using ata_piix as my default disk driver. With the SUSE patched 2.6.11.4 kernel (it has some libata patches) my DVD-RAM drive works, with 2.6.13-rc3 it doesn't work. My .config is nearly identical for both kernels (except options introduced after 2.6.11). I have two suspects: the changed interrupt routing and libata version differences. Especially strange is the fact that both kernels seem to disagree with lspci about the interrupts assigned to the SATA controller. Please find dmesg, /proc/interrupts and lspci -v attached for both kernels. Regards, Carl-Daniel -- http://www.hailfinger.org/ Linux version 2.6.11.4-21.7-default ([EMAIL PROTECTED]) (gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)) #1 Thu Jun 2 14:23:14 UTC 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 1f6e (usable) BIOS-e820: 1f6e - 1f6ea000 (ACPI data) BIOS-e820: 1f6ea000 - 1f70 (ACPI NVS) BIOS-e820: 1f70 - 2000 (reserved) BIOS-e820: e000 - f0006000 (reserved) BIOS-e820: f0008000 - f000c000 (reserved) BIOS-e820: fed2 - fed9 (reserved) BIOS-e820: ff00 - 0001 (reserved) 0MB HIGHMEM available. 502MB LOWMEM available. On node 0 totalpages: 128736 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 124640 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI present. ACPI: RSDP (v000 PTLTD ) @ 0x000f7810 ACPI: RSDT (v001 PTLTD Wistron 0x0604 LTP 0x) @ 0x1f6e4214 ACPI: FADT (v001 INTEL ALVISO 0x0604 LOHR 0x005f) @ 0x1f6e9e88 ACPI: MADT (v001 INTEL ALVISO 0x0604 LOHR 0x005f) @ 0x1f6e9efc ACPI: BOOT (v001 PTLTD $SBFTBL$ 0x0604 LTP 0x0001) @ 0x1f6e9fd8 ACPI: MCFG (v001 INTEL ALVISO 0x0604 LOHR 0x005f) @ 0x1f6e9f9c ACPI: SSDT (v001 SataRe SataPri 0x1000 INTL 0x20030224) @ 0x1f6e510c ACPI: SSDT (v001 SataRe SataSec 0x1000 INTL 0x20030224) @ 0x1f6e4a7a ACPI: SSDT (v001 PmRef Cpu0Ist 0x3000 INTL 0x20030224) @ 0x1f6e4635 ACPI: SSDT (v001 PmRef Cpu0Cst 0x3001 INTL 0x20030224) @ 0x1f6e4457 ACPI: SSDT (v001 PmRefCpuPm 0x3000 INTL 0x20030224) @ 0x1f6e425c ACPI: DSDT (v001 INTEL ALVISO 0x0604 MSFT 0x010e) @ 0x ACPI: PM-Timer IO Port: 0x1008 ACPI: local apic disabled Allocating PCI resources starting at 2000 (gap: 2000:c000) Built 1 zonelists Kernel command line: root=/dev/sda8 vga=0x317 selinux=0 splash=silent resume=/dev/sda9 single bootsplash: silent mode. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 1596.886 MHz processor. Using pmtmr for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 505268k/514944k available (1866k kernel code, 9088k reserved, 658k data, 204k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 3153.92 BogoMIPS (lpj=1576960) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: afe9fbff 0010 0180 CPU: After vendor identify, caps: afe9fbff 0010 0180 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 2048K CPU: After all inits, caps: afe9fbff 0010 0040 0180 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: Intel(R) Pentium(R) M processor 1.60GHz stepping 08 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. checking if image is initramfs... it is Freeing initrd memory: 1505k freed ACPI: Looking for DSDT in initrd... not found! not found! ACPI: setting ELCR to 0200 (from 0c00) NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfd79e, last bus=6 PCI: Using MMCONFIG mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050211 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI-0250: *** Warning: Handle is NULL and Pathname is relative ACPI-0250: *** Warning: Handle is NULL and Pathname is relative ACPI-0250: *** Warning: Handle is NULL and Pathname is relative ACPI-0250: *** Warning: Handle is NULL and Pathname is relative ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller :00:1f.2 PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Routing Table
Re: updating mtime for char/block devices?
Russell King schrieb: > On Tue, Mar 01, 2005 at 01:45:47AM +0100, Carl-Daniel Hailfinger wrote: > >>Can I prevent mtime updates for all device files? Mounting /dev readonly >>would certainly help, but for that to work I'd have to move /dev to a >>different filesystem, right? > > > tty mtime updates aren't marked dirty, so aren't written back to disk. > Intentionally. It seems the tty mtime exception doesn't include /dev/ptmx. That's probably unintentional. Is there a chance to extend the tty mtime exception to all char devices or at least major 4+5? Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: updating mtime for char/block devices?
Russell King schrieb: On Tue, Mar 01, 2005 at 01:45:47AM +0100, Carl-Daniel Hailfinger wrote: Can I prevent mtime updates for all device files? Mounting /dev readonly would certainly help, but for that to work I'd have to move /dev to a different filesystem, right? tty mtime updates aren't marked dirty, so aren't written back to disk. Intentionally. It seems the tty mtime exception doesn't include /dev/ptmx. That's probably unintentional. Is there a chance to extend the tty mtime exception to all char devices or at least major 4+5? Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: updating mtime for char/block devices?
Arjan van de Ven schrieb: > On Mon, 2005-02-28 at 00:51 +0100, Carl-Daniel Hailfinger wrote: > >>Hi, >> >>is it intentional that >>echo foo >/dev/hda1 >>doesn't update the mtime of the device node, but >>echo foo >/dev/tty10 >>does update the mtime of the device node? >> >>And no, mounting with the noatime flag doesn't help because the >>mtime is updated. IIRC some time ago this behaviour was different, >>but I could easily be mistaken. > > > devices are tricky in general in this respect, /dev may be mounted read > only for example ;) Sorry for not specifying my real problem which is preventing disk access when my laptop is running on battery. Can I prevent mtime updates for all device files? Mounting /dev readonly would certainly help, but for that to work I'd have to move /dev to a different filesystem, right? Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: updating mtime for char/block devices?
Arjan van de Ven schrieb: On Mon, 2005-02-28 at 00:51 +0100, Carl-Daniel Hailfinger wrote: Hi, is it intentional that echo foo /dev/hda1 doesn't update the mtime of the device node, but echo foo /dev/tty10 does update the mtime of the device node? And no, mounting with the noatime flag doesn't help because the mtime is updated. IIRC some time ago this behaviour was different, but I could easily be mistaken. devices are tricky in general in this respect, /dev may be mounted read only for example ;) Sorry for not specifying my real problem which is preventing disk access when my laptop is running on battery. Can I prevent mtime updates for all device files? Mounting /dev readonly would certainly help, but for that to work I'd have to move /dev to a different filesystem, right? Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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/
updating mtime for char/block devices?
Hi, is it intentional that echo foo >/dev/hda1 doesn't update the mtime of the device node, but echo foo >/dev/tty10 does update the mtime of the device node? And no, mounting with the noatime flag doesn't help because the mtime is updated. IIRC some time ago this behaviour was different, but I could easily be mistaken. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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/
updating mtime for char/block devices?
Hi, is it intentional that echo foo /dev/hda1 doesn't update the mtime of the device node, but echo foo /dev/tty10 does update the mtime of the device node? And no, mounting with the noatime flag doesn't help because the mtime is updated. IIRC some time ago this behaviour was different, but I could easily be mistaken. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3 (fwd)
Pavel Machek schrieb: > >>>I'm not sure if you can push the whole industry at once. >> >>The goal is to know what to tell the system vendors >>interested in supporting Linux what they should do >>with their BIOS on future platforms. >> >>I believe our message should be: >>1. BIOS should save/restore video in S3 > > Actually, that'd expect too much of BIOS writers. I believe right > solution is "POST video as you do during normal boot in S3 resume". Why not leave the choice to the BIOS writers? If some are able to save/restore video state by themselves, we shoudln't stop them. As long as the state after resume accepts setting the mode without lockup, we should be fine. >>2. Use Intel's ACPICA ASL compiler -- if not for production, >>then at least as a static source code checker for validation. > > > 3. Try to boot linux (here's live cd). If it complains about bios bugs > (dmesg | grep ...), try to see if it is not indeed your bug. That could even be automated more. A live cd which boots, performs a few tests, displays the results on screen and offers an option to save these results to usbstick/network/disk/whatever. After saving the boot results, it will perform a S3 suspend and resume and display/save the results of that, too. If Intel have enough money, they could provide the functionality on a hard disk and it would have the benefit that S4 could be tested as well. If the disk has a FAT32 partition, the results can be saved there. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Pavel Machek schrieb: > >>>to reinitialise the graphics hardware, few are going to care about >>>making life easier for Linux. >> > [...] >>3. Get some shiny certification/label going that can be put on >>fully conforming products as a sticker. Something like the old >>"EPA pollution preventer" logo, but with a more appealing design. >>Perhaps a "InstantOn/PowerSave" sticker, you get the idea. > > Like "This machine actually works" sticker? :-) Yes. >>4. Include a mandantory description of video bringup after resume > > That sounds overcomplicated. Simply add this to the specs: You have to start to think like a vendor with a long legacy. Then my spec draft will make more sense. Basically, you can't tell a vendor that his hardware is broken or he will ignore your efforts from that point on. "It's a question of honour." If, on the other hand, a vendor can claim his products are conforming to the spec by issuing a software update for broken hardware, it is much more likely that the spec gets accepted. > "BIOS must POST video during S3 wakeup. Video must be working > and in 80x25 text mode when it jumps to OS. VESA BIOS calls must be > available to the OS." That would make some products non-conformant which are working perfectly today. If the video state is preserved over S3, it doesn't make sense to declare that behaviour non-conformant. > BIOS must do that during normal boot; this should be very little > additional work. Not necessarily. Some BIOSes stay in graphics mode during the whole bootup (at least it seems so) and would have to include additional code to enter 80x25 text mode. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Vernon Mauery schrieb: > Carl-Daniel Hailfinger wrote: > >>1. A first step towards better DSDTs would be to make the ASL compiler >>complain about the same things which are complained about by the >>in-kernel ACPI interpreter. An example would be the following: >> >>acpi_processor-0496 [10] acpi_processor_get_inf: Invalid PBLK length [7] >> >>The ASL compiler will not complain about it, yet the kernel will >>refuse to do any processor throttling with a PBLK length of 7. > > > This is like getting gcc to complain about run-time bugs in a program. Oh, gcc does that to a certain extent. For example, it has warnings like "this comparison is always true" or "value too big for selected type". > The compiler of a language (ASL in this case) compiles the language, > regardless of run-time bugs because it can only detect syntax errors. > And iasl does that pretty well. It is possible to do quite a bit of semantic verification at compile time, but of course there are limits to everything. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Matthew Garrett schrieb: > On Thu, 2005-02-17 at 01:16 -0500, Len Brown wrote: > >>I think that it is the BIOS' job on S3-suspend >>to save the video mode. On S3-resume the BIOS should >>re-POST and restore the video mode. > > I agree, but in the absence of spec requirement and some form of > certification process, I don't see it happening in the near future. > Given that vendors are still shipping invalid DSDTs, if Windows is able > to reinitialise the graphics hardware, few are going to care about > making life easier for Linux. 1. A first step towards better DSDTs would be to make the ASL compiler complain about the same things which are complained about by the in-kernel ACPI interpreter. An example would be the following: acpi_processor-0496 [10] acpi_processor_get_inf: Invalid PBLK length [7] The ASL compiler will not complain about it, yet the kernel will refuse to do any processor throttling with a PBLK length of 7. 2. Urge/force vendors to use the latest ASL compiler available. In most cases, this will result in a size reduction of the compiled code, which should be in the interest of the vendors. 3. Get some shiny certification/label going that can be put on fully conforming products as a sticker. Something like the old "EPA pollution preventer" logo, but with a more appealing design. Perhaps a "InstantOn/PowerSave" sticker, you get the idea. 4. Include a mandantory description of video bringup after resume into the ACPI spec along the lines of "Conforming products SHOULD make information about handling of the primary video device on resume available to the ACPI interpreter during runtime. If video state will be preserved over a suspend/resume cycle, the _WAK method for said video device MUST be empty. If the video device requires any actions by the operating system after resume to restore the state it had before suspend, the _WAK method for said video device MUST contain ALL the code needed to restore the state before suspend. The _WAK method MAY call OS-supplied ACPI helper functions like ACPI_EXECUTE_CODE_FROM_ROM to keep the _WAK method short. If no _WAK method for a given video device is available, the OS MUST be able to rely on the fact that video state is preserved over suspend/resume. Something like item 4 would be a major step forward and as a bonus, it wouldn't require any hardware changes, only perhaps 3 or 4 additional lines of code in the DSDT. If the _WAK function for my laptop graphics card existed and had the hypothetical commands ACPI_EXECUTE_CODE_FROM_ROM_X86(VGA.ROM) ACPI_RESTORE_VESA_STATE(VGA) we wouldn't have this discussion in the first place. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Matthew Garrett schrieb: On Thu, 2005-02-17 at 01:16 -0500, Len Brown wrote: I think that it is the BIOS' job on S3-suspend to save the video mode. On S3-resume the BIOS should re-POST and restore the video mode. I agree, but in the absence of spec requirement and some form of certification process, I don't see it happening in the near future. Given that vendors are still shipping invalid DSDTs, if Windows is able to reinitialise the graphics hardware, few are going to care about making life easier for Linux. 1. A first step towards better DSDTs would be to make the ASL compiler complain about the same things which are complained about by the in-kernel ACPI interpreter. An example would be the following: acpi_processor-0496 [10] acpi_processor_get_inf: Invalid PBLK length [7] The ASL compiler will not complain about it, yet the kernel will refuse to do any processor throttling with a PBLK length of 7. 2. Urge/force vendors to use the latest ASL compiler available. In most cases, this will result in a size reduction of the compiled code, which should be in the interest of the vendors. 3. Get some shiny certification/label going that can be put on fully conforming products as a sticker. Something like the old EPA pollution preventer logo, but with a more appealing design. Perhaps a InstantOn/PowerSave sticker, you get the idea. 4. Include a mandantory description of video bringup after resume into the ACPI spec along the lines of Conforming products SHOULD make information about handling of the primary video device on resume available to the ACPI interpreter during runtime. If video state will be preserved over a suspend/resume cycle, the _WAK method for said video device MUST be empty. If the video device requires any actions by the operating system after resume to restore the state it had before suspend, the _WAK method for said video device MUST contain ALL the code needed to restore the state before suspend. The _WAK method MAY call OS-supplied ACPI helper functions like ACPI_EXECUTE_CODE_FROM_ROM to keep the _WAK method short. If no _WAK method for a given video device is available, the OS MUST be able to rely on the fact that video state is preserved over suspend/resume. Something like item 4 would be a major step forward and as a bonus, it wouldn't require any hardware changes, only perhaps 3 or 4 additional lines of code in the DSDT. If the _WAK function for my laptop graphics card existed and had the hypothetical commands ACPI_EXECUTE_CODE_FROM_ROM_X86(VGA.ROM) ACPI_RESTORE_VESA_STATE(VGA) we wouldn't have this discussion in the first place. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Vernon Mauery schrieb: Carl-Daniel Hailfinger wrote: 1. A first step towards better DSDTs would be to make the ASL compiler complain about the same things which are complained about by the in-kernel ACPI interpreter. An example would be the following: acpi_processor-0496 [10] acpi_processor_get_inf: Invalid PBLK length [7] The ASL compiler will not complain about it, yet the kernel will refuse to do any processor throttling with a PBLK length of 7. This is like getting gcc to complain about run-time bugs in a program. Oh, gcc does that to a certain extent. For example, it has warnings like this comparison is always true or value too big for selected type. The compiler of a language (ASL in this case) compiles the language, regardless of run-time bugs because it can only detect syntax errors. And iasl does that pretty well. It is possible to do quite a bit of semantic verification at compile time, but of course there are limits to everything. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Pavel Machek schrieb: to reinitialise the graphics hardware, few are going to care about making life easier for Linux. [...] 3. Get some shiny certification/label going that can be put on fully conforming products as a sticker. Something like the old EPA pollution preventer logo, but with a more appealing design. Perhaps a InstantOn/PowerSave sticker, you get the idea. Like This machine actually works sticker? :-) Yes. 4. Include a mandantory description of video bringup after resume That sounds overcomplicated. Simply add this to the specs: You have to start to think like a vendor with a long legacy. Then my spec draft will make more sense. Basically, you can't tell a vendor that his hardware is broken or he will ignore your efforts from that point on. It's a question of honour. If, on the other hand, a vendor can claim his products are conforming to the spec by issuing a software update for broken hardware, it is much more likely that the spec gets accepted. BIOS must POST video during S3 wakeup. Video must be working and in 80x25 text mode when it jumps to OS. VESA BIOS calls must be available to the OS. That would make some products non-conformant which are working perfectly today. If the video state is preserved over S3, it doesn't make sense to declare that behaviour non-conformant. BIOS must do that during normal boot; this should be very little additional work. Not necessarily. Some BIOSes stay in graphics mode during the whole bootup (at least it seems so) and would have to include additional code to enter 80x25 text mode. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3 (fwd)
Pavel Machek schrieb: I'm not sure if you can push the whole industry at once. The goal is to know what to tell the system vendors interested in supporting Linux what they should do with their BIOS on future platforms. I believe our message should be: 1. BIOS should save/restore video in S3 Actually, that'd expect too much of BIOS writers. I believe right solution is POST video as you do during normal boot in S3 resume. Why not leave the choice to the BIOS writers? If some are able to save/restore video state by themselves, we shoudln't stop them. As long as the state after resume accepts setting the mode without lockup, we should be fine. 2. Use Intel's ACPICA ASL compiler -- if not for production, then at least as a static source code checker for validation. 3. Try to boot linux (here's live cd). If it complains about bios bugs (dmesg | grep ...), try to see if it is not indeed your bug. That could even be automated more. A live cd which boots, performs a few tests, displays the results on screen and offers an option to save these results to usbstick/network/disk/whatever. After saving the boot results, it will perform a S3 suspend and resume and display/save the results of that, too. If Intel have enough money, they could provide the functionality on a hard disk and it would have the benefit that S4 could be tested as well. If the disk has a FAT32 partition, the results can be saved there. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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/
[PATCH] pci/quirks.c: unhide SMBus device on Samsung P35 laptop
Hi,
this patch is needed to make the SMBus device on my Samsung P35
laptop visible. By default, it doesn't appear as a pci device.
Patch tested, works perfectly for me. Please apply.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Signed-off-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
= drivers/pci/quirks.c 1.68 vs edited =
--- 1.68/drivers/pci/quirks.c 2005-02-03 07:42:20 +01:00
+++ edited/drivers/pci/quirks.c 2005-02-16 23:50:49 +01:00
@@ -801,6 +801,12 @@
case 0x12bc: /* HP D330L */
asus_hides_smbus = 1;
}
+ } else if (unlikely(dev->subsystem_vendor == PCI_VENDOR_ID_SAMSUNG)) {
+ if (dev->device == PCI_DEVICE_ID_INTEL_82855PM_HB)
+ switch(dev->subsystem_device) {
+ case 0xC00C: /* Samsung P35 notebook */
+ asus_hides_smbus = 1;
+ }
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82845_HB,
asus_hides_smbus_hostbridge );
= include/linux/pci_ids.h 1.200 vs edited =
--- 1.200/include/linux/pci_ids.h 2005-01-31 07:33:43 +01:00
+++ edited/include/linux/pci_ids.h 2005-02-16 23:48:09 +01:00
@@ -1905,6 +1905,8 @@
#define PCI_DEVICE_ID_OXSEMI_16PCI954PP0x9513
#define PCI_DEVICE_ID_OXSEMI_16PCI952 0x9521
+#define PCI_VENDOR_ID_SAMSUNG 0x144d
+
#define PCI_VENDOR_ID_AIRONET 0x14b9
#define PCI_DEVICE_ID_AIRONET_4800_1 0x0001
#define PCI_DEVICE_ID_AIRONET_4800 0x4500 // values switched? see
-
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: [ACPI] Call for help: list of machines with working S3
Stefan Dösinger schrieb: >>The problems with this patch are: >>- you need to press a key to come back from the "resume-console" after >>resume. - DRI in X does not work (at least for me with intel-agp, others >>reportet it works) >>I just disabloed it by not loading intel-agp (hotplug-blacklist) > > You can force the radeon X driver to use pci mode by setting Option > "ForcePciMode" to "true" or something simmilar in you X config file. This way > you can get dri without intel-agp. This is much slower, but enought to play > tuxracer ;-) How do I enable DRI with my card to test that crash? I have the following in my XF86Config: Section "DRI" Group "video" Mode 0660 EndSection but nothing else about DRI. So do I have to change something in my configuration? Oh, and could you please include run "lspci -vv" and include the part about VGA compatible controller in your mail? I have some hypothesis about the settings there having to do with resume. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Romano Giannetti schrieb: > On Tue, Feb 15, 2005 at 06:08:37PM +0100, Norbert Preining wrote: > >>On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: >> >>>To suspend and resume properly, call the following script as root: >> >>Success. > > I tried with my Sony Vaio FX701. No luck. It goes S3 ok, but it will never > come back (blank screen, HDD led fixed on). > > I am wishing to help, imply tell me what I have to do. Please tell us about your graphics chipset, your .config, your dmesg and the modules loaded. Then we my be able to help. Regards, Carl-Daniel P.S. If anyone of you is running SUSE 9.2, try their latest kernels from ftp.suse.com/pub/projects/kernel/kotd/i386/HEAD/ Additionally, you may have to upgrade mkinitrd and udev with packages from ftp.suse.com/pub/projects and ftp.suse.com/pub/people (try searching around a bit and you'll surely find them). I'm running a kernel from there right now and can still use S3 without problems on my Samsung P35. -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Romano Giannetti schrieb: On Tue, Feb 15, 2005 at 06:08:37PM +0100, Norbert Preining wrote: On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: To suspend and resume properly, call the following script as root: Success. I tried with my Sony Vaio FX701. No luck. It goes S3 ok, but it will never come back (blank screen, HDD led fixed on). I am wishing to help, imply tell me what I have to do. Please tell us about your graphics chipset, your .config, your dmesg and the modules loaded. Then we my be able to help. Regards, Carl-Daniel P.S. If anyone of you is running SUSE 9.2, try their latest kernels from ftp.suse.com/pub/projects/kernel/kotd/i386/HEAD/ Additionally, you may have to upgrade mkinitrd and udev with packages from ftp.suse.com/pub/projects and ftp.suse.com/pub/people (try searching around a bit and you'll surely find them). I'm running a kernel from there right now and can still use S3 without problems on my Samsung P35. -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Stefan Dösinger schrieb: The problems with this patch are: - you need to press a key to come back from the resume-console after resume. - DRI in X does not work (at least for me with intel-agp, others reportet it works) I just disabloed it by not loading intel-agp (hotplug-blacklist) You can force the radeon X driver to use pci mode by setting Option ForcePciMode to true or something simmilar in you X config file. This way you can get dri without intel-agp. This is much slower, but enought to play tuxracer ;-) How do I enable DRI with my card to test that crash? I have the following in my XF86Config: Section DRI Group video Mode 0660 EndSection but nothing else about DRI. So do I have to change something in my configuration? Oh, and could you please include run lspci -vv and include the part about VGA compatible controller in your mail? I have some hypothesis about the settings there having to do with resume. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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/
[PATCH] pci/quirks.c: unhide SMBus device on Samsung P35 laptop
Hi,
this patch is needed to make the SMBus device on my Samsung P35
laptop visible. By default, it doesn't appear as a pci device.
Patch tested, works perfectly for me. Please apply.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
= drivers/pci/quirks.c 1.68 vs edited =
--- 1.68/drivers/pci/quirks.c 2005-02-03 07:42:20 +01:00
+++ edited/drivers/pci/quirks.c 2005-02-16 23:50:49 +01:00
@@ -801,6 +801,12 @@
case 0x12bc: /* HP D330L */
asus_hides_smbus = 1;
}
+ } else if (unlikely(dev-subsystem_vendor == PCI_VENDOR_ID_SAMSUNG)) {
+ if (dev-device == PCI_DEVICE_ID_INTEL_82855PM_HB)
+ switch(dev-subsystem_device) {
+ case 0xC00C: /* Samsung P35 notebook */
+ asus_hides_smbus = 1;
+ }
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82845_HB,
asus_hides_smbus_hostbridge );
= include/linux/pci_ids.h 1.200 vs edited =
--- 1.200/include/linux/pci_ids.h 2005-01-31 07:33:43 +01:00
+++ edited/include/linux/pci_ids.h 2005-02-16 23:48:09 +01:00
@@ -1905,6 +1905,8 @@
#define PCI_DEVICE_ID_OXSEMI_16PCI954PP0x9513
#define PCI_DEVICE_ID_OXSEMI_16PCI952 0x9521
+#define PCI_VENDOR_ID_SAMSUNG 0x144d
+
#define PCI_VENDOR_ID_AIRONET 0x14b9
#define PCI_DEVICE_ID_AIRONET_4800_1 0x0001
#define PCI_DEVICE_ID_AIRONET_4800 0x4500 // values switched? see
-
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: [ACPI] Call for help: list of machines with working S3
Matthew Garrett schrieb: > On Tue, 2005-02-15 at 19:57 +0100, Carl-Daniel Hailfinger wrote: > > >>Kendall Bennett is working with me to get suspend/resume working >>even with framebuffers. Once we have results, I'll post them here. > > > I've had success using vesafb with vbetool state restoration. vga16fb > ought to work fairly happily. Well, in my testing the machine deadlocked if any framebuffer was active during resume. It even deadlocked *before* I could run vbetool. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Norbert Preining schrieb: > On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: > >>To suspend and resume properly, call the following script as root: > > > Success. Great! > After deactivating DRI in the X config file and saving the states with > your script (thanks) and turning off various stuff I get X running > again. > > Questions: > - DRI must be disabled I guess?! Even with newer X server (x.org)? I never disabled it. > - I dont have to restore the font, it is back without any problem > (I have vga console) Good. I guess that's highly chipset-specific. > - Sometimes I have to make a Sysrq-s (sync) to get some stuff running > (eg logging in from the console hangs after input of passwd, calling > sysrq-s makes it continue). I had a similar effect when logging in > AFTER resuming (for the resume I had only gdm running but wasn't > logged in) the GNOME starting screen stayed there indefinitely, no > change. Even after restarting the X server and retrying. > Logging in with twm session DID work without any problem. > Do you have any idea what this could be? Pavel? > - My script is a bit more complicated: stopping: hotplug, mysql, > ifplugd, waproamd, cpufreqd, acpid, ifdown eth0, eth1, rmmod acerhk > echo "performance" onto governor, then going to sleepand doing > more or less the reverse stuff after waking up. > DO you have any experience with hotplug network etc stuff, working > even without stopping? I used to unload modules, shutdown network interfaces etc. until I tried without all that stuff and it still worked. So I concluded that stopping things before suspend was a thing only needed with older kernels. Granted, mounted volumes on USB or IEEE1394 still have problems because the kernel doesn't expect them to disappear for a few moments, but that's nothing a module unload would fix. Simply umount all external drives and use my script. Drivers which still need to be unloaded and reloaded are buggy and have to be fixed. I'll prepare a web page with detailed S3/S4 suspend/resume information for ATI graphics card owners including step-by-step howtos for smooth suspend/resume cycles. Kendall Bennett is working with me to get suspend/resume working even with framebuffers. Once we have results, I'll post them here. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Norbert Preining schrieb: > On Mon, 14 Feb 2005, Pavel Machek wrote: > >>(1) systems where video state is preserved over S3. >> >>(2) systems where it is possible to call video bios during S3 >> resume. Unfortunately, it is not correct to call video BIOS at that >> point, but it happens to work on some machines. Use >> acpi_sleep=s3_bios. >> >>(3) systems that initialize video card into vga text mode and where BIOS >> works well enough to be able to set video mode. Use >> acpi_sleep=s3_mode on these. >> >>(4) on some systems s3_bios kicks video into text mode, and >> acpi_sleep=s3_bios,s3_mode is needed. >> >>(5) radeon systems, where X can soft-boot your video card. You'll need >> patched X, and plain text console (no vesafb or radeonfb), see >> http://www.doesi.gmxhome.de/linux/tm800s3/s3.html. >> >>(6) other radeon systems, where vbetool is enough to bring system back >> to life. Do vbetool vbestate save > /tmp/delme; echo 3 > /proc/acpi/sleep; >> vbetool post; vbetool vbestate restore < /tmp/delme; setfont >> , and your video should work. >> >>Acer TM 800 vga=normal, X patches, see webpage (5) > > > > Acer TM 650 (Radeon M7) > > vga=normal plus boot-radeon (webpage(5)) works to get text console > back. But switching to X freezes the computer completely. Please try method (6). It should work perfectly because it is the successor for method (5) and works even without special patches for X. > X from debian sid. > XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-10 20041215174925 [EMAIL > PROTECTED]) > Release Date: 15 August 2003 > X Protocol Version 11, Revision 0, Release 6.6 > Build Operating System: Linux 2.4.26 i686 [ELF] > Build Date: 15 December 2004 > > > I would like to get X running to, but there are no traces in the logfile > whatsoever to be seen. Pity. First, boot into X and run the following script ONCE: #!/bin/bash statedir=/root/s3/state mkdir -p $statedir chvt 2 sleep 1 vbetool vbestate save >$statedir/vbe To suspend and resume properly, call the following script as root: #!/bin/bash statedir=/root/s3/state curcons=`fgconsole` fuser /dev/tty$curcons 2>/dev/null|xargs ps -o comm= -p|grep -q X && chvt 2 cat /dev/vcsa >$statedir/vcsa sync echo 3 >/proc/acpi/sleep sync vbetool post vbetool vbestate restore <$statedir/vbe cat $statedir/vcsa >/dev/vcsa rckbd restart chvt $[curcons%6+1] chvt $curcons Unless you change your grahics card or other hardware configuration, the state once saved will be OK for every resume afterwards. NOTE: The "rckbd restart" command may be different for your distribution. Simply replace it with the command you would use to set the fonts on screen. > So it seems that my laptop does not fall in any of these categories. Please try my scripts and resport back. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Norbert Preining schrieb: On Mon, 14 Feb 2005, Pavel Machek wrote: (1) systems where video state is preserved over S3. (2) systems where it is possible to call video bios during S3 resume. Unfortunately, it is not correct to call video BIOS at that point, but it happens to work on some machines. Use acpi_sleep=s3_bios. (3) systems that initialize video card into vga text mode and where BIOS works well enough to be able to set video mode. Use acpi_sleep=s3_mode on these. (4) on some systems s3_bios kicks video into text mode, and acpi_sleep=s3_bios,s3_mode is needed. (5) radeon systems, where X can soft-boot your video card. You'll need patched X, and plain text console (no vesafb or radeonfb), see http://www.doesi.gmxhome.de/linux/tm800s3/s3.html. (6) other radeon systems, where vbetool is enough to bring system back to life. Do vbetool vbestate save /tmp/delme; echo 3 /proc/acpi/sleep; vbetool post; vbetool vbestate restore /tmp/delme; setfont whatever, and your video should work. Acer TM 800 vga=normal, X patches, see webpage (5) Acer TM 650 (Radeon M7) vga=normal plus boot-radeon (webpage(5)) works to get text console back. But switching to X freezes the computer completely. Please try method (6). It should work perfectly because it is the successor for method (5) and works even without special patches for X. X from debian sid. XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-10 20041215174925 [EMAIL PROTECTED]) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.26 i686 [ELF] Build Date: 15 December 2004 I would like to get X running to, but there are no traces in the logfile whatsoever to be seen. Pity. First, boot into X and run the following script ONCE: #!/bin/bash statedir=/root/s3/state mkdir -p $statedir chvt 2 sleep 1 vbetool vbestate save $statedir/vbe To suspend and resume properly, call the following script as root: #!/bin/bash statedir=/root/s3/state curcons=`fgconsole` fuser /dev/tty$curcons 2/dev/null|xargs ps -o comm= -p|grep -q X chvt 2 cat /dev/vcsa $statedir/vcsa sync echo 3 /proc/acpi/sleep sync vbetool post vbetool vbestate restore $statedir/vbe cat $statedir/vcsa /dev/vcsa rckbd restart chvt $[curcons%6+1] chvt $curcons Unless you change your grahics card or other hardware configuration, the state once saved will be OK for every resume afterwards. NOTE: The rckbd restart command may be different for your distribution. Simply replace it with the command you would use to set the fonts on screen. So it seems that my laptop does not fall in any of these categories. Please try my scripts and resport back. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Norbert Preining schrieb: On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: To suspend and resume properly, call the following script as root: Success. Great! After deactivating DRI in the X config file and saving the states with your script (thanks) and turning off various stuff I get X running again. Questions: - DRI must be disabled I guess?! Even with newer X server (x.org)? I never disabled it. - I dont have to restore the font, it is back without any problem (I have vga console) Good. I guess that's highly chipset-specific. - Sometimes I have to make a Sysrq-s (sync) to get some stuff running (eg logging in from the console hangs after input of passwd, calling sysrq-s makes it continue). I had a similar effect when logging in AFTER resuming (for the resume I had only gdm running but wasn't logged in) the GNOME starting screen stayed there indefinitely, no change. Even after restarting the X server and retrying. Logging in with twm session DID work without any problem. Do you have any idea what this could be? Pavel? - My script is a bit more complicated: stopping: hotplug, mysql, ifplugd, waproamd, cpufreqd, acpid, ifdown eth0, eth1, rmmod acerhk echo performance onto governor, then going to sleepand doing more or less the reverse stuff after waking up. DO you have any experience with hotplug network etc stuff, working even without stopping? I used to unload modules, shutdown network interfaces etc. until I tried without all that stuff and it still worked. So I concluded that stopping things before suspend was a thing only needed with older kernels. Granted, mounted volumes on USB or IEEE1394 still have problems because the kernel doesn't expect them to disappear for a few moments, but that's nothing a module unload would fix. Simply umount all external drives and use my script. Drivers which still need to be unloaded and reloaded are buggy and have to be fixed. I'll prepare a web page with detailed S3/S4 suspend/resume information for ATI graphics card owners including step-by-step howtos for smooth suspend/resume cycles. Kendall Bennett is working with me to get suspend/resume working even with framebuffers. Once we have results, I'll post them here. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Matthew Garrett schrieb: On Tue, 2005-02-15 at 19:57 +0100, Carl-Daniel Hailfinger wrote: Kendall Bennett is working with me to get suspend/resume working even with framebuffers. Once we have results, I'll post them here. I've had success using vesafb with vbetool state restoration. vga16fb ought to work fairly happily. Well, in my testing the machine deadlocked if any framebuffer was active during resume. It even deadlocked *before* I could run vbetool. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Pavel Machek schrieb: > Hi! > > Stefan provided me initial list of machines where S3 works (including > video). If you have machine that is not on the list, please send me a > diff. If you have eMachines... I'd like you to try playing with > vbetool (it worked for me), and if it works for you supplying right > model numbers. > > Pavel > > > Video issues with S3 resume > ~~~ > 2003-2005, Pavel Machek > > During S3 resume, hardware needs to be reinitialized. For most > devices, this is easy, and kernel driver knows how to do > it. Unfortunately there's one exception: video card. Those are usually > initialized by BIOS, and kernel does not have enough information to > boot video card. (Kernel usually does not even contain video card > driver -- vesafb and vgacon are widely used). > > This is not problem for swsusp, because during swsusp resume, BIOS is > run normally so video card is normally initialized. S3 has absolutely > no change to work with SMP/HT. Be sure it to turn it off before > testing (swsusp should work ok, OTOH). > > There are few types of systems where video works after S3 resume: > > (1) systems where video state is preserved over S3. > > (2) systems where it is possible to call video bios during S3 > resume. Unfortunately, it is not correct to call video BIOS at that > point, but it happens to work on some machines. Use > acpi_sleep=s3_bios. > > (3) systems that initialize video card into vga text mode and where BIOS > works well enough to be able to set video mode. Use > acpi_sleep=s3_mode on these. > > (4) on some systems s3_bios kicks video into text mode, and > acpi_sleep=s3_bios,s3_mode is needed. > > (5) radeon systems, where X can soft-boot your video card. You'll need > patched X, and plain text console (no vesafb or radeonfb), see > http://www.doesi.gmxhome.de/linux/tm800s3/s3.html. (5) machines should also work with (6), but not the other way round. > > (6) other radeon systems, where vbetool is enough to bring system back > to life. Do vbetool vbestate save > /tmp/delme; echo 3 > /proc/acpi/sleep; > vbetool post; vbetool vbestate restore < /tmp/delme; setfont > , and your video should work. (6) has to be done from a text console! It should work for all radeon systems, btw. > > Now, if you pass acpi_sleep=something, and it does not work with your > bios, you'll get hard crash during resume. Be carefull. Also it is > safest to do your experiments with plain old VGA console. vesafb and > radeonfb (etc) drivers have tendency to crash the machine during resume. > > You may have system where none of above works. At that point you > either invent another ugly hack that works, or write proper driver for > your video card (good luck getting docs :-(). Maybe suspending from X > (proper X, knowing your hardware, not XF68_FBcon) might have better > chance of working. > > Table of known working systems: > > Model hack (or "how to do it") > -- > IBM TP R32 / Type 2658-MMG none (1) > Athlon HP Omnibook XE3none (1) > Compaq Armada E500 - P3-700 none (1) (S1 also works OK) > IBM t41p none (1) > Athlon64 desktop prototypes3_bios (2) > HP NC6000 s3_bios (2) > Toshiba Satellite 4080XCDT s3_mode (3) > Toshiba Satellite 4030CDT s3_mode (3) > Dell D600, ATI RV250vga=normal (**) The Dell system above should also work fine with vbestate. > Asus L2400D s3_mode (3)(***) (S1 also works OK) > Toshiba Satellite P10-554 s3_bios,s3_mode (4)() > Acer TM 800 vga=normal, X patches, see webpage (5) > Athlon64 Arima W730a vbestate needed (6) > eMachines athlon64 machines vbestate needed (6) (someone please get me > model #s) Samsung P35 vbestate needed (6) > > (**) Text console is "strange" after resume. Backlight is switched on again > by the X server. X server is: > | X Window System Version 6.8.1.904 (6.8.2 RC 4) > | Release Date: 2 February 2005 > | X Protocol Version 11, Revision 0, Release 6.8.1.904 > | Build Operating System: SuSE Linux [ELF] SuSE > as present in SUSE 9.3preview3. > > (***) To be tested with a newer kernel. > > () Not with SMP kernel, UP only. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Call for help: list of machines with working S3
Pavel Machek schrieb: Hi! Stefan provided me initial list of machines where S3 works (including video). If you have machine that is not on the list, please send me a diff. If you have eMachines... I'd like you to try playing with vbetool (it worked for me), and if it works for you supplying right model numbers. Pavel Video issues with S3 resume ~~~ 2003-2005, Pavel Machek During S3 resume, hardware needs to be reinitialized. For most devices, this is easy, and kernel driver knows how to do it. Unfortunately there's one exception: video card. Those are usually initialized by BIOS, and kernel does not have enough information to boot video card. (Kernel usually does not even contain video card driver -- vesafb and vgacon are widely used). This is not problem for swsusp, because during swsusp resume, BIOS is run normally so video card is normally initialized. S3 has absolutely no change to work with SMP/HT. Be sure it to turn it off before testing (swsusp should work ok, OTOH). There are few types of systems where video works after S3 resume: (1) systems where video state is preserved over S3. (2) systems where it is possible to call video bios during S3 resume. Unfortunately, it is not correct to call video BIOS at that point, but it happens to work on some machines. Use acpi_sleep=s3_bios. (3) systems that initialize video card into vga text mode and where BIOS works well enough to be able to set video mode. Use acpi_sleep=s3_mode on these. (4) on some systems s3_bios kicks video into text mode, and acpi_sleep=s3_bios,s3_mode is needed. (5) radeon systems, where X can soft-boot your video card. You'll need patched X, and plain text console (no vesafb or radeonfb), see http://www.doesi.gmxhome.de/linux/tm800s3/s3.html. (5) machines should also work with (6), but not the other way round. (6) other radeon systems, where vbetool is enough to bring system back to life. Do vbetool vbestate save /tmp/delme; echo 3 /proc/acpi/sleep; vbetool post; vbetool vbestate restore /tmp/delme; setfont whatever, and your video should work. (6) has to be done from a text console! It should work for all radeon systems, btw. Now, if you pass acpi_sleep=something, and it does not work with your bios, you'll get hard crash during resume. Be carefull. Also it is safest to do your experiments with plain old VGA console. vesafb and radeonfb (etc) drivers have tendency to crash the machine during resume. You may have system where none of above works. At that point you either invent another ugly hack that works, or write proper driver for your video card (good luck getting docs :-(). Maybe suspending from X (proper X, knowing your hardware, not XF68_FBcon) might have better chance of working. Table of known working systems: Model hack (or how to do it) -- IBM TP R32 / Type 2658-MMG none (1) Athlon HP Omnibook XE3none (1) Compaq Armada E500 - P3-700 none (1) (S1 also works OK) IBM t41p none (1) Athlon64 desktop prototypes3_bios (2) HP NC6000 s3_bios (2) Toshiba Satellite 4080XCDT s3_mode (3) Toshiba Satellite 4030CDT s3_mode (3) Dell D600, ATI RV250vga=normal (**) The Dell system above should also work fine with vbestate. Asus L2400D s3_mode (3)(***) (S1 also works OK) Toshiba Satellite P10-554 s3_bios,s3_mode (4)() Acer TM 800 vga=normal, X patches, see webpage (5) Athlon64 Arima W730a vbestate needed (6) eMachines athlon64 machines vbestate needed (6) (someone please get me model #s) Samsung P35 vbestate needed (6) (**) Text console is strange after resume. Backlight is switched on again by the X server. X server is: | X Window System Version 6.8.1.904 (6.8.2 RC 4) | Release Date: 2 February 2005 | X Protocol Version 11, Revision 0, Release 6.8.1.904 | Build Operating System: SuSE Linux [ELF] SuSE as present in SUSE 9.3preview3. (***) To be tested with a newer kernel. () Not with SMP kernel, UP only. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: EDD failures since edd=off patch
Matt Domsch schrieb:
> On Thu, Feb 10, 2005 at 03:11:52PM +0100, Carl-Daniel Hailfinger wrote:
>
>>Hi Matt,
>>
>>it seems the edd=off patch has caused some problems with
>>some machines I have access to. They simply don't boot
>>anymore unless I specify edd=foo. foo can be {off,skip,bar}
>>so it seems the hang on boot is related to the parser
>>not finding the parameter it is looking for.
>>I looked through the code some days ago and it seemed to
>>me that the register used to iterate through the command
>>line buffer only got its lower 16 bit reset before calling
>>into the BIOS. I don't have the code handy right now,
>>but I can look later if the hints I gave are insufficient.
>
>
> Yes, please. I'm reading the code, and %ecx gets set to
> (COMMAND_LINE_SIZE-7) which is 256-7=249. So the upper 24 bits of
> %ecx are going to always be zero, and if "edd=" isn't seen, then %ecx
> will be zero when dropping into edd_mbr_sig_start. The only other
> register touched is %esi, but it's pushed at the beginning, and pop'd
> on all exit cases, so that should be unchanged.
>
> ZF is the only other bit I can picture. On the "no edd= option" path,
> ZF=0 on exit. With "edd=of" or "edd=sk", ZF=1. But with "edd=bar",
> ZF=0, which you say works too. So that's not it...
>
> CF is taken care of around the int13 calls already, so that's not
> it...
It all boils down to the question: When do the flags set by INCL
differ from those set by CMPW? We have already ruled out CF and ZF,
so only OF, SF, AF, PF can be the culprit.
Looking again, I think it will hang with edd=zz, but I have to verify
that.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
-
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: [ACPI] Re: [RFC] Reliable video POSTing on resume
Li-Ta Lo schrieb: > On Mon, 2005-02-07 at 09:01, Pavel Machek wrote: > 3 - it's always there and can be executed at *any* time: booting, returning from suspend, etc. Also it would allow the VESA framebuffer driver to change graphics mode at any time (for instance). >>> >>>OK, and what would force you to do the above in the kernel? If the code >>>lives in initramfs, it can be called very early, too. >> >>It will be easier to debug in kernel than in initramfs, for >>one. Kernel code is bad enough, but initramfs running while kernel is >>not even initialized is going to be even more "fun". > > One good thing about the emulator is it is very portable. There is > virtually no stdlib dependency. We can freely move it between user > and kernel space. When integrating the emulator into LinuxBIOS, > we first tried to use it as an user space program and then "port" it > into "kernel" space. The porting was done in a few days and the most > of the time was spent fixing LinuxBIOS itself than doing any "porting". > Actually, the same emulator source were used in both user and kernel > space as a kind of regression test. Do you have a kernel patch against a recent kernel? I'd like to try the in-kernel emulator. A userspace variant would also be fine, provided it solves the "VGA BIOS calls normal BIOS" type of problem I'm seeing on my machine (Samsung P35 laptop with ATI Radeon Mobility 9700). Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Re: [RFC] Reliable video POSTing on resume
Jon Smirl schrieb: > On Thu, 10 Feb 2005 21:06:36 +, Matthew Garrett <[EMAIL PROTECTED]> wrote: > >>On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote: >> >> >>>So perhaps this problem is something similar? > > > What type of computer has the problem? Who makes it's video chips? Samsung P35 notebook with ATI Mobility Radeon 9700. IIRC I saw the c000: jump on my machine. Give me code to test and I'll mail you the results in a few minutes. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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/
EDD failures since edd=off patch
Hi Matt,
it seems the edd=off patch has caused some problems with
some machines I have access to. They simply don't boot
anymore unless I specify edd=foo. foo can be {off,skip,bar}
so it seems the hang on boot is related to the parser
not finding the parameter it is looking for.
I looked through the code some days ago and it seemed to
me that the register used to iterate through the command
line buffer only got its lower 16 bit reset before calling
into the BIOS. I don't have the code handy right now,
but I can look later if the hints I gave are insufficient.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
-
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/
EDD failures since edd=off patch
Hi Matt,
it seems the edd=off patch has caused some problems with
some machines I have access to. They simply don't boot
anymore unless I specify edd=foo. foo can be {off,skip,bar}
so it seems the hang on boot is related to the parser
not finding the parameter it is looking for.
I looked through the code some days ago and it seemed to
me that the register used to iterate through the command
line buffer only got its lower 16 bit reset before calling
into the BIOS. I don't have the code handy right now,
but I can look later if the hints I gave are insufficient.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
-
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: [ACPI] Re: [RFC] Reliable video POSTing on resume
Jon Smirl schrieb: On Thu, 10 Feb 2005 21:06:36 +, Matthew Garrett [EMAIL PROTECTED] wrote: On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote: So perhaps this problem is something similar? What type of computer has the problem? Who makes it's video chips? Samsung P35 notebook with ATI Mobility Radeon 9700. IIRC I saw the c000: jump on my machine. Give me code to test and I'll mail you the results in a few minutes. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [ACPI] Re: [RFC] Reliable video POSTing on resume
Li-Ta Lo schrieb: On Mon, 2005-02-07 at 09:01, Pavel Machek wrote: 3 - it's always there and can be executed at *any* time: booting, returning from suspend, etc. Also it would allow the VESA framebuffer driver to change graphics mode at any time (for instance). OK, and what would force you to do the above in the kernel? If the code lives in initramfs, it can be called very early, too. It will be easier to debug in kernel than in initramfs, for one. Kernel code is bad enough, but initramfs running while kernel is not even initialized is going to be even more fun. One good thing about the emulator is it is very portable. There is virtually no stdlib dependency. We can freely move it between user and kernel space. When integrating the emulator into LinuxBIOS, we first tried to use it as an user space program and then port it into kernel space. The porting was done in a few days and the most of the time was spent fixing LinuxBIOS itself than doing any porting. Actually, the same emulator source were used in both user and kernel space as a kind of regression test. Do you have a kernel patch against a recent kernel? I'd like to try the in-kernel emulator. A userspace variant would also be fine, provided it solves the VGA BIOS calls normal BIOS type of problem I'm seeing on my machine (Samsung P35 laptop with ATI Radeon Mobility 9700). Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: EDD failures since edd=off patch
Matt Domsch schrieb:
On Thu, Feb 10, 2005 at 03:11:52PM +0100, Carl-Daniel Hailfinger wrote:
Hi Matt,
it seems the edd=off patch has caused some problems with
some machines I have access to. They simply don't boot
anymore unless I specify edd=foo. foo can be {off,skip,bar}
so it seems the hang on boot is related to the parser
not finding the parameter it is looking for.
I looked through the code some days ago and it seemed to
me that the register used to iterate through the command
line buffer only got its lower 16 bit reset before calling
into the BIOS. I don't have the code handy right now,
but I can look later if the hints I gave are insufficient.
Yes, please. I'm reading the code, and %ecx gets set to
(COMMAND_LINE_SIZE-7) which is 256-7=249. So the upper 24 bits of
%ecx are going to always be zero, and if edd= isn't seen, then %ecx
will be zero when dropping into edd_mbr_sig_start. The only other
register touched is %esi, but it's pushed at the beginning, and pop'd
on all exit cases, so that should be unchanged.
ZF is the only other bit I can picture. On the no edd= option path,
ZF=0 on exit. With edd=of or edd=sk, ZF=1. But with edd=bar,
ZF=0, which you say works too. So that's not it...
CF is taken care of around the int13 calls already, so that's not
it...
It all boils down to the question: When do the flags set by INCL
differ from those set by CMPW? We have already ruled out CF and ZF,
so only OF, SF, AF, PF can be the culprit.
Looking again, I think it will hang with edd=zz, but I have to verify
that.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
-
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] Reliable video POSTing on resume
Paulo Marques schrieb: > Adam Sulmicki wrote: > >> >> hi all, >> I would like point to work done by Li-Ta Lo. >> >> It allows you to completely initalize the VGA BIOS w/out using >> PC BIOS at all. >> >> >> http://www.clustermatic.org/pipermail/linuxbios/2005-January/010236.html >> unforunatelly the information the web is somewhat sparse, but >> you can get more info by following the archive of the >> thread (which head I listed above) and perhaps by posting to >> linuxbios mailing list (Ollie, is somewhat buy those days with his >> new baby). > > > I did some work on reducing the core x86 emulation code (and have my > name mentioned in that thread for it). The code size went from 59kB to > 38kB. This does not include emulation of BIOS functions or hardware > (like the standard PC timer). > > It seems to me that x86 emulation in the kernel is the way to go because: > > [...] > > 3 - it's always there and can be executed at *any* time: booting, > returning from suspend, etc. Also it would allow the VESA framebuffer > driver to change graphics mode at any time (for instance). OK, and what would force you to do the above in the kernel? If the code lives in initramfs, it can be called very early, too. And how many competing implementations of video helpers/emulation code do we have now? - scitechsoft emu - linuxbios emu - etc. (I surely forgot some) Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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] Reliable video POSTing on resume
Paulo Marques schrieb: Adam Sulmicki wrote: hi all, I would like point to work done by Li-Ta Lo. It allows you to completely initalize the VGA BIOS w/out using PC BIOS at all. http://www.clustermatic.org/pipermail/linuxbios/2005-January/010236.html unforunatelly the information the web is somewhat sparse, but you can get more info by following the archive of the thread (which head I listed above) and perhaps by posting to linuxbios mailing list (Ollie, is somewhat buy those days with his new baby). I did some work on reducing the core x86 emulation code (and have my name mentioned in that thread for it). The code size went from 59kB to 38kB. This does not include emulation of BIOS functions or hardware (like the standard PC timer). It seems to me that x86 emulation in the kernel is the way to go because: [...] 3 - it's always there and can be executed at *any* time: booting, returning from suspend, etc. Also it would allow the VESA framebuffer driver to change graphics mode at any time (for instance). OK, and what would force you to do the above in the kernel? If the code lives in initramfs, it can be called very early, too. And how many competing implementations of video helpers/emulation code do we have now? - scitechsoft emu - linuxbios emu - etc. (I surely forgot some) Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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] Reliable video POSTing on resume
Xavier Bestel schrieb: > Le vendredi 04 fÃvrier 2005 Ã 00:03 -0500, Jon Smirl a Ãcrit : > >>Doing this in user space lets you have two reset >>programs, vm86 and emu86 for non-x86 machines. > > > Perhaps only emu86 should be used, to have a well-debugged codepath on > all archs (amd64, ppc, ...) > As it's usermode, the code size is less of a problem. Well, if it has to live in initramfs, it better be really small. An initramfs with a size of 8 megabytes isn't going to make you many friends. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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] Reliable video POSTing on resume
James Simmons schrieb: >>>int video_helper(struct video_actions *what_to_do) >> >>I do not know, synchronously executing userland code from kernel seems >>like wrong thing to do. > > I'm not a fan for this either. The good news is most graphics cards don't > require these tricks. The only ones that do are the ix86 cards. The real > solution would be if the hradware vendors open the parts of the spec to do > what we need. Many of the older cards could be supported in this way if we > talk to the vendors. They shouldn't care if the specs are released anymore. > The problem would be the latest Radeon card and NVIDIA cards which > unfortunely are the most common cards for x86 platforms ;-( Well, either you call userspace synchronously or you crash on resume. I know what I prefer. And this synchronous call isn't so bad because it comes with a timeout. So whatever the userspace program does, after two seconds the kernel will continue unaffected. Once you execute the code asynchronously, you get nondeterministic behaviour. That's sure fun for filling up your random pool, but I wouldn't trust my data to such a system. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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] Reliable video POSTing on resume
Pavel Machek schrieb: > > I do not understand how initramfs fits into picture... Plus lot of > people (me :-) do not use initramfs... Well, an initrd which is never unmounted should work, too. On SUSE, "mkdir /initrd" and see what you've been missing. I don't know why that directory doesn't exist by default except for the reason that freeing the initrd frees some memory. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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] Reliable video POSTing on resume
Jon Smirl schrieb: > On Fri, 4 Feb 2005 08:44:54 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote: > >>We already try to do that, but it hangs on 70% of machines. See >>Documentation/power/video.txt. > > We know that all of these ROMs are run at power on so they have to > work. This implies that there must be something wrong with the > environment the ROM are being run in. Video ROMs make calls into the > INT vectors of the system BIOS. If these haven't been set up yet > running the VBIOS is sure to hang. Has someone with ROM source and > the appropriate debugging tools tried to debug one of these hangs? > Alternatively code could be added to wakeup.S to try and set these up > or dump the ones that are there and see if they are sane. My problem (Samsung P35) is that the BIOS wants to call code which is no longer mapped because the BIOS is too big to fit into the standard area. Since that additional area has been overwritten, we are out of luck. Maybe if we did something like backing up all untouched real mode memory immediately after switching to protected mode, it could work. But I don't know whether that is feasible on boot. Anyways, you don't want to run possibly buggy closed source bios code in an environment where a single random memory write may corrupt the kernel without debuggability. And sometimes there is BIOS code which is can't be run twice. Period. Don't believe that one? I have a machine where calling EDD code in the BIOS twice will hang the second time. See boot parameter edd=off for reference :-( So I agree that we could try to preserve the state better, but I also can guarantee you it won't help everywhere. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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] Reliable video POSTing on resume
Jon Smirl schrieb: > Reseting a video card from suspend is essentially the same problem as > reseting secondary video cards on boot. The same code can address both > problems. > > Some things to consider > > 1) With multiple video cards you have to ensure only a single VGA gets > enabled. Running video reset on a card is going to turn on it's VGA > emulation. So you have to ensure that VGA emulation on other cards is > disabled first. No problem. Let the kernel tell the userspace application which card to reset. > 2) I add the 'rom' parameter in sysfs so that you can get to the rom > contents from a user space app. It's there to support running video > reset code. "echo 1 >rom" to see the contents, it is not enabled by > default. That could be very helpful for secondary cards. > 3) The user space reset programs have to be serialized because of the > rule about only a single VGA at a time. Calling vm86 from kernel mode > is not a good idea. Doing this in user space lets you have two reset > programs, vm86 and emu86 for non-x86 machines. With the approach I detailed in the thread starter, this is easily possible. vesaposter can call the kernel function used to synchronize in an endless loop and this kernel function would not only be used to synchronize, but its return value would tell vesaposter what to do to which card. An alternative would be to restart vesaposter as soon as it has finished its job, which would make the POSTing reliable even if the BIOS code hangs or causes crashes. The kernel can simply store a list of video devices and their respective treatments and the kernel function called by vesaposter would just iterate through the list. Hmmm... why not call it int video_helper(struct video_actions *what_to_do) and it blocks until we have something to POST. It could contain all the locking needed to serialize access to the video cards. OTOH, if starting applications from initramfs at resume time is easy, we could make video_helper non-blocking and start vesaposter on demand. And the problem of locking all application memory: The current tool for POSTing and restoring video state (vbetool) uses only 27k on disk. If we put it in initramfs, we could maybe avoid mlock completely (if we can guarantee initramfs contents aren't swapped out). And it would be available early enough for initializing video hardware on boot. > A starting place for a user space reset program: > ftp://ftp.scitechsoft.com/devel/obsolete/x86emu/x86emu-0.8.tar.gz > > This thread talks about the VGA routing code: > http://lkml.org/lkml/2005/1/17/347 Thanks for the pointers! I'll have to compare it to our current userspace reset and vesa register restoring program http://www.srcf.ucam.org/~mjg59/vbetool/ Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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] Reliable video POSTing on resume
Oliver Neukum schrieb: > Am Freitag, 4. Februar 2005 08:48 schrieb Pavel Machek: > >>What about simply blocking all video accesses before disk (etc) is >>resumed, so that "normal" (not locked in memory) application can be >>used? > > Very bad for debugging. Genuine serial ports are becoming rarer. As a bonus, even genuine serial ports may be in undefined state after resume. I'm unfortunate enough to have a brand new notebook with serial port, but the serial console code will print garbage after resume until I do a echo foo >/dev/ttyS0 I've already sent mail to linux-serial for that problem, but the list appears to be dead. Any pointers to the right contact would be appreciated. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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] Reliable video POSTing on resume
Jon Smirl schrieb: On Fri, 4 Feb 2005 08:44:54 +0100, Pavel Machek [EMAIL PROTECTED] wrote: We already try to do that, but it hangs on 70% of machines. See Documentation/power/video.txt. We know that all of these ROMs are run at power on so they have to work. This implies that there must be something wrong with the environment the ROM are being run in. Video ROMs make calls into the INT vectors of the system BIOS. If these haven't been set up yet running the VBIOS is sure to hang. Has someone with ROM source and the appropriate debugging tools tried to debug one of these hangs? Alternatively code could be added to wakeup.S to try and set these up or dump the ones that are there and see if they are sane. My problem (Samsung P35) is that the BIOS wants to call code which is no longer mapped because the BIOS is too big to fit into the standard area. Since that additional area has been overwritten, we are out of luck. Maybe if we did something like backing up all untouched real mode memory immediately after switching to protected mode, it could work. But I don't know whether that is feasible on boot. Anyways, you don't want to run possibly buggy closed source bios code in an environment where a single random memory write may corrupt the kernel without debuggability. And sometimes there is BIOS code which is can't be run twice. Period. Don't believe that one? I have a machine where calling EDD code in the BIOS twice will hang the second time. See boot parameter edd=off for reference :-( So I agree that we could try to preserve the state better, but I also can guarantee you it won't help everywhere. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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] Reliable video POSTing on resume
Pavel Machek schrieb: I do not understand how initramfs fits into picture... Plus lot of people (me :-) do not use initramfs... Well, an initrd which is never unmounted should work, too. On SUSE, mkdir /initrd and see what you've been missing. I don't know why that directory doesn't exist by default except for the reason that freeing the initrd frees some memory. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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] Reliable video POSTing on resume
James Simmons schrieb: int video_helper(struct video_actions *what_to_do) I do not know, synchronously executing userland code from kernel seems like wrong thing to do. I'm not a fan for this either. The good news is most graphics cards don't require these tricks. The only ones that do are the ix86 cards. The real solution would be if the hradware vendors open the parts of the spec to do what we need. Many of the older cards could be supported in this way if we talk to the vendors. They shouldn't care if the specs are released anymore. The problem would be the latest Radeon card and NVIDIA cards which unfortunely are the most common cards for x86 platforms ;-( Well, either you call userspace synchronously or you crash on resume. I know what I prefer. And this synchronous call isn't so bad because it comes with a timeout. So whatever the userspace program does, after two seconds the kernel will continue unaffected. Once you execute the code asynchronously, you get nondeterministic behaviour. That's sure fun for filling up your random pool, but I wouldn't trust my data to such a system. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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] Reliable video POSTing on resume
Xavier Bestel schrieb: Le vendredi 04 fvrier 2005 00:03 -0500, Jon Smirl a crit : Doing this in user space lets you have two reset programs, vm86 and emu86 for non-x86 machines. Perhaps only emu86 should be used, to have a well-debugged codepath on all archs (amd64, ppc, ...) As it's usermode, the code size is less of a problem. Well, if it has to live in initramfs, it better be really small. An initramfs with a size of 8 megabytes isn't going to make you many friends. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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] Reliable video POSTing on resume
Oliver Neukum schrieb: Am Freitag, 4. Februar 2005 08:48 schrieb Pavel Machek: What about simply blocking all video accesses before disk (etc) is resumed, so that normal (not locked in memory) application can be used? Very bad for debugging. Genuine serial ports are becoming rarer. As a bonus, even genuine serial ports may be in undefined state after resume. I'm unfortunate enough to have a brand new notebook with serial port, but the serial console code will print garbage after resume until I do a echo foo /dev/ttyS0 I've already sent mail to linux-serial for that problem, but the list appears to be dead. Any pointers to the right contact would be appreciated. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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] Reliable video POSTing on resume
Jon Smirl schrieb: Reseting a video card from suspend is essentially the same problem as reseting secondary video cards on boot. The same code can address both problems. Some things to consider 1) With multiple video cards you have to ensure only a single VGA gets enabled. Running video reset on a card is going to turn on it's VGA emulation. So you have to ensure that VGA emulation on other cards is disabled first. No problem. Let the kernel tell the userspace application which card to reset. 2) I add the 'rom' parameter in sysfs so that you can get to the rom contents from a user space app. It's there to support running video reset code. echo 1 rom to see the contents, it is not enabled by default. That could be very helpful for secondary cards. 3) The user space reset programs have to be serialized because of the rule about only a single VGA at a time. Calling vm86 from kernel mode is not a good idea. Doing this in user space lets you have two reset programs, vm86 and emu86 for non-x86 machines. With the approach I detailed in the thread starter, this is easily possible. vesaposter can call the kernel function used to synchronize in an endless loop and this kernel function would not only be used to synchronize, but its return value would tell vesaposter what to do to which card. An alternative would be to restart vesaposter as soon as it has finished its job, which would make the POSTing reliable even if the BIOS code hangs or causes crashes. The kernel can simply store a list of video devices and their respective treatments and the kernel function called by vesaposter would just iterate through the list. Hmmm... why not call it int video_helper(struct video_actions *what_to_do) and it blocks until we have something to POST. It could contain all the locking needed to serialize access to the video cards. OTOH, if starting applications from initramfs at resume time is easy, we could make video_helper non-blocking and start vesaposter on demand. And the problem of locking all application memory: The current tool for POSTing and restoring video state (vbetool) uses only 27k on disk. If we put it in initramfs, we could maybe avoid mlock completely (if we can guarantee initramfs contents aren't swapped out). And it would be available early enough for initializing video hardware on boot. A starting place for a user space reset program: ftp://ftp.scitechsoft.com/devel/obsolete/x86emu/x86emu-0.8.tar.gz This thread talks about the VGA routing code: http://lkml.org/lkml/2005/1/17/347 Thanks for the pointers! I'll have to compare it to our current userspace reset and vesa register restoring program http://www.srcf.ucam.org/~mjg59/vbetool/ Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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/
[RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi!
Nigel Cunningham wrote:
> Hi.
>
> On Fri, 2005-02-04 at 09:54, Pavel Machek wrote:
>
>>Hi!
>>
>>
>Are you able to use framebuffer(radeonfb,1024x768) with this
>configuration or do you need to use plain vga-console for it to work?
No.
For a working framebuffer console you would have to perform the steps
my script does *before* the kernel tries to access the framebuffer
console after resume. Since this is not yet possible, you're out of
luck. If
- the vbestate utility was a kernel module or
>>>
>>>OK, I managed to track this down further.
>>>"vbetool post" should be equivalent to "acpi_sleep=s3_bios", but there
>>>are some differences. For me, that's easy to explain: "vbetool post"
>>>segfaults because it wants to access parts of the video bios which
>>>are no longer available. "acpi_sleep=s3_bios" suffers from the same
>>>problem, but it runs in real mode and can't recover :-(
>>>
>>>To alleviate that problem, the kernel could run the video bios in
>>>vm86 mode (like vbetool does by using lrmi). This would simplify
>>>the asm wakeup code and make video POST more reliable.
>>>
>>>Pavel, what do you think?
>>
>>Well, calling BIOS using vm86 is going to be quite a lot of code. If
>>it is self-contained and not too huge, it is probably okay. It should
>>help with quite a lot of cards, but who knows...
>>
>>Yes, it is probably worth trying.
>
> I'd love to see it too. Pavel, even if you don't want to merge it for a
> while, we can always incorporate it in the Suspend2 patches so it gets
> some testing. I know I'd try it on my i830 based Omnibook.
Can we use call_usermodehelper at this early resume stage (before any
video access)? Calling vm86 directly is probably not going to fly
because we want to be shielded from any misbehaviour in the bios code
and it may be necessary to kill the process running the bios code.
Cases in point: My bios will cause the POSTing application to segfault.
Others have reported the POSTing application just hangs, but the
important things are done before the hang, so killing it after maybe
5 seconds would be ok.
Rough outline how to do that without adding tons of code:
We need a call_usermodehelper_from_ram_with_timeout for that.
Kernel: Userspace:
User wants to enter S3
init_mutex_locked(s3_sem)
call_usermodehelper("vesaposter")
vesaposter calls LRMI_init
vesaposter mlocks all its memory
vesaposter calls into kernel
and down(s3_sem)
suspend vesafb
User has triggered resume
run wakeup.S
thaw essential threads
set a timer of 5 seconds
up(s3_sem)
thaw and schedule vesaposter
wait for timer or vesaposter termination
vesaposter returns from kernel
vesaposter posts video card
vesaposter terminates
resume vesafb
continue resume
Problems with that approach:
- vesaposter has to be locked in memory to avoid disk accesses
- vesafb has to refrain from touching video until after POST
- the vesaposter thread has to be the first unfrozen and
scheduled and completed thread. Only after that we can resume
vesafb and other threads
- the locking will be tricky
Advantages:
- the problems all seem to be solvable easily
- security and stability are similar to the current userspace code
- we can use vesafb on such machines
- the kernel code won't be much more than two dozen lines
- the userspace POSTing code can be upgraded without the need
for kernel updates (no policy in the kernel)
What do you think?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
-
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/
[RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! Nigel Cunningham wrote: Hi. On Fri, 2005-02-04 at 09:54, Pavel Machek wrote: Hi! Are you able to use framebuffer(radeonfb,1024x768) with this configuration or do you need to use plain vga-console for it to work? No. For a working framebuffer console you would have to perform the steps my script does *before* the kernel tries to access the framebuffer console after resume. Since this is not yet possible, you're out of luck. If - the vbestate utility was a kernel module or OK, I managed to track this down further. vbetool post should be equivalent to acpi_sleep=s3_bios, but there are some differences. For me, that's easy to explain: vbetool post segfaults because it wants to access parts of the video bios which are no longer available. acpi_sleep=s3_bios suffers from the same problem, but it runs in real mode and can't recover :-( To alleviate that problem, the kernel could run the video bios in vm86 mode (like vbetool does by using lrmi). This would simplify the asm wakeup code and make video POST more reliable. Pavel, what do you think? Well, calling BIOS using vm86 is going to be quite a lot of code. If it is self-contained and not too huge, it is probably okay. It should help with quite a lot of cards, but who knows... Yes, it is probably worth trying. I'd love to see it too. Pavel, even if you don't want to merge it for a while, we can always incorporate it in the Suspend2 patches so it gets some testing. I know I'd try it on my i830 based Omnibook. Can we use call_usermodehelper at this early resume stage (before any video access)? Calling vm86 directly is probably not going to fly because we want to be shielded from any misbehaviour in the bios code and it may be necessary to kill the process running the bios code. Cases in point: My bios will cause the POSTing application to segfault. Others have reported the POSTing application just hangs, but the important things are done before the hang, so killing it after maybe 5 seconds would be ok. Rough outline how to do that without adding tons of code: We need a call_usermodehelper_from_ram_with_timeout for that. Kernel: Userspace: User wants to enter S3 init_mutex_locked(s3_sem) call_usermodehelper(vesaposter) vesaposter calls LRMI_init vesaposter mlocks all its memory vesaposter calls into kernel and down(s3_sem) suspend vesafb User has triggered resume run wakeup.S thaw essential threads set a timer of 5 seconds up(s3_sem) thaw and schedule vesaposter wait for timer or vesaposter termination vesaposter returns from kernel vesaposter posts video card vesaposter terminates resume vesafb continue resume Problems with that approach: - vesaposter has to be locked in memory to avoid disk accesses - vesafb has to refrain from touching video until after POST - the vesaposter thread has to be the first unfrozen and scheduled and completed thread. Only after that we can resume vesafb and other threads - the locking will be tricky Advantages: - the problems all seem to be solvable easily - security and stability are similar to the current userspace code - we can use vesafb on such machines - the kernel code won't be much more than two dozen lines - the userspace POSTing code can be upgraded without the need for kernel updates (no policy in the kernel) What do you think? Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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/
