Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Yu, Luming]

[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]

ACPI Test Report  for 2.4 ia64 kernel + latest ACPI
=========================
Hardware Configuration:
-----------------------
System Name: ACPI-LION
System Type: 4 way 800M Itanium, Lion
M/B revision: N/A
Processor version: N/A
Firmware Versions: N/A
I/O configuration summary:
	QLogic QLA12160, Seagate ST39205LC boot drive
	IDE floppy and CDROM
	Serial console
	PS/2 keyboard and mouse
	USB mouse
	Ethernet Pro 100

Software Configuration:
-----------------------
	1.Bk pull form http://lia64.bkbits.net/linux-ia64-2.4 on 11/11 (Shanghai time)
	2.Bk pull from http://linux-acpi.bkbits.net/linux-acpi-test-2.4.22 on 11/11 (Shanhai time)

	Successfully automerged by bk without out any manually work.

ACPI Features Tested: (prioritized).
--------------------
1. Boot off SCSI disk	tested ok
2. serial console		tested ok
3. PS/2 keyboard		tested ok
4. ATI (run X window system)	tested ok
5. PS/2 mouse			tested ok
6. USB mouse			Doesn't work
7. NIC (eg. Ping or ftp)		tested ok
8. IDE (eg. r/w floppy or CDROM)	tested ok
9. SCI (eg. Press power button)	tested ok

CPU0       CPU1       CPU2       CPU3
 32:        955          3         18          4   IO-SAPIC-edge  keyboard
 33:        758          1         12          2   IO-SAPIC-edge  ide1
 34:         35          3          0          0   IO-SAPIC-edge  ide0
 36:       1155          1         62          5   IO-SAPIC-edge  PS/2 Mouse
 39:          5          0          0          0  IO-SAPIC-level  acpi
 44:          8          0          0          0   IO-SAPIC-edge  serial
 45:         17          0          0          0   IO-SAPIC-edge  serial
 48:         50          0          0          0  IO-SAPIC-level  usb-uhci
 49:        416          2         16          3  IO-SAPIC-level  eth0
 51:       6711         50        317         33  IO-SAPIC-level  qla1280
239:     415744     405691     414447     414241          LSAPIC  timer
254:      16595      17569      17140      16850          LSAPIC  IPI
NMI:          0          0          0          0
ERR:          0

Problems:

1. Unalignment issue.( It appeared when testing power button)
kernel unaligned access to 0xe000000004c2f199, ip=0xe000000004615fb1

2. USB doesn't work

3.PCI: no interrupt route for 00:00:03 pin B

4.alloc 0x0-0xcf7 from PCI IO for PCI Bus 00:00 failed   (Bjron said it is harmless)

5.> 1. After login, the dmesg return below message. 	(Bjorn said these are unimplemented system call, Need a patch to turn off them)
> ...
> ifup-post(864): <sc1236(0,1008,0,20000000000d5b20)>

 <<dmesg.24.ZIP>>  <<lspci.24.TXT>>  <<conf.TXT>> 

Thanks,
Luming


