panic: initiate_write_inodeblock_ufs2: already started on 6.0-RC1 with Intel SRCU42L RAID.
I ran into this panic this evening; PR entered as kern/87861. The filesystem that gets this is on an Intel SRCU42L RAID5 array and that seems to be the important characteristic. This also happens in 5.4-stable, so it's not something special about 6.0. I can reproduce this at will so it will be easy for me to help diagnose it. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
in_cksum() for ip packets with multiple mbufs
i come across this unusual problem. i changed the ip_tos field of the struct ip and computed the checksum by using in_cksum(). when the packet uses only one mbuf the computed checksum is ok but when the packet uses more than one mbuf then the computed checksum is wrong. eg. pinging with payload less than 1470 bytes is ok but with payload greater than 1480 bytes does not work. (the error being bad checksum --that i knew by capturing network packets by ethereal) is it a real problem or i have made some mistake. i put the code before the if_output() in the ip_output() function. help !! kamal __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: in_cksum() for ip packets with multiple mbufs
On 2005-10-23 01:30, kamal kc [EMAIL PROTECTED] wrote: i come across this unusual problem. i changed the ip_tos field of the struct ip and computed the checksum by using in_cksum(). when the packet uses only one mbuf the computed checksum is ok but when the packet uses more than one mbuf then the computed checksum is wrong. Note that the IP header contains a checksum of the IP header only. A common mistake is to calculate the checksum of data too, which results in an invalid IP header checksum. eg. pinging with payload less than 1470 bytes is ok but with payload greater than 1480 bytes does not work. (the error being bad checksum --that i knew by capturing network packets by ethereal) is it a real problem or i have made some mistake. i put the code before the if_output() in the ip_output() function. Show us the diff, if possible :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: in_cksum() for ip packets with multiple mbufs
i changed the ip_tos field of the struct ip and
computed the checksum
by using in_cksum().
when the packet uses only one mbuf the computed
checksum is ok but
when the packet uses more than one mbuf then the
computed checksum is
wrong.
Note that the IP header contains a checksum of the
IP header only.
A common mistake is to calculate the checksum of
data too, which results
in an invalid IP header checksum.
ok i made this mistake to calculate the checksum
over the entire IP payload.
i corrected this and used the ip_hl field :::
/* the argument m is the (struct mbuf *) that
* contains the packet data
*/
void copy_the_memorybuffer(struct mbuf **m)
{
struct mbuf *mbuf_pointer=*m;
struct mbuf **next_packet;
next_packet=mbuf_pointer;
struct ip *my_ip_hdr;
my_ip_hdr=mtod((*next_packet),struct ip *);
my_ip_hdr-ip_tos=64;
my_ip_hdr-ip_sum=0;
my_ip_hdr-ip_sum=
in_cksum((*next_packet),(my_ip_hdr-ip_hl2));
...
}
but still it doesn't seem to work. and the problem
is still there.
i am really confused ..
eg. pinging with payload less than 1470 bytes is
ok but with payload
greater than 1480 bytes does not work. (the error
being bad checksum
--that i knew by capturing network packets by
ethereal)
is it a real problem or i have made some mistake.
i put the code before the if_output() in the
ip_output() function.
Show us the diff, if possible :)
sorry i did not understand what to show here.
does it mean to show the packet data captured by
the ethereal..
thanks kamal
__
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: in_cksum() for ip packets with multiple mbufs
On 2005-10-23 04:13, kamal kc [EMAIL PROTECTED] wrote:
/* the argument m is the (struct mbuf *) that
* contains the packet data
*/
void copy_the_memorybuffer(struct mbuf **m)
{
struct mbuf *mbuf_pointer=*m;
struct mbuf **next_packet;
next_packet=mbuf_pointer;
struct ip *my_ip_hdr;
my_ip_hdr=mtod((*next_packet),struct ip *);
my_ip_hdr-ip_tos=64;
my_ip_hdr-ip_sum=0;
my_ip_hdr-ip_sum=
in_cksum((*next_packet),(my_ip_hdr-ip_hl2));
...
}
Why all this pointer fun? How do you know that it's safe to dereference
`m' when you do:
struct mbuf *mbuf_pointer=*m;
Why are you dereferencing `m' once to obtain mbuf_pointer and then
taking the address of that to obtain next_packet, when you could
just do:
next_packet = m;
There are also several other problems with copy_the_memorybuffer() as
it's written above:
- It's considered bad style to mix declarations and code the way you
have done above
- It is probably better to return the copy of the mbuf you're
fiddling with, instead of modifying in place a parameter of the
function.
- If you are not *REALLY* copying the data of the mbuf, then
the name of copy_the_memorybuffer() is very confusing.
- What is the magic constant 64 that is assigned to ip_tos?
What you probably want to do is something like:
void
ip_set_type_of_service(struct mbuf *m)
{
struct ip *iph;
assert(m != NULL);
iph = mtod(m, struct ip *);
iph-ip_tos = IPTOS_PREC_IMMEDIATE;
iph-ip_sum = 0;
iph-ip_sum = in_cksum((uint16_t *)iph, iph-ip_hl 2);
}
but that's not copying anything.
but still it doesn't seem to work. and the problem
is still there.
You have obviously made a lot of changes that we haven't seen yet.
Instead of posting snippets here and there, save a copy of the original
sources somewhere, then a copy of the new sources, and run diff(1) on
the two directories to extract *ALL* the changes.
$ cd /usr/src
$ diff -ruN src.old/ src/ /tmp/patchfile
and put the patchfile somewhere online where we can have a look at all
the changes.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
iSCSI initiator driver beta version, testers wanted
this is the second round of tests, the driver is cleaner, handles multiple LUN's ok, and can handle big (256) tagged opening. so far it's been tested on OS: FreeBSD-5.4/6.0 both intel amd64, UP SMP targets: NetAPP, Intransa, SanRAD, Cisco, Promise, Equallogic still missing: most important is recovery after a network disconnect. the source is in: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-12.tar.bz2 danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Accessing USB Mass Storage Device
At about the time of 10/20/2005 4:04 AM, Bernd Walter stated the following: On Tue, Oct 18, 2005 at 10:38:45PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel Rudy [EMAIL PROTECTED] writes: : : When the umass driver is compiled into the kernel, and one inserts a USB : mass storage device, how does one access the device descriptors (serial : number) while the device is listed as a da device? I would perfer to : have the OS do all the work of accessing the hardware. The serial number can be obtained with devifo. However, since cam doesn't hook into the device tree, mapping da number to umass number can be tricky in the arbitrary case. devinfo -v | grep umass umass0 pnpinfo vendor=0x054c product=0x014d devclass=0x00 devsubclass=0x00 release=0x0110 sernum=0052450548137984 intclass=0x08 intsubclass= at port=0 interface=0 This is the USB serial number, there might even exist another one at CAM device layer. e.g.: [108]cicely13# camcontrol inquiry -n da -u 1 pass1: General Flash Disk Drive 2.05 Removable Direct Access SCSI-2 device pass1: Serial Number ST92163-2000 pass1: 1.000MB/s transfers [110]cicely13# devinfo -v | grep umass0 umass0 pnpinfo vendor=0x0483 product=0x1307 devclass=0x00 devsubclass=0x00 sernum=4710765066451 interface=0 intclass=0x08 intsubclass=0x06 at port=1 That was one of the first things that I tried. It didn't work. All I got was a blank line. -- Daniel Rudy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Accessing USB Mass Storage Device
On Sun, Oct 23, 2005 at 07:34:45PM -0700, Daniel Rudy wrote: At about the time of 10/20/2005 4:04 AM, Bernd Walter stated the following: On Tue, Oct 18, 2005 at 10:38:45PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel Rudy [EMAIL PROTECTED] writes: : : When the umass driver is compiled into the kernel, and one inserts a USB : mass storage device, how does one access the device descriptors (serial : number) while the device is listed as a da device? I would perfer to : have the OS do all the work of accessing the hardware. The serial number can be obtained with devifo. However, since cam doesn't hook into the device tree, mapping da number to umass number can be tricky in the arbitrary case. devinfo -v | grep umass umass0 pnpinfo vendor=0x054c product=0x014d devclass=0x00 devsubclass=0x00 release=0x0110 sernum=0052450548137984 intclass=0x08 intsubclass= at port=0 interface=0 This is the USB serial number, there might even exist another one at CAM device layer. e.g.: [108]cicely13# camcontrol inquiry -n da -u 1 pass1: General Flash Disk Drive 2.05 Removable Direct Access SCSI-2 device pass1: Serial Number ST92163-2000 pass1: 1.000MB/s transfers [110]cicely13# devinfo -v | grep umass0 umass0 pnpinfo vendor=0x0483 product=0x1307 devclass=0x00 devsubclass=0x00 sernum=4710765066451 interface=0 intclass=0x08 intsubclass=0x06 at port=1 That was one of the first things that I tried. It didn't work. All I got was a blank line. Neither the USB serial number nor the CAM one must exist. And if they exist noone garanties that they make sense, in the case above the CAM one sounds more like a chip identification than a unique serial number. However the devinfo umass* line must exist, at least without a serial. To make things more confusing, an USB device may even have different serial numbers in different languages, while it is not often used an USB device can have strings in several languages, the serial number is not an exception here. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
devinfo(3) problem...
Consider the following code fragment:
(segment 2)
Calling code section:
/* get devinfo root nexus */
printf(root ptr: %p\n, root);
result = usb_devinfo_root(root);
printf(root ptr: %p\n, root);
if (result 0)
{
usb_devinfo_close();
return(-1);
}
/* internal: get devinfo root nexus */
int usb_devinfo_root(struct devinfo_dev **root)
{
printf(root: %p\n, *root);
*root = devinfo_handle_to_device(DEVINFO_ROOT_DEVICE);
printf(root: %p\n, *root); second call printf
if (*root == NULL)
{
if (usb_param_use_error == TRUE) error(usb.c: usb_devinfo_root:
root device not found, errno);
if (usb_param_errors_fatal == TRUE) exit(2);
return(-1);
}
return(0);
}
The problem is that devinfo_handle_to_device always returns a null
pointer here. Why? The next code segment, devinfo_handle_to_device
returns a proper address.
(segment 1)
/* get devinfo root nexus */
root = devinfo_handle_to_device(DEVINFO_ROOT_DEVICE);
if (root == NULL)
{
devinfo_free();
return(-1);
}
output:
usb_param_devmode: 255
usb_param_devtype: 255
usb_param_mode_pref: 0
ioctl result: -1
devinfo result: 0
found_ioctl: 0
found_devinfo: 1 first call
devinfo device name: umass0
usb_devinfo_open result: 0
root ptr: 0x2815769c
root: 0x2815769c
root: 0x0 second call
usb.c: usb_devinfo_root: root device not found: No such file or directory
root ptr: 0x0
Fatal: Unable to get device information
Now I have made sure that I have called devinfo_free() during the first
call before calling devinfo_init() a second time. I tried calling this
code branch on the first time, and it executes properly, so why does it
fail on the second call?
--
Daniel Rudy
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvi for serious hacking
On Tue, Oct 18, 2005 at 02:08:40AM +0900, Sangwoo Shim wrote: Actually the first thing that I do after minimal installing of new system is to install vim from the ports tree. (in fact, installing cvsup, of course :-) I remember once upon a time someone (david?) made a suggestion that nvi in our tree should be changed to vim-lite(or something.) I'm tend to agree with that.. (Although vim is GPL'd, nvi is in the src/contrib anyway..) Please no ;-) Although vim has some nice features its definitively different to standard vi behaviour, which can really bitch you in some situations. Most favourite example: I personally still get mad if it comes to the u undo key. Standard vi lets you toggle your last change by hitting u. So I'm used that it doesn't hurt to type the u key multiple times. This is very usefull to let your eye browse through a complex change to make an a/b comparison. If you do that in vim, then you loose as many last changes as you hit u repeatedly. And if you did many changes you loose a serious amount of work. From my experience you cannot recover from such a mistake. Therefore standard vi is for me much superior, since with it I can get my job done in a reliable manner without fancy side effects. I don't want to start an editor flamewar. I know many people who start to like vi starting with vim. And editors are an issue of taste and experience in use ... Its only a thing to take into consideration whats better. To learn standard vi, thats available everywhere. Or to have the same situation as with emacs ... Vim is still kind of an exot for me. That its standard vi on nearly all Linuxes around still doesn't qualify it enough as standard vi... Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? - http://www.apsfilter.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: in_cksum() for ip packets with multiple mbufs
void copy_the_memorybuffer(struct mbuf **m)
{
struct mbuf *mbuf_pointer=*m;
struct mbuf **next_packet;
next_packet=mbuf_pointer;
struct ip *my_ip_hdr;
my_ip_hdr=mtod((*next_packet),struct ip *);
my_ip_hdr-ip_tos=64;
my_ip_hdr-ip_sum=0;
my_ip_hdr-ip_sum=
in_cksum((*next_packet),(my_ip_hdr-ip_hl2));
...
}
Why all this pointer fun? How do you know that it's
safe to dereference
`m' when you do:
struct mbuf *mbuf_pointer=*m;
Why are you dereferencing `m' once to obtain
mbuf_pointer and then
taking the address of that to obtain next_packet,
when you could
just do:
next_packet = m;
There are also several other problems with
copy_the_memorybuffer() as
it's written above:
- It's considered bad style to mix declarations
and code the way you
have done above
- It is probably better to return the copy of
the mbuf you're
fiddling with, instead of modifying in place a
parameter of the
function.
one thing i would like to ask?
does it make any difference if i free the mbuf 'm'
passed to if_output() and pass my own mbuf to
if_output.
is the original mbuf referenced by any
other pointers or global variables ??
i couldn't figure out much from the sources.
- If you are not *REALLY* copying the data of
the mbuf, then
the name of copy_the_memorybuffer() is very
confusing.
i didn't showed in the above code snippet but
actually i am copying the data contained in the
mbufs in a character array.
my purpose is to compress the data contained in
the ip packet
- What is the magic constant 64 that is assigned
to ip_tos?
that was just to see that i could actually modify
the ip header.
What you probably want to do is something like:
void
ip_set_type_of_service(struct mbuf *m)
{
struct ip *iph;
assert(m != NULL);
iph = mtod(m, struct ip *);
iph-ip_tos = IPTOS_PREC_IMMEDIATE;
iph-ip_sum = 0;
iph-ip_sum = in_cksum((uint16_t *)iph,
iph-ip_hl 2);
}
thanks i will try this code and try to make the
code simpler next time.
but that's not copying anything.
but still it doesn't seem to work. and the problem
is still there.
You have obviously made a lot of changes that we
haven't seen yet.
Instead of posting snippets here and there, save a
copy of the original
sources somewhere, then a copy of the new sources,
and run diff(1) on
the two directories to extract *ALL* the changes.
$ cd /usr/src
$ diff -ruN src.old/ src/ /tmp/patchfile
and put the patchfile somewhere online where we can
have a look at all
the changes.
i am new to kernel sources and kernel programming and
thank you for informing me on the diff(1).
thanks to you that the problem was solved (i don't
know if it is completely ok). i found that
- i had made mistake in computing checksum.
earlier checksum was computed over the whole
dat
I may soon put up patchfiles on web.
thanks.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: in_cksum() for ip packets with multiple mbufs
void copy_the_memorybuffer(struct mbuf **m)
{
struct mbuf *mbuf_pointer=*m;
struct mbuf **next_packet;
next_packet=mbuf_pointer;
struct ip *my_ip_hdr;
my_ip_hdr=mtod((*next_packet),struct ip *);
my_ip_hdr-ip_tos=64;
my_ip_hdr-ip_sum=0;
my_ip_hdr-ip_sum=
in_cksum((*next_packet),(my_ip_hdr-ip_hl2));
...
}
Why all this pointer fun? How do you know that it's
safe to dereference
`m' when you do:
struct mbuf *mbuf_pointer=*m;
Why are you dereferencing `m' once to obtain
mbuf_pointer and then
taking the address of that to obtain next_packet,
when you could
just do:
next_packet = m;
There are also several other problems with
copy_the_memorybuffer() as
it's written above:
- It's considered bad style to mix declarations
and code the way you
have done above
- It is probably better to return the copy of
the mbuf you're
fiddling with, instead of modifying in place a
parameter of the
function.
one thing i would like to ask?
does it make any difference if i free the mbuf 'm'
passed to if_output() and pass my own mbuf to
if_output.
is the original mbuf referenced by any
other pointers or global variables ??
i couldn't figure out much from the sources.
- If you are not *REALLY* copying the data of
the mbuf, then
the name of copy_the_memorybuffer() is very
confusing.
i didn't showed in the above code snippet but
actually i am copying the data contained in the
mbufs in a character array.
my purpose is to compress the data contained in
the ip packet
- What is the magic constant 64 that is assigned
to ip_tos?
that was just to see that i could actually modify
the ip header.
What you probably want to do is something like:
void
ip_set_type_of_service(struct mbuf *m)
{
struct ip *iph;
assert(m != NULL);
iph = mtod(m, struct ip *);
iph-ip_tos = IPTOS_PREC_IMMEDIATE;
iph-ip_sum = 0;
iph-ip_sum = in_cksum((uint16_t *)iph,
iph-ip_hl 2);
}
thanks i will try this code and try to make the
code simpler next time.
but that's not copying anything.
but still it doesn't seem to work. and the problem
is still there.
You have obviously made a lot of changes that we
haven't seen yet.
i did not put the whole code because i am a bit lazy
and the code is cumbersome. and i thought that
it was causing the problem.
Instead of posting snippets here and there, save a
copy of the original
sources somewhere, then a copy of the new sources,
and run diff(1) on
the two directories to extract *ALL* the changes.
$ cd /usr/src
$ diff -ruN src.old/ src/ /tmp/patchfile
and put the patchfile somewhere online where we can
have a look at all
the changes.
i am new to kernel sources and kernel programming and
thank you for informing me on the diff(1).
thanks to you that the problem was solved (i don't
know if it is completely ok). i found that
- i had made mistake in computing checksum.
earlier checksum was computed over the whole
data but now i calculate checksum over the
header only.
- byte ordering.
tell me one thing isn't the byte order of the
ip_id in network byte order in the mbuf when passed
to the if_output() ??
i had to use the htons() to ip_id before computing
the checksum
- final thing does this makes any difference
(calling the htons() twice):
ip-ip_id=htons(ip-ip_id);
ip-ip_id=htons(ip-ip_id);
I will try put up patchfiles on web.
thanks very much,
kamal
__
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
