FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 12-16-2011, 09:27 AM
Jonathan Nieder
 
Default Bug#644174: ACPI I/O resource conflicts with ACPI region SMBI

Mathieu Malaterre wrote:

> So short story: just unplugged any USB device and it should boot nicely.
>
> Let me know if I should just close this bug.

Thanks for the follow up.

No, we shouldn't close this --- it seems it's just another sign that
xhci support is a little broken in squeeze. Nice to see that's the
*only* problem here.

What is the latest squeeze kernel you've tried and reproduced this
with? ("cat /proc/version" will say the current version in
parentheses.)

To move forward:

- Please attach "acpidump" output. (I doubt it's relevant, but it's
useful to have for reference.)

- Please test a v3.2 release candidate from experimental. The only
packages from outside squeeze that should be needed for this, aside
from the kernel image itself, are linux-base and initramfs-tools.

- If it reproduces the problem, please blacklist the xhci_hcd
module by writing

blacklist xhci_hcd

to a file /etc/modprobe.d/mm-blacklist-xhci.conf, run

update-initramfs -u -k all

and reboot to try again without USB 3.0 support. If we're very
lucky, this will work around the problem. In that case, please
write a summary of the problem to upstream
(linux-usb@vger.kernel.org, cc-ing Sarah Sharp
<sarah.a.sharp@linux.intel.com> and either me or this bug log so we
can track the resulting discussion). Be sure to include:

- steps to reproduce the problem
- symptoms, and how they differ from what you expected
- ways to avoid triggering the problem (maybe some USB ports
trigger it and others don't? etc)
- full "dmesg" output from booting, and a photo of the screen
after reproducing the problem (ideally by running "modprobe
xhci_hcd" in the very same run of Linux), as attachments
- which kernel versions you've tested, and what happened with each
- a link to this bug log for the full story
- any other weird symptoms or observations

Thanks for your patience and hope that helps,
Jonathan



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111216102758.GD5974@elie.hsd1.il.comcast.net">ht tp://lists.debian.org/20111216102758.GD5974@elie.hsd1.il.comcast.net
 
Old 12-22-2011, 02:18 PM
Mathieu Malaterre
 
Default Bug#644174: ACPI I/O resource conflicts with ACPI region SMBI

On Fri, Dec 16, 2011 at 11:27 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> *- Please test a v3.2 release candidate from experimental. *The only
> * packages from outside squeeze that should be needed for this, aside
> * from the kernel image itself, are linux-base and initramfs-tools.
>
> *- If it reproduces the problem, please blacklist the xhci_hcd
> * module by writing
>
> * * * *blacklist xhci_hcd
>
> * to a file /etc/modprobe.d/mm-blacklist-xhci.conf, run
>
> * * * *update-initramfs -u -k all
>
> * and reboot to try again without USB 3.0 support. *If we're very
> * lucky, this will work around the problem. *In that case, please
> * write a summary of the problem to upstream
> * (linux-usb@vger.kernel.org, cc-ing Sarah Sharp
> * <sarah.a.sharp@linux.intel.com> and either me or this bug log so we
> * can track the resulting discussion). *Be sure to include:
>
> * *- steps to reproduce the problem
> * *- symptoms, and how they differ from what you expected
> * *- ways to avoid triggering the problem (maybe some USB ports
> * * *trigger it and others don't? etc)
> * *- full "dmesg" output from booting, and a photo of the screen
> * * *after reproducing the problem (ideally by running "modprobe
> * * *xhci_hcd" in the very same run of Linux), as attachments
> * *- which kernel versions you've tested, and what happened with each
> * *- a link to this bug log for the full story
> * *- any other weird symptoms or observations

System: Dell System Vostro 3750 / Portable Computer

Ok. So I am running: 3.2.0-rc4-amd64 from debian experimental.

No mouse plugged to USB 2.0/3.0 interface: boot is fine
Mouse plugged to USB 2.0 interface: boot is fine
Mouse plugged to USB 3.0 interface: boot simply stops

As suggested by Jonathan N. [1] here is what I did next:

$ cat /etc/modprobe.d/mm-blacklist-xhci.conf
blacklist xhci_hcd
$ update-initramfs -u -k all
$ sudo reboot

3.2.0-rc4-amd64 refuse to boot as soon as I plug my mouse to USB 3.0
port (screenshot at [2]). USB 2.0 and no mouse still boot fine.

I am attaching dmesg from a kernel boot, when mouse is attached to USB
2.0 port (see [3]).

I think I'll revert to 2.6.39-bpo.2-amd64 because kernel does not
seems to like my video card. When I suspend/resume, screen is
displayed on screen Ctrl+Shift+F8, while pointer stays on
Ctrl+Shift+F7. I can type fine from Ctrl+Shift+F7, since I can see
results on Ctrl+Shift+F8. I'll try to compile the nvidia kernel and
see if suspend/resume works.


Refs:
[1] http://bugs.debian.org/644174
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644174#64
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644174#69

Thanks,
--
Mathieu



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CA+7wUsxRg52yC+wu7uO-YChPEbQ3vaYWG6F7ee=iPx8YX7omWQ@mail.gmail.com">htt p://lists.debian.org/CA+7wUsxRg52yC+wu7uO-YChPEbQ3vaYWG6F7ee=iPx8YX7omWQ@mail.gmail.com
 
Old 12-22-2011, 06:47 PM
Jonathan Nieder
 
Default Bug#644174: ACPI I/O resource conflicts with ACPI region SMBI

Hi,

Mathieu Malaterre wrote:

> Ok. So I am running: 3.2.0-rc4-amd64 from debian experimental.
>
> No mouse plugged to USB 2.0/3.0 interface: boot is fine
> Mouse plugged to USB 2.0 interface: boot is fine
> Mouse plugged to USB 3.0 interface: boot simply stops
>
> As suggested by Jonathan N. [1] here is what I did next:
>
> $ cat /etc/modprobe.d/mm-blacklist-xhci.conf
> blacklist xhci_hcd
> $ update-initramfs -u -k all
> $ sudo reboot
>
> 3.2.0-rc4-amd64 refuse to boot as soon as I plug my mouse to USB 3.0
> port (screenshot at [2]). USB 2.0 and no mouse still boot fine.

So do I understand correctly, that blacklisting the xhci driver does
_not_ avoid trouble? Can you confirm that the blacklisting worked,
by booting and checking that the xhci_hcd module is not loaded?

If so, this presumably has nothing to do with the xhci driver, and is
probably caused by something lower level.

Happy holidays,
Jonathan



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111222194705.GC8650@elie.Belkin">http://lists.debian.org/20111222194705.GC8650@elie.Belkin
 
Old 12-22-2011, 06:52 PM
Sarah Sharp
 
Default Bug#644174: ACPI I/O resource conflicts with ACPI region SMBI

On Thu, Dec 22, 2011 at 04:18:56PM +0100, Mathieu Malaterre wrote:
> On Fri, Dec 16, 2011 at 11:27 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > *- Please test a v3.2 release candidate from experimental. *The only
> > * packages from outside squeeze that should be needed for this, aside
> > * from the kernel image itself, are linux-base and initramfs-tools.
> >
> > *- If it reproduces the problem, please blacklist the xhci_hcd
> > * module by writing
> >
> > * * * *blacklist xhci_hcd
> >
> > * to a file /etc/modprobe.d/mm-blacklist-xhci.conf, run
> >
> > * * * *update-initramfs -u -k all
> >
> > * and reboot to try again without USB 3.0 support. *If we're very
> > * lucky, this will work around the problem. *In that case, please
> > * write a summary of the problem to upstream
> > * (linux-usb@vger.kernel.org, cc-ing Sarah Sharp
> > * <sarah.a.sharp@linux.intel.com> and either me or this bug log so we
> > * can track the resulting discussion). *Be sure to include:
> >
> > * *- steps to reproduce the problem
> > * *- symptoms, and how they differ from what you expected
> > * *- ways to avoid triggering the problem (maybe some USB ports
> > * * *trigger it and others don't? etc)
> > * *- full "dmesg" output from booting, and a photo of the screen
> > * * *after reproducing the problem (ideally by running "modprobe
> > * * *xhci_hcd" in the very same run of Linux), as attachments
> > * *- which kernel versions you've tested, and what happened with each
> > * *- a link to this bug log for the full story
> > * *- any other weird symptoms or observations
>
> System: Dell System Vostro 3750 / Portable Computer
>
> Ok. So I am running: 3.2.0-rc4-amd64 from debian experimental.
>
> No mouse plugged to USB 2.0/3.0 interface: boot is fine
> Mouse plugged to USB 2.0 interface: boot is fine
> Mouse plugged to USB 3.0 interface: boot simply stops

Does the boot stop when you have a non-HID USB device plugged into the
USB 3.0 port (e.g. hub or flash drive or USB speaker)? It could be an
issue with a buggy BIOS trying to use the mouse and keyboard (HID
devices) attached to the USB 3.0 host. Perhaps it changes the ACPI
tables when it tries to use the USB 3.0 host controller, and
accidentally overlaps the regions? But if your keyboard and mouse were
under USB 2.0, maybe it will only map in the USB 2.0 host controller.

> As suggested by Jonathan N. [1] here is what I did next:
>
> $ cat /etc/modprobe.d/mm-blacklist-xhci.conf
> blacklist xhci_hcd
> $ update-initramfs -u -k all
> $ sudo reboot

Were you blacklisting xhci only because of the "xhci_hcd 0000:03:00.0:
WARN: Stalled endpoint" messages? Because those messages are harmless,
and don't mean anything is *wrong* with the host controller.

Even if there's no xHCI driver loaded, it seems that ACPI is noticing
the conflict between the PCI registers and another region. So unloading
the xHCI driver won't help your system boot. You'd need to get a fix
into the ACPI subsystem to work around the conflict. I don't think any
xHCI driver modification can help here.

> 3.2.0-rc4-amd64 refuse to boot as soon as I plug my mouse to USB 3.0
> port (screenshot at [2]). USB 2.0 and no mouse still boot fine.
>
> I am attaching dmesg from a kernel boot, when mouse is attached to USB
> 2.0 port (see [3]).
>
> I think I'll revert to 2.6.39-bpo.2-amd64 because kernel does not
> seems to like my video card. When I suspend/resume, screen is
> displayed on screen Ctrl+Shift+F8, while pointer stays on
> Ctrl+Shift+F7. I can type fine from Ctrl+Shift+F7, since I can see
> results on Ctrl+Shift+F8. I'll try to compile the nvidia kernel and
> see if suspend/resume works.
>
>
> Refs:
> [1] http://bugs.debian.org/644174
> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644174#64
> [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644174#69

Sarah Sharp



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111222195243.GB18208@xanatos">http://lists.debian.org/20111222195243.GB18208@xanatos
 
Old 12-28-2011, 04:11 PM
Mathieu Malaterre
 
Default Bug#644174: ACPI I/O resource conflicts with ACPI region SMBI

On Thu, Dec 22, 2011 at 8:52 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
> On Thu, Dec 22, 2011 at 04:18:56PM +0100, Mathieu Malaterre wrote:
>> On Fri, Dec 16, 2011 at 11:27 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> > *- Please test a v3.2 release candidate from experimental. *The only
>> > * packages from outside squeeze that should be needed for this, aside
>> > * from the kernel image itself, are linux-base and initramfs-tools.
>> >
>> > *- If it reproduces the problem, please blacklist the xhci_hcd
>> > * module by writing
>> >
>> > * * * *blacklist xhci_hcd
>> >
>> > * to a file /etc/modprobe.d/mm-blacklist-xhci.conf, run
>> >
>> > * * * *update-initramfs -u -k all
>> >
>> > * and reboot to try again without USB 3.0 support. *If we're very
>> > * lucky, this will work around the problem. *In that case, please
>> > * write a summary of the problem to upstream
>> > * (linux-usb@vger.kernel.org, cc-ing Sarah Sharp
>> > * <sarah.a.sharp@linux.intel.com> and either me or this bug log so we
>> > * can track the resulting discussion). *Be sure to include:
>> >
>> > * *- steps to reproduce the problem
>> > * *- symptoms, and how they differ from what you expected
>> > * *- ways to avoid triggering the problem (maybe some USB ports
>> > * * *trigger it and others don't? etc)
>> > * *- full "dmesg" output from booting, and a photo of the screen
>> > * * *after reproducing the problem (ideally by running "modprobe
>> > * * *xhci_hcd" in the very same run of Linux), as attachments
>> > * *- which kernel versions you've tested, and what happened with each
>> > * *- a link to this bug log for the full story
>> > * *- any other weird symptoms or observations
>>
>> System: Dell System Vostro 3750 / Portable Computer
>>
>> Ok. So I am running: 3.2.0-rc4-amd64 from debian experimental.
>>
>> No mouse plugged to USB 2.0/3.0 interface: boot is fine
>> Mouse plugged to USB 2.0 interface: boot is fine
>> Mouse plugged to USB 3.0 interface: boot simply stops
>
> Does the boot stop when you have a non-HID USB device plugged into the
> USB 3.0 port (e.g. hub or flash drive or USB speaker)? *It could be an
> issue with a buggy BIOS trying to use the mouse and keyboard (HID
> devices) attached to the USB 3.0 host. *Perhaps it changes the ACPI
> tables when it tries to use the USB 3.0 host controller, and
> accidentally overlaps the regions? *But if your keyboard and mouse were
> under USB 2.0, maybe it will only map in the USB 2.0 host controller.

I tried booting kernel 3.0.2 (debian/unstable 3.2.0-rc4-amd64) with a
USB key plugged into USB 3.0 and was stuck again. So I can confirm
that with a normal USB key (non-HID) plugged in USB 3.0 port, makes
the kernel refuse to boot.

After a normal boot, key appears as :
[ 158.736727] usb 3-2: new high-speed USB device number 2 using xhci_hcd
[ 158.755680] xhci_hcd 0000:03:00.0: WARN: short transfer on control ep
[ 158.756522] xhci_hcd 0000:03:00.0: WARN: short transfer on control ep
[ 158.757426] xhci_hcd 0000:03:00.0: WARN: short transfer on control ep
[ 158.758299] xhci_hcd 0000:03:00.0: WARN: short transfer on control ep
[ 158.758698] usb 3-2: New USB device found, idVendor=0951, idProduct=160f
[ 158.758708] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 158.758714] usb 3-2: Product: DT Mini Slim
[ 158.758719] usb 3-2: Manufacturer: Kingston
[ 158.758723] usb 3-2: SerialNumber: 0019E06B07B5F9A1879A0D15
[ 158.760294] scsi7 : usb-storage 3-2:1.0
[ 159.760670] scsi 7:0:0:0: Direct-Access Kingston DT Mini Slim
1.00 PQ: 0 ANSI: 2
[ 159.763089] sd 7:0:0:0: Attached scsi generic sg2 type 0
[ 159.763655] sd 7:0:0:0: [sdb] 15654848 512-byte logical blocks:
(8.01 GB/7.46 GiB)
[ 159.763834] sd 7:0:0:0: [sdb] Write Protect is off
[ 159.763841] sd 7:0:0:0: [sdb] Mode Sense: 16 0f 09 51
[ 159.764012] sd 7:0:0:0: [sdb] Incomplete mode parameter data
[ 159.764019] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[ 159.765193] sd 7:0:0:0: [sdb] Incomplete mode parameter data
[ 159.765200] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[ 159.765778] sdb: sdb1
[ 159.766855] sd 7:0:0:0: [sdb] Incomplete mode parameter data
[ 159.766865] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[ 159.766875] sd 7:0:0:0: [sdb] Attached SCSI removable disk


>> As suggested by Jonathan N. [1] here is what I did next:
>>
>> $ cat /etc/modprobe.d/mm-blacklist-xhci.conf
>> blacklist xhci_hcd
>> $ update-initramfs -u -k all
>> $ sudo reboot
>
> Were you blacklisting xhci only because of the "xhci_hcd 0000:03:00.0:
> WARN: Stalled endpoint" messages? *Because those messages are harmless,
> and don't mean anything is *wrong* with the host controller.

I simply blindly follow the suggestion.

> Even if there's no xHCI driver loaded, it seems that ACPI is noticing
> the conflict between the PCI registers and another region. *So unloading
> the xHCI driver won't help your system boot. *You'd need to get a fix
> into the ACPI subsystem to work around the conflict. *I don't think any
> xHCI driver modification can help here.

Is there a way to check if bug is related to ACPI or rather USB 3.0 ?

Thanks again,
--
Mathieu



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CA+7wUswZph6iOKVZS5y9S-LPf72ToYPrG6ExXawhqQs_1KM5DQ@mail.gmail.com">http://lists.debian.org/CA+7wUswZph6iOKVZS5y9S-LPf72ToYPrG6ExXawhqQs_1KM5DQ@mail.gmail.com
 
Old 01-02-2012, 05:14 PM
Sarah Sharp
 
Default Bug#644174: ACPI I/O resource conflicts with ACPI region SMBI

On Wed, Dec 28, 2011 at 06:11:14PM +0100, Mathieu Malaterre wrote:
> On Thu, Dec 22, 2011 at 8:52 PM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> > On Thu, Dec 22, 2011 at 04:18:56PM +0100, Mathieu Malaterre wrote:
> >> On Fri, Dec 16, 2011 at 11:27 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> >> System: Dell System Vostro 3750 / Portable Computer
> >>
> >> Ok. So I am running: 3.2.0-rc4-amd64 from debian experimental.
> >>
> >> No mouse plugged to USB 2.0/3.0 interface: boot is fine
> >> Mouse plugged to USB 2.0 interface: boot is fine
> >> Mouse plugged to USB 3.0 interface: boot simply stops
> >
> > Does the boot stop when you have a non-HID USB device plugged into the
> > USB 3.0 port (e.g. hub or flash drive or USB speaker)? *It could be an
> > issue with a buggy BIOS trying to use the mouse and keyboard (HID
> > devices) attached to the USB 3.0 host. *Perhaps it changes the ACPI
> > tables when it tries to use the USB 3.0 host controller, and
> > accidentally overlaps the regions? *But if your keyboard and mouse were
> > under USB 2.0, maybe it will only map in the USB 2.0 host controller.
>
> I tried booting kernel 3.0.2 (debian/unstable 3.2.0-rc4-amd64) with a
> USB key plugged into USB 3.0 and was stuck again. So I can confirm
> that with a normal USB key (non-HID) plugged in USB 3.0 port, makes
> the kernel refuse to boot.

Please try a USB hub as well. It's possible the BIOS is trying to read
from the flash drive (which is what I assume you mean by USB key).

> >> As suggested by Jonathan N. [1] here is what I did next:
> >>
> >> $ cat /etc/modprobe.d/mm-blacklist-xhci.conf
> >> blacklist xhci_hcd
> >> $ update-initramfs -u -k all
> >> $ sudo reboot
> >
> > Were you blacklisting xhci only because of the "xhci_hcd 0000:03:00.0:
> > WARN: Stalled endpoint" messages? *Because those messages are harmless,
> > and don't mean anything is *wrong* with the host controller.
>
> I simply blindly follow the suggestion.

Yeah, don't try to blacklist xhci-hcd. It's not useful.

> > Even if there's no xHCI driver loaded, it seems that ACPI is noticing
> > the conflict between the PCI registers and another region. *So unloading
> > the xHCI driver won't help your system boot. *You'd need to get a fix
> > into the ACPI subsystem to work around the conflict. *I don't think any
> > xHCI driver modification can help here.
>
> Is there a way to check if bug is related to ACPI or rather USB 3.0 ?

The log messages seem to indicate that it's either an ACPI or a BIOS
issue. I really can't suggest any other tests without some input from
the ACPI folks. The best solution I can suggest is not boot with a USB
device plugged into your USB 3.0 port.

Sarah Sharp



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120102181430.GA8562@xanatos">http://lists.debian.org/20120102181430.GA8562@xanatos
 
Old 01-02-2012, 06:11 PM
Jonathan Nieder
 
Default Bug#644174: ACPI I/O resource conflicts with ACPI region SMBI

Quick side question:

Sarah Sharp wrote:

> Yeah, don't try to blacklist xhci-hcd. It's not useful.

How else do you suggest that people figure out whether symptoms are
produced by the xhci-hcd driver or something else? However, I agree
that it's not useful _any more_, since Mathieu tried that test
already.

[...]
> The log messages seem to indicate that it's either an ACPI or a BIOS
> issue. I really can't suggest any other tests without some input from
> the ACPI folks. The best solution I can suggest is not boot with a USB
> device plugged into your USB 3.0 port.

Hm. Mathieu, is it possible to suspend-to-disk ("echo disk >/sys/power/state")
and resume with a USB device plugged into the USB 3.0 port?

Please also attach output from "acpidump" after a successful boot.

Can you reproduce this when booting in recovery mode with
i915.modeset=0 appended to the kernel command line?

Thanks,
Jonathan



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120102191158.GC30183@elie.hsd1.il.comcast.net">h ttp://lists.debian.org/20120102191158.GC30183@elie.hsd1.il.comcast.net
 
Old 08-16-2012, 10:09 PM
Wojtek Zabolotny
 
Default Bug#644174: ACPI I/O resource conflicts with ACPI region SMBI

I don't know, if it helps to isolate the cause of the problem, but I've just stated that with kernel 3.5.2 my Vostro 3750 boots with USB device connected to USB 3.0 port, when I add the "pci=noacpi"
parameter to the kernel commandline in grub.


Without that parameter booting hangs as previously.
I attach the acpidump after successfull booting enforced by adding of "pci=noacpi".
--
Regards,
Wojtek
 
Old 08-16-2012, 10:17 PM
Wojtek Zabolotny
 
Default Bug#644174: ACPI I/O resource conflicts with ACPI region SMBI

I have also verified, that with 3.5.2 booted with "pci=noacpi"
the command "#echo disk>/sys/power/state" correctly suspends system to disk.
The operation is correctly resumed if I power on the system later on with the same kernel
and also with "pci=noacpi".

--
Regards,
Wojtek


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 502D7181.6040305@elka.pw.edu.pl">http://lists.debian.org/502D7181.6040305@elka.pw.edu.pl
 

Thread Tools




All times are GMT. The time now is 06:53 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org