Re: Determining disk device and kicking GEOM when doing automatic mounting of umass devices
Darren Pilgrim [EMAIL PROTECTED] writes:
GEOM doesn't automatically read the partition table and create the
slice device [...]
Yes, it does. When the umassX provider shows up, GEOM immediately
tastes it and creates geoms for the individual slices.
If it really doesn't on your system, try the following:
# /etc/rc.d/devd stop
# logger START
# sysctl debug.bootverbose=1
# sysctl -b kern.geom.conftxt geom-before
[insert umass device, wait 10 secs]
# sysctl -b kern.geom.conftxt geom-after
# sysctl debug.bootverbose=0
# logger STOP
# /etc/rc.d/devd start
# awk '/START/{s=1}{if(s)print}/STOP/{s=0}' /var/log/messages geom-logs
then post the contents of geom-{before,after,logs}.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: usbd.conf: detach ukbd
-Original Message- From: Maksim Yevmenkin [mailto:[EMAIL PROTECTED] Sent: Thursday, June 09, 2005 5:50 PM To: Norbert Koch Cc: [EMAIL PROTECTED] Org Subject: Re: usbd.conf: detach ukbd Norbert, when running usbd (under FreeBSD 4.11) with -dv switches I can see that a usb keyboard correctly attaches as ukbd0, but detaches as fall-through USB device. can you please tell what is in your /etc/usbd.conf? Do I just have to live with that fact or can I change that anyhow? Is that a device/device-class specific problem? does something like device USB keyboard devname ukbd[0-9]+ attach foo detach bar work? note: please replace foo and bar with actual commands you want to be executed. No it does not, which is exactly my problem. Actually, I don't have the wildcard in my devname, just ukbd0, but that doesn't make the difference, I think. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: usbd.conf: detach ukbd
I'm not sure if detach is supported like that, because the ukbd
device name
will not be passed to usbd during detach. Then one needs to
match against
the class/subclass of the USB-keyboard:
device USB keyboard
class 3
subclass 1
detach ukbd0
But from what I see, when running usbd, the class and
subclass keys of the cherry keyboard, I am testing with,
are both zero at attach and detach. So, one idea would be
to rewrite usbd.conf in the attach script. Usbd
- as it is now - does only setenv (DEVNAME), but it
would be trivial to add e.g. setenv (VENDOR) and
setenv (PRODUCTID).
Else if devd is not available on 4.11 you will have to change
some code and
compile a new kernel, from what I can see.
To the file /sys/dev/usb/ukbd.c add this:
static void
usbd_add_device_detach_event(device_t self)
{
struct usb_event ue;
bzero(ue, sizeof(ue));
strlcpy(ue.u.ue_device.udi_devnames[0],
device_get_nameunit(self), USB_MAX_DEVNAMELEN) ;
usb_add_event(USB_EVENT_DEVICE_DETACH, ue);
return;
}
ukbd_detach()
{
...
usbd_add_device_detach_event(self);
return (0);
}
This will make the suggestion from Maksim work.
A generic solution would be to call
usbd_add_device_detach_event() from the
bus_child_detached method of uhub, which must be added.
Also one can change usb_disconnect_port() to generate the event
before the
sub-devices are detached, but that might not work in all cases.
--HPS
Hmm, may be I'll try this.
Thank you very much.
Norbert
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Determining disk device and kicking GEOM when doing automatic mounting of umass devices
From: Dag-Erling Smørgrav [mailto:[EMAIL PROTECTED]
Darren Pilgrim [EMAIL PROTECTED] writes:
GEOM doesn't automatically read the partition table and create the
slice device [...]
Yes, it does. When the umassX provider shows up, GEOM immediately
tastes it and creates geoms for the individual slices.
If it really doesn't on your system, try the following:
# /etc/rc.d/devd stop
# logger START
# sysctl debug.bootverbose=1
# sysctl -b kern.geom.conftxt geom-before
[insert umass device, wait 10 secs]
# sysctl -b kern.geom.conftxt geom-after
# sysctl debug.bootverbose=0
# logger STOP
# /etc/rc.d/devd start
# awk '/START/{s=1}{if(s)print}/STOP/{s=0}' /var/log/messages
geom-logs
then post the contents of geom-{before,after,logs}.
Attached as named above. The logs show the da0 DISK class in the GEOM
config, but no MBR class entry.
This is on -current as of May 22.
geom-before
Description: Binary data
geom-after
Description: Binary data
geom-logs
Description: Binary data
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Determining disk device and kicking GEOM when doing automatic mounting of umass devices
Darren Pilgrim [EMAIL PROTECTED] writes: Attached as named above. The logs show the da0 DISK class in the GEOM config, but no MBR class entry. Take a closer look at geom-logs. It shows a slew of CAM errors. There's something wrong with your fob, or possibly (but not likely) with the USB stack. Here's what I get in a similar scenario: Jun 10 09:14:02 xps des: START Jun 10 09:14:06 xps kernel: umass0: vendor 0x0d7d USB DISK, rev 1.10/1.00, addr 5 Jun 10 09:14:06 xps kernel: umass0:0:0:-1: Attached to scbus0 Jun 10 09:14:07 xps kernel: pass0 at umass-sim0 bus 0 target 0 lun 0 Jun 10 09:14:07 xps kernel: pass0: USB DISK 1.20 Removable Direct Access SCSI-0 device Jun 10 09:14:07 xps kernel: pass0: Serial Number Jun 10 09:14:07 xps kernel: pass0: 1.000MB/s transfers Jun 10 09:14:07 xps kernel: GEOM: new disk da0 Jun 10 09:14:07 xps kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Jun 10 09:14:07 xps kernel: da0: USB DISK 1.20 Removable Direct Access SCSI-0 device Jun 10 09:14:07 xps kernel: da0: Serial Number Jun 10 09:14:07 xps kernel: da0: 1.000MB/s transfers Jun 10 09:14:07 xps kernel: da0: 31MB (64000 512 byte sectors: 64H 32S/T 31C) Jun 10 09:14:13 xps des: STOP except my fob is unpartitioned (like a floppy), which is why I only get da0. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to do a routing lookup inside the kernel in FreeBSD ?
On Thu, Jun 09, 2005 at 05:42:16PM -0400, Aziz Kezzou wrote: Hi all, I am trying to figure out from the kernel source code (FreeBSD 5.3) how can I perform a routing lookup in a KLD module. Since I am short in time, if anyone knows how do to do this I would appreciate. Any pointers to the right portion of the code are also apperciated. man 9 rtalloc Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgplMLIfk8hyC.pgp Description: PGP signature
RE: Determining disk device and kicking GEOM when doing automatic mounting of umass devices
-Original Message- From: Dag-Erling Smørgrav [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 12:16 AM To: Darren Pilgrim Cc: freebsd-hackers@freebsd.org Subject: Re: Determining disk device and kicking GEOM when doing automatic mounting of umass devices Darren Pilgrim [EMAIL PROTECTED] writes: Attached as named above. The logs show the da0 DISK class in the GEOM config, but no MBR class entry. Take a closer look at geom-logs. It shows a slew of CAM errors. There's something wrong with your fob, or possibly (but not likely) with the USB stack. Except that after all those errors, it still mounts and works fine. Also, trying to mount /dev/da0 does produce the MBR entry in the GEOM config: 1 MBR da0s1 255849984 512 i 0 o 2048 ty 11 It also produces a single READ CAPACITY CAM error like those produced when the device attaches. I also tested with a known-good USB zip drive plugged into the same USB port. It attached flawlessly: the console showed the normal attach messages, GEOM config shows the appropriate MBR entry and /dev/da0s4 is created. So yeah I gueuss my fob is busted or funky. The CAM errors are just the drive saying there's no media present, so maybe the device doesn't support the commands necessary to report disk capacity? Is there a way to educate CAM about this so the attach procedure doesn't break? Why would the CAM errors prevent GEOM from creating the MBR geom during attach but not when trying to mount /dev/da0? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Google SoC idea
On 6/8/05, Scott Long [EMAIL PROTECTED] wrote: Ivan Voras wrote: Scott Long wrote: Again, I'm not exactly sure how a generic mechanism can handle the distinction of data vs. metadata vs. journal data. Also, what you I don't care about the distinction at this level - all data is treated equal. But for journalling to work, you must care about the distinction. No, one does not have to concern oneself if the data block they are currently processing is data or metadata. That issue is completely dependent on the type of journaling implementation one is trying to achieve. -- -David Steven David Rhodus [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
X86 machine code enter and FreeBSD kernel
I received no reply on this question at questions mailing list, so I try asking this here. Hope I'm not asking this in completely wrong list. In recent discussion in OpenWatcom lists it was noticed that at least certain addressing modes of assembler ENTER instruction causes a crash when used in Linux. GCC circumnavigates this by not emitting ENTER instructions in machine code. Linus's comment on the above issue can be found on: http://groups.google.co.nz/groups?selm=7i86ni%24b7n%241%40palladium.transmeta.com What's the status of the above feature in FreeBSD, does the kernel support the whole x86 instruction set without similar cut corners? -Reko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: X86 machine code enter and FreeBSD kernel
I received no reply on this question at questions mailing list, so I try asking this here. Hope I'm not asking this in completely wrong list. In recent discussion in OpenWatcom lists it was noticed that at least certain addressing modes of assembler ENTER instruction causes a crash when used in Linux. GCC circumnavigates this by not emitting ENTER instructions in machine code. Linus's comment on the above issue can be found on: http://groups.google.co.nz/groups?selm=7i86ni%24b7n%241%40palladium.transmeta.com What's the status of the above feature in FreeBSD, does the kernel support the whole x86 instruction set without similar cut corners? -Reko Mainly, I think gcc sets stack by hands beacause ENTER does a lot of dirty work. If you see x86 pseudocode, it perform a lot of wasting work... however, what you proposed is not a bug, just a way of ruling stack frames. rookie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X86 machine code enter and FreeBSD kernel
Hi, Reko Turja wrote: I received no reply on this question at questions mailing list, so I try asking this here. Hope I'm not asking this in completely wrong list. In recent discussion in OpenWatcom lists it was noticed that at least certain addressing modes of assembler ENTER instruction causes a crash when used in Linux. GCC circumnavigates this by not emitting ENTER instructions in machine code. Linus's comment on the above issue can be found on: http://groups.google.co.nz/groups?selm=7i86ni%24b7n%241%40palladium.transmeta.com What's the status of the above feature in FreeBSD, does the kernel support the whole x86 instruction set without similar cut corners? This here is out of my memory from the days when 'enter' was a new instruction. So, do not kill me if I am wrong. 'enter' allows to specify a nesting level. Languages like Pascal can use this for functions which are local to other functions to enable the inner function to access the stack of the outer function. C does not support this at all. So, if you use this instruction, it must be used with a nesting level of zero. This will not cause any problems but will be a plain waste of CPU time. Erich ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bootable CDROM creation system
On Jun 8, 2005, at 11:35 PM, Dag-Erling Smørgrav wrote: Chad David [EMAIL PROTECTED] writes: My company built a tool a few years back for creating a bootable cdrom based on a running host FreeBSD 3/4 system, which promptly got shelved and forgotten.I recently had to update it for FreeBSD 5 and thought that perhaps the community at large could make use it before it gets forgotten again. # cd /usr/src # make buildworld buildkernel # mkdir /tmp/cdrom # make installworld installkernel DESTDIR=/tmp/cdrom # cd /usr/src/etc # make distribution DESTDIR=/tmp/cdrom # mkisofs -o /tmp/cdrom.iso -r -no-emul-boot -b /tmp/cdrom/boot/cdboot /tmp/cdrom # burncd -s max data /tmp/cdrom.iso fixate eject did I leave anything out? I think you need to use -b boot/cdboot (i.e. I think it's a relative path to the root of the image) or it won't work and it's --no-emul-boot I believe. -J can be handy for Windoze systems as well. :-P -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Screen Resolution
On May 29, 2005, at 11:42 PM, Erich Dollansky wrote: Hi, Hervé Kergourlay wrote: xorgconfig I launch this tools but I 'm not sure of the screen resolution details, vertical refresh rate, horizontal sync rate, ... I fill the answers with standard values Do not do this. You must have the details for you monitor. Especially if it is a CRT, it could even kill it if the details are wrong. but at the end, no xorg.conf file is written on the disk in /etc/X11 ? It has to be there. No it doesn't. xorgcfg actually defaults to writing xorg.conf to some subdirectory of /usr/X11R6/lib/X11 or some such nowadays rather than /etc/X11. You can see that path when you ask it to save the configuration. Probably the docs need to be updated to include the other more cryptic path as another place to look besides /etc/X11. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
unitialized memory is all zeros...why not garbage instead?
Hey everybody,
I have a feeling that I'm missing something really obvious, but I'm having
trouble understanding why the following program:
#include stdlib.h
#include stdio.h
int main (int argc, char * argv[])
{
void * ptr = malloc(65536);
size_t i;
for (i = 0; i 65536; i++)
{
printf (%x, *((unsigned char *)ptr + i));
if ((i % 16) == 0)
{
puts(\n);
}
}
return 0;
}
Never prints anything but 0's.
I ran less up to my hw.physmem by feeding it /dev/random and watching
top, and then ran the program, so I know there was tons of non-zero
bits in memory.
I'm curious because I am worried about information leaks between processes
on the same machine...did somebody decide to solve this problem while I
wasn't paying attention? :)
%gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.2 [FreeBSD] 20040728
%uname -a
FreeBSD mylabtop.berkeley.edu 5.4-STABLE FreeBSD 5.4-STABLE #1: Wed May
11 12:05:39 PDT 2005
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unitialized memory is all zeros...why not garbage instead?
In the last episode (Jun 10), Mike Hunter said:
I have a feeling that I'm missing something really obvious, but I'm
having trouble understanding why the following program:
int main (int argc, char * argv[])
{
void * ptr = malloc(65536);
Never prints anything but 0's.
The kernel zeros out memory before handing it to processes.
--
Dan Nelson
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Slowing down an old program to run on a fast CPU?
Hey everybody, I was playing around in ports and came across xroach. Cool program :) The only problem is that it runs too fast; you can't see the roaches because they scurry under your windows too quickly. Is there a general-purpose approach to this kind of problem in the FBSD world? I can see myself writing a C program called `slow` that would take argv[1] as the factor ( 1) by which argv[2] should be slowed down by. Anybody else ever come up against this? Thanks and happy Friday! Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slowing down an old program to run on a fast CPU?
On Fri, 10 Jun 2005, Mike Hunter wrote: Hey everybody, I was playing around in ports and came across xroach. Cool program :) The only problem is that it runs too fast; you can't see the roaches because they scurry under your windows too quickly. Is there a general-purpose approach to this kind of problem in the FBSD world? I can see myself writing a C program called `slow` that would take argv[1] as the factor ( 1) by which argv[2] should be slowed down by. Anybody else ever come up against this? Thanks and happy Friday! You could try installing vmware and running however many copies of windows it takes to make the game playable... (i would say some other form of *BSD, but it probobly wouldn't hog as much cpu :P) ~NVX ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unitialized memory is all zeros...why not garbage instead?
At 3:40 PM -0700 6/10/05, Mike Hunter wrote: Hey everybody, I have a feeling that I'm missing something really obvious, but I'm having trouble understanding why the following program: Never prints anything but 0's. Kernel generally clears out memory in the background. See also the man page for 'malloc', which will describe some options that you can set by creating an appropriate symlink at /etc/malloc.conf. In particular, the -J flag. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slowing down an old program to run on a fast CPU?
You think that is bad, try running 'rain' on an xterm! -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slowing down an old program to run on a fast CPU?
On 2005-06-10 15:44, Mike Hunter [EMAIL PROTECTED] wrote: Hey everybody, I was playing around in ports and came across xroach. Cool program :) The only problem is that it runs too fast; you can't see the roaches because they scurry under your windows too quickly. A port patch would fix this nicely, I guess :-) But it's not a general solution that would work by something like: % slowdown -f 0.025 ./a.out ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slowing down an old program to run on a fast CPU?
On Fri, Jun 10, 2005 at 03:44:15PM -0700 I heard the voice of Mike Hunter, and lo! it spake thus: Is there a general-purpose approach to this kind of problem in the FBSD world? I can see myself writing a C program called `slow` that would take argv[1] as the factor ( 1) by which argv[2] should be slowed down by. It'd be tough. One way might be a wrapper program that SIGSTOP'd and SIGCONT'd the program with some pauses, but that would be incredibly nasty and probably not too pretty. A better way could would be to wrap the program with a library implementing sleep() and friends differently, so they pause for N times as long. But even that doesn't help when the programs don't slow themselves down. I guess the only general solution would be an API into the scheduler saying Don't give this program more than N% of the CPU, but I'm pretty sure we don't have one. It'd be neat, though... /usr/bin/too-nice-for-its-own-good8-} -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
NDIS driver Intel(R) PRO/Wireless 2200BG reaches kernel panic
Hello. I have installed FreeBSD 5.4 on a ASUS S5200N. Runs very nice! However I still need to install Wifi. I saw that Intel(R) PRO/Wireless 2200BG is not supported by wlan FreeBSD driver (reading through the man pages). Then I found that I could use the NDIS driver added on FreeBSD 5.3 to achieve Wireless Networking. So, I copied the Windows driver to /sys/modules/if_ndis. Then I run the command: ndiscvt -i w29n51.INF -s w29n51.sys -o ndis_driver_data.h After that: make make install Everything goes fine, but when I do: kldload ndis.ko kldload if_ndis.ko I get this: no match for MmMapIoSpace no match for MmUnmapIoSpace no match for WmiTraceMessage no match for IoWMIRegistrationControl no match for WmiQueryTraceInformation ntoskrnl dummy called... ndis0: Intel(R) PRO/Wireless 2200BG Network Connection mem 0xfe8fe000-0xfe8fefff irq 18 at device 5.0 on pci1 ndis0: NDIS API version: 5.1 ndis0: Ethernet address: 00:0e:35:40:56:24 ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 5.5Mbps 11Mbps ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ntoskrnl dummy called... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8002 fault code = supervisor read, page not present instruction pointer = 0x8:0x8002 stack pointer = 0x10:0xd4c71adc frame pointer = 0x10:0xc24b57b0 code segment= base 0x0, limit 0xff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 556 (kldload) trap number = 12 panic: page fault Uptime: 2m13s Cannot dump. No dump device defined. What does this mean (I know what means page fault)? Does this mean that there is a bug in the NDIS driver? Or is the page fault a problem in the Windows driver? And, what about all those no match for *? The example I found on the internet used NDIS API version: 5.0. Does the NDIS driver for FreeBSD support the 5.1 API? I tried to find more reading man pages but without success... Am I just plain stupid wrong with something? By the way, FreeBSD runs a lot faster that Windows XP on my laptop, even with KDE. ;-) I will appreciate any hints you can provide... Best regards, Braulio Solano ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