[-- Attachment #2: dmesg.24.ZIP --]
[-- Type: application/x-zip-compressed, Size: 5048 bytes --]

[-- Attachment #3: lspci.24.TXT --]
[-- Type: text/plain, Size: 965 bytes --]

PK\x03\x04\x14\0\0\0\b\0ç™l/ŸépLI\x03\0\0H\x10\0\0\r\0\0\0lspci_241.TXTÝ•[Oâ@\x14ÇßMü\x0eç\x11\x12Ñé•J²\x0fˆ·fíŠV6$†‡i;…fÛi3-ºúé÷´ÜŠH¹¸»‰ö\x01H™9çüÏÿ7s\bi\x11嘀i·Á\x117d-0yÆBèÄ"9\x06CVšòå\x19tM³¯\x15«j‚=\x01‘ê‡\a0}.C:L[àŒSˆhš1q\x04\x11ó‚q\x04\x1e{JYx\x04!Í\x18w_€\x1c\x1e\x1c\x1e"¥\x04æù\x05\x04˜JøԭΊ\vgY¡–ˆxØ\b|0\b<ZEºA©\x16{ì¤/ø2Z
Ø‚\x1eÿÅãgžW\x14¸\fTIu÷\x11 «‹]æÉ-$±ÈR \x19H„`=iðʾIú`!S†ž}†EðLÄaÈD•Î|åªÎ<nïºcþW•G`Þ߁j¬Q«ûÆL­"—Ô*`[gã´Jd±à\x1dˆ>"iIÆš’Ý /H©\x132o°ê•Š§ kv–k×\r…h
tÑ\vA£(ß[ü/Ä8Éà|RÓªg2¦2okýz£!\a\x1f;+\x1a\x16v‘˜à\fe¬%IÓš'ÆÉ)<Î×bÕ9—ƒiÆÆn\x17QNá\x12\v[d¼iÿ€˜ƒ\x15ç/œ˜
o\x1f5s¤N\x17»-\x16Åâ%7‡L\x1fŸú,ÿ†š"7œ ;\x02\x1eóF"˜Ï2w”w¿>5Ný>XËæü$êê :[‘l‹l’U
Ô¡	u‚0È\x02†Ú\x1f=w\0Ýø™	°(§C\x161žÁ\x13\x13i€]“g&êhâÏ«6ú\x17%4\vrŽÊV¶\x1fLx`îˆÇa<ĸèŠ\v÷\x18\rú7\x13ûäæ›;\x01£ý‹+\x01?“$àÍNj¤²·\x0eÙ¶·ºµÖJcn¥¬é^[¼ôýíò-‘sñ;¡¼pêþÖz\x13Ï-â­^\x19²ñ}=\rÚ64H\x04i¸Žñ”½7rU\õ¡\x01†:ùe\x17¶BÛó\x04KÓÒ,šÝîÔ§§[ÙÈ®W0ñó{avÉ¢\x10©Ed\x14bwl\x13±‰EŽk\x19ê»^[dٝ&7í®$K:ó1Å‚F”s,¬\x17f‚*“\x10x]¹XG,¦Šô÷\x15•£®àŽ5+ñÖukôº™mi\r‘Æ\x0eDJ\x7f™Hi?"Uµ‚Hif¤ŸO¿Ž‰Tf$\x1c\x0f+\x06ªë\bOþ\x0egbƼbO7ßS&ȼîÎÙÜcÎ\x13IvªçüÔ)yƒ\a[Γ‰›Ø\võ«ö‚5·åqÞ\vã\x13÷B©ê…çíÜ\v÷ËöBÛ¹\x17þ'î…ZÕ\vwg.$ùËöb'.þ\0PK\x01\x02\x14\v\x14\0\0\0\b\0ç™l/ŸépLI\x03\0\0H\x10\0\0\r\0\0\0\0\0\0\0\x01\0 \0\0\0\0\0\0\0lspci_241.TXTPK\x05\x06\0\0\0\0\x01\0\x01\0;\0\0\0t\x03\0\0\0\0

[-- Attachment #4: conf.TXT --]
[-- Type: text/plain, Size: 0 bytes --]

Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Yu, Luming]

[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]

ACPI Test Report  for 2.4 ia64 kernel + latest ACPI
=========================
Hardware Configuration:
-----------------------
System Name: ACPI-LION
System Type: 4 way 800M Itanium, Lion
M/B revision: N/A
Processor version: N/A
Firmware Versions: N/A
I/O configuration summary:
	QLogic QLA12160, Seagate ST39205LC boot drive
	IDE floppy and CDROM
	Serial console
	PS/2 keyboard and mouse
	USB mouse
	Ethernet Pro 100

Software Configuration:
-----------------------
	1.Bk pull form http://lia64.bkbits.net/linux-ia64-2.4 on 11/19 (Shanghai time)
	2.Bk pull from http://linux-acpi.bkbits.net/linux-acpi-test-2.4.22 on 11/19 (Shanhai time)
	Successfully automerged by bk without out any manually work.

	3. patch from http://bugzilla.kernel.org/show_bug.cgi?id=1533  to solve  kernel unaligned access when pressing power button

ACPI Features Tested: (prioritized).
--------------------
1. Boot off SCSI disk			tested ok
2. serial console			tested ok
3. PS/2 keyboard			tested ok
4. ATI (run X window system)		tested ok
5. PS/2 mouse				tested ok
6. USB mouse				Doesn't work
7. NIC (eg. Ping or ftp)		tested ok
8. IDE (eg. r/w floppy or CDROM)	tested ok
9. SCI (eg. Press power button)		tested ok
10. Soft Power off				tested ok

           CPU0       CPU1       CPU2       CPU3
 32:        617          6          1          0   IO-SAPIC-edge  keyboard
 33:        317          3          0          1   IO-SAPIC-edge  ide1
 34:         36          0          0          2   IO-SAPIC-edge  ide0
 36:        460          4          0          0   IO-SAPIC-edge  PS/2 Mouse
 39:          4          0          0          0  IO-SAPIC-level  acpi
 44:          9          0          0          0   IO-SAPIC-edge  serial
 45:         16          1          0          0   IO-SAPIC-edge  serial
 48:         51          1          0          0  IO-SAPIC-level  usb-uhci
 49:        270          7          4          0  IO-SAPIC-level  eth0
 51:       5620        314         33          4  IO-SAPIC-level  qla1280
239:     231404     230443     230141     220616          LSAPIC  timer
254:      15752      15328      15507      15285          LSAPIC  IPI
NMI:          0          0          0          0
ERR:          0

Problems:

1. USB mouse doesn't work. ( I need to verify config file)

2.PCI: no interrupt route for 00:00:03 pin B

3.alloc 0x0-0xcf7 from PCI IO for PCI Bus 00:00 failed   (Known issue)

4.> 1. After login, the dmesg return below message. 	(Known issue)
> ...
> ifup-post(864): <sc1236(0,1008,0,20000000000d5b20)>

 <<conf.TXT>>  <<dmesg.24.ZIP>>  <<lspci.24.ZIP>> 
Thanks,
Luming

[-- Attachment #2: conf.TXT --]
[-- Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: dmesg.24.ZIP --]
[-- Type: application/x-zip-compressed, Size: 5108 bytes --]

[-- Attachment #4: lspci.24.ZIP --]
[-- Type: application/x-zip-compressed, Size: 1201 bytes --]

Re: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Bjorn Helgaas]

On Wednesday 19 November 2003 6:08 am, Yu, Luming wrote:

Thanks for doing this work and posting the results.

> 1. USB mouse doesn't work. ( I need to verify config file)

The driver seems to know about the device:

	Product: USB Wheel Mouse
	host/usb-uhci.c: interrupt, status 3, frame# 1415
	input: USB HID v1.00 Mouse [04fc:0003] on usb1:2.0

although it looks unhappy about it.  The "interrupt, status 3" message
seems to be a warning about an interrupt when the driver didn't expect
it.  I wonder whether this can be reproduced on an x86 box?

You could also try the CONFIG_USB_UHCI_ALT driver instead of the
CONFIG_USB_UHCI one you seem to be using, and see whether that
makes a difference.

> 2.PCI: no interrupt route for 00:00:03 pin B

You say this is a known issue for 2.6, but I can't find any details
or discussion about it.  It looks to me like a firmware problem.
The function at 00:00:03.3 (2.6 nicely tells us which function)
claims it's using INTB, but ACPI isn't telling us which GSI that
corresponds to.  Can you ask your BIOS guys about this?

> 3.alloc 0x0-0xcf7 from PCI IO for PCI Bus 00:00 failed   (Known issue)

I poked at this again.  The reason this fails is because the
VGA console driver starts up very early and allocates ports
0x3c0-0x3df.  It would be nice if we could figure out a way
to allocate those ports later, after the PCI bridge has been
discovered, so we get the ioport resources correct, but I
don't know a reasonable way to do that.

> 4.> 1. After login, the dmesg return below message. 	(Known issue)
> > ifup-post(864): <sc1236(0,1008,0,20000000000d5b20)>

I just added a patch to remove these messages, so this should
be fixed.

>  <<conf.TXT>>  <<dmesg.24.ZIP>>  <<lspci.24.ZIP>> 

The conf.TXT attachment was empty.

Bjorn

Re: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Matthew Wilcox]

On Wed, Nov 19, 2003 at 05:33:20PM -0700, Bjorn Helgaas wrote:
> > 3.alloc 0x0-0xcf7 from PCI IO for PCI Bus 00:00 failed   (Known issue)
> 
> I poked at this again.  The reason this fails is because the
> VGA console driver starts up very early and allocates ports
> 0x3c0-0x3df.  It would be nice if we could figure out a way
> to allocate those ports later, after the PCI bridge has been
> discovered, so we get the ioport resources correct, but I
> don't know a reasonable way to do that.

Ah, I introduced a mechanism for doing the opposite of this in 2.6-test8
(it's credited to Ben Herrenschmidt since he did the debugging and got
it merged).  If you call insert_resource() instead of request_resource(),
conflicting resources get the new resource added as their parent.

I knew this was going to be handy for more than just PPC ;-)

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Bjorn Helgaas]

On Wednesday 19 November 2003 8:28 pm, Matthew Wilcox wrote:
> On Wed, Nov 19, 2003 at 05:33:20PM -0700, Bjorn Helgaas wrote:
> > > 3.alloc 0x0-0xcf7 from PCI IO for PCI Bus 00:00 failed   (Known issue)
> > 
> > I poked at this again.  The reason this fails is because the
> > VGA console driver starts up very early and allocates ports
> > 0x3c0-0x3df.  It would be nice if we could figure out a way
> > to allocate those ports later, after the PCI bridge has been
> > discovered, so we get the ioport resources correct, but I
> > don't know a reasonable way to do that.
> 
> Ah, I introduced a mechanism for doing the opposite of this in 2.6-test8
> (it's credited to Ben Herrenschmidt since he did the debugging and got
> it merged).  If you call insert_resource() instead of request_resource(),
> conflicting resources get the new resource added as their parent.
> 
> I knew this was going to be handy for more than just PPC ;-)

Nice!  I'll send a patch to Tony for 2.6.1.

RE: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Luck, Tony]

> Nice!  I'll send a patch to Tony for 2.6.1.

Isn't the plan that David will keep running 2.6
until Linus opens 2.7?  Won't there be a few "dot"
releases in 2.6 before that happens?

-Tony

RE: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Yu, Luming]

>> 1. USB mouse doesn't work. ( I need to verify config file)
>
>The driver seems to know about the device:
>
>	Product: USB Wheel Mouse
>	host/usb-uhci.c: interrupt, status 3, frame# 1415
>	input: USB HID v1.00 Mouse [04fc:0003] on usb1:2.0
>
>although it looks unhappy about it.  The "interrupt, status 3" message
>seems to be a warning about an interrupt when the driver didn't expect
>it.  I wonder whether this can be reproduced on an x86 box?
>
>You could also try the CONFIG_USB_UHCI_ALT driver instead of the
>CONFIG_USB_UHCI one you seem to be using, and see whether that
>makes a difference.

USB mouse still doesn't work on lion, but it works on tiger, and this kind of symptom cannot be reproduced on ia32 box.

>> 2.PCI: no interrupt route for 00:00:03 pin B

>You say this is a known issue for 2.6, but I can't find any details
>or discussion about it.  It looks to me like a firmware problem.
>The function at 00:00:03.3 (2.6 nicely tells us which function)
>claims it's using INTB, but ACPI isn't telling us which GSI that
>corresponds to.  Can you ask your BIOS guys about this?

There is only 1 PRT entry in DSDT for bus 0, slot 3,  but it is for pin D  not for pin B . And the error message reflect that fact. 
This error is for device 00:03.3 --SMBus. I don't know how to test that device.
Actually 2.6 will call acpi_pci_irq_derive try to derive IRQ from parent bridge, if nothing found from PRT List, But 2.4 will not do that.
Actually, acpi_pci_irq_enable will not be called in 2.4. Maybe this is a issue. But it will not help this case.

                Package (0x04)
                {
                    0x0003FFFF, 
                    0x03, 
                    0x00, 
                    0x32
                }, 

>> 3.alloc 0x0-0xcf7 from PCI IO for PCI Bus 00:00 failed   (Known issue)

>I poked at this again.  The reason this fails is because the
>VGA console driver starts up very early and allocates ports
>0x3c0-0x3df.  It would be nice if we could figure out a way
>to allocate those ports later, after the PCI bridge has been
>discovered, so we get the ioport resources correct, but I
>don't know a reasonable way to do that.

Since VGA console driver faile to allocate that port range,  why it still can work?
Does it mean 0x3c0-0x3df is inessential to  VGA console driver.

> 4.> 1. After login, the dmesg return below message. 	(Known issue)
> > ifup-post(864): <sc1236(0,1008,0,20000000000d5b20)>

>I just added a patch to remove these messages, so this should
>be fixed.

It's gone!

Re: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Bjorn Helgaas]

On Wednesday 10 December 2003 3:29 am, Yu, Luming wrote:

> >> 2.PCI: no interrupt route for 00:00:03 pin B
> 
> >You say this is a known issue for 2.6, but I can't find any details
> >or discussion about it.  It looks to me like a firmware problem.
> >The function at 00:00:03.3 (2.6 nicely tells us which function)
> >claims it's using INTB, but ACPI isn't telling us which GSI that
> >corresponds to.  Can you ask your BIOS guys about this?
> 
> There is only 1 PRT entry in DSDT for bus 0, slot 3,  but it is for pin D  not for pin B . And the error message reflect that fact. 
> This error is for device 00:03.3 --SMBus. I don't know how to test that device.
> Actually 2.6 will call acpi_pci_irq_derive try to derive IRQ from parent bridge, if nothing found from PRT List, But 2.4 will not do that.

But your testing report from 2.6 shows the same message.  Did you
get any response from your BIOS guys?

> >> 3.alloc 0x0-0xcf7 from PCI IO for PCI Bus 00:00 failed   (Known issue)
> 
> >I poked at this again.  The reason this fails is because the
> >VGA console driver starts up very early and allocates ports
> >0x3c0-0x3df.  It would be nice if we could figure out a way
> >to allocate those ports later, after the PCI bridge has been
> >discovered, so we get the ioport resources correct, but I
> >don't know a reasonable way to do that.
> 
> Since VGA console driver faile to allocate that port range,  why it still can work?
> Does it mean 0x3c0-0x3df is inessential to  VGA console driver.

No, I think those ports are essential.  The driver just uses them,
even if the allocation fails.  I have a 2.6 patch that cleans this
up.  It doesn't change any functionality; it just gets rid of the
message and makes /proc/ioports more correct.  I'll submit it as
soon as it makes sense to put non-critical changes into 2.6.

Bjorn

Re: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Bjorn Helgaas]

On Wednesday 10 December 2003 5:34 pm, I wrote:
> > >> 3.alloc 0x0-0xcf7 from PCI IO for PCI Bus 00:00 failed   (Known issue)
> > 
> > Since VGA console driver faile to allocate that port range,  why it still can work?
> > Does it mean 0x3c0-0x3df is inessential to  VGA console driver.
> 
> No, I think those ports are essential.  The driver just uses them,
> even if the allocation fails.  I have a 2.6 patch that cleans this
> up.  It doesn't change any functionality; it just gets rid of the
> message and makes /proc/ioports more correct.  I'll submit it as
> soon as it makes sense to put non-critical changes into 2.6.

I didn't answer this quite right.  The VGA driver allocates ports
0x3c0-0x3df early, and that allocation succeeds.  Later, we
discover the PCI root bridges, and try to allocate the port ranges
for each.  It's the PCI root bridge allocation that fails, because
it's trying to allocate a range that includes the VGA ports.

So we end up with something like this in /proc/ioports (this is a
made-up example, but same idea):

	000003c0-000003df : vga+
	00004000-00009fff : PCI Bus 00:00
	  00004000-000040ff : sym53c8xx
	  00004100-000041ff : sym53c8xx

when we should have this:

	00000000-00000cf7 : PCI Bus 00:00
	  000003c0-000003df : vga+
	00004000-00009fff : PCI Bus 00:00
	  00004000-000040ff : sym53c8xx
	  00004100-000041ff : sym53c8xx

The patch just changes the PCI root bridge allocation so that
instead of failing if part of the range has already been allocated,
it inserts a new range up one level, so it encloses the previous
VGA allocation.

Bjorn

RE: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Yu, Luming]

>> > >> 3.alloc 0x0-0xcf7 from PCI IO for PCI Bus 00:00 failed   (Known issue)
>> > 
>> > Since VGA console driver faile to allocate that port range,  why it still can work?
>> > Does it mean 0x3c0-0x3df is inessential to  VGA console driver.
>> 
>> No, I think those ports are essential.  The driver just uses them,
>> even if the allocation fails.  I have a 2.6 patch that cleans this
>> up.  It doesn't change any functionality; it just gets rid of the
>> message and makes /proc/ioports more correct.  I'll submit it as
>> soon as it makes sense to put non-critical changes into 2.6.

>I didn't answer this quite right.  The VGA driver allocates ports
>0x3c0-0x3df early, and that allocation succeeds.  Later, we
>discover the PCI root bridges, and try to allocate the port ranges
>for each.  It's the PCI root bridge allocation that fails, because
>it's trying to allocate a range that includes the VGA ports.

>So we end up with something like this in /proc/ioports (this is a
>made-up example, but same idea):
>
>	000003c0-000003df : vga+
>	00004000-00009fff : PCI Bus 00:00
>	  00004000-000040ff : sym53c8xx
>	  00004100-000041ff : sym53c8xx
>
>when we should have this:
>
>	00000000-00000cf7 : PCI Bus 00:00
>	  000003c0-000003df : vga+
>	00004000-00009fff : PCI Bus 00:00
>	  00004000-000040ff : sym53c8xx
>	  00004100-000041ff : sym53c8xx
>
>The patch just changes the PCI root bridge allocation so that
>instead of failing if part of the range has already been allocated,
>it inserts a new range up one level, so it encloses the previous
>VGA allocation.

Could you let me see what are you patch doing.  

I think  "To bus device, resources returned from _CRS method means that bus device will
supply those resouces to its children devices. So it's unreasonable to call
request_resource for them."

I have a patch for above statement.  Please take http://bugzilla.kernel.org/show_bug.cgi?id\x1685 a look.

Thanks,
Luming

Re: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Matthew Wilcox]

On Tue, Dec 16, 2003 at 05:37:35PM +0800, Yu, Luming wrote:
> >So we end up with something like this in /proc/ioports (this is a
> >made-up example, but same idea):
> >
> >	000003c0-000003df : vga+
> >	00004000-00009fff : PCI Bus 00:00
> >	  00004000-000040ff : sym53c8xx
> >	  00004100-000041ff : sym53c8xx
> >
> >when we should have this:
> >
> >	00000000-00000cf7 : PCI Bus 00:00
> >	  000003c0-000003df : vga+
> >	00004000-00009fff : PCI Bus 00:00
> >	  00004000-000040ff : sym53c8xx
> >	  00004100-000041ff : sym53c8xx
> >
> >The patch just changes the PCI root bridge allocation so that
> >instead of failing if part of the range has already been allocated,
> >it inserts a new range up one level, so it encloses the previous
> >VGA allocation.
> 
> Could you let me see what are you patch doing.  

I haven't seen Bjorn's patch yet, but it'll be something like:

--- arch/ia64/pci/pci.c 12 Aug 2003 19:10:49 -0000      1.3
+++ arch/ia64/pci/pci.c 16 Dec 2003 12:13:53 -0000
@@ -153,7 +153,7 @@ alloc_resource (char *name, struct resou
        res->end = end;
        res->flags = flags;
 
-       if (request_resource(root, res))
+       if (insert_resource(root, res))
                return -EBUSY;
 
        return 0;


> I think  "To bus device, resources returned from _CRS method means that bus device will
> supply those resouces to its children devices. So it's unreasonable to call
> request_resource for them."

That's faulty logic.  Resources can either be busy (used at the leaf
by a driver) or merely containers for other resources (as they are in
this case).

> I have a patch for above statement.  Please take http://bugzilla.kernel.org/show_bug.cgi?id\x1685 a look.

No.  That will lose the information about which areas are under which
busses, which is rather useful information to have.  For example, when
PCI needs to allocate resources, if we don't partition the root resource
amongst the child busses, we could inadvertently allocate resources that
straddle two PCI busses, and that just won't work.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Bjorn Helgaas]

On Tuesday 16 December 2003 5:17 am, Matthew Wilcox wrote:
> On Tue, Dec 16, 2003 at 05:37:35PM +0800, Yu, Luming wrote:
> > Could you let me see what are you patch doing.  
> 
> I haven't seen Bjorn's patch yet, but it'll be something like:
> 
> --- arch/ia64/pci/pci.c 12 Aug 2003 19:10:49 -0000      1.3
> +++ arch/ia64/pci/pci.c 16 Dec 2003 12:13:53 -0000
> @@ -153,7 +153,7 @@ alloc_resource (char *name, struct resou
>         res->end = end;
>         res->flags = flags;
>  
> -       if (request_resource(root, res))
> +       if (insert_resource(root, res))
>                 return -EBUSY;
>  
>         return 0;

Yup, that's exactly the patch.

And I agree with Matthew about preferring this over your patch.
Did you look at /proc/iomem with and without your patch?  The
value of keeping the request_resource() (or insert_resource())
should be obvious.

Bjorn

RE: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Yu, Luming]

>> I think  "To bus device, resources returned from _CRS method means that bus device will
>> supply those resouces to its children devices. So it's unreasonable to call
>> request_resource for them."

>That's faulty logic.  Resources can either be busy (used at the leaf
>by a driver) or merely containers for other resources (as they are in
>this case).

My concern is that if a device driver want to request a resource,
but that resource has been allocated by bus device (which supply this resources to its children devices) 
then  -EBUSY get returned. Maybe device driver can
ignore this error.  But how to detect a real resource conflict  with other device (another resource consumer)?  All of them return -EBUSY.

>> I have a patch for above statement.  Please take http://bugzilla.kernel.org/show_bug.cgi?id\x1685 a look.
>No.  That will lose the information about which areas are under which
>busses, which is rather useful information to have. 

Yes, I agree. 

> For example, when
>PCI needs to allocate resources, if we don't partition the root resource
>amongst the child busses, we could inadvertently allocate resources that
>straddle two PCI busses, and that just won't work.

All resources info returned from _CRS has been saved in pci_root_info->controller->window.  Is it enough?
 
Thanks,
Luming

RE: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Yu, Luming]

>Did you look at /proc/iomem with and without your patch?  The
>value of keeping the request_resource() (or insert_resource())
>should be obvious.

My patch just eliminate resources provider from resource tree.
Maybe it's not good, but it will not confuse device driver.

Re: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Matthew Wilcox]

On Wed, Dec 17, 2003 at 10:54:09AM +0800, Yu, Luming wrote:
> >> I think  "To bus device, resources returned from _CRS method means that bus device will
> >> supply those resouces to its children devices. So it's unreasonable to call
> >> request_resource for them."
> 
> >That's faulty logic.  Resources can either be busy (used at the leaf
> >by a driver) or merely containers for other resources (as they are in
> >this case).
> 
> My concern is that if a device driver want to request a resource,
> but that resource has been allocated by bus device (which supply this resources to its children devices) 
> then  -EBUSY get returned. Maybe device driver can
> ignore this error.  But how to detect a real resource conflict  with other device (another resource consumer)?  All of them return -EBUSY.

No, you don't understand how resources work.  When device drivers request
them, they're marked as busy.  When busses claim them, they're marked
as not-busy.  Take a look at __request_region in kernel/resource.c.
It checks IORESOURCE_BUSY to see whether it can have the new resource
as a child of the existing one.

> > For example, when
> >PCI needs to allocate resources, if we don't partition the root resource
> >amongst the child busses, we could inadvertently allocate resources that
> >straddle two PCI busses, and that just won't work.
> 
> All resources info returned from _CRS has been saved in pci_root_info->controller->window.  Is it enough?

No, the generic PCI code knows nothing about this ACPI-specific
information.  It relies on the resources being set up correctly.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

RE: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Yu, Luming]

>> >> I think  "To bus device, resources returned from _CRS method means that bus device will
>> >> supply those resouces to its children devices. So it's unreasonable to call
>> >> request_resource for them."
>> 
>> >That's faulty logic.  Resources can either be busy (used at the leaf
>> >by a driver) or merely containers for other resources (as they are in
>> >this case).
>> 
>> My concern is that if a device driver want to request a resource,
>> but that resource has been allocated by bus device (which supply this resources to its children devices) 
>> then  -EBUSY get returned. Maybe device driver can
>> ignore this error.  But how to detect a real resource conflict  with other device (another resource consumer)?  All of them return -EBUSY.
>
>No, you don't understand how resources work.  When device drivers request
>them, they're marked as busy.  When busses claim them, they're marked
>as not-busy.  

  I didn't find the busy flag for resources you mentioned is being used in request_resource function.

  Actually, based on whether there is a resource conflict happened, request_resource determine whether return -EBUSY . (2.6/kernel/resources.c)

  Does device drivers use different function to request resources with bus device? If they are using same function without any additional information 
, how could request_resource understand this is busses claiming resources, that is device requesting resources?

  According to comments of code, insert_resource is equivalent of request_resource when no conflict happens. If a conflict happens, and the
conflicting resources entirely fit within the range of the new resource, then the new resource is inserted and the conflicting resources become
childs of the new resource. 

  Obviously, if device drivers want to consume some resources, then they cannot use insert_resource, because insert_resource will not report conflict.

  If they use request_resource, and that resources has been claimed by bus devices,  then conflict will get returned. 
 
  To anyone using request_resource to consume some resources, how to handle conflict situation? If this conflict is between resources supplier (BUS device)
and resources consumer (Device ) , then device driver should ignore this conflict, because it's not a true conflict.

  If this conflict is betwwen resources consumer (Device) and resources consumer (another device), then the device driver should think of it as a serious bug.

 But when conflict happend, the device driver have no idea to tell with who it is conflicted.  (Resource consumer, or Resource supplier)

Do you have any idea?

Re: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report

[Matthew Wilcox]

On Thu, Dec 18, 2003 at 10:42:04AM +0800, Yu, Luming wrote:
> >No, you don't understand how resources work.  When device drivers request
> >them, they're marked as busy.  When busses claim them, they're marked
> >as not-busy.  
> 
>   I didn't find the busy flag for resources you mentioned is being used
> in request_resource function.

That's right, it's used in request_region().

>   Actually, based on whether there is a resource conflict happened,
> request_resource determine whether return -EBUSY . (2.6/kernel/resources.c)

request_resource() is used when you know what the parent resource is.
It's assumed to be not-busy; all it's checking for are existing children
of the parent resource which would conflict.

>   According to comments of code, insert_resource is equivalent of request_resource when no conflict happens. If a conflict happens, and the
> conflicting resources entirely fit within the range of the new resource, then the new resource is inserted and the conflicting resources become
> childs of the new resource. 

Yes, I wrote that comment ;-)

>   Obviously, if device drivers want to consume some resources, then they cannot use insert_resource, because insert_resource will not report conflict.

Right, device drivers wouldn't use either request_resource or insert_resource.
They're used by the bus drivers which know a lot more about the system
topology than device drivers (which in general do not care).

>   To anyone using request_resource to consume some resources, how to handle
> conflict situation? If this conflict is between resources supplier (BUS
> device) and resources consumer (Device ) , then device driver should ignore
> this conflict, because it's not a true conflict.

Drivers never see a conflict because they use request_region() which handles
the resource hierarchy for them.

Look at the patch I sent earlier in the thread.  We change the bus driver
to call insert_resource; we don't change the vga driver at all.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain