[arch-dev-public] [signoff] udev 128-1
Thanks Eric for being on the ball. I didn't check for a new version today. Pushed to testing. Some important changes: * Stock rules are not in /lib/udev/rules.d/ * /etc/udev/rules.d is still respected and should be used for non-stock rules * Custom readme moved to /usr/share/udev. slated for removal later (man pages are superior) * Improved stock rules, will eventually need to clean up our Arch rules... * Possibly others. Please test and let me know how it goes. Also, a x86_64 build would be nice. Cheers, Aaron
2008/9/12 Aaron Griffin <aaronmgriffin@gmail.com>:
Thanks Eric for being on the ball. I didn't check for a new version today.
Pushed to testing. Some important changes: * Stock rules are not in /lib/udev/rules.d/
not -> now
* /etc/udev/rules.d is still respected and should be used for non-stock rules * Custom readme moved to /usr/share/udev. slated for removal later (man pages are superior) * Improved stock rules, will eventually need to clean up our Arch rules... * Possibly others.
Please test and let me know how it goes.
Also, a x86_64 build would be nice.
-- Roman Kyrylych (Роман Кирилич)
Aaron Griffin schrieb:
Thanks Eric for being on the ball. I didn't check for a new version today.
Pushed to testing. Some important changes: * Stock rules are not in /lib/udev/rules.d/ * /etc/udev/rules.d is still respected and should be used for non-stock rules * Custom readme moved to /usr/share/udev. slated for removal later (man pages are superior) * Improved stock rules, will eventually need to clean up our Arch rules... * Possibly others.
Please test and let me know how it goes.
Also, a x86_64 build would be nice.
Cheers, Aaron
Damn, I haven't checked in the new load-modules script with the fixed blacklist yet. I'll do that later today and release a -2 then, if that is alright. Also, would you mind looking at klibc-udev? It's only used for a fraction of a second on every boot, but we should still update it.
Aaron Griffin wrote:
Thanks Eric for being on the ball. I didn't check for a new version today.
Pushed to testing. Some important changes: * Stock rules are not in /lib/udev/rules.d/ * /etc/udev/rules.d is still respected and should be used for non-stock rules * Custom readme moved to /usr/share/udev. slated for removal later (man pages are superior) * Improved stock rules, will eventually need to clean up our Arch rules... * Possibly others.
Please test and let me know how it goes.
Also, a x86_64 build would be nice.
Cheers, Aaron
I still lose (at least) my wireless network connection when I update to this udev version. I'm using gnome-network-manager with an Intel PRO/Wireless 3945ABG card and iwlwifi. Trying to figure this out now because I like the internet... Allan
Allan McRae schrieb:
I still lose (at least) my wireless network connection when I update to this udev version. I'm using gnome-network-manager with an Intel PRO/Wireless 3945ABG card and iwlwifi. Trying to figure this out now because I like the internet...
Two possible causes: 1) The module isn't loaded. This is easy to fix, as you just need to load it manually. 2) The firmware isn't loaded. This is more difficult to fix. Can you see if iwl3945 is in lsmod and if so, check dmesg.
Thomas Bächler wrote:
Allan McRae schrieb:
I still lose (at least) my wireless network connection when I update to this udev version. I'm using gnome-network-manager with an Intel PRO/Wireless 3945ABG card and iwlwifi. Trying to figure this out now because I like the internet...
Two possible causes: 1) The module isn't loaded. This is easy to fix, as you just need to load it manually. 2) The firmware isn't loaded. This is more difficult to fix.
Can you see if iwl3945 is in lsmod and if so, check dmesg.
iwl3945 is in lsmod. Taking a diff with the dmesg output with the old and new udev package gives this bit of interesting output: -ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17 -PM: Writing back config space on device 0000:0c:00.0 at offset 1 (was 100102, writing 100106) -firmware: requesting iwlwifi-3945-1.ucode -Registered led device: iwl-phy0:radio -Registered led device: iwl-phy0:assoc -Registered led device: iwl-phy0:RX -Registered led device: iwl-phy0:TX [drm] Initialized drm 1.1.0 20060810 ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:02.0 to 64 [drm] Initialized i915 1.6.0 20060119 on minor 0 NET: Registered protocol family 10 lo: Disabled Privacy Extensions -ADDRCONF(NETDEV_UP): eth0: link is not ready -ADDRCONF(NETDEV_UP): wlan0: link is not ready -wlan0: Initial auth_alg=0 -wlan0: authenticate with AP 00:15:e9:cc:1e:be -wlan0: RX authentication from 00:15:e9:cc:1e:be (alg=0 transaction=2 status=0) -wlan0: authenticated -wlan0: associate with AP 00:15:e9:cc:1e:be -wlan0: RX AssocResp from 00:15:e9:cc:1e:be (capab=0x471 status=0 aid=2) -wlan0: associated -wlan0: switched to short barker preamble (BSSID=00:15:e9:cc:1e:be) -ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready -wlan0: no IPv6 routers present
Allan McRae wrote:
Aaron Griffin wrote:
Thanks Eric for being on the ball. I didn't check for a new version today.
Pushed to testing. Some important changes: * Stock rules are not in /lib/udev/rules.d/ * /etc/udev/rules.d is still respected and should be used for non-stock rules * Custom readme moved to /usr/share/udev. slated for removal later (man pages are superior) * Improved stock rules, will eventually need to clean up our Arch rules... * Possibly others.
Please test and let me know how it goes.
Also, a x86_64 build would be nice.
Cheers, Aaron
I still lose (at least) my wireless network connection when I update to this udev version. I'm using gnome-network-manager with an Intel PRO/Wireless 3945ABG card and iwlwifi. Trying to figure this out now because I like the internet...
So, the dependency path from gnome-network-manager to udev is: |--gnome-network-manager |--networkmanager |--hal |--udev It appears hal needs a rebuild because of the libvolume_id soname bump in the udev package. Updating udev then restarting hal and networkmanager make my internet die. I very quickly tried rebuilding hal but it failed.... checking whether to rebuild gperf header files... checking for DBUS... yes checking for GLIB... yes checking if GLib is version 2.14.0 or newer... yes checking for VOLUME_ID... configure: error: Package requirements (libvolume_id >= 0.77) were not met: No package 'libvolume_id' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables VOLUME_ID_CFLAGS and VOLUME_ID_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.
Allan McRae wrote:
Allan McRae wrote:
Aaron Griffin wrote:
Thanks Eric for being on the ball. I didn't check for a new version today.
Pushed to testing. Some important changes: * Stock rules are not in /lib/udev/rules.d/ * /etc/udev/rules.d is still respected and should be used for non-stock rules * Custom readme moved to /usr/share/udev. slated for removal later (man pages are superior) * Improved stock rules, will eventually need to clean up our Arch rules... * Possibly others.
Please test and let me know how it goes.
Also, a x86_64 build would be nice.
Cheers, Aaron
I still lose (at least) my wireless network connection when I update to this udev version. I'm using gnome-network-manager with an Intel PRO/Wireless 3945ABG card and iwlwifi. Trying to figure this out now because I like the internet...
So, the dependency path from gnome-network-manager to udev is: |--gnome-network-manager |--networkmanager |--hal |--udev
It appears hal needs a rebuild because of the libvolume_id soname bump in the udev package. Updating udev then restarting hal and networkmanager make my internet die. I very quickly tried rebuilding hal but it failed....
checking whether to rebuild gperf header files... checking for DBUS... yes checking for GLIB... yes checking if GLib is version 2.14.0 or newer... yes checking for VOLUME_ID... configure: error: Package requirements (libvolume_id >= 0.77) were not met:
No package 'libvolume_id' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.
Alternatively, you may set the environment variables VOLUME_ID_CFLAGS and VOLUME_ID_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.
That error is because /usr/lib/pkgconfig/libvolume_id.pc moved to /lib/pkgconfig. Anyway, rebuilding hal doe snot fix my problem.
Allan McRae schrieb:
So, the dependency path from gnome-network-manager to udev is: |--gnome-network-manager |--networkmanager |--hal |--udev
It appears hal needs a rebuild because of the libvolume_id soname bump in the udev package. Updating udev then restarting hal and networkmanager make my internet die. I very quickly tried rebuilding hal but it failed....
checking whether to rebuild gperf header files... checking for DBUS... yes checking for GLIB... yes checking if GLib is version 2.14.0 or newer... yes checking for VOLUME_ID... configure: error: Package requirements (libvolume_id >= 0.77) were not met:
No package 'libvolume_id' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.
Alternatively, you may set the environment variables VOLUME_ID_CFLAGS and VOLUME_ID_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.
This is definitely a blocker. I am confused though, as volume_id is only required for hald-probe-storage and hald-probe-volume, which should not block hal from starting. Does hal start up at all and if yes, what processes are running (ps ax|grep -i hal)? As your problem seems related to networkmanager, is the interface present? Do the missing dmesg lines (about firmware and LED) show up when you simply run ifconfig wlan0 up?
Thomas Bächler wrote:
Allan McRae schrieb:
So, the dependency path from gnome-network-manager to udev is: |--gnome-network-manager |--networkmanager |--hal |--udev
It appears hal needs a rebuild because of the libvolume_id soname bump in the udev package. Updating udev then restarting hal and networkmanager make my internet die. I very quickly tried rebuilding hal but it failed....
checking whether to rebuild gperf header files... checking for DBUS... yes checking for GLIB... yes checking if GLib is version 2.14.0 or newer... yes checking for VOLUME_ID... configure: error: Package requirements (libvolume_id >= 0.77) were not met:
No package 'libvolume_id' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.
Alternatively, you may set the environment variables VOLUME_ID_CFLAGS and VOLUME_ID_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.
This is definitely a blocker. I am confused though, as volume_id is only required for hald-probe-storage and hald-probe-volume, which should not block hal from starting.
Does hal start up at all and if yes, what processes are running (ps ax|grep -i hal)?
Hal starts up fine. With the new udev I get the following processes: /usr/sbin/hald hald-runner /usr/lib/hal/hald-addon-cpufreq hald-addon-acpi: listening on acpi kernel interface /proc/acpi/event With the old udev I also get: /usr/lib/hal/hald-addon-dell-backlight hald-addon-input: Listening on /dev/input/event1 /dev/input/event2 /dev/input/event3 /dev/input/event4 /dev/input/event5 /dev/input/event6 hald-addon-storage: polling /dev/sr0 (every 2 sec) The storage one will be a libvolume_id issue but not sure about the other two.
As your problem seems related to networkmanager, is the interface present? Do the missing dmesg lines (about firmware and LED) show up when you simply run ifconfig wlan0 up?
Running "ifconfig wlan0 up" adds these lines to the dmesg output.
On Fri, Sep 12, 2008 at 11:38 AM, Allan McRae <allan@archlinux.org> wrote:
I still lose (at least) my wireless network connection when I update to this udev version. I'm using gnome-network-manager with an Intel PRO/Wireless 3945ABG card and iwlwifi. Trying to figure this out now because I like the internet...
Well, maybe it was a good idea to push udev to testing so that good ppl like you can start investigating the issue :) For the record : http://www.archlinux.org/pipermail/arch-dev-public/2008-August/007814.html The gitweb link I gave there does not seem to work anymore, but you can see the corresponding ML post instead : http://lists.freedesktop.org/archives/hal/2008-August/012177.html I thought hal <-> udev communication was broken because of the missing udevinfo symlink, but reintroducing it did not help. So there might be other problems.
Xavier schrieb:
Well, maybe it was a good idea to push udev to testing so that good ppl like you can start investigating the issue :) For the record : http://www.archlinux.org/pipermail/arch-dev-public/2008-August/007814.html The gitweb link I gave there does not seem to work anymore, but you can see the corresponding ML post instead : http://lists.freedesktop.org/archives/hal/2008-August/012177.html
I thought hal <-> udev communication was broken because of the missing udevinfo symlink, but reintroducing it did not help. So there might be other problems.
The patch you linked in that post suggests that you have to use "udevadm info" instead of "udevinfo". Maybe in earlier versions of udev, udevadm checked the value of argv[0] and now doesn't any more, thus a symlink will not suffice. Can you try adding a script called udevinfo with the contents: #!/bin/sh exec /sbin/udevadm info $* and see if it solves your problems? If yes, we can simply apply the patch http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=f6af40c1e7ea54e69eb2... to hal.
Thomas Bächler schrieb:
I thought hal <-> udev communication was broken because of the missing udevinfo symlink, but reintroducing it did not help. So there might be other problems.
The patch you linked in that post suggests that you have to use "udevadm info" instead of "udevinfo". Maybe in earlier versions of udev, udevadm checked the value of argv[0] and now doesn't any more, thus a symlink will not suffice.
Can you try adding a script called udevinfo with the contents: #!/bin/sh exec /sbin/udevadm info $* and see if it solves your problems? If yes, we can simply apply the patch http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=f6af40c1e7ea54e69eb2... to hal.
I applied the patch to hal and threw it to testing. I had another user test this: Without the patch, Xorg input hotplugging broke. When he added the udevinfo script like above, it worked again. I guess all udev interaction (including Allan's nm issue) are related to this. I'll upload a new cryptsetup as well, as the current version calls udevsettle ... the next version of cryptsetup will work without that though.
Thomas Bächler schrieb:
I applied the patch to hal and threw it to testing. I had another user test this: Without the patch, Xorg input hotplugging broke. When he added the udevinfo script like above, it worked again. I guess all udev interaction (including Allan's nm issue) are related to this.
The patch was incomplete, I applied the second part to blockdev.c as well. Automounting works great on KDE4, but is apparently broken on gnome. If anyone can find out why, I'd be glad to hear it.
On Fri, Sep 12, 2008 at 8:05 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Thomas Bächler schrieb:
I applied the patch to hal and threw it to testing. I had another user test this: Without the patch, Xorg input hotplugging broke. When he added the udevinfo script like above, it worked again. I guess all udev interaction (including Allan's nm issue) are related to this.
The patch was incomplete, I applied the second part to blockdev.c as well. Automounting works great on KDE4, but is apparently broken on gnome. If anyone can find out why, I'd be glad to hear it.
Using hal git (and removing all patches from the pkgbuild), I now see the usb device in gnome, but still can't mount it. Thunar works perfectly, and I assume that kde4 too.
On Fri, 2008-09-12 at 20:37 +0200, Xavier wrote:
On Fri, Sep 12, 2008 at 8:05 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Thomas Bächler schrieb:
I applied the patch to hal and threw it to testing. I had another user test this: Without the patch, Xorg input hotplugging broke. When he added the udevinfo script like above, it worked again. I guess all udev interaction (including Allan's nm issue) are related to this.
The patch was incomplete, I applied the second part to blockdev.c as well. Automounting works great on KDE4, but is apparently broken on gnome. If anyone can find out why, I'd be glad to hear it.
Not sure if it's related but on my testing partition all my ext3 fs's in fstab won't mount. When I mount them manually they autodetect as ext2.
Using hal git (and removing all patches from the pkgbuild), I now see the usb device in gnome, but still can't mount it. Thunar works perfectly, and I assume that kde4 too. -- K. Piche <kpiche@rogers.com>
On Fri, 2008-09-12 at 20:37 +0200, Xavier wrote:
Using hal git (and removing all patches from the pkgbuild), I now see the usb device in gnome, but still can't mount it. Thunar works perfectly, and I assume that kde4 too.
USB thingy no worky here neither. Just put hal and udev in ignorepkg for now.
Eduardo Romero schrieb:
On Fri, 2008-09-12 at 20:37 +0200, Xavier wrote:
Using hal git (and removing all patches from the pkgbuild), I now see the usb device in gnome, but still can't mount it. Thunar works perfectly, and I assume that kde4 too.
USB thingy no worky here neither. Just put hal and udev in ignorepkg for now.
What DE (or other mounting method)? This is important, as so far only gnome-volume-manager failed. Note that updating hal should be no problem, the old udev versions have udevadm already and all the new version does is change udevinfo calls to udevadm calls. The problem seems to be somewhere in udev.
On Sat, 2008-09-13 at 09:33 +0200, =?ISO-8859-1?Q?Thomas_B=E4chler_ wrote:
Eduardo Romero schrieb:
On Fri, 2008-09-12 at 20:37 +0200, Xavier wrote:
Using hal git (and removing all patches from the pkgbuild), I now see the usb device in gnome, but still can't mount it. Thunar works perfectly, and I assume that kde4 too.
USB thingy no worky here neither. Just put hal and udev in ignorepkg for now.
What DE (or other mounting method)? This is important, as so far only gnome-volume-manager failed.
Note that updating hal should be no problem, the old udev versions have udevadm already and all the new version does is change udevinfo calls to udevadm calls. The problem seems to be somewhere in udev.
Oh, Sorry I didn't gave much info, but I was having the same issue as Xavier. Using Nautilus, gnome-volume-manager, the USB is visible but does not mount, and doesn't spit out any graphical error. And the package in questions is udev-128-2 and hal-0.5.11-3. As a side not, also udev takes now twice the time to start up, from 3s to 6-7s.
Eduardo Romero schrieb:
As a side note, also udev takes now twice the time to start up, from 3s to 6-7s.
It didn't slow down here at all, I still have 3 seconds for uevents. It is possible that the blacklist checks take more time now though. 6 seconds isn't too bad, considering we had 30 to 60 seconds in the past sometimes.
Thomas Bächler schrieb:
Thomas Bächler schrieb:
I applied the patch to hal and threw it to testing. I had another user test this: Without the patch, Xorg input hotplugging broke. When he added the udevinfo script like above, it worked again. I guess all udev interaction (including Allan's nm issue) are related to this.
The patch was incomplete, I applied the second part to blockdev.c as well. Automounting works great on KDE4, but is apparently broken on gnome. If anyone can find out why, I'd be glad to hear it.
I just spoke to Allan, and the fixed hal solves his networkmanager problem.
Am Samstag 13 September 2008 schrieb Thomas Bächler:
Thomas Bächler schrieb:
Thomas Bächler schrieb:
I applied the patch to hal and threw it to testing. I had another user test this: Without the patch, Xorg input hotplugging broke. When he added the udevinfo script like above, it worked again. I guess all udev interaction (including Allan's nm issue) are related to this.
The patch was incomplete, I applied the second part to blockdev.c as well. Automounting works great on KDE4, but is apparently broken on gnome. If anyone can find out why, I'd be glad to hear it.
I just spoke to Allan, and the fixed hal solves his networkmanager problem. Boots fine here, all my groups and symlinks are there,
signoff x86_64 -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
udev 128-3 is wokrking fine here, signoff i686.
Aaron Griffin schrieb:
Thanks Eric for being on the ball. I didn't check for a new version today.
Pushed to testing. Some important changes: * Stock rules are not in /lib/udev/rules.d/ * /etc/udev/rules.d is still respected and should be used for non-stock rules * Custom readme moved to /usr/share/udev. slated for removal later (man pages are superior) * Improved stock rules, will eventually need to clean up our Arch rules... * Possibly others.
Please test and let me know how it goes.
Also, a x86_64 build would be nice.
Changes compared to -1: - Fixed path: /lib/pkgconfig -> /usr/lib/pkgconfig - Rewrote load-modules.sh: + Fixes http://bugs.archlinux.org/task/10972 This adds a new resolve-modalias binary, which resolves an alias without resolving the dependencies (modprobe can't do that). If you have a device which can be used by modules A and B, blacklisting A will no longer result in B being blacklisted with it. resolve-modalias has gcc-libs as a dependency, but gcc-libs is in base anyway, so it shouldn't matter. + Adds more comprehensive messages to /var/log/everything.log including a reason why a module hasn't been loaded. + If you want to disable a device completely, you can blacklist the modalias to prevent all matching modules from being loaded. This should make rc.conf blacklisting way more intuitive. - Fixed 80-drivers.rules: This was horribly broken, as modprobe was often called instead of load-modules.sh and thus blacklisting was completely disabled in -1, - Add only framebuffer drivers to the framebuffer blacklist, not random modules containing the string 'fb' Packages are available for i686 and x86_64 now, please sign off.
On Fri, Sep 12, 2008 at 10:05 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Aaron Griffin schrieb:
Thanks Eric for being on the ball. I didn't check for a new version today.
Pushed to testing. Some important changes: * Stock rules are not in /lib/udev/rules.d/ * /etc/udev/rules.d is still respected and should be used for non-stock rules * Custom readme moved to /usr/share/udev. slated for removal later (man pages are superior) * Improved stock rules, will eventually need to clean up our Arch rules... * Possibly others.
Please test and let me know how it goes.
Also, a x86_64 build would be nice.
Changes compared to -1: - Fixed path: /lib/pkgconfig -> /usr/lib/pkgconfig - Rewrote load-modules.sh: + Fixes http://bugs.archlinux.org/task/10972 This adds a new resolve-modalias binary, which resolves an alias without resolving the dependencies (modprobe can't do that). If you have a device which can be used by modules A and B, blacklisting A will no longer result in B being blacklisted with it. resolve-modalias has gcc-libs as a dependency, but gcc-libs is in base anyway, so it shouldn't matter. + Adds more comprehensive messages to /var/log/everything.log including a reason why a module hasn't been loaded. + If you want to disable a device completely, you can blacklist the modalias to prevent all matching modules from being loaded. This should make rc.conf blacklisting way more intuitive. - Fixed 80-drivers.rules: This was horribly broken, as modprobe was often called instead of load-modules.sh and thus blacklisting was completely disabled in -1, - Add only framebuffer drivers to the framebuffer blacklist, not random modules containing the string 'fb'
Thanks for the rewrite Thomas. Has this sped anything up for you? I know my udev time on boot is usually between 4s and 6s, so I'll see if this affects anything when I reboot
Aaron Griffin schrieb: >>> Also, a x86_64 build would be nice. >> Changes compared to -1: >> - Fixed path: /lib/pkgconfig -> /usr/lib/pkgconfig >> - Rewrote load-modules.sh: >> + Fixes http://bugs.archlinux.org/task/10972 >> This adds a new resolve-modalias binary, which resolves an alias >> without resolving the dependencies (modprobe can't do that). If you >> have a device which can be used by modules A and B, blacklisting A >> will no longer result in B being blacklisted with it. >> resolve-modalias has gcc-libs as a dependency, but gcc-libs is in >> base anyway, so it shouldn't matter. >> + Adds more comprehensive messages to /var/log/everything.log >> including a reason why a module hasn't been loaded. >> + If you want to disable a device completely, you can blacklist the >> modalias to prevent all matching modules from being loaded. >> This should make rc.conf blacklisting way more intuitive. >> - Fixed 80-drivers.rules: This was horribly broken, as modprobe was >> often called instead of load-modules.sh and thus blacklisting was >> completely disabled in -1, >> - Add only framebuffer drivers to the framebuffer blacklist, not random >> modules containing the string 'fb' > > Thanks for the rewrite Thomas. Has this sped anything up for you? I > know my udev time on boot is usually between 4s and 6s, so I'll see if > this affects anything when I reboot 3.2 seconds as usual. However, I now get Sep 12 18:32:25 artin load-modules.sh: Not loading module '8139cp' for alias 'pci:v000010ECd00008139sv000017AAsd00002074bc02sc00i00' because it is blacklisted in my everything.log. In earlier load-modules version, blacklisting 8139cp would have also disabled 8139too, which is necessary for my LAN.
participants (8)
-
Aaron Griffin
-
Allan McRae
-
Eduardo Romero
-
K. Piche
-
Roman Kyrylych
-
Thomas Bächler
-
Tobias Powalowski
-
Xavier